Piotr Wozniacki wrote:A quick answer for now:
-definitely, my Resolve grades look how they should (color is subjective, bu we're talking a huge red domination in the HEVC renders here, so no doubts whatsoever which are correct)
- my older HEVC renders also look much better now with hue adjusted; cannot compare them to the exact grades they originated from as they don't exist anymore. But the mere fact that - with such a big shift towards green I'm applying now - greens are not over-saturated at all speaks for itself.
- it's definitely not my Samsung, as I'm seeing the same on the Inferno (now that I can display my renders on it through HDMI, as yet another extended Windows monitor)
- I'll be experimenting further, because I tend to suspect something pretty obvious needs adjustment in the ffmpeg/libx265 command line.
Piotr
This is not what I asked.
I never heard you saying in the past that you have such a big discrepancy between Resolve preview and file playback. So is this new problem or did it always exist?It's not ffmpeg encode itself, but it can be issue with metadata. Problem is that when you play file by TV all this metadata seems to be ignored (TV probably uses e.g. Rec.2020 default settings). Why all those sample files made for Samsung, LG etc have mastering display info if TVs seems to ignore them anyway?
Your hope is madVR in this case as this passes data over HDMI (like Resolve preview does).
If you are in HDR pasthroug mode then those setting won't do anything as madVR pipes YUV data as is (with metadata I assume). It's TV which processes it according to metadata. You can try different encode with different master display metadata to check if this is passed to TV and affects its processing in any way.
Maybe Resolve HDMI does pass all this info and file playback/madVR doesn't.
Here is 1000$ question- what exactly does Resolve HDR mode enable on HDMI and where does it take all needed info from (project settings)? Does this flagging follows project settings- with white point etc included (maybe Resolve uses some default values regardless of project settings, which of course would be wrong, specially if TV does use this info for further processing!)?
Press CTR+J when playing with madVR and it will show you what it reads from file headers.
I would also rather disable calibration controls for the display just to make sure madVR does not alter your signal in any way. Your file YUV data matches (except compression) Resolve timeline, so you don't want it to be altered in any way at all! If anything it should be altered only by TV based on metadata (same as it apparently happens for Resolve HDMI preview). In this case madVR is your BM card which passes data as is. I would also rather have in Nvidia setting set output to YUV 10bit, not RGB.
Yo would need box like HDFury which would show you what metadata is traveling over HDMI in case of Resolve and madVR preview, so you could compare it. This is probably the first thing to do to 100% validate Resolve/madVR HDMI HDR preview- does it really switch all metadata according to the setting (at least for established formats P3 D65, Rec.2020 etc).
If you want to switch TV back to SDR mode you need to play some SDR (Rec.709) file with madVR. This should force TV to go back to SDR. If it doesn't maybe you have HDR set on Windows level (or there is other issue- driver, Full Screen Exclusive Mode related).
Any "by eye" adjustment to encode/TV HDMI port or preview itself is not a real solution. It may give you similar preview but this is rather poor work around.