Print

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

[Manni]

Hi there,

Thanks to @SamuriHL, I recently found a way to get HDR to HDR tonemapping to work with JRVR and besides the issue that had prevented it from working until now, I also found a few other issues with HDR passthrough, so I thought I'd report them all in one post. All my testing was done with the latest version of MC 32 at the time of posting this (build 49).

1) The biggest one is that HDR to HDR tonemapping in JRVR doesn't work if you don't first enable the OS HDR before starting playback with JRiver. I think Hendrik might already be aware of that bug, so please confirm if that's the case. It would be nice to resolve this quickly, because in the meantime we have to manually switch between SDR and HDR at OS level to get a correct picture in both SDR and HDR, especially when using a Rec-709 3D LUT, as the LUT is (correctly) disabled in HDR. If you don't enable HDR at the OS level, JRVR doesn't send the metadata to the display, so you can't disable the display tonemapping and let JRVR handle all the tonemapping. I see that JRVR is supposed to send SDR content as BT2020/PQ when HDR is enabled, but it looks like gamma is wrong when I do this.

[EDIT: Adding screenshots of settings and VRROOM OSD info below to help debugging]

a) Settings with OS HDR disabled (HDR metadata: CORRECT - no HDR reported as expected as the desktop is in SDR):
https://mega.nz/file/lisA1BpC#XtGiH_jFiFCIAqP-tATzfJtZvejmyuhXBX6Uzt6FjY0

b) Playback of a HDR10 file with OS HDR Disabled before playback: HDR metadata: INCORRECT - empty HDR metadata instead of the HDR to HDR peak nits target (1,000nits) or even the original metadata (1,000nits also).
https://mega.nz/file/p3E2wQaD#EBQAlLDUEdS91sl9MLXoelnAgOBNZyFpR6kI1U9vkIg

If I then simply enable OS HDR before playback (only change), I get these settings:

c) Settings with OS HDR enabled (HDR metadata: CORRECT - Empty HDR metadata as JRVR or Windows doesn't send any info for the desktop itself):
https://mega.nz/file/hqlGzYwS#BhcIdAGXiRnlHcui8YodJ6p31-WyipKPhoq_yyCwFr8

And if I then play the same HDR10 file:

d) Playback of the same HDR10 file with OS HDR enabled before playback: HDR metadata: CORRECT - HDR to HDR peak nits target (1,000nits), as expected
https://mega.nz/file/k6FHHaSC#V3onUtDnnYb1B--uCcC81YfMpioTkl1JJFQnVGJao_M

2) While there is an HDR10+ option in the JRVR HDR settings and while HDR10+ metadata is detected, JRVR only partially interprets the HDR10+ metadata. For example, if you play this HDR10+ test clip made by Florian Hoech (https://ff.de/hdr10plus-metadata-test/), JRVR correctly adjusts brightness according to the metadata, but doesn't react to the contrast metadata. It's better than the Oppo 203, which doesn't react to any HDR10+ metadata, and it's different from the Dune, that reacts to both metadata but raises brightness instead of lowering it. Ideally, my understanding is that in that clip, the HDR10+ metadata should 1) play the content normally then 2) increase the contrast then 3) decrease the brightness. Please take a look and validate. It might be necessary to check with Florian and ascertain what the correct behaviour should be, but in any case there should be some change in the contrast metadata section (it's very visible on the Dune) and there is none with JRVR, which only reacts to the brightness data. There is no bug with HDR10+ in JRVR, the contrast change in the test file simply isn't as noticeable when using a target peak of 1,000nits as it is with the Dune. When using a lower target (I tried when tonemapping both to SDR and to HDR witha target peak of 260nits), the contrast change is visible for both contrast and brightness metadata when playing the HDR10+ test file, so no issue there.

3) DV Metadata is not detected when playing a DV title ripped to BD Folder, whether you use full menus or title playback. It only works with a DV file. Unless there is a technical reason for this, please could you correct this so that we get the DV metadata with BD Folders as well? [EDIT: Not a bug. JRVR currently doesn't support disc-based DV (level 7) in folders, it only supports file based level 5 and 8.x. See #4 below for details on profile 7 DV support in remuxes.]

4) Not a bug but a suggestion, there doesn't seem to be any option in the JRVR HDR settings to enable/disable DV metadata processing, unlike with HDR10+ data. Given that, as far as I know, JRVR is unable to process the FEL, it migh be a good idea to provide an option to enable/disable DV metadata processing, so that if JRVR doesn't process correctly the titles that need the FEL to play correctly due to poor DV mastering, we can fall back to HDR10 instead, as I'd rather have JRVR dynamic HDR to HDR tonemapping all the time than wrong DV processing in these cases (possibly up to a few hundred titles currently) when only the RPU is taken into account instead of FEL+RPU. I wasn't able to test this as I didn't have the time to rip one of my DV discs to file, but unless JRVR only uses the MEL and never takes the RPU into account when discarding the FEL, it will cause issues in some titles, for example brightness fluctuations in the opening sequence of Saving Private Ryan or one frame red flashes in the opening credits of Halloween (there are many others, but these two are easy to test and VERY visible, I spotted them right away without looking for them when testing LLDV with the Dune). [EDIT: confirmed with Saving Private Ryan that Level 7 DV titles are NOT played back correctly when the FEL is required to interpret the RPU in poorly mastered DV titles. In that case, the DV metadata makes it WORSE than simply using the HDR10 base layer. So an option to disable DV processing when the RPU requires the FEL would definitely improve results for these titles.] [EDIT2: This will be fixed in a future build, only MEL titles will be supported in profile 7 remuxes from disc, DV will be disabled when a FEL is present to avoid these issues].

