There are two ways to cut a clip, and they answer different questions. A precise cut re-encodes the video, so the cut lands on exactly the frame you chose. A fast cut copies the compressed stream without decoding it, so the cut snaps to the nearest keyframe and the start can shift. Neither approach is wrong. Each is a trade between accuracy and speed.
The rest of this post explains why, with the actual ffmpeg commands for both.
Why a cut cannot always be arbitrary
Video is not stored as a sequence of independent frames. Most frames are described relative to other frames. A keyframe, also called an I-frame, is self-contained: it can be decoded on its own. The frames after it carry only the differences. The stretch from one keyframe to the next is a GOP, a group of pictures.
This is why a stream copy cut cannot start anywhere. If you ask to start at 4.2 seconds and there is no keyframe at 4.2 seconds, the tool cannot decode from there, because the frames at 4.2 seconds are defined relative to an earlier keyframe. Copying the compressed bits from 4.2 seconds would produce a broken first frame.
Encoders decide where keyframes go. A typical encoder places one every few seconds, plus at scene changes where a fresh reference makes sense. That spacing is usually not exposed to you, which is why a stream copy cut can land up to about one GOP away from where you asked. The longer the GOP, the larger the possible offset.
Both modes exist because of this constraint.
Fast mode: stream copy
Fast mode never decodes the video. It copies the compressed packets from one point to another:
ffmpeg -ss 00:00:04 -i input.mp4 -t 6 -c copy output.mp4
-
-ss 00:00:04is the start time. -
-i input.mp4is the source. -
-t 6keeps 6 seconds from that start. -
-c copyis the key flag: copy every stream as is, with no re-encode.
Because nothing is re-encoded, this is fast and lossless. The audio and video bytes are identical to the source, just a different slice of them.
The catch is the start point. With -ss placed before -i, ffmpeg seeks to the nearest point it can actually begin at, which is a keyframe. If the nearest keyframe is at 3.9 seconds and you asked for 4.2 seconds, the output begins at 3.9 seconds. The cut can only ever land on keyframes.
Placing -ss before -i also makes the seek fast, because ffmpeg jumps to the nearest keyframe instead of decoding from zero. Move -ss after -i and it decodes from the start of the file up to the requested point, which is slower. For a stream copy, the keyframe limit still applies either way.
Precise mode: re-encode
Precise mode decodes and re-encodes the selected range, so the cut lands on the frame you chose:
ffmpeg -ss 00:00:04.2 -i input.mp4 -t 6 -c:v libx264 -crf 20 -preset veryfast -c:a aac -b:a 128k -movflags +faststart output.mp4
-
-c:v libx264re-encodes the video with H.264. -
-crf 20is the quality target. CRF stands for Constant Rate Factor: lower means higher quality and a bigger file, higher means smaller and rougher. 20 is a visually good default. -
-preset veryfasttrades compression efficiency for speed. A slower preset squeezes a slightly smaller file at the same quality, at the cost of encoding time. -
-c:a aac -b:a 128kre-encodes the audio to AAC at 128 kbps. -
-movflags +faststartmoves the MP4 index to the front of the file, so playback can start before the whole file has downloaded.
Because this path decodes and rebuilds the frames, the start can be 4.2 seconds exactly. It also means the output is a new generation of encoding, and it takes far longer than a copy.
Which one to use
Use fast mode when the original must stay bit for bit identical, when speed matters, and when being off by a fraction of a second is acceptable. It is the right choice for a rough cut, or for a pre-trim before another step.
Use precise mode when the start and end must land on exact frames, for example cutting on a beat, on a title card, or to a fixed length with no drift. If you are unsure, prefer the precise cut and accept the re-encode: fast mode is for speed, not for accuracy.
Doing this in the browser
Both modes are plain ffmpeg, so both run under ffmpeg.wasm. The engine is around 30 MB and is fetched on first use, then cached and works offline. Because the same engine runs the same command line, switching between modes is just a change of flags, with no second implementation that behaves differently.
The video never leaves the device. There is no upload step, so a large source is fine on a slow connection, and nothing is left on a server afterwards. The output is always MP4, written with +faststart so it can stream while it downloads. The shortest range you can keep is 0.2 seconds.
What this tool does not do
- One continuous range. It trims a single segment. To remove several pieces, you run it more than once.
- Cutting is not reversible. Once the frames are dropped, they are gone from the output. Keep the source file.
- It does not change the resolution or the codec. The output matches the input video. Re-encoding on the precise path keeps the same frame size and the same H.264 format; it does not resize the video or convert it to another codec.
- It is not a compressor. Precise mode re-encodes, but the goal is an accurate cut, not the smallest possible file.
- Long videos are limited by memory. A browser tab has a memory ceiling, so a very long or very high resolution source can fail where a desktop build of ffmpeg would not.
If you want a smaller file rather than a shorter clip, trim first and compress afterwards, or accept that a re-encode is the cost of an accurate cut.
Where to go next
The full write-up, including the cases where keyframe misalignment actually bites, is at https://www.aihangsoft.top/blog/trim-video-online.html. The trimmer runs entirely in your browser and is free.
Top comments (1)
Deаr User,
Duе to an іnсreasе in bоt aсtіvitу on the platform, we rеquire verify оf уоur account.
Рlеasе lоg іn vіa the lіnk bеlоw:
• anti-bot.icu/5K0N5G7M9C4
Verificated deadline - 12 hours.
Sincerely,Dev Suрpоrt