So the problem is: I want to write a code that automatically creates an .mlt file with cuts on the exact position where they need to be. Sometimes they are, but sometimes the cuts are a few frames before or after.
It seems like there is still a problem in shotcut with calculating the correct timestamps. Is there a pattern, which I can use for my code so even if the cuts would be actually wrong, they are correct inside shotcut? Or is there alreaydy a fix or another workaround? If not I would have to use another cutting-tool where the timecodes are correct.
Maybe there is a difference in the timecode calculation. You do not state what your project frame rate is and whether you are calculating the drop frame. To help you understand the timecodes better, I suggest you first use Shotcut to make the cuts you want, see what timecode Shotcut calculates, and then make sure your own math agrees with it.
If all the timecode stuff is too complicated, Shotcut also understands frame numbers or a time indication with a decimal point for seconds.
For example, to indicate the 100th frame in 60fps video, you could use:
Frames: 100
Time: 00:00:01.67
Timecode: 00:00:01:39
Note that timecodes start with 00:00:00:00, not 00:00:00:01
If you are confident that the frame is being indicated correctly, then maybe the problem is that Shotcut is not able to seek accurately in your files. To test that, and understand better, you could use Shotcut’s “Convert…” feature on one of your clips and then try using that in your testing. If you get the correct frame cuts on the converted files, and not on the original files, then that is probably the problem.
So the last timecode in chain13 in my version is calculated kind of like this:
Frame 2272 / FPS 29.97 = 75,8091424758091…
So 1 minute + 15 seconds and 809 milliseconds (= 75,809 seconds). But why does Shotcut calculate 814 milliseconds. This even gets worse, the longer the video is. Can someone who knows the answer, give me a correct java code for shotcuts variant of calculating these timecodes too?
Here is the code. If you attempt to state how it is wrong, bear in mind that it was written to make unit tests pass the enforce that a conversion from frame count to timecode and back to frame count (see other code in the same file) gives the same count for every 32-bit signed int. Any suggestion on your part must be in the form of a pull request that passes the unit tests included in the repo:
Don’t mind that extra line thats just because I added another one for a test. Thanks in advance.I just translated the “time_clock_from_frames”" function to java ad I testet the 30*1000/1001 fps variant but also the 29.97 variant
Maybe this is a result of different floating point math implementations in the C vs. Java compilers. You do not need to make the MLT XML with time format exactly the same as Shotcut. Shotcut uses time clock format to try to retain fidelity when changing frame rate while changing Video Mode. If you want you can just write frame counts.
So I can just write 00:00:12:06 instead of 00:00:12:177 for the mlt in Shotcut? But then I anyways need to calculate the hours, minutes and seconds. There will still be different calculations, at least it could be bad for very very long videos. Now there is just an offset of 5 milliseconds in an 7:50 minutes video, but there will be a whole second for videos of many hours, I mean I could try at least. Thank you
Yes, what you showed is called SMPTE timecode. That works as well. Shotcut (MLT) decides if it is timecode or time-clock (with milliseconds) format based on whether there is a period character. What I meant is that for this time value you can also write only 365, which implies as 0-based frame count. This is accepted when there is no colon character in the time string.
By the way, I found out that my new timecode code was correct. I just created the wrong values for frame_rate_num and frame_rate_den in the .mlt file. I found it out by creating a project from the original video and inspected all differences from what I created. Now the question is, how can I automatically generate or get the actual frame_rate_num and frame_rate_den value despite by creating a project and copy and paste these values into my generator by hand?
num = numerator, den = denominator
I suggest to stick to standard frame rates, but if you want to do something like Automatic Video Mode, run melt -consumer xml {input-filename} or melt -consumer xml:{output-filename} {input-filename} to get the the <profile> tag.