HDR support in x265 and nvenc HEVC

  • Oh okay it is not supported in the filter...


    WHY THE WORLD HAVE TO BE SO MEAAAAAAAAAAAN !


    Just joking :)


    Guess I will try to find a way ton convert my HLG files to PQ and then edit them in Premiere or... stick with SDR files but not exploiting the camera make me kinda feel sad.


    Thank you both for your help and time.

  • Vouk

    Set the Label from Feature Request to Done
  • Vouk

    Set the Label from Adobe Premiere / MediaEncoder to Independent
  • Good idea.


    I will probably try to implement it by myself if they don't answer.


    Thanks again !


    EDIT: Could it be possible to use the zscale filter (https://ffmpeg.org/ffmpeg-filters.html#zscale) instead of the other filters currently in use ? Maybe not replace it in the code but add an option to customize the ffmpeg input where user can add their own parameters and use their own filter ?

    It seems this filter handle the HLG transfer function.

  • Theoretically yes, but it does not use FFmpegs standard values i.e. "709" instead of "bt709". Makes it complicated again to map all of these. I'll think about this later.

    Stay up-to-date and follow me on Twitter. Tell me your feedback.


    Help to improve this plugin and support me on patreon. Thank you.

  • I noticed that. That being said, the current 2.3 beta4 encodes using bt2020-10, which appears to still appear as PQ as per mediainfo, but perhaps we should still include the x265 tags for further control in case some things are not fully supported by ffmpeg yet.

  • I'll switch to zscale before any doing any release. As these settings are saved together with a project I'd like to prevent any conflicts like "bt709" vs "709".


    Please confirm zscale has all the options you need.

    Stay up-to-date and follow me on Twitter. Tell me your feedback.


    Help to improve this plugin and support me on patreon. Thank you.

  • Okay, I think this would work. Let's say you wanted to set:


    Range: Limited

    Color Space: BT2020-NCL

    Transfer Characteristics: HLG

    Color Primaries: BT2020


    Convert input to output: No


    Then, if I'm understanding zscale correctly, the options would be:


    zscale=rin=limited:pin=2020:tin=arib-std-b67:min=2020_ncl


    but if you checked the convert box the options would then be:


    zscale=r=limited:p=2020:t=arib-std-b67:m=2020_ncl


    (unless I'm understanding that "convert" option backwards, then just swap them)


    I noticed the "tin" options on https://ffmpeg.org/ffmpeg-filters.html#Options-4 didn't match all of the available "t" options, but I'm guessing anything in one should work in the other. HLG and PQ are both supported there, so I think that should be good.

  • I am thinking about removing these dropdown boxes again and just extend the regular zscale filter (Configure > Filters > Add filter (zscale) ) to support all the color space options. It'd be more consistent, I guess.


    That'd mean that there is also no need for the conversion checkbox, nor any mapping of option values. You can just add that filter if you need it.

    Stay up-to-date and follow me on Twitter. Tell me your feedback.


    Help to improve this plugin and support me on patreon. Thank you.

  • I am thinking about removing these dropdown boxes again and just extend the regular zscale filter (Configure > Filters > Add filter (zscale) ) to support all the color space options. It'd be more consistent, I guess.


    That'd mean that there is also no need for the conversion checkbox, nor any mapping of option values. You can just add that filter if you need it.

    That could work. It's a little less obvious what to do if you're intending to encode HDR and don't know these steps though. I do like the idea of having total control under the zscale options, I just worry about the user friendliness of the HDR workflow. If you're intending to do a color space conversion, that approach is intuitive. If you're just intending to make sure those values are flagged correctly, that procedure isn't as obvious.


    Perhaps instead, color space should have its own tab under the video config window. If you do that, you could allow the user to optionally select input and/or output color space options, whichever they need. By default I would have all color space filters turned off / unchecked, and let the user only turn on the ones they need. Probably default to limited range and rec709 options, since most people won't be doing HDR (yet).


    Might also be a good idea to bring back the x265 settings in this case too. That way people would be able to find what they need either way, and it just makes the x265 page more complete/consistent as well.

  • Yes, its a less obvious for advanced uhd/bt2020 users but also less confusion for yuv 420 hd/rec709. It depends on the use case. I think most users won't ever use colorspace conversion (and if the need it they can use that filter) so in my opinion it is the right way.


    Might also be a good idea to bring back the x265 settings in this case too.

    They will be back! Added them to the config already.

    Stay up-to-date and follow me on Twitter. Tell me your feedback.


    Help to improve this plugin and support me on patreon. Thank you.

  • Ouch. Well the colorspace filter could still be useable. It could be placed in the filters section, or in its own tab like I suggested above. It just wouldn't have all options for trc. But since you included the options in x265, maybe that wouldn't be as much of an issue. I just know things would be limited for other encoders. At least for now.


    I would have to imagine something is wrong with zscale though. No way it should be that slow.

  • Okay it seems to be more complex right now...


    I will try zscale for performances issues.

    If zscale is an issue, skip it and set in x265 options: --transfer arib-std-b67


    along with the correct values for --colorprim and --colormatrix depending on your content


    Also, make sure premiere is importing your video unprocessed. Try opening it in avidemux and seeing if it looks the same there, since avidemux doesn't process HDR's transfer characteristics correctly. If avidemux doesn't work, MPC-HC can display the raw video if you go into MadVR settings, under devices, HDR, and set "pass through HDR to display"


    If premiere reads the color as bt2020, it's possible it might still force the editor to read it as HDR video, in which case HDR highlights will be clipped on any output with voukoder, and proper HDR won't be possible. I suspect that may happen with the way your video's mediainfo is set, but it might not since it's HLG instead of PQ. HLG is technically compatible with SDR output unprocessed, it's designed in a special way different than PQ that way. So if it's being read as unprocessed HLG, then it won't actually look too bad while editing, just a bit darker really. However, even if Premiere reads the transfer characteristics unprocessed, it may still process the color, which would be a problem for outputting in bt2020 correctly. For that, you may need zscale for converting bt709 color back to bt2020. It's just a lot of work to get this to work right, that's why I prefer to work in the raw unprocessed video (either encoded as raw, or incorrectly flagged as bt709)