Print

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

[Manni]

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).

[Drybonz]

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.

[Manni]

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).

[mattkhan]

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

[Manni]

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.

[Drybonz]

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.

[mattkhan]

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?

[Hendrik]

Your linux shot does not seem to run peak detect, so it just reports Metadata.

[mattkhan]

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

[Hendrik]

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.

[mattkhan]

posted in https://yabb.jriver.com/interact/index.php/topic,137445.msg952927.html

[mattkhan]

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

[mattkhan]

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

[Hendrik]

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.

[mattkhan]

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.

[Karl78]

- 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...

[TheShoe]

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.

[DocCharky]

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 

[crestedporcupinethree]

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.

[rpro]

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.

[rpro]

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.

[rpro]

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).


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.