HDR color space irregularities

1. offizieller Beitrag

    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

    • Offizieller Beitrag

    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?

    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

    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??

    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.

    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.

    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....

    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.

    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.

    Einmal editiert, zuletzt von scarbrtj (5. Dezember 2019 um 14:36)

    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.

    • Offizieller Beitrag

    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.

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

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

    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.