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

Baptiste Coudurier baptiste.coudurier
Tue Sep 1 03:02:09 CEST 2009


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.

[...]

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org



More information about the ffmpeg-devel mailing list