Package Details: mpv-git 0.34.0_351_g45ff20986d-1

Git Clone URL: (read-only, click to copy)
Package Base: mpv-git
Description: Video player based on MPlayer/mplayer2 (git version)
Upstream URL:
Keywords: media player video
Licenses: GPL
Conflicts: mpv
Provides: mpv
Submitter: rpolzer
Maintainer: qmega
Last Packager: qmega
Votes: 220
Popularity: 0.94
First Submitted: 2012-12-04 09:21 (UTC)
Last Updated: 2022-06-20 15:48 (UTC)

Required by (276)

Sources (2)

Pinned Comments

qmega commented on 2021-11-15 01:39 (UTC)

This package is now building with meson, which was recently added upstream as an alternative to waf. Please report any issues.

For the time being, waf support is still included upstream, so old versions of the PKGBUILD should still work. However, if the meson build doesn't work for you, please do report the problem.

Latest Comments

Batou commented on 2022-06-21 02:41 (UTC)

@qmega THANK YOU!! Installing libxpresent fixed it for me. Everything's working well. Thanks for doing an awesome job maintaining this package! I know it's not easy.

qmega commented on 2022-06-20 23:41 (UTC) (edited on 2022-06-20 23:49 (UTC) by qmega)

@legionnaire That looks like most likely the same issue as previous comment. You probably just need to install libxpresent (or uncomment "x11" in _opt_features near the top of the PKGBUILD) and rebuild the package. My guess it that you had been using X11 for your video output, x11 support is no longer getting compiled for you due to the new dependency on libxpresent which you don't have installed, and the errors you actually see are from mpv attempting to automatically fallback to a drm-based output or something similar and failing to do that too.

