INTERACT FORUM

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)

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.

I got it back, apparently the window had minimized to 1x1px on my second monitor so I did not see it! I'm using Fedora 40 and have experienced lots of strange window positioning issues in recent gnome updates (46.2).

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.

Awesome, appreciate the follow-up, Thanks!

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.

When MC32 finds out that it's running for the first time on a machine that had a previous version of MC on it, it pulls in the old data and settings into MC32 and updates the settings to the current version. That explains why the failure dump was so short. It doesn't explain what the problem is. We could use some more info. The process hasn't failed in any of our testing and we haven't had any other user report of this.

Are you saying that you had MC32 running after your trick which prevented it from updating on the fly, THEN you restored the MC28 settings to MC28 and it crashed? Or did you restore the MC28 settings to MC32 and that crashed it??

Thanks for the report.

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?

Not seeing it either in Ubuntu 24.04 LTS.

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

What Distro are you running?  I'm not seeing this issue with Gnome 46 on Arch Linux (I'm on 46.2 of both gnome-shell and mutter if that's helpful).  Do you see it on any other windows?