[FFmpeg-devel] [RFC] additinal desc_type for dtshd mpeg-ts demuxer
Mon Jun 9 11:19:00 CEST 2008
M?ns Rullg?rd schrieb:
> madshi wrote:
>> 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.
So the Blu-Ray specification is not a standard? :-)
>> There are two problematic situations:
>> (1) 0x80 can be either MPEG2 video or LPCM audio. In the M2TS
> There is no such thing as "the m2ts container", at least not anything
Wikipedia sais: "A *technical standard* is an established norm or
requirement. It is usually a formal document that establishes uniform
engineering or technical criteria, methods, processes and practices."
There's an official and very detailed Blu-Ray specification available,
which according to my understanding and also according to wikipedia's
definition makes it a "technical standard".
>> 0x80 should always be LPCM audio.
> Says who?
Sais the Blu-Ray specification.
>> 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.
Do you want ffmpeg to support common TS files which
are out in the wild or not?
>> 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.
There is software available which does these conversions,
as stupid as it may seem.
End users do not know what the software does in detail.
They just expect things to work. Now of course you can
hold your hands over both ears and say "la la la la". But
that doesn't change the fact that sooner or later people
will bump into TS streams with 0x80 Blu-Ray PCM in it.
Users of my "eac3to" Blu-Ray and HD DVD handling tool
already did come to me with samples of such streams.
I see no basic problem adjusting ffmpeg so that it detects
such situations. Heck, I've no problem with it complaining
about it. It could post a big warning "incorrect PCM track
detected" or anything. But just pretending that such
misformatted TS streams wouldn't exist is not the right
thing to do in my book.
> 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 such descriptors are present. Unfortunately some
Blu-Ray tracks just have a "HDMV" descriptor and that's
it. You have no choice than to rely on the stream type
More information about the ffmpeg-devel