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

[Måns Rullgård]

madshi wrote:
> 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

These are standardised in ISO 13818-1.

> 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

These are all non-standard.

> There are two problematic situations:
>
> (1) 0x80 can be either MPEG2 video or LPCM audio. In the M2TS
> container

There is no such thing as "the m2ts container", at least not anything
standardised.

> 0x80 should always be LPCM audio.

Says who?

> In the TS container 0x80 is normally MPEG2 video.

In a standard MPEG-TS container, 0x80 is undefined.  It should certainly
not be MPEG2 video, since there is a defined stream type for that.

> BUT - if people convert an M2TS stream to TS, 0x80 can be PCM.

Such people are stupid, and should be handed to the firing squad.

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

The *only* way to have any clue whatsoever about the contents of streams
with stream type in the private range is by looking at various descriptors.

If a registration descriptor is present, its format_identifier value
should be registered with SMPTE.  The registration information generally
provides details on the stream type values used.

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

These are all examples of format_identifier values registered with the
SMPTE.

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

This is somewhat less reliable.  Those descriptor tags are in the
private range, and could be anything.  It is best to also look for
other indications of DVB or ATSC syntax.

-- 
M?ns Rullg?rd
mans at mansr.com