Cutting video without re-encoding, in production.

A highlight, ready before the meeting ends.

listener.app let you bookmark moments in a live Zoom meeting with a small companion tool. The promise was simple: the instant you bookmark 2:13 to 2:18, the system starts cutting that highlight, so by the time everyone says goodbye the clip is already sitting there — downloadable, shareable, done. A meeting runs 45 to 90 minutes. A highlight is 5 to 30 seconds. A host might bookmark a dozen of them, and none of them are allowed to wait for the recording to finish.

The obvious design is to capture one big file, then per bookmark run ffmpeg -ss … -t …over it and re-encode. It falls apart almost immediately:

• ✕The full file doesn't exist yet. The meeting is still going. Hosts bookmark a moment at minute five while Zoom is still on minute twenty-three — there is no finished recording to cut from.
• ✕Re-encoding is expensive. Trimming a 7-second highlight out of a multi-gigabyte MP4 by re-encoding burns tens of seconds of Lambda CPU. Multiply by every bookmark, by every meeting.
• ✕Seeking through a huge file is slow. Without a smart input seek, FFmpeg walks the file to find your timestamp — and on a 90-minute recording that's real time.
• ✕Pulling the whole file is wasteful. Dragging a gigabyte from S3 into a Lambda's /tmp just to keep 7 seconds of it is the definition of overkill.

Don't record one file. Record many.

Instead of one big MP4 per recording, the recorder writes the live stream as a sequence of short, fixed-length chunks — here, 240 seconds each. This one decision is the entire trick. Everything else is bookkeeping.

Why 240 seconds?

• ✓Short enough that any normal clip touches at most two chunks.
• ✓Long enough that uploads are amortised — you're not paying per-second upload overhead.
• ✓Concat-friendly every chunk starts on a clean keyframe, so two chunks join with -c copy and no re-encode.

// clip-lambda/config.ts
export default {
  videoCodec: "libx264",
  outputFormat: "mp4",
  chunkSize: 240,                 // <- the magic number, in seconds
  clipDimensions: ["512x288", "768x432"],
};

From Zoom to highlight, end to end.

The whole pipeline is a brain and a muscle. The API + MongoDB owns the chunk index and decides what work is even possible; a short-lived Node Lambda does the FFmpeg labour. Everything in between is S3 and a queue. Tap any stage to see what it's responsible for.

The split matters: the API turns away impossible requests with a single MongoDB lookup, so the expensive Lambda only ever runs when it can actually succeed. More on that in a moment.

Which chunks does a highlight actually need?

Given a bookmark in seconds relative to the whole meeting, and the chunk-duration map from MongoDB, the API works out which chunks to fetch from S3 and at what offsets. Drag the handles — the plan and the real FFmpeg commands update live.

The hot path is the single-chunk case: most highlights are short enough to live inside one chunk, so they need exactly one S3 GET and one copy. Here's the core of that logic — the same math the Lambda re-runs before it trusts the payload it was handed:

// which chunk does a timestamp fall in, and where inside it?
function locate(t, chunks) {
  let acc = 0;
  for (let i = 0; i < chunks.length; i++) {
    if (t < acc + chunks[i] || i === chunks.length - 1) {
      return { chunk: i + 1, offset: t - acc, dur: chunks[i] };
    }
    acc += chunks[i];
  }
}

// a clip is single-chunk when both ends land in the same one
function planClip(start, end, chunks) {
  const s = locate(start, chunks);
  const e = locate(end, chunks);
  if (s.chunk === e.chunk) {
    return { kind: "single", chunk: s.chunk, ss: s.offset, t: e.offset - s.offset };
  }
  return { kind: "span", from: s, to: e }; // pull two, then concat
}

The whole cut is three flags.

For the common single-chunk case, the entire FFmpeg command is this — and every flag is earning its place. Tap each card to see the version that looks almost identical but costs far more.

ffmpeg -ss 00:01:12 -i chunk_2.mp4 -t 6 -c copy clip.mp4

A note on precision: millisecond timestamps like 00:01:12.347 make cuts feelframe-accurate, but stream-copy still snaps to the nearest keyframe underneath. With short keyframe intervals the error stays under half a second — a trade I'll take every time over re-encoding.

When a clip crosses a boundary.

When the selection spans two chunks, it's three fluent-ffmpeg calls — and none of them re-encode the video. Step through them; this is the same builder the Lambda runs.

// pull the tail of the start chunk — still a pure stream-copy
ffmpeg("chunk_1.mp4")
  .inputOptions(["-ss 00:03:50"])      // input-side seek
  .outputOptions(["-t 10", "-c copy"]) // copy packets, no re-encode
  .on("end", () => resolve("part_1.mp4"))
  .on("error", reject)
  .save("part_1.mp4");

This only works because both files came out of the same encoder with the same parameters and start on a keyframe. If MP4 boxes ever refuse to join cleanly, there's a more forgiving route: convert each part to MPEG-TS first (still a copy) by passing .outputOptions(["-bsf:v h264_mp4toannexb", "-f mpegts"]), then concat the TS files. It's the textbook fix when the plain MP4 demuxer gets cranky.

FFmpeg in the Node.js world.

Everything above is FFmpeg the command-line tool. But the cutter is a Node Lambda, so in practice every cut is FFmpeg-as-a-child-process. I drive it with fluent-ffmpeg — a chainable builder over child_process.spawn — and the static ffmpeg binary ships in a Lambda layer at /opt/bin/ffmpeg, because Lambda doesn't have FFmpeg by default.

