No subject

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