https://bugs.kde.org/show_bug.cgi?id=368962
--- Comment #9 from farid <snd.no...@gmail.com> --- (In reply to Evert Vorster from comment #8) > 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. Evert, thanks for your input! You commented that this is happening on the refactoring branch, is that happening in the latest beta release? We are handling all the refactoring problems in this thread: https://phabricator.kde.org/T7082 Would you mind commenting on this issue there and a dev will definitely engage you on it. Cheers -- You are receiving this mail because: You are watching all bug changes.
