Hi On Thu, May 22, 2014 at 04:57:43AM +0100, Gale Andrews wrote: > > | 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?
yes, this would be the idea behind such API > > How would this choice be presented to users - as "bleeding edge" > for GStreamer, versus "safer" for FFmpeg? I dont really know > > Could the Audacity GUI for import and export be identical, whether > GStreamer or FFmpeg was chosen by the user? iam no GUI programmer nor a gstreamer one and the FFmpeg LTS-API doesnt exist yet, but after thinking about it for an hour now, it is maybe not so hard to create such stable/subset API > > > > 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 > > > > > -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire
signature.asc
Description: Digital signature
_______________________________________________ Libav-user mailing list Libav-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/libav-user