At 18:20 20/05/2003, you wrote:
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.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.
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.> 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.
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.Then I modified pes_play() to patch the bitrate in the sequence header and the RTL recording plays flawless...