The timecode required by the imported EDL file in DaVinci Resolve's scene cut detection function is 1 frame different from the timecode exported by PySceneDetect.

[tanglangxia]

Description:

Slice of EDL format content exported by PYSCENEDETECT:

001  AX V     C        00:00:00:00 00:00:01:16 00:00:00:00 00:00:01:16
002  AX V     C        00:00:01:17 00:00:03:14 00:00:01:17 00:00:03:14
003  AX V     C        00:00:03:15 00:00:05:05 00:00:03:15 00:00:05:05

DaVinci Resolve
DaVinci Resolve's scene cut detection will directly use 00:00:01:16 as the start of 002 instead of the correct 00:00:01:17

However, if I change the data to the following, it imports correctly:

001  AX V     C        00:00:00:00 00:00:01:17 00:00:00:00 00:00:01:17
002  AX V     C        00:00:01:17 00:00:03:15 00:00:01:17 00:00:03:15
003  AX V     C        00:00:03:15 00:00:05:06 00:00:03:15 00:00:05:06

Because the current detection is only a rough detection, DaVinci Resolve's scene cut detection can be used to correct and adjust the clips to the correct size before importing them into the software.

In addition, we hope that PySceneDetect can support reading EDL files for video cutting and saving pictures in the future，thank

[Breakthrough]

Could you provide some more information about the file you're processing (e.g. framerate) and how you're generating the EDL file? I tested locally with quite a few inputs and I never had any off-by-one issues. If you can include some debug logs too that may be useful.

There was a report of this in #502 but that was due to an inaccuracy in the framerate specified by the user. Does this happen with all inputs or just a specific one?

PySceneDetect can support reading EDL files for video cutting and saving pictures in the future

This is possible, you are welcome to file a feature request for this. I assume we would add a load-edl command similar to load-scenes.

[Breakthrough]

Sorry I misread the output, I see the issue now:

DaVinci Resolve's scene cut detection will directly use 00:00:01:16 as the start of 002 instead of the correct 00:00:01:17

I was not aware of this, but I can certainly add a flag or a fix for this.

[Breakthrough]

@tanglangxia I am going to release v0.6.7 very shortly. It includes a fix for this. Thank you for the bug report.

[tanglangxia]

Thanks for the fix