Bundle the ffmpeg sidecar #117

New issue

Closed

opened 2026-10-09 08:28:06 +00:00 by crowmaki · 1 comment

crowmaki commented

2026-10-09 08:28:06 +00:00

Owner

Parent

#24

What to build

Ship ffmpeg with the app as a Tauri sidecar, as ADR-0003 decided: "An unmodified LGPL build ships as a Tauri sidecar and is called only by Rust."

Today nothing is bundled. crates/studio-core/src/ffmpeg.rs already looks for ffmpeg in this order:

AI_STUDIO_FFMPEG.
Next to the app's executable, which is where Tauri installs sidecars.
PATH.

src-tauri/tauri.conf.json, however, has no bundle.externalBin. So posters, joined Voice clips, master stamping and proxies all depend on whatever ffmpeg the user has on PATH.

This shows in development too. A PATH ffmpeg without libopenh264 fails two studio-core unit tests (ffmpeg::tests::a_proxy_is_h264_at_a_short_side_of_768_with_the_masters_audio and ffmpeg::tests::a_proxy_of_a_small_master_keeps_its_size) with Unknown encoder 'libopenh264'. This was seen while working on #116. Proxies need OpenH264 whenever NVENC is not usable (ProxyEncoder).

Pick a prebuilt, unmodified LGPL ffmpeg for Windows x64 that has libopenh264, and NVENC (h264_nvenc) if possible. Fetch it at a pinned version with a checked hash, and bundle it under Tauri's sidecar naming (ffmpeg-<target-triple>.exe). Dev builds and tests should use the same binary, so local results don't depend on PATH.

Acceptance criteria

A script (or build step) downloads the chosen LGPL build at a pinned version, checks its SHA-256 and places it at src-tauri/binaries/ffmpeg-x86_64-pc-windows-msvc.exe. The binary is gitignored, not committed.
tauri.conf.json lists it in bundle.externalBin, and a bundled build installs it next to the app's executable, where Ffmpeg::locate finds it without AI_STUDIO_FFMPEG or PATH.
tauri dev and cargo test use the fetched binary, for example by having the fetch step run first and locate (or the test helper) fall back to src-tauri/binaries/. The two proxy tests above pass on a machine whose PATH ffmpeg lacks libopenh264, or has no ffmpeg at all.
The chosen build is confirmed to have libopenh264 (and NVENC if it has it), and detect_proxy_encoder still picks NVENC only when it works.
LGPL obligations are met for the shipped binary: the licence text and the build's source or build-recipe reference are included with the bundle (for example in a third-party notices file), and the build is used unmodified.
The README or the run-ai-studio skill says how to fetch the sidecar for development.

Blocked by

None.

## Parent #24 ## What to build Ship ffmpeg with the app as a Tauri sidecar, as ADR-0003 decided: "An unmodified LGPL build ships as a Tauri sidecar and is called only by Rust." Today nothing is bundled. `crates/studio-core/src/ffmpeg.rs` already looks for ffmpeg in this order: 1. `AI_STUDIO_FFMPEG`. 2. Next to the app's executable, which is where Tauri installs sidecars. 3. `PATH`. `src-tauri/tauri.conf.json`, however, has no `bundle.externalBin`. So posters, joined Voice clips, master stamping and proxies all depend on whatever ffmpeg the user has on `PATH`. This shows in development too. A `PATH` ffmpeg without `libopenh264` fails two `studio-core` unit tests (`ffmpeg::tests::a_proxy_is_h264_at_a_short_side_of_768_with_the_masters_audio` and `ffmpeg::tests::a_proxy_of_a_small_master_keeps_its_size`) with `Unknown encoder 'libopenh264'`. This was seen while working on #116. Proxies need OpenH264 whenever NVENC is not usable (`ProxyEncoder`). Pick a prebuilt, unmodified LGPL ffmpeg for Windows x64 that has `libopenh264`, and NVENC (`h264_nvenc`) if possible. Fetch it at a pinned version with a checked hash, and bundle it under Tauri's sidecar naming (`ffmpeg-<target-triple>.exe`). Dev builds and tests should use the same binary, so local results don't depend on `PATH`. ## Acceptance criteria - [ ] A script (or build step) downloads the chosen LGPL build at a pinned version, checks its SHA-256 and places it at `src-tauri/binaries/ffmpeg-x86_64-pc-windows-msvc.exe`. The binary is gitignored, not committed. - [ ] `tauri.conf.json` lists it in `bundle.externalBin`, and a bundled build installs it next to the app's executable, where `Ffmpeg::locate` finds it without `AI_STUDIO_FFMPEG` or `PATH`. - [ ] `tauri dev` and `cargo test` use the fetched binary, for example by having the fetch step run first and `locate` (or the test helper) fall back to `src-tauri/binaries/`. The two proxy tests above pass on a machine whose `PATH` ffmpeg lacks `libopenh264`, or has no ffmpeg at all. - [ ] The chosen build is confirmed to have `libopenh264` (and NVENC if it has it), and `detect_proxy_encoder` still picks NVENC only when it works. - [ ] LGPL obligations are met for the shipped binary: the licence text and the build's source or build-recipe reference are included with the bundle (for example in a third-party notices file), and the build is used unmodified. - [ ] The README or the `run-ai-studio` skill says how to fetch the sidecar for development. ## Blocked by None.

crowmaki added the

enhancement

needs-triage

labels

2026-10-09 08:28:09 +00:00

crowmaki commented

2026-10-09 08:30:19 +00:00

Author

Owner

Use version: 9.0.2 from https://www.gyan.dev/ffmpeg/builds/

crowmaki referenced this issue from a commit

2026-10-09 08:53:51 +00:00