8000 ffmpeg: Update build source to use BtbN GitHub Releases by sannya-singal · Pull Request #12634 · localstack/localstack · GitHub
[go: up one dir, main page]

Skip to content

ffmpeg: Update build source to use BtbN GitHub Releases #12634

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

Merged
merged 2 commits into from
May 21, 2025

Conversation

sannya-singal
Copy link
Contributor
@sannya-singal sannya-singal commented May 19, 2025

Motivation

The current ffmpeg installer in LocalStack downloads binaries from johnvansickle.com, a privately hosted site that has exhibited timeout issues, likely due to bandwidth limitations or rate throttling.

To address this, we are switching to BtbN/FFmpeg-Builds — a well-maintained, GitHub-hosted source for ffmpeg binaries with:

  • Actively maintained nightly and tagged releases
  • LGPL-compliant builds suitable for LocalStack’s hybrid licensing model

Changes

  • Uses the latest build of a specific major version and replaces ffmpeg download URL with BtbN-hosted static LGPL 7.1 builds.
  • Resolves architecture dynamically based on the host (e.g., linux64, linuxarm64)
  • Updates the structure handling to match BtbN’s layout (bin/ffmpeg, bin/ffprobe)

Testing

Successful installation tested in local setup-
Screenshot 2025-05-16 at 3 14 22 PM

Successful installation tested in CI-
https://app.circleci.com/pipelines/github/localstack/localstack/32720/workflows/4f5455cf-dddb-4d27-b11b-75c52c3c604a

@sannya-singal sannya-singal added this to the 4.5 milestone May 19, 2025
@sannya-singal sannya-singal self-assigned this May 19, 2025
@sannya-singal sannya-singal added the semver: minor Non-breaking changes which can be included in minor releases, but not in patch releases label May 19, 2025
Copy link
github-actions bot commented May 19, 2025

LocalStack Community integration with Pro

    2 files  ±0      2 suites  ±0   1h 43m 30s ⏱️ + 1m 57s
4 451 tests ±0  4 067 ✅ ±0  384 💤 ±0  0 ❌ ±0 
4 453 runs  ±0  4 067 ✅ ±0  386 💤 ±0  0 ❌ ±0 

Results for commit b38d11c. ± Comparison against base commit 5f9ae76.

♻️ This comment has been updated with latest results.

@sannya-singal sannya-singal marked this pull request as ready for review May 19, 2025 06:49
@sannya-singal sannya-singal requested a review from alexrashed as a code owner May 19, 2025 06:49
@sannya-singal sannya-singal added the review: merge when ready Signals to the reviewer that a PR can be merged if accepted label May 19, 2025
Copy link
Contributor
@k-a-il k-a-il left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, I hope this source proves to be more reliable 🚀

Copy link
Member
@viren-nadkarni viren-nadkarni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for jumping on this!

I was wondering about the retention policy:

The last build of each month is kept for two years.
The last 14 daily builds are kept.

Have you verified that if there is a new ffmpeg release (7.2), would our pinning of 7.1 and use of latest marker in the URL not cause the link to break? Would it continue to point to the 'last build of the month' for as long as the build is stored?

The link will break beyond two years, I'm guessing that's acceptable lifetime of a LS release anyway.

I would also like @alexrashed to take a look at this.

@sannya-singal
Copy link
Contributor Author

Thanks for jumping on this!

I was wondering about the retention policy:

The last build of each month is kept for two years.
The last 14 daily builds are kept.

Have you verified that if there is a new ffmpeg release (7.2), would our pinning of 7.1 and use of latest marker in the URL not cause the link to break? Would it continue to point to the 'last build of the month' for as long as the build is stored?

The link will break beyond two years, I'm guessing that's acceptable lifetime of a LS release anyway.

I would also like @alexrashed to take a look at this.

Great points!

Regarding your concern: It would not break immediately. The URL targets a 7.1-specific build, which will continue to receive nightly rebuilds until 7.2 becomes the new upstream release. Once 7.2 is out, n7.1-latest would no longer be updated, but the last 7.1 monthly build would remain available for 2 years, but will not be referenced by latest anymore in such cases.

After that, we would need to either: Refresh the pinned version (e.g., to 7.2) or follow the approach already described in Notion concerning the mirror the binary internally (e.g., to S3 or artifacts) if long-term retention is required.

I already synced with @alexrashed about the current approach in Notion, but I’m happy to wait for his review, though that likely means a ~3-week timeline since he’s on vacation 😛

Let me know how you'd like to proceed! 🙂

@sannya-singal
Copy link
Contributor Author

Marking this PR as a draft to prevent any accidental merges until we reach a conclusion on this.

@sannya-singal sannya-singal marked this pull request as draft May 20, 2025 11:05
@viren-nadkarni
Copy link
Member

Understood, thanks for clarifying 👍

Good job with actively starting the discussion and passing this through others. I think we can proceed with the merge.

@viren-nadkarni viren-nadkarni self-requested a review May 20, 2025 11:15
@sannya-singal sannya-singal marked this pull request as ready for review May 21, 2025 03:37
@sannya-singal sannya-singal merged commit 4a929ed into master May 21, 2025
34 checks passed
@sannya-singal sannya-singal deleted the ffmpeg-build branch May 21, 2025 03:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
review: merge when ready Signals to the reviewer that a PR can be merged if accepted semver: minor Non-breaking changes which can be included in minor releases, but not in patch releases
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0