Video Buffer Verifier example

[plugh]

I just completed a series of encodes to study the effect of differant vbv values. In the process of reviewing the results, I came across a particular frame sequence that was so beautifully illustrative I just HAD to share the results.

This is an HD encode, 1280x544
B frame opts were 2/1.62/0 (thanks Didée)
min p and q quants = 2 (thanks again, Didée)
2nd pass target size almost the same as 1st pass
(ie very little over/under flow adjustment)
All other 2nd pass parameters at default

Only variation in 2nd pass encodes was vbv values:
size=576KB, maxrate=~16.2Mbps, peakrate=0
size=512KB, maxrate=~14.5Mbps, peakrate=0
size=448KB, maxrate=~12.9Mbps, peakrate=0

They say a picture is worth a thousand words, so...
first pass, and each of the three vbv cases attached.

[Prettz]

Very illustrative. But what program is this you used here? It looks useful.

Also, what do the different colors stand for?

[CruNcher]

plugh yeah it's a nice example and test for ASP HD Standalone (SOC's) :)

[BigDid]

Very illustrative. But what program is this you used here? It looks useful.

Also, what do the different colors stand for?
Hi,

It looks like DRFAnalyser; more info here:
http://www.geocities.com/analyzerdrf/

Did

[plugh]

Attached is an enhanced version of xvidvfw.dll
All modified sources are included in the zip.

Derived from 1.1.2 sources, it adds a VBV compliance check on the encoder output stream with various stats displayed on the "Xvid status" window. (See attached screenshot). The simple algorithm used is borrowed from xvidcore.

Just substitute this dll for your existing one. Use it to verify 2nd pass is compliant, get a sense of how far off your 1st pass is, etc... Y'all might find what it reveals interesting.

Enjoy

[shon3i]

upload this to mytempdir.com.

[plugh]

I assume one of the mods will eventually 'approve' the attachments,
but as requested http://www.mytempdir.com/1090838
good for 21 days...

[Teegedeck]

I'm sorry; I like to check executables for viruses before approving them but ATM I'm almost exclusively running Linux w/o an antivirus software on it (hot phase of openSUSE 10.2 testing, I want them to fix those bugs before it goes final on Dec. 7th.!). But I promise to reboot in an hour or so and then I will check and approve the attachment.

BTW, mods don't get a notifier when there are attachments, so it might happen that one gets overlooked. If your attachments haven't been approved after 3 days please send a PM and ask about the reason. Thanks!

Of course using external hosting is always a good idea...

[buzzqw]

@Teegedeck

use www.virustotal.com is a free and very valuable service for file scanning

BHH

[Teegedeck]

Interesting! Thanks for the link, buzzqw.

Anyway, attachments checked and validated now.

[plugh]

BTW, mods don't get a notifier when there are attachments, so it might happen that one gets overlooked. If your attachments haven't been approved after 3 days please send a PM and ask about the reason. Thanks!

No problem, I figured it might take a little while to get approved. In the future I'll contact a mod if one seems to have been overlooked.

Nice thing about posting small things like this here is they don't evaporate in a few weeks...

[dukey]

does the video buffer verifier only work in 2 pass mode ?
I encode a lot of stuff in 1 pass target quantizer mode (because i am not too fussed about what size it comes out).

Be nice to set the profile to like HI DEF and not worrying about whether its gonna cause a melt down on hardware players if the bitrate gets too high.

[plugh]

The xvidgui enhancement will report on stream compliance, regardless of encoder mode.

The encoder attempts to vbv constrain during the second pass only.

[dukey]

is it not possible to make it work for 1 pass mode ?
I think the divx encoder does this.

[plugh]

You could try a target bitrate 1 pass (specify target = vbv max).

The vbv constraint algorithm xvid uses depends upon the first pass size data. In effect it examines the 1st pass stream frame sizes, identifies the frame sequences that violate the constraint, then scales those segments down so they are compliant. The set of scaled sizes are then used during encoding to compute the scaled target quant for each frame.

Look at the examples I posted at the beginning and you can see this. First pass vs various second passes - you'll see the quants increasing and the frame size "density" decreasing with more restrictive constraints.

[dukey]

yeah i understand how your method works
a 1 pass target bitrate encode is a really really horrible way of encoding. As soon as you hit a scene of high bitrate you end up with an ugly mess :p Where as setting the quantizer you want to work with you get a constant quality i guess.

The only way to make your method work .. with a 1 pass target quantizer encode would be.

