About exporting and CPU usage

Shotcut 22.04.25 flatpak
Linux Mint 20
Xeon 2666 v3 (10c/20t), 32GB, NVME 1TB Crucial
NVIDIA GTX 1660

I think this topic has been discussed more than once, but I really like to understand if it is possible to make a faster export.

So I’m exporting a video, using or not Hardware rendering makes no big difference in this video BUT, setting on “Parallel processing” does it: from 1:05 exporting time to 0:29 minutes (HW encoding on in both cases). I’ve read that this setting can cause some artifacts, but not for me in this video.

The thing is that without “Parallel processing” I’m getting 25-30% cpu usage, and with “Parallel processing” about 65-70% cpu. It seems to use all threads anyway.

The question is: why it is not using near 100% cpu? Is there a way to set a higher priority or something that push up the use of cpu for exporting?

Bottlenecks (specific isolated areas of no concurrency or slow CPU instructions), thread mutex locks, context switching, lack of optimization, copying memory, and data transfers between memory and CPU cache or over the PCI bus in the case of hardware encoding. These are all very detailed technical things that vary significantly from one situation to the next and combine in complex ways that I do not fully understand. We try to use parallel processing (frame threading) to counteract the bottlenecks in a filter, but there can be waste due to swapping data to the CPU memory cache if there are too many.

Basically, avoid filters that cause slowness due to these reason by learning what those are by experimentation. For example, Size Position & Rotate is a bottleneck even though it is slice-threaded.

Aha. In this video I have 8 video tracks. 3 of them are the same clip but resized and cropped (rectangular), and that’s why it benefits so much from the “parallel processing” setting. other 3 tracks have greenscreen animations ocassionally (using simple chroma key), and the last is a transparent png overlay.

I have seen too that when Shotcut is making the proxy or converting to editable video, ffmpeg is using almost 100% cpu (if not hardware encoding selected for this), so it really makes sense that the combination of filters is the cause.

Maybe some kernel process scheduler can be better for these kind of works, but this thing falls far far away from my knowledge.

Anyway, it is just curiosity, because what really matters, the edition, is really fluid for me using preview scaling and proxies. Not only in a decent desktop computer, but in my old laptop too. No lags, no shutter.

Thank you very much for your explanation.

This topic was automatically closed after 90 days. New replies are no longer allowed.