Beiträge von morphinapg

Zitat von Wickyed

Yes it is the same, HLG does not seems to be different before and after the encoding.

What is very strange is that even when I'm using the Premiere encoder to output in HDR PQ the colors are pretty the same...

I need to test all the encoded files on screens supporting HLG and PQ to see if there is any difference.

The problem is, Premiere is reading your HLG file as SDR. That's okay if you turn around and export as HLG, but the native export will be HLG displayed as SDR, encoded in an HDR container. Just like you could encode any SDR video in HDR mode through premiere's HEVC codec if you want.

HLG is designed in a way that if you read it as SDR, it still looks fairly good, but the colors being the same is an oddity. If the source has BT2020 colors, then Premiere would likely decode that into rec709 color space, meaning you'd need to perform a conversion using the colorspace filter to fix this (input rec709, output bt2020), and then select bt2020 and HLG options in x265 for correct output. Or skip the colorspace filter and use HLG paired with rec709 colorspace and primaries, although that's not recommended.

However, if Premiere is just ignoring the color space, then you may be seeing the native rec2020 color space, which SHOULD look slightly weird in the preview monitor. Like slightly desaturated, maybe a little yellow tinted. If that's the case then you would be free to encode to x265 with HLG and bt2020 options without using the colorspace filter.

Do you have a sample source file I could test? I could maybe give you some advice on how to encode it properly.

I thought of another thing. If it's still overly dark, even with the new preset, it's possible my custom LUT isn't being loaded in the second lumetri filter, so check on that. I believe this SHOULD be embedded into the preset, but if it's not, then I can upload that separately.

Basically what the preset does, is first it compresses the 0-10,000 nit HDR range into the 0-100nit SDR range, and then the second filter performs a transformation from rec709 gamma/color into smpte2084 gamma and rec2020 color. So without the second step, you basically get an image that's 1% the brightness of the original. Open up the second Lunetri effect and see if the LUT is active. Try checking the active checkbox above the LUT selection drop down. If checking that box does nothing, then the LUT is not embedded correctly and needs to be uploaded separately.

It has come to my attention that Premiere 2020 was treating HDR inputs differently than Premiere 2019, so I've created a new preset for Premiere 2020:

https://www.voukoder.org/attachment/743…020-pp2020-zip/

Never mind the previous post. I found the issue and created a new preset for Premiere 2020. Use this and then try encoding to HDR.

Remember, the output window will look desaturated and darker, but that's because it is transformed into a format that your display is not set up to preview correctly. It should however be in the correct format for 2020/2084 output.

and now maybe I can get a little bit of sleep today (lol)

I just tested in 2020 and my preset still works correctly. Not sure what's going on with your end. Try redownloading the preset as I do see the preset is named differently in your screenshots and mine. Perhaps you grabbed an older version of it before I reuploaded. I don't remember exactly what I changed before I reuploaded, but I did change something.

Nevermind, found the issue

Zitat von scarbrtj

That would seem to be... problematic for sure.

It's not. It doesn't matter what pixel format is being sent by Premiere, it only matters that the RGB/YUV values are correct for what your encoder expects based on the flags. Hence this whole preset I've been working on. It works fine in 2019, but I need to create a new one for 2020 it seems.

Okay, so I'm guessing the issue is premiere changing how it handles HDR Video between versions. I'll have to create a new preset for 2020 and then everything should be good.

I just realized something from your screenshot. Are you using Premiere 2020? I created and tested my preset in 2019, and that's what I'm still using for now. It's possible 2020 is handling HDR input differently than 2019 did. For example, 2019 doesn't map black levels correctly on HDR inputs, as it expected a full range video and got limited range instead, and so my preset had to correct for that as well. So if 2020 is handling HDR input differently, I'd need to create a different preset for 2020. If you happen to have a copy of 2019 still, I'd see if it's working there.

Maybe re-download and re-import my preset?

This is what my premiere monitor looks like

EDIT: Encoded, looks perfect

I just noticed something, you have 3 lumetri filters applied. There should only be two from the preset.

Zitat von scarbrtj

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

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

Alles anzeigen

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.

Zitat von scarbrtj

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.

Zitat von scarbrtj

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.

Zitat von scarbrtj

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

Zitat von scarbrtj

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.