HDR color space irregularities

scarbrtj

I have an h265 mp4 HDR Main10 movie file. I am editing in Premiere Pro 2020 version. When I export with Voukoder, regardless levels (0-255 vs 16-235) or constant luminance or NCL, and I am exporting with 10-bit turned on in the Bt2020 color space, when playing back these files on an HDR TV the whites are WAY blown out. It's rather horrible. If I export with Premiere's builtin h265 exporter using Main10 settings, the video comes out looking pristine. I can provide you with the source mp4 file if necessary but it is ~50GB so will take some coordination.

My question is, have you edited true 10bit HDR BT2020 files and exported with Voukoder AND played back on an HDR TV? Vouk is passing HDR metadata to the TV (ie the TV "knows" it's getting an HDR stream e.g.).

Hope this makes sense. In short, I do not think Voukoder is exporting and handling HDR source files correctly. I am aware HDR is a work in progress in premiere, but premiere on its own handles these exports in a predictable and proper manner.

Also on another note--do you think Vouk is "over amping" or "over normalizing" Ac3 and EAC3 audio on export? It sounds very very loud when bitstreaming to receivers/TVs.

thanks in advance

Vouk

First, what version of Voukoder are you using? There have been massive improvements made in version 2.3. You can try the release candidate version, but there will e a final 2.3 release this week.

I don't have an HDR TV (But I really wish to have one).

morphinapg Wickyed Maybe you can help here.

Regarding the audio: Voukoder is just using the FFmpeg encoders. Did you compare this with FFmpeg on the command line?

scarbrtj

thanks for reply. let me try new version. I am still on 2.2 I just realized. I will report back after updating to latest RC version.

scarbrtj

I can confirm with the update that the colors and highlights and etc are still way off. I believe you will be able to see on your own monitor the issues even with HDR->SDR converting. (However, on a 4K HDR TV it looks even worse although as I mentioned the TV "sees" the HDR10 metadata.) I am providing link to premiere output, voukoder output, and Mp4 source file (trimmed for size). Note how premiere output and the source file "look" the same. Voukoder output quite "off" (look st the icebergs; around 1:30-2:00 min in, all the highlight detail is off and overblown). I use MadVR for HDR->SDR.

vouk-16.235.bt2020.ncl.mkv:
https://drive.google.com/file/d/1zy6b8i…iew?usp=sharing

Premiere native h265 Main10 bt2020 output:
https://drive.google.com/file/d/16OW8BN…iew?usp=sharing

source mp4 file (trimmed):
https://drive.google.com/file/d/10G7-0E…iew?usp=sharing

scarbrtj

well hold your horses. I installed release candidate. it does not show up in premiere; i thought new versions uninstalled old ones. so I uninstalled 2.2 and uninstalled release candidate. and re-installed release candidiate. still doesn't show up. will look through forum how to get this to install. is it because i updated premiere recently??

scarbrtj

OK. Connector. Got it. Updated to rc beta 8. Now the BT2020 option is gone as an output space (which of course won't work for HDR10 and a BT2020 source file, correct?). What now?
[Blockierte Grafik: https://i.imgur.com/84KjILT.png]

scarbrtj

Some notes. rc beta8 encodes h265 about twice as slow as 2.2 for me. With 2.2 it used one NVIDIA 1080 @about 35%. Now it uses both my 1080s at about 8-12% each.

Sample rc beta8 output:
https://drive.google.com/file/d/1Vd0pz-…iew?usp=sharing

On playback on 4K TV, the TV does not recognize it as HDR. Also, the whites are now "zebra-ed" on the TV which is a really weird effect. (You will almost certainly not "see" this unless you attempt to playback on HDR 4K TV.) Playback on an SDR monitor looks normal. Please note Voukoder gave me no choice but to choose bt709 colorspace as bt2020 is now gone as an option with update.

What I think we have here is just really a lot of problems with Voukoder and HDR and BT2020.

morphinapg

You will need the latest 2.3 build, and follow the instructions in my guide here:

HDR Encoding Guide for Premiere Pro

The problem is with the way Premiere deals with HDR video. What voukoder gets is what's displayed in the program monitor. What it's expecting is the raw ST2084/bt2020 encoded video information, so you need to convert it to the appropriate format for voukoder to work properly. Don't use the colorspace filters as those will convert colors. Use the x265 flags as I outline in my guide instead.

As I explained there, you will need to use x265 for now to follow this process. Some modifications may make NVENC possible but I'm not experienced with how NVENC handles HDR, so I can't help with that yet.

scarbrtj

I saw the encoding guide, but this just makes Voukoder a more tedious option than Premiere alone which will handle h265 BT2020 10bit encodes just fine with proper color and SMPTE (Premiere native h265 Main10 bt2020 output: https://drive.google.com/file/…q41Pxu21/view?usp=sharing); Premiere alone will be software encoding just like x265 with Voukoder. And yeah, it takes like about 14 minutes for me to encode just 3 minutes of video this way.

For now it is better to rely on Premiere alone for h265 BT2020 Main10 encodes.

However, when you use NVENC in Voukoder, 4K h265 encodes at a rate of about 1:1, i.e. it takes just 3 minutes to encodes 3 minutes of video. A much better option if that will ever work! As an aside, Cyberlink software handles GPU accelerated HDR encodes very well. So we "know" NVENC will work....

morphinapg

Premiere's built in encoder will give you HDR, but there are some issues with it. For one, it's not proper HDR10. It outputs in PC range instead of legal video range, and there is no metadata accompanying it. On many players, the PC range will result in shadows being clipped, and the lack of metadata will mean you will have suboptimal tonemapping for just about any player/display. Beyond that, you can't use CRF encoding for constant quality and Premiere's encoder is nowhere near as efficient as x265.

But either way, this is a forum for voukoder, so my answer was in the context of using voukoder for HDR.

scarbrtj

The metadata does seem to accompany Premiere output (did you download the file).
When I output/encode HDR in Voukoder (rc beta8 shows this behavior; 2.2 at least did cause TV to enter HDR mode) and try to play on HDR TV, the TV doesn't know it's HDR/does not convert into HDR mode.
When I output/encode with Premiere alone, the TV enters HDR mode and the colors/highlights/shadows etc look exactly the same as the source file.
Premiere does take longer to encode than x265; but right now as stands Voukoder+x265 is kludgey.

EDIT: Also, I *believe* that if the source file in premiere is 16-235, when Premiere outputs 0-255 it doesn't map 16 to 0 and 235 to 255, so full range output is fine in that circumstance. I *believe* this is why my outputs in Premiere look correct on a TV without clipping etc... because thus far all my sources are 16-235.

morphinapg

Zitat von scarbrtj

The metadata does seem to accompany Premiere output (did you download the file).
When I output/encode HDR in Voukoder (rc beta8 shows this behavior; 2.2 at least did cause TV to enter HDR mode) and try to play on HDR TV, the TV doesn't know it's HDR/does not convert into HDR mode.
When I output/encode with Premiere alone, the TV enters HDR mode and the colors/highlights/shadows etc look exactly the same as the source file.
Premiere does take longer to encode than x265; but right now as stands Voukoder+x265 is kludgey.

EDIT: Also, I *believe* that if the source file in premiere is 16-235, when Premiere outputs 0-255 it doesn't map 16 to 0 and 235 to 255, so full range output is fine in that circumstance. I *believe* this is why my outputs in Premiere look correct on a TV without clipping etc... because thus far all my sources are 16-235.

Last time I tested the native HEVC output, it was indeed remapping and clipping. Perhaps that's changed since CC2018, but I would wager not if the output is described as full range. You could test with some "black clip" hdr test patterns. If it is remapping, it's possible your TV can understand full range HDR files, even though they're completely against the HDR10 spec.

There does seem to be some metadata there. I'm going to take a guess that premiere is either copying directly from the source file (which results in inaccurate metadata if there are edits) or it's just spitting out a default number. If it's copying from your source, it sounds like your source is using some default combination, meaning it's not actually accurately representing the content, because no properly mastered content would actually have metadata numbers that even.

Also, best not to use "16-235" when describing HDR, because it's technically 64-940. Limited or legal range is fine.

Ultimately, if it works for your purposes, that's fine. For me, it's absolutely not acceptable. I would have no way to monitor my edits in HDR, no way to monitor any color grading I might do, wouldn't be able to have a consistent quality between encodes, etc.

EDIT: Confirmed the metadata is not accurate, I quickly saw frames that had CLL above 1800 nits.

Vouk

The thing is I need to specify these values when creating the muxer / format instance:

- matrix

- primaries

- transfer

They are "unspecified" by default. Which seems to be okay for all non-2020 color spaces.

Currently they will be only set when using the color space filter and this seems to be the issue. I need to think about a smart way to set these values even when not using any filter. But if a filter is used the filter settings will overwrite these values.

morphinapg

EDIT: Sorry, made a mistake thinking I was still talking to scarbrtj

Zitat von Vouk

The thing is I need to specify these values when creating the muxer / format instance:

- matrix

- primaries

- transfer

They are "unspecified" by default. Which seems to be okay for all non-2020 color spaces.

Currently they will be only set when using the color space filter and this seems to be the issue. I need to think about a smart way to set these values even when not using any filter. But if a filter is used the filter settings will overwrite these values.

Alles anzeigen

Isn't the setparams filter I suggested the solution to that?

Vouk

Not sure. As far as i know the filter gets applied to the video stream, not to the format container.

But it seems the container (i.e. mp4) settings are important here.

scarbrtj

"EDIT: Confirmed the metadata is not accurate, I quickly saw frames that had CLL above 1800 nits."

Did you download the source file, and does it show similar or dissimilar CLL

(yes I forgot ranges for HDR

morphinapg

Zitat von Vouk

Not sure. As far as i know the filter gets applied to the video stream, not to the format container.

But it seems the container (i.e. mp4) settings are important here.

I'm not sure what the container has to do with it. The color space options are applied to the video stream. The container just holds that. It shouldn't need any extra information. I would guess container options like that would only be necessary if the video was flagged wrong in the first place.

If you see my command line from the other thread, that makes the video stream the correct format, and the mediainfo displays it correctly. If the container actually needs the color space information, ffmpeg should be passing that along correctly I would think.

All of the information generated by the colorspace or setparams filters should affect the "AVFormat" of the input which I believe gets daisy chained to whatever comes after it, another filter, codec, container, etc.

morphinapg

Zitat von scarbrtj

"EDIT: Confirmed the metadata is not accurate, I quickly saw frames that had CLL above 1800 nits."

Did you download the source file, and does it show similar or dissimilar CLL

(yes I forgot ranges for HDR

I don't have your source. You can check that in mediainfo.

scarbrtj

I did supply a link to source above

I noticed in the source file these values:
https://i.imgur.com/ucIzPGD.png

So I will set Premiere output to these values and see if the CLL "calms down", just as a test. Encoding it now....
https://i.imgur.com/2oxPqD4.png

Vouk

I was mistaken. It's the codec context I need to supply these values to. Still, they are unspecified by default and i guess we need to be able to set them somehow without any filters.

Tags