Print

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

[Manni]

My desktop is 120 10 bit rgb in the nVidia cp

JRiver:
Display Settings automatic change mode: Custom
Wait after change (use if display changes slowly): 1 second
FILM (23.976): 3840x2160 - 32 bit @ 119 Hz
FILM( 24): 3840x2160 - 32 bit @ 120 Hz

The rest are set to Desktop Settings

Drat, same as mine, so no idea why it works/blanks for you according to delay and it doesn't for me. Until I get the display to blank according to the delay specified, I don't think there is any point in going further.

Can you share any options you've changed in video settings or JRVR settings that might cause this difference? Are you using bitstreaming for audio? I do, maybe it does something when playback starts that causes this.

[SamuriHL]

Drat, same as mine, so no idea why it works/blanks for you according to delay and it doesn't for me. Until I get the display to blank according to the delay specified, I don't think there is any point in going further.

Can you share any options you've changed in video settings or JRVR settings that might cause this difference? Are you using bitstreaming for audio? I do, maybe it does something when playback starts that causes this.

Nothing really changed.  Yes bitstreaming for sure.  So definitely not the issue there.

[Hendrik]

The Wait only triggers if MC actually changes the refresh rate, of course. And to trigger the refresh rate change, the FPS field in the library needs to be filled appropriately. As I understood it, Manni doesn't use the library, in which case refresh rate changing would not actually work.
The library is an essential part of MC, and we rely on its metadata to be available for some of the advanced features.

[Manni]

The Wait only triggers if MC actually changes the refresh rate, of course. And to trigger the refresh rate change, the FPS field in the library needs to be filled appropriately. As I understood it, Manni doesn't use the library, in which case refresh rate changing would not actually work.
The library is an essential part of MC, and we rely on its metadata to be available for some of the advanced features.

Thanks for this, that would be an explanation for the behaviour I experience. I'm sure SamuriHL can easily confirm this by either using MC as an external player or simply using JRiver to play a file using "open with" if MC isn't the default for that file type. I'll do tests as well as soon as I can to confirm if this is resolved when using MC's library and MC as a front end.

However, I'm afraid the rest is incorrect.

Although I haven't made sure that there was an actual refresh rate change in my latest tests while I was testing solely the delay (I will as soon as I have a chance and I'll confirm), refresh rate change works fine even when MC is called as an external player. Everytime. It also works fine when you play a list of video files in the files section of the library (I have a selection of test files there that I use to test various things). It has worked fine for years, though I've never used the HDR metadata until recently because I was using HDR to SDR tonemapping. And HDR Metadata also works fine if you enable the OS HDR before playback.

I understand that the wait/delay might not be triggered in that case. I will check that by adding a single title in the library, but if so that's just a big bug that should be fixed. Technically, there is nothing that prevents MC from looking at the frame rate info in the file and adjust the refresh rate accordingly (which I believe is what it does anyway) and to add the specified delay when needed.

