I just noticed something, you have 3 lumetri filters applied. There should only be two from the preset.
Beiträge von morphinapg
-
-
Alles anzeigen
In 2.2, PQ is not selectable. The encode just comes out that way. In 2.3, I set the settings just like you showed for another file I previously provided a link to...
2020.2084.2020.mkv:
https://drive.google.com/file/d/1t5zjJe…iew?usp=sharing
And still no HDR-detectability by TV.
Re: HDR encoding guide, here is monitor with the Lumetri presets you provide:
https://i.imgur.com/ZjRO5fV.jpg
And here is what it is "supposed" to roughly look like:
https://i.imgur.com/QPMnHsA.jpgAnd here is output file sample using BT2020/SMPTE2084/BT2020NC:
(the link is coming! will update in a minute....)
Using your guide, the output is ULTRA-dark, almost unwatchable; this is what we might guess it would be just from the monitor view in Premiere. For me for whatever reason your HDR encoding guide is the worst I have seen so far in terms of outputs. Try it on the source file I originally linked to.The monitor SHOULD look dark/incorrect. It's pre-processing the output in SMPTE2084/BT2020, which your monitor is not displaying in. If you displayed it on an HDR monitor, in HDR mode, it would look correct. Since your TV is not displaying it correctly, what are you watching it with? It's very likely your player is not processing the HDR signal, an is therefore just showing you an image similar to the premiere monitor window. What does it look like if you re-import it back into premiere without my preset applied?
I'll test your video and see what I get.
-
As you can see they are essentially exactly the same except for "transfer characteristics" which was PQ in v2.2 and now, I guess with setparams filter, it becomes something else.
That's your problem. PQ is what's required for HDR10. With setparams you should set transfer characteristics to SMPTE2084, like this:
BT2020-10bit is a totally different transfer function, not what your TV expects for HDR. In your earlier post you said it looked bad, but it will look bad if you don't apply my preset to it first. Import and apply the Premiere preset, then encode with the above settings, then test it on the TV.
-
well so demux/mux not working
Vouk... can you confirm that HDR metadata is still being added to the h265 stream. It obv was in 2.2, and seems it might be, or is, for some users.... but I can't replicate that 2.2 behavior in 2.3 now. Do you think anything changed. The main difference I see is no longer being able to select BT2020CL or BT2020NCL in the main media export Premiere window.
Be careful with how you describe this. With the NVENC process, no "metadata" will be created. Metadata is specifically describing MaxCLL, MaxFALL, and mastering display characteristics. That unfortunately can't be included in NVENC encodes as far as I can tell. But most devices don't actually require this to display HDR video. They just fall back to a default tonemapping algorithm.
However, mediainfo confirms colorspace, transfer characteristics, and primaries flags are correctly included in the video stream. My TV recognizes these and plays them correctly without modification. Why your TV doesn't is unknown. I would imagine some difference with the container formats. Are you making sure to select 10bit in your encoder settings? (although my TV still recognizes it as HDR even with 8bit as long as those other flags are in there)
Maybe you can upload a file that worked, and then a file that doesn't, and I can see if I can find anything about them that differ.
-
If you're having an issue getting the TV to recognize it as HDR, this was my process whenever I encountered that in older builds:
First, extract the streams using gMKVExtractGUI:
https://sourceforge.net/projects/gmkvextractgui/
Then mux them back together. My choice was to use the MP4 Muxer gui in MeGUI:
https://sourceforge.net/projects/megui/
Open MeGUI, if it asks to update, do so, then go to tools -> Muxer -> MP4 Muxer, and from there, import your extracted video and audio tracks.
-
I mean, it plays them fine, they just don't engage the HDR mode on the TV like all my other HDR files do. And this is a new (bad) behavior since 2.2.
When I say it plays them fine, I mean it triggers the HDR mode. My encodes from earlier betas were having that problem (which remuxing solved), but RC2 works fine for me.
-
My TV is playing the files just fine unmodified (LG OLED 2016)
-
It's possible the container issue may be related to the fact that the encodes are flagged as variable frame rate, and need to be flagged as constant frame rate. Extracting the stream and remuxing can solve this. Also, manually selecting the frame rate in mkvtoolnix may solve this as well.EDIT: Nevermind this appears to be fixed in the latest build
-
Now my "problem" I would like to see solved (before going down the encoding guide road, Lumetri etc) is in 2.2, HDR10 metadata was included with HEVC NVENC and TV would engage HDR mode. Now, it will not with 2.3rc2. Would like to see that added back somehow.
Regarding HEVC NVENC... To put another way, 2.2 made true HDR10 files that looked really bad. 2.3rc2 makes files that are not true HDR10 from a 4KHDR TV standpoint but look a lot less bad than they ever have.Again are you using the plugin preset from the guide? It's the only way to get the colors to be pre-processed correctly to look right on HDR output. Otherwise you'll get way blown out highlights and oversaturated colors.
Again, for the TV thing you may need to try both MP4 and MKV, and if neither work, you can try remuxing. I've had that issue before too, it's not the video encode, it's with the way ffmpeg handles the container it seems. Sometimes it works, sometimes it doesn't. Also, files that won't work on one device may still work on others. I've had files not display on my TV but work fine on my 4K Blu-ray player.
-
As for getting the TV to recognize it, that depends on your TV. I've sometimes had to use MKVextract and then mux them into an MP4 with MeGUI's MP4 muxer or a similar MP4Box-based muxing gui or command line.
-
I tested with x264, VP9, and ProRes and they're all outputting HDR correctly now too!
-
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.
