FFmpeg bundling exception for XBMC

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. ---------- 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