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

[Måns Rullgård]

madshi wrote:
> M?ns Rullg?rd schrieb:
>> madshi wrote:
>>
>>>> Whatever it is, it specifies a number of additions to
>>>> standard MPEG-TS, indicated by the HDMV registration
>>>> descriptor.
>>>>
>>> Nope, only some of the additions are marked by "HDMV".
>>> E.g. TrueHD tracks have an "AC-3" registration descriptor
>>> and no "HDMV". So when using your logic ffmpeg would
>>> not be able to handle Blu-Ray TrueHD tracks properly.
>>>
>>
>> Stop nit-picking, please.  Had you bothered to read any
>> of my previous mails, you'd have realised that I *any*
>> registration descriptor sufficient to identify a stream
>> should be used, not only HDMV.  This is not the problem
>>
>> The problem is with when a stream has a stream type
>> in the private range, and there is *no* applicable
>> registration descriptor present.  When this is the
>> case, we *cannot* know what it is, and we should not
>> be trying to guess it.
>>
>
> If there's an "AC-3" registration descriptor how would you
> come to the conclusion that this would be a TrueHD stream
> and not a simple AC3 stream?
>
> The only way to handle a Blu-Ray TrueHD stream correctly
> is to make use of the new hard coded Blu-Ray stream type
> IDs. That was the point I was trying to make. Looking at
> the registration descriptor alone to identify a stream is
> simply not good enough.

The HDMV descriptor is at the program, not stream level.
When present, the extended Bluray stream type mappings
apply to all streams in the program, even if the individual
streams do not have registration descriptors.

To process to find the contents of a stream goes something like
this:

if (stream_type defined by ISO)
    use standard mapping;
else if (stream has registration descriptor)
    do whatever descriptor registration specifies;
else if (program has registration descriptor)
    use extended stream_type mapping;
else
    ignore;

>> I'm not talking about politics.  I'm talking about giving
>> people at least some incentive to create valid streams.
>> If invalid streams don't play, they'll have no choice but
>> to create valid ones.  In the long run, this makes life
>> much easier for everybody involved.
>
> If ffmpeg had some kind of monopol then that might
> work. But the tools commonly used for Blu-Ray and HD DVD
> demuxing, remuxing, reencoding and playing today are mostly
> not based on ffmpeg, as far as I can say. So you guys deciding
> that you don't want to support some specific "invalid" streams
> won't have much effect. If at all, people might just say:
> "Oh, ffmpeg doesn't work well for these new HD formats,
> let's use something else".

Good luck finding "something else" that is open source.

> Anyway, I know your opinion now and you know mine.
> So maybe we should leave it as that. I'm not using ffmpeg's
> splitters, anyway.

Then why do you care what we do?

>> The difference is that you try to please all the whining
>> users, while I send them to the firing squad.
>>
>
> My main interest is not in pleasing whining users. I'm interested
> in making my software work as good as possible even if the
> source may be "strange". I prefer software that just works
> and doesn't try to lecture the user of what he should do.

Would you also have your C compiler silently "fix" errors in your
code?

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