Openshot-qt: Can the "cut" of frames between clips be avoided?

[Rrushen]

System Details:

• Operating System / Distro: Win10
• OpenShot Version: 2.4.1

Hi, new user and already liking the program!

I am putting together rendered still images, with separate scenes, into one final movie.

What I notice is that there is a snap/cut/clip between each added videoclip, making perhaps ~10frames disappear from each switch from one scene to another. (This is seen in the preview as well as the exported video).

Vimeo link: https://vimeo.com/263565181

I am not using any transition effects, the clips are "snapped" to each other in one single row in the timeline.

So, my question is if this is possible to avoid in any way? Is there some preset that makes this happen?

Thanks for a superb program!

Regards,
Rushen

[peanutbutterandcrackers]

Hey there!

I'm glad that you're liking OpenShot!

That is a known problem that needs to be fixed.

However, a simple work-around to it would be to overlap the clips and apply a transition, if that isn't much of a bother to you.
Another way would be to try out the latest daily build (the version of the program made after every small change made to the source code). Please head over to the download page and click on the 'daily builds' button and grab the latest version and see if this problem still persists there.

I hope that helps.

Please do note that OpenShot is a community effort and a labour of love (of mostly a single person). And everyone working to make it better are squireling time away to work on it. Therefore, it might be a while before all the bugs/issues are fixed/addressed. Please be patient with this project. We are all just normal people trying to help each-other out. Hopefully, the devs will soon have the time to fix this too.
[This bug is actually a high-priority one. And the devs have already been notified about this. It's just a matter of time before this is actually fixed.]

[DylanC]

@peanutbutterandcrackers - What bug does this relate to? Is this a duplicate?

[peanutbutterandcrackers]

Ooops. Turns out, this is not exactly a duplicate. The one I was thinking about was this. The frame-overlapping bug...

[N3WWN]

@Rrushen I don't suppose you could post a couple of the raw clips that you used to create this video so that we can replicate your exact issue?

[Rrushen]

a.zip
b.zip
c.zip
I added the raw images as clips, here are three sets of images (zipped) to be arranged in the a-b-c order.

[N3WWN]

Thanks @Rrushen !

Using these images, I am able to replicate your bug.

It appears that there is a problem with the frame rate of the imported sequence.

If I import the 100 image sequence into a 100 FPS project, the clip is 3.33s long (333 frames or 3.3 video frames per image). This should result in a 1 second long clip (100 frames).

If I import the 100 image sequence into a 60 FPS project, the clip is 3.33s long (199.8 frames or 3.3 video frames per image). This should result in a 1.66 second long clip (100 frames).

This doesn't sound right to me as we are importing a specific number of frames into an environment which has a frame rate. I believe that each imported image frame should occupy 1 video frame.

What this sounds like, to me, is that the 3.3 video frames per image is hard-coded into libopenshot somehow.

I will look into this...

[N3WWN]

Leaving some notes here, mostly in case someone else has an idea of how to fix this....

When an image or image sequence is imported, OpenShot uses QtImageReader to open the files. QtImageReader has a hard coded 30fps frame rate. This is fine for a single image, but for a sequence of images, it means that each image occupies 1/30s regardless of the current project frame rate because a clip has its own frame rate and from this a duration is determined.

When a clip is added to the timeline, the duration is used to adjust the frame rate of the clip on the timeline. 100 frames at 30 fps is 100/30 = 3.33s duration. When placed on any timeline, this 3.33s duration clip is retained at 3.33s.

One way to solve this is for QtImageReader to know the project frame rate (that of the timeline) and use that frame rate as the default. But, QtImageReader only has knowledge of the clips, not the timeline. The timeline has knowledge of itself and the clips and can use FrameMapper to adjust the frame rate of clips, but only after the Reader (QtImageReader, in this case) has assigned the current frame rate to the clip, so we're back where we started.

This solutions would bring about another issue of changing the project frame rate after the image(s) have been imported; a change in project frame rate would require closing and reopening, or perhaps removing and reimporting, the imported image file(s) in order to retain a frame-by-frame mapping to the project.

Perhaps another solution would be to have QtImageReader set an "unknown" frame rate to images, which will then be calculated when the clip is added to the timeline. That would remove the problem of changing the project frame rate because the "unknown" frame rate is stored for the imported image file(s) but a known frame rate would be part of the clip on the timeline so that frame rate changes would not affect the length of the clips already on tracks.

This is what I'm going to start looking at...

[N3WWN]

I've run into some problems resolving this. I’m struggling with figuring out how to tell libopenshot what the current timeline frame rate is when importing image sequences. Right now they are hard coded at 30 fps, which is not correct if the project is not 30 fps. I am trying to figure out a way to get 1 image per frame, but QtImageReader doesn’t know about the project or the timeline, as far as I can tell.

[stale[bot]]

Thank you so much for submitting an issue to help improve OpenShot Video Editor. We are sorry about this, but this particular issue has gone unnoticed for quite some time. To help keep the OpenShot GitHub Issue Tracker organized and focused, we must ensure that every issue is correctly labelled and triaged, to get the proper attention.
This issue will be closed, as it meets the following criteria: - No activity in the past 180 days - No one is assigned to this issue
We'd like to ask you to help us out and determine whether this issue should be reopened. - If this issue is reporting a bug, please can you attempt to reproduce on the latest daily build to help us to understand whether the bug still needs our attention. - If this issue is proposing a new feature, please can you verify whether the feature proposal is still relevant.
Thanks again for your help!

[N3WWN]

I think this should be verified in a current OpenShot before it is closed out as being stale. It was definitely a bug in the import procedure at the time.

[N3WWN]

Confirmed that the bug still exists with OpenShot-v2.5.1-dev2-1597049004-bf0159bb-7cec1822-x86_64.AppImage:

a.zip (100 images) imported as a sequence into a HD 1080p 100 fps profile = 3.33s clip
a.zip (100 images) imported as a sequence into a HD 1080p 30 fps profile = 3.33s clip

Issue remains with relatively current daily build.