mpv and ffmpeg - Patch for successful build
 

As of today's update, mpv failed to build with ffmpeg. I Googled for a solution, and found some patches on Arch Linux's site (NOTE: patches are attached to this post. Download into the mpv directory and rename the files to remove .txt extension) which fixed the problem for me. I slightly modified the mpv.SlackBuild to automatically apply the patches before configuring and building.

After the line that says: But before: I inserted three blank lines, arrowed up 2, and inserted this line to apply the patches: mpv built successfully, and I am now watching videos with it, after the slackpkg update.

Hope this helps!

Its kind of silly to patch software that was intentionally broken out of the developer's personal spite. You're just going to get an unsupported build and a ton of pain when mpv upstream breaks it again.

Edit: Also for those you are missing the ytdl support built into mpv. This can be used with mplayer.

I don't use mpv because of politics. I use it because it works well for my needs, and I patched it so I can continue using it. I concern myself mainly with technical issues.

I was just looking at the github issue this morning. Apparently this is already fixed in mpv's git master, and the next release should be fine.

https://github.com/mpv-player/mpv/issues/5081

Personally, I was just going to rebuild it without libva support.

I just tried building it and of those patches just the vaapi-Use-libva2-message-callbacks.patch seems actually needed for the new va stuff on current.
BTW, thanks for reporting this!

You're very welcome! I didn't know if all of them were needed or not; however, it does no harm, and I'm inclined to leave them in for my personal system.

I don't know when the next release is going to be, and I don't have much experience with building from git; I just used the method I was most familiar with, and it worked. However, I look forward to the next release with anticipation.

mpv git head already includes the fixes for the new va libraries, but it won't build against ffmpeg 3.4 (something to do with using a libav api that hasn't be ported to ffmpeg yet.). it will build against ffmpeg head (3.5-dev) so when ffmpeg 3.5 is released that issue should resolve itself (unless anything else breaks in the mean time.).

The last official release of mpv, v0.27.0, will build against ffmpeg 3.4 but it doesn't have the fixes for the new va library versions, so it fails to build on current as of today's update.

This is the situation we currently find ourselves in.


An alternative to patching is using "git checkout -f f36d152eb7" to checkout a revision of mpv that has the vaapi changes, but still works with ffmpeg-3.4, and building from that until such time as 3.5 is out and slackware has moved to it. @marrowsuck deserves the credit for finding that.

just to clarify, mpv-0.27.0 builds fine against ffmpeg-3.4 on today's current with just this patch.

but v0.28 most likely wont. The revision marrowsuck identified is 302 changesets ahead of v0.27.0 and I think will be as uptodate as you'll be able to get without using ffmpeg 3.5 or the ffmpeg-mpv fork (which I don't like the idea of).

Both approaches appear to be valid. Use either the git revision listed above, or 0.27 and the patch, and you should be fine for now.

This is not politics, a better description is pointless self sabotage that is being imposed on the users. If you want to deal with unfriendly projects go for it. I just want people who come to this thread to better understand why this issue exists.

I'm not seeing much of a problem. They'll obviously delay the 0.28 release until FFMPEG 3.5 is out.

Yah that worked.

That's a perfectly good workaround for me, as I'm using the proprietary NVidia drivers.

Or it may be broken again when ffmpeg-3.5 is out. Mpv developers apparently has no respect for other projects and people shouldn't expect them to support ffmpeg anymore. It would be nice if they did, but I won't hold my breath for wm4 to rectify the damage caused by his tantrum or to not have another one.

In case the point was not clear, mpv works fine with ffmpeg-3.4 except for the fact that wm4 intentionally broke it because of personal issues. If it happened once it could happen again and users have only a few choices.

1. Play along.
2. Go through tedious efforts to undo the damage as its done.
3. Find an alternative.
4. Fork mpv.

In case my point was not clear, let me restate it. Personal developer issues (Read: politics) are not my concern. I use mpv because it meets my needs. If it breaks again in the future, I will again find a patch to fix it (which is not tedious, IMO) and move on.

Yes, that's my sentiment too! I'm afraid my programming days ended with 8-bit 6502s, so writing a patch for mpv is somewhat beyond me! If you manage it, remember to let us know! ;)

