Recorded and included `.webm` examples of the high performance 1440p, HDR mode, and Pixel mode streams
then updated the markdown previews table to use these generated examples.
Added `--max-fps` flag to explicitly control max frame rate up to 120 FPS.
Introduced 1440p resolution support in `get_cols_from_res`.
Added Mode 6 to support 32M Colors with experimental HDR (display-p3).
Optimized CV2 capture and javascript buffer logic for live latency reduction.
Added yielding to Python async loop for high FPS encoding stability.
Updated README.md to represent these fork enhancements.
Added `--max-fps` flag to explicitly control max frame rate up to 120 FPS.
Introduced 1440p resolution support in `get_cols_from_res`.
Added Mode 6 to support 32M Colors with experimental HDR (display-p3).
Optimized CV2 capture and javascript buffer logic for live latency reduction.
Added yielding to Python async loop for high FPS encoding stability.
Updated README.md to represent these fork enhancements.
Added `--res` argument to both `stream_server.py` and `ascii_video_player2.py`
to easily set higher quality/density ASCII and pixel rendering.
The `res` argument maps `480p`, `720p`, and `1080p` presets
to appropriate column sizes (854, 1280, and 1920).
Updated `README.md` to document the new `--res` flag.
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.
The binary protocol re-sent the full grid every frame. This adds an opt-in
per-frame codec that picks the smallest of three encodings and tags it in a
1-byte header, without changing the rendered output:
0 RAW framebuffer as-is (legacy)
1 ZLIB zlib(framebuffer)
2 DELTA only the cells changed since the previous frame, patched on top
Clients opt in via /ws?codec=adaptive; omitting it yields the original protocol
byte-for-byte, so existing clients are unaffected. A keyframe is forced
periodically for resync. codec.js is shared by the browser and the Node test,
so the shipped decode path is the tested one.
Optional --quality {lossless,high,balanced,low} enables lossy temporal delta
(conditional replenishment): a colour cell is only re-sent once it drifts past a
tolerance from what the viewer already sees; the character plane stays exact.
Default lossless = bit-exact.
Measured wire savings (mode 5, 200x80): static screen 0.3% of legacy (~375x),
pixel mode 11.6%, high-motion 63% (never worse). Encoder tuned (zlib level 3,
smart candidate selection) to stay well under the frame budget.
Verified bit-exact two independent ways: Python->Node vectors and a live
adaptive-vs-legacy WebSocket diff. (A fuller mutation + Autobahn conformance
harness exists on request.)
