Homebrew-core: Mpv and ffmpeg

[AirPort]

There's a bit of a mess about the topic's title that's happening now, so I'm opening this thread to give a heads up to homebrew's devs in order to decide the best course of action.
Long story short, mpv's main dev got fed up by the latest ffmpeg's API breakage, so now mpv requires its own fork to build, which basically is regular ffmpeg-git with a few patches on top of it.
I can see three solutions:

1. Add a ffmpeg-mpv keg-only formula, used obviously only by mpv. This would probably be the best choice (it would give the user the full flexibility it has now with base ffmpeg), the cons being that it would be basically a copy of the regular ffmpeg's formula, so additions to one of them should then be mirrored in the other one, and the fact that's not at all sure that ffmpeg-mpv will ever have stable releases and, correct me if I'm wrong, having HEAD-only formulas clashes with homebrew's guidelines.
2. Build ffmpeg-mpv and statically link it when mpv is installed. mpv-build official scripts basically do this, but in this case that would actually mean having no user control on ffmpeg's options. Also, it would mean that everytime HEAD mpv is installed from source it would need to also build ffmpeg, which is tedious and taxing in terms of time and resources.
3. Patch out the build check and make mpv compile against official ffmpeg. This is possible, but I wouldn't really suggest it: building against vanilla ffmpeg is somewhat possibile but unsupported, so it could easily break at any time.

That's the situation in brief. Right now it's a problem only for people that use HEAD mpv (like me), but if this mess is left unsolved it will effectively be impossibile to upgrade to the next stable version of mpv when the time comes.

[ilovezfs]

CC @zmwangx for thoughts.

[zmwangx]

Huh, I haven't been following mpv development, but IIRC wm4 (I suppose you're talking about him) used to be a regular contributor to FFmpeg, so couldn't he upstream his patches?