JRiver MC is one of the best players if not the best player available today, but its library and front end interface is very limited compared to what I achieve with MyMovies/CMC: no WOL to start an offline server when a title isn't available, no lights control (I use Vera lights) to switch the lights off when a film starts and on when a film stops, no network playback with an iOS app to select a title on iOS with a superb front end interface and play it on a Dune or an Oppo, the MC front end interface itself is quite dated (at least on Windows) compared to CMC though I've not looked at it recently, the search feature in the front end is extremenly limited (I have nearly 4,000 titles in my collection and use custom filters and categories, support for TV Series is poor... The list is endless and I don't mind, that's not what I use MC for.

I purchase MC solely for its amazing capabilites as an external player, especially its great full menus feature (by far its unique selling point for me), excellent JRVR renderer (actively maintained and developed), compatibility with madVR 3D LUTs that I've started using etc. For years I've purchased MC without using it (even the master license to pay more when I didn't need one as I never used any non Windows license and only realised recently that it didn't support BD Folders on Mac, so was of no use to me) simply to support your excellent work in LAV, that I've been using for years in combination with madVR even when I wasn't using MC as a player and that you kindly make available to the community for free.

MC as an external player is great, and this has nothing to do with its library. Unless you commit to bridge the gap is has with the other solution I use (which I'm sure will never happen as I assume my use case in a dedicated cinema room is an edge case in your audience), please support it as an external player. Again, it's one of the best if not the best available, and I'm certainly not the only one to use it that way. It's also a documented use, with specific features implemented so it should be supported. In fact it is supported as recently some features were added (not by you but by another developer) following a suggestion I made, for which I'm very grateful.

FYI, MC itself is perfectly capable of not having any issues with HDR Metadata in HDR passthrough, you only have to use madVR. This proves that it has nothing to do with using the library.  As I mentioned, this HDR metadata issue only happens with JRVR, which I've also started using as my primary renderer because it's not only caught up with madVR but in my opinion it's today ahead of madVR for my use (HDR to HDR tonemapping to a 1,000+nits display), in part thanks to the great work you've done in MC32 to resolve the brightness stability issues I reported in MC31 and the significant progress made over the last couple of years in HDR to SDR tonemapping. It's not quite caught up in this last area, but I use HDR to HDR tonemapping currently and JRVR works fine for that use.

If you don't want or are unable to fix this, then please make the "SDR playback as HDR (BT2020 PQ) when OS HDR is enabled" feature introduced in build 49 work properly so that we can leave the OS HDR permanently enabled as a workaround. Currently gamma is wrong when using this new feature: as reported earlier, the picture looks washed out and I assume an SDR 3D LUT can't be used anymore as I understand it's disabled in HDR passthough (as it should be).

Failing a fix or workaround for this, my only option would be to go back to madVR, which I'd rather not do as I prefer JRVR at the moment for my use (mainly because until now I thought it was maintained and supported and that bugs reported were actually fixed). If bugs occuring when MC is used as an external player with JRVR are not fixed, that's a big advantage of JRVR that goes away for me.

End of rant

[Hendrik]

If you don't want or are unable to fix this, then at least make the "SDR playback as HDR (BT2020 PQ) when OS HDR is enabled" feature introduced in build 49 work properly so that we can leave the OS HDR permanently enabled as a workaround. Currently gamma is wrong when using this new feature: as reported earlier, the picture looks washed out and I assume an SDR 3D LUT can't be used anymore as I understand it's disabled in HDR passthough (as it should be).

Do you actually use a version of MC that already has this feature?
The screenshot shown in the first post from your JRVR settings was a too old version of MC before this feature was introduced, so it did not actually include the detected or configured SDR brightness. So if you haven't updated since then, then you wouldn't actually have this feature yet, and instead are letting Windows up-convert the video, which is known to have some issues.

And a SDR 3DLUT cannot be used, because 3DLUTs are designed to compensate for the screen response, so the original video format is much less relevant then the current screen mode - which would be HDR, and as such a SDR 3DLUT cannot be applied.

[Manni]

Do you actually use a version of MC that already has this feature?
The screenshot shown in the first post from your JRVR settings was a too old version of MC before this feature was introduced, so it did not actually include the detected or configured SDR brightness. So if you haven't updated since then, then you wouldn't actually have this feature yet, and instead are letting Windows up-convert the video, which is known to have some issues.

And a SDR 3DLUT cannot be used, because 3DLUTs are designed to compensate for the screen response, so the original video format is much less relevant then the current screen mode - which would be HDR, and as such a SDR 3DLUT cannot be applied.

Thanks, I'll double check. I thought I had installed build 49 also on the HTPC, but if it's not a stable build it might still be on the last stable as I'm on the stable, not latest, so it might be that I only installed 49 manually on my laptop. I'll report back if I was on an older build on the HTPC I'll retest the new feature. Apologie in advance if that's the case. I'll also double check the refresh rate change, as it definitely works when MC is used as an external player.

I understand why the SDR 3D LUT can't work in HDR, that's why even if this new feature works it's only a temporary workaround, not a fix. I wouldn't have moved to JRVR if it didn't support madVR 3D LUTs, especially for SDR calibration.

[Hendrik]

I understand that the wait/delay might not be triggered in that case.

Can you check/confirm that you don't have other settings setup to change refresh rate?
For example if you set Settings -> Tree & View -> Fullscreen -> Resolution, this would apply entirely independent of the video, and also ignore the delay. I would recommend to not set this field, or rather ensure its set to "Desktop Settings" (which translates to "leave it at what it is"), so that the video-specific option can run.

If this one applies first, then the Video -> Display Settings mode doesn't need to change anymore, and also not apply its delay.

[Manni]

Can you check/confirm that you don't have other settings setup to change refresh rate?
For example if you set Settings -> Tree & View -> Fullscreen -> Resolution, this would apply entirely independent of the video, and also ignore the delay. I would recommend to not set this field, or rather ensure its set to "Desktop Settings" (which translates to "leave it at what it is"), so that the video-specific option can run.

If this one applies first, then the Video -> Display Settings mode doesn't need to change anymore, and also not apply its delay.

Thanks, I'll double check that and will report back, but I don;t remember evern touching this. I'll write a recap with an answer to all your questions in your last two posts as soon as I get a  chance to test, which might be in a few hours.

[JimH]

Sidecar files might work.  https://wiki.jriver.com/index.php/Sidecar_Files

[Manni]

Do you actually use a version of MC that already has this feature?

You were correct regarding this, I checked and I was running build 47 (last stable) on the HTPC, not 49. Apologies for that.
I installed 49 and now with OS HDR is enabled before playback, SDR Rec-709 content is played as BT2020 PQ, and it doesn't look washed out. In fact it looks very good, so well done.
I can't use a 3D LUT, but it's an acceptable workaround for me until the issue is fixed, as I can play SDR and HDR content with OS HDR enabled, get correct HDR metadata with HDR passthrough and HDR to HDR tonemapping.

I'll answer your other questions in separate posts after further tests.

[Manni]

Can you check/confirm that you don't have other settings setup to change refresh rate?
For example if you set Settings -> Tree & View -> Fullscreen -> Resolution, this would apply entirely independent of the video, and also ignore the delay. I would recommend to not set this field, or rather ensure its set to "Desktop Settings" (which translates to "leave it at what it is"), so that the video-specific option can run.

If this one applies first, then the Video -> Display Settings mode doesn't need to change anymore, and also not apply its delay.

I can confim that this setting is set to "Desktop Settings".

[Manni]

The Wait only triggers if MC actually changes the refresh rate, of course. And to trigger the refresh rate change, the FPS field in the library needs to be filled appropriately. As I understood it, Manni doesn't use the library, in which case refresh rate changing would not actually work.
The library is an essential part of MC, and we rely on its metadata to be available for some of the advanced features.

I am still confused about this, and as far as I can see the statement above is incorrect.

I double checked and as expected, automatic frame rate change is confirmed to work fine here, as it always has, even when launching MC as an external player from CMC.

To clarify, first re MC's auto refresh rate behaviour:

My desktop default frame rate is 119p, as most of the content I play is 23p.
If I play a 23p, 29p or 59p title, there is no refresh rate change (as expected) and no delay (as expected), content plays correctly at 119p.
If I play a 24p, 30p or 60p title, refresh rate changes automatically to 120p and content plays correctly.
If I play a 25p or 50p title, refresh rate changes automatically to 100p and content plays correctly.

This is exactly as per my custom settings in MC. It has worked since I started using MC to automatically switch refresh rates (although at the time I was using native refresh rates, no 119/120), after I reported a bug in madVR auto refresh rate that would fail with 24p BD folders, as it would select the refresh rate of the first file (often a menu or short file at 50 or 60p) and would not adjust to 24p for the main title.

MC auto refresh rate doesn't have this issue, so works correctly with all titles, even when MC is used as an external player.

This works fine whether the renderer is JRVR or madVR (with madVR auto refresh change disabled).

There is no situation in which the MC auto refresh rate doesn't work for me, whether I use MC to play a single file from a folder by clicking on it, play a file or a title from the MC library, or play a folder using MC as an external player called from CMC. So I still don't understand your statement quoted above, but as far as I can see it's not correct.

Now to explain how we got there, I reported that there was no delay for me when I did my last round of testing, but I think that's because my default rate is 119p and most of the content I played was 23p. So, by design, there was no refresh rate change, hence no delay. This is normal behaviour and precisely the reason why I chose a 119p default refresh rate for the desktop.

If I had inverted this and selected a 120p refresh rate for the desktop, I would get a sync (and a delay) with every title, and I guess that's exactly what SamuriHL experiences.

I tested playing a 24.00p file and in that case I do get a 3 sec delay (my current setting in the MC video options). Again, this is normal behaviour, I'm sorry I didn't think of making sure that a refresh rate change SHOULD happen when I last tested thing.

Up to this point, all correct, and apart from a brain fart on my part, no issue with auto refresh rate or the delay with MC, with library titles or as an external program.

Now where things start to be different here is the behaviour regarding HDR metadata, because I checked and if OS HDR is disabled, I don't get the correct HDR metadata, whether there is a delay / refresh rate change or not.

For example, with my 119p default refresh and OS HDR disabled, I play a 24.00 title, there is a 3s delay, a refresh rate change to 120p and I still get no metadata.

If I play a 23p title, there is no delay, no refresh rate change and no HDR metadata.

If I enable OS HDR before playback, playing the same titles, I get the same results re refresh rate change and delay, but I get the correct HDR metadata.

If I use madVR isntead of JRVR, I get the correct HDR metadata whether OS HDR is enabled before playback or not.

@SamuriHL, please could you change your default refresh rate to 119p instead of 120p and let us know if you still get the correct HDR metadata even if there is no refresh rate change and therefore no delay? Thanks!

[SamuriHL]

Yea I can test in probably 20 or 30 minutes.

[SamuriHL]

Works fine for me.

[Manni]

Works fine for me.

Thank you very much for confirming. So even when there is no frame rate change and no delay, you get the correct HDR metadata when the OS HDR isn't enabled.

Then I'm wondering what has changed for you, given that increasing the delay can't be making any difference.

Have you changed anything else?

Do you get the issue again if you change the delay back to what it was before you increased it (0.5 sec if I remember correctly)?

[SamuriHL]

I don't have any more time for testing tonight.  But up until I changed that setting I had this issue and it was most definitely reproduceable.  But then I've always had the option to change refresh rate enabled since I stopped using madvr.  (And even when I switch back to madvr for, e.g. hdr testing to see how much they've improved it, I keep jriver's refresh rate changing active).  It's entirely possible I didn't have this issue when the refresh rates matched but who realistically keeps their desktop at 23.976, as an example?  It was always set to 60 on the desktop.  So I'm guessing that's why I always saw this problem.  When they match, I doubt the delay makes any difference whatsoever since it's not used but I can't confirm if that was true for me in the past at this point as, like I said, I never had the desktop at 23.976 so refresh rate changing would always happen.

[Manni]

I don't have any more time for testing tonight.  But up until I changed that setting I had this issue and it was most definitely reproduceable.  But then I've always had the option to change refresh rate enabled since I stopped using madvr.  (And even when I switch back to madvr for, e.g. hdr testing to see how much they've improved it, I keep jriver's refresh rate changing active).  It's entirely possible I didn't have this issue when the refresh rates matched but who realistically keeps their desktop at 23.976, as an example?  It was always set to 60 on the desktop.  So I'm guessing that's why I always saw this problem.  When they match, I doubt the delay makes any difference whatsoever since it's not used but I can't confirm if that was true for me in the past at this point as, like I said, I never had the desktop at 23.976 so refresh rate changing would always happen.

I did keep my destop to 23p to limit the number of refresh rate changes, but of course I prefer to have it at 119p as it is now

I'm not saying that you didn't have the issue when the frame rate match, just that it's a good way to test if the delay actually makes a difference or not.

I think it would be interesting to see if you can get the issue back, because for me the delay makes zero difference, and it looks like it shouldn't make a difference either in your case if the issue doesn't come back when there is no refresh rate change, as Hendrik has explained that the delay was ignored when there was no refresh rate change.

[SamuriHL]

I'm watching a movie at the moment as my long weekend is coming to a close.  However, if I get a minute before I go to bed after the movie is done I'll run a quick test and let you know.  Personally at this point I'm keeping the desktop at 120 and with the delay set to 1s everything just works.  But I'll set it to 23.976 as a test and set the delay back to 0.5.  I seriously doubt this will make any difference and I expect it'll just work but we'll know for sure later.

[SamuriHL]

Well that's fun.  It would seem you have some bug fixing to do, Hendrick. 

Here's what I can say.  Desktop set to 23.976.  Set custom res in display settings in MC to 23.976.  Set the delay to 0.5.  It doesn't give me metadata.  Now here's the fun part that's going to drive Hendrick absolutely nuts.    Go set the delay to 1, play it again.  Metadata ensues like I'd expect.  BUT....if I THEN go set it back to 0.5 and play it again, it MIGHT sometimes have metadata.  LOL  The 1s delay always gives me metadata in every scenario I've tested.  But the idea that it's not doing anything with refresh rate when you have it set to custom and they match seems to be slightly untrue.  It may not be explicitly setting the refresh rate (or maybe it is and you don't see it because, well, they are the same) but it's definitely acting as though it's being set.

[Hendrik]

But the idea that it's not doing anything with refresh rate when you have it set to custom and they match seems to be slightly untrue.  It may not be explicitly setting the refresh rate (or maybe it is and you don't see it because, well, they are the same) but it's definitely acting as though it's being set.

