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~
