Rendering does not use full CPU

[farid abdelnour]

Hi Evert, long time!

Em qua, 25 de set de 2019 às 01:41, Evert Vorster <evorster at gmail.com>
escreveu:

> Hi there, Farid.
>
> I usually stay out of flame wars, as nothing good comes out of it.
> However, one of the complaints against kdenlive is it's slow preview speed
> on crappy hardware.
>

Agree.

>
> ----------------from the war---------------
> Kdenlive can't utilize a modern PC's hardware - no matter what you throw
> at it - 4 Titans, Threadripper and 128 GB of RAM - it'll be no faster than
> on a Core Duo and integrated graphics and 8 GB of RAM. It can't play back
> smooth 1080p video even when no effects are used. That's not what you'd
> expect from a professional video editing software in 2019.
>
>>
>> As we have explained to you before, this is an upstream problem. We are
>> trying to internally find a solution but you must know that the project is
>> maintained by basically one person most of the time. Welcome to the FLOSS
>> reality. If you skim through the issues tracker (
>> https://invent.kde.org/kde/kdenlive/issues), you'll see that we are
>> aware of your woes and are working to fix them, these things take time,
>> again because FLOSS. Do you get it now?
>>
> ----------------end of excerpt----------------
> Original poster might be embellishing a bit. I have no problems with 4K
> HEVC on my aging i7 with only 24GB of RAM.
>
> But, I feel you may be slightly wrong in saying that this is an upstream
> problem and that there is not much we can do about it.
> This is not entirely an upstream problem, and there are things that can be
> done about it:
> To make editing and preview smooth on older hardware and emulators, use
> proxies and this neat little trick laid out in:
>

I am referring about the fact that MLT doesn't support yet GPU processing
effects so that is one of the main issues and it is upstream. Proxies is
definitely a must, I use proxies on every project and very few effects, so
that is why it is not so bad for me I guess.

>
> https://bugs.kde.org/show_bug.cgi?id=369080
>

> It is a bit long-winded, my apologies for that.
> In short, to massively improve preview performance, drop the project
> resolution. Like, way down, to VGA size..
> Once you are ready to encode, bump it up to your desired resolution.
>
> I have asked for JBM to take a look at having the preview resolution tied
> to the preview window size, or proxy resolution (I mean, why would you want
> to have a higher resolution than the footage that you are playing back, or
> the window displaying it), instead of the project resolution, but he is a
> busy man and must have forgotten about it.
>

Very interesting suggestion, maybe JB can work on it for 19.12 as a
possible workaround. Don't know technically how feasible it is though.

>
> To speed up render performance, make a kdenlive profile that does hardware
> encode. I have had some successes with it, but then again I don't care how
> long it takes for something to encode... I walk away from my computer and
> go do something else while it is working away.
>

> Kind regards, all.
> Thanks for all the hard work you are putting into this wonderful
> software... please don't stop!
>

Thanks for your feedback

Cheers!

-- 
1111.1010.r.i.1101|n.o.i.s.1110|i.m.1010.g.1110|مقاومة
fsf member #5439
usuario GNU/Linux #471966
|_|0|_|
|_|_|0|
|0|0|0|
<a href="http://www.gunga.com.br">gunga</a>
<a href="http://www.tempoecoarte.com.br">tempoecoarte</a>
<a href="http://www.atelier-labs.org">atelier-labs</a>
<a href="http://www.mocambos.net">rede mocambos</a>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20190925/281c8cce/attachment.html>