[2.5.0] 240 FPS 1/8 Slomo Stutter

[mkarg]

Describe the bug: Applying "Slower > 1/8" on 240 FPS source footage produces stuttering 30 FPS file export.

Apparently importing fluent 240 FPS files drops seven of eight valueable frames, then eight times duplicates the same frame to produce stuttering slomo.

Steps to reproduce the behavior:

1. Produce fluent 240 FPS file (e. g. use action cam's "slomo" mode)
2. Pull footage on track
3. Apply "Slower > 1/8"
4. Render 30 FPS output
5. View the result in your player of choice

Expected behavior: Smooth 1/8 slomo running at 30 FPS.

Actual behavior: Stuttering 1/8 slomo running 30 FPS (actually holding each frame for the duration of eight frames).

System Details:

• OpenShot Version [e.g. 2.4.3]: 2.5.0
• Operating System / Distro: Windows 10

Log Files: N/A

Exception / Stacktrace: N/A

Screenshots: (Optional) N/A

[SuslikV]

This is rather limitation of the design than a bug. The chosen Preview profile in OpenShot ensures that length (duration in seconds) of the clip will be preserved during import, thus excessive frames are thrown away (to fit it into the 30 fps, for example). Later, the slowing this 30 fps clip by x1/8 is ~~reducing number of available frames even more~~ doubling available frames.

In short - behavior wouldn't be changed in nearby future. Maybe other options or workarounds will appear, but in the current PR's list nothing points to the new features that can do the trick.

[mkarg]

We should change the intended design then, as throwing away useful data and then duplicating the wrong frames eight times makes the "Slower > 1/8" function simply useless. Nobody wants stuttering videos, and nobody invests into a 240 FPS cam to just get his data thrown away. In essence, people will not use OpenShot.

[SuslikV]

It would be nice if some manufacturer will make changes to the open source code of the project to add this beautiful feature into OpenShot.

Google for optical flow slow motion source code for other types of slow-mo.

[mkarg]

I do not see why some manufacturer should do that as it is just a design flaw of openshot. You can produce smooth slomo with e. g. ffmpeg already (I use that as a workaround for this bug, infact -- see https://trac.ffmpeg.org/wiki/How%20to%20speed%20up%20/%20slow%20down%20a%20video).

[SuslikV]

Yeah, if FFmpeg filters support will be implemented, then this will be huge move to slow down... the export ^_^

It's not like design flaw - the implementation wouldn't change almost all available code or so. Simply, there is no much developers here. I made some changes to the OpenShot too, but my code is not very effective (I'm not a programmer by the way) and this is all I can do right now for the project.

If you can make it better - join! This is open source.

[mkarg]

Maybe you didn't see my official introduction back then. I am already a contributor to this project (working on effects mostly), and I am professional developer in my day job.

[SuslikV]

Then better to keep it as feature request not a bug.

[mkarg]

Then better to keep it as feature request not a bug.

Throwing useful data away and then copying the result n times is simply a bug. Not a programming bug, but a bug of the design. No user ever would understand if we redeclare cration of stutter as not-a-bug.

[SuslikV]

It will be much easier to remove the function until proper solution will be implemented just to not confuse the users.

In the code the mentioned x1/8 speed is looks like linear time key interpolation (possible result for 8s 120fps source at 30fps profile):

            "time": {
                "Points": [
                    {
                        "co": {
                            "X": 1.0,
                            "Y": 1.0
                        },
                        "interpolation": 1
                    },
                    {
                        "co": {
                            "X": 1921.0,
                            "Y": 241.0
                        },
                        "interpolation": 1
                    }
                ]
            }

Edit: Seems to be that Y is frame in Timeline, X is frame in Timeline too. Y=241-th frame at 30 fps is close to 8 sec - whole length of the clip, thus last second of movie is mapped to the 1921-th frame of the Timeline.

Here the new Y (frame from time) is taken according to the given X (Timeline's frame number). Clip consist of 240 frames (numbers 1-241) because everything on the Timeline should has Timeline's fps. Thus, these 1-241 frames just spreads over the 1-1921 frames with the linear interpolation.

https://github.com/OpenShot/libopenshot/blob/4f591c7b9447f8a3ce133698029cee4eab6c9b41/src/Clip.cpp#L314-L318

Nothing more is done in the code.

It is possible to rename the option to Expand the clip x8 times.

[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!

[BBI-YggyKing]

This bug / design flaw makes it impossible to use high frame rate source clips to achieve smooth slow motion. This issue should not be closed - it still happens in 2023.

[Colorjet3]

@jonoomph. This should be looked at.

[pragma-]

It's now almost August of 2024 and slowmo is still a horrible stuttery mess. I have to use kdenlive to get good smooth slowmo. Please fix this.

[Colorjet3]

I just submitted a Bug in the issues queue where the lead developer is now working off of. I also have flagged this as a top priority fix so hopefully it will be addressed in the near future.