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

[Michael Niedermayer]

Hi

On Thu, May 22, 2014 at 04:57:43AM +0100, Gale Andrews wrote:
> 
> | From Michael Niedermayer <michaelni at 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 <michaelni at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/libav-user/attachments/20140523/d3cb89dc/attachment.asc>