Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Need feedback: interface for ffmpeg/libav pref selection
View unanswered posts
View posts from last 24 hours

Goto page 1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  

Which of variants in post 1 would you prefer?
A (USE=libav for libav, USE=-libav for ffmpeg, USE=ffmpeg for optional libav/ffmpeg)
24%
 24%  [ 18 ]
B (USE=ffmpeg/libav to select, and USE=avcodec for optional either of them)
29%
 29%  [ 22 ]
C (FFMPEG_IMPL=ffmpeg/libav to select, USE=ffmpeg for optional either of the impls)
45%
 45%  [ 34 ]
Total Votes : 74

Author Message
mgorny
Developer
Developer


Joined: 27 Apr 2007
Posts: 83

PostPosted: Mon Feb 02, 2015 11:14 pm    Post subject: Need feedback: interface for ffmpeg/libav pref selection Reply with quote

Hello, users.

We are working on reimplementing ffmpeg/libav support in Gentoo and we kinda got stuck discussing the possible implementation details. Since the final outcome will affect how users see the implementation choice and set their preference, I would like to ask for your opinion.

If someone's interested in pure technical details, mailing list thread and especially possibility listing post.

TL;DR: after throwing all the technically impossible stuff, we have to keep USE=ffmpeg as-is (that is, to enable either ffmpeg/libav if it's optional in a package) and need to introduce extra flags to switch between ffmpeg and libav. Three possibilities are being discussed:

A. single USE=libav that uses libav, USE=-libav uses ffmpeg.

B. two USE flags you'd have to choose from. Like USE='ffmpeg libav' (we'd have to change the current USE=ffmpeg to something else).

C. a two-value USE_EXPAND you'd have to choose from. Like FFMPEG_IMPL='ffmpeg' or FFMPEG_IMPL='libav'.


Now into more details with the options.

Option A implies that for every package supporting both ffmpeg and libav, you'd see:

Code:
dev-libs/foo-1.2.3 USE="... libav ..."

signifying that libav will be used, or:

Code:
dev-libs/foo-1.2.3 USE="... -libav ..."

signifying ffmpeg.

Additionally, some packages will have:

Code:
dev-libs/foo-1.2.3 USE="... ffmpeg ... libav ..."

which means enabling optional support for libav, and:

Code:
dev-libs/foo-1.2.3 USE="... ffmpeg ... -libav ..."

which means enabling optional support for ffmpeg. What's really bad is that:

Code:
dev-libs/foo-1.2.3 USE="... -ffmpeg ... libav ..."

will mean no ffmpeg and no libav (since USE=-ffmpeg takes precedence over libav).

If Gentoo set libav as the default, you'd switch to ffmpeg by setting in make.conf:

Code:
USE="-libav"

but you can't change libav in package.use as that will wreak havoc trying to install ffmpeg and libav at the same time.


Option B goes for:

Code:
dev-libs/foo-1.2.3 USE="... ffmpeg-libav ... -ffmpeg-ffmpeg ..."

signifying that libav will be used, or:

Code:
dev-libs/foo-1.2.3 USE="... ffmpeg-ffmpeg ... -ffmpeg-libav ..."

signifying ffmpeg.

Additionally, some packages will have:

Code:
dev-libs/foo-1.2.3 USE="... ffmpeg ... ffmpeg-libav ... -ffmpeg-ffmpeg ..."

which means enabling optional support for libav, and:

Code:
dev-libs/foo-1.2.3 USE="... ffmpeg ... ffmpeg-ffmpeg ... -ffmpeg-libav ..."

which means enabling optional support for ffmpeg.

Code:
dev-libs/foo-1.2.3 USE="... -ffmpeg ... -ffmpeg-ffmpeg ... ffmpeg-libav ..."

will mean no ffmpeg and no libav (since USE=-ffmpeg).

If Gentoo set libav as the default, you'd switch to ffmpeg by setting in make.conf:

Code:
USE="-ffmpeg-libav ffmpeg-ffmpeg"

and you can't change those two flags in package.use.



