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

[Diego Biurrun]

On Sun, Jun 07, 2009 at 12:53:08PM +0100, Robert Swain wrote:
> Diego Biurrun wrote:
> >On Sun, Jun 07, 2009 at 11:38:42AM +0100, Robert Swain wrote:
> >>"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.
> 
> vhook has a successor in the works which promises to be much better 
> while vhook itself was deemed 'bad'.

But to this day, the replacement for vhook consists of nothing more than
promises.  It was pretty clear that libavfilter would take months until
completion, maybe years is a better estimate nowadays...

> Did the GIF decoder have a replacement pending at the time?

No.

> Did the platform portability issues have replacements?

Not all of them, no.

> It seems if some implementation of features has a replacement that is 
> preferred and it is lacking some subset of features, we transition to 
> the preferred implementation with the intention of fixing up any 
> regressions.
> 
> With libswscale at least, that happened. There were some code paths that 
> were slower with libswscale versus imgconvert and these were optimised 
> accordingly and promptly. Also, as I recall, more commonly used but 
> missing conversion paths were added.

I'll have to note here that dropping imgconvert did considerably speed
up this proces...

> In my opinion, however, the decision to transition depends on the amount 
> of work to rectify the regression versus the demand for/user base of the 
> feature. An AMR-WB encoder is no insignificant amount of work but maybe 
> not many people use it, in which case it doesn't really matter.

AMR-WB encoding is extremely obscure.

> >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?
> 
> None, so fair enough, I have no further comments other than to say good 
> luck with the transition and more power to free software. :)

Good, issues settled than.  I'll nuke libamr support tomorrow.

Diego