Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Michał Górny-5
Hi, everyone.

Just after the news item got published, user Wes mailed me with
a suggestion. While I think someone mentioned it earlier
in the bikesheds over ffmpeg, I have completely forgotten about it
and now I'd like to reconsider it. For this reason, I've reverted
the news item while it's still fresh and p.masked the revbumps.

The idea is that instead of having USE=libav (that's tangential to
USE=ffmpeg and confusing) to use a USE_EXPAND like FFMPEG_IMPL taking
either ffmpeg or libav. Now, why...


First of all, one of the key points in my news item is that users need
to keep consistent state of USE=libav throughout all the packages. Wes
pointed out that users are more likely to consider a dedicated variable
(USE_EXPAND) in make.conf global than a regular USE flag. Which makes
it more likely for them to end up in terrible state full of blockers.

Secondly, it avoids the confusion of having USE=ffmpeg and USE=libav
being used for completely different purposes. This is not only
confusing by users who need to set USE='ffmpeg libav' if they want
libav, but also confusing to developers who may end up using the two
flags to signify the two implementations. Think of the mess of USE='gtk
gtk3'.

FFMPEG_IMPL feels like a natural extension of USE=ffmpeg. USE=ffmpeg
tells to use ffmpeg or a replacement, FFMPEG_IMPL tells what will
exactly get used. Much less confusion.

Thirdly, this opens space for having more than two different
implementations in the future without having to reset the system. Maybe
this isn't something worth considering but -- as I see it -- the first
big fork starts a precedent, and both current versions suck :).

Fourthly, there's the case of implicity. Right now USE=-libav implies
ffmpeg. Therefore, USE=-* implies ffmpeg as well -- which is kinda
weird since it's supposedly the non-default. With this solution, USE=-*
will result in explicit error asking user to select an implementation.

As for the downsides:

1. there is a number of non-meaningful flag combinations.
FFMPEG_IMPL='', FFMPEG_IMPL='ffmpeg libav'. They will have to be
blocked via REQUIRED_USE='^^ ( ffmpeg_impl_ffmpeg ffmpeg_impl_libav )'.

2. There is some more work to get ebuilds correct (REQUIRED_USE).
However, this is a minor issue compared to the potential mistakes in
interpretation of USE='ffmpeg' and USE='libav'.


What are your thoughts?

--
Best regards,
Michał Górny

attachment0 (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Ulrich Mueller-2
>>>>> On Mon, 2 Feb 2015, Michał Górny wrote:

> FFMPEG_IMPL feels like a natural extension of USE=ffmpeg. USE=ffmpeg
> tells to use ffmpeg or a replacement, FFMPEG_IMPL tells what will
> exactly get used. Much less confusion.

> Thirdly, this opens space for having more than two different
> implementations in the future without having to reset the system. Maybe
> this isn't something worth considering but -- as I see it -- the first
> big fork starts a precedent, and both current versions suck :).

> Fourthly, there's the case of implicity. Right now USE=-libav implies
> ffmpeg. Therefore, USE=-* implies ffmpeg as well -- which is kinda
> weird since it's supposedly the non-default. With this solution, USE=-*
> will result in explicit error asking user to select an implementation.

> As for the downsides:

> 1. there is a number of non-meaningful flag combinations.
> FFMPEG_IMPL='', FFMPEG_IMPL='ffmpeg libav'. They will have to be
> blocked via REQUIRED_USE='^^ ( ffmpeg_impl_ffmpeg ffmpeg_impl_libav )'.

> 2. There is some more work to get ebuilds correct (REQUIRED_USE).
> However, this is a minor issue compared to the potential mistakes in
> interpretation of USE='ffmpeg' and USE='libav'.


> What are your thoughts?

In a nutshell, you have a binary choice here, namely ffmpeg or libav
as implementation, and instead of one USE flag you want to introduce
two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of the 4 possible
combinations only 2 are valid. So you need a REQUIRED_USE to forbid
some combinations.

Please spare us of this.

