FFmpeg windows builds will be removed

[rom1v]

I developed scrcpy for Linux, where the dependencies are just retrieved via apt.

But scrcpy had to work on Windows too. I'm bad at build systems, and have a very limited knowledge of Windows, so I initially just recommended to build from something which looks like a Linux environment (MSYS2). For the first public release (v1.0), I even just took the DLL installed from the MSYS environment.

But it was too cumbersome for me to create a release (I had to build from a Windows machine), so I wrote some script to cross-compile the binaries from Linux, and just downloaded prebuilt dependencies of FFmpeg and SDL (106b87a). This was a quick&dirty solution (which btw makes adding or upgrading dependencies very annoying). I'm not very proud of it, but at least it was good enough for solving my problem.

The FFmpeg binaries are downloaded from https://ffmpeg.zeranoe.com/builds/. This site will close soon:

ffmpeg.zeranoe.com will close on Sep 18, 2020, and all builds will be removed. If you're using Zeranoe FFmpeg Builds in your product, please ensure that you have a hosting strategy in place by the 18th. Thank you to everyone who supported the project along the way!

so the release script of scrcpy will just stop to work correctly.

In the short term, I could just keep the latest versions and ship them. But it becomes urgent to build the dependencies along with scrcpy. And an option to build static binaries would be awesome (#1624).

https://linuxfr.org/users/roger21/journaux/ffmpeg-pour-windows-ca-va-couper

[npes87184]

#1484 also suffered from dll hell. IMO, it can be solved in the same time?

[Biswa96]

I even just took the DLL installed from the MSYS environment.

MSYS2/MinGW FFmpeg builds are dynamically linked. So, you have to download all the dependencies which may not be the right solution here. One lazy solution would be to create a package for MSYS2 which already provides FFmpeg and SDL2. But the package will not be a standalone like the current releases.

The FFmpeg binaries are downloaded from https://ffmpeg.zeranoe.com/builds/. This site will close soon:

How those guys build it. Any script?

so the release script of scrcpy will just stop to work correctly.

Neevvveeerrr. With CI, possibility is endless.

[ouvtk]

Not sure if it will help much, but ffmpeg peeps already have a compilation guides: https://trac.ffmpeg.org/wiki/CompilationGuide
And https://github.com/rdp/ffmpeg-windows-build-helpers looks as the best option for cross-compiling.

But need to understand what the end goal would be, as compiling ffmpeg every as a dependency for scrcpy would be time consuming. I mean potentially ffmpeg community will come up with alternative source for the builds.

[rom1v]

MSYS2/MinGW FFmpeg builds are dynamically linked. So, you have to download all the dependencies which may not be the right solution here.

Yes, that's what I did for v1.0. 😄

How those guys build it. Any script?

I don't know.

In theory, I'd like to do something similar as we do in VLC (cf contrib/src/ffmpeg/rules.mak).

Neevvveeerrr. With CI, possibility is endless.

Yes, but I would like to be able to build the whole release from any computer (running linux) in a single script (even without docker) :)

[rom1v]

Not sure if it will help much, but ffmpeg peeps already have a compilation guides: https://trac.ffmpeg.org/wiki/CompilationGuide
And https://github.com/rdp/ffmpeg-windows-build-helpers looks as the best option for cross-compiling.

Thank you for the links 👍

as compiling ffmpeg every as a dependency for scrcpy would be time consuming

Only if we want/need to, otherwise it could use the dependencies provided by the system.

But it would also allow to create a minimal static build (that would be awesome to distribute the latest scrcpy release on linux).

[Biswa96]

In theory, I'd like to do something similar as we do in VLC

If that need a script to be added in scrcpy, would you add it?

Yes, but I would like to be able to build the whole release from any computer

By whole release, do you mean to compile dependencies also? Or scrcpy only?

[rom1v]

If that need a script to be added in scrcpy, would you add it?

Yes, a script which builds ffmpeg and a script which builds SDL. 👍

I would like to replace prebuild-deps by a directory deps with 3 subdirs:

• deps/src/ffmpeg
• deps/src/sdl
• deps/src/adb

Each subdir would contain a script to build and install the dependency into some destination directory (or just download and verify checksum for adb). The resulting built libraries would be used by the scrcpy build system.

But that should be optional (e.g. we should be able to build scrcpy against the system ffmpeg).

By whole release, do you mean to compile dependencies also? Or scrcpy only?

Yes, dependencies included.

The release script should generate the files posted on every release:

• scrcpy-server
• windows 32 bits release
• windows 64 bits release

If we compile the dependencies ourselves, either we just include the dll in the release, or better we build the scrcpy binaries with FFmpeg and libsdl statically linked.

And if that's the case, we could also generate:

• linux 32 bits release
• linux 64 bits release

This is just what I have currently in mind, maybe there are better ways.

[Biswa96]

Found something https://github.com/rdp/ffmpeg-windows-build-helpers.git. I will try it.

[npes87184]

Found something https://github.com/rdp/ffmpeg-windows-build-helpers.git. I will try it.

Be aware that the license of this script is GPLv3.

[npes87184]

Hi, @rom1v

Would you accept something like mxe? I built SDL2 and ffmpeg using mxe. After it, I built scrcpy against the output dlls in mxe and copied needed dlls by using copydlldeps (a tool from mxe).

