[Ffmpeg-devel] 4XM audio codec_tag

Baptiste Coudurier baptiste.coudurier
Mon Nov 6 15:16:32 CET 2006


Michael Niedermayer wrote:
> Hi
> 
> On Mon, Nov 06, 2006 at 02:29:17PM +0100, Baptiste Coudurier wrote:
>> Michael Niedermayer wrote:
>>> Hi
>>>
>>> On Mon, Nov 06, 2006 at 12:17:20PM +0100, Baptiste Coudurier wrote: 
>>> [...]
>>>>>>>>>>> I would tend towards: better clutter the table a bit
>>>>>>>>>>> and support more formats however rare than having a
>>>>>>>>>>> cleaner table.
>>>>>>>>>> Again you've drifted from the question of sharing the
>>>>>>>>>> codec ID table between unrelated formats, and treating
>>>>>>>>>> the RIFF table as some kind of absolute reference.
>>>>>>>>>>
>>>>>>>>>> Just face the facts: formats use different tags to
>>>>>>>>>> identify codecs, no matter how much you pretend that
>>>>>>>>>> all of them use the RIFF values.  The only way to
>>>>>>>>>> properly handle this is by using one codec tag table
>>>>>>>>>> per format.  End of story.
>>>>>>>>> i have no problem with one table per format, what i have
>>>>>>>>> a problem with is that libav* would fail decoding a file
>>>>>>>>> if no match is found and that it would leave the codec
>>>>>>>>> tag decission to the end user and not suggest a default
>>>>>>>>> one if theres none in the one table for the target format
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> if OTOH there is one table per format and a default
>>>>>>>>> fallback table then thats something different with which
>>>>>>>>> iam fine
>>>>>>>> A "fallback table" doesn't make any sense at all.  None.
>>>>>>>> Zero.  Nil. Either a format supports some particular codec,
>>>>>>>> in which case its ID table will have an entry for that
>>>>>>>> codec, or the codec is not supported, in which case failure
>>>>>>>> is the only sensible option. "Suggesting" to use a tag from
>>>>>>>> some other random format instead is utterly senseless.
>>>>>>>> Such behavior is what created the AVI mess in the first
>>>>>>>> place.
>>>>>>> avi is a generic container its supposed to be possible to
>>>>>>> store anything in it (with a few exceptions) the same is the
>>>>>>> case for mov, matroska and nut there is nothing messy with
>>>>>>> that
>>>>>> There is nothing messy about a container that can potentially
>>>>>> be used with any codec.  The mess comes when people INSIST ON
>>>>>> INVENTING THEIR OWN CODEC TAGS.  How the f*ck are others
>>>>>> supposed to know what those tags mean if they are not included
>>>>>> in some kind of official list?
>>>>> uhm, look in the lists for avi and mov? and just read the tag,
>>>>> ohh well is it so hard to guess that mpg1 is mpeg-1 video?
>>>>>
>>>> Now look at 'mp4s', we have to deal with avi fourcc cause someone
>>>> stupid thought that putting avi fourcc was ok to do...
>>> is that is the worst you can find? mp4s is microsofts official fourcc
>>> for iso mpeg4 version 1 IIRC so i would suspect that this is besides
>>> m4s2 the most official fourcc for mpeg4 in avi really not a good
>>> example for bad user invented tags in avi ...
>>>
>> No, one day, someone put avi fourcc in mov, now we want to decode files
>> using avi fourcc, then we have to check against avi fourcc in mov, and
>> then collision appear.
>>
>> Now same guy thinks, yes, mov is generic container so I can put whatever
>> fourcc I want, let's put mp4s... and we are in deep shit, He might not
>> want it all in fact, he just stream copied, and since we honor codec_tag
>> first, and after all we just cannot refuse him to do that, since mov is
>> generic container.
> 
> ok, change stream copy to not set codec_tag by default but instead add a
> command line parameter which changes that (sets codec_tag to input codec_tag)
> 
> furthermore
> 1. if a codec_tag is set and it exists in the muxers table with a
>    correct matching codec_id it should be used

yes

> 2. if a codec_tag is set and it exists in the muxers table with a
>    wrong mismatching codec_id or it does not exist in the table then 
>    it should be used if strict_std_compliance is set to 
>    <=FF_COMPLIANCE_EXPERIMENTAL or cause a fatal error if not

I would not accept mismatching codec_id. If it does not exists, yes.

> 3. if a codec_tag is not set then set it depending on the table

yes

> 4. if there is no entry in the table then use a common table if
>    strict_std_compliance is set to <=FF_COMPLIANCE_EXPERIMENTAL
>    or cause a fatal error if not

yes

> do you agree with that?
> 

mostly, yes.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312




More information about the ffmpeg-devel mailing list