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.
You could still talk with the ff guys and ask for that feature to be implemented 
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.
I'm guessing zscale would simply be performing a conversion anyway. I'm pretty surprised ffmpeg doesn't support it yet.
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.
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.
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.
They will be back! Added them to the config already.
Ok, I think with those there, I think that will be enough for most people if they don't know about the filters.
Okay, seems there is another issue with zscale.
It delays the export by 1.4 seconds per frame. That's not really usable.
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)
Do you have a simple solution to false the flag before editing ?
Your files appear to be AVC, so this solution may work (change all 3 to bt709):
https://forum.doom9.org/showthread.php?t=152419
I've yet to find a solution for ProRes, which I work with, but thankfully I have the option to flag it as bt709 myself in the recorder