Also, using sudo with mpv sounds like a pretty bad idea (huge attack surface, and shouldn't be much need). There might be something else wrong if you find yourself having to do that.

EDIT: Did you rebuild mpv-git (e.g. makepkg -f) after installing libxpresent, or just reinstall the already-built package? The latter would not be enough.

If you really did rebuild with libxpresent available and you're still getting that same error message, that's rather suspicious given the timing and the particular messages, but the next thing would be to check the "List of enabled features" returned by mpv --v and ensure that x11 is in there, assuming that you do use X11. If you don't use X11, please provide more details about your environment.

legionnaire commented on 2022-06-20 23:32 (UTC) (edited on 2022-06-20 23:35 (UTC) by legionnaire)

This is crashing on open after I updated:

(+) Video --vid=1 () (h264 1920x1080 29.970fps) (+) Audio --aid=1 --alang=eng () (aac 2ch 48000Hz) Subs --sid=1 --slang=eng (subrip) error: XDG_RUNTIME_DIR not set in the environment. [vo/gpu] VT_GETMODE failed: Inappropriate ioctl for device [vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be unavailable. [vo/gpu] Failed to commit ModeSetting atomic request (-13) [vo/gpu/opengl] Failed to set CRTC for connector 95: Permission denied error: XDG_RUNTIME_DIR not set in the environment. [ao/alsa] Playback open error: Host is down [ao/jack] cannot open server [ao] Failed to initialize audio driver 'pipewire' Could not open/initialize audio device -> no sound. Audio: no audio VO: [gpu] 1920x1080 yuv420p [vo/gpu/vulkan/libplacebo] vk->CreateSwapchainKHR(vk->dev, &sinfo, PL_VK_ALLOC, &p->swapchain): VK_ERROR_UNKNOWN (../src/vulkan/swapchain.c:583) [vo/gpu/vulkan/libplacebo] Failed (re)creating swapchain! Could not initialize video chain. Video: no video

Exiting... (Errors when loading file)

I've never opened MPV through bash (I just used "sudo mpv media.mkv") but I wanted to have some sort of log to paste here. If I just click on the executable from the start menu it opens (with the loading icon) for a few seconds then crashes.

EDIT: I installed libxpresent and then reinstalled mpv-git but it still crashes

qmega commented on 2022-06-20 22:07 (UTC)

@Batou You probably need to install libxpresent and rebuild the package. If you updated your PKGBUILD in the last few hours, there was supposed to be a message to that effect when pacman installed the package.

Batou commented on 2022-06-20 22:02 (UTC)

mpv-git does not work for me anymore. I'm now getting:

[vo/gpu] VT_GETMODE failed: Inappropriate ioctl for device
[vo/gpu] Failed to commit ModeSetting atomic request (-22)
[vo/gpu/opengl] Failed to set CRTC for connector 79: Invalid argument
[vo/gpu/vulkan/libplacebo] vk->CreateSwapchainKHR(vk->dev, &sinfo, PL_VK_ALLOC, &p->swapchain): VK_ERROR_UNKNOWN (../src/vulkan/swapchain.c:583)
[vo/gpu/vulkan/libplacebo] Failed (re)creating swapchain!
[cplayer] Could not initialize video chain.

every time I start the mpv. I only get the audio. I've tried everything. Even if you don't use mpv.conf file, it doesn't display anything. Non git mpv from Arch does work. No idea what's going on.

qmega commented on 2022-06-20 15:08 (UTC)

@DEC05EBA Sorry, I didn't seem to get an email notification for your comment. Currently I do see mpv_stream_cb_add_ro exported with this package on my system. I'd guess it was fixed by Let me know if you still have the issue. If it does still happen to you but only with this package, it may have to do with build flags.

qmega commented on 2022-06-20 15:02 (UTC) (edited on 2022-06-20 15:50 (UTC) by qmega)

I already added that if you uncomment the x11 feature in _opt_features (as usual it'll be enabled automatically if it's already installed when you build).

Maybe I'll try to add a note of some kind if you have libxrandr but not libxpresent installed, since that will unexpectedly disable x11 support. EDIT: Added a warning on install if you are upgrading from a version before the commit adding xpresent and you have the previous x11 depends installed but not libxpresent.

haawda commented on 2022-06-20 10:19 (UTC)

New dependency libxpresent, see

DEC05EBA commented on 2022-02-20 02:20 (UTC)

The built file is missing mpv_stream_cb_add_ro symbol for some reason. strings /usr/lib/ | grep -i mpv_stream returns nothing.

If I build mpv myself with only setting -Dlibmpv=true then those mpv_stream symbols are there. Im not sure why this aur package doesn't have them.

javadandroid commented on 2022-02-05 19:21 (UTC) ERROR: Meson version is 0.60.1 but project requires >=0.60.3

A full log can be found at /home/jj/Downloads/mpv-git/src/mpv/build/meson-logs/meson-log.txt ==> ERROR: A failure occurred in build(). Aborting...

i have this error for meson but last version is installed

qmega commented on 2021-11-15 01:39 (UTC)

This package is now building with meson, which was recently added upstream as an alternative to waf. Please report any issues.

For the time being, waf support is still included upstream, so old versions of the PKGBUILD should still work. However, if the meson build doesn't work for you, please do report the problem.

dudemanguy commented on 2021-11-06 21:26 (UTC)


qmega commented on 2021-11-06 18:46 (UTC)

@dudemanguy Done.

dudemanguy commented on 2021-11-06 18:26 (UTC)

Could aarch64 be added as an architecture? I compile on my pinephone sometimes.

Tjuh commented on 2021-05-30 21:27 (UTC)

Much gratitude qmega, rebuilding fixed it.

qmega commented on 2021-05-30 21:21 (UTC)

@Tjuh Try installing pacman-contrib 1.4.0-2 from community-staging or rebuilding it yourself. It needs to be linked against your newer pacman/libalpm.

SilverMight commented on 2021-05-16 16:20 (UTC)


I am a total idiot, a package I had required glslang-git as a dependency and that broke the build process. Needless to say, I won't do that again. And apologies for the formatting, I forgot how to do code blocks properly.

qmega commented on 2021-05-16 05:10 (UTC)


This package builds fine for me against: spirv-tools 2021.1-1 shaderc 2021.0-1

I wouldn't think ad_spdif would be doing anything shader-related, and that looks like a linker error which I don't think would be happening at that stage of the build either.

The error message looks like the linker wasn't given the flag for a library it's supposed to be linking to, but I don't know why. A full verbose log from waf that shows what commands it's running might help.

I'm really tired so I might be missing something obvious. But I can at least tell you for sure that the build works for me, including linking to shaderc.

What version is your glslang? Mine is 11.4.0-1.

SilverMight commented on 2021-05-15 17:32 (UTC) (edited on 2021-05-15 17:34 (UTC) by SilverMight)

Is anyone getting this error after the spirv-tools and shaderc tools update? Downgrading them fixes it for me. mpv: symbol lookup error: /usr/lib/ undefined symbol: _ZN8spvtools9Optimizer18RegisterSizePassesEv Furthermore, trying to build against these new versions gives me this error, but downgrading me lets it build fine ` [289/502] Compiling audio/decode/ad_spdif.c /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../lib/libshaderc_combined.a( undefined reference to symbol '_ZN7glslang7TShader16setHlslIoMappingEb' /usr/bin/ld: /usr/lib/ error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status

Waf: Leaving directory /tmp/makepkg/mpv-git/src/mpv/build Build failed -> task in 'mpv' failed with exit status 1 (run with -v to display more information) ==> ERROR: A failure occurred in build(). Aborting... `

nesk_aur commented on 2021-02-23 07:18 (UTC)

I did try deleting /tmp/makepkg completely, same error. Anyway, I got my own mpv build set up, so no problem.

qmega commented on 2021-02-23 05:10 (UTC)

That doesn't look like an issue with this package. Looks like a configuration issue on your system. I'm not very familiar with makepkg internals, but I think that looking for the source clone in /tmp/makepkg means it's either your current working dir or your SRCDEST. The existing mpv directory there, if you didn't create it yourself, could have been left there by some other tool in the process of building another mpv package. I can only speculate on what it contains.

Assuming you don't have something particular set up in /tmp/makepkg intentionally, and that being in /tmp means it's expendable, you could delete it and the build would probably work. Setting SRCDEST (in /etc/makepkg.conf or an environment variable when running makepkg) to a directory where it can clone the source would probably also get past this problem. There may be a deeper problem with your makepkg configuration, though. If you need help with that, Forums or IRC would be better places to ask.

nesk_aur commented on 2021-02-22 13:09 (UTC)

Getting this error:

==> Making package: mpv-git 0.33.0_61_gdae9ea3fa7-1 (Mon 22 Feb 2021 16:07:05 MSK)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
==> ERROR: /tmp/makepkg/mpv is not a clone of

qmega commented on 2021-01-15 04:58 (UTC)

Added an option to enable Javascript support. You can uncomment it near the top of the PKGBUILD, or just install the mujs package and then rebuild this one; mpv's build system enables javascript by default if mujs is found.

lunax commented on 2021-01-14 03:14 (UTC)

I would love to see Javascript support.

qmega commented on 2020-12-11 23:30 (UTC)

@Baerbeisser Works for me. That errors looks like it comes from aria2... but that works for me too. Maybe try with another command line tool like curl, and then examine aria2 or your system certs depending on whether it works.

I've seen cert chains that work in the browser and not from the command line because browsers chase intermediate certs, so it could be something like that, but I'm not sure why it would be happening to you and not me. Looks like uses Let's Encrypt, and I believe something changed with their intermediates lately, so maybe something on your system is just out of date?

Baerbeisser commented on 2020-12-11 19:34 (UTC)

Build fails since yesterday. Message:

12/11 20:17:08 [ERROR] CUID#7 - Download aborted. URI=
Exception: [] errorCode=1 URI=
  -> [] errorCode=1 SSL/TLS handshake failure:  `not signed by known authorities or invalid' `issuer is not known'

The URL opens in the Browser though.

qmega commented on 2020-10-16 21:48 (UTC)

@misc: Yeah, noexec on the filesystem you cloned to would do it. Wouldn't affect waf because prepare() is copying that so it's actually residing on /tmp's filesystem.

I've made the change you suggested.

Thanks for following up.

misc commented on 2020-10-16 19:29 (UTC) (edited on 2020-10-16 19:32 (UTC) by misc)

@qmega: no noexec for /tmp and no issues with python3 either.

The full error is: /mnt/build/mpv-git/PKGBUILD: line 140: /tmp/makepkg/mpv-git/src/ Permission denied

(Re. python or python3, I have no preference.)

edit: noexec is however set for the partition that the PKGBUILD & co. reside on, and since the on /tmp is only a symlink, I'm guessing that's the cause.

qmega commented on 2020-10-10 00:51 (UTC)

@misc That's strange. I compile in tmpfs too and I haven't had problems like that. The only thing that comes to mind is having it mounted noexec, but I don't think it's that because then it would have failed on ./waf before it got to that line. there some chance that /usr/bin/python3 isn't executable? That would probably result in the same error message as the interpreted file itself not being executable. I'm trying to think of what else could cause a permission error and I can't think of much. What exactly is the error you get?

I'm not opposed to calling python as you propose (though I think I'd call python3) if it solves a real problem, but I'd like to understand what's going on first.

misc commented on 2020-10-09 17:21 (UTC)

Line 139 should probably be changed to call the script like $(python "$srcdir"/, otherwise it can fail to execute due to insufficient permissions (for people like me; guessing it's since I compile in tmpfs).

qmega commented on 2020-07-16 06:17 (UTC)


Why are the options not desirable? They seem useful to me and were requested in the past. The only practical downside I see is that on the first install, the user may have to explicitly enable something that the community package had by default -- but that only has to be done once. Depending on those by default would mean that people who didn't want those dependencies -- e.g. someone who used only Wayland and didn't want to install X libraries -- would have to remove them every time, or live with them. With a binary package there has to be a compromise, but I don't see the need for that here.

The majority of mpv's optional features are enabled by default if their dependencies are present, so there's no need to explicitly enable them every time. All one has to do is install them before (re)building the package. I imagine that in many cases, the dependencies for what you want would be installed already. Whatever is linked in will be picked up as dependencies of the package when it's built.

Are there specific problems that the current setup of this package is causing?

qmega commented on 2020-07-16 05:53 (UTC)

@haawda I can't reproduce that. Tried with LANG=de_DE.UTF-8 and LANG=de_DE.ISO-8859-1. What are your LANG / LC_* settings and what error do you get? Or, maybe consider opening an issue upstream. Even if it is just an issue on your system, GitHub is probably a better medium for debugging than here.

commented on 2020-07-11 18:01 (UTC)

This package should more closely map to the mpv package in community, i.e. the default build should use an identical build config to mpv. The "optional" features in the PKGBUILD are not really desirable.

haawda commented on 2020-07-08 19:52 (UTC)

I needed to add LANG=C to the build function, otherwise build would fail with a linking error.

qmega commented on 2019-10-31 01:35 (UTC)

@ekce Sounds like it could be which was fixed today. I can reproduce the crash with that commit reverted and --gpu-api=opengl, but with master as of this writing it's fine. Try again?

If it's still broken for you, open an issue upstream. Even if it ends up being a problem with your system and not a bug in mpv, that's probably a better place to figure it out. AUR comments aren't great for debugging.

ekce commented on 2019-10-30 16:20 (UTC)

See the comments on mpv-build-git. It's possible that the most recent build has a bug that causes it to crash right after starting up.

qmega commented on 2019-10-03 01:34 (UTC) (edited on 2019-10-26 02:12 (UTC) by qmega)

Oh, actually, I wasn't aware of that dependency chain. Pretty sure that's a somewhat recent change. Given that, you'd have to try pretty hard to build mpv without vulkan-icd-loader installed. I think it's totally fair to add vulkan-headers as a makedepend at this point. It's a tiny and harmless package anyway.

Thanks a lot for checking that out and letting me know! I'll update the package.

Edit: Of course it couldn't be that easy. This is going to change again soon: and libplacebo won't be an implicit depend anymore. Maybe I'll put the vulkan option back but leave it default enabled.

Ckat commented on 2019-10-02 20:45 (UTC)

ah I see, I did a quick check and saw vulkan-icd-loader is required by dav1d, which is something ffmpeg requires. and mpv requires ffmpeg for sure. but I gues its stil possible to not have vulkan-icd-loader in some cases.

qmega commented on 2019-10-02 00:48 (UTC)

If you have vulkan-icd-loader installed, you must also install vulkan-headers or mpv will fail to build.

vulkan-headers isn't a hard makedepend because you can build without it, but only if vulkan-icd-loader is also not installed, because of a weird packaging situation that's out of my control (vulkan-icd-loader contains a pkg-config file for vulkan, but not the headers). The PKGBUILD does make an attempt to detect this situation and add the makedepend on vulkan-headers, but that apparently doesn't work with some AUR helpers (depending on when / how they source the PKGBUILD, probably).

See also:

Ckat commented on 2019-10-01 21:36 (UTC)

complaining about missing vulkan-headers when I try to install this, after installing it builds fine. might want to add that as builddep

qmega commented on 2019-09-27 22:09 (UTC)

Ah, I knew this would happen... That was actually my commit, but I didn't know when it'd be merged so I didn't want to prematurely update the PKGBUILD. Probably should have left the flag there and just default-enabled it... but oh well. Fixed now.

katt commented on 2019-09-27 15:52 (UTC)

commit 919b7a55cdc837166bf831cdd1f01e4ad5b2cf89 removed --enable-zsh-comp and building this package without removing that flag will obviously fail.

qmega commented on 2019-08-09 22:06 (UTC)

@account Are your mirrors up to date? Until very recently mpv wouldn't build against repo ffmpeg (requiring a new version that hadn't been released), but as of ffmpeg 4.2 this package should build against the ffmpeg in Extra.

account commented on 2019-08-09 21:10 (UTC)

And I can't install ffmpeg-git T_T unable to satisfy dependency '' required by x264 unable to satisfy dependency '' required by x264 unable to satisfy dependency '' required by x264 unable to satisfy dependency '' required by x264

account commented on 2019-08-09 21:03 (UTC)

Build fails too! Checking for Libav/FFmpeg library versions : no ('libavutil >= 56.27.100 libavcodec >= 58.16.100 libavformat >= 58.9.100 libswscale >= 5.0.101 libavfilter >= 7.14.100 libswresample >= 3.0.100' not found) Unable to find development files for some of the required FFmpeg/Libav libraries. Git master is recommended.

qmega commented on 2019-08-08 04:16 (UTC)

This package builds fine for me (with the non-stable ffmpeg commit reverted) on a fully updated system with mesa 19.1.4-1, and the x11egl context did get built. The mesa package appears to still provide egl.pc and glesv2.pc. That seems weird given freedesktop Bug 110141, so I could be missing something, but that's what I see.

Assuming whatever build problems you have persist with mesa 19.1.4-1, could you be more specific about what fails?

BillFleming commented on 2019-08-07 03:48 (UTC)

Need to add libglvnd-glesv2 to build depends now that new mesa has released. Otherwise will get egl build problems.

qmega commented on 2019-07-29 16:54 (UTC)

waf provides no api compatibility across versions. Using a system-installed waf would not build correctly. People have tried this before. This comes up with basically anything that uses waf and is probably why there's no official Arch package for waf even though software in the official repos (samba) uses it to build. Not even Debian uses system waf.

This package does use makepkg to download waf, so if you've gotten it to download once, waf should be available for future builds without having to download anything -- until mpv upgrades the waf version it uses, but that does not happen very often.

(Interestingly, in this situation you'd have actually been better off if we didn't download waf through makepkg. mpv's waf bootstrap script has a backup download URL so that it works when is down. I'm not aware of any way to specify backup mirrors for makepkg sources.)

rien333 commented on 2019-07-29 12:21 (UTC)

Why does this not use the system waf? The waf servers are down atm, and it's kinda annoying that I'm required to download it now whereas it could already be available on my system.

commented on 2019-07-12 12:47 (UTC)


saymonz commented on 2019-07-08 20:44 (UTC) (edited on 2019-07-08 20:48 (UTC) by saymonz)

Won't build latest updates on my system with current repo ffmpeg:

Checking for libav* is Libav                                         : no
Checking for Libav/FFmpeg library versions                           : no ('libavutil >= 56.27.100 libavcodec >= 58.16.100 libavformat >= 58.9.100 libswscale >= 5.0.101 libavfilter >= 7.14.100 libswresample >= 3.0.100' not found)
Unable to find development files for some of the required FFmpeg/Libav libraries. Git master is recommended.

Builds fine with ffmpeg-git from AUR.

r3b311i0n commented on 2019-06-08 09:50 (UTC)

@qmega Yup, that was it. Thanks for the info.

qmega commented on 2019-06-08 05:51 (UTC)

@r3b311i0n Do you have vulkan-icd-loader installed? This has come up a few times before. vulkan-headers isn't a hard depend because you can build without it, but only if vulkan-icd-loader is also not installed, because of a weird packaging situation that's out of my control. The PKGBUILD does make an attempt to detect this situation and add the makedepend, but that apparently doesn't work with some AUR helpers (depending on when / how they source the PKGBUILD, probably).

For more info, see the comment+link in the PKGBUILD or skim the comments here for "vulkan".

I guess I could just make vulkan a default depend, but it doesn't feel right to do that just to work around a packaging issue.

r3b311i0n commented on 2019-06-06 19:51 (UTC)

Build seems to be failing without vulkan-headers...

qmega commented on 2019-04-20 21:30 (UTC) (edited on 2019-04-20 21:46 (UTC) by qmega)

Re: out-of-date flag: 0.29.1 wasn't cut from master; it's on a separate branch. Even if I bumped the version of this package now, it would still say 0.29.0. This package has actually been bumped already since the release of 0.29.1.

qmega commented on 2018-07-12 21:16 (UTC) (edited on 2018-08-14 03:27 (UTC) by qmega)

@Hello71: I like the idea, but I want to make sure we're always using the version upstream wants (since waf provides no compatibility guarantees), and with this being a -git package updating manually isn't reliable.

I've submitted a PR upstream [1] that would allow the PKGBUILD to run the waf version check without trying the download, and just fail in prepare() or build() if there's a mismatch. This would make it clear that the PKGBUILD needs updating rather than having the version mismatch create some spurious failure. With that or something equivalent in place, I'll make the change you requested.

EDIT: Done.


Hello71 commented on 2018-07-10 13:26 (UTC)

please download waf at download time not at compile time. this is marginally more secure and saves a bunch of bandwidth.

BurhanDanger commented on 2018-06-18 05:49 (UTC)

Sorry, my bad. Didn't see whole PKGBUILD carefully. I have an AUR helper which parses .SRCINFO to install depends and makedepends through explicit pacman calls and not do makepkg -s.

qmega commented on 2018-06-17 21:55 (UTC) (edited on 2018-06-17 21:56 (UTC) by qmega)

@BurhanDanger It only does if vulkan-icd-loader is installed. Otherwise, it'll happily build without vulkan. If you have the loader installed at the time you source the PKGBUILD, it should add the headers to makedepends automatically (see [1] for details and explanation). Do you have a situation where that didn't work?


BurhanDanger commented on 2018-06-17 17:07 (UTC) (edited on 2018-06-17 17:07 (UTC) by BurhanDanger)

I think this need vulkan-headers in makedepends.

qmega commented on 2018-05-30 23:51 (UTC)

Added to makedepends. Thanks!

eigengrau commented on 2018-05-30 06:05 (UTC)

pactree is now part of the pacman-contrib package (not part of base or base-devel).

qmega commented on 2018-05-12 15:13 (UTC)

Now that ffmpeg 4.0 has hit the official repos, this package finally builds against system ffmpeg again.

vinegret commented on 2018-04-28 04:35 (UTC)

@postadelmaga, also compiled ffmpeg v.4 can install from

dbermond commented on 2018-04-16 00:18 (UTC)

@postadelmaga That's normal and expected.

In order to build the current mpv git master you need ffmpeg git master (for example, ffmpeg-git or ffmpeg-full-git package). It will not build with ffmpeg 3.4.

postadelmaga commented on 2018-04-16 00:12 (UTC) (edited on 2018-04-16 00:12 (UTC) by postadelmaga)

Just got this on a fresh Arch installation during compilation, looks some issue with dependency:

Checking for libav* is Libav                                         : no 
Checking for Libav/FFmpeg library versions                           : no 
('libavutil >= 56.12.100 libavcodec >= 58.16.100 libavformat >= 58.9.100 libswscale >= 5.0.101 libavfilter >= 7.14.100 libswresample >= 3.0.100' not found) 
 Unable to find development files for some of the required FFmpeg/Libav libraries. Git master is recommended.

fx333 commented on 2018-03-19 22:16 (UTC)

The case that prompted me to modify the script was a libva dependency, but it turns out my ffmpeg package wasn't depending on libva. So is actually working as intended it seems.

Although somewhat hacky, you can offload library searching to ld (the rpath would still need special consideration):

$ ld --verbose -o /dev/null -lz 2>/dev/null | grep ^-l
-lz (/usr/lib/

qmega commented on 2018-03-18 23:22 (UTC)

The current script prunes dependencies-of-dependencies. The block of code labeled "Remove redundant dependencies" does that. Do you have some case where that isn't working?

I like the idea of using readelf instead of ldd (it was actually suggested once before), but I think that would require handling rpath and finding the actual files manually, unless you know of an easy way to do that. To demonstrate the issue: I build this package against ffmpeg-git installed in a subdirectory of /usr/lib (and registered with the package manager) so I can have it alongside ffmpeg release; the script with your patch fails on those libs because it assumes everything is in /usr/lib directly.

fx333 commented on 2018-03-18 19:32 (UTC) (edited on 2018-03-18 19:33 (UTC) by fx333)

The script will recursively list dependencies, this causes the mpv-git package to depend on e.g. all of ffmpeg's depends too.

I don't think this is correct, here's a patch to use readelf instead:

qmega commented on 2018-01-27 04:43 (UTC)

Just pushed a workaround for the vulkan-headers situation. It's added to makedepends if pkg-config can resolve vulkan when the PKGBUILD is sourced. This should make the dependencies work out without forcing them on people who don't want vulkan at all.

qmega commented on 2018-01-27 04:29 (UTC)

@speak It needs vulkan-headers only if vulkan-icd-loader is installed. The latter comes with the pkg-config file which points to the header, but the former includes the header. I don't think this makes sense and I opened a bug report[1] against the packages a while back but so far it's been ignored. If you don't have either package installed, the build will work fine (but not have Vulkan support) so I don't want to add the depend unconditionally.


speak commented on 2018-01-26 13:57 (UTC)

This seems to need a dependency to vulkan-headers.

Those trying to install it as it stands, install vulkan-headers before this.

Tralba commented on 2018-01-10 06:48 (UTC)

@qmega The issue seems to be my AUR-helper not updating the PKGBUILD along with the files from git, manually building them or removing all old files solved my problem.

qmega commented on 2018-01-07 22:04 (UTC)

@Tralba Definitely not. The PKGBUILD hasn't had anything related to ffmpeg-mpv for a month. Even before that, it referenced "ffmpeg-mpv-git" so unless you've modified your quote something's weird. Are you sure this is the package you're building? And your checkout of it is up to date? Try "git rev-parse HEAD" in the directory with the PKGBUILD. Should say bc3ac332ee6e.

Tralba commented on 2018-01-07 20:24 (UTC)

My build fails with "unable to resolve dependency 'ffmpeg-mpv'" although I have ffmpeg-git installed, is that supposed to happen?

laichiaheng commented on 2017-12-26 02:23 (UTC) (edited on 2017-12-26 03:15 (UTC) by laichiaheng)

@qmega mpv-build-git solves my problem, but there is something wrong with the shaderc-git in the AUR, so I have to remove these lines to build mpv-build-git:




patch -p1 -i "${srcdir}/4933.patch"

qmega commented on 2017-12-25 15:54 (UTC)

@laichiaheng This is what the last 6 comments on this page have been about. Please read them.

laichiaheng commented on 2017-12-25 15:42 (UTC)

no ('libavutil >= 56.6.100 libavcodec >= 58.7.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. Git master is recommended.

qmega commented on 2017-12-25 01:21 (UTC)

It's easy enough to install ffmpeg-git in parallel and avoid having to recompile everything else. All that's needed on this side is a PKG_CONFIG_PATH export in build(). I'm doing that locally with a hacked-up version of the ffmpeg-git package, but it didn't seem worth actually uploading to the AUR; it's not a good solution, but I'm still hoping this situation is temporary. The time may be approaching when I'll have to accept it's not and figure out what to do with this package. (Ideas would be welcome. I'd rather not require ffmpeg-git replacing system ffmpeg.)

Well, mpv just made a release and still depends on unreleased ffmpeg. So let's see what the Community package does.

dbermond commented on 2017-12-18 00:48 (UTC)

@kevku unfortunately, that's the cost you need to pay for living in the bleeding edge. You need to handle this for yourself.

kevku commented on 2017-12-17 20:20 (UTC)

installing ffmpeg-git breaks everything else that uses ffmpeg tho like firefox

qmega commented on 2017-12-14 18:00 (UTC)

Currently this package will only build against ffmpeg-git (or some variant thereof). It requires ffmpeg updates that have not been in any release yet. Once ffmpeg 3.5 is released, it should work with that, and I'm hoping it will stay compatible with ffmpeg release after that. If not, I might have to switch the depend here to ffmpeg-git, but I'm trying to avoid that. ffmpeg-mpv is no longer being updated, so it doesn't count. Either install ffmpeg-git, or wait until ffmpeg 3.5 is released.

C0rn3j commented on 2017-12-13 13:29 (UTC)

Haven't been able to build this package for a while now, is there anything I'm doing wrong? Here are the ffmpeg packages I have installed -

ffmpeg 1:3.4-4 ffmpeg-mpv-git 3.5.r89366.g65b5fcfbe2-1 ffmpeg2.8 2.8.13-2

qmega commented on 2017-12-06 04:55 (UTC)

Done, thanks.

Note: I left the depend as just 'ffmpeg', but currently this package will only build against ffmpeg-git (or some variant thereof). Once ffmpeg 3.5 is released, it should build against that, and I'm hoping it will keep working with release most of the time after that. (I personally managed to get away with building mpv-git against ffmpeg release without any problems up until this recent turmoil.)

CounterPillow commented on 2017-12-05 12:52 (UTC)

You should remove ffmpeg-mpv-git, see

qmega commented on 2017-12-02 17:41 (UTC)

@a36233: (re: out of date flag) The file missing there should be provided by libdrm, which is required by both ffmpeg and ffmpeg-mpv-git via libva. If you're still having the problem, post the output of `pacman -Qikk libdrm`. (Also, next time please post the error as a comment instead of flagging out of date.)

qmega commented on 2017-11-27 05:24 (UTC)

If anyone gets an error regarding the --enable-zsh-comp flag not existing in the next week, just delete that line from the PKGBUILD. There's a pending pull request that removes that switch and makes zsh completion installed unconditionally. I'm going to be out of town for a week, so if that PR gets merged, this PKGBUILD will break, but the switch can be safely removed. I've prepared a commit doing that, which I'll try to push when I get the chance if the PR does get merged, but I might not get to it right away.

qmega commented on 2017-11-15 04:13 (UTC)

@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 (UTC)

Mpv failed today after an Syu. Apparently, there's now a problem with It was/is a 32 bit file, kept in /usr/lib32. When mpv tries to run, it can't find 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 (UTC)

@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] [2]

dojero commented on 2017-11-04 04:27 (UTC)

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-01 13:01 (UTC) (edited on 2017-11-01 13:02 (UTC) by qmega)

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 (UTC)

@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 (UTC)

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 Aborting.

qmega commented on 2017-10-31 00:17 (UTC)

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]

qmega commented on 2017-10-28 02:46 (UTC)

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.

Griever commented on 2017-10-28 00:40 (UTC) (edited on 2017-10-28 00:43 (UTC) by Griever)

The only change mpv's ffmpeg fork currently contains from upstream ffmpeg git is a revert of the commit which broke mpv. Depending on a ffmpeg-mpv-git package doesn't seem like the best move. ffmpeg appears to be working on fixing this unintended breakage upstream and I'd suggest waiting for that to land. Until then, users have a couple choices: 1) Build ffmpeg-git without the commit which caused the breakage[1] 2) Use ffmpeg 3.4 (#branch=release/3.4) 3) Build mpv with the patch that fixes(?) the issue[2] Note that the above still requires the workaround dbermond posted. This is likely just another knee-jerk reaction by mpv's developer and will hopefully be peacefully resolved soon. [1] [2]

dbermond commented on 2017-10-27 18:52 (UTC)

@qmega mpv has removed official support for upstream ffmpeg and will fail to build with it. Now mpv requires the git master branch of its own modified version of ffmpeg, called ffmpeg-mpv. For details, see: For a possible solution until there is no Arch official repository workaround, see: Another possibility is to depend directly on ffmpeg-mpv-git, but this would restrict users to a single ffmpeg aur variant.

qmega commented on 2017-08-02 00:14 (UTC)

Right, ffmpeg-git uses libmysofa instead of netcdf, as will future ffmpeg releases, presumably.

laichiaheng commented on 2017-08-01 15:58 (UTC) (edited on 2017-08-01 15:58 (UTC) by laichiaheng)

I've found another package in AUR, it is mpv-build-git which is built with ffmpeg-git, and it seems like there is no need to install the netcdf.

qmega commented on 2017-07-31 23:56 (UTC)

It's ffmpeg that needs to be built with libmysofa, not mpv. It looks like ffmpeg-full-git is the only AUR package that currently includes it by default. It's not yet in any ffmpeg release, so if you're using a release version you'd need netcdf instead (that was recently removed from the official repo package).

laichiaheng commented on 2017-07-31 08:30 (UTC) (edited on 2017-07-31 08:31 (UTC) by laichiaheng)

Will it be built with libmysofa to enable the sofalizer?

qmega commented on 2017-07-08 15:33 (UTC)

Yeah, it does look like it's from that commit, but I don't know what the proper fix is. In any case, it's an upstream issue, nothing to be done here. I saw you updated your issue there, but they'll probably ask for a more detailed log (with -v) so you might want to go ahead and upload that.

laichiaheng commented on 2017-07-08 05:53 (UTC) (edited on 2017-07-08 07:18 (UTC) by laichiaheng)

It happens to the HEVC 10bit, and it seems to be caused by the 300f6a334498059f28ec63406112348c7e00fa64 which you mentioned before. Is there any way to fix it? VO: [opengl] 1920x1080 yuv420p10 [vo/opengl] before retrieving framebuffer depth: OpenGL error INVALID_VALUE. AV: 00:00:00 / 01:43:56 (0%) A-V: -0.034 DS: 2.500/0 [vo/opengl] after video rendering: OpenGL error INVALID_VALUE. [vo/opengl] after rendering: OpenGL error INVALID_VALUE. [vo/opengl] after video rendering: OpenGL error INVALID_VALUE. AV: 00:00:00 / 01:43:56 (0%) A-V: 0.006 DS: 2.643/0 Opening video filter: [vapoursynth file=/home/user/.local/share/SVP4/scripts/ buffered-frames=4 concurrent-frames=7] Using conversion filter. [vapoursynth] Unsupported output format. Image formats incompatible or invalid. Video filter chain: [in] 1920x1080 yuv420p10 bt.709/bt.709/bt.1886/limited SP=1.000000 CL=unknown [scale] 1920x1080 yuv420p16 bt.709/bt.709/bt.1886/limited SP=1.000000 CL=unknown [a] [vapoursynth] "vapoursynth.00" ??? <--- [out] ??? AV: 00:00:03 / 01:43:56 (0%) A-V: 0.005 DS: 2.405/2 Dropped: 10 [vo/opengl] after creating framebuffer texture: OpenGL error INVALID_VALUE. AV: 00:00:04 / 01:43:56 (0%) A-V: 0.002 DS: 2.360/3 Dropped: 12

qmega commented on 2017-07-06 22:08 (UTC)

No idea. What is "doesn't work well" supposed to mean? Are you still getting the errors you posted the other day, or have you successfully built but mpv but it isn't doing what you want? In either case, as I said the other day, please provide the exact commands you're running and their output. mpv-vapoursynth uses 0.25.0 release, so if that works and git master doesn't you could bisect between the two. The only changes in the AUR package since 0.25.0 have been the option stuff, which shouldn't affect the build at all if you don't enable them, so this is probably an upstream change or something on your own machine. If it's the former, my best completely uneducated guesses are either 300f6a334498059f28ec63406112348c7e00fa64, or your config becoming invalid due to the list-option parsing changes. If that doesn't help and you can't bisect yourself, you'll have to provide more information if you want help.

laichiaheng commented on 2017-07-06 15:44 (UTC)

The newer build of mpv-git doesn't work well with SVP4, but some older version like mpv-vapoursynth works fine with it, what might cause this?

qmega commented on 2017-07-04 19:12 (UTC)

A little more info might help, but those messages probably came from trying to clone the git repo for mpv, or possibly for this AUR package if you're using a helper that works like that. Probably GitHub (or Arch) servers were having temporary issues, or maybe there's a misbehaving proxy in the way. It's probably worth just trying again, now that it's been a few hours. If it still happens, please provide the exact commands you're running and their full output.

laichiaheng commented on 2017-07-04 13:39 (UTC)

The requested URL returned error: 504 The requested URL returned error: 502

qmega commented on 2017-05-29 23:05 (UTC)

Implemented a basic options system. Thanks for the idea, severach, and sorry it took me so long to get around to doing it. It's not comprehensive, but I put in the stuff that's frequently requested and most of what's in the community package, minus a few that appear to be redundant or you'd already have installed if you wanted them. If anything's missing, feel free to request it.

severach commented on 2017-04-27 22:54 (UTC)

_opt_FooBar=1 Simple solution: put options at the top of the PKGBUILD. When enabled, they add to depends and turn on the appropriate compile options. Anyone willing to run makepkg gets to choose. Options don't work in the repos but they do work in the AUR.

qmega commented on 2017-04-27 22:14 (UTC)

@ThrowAwayNo_1: Currently I only have ffmpeg as a hard depend because that's the only thing that you can't build mpv without. There is a script that sets the dependencies of the generated package to what it actually depends on, so in my personal install (and yours too, if you installed it), libxss is a dependency. If I added it as a default dependency, someone using mpv on a Wayland-only machine, or a headless machine using --vo=image or audio only or something, would have to edit the PKGBUILD to remove it every time if they wanted to avoid installing and linking against a ton of X11 libs. Granted, most people using this package are probably using X11, but trying to guess at that balance with all the optional dependencies strikes me as a losing battle. The way it is now, everyone has to figure out their optional dependencies the first time (unless everything they need is already installed), but then you pretty much never have to worry about it again, except in the rare occasion a new dependency is added for a feature you already used that you don't already happen to have installed. (I guess that's what happened to you here.) About optdepends, see the comment I just pinned.

qmega commented on 2017-04-27 22:00 (UTC)

I've gotten a lot of requests to add various optional dependencies to optdepends, so I'm pinning an explanation of why I don't do that. I'm still very much open to suggestions on how to improve the situation; I just don't want to answer the same question again and again. TL;DR: Basically, mpv's optional dependencies aren't really optdepends the way the packaging system sees them. Either they were linked against at build time, and mpv won't run without them (hard depend), or they weren't, in which case even if you install them they can't be used until you rebuild mpv. An optdepend tells the packaging system that you can freely install or uninstall it and you will just get/lose the associated optional functionality. Although mpv has many optional dependencies, they don't work like that. They're optional at compile time, but once you've built the package they're either hard dependencies or not dependencies at all. For example: Lua scripting support. If you don't have a supported Lua interpreter installed when you build, your copy of mpv will not support Lua scripting, even if you install Lua later. And if you build with Lua support, uninstalling Lua will render your mpv unable to run entirely, not just disable Lua support. There is a script included with this package that detects what libraries your build is linked against and sets those as (hard) depends when creating the package, so the package you install accurately reflects its dependencies. It might be nice if you were presented with a list of optional dependencies to choose from before building the package for the first time, but I'm not aware of a decent way to do that - user interaction in the PKGBUILD feels nasty, and I definitely don't want any interaction required after the first build. As a compromise, I have a message on install that mentions this issue, but I have it only on the first install to avoid annoying people. This system is certainly far from ideal, but I haven't thought of anything better. The way it is prevents dependencies from getting out of sync, and allows everyone to use whichever optional features they want without having to install a bunch of stuff they don't or edit the PKGBUILD every time. The price is that you have to figure out which extra packages you need the first time you install, but at least you only have to do that once. If anyone can think of a better system, I'm all ears.

ThrowAwayNo_1 commented on 2017-04-26 02:52 (UTC) (edited on 2017-04-26 03:02 (UTC) by ThrowAwayNo_1)

Could you consider add libxss to the list of dependencies? Currently mpv needs it for X11 video output: the command `mpv -vo help` does not show the X11 options if this package is built without libxss, and mpv won't play any video file under X. Please at least add it to the list of optional dependeicies.

qmega commented on 2017-04-02 00:56 (UTC) (edited on 2017-04-02 01:07 (UTC) by qmega)

I decided not to switch back at the time because mpv's releases are pretty much arbitrary git snapshots, and mpv built from master identifies itself by a commit, not the last or next version, so I figured a release-based version still wouldn't mean much. Also, the releases aren't tagged on master, but on a separate branch with extra merge + version commits, so the version tag isn't actually reachable from HEAD, and getting the latest tag has always been a little "interesting". (I never really liked just grabbing the latest tag - it wouldn't give you the tag you wanted if e.g. fixes were backported to an old release.) I don't feel very strongly about this, so I'll reinstate some kind of release-based pkgver for now, but I wonder if a date-based version format would be more appropriate. What you really want to know when you look at the version is how out-of-date it is, right? The date you built it or the date of the last commit would be better indicators of that than release numbers, which for mpv are somewhat arbitrary and irregular. Opinions?

WorMzy commented on 2017-04-01 23:18 (UTC)

This package used to use a similar pkgver (see ), but was removed because upstream stopped making releases, and the package in community/ switched to commit versioning. I'd say there's a good argument for switching back to a more descriptive pkgver now.

escondida commented on 2017-04-01 21:37 (UTC)

I'd like to suggest using the following pkgver(), which would provide a more informative version number along the lines of "0.24.0.r189.gdc7d71fc8e", where r189 is revisions since last tag and everything preceding it is the tagged version number. pkgver() { cd mpv tag="$(git tag -l --sort=version:refname | sed -n '$p')" printf '%s.r%s.g%s' \ $(echo $tag | sed 's/^v//') \ $(git rev-list --count "$tag"..HEAD) $(git rev-parse --short HEAD) }

qmega commented on 2017-01-07 02:17 (UTC) (edited on 2017-01-07 02:22 (UTC) by qmega)

Can't reproduce, but based on your error my guess is your python / python-docutils packages are mismatched since the Python 3.6 upgrade, so you're running python 3.6 with docutils in /usr/lib/python3.5 or python 3.5 with docutils in /usr/lib/python3.6. A full system upgrade with up to date mirrors should fix it. If not, check your versions of each package to be sure: latest as of this writing are python 3.6.0-1 and python-docutils 0.13.1-2 (obviously you need both installed, but as they're makedeps I'm assuming you do).

thelongdivider commented on 2017-01-05 06:58 (UTC)

Anyone else having this problem? Traceback (most recent call last): File "/usr/bin/rst2man", line 21, in <module> from docutils.core import publish_cmdline, default_description ModuleNotFoundError: No module named 'docutils' Build failed -> task in 'rst2man' failed (exit status 1): {task 140156037857856: rst2man mpv.rst -> mpv.1} ' /usr/bin/rst2man --strip-elements-with-class=contents ../DOCS/man/mpv.rst DOCS/man/mpv.1 ' ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build mpv-git.

qmega commented on 2016-12-01 03:43 (UTC)

@Soukyuu: That's been asked a couple times before. Here's what I said last time: (TL;DR: They aren't really optdepends the way the packaging system sees them. Either they were linked against at build time, and mpv won't run without them (hard depend), or they weren't, in which case even if you install them they can't be used unless you rebuild mpv. The situation isn't ideal, and I'm open to ideas.) An optdepend tells the packaging system that you can freely install or uninstall it and you will just get/lose the associated optional functionality. Although Lua support is an optional dependency for mpv, it doesn't work like that. If you don't have it installed when you build, Lua support won't be there, even if you install Lua later. And if you build with Lua support, uninstalling Lua will render your mpv unable to run. If you have a compatible Lua installed when you build mpv, it will be picked up and will be a hard depend of the generated package (as it should be, because the package won't work without it). As a compromise, the last time this was asked I added a message on install that addresses this issue and specifically mentions Lua, but I have it only on the first install to avoid annoying people. Here's also what I said last time about the auto-detecting dependencies thing: I know the dependency system is non-ideal, but I haven't thought of anything better. The way it is prevents dependencies from getting out of sync, and allows everyone to use whichever optional features they want without having to install a bunch of stuff they don't or edit the PKGBUILD every time. The price is that you have to figure out which extra packages you need the first time you install, but at least you only have to do that once. If you can think of a better system, I'm all ears.

Soukyuu commented on 2016-11-29 19:41 (UTC)

lua51/luajit are needed for lua/OSC support, maybe you could add them as optional dependencies?

qmega commented on 2016-06-16 04:22 (UTC)

For anyone who uses nnedi3 or superxbr: They're being removed soon ( I've removed the enable flag from this package already because I'll be out of town for a while and don't want the package to break if they remove it while I'm gone. Both scalers are already implemented as user shaders: For now you can also just add the flag back to the build if you want, but user shaders will be the way to use nnedi3 or superxbr in the future.

qmega commented on 2016-04-25 03:01 (UTC)

FYI, there's a bash completion for mpv at which seems pretty well updated. (I use zsh, so I haven't personally used it.) Looks like the bash-completion package has removed their mpv thing for the next release, so you might want to check that out. Or switch to zsh, it's better ;)

CounterPillow commented on 2016-04-24 17:32 (UTC)

Nevermind me, some retard broke /usr/share/bash-completion/completions/mpv, fault isn't in this package.

CounterPillow commented on 2016-04-24 17:22 (UTC)

Did bash completion break for anybody else? Because it did break for me.

severach commented on 2016-02-09 08:17 (UTC)

I update my git packages on each version change so that git users get updated no less often than non git users. Updates on each commit seem excessive.

qmega commented on 2016-02-03 06:38 (UTC)

Well, mpv is committed to almost every day. Mirroring every upstream commit might be feasible for some (small / rarely-updating) packages, but for this one it'd be ridiculous. You could script your upgrade process to explicitly upgrade this package (and similar ones) every time, or after a certain time has passed since your last rebuild. If you want to get fancy, you could even e.g. check and compare the sha with the version of your installed package.

EndlessEden commented on 2016-02-03 05:26 (UTC)

@qmega: no, just laziness. aur-helpers are tracking version changes, so it automatically flags to update on change. I really hate having to go through and find whats updated and whats not. Ive gave the same suggestion to alot of maintainers.

qmega commented on 2016-02-03 02:50 (UTC)

@1ace: That shouldn't be necessary. If you have wayland installed at build time, it should automatically be detected and linked against. Is that not working for you? @mnovick1988: I'll add the ARM stuff momentarily. As for the git thing, I'm a little confused about what you're suggesting. Are you saying I should commit to this package every time there's a commit to mpv upstream? I'm definitely not going to do that. I could maybe be convinced to commit here when there's a release upstream, but given that mpv's releases are basically arbitrary git snapshots, there still wouldn't be a whole lot of meaning to that, IMO. But if you meant something else, please clarify.

EndlessEden commented on 2016-02-03 00:29 (UTC)

@WorMzy: While i realize this, a bit of automation makes life alot easier. - Although, i could just set up a cron for that though... but im lazy. Lack of correct term at that moment.(aur helper) Request: can you add arch=('i686' 'x86_64' 'armv6h' 'armv7h') to the pkgbuild.

1ace commented on 2016-02-02 23:14 (UTC)

Would you be OK with adding `--enable-wayland` ?

WorMzy commented on 2016-01-26 10:17 (UTC) Users with AUR helpers should understand that this is a -git package and they should upgrade it frequently (or track the upstream repository for changes). The PKGBUILD should only be updated if the dependencies change or the build/package/etc functions need updating. Also, tools like yaourt are not package managers, they are AUR helpers.

EndlessEden commented on 2016-01-26 08:54 (UTC)

@qmega - no no, its working fine on my end. Im quite satisfied. Once i realized it was auto-detecting ffmpeg-git(which i was using at the previous time-of-build) as the ffmpeg provider, then setting a depend. on it. All was good, i just now always rebuild mpv right after ever ffmpeg build. **Note: you should bump the git-version per commit. That way package managers with aur support(such as yaourt) can auto-detect the update and treat it as a upgraded package.

qmega commented on 2016-01-13 00:18 (UTC)

@ttz: An optdepend tells the packaging system that you can freely install or uninstall it and you will just get/lose the associated optional functionality. Although Lua support is an optional dependency for mpv, it doesn't work like that. If you don't have it installed when you build, Lua support won't be there, even if you install Lua later. And if you build with Lua support, uninstalling Lua will render your mpv unable to run. If you have a compatible Lua installed when you build mpv, it will be picked up and will be a hard depend of the generated package (as it should be, because the package won't work without it). As a compromise, the last time this was asked I added a message on install that addresses this issue and specifically mentions Lua, but I have it only on the first install to avoid annoying people. Here's also what I said last time about the auto-detecting dependencies thing: I know the dependency system is non-ideal, but I haven't thought of anything better. The way it is prevents dependencies from getting out of sync, and allows everyone to use whichever optional features they want without having to install a bunch of stuff they don't or edit the PKGBUILD every time. The price is that you have to figure out which extra packages you need the first time you install, but at least you only have to do that once. If you can think of a better system, I'm all ears. @mnovick1988: ffmpeg is the only dependency that is hardcoded in the PKGBUILD because it's the only thing that mpv can't be built without. Since ffmpeg-git provides ffmpeg, it satisfies any pre-checking done by an AUR helper or whatever. When packaging, though, the dependencies are filled based on what the built binary links against. In your case, the package that owns the relevant library files is ffmpeg-git, so that's the package that goes in. When one package provides another, the script has no way of knowing if the thing mpv links against is part of the shared feature set or something that only the special version has. I suppose a special case could be added for ffmpeg, but I'm not sure if that would even be correct. (Would your mpv binary actually still work if you replaced your git ffmpeg with release?) Was this just a curiosity, or is it actually causing problems for you?

