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

Alex Converse alex.converse
Thu Jul 15 21:39:45 CEST 2010

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

I'm not saying that this is the best idea, merely that it doesn't
break ABI as you have been falsely asserting.

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

Fine I'll concede this point. Propose a patch for AVFORMAT 53 and
let's continue with this patch under the current ABI until AVFORMAT 53

More information about the ffmpeg-devel mailing list