Package Details: mpv-git 0.27.0_332_g09c61347a8-1

Git Clone URL: https://aur.archlinux.org/mpv-git.git (read-only)
Package Base: mpv-git
Description: Video player based on MPlayer/mplayer2 (git version)
Upstream URL: https://mpv.io
Keywords: media player video
Licenses: GPL
Conflicts: mpv
Provides: mpv
Submitter: rpolzer
Maintainer: qmega
Last Packager: qmega
Votes: 177
Popularity: 2.190353
First Submitted: 2012-12-04 09:21
Last Updated: 2017-11-02 05:12

Required by (79)

Sources (2)

Pinned Comments

qmega commented on 2017-11-02 05:19

ffmpeg-mpv-git can now be installed alongside a different system ffmpeg, and is now the default dependency for this package, because that actually builds successfully right now. You can still build against the system ffmpeg by uncommenting a line in the PKGBUILD, but as of this writing that build will fail. In the future, mpv should build with upstream ffmpeg "most of the time" (according to mpv's primary dev). I'm not yet sure which will be the eventual default for this package, but for now it's the one that it actually builds with.

Latest Comments

qmega commented on 2017-11-15 04:13

@dojero libva was updated to .so.2. You need to recompile whatever ffmpeg you're using, and then mpv, so that they use the new API / ABI.

The 32-bit stuff is probably just a leftover that hasn't been upgraded because Arch has dropped 32-bit support. Assuming your machine is 64-bit, that's what this package will be built as and it won't be able to use 32-bit libraries. That file is a red herring. (And in general, I wouldn't expect copying a .so file from /usr/lib32 to /usr/lib to fix anything in any situation, if your system is sanely configured.)

dojero commented on 2017-11-13 22:40

Mpv failed today after an Syu. Apparently, there's now a problem with libva.so.1. It was/is a 32 bit file, kept in /usr/lib32. When mpv tries to run, it can't find libva.so.1 and quite with that error. I tried copying the file from /usr/lib32 to /usr/lib, but that just gets a Wrong ELF Class error (ELFCLASS 32).

Any ideas would be appreciated.

qmega commented on 2017-11-04 18:37

@dojero I'm guessing you had vulkan-icd-loader installed without vulkan-headers. Until recently, this would have meant mpv would look for the header, fail to find it, and build without vulkan support. A recent change[1] made it use pkg-config to find vulkan, and vulkan.pc is provided by vulkan-icd-loader even though the header isn't, hence the build failure. I don't think the pc file should be included in a package that doesn't have or depend on everything it points to, so I've opened a bug with Arch packages.[2] IMO vulkan-headers and vulkan-icd-loaders should be one package, but that may be difficult due to the way they're built.

What you saw in the PKGBUILD commit log was adding it as an optional thing; if you uncomment "vulkan" in _opt_features in the PKGBUILD, then vulkan-headers would be added as a makedepend and vulkan-icd-loader as a depend, and the build would have worked. (The option isn't necessary if you already have it installed, though; it'll be picked up automatically.)

[1] https://github.com/mpv-player/mpv/commit/b86fb0f3e95b9f2155264415d8f819e19b0c26a2
[2] https://bugs.archlinux.org/task/56238

dojero commented on 2017-11-04 04:27

Working fine with ffmpeg-mpv-git. But in order to get it to build, I also had to install vulkan-headers, which isn't listed as a dependency (although it is noted in the list of changes to the package build). Perhaps it should be added as a dependency.

qmega commented on 2017-11-02 05:19

ffmpeg-mpv-git can now be installed alongside a different system ffmpeg, and is now the default dependency for this package, because that actually builds successfully right now. You can still build against the system ffmpeg by uncommenting a line in the PKGBUILD, but as of this writing that build will fail. In the future, mpv should build with upstream ffmpeg "most of the time" (according to mpv's primary dev). I'm not yet sure which will be the eventual default for this package, but for now it's the one that it actually builds with.

qmega commented on 2017-11-01 13:01

Some changes have been merged in libav and ffmpeg-mpv that haven't been merged by ffmpeg upstream yet, and mpv now depends on them; it's failing on the soversion being too low, not the explicit lack of ffmpeg-mpv. Once ffmpeg merges the changes (assuming they do), this package should then build against it again.

j605 commented on 2017-11-01 08:19

@Nothing4You it seems to require ffmpeg-mpv and doesn't build now. It is better to wait for a week or two until wm4 manages to merge this in upstream.

Nothing4You commented on 2017-10-31 20:24

Shouldn't this be building against ffmpeg-full-git 3.5.r88431.gd0920da029-1 now?
Or does it actually still require ffmpeg-mpv-git?

I'm getting the following error:
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)
Unable to find development files for some of the required FFmpeg/Libav libraries. You need git master. 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.

qmega commented on 2017-10-31 00:17

Note: mpv now requires ffmpeg git.[1] I'm still patching to allow upstream ffmpeg for now, but I'm not going to maintain backwards compatibility for ffmpeg release by myself. This package may start depending on ffmpeg-git, but I'm not doing that yet because that would exclude ffmpeg-mpv-git at the moment.

It's entirely possible this churn will continue for a bit. Users with limited free time who don't have any problems with their current mpv might want to hold off on upgrading for the time being.

[1] https://github.com/mpv-player/mpv/commit/a7f4ecb01299835a1afe5cc051be1e9bb5d4f15d

qmega commented on 2017-10-28 02:46

Thanks for the heads up.

I'm hoping this will blow over too, and don't want to make an intrusive change that might just be reverted next week. For now I'm reverting the commit that rejects upstream ffmpeg and applying the patch from #5033 - it's by the same guy who made the breaking change in ffmpeg so I'd sure hope it fixes the issue, and appears to work with the stable ffmpeg in Arch's repos as well.

I don't want to carry patches against upstream long-term, but for the time being either ffmpeg or mpv needs to be patched (unless we bundle ffmpeg here). Patching here seems like it will be the least trouble for most users for now. I'll reevaluate this decision after seeing what happens the next week or so.

All comments