INTERACT FORUM
More => Old Versions => JRiver Media Center 31 for Windows => Topic started by: Hendrik on April 11, 2023, 03:28:20 am
-
Here is more detail on our work for JRVR, in part from improvements made and being made to libplacebo, the rendering library used in JRVR.
New in Media Center 31 Now
- HDR Tonemapping improvements
- Fully re-designed tonemapping pipeline, better detail retention and vastly improved gamut mapping
- New and improved peak detection and dynamic tonemapping
- Support for HDR10+ tonemapping, using dynamic brightness and HDR10+ tonemapping curves (and preliminary/basic support for DV dynamic scene data)
- HDR to HDR tonemapping (especially useful for HDR10+, as there is no metadata passthrough at this time)
- Black Bar cropping, based on the metadata of the new analysis tools
- Automatically crop off (static) black bars, particularly useful for ultra-wide display setups, projectors or 21:9 TVs
- Re-design the aspect ratio settings to make it easier to setup for anamorphic or ultra-wide setups
- More post-processing options
- Built-in sharpening option (probably using Adaptive Sharpen)
- Support for custom shaders (mpv-style GLSL shaders)
Coming Soon
- Platform specific improvements
- Alternate presentation mode for Windows, to improve stability and hardware utilization (hopefully removing glitches on certain hardware)
- Zero-Copy/Native Hardware acceleration on Linux through VA-API (Intel GPUs primarily, but also others supporting VAAPI)
- Enabling Vulkan rendering on Mac through MoltenVK for improved performance and reliability
General Video Improvements Planned
- Cross-Platform improvements
- Local file access on cross-platform library server setups (not strictly video, but the most important here)
- Investigating Blu-ray "Title" playback mode for Linux/Mac
- RPi improvements
- Hardware accelerated video decoding for RPi 3/4
- JRVR profile tuned for the RPi
- Transcoding improvements
- Support for transcoding into HEVC and retaining HDR10 metadata (realtime would require GPU transcoding, software is never fast enough)
- Expanding GPU encoding options on Linux (only NVENC currently supported, minimally Intel GPUs through QSV or VAAPI will be added)
- Investigating HDR -> SDR tonemapping during transcoding (slipped from MC30, might require GPU assistance using the same backend as JRVR, complex topic)
- Explore moving away from fixed transcoding presets to some simple options to combine container choice + video codec preset + audio codec preset.
On transcoding improvements - it would greatly benefit from introducing GPU processing, for scaling, tonemapping, deinterlacing, and all that. However, I have been reluctant to do this for the time being due to stability concerns, as well as keeping it functional on systems without GPU power.
But with video moving as fast as it does, having a GPU to process video for transcoding might become a requirement, or at least required if those features are desired to be used. We'll investigate this topic in the coming months.
-
Great List! Any thoughts on enabling HW Acceleration for other chroma subsampling apart from 4:2:0 (where the GPU HW supports it)?
-
Probably not. The mainstream HW Accel APIs like D3D11 do not support it.
-
Worth the (re)ask as the underlying silicon is so good these days. Even Intel's iGPUs will do 4:2:2 and 4:4:4, nVidia 4:4:4, and no idea on AMD.
-
Well, you hit all the highlights of what's on my wishlist! :) Very kuel. The dynamic tonemapping is definitely high on my wishlist. Being able to set a target nit and have dynamic tonemapping that doesn't blow out the mid-tones (hello, LG) will be a godsend for JRVR. Taking HDR10+ metadata when available and using that to dynamically tonemap to HDR would be awesome, as my LG doesn't do HDR10+. Any Dolby Vision improvements that can be made will be appreciated, as well. Yea....awesome list indeed!
-
On transcoding improvements - it would greatly benefit from introducing GPU processing, for scaling, tonemapping, deinterlacing, and all that. However, I have been reluctant to do this for the time being due to stability concerns, as well as keeping it functional on systems without GPU power.
But with video moving as fast as it does, having a GPU to process video for transcoding might become a requirement, or at least required if those features are desired to be used. We'll investigate this topic in the coming months.
Curious about this from a cross-platform perspective. Obviously on Windows you have nVidia, AMD, and Intel that all support this to varying degrees. I suspect similar on Linux. On Mac, I have a MacBook Pro 16 M2 Max which should have plenty of GPU power for this. Would it target that, as well?
-
We might look into Mac hardware encoding at some point, but its the least supported and explored for the software stack we're using.
-
Yea, fair enough. It's an amazing video editing machine, though which is why I bought it. (Davinci). Would be really awesome to see it get some love at some point but totally get how priorities go.
-
Is calibration considered "done" at this point? And video profiles (per client/library item)?
-
JRVR Profiles are part of the settings, not the library, so they should be per-client. Unless I'm missing some mechanism here that totally eludes me? Or you want them synced?
Making profiles per library item would be up to you, you could just define a field with some specific values, and then have the profiles look at that field. This is not exactly per item settings, but I would assume many share similar characteristics.
If you had anything else in mind, let us know.
As for calibration, calibrating HDR output is still a bit of a weird topic, and we will mostly rely on the entire ecosystem to figure that out a bit more.
Otherwise, we can do ICC and 3DLUT now. Anything else in that area I missed?
The list above is not necessarily exhaustive, and if there are any requests for topics we have worked on in the past, or new ones, they will be considered. I might have forgotten something just now when making the list, so feel free to remind us as well.
-
JRVR Profiles are part of the settings, not the library, so they should be per-client. Unless I'm missing some mechanism here that totally eludes me? Or you want them synced?
Making profiles per library item would be up to you, you could just define a field with some specific values, and then have the profiles look at that field. This is not exactly per item settings, but I would assume many share similar characteristics.
If you had anything else in mind, let us know.
ok I see, it feels a little tricky to manage in that a profile covers all settings as opposed some subset (c.f. madvr profiles) though I guess most (all?) of the jrvr settings are currently really driven by your hardware so should be client only? I'm not using jrvr in anger myself (yet) so my comments are necessarily a bit abstract.
-
ok I see, it feels a little tricky to manage in that a profile covers all settings as opposed some subset
JRVR profiles are actually isolated to the config section they are in, eg. Output has its own profiles. As does Scaling, etc. This should give some flexibility to have profiles for performance (eg. in scaling), as well as profiles related to the display or such in Output.
-
Right ok, I didn't realise that
I think a mechanism to remotely manage configuration would be nice (I mentioned this in the context of using DSP studio on remote zones recently, same thing), perhaps including a way to copy from one to another
-
It's been a while since I've brought this up, and it's never been acknowledged by JRiver before, so I'm not sure if it's just never going to be considered, but since you're working on video, I figure it can't hurt to throw it out there again.
I use a detached display often while working to watch videos, and I'm constantly having to manually adjust the display window size to match the video playing aspect ratio, which just gets old fast.
I would really love it if MC could behave like youtube and windows media center, and force the display window to match the video aspect ratio automatically. if a playlist moves to a different video of a different aspect ratio, the window should adapt to keep the video 'full screen inside the detached display' automatically/dynamically.
Or, if I grab any side of the detached display to resize it, the window should adjust both horizontal and vertical sizes to keep the video 'full screen'.
I hope when you get to the automatic black bar detection work you mentioned above, this is a "simple" change that can also be made.
I can see no good reason to have the detached window be bigger on one side than the video playing, other than any work required to 'fix' the current behavior.
thanks for considering!
-
One more. Now that we can detect Object Based Audio (ATMOS/DTS-X etc), can we have a Tools--> Options--> Audio--> Bitstreaming--> checkbox for just bit streaming these? Long Live videoclock!
-
Decode ATMOS to LPCM + MAT 2.0?? Is that what you said? ;D LOL Yea, actually that would be a useful feature to bitstream only the object based formats.
-
btw what is experimental about 3D LUT support? or what needs to happen to make it not experimental?
-
For me the first priority before all this fancy stuff would be handling of HDR over network (remotes etc). As most new releases are HDR more and more videos requires tonemap/pass through to be playable on the clients. Perhaps team also thinks this way already but thought it doesn't hurt to mention it.
-
There is a bunch of stuff to consider with transcoding HDR playback to other devices. We have a mix of HDR and SDR display devices. I'm not sure what sort of process is needed to determine the capabilities of the target device. I'm guessing that JR's own code (MC Clients, JRemote etc) can work out that native display capabilities, but... how about Web Browsers, DLNA devices etc. Ideally, you would want to know the capabilities of the end renderer and then push a SDR or HDR version.
A small thing (and I know it is on Hendrik's list) is that thumbnails of HDR content are wrong in MC.
-
like this? https://github.com/FoLLgoTT/Warping
mpv-style custom GLSL shaders that we would use are very powerful and you get lots of control. The one above can probably be improved to actually not require the target resolution coded into it, and recently there is also new support for configurable parameters, so it would be relatively easy to create a config page for it, if this is something unique that offers rather specific advantage - for comparably little effort on our side.
fwiw I tried that in mpv and, in about 5mins, I had it quite roughly dialled in. The fiddly bit is the need to edit a text file & restart a test pattern, if it were feasible to do that in near real time (e.g. a dialog overlay with a spinner that moves a value up and down so you can watch the image distort) then that would be really nice. I wonder if, because it's a shader, it would be possible to do this outside of jrvr? something like a little util that is an offshoot of theatre view, which renders an & which has the required controls built in? Certainly that would be v neat/user friendly even if it might be more effort than it's worth.
-
fwiw I tried that in mpv and, in about 5mins, I had it quite roughly dialled in. The fiddly bit is the need to edit a text file & restart a test pattern, if it were feasible to do that in near real time (e.g. a dialog overlay with a spinner that moves a value up and down so you can watch the image distort) then that would be really nice. I wonder if, because it's a shader, it would be possible to do this outside of jrvr? something like a little util that is an offshoot of theatre view, which renders an & which has the required controls built in? Certainly that would be v neat/user friendly even if it might be more effort than it's worth.
We could integrate it into the JRVR settings, which generally apply live (at least when you hit "Apply") and even while video is paused, that would be relatively easy and a whole lot better then config editing already.
Outside of JRVR is not so easy, as the entire shader processing is of course tied to JRVR itself.
-
For me the first priority before all this fancy stuff would be handling of HDR over network (remotes etc). As most new releases are HDR more and more videos requires tonemap/pass through to be playable on the clients. Perhaps team also thinks this way already but thought it doesn't hurt to mention it.
The original post above includes HDR transcoding/streaming with some comments. Its a tricky thing to do in a way thats still realtime fast (might require GPU power, which is a bit more complicated in transcoding then it is for playback). But I understand the need for it with more and more content being HDR. Its definitely something I want to finally do, but it needs to be done right.
-
Remember when you add dynamic tone mapping, I want to still output HDR. :) This is great for the LG's that can set a tone curve. If I can tone map to 880 nits, I'm gonna be happy.
-
We could integrate it into the JRVR settings, which generally apply live (at least when you hit "Apply") and even while video is paused, that would be relatively easy and a whole lot better then config editing already.
that would be great (particularly as it would need to be part of a profile)
would it be possible to add an equivalent MCWS call to Playback/LoadDSPPreset? if so, it means it could be updated easily on the fly from another device
-
The first version is available now and features the re-designed tone mapping pipeline. Any feedback on quality would be appreciated. You can turn on peak detection/dynamic tone mapping in the Advanced section (or load the "Quality" preset), I'll likely move the option back to the Output page later.
-
Any info on what exactly has changed? Is it described in some libplacebo config perhaps?
Do you think custom shader support can be exposed sooner rather than later btw?
-
If you want to read about the major changes, only really the libplacebo changelog is where any information can be found. We are shipping a git master snapshot from yesterday.
gamut mapping: https://code.videolan.org/videolan/libplacebo/-/commit/64099247d799272b9c72997c0fc834426b02ccee
tone mapping: https://code.videolan.org/videolan/libplacebo/-/commit/c378870595d3254490183352057d07359da4d54c
Alas, I couldn't find any good one about the new histogram based peak measurements. And there are more tweaks and improvements all around.
Summary:
- Fancy math to improve gamut mapping (eg. reducing BT.2020 to BT.709), resulting in improved details
- Tone mapping is now done in the IPTQc4 colorspace, which improves the quality (its a derivative of the ICtCp/IPT colorspace specifically tuned for libplacebo, which is designed for image processing)
- Histogram for peak detection, improving the peak and average brightness values, excluding outliers
Some of the other features related to that will need hooking up to settings and providing the necessary metadata, those changes will come over the next builds.
-
Very kuel. I'll give it a try soon. I'm excited!
-
I don't think it's working properly for me on my LG G2. It's not passing any HDR metadata to the display at all.
EOTF 2: SMPTE ST 2084 [PQ], MT: unknown, WP: unknown
GRN: 31982, 16503 [0.63964, 0.33006]
BLU: 14990, 29980 [0.2998, 0.5996]
RED: 7519, 2978 [0.15038, 0.05956]
WP: 15625, 16455, [0.3125, 0.3291]
Max/Min Lum: 0 / 0 nits
MaxCLL/FALL: 0 / 0 nits
And yes, I know how you have to enable HDR in windows before starting it. Worked in 30, does not seem to work in 31.
-
Verify settings maybe? HDR pass-through enabled in the JRVR config?
I could see metadata arrive with my HDFury Arcana.
Tone mapping with HDR output is coming once I put in the options for that, I assume within the next two weeks maybe.
-
Do you think custom shader support can be exposed sooner rather than later btw?
Full custom has some additional considerations I need to think about.
As for the geometry shader, I talked to the author of it and he agreed to let us integrate it. So I might do that first.
-
Full custom has some additional considerations I need to think about.
As for the geometry shader, I talked to the author of it and he agreed to let us integrate it. So I might do that first.
sounds great
-
Verify settings maybe? HDR pass-through enabled in the JRVR config?
I could see metadata arrive with my HDFury Arcana.
Tone mapping with HDR output is coming once I put in the options for that, I assume within the next two weeks maybe.
I'm not sure what's going on with it. After rebooting I could see it was 1000 nits but the rest of the metadata was still 0. I'll hold off on further testing until HDR output is available and see what happens then. That'll be huge for me.
-
If you want to read about the major changes, only really the libplacebo changelog is where any information can be found. We are shipping a git master snapshot from yesterday.
gamut mapping: https://code.videolan.org/videolan/libplacebo/-/commit/64099247d799272b9c72997c0fc834426b02ccee
tone mapping: https://code.videolan.org/videolan/libplacebo/-/commit/c378870595d3254490183352057d07359da4d54c
Alas, I couldn't find any good one about the new histogram based peak measurements. And there are more tweaks and improvements all around.
Summary:
- Fancy math to improve gamut mapping (eg. reducing BT.2020 to BT.709), resulting in improved details
- Tone mapping is now done in the IPTQc4 colorspace, which improves the quality (its a derivative specified by Dolby of the ICtCp/IPT colorspace, designed for image processing)
- Histogram for peak detection, improving the peak and average brightness values, excluding outliers
Some of the other features related to that will need hooking up to settings and providing the necessary metadata, those changes will come over the next builds.
using a JVC N7 with filter in place (native gamut is roughly DCI-P3) and comparing madvr b113 (with a particular compromise option turned on which is required for reasonable performance) with the above says that jrvr is noticeably more saturated, whether it's too saturated or madvr is undersaturated is hard to say but I am leaning towards saying it looks too much on jrvr (visually I suspect it is that red is too saturated)
one question, is target peak nits in jrvr meant to be set to the actual peak nits of your display or does it have some other meaning (c.f. madvr which has some not at all obvious config options)
-
If you are outputting SDR, I would recommend to try a range of target nit values, from whatever your peak is to slightly above or below it (depending where it is), and see how it looks, as the perceived result can depend on environment factors as well.
Especially if your target nit is pretty low (as many projectors are), I would try aiming a bit higher.
SDR doesn't really have a proper reference nit, so you definitely get some freedom here. We don't tonemap SDR content to your display either, after all.
If the result feels very oversaturated, I would also make sure that the gamut etc are all set properly to match the _wire format_ the display expects. A too narrow gamut on the renderer's side would result in oversaturation on the display.
If your display is DCI-P3, which seems to be what most content is in anyway, then no gamut compression would need to take place, and saturation should not really be impacted by the renderer. Unless of course your file is one of those that uses actual BT.2020 colors.
If gamut compression is being performed there are also options to impact the behavior that are not exposed, but right now its using the recommended perceptual method, which has a good balance between preserving hue, saturation and brightness. Alternatives will focus more on one of those three properties, sacrificing the others.
-
I set it to dci-p3 which the PJ expects, any other value looks really odd so I am pretty sure it's not a gamut mapping problem. It doesn't necessarily look bad unless it's skin tones, just obviously much more intense. I will play around with settings a bit and do some more comparisons
-
Nice changes in the 31.0.1 and 31.0.2.
5. NEW: Support for HDR to HDR tone mapping in JRVR.
7. NEW: HDR10+ dynamic tone mapping in JRVR.
HDR to HDR tone mapping is great!. Early days, as I need to test on the TV and PJ, but it is looking good on my HDR1000 monitor with high nit content (eg looks better than what the screens Tone Mapping does). How does the interplay between these two features work (I see if I also enable "HDR10+ dynamic tone mapping in JRVR" then in the JRVR Monitoring that there is then no mention of HDR to HDR tone mapping.
8. NEW: Image sharpening post-processing for JRVR.
I know someone who is going to like this when it becomes public :)
6. NEW: JRVR uses a new dynamic tone mapping algorithm using a re-designed histogram peak detection, enabled by default in the "Quality" preset.
How do you read this? I just see the attached static pic.
-
Very, very kuel!!!
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: 880 / 0.005 nits
MaxCLL/FALL: 699 / 0 nits
NICE :D It looks REALLY good especially for the first version of it. Well done!
-
How does the interplay between these two features work (I see if I also enable "HDR10+ dynamic tone mapping in JRVR" then in the JRVR Monitoring that there is then no mention of HDR to HDR tone mapping.
HDR10+ is not a feature you can turn on or off. If the file has HDR10+ tone mapping data (which not all HDR10+ files do, some just have scene peak data, which then disables peak detection only), then those metadata defined tone mapping curves are used. The tone mapping algorithm should show up as st2094-40 in the OSD - but only if its actually doing something - eg. the scene brightness is above your desired peak, otherwise its not there at all.
Of course HDR10+ metadata is equally used when tone mapping to SDR.
How do you read this? I just see the attached static pic.
Read what? The image shows the tone mapping/gamut mapping debug visualization.
The colored part is the gamut lobe, and the "graph" is the tone mapping.
Its more to help figure out what tone mapping is doing, not for users to gain information from. I can barely read it myself, but having it helps to show it to the people that do!
The text info OSD will contain a lot more information now about the tone mapping, including the measured brightness if dynamic peak detection is enabled (its not a separate bullet point, but should say something like "<algorithm> tone mapping (measured -> desired)". That should be more interesting for most people.
-
What happens when a video has both HDR10+ and Dolby Vision? Does it just stick with the HDR10+ metadata to help with tone mapping and setting the tone curves? Or does it somehow use both? The reason I ask is I see both listed in the display when playing one so was unsure what, exactly it was doing. Looks fantastic either way just more curious how it works.
-
What happens when a video has both HDR10+ and Dolby Vision? Does it just stick with the HDR10+ metadata to help with tone mapping and setting the tone curves? Or does it somehow use both? The reason I ask is I see both listed in the display when playing one so was unsure what, exactly it was doing. Looks fantastic either way just more curious how it works.
If HDR10+ tone mapping curves are present, it'll use those. Thats not a features supported from Dolby metadata yet. Dynamic scene brightness is used from either HDR10+ or DV, hopefully they wouldn't vastly disagree what the brightness is.
Note that there is no commercial content that ever supports both. Self-made content with copied metadata from other sources ... well no guarantees if they don't match.
-
If HDR10+ tone mapping curves are present, it'll use those. Thats not a features supported from Dolby metadata yet. Dynamic scene brightness is used from either HDR10+ or DV, hopefully they wouldn't vastly disagree what the brightness is.
Note that there is no commercial content that ever supports both. Self-made content with copied metadata from other sources ... well no guarantees if they don't match.
That is absolutely untrue I'm afraid. There most DEFINITELY is commercial content that has both! I know, I have a bunch. Alien, Alita, etc etc. Hence the question. Whether they match, I couldn't tell you as I don't have HDR10+ support on my LG OLEDs.
EDIT: This is from 1917, as an example:
Video
ID : 1
ID in the original source medium : 4113 (0x1011)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU, Blu-ray compatible / SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible
Codec ID : V_MPEGH/ISO/HEVC
Fun, right?? :D
-
Hendrik, do you know if HDR10+ JSON Sidecar files are supported?
-
Hendrik, do you know if HDR10+ JSON Sidecar files are supported?
They are not, and will not be. Metadata needs to be in the video. Metadata in extra files is a tool for authoring, not for playback.
-
thanks
-
Video is a constantly evolving topic, and while JRVR has made tons of progress, there is always more work to do....
Most of this JRVR tonemapping talk goes over my head ;D
Can I ask about a basic video playback feature that has been on my MC wish list for years - I predominantly use MC to watch Tv and movies in theater view with an IR MCE remote control and bitstream the audio. Is there any way you can put video playback slow motion controls into the theater view OSD (similar to Subtitles/LipSync/Zoom). And more importantly, prevent the "DSP Tempo dialog" from popping up when slow motion is enabled, preferably add an option to just mute the audio when video slow motion is used.
Thanks
-
Split Displaycal discussion.
-
Many thanks for this listing!
Regarding Windows color profiles and gamut mapping in JRVR, please note that Windows is switching from a passive attitude to system color correction (where the applications are responsible for performing the color conversions according to the display characteristics specified in ICC profiles associated with the display) to an active role where Windows performs automatic color correction at system level in an individual manner for each connected display (Advanced Color). This is done by performing de-gamma, color space conversion and re-gamma in the graphic card, using hardware blocks as described here (https://learn.microsoft.com/en-us/windows/win32/wcs/display-calibration-mhc).
This was already the case for Windows HDR mode since some Windows 10 build, but it's going to be enabled for SDR as well in Windows 11 (https://devblogs.microsoft.com/directx/auto-color-management/).
The display ICC profiles can now feature Microsoft proprietary tags to list display characteristics just for HDR mode, such as display min/max luminance or frame average luminance, as well as color primaries or white point. This can override EDID or DisplayID data that was used before for HDR presentation.
Details and links to other articles that go into more detail are here: Use DirectX with Advanced Color on high/standard dynamic range displays (https://docs.microsoft.com/en-us/windows/win32/direct3darticles/high-dynamic-range).
Please also note that using SetHDRMetadata on the swap chain is no longer guaranteed to send metadata to the display, as Microsoft warns about it themselves (https://learn.microsoft.com/en-us/windows/win32/api/dxgi1_5/nf-dxgi1_5-idxgiswapchain4-sethdrmetadata). I warned about this before, but I did not have a link to an official Microsoft statement to bring proof about this, and I was told the device you use shows the display is still sent the metdadata you specify on the swap-chain.
-
Since I notice there is HDR10+ support coming, may I request looking into whether HDR10+ passthrough can be implemented. HDR10+ Gaming support was recently enabled in the Nvidia drivers (r526.98 (https://www.nvidia.com/en-us/geforce/news/geforce-rtx-4080-game-ready-driver/)), and some games, such as the latest Need for Speed from Electronic Arts I think, can already output HDR10+ to compatible displays. It might only work when switching to HDR is done through the NVAPI though, I have not looked into it.
-
Since I notice there is HDR10+ support coming, may I request looking into whether HDR10+ passthrough can be implemented. HDR10+ Gaming support was recently enabled in the Nvidia drivers (r526.98 (https://www.nvidia.com/en-us/geforce/news/geforce-rtx-4080-game-ready-driver/)), and some games, such as the latest Need for Speed from Electronic Arts I think, can already output HDR10+ to compatible displays. It might only work when switching to HDR is done through the NVAPI though, I have not looked into it.
"HDR10+ Gaming" uses "Source Side Tone Mapping" based on dynamic scene data - this is practically the same as using the new HDR to HDR tone mapping mode in JRVR. Actual metadata passthrough to enable "Sink Side Tone Mapping" is not supported in any (public) API, neither from Microsoft or NVIDIA. Not that anyone I have ever spoken to could find. MS has a stub of an API with no documentation that just takes a binary blob, and according to MS engineers its not implemented at all.
-
Personally, I think the decision is very important and it's good that JRVR is being further expanded. As already mentioned, the video area is a constantly evolving topic.
In addition, the integrated madVR, as far as I can see, has not received any updates since 2018, as the company now sells its software together with hardware.
So I see a big plus for JRVR for the future of JRiver.
-
"HDR10+ Gaming" uses "Source Side Tone Mapping" based on dynamic scene data - this is practically the same as using the new HDR to HDR tone mapping mode in JRVR. Actual metadata passthrough to enable "Sink Side Tone Mapping" is not supported in any (public) API, neither from Microsoft or NVIDIA. Not that anyone I have ever spoken to could find. MS has a stub of an API with no documentation that just takes a binary blob, and according to MS engineers its not implemented at all.
Ah, I see, that's unfortunate! Thank you for the explanation!
-
Im currently using MC30 and have now bought MC31, so very much looking forward to testing the new features being introduced. Since I’m a projector user I haven’t moved across 100% to JRVR as madvr still offers me features better suited for my large 145” curved scope screen.
First off I want to ask about the new “adaptive” sharpening you are adding, is it the same as the madvr “adaptive sharpen”?
I have tested “adaptive sharpening” in madvr many times over the years but still prefer my current settings, maybe complex for some to get their head round.
I currently use “image enhancements” and “upscaling refinement” in madvr and can produce a very beautiful clean image. I have three profiles, three separate profiles where I have created different sharpening settings , soft, sharp and HDR. I use Command Fusion on the ipad which allows me to set one of the three sharpening settings depending on the quality of the film.
Now we all know that probably little to no sharpening would be required on smaller Oleds etc etc, however when you have a projection screen of 145” like mine one certainly does. However all the sharpening tools have to be used with care or else the image can look very digital and introduce heaps of artifacts!
BTW I use Windows 10, 3080 video card and upscale everything to 4K using the JVC NZ9, Isco IIIL anamorphic lens, and a cineslide to hold the lens which moves in and out for 16:9 or scope. I have motorised side masking with four ratios all with automated stops, 4:3, 16:9, 1.85 and ScopE.
My question is….
1. It looks like the “adaptive sharpening” in MC31 will not contain specific areas of the image like madvr, sharpen edges, crispen edges, thin edges, enhance detail, correct?
2. When Ive tested “adaptive sharpening” in madvr without any of the others, its sharpens all parts of the image, is this correct?
3. If I start to use JRVR rather than madvr on MC31, will I still be able to have three profiles, 1,2 and 3 for sharpening that I can incorporate into Command Fussion on the ipad?
My images below really explain it all.
Im excited about the new changes especially geometry correction, will explain further in new separate posts….
-
1. It looks like the “adaptive sharpening” in MC31 will not contain specific areas of the image like madvr, sharpen edges, crispen edges, thin edges, enhance detail, correct?
2. When Ive tested “adaptive sharpening” in madvr without any of the others, its sharpens all parts of the image, is this correct?
can't be sure but I think this post still applies -> https://yabb.jriver.com/interact/index.php/topic,133812.msg933099.html#msg933099
i.e. you'll need to wait for custom shader support to get the array of options you want
3. If I start to use JRVR rather than madvr on MC31, will I still be able to have three profiles, 1,2 and 3 for sharpening that I can incorporate into Command Fussion on the ipad?
JRVR profiles are rule (i.e. content) based in the same way zoneswitch is, I don't believe there is currently any way to change this on the fly (except manually by opening the settings screen)..
-
can't be sure but I think this post still applies -> https://yabb.jriver.com/interact/index.php/topic,133812.msg933099.html#msg933099
i.e. you'll need to wait for custom shader support to get the array of options you want
JRVR profiles are rule (i.e. content) based in the same way zoneswitch is, I don't believe there is currently any way to change this on the fly (except manually by opening the settings screen)..
Maybe Hendrick might explain the "ins and outs" of adaptive sharpening...
I need to wait for custom sharder support to get what I want, can you please explain what does this mean?
So it looks like I will never be able to use three different sharpness settings without opening settings page. If thats the case this wouldnt work for me as popping up a menu in the middle of a movie would certainly kill the experience.
-
It means you being able to add whatever shaders you want rather than only being able use whatever is bundled. Many other players support such a thing (eg MPC, MPV).
e.g. here's an adaptivesharpen filter (not sure it's what jriver uses) https://forum.doom9.org/showthread.php?t=172131
there's a bunch of other similar threads around
So it looks like I will never be able to use three different sharpness settings without opening settings page. If thats the case this wouldnt work for me as popping up a menu in the middle of a movie would certainly kill the experience.
not sure I'd say never, you'd need to ask for the feature and see if it gets implemented
there are plenty of MCC commands for various things after all so doesn't seem impossible to me
-
We are not going to write a custom shader for processing. It requires a lot of time and effort investment in a field I'm not an expert in (video dsp theory). If there is a high quality post processing shader available, we can look into using them if it makes sense to have their functionality as default.
Adaptive Sharpen itself really doesn't have any more user-facing options than the strength (called curve height in the shader).
-
I thought you planned to add support for user controlled custom shaders? This is what I was referring to rather than something you would add
-
Some of this is in the first public build Matt just posted.
https://yabb.jriver.com/interact/index.php/topic,135824.0.html
-
Many thanks for the new JRVR features added!
-
not sure I'd say never, you'd need to ask for the feature and see if it gets implemented
there are plenty of MCC commands for various things after all so doesn't seem impossible to me
I agree, either a request for MCC commands or in JRVR Profiles --> Profile Selection Rules allow selection based on a User Assigned keypress should do the trick.
-
Maybe Hendrick might explain the "ins and outs" of adaptive sharpening...
I need to wait for custom sharder support to get what I want, can you please explain what does this mean?
So it looks like I will never be able to use three different sharpness settings without opening settings page. If thats the case this wouldnt work for me as popping up a menu in the middle of a movie would certainly kill the experience.
Adaptive sharpen tries to sharpen blurry edges the most whilst doing the least sharpening for very sharp edges and flat areas.
The adaptive sharpen used is this:
https://gist.github.com/igv/8a77e4eb8276753b54bb94c1c50c317e
Optimal sharpening strength (according to objective metrics) - 0.5 (default setting)
Hendrik was kind enough to give us a box where we can adjust the strength up and down easily without editing the actual shader.
-
Note that for settings handling reasons, our strength is multiplied by 100 if that wasn't obvious. So 0.5 in the script is 50 in the settings.
-
Adaptive sharpen tries to sharpen blurry edges the most whilst doing the least sharpening for very sharp edges and flat areas.
The adaptive sharpen used is this:
https://gist.github.com/igv/8a77e4eb8276753b54bb94c1c50c317e
Optimal sharpening strength (according to objective metrics) - 0.5 (default setting)
Hendrik was kind enough to give us a box where we can adjust the strength up and down easily without editing the actual shader.
Thank you for answering my initial question.
-
a couple of quality of life enhancements, it would be nice/convenient if....
.. the currently active profile is selected for you in the JRVR settings dialog when that dialog is opened while playback is active
.. geometry correction is applied to the OSD
I'm guessing the latter can be filed under "never going to happen" but you never know :)
-
Hendrik, any chance to see the FEL layer being properly consumed as well? I know it's a long shot, but perhaps a DoVi-baker kind of approach but done at playback time?
-
Split Geometry Correction Comes to New Zealand (https://yabb.jriver.com/interact/index.php/topic,135868.0.html)
-
And I've only had a few hours with it, cant wait for a full day to test some of my 3000 BD rips ;)
-
Hendrik, any chance to see the FEL layer being properly consumed as well? I know it's a long shot, but perhaps a DoVi-baker kind of approach but done at playback time?
We're looking into it, but figuring out all the moving parts needs a lot of effort, so it may happen eventually, but probably not right away.
-
Still, the fact that you're looking at it is awesome. There's nothing that isn't properly licensed that can touch the FEL right now.
-
Still, the fact that you're looking at it is awesome. There's nothing that isn't properly licensed that can touch the FEL right now.
Fully agree! Thanks a lot Hendrik!
-
I can see when in the JRVR OSD that some of my movies are HDR10+ but I don't see the corresponding info in the HDR Format Feild. Is this a current Limitation?
Thanks
Nathan
-
Mine is populated
-
Mmmm... I just get "HDR10-compatible" nothing about "HDR10+"
-
Maybe mine is filled earlier with mediainfo solution. Can't right now do re-analyze to verify
-
Been testing the HDR Tonemapping with "Use HDR Dynamic Peak Detection (enables Dynamic Tone Mapping) and it is working really well. Knocks down some of the specular highlights on 4000nit content when playing to a 1000nit screen much better than the monitor does. Keeps detail where the monitor seems to just clip. Nice work!
-
Maybe mine is filled earlier with mediainfo solution. Can't right now do re-analyze to verify
Could be, I reanalyzed all video at one point and I don't have any listings for HDR10+
-
One of the fun tests to play around with is the Spears and Munsill UHD disc. The new version is due out a week from today. I've got mine preordered and it'll be here next Monday. When I was looking at lots of madvr tonemapping options, the previous version of the disc was great at identifying issues. Since I'll have both versions (the first version was not overly well mastered which has a tendency to break DTM algorithms LOL) I'll be able to compare and look at the results. The big question is how much detail is retained on 4000+ nit content. From what I can tell in just playing around, it's VERY good so far. Looking forward to stress testing it a bit.
-
Could be, I reanalyzed all video at one point and I don't have any listings for HDR10+
Nope, just cleared HDR Format field and I still get HDR10+ after MC video analysis
-
The list above is not necessarily exhaustive, and if there are any requests for topics we have worked on in the past, or new ones, they will be considered. I might have forgotten something just now when making the list, so feel free to remind us as well.
Smooth Motion
-
One of the fun tests to play around with is the Spears and Munsill UHD disc. The new version is due out a week from today. I've got mine preordered and it'll be here next Monday. When I was looking at lots of madvr tonemapping options, the previous version of the disc was great at identifying issues. Since I'll have both versions (the first version was not overly well mastered which has a tendency to break DTM algorithms LOL) I'll be able to compare and look at the results. The big question is how much detail is retained on 4000+ nit content. From what I can tell in just playing around, it's VERY good so far. Looking forward to stress testing it a bit.
Thanks for the heads up about the new version!
-
Up I'll be looking for the new Spears and Munsil as well!
-
Can I just ask a few questions about FSRCNNX 16 please....
Ive used madvr NGU Very High now for years and years, now we have adaptive sharpening I feel FSRCNNX 16 with a small amout of sharpening is giving me superior results to NGU Very High.
But Im so green with FSRCNNX 16 and after doing lots of searching I cant find much on it in laymens terms.
1. How many years has FSRCNNX been out for?
2. I hear there is many different implementations of FSRCNNX, some better than others they say... Is FSRCNNX 16 the best version out there today?
3. Is there ever any possibility that FSRCNNX 16 could even be improved?
Thanks in advance for helping me understand the "ins & outs" of FSRCNNX.
-
FSRCNNX is a neural network based algorithm. Its quality comes from training it with images and how they should look.
The current version was trained in 2021 and overall the algorithm has been out since 2018, with some predecessors being used before that already.
Any algorithm can possible be further improved, with new and better training sets and a lot of time. But this is not something we're working on, we just supply access to it.
-
So I just migrated to MC31 from MC30.
I have to say, the new DTM engine and sharpening features have really ironed out any issues I had previously with MC30.
It's definitely a more efficient build, pans are super smooth and image is cleaner, sharper and brighter (no need to set Target peak nits to an extremely low number)
I tried several UHD movies and series which were problematic but now all are working spectacularly.
Black Panther - First 10 minutes looks amazing, I can run this using Hable algo and the details in dark scenes are superb!
Mandalorian Ep 3 - First 20 mins, this always too dark for me and making adjustments would fix a particular scene but the whole balance was off, it's just right now!
See S2 E3 - First 10 mins, dark scenes mixed with the snow scene never really looked good for me, looks absolutely perfect now.
Everest - First 10 mins, adjusting for blacks in other movies/shows would always clip the whites here, MC31 fixes this so I can have my cake and eat it too.
One last issue which I've had is that I have this movie: Everything Everywhere All at Once (mkv) which plays fine with embedded PGS english subs, works fine in mpc-be but in MC30/31 it does not have any available subtitles. Any way for me to check why it's not showing?
thanks!
-
One last issue which I've had is that I have this movie: Everything Everywhere All at Once (mkv) which plays fine with embedded PGS english subs, works fine in mpc-be but in MC30/31 it does not any available subtitle at all. Any way for me to check why it's not showing?
Check the file in something like MKVToolNix and see if the sub is tagged as "enabled"
-
Check the file in something like MKVToolNix and see if the sub is tagged as "enabled"
Yup this fixed it, just needed to enable the tracks in mkvtoolnix, thank you very much!
-
murray,
Thanks very much for your posts at AVSForum (as RapalloAV).
https://www.avsforum.com/threads/madvr-player-support-thread.2215490/page-427#post-62538059
and thanks, jmone, for all your help getting murray to the finish line.
-
Ahhh, it's all part of the fun. We are now discussing the pros and cons of HDR-->SDR vs HDR-->HDR tonemapping. I'll bet a beer that Murray will stick with HDR-->SDR as it look great (his words) and does not have issues from the PJ switching between SDR and HDR modes. I get around this by leaving Windows in HDR mode all the time (on my Flat Screens - my JVC PC has a Magenta Bug to work around), and let Windows do the reverse SDR-->HDR tonemapping. Now if JRVR could do that! Maybe MC32 for that one.
-
Nope, just cleared HDR Format field and I still get HDR10+ after MC video analysis
I think I've found what is going on. Do you have 1917 or WW1984 for example (both are HDR10+)? For me these are listed as "DolbyVision Profile 7, HDR10-compatible" under HDR format. From what I can see files tagged as "DolbyVision Profile 7, HDR10-compatible" could be HDR10 or HDR10+. Files that are only HDR10 or HDR10+ are tagged correctly.
-
1917 is tagged the same way for me
-
Ahhh, it's all part of the fun. We are now discussing the pros and cons of HDR-->SDR vs HDR-->HDR tonemapping. I'll bet a beer that Murray will stick with HDR-->SDR as it look great (his words) and does not have issues from the PJ switching between SDR and HDR modes. I get around this by leaving Windows in HDR mode all the time (on my Flat Screens - my JVC PC has a Magenta Bug to work around), and let Windows do the reverse SDR-->HDR tonemapping. Now if JRVR could do that! Maybe MC32 for that one.
Very true and after lots of testing tonight Ive decided to keep all in SDR as Hendrick has created an amazing HDR to SDR. To be honest I just dont see HDR to HDR running on my JVC NZ9 looking any better than HDR to SDR on MC31. I hate all the resyncing of the projector so I have decided to run all in SDR. If it looked even 50% better in HDR to HDR I might live with the resync times, but its absolutly all perfect for me staying SDR all the way...... Im very very happy!
-
I think I've found what is going on. Do you have 1917 or WW1984 for example (both are HDR10+)? For me these are listed as "DolbyVision Profile 7, HDR10-compatible" under HDR format. From what I can see files tagged as "DolbyVision Profile 7, HDR10-compatible" could be HDR10 or HDR10+. Files that are only HDR10 or HDR10+ are tagged correctly.
Yes I brought this up before and asked about which is actually being used earlier in the thread. There are quite a few that have both HDR10+ and DV.
-
I have a question. If I understands this correct. Hdr to hdr tonemapping is activated with ticking off this feature hdr to hdr tonemapping in jrvr settings right? But this talk about hdr to sdr what is that about and how is this done or activated? is this making and sdr movie get played as a hdr thus able to use tone mapping on a sdr movie? or is it just plain hdr to sdr...is this just as simple as one does not tick of hdr mode in jrvr setting...so that hdr movies are just played like an sdr movie?
-
For HDR to SDR -> Disable "Use the display's HDR capability"
For simple HDR passthrough -> Enable "Use the display's HDR capability"
If you want to use HDR to HDR Tone Mapping -> Enable "Use the display's HDR capability" & Enable "Enable HDR to HDR Tone Mapping"
-
Any plans for IVTC? I really hate NTSC bodges, but was looking at one of Murray's problematic movies (Oklahoma!) and the processing of this 60i BD Encode (remuxed to MKV) is tough to do without massive frame drops. I may get him to post a link to a 10min sample if you are interested. The other option is to post process the video stream.
The odd thing in this testing is deinterlacing seems very expensive (YADIF worst, then D3D) but the OSD stats seems weird at times. I can get constant dropped frames when MAX render time is reported as around 10ms when using D3D, so I'm not sure the stats takes the HW Deinterlacing into account, and at other times the MAX render times can jump to over 30+ms and not drop frames.
The next odd thing is when in 59.94hz mode, the reported VSync wanders all over the place, which I don't think helps. I don't see this on 23.976 or 50hz.
-
No plans for IVTC at this point.
-
No probs - more than one way to skin a cat.
-
I'm adding black bar and aspect ratio options to JRVR currently, and I wanted to get some feedback if this covers everything sensible for usual setups.
Basically this is what I'm thinking right now, on a per-output basis in JRVR.
- Enable Black Bar Cropping
- Crop to [Automatic] (using the metadata), and [a list of common aspect ratios] (similar to whats available today in the context menu)
- Aspect Ratio Mode: Preserve, Stretch, Crop. Existing options as a per-output default. (moved from Video -> Aspect Ratio mode into per-output settings)
- Aspect Ratio adjustment, eg. a factor to adjust the aspect ratio by. Might have some presets and an input for a scale factor. This would be used for anamorphic lenses (or older screens with non-square pixels).
(this option was previously available in Video -> Aspect Ratio correction, this is moving it and making it per-output when using JRVR)
Advanced:
- Vertical Image Shift, Shift image to the top or bottom, rather then centered.
These are essentially all existing settings, streamlined into per-output settings in JRVR, and of course making use of automatic black bar cropping based on the metadata we're gathering now.
-
It sounds good to me
-
I would like to echo some of the comments I have seen on this thread, which have stated that Dynamic Tone Mapping on JRVR MC31 is just amazingly good!!! Up to MC30, I have been using the last free version of madVR (113 ?), but JRVR in MC31 has surpassed the performance of that madVR version, and I have decided to use it all the time now ! Outstanding job, JRiver team !!!
-
I would like to echo some of the comments I have seen on this thread, which have stated that Dynamic Tone Mapping on JRVR MC31 is just amazingly good!!! Up to MC30, I have been using the last free version of madVR (113 ?), but JRVR in MC31 has surpassed the performance of that madVR version, and I have decided to use it all the time now ! Outstanding job, JRiver team !!!
Great to read another very happy user of JRVR MC31, its so good to have finished using the dead 113 madvr!
-
I would like to echo some of the comments I have seen on this thread, which have stated that Dynamic Tone Mapping on JRVR MC31 is just amazingly good!!! Up to MC30, I have been using the last free version of madVR (113 ?), but JRVR in MC31 has surpassed the performance of that madVR version, and I have decided to use it all the time now ! Outstanding job, JRiver team !!!
I believe JRVR is heavily based on libplacebo. Hopefully, JRiver contributes to the project. In what way is the DTM improved vs JRiver 30 and MadVR 113?
-
I believe JRVR is heavily based on libplacebo. Hopefully, JRiver contributes to the project.
Yes, Hendrik contributes to the project - https://code.videolan.org/videolan/libplacebo/-/project_members
-
I'm adding black bar and aspect ratio options to JRVR currently, and I wanted to get some feedback if this covers everything sensible for usual setups.
Basically this is what I'm thinking right now, on a per-output basis in JRVR.
- Enable Black Bar Cropping
- Crop to [Automatic] (using the metadata), and [a list of common aspect ratios] (similar to whats available today in the context menu)
- Aspect Ratio Mode: Preserve, Stretch, Crop. Existing options as a per-output default. (moved from Video -> Aspect Ratio mode into per-output settings)
- Aspect Ratio adjustment, eg. a factor to adjust the aspect ratio by. Might have some presets and an input for a scale factor. This would be used for anamorphic lenses (or older screens with non-square pixels).
(this option was previously available in Video -> Aspect Ratio correction, this is moving it and making it per-output when using JRVR)
Advanced:
- Vertical Image Shift, Shift image to the top or bottom, rather then centered.
These are essentially all existing settings, streamlined into per-output settings in JRVR, and of course making use of automatic black bar cropping based on the metadata we're gathering now.
Thank you Hendrik for all the new features you are adding to JRVR, its much appreciated.
I would love to stop using my JVC NZ9 projector for my anamorphic stretch as the new model blanks on and off when I activate stretch so it isn’t pleasant. The previous model NX9 didn’t exhibit this blanking iussue and since I’m an X cinema projectionist I’m a bit of a presentation freak!
My only concern is would I be able to activate the JRVR stretch manually ON & OFF as I don’t want it activating automatically by itself? If it was only an automatic system I wouldn’t use it. For many it wouldn’t matter as most don’t have incorporated automated black side masking and a Cineslide for the “A” lens.
Please let me explain …
I use the playlist feature within JRiver which is a wonderful feature BTW, I make up an assortment of 3 to 4 trailers with different ratios > main feature…. Sometimes I prefer to show an odd scope trailer in 16:9 or 1.85 as many cinemas do before the main feature starts which might be scope. After the pre show the masking opens up to reveal the ScopE widescreen of the main feature, thereby adding impact.
I have many functions built into one button press for scope, Cineslide that moves the “A” lens in and out, black automated 4 stop masking for 4:3, 16:9, 1.85 and 2.35 scope, “A” stretch in the proj. That one button press changing from 16:9 to scope has all the “other” functions timed within mllliseconds of each other takes approx. 2 seconds and has impact!
I think for it to work for me it would need to be basically ON or OFF stretch, that I could build into Command Fusion 2.35 button. All I would need to do is remove the proj stretch from the 2.35 button and replace it with JRVR ON stretch, all the other buttons 4:3, 16:9 and 1.85 I would add JRVR OFF stretch. A keystroke assigned to ON and OFF would be all that’s required for me to use the new feature.
Im happy to offer any testing if you are in agreeance to a manual A stretch ON/Off function.
So in a nutshell to keep everyone happy, I suggest a manual way to operate the A stretch ON/OFF and maybe an automated way for those that don’t use Cineslides and automated black masking with multiple raitios.
-
some of the existing options have MCC commands to operate them, some don't (partly because they are not live playback options). If all of these move into the playback space then it would be good to get them accessible via MCC (and hence MCWS).
while we're on the wishlist :) it would also be nice to get access to that information in an easier to read format, currently you have to parse the internal settings format to tell what the active aspect ratio is.
e.g. determining if it's 2.4 mode requires parsing something like this (1:1)(11:AspectRatio)(35:(1:4)(1:0)(1:0)(6:327692)(1:1)(1:0))
-
I'm glad you can parse it! I've always just copied it blindly from one entry to another in the DB!
-
I believe JRVR is heavily based on libplacebo. Hopefully, JRiver contributes to the project. In what way is the DTM improved vs JRiver 30 and MadVR 113?
Good to hear, thanks! The MadVR situation is obviously bad.
-
I'm adding black bar and aspect ratio options to JRVR currently, and I wanted to get some feedback if this covers everything sensible for usual setups.
Basically this is what I'm thinking right now, on a per-output basis in JRVR.
- Enable Black Bar Cropping
- Crop to [Automatic] (using the metadata), and [a list of common aspect ratios] (similar to whats available today in the context menu)
- Aspect Ratio Mode: Preserve, Stretch, Crop. Existing options as a per-output default. (moved from Video -> Aspect Ratio mode into per-output settings)
- Aspect Ratio adjustment, eg. a factor to adjust the aspect ratio by. Might have some presets and an input for a scale factor. This would be used for anamorphic lenses (or older screens with non-square pixels).
(this option was previously available in Video -> Aspect Ratio correction, this is moving it and making it per-output when using JRVR)
Advanced:
- Vertical Image Shift, Shift image to the top or bottom, rather then centered.
These are essentially all existing settings, streamlined into per-output settings in JRVR, and of course making use of automatic black bar cropping based on the metadata we're gathering now.
Hello Hendrick, are you considering something like Non Linear stretching for us to have the option to fill up our screens, regardless of the original aspect ratio ?
-
Hello Hendrick, are you considering something like Non Linear stretching for us to have the option to fill up our screens, regardless of the original aspect ratio ?
This is certainly something that I wouldnt use, but I do think it would be a HUGE selling point to attract many new customers to JR as so many keep asking for it on the proj forums.
-
Hello Hendrick, are you considering something like Non Linear stretching for us to have the option to fill up our screens, regardless of the original aspect ratio ?
Non-Linear Stretching is not something we are currently looking into, sorry.
Maybe thats something custom shaders can do for you though, once we implement those.
-
some of the existing options have MCC commands to operate them, some don't (partly because they are not live playback options). If all of these move into the playback space then it would be good to get them accessible via MCC (and hence MCWS).
How about a MCC to pin a defined JRVR profile to be active, disregarding all selection rules? (If there even are any)
I'm not particularly sold on the idea of handling every option in 5 different ways.
-
How about a MCC to pin a defined JRVR profile to be active, disregarding all selection rules? (If there even are any)
I'm not particularly sold on the idea of handling every option in 5 different ways.
For me, this would be fine (though I hope to rely 100% on automatically switching)
It would be great if the active profile can also be added as a field to MCWS/v1/Playback/Info?Zone=xx
-
Request: allow external .sup subtitles.
-
Any plans for IVTC? I really hate NTSC bodges, but was looking at one of Murray's problematic movies (Oklahoma!) and the processing of this 60i BD Encode (remuxed to MKV) is tough to do without massive frame drops. I may get him to post a link to a 10min sample if you are interested. The other option is to post process the video stream.
The odd thing in this testing is deinterlacing seems very expensive (YADIF worst, then D3D) but the OSD stats seems weird at times. I can get constant dropped frames when MAX render time is reported as around 10ms when using D3D, so I'm not sure the stats takes the HW Deinterlacing into account, and at other times the MAX render times can jump to over 30+ms and not drop frames.
The next odd thing is when in 59.94hz mode, the reported VSync wanders all over the place, which I don't think helps. I don't see this on 23.976 or 50hz.
Oklahoma is an oddity, as it was originally shot at 30 FPS. The BD is 59.94 FPS interlaced (or more properly PsF or progressive sequential frame). There is NO telecine applied to this title, as each frame on the BD alternates fields to recreate the 29.97 FPS original frame.
I have had no trouble playing this title on Zoom Player, I'll give it a run tonight on JRiver 31 beta (as soon as I download it).
-
Thanks - figured it all out we remuxed it back to the real 30fps. It is a very good transfer (once you get it out of 59.94i) and plays great in JRVR now. Not my cup of tea, but the quality of this 70mm 30fps transfer is top notch. Shows what could be done even "back in the day".
-
I'm adding black bar and aspect ratio options to JRVR currently, and I wanted to get some feedback if this covers everything sensible for usual setups.
Basically this is what I'm thinking right now, on a per-output basis in JRVR.
...
Thank you, thank you thank you etc. etc. etc.
Please make sure that all A.R presets are customizable, both in size (vertical & horizontal) and in position. Please provide at least 10 customizable presets.
Please take into account that 1.77:, 1.85:1 and 2.40:1 are not the only offered ARs.
I personally have commercially released media in the following ARs:
1.77:1
1.85:1
2.00:1
2.20:1
2.35:1
2.40:1
2.55:1
2.76:1
2.85:1
Finally a compelling reason to make JRiver my preferred player.
Been playing with MPV recently, setting up custom AR's:
Shift+F1 set video-scale-x .7; set video-scale-y 1.0 #menu: Aspect Ratio > 1.77:1
Shift+F2 set video-scale-x .73; set video-scale-y 1.031 #menu: Aspect Ratio > 1.85:1
Shift+F3 set video-scale-x .79; set video-scale-y 1.13 #menu: Aspect Ratio > 2.00:1
Shift+F4 set video-scale-x .86; set video-scale-y 1.24 #menu: Aspect Ratio > 2.20:1
Shift+F5 set video-scale-x .92; set video-scale-y 1.35 #menu: Aspect Ratio > 2.40:1
Shift+F6 set video-scale-x .96; set video-scale-y 1.42 #menu: Aspect Ratio > 2.55:1
Shift+F7 set video-scale-x 1.08; set video-scale-y 1.54 #menu: Aspect Ratio > 2.76:1
Shift+F8 set video-scale-x 1.15; set video-scale-y 1.68 #menu: Aspect Ratio > 2.85:1
Please note that the correction for the 1.5x anamorphic lens is already factored into the scale ratios.
JRiver 31 is looking better and better. ;D Time to upgrade (again)
Vern
-
Oklahoma is an oddity, as it was originally shot at 30 FPS. The BD is 59.94 FPS interlaced (or more properly PsF or progressive sequential frame). There is NO telecine applied to this title, as each frame on the BD alternates fields to recreate the 29.97 FPS original frame.
I have had no trouble playing this title on Zoom Player, I'll give it a run tonight on JRiver 31 beta (as soon as I download it).
I dont know why Oklahoma drops lots frames on JRVR??
Ive had the BD for many years and it never dropped frames and still doesnt when I play it on madvr, plus Im using the 3080 video card.
Nathan did fix the issue for me but we really shouldnt have to make these changes to a 59.97 fps interlaced film.
-
I dont know why Oklahoma drops lots frames on JRVR??
Ive had the BD for many years and it never dropped frames and still doesnt when I play it on madvr, plus Im using the 3080 video card.
Nathan did fix the issue for me but we really shouldnt have to make these changes to a 59.97 fps interlaced film.
The issue is that Blu Ray doesn't include progressive 30FPS as a supported frame rate in their standards.
So the only way to encode it on blu ray is 60 fps frame packed as discussed above. This looks the same as 30 fps interlaced to the authoring software. Yes, it's a kluge, but you can blame the people that originally created the blu ray standards.
And yes, it stutters on MC 30, but plays fine on 31, Zoom Player and MPV.
-
The issue is that Blu Ray doesn't include progressive 30FPS as a supported frame rate in their standards.
So the only way to encode it on blu ray is 60 fps frame packed as discussed above. This looks the same as 30 fps interlaced to the authoring software. Yes, it's a kluge, but you can blame the people that originally created the blu ray standards.
And yes, it stutters on MC 30, but plays fine on 31, Zoom Player and MPV.
My rip doesnt play fine on MC31, I dont know why yours would?
I also dont know why it plays fine on madvr ever since the print was released but not on my version of MC31 JRVR.
One of those oddities I suppose....
-
Thank you, thank you thank you etc. etc. etc.
Please make sure that all A.R presets are customizable, both in size (vertical & horizontal) and in position. Please provide at least 10 customizable presets.
Please take into account that 1.77:, 1.85:1 and 2.40:1 are not the only offered ARs.
I personally have commercially released media in the following ARs:
Just got done doing some preliminary testing on 31. Fortunately, the MCC 28038 commands still work. Thanks for including a custom field for the anamorphic lens expansion factor as I use a 1.5x HE lens with a 2.76:1 screen.
While the tone mapping looks OK, the test patterns I looked at don't look very favorable for libplacebo.
I have attached 3 patterns, one from JRVR31, one from the most recent MPV, and one from JRVR30 / MadVR beta 166. All were run on the same system.
The MPV config is:
[bt.2100-pq]
profile-cond=get("video-params/primaries") == "bt.2020" and get("video-params/gamma") == "pq"
profile-restore=copy
target-trc=bt.1886
target-prim=bt.2020
target-trc=gamma2.2
tone-mapping-mode=auto
gamut-mapping-mode=auto
target-peak=100
Files attached were taken using Windows screen capture. I hope it's all right to post these here.
-
My rip doesnt play fine on MC31, I dont know why yours would?
I also dont know why it plays fine on madvr ever since the print was released but not on my version of MC31 JRVR.
One of those oddities I suppose....
I'm playing mine off of a mounted ISO. Same PC, it has both 30 & 31 on it. i just installed the latest release 310017 tonight, using JRVR on it. played with no stuttering.
-
I'm playing mine off of a mounted ISO. Same PC, it has both 30 & 31 on it. i just installed the latest release 310017 tonight, using JRVR on it. played with no stuttering.
Mine is an mkv from the BD. Maybe JRVR has trouble with the interlacing.
-
Lets not go too far down the rabbit hole that is Oklahoma, but FWIW it's the "deinterlacing" overhead that is pushing Murray's 3080 to0 hard on this title with the "max" settings he has. The answer would be to:
- lower settings
or
- turn off deinterlacing
or
- mux it back to 30p
The easiest (as this is a one off) was to just create a 30p version. Plays perfectly without having to change settings to accommodate what is a very unique title.
FWIW - I could play the original on my 4090 without dropping frames.... but only just.
-
While the tone mapping looks OK, the test patterns I looked at don't look very favorable for libplacebo.
what's it meant to look like?
-
what's it meant to look like?
The MadVR JRiver output. These are frame captures, in motion the darker patches are blinking on and off.
You can find a complete set of patterns on the Spears and Muncil V3 calibration set, or a somewhat easier to navigate set referenced here: https://www.avsforum.com/threads/hdr10-test-patterns-set.2943380/ (https://www.avsforum.com/threads/hdr10-test-patterns-set.2943380/).
Working with tone mapping can be very subjective, but these patterns and images help us to actually quantify what we believe our eyes are seeing.
Watching real world program material, the JRVR31 and the MPV tone mapping algorithms have visibly higher (excessive?) saturation in the reds than MadVR does.
This shows clearly in the test pattern I posted, as MadVR with the proper settings is really the only option that seems to process all colors equally.
If you desire, I can post my MadVR calibration settings for you. I am using a JVC RS3100 running medium laser.
On second thought, I have included it as an attachment. (It's actually using max3 variant 2).
When you download these patterns, you will find in section 9, an HDR video that has 20 or so still images that show these differences. Put them up side by side on a display and observe the impact on the saturation in the reds in particular caused by variations in tone mapping algorithms.
Disclaimer: I am only speaking from my observations which are based on logic and my perceptions. These are based on prior experience as a projectionist for 30 years in commercial theatres and experience calibrating all manner of projectors in my HT for the past 15 years or so.
-
FWIW - Hendrik has already noted the following in a post I had about something up with tonemapping blues (but this test was with HDR Output - and then windows weird PrtScr but you get the idea):
The desaturation of strong blue tones is a known issue and should be improved when we next update libplacebo.
-
Watching real world program material, the JRVR31 and the MPV tone mapping algorithms have visibly higher (excessive?) saturation in the reds than MadVR does.
yes I've reported this previously, there are certainly saturation issues with red that are quite apparent on skin tones.
-
Tonemapping is an ever ongoing process. Definitely tracking some saturation issues still.
-
Split madVR Settings (https://yabb.jriver.com/interact/index.php/topic,136309.0.html)
Please don't use this thread for madVR discussion.
-
OK - found a better way to do print screens when in Windows HDR Mode (Win + Alt + PrtScn and then look in your C:\Users\[USERNAME]\Videos\Captures for the "sdr" PNG version). Still looks funky but it shows the results much less weirdly than a straight PrtScn and closer to what you really see. In real life viewing the gradients are much smoother.
So this is a "2020 10,000nit HDR HSV Sweep Test pattern. The top pics are with "enable HDR to HDR Tone Mapping" and "Reduce Gamut to DCI-P3-D65 (in BT.2020)" ON with a HDR to HDR Target Peak Nits set to 1000. The bottom pics are with these off for comparison.
As Hendrik says, tone mapping is an ongoing journey and the changes from 31.0.23 to 31.0.24 is a big step up for the undersaturation of Purple, though it looks like there is still a bit to go to get in fully linear like the other primaries.
-
Taking fully saturated high brightness color and trying to fit it into an image thats not only lower brightness, but also more limited gamut range, is always going to be a trade off. Its usually a combination of desaturation and losing some details. Or rather, minimizing both. If you want perfect saturation, you could clip the color space, but you lose detail then. Or if you want perfect detail, you can go full on desaturation. The mode we use is called "perceptual" which tries to balance these.
I could put the option back in to let you choose between these three modes, but I don't believe the other two (clip and desat) are really worth using outside of making pattern look good.
-
I could put the option back in to let you choose between these three modes, but I don't believe the other two (clip and desat) are really worth using outside of making pattern look good.
Dieselgate didn't turn out well for VW.
My money is on Hendrik and Niklas.
-
Nope - I'm happy to stick to the mainstream! As you say, there HAS to be a trade off. Well until we get better displays and tone mapping is no longer required!
Test patterns are no match for just watching stuff in real life, but they are good at showing what is being done behind the scenes. The real goal is to have Skin tones look right as we are all very sensitive to that. I don't care if say a red or purple dress's hue is slightly different as I have no mental reference on what it should look like in real life anyway. As long as it is not obviously over or under saturated then who cares?
Plus (and as I said), these SDR screen shots of an HDR screen are at best wonky and you have to look at the test pattern in real time where you can see the impact of Tone and Gamut Mapping. That HSV test pattern does show how well the changes have gone with the mapping of Red and Green both with the reduction of luminance and also gamut. They look perfect in fact (at 1000nits and P3) on my monitor, with nice blending from one hue to another and nice blending from one luminance to another. The only one that does not look perfect is the Blue which (on my screen) shows issues with the transitions on the red side all through the luminance range but it's mostly at the med to low nits.
Also this is a big step up from the prior version, and is also much much better than what my display can do natively. Notice how the bottom two shots in the image have no graduation at all? Really not good. The JRVR version are nice and smooth (with the exception of the Blue / Red transition) the rest looks spot on (eg Red to Green and Green to Blue look great). I'll see if I can film this. Edit: Nope - poor idea.
-
FWIW - I had a poke around a later madVR release with this test HSV Sweep. Hard to compare exactly with JRVR as I don't think madVR can even do P3 in 2020 (win for JRVR). So in just comparing tone mapping from 10,000 down to 1,000nits (without gamut mapping), JRVR looked better with the luminance graduations and between red to through yellow to green through cyan to blue. madVR better on the blue though magenta to red. The Blue to Red transition and Blue at higher nits must be harder for some reason as while the transitions looked smoother on madVR, it still was not that great.
-
Hi,
I would like to thank you for the new HDR to HDR tone mapping feature, it's really great!
I did notice something strange having to do with Dolby Vision. When the video file has DV information (Profile 5,7 and 8 ), the black floor gets raised slightly. I think this might be correct behaviour, as DV never really has a 0 nit minimum luminance? This doesn't happen when the exact same file is stripped of the DV information, or with any regular HDR10 video.
I tried to produce some evidence, but as has been said above, making screenshots in HDR has proven to be a challenge, even with the windows+alt+screen trick. I did try several different videos, and even extracted the DV data for some to make sure it's the exact same HDR10 base layer.
I guess I wanted to confirm if this is intended behaviour, and if anyone else has noticed this or can reproduce my results?
-
. Hard to compare exactly with JRVR as I don't think madVR can even do P3 in 2020 (win for JRVR).
I think it's calibration > report bt.2020 to display (nvidia only)
-
a few small quality of life improvements around the config would be nice
1) one click access to jrvr settings (currently have to go video settings then jrvr)
2) auto select the currently active jrvr profile when opening settings page
3) make video settings and jrvr settings pages remember their size (currently both open full screen every time and don't remember being resized)
-
The settings dialog already remember their size, and do not open in fullscreen by default.
-
The settings dialog already remember their size, and do not open in fullscreen by default.
Not for me they don't
Is it stored in registry or library? Perhaps I can surgically delete something to reset it
-
Should be in the registry under Properties, Window Placement - JRVR Options
But it should also save when you shrink it down again.
-
1) one click access to jrvr settings (currently have to go video settings then jrvr)
+1 for this. You could always do it with right click DirectShowFilters--> xyz when in custom or with madVR but JRVR is greyed out.
-
Should be in the registry under Properties, Window Placement - JRVR Options
But it should also save when you shrink it down again.
deleting the registry entries fixed it, fwiw it previously had
2C0000000001000001000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB1000000D40200000707000 050080000
-
Hello JRiver team !
Just bought the update , 10 years without you .. and now I'm back ;-)
I'm back 'cause I want to test HDR to HDR Tonemap on my Sony XW5000 Laser projector.
So can you please confirm the settings for me ?
Red October JRVR
Quality preset
Enable black bar cropping
Use the display HDR capability for HDR video ON
Automatically switch to HDR ON
HDR to SDR conversion Target peak Nits : no idea ..
Enable HDR to HDR Tone mapping ON
Reduce Gamut to DCI-P3 ON but not sure ...
HDR to HDR Peak Nits : 80 I will measure the nits of my setup later and calibrate the projector. This setting is the max nits of my projector, isn't it ?
Tone Mapping Algo : Auto
Enable 10 bit output for SDR ON
Upscaling Jinc
Chroma Upscaling Bilateral Chroma Scaling
Scale in Sigmoidal Light
SuperRes ON - FSRCNNX 16
Downscaling Lanczos 4taps
Debanding Low
Sharpening 50
Video Hardware D3D11
Advanced HDR Settings
Use HDR Dynamic Peak Detection ON
Convert HLG to HDR10 ON
A huge thanks to you !
-
Hi tixi! Welcome back :)
Looks like a good starting point. Will really depend on your GPU with some of these settings (like FSRCNNX 16) to be fast enough to not drop frames, but you will notice this immediately. If you are HDR to HDR tonemapping then setting the SDR Target Peak Nits is kind of irrelevant, but you might as well set it to somthing similar to start with incase you end up doing HDR to SDR tone mapping (as that seems to be what most PJ users do). I do notice that your XW5000 is a pretty bright PJ so 80nits sounds low but it is easy enough to play with the max brightness settings to get something that you like the look of. Scaling Gamut down to P3 in 2020 is probably a good move as your PJ has 95% P3 coverage and for those few HDR movies that have full 2020 it will mean your PC will be doing most of the gamut scaling rather than your PJ (which probably just clips).
Have a play and let us know how you go.
-
Hi tixi! Welcome back :)
Looks like a good starting point. Will really depend on your GPU with some of these settings (like FSRCNNX 16) to be fast enough to not drop frames, but you will notice this immediately. If you are HDR to HDR tonemapping then setting the SDR Target Peak Nits is kind of irrelevant, but you might as well set it to somthing similar to start with incase you end up doing HDR to SDR tone mapping (as that seems to be what most PJ users do). I do notice that your XW5000 is a pretty bright PJ so 80nits sounds low but it is easy enough to play with the max brightness settings to get something that you like the look of. Scaling Gamut down to P3 in 2020 is probably a good move as your PJ has 95% P3 coverage and for those few HDR movies that have full 2020 it will mean your PC will be doing most of the gamut scaling rather than your PJ (which probably just clips).
Have a play and let us know how you go.
Hi Jmone
Thanks for your answers ;-)
Yes my Sony is very bright, but I have negative 100'' 0.6 gain projector screen ( my setup is in a white living room so it helps a lot ! ) . I will compare HDR to HDR TM et HDR to SDR TM.
My PC specs is a Intel NUC with Core i7 with RTX2060 , no drop frame , just great !
I will let you know very soon ;-)
-
One of the great things about JRVR is just how efficient it is. You can really crank up the settings with modest GPUs.
-
One of the great things about JRVR is just how efficient it is. You can really crank up the settings with modest GPUs.
I totally agree with that !
I've test with Madvr with same settings :
JRiver : no fan noise on the NUC, really pleasant..
Madvr : fan at 80/90 % , for the same result...
-
Nice!
-
Which is the sharper Chroma Upscaling algorithm ? Bilateral Chroma Scaling or Lanczos (or other) ?
-
deleting the registry entries fixed it, fwiw it previously had
2C0000000001000001000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB1000000D40200000707000 050080000
same thing happened again, it stuck in full screen and won't remember the setting, different value this time
2C00000002010000
03000000FFFFFFFF
FFFFFFFFFFFFFFFF
FFFFFFFF7BFFFFFF
8A00000022060000
06060000
-
Make sure you dont position it half way offscreen, I think it doesnt like that.
-
Is anyone else running into a/v sync issues every once in a while recently? Video will glitch and then audio goes out of sync, I usually just switch audio tracks back and forth and it's fixed, maybe once every 30 minutes or so. I figured it was just my hardware, but it's happened on a few different filetypes now and just started recently (within last couple weeks of builds) so I thought I'd ask. Up-to-date W11, Intel iGPU using HDR passthrough, everything (besides content) at 60hz. Lots of recent driver and windows updates too so I can investigate.
Do you recommend using VideoClock with JRVR? I haven't tried disabling it but perhaps it's contributing to the issue.
-
Since no one else was having issues I ended up doing a clean reinstall of the latest Intel graphics drivers and my lip sync problems have disappeared. It felt like a driver problem all along, hopefully this can help someone else out if they run into the same thing.
-
Just installed V31 and started playing with it.
First of all, congrats on the progress on JRVR, the DTM has much improved.
I have a few questions:
1) I use a DCI P3 with a 2.4 gamma as a baseline for my JVC NZ8. When using JRVR set to P3 / gamma 2.4, the gamut looks right but it looks like there is some black crush (confirmed with the S&M brightness pattern). What are the correct options to get proper DTM? This is without a 3D LUT first. [EDIT: I selected a 30000:1 custom contrast, which is the native contrast of the PJ with the current settings, laser dimming disabled].
2) Re 3D LUT, I'm assuming we can use any 3D LUT created for madVR using Colorspace / Calman / DisplayCal, am I correct? If so, can we target gamma 2.4, or do we have to target gamma 2.2 for the LUT to be valid?
3) Re vertical shift for black bar detection, it's great to see that you plan to add this feature. Two questions about this: 1) Any ETA for this to be implemented and 2) I understand that the black bar detection is done offline to save processing time, when adding the files to the library. I use JRiver as a player with CMC as a front end. Please can you make sure that the metadata will be used for the vertical shift even when using JRiver as a player, as long as the metadata is present in the library for that title? Vertical shift is a key feature on my 16/9 screen.
Thanks and keep up the good work! :)
Once I've resolved these set up questions, I'll do more testing and will report back.
-
There's a thread here you could read. Start at least half way through. It got lots better near the end.
https://yabb.jriver.com/interact/index.php/topic,136378.0.html
Hendrik is our developer. haasn is the author of libplacebo.
There's also a black bar thread somewhere.
-
I think you need Hendrik to answer as I don't believe any of this is documented anywhere. I asked various Q's in this in some threads so will try to summarise
1) I use a DCI P3 with a 2.4 gamma as a baseline for my JVC NZ8. When using JRVR set to P3 / gamma 2.4, the gamut looks right but it looks like there is some black crush (confirmed with the S&M brightness pattern). What are the correct options to get proper DTM? This is without a 3D LUT first. [EDIT: I selected a 30000:1 custom contrast, which is the native contrast of the PJ with the current settings, laser dimming disabled].
Not sure what proper means but ime (JVC n7, dci p3, gamma 2.4) any black point adjustment produces an overly saturated image so I go with no such adjustment (the oled option in the contrast dialog) which dials it down. I suspect this may similarly ameliorate your black crush but not tested that myself.
2) Re 3D LUT, I'm assuming we can use any 3D LUT created for madVR using Colorspace / Calman / DisplayCal, am I correct?
It accepts madvr format lut, it does produce the same output as madvr when configured currently with a displaycal lut (can't speak for the other apps but would guess they are ok too)
If so, can we target gamma 2.4, or do we have to target gamma 2.2 for the LUT to be valid?
I haven't seen it said that there is such a limitation. The 3dlut gamma (tone curve) option should be set to bt1886 though (for me it's not so intuitive but it's what is required to match madvr when using a displaycal generated lut and appears to be independent of any user controlled settings in displaycal)
One point of difference btw is that jrvr does not do anything to the video card gamma table so ensuring the contents of this is left to the user to handle
-
Thank you both.
I'll wait for Hendrick's reply re black bar detection and picture shift.
I'll post in the other thread re the gamma and DTM issues.
-
Happy to report that I've resolved my set up issues (it was a levels mismatch).
Any chance to get a reply from Hendrik re the vertical picture shift feature related to black bar detection?
1) will it work when JRiver is used as a player rather than a front end, provided the title is in the library and the black bars have been detected during import? I use JRiver with CMC
2) any ETA for this feature?
thanks!
-
Just installed V31 and started playing with it.
First of all, congrats on the progress on JRVR, the DTM has much improved.
I have a few questions:
1) I use a DCI P3 with a 2.4 gamma as a baseline for my JVC NZ8. When using JRVR set to P3 / gamma 2.4, the gamut looks right but it looks like there is some black crush (confirmed with the S&M brightness pattern). What are the correct options to get proper DTM? This is without a 3D LUT first. [EDIT: I selected a 30000:1 custom contrast, which is the native contrast of the PJ with the current settings, laser dimming disabled].
2) Re 3D LUT, I'm assuming we can use any 3D LUT created for madVR using Colorspace / Calman / DisplayCal, am I correct? If so, can we target gamma 2.4, or do we have to target gamma 2.2 for the LUT to be valid?
3) Re vertical shift for black bar detection, it's great to see that you plan to add this feature. Two questions about this: 1) Any ETA for this to be implemented and 2) I understand that the black bar detection is done offline to save processing time, when adding the files to the library. I use JRiver as a player with CMC as a front end. Please can you make sure that the metadata will be used for the vertical shift even when using JRiver as a player, as long as the metadata is present in the library for that title? Vertical shift is a key feature on my 16/9 screen.
Thanks and keep up the good work! :)
Once I've resolved these set up questions, I'll do more testing and will report back.
I have found that BT.2020 gamma 2.2 seems to work best for me on my RS3100. No LUT in use. No clipping on white or black, verified with test patterns. All PJ settngs default.
P3 gave me a darker image and clipped blacks as well I could improve with brightness / contrast adjustments in the NVidia CP.
-
I have found that BT.2020 gamma 2.2 seems to work best for me on my RS3100. No LUT in use. No clipping on white or black, verified with test patterns. All PJ settngs default.
P3 gave me a darker image and clipped blacks as well I could improve with brightness / contrast adjustments in the NVidia CP.
Thanks, but as I said in my previous post just above yours, my issues were entirely due to a levels mismatch issue. With P3 / gamma 2.4, I get the expected picture and there is no need to make any adjustments anywhere. No shadow details loss and no highlights clipping.
I am using the native gamut in my rs3100 (profile off / filter on) as a baseline, which is tracking very close to P3 (I calibrate with a C6 profiled to an i1pro2), and gamma is calibrated to 2.4 precisely using an internal 1D LUT, so there is no doubt that these are the correct values here and that the software is working cas intended with the correct levels and matching settings. Now that the setup is correct, I’ll try a 3D LUT.
You can only use P3 if you use the native gamut or the DCI profile. If you haven’t measured your gamma, there is no way to know which one to use, as the factory presets can be significantly off if you haven’t autocaled them recently.
Very impressed with the DTM in JRVR in MC31 (build 36), it’s a huge improvement over the previous versions.
-
Thanks, but as I said in my previous post just above yours, my issues were entirely due to a levels mismatch issue. With P3 / gamma 2.4, I get the expected picture and there is no need to make any adjustments anywhere. No shadow details loss and no highlights clipping.
I am using the native gamut in my rs3100 (profile off / filter on) as a baseline, which is tracking very close to P3 (I calibrate with a C6 profiled to an i1pro2), and gamma is calibrated to 2.4 precisely using an internal 1D LUT, so there is no doubt that these are the correct values here and that the software is working cas intended with the correct levels and matching settings. Now that the setup is correct, I’ll try a 3D LUT.
You can only use P3 if you use the native gamut or the DCI profile. If you haven’t measured your gamma, there is no way to know which one to use, as the factory presets can be significantly off if you haven’t autocaled them recently.
Very impressed with the DTM in JRVR in MC31 (build 36), it’s a huge improvement over the previous versions.
Good to hear. If you haven't run across these before https://drive.google.com/drive/folders/1m4IBq0euAxamL9ePgfdFuf8_5nLcRwHA (https://drive.google.com/drive/folders/1m4IBq0euAxamL9ePgfdFuf8_5nLcRwHA) there is some Test footage there that probably represents the worst case clipping scenario. It's in 09. Test footage.
-
Good to hear. If you haven't run across these before https://drive.google.com/drive/folders/1m4IBq0euAxamL9ePgfdFuf8_5nLcRwHA (https://drive.google.com/drive/folders/1m4IBq0euAxamL9ePgfdFuf8_5nLcRwHA) there is some Test footage there that probably represents the worst case clipping scenario. It's in 09. Test footage.
Thanks, I haven't done any extended tests with tricky content yet, but I will now that JRVR is set up properly.
-
Hello,
Is it possible to explain how to use the new HDR functions in JRVR ? (wiki not updated yet...). With usecases for projectors would be great ;D
-
Hello,
Is it possible to explain how to use the new HDR functions in JRVR ? (wiki not updated yet...). With usecases for projectors would be great ;D
I second that. I would like to use JRVR-tone mapping for both an oled and projector, but keep going back to madVR because I'm not sure what settings to use.
-
There are hardly any settings and no one knows what an individual system is doing so you probably just need to ask specific questions instead and/or just try it
-
At least they should explain the product they are selling.
-
Please see the wiki.
Accept defaults if you need to. It's not complicated.
-
I second that. I would like to use JRVR-tone mapping for both an oled and projector, but keep going back to madVR because I'm not sure what settings to use.
Here in the same situation. I'm trying the trial version, but I can't find information to set up JRVR to get betters results with a JVC X7000 model. I would like to know what values to set in the tonemapping section.
-
I'm almost newby in JRVR and MadVR, but this is my configuration for HDR :
>use the display's HDR capability -> No
>Target Peak Nits -> 70 nits (what I read with my x-rite idpro)
>Target SDR contrast -> 10000:1
>Enable HDR to HDR tone mapping -> yes
>Reduce gamut to DCI-P3 -> yes (but for what JRVR is sending REC709 to projector)
>HD to HDR Target Peak Nits -> I don't understand what it is - I left it like that
>Enable contrast recovery -> I left 0.4 (I don't really see any change... Does it change gamma for darkest areas?)
My setup is a JVC X7900, fed by a PC with RTX 4070Ti, in a dedicated room (fullblack). Screen is a white microperforated - basis 2.6m
Further comments would be really appreciated :)
-
Quick question: wasn't there an option to limit HDR subtitles brightness at some point? I can't find it anywhere.
-
>Target SDR contrast -> 10000:1
it's a dark room with a capable projector so it's likely you should go higher, what's your normal gamma target for SDR?
>Enable HDR to HDR tone mapping -> yes
>HD to HDR Target Peak Nits -> I don't understand what it is - I left it like that
set to no and that 2nd option will disappear
>Reduce gamut to DCI-P3 -> yes (but for what JRVR is sending REC709 to projector)
set to whatever your pj is set to display
>Enable contrast recovery -> I left 0.4 (I don't really see any change... Does it change gamma for darkest areas?)
entirely subjective preference so up to you
idk how contrast recovery is implemented in jrvr but in other renderers it operates a bit like a sharpening filter (not implemented as such but the effect is probably most intuitively that way)
-
Thanks Mattkhan for your answer!
remaining questions :
>About contrat : My gamma target is 2.3, but what does it change?
>If I disable HDR to HDR tone mapping do I lose the DTM ? (Or I misunderstood something...)
-
HDR to HDR settings only matter if you have HDR pass-through enabled, otherwise you just use HDR to SDR. In fact in the next update those settings will be hidden if pass-through is disabled to improve clarity.
-
OK thanks Hendrik. The usecase is for people who are using HDR on their projector but want to use HDR DTM of JRVR instead of the DTM of their projector? right?
-
Quick question: wasn't there an option to limit HDR subtitles brightness at some point? I can't find it anywhere.
Bumping this...
-
I just wanted to point out that bjin has recently updated the RAVU shaders and added an Antiring version that you may want to add or update.
https://github.com/bjin/mpv-prescalers
Also Artoriuz recently updated this:
https://artoriuz.github.io/blog/mpv_upscaling.html
And created a couple Bilateral chroma shaders of his own that are light as a feather.
https://github.com/Artoriuz/glsl-joint-bilateral/releases
I like like using this image from madVR Doom9 forum years ago cause you can see the chroma quality when upscaling massively and how well everything is working together
https://file.io/ZNcFlMyjFbzQ
I've been jumping back and forth between JRiver and mpv for testing all the work taking place.
-
there's an update to the geometry correction filter which would be good to pick up -> https://www.avsforum.com/threads/free-geometry-correction-for-curved-screens.3233423/page-2#post-62775538
-
Im using the latest version with my pj in a dedicated black room.
So I should choose a very high target sdr contrast setting?
I just checked. The native contrast of the pj should be between 25000 - 33000. but if I try to change the target sdr contrast while using the user setting I could insert for example 28000 but after I save the setting and get back to the settings my values I entered are gone.
-
Don't put in the ":1", just the raw value, it might not parse properly otherwise
-
Thanks Hendrik. I did try putting only 28000 but it also disappeared after saving. The field is blank after I came back to the settings.
-
Thanks Hendrik. I did try putting only 28000 but it also disappeared after saving. The field is blank after I came back to the settings.
Mine does exactly the same as yours so I dont bother to use the manual settings. Mine has been like that since that section was first introduced.
-
Fixed that issue for the next build. It still works setting a custom value right now, it just doesn't display.
-
I just wanted to point out that bjin has recently updated the RAVU shaders and added an Antiring version that you may want to add or update.
https://github.com/bjin/mpv-prescalers
Also Artoriuz recently updated this:
https://artoriuz.github.io/blog/mpv_upscaling.html
And created a couple Bilateral chroma shaders of his own that are light as a feather.
https://github.com/Artoriuz/glsl-joint-bilateral/releases
I like like using this image from madVR Doom9 forum years ago cause you can see the chroma quality when upscaling massively and how well everything is working together
https://file.io/ZNcFlMyjFbzQ
I've been jumping back and forth between JRiver and mpv for testing all the work taking place.
there's an update to the geometry correction filter which would be good to pick up -> https://www.avsforum.com/threads/free-geometry-correction-for-curved-screens.3233423/page-2#post-62775538
Thanks, I'll look into updating some shaders this week. And also enable the new anti-ringing in libplacebo that the RAVU AR is based on.
-
Thanks, I'll look into updating some shaders this week. And also enable the new anti-ringing in libplacebo that the RAVU AR is based on.
great thanks
assuming this info is readily available, would it be possible to add the small details mentioned in https://yabb.jriver.com/interact/index.php/topic,136378.msg948822.html#msg948822 ? would be useful to know which value is displayed currently too
-
This data is not exposed by libplacebo, unfortunately. The only place anything of that shows up is in its render feedback, eg. what the performance status lines are made from, and thats pre-formatted text.
-
I have a (probably) dumb question: what do advanced scalers (such as fsrcnnx) do when displaying a 4K video on a 4K screen?
You'd assume it does not kick in at all, since there's only chroma to upscale.
What am I missing?
-
Upscaling does not engage when there is no upscaling to do. Nothing to miss!
The settings of course don't know what kind of video you are going to play.
-
Seems logical 😅
I asked because I had a weird bug the day before yesterday, I'm pretty sure FSRCNNX 16 kicked in with a 4K mkv on a 4K screen (LG 65C2). I saw it on Ctrl+J timings and because the picture heavily stuttered, probably because doubling 4K was a bit tough on my system.
Can't seem to reproduce it though. So everything's fine ;D
-
Forgive my ignorance, but I would like to understand something more about Dolby Vision.
Let me start by saying that I use a projector and, as I know, at the moment there are no projectors that support DV apart from some USTs.
As mentioned in the past, I had the opportunity to compare my BDMV, which does not support DV, of TOP GUN Maverick with the 1:1 copy in mkv format, and the difference between the two formats was very evident right away.
I therefore thought of converting the BDMV of The Lord of the Rings to mkv too, but in this case the DV in mkv format was not very evident. I also compared the individual frames, but in my opinion they were practically similar.
Obviously I checked the OSD of both mkv files, and the words Dolby Vision appeared in both, unlike the BDMVs.
Could it be due to the fact that Top Gun's DV is 8.1 while LOTR's is 7?
Or JRiver currently only supports 8.1 format?
Or did I make a mistake in making the conversion?
Thanks to those who help me understand (possibly in simple words ;D ).
-
Blu-ray DV should always be profile 7, not sure I saw any other DV on BD. But regardless of that, the difference will of course depend on the mastering of the movie. It might have an impact, it might not. It all depends on what they put in there. Profile 7 also has an (optional) enhancement layer thats not supported yet. 8.1 is only metadata.
-
Thanks Hendrik for the explanations.
In fact Top Gun, among the ones I have, is the only one with Profile 8.1
So at the moment it is not convenient for me to convert BDs to mkv, but to wait for the enhancement layer to be supported.
-
So, I came back to JRiver/JRVR after a few weeks playing again with MPC-BE/madvr.
I noticed that, in NVCP, the "power managment mode" MUST be set to "prefer maximum performance" when using JRiver, otherwhise I get random dropped frames that might or might have not existed a couple of month ago (maybe I just didn't notice at the time... but I doubt that :P).
I have a RTX 3090 which should be able to swallow any JRVR setting. Yet, when the NVCP "power managment mode" setting is set to "adaptive", JRVR render times are way (WAY) higher.
Take a 2160p23 DV file on a HDR 4K screen (LG C2). No luma upscaling (obviously), HDR passthrough (so no DTM), audio bitstreaming. JRVR Settings are default "quality preset" + adaptive sharpen 50.
With "adaptive" : 10ms avg / 20ms to 30ms peak (on OSD... probably a bit higher, of frames wouldn't drop, would they?...)
With "Maximum performance" : 1.4ms avg / 1.5-2.5ms peak
I don't know if it's a driver bug, a JRVR bug, or a nvidia power management "feature". In my untrained eyes, it feels that, even with "adaptive" setting, the GPU should switch to a "performance" state when JRiver is on and actually using GPU power. But it's probably way more complicated than that from a dev point of view :D
I still felt it was worth reporting though :)
EDIT : okay, so it's a super-known issue :D
https://yabb.jriver.com/interact/index.php/topic,136395.msg944765.html#msg944765
Oh well, now there's one more post for dummies like me to find a solution ;D
-
The next build of Media Center will include an update to libplacebo, resulting in a whole bunch of changes in JRVR.
- Improved dynamic tone mapping
The peak detection is now much more responsive, which should result in a more even tone mapping on fast brightness changes in the scene. Additionally, the tone mapping curve has been re-tuned for overall a better behavior.
For easier analysis, the detected peak and average brightness will now be shown on the OSD. - New and improved scaling algorithms
Most scaling algorithms have been tuned for improved performance. And we have two new algorithms, JincSharp, a sharpened version of Jinc, with 3 and 4 taps. And the Hermite filter for downscaling, a very low-cost filter close to the performance of bilinear, but with much higher quality. - Completely re-designed caching
We can now cache shaders more efficiently, as well as caching various LUTs used in rendering, eg. for gamut mapping, or the generated ICC LUT, which should result in a faster startup of the renderer.
Of course these are only the highlights, and many small tweaks and improvements went into this update.
These changes will be available in 31.0.60
-
That's exciting. I look forward to testing them out.
-
Thanks for the great job.
I have a question before starting to test. Is about DV metadata being used. I don't know if the DV metadata is used like LLDV processing in some devices. I mean, a DV tone mapping in a BT.2020 color space done before the frame is sent to the display. I guess that JRVR injects the HDR format info frame so HDR10 compatible frame instead DV frame is sent. So non-DV displays can, at least, get a fully HDR10 compatible frame, but with the DV tone mapping applied.
A bit confused, to be honest, about this.
My display is a 77 inch Samsung OLED TV.
Thanks in advance.
-
DV metadata is used to transform the image into HDR10. The DV tone mapping data to tone map to SDR is not used at this time.
-
DV metadata is used to transform the image into HDR10. The DV tone mapping data to tone map to SDR is not used at this time.
Thanks. Maybe I'm wrong I just know how, by example, Nvidia shield with Kodi Nerds compilation always send DV frames (if DV layer is found in the hevc stream), no matter if display support it or not. Zidoo Z9X also admits EDID editing to use this trick.
But there are two kinds of DV frames it can send.
-) Standard DV frames, are tagged as DV frames and DV metadata is send attached to the frames so the DV display should finally apply a tone mapping/curve before frame is shown. DV color space is used.
A fully DV compatible display is needed for this, since a last step needs to be performed by the display
-) LLDV DV frames, are tagged as LLDV, but player applies DV metadata (tone mapping/curve) before the frame is sent and BT.2020 is used. So the frame sent is basically an HDR10 frame.
A display able to recognize that tag, and/or a display able to interpret those frames, simply, as HDR10 is more than enough. That trick has been used by projectors and non-DV display owners to enjoy DV content without DV displays. At least an HDFury is needed for most displays (adding hdr info frame) since the LLDV frames should be tagged as HDR10. If not, the display won't enable HDR10 and the LLDV frames will be processed as SDR, so wrong image.
https://www.avsforum.com/threads/dolby-vision-including-hdr10-conversion-w-dtm-on-projectors.3097934/
https://www.avsforum.com/threads/alternative-devices-for-enabling-lldv-please-read-posts-1-2.3254266/
Could it be possible to implement this process/profile in JRVR ?
JRVR would be the only product able to play DV files with correct rendering in every HDR10 compatible display without needing more elements.
-
It is not possible to send DV metadata from a PC at this time. You will get a HDR10/BT.2020 image from DV sources with JRVR already, and the DV metadata is being applied to the image to transform it as the DV metadata indicates. This works with any HDR10 screen (or even SDR screens), no DV support is needed.
-
It is not possible to send DV metadata from a PC at this time. You will get a HDR10/BT.2020 image from DV sources with JRVR already, and the DV metadata is being applied to the image to transform it as the DV metadata indicates. This works with any HDR10 screen (or even SDR screens), no DV support is needed.
Thanks a lot.
I guess It's time to test it !!
-
First of all, thank you very much for exposing the libplacebo parameters in the advanced JRVR settings. This is extremely useful.
I think you asked in one of the threads which parameter it might be useful to add to the GUI, and one of them is definitely knee_adaptation=<0.0..1.0>.
The default of 0.4 crushes highlights details in high nits titles with a projector and 100nits peak, and until now the only way to improve that was to lie about the peak nits (bring it up to 200nits for example), which of course had a negative impact on shadow detail.
I'm still adjusting this but I find that raising this value up to 0.7 or 0.8 adds a lot of depth to the picture and brings back a lot of details in some bright scenes (the trade-off being that we lose some brightness of course).
A good scene to test this is the beginning of chapter 3 in Pacific Rim. With the default 0.4, the cloud details in the sky at the beginning of the pan are completely crushed (again with a peak of 100nits). Adjusting to 0.8 brings back a lot of detail and adds depth to the picture. I still have to explore as this might have some drawbacks otherwise, but it's one parameter that I would expose. I'll let you know if I find others. If anyone has suggestions to address this better with other parameters, I'm all ears.
On another topic, I've found that JRVR has a bad brightness fluctuation issue. This is very visible again especially in high nits titles, such as Mad Max Fury Road. Watch chapter 3 for example, and you'll see that the brightness fluctuation is obvious, at least with a peak of 100nits. I tried to enable/disable the slow HDR peak detection option in the JRVR advanced settings, but that doesn't seem to help. I use spline with 0 contrast and no contrast enhancement.
That really needs to get fixed, because in its current state JRVR is not usable due to this brightness instability.
Note that there is no such brightness instability issue with madVR as long as you select the correct settings in the latest test builds (detail threshold = 1, TM curve= Mercury, brightness adaptation speed much higher than the default, at least double each value, and conservative contrast recovery values, up to log low).
-
Note that there is no such brightness instability issue with madVR as long as you select the correct settings in the latest test builds (detail threshold = 1, TM curve= Mercury, brightness adaptation speed much higher than the default, at least double each value, and conservative contrast recovery values, up to log low).
Thanks for the heads up on this. I hadn't tried any of the test builds but I installed it and used the settings you listed here... this has fixed the ultra-dark HDR output I was getting with JRVR and the old MadVR. I get a touch of stutter on 4k HDR files now, but they look a lot better and I'll try to tweak the stutter back out. Thanks again.
-
Thanks for the heads up on this. I hadn't tried any of the test builds but I installed it and used the settings you listed here... this has fixed the ultra-dark HDR output I was getting with JRVR and the old MadVR. I get a touch of stutter on 4k HDR files now, but they look a lot better and I'll try to tweak the stutter back out. Thanks again.
Glad it helped, but let's keep the discussion here on JRVR :)
I only mentioned madVR as it doesn't have this brightness stability issue (with the correct settings).
-
there was more discussion on tm advanced params and curves in https://yabb.jriver.com/interact/index.php/topic,136378.msg951450.html#msg951450
there's a desmos link which shows the behaviour of the curve as you vary these params which you may find useful (or not) to try to relate to what you see
-
there was more discussion on tm advanced params and curves in https://yabb.jriver.com/interact/index.php/topic,136378.msg951450.html#msg951450
there's a desmos link which shows the behaviour of the curve as you vary these params which you may find useful (or not) to try to relate to what you see
Thanks, let's pursue the dicussion there as it might be a better place to do so.
-
Glad it helped, but let's keep the discussion here on JRVR :)
I only mentioned madVR as it doesn't have this brightness stability issue (with the correct settings).
I agree, but it seems like this could be a good model for something that isn't working in JRVR.
-
does the linux build have the same version of libplacebo as windows?
I think yes (both the dll and the so have 338 in the title) but then why don't I have the same avg/peak info in the OSD?
-
Your linux shot does not seem to run peak detect, so it just reports Metadata.
-
Your linux shot does not seem to run peak detect, so it just reports Metadata.
it has the same config as far as I can see, i.e. peak detection is enabled
-
The rendering path is very different, almost looks like it's in some fallback mode. Maybe check logs and/or open a thread on Linux for follow-up.
-
posted in https://yabb.jriver.com/interact/index.php/topic,137445.msg952927.html
-
I just noticed all my monitor specific configuration has been wiped again and then get bit by the same "MC clients don't auto backup their settings regularly" problem as last time.
I do have an older backup (that I took the last time this happened) but is there any way to selectively restore just some particular set of JRVR config? I was thinking of hacking just the snippet the ini files out of the backup zip which is pretty hacky
I think there's got to be a better way to manage this config as that's twice in a few months that the config has been wiped without any intervention on my part (and no clue when it happened so no obvious way to find out). Given it's monitor specific config, this would be plausible but not v helpful behaviour
disconnect a known monitor
restart machine (and/or MC alone)
MC discards any configuration for monitors that aren't connected thus losing all your config
reconnect monitor
restart machine/MC
MC now starts from a blank slate again
it's just a guess, no clue if MC does this
-
it can't be that as I hacked that config back into position, restored the backup and restarted. The profiles are still not present but a new backup does contain that hacked in data.
Now I can see that the monitor id has changed for some reason
[JRVR\\Monitors\\??DISPLAY#JKC9070#5&2cf56480&0&UID372993#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}]
[JRVR\\Monitors\\??DISPLAY#JKC9070#5&27b3c7a3&0&UID372994#{e6f07b5f-ee97-4a90-b076-33f57bf4eaa7}]
just the fragment in the middle (2cf56480&0&UID372993 vs 27b3c7a3&0&UID372994)
where does this value come from?
what can be done to insulate JRVR config from this sort of thing? e.g. I can see that the last token appears to be some form of guid, do we need the other values to form a unique id?
NB: manually fixing the monitor id and restoring was ultimately the way to get back into business, definitely not ideal
-
Windows provides an opaque unique identifier for the screen. We don't interpret it or anything like that, just use it.
MC does not delete any information for missing monitors. Whatever happened in all of those situations likely just caused Windows to change your ID.
-
it's logical but still a pretty terrible user experience to find all your config has completely disappeared, MC hasn't noticed and there's no visible reason for it to have happened given that the visible name of the monitor hasn't changed but you can still hack your way through some internal ini files to recover it if you happened to take a backup :)
e.g. MC could see that a named monitor has been replaced and offer to migrate the config for you, problem solved
in the end, there's an MC bug here because if MC relies on an ID generated by windows for some user config and that id is not stable then MC does not have a stable/reliable approach to managing important config.
-
- Enabling Vulkan rendering on Mac through MoltenVK for improved performance and reliability
Very good news (I use both Mac and Win). Meanwhile I update the license to MC32...
-
Why does VSYNC MEASURED jump all around?
My display via nVidia video driver is set to "120Hz" refresh rate.
G-SYNC is completely disabled.
Doesn't seem to affect anything, but when switching to MadVR it's stable at 120Hz. Used to be in JRVR as well but last few releases I've seen this. Just curious.
-
So, something has been troubling me for a while: the framerate matching option feels a bit... unreliable.
First, there is this bug:
- launch a 23p video file
- The renderer switches the screen to 23 Hz
- pause the video
- Alt+tab to Windows Explorer
- launch another 23p video file (let's say, next episode of your fave TV show)
- The renderer switches to your default display framerate (e.g. 60 or 120 Hz depending on your settings) and does not stay to 23 Hz.
It's not a big deal: i've learnt to completely exit JRiver before starting another video but... annoying.
Then there is the more "general" impression of unreliability. Often, when I launch a file, after a couple of usual blinks and black screens, the display framerate is matched with the movie's, BUT there are these weird, random stutters with dropped frames. Maybe pause and resume playback will fix it. Maybe alt+tab a couple of times will fix it, maybe click your window to bring it into focus will fix it (because, wierdly enough, it is not). Maybe bring OSD with ctrl+j and then hide it will fix it. Sometimes these steps work at random, and the stutter/dropped frames stop, but sometimes they don't, and you need to close your player and start again. Again, not a big deal, but not a good impression either :(
-
Is there any support Dolby Vision straight off of UHD discs yet?
Is there any support for Dolby Vision FEL where it can somewhat repair the image when the HDR10 is poorly encoded and the extra layer's image info can somewhat make up for it?
Thanks.
-
Why does VSYNC MEASURED jump all around?
My display via nVidia video driver is set to "120Hz" refresh rate.
G-SYNC is completely disabled.
Doesn't seem to affect anything, but when switching to MadVR it's stable at 120Hz. Used to be in JRVR as well but last few releases I've seen this. Just curious.
I thought I had fixed this but in the last couple of weeks I'm getting "VSYNC Measured" values jumping around with corresponding video stutter. :( My workaround was to have a script that would minimize all desktop windows then open jriver, go into Standard View mode while the video is starting and playing, then switch to Display View mode and go into Fullscreen. That workaround no longer works. This is occurring even with version 31.0.87, and with latest 32. I have Prefer Maximum Performance enabled in NVIDIA settings for "Media Center 32.exe".
I am at my wits end. I didn't change my video driver (551.46) since February. There were a few Windows 11 updates since then. I wonder if they messed something up?
No problems using MadVR as the video renderer, and everything works fine in MPC-HC using MadVR or MPC Video Renderer (the latter has basic Dolby Vision -> HDR10 support, but no 3DLUT support).
I tested using 1080p and 2160p videos, that have SDR, HDR, Dolby Vision. All do the same thing. Even with all JRVR scaling and processing set to the minimum. HDR tone mapping enabled and disabled. Output at 3840x2160p, VSYNC enabled, GSYNC off.
One interesting thing is that if I play back on my 1440p monitor, the framedrops are less apparent, but still there (using MSI RivaTuner server to show the frame timing).
I think there is a serious problem somewhere - maybe thread is not waking up in time? Shader being recompiled at the wrong time? Shader not being woken up in time? I have no idea.
-
Another data point: if I resize the window in Display View mode (make it smaller) the VSYNC measured jumps around from 50 hz to 120 hz and back again, constantly.
Also, if I pause the video, it will still do it (although I guess this doesn't matter since the timing is probably relaxed when paused). Something to investigate? My hardware specs are probably listed in this thread or similar threads.
NVIDIA 4090 card, any driver version, AMD 7950X3D CPU (also occurs on an Intel i7-9700K with the same 4090 videocard, last year). Windows 11 latest updates.
-
Using RivaTuner OSD to record the stutter, I took a screenshot of the various spikes in the frametimes (these can be seen as stutter, especially if it happens when a person turns their head).
(https://i.imgur.com/gYoMqua.png)
Scene from Shogun 2024, HEVC 2160p Dolby Vision (output as HDR10 in JRVR).
This is on my 2560x1440p display, JRiver output at 120 hz. I put it into a window, which makes the spikes much more frequent. If I go fullscreen it reduces the occurrence of the spikes by 75%.
I told jriver to use the Null Output audio device, to rule out audio driver issues.