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

[Nico Sabbi]

Trent Piepho wrote:

>>
>>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.
>  
>

yes, IS13818-1 is the right one

>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. 
>
PSIP spec (atsc tables) requires this

> 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?
>  
>

yes: for some funny reason it's (or it was) common practice to use the 
same format
used by DVD to encapsulate AC3 in TS, although there's no reason to 
convey it this way

>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.  
>

it's not required

>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.
>
>  
>

correct

>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.
>  
>
not exact: it will be marked as PES_PRIVATE1 and ac3 probing will happen 
in a52_check()

>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?  
>

yes, I've seen them quite often

>The auto-detection only checks the first four bits. 
>What about the next 28 bits, maybe there is something to look for there? 
>  
>
no

>After the 32-bit substream header, should there be a AC3 syncword that can be
>checked for?
>

no

>  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? 
>

since usually a lot of packets are scanned before deciding the stream type
(default: 32KB) this method permits to identify the content used with
a certain degree of security

> 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.
>  
>

I agree that every format detected should have a score

>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?  
>

I'll repeat it: there is and there must not be any binding between 
channels.conf and the TS demuxer,
except maybe a new STREAM_CTL to ask stream_dvb to add the PMT pid to 
the TS (easy to
implement, I'll do it this week-end if I have time).
The match between -aid and the stream id is checked in ts_detect_streams()

>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?  
>

I'm not sure. As I wrote pes_private1 streams can contain _anything_


>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)?
>
>  
>

maybe the safer thing to do is: when there are no tables and the demuxer 
finds
a pes_private1 { if the payload contains 0xb77 word assign it AUDIO_A52 
stream_type}
else assign it PES_PRIVATE1 type.

assign it