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

Activity

1. soup2002-rgb commented on Mar 16, 2026

   

   soup2002-rgb

   on Mar 16, 2026

   More actions

   Having the exact same issue
2. spk commented on Mar 18, 2026

   

   spk

   on Mar 18, 2026

   More actions

   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.
3. SignpostMarv commented on Mar 18, 2026

   

   SignpostMarv

   on Mar 18, 2026

   Author

   More actions

   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?
4. mifi commented on May 30, 2026

   

   mifi

   on May 30, 2026

   Owner

   More actions

   I couldn't find a way for yt-dlp to download an mkv file directly, but I can get it to download an mp4 file (with h264):

   yt-dlp -f 136 'https://www.youtube.com/watch?v=zgaN8OXLaOQ'

   ...but when i open it in losslesscut and export it outputs the correct starting keyframe regardless of which output format i select (mp4/mkv). The cut i did is:

   {
     start: 4.333333,
     end: 9.5,
   }

   (2nd keyframe is at 4.333333, 1st is at 0.)

   I can also get yt-dlp to download a webm file (with vp9 video):

   # webm
   yt-dlp 'https://www.youtube.com/watch?v=zgaN8OXLaOQ'

   ...and i can reproduce your problem (I think) when cutting it and exporting as mkv: it will start from the first keyframe (time 0) instead of the desired keyframe at 4.333333. But when I select mp4 output format it plays from the correct keyframe at 4.33333 (with VLC because quicktime/macos doesn't allow playback of vp9 inside mp4).

   So it works differently between mp4 and mkv, with otherwise the exact same ffmpeg command. I would most definitely say that this is yet another bug or quirk in FFmpeg which makes it even harder to reason about how FFmpeg chooses the start cutpoint. I will update docs.
5. mifi commented on May 30, 2026

   

   mifi

   on May 30, 2026

   Owner

   More actions

   I've added a reference to this in #1216 - so i'm closing this issue because i don't know how to fix this also

   👍React with 👍1Reacted by SignpostMarv
6. mifi

   closed this as not plannedon May 30, 2026
7. mifi

   added a commit that references this issue on May 30, 2026

   fix keyframe warn logic

   ...

   2605307
8. mifi

   added a commit that references this issue on Oct 18, 2026

   Compensate ffmpeg's B-frame seek offset for Matroska keyframe cuts

   ...

   1c4bb77
9. mifi commented on Oct 18, 2026

   

   mifi

   on Oct 18, 2026 – with Claude

   Last edited by mifi

   Owner

   More actions

   I think I found the cause of this: for mkv/webm files with b-frames, ffmpeg seeks 3/23s earlier than asked, so a cut starting on a keyframe would start from the previous keyframe, repeating a part of the video at the start of each cut. #3131 should fix that and it's in the nightly now https://mifi.no/llc/nightly/ - it's only been tested on synthetic files so far, so would be great if you can try it