EndlessEden commented on 2016-01-12 20:49 (UTC)

strangely, this sets a dependancy on ffmpeg-git, in the package afterbuilding. but the pkgbuild specifically states ffmpeg is the depend.

ttz commented on 2016-01-10 04:24 (UTC) (edited on 2016-01-10 04:25 (UTC) by ttz)

suggestion: add lua and luajit as opt deps (needed for On Screen Controller)?

qmega commented on 2016-01-09 23:52 (UTC)

Done. I was thinking about doing that when the change was first made upstream, but got busy and forgot. This means the binaries built by this package by default must be distributed under GPL3. I don't think this should cause any problems for anyone, but someone please correct me if I'm wrong.

regitator commented on 2016-01-09 12:03 (UTC)

Can I propose to add "--enable-gpl3" to the configure options and changing the license to GPL3? This enbles some additional features (nnedi3 scaler). Thanks!

ahjolinna commented on 2015-09-20 16:39 (UTC)

@bernd_b: was first disabled, now its removed 100%, here is the reason why: more about it: qmega: about that 'out-of-date flag', I can't even remember the reason anymore, I did it 4am + vodka...maybe that is the reason..sorry :D

bernd_b commented on 2015-09-20 13:06 (UTC)

[dvdnav] DVD menu support has been removed Did I make something wrong again or is it just what is says? How would I switch from title to title without using command-line from now on playing DVDs?

