Summary: | Git Master 2015-11-04 - Would like to have more than 3 concurrent processing threads. | ||
---|---|---|---|
Product: | [Applications] kdenlive | Reporter: | Evert Vorster <evorster> |
Component: | User Interface | Assignee: | Jean-Baptiste Mardelle <jb> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | Peter, qubodup, wegwerf-1-2-3 |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Evert Vorster
2015-11-04 13:55:50 UTC
I produce scripts with the generate scripts thing and just put a larger number in the script (change real_time=-3 to real_time=-8 or whatever it's called), this works fine and does make the render go faster, so it would be great to be able to push it higher in kdenlive itself. Do bear in mind though, that the mlt processing threads is not that same as encoding threads in general. If you're encoding an h264 movie with one mlt thread, it'll still use all your cores to encode the movie. See this for more -> http://www.mltframework.org/bin/view/MLT/Questions#Does_MLT_take_advantage_of_multi Git commit 579bee161e588c259731a0564ea4fd5d7b0e22e8 by Jean-Baptiste Mardelle. Committed on 06/11/2015 at 16:34. Pushed by mardelle into branch 'master'. Allow more than 3 concurrent threads, however not sure about stability, feedback welcome M +2 -1 src/dialogs/kdenlivesettingsdialog.cpp M +3 -0 src/mainwindow.cpp M +8 -1 src/monitor/glwidget.cpp M +1 -0 src/monitor/glwidget.h M +3 -3 src/renderer.cpp http://commits.kde.org/kdenlive/579bee161e588c259731a0564ea4fd5d7b0e22e8 I had disappointing effects with MLT threads > 1 within Kdenlive: playhead position did not work anymore. Sadly, having multiple processing threads also messes up video encoding. ( I was planning on starting up kdenlive in one core mode, then switching to multiple processing threads for rendering, and then switching back to single core because of the UI instabilities) I get various irregularities, like the entire effects stack not being applied, a corrupted first frame in some tests.... In short, the processing threads seem to divvy up the effects stack between themselves, and some effects take longer to apply than others, hence messing up the order in which they are applied, if at all. For rendering purposes, it would be smarter to assign a CPU to a frame, and that CPU renders the whole stack on to the frame, and the next CPU tackles the next frame, and so on for the number specified of threads, and just wait until the frame is done before passing it to the encoder. As for the UI, I have noticed some instablities there, too. In summary, the way this feature is implemented needs to be re-thunk. There needs to be processing threads on render, and one for the UI. There is already a processing threads on the encoder, and that works beautifuly. So, melt also mis-handles multiple processing threads, as far as processing goes. On v15.11.80-53-g0918054, with am amd phenom x4 9550 quadcore CPU I am able to select up to 4 threads for rendering. I would like to suggest that the limit is removed or set to twice the amount of available CPU cores. This is based on my experience (because unfortunately http://stackoverflow.com/questions/481970/how-many-threads-is-too-many doesn't have a mathematical function as an answer): In my experience (in previous versions and when using script export and editing the script), I can use 7 threads with slight speed bumps when trying to use the computer for other things from time to time. 8 threads make it more noticeable but still ok and I tend to use 8 for rendering while I'm away from the computer. |