Ulrich

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Gordon Pettey
Having USE="ffmpeg" at all is the source of any confusion in case somebody is using libav. Either with an expand set (which seems wasted just for two options) or two regular flags, just force one or none. There is absolutely no sense in having USE="ffmpeg" on for a system using libav.

On Mon, Feb 2, 2015 at 8:12 AM, Ulrich Mueller <[hidden email]> wrote:
>>>>> On Mon, 2 Feb 2015, Michał Górny wrote:

> FFMPEG_IMPL feels like a natural extension of USE=ffmpeg. USE=ffmpeg
> tells to use ffmpeg or a replacement, FFMPEG_IMPL tells what will
> exactly get used. Much less confusion.

> Thirdly, this opens space for having more than two different
> implementations in the future without having to reset the system. Maybe
> this isn't something worth considering but -- as I see it -- the first
> big fork starts a precedent, and both current versions suck :).

> Fourthly, there's the case of implicity. Right now USE=-libav implies
> ffmpeg. Therefore, USE=-* implies ffmpeg as well -- which is kinda
> weird since it's supposedly the non-default. With this solution, USE=-*
> will result in explicit error asking user to select an implementation.

> As for the downsides:

> 1. there is a number of non-meaningful flag combinations.
> FFMPEG_IMPL='', FFMPEG_IMPL='ffmpeg libav'. They will have to be
> blocked via REQUIRED_USE='^^ ( ffmpeg_impl_ffmpeg ffmpeg_impl_libav )'.

> 2. There is some more work to get ebuilds correct (REQUIRED_USE).
> However, this is a minor issue compared to the potential mistakes in
> interpretation of USE='ffmpeg' and USE='libav'.


> What are your thoughts?

In a nutshell, you have a binary choice here, namely ffmpeg or libav
as implementation, and instead of one USE flag you want to introduce
two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of the 4 possible
combinations only 2 are valid. So you need a REQUIRED_USE to forbid
some combinations.

Please spare us of this.

Ulrich

Reply | Threaded
Open this post in threaded view
|

Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Michał Górny-5
Dnia 2015-02-02, o godz. 08:54:04
Gordon Pettey <[hidden email]> napisał(a):

> Having USE="ffmpeg" at all is the source of any confusion in case somebody
> is using libav. Either with an expand set (which seems wasted just for two
> options) or two regular flags, just force one or none. There is absolutely
> no sense in having USE="ffmpeg" on for a system using libav.

If things were that simple, you wouldn't need me :P.

This would mean that the flags have two slightly different uses. They
either enable ffmpeg or libav when it is optional, or they choose
between ffmpeg or libav when it is not. Not that bad?

Now if we want to default to libav, we set USE=libav. Oh wait, that
enables optional libav support in all packages. And if we don't do
that, a number of packages with obligatory ffmpeg/libav support doesn't
install by default.

Users have real trouble setting their preferences too. If they prefer
ffmpeg, they need to change that for every package in question or
they implicitly enable the optional support for all packages.

--
Best regards,
Michał Górny

attachment0 (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Michael Orlitzky
In reply to this post by Ulrich Mueller-2
On 02/02/2015 09:12 AM, Ulrich Mueller wrote:

>
>> What are your thoughts?
>
> In a nutshell, you have a binary choice here, namely ffmpeg or libav
> as implementation, and instead of one USE flag you want to introduce
> two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of the 4 possible
> combinations only 2 are valid. So you need a REQUIRED_USE to forbid
> some combinations.
>
> Please spare us of this.
>

Why do we need two flags for this? Wouldn't a single global
USE=ffmpeg_impl_libav have exactly the desired behavior?


Reply | Threaded
Open this post in threaded view
|

Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Michał Górny-5
Dnia 2015-02-02, o godz. 10:44:46
Michael Orlitzky <[hidden email]> napisał(a):

> On 02/02/2015 09:12 AM, Ulrich Mueller wrote:
> >
> >> What are your thoughts?
> >
> > In a nutshell, you have a binary choice here, namely ffmpeg or libav
> > as implementation, and instead of one USE flag you want to introduce
> > two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of the 4 possible
> > combinations only 2 are valid. So you need a REQUIRED_USE to forbid
> > some combinations.
> >
> > Please spare us of this.
> >
>
> Why do we need two flags for this? Wouldn't a single global
> USE=ffmpeg_impl_libav have exactly the desired behavior?
Maybe. Though it still will keep the confusion of !libav meaning ffmpeg.

I mean:

  ffmpeg? (
    !libav? ( ffmpeg )
    libav? ( ffmpeg )
  )

(or without the outer 'ffmpeg?'). In your variant:

  ffmpeg? (
    !ffmpeg_impl_libav? ( ffmpeg )
    ffmpeg_impl_libav? ( ffmpeg )
  )

Maybe a little cleaner but still relies on the implicit thing. Not to
mention the user is supposed to set either:

  FFMPEG_IMPL=libav

or:

  FFMPEG_IMPL=

which is nowhere close to sane :).

