Print

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

[Manni]

ok yes I see what you mean, there's an example at approx 28:49 when they first walk in the bathroom. If you pause at that point and wait a little while then the peak nits stabilises to approx 1000nits, if you do this a few times (i.e. 1s jump forward then wait) then you see the following avg/peak nits pattern

8.1,957.9
7.4,99.8
11.1,99.8
15.2,471.1
15.4,489.5
17.4,513.5
24.7,522.5

this dip and rebound drives the brightness change and it occurs about 3-4s after the dip in peak nits and lasts for a second or so before it pops back up so I assume this is some sort of decaying average being applied over some seconds to judge the brightness? I guess it needs some additional logic to guard against short lived outliers which aren't scene changes to fix it which seem like it should be doable.

the nearly 1k nits peak scene is the attached and you can see the peak comes from the light that is outside the room but still just visible, in the next second the door has closed so it's no longer there hence the major reduction in peak nits

I'd agree this definitely would be a good thing to fix, you can make various choices on how to tune it but those give a generally consistent appearance but flickering is in the distracting category which you can't really get away from (once you see it).

Thanks for confirming and looking into this. I'm super sensitive to frame drops and brightness fluctuations, so yes, that's not something I can live with, but many people have more tolerance. That's the first thing I adressed with madVR when I recommissioned my HTPC, and hopefully both can be solved in JRVR as well.

Glad one of the examples I provided showed the issue with JRVR. Now we have at least two clips that cause brightness instability with JRVR, hopefully this will help the devs to fix.

[Hendrik]

ok yes I see what you mean, there's an example at approx 28:49 when they first walk in the bathroom.

Could you cut a short sample of that scene? Preferably as short as can be to reproduce, and long enough to see it of course.

[mattkhan]

 

Could you cut a short sample of that scene? Preferably as short as can be to reproduce, and long enough to see it of course.

I sent a link via email

[Hendrik]

Got it, thanks. Will look at it soon-ish, after I finish some other work.

[Bob Sorel]

I can also confirm this problem...I reported it back on September 10, 2023 with a much earlier build. Here is the quote:

The below observations have held true with builds 42 and 50, the only 2 versions I have tried:

I have a similar (or maybe the same...I haven't done enough testing yet) issue. I noticed very frequent and sudden brightness fluctuations in Love In Taipai, a few hundred over the course of the movie, and when I checked with MPC-HC's Info tool it was listed as "SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible". Since I am not technically educated enough to know whether or not it is the fault of the DTM, I have narrowed down the problem only to JRVR in general, as when I switch to Red October madVR the problem goes away. I planned on doing more testing before reporting this problem, but since this thread was already started I thought I would at least confirm that I have noticed the behavior, though I have not examined enough other content to reach any conclusions.

While I am here, I might as well report another problem I have noticed with JRVR:

When the APL is low AND has no bright elements in it, the graininess of the film increases and actually shimmers at times. Once there is a bright element in the frame, then the graininess and shimmering disappear and the picture once again looks solid. This is very noticeable on a 158" scope screen (167" 16:9), where people with smaller screens might not notice the effect. The "shimmering" can also give the appearance of movement or "crawl". This happens on any video, not just HDR10+ or even with HDR (1080p does the same thing), so I suspect the issue is with the VR in general, not the tone mapping. Again, more testing is necessary. And again, switching to MC's stock version of madVR fixes this problem as well.

I mistakenly thought it was an HDR10+ issue at that time. @Manni, thanks for bringing this issue to the surface and assuring me that I wasn't crazy...

[haasn]

You can make the HDR peak detection settings much less aggressive if you're sensitive to this sort of thing. Possibly, the recent changes (aimed at combating the exact opposite problem) were too aggressive.

That being said, one thing I was wondering about was whether we should be using the N% histogram value instead of the average brightness.

[Manni]

You can make the HDR peak detection settings much less aggressive if you're sensitive to this sort of thing. Possibly, the recent changes (aimed at combating the exact opposite problem) were too aggressive.

That being said, one thing I was wondering about was whether we should be using the N% histogram value instead of the average brightness.

Hi Haasn,