Option C is only a little different (since it detaches ffmpeg&libav from USE):

Code:
dev-libs/foo-1.2.3 USE="..." FFMPEG_IMPL="libav -ffmpeg"

signifying that libav will be used, or:

Code:
dev-libs/foo-1.2.3 USE="..." FFMPEG_IMPL="ffmpeg -libav"

signifying ffmpeg.

Additionally, some packages will have:

Code:
dev-libs/foo-1.2.3 USE="... ffmpeg ..." FFMPEG_IMPL="libav -ffmpeg"

which means enabling optional support for libav, and:

Code:
dev-libs/foo-1.2.3 USE="... ffmpeg ..." FFMPEG_IMPL="ffmpeg -libav"

which means enabling optional support for ffmpeg.

Code:
dev-libs/foo-1.2.3 USE="... -ffmpeg ..." FFMPEG_IMPL="-ffmpeg libav"

will mean no ffmpeg and no libav (since USE=-ffmpeg disables use of FFMPEG_IMPL).

If Gentoo set libav as the default, you'd switch to ffmpeg by setting in make.conf:

Code:
FFMPEG_IMPL=ffmpeg

and you are not supposed to use that in package.use :).


Which of the three variants would you prefer?


Last edited by mgorny on Tue Feb 03, 2015 1:18 pm; edited 1 time in total
Back to top
View user's profile Send private message
The Doctor
Moderator
Moderator


Joined: 27 Jul 2010
Posts: 2678

PostPosted: Mon Feb 02, 2015 11:36 pm    Post subject: Reply with quote

I like A because it requires the least amount of study for the user. Personally, I just threw ffmpeg into package.mask so portage would know which one to use. C would also be a nice way to do it, but then it starts to sound like extra clutter for make.conf.

The reason I dislike changing the meaning of ffmpeg is that will mean head aches for many people trying to figure it out.
_________________
First things first, but not necessarily in that order.

Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box.
Back to top
View user's profile Send private message
tclover
Guru
Guru


Joined: 10 Apr 2011
Posts: 516

PostPosted: Mon Feb 02, 2015 11:39 pm    Post subject: Reply with quote

I guess keeping the actual behaviour as is is fine as well... no extra work required since option C seems to be more practicable without extra USE flags mess, package rebuilds and such. Does setting up FFMPEG_IMPL environment variable looks to be better? or strait forward? or _more_ simple? instead of just installing in ffmpeg or libav? or paritcular package pulling in ffmpeg or libav depending on the compatibility/version (ABI/API)? It looks like FFMPEG_IMPL could be a burden in this latter case. So, I'm in the 'keep as is', install whatever requested or wanted without extra step or work.
_________________
home/:mkinitramfs-ll/:supervision/:e-gtk-theme/:overlay/
Back to top
View user's profile Send private message
miket
Guru
Guru


Joined: 28 Apr 2007
Posts: 483
Location: Gainesville, FL, USA

PostPosted: Tue Feb 03, 2015 1:14 am    Post subject: Reply with quote

Here's what this kind of thing comes down for me.

Want ffmpeg?
Code:
emerge -1 media-video/ffmpeg


Rather have libav?
Code:
emerge -1 media-video/libav


Do one of these before emerging whatever has USE=ffmpeg.

I would think that before deciding on what rule for just this case, it would be better to get an idea of a what general pattern to prefer throughout the distribution to handle the selection of the dependency to satisfy a virtual. Having a way to choose between ffmpeg and libav is nice for deciding how to satisfy virtual/ffmpeg, but it would be far more satifying if there were a consistent way across at least most of the 197 virtuals in Portage. Without that, I'd be just as happy to stick with the procedure above.
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Tue Feb 03, 2015 1:51 am    Post subject: Re: Need feedback: interface for ffmpeg/libav pref selection Reply with quote

I like C
Because it hold the most logic for me.
But at the same time that last case of it
I cannot stand, kind of two edges way around (un)logic:
mgorny wrote:
Code:
dev-libs/foo-1.2.3 USE="... -ffmpeg ..." FFMPEG_IMPL="-ffmpeg libav"

