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

[Oliver Endriss <o.endriss@gmx.de>]

Johannes Stezenbach wrote:
> Gregor Lawatscheck wrote:
> > 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.

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)

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.

Assuming that both firmware releases use the same RTSL binary: 
There must be a change in the code which triggers this bug.

Maybe the info above might help to locate the problem.

Oliver


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