Thanks for this suggestion. Which parameter are you suggesting to change in libplacebo, and in which way? As reported, changing the "Allowed delayed HDR Peak detection" in JRVR Advanced settings doesn't help, and obviously we don't want to lose HDR dynamic peak detection, which enables dynamic tonemapping. These are the only related options I can see in the JRVR interface.

I know this isn't your area, but it might be good to expose this parameter in the GUI so we can find the best compromise or adjust to taste if you've already made changes in the opposite direction. Brightness stability is a top priority for PQ, along with no frame drops, at least for me, because they are the most noticeable and distracting artifacts. Everything else (within reason!) comes second.

In the meantime, we can change the libplacebo parameters in JRVR of course, so please advise which change you have in mind.

[mattkhan]

I think it will be these ones

https://libplacebo.org/options/#hdr-peak-detection

Probably
scene_threshold_low and high in particular

I'll give it a try though I am slightly sceptical this will work for this sort of case and/or seems like something that would be easier to tune if one could record the levels seen by jrvr and then test different filter values offline (rather than via playback which is a slightly slow & laborious process)

[mattkhan]

I couldn't find any difference using those parameters on this scene so I still think it would need a change in the algorithm itself

[mattkhan]

I did some more testing of Jrvr Vs madvr and I would say jrvr is now noticeably flatter than latest madvr, not sure how else to put it, just greater depth/contrast in madvr I think

[Manni]

I did some more testing of Jrvr Vs madvr and I would say jrvr is now noticeably flatter than latest madvr, not sure how else to put it, just greater depth/contrast in madvr I think

Plus a lot more saturation with the latest improvements with StimHK lum method, gamut roll-off and ACES settings.