All it can do is act on the information Windows gives it. It gets the current mode from Windows and compares it to the configured mode. If Windows lies or rather is confused by 23/24 again, then there is little we can do about that.
But I'm adding some extra logging to tell us what Windows reports exactly.

[Manni]

Well that's fun.  It would seem you have some bug fixing to do, Hendrick. 

Here's what I can say.  Desktop set to 23.976.  Set custom res in display settings in MC to 23.976.  Set the delay to 0.5.  It doesn't give me metadata.  Now here's the fun part that's going to drive Hendrick absolutely nuts.    Go set the delay to 1, play it again.  Metadata ensues like I'd expect.  BUT....if I THEN go set it back to 0.5 and play it again, it MIGHT sometimes have metadata.  LOL  The 1s delay always gives me metadata in every scenario I've tested.  But the idea that it's not doing anything with refresh rate when you have it set to custom and they match seems to be slightly untrue.  It may not be explicitly setting the refresh rate (or maybe it is and you don't see it because, well, they are the same) but it's definitely acting as though it's being set.

Thanks for testing and reporting. It still doesn't explain why the delay fixes it for you and doesn't do anything for me, but hopefully the additional logging will help Hendrik to figure out what's happening.

I'll try with native frame rates when I get a chance (desktop 23p and 23p/24p for 23p/24p), but you might want to try with 119p desktop and 119p/120p custom for 23p/24p, which is what I'm using. There might be a different behaviour if you try to reproduce what I'm actually using.

