INTERACT FORUM
More => Old Versions => JRiver Media Center 32 for Windows => Topic started by: Manni on May 31, 2024, 04:00:35 am
-
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!
-
Reserved
-
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.
-
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.
-
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.
-
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 target peak value than 1,000nits and will confirm if I observe the same here. That’s good news!
-
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.
I can confirm that with a lower target peak (I tried with 260nits on my laptop) I can reproduce the above, so there is no issue with HDR10+ processing in JRVR. I've updated the title and the first post to reflect this. I had to restart the ripping of one of my DV titles to mkv, so I'll post more about this later. About to test HDR metadata with the HTPC, will post screenshots soon.
-
@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.
-
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?
-
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.
-
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.
-
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)
-
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 Level 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 the separate track on the actual Blu-ray, where its not seen unless you go specifically looking.
Thanks for the explanation. Yes, that's what I did to test for the implementation in JRVR, as I don't have any of these issues with BD folders given that DV isn't enabled for these.
There are many users playing mkv DV files from disc rips with JRVR and being very happy with it. I'm sure it works fine with the majority of DV titles ripped from disc (especially MEL titles, but also FEL titles mastered properly, where the RPU can be used without the FEL). This is why I suggested an option: some users might prefer to have DV enabled all the time and have the issue with the up to a couple hundred titles that actually need the FEL. Others would prefer it to disable DV processing for FEL titles so that they don't get DV processing if it's not supported properly. So it might be wise to provide an option, or even a few DV-related options, if you don't want to face pitchforks :) For example, you could have a global DV processing option (as you have for HDR10+) so users could decide if they want DV or not at all, and then a sub option re how to handle FEL titles: DV on or DV off for these. That kind of granularity would make JRVR better than the vast majority of players unable to handle FEL DV properly. Note that personally, I don't care as I use BD folders, so will not get DV at all and I don't mind as I'm happy with JRVR dynamic HDR to HDR tonemapping.
You haven't replied to the question at the end of my previous post. How does DV processing work when it's active in JRVR (whether it should or shouldn't be)? Does it supplement or replace JRVR's dynamic tonemapping? Does it work differently in HDR to SDR and HDR to HDR? [EDIT: I see you've edited your post above and have partially answered this, thanks]. By the way, I don't think using the 12bit info in the EL really matters until we have native 12-bit panels. Otherwise, bit-depth needs to be downscaled to 10 again by the panel. What's the point of that? :)
-
There is no difference to DV processing depending on the target output. First all DV transformations are applied resulting in an (improved) HDR10 image, only then it is processed further (or not in case of pass-through). Tonemapping is not impacted by it at all. We don't even get the per-scene brightness data from DV right now to supplement the DTM (instead we do our own measurements as with all content), although I plan to add that in a future update, it just takes some work to pass the data from the source through the decoder to the renderer and requires a bunch of components to line up, including external ones.
-
There is no difference to DV processing depending on the target output. First all DV transformations are applied resulting in an (improved) HDR10 image, only then it is processed further (or not in case of pass-through). Tonemapping is not impacted by it at all. We don't even get the per-scene brightness data from DV right now to supplement the DTM (instead we do our own measurements as with all content), although I plan to add that in a future update, it just takes some work to pass the data from the source through the decoder to the renderer and requires a bunch of components to line up, including external ones.
Thanks a lot for the detailed explanation, much appreciated.
One thing I forgot to mention in the first post that might help explain the difference some of us experience between manually enabling OS HDR before playback and leaving it disabled, and possibly the dropped frames issue in HDR passthrough:
- When OS HDR is disabled before playback, if you look at the vSync info in the JRVR OSD it jumps all over the place. I don't think it reflects the actual vsync rate, as there is no more or less frames dropped or repeated, but it moves up and down like crazy. This never happens with madVR.
- When OS HDR is enabled before playback, the vSync info in the OSD is rock steady, as it should be: 119.880hz when playing 23p content at 119p.
Can you reproduce this behaviour, and does it help to understand what might be wrong for some users and not others? Could it be different depending on the processing/rendering path/hardware acceleration options etc?
I'll do the tests with the VRROOM as soon as I can, but I have to do *some* work today in between the testing :)
-
One thing I forgot to mention in the first post that might help explain the difference some of us experience between manually enabling OS HDR before playback and leaving it disabled, and possibly the dropped frames issue in HDR passthrough:
- When OS HDR is disabled before playback, if you look at the vSync info in the JRVR OSD it jumps all over the place. I don't think it reflects the actual vsync rate, as there is no more or less frames dropped or repeated, but it moves up and down like crazy. This never happens with madVR.
- When OS HDR is enabled before playback, the vSync info in the OSD is rock steady, as it should be: 119.880hz when playing 23p content at 119p.
Can you reproduce this behaviour, and does it help to understand what might be wrong for some users and not others? Could it be different depending on the processing/rendering path/hardware acceleration options etc?
I have actually been observing this no matter how I start playback or if I even play HDR at all. But it hasn't been causing any apparent playback issues as far as I can tell. It used to be perfectly stable, I wonder if something in the driver or Windows changed.
I'm working on a new presentation mode that may impact this, we will see.
-
I have actually been observing this no matter how I start playback or if I even play HDR at all. But it hasn't been causing any apparent playback issues as far as I can tell. It used to be perfectly stable, I wonder if something in the driver or Windows changed.
I'm working on a new presentation mode that may impact this, we will see.
Thanks, it's must have been a coincidence then. I agree that I haven't seen any detrimental impact of this weird fluctuation on playback, as reported earlier.
One suggestion, it would be great if you could provide in the JRVR OSD the peak target when doing HDR to HDR tonemapping, so that we can see the difference with HDR passthrough, as currently I don't think there is any. The original peak is reported for the input as HDR 10 peak, but there is no information reported the tonemapped peak. Maybe report "HDR to HDR (peak)" instead of "HDR Passthrough" when HDR to HDR tonemapping is enabled? Because technically, it's not passthrough if you tonemapped HDR to HDR, that's one of the reasons (along with the empty HDR metadata) why I thought HDR to HDR wasn't working.
I can't see any difference in the OSD at the moment that would help clarify the active mode (HDR passthrough vs HDR to HDR) at a glance.
Reporting the 3D LUT on the OSD (if active) as already discussed would also be helpful, but I'm aware that you don't have much room available in the OSD in SDR.
-
Ok, interesting. I think Manni you're on to something here about the refresh rate change causing the issue. If I set my display to 120 and turn OFF custom refresh rate options in MC, I do indeed get metadata passed without having to enable the OS nonsense first. IF, however, I have the refresh rate option in MC set to on, I lose all metadata unless I enable OS HDR before playback. So I don't know if that can be improved but that's what's happening there.
Hendrick, while we're on the topic of DV and profile 7. Any chance you could eventually include an option to convert it to profile 8 on the fly. Kodi now has that option built in and it's useful for some people. I think for the purposes of using the DV data here it MIGHT be useful? But I'm with Manni, please don't just shut it off for profile 7. I definitely see improvement in MEL titles for sure. An option would be nice.
-
" I definitely see improvement in MEL titles for sure. An option would be nice."
Interesting - are you sure this is not placebo effect? I can't claim I know all details on how JRVR/Libplacebo handles DV, but MEL titles have an empty 2nd layer, leaving only the RPU data to be consumed as an improvement to the base HDR. However, Hendrik confirmed that scene-based DV metadata is not consumed yet. What is left for P7? Only peak brightness info? (For Profile 5, we know that it can properly consume ICtCp which is better than YcBrCr).
I actually like what Hendrik suggested - detect the presence of a 2nd layer and turn off DV. Is this available in the latest build? I have been using "vf=format:dolbyvision=no" with MPV to ignore DV on anything but Profile 5 ATM.
Also excited to hear you have plans to support DV scene based tonemapping. This would be interesting. But what would be really cool is if you could pull "a trick out of the hat" and add FEL support as well... I don't care about FEL titles that fixes brightness (because JRVR can do the same with its own tonemapping), but I care about titles with poorly authored Base layer and huge FEL layer to fix the problems. Paramount, Kino Lorber, some titles from Studio Canal seem to be the main offenders here.
-
I definitely see improvement in MEL titles for sure.
I made it so that it's only turned off for FEL titles, since on MEL the enhancement layer is all zeros anyway.
If there is any noticeable improvement is arguable, but the image reshaping instructions are used regardless, which can change on a per-scene basis, we only don't use any of the tone mapping instructions in the further DV levels.
-
Perfect, thanks for that. It seems helpful to me. Whether it's placebo or not, it's definitely not harming anything by having it.
-
Ok, interesting. I think Manni you're on to something here about the refresh rate change causing the issue. If I set my display to 120 and turn OFF custom refresh rate options in MC, I do indeed get metadata passed without having to enable the OS nonsense first. IF, however, I have the refresh rate option in MC set to on, I lose all metadata unless I enable OS HDR before playback. So I don't know if that can be improved but that's what's happening there.
Hendrick, while we're on the topic of DV and profile 7. Any chance you could eventually include an option to convert it to profile 8 on the fly. Kodi now has that option built in and it's useful for some people. I think for the purposes of using the DV data here it MIGHT be useful? But I'm with Manni, please don't just shut it off for profile 7. I definitely see improvement in MEL titles for sure. An option would be nice.
Thanks for confirming that you're also experiencing this and that refresh rate change might be involved.
I'm still testing and trying to find a way to 100% reproduce the issue. Please can you check in your VRROOM OSD settings and report what your "ignore metadata change" box is set to? If it's checked (enabled), can you disable it and report if you see any difference in behaviour re displaying the HDR metadata info?
What is your default refresh rate in Windows (and/or the one specified in JRVR if you use custom)?
-
Thanks for confirming that you're also experiencing this and that refresh rate change might be involved.
I'm still testing and trying to find a way to 100% reproduce the issue. Please can you check in your VRROOM OSD settings and report what your "ignore metadata change" box is set to? If it's checked (enabled), can you disable it and report if you see any difference in behaviour re displaying the HDR metadata info?
What is your default refresh rate in Windows (and/or the one specified in JRVR if you use custom)?
I can 100% reproduce it like I told you. My PC is set to 120Hz 2160 res. If I enable Display settings automatic change mode: on set to 23.976 for (most) UHD's, then I lose metadata. Unchecking the ignore metadata change made no difference and I knew it wouldn't because I manually refresh my VRROOM (note I'm not using the OSD. I have that OFF completely. I am using the web interface which I ALWAYS have up on my laptop.) Refreshing after the HDR signal settles down still shows that the metadata is missing.
EDIT:
And turning OFF the display settings automatic change mode gives me metadata every time. Without having to enable the OS HDR mode. So yes, the refresh rate changing is 100% causing this problem, at least for me.
-
Okay, I've done more testing re bug #1 (HDR metadata) and I can confirm the following:
1) There is definitely a link with auto refresh rate switching in JRiver display settings. I never have the issue with auto refresh rate disabled. The issue only arises when it's set to on (standard/native rates) or custom (I use 119/120 as appropriate, with a defaut at 119.
2) The issue can happen even if there is no need to switch, for example the current rate is 119 and you play a 23p title.
3) Whether the correct metadata is displayed or not doesn't seem to affect the HDR to HDR tonemaping (it's still active and the picture changes if you change the target), but there might be unwanted double tonemapping as the display tonemapping might stilll be active with empty metadata.
4) This empty metadata issue hapens with HDR passthrough and HDR to HDR. It's obviously more of an issue with HDR passthrough if it trigger the wrong curve in the display.
5) This doesn't seem to be a VRROOM issue but I never use the device itself to display HDR metadata.
6) Not related but I've done some tests and I confirm that enabling HDR10+ processing frequently produces worse results than leaving it disabled, for example with the S&M demo content. I therefore recommend to leave it disabled as JRVR DTM does a significantly better job, at least with a 1,000nits peak target for HDR to HDR.
-
I can 100% reproduce it like I told you. My PC is set to 120Hz 2160 res. If I enable Display settings automatic change mode: on set to 23.976 for (most) UHD's, then I lose metadata. Unchecking the ignore metadata change made no difference and I knew it wouldn't because I manually refresh my VRROOM (note I'm not using the OSD. I have that OFF completely. I am using the web interface which I ALWAYS have up on my laptop.) Refreshing after the HDR signal settles down still shows that the metadata is missing.
EDIT:
And turning OFF the display settings automatic change mode gives me metadata every time. Without having to enable the OS HDR mode. So yes, the refresh rate changing is 100% causing this problem, at least for me.
It looks like we posted at the same time. I also refresh the OSD using the web interface or the remote/IP control. We're in agreement, I just wanted to make sure that a rogue option wouldn't make testing more unpredictable.
-
2) Yup, I noticed that, as well. Doesn't matter if it needs to change, if the option is enabled, it messes with the metadata
3) For my LG, it will indeed trigger the wrong curve. If I remember correctly, HDR sent with no metadata will trigger a 4000 nit curve by default. Which is not great.
6) Interesting...I'll have to check some of my HDR10+ titles and see if that holds true outside of demo material.
It looks like we posted at the same time. I also refresh the OSD using the web interface or the remote/IP control. We're in agreement, I just wanted to make sure that a rogue option wouldn't nake testing more unpredictable.
Understood.
-
What happens if you set a delay for the resolution change to complete? (Settings -> Video -> Display Settings on Custom, and set Wait after change)
-
What happens if you set a delay for the resolution change to complete? (Settings -> Video -> Display Settings on Custom, and set Wait after change)
I already have a 3s delay. I increased it from 1sec (which was already working fine). I'll try the maximum delay and will report back. If it helps, I'll try to bring it down to the minimum that works reliably,
-
Well I'll be damned. That works. I set it for 2 seconds (had it set to 0.5 already) and sure enough I now have metadata. I suspect 1 second would work fine.
EDIT: 1 second works for me, as well. Not sure why it's not working for you, Manni but this solves all my issues now. Huzzah!
-
Well I'll be damned. That works. I set it for 2 seconds (had it set to 0.5 already) and sure enough I now have metadata. I suspect 1 second would work fine.
EDIT: 1 second works for me, as well. Not sure why it's not working for you, Manni but this solves all my issues now. Huzzah!
Can you try ten times? It might be a lucky strike. As I wrote above, I was already using a 3sec delay (that I had increased from my normal 1s) to see if it would help yesterday. It didn’t. I tried 15s and 60s, still no metadata on Pacific Rim. I’m using folders and full menus, while you use mkv files, so it might make a difference. Make sure that auto refresh is set to on or auto and not left to off from a previous test…
-
Wait, I’m getting metadata on the main title, let me try a few times with various values. I haven’t checked but there might be no metadata on the menu files.
-
Can you try ten times? It might be a lucky strike. As I wrote above, I was already using a 3sec delay (that I had increased from my normal 1s) to see if it would help yesterday. It didn’t. I tried 15s and 60s, still no metadata on Pacific Rim. I’m using folders and full menus, while you use mkv files, so it might make a difference. Make sure that auto refresh is set to on or auto and not left to off from a previous test…
Trust me, I had everything set correctly and it works. I did it multiple times. I'm watching a movie now on another device so no more testing tonight but I can certainly try with a folder or ISO easy enough tomorrow. But it's definitely working for me now. I went from 120 desktop to 23.976 and it worked fine. Multiple times.
-
Trust me, I had everything set correctly and it works. I did it multiple times. I'm watching a movie now on another device so no more testing tonight but I can certainly try with a folder or ISO easy enough tomorrow. But it's definitely working for me now. I went from 120 desktop to 23.976 and it worked fine. Multiple times.
No worries, I trust you, just checking.
I checked and as I thought the menu should get metadata (it’s displaying it now). I’ve had no metadata with 5 seconds, it looks like I might need at least ten to get more reliable results, but it still failed with 15 and 60, so clearly not the entire solution with bd folders.
-
No worries, I trust you, just checking.
I checked and as I thought the menu should get metadata (it’s displaying it now). I’ve had no metadata with 5 seconds, it looks like I might need at least ten to get more reliable results, but it still failed with 15 and 60, so clearly not the entire solution with bd folders.
I'll check on folders tomorrow with my LG and see if it's display dependent or something with MC.
-
I'll check on folders tomorrow with my LG and see if it's display dependent or something with MC.
Thanks, but it's something else here (3090 HTPC to Denon X8500HA AVR to VRROOM to Samsung S90C).
I disabled BD menus, and whether I play BD folder with title playback or simple mkv or mp4 titles, I still get no metadata with a 15 sec delay.
Anyway, I'm glad it's solved for you :)
-
Thanks, but it's something else here (3090 HTPC to Denon X8500HA AVR to VRROOM to Samsung S90C).
I disabled BD menus, and whether I play BD folder with title playback or simple mkv or mp4 titles, I still get no metadata with a 1 sec delay.
Anyway, I'm glad it's solved for you :)
Man that sucks. Yea I'm super pleased it's working for me now. That makes it much easier to use in my case.
-
Man that sucks. Yea I'm super pleased it's working for me now. That makes it much easier to use in my case.
I corrected a typo in my post, it was even with 15 secs, not even with 1sec. Maybe it will be different with your LG, please let us know tomorrow.
-
I corrected a typo in my post, it was even with 15 secs, not even with 1sec. Maybe it will be different with your LG, please let us know tomorrow.
I paused my movie for a brief moment just to try it cause I really wanted to know. The Crow folder backup I did yesterday:
EOTF 2: SMPTE ST 2084 [PQ], MT: DCI-P3 [WO], WP: D65
GRN: 34000, 16000 [0.68, 0.32]
BLU: 13250, 34500 [0.265, 0.69]
RED: 7500, 3000 [0.15, 0.06]
WP: 15635, 16450, [0.3127, 0.329]
Max/Min Lum: 842 / 0.005 nits
MaxCLL/FALL: 300 / 0 nits
That's on the menu. It's working perfectly for me in all scenarios.
-
I paused my movie for a brief moment just to try it cause I really wanted to know. The Crow folder backup I did yesterday:
EOTF 2: SMPTE ST 2084 [PQ], MT: DCI-P3 [WO], WP: D65
GRN: 34000, 16000 [0.68, 0.32]
BLU: 13250, 34500 [0.265, 0.69]
RED: 7500, 3000 [0.15, 0.06]
WP: 15635, 16450, [0.3127, 0.329]
Max/Min Lum: 842 / 0.005 nits
MaxCLL/FALL: 300 / 0 nits
That's on the menu. It's working perfectly for me in all scenarios.
Thanks. No idea why it doesn’t help here.
-
To be clear, if you either don't change refresh rate, or HDR is already enabled beforehand, it 100% works for you?
I have been looking into enabling HDR earlier if the video is actually flagged HDR in the Media Center library (because that would be before we even open the file to check, Library is all we got), to avoid some issues with breaking HDMI audio streams for some people. Maybe doing HDR before refresh rate would help. Or in fact sort of "at the same time" (although not really, Windows display mode changes are stupid and don't let you combine settings).
-
To be clear, if you either don't change refresh rate, or HDR is already enabled beforehand, it 100% works for you?
I have been looking into enabling HDR earlier if the video is actually flagged HDR in the Media Center library (because that would be before we even open the file to check, Library is all we got), to avoid some issues with breaking HDMI audio streams for some people. Maybe doing HDR before refresh rate would help. Or in fact sort of "at the same time" (although not really, Windows display mode changes are stupid and don't let you combine settings).
Sorry for the late reply, I was busy most of the day and wanted to do some tests before replying.
1) Disabling the refresh rate change doesn't always help. Even with it off, I frequently get no metadata with JRVR.
2) Enabling OS HDR manually always help. I never get empty metadata if I do that before playback.
3) This never happens with madVR. madVR always sends the correct metadata in HDR passthrough, irrespective of the OS HDR state.
4) Although it might help others, I don't use the JRiver database as I only use MC as an external player for CMC (and that's not going to change as there are too many limitations when using the JRiver front end for my use), so unfortunately not an option or a solution for me. Ideally you want to figure out what's wrong and resolve it for the player.
So currently the only workaround for me remains to switch OS HDR on manually, which really isn't usable as I frequently switch between SDR and HDR content.
-
Hendrick, I really think trying an order change to see if that helps. I.E. HDR on first, then mess with the refresh rate. I have a feeling it could change the equation.
-
Hendrick, I really think trying an order change to see if that helps. I.E. HDR on first, then mess with the refresh rate. I have a feeling it could change the equation.
As explained above, this might help others but it won't help me as this relies on getting the HDR flag from the JRiver database, which I don't use.
However, hang on, I decided that I should try rebooting my PC in case something was hosed and it looks like it might be working now. I need to rerun the tests.
Which driver version are you on, and on wich OS?
-
Nope, it was a fluke. Still only working relialy for me if OS HDR is enabled manually beforehand.
-
546.65 like you (I just reverted a couple days ago based on the doom9 thread). Windows 11 which just updated itself to 24h2 but I doubt anything's changed with that.
-
546.65 like you (I just reverted a couple days ago based on the doom9 thread). Windows 11 which just updated itself to 24h2 but I doubt anything's changed with that.
Thanks, that's what I thought, I just wanted to check there was no difference there.
@Hendrik, I checked the new feature in the last build that is supposed to output SDR content as BT2020 / PQ if the OS HDR is enabled, as it could be a workaround if it allowed me to play all content with the OS HDR enabled. Unfortunately, it doesn't seem to be working properly, gamma with SDR content is all washed out. Are you using a fixed 2.2 or something like that? Also I gue it wouldn't work with my SDR 3D LUT, but gamma is wrong with the LUT enabled or disabled.
-
546.65 like you (I just reverted a couple days ago based on the doom9 thread). Windows 11 which just updated itself to 24h2 but I doubt anything's changed with that.
Quick question: When you change the refresh rate delay in the settings, does it do anything visibly (apart from solving the metadata issue)? Here there is no difference at all whether the delay is 0.5s or 15s. Is that normal?
@Hendrik: One more thing I noticed, if you enable OS HDR manually before playback, the HDR metadat is always correct, but if you enable HDR to HDR tonemapping back and forth, instead of switching between the original metadata (passthrough) and the HDR to HDR metadata (peak target) you get empty metadata again. Can you reproduce this? If so, this might help you to locate the part of the code that sends empty metadata, because that should never be the case.
-
Quick question: When you change the refresh rate delay in the settings, does it do anything visibly (apart from solving the metadata issue)? Here there is no difference at all whether the delay is 0.5s or 15s. Is that normal?
Yes there's a very visible difference for me. When I initially went from 0.5 to 2, it basically blanks the screen for 2 seconds before activating HDR mode. At least on my G2 that's what it does. 2 is far too long for my taste so I'm happy it works at 1. It does not, however, work at 0.5 for me.
-
Yes there's a very visible difference for me. When I initially went from 0.5 to 2, it basically blanks the screen for 2 seconds before activating HDR mode. At least on my G2 that's what it does. 2 is far too long for my taste so I'm happy it works at 1. It does not, however, work at 0.5 for me.
Thanks, so that’s the first thing I have to resolve, and probably why it doesn’t help in my case. Changing the delay doesn’t make any difference here (no blanking at all, even with 5 or 15 secs). Have you tried with a 119p or 120p default refresh rate, going to 119p or 120p? Maybe you can reproduce what I experience if you mirror this.
Otherwise please tell me what your options are and I’ll try to see what’s different.
-
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
-
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.
-
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.
-
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.
-
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 :)
-
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.
-
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.
-
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.
-
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.
-
Sidecar files might work. https://wiki.jriver.com/index.php/Sidecar_Files
-
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.
-
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".
-
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!
-
Yea I can test in probably 20 or 30 minutes.
-
Works fine for me.
-
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)?
-
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 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.
-
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.
-
Well that's fun. It would seem you have some bug fixing to do, Hendrick. :D
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.
-
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.
-
Well that's fun. It would seem you have some bug fixing to do, Hendrick. :D
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.
-
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.
-
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.
-
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.
-
I'm nearly certain it won't make any difference in my setup but I'll try at some point today.
-
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 :)
-
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.
-
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.
-
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 :)
-
Honestly, I'm just glad it's working for me now. LOL :D Seriously, though, we'll check again when the new build is out.
-
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.
-
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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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...
-
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.
-
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! :)
-
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.
-
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.
-
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.
-
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.
-
Yes - new beta build.
What HDFury device do you have?
-
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.
-
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?
-
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/
-
Yes, I absolutely do split them. All my devices are connected to the VRROOM. My receiver is 2.0a and doesn't support eARC. So that's connected through HDMI out on the VRROOM and no video is passed to it. Audio to the display is muted so it's only receiving a pure video signal. This setup works extremely well for me.
-
Thanks both. Interesting and something to research.
-
Just to say that I tested the latest nVidia studio driver 565.99 and if doesn't seem to drop frames with HDR passthrough, so it might be an option for some.
Unfortunately, my long Atmos freezes/drops are back with that branch, irrespective of the frame rate, so I'm back with 546.65. No frame drops in HDR passthrough, and only occasional micro audio drop (usually at most one per film, if any), as long as I'm in 4K119 (I haven't tested at 4K23 with 546.65).
It's annoying, but far less of an issue than the 3-5 seconds long freezes/drops that I get with more recent (and older) drivers, where the picture freezes for like 150-250 frames, I have no sound for that duration, then trhe picture catches up and I get the sound back. One is a slight annoyance, the other a dealbreaker.
I really wish that nVidia could get rid of this issue once and for all.
-
Saves me the time to test it myself. :) I'm sticking to the same driver for the moment until a new game requires a newer one.
-
Saves me the time to test it myself. :) I'm sticking to the same driver for the moment until a new game requires a newer one.
Do you also have the long Atmos drops? If not, the latest driver might be an option for you. Many people with the same GPU (3090) don't have this issue with Atmos.
-
Oh yes, I have the ATMOS issue with other drivers. it drives me nuts. 3080 on my machine.
-
Oh yes, I have the ATMOS issue with other drivers. it drives me nuts. 3080 on my machine.
Ah, sorry but good to know. Do you also have the micro audio drops (up to one per film) with 546.65?
-
Yup. I tend to get more than one usually 3 or 4 depending on the length of the film. But they are there. Definitely not as bad as the complete dropouts in other drivers.
-
Yup. I tend to get more than one usually 3 or 4 depending on the length of the film. But they are there. Definitely not as bad as the complete dropouts in other drivers.
Good to know that our setup seems similarly afflicted, even if I'd prefer for you not have the issue. Indeed, it means that we can save each other's time! Please let me know if you ever find a way to fully fix it. I'll do the same...
-
Yea definitely. Will do. I'm using my HTPC less and less these days for the reasons we already discussed so it's not as big of an issue anymore. But it would be nice to solve it regardless.
-
Thanks for the new option to enable HDR early.
I've installed build 55, enabled the new option in setings/video/display, and disabled OS HDR.
I'm getting the following results with driver 546.65, playing a 4,000nits title (Pacific Rim) with a 1050nits target for HDR to HDR using BD folders and full menus (my default frame rate is 119p, so there is no refresh rate change) full screen:
- I always get the correct peak of 1050nits for the main title, but I still get empty/desktop metadata on the menu itself on occasions. It might be a VRROOM issue, so let's ignore that.
- It takes a lot longer for the picture to display after the HDMI resync when HDR is enabled, even though playback has started (I can hear the sound). At least 10 seconds, up to a minute. Usually the TV goes past the black screen and to a "can't get signal" screen. I never had this issue before. Note: I get the same long sync time when switching to HDR in the OS manually, so if JRVR is simply doing this automatically this is normal in my setup, but when I use OS HDR it only happens once, it's not before each title so it's less noticeable.
- If I disable the new option in the display settings, I don't get the correct metadata (1050nits) but NV HDR is enabled in a few seconds, as was the case previously.
- Either way, if I switch between HDR passthough and HDR to HDR while playing content using the menus, the correct metadata is still not sent (it should switch between 1050nits and 4,000nits) even after I close the settings. I haven't tried doing this with profiles because there is no way AFAIK to assign a profile to a hotkey.
If I enabled OS HDR before I start playback, the correct metadata is sent (1050nits) right away, as expected. However JRVR still doesn't send the correct metadata when you switch between HDR passthough and HDR to HDR, even after I close the settings.
Anyone getting different results? Does using the new option in display settings also significantly increase your HDMI sync going from SDR to HDR?
Although I'm very grateful for the new option, it's not usable here from a practical point of view, so I'm back to enabling OS HDR permanently, which also has the advantage of not causing any HDMI resync for 23p HDR titles if the default/desktop is set to 4K119p (or 4K23).
I thought about it and I don't think it's possible for JRVR to switch between HDR and SDR when the OS HDR is enabled, so I don't think there is a way for JRVR to bring SDR 3D LUT back when OS HDR is enabled.
As my current display is accurate enough in SDR without a 3D LUT and given that SDR played as HDR works fine since build 49, I'll therefore keep using the workaround of enabling OS HDR all the time.
However, is there a way to correct the wrong metadata that is sent when switching during playback between HDR to HDR and HDR passthrough? Or is this considered an edge use case that doesn't need fixing, as most people (including myself) would not switch between these modes during playback, except for testing the improvements brought by HDR to HDR tonemapping?
-
However, is there a way to correct the wrong metadata that is sent when switching during playback between HDR to HDR and HDR passthrough? Or is this considered an edge use case that doesn't need fixing, as most people (including myself) would not switch between these modes during playback, except for testing the improvements brought by HDR to HDR tonemapping?
JRVR always hands the correct metadata to Windows, if it changes every frame, or once in a settings change. It would be up to Windows to update the metadata send to the display - which it might not do, since HDR metadata like this is designed to be static, not dynamic.
-
JRVR always hands the correct metadata to Windows, if it changes every frame, or once in a settings change. It would be up to Windows to update the metadata send to the display - which it might not do, since HDR metadata like this is designed to be static, not dynamic.
Thanks. I checked and it's the same with madVR, so nothing worse with JRVR. Most likely the OS that doesn't update. I agree that these are not supposed to change.
-
Happy to confirm that 555.99 doesn't drop frames in HDR passthrough (or HDR to HDR). I have also found a couple of workarounds to the Atmos audio dropouts, but as this issue isn't specific to HDR passthrough, I've created a new thread to discuss it: https://yabb.jriver.com/interact/index.php/topic,139110.0.html.
If you experience the Atmos audio dropouts issue with a 3xxx GPU when going through an HDMI 2.1 AVR, please provide data and contribute.
-
I'll update my driver at some point when I get a minute. That's good to know.
-
I'll update my driver at some point when I get a minute. That's good to know.
Make sure you make a system image before you do so. I only had micro Atmos dropout with 546.65, I got the long freezes again with the new driver and wasn’t able to get just the micro drop outs when I reverted to 546.65 (even after a clean install). The new driver has no frame drops in HDR passthrough, but it’s only usable because of the 8bit workaround I mention in the other post.
I could go back to my last system image if I wanted to, so make sure you have one.
-
Maybe I'll just leave it alone for now. LOL
-
Maybe I'll just leave it alone for now. LOL
You could still test the two partial workarounds with 546.65 and report back if you don’t want to try the latest.
-
You could still test the two partial workarounds with 546.65 and report back if you don’t want to try the latest.
I intend to. Just need to find time. This is going to be a very busy summer and time is going to be more limited for HTPC projects than I'd like.
-
I intend to. Just need to find time. This is going to be a very busy summer and time is going to be more limited for HTPC projects than I'd like.
No worries, I understand. Let's discuss in the other thread.
-
Just to say that I've done some testing with the 1080ti and the latest 555.99 driver and the correct metadata is never sent with HDR to HDR, whether the new option in display settings is selected or not, and whether OS ODR is selected or not before playback.
Same with HDR passthrough. The HDR metadata is always empty.
When the new option is enabled, the HDMI sync isn't longer as with the 3090, but it as no effect.
I'll try with the 4080 super tomorrow, let's hope it works otherwise I'll try to revert back to 546.65
-
I've received the 4080 Super and I'm happy to report that HDR metadat works fine with it in all situations. Plus, when OS HDR is disabled before playback, HDMI sync only takes a normal 3-5 secs, as expected, so that's entirely usable in order restore 3D LUT feature with SDR content.
I'll guess I'll set the OS HDR depending on what I'm watching primarily (HDR most of the time and SDR if watching an SDR TV Series or something).
Anyway, this is HDR metadata issue can be considered fully fixed with a recent 4xxx GPU. I assume that what I experience now is what Hendrik was experiencing.
Really weird that some GPUs behave differently in this regard, and can be as bad as the 1080ti, ie no HDR metadata ever.
This, along with the fact that the 1080ti started to display frequent and intermittent sparkles makes me less guilty about getting the 4080 super.
Happy to report that there are no frame drops with HDR passthrough with the 4080 super with the latest 555.99 driver.
Will now test the Atmos dropouts and will report back in the other thread.
[EDIT 22-jun-24: I've edited the first post and title to reflect the fact that all these issues are resolved with a 4xxx GPU]
-
"This, along with the fact that the 1080ti started to display frequent and intermittent sparkles makes me less guilty about getting the 4080 super"
Not exactly what your sparkles look like, but in the distant past, I had sparkles, particularly noticeable in very dark scenes (eg. a lot of blacks). This was cured by setting the driver to limited color vs RGB. Occurred with my 1080ti all the time - first time I noticed it was on my PS4 in games, and then as I was messing around with color settings in the nVidia control panel app, when I tried to set to RGB/Full I would get that effect. Not in every movie. My test to reproduce it was to run the intro to Labyrinth where the CGI owl is flying around the screen during the opening credits. It was very noticeable there.
Assuming we're talking about the same "sparkle" effect ;)
For my 3000 and 4090, it's been a non-issue regardless of the color settings.
-
"This, along with the fact that the 1080ti started to display frequent and intermittent sparkles makes me less guilty about getting the 4080 super"
Not exactly what your sparkles look like, but in the distant past, I had sparkles, particularly noticeable in very dark scenes (eg. a lot of blacks). This was cured by setting the driver to limited color vs RGB. Occurred with my 1080ti all the time - first time I noticed it was on my PS4 in games, and then as I was messing around with color settings in the nVidia control panel app, when I tried to set to RGB/Full I would get that effect. Not in every movie. My test to reproduce it was to run the intro to Labyrinth where the CGI owl is flying around the screen during the opening credits. It was very noticeable there.
Assuming we're talking about the same "sparkle" effect ;)
For my 3000 and 4090, it's been a non-issue regardless of the color settings.
Thanks but I never had that before with any of my GPUs, including the 1080ti. I think it's just getting old and is starting to fail.
What I call sparkles in this case are intermittent full wihite pixels that were there even on the windows desktop, so 100% not video levels related. More visible on dark background, so I could see them easily on the film covers in CMC, before I even launched a title.
In any case, the 4080 is gone and the 3090 is back in the HTPC, four films now without any drop (the last one was a DTS:X one for good measure).
The 1080ti is mostly used as a headless additional GPU in the E-GPU for the Dell XPS 17, so sparkles won't matter there :)
-
Roger that. The problem ultimately is that there are too many links in the chain, and I suspect a lack of real adherence to "standards" - it must be a nightmare for JRiver, Microsoft, vendor X/Y/Z to ensure any consistency and reliability.
video card, AVRs, TVs, quality of HDMI cables (that is a thing!), splitters (in your case), various drivers, OS patch levels, various operating systems, and on and on...
This is why "good enough" or "good enough for government work" is the standard :)
But the nit pickers like you, me, others, and the high standards of a company like JRiver are important - because then "good enough" is darn good, and those willing to go the extra miles can really benefit
-
On behalf of JRiver, thanks TheShoe!
And thanks to manni and SamuriHL and others for their patience in finding solutions and sharing them. It's very rewarding to watch.
-
Roger that. The problem ultimately is that there are too many links in the chain, and I suspect a lack of real adherence to "standards" - it must be a nightmare for JRiver, Microsoft, vendor X/Y/Z to ensure any consistency and reliability.
video card, AVRs, TVs, quality of HDMI cables (that is a thing!), splitters (in your case), various drivers, OS patch levels, various operating systems, and on and on...
This is why "good enough" or "good enough for government work" is the standard :)
But the nit pickers like you, me, others, and the high standards of a company like JRiver are important - because then "good enough" is darn good, and those willing to go the extra miles can really benefit
Agreed that it's a miracle when it works. But even when that happens, it never does for long.
Family still banned from using the network, I just got 3 or 4 micro drops when watching an Atmos film.
I've decided to go back to my Oppo for watching critical 4K blurays with immersive sound (with the added advantage of full FEL profile 7 support with the Oppo, as you know), and only use the HTPC for series and blurays. I don't think we'll ever get perfection, and I barely have any drop outs with bluray and SDR TV series when bitstreaming, and definitely none when not bitstreaming. I use the MyMovies app on iOS as a front end of ther Oppo and the Dune, it's not as nice as CMC but at least I can get reference audio and picture quality.
By the way, for those interested, I've done some chroma tests with both the 4080 and my 3090, and when you don't use the OS HDR 4:4:4 chroma is downscaled behind the renderers back by my Samsung S90C (at least when using 4K100p+ in RGB 10bits with PC mode and game mode disabled to get filmmaker mode and good calibration). I only get 4:4:4 if the OS HDR is enabled, which means that I can't use a 3D LUT anyway for my SDR content.
-
Theshoe, I use supra hdmi cables and never had any problems with it, but that can change? Could buying a new cable be worth trying? and if so what cable do you use?
I use jrvr, hardware accelrated..and video clock set to off and I dont tick on "use the displays hdr" in jrvr. so in osd it says sdr 8 bit.
I usually get 1 to 3 framedrops during a movie and 1 or 3 repeated frames. If I am lucky I only get 2 repeated frames. This could be on the same movie too.
I have tried ticking off videoclock and so and also tick off hdr passthrough...but to no avail.
I understand Manny use complicated setup 3d Lut, which I dont use I do as little change as I can to not create problems for myself. But If I understand correctly, a rtx 4000 series gpu could solve my setup too?
I tend to stay away from hdr stuff as they create more artifacts(especially in difficult tricky motion or very fast motion) and microstutter.
I use local movie files that I have downloaded and try to stay to remux files. (no server too).
( I noticed a new box to tick under display settings; use hdr if available. why is there an option here for hdr? is this jrivers own hdr management instead of using the displays hdr capability? ..ok forget about this question, I tested it out and is was the same as to tick on hdr in jrvr settings.)
-
Toggle hardware acceleration. It sometimes has problems, maybe driver related.
-
Theshoe, I use supra hdmi cables and never had any problems with it, but that can change? Could buying a new cable be worth trying? and if so what cable do you use?
I don't think replacing your cables will solve frame drops.
My point was that poorly made cables can cause visual artifacts. Not sure about frame drops. I've had a few cables in the past that were just junk and replacing them solved the problems I was having at the time. I cut the ends open to see what was inside and it was just really shoddy build quality, I know a little something about this stuff to recognize poor craftsmanship. Since then, I've been using Audio Quest HDMI cables and have never had an issue with playback.
I've been watching a lot of shorter content lately and have not had frame drops I can recall. The last couple movies we didn't have issues either, but the issue seems pretty random, and I know that no two setups are equal here.
-
What kind of artifacts did hdmi fix? was it artifacts due to motion? like around moving objects?(mostly in front of faces/heads or objects in motion)?
And may I ask which one of audioquest cable do you have?, there are many.
https://www.hifiklubben.no/kabler/hdmi-kabel/?brand=AudioQuest
-
I am using a 6 bucks HDMI 2.1 cable for years and have no issue with a permanent 40Gbps (120Hz 10bit full RGB) connection (not 48Gbps as the TV can't handle 12 bit input). Never understood how people can spend so much for snake oil cables.
-
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.
Yeah I've tried many drivers, even went back to an old driver that was suggested - that worked for a while, but after a month or two the framedrops came back.
So to mitigate them (and this worked for several months until recently, on the same driver!), I did some experiments. If I see a framedrop while watching a video (JRVR, 4K video in an MKV from a streaming source, although I've also seen it on regular Blu-ray remuxes), I would do the following until the framedrops went away:
1. Take JRiver out of fullscreen into windowed mode.
2. Right click anywhere in the video's viewport to get a popup menu to appear.
3. Go back to fullscreen.
This had worked for me in the past. It's almost like there is some problem with mouse input coupled with windowed/fullscreen that "resets" something. Perhaps mouse/keyboard input was being polled too fast, or the input polling (or maybe even GUI render of UI elements?) itself took time away from video frame generation, causing stutter? I don't know.
It is odd that this doesn't affect MadVR. I wonder if maybe JRiver is communicating in some way with JRVR, causing latency, that doesn't occur when using MadVR?
I also used Afterburner's frame time/latency OSD to verify the frame stutter - jagged-looking graphs until I do the above. Using MPC-HC and MadVR, they are smooth as butter.
-
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.
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)
Not sure it will help or is relevant, but I recently found out that the correct way to process a DV title when FEL is present and you can't process it is to convert profile 7 to profile 8. This makes it possible to keep the DV metadata in order to help with the tonemapping, instead of discarding everything (including RPU) due to the possible brightness jumps.
Apparently, profile 7 has these flags in the RPU header:
"el_spatial_resampling_filter_flag": true,
"disable_residual_flag": false,
When processing Profile 7 DV without the EL, the RPU should be converted to Profile 8 and this has these flags set opposite in the header:
"el_spatial_resampling_filter_flag": false,
"disable_residual_flag": true,
Not sure it would make any difference now as you don't use the DV dynamic metadata in JRVR anyway, but I just thought I'd let you know as you said that you planned to take it into account in the future.
AFAIK, the above is the way recent media players with the Amlogic 928x chipset (new 8K Dune and Zidoo for example) handle DV titles with FEL, as they can't process the FEL due to the limitations in the DV implementation (even if the hardware would be capable as they have the processing ability to process the two streams concurrently). Of course UGOOs circumvent that with Corelec and handle FEL titles fully.