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

[Ralph Metzler <rjkm@metzlerbros.de>]

Gregor Lawatscheck writes:
 > At 18:20 20/05/2003, you wrote:
 > >In my recording, bytes 8-10 of the sequence header are encoded as
 > >0f d2 23, which is bitrate '0000 1111 1101 0010 00'b = 16200!
 > >Same bitrate as Gregor encountered.
 > 
 > Nice one, looks like we've pin-pointed it. What happens if you run the file 
 > through analyze of mpegtools ( 
 > http://www.metzlerbros.org/dvb/dvb-mpegtools-0.2.5.tar.gz )? It could hang 
 > or segfault (as stremtype does with these files) after patching vbv_delay 
 > with PVAstrumento it should calculate the correct bitrates GOPs in the 
 > stream. Are these RTL recordings VBR?  So there's a bug in mpegtools as 
 > well which might have been reproduced by employing the same routines in the 
 > firmware which could also need fixing.


Where would that be?
The ES is not touched in mpegtools or in the firmware.


 > Over here the real / average bitrate of the VBR stream is something like 
 > 3676000 (9190 * 400) bps. As Wiljo explains in PVAstrumento's help file, 
 > broadcasters mostly set the bitrate in the seqeunce header to the maximum 
 > for the stream. In the case of BBC-2 for example I'm sure I've seen 
 > bitrates of up to 12 Mbit on single frames though (unless analyze showed 
 > the wrong values). Maybe they set  it to the highest bitrate that can occur 
 > between one sequence header and the next?
 > 
 > > > 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.
 > >
 > >I checked some other recordings which don't show that problem. There is
 > >a much higher value in the bitrate field: 15 Mbit seems to be a common
 > >value.
 > 
 > Very interesting - BBC-1 which has always been *the* stable channel on the 
 > mux with the new drivers/firmware uses exactly 15 Mbit as a value. It all 
 > makes sense - even why demuxing the stream in transfer mode seem to work 
 > really well in succession on some scenes but not at all on others.
 > 
 > >Then I modified pes_play() to patch the bitrate in the sequence header
 > >and the RTL recording plays flawless...
 > 
 > Oliver, could you please post this patch to the list? We both know this 
 > needs fixing in the firmware but I'm sure quite a few people would like a 
 > temporary fix to a problem that's been haunting them especially with DVB-T 
 > and av7110s to demux ever since the new firmware in early in 2002. After 
 > all it doesn't alter the recordings itself only the output to the av7110.


Again, there is no kind of ES level processing in the firmware. This is all
done by the video DSP microcode which did not change for quite a while 
(since the last RTSL release I got sometime back in 2001).

The real fix is to throw out OSD memory and give it back to the video
decoder which seems to need it for some streams.
I have files which play fine when I increase the video buffer back to
its old size. There are some workarounds which also work with the
smaller buffer but I am still looking for a better solution (if/when I
have the time).


Ralph


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