NuEnc 0.00d & Libavcodec improvements/suggestions

[tie82]

Hi,

i have big probs with your avcodec.
Using it with FreeEnc, the encoder always crashed after the 1. pass (just closed itself). Then i used 1pass-coding to see the result and he gave me a corrupt m2v with a picture like this:
http://home.arcor.de/ossionline/Zwischenablage01.jpg

With the original FreeEnc-avcodec there are no problems except the bitrate (much too small)
With the avcodec from quenc i have no probs anyway, but i want to test yours :).
Using Win XP Pro on an Athlon XP 2400+.

Perhaps you know wath the prob is or it can help you in the development ;)

Greets
tie82

[Amnon82]

The version compiled 09.09.04 chrashed my newest ESD 0.5. I add now the 01.09.04 dll to this release.

[Asmodeus]

Originally posted by tie82
Hi,

i have big probs with your avcodec.
Using it with FreeEnc, the encoder always crashed after the 1. pass (just closed itself). Then i used 1pass-coding to see the result and he gave me a corrupt m2v with a picture like this:
http://home.arcor.de/ossionline/Zwischenablage01.jpg

With the original FreeEnc-avcodec there are no problems except the bitrate (much too small)
With the avcodec from quenc i have no probs anyway, but i want to test yours :).
Using Win XP Pro on an Athlon XP 2400+.

Perhaps you know wath the prob is or it can help you in the development ;)

Greets
tie82

Last build of FreeEnc isn't set for newest Peter's avcodec build, so this might hapen, and also in my computer hapens.
For sugestion about FreeEnc beter go here (http://www.kvcd.net/forum/viewforum.php?f=85&sid=28e07ce7753bb9c61a74bba1953fca57).

[Peter Cheat]

Current Development Status (for those who care)
-----------------------------------------------

1. Two algorithms are being developed simultaneously. One which allocates quantisers to frames, and one that allocates bits to frames.

Allocating quantisers is the best for constant quality it seems. Bit allocation introduces so many uncertainties, I frames either get too many bits or too few bits, B frames sometimes get a quantiser lower than the P frames on either side. This is a problem. Using >3 passes solves the problem with bit allocation, and it turns out to be better than a quantiser distribution with the same number of passes.

2. Max bitrate is adhered too properly.

3. Bit allocation algorithm broke the buffer underflow protection code. Should still work properly with quantiser distribution.

4. X-pass encoding. If CCE has 10 passes, why not have infinite? (ok, its pointless, but why not have it if you can)

------------------------------------------------

Expect an update on Wednesday. It will come with a clean compile of QuEnc (obvioulsy renamed to not cause confusion) which will work 100% and take advantage of X pass encoding. I will probably move the site elsewhere, because host.sk is slow and people are having trouble getting files from it.

[dragongodz]

(for those who care)
many of us do. :)

If CCE has 10 passes, why not have infinite? (ok, its pointless, but why not have it if you can)
well you already answer yourself, its pointless. with CCE doing more than 3 or 4 passes is pointless, i dont know why they bothered to go all the way to 10 passes.

[lithoc]

IMHO,I would say if there's features that allow turbo mode in the 1st pass like Xvid would be nice.
I don't mind doing more than 2 passes if it's faster.

[Bogalvator]

I'd just like to say that I also follow your developments with great interest and I eagerly await your updated QuEnc.

Keep up the good work!

[Peter Cheat]

Originally posted by lithoc
IMHO,I would say if there's features that allow turbo mode in the 1st pass like Xvid would be nice.
I don't mind doing more than 2 passes if it's faster.

Ok, this will be a feature. Turbo mode will disable trellis and any other features that slow down the encoding process, but have negligible affect on the statistics obtained, just like XviD.

@dragongodz
Allowing infinite passes actually meant I delete/simplify some code. Also allowed me to check how good the algorithm for quantiser distribution was. By 6-7 passes, the output was spot on in the filesize department without the use of the bit pool, ie the frame sizes were almost exactly what was predicted. This means that by this stage the encode is optimal. I tested with short clips, I don't know if longer clips will need more, less or the same number of passes to be optimal. I'll see if PSNR improves with more passes.

