PR #16 merged: feat(capture): live camera.proxy.mp4 — pack-sized analysis copy (#13)
What
Closes #13. (Supersedes #15, which GitHub auto-closed when its stacked base branch was deleted on merging #14.)
Each camera now runs two writers fed the same sample buffers: the full-res master and an 854x480 @ 600 kbps camera.proxy.mp4. Written live during recording — no post-stop transcode, so manifest.json (the finalization signal for the app and roll-push) still lands instantly, and the proxy's PTS are identical to the master's (cameraSyncOffsetMs applies unchanged).
CamWriterhelper wraps the writer+input pair; bothCameraRecorder(one-shot) andCameraStation(serve daemon) run master+proxy through it.- Proxy failure is non-fatal: logged, take continues,
manifest.camera.proxyomitted. manifest.camera.proxy = {file, w, h, bitrate}; schema updated; sidecar → 0.0.16.- 600 kbps rather than the issue's 0.8–1.2 Mbps: the issue's own 25–35MB size target implies ~0.6 Mbps (1.0 Mbps × 455s ≈ 57MB would risk the cap).
Verified (real takes, Green Machine continuity cam)
| path | camera.mp4 | camera.proxy.mp4 |
|---|---|---|
one-shot --screen | 1920x1080 @ 6.04 Mbps, 360 frames | 854x480 @ 0.59 Mbps, 360 frames, same duration |
--serve daemon (app path) | 1920x1080 @ 6.07 Mbps, 337 frames | 854x480 @ 0.60 Mbps, 337 frames, same duration |
Proxy extrapolates to ~34MB per 7.5-min take → pack archive lands under the 100MB cap. Both manifests validate against pack.schema.json (ajv, draft 2020-12).
Downstream note
The /pack archive builder (sandbox/crunch side) should ship camera.proxy.mp4 instead of camera.mp4 when manifest.camera.proxy is present. roll-push.sh needs no change — it mirrors the whole take dir, so edator keeps the full-res master.
🤖 Generated with Claude Code