Bug 450790 - Recorder not showing last frame properly
Summary: Recorder not showing last frame properly
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Dockers/Recorder (show other bugs)
Version: nightly build (please specify the git hash!)
Platform: Compiled Sources All
: NOR normal
Target Milestone: ---
Assignee: Reinold Rojas
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-02-24 09:33 UTC by Rexel
Modified: 2024-06-05 19:21 UTC (History)
3 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 Rexel 2022-02-24 09:33:19 UTC
I've reexported the same recorder project many times but it still doesn't hold the last frame, I've set it to 10 seconds and it still treats the last frame as a normal frame to be held only for a millisecond. Not sure how this can be reproduced on another system.

I've also tried updating my ffmpeg and exporting other formats (webm and mkv) and it still doesn't hold the last frame.

Flash effect format also says "ffmpeg crashed" but not sure how to show the logs from that one.

The exported video, the source frames, and the Krita file can be found here (14mb)
https://drive.google.com/file/d/1ZyMYUiflkKPgYZbc5O1XxBDbVXa88064/view?usp=sharing

Maybe has something to do with changing the image size midway? I usually change that when I paint but I'm not sure if I did it on this particular painting.

I've also used the recorder on other projects but it seems to work fine for them, the "hold last frame" working as intended

Other info:

Krita

 Version: 5.1.0-prealpha (git 65ea446)
 Installation type: installer / portable package
 Languages: en_US, en
 Hidpi: true

Qt

  Version (compiled): 5.12.12
  Version (loaded): 5.12.12

OS Information

  Build ABI: x86_64-little_endian-llp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: winnt
  Kernel Version: 10.0.19042
  Pretty Productname: Windows 10 (10.0)
  Product Type: windows
  Product Version: 10
Comment 1 Reinold Rojas 2022-03-07 00:54:05 UTC
Hi Rexel,

Thanks for the Krita files and bug report. I can confirm that the hold frame option doesn't work/crashes for your krita file file. 

Setting to confirmed and assigning to myself since I added that feature.
Comment 2 scene 2022-05-03 15:44:16 UTC
Same issue here.

After few tries, I find that if changing the image size midway, the loop last frame option will not work.

Maybe a ffmpeg bug  or misconfiguration of ffmpeg parameters?
Comment 3 David REVOY 2024-01-30 09:07:28 UTC
Hi, I think my issue #461869 is related: https://bugs.kde.org/show_bug.cgi?id=461869 (I share on it a workaround, if it helps).
Comment 4 Reinold Rojas 2024-01-31 04:27:44 UTC
I'm fairly sure its not related to that other bug. I think that one is mostly from some of the ffmpeg commands not properly taking into account the input fps. This one seems to be some other issue that just skips part of the script entirely. Its possible the scaling caused the issue but will probably take some more testing to confirm.
Comment 5 Reinold Rojas 2024-02-01 05:16:14 UTC
After some testing it seems like it is the different resolution for the saved images (from the painting changing sizes midway). Checking the ffmpeg docs it says "The _size_, the pixel format, and the format of each image must be the same for all the files in the sequence." Trying a simple ffmpeg command to extend a custom frame it breaks exactly when the input image resolution changes. 

It does seem like the preview still works (probably because it gets and reads the extended portion separately from the main file) so I think doing the same for the end result should get around the issue.

fmmpeg doc: https://ffmpeg.org/ffmpeg-all.html#image2-1
Comment 6 Reinold Rojas 2024-02-03 20:22:17 UTC
I'm now not totally sure it is a scale issue. I tried using the same  method to extend a frame as the preview and use it for the end but that doesn't seem to work. ffmpeg just seems to skip rendering that portion entirely if its added to the end.

I found this a comment on stack overflow that mentions exactly what I thought was the problem (different resolutions for input images) but trying that doesn't seem to fix the issue here. https://superuser.com/a/1136305 and ffmpeg doc https://ffmpeg.org/ffmpeg-filters.html#scale

I'm not quite sure what else to try/test if anyone has any ideas...

Here was my last ffmpeg filter command I was testing with for visibility:

```
 [0]scale=w=$WIDTH:h=$HEIGHT:force_original_aspect_ratio=decrease:eval=frame[main1];
 [main1]loop=1:size=1:start=0[main2];
 [main2]setpts=PTS-STARTPTS[main3];
 [1]split=3 [preview1][transition1][ending1];
 [transition1]scale=$WIDTH:$HEIGHT:force_original_aspect_ratio=decrease:eval=frame [transition2];
 [transition2]loop='if(gte($FIRST_FRAME_SEC, 1), 1*$IN_FPS, 0)':size=1:start=1[transition3];
 [transition3]setpts=PTS-STARTPTS[transition4];
 [preview1]loop='if(gte($FIRST_FRAME_SEC, 1), ($FIRST_FRAME_SEC*$IN_FPS) - 0.5*$IN_FPS, $FIRST_FRAME_SEC*$IN_FPS)':size=1:start=1[preview2];
 [preview2]scale=$WIDTH:$HEIGHT:force_original_aspect_ratio=decrease:eval=frame[preview3];
 [preview3]setpts=PTS-STARTPTS[preview4];
 [ending1]loop=$LAST_FRAME_SEC*$IN_FPS:size=1:start=1[ending2];
 [ending2]scale=$WIDTH:$HEIGHT:force_original_aspect_ratio=decrease:eval=frame[ending3];
 [ending3]setpts=PTS-STARTPTS[ending4];
 [transition4][main3]xfade=transition=smoothright:duration=0.5:offset=0[combined1];
 [combined1]trim=start_frame=1[combined2];
 [combined2]scale=$WIDTH:$HEIGHT:force_original_aspect_ratio=decrease:eval=frame[combined3];
 [ending4][combined3]scale2ref[ending5][combined4] ;
 [preview4][combined4][ending5] concat=n=3[final1];
 [final1] setpts=PTS-STARTPTS[final2];
 [final2] trim=start_frame=1
```
Comment 7 Emmet O'Neill 2024-05-01 23:41:57 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 429326, 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 8 Freya Lupen 2024-06-05 19:21:11 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 429326, 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