View Full Version : QuEnc 0.72
MrC
20th November 2006, 13:27
Hi,
i have a undersize problem with QuEnc 0.71 too.
I have solved turning back to QuEnc 0.70, which has a better filesize control when encoding in VBR 2 pass mode.
;)
Bye
________
vaporizers (http://vaporizers.net/)
dragongodz
27th November 2006, 05:37
QuEnc 0.70, which has a better filesize control when encoding in VBR 2 pass mode.
though can throw some bad quality frames with tight max bitrate restrictions where 0.71 doesnt.
sorry i have been busy changing ISP amongst other things. will have to get back in to updating QuEnc soon. just cant say exactly when yet. :)
MrC
27th November 2006, 13:37
...[cut]...get back in to updating QuEnc soon. just cant say exactly when yet. :)
We will stay tuned!
Always :thanks:
Bye
________
Honda CBR250RR (http://www.cyclechaos.com/wiki/Honda_CBR250RR)
MrC
27th November 2006, 13:39
Another question, maybe yet asked....
DGZ, are you planning to introduce some kind of H264 encoding in future versions of QuEnc?
Bye
________
Suzuki SV1000 (http://www.cyclechaos.com/wiki/Suzuki_SV1000)
dragongodz
28th November 2006, 03:33
are you planning to introduce some kind of H264 encoding in future versions of QuEnc?
its possible. i havent made any plans to at the moment though. maybe if enough people want it i may add it to the list.
Guest
6th December 2006, 17:26
I used Quenc to encode a 24fps AVS script. The resulting MPEG2 file had a frame rate of 23.976. Why did it change the rate and how to I stop that? Thank you.
dragongodz
7th December 2006, 02:54
The resulting MPEG2 file had a frame rate of 23.976.
sorry but can not confirm. i just tested a 24fps clip and it came out 24fps mpeg aswell.
after you load the AVS in QuEnc can you press the "i" button next to the "Source AVS file" line ? that will give you the information QuEnc is getting about the clip/source from Avisynth.
if that says 24fps and still encodes to 23.976fps then can you please give details on what settings etc you are using ?
vlada
6th January 2007, 16:57
Hi, recently I tried to encode a movie in 1368x720 resolution. Unfortunately I received an undersized result (4300 kbps instead of 6000 kbps). I had the absolutely same problem with a standard DVD-Video encode (720x576@25fps) last week. I hoped the rate control will be improved in 0.71, but I'm still getting undersized movies. I have checked VBR, HQ, Trellis, 2-pass and Auto Max Bitrate.
Is there anything I could do to improve this? Thank you.
MrC
12th January 2007, 14:01
Hi, recently I tried to encode a movie in 1368x720 resolution. Unfortunately I received an undersized result (4300 kbps instead of 6000 kbps). I had the absolutely same problem with a standard DVD-Video encode (720x576@25fps) last week. I hoped the rate control will be improved in 0.71, but I'm still getting undersized movies. I have checked VBR, HQ, Trellis, 2-pass and Auto Max Bitrate.
Is there anything I could do to improve this? Thank you.
Use QuEnc 0.70. It has a better rate control when doing VBR 2-pass
:)
Bye
________
FZ750 (http://www.cyclechaos.com/wiki/Yamaha_FZ750)
Mug Funky
15th January 2007, 08:10
hmm. i haven't had any undersize (or oversize, or max bitrate spikes) with 0.71
perhaps trellis should be turned off? the settings i tend to use are HQ, DC precision 10 bits, closed GOP (12, 2 bframes). matrix doesn't seem to matter here, and interlaced or progressive give the same results wrt ratecontrol.
i almost exclusively encode PAL.
MrC
16th January 2007, 14:30
To me 0.71 gives *always* undersizing problems with this kind of configuration:
2 pass ON
VBR ON
HQ ON
Trellis OFF
DC 10
GOP 12
B-Frame 2
Interlaced OFF
Auto Max BitRate OFF
:(
Same configuration but QuEnc 0.70, almost no undersizing problems....
;)
Bye
________
C200 (http://www.cyclechaos.com/wiki/Honda_C200)
Mug Funky
18th January 2007, 00:10
Auto Max BitRate OFF
if this is so, what number is entered for Max bitrate? 9800? 8500?
because that may have something to do with it, though i admit it's a bit of a straw-clutching effort on my part.
dragongodz
18th January 2007, 10:58
ok i have already said this previously but i will say it again.
yes QuEnc 0.71 can sometime undersize more than 0.70. HOWEVER 0.70 can also throw the occasional bad frame(very high quant) especially when max bitrate is close to target bitrate. the undersized 0.71 should look more pleasing than those bad frames to most people.
Mr_Odwin
18th January 2007, 12:47
I discovered a small thing (really small). The ac3 files generated when a bitrate of 32k is selected seem to be unplayable.
dragongodz
18th January 2007, 13:11
The ac3 files generated when a bitrate of 32k is selected seem to be unplayable.
only if 2 channels or more. 32k mono does work though it doesnt sound that great, as should be expected. really why would you want to use such a ridiculously low bitrate though ? the only time i would ever even think of using that low is if the soundtrack was purely beeps. for anything like voice or music people should use a more sensible bitrate.
MrC
18th January 2007, 13:52
if this is so, what number is entered for Max bitrate? 9800? 8500?
Usually I use 2000+Avg if Avg<5000 and 1000+Avg if Avg>5000
:)
Bye
________
FJR1300 (http://www.cyclechaos.com/wiki/Yamaha_FJR1300)
vlada
19th January 2007, 08:29
dragongodz
What is the problem with bitrate control in QuEnc? Other encoders usually don't have such problems. I had undersized movies and exceeded max bitrate with basically all QuEnc versions. Why is it so difficult to make it work properly?
Mr_Odwin
19th January 2007, 10:46
This may be a foreign language thing but your post comes over as kind of aggressive. I think if the issue was simple then dragongodz (who appears to be a proficient coder) would have it completely sorted by now, but it's clearly not trivial.
Even if it was trivial, it's free software and the author can get around to fixing it whenever he wants.
As it stands, I love QuEnc and use it pretty much every day. If I ever notice anything amiss it's because I use it so much.
dragongodz
19th January 2007, 10:48
Other encoders usually don't have such problems.
ok so i wont mention how CCE has been known to go over max bitrate. i wont mention how Mainconcept has been known to undersize. i wont mention how HC has been known to undersize etc etc etc etc etc etc etc etc etc etc etc.
Why is it so difficult to make it work properly?
any time you feel like rewriting the rate control please go right ahead. or if you would rather i will stop right now and people can go and use those "other encoders" and i will bin QuEnc instead of me obviously holding a gun to peoples heads and waisting my time.
vlada
19th January 2007, 12:47
Mr_Odwin, dragongodz
I'm very sorry if I sounded agressive, I didn't mean to. I was just interested in the issue from a technical point of view. I appreciate your hard work and I know that you're doing it for free in your spare time. Unfortunately I'm not a C/C++ programmer so I can't help with the development.
I remember that many encoders had problems with wong output size, but most of them work correct now. At least I never had any problems with 2-pass in XviD, x264 or HC.
Mug Funky
20th January 2007, 18:15
one problem with max bitrates is how they're calculated.
one example that springs readily to mind is Spruce - they made authoring software and a hardware encoder to go with it. all are specifically for making DVDs.
between maestro's bitrate viewer, it's DVD muxer and the encoder you have 3 different ideas of what a compliant max bitrate is. set the max to 8500 and you'll sometimes get spikes over 12mbps. the bitrate profiler shows the spikes, but the muxer doesn't throw any errors. sometimes the muxer will abort a compile when the profiler doesn't show any problems.
...and that's with hardware and software that were designed to work together. the same happens with Scenarist and streams produced with Sonic encoders - scenarist will reject streams made by it's own encoder.
now take something like QuEnc. scan it in BitrateView (the green one with the green quant graph and yellow bitrate graph) and a quenc 2-pass encode will show it going over the max bitrate by a lot. scan the same stream again and you'll have different numbers that follow the same curve. then you could scan the stream in Moonlight Streameye and it'll report a max bitrate well within what you set in quenc.
so which software is lying? quenc, bitrateview or streameye? the trick is that it's all open to interpretation and really it's a matter of luck as to whether there'll be playback issues or not - because every decoder or chipset or standalone player will have different ideas on how high is too high.
FWIW, 2-pass in quenc hasn't given me any problems. 1-pass has a tendency to spike in 2 particular situations, but if you lay off the custom matrices and just set the max bitrate maybe 500 kbps below what you normally would (and well above the average or you might as well go 1-pass or CBR), even these situations are no problem (for those interested - hard cuts between no-motion, bugger-all detail scenes to very complex ones, and bursts of pure white noise are the only situations i've seen that cause problems in 1-pass).
dragongodz
25th January 2007, 15:46
small update. QuEnc 0.72. see first post in this thread.
sorry but the last couple of months have been very busy. hopefully mid february should see things settling back down.
feedback welcome of course.
Fishman0919
25th January 2007, 16:38
Very Good dragongodz.... Thank You very much. I'll give it a try tonite.... got a few thing that need to be encoded.
Guest
25th January 2007, 18:09
When making an HD sized encode, QuEnc should set the high level indication in the stream. Without that, many players cannot play the resulting stream. I had to hack a tool to fix the M2V in that regard. But QuEnc should do it.
dragongodz
26th January 2007, 01:57
When making an HD sized encode, QuEnc should set the high level indication in the stream.
it appears some work on that has just begun with ffmpeg so hopefully that should be done with the next QuEnc release aswell.
Ebobtron
27th January 2007, 19:15
dragongodz,May I add my thank you to the list? I would like to add extra thanks for the additional information in the last couple of versions.
Some time ago, we were discussing AC3 encoding and the audio levels. My Recent work with the encoder suggests you really hit the mark with two channel encoding.
-3db in -3db out two channel.
The source for this test was orchestral music 4 minutes long
A six channel encode gave the following results
-3db in 0db out 6 chan.
-9db in 2.9db down a 3.1 db gain.
here I used white noise one channel at a time for channel identification. Each channel excluding the LFE was amplified some 6db +-.3
You have reached unity in the first case, which is way cool. :cool:
Fearing that a white noise test was as far from reality as one could get
An active six-channel source that is 2.7db down gave the following.
-2.7 db in -.2db down
that is more like it, the two peaks where both held off the rail.
Not at all unity but I can deal. Great work.
So now that I have buttered you up a little.
a = WAVSource("DMC_2point7db_down.wav")
l = GetChannel(a, 1)
r = GetChannel(a, 2)
c = GetChannel(a, 3)
lfe = GetChannel(a, 4)
rl = GetChannel(a, 5)
rr = GetChannel(a, 6)
MergeChannels(l, c, r, rl, rr, lfe)
My POV is very simple, AviSynth's audio output is a wav file. One needs do nothing with the stream to save it. Figure out how many bytes, write the header chunks. A wave file.
This should have the channel order l, r, c, lfe, rl, rr.
To support my argument I offer NicAc3Source which decodes to the wave file order (all hail Nic :) ).
My point:
Shouldn’t QuEnc take a six-channel wave format and output a properly ordered ac3 file?
Great work thanks again
Rob
dragongodz
28th January 2007, 03:06
My POV is very simple, AviSynth's audio output is a wav file.
but is it really ? i mean does it always output to wav order or does it simply use input(decoder) order to the same output order ? that really should be tested, especially with different decoders, to see if any do not reorder to wav format. if any do not then it leaves the same problem of having to reorder in avisynth anyway.
Shouldn’t QuEnc take a six-channel wave format and output a properly ordered ac3 file?
actually this has been suggested on the ffmpeg list several times and its flatly rejected for whatever reasons.
as i have stated previously, the less i have to change in ffmpeg source the better since anytime i want to update that means going back through and finding and redoing all the changes.
however if you can show me, or i can not find otherwise, that all decoders output to wav format then i will definatly consider making the changes.
Ebobtron
29th January 2007, 16:05
dragongodz,
Well I read your post, put my Don Quixote on and Poncho and I went out upon the internet tilting at ambiguity. Sadly, I lost my Aldonza (my passion). Quote:
My POV is very simple, AviSynth's audio output is a wav file.
but is it really ?
Yes, it is. A PCM data stream using 16 bit samples has the first 16bits as channel one and the second as channel two. If the next 16bits are channel one again we have a two channel stream, but you know this.
And considering the results of my quest, my point of view, irrelevant. Relevance requires reality.
FFMPEG doesn’t make a six channel wave from a six channel anything. The current change log did not describe a change. So like if you do not make a 5.1 wave. You can ignore that it exists.
BeSweets ac3encod.dll is based on “FFMPEG'S AC3ENC“. AC3 channel ordering required. BeSweet will decode ac3 to a properly (???) channel-ordered wave file or not if you prefer. At least they know that the 5.1 spec exists.
ac3tool not do it, proper ac3 -> ac3tool -> incorrectly ordered PCM stream
headac3he not either proper ac3 -> headac3he -> incorrectly ordered PCM stream
Aften do it correctly, 5.1 Wave -> aften -> decoder -> correctly ordered PCM stream
5.1 wave in 5.1 ac3 out, cool.
As for the rest. Sorry, the data does not support a conclusion at this time.
the first six channels has been well described
Multiple Channel Audio Data and WAVE Files
Updated: December 4, 2001 (http://www.microsoft.com/whdc/device/audio/multichaud.mspx)
Not exactly new information.
actually this has been suggested on the ffmpeg list several times and its flatly rejected for whatever reasons.
There it is.
You could reorder the stream and leave the ffmpeg code alone, would be a bit slow. But why should you be the only one? I can not ask this of you.
"I am one of many. I choose to be different, very different." me
Horse ran away……… Poncho left too………
I think I will take my sword and go home….
Nothing left to do but sing the damn song…. :o
Thanks :)
Espio
30th January 2007, 07:48
I just encoded two videos of exactly 24 minutes in length and got 271Mb for the first and 342Mb for the second. The audio and muxing are done outside of QuEnc, but I don't think they would give such varied results. Also, the audio is CBR at 128kbps. And the source resolutions are the same, and the sizes, etc.
Settings are:
MPEG-2
avg bitrate - 1800kbps
max bitrate - 8000kbps
use VBR - on
HQ - on
Trellis - off
2 pass - on
Just did another video of same length, etc and got 236Mb.
Ebobtron
30th January 2007, 09:24
Why would you expect them to be the same? With vbr on the bitrate will vary. Different pictures require different encoding different motion requires different encoding. :)
Fishman0919
30th January 2007, 13:01
@ Ebobtron
24 min of video is about 34,525 frames.... it wouldn't matter if you were encoding clip A, clip B or clip C.... if you tell the encoder to encoded 34,525 frames @1800k you should get a video file about 323mb... A+B=C...it's math (formula shown is not intended for real uses) ;-)
Settings are:
MPEG-2
avg bitrate - 1800kbps
max bitrate - 8000kbps
use VBR - on
HQ - on
Trellis - off
2 pass - on
VBR is the type of encoding,but MPEG2 uses ABR (average bit rate), meaning using VBR make the ABR of the encoding @1800k
Edit: Sorry, unless you were doing a 1-pass VBR... then clip differences would matter.
@Espio
Are you comparing sizes before or after you are muxing the audio
Ebobtron
30th January 2007, 18:23
@ Fishman0919Well,
I was being a bit of a butt. :) Sorry. :o
I guess Espio wants us to assume what other settings he may be using. He needs to provide dragongodz with more info.
With the settings he provided I can't make the filesize vary more than about 2 percent between high motion and low. Is he NTSC or PAL? Is he ... ??
Fishman0919
30th January 2007, 18:58
With the settings he provided I can't make the filesize vary more than about 2 percent between high motion and low. Is he NTSC or PAL? Is he ... ??
NTSC or PAL wouldn't matter, you will get diff size between ntsc and pal but from clip to clip you will get the same size.
24 min of video is 24 min of video, NTSC or PAL, 3 diff encodings in PAL of 24 min should be about the same size, footage won't change the fact, and the same for NTSC
Sorry, I'm not trying to come across harsh and if I am... I am sorry, but 24 min at 1800k = same result
I did 4 encodings of 24 min @1800k, 2 with HC and 2 with CCE (1 Basic and 1 SP2), all came out to be right around 323mb.
No encoder is going to be right on target but the vary he is getting is a bit much
Ebobtron
30th January 2007, 19:45
Those things may matter to the program. If the program has an error it may only occur when using certain setting.
Affar
30th January 2007, 20:11
new version is 0.72.
QuEnc 0.72
----------
.fixed separate not working with -close
.changed will not encode pulldown when interlaced disabled but pulldown enabled
.small tweak to 2 pass ratecontrol
:thanks: :thanks: :thanks: :thanks: :thanks:
good job :sly:
dragongodz
30th January 2007, 20:28
put my Don Quixote on and Poncho and I went out upon the internet tilting at ambiguity.
sorry Ebobtron you lost me a bit with this post. i must have been transfixed by the windmills. ;)
24 min of video is 24 min of video, NTSC or PAL, 3 diff encodings in PAL of 24 min should be about the same size, footage won't change the fact
actually it can. are all 3 clips the same type of footage(action, still, grainy, smooth - meaning compressability) ? whats the resolution ? whats the average quant results ? so little information to go from that post.
oh and QuEnc doesnt pad of course. :)
No encoder is going to be right on target but the vary he is getting is a bit much
to which i would need much more information to know why there is such a variance.
Fishman0919
30th January 2007, 21:20
Sorry, and I am assuming that the res is the same for all the clips being encoded.
Espio
2nd February 2007, 22:10
Okay, the video is all one type (anime, and of the same series), the sizes are after the audio is muxed, but the audio is at 128kbps CBR, so that shouldn't matter. The resolution in each video is 768x432, GSpot shows the codec as DivX4 (OpenDivX) average bitrate as 655kbps. I don't know how to find the average quant results so if you tell me how, I'll get you those.
I know QuEnc doesn't pad, which is good, I'm just wondering if that's the reason for the size differences. The audio encoding program is BeSweet v1.5b31. Hope this helps.
dragongodz
3rd February 2007, 04:57
anime, and of the same series
can you say which series and which 3 episodes ? i am a big anime fan aswell so if its something i have i can test specifically against that. ok mine would be PAL but its something to start with anyway.
768x432, GSpot shows the codec as DivX4 (OpenDivX) average bitrate as 655kbps
oh dear. why do i have a nasty feeling that doesnt look real good(smoothed, lost all fine detail etc) ? that is nowhere near high enough bitrate for that resolution, atleast for standard anime.
I don't know how to find the average quant results so if you tell me how, I'll get you those.
there is bitrateviewer(can be a bit dodgy with what it reports i find) and elecard streameye. either of those should be able to give you the average quant of the encoded mpeg. that is the part to find out.
Ebobtron
3rd February 2007, 11:02
@dragongodz,To understand you must take up the quest (helps if you’re a little senile).
I had asked you to reorder the six channel ordering of QuEnc’s ac3 encoder. Your reply suggested a number of issues, and your remark about a more convincing argument sent me galloping off upon my high horse in search of that.
Background:My personal needs for artificial surround channels is not, and I never work with real ones personally for my projects. It should be no surprise to anyone that I know little about ac3 encoders.
My work with avsFilmCutter prompted the sudden interest when I discovered that writing wave files from AviSynth sources was child’s play as long as you maneuver around the 64-bit math landmines.
When you offered “72” I remembered the audio issues and I wondered how that had or had not progressed. My ability to measure the progress has also improved greatly and when I looked over the two channel data I was very pleased. Having the ability to create clean six channel wave files that I can measure, I tested the six or 5.1 channel gain/loss of QuEnc’s ac3.
This is how I was reminded of the channel order issue which I didn’t fully understand (still don‘t think I do, do not really care either). I did along the way find that the dragon (not you) has ruled for sometime with no attempt to lop off his or her fetid head.
In besweet and ffmpeg and QuEnc, this is a ffmpeg problem.
You said they are disinterested in changing it.I can ask you to take up the sword with me, I believe that would be fruitless for one and confusing for the current users. Or I can do the more informed thing and not.
“getchannel.htm” remark 1, from the AviSynth documentation, to me has a problem.I, me the user, should not have to care about the channel order of the ac3 file or dts file. That is the job of the encoder/decoder.
I do not want to appear ungrateful for the ability to reorder the channels from within the script. I just do not think there is a good reason that I should have to other than I apparently have to.
Of course, all this is my humble opinion. The dragon will die someday or it might live on forever, we still buy software and operating systems from the guys who gave us 640K of continuous RAM and paged the rest.
Well don’t we. :o
Oh and just off hand which dumb butt made the final decision on wave files railing at 0 db. If your reading this, did you ever hear of the term headroom? Can you actually read?
:) Thanks for the interest and your good work.
dragongodz
3rd February 2007, 13:25
You said they are disinterested in changing it.
actually what i said was i am reluctant to make the change as it means having to make it every time i update ffmpeg/libavcodec source.
also
“getchannel.htm” remark 1, from the AviSynth documentation
as you mention shows how different audio formats have different channel orders. and add in the part mentioned at the top of that page
The ordening of the channels is determined by the ordening of the input file, because AviSynth doesn't assume any ordening.
this means its up to the decoder what order avisynth gets the channels in, and thus outputs them. that is does it present them in the order of the format or does it output them in wav order ? if it doesnt re-order to wav order then avisynth doesnt output it as wav order. so you would have to re-order them with avisynth(via script) anyway if wav order is what you or the encoder wanted.
start to see the dilemma ? i do not know which decoders present any of the different audio formats in which order. so if i assume it will always be wav order that could also open up a trap for any that do not.
so i may change it to assume wav order eventually but i would want to test, or be shown tests, of different decoders first to see how they handle it. even just taking AC3 as an example there is multiple decoders(including directshow usage etc).
Ebobtron
3rd February 2007, 20:13
so i may change it to assume wav order eventually but i would want to test, or be shown tests, of different decoders first to see how they handle it. even just taking AC3 as an example there is multiple decoders(including directshow usage etc).That was my first campaign, it was a total loss. There is no consistent data for you to review.actually this has been suggested on the ffmpeg list several times and its flatly rejected for whatever reasons.This "dragon head" is more important to me because if they don't change why should you be any different. QuEnc suddenly being different, would add to the ambiguity. And I don't believe the return for that much additional work is worth it.I, at first, thought the issue much simpler than it appears to be. With what I understand today, I find my request without merit. Therefore I withdraw said request and beg my leave of you, my lord. :) I shall have to find another windmill.
Thanks
Ebobtron
5th February 2007, 05:28
@dgodzDid you see this.http://slideitondvd.com/Supporters.html
Very strange and off putting.
The gentleman who runs this site, addressed the issue.
Espio
5th February 2007, 07:32
Well, it's a TVrip fansub, so the quality isn't all that important, but it looks pretty good for the bitrate and resolution. Anyway, the series is Mushi-shi, subbed by ANBU, episodes 1-3.
I'm assuming the numbers you want are the peak and average Q levels (from Bitrate Viewer), so here they are:
Episode 1: Peak:2.27
Average:2.00
Episode 2: Peak:2.07
Average:1.10
Episode 3: Peak:4.20 (spiked at beginning for some reason)
Average:1.99
Boulder
5th February 2007, 07:39
Those values look like there's encoder saturation - the video is probably so smoothed that there's not much detail left. Try a quant matrix that is meant for high bitrates (such as Fox Home Entertainment) and see if the problem still occurs.
Espio
6th February 2007, 03:26
Sorry to sound dumb, but I don't know how to use quant matrices or where to get them, unless QuEnc has them built-in.
Mug Funky
6th February 2007, 12:10
quenc takes the same matrix format xvid takes. you can load them in if you go to advanced settings.
you can get by with just standard and qlb (for low bitrates) though. of course, if you're getting saturation you should put in something like didee's 6of9 HVS or similar.
[edit]
as for obtaining these matrices,:search:
dragongodz
11th February 2007, 06:09
Episode 1: Peak:2.27
Average:2.00
Episode 2: Peak:2.07
Average:1.10
Episode 3: Peak:4.20 (spiked at beginning for some reason)
Average:1.99
yep thats looking pretty close to saturation. B-frames are a little biased towards up than down so you would probably find they are the greatest area for taking the average above 1. really though they are rather motion dependant so thats not hurting them as much. in other words better to have Q1 I and P etc.
tamahome
19th February 2007, 01:06
personally since the versions 0.7x quenc is unusable, I encode under diko, everything works well with version 0.61, but with the versions 0.7x quenc launches out and cuts themselves 2-3 minutes after without reason: /
Mug Funky
19th February 2007, 12:25
get rid of the -mpeg2 switch, probably.
i've had no problem on the 20 odd computers i've run it on :)
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.