Keyframe Cut vs Frame-Exact Cut for YouTube Clips
In short
A keyframe cut copies the video stream without re-encoding, so it is fast and lossless but can start a moment before your in point. A frame-exact cut re-encodes the clip so it starts where you asked, which is slower. B-ROLL uses the fast cut by default and offers Exact frame cut in Advanced options.
On this page
What is a keyframe cut?
A keyframe cut is a stream-copy cut that starts at the nearest complete frame stored in the stream, at or before your in point. The video is copied, not re-encoded, so a keyframe cut is fast and changes no pixels.
The reason is how YouTube’s long-GOP codecs (H.264, VP9, AV1) store video. Only keyframes, also called I-frames, hold a whole picture; the P and B frames between them are stored as changes and cannot be shown on their own. The ffmpeg documentation explains that in most formats ffmpeg cannot seek exactly, so it jumps to the closest seek point before the position you asked for, and with stream copy it keeps the extra stretch up to that position.
The same documentation notes that stream copy does no decoding or encoding, which makes it very fast and free of quality loss.
The table compares the two cut modes B-ROLL offers for a YouTube clip.
| Cut mode | How it works | Speed | Accuracy at the start | Quality impact |
|---|---|---|---|---|
| Keyframe cut (B-ROLL default) | ffmpeg copies the stream from the keyframe at or before your in point | Fast: no decoding or encoding | Can start a moment before your in point | None: the frames are the original ones |
| Frame-exact cut: Exact frame cut (slower, re-encodes) | yt-dlp adds --force-keyframes-at-cuts, and ffmpeg decodes and re-encodes the section |
Slower: every frame of the section is encoded | Starts at the time you set | One extra generation of lossy compression in the clip |
Both modes download only the range you set, never the whole video. How cut modes fit next to codecs, containers and intermediates is mapped in codecs and formats for editing YouTube footage.
What is a frame-exact cut?
A frame-exact cut is a cut that re-encodes the clip so its first frame is the frame you asked for, not the keyframe before it. The yt-dlp README describes --force-keyframes-at-cuts as slow because it needs a re-encode, and says the result may show fewer artifacts around the cuts. The short definition is also under frame-exact cut in the glossary.
In yt-dlp’s own code, the change is simple: when a section has a start or end time and --force-keyframes-at-cuts is on, the FFmpegFD downloader no longer passes -c copy to ffmpeg. Without stream copy, ffmpeg decodes the section, throws away the frames before your in point and encodes the rest. The whole clip is re-encoded, not only the frames at its edges.
In B-ROLL, the frame-exact cut is the checkbox Exact frame cut (slower, re-encodes) in Advanced options, which adds that yt-dlp option. The preview player has no switch of its own; the player follows the same Advanced setting. Every other clip option, from several parts per video to file naming, is on the YouTube clip downloader page.
How does a keyframe cut move the start of a clip?
A keyframe cut moves the start of a clip earlier, not later. The reason is the seek: ffmpeg jumps back to the last keyframe before your in point. With stream copy it keeps everything from that keyframe on, so your clip opens with frames you did not ask for.
How early depends on the gap between keyframes in the stream you downloaded, which varies by video and by stream. B-ROLL prefers YouTube’s HLS streams for clips, because seeking deep into one large file could stall for minutes; the stream picked for a clip can therefore differ from the one a full download of the same video would get.
Two things look like an early start but are not keyframe problems. The player in B-ROLL sets in and out points to the whole second, and a typed time is read as minutes when it is a plain number (2 means 2:00). The symptom and its fixes, step by step, are in YouTube clip starts at the wrong time? How to fix it. Why long-GOP streams only allow clean entry at keyframes is covered in why H.264 and AV1 are hard to edit.
Which cut mode should you choose?
For most editing, choose the keyframe cut: it is faster, keeps the original frames, and the extra frames at the start are a free handle you trim on the timeline. Choose the frame-exact cut when the file itself must start on the right frame.
When to pick each mode:
- Keyframe cut: b-roll you will trim in DaVinci Resolve or Premiere Pro anyway, long clips where re-encoding time adds up, and any clip you convert to ProRes or DNxHR.
- Frame-exact cut: a file that goes somewhere untrimmed (a client, a social upload, a reference folder), audio or video that must line up from its first frame, and short clips where the extra time is small.
The editor’s verdict: leave the fast cut on and mark your in point a second early in the player, so the handle is yours, not the keyframe’s. The steps for marking a range are in how to download part of a YouTube video.
How does the cut mode affect quality?
A keyframe cut has no quality cost, because ffmpeg copies the original compressed frames. A frame-exact cut adds one generation of lossy compression to the whole clip, since the section is decoded and encoded again.
The ProRes and DNxHR route changes the math. When you pick ProRes or DNx, B-ROLL downloads a master and then converts it with ffmpeg to an intraframe .mov. With a keyframe cut, that conversion is the single re-encode the clip goes through.
With a frame-exact cut, the clip is encoded once for the cut and again for the conversion. A keyframe cut plus a trim on the timeline gives you the same frame accuracy with one encode less, because ProRes and DNxHR store every frame whole and your NLE can cut on any of them.
Frequently asked questions
Does a frame-exact cut lose quality?
Yes, a little, and only in the clip. A frame-exact cut decodes the section and encodes it again, which adds one generation of lossy compression that a keyframe cut avoids by copying the stream. The size of the loss depends on the encoder settings ffmpeg applies, so for b-roll you trim on the timeline anyway, the lossless keyframe cut is the safer default.
How much slower is a frame-exact cut?
A frame-exact cut is slower by the time your processor needs to encode the clip, which grows with clip length and resolution. A keyframe cut only copies data, so it finishes close to the time the download itself takes. A frame-exact cut must decode and encode every frame of the section, so a long 4K clip adds more work than a short 1080p one.
Does it matter if I trim again in the NLE?
No, not for accuracy. If you set the real in point on your timeline, the extra frames a keyframe cut leaves at the start simply become a handle you trim away. The cut mode matters when the file itself must start on an exact frame, for example when you hand it to someone else. B-ROLL's range options are described in the YouTube clip downloader.
Sources
- yt-dlp README on GitHub github.com
- yt-dlp source: FFmpegFD in downloader/external.py github.com
- ffmpeg documentation: ffmpeg command-line tool (-ss, stream copy) ffmpeg.org
