Changed Framerate and Cut Segment Length cause Incorrect Cut Points

[Avetho]

The fewer issues I have to read, the more new features I will have time to implement, so I ask that you please try these things first

• Try with the newest version from GitHub (also it might have already been fixed in latest nightly build)
• Read the documentation and FAQ, Known issues, Troubleshooting
• Search for your problem under Issues or Discussions
• This problem happens with all kinds of files that I try. For problem only with a particular file or type, use this other form instead

Operating System

Windows 10

Steps to reproduce

Import a long file, increase the fps, set the export segment start to a keyframe after the start of the video, and the segment end to a keyframe before the end of the video file, then export the file.

Expected behavior

The exported file should be cut where the segment was cut, and play at the desired frame rate.

Actual behavior

The exported file plays at the desired frame rate, but while the beginning was cut in roughly the right place, the end appears to not have been cut at all.

I suspect that it applied the framerate change first, and then attempted to cut the segment based on the new framerate time rather than the old framerate, and cannot cut a video file that is shorter than the original video using the old timestamps, so the further into the clip the cut is made, the cut will be made in a yet more incorrect place. Changing the order of operations to cut first and only change framerate after would likely fix this, as right now it requires two individual edits and exports per clip, roughly doubling the time spent on edits from having to import the once-exported clip for a second editing pass, applying the cut or framerate first, exporting, then reimporting to perform the other edit.

Perhaps even applying the cuts based on frame number rather than timestamp would fix the problem, as the frame number doesn't change with framerate like timestamps do, so while the segment length should be shown to the user in timestamps, it should be recorded as frame numbers on the back end, which would allow segment length to be displayed according to the set framerate as well, such as changing a 1 hour long clip from 30 fps to 60 fps would have the segment end timestamp change from 1 hour to 30 minutes instead of continuing to display 1 hour as it does now.

Share log from developer tools

No response

[mifi]

The change FPS function uses teh ffmpeg argument -itsscale X. This is an input argument so it applies before any cuts are done. I just tried to move it to the end of the command but I got this error: Option itsscale (set the input ts scale) cannot be applied to output url -- you are trying to apply an input option to an output file or vice versa. Move this option before the file it belongs to.

So I don't think it's easy to fix this. But we should probably show a warning to the user or prevent them from changing the frame rate if they are also cutting.

[Avetho]

That sounds like a good workaround for now. Perhaps an option to enable it doing multiple processing steps? I imagine it would be a bit slower, having to process a cut first, then reimport the temporary output mp4 (or whatever format) in the background (in the program cache?) to change the framerate before it does the final save, but to keep the default high speed of the program it could be an option that defaults to off to maintain the current behavior, just with the warning message. That way those of us who want it can enable it at the cost of some speed, and the warning can also have a line saying something like "Enable 'Multi-Pass Processing' to change framerate and cut at the same time" or something so new users can know about the option right away. It could be added as an experimental setting right under 'Allow multiple instances' with the (experimental) tag so users know it might have some bugs.

[mifi]

That's possible, but it's so easy to do it in two separate steps and the complexity of adding multi-pass processing does not justify the demand (you're the first to ask about it), so I don't think it's going to be implemented any time soon. but i'm adding a warning in the export dialog.