vbv constraint vs undersize avoidance

[plugh]

It has taken some time and effort, but I've tracked down why some of my encodes continue to have problems after VBV constraints have been applied.

It is because the 2nd pass *encoding* phase, where scaled vs desired vs actual frame sizes are tracked and overflow / underflow adjustment occurs, does NOT factor in VBV constraints.

explanation:

During the 'theoretical' scaling phase of pass 2, the scaled 1st pass frame sizes are checked against the VBV constraints and any scenes that violate the constraints are scaled down. The bits freed up are then redistributed, scaling up other areas.

Under the right conditions during the 2nd pass encoding phase, an accumulation of unspent bits can occur for various reasons (the 'undersized file' situations). This is becuase the actual encoded frames sizes on average are less than the calculated scaled/desired sizes, producing a surplus of unused bitrate.

-->When such an encode gets to a VBV constrained (scaled down) scene, the rate control algorithm then 'spends' these accumulated bits scaling the scene back up, resulting in it AGAIN violating the VBV constraint.

In effect, the 2nd pass encoding phase gives higher priority to avoiding an undersized file than to insuring the stream does not violate the specified VBV constraints.

hmmm...

I'm wondering what to do about this as VBV constraints are of paramount importance to the encodes *I* am doing. Not only that, but this flaw means that under the stated conditions, xvid output is not conformant - all the Simple and Advanced Simple profiles specify vbv_size and vbv_maxrate, as well as the various standalone player profiles out there.

Only thing I can think of is to modify the RC mechanism (plugin_2pass2.c routine rc_2pass2_before ) to incorporate a check that the desired size it computes doesn't violate a running vbv compliance check. If it does, it needs to cap the target frame size to keep the stream in compliance - even if it means an undersized file!

Comments?

[plugh]

Well, I gave it a whirl...

Added a vbv check during the 2nd pass encoding phase, with logic to override the overflow-computed 'desired size' (before it was used to compute the new frame quant) if it would violate the vbv constraint, and WOW what a difference. Went from ~300 dropped frames in a 20K frame clip to - zero! I don't believe it was that simple!

Yes, the file output file is undersized relative to what I specified as target, but it actually PLAYS! The VBV constraint actually works now! Specifying to large of an output file doesn't undo the vbv scaling.

Hot Damn! Woo Hoo!

My implimentation isn't perfect I'm sure, but the output is a LOT closer to being "right" in this case than it was before.

Do any xvid devo's monitor this forum any more? Anyone else with vbv sensitive needs interested in the code? It's all of 26 lines, including comments. Oh, what the hey...

plugin_2pass2.c - a few lines before/after each mod included

double fq_error;

/* track vbv fill during encode for compliance */
float vbvfill;

int min_quant; /* internal minimal quant, prevents wrong quants from being used */

}
#endif
/* Initialize for vbv check during encoding */
rc->vbvfill = (float)rc->param.vbv_initial/8.f;

/* vbv_size==0 switches VBV check off */

*-----------------------------------------------------------------------*/

/* adapted from check_curve_for_vbv_compliancy routine below - PLEASE CLEAN ME UP */
if (rc->param.vbv_size > 0) {
const double fps = (double)data->fbase/(double)data->fincr;
const float vbv_size = (float)rc->param.vbv_size/8.f;
const float maxrate = (float)rc->param.vbv_maxrate;
const float framein = (int)(maxrate/fps+0.5)/8.f;

/* update vbv fill level */
rc->vbvfill += framein - dbytes;

/* this check is _NOT_ an "overflow"! only reading from disk stops then */
if (rc->vbvfill > vbv_size) rc->vbvfill = vbv_size;

/* but THIS would be an underflow. readjust vbvfill, cap framesize */
if (rc->vbvfill < 0) {
rc->vbvfill += dbytes - s->scaled_length;
DPRINTF(XVID_DEBUG_RC,
"[xvid rc] -- vbv violation - frame: %d adjusted vbvfill: %d target: %d cap: %d\n",
data->frame_num, (int)rc->vbvfill, (int)dbytes, s->scaled_length);
dbytes = s->scaled_length;
}
}

#ifdef PASS_SMALLER

[plugh]

I'm in the final testing stages of my revamped 2pass2 RC with the 4th iteration on my vbv compliance related fixes, and I have a small problem.

