# Castin Tauri Tools

Windows builds use the tracked `ffmpeg.exe` in this directory so download
recording, thumbnails, and FLV playback work without a user-installed
dependency after a clean checkout. If the selected ffmpeg build ships adjacent
runtime DLLs, those DLLs must live beside `ffmpeg.exe` in this directory.

The committed Windows binary is `ffmpeg version
6.1.1-essentials_build-www.gyan.dev`. It reports GPL/version3 configuration, so
redistribution and Store packaging must comply with FFmpeg's license terms.

For local development on non-Windows platforms, place the platform ffmpeg binary
in this directory manually, along with any adjacent runtime libraries it needs.
Those local non-Windows binaries remain ignored by git. Runtime app code
resolves ffmpeg only from Tauri bundled resources and does not use `ffmpeg` from
the user's `PATH`.
On Windows, `npm run prepare:ffmpeg:windows` can still refresh `ffmpeg.exe` from
Chocolatey or another explicit `-FfmpegPath` when intentionally replacing the
tracked binary.
Run `npm run verify:ffmpeg` from `Castin-Tauri/` before packaging to confirm the
bundled binary can execute by explicit path and is portable enough for release.
Use `npm run verify:ffmpeg:local` only when intentionally validating a local
developer-machine binary.

Do not ship a macOS Homebrew copy directly unless its dylib dependencies are
also bundled and its install names are rewritten. Prefer a self-contained
release ffmpeg binary for distributable macOS Tauri packages; release
verification fails by default when Homebrew dylib paths are detected. On macOS,
`npm run prepare:ffmpeg:macos` can copy the non-system dylib closure into
`Tools/lib/` and rewrite install names to bundle-relative paths. After building
the macOS app bundle, run `npm run verify:ffmpeg:macos-app` to verify the copied
`Contents/Resources/Tools` layout, not just the source `Tools` directory.
Keep `Tools/lib/.gitkeep` tracked so Tauri's resource glob has a stable
directory on Windows builds even when no macOS dylibs are present. Real dylibs in
`Tools/lib/` remain local generated artifacts and are ignored by git.
