Creating an EDL file with video that is 23.98 seems to have some sort of frame drift

[AlexLaframboise]

Description:

Creating an EDL from a 90min feature that is 23.98 seems to create an EDL file that has drifting timecodes. i.e, they start frame accurate, but as the timecodes increase in value from 00.00.00.00 they begin to become shorter/longer than the actual timecodes needed to be frame accurate.

Command:

scenedetect -v info -m 8 -f 23.98 -i '/Volumes/TB4 2T/!Sound Projects/WORK/FolderName/!!Picture/VideoName_Apple_ProRes_Proxy.mov' detect-adaptive save-edl -o '/Volumes/TB4 2T/!Sound Projects/WORK/FolderName/!!Picture'

Output:

All I've done is redacted the name of the video since its for an active project, and I've changed the extension of the EDL back to TXT to allow me to upload it to GitHub

VideoName_Apple_ProRes_Proxy.txt

Environment:
[PySceneDetect] PySceneDetect 0.6.6

System Info

OS macOS-15.2-arm64-arm-64bit-Mach-O
Python CPython 3.13.2
Architecture 64bit + Mach-O

Packages

av Not Installed
click 8.1.8
cv2 4.11.0
imageio Not Installed
imageio_ffmpeg Not Installed
moviepy Not Installed
numpy 2.2.3
platformdirs 4.3.6
scenedetect 0.6.6
tqdm 4.67.1

Tools

ffmpeg Not Installed
mkvmerge Not Installed

I trigger this command via Keyboard maestro to auto fill various parts of the command to then send keystrokes to Pro Tools (DAW used in post production). I've verified that its not something caused by my macro as the timecodes listed in the first column don't match a visible hard/fast cut in the respective video

[Breakthrough]

Are you sure the framerate is 23.98 exactly? Could you provide a deubg log as well? E.g. add -v debug --logfile log.txt to the beginning of your command and attach it. Feel free to redact filenames. If possible, could you also show what ffprobe knows about the file?

[AlexLaframboise]

If I need to be ultra exact, its 23.976, however I was still getting this issue before defining the frame rate as exactly 23.98.

and since I'm not well versed in using command prompts and the like, is an output from Shutter Encoder (which uses ffmpeg and ffprobe) sufficient?

and here's my log file that was created

log.txt

Would the fact I'm using apple's pro res proxy be an issue?

By the way, can I just say how great full I am for you creating this wonderful tool, I'm legitimately looking to replace a 800CAD tool with this library :)

[Breakthrough]

If I need to be ultra exact, its 23.976, however I was still getting this issue before defining the frame rate as exactly 23.98.

The FPS must be exact if you define it manually, so it needs to be 23.976. You shouldn't need to define the FPS manually in most cases. Let me know if that fixes the issue.

[AlexLaframboise]

Hi again, I've modified my script again following what you said previously. It still is showing the same behaviour even with the command now feeding the exact time code of 23.976.

Here's my attached Log File
log.txt

and the resulting EDL file,
REDACTED_LOCKED_031425_Apple_ProRes_Proxy.txt

To help with this, I've also done the same test with a video I do have rights to share, converting with the same process as used for the redacted video and I've gotten the same results... However when using this video as normal in its native 25fps framerate, everything worked smoothly.

Here's a video showcasing the drift in an actual session,

2025-04-08.21-06-52.mp4

And log files and the EDL for this conversion

log.txt

2398life_of_mammals_01_winning_design_Apple_ProRes_Proxy.txt

EDIT;
I've also now tried with a MOV file with the Avid DNxHD Codec and the same issues crop up.

[Breakthrough]

To help with this, I've also done the same test with a video I do have rights to share, converting with the same process as used for the redacted video and I've gotten the same results... However when using this video as normal in its native 25fps framerate, everything worked smoothly.

1. Does that mean you're only seeing this for specific framerates, and it doesn't happen for certain inputs?
2. Does this happen for source material in it's original framerate, or only after conversion to a different rate?

I've also now tried with a MOV file with the Avid DNxHD Codec and the same issues crop up.

Do you suspect the issue is related to a specific codec? If so, could you try running using the PyAv backend (add -b pyav to the beginning of the command) and let me know if there's any difference?

[AlexLaframboise]

Do you suspect the issue is related to a specific codec? If so, could you try running using the PyAv backend (add -b pyav to the beginning of the command) and let me know if there's any difference?

Just ran again with pyav and still experiencing the same issues, although there does seem to be a different amount of cuts.

As far as you're aware, should PySceneDetect function with any valid codec? ie, major codecs supported by ffmpeg?

[Breakthrough]

Do you suspect the issue is related to a specific codec? If so, could you try running using the PyAv backend (add -b pyav to the beginning of the command) and let me know if there's any difference?

Just ran again with pyav and still experiencing the same issues, although there does seem to be a different amount of cuts.

As far as you're aware, should PySceneDetect function with any valid codec? ie, major codecs supported by ffmpeg?

Interesting, I wonder why the difference is there... It should work with most codecs, but that depends on what backend library you're using, and how it was compiled for your system. That's also why we support different backends, for folks with different needs. Could you respond to the two questions I posted previously? And please do provide a sample if possible.

It's possible I missed something when I added the save-edl command, but in my testing (including 23.976 FPS videos), it seems to work smoothly.

[AlexLaframboise]

Hey there! sorry, life got in the way... do you have a suite of tests that you would recommend?

in response to you questions above;

1. It seems to happen with a small collection of inputs at any frame rate (23.98) as both a ProRes Proxy and DNxHD 36) from shutter encoder.
2. seems to not matter the frame rate to a certain extent. the video that was cause issues was not working at either 23.98 or 24, but would work correctly at 25 fps.

as a side note, with the EDL format, would it be possible to enable an argument that allows offsets in the outputted timecodes? An example would be that video files I work with have an onscreen timecode that starts at 01;00;00;00 but the resulting frame rates in the EDL start at 00;00;00;00 - This would be a massive convenience feature while also speeding up some workflows if using the EDL files with tools such as EdiLoad.