[FFmpeg-devel] [PATCH] MPEG-TS demuxer: Report 4cc in codec_tag field instead of SMTPE RID

[Måns Rullgård]

Baptiste Coudurier <baptiste.coudurier at gmail.com> writes:

> On 08/31/2009 05:48 PM, M?ns Rullg?rd wrote:
>> Baptiste Coudurier<baptiste.coudurier at gmail.com>  writes:
>>
>>> On 08/31/2009 05:05 PM, M?ns Rullg?rd wrote:
>>>> Baptiste Coudurier<baptiste.coudurier at gmail.com>   writes:
>>>>
>>>>> On 08/31/2009 03:31 PM, M?ns Rullg?rd wrote:
>>>>>> Baptiste Coudurier<baptiste.coudurier at gmail.com>    writes:
>>>>>>
>>>>>>> On 8/31/2009 10:42 AM, M?ns Rullg?rd wrote:
>>>>>>>> Reimar D?ffinger<Reimar.Doeffinger at gmx.de>     writes:
>>>>>>>>
>>>>>>>>> On Mon, Aug 31, 2009 at 09:18:29AM -0700, Baptiste Coudurier wrote:
>>>>>>>>>> On 8/31/2009 1:27 AM, Reimar D?ffinger wrote:
>>>>>>>>>>> On Mon, Aug 31, 2009 at 10:56:18AM +0300, Christian P. Schmidt wrote:
>>>>>>>>>>>> I know that mpeg-ts streams to not support 4cc tags for the codecs.
>>>>>>>>>>>> However, the mpeg-ts demuxer currently copies the registration ID into
>>>>>>>>>>>> the codec's tag field, which in my opinion is worse than leaving the
>>>>>>>>>>>> field empty.
>>>>>>>>>>>>
>>>>>>>>>>>> As an easy workaround the current tables for codec detection
>>>>>>>>>>>> could be expanded to hold the 4cc codes as used in riff.c and
>>>>>>>>>>>> return those in the codec_tag field.
>>>>>>>>>>>>
>>>>>>>>>>>> There are two codecs that do not have an official 4cc tag,
>>>>>>>>>>>> namely bluray-pcm and E-AC-3. I'd go with mplayer's
>>>>>>>>>>>> definitions for those, BPCM and EAC3.
>>>>>>>>>>> The codec_tag is not really supposed to be a fourcc, if there
>>>>>>>>>>> is no stream-specific tag that (more or less uniquely)
>>>>>>>>>>> indicates the codec used in the file it should be 0. Obviously
>>>>>>>>>>> it shouldn't be "random" nonsense like it seems to be
>>>>>>>>>>> currently either though.
>>>>>>>>>> Huh, it's not "random" nonsense, it's the registration descriptor if
>>>>>>>>>> present.
>>>>>>>>> Well, with DVB-T receptions I know I got something else about each try
>>>>>>>>> (sorry, haven't properly debugged it, nor recorded enough samples).
>>>>>>>>> And HDMV for LPCM audio _and_ and some video codecs is not exactly a
>>>>>>>>> "tag that (more or less uniquely) indicates the codec".
>>>>>>>>> I don't mind much, but I am having some doubts that the thing that
>>>>>>>>> currently ends up in codec_tag belongs there.
>>>>>>>> If anything, codec_tag should be set to stream_type from the PMT.  The
>>>>>>>> problem is that the meaning of stream_type values in the private range
>>>>>>>> (0x80 -- 0xff) depends on the registration descriptor and possibly
>>>>>>>> other private descriptors.  There is simply no way to uniquely
>>>>>>>> identify, in the general case, an MPEG-TS stream in 32 bits.
>>>>>>> Actually, I just double checked, codec_tag is set to stream_type
>>>>>>> then it is overwritten to registration descriptor if present.
>>>>>>> ISO specifies registration of private data through registration
>>>>>>> descriptor: "The registration_descriptor provides a method to
>>>>>>> uniquely and unambiguously identify formats of private data"
>>>>>>>
>>>>>>> This was discussed and Michael agreed to set codec_tag.
>>>>>> No disrespect, but Michael doesn't seem to understand MPEG-TS.
>>>>>>
>>>>>>> It is clear that only one field, codec_tag, can be limiting in the
>>>>>>> Bluray situation. ATSC and DVB uses registration descriptors correctly
>>>>>>> I think.
>>>>>> Bluray, ATSC, and DVB all use the registration descriptor properly.
>>>>>> They just use it in slightly different ways.  A registration
>>>>>> descriptor of "HDMV" indicates that a specific meaning for stream_type
>>>>>> values in the private range is used.  Assuming a one-to-one mapping
>>>>>> between codecs and registration descriptors would be a huge mistake.
>>>>> Well, what Bluray does seems very far from:
>>>>> "uniquely and unambiguously identify formats of private data" to me.
>>>>>
>>>>> Bluray uses registration descriptor 'AC-3' for both ac3 and ac3 mixed
>>>>> with truehd tracks. This seems much in contradiction with 'uniquely'
>>>>> to me.
>>>> I haven't seen the bluray specs, but I assume they specify some way of
>>>> separating eac3 from truhd data.
>>>>
>>>>> There are some registration descriptors that follow this rule, like
>>>>> 'BSSD', 'drac' or 'VC-1' and more I guess.
>>>> There is no such "rule".  The registration descriptor, together with
>>>> whatever add-on spec it invokes, *do* uniquely identify the stream in
>>>> all cases.  The registration descriptor alone is *not* required to do
>>>> so.
>>> What specs say are rules, and there is such rule:
>>> "The registration_descriptor provides a method to uniquely and
>>> unambiguously identify formats of private data"
>>>
>>> ISO specify one method of registering private data and this method is
>>> the use of the registration descriptor.
>>>
>>> "formats of private data" is pretty clear, furthermore interesting
>>> field is called format_identifier.
>>> Therefore when 2 _different_ formats uses the same format_identifier,
>>> IMHO this contradicts and violates the specs, whatever add-on specs
>>> may or may not say.
>>
>> Sorry, but you're wrong.  There is nowhere a requirement that the
>> format_identifier value correspond one-to-one with anything.
>
> I think the specs are pretty clear:
> "The registration descriptor of ITU-T Rec. H.222.0 | ISO/IEC 13818-1
> is provided by this text in order to enable users of this
> Specification to unambiguously carry data when its format is not
> recognized by this Specification. This provision will permit this
> Specification to carry all types of data while providing for a method
> of unambiguous identification of the characteristics of the underlying
> private data."
>
> I maintain that using the same registration descriptor for different
> private data is against the specifications, since it goes against
> providing unambiguous identification of the underlying private data.

I don't understand how you can come to that conclusion.  The wording
clearly allows for other data than the format_identifier itself to be
part of the method of identifying the stream format.

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