In the meantime, someone in the other thread has pointed out QMPlay2, which looks like a viable alternative....

--
Pete

Hey, Pete. I have seen some of your other posts, and can truly empathize with some of the issues you've had with your system, as I have also struggled with my system having its own set of issues.

The patch I was referring to originally is referenced in my original post. My point of view is that if the program works for my needs, then that's all that matters. And there's always someone who has come across the same issues as I in any given program, and there's almost always a workaround or patch. Google is your friend. ;)

Hope this helps.

Re-reading my post, I realise it wasn't as clear as I had intended! I meant if you write a patch in future, please let us know! Sorry for any confusion!

There has been a huge flurry of upgrades in -current recently (new release imminent?), and I would expect this to cause the odd breakage. Usually I manage to work around it, but this time I came unstuck! I still haven't figured out why the MPlayer build script threw a tantrum, but I don't need to any longer, and no doubt it will be picked up by the team in due course. I really don't want to use the vdpau workaround unless I absolutely have to. Its not that I have anything against vdpau - both my other machines use ati gfx and the kernel drivers, and vdpau works fine on them. But using a translation layer from vdpau to vaapi seems like a kludge - however well intended - that I would rather avoid!

Thanks for your help, and to all the other contributors to this, and the other, thread

--
Pete

You're very welcome. It's my :twocents: contribution. I certainly enjoy using Slackware, and do my best to help others in some small way.

Happy Slacking!

If they'd decided to continue with their FFMPEG fork, then my recommendation would have been to have one MPV SlackBuild that does the following:

1. installs ffmpeg (theirs) into $PKG/usr/lib$LIBDIRSUFFIX/mpv
2. builds mpv against it, using "-Wl,-rpath=/usr/lib/lib$LIBDIRSUFFIX/mpv -L$PKG/usr/lib$LIBDIRSUFFIX/mpv"

This is a fairly standard way of building dependencies into a package.

I did suggest this on the slackbuilds-users mailing list.

That is a really ugly hack as far as package distribution goes, but to be fair there are no good solutions here.

I've actually seen it documented elsewhere, but I'm not going to look for it right now.

(EDIT: example 1, example 2).

I wasn't aware of the helper build script mpv project provides:

https://github.com/mpv-player/mpv-build

It's as easy as this:

It fetches latest ffmpeg and libass from git HEAD and links them statically. There are also options to use release versions instead, see README.

Works flawlessly, just copy the resulting mpv executable where you want.

I have a SlackBuild that uses that to build a proper Slackware package. It currently builds 0.28.

https://github.com/duganchen/my_slac...mpv.SlackBuild

I'd mentioned it in another thread about this issue, but I can't find that thread right now.

I dont have any problem with mpv + ffmeg on the contrary, only hapiness.
I can play any kind of videos (4k, hvec, ts, hdr, 10bits, etc) with hardware off course.

Please do not judge me, i'm just an amateur.
My personal builds
first https://github.com/ericfernandesferreira/audio
second https://github.com/ericfernandesferreira/video

Just a heads up for anyone still using mpv. Nasty remote code execution: CVE-2018-6360

After a lot of prompting and resistance it looks like they've tagged a 0.27.1 and 0.28.1, but it's clear from the comments here that the mpv dev's don't consider security issues their responsibility to patch in anything other than git master, which kind of makes a mockery of tagging releases in the first place.

Anyway, be warned.

Just use my SlackBuild to build 0.28.1.

for good luck with version 0.28.2 you need to apply only one fourth patch

(mpv-do-not-fail-with-minor-ffmpeg-updates.patch)

Again: just use my SlackBuild to build 0.28.2. It will build all future versions without needing to be updated.

Doesn't your mpv build pull down and embed it's own copy of ffmpeg? The reason I switched from mplayer to mpv in the first place was that it used the system installed ffmpeg library rather than it's own embedded version.

Now, somewhat ironically, it's easier to get mplayer to use the system library than it is mpv.

Not only its own copy of ffmpeg, but a rage fork which does not have nearly as many developers looking at it. At least MPlayer uses the upstream ffmpeg source when you choose to build it with a static ffmpeg.

Additionally mpv recently broke the ffmpeg API compatibility again...

Yes. I'm fine with this both technically (I have a fast enough build system) and politically.