[linux-dvb] vbv delay/buffer overflows on VBR statmux

[Gregor Lawatscheck <gpel@mpex.net>]

At 16:44 14/05/2003, I wrote:
>To exclude audio sync per se as a source for the lock ups I've demuxed 
a >testscreen with pvastrumento, looking at just the video, leaving all 
"fix" options >off:
>
>http://www.mpex.net/riovolt/bbc3-testscreen-broken.mpv.mpg  (2,5 MB)
>
>This locks up the current firmware / driver.
>
>Now the following is the demux of exactly the same filesize but this time 
with >pvastrumento tagging VBR headers and no other changes to the data 
(as >verified by hexcompare although I don't understand how exactly VBR 
headers >are set):
>
>http://www.mpex.net/riovolt/bbc3-testscreen-vbr_header.mpv.mpg (2,5 MB)
>
>This works fine with current firmware / driver as I've tried to point out 
in my >earlier posting. I'm using mplayer rc5 -vo mpegpes -ao mpegpes and 
CVS >(driver and firmware) to test this lockup.

>I believe this happens with the new firmware / drivers when a stream is 
VBR but >not tagged as one.

I seem to have some success by making vdr set the vbv-delay of I-FRAMEs to 
0xFFFF, similar to what PVAStrumento does when tagging streams as VBR. It 
now seems to demux perfectly.
Please see 
http://www.linuxtv.org/mailinglists/vdr/2003/05-2003/msg00703.html over on 
the vdr-list.

As Wiljo Heinen, author of PVAStrumento, points out in replying:

[quote]
13818-2 mentiones for instance:
"If low_delay is equal '1' and if the bitstream contains big pictures, the
vbv_delay values encoded in the picture_header() of big pictures may be
wrong if not equal to hexadecimal FFFF."

Maybe sth. like that happens, so setting vbv_delay to 0xFFFF will heal the
decoder. I don't know.The linux driver ppl. should have a look at this.
[/quote]


I googled a bit more and found
http://www.eee.metu.edu.tr/~alatan/PAPER/icip.00.pdf

which states:

[quote]
The MPEG-2 standard defines two VBV modes, namely,
Constant Bit-Rate (CBR) and Variable Bit-Rate (VBR)
modes [1]. The rules to determine the above listed tasks
differ in these two modes. Fig. 2 depicts both of these
models. As it is observed from this figure, CBR mode
should have a fixed predetermined rate during data
transfer, whereas VBR is assumed to achieve the transfer
with its maximum rate until it fills the buffer. As a
reference to the MPEG-2 video syntax and for a better
comprehension, Fig. 3 illustrates a typical bitstream.
[...]
In VBR VBV model, data always enters VBV at Rmax, if the
buffer is not full. When the buffer is full, no data enters
the buffer, i.e., R(n) = 0.
[/quote]

It would be great if the firmware wizards could comment/fix what it might 
be in the buffer code that keeps newer firmware from having problems with 
VBR. However possibly something could be introduced in the driver to tag 
the vbv_delay accordingly to the buffer to avoid overflows before passing 
it on. Any thoughts?

I'm not quite sure how to detect a stream being VBR a driverlevel other 
than looking at bitrate changing between headers - then again that's not 
quick enough when starting a demux? Can it even hurt to have the vbv_delay 
set too high at the beginning of a stream for CBR - I wouldn't have thought so?

- Gregor



--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.