5) JRVR with HDR passthrough drops frames depending on the nVidia driver. I've already reported this and discussed this with Hendrik in another thread. This happens with the latest nVidia driver, it happened at some point in the past, was resolved, then started again. I had to go back to 546.65 to get HDR passthrough to play without frame drops. Whenever this happens with JRVR, it either doesn't happen with madVR, or it can be resolved by playing with the fine-tuning rendering settings available in madVR (CPU/GPU queues, frames presented in advance, etc). In the other thread (in the MC31 forum), Hendrik said that he was thinking of offering more settings to potentially address this if I remember correctly, any progress in this area? Although it's not directly a JRVR issue as it's caused by the driver and a temporary workaround can be to go back to the last known working driver, this isn't a long term solution. I see that quite a few people are posting about frame drop issues in HDR passthrough with JRVR, both here and in other forums, so it's not just my rig.

Not a bug but praise: the HDR to HDR tonemapping works great and really helps on my display (peak 1,000nits) with high nits content, especially demo material such as the 10,000nits demo clips in the S&M UHD Bluray test discs. With such a high nits peak in my TV, it helps less often with real content as most content is mastered to 1,000nits, but I'm sure it still helps in the brightest titles. I need to do more testing, but at least with the S&M 10,000nits demo material (even the 2,000nits HDR10 version) the difference is significant, so if bug #1 and #2 could be resolved, it would definitely be my prefered way to watch HDR content on my display. I can imagine how helpful it would be with lower nits displays, for example projectors or even older OLEDs with less than 600-800nits, though in that case HDR to SDR might be a better option. Given that JRVR has, unlike madVR, also resolved in MC32 all the brightness stability issues that I reported in MC31, it's a great option to have, so thanks for all the good work!

Thanks for listening and taking the above into consideration or providing info if I got anything wrong. I'll post back some more info when I've had a chance to do more testing with DV files or if I find anything else as I do more testing.

[Manni]

Reserved

[Hendrik]

1) The biggest one is that HDR to HDR tonemapping in JRVR doesn't work if you don't first enable the OS HDR before starting playback with JRiver. I think Hendrik might already be aware of that bug, so please confirm if that's the case, it would be nice to resolve this quickly, because in the meantime we have to manually switch between SDR and HDR at OS level to get a correct picture in both SDR and HDR, especially when using a 3D LUT, as the LUT is disabled in HDR. If you don't enable HDR at the OS level, JRVR doesn't send the metadata to the display, so you can't disable the display tonemapping and let JRVR handle all the tonemapping.

I'm not able to observe this behavior, nor does the code suggest that it is possible - there is no fundamental difference between plain pass-through, and HDR to HDR tonemapping, all it really does is override the metadata values before they are send, and of course adjust the image accordingly. There is only one spot where metadata is being generated and send to the GPU, and the HDR-to-HDR peak configuration just overrides the value present there (assuming its actually lower then the videos, we are never increasing it)

I have actually tested this just now with my HDfury to observe the metadata, starting from a SDR desktop, with HDR to HDR tonemapping setup to 270 nits just to have a unique value, and after playback start and letting the values refresh, the HDMI metadata reads 270 nits as expected.

When testing, do note that Windows only applies metadata when the video player is in fullscreen.

2) While there is an HDR10+ option in the JRVR HDR settings and while HDR10+ metadata is detected, JRVR only partially interprets the HDR10+ metadata. For example, if you play this HDR10+ test clip made by Florian Hoech (https://ff.de/hdr10plus-metadata-test/), JRVR correctly adjusts brightness according to the metadata, but doesn't react to the contrast metadata. It's better than the Oppo, which doesn't react to any HDR10+ metadata, and it's different from the Dune, that reacts to both metadata but raises brightness instead of lowering it. Ideally, my understanding is that in that clip, the HDR10+ metadata should 1) play the content normally then 2) increase the contrast then 3) lower the brightness. Please take a look and validate. It might be necessary to test with Florian and ascertain what the correct behaviour should be, but in any case there should be some change in the contrast metadata secton (it's very visible on the Dune) and there is none with JRVR, which only reacts to the brightness data.

This is the level of HDR10+ support that is available at this time. We use per-scene brightness data and tone mapping curves, and even this realistically often behaves worse then just using our own DTM.

3) DV Metadata is not detected when playing a DV title ripped to BD Folder, whether you use full menus or title playback. It only works with a DV file. Unless there is a technical reason for this, please could you correct this so that we get the DV metadata with BD Folders?

Blu-ray DV is not supported at this time.
Which falls into the next question as well - FEL only ever exists on Blu-ray. The DV support is designed for Profile 5 and Profile 8.x, not Blu-ray Profile 7. We should probably disable this if the RPU requests an EL to be present.

[Manni]

Hi Hendrik,

Thanks for the quick and detailed reply, much appreciated.

Re #1, I’m not at my desk now but I’ll re-run some tests as soon as I’m back. I also have a HD Fury in the chain (VRROOM) and that’s how I could identify the issue. You are correct that there is no difference between the two, but the effect isn’t the same. Without the NV OS enabled manually, there is no HDR10 metadata, so I guess the display in that case applies a standard curve (static always in my case) in such situations. When HDR to HDR is enabled, there is still no metadata, so there is no difference in the display behaviour, which means that we now have dual tonemapping: JRVR tonemaps dynamically to whichever value we specify (1,000nits in my case) and then the display applies the same static tonemapping as with no metadata. If you enable the nVidia HDR switch, then the correct metadata is sent (original if HDR to HDR is disabled, specified if HDR to HDR is enabled). This disables the display tonemapping, hence we don’t have dual tonemapping anymore.

