Re: [sabayon-dev] idea: switching back to ffmpeg

[Jerrod Frost]

That will be put in the new release info once we make a new "release" here
soon.

On Wed, Sep 27, 2017, 9:31 AM Svantoviit  wrote:

> I would appreciate an announcement that Sabayon has switched back go
> ffmpeg.
>
> --
> SvantoViit
>
>

Re: [sabayon-dev] idea: switching back to ffmpeg

[Svantoviit]

I would appreciate an announcement that Sabayon has switched back go
ffmpeg.

--
SvantoViit

Re: [sabayon-dev] idea: switching back to ffmpeg

[Svantoviit]

"Our users" or "our user base" are very vague categories.
Although it has been stated, that Sabayon is not a democracy,
as one of the users I can say I am happy with libav ;)

--
SvantoViit

Re: [sabayon-dev] idea: switching back to ffmpeg

[Sławomir Nizio]

Silence here, so let me share the status: it's still undecided, and the
discussion can continue when /some guy/ can fully participate (goes from
semi-away which is due to technical problems).

Re: [sabayon-dev] idea: switching back to ffmpeg

[KJS]

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 
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
>  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
>  was
> cut *2013-08-20*.
>
>
>
> On Mon, May 1, 2017 at 4:09 PM, KJS  wrote:
>
>> Wasn't libav 11.9 released last month?
>>
>> On Mon, May 1, 2017 at 9:43 AM, Ben Roberts 
>> 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 
>>> 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  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 

Re: [sabayon-dev] idea: switching back to ffmpeg

[Ben Roberts]

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
 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
 was
cut *2013-08-20*.



On Mon, May 1, 2017 at 4:09 PM, KJS  wrote:

> Wasn't libav 11.9 released last month?
>
> On Mon, May 1, 2017 at 9:43 AM, Ben Roberts 
> 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 
>> 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  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~

>>>

Re: [sabayon-dev] idea: switching back to ffmpeg

[KJS]

Wasn't libav 11.9 released last month?

On Mon, May 1, 2017 at 9:43 AM, Ben Roberts 
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  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  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~

Re: [sabayon-dev] idea: switching back to ffmpeg

[Ben Roberts]

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

Re: [sabayon-dev] idea: switching back to ffmpeg

[Jerrod Frost]

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  wrote:

> I have to agree with Ettore
>
> On Mon, May 1, 2017 at 6:02 AM, Sławomir Nizio  > 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~
>

Re: [sabayon-dev] idea: switching back to ffmpeg

[KJS]

I have to agree with Ettore

On Mon, May 1, 2017 at 6:02 AM, Sławomir Nizio 
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~

Re: [sabayon-dev] idea: switching back to ffmpeg

[Sławomir Nizio]

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

Re: [sabayon-dev] idea: switching back to ffmpeg

[Jerrod Frost]

Just a heads up, right now we're thinking of working to get libav working
upstream. We are still in talks and it's not set in stone yet.

On Fri, Apr 28, 2017, 2:13 PM Sławomir Nizio 
wrote:

> Joost expressed on IRC he would be OK with the switch.
>
> Ettore - ?
> Fabio - ?
> The world economy - ?
>
>

Re: [sabayon-dev] idea: switching back to ffmpeg

[Sławomir Nizio]

> It would be awesome for the users to have the choice, actually. ,-)

It could be useful only in limited number of cases I think, and neither
Debian, Gentoo nor Arch do it, from what I can see.

(Gentoo provides the choice, but they can't co-exist, and switching
requires rebuilding many packages.)

The idea was proposed in Debian
(https://lists.debian.org/debian-devel/2014/07/msg01010.html and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729203, but it was
rejected in the end. I didn't read the whole thread, but it seems the
reason was it would be more work for the security team to keep up with both.

Re: [sabayon-dev] idea: switching back to ffmpeg

[Nicolas Sebrecht]

On Wed, Apr 26, 2017 at 01:02:20AM +0200, Joost Ruis wrote:

>What matters to me is what works best for our users.

It would be awesome for the users to have the choice, actually. ,-)

-- 
Nicolas Sebrecht

Re: [sabayon-dev] idea: switching back to ffmpeg

[Sławomir Nizio]

> The fact that https://gpo.zugaina.org/media-video/obs-studio has a hard
> dep on ffmpeg could be because the Gentoo maintainer isn't aware of the
> virtual package.

I read it really does not compile with libav.

> I'm not technically up to date, but if libav is indeed
> breaking away with ffmpeg compatibility or visa versa we should decide
> what to use.

And there is not only OBS Studio. Here is a list (it may be a little
outdated):

(what depends on media-video/ffmpeg and not media-video/libav of the
virtual; USE flags ignored, excluding system-ffmpeg)

app-cdr/backlite
dev-python/audioread
dev-qt/qtwebengine (with USE=system-ffmpeg)
dev-util/electron (as above)
games-engines/openmw
media-gfx/gmic
media-libs/gegl
media-libs/openimageio
media-sound/beets
media-sound/cmus
media-sound/mixxx
media-tv/kodi
media-video/dcpomatic
media-video/ffcast
media-video/mplayer
media-video/peek
media-video/ttcut
net-im/qtox
net-misc/youtube-viewer
net-p2p/tribler
net-voip/homer
www-client/chromium (with USE=system-ffmpeg)

> 
> Either way I know we have good contacts with upstream libav and we could
> get answers there. (Ettore could you investigate?)

OK, I'll wait on what Ettore says about this before going any further.

> Having said this. We are an opensource project and if there are issues
> with upstream software we at least investigate and inform upstream about
> this.

There is a problem, but I understand why package maintainers don't want
to patch the hell out themselves.

Re: [sabayon-dev] idea: switching back to ffmpeg

[Sławomir Nizio]

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

I believe only ffmpeg with the stable keyword would be used.

Re: [sabayon-dev] idea: switching back to ffmpeg

[Joost Ruis]

What matters to me is what works best for our users.

The fact that https://gpo.zugaina.org/media-video/obs-studio has a hard dep
on ffmpeg could be because the Gentoo maintainer isn't aware of the virtual
package. I'm not technically up to date, but if libav is indeed breaking
away with ffmpeg compatibility or visa versa we should decide what to use.

Either way I know we have good contacts with upstream libav and we could
get answers there. (Ettore could you investigate?)

Having said this. We are an opensource project and if there are issues with
upstream software we at least investigate and inform upstream about this.

Just my thoughts.

On Tue, Apr 25, 2017 at 11:37 PM, Jerrod Frost  wrote:

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

Re: [sabayon-dev] idea: switching back to ffmpeg

[Jerrod Frost]

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