split-video sometimes cut at wrong frames/length #479
Description
Description:
With one particular video file (which I think I can share privately if needed) I noticed that created cut scene files generated by this command did not have the correct length in frames reported in the SceneTimings.csv file. Yet with recoding, in this case lossless, according to the doc (https://trac.ffmpeg.org/wiki/Seeking) the ffmpeg -ss commands should ensure accuracy.
scenedetect -i “%_InputFile%” -b pyav load-scenes -i SceneTimings.csv -c “Start Frame” split-video -a “-map 0:v -c:v libx264 -preset veryfast -crf 0 ” -f $SCENE_NUMBER.mkv
(With SceneTimings.csv generated by scenedetect -i “%_InputFile%” -b pyav -s stats.csv --min-scene-len 10s detect-adaptive --weights 1 1 1 list-scenes -s -f scenesTimings.csv but it should not affect the behavior)
I also tried split-video with -m flag and manually running the ffmpeg commands with the values reported in the SceneTimings.csv file with different seek methods which I report in the following table where there is the number of frames per scene calculated with the command:
ffprobe -i “%SceneNumber%.mkv” -select_streams v:0 -count_frames -show_entries stream^=nb_read_frames -v quiet -of csv^=“p=0” >> framelist.txt
| Scene n. | SceneTimings Frames | scenedetect -m | Diff | scenedetect mkv out | Diff2 | scenedetect mp4 out | Diff3 | ffmpeg mkv | Diff4 | vf select | Diff5 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 683 | 684 | 1 | 679 | -4 | 679 | -4 | 653 | -30 | 655 | -28 |
| 2 | 358 | 380 | 22 | 359 | 1 | 359 | 1 | 257 | -101 | 257 | -101 |
| 3 | 306 | 304 | -2 | 306 | 0 | 306 | 0 | 287 | -19 | 289 | -17 |
| 4 | 334 | 309 | -25 | 333 | -1 | 333 | -1 | 316 | -18 | 314 | -20 |
| 5 | 286 | 355 | 69 | 289 | 3 | 289 | 3 | 281 | -5 | 284 | -2 |
| 6 | 573 | 506 | -67 | 572 | -1 | 572 | -1 | 255 | -318 | 254 | -319 |
| 7 | 277 | 330 | 53 | 275 | -2 | 275 | -2 | 244 | -33 | 243 | -34 |
| 8 | 314 | 284 | -30 | 316 | 2 | 316 | 2 | 228 | -86 | 230 | -84 |
| 9 | 324 | 301 | -23 | 324 | 0 | 324 | 0 | 254 | -70 | 254 | -70 |
| 10 | 269 | 269 | 0 | 269 | 0 | 269 | 0 | 251 | -18 | 251 | -18 |
| 11 | 301 | 342 | 41 | 299 | -2 | 299 | -2 | 257 | -44 | 257 | -44 |
| 12 | 328 | 288 | -40 | 331 | 3 | 331 | 3 | 344 | 16 | 346 | 18 |
| 13 | 305 | 351 | 46 | 302 | -3 | 302 | -3 | 274 | -31 | 274 | -31 |
| 14 | 268 | 219 | -49 | 268 | 0 | 268 | 0 | 333 | 65 | 334 | 66 |
| 15 | 257 | 262 | 5 | 259 | 2 | 259 | 2 | 291 | 34 | 289 | 32 |
| 16 | 248 | 304 | 56 | 246 | -2 | 246 | -2 | 264 | 16 | 266 | 18 |
| 17 | 266 | 205 | -61 | 266 | 0 | 266 | 0 | 256 | -10 | 257 | -9 |
| 18 | 268 | 307 | 39 | 268 | 0 | 268 | 0 | 270 | 2 | 271 | 3 |
| 19 | 271 | 304 | 33 | 271 | 0 | 271 | 0 | 284 | 13 | 285 | 14 |
| 20 | 286 | 214 | -72 | 287 | 1 | 287 | 1 | 247 | -39 | 247 | -39 |
| 21 | 352 | 352 | 0 | 352 | 0 | 352 | 0 | 247 | -105 | 247 | -105 |
| 22 | 305 | 346 | 41 | 307 | 2 | 307 | 2 | 441 | 136 | 440 | 135 |
| 23 | 274 | 284 | 10 | 272 | -2 | 272 | -2 | 294 | 20 | 294 | 20 |
| 24 | 270 | 219 | -51 | 269 | -1 | 269 | -1 | 243 | -27 | 245 | -25 |
| 25 | 295 | 313 | 18 | 296 | 1 | 296 | 1 | 398 | 103 | 398 | 103 |
| 26 | 302 | 284 | -18 | 301 | -1 | 301 | -1 | 360 | 58 | 358 | 56 |
| 27 | 265 | 324 | 59 | 265 | 0 | 265 | 0 | 354 | 89 | 355 | 90 |
| 28 | 261 | 228 | -33 | 261 | 0 | 261 | 0 | 262 | 1 | 263 | 2 |
| 29 | 460 | 436 | -24 | 461 | 1 | 461 | 1 | 335 | -125 | 335 | -125 |
| 30 | 260 | 258 | -2 | 258 | -2 | 258 | -2 | 597 | 337 | 599 | 339 |
| 31 | 414 | 414 | 0 | 414 | 0 | 414 | 0 | 312 | -102 | 311 | -103 |
| 32 | 375 | 377 | 2 | 377 | 2 | 377 | 2 | 370 | -5 | 371 | -4 |
| 33 | 379 | 451 | 72 | 378 | -1 | 378 | -1 | 431 | 52 | 431 | 52 |
| 34 | 273 | 228 | -45 | 272 | -1 | 272 | -1 | 314 | 41 | 315 | 42 |
| 35 | 354 | 380 | 26 | 355 | 1 | 355 | 1 | 447 | 93 | 447 | 93 |
| 36 | 624 | 588 | -36 | 622 | -2 | 622 | -2 | 1405 | 781 | 1400 | 776 |
| 37 | 332 | 380 | 48 | 333 | 1 | 333 | 1 | 266 | -66 | 264 | -68 |
| 38 | 387 | 380 | -7 | 386 | -1 | 386 | -1 | 546 | 159 | 547 | 160 |
| 39 | 450 | 456 | 6 | 450 | 0 | 450 | 0 | 260 | -190 | 262 | -188 |
| 40 | 467 | 401 | -66 | 467 | 0 | 467 | 0 | 294 | -173 | 292 | -175 |
| 41 | 1486 | 1486 | 0 | 1486 | 0 | 1486 | 0 | 305 | -1181 | 305 | -1181 |
| Sum | 15107 | 15103 | -4 | 15101 | -6 | 15101 | -6 | 14327 | -780 | 14336 | -771 |
I noticed that the split made by scenedetect split-video using ffmpeg does not have the total frames as that of the original video, and neither do the manual ones using ffmpeg (-ss before or after -i, and -vf select="between(n,start_frame_num,end_frame_num) ).
The split that comes closest is with mkvmerge but it does not precisely cut each scene in the chosen timestamps.
Environment:
scenedetect version
[PySceneDetect] PySceneDetect 0.6.5
[PySceneDetect] Loading user config file:
C:\Users\A\AppData\Local\PySceneDetect\scenedetect.cfg
System Info
------------------------------------------------------------
OS Windows-10-10.0.19045-SP0
Python CPython 3.13.0rc1
Architecture 64bit + WindowsPE
Packages
------------------------------------------------------------
av 13.1.0
click 8.1.7
cv2 4.10.0
imageio 2.36.0
imageio_ffmpeg 0.5.1
moviepy 2.1.1
numpy 2.1.3
platformdirs 4.3.6
scenedetect 0.6.5
tqdm 4.67.1
Tools
------------------------------------------------------------
ffmpeg 7.1-full_build-www.gyan.dev
mkvmerge v88.0 ('All I Know') 64-bit
Media/Files:
The SceneTimings.csv :
If it is needed, perhaps to replicate or create a test, I can privately send the video file somehow.
EDIT: After looking at the mediainfo of the input file, it reports variable frame rate for the video.
Could it explain the mismatch between the frames written in SceneTiming.csv and the actual frames in the cuts?