Bug 478562 - Automatic Scene Split drifted if video > 2min
Summary: Automatic Scene Split drifted if video > 2min
Status: CONFIRMED
Alias: None
Product: kdenlive
Classification: Applications
Component: Rendering & Export (show other bugs)
Version: 23.08.4
Platform: Flatpak Linux
: NOR normal
Target Milestone: ---
Assignee: Jean-Baptiste Mardelle
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-12-15 15:31 UTC by red_Arti
Modified: 2024-01-19 15:16 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
autoScene-bug-demo (35.71 KB, application/x-kdenlive)
2023-12-15 15:31 UTC, red_Arti
Details

Note You need to log in before you can comment on or make changes to this bug.
Description red_Arti 2023-12-15 15:31:30 UTC
Created attachment 164196 [details]
autoScene-bug-demo

SUMMARY
Kdenlive's Automatic Scene Split fails to align the real scene changing points.

When video is short, the result is good.
Sometimes when video is longer than 2 min, all splitting points are a few frames later than where they should be.

I uploaded two video files, which are from same movie. 
I cut them into 20s and 2min length, and make them two start at same time
https://drive.google.com/drive/folders/16EpVuh4ZTyXEEc1Pkqvz60Pp0sXGCtzO


STEPS TO REPRODUCE
1. Download the attachment I upload (the Kdenlive project file)
2. Download 2 video files from the google drive link
3. Put the 2 video files into same path with project file. Open the project

OBSERVED RESULT
You can see the splitting points are not correctly aligned

EXPECTED RESULT
The splitting points of the two video clips should be correctly aligned


SOFTWARE/OS VERSIONS
Kdenlive 23.08.4 from flatpak 

ADDITIONAL INFORMATION
Comment 1 red_Arti 2024-01-18 03:34:01 UTC
I think I found where the problem comes from. ffmpeg gives different timestamps.

Two "start" timestamps are different: 
0.083 - 0.015 = 0.068
0.068 is the drifted time !

I don't know why ffmpeg think start time different. 
I cut and saved those two video files by Avidmux, from same movie file.

Can we do something in Kdenlive to correct that result?

----------------------------------------------------------------------------------

video-short.mkv

`ffmpeg -i` RESULT:
Input #0, matroska,webm, from 'video-short.mkv':
Duration: 00:00:23.45, start: 0.083000  <---------------- *** look at this ***
Stream #0:0: Video: DURATION        : 00:00:23.440000000
Stream #0:1: Audio: DURATION        : 00:00:23.450000000

GOR RESULTS:  (5.715, 5.756, 12.68, 18.352)  <---------------- *** look at this ***

`ffprobe packet=pts_time,flags` RESULT:
0.083000,K_
0.250000,__
0.167000,__
0.125000,__
---------------------------------------------------------------

video-long.mkv

`ffmpeg -i` RESULT:
Input #0, matroska,webm, from 'video-long.mkv':
Duration: 00:02:48.18, start: 0.015000  <---------------- *** look at this ***
Stream #0:0: Video: DURATION        : 00:02:48.168000000
Stream #0:1: Audio: DURATION        : 00:02:48.175000000

GOR RESULTS:  (5.783, 5.824, 12.748, 18.42,  ...)  <---------------- *** look at this ***

`ffprobe packet=pts_time,flags` RESULT:
0.084000,K_
0.250000,__
0.167000,__
0.125000,__
0.209000,__
Comment 2 Jean-Baptiste Mardelle 2024-01-19 15:16:07 UTC
We use an ffmpeg command to detect the scene changes:
ffmpeg -loglevel info -i source.mkv -filter:v "select='gt(scene,0.4)',showinfo" -vsync vfr -f null -
Then we extract the pts_time values.
Testing the command on your 2 source files, the filter effectively gives different results with a small offset as shown in Kdenlive. Not sure How this can be solved. I tried replacing vsync by the newer fps_mode, and test several values for it but it didn't make any change... 

Also, I tried remuxing the video-long.mkv file to MP4, using :
ffmpeg -i video-long.mkv -c:a copy -c:v copy output.mp4
And now the 2 videos are different, the transcoded output adds 2 duplicated frames at the start of the video, which now matches the detected scenes by Kdenlive.

Another option would be to try to detect the "start" value you mentionned in your comment in FFmpeg (as it is not available in Kdenlive) and substract it from the resulting timecodes...

Not sure what is the best way to solve this.