[MPlayer-dev-eng] AC-3 in a TS stream

[Trent Piepho]

> From: Nico Sabbi <nicola_sabbi at fastwebnet.it>
> 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 don't suppose there is a magic phrase to search for that will find a
specification?  It seems the DVD format is super-secret.

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

It looks like this doesn't work.  I wrote a perl script to parse the output
of mplayer's debug messages and ran:

mplayer -v -v -vo null -ao null dvb://KTWB-DT -frames 1

over and over.  The results are consistent after many tries.  If a PES packet
is detected as A52 (with or without header) then audio is detected on the
specified audio PID.  If all PES packets are detected as PES_PRIVATE1, then no
audio will be found on the audio PID.  Here is the output of my perl script
which I think will make it clear what is going on:

PRIVATE1 PES Size 5882 First byte 32 Format PES_PRIVATE1
A52_CHECK(168 input bytes), found 0 frame syncwords of 0 bytes length
PRIVATE1 PES Size 5882 First byte 56 Format PES_PRIVATE1
A52_CHECK(336 input bytes), found 0 frame syncwords of 0 bytes length
PRIVATE1 PES Size 5882 First byte EC Format PES_PRIVATE1
A52_CHECK(504 input bytes), found 0 frame syncwords of 0 bytes length
PRIVATE1 PES Size 5882 First byte BA Format PES_PRIVATE1
A52_CHECK(672 input bytes), found 0 frame syncwords of 0 bytes length
PRIVATE1 PES Size 5882 First byte A9 Format PES_PRIVATE1
A52_CHECK(840 input bytes), found 0 frame syncwords of 0 bytes length
PRIVATE1 PES Size 5882 First byte DC Format PES_PRIVATE1
A52_CHECK(1008 input bytes), found 1 frame syncwords of 1536 bytes length
PRIVATE1 PES Size 5882 First byte 3A Format PES_PRIVATE1
A52_CHECK(1176 input bytes), found 1 frame syncwords of 1536 bytes length
Auto-Detection: Failed, Audio -1, Video 36, Non-PRIVATE1 PES packets: No
PES packets 34, Audio PES packets 7, bytes >=35292

In this example, the tsprobe found 7 PES packets on the audio PID.  None them
began with 0x0b77 or 0x8, so they are all PES_PRIVATE1.  a52_check is called,
but doesn't find AC3.  The auto-detection of audio fails and mplayer thinks
there no audio pid, even though I told it there was.

I think there is a bug in the way a52_check is called.  If you look at the
input bytes for a52_check, it goes up by 168 for each PES packet.  That is
only one TS packet's worth of data.  It looks like the rest of the audio TS
packets that make up the PES packet are not getting passed to a52_check, and
so the check fails.

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

I am confused about this.  You say there is no AC3 syncword after the DVD VOB
sub-header, but the patch you later provided checks for an AC3 syncword after
the DVD VOB header for the DVD VOB style AC3 format.

Anyway, I looked at how mplex and dvdauthor deal with DVD VOB AC3 sub-headers,
since there is no spec I could find.  This is what I found:

dvdauthor will only look for a sub-header if the PTS_DTS flag is set in the
PES header.

dvdauthor and mplex expect the AC3 substream ID to be, in binary, 10000xxx,
for AC-3 substream xxx.  The code for a DTS substream is 10001xxx.  The TS
auto-detect code checks for 1000xxxx, one bit less specific than it could be.

The second byte after the sub-stream ID might be some kind of continuity
counter.  I'm unsure about this one.  dvdauthor ignores it, mplex sticks
something (???) there.  I found an dvd-audio open source project's docs that
say it is a continuity counter.

The next two bytes of the sub-stream header are an offset to the start of an
AC3 frame.  If the offset is 1 (I think, maybe 2?), then the AC3 frame
syncword must start immediately after the sub-stream header.  This is what
I suggested before, and what your patch checks for.

If the offset value is say 10, it is not clear to me if the 9 bytes between
the end of the PES sub-header and the start of the AC3 frame are:
A) payload data, ie. the end of the previous AC3 frame
B) extra bytes that are part of the PES sub-header, since PCM for example
   is not the same length as AC3.  So maybe it's the size, which would make
   sense.

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

I'm not sure I understand what you are saying here.  I though tsprobe
controlled the amout of data scanned, my mplayer uses 2000000 as the default
tsprobe size.  There is something else that is 32KB?

What I was trying to say, was during the TS probe, do auto-detection.  The
code should figure out if the stream is AC3, subtitles, AC3 in VOB format,
etc.  Once it decides, save that format.  During playback, the demux doesn't
try to guess AC3 vs AC3 in VOB format, it just uses the format it detected
during the probe.  

When you scan the first few bytes of hundreds of megabytes of unaligned AC3
data, it is very likely that bit patterns will come up that look like AC3 in
VOB or subtitles or something else.

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

Can contain anything, but if the specified audio PID has PRIVATE1 data that
isn't detected as something else, isn't AC3 a very safe bet?

> 
> Please, let me know if this patch helps you.

This does help, since the AC3 in VOB format now checks for:

8X XX XX XX 0B 77

instead of just

8X

Which is far less likely to randomly appear in the middle of an AC3 frame.  Of
course it still could.  If the first 168 bytes of each PES packet doesn't
happen to contain 8X XX* 0B 77, then A52 still isn't detected, and the
a52_check still fails.