will mean no ffmpeg and no libav (since USE=-ffmpeg disables use of FFMPEG_IMPL).

Why not a syntax error if more than one word or a minus '-' sign in it?
Just allow these three cases:

FFMPEG_IMPL="libav"
FFMPEG_IMPL="ffmpeg"
FFMPEG_IMPL=""

The last means having NIL
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Tue Feb 03, 2015 3:05 am    Post subject: Re: Need feedback: interface for ffmpeg/libav pref selection Reply with quote

mgorny wrote:
TL;DR: after throwing all the technically impossible stuff, we have to keep USE=ffmpeg as-is (that is, to enable either ffmpeg/libav if it's optional in a package) and need to introduce extra flags to switch between ffmpeg and libav. Three possibilities are being discussed:

mgorny ... doesn't that rule out option B:

mgorny wrote:
B. two USE flags you'd have to choose from. Like USE='ffmpeg libav' (we'd have to change the current USE=ffmpeg to something else).

... or am I misunderstanding something?

mgorny wrote:
A. single USE=libav that uses libav, USE=-libav uses ffmpeg.

Isn't this what we have currently as per eselect news 2015-02-01-use-libav? Probably not very intuitive as ffmpeg suggests media-video/ffmpeg whereas -libav doesn't. It might actually be the least disruptive of the {2,3} choices, but I can foresee users being thoroughly confused about the matter ... particularly as this would amount to ffmpeg denoting one feature (applying to both ffmpeg and libav) and libav another.

mgorny wrote:
C. a two-value USE_EXPAND you'd have to choose from. Like FFMPEG_IMPL='ffmpeg' or FFMPEG_IMPL='libav'.

As to timing if this is to be why not coordinated its release to coincide with CPU_FLAGS_X86?

mgorny wrote:
Which of the three variants would you prefer?

I take it that remaining as it is/was, or other suggestions, are not an option? If 2015-02-01-use-libav is correct then hasn't this decision already been made? Also, if this is to serve as a poll you should add "none of the above" so that objections to the provided choices can be voiced.

best ... khay
Back to top
View user's profile Send private message
BlueFusion
Guru
Guru


Joined: 08 Mar 2006
Posts: 371

PostPosted: Tue Feb 03, 2015 3:26 am    Post subject: Reply with quote

Option C seems the most appropriate and simple.

'I want ffmpeg or ffmpeg-like support so I will have USE="ffmpeg".'

'I want to use libav instead of ffmpeg, so I will tell Portage with FFMPEG_IMPL="libav".'
Back to top
View user's profile Send private message
ulm
Developer
Developer


Joined: 04 Oct 2004
Posts: 98
Location: Mainz, Germany

PostPosted: Tue Feb 03, 2015 6:05 am    Post subject: Reply with quote

Both options B and C violate the KISS principle, because where one flag would be sufficient, you will have two. Which are mutually exclusive, so you must jump through hoops (i.e. REQUIRED_USE) to suppress the meaningless combinations.

With regard to option C: I fear that the USE_EXPAND setting will be hard to find for users who prefer the implementation that is not the default (i.e. if they want ffmpeg). Tools like ufed and flaggie support normal USE flags only.
Back to top
View user's profile Send private message
Fitzcarraldo
Advocate
Advocate


Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom

PostPosted: Tue Feb 03, 2015 10:08 am    Post subject: Reply with quote

I prefer Option A, because a single flag takes care of everything. Less confusing, in my opinion.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.

Fitzcarraldo's blog
Back to top
View user's profile Send private message
xaviermiller
Bodhisattva
Bodhisattva


Joined: 23 Jul 2004
Posts: 8706
Location: ~Brussels - Belgique

PostPosted: Tue Feb 03, 2015 10:22 am    Post subject: Reply with quote

Hello,

Why a virtual is not sufficient? If we do this for libav/ffmpeg, why don't we do it for all the other virtuals:
- libressl / openssl
- udev / eudev / mdev / systemd
- gcc / llvm
?

EDIT: why can't we add a USE on virtual/ffmpeg that will choose the iplementation.