--
Best regards,
Michał Górny

attachment0 (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Alexis Ballier-2
In reply to this post by Ulrich Mueller-2
On Mon, 2 Feb 2015 15:12:50 +0100
Ulrich Mueller <[hidden email]> wrote:

> > What are your thoughts?
>
> In a nutshell, you have a binary choice here, namely ffmpeg or libav
> as implementation, and instead of one USE flag you want to introduce
> two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of the 4 possible
> combinations only 2 are valid. So you need a REQUIRED_USE to forbid
> some combinations.


We already have three possibilities: ffmpeg, libav or none (only for
some packages but they do exist).
With the N-1th proposal, it was overseen that USE="-ffmpeg libav" should
be forbidden by REQUIRED_USE.

With the N-1th proposal, we had two bits (USE='ffmpeg libav') to code 3
states. With the above proposal, we have a kind of unary coding:
USE=-ffmpeg means 'none', USE=ffmpeg + ffmpeg_impl_$x means '$x'.

I understand your point; I'm not entirely convinced which one is
better, but I'm tempted by the simplicity for users of the above unary
proposal.

Alexis.

Reply | Threaded
Open this post in threaded view
|

Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Alec Ten Harmsel
In reply to this post by Michał Górny-5

On 02/02/2015 09:06 AM, Michał Górny wrote:

> Hi, everyone.
>
> Just after the news item got published, user Wes mailed me with
> a suggestion. While I think someone mentioned it earlier
> in the bikesheds over ffmpeg, I have completely forgotten about it
> and now I'd like to reconsider it. For this reason, I've reverted
> the news item while it's still fresh and p.masked the revbumps.
>
> The idea is that instead of having USE=libav (that's tangential to
> USE=ffmpeg and confusing) to use a USE_EXPAND like FFMPEG_IMPL taking
> either ffmpeg or libav. Now, why...
>
>
> First of all, one of the key points in my news item is that users need
> to keep consistent state of USE=libav throughout all the packages. Wes
> pointed out that users are more likely to consider a dedicated variable
> (USE_EXPAND) in make.conf global than a regular USE flag. Which makes
> it more likely for them to end up in terrible state full of blockers.
>
> Secondly, it avoids the confusion of having USE=ffmpeg and USE=libav
> being used for completely different purposes. This is not only
> confusing by users who need to set USE='ffmpeg libav' if they want
> libav, but also confusing to developers who may end up using the two
> flags to signify the two implementations. Think of the mess of USE='gtk
> gtk3'.

I might not have followed this discussion close enough; wasn't the end
result that USE='ffmpeg' uses ffmpeg and USE='libav' uses libav? As in
there will be no more USE='ffmpeg libav' in the future, only USE='libav'
for libav?

>
> FFMPEG_IMPL feels like a natural extension of USE=ffmpeg. USE=ffmpeg
> tells to use ffmpeg or a replacement, FFMPEG_IMPL tells what will
> exactly get used. Much less confusion.

I would agree except that as far as I know ffmpeg and libav are not
trying to be binary compatible.

>
> Fourthly, there's the case of implicity. Right now USE=-libav implies
> ffmpeg. Therefore, USE=-* implies ffmpeg as well -- which is kinda
> weird since it's supposedly the non-default. With this solution, USE=-*
> will result in explicit error asking user to select an implementation.
>
> As for the downsides:
>
> 1. there is a number of non-meaningful flag combinations.
> FFMPEG_IMPL='', FFMPEG_IMPL='ffmpeg libav'. They will have to be
> blocked via REQUIRED_USE='^^ ( ffmpeg_impl_ffmpeg ffmpeg_impl_libav )'.
>
> 2. There is some more work to get ebuilds correct (REQUIRED_USE).
> However, this is a minor issue compared to the potential mistakes in
> interpretation of USE='ffmpeg' and USE='libav'.
>
>
> What are your thoughts?
>

During the earlier discussion, I was of the opinion that USE='ffmpeg'
should just cause a dependency on virtual/ffmpeg and that would solve
all the problems. I don't think this is right, though; if ffmpeg and
libav are not trying for (or actively avoiding) binary compatibility,
why not treat them as separate projects and just add
RDEPEND='!media-video/ffmpeg' to libav's ebuild and vice versa?

Just my two cents. I'm not a developer, but this seems like the simplest
solution to me.

Alec

Reply | Threaded
Open this post in threaded view
|

Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Michael Orlitzky
In reply to this post by Michał Górny-5
On 02/02/2015 10:50 AM, Michał Górny wrote:
>
> Maybe. Though it still will keep the confusion of !libav meaning ffmpeg.
>

We could remove USE=libav from the tree, leaving only USE=ffmpeg. Then
ffmpeg_impl_libav would switch the implementation if USE=ffmpeg is enabled.



> Maybe a little cleaner but still relies on the implicit thing. Not to
> mention the user is supposed to set either:
>
>   FFMPEG_IMPL=libav
>
> or:
>
>   FFMPEG_IMPL=
>
> which is nowhere close to sane :).
>

