I already explained everything, but you are still treating “Duration” in Shotcut = out in MLT, which it is not. I am not participating in this discussion any further.
It is also confusing how the 3rd clip in this example starts from 01:41:25 when 2nd clip of duration 44:46 starts at 56:38 and ends at 01:41:24. Yet 4th clip starts from 1:44:40 where 3rd clip of 3:15 ends.
EDL Export is definitely broken Shotcut.edl (756 Bytes)
It is due to this timecode “display issue”. Here is proper EDL for above example 09_04_Regatta.edl (785 Bytes)
I am not.
The problem is with the way Shotcut interprets timecodes. This results in definite bug with 59.94 fps EDL generation in Shotcut.
And it is not limited to 59.94 fps. Here is Shotcut generated EDL for 29.97 Shotcut.edl (231 Bytes) when it should be 2012-01-11.Denis.edl (260 Bytes)
I didn’t test 29.97 extensively and 29.97 example is not very drastic (just off by a frame here and there)…
Here is an example of “industry standard” timecode math implementation timecode-boss
Argh, I was reading fast and thought that 26 was the minutes instead of the seconds. Sorry.
Granted, but ffmpeg treats 59.94 as drop frame with double-length drops, I assume to make it overlay with 29.97 cleanly. There is a specific check at line 43 (invoked if AV_TIMECODE_FLAG_DROPFRAME is set):
I’m not saying anything should change. I’m observing that Shotcut is built on ffmpeg but treating timecode differently than ffmpeg in the case of 59.94, which may be useful information to some users.
This is from the screenshot in post 22. I confess I don’t understand this one either. I can reproduce it using File > Open Other > Color with each element set to the same lengths as the screenshot. Without drop frame in effect, I would assume the start of the third clip should be this:
00:00:56:38 start of 2nd clip
+
00:00:44:46 duration of 2nd clip
equals
00:01:41:23 end of 2nd clip
00:01:41:24 start of 3rd clip
But instead, the start of the 3rd clip is shown as 00:01:41:25.
At a bare minimum, if the duration is an even number of frames, then I would assume the start time of that clip and the start time of the next clip to both be odd or both be even. I don’t understand how adding an even number of frames to an even start time can result in the next clip having an odd start time. This happens very often to even-length clips in the 59.94 screenshots above. Is it a rounding thing?
It is not pure rounding error but mis-interpretation what timecode is plus rounding error.
Let’s start from what timecode is. In layman terms it is hh:mm:ss AND number of frames after last full second. Agreed? (in layman terms?)
So, in the example above, cut on 193.MTS is from 0 to 56 second plus 35 frames or from 0 frame to 54*60+35= 3395 frame (NOTE how nominal framerate of 60 vs 59.94 is used by “the industry”). Since EDL is not including out frame and Shotcut does, in MLT I properly set in point at 0 and out at frame 3394.
Shotcut interprets that 3394 frame as timecode 3394 *1001 / 60,000 = 56.623 internally; and displays and outputs it in EDL as timecode “00:00:56:38”. The industry interprets that 3394 frame as timecode “00:00:56:35”
Is it clear where those extra 3 frames come from in 193.MTS cut in the example?
Similarly for the 2nd and 3rd clip.
2nd clip starts at 01:18 or 60+18=78 frame and goes till “46th second plus 2 frames” per “industry standard” or till 46 * 60 + 2 = 2762 or including frame 2761 for Shotcut; and for total of 2684 frames that for Shotcut is 2684 * 1001 / 60,000 = 44.778 duration displayed as “00:00:44:46” timecode. For “the industry” this is a duration of “00:00:44:44” 2684-44*60=2684-2640=44 or 44 seconds and 44 frames (sorry my duration fall on 44 for both seconds and 44 frames 
). So 2nd line in proper EDL reads
00:00:01:18 00:00:46:02 00:00:56:35 00:01:41:19
For Shotcut it is
00:00:01:18 00:00:46:05 00:00:56:38 00:01:41:25
This is how the bug stacks - 3 extra frames from first clip and 2 extra frames from improper duration of the 2nd clip …
I hope it is clear now that this is not just a rounding error.
It is more evident on 59.94 material but same problem exist for 29.97 regardless of drop-frame vs. non-drop-frame. The nature is irrelevant of notation used.
Yes, something is weird is going on. I’m just looking at the viewer, I didn’t even get to examining shotcut’s EDL yet.
I’m just looking at the viewer and matching with a test video that has frame number, HH:MM:SS.ms, SMPTE DF, NDF timecodes stamped on . To make the filesize smaller it’s just 640x360p59.94. I confirmed the validity of this test video in Premiere Pro, and other programs - everything is working as expected
https://www.mediafire.com/file/w6fj1bn9bk0usoc/640x360p59.94.mp4/file
The first “glitch” in shotcut occurs after 00:00:16:58 , or frame 1018. The next frame in shotcut displays as 17:00, but should 16:59 (by any convention). The 2nd at 00:00:33:58, same jump in the next frame timecode to 00:00:34:00 , instead of 00:00:33:59. So it’s +2 now compared to either NDF or DF timecode.
But if I seek or jump into the file , sometimes it corrects itself and matches the DF timecode . eg. frame 4135 matches DF 00:01:08:59. But once it gets to that same point 1 min later, that 00:01:16:58 jumps over 00:01:16:59 on the next frame straight to 00:01:17:00
So depending on where you seek, you might be 0,+1,+2, or +3 deviation from DF timecode. Right after the minute markers, it matches until the 16-17th second where it is +1, 33-34th second +2, 50-51th second +3, etc… and on the true DF mark, it corrects to 0 for the 1st 3 minutes. But after that it doesn’t match the pattern. But the “jumps” seem to occur between the 16-17th second, 33-34th second
In case this was a long gop/ seek issue, I repeated with an I-frame format - same problem
Always a treat to hear from you @pdr. I can reproduce your findings but cannot explain them. The interesting thing about the glitch timing is that it takes 16.683 seconds to fall one frame behind at 59.94 compared to 60fps.
I’m still mystified by the previous problem. Maybe they’re related. Can somebody check my math?
In the playlist screenshot, 194.MTS (the second clip of post 22) has a start time of 00:00:56.38 and lasts 00:00:44:46. The question is when to start 196.MTS (the third clip). The screenshot says 00:01:41.25.
Step 1: Convert the start point 56s38f to a frame number.
56s * 60000 / 1001 + 38f = 3,394.6 which truncates to 3,394.
Step 2: Convert the 2nd clip’s duration into a count of frames.
44s * 60000 / 1001 + 46f = 2,683.3 which truncates to 2,683
Step 3: Add duration to the In point.
3,394 + 2,683 = 6,077
Step 4: Convert 6,077f to drop-frame timecode.
Not actual SMPTE reduction math shown, but is sufficient for here:
6077 * 1001 / 60000 = 101.3846166s
The 101 part is of course 60+41 = 1m41s.
The remaining 0.3846166 * (60000 / 1001) = 23.0539f which truncates to 23 frames.
However, we crossed a minute boundary that is not divisible by 10, so SMPTE says we drop frames, which means advancing the counter by 4 frames for 59.94fps video.
That would mean the final timecode is:
00:01:41:23 NDF
00:01:41:27 DF
Doing the same math but with a 60fps source:
00:01:41:24 NDF
00:01:41:28 DF
I don’t understand how to get 00:01:41:25. It’s like it dropped two frames instead of four.
The reason I’ve used 60000/1001 rather than 60fps is because the conversion to a frame number has to be done at the frame rate the footage was captured in. If a camera captured at 59.94 but the time-to-frame-number conversion was done at 60fps, the resulting frame number would be ahead (faster) than the actual frames coming from the camera.
Or so goes the theory.
Bingo!
According to shotcut math frame 1019 is 1019 * 1001 / 60000 = 17.00031(6) when it should be “16:59 (by any convention)”
Okay, finally found the problem. Shotcut appears to be calculating frames correctly. The “problem” is converting a frame number into a timecode that meets expectations.
We can’t expect to see frames 0 through 59 for every single real-time second because the source is only 59.94fps. The frame rate isn’t fast enough to enable 0 through 59 to exist for every single second. If it was, we would actually have 60fps video. A 59.94 frame is longer than 1/60th of a second, but we’ve been trying to mentally view 59.94 video as 60fps when we searched the player clock for sequential frames up through 59. However, every 16-ish seconds, a frame (since it’s longer than 1/60th of a second) is able to straddle a 1/60th slot, which looks like a frame skip, but is actually true to the passage of time.
The end result is that the clock in the Shotcut player is basically a wall clock that does the same thing as a millisecond clock, but with the resolution of frames instead of milliseconds. It does not have predictable skips or alignment like SMPTE does. It is not SMPTE DF and it is not sequential NDF. It merely displays the exact passage of time based on exact frame rate. It will never show “all frames” by virtue of the fact that all frames can’t exist in a fractional frame rate.
So, Shotcut appears to actually be right when it comes to representing the exact wall clock time of the playhead. But this value isn’t particularly useful or predictable. As in, EDLs are made with either DF or NDF timings, not wall clock timings. Same for hardware timecode master clocks, to which Shotcut is unlikely to sync by using a wall clock timing. There may be something to be said for enabling SMPTE with 4 drop frames on 59.94 video, which currently does not happen. Then we get a valid EDL along with a useful near-exact wall clock time for a human editor to view. If exact wall clock time is needed, we already get it implicitly from the time_clock_from_frames() function, so getting the same value from time_smpte_from_frames() is potentially redundant or misleading (since SMPTE is in the name).
As for why the screenshot timings don’t line up, well… now we know it all depends on whether some frames underneath were able to straddle a 1/60th slot.
To see the math in action, let’s take pdr’s example of frame 1019 which is 00:00:16.59 in NDF, but it is skipped by the Shotcut source player clock.
In the case of 59.94fps, line 978 says “secs = 1019 / 59.94” which is 17.0003 and naturally matches the wall clock (after skipping/straddling over frame 59) by using literal frames per second math. Doing “secs = 1019 / 60” results in 16.9833 and matches our frame 59 expectation. However, if we use 60fps math on frame 16052, the timecode will show the expected NDF value but be 16 frames behind a real-time wall clock, which is a problem of its own. pdr’s diagnostic video illustrates the drift perfectly, and this is why we can’t unilaterally impose 60fps timecode on a video made with 59.94 frame rate. SMPTE timecode is supposed to be the bridge between these two problems, but it isn’t being activated for 59.94 currently. Since Shotcut does not import timecode and has no self-imposed obligation to parse and match the timecode of the source, I see no harm in forcing 59.94 to use DF to produce valid EDL and to show time that’s reasonably close to exact wall clock. Thoughts?
I added rules for drop-frame on 59.94 fps for the next beta so the frame skipping is deterministic.
EDL Export is using different code (timecode npm module) and not affected by this change. Based on a quick code inspection, Shotcut appears to use its non-drop-frame mode although drop frame is available as an option. I have not investigated that further and have no immediate plans to. Someone else can: the javascript code is in your installation for you to hack on it.
I will try to add a Time Format option to the Settings menu by the end of the year that affects the UI wherever it currently shows timecode.
2 Likes
That’s awesome! When is the next beta? 
I looked at (timecode npm module) on github and I am afraid it has similar problem with 59.94 timecode. So my expectation is that 59.94 EDL Export might still be broken since I assume EDL Export gets frames from Shotcut and converts them to timecode and therefore will not be affected by the change.
Who maintains EDL Export?
I downloaded beta 2 and so far it handles 59.94 timecodes nicely.
As expected EDL Export is still broken since it uses timecode npm module that has the same timecode problem shotcut used to have. Also EDL Export crashes (with some JavaScript error) on timelines with 2 video tracks.
I’m not certain this EDL export will do what you want. I gather that the output format is based on CMX3600 which only supports one output track. Shotcut is not able to take multi-track video and determine transitions based on fade in/out filters, meaning the “tractor” dissolve method wasn’t used (at least, not determine without a lot of guessing and compositing).
Best I can tell, line 6814 of export-edl.js is the culprit, not timecode.js. Shotcut is not creating FCM statements in the EDL, so the EDL default of Non Drop Frame should pair nicely with timecode.js never having “drop_frame” set to True. However, if millisecond time is passed into export-edl.js, then it is converted to timecode on line 6815 using fractional frame rate (59.94) which takes us back to the wall clock issue.
What is the workflow you are envisioning? Shotcut for editing, then something else for grading and sound?
I think “the industry” disregard FCM statement in EDL for 59.94. At least Premiere outputs exactly the same In and Out Points regardless of FCM setting (yet outputs FCM 
)
The problem is not with FCM but rather “wall clock issue”
EDL Export generates wrong timecodes, exactly the same as Shotcut displayed prior to most recent beta.
I personally don’t care about EDL Export. Just passing information since some may want to export EDL and then wonder why they are getting wrong cuts in other software.
I actually use Premiere for editing (or my old FCP edits) and Shotcut for post and rendering. On some filters Shotcut (ffmpeg???) just faster and better than Adobe.
This topic was automatically closed after 90 days. New replies are no longer allowed.