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

Baptiste Coudurier baptiste.coudurier
Fri Jul 16 04:59:08 CEST 2010

On 07/15/2010 07:47 PM, Michael Niedermayer wrote:
> On Thu, Jul 15, 2010 at 09:21:08PM +0200, Reimar D?ffinger wrote:
>> On Thu, Jul 15, 2010 at 03:05:51PM -0400, Alex Converse wrote:
>>> 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.
>> Uh, the problem is that we have nothing else that could qualify as a unique
>> identifier for the format.
> Iam not against a format_id like codec_id

I was thinking about that as well. It could be useful.

Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org

More information about the ffmpeg-devel mailing list