With only one flag, why bother with the USE_EXPAND?


Reply | Threaded
Open this post in threaded view
|

Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Ben de Groot-2
On 3 February 2015 at 00:00, Michael Orlitzky <[hidden email]> wrote:

> On 02/02/2015 10:50 AM, Michał Górny wrote:
>>
>> Maybe. Though it still will keep the confusion of !libav meaning ffmpeg.
>>
>
> We could remove USE=libav from the tree, leaving only USE=ffmpeg. Then
> ffmpeg_impl_libav would switch the implementation if USE=ffmpeg is enabled.
>
>
>
>> Maybe a little cleaner but still relies on the implicit thing. Not to
>> mention the user is supposed to set either:
>>
>>   FFMPEG_IMPL=libav
>>
>> or:
>>
>>   FFMPEG_IMPL=
>>
>> which is nowhere close to sane :).
>>
>
> With only one flag, why bother with the USE_EXPAND?
>
>

Actually, after reading this conversation, I don't think we need the
USE_EXPAND. The current solution with USE="ffmpeg libav" works. It may
not be the cleanest, but the other solution proposed here doesn't add
that much.

Please restore the news item and unmask the revbumps, so we can get on
with business. :)

--
Cheers,

Ben | yngwin
Gentoo developer

Reply | Threaded
Open this post in threaded view
|

Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Ulrich Mueller-2
In reply to this post by Alexis Ballier-2
>>>>> On Mon, 2 Feb 2015, Alexis Ballier wrote:

> Ulrich Mueller <[hidden email]> wrote:

>> In a nutshell, you have a binary choice here, namely ffmpeg or
>> libav as implementation, and instead of one USE flag you want to
>> introduce two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of
>> the 4 possible combinations only 2 are valid. So you need a
>> REQUIRED_USE to forbid some combinations.

> We already have three possibilities: ffmpeg, libav or none (only for
> some packages but they do exist).

Right.

> With the N-1th proposal, it was overseen that USE="-ffmpeg libav"
> should be forbidden by REQUIRED_USE.

Why? When you have USE="-ffmpeg", the libav flag is a "don't care"
which is ignored. "ffmpeg" controls the feature, "libav" chooses the
implementation. This is very clear from the flags' descriptions and
was also well explained in the (N-1) news item.

   -ffmpeg -libav -> none
   -ffmpeg +libav -> none
   +ffmpeg -libav -> ffmpeg
   +ffmpeg +libav -> libav

