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

I made a mistake, and I'm terribly sorry.  I didn't intend to mislead
anyone.  No need to get aggressive.

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

I'd rather not spend time writing a patch that will be immediately
rejected.

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