SUMMARY When making this image (https://share.tube/videos/watch/ba0a9d02-273b-4f72-89a7-713d1bdfe0d7), I had hoped the recorder docker would try to convert all the images to be the same size before encoding. This turned out not the be the case, instead the first image was used as the video size and then every subsequent image was scaled to that first image's dimensions. A quirk of video file formats, I am sure. I had to render each canvas size change separately, and then combine them to make the final video. STEPS TO REPRODUCE 1. Make a small image. 2. Enable the recorder. 3. Draw a bit 4. Change the canvas size (by crop, by canvas view arrows, by image->resize canvas). 5. Draw some more. 6. Render the result with 'scale to size' enabled. OBSERVED RESULT Everything is locked into the aspect ratio of the first frame. EXPECTED RESULT All frames are scaled to a certain size and then converted to a video file?
*** Bug 434626 has been marked as a duplicate of this bug. ***
Of note: The resize function in ffmpeg seems to be mostly about storing metadata inside the file instead of actually resizing the result? Maybe we should fix that first?
This could be solved by adding ",setsar=1" after "scale=$WIDTH:$HEIGHT", but.. frames become stretched. We can add black padding to keep ratio by adding "force_original_aspect_ratio=decrease,pad=$WIDTH:$HEIGHT:(ow-iw)/2:(oh-ih)/2" but probably it doesn't look so good? Also some filters and encoders like gif doesn't work with variable input image size it either causes ffmpeg to crash or just skip everything until the target ratio is reached. You can try how it works, just edit MP4 x264 profile like this: ------------------------------------------------------------ -framerate $IN_FPS -i "$INPUT_DIR%07d.jpg" -vf "scale=$WIDTH:$HEIGHT:force_original_aspect_ratio=decrease,pad=$WIDTH:$HEIGHT:(ow-iw)/2:(oh-ih)/2,setsar=1" -c:v libx264 -r $OUT_FPS -pix_fmt yuv420p ------------------------------------------------------------ If it's ok, I will update profiles accordingly.
Dmitrii Utkin, I think scaling w/ black bars here would be the appropriate solution for MP4. Are you saying that GIF would be a problem with the proposed solution though?
Eoin O'Neill, yes.. By some reason it doesn't render frames with different frame size(?). Just some part of the whole timelapse. Looks like palette generator filter causes render to stop. split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse If I remove it, the resulting gif is created as expected (whole timelapse), but it look horrible due to missing palette.
(In reply to Dmitrii Utkin from comment #3) > This could be solved by adding ",setsar=1" after "scale=$WIDTH:$HEIGHT", > but.. frames become stretched. We can add black padding to keep ratio by > adding > "force_original_aspect_ratio=decrease,pad=$WIDTH:$HEIGHT:(ow-iw)/2:(oh-ih)/ > 2" but probably it doesn't look so good? > > Also some filters and encoders like gif doesn't work with variable input > image size it either causes ffmpeg to crash or just skip everything until > the target ratio is reached. > > You can try how it works, just edit MP4 x264 profile like this: > > ------------------------------------------------------------ > -framerate $IN_FPS > -i "$INPUT_DIR%07d.jpg" > -vf > "scale=$WIDTH:$HEIGHT:force_original_aspect_ratio=decrease,pad=$WIDTH: > $HEIGHT:(ow-iw)/2:(oh-ih)/2,setsar=1" > -c:v libx264 > -r $OUT_FPS > -pix_fmt yuv420p > > ------------------------------------------------------------ > > If it's ok, I will update profiles accordingly. This workaround worked for me!
*** Bug 485502 has been marked as a duplicate of this bug. ***
Git commit 40524a339fc519cec62ed6e1fab663e923111635 by Emmet O'Neill, on behalf of Ralek Kolemios. Committed on 01/05/2024 at 22:07. Pushed by emmetoneill into branch 'master'. Reworked default FFmpeg profiles Related: bug 455006, bug 450790, bug 485515, bug 485514 M +2 -0 plugins/dockers/recorder/recorder_export.cpp M +166 -147 plugins/dockers/recorder/recorder_export_config.cpp M +1 -0 plugins/dockers/recorder/recorder_profile_settings.ui https://invent.kde.org/graphics/krita/-/commit/40524a339fc519cec62ed6e1fab663e923111635