Project is time-wise bigger in Shotcut than it actually is

[Snickbrack]

I am currently working on a Tool which creates a huge randomized collection of video-parts from a pre-made collection of videos.

Collection of Videos → My Tool → Huge Collection of randomized Video-Parts inside a MLT-File

I am using a custom-made C# Console Application to edit an MLT-“Template”-File. I call it a template because it has some placeholders like a ChainCollection or EntryCollection which are used to determine where to put the Video-Chain Entries or the Playlist-Entry Entries into the resulting MLT-File which is then used to render the Output-Video.

In my C# App I am loading all of the Input Videos (around 140 Videos) and generate Video-Parts which are used to determine which Parts should be used from an Input-Video.

In the above Screenshot you can see the “randomGeneratedMillisecondList”-List which holds the Amount of Milliseconds which are available for each of the input Videos.

I am then using this List to create a List of Parts of each of the Input Videos which are basicly just a split of the previous Amount of Milliseconds per Video and a random selection of Groups of Milisecond inside one Input Video.

The Output of this Method is the following List:

This List is as of now more or less the represantation of the resulting PlaylistEntry-Collection. The Start- and End-Times of the PlaylistEntries and the Videofile-Reference. There are 734 Elements in this List because each Video can result in 1-12 Groups of Video-Parts.

The next step is to place these Informations into the MLT-File (which I have appended to this post).

YoutubeShortsRandomize_638288277018814864.mlt (144.5 KB)

In this example I have following “numbers”:

Amount of Input Videos: 120
Length of Resulting Video: 15 Seconds
Average Amount of Milliseconds by each Input-Video: 125
Amount of Milliseconds used by all Video-Parts:

(The Amount is not 15000 because there are some rounding Issues in the Code but nothing related)

So you can see that the Video itself shouldn’t be longer than 15 Seconds.

But I have an Issue with the Project in Shotcut when I open it up.

Even the rendered Video is around 38 Seconds long.

How can this be?

Is there something with the Milliseconds of each of the Playlist-Entries?

[Snickbrack]

@shotcut Can you please explain why you have switched the Category?

[shotcut]

Your posts are not for normal Shotcut users and don’t belong in any of our categories.

Can you explain why you keep asking for help to make your app, which you have not fully explained or published its code? Why should I bother to help you, especially since you are not helping Shotcut’s code?

[shotcut]

Sorry I mistook you for another user whose name has a similar length and cadence.

Different Frames when using cuts inside Shotcut and in the Java FFmpegFrameGrabber class

I got an video, which is 14059 frames long. If I use it inside my java application and put a cut into frame 369 (at least the FFmpegFrameGrabber method getFrameNumber() says so), and then I put this cut into a .file and open this one in Shotcut, the frame is 3 frames off from where the cut should be. I found out, when I this: grabber.setFrameNumber(0); Frame frame; while ((frame = grabber.grabImage()) != null){ if (frame.image == null) continue; BufferedImage wholeFrame = converter.con…

Still, questions for custom code don’t belong in general help.

Your out times are probably wrong. The total duration equals the sum of its parts. The out is not equal to in + duration in MLT XML. out refers the time of the start of the last frame. Using frame counts duration = out - in + 1.

[Snickbrack]

I am a little bit suprised about the response. I am trying to improve the Project with my questions. Yes these questions are related to my app but my use-cases related to Shotcut/Melt like asked here can also be useful for others. Because I am not asking for Help regarding my App but about the Time-Handling for Clips used in a MLT-File. But I dont want to discuss this here.

And regarding your answer:

@shotcut

Your out times are probably wrong. The total duration equals the sum of its parts. The out is not equal to in + duration in MLT XML. out refers the time of the start of the last frame. Using frame counts duration = out - in + 1.

Aren’t these In- and Out-Times in Milliseconds? Because <producer id="black" in="00:00:00.000" out="00:13:42.433"> for example looks most likely to use Milliseconds. And I am also using Milliseconds for the Times.

And Milliseconds should be indipendent from Frames as is because it is an absolute time/length of a clip.

Is there a way to use Millisecond-Timings with Shotcut/Melt?

[Snickbrack]

And speaking of the In- and Out-Parameters, I can’t find anything in the Documentation about this. Maybe we could add it even for the MLTFramework. This will definitely be interesting for others.

[shotcut]

@Snickbrack

Milliseconds should be indipendent from Frames

MLT is not millisecond precision; it is frame-oriented. Time values convert to frame counts and vice versa.

[Snickbrack]

Okay. Thanks anyway.

[Snickbrack]

@shotcut

Using frame counts duration = out - in + 1.

Okay I had another look at it. As I can see the MLT XML Structure it is using the following Format for In and Out: hh:mm:ss.fff (Where fff are the Milliseconds using three digits)

So there is (or should) actually no Frame handling needed. And Shotcut should do the handling of the conversion from Milliseconds to Frames based on the FPS of each Video used.

But this is not happening here. (And this is not related to my App at all)

And your Calculation duration = out - in + 1 is equivalent to duration + in - 1 = out. And this should work if Frames or Milliseconds are used. You said there is some kind of Frame <-> Millisecond-Conversion.

So this confuses even more why the times are messed up in Shotcut.

Edit: Maybe there is some kind of bug in Shotcut which is related to Importing and Saving the MLT-File. Which wouldn’t affect MLT-File created outside of Shotcut and whcih are then wrongly calculated. Just an Idea.

[Austin]

MLT does conversion in a way that is fully reversible without ambiguity due to floating point precision errors. This can account for some unexpected time gaps, but they are consistent within MLT. See below.

Also remember to base all timestamps on the zero point of the timeline or clip. Don’t add one time span to the previous time span directly. There will be accumulation errors. Convert to frames, add frame counts together to get a new position, then convert the frame count back to a timestamp.

Problem with calculated timestamps

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:

[Snickbrack]

@Austin

Also remember to base all timestamps on the zero point of the timeline or clip. Don’t add one time span to the previous time span directly. There will be accumulation errors.

I dont really get this point. What does base all timestamps on the zero point mean?

[Austin]

Let’s say we have a project timeline with two clips on it back-to-back. The start and end times of clip 2 are relative to 00:00:00.000 on the timeline. To find the start time of clip 2, first convert the timestamp of clip 1’s end time to a frame number if it isn’t already, then add 1 frame to become the start of clip 2, and convert that frame number back to a timestamp. Don’t assume every frame in 29.97fps is 0.033 seconds and blindly add 0.033 to the end of one clip thinking it will produce the start of the next clip. Drift will happen. I’m not saying you did that… I’m just pointing out a common problem people encounter when writing their own code for Shotcut. If your code is posted somewhere, maybe one of us could offer more specific suggestions.

[Snickbrack]

Okay, so I found a way to handle this via FFMPEG directly. Shotcut is not flexible enough to handle this.

Thanks for the Comments.