What happened
PhoonoS transcodes on cloud workers whose CPU is limited the way a container platform limits it. The obvious fix for a job that did not fit its deadline was more CPU. Before buying it, it was measured — 60 seconds of a video podcast at 240p, CPU capped by Docker to match production:
| Encoder | 2 vCPU | 8 vCPU | Speed-up |
|---|---|---|---|
| SVT-AV1, preset 4 | 37 s | 23 s | 1.61× |
x265, slow | 17 s | 16 s | 1.06× |
Four times the CPU made x265 six percent faster.
Why
At 240p a frame has very few coding-tree rows to hand to parallel threads. The encoder's internal parallelism has nothing to distribute. The sublinear scaling one usually assumes — something like (cores/2)^0.75, which would predict 2.8× — was not merely optimistic; it was irrelevant at this resolution.
Where the parallelism actually was
Between jobs, not within one: run several encodes at once on a smaller worker each, rather than one encode on a big worker. Same total CPU, several times the throughput — and cheaper.
The rule
Before raising a worker's CPU, measure whether the workload will use it. For encoders at low resolution the answer is almost always no. The decision "add cores so it fits the deadline" looks obvious and may buy nothing.
Applied elsewhere
EmpoorioChain's parallel-execution engine tunes its thread pool to the validator's core count — and its report is careful to label throughput figures as projections until measured on the reference machine, because this note is exactly how projections go wrong.
From the PhoonoS media-pipeline work, 2026-08-23.