[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 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.

>>>> 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.

> Furthermore, people can put their own format identifier without
> registering it.

That's outside the scope of this discussion.

> 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.

> 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.

There are many possible combinations, most of them equally valid.

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