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

[Nico Sabbi]

Trent Piepho wrote:

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

all that is know is hearsay, because the specs  are very expensive and 
require signing an NDA,
afaik.
Some information is available here: dvd.sf.net

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

in this case my code is buggy. I'll fix it this week-end, if possible.
Can you post a link to this sample, please? I need a lot of them to test 
the code

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

I guess I know why: other initial bytes than 0x8n in the next payload 
packet will make
demux_ts forget that previously it found a PES_PRIVATE1 stream

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

yes, but in any position in the payload of the current packet

>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.
>  
>
the sub header is always needed, even with no pts/dts

>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.
>  
>
of course: it searches AC3.
0x80 -> 0x87 : AC3
0x88 -> 0x8f : DTS (that I don't want to deal with)

>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.
>  
>
no, it's the count of AC3 frames present in the current pes packet

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

yes

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

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

no

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

32KB is the default value for -tsprobe. Specifying -tsprobe 2000000 will 
override the
default value

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

right

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

I should implement a scoreboard for each of these possible types

>  
>
>>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?
>  
>
not so much

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

ok. you convinced me that when dealing with a pes_private1 stream not 
qualified by the PMT
I should implement a parser to match the most likely format used.
It'll take some time.
In the meantime, you can add that PMT pid in your channels.conf
    Nico