ffmpeg -i input.mov -c:v hap -format hap_alpha -c:a copy output.mov
The two go-to alpha formats both software-decode in OBS. VP9 alpha is forced to CPU by design because the "alpha plane" is actually a second VP9 stream packed into the WebM container that hardware decoders can't see as one job. ProRes 4444 has no GPU decode block on any consumer GPU, so every one of its ~330 Mbps gets touched on a CPU thread. And OBS's stats panel only counts encoder/compositor/network drops, not Media Source decode stalls... so the panel stays green while the overlay visibly stutters.
HAP sidesteps the whole problem because frames are stored pre-encoded as DXT5/BC3 GPU textures — no DCT, no entropy decode, no motion compensation. Decode collapses to disk read → Snappy decompress → texture upload, ~10–100× cheaper than DCT codecs, and file size drops to ~200–250 Mbps vs ProRes's ~330.
This looks to be the only efficient high quality alpha format in OBS right now. I'd much rather do VP9 because of the filesize, but unless the alpha plane can be made visible to hardware decoders, it's not a viable option for super-high quality super-high alpha real-time playback in OBS.
References:
- obs-studio PR #2048 — https://github.com/obsproject/obs-studio/pull/2048
- Vidvox HAP video specification — https://github.com/Vidvox/hap/blob/master/documentation/HapVideoDRAFT.md
- OBS forum on what the Stats panel actually counts — https://obsproject.com/forum/threads/dropped-fra mes-network-vs-frames-missed-due-to-redering-log-vs-skipped-frames-due-to-encoding-log.144181/