Make anylinux appimage be able to work with yt-dlp

[Samueru-sama]

          > > > Check my `anylinux` mpv appimage: https://github.com/Samueru-sama/mpv-AppImage/releases/tag/continuous

It uses the deploy everything mode of go-appimage, and MPV is build using the mpv-build scripts which statically link a lot of stuff.
However it is not perfect, for some reason opening videos with yt-dlp doesn't work, but besides that it has no problem playing local videos.
And it seems the issue with yt-dlp is related to glibc being bundled, so it is likely that running the build scripts on a musl enviroment might fix that issue, however it is also likely that the script might not work on alpine lol
Another appimage that uses the deploy everything mode is the flameshot appimage.

You could refactor a bit to use this: https://github.com/jirutka/setup-alpine

I've tested making the appimage in an alpine container, after a lot of pain I was able to get it to launch.

However the issue of mpv not playing youtube videos is still there, this is the error that I get:

./mpv_Media_Player-v0.38.0-743-gad7976c33e-x86_64.AppImage "https://www.youtube.com/watch?v=dQw4w9WgXcQ"                                                                                                                                                                      4907ms 
No protocol handler found to open URL https://www.youtube.com/watch?v=dQw4w9WgXcQ
The protocol is either unsupported, or was disabled at compile-time.
No protocol handler found to open URL https://rr3---sn-hp57yn7r.googlevideo.com/videoplayback?expire=1725438108&ei=PMTXZpPKA4-my_sPge_LuAQ&ip=38.25.175.104&id=o-AIAyJlPZc-Ur8AiUlyyhe8dzIjV2azYmM7urQAvKo__U&itag=251&source=youtube&requiressl=yes&xpc=EgVo2aDSNQ%3D%3D&mh=7c&mm=31%2C29&mn=sn-hp57yn7r%2Csn-hp57knds&ms=au%2Crdu&mv=m&mvi=3&pl=19&initcwndbps=722500&vprv=1&svpuc=1&mime=audio%2Fwebm&rqh=1&gir=yes&clen=3437753&dur=212.061&lmt=1717047822556748&mt=1725416221&fvip=5&keepalive=yes&c=IOS&txp=4532434&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cxpc%2Cvprv%2Csvpuc%2Cmime%2Crqh%2Cgir%2Cclen%2Cdur%2Clmt&sig=AJfQdSswQwIgBR5_cmGqM5IA5M86a-9YS7uXNJ8Sf55bHZl7J-1GZWACHxUcqulIoOmKwUZdO5KoIs3sjmhSiImNYt4KTxxgeEA%3D&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=ABPmVW0wRgIhAPS3Crcf4LgLNnB1z5OOW3apfmmPNzdNU5DJvnIdXj0_AiEA6GEarvWkWLuPGLV1ZCfVcFi_kPf9S_mlFvwt2RJYZZ8%3D
The protocol is either unsupported, or was disabled at compile-time.
EDL: Could not open source file 'https://rr3---sn-hp57yn7r.googlevideo.com/videoplayback?expire=1725438108&ei=PMTXZpPKA4-my_sPge_LuAQ&ip=38.25.175.104&id=o-AIAyJlPZc-Ur8AiUlyyhe8dzIjV2azYmM7urQAvKo__U&itag=251&source=youtube&requiressl=yes&xpc=EgVo2aDSNQ%3D%3D&mh=7c&mm=31%2C29&mn=sn-hp57yn7r%2Csn-hp57knds&ms=au%2Crdu&mv=m&mvi=3&pl=19&initcwndbps=722500&vprv=1&svpuc=1&mime=audio%2Fwebm&rqh=1&gir=yes&clen=3437753&dur=212.061&lmt=1717047822556748&mt=1725416221&fvip=5&keepalive=yes&c=IOS&txp=4532434&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cxpc%2Cvprv%2Csvpuc%2Cmime%2Crqh%2Cgir%2Cclen%2Cdur%2Clmt&sig=AJfQdSswQwIgBR5_cmGqM5IA5M86a-9YS7uXNJ8Sf55bHZl7J-1GZWACHxUcqulIoOmKwUZdO5KoIs3sjmhSiImNYt4KTxxgeEA%3D&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=ABPmVW0wRgIhAPS3Crcf4LgLNnB1z5OOW3apfmmPNzdNU5DJvnIdXj0_AiEA6GEarvWkWLuPGLV1ZCfVcFi_kPf9S_mlFvwt2RJYZZ8%3D'.
No video or audio streams selected.
Exiting... (Errors when loading file)

this only happens when the deploy everything mode is used, which bundles glibc/musl into the appimage, if it doesn't get used this error doesn't happen, however that means that appimage isn't as universal as a static binary.

edit: I think the issue with mpv is that I'm missing a library that is no seen by ldd since mpv uses yt-dlp to open youtube videos.

Have you tried to do the following:

1. Get yt-dlp from pip3 (use --user, to avoid destroying the system)
2. Get pyinstaller
3. Use the -f option to generate a single file yt-dlp binary
4. Add the yt-dlp single-file binary to the appimage (no need to use staticx since the appimage contains both ld.so and libc.so)

Originally posted by @xplshn in Azathothas/Toolpacks#28 (comment)

[Samueru-sama]

Tried using that, it created a yt-dlp binary with a _internal directory, I pasted both to the ./usr/bin of the appimage.

