The code was correct. It had just never run on a real machine. Basil Yusuf had written Mecka AI’s new encode path for dedicated video-transcoding ASICs, chips built for one narrow job, and on paper it worked. Then it met production video. A slight jitter in the frame rate, 60.001 frames per second where the pipeline expected a flat 60, kicked the job onto a fallback route, into a software encoder that the ASIC-patched ffmpeg builds switch off. The failure on screen was one line: Unrecognized option ‘crf’.
That was the small problem. The larger one showed up in memory. The pattern production used for multi-segment jobs ran out of room at 24 gigabytes the moment two ASIC encoder sessions shared one process. Run one session at a time and the numbers turned ugly the other way: 770 seconds against 213 for the chunked path. Single-process parallelism, the thing the whole design leaned on, was dead on this hardware.
Both failures pointed the same way. The chips were not refusing the work. They were refusing the assumptions the pipeline carried in with it, written years earlier for hardware with room to spare.
Most engineers would have read all this as a verdict on the chips. The field’s view of video infrastructure fits in one sentence: buy more GPUs. Yusuf, who came to Mecka in March from Google and went straight at the company’s largest cost, drew the opposite lesson. The pipeline, not the hardware, was built wrong.
Mecka turns first-person video of human work, hours of cooking and cleaning and assembly filmed by paid contributors, into training data for robots, which means its margins ride on the cost of processing video at scale. GPUs do that work across the field by default, less because they suit encode-heavy jobs than because they are already racked and already understood. The dedicated ASICs promised a far cheaper path. The catch was that no ordinary pipeline ran on them untouched. Standard encoders assume room to hold long runs of frames and lean on codec features the chips do not offer, so a pipeline tuned for general-purpose hardware shows up making promises the ASICs refuse to keep.
So Yusuf built one that did not. His path splits incoming video into chunks and re-encodes each with a GOP-1 structure, in which every frame stands alone instead of leaning on its neighbors, which sidesteps the chips’ memory limits. A second stage re-encodes the result in a single decode pass, through a re-encoder he wrote himself in Zig, a young systems language better known from hobbyist forums than production pipelines. Why Zig? “I needed deterministic memory behavior in a hot loop processing petabytes,” he said. “Zig gives you C-level control with none of C’s footguns, and the code stays readable. That’s the whole reason.”
The choice carried an irony he sat with. The Zig community is famously wary of AI-assisted coding, so he bet the company’s encode path on a language whose culture pushes against the way most of the industry now writes software. Production video systems run on C and C++ by long habit. Staking a company’s pipeline on a language that has not reached its 1.0 release is either nerve or recklessness, and only production settles which.
Production settled it. A validated run clocked 53.9 seconds where the GPU path’s p99 sat at 157, with no frame mismatches.
Then came the part Yusuf calls the actual point. A cheaper path that engineers have to remember to pick is a demo. A path the platform picks on its own is an architecture. He built an autoscaler that treats the ASIC route as cost-primary and general-purpose GPU capacity as automatic spillover on one shared queue. New jobs flow to the cheap hardware first and spill to the costly hardware only when they must. The migration stopped being a project and became the default.
The spillover design also answers the fragility worry before anyone raises it. If the custom path degrades or the chips saturate, jobs overflow to GPUs on their own and the pipeline keeps moving. The exotic hardware is a cost saving, never a single point of failure, which is the line between betting the company on new chips and arranging to profit from them.
There is a broader argument folded into the engineering, and Yusuf makes it without much prompting: the field treats hardware choice as procurement when it should treat it as design. “GPU-first is the default because it’s easy, not because it’s right,” he said. “Everyone treats the hardware as a fixed fact and optimizes the software above it. The hardware is a design surface like everything else.”
The counterargument writes itself, and he has heard it. Custom paths are brittle, turnover erases the knowledge that built them, and the GPU tax is the price of tools everyone understands. His answer is that at petabyte scale the tax compounds until it is the business. The case for the custom path rests on volume, and he does not pretend otherwise. A team processing a few hundred hours a month should keep buying the easy thing.
Somewhere in Mecka’s racks, hours of people cooking and cleaning and assembling stream through an encode path that did not exist at the start of this year, written partly in a language most of the industry has never shipped, on chips the field called the wrong shape for the job. Asked what he would tell a team stuck on the GPU default, he laughed. “Check what you’re actually paying for the easy path. Then decide if it’s still easy.”
