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

[Johannes Stezenbach <js@convergence.de>]

Gregor Lawatscheck wrote:
> 
> [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]

IMHO low_delay is not normally used/supported for TV, as it implies
that there are no B-frames pesent. It simply means "I don't care about
synchronization, display incoming data asap."
VBV delay is an old method of synchronization, if possible one will
want to synchronize to the PTS.

Here's another quote from ISO/IEC 13818-2:
"D.9.11 Bit_rate and vbv_delay
  MPEG-1  Bit_rate and vbv_delay are set
    to 3FFFF and FFFF (hex) respectively to indicate variable bitrate. Other
    values are for constant bitrate.
  MPEG-2  The semantics for bit_rate are changed. In variable bitrate
    operation, vbv_delay may be set to FFFF (hex), but a different value
    does not necessarily mean that the bitrate is constant. Constant
    bitrate operation is simply a special case of variable bitrate
    operation. There is no way to tell that a bitstream is constant
    bitrate without examining all of the vbv_delay values and making
    complicated computations.
"

> 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?

The av7110 firmware has fixed size buffers allocated during
initialization. I don't know if the RTSL (supplied binary only by TI)
uses the vbv_delay internally, but I don't think so. Synchronization
is always done to the PTS/STC, i.e. incoming data is decoded as soon as
possible and is displayed when its presentation time stamp is due. This
should work with VBR and CBR.

Johannes


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