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

[wm4]

On Tue, 20 May 2014 19:17:07 +0200
Michael Niedermayer <michaelni at gmx.at> wrote:

> Hi
> 
> On Tue, May 20, 2014 at 09:14:33AM +0100, Richard Ash wrote:

> > 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 ...

Definitely there would be interest in such a thing all over the place.
IMO the main problem with libavcodec etc. is that they provide a very
low-level API. This is fine for API users which need it, but for
everyone else this causes a load of complexity which would otherwise
not be needed. For example, not many API users care about the
separation of decoder and demuxer, but on the other hand connecting
these can be hard work. Likewise, writing code to convert the output
using libswscale etc. is additional work that could be avoided by a
high-level API.

Here's some quick brainstorming what a high-level API could look like
in the decoding case:

av_decoder *dec = av_decoder_open("somefile.mp3");
av_decoder_set_audio_format(dec, AV_SAMPLE_FMT_S16);
av_decoder_set_audio_rate(dec, 48000);
av_decoder_set_audio_channels(dec, AV_CH_LAYOUT_STEREO);
av_decoder_set_audio_filters(dec, "aecho,earwax");
// Decode all data from stream 0
while ((AVFrame *data = av_decoder_decode(dec, 0)) {
    do_something(data->data[0], data->nb_samples);
}

This is all what many API users will need. Now imagine how much (broken)
boilerplate you'd have to write to get this, and how much of it will
break with future API changes.

Obviously this example is naive and would need some refinement, and I'm
not sure how encoding would work; I'm just saying it can be done.

In particular, I think there should be a high interest to get people
away from gstreamer - mostly because it turns out that gstreamer's
ffmpeg wrapper is pretty buggy overall, and users should be _not_
forced to use that just for the sake for a more stable API.