Media Encoder not using GPU acceleration during cross-dissolve

[Ben Cooper]

This is a problem I've had for at least two years (actually can't remember how long), but it's finally irritating me enough to post about it.

As a whole, GPU acceleration works really nicely on my system. I have an Nvidia 1060 6GB card, 32GB RAM and a Ryzen 7 3700X. The video editing I do is for gaming stuff on YouTube, rarely anything more complex than some cuts and adding an audio track. I export everything using GPU-accelerated H.264 and it flies along beautifully fast; a ~20 minute video at 1080p60 will render in about 5 minutes.

Unless it features cross-dissolve. Now, unless I'm sorely mistaken, cross dissolve should be a GPU-accelerated effect, and indeed it works beautifully when editing in the timeline. But when I go to export - whether through Premiere Pro, or the Media Encoder queue, every time there's a cross-dissolve, performance absolutely tanks. If I monitor hardware usage, GPU drops to 0%, CPU rises to 100%, and it takes about 15 seconds to render each 60-frame transition. That's 4 frames per second, which cannot possibly be right.

The footage itself is recorded as an .MKV file, which Premiere Pro won't touch, so I pre-process it first in Handbrake to a .mp4 using the NVEnc implementation of H.264.

From Googling over the years, I seem to be the only person that's ever had this issue. I really hope I'm just being thick and there's an option I'm missing, but it's so bizarre that cross dissolve works fine in the timeline, but not in Media Encoder, and that GPU acceleration works find in Media Encoder except for Cross Dissolve. I've not got "render at maximum depth" selected, and all my GPU drivers are up to date.

If there's any advice for how to go about diagnosing or solving the problem, that would be super helpful. I've attached a 30-second sample of footage, a project that uses it in two timelines - one with cross dissolves, and one without, and the render log. As this shows, the one without cross dissolves renders in 7 seconds, the one with takes just over 1 minute.

[EckiAME]

"Cross Dissolve" is marked as "accelerated" in Premiere Pro. Can you try a direct export and see if the render performance looks different? I am trying to find out if this is a Prmiere Pro or an AME issue.

[Ben Cooper]

Exactly the same problem with a direct export.

[eckiAMETeam]

Moving the issue over to our friends at Premiere Pro.

[Ann Bens]

Tested this:

It does it on all GPU acc transitions not just cross dissolve.

[Kyle Plumadore]

Hi Ben,

You're running into a couple different issues here. 

First - the CPU usage being high is not because the transition is being rendered by the CPU - it's high because Premiere falls back to CPU decoding during export if the export format is a HW encoded format. This is due to an outstanding bug where exports can fail with both HW decode and HW encode enabled during export. You can monitor HW encode/decode independently in windows task manager if you want to see this for yourself: 

(Compare e.g. playback vs export)

Second - your source media is a GOP codec - avc/h.264. This means seeking to arbitrary locations in the file is expensive compared to a non-GOP codec like ProRes because reference frames need to be decoded first to get to your seeked frame. Whenever you have a cut in GOP media, it is equivalent to a seek. 

Normally this is a painful but manageable issue performance-wise. However, your sample sequence - which cuts up a single source GOP media file and applies transitions to these cuts - is greatly exacerbating this problem. 

Let me try to explain why:

During a transition Premiere needs to fetch frames from two media sources - one for each source of the transition. Typically, these are two distinct media files. When they are two distinct media files, even if the media files are GOP files, Premiere is sequentially accessing frames in each of the two media files. This means each file is decoded linearly - there is no seeking within a GOP file (other than potentially for the very first frame).

In your sequence - both frames are coming from the same source file - this forces the decoder for that file to constantly be seeking between two regions of the same media - e.g. it's effectively two seeks per output frame during the transition. Again, this is not a problem for non-GOP media, but for GOP media this seek is very expensive.

Since Premiere is using CPU decoding for this export, you see a large spike in CPU usage as the decoder is constantly seeking between two locations in the same file.

There is probably something we can do on the application side to handle this scenario better. I do understand why it would be common especially for editing something like a video game stream. 

In the meantime, you can "workaround" this by either using non-GOP source media files, by breaking up your source media files into separate files on disk, or by just duplicating your entire source media files.

I tested this by duplicating the media file in your sample project - once for each cut - and as expected the render time decreases to roughly the same render time as the non-transition version. If you want a copy of this version of the project/media send me an email at plumador@adobe.com and I'll provide a link. 

[R Neil Haugen]

Thanks for that detailed reply. Useful explanation.

[Ann Bens]

@Kyle Plumadore 

thanks for taking the trouble to explain what is going on under the hood.

[Ben Cooper]

Thanks @Kyle Plumadore for such a clear and detailed reply! Based on this, I figured it was worth splashing out on a big HDD and switching my entire workflow over to ProRes post-recording, and it has indeed solved all the problems. Thanks once again!