Regarding the proposed solutions, 1 and 2 are too ugly (I'd rather switch to Libav than do either of these), and 3 sounds too risky, or they wouldn't have required the fork in the first place. If the situation doesn't get resolved before the next major release, I would seriously consider Libav as solution 4 (I don't see a mpv-player/Libav-mpv, so I'm assuming the main line Libav is working at the moment).

I'll catch up on the discussions later.

[AirPort]

Mainline libav is supported, but it also has its share of issue, most notably its subtitles' support seems to be severely lacking. Mpv itself suggests ffmepg in its faqs.

[zmwangx]

I'm aware of that, but I prefer a lacking build over a compilation error.

[ilovezfs]

Best solution would be to get mpv and ffpmeg to make peace.

[zmwangx]

On further thought, they probably won't cut a release in a state like this. The only reason mpv cut releases is for packaging (I think wm4 said that once), and this would be a packaging nightmare for almost everyone.

[AirPort]

Having followed the situation for a bit, it seems that mpv decided to go the way of eg. Chromium and Firefox, having a custom, controlled branch for the long run, so I fear this is not a temporary knee-jerk reaction that will solve itself with a bit of time.

[zmwangx]

That's unfortunate. I'll catch up on the discussions.

[Argon-]

Regarding the proposed solutions, 1 and 2 are too ugly

That's not much of an argument though. Especially users don't care.

and 3 sounds too risky

It definitely is. Right now, mpv doesn't even compile with ffmpeg HEAD because ffmpeg-mpv contains a new API (merged from libav) that ffmpeg refuses to merge. We must assume the fork will diverge to a point where it will not be feasible for a brew maintainer to follow all patches.

I would seriously consider Libav as solution 4

This would seriously impact user experience though. libav not only lacks the mentioned subtitles, it lacks various other features as well. I've also heard multiple reports of worse performance. There really is a reason why these days pretty much everyone prefers ffmpeg over libav. There's also the issue of reported security problems not being addressed in libav for a long time while ffmpeg fixes these in a timely manner. You can read more about such things here: https://wiki.debian.org/Debate/libav-provider/ffmpeg#Why_Debian_should_switch_to_FFmpeg and here: https://lwn.net/Articles/650816/
Bottom line: using libav is essentially a downgrade in features and security.
A user doesn't see (nor care) if the solution that brought him mpv was ugly, only the end result counts.

Personally, I dislike 1 for the duplication. I would absolutely prefer 2: do a static build of ffmpeg-mpv "on the fly" (yes, for every build) like mpv-build does. It's cleaner and a process aligned with mpv-build which is the only "official" way/procedure of building mpv anyway. The only problem I see here is how to specify options for ffmpeg without stuffing all ffmpeg options into the mpv formula. Maybe take the ones from a current ffmpeg install?

[zmwangx]

That's not much of an argument though. Especially users don't care.

1 and 2 require user input, so users definitely do care.

[zmwangx]

Maybe take the ones from a current ffmpeg install?

No, that's definitely not right.

[ilovezfs]

How much customization to ffmpeg is actually reasonable for ffmpeg insofar as it's used by mpv? It seems like mpv wants to have its cake and eat it too if we're supposed to both vendor ffmpeg and make the vendored ffmpeg _independently_ user configurable at build time.

[Argon-]

1 and 2 require user input, so users definitely do care.

How so? A novice user that used to brew install mpv will be able to continue doing so. Just when this formula switches to libav, he will end up with less features and more security issues. That's what I tried to illustrate.

How much customization to ffmpeg is actually reasonable for ffmpeg insofar as it's used by mpv?

The options exposed by the ffmpeg formula are all about features. This directly translates to mpv: when ffmpeg is build without support for format x then mpv can't use format x.
Personally, I'm maxing out my build because why not. It's not like there's "disk space wasted".

[ilovezfs]

mpv-build official scripts basically do this, but in this case that would actually mean having no user control on ffmpeg's options.

It sounds like that's what mpv actually is signing up for though. No configuration of ffmpeg independently of mpv configuration.

[Argon-]

Btw I would advise not to take any actions already because I don't think the current situation is final. Some mpv developers seem not very happy with this decision.

Other than that, this means a --HEAD build with the current formula is broken (as no release nor HEAD of ffmpeg builds with mpv). New issues should be redirected here I guess.

[AirPort]

Here's a recent rationale for the whole move btw.

This would seriously impact user experience though. libav not only lacks the mentioned subtitles, it lacks various other features as well.

Another reason I would add is a/v filters, since Libav's libavfilter is really lacking compared to ffmpeg's one, and that I think is a big user-facing change.

[ilovezfs]

So far the libav option sounds like the best option for brew. I would urge upstream mpv to just make the necessary ffmpeg API changes like everyone else and not go down this road, which is basically a nightmare from a packaging perspective.

[zmwangx]

A novice user that used to brew install mpv will be able to continue doing so. Just when this formula switches to libav, he will end up with less features and more security issues.

I don't think a user who installs mpv and ffmpeg without any options at all will lose features. Maybe I'm wrong, but IMO the issues we're discussing here are mostly about more advanced configurations. I can't comment on security; you're probably right there.

Btw I just looked at mpv-build and it seems ugly as hell to me. It's okay for internal build server use (you can do anything in your private space), but asking packagers to duplicate that kind of setup feels rather insane.

It sounds like that's what mpv actually is signing up for though. No configuration of ffmpeg independently of mpv configuration.

mpv-build does support FFmpeg build options. Through

echo --enable-libx264 >> ffmpeg_options

You get the idea.

Other than that, this means a --HEAD build with the current formula is broken (as no release nor HEAD or current ffmpeg builds with mpv).

I don't think it's a good idea to fix --HEAD for now.

---

Disclosure: I've never been a fan of Libav. I've been actively against Libav, since the fork.

[zmwangx]

Btw I'm not saying switching to Libav (hypothetically) wouldn't require user input. It would, but it's a more reasonable "Homebrew's mpv now depends on Libav, so you need to configure Libav to your liking", rather than some "we now have a special FFmpeg just for mpv" nonsense.

[Argon-]

I don't think it's a good idea to fix --HEAD for now.

I concur, that's why I said "I would advise not to take any actions already" ;)

mpv-build does support FFmpeg build options

It's probably a UI/UX nightmare to expose this to users though.

So far the libav option sounds like the best option for brew.

How did you arrive from "player with less features and more security issues" to "best option"?

It would, but it's a more reasonable "Homebrew's mpv now depends on Libav, so you need to configure Libav to your liking", rather than some "we now have a special FFmpeg just for mpv" nonsense.

But none of this happens? Or do I get you wrong?
When a user does brew install mpv the formula will pull in libav and compile it (when not already there) as a build dependency (first case) or clone ffmpeg-mpv and build/link it statically on the fly (second case). The user is not required to take any action. The install won't fail and print "please install libav" or "please check out this strange ffmpeg-fork yourself". It's all still brew install mpv for him. What the formula does internally doesn't matter much to a user interested in the build products.

[Argon-]

https://github.com/mpv-player/mpv/commit/a7a1ae0b3d60cdaab0774fcb08de33fa6b12848b things are definitely not final...

[zmwangx]

mpv-build does support FFmpeg build options

It's probably a UI/UX nightmare to expose this to users though.

Yes, that's why solution 2 doesn't work.

But none of this happens? Or do I get you wrong?
When a user does brew install mpv the formula will pull in libav and compile it (when not already there) as a build dependency (first case) or clone ffmpeg-mpv and build/link it statically on the fly (second case). The user is not required to take any action.

Again, I'm not talking about a vanilla build of mpv a combo of vanilla FFmpeg and vanilla mpv. That case will be fine whatever we do, except if we use Libav there might be more vulnerabilities (most people don't care and don't need to care anyway). But if you installed FFmpeg with options and rely on those in your mpv build, action is required; otherwise you end up with a crippled build.

[ilovezfs]

So far the libav option sounds like the best option for brew.

Because it's switching a dependency instead of adding a new formula or vendoring something complicated.

[zmwangx]

vendoring something complicated.

It's worse than that. How do you expose the FFmpeg options?

[ilovezfs]

It's worse than that. How do you expose the FFmpeg options?

You don't unless they're exposed separately as mpv options.

Honestly the wording of https://github.com/mpv-player/mpv/commit/a7a1ae0b3d60cdaab0774fcb08de33fa6b12848b makes me want to remove mpv from Homebrew.

[zmwangx]

You don't unless they're exposed separately as mpv options.

Yeah, and the problem is you don't want to stuff a bunch of FFmpeg options into the mpv formula. Now that I think about it, it's not as bad as I initially thought, since a lot of FFmpeg options are encoder options and don't affect decoding (I can't think of why you need x264, for instance), but this vendoring route is still a nightmare nevertheless.

