On Sun, 10 Apr 2016 at 21:39 Michael Niedermayer <mich...@niedermayer.cc> wrote:
> On Sun, Apr 10, 2016 at 11:00:23PM +0300, Jan Ekstrom wrote: > > Hi, > > > > On Sun, Apr 10, 2016 at 10:13 PM, Michael Niedermayer > > <mich...@niedermayer.cc> wrote: > > > This is not about changing a bad encoder to a good encoder, this patch > > > is about removing choices. > > > Before this patch users can force libfaac and have twice as long > > > battery life at lower quality after the patch the users do not have > > > that choice anymore > > > > > > I do not think thats a good idea nor in the interrest of our users > > > > I have thought about this somewhat, and the things boil down to: > > * Libfaac is old, unmaintained, produces relatively bad quality and > > requires a "nonfree" configuration, which disables any sort of binary > > distribution. Last point probably being the most problematic for > > anyone who wants to use it outside of a server context. In which case > > there's already fdk-aac available, which has found immense popularity > > during the last few years before the internal encoder became better. > > Fdk-aac still serves a purpose with HE-AAC, as well as some specific > > LC-AAC use cases (latter according to some random people on #ffmpeg ), > > so it yet isn't considered something worth removing. > > * Both are very fast (about 30x realtime vs 60x realtime as far as > > could be gathered by the numbers posted on this thread if I am reading > > them correctly). Even if you are doing live recording, neither of > > these is likely to be slow enough for the CPU usage to really matter. > > * The faac encoder will still be there for those who really want to > > still use it, albeit no longer through libavcodec. This can actually > > ease usage for some people as they can now compile libavcodec without > > enable-nonfree and instead handle the licensing incompatibility on > > their side in one way or another (except it's supposedly licensed as > > GPL while parts of its source code are suposedly GPL-incompatible, > > thus pretty much making that case not really true, unlike fdk-aac > > which doesn't seem to have such contradictions within its own code > > base). > > > * Keeping this encoder available will serve as an endorsement for it. > > Do we really want to endorse this encoder? > > its not my intend to endorse anything. I just object to the removial > of optional libfaac support as long as its much faster than the > native encoder. Its twice as fast ATM, thats alot > > libfaac shows that it is possible to encode fast, the mail from > claudio suggests the same ... > > My request simply is "make our encoder as fast as libfaac before > removing libfaac" > > this is not about libfaac, it is about making our encoder better > > Doesn't answer my question about why we should keep a nonfree encoder which most users can't use. Kieran _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
