FFmepg rebuild Schedule ?

[Hans de Goede]

Hi,

I've done a local rebuild of the ffmpeg stack to prepare and test my packages
for the ffmpeg bump.

audacious-plugins-freeworld is committed and ready to build as soon as the
new ffmpeg is in place

gstreamer-ffmpeg is a problem, as upstream is using/supporting only libav and not
ffmpeg, and the 2 seem to have grown apart quite a bit API wise with the last ffmpeg
release. I've been looking at patching gstreamer-ffmpeg to build with ffmpeg rather
then libav, but the 2 really have grown too far apart, requiring too many changes,
which will surely introduce a lot of bugs.

Some examples of the issues are:
-ffmpeg no longer has URLProtocol and av_register_protocol publicly available, they
are still used internally so I've hacked around this, but this hack will require some
changes to our ffmpeg packages, to make the interfaces public again.
-AVCodec no longer has a palettectrl member, instead the palette now is passed as
  data[1] to image read/write functions. Supporting this model requires major surgery
  to gstreamer-ffmpeg

So we've 4 options:

1) Try to patch gstreamer-ffmpeg to build with new ffmpeg, tried and failed
2) Build gstreamer-ffmpeg with an old ffmpeg-compat. May work for now, but seems like
a dead end in the long run, as I'm sure we don't want to have an ffmpeg-compat
stick around for ever, and having one stick around for ever would seem like a bad
idea from a security pov.
3) Build gstreamer-ffmpeg with its bundled libav copy, this is actually the advised
way to ship gstreamer-ffmpeg by upstream.
4) Package libav in such a way that it is parallel installable to ffmpeg, use a system
libav with gstreamer-ffmpeg

For now I believe that 3. is the best solution, if we get more packages which only work
with libav and not with with ffmpeg we can move to 4. Alternatively if upstream libav
starts making similar API changes as ffmpeg, and gstreamer-ffmpeg moves to the new
API's we could try 1. again.

Regards,

Hans