[dragongodz]

Allowing infinite passes actually meant I delete/simplify some code.
thats fine, passes can always be limited outside the rate control, such as gui/commandline.suchj as
if(maxpass > x) maxpass = x; // where x is max allowed passes

I'll see if PSNR improves with more passes.
you may want to check out SSIM aswell, meant to be better(not perfect of course) than PSNR which has been shown before to not be 100% reliable. there is a plugin for avisynth which you can use to compare 2 clips.

[dragongodz]

oh ye, is min bitrate working with your changes aswell ? that would be very good to have fixed too. :)

[Peter Cheat]

Min bitrate was always working correctly. Libavcodec adds padding when a frame is below the min bitrate. Deliberatly lowering the quant to stay above the min bitrate is not really an option - the quality difference becomes very noticeable.

[dragongodz]

Min bitrate was always working correctly
actually no it wasnt. it used to be when min rate was set to anything other than 0 the bitrate calculation would be buggered. so you wouldnt end anywhere near your target.

Libavcodec adds padding when a frame is below the min bitrate
this was added with 0.49pre1. i dont know when it was actually commited to cvs.

though with your rewriting the allocation etc anyway i guess it shouldnt be a problem. :)

[lithoc]

Originally posted by Peter Cheat
Ok, this will be a feature. Turbo mode will disable trellis and any other features that slow down the encoding process, but have negligible affect on the statistics obtained, just like XviD.



Thanks a lot.

I'm very happy with the developement of this project and looking forward to do some testing. And when the bitrate management is done, hopefully Michael can update it to the main cvs.

[Peter Cheat]

I've had problems getting my modifications to work with QuEnc. I recompiled QuEnc with my DLL, and it encodes, but not correctly. The second pass stats mess up, for some reason. The compressibility seems to be calculated incorrectly. I'm wondering if QuEnc interferes with the texture information, which will wreck my results. Maybe the log() function becomes broken when using with C++ compiled executable. Does anyone know what the problem could be? Also, after doing an X pass encode, I get an error when closing QuEnc saying that "memory could not be read". Do you know the problem Nic?

[dragongodz]

try changing the line

c->rc_initial_cplx = 500;

to

c->rc_initial_cplx = 0;

in AVSEnc.cpp.

also make sure when you compile you use the --enable-memalign-hack option.

[Peter Cheat]

Originally posted by dragongodz
try changing the line

c->rc_initial_cplx = 500;

to

c->rc_initial_cplx = 0;

in AVSEnc.cpp.

also make sure when you compile you use the --enable-memalign-hack option.

c->rc_initial_cplx won't change anything as I don't even use complexity for x pass. Enabling the memalign hack doesn't help, because thats enabled in my compile already. I tested without memalign hack, and it was still wrong. I'll compile it in Cygwin and see if it helps.

[dragongodz]

ok. if you still have problems you can always send me the source and i can try compiling it and see if i can spot whats wrong.

[zilog jones]

I had some weird problems with the GUI - if I pressed the "show desktop" button (in Win2k) while encoding, i couldn't restore the QuEnc window again. It was still working (according to task manager) and made what seemed to be an OK video, but I couldn't see what was happening. I dunno if someone's reported this already. I've got a GF2 and DirectX 9.0b if that's of any help.

Also, if there's two things missing from this great encoder (which I've found sooo much better than TMPGEnc for interlaced video!), it's batch encoding and an auto-shutdown option.

[dragongodz]

bug reports or ideas should go in the normal QuEnc thread really.

I dunno if someone's reported this already.
no i havent seen anyone else report it. anyone else have that problem ?

batch encoding and an auto-shutdown option
auto-shutdown is very easy actually. batch is a bit harder and i dont know if Nic was interested in adding that or not. you could do it now by doing a BAT which calls and encodes several files 1 after the other.

[Peter Cheat]

