SUMMARY: Hi, The Recorder docker has a "Input FPS" option (the first on the top). This option influences as a multiplier the duration of "Extend end result" and "Enable result preview". But it's not expected as these two values are set in seconds. STEPS TO REPRODUCE: [setup] - Create a new document, open the Recorder docker, set it to 1 second, and start recording. - Scribble a little artwork for 5 minutes, so you get more or less 300 frames recorded. 1. Try to export the first video with "Input PFS" at 2, and preview/end-result to 6 seconds. 3. Try to export a second video with "Input PFS" at 120, and preview/end-result to 6 seconds. OBSERVED RESULT: None of the two videos will have 6 seconds intro and outro. - The first one (Input FPS 2) will end with a 1min30 way too long intro/outro, 15x longer than the 6 second promised/setup. - The second one (Input FPS 120) will end into a 2 second intro/outro, 0.25x shorter than the 6 second promised/setup, almost not visible. This is because the Input FPS multiply or divide the speed of intro/outro and Krita does probably a mistake in the math. This Input FPS setting should only influence the input FPS of the frames, not influences the seconds of intro/outro, these ones should only be calculated with the Output FPS (eg. 6 seconds at 30FPS = 180 Frames long at 30FPS). MATH FOR WORKAROUND: This bug is invisible with the default "30 Input FPS" and "30 FPS playback" settings. But as soon as you have a painting with a duration of hours and want to shorten it with the Input FPS, you'll loose the consistency of Intro/Outro feature: they'll be two fast... Unless you do reverse math: eg. if you want 6 second and need 120 Input FPS to get your duration exact, do: 30/120=0.25 so 6 seconds will be 6x0.25=1.5 seconds intro/outro. and to get a real 6 second, you need to do 6x(1/0.25), so 6x4, and enter 24second. Result; at 120FPS; 24 seconds for 6 seconds. EXPECTED RESULT: The value entered as seconds for the end result (outro) and the result preview (intro) to be respected on the final rendering, no matter what Input FPS value is set.
Hi David, Yes it works like you described and it seems the input fps is messing with duration of the preview and end result. I took a little bit of a look and I think it has something to do with how the framerate is set either for the input files or the export file. I'll try and look into this sometime this weekend. thanks for the detailed bug report.
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/2061
Git commit a8f6ca21b04af5e58fa7cc29d8a1ddf9b0967f4e by Dmitry Kazakov, on behalf of Reinold Rojas. Committed on 31/01/2024 at 08:44. Pushed by dkazakov into branch 'master'. Fixed recorder export being sped up by input fps Before this commit if a number higher than 30 was put for INPUT_FPS it would speed up the preview, preview transition, and extended result. This commit fixes the ffmpeg profiles so they properlly take into account the INPUT_FPS. M +23 -23 plugins/dockers/recorder/recorder_export_config.cpp https://invent.kde.org/graphics/krita/-/commit/a8f6ca21b04af5e58fa7cc29d8a1ddf9b0967f4e
Thank you Reinold for the MR, and thank you Dmitry for the review and the merging. 👍