We should really try to reproduce the same parameters so that our configurations are as close as possible when testing this. It doesn't make sense that the delay works for you and doesn't work for me, we have the same OS, same GPU family, same driver, and it doesn't look like there is anything different in our nVidia or JRiver settings.

[Manni]

All it can do is act on the information Windows gives it. It gets the current mode from Windows and compares it to the configured mode. If Windows lies or rather is confused by 23/24 again, then there is little we can do about that.
But I'm adding some extra logging to tell us what Windows reports exactly.

Thanks, looking forward to testing a new build with the extra logging.

[SamuriHL]

I can't do 119 on my desktop without creating a custom resolution.  I have no desire to do all that just for testing.  My options are 100 and 120.  That's it.

[Manni]

I can't do 119 on my desktop without creating a custom resolution.  I have no desire to do all that just for testing.  My options are 100 and 120.  That's it.

Nah, that's just in the nVidia CP. You can access all the other resolutions in the OS advanced display properties (not only 120, 119 and 100p but also all the native resolutions at 60p and below), so if you select 119p there, you'll get 119p on the desktop. If you use a refresh rate switcher (including MC's), you'll switch to 119p too, and I have no custom res.

In any case, for testing you can just select 120p and play 24p content to get the "no refresh rate change" situation. What matters is that you use 119p or 120p in the desktop as a starting point so that we can figure out if you can reproduce the issue I experience or not.

I'll test behaviour with native refresh rate to try to reproduce your conditions (desktop 60, 23/24 playback) when I get a chance.

[SamuriHL]

I'm nearly certain it won't make any difference in my setup but I'll try at some point today.

[Manni]

I'm nearly certain it won't make any difference in my setup but I'll try at some point today.

Thanks a lot, much appreciated

[Manni]

So I tried with 60p desktop/default, auto-refresh on to native refresh rates (23p/24p) and it makes no difference here:

- no HDR metadata with JRVR with OS HDR disabled before playback.
- HDR metadata correct 100% of the time with JRVR if OS HDR is enabled before playback.
- HDR metadata correct 100% of the time with JRVR, whether OS HDR is enabled or not before playback.

I tried with different delay values for JRVR, from no delay to 10 seconds, and it doesn't make any difference here either.

I doubt it will be different for you when you do the opposite and try 119p/120p, but still interested if you can confirm.

In the meantime, leaving OS HDR enabled all the time is an acceptable workaround as both SDR and HDR work perfectly. In fact it's possibly better because as the desktop is in 119p HDR by default, there is no HDMI sync at all when I play most of the content I usually watch (23p HDR).

The only significant downside is that I lose my 3D LUT for SDR content, but my baseline manual calibration is fairly close already, so it's still watchable.

Looking forward to the new build with the extra logging.

[SamuriHL]

It all just works for me.  119 on desktop, works fine with any delay set for 119 film.  120 on desktop, works fine with 1s delay set for 119 film.  Basically, at this point, it all just works as long as I keep 1s delay when it's changing res.  And if it's not changing res, it simply works with whatever delay set.

[Manni]

It all just works for me.  119 on desktop, works fine with any delay set for 119 film.  120 on desktop, works fine with 1s delay set for 119 film.  Basically, at this point, it all just works as long as I keep 1s delay when it's changing res.  And if it's not changing res, it simply works with whatever delay set.

Thanks for taking the time to test and confirm.

I don't think there is more we can do until we get the build with extra logging. Then hopefully if we do the same tests Hendrik will be able to compare the logs and find what's not working here.

Thanks again for all your help debugging this, much appreciated

[SamuriHL]

Honestly, I'm just glad it's working for me now.  LOL   Seriously, though, we'll check again when the new build is out.

[Hendrik]

It all just works for me.  119 on desktop, works fine with any delay set for 119 film.  120 on desktop, works fine with 1s delay set for 119 film.  Basically, at this point, it all just works as long as I keep 1s delay when it's changing res.  And if it's not changing res, it simply works with whatever delay set.

Thats basically how I experience it as well. I run my desktop on 119 typically, although these days I just leave HDR on as well, to eliminate annoying handshakes, and I also often watch stuff on Netflix, which can't toggle HDR on, so leaving it on ensures I get 4K HDR content there.

I am also adding an option for the next build to toggle HDR during the same process of switching the refresh rate, although I'm not quite happy how that works yet..
But the idea is to have it run sooner, and also allow the delay to occur after, so that the mode is properly finalized before video starts being rendered.

[Manni]

Thats basically how I experience it as well. I run my desktop on 119 typically, although these days I just leave HDR on as well, to eliminate annoying handshakes, and I also often watch stuff on Netflix, which can't toggle HDR on, so leaving it on ensures I get 4K HDR content there.

I am also adding an option for the next build to toggle HDR during the same process of switching the refresh rate, although I'm not quite happy how that works yet..
But the idea is to have it run sooner, and also allow the delay to occur after, so that the mode is properly finalized before video starts being rendered.

Sounds good, thanks.

The absence of annoying handshakes is definitely a great advantage of having the OS in 4K119p HDR, as most of my content is 4K HDR 23p.

The only reason why I keep the OS in SDR (apart from saving power) is to be able to use my SDR 3D LUT with SDR content.

Is there any way you could add a "Never (Force SDR)" option to the "Play SDR as HDR" feature in the JRVR HDR settings so that even when the OS HDR is enabled, playing SDR content would force the OS to switch back to SDR before playback, then switch back to OS HDR after playback, which would allow those of us with an SDR 3D LUT to keep using it?

That way, we could keep OS HDR enabled all the time, and JRVR would simply temporarily switch back to SDR when needed.

This would be a permanent solution for me, because if there is a way to keep my SDR 3D LUT without having the OS permanently in SDR, it would limit the number of HDMI resync.

[Manni]

One more issue to report that might help explain the behaviour and find a fix:

Let's take Mad Max Fury Road as an example (4,000nits peak), with HDR to HDR set with a 1,000nits peak.

Starting with desktop at 119p, custom res in MC set to 119p for native 23p content, so no refresh rate change. I haven't tested at native 23p.

- If I enable OS HDR before playback, I get the correct HDR metadata with HDR to HDR (if I wait long enough after playback starts, sometimes it takes a while). i.e. 1,000nits peak, the target I've specified.
- If I pause the picture, go to the HDR settings in MC, and disable HDR to HDR, JRVR should then send the native HDR metadata (4,000nits), so that the display can tonemap correctly using its internal PQ calibration. Unfortunately, JRVR doesn't, and instead sends no metadata (same issue as if you start playback without enabling OS HDR first). This is definitely incorrect, and there is no refresh rate change involved. So you might want to look at the code and find out why it replaces valid metadata with empty metadata, when it clearly shouldn't.
- If you then try to switch back to HDR to HDR, there is no way to get the correct target HDR metadata (1,000nits), so that the display's internal tonemapping is disabled. It doesn't make any difference here as 1,000nits is the default PQ curve, but it could make a difference in some situations.

@SamuriHL, @Hendrik, can you reproduce this?

[SamuriHL]

It'll be probably 7 or 8 hours from now before I can test. There is a new build out that you should try in the meantime.

[Manni]

It'll be probably 7 or 8 hours from now before I can test. There is a new build out that you should try in the meantime.

Thanks. Re the new build, it might be the case if you're a beta tester, but I'm not so 49 is still the latest available as of now on the forum and when checking for "latest", which is all I have access to.

[Hendrik]

The metadata logic is really not complicated, it just gives the currently relevant metadata to the D3D Output, its never zeroed or otherwise going through complex logic. Its Windows responsibility to select the appropriate metadata to send to the screen, which is typically the current fullscreen window, if any. If no window is in proper fullscreen, then you get no metadata, or rather Windows default metadata if you used Windows HDR calibration.

If you open the settings during playback, you break the fullscreen lock. Maybe something on your system prevents it from recognizing it as proper fullscreen again after. I get real-time metadata changes here when messing with the settings and closing the dialog again.

[Manni]

The metadata logic is really not complicated, it just gives the currently relevant metadata to the D3D Output, its never zeroed or otherwise going through complex logic. Its Windows responsibility to select the appropriate metadata to send to the screen, which is typically the current fullscreen window, if any. If no window is in proper fullscreen, then you get no metadata, or rather Windows default metadata if you used Windows HDR calibration.

If you open the settings during playback, you break the fullscreen lock. Maybe something on your system prevents it from recognizing it as proper fullscreen again after. I get real-time metadata changes here when messing with the settings and closing the dialog again.

Thanks, I'll check and confirm. One more reason to implement hotkeys to select a profile in MC. I never have to open the settings when testing these kind of things with madVR, I just assign a profile to a hotkey to test this on-the-fly.

[Manni]

The metadata logic is really not complicated, it just gives the currently relevant metadata to the D3D Output, its never zeroed or otherwise going through complex logic. Its Windows responsibility to select the appropriate metadata to send to the screen, which is typically the current fullscreen window, if any. If no window is in proper fullscreen, then you get no metadata, or rather Windows default metadata if you used Windows HDR calibration.

If you open the settings during playback, you break the fullscreen lock. Maybe something on your system prevents it from recognizing it as proper fullscreen again after. I get real-time metadata changes here when messing with the settings and closing the dialog again.

I checked and you are half correct (or rather, I'm sure you are entirely correct but it doesn't behave entirely like this here) :

• When I open the video settings or HDR settings, it doesn't break anything. The correct HDR metadata (HDR to HDR target of 1,000nits is still sent, forever).
• When I uncheck "HDR to HDR", that's when it breaks and starts sending no metadata (which I assume, now that you've explained it, is simply the desktop empty metadata as I don't use any Windows HDR calibration).
• When you close the options, it takes a few seconds but then the correct HDR metadata (native, so 4,000nits in my example) is sent, so windows recognizes MC as full screen.
• However, if I then go to options and check the HDR to HDR option again, I never get the correct metadata again (the metadata remains empty/desktop). This is not as much of a problem because JRVR knows the target so doesn't really care about the metadata, but it becomes one if I then disable "HDR ot HDR" again, because the HDR metadata remains empty.

So unlike you, there is no way here to change metadata in real-time, whether in the options (which is to be expected according to your explanation) or once the options are closed, because at some point you get stuck with the empty/windows metadata, even if you get out of the options. Can you actually go from "HDR to HDR" to "HDR passthough" and then back to "HDR to HDR" without getting empty/windows metadata at that point? More importantly, do you ever get the correct native HDR metadata if you disable "HDR to HDR" more than once?

In case you wonder, MC is definitely full screen and the active/foreground app. There is a bug in JRVR (already reported) that means you have to click on the fullscreen video once when you start playback in order to display the OSD with CTRL-J (probably because for some reason, when launched full screen as a player from CMC, MC isn't the active app). But the OSD shows up right away after I leave the options, so MC is definitely the active/foreground app at that time when I go through the steps described above.

[rpro]

I've had the bug with all versions of JRiver with JRVR where I would have no sound if I let JRVR automatically enable/disable HDR. I thought it was a quirk of my system (audio goes to my Denon AVR-X3600H, video goes straight to the LG CX TV). My workaround was to use a program I found on github called AutoHDR - however, it only works on NVIDIA cards, and it also had a bug where it selected the wrong display - I had to fix that.

Anyways, I use Emby Theater as my front-end to launch JRiver as an external player - it would check the name of the file (or the folder if a BDMV) for HDR or DV, and run AUTOHDR_ON.exe /wait to get Windows into HDR before it launches JRiver, and run AUTOHDR_OFF.exe when it is finished. This always worked for me and I would retain my audio.

Now what I found really interesting is that when I got framedrops with JRiver (still an ongoing issue I cannot resolve), I decided to do a clean wipe of JRiver, including delete all the JRiver configuration files (I think in AppData). The sound started working again when I let JRVR switch to HDR. This worked for a while - and then one day it stopped working again. Perhaps the configuration file gets corrupted or gets placed in an inconsistent state.

Unfortunately right now I use MPC-HC with the new MPC Video Renderer. It can convert DolbyVision to HDR10 - not as well as JRiver but I don't get framedrops. I will still use JRiver+MadVR for SDR Blu-rays for the menu support.

[Manni]

I did get that bug too (no audio when switching between SDR and HDR with JRiver) but it wasn't consistent, so I thought it was a glitch, or due to my video chain (I also have a Denon X8500H AVR, as well as a HD Fury VRROOM). I'll add this issue to the list above if I'm not the only one to experience this.

Regarding the frame drops in HDR passthrough, as explained in the first post in point #5, as far as I can see this is caused by a conflict between JRiver and whatever nVidia driver you're using. I reported it a while ago (when I was getting framedrops), then it got fixed by a later nVidia driver, then it got broken again recently... I'm currenty using 546.65 and I have no frame drops in HDR passthrough with JRiver. Did you try it? If you haven't, please try it and report back. Henrick has said in the past that he would try to implement options to try to deal with this (similar to the number of frames in advance etc in madVR, because madVR or MPC-VR don't have the issue), but he hasn't commented on this in this thread.

Regarding the switching between SDR and HDR, three things: 1) did you try to adjust the delay in the auto refresh rate switching in JRiver? This helps some (but not me) when switching from SDR to HDR. 2) If you watch primarily HDR content, setting the OS to HDR and letting JRiver handle SDR as HDR works fine since build 49. 3) Hendrik is planning to add extra logging to a future build and also the enable HDR earlier in the process, so hopefully it will be fixed soon for those not helped by 2.