Originally posted by zilog jones
I had some weird problems with the GUI - if I pressed the "show desktop" button (in Win2k) while encoding, i couldn't restore the QuEnc window again. It was still working (according to task manager) and made what seemed to be an OK video, but I couldn't see what was happening. I dunno if someone's reported this already. I've got a GF2 and DirectX 9.0b if that's of any help.

Also, if there's two things missing from this great encoder (which I've found sooo much better than TMPGEnc for interlaced video!), it's batch encoding and an auto-shutdown option.

Thats not a bug. The GUI has lower priority than the encoder. Lower the priority of the encoder, and this will not happen...

BTW, notice the update. Try it out. Should be better. The problem I had was actually an error in a formula in the rate control. For some reason, the problem only showed itself when used with QuEnc (NuEnc).

[Amnon82]

Only thing I can say is: WHOW!

This multipass is amazing! I tested now 2, 3, and 4 Pass. It's realy great. I think You rebuilding CCE for free :)

Go on with Your great work. I'm waiting for the next REAL release.

I do a test with chapter 29 of Matrix. I'll post my result soon on my page and link it here.

to the test: http://forum.doom9.org/showthread.php?s=&threadid=82931

[spase]

If I am off topic (or posting in the wrong place) please let me know.

Will NuEnc work with DVD-Rebuilder?

[Amnon82]

@spase: NO! It doesn't support DVDRB yet. Maybe in the future.

[Bogalvator]

I tested NuEnc on a 41 minute clip I'm trying to make an SVCD of.

Set it at 5 passes, 2474 average bitrate, 2589 max bitrate, buffer size of 112, GOP of 15, max B frames of 2, turbo, trellis & "High Quality" settings were ticked, and DC precision was 8.

Bitrate Viewer reports the clip has a peak of 4305, and an average of 1915.

Something I missed?

[zilog jones]

Originally posted by dragongodz
bug reports or ideas should go in the normal QuEnc thread really. Sorry! Only noticed the other thread after posting this one...


no i havent seen anyone else report it. anyone else have that problem ?
It doesn't seem to be happening any more, actually. Maybe Windows was just being pissy. It does take a while for the window to re-appear, but then again I'm running it on a P3 ^_^

auto-shutdown is very easy actually. batch is a bit harder and i dont know if Nic was interested in adding that or not. you could do it now by doing a BAT which calls and encodes several files 1 after the other.

Oh yeah, I forgot QuEnc can do command line switches. Sounds like a plan...

[johnnyquid]

@petercheat

Nuenc version 0.00a does not appear to use the -2 switch. I was using DVD Rebuilder to test Nuenc and Nuenc does 1 pass even when asked to do 2 pass. I also started Nuenc from the command line with the -2 option and got the same result (i.e. the number of passes in the pulldown in the GUI does not change).

Also what is the turbo option and is there a command line switch for it?

Are there command line switches for more than 2 passes?

[Peter Cheat]

Originally posted by Bogalvator
I tested NuEnc on a 41 minute clip I'm trying to make an SVCD of.

Set it at 5 passes, 2474 average bitrate, 2589 max bitrate, buffer size of 112, GOP of 15, max B frames of 2, turbo, trellis & "High Quality" settings were ticked, and DC precision was 8.

Bitrate Viewer reports the clip has a peak of 4305, and an average of 1915.

Something I missed?

Ok, there does seem to be some sort of problem here. It seems the more passes you do, the more the max bitrate is increased by. It should be the other way around, but I've seen the same problem. When muxing, were any buffer underflows reported?

@johnnyquid
I didn't do anything with the commandline switches. I didn't check to see if they work. Does NuEnc report that it is doing a 2nd pass in the status area?

Turbo mode disables optimisations for first pass that slow down the encoding process. Trellis is disabled, the mbd is set to 1, and a the cmp functions are set to 0. These settings don't change the first pass stats much, so disabling doesn't really effect quality, but makes encoding much faster. There is no commandline switch for it yet.

