[MPlayer-dev-eng] Proposed patch: ignore bad consistency counter check in demux_ts

[Nico Sabbi]

On Thursday 19 February 2009 23:21:49 Steven Brudenell wrote:
> This patch is to ignore the bad CC check in demux_ts, as it doesn't
> appear to be critical for stream playback and actually seems to
> hurt DVB applications. I would prefer to make this check optional
> somehow, but I can't figure out any way to make options to pass to
> demuxers. If someone can document this for me (or point me to an
> example where it's currently done), I'll change this to an option.
>
> For some time now I've had a problem where when playing
> high-bitrate streams over DVB (especially 1920x1080 ones), mplayer
> sometimes fails to start playing a stream. It would fill its stream
> cache, then exit with an "end of file" message.
>
> *Sometimes* it would work, and I could watch the stream normally.
> There never seems to be anything wrong with the stream in this case
> (not too many decoding errors, etc).
>
> Turning up verbosity revealed messages like "GOOD CC: 3, BAD CC:
> 29" shortly before exiting. It seems that demux_ts checks the
> "continuity counter" bit of mpeg streams before deciding that it is
> indeed a TS. Apparently these continuity counters don't come across
> well in high-bitrate DVB streams for some reason.
>
> I noticed that CCs aren't verified during stream playback (the code
> to do this seems commented out, so I guess they were at some
> point), so I guess this must not be that critical to stream
> playback.
>
> This problem persisted across several versions of mplayer and
> kernel, and even moving from Washington to Pennsylvania (so it
> can't possibly be a single misconfigured system on the broadcasting
> end).
>
> I decided to try removing this check, and it seems to work well. I
> can now start up 1920x1080 DVB streams without any trouble. The one
> bad effect is that for channels with very low signal, mplayer will
> start playback with very little data to work with, and will have
> some trouble. I think this is a fine tradeoff however.
>
> I don't really know the ramifications of this change to other
> applications. Can anyone fill me in?


that check is only necessary during the demux_open() phase, that is 
when a stream is analyzed to guess the format of the multiplex.
Disabling that check would make a lot of garbage appear like MPEG-TS, 
that is obviouly unacceptable. 

Your problem lies somewhere else: in your reception conditions.
Passing an option to the demuxer is as easy as adding the variable on 
top of the file and modifying cfg-common.h accordingly. Look at 
ts_probe as an example