Avidemux Smart Copy Explained: Why Frame-Accurate Lossless Cutting Is Hard
Smart Copy was a feature of the Avidemux 2.5 series: when you cut at a non-keyframe, it re-encoded only the short section around the cut point (roughly one GOP) and copied everything else bit-for-bit. You got a frame-accurate cut without the cost — or the quality loss — of re-encoding the entire video. It was widely loved, and its removal in Avidemux 2.6 is still debated in the community years later.
If you are on a modern Avidemux (2.8.1 is the current stable release as of this writing), Smart Copy is not coming back — but understanding why it disappeared explains a lot about how cutting works today, and points you to the workarounds that actually get the job done.
Why Smart Copy worked: the GOP problem
Compressed video does not store every frame as a full picture. A typical stream is organized into groups of pictures (GOPs): one keyframe (I-frame) followed by a run of predictive frames (P- and B-frames) that are stored only as differences from other frames. To change one frame in the middle of a GOP, you must decode the whole GOP up to that point and re-encode the remainder.
Smart Copy exploited this structure: it re-encoded just the GOPs containing your cut points and copied the untouched GOPs verbatim. The result was frame-accurate cutting with near-Copy speed and near-Copy quality. For MPEG-2 sources — which the 2.5-era user base worked with constantly — it was near-perfect.
Why 2.6+ dropped it: the architecture changed
Avidemux 2.6 was a ground-up rewrite of the editing and frame-access engine. According to discussions on the official avidemux.org forum and developer notes, the new architecture made the old Smart Copy logic extremely difficult to preserve:
- Frame access was redesigned around a unified seeking/decoder pipeline shared by all codecs. The old Smart Copy code was deeply tied to the 2.5-era decoder plumbing and did not survive the port.
- B-frame dependencies got harder. Modern H.264 streams use long reference chains; re-encoding “just one GOP” cleanly requires reconstructing decoder state across frame types, which is far more fragile than it was with MPEG-2.
- Nobody volunteered to rewrite it. Avidemux is maintained by a small team (largely a single lead developer). Rebuilding Smart Copy for the new engine would have been a large, codec-specific project, and the team’s limited time went to stability, new codecs, and the filter system instead.
Historical note. The details above reflect community and developer discussion on the official forum, not an official design document — there is no single changelog entry that says “Smart Copy was removed because of X.” What is certain is that the feature existed in 2.5.x and is absent from every 2.6+ release including 2.8.1. (Note: 2.8.2 is the nightly/development line, not a stable release.)
What Avidemux 2.8.x offers instead
Modern Avidemux gives you two clean modes and one manual hybrid. See Copy mode vs re-encoding for the underlying concept.
| Option | How it works | Cut precision | Speed / quality |
|---|---|---|---|
| Copy mode (Video Output = Copy) | Stream copied untouched; no decoding | Keyframes only | Instant, fully lossless |
| Full re-encode | Every frame decoded and re-compressed (e.g. x264) | Any frame | Slow; small generation loss (tunable with CRF) |
| Manual “smart copy” | Cut the small section around the cut, re-encode just it, then append everything back together | Any frame | Fast; re-encoded segments get generation loss |
The manual smart-copy workaround, and its pitfall
The DIY approach: cut out a few seconds around your cut point, save that piece with a real encoder, then re-open the first segment and use File → Append to stitch the re-encoded piece back between the Copy-mode outer segments. It works, but there is a trap: every piece must use identical codec parameters — same resolution, same codec, same container-compatible format, and (for H.264) consistent profile/level. A mismatch produces broken timestamps or an unplayable file, so verify the result plays correctly end to end. Depending on your build, appended segments may also need identical frame rates to mux cleanly.
How LosslessCut handles the same problem
LosslessCut, the most common alternative to Avidemux for quick cutting, deliberately does not try to replicate Smart Copy. Its approach:
- Default: keyframe cutting. Like Avidemux’s Copy mode — fast and lossless, cut points snap to keyframes.
- “Smart cut” experiment: LosslessCut has an experimental smart-cut feature that uses ffmpeg to re-encode the few frames around the cut point and concatenates the segments. In practice it is fragile across codec variants, which is why it stays experimental.
- The real answer for both tools is the same: either accept keyframe cuts, or re-encode. No current free tool has rebuilt a reliable universal smart-copy.
So the Avidemux vs LosslessCut decision is not really about Smart Copy — neither has it. It is about workflow: Avidemux gives you a full editing timeline, filters, and encoders in one program; LosslessCut gives you a faster, simpler keyframe-cutting experience. If you need frame-accurate cuts regularly, the practical answer in either tool is re-encoding.
Practical advice: which approach for which job
| Your situation | Best choice | Why |
|---|---|---|
| Trimming intros/outros off recordings | Copy mode | A few seconds of imprecision rarely matters; keyframe cuts are instant and lossless. See cutting without re-encoding. |
| Cutting at exact frames for an edit | Full re-encode (x264, CRF ~18–20) | The only reliable frame-accurate method in 2.8.x; quality loss is negligible at good CRF values. |
| One cut in a 2-hour file, deadline in minutes | Manual smart-copy workaround | Re-encoding only the cut segment keeps the job fast; double-check the appended result. |
| Cutting many clips from one long source | Full re-encode | Manual stitching does not scale; script or batch re-encode instead. |
| Removing a section in the middle (video intact otherwise) | Copy mode for the keepers, re-encode or manual workaround for the joined edges | Keyframe cuts plus append keep 99% of the file lossless. |
Bottom line. Smart Copy was a brilliant solution to a genuinely hard problem — and the problem is still hard. No free editor has a production-quality version of it today. Until someone writes one, Avidemux’s honest two choices (keyframe Copy, or full re-encode) are the reliable path; the manual segment workaround covers the middle ground when you are willing to babysit the parameters.
This is an independent guide site and is not affiliated with the Avidemux developers. For the official project and forum, visit avidemux.org.
Frequently asked questions
What was Smart Copy in Avidemux?
Smart Copy was a feature of Avidemux 2.5.x that re-encoded only the short video sections around your cut points (roughly one GOP each) while copying everything else bit-for-bit. It delivered frame-accurate cuts with near-Copy speed and quality.
Why was Smart Copy removed from Avidemux?
Avidemux 2.6 rewrote the editing and frame-access engine, and the old Smart Copy code was tied to the 2.5-era decoder plumbing. According to forum discussion, complex B-frame dependencies in modern codecs and limited developer time meant the feature was never ported to the new architecture.
Can I get frame-accurate cuts in Avidemux 2.8.1 without re-encoding the whole file?
Copy mode cuts only on keyframes, so true frame accuracy always requires re-encoding something. You can either re-encode the entire file, or manually cut out the small section around the cut, re-encode just that section, and append the pieces back together with identical codec parameters.
Does LosslessCut have Smart Copy?
No. LosslessCut defaults to keyframe cutting like Avidemux’s Copy mode, and its experimental smart-cut feature is fragile across codecs. The practical answer in both tools is the same: accept keyframe cuts or re-encode.