Exporting (& rendering) extremely slow (Task Manager shows low CPU & practically no GPU utilization)

Video encoding*

(Why can't you edit on these forums? :/)

Yes, thank you very much.  That's how it makes sense to do it, especially (thinking of it now) if you need to make a little change but need to export the whole video because of it, only the section the you changed needs to newly render.  Otherwise, you're simply exporting the (at the point) pre-rendered ProRes video and simply need to re-encode it.

Again, not sure why Premiere wouldn't have the option (to encode the render files rather than simply export them), but yeah, I honestly don't mind that extra step.  Video ending used to be my hobby.  (Would improve DVD quality stuff using AVISynth and would actually edit in Premiere using AVS scripts.)

In any case, thanks again!

I hear a lot from both Premiere and Resolve users about the limited capability to fine tune long-GOP H.264 export settings. Though in both apps *if* you know all the stuff they do have (not always obvious ... ) you can get better settings than many realize.

But still, a lot of heavy users export say a ProRes 422 or LT, then take that in ShutterEncoder, Handbrake, or ffmpeg to do their deliverables.

As it seems SE and Handbrake are both essentially user interfaces using the ffmpeg coding. SE has a newer, easy-to-use UI compared to Handbrake but both provide a ton of options.

Neil

Ah, well that makes sense; thank you.  Okay, so it's literally an export of the rendered clips into a container.  Why wouldn't they have an encode option built in?..

You know, seems like that's the best option anyway, and then encode the darn thing externally in Handbrake or something.

For Premiere to "use previews", they must be exactly the same fornat/codec as the export will be. As in, say both are 1920x1080 29.97 ProRes 422 ...

And the codec must be an intraframe not interframe. No H.264/265 can be used.

Last message got cut off for some reason.  Meant to say "either way, that's the reason?"

Also, if the clip is fully rendered and I choose the option to "Use Previews" (which are also 2160p, and either way are now a rendered video with all the corresponding frames), why does it take just as long?  I was hoping at the very least that would rememedy the problem, though ideally then the project render would be uncompressed (which is way too large).  Any input on this?

Right, well that explains it, but so... this "behavior" sounds like a bug (or certainly suboptimal/inefficient in terms of resource management for this process).  I'm not sure I understand your suggestion of stopping the export and restarting it.  That would just reset the process.

Also, as you can see, the VRAM usage was the same for the latter part(s) of the sequence, and so you're saying that, either way,

I think the problem there is Adobe's behavior by design. If graphics RAM gets depleted (or maxed out) during export of an ultra-high-rez still image, then Premiere Pro will become locked to the ultra-slow-mode (no GPU acceleration at all, and only one core is utilized while all the other cores sit idle) for the entire remainder of the export job. The only way to regain GPU acceleration would be to completely stop the export, and if that does not solve it exit and restart Premiere Pro.

So... it's still rather slow, but it did significantly pick up around the 35% mark and then even moreso at the 50% mark (actually finished within an hour after this).

As you can see, the GPU also started to work and be utilized.  Either way I don't think the process should take this long, but I've come to learn, I think, that the GPU isn't utilized for photos and that Premiere has a hard time working with PNG images.  What I don't understand, if that's the case, is why they aren't just internally converted , but yeah, it was high resolution PNG images that were being rendered in that process.  At the "35%" mark, it's lower resolution JPG images without any changes in scaling or movement/location, and then the latter half is already (possibly pre-rendered, although it's still in yellow) video from another project.

The question still remains then, however, why the low CPU usage?  The point isn't just that it's slow (for whatever reasons that may be).  It's clear, based on its behavior, that RAM isn't the bottleneck for this process.  It may be for the computer, but not the issue here.  Primarily the question is, why the underutilization of CPU pretty much throughout?  Is it not able to utilize all the cores (it's not/cannot be turned into a multi-threaded process)?

Hmm...  Something tells me that's not right.  I'm going to try recreating the beginning part in another editor and see how that goes.  There's absolutely no reason it should be like this.  Besides, I previously exported in 30 FPS, and it was still long (took like a day and a half), but not this ridiculous.

I'll get back here after I try.  Hopefully this job finishes by the end of at least tomorrow...  I think the last half should be less intensive because it's an import of another project/sequence.  It's really just upscaling from 1080p to 4K.