5:17 p.m.
On Mon, Feb 24, 2014 at 12:30 AM, Ralf Corsepius
<ralf.corsepius(a)gmail.com> wrote:
On 02/24/2014 07:20 AM, 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.
>
> ----------
>
> From what I can tell, the three reasons that the XBMC developers
> bundle FFmpeg are:
There are 2 strong reasons to not bundle FFMPEG:
* Users (eg. me) rebuild rpmfusion's ffmpeg with options not supported by
rpmfusion:
=> rpmfusion bundling xbmc's ffmpeg would void this undertaking and reduce
rpmfusion's usability.
* ffmpeg is quite security sensitive (AFAICT, e.g. Google recently reported
(IIRC), ca. 1000 bugs, which reportedly were incorporated into upstream
ffmpeg)
=> XBMC's bundling imposes severe security risks on both XMBC and rpmfusion
That said, I am quite opposed to let rpmfusion bundle ffmpeg and am in favor
of staying hard for didacitcal, to teach upstream XBMC that their
undertaking is counterproductive.
One could say that the issue which prompted my bundling exception
proposal, https://github.com/xbmc/xbmc/pull/4005, is a direct
consequence of "teaching upstream". They've made it more difficult to
unbundle with the express purpose of influencing downstream
distributors of XBMC.
You can see where that trajectory leads. Yes, it's all open source,
and the GPL technically allows RPM Fusion to do what we want, etc, but
Alex and I are heading down a path of maintaining an
increasingly-diverging XBMC fork at this point, and no one else has
committed to becoming a full co-mainatainer of the package in order to
share the workload, particularly the workload associated with
downstream patches.
Alex and I know firsthand that this is not a good situation, and in
fact I don't know any of the upstream developers who are rabidly
enthusiastic about the bundling situation either. If the issues I
outlined in my previous email could go away or be reduced, I'm
confident that they would pull FFmpeg from their tree right away.
They've certainly pulled bundled libraries out over the years when
it's made sense to do so. https://github.com/xbmc/xbmc/pull/1450 is
one example.
I'm all for Fedora's strong package guidelines - it's why I use and
contribute to Fedora. Please believe me that I wouldn't go the
bundling exception route if I felt that another choice was truly
feasible. After working on this package for years, I believe this is
the least-worst option available.
Looking at it from another angle, it's important that our relationship
with upstream XBMC involve give-and-take. If we don't allow the
specific exception here for FFmpeg, we are certainly teaching them
something: we're souring Fedora's name with upstream and making them
care even less about our platform.
I'm not yet at the point where I want to pull XBMC from RPM Fusion
altogether, but version 13 final will have that pull request in the
codebase, and we need to decide what to do.
One thing that would really help to smooth over the relationship is if
we had a patch to XBMC that allowed us to add a large caveat to their
branding. It would be wonderful if we had some sort of "XBMC, modified
by bugzilla.rpmfusion.org" splash screen or logo. One of the XBMC
developers pointed me at Debian's effort with this. Debian has started
down this road, in large part because of these issues:
http://balintreczey.hu/blog/introducing-xbmc-from-debian/ . This would
be a great area of work for someone reading this discussion who could
become a potential contributor to XBMC/RPM Fusion. It would be even
better if the solution could be something extensible enough that
upstream would accept into their codebase.
Another thing to consider Ralf is that I intend to maintain the
package in such a way that it will be trivial to switch between using
the bundled FFmpeg and the non-bundled version using a build
conditional. It should be simple for you to continue building against
your own custom FFmpeg package - you will just need to flip the
"without external_ffmpeg" conditional to "with external_ffmpeg" when
you rebuild your XBMC. See the ongoing work at
http://fedorapeople.org/cgit/alexlan/public_git/xbmc-rpm.git
This sort of build switch is useful for a variety of reasons: 1) Given
the sheer number of bugs directly related to FFmpeg differences,
having a simple boolean switch lowers the barrier for our bug
reporters to do their own investigating, 2) It makes my efforts with
building nightly XBMC snapshots easier, since I don't have to worry
about matching all the FFmpeg versions between Fedora 21 and Fedora
19, and 3) the build conditional makes it easier to switch the default
back to external FFmpeg if and when that day ever comes.
- Ken