This article walks through the implementation used in the small, dependency-free Photo2Reel exporter. The complete MIT-licensed source is also available in the public GitHub repository.

The pipeline in one sentence

Local image files become decoded Image objects, those images are drawn onto a fixed-size canvas, canvas.captureStream() supplies the video track, Web Audio supplies an optional audio track, and MediaRecorder turns the combined stream into chunks that become a downloadable Blob.

Nothing in that pipeline requires fetch(), an upload form, a database, or a remote encoder. An object URL such as blob:https://... is a browser-managed reference to local data; creating one does not send the file anywhere.

The implementation loads photos this way:

async function addFiles(fileList) {
  for (const file of [...fileList].filter(f => f.type.startsWith('image/'))) {
    const url = URL.createObjectURL(file);
    const image = new Image();
    image.src = url;

    try {
      await image.decode();
      photos.push({ file, url, image, duration: 3 });
    } catch {
      URL.revokeObjectURL(url);
    }
  }
}

Waiting for image.decode() matters. It moves a possible decoding failure to the import step instead of discovering it halfway through a recording. Keeping the object URL also avoids converting a large binary file into a longer base64 string. When a photo is removed, its URL is revoked.

Make the canvas the output contract

The exporter uses a 1280 × 720 canvas. That is not merely a preview size: it defines the actual video frame. CSS may scale the visible canvas down for a phone, but its drawing buffer remains 1280 by 720.

Photos rarely share the canvas aspect ratio. Stretching them damages proportions, while filling the entire frame would crop portraits. This implementation chooses containment over cropping and paints a dark matte behind unused space:

function drawContained(image) {
  const iw = image.naturalWidth || image.width;
  const ih = image.naturalHeight || image.height;
  const cw = canvas.width;
  const ch = canvas.height;

  const scale = Math.min(cw / iw, ch / ih);
  const width = iw * scale;
  const height = ih * scale;

  ctx.fillStyle = '#060c19';
  ctx.fillRect(0, 0, cw, ch);
  ctx.drawImage(image, (cw - width) / 2, (ch - height) / 2, width, height);
}

Using Math.min() is the key. Replacing it with Math.max() produces a cover-style frame: no matte, but some source pixels are cropped. Neither choice is universally correct. A slideshow that preserves family photos benefits from containment; a full-bleed social clip may deliberately prefer cover.

Negotiate the recording format at runtime

There is no single MIME string that can be assumed across every browser. File extensions do not choose encoders either. The application has to ask the current browser which recorder configurations it exposes, in preference order.

function bestMime() {
  if (!window.MediaRecorder) return '';

  const candidates = [
    'video/webm;codecs=vp9,opus',
    'video/webm;codecs=vp8,opus',
    'video/webm',
    'video/mp4;codecs=avc1.42E01E,mp4a.40.2',
    'video/mp4'
  ];

  return candidates.find(type => MediaRecorder.isTypeSupported(type)) || '';
}

The order expresses policy, not a claim that the first entry is always best. Here, explicit WebM combinations are preferred, generic WebM is a fallback, and MP4 is used only when the runtime reports a matching recorder.

The selected MIME type must travel through the rest of the pipeline. The recorder receives it, the final blob uses its container portion, and the download extension follows the same decision:

const recorder = new MediaRecorder(stream, {
  mimeType,
  videoBitsPerSecond: 5_000_000
});

const extension = mimeType.includes('mp4') ? 'mp4' : 'webm';
const blob = new Blob(chunks, { type: mimeType.split(';')[0] });
download.download = `photo-slideshow.${extension}`;

Renaming a WebM blob to .mp4 does not convert it. It only creates a misleading file.

isTypeSupported() is a capability gate, not a reason to remove error handling. Recorder construction or recording can still fail because of the selected tracks, media resources, or runtime conditions. The UI should report that failure and leave the original files untouched.

Schedule scenes against absolute deadlines

A tempting slideshow loop is “draw, sleep for the duration, repeat.” Its weakness is accumulated delay: drawing and UI work take time, so every scene begins a little later than the last. The implementation instead computes each scene's deadline from one performance.now() origin.

A reusable version looks like this:

const started = performance.now();
let cumulativeMs = 0;

for (let index = 0; index < photos.length; index += 1) {
  const photo = photos[index];
  drawContained(photo.image);

  cumulativeMs += photo.duration * 1000;
  const remaining = started + cumulativeMs - performance.now();
  if (remaining > 0) {
    await new Promise(resolve => setTimeout(resolve, remaining));
  }
}

