FFmpeg bundling exception for XBMC

[Dominik 'Rathann' Mierzejewski]

Hi Ken,

On Monday, 24 February 2014 at 07:20, Ken Dreyer wrote:
> Hi folks,
> 
> Alex Lancaster recently pointed out that XBMC upstream has completely
> removed the option to use an external FFmpeg.
> 
> https://github.com/xbmc/xbmc/pull/4005
> 
> FFmpeg has been a long ongoing saga with XBMC. The XBMC developers
> develop their own patches to their private FFmpeg fork, and Alex and I
> have had various success or failure over the years with unbundling
> FFmpeg in the past. Unfortunately XBMC has recently taken steps in the
> direction to make this harder, at least for the v13 "Gotham" release.
> 
> The summary is that Alex and I need a bundling exception from the RPM
> Fusion developer community in order to keep XBMC in RPM Fusion.

Is this a permanent or temporary exception?

I'd be +1 to a temporary exception, but -1 on permanent.

> ----------
> 
> From what I can tell, the three reasons that the XBMC developers
> bundle FFmpeg are:
> 
> 1) FFmpeg API instability. XBMC is tightly coupled to the FFmpeg API,
> and this API changes too often. XBMC developers do not choose to spend
> their time making sure that XBMC works with all the FFmpeg versions
> that Linux distributions may ship.

This is a self-perpetuating myth that hasn't been true for over a year
now. FFmpeg has two release streams maintained in parallel (let's call
them "feature" and "maintenance"). Currently, these are 2.1.x and 1.2.x.

It looks like 1.2.x is bundled in xbmc-13.0-Gotham_alpha9, so could you
ask upstream why don't they simply track 1.2.x release stream?

> 2) FFmpeg development process. From what I understand there is a
> certain inertia involved in getting patches uptream and then waiting
> for them to flow back downstream into Linux distributions. Since the
> XBMC developers care a lot about Windows, MacOS, and Android, concerns
> about waiting for an upstream/downstream cycle do not apply for those
> non-Linux developers, since FFmpeg must be bundled on those platforms
> anyway. Those developers have substantial weight in the XBMC
> community.

I follow ffmpeg-devel list from time to time and I'm under the
impression that patches are welcome and quickly accepted (assuming they
are up to FFmpeg standards). I'll check if there were any patches
from XMBC developers in the last year or so. FFmpeg certainly cares
about working on the same platforms as you listed for XBMC, so I don't
see any conflict of interest here.

> 3) Support. Due to the first two factors (unstable FFmpeg API, and
> slow upstream/downstream cycles), several developers in the XBMC
> community are not happy when Fedora or Debian packages XBMC against an
> external FFmpeg and users complain on their support forums because of
> bugs that were "already fixed" in XBMC's FFmpeg fork. Because XBMC
> users are complaining to upstream, rather than to us at RPM Fusion,
> the upstream developers are concerned that our unbundling creates user
> confusion, gives XBMC a bad name, and adds unnecessary support load on
> their forum community.

Why don't they make it easy to prominently display the correct support
venue instead of making life harder for downstream distributors?

[...]
> Q: Does the maintainer of the Fedora package of the library being
> bundled have any comments about this?
> 
> I haven't discussed this with the FFmpeg maintainer(s) in RPM Fusion,
> but I'm quite interested in maintainers' feedback.

It might be possible to build a compat-ffmpeg12 package so that XBMC
can build against it.

Regards,
Dominik

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
        -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"