FFmepg rebuild Schedule ?

[Hans de Goede]

Hi,

On 06/25/2012 11:15 AM, Nicolas Chauvet wrote:
> 2012/6/25 Hans de Goede <j.w.r.degoede at gmail.com>:
>> Hi,
> ..
>> gstreamer-ffmpeg is a problem, as upstream is using/supporting only libav
> I'm not sure to understand on which version you have based you analyse on ?
> gst-ffmpeg latest version is 0.11.2 back to march, which is 'around
> the same date' of the latest API change from ffmpeg development
> version.
> Instead we have gstreamer 0.10 infrastrucuture from fedora.

Right, note that gstreamer-0.11 are non stable API / ABI preview releases
of what will become gstreamer-1.0, iow they are not really suitable for
packaging.

> I don't know the development status of gstreamer 0.11, but if the
> stable version will not be due to Fedora 18 GA, then we might use
> ffmpeg-compat for easier transition. (or to backport changes from
> gst-ffmpeg-0.11.2 if it has support for recent ffmpeg).

gst-ffmpeg-0.11.x also does not support ffmpeg-0.11

>> 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.
> vlc upstream advertised compatibility with both ffmpeg and libav. But
> they came back to provide binaries built with ffmpeg.
> At the time of the switch, their analyze was that ffmpeg was a better
> upstream, specially as they re-integrate security fixes and features
> from libav whereas libav doesn't.
>
> I would like to avoid any topic that would revisit the previous
> decision to stay with FFmpeg in RPM Fusion. I might have been
> suspicious at the time of the fork, I saw the line have changes from
> ffmpeg.org perspective and improved. But I have no doubt that is was
> the correct decision.

I'm not advocating re-evaluating that decision, I'm just saying that for
gstreamer-ffmpeg it is not working out well atm, so we need to come up
with solution for the gstreamer-ffmpeg case, this can be a gstreamer-ffmpeg
specific solution.


>
>> So we've 4 options:
>
>> 1) Try to patch gstreamer-ffmpeg to build with new ffmpeg, tried and failed
> This failure is suspicious to me, vlc upstream can be built with
> either libav of ffmpeg and binaries are nowadays provided with ffmpeg,
> which is more

This is a choice made by upstream, vlc has chosen to support both, gst-ffmpeg
upstream has chosen to support only libav.

>> 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
> ffmpeg-compat (0.6x branch) is still maintained security wise. This is
> what will be done for EL-6 since this version will match the gstreamer
> components there. I can be used as a transition state.
> Also it could be investigated to move to branch 0.7 for ffmpeg-compat
> which is advertised as using the same "oldabi" from ffmpeg-0.6.

Hmm, 0.7 is too old. gstt-ffmpeg needs 0.10, which brings us to the problem
that 0.10 and 0.11 are not parallel installable since some of the libs change
soname but not all of them. We could try packaging only libavcodec,
libavdevice and libavformat of 0.10 in a compat package, while using the others
from 0.11

May I point out that an upstream doing binary incompatible non parallel
installable releases is not making things any easier for us ?

>> 3) Build gstreamer-ffmpeg with its bundled libav copy, this is actually the
>> advised
>> way to ship gstreamer-ffmpeg by upstream.
> It can hardly be done, we will miss the benefit of sse2 in i686 by
> default and others CPU related optimization.
> (not even talking about ARM case here). That will be a duplicate
> maintenance effort anyway. (as usually with internal built).

I don't see how using an internal copy would result in not using cpu
optimization:

[hans at shalem ~]$ rpm -ql ffmpeg-libs
ffmpeg-libs-0.11.1-1.fc18.x86_64
/usr/lib64/libavcodec.so.54
/usr/lib64/libavcodec.so.54.23.100
/usr/lib64/libavdevice.so.54
/usr/lib64/libavdevice.so.54.0.100
/usr/lib64/libavfilter.so.2
/usr/lib64/libavfilter.so.2.77.100
/usr/lib64/libavformat.so.54
/usr/lib64/libavformat.so.54.6.100
/usr/lib64/libavutil.so.51
/usr/lib64/libavutil.so.51.54.100
/usr/lib64/libpostproc.so.52
/usr/lib64/libpostproc.so.52.0.100
/usr/lib64/libswresample.so.0
/usr/lib64/libswresample.so.0.15.100
/usr/lib64/libswscale.so.2
/usr/lib64/libswscale.so.2.1.100

So we don't have multiple compiles, but runtime cpu detection in one
binary, which will still work fine if the lib is statically linked into
the gstreamer plugin.

As for the maintenance burden, gst-ffmpeg ships with a bundled copy, and
this is the *preferred* way to build it. Upstream takes care of updating
the bundled libav copy on a timely basis. Doing things this way is actually
less maintenance work, since I can stop worrying about compatibility with
the system ffmpeg-libs (which is not guaranteed) and I will no longer need
to write patches to fix gstreamer-ffmpeg building and running with a
different set of ffmpeg-libs then it was written for!

>> 4) Package libav in such a way that it is parallel installable to ffmpeg,
>> use a system
> Last I've checked, it couldn't be done without forging a non-existant
> ABI as ffmpeg/libav are mutually exclusive system wide.

Right, so we would need to install it into a different library dir, use
rpath tricks, and pray that no apps ever uses both gstreamer and directly
links to ffmpeg, not a nice prospect I agree.

So given all of the above, and seeing how 1, 2 and 4 are somewhere between
very hard to do and impossible, I'm even more convinced now that 3. is the right
option.

Regards,

Hans