[FFmpeg-devel] [RFC] the future of libamr
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