@spase
I don't know if it will ever work with DVDRB. I wouldn't use NuEnc for backups yet anyway. You are better off using QuEnc until NuEnc is stable. When it is, source will probably be committed to CVS and QuEnc may see the changes. NuEnc will probably disappear, as it is at the moment only for testing.

What will change for next update:
-Ratecontrol equation will be able to be changed (and hence change the bitrate distribution)
-Ability to chose how aggressive to be with max bitrate
-Extra options for NuEnc (noise reduction, keep intermediate passes)

[johnnyquid]

@Peter Cheat

When using the -2 command line option Nuenc does a one pass encode while showing 1 pass picked on the pulldown list. The display also shows Pass 1/1 as it is encoding. If the -auto option is not used then the pulldown can be changed manually to do two passes. Nuenc will then do the correct number of passes. Oddly, it does not show the pass progress in x/y format but just gives the current pass number. Also note that in the -? display the description for -mpeg2 is obviously wrong.

[dragongodz]

I didn't do anything with the commandline switches.
no but you did change the 2 pass gui control. you can change it to whatever, quit, run NuEnc again and its back to 1. so the new control is not setting/using the information. :)

Turbo mode disables optimisations for first pass that slow down the encoding process
and also produces a slightly larger max bitrate, at least with just 2 passes.

cmp functions are set to 0
i had a quick look at the source and couldnt see that. not that i would reccomend setting them to 0 anyway, 1 maybe but not 0. that will effect size/frame.

[Peter Cheat]

Originally posted by dragongodz
no but you did change the 2 pass gui control. you can change it to whatever, quit, run NuEnc again and its back to 1. so the new control is not setting/using the information. :)

I see now, this will be fixed :D

Originally posted by johnnyquid
Oddly, it does not show the pass progress in x/y format but just gives the current pass number

This had to be changed for X pass. Its better to show the pass number than saying 1/2 for first pass, 2/2 for second pass, and 2/2 for any additional pass...I will change it, I just couldn't be bothered :D

I now have in my possesion the drafts for mpeg2 standards. I will write a summary of the standard, showing that my initial interpretation of what max bitrate mean is correct, and also outlining reasons for jerky playback on hardware players. I also have a book with a more simpler explanation of the standard (the final standard) stating exactly what I have been saying (MPEG-2 by John Watkinson). Buffer underflows are the problem with some streams created with libav based encoders, not the max bitrate...
The other problem is related to the muxing software, libavcodec currently writes the _WRONG_ VBV size to use (look in bitrate viewer or ReStream). Tools that use the value specified in the stream create incorrectly muxed streams. MPLEX allows you to specify the VBV to use, getting around this problem. The VBV size will be written correctly in the next version of NuEnc.

A copy of the MPEG-2 draft ishere (http://www.ee.columbia.edu/~eleft/e6880-Spring98/docs/is138182.pdf). Only minor corrections were made to the final version. This document applies to SVCD/DVD.

[dragongodz]

you may want to try setting min rate to other than 0 aswell and comparing how your rate control reacts compared to set at 0. it would be good to know that does work properly with yours. :)

[Peter Cheat]

Well, I can't test right now, but looking at the code...

static inline double qp2bits(RateControlEntry *rce, double qp, double compressibility){
...
...
...
if (new_bits < min_rate) new_bits = min_rate;
return new_bits;
}


...it should work. The ratecontrol compensates for the minimum rate internally, so there shouldn't be a problem...I will test it later.

BTW, is a CQ mode worth coding. Do people use CQ over two-pass?

[Mug Funky]

no reason not to have a CQ mode... i use them quite often, and they are good for testing various noise filters and whatnot - check the filesize after a CQ encode at quant 2 for example...

currently most of the compressibility stats on noise filters are based on mpeg-4 encodes, and though related, mpeg-2 stats would be nice to play with as well.

bottom line, it couldn't hurt.

[edit]

also, with a slow system like mine, 2 pass encodes are somewhat a luxury . a max-bitrate limited CQ encode is my preferred mode in TMPGenc and CCE (though they work with different numbers, which is a pain).

