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

Trent Piepho xyzzy at speakeasy.org
Sat Feb 21 11:55:35 CET 2009


On Fri, 20 Feb 2009, Nico Sabbi wrote:
> On Thursday 19 February 2009 23:21:49 Steven Brudenell wrote:
> > 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.
> >
>
> 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

Sometimes demodulators take a couple seconds to lock to the stream.  Before
that the error rate is a lot higher.  Since the demuxer is only going to
check the beginning of the data, it may be getting too much bad data to
recognize the stream as TS even though the stream would still be playable
after a few seconds.  A high bit rate stream will fill up the demuxer's
probe buffer much faster and thus get more bad data while the demodulator
is still locking.

If the input is DVB, then the probability of the stream being TS is nearly
100%.  Certainly the autodetection logic could take that into account.



More information about the MPlayer-dev-eng mailing list