Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Hendrik]

Here is more detail on our work for JRVR, in part from improvements made and being made to libplacebo, the rendering library used in JRVR.

New in Media Center 31 Now
- HDR Tonemapping improvements
  - Fully re-designed tonemapping pipeline, better detail retention and vastly improved gamut mapping
  - New and improved peak detection and dynamic tonemapping
  - Support for HDR10+ tonemapping, using dynamic brightness and HDR10+ tonemapping curves (and preliminary/basic support for DV dynamic scene data)
  - HDR to HDR tonemapping (especially useful for HDR10+, as there is no metadata passthrough at this time)

- Black Bar cropping, based on the metadata of the new analysis tools
  - Automatically crop off (static) black bars, particularly useful for ultra-wide display setups, projectors or 21:9 TVs
  - Re-design the aspect ratio settings to make it easier to setup for anamorphic or ultra-wide setups

- More post-processing options
  - Built-in sharpening option (probably using Adaptive Sharpen)
  - Support for custom shaders (mpv-style GLSL shaders)

Coming Soon

- Platform specific improvements
  - Alternate presentation mode for Windows, to improve stability and hardware utilization (hopefully removing glitches on certain hardware)
  - Zero-Copy/Native Hardware acceleration on Linux through VA-API (Intel GPUs primarily, but also others supporting VAAPI)
  - Enabling Vulkan rendering on Mac through MoltenVK for improved performance and reliability

General Video Improvements Planned
- Cross-Platform improvements
  - Local file access on cross-platform library server setups (not strictly video, but the most important here)
  - Investigating Blu-ray "Title" playback mode for Linux/Mac

- RPi improvements
  - Hardware accelerated video decoding for RPi 3/4
  - JRVR profile tuned for the RPi

- Transcoding improvements
  - Support for transcoding into HEVC and retaining HDR10 metadata (realtime would require GPU transcoding, software is never fast enough)
  - Expanding GPU encoding options on Linux (only NVENC currently supported, minimally Intel GPUs through QSV or VAAPI will be added)
  - Investigating HDR -> SDR tonemapping during transcoding (slipped from MC30, might require GPU assistance using the same backend as JRVR, complex topic)
  - Explore moving away from fixed transcoding presets to some simple options to combine container choice + video codec preset + audio codec preset.

On transcoding improvements - it would greatly benefit from introducing GPU processing, for scaling, tonemapping, deinterlacing, and all that. However, I have been reluctant to do this for the time being due to stability concerns, as well as keeping it functional on systems without GPU power.
But with video moving as fast as it does, having a GPU to process video for transcoding might become a requirement, or at least required if those features are desired to be used. We'll investigate this topic in the coming months.

[jmone]

Great List!  Any thoughts on enabling HW Acceleration for other chroma subsampling apart from 4:2:0 (where the GPU HW supports it)? 

[Hendrik]

Probably not. The mainstream HW Accel APIs like D3D11 do not support it.

[jmone]

Worth the (re)ask as the underlying silicon is so good these days.  Even Intel's iGPUs will do 4:2:2 and 4:4:4, nVidia 4:4:4, and no idea on AMD.

[SamuriHL]

Well, you hit all the highlights of what's on my wishlist!    Very kuel.  The dynamic tonemapping is definitely high on my wishlist.  Being able to set a target nit and have dynamic tonemapping that doesn't blow out the mid-tones (hello, LG) will be a godsend for JRVR.  Taking HDR10+ metadata when available and using that to dynamically tonemap to HDR would be awesome, as my LG doesn't do HDR10+.  Any Dolby Vision improvements that can be made will be appreciated, as well.  Yea....awesome list indeed!

[SamuriHL]

On transcoding improvements - it would greatly benefit from introducing GPU processing, for scaling, tonemapping, deinterlacing, and all that. However, I have been reluctant to do this for the time being due to stability concerns, as well as keeping it functional on systems without GPU power.
But with video moving as fast as it does, having a GPU to process video for transcoding might become a requirement, or at least required if those features are desired to be used. We'll investigate this topic in the coming months.

Curious about this from a cross-platform perspective.  Obviously on Windows you have nVidia, AMD, and Intel that all support this to varying degrees.  I suspect similar on Linux.  On Mac, I have a MacBook Pro 16 M2 Max which should have plenty of GPU power for this.  Would it target that, as well?

