| From Michael Niedermayer <michae...@gmx.at> | Wed, 21 May 2014 15:26:21 +0200 | Subject: [Audacity-devel] [Libav-user] Requesting help to port Audacity to recent FFmpeg > On Wed, May 21, 2014 at 01:39:46AM +0100, Martyn Shaw wrote: > > Thanks Richard, I think you have made a good summary here. > > > > Audacity is attempting to make itself independent of the changes in > > libav and ffmpeg by using Gstreamer as a third-party. I support that > > (for now at least). We want the functionality without the hassle. > > understood, though about the "mess" some of the changes in the API > where needed so the codec can give you a buffer of the right size > instead of failing if the one you allocated was too small, > You wouldnt want to keep using an API that has such limitations, > and thats also just a one time fix, once that part of the API > is fixed it wont need to be fixed again. > > And then your interface code to ffmpeg was and is alot more complex > than needed, for example the whole use of url protocol wasnt > needed (which was one thing that needed an update API wise and yes > this one resulted out of libav-ffmpeg fork mess, there was no > reason to make that API private) > but then again audacity had no need to use any of this api, and the > code is simpler without using it as well > > Then there was the ffmpeg format probing code in audacity, i dont > understand why this was put there, the code is alot simpler without > it and ffmpeg will do the probing for you without that code. > Ive removed that too on the github clone and that change isnt api > update related it was just simplifying the audacity-ffmpeg interface > code. > And i suspect theres alot more that can be simplified in it, and the > amount of "api-hassle" there would be in the future should be alot > less when the interface is using only what it actually needs to
Michael, So do you envisage Audacity could treat the "simple, long term stable" FFmpeg API/subset as "third-party", in the way that we we hope to treat "GStreamer"? That is - almost no maintenance would be needed by Audacity even if new stable-supported FFmpeg features were added? How would this choice be presented to users - as "bleeding edge" for GStreamer, versus "safer" for FFmpeg? Could the Audacity GUI for import and export be identical, whether GStreamer or FFmpeg was chosen by the user? Gale > > On 20/05/2014 09:14, Richard Ash wrote: > > > On Wed, 14 May 2014 19:27:38 +0200 > > > Michael Niedermayer <michae...@gmx.at> wrote: > > >> On Sun, May 11, 2014 at 09:16:29PM +0200, Benjamin Drung wrote: > > >>> That's why I send this mail to this mailing list to request help. Is > > >>> there anyone who has the time and skill to help porting Audacity to > > >>> the latest FFmpeg API version? > > >>> > > >>> [1] http://bugzilla.audacityteam.org/show_bug.cgi?id=606 > > > > > > I think I'm right in saying that no-one on the audacity-devel list was > > > specifically aware of this work/request (or I might have said something > > > earlier). > > > > > > As a result of this problem, one of the Audacity contributors, Leyland > > > Lucius, has been perusing the use of Gstreamer as an abstraction layer > > > for ffmpeg. This work has recently arrived in Audacity SVN, so you > > > should be able to see where it is at (it isn't working for me, but I > > > don't think it's Leyland's fault). > > > > > > The rationale for doing this is that the Gstreamer 1.0 API is much more > > > stable than the libAV one, and there is an (actively maintained) > > > gst-plugin-libav which provides the functionality of libAV through that > > > API. Thus the problem of providing up-to-date builds of libAV is > > > reduced, and an abstraction layer is provided. > > > > > > This also has the benefit of allowing (in principal) any other codecs > > > which are supported in Gstreamer (or by plugins for it) to be added to > > > Audacity relatively easily. This is something we hope to make modular, > > > so that it doesn't need a complete new build of audacity to use new > > > gstreamer plug-ins, and every download of Audacity doesn't have to ship > > > with every possible codec library. > > > > > > > > > > > > Richard > > > _______________________________________________ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user
