The live WebSocket pushed every frame on a wall-clock schedule regardless of
whether the client could keep up. On a slow device frames piled into the client
decode queue, and the client paid the inflate+delta-patch cost for each one
before dropping the excess in its render loop. CPU spent on frames never shown.
Client now reports its decoded-frame backlog (frameBuffer depth) ~4x/sec over
the existing command channel. When the backlog exceeds BACKLOG_HIGH the server
skips frames: it advances the source cheaply (grab, no decode/encode/send) so
video stays time-aligned with audio, and crucially holds prev_frame across the
gap so the next sent frame is a correct delta against the last SENT frame. No
keyframe resync needed - deltas are always relative to the last sent frame.
MAX_CONSEC_DROPS caps the gap and guarantees liveness for slow/non-reporting
clients. Fully backward compatible: a client that never reports keeps backlog=0
and behaviour is unchanged.
test/test_backpressure_gap.js encodes a keyframe + a dropped gap via codec.py
and decodes through the shipped codec.js, asserting the post-gap frame is
reconstructed bit-exact (and is a real DELTA), matching the no-drop path.
Builds on the existing live seek/play/volume. Adds a polished, responsive control bar with play/pause, +/-10s skip, a played-progress fill, and a YouTube-style hover thumbnail preview on the seek bar. Thumbnails come from a small lazy /scrub endpoint that builds an in-memory sprite once per video with a single ffmpeg pass (no disk cache); easy to point at the static compiler's sprite instead.
Cold-start root cause: on a slow first load the <audio> element starts late, so
the audio-ready gate's wall-clock fallback has already advanced playback a second
or two by the time audio finally begins at currentTime≈0. The master clock then
snapped back toward 0, every buffered frame read as "in the future", and
renderFrame() deadlocked until audio caught up — the freeze. A refresh warms the
cache, audio starts immediately, the gap (and the freeze) vanish — which is why
reloading "fixes" it.
Fix: the first time audio is genuinely playing, capture the offset between the
wall clock and the audio clock and add it back, so the master clock follows
audio's *rate* without ever moving backward. When audio starts promptly the
offset is ~0, so normal playback is unchanged.
experiments/freeze_repro.js models a 2s-late audio start with a realistic jitter
buffer + 60fps render loop: the original code and a naive `currentTime > 0` guard
render 0-1 of ~96 frames after audio starts (frozen ~4s); the anchored clock
renders 96/96 smooth. Real-browser regression (muted Chrome): normal playback
unaffected at ~29 fps.
