#Performance
Every number below comes from the project's own measurements. Each says what it was measured on. They have different dates, runtimes and methods, so do not add them together into one headline speedup.
#What has been measured
| Change | Result | How to read it |
|---|---|---|
| Rust DCT conversion + SIMD motion search | Mean encode time 10.78–13.91 ms became 5.41–7.60 ms | About 1.8–2.0× faster encode, with matching packet and reconstruction hashes |
| Full-video delivery after optimization | Mean 52–59 FPS on a 60 s clip | Server and receiver delivery, not browser render FPS |
| Bounded decode-ahead queue | Over-budget frames: 320 of 1845 without, 19 of 2742 with depth 3 | Separate runs on different scene coverage; not a controlled A/B |
| Decoder threads | Source work faster, encode slower | No demonstrated average end-to-end win |
At 60 FPS the per-frame budget is about 16.7 ms. A frame over budget is not necessarily a visibly dropped frame.
#Bandwidth
Raw pixel mode sends three bytes per cell plus a four-byte index. At 450×253 and 60 FPS that is about 20.5 MB/s.
In one live Rust + DCT session (59.94 FPS source, 464×256 grid, quality 70), the server reported roughly 20.9 MB/s raw versus 90–150 KB/s on the wire, about 140–219× less, while delivering 57–61 FPS. That excerpt covers a calm opening section. In the codec pilot, quality 70 ranged from about 168× (calm scenes) down to about 47× (high motion).
#Compared with standard codecs
In a small three-window pilot at 464×256, ASCILINE quality 70 averaged about 1.9 Mbit/s at 35.4 dB PSNR. Realtime VP9 and AV1 produced higher PSNR and SSIM at roughly half the payload. (H.264 there was OpenH264, not x264.)
That is the expected result, not a failure: ASCILINE is aiming at a programmable representation, not at out-compressing standard codecs. Hardware playback, energy use and broad content were not measured.
#Does it need a GPU?
No GPU is required for ASCII modes. On one Windows machine (Chrome 155, a 30 FPS clip, 200 columns, the default Python engine, 3 runs per setting):
- The server produces 30 FPS using about 0.17 CPU cores and no GPU.
- The player holds 30 FPS with Chrome's GPU switched off as well as on. Doing without it costs about 0.04 extra CPU cores.
That is not the same as "never touches the GPU": when one is available, Chrome draws the canvas on it, at 0.74% on average. Other systems, the Rust engine, color and pixel modes, and real low-power devices are not measured yet.
The full tables, method and scripts to repeat it are in GPU use in PERFORMANCE.md.
#What has been validated
A Windows checkout built with Python 3.11 and FFmpeg 8.1. The Python tests, npm test and the native Rust test passed, and we confirmed playback through the repository's own web player and the local SDK page.
That covers one machine and one client. It does not establish 60 FPS on every device, a Linux/macOS matrix, multi-client capacity or long-duration behavior.
#Measure your own session
Start the server with recording on:
python stream_server.py video.mp4 --engine rust --pixel --pixel-codec dct \
--cols 450 --fps 60 --no-thumbnails --decode-ahead 3 \
--perf-record experiments/rust_audit/output/playback
Watch normally, stop with Ctrl+C, then summarize:
python experiments/rust_audit/playback_report.py experiments/rust_audit/output/playback
The report separates source decode, encode, send time and client decode/draw, so you can see which stage is actually the bottleneck before changing anything. Tune one variable at a time, keep the tab in the foreground, and compare exact recordings.
Methods and raw results: PERFORMANCE.md and the codec benchmark.