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

[Baptiste Coudurier]

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.

There are some registration descriptors that follow this rule, like 
'BSSD', 'drac' or 'VC-1' and more I guess.

>>> The correct solution is to make the MPEG-TS demuxer figure out the correct
>>> codec_id value based on all available information.  Then apps will not
>>> need to care about codec_tag.
>> Exactly, and that's what is done. If codec is not determined or not
>> known by libavformat, codec_tag can help application determine format.
>
> Only if lavf has an incomplete list.

Lavf list is incomplete: smpte-ra.org does only specify which 
organization define the format identifier, not the format itself.
Furthermore, people can put their own format identifier without 
registering it.

Setting codec_tag provides one way for the application to infer what the 
file contains if this format identifier is known and unique which is 
better than nothing IMHO, ideally applications would have access to both 
stream type and registration descriptor, or even access to the PMT part 
refering to this stream.

In the bluray case, some tracks use the same registration descriptor, 
but different stream types. In some other files, tracks with private 
data use private data stream type but unique registration descriptor.

I guess the code could be changed to set codec_tag to registration 
descriptor only if stream type is private data.

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