Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[vdr] [PATCH] (DVB-T) statmux fix vbr tagging for pic header
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.
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.
I've posted about this over on the linux-dvb list:
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
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.
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.
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á.
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
comments from testers appreciated.
and here are some references:
statmux / sync / PTS demux handling in new head?:
mpeg-2 header reference:
info about vbv delay:
To unsubscribe send a mail to email@example.com with "unsubscribe vdr" as subject.
Main Index |