[Peter1234]

I also think a CQ mode would be a valuable addition.

[dragongodz]

i assume you mean constant quality ?

rate control equation tex is meant to be for constant quality, at least according to the documentation.

i would rather see 1 and 2 pass(or 3 pass) working fully before worrying about CQ aswell.

[Mug Funky]

actually, more specifically i meant constant quantizer (which i suppose amounts to the same thing).

this is more useful for testing filters, and is quite usable for 1-pass encoding if you make a good guess at the output bitrate (doing several encodes of a short-but-representative sample and picking a quantizer based on that gives pretty good results).

of course, this isn't a priority, but it seems like it'd be trivial to implement (there are also things i'd like to see first, such as alternate scan and a field-order setting - QuEnc is extremely good at interlaced content, and alternate scan would deliver even better quality/bitrate. with this i would never need to deinterlace again for my SVCD encodes, even on field-blended video).

[dragongodz]

yes constant quant can be done very easily. avcodec has settings for min and max quant to use. simply set them to the same and you have constant quant. :)

[RobertR]

Originally posted by Peter Cheat

The other problem is related to the muxing software, libavcodec currently writes the _WRONG_ VBV size to use (look in bitrate viewer or ReStream). Tools that use the value specified in the stream create incorrectly muxed streams. MPLEX allows you to specify the VBV to use, getting around this problem. The VBV size will be written correctly in the next version of NuEnc.

Are You refering to value of 1835? Although it may look wrong it is correct value. I don't recall now if i got the explanation from ffmpeg mailing list or kvcd.net forums but above is in kbits and is the same as 224KB ( 224*1024*8=1835008 ).

I've just checked how bitrateviewer reports vbv buffer size and in case of vob taken from dvd it's 112. Feeding bitrateviewer with ffmpeg(1) produced m2v shows the same figure. (I know i've read somewhere an explanation why it shows 112 instead of 224 but can't find it atm)

(1) Since i can't realy test it under windows i've created a patch from your files and applied it to saturday's cvs (i had just 2 easily solved rejects). I've run 2 pass encode this way and resulting m2v is visualy very good (original vob has avg bitrate at 4500, peak at 8000 ; reencoding was set to 300 min, 3500 avg, 8000 peak). I've checked output in bitrateviewer and there were parts where q was almost constant and bitrate was jumping from 2000 to 4000. I've also noticed that in some parts there is huge peak of q (goes up to 5-6) and at same very moment huge drop of bitrate (from around 3000 down to just above 1000). On original vob there is no sign of things like that.
Apart from that encoded file was well within limits (3524 avg bitrate, 7856 peak).

[hank315]

AFAIK the maximum VBV buffer for Main profile@Main level is 1835008.
So you have to put for vbv_buffer_size 112 because the VBV buffer is calculated as:

VBV buffer = 16 * 1024 * vbv_buffer_size

[RobertR]

Originally posted by hank315
AFAIK the maximum VBV buffer for Main profile@Main level is 1835008.
So you have to put for vbv_buffer_size 112 because the VBV buffer is calculated as:

VBV buffer = 16 * 1024 * vbv_buffer_size
Isn't this formula a bit recursive ? ;)
Most of other (than ffmpeg/mplayer) software uses 224 as vbv buffer size. Maybe BitrateViewer shows vbv buffer size in sectors and not in kilobytes ?

[hank315]

Maybe my ISO spec is a little bit outdated (ISO/IEC 138818-2:1995) but according to this spec this is the way to calculate the size of the Video Buffer Verifier (VBV buffer).
I always wondered why some programs would use 224 as vbv_buffer_size so maybe it is better to throw my (outdated ???) specs in the fireplace. :confused:

[Bogalvator]

Originally posted by Peter Cheat
When muxing, were any buffer underflows reported?

Apologies for the delay in responding.

TMPGEnc reported "359 s packets cause buffer underflow" - a lot less than normal.

[Peter Cheat]

Originally posted by Bogalvator
Apologies for the delay in responding.

