Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use latest FFmpeg (4.4) for Windows x64 #2583

Closed
wants to merge 4 commits into from

Conversation

nkh0472
Copy link
Contributor

@nkh0472 nkh0472 commented Aug 24, 2021

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.

The link will fetch the latest version, but the checksum needs to be changed when a newer stable version is released.
@rom1v
Copy link
Collaborator

rom1v commented Aug 24, 2021

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
Copy link
Contributor Author

nkh0472 commented Aug 25, 2021

(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.

rom1v added a commit that referenced this pull request Jan 17, 2022
Use FFmpeg win64 binaries from gyan.dev (referenced from ffmpeg.org):

 - https://www.gyan.dev/ffmpeg/builds/
 - https://ffmpeg.org/download.html#build-windows

Keep the old FFmpeg prebuilt binaries (4.3.1) for win32 builds.

Fixes #1753 <#1753>
Refs #1838 <#1838>
Refs #2583 <#2583>

Co-authored-by: Yu-Chen Lin <[email protected]>
Co-authored-by: nkh0472 <[email protected]>
Signed-off-by: Romain Vimont <[email protected]>
@nkh0472 nkh0472 closed this Jan 18, 2022
rom1v added a commit that referenced this pull request Jan 18, 2022
Use FFmpeg win64 binaries from gyan.dev (referenced from ffmpeg.org):

 - https://www.gyan.dev/ffmpeg/builds/
 - https://ffmpeg.org/download.html#build-windows

Keep the old FFmpeg prebuilt binaries (4.3.1) for win32 builds.

Fixes #1753 <#1753>
Refs #1838 <#1838>
Refs #2583 <#2583>
PR #2952 <#2952>

Co-authored-by: Yu-Chen Lin <[email protected]>
Co-authored-by: nkh0472 <[email protected]>
Signed-off-by: Romain Vimont <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants