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

[Trent Piepho]

> Date: Tue, 21 Feb 2006 13:20:18 +0100
> From: Nico Sabbi <nsabbi at email.it>
> Subject: Re: [MPlayer-dev-eng] Re: Another ATSC "a52: CRC check
> 	failed" problem
> 
> Trent Piepho wrote:
> > Here is a question, can auto-detection be made to work (better)?  
> 
> not without tables: data in pes_private1 streams (id==0xbd) can be
> really anything
> 
> > I would try,
> > but where can I get better documentation on the PES format?  All I find is
> > info on the first 6 bytes of the PES header.
> >   
> 
> search IS13818-2

Thanks for the tip.  IS13818-2 only defines the bitstream format for mpeg-2
ES, but it references IS13818-1, which has the TS, PS, and PES information.

I've looked at the stations which (relatively) work, and those that don't, and
I think the problem is one of alignment, not of format.

It appears that every ATSC station I get has AC-3 audio encoded inside a PES
stream with ID 0xbd.  None of them encode the audio further inside a sub-stream
with a substream_id of 0x8n.  In fact, I have no idea what this 'substream'
you're talking about is.  The IS13818-1 documentation doesn't say anything
about sub-streams with a 4-byte header inside PES streams.  Nor does the AC3
spec, Doc A/52A.  I suppose there is some other document that defines them?

I've edited the debug output of the TS demuxer slightly, but I think it will be
clear to you what it means.

Stations which "work" look like this:

pes_parse2: HEADER 0x000001 0xbd 0x1808(=6152)
pes_parse2: audio buf = 0B 77 47 B6 1C 30 E1 B4, 80: 0
A52 RAW OR SYNCWORD

The start of the PES payload data is always 0x0b77, which is detected as an
ac-3 syncword; the steam is tagged AUDIO_A52, and everything is fine.  The PES
size is always 6152, which is exactly four 1536 byte AC3 frames plus 8 bytes
extra PES headers.  For other working stations, the PES packet size is always
the right amount to hold some constant number of whatever AC3 frame size they
are using.

Stations which do not work looks like this (sequence of 3 PES headers):

pes_parse2: HEADER 0x000001 0xbd 0x072a(=1834)
pes_parse2: audio buf = 5F E8 F0 69 47 A2 FC 75, 80: 0
PES_PRIVATE1
--
pes_parse2: HEADER 0x000001 0xbd 0x0672(=1650)
pes_parse2: audio buf = 66 B6 0D 68 79 7A 0B 77, 80: 0
PES_PRIVATE1
--
pes_parse2: HEADER 0x000001 0xbd 0x072a(=1834)
pes_parse2: audio buf = 83 25 BB CA D6 4C 3A 18, 80: 128
A52 WITH HEADER


The start of the PES payload is not 0x0b77.  The AC3 frames are NOT aligned
with the start of the PES packets.  The data is still just a raw AC3 stream
with no extra headers.  The PES packet will either get tagged as PES_PRIVATE1,
or as 'A52 WITH HEADER', if the first four bits are 0x8.  When 'A52 WITH
HEADER' is detected, four bytes are cut out of the AC3 stream, which causes an
error in the steam.

It seems that if mplayer happens to get a PES packet during the tsprobe that
is detected as AUDIO_A52, audio will play.  This happens when there is a PES
packet that starts with 0x0b77 or 0x8.  If none of these happen to come up,
and with non-aligned streams it's just random chance, no audio is detected.

This is why KCPQ, which uses ~1834 byte packets will usually have audio, while
KTWB with ~5882 byte packets will usually NOT have audio.  With the larger
packets there are fewer audio PES packets in the tsprobe, which results in
fewer chances for a packet to start with 0x8.

I can think of a few ways to improve the auto-detection.

I don't know anything about the ac3 in a substream format.  Does it really
exist in a TS stream?  The auto-detection only checks the first four bits. 
What about the next 28 bits, maybe there is something to look for there? 
After the 32-bit substream header, should there be a AC3 syncword that can be
checked for?  If the check is made more specific, there will be fewer false
positives.

The autodetection code allows for one PID in a TS stream to change from being
AC3 with no substream header, to AC3 with a substream header, to DVD
subtitles, to PCM audio, and so forth, on a packet by packet basis.  Is it
useful to support a stream changing formats like this?  Can it even happen? 
Wouldn't it be better to try to auto-detect the stream format during the
tsprobe, then lock that format?  Instead of trying to auto-detect on a packet
by packet basis, without regard to the format of the previous packet.

If a PID is specified via channels.conf or -aid as having the audio stream, is
it a good idea to try to auto-detect DVD and DVB subtitles in it?  The user
has said, it is not subtitles but audio.  Why second guess them with fallible
auto-detection?

If a MPEG-TS PID is defined as having audio, and has a PES type of 0xbd, it is
almost certainly the case that is has AC3 audio, right?  How about assuming it
is AC3 unless something else, e.g. PMT, auto-detection during tsprobe, etc.,
finds something else.  Right now it looks like if an audio PID doesn't have
ac3 auto-detected or specified via PMT, it is assumed to have nothing usable
in it.  If mplayer has to guess, isn't the guess that is almost always right
(AC-3) better than the one which is almost always wrong (private data)?