Shotcut is tripping calculating timecodes


My understanding that Shotcut is using 30fps non-drop frame timecodes and it trips!

5th clip in the picture above is exactly 58 seconds long, yet 2:27;28 + 58 seconds exactly is 3:26;00 in Shotcut time :laughing:.

Not a big deal, but I wonder if this impacts EDL generation.

BTW, correct me if I am wrong, but AFAIK hh:mm:ss;ff is a Drop-Frame notation. Shotcut’s non-drop frame should be hh:mm:ss:ff, no?

Similarity for 60p materials the math doesn’t add up

00115.MTS 3rd cut is 7:56 long and starts at 49:00 exactly, yet highlighted cut starts at 56:57 instead of 56:56… If one would look carefully this sequence has 10 extra frames in timecode.

What is the frame rate of the MTS files? If it’s 29.97 or 59.94, then I wonder if frame drop/dupe to convert to an even 60fps is in play.

My material is all NTSC. That is in first example of 30 fps it is 29.97 and in second 60p example it is 59.94.

Math is wrong in both cases.

I handroll .mlt from .edl that I export from Adobe Premiere and I set actual frames in .mlt where my cuts are. I am confident that I feed Shotcut good cut points. Yet, I believe, Shotcut timecode math is wrong!

Since I feed Shotcut actual frames timecode doesn’t matter. Only it does, because Shotcut converts my frames into timecode once I open my handrolled .mlt and it trips!


Can you describe how this is done in your MLT generator? Is this specified in milliseconds like hh:mm:ss.mmm, or some other format?

You are correct. Note that the first screenshot is using drop-frame. The second screenshot is not using drop-frame… it is pure 60fps, so some frame duplication will happen to scale 59.94 up to 60fps. Shotcut changes the notation based on the Video Mode of the timeline. It supports both DF and NDF.

Actually, I’m a little confused on this as well now. In the first screenshot, there is a start point of 00:03:26;00 which is not a valid DF timecode. It should be 00:03:25;29 or 00:03:26;02. @shotcut Do these timestamps refer to “elapsed passing of time” rather than formal timecode, as in 00:00:00;15 refers to 15frames / 30fps = 0.500 milliseconds so the underlying engine can be based on time rather than frames? I don’t use the playlist, so this is all new to me and I’m guessing…

I set frames as in and out points in MLT generated from EDL. See attached Test.txt (890 Bytes)
When I open those MLT with Shotcut it converts those frames into timecodes and trips occasionally.

I use playlist to confirm that cuts are properly imported and they often do not match to timecodes in EDL.

More accurate statement would be that for 29.97 material it appears that Shotcut displays in playlist 30 fps non-drop frame timecode using drop frame notation.

As I mentioned I set actual frames in MLT generated from EDL, so it doesn’t matter as frames are frames for both drop frame and non-drop frame. However Shotcut times do not match drop frame EDL at all and apart from extra frames here and there more or less match non-drop frame EDL.

Interestingly enough for 29.97 material Shotcut always trips by 2 frames. While for 59.94 material sometimes it is 2 frames, sometimes it is 1 frame. This effect stacks with cuts and I have timelines with extra 6 to 10+ frames.

Let’s see if EDL and MLT have the same definition of in and out to account for the extra frames…

Let’s say we’re looking at a video with ten frames. Shotcut will number them 0 through 9.

If an edit says In=3 and Out=7, then it means the eighth frame (zero-based index 7) will be the last frame shown on screen, and the cut clip with have a total of 5 frames (counting 3 to 7 inclusive).

Is this the same understanding of In and Out that the EDL file and the EDL-to-MLT translator have?

And yes, I see your point about 30 fps NDF timing with DF notation. Shotcut tries to be frame rate agnostic by translating many things into milliseconds where possible. This allows clips with differing frame rates to be mixed on the same timeline without preprocessing. So it wouldn’t surprise me if what we’re seeing isn’t formal timecode, but rather an elapsed time reference with the resolution of the defined Video Mode. If that ends up being true, then unfortunately, it won’t be intuitive to translate the “timecode” seen in the playlist to exact frames in the source for confirmation.

Wrong. From Wikipedia

drop-frame timecode skips frame numbers 0 and 1 of the first second of every minute, except when the number of minutes is divisible by ten.

03:26 is not the start of minute 3.


While for 59.94 material sometimes it is 2 frames, sometimes it is 1 frame.

There are specific rules for when to skip frames for NTSC frame rate, but 59.94 fps is not NTSC and there are no specific rules; so, we just use a simpler math. Drop-frame notation is not used because it not NTSC drop-frame:

If you want to change it by pull request, then it must pass these unit tests that verifies that the timecode for every frame number converts back to the same timecode, which is extremely important:

1 Like

Is there any “industry standard” on 59.94 fps?

I am now wondering what Adobe means by say “00:00:56:35” when generating EDL for 59.94. Is it 3392 frame? Could there be different interpretation of what said “00:00:56:35” means?

Are In and Out frames “inclusive” in Shotcut?

I believe EDL spec interprets In as included and Out as excluded. That’s why in EDL an out-point of previous clip in timeline (last column) is the same as an in-point for next clip (last column -1), assuming that clips are joined.

Interesting. When generating FinalCut XML Adobe thinks that “00:00:56:35” is frame 3395.

Also FinalCut XML appears to assume that out-point is not included. I.e. same as with EDL, outpoint for previous clip on timeline is an in-point for next clip in FinalCut XML, assuming there is no gap

In MLT in and out are inclusive. out = in + duration - 1
In Shotcut Export EDL, it treats in as inclusive and out as exclusive.

Hmm, digging deeper it appears that both Adobe and Apple interprets 59.94 timecodes as Nominal frame-rate (that is 60 for 59.94) * seconds + number of frames. That is in my example of “00:00:56:35” timecode for Adobe and Apple it is frame 3395=54*60+35.

Shotcut interprets 3395 as having timecode “00:00:56.640” = “00:00:56:39” and previous 3394 frame as having timecode “00:00:56.623” = “00:00:56:38”

Does Shotcut uses actual frames or timecode internally?

frame numbers starting with 0.

So for 59.94 fps Shotcut timecode math should be (in my previous example of 0-3394 frames) 3394 *1001 / 60,000 = 56.623, right?

It is displayed as “00:00:56:38” and it doesn’t mean 56 seconds and 38 frames. It really means 56 seconds and 34 frames, right?

Confusing isn’t it?