If you are building programmable video, at some point you stop arguing about timelines in the abstract and confront a duller problem: something has to paint the frames. Not a marketing-site screenshot, but a composition surface that respects timed layers, fonts, shaders, and motion that is supposed to match what the editor showed — and then hand those frames to an encoder. Chrome-class browsers are good at that work. They are also good at failing in ways that look healthy from a distance: out-of-memory kills, GPU process flaps, hung tabs, contexts that still answer a ping while painting black.
At SceneRok we treat video as source code. Agents and humans author VidScript or build timelines through @scenerok/sdk; generative calls can resolve at compile time; a compiler owns structure so the same inputs produce the same edit. None of that removes the need to draw. This piece is about the pool patterns that sit under preview and final render when the drawer is a real browser. I am sticking to patterns on purpose. You will not get an inventory of our pipes, pool sizes, or host topology — those go stale, and they are not the interesting part anyway.
Why keep browsers warm
The clean mental model is one browser per job: launch, load the scene, capture, kill. It is clean until every request pays cold start — process bring-up, profile init, GPU or software raster path, fonts, first paint — before anyone can answer "does this cut look right?" For agent-authored video that question is the product loop. People and agents iterate; if each scrub feels like waiting for a machine to boot, they stop iterating.
So you keep browsers warm. Warmth buys launch cost and introduces a harder problem: a warm browser is shared, privileged, and sticky with state. The design question is how to reuse it without yesterday's job leaking into today's.
Isolation before clever reuse
Slowness is annoying. Cross-job leakage is worse. Cookies, cached media, service workers, localStorage from another tenant, a WebGL context that never quite recovered — any of that quietly destroys the reproducibility story you sold when you said the edit was deterministic.
In practice that means one job gets one logical browser context, preferably a fresh profile or a hard reset rather than another tab on a shared profile, because tabs share more than people remember. It also means you should not trust the page's ready events alone; they fire early. Paint something you control, check a pixel or DOM invariant you understand, and only then start the capture clock. Teardown is the same story in reverse: graceful close is nice when the renderer is healthy, and useless when it is wedged, so hard kill with a timeout is part of the design, not an embarrassment. Media caches deserve the same suspicion. Prefetch helps performance and also smuggles assets across scenes unless you scope or wipe them between leases.
People hear "isolation" and think security review. For programmable video it is also correctness. If the pool leaks state, you are debugging ghosts while claiming the compiler is deterministic.
Leases, not immortal workers
A warm pool is not a promise that a browser lives forever. Treat reuse as a lease: take a browser that passed the last health check, bind it to a job id and a wall-clock deadline, run capture inside that deadline, and release it only after reset succeeds — otherwise quarantine it.
Quarantine is the part operators skip when they are optimistic. A browser that crashed mid-encode, blew GPU memory, or spent too long in "almost done" should not return to the hot set because someone hopes the next job will be fine. Mark it sick, bring up a cold replacement, and watch how often that happens. Quarantine rate tells you more about pool health than average frame time.
Even when preview and final share code paths, their policies should differ. Preview exists for latency and representative fidelity; final exists for pixel honesty and encode quality. If you shove both intents through one undifferentiated queue, you get slow iteration for people who are exploring and flaky masters for people who are shipping.
Budgets instead of hope
In browser capture, timeouts are not a config afterthought. They are how you keep a hung GPU path from owning the machine. You want stacked budgets: how long you wait to acquire a healthy browser, how long load may take, how long until first meaningful frame, how long the stream may stall once it has started, and a hard ceiling so nothing runs forever because a 4K job is "almost finished."
When a budget trips, recovery should be boring. Abort, record a high-level reason code (not a memory dump in a blog post), recycle the browser, and retry automatically only when the failure class looks like a transient worker problem. A bad scene input and a poisoned warm worker are not the same event. Retrying everything without classification is a good way to amplify an outage.
Crashes you can see vs crashes you ship
Browsers crash. GPU subprocesses disappear while the parent still looks fine. If supervision only asks whether the top process is alive, you will eventually ship black frames with a green health check.
What holds up in practice is a heartbeat on meaningful progress — frames actually produced — and a watchdog that does not live inside the stuck capture loop. After a crash, quarantine and replace cold rather than hot-patching a mystery. Jobs should be restartable under the same id from a known checkpoint when you have one, so a mid-flight failure does not force you to pretend the whole creative pipeline never ran.
That last point matters more for SceneRok than for a pure compositor. Generative assets can already be resolved and stored at compile time; composition happens after. A browser dying during frame capture should not automatically re-roll every model call if the compile artifacts are durable. Keeping those stages separate is reliability and cost control at once.
Hardware paint vs software paint
Headless Chrome will paint without a real GPU, usually through software rasterization. That path is useful in constrained environments and expensive for motion-heavy scenes. Preview can bias toward speed if timeline timing stays honest. Final should bias toward the path that matches creative intent, and if you silently fall back from hardware acceleration, say so — capability detection beats wishing. Preview and final are not identical pipelines; say which one is representative and which one is authoritative, and treat silent disagreement on opacity, font hinting, or blend modes as a product bug waiting for a brand review.
Same source, different job
Programmable video only works if one source drives both experiences. For us that is VidScript or the SDK compiling to the same intermediate timeline; the browser pool is machinery behind that contract. Preview's job is fast feedback and clear failure. Final's job is delivery quality, transient retries where they help, and a clear stop when they do not. If every request is treated like a master, agents cannot explore. If every request is treated like a disposable sketch, clients cannot ship. The lease has to carry intent.
What we actually watch, without dressing it up as a benchmark post, is acquire latency people feel in the editor, crashes users never see because quarantine worked, and whether preview timing still agrees with final timing. Pool sizes and frame-time charts do not belong here; they rot.
Closing
A reliable browser pool is not "Chrome on a server." It is careful reuse of crashy, GPU-adjacent work: isolate per job, warm without lying to yourself about state, put real budgets on every stage, quarantine sickness, and keep preview and final as different contracts over the same creative source.
That is how programmable video starts to feel like software — people and agents iterating on code — instead of a cold boot every time someone scrubs the timeline.
If you want the product side of this (editor, CLI, agents writing VidScript), start at scenerok.com. The pool should stay boring. The videos should not.
Top comments (0)