[Ffmpeg-cvslog] r6963 - trunk/libavformat/riff.c

[Måns Rullgård]

Baptiste Coudurier <baptiste.coudurier at smartjog.com> writes:

>>>>>>> Nooooo.  We were trying to get rid of those invalid bogus tags from
>>>>>>> riff.c.  Don't add more of them.
>>>>>> nut per spec uses the avi-riff tags to identify codecs, libnut uses
>>>>>> "MP3 " ...
>>>>>> ask oded why
>>>>>> but the nut tags do belong in riff.c IMO, furthermore there is no harm
>>>>>> from this wav/avi cant use them anyway as they are too long, also they
>>>>>> are at the end so they wont be selected by default ...
>>>>>>
>>>>> IMHO, nut uses fourcc, aka 32 bit int that is supposed to
>>>>> identify a codec, not avi-riff tags,
>>>> wrong, to quote the spec:
>>>> fourcc
>>>>     identification for the codec
>>>>     example: "H264"
>>>>     MUST contain 2 or 4 bytes, note, this might be increased in the future
>>>>     if needed
>>>>     the id values used are the same as in avi, so if a codec uses a specific
>>>>     fourcc in avi then the same fourcc MUST be used here
>>> That's about as vague as it gets, and is furthermore completely
>>> irrelevant.  The tables in riff.c are for AVI and WAV.  AVI and WAV
>>> use 16-bit tags for audio.  Hence, "MP3 " is invalid in that table.
>>> If NUT wants to use 32-bit tags for audio, thats fine.  Just don't
>>> claim they are the same as AVI, and don't pollute the RIFF tables with
>>> them.
>> ive heared your oppinion, ive not heared any reasoning to support
>> it, not even a vague one and iam sure you heared that i rejected a
>> table split based on philosphical reasoning, so i guess that leaves
>> you with either showing some end user vissible advantage or to fork

How about ffmpeg being spec compliant as a reason?  Oh, I forgot, you
don't care about specs...

> This is becoming childish.
> Why not merging all codec tables in riff.c then ?

Yeah, include the MPEG ones too.

-- 
M?ns Rullg?rd
mru at inprovide.com