590 seconds to 17: proving the fast path gives the same answers
In July 2026 the PeakClips pipeline spent about 25 minutes per source video deciding which candidate clips were worth cutting, and most of that time was spent decoding 4K video to look for nothing happening. One change brought the dead-air gate on a 24-minute 4K60 source from 590 s to 17 s. The speedup is the part people quote. The part I care about is the harness that had to pass before the flag was allowed on, and the rule it enforces: speed must never change a gate decision.
The gate, and why it was slow
The dead-air gate is a quality filter. For each candidate window of roughly a minute it samples frames at four per second, measures how long the longest run of "nothing happening" is, and drops the window if that run exceeds a threshold. Simple logic, expensive input: the sources were 4K60 AV1 downloads, because that is the only form the platform serves 4K in, and the gate decoded the full-resolution span for every candidate. Measured on 5 July 2026 on real footage: 66 to 82 seconds of wall time and 500 to 700 CPU-seconds per candidate, with decoding as about 90% of the cost.
Measure first: three fixes that were not
Before changing the design I benchmarked the obvious levers, and every one of them lost.
- Piping frames from FFmpeg instead of OpenCV was two times slower, not faster.
- Hardware AV1 decoding looked free on paper; the Apple media engine supports it. The static FFmpeg build in use silently fell back to software, and the timings came out identical. A flag that reports success while doing nothing is a trap worth naming.
- The object detector was already on the GPU at about 25 ms per frame with identical detections on every test clip. It was not the bottleneck, however much it looked like the expensive part.
Three measurements, three "no"s, half a day. Cheaper than shipping any of them.
The proxy, and the rule that made it allowed
The design that won was a 480p analysis proxy: download a small H.264 copy alongside the 4K source, run every visual analysis (dead air, framing, subject detection, tracking) on the proxy, and render the finals from the 4K. Paired with it, a one-pass feature timeline: scan the file once and answer every overlapping window from the same features, instead of re-decoding each window's overlap.
A proxy changes the pixels the gate sees, so it can change the gate's answer. That is the whole risk, and it is where most "optimisations" quietly become regressions. The rule I set for the work was that the fast path must reach identical decisions to the old one on real sources, and that the configuration flags stay off until that is proven. The rule is written into the configuration file next to the flags, so the next operator reads it before turning anything on.
The harness: two kinds of disagreement
tools/diff_gate.py takes a real source video and runs the gate over a grid of overlapping windows (60 s long, 45 s stride, the shape of real candidates) through four paths: the old per-span decode of the full file as ground truth, the timeline on the full file, the proxy per span, and proxy plus timeline, the configuration that would ship. Then it compares every verdict. The design decision that made the proxy safe is in how disagreements are classed:
- Strict (old says alive, fast says dead) is tolerable, because the pipeline re-judges every proxy "dead" verdict on the full-resolution file before acting on it. A strict disagreement costs one 4K probe and never changes the final decision. By construction, the fast path can only ever be as strict or stricter than the old one.
- Missed (old says dead, fast says alive) cannot be recovered, because an "alive" is trusted and nothing re-checks it. One missed drop fails the harness with a non-zero exit, and the flags stay off.
Windows whose dead run sits within two samples of the threshold are flagged for a human to eyeball even when the verdicts agree, because that is where any proxy will wobble first.
On the 24-minute source, 31 windows: the old path took 590.1 s, proxy plus timeline took 16.7 s, 30 verdicts were identical, one borderline window went strict and was escalated to the full file, and there were zero missed drops. The flags went on for that source class, in the same pull request as the harness, with the harness output in the record.
What the number is and is not
It is per source video, not per clip, and it is the dead-air gate alone; the whole gate phase on a full run went from about 10 minutes to 2 to 4 minutes. It was proven on one source class and not on a second. The honest version fits in one sentence, and I use that sentence rather than the bigger one it is often rounded up to.
Two sibling speedups from the same week were measured and rejected by the same discipline. A tracking proxy, for subject-following crops, failed its own harness: crop drift of 0.34 of a frame width on real footage, for a gain of about 1.1x, so the flag ships dormant. And the hardware video encoder, which won on local quality metrics at 36 times less CPU, lost 0.005 SSIM on caption edges after the platform's own transcode; every production clip is caption-heavy, so the software encoder stays and the evidence sits in a comment beside the setting.
The takeaway
A faster path is only an optimisation if you can prove it is never less strict than the thing it replaces. The way to make that provable is to design the fast path so that its only possible error is the recoverable kind, then build the harness that would catch the other kind, run it on real inputs, and refuse to ship until it passes. The 35x came from a 480p proxy. The confidence to turn it on came from diff_gate.py saying "no missed drops" on footage that mattered.