On 9/29/2016 7:21 PM, Michael Niedermayer wrote: > On Thu, Sep 29, 2016 at 09:54:42PM +0100, Josh de Kock wrote: >> There is really no need for two aac wrappers, we already have >> libfdk-aac which is better. Not to mention that faac doesn't >> even support HEv1, or HEv2. It's also under a license which is >> unusable for distribution, so it would only be useful to people >> who will compile their own ffmpeg, only use it themselves (which >> at that point should just use fdk-aac). >> >> Signed-off-by: Josh de Kock <j...@itanimul.li> >> --- >> Changelog | 1 + >> LICENSE.md | 2 - >> configure | 6 -- >> doc/encoders.texi | 105 --------------------- >> doc/ffserver.conf | 2 +- >> doc/general.texi | 2 +- >> doc/muxers.texi | 4 +- >> doc/platform.texi | 2 +- >> libavcodec/Makefile | 1 - >> libavcodec/allcodecs.c | 1 - >> libavcodec/libfaac.c | 248 >> ------------------------------------------------- >> 11 files changed, 6 insertions(+), 368 deletions(-) >> delete mode 100644 libavcodec/libfaac.c > > dont remember if it was specific to libfaac but some issues in the > mov edit list patches about initial padding and trailing padding > where found using libfaac as encoder.
Both libfdk-aac and the internal encoder also seems to set inital_padding, so this is not really a reason to keep an inferior encoder around. Nothing really set trailing_padding right now, at least until and if the mp3lame commits make it to the tree. > if libfaac support is droped, muxers wont be tested against it anymore > most likely. It could be done with command line faac and remuxing but > that special case makes it so unwieldy that i doubt anyone will do it > > also quite some testcases in trac tickets used libfaac as it was > default at the time, > regression testing future changes against these tickets may be > unreliable without libfaac Bugs in libfaac or the lavc wrapper wouldn't happen anymore because the wrapper just wont exist anymore. And if some issue can't be reproduced with aacenc or libfdk-aac, then it wouldn't be an issue to begin with. We dropped libdcadec and libutvideo for being duplicate of internal functionality, libquvi for being unmaintained and no longer functional, and we dropped libaacplus and libvo-aac for sucking in both quality and license and having better alternatives also in both regards. The same applies to libfaac. Lets not waste more time bikeshedding about it. Nodody should be using this thing when aacenc and libfdk-aac exist. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
