More > JRiver Media Center 32 for Windows
JRVR issues with HDR Passthrough [All these fixed with build 55]
Manni:
--- Quote from: SamuriHL on June 01, 2024, 05:30:15 pm ---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
--- End quote ---
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:
--- Quote from: Manni on June 01, 2024, 05:38:09 pm ---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.
--- End quote ---
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:
--- Quote from: Hendrik on June 02, 2024, 02:55:40 am ---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.
--- End quote ---
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:
--- Quote from: Manni on June 02, 2024, 05:46:42 am ---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).
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version