Adding more and more configurations variables in portage will tend to complexity.
_________________
Kind regards,
Xavier Miller


Last edited by xaviermiller on Tue Feb 03, 2015 10:31 am; edited 1 time in total
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7470

PostPosted: Tue Feb 03, 2015 10:23 am    Post subject: Reply with quote

I'd like option D
USE="ffmpeg" -> ffmpeg
USE="-ffmpeg" -> libav

option A looks the easiest, but i dislike the idea of using -ffmpeg to get ffmpeg, ffmpeg is ffmpeg not libav, the tag should aim the original package not the fork. I don't find any logic that to get ffmpeg i must tell portage -ffmpeg!
Back to top
View user's profile Send private message
Fitzcarraldo
Advocate
Advocate


Joined: 30 Aug 2008
Posts: 2034
Location: United Kingdom

PostPosted: Tue Feb 03, 2015 11:29 am    Post subject: Reply with quote

krinn wrote:
I'd like option D
USE="ffmpeg" -> ffmpeg
USE="-ffmpeg" -> libav

option A looks the easiest, but i dislike the idea of using -ffmpeg to get ffmpeg, ffmpeg is ffmpeg not libav, the tag should aim the original package not the fork. I don't find any logic that to get ffmpeg i must tell portage -ffmpeg!

Yes, I would have preferred that too, but, if I understand mgorny's post correctly, there would already be a ffmpeg USE flag:

mgorny wrote:
after throwing all the technically impossible stuff, we have to keep USE=ffmpeg as-is (that is, to enable either ffmpeg/libav if it's optional in a package) and need to introduce extra flags to switch between ffmpeg and libav.

which is presumably why he did not propose what you call 'Option D' as 'Option A'.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC udev elogind & KDE on both.

Fitzcarraldo's blog
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Tue Feb 03, 2015 12:03 pm    Post subject: Reply with quote

ulm wrote:
Both options B and C violate the KISS principle, because where one flag would be sufficient, you will have two.

KISS does not mean to minimize the number of flags. It means to keep flags clearly structured and possibly generic.
Someday a third ffmpeg fork might appear, and in this moment the previous saving of one flag turns to a catastrophe.
Indeed, you do need only 2 flags to distinguish 3 cases - even to distinguish 4 cases if a third ffmpeg fork happens - but the latter example shows that minimizing the number of flags is exactly the opposite of KISS: The user would have to look up in a table which combination means what.

Quote:
so you must jump through hoops (i.e. REQUIRED_USE) to suppress the meaningless combinations.

So you prefer a simpler implementation over a simpler user interface. In fact, increasing the redundancy in the user's configuration and giving the user a feedback in the case of a mistake is a big advantage of C: The user gets the information that he misunderstood something, while with a smaller number of flags, he might possibly just end up with an undesired result.

Quote:
I fear that the USE_EXPAND setting will be hard to find for users who prefer the implementation that is not the default

Exactly this will not happen: If the user does not specify USE_EXPAND, he will get an error, doesn't he? (At least, this is how I would interpret option C; working here with use-defaults would be a bad idea).

Quote:
Tools like ufed and flaggie support normal USE flags only.

In ufed, this is planned, but not yet implemented AFAIK.

The documentation of USE_EXPAND is a separate problem: The documentation about this mechanism is rather hidden and unknown to many users; there were already such questions concerning CPU_FLAGS_X86 (e.g. how to change per-package in package.use): The new portage syntax for package.use is a step in the right direction, but all these things should be documented on the portage man page and possibly also in the handbook.
Back to top
View user's profile Send private message
Dr.Willy
Guru
Guru


Joined: 15 Jul 2007
Posts: 547
Location: NRW, Germany

PostPosted: Tue Feb 03, 2015 12:47 pm    Post subject: Reply with quote

Ok, maybe I'm missing something, but one thing isn't clear to me:
Why do we need two use-flags at all? Can't USE='ffmpeg' mean the package uses virtual/ffmpeg and have portage pick the right version? Or is virtual/ffmpeg no longer a thing?
Back to top
View user's profile Send private message
ulm
Developer
Developer


Joined: 04 Oct 2004
Posts: 98
Location: Mainz, Germany

PostPosted: Tue Feb 03, 2015 12:51 pm    Post subject: Reply with quote

mv wrote:
ulm wrote:
Both options B and C violate the KISS principle, because where one flag would be sufficient, you will have two.

KISS does not mean to minimize the number of flags. It means to keep flags clearly structured and possibly generic.
Someday a third ffmpeg fork might appear, and in this moment the previous saving of one flag turns to a catastrophe.
Indeed, you do need only 2 flags to distinguish 3 cases - even to distinguish 4 cases if a third ffmpeg fork happens - but the latter example shows that minimizing the number of flags is exactly the opposite of KISS: The user would have to look up in a table which combination means what.

Nobody has suggested to use two flags for choosing between three implementations. Apart from its being completely counterintuitive, it simply won't work, because one of the flags must be a feature flag (see mgorny's original post why that is so). Also we cannot plan for all eventualities: If a third ffmpeg implementation will appear, we must reconsider the situation in any case. Maybe it will be ABI compatible to one of the existing ones, so we could have a proper virtual? We cannot know beforehand.