If you are ok on mxe, I can create a PR about this.

[rom1v]

Would you accept something like mxe?

For now, I don't know enough to have an opinion.

MXE (M cross environment) is a GNU Makefile that compiles a cross compiler and cross compiles many free libraries such as SDL and Qt.

So compiling the cross compiler is a necessary step?

[rom1v]

Oh, ffmpeg.org provides an alternative link to builds of FFmpeg:

• http://ffmpeg.org/download.html#build-windows
• https://github.com/BtbN/FFmpeg-Builds/releases

This does not change the goal to get a proper solution, but it could help in the short term :)

[npes87184]

Would you accept something like mxe?

For now, I don't know enough to have an opinion.

For demo and testing, I can provide a PoC in a branch of my forked repo.
BTW, it seems to me that use mxe makes sense. We don't need to re-create wheel if there is someone has done it before.

MXE (M cross environment) is a GNU Makefile that compiles a cross compiler and cross compiles many free libraries such as SDL and Qt.

So compiling the cross compiler is a necessary step?

From my point of view, the answer looks yes.

[npes87184]

Hi, @rom1v

You can try this commit if you have an interest in this.

I just simply modified the win64 version.

Thanks.

[rom1v]

@npes87184 Oh, thank you! Very interesting.

It looks great in the Makefile.

However, since it rebuilds everything (including gcc and other stuff), it takes too much time. 😞

[npes87184]

@npes87184 Oh, thank you! Very interesting.

It looks great in the Makefile.

I guess it still has some problems need to be solved. When it executes the copydlldeps.sh, it shows that some dlls does not find. Even though, I can run this in my windows 10, I am not sure if it affects or not.

I guess we need to write down all the dependencies of ffmpeg and SDL2 in app/meson.build.

However, since it rebuilds everything (including gcc and other stuff), it takes too much time. 😞

Yes, it is a problem. It also has pre-built libs here. However, I have not tested it.

BTW, if we want to do static link ffmpeg, it also needs to care about the license.

[rom1v]

BTW, if we want to do static link ffmpeg, it also needs to care about the license.

True.

Static link is a nice-to-have solution so that Linux users could quickly test the latest version using a binary. If we are able to build the deps dynamically for Windows, it's already good.

[npes87184]

Oh, ffmpeg.org provides an alternative link to builds of FFmpeg:

• http://ffmpeg.org/download.html#build-windows
• https://github.com/BtbN/FFmpeg-Builds/releases

This does not change the goal to get a proper solution, but it could help in the short term :)

I create a PR that use ffmpeg built from BtbN in #1838 .

[deep9]

Until this is resolved, you can prepend the ffmpeg url with https://web.archive.org/web/20200916091820/ (like https://web.archive.org/web/20200916091820/https://ffmpeg.zeranoe.com/builds/win32/shared/ffmpeg-4.3.1-win32-shared.zip) in prebuild-deps/Makefile

[rom1v]

@deep9 Thank you for your suggestion. I tested, but their server are quite slow for downloading such archives (and I guess it's not very fair to download from them).

Instead, I added the releases on GitHub, and referenced them: 5dc3285

[deep9]

@rom1v Sure, this is more stable solution, mine was intended as a workaround :)

[LHLaurini]

May I suggest using Conan? It's able to both download prebuilt binaries (if available) or build automatically from the source. I haven't used it much, but it's worked well for me so far.

Problem is it's much better integrated with CMake. Meson, not so much.

[rom1v]

Problem is it's much better integrated with CMake. Meson, not so much.

Note: it seems that meson can use the CMake find_package for compatibility.

(However, Conan is not available is official Debian repositories, so I prefer not to depend on it.)

[Menstro]

Unsubscribe

[rom1v]

@Menstro

Unsubscribe

To unsubscribe from a thread on github, there is a button Unsubscribe on the right column, in the "Notifications" section.

[LHLaurini]

(However, Conan is not available is official Debian repositories, so I prefer not to depend on it.)

Conan can be installed using pip.

Even then, seems the official Conan repo doesn't have a ffmpeg recipe yet. Maybe once it's available, we could give it another thought.

[MartinDelille]

Even then, seems the official Conan repo doesn't have a ffmpeg recipe yet. Maybe once it's available, we could give it another thought.

It's available and functional: conan-io/conan-center-index#6707

[AlynxZhou]

If we need to build dependencies on windows, I suggest to try meson's wrap, which can helps to gather and build dependencies. See #1624 (comment).

[AlynxZhou]

However wrapdb has SDL2 but not ffmpeg.

[AlynxZhou]

A meson-ported ffmpeg hosted by gstreamer is https://gitlab.freedesktop.org/gstreamer/meson-ports/ffmpeg but it's ffmpeg 4.1.

[rom1v]

I published a custom build specific to scrcpy (containing only the features used by scrcpy):
https://github.com/rom1v/scrcpy-deps

Here is a commit (not merged yet) to use it: custom-ffmpeg

For comparison, here are the sizes of the dll for FFmpeg 5.1.2:

• before: 89M
• after: 4.7M

[rom1v]

And now, FFmpeg 6.0 🎉

https://github.com/rom1v/scrcpy-deps/releases/tag/6.0-scrcpy