Personally, I'll need two things to start looking at JRVR again and try to help bridge that gap:
- brightness instability issue resolved (hopefully that won't take too long as Hendrick has confirmed he will be looking into this soon-ish).
- implementation of vertical shift according to black bars / A/R. I can't use a player/renderer that doesn't support this, preferably in real-time as madVR does, so that I can mask a single black bar at the bottom of my 16/9 projector screen. This has been on the MC to do list for a while now, but it looks like most of the work is happening on the audio side of JRiver at the moment, based on the changelog from the last builds, so I hope the video side will get some love again soon (I fully understand that users on the audio side need some attention too). I've worked with the developer of CMC to implement an automatic selection of a picture mode in the JVCs according to the A/R saved in the MyMovies database, it's fully functionmal and will be implemented in the next build early next year. This will allow support for titles not handled by JRVR black bar detection, such as DVDs. But it's a pain to do this for all titles, so really vertical lens shift is needed to be implemented in JRVR. Ideally, JRVR would provide the option to detect black bars in real-time. Yes, it's costly but it's no problem for a recent GPU and so much better than relying on metadata and a lengthy scanning process, especially when you have 3600+ titles and are not using the MC library at all (I only use MC as a player, the metadata is provided by MyMovies and the front-end by CMC on the HTPC and by the MyMovies app on iOS for my Oppo 203 clone and Dune Pro Vision 4K Solo player).

Until then, unfortunately JRVR isn't useable for me, so my motivation to spend time helping to improve it is minimal. It's made great progress in MC31 compared to what I tested a while ago in previous versions, but it still lags behind madVR, both from a tonemapping/PQ point of view at 100-150nits of peak brightness or less and from a functionality point of view (no vertical picture shift, no shortkeys to manually select profiles, no command line exec on profile selection) all things I use for automation with madVR in my projector setup. I can survive without some of these, but not without the two items listed above.

I'm sure JRVR is great for high nits displays, especially if you can use it in HDR passthrough, but it's not there (yet) for a projector setup.

This being said and to be fair, JRVR has less bugs (with an old driver in my case, as HDR passthrough support is broken in recent drivers with my 3090) and is better maintained than madVR, which is a big plus, but only if it's on a par re functionality and PQ.

Once the above two items are fixed/implemented, I'll come back and will be happy to try to help bridge the PQ gap by providing examples where JRVR is still lacking vs madVR.

[mattkhan]

no shortkeys to manually select profiles

Fwiw there are mcws commands to do this now so should be possible to handle this situation if using a programmable remote

[Manni]

Fwiw there are mcws commands to do this now so should be possible to handle this situation if using a programmable remote

Thanks, I've seen this and might dig into it when/if I find the time  but it's still a lot more complicated than simply assigning a shortcut key and a commande line to each profile in the GUI, as is possible with madVR. That's in the WIBNI list though, not in the "can't live without" list

[JimH]

manni,
You've been a lot of help, but sometimes your posts come across as pushy -- more demands than requests.  If you want to live in madVR land, please do it, and without giving us one last ultimatum.

I appreciate your technical expertise and eagerness for progress, but in the list above, Hendrik already gave you a work-around, and mattkahn just gave you another.  That you don't get precisely what you expect is just life.  Live with it.

Niklas and Hendrik have done something amazing and incredibly useful. 

As we say, you're either on the bus, or you're not.

Jim

[mattkhan]

I don't think it's either/or in general, whichever is best overall is the one to use. Currently there are pros and cons to each but, just for HDR on a projector, madvr has definitely taken a marked step forward relative to jrvr in last month or two. It's normal thing really, one lib gets a burst of activity to push things forward and that raises the bar, hopefully jrvr responds in kind in the coming months

[Manni]

manni,
You've been a lot of help, but sometimes your posts come across as pushy -- more demands than requests.  If you want to live in madVR land, please do it, and without giving us one last ultimatum.

I appreciate your technical expertise and eagerness for progress, but in the list above, Hendrik already gave you a work-around, and mattkahn just gave you another.  That you don't get precisely what you expect is just life.  Live with it.

Niklas and Hendrik have done something amazing and incredibly useful. 

As we say, you're either on the bus, or you're not.

Jim

Jim, I didn't put any ultimatum, and I apologise if my post came accross as demands.

Please take all the time you need, or don't do anything, I'm not making any demands. I'm 100% on board with MC, and yes Hendrik and Niklas have done something amazing with JRVR, but this is a comparison thread, so I posted where I believe JRVR is still lacking compared to madVR and why I've (temporarily) paused using it.

I've accepted the old driver workaround as I have no choice, and as I said the solution offered by Mattkhan is about something that's not a big deal for me (shortkeys and command line for profiles). The two biggies are brightness stability and vertical picture shift. Without these, I can't use JRVR. It's as simple as that. Hendrik has already confirmed that he'll be looking into the brightness stability issue soonish (not sure which workaround you're talking about, I haven't seen any from him, Haasn didn't reply when I asked more details on which parameters to use in JRVR in order to fix the issue). Re the vertical shift, I understand that there is no ETA for scheduled features, but it's been a few months now and I have no guarantee that it will ever be implemented. So without an ETA, I'm off JRVR for now.

It's a purely personal position, and obviously not something relevant for anyone without a projector (and most likely a 16/9 screen). Given that it's likely a niche part of your audience, I could completely understand if it was to take years or even was never implemented, but then why should I invest time in a feature (JRVR) that I can't use, when one (madVR) already provides what's missing, and currently with significantly better PQ? It doesn't make sense for me and I hope you can understand this.

For me, brightness stability and vertical picture shift (preferably in real-time) are big deals.

You find me pushy, I find support often dismissive. Often, my feedback is dismissed until/unless one of the "regulars" confirms the issue. It's not very pleasant, even if I can understand. I guess we both have to live with this.

It takes a lot of time to contribute and look into a rendering solution in order to help improve it. I'm happy to do this if it's a renderer I can use. If it's not, I just can't afford the time. My hobby is not to spend time on renderers, my hobby (and my work, I work in film & TV) is to watch content in the best possible way. I hope you'll understand.

I explained why I can't use JRVR at the moment. I'm not demanding anything and I can definitely live without JRVR.

This being said, I'd love it if JRVR could fit my needs better, and I'll be happy to help and contribute if it does.

I don't think one has to choose the land they live in. Competition is always a good thing. I did push for madVR to improve it's saturation, and I did say at the time (publicly) that JRVR was superior in that aspect, so competition is always in the interest of the user. I strongly believe that there is room for both madVR and JRVR, they both have their pros and cons, and I refuse to be in one land or the other, even if I've paused using JRVR for now.

