On Monday, 24 February 2014 at 07:20, Ken Dreyer wrote:
Alex Lancaster recently pointed out that XBMC upstream has completely
removed the option to use an external FFmpeg.
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
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
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.
| MPlayer http://mplayerhq.hu
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"