[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: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.  The
"method to uniquely and unambiguously identify" the streams may well
involve the application of rules from additional specs.  For HDMV,
this is "System Description Blu-ray Disc Read-Only Format part 3 Audio
Visual Basic Specifications" [sic].  I have not seen this spec, so I
do not know what it contains.  I have to assume it is sufficient to
decode a stream marked with this format_identifier value.

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