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

[Baptiste Coudurier]

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.

That's not really important though, implementation must deal with both 
simple and complicated scenario.

>>>>> 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.
>
> If some application is able to make sense of a format identifier not
> handled by lavf, that can only mean that lavf *could* be improved to
> handle this value as well.

Yes it could, unfortunately people are not necessarly interested nor 
willing to disclose or share. The code was added specifically to support 
this situation.

>> Furthermore, people can put their own format identifier without
>> registering it.
>
> That's outside the scope of this discussion.

See above, that's why codec_tag was set in the first place.

>> 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 most general case, you would indeed need the full PMT to be
> certain of having all the required information.  The spec invoked by
> some format identifier could very well rely on additional, private
> descriptors to fully identify the format.  DVB does this to some
> extent, but not for streams we care about.

Yes, I agree with this, like explained on roundup, I support the idea of 
a "container_data" field in AVCodecContext or a "codec_data" field in 
AVStream could be introduced, used to store the part of the PMT, 
additionnaly it could contain full stsd atom present in mov/mp4, or the 
full bmpheader or waveformat header from avi/wav, or any structure used 
by the container to describe the codec.

It would be container specific, but documented (maybe partially) by 
corresponding specifications.

[...]

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