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

Måns Rullgård mans
Mon Jun 9 12:10:48 CEST 2008

madshi wrote:
> M?ns Rullg?rd schrieb:
>> madshi wrote:
>>> To my best knowledge this is the right way to demux TS and m2ts files:
>>> 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?  :-)

That depends.  You have to give them $UINT_MAX, your soul, and your
first-born son to see it.

>>> 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.
> Huh?
> Wikipedia [...].

Wikipedia is not an authoritative source for information on *anything*,
least of all format standards.

>>> 0x80 should always be LPCM audio.
>> Says who?
> Sais the Blu-Ray specification.

Do you have a copy of this 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?

I only care about the valid ones.

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

So send the authors of said software to the same firing squad.

> End users do not know what the software does in detail.
> They just expect things to work.

I expect my car to fly.  What?  It can't?  I *demand* that it fly!

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

Then tell them to go home.  Or to the firing squad.

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

If there is an "HDMV" registration descriptor present, one can assume
that the Bluray stream type mappings are used, whatever they may be.
This is exactly what I meant when I suggested "looking at descriptors".

If there is no registration descriptor, only standard stream types
should be present.  Others should be either ignored, or passed to
the application as unknown data.

Now I'm off to buy some more shells for my shotgun...

M?ns Rullg?rd
mans at mansr.com

More information about the ffmpeg-devel mailing list