That's a pretty good break down of the situation Ben. Thanks for helping out. This helps clarify differences beyond what I was aware.
On Mon, May 1, 2017, 10:41 AM KJS <wolf...@gmail.com> wrote: > Thanks for clearing that up. > > So it appears that getting the support of upstream to work on packages > would be a great amount causing user base to be "stuck". I wasn't aware > that there was so many packages and our manpower is too low to impact > upstream. I believe debian went back to ffmpeg a year ago. Joost is > correct with statement, "best for users" and that seems to be ffmpeg. When > it comes down to it, we have go with what the user base needs. > > On Mon, May 1, 2017 at 10:21 AM, Ben Roberts <opti...@sabayonlinux.org> > wrote: > >> 11.9 is the latest patch release on the 11.x branch, 12.0 is also in >> portage but not marked stable. Neither provides the same versions of the >> component libraries as ffmpeg even as old as ffmpeg 3.0.x (bearing in mind >> ffmpeg is already u pto 3.3 branch, 3.0.x is already quite old). There may >> be recent releases of libav, but they are not drop-in replacements for >> ffmpeg. >> >> There are multiple component libraries in each package, but taking a >> single example, libavfilter 6.31 is provided by ffmpeg 3.0.7. libav 11.x >> and 12.0 only provide libavfilter 5.x. There is software out there that >> depends on newer component library versions than provided by any available >> libav release (tvheadend 4.2.1 as a single example of that). >> >> If both packages were comparable, a decision based on politics wouldn't >> impact which dependent software Sabayon could provide. But since the >> packages are not comparable, there are different sets of dependent packages >> that can be offered based on the choice of libav versus ffmpeg. It just so >> happens at the moment there are no packages which depend only on libav, so >> by choosing to stick with libav there are dependent packages Sabayon could >> not provide, whereas by switching all dependent packages could be provided. >> >> >> From libav's download page: >> --- >> *12* was released on *2016-10-18*. It is the latest point release from >> the *12* release series. >> >> *12* was published *2016-10-18*, the 12 branch >> <https://git.libav.org/?p=libav.git;a=shortlog;h=refs/heads/release/12> was >> cut *2016-10-02*. >> >> --- >> >> *11.9* was released on *2017-04-09*. It is the latest point release from >> the *11* release series. >> >> *11* was published *2014-12-03*, the 11 branch >> <https://git.libav.org/?p=libav.git;a=shortlog;h=refs/heads/release/11> was >> cut *2013-08-20*. >> >> >> >> On Mon, May 1, 2017 at 4:09 PM, KJS <wolf...@gmail.com> wrote: >> >>> Wasn't libav 11.9 released last month? >>> >>> On Mon, May 1, 2017 at 9:43 AM, Ben Roberts <opti...@sabayonlinux.org> >>> wrote: >>> >>>> Let's bear in mind the problem is not just that there are packages that >>>> don't have direct support for libav. The problem is also partly that there >>>> is not a libav release that provides all the same component library >>>> versions that are available in ffmpeg; libav is definitively behind ffmpeg >>>> at the present time. >>>> >>>> To stick with libav and be able to offer the same packages as if we had >>>> ffmpeg, multiple things are needed: >>>> - libav to cut a new release that is comparable to recent ffmpegs >>>> (>=3.0.x). The last version of libav was cut in Feb 2016 so is well over 12 >>>> months lagged behind ffmpeg. >>>> - Every single package which currently depends on ffmpeg to be patched >>>> to support libav, new ebuilds written and submitted to the portage tree. >>>> >>>> To me that sounds like an awful lot of work, needing to be coordinated >>>> with multiple upstreams. Are there any other distros that offer libav only, >>>> with no ffmpeg alternative? >>>> >>>> On Mon, May 1, 2017 at 3:36 PM, Jerrod Frost <piroisl...@gmail.com> >>>> wrote: >>>> >>>>> Can we get a list of every application in portage that DOES NOT >>>>> support libav and requires ffmpeg? >>>>> I would volunteer to attempt filing bugs for each application >>>>> requesting libav support. >>>>> >>>>> On Mon, May 1, 2017 at 9:31 AM KJS <wolf...@gmail.com> wrote: >>>>> >>>>>> I have to agree with Ettore >>>>>> >>>>>> On Mon, May 1, 2017 at 6:02 AM, Sławomir Nizio < >>>>>> slawomir.ni...@sabayon.org> wrote: >>>>>> >>>>>>> > We are one of the few distributions (actually i'm not aware of >>>>>>> others) >>>>>>> > that support libav out of the box, and i'm proud of it. What i >>>>>>> would >>>>>>> > propose instead is trying to push upstream projects that misses >>>>>>> libav >>>>>>> > support and/or helping libav providing support to them. >>>>>>> >>>>>>> Volunteers? :) >>>>>>> >>>>>>> One of the apps I have installed is cmus, and it's an older version >>>>>>> because the newer one doesn't support libav, so I'll use it as an >>>>>>> example. >>>>>>> >>>>>>> Some upstreams don't seem to be willing to take the additional >>>>>>> effort of >>>>>>> supporting both libraries, e.g.: >>>>>>> https://github.com/cmus/cmus/issues/139. If by upstream you mean >>>>>>> Gentoo, >>>>>>> it is also being the case, it seems. Maybe the people you mentioned >>>>>>> could help, but then let's not forget patching an application is not >>>>>>> a >>>>>>> one time thing, but support has to be ensured for future versions of >>>>>>> the >>>>>>> application and the libs. >>>>>>> >>>>>>> > That being said, if majority of the staff agree and wants the >>>>>>> > transition, i would be ok with it, despite not liking it :o) >>>>>>> >>>>>>> I don't have a strong opinion here, but missing apps support is a >>>>>>> problem a distribution should approach somehow. An alternative way >>>>>>> would >>>>>>> be to have these libraries installed in parallel with patching >>>>>>> applications to find these, but again it's an effort I'd rather be >>>>>>> avoided. Still, that would probably be much easier than the former >>>>>>> approach. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> KJS >>>>>> ~wolfden~ >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> KJS >>> ~wolfden~ >>> >>> >>> >>> >> >> >> >> > > > -- > KJS > ~wolfden~ >