Update. Just realized mpv could be used for encoding too, so x264 comes into play when you --ovc=libx264... But not sure why anyone would do that instead of using FFmpeg directly.

[ilovezfs]

Yeah a cleaner option would probably be a separate mpv-ffmpeg formula, hopefully with a slimmer option profile than the stock ffmpeg formula.

[ilovezfs]

But to be clear: if it becomes a choice between a separate mpv-ffmpeg and using libav, it's probably going to need to be libav because maintaining yet another ffmpeg formula isn't exactly within our budgeted resources. Ahem.

[Argon-]

Honestly the wording of mpv-player/mpv@a7a1ae0 makes me want to remove mpv from Homebrew.

Ever read the ffmpeg mailing list, especially patch reviews? Makes you want to remove ffmpeg.
This problem here basically originates from a conflict and that's why the words are a bit more harsh than they should. I can understand wm4 here (although I don't like this choice). As it stands, the decisions and delays from ffmpeg developers made his work a lot more painful the past few weeks. And they also actively broke mpv for like a week.
Also let's not forget that other projects like chromium or firefox also have a fixed ffmpeg in-tree. So this is not something unheard of. It's just that brew doesn't package these (afaik) while other package managers do.

But as I said before: let's wait before doing anything right now and just accept that a --HEAD build is broken for now. This situation might change rapidly the next days/weeks...

[zmwangx]

But to be clear: if it becomes a choice between a separate mpv-ffmpeg and using libav, it's probably going to be need to be libav because maintaining yet another ffmpeg formula isn't exactly within our budgeted resources. Ahem.

