Reel pipeline — compute report

Compared against the FINISHED CLIPS table that came with the brief — the other machine's run of the same ten reels. Its wall-clock column is derived (CPU time ÷ average cores), everything else is read straight off it.

Throughput — a dead heat.

Cores burned to get it — 3.5× apart.

CPU per delivered frame — 3.6× apart.

The DGX did not win. Same ten reels, same 317 seconds of video, same wall clock (914 s vs 907 s) — while spending 3.6× the CPU to get there. A 20-core workstation and a laptop tie, because the pipeline is serialised: throughput is set by one ffmpeg at a time, not by how many cores are available.

Two explanations fit the 3.6×, and the brief's screenshot can't distinguish them: (a) the MacBook run encodes in hardware (VideoToolbox), which drops CPU while leaving wall clock alone — consistent with its 1.15 Wh and 2.35 cores; or (b) the MacBook pipeline doesn't do the triple encode. Note that (b) would be almost exactly the 3.1× measured here for collapsing three encodes into one. Either way it points at the same fix. The test that settles it: ask that session for its ffmpeg command lines, or run stageprof.py there.

Caveats worth keeping: the per-clip durations derived from the screenshot (18.5–42.9 s) only roughly overlap the ones measured here (25.2–40.7 s), so the row-to-row mapping is unknown even though the totals agree to 0.03 %. And if that run counted only its parent process rather than every ffmpeg child, the 3.6× is an artifact — though its 2.6–6.3 peak-core column says it was counting children.

Speed = finished frames (25 fps) per second of wall clock. There is no Energy column because this box exposes no energy counter — no RAPL, no powercap, no hwmon energy sensor; nvidia-smi reports GPU power only. CPU-seconds stands in for it.

Clip 01, every ffmpeg call and Python stage timed separately. Encoding is 95 % of it, spread over three generations of the same picture. The text raster is small in CPU but runs at exactly 1.00 core, so it costs ~20 % of the wall clock with 19 cores parked.

The full track is the whole machine. Peak process count across all ten builds was 2: one Python driver and one ffmpeg. Nothing in the pipeline ever runs two things at once.

Same 30 s of source. The fused graph — cut, grade, concat, speed and delivery encode in one ffmpeg — uses 3.1× less CPU, half the wall clock, writes a 28 % smaller file, and scores better against a lossless reference (SSIM 0.98305 vs 0.98241).

Transcription is the largest single compute item in the system: 2.43 CPU-hours per talk, more than all ten renders put together. It runs large-v3 int8 on the CPU as 14 workers × 3 threads — 42 threads on 20 cores — holding 4.53 GB each, ~63 GB resident. Measured: one 4.6-minute chunk costs 180 s wall and 625 s CPU alone. Perfectly packed that is 7.3 minutes per talk; the production run took ~32. Raising cpu_threads to 20 made it far worse — killed at 22 minutes, unfinished, after 8 500 CPU-seconds.

≈ 51 CPU-hours of work against 480 core-hours a day available — about 11 % of the machine, stretched across 8.8 hours because almost nothing runs in parallel. The constraint is the code, not the hardware. The right-hand column is a projection composed from measured factors, not an end-to-end run. What breaks first at 100/day is human review, then ASR memory on anything smaller than this box, then storage at ~28 GB of source per day.

Orange steps are the ones that cost. Nothing in this chain touches the GPU — NVDEC and NVENC are both present in the ffmpeg build and both unused.

Everything behind this page, including the measurement harness — run measure.py on the MacBook and the two sides become the same instrument.