QuEnc 0.60 Released!

[Nic]

QuEnc 0.60 Released! New two pass control :)

http://nic.dnsalias.com


New XviD Ratecontrol in 2 Pass mode!
Added a MPEG-1 System mux mode
Can apply pulldown to the encode
Bug fixing...More stable (for use in more than one instance of QuEnc, etc)
Tooltips
A bunch of other stuff I'm too ill to remember ;)


Have fun :)

-Nic

EDIT:
Just release 0.61! Slight bug in the MPEG-1 System Mux was fixed.

[Mug Funky]

weeeee! thanks, nic.

[Koepi]

Great! :)

Unfortunately I did my last full-dvd-encode just yesterday and I've no projects on hold, so it needs some time until I can test it :)

Thakns for your work Nic!

Cheers
Koepi

[Teegedeck]

Yaaay! Congrats! The only MPEG-2-encoder I'd ever use turns 0.60! :)

[dragongodz]

a milestone indeed. Nic releases a 0.60 version. seems he has overcome that demon. :D

[communist]

Great! I have 4 SVCDs to encode for a friend and I just started the first pass on the first disc with 0.59 - might aswell abort it and use this version :D

Quick test with a few small test files: No more crash when running several instances in 2pass mode. Quality seems as good as with 0.59b4 if not slightly better.
Thank You :)

[Affar]

I have same problem with previous version. When i encode this CLIP (http://www.divxhouse.com/temp/error_db.avi), the encoded video has one frame less than source.

Thanks

[ginoboy]

Great!! Excellent! :cool:

Thank you Nic! ;)

[]'s

[communist]

Originally posted by Affar
I have same problem with previous version. When i encode this CLIP (http://www.divxhouse.com/temp/error_db.avi), the encoded video has one frame less than source.

Thanks
AFAIK this is not a QuEnc bug but a VfW / B-frame issue (the 'B-frame decoder lag' message).

[TuRiSOft]

Hey NIC thank you !!! With you and Hank who needs more to use not freeware MPEG2 encoders?

[robot1]

Thank you, Nic.
Will test soon.

[Nic]

@Affar: When I put that AVI clip in VDub, it says it has 149 frames. When I encode a M2V file and run it through BitrateViewer, it says it has 149 frames too. What discrepancy are you seeing and how do I replicate it.

-Nic

[Affar]

I dont know where is the problem, but this persist in 3 diferent pc.

ERROR with this scripts
(avisynth 2.5.5 + ffdshow october 2005 + xvid 1.1)

Avisource("O:\error_db.avi")
BicubicResize(352,576,0,0.50)
ConvertToYV12 ()

Directshowsource("O:\error_db.avi")
BicubicResize(352,576,0,0.50)
ConvertToYV12 ()


Quenc configuration:

quenc.exe -i "script.avs" -o "O:\error_db.m2v" -b 1600 -maxbitrate 2500 -dc 10 -priority 4 -2 -mpeg2 -hq -vbr -scene -notrell -nocgop -nointerlaced -noextreme -gopsize 15 -maxbframes 2 -nocmatrix -aspectratio 4:3 -mpeg2mux noaudio -auto -close

And bitrateviewer says... 148 frames
http://www.divxhouse.com/temp/error_db.gif

any suggestions?

[Pookie]

Awesome. I love this encoder. Can't wait to try out the new version.

[dragongodz]

And bitrateviewer says... 148 frames
yes i got that but look at the number of pictures read, 149.

i tested the .avs with Tmpgenc 2.5 and MainConcept 1.4 aswell and guess what, exact same results.
mpeg stream eye says 149 frames for all of them by the way.

also tried loading the avi in to Tmpgenc and it said 177 frames. tried MC and it said 149 but actually encoded 1 less (147 frames, 148 pics read in bitrate viewer). weird avi. :D

so sorry but this is not a QuEnc problem since the other encoders are encoding exactly the same.

[unixfs]

Nic,
I have a question for you: can you explain what algorithm
you use to calculate the SCR?
In mencoder I used a series of tricks (
something similar to: for every pack scr = Gop initial pts + (delta data/ N) where N is the sum of video and audio data I'm about to mux
), but I realize it's a flawed and too simplistic method.

Often it works well, but sometimes audio pts diverges too much from scr;
additionally it's impossible to manage multiple audio tracks.

I'm looking for better alternatives.

Thanks.

[Nic]

@unifxs: Thankfully libavformat takes care of it for me :) SCR is a pain, I remember coding ReJig and that being one of the most difficult problems for getting DVD compatability just right. I honestly can't remember that much about it now. Sorry. I remember MPUCoders forum had a nice thread on it once.

