mpv AppImage for most distributions

[probonopd]

The download page says

Distributions usually package outdated, unmaintained, and unsupported versions of mpv. This is especially true for popular distros like Debian and Ubuntu. You are recommended to use mpv-build or 3rd party packages instead.

Providing an AppImage would have, among others, these advantages:

• Users would not have to rely on third-party packages or repositories, but could get the most recent version for Linux from the official download page (like for Windows and macOS)
• Works for most Linux distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
• One app = one file = super simple for users: just download one AppImage file, make it executable, and run
• No unpacking or installation necessary
• No root needed
• No system libraries changed
• Just one format for all major distributions
• Works out of the box, no installation of runtimes needed
• Optional(!) desktop integration with appimaged
• Binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can GPG2-sign your AppImages (inside the file)

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

Here is a __sample mpv AppImage for testing__:
https://bintray.com/probono/AppImages/mpv_Media_Player/_latestVersion#files

This is expected to run on most 2014-ish and later distributions. It has been generated from the existing trusty ppa. But seeing that this project is already using Travis CI to do continuous builds, we could bundle those up as AppImages as well.

Do you think this would be useful?
I'd be happy to help producing an official mpv AppImage.

[mia-0]

Or just use Windows.

[ghost]

I'm rather suspicious against this AppImage thing too. Maybe if it actually proves useful. Until then I wouldn't want to experiment on mpv users with it (the issue being mostly that we would have to provide support, while we'd like to spend out energy on other things).

[probonopd]

@lachs0r while I respect your decision, I'd be curious about the rationale.

@wm4 do you really think that users feel warm and fuzzy about an application if even the authors don't want to support it? You are already now doing builds, why not provide them for download? Besides, it could also just be used for testing continuous builds.

[mc4man]

If you were going to provide a sample it may make sense to make sure it actually can run, certainly doesn't in 14.04
Maybe? because it wants outdated samba-libs, shows this times about 40
/tmp/.mount_FtWTnc/usr/bin/mpv: /usr/lib/x86_64-linux-gnu/samba/libgse.so.0: version `SAMBA_4.1.6_UBUNTU' not found (required by /tmp/.mount_FtWTnc/usr/lib/x86_64-linux-gnu/libsmbclient.so.0)

when-
strings /usr/lib/x86_64-linux-gnu/samba/libgse.so.0 |grep SAMBA
SAMBA_4.3.11_UBUNTU

[probonopd]

@mc4man you are right, there was a bug that prevented the AppImage from loading the bundled Samba libraries correctly from inside the AppImage. Removed it for now. Depending on interest in this, I may consider to provide a fixed one, but right now I get the notion that it is not appreciated.

[CounterPillow]

Krita has successfully been using AppImage for getting fresh builds and beta/release candidate builds out to people in an easy way, with a custom patched Qt for some tablet-specific issue. In that sense, it is very useful if you want people to test something in a known configuration. mpv's "release" methodology of pretty much just tagging some git commit as a new release is probably not going to profit much from the ability to ship release candidates in an unobtrusive way.

As the sample AppImage proved though, there's one major drawback: dependencies on libraries are quite leaky (which in some cases is desired if you don't want to ship the entire userland). I'm not sure how this would interact with things such as a recent mpv version running with an ancient mesa and kernel GPU driver version of the super-stable enterprise-grade distribution.

I think a lot of the benefits are already covered by the easy to use mpv-build, though admittedly it's not as user-friendly as a pre-built AppImage since users have to actually install some development headers on some distributions for the build to work and have all the desired features.

[probonopd]

@CounterPillow thanks for your thoughtful remarks. You rightfully point out that with Linux you can never be sure what you can take for granted from the operating system. My experience has been that with some experimentation, one usually can find a set of dependencies to be bundled that allows the application to run on the vast majority of distributions released in the last 3-5 years or so.

[ccompletion]

@lachs0r
To complete your sentiment: or just use mplayer, mplayer2, ffmpeg, libav, ...

[CounterPillow]

wow you sure showed him

[ccompletion]

@CounterPillow
Just in case this is not clear: I was not trolling. The sentiment really can go both way. Maybe I also wanted to point out that it's much easier to switch mpv than switch a whole OS. I was fair enough to not mention VLC, right? Ooops...

[CounterPillow]

wow you sure showed him

[ghost]

do you really think that users feel warm and fuzzy about an application if even the authors don't want to support it?

We don't really develop software so that we can spend our time on user support. Do you think we're some company? But apart from that, we do somewhat try to help users or fix bugs for the feature set we claim to support. But if we added AppImage to that, it would mean we'd have to deal with AppImage problems as well, and not only do we not want to do that, we don't even have the knowledge to do that.

You are already now doing builds, why not provide them for download? Besides, it could also just be used for testing continuous builds.

Well, we do provide mostly-official windows builds. But fortunately windows has barely any packaging problems, and any problems that could happen would happen with self-built binaries as well. Also, making a Linux build is much much cheaper than distributing a Linux build, thus we encourage users to build it themselves.

@ccompletion

If you want to stop using mpv just because we don't provide AppImage you got some... severe problem, and probably don't appreciate mpv's strengths all that much.

Threatening devs to stop using their software because they don't do something you want generally doesn't work, by the way.

[ghost]

Also to be clear: if it should turn out that AppImage packages are much better than distro packages (for most distros), then it'd definitely be worth to provide an official one.

[ccompletion]

@wm4
I'm sorry you perceived it as threatening. This was not my intent.

And you made a bad guess. I'm not using mpv. I am looking for what's available as AppImage and also ended up here, looking for mpv AppImage. What I posted was a honest feeling I got as a potential new user.

Take it for what you will.

[CounterPillow]

@ccompletion

What I posted was a honest feeling I got as a potential new user. Take it for what you will.

Not sure why you think your opinion as someone who isn't even using mpv matters to people on this issue tracker. That makes you not even a luser, but something entirely new below luser. We're reaching levels of entitlement that I didn't even consider to be possible. I think based on your behaviour here, the mpv project is probably better off not having you as a user.

[mia-0]

What I was trying to say with my post was that a Windows executable actually works. In fact, running mpv.exe with wine (provided you pick the right GPU context) works more reliably than AppImage, and across many different distributions (non-Linux, too). You don’t get working hardware decoding with either one.

Of course that’s sort of cheating because all the dependencies are statically linked. But the big difference is that the critical parts that make cross-distro portability so hard are all part of Wine’s abstraction layer.

That said, however, I’m looking into hosting repositories for the most common Linux distributions, since I have already migrated my Windows builds to a custom Open Build Service instance. The one at build.opensuse.org won’t let me redistribute non-crippled FFmpeg, and I can’t really burden Packman with this, so we’ll just run our own instance.

There’s at least one potential showstopper blocking the upcoming release anyway, so I will likely have mpv packaged for a few distros (including automatic git builds) by the time that’s ready.

[Hasshu]

Not sure why you think your opinion as someone who isn't even using mpv matters to people on this issue tracker. That makes you not even a luser, but something entirely new below luser. We're reaching levels of entitlement that I didn't even consider to be possible. I think based on your behaviour here, the mpv project is probably better off not having you as a user.

@CounterPillow wow you sure showed him

Kidding aside...

@lachs0r That's great news, thanks for the update.

[flux242]

@probonopd would love to have mpv and its shitload of dependent packages in an AppImage. Could you provide a working yml for the latest version?

[probonopd]

@probonopd would love to have mpv and its shitload of dependent packages in an AppImage. Could you provide a working yml for the latest version?

The proper way is to build on Travis CI for trusty, and then to use linuxdeployqt.

I might have a look in case @pigoz or @haasn are interested, but I won't spend my time if there is no clear commitment from the project.

[pigoz]

It's probably not a bad idea to provide an AppImage that at least includes a blessed ffmpeg and libass version, as well as other dependencies (but which ones?).

[CounterPillow]

The following additional ones come to mind:

• luajit
• mujs
• shaderc
• dav1d

As far as I know we'd also need to either bundle glibc or build against an ancient version of it.

But how does updating software in AppImage-land work? Is there some update system? Because if it just makes people responsible for updating it themselves I can see that become a problem.

Also, how does flatpak look these days?

[flux242]

@probonopd actually I have even tried to go back to use vlc but the vlc in an AppImage does not support hardware acceleration because of the older libva api version (here's the output https://pastebin.com/EDmGUu6D). I'm adding this because if something should move here then this problem should be considered too. mpv in an AppImage without hardware acceleration is kind of useless too (for me at least)

[mc4man]

There has been no appimage of mpv of the 1/2 dozen or so produced that works properly across distros & distro releases. As far as hwdec there is no current appimage video player that supports it or supports reliably .
I would think you'd need to show one time that it's possible to produce a decently enabled mpv that works across various distros, ect.

As far as flatpack there is no mpv, only GnomeMpv which works ok. As far as hwdec it supports vaapi but not vdpau or nvdec. Same for the flatpack vlc..

In terms of best capabilities the snap vlc is as good or better than the packaged versions, full support for hwdec, (vdpau just fixed), vulkan, ect. As far as a snap mpv all previous attempts are flawed to one extent or another.
How well snaps work across distros is unknown to me..

[probonopd]

Think of an AppImage as a self-mounting filesystem image that runs whatever you, the application developer, puts inside it. Like with a zip, tar.gz, or iso file.
There are no restrictions on what you can or cannot put inside, and there is also no mandatory sandboxing (unlike Flatpak and Snappy). So it's purely a matter of figuring out what needs to be bundled to make hardware acceleration work.

Only restriction: Use ingredients compiled on a system no newer than the oldest target system (distribution) your users might be using, for compatibility reasons. To be listed on AppImageHub, this currently means Ubuntu 14.04, the oldest still-supported Ubuntu release.

If the video drivers are breaking binary compatibility (which means that applications built on e.g., Ubuntu 14.04 will no longer run properly on a newer one, e.g., 18.04) then I consider it a bug in those drivers that needs to be fixed. Alternatively it could be worked around by building two AppImages, one for old and one for new systems. But I don't know whether this is the case here.

[haasn]

I think @lachs0r mentioned that the taisei developers gave up on trying to get AppImage + cross-platform 3D graphics to work in a sane way?

At some level, we would have to package (and keep up to date) all of mesa, vulkan, etc.; depending only on the kernel syscall API and nothing else. Not sure if that's a sane idea. Plus, how do we gain access to video hardware in a cross-platform way? (Permissions etc.)

Edit: Actually, we don't need to be that extreme, since we can get access to the OpenGL driver via GLX/EGL and load the function pointers from that. We would need to include the vulkan loader, however.

[flux242]

if video driver compatibility issues prevent creating AppImages for older distributions like ubu 14.04, ubu 16.04 then it should be simply skipped (or shipped without hwdec like vlc devs do). These distros are still used on the server side mainly and supporting only 18.04 LTS would cover 99% of all ubu desktop users. 18.04 is already 9 months old btw.

[probonopd]

supporting only 18.04 LTS would cover 99% of all ubu desktop users

Where do you have your data from? I still know someone who uses ubuntu gutsy. Not everyone updates the OS every couple of years.

[flux242]

I still know someone who uses ubuntu gutsy
that's your 1%
Not everyone updates the OS every couple of years.
you've missed the point. The point is - there's a reason why they don't want no appimage.