I was running these tests at 119/120p in RGB 10 bits to stay within FRL5 limits at all frame rates (as that’s the limit of the VRROOM and my Denon AVR), so you might want to test this as it might impact on how to reproduce. If you still can’t, I’ll take screenshots of the settings and of my VRROOM OSD when I’m back at my desk and we can try to identify why the behaviour is different. I run all my tests in full screen, so that’s not the reason.

Re #2, I’m with you on this, I just thought you might want to know. I have no problem believing the JRVR dynamic tonemapping is better than using HDR10+ metadata, as is the case with madVR vs HDR10+ on the JVC, so I’ll just disable HDR10+ processing.

Re #3, thanks for confirming that DV processing is only supported with files and that FEL isn’t. Yes, FEL is only present on disc DV, and disabling DV / falling back to HDR10 if the RPU requests a FEL to be present is definitely preferable to avoid artifacts with poorly mastered DV titles that make DV worse than HDR10 when the FEL isn’t available. I wish the Dune would do this. I have started a rip of Saving Private Ryan to mkv while I’m away, I’ll test the behaviour with JRVR and I’ll let you know if anything needs to be done or not.

You’re not replying re #5, so I assume there is no progress. I hope this will be fixed at some point or that we’ll have more flexibility with settings to try to address this if these frame drops in HDR Passthrough if that’s not something you can reproduce and fix.

Thanks again and well done for all the improvements in MC32.

[Hendrik]

I had a look at the HDR10+ test sample provided above, and I experience a change in image in all cases. According to the description, segments with ignored metadata should remain the same, while interpreted metadata result in change.

I can clearly see the contrast/saturation increase in the "contrast" section, and the brightness decrease in the brightness section, as seemingly is intended.
It appears the "contrast" section does this adjustment using the tone mapping curve, which is supported by JRVR.

I have been testing with HDR to SDR tone mapping however, which means a far stronger tonemap then HDR to HDR would do.

[Manni]

I had a look at the HDR10+ test sample provided above, and I experience a change in image in all cases. According to the description, segments with ignored metadata should remain the same, while interpreted metadata result in change.

I can clearly see the contrast/saturation increase in the "contrast" section, and the brightness decrease in the brightness section, as seemingly is intended.
It appears the "contrast" section does this adjustment using the tone mapping curve, which is supported by JRVR.

I have been testing with HDR to SDR tone mapping however, which means a far stronger tonemap then HDR to HDR would do.

Thanks, that makes sense. For some reason the contrast change is much more visible on the Dune. I’ll test again with a lower target peak value than 1,000nits and will confirm if I observe the same here. That’s good news!

[Manni]

I have actually tested this just now with my HDfury to observe the metadata, starting from a SDR desktop, with HDR to HDR tonemapping setup to 270 nits just to have a unique value, and after playback start and letting the values refresh, the HDMI metadata reads 270 nits as expected.

I can confirm that with a lower target peak (I tried with 260nits on my laptop) I can reproduce the above, so there is no issue with HDR10+ processing in JRVR. I've updated the title and the first post to reflect this. I had to restart the ripping of one of my DV titles to mkv, so I'll post more about this later. About to test HDR metadata with the HTPC, will post screenshots soon.

[Manni]

@Hendrik

I've added screenshots of my settings and of the VRROOM OSD in the first post to help debugging the need to enable OS HDR here in order to get the correct HDR metadata sent to the display. I should have used a non-1,000nits title, or changed my target peak in HDR to HDR to something else than 1,000nits to make this clearer to the non initiated, but as you'll see it doesn't change the fact that the correct HDR metadata is only sent by JRVR (not only here, @SamiruHL has the same issue, he might post later to confirm) if the OS HDR is enabled manually BEFORE starting playback.

I hope this will help you to reproduce the issue.

[Hendrik]

Like I said above, I can't reproduce that at all. I have a HDfury Arcana, which doesn't add a OSD ontop of the video, but rather has its own tiny screen with the metadata, and it reports accurate values in all scenarios (although I have to manually refresh the data display using its button, which brings me to the next part). Are you certain it refreshes properly in all scenarios? One thing that happens is that there is several mode changes in quick succession here - even more if you use refresh rate changing. First it sets the refresh rate, then it enables HDR, and then it sends the metadata. There is no method in Windows to set all the changes in one go, you can only set them step by step.

If the VRROOM has a button to swap data display pages or refresh the data, maybe worth cycling it to see if its just not showing the latest, like my Arcana does?
I imagine there might be similar software on these devices, just with different connectivity exposed and other features hooked up.

Ultimately, all we do is give the data to Windows. It is responsible for sending it out.

The more important question - if you play a high nits video, can you actually observe the TV still acting undesireable?

[Manni]

Like I said above, I can't reproduce that at all. I have a HDfury Arcana, which doesn't add a OSD ontop of the video, but rather has its own tiny screen with the metadata, and it reports accurate values in all scenarios (although I have to manually refresh the data display using its button, which brings me the next part). Are you certain it refreshes properly in all scenarios? One thing that happens is that there is several mode changes in quick succession here - even more if you use refresh rate changing. First it sets the refresh rate, then it enables HDR, and then it sends the metadata. There is no method in Windows to set all the changes in one go, you can only set them step by step.

Ultimately, all we do is give the data to Windows. It is responsible for sending it out.

The more important question - if you play a high nits video, can you actually observe the TV still acting undesireable?

Any HD Fury device (with 4K120 support in my case) should report this correctly, whether on the actual device as on the Arcana or on the device OSD as in my screenshots. I have almost all of them since the Integral, including the Arcana, as I'm a beta tester for HD Fury. I'll double check that the VRROOM itself displays the correct info, in case it's a bug in the VRROOM, but I doubt it as SamuriHL experiences the same issue as I do. I'm 100% certain that it refreshes properly, I refresh it every time manually.