bernd_b commented on 2015-09-20 12:04 (UTC)

Yes, I got something wrong with my own compile. So I try to sum up: [root@amd64-archlinux mpv]# git describe --tags v0.1.0-6141-g126367b where v0.1.0 -> is the version number? 6141 -> is the release number? g126367b -> is the latest commit number?

qmega commented on 2015-09-19 23:34 (UTC) Should be upstream shortly. Can I ask again the reason for the out-of-date flag?

ahjolinna commented on 2015-09-19 16:54 (UTC)

qmega: that worked for me

qmega commented on 2015-09-19 16:01 (UTC)

@bernd_b: 126367b is the latest commit as of this writing. 8fbc64f is several months old. Did you forget to git pull on your own copy? @ahjolinna: Hmm, looks like some bits in $? were set when running mpv even though it ran fine and returned zero. I'm not sure why that would happen, but I guess only the actual exit status should be checked. Try adding this to the end of prepare(): sed -i 's/$? != 0/$? >> 8 != 0/' TOOLS/ If it works, I'll fix it upstream.

ahjolinna commented on 2015-09-19 15:20 (UTC)

here is the build log:

bernd_b commented on 2015-09-19 09:28 (UTC)

No errors here as I just ran this package. Still the versions makes me wonder: If I start mpv compiled with this package, it introduces itself with: mpv git-126367b I I start my own git compiled mpv, I get this message: mpv git-8fbc64f There were only five minutes between the two compilations.

