7b8b6bcd0cf01d18e0efe306c07c7cdd37f4293d
The previous ffmpeg-as-HTTP-server pipeline shape held back two improvements at once. ffmpeg as the runtime server lost a one-shot `-listen 1` accept to a probe-and-discard health check, and forced us to size analyze/probe budgets carefully so ffmpeg would serve before our deadline. Replacing it with a small tokio task that accepts once, drains the HTTP request, writes a fixed 200 OK, then `tokio::io::copy`s gst stdout to the socket removes all of that. VAAPI H.264 (vah264enc) drops CPU encode from ~50% of a core to single-digit %. An earlier attempt at vaav1enc had to be abandoned: libavformat cannot demux AV1-in-MPEG-TS with the custom mapping even with a 20MB probe budget — mpv reports video=eof. H.264 keeps the hardware win on the well-trodden demuxer path. scripts/smoke-pipeline.sh mirrors the runtime pipeline with videotestsrc/audiotestsrc into a file and asserts that mpv reports `video=playing` (not video=eof). The naive --frames=10 check was a false positive when no video stream is recognized; the verbose grep is the real gate. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Description
No description provided
Languages
Rust
97.6%
Shell
2.4%