[FFmpeg-devel] [RFC] additinal desc_type for dtshd mpeg-ts demuxer

[madshi]

elupus schrieb:
> Hi, 
>
> Was playing around with a blueray mpegts file, and noticed that lavf wasn't
> detecting the audio stream in it. Turns out the desc_type for this dts
> track was 0x86. After some looking about, I found highly non offical list
> of desc_types in a software called TsRemux
> http://forum.doom9.org/showthread.php?t=125447 
>
> VIDEO_STREAM_MPEG1 = 0x01,
> VIDEO_STREAM_MPEG2 = 0x02,
> AUDIO_STREAM_MPEG1 = 0x03, // all layers including mp3
> AUDIO_STREAM_MPEG2 = 0x04,
> VIDEO_STREAM_H264 = 0x1b,
> AUDIO_STREAM_LPCM = 0x80,
> AUDIO_STREAM_AC3 = 0x81,
> AUDIO_STREAM_DTS = 0x82,
> -> AUDIO_STREAM_AC3_TRUE_HD = 0x83,
> -> AUDIO_STREAM_AC3_PLUS = 0x84,
> -> AUDIO_STREAM_DTS_HD = 0x85,
> -> AUDIO_STREAM_DTS_HD_MASTER_AUDIO = 0x86,
> PRESENTATION_GRAPHICS_STREAM = 0x90,
> INTERACTIVE_GRAPHICS_STREAM = 0x91,
> SUBTITLE_STREAM = 0x92,
> SECONDARY_AUDIO_AC3_PLUS = 0xa1,
> SECONDARY_AUDIO_DTS_HD = 0xa2,
> VIDEO_STREAM_VC1 = 0xea
>
> I highlighted the interesting ones. Oddly is not listing 0x8a as a dts
> track which lavf's demuxer does. Would a patch be accepted adding the
> desc_types not in lavf currently, under the same hdmv check?
>
> I can't see that it would break any existing file by adding these types,
> and i think it's more likely to get bug reports on missdetected audio
> streams instead of not seeing any stream all. I know there is some poeple
> wanting to replace the mpegts demuxer, but untill then...
>
> Don't bother commenting on cosmetics on the attached patch, it was just a
> quick and dirty test to fix the sample i found. 
>
> Joakim
>   


To my best knowledge this is the right way to demux TS and m2ts files:

0x01: MPEG2 video
0x02: MPEG2 video
0x03: MP2 audio (MPEG-1 Audio Layer II)
0x04: MP2 audio (MPEG-2 Audio Layer II)
0x06: private data (can be AC3, DTS or something else)
0x0F: AAC audio (MPEG-2 Part 7 Audio)
0x11: AAC audio (MPEG-4 Part 3 Audio)
0x1B: h264 video
0x80: MPEG2 video or PCM audio
0x81: AC3 audio
0x82: DTS audio
0x83: TrueHD/AC3 interweaved audio
0x84: E-AC3 audio
0x85: DTS-HD High Resolution Audio
0x86: DTS-HD Master Audio
0x87: E-AC3 audio
0xA1: secondary E-AC3 audio
0xA2: secondary DTS audio
0xEA: VC-1 video

There are two problematic situations:

(1) 0x80 can be either MPEG2 video or LPCM audio. In the M2TS
container 0x80 should always be LPCM audio. In the TS container
0x80 is normally MPEG2 video. BUT - if people convert an M2TS
stream to TS, 0x80 can be PCM. Also if people convert a TS stream
to M2TS, 0x80 could be MPEG2 video. The most reliable way to
figure out what it really is is checking the descriptors. If there's a
descriptor 0x05 with the format_descriptor "HDMV" then the track
originates from a Blu-Ray and thus is PCM.

(2) 0x06 can be AC3, DTS or something else. You need to check
the descriptors to find out what it really is. If there's a descriptor
0x05 with the format_identifier of "DTS1", "DTS2", "DTS3" or
"AC-3" then you know what the track is. If there's a descriptor
0x05 with the format_identifier "BSSD" then it's an old style (non
Blu-Ray) LPCM track. I don't know how to handle such a track.
Have no sample for that. Finally, if there's no descriptor 0x05
which tells you which format this track is, you can look for
descriptors 0x6a (DVB AC3), 0x73 (DVB DTS) or 0x81 (ATSC
AC3). If any of these 3 descriptors is present, again you know
what the 0x06 track contains.

Regards, madshi.