Openshot preview does not match exported clip (1/4 speed slice not exporting correctly) #1438
Comments
|
I am not so sure about the issue itself but could you perhaps please give the latest daily build a shot? Please head over to the download page and click on 'daily builds' button and grab the latest one; uninstall the current OpenShot version and install the latest build, and see if this still persists in the latest version. Thanks! |
|
P. S: Thank you for the good report. It is very thorough. I'm sure it will help the devs understand the issue really well (and hopefully fix it really soon). |
|
Will give it a try later this evening. Lol, I work as a senior software
engineer, so, used to doing bug reports.
…On Thu, Mar 29, 2018 at 9:32 PM, peanutbutterandcrackers < ***@***.***> wrote:
P. S: Thank you for the good report.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1438 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AfXFVeRZClLYyRbG9WZCrxNv5OmiccLlks5tjbVegaJpZM4S_9Lj>
.
|
|
I installed the latest build and recreated the steps and the issue remains.
…On Thu, Mar 29, 2018 at 9:32 PM, peanutbutterandcrackers < ***@***.***> wrote:
I am not so sure about the issue itself but could you perhaps please give
the latest daily build a shot? Please head over to the download
<https://www.openshot.org/download/> page and click on 'daily builds'
button and grab the latest one; uninstall the current OpenShot version and
install the latest build, and see if this still persists in the latest
version. Thanks!
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1438 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AfXFVWIEAXwWGCBqZ4qxj12PdG5aPzZUks5tjbVKgaJpZM4S_9Lj>
.
|
|
Also, if you have a ftp site, I have the actually files that I can upload. One is 8 GB though and the other only 100 MB |
|
@jmollo310 - Perhaps can you upload the 100MB zip somewhere and provide us a link? |
|
I can not reproduce the issue with smaller clips. The two mp4 files are
100 MB and 8 GB respectively. And, they zip into approx. 8.1 GB. Even my
google drive won't take a file of that size. Anyone know of any other
option?
…On Sat, Mar 31, 2018 at 1:35 AM, DylanC ***@***.***> wrote:
@jmollo310 <https://github.com/jmollo310> - Perhaps can you upload the
100MB zip somewhere and provide us a link?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1438 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AfXFVa3gwMRQpjjBzjFbIKYzIQ4tzugjks5tjz_OgaJpZM4S_9Lj>
.
|
|
@jmollo310 - Dropbox, perhaps? o.O @DylanC - You sure you are willing to test that big file, Cap'ain? :D |
|
@peanutbutterandcrackers - Of course! :) |
|
Please try this link to download. These will be the same files used.
https://www.dropbox.com/s/yef20vampv3ythl/PlayerUnknown%27s%20Battlegrounds.zip?dl=0
. Dropbox is saying I am all out of space so I'm not sure if I will need
to upgrade the account before the link works.
…On Fri, Apr 6, 2018 at 12:26 AM, DylanC ***@***.***> wrote:
@peanutbutterandcrackers <https://github.com/peanutbutterandcrackers> -
Of course! :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1438 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AfXFVZgMafIyUsFqxIyEixR5audPssSKks5tlxjAgaJpZM4S_9Lj>
.
|
|
I think the link works as it lets me start the download. |
|
@DylanC - Cap'ain? We need your help here, good sir! |
|
@peanutbutterandcrackers I'll have a look. |
|
@jmollo310 - Do you have a smaller example? Maybe 2Gb or something? I have the folder downloaded but not enough disk space to extract it. |
|
The zip file did not really do much compression if any. So, in it there
would be 2 files of 100MB and 8.3 GB.
I can try to split the video using ffmpeg. Something like this to retain
original format: ffmpeg -i myfile.mp4 -c copy -ss 00:01:30 -to 00:03:00
newfile.mp4
I just tried a test to see if I can reproduce it with a 200 MB and 1.8 GB
file and there was so no issue albeit they were different recordings by the
same software shadowplay. And, think the issue may occur because of the
file size.
Can you get a flash drive over 9 GB to extract it into?
…On Wed, Apr 18, 2018 at 1:27 AM, DylanC ***@***.***> wrote:
@jmollo310 <https://github.com/jmollo310> - Do you have a smaller
example? Maybe 2Gb or something? I have the folder downloaded but not
enough disk space to extract it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1438 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AfXFVaZThiAgBYaOUy3VD0wePDrTR7CHks5tpvjXgaJpZM4S_9Lj>
.
|
|
@jmollo310 - I think I'm just a little bit short on storage then. 😆 I used to have lots of flash drives but they seem to be missing. I do have a 2Gb flash drive on hand which is of no use really. I think its time to buy some new flash drives or use my external backup hard drive temporarily. |
|
@jmollo310 - Hi there, I've tried this tonight. I had to follow the youtube video as the instructions were kinda confusing. I made something kinda similar with the video clips you provided: However, the Exported video turned out to be the same as the preview inside Openshot. Not sure what else I could try here. @peanutbutterandcrackers - Keeping you in the loop here. |
|
@jmollo310 - I should mention I was using the latest daily build instead of v2.4.1. Maybe you could give that a try? |
|
I tried it on v2.4.1-dev1 a couple weeks ago. It didn't work.
Are you using windows 10 to run Open Shot?
…On Mon, Apr 23, 2018 at 2:38 PM, DylanC ***@***.***> wrote:
@jmollo310 <https://github.com/jmollo310> - I should mention I was using
the latest daily build instead of v2.4.1. Maybe you could give that a try?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1438 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AfXFVeqYYon0xxVnQA8NFt087TFluVAMks5trknSgaJpZM4S_9Lj>
.
|
|
@jmollo310 - Yes, I tested on Windows 10 but it was a daily build and not the v2.4.1 release. Did you try out a daily build? |
|
I just tried the most recent daily build and still had the issue. Here is
the youtube clip of me going through the steps with this build:
https://youtu.be/I9tXsXdpzSA
…On Wed, Apr 25, 2018 at 1:06 AM, DylanC ***@***.***> wrote:
@jmollo310 <https://github.com/jmollo310> - Yes, I tested on Windows 10
but it was a daily build and not the v2.4.1 release. Did you try out a
daily build?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1438 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AfXFVRyA9Sps8esuyW9_hKTsLMnsHCR3ks5tsC6jgaJpZM4S_9Lj>
.
|
|
I wonder if the issue has to do with the export being at a different frame rate than the project itself. The project profile is Try creating a new project and change the project profile to |
|
I just tried setting the profile and it had no effect.
…On Thu, Apr 26, 2018 at 5:52 AM, Richard Alloway ***@***.***> wrote:
I wonder if the issue has to do with the export being at a different frame
rate than the project itself.
The project profile is HDV 720 24p (24 fps) but you export at 25 fps with
profile HD 1080p 25fps.
Try creating a new project and change the project profile to HD 1080p
25fps before adding any of the clips to the timeline.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1438 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AfXFVTm5olDMripHQJQz2B8AozmuZOrVks5tscMbgaJpZM4S_9Lj>
.
|
|
Did you set the profile BEFORE adding anything to the timeline or AFTER adding items to the timeline? I just replicated your issue exactly by following the steps in your YouTube video and posted the result here: The rendered video had no sound and the slow motion portion was static, just as you described. Taking the exact same project, hitting the red render button and immediately hitting the If you're going to change the frame rate of the rendered video, you must do it as the very first thing that you do with the project. The issue is with how keyframes are set and stored in the projects. When you export/render at a different frame rate, the location of the keyframes changes. This is mentioned in other issues, such as #519 , #640 , #1034 , #1041 and #1098 . It is a known bug that does not yet have a solution. As a little more depth into the issue, the long clip was at position 20.86s (at the end of the clip on Track 0 aka frame 500.64) and you cut it at 23:42:11 and 23:47:24. Those were at frame 34139 and 34258 of the project, respectively, at 24 frames per second. Project frame 34139 is clip frame 33638.36. When you exported, you changed the frame rate to 25 frames per second, which shifts the keyframes by 1 frame for every second. At exactly 23min42sec into the timeline, we're talking about a -1422 frame offset at 25 fps for keyframes set at 24 fps. That is why the frame that is static is from earlier in the clip than the cut section should include. FYI, the static frame is from 22:50:24 (frame 32904) on the timeline, which is visible before the slices were made. I'm not familiar enough with the internal math to predict which frame will be selected at different frame rates or to explain why the frame is static, especially when time dilation is involved. 😉 |
|
@N3WWN - Your ability to reproduce issues like this one is truly amazing! |
|
@DylanC Thank you, sir! 🙇 |
|
That fixed it! Thank you very much!
…On Thu, Apr 26, 2018 at 9:08 AM, Richard Alloway ***@***.***> wrote:
@DylanC <https://github.com/DylanC> Thank you, sir! 🙇
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1438 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AfXFVbnHU56HoetvqjxwSt6b-iUxTxpEks5tsfDqgaJpZM4S_9Lj>
.
|
|
Also, I don't think I rebooted when I did the last test thus resulting in
it not working.
…On Thu, Apr 26, 2018 at 11:43 AM, John Mollo ***@***.***> wrote:
That fixed it! Thank you very much!
On Thu, Apr 26, 2018 at 9:08 AM, Richard Alloway ***@***.***
> wrote:
> @DylanC <https://github.com/DylanC> Thank you, sir! 🙇
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#1438 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AfXFVbnHU56HoetvqjxwSt6b-iUxTxpEks5tsfDqgaJpZM4S_9Lj>
> .
>
|
I have to say I don't like this idea. The profiles exist for a reason, and arbitrary frame rates aren't valid for every format. If you have a project set up with some 15fps profile, and you change to one of the 1080p HD profiles, creating a 15fps 1080p profile is doing the user a disservice. 15fps is not a legal frame rate for ATSC or HDV video so that autogenerated profile is invalid. |
|
Yeah, so... this part?
Completely, gloriously false. I could not possibly have said something more wrong, unless perhaps I'd asserted that 2 + 2 = 5. I forgot that we were dealing with linear frame numbers, not a combined time-signature+frame-number format. (Like When you're dealing with linear frame numbers, converting from one rate to another is a simple matter of multiplying every frame number by the ratio of target rate to source rate. So, to convert from 24fps to 60fps, you simply multiply every frame number by So, given that reality, technically it does present a third option for dealing with this. Option C: Adjust frame#-based keyframes on project fps change, copy-and-align on exportThis would leave the existing frame-number-based method of storing keyframe positions, but borrows the copy-and-conform idea I presented in Option B above, as a way of dealing with export rate mismatches. Nothing changes about how the keyframe data is stored. Whenever the project frame rate is changed, the parameter list is walked, and every keyframe position adjusted using the formula ...Honestly, I don't know. The idea of frame#-based positioning still makes me uneasy, as we've seen how fragile it can be. But, if managed correctly it's not completely unworkable. And while the playhead is being used as the interface to adjust parameter values, it does make some things simpler to position them by frame# instead of time. In the short-to-middle term, this is probably the least work of all the options, and requires touching the least code. Update: Fixed a stupid confusion regarding the parameter (not "effects") list. |
|
@ferdnyc - Should this issue be closed or marked as an enhancement? Not quite sure where this 33 comment issue stands anymore. 😆 |
|
IMHO, marked as a bug. OpenShot's handling of frame-rate changes is broken. If the frame rate on an existing project is changed, any previously-set parameter keyframe locations get smeared across the timeline. If the project is exported into a video format with a frame rate that doesn't match the project frame rate, the export is performed incorrectly. |
I had not considered that only certain profiles are valid. I know that some profiles are more optimal for some services/devices due to being native resolution/refresh rate/etc, but that was as far as I knew. In #519 (comment) , someone asked if we could simply grey out profiles which are incompatible. Right now, "incompatible" is likely only a profile with a different frame rate. The end-game solution is to be able to freely change frame rates mid-project or during export, but until then, I wonder if this wouldn't be a good stopgap measure? |
|
On export, almost certainly. Except for perhaps the most basic case where the timeline consists of only a single clip, you can't export to any video format with a fps that doesn't match the project frame rate, or the export will break. So we shouldn't let the users try, since we know the video that comes out will be incorrect. If they want to export at a certain frame rate, they need to set the project to that frame rate. And there's the rub. As far as allowing the user to change the project rate... that's trickier. Because, yes, the solution to exporting is that you SHOULD set the project rate to the export rate, before doing the export. And AIUI currently (and I don't imagine that my understanding of all the issues here is complete, as it is a nebulous problem) ...AIUI currently, changing the project framerate is sometimes, but not always a problem. It's a problem when there are parameters with existing keyframe points on the timeline, as they won't be updated correctly. If the timeline consists only of clips, changing the frame rate shouldn't break anything. If the user hasn't set any manual keyframes, but their project consists of both clips and transitions/effects (which are positioned on the timeline by time index, but may have keyframe points set that control the progress of the effect/transition — or may not? does every effect/transition set keyframes?)... I'm not sure how/if we can predict when it'll be problematic. But I think if OpenShot were to disallow ever changing the project frame rate, we'd get complaints from equally frustrated users who need to, and now have no recourse but to start recreating their entire project from scratch. So, while doing that may "cover our asses" in terms of allowing the user to not perform unsafe operations, I'm not sure it's really any better for them. |
|
And I'm just realizing, now, that I never tested whether my add/remove track fix in #1546 properly handles effects and transitions. Off to do that... ETA: Glad I checked. Effects are fine, because they're anchored to a particular clip. But transitions need to be updated on add/remove track just like clips. And now they are. |
|
Hey guys,
This issue came up for me because I was not educated enough on the product
to know to set the frame rate before using. I assumed that I could simply
import my files and then export to which ever resolution and fps I wanted.
Generally speaking, as a newbie on this product, those would be common
formats such as 1080p 25 fps type ones.
A couple questions based upon what I've heard so far and hope it doesn't
sidetrack the conversation:
1. If you save a project at the wrong settings. Can you change those
settings then reopen?
2. What prevents one from remapping the export resolution and rate to the
current project? If the clip times, transitions, effects etc are save
merely as data, couldn't that be applied to any resolution and rate?
3. Perhaps there is a need for a "New Project" wizard where the settings
are created based upon the expectation of what type of export the user
wants to create.
4. There are cases where software bugs have been left open as training
issues until there is time and funding for the fix especially if it would
require major changes. Perhaps, for the time being, for us new folks,
there can be extra educationly popups or enforcement of the expected export.
Regards,
John
…On Wed, May 2, 2018 at 8:19 PM, Frank Dana ***@***.***> wrote:
On export, almost certainly. Except for perhaps the most basic case where
the timeline consists of only a single clip, you can't export to any video
format with a fps that doesn't match the project frame rate, or the export
will break. So we shouldn't let the users try, since we know the video that
comes out will be incorrect. If they want to export at a certain frame
rate, they need to set the project to that frame rate.
And there's the rub. As far as allowing the user to change the project
rate... that's trickier. Because, yes, the solution to exporting is that
you SHOULD set the project rate to the export rate, before doing the
export. And AIUI currently (and I don't imagine that my understanding of
all the issues here is complete, as it is a nebulous problem) ...AIUI
currently, changing the project framerate is *sometimes*, but not *always*
a problem.
It's a problem when there are parameters with existing keyframe points on
the timeline, as they won't be updated correctly. If the timeline consists
only of clips, changing the frame rate shouldn't break anything. If it
consists only of clips and transitions/effects (which are *positioned* on
the timeline by time index, but may have keyframe points set that control
the progress of the effect/transition — or may not? does every
effect/transition set keyframes?), but no manually-adjusted parameter
keyframes... I'm not sure how/if we can predict when it'll be problematic.
But I think if OpenShot were to disallow ever changing the project frame
rate, we'd get complaints from equally frustrated users who *need to*,
and now have no recourse but to start recreating their entire project from
scratch. So, while doing that may "cover our asses" in terms of allowing
the user to not perform unsafe operations, I'm not sure it's really any
better for them.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1438 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AfXFVbWw_nW-hm8SQuwvqsJUmijjc-Pqks5tunc2gaJpZM4S_9Lj>
.
|
|
Also one more item:
5. Perhaps there could be a basic and advanced mode where the basic mode
requires setting the project resolution and framerate first and only allows
export to that. Advanced, would allow the user to set the project then
export differently.
…On Wed, May 2, 2018 at 9:26 PM, John Mollo ***@***.***> wrote:
Hey guys,
This issue came up for me because I was not educated enough on the product
to know to set the frame rate before using. I assumed that I could simply
import my files and then export to which ever resolution and fps I wanted.
Generally speaking, as a newbie on this product, those would be common
formats such as 1080p 25 fps type ones.
A couple questions based upon what I've heard so far and hope it doesn't
sidetrack the conversation:
1. If you save a project at the wrong settings. Can you change those
settings then reopen?
2. What prevents one from remapping the export resolution and rate to the
current project? If the clip times, transitions, effects etc are save
merely as data, couldn't that be applied to any resolution and rate?
3. Perhaps there is a need for a "New Project" wizard where the settings
are created based upon the expectation of what type of export the user
wants to create.
4. There are cases where software bugs have been left open as training
issues until there is time and funding for the fix especially if it would
require major changes. Perhaps, for the time being, for us new folks,
there can be extra educationly popups or enforcement of the expected export.
Regards,
John
On Wed, May 2, 2018 at 8:19 PM, Frank Dana ***@***.***>
wrote:
> On export, almost certainly. Except for perhaps the most basic case where
> the timeline consists of only a single clip, you can't export to any video
> format with a fps that doesn't match the project frame rate, or the export
> will break. So we shouldn't let the users try, since we know the video that
> comes out will be incorrect. If they want to export at a certain frame
> rate, they need to set the project to that frame rate.
>
> And there's the rub. As far as allowing the user to change the project
> rate... that's trickier. Because, yes, the solution to exporting is that
> you SHOULD set the project rate to the export rate, before doing the
> export. And AIUI currently (and I don't imagine that my understanding of
> all the issues here is complete, as it is a nebulous problem) ...AIUI
> currently, changing the project framerate is *sometimes*, but not
> *always* a problem.
>
> It's a problem when there are parameters with existing keyframe points on
> the timeline, as they won't be updated correctly. If the timeline consists
> only of clips, changing the frame rate shouldn't break anything. If it
> consists only of clips and transitions/effects (which are *positioned*
> on the timeline by time index, but may have keyframe points set that
> control the progress of the effect/transition — or may not? does every
> effect/transition set keyframes?), but no manually-adjusted parameter
> keyframes... I'm not sure how/if we can predict when it'll be problematic.
>
> But I think if OpenShot were to disallow ever changing the project frame
> rate, we'd get complaints from equally frustrated users who *need to*,
> and now have no recourse but to start recreating their entire project from
> scratch. So, while doing that may "cover our asses" in terms of allowing
> the user to not perform unsafe operations, I'm not sure it's really any
> better for them.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#1438 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AfXFVbWw_nW-hm8SQuwvqsJUmijjc-Pqks5tunc2gaJpZM4S_9Lj>
> .
>
|
|
Thanks for your input, John. You make some good points, and honestly it's really valuable having the input of less experienced users on these issues, since they (you) bring a perspective on OpenShot that isn't "tainted" by familiarity with its quirks and baked-in assumptions. To address some specifics:
Currently no, on point 1, unfortunately. The core issue here is that, for various historical reasons, certain elements of OpenShot projects are stored positioned by their frame number (a simple integer, like "frame 1074", for example), and... well, you can probably see what happens when you change the frame-rate, either in the project or on export. "Frame 1074" moves to a completely different place, and that isn't properly handled in OpenShot at this time. It could and ultimately should be, and that lack of correct handling is the core of the bug.
I think that's a good idea just in general, and ultimately an "enhancement" component of this issue, that may be the right way to go for OpenShot. (It would also allow us to do other "setup" things we may want to do, like create a project folder where all of the various files for the project are meant to be stored. Which would solve a lot of other problems we've been fighting with file locations, save paths, recovery, and the like.) But while that would allow us to set users' expectations better (which is certainly a valuable thing in its own right), it wouldn't get us any closer to giving users the ability to modify project frame rate which, ultimately, I think is an ability that has to be provided in some form.
If we can solve the export-at-a-different-frame-rate problem, then it'll be solved, and there will be no reason to prevent any users from doing that. Until it's solved, the problem is that any sort of "Advanced" mode like that isn't possible. It's our bug preventing users from successfully doing something that they should be able to do, rather than a conscious decision to "restrict" any operations. What we really need is an "Advanced" version of the code where this bug is fixed. 😁 |
|
John's questions did lead me to another thought (how Socratic!), regarding my Option C proposal above. I'd been focused on being able to do the frame-rate conversions "live" whenever the user selected a different profile, whether in the project settings or on export. But what if it wasn't done on live data, but rather as a one-shot conversion process applied to a project file when loading? Here's my sketchy outline of a though: Option D, maybe?
Sequestering the frame-number remapping process to one particular path in the code might make things simpler, and even moreso than my previous proposals, would allow the rest of the code to stay unchanged, remaining blissfully unaware of these issues. The one possible complication here is the unordered-by-design nature of the project files' JSON data. I had initially thought of just setting a variable in the project file that says "convert me from N fps to M fps", which would be done the next time it's loaded. But since it may be difficult to guarantee that variable will be seen before any of the frame-number-based data gets loaded in, I think the conversion process needs to be initiated by OpenShot itself when loading the file, rather than depending on any information contained within. |
|
I have the code working perfectly to grey out the non-compatible profiles in the This may need to be modified to look for keyframed items in the project and only restrict the profiles based on if they really are incompatible or not. I have the code working perfectly to grey out the non-compatible video profiles in the Simple and Advanced tabs in the If any of this is useful, I can keep working on it and/or submit a WIP PR for what I have working. If any of this is not useful, I'll stop working on it and save my time for other items. 😉 I do think that changing frame rates ANYWHERE is problematic at this point and is probably the 2nd biggest complaint from the users (the first being performance, which should be much better in 2.4.2). [Here's where the message gets long... please stick with me! 😊 ] Live migration of the keyframes when profiles are changed is what I think would be "best", at least in my mind. Could we add a property to the keyframed items as to whether they should be frame-accurate or time-accurate? Then, during conversion, if a keyframe is calculated to be mid-frame, the decision can be made to adjust to the closest frame or keep it at the time. Doing this, we could store all keyframes with a time-value in the project file, making project files profile-agnostic. The type accuracy (frame or time) could be defaulted based on the type of keyframe; things like fades do not need to be frame accurate, but things like transitions may need to be frame accurate. The type of accuracy could be a toggle in the properties, too. Another potential problem would be profile reversion with different results. For instance, converting from 30 fps to 100 fps to 60 fps to 29.97 fps to 30 fps should result in the keyframes being in the exact same position for both instances that the project is 30 fps. A possible workaround for this would be storing the "original" data next to the "current" data and only using the original data for calculations when the frame rate changes. Start project at 30 FPS
Convert to 100 FPS
Convert to 29.97 FPS
Convert back to 30 FPS
This removes accumulated variation accrued with each frame rate change. When a positional/chronological change is made to a keyframe, the new position and rate are stored as the "original" values for the keyframe. Value-only changes made to a keyframe don't impact where/when a keyframe exists, so the "original" value is left intact. The actual method used to internally represent when a keyframe exists on the timeline (it is a timeline after all) can be derived from the current position stored in the project. |
I feel like you may be overcomplicating some things here (and through the rest of the second half). "Time-accurate" doesn't really mean anything, certainly not at a sub-frame level. Every keyframe needs to be "frame accurate", in the sense that it currently needs to be placed on some frame boundary or the interface has no idea what to do with it and it becomes unmodifiable. And given that, during conversion every keyframe position has to be rounded to the nearest frame boundary at the new frame rate, which means some keyframes may have to shift slightly and there's nothing that can be done about that when switching frame rates: if they shift then it's because the old position isn't a frame boundary anymore. If someone goes from 29.97fps to 60fps to 24fps to 29.97fps, I feel it is absolutely no problem if their keyframes don't all end up on exactly the same frame they started at. They should only shift by a frame or two, at most, and I don't feel it's worth the complexity to even try preventing that. If it's an issue for any users that they changed the frame rate three times and now their transition is starting on frame 174 when they initially set it on frame 173, then they're encouraged to buy Adobe Premiere Pro where exactly the same thing will probably still happen. 😆 But storing keyframes by both time position and frame position is like that proposal that the user be able to choose between 0-based and 1-based frame numbering: Trying to write code that can deal with both is just a special kind of nightmare. In this case, we don't even have code that can deal with one of these situations properly, so I think the focus should be on picking a horse and riding it. Positioning keyframe points by time index is almost certainly the best way to do it. It's also incredibly hard to do because there's no support in the interface for it. (If you have a "time-accurate" keyframe that falls between two frame boundaries, how do you adjust it? Or delete it? That was the entire problem in both my Option A and B scenarios above, and why I ultimately rejected them as workable solutions, certainly for 2.4.2, and really for 2.4.anything at a minimum.) While I'd love for (all) keyframes to be positioned by time, and it would solve the problem of frame-rate conversion, it would introduce a whole host of other problems. (Probably even bigger problems, even though right now it doesn't seem like any problem could be bigger than this one because, currently, there aren't any bigger problems.) Until then, I still think (all) keyframes need to stay positioned by frame#, and the focus should be on getting that to work right even when the frame rate changes. But by "right" I mean "doubling the frame rate no longer causes all of the keyframes to be positioned half as far up the timeline as they're supposed to be", not "worrying about whether keyframe positions might be forced to shift by tens of milliseconds when the frame rate changes". |
|
...That being said, this:
sounds awesome. I really wish the step of disabling project frame-rate changes wasn't necessary, because it's going to screw up a lot of people (and will probably become the new biggest complaint, simply for its prominence) — but at least for 2.4.2, it probably is necessary. In reality they'll be complaining about no longer being able to do something that, for the most part, would've been silently screwing up their projects when they were allowed to do it in the past, so even though the complaints may be louder it should hopefully cause fewer actual problems. |
You're probably right! I haven't looked at any of the keyframing code yet... just kinda thinking out loud. hehe I suppose the magnitude of the accumulated errors (or rather, the lack thereof) is not worth taking into consideration. Even going from 25fps to 60fps to 100fps to 29.97 fps and back to 25fps couldn't accumulate more than about 4 frames of positioning error (it would actually be much less than that), which is 0.16s during playback at most. While I think my idea of storing the original position and associated frame rate is still a good idea (or at least has some merit, perhaps it would only be workable in a new project which claims to be that accurate versus crowbarring it into this existing project. 😉
This was my basic thought, too. I think it'd be an easier pill to swallow for users to complain "I can't export the project that I invested 10 hours working on at the frame rate I want. 😞" versus "I spent 10 hours working on this project, changed the profile to a different frame rate and now I have to start over from scratch! 😠" I'll submit a WIP PR for profile.py, which is working, and will continue to look at export.py. I need to get my head further around how the profile lists are updated and pared down to get that one working properly. |
|
TL;DR Set the export frame rate before working on any clips or changing speeds. Work Around: Export video with initial frame rate. This is a really nasty bug been causing me trouble for months. Should not be hidden in this monstrous thread. |
|
This workaround worked for me. |
|
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:
We'd like to ask you to help us out and determine whether this issue should be reopened.
Thanks again for your help! |
|
I've invested 10 hours in the project, and now not only doesn't it export correctly, because I was trying to fix this error, my preview is also fubar'd. I didn't read through the 49 comments to see exactly what's wrong, but suffice it to say that the behavior is not intuitive nor predictable. |
|
Sorry for the novice questions...
|
|
@waggers5 if you right click on a file and click on Yes OpenShot can handle files will all different frame rates. It does the math (for instance showing every other frame if a 60 fps file is in a 30 fps project). Are you having any trouble with exporting? |
Hi, thanks for the response. One of my clips had the issue mentioned in my first export attempt, but I tried again (without changing anything) and it was fine second time around. |
|
@waggers5 Ok. I'm trying to reproduce this to get it fixed. What was the frame rate of the file, and the frame rate of your export where export wasn't correct? |
System Details:
Issue Description and steps to reproduce:
Using prerecorded nvideo shadowplay clips of PUBG game, I do the following:
Exported clip shows a stopped stuttered frame where the 1/4 speed track 2 should be and it's about 15 seconds before track 2 slice should be beginning.
Here is a youtube clip showing entire process: https://youtu.be/YdCV-dmZ7GQ
The text was updated successfully, but these errors were encountered: