| Message ID | 20160929205442.63177-1-josh@itanimul.li |
|---|---|
| State | Accepted |
| Commit | dc0f711459e0c682bf9f94ba38d26736e90cff45 |
| Headers | show |
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 <josh@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. 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 [...]
On Fri, 30 Sep 2016 00:21:56 +0200 Michael Niedermayer <michael@niedermayer.cc> 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 <josh@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. Just because it was useful in one situation doesn't mean we have to keep it forever. Also this argument is highly shady and unspecific. Why couldn't this done with another encoder? What are the details on this? > 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 I highly doubt anyone will bother with installing and compiling with libfaac at all. > 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 Well good thing that we don't have to fix libfaac bugs anymore once this is removed. What is the real reason you want to keep this? Last time you argued libfaac was needed for audio encoding on phones, even though absolutely nobody is going to put ffmpeg+libfaac into an "app" because of license problems.
2016-09-30 0:33 GMT+02:00 wm4 <nfxjfg@googlemail.com>: > On Fri, 30 Sep 2016 00:21:56 +0200 > Michael Niedermayer <michael@niedermayer.cc> wrote: > Also this argument is highly shady Am I correct that it is just a language error that makes you attack another developer personally? Carl Eugen
On 29/09/2016 23:42, Carl Eugen Hoyos wrote: > 2016-09-30 0:33 GMT+02:00 wm4 <nfxjfg@googlemail.com>: >> On Fri, 30 Sep 2016 00:21:56 +0200 >> Michael Niedermayer <michael@niedermayer.cc> wrote: > >> Also this argument is highly shady > > Am I correct that it is just a language error that makes you > attack another developer personally? wm4 didn't attack anyone, they just said that the argument was ambiguous and may benefit from further explanation. -- Josh
On Fri, 30 Sep 2016 00:42:11 +0200 Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > 2016-09-30 0:33 GMT+02:00 wm4 <nfxjfg@googlemail.com>: > > On Fri, 30 Sep 2016 00:21:56 +0200 > > Michael Niedermayer <michael@niedermayer.cc> wrote: > > > Also this argument is highly shady > > Am I correct that it is just a language error that makes you > attack another developer personally? No.
2016-09-30 0:51 GMT+02:00 wm4 <nfxjfg@googlemail.com>: > On Fri, 30 Sep 2016 00:42:11 +0200 > Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: > >> 2016-09-30 0:33 GMT+02:00 wm4 <nfxjfg@googlemail.com>: >> > On Fri, 30 Sep 2016 00:21:56 +0200 >> > Michael Niedermayer <michael@niedermayer.cc> wrote: >> >> > Also this argument is highly shady >> >> Am I correct that it is just a language error that makes you >> attack another developer personally? > > No. Then what do you suggest? Carl Eugen
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 <josh@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.
On 30/09/2016 00:11, Carl Eugen Hoyos wrote: > 2016-09-30 0:51 GMT+02:00 wm4 <nfxjfg@googlemail.com>: >> On Fri, 30 Sep 2016 00:42:11 +0200 >> Carl Eugen Hoyos <ceffmpeg@gmail.com> wrote: >> >>> 2016-09-30 0:33 GMT+02:00 wm4 <nfxjfg@googlemail.com>: >>>> On Fri, 30 Sep 2016 00:21:56 +0200 >>>> Michael Niedermayer <michael@niedermayer.cc> wrote: >>> >>>> Also this argument is highly shady >>> >>> Am I correct that it is just a language error that makes you >>> attack another developer personally? >> >> No. > > Then what do you suggest? > Can we not resort to personal arguments? please. Is it possible to confirm that there are no other encoders which could produce the same issue in movenc as libfaac? Also, related to libfaac would be irrelevant if it were dropped. -- Josh
On Fri, 30 Sep 2016 00:33:54 +0200, wm4 wrote: > I highly doubt anyone will bother with installing and compiling with > libfaac at all. Agreed. From my observations encountering a user with a modern ffmpeg actually encoding with libfaac is a very rare occurance. Compared to other encoders it is virtually unused. The impression I get is those that do are likely copying random, ancient commands.
2016-09-30 1:15 GMT+02:00 Lou Logan <lou@lrcd.com>: > On Fri, 30 Sep 2016 00:33:54 +0200, wm4 wrote: > >> I highly doubt anyone will bother with installing and compiling with >> libfaac at all. > > Agreed. > > From my observations encountering a user with a modern ffmpeg > actually encoding with libfaac is a very rare occurance. Compared > to other encoders it is virtually unused. > > The impression I get is those that do are likely copying random, > ancient commands. The two last sentences seem to contradict each other, no? Carl Eugen
On Fri, 30 Sep 2016 01:17:47 +0200, Carl Eugen Hoyos wrote:
> The two last sentences seem to contradict each other, no?
No.
On Thu, Sep 29, 2016 at 08:12:14PM -0300, James Almer wrote: > On 9/29/2016 7:21 PM, Michael Niedermayer wrote: > > On Thu, Sep 29, 2016 at 09:54:42PM +0100, Josh de Kock wrote: [...] > > > 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. I never talked about bugs in libfaac or bugs in the libfaac wraper, in fact i dont remember any bugs there. What i meant are bugs that use testcases which as part of the testcase used libfaac (libfaac being one of the few options that were available in the past for aac encoding results in it having beenfrequently used) Many bugs are sensitve to changes, for example a bug in a muxer is not unlikely to depend on some of the packet sizes, durations, timestamps, exact initial padding value, ... the closer one can match all that the more likely testing a testcase in a old ticket with a modern ffmpeg actually does a useful test. droping the encoder that was used in such old tickets makes testing the old testcases less meaningfull. Its as if your muxer shows a issue with mpeg1 video and mp3 and you drop these encoders. the muxer might still show the issue with h264 and flac but then it quite possibly wont or it possibly wont with the sample and command line referenced in the ticket or if you want to you could also say that fewer encoders being available limits the broadness/coverage of tests of the muxers and core and each encoder (not specific to aac encoders) does likely have its peculiarities. or you could see it as in I and carl test old tickets for regression these old tickets used libfaac. libfaacs removial will make such regression tests less meaningfull as the bugs are less likely to reproduce with a different encoder. [...]
> 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. > 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 Isn't it possible to just generate raw aac, or some other low level container format, with faac, and store those as fate samples? Or does that not show the same issue, so that the tests can stay even without libfaac itself?
On 29 September 2016 at 21:54, Josh de Kock <josh@itanimul.li> 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 <josh@itanimul.li> > --- > > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Hi, Thanks for the patch, I'll push it tomorrow. Enough discussions have taken place that dealing with the aftermath of removing it will actually be easier than continuing the 6 month discussions that have been taking place. Our decoder is much faster than it (using the -aac_coder fast option) and still has much much better quality. Testcases are useless because libfaac does nothing right, especially in terms of bitstream compliance. And like wm4 mentioned, libfaac has license issues too.
On Fri, 30 Sep 2016 14:16:40 +0100 Rostislav Pehlivanov <atomnuker@gmail.com> wrote: > On 29 September 2016 at 21:54, Josh de Kock <josh@itanimul.li> 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 <josh@itanimul.li> > > --- > > > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > Hi, > > Thanks for the patch, I'll push it tomorrow. > Enough discussions have taken place that dealing with the aftermath of > removing it will actually be easier than continuing the 6 month discussions > that have been taking place. > Our decoder is much faster than it (using the -aac_coder fast option) and > still has much much better quality. Testcases are useless because libfaac > does nothing right, especially in terms of bitstream compliance. And like > wm4 mentioned, libfaac has license issues too. I support this. Good luck.
On Fri, Sep 30, 2016 at 10:33:04AM +0200, Timo Rothenpieler wrote: > > 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. > > 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 > > Isn't it possible to just generate raw aac, or some other low level > container format, with faac, and store those as fate samples? It is probably possible for some cases and it would be a good idea either way, but iam not sure theres a volunteer to do this. btw, I think the most suitable and flexible format for this is the ffprobe one requiring the ffprobe demuxer patch It would allow all kinds of transformations to be done with a minimum of work to create more minimal test cases. > Or does that not show the same issue, so that the tests can stay even > without libfaac itself? Theres no way i can really say how hundreads of tickets behave if they are turned from encoding into stream copy. My guess is that for many that would work for some it would probably not work [...]
On 30 September 2016 at 18:12, Michael Niedermayer <michael@niedermayer.cc> wrote: > On Fri, Sep 30, 2016 at 10:33:04AM +0200, Timo Rothenpieler wrote: > > > 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. > > > 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 > > > > Isn't it possible to just generate raw aac, or some other low level > > container format, with faac, and store those as fate samples? > > It is probably possible for some cases and it would be a good idea > either way, but iam not sure theres a volunteer to do this. > > I'll do it, just post links to the tickets.
On Fri, Sep 30, 2016 at 08:00:53PM +0100, Rostislav Pehlivanov wrote: > On 30 September 2016 at 18:12, Michael Niedermayer <michael@niedermayer.cc> > wrote: > > > On Fri, Sep 30, 2016 at 10:33:04AM +0200, Timo Rothenpieler wrote: > > > > 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. > > > > 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 > > > > > > Isn't it possible to just generate raw aac, or some other low level > > > container format, with faac, and store those as fate samples? > > > > It is probably possible for some cases and it would be a good idea > > either way, but iam not sure theres a volunteer to do this. > > > > > I'll do it, just post links to the tickets. I dont have a list of tickets that used libfaac and iam not sure how to search for them you can find some by searching for "-> libfaac" "-> aac (libfaac)" This will only work when that part of the output was quoted in the ticket, like in tickets with full uncut output. Iam not sure this covers all ffmpeg versions either the more tickets can be turned into fate tests the better, libfaac or not. Also i do not object to libfaacs removial i just was trying to point out the disadvantages i saw if its done. As you surely noiced i rarely am a supporter of removing features ... Thanks [...]
On 30 September 2016 at 14:16, Rostislav Pehlivanov <atomnuker@gmail.com> wrote: > > > On 29 September 2016 at 21:54, Josh de Kock <josh@itanimul.li> 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 <josh@itanimul.li> >> --- >> >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > > > Hi, > > Thanks for the patch, I'll push it tomorrow. > Enough discussions have taken place that dealing with the aftermath of > removing it will actually be easier than continuing the 6 month discussions > that have been taking place. > Our decoder is much faster than it (using the -aac_coder fast option) and > still has much much better quality. Testcases are useless because libfaac > does nothing right, especially in terms of bitstream compliance. And like > wm4 mentioned, libfaac has license issues too. > Pushed I'm looking at trac to see what needs a faac sample as a fate test, but if anyone's bored they're welcome to join me :)
diff --git a/Changelog b/Changelog index d7f5dc9..2c2f32d 100644 --- a/Changelog +++ b/Changelog @@ -36,6 +36,7 @@ version <next>: - sdl2 support for ffplay - sdl1 output device and sdl1 support removed - extended mov edit list support +- libfaac encoder removed version 3.1: diff --git a/LICENSE.md b/LICENSE.md index d08c747..a384fa0 100644 --- a/LICENSE.md +++ b/LICENSE.md @@ -115,8 +115,6 @@ The Fraunhofer FDK AAC and OpenSSL libraries are under licenses which are incompatible with the GPLv2 and v3. To the best of our knowledge, they are compatible with the LGPL. -The FAAC library is incompatible with all versions of GPL and LGPL. - The NVENC library, while its header file is licensed under the compatible MIT license, requires a proprietary binary blob at run time, and is deemed to be incompatible with the GPL. We are not certain if it is compatible with the diff --git a/configure b/configure index 899057d..4313b7d 100755 --- a/configure +++ b/configure @@ -225,7 +225,6 @@ External library support: and libraw1394 [no] --enable-libebur128 enable libebur128 for EBU R128 measurement, needed for loudnorm filter [no] - --enable-libfaac enable AAC encoding via libfaac [no] --enable-libfdk-aac enable AAC de/encoding via libfdk-aac [no] --enable-libflite enable flite (voice synthesis) support via libflite [no] --enable-libfontconfig enable libfontconfig, useful for drawtext filter [no] @@ -1487,7 +1486,6 @@ EXTERNAL_LIBRARY_LIST=" libcelt libdc1394 libebur128 - libfaac libfdk_aac libflite libfontconfig @@ -2772,8 +2770,6 @@ pcm_mulaw_at_encoder_select="audio_frame_queue" chromaprint_muxer_deps="chromaprint" h264_videotoolbox_encoder_deps="videotoolbox_encoder pthreads" libcelt_decoder_deps="libcelt" -libfaac_encoder_deps="libfaac" -libfaac_encoder_select="audio_frame_queue" libfdk_aac_decoder_deps="libfdk_aac" libfdk_aac_encoder_deps="libfdk_aac" libfdk_aac_encoder_select="audio_frame_queue" @@ -5071,7 +5067,6 @@ die_license_disabled gpl x11grab die_license_disabled nonfree cuda die_license_disabled nonfree cuvid -die_license_disabled nonfree libfaac die_license_disabled nonfree libnpp enabled gpl && die_license_disabled_gpl nonfree libfdk_aac enabled gpl && die_license_disabled_gpl nonfree openssl @@ -5681,7 +5676,6 @@ enabled libcelt && require libcelt celt/celt.h celt_decode -lcelt0 && die "ERROR: libcelt must be installed and version must be >= 0.11.0."; } enabled libcaca && require_pkg_config caca caca.h caca_create_canvas enabled libebur128 && require ebur128 ebur128.h ebur128_relative_threshold -lebur128 -enabled libfaac && require2 libfaac "stdint.h faac.h" faacEncGetVersion -lfaac enabled libfdk_aac && { use_pkg_config fdk-aac "fdk-aac/aacenc_lib.h" aacEncOpen || { require libfdk_aac fdk-aac/aacenc_lib.h aacEncOpen -lfdk-aac && warn "using libfdk without pkg-config"; } } diff --git a/doc/encoders.texi b/doc/encoders.texi index 73ebd9c..1f4044e 100644 --- a/doc/encoders.texi +++ b/doc/encoders.texi @@ -612,111 +612,6 @@ and slightly improves compression. @end table -@anchor{libfaac} -@section libfaac - -libfaac AAC (Advanced Audio Coding) encoder wrapper. - -This encoder is of much lower quality and is more unstable than any other AAC -encoders, so it's highly recommended to instead use other encoders, like -@ref{aacenc,,the native FFmpeg AAC encoder}. - -This encoder also requires the presence of the libfaac headers and library -during configuration. You need to explicitly configure the build with -@code{--enable-libfaac --enable-nonfree}. - -@subsection Options - -The following shared FFmpeg codec options are recognized. - -The following options are supported by the libfaac wrapper. The -@command{faac}-equivalent of the options are listed in parentheses. - -@table @option -@item b (@emph{-b}) -Set bit rate in bits/s for ABR (Average Bit Rate) mode. If the bit rate -is not explicitly specified, it is automatically set to a suitable -value depending on the selected profile. @command{faac} bitrate is -expressed in kilobits/s. - -Note that libfaac does not support CBR (Constant Bit Rate) but only -ABR (Average Bit Rate). - -If VBR mode is enabled this option is ignored. - -@item ar (@emph{-R}) -Set audio sampling rate (in Hz). - -@item ac (@emph{-c}) -Set the number of audio channels. - -@item cutoff (@emph{-C}) -Set cutoff frequency. If not specified (or explicitly set to 0) it -will use a value automatically computed by the library. Default value -is 0. - -@item profile -Set audio profile. - -The following profiles are recognized: -@table @samp -@item aac_main -Main AAC (Main) - -@item aac_low -Low Complexity AAC (LC) - -@item aac_ssr -Scalable Sample Rate (SSR) - -@item aac_ltp -Long Term Prediction (LTP) -@end table - -If not specified it is set to @samp{aac_low}. - -@item flags +qscale -Set constant quality VBR (Variable Bit Rate) mode. - -@item global_quality -Set quality in VBR mode as an integer number of lambda units. - -Only relevant when VBR mode is enabled with @code{flags +qscale}. The -value is converted to QP units by dividing it by @code{FF_QP2LAMBDA}, -and used to set the quality value used by libfaac. A reasonable range -for the option value in QP units is [10-500], the higher the value the -higher the quality. - -@item q (@emph{-q}) -Enable VBR mode when set to a non-negative value, and set constant -quality value as a double floating point value in QP units. - -The value sets the quality value used by libfaac. A reasonable range -for the option value is [10-500], the higher the value the higher the -quality. - -This option is valid only using the @command{ffmpeg} command-line -tool. For library interface users, use @option{global_quality}. -@end table - -@subsection Examples - -@itemize -@item -Use @command{ffmpeg} to convert an audio file to ABR 128 kbps AAC in an M4A (MP4) -container: -@example -ffmpeg -i input.wav -codec:a libfaac -b:a 128k -output.m4a -@end example - -@item -Use @command{ffmpeg} to convert an audio file to VBR AAC, using the -LTP AAC profile: -@example -ffmpeg -i input.wav -c:a libfaac -profile:a aac_ltp -q:a 100 output.m4a -@end example -@end itemize - @anchor{libfdk-aac-enc} @section libfdk_aac diff --git a/doc/ffserver.conf b/doc/ffserver.conf index 7a30fb6..e3f99bb 100644 --- a/doc/ffserver.conf +++ b/doc/ffserver.conf @@ -317,7 +317,7 @@ StartSendOnKey #AVPresetVideo baseline #AVOptionVideo flags +global_header # -#AudioCodec libfaac +#AudioCodec aac #AudioBitRate 32 #AudioChannels 2 #AudioSampleRate 22050 diff --git a/doc/general.texi b/doc/general.texi index a0f1122..f08c3cd 100644 --- a/doc/general.texi +++ b/doc/general.texi @@ -887,7 +887,7 @@ following image formats are supported: @item 8SVX exponential @tab @tab X @item 8SVX fibonacci @tab @tab X @item AAC @tab EX @tab X - @tab encoding supported through internal encoder and external libraries libfaac and libfdk-aac + @tab encoding supported through internal encoder and external library libfdk-aac @item AAC+ @tab E @tab IX @tab encoding supported through external library libfdk-aac @item AC-3 @tab IX @tab IX diff --git a/doc/muxers.texi b/doc/muxers.texi index 2c937c7..9ec2e31 100644 --- a/doc/muxers.texi +++ b/doc/muxers.texi @@ -1437,9 +1437,9 @@ ffmpeg -i in.mkv -codec copy -map 0 -f segment -segment_list out.csv -segment_fr @item Convert the @file{in.mkv} to TS segments using the @code{libx264} -and @code{libfaac} encoders: +and @code{aac} encoders: @example -ffmpeg -i in.mkv -map 0 -codec:v libx264 -codec:a libfaac -f ssegment -segment_list out.list out%03d.ts +ffmpeg -i in.mkv -map 0 -codec:v libx264 -codec:a aac -f ssegment -segment_list out.list out%03d.ts @end example @item diff --git a/doc/platform.texi b/doc/platform.texi index 21b135f..4729d41 100644 --- a/doc/platform.texi +++ b/doc/platform.texi @@ -314,7 +314,7 @@ These library packages are only available from @uref{http://sourceware.org/cygwinports/, Cygwin Ports}: @example -yasm, libSDL-devel, libfaac-devel, libgsm-devel, libmp3lame-devel, +yasm, libSDL-devel, libgsm-devel, libmp3lame-devel, libschroedinger1.0-devel, speex-devel, libtheora-devel, libxvidcore-devel @end example diff --git a/libavcodec/Makefile b/libavcodec/Makefile index a0413ff..a1560ba 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -862,7 +862,6 @@ OBJS-$(CONFIG_ILBC_AT_ENCODER) += audiotoolboxenc.o OBJS-$(CONFIG_PCM_ALAW_AT_ENCODER) += audiotoolboxenc.o OBJS-$(CONFIG_PCM_MULAW_AT_ENCODER) += audiotoolboxenc.o OBJS-$(CONFIG_LIBCELT_DECODER) += libcelt_dec.o -OBJS-$(CONFIG_LIBFAAC_ENCODER) += libfaac.o OBJS-$(CONFIG_LIBFDK_AAC_DECODER) += libfdk-aacdec.o OBJS-$(CONFIG_LIBFDK_AAC_ENCODER) += libfdk-aacenc.o OBJS-$(CONFIG_LIBGSM_DECODER) += libgsmdec.o diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c index b403bf2..fed740a 100644 --- a/libavcodec/allcodecs.c +++ b/libavcodec/allcodecs.c @@ -594,7 +594,6 @@ void avcodec_register_all(void) REGISTER_DECODER(QDMC_AT, qdmc_at); REGISTER_DECODER(QDM2_AT, qdm2_at); REGISTER_DECODER(LIBCELT, libcelt); - REGISTER_ENCODER(LIBFAAC, libfaac); REGISTER_ENCDEC (LIBFDK_AAC, libfdk_aac); REGISTER_ENCDEC (LIBGSM, libgsm); REGISTER_ENCDEC (LIBGSM_MS, libgsm_ms); diff --git a/libavcodec/libfaac.c b/libavcodec/libfaac.c deleted file mode 100644 index 98b3ba8..0000000 --- a/libavcodec/libfaac.c +++ /dev/null @@ -1,248 +0,0 @@ -/* - * Interface to libfaac for aac encoding - * Copyright (c) 2002 Gildas Bazin <gbazin@netcourrier.com> - * - * This file is part of FFmpeg. - * - * FFmpeg is free software; you can redistribute it and/or - * modify it under the terms of the GNU Lesser General Public - * License as published by the Free Software Foundation; either - * version 2.1 of the License, or (at your option) any later version. - * - * FFmpeg is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * Lesser General Public License for more details. - * - * You should have received a copy of the GNU Lesser General Public - * License along with FFmpeg; if not, write to the Free Software - * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA - */ - -/** - * @file - * Interface to libfaac for aac encoding. - */ - -#include <faac.h> - -#include "libavutil/channel_layout.h" -#include "libavutil/common.h" -#include "avcodec.h" -#include "audio_frame_queue.h" -#include "internal.h" - - -/* libfaac has an encoder delay of 1024 samples */ -#define FAAC_DELAY_SAMPLES 1024 - -typedef struct FaacAudioContext { - faacEncHandle faac_handle; - AudioFrameQueue afq; -} FaacAudioContext; - -static av_cold int Faac_encode_close(AVCodecContext *avctx) -{ - FaacAudioContext *s = avctx->priv_data; - - av_freep(&avctx->extradata); - ff_af_queue_close(&s->afq); - - if (s->faac_handle) - faacEncClose(s->faac_handle); - - return 0; -} - -static const int channel_maps[][6] = { - { 2, 0, 1 }, //< C L R - { 2, 0, 1, 3 }, //< C L R Cs - { 2, 0, 1, 3, 4 }, //< C L R Ls Rs - { 2, 0, 1, 4, 5, 3 }, //< C L R Ls Rs LFE -}; - -static av_cold int Faac_encode_init(AVCodecContext *avctx) -{ - FaacAudioContext *s = avctx->priv_data; - faacEncConfigurationPtr faac_cfg; - unsigned long samples_input, max_bytes_output; - int ret; - - /* number of channels */ - if (avctx->channels < 1 || avctx->channels > 6) { - av_log(avctx, AV_LOG_ERROR, "encoding %d channel(s) is not allowed\n", avctx->channels); - ret = AVERROR(EINVAL); - goto error; - } - - s->faac_handle = faacEncOpen(avctx->sample_rate, - avctx->channels, - &samples_input, &max_bytes_output); - if (!s->faac_handle) { - av_log(avctx, AV_LOG_ERROR, "error in faacEncOpen()\n"); - ret = AVERROR_UNKNOWN; - goto error; - } - - /* check faac version */ - faac_cfg = faacEncGetCurrentConfiguration(s->faac_handle); - if (faac_cfg->version != FAAC_CFG_VERSION) { - av_log(avctx, AV_LOG_ERROR, "wrong libfaac version (compiled for: %d, using %d)\n", FAAC_CFG_VERSION, faac_cfg->version); - ret = AVERROR(EINVAL); - goto error; - } - - /* put the options in the configuration struct */ - switch(avctx->profile) { - case FF_PROFILE_AAC_MAIN: - faac_cfg->aacObjectType = MAIN; - break; - case FF_PROFILE_UNKNOWN: - case FF_PROFILE_AAC_LOW: - faac_cfg->aacObjectType = LOW; - break; - case FF_PROFILE_AAC_SSR: - faac_cfg->aacObjectType = SSR; - break; - case FF_PROFILE_AAC_LTP: - faac_cfg->aacObjectType = LTP; - break; - default: - av_log(avctx, AV_LOG_ERROR, "invalid AAC profile\n"); - ret = AVERROR(EINVAL); - goto error; - } - faac_cfg->mpegVersion = MPEG4; - faac_cfg->useTns = 0; - faac_cfg->allowMidside = 1; - faac_cfg->bitRate = avctx->bit_rate / avctx->channels; - faac_cfg->bandWidth = avctx->cutoff; - if(avctx->flags & AV_CODEC_FLAG_QSCALE) { - faac_cfg->bitRate = 0; - faac_cfg->quantqual = avctx->global_quality / FF_QP2LAMBDA; - } - faac_cfg->outputFormat = 1; - faac_cfg->inputFormat = FAAC_INPUT_16BIT; - if (avctx->channels > 2) - memcpy(faac_cfg->channel_map, channel_maps[avctx->channels-3], - avctx->channels * sizeof(int)); - - avctx->frame_size = samples_input / avctx->channels; - - /* Set decoder specific info */ - avctx->extradata_size = 0; - if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) { - - unsigned char *buffer = NULL; - unsigned long decoder_specific_info_size; - - if (!faacEncGetDecoderSpecificInfo(s->faac_handle, &buffer, - &decoder_specific_info_size)) { - avctx->extradata = av_malloc(decoder_specific_info_size + AV_INPUT_BUFFER_PADDING_SIZE); - if (!avctx->extradata) { - ret = AVERROR(ENOMEM); - goto error; - } - avctx->extradata_size = decoder_specific_info_size; - memcpy(avctx->extradata, buffer, avctx->extradata_size); - faac_cfg->outputFormat = 0; - } - free(buffer); - } - - if (!faacEncSetConfiguration(s->faac_handle, faac_cfg)) { - int i; - for (i = avctx->bit_rate/1000; i ; i--) { - faac_cfg->bitRate = 1000*i / avctx->channels; - if (faacEncSetConfiguration(s->faac_handle, faac_cfg)) - break; - } - if (!i) { - av_log(avctx, AV_LOG_ERROR, "libfaac doesn't support this output format!\n"); - ret = AVERROR(EINVAL); - goto error; - } else { - avctx->bit_rate = 1000*i; - av_log(avctx, AV_LOG_WARNING, "libfaac doesn't support the specified bitrate, using %dkbit/s instead\n", i); - } - } - - avctx->initial_padding = FAAC_DELAY_SAMPLES; - ff_af_queue_init(avctx, &s->afq); - - return 0; -error: - Faac_encode_close(avctx); - return ret; -} - -static int Faac_encode_frame(AVCodecContext *avctx, AVPacket *avpkt, - const AVFrame *frame, int *got_packet_ptr) -{ - FaacAudioContext *s = avctx->priv_data; - int bytes_written, ret; - int num_samples = frame ? frame->nb_samples : 0; - void *samples = frame ? frame->data[0] : NULL; - - if ((ret = ff_alloc_packet2(avctx, avpkt, (7 + 768) * avctx->channels, 0)) < 0) - return ret; - - bytes_written = faacEncEncode(s->faac_handle, samples, - num_samples * avctx->channels, - avpkt->data, avpkt->size); - if (bytes_written < 0) { - av_log(avctx, AV_LOG_ERROR, "faacEncEncode() error\n"); - return bytes_written; - } - - /* add current frame to the queue */ - if (frame) { - if ((ret = ff_af_queue_add(&s->afq, frame)) < 0) - return ret; - } - - if (!bytes_written) - return 0; - - /* Get the next frame pts/duration */ - ff_af_queue_remove(&s->afq, avctx->frame_size, &avpkt->pts, - &avpkt->duration); - - avpkt->size = bytes_written; - *got_packet_ptr = 1; - return 0; -} - -static const AVProfile profiles[] = { - { FF_PROFILE_AAC_MAIN, "Main" }, - { FF_PROFILE_AAC_LOW, "LC" }, - { FF_PROFILE_AAC_SSR, "SSR" }, - { FF_PROFILE_AAC_LTP, "LTP" }, - { FF_PROFILE_UNKNOWN }, -}; - -static const uint64_t faac_channel_layouts[] = { - AV_CH_LAYOUT_MONO, - AV_CH_LAYOUT_STEREO, - AV_CH_LAYOUT_SURROUND, - AV_CH_LAYOUT_4POINT0, - AV_CH_LAYOUT_5POINT0_BACK, - AV_CH_LAYOUT_5POINT1_BACK, - 0 -}; - -AVCodec ff_libfaac_encoder = { - .name = "libfaac", - .long_name = NULL_IF_CONFIG_SMALL("libfaac AAC (Advanced Audio Coding)"), - .type = AVMEDIA_TYPE_AUDIO, - .id = AV_CODEC_ID_AAC, - .priv_data_size = sizeof(FaacAudioContext), - .init = Faac_encode_init, - .encode2 = Faac_encode_frame, - .close = Faac_encode_close, - .capabilities = AV_CODEC_CAP_SMALL_LAST_FRAME | AV_CODEC_CAP_DELAY, - .sample_fmts = (const enum AVSampleFormat[]){ AV_SAMPLE_FMT_S16, - AV_SAMPLE_FMT_NONE }, - .profiles = NULL_IF_CONFIG_SMALL(profiles), - .channel_layouts = faac_channel_layouts, -};
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 <josh@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