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

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

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