To do a first pass on the video.
Setup the 2nd pass, but setup all the minimum quantizer values to the quantizer value i want to encode with. Set a very large target file size, so large that it will always use the minimum quantizer value, unless of course it violates the video buffer. That seems a bit of a pain in the ass.
The divx encoder does does enforce the max bitrate limits on a 1 pass target quantizer encode. But it doesn't seem to use b frames for a 1 pass encode. Anyone ? ;p

[plugh]

First off it isn't "my" method - I'm just stating what is in the code.

Unfortunately, your suggested two pass approach won't work; see http://forum.doom9.org/showthread.php?t=118419

It is *that* problem which led me to dig into the xvid code to understand what is going on, and I've been trying to come up with a fix. The code I posted in that topic was my first iteration; I'm now on my third, and recently had a 'eureka!' moment that will lead to my fourth attempt. (In the process I've also developed a few other beneficial tweaks.)

It is also the reason I created the enhanced xvidvfw I posted above, both as a tool for my personal use and so that other people might 'discover' the problem as well.

[dukey]

http://img234.imageshack.us/img234/3861/divxjy4.png

heres a movie i encoded with divx (quant 2), it was a 1 pass target quantizer encode. The video has a huge amount of motion in parts and divx seems to throttle the bitrate accordingly to stop buffer overruns. Would be great if xvid would do this too :p rather than just attempting to do it on a 2 pass encode.

heres the page with the detailed specs on the mpeg4 profiles
http://www.m4if.org/resources/profiles/index.html
dunno if they are any use :) So apparantly max bitrate for level 5 is 4.8mbit, interesting :)

[Sharktooth]

i dont think constant quant is limited by VBV... just because there's no RC in a constant quant encoding mode... :p

[Teegedeck]

Indeed.

[dukey]

'just because there's no RC in a constant quant encoding mode'

what does that mean ? It shouldn't matter if you do a 1 or 2 pass or even 5 pass encode. It shouldn't violate the VBV? It all gets decoded the same anyway ?

[Teegedeck]

Hm, let me try: 'Bitrate' is a function of framesize and quantization of successive frames. Each frame is compressed using a quantizer that chiefly determines that frame's size by multiplying the DCT frequencies of the quantization matrix in MPEG quantizers. Quantizers have even numbers. That means with a constant quantizer you have no control over the framesize whatsoever. Frames that are originally very small receive the same level of compression as frames that contain a lot of information. Sudden bitrate spikes are absolutely probable as well as continuously high bitrates.

In order to control bitrate (like for VBV) you must be able to assign quantizers depending upon the original framesize (and depending on the framesize of adjacent frames, in the case of VBV). That's why you need two-pass for VBV.

[Manao]

You don't need two passes to respect a VBV buffer. x264 doesn't need two passes, neither does DivX nor any other encoder I'm aware of.

You can apply a VBV constraint to a one pass constant quantizer encoding. Of course, the quantizer won't be constant, but the result is something that can be wanted : "constant quality" except when the bitrate would be too high for the result to be decoded.

[Teegedeck]

You can apply a VBV constraint to a one pass constant quantizer encoding. Of course, the quantizer won't be constant, but the result is something that can be wanted : "constant quality" except when the bitrate would be too high for the result to be decoded.'Constant quality encode' is a mode which XviD doesn't have, and that's all there is to it.

[Manao]

The quotes were there for a purpose. Constant quantizer in Xvid is the first pass mode that is closest to constant quality.

[dukey]

You don't need two passes to respect a VBV buffer. x264 doesn't need two passes, neither does DivX nor any other encoder I'm aware of.

You can apply a VBV constraint to a one pass constant quantizer encoding. Of course, the quantizer won't be constant, but the result is something that can be wanted : "constant quality" except when the bitrate would be too high for the result to be decoded.

my thoughts exactly
What is the point in setting a profile mode if the encoder will then violate the max bitrate for that profile? I know profile settings are quite sloppy as the home theatre mode sets a default value of 2 consequitive B frames when the divx home theatre profile quite specifically says max of 1.

In order to control bitrate (like for VBV) you must be able to assign quantizers depending upon the original framesize (and depending on the framesize of adjacent frames, in the case of VBV). That's why you need two-pass for VBV.


How does divx do it then ? Look back earlier in this thread and theres a pic of it doing it quite perfectly in 1 pass mode.

[plugh]

