[FFmpeg-devel] [RFC] the future of libamr

Baptiste Coudurier baptiste.coudurier
Sun Jun 7 20:34:47 CEST 2009


Diego Biurrun wrote:
> On Sun, Jun 07, 2009 at 11:38:42AM +0100, Robert Swain wrote:
>> Diego Biurrun wrote:
>>> On Sat, Jun 06, 2009 at 07:20:09PM +0100, Robert Swain wrote:
>>>> Diego Biurrun wrote:
>>>>> On Fri, Jun 05, 2009 at 02:21:23PM +0100, Robert Swain wrote:
>>>>>> OK, then I guess the only issue is a feature regression in that 
>>>>>> libopencore-amrwb doesn't do encoding. As Diego points out, there's 
>>>>>> nothing stopping people from using FFmpeg 0.5 or a version of svn from 
>>>>>> before the libamr reference wrapper gets removed, but I'm not really 
>>>>>> fond of feature regressions. Is there any good reason not to keep the 
>>>>>> libamr-wb reference encoder wrapper?
>>>>> May I suggest that you read the 25+ messages in this thread before
>>>>> restarting the discussion at square one?  Pros and cons have already
>>>>> been hashed out extensively and a consensus seemed to have been reached.
>>>>> If you have anything new to add, reply to the relevant subthread.  Just
>>>>> raising the same concerns over and over again is inconstructive and
>>>>> leads nowhere.
>>>> I had actually read them but had forgotten about them as I was out of 
>>>> the country so, I apologise for this. However, I didn't see a deadline 
>>>> set for consensus to be reached.
>>>>
>>>> Benoit had some reservations about feature regression then decided it 
>>>> was OK, though I don't see him mention any compelling reason why he 
>>>> changed his mind other than that removing non-free components is good. 
>>>> Benoit?
>>>>
>>>> Then Baptiste commented that he wasn't too keen on a feature regression 
>>>> and you stated that it seemed a consensus had been reached. Then 3 days 
>>>> after Baptiste's comment, you committed the OpenCORE support and said 
>>>> you were going to remove libamr. A consensus has not been reached if not 
>>>> everyone has accepted the same idea and it seems not everyone has.
>>>>
>>>> I'm not sure how many people actually use AMR-WB encoding. I would guess 
>>>> the parties interested would be mostly commercial.
>>>>
>>>> I don't really know what option is best. It's non-free but removing it 
>>>> would be a feature regression. Why did we have the AMR reference 
>>>> implementation wrapped in the first place if not having non-free stuff 
>>>> in FFmpeg was a major concern versus not having the feature?
>>> Quoting myself:
>>>
>>>  Pros and cons have already been hashed out extensively and a consensus
>>>  seemed to have been reached.  If you have anything new to add, reply
>>>  to the relevant subthread.  Just raising the same concerns over and
>>>  over again is inconstructive and leads nowhere.
>>>
>>> Of course it's a feature regression.  But luckily there is no law
>>> against it.  All you need are good reasons.  We have done it before.
>>> There are good reasons now, so we can do it again.
>> No solid consensus was reached and there _was_ opposition to a 
>> consensus.
> 
> There was a discussion where arguments were exchanged.  The people who
> raised concerns appeared convinced after the discussion.
>
> Then Baptiste and later you jumped into the discussion without having
> read the previous discussion (or having forgot about it).  If everybody
> does that it's very easy to mount a denial of service attack against the
> person proposing a change and thus against a consensus.
> 

"Against a consensus" ? This is nonsense.
You cannot be against consensus. Either there is consensus, or not.

In this case there is _no_ consensus.

"Yes, thanks. Well I'm not sure we should remove a feature :/"

I can't see how you interpret this as being ok with the removal of
libamr, so to be clear: I'm against this removal.

There is no consensus, please don't claim there is or have been one.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org



More information about the ffmpeg-devel mailing list