I still use JRiver MC with madVR, and I love MC (it's the only player I use, even if I do so with a different front end). I regularly recommend it, and if it's supported in CMC it's because I suggested it many years ago. Hopefully it's not because I'm (temporarily) off the JRVR wagon that you're going to throw me out of the MC train.

[Hendrik]

Don't worry, I'll definitely try to judge if something is a symptom of a general problem or a singular weird video.

[Manni]

Don't worry, I'll definitely try to judge if something is a symptom of a general problem or a singular weird video.

It's not a singular weird video, it's been confirmed with both Mad Max Fury Road (unless you're discarding my report) and MI6-Fallout (Mattkhan). I'll provide other clips if needed (I've given a list in my previous post, such as Lucy, The Meg, etc), but it's definitely not a one-off, even though it only happens in specific situations. These are the same clips I use to detect (and fix) brightness instability in madVR when present, so I know where to look to make it obvious, it doesn't mean it can't happen in any title.

[JimH]

You literally just said it's an unreasonable expectation (to look at individual scenes)

I wasn't explicit enough for you, apparently.  We don't look at every scene reported.  We don't have the movies.  We don't have the equipment.

Of course we look at scenes.

Matt, it's probably a language problem.

[mattkhan]

Ok fair comment, I misunderstood

[FenceMan]

manni,
You've been a lot of help, but sometimes your posts come across as pushy -- more demands than requests.  If you want to live in madVR land, please do it, and without giving us one last ultimatum.

I appreciate your technical expertise and eagerness for progress, but in the list above, Hendrik already gave you a work-around, and mattkahn just gave you another.  That you don't get precisely what you expect is just life.  Live with it.

Niklas and Hendrik have done something amazing and incredibly useful. 

As we say, you're either on the bus, or you're not.

Jim

One observation and a suggestion.

Yes MadVR has made progress in the last month but if you guys think that is going to ever result in an HTPC version that isn't time limited and capture card blocked once they are done moving things to the Envy than you are incredibly naive.  Everyone is being used as free testers for Envy development and gets to use the HTPC version temporarily while doing so but that will not last forever so those with the knowledge to help JRVR development should do that happily because there is a useable means to an end with JRVR.

There is a potential giant market out there if you guys are able to get JRVR working with the VideoProcessor program.  Everything past MadVR 113 has either timed out or specifically blocks the VP program so dozens / hundreds of users are "stuck" at 113 and would probably jump onboard a program that has active development and is very arguably already better than MadVR 113.  This might be better use of everyone's time right now rather than chasing edge case issues that few even notice at this point.

[mattkhan]

chasing edge case issues that few even notice at this point.

The difference between madvr and jrvr right now on a projector are not edge case issues. It's an obviously better picture overall (on top of some edge case issues to which people have varying sensitivity).

[FenceMan]

The difference between madvr and jrvr right now on a projector are not edge case issues. It's an obviously better picture overall (on top of some edge case issues to which people have varying sensitivity).

I have not tested the newest versions (way too many options) so I will trust what you say.

My point stands though, there is an untapped market out there for a high quality renderer that works with VP. 

[mattkhan]

It doesn't need to work with VP, MC itself can use a capture card already, it just needs improvements to handle HDR. There was already mentioned on some other thread btw.

[FenceMan]

It doesn't need to work with VP, MC itself can use a capture card already, it just needs improvements to handle HDR. There was already mentioned on some other thread btw.

Great point.  I did read the other thread but have not tried yet.  Seems like a little tweaking can make it pretty seamless.  How cool would it be to be able to browse our stored libraries and then seamlessly switch to capture card if we want to watch streaming or physical media.....

[mattkhan]

Going OT a bit but I think MC needs a known compatibility list of capture cards and/or improvements to how it interacts with them. I still use mpc-be rather than MC for this purpose because MC has had problems with cards I have used whereas mpc-be just worked.

[Manni]

I have completed the tests over at AVS Forums regarding brightness stability tests comparing madVR, JRVR and as a control renderer MPC-VR, which I believe is static and fixed at 125nits.

In the last run, I've tested both renderers against the JVC DTM (fw 3.0, HDR frame adapt, frame by frame DTM) because I suspect MPC-VR to be static and not dynamic, so it didn't feel like a fair comparison. I got the same results: the JVC DTM passes all the brightness stability tests that are failed by madVR, JRVR or both renderers.

As you'll see, I've used two different sets of settings:
In post #1 https://www.avsforum.com/threads/brightness-stability-issue-with-projectors-or-low-nits-displays-when-using-dtm-with-jrvr-and-madvr-no-support-questions.3290169/#post-63007530, optimised settings at 108nits DPL and test results. As you'll see, with these settings, madVR passes most of the brightness stability test. When it fails, it can be resolved if it's unstability by disabling DTN (Jumanji) or by raising detail threshold to 10 (Dune), but that's not a fix, it only resolves the clipping, any detail above 1 will cause brightness instability in other clips. JRVR is the worst performing and I couldn't find any fix. The JVC DTM passes all the tests.

In post #2 https://www.avsforum.com/threads/brightness-stability-issue-with-projectors-or-low-nits-displays-when-using-dtm-with-jrvr-and-madvr-no-support-questions.3290169/#post-63007547, worst-case settings at 50nits DPL and test results. With these, many new clips fail with madVR, and the fix is simply to use better settings (optimised ones). With JRVR, the results are the same re number of passes or fails. The JVC DTM passes all the tests.

I attach the results for both sets of settings, please read the linked posts for more information.

If any users or the devs would like to reproduce these issues, you can download all the clips causing brightness stability issues with JRVR in the first post. I would suggest you focus first on the first clips, which are the most offensive/obvious ones from a brightness stability point of view: Mad Max Fury Road (all of Chapter 3), MI6 - Fallout (the whole of the bathroom scene), Jumanji 2019 (two visible issues in one clip, depending on settings).

Madshi has got all the information and is likely to get working on this in the next couple of weeks, so hopefully many if not most of the issues will be fixed in madVR soon.

I hope that you guys can reproduce and improve these results with JRVR as well.

As soon as a developer has made progress with either renderer, I'll re-test with the improved build and will produce updated test results.

[Plutotype]

Which renderer JRVR or MADVR provides better HW efficiency? I mean which provides acceptable HDR to SDR tonemapping ( and color conversion ), downscaling 4K to FHD, but with lower GPU requirements.

- 4k HDR source ( some with single layer DV), mostly 23/24p
- 1080p SDR REC.709 target display
- Notebook level of CPU with integrated GPU ( in my case its Intel HD620 and dedicated Nvidia MX150 )
- rather low quality settings

Tried MPC-HC with madvr and even with the option trade Q for perf option "compromises to tone mapping", the upload and rendering queues dropped to 1-2 frames, which resulted in occasional video stutter. Not mentioning the NB went really hot. Will try JRiver with JRVR later on. What are your experiences in terms of renderer efficiency for such very "basic" scenario?

Thanks

[mattkhan]

acceptable is too subjective to be able to comment imv

madvr can use significantly more GPU than jrvr but, when both are configured reasonably, I find they produce a comparable load on the GPU. Other posters have said they can achieve better results with jrvr with lower powered hardware than they have been able to achieve with madvr though so my guess is jrvr will work for you.

[haasn]

Note that JRVR (and probably also madVR) mainly targets discrete GPUs, and a lot of the shaders may not be particularly optimized for integrated or mobile GPUs. While there is a bunch of low-hanging fruit that we could pursue to try and optimize JRVR more for this use case, it's never been a priority since most users of heavy shaders will be on some sort of discrete graphics PC.

Generally, though, JRVR receives more optimization than madVR (just my personal impression from others' comments in the past), in particular scaling and DTM.

[Hendrik]

I have setup a new thread for MC32 to continue the discussion over here: https://yabb.jriver.com/interact/index.php/topic,138341.0.html
and I'm in the process of analyzing the brightness samples above to see how to improve the peak detection.

[Manni]

I have setup a new thread for MC32 to continue the discussion over here: https://yabb.jriver.com/interact/index.php/topic,138341.0.html
and I'm in the processing of analyzing the brightness samples above to see how to improve the peak detection.

That's great, thanks, lookking forward to discussing in new thread.