schizo: "even dropping frames"

[draggoon01]

am i the only one who cringed when reading this:

"First, it must be sure not to exceed the specified maximum bitrate. It will do whatever it takes to prevent this, even dropping frames in the most extreme cases."

http://www.divx.com/divx/windows/beta/

[Sephiros]

Hi

No you're not! It better be customizable or only in very extreme cases and not drop like 10 frames in a row....

I don't know if it's already doing this in 5.0.3 if it's the ase then ok, it's not too dramatic (never noticed).

but if it's likely to drop 1 frames every 100, we got a serious problem.....

[timeToy]

as seem here:
http://forums.divx.com/viewtopic.php?topic=47624&forum=23

We must take extra care not to overflow or underflow the decoder buffer, this is not a problem with PC based decoder where the available memory is not limited, but for a hardware based decoder, this is critical. Failure to do so will result in freezing and frame dropping in hardware based decoder. So the Rate Control algorithm introduced in 5.0.3 makes sure this is not happening. If some extreme cases it can, in the end, if there is no other possibilities drop a frame, but this is an extremely rare event.
In order to make sure there is not dropped frame in your encode, create an empty file called FrameLevelControl.txt an the root of the C drive, when the encode is finish, check this file, at the end of it you’ll find:

Quantizer distribution:
Q=1 0
Q=2 1
Q=3 354
Q=4 3192
Q=5 42394
Q=6 78357
Q=7 19430
Q=8 198
Q=9 0
Q=10 0
Q=11 0
Q=12 0
Q=13 0
Q=14 0
Q=15 0
Q=16 0
Q=17 0
Q=18 0
Q=19 0
Q=20 0
Q=21 0
Q=22 0
Q=23 0
Q=24 0
Q=25 0
Q=26 0
Q=27 0
Q=28 0
Q=29 0
Q=30 0
Q=31 0
Q=32 0 ----> dropped frames

The number of Q=32 frames are the dropped frames.

Again, this extremely rare and this is not happening for normal encode.