[FFmpeg-devel] [RFC] the future of libamr
Diego Biurrun
diego
Sun Jun 7 13:08:47 CEST 2009
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.
> "Efforts should be made to remove non-free components from FFmpeg.
> Feature regressions are an acceptable cost for removal of said
> components." - Should this be a new FFmpeg policy?
I don't know what your big beef with "feature regressions" is. We have
had plenty of feature regressions over time. Things that come to mind
off the top of my head are vhook, Michale nuking Kabi's GIF decoder, the
libswscale transition, dropping BeOS support, portability hack removals
and if you start searching I'm sure you will come up with more.
So this is neither new nor as much a policy issue as you portray it to
be. It is a cost/benefit tradeoff. I could repeat myself about what
that tradeoff consists in, but I'm growing weary.
What exactly is the, preferrably new, issue you see?
Diego
More information about the ffmpeg-devel
mailing list