Right now the workaround of having the OS set to HDR and letting JRiver handle SDR as HDR works fine, though I can't use a 3D LUT for SDR content anymore, so it's not a permanent fix. With 546.65, I don't have any of the other issues.

I hope you'll be able to come back to JRiver soon, MPC-BE with MPCVR is a great player but there are too many missing features for me to consider it, and I also use MC as an external player (though with CMC): no full menus, no 3D LUT calibration, significantly inferior dynamic tonemapping compared to JRVR, etc...

[Hendrik]

The audio issue can be solved by using the forthcoming option to toggle HDR before playback starts. Its otherwise caused by changing the display mode while a HDMI audio stream is already established, which seems to break some audio drivers sometimes.

[Manni]

The audio issue can be solved by using the forthcoming option to toggle HDR before playback starts. Its otherwise caused by changing the display mode while a HDMI audio stream is already established, which seems to break some audio drivers sometimes.

Sounds good!

[SamuriHL]

Oh interesting, so that's not just me.  LOL  Yea, I had that issue, too, and like Manni I assumed it was some stupid issue with the VRROOM and nothing to do with JRiver.  Well, that'll be good to have that solved then. Nice.

[TheShoe]

Oh interesting, so that's not just me.  LOL  Yea, I had that issue, too, and like Manni I assumed it was some stupid issue with the VRROOM and nothing to do with JRiver.  Well, that'll be good to have that solved then. Nice.

