I noticed that no matter what I set for threads, or parallel processing, or setting real_time= in render options, I could not get the final render to use all my cores, like I could in timeline previews by setting real_time=-12 in encoder options. Let me preface this by saying that I'm no c++ dev. I have zero experience there. But I looked at the source and I found out that it was either 1, or 4 threads. So I changed it to use the KdenliveSettings::encodethreads() instead, and now mlt uses the proper number of cores/threads I have set in the rendering dialog. int threadCount = QThread::idealThreadCount(); if (threadCount < 2 || !m_view.parallel_process->isChecked() || !m_view.parallel_process->isEnabled()) { threadCount = 1; } else { threadCount = KdenliveSettings::encodethreads(); } The threadCount = KdenliveSettings::encodethreads(); was what I changed.
Interesting, has this caused any rendering artifacts (weird colors on some areas of the clips)?
There is a misunderstanding: real_time is for *processing* threads (MLT calculating frames/slices in parallel) while encodethreads is for *encoding* (typically libx264 or libvpx compressing the calculated video). Increasing encodethreads works, but beyond 4 it doesn't speed up much. But MLT parallel processing doesn't always work well (with several frei0r effects/transitions). It is difficult to find a balance filling the cores for render, as either processing or encoding can be bottleneck depending on video characteristics... For previews, the codec used doesn't use frame-to-frame compression (MJPEG, DNxHD...), so encoding almost does not come into equation.
(In reply to Vincent PINON from comment #2) > There is a misunderstanding: real_time is for *processing* threads (MLT > calculating frames/slices in parallel) while encodethreads is for *encoding* > (typically libx264 or libvpx compressing the calculated video). > > Increasing encodethreads works, but beyond 4 it doesn't speed up much. > But MLT parallel processing doesn't always work well (with several frei0r > effects/transitions). > > It is difficult to find a balance filling the cores for render, as either > processing or encoding can be bottleneck depending on video > characteristics... > > For previews, the codec used doesn't use frame-to-frame compression (MJPEG, > DNxHD...), so encoding almost does not come into equation. Yeah. I should have elaborated. I'm using GPU for encoding. Nvenc. Increasing the processing threads from 4 to 12 really sped up my render times for final rendering and timeline preview.
(In reply to farid from comment #1) > Interesting, has this caused any rendering artifacts (weird colors on some > areas of the clips)? Not that I have noticed, yet.
Vincent, could you please clarify if the information from the reporter added as recent comments is sufficient to resolve or confirm this issue?
Maybe having it as a slider, separate from encoder threads, a processing (or rendering threads) and let people use what works okay for them. I haven't extensively tested it, but I've rendered several videos that had blurs, composites, transforms, rotoscopes, transitions, etc, and so far not had issues with the effects I've used.
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!
Sorry for late reply. It's true that we could add this slider to the UI (which already has the warning about possible artifacts). There are actually many things to change to the render UI, we think to address it hopefully in 2021...
(In reply to Vincent PINON from comment #8) > Sorry for late reply. > It's true that we could add this slider to the UI (which already has the > warning about possible artifacts). > There are actually many things to change to the render UI, we think to > address it hopefully in 2021... Related task: https://invent.kde.org/multimedia/kdenlive/-/issues/444
This is still an issue. I rendered today and saw real_time is hard limited to -4, even if I try to set it in the other options widget. My encoding times are severely hampered because of this and my GPU (nvidia) is only being about 25% utilized for video encoding. Several times slower than ffmpeg or handbrake at encoding with similar options.
Git commit 75d3a9e2f7703b0aa4ae3343edcec2963e9ffc55 by Julius Künzel. Committed on 06/06/2022 at 12:57. Pushed by jlskuz into branch 'master'. [Rendering] Allow for custom processing thread count FIXED-IN: 22.08 M +10 -7 src/dialogs/renderwidget.cpp M +3 -3 src/kdenlivesettings.kcfg M +43 -27 src/ui/renderwidget_ui.ui https://invent.kde.org/multimedia/kdenlive/commit/75d3a9e2f7703b0aa4ae3343edcec2963e9ffc55