[MPlayer-dev-eng] Re: MPlayer-dev-eng Digest, Vol 38, Issue 67

Trent Piepho xyzzy at speakeasy.org
Mon Feb 20 01:04:59 CET 2006


On Sun, 19 Feb 2006 mplayer-dev-eng-request at mplayerhq.hu wrote:
> From: Nico Sabbi <nicola_sabbi at fastwebnet.it>
> Subject: Re: [MPlayer-dev-eng] Another ATSC "a52: CRC check failed"
> 	problem
> 
> Mark Haun wrote:
> >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.,
> >
> 
> 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.
> 
> 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.

I get these same two channels, have have the same problems.

I've made available the following files which may help:

http://www.speakeasy.org/~xyzzy/download/C81.ts.bz2

This is a ~3 second capture of QAM channel 81, which carries both KCPQ-DT
(tsprog 1, vid 33, aid 34, AC3 2.0) and KTWB-DT (tsprog 2, vid 36, aid 37, AC3
5.1)

http://www.speakeasy.org/~xyzzy/download/KCPQ-DT.ts.bz2
http://www.speakeasy.org/~xyzzy/download/KTWB-DT.ts.bz2

These are about ~6 seconds of just the given channel, the de-muxing was done
by the kernel DVB layer.  I don't know if this is hardware of software.

http://www.speakeasy.org/~xyzzy/download/KCPQ-DT.ac3

This is just the ac3 from KCPQ-DT from -dumpaudio.  If I run this through
the AC3 re-syncer I wrote, I get output like this:

Frame 0: Error in frame, syncword not found
        Next syncword found (offset 50), re-syncing
Frame 9: Frame appears to be short 4 bytes, (1532 out of 1536), re-syncing
Frame 14: Frame appears to be short 4 bytes, (1532 out of 1536), re-syncing
Frame 28: Frame appears to be short 4 bytes, (1532 out of 1536), re-syncing
Frame 40: Frame appears to be short 4 bytes, (1532 out of 1536), re-syncing
Frame 45: Frame appears to be short 4 bytes, (1532 out of 1536), re-syncing
Frame 51: Frame appears to be short 4 bytes, (1532 out of 1536), re-syncing
Frame 58: Frame appears to be short 4 bytes, (1532 out of 1536), re-syncing
Frame 79: Frame appears to be short 4 bytes, (1532 out of 1536), re-syncing
Frame 91: Frame appears to be short 4 bytes, (1532 out of 1536), re-syncing
Frame 99: Frame appears to be short 4 bytes, (1532 out of 1536), re-syncing
Frame 111: Frame appears to be short 4 bytes, (1532 out of 1536), re-syncing
Frame 114: Frame appears to be short 4 bytes, (1532 out of 1536), re-syncing
Frame 125: Frame appears to be short 4 bytes, (1532 out of 1536), re-syncing
Frame 145: Frame appears to be short 4 bytes, (1532 out of 1536), re-syncing
Frame 193: Short frame from premature end of file

It appears that some random frames have 4 bytes missing.  It's not the first
four bytes, or the syncword and header would be missing, and they're not, or
there'd be different errors.




More information about the MPlayer-dev-eng mailing list