Bug 429326

Summary:	Recorder docker doesn't account for canvas size changes during drawing session.
Product:	[Applications] krita	Reporter:	wolthera <griffinvalley>
Component:	Animation	Assignee:	Krita Bugs <krita-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	eoinoneill1991, info, kona.yachiyachi+kde, loentar, zoldyakopersonal
Priority:	NOR
Version:	git master (please specify the git hash!)
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:	https://invent.kde.org/graphics/krita/-/commit/47961a1a9c3322bfae8250cb9d3f8114af07cc7d	Version Fixed In:
Sentry Crash Report:

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