[FFmpeg-devel] [PATCH] Add WebM to the Matroska demuxer name

[Baptiste Coudurier]

On 07/15/2010 12:35 PM, M?ns Rullg?rd wrote:
> Alex Converse<alex.converse at gmail.com>  writes:
>
>> 2010/7/15 M?ns Rullg?rd<mans at mansr.com>:
>>> Alex Converse<alex.converse at gmail.com>  writes:
>>>
>>>> 2010/7/15 M?ns Rullg?rd<mans at mansr.com>:
>>>>> Baptiste Coudurier<baptiste.coudurier at gmail.com>  writes:
>>>>>
>>>>>> On 07/15/2010 10:32 AM, M?ns Rullg?rd wrote:
>>>>>>> Reimar D?ffinger<Reimar.Doeffinger at gmx.de>    writes:
>>>>>>>
>>>>>>>> On Thu, Jul 15, 2010 at 01:58:58AM -0400, Alex Converse wrote:
>>>>>>>>> $subj
>>>>>>>>>
>>>>>>>>> Some users are getting confused. We do a similar thing for
>>>>>>>>> "mov,mp4,m4a,3gp,3g2,mj2."
>>>>>>>>
>>>>>>>> And I've always considered it a bad idea.
>>>>>>>> Changing this field means the value you need to use for -f changes
>>>>>>>> (and MPlayer actually also relies on this name), so strictly speaking
>>>>>>>> this would require a major version bump.
>>>>>>>
>>>>>>> -f matroska,webm would be nothing short of ridiculous.
>>>>>>
>>>>>> WTF, for demuxers, values are matched between commas. Mans, you even
>>>>>> reviewed that patch.
>>>>>
>>>>> I forgot about that, and now I come to think it was probably not such
>>>>> a good idea.  It will break any application which enumerates the
>>>>> demuxers and does something with the name, and as such this should be
>>>>> considered an ABI break.
>>>>
>>>> That strikes me as ABI abuse. *av_find_input_format() still works. You
>>>> could make the same argument about longnames. Where do we guarantee
>>>> that short name lists won't grow. I don't see anything in the doxy or
>>>> any other annotation treating shortnames and long names differently in
>>>> any ABI regard.
>>>
>>> What if you want to make a list of all format?  av_find_input_format()
>>> only works when you already know the name.  Consider as an example a
>>> GUI app presenting a list (of long_names) to the user, then using
>>> av_find_input_format() to select the one the user chooses.  Such an
>>> app would break if the name suddenly needs to be split before it can
>>> be used.
>>
>> Some existing names already need to be split.
 >
> So we need to fix them.  Don't try appeal to tradition on me.
> Traditions are often wrong.

No, no name need to be split, you can call av_find_input_format with the 
full name _with_ commas.

>>>>> The correct solution is to make that field a proper array like we have
>>>>> for some other properties.  To avoid breaking ABI, we could even add
>>>>> a list of aliases at the end of the struct.  The single name field
>>>>> could be dropped at the next big break if we want to.
>>>>
>>>> I don't see how a proper array is better than a comma delimited list
>>>> for these purposes
>>>
>>> Only a million times easier to parse.  String processing is not
>>> something you want to be doing in C unless you really have to.
>>
>> Splitting on commas is pretty basic as far as string processing goes.
>
> Not as simple as iterating over an array.  There are two basic ways of
> doing it: 1) make a copy of the string and use strtok_r (which Stefano
> was struggling with the other day), or 2) scan for commas and copy out
> only the relevant part.  If you want the full list, it gets even more
> complicated.  Storing an array directly requires no code at all.  You
> can't win this argument.

There are already enough APIs for working with input formats, there is 
no need for an array that will be more complicated to extend.

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org