Bug 429326 - Recorder docker doesn't account for canvas size changes during drawing session.
Summary: Recorder docker doesn't account for canvas size changes during drawing session.
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Animation (show other bugs)
Version: git master (please specify the git hash!)
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
: 434626 485502 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-11-18 22:10 UTC by wolthera
Modified: 2024-06-05 19:21 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description wolthera 2020-11-18 22:10:26 UTC
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?
Comment 1 tomtomtomreportingin 2021-03-19 20:36:45 UTC
*** Bug 434626 has been marked as a duplicate of this bug. ***
Comment 2 wolthera 2021-05-11 15:38:40 UTC
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?
Comment 3 Dmitrii Utkin 2021-05-15 18:33:09 UTC
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.
Comment 4 Eoin O'Neill 2021-05-18 20:34:54 UTC
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?
Comment 5 Dmitrii Utkin 2021-05-19 07:19:26 UTC
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.
Comment 6 Konayachi 2021-12-27 20:42:28 UTC
(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!
Comment 7 Freya Lupen 2024-04-15 13:32:53 UTC
*** Bug 485502 has been marked as a duplicate of this bug. ***
Comment 8 Emmet O'Neill 2024-05-01 23:42:05 UTC
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
Comment 9 Freya Lupen 2024-06-05 19:21:03 UTC
Git commit 47961a1a9c3322bfae8250cb9d3f8114af07cc7d by Freya Lupen, on behalf of Ralek Kolemios.
Committed on 05/06/2024 at 19:10.
Pushed by freyalupen into branch 'krita/5.2'.

Reworked default FFmpeg profiles
Related: bug 455006, bug 450790, bug 485515, bug 485514

 Conflicts:
	plugins/dockers/recorder/recorder_export.cpp
	plugins/dockers/recorder/recorder_export_config.cpp

(cherry-picked from commit 40524a33)

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/47961a1a9c3322bfae8250cb9d3f8114af07cc7d