The build greeted me with the following message: Unable to find development files for some of the required FFmpeg/Libav libraries. You need at least FFmpeg 3.2.2 or Libav 12. For FFmpeg, the mpv fork, that might contain additional fixes and features is required. It is available on https://github.com/mpv-player/ffmpeg-mpv Aborting. This is a consequence of: https://github.com/mpv-player/mpv/commit/83d44aca7dc7f46b8d3b64d441f5a8317a40e080 So there are two ways out: - Patch this out. - Package media-video/ffmpeg-mpv. Maybe also in that case, a "system-ffmpeg" useflag patching this out could be helpful.
Yes, I've seen this insanity. I'll work on patches to use system ffmpeg instead.
Easier than a patch is to add to CPPFLAGS: -DLIBAVCODEC_MPV=1 Alternatively, the easiest patch would be to modify the wscript to accept "is_ffmpeg_garbage": 'deps': 'is_ffmpeg || is_libav', => 'deps': 'is_ffmpeg_garbage || is_ffmpeg || is_libav',
Hi, (In reply to Coacher from comment #1) > Yes, I've seen this insanity. I'll work on patches to use system ffmpeg > instead. Is it possible to make it switch-able, i.e. `system-ffmpeg` vs `bundled-ffmpeg and static build`? AFAIK, www-client/chromium uses something like this. I'm afraid from now on mpv with every new commit will more and more depend on its own ffmpeg... Regards, Alex
(In reply to Oliver Freyermuth from comment #2) > Easier than a patch is to add to CPPFLAGS: > -DLIBAVCODEC_MPV=1 > Alternatively, the easiest patch would be to modify the wscript to accept > "is_ffmpeg_garbage": > 'deps': 'is_ffmpeg || is_libav', > => > 'deps': 'is_ffmpeg_garbage || is_ffmpeg || is_libav', now it doesn't work even with ffmpeg-9999 ------- Checking for FFmpeg/Libav present : yes Checking for libav* is FFmpeg mpv modified version : no Checking for libav* is upstream FFmpeg (unsupported) : yes Checking for libav* is Libav : no Checking for Libav/FFmpeg library versions : no ('libavutil >= 56.0.100 libavcodec >= 58.2.100 libavformat >= 58.0.102 libswscale >= 5.0.101 libavfilter >= 7.0.101 libswresample >= 3.0.100' not found -------
mpv-git can be built only with ffmpeg-mpv-git
https://github.com/mpv-player/mpv/pull/5058
Created attachment 501532 [details] mpv ebuild Not sure if up to QA, but I have working mpv and ffmpeg-mpv ebuilds Also not sure where these should go, so I will put them here. - mpv depends on and builds against media-video/ffmpeg-mpv - media-video/ffmpeg-mpv ebuild is modified ffmpeg ebuild changing only the install location and git repo - patch for mpv wscript is to bypass the version checking of ffmpeg-mpv libs, which I could not get working, could be improved.
Created attachment 501534 [details, diff] mpv patch for wscript
Created attachment 501536 [details] ffmpeg-mpv ebuild
(In reply to Brandon from comment #9) > Created attachment 501536 [details] > ffmpeg-mpv ebuild I have to build with ffmpeg git installed or mpv fails to link (non -9999 ffmpeg packages fail to link), and if I don't build one of these (ffmpeg or ffmpeg-mpv) with FFTOOLS set to -*, there are package collisions. Also I get that I am using a different runtime version of labavcodec when I run mpv -V: mpv 0.27.0-329-g501230f2a-dirty (C) 2000-2017 mpv/MPlayer/mplayer2 projects built on Wed Nov 1 02:08:15 EDT 2017 ffmpeg library versions: libavutil 56.0.100 libavcodec 58.2.100 (runtime 58.1.100) libavformat 58.0.102 libswscale 5.0.101 libavfilter 7.0.101 libswresample 3.0.101 ffmpeg version: N-88441-g17806f6083 Everything still works, though. Thanks for the working ebuilds!
(In reply to stressfactor from comment #10) > (In reply to Brandon from comment #9) > > Created attachment 501536 [details] > > ffmpeg-mpv ebuild > > I have to build with ffmpeg git installed or mpv fails to link (non -9999 > ffmpeg packages fail to link), and if I don't build one of these (ffmpeg or > ffmpeg-mpv) with FFTOOLS set to -*, there are package collisions. > > Also I get that I am using a different runtime version of labavcodec when I > run mpv -V: > > mpv 0.27.0-329-g501230f2a-dirty (C) 2000-2017 mpv/MPlayer/mplayer2 projects > built on Wed Nov 1 02:08:15 EDT 2017 > ffmpeg library versions: > libavutil 56.0.100 > libavcodec 58.2.100 (runtime 58.1.100) > libavformat 58.0.102 > libswscale 5.0.101 > libavfilter 7.0.101 > libswresample 3.0.101 > ffmpeg version: N-88441-g17806f6083 > > Everything still works, though. > Thanks for the working ebuilds! Turns out the problem with the runtime being different on running mpv -V was due to me not updating my tomoyo policies. Sorry, please ignore that part.
An alternative is to specify: --enable-ffmpeg-upstream which has been implemented by recent commits. It does not lead to an actually building mpv yet ( https://github.com/mpv-player/mpv/issues/5066 ) but I expect that, now that the first rage is over, future compatibility with ffmpeg will become better again. After all, maintaining ffmpeg-mpv is also a PITA for mpv. So my suggestion would be to add "system-ffmpeg" to the mpv live ebuild, and if that's done, set that flag. Depending on future developments, that could be default-on.
Thank you for patches and stuff, but I don't recognize any usefulness in bringing ffmpeg-mpv in Gentoo. It's going to be in unstable limbo and probably won't have any releases ever. Its only purpose is to please certain mpv devs [1,2]: " The real reason I'm doing is so I can control what FFmpeg is used exactly and therefore what set of APIs is available to me (as a developer) exactly. So I don't have to worry anymore about "when" I can use a certain new FFmpeg API. Having to worry about this is quite grating, especially when I added the API myself. I'm not interested in waiting weeks until I can get certain patches into ffmpeg, and then wait a few months until the next ffmpeg release, and a few years until distros like debian finally support it. Using a ffmpeg fork (which will always be just small patches ontop of upstream ffmpeg) will be so much easier. " Also "just let wm4 have his ragefork for a week or two" [3]. Currently one cannot build mpv-9999 with ffmpeg-9999, because some of the patches submitted by mpv devs weren't merged [2], which is the whole reason of this fork. However I'll put all the necessary machinery in the ebuild so it should build once ffmpeg devs review and merge those patches. [1]: https://github.com/mpv-player/mpv/commit/83d44aca7dc7f46b8d3b64d441f5a8317a40e080#commitcomment-25265847 [2]: https://github.com/mpv-player/mpv/commit/83d44aca7dc7f46b8d3b64d441f5a8317a40e080#commitcomment-25284292 [3]: https://github.com/mpv-player/mpv/commit/83d44aca7dc7f46b8d3b64d441f5a8317a40e080#commitcomment-25265847
PR: https://github.com/gentoo/gentoo/pull/6105
PR was merged. Standing by for any further updates upstream on the matter.
I'm not satisfied with this solution. Forcing mpv to use upstream ffmpeg means no support from the mpv developers, and ffmpeg's response to the ffmpeg-mpv situation has be less than impressed (apparently they made arbitrary changes to the ffmpeg-mpv/libav patches that not only introduce bugs but also seem explicitly designed to make compatibility a nightmare to maintain). I'd be happier using mpv with ffmpeg-mpv, rather than ffmpeg. Would it still be possible to package ffmpeg-mpv?
(In reply to Niklas Haas from comment #16) > I'm not satisfied with this solution. Forcing mpv to use upstream ffmpeg > means no support from the mpv developers, and ffmpeg's response to the > ffmpeg-mpv situation has be less than impressed (apparently they made > arbitrary changes to the ffmpeg-mpv/libav patches that not only introduce > bugs but also seem explicitly designed to make compatibility a nightmare to > maintain). I don't know how you come to this conclusion but I can assure you that it does not reflect reality: Several FFmpeg developers have actively tried to find a solution for an unacceptable patch, the reaction was that mpv refuses to support upstream FFmpeg.
Novelty. So first mpv tells everyone to use libav, ffmpeg is the worst thing in the world. Next thing, mpv tells everyone that ffmpeg is the only right implementation, you must not ever use libav. Now it tells us everyone else is wrong, and a custom house fork of ffmpeg is the only way forward. See a pattern?
Not to pile-on or be overly negative, but looking over this situation in sum, the retrograde commentary on how this forking silliness won't possibly affect downstream for several years because **Debian**, and their unwillingness to comprehend how this punishes distros and users that actually **do** compile from their repo (the defense being, essentially, "well, downstream doesn't care about us, so we won't care about it!"), I gave up and simply transitioned to their most recent release in the tree. I've been building mpv live since I first installed it years ago and this feels like a significant downgrade to me. This being said, the reason I make this posting is, honestly, their most recent comments on the situation and generally defiant and negligent attitude; suggestions made [here][1] that they're intending to sync their releases with upstream FFmpeg compatibility makes me fear this is not, in fact, a short-lived endeavor. Will it be *effort* for them to maintain their fork? Yeah, but not very much with even fairly standard git configurations and tools (rerere, anyone?). I hate to reiterate the tedious arguments already made in various places in their github repo, but others have pointed out that **nobody** likes the bundling in projects like chromium, but many distros simply live with it because it's nontrivial to un-bundle. Then again, gentoo gives me exactly this option, and I make happy use of it. The developers are deaf to this argument, insisting on continuing with a practice basically nobody likes and puts up with only out of necessity. In general, the developers talk about their fork as being a development asset and suggest that its purpose is to allow them to develop their software independent of the development process of what still is a significant upstream dependency for their project. While they cite a specific incident as provoking the fork, it seems that their contributors nonetheless see it as an enduring development-asset going forward. In the end, since, for the moment, mpv devs are not so self-immolating as to fully break with FFmpeg compatibility, I'm wondering if the live-ebuild is just unsustainable until (and if) mpv snaps out of this. Honestly, given the attitude they evince in dealing with this (I understand drama occurs, I appreciate developers wanting to stabilize their development environments), I'd sooner give their live-ebuild the boot than give them a package for their fork *just* so you can build their software from the repo between major releases. Alternatively, we might contrive to pool their patches atop a given FFmpeg HEAD and apply them to FFmpeg conditional on a use-flag, then make the live mpv ebuild depend on FFmpeg being built with that flag enabled. But this has the potential to be highly error-prone and labor-intensive. [1] https://github.com/mpv-player/mpv/commit/83d44aca7dc7f46b8d3b64d441f5a8317a40e080#commitcomment-25386604
https://github.com/mpv-player/mpv/commit/f19797dea62ab9619a18a2ffab1b67bdafe55b8c#diff-dc6134e3d3c869a052520d86f46371dc
(In reply to soredake from comment #20) > https://github.com/mpv-player/mpv/commit/ > f19797dea62ab9619a18a2ffab1b67bdafe55b8c#diff- > dc6134e3d3c869a052520d86f46371dc Looks like mpv does not require custom ffmpeg anymore? Why? Does it a regression or an advance? Regards, Alex
Not sure. But now there is also a fork of mpv, called ffmpv: https://github.com/ffmpv/ffmpv (https://twitter.com/BMahol/status/927585813516505088) ;)
(In reply to Peter Große from comment #22) > Not sure. But now there is also a fork of mpv, called ffmpv: > https://github.com/ffmpv/ffmpv > (https://twitter.com/BMahol/status/927585813516505088) ;) So far it goes curiouser and curiouser... Yup, mpv people confirm that now mpv doesn't need its own ffmpeg https://github.com/mpv-player/mpv/commit/f19797dea62ab9619a18a2ffab1b67bdafe55b8c Unfortunately I don't know who ffmpv and P.Mahol are, and how it's related to mpv-ffmpeg turmoil.
Since mpv people say that mpv doesn't need its own ffmpeg anymore, I tried to build mpv-9999 with upstream ffmpeg-9999. It fails with the error: ----------------------------------------------------------- ... waf: error: no such option: --enable-ffmpeg-upstream * ERROR: media-video/mpv-9999::gentoo failed (configure phase): * configure failed ... ---------------------------------------------------------- Looks like all that "custom ffmpeg" things should be reverted back... Regards, Alex
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=02da5a73c46cfc7dee789ae5d09d39a049f71e59 commit 02da5a73c46cfc7dee789ae5d09d39a049f71e59 Author: Ilya Tumaykin <itumaykin@gmail.com> AuthorDate: 2017-12-17 22:12:06 +0000 Commit: Patrice Clement <monsieurp@gentoo.org> CommitDate: 2017-12-21 20:19:51 +0000 media-video/mpv: drop obsolete configure option in 9999. Closes: https://bugs.gentoo.org/635650 Package-Manager: Portage-2.3.19, Repoman-2.3.6 media-video/mpv/mpv-9999.ebuild | 1 - 1 file changed, 1 deletion(-)