As it turns out, one of the issues with maintaining vbv compliance had to do with the process of generating quants for the scaled frames. As I mentioned in the other thread, I've incorporated some non-linear behaviour into that process that (at least for my test material) seems to improve it's accuracy.

For example - two HD xvid encodes, both with no I-frame boost/tax, no curve compression, the overflow mechanism DISABLED, and the 2nd pass output size set to equal the 1st pass size (debug output showed the file scale factor was 1.000001). The only up/down scaling of frames occurring was due to the vbv algorithm - this provided a range of frame scale factors of ~1.02 (make some bigger) to ~.45 (make some smaller). I/P/B min quant was 1 (no clipping).

Keeping in mind that the overflow (negative feedback) mechanism is disabled, this provides a test of the ability of the quant generation code to track an input curve. Results:

The v1.1.2 code generated output file was 6.30% oversized.
My revised code's generated output file was 1.75% oversized.
ie less than 2% error, with NO negative feedback applied

The problem: A while back, I observed a non-optimal quant / framesize 'pattern' in some encodes; my investigation led me to this http://forum.doom9.org/showthread.php?p=906753#post906753

Now I have less error in the quant generation, and at a file scale factor of 1.0, even 5/5/5 overflow settings are a bit too aggressive - the 15/25/25 that comes out of the ref'd code causes definite oscillation (back and forth overcorrection) when the overflow feedback mechanism is enabled. I.E. the settings that *were* used for file scale factors less than .6 are still a bit too strong at 1.0 with my revised code (and my test material).

I have neither the test material, the time, nor the inclination to do the test encodes necessary to re-tune the file scale factor shift points and overflow boost multipliers in that bit of code. I'm inclined to just disable it in the source/binary I plan on posting, so that whatever you enter via the gui/api is just used as-is.

Comments?

[plugh]

OK, for those of you interested, here it is...

Taking advantage of the xvid plugin system, this xvidvfw.dll incorporates my modified version of plugin_2pass2.c as an alternate 2nd pass choice from the main gui dialogue box.

Use this dll with your existing xvidcore.dll. If you select the normal second pass, you'll use the version resident in your xvidcore. If you select the alternate second pass, you'll use my modified version resident in this dll. Should make doing comparisons between the two versions very easy.

The xvid status window has the same enhancements as the version I posted in the other thread, so you can monitor vbv compliance of the encode as it proceeds.

There are also eight additional profiles in this build - the four that celtic_druid defined for mediatek based players, and four that I defined for my target platform of interest {trying to get these to actually work was what set me off on my bug hunt}.

As per my preceding post, 'smart overflow setting" is disabled in my code; if you want/need higher values, enter them yourself. (But the defaults of 5/5/5 work "ok").

Based on v1.1.2 sources; all sources included in the zip. My changes to 2pass2 include additional/modified debug prints, and several conditionally compiled changes (via #ifdef). To a certain extent you can mix and match the changes, or selectively enable them for experimentation. Disabling restores original functionality. See comments in the file for more info.

-edit- updated version below (http://forum.doom9.org/showthread.php?p=915512#post915512)

[henryho_hk]

Excellent! Is it possible if I can involve it through xvid_encraw? (sounds impossible w/o dedicated build)

[plugh]

I haven't used encraw, so I only know a little about it.

My code is just a modified version of the existing source file, so it is trivial to build an xvidcore.dll with it (it took extra work to put it in xvidvfw.dll). If encraw uses the standard xvidcore dll then it would pick up the changes, but the only way to switch back and forth would be to swap .dll files.

...

Ok, attached is v1.1.2 xvidcore.dll with my 2pass2 code.

Obviously, it does not make sense to use this with the vfw gui posted above. It won't hurt anything, but you'll just be switching between two copies of the same code.

BTW - I don't know if encraw gives you a way to set the xvid debug output mask, but this build has debug prints enabled. Set mask to 0x80 and use 'debugview' utility to monitor the messages. Besides other info, you'll get vbv statistics at the end similar to what my vfw gui shows you, to let you know if the output really was compliant.

[tolkien]

i dont think this worked cos i told xvid to give me an 88mb file and i only got 50mb

[foxyshadis]

And you read the sticky, and compared against vanilla 1.1.x or 1.2, which gave you the 88 you asked for, right?

[tolkien]

which one gives 88? im using the latest xvid and it didnt work

[plugh]

In case it isn't clear from the discussion, the modified version gives higher priority to maintaining vbv compliance than to avoiding an undersized file. It tries to permit frame growth on non-critical segments up to the 'vbv envelope', but if you were pushing things before you will likely get an undersized file with this version.

One other change present in this code I should mention - it is possible that the *initial* vbv scaling process can fail if there is no way to redistribute the bits from scaled down scenes (ie most or all the input curve needs to be scaled down). In this case, the original code just shrugged and went on with the encode, leaving you none the wiser. This version returns an error and quits.

[tolkien]

so how would i get 88mb

[DarkZell666]

By reading the sticky by jon.schaffer at the top of the forum ?
It says "Oversized/Undersized explanations" :)

/me becomes generous.
/say Tadam : http://forum.doom9.org/showthread.php?t=92046

Huhu, havefun reading ;)

