I’m used to seeing 98 to 99% CPU utilization in all 8 cores continuously as I’m rendering in DaVinci Resolve, and if it’s a clip over 8 to 10 minutes the overall CPU Temp zooms up over 200 degrees F … so when I see this ( attached) with Shotcut. Sp, I’ve got to wonder … why is it so low and slow?
Any ideas? Is this normal? How can I push it harder?
The only remaining culprit that has not been eliminated is the disk. You are probably at the point where the disc cache is saturated, so you are down to the actual write speed of your disk drive. This will be lower than the advertised speed (which is the burst write to cache speed) by a factor of 10x, 20x or even 100x.
Which filters are you using? Not all filters are multi-threaded.
Disk is unlikely to be a concern, especially if the inputs and outputs are H.264. That’s only a few MB/sec. Any disk can handle that.
Thanks for the suggestion… but that’s not it… I have an nearly empty NVME M2 SSD on the motherboard running the application and a fast drive with the data files… and, if I do a similar video on Davinci Resolve it zipps right up to nearly 100% again but the interesting thing is that in spite of the apparent low utilization, Shotcut does appear to actually render the clips fairly quickly… I just wonder if I can speed it up (safely) cause time is $$.
This is exactly where I would expect to see a cache saturation slowdown.
…or a cache saturation slowdown here, especially if both the output of the export and the Shotcut log are going to the same physical drive.
Austin,
I’m a total nube at Shotcut and only had a Size and Rotate filter creating a picture-in-picture effect and a Rich Text Intro and Exit text filter so far… I’ve got to watch a lot more of these tutorial videos and then practice right away because I often forget as much as I learned as i goes in one ear and out the other quickly if I don’t actually do it to it.
are these two multi-threaded?
“Only had a SPR filter”, he says 
“ONLY an SPR filter…”
That is the filter I use the most, that I love the most…
…and it is an absolute CPU hog.
My guess now is that each time Shotcut makes another log entry re the SPR filter, the OS comes back with “I’m sorry, but my queue is full of the Exporting video. You will just need to wait your turn”
Is there a way to turn off the logging, ? or some other typical way to speed it up?
I’m actually not sure about the text filters. A quick way to check would be to export a short clip with no filters at all and see if CPU goes to at least 8 cores at 100%.
Another possibility… are you using hardware encoding? If so, Shotcut might be building frames extremely fast, and the lag is actually waiting on the GPU to encode the frame, which wouldn’t show up as CPU usage, causing CPU to look low.
“Slowdown” and “NVMe” don’t go in the same sentence.
@Austin, Sure thing… I’ll run a few more tests with and without any filters since based on the replies here it seems that normally typical CPU utilization during rendering is much higher than mine… I’m not complaining tho because it seems to me that its rendering fast… I wish there was a good benchmark reference I could compare against…
And yes I am running with hardware encoding using the NVIDIA GeForce RTX 2060 and its DirectX 12.1 vs OpenGL so i think you are right that that’s what may be unloading the CPU Cores…that makes sence… Thanks
That changes everything!
Since you were talking about 98% CPU utilization, without mentioning a GPU, I assumed you were doing it all with the CPU (Which some here argue is faster).
That is contrary to what I am reading online, when it comes to cache saturation. The NVMe interface is lightning fast, up to the point where the internal RAM cache is full. Then It can only go as fast as flash cells can be written, which is at least an order of magnitude slower than the NVMe interface itself.
The concept is right in theory, but the OP’s case is not a proper application of it. The OP is exporting with hardware, meaning H.264 or H.265. The output data rate for those codecs will likely be less than 50 MB/sec. Even a spinning disk HDD on a USB connection can handle that data rate. As for flash cells, an order of magnitude slower than the NVMe interface itself is still so significantly faster than 50 MB/sec that saturation cannot be a factor in this case. The people talking about cache saturation online are writing BRAW or ProRes RAW or CinemaDNG or some other format with an absurdly high data rate. H.264/265 doesn’t even remotely reach those data rates by design.
You always understand and learn fast, so I don’t stay ahead of you for long! 
I began learning about cache saturation on flash drives only recently. I was moving most of my video archives to larger flash drives, and watching with KDE System Monitor. The transfers would start out at 150 MB/sec, blazing along until the cache saturated, then they would bounce a few times before settling down to either 30 MB/sec or 18 MB/sec depending on the drive.
At those numbers, that sounds more like older SSD rather than NVMe. Newer NVMe drives can have quadruple digits on read/write speeds:
That little monster is fast.
Yet still, all but one of the reviews I found were somewhat deceiving; they all went on and on about the 6.8 GB/sec or better raw write speed; it was only on page 2 of one five-page review that I found…
"Sabrent’s 4TB Rocket 4 Plus is a writing monster. It wrote 1.12TB of data at 6.8 GBps before degrading to an average write speed of 1.8 GBps. After writing a total of 2.2TB of data, the Rocket 4 Plus’s write speed degraded once more, to 1.1GBps, for the remainder of the test. The SLC cache recovered very quickly — roughly 450GB within just a minute of idle time. "
Still,1.1 GB/sec is amazingly fast, but those touted 7 GB/sec numbers are the NVME 4 DRAM write speeds, not the true flash speed.
They have packed an enormous amount of DDR4 into these packages, which means you can think you have saved your data against loss, only to find that it vanished when the power went out after the OS had reported the data transfer complete.
This topic was automatically closed after 90 days. New replies are no longer allowed.