Quote:
Quote:
I fear that the USE_EXPAND setting will be hard to find for users who prefer the implementation that is not the default

Exactly this will not happen: If the user does not specify USE_EXPAND, he will get an error, doesn't he? (At least, this is how I would interpret option C; working here with use-defaults would be a bad idea).

I fear that option C would bless us with exactly that, namely a default setting of FFMPEG_IMPL="-ffmpeg libav" in profiles.
Back to top
View user's profile Send private message
ulm
Developer
Developer


Joined: 04 Oct 2004
Posts: 98
Location: Mainz, Germany

PostPosted: Tue Feb 03, 2015 1:00 pm    Post subject: Reply with quote

Dr.Willy wrote:
Ok, maybe I'm missing something, but one thing isn't clear to me:
Why do we need two use-flags at all? Can't USE='ffmpeg' mean the package uses virtual/ffmpeg and have portage pick the right version? Or is virtual/ffmpeg no longer a thing?

There were concerns that after switching the implementation from ffmpeg to libav (or vice versa) reverse dependencies would be broken, but the package manager would not trigger their rebuilds: http://article.gmane.org/gmane.linux.gentoo.devel/94391
Generally, a virtual for libraries can only work if they are ABI compatible.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Tue Feb 03, 2015 1:28 pm    Post subject: Re: Need feedback: interface for ffmpeg/libav pref selection Reply with quote

khayyam wrote:
mgorny wrote:
A. single USE=libav that uses libav, USE=-libav uses ffmpeg.

Isn't this what we have currently as per eselect news 2015-02-01-use-libav?

... to answer my own question:

Code:
% eselect news list | grep libav
 [11]  2015-02-01  (2015-02-01-use-libav - removed?)
% eselect news read 11
2015-02-01-use-libav
!!! Warning: News item "2015-02-01-use-libav" no longer exists

... so it came ... and it went.

mv wrote:
Indeed, you do need only 2 flags to distinguish 3 cases - even to distinguish 4 cases if a third ffmpeg fork happens - but the latter example shows that minimizing the number of flags is exactly the opposite of KISS: The user would have to look up in a table which combination means what.

Yes, but you have to wonder why libav was added at all, that would seem to me the essential violation of KISS. The probability that were there another fork this would be added is next to nil, libav was added as there is a relation between the fork and parties doing the package maintenance. The "choice" (so to speak) is not one that benefits users (which is often the case with forks). It is libav's inclusion which is the causal origin of much of the subsequent issues as it rode on the 'ffmpeg' namespace, required the addition of virtual/ffmpeg, has various levels of support/breakage with regard to other packages (ie, media-video/mpv recommends ffmpeg over libav ... some packages are masked due to not building against, or having issues with, libav), etc, etc. In short, while the underlying theme of "choice" seems innocuous, it hasn't been of any real benefit to users.

