[MPlayer-dev-eng] Another ATSC "a52: CRC check failed" problem

[Nico Sabbi]

Mark Haun wrote:

>Hello list,
>
>I've been experiencing persistent "a52: CRC check failed" errors with two of
>my local ATSC broadcasters (KTWB and KCPQ in Seattle, WB and FOX networks). 
>Upon launching mplayer as, e.g.,
>
>mplayer dvb://KCPQ
>
>the audio stutters for a couple of seconds, the video slows down to 1
>frame/sec trying to resync, and then it dies.  After hours of fruitless
>effort trying to find something wrong with my ALSA setup, I stumbled onto
>the following patch, posted last year:
>  
>

the problem is this: usually, when dealing with TS,  AC3 is carried in PES
packets in private-1 form in a substream (totally idiotic and useless, 
given the
nature of TS) beginning with a 0x8n identifier.
Certain broadcasters do the right thing and remove the substream id, so
after the pes headers there's only the raw AC3 payload.
Unfortunately there's no way to know for sure which format is being used,
so demux_ts.c probes the substream_id in the payload in order to remove the
4 extra bytes (because otherwise certain decoders and muxers could be 
confused)
but sometimes there's a 0x8n byte in the raw payload (in the second 
form) that leads
the demuxer to consider it a substream_id identifier, and consequently 
to drop
part of the audio packets.

If you upload somewhere (maybe mphq2?) a short sample with the whole TS,
indicating which pid contains the audio track you use, I will try to 
search particular
descriptors that may help me to identify which pes format is being used.

    Nico