6:20 a.m.
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:
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.
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.
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.
Below are the answers to the standard Bundling Exception questions
from https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
----------
Q: Has the library behaviour been modified? If so, how has it been modified?
Yes, the XBMC developers modify their FFmpeg library. It is hard to
give specifics because the situation changes over the years. Sometimes
their modifications are trivial bugfixes, and sometimes the
modifications are more invasive.
Q: Why haven't the changes been pushed to the upstream library?
The XBMC developers are interested in pushing the changes, but it
takes time and energy to get the patches reviewed and merged upstream.
As explained above, the upstream/downstream cycle is two slow for the
release pacing to which XBMC strives.
Merging patches upstream is a priority but not a high enough priority
to make it feasible to unbundle FFmpeg, particularly for XBMC v13.
Q: Have the changes been proposed to the Fedora package maintainer for
the library?
Not that I'm aware of. The work mainly happens on the FFmpeg
development email lists.
Q: Could we make the forked version the canonical version within Fedora?
I don't think this would align with upstream's long-term or short-term
goals. I think we will need to wait and see how things shake out in
XBMC. There is talk of removing the FFmpeg directory from their tree
and splitting it into a separate Git repository. That could be a step
in the right direction towards making it easier to unbundle FFmpeg
once again.
FFmpeg is under active development, and XBMC is also under active
development, so both projects are certainly still alive. I think this
question is only relevant when one of the projects is close to death.
Q: Is upstream keeping the base library updated or are they
continuously one or more versions behind the latest upstream release?
XBMC stays close to the upstream FFmpeg project. Again, FFmpeg's API
instability doesn't always make this easy, but they do a fairly good
job.
Q: What is the attitude of upstream towards bundling? (Are they eager
to remove the bundled version? are they engaged with the upstream for
the library? Do they have a history of bundling? Are they
argumentative?)
The attitude depends on the individuals. Some developers are more
interested in unbundling than others. If we can address the three
points I outlined above, particularly the support load question, I
think that will go a long way towards making upstream more receptive
to ideas of unbundling.
More discussion and community involvement is needed.
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.
Q: Is there a plan for unbundling the library at a later time? Include
things like what features would need to be added to the upstream
library, a timeline for when those features would be merged, how we're
helping to meet those goals, etc.
I hear different things depending on who's talking, so in the interest
of being conservative I don't want to promise things that aren't
clearly communicated from XBMC as project-wide announcements.
I will say that there is general interest in improving the situation.
On the other hand, from my limited perspective, I don't think the
situation can be improved without more stability and higher
development velocity from the FFmpeg project.
Q: Please include any relevant documentation -- mailing list links,
bug reports for upstream or the bundled library, etc.
This link constitutes the most pressing issue:
https://github.com/xbmc/xbmc/pull/4005
Here is a list of recent XBMC bugs related to our unbundling of FFmpeg.
https://bugzilla.rpmfusion.org/2765
https://bugzilla.rpmfusion.org/2870
https://bugzilla.rpmfusion.org/2925
https://bugzilla.rpmfusion.org/3059
https://bugzilla.rpmfusion.org/3159
This bug list is not exhaustive but it gives a good sample of the issues.
- Ken
7:17 a.m.
On Sun, 2014-02-23 at 23:20 -0700, Ken Dreyer wrote:
Hi folks,
Alex Lancaster recently pointed out that XBMC upstream has completely
removed the option to use an external FFmpeg.
<snip>
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.
Normally I hate bundled libraries, but given the situation, I think I'm
+1 for this.
Jonathan
7:30 a.m.
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.
Ralf
8:31 a.m.
On Mon, 2014-02-24 at 08:30 +0100, Ralf Corsepius wrote:
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.
While this is valid, is it a good enough reason on its own to refuse to
allow a bundling exception?
* 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
This is a very valid reason. Do you have links so we can check whether
XBMC's ffmpeg fork has had these fixes applied? If not (especially for
any security bugs), then that would indicate that XBMC isn't doing well
at maintaining its fork, and that would sway my opinion.
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.
While I agree with your sentiment, I suspect that upstream XBMC won't
really care if we refuse to bundle ffmpeg. I don't think Fedora users
are a very large percentage of the XBMC user base. This is why I think
that in this case (again, assuming that XBMC is applying security fixes
to their fork), we should allow a bundling exception.
The main two arguments that would change my mind would be if XBMC is not
applying security fixes to their code or if someone actually produced
patches that allowed XBMC 13 to be built against RPM Fusion's ffmpeg.
Jonathan
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
9:47 p.m.
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"
12:32 a.m.
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(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
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
Best regards,
--
Sérgio M. B.
4:50 p.m.
Ken Dreyer wrote:
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
Then it needs to be patched to revert these commits, or parts of them. It
shall be noted that it is NOT necessary to use their "DLL loader"
(presumably a cross-platform wrapper around dlopen) to load FFmpeg (the main
stuff they removed), it is enough to link the system shared library
directly. So the actual CODE does not need to be any different than for
static linking, only the build setup needs to link the shared library.
Kevin Kofler
4:51 p.m.
Ken Dreyer wrote:
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
If you're going through the effort of patching the code to work with the
system FFmpeg anyway, why not make it the default?
Kevin Kofler
1:34 p.m.
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(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
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.
3698
days inactive
3707
days old
rpmfusion-developers@lists.rpmfusion.org
9 comments
6 participants
participants (6)
-
Dominik 'Rathann' Mierzejewski -
Jonathan Dieter -
Ken Dreyer -
Kevin Kofler -
Ralf Corsepius -
Sérgio Basto