Premiere Degrades Quality of H.265 HEVC Footage With Non-GPU Accelerated Effects

[steelsam]

I’ve noticed what appears to be a bug in how Premiere renders H.265/HEVC footage after applying certain effects. From what I can tell, if an effect is not natively GPU accelerated, the image will be degraded by color noise/artifacting and perhaps a color shift. It essentially looks the same as if using MPE Software Only.

Effects such as Warp Stabilizer don’t cause this, as I don’t think they are in the same processing pipeline, but I have found that the following do:

• Camera Blur
• Neat Video
• Color Balance
• Flicker Free (older non-GPU acceleration version)
• Luma Key
• Posterize Time

Out of these, Neat Video’s noise reduction plugin is the most relevant to my workflow – but I wanted to show that this bug applies to both native and 3rd party effects. And while it’s a bummer that Neat Video for Premiere isn’t really usable with HEVC footage, I found that if I dynamic link to Ae and use Neat Video there, the issue isn’t present.

I’ve also included a couple of still frames for reference – notice the blocky color artifacts on the second image, especially in the purple areas to the left and right sides of the frame. The first image just has Lumetri applied, while the second also has Camera Blur but with the percent blur set to 0 (saturation has been boosted in both to help show the issue).

Lastly, I have observed this problem on a variety of HEVC footage (422 10-bit, 420 10-bit, and 420 8-bit) and two different workstations (specs below).

Anybody else noticing this or have some insight into what's going on?

System 1

Windows 11

Premiere Pro 2022

i9-12900K

64GB DDR5 4800MHz RAM

RTX 3080

Multiple NVMe SSDs (500GB–1TB)

System 2

Windows 10

Premiere Pro 2022

i9-9900K

64GB DDR4 2666MHz RAM

GTX 1070

Multiple NVMe SSDs (500GB–1TB)

[R Neil Haugen]

Think of how the long-GOP compression works: it takes the pixel data, and looks for blocks of similar tones, then saves data space by using the same pixel data for the group.

Say there are four pixels in a group, of 28/42/37, 29/40/35, 31/40/40, and 26/41/38.

Depending on how much compression is used, that block could easily all be recorded as 28/41/36.

Because long-GOP saves a lot of data as information about the pixels that have changed since the last 'intraframe', before the next one, or both. So, it saves the data needing to be written to disk by writing all 'nearly the same' pixels as the same.

Creating a macro-block artifact.

Premiere's not the greatest at doing high-Q H.264/HEVC. So a lot of people export say a ProRes or DNx 'master' file, then in Handbrake, ShutterEncoder, or ffmpeg create their H.264/HEVC file.

Neil

[steelsam]

Thanks for responding Neil. However, I don't think this bug has to do with long-GOP in the way you suggest. What I'm describing specifically impacts HEVC footage – not H.264 – and only presents itself once certain types of effects are applied, even if those effects shouldn't actually be doing anything to the image (i.e. Camera Blur but with the amount set to 0%).

[R Neil Haugen]

H.264 and HEVC use different patterns and algorithms or whatever the specific process is called, so it is expected the results will not be duplicates albeit at different data rates.

Camera blur is a major cause of image degradation in long-GOP encodes, both in Premiere and in Resolve. I teach pro colorists how to work in Premiere when they have to, and of course, follow very closely their work in Resolve. Participate in their forums and discussions.

Camera blur is often a problem child in those discussions. How to get some blurring but not get any macroblocking. Why? What does blurring do? It removes detail data. Details are the differences in pixels at neighboring sites. Blurring intentionally removes the details, meaning ... it blends them into more similar pixels than they were before.

Even at "0", I would imagine there is still some blurring math being processed. Perhaps more than it should. Feel free to post that bit with full details and images on their Premiere Pro UserVoice site, as that is where the devs log all posts into their system. This forum is primarily user to user. 

But this is most certainly not a Premiere-only issue. I've been around similar issues with Resolve.

And Neat can have similar effects as far as 'smoothing' something to the point macroblocking occurs. Which is why learning how to work Neat's parameters is so important. And why for instance, temporal reduction set to 3 frames may work fine for midtones, but perhaps 5 frames is needed with shadow images especially if macroblocking occurs.

HEVC uses even more intensive compression patterns than H.264 as it has to in order to get significantly more compression.

So is it possible there's a bug? Yes ... possible. And feel free to post to the engineers.

Is it possible this is an issue with settings and with long-GOP compression, especially in Premiere? Oh, yes. As noted, Premiere is not as good at long-GOP encoding as the 'specialist' apps are. And thankfully, they're all both free and very reliable.

Neil

[steelsam]

I'd like to try to clarify a few things. Forget about Camera Blur, I was just using it as an example. Any of those effects that I listed cause the exact same issue and importantly, it happens as soon as the effect is applied to a clip. So in the case of Neat Video, the macroblocking and color shift appear even before a profile is built.

Look at the images in my original post. The first still frame has it's saturation boosted via Lumetri and looks like I would expect. The second one is from the exact same clip, with the same Lumetri settings, except it has Camera Blur (set to 0 so as to not impact the image other than to showcase the issue) applied as well. The color artifacting is visible everywhere but inspect the left and right sides of the frame in the purple areas and it is easy to spot. Again, this is not specific to the functions of Camera Blur or Neat Video, any of those non-GPU accelerated effects I listed will present in the exact same way.

I also want to reiterate that I have not been able to replicate this issue with any H.264 footage, regardless of whether it is long-GOP or All-I. As such, it seems like this is a problem specific to HEVC and probably specific to Premiere since, as mentioned in my original post, After Effects does not exhibit the same problem.

As for sending this to the engineers, I did post this over on the UserVoice site. Although it can be frustrating when it often feels like I might as well write a message on a piece of paper, fold it into a paper airplane, and then throw it out the window in a random direction (just venting about my experience with the site – not aimed at you in any way). It'd be awesome to have that assumption proved wrong in this instance but I'm not holding my breath. If you would be willing to pass this along to any of your contacts though, that would be super appreciated.

[R Neil Haugen]

There are something around several hundred thousand users of Premiere Pro ... so individually, we're all kinda "small". And the engineering staff is nowhere near the size so many users think it is.

Yes, I know the head of all the Adobe 'DVAs' ... the digital video apps PrPro, Ae, Me, and Audition. And the program managers under him for each of the apps. And a number of engineers and supers in each program.

As an ACP, they've had panel discussions on the "ACP Summit" day the day before MAX, with many of the programs from Photoshop through Illustator and the Video apps there. They've discussed how their "portals" are setup and work. And every post in the UserVoice is manually logged into the system of the particular app by an engineer. And collated to be sent to the all-important Marketing & Experience staffers ... who are many layers of people, all essentially above the individual program teams for decision making.

The M&E folks work by divining metrics ... and the UserVoice is the one metric we can actually affect directly. So it's not only the way to get info directly to the team but to the, if anything, more important M&E staff.

Do they respond individually? No. Not even to mine, and I've posted a fair number. I do at times hear say at NAB or MAX from an engineer that they're aware of a posting I did.

I've also been told that my posts are LOVED by the engineers for one reason: the details they need to understand the issue are all there. Way too many posts are simply "X is broke. Fix it!"

Um ... if X ain't broke on any system they have access to, they don't have a clue what system or media you're using, there ain't no way in Hades they can do anything about it.

But given enough speicifics, if they haven't already seen the bug/problem and have it scheduled, they can test for it conclusively. They also have found that the people who post simple things with few details don't normally give more useful details if contacted. So one is far more likely to be contacted if you've given enough details to begin with.

Neil