Media Editing

Somewhere on a hard drive there is a two-hour video that would make a great eight-minute live set. The problem is the two hours.

This is the first in a short series about media editing for live performance. Not editing in the sense of assembling a narrative, with a timeline, a story and a reason for every cut. This is the unglamorous preparation that happens before a show: turning a long source into a set of short, reliable clips that can be triggered while you're also listening, cueing and trying not to knock over someone's drink.

Live performance is a different brief

On stage you don't have two hours. You have a few seconds between cues, one hand on a fader, and a laptop balanced on a flight case. Scrubbing through a long file to find the good bit is not a performance technique. It's a way to lose the room.

Three constraints shape everything:

• Time. You need to find a clip, trigger it, and get back to the next decision. Anything that requires reading a filename or hunting through a timeline is too slow.
• Attention. You're already listening to the room, watching the crowd, and keeping one eye on the mixer. The clip library has to be legible without conscious thought.
• Reliability. The machine may not be yours. The player may be older than you expect. The codec has to behave the first time, not after a settings dialog.

None of this replaces a proper edit. If you're cutting a trailer, open Resolve and enjoy the timeline. This is for the unglamorous volume work: the same operation applied to a whole source, reproducibly, so you can spend your attention on the twenty clips that matter.

The Video Editing post calls this the inverse of a normal edit: instead of assembling a timeline from many sources, we're pulling many clips out of one source. That post covers the offline-editor route — cutting on a timeline rather than live — the software you might use, and the scripted basics up to merging. This series is the companion route. It starts a step earlier, with finding the cuts in the first place, then carries on through culling and delivery. The distinction is mostly one of emphasis: the offline-editing post is about the timeline and the software around it; this series is about the media itself — codecs, containers, frame rates, audio and delivery.

The other post calls the scripted method "RNGesus Take the Wheel", and for good reason. If you point a detector at two hours of footage and accept whatever comes out, it is a gamble. The difference here is the review and curation steps. The detector proposes; you decide. The offline editor is still the right tool when you want to build a precise timeline. This is the right tool when you want to process a long source in bulk and then spend your attention on the keepers.

Candidates, not clips

The first mental shift is to stop thinking of the output as a finished edit. A scene detector gives you candidates. Some are great. Some are technically scenes but emotionally nothing. Some are five seconds of a person walking into frame, which might be brilliant or might be exactly what it says on the tin. You won't know until you see them in motion.

That's why the workflow has two separate folders for the results. One is a quarry; the other is a toolbox. The quarry holds every segment the detector found. The toolbox holds the handful you'd actually reach for in the dark.

What "performance-ready" actually means

A clip that plays fine on your laptop is not necessarily a clip that will play fine on a venue's machine. A few technical decisions make the difference between "it works" and "it works everywhere".

Container versus codec. An MP4 is a box. H.264 is what's inside. A player can support the box and still choke on the contents, which is why "it plays on my laptop" is not a delivery spec. The workflow here lands on H.264 High in MP4 because that's the combination most players understand.

Pixel format. yuv420p is the common denominator. Some players will accept other things. The one in the venue will not.

Frame rate and resolution. Pick the numbers your rig runs at and conform everything to them. A player that has to rescale or reinterpret on the fly is a player that might stutter at the worst possible moment.

Keyframes and clean starts. Video is stored as occasional full frames with smaller changes in between. If you stream-copy a segment out of a long file, the cut has to start at a keyframe, so the clip may begin earlier than you asked or include frames you didn't want. Re-encoding gives every clip a clean start, at the cost of time and a little quality.

Fast start. An MP4 normally keeps its index at the end. +faststart moves it to the front, so the player can begin before it has read the whole file.

Audio. For visual-only work, strip it. A stray burst of source audio in the middle of a set is a special kind of awful. If you need the audio, normalise it and make that decision deliberately rather than inheriting whatever the source happened to contain.

You don't have to hold all of this in your head while you work. The scripts make most of the decisions for you. But knowing what they're doing makes it much easier to fix things when a clip misbehaves.

The pipeline

The whole series follows the same shape:

1. Detect. Find the points where the picture changes.
2. Review. Look at the first frame of each scene and decide what's promising.
3. Cut. Turn the cut points into clip lengths and cut the clips.
4. Cull and name. Keep the good ones, give them names you can read on stage.
5. Conform. Match the rig's resolution, frame rate and audio expectations.
6. Rehearse. Test every clip on the actual show machine.

The folder structure keeps those stages separate:

show/
  00-source/    the untouched original
  01-scenes/    detection files, thumbnails, contact sheet
  02-clips/     every segment the detector found
  03-selects/   the keepers, named and banked
  04-ready/     conformed for the rig

Keep the source untouched. Keep the intermediate files disposable. Put the clips you'll actually perform with somewhere they can be copied to a show drive without dragging the whole project along.

The four scripts

The workflow uses four small shell scripts by NapoleonWils0n:

The repo now points at a Rust port. The shell versions are still there for reference, and they're still what I reach for, because they're short enough to read in a text editor and change when a project needs something slightly different. If you're starting from scratch, the Rust versions are probably the sensible choice. The workflow is the same either way. His long-form video walkthrough is linked from the Video Editing post if you'd rather watch the whole thing.

To follow along, clone the repo and copy or symlink the four scene-* scripts into a folder on your PATH. I keep mine in ~/.scripts with a .sh suffix. The examples use the bare names; either add the folder to your PATH or call scene-detect.sh. You'll need ffmpeg and ffprobe. The rest is standard shell tools, which you already have. They're POSIX shell scripts, so on Windows WSL is the usual route.

What's next

In part two we'll point scene-detect at the source, work out what threshold actually means, and make a contact sheet so you can see what the detector found before you commit to cutting.

Companion: Video Editing — the offline-editor route, software options, and the merge script.

The series: 1. Media Editing · 2. Finding the Cuts · 3. Cutting, Culling and Naming · 4. Performance-Ready Clips