[plugh]

oops

All the testing I've done of this 2pass2 mod, and something dumb and stupid almost completely unrelated comes along and bites me in the A** (something you C coders will understand - a missing equal sign in an if statement)

The previously posted xvidvfw.dll will always use the alternate 2nd pass code, even if you select the original.

Attached version corrects this.

Sorry :o

[tolkien]

darkzell ive read that faq and none of those options work cept setting the quantizer which can give me a larger file but still gives me nothing close to what i ask for

[foxyshadis]

You still haven't answered my question: Is this unequivocally related to this custom build of xvid? Does it work as you expect with the standard versions, ie, does it give you 88 mb when you use vanilla 1.1.2? If yes, it would help to post as much information about the source and your procedure - right now you're providing exactly nothing to help anyone help you. If not, you're posting in the wrong thread and this needs to be split.

[squid_80]

Excellent! Is it possible if I can involve it through xvid_encraw? (sounds impossible w/o dedicated build)
I think I could add this to encraw. It's just a plugin right? So I add the plugin code to encraw (similar to how it was added to xvidvfw), add a command line switch to choose between the regular 2pass function and this new one, and it should work with any existing xvidcore.dlls.
Are the previously posted code sections the only modifications?

[DarkZell666]

(something you C coders will understand - a missing equal sign in an if statement)lol, that's what happens when you code half drunk :p

[plugh]

I think I could add this to encraw. It's just a plugin right? So I add the plugin code to encraw (similar to how it was added to xvidvfw), add a command line switch to choose between the regular 2pass function and this new one, and it should work with any existing xvidcore.dlls.
Are the previously posted code sections the only modifications?

Yes to all questions, except perhaps the last one depending upon what you are referring to.

You want the "plugin_2pass2_alt.c" that is in the xvidvfw zip posted above. The mods I did to move this into xvidvfw.dll were:

Check the two #include lines to locate xvid.h and portab.h (which are part of core, but you probably already have them - if not download the 1.1.2 source kit from xvid.org).

You will also need a couple of defines - 'ARCH_IS_IA32' and 'ARCH_IS_32BIT' - I'm using MSVC6, so I just added them to settings, or I guess you could add them to the source before those two include lines.

If you want to enable the debug messages (do you support setting the mask?) you'll need '_DEBUG' defined, and you'll need to accomodate 'xvid_global' in your code - I just defined a local copy in the vfw code and initialized it with the same value being passed to core in the init call.