[Hendrik]

We might look into Mac hardware encoding at some point, but its the least supported and explored for the software stack we're using.

[SamuriHL]

Yea, fair enough.  It's an amazing video editing machine, though which is why I bought it.  (Davinci).  Would be really awesome to see it get some love at some point but totally get how priorities go.

[mattkhan]

Is calibration considered "done" at this point? And video profiles (per client/library item)?

[Hendrik]

JRVR Profiles are part of the settings, not the library, so they should be per-client. Unless I'm missing some mechanism here that totally eludes me? Or you want them synced?
Making profiles per library item would be up to you, you could just define a field with some specific values, and then have the profiles look at that field. This is not exactly per item settings, but I would assume many share similar characteristics.

If you had anything else in mind, let us know.

As for calibration, calibrating HDR output is still a bit of a weird topic, and we will mostly rely on the entire ecosystem to figure that out a bit more.
Otherwise, we can do ICC and 3DLUT now. Anything else in that area I missed?

The list above is not necessarily exhaustive, and if there are any requests for topics we have worked on in the past, or new ones, they will be considered. I might have forgotten something just now when making the list, so feel free to remind us as well.

[mattkhan]

JRVR Profiles are part of the settings, not the library, so they should be per-client. Unless I'm missing some mechanism here that totally eludes me? Or you want them synced?
Making profiles per library item would be up to you, you could just define a field with some specific values, and then have the profiles look at that field. This is not exactly per item settings, but I would assume many share similar characteristics.

If you had anything else in mind, let us know.

ok I see, it feels a little tricky to manage in that a profile covers all settings as opposed some subset (c.f. madvr profiles) though I guess most (all?) of the jrvr settings are currently really driven by your hardware so should be client only? I'm not using jrvr in anger myself (yet) so my comments are necessarily a bit abstract.

[Hendrik]

ok I see, it feels a little tricky to manage in that a profile covers all settings as opposed some subset

JRVR profiles are actually isolated to the config section they are in, eg. Output has its own profiles. As does Scaling, etc. This should give some flexibility to have profiles for performance (eg. in scaling), as well as profiles related to the display or such in Output.

[mattkhan]

Right ok, I didn't realise that

I think a mechanism to remotely manage configuration would be nice (I mentioned this in the context of using DSP studio on remote zones recently, same thing), perhaps including a way to copy from one to another

[JustinChase]

It's been a while since I've brought this up, and it's never been acknowledged by JRiver before, so I'm not sure if it's just never going to be considered, but since you're working on video, I figure it can't hurt to throw it out there again.

I use a detached display often while working to watch videos, and I'm constantly having to manually adjust the display window size to match the video playing aspect ratio, which just gets old fast.

I would really love it if MC could behave like youtube and windows media center, and force the display window to match the video aspect ratio automatically.  if a playlist moves to a different video of a different aspect ratio, the window should adapt to keep the video 'full screen inside the detached display' automatically/dynamically.

Or, if I grab any side of the detached display to resize it, the window should adjust both horizontal and vertical sizes to keep the video 'full screen'.

I hope when you get to the automatic black bar detection work you mentioned above, this is a "simple" change that can also be made.

I can see no good reason to have the detached window be bigger on one side than the video playing, other than any work required to 'fix' the current behavior.

thanks for considering!

[jmone]

One more.  Now that we can detect Object Based Audio (ATMOS/DTS-X etc), can we have a Tools--> Options--> Audio--> Bitstreaming--> checkbox for just bit streaming these?  Long Live videoclock!

[SamuriHL]

Decode ATMOS to LPCM + MAT 2.0??  Is that what you said?     LOL  Yea, actually that would be a useful feature to bitstream only the object based formats.

[mattkhan]

btw what is experimental about 3D LUT support? or what needs to happen to make it not experimental?

[lepa]

For me the first priority before all this fancy stuff would be handling of HDR over network (remotes etc). As most new releases are HDR more and more videos requires tonemap/pass through to be playable on the clients. Perhaps team also thinks this way already but thought it doesn't hurt to mention it.

[jmone]

