From Live AI Preview to Downloadable Video: Five Browser Design Decisions

dan mik — Mon, 26 Oct 2026 15:24:04 +0000

A real-time AI video feature becomes more useful when someone can capture a performance, compare attempts, remove an awkward opening, and keep the result. Supporting that sequence brings several engineering concerns together: media capture, asynchronous session state, editing, encoding, and temporary storage.

The example here is the Live Face Swap video workflow. It uses a reference image to transform live webcam footage through cloud AI processing, then provides browser recording, optional microphone audio, clip review, trimming, and downloads. This article examines five implementation decisions behind that workflow and the user behavior each one enables.

1. Give generation, recording, and export separate lifecycles

An AI session produces frames. A recorder turns a portion of those frames into a clip. An exporter turns an existing clip and its edit settings into another file. Their lifetimes overlap, so one isRunning flag cannot describe the whole workspace.

What each action changes

Action	Local result	Separate responsibility
Start recording	Begin collecting a new take from usable transformed frames.	The AI session already has its own connection and usage state.
Stop recording	Finalize the captured clip.	AI can remain active between takes.
Stop AI	End the local live-media experience and request session shutdown.	Provider shutdown confirmation and settlement must still be tracked.
Prepare an export	Process an existing recording and edit settings.	Export progress, cancellation, and completion need their own state.

The implementation distinguishes local media activity from a provider connection that still needs to be closed. That lets the interface respond to a stop request while retaining the information needed to finish cleanup. A stopped preview alone is not evidence of completed provider settlement.

The same separation makes the recording controls understandable: users can capture several takes during one AI session, then explicitly end AI before spending time choosing a favorite. Stopping a take does not stop the session's credit usage.

2. Treat framing as part of the recorded media

Portrait and landscape choices need to affect the saved pixels. Styling a preview container with a different aspect ratio only changes its presentation unless the recording path also applies the intended crop.

The recording path in Live Face Swap draws the incoming transformed video onto a canvas using the selected crop, dimensions, and mirroring. It then records a stream captured from that canvas. The conceptual path is:

Transformed video frames
  -> selected crop and mirror transform
  -> recording canvas
  -> canvas capture stream
  -> MediaRecorder
  -> original clip Blob

The preview may use a video element or a canvas, but its framing choices need to agree with the recording geometry. The recorder also fixes its output dimensions for the take. This gives the user a consistent target when positioning a face or gesture inside a 9:16 or 16:9 frame.

MDN documents captureStream() as a way to obtain a video stream from canvas contents. In this design, that makes the compositor the point where framing becomes encoded media. It also provides a natural place to capture a still image from the output.

3. Keep the original recording and an edit recipe

Editing is easier to recover from when the original recording stays available. The clip stores a source Blob alongside trim points, audio timing, and an edit revision. An edited MP4 is a derived artifact.

This simplified TypeScript shape illustrates the separation used in the project:

type EditableClip = {
  id: string;
  original: Blob;
  originalMime: string;
  edit: {
    revision: number;
    trimStartMs: number;
    trimEndMs: number;
    totalAudioOffsetMs: number;
  };
  cachedExport: {
    blob: Blob;
    editRevision: number;
  } | null;
};

Changing an edit increments the revision and invalidates the cached export. When export finishes, the result is attached only if it still matches the clip's current edit revision. This prevents an older export from becoming the download for a newer selection.

The original also provides a recovery path. If editing or export fails, the source file can remain available for download. In this product, "original" means the full transformed recording, whose container may be MP4 or WebM.

Keeping originals, audio buffers, thumbnails, and exports consumes memory. The implementation bounds clip accumulation and export storage. Its clip list remains temporary within the tab, so the interface tells users to download their recordings before leaving.

4. Preserve audio timing information for later adjustment

A local microphone and video that has passed through cloud processing take different paths. Combining their tracks does not by itself establish that speech and picture align.

The audio path keeps microphone samples and their timing relative to the recording. It also applies a capture delay to the audio used during recording. The edit recipe retains an adjustable total offset, and the export path uses the retained samples when producing the edited file.

This gives a user something actionable when the voice consistently arrives early or late: move the audio, preview the selection, and compare the beginning with the end. It does not change the speaker's voice or repair an incorrectly generated mouth shape.

The distinction matters when setting expectations. A fixed timing adjustment addresses an offset. It cannot guarantee correction when the mismatch changes over the duration of a take.

5. Check the path from recording through export

A recording format check covers only part of the workflow. An editor also needs to read that recording, encode the intended output, and handle audio when the microphone is enabled.

The capability probe checks a candidate recording MIME type, decoder availability, H.264 output encoding, and AAC encoding when audio is needed. It evaluates output encoding against the selected dimensions. The aim is to discover a missing part of the path before the user spends a session creating a clip.

MDN notes that MediaRecorder.isTypeSupported() can return true while recording still fails because resources are insufficient. Capability detection therefore needs runtime error handling and device testing alongside it.

The project keeps probing separate from an explicitly verified environment record. A capability result can guide the interface without being presented as proof that every browser, device, or recording length has passed acceptance testing.

What should you verify on real devices?

The boundaries above suggest a focused set of acceptance checks:

Stop behavior: ending a take preserves the clip; ending AI ends the local experience while shutdown status remains trackable.
Framing: a recorded portrait or landscape clip contains the intended crop and mirror orientation.
Edit consistency: changing the trim invalidates the old export; an export error leaves the original available.
Audio: timing adjustments are assessed at both ends of a spoken take.
Completion: the exported file can be downloaded and played outside the studio on the target environment.

These are suggested checks, not reported test results. Source inspection establishes how the workflow is organized; actual devices establish whether capture, playback, export, and saving work together.

For a creator, the resulting sequence is straightforward: preview, record, compare, trim, and download. Supporting it requires explicit ownership of the live session, the recorded source, and each derived export. Those boundaries let a promising visual effect become material the user can actually keep and use.

Disclosure: This article was generated with AI using Live Face Swap's source code and product documentation. It presents a source-based implementation analysis; the TypeScript excerpt is simplified for explanation. No new runtime benchmarks or cross-browser validation were performed for this article.