It might be caused by the refresh rate change. I use the JRiver refresh rate change due to some issues with the madVR one that we've already discussed.

Please could you use custom refresh rate to display 23.976 at 119 and 24.00 at 120 and test again? I'm quite sure that this happens also when switching to the native refresh rate, but I haven't checked that. I'll check along with the VRROOM metadata info and I'll confirm.

It's hard to say if this can cause issues on the content, as it all depends on what the display does when a title gives it empty HDR metadata. Depending on the actual metadata and the actual content, I can imagine situations where this would be worse. For example, if you have content with maxCLL up to 10,000nits (Mad Max Fury Road or S&M Demo material) but send empty metadata, the display my tonemap whatever it gets as if it was 4,000nits, which could darken the picture if JRVR has already tonemapped it to 1,000nits. I haven't done tests because I only managed to get HDR to HDR to work properly yesterday evening and I wanted to report these issues ASAP. Hopefully others will confirm they experience the same issue. AFAIK SamuriHL also has a VRROOM, so I'll double check that first. If the VRROOM reports the wrong info in the OSD (Which I believe I'd have noticed earlier unless it's very specific to this situation), I'll hook up the Arcana to confirm if I get the same results as you do or not.

Of course if it's a VRROOM bug then there is no impact on the content

I'm on windows 11 Pro x64, latest build, with the nVidia drivers I mentioned in post#1, in case that's another possible difference. I noticed the absence of HDR metadata when using JRVR HDR passthrough with all the drivers I've used, whether using HDR to HDR tonemapping or not.

[Manni]

Blu-ray DV is not supported at this time.
Which falls into the next question as well - FEL only ever exists on Blu-ray. The DV support is designed for Profile 5 and Profile 8.x, not Blu-ray Profile 7. We should probably disable this if the RPU requests an EL to be present.

I have tested DV support in JRVR with Saving Private Ryan (level 7 title, ripped directly from the original UK disc with the latest makemkv) that Level 7 DV titles are NOT played back correctly by JRVR when the FEL is required to interpret the RPU in poorly mastered DV titles. In that case, the DV metadata makes it WORSE than simply using the HDR10 base layer.

To test for this if you have Saving Private Ryan on 4K UHD bluray, simply play the opening sequence in the Omaha Beach cemetary. As soon as the old guy is leaving the trees with the bright sky in the background, you should see very visible brightness fluctuations. This is JRVR using RPU information without the FEL, which is necessary to interpret RPU with poorly mastered DV titles.

Another good test for this is the Halloween (original one) opening credits. Around the director's credit (John Carpenter), you should see flashes of red frames. Also wrong RPU info that can't be used without FEL.

So disabling the DV metadata when RPU requires the FEL would definitely improve results for these titles. I've updated post 1 accordingly.

Note that this is an issue with disc-based DV for all players that don't have full MEL+FEL level support, including hardware mediaplayers such as the Dune. The only exceptions are hardware BD Players (Oppo 203, Sony) because they have full MEL+FEL level 7 support, and hardware mediaplayers based on the Amlogic S922X-J chipset such as the Ugoos AM6B+, as they have the required hardware to decode both layers. There might also be an experimental player that does this on Windows. Anyway, you're not alone to have this issue with up to a few hundred titles, so if you could disable the use of DV metadata when playing such titles, it would be great.

What I don't understand it why DV processing is active when playing level 7 disc-based rips, when you said earlier that level 7 wasn't supported? If it's not supported, we should get only the HDR10 base layer, and there wouldn't be any issue with the titles (like Saving Private Ryan or the original Halloween) that need the FEL to interpret the RPU correctly.

Question: Does JRVR use the DV metadata to improve on its own dynamic tonemapping, or does the DV metadata replace JRVR's tonemapping? Does JRVR behave differently depending on the mode (HDR to SDR, HDR passthrough, HDR to HDR)? It might be good to provide an option to enable/disable DV metadata in order to give more flexibility. Personally, with JRVR doing dynamic HDR to DHR tonemapping, I'd rather disable DV processing if it replaces JRVR (as with HDR10+) instead of supplementing it.

[Hendrik]

What I don't understand it why DV processing is active when playing level 7 disc-based rips, when you said earlier that level 7 wasn't supported? If it's not supported, we should get only HDR10, and there wouldn't be any issue with the titles that need FEL to interpret the RPU correctly.

Because the DV data doesn't actually communicate its level directly. It just says "do this to the image", and the levels are more of a marketing thing / a set of features. But I've added a check to disable processing if an Enhancement Layer is present, which should effectively disable Profile 7 entirely.
Of course this only worked in the first place if you remuxed a BD into MKV or something, because it then moved the DV data into the main video track, similar to how Profile 5 or 8 are setup, rather then a separate track on the actual Blu-ray, where its not seen unless you go specifically looking.

Question: Does JRVR use the DV metadata to improve on its own dynamic tonemapping, or does the DV metadata replace JRVR's tonemapping? Does JRVR behave differently depending on the mode (HDR to SDR, HDR passthrough, HDR to HDR)? It might be good to provide an option to enable/disable DV metadata in order to give more flexibility. Personally, with JRVR doing dynamic HDR to DHR tonemapping, I'd rather disable DV processing if it replaces JRVR (as with HDR10+) instead of supplementing it.

We don't use the DV tonemapping features, only the image transformation features (which is of most importance for Profile 5, which is otherwise unwatchable, but also results in an improved image with Profile 8 ). As long as its working properly, there should be no reason to want to turn it off.
The EL would fall into the same category - make a better HDR10 image (or would we call it HDR12 since it usually adds bitdepth?), but processing it is not supported yet.

