Interesting. LibAV is supposedly cleaner, harder code, but much of libAV ends up in ffmpeg anyway from what I'm reading and ffmpeg has more support for most other applications etc. Their problem is ffmpeg tends to be more bloated and risky about adopting patches and code? As long as we're not updating ffmpeg every chance we get and wait for ffmpeg releases to prove their stability etc, I think we may be fine. Sticking to libav may prove more secure and show support for applications that choose to support libav. I'm not for or against this currently.
Does anyone else have any thoughts on this? On Tue, Apr 25, 2017 at 12:49 PM Sławomir Nizio <slawomir.ni...@sabayon.org> wrote: > Hello, > > The libav project has served Sabayon well, and the fact it appeared and > has been actively developed might have made great impact on the world of > audio/video libraries. However, this may be a good time to switch back > to ffmpeg. There are references on IRC that it's wanted by users because > of projects that work only with ffmpeg. > > I analysed it and concluded that there should be no big problems about > the switch. Here is what I found out. I used 3.2.4 as target, which is > the last stable version. > > No package should be lost after the switch. First of all, it seems that > there are no "actual" packages in Gentoo tree that work with libav but > not ffmpeg. (I took a simplistic approach for checking this, parsing in > a way and comparing reverse dependencies listings from > http://qa-reports.gentoo.org/, but it believe it was accurate.) Second, > according to bug reports about incompatibilities with ffmpeg 3, packages > that Sabayon provides with ffmpeg USE flag enabled have either patches > (on BZ or at upstream) or new versions available that should correct the > failure. Certainly, I didn't check that patches myself, so there is > still a risk, but basing on the whole, it's negligible. It is also > possible that a failure has not been reported. Comments on interesting > cases I noted down are below. > > tracker bugs: > https://bugs.gentoo.org/show_bug.cgi?id=574788 (ffmpeg-3) - [TRACKER] > media-video/ffmpeg-3.0 transition > https://bugs.gentoo.org/show_bug.cgi?id=575538 [TRACKER] > media-video/ffmpeg-3.0 stabilization > > not listed above, so I'm listing it here (new version is available): > https://bugs.gentoo.org/show_bug.cgi?id=609640 > media-libs/xine-lib-1.2.6-r2 fails to compile after upgrading to > media-video/ffmpeg-3.2.4 > > about to be removed from Gentoo: > https://bugs.gentoo.org/show_bug.cgi?id=575824 app-cdr/backlite-1.0.3-r1 > : src/.../k9avidecode.cpp:241: 33: error: ‘PIX_FMT_RGB24’ was not > declared in this scope > > easy workaround is to disable this flag on ffmpeg (not much useful, no > reverse dependency problems): > https://bugs.gentoo.org/show_bug.cgi?id=598054 =media-video/ffmpeg-3.1.5 > can't link properly when USE="jpeg2k" > > > > I can do the work. Due to a large number of packages to rebuild and the > need to handle issues, if any, the work would be spread across a few > days, perhaps up to about a week. Until finished, no other package > related work could be done in Entropy (!), which means a short freeze. > > I could start at the end of this week, or even a little earlier, if > nobody complains. > > Is there something I missed that makes the switch not possible? > >
