asepharyana
add31d3561
Root cause (3rd iteration): ffmpeg '-re' on the demuxer does NOT reliably throttle a multi-stage live pipe (merge ffmpeg -> encoder x264 -> NUT -> demuxer). In production the demuxer still emitted ~240fps while the WebRTC sender consumed 30fps, building a 100k+ frame backlog (observed: frames=197490 vs sent #24600, ~8.4 min in). The sender always emitted the OLDEST buffered frame -> video frozen ~10 min behind live, while audio (tiny, jitter-buffer recovered) stayed smooth. Local file/pipe tests showed -re working (30fps) but the live YouTube/WebM pipeline did not — -re is not trustworthy here. Fix: enforce 1x video output with a token-bucket limiter in the demuxer (Node side), independent of ffmpeg. Capacity = 1s of frames, refill 1 token per 1000/fps ms. Surplus non-key frames are DROPPED (never buffered) so the sender always emits the newest frame; keyframes are forced through even over budget so the decoder keeps a fresh IDR. The limiter does NOT stall the ffmpeg process (unlike the earlier proc.stdout pause), so audio on fd3 keeps flowing. Verified: tsc --noEmit clean.