Sounds like a bug. The ebuild should depend on virtual/ffmpeg instead of depending on one of libav and ffpmeg directly. I think you should file a bug report in bugs.gentoo.org._________________emerge --quiet redefined | E17 vids: I, II | Now using e from git | e18, e19, and kde4 sucks :-/

No, a bugreport is not required. Just have a look at the ChangeLog of mpv:

Quote:

08 Jul 2013; Tom Wijsman <TomWij@gentoo.org> mpv-9999.ebuild:
Proxy commit by Nikoli: Explicitly depend on libav-9 and ffmpeg-1.2 instead of
virtual/ffmpeg-9, fixes bug #476222. Remove warning about CFLAGS and LDFLAGS,
we now append our flags instead of replacing upstream's flags. Removed some
configure options which upstream no longer provides, some USE flag behavior
was changed as a result. USE flag radio now has correct dependencies, it no
longer depends on oss; added threads USE flag.

IMHO the tree should be cleaned regarding deps on [virtual,media-video]/ffmpeg. If packages don't pull in the virtual you can be sure it is by intention.

No, a bugreport is not required. Just have a look at the ChangeLog of mpv:

Quote:

08 Jul 2013; Tom Wijsman <TomWij@gentoo.org> mpv-9999.ebuild:
Proxy commit by Nikoli: Explicitly depend on libav-9 and ffmpeg-1.2 instead of
virtual/ffmpeg-9, fixes bug #476222. Remove warning about CFLAGS and LDFLAGS,
we now append our flags instead of replacing upstream's flags. Removed some
configure options which upstream no longer provides, some USE flag behavior
was changed as a result. USE flag radio now has correct dependencies, it no
longer depends on oss; added threads USE flag.

IMHO the tree should be cleaned regarding deps on [virtual,media-video]/ffmpeg. If packages don't pull in the virtual you can be sure it is by intention.

I would consider it a bug, irrespective of what the Changelog says. When one runs "emerge mpv", this kind of blockers shouldn't crop up. It may not be a bug in mpv but a bug in portage.

Edit: Ok. I see where the blocker is coming from. It depends on >=ffmpeg-1.2 which is hard masked._________________emerge --quiet redefined | E17 vids: I, II | Now using e from git | e18, e19, and kde4 sucks :-/

Save yourself the trouble, that ebuild change appeared to be problematic.

+ 17 Jul 2013; Tom Wijsman <TomWij@g.o> mpv-0_p20130715.ebuild,
+ mpv-9999.ebuild:
+ Made ffmpeg dependency consistent; that way, it doesn't satisfy and block
+ itself at the same time if the user has a lower version installed. Discovered
+ in topic #964594 on the Gentoo Forums.

No, in reality there should be no blocker for this scenario; therefore I changed the ffmpeg dependencies to match when USE has +postproc such that it will show that it really needs the >=media-video/ffmpeg-1.2 and can't satisfy that as it is masked. It would then output the typical message indicating that no satisfied dependencies would be find, alongside the mask message. But what we have seen, is that it satisfied both due to a lack of backtracking as it blocks media-video/ffmpeg (as it is installed; so, it satisfies it while it shouldn't because there is another more strict dep) against >=media-video/libav-9:=[encode?,threads?,vdpau?]. Instead of that, it is now made to do a hard dependency on >=media-video/ffmpeg-1.2[encode?,threads?,vdpau?] when USE has +postproc as it was supposed to do; but due to dependency graph resolution limitations, it did never come to that condition. It's sad but true; some blockers aren't really blockers, they are rather the consequence of the complexity and limitations involved...

ppurka wrote:

It depends on >=ffmpeg-1.2 which is hard masked.

Yes, in this scenario with +postproc in USE the only way to satisfy the dependencies is by unmasking >=media-video/ffmpeg-1.2 and giving it the same encore, threads and vdpau USE flags.

Run `pkg-config --modversion libavutil,libavcodec,libavformat,libswscale` to see which versions you have; as you can guess, you'll need a newer ffmpeg to make sure the versions are high enough for that line you quoted to be satisfied. I think you will need >=ffmpeg-1.2...