It works for me - solved the issue.

A new issue - but do not think it's MC's problem - is that my Marantz about 10% of the time when kicking into HDR will lose the connection.  Changing inputs on the Marantz and then back to my HTPC will resolve it.  I chalk this one up the the darn HDMI handshaking between the various components (LG OLED, Marantz, HTPC/nVidia 4090).  Adding a delay to display mode switching doesn't seem to have any impact on resolving it.
 

[SamuriHL]

That's one of the reasons Manni and I stick an HD Fury device in between everything and the display.  My audio processing is completely outside the video chain.

[Manni]

It works for me - solved the issue.

A new issue - but do not think it's MC's problem - is that my Marantz about 10% of the time when kicking into HDR will lose the connection.  Changing inputs on the Marantz and then back to my HTPC will resolve it.  I chalk this one up the the darn HDMI handshaking between the various components (LG OLED, Marantz, HTPC/nVidia 4090).  Adding a delay to display mode switching doesn't seem to have any impact on resolving it.
 

I assume you're testing the new beta build when you say that "it" solved the issue. Let's hope the rest of us will be able to access it soon.

[TheShoe]

Yes - new beta build.

What HDFury device do you have?

[Manni]

Yes - new beta build.

What HDFury device do you have?

VRRoom, like @SamuriHL. Well, that's what I'm currently using, I'm a beta tester for HD Fury so I also have two other VRRooms and an Arcana, a Maestro, a Vertex, a Linker, an Integral and a few other converters/scalers.

