[FFmpeg-devel] [RFC] the future of libamr
Wed May 20 12:21:17 CEST 2009
On Wed, May 20, 2009 at 03:36:26PM +0530, Jai Menon wrote:
> On Wed, May 20, 2009 at 3:25 PM, Diego Biurrun <diego at biurrun.de> wrote:
> > On Wed, May 20, 2009 at 11:01:48AM +0200, Benoit Fouet wrote:
> >> On 05/19/2009 07:38 PM, Diego Biurrun wrote:
> >> > Now that OpenCORE AMR support is just around the corner, what about
> >> > libamr? ?I'm in favor of removing support for it. ?It's nonfree and it's
> >> > crap and we have a free replacement.
> >> >
> >> > There is a catch: libamr supports AMR-WB encoding, OpenCORE does not.
> >> > IMO we can disregard this. ?Hopefully it will spur the development of a
> >> > native replacement. ?I do not plan to remove libamr support from the 0.5
> >> > branch, so it will always be available there.
> >> or we can only keep the support of the WB encoder, depending on non-free
> >> flag ?
> > You don't think keeping it in the 0.5 branch will be enough? ?I think
> > removing non-free components from FFmpeg should be a high-priority goal
> But functionality should also be right up there in this list of goals,
> so to say.
Functionality is not the top priority. Otherwise we would have a
Windows DLL loader. Refer to the FAQ for our position on that.
> And what about people who want to be able to encode to
> AMR-WB and still make use of enhancements in trunk?
They will feel the pain or inconvenience of using nonfree software and
having to patch FFmpeg manually. With a bit of luck, this will motivate
them to write an encoder or fund somebody else to do it.
> >> I'm not sure that the people who need WB encoder are the one who are
> >> going to write a free WB encoder anyway :)
> > Who is going to write it or fund writing it then? ?If it is cheap, good
> > enough and available, nobody might be motivated.
> Doesn't that imply something :)
It implies that it can be a good strategy to let people feel some pain
and inconvenience. Experience shows that it increases the motivation to
fix the issues at hand properly. Short term pain, long term gain.
> > Look at how long we have had to put up with libfaad and Adobe Flash...
> And I guess this will continue till support for missing tools ends up in ffaac.
> Are you saying that this process will be somehow accelerated if we
> remove the libfaad wrapper?
In general, yes. At this point in time, probably not, because all the
missing features are being worked on and it is not clear what is needed
to accelerate their implementation.
More information about the ffmpeg-devel