-Nic

[manolito]

Next version will probably be 0.60 which will have Beta 3's 1st Pass RC and XviD's 2 pass RC. -Nic
Just did a 1 pass VBR encode with 0.61 which came out way undersized (2.52 GB instead of 4.7 GB). As far as I remember my 1 pass encodes with 0.59 Beta 3 always came out right, only Beta 4 1pass VBR was broken.

Another question about the new tool tips:
Scene Detection --- Bad for DVD encoding
Closed GOP --- Recommended for DVD encoding

From my experiences with CCE just the opposite should be true.

Cheers
manolito

[Nic]

@manolito:
1Pass VBR has always been a bit flaky, due to it's very nature. 2Pass is definitely the way to go. 2 Pass also enable the XviD ratecontrol. But I'll look into seeing what I can do.

"From my experiences with CCE just the opposite should be true"
What experiences are those? Could you elaborate. In reality any which way should be fine. Scene Detection can cause bizarre GOPs (i.e. very short GOPs) that a DVD player might not like, but I'm sure most don't have a problem. Closed GOPs are useful for seeking, but aren't necessary. Share your experiences...Are you talking from a quality point of view? If so, then closed gop = false and scene detection = true would probably equate to better quality.

-Nic

ps
@dgz: What changed between beta 3 & 4 again? I can't remember :)
(Ok, time for me to start using a CVS or at least write a changelog)

[dragongodz]

just my humble opinion

Scene Detection --- A few dvd players may not like it 100%
Closed GOP --- Only required for multi-angle DVD encoding or editing

What changed between beta 3 & 4 again? I can't remember
for 1 pass encoding nothing. however what you could try is changing
lmin = 1 * FF_QP2LAMBDA;
to
lmin = 1;
or
lmin = 0.6 * FF_QP2LAMBDA;

since if you remember the use of lambda caused undersizing with 2 pass for over about 4000Kb/s.

actually, just looking, i see you have lambda in the low bitrate setting aswell so would probably want to change that aswell. so either = 2 or = 1 * FF_QP2LAMBDA.

Ok, time for me to start using a CVS or at least write a changelog
since you used to go over/erase versions changes when you did a new one in the same thread a lot of what was changed when was lost. it would be handy though.

[manolito]

@Nic

Well I was wrong about Beta 3 getting 1 pass VBR right. I just redid the same encode with Beta 3, and it also came out terribly undersized.

CCE was the first encoder I used (I came here through DVD2SVCD), and this is what the CCE manual says about Scene Change Detection and Closed GOP:
If Restrict auto I frame insertion is selected, image quality will be slightly degraded. Therefore, do not select this unless necessary.
If Close all GOPs is selected, image quality will be slightly degraded. Therefore, do not select this unless necessary.
"Restrict Auto I frame insertion" is how you disable Scene Change Detection in CCE.

Everybody at the DVD2SVCD thread seemed to agree that these were the best settings for CCE, so I never even bothered to play with them.
1Pass VBR has always been a bit flaky, due to it's very nature.
Just a technical question about 1Pass VBR with libavcodec based encoders:

In CCE and TMPGEnc and HC you do not have control over average bitrate with 1Pass VBR, so some kind of prediction is required if you need a fixed output size. If I understand it right, a 1Pass VBR in CCE (they call it OPV) is just a constant quant encode with the exception that the min and max bitrate restrictions are observed.

Now how does QuEnc manage to do a 1Pass VBR without prediction? Do you start with a certain fixed quantizer and then constantly monitor average bitrate (or file size) and adjust the quantizer dynamically?

Cheers
manolito

[Nic]

@manolita:
What CCE states is quite correct. For quality scene change detection is very good. Closed GOP also stops predication across GOP boundaries so it can hurt quality. But both might cause compatability (scene=on & cgop=off) problems and the enhancement to quality is minimal. I really don't know. Probably makes so little difference either which way it probably isn't worth discussing ;)