TMPGEnc reported "359 s packets cause buffer underflow" - a lot less than normal.

It may be a lot less, but still not good enough. I question TMPGEnc's muxing capabilities. I've had problems with it, it sometimes does strange things when muxing, and reports buffer underflows when really there shouldn't be any. Would it be too much to ask to see if you could try muxing with MPLEX or BBMPEG and see if the results are consistent?

Its been a while since I've encoded in TMPEnc, but I think that when you specify a VBV of 112KB, BV reports it as 112KB. I am not sure, though.

I think that this is the correct formula:
VBV buffer = 16 * 1024 * vbv_buffer_size

but I have the feeling that FFMPEG uses:
1 byte = 8 bits
1024 = 1k
224KB * 8 * 1024 = 1835008bits

Also CQ is not exactly the same as constant quant. It is more like an average quant. Say CQ100 = Quant 1, CQ0 = Quant 31. CQ75 = Quant 7.75. But you can't have fractional quantisers. The 7.75 represents the average quant (usually the average for P Frames). It allows for an exact filesize to be achieved, provided you know what value to use. The value wanted can be established using some form of prediction.

[dragongodz]

Also CQ is not exactly the same as constant quant. It is more like an average quant. Say CQ100 = Quant 1, CQ0 = Quant 31. CQ75 = Quant 7.75. But you can't have fractional quantisers. The 7.75 represents the average quant (usually the average for P Frames).
thats why i was asking about constant quality, which is generally considered what you describe, or constant quant. lets call them by their full names so there is no confusion. :)

It allows for an exact filesize to be achieved, provided you know what value to use. The value wanted can be established using some form of prediction.
true for both dependant on the prediction method.

[Peter Cheat]

Well, not really. If you use constant quant you can have only have whole values. The filesize at quant 2 is A and the filesize at quant 3 is B. Say you want file size X. But B < X < A. You can either take the higher quality but larger file or the lower quality smaller file. If you use constant quality (not constant quant), you can use an average quant (say 2.5) to get a more accurate filesize.

[dragongodz]

sorry i should have explained that better.

what i meant was using constant quant you can get within/under your desired size(or maximum size). prediction would give you an idea how much etc so you could decide if that was desirable/adequate.

[Bogalvator]

Tried

mplex -f 4 -V ....

and it returned "**ERROR: [???] MUX STATUS: Frame data under-runs detected!"

Oddly it also said the peak was 5403, whereas BV said 4305.

Could it be because the average, 2474, and the max, 2589, are so close together?

[Peter Cheat]

Bitrate Viewer lies about what the max bitrate is. It takes the average bitrate over each second of video. Maximum bitrate is really quite irrelevant, it is buffer underflows that are problematic.

[dragongodz]

It takes the average bitrate over each second of video. Maximum bitrate is really quite irrelevant, it is buffer underflows that are problematic.
max bitrate is not irrelevant if we take the 1 simple thing that the majority of places/people/etc all state as true and part of the specs.
dvd specs at the least say a max video bitrate of 9800Kb per second. svcd specs has its max bitrate aswell and from a link you gave yourself its been stated exceeding that can cause hardware players to have problems playing the video smoothly. it is all tied in together.

[Peter Cheat]

Originally posted by dragongodz
dvd specs at the least say a max video bitrate of 9800Kb per second. svcd specs has its max bitrate aswell and from a link you gave yourself its been stated exceeding that can cause hardware players to have problems playing the video smoothly. it is all tied in together.

Do you understand what maximum bitrate means? I think not. You can either read the section in the MPEG-2 specs about the VBV buffer, or save yourself some time and read this (http://petercheat.host.sk/libav/maxbitrate-truth.html). I just summarised the meaning of maximum bitrate so it can be easily understood. It is commonly misunderstood, and then incorrect information is passed on. What bitrate viwer about the bitrate is 100% irrelevant in terms of a compliant stream. Maximum bitrate refers to the maximum bitrate the buffer is written to, not the maximum bitrate of the decoded stream.