How does divx do it then ? Look back earlier in this thread and theres a pic of it doing it quite perfectly in 1 pass mode.
I'd like to see that algorithm as well.

I mean, here I am, I've just been handed the 'next' frame to encode. I look at it with my crystal ball predictor, and conclude "yeah verily, I better encode this at quant 4 else it will be to big and will violate my vbv constraint"

But wait, I look at my crystal ball again, and see that the *next* frame (_after_ the one I've just been handed and haven't encoded yet) is actually going to encode as a small frame, and thus I can let this one encode at quant three since the _stream_ (this one followed by the next, smaller, one) will remain vbv compliant.

Yeah, I'd like to see that algorithm...

Note: I'm not saying it can't be done - I just don't see how it could be done with any accuracy.

[dragongodz]

I mean, here I am, I've just been handed the 'next' frame to encode. I look at it with my crystal ball predictor, and conclude "yeah verily, I better encode this at quant 4 else it will be to big and will violate my vbv constraint"
basically correct. however you do not need a crystal ball. what you need to do is keep a tally of all the last frame sizes for the last second minus 1 frame. once you do an initial encode of the current frame, before writing it, you add that to the tally and see if it breachs VBV. if it does then recode current frame down/smaller and check again. once VBV compliant or unable to reduce more etc write the resulting frame. proceed to next frame and repeat.

[Sharktooth]

You can predict the framesize with a certain precision...but still enforcing VBV on a constant quant encode will make it a NON-constant quant encode... unless you have high quants and high buffers.

[dragongodz]

still enforcing VBV on a constant quant encode will make it a NON-constant quant encode
i agree. however the statement earlier
That's why you need two-pass for VBV
is not correct.

a 1 pass vbr(target bitrate) with VBV constraints is possible to do.

[plugh]

basically correct. however you do not need a crystal ball. what you need to do is keep a tally of all the last frame sizes for the last second minus 1 frame. once you do an initial encode of the current frame, before writing it, you add that to the tally and see if it breachs VBV. if it does then recode current frame down/smaller and check again. once VBV compliant or unable to reduce more etc write the resulting frame. proceed to next frame and repeat.

So, maybe encode 'current' frame(s) twice, and ignore the potentially beneficial effect of future frames on the constraint wrt the current frame. ie, you can encode the current frame larger, lowering current buffer level, if you know that next frame(s) wil be below maxrate and thus bring level back up.

I can see your approach working, subject to the reencode requirement and accepting a possibly non-optimal frame size. Seems as though full 2 pass would be needed for optimal results though, as then you have 'future' information available.

Algorithm in xvid goes through all possible (I think it is N^2/2 ?) buffer fill sequences in each scene to find minimum scale factor. Just an observation...

Anyway, I'm going to get back to trying to fix 2pass2 RC so it doesn't destroy the vbv scaling it did at an earlier stage. Now have a frame size capping approach based upon the scale factors determined during earlier vbv analysis that should still allow the overflow mechanism some room to do its thing.

Have also incorporated non-linearity into two steps in the frame size to quant generation code that seem to produce measurably better results (at least for the scaling ratios and quant ranges of my test material) than the existing code.

If anyone's interested...

[dragongodz]

So, maybe encode 'current' frame(s) twice, and ignore the potentially beneficial effect of future frames on the constraint wrt the current frame. ie, you can encode the current frame larger, lowering current buffer level, if you know that next frame(s) wil be below maxrate and thus bring level back up.
yes the example i gave is just the plainest/simplest example. also of course frames would only need to be encoded twice when they exceed the VBV. you could reduce chances of that by doing something like basing current frames initial estimate on previous frame of same type. not optimal ,especially with a scene change between, but a cheap starting point so a 1 pass encode should still be much faster than 2 pass encoding.
something like a 2 frame overlapping method should give better results but of course is more complex and i didnt think needed to be gone in to here to get my point across.

I can see your approach working, subject to the reencode requirement and accepting a possibly non-optimal frame size. Seems as though full 2 pass would be needed for optimal results though, as then you have 'future' information available.
i agree, 2 pass is better for optimal results. however this is more about the fact VBV restriction can be adhered to with 1 pass aswell. there are times when people may not want or need the best possible but just want a fast encode that uses the VBV restrictions.

If anyone's interested..
yes some of us are interested. so any work you do is appreciated. :)

[henryho_hk]

Yeap, plugh, I am still enjoying your posts at:

http://forum.doom9.org/showthread.php?t=118419