Use latest FFmpeg (4.4) for Windows x64

[nkh0472]

The download link in ./prebuilt-deps/Makefile will fetch the latest version (for now it is 4.4), but the checksum needs to be changed when a newer stable version is released.

There is a way to fetch the latest release version number of FFmpeg and the sha256sum of the build, more info about them can be seen in https://github.com/GyanD/codexffmpeg.

---

In another PR #2582, I mentioned that the situation about update FFmpeg pre-compiled build for Windows is a little bit complex.

Part of the reason is FFmpeg doesn't provide an official binary build, and two semi-official binary builds only contain a 64bit version.

Therefore it's kind of difficult to get 32bit binary builds for every stable release (unless compile by ourselves, although it requires a lot of computing resources and disk space).

But no matter what, the 64bit version of it is always available. So I make this PR to make sure at least we can use the latest 64bit FFmpeg.

As I mentioned earlier, there are two semi-official providers of binary pre-compiled builds for windows, gyan.dev and BtbN.

The reason why I chose the former is that for the stable version of FFmpeg, he only provides a single compiled version, so it is more stable and controllable; Another one often publishes updated pre-compiled files of the stable version.

[rom1v]

As I just answered in #2582, I think it should point to a specific (tested) version, with its checksum (committed in the repo), not just some latest version (even if it could be more convenient).

(also ref #1838)

unless compile by ourselves, although it requires a lot of computing resources and disk space

That would be a good solution IMO (see discussions in #1753). Moreover, scrcpy uses only few parts of FFmpeg (only H.264, etc.), so we could build small FFmpeg dll.

[nkh0472]

(also ref #1838)

It seems that someone has done similar work to this RP, and that RP looks more perfect, so you can close this RP in any time.

As I just answered in #2582, I think it should point to a specific (tested) version, with its checksum (committed in the repo), not just some latest version (even if it could be more convenient).

With regard to the "tested specific" version, I think starting with the stable release of FFmpeg is a good start. As mentioned earlier, the stable version of gyan.dev is only released once when FFmpeg releases a new stable version, and the interval is usually about 6 months.

It seems unfair for you to test every six months at most, but I think some people in the community should be happy to help complete this work while enjoying the latest FFmpeg.

You are only responsible for the version you used. At the same time, if you can make a few changes to the compiled script to use the tested version by default, but at the same time, we can use the latest version through the build parameters, it will be an ideal solution.

Moreover, scrcpy uses only few parts of FFmpeg (only H.264, etc.), so we could build small FFmpeg dll.

I think the ultimate goal of scrcpy is to have a series of scripts that compile the deps, as #1753 said.

However, I am somewhat dissatisfied with the current situation, because it seems that there is neither a minimum build used in scrcpy releases, nor a guide for compiling minimum build (at least describing the libraries that must be included in FFmpeg).

In addition, although I haven't actually compiled the minimum build, I insist on guessing that compiling such FFmpeg still requires a relatively large amount of resources. In the process of self compilation (not in releases), using precompiled package is an good choice that can exchange a small amount of space for a large amount of time (including the time required for compilation and trouble solving). Even after the script for minimum build is completed in the future, using precompiled package can still appear in the compiled script as a cost-effective option.

In summary, as a compromise for now, it may be a reasonable option to include the precompiled package you specified and the latest stable version of the precompiled package in the current script for everyone to choose. To do this, we only need to make a few changes to the script.