> With the N-1th proposal, we had two bits (USE='ffmpeg libav') to
> code 3 states. With the above proposal, we have a kind of unary
> coding: USE=-ffmpeg means 'none', USE=ffmpeg + ffmpeg_impl_$x means
> '$x'.

Yes, but you would then have 3 bits (i.e. 8 combinations) to code only
3 possible states.

> I understand your point; I'm not entirely convinced which one is
> better, but I'm tempted by the simplicity for users of the above
> unary proposal.

Ulrich

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Ulrich Mueller-2
In reply to this post by Ben de Groot-2
>>>>> On Tue, 3 Feb 2015, Ben de Groot wrote:

> Please restore the news item and unmask the revbumps, so we can get on
> with business. :)

+1

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Alexis Ballier-2
In reply to this post by Ulrich Mueller-2
On Mon, 2 Feb 2015 17:14:22 +0100
Ulrich Mueller <[hidden email]> wrote:

> >>>>> On Mon, 2 Feb 2015, Alexis Ballier wrote:
>
> > Ulrich Mueller <[hidden email]> wrote:
>
> >> In a nutshell, you have a binary choice here, namely ffmpeg or
> >> libav as implementation, and instead of one USE flag you want to
> >> introduce two (ffmpeg_impl_ffmpeg and ffmpeg_impl_libav), but of
> >> the 4 possible combinations only 2 are valid. So you need a
> >> REQUIRED_USE to forbid some combinations.
>
> > We already have three possibilities: ffmpeg, libav or none (only for
> > some packages but they do exist).
>
> Right.
>
> > With the N-1th proposal, it was overseen that USE="-ffmpeg libav"
> > should be forbidden by REQUIRED_USE.
>
> Why? When you have USE="-ffmpeg", the libav flag is a "don't care"
> which is ignored. "ffmpeg" controls the feature, "libav" chooses the
> implementation. This is very clear from the flags' descriptions and
> was also well explained in the (N-1) news item.

Would you offer me a beer each time I'll point you at some user doing
USE='-ffmpeg libav' because he wants libav only ? :)

> > With the N-1th proposal, we had two bits (USE='ffmpeg libav') to
> > code 3 states. With the above proposal, we have a kind of unary
> > coding: USE=-ffmpeg means 'none', USE=ffmpeg + ffmpeg_impl_$x means
> > '$x'.
>
> Yes, but you would then have 3 bits (i.e. 8 combinations) to code only
> 3 possible states.

Yes, unary is very inefficient :)


My real answer is: I don't know, I'm fine with both, but IMHO we should
aim at something natural and straightforward for users.

(and if I can get free beer, that's even better :) )


Alexis.

Reply | Threaded
Open this post in threaded view
|

Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Ulrich Mueller-2
>>>>> On Mon, 2 Feb 2015, Alexis Ballier wrote:

> On Mon, 2 Feb 2015 17:14:22 +0100
> Ulrich Mueller <[hidden email]> wrote:

>> Why? When you have USE="-ffmpeg", the libav flag is a "don't care"
>> which is ignored. "ffmpeg" controls the feature, "libav" chooses
>> the implementation. This is very clear from the flags' descriptions
>> and was also well explained in the (N-1) news item.

> Would you offer me a beer each time I'll point you at some user
> doing USE='-ffmpeg libav' because he wants libav only ? :)

"-ffmpeg libav" is a valid combination, given that "ffmpeg" can be set
per-package, whereas typically there would be only a global setting of
"libav". It is quite a similar situation to what we had with openmotif
and lesstif, where the motif flag enabled the feature, and the lesstif
flag chose the implementation.

Or is it the name of the flag that is causing confusion? That could be
changed.

Ulrich