So, this "problem" which we are trying to solve here seems to me entirely after-the-fact, if not casually the outcome of poor decisions made previously.

best ... khay
Back to top
View user's profile Send private message
mgorny
Developer
Developer


Joined: 27 Apr 2007
Posts: 83

PostPosted: Tue Feb 03, 2015 1:41 pm    Post subject: Reply with quote

The Doctor wrote:
I like A because it requires the least amount of study for the user. Personally, I just threw ffmpeg into package.mask so portage would know which one to use.

I doubt it actually would. It would more likely tell you to unmask ffmpeg :).

tclover wrote:
I guess keeping the actual behaviour as is is fine as well... [...] So, I'm in the 'keep as is', install whatever requested or wanted without extra step or work.

miket wrote:
Here's what this kind of thing comes down for me.

Want ffmpeg?
Code:
emerge -1 media-video/ffmpeg


Rather have libav?
Code:
emerge -1 media-video/libav

The current behavior is broken and doesn't really work. If i does, it's a pure coincidence that breaks other stuff you don't notice. I wouldn't waste two days of my life to replace something that works well. Long story short, if you try to install libav when you have ffmpeg installed you're more likely to see a lot of blockers than clean solution. And if it even succeeds installing it, revdeps won't be rebuilt later after upgrading libav because the dependency tree is silently broken.

EDIT: and please get me clear. I'm not only saying that the switch will result in possibility of immediately broken packages. I mean that the internal databases will be temporarily broken and further upgrades of libav can break stuff.

khayyam wrote:
mgorny wrote:
TL;DR: after throwing all the technically impossible stuff, we have to keep USE=ffmpeg as-is (that is, to enable either ffmpeg/libav if it's optional in a package) and need to introduce extra flags to switch between ffmpeg and libav. Three possibilities are being discussed:

mgorny ... doesn't that rule out option B:

mgorny wrote:
B. two USE flags you'd have to choose from. Like USE='ffmpeg libav' (we'd have to change the current USE=ffmpeg to something else).

... or am I misunderstanding something?

Well, it kinda does but it is technically possible. However, I changed the example to use different flags and not require changing USE=ffmpeg. Hope this illustrates it better.

khayyam wrote:
mgorny wrote:
A. single USE=libav that uses libav, USE=-libav uses ffmpeg.

Isn't this what we have currently as per eselect news 2015-02-01-use-libav?

The process has been stalled on users' request to reconsider the best solution. We didn't consider option C when working on A, and it seemed superior to me.

khayyam wrote:
mgorny wrote:
C. a two-value USE_EXPAND you'd have to choose from. Like FFMPEG_IMPL='ffmpeg' or FFMPEG_IMPL='libav'.

As to timing if this is to be why not coordinated its release to coincide with CPU_FLAGS_X86?

For a start, because we're still using CVS. Awesome, isn't it? But seriously, because big changes are big and hard to do many of them at once. Especially if you have to do all the work yourself.

khayyam wrote:
mgorny wrote:
Which of the three variants would you prefer?

I take it that remaining as it is/was, or other suggestions, are not an option?

We found no other working solution. If you can think of one that hasn't been thought yet, you have the possibility of adding a post and telling us about it.

I think all other concerns have been answered by ulm already.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Tue Feb 03, 2015 1:56 pm    Post subject: Reply with quote

mgorny wrote:
khayyam wrote:
I take it that remaining as it is/was, or other suggestions, are not an option?

We found no other working solution. If you can think of one that hasn't been thought yet, you have the possibility of adding a post and telling us about it.

mgorny ... none the less, as its a "poll" there needs to be a "none of the above" option, otherwise the "choices" preclude, and artificially limit, choice. As for a "working solution" not so far covered, we could drop libav entirely ... but my guess is this isn't on the table.

best ... khay
Back to top
View user's profile Send private message
Roman_Gruber
Advocate
Advocate


Joined: 03 Oct 2006
Posts: 3846
Location: Austro Bavaria

PostPosted: Tue Feb 03, 2015 2:42 pm    Post subject: Reply with quote

