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

[Gregor Lawatscheck <gpel@mpex.net>]

At 13:22 20/05/2003, you wrote:
> Some more infos:
> Probably Gregor's problem is the same as the problem we had with RTL
> recordings last year ('RTL bug').
>
> Until now Gregor found two workarounds:
> - patch vbf_delay=0xffff in the picture header (0x00000100)
> *or*
> - modify bit_rate field in the sequence header (0x000001b3)
Thanks for reporting this Oliver, I was a bit too busy after I had made the 
second discovery -- most of the discussion on this went on over on the vdr 
list but it clearly needs to be discussed on here.

Setting the vbv_delay to 0xffff was a workaround which works for most of 
the recordings, but it didn't seem to be the root cause. In fact some, if 
few, recordings still managed to lock up the av7110 so I started to rule 
this out as a solution.

More importantly it seems something is going wrong with the way bitrate 
information is read and processed from the sequence header. Most of the 
recodings locking up the av7110 here have a bitrate of 6480000 bps. 
Something to bear in mind: The bitrate expressed in the normal sequence 
header is in units of 400 bits/second! So for 6480000 bps a figure of 16200 
would be encoded in the 18 bits of the sequence header: 
http://www.mpucoder.com/DVD/mpeghdrs.html#seq

From what I can make out the bitrate field in the normal sequence header 
suffices to describe bitrates of up to a 100 Mbit - only if it's greater 
the field in the extension header (01B5) is used?

> I have an old RTL recording which cannot be replayed with the current
> firmware. But it plays fine with the 0.9.4 firmware + current driver.
> After patching the data stream as indicated above the recording plays
> flawless with the current firmware.
Yes, we're guessing something might go wrong with the bitshifting or 
calculation used to determine an internal buffersize for the bitrate which 
then under certain conditions overflows. We'd appreciate if this could be 
checked in the firmware to resolve this deadlock.

When the deadlock occurs with a specially crafted bitrate the following 
happens: Around 224 k of data is sent as lots of 2048 sized packets within 
the same picture header.  When the lock up occurs around 105 of these ~2048 
byte packets are sent without any new frame being detected eventhough there 
clearly should be. The stream itself indicates 224 k as vbv buffer size, so 
really any single picture wouldn't be larger than that anyway.

With a vbv delay at 0xfff this seems to be avoided most of the time. With a 
smaller vbv delay it doesn't seem to go to the next pictue header / group 
of picture, thinks it's still on the same picture (which it assumes is 
longer than 105 x 2048 byte packets) and locks up. It's usually right at 
the end of a group of pictues (GOP) only few bytes before the next sequence 
header.


- Gregor 


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