There is a bunch of stuff to consider with transcoding HDR playback to other devices.  We have a mix of HDR and SDR display devices.  I'm not sure what sort of process is needed to determine the capabilities of the target device.  I'm guessing that JR's own code (MC Clients, JRemote etc) can work out that native display capabilities, but... how about Web Browsers, DLNA devices etc.  Ideally, you would want to know the capabilities of the end renderer and then push a SDR or HDR version.

A small thing (and I know it is on Hendrik's list) is that thumbnails of HDR content are wrong in MC.

[mattkhan]

like this? https://github.com/FoLLgoTT/Warping

mpv-style custom GLSL shaders that we would use are very powerful and you get lots of control. The one above can probably be improved to actually not require the target resolution coded into it, and recently there is also new support for configurable parameters, so it would be relatively easy to create a config page for it, if this is something unique that offers rather specific advantage - for comparably little effort on our side.

fwiw I tried that in mpv and, in about 5mins, I had it quite roughly dialled in. The fiddly bit is the need to edit a text file & restart a test pattern, if it were feasible to do that in near real time (e.g. a dialog overlay with a spinner that moves a value up and down so you can watch the image distort) then that would be really nice. I wonder if, because it's a shader, it would be possible to do this outside of jrvr? something like a little util that is an offshoot of theatre view, which renders an & which has the required controls built in? Certainly that would be v neat/user friendly even if it might be more effort than it's worth.

[Hendrik]

fwiw I tried that in mpv and, in about 5mins, I had it quite roughly dialled in. The fiddly bit is the need to edit a text file & restart a test pattern, if it were feasible to do that in near real time (e.g. a dialog overlay with a spinner that moves a value up and down so you can watch the image distort) then that would be really nice. I wonder if, because it's a shader, it would be possible to do this outside of jrvr? something like a little util that is an offshoot of theatre view, which renders an & which has the required controls built in? Certainly that would be v neat/user friendly even if it might be more effort than it's worth.

We could integrate it into the JRVR settings, which generally apply live (at least when you hit "Apply") and even while video is paused, that would be relatively easy and a whole lot better then config editing already.

Outside of JRVR is not so easy, as the entire shader processing is of course tied to JRVR itself.

[Hendrik]

For me the first priority before all this fancy stuff would be handling of HDR over network (remotes etc). As most new releases are HDR more and more videos requires tonemap/pass through to be playable on the clients. Perhaps team also thinks this way already but thought it doesn't hurt to mention it.

The original post above includes HDR transcoding/streaming with some comments. Its a tricky thing to do in a way thats still realtime fast (might require GPU power, which is a bit more complicated in transcoding then it is for playback). But I understand the need for it with more and more content being HDR. Its definitely something I want to finally do, but it needs to be done right.

[SamuriHL]

Remember when you add dynamic tone mapping, I want to still output HDR.    This is great for the LG's that can set a tone curve.  If I can tone map to 880 nits, I'm gonna be happy.

[mattkhan]

We could integrate it into the JRVR settings, which generally apply live (at least when you hit "Apply") and even while video is paused, that would be relatively easy and a whole lot better then config editing already.

that would be great (particularly as it would need to be part of a profile)

would it be possible to add an equivalent MCWS call to Playback/LoadDSPPreset? if so, it means it could be updated easily on the fly from another device

[Hendrik]

The first version is available now and features the re-designed tone mapping pipeline. Any feedback on quality would be appreciated. You can turn on peak detection/dynamic tone mapping in the Advanced section (or load the "Quality" preset), I'll likely move the option back to the Output page later.

[mattkhan]

Any info on what exactly has changed? Is it described in some libplacebo config perhaps?

Do you think custom shader support can be exposed sooner rather than later btw?

[Hendrik]

If you want to read about the major changes, only really the libplacebo changelog is where any information can be found. We are shipping a git master snapshot from yesterday.

gamut mapping: https://code.videolan.org/videolan/libplacebo/-/commit/64099247d799272b9c72997c0fc834426b02ccee
tone mapping: https://code.videolan.org/videolan/libplacebo/-/commit/c378870595d3254490183352057d07359da4d54c

Alas, I couldn't find any good one about the new histogram based peak measurements. And there are more tweaks and improvements all around.

Summary:
- Fancy math to improve gamut mapping (eg. reducing BT.2020 to BT.709), resulting in improved details
- Tone mapping is now done in the IPTQc4 colorspace, which improves the quality (its a derivative of the ICtCp/IPT colorspace specifically tuned for libplacebo, which is designed for image processing)
- Histogram for peak detection, improving the peak and average brightness values, excluding outliers

Some of the other features related to that will need hooking up to settings and providing the necessary metadata, those changes will come over the next builds.

[SamuriHL]

Very kuel.  I'll give it a try soon.  I'm excited!

[SamuriHL]

I don't think it's working properly for me on my LG G2.  It's not passing any HDR metadata to the display at all.

EOTF 2: SMPTE ST 2084 [PQ], MT: unknown, WP: unknown
GRN: 31982, 16503 [0.63964, 0.33006]
BLU: 14990, 29980 [0.2998, 0.5996]
RED: 7519, 2978 [0.15038, 0.05956]
WP: 15625, 16455, [0.3125, 0.3291]
Max/Min Lum: 0 / 0 nits
MaxCLL/FALL: 0 / 0 nits

And yes, I know how you have to enable HDR in windows before starting it.  Worked in 30, does not seem to work in 31.

[Hendrik]

Verify settings maybe? HDR pass-through enabled in the JRVR config?

I could see metadata arrive with my HDFury Arcana.

Tone mapping with HDR output is coming once I put in the options for that, I assume within the next two weeks maybe.

[Hendrik]

Do you think custom shader support can be exposed sooner rather than later btw?

Full custom has some additional considerations I need to think about.

As for the geometry shader, I talked to the author of it and he agreed to let us integrate it. So I might do that first.

[mattkhan]

Full custom has some additional considerations I need to think about.

As for the geometry shader, I talked to the author of it and he agreed to let us integrate it. So I might do that first.

sounds great

[SamuriHL]

Verify settings maybe? HDR pass-through enabled in the JRVR config?

I could see metadata arrive with my HDFury Arcana.

Tone mapping with HDR output is coming once I put in the options for that, I assume within the next two weeks maybe.

I'm not sure what's going on with it.  After rebooting I could see it was 1000 nits but the rest of the metadata was still 0.  I'll hold off on further testing until HDR output is available and see what happens then.  That'll be huge for me.

[mattkhan]

If you want to read about the major changes, only really the libplacebo changelog is where any information can be found. We are shipping a git master snapshot from yesterday.

gamut mapping: https://code.videolan.org/videolan/libplacebo/-/commit/64099247d799272b9c72997c0fc834426b02ccee
tone mapping: https://code.videolan.org/videolan/libplacebo/-/commit/c378870595d3254490183352057d07359da4d54c

Alas, I couldn't find any good one about the new histogram based peak measurements. And there are more tweaks and improvements all around.

Summary:
- Fancy math to improve gamut mapping (eg. reducing BT.2020 to BT.709), resulting in improved details
- Tone mapping is now done in the IPTQc4 colorspace, which improves the quality (its a derivative specified by Dolby of the ICtCp/IPT colorspace, designed for image processing)
- Histogram for peak detection, improving the peak and average brightness values, excluding outliers

Some of the other features related to that will need hooking up to settings and providing the necessary metadata, those changes will come over the next builds.

using a JVC N7 with filter in place (native gamut is roughly DCI-P3) and comparing madvr b113 (with a particular compromise option turned on which is required for reasonable performance) with the above says that jrvr is noticeably more saturated, whether it's too saturated or madvr is undersaturated is hard to say but I am leaning towards saying it looks too much on jrvr (visually I suspect it is that red is too saturated)

one question, is target peak nits in jrvr meant to be set to the actual peak nits of your display or does it have some other meaning (c.f. madvr which has some not at all obvious config options)

[Hendrik]

If you are outputting SDR, I would recommend to try a range of target nit values, from whatever your peak is to slightly above or below it (depending where it is), and see how it looks, as the perceived result can depend on environment factors as well.
Especially if your target nit is pretty low (as many projectors are), I would try aiming a bit higher.

SDR doesn't really have a proper reference nit, so you definitely get some freedom here. We don't tonemap SDR content to your display either, after all.

If the result feels very oversaturated, I would also make sure that the gamut etc are all set properly to match the _wire format_ the display expects. A too narrow gamut on the renderer's side would result in oversaturation on the display.

If your display is DCI-P3, which seems to be what most content is in anyway, then no gamut compression would need to take place, and saturation should not really be impacted by the renderer. Unless of course your file is one of those that uses actual BT.2020 colors.
If gamut compression is being performed there are also options to impact the behavior that are not exposed, but right now its using the recommended perceptual method, which has a good balance between preserving hue, saturation and brightness. Alternatives will focus more on one of those three properties, sacrificing the others.

[mattkhan]

I set it to dci-p3 which the PJ expects, any other value looks really odd so I am pretty sure it's not a gamut mapping problem. It doesn't necessarily look bad unless it's skin tones, just obviously much more intense. I will play around with settings a bit and do some more comparisons

[jmone]

Nice changes in the 31.0.1 and 31.0.2.

5. NEW: Support for HDR to HDR tone mapping in JRVR.
7. NEW: HDR10+ dynamic tone mapping in JRVR.

HDR to HDR tone mapping is great!.  Early days, as I need to test on the TV and PJ, but it is looking good on my HDR1000 monitor with high nit content (eg looks better than what the screens Tone Mapping does).  How does the interplay between these two features work (I see if I also enable "HDR10+ dynamic tone mapping in JRVR" then in the JRVR Monitoring that there is then no mention of HDR to HDR tone mapping.

8. NEW: Image sharpening post-processing for JRVR.

I know someone who is going to like this when it becomes public

6. NEW: JRVR uses a new dynamic tone mapping algorithm using a re-designed histogram peak detection, enabled by default in the "Quality" preset.

How do you read this?  I just see the attached static pic.

[SamuriHL]

Very, very kuel!!! 

EOTF 2: SMPTE ST 2084 [PQ], MT: DCI-P3 [WO], WP: D65
GRN: 34000, 16000 [0.68, 0.32]
BLU: 13250, 34500 [0.265, 0.69]
RED: 7500, 3000 [0.15, 0.06]
WP: 15635, 16450, [0.3127, 0.329]
Max/Min Lum: 880 / 0.005 nits
MaxCLL/FALL: 699 / 0 nits

NICE   It looks REALLY good especially for the first version of it.  Well done!

[Hendrik]

How does the interplay between these two features work (I see if I also enable "HDR10+ dynamic tone mapping in JRVR" then in the JRVR Monitoring that there is then no mention of HDR to HDR tone mapping.

HDR10+ is not a feature you can turn on or off. If the file has HDR10+ tone mapping data (which not all HDR10+ files do, some just have scene peak data, which then disables peak detection only), then those metadata defined tone mapping curves are used. The tone mapping algorithm should show up as st2094-40 in the OSD - but only if its actually doing something - eg. the scene brightness is above your desired peak, otherwise its not there at all.

Of course HDR10+ metadata is equally used when tone mapping to SDR.

How do you read this?  I just see the attached static pic.

Read what? The image shows the tone mapping/gamut mapping debug visualization.
The colored part is the gamut lobe, and the "graph" is the tone mapping.

Its more to help figure out what tone mapping is doing, not for users to gain information from. I can barely read it myself, but having it helps to show it to the people that do!

The text info OSD will contain a lot more information now about the tone mapping, including the measured brightness if dynamic peak detection is enabled (its not a separate bullet point, but should say something like "<algorithm> tone mapping (measured -> desired)". That should be more interesting for most people.

[SamuriHL]

What happens when a video has both HDR10+ and Dolby Vision?  Does it just stick with the HDR10+ metadata to help with tone mapping and setting the tone curves?  Or does it somehow use both?  The reason I ask is I see both listed in the display when playing one so was unsure what, exactly it was doing.  Looks fantastic either way just more curious how it works.

[Hendrik]

What happens when a video has both HDR10+ and Dolby Vision?  Does it just stick with the HDR10+ metadata to help with tone mapping and setting the tone curves?  Or does it somehow use both?  The reason I ask is I see both listed in the display when playing one so was unsure what, exactly it was doing.  Looks fantastic either way just more curious how it works.

If HDR10+ tone mapping curves are present, it'll use those. Thats not a features supported from Dolby metadata yet. Dynamic scene brightness is used from either HDR10+ or DV, hopefully they wouldn't vastly disagree what the brightness is.
Note that there is no commercial content that ever supports both. Self-made content with copied metadata from other sources ... well no guarantees if they don't match.

[SamuriHL]

If HDR10+ tone mapping curves are present, it'll use those. Thats not a features supported from Dolby metadata yet. Dynamic scene brightness is used from either HDR10+ or DV, hopefully they wouldn't vastly disagree what the brightness is.
Note that there is no commercial content that ever supports both. Self-made content with copied metadata from other sources ... well no guarantees if they don't match.

That is absolutely untrue I'm afraid.  There most DEFINITELY is commercial content that has both!  I know, I have a bunch.  Alien, Alita, etc etc.  Hence the question.  Whether they match, I couldn't tell you as I don't have HDR10+ support on my LG OLEDs.

EDIT:  This is from 1917, as an example:

Video
ID : 1
ID in the original source medium : 4113 (0x1011)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU, Blu-ray compatible / SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible
Codec ID : V_MPEGH/ISO/HEVC

Fun, right?? 

[jmone]

Hendrik, do you know if HDR10+ JSON Sidecar files are supported?

[Hendrik]

Hendrik, do you know if HDR10+ JSON Sidecar files are supported?

They are not, and will not be. Metadata needs to be in the video. Metadata in extra files is a tool for authoring, not for playback.

[jmone]

thanks

[tzr916]

Video is a constantly evolving topic, and while JRVR has made tons of progress, there is always more work to do....

Most of this JRVR tonemapping talk goes over my head 

Can I ask about a basic video playback feature that has been on my MC wish list for years - I predominantly use MC to watch Tv and movies in theater view with an IR MCE remote control and bitstream the audio. Is there any way you can put video playback slow motion controls into the theater view OSD (similar to Subtitles/LipSync/Zoom). And more importantly, prevent the "DSP Tempo dialog" from popping up when slow motion is enabled, preferably add an option to just mute the audio when video slow motion is used.

Thanks

[JimH]

Split Displaycal discussion.

[bogdanbz]

Many thanks for this listing!

Regarding Windows color profiles and gamut mapping in JRVR, please note that Windows is switching from a passive attitude to system color correction (where the applications are responsible for performing the color conversions according to the display characteristics specified in ICC profiles associated with the display) to an active role where Windows performs automatic color correction at system level in an individual manner for each connected display (Advanced Color). This is done by performing de-gamma, color space conversion and re-gamma in the graphic card, using hardware blocks as described here.

This was already the case for Windows HDR mode since some Windows 10 build, but it's going to be enabled for SDR as well in Windows 11.

The display ICC profiles can now feature Microsoft proprietary tags to list display characteristics just for HDR mode, such as display min/max luminance or frame average luminance, as well as color primaries or white point. This can override EDID or DisplayID data that was used before for HDR presentation.

Details and links to other articles that go into more detail are here: Use DirectX with Advanced Color on high/standard dynamic range displays.

Please also note that using SetHDRMetadata on the swap chain is no longer guaranteed to send metadata to the display, as Microsoft warns about it themselves. I warned about this before, but I did not have a link to an official Microsoft statement to bring proof about this, and I was told the device you use shows the display is still sent the metdadata you specify on the swap-chain.

[bogdanbz]

Since I notice there is HDR10+ support coming, may I request looking into whether HDR10+ passthrough can be implemented. HDR10+ Gaming support was recently enabled in the Nvidia drivers (r526.98), and some games, such as the latest Need for Speed from Electronic Arts I think, can already output HDR10+ to compatible displays. It might only work when switching to HDR is done through the NVAPI though, I have not looked into it.

[Hendrik]

Since I notice there is HDR10+ support coming, may I request looking into whether HDR10+ passthrough can be implemented. HDR10+ Gaming support was recently enabled in the Nvidia drivers (r526.98), and some games, such as the latest Need for Speed from Electronic Arts I think, can already output HDR10+ to compatible displays. It might only work when switching to HDR is done through the NVAPI though, I have not looked into it.

"HDR10+ Gaming" uses "Source Side Tone Mapping" based on dynamic scene data - this is practically the same as using the new HDR to HDR tone mapping mode in JRVR. Actual metadata passthrough to enable "Sink Side Tone Mapping" is not supported in any (public) API, neither from Microsoft or NVIDIA. Not that anyone I have ever spoken to could find. MS has a stub of an API with no documentation that just takes a binary blob, and according to MS engineers its not implemented at all.