More > JRiver Media Center 32 for Windows
JRVR issues with HDR Passthrough [All these fixed with build 55]
Manni:
--- Quote from: Hendrik on May 31, 2024, 04:29:17 am ---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.
--- End quote ---
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.
Hendrik:
--- Quote from: Manni on May 31, 2024, 09:13:12 am ---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.
--- End quote ---
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.
--- Quote from: Manni on May 31, 2024, 09:13:12 am ---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.
--- End quote ---
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)
Manni:
--- Quote from: Hendrik on May 31, 2024, 09:19:13 am ---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.
--- End quote ---
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? :)
Hendrik:
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.
Manni:
--- Quote from: Hendrik on May 31, 2024, 09:46:03 am ---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.
--- End quote ---
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 :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version