FFmpeg bundling exception for XBMC

[Sérgio Basto]

On Qua, 2014-02-26 at 00:32 +0000, Sérgio Basto wrote: 
> On Seg, 2014-02-24 at 10:17 -0700, Ken Dreyer wrote: 
> > On Mon, Feb 24, 2014 at 12:30 AM, Ralf Corsepius
> > <ralf.corsepius at 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
> 
> I like this solution 
> 
> > 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.
> 
> Maybe the problem was, we jumped or bumped ffmpeg versions too quickly
> for XBMC, in this case switch to internal ffmpeg could be a solution,
> instead go with alfa versions of XBMC to released Fedora versions. We
> got xbmc-13.0-0.2.Gotham_alpha9.fc20 for F20 ... 
> but when available XBMC should use external version, IMHO 

Put in other way, if we have an ffmpeg-compat-1.1 wouldn't be a better
solution ? and not have a  bundling exception .

Best regards,
-- 
Sérgio M. B.