This patch implements possibility to edit videos with varying frame rates.
Currently the situation is, that user must use speed effect to change speed of movie strip, that doesn't match scene framerate. Editing such strip has some issues, but ideally you wouldn't need to use speed effect at all.
In this patch, strip playback rate is stored as absolute value in frames per second. Strip length is calculated from content length (in frames), stored playback rate and scene framerate. This method was chosen over relative playback rate that would be updated on framechange, because there is no need for update function. If update function would be used, recalculating relative playback rate is susceptibe to drift when changing framerate (dragging slider with custom framerate) because of precision issues as was the case in D4067.
This works well, until scene framerate is changed after editing strips.
There are 2 main reasons why things break after changing framerate:
- Strip length and position on timeline is not changed
- Strip animation is frame based and keyframes would remain on same frame, while time axis stretches or shrinks.
Problem with strip length on timeline and cut positions could be solved in 2 ways:
- Recalculate these positions when scene framerate is changed. This approach may result in loss of precision, as mentioned earlier. It would be relatively simple change though.
- Store these positions in values that are independent from scene framerate - seconds. No update function needed, but a lot of drawing and set/get functions would need to be changed.
Storing edit points in seconds may result in one issue that is very edge case, but it can happen: start/end points must be editable in any framerate. Therefore if user edits endpoint of 1 strip so that it is touching another strip in low framerate and switches to higher framerate, a gap or strip collision may be created, because non-edited strip has been edited in diffferent framerate and it's end point position was "rounded" in lower framerate. So this method may be error-prone as well. Solution is to make strips "aware of each other" and adjust edit points of all strips, so they can never collide each time user makes an edit.
Problem with animation keyframe position is different, because their position is rigidly based on frame values and there is no other way to move these than running update function on framechange.
Scaling time has much more intricate issues that would doubtfuly be ever resolved. For example F-curve with generated sine wave does not scale with scene frame rate.
Therefore to proceed further, I think it is necessary to better outline goals.
In summary:
If goal is to just support adding movie strips with different framerates, patch is available for functional review.
If goal is to support above + changing scene framerate effortlessly, depending on method agreed on, this can be relatively quick(but imprecise) or quite involved change. In either case, I definitely wouldn't attempt this after BCON1.