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

Robert Swain robert.swain
Sun Jun 7 13:53:08 CEST 2009

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'. Did the GIF decoder have a 
replacement pending at the time? libswscale was a replacement that was 
supposed to be mostly better than imgconvert. Did the platform 
portability issues have replacements?

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 

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.

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.

One could argue that the vhook filters are also no insignificant amount 
of work, though people don't usually need all of them and the ones in 
high demand are receiving attention in libavfilter already.

> 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. :)


More information about the ffmpeg-devel mailing list