Skip to main content
View as Markdown

How it works

Two properties explain most of Decodx's behaviour. Both are worth understanding, because they change how you work.

The pipeline​

A render moves through stages: material is captured or ingested, scenes are planned, narration is generated, scenes are produced, the video is stitched, checked, transcoded, and the poster and document are emitted.

Each stage takes the previous stage's output and produces a well-defined artifact. Nothing later in the pipeline reaches backwards.

The same project renders the same video​

Rendering is deterministic: given the same project and the same source material, Decodx produces the same output. There is no model improvising in the render loop — language models help you draft a script or a document, and once that text exists it is fixed input like anything else.

Practically: re-rendering to check something is safe. You will not get a subtly different video.

Why re-renders are nearly free​

Every expensive artifact is identified by the content that produced it. Narration audio is keyed to the exact line and voice; an avatar clip to its exact script and identity; a produced scene to its exact inputs.

When you re-render, Decodx recomputes those keys. Anything whose inputs are unchanged is reused as-is. Only what genuinely changed is re-made.

So editing one narration line in a twelve-scene video re-generates one line of audio and re-produces one scene. The other eleven are reused. That is why the estimate collapses on a re-render — and why keeping a library current is affordable at all.

What invalidates a cache entry: changing the text, the voice, the avatar, or the source material a scene depends on. Reordering scenes does not. Changing project-level settings that affect every scene — the aspect ratio, the brand watermark — will re-produce every scene, which is why a high estimate on a small edit usually means a project-level setting moved.

The cost model​

External providers do the expensive work; Decodx orchestrates them. That's why costs are shown as estimates before a job runs rather than hidden behind credits — the numbers are real, and the cache is what makes them small.