Bugzilla – Bug 233
Option to link against system lame and ffmpeg
Last modified: 2018-08-20 11:51:26 UTC
On Linux we don't need to load dynamically (dlopen) lame and ffmpeg. Instead we prefer to compile audacity using system libraries. If we compile audacity using system libraries, it will be easier to detect and fix bugs like #176. Edit -> Preferences... -> Libraries can be removed then.
(In reply to comment #0) You mean you can remove Edit > Preferences: Libraries if defined wxGTK? They can't be removed on windows/Mac, I think. FFmpeg is not autodetected yet (bug 141) and even when it is, users still sometimes need to browse (or prefer not to use the library location Audacity specifies). Plus they can download the libraries from that Prefs pane.
I mean to have an configure flag for compiling audacity against the system lame and ffmpeg. If this flag is enable, audacity should drop the dlopen part and just link against the system libraries. If this flag is enabled, Edit > Preferences: Libraries should be disabled.
A bug was filed in Debian: http://bugs.debian.org/600747
Created attachment 64 [details] audacity-ffmpeg.patch Attached the patch that allows compiling against system ffmpeg (and dropping dlopen part) if USE_SYSTEM_FFMPEG is set. If USE_SYSTEM_FFMPEG is not set, everything should behave like before. This patch needs some improvements: 1a. autoconf part: There should be a configure flag for setting USE_SYSTEM_FFMPEG. Currently I set it manually after ./configure with: echo "#define USE_SYSTEM_FFMPEG 1" >> src/configunix.h 1b. Following line should only be set if USE_SYSTEM_FFMPEG is defined: FFMPEG_SYSTEM_LIBS="$AVCODEC_LIBS $AVFORMAT_LIBS" 2. The patch compiles and audacity starts. When using USE_SYSTEM_FFMPEG, no ffmpeg format is detected.
(In reply to comment #4) > The patch compiles and audacity starts. When using USE_SYSTEM_FFMPEG, no > ffmpeg format is detected. Is this the problem most people get when they compile FFmpeg > 0.5 themselves? http://forum.audacityteam.org/viewtopic.php?f=18&t=39251&p=119648#p114553
> Is this the problem most people get when they compile FFmpeg > 0.5 themselves? > http://forum.audacityteam.org/viewtopic.php?f=18&t=39251&p=119648#p114553 No, because the linking will fail if an unknown symbol is used. I hit this linking error and applied the patch from bug #176.
Created attachment 65 [details] audacity-system-ffmpeg3.patch Here's an updated patch. It fixes all issues described above. I forgot to initialize the FFmpeg library if the dynamic loading was disabled. This patch has a proper configure integration. After applying the patch, you need to make autogen.sh executable and run autogen.sh to regenerate the configure script. Everything should behave like before unless you pass --disable-dynamic-loading to configure. If you run configure with --disable-dynamic-loading, the dynamic loading of FFmpeg will be disabled and audacity will be linked against the system FFmpeg. My patch includes the bug fix for bug #176 and I added more #ifdefs for deprecated FFmpeg functions.
Created attachment 66 [details] audacity-system-ffmpeg4.patch Updated audacity-system-ffmpeg4.patch attached. This patch works on Debian unstable and Ubuntu 11.04 (natty). Two things are changes: 1) FFmpeg.h declares match_ext for FFmpeg 0.5 (because audacity uses this internal function). 2) audacity_checklib_ffmpeg.m4 checks for libavutil too, because libavutil is required too.
(In reply to comment #7) > After applying the patch, you need to make autogen.sh executable and run > autogen.sh to regenerate the configure script. I applied the patch (only) but I don't know which autogen.sh file you mean. I have eight files with this name in various parts of the Audacity tree but none seem relevant to FFmpeg. And when I find it and make it executable, what do I type from which location?
Created attachment 67 [details] audacity-system-ffmpeg5.patch > I applied the patch (only) but I don't know which autogen.sh file you mean. > And when I find it and make it executable, what do I type from which location? autogen.sh was part of the patch. I lost it in version 4. Attached is version 5 with autogen.sh in it. It does nothing else than calling aclocal and autoconf with the correct parameters (because I always forget the commands). patch -p0 < audacity-system-ffmpeg5.patch chmod +x autogen.sh ./autogen.sh
From http://tinyurl.com/4goaj6p: >> Richard: We have never asked the FFmpeg team whether they are happy for GPL >> builds to be linked against Audacity with it's binary plug-in support... >> we don't do the things they ask for (http://ffmpeg.org/legal.html) > Benjamin: My patch allows build-time linkage, but it would be still dynamic > linked (just not using dlopen). I don't think the enhancement in bug 233 can go ahead unless we do ask. Even then there may be questions if we want Audacity to (have the capability to) behave differently on different platforms. I usually favour flexibility in these cases, but should the user be completely denied the dlopen method to a different version of FFmpeg through the Preferences (or would Auadacity refuse that other version)? If we resolve 233 "wontfix" we should still address bug 176 on its own, though I could not make Audacity accept self-compiled FFmpeg using the patch attached to that bug.
From http://tinyurl.com/4goaj6p: >>> Richard: We have never asked the FFmpeg team whether they are happy for GPL >>> builds to be linked against Audacity with it's binary plug-in support... >>> we don't do the things they ask for (http://ffmpeg.org/legal.html) >> Benjamin: My patch allows build-time linkage, but it would be still dynamic >> linked (just not using dlopen). > I don't think the enhancement in bug 233 can go ahead unless we do ask. My patch doesn't change anything regarding licensing. Currently Audacity is linked dynamical to FFmpeg and can be shipped separated due to dlopen. With the patch it is possible to disable the dlopen part and just link dynamical (if the configure flag --disable-dynamic-loading is used). If there is a problem with Audacity's binary plug-in support and FFmpeg, it is unrelated to my patch. > Even then there may be questions if we want Audacity to (have the capability > to) behave differently on different platforms. It's a nice feature for distributions to make audacity work smoothly with the FFmpeg version provided by the distribution. > I usually favour flexibility in these cases, but should the user be > completely denied the dlopen method to a different version of FFmpeg through > the Preferences (or would Auadacity refuse that other version)? If audacity is compiled with --disable-dynamic-loading, the user can only use the FFmpeg version which it was compiled with (or a binary compatible one). If audacity is compiled without --disable-dynamic-loading, the user can select a FFmpeg version to dlopen. If a distribution uses --disable-dynamic-loading, audacity will work with the FFmpeg package from the distribution and the users have to do no configuration. They can replace the package by a compatible one. The user can compile FFmpeg trunk and install in locally and then compile audacity with --disable-dynamic-loading against their local version. > If we resolve 233 "wontfix" we should still address bug 176 on its own, though > I could not make Audacity accept self-compiled FFmpeg using the patch attached > to that bug. That should be possible. If audacity is compiled and linked against the wrong FFmpeg version, you probably have to play with configure.
Created attachment 71 [details] audacity-system-ffmpeg6.patch Updated patch to make it apply to the latest svn revision.
Created attachment 93 [details] audacity-system-ffmpeg7.patch Refreshed and replaced USE_SYSTEM_FFMPEG by DISABLE_DYNAMIC_LOADING_FFMPEG.
(In reply to comment #14) A user e-mailed to request that we consider applying this patch as it would help his distro (openSUSE}.
Created attachment 196 [details] disable-dynamic-ffmpeg.patch Here's the updated patch that we use in Debian/Ubuntu to disable the dynamic loading of FFmpeg.
Created attachment 197 [details] disable-dynamic-lame.patch Here is the second patch that does the same for LAME. The second patch needs the first patch to work.
What prevents you from applying the proposed patches? They do not have any effect on Windows or Mac. They do not have any effect on Linux unless --disable-dynamic-loading is specified as configure flag. With --disable-dynamic-loading specified, the FFmpeg and LAME version of the system will be used. The user looses the option to disable FFmpeg or LAME. The user can still change the used FFmpeg or LAME version by installing a different version into /usr/local for example.
(In reply to comment #18) Does Ubuntu 12.04 use FFmpeg for their Audacity package or is it linking with avconv (which seems the same thing, renamed)? I see terminal warnings that FFmpeg is "not developed anymore... use avconv instead." So is this patch still valid?
Debian and Ubuntu uses libav instead of FFmpeg. libav is a fork of FFmpeg. Both projects are still active and in development. The fork was created due to disagreements beyond the developers of FFmpeg. It is not clear, which project will be superior. The libav team deprecated the command line tool 'ffmpeg' and recommend to use 'libav' instead. This is totally unrelated to the library which is used by Audacity. Audacity can use FFmpeg or libav. The proposed patches do not have any effect on the FFmpeg/libav issue.
Created attachment 267 [details] disable-dynamic-ffmpeg.patch Here are the refreshed patches for 2.0.1 with a TortoiseSVN friendly strip level 0.
Created attachment 268 [details] disable-dynamic-lame.patch
Created attachment 269 [details] disable-dynamic-lame.patch Another update for disable-dynamic-lame.patch (I forgot to add m4/audacity_checklib_lame.m4 to the patch).
(In reply to comment #21) Thanks. Patches fine. Does not build. Log attached.
Created attachment 271 [details] VC++ errors in applying disable-dynamic-ffmpeg.patch
Applied disable-dynamic-lame.patch. Fixed a couple of compile warnings.
Created attachment 273 [details] disable-dynamic-ffmpeg-v2.patch Here's a fixed version of disable-dynamic-ffmpeg.patch. It builds with and without having --disable-dynamic-loading specified when running configure.
Created attachment 290 [details] use-newer-ffmpeg-function-name.patch
Created attachment 291 [details] disable-dynamic-ffmpeg-v3.patch I spitted the patch into two parts and updated the second part.
(In reply to comment #29) Applied and committed use-newer-ffmpeg-function-name.patch (r11956) and disable-dynamic-ffmpeg-v3.patch (r11957).
AFAICT this is long ago deemed satisfactory so moved to RESOLVED-FIXED. However should Michael's FFmpeg On-Demand Loading (or something else) be added to Libraries Preferences this will need revisiting .