qmega commented on 2015-09-19 05:58 (UTC)

The real error should be just above that, from the completion generation script. Anything below "[NNN/NNN] Creating build/etc/_mpv" is relevant. Post that here. Also, why the out-of-date flag? Do you want the release-based versioning scheme back? I have mixed feelings about that myself. It was kind of wonky.

ahjolinna commented on 2015-09-19 04:23 (UTC)

I get this error: Waf:Leaving directory `/tmp/yaourt-tmp-ahjolinna/aur-mpv-git/src/mpv/build' Build failed -> task in '_mpv' failed (exit status 255): {task 140411469841408: _mpv -> _mpv} ' "/usr/bin/perl" "/tmp/yaourt-tmp-ahjolinna/aur-mpv-git/src/mpv/TOOLS/" "/tmp/yaourt-tmp-ahjolinna/aur-mpv-git/src/mpv/build/mpv" > "etc/_mpv" ' ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build mpv-git.

qmega commented on 2015-08-31 19:53 (UTC)

Looks like the script is not executable. Do you have /tmp mounted noexec or something? Though in that case mpv's actual build shouldn't have been able to run either, so it'd have to be something a little more complicated. What filesystem is /tmp on? Maybe something weird with symlinks.

desaparecido commented on 2015-08-31 16:29 (UTC)

hi, I have this error when building: + install /tmp/makepkg/mpv-git/pkg/mpv-git/usr/share/zsh/site-functions/_mpv (from build/etc/_mpv) Waf: Leaving directory `/tmp/makepkg/mpv-git/src/mpv/build' 'install' finished successfully (0.780s) /home/luis/builds/mpv-git/PKGBUILD: line 74: /tmp/makepkg/mpv-git/src/ Permission denied ==> ERROR: A failure occurred in package(). Aborting... ... somebody else? I don't know if I missing something :/ ... thanks :-)

qmega commented on 2015-08-20 20:55 (UTC)

Good idea; done. It'll only show the first time you install, though, I don't want to bother people every time they upgrade.

AlfredoRamos commented on 2015-08-19 17:40 (UTC)

Ya I see your point, something similar happens with vim. Maybe a message in the .INSTALL file then?

qmega commented on 2015-08-14 05:49 (UTC)

An optdepend would suggest that mpv would still run if you uninstalled it, which would not be the case if you linked at build time. If you build it with lua52 installed, it will be a (hard) depend of the generated package. Also, it doesn't have to be lua52; luajit works as well (I believe). I know the dependency system is non-ideal, but I haven't thought of anything better. The way it is prevents dependencies from getting out of sync, and allows everyone to use whichever optional features they want without having to install a bunch of stuff they don't or edit the PKGBUILD every time. The price is that you have to figure out which extra packages you need the first time you install, but at least you only have to do that once. If you can think of a better system, I'm all ears.

AlfredoRamos commented on 2015-08-13 09:36 (UTC)

Could you add lua52 as optional dependency? It would be nice at least to know which version it (optionally) needs.

qmega commented on 2015-06-28 23:25 (UTC)

Works for me. Maybe a transient issue. Try again?

IncredibleLaser commented on 2015-05-26 16:33 (UTC)

You're completely correct, I mean the OSC. I just searched the internet and the first result I found for the OSC was that it needs luajit, so I just assumed that this is a dependency. I just realized I included your commented dependencies and it so happens that they list lua (but the list is, as you wrote, out of date).

qmega commented on 2015-05-24 05:06 (UTC)

I assume you're talking about the OSC, as the OSD doesn't require lua. Even for that, though, it doesn't have to be luajit. lua52 works as well. Whichever one you use will be picked up as a dependency automatically. What's the rationale for explicitly depending on luajit? It would make trouble for people who use lua52 instead (which I think is most people) and for anyone who wants to build without lua altogether.

IncredibleLaser commented on 2015-05-23 09:46 (UTC)

In order to compile mpv with the OSD, luajit is a needed dependency.

Corubba commented on 2015-03-15 08:55 (UTC)

the waf server seems to be unavailable at the moment, here is a patch to make the bootstrap use a (official) mirror instead.

qmega commented on 2015-03-10 01:00 (UTC)

I added it because the official community package did. I checked at the time and I was able to reproduce the issue (no relro or stack canary). However, I can't now, with a current checkout or with the release when the official package added the dep, for some reason. So I don't know what changed, but it looks like hardening-wrapper is no longer needed, so I've removed it. Thanks for pointing it out. Note that this means PIE will no longer be enabled by default, just because the default makepkg.conf doesn't do that, but it does work if you add the flags.

CounterPillow commented on 2015-03-09 16:49 (UTC)

Is there any specific security reason for hardening-wrapper to be required as a build dependency? It breaks dlang-dmd by hijacking the linker binary name and adding a bunch of unexpected options. I can remove it after the build process, of course, but I'd rather not have to deal with it at all. Can't the compiler/linker options it adds be added as a patch to the build script?

qmega commented on 2015-02-14 19:39 (UTC)

Sorry, I've been sick and haven't been keeping up with stuff. Made the sed change.

WorMzy commented on 2015-02-12 12:52 (UTC)

It should work again now, rc2 is out, and has been tagged with an underscore instead of a hyphen. qmega: You might want to modfiy the sed command on the _tagver line to replace hyphens with underscores in case hyphens are used in future versions. Changing it to sed -e 's:^v::' -e 's:-:_:g' should work.

WorMzy commented on 2015-01-24 12:30 (UTC)

It shouldn't need a <commit-id> (just called <commit> in the man page), --tags replaces it: --tags[=<pattern>] Pretend as if all the refs in refs/tags are listed on the command line as <commit>. If <pattern> is given, limit tags to ones matching given shell glob. If pattern lacks ?, *, or [, /* at the end is implied.

qmega commented on 2015-01-19 06:02 (UTC)

Ah, yeah, sorry about that. My script didn't like it if the binary was linked against untracked libraries. I had meant to fix that the next time I worked on the script, but haven't gotten around to it yet. Implemented a sloppy fix for now.

rezad commented on 2015-01-18 22:33 (UTC)

i get some error with the last step of package creation error: No package owns /usr/lib/ error: No package owns /usr/lib/ Traceback (most recent call last): File "/media/shared/apps/usr/tmp/makepkg/mpv-git/src/", line 25, in <module> ['pacman', '--query', '--owns', '--quiet'] + list(libs)

Ram-Z commented on 2015-01-07 23:41 (UTC)

Ah yes true, `objdump` only lists the filename. For what it's worth, I wrote a bash script a while back which does almost the same using `objdump`: Unfortunately it depends on mlocate, which might not be installed on every system. I hadn't thought of using ldconfig, thanks for the tip. Yeah, I thought of the whole dependencies thing after commenting, so it does actually have a purpose beyond pleasing namcap. If it works it's probably fine for an AUR pkg, even if ugly. Although split pkgs can have a separate depends, it is still static. I was talking about dynamically generating the array during execution being dirty.

qmega commented on 2015-01-07 09:03 (UTC)

Hmm, yeah, objdump is probably a better idea. Then I wouldn't need to special-case fakeroot, and might avoid similar problems in the future. The reason I used ldd was mainly out of laziness, because it gives you the actual path so you don't have to hunt down the files. I could get the mapping from ldconfig and use that, but on a 64-bit machine that includes 32-bit libs with the same name. I can probably figure something out, but I won't have much computer access for the next few days, so it's unlikely I'll get a chance to work on it until the weekend or so. In the mean time, any suggestions are welcome. As for the value of the whole thing, it certainly is a dirty hack, but having accurate dependencies is not just about making namcap happy. I don't know if you're familiar with mpv's build process, but the basic gist is that it links against any optional dependencies it finds on the system (and there are quite a few). For example, I personally use libbs2b, but I'm guessing most people don't. If that isn't included in the depends for my mpv package, then pacman would let me remove it without a second thought, but that would render my current build of mpv unable to run. It would also let me install the same package on another machine where it wouldn't work; one of the jobs of a package manager is to automatically install dependencies in cases like that. On the other hand, I don't want to try to add every possible optional feature as a hard depend, because then everyone would have to either dig through the (long) list every time they build, or install a bunch of packages they don't need. As for modifying depends in package(), I think that's reliable/supported because it's used for split packages. Still, I know it's ugly, and I don't really like it either, but it was the only semi-reasonable solution I could think of; no static set of depends will be right for everyone. If anyone has a better way to address this problem, I'd love to hear it. Or, if everyone hates this, I can drop it, but then we'll be back where we started (which was not a great place, IMO). In any case, thanks @Ram-Z for taking the time to look at / comment on it.

Ram-Z commented on 2015-01-06 23:39 (UTC)

You might want to use `objdump -p | sed -n 's/NEEDED\s*//p'` to only pick up on actual dependencies instead of the recursive `ldd`. (or whatever python equivalent to extract the lib from the NEEDED line) But to be honest, I don't think that this is a good solution, it's pretty dirty and hacky to modify the depend array during makepkg. And for what?! Make namcap happy?! Not worth it IMHO, but, hey, that's just me and I don't even use Arch. So whatever.

qmega commented on 2015-01-01 04:21 (UTC)

Added experimental dependency detection. The built package should now better reflect what the mpv inside actually links against. It seems to be working pretty well so far, but please let me know if it gets something wrong. The only issue I'm currently having on my system is that it pulls in mesa unnecessarily, which I think has to do with some provides mess; I don't have time to look into it at the moment. Any feedback appreciated.

qmega commented on 2014-12-31 00:22 (UTC)

portaudio was removed upstream yesterday. I've updated for that. As for the dependencies, that's happening because the configure script automatically picks up whatever it finds on your system; see the warning at the top of the PKGBUILD. xdg-utils is needed for the install script, but namcap doesn't know that. As for the lua stuff, the configure is probably picking up lua51 and building against that, and so it doesn't link against 5.2, which the lua package provides. I've been thinking about writing something to update dependencies in package() or something... I'll get around to it eventually.

haawda commented on 2014-12-30 22:30 (UTC)

