Skip to content

fix(desktop): Windows FFmpeg from BtbN GitHub + detect bin/ layout (#248) - #249

Merged
thcp merged 1 commit into
mainfrom
fix/windows-ffmpeg-btbn-github
Jul 6, 2026
Merged

fix(desktop): Windows FFmpeg from BtbN GitHub + detect bin/ layout (#248)#249
thcp merged 1 commit into
mainfrom
fix/windows-ffmpeg-btbn-github

Conversation

@thcp

@thcp thcp commented Jul 6, 2026

Copy link
Copy Markdown
Collaborator

Fixes #248.

Problem

Two issues reported for Windows FFmpeg setup:

  1. Slow download. First-run setup fetches FFmpeg from gyan.dev, a single US-hosted mirror. A German reporter saw ~0.1 MB/s (vs 10 MB/s pulling FFmpeg from GitHub on the same connection).
  2. Manual FFmpeg not detected. The reporter placed FFmpeg at data/ffmpeg/bin/ffmpeg.exe (the upstream folder layout), but detection only checked data/ffmpeg/ffmpeg.exe, so it downloaded anyway.

Changes (all in desktop/src-tauri/src/main.rs)

1. Windows FFmpeg download: gyan.dev -> BtbN GitHub

  • Default asset is now ffmpeg-n8.1-latest-win64-gpl-8.1.zip from BtbN/FFmpeg-Builds, served via GitHub's CDN (fast worldwide, including the EU).
  • Checksum verification reworked: BtbN publishes one combined checksums.sha256 (every asset as <hash> <filename> lines) instead of gyan's per-file {url}.sha256. A new pure helper sha256_from_checksums extracts the line for our archive. Fails closed if the archive is not listed.
  • A custom STEMDECK_FFMPEG_URL override still skips verification (unchanged behavior).
  • Extraction is unchanged: it already flattens by matching ffmpeg.exe/ffprobe.exe anywhere in the archive, so BtbN's bin/ layout and the extra ffplay.exe are handled.

GPL is fine here because StemDeck shells out to FFmpeg as a separate process (mere aggregation), not linking it.

2. Detect a manually-placed FFmpeg under data/ffmpeg/bin/

  • New resolve_existing_ffmpeg checks the STEMDECK_FFMPEG override, then flat data/ffmpeg/, then data/ffmpeg/bin/, returning the first that exists.
  • Wired into probe_runtime, ffmpeg_dir_if_present, and ensure_ffmpeg, so a manually-placed build is honored instead of triggering a download.
  • write_setup_config now records ffprobe next to the resolved ffmpeg.

Scope

Windows only (macOS/evermeet and Linux/johnvansickle sources unchanged). The bin/ fallback is cross-platform since it is harmless elsewhere.

Testing

  • cargo fmt --check: clean.
  • cargo test: 11 passed, including 2 new tests (sha256_from_checksums_picks_matching_line, resolve_existing_ffmpeg_prefers_flat_then_bin).
  • The Windows download path is #[cfg(windows)] and could not be built on the macOS dev box (cross-compile fails on the ring C toolchain); it builds in the Windows release job. Manual Windows checks still pending: real first-run download from BtbN, and bin/ detection without a download.

)

Switch the Windows FFmpeg download from gyan.dev (single US mirror, ~0.1 MB/s
for the reporter) to BtbN's GitHub build, served via GitHub's CDN. Uses the
pinned asset ffmpeg-n8.1-latest-win64-gpl-8.1.zip and verifies it against
BtbN's combined checksums.sha256 (one file listing every asset), replacing the
old per-file {url}.sha256 companion fetch. Fails closed if the archive is not
listed. Custom STEMDECK_FFMPEG_URL overrides still skip verification.

Also detect a manually-placed FFmpeg under data/ffmpeg/bin/ (the upstream
folder layout) in addition to the flat data/ffmpeg/ location, so users who drop
in their own build are honored instead of triggering a download. Detection now
flows through resolve_existing_ffmpeg across probe_runtime, ffmpeg_dir_if_present,
and ensure_ffmpeg; write_setup_config records ffprobe next to the resolved
ffmpeg.
@thcp
thcp marked this pull request as ready for review July 6, 2026 16:50
@thcp
thcp merged commit ec73f55 into main Jul 6, 2026
8 checks passed
@thcp
thcp deleted the fix/windows-ffmpeg-btbn-github branch July 6, 2026 16:50
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.

[Bug]: FFmpeg is not being recognized | And the download is extremely slow

1 participant