I see you can understand why it probably comes out undersized. VBR one pass encoding is very hard to get right unless what you do is limit the range so much that it's almost CBR anyway. QuEnc can do Constant Quant too you know. Just enter a bitrate between 1-31 and it runs in Constant Quant mode.

-Nic

[dragongodz]

damn, i must have had invisible post mode on again. i hate when that happens. :sly:

[Mug Funky]

i've just noticed that the new ratecontrol seems to hit fades-to-black a little too hard - you can confirm this by looking at the quantizers (or just watching it :)). not sure if this falls under the category of "small tweak" or "major rewrite"...

also, though i trust xvid's and thus quenc's new ratecontrol, Maestro has been complaining about occasional buffer underflows (very few) on compiling. it does this with HC as well, so perhaps it's just maestro's problem (bitrateview doesn't show any unnecessarily high peaks). [edit: my max bitrate is 8500]

aside from that, the ratecontrol is working perfectly - good quality and spot-on the bitrate.

i wonder whether it'd be possible to enter a filesize into the little bitrate box? i think this was mentioned a while ago in the request thread...

[nnigam]

Strange behavior with the quenc output with .61 version.

I am capturing my dv camera output to an avi file using windv, capturing the timecodes using dv_datecode. Somehow avisynth is not opening the avi using AVISource so I have to use DirectShowSource. I then process the avs file with quenc .61. It complains about YV12 so I added convertoYV12 into the avs script. The output then becomes an mpg file not an m2v file which muxman refuses to open.

So I process the mpg from above with dgindex, and then use that in in the avs script, and remove the convertoyv12 line. Everything else is the
same, but this time I get an m2v file which Muxman reads just fine. No changes are made in the quenc settings, and the only change in the avs file is to remove the convertoyv12 line, and change directshowsource to mpegsource. Actually I used the script I use to process the avs files and added convertoyv12 to it for the first step.

I do not see any option for mpg/m2v, and chaning the extension in the output file name does not work.

I really would like to know what is going on since now I have to process the files twice through quenc. I upgraded my pc to amd athlon 64, and process time is down to about 3 hours but still would like to avoid having to run quenc twice on the same file.

[Nic]

Ok, I assume what's happening is that, when using DirectShowSource at least some sort of Audio stream is also coming through. Go to the advanced settings and in the mux profile part (lower left corner). Select "No Audio". After encoding the filename may still say .mpg, but will really be a raw mpeg-2 file (.m2v) so you can change it then add it into muxman.

Make sure the video is also the right resolution and frame rate otherwise muxman won't like it.

-Nic

[nnigam]

Thanks, I did not think of that. I think the audio is in the mpeg file.

Frame rate, resolution etc are all taken care of as defaults in the script.

[Wilbert]

Well I was wrong about Beta 3 getting 1 pass VBR right. I just redid the same encode with Beta 3, and it also came out terribly undersized.
Friday i had to do a bunch of mpeg-1 files (with 0.61). They also came out very undersized, although the encoding still had a lot of visible blocking. Highering the average and max bitrate didn't help.

[Koepi]

Weird, my last encode was aiming for 4.3GB and ended up at 3GB - I assumed the codec is saturated. The "original" was very crappy quality so I can't tell fo sure if QuEnc could have done better. (Target bitrate was 3950kbps, max bitrate 8000kbps.)

Cheers
Koepi

[Nic]

@Wilbert: Was that with 2 pass, or one pass?

@Koepi: How does a bitrate graph of the file look like? Is Quant 1 getting used much?

[Wilbert]

@Wilbert: Was that with 2 pass, or one pass?
It was 2 pass (i didn't try 1 pass).

[onesoul]

I tried to send you private message Nic, since your box is full I will post here :p

"Hi Nic, I am sending you a pvt although I am not sure I should post in the quenc thread instead." - lol

I found a weird ghost encoded by Quenc 0.61 as you can see at the bottom of the following pics:
http://img223.echo.cx/img223/6892/quenc0610000506pq.jpg
http://img251.echo.cx/img251/7413/quenc0610000513kv.jpg

It happens at frame 50 and 51, I did the encode at average 3100kbps, I noticed that as dc precision goes higher the worse it gets.

Here are the links to the source clip I used (around 103 mb total):

Your Download-Link: http://rapidshare.de/files/2038719/birds_original.part1.rar.html
Your Download-Link: http://rapidshare.de/files/2040566/birds_original.part2.rar.html
Your Download-Link: http://rapidshare.de/files/2040501/birds_original.part3.rar.html

Left click on them, and then click on free download below.

I find this clip a good test, the fading scenes and specially the fading in to the clouds moving are very hard ones (which I found quenc to be better than others on this particular scene). But generally quenc presents more blocks and noise. The undesizing issue is notorious too.

note: sorry I didn't see if the ghost issue happened to earlier quenc versions.

Hope it helps with you something.

Cheers,
onesoul

[Nic]

Thanks a lot for that onesoul....I look into them ASAP. (My PMs are cleared now :) )

-Nic

[video_magic]

This is all edge-of-the-seat action :) but is it true that the actual guidelines for how mpeg works (or some vital parts) are not viewable and have to be worked out or guessed? - I think this is the case unless people pay to see them, I have read up a lot on the net but it seems this is for mpeg-2 for DVD and I don't know about mpeg-1 which I gather is for VCD. Either ways it's more respect to Nic for working this stuff out! The more I read around I just get more despairing and more glad for Quenc and other people that make the tools :thanks:
Kind of a long shot but is Quenc going to be developed for new Mpeg technlogies like whatever is coming in as the next generation after mpeg-1 and 2. I know that sounds kind of a weak question but now I am looking at this archiving I do wonder about this situation long-term, I trust you understand even if there is no sound answer :o Is Mpeg-4 better for the near long-term Nic, I mean over DVD? I was just thing about DivX and other Mpeg-4 and noticed it looks as good at lower bitrates and I understand there
is hardware player support, so I had to compare this to DVD in my mind. either way, Mpeg-2 for DVD is great for a lot of my current needs like archiving lectures and general footage where high-detail is not the issue.

Thanks a lot for your current work and any hints :)

[Nic]

@onesoul: Just tried to download your files. I didn't notice they were on rapidshare. I can never download from there, my ISP/IP Address is pretty much blocked by them :( Any chance you could upload it elsewhere?

@video_magic: Depends on your needs. MPEG-4 (and it's part 10 H264/AVC) is definitely the successor to MPEG-1/2, But still mainstream support is rare. MPEG-2 is going to be around for a long long time, so it's a good choice for archiving and compatability.

-Nic

[Koepi]

Heya Nic,

ok, I'll try to find a tool which gives me statistical data about an mpeg2.

On a sidenode, since I quit my current job next monday and have a little time before starting with my next one then, I'll try to interface xvid with QuEnc and get a basic avi muxer working - that'd sure rock, a all-in-one encoding solution ;) (Only if you think that's no bad idea of course.).

Cheers
Koepi

[dragongodz]

I'll try to find a tool which gives me statistical data about an mpeg2.
mpeg stream eye can give you info such as average bitrate etc. so may be a starting point.

I'll try to interface xvid with QuEnc and get a basic avi muxer working - that'd sure rock, a all-in-one encoding solution (Only if you think that's no bad idea of course.).
avformat has avi muxxing so thats shouldnt be a problem. actually we did discuss this once before and some of us thought having 2 seperate apps, QuEnc for mpeg1/2 and ??Enc for things like snow etc to avi, would be better.

anyway i am sick as a dog so am back off to bed.

[Swede]

@onesoul: Just tried to download your files. I didn't notice they were on rapidshare. I can never download from there, my ISP/IP Address is pretty much blocked by them :( Any chance you could upload it elsewhere?I'll d/l them for you and put them in your webspace...

[onesoul]

Thanks Swede :). I should have known better.

Nic, I am experiencing the same problem as you (ISP/IP blocked) which wouldn't happen before. Now I can't even download the files I uploaded myself, lol, isn't that weird?

[Nic]

@Swede: Thanks as always :)

@onesoul: rapidshare is a nice idea in principle, but has it's problems. I haven't looked into trackerless bittorrents since their introduction, that might be a nice solution for things in the future.

@koepi: Do with QuEnc as you please. Probably compiling FFMPEG with XviD (I think it supports it) and Lame and then adding it to QuEnc is a nice solution. But if you really do have a few moments of time, i'd love it if you could browse the ratecontrol code in QuEnc. It's pretty easy to read (harder to follow though) and could perhaps do with some tweaking (I can't figure out why undersize occurs and don't have the time to look into it right now).
Congrats on the new job! :)

@dgz: I'm very ill too right now. It sucks.

