Hello, I have some files (MOV container, H.264 / MPEG-4 AVC codec) that I’m attempting to render to a dpx sequence. I used the preset, and added .%04d before .dpx in order to get desired padding for my image sequence. Based on some cursory internet research talking about threading, I have tested with: Speed, Threads: Auto, Parallel Processing on, with 1/4 of my total CPU count. Speed, Threads: 1, Parallel Processing on, with 1/4 of my total CPU count, as well as bumping up the number of threads to 6. I have also tested it with a different file from the same camera, as well as some test footage from action vfx and pexels that are different containers but the same codec (which i know isn’t much of a test, but at least proves it is not the original file). I have also tested with rendering to jpgs and pngs, with the same results.
Curiously, all clips were crashing on frame 75. I don’t see any other place for more error logs or information - is there an error console or terminal somewhere that I’m just missing? Hard to know where to go from here when the rendering log window just says that the rendering ‘has crashed.’
Edit: Realized I should also post the actual Error Log from the job Queue:
/home/indoorjetpacks/Videos/test/untitled2.%04d.dpx
Rendering crashed
Video without audio track
Rendering of /home/indoorjetpacks/Videos/test/untitled.%04d.dpx crashed
Rendering of /home/indoorjetpacks/Videos/test/untitled.%04d.dpx aborted, resulting video will probably be corrupted.
It creates them through frame 75, but crashes after that, and the ranges i was testing were all longer than that. I tested with a few from 120 (the original clip) up to 230 frames with the other test footage.
Also, is there any difference between the appimage and flathub? Or is the general point “dont use dnf and dont use fedora discover” because of updates or stability or some such? (If not, what is the reason for that recommendation? I try to avoid a ton of different ‘ways’ to install things if at all possible so would like to know exactly why I’d be adding/using yet another way to install software. )
Not from a functionality perspective. The appimage may avoid some dependencies, though.
Fedora does their own packaging, that’s why I recommend to try the Flathub Flatpak first, then the appimage, in case of issues with Kdenlive on Fedora.
Back to your issue: Have you tried rendering a different section of the project after frame 75? Does it then still crash after rendering 75 frames? What if you dropped the %04d?
In case it ever actually matters for someone testing stuff (it shouldn’t in this case), there are a couple of small differences between the appimage and flatpak for 25.04.2 (and between both of those and any distro packages someone built from a release tag).
But for anyone not using OTIO, they should be inconsequential. And in general what Bernd said should apply for most releases.
Ahhhhhhh, your suggestion about ‘rendering a different section of the project’ tipped me off to poking around some more - there was an in/out range that was small enough with my timeline overview that I didn’t see, and it seemed like the ‘Rendered File Length’ duration was updating when I was selecting clips individually (which, I suppose it may have been since I was making new projects+sequences and selecting random cut points to use.
Also, that is good to know about the flathub flatpak / appimage, and also about the OTIO Ron, since I’m using those fairly often as well (making the slow switch away from Davinci Resolve and have been importing existing projects with OTIO’s, and will likely get OTIOs in the future to work off of)
Ah, although the rendering range for my original clip is correct now (it still says it crashes when rendering, but does write files), it does appear that it’s missing color channels. Using a channel extractor inside kdenlive to compare, it appears it’s only outputting the red channel. And no change happens with ‘full color range’ enabled/disabled
If you need OTIO, then the AppImage is probably what you want to run with (and possibly even the nightlies of those). It is still work in process and some interop and other issues are still shaking out, so please do report any problems that you run into with it.