// clip-lambda/ffmpeg.ts
// FFmpeg is a CLI. Inside a Node Lambda you drive it as a child process —
// fluent-ffmpeg is a chainable builder over child_process.spawn.
import ffmpeg from "fluent-ffmpeg";

ffmpeg.setFfmpegPath("/opt/bin/ffmpeg"); // static binary shipped in a Lambda layer

export function cut(input, ss, duration, output) {
  return new Promise((resolve, reject) => {
    ffmpeg(input)
      .inputOptions([`-ss ${ss}`])            // input-side seek — BEFORE -i
      .outputOptions([`-t ${duration}`, "-c copy"])
      .on("end", () => resolve(output))
      .on("error", reject)
      .save(output);
  });
}

A few things bite you here that the docs never mention. .on("error") is not optional — a rejected promise that nobody catches will hang the whole invocation until Lambda times out. The order of .inputOptions() versus .outputOptions() maps directly to before/after -i, so the seek-placement rule from earlier is something you enforce in which builder method you call. And fluent-ffmpeg swallows stderr by default — pipe it somewhere, because when a cut fails, FFmpeg's stderr is the only thing that tells you why.

The one place I do re-encode

The highlight keeps its original resolution, but feeds and mobile need smaller variants — and you can't rescale and -c copy at once, because -vf scale forces a decode and re-encode. So after the lossless cut, I fan the variants out with Promise.all, since each one is independent:

// the ONE re-encode: smaller variants for feeds + mobile.
// each is independent, so fan them out with Promise.all.
const variants = ["512x288", "768x432"];

await Promise.all(
  variants.map((dim) => {
    const [w, h] = dim.split("x");
    return new Promise((resolve, reject) =>
      ffmpeg(clip)
        .outputOptions([`-vf scale=${w}:${h}`]) // scale ⇒ must re-encode
        .on("end", resolve)
        .on("error", reject)
        .save(`clip_${dim}.mp4`)
    );
  })
);

This is fine because it runs on a 5–30 second highlight, not a 90-minute meeting. The expensive thing — re-encoding the source — never happens. The cheap thing — re-encoding a few seconds of already-cut output — happens once, in parallel, off the critical path.

Why Lambda — and the limits it makes you respect.

Clip jobs are bursty, short, parallel, and stateless — a host bookmarks five moments in a minute, then nothing for ten. That's exactly the shape Lambda is good at: I pay for the couple of seconds each cut runs and nothing while no one's clipping. But bundling FFmpeg into a function means living with a few limits.

• ›/tmp is small and shared. Lambda's scratch space defaults to 512 MB and is reused across warm invocations. Two 240s chunks blow through that, and leftovers from the last run poison the next. I raise the ephemeral storage and delete every file at the end of the handler — even on success.
• ›Memory is CPU. Lambda scales vCPU with memory, so a 3 GB function cuts noticeably faster than a 512 MB one. For CPU-bound FFmpeg work, more memory is often cheaper overall because the job finishes sooner.
• ›Ship FFmpeg as a layer. A static ffmpeg binary in a Lambda layer keeps the deploy package small and shared across functions, instead of fattening every bundle.
• ›Cold starts hurt the tail. An FFmpeg-bundled function cold-starts in 2–3s, which dominates p99 latency for highlights requested right after a meeting ends. Provisioned concurrency smooths it out.

// clip-lambda/handler.ts
export const handler = async (event) => {
  try {
    const plan = planClip(event.start, event.end, event.chunks); // re-run the math, trust nobody
    const clip = await produceClip(plan);  // GET chunk(s) from S3 → cut → (concat) → scale → PUT
    await sendToSQS({ highlightId: event.highlightId, clip });   // async completion, not a sync reply
    return ok(clip);
  } finally {
    deleteAllLocalFiles(event.verificationKey); // wipe /tmp even on success — warm runs share it
  }
};

Don't pay for doomed work

The cheapest optimisation in the whole system lives in the API, not the Lambda. While a meeting is live, hosts constantly bookmark a moment that's still "now" — before the final chunk has uploaded to S3. One MongoDB read catches that and skips the invocation entirely. A Lambda call that was going to fail is a Lambda call you didn't have to pay for:

// api/src/highlight.ts — refuse impossible work before paying for a Lambda
const { callLambda } = await shouldCallLambda(start, end, chunkMap, recordingId);

// the chunk isn't in S3 yet — e.g. the host bookmarked a moment that is still "now"
if (!callLambda) return;

await invokeClipLambda({ start, end, chunks: chunkMap, highlightId });

And the Lambda never replies to the API directly. It pushes to SQS; a worker drains the queue, updates MongoDB, and fires a WebSocket event to the listener.app UI. That decoupling is what lets a host bookmark ten moments in thirty seconds without the UI ever blocking — each highlight just appears as its cut lands.

What surprised me along the way.

A handful of things I didn't expect going in. Tap to read each one.

Where the design pays for itself.

Same clip, two designs. Flip the switch to compare the naive "download everything and re-encode" approach against the chunked stream-copy one.

Storage barely moves — the chunks plus a clip add up to about the same bytes as one big file plus a clip. The win is entirely in compute saved and, just as much, in latency. Making clips feel instant changed how people used the feature: it stopped feeling like a render job and started feeling like highlighting text.

What I'd change next time.

Four things that look obvious now. Tap to expand.

The FFmpeg flags behind all of this.

Every flag this system leans on, in one place. Filter by keyword or category.

The two that matter most are the seek-placement rule[1] and the concat demuxer[2]. Get those right and most of this falls out naturally.

Cutting video without re-encoding — common questions.