How Velora AI Studio's Parallel Scene Renderer Handles 1,000+ Videos Simultaneously

The Scalability Challenge

When a creator generates a 5-minute Autopilot video on Velora AI Studio, they're not generating one thing. They're generating a script, voiceover audio, background music, 15–30 individual video clips, subtitle overlays, and the final composite render — all in sequence, all assembled into a single polished video. At 1,000 concurrent users, the naive approach (process each video end-to-end, one step at a time) collapses immediately.

Early versions of our render pipeline did exactly that. A 5-minute video took 8–12 minutes to generate, users could see their position in a queue, and peak-hour congestion was a real pain point. We needed a fundamentally different architecture.

The Parallel Scene Graph

The core insight behind our new engine is that a video is a directed acyclic graph (DAG) of dependencies — not a linear pipeline. Scene 3 does not need to wait for Scene 2 to finish if they don't share assets. Voiceover synthesis for Scene 5 can happen simultaneously with B-roll generation for Scene 2. The final composite render is the only step that genuinely requires everything to be complete.

We modeled the entire generation pipeline as a DAG. Each node in the graph is an atomic work unit — one clip generation, one TTS call, one subtitle render, one music segment. Our scheduler analyzes the dependency graph of each incoming job and dispatches all leaf nodes (nodes with no unresolved dependencies) simultaneously across our worker pool.

• →
  Phase 1 — Script Generation: LLM call produces the full script JSON with scene breakdowns. This is sequential because every subsequent step depends on it. Takes ~3s.
• →
  Phase 2 — Parallel Asset Generation: All TTS calls, all clip generations, and music generation fire simultaneously. A 10-scene video now takes as long as the slowest single clip — not the sum of all clips.
• →
  Phase 3 — Subtitle Processing: Word-level timestamps from the TTS engine are processed in parallel with asset generation. Ready the moment Phase 2 completes.
• →
  Phase 4 — Composite Assembly: Our FFmpeg-based assembly layer receives all assets and compiles the final video. Takes ~20–40s depending on resolution.

The Job Queue Architecture

Underlying the scheduler is a distributed job queue built on Redis-backed BullMQ. Every atomic work unit becomes a job in a typed queue (video-gen, tts, music-gen, subtitle, composite). Workers are horizontally scaled containers, each specialized for a subset of job types. Video generation workers carry GPU-adjacent logic and API clients for Kling, Veo 3, and Sora. TTS workers handle the ElevenLabs and Minimax voice synthesis streams.

The parent job coordinates everything through a job completion callback system. When a child job (e.g., Scene 7's clip) finishes, it emits a completion event. The parent job's coordinator checks whether all siblings are complete. The moment the last dependency resolves, the composite job is auto-enqueued without any polling delay.

Smart Frame Caching

The final piece of the engine is our frame cache. If two different creators request a clip with near-identical prompts (e.g., "aerial view of a city at sunset, cinematic"), generating two separate clips is wasteful. Our semantic cache uses vector embeddings of prompts. Before dispatching a generation job, the system checks if a sufficiently similar clip already exists in our shared asset store (cosine similarity >0.92 threshold). If a match is found, the cached clip is reused, shaving seconds off the generation time for that scene.

Combined, these optimizations — parallel DAG scheduling, typed worker pools, event-driven coordination, and semantic frame caching — are what give us the 40% render time reduction compared to our previous sequential engine. And because the architecture is horizontally scalable, capacity grows linearly with added workers: 1,000 concurrent jobs today, 10,000 tomorrow.