This way it also benefits you when doing full pass-through, as it applies the DV improvements and creates an improved HDR10 image. (Why the HDR10 image wasn't just like this from the start, you ask? Partly compression advantages, partly to make DV sell more)

[Manni]

Because the DV data doesn't actually communicate its level directly. It just says "do this to the image", and the levels are more of a marketing thing / a set of features. But I've added a check to disable processing if an Enhancement Layer is present, which should effectively disable Level 7 entirely.
Of course this only worked in the first place if you remuxed a BD into MKV or something, because it then moved the DV data into the main video track, similar to how Profile 5 or 8 are setup, rather the separate track on the actual Blu-ray, where its not seen unless you go specifically looking.

Thanks for the explanation. Yes, that's what I did to test for the implementation in JRVR, as I don't have any of these issues with BD folders given that DV isn't enabled for these.

There are many users playing mkv DV files from disc rips with JRVR and being very happy with it. I'm sure it works fine with the majority of DV titles ripped from disc (especially MEL titles, but also FEL titles mastered properly, where the RPU can be used without the FEL). This is why I suggested an option: some users might prefer to have DV enabled all the time and have the issue with the up to a couple hundred titles that actually need the FEL. Others would prefer it to disable DV processing for FEL titles so that they don't get DV processing  if it's not supported properly. So it might be wise to provide an option, or even a few DV-related options, if you don't want to face pitchforks For example, you could have a global DV processing option (as you have for HDR10+) so users could decide if they want DV or not at all, and then a sub option re how to handle FEL titles: DV on or DV off for these. That kind of granularity would make JRVR better than the vast majority of players unable to handle FEL DV properly. Note that personally, I don't care as I use BD folders, so will not get DV at all and I don't mind as I'm happy with JRVR dynamic HDR to HDR tonemapping.

You haven't replied to the question at the end of my previous post. How does DV processing work when it's active in JRVR (whether it should or shouldn't be)? Does it supplement or replace JRVR's dynamic tonemapping? Does it work differently in HDR to SDR and HDR to HDR? [EDIT: I see you've edited your post above and have partially answered this, thanks]. By the way, I don't think using the 12bit info in the EL really matters until we have native 12-bit panels. Otherwise, bit-depth needs to be downscaled to 10 again by the panel. What's the point of that?

[Hendrik]

There is no difference to DV processing depending on the target output. First all DV transformations are applied resulting in an (improved) HDR10 image, only then it is processed further (or not in case of pass-through). Tonemapping is not impacted by it at all. We don't even get the per-scene brightness data from DV right now to supplement the DTM (instead we do our own measurements as with all content), although I plan to add that in a future update, it just takes some work to pass the data from the source through the decoder to the renderer and requires a bunch of components to line up, including external ones.

[Manni]

There is no difference to DV processing depending on the target output. First all DV transformations are applied resulting in an (improved) HDR10 image, only then it is processed further (or not in case of pass-through). Tonemapping is not impacted by it at all. We don't even get the per-scene brightness data from DV right now to supplement the DTM (instead we do our own measurements as with all content), although I plan to add that in a future update, it just takes some work to pass the data from the source through the decoder to the renderer and requires a bunch of components to line up, including external ones.

Thanks a lot for the detailed explanation, much appreciated.

One thing I forgot to mention in the first post that might help explain the difference some of us experience between manually enabling OS HDR before playback and leaving it disabled, and possibly the dropped frames issue in HDR passthrough:

- When OS HDR is disabled before playback, if you look at the vSync info in the JRVR OSD it jumps all over the place. I don't think it reflects the actual vsync rate, as there is no more or less frames dropped or repeated, but it moves up and down like crazy. This never happens with madVR.

- When OS HDR is enabled before playback, the vSync info in the OSD is rock steady, as it should be: 119.880hz when playing 23p content at 119p.

Can you reproduce this behaviour, and does it help to understand what might be wrong for some users and not others? Could it be different depending on the processing/rendering path/hardware acceleration options etc?

I'll do the tests with the VRROOM as soon as I can, but I have to do *some* work today in between the testing

[Hendrik]

One thing I forgot to mention in the first post that might help explain the difference some of us experience between manually enabling OS HDR before playback and leaving it disabled, and possibly the dropped frames issue in HDR passthrough:

- When OS HDR is disabled before playback, if you look at the vSync info in the JRVR OSD it jumps all over the place. I don't think it reflects the actual vsync rate, as there is no more or less frames dropped or repeated, but it moves up and down like crazy. This never happens with madVR.

- When OS HDR is enabled before playback, the vSync info in the OSD is rock steady, as it should be: 119.880hz when playing 23p content at 119p.

Can you reproduce this behaviour, and does it help to understand what might be wrong for some users and not others? Could it be different depending on the processing/rendering path/hardware acceleration options etc?

I have actually been observing this no matter how I start playback or if I even play HDR at all. But it hasn't been causing any apparent playback issues as far as I can tell. It used to be perfectly stable, I wonder if something in the driver or Windows changed.
I'm working on a new presentation mode that may impact this, we will see.

[Manni]

I have actually been observing this no matter how I start playback or if I even play HDR at all. But it hasn't been causing any apparent playback issues as far as I can tell. It used to be perfectly stable, I wonder if something in the driver or Windows changed.
I'm working on a new presentation mode that may impact this, we will see.

Thanks, it's must have been a coincidence then. I agree that I haven't seen any detrimental impact of this weird fluctuation on playback, as reported earlier.

One suggestion, it would be great if you could provide in the JRVR OSD the peak target when doing HDR to HDR tonemapping, so that we can see the difference with HDR passthrough, as currently I don't think there is any. The original peak is reported for the input as HDR 10 peak, but there is no information reported the tonemapped peak. Maybe report "HDR to HDR (peak)" instead of "HDR Passthrough" when HDR to HDR tonemapping is enabled? Because technically, it's not passthrough if you tonemapped HDR to HDR, that's one of the reasons (along with the empty HDR metadata) why I thought HDR to HDR wasn't working.

I can't see any difference in the OSD at the moment that would help clarify the active mode (HDR passthrough vs HDR to HDR) at a glance.

Reporting the 3D LUT on the OSD (if active) as already discussed would also be helpful, but I'm aware that you don't have much room available in the OSD in SDR.

[SamuriHL]

Ok, interesting.  I think Manni you're on to something here about the refresh rate change causing the issue.  If I set my display to 120 and turn OFF custom refresh rate options in MC, I do indeed get metadata passed without having to enable the OS nonsense first.  IF, however, I have the refresh rate option in MC set to on, I lose all metadata unless I enable OS HDR before playback.  So I don't know if that can be improved but that's what's happening there.

Hendrick, while we're on the topic of DV and profile 7.  Any chance you could eventually include an option to convert it to profile 8 on the fly.  Kodi now has that option built in and it's useful for some people. I think for the purposes of using the DV data here it MIGHT be useful?  But I'm with Manni, please don't just shut it off for profile 7.  I definitely see improvement in MEL titles for sure.  An option would be nice.

[danbez]

" I definitely see improvement in MEL titles for sure.  An option would be nice."

Interesting - are you sure this is not placebo effect? I can't claim I know all details on how JRVR/Libplacebo handles DV, but MEL titles have an empty 2nd layer, leaving only the RPU data to be consumed as an improvement to the base HDR. However, Hendrik confirmed that scene-based DV metadata is not consumed yet. What is left for P7? Only peak brightness info? (For Profile 5, we know that it can properly consume ICtCp which is better than YcBrCr).

I actually like what Hendrik suggested - detect the presence of a 2nd layer and turn off DV. Is this available in the latest build? I have been using "vf=format:dolbyvision=no" with MPV to ignore DV on anything but Profile 5 ATM.

Also excited to hear you have plans to support DV scene based tonemapping. This would be interesting. But what would be really cool is if you could pull "a trick out of the hat" and add FEL support as well... I don't care about FEL titles that fixes brightness (because JRVR can do the same with its own tonemapping), but I care about titles with poorly authored Base layer and huge FEL layer to fix the problems. Paramount, Kino Lorber, some titles from Studio Canal seem to be the main offenders here.

[Hendrik]

I definitely see improvement in MEL titles for sure.

I made it so that it's only turned off for FEL titles, since on MEL the enhancement layer is all zeros anyway.
If there is any noticeable improvement is arguable, but the image reshaping instructions are used regardless, which can change on a per-scene basis, we only don't use any of the tone mapping instructions in the further DV levels.

[SamuriHL]

Perfect, thanks for that.  It seems helpful to me.  Whether it's placebo or not, it's definitely not harming anything by having it.

[Manni]

Ok, interesting.  I think Manni you're on to something here about the refresh rate change causing the issue.  If I set my display to 120 and turn OFF custom refresh rate options in MC, I do indeed get metadata passed without having to enable the OS nonsense first.  IF, however, I have the refresh rate option in MC set to on, I lose all metadata unless I enable OS HDR before playback.  So I don't know if that can be improved but that's what's happening there.

Hendrick, while we're on the topic of DV and profile 7.  Any chance you could eventually include an option to convert it to profile 8 on the fly.  Kodi now has that option built in and it's useful for some people. I think for the purposes of using the DV data here it MIGHT be useful?  But I'm with Manni, please don't just shut it off for profile 7.  I definitely see improvement in MEL titles for sure.  An option would be nice.

Thanks for confirming that you're also experiencing this and that refresh rate change might be involved.

I'm still testing and trying to find a way to 100% reproduce the issue. Please can you check in your VRROOM OSD settings and report what your "ignore metadata change" box is set to? If it's checked (enabled), can you disable it and report if you see any difference in behaviour re displaying the HDR metadata info?

What is your default refresh rate in Windows (and/or the one specified in JRVR if you use custom)?

[SamuriHL]

Thanks for confirming that you're also experiencing this and that refresh rate change might be involved.

I'm still testing and trying to find a way to 100% reproduce the issue. Please can you check in your VRROOM OSD settings and report what your "ignore metadata change" box is set to? If it's checked (enabled), can you disable it and report if you see any difference in behaviour re displaying the HDR metadata info?

What is your default refresh rate in Windows (and/or the one specified in JRVR if you use custom)?

I can 100% reproduce it like I told you.  My PC is set to 120Hz 2160 res.  If I enable Display settings automatic change mode: on set to 23.976 for (most) UHD's, then I lose metadata.  Unchecking the ignore metadata change made no difference and I knew it wouldn't because I manually refresh my VRROOM (note I'm not using the OSD.  I have that OFF completely.  I am using the web interface which I ALWAYS have up on my laptop.)  Refreshing after the HDR signal settles down still shows that the metadata is missing.

EDIT:

And turning OFF the display settings automatic change mode gives me metadata every time.  Without having to enable the OS HDR mode.  So yes, the refresh rate changing is 100% causing this problem, at least for me.

[Manni]

Okay, I've done more testing re bug #1 (HDR metadata) and I can confirm the following:
1) There is definitely a link with auto refresh rate switching in JRiver display settings. I never have the issue with auto refresh rate disabled. The issue only arises when it's set to on (standard/native rates) or custom (I use 119/120 as appropriate, with a defaut at 119.
2) The issue can happen even if there is no need to switch, for example the current rate is 119 and you play a 23p title.
3) Whether the correct metadata is displayed or not doesn't seem to affect the HDR to HDR tonemaping (it's still active and the picture changes if you change the target), but there might be unwanted double tonemapping as the display tonemapping might stilll be active with empty metadata.
4) This empty metadata issue hapens with HDR passthrough and HDR to HDR. It's obviously more of an issue with HDR passthrough if it trigger the wrong curve in the display.
5) This doesn't seem to be a VRROOM issue but I never use the device itself to display HDR metadata.
6) Not related but I've done some tests and I confirm that enabling HDR10+ processing frequently produces worse results than leaving it disabled, for example with the S&M demo content. I therefore recommend to leave it disabled as JRVR DTM does a significantly better job, at least with a 1,000nits peak target for HDR to HDR.