[TheShoe]

So you are splitting the HDMI signal from the PC into separate audio/video output at the VRROOM?  I assume then you feed the video into the TV and the audio into the processor/receiver?

other than access to information about the data being output from the PC, what other advantages is this giving you?

[Manni]

So you are splitting the HDMI signal from the PC into separate audio/video output at the VRROOM?  I assume then you feed the video into the TV and the audio into the processor/receiver?

other than access to information about the data being output from the PC, what other advantages is this giving you?

Maybe @SamuriHL does, but I don't. All sources including the HTPC go to my AVR (HDMI 2.1 in/out Denon X8500H), then to the HDMI 2.1 VRRoom, then to my TV (HDMI 2.1 Samsung 77S90C).

The advantages of having a HD Fury device in the chain for me are too many to list:

• Adding Dolby Vision support using LLDV for all my non-HTPC sources with player-led DV support (Oppo 203 clone, Dune Pro Vision 4K Solo, Apple TV 4K 2021) while the Samsung doesn't support Dolby Vision natively;
• Getting detailed info about what comes in (source output) and out of the VRROOM (to the display) for debugging;
• Spoofing HDR to get the correct metadata and peak brightness when using madTPG as a pattern generator in HDR;
• Downscaling FRL5 from the HTPC to TDMS for my 4K LG Monitor (which is only HDMI 2.0x and is connected to the second output of the VRRoom, which I also use as a splitter);
• Using a 1080p60 EDID with my Humax TN5000 (HDMI 1.4 only) to get sound;
• Adding 3 more HDMI 2.1 inputs that I can use with sources that don't need audio, for example my pGenerator (not that it needs 2.1 but my all my AVR inputs are taken and it has only one HDMI 2.1 in/out, while the VRoom has 4/2+audio only);
• Plus, of course, if your AVR doesn't support the most recent formats, split the video and audio so that you keep the full video signal and send audio only to old AVR...

I'm in the process of writing a review for the Samsung S90C, I explore some of these uses (for example adding DV support to any HDR10 display) if you want to take a look, but it's kind of off topic in this thread: https://www.avsforum.com/threads/2023-samsung-77%E2%80%9D-s90c-4k-qd-oled-review-dolby-vision-support-recommended-settings-calibration-results-tips-and-comparison-with-jvc-nz8-projector.3302053/