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

[Alex Converse]

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.

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