attachment0 (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Michał Górny-5
Dnia 2015-02-02, o godz. 18:08:01
Ulrich Mueller <[hidden email]> napisał(a):

> >>>>> On Mon, 2 Feb 2015, Alexis Ballier wrote:
>
> > On Mon, 2 Feb 2015 17:14:22 +0100
> > Ulrich Mueller <[hidden email]> wrote:
>
> >> Why? When you have USE="-ffmpeg", the libav flag is a "don't care"
> >> which is ignored. "ffmpeg" controls the feature, "libav" chooses
> >> the implementation. This is very clear from the flags' descriptions
> >> and was also well explained in the (N-1) news item.
>
> > Would you offer me a beer each time I'll point you at some user
> > doing USE='-ffmpeg libav' because he wants libav only ? :)
>
> "-ffmpeg libav" is a valid combination, given that "ffmpeg" can be set
> per-package, whereas typically there would be only a global setting of
> "libav". It is quite a similar situation to what we had with openmotif
> and lesstif, where the motif flag enabled the feature, and the lesstif
> flag chose the implementation.
It is valid but USE=libav is then unexpectedly meaningless :). This
thread alone shows how confused users are by it.

> Or is it the name of the flag that is causing confusion? That could be
> changed.

Maybe. But there's no good solution for that either. My USE=avcodec idea
brought many complaints... But even then, regular USE flags for this
kind of global switch don't work well.

Maybe we should do the Arfrever thing. USE=ffmpeg-or-libav
and USE=ffmpeg-instead-of-libav. This will avoid most of the confusion,
though ffmpeg users will complain that we don't have
USE=libav-instead-of-ffmpeg instead.

--
Best regards,
Michał Górny

attachment0 (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Michał Górny-5
In reply to this post by Michael Orlitzky
Dnia 2015-02-02, o godz. 11:00:59
Michael Orlitzky <[hidden email]> napisał(a):

> On 02/02/2015 10:50 AM, Michał Górny wrote:
> >
> > Maybe. Though it still will keep the confusion of !libav meaning ffmpeg.
> >
>
> We could remove USE=libav from the tree, leaving only USE=ffmpeg. Then
> ffmpeg_impl_libav would switch the implementation if USE=ffmpeg is enabled.

Wasn't that your point in the first mail?

> > Maybe a little cleaner but still relies on the implicit thing. Not to
> > mention the user is supposed to set either:
> >
> >   FFMPEG_IMPL=libav
> >
> > or:
> >
> >   FFMPEG_IMPL=
> >
> > which is nowhere close to sane :).
> >
>
> With only one flag, why bother with the USE_EXPAND?
Because otherwise we're back to USE=libav, only named different
and illegally as well (PMS sez _ is reserved for USE_EXPAND).

--
Best regards,
Michał Górny

attachment0 (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Alexis Ballier-2
In reply to this post by Ulrich Mueller-2
On Mon, 2 Feb 2015 18:08:01 +0100
Ulrich Mueller <[hidden email]> wrote:

> >>>>> On Mon, 2 Feb 2015, Alexis Ballier wrote:
>
> > On Mon, 2 Feb 2015 17:14:22 +0100
> > Ulrich Mueller <[hidden email]> wrote:
>
> >> Why? When you have USE="-ffmpeg", the libav flag is a "don't care"
> >> which is ignored. "ffmpeg" controls the feature, "libav" chooses
> >> the implementation. This is very clear from the flags' descriptions
> >> and was also well explained in the (N-1) news item.
>
> > Would you offer me a beer each time I'll point you at some user
> > doing USE='-ffmpeg libav' because he wants libav only ? :)
>
> "-ffmpeg libav" is a valid combination, given that "ffmpeg" can be set
> per-package, whereas typically there would be only a global setting of
> "libav". It is quite a similar situation to what we had with openmotif
> and lesstif, where the motif flag enabled the feature, and the lesstif
> flag chose the implementation.

Even though I got the ffmpeg/libav flags right, the motif situation
actually always confused me :/

> Or is it the name of the flag that is causing confusion? That could be
> changed.

I guess the flag name isn't helping indeed. The initial proposal wanted
to preserve the meaning of the 'ffmpeg' useflag, breaking the symmetry
between ffmpeg & libav flags. Michal proposed the 'libavcodec' flag to
restore it, but IMHO this was even worse. If you happen to have an idea
of a correct name for a flag that enables some of 'libavcodec,
libavutil, libavformat, libswscale, libavresample, libswresample or
libavdevice' support, then please shout.

