INTERACT FORUM

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 value than 1,000nits and will confirm if I observe the same here. That’s good news!

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.

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.

Just one minor note: restoring the settings of MC28 caused the program to crash again. So for anyone in the same situation, don't restore settings, only media.

At last I got MC 32 running.

I figured that maybe rinsing the entire J River map would solve things (the Media Center 28 map along with the Cache, Lock and Settings folders) would solve things, and it did. Yes, it deleted all data, but I got that backed up.

Thanks for all the support.

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.

Reserved

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.

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.

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?

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

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 imaging how helpful it would be with lower nits displays, for example projectors or even older OLEDs with less than 600-800nits. 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.

I'm just getting done fixing everything. It's taken me 9 hours to fix and I'm not even sure if it worked. I fixed everything once and then backed up in JRiver, shut down JRiver, reopened it, and all the playlists were deleted again. I had to refix everything a second time which took me four hours. Please help

I speed read all of the above and didn't catch this being mentioned...

The work you're doing on these playlists... Is it being carried out on an MC client by any chance?

The only work I do on my playlists is in JRemote and JRiver MC 32.