If one iteration runs late, the next wait becomes shorter instead of carrying the entire delay forward. This does not create hard real-time behavior—background-tab throttling, device sleep, and a busy main thread still exist—but it prevents ordinary JavaScript work from automatically accumulating into timeline drift.

The canvas stream is requested at 30 frames per second:

const stream = canvas.captureStream(30);

That does not mean the code has to redraw an unchanged photograph thirty times every second. A still scene can remain on the canvas until its deadline. The captured stream represents that surface while the recorder handles the video cadence.

One consequence is easy to overlook: recording is wall-clock work. A slideshow with a long visual timeline does not finish instantly; the current implementation records while that timeline passes. An offline frame encoder would be a different architecture.

Mix audio into the same MediaStream

Canvas contributes video only. To add music, the exporter builds a Web Audio graph whose destination exposes a MediaStream audio track:

const audioContext = new (window.AudioContext || window.webkitAudioContext)();
const destination = audioContext.createMediaStreamDestination();
const gain = audioContext.createGain();

gain.gain.value = Number(volume.value) / 100;
gain.connect(destination);

// For a user-selected local audio file:
const audioElement = new Audio(URL.createObjectURL(audioFile));
audioElement.loop = true;
const source = audioContext.createMediaElementSource(audioElement);
source.connect(gain);

await audioContext.resume();
await audioElement.play();

for (const track of destination.stream.getAudioTracks()) {
  stream.addTrack(track);
}

The graph is media element → gain → media-stream destination. The destination track joins the canvas track before MediaRecorder is constructed, so the recorder sees one combined stream. The audio element loops when it is shorter than the slideshow and is paused when recording stops.

The demo can also synthesize a soundtrack. Oscillators connect through short gain envelopes to the same destination. Their start times are scheduled against audioContext.currentTime, which is preferable to firing every note from a chain of JavaScript timers. The recorder still determines the final cutoff, so a note scheduled beyond the slideshow endpoint is simply not present in the completed recording.

Audio contexts commonly need to be resumed from a user action. Starting export from a button click gives resume() and play() the user gesture they need, although an unsupported input codec can still make play() reject. That rejection belongs in the same visible error path as recorder failures.

Do not build the blob before the recorder has stopped

MediaRecorder delivers data asynchronously. A timeslice asks it to emit chunks periodically, but it does not define slideshow frames or exact edit boundaries.

const chunks = [];
const stopped = new Promise(resolve => {
  recorder.onstop = resolve;
});

recorder.ondataavailable = event => {
  if (event.data.size) chunks.push(event.data);
};

recorder.start(250);

// Draw scenes and wait for their deadlines here.

recorder.stop();
await stopped;

const blob = new Blob(chunks, { type: mimeType.split(';')[0] });
const resultUrl = URL.createObjectURL(blob);

Waiting for stop ensures the final dataavailable event has been handled before the blob is assembled. The resulting object URL can be assigned directly to an <a download> element.

Output URLs should not live forever. Before exposing a replacement render, the implementation calls URL.revokeObjectURL(previousResultUrl). The same cleanup rule applies to removed images and temporary audio URLs. The AudioContext is closed after the recorder finishes.

Practical limits and hardening points

Browser-local does not mean resource-free. Decoded images, a 1280 × 720 drawing buffer, recorder chunks, and the final blob all occupy memory in the user's tab. Long sequences and high-resolution inputs should be tested on the target device rather than inferred from desktop behavior.

Format support is also a runtime property. A responsible interface checks for MediaRecorder, canvas.captureStream, and at least one accepted MIME candidate, then displays the actual output container. It should never promise MP4 before negotiation has happened.

For a more defensive production version, I would add four things around the compact reference implementation:

1. Listen for recorder.onerror and reject the pending completion promise instead of relying only on synchronous try/catch.
2. Put audio pause, temporary URL revocation, track stopping, and AudioContext.close() in a finally path so a failed play() cannot skip cleanup.
3. Check that the completed blob has a nonzero size, then test playback—not merely download creation—during browser QA.
4. Warn users to keep the page active during recording, because background throttling and device sleep can disturb a wall-clock export.

The main architectural lesson is modest: use capability negotiation rather than browser names, calculate scene changes from one monotonic start time, and mix audio before constructing the recorder. With those boundaries in place, Canvas, Web Audio, and MediaRecorder form a useful local media pipeline without an upload queue or server-side renderer.