Package Details: mpv-git 0.39.0_13_g2c5928e518-1

Git Clone URL: https://aur.archlinux.org/mpv-git.git (read-only, click to copy)
Package Base: mpv-git
Description: Video player based on MPlayer/mplayer2 (git version)
Upstream URL: https://mpv.io
Keywords: media player video
Licenses: GPL-2.0-or-later
Conflicts: mpv
Provides: libmpv.so, mpv
Submitter: rpolzer
Maintainer: qmega
Last Packager: qmega
Votes: 229
Popularity: 0.31
First Submitted: 2012-12-04 09:21 (UTC)
Last Updated: 2024-09-24 06:58 (UTC)

Required by (488)

Sources (2)

Latest Comments

1 2 3 4 5 6 .. 38 Next › Last »

kode54 commented on 2025-10-29 22:20 (UTC)

I'll try to remember not to use chroot to build this package, at least if it can't be fixed to provide similar dependencies to itself or the extra/ package otherwise.

qmega commented on 2025-10-29 07:07 (UTC)

Indeed, building in a chroot is not well supported by this package. That's not intentional but I don't see a clear/complete solution.

The case with jack (and similar) would be improved by depending on libjack.so instead of resolving it to a package. That seems like a practical thing for the dep scanner to do (with fallback for libs lacking provides) but I'll have to give it a little more thought and testing when I have more time. I think it will have to check direct dependencies rather than use ldd or it ends up with a bunch of implementation details in the list. Having pacman look for a provider for every lib also makes the script a lot slower, which is annoying, though not checking recursive deps would also help there.

That would still leave chroot builds with a relatively minimal set of supported features compared to non-chroot builds and extra/mpv.

Optimizing for chroot builds would probably mean getting rid of the dependency scanner, including more (compile-time) optional dependencies as default, and maybe explicitly disabling others, but I feel like that would significantly reduce ergonomics (and/or dependency correctness) of non-chroot builds.

kode54 commented on 2025-10-29 05:58 (UTC) (edited on 2025-10-29 05:59 (UTC) by kode54)

The dependency scanner forces it to hard depend on every nested dependency of things like ffmpeg, including default providers of dependencies where multiple may exist.

For instance, on my system, it hard depends on jack2, which tries to replace my system's pipewire-jack.

It only "works as intended" if I do not build in a chroot.

xAsh commented on 2025-05-22 10:12 (UTC)

Hi qmega, thanks for pointing me in the right direction. I had libopensles-standalone installed, which is a dependency of android_translation_layer. I've removed both packages as I don't need ATL anymore, and I'm now able to install mpv-git fine. Thanks again!

qmega commented on 2025-05-16 08:27 (UTC)

@xAsh Looks like meson thinks it found some part of OpenSLES on your system but didn't find a header it expected to be part of that. Could be a non-standard or broken installation of some kind. Or could be some mistake or inflexibility in mpv's usage of the library (which I'm not familiar with). Do you intentionally have opensles of some sort installed?

If you don't use mpv's opensles ao, you can probably bypass this problem by adding -Dopensles=disabled to _opt_extra_flags or the meson setup build command.

xAsh commented on 2025-05-16 01:47 (UTC)

Anyone else unable to build it?

FAILED: libmpv.so.2.5.0.p/audio_out_ao_opensles.c.o
sccache cc -Ilibmpv.so.2.5.0.p -I. -I.. -I../include -Icommon -Ietc -Iplayer/javascript -Iplayer/lua -Isub -Ivideo/out -I/usr/include/fribidi -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-6 -I/usr/include/libxml2 -I/usr/include/luajit-2.1 -I/usr/include/uchardet -I/usr/include/vapoursynth -I/usr/include/python3.13 -I/usr/include/pipewire-0.3 -I/usr/include/spa-0.2 -I/usr/include/libdrm -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libmount -I/usr/include/blkid -fvisibility=hidden -fdiagnostics-color=always -Wall -Winvalid-pch -Wextra -std=c11 -D_FILE_OFFSET_BITS=64 -Wdisabled-optimization -Wempty-body -Wformat -Wimplicit-fallthrough -Wparentheses -Wpointer-arith -Wshadow -Wundef -Wvla -Wno-cast-function-type -Wno-format-zero-length -Wno-missing-field-initializers -Wno-sign-compare -Wno-switch -Wno-unused-parameter -fno-math-errno -fno-signed-zeros -fno-trapping-math -Werror=format-security -Wno-unused-result -D_GNU_SOURCE -Wmissing-prototypes -Wstrict-prototypes -Werror=implicit-function-declaration -Wno-pointer-sign -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -flto=auto -fPIC -pthread -D_REENTRANT -MD -MQ libmpv.so.2.5.0.p/audio_out_ao_opensles.c.o -MF libmpv.so.2.5.0.p/audio_out_ao_opensles.c.o.d -o libmpv.so.2.5.0.p/audio_out_ao_opensles.c.o -c ../audio/out/ao_opensles.c
../audio/out/ao_opensles.c:29:10: fatal error: SLES/OpenSLES.h: No such file or directory
   29 | #include <SLES/OpenSLES.h>
      |          ^~~~~~~~~~~~~~~~~
compilation terminated.
[293/343] Generating manpages with a custom command
ninja: build stopped: subcommand failed.

djsigmann commented on 2024-12-02 18:57 (UTC) (edited on 2024-12-02 18:57 (UTC) by djsigmann)

I had an issue similar to @Beethoven-n's, however, when running libtree as @qmega suggested, it turned out that shaderc was trying to find libglslang.so.14, reinstalling the package solved any issues. One might also want to reinstall the lib32-shaderc package, should it be installed.

paru -Syu shaderc lib32-shaderc

Beethoven-n commented on 2024-12-01 20:21 (UTC)

turns out, the issue was because of ffmpeg-obs, and the idea just randomly occurred to me last night installing obs-studio-liberty so that i could use stock ffmpeg fixed it

qmega commented on 2024-12-01 06:57 (UTC)

@Beethoven-n What about ffmpeg? libavfilter.so also links against libglslang. Are you sure your mirrors are up to date?

I can't be sure without more context, but I believe your error comes from trying to generate protocols for the desktop file near the end of the build. The actual compilation of the mpv binary has completed at that point, and I find it unlikely it would have linked to a non-existent library. My guess it linked to ffmpeg and that's what's linked to the glslang you don't have installed. With your particular error message, it looks like maybe you downgraded glslang but didn't downgrade ffmpeg to match?

If needed, you can run lddtree from pax-utils on /tmp/makepkg/mpv-git/src/mpv/build/mpv and /usr/bin/ffmpeg to see what is directly linked to the stale library.

Beethoven-n commented on 2024-12-01 06:23 (UTC)

@qmega I already use the repo version of libplacebo.

1 2 3 4 5 6 .. 38 Next › Last »