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

Alex Converse alex.converse
Thu Jul 15 22:10:29 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>:
>>>>> 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.
>

So am I going to wind up burying this patch because we can't agree on
what the ideal libavformat API should be?

What's making me irritated here is the patch is not being held up
because it is broken but because people dislike the established
interfaces.

Regards,
Alex Converse



More information about the ffmpeg-devel mailing list