I tested with x264, VP9, and ProRes and they're all outputting HDR correctly now too!
Beiträge von morphinapg
-
-
scarbrtj are you using the plugin preset I included in my guide? Without that, it won't look right. You need that for correct HDR pre-processing
-
2.3rc2 allows you setting different color space values using the "setparams" filter.
Hope that helps.
I tested it and it works. I can't fully test 10bit HEVC with NVENC because my GPU doesn't support 10bit encoding with NVENC (GTX970) but with 8bit selected, all of the correct color space flags get passed correctly. I've updated the HDR guide to add this bit of detail.
-
Starting with Voukoder 2.3 RC2, you can now use NVENC's HEVC codec to encode in HDR as well following this guide. Make sure your HEVC output is in 10bit mode, and then go over to the filters tab and add "setparams" to the following:
The biggest issue is you won't be able to inject the stream with proper HDR10 metadata. So if you want a fully HDR10 compliant output, make sure you use x265, but for basic HDR support in HEVC through NVENC, this is now possible. Thank you, Vouk!
-
I am using an HDFury Diva (https://www.hdfury.com/product/4k-diva-18gbps/) to generate that info so I would *guess* it's not individual frame but the HDR metadata as transmitted by the source itself for the entire stream. That is, this info pops up the split second an HDR stream starts, and that info doesn't change for the entire time I capture.
Well I think we can all agree ingesting and encoding HDR is pretty complicated to get right.Okay I know the HDFury gets it right. Premiere is definitely expanding from limited to full range then, which causes the nit values to display and measure incorrectly. It might still look close enough in many places, but it's not a totally accurate reproduction. My process should result in something much more accurate.
And with the setparams filter in the future, that process should be applicable to NVENC HEVC as well.
-
Can the decimate filter be added at all? Sometimes my video game footage is 30fps inside a 60fps container, but sometimes using decimate instead of just changing frame rate manually results in less frame judder, as it can account better for variations in frame pacing.
I wasn't sure if filters that change the frame rate would be possible or not.
-
FWIW here's the HDR info from the source at the moment of source capture
https://i.imgur.com/Yhck95q.pngOkay, so either that is a measurement of a single frame, or Premiere absolutely is transforming your RGB values, making highlights brighter (and shadows darker)
If the whole source gives you that metadata, you should use it in premiere. But Premiere is still setting the output inaccurately it seems.
-
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.
I see two cases:
1. leave it at unspecified when no filters are used. If someone wants they can set these manually in x265 and maybe other codecs that have those options. This is how I use 2.3, I believe.
2. They can use filters to specify them if they need to be specified
-
Alles anzeigen
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.pngOkay it's cool to see Premiere has changed their output options there for HDR. Sorry about being inaccurate about that. Haven't tested that in a while. When I tested it, it was just a single checkbox for HDR and that was it.
However, your source isn't anywhere near that dark. The source values are flat out wrong. Like I said, MaxCLL in your source is probably close to something like 2000. MaxFALL I wouldn't be able to tell you without taking a lot more measurements.
-
"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.
-
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.
-
EDIT: Sorry, made a mistake thinking I was still talking to scarbrtj
Alles anzeigenThe 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.
Isn't the setparams filter I suggested the solution to that?
-
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.
-
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.
-
Okay, I first tested with
ffmpeg -i test.mkv -vf setparams=color_primaries=bt2020:color_trc=smpte2084:colorspace=bt2020nc -c:v libx265 -crf 18 out.mkv
but that did nothing
however, when I did it this way:
ffmpeg -i test.mkv -color_primaries bt2020 -color_trc smpte2084 -colorspace bt2020nc -c:v libx265 -crf 18 out.mkv
it worked perfectly
I don't know how to test NVENC from the command line though. I think you need a special build for that, but I have a feeling it would work similarly, given how NVENC passes on the flags given by the colorspace filter correctly.
-
That's definitely helpful, but it's still lacking smpte2084.
I actually may have just found an alternative filter: setparams. It basically does the same thing as colorspace, without any conversions, and supports all the formats we need. The colorspace filter could still be useful in cases where you definitely want full control over the input and output color spaces, to control conversion between spaces within those possible values, but if all you want so do is flag the incoming video as these formats, setparams may be the better choice
-
I did some tests and while I was able to get NVENC to output BT2020 color correctly, the colorspace filter unfortunately doesn't have a SMPTE 2084 setting for trc, and the BT2020-10bit option doesn't work as an alternative, so as of now, it's not possible. Use x265 instead.
-
It may be possible to create a different preset for use with NVENC, when colorspace as it currently exists is also being used, but I will need to test some possible solutions for this. Again, even if I do, you'll still be lacking some HDR metadata support.
-
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.
-
You can't select these BT2020 etc options with HEVC NVENC. Do you not get faster h265 encode though with NVENC vs x265? Or the same, more or less?
Yeah I have no experience with NVENC for HDR. NVENC will definitely be faster, but the quality will be lower (or require higher bitrates), so typically x265 would typically be the better option anyway if you're prioritizing quality or file size. You'll just want to make sure you have a good CPU. I'm currently using a AMD Ryzen 7 2700X and long videos can still take quite some time to encode. I encoded a 2.5 hour video recently and it took me about 24 hours.
What we may need to support NVENC is the addition of the ispace, itrc, and iprimaries settings in the colorspace filter options. You can correctly set space, trc, and primaries in the colorspace filters, but I believe they will perform conversions, assuming the source is rec709. In order to prevent conversions, you'd need to set ispace, itrc, and iprimaries instead to define the input characteristics manually, rather than letting ffmpeg assume them. If those options are set correctly, it's possible NVENC may be able to automatically encode into HDR, but you won't be able to include HDR metadata like MaxCLL, MaxFALL, or mastering display characteristics either.
