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

[Måns Rullgård]

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.

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

-- 
M?ns Rullg?rd
mans at mansr.com