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

[Michael Niedermayer]

Hi

On Tue, May 20, 2014 at 11:41:53PM +0200, Benjamin Drung wrote:
[...]
> > > 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).
> > 
> > I wasnt aware of that, but still is there no interrest in directly
> > supporting FFmpeg ?
> 
> The lacking interest in continue supporting FFmpeg was caused by the
> missing manpower to keep Audacity updated against the changing API of
> FFmpeg.
> 
> I assume that no Audacity will be against having FFmpeg support in the
> source code if this support is kept up-to-date.

> I like to commit your
> work to the Audacity SVN so that we have both - support for FFmpeg and
> Gstreamer.

that sounds great


> 
> > Also i just fixed planar export & put the disabled options back so
> > my github should contain a audacity that fully works with latest
> > ffmpeg, of course there will be bugs but iam happy to fix them if
> > they get reported to me ...
> 
> I tested your patches with FFmpeg 2.2.1-2 on Ubuntu 14.04 with the
> --disable-dynamic-loading configure flag. To succeed compiling, I had to
> apply the attached 0001*.patch.

applied that one to my tree, should i apply other fixes from you there
too or wait until they reach upstream svn ?


[...]
> I found some issues:
> 
> 1) There was a debugging line left in the code: fprintf(stderr, "READ %d
> ret %d\n", size, ret);

fixed


> 
> 2) I can't export audio as mp4. Neither as mp4 export, nor as custom
> FFmpeg export (can't be selected there). FFmpeg has mp4 support enabled:
> 
> $ ffmpeg -formats 2>/dev/null | grep mp4
>  D  mov,mp4,m4a,3gp,3g2,mj2 QuickTime / MOV
>   E mp4             MP4 (MPEG-4 Part 14)

hmmm, what do you mean by "mp4" ?
there are alot of audio codecs that can be stored in mp4, for example
aac, mp3, vorbis, also there are multiple ways to encode aac, libfaac
ffmpegs native encoder and a few others ...

I tried a few things and found a few bugs (which i fixed) but iam
not convinced i fixed the issue you describe


> 
> 
> > >
> > > 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.
> > 
> > Iam quite aware of the API stability issues in our API.
> > Its a result of FFmpeg supporting all features and bugfixes as well
> > as to be API compatible to the fork (libav) and that changing the API
> > all the time.
> > 
> > One question here would be if there would be interrest if FFmpeg would
> > provide a seperate simple API which isnt designed to be as efficient
> > as possible and which makes no attempt to be compatible with libav.
> > such API could then be long term stable
> > ?
> > This idea did come up already a few times IIRC. Just noone imlpemented
> > it yet, but the more people support the idea the more likely someone
> > will sit down and write it ...
> 
> IMO it would make sense to have a subset of the API (it doesn't have to
> be a separate API) where you promise long term stability.

thats tricky
for example all the current API works based on AVPackets
and for example libav plans to remove the destruct callback from
AVPackets
so any subset would break
sure we could just keep the destruct callback and ignore libav removing
it but AVPackets are part of the public API & ABI and if we do that
then ffmpeg would not be ABI compatible with libav anymore which we
mostly are currently.


> 
> > > 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.
> 
> Are there really codecs that are supported by Gstreamer, but not by
> FFmpeg?

I dont know, is there a list of codecs which Gstreamer supports
somewhere ?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/libav-user/attachments/20140521/d282bba0/attachment.asc>