Issue with repeating segments at start of each export & merge clip

[SignpostMarv]

The fewer issues I have to read, the more new features I will have time to implement, so I ask that you please try these things first

• Try with the newest version from GitHub (also it might have already been fixed in latest nightly build)
• Read the documentation and FAQ, Known issues, Troubleshooting
• Search for your problem under Issues or Discussions
• This problem happens with all kinds of files that I try. For problem only with a particular file or type, use this other form instead

Operating System

Windows 11

Steps to reproduce

1. source a youtube video via yt-dlp that results in a .mkv video file
2. select several non-contiguous clips
3. export & merge

Expected behavior

File exports as expected regardless of container type, with maybe some differences depending on whether smart or keyframe cut is used.

Actual behavior

When exporting MKV clips to a new video with an MKV container, the preceding second or so leading up to the clip is repeated prior to the clip actually starting.

The problem does not exist when the clips are exported with an MP4 container.

mkv-export.txt
mp4-export.txt

Share log from developer tools

No response

[soup2002-rgb]

Having the exact same issue

[spk]

Reproducing with GNOME screen recorder .webm files on Linux.

The root cause is that GNOME's screen recorder produces .webm files with only a single keyframe at the very beginning (~0.005s). With -ss before -i and -c copy, ffmpeg must seek to the nearest keyframe before the cut point — which in this case is always the very first frame of the file. So every exported segment starts from the beginning of the original video.

You can verify this with:

  ffprobe -select_streams v -show_packets -show_entries packet=pts_time,flags -of csv input.webm | grep ",K"

On my file this outputs a single line: packet,0.005000,K_

LosslessCut runs:

  ffmpeg -ss '15.73207' -i 'input.webm' -t '9.65166' ... -c:0 copy

With no keyframes at the cut points, the output file contains all frames from 0.005s up to the segment end, not just the intended 15.73s–25.38s range. The container timestamps are adjusted correctly (starting at 0), but the actual frame data includes everything before the cut.

Workaround: Re-encode instead of stream copy (e.g. VP9 libvpx-vp9 -crf 18 -b:v 0), which allows frame-accurate cuts regardless of keyframe placement.

Possible fix: LosslessCut could detect sparse/missing keyframes at cut points and warn the user, or automatically fall back to re-encoding for those segments.

[SignpostMarv]

Workaround: Re-encode instead of stream copy (e.g. VP9 libvpx-vp9 -crf 18 -b:v 0), which allows frame-accurate cuts regardless of keyframe placement.

Possible fix: LosslessCut could detect sparse/missing keyframes at cut points and warn the user, or automatically fall back to re-encoding for those segments.

The workaround I got was to switch container format, no transcoding required?