./AppRun "https://www.youtube.com/watch?v=80mGyTh6S_E"                                                                                                                                                                98ms 
No protocol handler found to open URL https://www.youtube.com/watch?v=80mGyTh6S_E
The protocol is either unsupported, or was disabled at compile-time.
No protocol handler found to open URL https://rr4---sn-5pgux3nva0upvon8x-h5gl.googlevideo.com/videoplayback?expire=1725450528&ei=wPTXZpT0AfK4y_sPisSxkAM&ip=38.25.175.104&id=o-AKe5fMx3SdLqKhjwUEN35GFxXEo7HvSLyPvIgT-ME-ij&itag=251&source=youtube&requiressl=yes&xpc=EgVo2aDSNQ%3D%3D&mh=7i&mm=31%2C29&mn=sn-5pgux3nva0upvon8x-h5gl%2Csn-hp57kndk&ms=au%2Crdu&mv=m&mvi=4&pl=19&initcwndbps=1283750&bui=AQmm2exgAnxdSfrOI1XDquyvklcMeOBB-v2VkNEnZmFdwgmVjYpJ2iGN3tnZQjgVX9xEp0hPT5DyOEl4&spc=Mv1m9nYNPQFDbAFtiVmPj083R1wvH7vRi3PdVvwMDY-ML8KGl2L5&vprv=1&svpuc=1&mime=audio%2Fwebm&ns=TbjDxmRaYpAFNpH9LPLT_28Q&rqh=1&gir=yes&clen=13681191&dur=926.861&lmt=1725399597441343&mt=1725428473&fvip=2&keepalive=yes&c=WEB_CREATOR&sefc=1&txp=5532434&n=xpoj8ZCCfrpluA&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cxpc%2Cbui%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Cns%2Crqh%2Cgir%2Cclen%2Cdur%2Clmt&sig=AJfQdSswRQIhALAChokoquxFdVlZSzEy-zZTpRHDUwOCJGPER1SewElZAiBuLF2JxHUa2n96cvJkqa0K_d78cY3EXfBCpx0z4YuNfw%3D%3D&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=ABPmVW0wRQIgSsLo0MF4EEepaggX1tKa6oC5BjbdCyFpnuVsZECum28CIQDAqA-PwnEQUaySMWhChtUf0JfIXVkyXa_MqfsttFqs0g%3D%3D
The protocol is either unsupported, or was disabled at compile-time.
EDL: Could not open source file 'https://rr4---sn-5pgux3nva0upvon8x-h5gl.googlevideo.com/videoplayback?expire=1725450528&ei=wPTXZpT0AfK4y_sPisSxkAM&ip=38.25.175.104&id=o-AKe5fMx3SdLqKhjwUEN35GFxXEo7HvSLyPvIgT-ME-ij&itag=251&source=youtube&requiressl=yes&xpc=EgVo2aDSNQ%3D%3D&mh=7i&mm=31%2C29&mn=sn-5pgux3nva0upvon8x-h5gl%2Csn-hp57kndk&ms=au%2Crdu&mv=m&mvi=4&pl=19&initcwndbps=1283750&bui=AQmm2exgAnxdSfrOI1XDquyvklcMeOBB-v2VkNEnZmFdwgmVjYpJ2iGN3tnZQjgVX9xEp0hPT5DyOEl4&spc=Mv1m9nYNPQFDbAFtiVmPj083R1wvH7vRi3PdVvwMDY-ML8KGl2L5&vprv=1&svpuc=1&mime=audio%2Fwebm&ns=TbjDxmRaYpAFNpH9LPLT_28Q&rqh=1&gir=yes&clen=13681191&dur=926.861&lmt=1725399597441343&mt=1725428473&fvip=2&keepalive=yes&c=WEB_CREATOR&sefc=1&txp=5532434&n=xpoj8ZCCfrpluA&sparams=expire%2Cei%2Cip%2Cid%2Citag%2Csource%2Crequiressl%2Cxpc%2Cbui%2Cspc%2Cvprv%2Csvpuc%2Cmime%2Cns%2Crqh%2Cgir%2Cclen%2Cdur%2Clmt&sig=AJfQdSswRQIhALAChokoquxFdVlZSzEy-zZTpRHDUwOCJGPER1SewElZAiBuLF2JxHUa2n96cvJkqa0K_d78cY3EXfBCpx0z4YuNfw%3D%3D&lsparams=mh%2Cmm%2Cmn%2Cms%2Cmv%2Cmvi%2Cpl%2Cinitcwndbps&lsig=ABPmVW0wRQIgSsLo0MF4EEepaggX1tKa6oC5BjbdCyFpnuVsZECum28CIQDAqA-PwnEQUaySMWhChtUf0JfIXVkyXa_MqfsttFqs0g%3D%3D'.

Same error as before.

Seems like the issue is in the mpv binary that for some reason gets broken when deploy everything is used.

Related: probonopd/go-appimage#298

I noticed that the error has changed, before it used to say [ffmpeg] tcp: Failed to resolve hostname www.youtube.com: System error now it says No protocol handler found to open URL

[Azathothas]

Why not use a mostly-static yt-dlp?
[+] https://bin.ajam.dev/x86_64_Linux/yt-dlp

$ file yt-dlp
yt-dlp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=cc74c4a74145b7afe126ee5e67d528f4a0e6fee2, stripped

Most static binaries on Linux will rely on libc of your system to do DNS resolutions & such, so if you remove even libc (as can happen from non standard static binaries like appimages), you would have to ensure to link against something like c-ares.
I have had similar issues with curl/wget where they fail DNS resolutions, they were fixed after I built them with c-ares as now I could manually hard-code/specify the DNS servers manually.
Though, perhaps this is not related at all and could be a useless rabbit hole.
Regardless, could you point me to the script you are using to compile a mostly-static mpv?
Is it this one https://github.com/mpv-player/mpv-build ?

[Samueru-sama]

Why not use a mostly-static yt-dlp? [+] https://bin.ajam.dev/x86_64_Linux/yt-dlp

$ file yt-dlp
yt-dlp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=cc74c4a74145b7afe126ee5e67d528f4a0e6fee2, stripped

