Openshot-qt: Panning completion time varies with export fps setting.

[Just-Curious]

Using OpenShot 2.1.0 on Windows 10 Pro

I am panning across a 11996x2241 picture with the default profile set to HD1080p, 60 fps. The scaling is set to 3.0 and the animation is set to Entire Clip | Edge to Edge | Right to Left. Exporting to HD1080p, 60 fps results in a correct pan across the entire image in 20 seconds.

If I export using HD1080p, 30 fps, the video takes 20 seconds to pan across only 1/2 of the picture.

Alternatively, if I start with the default profile set to HD1080p, 30 fps, exporting at 30 fps is correct, but exporting at 60fps pans the entire picture in the first 10 seconds.

This also happens using version 2.1.0 on MAC OS10. And, I installed openshot (version 1.4.3) on my Raspberry Pi running Jessie, but it crashes while exporting and does lots of other strange things.

[Just-Curious]

Hello,

I've just downloaded version 2.3.2 and tried this exercise again, this time by importing the project file and then changing the default profile from 1080p 60 fps to 1080p 30 fps. When played at the 60 fps setting, the entire picture is panned across in 20seconds; at 30 fps, only half the picture is panned across in 20 seconds. I've zipped up the project file, source file, and a video of the results described.

Aku.zip

It doesn't seem right to me.

[DylanC]

@Just-Curious - Thanks for the details here. I will test this soon.

[Just-Curious]

Thanks for responding! Here is a link to results from version 2.3.4:

https://1drv.ms/u/s!AjUees71jgJMgcst5xzBnRO_RYnVQQ

[DylanC]

@Just-Curious - Thanks. I have this downloaded to my machine. I will look at this today or tomorrow.

[Just-Curious]

No change in version 2.4

[Just-Curious]

No change in version 2.4.1

[DylanC]

@Just-Curious - Thanks.

[ferdnyc]

I just re-read this report again, with a better understanding of... well, OpenShot, really, compared to the first time I read it.

Am I correct in saying that the issue can basically be summed up as, "Exporting at a frame rate other than the project frame rate causes timing issues in the output video?"

(Because, if so, then that's a well-known issue. Changing the frame rate on export is not currently supported. Honestly, we've discussed disabling the ability to do that completely, even though that would cause considerable pain to users, and probably would if we could find a clean, understandable way to do it. Because the fact is, even though it's _not_ currently prohibited, it doesn't work even remotely right, and allowing people to try is... misleading, almost?)

[DylanC]

@ferdnyc - I don't think we should allow users to do actions that can cause more issues.

[ferdnyc]

Oh, I agree. The tricky thing about _prohibiting_ it, though, is that not every frame rate is valid for every export profile. So, really, we shouldn't be allowing them to choose format on export at all, they should have to export to the same profile the project is set to.

And then the issue with _that_ becomes the fact that, well... as things stand right now, changing the project profile to one with a different frame rate is also broken, for existing projects. (If they use any keyframes at all, they get smeared clear across the Timeline, because they're stored by frame number and those frame numbers aren't recomputed when the frames _move_ on a frame-rate change.)

So, really, we're left with telling people that they have to pick a frame rate in the very beginning when they start creating their project, and then they're stuck with it forever. And the only recourse if they need a _different_ frame rate is to start a new project at that frame rate, then recreate all of the Timeline contents at that rate. It's... not a great situation.

(It's also discussed in #1438 (and at _great_ length. because I am apparently in love with the sound of my own voice/typing). The outcome of what I'm optimistically calling a discussion, even though it's mostly just me droning on, is @N3WWN saying he has code working to prevent exactly the action being reported in this bug — exporting at a frame rate different from the project rate — and PR #1557 was created to track that code. But that PR never left WIP status, it was done against the master branch so now it's out of date, and that was around the time @jonoomph dropped off the face of OpenShot so it never got looked at for completion or possible merging. And now @N3WWN is MIA as well, so I really don't know what the status is of anything anymore.)

[ferdnyc]

But I guess the long and short of it is, this bug can probably be closed as a duplicate of #1438. Even though this report is _far_ older, that's where we've been tracking/documenting the core issue.

[peanutbutterandcrackers]

Closing this one as per @ferdnyc's suggestion. Please follow the discussion over at #1438