Check codec.c in the vfw zip above, and search for "//del" (no, it doesn't mean 'delete'); it was maybe 6 lines total related to 2pass2, including the 'if' I screwed up.

Oh, and if you DO enable the debug messages and are NOT using MSVC6, there are some "I64d" format specifiers in 2pass2 that will probably need to be changed back to "lld" - I had to change them to get 64bit ints output correctly...

[squid_80]

Done: http://members.optusnet.com.au/squid_80/xvid_encraw.zip
The debug stuff isn't enabled at this stage.
Use -altpass2 instead of -pass2 to use the new algorithm.
(This build also has Kopernikus's hvs mods added but it's not working too well for me, seems to get stuck on some frames. Try with -notrellis if this happens.)

[tolkien]

You still haven't answered my question: Is this unequivocally related to this custom build of xvid? Does it work as you expect with the standard versions, ie, does it give you 88 mb when you use vanilla 1.1.2? If yes, it would help to post as much information about the source and your procedure - right now you're providing exactly nothing to help anyone help you. If not, you're posting in the wrong thread and this needs to be split.

i get the problem in this xvid and the normal xvid yes

[henryho_hk]

Excellent! squid80!

BTW, why does it say "xvid [warn]: Can't find xvid_plugin_ssim, ssim calculations will be disabled"?

[squid_80]

There are some new options for calculating ssim (encoded frame vs. original), see xvid_encraw -help. But you need an up-to-date (cvs build) xvidcore.dll to use them.

[henryho_hk]

Using plugh's xvidcore.dll and squid's new xvid_encraw, a 2pass encode crashes at 2nd pass.

Source VOB: http://forum.doom9.org/showthread.php?p=913768#post913768

Script:

vf="railings.d2v"
mpeg2source(vf,cpu=4)
colormatrix(d2v=vf)
tomsmocomp(1,5,0)
DegrainMedian(mode=3)


Command lines:

"bin\xvid_encraw_20061212.exe" -zones 0,q,3,KO -packed -progress 100 -max_key_interval 300 -par 5 -vbvsize 3145728 -vbvmax 4854000 -vbvpeak 8000000 -quality 5 -vhqmode 1 -max_bframes 1 -bquant_ratio 162 -bquant_offset 0 -qtype 1 -qmatrix "matrix\Didees-SixOfNine.cqm" -nochromame -turbo -pass1 "tdc_1.stats" -type 2 -i "tdc_1.avs"
"bin\xvid_encraw_20061212.exe" -zones 0,w,1.0,KO -packed -progress 100 -max_key_interval 300 -par 5 -vbvsize 3145728 -vbvmax 4854000 -vbvpeak 8000000 -quality 6 -vhqmode 1 -max_bframes 1 -bquant_ratio 162 -bquant_offset 0 -qtype 1 -qmatrix "matrix\Didees-SixOfNine.cqm" -imin 3 -imax 4 -pmin 3 -pmax 5 -bmin 3 -bmax 5 -chigh 15 -clow 5 -bvhq -bitrate 1553 -altpass2 "tdc_1.stats" -type 2 -i "tdc_1.avs" -avi "tdc_1_MTK-58_br_1553.avi"


I will test xvidvfw tonight.

[plugh]

You don't need new xvidcore, since he built the mod into encraw.

Either 'old' encraw with 'new' xvidcore (use pass2 switch)
or 'new' encraw with 'old' xvidcore (use altpass2 switch)

By the way, if I am reading the command line right (as I said, I haven't used encraw), you may be tying the vbv code's hands with those quant ranges.

-imin 3 -imax 4 -pmin 3 -pmax 5 -bmin 3 -bmax 5

If it needs to scale down frames (increase quant) for vbv compliance, your max's may prevent it from doing so, giving you a non-compliant stream.

[henryho_hk]

If it needs to scale down frames (increase quant) for vbv compliance, your max's may prevent it from doing so, giving you a non-compliant stream.

These quant limits are from Teegedeck's presets (http://forum.doom9.org/showthread.php?t=107897). His idea is to limit the quant range (thus predictable quality) and to control the output size by using different custom matrices (known compressibility and characteristics). I wish to adopt the best of both world to create quality xvid with standalone compatibility. The first try is to simply add the VBV parameters and 1-B-frame limit (in compressibility test & two encoding passes). Yet, since your new VBV codes would abort the encoding process when the bitrate "overflows", I may try different approaches or even to relax the quant limits (sorry, Teegedeck).

[plugh]

Interesting... I was under the impression that most standalones don't support custom matrices; just curious, what's your target chipset?

BTW, since vbv code is in second pass, vbv switches in first pass encraw command line should have no effect.

[henryho_hk]

Interesting... I was under the impression that most standalones don't support custom matrices;

I am encoding them for my friends and they are not complaining. I think the newer chipsets do support custom matrices.

vbv switches in first pass encraw command line should have no effect.

Thank you very much. I will modify my batch script. Unfortunately, my main computer refused to work tonight. I am afraid I can't resume my testings before next week.

[plugh]

henryho, I noticed the 'chigh' and 'clow' parameters in your command line, and it got me to thinking...

The way the 2pass2 code is structured, curve compression is applied AFTER vbv scaling is done. Curve compression, however, can't do anything but _help_ a non-compliant curve - it always takes bits away from higher bitrate frames.

On that basis, seems to me that curve compression should be applied BEFORE vbv scaling; it might even bring non-compliant scenes into compliance before the vbv algorithm is even applied...

Comments anyone?

PS - A similar situation exists with I-frame boost and it's associated 'tax' (which reduces the size of P&B frames to compensate for the boost), but as it's a bit more complicated I'm still pondering that one...

[dragongodz]

On that basis, seems to me that curve compression should be applied BEFORE vbv scaling; it might even bring non-compliant scenes into compliance before the vbv algorithm is even applied...
i agree. that would seem a better way to me.

[708145]

Done: http://members.optusnet.com.au/squid_80/xvid_encraw.zip
The debug stuff isn't enabled at this stage.
Use -altpass2 instead of -pass2 to use the new algorithm.
(This build also has Kopernikus's hvs mods added but it's not working too well for me, seems to get stuck on some frames. Try with -notrellis if this happens.)

Any chance to get the complete source of that build? I plan to mess with alternative 2pass modes for high fps encodes (>50fps) over xmas and it would be a good start.

bis besser,
T0B1A5

[squid_80]

http://members.optusnet.com.au/squid_80/sources/xvid_encraw_src.zip

[708145]

http://members.optusnet.com.au/squid_80/sources/xvid_encraw_src.zip

thanks

[henryho_hk]

On that basis, seems to me that curve compression should be applied BEFORE vbv scaling

Agree. It makes more sense to me.

BTW, there is no more crashes with squid_80's 20061213 build. Excellent!

[ImmortAlex]

I'm always getting slightly undersized files with alternative 2nd pass using -altpass2 in xvid_encraw. About 30-70kbps in 1000-2000kbps encodings.

[plugh]

As stated above, the altpass2 code gives higher priority to vbv compliance than undersize avoidance. I would need you to capture debug prints in order to diagnose. However the squid_80 encraw build with altpass2 does not have them enabled.

Can you reproduce with my xvidvfw build (which has the prints enabled) and VDM?

[ImmortAlex]

I hope I'll have some free time next week to test it.
Looks like after dropping bits for strict vbv compliance encoder doesn't use them at all in any other place. I'm using vbv options for MTK-based standalone, setting up about 4000 kbps limit, but encoding not more than at 2000 kbps average. Encoder reach vbv limit not so often, so I got not so much undersize.
Too bad that undersize is unpredictable, so I can't compensate it setting little bit higher bitrate.

[plugh]

The other factor is the overflow control parameters.

I just scanned the encraw source and it uses defaults of 5/5/5 for these params (same as xvidvfw). Since the new code isn't as aggressive (see 3rd and 4th posts in this thread) you may want to bump them up a few notches. Try entering 10/10/10 or 10/15/10 and see if that helps.

[ImmortAlex]

Or because of curve compression (-chigh -clow in xvid_encraw)... I'm using it according to presets discussed in this forum.

[plugh]

CC shouldn't cause undersize, as bits are redistributed. And re: your comment above, the vbv algorithm redistributes bits as well. Undersize can only be caused by three things. (1) min quant constraint prevents growing frames, (2) in my version, vbv constraint can prevent growing frames, (3) and overflow control params set to 'weak' to grow them enough.

All of these can prevent accumulated unused bitrate from being applied to sequences of frames. If the sequences are sufficiently long, there may not be sufficient 'play' to use up all the excess.

It used to be that the 'critical' sections the vbv algo scaled down were prime candidates to get scaled up, simply because they *could* be scaled up before hitting the min quant limit.

FYI: There is actually another case I've ran into - end credits in a weight zone. Say you apply a weight of .5 to end credits, so they are scaled down in size. And due to min quants, the encode is running along undersized. When the encode gets to the end credits with multi-megabytes of unspent bits, it scales them back up in order to consume some; another case of frames previously scaled down being scaled back up due to undersize avoidance code...

However, first thing to check is the oveflow params. If you read the post I referred to (and the one it links to), you'll see that I disabled some code that attempted to automagically increase these depending upon the amount the second pass was being shrunk relative to the first pass (ie half the size means scaler=.5). You'll also see why I did so in those posts. It is entirely possible you need higher values than the 5/5/5 default for your particular encode.

[henryho_hk]

Another possible reason for the 2000kbps encodes may be the matrix. One of the major idea of Teegedeck's presets is to choose a matrix and use a controlled range of quantizers. That's why a compressibility test is suggested for choosing the right preset at a target overall bitrate. Using a smoothing matrix on "easy" sources will definitely produce undersized encodes. On the other hand, with grainy/noisy scenes, it is very easily to produce a 8000kbps encode under MTK vbv constraints.

[Vitecs]

plugh - thanks a lot for this mod. My encodes becomes more and more "playable" at my LG.

Don't you think current XVid developers should be aware of buggy VBV check? I understand the size is important issue, but user selects preset "Home" for only one special reason. Moreover, seeing "VBV - used in Two-Pass mode" filled vith values and greyed out in"XviD Configuration" screen I expect encoder will comply with it.
My point here is that people pays a little attention to VBV in comparision to b-frames, QPELs etc for SAP compatibility. Me as a typical example. Having a little knowledge about subject I spent hours to "encode->burn->go.to.living.room->play->check" loop.
Now I know the reason:thanks:

[plugh]

You're welcome. And I tend to agree with you - the vbv constraints exist for a reason, and violating them just to fill some arbitrary media size seems questionable.

I'm busy with some other projects at the moment, but still intend to rework the curve compression & I-frame boost/tax code to better 'mate' with the VBV stuff (as discussed above). And I've had a couple ideas about recalibrating the 'smart overflow setting' stuff disabled in my current release.

So feedback (both problems and success stories) from users is greatly appreciated.

[Selur]

Which builds do support the "alt2pass"-option ?
Asking concerning a feature request for MeGui to support alt2pass. :) (see: http://sourceforge.net/tracker/index.php?func=detail&aid=1773456&group_id=156112&atid=798479)

Cu Selur

[Sharktooth]

i found the answer: http://forum.doom9.org/showthread.php?p=916998#post916998
so i guess it is included in the xvid_encraw already "bundled" with megui.
in that case it would be easy to implement. just add a checkbox or even directly replace pass2 with altpass2...

[Selur]

Nice :)

[Sharktooth]

ok, i think altpass2 needs also the -vbv*** switches too, does it?

[plugh]

It doesn't *need* them, but as vbv compliance was the main focus of the changes you'll probably want them.

However, there are also secondary changes that are independant of the vbv stuff that should actually give better quant distributions (at least over the quant ranges I tested).

And be aware that the 'overflow' settings are handled differantly. What you specify (including zeroes, which disables it) is *exactly* what is used - the conditionalized bit of code in the original pass2 that internally adjusted them ("smart overflow setting") has been disabled.

Both of the above areas were done as part of the vbv work (as they impact the stream of frame sizes) but IMO are improvements unto themselves, whether a vbv constraint is being applied or not.

Comments/feedback welcomed...

[Sharktooth]

thanks for the info. so, most of the megui Xvid profiles are using 5/5/5 or 0/5/5 for the overflow settings.
i guess those values should be adjusted if i modify megui to use altpass2...

[plugh]

The 0/5/5 case - probably, as '0' meant 'default (=10)' before and means 'turn off' now.

The 5/5/5 case - perhaps, as that 'strength' may be ok, or you might want to bump it up a bit.

(Note: 0/5/5 is stronger than 5/5/5 in original pass2 code)

FWIW, my testing of the quant related changes led me to conclude that less strength is needed now. (ref here (http://forum.doom9.org/showthread.php?p=914461#post914461)) And the combination of changes produce quant streams with less gyration (smaller standard deviation) - at least with MY test material...

I've posted about "smart overflow setting" a couple times; here (http://forum.doom9.org/showthread.php?p=906753#post906753) is one of them. For high quality encodes that bit of code would turn vfwgui defaults of 5/5/5 into 15/25/25 and the old embedded defaults of 10/10/10 into 30/50/50 - WAY to much negative feedback!

BTW, keep in mind that my comments are wrt the pass2 code, not the user interface(s) supplying values to it. For example the vfwgui defaults were not the same as the old embedded defaults (don't know about encraw's defaults).

[squid_80]

I made encraw use the same defaults as vfw wherever possible.