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

Måns Rullgård mans
Thu Jul 15 21:35:14 CEST 2010

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.

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

M?ns Rullg?rd
mans at mansr.com

More information about the ffmpeg-devel mailing list