Start with the arithmetic on the failure. The published keyframe listing for the test file shows keyframes at 0, 2.002, 4.004 and 6.006 seconds [9]. Extend that cadence and the sixth keyframe lands at 12.012, which is 0.388 seconds before the requested 12.4 start, and 0.388 is exactly the excess in the ffprobe duration of the copied clip [2][1]. That excess is the distance back to the previous keyframe, and every frame in the output is shifted earlier by the same amount [3].
Nothing is broken. Stream copy moves compressed packets without decoding them, and most frames in a compressed stream only describe the difference from their neighbours, so a keyframe is the only legal starting packet [4]. FFmpeg snaps backwards to the nearest one and reports the duration it actually wrote [4][2].
The segmentation that fixes it is three spans: start to the first keyframe after start, re-encoded; that keyframe to the last keyframe before end, stream copied; that keyframe to end, re-encoded [7]. If start and end sit inside the same GOP there is no middle, and the whole short span gets re-encoded [8].
Now treat the headline cost figure as a claim about someone else's content. "Encoding cost proportional to two GOPs instead of the whole file" [6] is a statement about GOP length, not about the script. At the sample cadence two GOPs is 4.004 seconds, which against a two-hour source is about 0.06 percent of the timeline [2]. Two conditions have to hold for that to transfer. The GOP has to be short relative to the clip you are cutting. The fragments have to be concat-compatible with the copied middle, which means matching codec, resolution, pixel format and audio parameters, read off the source rather than hardcoded in your preset [12].
The second condition is where a screen-recording library bites. Screen recorders and some camera output emit keyframes on scene change only, and the gaps there can be 30 seconds or more [10]. A 20-second request on that content fits inside a single GOP, the middle disappears, and you are back to re-encoding the span in full [3]. The keyframe distribution of your ingest, not the trim code, is the real spec for the feature [10].
The details in the helper code are worth reading before you copy any of it. Frame rate is parsed by splitting r_frame_rate on the slash so that "30000/1001" becomes 29.97, with no eval() anywhere near a string that came out of ffprobe [13]. The keyframe search uses a 1e-6 tolerance rather than comparing floats exactly [14]. The execFile call sets maxBuffer to 64 MB, which is the config line that tells you how large a full packet listing gets [15]. On a two-hour file that probe reads every packet header: fast, because it does not decode, but not free, so it wants caching per asset [11]. Keyframe positions never change for a given file, which makes this the rare cache with no invalidation story to write [11].
The published excerpt stops mid-import in smart-trim.js, so the fragment encoder flags and the concat invocation are not shown [17]. The transferable part is the segmentation rule and the probe, both of which the author reports working on FFmpeg 7.x and 8.x as well as the 9.0 "Lei" build it was tested against [16].