What I find interesting in this proposal is that ffmpeg useflag keeps
its old meaning, and we have a symmetric setting for choosing the
implementation.

Alexis.

Reply | Threaded
Open this post in threaded view
|

Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Michał Górny-5
Dnia 2015-02-02, o godz. 18:18:14
Alexis Ballier <[hidden email]> napisał(a):

> On Mon, 2 Feb 2015 18:08:01 +0100
> Ulrich Mueller <[hidden email]> wrote:
>
> > >>>>> On Mon, 2 Feb 2015, Alexis Ballier wrote:
> >
> > > On Mon, 2 Feb 2015 17:14:22 +0100
> > > Ulrich Mueller <[hidden email]> wrote:
> >
> > >> Why? When you have USE="-ffmpeg", the libav flag is a "don't care"
> > >> which is ignored. "ffmpeg" controls the feature, "libav" chooses
> > >> the implementation. This is very clear from the flags' descriptions
> > >> and was also well explained in the (N-1) news item.
> >
> > > Would you offer me a beer each time I'll point you at some user
> > > doing USE='-ffmpeg libav' because he wants libav only ? :)
> >
> > "-ffmpeg libav" is a valid combination, given that "ffmpeg" can be set
> > per-package, whereas typically there would be only a global setting of
> > "libav". It is quite a similar situation to what we had with openmotif
> > and lesstif, where the motif flag enabled the feature, and the lesstif
> > flag chose the implementation.
>
> Even though I got the ffmpeg/libav flags right, the motif situation
> actually always confused me :/
>
> > Or is it the name of the flag that is causing confusion? That could be
> > changed.
>
> I guess the flag name isn't helping indeed. The initial proposal wanted
> to preserve the meaning of the 'ffmpeg' useflag, breaking the symmetry
> between ffmpeg & libav flags. Michal proposed the 'libavcodec' flag to
> restore it, but IMHO this was even worse. If you happen to have an idea
> of a correct name for a flag that enables some of 'libavcodec,
> libavutil, libavformat, libswscale, libavresample, libswresample or
> libavdevice' support, then please shout.
>
> What I find interesting in this proposal is that ffmpeg useflag keeps
> its old meaning, and we have a symmetric setting for choosing the
> implementation.
Yes. And think of the beauty of:

  FFMPEG_IMPL=ffmpeg
  FFMPEG_IMPL=libav

You may even imagine it a regular string config, not a USE_EXPAND!

Wes has compared this to ruby & python. One USE=python|ruby on some
packages to enable the optional support, and generic globally set
RUBY/PYTHON_TARGETS.

--
Best regards,
Michał Górny