Most static binaries on Linux will rely on libc of your system to do DNS resolutions & such, so if you remove even libc (as can happen from non standard static binaries like appimages), you would have to ensure to link against something like c-ares. I have had similar issues with curl/wget where they fail DNS resolutions, they were fixed after I built them with c-ares as now I could manually hard-code/specify the DNS servers manually. Though, perhaps this is not related at all and could be a useless rabbit hole. Regardless, could you point me to the script you are using to compile a mostly-static mpv? Is it this one https://github.com/mpv-player/mpv-build ?

I didn't know you had a static yt-dlp as well 👀 will test it tomorrow.

And yes I am using the mpv-build scripts.

I also have a refactored appimage script here since the original I wrote is a mess right now (was back when I was using linuxdeploy), the listed dependencies on the script are the name of the alpine packages.

[xplshn]

Why not use a mostly-static yt-dlp? [+] https://bin.ajam.dev/x86_64_Linux/yt-dlp

$ file yt-dlp
yt-dlp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=cc74c4a74145b7afe126ee5e67d528f4a0e6fee2, stripped

Most static binaries on Linux will rely on libc of your system to do DNS resolutions & such, so if you remove even libc (as can happen from non standard static binaries like appimages), you would have to ensure to link against something like c-ares. I have had similar issues with curl/wget where they fail DNS resolutions, they were fixed after I built them with c-ares as now I could manually hard-code/specify the DNS servers manually. Though, perhaps this is not related at all and could be a useless rabbit hole. Regardless, could you point me to the script you are using to compile a mostly-static mpv? Is it this one https://github.com/mpv-player/mpv-build ?

I didn't know either, seems like we indeed have an yt-dlp build in the repos. I'm glad.

[Azathothas]

So after about 4 hrs wrestling with that build script, I gave up.
I don't understand why they do not provide a docker image that anyone can use to build the binary.
I tested on both Ubuntu & Debian with all prerequisites installed. I even built all the libs from scratch by myself and tried directly linking. It was always some linking error. As expected, glibc distros don't play nice.

Eventually, I redid the same experiment on alpine, and guess what, it compiled successfully with as much features enabled as possible (I only had to disable pulseaudio). Unfortunately now the issue was, no matter what I did, the binary always compiled dynamically. I learned years worth of meson in one day just to get it to work, disabling/enabling features one by one.
This too ended up being a rabbit hole, in the end I found out that, if I disabled everything, only static library libmpv would be built and if I try to enable even a single feature, the binary would compile again but dynamically (I double-checked that all the libraries present were indeed static, but mpv would link itself dynamically anyway).

That seems to be the end of my patience.
I don't know what distro/pkg system you use, I would be very interested in a full build.log
if that's not possible, please provide me both the raw mpv binary and the appimage.

[xplshn]

So after about 4 hrs wrestling with that build script, I gave up. I don't understand why they do not provide a docker image that anyone can use to build the binary. I tested on both Ubuntu & Debian with all prerequisites installed. I even built all the libs from scratch by myself and tried directly linking. It was always some linking error. As expected, glibc distros don't play nice.

Eventually, I redid the same experiment on alpine, and guess what, it compiled successfully with as much features enabled as possible (I only had to disable pulseaudio). Unfortunately now the issue was, no matter what I did, the binary always compiled dynamically. I learned years worth of meson in one day just to get it to work, disabling/enabling features one by one. This too ended up being a rabbit hole, in the end I found out that, if I disabled everything, only static library libmpv would be built and if I try to enable even a single feature, the binary would compile again but dynamically (I double-checked that all the libraries present were indeed static, but mpv would link itself dynamically anyway).

That seems to be the end of my patience. I don't know what distro/pkg system you use, I would be very interested in a full build.log if that's not possible, please provide me both the raw mpv binary and the appimage.

If the binary isn't linked to anything but the libc/ld, then you should be happy that you got to that point, because you can know use appimagetool to create a small mpv binary that is indeed static, and the only thing that isn't would be its libc, but it would still be portable. If you're not going to try going at it again, would you mind sharing the steps/options that you had to change or tweak? (alpine)

[xplshn]

If you REALLY want a static mpv binary, OasisLinux (a completely static Linux distro) has them. But Oasis patches mpv and fixes some of its issues.

binary (the rootfs is a git repo, it gets rebuilt every a few months, LTS): https://github.com/oasislinux/root-x86_64/blob/media/bin/mpv
pkg build recipe: https://github.com/oasislinux/oasis/tree/master/pkg/mpv

[Samueru-sama]

So after about 4 hrs wrestling with that build script, I gave up. I don't understand why they do not provide a docker image that anyone can use to build the binary. I tested on both Ubuntu & Debian with all prerequisites installed. I even built all the libs from scratch by myself and tried directly linking. It was always some linking error. As expected, glibc distros don't play nice.

Eventually, I redid the same experiment on alpine, and guess what, it compiled successfully with as much features enabled as possible (I only had to disable pulseaudio). Unfortunately now the issue was, no matter what I did, the binary always compiled dynamically. I learned years worth of meson in one day just to get it to work, disabling/enabling features one by one. This too ended up being a rabbit hole, in the end I found out that, if I disabled everything, only static library libmpv would be built and if I try to enable even a single feature, the binary would compile again but dynamically (I double-checked that all the libraries present were indeed static, but mpv would link itself dynamically anyway).

Sorry but I forgot to mention that on alpine I had to ln -sf /usr/lib/ninja-build/bin/ninja /usr/bin/ninja because otherwise I would have build.ninja not found errors, no idea if this is related to the issue you have.

Also note that mpv build makes a mostly static binary, but it isn't fully static.

That seems to be the end of my patience. I don't know what distro/pkg system you use, I would be very interested in a full build.log if that's not possible, please provide me both the raw mpv binary and the appimage.

The workflow run on ubuntu 20.04:
https://github.com/Samueru-sama/mpv-AppImage/actions/runs/10689627510/job/29632162587

Note that on ubuntu the dependency list is different: https://github.com/Samueru-sama/mpv-AppImage/blob/main/.github/workflows/blank2.yml#L19-L25

