The Last Mile: Rendering, Encoding, and Fallbacks

Recordly's export stage is where a project description becomes a file another person can watch. The important question is not simply which codec is selected, but how a source frame moves through decoding, scene rendering, encoding, audio processing, muxing, and saving—and how the application chooses a different route when a machine or a visual feature does not fit the fastest path. Following that pipeline lets readers distinguish a performance choice from a fidelity compromise and diagnose an export problem without treating the export button as a black box.

Export is a resource-managed pipeline

Recordly's modern MP4 exporter begins with source metadata and an effective duration. The effective duration is not always the source duration: trims remove ranges, speed regions change how long kept ranges occupy the output, and audio or clip edits may affect finalization. The exporter then decodes source frames sequentially rather than seeking independently for every output frame. Streaming keeps memory bounded and gives the pipeline a natural order: decode a frame, render the scene at its source and output timestamps, send the rendered frame toward the encoder, and continue.

The rendered frame is produced by the same scene-oriented machinery that powers the editor. The exporter passes appearance and timeline state into a frame renderer, which applies the crop, padding, background, camera transform, cursor, webcam, captions, annotations, and effects. This is the point at which project intent becomes pixels. Encoding does not decide where a zoom should look or when an annotation is visible; it receives the already-composed frame.

That separation is useful because it makes the export stages legible. A decoder failure is different from a renderer failure. A renderer can produce a frame while an encoder rejects the requested H.264 profile or dimensions. Video encoding can complete while audio processing or MP4 finalization fails. If all of those operations were one opaque call, the user would see only “export failed.” Recordly's exporter instead tracks phases, backend names, frame counts, queue behavior, and finalization timings so the failure can be associated with a stage.

The basic pipeline is:

flowchart LR A["Project state"] --> B["Metadata and sequential decode"] B --> C["Shared scene renderer"] C --> D{"Export route"} D --> E["WebCodecs encoding"] D --> F["Native streaming encoding"] D --> G["Native static layout"] E --> H["Audio plan and processing"] F --> H G --> H H --> I["Mux and chunked writes"] I --> J["Temp file finalization"] D -. "unsupported or failed" .-> C B -. "known decode failure" .-> K["Retry with fallback source"]

The diagram has a deliberate asymmetry. The scene renderer is common enough to be the compatibility center, while the encoding route can change. A native compositor may bypass parts of the general frame-by-frame path for a restricted composition, but it must still represent the project's requested meaning. If it cannot, the exporter returns to the shared renderer rather than silently dropping the feature.

Why streaming and backpressure matter

A long screen recording can contain millions of decoded pixels and a large encoded output. Keeping every decoded frame or every encoded chunk in the renderer would turn export into a memory contest. Recordly's modern path uses streaming decode and processes frames in order. Its MP4 muxer can write to a main-process temporary file through chunked IPC instead of collecting a multi-gigabyte buffer in the renderer.