attachment0 (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Michał Górny-5
In reply to this post by Michał Górny-5
Dnia 2015-02-02, o godz. 15:06:40
Michał Górny <[hidden email]> napisał(a):

> The idea is that instead of having USE=libav (that's tangential to
> USE=ffmpeg and confusing) to use a USE_EXPAND like FFMPEG_IMPL taking
> either ffmpeg or libav. Now, why...

Ok, since this is going to be a long night, a quick summary of
the alternatives.

First of all, plain USE='ffmpeg libav' where each one signifies one of
the impls. This can't work because we already have packages that depend
on, say, 'app-misc/tracker[ffmpeg]'. If we replaced that with two
optional flags, we'd have to do '|| ( tracker[ffmpeg] tracker[libav]
)'. And || () deps are pretty much fragile, don't support := operator
and cause unpredictable blockers during dependency resolution. So this
can't work.

Secondly, global variables that are not USE flags. They can't work
since the dependencies in ebuilds need to be consistent and can not be
affected by external variables.

Thirdly, || () blocks. I already listed above why they must not be used.


So, after throwing all technically unsound solutions, we are left with
having to have exactly one *feature flag* -- the flag that enables
ffmpeg-or-libav support in the packages that have it optional, and one
or more *implementation flags* that select the implementation when more
than one can be used.

For feature flag, name is the only issue. Currently USE=ffmpeg serves
that purpose and I think changing that would have a very high cost
(and cause a lot of bikeshed), esp. if we would end up reusing the flag
for another purpose. So most likely leave it as-is.

For implementation flags, we have three options:

a. one binary 'libav' flag that switches between the two
implementations,

b. two regular unary flags that select one of the implementations,

c. two USE_EXPAND unary flags that select one of the implementations.


A. binary 'libav' flag (or similar)

 default set in profiles:

   USE="${USE} libav"

 user changes impl to ffmpeg:

   USE="-libav"

 portage output:

   media-video/foo USE="... ffmpeg ... libav ..."

 ebuild code:

   IUSE="ffmpeg libav"

   RDEPEND="
     ffmpeg? (
       !libav? ( media-video/ffmpeg:0= )
       libav? ( media-video/libav:0= )
     )"

 non-meaningful flag combinations:

   USE="-ffmpeg libav" -> doesn't give you libav


B. two regular unary flags (i'm going to use ffmpeg/libav here but
the names would likely have to be different)

 default set in profiles:

   USE="${USE} libav"

 user changes impl to ffmpeg:

   USE="-libav ffmpeg"

 portage output:

   media-video/foo USE="... avcodec ... libav ... -ffmpeg ..."

 ebuild code:

   IUSE="avcodec ffmpeg libav"

   RDEPEND="
     avcodec? (
       ffmpeg? ( media-video/ffmpeg:0= )
       libav? ( media-video/libav:0= )
     )"

   REQUIRED_USE="avcodec? ( ^^ ( ffmpeg libav ) )"

 non-meaningful flag combinations:

   USE="-avcodec *" -> doesn't give you libav or ffmpeg

 disallowed flag combinations:

   USE="avcodec -ffmpeg -libav" -> no implementation selected
   USE="avcodec ffmpeg libav" -> multiple implementations selected


C. two USE_EXPAND unary flags

 default set in profiles:

   FFMPEG_IMPL="libav"

 user changes impl to ffmpeg:

   FFMPEG_IMPL=ffmpeg

 portage output:

   media-video/foo USE="... ffmpeg ..." FFMPEG_IMPL="libav -ffmpeg"

 ebuild code (yeah, pain to type -- but only once...):

   IUSE="ffmpeg ffmpeg_impl_ffmpeg ffmpeg_impl_libav"

   RDEPEND="
     ffmpeg? (
       ffmpeg_impl_ffmpeg? ( media-video/ffmpeg:0= )
       ffmpeg_impl_libav? ( media-video/libav:0= )
     )"

   REQUIRED_USE="ffmpeg? ( ^^ ( ffmpeg_impl_ffmpeg ffmpeg_impl_libav ) )"

 non-meaningful flag combinations:

   USE="-ffmpeg" FFMPEG_IMPL="*" -> doesn't give you libav or ffmpeg

 disallowed flag combinations:

   USE="ffmpeg" FFMPEG_IMPL="-ffmpeg -libav" -> no implementation selected
   USE="ffmpeg" FFMPEG_IMPL="ffmpeg libav" -> multiple implementations selected


--
Best regards,
Michał Górny

attachment0 (968 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Quick RFC: USE=libav vs FFMPEG_IMPL=libav|ffmpeg

Michael Orlitzky
On 02/02/2015 05:47 PM, Michał Górny wrote:
>
> For feature flag, name is the only issue. Currently USE=ffmpeg serves
> that purpose and I think changing that would have a very high cost
> (and cause a lot of bikeshed), esp. if we would end up reusing the flag
> for another purpose. So most likely leave it as-is.

Agreed.


> For implementation flags, we have three options:
>
> a. one binary 'libav' flag that switches between the two
> implementations,
>

This is what I was trying to convey earlier.


>
>  non-meaningful flag combinations:
>
>    USE="-ffmpeg libav" -> doesn't give you libav
>
>

Except I wouldn't name the implementation flag "libav" because that's
confusing. Name it ffmpeg-impl-libav or whatever's allowed by the PMS. Then,

  USE="-ffmpeg ffmpeg-impl-libav" -> doesn't give you libav

is not weird.


12