Unless there's a volunteer who pledge long term support, I guess, e.g. me? I'll be happy to do that if someone demonstrates a Libav-based build is considerably worse than a FFmpeg-based build, or when I take the time to find that out myself (haven't used Libav much).

And let's not forget that other projects like chromium or firefox also have a fixed ffmpeg in-tree.

I wouldn't complain if FFmpeg is moved into the mpv tree, and the mpv build script uses that FFmpeg out of box (possibly with a switch).

[ilovezfs]

Did anyone else notice the option name is --ffmpeg-garbage? I think this has gotten out of control.

[Argon-]

I wouldn't complain if FFmpeg is moved into the mpv tree, and the mpv build script uses that FFmpeg out of box (possibly with a switch).

That's good to know and I've heard similar from other package managers. Let's see if there will be more development into this direction

Did anyone else notice the option name is --ffmpeg-garbage? I think this has gotten out of control.

Out of control because of "garbage"? Sorry, but you must be new to multimedia open source software.
They will calm down, eventually. It's not like any of use can (or should) do anything about this anyway.

[zmwangx]

Sorry, but you must be new to multimedia open source software.

This is a hundred times calmer than the hostile forking in 2011, for sure.

[ilovezfs]

That's good to know and I've heard similar from other package managers. Let's see if there will be more development into this direction

This will just mean basically zero or close to zero options for ffmpeg in the Homebrew mpv formula.

[AirPort]

Did anyone else notice the option name is --ffmpeg-garbage? I think this has gotten out of control.

For what it's worth the code is full of x_garbage functions. I mean, until recently a special pixel format used only by an ancient apple hwaccel API (IIRC) was called "ashit". I guess I've been desensitized, but this is really nothing compared to other things I've seen in software developement, especially in multimedia.

[zmwangx]

This will just mean basically zero or close to zero options for ffmpeg in the Homebrew mpv formula.

I think it's okay to have close to zero FFmpeg options. People who want to do funny things like --ovc=libx265 should just build mpv themselves.

[ilovezfs]

Yeah I only have a problem if their moving it in-tree means a proliferation of options in the mpv formula, which already has 17.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[spaghetti-]

I got it to compile by statically compiling ffmpeg-mpv and changing the pkg-config path in superenv to reflect that.

diff --git a/Formula/mpv.rb b/Formula/mpv.rb
index c557288ae..3db49e6ca 100644
--- a/Formula/mpv.rb
+++ b/Formula/mpv.rb
@@ -78,6 +78,8 @@ class Mpv < Formula
     args << "--enable-dvdread" if build.with? "libdvdread"
     args << "--enable-pulse" if build.with? "pulseaudio"

+    ENV.prepend_path "PKG_CONFIG_PATH", "/Users/alex/repos/ffmpeg-mpv/build/lib/pkgconfig"
+
     system "./bootstrap.py"
     system "python3", "waf", "configure", *args
     system "python3", "waf", "install"

It's not a permanent solution or automated by any means, but if anyone wants a quick fix to get the bundle/other benefits homebrew provides then this'll work. Details.

[zmwangx]

@spaghetti- Just so you know, your blog post's title contains a typo: ffmpeg-mpv, not ffmpeg-mpeg.

[spaghetti-]

@zmagg fixed, thanks.

[ilovezfs]

Happy MrM :turkey: day @zmwangx

[zmwangx]

@ilovezfs LoL thanks you too Ⓜ️

[JCount]

🍴@ilovezfs @zmwangx

[FrostedMint]

Instead of having a checkout of ffmpeg-mpv in your home folder, you can also just create an ffmpeg-mpv formula, with the following changes on the base ffmpeg formula:

1c1
< class Ffmpeg < Formula
---
> class FfmpegMpv < Formula
4,12c4,6
<   url "https://ffmpeg.org/releases/ffmpeg-3.4.tar.bz2"
<   sha256 "5d8911fe6017d00c98a359d7c8e7818e48f2c0cc2c9086a986ea8cb4d478c85e"
<   head "https://github.com/FFmpeg/FFmpeg.git"
< 
<   bottle do
<     sha256 "1807e00fdfc308feaa78924e0b6991b26e6f37ea379ac82b78dca038a0f67a7b" => :high_sierra
<     sha256 "fb6b9798000d2a108b514763a08b5fe2fe9176bcb7e4676d0d8948d0e3d663b6" => :sierra
<     sha256 "82954cce27930c0416716931fda0c54bc21464394cf1c4cfe54232c670f040e0" => :el_capitan
<   end
---
>   head "https://github.com/mpv-player/ffmpeg-mpv.git"
> 
>   keg_only "mpv depends on a forked ffmpeg"

And then, update the mpv formula like so:

diff --git a/Formula/mpv.rb b/Formula/mpv.rb
index c557288ae..885878d53 100644
--- a/Formula/mpv.rb
+++ b/Formula/mpv.rb
@@ -18,7 +18,7 @@ class Mpv < Formula
   depends_on :python3 => :build

   depends_on "libass"
-  depends_on "ffmpeg"
+  depends_on "ffmpeg-mpv"

   depends_on "jpeg" => :recommended
   depends_on "little-cms2" => :recommended

You could then migrate over with something like:

$ brew rm mpv
$ brew install --HEAD ffmpeg-mpv $FFMPEG_OPTIONS
$ brew install --HEAD mpv $MPV_OPTIONS

If folks are interested, I can try to maintain a separate tap with ffmpeg-mpv and a modified mpv formula.

[FrostedMint]

For those interested, a tap with ffmpeg-mpv available here: FrostedMint/homebrew-mpv. I’ll try to make sure it’s up-to-date on a weekly basis, but feel free to submit a PR if you want changes pulled in sooner.

[Akemi]

ffmpeg-mpv has been removed from mpv again. so this issue can probably be closed.

[zmwangx]

Lovely, thanks.

[ilovezfs]

Reason has prevailed!

[ilovezfs]

@AirPort thanks for bringing this situation to our attention :)

[ilovezfs]

mpv released 0.28.0, which depends on ffmpeg > 3.4 :see_no_evil:
https://github.com/mpv-player/mpv/releases/tag/v0.28.0
https://github.com/Homebrew/homebrew-core/pull/22112

So I'm closing that PR until ffmpeg releases 3.5.

[retokromer]

Should be quite soon.