Re: [Audacity-devel] audacity and ffmpeg 0.5

[Richard A. <ri...@au...>]

On Fri, 2009-08-21 at 04:22 +0400, LRN wrote:
> > I worked on getting audacity 1.3.8 into Debian/Ubuntu. There is one
> > blocking issue: audacity does not support the version of ffmpeg wich is
> > in Debian/Ubuntu. I tried to make it compatible, but I failed.
> >   
> Damn, this ffmpeg 0.5 is probably the worst thing that could have
> happened to me. I just spoke to a few guys on #ffmpeg and they have told
> me that releasing 0.5.1 is not a priority. That is, the features of
> post-0.5 trunk that i wanted (namely - opencore) are not going to appear
> in a stable form for...some unknown period of time. And all the while
> distro maintainers will stick to 0.5 as long as they can. Stubborn lot
> they are. But can't blame them.
> 
> Now, about hacking Audacity. I think you're doing it wrong. Audacity
> have worked with pre-0.5 (which, basically, is 0.5 in terms of the API,
> at least it's much more compatible to 0.5), so maybe it's better to dig
> back into CVS and...uh...how would you call it? Forward-port? Because
> it's not a backport, IMHO.
> What has to be done is:
> Pull avcodec_version, avformat_version and avutil_version
> Get version numbers.
> Pull other functions, depending on version numbers.
> Continue to use different pieces of code for different versions.
> 
> To do that one would need to use a set of FFmpeg headers that are
> compatible with all versions that are handled at runtime (which should,
> at this moment, be 0.5 and one of the post-0.5 versions, can't give you
> the exact numbers right now). This may require a some header hacking (at
> the moment all headers are taken directly from ffmpeg repository without
> alterations).
> 
> It's slightly easier to decide which version is supported at compile
> time with #ifdef's, but Audacity is in unique position, it IS able load
> whatever is available and decide at runtime. It could be worth the effort.
> 
> Actually, i foresee that this compatibility issue is not going to be
> resolved, even if 0.5.1 comes out, so here's a question for all the
> Audacity developers: runtime compatibility or compile-time compatibility?

I think compile-time compatibility is adequate if we can manage some
sensible messages when we aren't loading ffmpeg because it's
incompatible (probably based on trying to get the version of what is
being supplied somehow?). My logic is this:

* For non-linux users, the headers used will be those in the Audacity
source tree, and they will be downloading our (well, LRN's) build of
ffmpeg to go with it. This will obviously track development reasonably
actively, at least until more of the features we would like to use are
working. They don't care about 0.50 at all.
* For Linux users, the configure script will detect the presence of
system ffmpeg (via pkgconfig) and attempt to use those headers in
preference to the local ones. Assuming that the headers installed match
the binaries installed (which is someone else's fault if it isn't true),
then we should as far as reasonable build a version of Audacity that
uses the installed version of ffmpeg. If the installed version of the
library changes, then rebuilding Audacity is a reasonable thing to have
to do (they will have to rebuild all the other applications using ffmpeg
anyway).

Distributions that have ffmpeg available should always build Audacity
with ffmpeg installed and so the headers available (it's a
straightforward dependency), so the resulting binary should match the
libraries they are shipping. Those that don't will disable ffmpeg
completely anyway to avoid using the headers as well, so we can't do
much about that.

For end users building audacity, they simply need to install ffmpeg (and
it's development package if required) before they try to build Audacity,
and it should "just work".

Ideally, I think compiling Audacity should require that all the
functions we are going to import are declared in the ffmpeg headers we
are compiling against, thus ensuring that trying to build audacity
against too old a version of ffmpeg will fail at compile time, and
conversely that using newer headers will show up any functions whoose
signatures have changed. This should never happen to end users, because
we can set the required versions of libavformat, libavcodec and
libavutil in the configure script to the minimum version known to work,
or if necessary provide two acceptable values, one for 0.5 and one for
the currently supported HEAD version. This will ensure that if they have
unusable ffmpeg headers they are ignored at configure time. For
developers however it will make it more obvious when we need to adapt
our code to cope with what the ffmpeg developers are throwing at us.

Given this scenario, we can use the values of LIBAVCODEC_VERSION_MAJOR,
LIBAVCODEC_VERSION_MINOR, LIBAVCODEC_VERSION_MICRO and so on in the
headers to control what we try to build at compile time. At run time, we
just need to get the library version and check it is what we were hoping
for as we do now.

Richard