And, some dependencies seem to have changed: haawda@frege mpv-git]$ namcap ~/repo/mpv-git-0.7.2_2822_g628f1dc-1-x86_64.pkg.tar.xz mpv-git E: Dependency libcaca detected and not included (libraries ['usr/lib/'] needed in files ['usr/lib/', 'usr/bin/mpv']) mpv-git E: Dependency jack detected and not included (libraries ['usr/lib/'] needed in files ['usr/lib/', 'usr/bin/mpv']) mpv-git E: Dependency lua51 detected and not included (libraries ['usr/lib/'] needed in files ['usr/lib/', 'usr/bin/mpv']) mpv-git W: Dependency included and not needed ('xdg-utils') mpv-git W: Dependency included and not needed ('lua')

haawda commented on 2014-12-30 22:24 (UTC)

I get: waf: error: no such option: --enable-portaudio

qmega commented on 2014-11-19 19:00 (UTC)

youtube-dl support is now baked in but not enabled by default. Use --ytdl to enable.

qmega commented on 2014-10-31 17:57 (UTC)

FYI, the lua replacement is coming along nicely: I've been using it for a little while with no issues. (I don't use it very often, though, so YMMV. At least it hasn't broken anything else.) The version of youtube-dl in the Arch repos is now new enough that it'll work without modification, so I'd encourage anyone who uses mpv for youtube to try out the new script. Testing is needed.

qmega commented on 2014-10-25 20:23 (UTC)

Fair enough. Done.

diffycat commented on 2014-10-25 19:09 (UTC)

Why not uncomment that line by default and add 'youtube-dl' to optdepends?

qmega commented on 2014-10-25 18:57 (UTC)

Upstream has removed quvi support. If you want to install the replacement script which uses youtube-dl, you can just uncomment the line at the end of package(). Obviously you'll need youtube-dl installed for the script to work. There should be a lua plugin soon that allows giving mpv URLs on the command line like before.

commented on 2014-09-25 08:40 (UTC)

To anyone, if you run into the following error: mpv: error while loading shared libraries: cannot open shared object file: No such file or directory Just reinstall mpv-git. Recently, `libdvdnav` was upgraded, so mpv has to be linked again.

WorMzy commented on 2014-09-19 22:55 (UTC)

qmega, any chance you could switch to a more descriptive pkgver in the future? I use the following in my local build: pkgver() { cd "$srcdir/$_gitname" _curtag="$(git rev-list --tags --max-count=1)" _tagver="$(git describe --tags $_curtag | sed 's:^v::')" _commits="$(git rev-list --count HEAD --since=$_tagver)" _sha="$(git rev-parse --short HEAD)" printf "%s_%s_g%s" $_tagver $_commits $_sha } Resolves to: pkgver=0.5.3_1553_g60f5e53 Credit to for the pointers.

qmega commented on 2014-09-06 21:08 (UTC)

Yeah, that dependency will definitely go away in the near-ish future. I had actually considered dropping it already and including the script in the package, but at the moment the built-in support is more convenient and still works most of the time, in my experience (though I don't use it very often). But I suppose I could go ahead and get rid of it anyway, and it would still link against quvi if it's installed at build time. Any opinions?

rpolzer commented on 2014-07-11 19:31 (UTC)

Sorry - I no longer have the time to maintain this package. It is now up for adoption.

nasedo commented on 2014-07-08 14:49 (UTC)

Please change dependency on lua51 to lua. There were issues with mpv and libquvi linking to different versions but extra/libquvi now uses lua 5.2 (as does community/mpv).

qmega commented on 2014-06-26 22:16 (UTC)

Please enable generation of zsh completion (--enable-zsh-comp). Might also be a good idea to add the other deps/flags that were recently added to the official package.

Barthalion commented on 2014-05-20 16:44 (UTC)

In case you are looking for a nicer pkgver(), here's what I used to use: pkgver() { cd mpv _tag=$(git tag -l | tail -n1 | cut -c 2-) _commits=$(git rev-list v${_tag}..@ --count) _hash=$(git rev-parse --short @) echo ${_tag}.${_commits}.${_hash} } It's not perfect, but a bit more meaningful that number of commits.

trizen commented on 2014-05-08 09:04 (UTC)

It builds fine, but I get a "segmentation fault" when I try to run it. Does anyone else have this problem?

pdexter commented on 2014-03-28 20:48 (UTC)

That did it, thanks!

Nothing4You commented on 2014-03-28 20:43 (UTC)

That means that you have to recompile the package because a shared lib dependency was updated.

pdexter commented on 2014-03-28 20:29 (UTC)

When opening an mkv file mpv: error while loading shared libraries: cannot open shared object file: No such file or directory

rpolzer commented on 2014-01-23 14:58 (UTC)

Works for me without having that installed. Maybe because of something else in AUR?

vonn commented on 2014-01-22 13:00 (UTC)

Fixed installing libpthread-stubs from AUR.

vonn commented on 2014-01-22 12:51 (UTC)

I'm getting "Unable to find pthreads support." error. What should I do? Here the entire output:

rpolzer commented on 2014-01-22 07:48 (UTC)

Fixed sdl2. As for waf: the author of waf disagrees with doing that, as he wants to reserve the right to do incompatible changes to waf. So we insist on using the one version of waf we develop for. In fact, filing a bug upstream that the build scripts don't work with ANOTHER version of waf will simply have no success.

RunningDroid commented on 2014-01-22 01:49 (UTC)

Please add --enable-sdl2 to the configure line, add waf to makedepends, remove "./", and use the system's waf instead of the one fetched by

rpolzer commented on 2014-01-21 09:42 (UTC)

Fixed libcdio issue by bumping the version.

SleepyFloyd commented on 2014-01-19 20:12 (UTC)

Nope, ffmpeg still works. VLC and mplayer also got updated today, they work fine, too.

rpolzer commented on 2014-01-19 20:04 (UTC)

Same error if you run ffmpeg from the command line? If yes, the issue is there.

SleepyFloyd commented on 2014-01-19 20:02 (UTC)

January 19th update of libcdio (or libcdio-paranoia?) breaks mpv. " can't be found." Symlinking the new library back doesn't work as a temponary fix.

polyzen commented on 2013-12-28 22:18 (UTC)

Got the following while makepkg was in package() as the file isn't in $srcdir/$_gitname/etc: "install: cannot stat ‘etc/encoding-example-profiles.conf’: No such file or directory" Removing ",encoding-example-profiles" from line 71 fixes this.

ricardomv commented on 2013-12-28 22:16 (UTC)

please do not install ‘etc/encoding-example-profiles.conf’ manually it is now installed by default

rpolzer commented on 2013-12-20 18:29 (UTC)

Right. Fixed it.

commented on 2013-12-18 18:37 (UTC)

Actually, "--disable-lircc" was just removed and "--disable-lirc" is a different option. See

kritztopf commented on 2013-12-18 16:36 (UTC)

The PKGBUILD contains a typo, there's an extra c after --disable-lirc. Fixed PKGBUILD: Greetings

sl1pkn07 commented on 2013-11-24 13:45 (UTC)


sl1pkn07 commented on 2013-11-23 19:31 (UTC)

i don't know is a waf bug, bug vapoursynth use waf with python3 and don't have the issue > mpv waf with python3 > mpv waf with python2

rpolzer commented on 2013-11-23 18:24 (UTC)

Sounds more like a waf bug then. Will debug this first, maybe there is a way around it or waf fixes it soon.

sl1pkn07 commented on 2013-11-23 17:48 (UTC)

please change: "./waf" to "python2 ./waf" if use python/python3 the ./waf install rebuild everything greetings

misc commented on 2013-11-23 16:54 (UTC)

Since pacman 4.1 there is also prepare() for the configuration commands.

rpolzer commented on 2013-11-23 15:15 (UTC)

Doing the compiles from package() is AFAIK unacceptable. Will see how to fix this.

commented on 2013-11-23 13:56 (UTC)

respects CFLAGS and doesn't build twice:

jahiy commented on 2013-11-23 12:07 (UTC)

PKGBUILD for mpv-git (waf) I rewrite PKGBUILD to use waf for building.

commented on 2013-11-22 15:02 (UTC)

/home/lucy/.build/mpv-git/PKGBUILD: line 42: ./configure: No such file or directory mpv switched to waf for building pkgbuild should be updated to use it ( or ./old-configure (which will be removed in the future)

Nothing4You commented on 2013-11-17 17:53 (UTC)

Oh, ffmpeg, right. I forgot about that, rebuilding it now.

rpolzer commented on 2013-11-17 16:52 (UTC)

Cannot reproduce. But, mpv nowhere uses libnut. This is ffmpeg's doing. Can you try rebuilding/reinstalling ffmpeg, then try again? Also, what does "ffprobe -version" say?

Nothing4You commented on 2013-11-17 15:51 (UTC)

video/decode/lavc_dr1.c:258:9: warning: 'avcodec_default_release_buffer' is deprecated (declared at /usr/include/libavcodec/avcodec.h:3666) [-Wdeprecated-declarations] avcodec_default_release_buffer(s, frame); ^ CC video/filter/vf_dlopen.o CC mpv /usr/bin/ld: cannot find -lnut collect2: error: ld returned 1 exit status Makefile:389: recipe for target 'mpv' failed make: *** [mpv] Error 1 ==> ERROR: A failure occurred in build(). Aborting...

rpolzer commented on 2013-11-16 13:52 (UTC)

The two spaces serve to help me to sync with the community "mpv" PKGBUILD.

rpolzer commented on 2013-10-27 11:14 (UTC)

Done. Also synced with community/mpv.

rpolzer commented on 2013-10-25 15:33 (UTC) As you see, the real issue is broken sdl2. A fixed version is already in staging. Once it is in the main repository, I will bump this PKGBUILD to trigger recompile.

karol_007 commented on 2013-10-25 13:06 (UTC)

Checking for SSA/ASS support ... yes Checking for libass OSD support ... yes Checking for ENCA ... no Checking for zlib ... Error: Unable to find development files for zlib. Check "config.log" if you do not understand why it failed. ==> ERROR: A failure occurred in build(). Aborting... Suggested fix: remove '--enable-sdl2'

sl1pkn07 commented on 2013-10-22 13:44 (UTC)

quvi/libquvi/libquvi-scripts from [extra] is building with lua51, then need build mpv with lua51 support. by default, if have installed both version of lua (lua51 and lua(52)), always search first place lua51, if found use it quvi-git/libquvi-git/libquvi-scripts-git and libquvi/quvi/libquvi-scripts 0.4 branch from [AUR] is building with lua(52), if use with mpv/mpv-git need rebuild mpv/mpv-git with --lua=52 flag greetings

rpolzer commented on 2013-10-22 13:18 (UTC)

The check for Lua is a more complicated story. It should indeed possibly cause segfaults in e.g. dmesg, but should not abort compilation. The issue is that both mpv-git and quvi use Lua, but linking two different Lua versions will cause a crash. So the check serves to try out the condition that would lead to a crash in mismatching Lua versions, to find out the Lua release quvi was linked to.

lolilolicon commented on 2013-10-01 04:51 (UTC)

I second @ipha, the pdf is really redundant, and I suspect is more oriented at Windows users who do not have a proper manual system. --disable-pdf is what I do.

ipha commented on 2013-10-01 04:46 (UTC)

Is building the PDF doc really necessary? AFIK it's the exact same information that's in the man page.

holos commented on 2013-09-29 17:53 (UTC)

At least here, ./configure's check for lua51 will crash. Setting --lua=52 bypasses this needless check

rpolzer commented on 2013-09-22 15:38 (UTC)

Thanks, I applied the changes to my PKGBUILD, and also synced it with the [community] one. Differences to it in dependencies are separated by two spaces, and configure flags by that backslash line.

aphirst commented on 2013-09-22 13:37 (UTC)

Aha! There was a docutils.conf file elsewhere in the repo - and when I fed that as a --config option to rst2latex, pdflatex failed because it couldn't find fullpage.sty This is in the package texlive-latexextra, so could you add that to depends? With that, mpv-git builds fine.

aphirst commented on 2013-09-22 13:04 (UTC)

By adding --disable-pdf to ./configure I was able to get it to successfully build. The guys on the mpv IRC channel reckon this is to do with a missing texlive dependency. I only have texlive-core and texlive-bin installed currently, and this package works fine for someone with texlive-most installed. I tried to use rst2latex and pdftex on the .rst files from the git manually to try to work out which packages were causing failures, but frustratingly the PDF _appears_ to be successfully generated. As such, I myself haven't been able to work out exactly which specific texlive dependency is required. Hopefully someone else can fathom that out, but in the meantime --disable-pdf lets the package compile for everyone.

aphirst commented on 2013-09-22 01:50 (UTC)

Tried installing this just now - got right to the end then failed on generating one of the documentation PDFs: audio/filter/af_lavfi.c: In function 'recreate_graph': audio/filter/af_lavfi.c:149:5: warning: 'avfilter_graph_parse' is deprecated (declared at /usr/include/libavfilter/avfilter.h:1352) [-Wdeprecated-declarations] if (graph_parse(graph, p->cfg_graph, inputs, outputs, NULL) < 0) ^ CC video/filter/vf_dlopen.o CC mpv DOCS/man/en/mpv.rst DOCS/man/en/mpv.1 --config=DOCS/man/docutils.conf DOCS/man/en/mpv.rst DOCS/man/en/mpv.tex pdflatex -interaction=batchmode -jobname=DOCS/man/en/mpv DOCS/man/en/mpv.tex; pdflatex -interaction=batchmode -jobname=DOCS/man/en/mpv DOCS/man/en/mpv.tex This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013/Arch Linux) restricted \write18 enabled. entering extended mode This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013/Arch Linux) restricted \write18 enabled. entering extended mode make: *** [DOCS/man/en/mpv.pdf] Error 1 rm DOCS/man/en/mpv.tex ==> ERROR: A failure occurred in build(). Aborting... ==> ERROR: Makepkg was unable to build mpv-git.