-Nic

[Koepi]

dgz, nic: get better soon!

Nic: Thanks - it's really a nice job I'm going to get :)

As I need to look into the sources first anyways before starting such a (not too simple IMO) task I could of course look into ratecontrol.
Which values do you set for "container overhead"? That would account for maybe up to 3MB undersize if there isn't real frame-based container overhead in mpeg1/2.

But i'll have to see - it's only a few days until I can get to that :)

Cheers
Koepi

[zilog jones]

IfoEdit is giving me "buffer underruns" (or something like that) with videos I encoded with QuEnc when authoring DVDs. Am I doing something wrong?

The video is 720x576/25fps, from an avs (yv12)
Here's the settings I used:
6500kbps VBR, 2-pass, high-quality
Trellis Quant
12 GOP; 2 max b-frames (is this the default? i don't think i changed it)
Interlaced TFF
DC precision 9
Scene detection
4:3 AR
9500 max bitrate
No audio

[Koepi]

Your max bitrate isn't dvd compliant. Set it to 8500 (-audio bitrate).

[Encoder Master]

I though 9800Kbps is the max. standart of DVDs?!
But with a bitrate of 9500Kbps he has enough for the Audio (for example 256Kbps) and it is dvd-kompliant.

[zilog jones]

Yeah, I thought the max was 9800 too, but I thought underruns were caused by the bitrate being too high in some place, so it makes sense.

Thanks for the help!

[Mug Funky]

max total peak for DVD (including audio, subs, etc) is 10.08mbps

max peak for video only is 9.8

max for any one stream in multiangle is 8.0 minus all audio/subs (so for a 2.0 ac3 you'd end up with absolute max for multiangle video at 7776 kbps, but i'd recommend going a lot lower). additionally, length and GOP structure must be the same for multiangle.

when all's said and done, between poor quality pressings and varying playback equipment, 8.5mbps is a safe max for video. if you're very confident in your encoder's rate control, you could go to 9.0 as well.

remember that a standalone will probably have more difficulty reading burnt DVDs, meaning max bitrate should be conservative here as well (though a good burn will play as well if not better than a badly glass-mastered disc).

it would be so much easier if DVD players had larger buffers - then we could let the bitrate breathe a bit more, and also there'd be no pause at layer breaks.

[Nic]

@onesoul: Thanks again for the clip :) Finally got round to looking at it (I'm still pretty ill, bad chest infection, makes breathing a b***h)

I'm surprised you found the problem (it's so hard to spot). I think it's a motion problem. I'll try and track it down. I might PM you a private build to test, if you'd be willing?

Thanks again,
-Nic

@Swede:Thanks for getting me those files. :)

ps
EDIT: Ok, stupidly, with ffmpeg, you can have EPZS motion estimation or none whatsoever (don't be confused by such options as FULL, etc, they don't actually exist and default to NONE). With NONE however, the problem is gone! And the quality doesn't appear actually any worse?! There must be a bug in the motion code of ffmpeg. I'm going to try and make the bug easy to replicate for the ffmpeg crew, to see if they can fix it.
(I think it only mucks up on things like fades, but it shouldn't be breaking that badly)

[onesoul]

@Nic

No problem, a small contribution it is (I'm sounding like Yoda, lol). I thank you for developing Quenc :).
And thanks for the explanation also, sure I'd like to help testing new version. Maybe when ffmpeg motion estimation is corrected, quality will improve also?

I found it almost by accident, I was comparing the different encoders with that clip, especially at the fading scenes, and I do that by going frame by frame (using avscompare with up to 4 windows). It sounds a bit excentric, I admit that ;).

Get well soon, that goes to dgz too.

[dragongodz]

with ffmpeg, you can have EPZS motion estimation or none whatsoever (don't be confused by such options as FULL, etc, they don't actually exist and default to NONE
so ME_FULL, ME_LOG and ME_PHODS in motion_est.c are never actually used do you mean ?

I do that by going frame by frame
so how many frames does this happen on out of curiosity ?

Get well soon, that goes to dgz too.
thanks. feeling much better, medication does wonders. :D
probably back to 75% but still coughing up things i would rather not be. sounds like Nics worse with the breathing probs.
get well soon Nic and yes i know it sucks.

[onesoul]

so how many frames does this happen on out of curiosity ? In two frames, the ones I linked to. The frame right before was black.