[Manni]

I can 100% reproduce it like I told you.  My PC is set to 120Hz 2160 res.  If I enable Display settings automatic change mode: on set to 23.976 for (most) UHD's, then I lose metadata.  Unchecking the ignore metadata change made no difference and I knew it wouldn't because I manually refresh my VRROOM (note I'm not using the OSD.  I have that OFF completely.  I am using the web interface which I ALWAYS have up on my laptop.)  Refreshing after the HDR signal settles down still shows that the metadata is missing.

EDIT:

And turning OFF the display settings automatic change mode gives me metadata every time.  Without having to enable the OS HDR mode.  So yes, the refresh rate changing is 100% causing this problem, at least for me.

It looks like we posted at the same time. I also refresh the OSD using the web interface or the remote/IP control. We're in agreement, I just wanted to make sure that a rogue option wouldn't make testing more unpredictable.

[SamuriHL]

2) Yup, I noticed that, as well.  Doesn't matter if it needs to change, if the option is enabled, it messes with the metadata
3) For my LG, it will indeed trigger the wrong curve.  If I remember correctly, HDR sent with no metadata will trigger a 4000 nit curve by default.  Which is not great.
6) Interesting...I'll have to check some of my HDR10+ titles and see if that holds true outside of demo material.

It looks like we posted at the same time. I also refresh the OSD using the web interface or the remote/IP control. We're in agreement, I just wanted to make sure that a rogue option wouldn't nake testing more unpredictable.

