The libva guard fired: the release ffmpeg had no h264_vaapi. ffmpeg-sys-next
configures with --disable-autodetect and only passes --enable-vaapi when its
build-vaapi feature is set; ffmpeg-next 8.0 doesn't forward it, so installing
libva-dev alone did nothing.
Inject a direct ffmpeg-sys-next dependency with the build-vaapi feature
(Linux only) in both the GitHub Actions and container build paths. With it,
FFmpeg gets --enable-vaapi (and fails loudly if libva-dev is missing rather
than silently shipping software-only).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The Linux release ffmpeg is built statically from source, and ffmpeg only
autodetects --enable-vaapi when libva headers are present at configure time.
Neither build path installed them, so every release shipped a static ffmpeg
with no h264_vaapi encoder -- the zero-copy export silently fell back to
software 100% of the time.
- Containerfile + build.yml: install libva-dev + libdrm-dev so the from-source
ffmpeg gets VAAPI.
- build.yml: assert the release binary links libva, so a missing dep can't
silently regress to a software-only build again.
- deb/rpm: libva (libva2/libva-drm2/libdrm2, libva/libdrm) is a hard runtime
dep -- the vaapi-enabled ffmpeg DT_NEEDEDs it, so the app won't launch
without it. The VA driver is a soft recommends (absent it, export falls back
to software): va-driver-all (deb), intel-media-driver/mesa-va-drivers (rpm).
build.rs needs no change: releases link ffmpeg statically (its bundling path
is skipped) and the AppImage is thin, taking libva from the host like libvulkan.
The shipping product is the pure-Rust app in lightningbeam-ui/; the old
JavaScript UI in src/ is browser-only (window.__TAURI__ is shimmed by
src/tauri_polyfill.js), so the src-tauri Tauri backend is dead. It also no
longer compiled (mid-refactor: missing video_server module, handler list
referencing deleted commands), and CI only ever built lightningbeam-ui.
- Delete src-tauri/ entirely (commands, native renderer/render-window,
websocket frame streamers, Tauri config, generated schemas, icons).
- Relocate icon.icns into lightningbeam-ui/lightningbeam-editor/assets/icons/
(the only src-tauri asset still needed) and repoint the editor's window-icon
include_bytes! at assets/icons/256x256.png (was src-tauri/icons/icon.png).
- CI/packaging: drop the redundant icon-copy steps (PNGs are committed in the
editor assets) and point macOS bundling at the relocated icns.
- package.json: drop @tauri-apps/* deps and the tauri script.
- Docs/.gitignore: drop src-tauri references.
daw-backend/ (shared audio engine) and the top-level WASM lightningbeam-core/
are untouched. Editor builds clean.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
cmake-rs 0.1.54 panics with "unsupported or unknown VisualStudio version: 18.0"
because the windows-latest runner now ships Visual Studio 18 (2026), which the
crate's VS-generator detection doesn't recognize.
Install Ninja and set CMAKE_GENERATOR=Ninja for the Windows build so the cmake
crate skips VS-version detection and drives cl.exe (from the active MSVC env)
directly. build.rs already searches the single-config (non-Release) output dirs,
so no linking changes are needed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Git for Windows puts its usr\bin on PATH ahead of the MSVC tools, so under
Git Bash rustc picked up coreutils link.exe instead of MSVC link.exe and
every link (even host build scripts like proc-macro2/serde) failed with
"/usr/bin/link: extra operand".
Split the build step: non-Windows keeps the bash script (needs --target
handling); Windows builds under pwsh, where the MSVC environment from
msvc-dev-cmd stays at the front of PATH.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The cmake crate building nam-ffi/NeuralAudio panicked with "couldn't determine
visual studio generator" because the Windows job never ran vcvars, so
cmake-rs had no VisualStudioVersion to detect the VS generator from.
Add an ilammy/msvc-dev-cmd step (x64) after the Windows dependency install; it
runs vcvars and exports the env to later steps so the C++ build can configure.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Skyler Lehmkuhl