commented on 2013-09-21 18:43 (UTC)

.desktop file (and icons) are now upstream, so no need to override them in this package

PerfectGentleman commented on 2013-09-19 13:30 (UTC)

built packages with CFLAGS="-march=native -mtune=native -O2 -pipe -fomit-frame-pointer -fopenmp" CXXFLAGS="-march=native -mtune=native -O2 -pipe -fomit-frame-pointer -fopenmp"

alucryd commented on 2013-09-07 17:34 (UTC)

This does not belong in the AUR, see thread here

alucryd commented on 2013-09-07 10:41 (UTC)

Duplicate of mpv-git, which was around longer, plus mpv is now in [community]. Merging into mpv-git.

diffycat commented on 2013-09-06 16:56 (UTC)

@lolilolicon Yes, but i believe it should be fixed in that pkgbuild. And community/mpv doesn't provide vaapi support.

lolilolicon commented on 2013-09-06 16:02 (UTC)

@diffycat, the error message can't be much clearer; it's due to the removal of mplayer.xpm: Maybe community/mpv is sufficient for you? One less package to build yourself is always a good thing :)

diffycat commented on 2013-09-06 15:47 (UTC)

package() failed to me: ==> Entering fakeroot environment... ==> Starting package()... ./ if test ! -d /tmp/yaourt-tmp-aidan/aur-mpv-git/pkg/mpv-git/usr/bin ; then install -d /tmp/yaourt-tmp-aidan/aur-mpv-git/pkg/mpv-git/usr/bin ; fi install -m 755 mpv /tmp/yaourt-tmp-aidan/aur-mpv-git/pkg/mpv-git/usr/bin if test ! -d /tmp/yaourt-tmp-aidan/aur-mpv-git/pkg/mpv-git/usr/share/man/man1 ; then install -d /tmp/yaourt-tmp-aidan/aur-mpv-git/pkg/mpv-git/usr/share/man/man1 ; fi install -m 644 DOCS/man/en/mpv.1 /tmp/yaourt-tmp-aidan/aur-mpv-git/pkg/mpv-git/usr/share/man/man1/ install: cannot stat ‘/tmp/yaourt-tmp-aidan/aur-mpv-git/src/mpv/etc/mplayer.xpm’: No such file or directory ==> ERROR: A failure occurred in package(). Aborting...

RunningDroid commented on 2013-09-04 17:42 (UTC)

Can you have this also install the 16x16, 32x32, and 64x64 icon pngs?

RunningDroid commented on 2013-09-04 17:17 (UTC)

etc/mpv-icon-source.svg has been removed, but now there are 16x16, 32x32, and 64x64 pngs of the icon.

lolilolicon commented on 2013-08-29 02:03 (UTC)

@c_14, it's not actually wayland 1.2.1 that fixes the issue; actually if you compiled with that, your mpv is not wayland-enabled. The issue was fixed on mpv's side:

c_14 commented on 2013-08-28 22:05 (UTC)

New version of wayland in [extra] fixes issue. mpv-git compiles fine now.

rtfreedman commented on 2013-08-27 21:23 (UTC)

Install lua51-socket from community - libquvi needs it.

flecht commented on 2013-08-27 11:22 (UTC)

I got some wayland errors and had to disable it.

timofonic commented on 2013-08-27 06:55 (UTC)

mpv "" Playing ** (process:14542): CRITICAL **: [_chk_script_ident] /usr/share/libquvi-scripts/0.9/common/quvi/youtube.lua:69: module 'socket.url' not found: no field package.preload['socket.url'] no file '/usr/share/lua/5.2/socket/url.lua' no file '/usr/share/lua/5.2/socket/url/init.lua' no file '/usr/lib/lua/5.2/socket/url.lua' no file '/usr/lib/lua/5.2/socket/url/init.lua' no file './socket/url.lua' no file '/usr/share/libquvi-scripts/0.9/common/socket/url.lua' no file '/usr/lib/lua/5.2/socket/' no file '/usr/lib/lua/5.2/' no file './socket/' no file '/usr/lib/lua/5.2/' no file '/usr/lib/lua/5.2/' no file './' [quvi] Could not find any subtitle scripts in the path [ffmpeg/?] https protocol not found, recompile with openssl or gnutls enabled. [ffmpeg] Protocol not found. Make sure ffmpeg/Libav is compiled with networking support. Failed to open What's wrong?

timofonic commented on 2013-08-27 06:02 (UTC)

I have the wayland package installed (from [extra]) and I get the same error as if not installed.

lolilolicon commented on 2013-08-26 03:54 (UTC)

--disable-wayland would be the way to go for now. Right now you need wayland from git to build with wayland support. The additional WL_SHM_FORMAT_* are introduced in: The breaking mpv commit:

WonderWoofy commented on 2013-08-26 00:59 (UTC)

Clean chroot doens't work, but simply dissabling wayland support does. Building in a clean chroot still pulls in the deps that also pull in wayland. I shouldn't have deleted that post…

WonderWoofy commented on 2013-08-26 00:58 (UTC)

Add '--disable-wayland \' to the configure options.

karol_007 commented on 2013-08-26 00:57 (UTC)

Ooops, you're right WonderWoofy, I do have wayland installed.

karol_007 commented on 2013-08-26 00:51 (UTC)

If you don't have wayland, it fails with CC video/out/vo_wayland.o video/out/vo_wayland.c:61:6: error: 'WL_SHM_FORMAT_RGB332' undeclared here (not in a function) {WL_SHM_FORMAT_RGB332, IMGFMT_BGR8, false}, // 3b 3g 2r ^ video/out/vo_wayland.c:62:6: error: 'WL_SHM_FORMAT_BGR233' undeclared here (not in a function) {WL_SHM_FORMAT_BGR233, IMGFMT_RGB8, false}, // 3r 3g 3b, ^ video/out/vo_wayland.c:63:6: error: 'WL_SHM_FORMAT_XRGB4444' undeclared here (not in a function) {WL_SHM_FORMAT_XRGB4444, IMGFMT_BGR12_LE, false}, // 4b 4g 4r 4a ^ video/out/vo_wayland.c:64:6: error: 'WL_SHM_FORMAT_XBGR4444' undeclared here (not in a function) {WL_SHM_FORMAT_XBGR4444, IMGFMT_RGB12_LE, false}, // 4r 4g 4b 4a ^ video/out/vo_wayland.c:65:6: error: 'WL_SHM_FORMAT_RGBX4444' undeclared here (not in a function) {WL_SHM_FORMAT_RGBX4444, IMGFMT_RGB12_BE, false}, // 4a 4b 4g 4r ^ video/out/vo_wayland.c:66:6: error: 'WL_SHM_FORMAT_BGRX4444' undeclared here (not in a function) {WL_SHM_FORMAT_BGRX4444, IMGFMT_BGR12_BE, false}, // 4a 4r 4g 4b ^ video/out/vo_wayland.c:67:6: error: 'WL_SHM_FORMAT_ARGB4444' undeclared here (not in a function) {WL_SHM_FORMAT_ARGB4444, IMGFMT_BGR12_LE, false}, ^ video/out/vo_wayland.c:68:6: error: 'WL_SHM_FORMAT_ABGR4444' undeclared here (not in a function) {WL_SHM_FORMAT_ABGR4444, IMGFMT_RGB12_LE, false}, ^ video/out/vo_wayland.c:69:6: error: 'WL_SHM_FORMAT_RGBA4444' undeclared here (not in a function) {WL_SHM_FORMAT_RGBA4444, IMGFMT_RGB12_BE, false}, ^ video/out/vo_wayland.c:70:6: error: 'WL_SHM_FORMAT_BGRA4444' undeclared here (not in a function) {WL_SHM_FORMAT_BGRA4444, IMGFMT_BGR12_BE, false}, video/out/vo_wayland.c:71:6: error: 'WL_SHM_FORMAT_XRGB1555' undeclared here (not in a function) {WL_SHM_FORMAT_XRGB1555, IMGFMT_BGR15_LE, false}, // 5b 5g 5r 1a ^ video/out/vo_wayland.c:72:6: error: 'WL_SHM_FORMAT_XBGR1555' undeclared here (not in a function) {WL_SHM_FORMAT_XBGR1555, IMGFMT_RGB15_LE, false}, // 5r 5g 5b 1a ^ video/out/vo_wayland.c:73:6: error: 'WL_SHM_FORMAT_RGBX5551' undeclared here (not in a function) {WL_SHM_FORMAT_RGBX5551, IMGFMT_RGB15_BE, false}, // 1a 5g 5b 5r ^ video/out/vo_wayland.c:74:6: error: 'WL_SHM_FORMAT_BGRX5551' undeclared here (not in a function) {WL_SHM_FORMAT_BGRX5551, IMGFMT_BGR15_BE, false}, // 1a 5r 5g 5b ^ video/out/vo_wayland.c:75:6: error: 'WL_SHM_FORMAT_ARGB1555' undeclared here (not in a function) {WL_SHM_FORMAT_ARGB1555, IMGFMT_BGR15_LE, false}, video/out/vo_wayland.c:76:6: error: 'WL_SHM_FORMAT_ABGR1555' undeclared here (not in a function) {WL_SHM_FORMAT_ABGR1555, IMGFMT_RGB15_LE, false}, ^ video/out/vo_wayland.c:77:6: error: 'WL_SHM_FORMAT_RGBA5551' undeclared here (not in a function) {WL_SHM_FORMAT_RGBA5551, IMGFMT_RGB15_BE, false}, ^ video/out/vo_wayland.c:78:6: error: 'WL_SHM_FORMAT_BGRA5551' undeclared here (not in a function) {WL_SHM_FORMAT_BGRA5551, IMGFMT_BGR15_BE, false}, ^ video/out/vo_wayland.c:79:6: error: 'WL_SHM_FORMAT_RGB565' undeclared here (not in a function) {WL_SHM_FORMAT_RGB565, IMGFMT_BGR16_LE, false}, // 5b 6g 5r ^ video/out/vo_wayland.c:80:6: error: 'WL_SHM_FORMAT_BGR565' undeclared here (not in a function) {WL_SHM_FORMAT_BGR565, IMGFMT_RGB16_LE, false}, // 5r 6g 5b ^ video/out/vo_wayland.c:81:6: error: 'WL_SHM_FORMAT_RGB888' undeclared here (not in a function) {WL_SHM_FORMAT_RGB888, IMGFMT_BGR24, false}, // 8b 8g 8r ^ video/out/vo_wayland.c:82:6: error: 'WL_SHM_FORMAT_BGR888' undeclared here (not in a function) {WL_SHM_FORMAT_BGR888, IMGFMT_RGB24, false}, // 8r 8g 8b ^ video/out/vo_wayland.c:83:6: error: 'WL_SHM_FORMAT_XBGR8888' undeclared here (not in a function) {WL_SHM_FORMAT_XBGR8888, IMGFMT_RGB0, false}, ^ video/out/vo_wayland.c:84:6: error: 'WL_SHM_FORMAT_RGBX8888' undeclared here (not in a function) {WL_SHM_FORMAT_RGBX8888, IMGFMT_0BGR, false}, ^ video/out/vo_wayland.c:85:6: error: 'WL_SHM_FORMAT_BGRX8888' undeclared here (not in a function) {WL_SHM_FORMAT_BGRX8888, IMGFMT_0RGB, false}, ^ video/out/vo_wayland.c:86:6: error: 'WL_SHM_FORMAT_ABGR8888' undeclared here (not in a function) {WL_SHM_FORMAT_ABGR8888, IMGFMT_RGBA, false}, ^ video/out/vo_wayland.c:87:6: error: 'WL_SHM_FORMAT_RGBA8888' undeclared here (not in a function) {WL_SHM_FORMAT_RGBA8888, IMGFMT_ABGR, false}, ^ video/out/vo_wayland.c:88:6: error: 'WL_SHM_FORMAT_BGRA8888' undeclared here (not in a function) {WL_SHM_FORMAT_BGRA8888, IMGFMT_ARGB, false}, ^ make: *** [video/out/vo_wayland.o] Error 1 ==> ERROR: A failure occurred in build(). Aborting... I installed mpv

