[Ffmpeg-devel] 4XM audio codec_tag

[Baptiste Coudurier]

Hi

Michael Niedermayer wrote:
>>> [...]
>>> if you wish to prevent the user from doing things (s)he wants to do
>>> then you shouldnt write open source software
>> That doesn't mean we should make it easier for users to do stupid
>> things, like creating files in violation of the standards.  Of course
>> we can't completely stop them from doing it, but they should at least
>> have to put some effort into it.
> 
> could you point me to the spec which disallows a new codec to be stored in
> it? iam not even sure if mpeg-ps/ts do that and if they do, are really all
> the things various _different_ standard comittees put in it valid?
> 

Depends on container, but I know for sure that ISO Media and derivates
does not support it by defining really constrained specs. (mp4 only
allows 'mp4v' and 'avc1' as fourcc and defines codec type in object type
id, all values are defined or reserved, same for 3gp, I don't really
know for mov, I did not check deeply). I think that overriding a
reserved value is non standard and therefore forbidden.

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

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