Created attachment 161711 [details] Screenshot of the popup when I try to render animation STEPS TO REPRODUCE 1. Create an animation using an animation docker 2. "Render Animation" 3. Set "First frame" to value other than 0 4. Click "OK" OBSERVED RESULT A window pops up saying "Could not render animation: Unknown error." and animation is not rendered into video. EXPECTED RESULT The animation is rendered normally, as if "First frame" was 0. SOFTWARE/OS VERSIONS Windows: 10 Pro 22H2 KDE Frameworks Version: 5 / LGPLv2.1+ Qt Version: GPLv2 + GPLv3 + LGPLv2.1 + LGPLv3
Hi, Nathur! Could you please check this build when it is finished? I think I have fixed this bug: https://binary-factory.kde.org/job/Krita_Stable_Windows_Build/1987/
(In reply to Dmitry Kazakov from comment #1) > Hi, Nathur! > > Could you please check this build when it is finished? I think I have fixed > this bug: > > https://binary-factory.kde.org/job/Krita_Stable_Windows_Build/1987/ Thanks Dmitry! After running some tests with this new build, I can say... I'm confused as hell In some files I get the Unknown Error, in some I don't and the animation renders as intended I've zero idea what could be causing this whole thing, but eventually I thought to check the log files that came with the rendered animations, and found this: > D:/krita-nightly-x64-5.2.0-rc1-4cc1ab5a65/bin/ffmpeg.exe -hide_banner -y -y -r 30 -i D:/Mis Cosas/Imagenes/Por mÃ/Hollow Knight/Grimm Dross/fotograma%04d.png -ss 0:0:20.889 -t 0:0:6.006 -i D:/Mis Cosas/Imagenes/Por mÃ/Hollow Knight/Grimm Dross/GrimmDross_Audio.wav -c:v libopenh264 -b:v 5000k D:/Mis Cosas/Imagenes/Por mÃ/Hollow Knight/Grimm Dross/GrimmDross_2.mp4 > ===================================================== > [image2 @ 0000018fd2618240] Could find no file with path 'D:/Mis Cosas/Imagenes/Por mí/Hollow Knight/Grimm Dross/fotograma%04d.png' and index in the range 0-4 > D:/Mis Cosas/Imagenes/Por mí/Hollow Knight/Grimm Dross/fotograma%04d.png: No such file or directory Hope it helps
Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information.
Hi, Nathan! Could you please tell me what files you have in this folder: D:/Mis Cosas/Imagenes/Por mí/Hollow Knight/Grimm Dross/ There should be files like fotograma0001.png fotograma0002.png and so on...
Okay, I cannot reproduce this bug locally, however hard I try. Please send me the list of files you have in this folder, or, what are the numbers in files 'fotograma%04d.png' in that folder. Btw, could you also check if you have enough space on drive D:? Perhaps Krita fails to write all the frames there?
Marking the bug as waiting-for-info
(In reply to Dmitry Kazakov from comment #6) > Okay, I cannot reproduce this bug locally, however hard I try. Please send > me the list of files you have in this folder, or, what are the numbers in > files 'fotograma%04d.png' in that folder. > > Btw, could you also check if you have enough space on drive D:? Perhaps > Krita fails to write all the frames there? Hey Dmitry! No, it says I've got around 300 GB of free space in D:, so it can't be that So, I went and tried to render the GrimmDross animation again, and found that the frame files, rather than 0001, 0002, etc. were instead starting from 0633 (ending at 0814). Likely given that originally the keyframes were around that number in the .kra file. But thing is, I'd moved the animation to frame 0 a while ago I also checked with a test animation I have, and likewise the frame files start at 0024, corresponding with the animation in the .kra file (and ending at 0084). But for some reason, when I click OK on the error popup, rather than remove all the frame files, it leaves 0024-0047 intact, which matches the duration of the first keyframe Later though, I thought maybe the error was because one of the folders in the path has an accented letter (í), so I tried rendering it in a different folder, but I still get the error Additionally, I tried setting the Animation Cache to "on-disk", but still nothing
Adding an accented letter to the path was the first thing I tried to do here locally :) Could you give a bit more info about what you mean by "I'd moved the animation to frame 0 a while ago"? Just removed a few of the leading columns from the timeline? Btw, is it possible to share the crashing image with me (privately, via email), so I could test it better?
Git commit 0ed384a5dae0d99582f964c0061519769b7a0176 by Dmitry Kazakov. Committed on 25/09/2023 at 15:46. Pushed by dkazakov into branch 'master'. Fix removal of duplicated frames in "Only Unique Frames" mode The offset was applied incorrectly so the clean-up stage of the rendering process removed incorrect files (basically, the files without the normalizing offset) The patch should also fix a possible offset issue between the video and audio when rendering multiple times into the same folder Related: bug 450449, bug 458997 M +2 -2 libs/ui/KisAsyncAnimationFramesSavingRenderer.cpp M +1 -17 libs/ui/animation/KisAnimationRender.cpp M +0 -4 libs/ui/animation/KisAnimationRender.h M +13 -21 libs/ui/dialogs/KisAsyncAnimationFramesSaveDialog.cpp M +2 -2 libs/ui/dialogs/KisAsyncAnimationFramesSaveDialog.h https://invent.kde.org/graphics/krita/-/commit/0ed384a5dae0d99582f964c0061519769b7a0176
Git commit 2fbd233de9554bb94a98fbf53cb14dc3e457fe5d by Dmitry Kazakov. Committed on 25/09/2023 at 15:50. Pushed by dkazakov into branch 'krita/5.2'. Fix removal of duplicated frames in "Only Unique Frames" mode The offset was applied incorrectly so the clean-up stage of the rendering process removed incorrect files (basically, the files without the normalizing offset) The patch should also fix a possible offset issue between the video and audio when rendering multiple times into the same folder Related: bug 450449, bug 458997 M +2 -2 libs/ui/KisAsyncAnimationFramesSavingRenderer.cpp M +1 -17 libs/ui/animation/KisAnimationRender.cpp M +0 -4 libs/ui/animation/KisAnimationRender.h M +13 -21 libs/ui/dialogs/KisAsyncAnimationFramesSaveDialog.cpp M +2 -2 libs/ui/dialogs/KisAsyncAnimationFramesSaveDialog.h https://invent.kde.org/graphics/krita/-/commit/2fbd233de9554bb94a98fbf53cb14dc3e457fe5d
Hi, Nathan! Could you please test this build when it completes building? I couldn't reproduce the original issue, but I could reproduce a related issue with "unique frames" handling. Perhaps it could also fix your issue? This is the link to the build (it should complete in half an hour): https://binary-factory.kde.org/job/Krita_Stable_Windows_Build/1992/
(In reply to Dmitry Kazakov from comment #9) > Adding an accented letter to the path was the first thing I tried to do > here locally :) > > Could you give a bit more info about what you mean by "I'd moved the > animation to frame 0 a while ago"? Just removed a few of the leading columns > from the timeline? > > Btw, is it possible to share the crashing image with me (privately, via > email), so I could test it better? Hey Dmitry! By "moving the animation to frame 0" I meant dragging the entire set of keyframes back to the very beginning of the timeline, with the first keyframe being in 0 and so on. Because when I'd first tried to render the animation it began around the 600 mark, in order to match the original audio file I was working with Also by "crashing image" you mean the .kra files that won't render, right?
Hi, Nathan! Yes, by "crashing image" I mean the image that causes the problem. You can share it privately via email if you don't want to have it publicly available. You can also try the new build, perhaps it has the issue fixed... https://binary-factory.kde.org/job/Krita_Stable_Windows_Build/1992/
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Okay, I have the testing file on my email, so I will look into that.
Git commit 2cf4dfbf0de99d81fbe32654d0fad6a2d629ad16 by Dmitry Kazakov. Committed on 17/10/2023 at 16:42. Pushed by dkazakov into branch 'krita/5.2'. Fix rendering of the video when start frame is non-zero When start frame is non-zero or if the frames are saved with numbering offset, we should pass correct offsets to ffmpeg. Before the patch, it had the following problems: 1) If start numbering was > 4, then ffmpeg rendering failed. 2) If first frame was non-zero, then audio was saved with wrong offset M +7 -6 libs/ui/animation/KisVideoSaver.cpp https://invent.kde.org/graphics/krita/-/commit/2cf4dfbf0de99d81fbe32654d0fad6a2d629ad16
Git commit a11cf8e076e537bb457a8226cf4703cbeb33cde0 by Dmitry Kazakov. Committed on 17/10/2023 at 16:43. Pushed by dkazakov into branch 'master'. Fix rendering of the video when start frame is non-zero When start frame is non-zero or if the frames are saved with numbering offset, we should pass correct offsets to ffmpeg. Before the patch, it had the following problems: 1) If start numbering was > 4, then ffmpeg rendering failed. 2) If first frame was non-zero, then audio was saved with wrong offset M +7 -6 libs/ui/animation/KisVideoSaver.cpp https://invent.kde.org/graphics/krita/-/commit/a11cf8e076e537bb457a8226cf4703cbeb33cde0
Hi, Nathan! Could you please test this build when it is finished? https://binary-factory.kde.org/job/Krita_Stable_Windows_Build/2015/ I think the bug is fixed now. Please also check if there is any offset between the video and audio streams. Now there should be no offset :)
(In reply to Dmitry Kazakov from comment #20) > Hi, Nathan! > > Could you please test this build when it is finished? > > https://binary-factory.kde.org/job/Krita_Stable_Windows_Build/2015/ > > I think the bug is fixed now. Please also check if there is any offset > between the video and audio streams. Now there should be no offset :) Dmitry, you bloody genius, it works!! Thank you so much for bearing with all this (Also the offset seems to be alright) There *are* some other bugs I've found, but I'll get those handled in separate reports. Again, thank you!