Re: [Audacity-devel] [Libav-user] Requesting help to port Audacity to recent FFmpeg

[Gale A. <ga...@au...>]

| From Michael Niedermayer <mic...@gm...> 
| 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 <mic...@gm...> 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
> > >