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