More > JRiver Media Center 32 for Windows

JRVR issues with HDR Passthrough [All these fixed with build 55]

(1/27) > >>

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) [EDIT: it was in fact the last stable, build 47, not the latest, build 49, but that doesn't change anything in the issues reported below, it's only the reason why the SDR to BT2020/PQ feature when OS HDR is enabled didn't work, as mentioned later in the discussion.]

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: this SDR to HDR issue is because I was using build 47. This works fine with build 49]. [EDIT 03-jun-24: This HDR metadat issue is resolved for some by setting the delay in the Autorefresh rate video options in MC to 1 or above. Unfortunately, this doesn't help here and I still have to enable OS HDR before playback to get the correct metadata.] [EDIT: This issue is fully resolved with build 55. Unfortunately, there are still issues with older GPUs].

[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 Friedrich (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]. [EDIT3: this is fixed from build 55]

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.

6) MC breaks HDMI audio when switching to HDR. This seems to happen to some users with an AVR in the chain (Denon reported). Should be fixed in upcoming build with the option to switch to HDR earlier. [EDIT: seems fixed from build 55].

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. [EDIT: all the issues reported above are fixed from build 55 with a 4xxx GPU (tested with 4080 super] THANKS!

Manni:
Reserved

Hendrik:

--- Quote from: Manni on May 31, 2024, 04:00:35 am ---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.

--- End quote ---

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.


--- Quote from: Manni on May 31, 2024, 04:00:35 am ---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.

--- End quote ---

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.


--- Quote from: Manni on May 31, 2024, 04:00:35 am ---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?

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page