Understood.

[Hendrik]

What happens if you set a delay for the resolution change to complete? (Settings -> Video -> Display Settings on Custom, and set Wait after change)

[Manni]

What happens if you set a delay for the resolution change to complete? (Settings -> Video -> Display Settings on Custom, and set Wait after change)

I already have a 3s delay. I increased it from 1sec (which was already working fine). I'll try the maximum delay and will report back. If it helps, I'll try to bring it down to the minimum that works reliably,

[SamuriHL]

Well I'll be damned.  That works.  I set it for 2 seconds (had it set to 0.5 already) and sure enough I now have metadata.  I suspect 1 second would work fine.

EDIT: 1 second works for me, as well.  Not sure why it's not working for you, Manni but this solves all my issues now.  Huzzah!

[Manni]

Well I'll be damned.  That works.  I set it for 2 seconds (had it set to 0.5 already) and sure enough I now have metadata.  I suspect 1 second would work fine.

EDIT: 1 second works for me, as well.  Not sure why it's not working for you, Manni but this solves all my issues now.  Huzzah!

Can you try ten times? It might be a lucky strike. As I wrote above, I was already using a 3sec delay (that I had increased from my normal 1s) to see if it would help yesterday. It didn’t. I tried 15s and 60s, still no metadata on Pacific Rim. I’m using folders and full menus, while you use mkv files, so it might make a difference. Make sure that auto refresh is set to on or auto and not left to off from a previous test…

[Manni]

Wait, I’m getting metadata on the main title, let me try a few times with various values. I haven’t checked but there might be no metadata on the menu files.

[SamuriHL]

Can you try ten times? It might be a lucky strike. As I wrote above, I was already using a 3sec delay (that I had increased from my normal 1s) to see if it would help yesterday. It didn’t. I tried 15s and 60s, still no metadata on Pacific Rim. I’m using folders and full menus, while you use mkv files, so it might make a difference. Make sure that auto refresh is set to on or auto and not left to off from a previous test…

Trust me, I had everything set correctly and it works.  I did it multiple times.  I'm watching a movie now on another device so no more testing tonight but I can certainly try with a folder or ISO easy enough tomorrow.  But it's definitely working for me now.  I went from 120 desktop to 23.976 and it worked fine.  Multiple times.

[Manni]

Trust me, I had everything set correctly and it works.  I did it multiple times.  I'm watching a movie now on another device so no more testing tonight but I can certainly try with a folder or ISO easy enough tomorrow.  But it's definitely working for me now.  I went from 120 desktop to 23.976 and it worked fine.  Multiple times.

No worries, I trust you, just checking.

I checked and as I thought the menu should get metadata (it’s displaying it now). I’ve had no metadata with 5 seconds, it looks like I might need at least ten to get more reliable results, but it still failed with 15 and 60, so clearly not the entire solution with bd folders.

[SamuriHL]

No worries, I trust you, just checking.

I checked and as I thought the menu should get metadata (it’s displaying it now). I’ve had no metadata with 5 seconds, it looks like I might need at least ten to get more reliable results, but it still failed with 15 and 60, so clearly not the entire solution with bd folders.

I'll check on folders tomorrow with my LG and see if it's display dependent or something with MC.

[Manni]

I'll check on folders tomorrow with my LG and see if it's display dependent or something with MC.

