https://bugs.kde.org/show_bug.cgi?id=368962
Evert Vorster <evors...@protonmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDSINFO |CONFIRMED
Resolution|REMIND |---
Ever confirmed|0 |1
--- Comment #8 from Evert Vorster <evors...@protonmail.com> ---
This bug is still continuing to bite people, and is also present in the
timeline refactoring branch.
I assigned an even older recently re-opened bug from 2015 as a duplicate of
this one as it got re-opened with a report that more closely resembles this bug
from 2016.
I can't code, but I have been studying this bug for a while and can aid any
programmer that is willing to try with testing all the corner cases of a fix.
In order to sort this bug, the following needs to happen:
When selecting a change in project framerate, each source clip has to be
re-read to get the new frame numbers correct. This already happens, and is
good.
However, the next thing that needs to happen is that every referenced frame on
all the clips needs to be updated.
This does not happen.
In short, say a clip has an in point of 100 and out of 200, and the user now
doubles the frame rate, then the in point needs to be 200 and the out point
needs to be 400, to reflect the new frame rate.
Every frame that is referenced on the timeline also needs to be updated to
reflect the new frame number at the changed frame rate.
This also does not happen.
Since the frame numbers are integer, there is some loss of fidelity when
lowering the frame rate, this is unavoidable, and expected.
There is also the case of frames being adjacent on the timeline that needs to
stay adjacent,for instance, when a clip ends on one frame, and the next clip
starts on the next frame.
Conceivably, with integer math the two frames can end up with the same number
when dropping the frame rate, or be separated when the frame rate increases.
This would seriously corrupt the project.
We might just have to check for adjacent frames, and keep then adjacent by
simply assigning the starting frame of the new clip to be adjacent to the old
rather than doing the frame rate change math for that frame. This "feels" a
little hackish, however since videos are forced to be integer frames there is
no elegant way to do this.
The other option, of course, is to not allow a project's frame rate to be
changed at all. When a user starts a new project, they have to input the frame
rate and not have the option to change it. They can render at a different frame
rate, of course, but that would be the same as using ffmpeg to resample the
output file.
--
You are receiving this mail because:
You are watching all bug changes.