And I had to install meson with pip3

You can also get the full raw log by clicking in the gear icon.

And the appimage is already in the releases, it is the one that contains anylinux in the title, by running it with --appimage-extract you also can get access to the mpv binary inside, though it has been run thru patchelf by go-appimage.

Do you want the raw binary from ubutu or alpine?

If you're not going to try going at it again, would you mind sharing the steps/options that you had to change or tweak? (alpine)

In the refactored build script I shared above I have listed the alpine dependencies, all you have to do is install them, do the ln -sf /usr/lib/ninja-build/bin/ninja /usr/bin/ninja and run the script.

[Samueru-sama]

Why not use a mostly-static yt-dlp?
[+] https://bin.ajam.dev/x86_64_Linux/yt-dlp

That yt-dlp binary doesn't work with the regular MPV appimage that I have:

But before, some needed context, there are two types of appimages:

• The common appimage that relies on the host libraries, what 99.99% of appimages are, these appimages only work on Glibc systems and the tooling ignores the following libraries from being bundled since they present issues when bundled, that's the 18.3 MB appimage in the release.

• Go-appimage has a deploy everything mode that ignores the list and deploys everything, including ld-linux, however it isn't perfect as seen here it causes this issue when trying to use yt-dlp, that appimage can work on musl systems due to it having bundled glibc and everything else, that's the 24.5 MB appimages in the release.

With that said, the regular non anylinux appimage that I have does not have problems playing videos with yt-dlp. https://imgur.com/esDTLdS.png

However trying that appimage with the static yt-dlp binary shows the following error:

./mpv "https://www.youtube.com/watch?v=80mGyTh6S_E"
[ytdl_hook] ERROR: Invalid update channel '' requested. Valid channels are stable, nightly, master
[ytdl_hook] youtube-dl failed: unexpected error occurred
Failed to recognize file format.
Exiting... (Errors when loading file)

First I play a video using my distros yt-dlp, no problems.

I install yt-dlp with dbin. Now I get the error of above.

I tested removing the yt-dlp from the distro just in case there is a conflict and I still get the same error.

[Azathothas]

I see.
I seem to have misunderstood everything.
I expected mpv to be mostly static binary (so only the libc has to be copied).
And appimages seem to be just a portable disc, they refuse to work if I don't have fuse or low privilege.
I also tested files from: https://github.com/ivan-hc/MPV-appimage
Same story. All the binaries (after extracting) were dynamic, and it's just a copy of the whole filesystem needed to run mpv.

I am not a regular linux user, I am a sysadmin/netadmin, so I only have experience with servers which are headless and static binaries are what work reliably on those.
I understand how regular users (with windows managers, GUI & more) would choose APPImages as that seems to be one of the few portable means they can use their apps (which are mostly GUI), but to me, they are no longer interesting.
Staticx now seems a much saner way, as it creates binaries which are just archives that are self-extracting at run time. (The extracted files are created/pruned upon each run, except for external cache/config files). If you know another format that resembles staticx, and doesn't try mounting an entire filesystem, do let me know.
The reason the staticx static yt-dlp binary didn't work was that it was expecting to be able to self-extract on a regular filesystem, and appimages aren't that. Dynamic yt-dlp is probably the way to go here.
There's already official dynamic binaries at:
https://github.com/yt-dlp/yt-dlp/releases/latest
https://github.com/yt-dlp/yt-dlp-nightly-builds/releases/latest

For now, I think AppImages are entirely out of the question. I might continue a longer rant at: Azathothas/Toolpacks#28 and also take @xplshn's pelf a bit more seriously.
Until then, my time will mostly be spent in adding more OS (BSDs) and probably even cosmo's APE binaries.

I had rather not spam here about topics completely unrelated to your Issue, and such will no longer reply.
I wish you luck in fixing your port.

[Samueru-sama]

And appimages seem to be just a portable disc, they refuse to work if I don't have fuse or low privilege

You can still run appimages without fuse by passing the --appimage-extract-and-run flag or setting the env variable APPIMAGE_EXTRACT_AND_RUN=1 which is actually often done in CI when building appimages btw.

The downside of this method is higher startup times and that the appimage remains extracted in /tmp after being closed.

Ivan calls his appimages archimages, he basically wraps a junest enviroment into an appimage, something similar is also being done with conty containers, which for stuff like Steam which needs 32 bit libraries is the quick and dirty simple solution lol

So appimages are very similar to staticx because I remember that when I had those errors with xdotool I was getting the error from a path in /tmp.

(The extracted files are created/pruned upon each run, except for external cache/config files)

The appimage runtime also does stuff like if you place a directory next to the appimage with the name of the appimage + .home it will set $HOME to that location and that way you can have it be fully portable.

The reason the staticx static yt-dlp binary didn't work was that it was expecting to be able to self-extract on a regular filesystem, and appimages aren't that

Doesn't seem like that was the issue, because you can run the appimage extracted as seen here:

(You normally don't have to cd into the dir in /tmp and run the AppRun, I did it just to show that it is not a read-only filesystem)

EDIT: Yeah I tested on the regular mpv arch package and the same error happens:

Dynamic yt-dlp is probably the way to go here.
There's already official dynamic binaries at:

With that said the official binary does work with the mpv-appimage and mpv arch package.

[Samueru-sama]

If you REALLY want a static mpv binary, OasisLinux (a completely static Linux distro) has them. But Oasis patches mpv and fixes some of its issues.

binary (the rootfs is a git repo, it gets rebuilt every a few months, LTS): https://github.com/oasislinux/root-x86_64/blob/media/bin/mpv pkg build recipe: https://github.com/oasislinux/oasis/tree/master/pkg/mpv

I tested it with a youtube vid, doesn't work either LOL.

I first test with the regular mpv appimage that doesn't have everything deployed, it works, also note that I'm using the official yt-dlp binary.

Then I try the same with the static mpv binary you linked, doesn't work.

Edit: And it is just not yt-dlp, that mpv binary doesn't work with any video I give.

[xplshn]

Staticx now seems a much saner way, as it creates binaries which are just archives that are self-extracting at run time. (The extracted files are created/pruned upon each run, except for external cache/config files). If you know another format that resembles staticx, and doesn't try mounting an entire filesystem, do let me know.

Staticx, as you said, will decompress the entire archive, which is in fact the same thing that AppBundles do. AppImages' advantage is that they don't have slower start-up times than a regular binary, nor does it waste RAM. Also, static AppImages are a thing, an AppImage that is static on the outside, just like staticx binaries, but contains dynamically linked binaries within.

Those type of AppImages is what we're hoping to get on your repo, basically staticx but for more broader use-cases. The issues you'll have with it are the same ones you'd have with staticx, appbundles and other ways of trying to create a portable binary, parting from an unportable one.

[xplshn]

If you REALLY want a static mpv binary, OasisLinux (a completely static Linux distro) has them. But Oasis patches mpv and fixes some of its issues.
binary (the rootfs is a git repo, it gets rebuilt every a few months, LTS): https://github.com/oasislinux/root-x86_64/blob/media/bin/mpv pkg build recipe: https://github.com/oasislinux/oasis/tree/master/pkg/mpv

I tested it with a youtube vid, doesn't work either LOL.

I first test with the regular mpv appimage that doesn't have everything deployed, it works, also note that I'm using the official yt-dlp binary.

Then I try the same with the static mpv binary you linked, doesn't work.

Edit: And it is just not yt-dlp, that mpv binary doesn't work with any video I give.

No, it won't. Oasis is not FHS, that mpv binary was compiled in an OASIS environment, where libALSA is configured to look for its files at /share, if you create such dir and copy the regular ALSA config, it will work. I am saying that we could try using the OASIS build reciped, since OASIS is a complete self-hosting Linux system that is completely static, they don't even have a ld.so

[Azathothas]

I have successfully compiled a static mpv appimage that is universal, is bundled with as many features as possible, and also contains youtube-dl and other goodies.

I tested these on containers with only the bare minimums (not even yt dlp or any other utilities or libraries):

[+] https://github.com/Samueru-sama/mpv-AppImage/releases/download/continuous/mpv_Media_Player-v0.38.0-741-ga0ebfc3462-x86_64.AppImage 18.2 MB

!#doesn't even open
/tmp/.mount_mpv_MeElcnIj/usr/bin/mpv: error while loading shared libraries: libEGL.so.1: cannot open shared object file: No such file or directory

[+] https://github.com/Samueru-sama/mpv-AppImage/releases/download/continuous/WIP-mpv_Media_Player-v0.38.0-741-ga0ebfc3462-anylinux-x86_64.AppImage 24.4 MB

!#VERSION
🌀 ❯ ./WIP-mpv_Media_Player-v0.38.0-741-ga0ebfc3462-anylinux-x86_64.AppImage -v
[cplayer] Command line options: '-v'
[cplayer] mpv v0.38.0-741-ga0ebfc3462 Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
[cplayer]  built on Sep  3 2024 19:57:30
[cplayer] libplacebo version: v7.349.0 (v7.349.0-9-gefb89342)
[cplayer] FFmpeg version: N-116848-g3f9b78bd19
[cplayer] FFmpeg library versions:
[cplayer]    libavcodec      61.11.100
[cplayer]    libavdevice     61.2.100
[cplayer]    libavfilter     10.2.102
[cplayer]    libavformat     61.5.101
[cplayer]    libavutil       59.35.100
[cplayer]    libswresample   5.2.100
[cplayer]    libswscale      8.2.100
[cplayer] Configuration: -Dprefix=/home/runner/work/mpv-AppImage/mpv-AppImage/mpv/mpv.AppDir/usr -Dbuildtype=release
[cplayer] List of enabled features: build-date cplugins dvbin egl egl-x11 ffmpeg gl glibc-thread-name glob glob-posix gpl iconv jpeg lcms2 libass libavdevice libdl libplacebo linux-fstatfs lua52 memrchr posix ppoll pthread-condattr-setclock pulse vector vk-khr-display vt.h vulkan x11 zlib
[cplayer] Setting option 'v' = '' (flags = 8)
[cplayer] Usage:   mpv [options] [url|path/]filename
[cplayer]
[cplayer] Basic options:
[cplayer]  --start=<time>    seek to given (percent, seconds, or hh:mm:ss) position
[cplayer]  --no-audio        do not play sound
[cplayer]  --no-video        do not play video
[cplayer]  --fs              fullscreen playback
[cplayer]  --sub-file=<file> specify subtitle file to use
[cplayer]  --playlist=<file> specify playlist file
[cplayer]
[cplayer]  --list-options    list all mpv options
[cplayer]  --h=<string>      print options which contain the given string in their name
[cplayer] Set property: user-data/osc/visibility="auto" -> 1
[cplayer] Set property: user-data/osc/margins={"b":0,"r":0,"t":0,"l":0} -> 1
   libswscale      8.2.100
   
!#PLAYTEST (no yt-dlp)
❯ ./WIP-mpv_Media_Player-v0.38.0-741-ga0ebfc3462-anylinux-x86_64.AppImage 'https://iv.nowhere.moe/watch?v=HsQ-cr-AZsg'
[ffmpeg] tcp: Failed to resolve hostname iv.nowhere.moe: System error
Failed to open https://iv.nowhere.moe/watch?v=HsQ-cr-AZsg.
[ytdl_hook] Subprocess failed: init
[ytdl_hook] Subprocess failed: init
[ytdl_hook] Subprocess failed: init
[ytdl_hook]
[ytdl_hook] youtube-dl failed: not found or not enough permissions
Exiting... (Errors when loading file)   

!#PLAYTEST (static/dynamic yt-dlp)
[ytdl_hook]
[ytdl_hook] youtube-dl failed: not found or not enough permissions
Failed to recognize file format.
#though I made sure it existed and had enough perms

[+] https://github.com/ivan-hc/MPV-appimage/releases/download/continuous/MPV-Media-Player_0.38.0-6-archimage3.4.4-2-x86_64.AppImage 159 MB

!#VERSION
🌀 ❯ ./MPV-Media-Player_0.38.0-6-archimage3.4.4-2-x86_64.AppImage -v
[cplayer] Command line options: '-v'
[cplayer] mpv v0.38.0-dirty Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
[cplayer]  built on Jul  3 2024 05:59:22
[cplayer] libplacebo version: v7.349.0
[cplayer] FFmpeg version: n7.0.2
[cplayer] FFmpeg library versions:
[cplayer]    libavutil       59.8.100
[cplayer]    libavcodec      61.3.100
[cplayer]    libavformat     61.1.100
[cplayer]    libswscale      8.1.100
[cplayer]    libavfilter     10.1.100
[cplayer]    libswresample   5.1.100
[cplayer]
[cplayer] Configuration: -Db_pie=true -Dpython.bytecompile=1 -Dlibmpv=true -Dgl-x11=enabled -Dcaca=disabled -Dcdda=enabled -Ddvbin=enabled -Ddvdnav=enabled -Dlibarchive=enabled -Dopenal=enabled -Dprefix=/usr -Dlibexecdir=lib -Dsbindir=bin -Dauto_features=auto -Dbuildtype=plain -Dwrap_mode=nodownload
[cplayer] List of enabled features: alsa av-channel-layout avif-muxer build-date cdda cplugins cuda-hwaccel cuda-interop dmabuf-interop-gl dmabuf-wayland drm dvbin dvdnav egl egl-drm egl-wayland egl-x11 ffmpeg ffnvcodec gbm gl gl-x11 glibc-thread-name glob glob-posix gpl iconv jack javascript jpeg jpegxl lavu-uuid lcms2 libarchive libass libavdevice libbluray libdl libplacebo linux-fstatfs luajit memfd-create openal pipewire posix posix-shm ppoll pthread-condattr-setclock pulse rubberband rubberband-3 sixel uchardet vaapi vaapi-drm vaapi-wayland vaapi-x11 vapoursynth vdpau vdpau-gl-x11 vector vk-khr-display vt.h vulkan vulkan-interop wayland wayland-protocols-1-27 wayland-protocols-1-31 wayland-protocols-1-32 x11 xv zimg zimg-st428 zlib
[cplayer] Reading config file /etc/mpv/encoding-profiles.conf
[ifo_dvdnav] Opening /etc/mpv/encoding-profiles.conf
[bdmv/bluray] Opening /etc/mpv/encoding-profiles.conf
[file] Opening /etc/mpv/encoding-profiles.conf
[cplayer] Applying profile 'default'...
[cplayer] Setting option 'v' = '' (flags = 8)
[cplayer]
[cplayer] Usage:   mpv [options] [url|path/]filename
[cplayer]
[cplayer] Basic options:
[cplayer]  --start=<time>    seek to given (percent, seconds, or hh:mm:ss) position
[cplayer]  --no-audio        do not play sound
[cplayer]  --no-video        do not play video
[cplayer]  --fs              fullscreen playback
[cplayer]  --sub-file=<file> specify subtitle file to use
[cplayer]  --playlist=<file> specify playlist file
[cplayer]
[cplayer]  --list-options    list all mpv options
[cplayer]  --h=<string>      print options which contain the given string in their name
[cplayer]
[cplayer] Set property: user-data/osc/visibility="auto" -> 1
[cplayer] Set property: user-data/osc/margins={"b":0,"r":0,"l":0,"t":0} -> 1
/tmp/.mount_MPV-MeMnlMOj/.local/share/junest/bin/junest: exit trap: line 1: syntax error near unexpected token `('

!#PLAYTEST (no yt-dlp)
❯ ./MPV-Media-Player_0.38.0-6-archimage3.4.4-2-x86_64.AppImage 'https://iv.nowhere.moe/watch?v=HsQ-cr-AZsg'
[ytdl_hook]
[ytdl_hook] youtube-dl failed: not found or not enough permissions
Failed to recognize file format.
Exiting... (Errors when loading file)
/tmp/.mount_MPV-MecDHbIL/.local/share/junest/lib/core/common.sh: exit trap: line 1: syntax error near unexpected token `('

!#PLAYTEST (static/dynamic yt-dlp)
[ffmpeg] tcp: Failed to resolve hostname iv.nowhere.moe: System error

And finally mine:
[+] https://pub.ajam.dev/temp/mpv.x86_64.AppImage 448.761 MB

!#VERSION
 ./mpv.AppImage -v
[cplayer] Command line options: '-v'
[cplayer] mpv 0.38.0 Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
[cplayer]  built on Jan  1 1980 00:00:00
[cplayer] libplacebo version: v7.349.0
[cplayer] FFmpeg version: 6.1.2
[cplayer] FFmpeg library versions:
[cplayer]    libavutil       58.29.100
[cplayer]    libavcodec      60.31.102
[cplayer]    libavformat     60.16.100
[cplayer]    libswscale      7.5.100
[cplayer]    libavfilter     9.12.100
[cplayer]    libswresample   4.12.100
[cplayer]
[cplayer] Configuration: <ommited>
[cplayer] List of enabled features: alsa av-channel-layout avif-muxer build-date caca cplugins cuda-hwaccel cuda-interop dmabuf-interop-gl dmabuf-wayland drm dvbin dvdnav egl egl-drm egl-wayland egl-x11 ffmpeg ffnvcodec gbm gl glibc-thread-name glob glob-posix gpl iconv javascript jpeg jpegxl lavu-uuid lcms2 libarchive libass libavdevice libbluray libdl libplacebo linux-fstatfs lua memfd-create openal pipewire posix posix-shm ppoll pthread-condattr-setclock pulse rubberband rubberband-3 sdl2 sdl2-audio sdl2-gamepad sdl2-video uchardet vaapi vaapi-drm vaapi-wayland vaapi-x11 vdpau vector vk-khr-display vt.h vulkan vulkan-interop wayland wayland-protocols-1-27 wayland-protocols-1-31 wayland-protocols-1-32 x11 xv zimg zimg-st428 zlib
[cplayer] Reading config file /nix/store/rk6mmbi0838fg06dzkngc8ml1anplqbq-mpv-0.38.0/etc/mpv/encoding-profiles.conf
[ifo_dvdnav] Opening /nix/store/rk6mmbi0838fg06dzkngc8ml1anplqbq-mpv-0.38.0/etc/mpv/encoding-profiles.conf
[bdmv/bluray] Opening /nix/store/rk6mmbi0838fg06dzkngc8ml1anplqbq-mpv-0.38.0/etc/mpv/encoding-profiles.conf
[file] Opening /nix/store/rk6mmbi0838fg06dzkngc8ml1anplqbq-mpv-0.38.0/etc/mpv/encoding-profiles.conf
[cplayer] Applying profile 'default'...
[cplayer] Setting option 'v' = '' (flags = 8)
[cplayer]
[cplayer] Usage:   mpv [options] [url|path/]filename
[cplayer]
[cplayer] Basic options:
[cplayer]  --start=<time>    seek to given (percent, seconds, or hh:mm:ss) position
[cplayer]  --no-audio        do not play sound
[cplayer]  --no-video        do not play video
[cplayer]  --fs              fullscreen playback
[cplayer]  --sub-file=<file> specify subtitle file to use
[cplayer]  --playlist=<file> specify playlist file
[cplayer]
[cplayer]  --list-options    list all mpv options
[cplayer]  --h=<string>      print options which contain the given string in their name
[cplayer]
[cplayer] Set property: user-data/osc/visibility="auto" -> 1
[cplayer] Set property: user-data/osc/margins={"r":0,"b":0,"l":0,"t":0} -> 1

!#PLAYTEST (no yt-dlp)

[Samueru-sama]

No, it won't. Oasis is not FHS, that mpv binary was compiled in an OASIS environment, where libALSA is configured to look for its files at /share, if you create such dir and copy the regular ALSA config, it will work. I am saying that we could try using the OASIS build reciped, since OASIS is a complete self-hosting Linux system that is completely static, they don't even have a ld.so

What a shame, I tried ln -s /usr/share /share but didn't work either.

I have successfully compiled a static mpv appimage that is universal, is bundled with as many features as possible, and also contains youtube-dl and other goodies.

You just made a distro 😅 There has to be another way to fix the yt-dlp issues other than shipping an entire distro.

Note that yt-dlp is an optional dependency of mpv, so it isn't bundled the appimage, but if the only way to fix this issue involves bundling yt-dlp I have no problem then, however this went a bit to extreme lol.

[xplshn]

I have successfully compiled a static mpv appimage that is universal, is bundled with as many features as possible, and also contains youtube-dl and other goodies.

I tested these on containers with only the bare minimums (not even yt dlp or any other utilities or libraries):

[+] https://github.com/Samueru-sama/mpv-AppImage/releases/download/continuous/mpv_Media_Player-v0.38.0-741-ga0ebfc3462-x86_64.AppImage 18.2 MB

!#doesn't even open
/tmp/.mount_mpv_MeElcnIj/usr/bin/mpv: error while loading shared libraries: libEGL.so.1: cannot open shared object file: No such file or directory

Ofc it won't, libEGL.so provides graphics in Linux, (mesa-egl/mesa-libegl). Graphics are loaded when they are available, so mpv uses dlopen() for that. The AppImage would indeed work if you were using it in a normal system where mpv is desired. Why would you open a video/movie/music player without having graphics/audio support in your system?

[xplshn]

@Azathothas Nix has a Musl store. Try to use that one for generating binaries if possible, it is extensive, so there shouldn't be issues, using Musl means 30% smaller binaries.

[xplshn]

@Azathothas I extracted your mpv.AppImage, you really did make a distro, the thing includes 181 locales. It includes the entirety of libXft, not just the needed bits, WHY? It even contains systemd .service files, perl, etc.

[xplshn]

Apart from being almost a full-fledged distro (includes GTK libraries, why? it also has PERL, which is not a dependency of mpv)

I tested @Samueru-sama's appimage in Void Glibc, and I have just tested on Alpine. It worked in both.

[xplshn]

@Azathothas Have you thought of using this: https://github.com/leleliu008/ppkg-formula-repository-official-core ? @Samueru-sama suggested it, I know you've used ppkg before, and I think that's what's used for providing various binaries already.

[Samueru-sama]

@Azathothas Have you thought of using this: https://github.com/leleliu008/ppkg-formula-repository-official-core ? @Samueru-sama suggested it, I know you've used ppkg before, and I think that's what's used for providing various binaries already.

Worth mentioning that I tried to use https://github.com/leleliu008/ppkg-formula-repository-official-core to build mpv but the build failed, I don't know if it is that I don't how to use it lol.

[Azathothas]

All of the examples and tests was not to bash existing mpv appimages, rather it was to show that a fully portable (as is the entire point of appimages) image is possible but at the cost of size.
Yesterday I went asking for help about the same thing on various forums/groups, the universal consensus went something like this, I could reduce the size but what would be the point. Most appimages provided by official projects, sacrifice portability in the name of making the image as small as possible. They include the bare minimum, don't include libc , don't include plugins etc. And in my testing, with a bare metal server, those app images error out like I showed in the detailed test above.
Meanwhile my bloaty image doesn't, it works anywhere.

So I am faced with a choice, reduce the size but at these costs:

• Manually create hundreds of appimages including figuring out their dependencies which won't work everywhere anyway after all that effort
• Manually maintain these build scripts
• Be unable to do automated tests because I test binaries in containers with nothing in it, there's no simple way to test appimages unless I pull in the entirety of appimage test suit, which would take a long time for each build

Or I have a bloated appimage:

• I don't have to create anything manually, I can simply use nix-appimage to bundle it
• since I didn't have to figure out dependencies, and such, it takes 1-2 mins to write a build script that builds a universal appimage that works everywhere
• I don't have to maintain anything since nix package maintainer already do it for me
• also, I be able to do automated tests on bare metal containers just like I test static binaries without pulling in extensive test suite

This doesn't mean I won't explore ways to minimize the size, but if I ever do end up supporting GUI apps, I will go for the bloated appimage route

Also, I am in no control of what gets generated/included, it's essentially the /nix root packed as squash archive.
I could probably add a mid build hook to strip the runtime, delete systemd files and such to reduce size with no impact to probability.
Also, this was the only appimage that worked on my systems (which contrary to your note about me not having a graphics/audio support, I need to point out that the nix build mpv appimage had no complaints and the screenshots are from that server)

I also had quite a bit of laugh reading this: boredsquirrel/dont-use-appimages#1
I bet @Samueru-sama hates exactly my kind of linux users haha.

[Azathothas]

This one is built on a void-rootfs, has yt-dlp included, and also the void pkg manager
It's nearly half the size of my bloated appimage:
https://pub.ajam.dev/temp/mpv.x86_64.void.AppImage [231 MB]

It took the author roughly 5 hours of setting up the environment, figuring out dependencies and then finally building it.
Unless people submit me PRs, I don't think I can spare such amount of time for just one package.

And my way:

!#Replace mpv with any of the ~ 100000 nix pkg (https://search.nixos.org/packages ) and it just works
nix bundle --bundler "github:ralismark/nix-appimage" "nixpkgs#mpv" --log-format bar-with-logs

!# I just built an appimage of the ladybird browser and I simply replace mpv with ladybird.
# To my knowledge there's no official appimage for ladybird and the one created by the inventor himself, hasn't been updated https://github.com/probonopd/Ladybird.AppImage/issues/2
# If you know something else that's this easy & portable sure I am all ears

And https://github.com/leleliu008/ppkg-formula-repository-official-core/blob/master/formula/mpv.yml is marked as type pkgtype: lib so I don't think it's what you are looking for.
Maybe @leleliu008 could offer us more insight

[Samueru-sama]

All of the examples and tests was not to bash existing mpv appimages, rather it was to show that a fully portable (as is the entire point of appimages) image is possible but at the cost of size. Yesterday I went asking for help about the same thing on various forums/groups.

Be very careful asking other people about suggestions when making an appimage unless they actually know how they work, because the information you will get will very likely be very outdated.

the universal consensus went something like this, I could reduce the size but what would be the point. Most appimages provided by official projects, sacrifice portability in the name of making the image as small as possible. They include the bare minimum, don't include libc , don't include plugins etc. And in my testing, with a bare metal server, those app images error out like I showed in the detailed test above. Meanwhile my bloaty image doesn't, it works anywhere.

That's because most appimages are the regular appimages I was talking about before that try to be mostly compatible, those that depend on Glibc and some host libraries. Those appimages are common because they are easy to make and rarely you need to change the build process to accommodate them and they cover +95% of linux users, I mean you can already see here my regular mpv appimage has been working fine since day one while the one that bundles everything has this weird issue with yt-dlp.

The reason you don't see appimages like the mpv-anylinux one that work on all systems is the same reason you don't see static binaries of complex applications, it is not easy 😭

Also what do you mean by they don't include plugins? the qt plugins? those are included by the appimagetooling already.

And at least for me (I don't know @xplshn lol) it isn't a very big deal if I never figure out how to get the anylinux appimage to work with yt-dlp, what gets me is that the issue seems simple but we don't know what is going wrong, sound works, video playback works, but for some reason it has that issue with yt-dlp.

I also had quite a bit of laugh reading this: boredsquirrel/dont-use-appimages#1
I bet @Samueru-sama hates exactly my kind of linux users haha.

Cringe warning: That very post motivated me to start contributing to appimages btw, you can see my github activity has been constant after I made that issue. (that and having ptsd from the yuzu flatpak shipping an oudated mesa lol).

This one is built on a void-rootfs, has yt-dlp included, and also the void pkg manager
It's nearly half the size of my bloated appimage:
https://pub.ajam.dev/temp/mpv.x86_64.void.AppImage [231 MB]

Yeah for other applications (like Steam which the current appimage we have is 640 MiB) using this or the nix approach might produce a smaller appimage and be feasible, specially because with stuff like Steam you really want to be on a recent mesa version, which the distro you are using may not always have.

Maybe @leleliu008 could offer us more insight

@leleliu008 here is a TL:DR since this is getting very long:

I have two appimages being released here:

• The smaller appimage works fine with yt-dlp when giving a youtube url to mpv, note that yt-dlp is not bundled in the appimage and has to come from the host.
• The bigger appimage can't play youtube vids with yt-dlp, all combinations of yt-dlp being the python script, static binary, dynamic binary and bundling yt-dlp in the appimage have been tried, none have worked, the issue is in the appimage.

We don't know what breaks exactly, and it is the only thing that breaks because video playback and audio work perfectly on local videos.

The bigger appimage bundles more system libraries (making it compatible on musl systems), you can inspect the contents of the appimages by passing the --appimage-extract flag

EDIT: I may have misread what @Azathothas said about insight and that only related to the mpv formula, but anyway any insight in this very issue is also appreciated.

[Samueru-sama]

The issue has been fixed! Max found what the problem was 👀

Turns out go-appimage is breaking something in ld-linux.so.