Thanks, but it's something else here (3090 HTPC to Denon X8500HA AVR to VRROOM to Samsung S90C).

I disabled BD menus, and whether I play BD folder with title playback or simple mkv or mp4 titles, I still get no metadata with a 15 sec delay.

Anyway, I'm glad it's solved for you

[SamuriHL]

Thanks, but it's something else here (3090 HTPC to Denon X8500HA AVR to VRROOM to Samsung S90C).

I disabled BD menus, and whether I play BD folder with title playback or simple mkv or mp4 titles, I still get no metadata with a 1 sec delay.

Anyway, I'm glad it's solved for you

Man that sucks.  Yea I'm super pleased it's working for me now.  That makes it much easier to use in my case.

[Manni]

Man that sucks.  Yea I'm super pleased it's working for me now.  That makes it much easier to use in my case.

I corrected a typo in my post, it was even with 15 secs, not even with 1sec. Maybe it will be different with your LG, please let us know tomorrow.

[SamuriHL]

I corrected a typo in my post, it was even with 15 secs, not even with 1sec. Maybe it will be different with your LG, please let us know tomorrow.

I paused my movie for a brief moment just to try it cause I really wanted to know.  The Crow folder backup I did yesterday:

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: 842 / 0.005 nits
MaxCLL/FALL: 300 / 0 nits


That's on the menu.  It's working perfectly for me in all scenarios.

[Manni]

I paused my movie for a brief moment just to try it cause I really wanted to know.  The Crow folder backup I did yesterday:

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: 842 / 0.005 nits
MaxCLL/FALL: 300 / 0 nits


That's on the menu.  It's working perfectly for me in all scenarios.

Thanks. No idea why it doesn’t help here.

[Hendrik]

To be clear, if you either don't change refresh rate, or HDR is already enabled beforehand, it 100% works for you?

I have been looking into enabling HDR earlier if the video is actually flagged HDR in the Media Center library (because that would be before we even open the file to check, Library is all we got), to avoid some issues with breaking HDMI audio streams for some people. Maybe doing HDR before refresh rate would help. Or in fact sort of "at the same time" (although not really, Windows display mode changes are stupid and don't let you combine settings).

[Manni]

To be clear, if you either don't change refresh rate, or HDR is already enabled beforehand, it 100% works for you?

I have been looking into enabling HDR earlier if the video is actually flagged HDR in the Media Center library (because that would be before we even open the file to check, Library is all we got), to avoid some issues with breaking HDMI audio streams for some people. Maybe doing HDR before refresh rate would help. Or in fact sort of "at the same time" (although not really, Windows display mode changes are stupid and don't let you combine settings).

Sorry for the late reply, I was busy most of the day and wanted to do some tests before replying.

1) Disabling the refresh rate change doesn't always help. Even with it off, I frequently get no metadata with JRVR.
2) Enabling OS HDR manually always help. I never get empty metadata if I do that before playback.
3) This never happens with madVR. madVR always sends the correct metadata in HDR passthrough, irrespective of the OS HDR state.
4) Although it might help others, I don't use the JRiver database as I only use MC as an external player for CMC (and that's not going to change as there are too many limitations when using the JRiver front end for my use), so unfortunately not an option or a solution for me. Ideally you want to figure out what's wrong and resolve it for the player.

So currently the only workaround for me remains to switch OS HDR on manually, which really isn't usable as I frequently switch between SDR and HDR content.

[SamuriHL]

Hendrick, I really think trying an order change to see if that helps.  I.E. HDR on first, then mess with the refresh rate.  I have a feeling it could change the equation.

[Manni]

Hendrick, I really think trying an order change to see if that helps.  I.E. HDR on first, then mess with the refresh rate.  I have a feeling it could change the equation.

As explained above, this might help others but it won't help me as this relies on getting the HDR flag from the JRiver database, which I don't use.

However, hang on, I decided that I should try rebooting my PC in case something was hosed and it looks like it might be working now. I need to rerun the tests.

Which driver version are you on, and on wich OS?

[Manni]

Nope, it was a fluke. Still only working relialy for me if OS HDR is enabled manually beforehand.

[SamuriHL]

546.65 like you (I just reverted a couple days ago based on the doom9 thread).  Windows 11 which just updated itself to 24h2 but I doubt anything's changed with that.

[Manni]

546.65 like you (I just reverted a couple days ago based on the doom9 thread).  Windows 11 which just updated itself to 24h2 but I doubt anything's changed with that.

Thanks, that's what I thought, I just wanted to check there was no difference there.

@Hendrik, I checked the new feature in the last build that is supposed to output SDR content as BT2020 / PQ if the OS HDR is enabled, as it could be a workaround if it allowed me to play all content with the OS HDR enabled. Unfortunately, it doesn't seem to be working properly, gamma with SDR content is all washed out. Are you using a fixed 2.2 or something like that? Also I gue it wouldn't work with my SDR 3D LUT, but gamma is wrong with the LUT enabled or disabled.

[Manni]

546.65 like you (I just reverted a couple days ago based on the doom9 thread).  Windows 11 which just updated itself to 24h2 but I doubt anything's changed with that.

Quick question: When you change the refresh rate delay in the settings, does it do anything visibly (apart from solving the metadata issue)? Here there is no difference at all whether the delay is 0.5s or 15s. Is that normal?

@Hendrik: One more thing I noticed, if you enable OS HDR manually before playback, the HDR metadat is always correct, but if you enable HDR to HDR tonemapping back and forth, instead of switching between the original metadata (passthrough) and the HDR to HDR metadata (peak target) you get empty metadata again. Can you reproduce this? If so, this might help you to locate the part of the code that sends empty metadata, because that should never be the case.