[vdr] [PATCH] (DVB-T) statmux fix vbr tagging for pic header

[Gregor Lawatscheck <gpel@mpex.net>]

At 07:41 14/05/2003, I wrote:
> Just to say - it cristallized that this "blank screen" bug is down to 
> statistical multiplexing and corresponding headers in the PES stream.
> I've posted about this over on the linux-dvb list:
> http://www.linuxtv.org/mailinglists/linux-dvb/2003/05-2003/msg00191.html
After a lot of talking and speculation and testing out I've come up with an 
experimental, dirty patch for vdr-1.1.31 to work around problems with 
either the firmware, the drivers or the way some mux encoders send the 
headers for variable bitrate streams.

It's intended for people who get black screens on switching to a channel  / 
recording a channel in transfer mode. This applies mostly to DVB-T in the 
UK with the BBC mux . It possibly fixes problems with recordings on full 
featured DVB-T cards - would be interesting if people could test this. It 
should pretty much apply against at least the last 10 developer versions.

As I said the patch is dirty - it shouldn't break anything but it could be 
done a lot nicer. Namely to only actually modify the I-Frame picture header 
on a VBR channel (or when set in channels.conf) rather than on any channel. 
Furthermore integration with existing code could probably be neater. My 
reasoning is though, it can't hurt to have this out to the public to get 
some feedback and to help other DVB-T users getting rid of the annoying 
blank screen bug that sometimes hangs the decoder so bad it introduces 
delays or needs drivers reloading.

Basically I looked at what pvastrumento does to set the so called "VBR 
headers" in the picture header which I noticed fixed the new drivers / 
firmware from stopping the replay after a second. In fact to do this 
pvastrumento sets the so called "vbv delay" right up to the maximum. It 
thus, if I understand correctly, defines the longest time possible for the 
decoder to keep the files in the buffer before reassembling them.

I should have looked at the pvastrumento help file earlier. It seems to 
back up my results. Thanks Wiljo Heinen for a great program and a decent 
helpfile!):

[quote]
For convenience (and cheaper equipment... probably) most TV stations flag 
their video stream as being a fixed bitrate stream. The nominal bitrate, 
that is the bitrate contained in the video headers, is set to a value that 
is higher than the highest bitrate they will transfer.
[/quote]

Unfortunately that doesn't appear the case with the BBC mux. Nominal 
bitrate in the sequence header is set to 6.2 Mbit, but it does go up to 12 
or more Mbit in transmission.

[quote]
Though in reality their transmission is a variable bitrate the digital 
receivers have no problem to cope with this situation: they simply set 
their buffers so that the nominal bitrate can be processed -- et voilá.
[/quote]

OK this might be where the root of the problem lies. The buffers either in 
the firmware, the drivers or both seem to be too small for dealing with the 
stream. Setting the vbv delay higher seems to increase them or change the 
handling. This might possibly also fix future problems with RTL (if this 
happened to be similar) and other statmuxed channels too.

Here's the patch
http://www.mpex.net/riovolt/vdr-statmux-vbr_vbv_delay.patch
comments from testers appreciated.

and here are some references:

statmux / sync / PTS demux handling in new head?:
http://www.linuxtv.org/mailinglists/linux-dvb/2003/05-2003/msg00191.html
and http://www.linuxtv.org/mailinglists/linux-dvb/2003/05-2003/msg00197.html

mpeg-2 header reference:
http://members.aol.com/mpucoder/DVD/mpeghdrs.html

info about vbv delay:
http://www.broadcastpapers.com/sigdis/TandbergPortDigitalLinksMobile04.htm
and http://www.nhk.or.jp/strl/publica/bt/en/le0011.pdf

- Gregor 


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