Session 2 reversed several of its own conclusions. The docs are append-only, so a reader could land on a superseded section and act on it. This pass makes the repo internally consistent. Defects found and fixed in STATUS.md: - claimed "Hybrid VQ with k=1024: no" as the answer to the linework question, directly contradicting FINDINGS 14, which rejected k=1024. Both profiles are k=256. - malformed profile table (six column separators, five columns). - next-steps list had two items numbered 3 and listed the full-disc survey twice. - the disk-benchmark section still read CRITICAL-PATH with "if SCSI sustains >=800 KB/s, ship pixel-exact". That was written while the bandwidth figure was misread as 4 MB/s. At 4 Mbps pixel-exact needs 92-97% of the pipe and is not available, and the ring-buffer result means the design no longer hangs on the benchmark at all. Rewritten with what it IS still worth doing: confirming the 4 Mbps provenance, and confirming DMA is used rather than PIO. FINDINGS now carries supersession blockquotes on 5, 8, 11, 17 and 18 pointing at the sections that correct them. 18 is the dangerous one -- its peak-vs- sustained test is reversed by 21 -- so it is marked DO NOT ACT ON THIS SECTION while noting the per-frame data itself remains valid. profile_gen.py had the same problem in code: it defaulted to the superseded peak sizing and returned lam=25 where the docs say lam=10. The buffered test is now the default and peak sizing is behind --size-for-peak as a bound only. A tool that contradicts the findings is worse than no tool. Also preserves the five measurement scripts that produced this session's numbers as tools/analysis/05-09, following the session 1 precedent, and adds an "explicitly abandoned -- do not re-propose" list to STATUS covering entropy coding, k=1024 codebooks and flat 4x4 VQ. Claude-Session: https://claude.ai/code/session_01194oWYW8DQXK1SZ2DnChW6
19 lines
1008 B
Python
19 lines
1008 B
Python
"""At a 488 KB/s (4 Mbps) ceiling and ~52% mean utilisation, the mean is not the
|
|
risk -- the peaks are. Measure per-frame peak-to-mean, then check whether the
|
|
leaky-bucket rate controller actually holds the ceiling."""
|
|
import sys; sys.path.insert(0,'tools/encoder')
|
|
import vq_hybrid as H, ratectl as RC, numpy as np
|
|
S=sys.argv[1]
|
|
BW=4_000_000/8/1024
|
|
print(f"ceiling {BW:.0f} KB/s (4 Mbps), audio {RC.AUDIO_KBPS} KB/s\n")
|
|
print(f'{"scene":8}{"lam":>5}{"mean":>8}{"p90":>8}{"MAX":>8}{"pk/mean":>9}{"MAX % of pipe":>15}',flush=True)
|
|
for s in ['00010','00020','00146','00181']:
|
|
m=H.build(f'{S}/fr_{s}',k1=256,k4=256,iters=16)
|
|
for lam in [60.,10.]:
|
|
e=H.encode(m,lam=lam)
|
|
kb=e['sizes']*12/1024 # per-frame instantaneous KB/s
|
|
tot=kb+RC.AUDIO_KBPS
|
|
print(f'{s:8}{lam:5.0f}{tot.mean():8.1f}{np.percentile(tot,90):8.1f}'
|
|
f'{tot.max():8.1f}{tot.max()/tot.mean():9.2f}{tot.max()/BW*100:14.1f}%'
|
|
+ (' OVER' if tot.max()>BW else ''),flush=True)
|