Hardware Encoded render is darker than the original, the preview or a Software Encoded render

Report · Dec 18, 2020

Hi everyone,

I've been dealing with exports being too dark for the past few days, or at least: the colors are waaaay off from the original video. Since I now finally have a 100% sRGB monitor, I thought it might have to do something with that, so I went down a rec.709 / sRGB rabbit hole yesterday.... But corrrecting into either direction did not get me back to the image of the original. So that couldn't be the problem...

Then I thought it was just my new computer, so I tried my trusty laptop, and it has the same issue (apparently I've been exporting dark videos for a while now....).

Just today I decided to test the difference between Hardware Encoding (which I've been using for months, thank god for the 2.5x extra speed and a cooler overall computer in my case - meaning WAY less fan noise) and Software Encoding. Software encoding is so close to the original, I couldn't even tell Software and Original apart when putting them on 2 different tracks and switching between the 2. So the problem only arises with HW Encoding.

Here's 3 screenshots from the Premiere Pro preview window (of course, the problem is also there in VLC, on my phone, and other video players).

You can clearly see that in the bottom image the stage is darker, and I myself am more ?orangy? ...

System:

My desktop is an AMD Ryzen 3700x system with RTX 3060 Ti, latest CC version of Premiere Pro, latest version of Windows, latest version of Nvidia Drivers.
My laptop is an Intel 6700HQ system with GTX 960M (I guess you can see why I chose to upgrade 😉 ), also everything is fully updated on there, I made sure to double check.

I've played around with the export settings so much, I'm sure I've covered all the bases to rule out what's causing the problem. I normally export h.264, 1080p, hardware encoding, VBR 1-pass, 16 mbps.
Also just using "match source - high bitrate" gives me the same problem.

I've googled for so many hours now, I just don't know what to do.

Oh, I just wanted to hit "post", when I thought to test importing the SW and HW versions and rendering them again, and see if there are any extra changes being added...
Weird conclusion: re-exporting the SW render as HW or SW does NOT change the video. And re-exporting the HW render as HW or SW does NOT change the video. HOW??

This gives me the impression that it must happen when Premiere Pro interprets the original file. I just looked into the properties of all the clips in my now overcrowded Premiere project, and found out that the original is "Video Codec Type: MP4/MOV H.264 4:2:0 (Full Range)" while all the other ones are "Video Codec Type: MP4/MOV H.264 4:2:0".

Does this mean that it has something to do with my GPU interpreting the "Full Range" (I'm guessing that's the 0-255 vs 16-235 thing) footage differently from the non-"Full Range" stuff, while the CPU sees them both as being the same?
But how does Premiere Pro get that wrong only in the render, not in the preview window?

Also: incidently I just tinkered with the Nvidia Control Panel settings {"Adjust Video Colour Settings" - "With the Nvidia Settings" - "Advanced" - "Dynamic Range" - "Full (0-255)"} yesterday, because of a "Matt WhoisMatt Johnson" video about colours being wrong after the render, but that didn't change anything for me.

I just checked the Waveforms, and it looks like the HW version stretched the values out with a mid-point that stays in place around the 100 (out of 255) mark.

I can't find ANY settings that fix this. Not in "Interpret Footage", "Export Settings", "Sequence Settings", "Project Settings" or "Preferences".

Is there anyone who can save me? This shouldn't happen, right?

Report · Dec 18, 2020

I believe 99,9% of videocams produce files with limited color range (16-235), and it seems NVENC by default assumes that the video is 16-235 unless told different. So either you change your input, or find a way to tell encoder that it's 0-255 actually.

Report · Dec 19, 2020

I've spoken to Adobe Support Staff, and this is something that should not be happening. After them and me testing multiple other files as well, we concluded that it's in fact a color range issue. Apparently some cameras (I assume some "older ones") use the full color range. The 2 cameras that produced these problems were a GoPro 5 and a Canon EOS 600D. My Sony a6400 and my Samsung Galaxy S20 do not produce the same problems. And in fact, the problem-producing files are "MP4/MOV H.264 4:2:0 (Full Range)" (read: 0-255), and the ones that don't produce any problems are "MP4/MOV H.264 4:2:0" (read: 16-235). Still, the problem only arises when using Hardware Encoding.
This video mentions some of the color-range weirdness (around the 4 minute mark he shows the differences): https://www.youtube.com/watch?v=7kjZZNT5js4&ab_channel=EposVox

They've asked me to submit an official "feature request" to have them fix it, and are quite sure it will get picked up by the dev team. I'm keeping my fingers crossed...

Report · Dec 25, 2021

Fast forward a year ... and it is still happening. Tried both 2021 and 2022 and it's exactly as the OP described. iMac 27 5K retina with AMD Radeon M390 card. Using GoPro Hero Black 7 videos.

@Unjugglablehave you heard from support at all during that year ?

Thanks

C.

Report · Dec 26, 2021

The problem is the camera is doing 'full range' encoding where Premiere assumes legal range. By standards properly applied, ALL "YUV" (technically Y-CbCr) media is supposed to be legal in encoding, 16-235. Only the 12-bit RGB media is supposed to be camera-encoded as "full" 0-255.

Note: this has nothing WHATEVER to do with how much dynamic range is captured into the file or displayed ... it's only the encoding process. How the data is 'stored' in the file. As YUV and RGB media will both be displayed 0-255 if the user doesn't muck up their system settings.

Like setting the monitor to 'full' 0-255 ... which you should never do! Period.

And Premiere normally treats any SDR media expecting it to be properly encoded ... so that's the nature of the problem. Improper camera encoding to full on a YUV file.

In the Effects folder are some Lumetri presets with LUTs in them for full to legal and legal to full as specified in the preset names. I would suggest applying the full to legal preset as the first step on handling these in Premiere.

That is the workaround for improperly encoded camera files. And if you can, set that camera to legal range encoding so you don't GET this problem. Again, it has absolutely nothing to do with image dynamic range. Capture or display.

Neil

Report · Dec 26, 2021

I think Adobe used to have a LUT that you could apply during render to fix the gamma shift. I simply apply an adjustment layer when I am finished editing. I want the render speeds of Nvenc and Quick Sync. The video below might be helpful.