felixonmars commented on 2013-08-26 00:32 (UTC)

Build failed for me, due to something missing about wayland: video/out/vo_wayland.c:61:6: error: 'WL_SHM_FORMAT_RGB332' undeclared here (not in a function) {WL_SHM_FORMAT_RGB332, IMGFMT_BGR8, false}, // 3b 3g 2r ^ I do have wayland 1.2.0 from [extra] installed, and the configure script should find it: Checking for Wayland ... yes Could anyone help me with this?

qmega commented on 2013-08-23 21:29 (UTC)

The -really-quiet in the desktop file should probably have two leading dashes (--really-quiet). mpv prefers that format (see their changes file). Obviously not a big deal, but not exactly hard to fix either. Also, maybe change the %F to %U because it can handle URLs.

rpolzer commented on 2013-08-15 13:09 (UTC)

No. The only bug is somewhat misleading option naming. --enable-lirc enable LIRC (remote control) support [autodetect] --enable-lircc enable LIRCCD (LIRC client daemon) input [autodetect] We enable lirc (by using the dependency and autodetect), and disable this client daemon thing. --enable flags are (and always were) broken in mplayer/mpv's configure script, so we don't use them (basically, they skip ALL detection, including calling pkg-config to figure out the proper CFLAGS/LDFLAGS, so if we used them, we'd have to put all that logic into the PKGBUILD). I honestly do not even remember why I disabled the client daemon. Does anyone want it? I will then just enable it by removing its --disable and adding the dependency. I don't have an infrared port, so I don't care.

lolilolicon commented on 2013-08-15 05:32 (UTC)

Doesn't that mean a bug in either namcap or mpv?

rpolzer commented on 2013-08-15 05:04 (UTC)

namcap says lirc-utils IS used. So keeping that there.

rpolzer commented on 2013-08-15 04:20 (UTC)

As for icon and desktop file, we're rather discussing this upstream first. For now only fixing the MIME type.

jleclanche commented on 2013-08-12 01:19 (UTC)

Please remove lirc-utils dependency since you compile with lirc disabled.

qmega commented on 2013-08-10 06:41 (UTC)

audio/x-flac is missing from the desktop file.

sl1pkn07 commented on 2013-08-07 13:54 (UTC)

mpv-git uses different repo/branch

patryk commented on 2013-08-07 12:03 (UTC)

what is difference between this package and mpv-git ?

lolilolicon commented on 2013-08-03 15:13 (UTC)

Hello, the mplayer.xpm icon is too shabby; why don't we use the mpv svg image instead? rsvg-convert -a -w 256 -h 256 -f png -o "$pkgdir"/usr/share/pixmaps/mpv.png etc/mpv-icon-source.svg (add librsvg to makedepends probably)

rtfreedman commented on 2013-07-20 03:07 (UTC)

I'm sorry, but I don't know nothing whatsoever about wayland - never used it myself.

Gently commented on 2013-07-20 02:15 (UTC)

Can this be run just as is and wayland is invoked or does a special method need to be used to call mpv from and session?

rtfreedman commented on 2013-07-12 14:48 (UTC)

Back to gcc - clang chokes... added fribidi-git and disabled cpu runtime detection

ValdikSS commented on 2013-07-12 09:14 (UTC)

Validating source files with md5sums mpv.desktop ... FAILED

misc commented on 2013-07-08 14:51 (UTC)

mpv.desktop lacks "video/webm".

adam777 commented on 2013-07-08 12:44 (UTC)

Thanks @drcouzelis, it worked. Hopefully the PKGBUILD will be updated soon.

drcouzelis commented on 2013-07-08 03:05 (UTC)

@adam777: I was able to compile mpv-git by removing these two options: --disable-winsock2_h --disable-vstream

adam777 commented on 2013-07-07 19:23 (UTC)

I get the following error when trying to update to the latest git version: --2013-07-07 22:19:49-- Resolving (, 2a01:4f8:120:34c2::2 Connecting to (||:443... connected. HTTP request sent, awaiting response... 200 OK Length: 1909 (1.9K) [application/x-gzip] Saving to: ‘mpv-git.tar.gz’ 100%[==========================================================>] 1,909 --.-K/s in 0s 2013-07-07 22:19:49 (145 MB/s) - ‘mpv-git.tar.gz’ saved [1909/1909] mpv-git/ mpv-git/mpv.desktop mpv-git/mpv.install mpv-git/PKGBUILD ==> Making package: mpv-git 0.35042.b5f07e8-1 (Sun Jul 7 22:19:49 IDT 2013) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Cloning mpv git repo... Cloning into bare repository '/home/adamdagan/mpv-git/mpv'... remote: Counting objects: 197032, done. remote: Compressing objects: 100% (39170/39170), done. remote: Total 197032 (delta 155338), reused 195608 (delta 154065) Receiving objects: 100% (197032/197032), 43.87 MiB | 544.00 KiB/s, done. Resolving deltas: 100% (155338/155338), done. Checking connectivity... done -> Found mpv.desktop ==> Validating source files with md5sums... mpv ... Skipped mpv.desktop ... Passed ==> Extracting sources... -> Creating working copy of mpv git repo... Cloning into 'mpv'... done. Checking connectivity... done Branch makepkg set up to track remote branch master from origin. Switched to a new branch 'makepkg' ==> Starting pkgver()... ==> Updated version: mpv-git 0.35413.441b684-1 ==> Starting build()... ==> Starting configure... Unknown parameter: --disable-winsock2_h ==> ERROR: A failure occurred in build(). Aborting...

rtfreedman commented on 2013-06-15 21:35 (UTC)

Added --enable-librtmp in ffmpeg's configure

karol_007 commented on 2013-06-11 14:15 (UTC)

Have you tried ? It depends on sdl2-hg, so maybe it uses it for something. mpv-git would at least need sdl as a dependency.

OrdinaryMagician commented on 2013-06-11 13:59 (UTC)

How the hell do I enable SDL video output? I tried adding --enable-sdl but that didn't work. :/

adam777 commented on 2013-05-31 14:30 (UTC)

Thanks, jsteel.

jsteel commented on 2013-05-31 09:34 (UTC)

Yes, it will only get updated here when it's resubmitted. You should track upstream and update when you like, or just from time to time.

adam777 commented on 2013-05-31 08:59 (UTC)

I have a question regarding the package version. From my (limited) PKGBUILD and git knowledge, it seems that the package version is "number of commits.git hash". It works perfectly fine if I clone the git repository myself. At the moment I'm getting "35130.76f6df6", which is indeed the latest. If I manually try to update the package, I end up with the package "mpv-git 0.35130.76f6df6-1" on my system, as expected. The AUR, however, states version "0.35042.b5f07e8" which is wrong, and so my update monitor isn't prompting me to update. Does the package version in the AUR only gets updated when the maintainer manually triggers such update? Thanks, Adam.

rtfreedman commented on 2013-05-20 20:38 (UTC)

"As for the useless configure flags: ..." I suggest then adding missing '--disable-dsound' - just to be sure ;)

vodik commented on 2013-05-19 19:42 (UTC)

Shit, my bad. I must have made a mess of it. Carry on. That said, %cd.%h is the date and hash of the last commit. It isn't just date alone. Quite a few other packages use that format and it works fine, even if there are more than one commit in a day.

rpolzer commented on 2013-05-19 18:06 (UTC)

As for the useless configure flags: I just prefer specifying all I can, and listing all others as deps, so that the package is guaranteed to build the same way for everyone. For easier manual checking if all flags have been looked at, I even included the "obviously redundant" ones.

rpolzer commented on 2013-05-19 18:05 (UTC)

But the number of commits comes first, only then the git hash. That way, versions ARE always increasing. Using only the date may be bad if there is more than one commit on a single day.

vodik commented on 2013-05-19 17:34 (UTC)

Might want to reconsider the "0.$minorver.$microver" pkgver. A newer package can be assigned a version that pacman thinks is older than the pervious package: $ vercmp 0.541fe30.35039 0.228c3d2.35040 1 I switched to `git log -1 --format="%cd.%h" --date=short | sed 's/-/./g'` so I can provide mpv-git in my personal repo.

rtfreedman commented on 2013-05-17 22:15 (UTC)

These are windows/macos specific auto-detected options and never fulfilled on i686/x86_64: --disable-winsock2_h --disable-direct3d --disable-macosx-bundle --disable-corevideo --disable-cocoa --disable-coreaudio Though, no harm is done... it's questionable and implies options are valid otherwise. Remove it for clarity.

sl1pkn07 commented on 2013-05-07 17:24 (UTC)

oh, zankius for the tip. updating...

rtfreedman commented on 2013-05-07 17:06 (UTC)

You need to add '--cc=clang' to scripts/ffmpeg-config And '--disable-programs' is a good idea as well

rtfreedman commented on 2013-05-07 17:02 (UTC)

This build script uses (persistent) git repositories (ffmpeg-git, mpv-git and libass-git) located where PKGBUILD resides - clang is used by default, but can be changed to gcc easily. It is heavily commented and configured without seldom used features by default

sl1pkn07 commented on 2013-04-28 22:20 (UTC)

to build with samba need: --extra-cflags="-I/usr/include/samba-4.0"

Barthalion commented on 2013-04-21 14:29 (UTC)

By the way, apparently smbclient isn't required anymore.

Barthalion commented on 2013-04-21 14:21 (UTC)

I'm wondering if it makes any sense to have a zero before the rest of string in $pkgver…

opt1mus commented on 2013-04-02 08:25 (UTC)

Successful build after removing; --disable-apple-remote \ --disable-apple-ir \

Nothing4You commented on 2013-04-01 23:02 (UTC)

==> Starting make... Unknown parameter: --disable-apple-remote ==> ERROR: A failure occurred in build(). Aborting... related to:

rpolzer commented on 2013-02-09 20:16 (UTC)

Yes, did exactly that. Thanks!

asdf-chan commented on 2013-02-07 20:59 (UTC)

As timofonic has said already, it's failing to build. It's related to this commit: >Remove BSD legacy TV/radio support (BT848 stuff) >>FreeBSD actually supports V4L2, and V4L2 supports this chip. Also, this chip is from 1997. Farewell. A quick fix would be deleting the 55th line with "--disable-radio-bsdbt848". Actually, it builds correctly if you delete that line. Regards, _asdf

timofonic commented on 2013-02-07 07:37 (UTC)

I'm unable to build this package. I installed ffmpeg-full-git too (but fixed it in ffmpeg-full-git-fixed, because unable to build it). # packer -S mpv-git Aur Targets (1): mpv-git Proceed with installation? [Y/n] Edit mpv-git PKGBUILD with $EDITOR? [Y/n] n Edit mpv.install with $EDITOR? [Y/n] n ==> Determining latest git revision... -> Version found: 20130207 ==> Making package: mpv-git 20130207-1 (Thu Feb 7 08:30:32 CET 2013) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving Sources... -> Found mpv.install -> Found mpv.desktop ==> Validating source files with md5sums... mpv.install ... Passed mpv.desktop ... Passed ==> Extracting Sources... ==> Removing existing pkg/ directory... ==> Starting build()... ==> Connecting to GIT server.... remote: Counting objects: 109, done. remote: Compressing objects: 100% (9/9), done. remote: Total 74 (delta 63), reused 74 (delta 63) Unpacking objects: 100% (74/74), done. From 630a2b1..ae070a6 master -> origin/master First, rewinding head to replay your work on top of it... Fast-forwarded master to ae070a6f1eff9f38dcd3ec785dd1f251e3761472. ==> The local files are updated. ==> GIT checkout done or server timeout ==> Starting make... Unknown parameter: --disable-radio-bsdbt848 ==> ERROR: A failure occurred in build(). Aborting... The build failed.

rpolzer commented on 2013-01-24 09:50 (UTC)

I am currently trying to get this patch upstream. It shouldn't be THAT hard... but I am waiting at the moment, as someone said they have a patch that will support BOTH libcdio versions. For now, I committed an adjusted configure check that disables the new version of libcdio.

flocke commented on 2013-01-24 09:44 (UTC)

I don't think you need to rewrite the patch, the version from mplayer2-git works just fine with mpv. I just compiled it with the patch.

Weegee commented on 2013-01-22 23:31 (UTC)

Okay, it seems like the new libcdio API needs a patch (as seen here: I just added "-disable-libcdio" to the PKGBUILD though since I don't need CD support, but I guess a rewrite of the patch in the mplayer2-git tarball should do it. I'm just too lazy right now ...

Weegee commented on 2013-01-22 23:16 (UTC)

Doesn't build on my system: stream/stream_cdda.c:20:23: fatal error: cdio/cdda.h: No such file or directory I have libcdio 0.90-2 and libcdio-paranoia 10.2+0.90-1 installed though ...