Re: FFmepg rebuild Schedule ?

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