b) because it come near my choice for ffmpeg. but personally i prefer another option for ffmpeg as number 1

And option a) implies to look in the ebuild to realize that if you do not use libav ffmpeg is autoselected.

Bold question, do we really need libav? i know ffmpeg for ages and it worked for myself? Libav hmm never used / heard / whatever ... rant ...
Back to top
View user's profile Send private message
Dr.Willy
Guru
Guru


Joined: 15 Jul 2007
Posts: 547
Location: NRW, Germany

PostPosted: Tue Feb 03, 2015 2:48 pm    Post subject: Reply with quote

khayyam wrote:
As for a "working solution" not so far covered, we could drop libav entirely ...

Probably because that is not a "working solution" for anyone who wants to use libav.
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Tue Feb 03, 2015 3:14 pm    Post subject: Reply with quote

ulm wrote:
Nobody has suggested to use two flags for choosing between three implementations.

Nevertheless it is an example showing that merely minimizing the number of USE-flags should not be an aim and also does not necessarily keep things simple (from the user perspective; I agree that the package manager will have slightly more to do).
Quote:
If a third ffmpeg implementation will appear, we must reconsider the situation in any case.

I don't think so: The implementation is added to FFMPEG_IMPL, and packages just need to have the proper dependency; the latter must be decided per package anyway. At least, in contrast to the other options, this has a high chance to be a future-safe user interface.
Quote:
Maybe it will be ABI compatible to one of the existing ones, so we could have a proper virtual?

With a virtual we are again with the problem of := dependency not properly working (except if the fork has all subslots analogous so that the subslots can go into the virtual).
Quote:
I fear that option C would bless us with exactly that, namely a default setting of FFMPEG_IMPL="-ffmpeg libav" in profiles.

I would strongly vote against this, but C was not subdivided in the poll. Anyway, I do not see why this choice (or the opposite) would have need to be set by a profiles.
Note that this is in contrast to A where it is necessary that a profile decides for one of the two implementations as the default.
Back to top
View user's profile Send private message
miket
Guru
Guru


Joined: 28 Apr 2007
Posts: 483
Location: Gainesville, FL, USA

PostPosted: Tue Feb 03, 2015 3:23 pm    Post subject: Reply with quote

Finally, I thought of my preference. Remember that my big point was that the best solution should be the one that should be able to serve as the general pattern for all virtuals. There are way too many virtuals to go with a scattershot approach.

Saying USE=libav to indicate "build the package with libav instead of ffmpeg" does not square very well with "build my package without multimedia support" when you're using it to mean "build with libav instead of ffmpeg".

As others have pointed out, putting this setting in a place other than in the normal USE space makes things more tricky for some editors and for many users.

Here's my option E (option D already having been claimed):
Code:
USE=prefer_libav
that works independently of the setting of USE=ffmpeg.

The normal USE flags indicate how to build a normal package but not so much at how to build a virtual. The point of having virtuals, after all, is to allow for indirection in specifying the dependency for a normal package: in most cases, the user doesn't care a whole lot about which dependency of a virtual is the preferred one. The prefer_* series would govern virtuals only.

I'd be really happy to have this: USE="prefer_eudev prefer_vim"
Back to top
View user's profile Send private message
derk
Guru
Guru


Joined: 10 Mar 2003
Posts: 347
Location: St Thomas Ontario

PostPosted: Tue Feb 03, 2015 3:45 pm    Post subject: Reply with quote

what about the programs that are ffmpeg only .. not all are obsolete .. k9copy, or mplayer for instance .. there you must use ffmpeg only and that forces it globally.. you can not have both installed

Last edited by derk on Tue Feb 03, 2015 3:49 pm; edited 1 time in total
Back to top
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 10587
Location: Somewhere over Atlanta, Georgia

PostPosted: Tue Feb 03, 2015 3:49 pm    Post subject: Reply with quote

I don't think that's an issue. If a particular program depends on ffmpg explicitly then it can so depend. Programs that don't care can depend on the virtual. In other words, no need for concern.

- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum