Trim a clip without re-encoding
Cuts a clip to a start time and duration by stream-copying instead of re-encoding, finishing almost instantly at the source's full quality.
Last updated
ffmpeg -ss 00:00:30 -i input.mp4 -t 00:00:15 -c copy output.mp4
How it works
-ss 00:00:30 placed BEFORE -i tells ffmpeg to seek the input to that timestamp before decoding starts, which is fast because it skips straight there instead of decoding every frame from zero. -t 00:00:15 then sets how much to keep after that point — 15 seconds of output, starting at the 30-second mark. -c copy stream-copies both video and audio rather than re-encoding, which is what makes the whole operation finish in roughly the time it takes to read and write the bytes.
Because nothing is decoded and re-encoded, the trimmed output is bit-for-bit identical in quality to the source for the frames it keeps — there's no generational quality loss the way there would be with a re-encoded trim.
Watch out for
- →-c copy can only cut on keyframes, so with a fast-seeking -ss before -i, the actual start point may snap to the nearest keyframe rather than land on the exact frame requested — sometimes a second or so off. For frame-accurate trims, drop -c copy and let ffmpeg re-encode instead.
- →-t is a DURATION relative to the start point, not an absolute end time — use -to 00:00:45 instead if you'd rather specify where the clip ends.
- →Placing -ss after -i (rather than before) does slower, frame-accurate output seeking instead of fast input seeking — useful if precision matters more than speed for a particular cut.
Part by part
- -ss 00:00:30
- The start point. Its position before -i is deliberate — see the mistakes below, because moving it changes both speed and accuracy.
- -t 00:00:15
- How long to keep, not the end timestamp. Fifteen seconds from the start point, so this clip ends at 45 seconds.
- -c copy
- Copy both streams without re-encoding. Instant and lossless, at the cost of only being able to cut on keyframes.
Common mistakes
ffmpeg -i input.mp4 -ss 00:00:30 -t 00:00:15 -c copy output.mp4Putting -ss after -i makes ffmpeg decode from the beginning to reach the start point, which on a long file is dramatically slower. It is more precise that way, but with -c copy that precision is unavailable anyway.
ffmpeg -ss 00:00:30 -i input.mp4 -t 00:00:15 -c copy output.mp4ffmpeg -ss 00:00:30 -i input.mp4 -to 00:00:15 -c copy output.mp4-to is an end timestamp, not a duration, and when -ss comes first it is measured from the new zero. This produces a fifteen-second clip by accident and a confusing result whenever the numbers differ.
ffmpeg -ss 30 -i input.mp4 -t 15 -c copy -c:v libx264 output.mp4Adding a video codec after -c copy overrides it, so the video is re-encoded while the audio is copied. The last matching option wins, which makes flag order significant in a way that is easy to miss.
Questions
Why does my clip start a second or two early?
Because -c copy can only cut at a keyframe, and it seeks to the nearest one at or before your timestamp. That is the price of an instant, lossless trim — re-encode if you need frame-accurate cuts.
How do I get an exact cut?
Drop -c copy so the video is re-encoded, and put -ss after -i for accurate seeking. It is far slower and loses a generation of quality, so only do it when the imprecision actually matters.
What is the difference between -t and -to?
-t is a duration and -to is an end position. With -ss before -i the timeline is rebased to the cut point, so -to is measured from there rather than from the original file, which is the usual source of confusion.
Can I trim the end without knowing the duration?
Yes, use a negative -sseof to seek from the end of the file — -sseof -00:00:10 starts ten seconds before it finishes. Useful when you want the last portion of an unknown-length recording.