INTERACT FORUM
More => Old Versions => JRiver Media Center 28 for Windows => Topic started by: datdude on October 07, 2021, 03:35:10 pm
-
[Edit by JimH] -- Red October JRVR was added to build 73. More recent builds are on the Download Page.]
1. NEW: JRVR is available integrated with Red October for Video playback. (Preview)
Working well for me. Nicely done!
It looks like it is tone mapping my HDR movies since my LG is not switching to the HDR mode? They look as good as using MadVR without any careful comparison.
-
JRVR Testing (so far): Looks good! I ran a bunch of test patterns and real content (many side by side with JRVR on one screen and madVR on another)
- Stable and responsive (no hang up or weird full screen stuttering like you can get with madVR)
- GPU Usage: Not a great comparison but it is lower than the madVR settings I use for 3D (40% vs 50%) and the same for CPU and Video Decode
- AV Sync: Perfect on 23.976/50/59.94 (using my existing lip sync settings)
- De-Interlacing: Looks different using test patterns side by side with madVR but on real content it looked identical and was good
- TV Engine: No Issues
- SDR Content: looks correct and the same as madVR
- HDR Content: levels are wrong (as we know HDR is not yet supported)
- Subtitles: Good
- Frame Rate Changes: No issues
- BD Title Playback: No Issues
- BD Full Menu Playback: No OSD (I'm not sure if this should work at this stage)
Summary: A really good preview. Nice and solid and while not complete (missing HDR, and BD Menu OSD support) it is looking like it has plenty of merit as the "default" renderer once complete.
Thanks for the work on this!
Nathan
-
HDR should currently tone map to SDR and look acceptable. If it doesn't, that would be a bug.
Hardware deinterlacing is not currently supported and it'll use YADIF instead
-
....also no issues with playback on "Std" content (1080p / UHD : 4:2:0) as well as higher specked, UHD HFR @ 4:2:2 500mbps, or UHD AV1 clips
-
HDR should currently tone map to SDR and look acceptable. If it doesn't, that would be a bug.
I'm testing on my Win11 Box with HDR ON on the time. HDR Material is OKish but is still visibly different vs madVR HDR. Some parts are mapped OK, but others look oversaturated / blownout. I'll tried to get a comparison screen shot but you can't screenshot HDR accurately. Anyway, the HDR -> SDR tone mapping works OK but is no substitute for HDR.
Hardware deinterlacing is not currently supported and it'll use YADIF instead
Right that explains it. YADIF is fine. I only noticed a difference in the test pattern anyway, not on real content.
-
FYI - Thinking a bit more about the HDR Tone Mapping in my testing, it will be HDR Content --> SDR (Tone Mapped by JRVR) --> HDR (Tone Mapped by Windows 11).... so it is going to look different to madVR that I've set to just passthrough HDR.
-
I would definitely ask to disable windows HDR things when evaluating the tone mapping, who knows how they interact. Passthrough is coming in the future.
There is also a bunch of parameters for tone mapping that can be made configurable, including different algorithms, so once we have options that'll be something to play with. But getting it to work on Windows with Red October and LAV was the priority.
-
...and for a first cut JRVR it is working really really well! I would say it is already a better renderer than EVR + it is cross platformed. You have done a great job in a very short amount of time. ;D
I'll test the tone mapping with Win OS HDR Off shortly (got a vid call coming up).
-
I would definitely ask to disable windows HDR things when evaluating the tone mapping, who knows how they interact. Passthrough is coming in the future.
Lets see if this screen shot works. It's from an HDR Video played with JRVR with both Windows and my monitors set to HDR OFF. It infact looks way way more saturated than the same video played with HDR On (monitor and windows), which only looks a bit off.
There is also a bunch of parameters for tone mapping that can be made configurable, including different algorithms, so once we have options that'll be something to play with. But getting it to work on Windows with Red October and LAV was the priority.
FWIW (and as an aside), I'm not that sold on the frenzy around Tone Mapping (over at the madVR thread anyway) vs Passthough. Sure it is good for low NIT devices like my PJ (in that it is better than what my PJ can do natively... but no longer being a pixel peeper I find my eyes/brain do a pretty good job on their own unless viewing content is side by side). Also most flat panels have a pretty good NIT range already and it will only get better. eg, I'm testing on displays that can run at 1000nits in HDR mode but I run them in "std" HDR mode most of the time anyway.
So, my personal preference would be to get HDR passthrough working first.
-
Hendrik, I've sent you a link to the sample video that I took this screen shot from.
Thanks
Nathan
-
Tone Mapping is important because there is a lot of SDR PC screens and older TVs out there that don't do HDR, and videos are supposed to look well on those.
There is also optional peak detection to properly scale the tonemapping which is not enabled right now.
-
True.
-
After random noodling around, it is a very solid experience. Fast, no glitches, just works. The only other things to add is
- there is no 3D Support that I can see (I'm sure some will ask)
- I oddly miss the Ctrl-J to see an OSD to see what is happening! (weird I know) ::)
-
There will likely be a debug OSD in the future, as it greatly helps debugging/testing. 3D is not currently planned, its more dead every day now, and not very cross-platform.
-
- there is no 3D Support that I can see (I'm sure some will ask)
- I oddly miss the Ctrl-J to see an OSD to see what is happening! (weird I know) ::)
I think we should use ctrl-j for that reason.
And I agree with Hendrik about 3D. It came and went in the 1950's.
Great job of testing and reporting! Thanks for saving the real bugs for later.
-
I agree 3D is dead, Just running through my test files. I don't think there are any real bugs, but i've only tested on one machine so far. I will see how it goes at the other end of the performance scale.... on a Win 10 NUC at some point today.
-
My testing on the NUC7 (i5) did not get far. JRVR is using the GPU but I'm not sure how much as my CPU pegs at 100% and the GPU is around 50% (on a UHD BD HEVC 23.976). Dropping lots of frames. As a comparison EVR also dropped frames (but not as bad) yet madVR (set to Best Performance Profile) has the CPU around 50% and the GPU 95% and was fine.
-
Native/Zero-copy hardware decoding will likely be required for such devices to play properly on complicated content. Using D3D11 decoding should be the most efficient decoding of any of the options available right now.
-
Is that something I can trigger for testing? .... or just wait for now?
-
Might just be personal preference, but the JRVR deinterlacing on 720p broadcast content (Pearl Jam Unplugged) looks significantly better at reducing jaggies than madvr (video mode). Overall much smoother broadcast.
One thing I also realized that madvr has is per file 'black' settings. I have numerous videos where the black level is completely washed out, and if you add a flag to the file name, madvr will set it to your custom black level.
-
The software deinterlacing isn't bad, it is just slow. We'll have to see what we do about hardware/accelerated deinterlacing.
There is no good cross-platform way to access the fixed-function video hardware in GPUs, and the quality is pretty random. Thinking about it, deinterlacing is just fancy upscaling of half a frame each, some scaling algorithms like NNEDI3 actually initially started life as a deinterlacing filter. So we'll see.
Although for low-end hardware the fixed-function deinterlacing might be the only good option, so at least on Windows it'll get hooked into, as thats mostly the expected functionality and offers deinterlacing largely for "free".
-
One thing I also realized that madvr has is per file 'black' settings. I have numerous videos where the black level is completely washed out, and if you add a flag to the file name, madvr will set it to your custom black level.
I imagine that if there will be JRVR customisable per file playback settings, it would be stored in the Playback Info field like other video playback options.
-
One thing I also realized that madvr has is per file 'black' settings. I have numerous videos where the black level is completely washed out, and if you add a flag to the file name, madvr will set it to your custom black level.
This is the first time I've heard about these black level settings: could you link me something to learn more?
-
There will likely be a debug OSD in the future, as it greatly helps debugging/testing. 3D is not currently planned, its more dead every day now, and not very cross-platform.
Its not dead yet in Germany :) ... harder to order for me now, thanks to covid ... Monster Hunter is coming out on 3D bluray there ... and Jumanji Next Level in Australia in 3D
And i still prefer to watch new releases in 3d first if they are available ... its still stunning on LG OLED
Passthrough might be tough due to hardware support ... but if can render it TopBottom or SBS it would be a plus ... and if can do it in 4K - even better
-
Here we go: https://yabb.jriver.com/interact/index.php/topic,130913.msg907597.html#msg907597 (build 73).
For now it's Red October JRVR. The name may change. No new features, but video quality is improved compared to (at least) EVR.
-
Made a quick test with different videos like LG ST. Petersburg demo 114 Mbit bitrate , Sony HDR camp 4k HDR , LG Chess (h265 10bit 62Mbit 59fps HDR) and some of my 29i music concerts. Everything works fine. CPU and GPU usage is much less than madVR, except for the 29i stuff which utilizes more CPU and GPU compared to madVR ->SW deinterlaing, as I understood so far. Picture quality - first impression is like madVR.
Congratulations for MC's new video renderer.
-
There will likely be a debug OSD in the future, as it greatly helps debugging/testing. 3D is not currently planned, its more dead every day now, and not very cross-platform.
hate to read this but it is what it is. please keep madVR support for those of us with massive 3D collections. as a family we enjoy 3D often. a minority I am sure, but as long as you keep it there as-is, we're fine.
-
In Costa Rica 4k 29,97 FPS in the intro JRVR has some micro stuttering compared to madVR where the camera move in the beginning is super smooth. On my desktop monitor the 29,97 are up scaled to 60 FPS.
-
Can you post a reference to the exact video? Even small differences could invalidate such a test, thanks.
-
JRVR with Subtitle mode: Always show subtitles does not show external subtitle
-
- I oddly miss the Ctrl-J to see an OSD to see what is happening! (weird I know) ::)
While waiting to have an OSD showing what's going on, is it possible to choose where to place the current OSD? I should move it within the active area.
I also did some short tests and apart from the HDR with wrong levels, as already said, especially in the highlights, I noticed that the chapter or subtitle change is slower and more jerky than madvr.
Excellent use of the GPU which went from 70% to 55%.
-
Can you post a reference to the exact video? Even small differences could invalidate such a test, thanks.
http://admision2.unap.edu.pe/sugihbareng/costa.rica.in.4k.60fps.hdr.ultra.hd.xhtml (http://admision2.unap.edu.pe/sugihbareng/costa.rica.in.4k.60fps.hdr.ultra.hd.xhtml)
It's not the original link and I could not remeber it. I had it downloaded 2017 to my MC library.
-
Upcoming build 76 supports D3D11 native/zero copy hardware decoding, although it's not being enabled automatically in Red October yet, which will come soon once D3D11 deinterlacing is supported.
Proper integration with D3D11 decoding and deinterlacing should allow even 4k playback on lower end systems, as well as save power.
If anyone wanted to test early, you can use a custom setup with LAV video and turn on D3D11.
Also if anyone is experiencing judder or micro stutters, i need exact video samples to reproduce. Movie or clip names won't do since small technical differences make the difference for such tests. Please also mention which FPS the file has and what refresh your screen is to make sure I test the right things. :) You can also PM me or send a mail with such samples, as needed
-
First impressions on the NUC7 is good! Will post back some details, but 23.976 UHD HDR BD is playing with about 75% CPU & GPU utilisation.
-
Pretty impressive boost in performance on the NUC7.
- 23.976fps UHD HDR BD HEVC plays well
- 50fps UHD AVC plays well!!! (this is a surprise)
- 50fps UHD HDR HEVC is still a bit too much with stuttering but it is "different" to EVR (which is a mess with audio issues as well) and madVR (with it's usual dropped frames). MCVR looks like it is blending the dropped frames, it's not abrupt drops but more of a pulsing of the speed. Still not a great outcome but it handles it better
I however did see some Green Bar issues on letterboxed HEVC UHD BD (eg WW84 - bottom green line in the black bar area) and also on the right had side of DVB-T SD Content - see pics.
-
Can you try one of those vids with issues on another GPU to see if there is something driver related or a generic problem?
-
No green bar issue on a RTX3090. About to test a NUC8 as well.
-
NUC8 was the same in my testing to the NUC7 for both performance and the green lines. I was hoping the NUC8's Intel Iris Plus 655 would give the extra performance bump over the NUC7's 640 to play UHD HDR 50fps material but still not quite enough.
-
The NUC8 was eligible for the Win11 upgrade so I did that and retested (but probably still need to update drivers etc...). Anyway about the same, but if anything a bit better performance on HFR UHD HEVC Video. Same green band issue.
-
The HDR tonemapping can be pretty heavy on the GPU, maybe with pass-through they can do better. Going to dig up my NUC7 today and see whats up with those.
-
If anyone wanted to test early, you can use a custom setup with LAV video and turn on D3D11.
Having made some tests and with the 23p I did not notice big differences apart from the lower use of the GPU (from 55% to 42% even with 4k HDR), while with it I can still view 60p files such as Gemini Man or the various LG demos: I only see a few images at each scene change.
Another small problem I noticed is that MC no longer maintains the zoom settings. Having a 21: 9 screen, I have to use the zoom in case of a 16: 9 file to make it fit within the screen area, but if I stop the movie and then restart it, I have to do the same operation again because the position was not been saved.
P.S. GPU RX 580
-
Having made some tests and with the 23p I did not notice big differences apart from the lower use of the GPU (from 55% to 42% even with 4k HDR), while with it I can still view 60p files such as Gemini Man or the various LG demos: I only see a few images at each scene change.
This is only available in build 76, and not enabled by default until a future build beyond that.
-
The HDR tonemapping can be pretty heavy on the GPU, maybe with pass-through they can do better. Going to dig up my NUC7 today and see whats up with those.
I came to the same conclusion as JRVR can play UHD AVC SDR 50fps material just fine (which is a pretty mean feat) on the NUC. It's the UHD HEVC HDR 50fps that is just a bit too much. But again, it is really a big jump in performance over EVR/madVR opening up modern codecs on such low powered iGPUs. Well Done. Looking forward to seeing what HDR passthrough can do.
-
Got the issue with the green parts figured out as well hopefully, was a simple mistake luckily, and not some driver nonsense. So back to adding deinterlacing and then we can all enjoy D3D11 native decoding
-
This is only available in build 76, and not enabled by default until a future build beyond that.
+ you also then have to do the following if you want to test
1) register LAVVideo.ax in C:\Users\[USERNAME]\AppData\Roaming\J River\Media Center 28\Plugins\lav64 with an elevated cmd prompt running "regsvr32.exe LAVVideo.ax"
2) in MC --> Tools --> Options --> Video you can then select "Video mode: Advanced - Custom" and start with "Red October JRVR" then "Add" Video decoder: LAV Video Decoder --> Configure and make sure that "Hardware Decoder to use" is "DSD11" as per the pic
-
Got the issue with the green parts figured out as well hopefully, was a simple mistake luckily, and not some driver nonsense. So back to adding deinterlacing and then we can all enjoy D3D11 native decoding
Great! Was it just a scaling issue?
-
+ you also then have to do the following if you want to test
1) register LAVVideo.ax in C:\Users\[USERNAME]\AppData\Roaming\J River\Media Center 28\Plugins\lav64 with an elevated cmd prompt running "regsvr32.exe LAVVideo.ax"
2) in MC --> Tools --> Options --> Video you can then select "Video mode: Advanced - Custom" and start with "Red October JRVR" then "Add" Video decoder: LAV Video Decoder --> Configure and make sure that "Hardware Decoder to use" is "DSD11" as per the pic
That's exactly what I did :(
-
Any info on how the tonemapping works? For example, how does it know what to compress down to?
Do you plan to support anamorphic lens in this round btw? ie black bar detection and zoom to a specific ratio
-
That's exactly what I did :(
But you don't have build 76 yet.
Any info on how the tonemapping works? For example, how does it know what to compress down to?
It just targets reference SDR levels for now. Options will be available later.
Do you plan to support anamorphic lens in this round btw? ie black bar detection and zoom to a specific ratio
Not anytime soon, thats rather niche and would come after a lot of other things.
An alternative however would be that one of the external tools for MC get adapted to do that. Aspect Ratio/Zoom overrides are just stored in a library field, so if a tool were to do black bar detection and then appropriately update the field...
-
Not anytime soon, thats rather niche and would come after a lot of other things.
An alternative however would be that one of the external tools for MC get adapted to do that. Aspect Ratio/Zoom overrides are just stored in a library field, so if a tool were to do black bar detection and then appropriately update the field...
ok so MC can do this already if told to do so? I hadn't look for that given I use madvr for that purpose so far
-
Yes, MC can reposition the video window any way you like, cutting off black bars etc. These settings are saved in the library, so its setup once (or setup externally). These settings are not available on Linux/Mac yet, but are implemented there, and will come in the next update. There is just no automation to get the right values - and of course you might have issues if you mix different screens.
There are potential issues with subtitles as I don't think it moves them into the visible section then, but subtitles are due for some reworking at some point.
-
Different screens would be a problem. Is it feasible to extend the mcws play command to take additional parameters to see such valurs on a per play basis? Or extend the library field to allow for per client settings?
-
I'm not in front of these right now, but I believe there are options to specify the cut-off for black bars only (ie. re-specifying the source rectangle), without forcing the image to change - which would allow the image to expand if your resolution allows it (eg. if the resolution is wider then 16:9), without causing issues on a normal 16:9 screen.
That is if your anamorphic setup actually uses a wider resolution in some fashion. If its just using image manipulation on a normal resolution that wouldn't work, but I have no experience with such setups.
-
In my case I use a 1.33x horizontal expansion lens which means zooming after the blacks bars are eliminated and then the lens stretches it back out to the correct AR. A more general solution will support different scaling ratios to support different lens.
-
FYI I added Black Bar detection / crop factor to SOT - https://yabb.jriver.com/interact/index.php/topic,106802.msg904848.html#msg904848
-
But you don't have build 76 yet.
If anyone wanted to test early, you can use a custom setup with LAV video and turn on D3D11.
It seemed to me that the test could be brought forward
-
No, you can test with build 76 and the manual instructions, or an even later build when its all fully integrated. But build 76 is available publicly now, so you can do that now.
-
I'm not in front of these right now, but I believe there are options to specify the cut-off for black bars only (ie. re-specifying the source rectangle), without forcing the image to change - which would allow the image to expand if your resolution allows it (eg. if the resolution is wider then 16:9), without causing issues on a normal 16:9 screen.
can you point me at the options for this pls? it's not obvious to me which fields control this.
-
Right Click during Playback, the Window menu. If I take a typical cinema movie in 2.35:1 with letterboxing (eg. 16:9 in 1920x1080 or 3840x2160):
- Crop Black Bars -> 2.35
- Crop Black Bars -> Untick "Crop Sides of Video to Fill Screen"
This should just allow the video to fill the screen if there is room without any bad cropping or scaling.
In some tests I've had aspect ratio issues, but right now I can't reproduce them anymore. Otheriwse Override Aspect Ratio is there to resolve those.
This entire sizing logic is not new to JRVR, its been in MC a long time for DirectShow playback.
-
...and from memory those settings are then saved into the "Playback Info" field and used for later playback. You can also copy these settings to similar videos.
-
Download v76 and do some short tests.
- zoom settings are now correctly saved.
- the tone mapping seems improved, but I need to verify better
- 60p files are played correctly, but a green strip has appeared at the bottom as indicated by jmone.Edit: only in case of custom setting, while if I let JRVR do everything automatically, no green strip appears, but the movie goes jerky as before
Thanks guys for the work you are doing
-
So far, so good on my R1505G (https://www.cpubenchmark.net/cpu.php?cpu=AMD+Ryzen+Embedded+R1505G&id=3486). I haven't thrown any super high bitrate stuff at it yet, but I've been using it to play 2160p h.265 hdr remuxes and 1080p h.264 files. I've noticed some microstuttering w/ certain files but I want to do some more testing before I can help diagnose.
Pretty amazing, this is a real game changer. When I have some more time I will start testing it out on Linux + Wayland.
-
Hardware decoding should hopefully function without glitches now, and deinterlacing is done in hardware, both for software decode and D3D11 hardware decode (for what its worth, a feature madVR for some reason never bothered to implement, which is why D3D11 decode never saw widespread use there)
V77 Testing (yet to be posted on the main board) on the NUC7
- No need to use Custom mode anymore
- Green Line issue fixed
- Deinterlacing looks good, 1080p(i) --> UHD Scaling works nicely
- Can play (just) up to UHD HDR BD 23.976 with tonemapping, or UHD BD 50fps (not HDR / Tonemapping). Can not play UHD HDR BD 50fps without dropping frames
So, it is pretty amazing that such a low powered and old iGPU can now handle a wide range of content. One thing I would say is that you can not run anything else at the same time, even having Task Manager up (to see GPU / CPU utilisation) tips my NUC7 over the edge and I start to get dropped frames and out of sync audio on some material.
A job really well done and it will be interesting to see JRVR goes on newer NUCs etc.
-
Rereading the latest posts, I had a question: does JRVR work on the GPU, as happens with madvr, or on the CPU or on both?
-
No (sufficiently advanced) video renderer will ever work on the CPU, its just not possible. CPUs are not fast enough to do that.
Of course there is always some work thats done on the CPU, as is with everything, but no image processing or the likes should happen there.
On Windows JRVR uses D3D11 to use the GPU, on Linux/Mac it uses Vulkan or OpenGL. Technically it could also use Vulkan on Windows, but that would disable D3D11 decoding and deinterlacing features (at least for now), and there is no real major reason to switch either.
-
Thanks for the explanations. So in the case of IdVR, it uses the integrated GPU, correct?
-
Of course.
-
Good! :)
So, given the current prices of the GPUs, it will be worthwhile to take the upcoming IdVR.
I wait to know all the specifics. For me it would be interesting, among other things, also that it had two HDMI outputs to connect one to the receiver (just audio would be enough) and the other to the pj.
-
This is an pretty cool new feature of JRiver. It looks good as long the brightness of the film is in a lower range. If you look at Films like the Shallows you have very big clipping problems.
I hope there will be a solution in the future for brighter films.
-
I too see some SDR tone mapping issues on HDR material but keep in mind, it's only a preview so far. Just the base platform is in and working. All sorts of stuff still to be done, such as overlays (for BD Menus), HDR Passthrough (instead of HDR to SDR tone mapping), menu to control options etc etc etc. Who know (well Hendrik does) how it will evolve over time.
I'm pretty impressed how usable it already is. I'm especially surprised at how well it does on low powered iGPUs and that the core is now cross platform. I can certainly see JR switching the default renderer to JRVR on all versions of MC offering a good quality "just works" on a wide range of HW over EVR etc. How it goes replacing madVR will depend on what features you need vs the JRVR dev path at any point in time. At present I'm still using madVR but I get the feeling that may not last that long!
-
The next build will add a first settings panel, so a few comments on some of those, specifically HDR tonemapping settings.
There are two tonemapping algorithms you can currently choose between, BT.2390 and Hable.
Both of these work much better with proper peak information, so either your file provides good metadata, or you use the Peak Detection option (although disabling that will offer good performance benefits on low-end systems).
And you can configure the target peak in nits to achieve a more appropriate tonemapping, although reducing the target from the default will amplify any short-comings in the tonemapping, so its not necessarily recommended. But ultimately this option should be set to taste, not some theoretical value.
Additionally, parameters for Desaturation are available. I won't go into the deep math about how they work, but here are two sets you can try:
- Default: 0.9 Strength, 0.2 Exponent.
- Alternative: 0.75 Strength, 1.5 Exponent
Of course you are free to try other numbers as well.
Depending on the content, a mixture of different desaturation settings and the algorithm choice can definitely help with tonemapping results that are too bright.
Other then tonemapping, scaling algorithms are selectable so far. More settings to come.
On a more general note on the settings, the dialog has an "Apply" button which should apply the settings to the active video, so you can pause it, change settings, and hit Apply to see the changes. This works as long as the video is being shown in the active zone.
-
There are two tonemapping algorithms you can currently choose between, BT.2390 and Hable.
Both of these work much better with proper peak information, so either your file provides good metadata, or you use the Peak Detection option (although disabling that will offer good performance benefits on low-end systems).
I recall MadVR at some beta point had video analysed for brightness. It was ditched later in favour of Dynamic Tone Mapping. My guess it was no good for Envy.
But for MC this might be interesting. Maybe measure brightness values between chapters (takes care of complicated scene detection algorithms) ... UHD disc usually have pretty good chapters to separate "scenes" ... granted its not ideal (as chapter might have both bright and dark scenes) ... and its not on par with DTM in term of flexibility ... still beats a hell of a brightness value for whole movie
-
First initial impressions (on a 3090 --> HDR Display) running MC V28.0.78
- Well laid out Menu
- Could we get the ability to access the JRVR Menu through Right Click --> Direct Show Filters --> JRVR like with madVR (as this way you still have Video Playback control, as going via Playback Settings you lose playback control)?
- I'm impressed with Hable over BT.2390 on my Max 1,000nit HDR BT2020/DCI P3 videos. It does not blow out highlights (or make them iridescent) like 2390 (though is "darker" overall).
- I'll need to play more with Strength and Exponent but unless you put in crazy high strength #'s it seems fairly subtle
- Love that JINC is an option (no issues on a 3090) and will see what options work best on the NUC
Let the knob twiddling begin!
-
BT.2390 definitely provides a brighter image overall, and with some adjustments to either peak nits and/or desaturation, you can also minimize the blow out. It's all a balancing act.
That said Hable looks pretty close to the madVR version we are shipping, in brightness too, so maybe that's a better option for now.
New algorithms might appear in the future, as the industry figures out what's best and research gets published.
On a quick side note, both Peak Detect and Jinc use compute shaders to achieve good performance, so performance might go down drastically when those are not supported - and i think Peak Detect just turns itself off.
-
These options will be great to "dial in" different displays, OLED Displays at 500ish Nits, Beamers at much lower Nits, and some LCD Screens at over 1,000 Nits...... or just use Passthrough to let a HDR Display do it's own thing.
You could even make a "generic" selection option for those that don't know their displays' brightness
-
Did some more quick tests on the NUC (one to a LG OLED, the other to a Epson PJ in a dark room)
- I tried all combos of the current settings, these little PCs can not play back tone mapped HDR UHD 50/60fps material without dropping frames. No issues with STD UHD BD however. So unless HDR passthrough helps, it looks like HW upgrade time for me
- With out of the box settings, Hable's tone mapping works far better
- 400nits looks pretty good on the OLEDs with Hable and 200 on the PJ.
I'll have to wait till it is dark here in Oz to crank up the big JVC (with a 1060Ti) and see how that goes.
-
Thanks again for all the testing and reporting. Waiting for dark now.
-
Setting Update on Beta Channel does not load 28.0.78. Have to manually load it.
Is there option to skip video by frame? Minimum i can set now is 5 sec. Nearly impossible to take screen shot of same frame for comparison.
First test Upscaling and Deinterlacing.
Source: US NTSC DVD of Futurama Season 1.
Observation:
Deinterlacing looks same to me in Video mode.
MadVR allows forcing Film mode which in my opinion is better for this particular DVD. Maybe JRVR can have some specific field/tag that allows user to control deinterlacing option (Auto, None, Film, Video)
Upscaling on MadVR is noticeably better for animated stuff ... not so noticeable for films
EDIT: these combing effects only pops in ocassionally ... my guess - bad editing (its even worse for PAL DVD) ... majority of stuff gets deinterlaced properly both in Film and Video mode ... like i mentioned, Film mode seems to hadle "bad" spots better for this DVD
-
Upscaling on MadVR is noticeably better for animated stuff ... not so noticeable for films
Well you are using NGU, alternatives for that will be added at a later point. For now just normal scalers.
As for "film" deinterlacing, what that really means in madVR is that it actually turns deinterlacing off, and tries to do IVTC instead (which is entirely custom). But your file at hand is being detected as a 5:5 cadence, which is usually a sign of bad frame blending during mastering of the disc, or such shenanigans. I don't have any immediate plans for IVTC, but who knows in the future when everything else is done.
Of course that wont save that clip, even the film mode looks bad with the blending of the hand and bottle. If I cared about that content, I would try to offline process it and see if it can be rescued. Thats usually the best choice for old DVDs that don't have a more modern source.
-
Great to hear that alternative to NGU is on roadmap.
I always suspected those combing were mastering problem. IVTC for future would be great. Still have some old DVDs that will likely never see BD release.
Great progress on JRVR ... briefly looked at tone mapping and its great too ... will post observation on those later
PS. any way to skip video frame by frame in MC ... for easier screenshot takes
-
Did some testing and watching of content on my JVC X7500 (1660ti) and it looked great when the JVC was set to SMPTE ST 2084 (though it is a rather convoluted pipeline with JRVR tonemapping HDR to SDR --> Windows 11 then tonemapping SDR to HDR). The result was every bit as good as what I was getting with madVR tonemapping. Good details in the shadows and highlights well controlled. Hable is still my preferred option. I'm looking forward to seeing how HDR passthrough works, or even a SDR --> HDR tonemapping for those of us with HDR displays.
Oddly, I did get periods where the video was dropping frames. A pause/play would settle it down but it's not something I've seen for a long time so I'm unsure of the cause. I bumped the NVidia profile to performance but that did not seem to help.
-
I just installed 77 again. Then I checked for updates and build 78 was there.
-
I just installed 77 again. Then I checked for updates and build 78 was there.
I was on 76 public release ... changed option to beta ...entered password ... and it said i was on latest
-
Glad to hear NGU is on the roadmap. I have lots of 480p movies, mostly black and white, carefully converted from DVD using Handbrake to de-comb, etc. Using madVR, I can get them looking almost as good as Blu-ray on my 4K TV.
JRVR, not surprisingly, doesn't even come close to madVR on 480p. I'm sure that's a low priority, except for people who want to play DVDs from their discs with a decent-looking picture.
I'll be staying with madVR on Windows, but I also have Mac and Linux machines that currently can't do better than VLC quality. it'll be great to have the option of JRVR, so don't forget us 480p folks.
-
From the beginning I had noticed that the image, especially of 4k HDR, was more compact, cleaner than madvr, and today I understood what it was: the almost total absence of video noise.
With madvr I had never been able to remove it, and in the end I thought, since in some films it was more present than in others, that it was a choice of the director, but now I have discovered that it is not so: does it depend on JRVR's best work? Or was it just me who didn't know how to use madvr (I've always used Asmodian's low settings)?
-
From the beginning I had noticed that the image, especially of 4k HDR, was more compact, cleaner than madvr, and today I understood what it was: the almost total absence of video noise.
With madvr I had never been able to remove it, and in the end I thought, since in some films it was more present than in others, that it was a choice of the director, but now I have discovered that it is not so: does it depend on JRVR's best work? Or was it just me who didn't know how to use madvr (I've always used Asmodian's low settings)?
Screenshot comparison would be good ... to know exactly what you mean
In some case "film grain" is part of film "character" ... EDIT: and noise reduction (whether intentional or biproduct of other processing) can "flatten" out the image
-
OK ... did some testing with my OLED E6
I agree that Hable is close to MadVR. But I have some problems.
With MadVR i set target nits at 480. Doing 480 nits for Hable gives similar results where scenes are very bright, but dark scenes gets crushed.
Doing 100 nits for Hable gives similar to my MadVR, but then very bright scenes get "clipped".
See attached (used Batman v Superman for dark scene ... Harry Potter Hallows2 for bright scene)
Similar story with BT (didnt include screenshots ... afraid too overcrouded)
EDIT: desaturation settings were left at default
-
In fact I should have done some comparison screenshots, it was the most logical thing, but I only trusted my eyes.
I then started MC with madvr to make the comparison (I hadn't used it anymore) and strangely the image didn't start (you could only hear the audio). I rebooted, and the image started but as soon as I changed the chapter everything froze: is it possible that JRVR and madvr went into conflict? Or is my htpc having problems?
-
There will be no conflict between madVR and JRVR so it is something else?
-
I have no idea. Tomorrow I take a look at madvr settings and if it still doesn't work I try to reinstall it
-
....well something weird has also happened to me with madVR on my main PC (just went to do comparison pics). On Fury Road I was just getting mostly a black screen with the odd sec of visible video. On other videos it was fine. I also removed my custom madVR version and let MC dowload the shipped version and the reset the setting using MC --> Tools --> Options --> Quality Settings --> Best Quality.
This is one of the reason I'm keen to see JRVR Shine.
-
What is JRVR shine?
-
I agree that Hable is close to MadVR. But I have some problems.
With MadVR i set target nits at 480. Doing 480 nits for Hable gives similar results where scenes are very bright, but dark scenes gets crushed.
I agree that side by side the dark detail in JRVR/Hable is crushed vs madVR/ST2390 (the following is a comparison of both set to 750nits). I also had a play with changing Strength and Exponent but changes are subtle unless you go wild. Keep in mind however that there is no Target Gamut / Gamma options to set yet.
-
What is JRVR shine?
As in do well. I'd personally be very happy with JRVR being the renderer that "Just Works" and produces a great image across a range of equipment without the hair pulling you can get with madVR. Don't get me wrong, madVR is very good but weird things like what I just got with Fury Road leaves your wondering what is going on.
-
What is JRVR shine?
It's a T-Shirt we have in development. Might take a while.
-
I'd personally be very happy with JRVR being the renderer that "Just Works" and produces a great image across a range of equipment without the hair pulling ...
That's the goal. Well said.
-
I'd personally be very happy with JRVR being the renderer that "Just Works" and produces a great image across a range of equipment without the hair pulling you can get with madVR.
This. I've read the entire thread, and, honestly, it's a foreign language to me. I see a lot of 'what's MC doing vs what's the TV doing' and such and often wonder if I'm getting the best out of the HTPC which is using the intel UHD 730 graphics. Everything is at default. MC uses ROHQ. When I switch the TV to the HTPC input, it shows an UHD symbol in the top right, and things look pretty impressive to me and my untrained, ignorant eyes!
I am certain that soon, I will reap the benefits of all this work and heavy testing and wanted to say a massive thank you to all involved in that time consuming process, which although hard to follow, is still fascinating to watch unfold.
-marko
-
I noticed the settings dialog is not saving settings per zone, i.e. change in one zone, switch the zone dropdown to another one, reopen the settings dialog, the settings are as per the previous zone. Not sure if intentional or just not implemented yet but thought I'd mention it in case it is meant to be per zone already.
-
Its not meant to be per zone currently. I have not decided yet what to do about that, since once it gets down to it, people might also want more flexible options per-file or more generically depending on various file properties, and conversely zones might be for different audio devices (headphones vs speakers, or such) but for the same display, so its all not a great fit, and ZoneSwitch also doesn't have enough information to fully represent all video properties relevant for such decisions (which are only available during playback).
So I was considering a profile system driven by expressions to select the current one, or something like that, but thats for later.
-
So I was considering a profile system driven by expressions to select the current one, or something like that, but thats for later.
that would be nice
fwiw it sounds like a similar problem as we have now with per file (audio) DSP configuration (where you often want to be able to use some base config and then customise certain aspects on a file basis), might be nice to solve this for video and then later apply that to DSP.
-
Its not meant to be per zone currently.
Then maybe this is why madvr no longer works for me.
I have created a new zone for JRVR, which I activate manually after disabling the switch so when I switch to the zone with madvr, obviously something remains of the zone with JRVR.
(but maybe, as an ignoramus, I'm talking nonsense) :(
-
Only the JRVR settings are not per-zone, selecting between madVR and JRVR should not be impacted from that.
I routinely switch between all three options for testing, and have not noticed any issues.
-
The new release solved the problem:
In Costa Rica 4k 29,97 FPS in the intro JRVR has some micro stuttering compared to madVR where the camera move in the beginning is super smooth. On my desktop monitor the 29,97 are up scaled to 60 FPS.
I have switched my Workstation & Media Renderer in the Living Room now to JRVR. So far no issues. Quality is on par or even better than madVR. In Alien 1 there is less noise compared to madVR (GTX 1070). In my music concerts movement of artists is great - no latency issues.
If using Jinc for up-scaling 29i ripped blu-ray's JRVR requires also some beefy GPU but much less utilization than madVR.
Great work!
-
Split terrym's Problem with Bad Files (https://yabb.jriver.com/interact/index.php/topic,131034.0.html)
-
In Alien 1 there is less noise compared to madVR (GTX 1070)
Is it UHD version of Alien? ... Which JRVR you using - Hable or BT? ... By noise - you mean film grain?
-
Is it UHD version of Alien? ... Which JRVR you using - Hable or BT? ... By noise - you mean film grain?
It's BD Version. No - In the scene at 58:00 it's really noise in the movie.
-
It's BD Version. No - In the scene at 58:00 it's really noise in the movie.
Is it Director's cut or Theatrical?
I need to dig through my boxes for BD version as I have replaced it with UHD version on NAS.
If its excessive film grain that was present in original disc ... and video renderer removed it without user telling it so ... i would be a bit worried
PS. MadVR also have noise reduction option ... but from what i recall its quite expensive operation
-
Screenshot comparison would be good ... to know exactly what you mean
In some case "film grain" is part of film "character" ... EDIT: and noise reduction (whether intentional or biproduct of other processing) can "flatten" out the image
I fixed madvr so I was able to take a couple of comparison screenshots.
The movie is Joker in which undoubtedly the director wanted a bit of video grain on purpose. With madvr the image seems more detailed but with more video noise, with jrvr less detailed but with equally less video noise.
[img width= height= alt=madvr" border="0]https://i.ibb.co/G07f2Rv/madvr.png[/img] (https://ibb.co/G07f2Rv)
[img width= height= alt=jrvr" border="0]https://i.ibb.co/s95PSfG/jrvr.png[/img] (https://ibb.co/s95PSfG)
-
I fixed madvr so I was able to take a couple of comparison screenshots.
The movie is Joker in which undoubtedly the director wanted a bit of video grain on purpose. With madvr the image seems more detailed but with more video noise, with jrvr less detailed but with equally less video noise.
[img width= height= alt=madvr" border="0]https://i.ibb.co/G07f2Rv/madvr.png[/img] (https://ibb.co/G07f2Rv)
[img width= height= alt=jrvr" border="0]https://i.ibb.co/s95PSfG/jrvr.png[/img] (https://ibb.co/s95PSfG)
I assume this is HD source too ... upscaling to 4K
I also assume you using NGU fot MadVR. That scaler is sharp. And imho is one step ahead of Jinc (thank god, Hendrick is working on alternative).
JRVR atm uses Jinc ... which by itself is an excelent scaler ... but produces softer results ... film grain gets soften out too ... which kinda looks like DNR producing "cleaner" but softer/"blurrier" image.
Its possible with MadVR to use NGU then set in postprocessing to reduce noise ... results are excelent (albeit not too my liking ... as i prefer film grain), but needs powerful GPU as i recall noise reduction is quite costly computationally in MadVR
-
Sorry if I haven't provided more details. The file is not an upscaled HD, but a 4K. Also on madvr I use Jinc because for my Rx580 NGU it is too much in case of 4k HDR sources.
-
Sorry if I haven't provided more details. The file is not an upscaled HD, but a 4K. Also on madvr I use Jinc because for my Rx580 NGU it is too much in case of 4k HDR sources.
Hmm ... i cannot see grain reduction in this scene from Joker UHD between MadVR and JRVR (both Hable and BT) ... for UHD scaling wont matter much (only chroma channel gets scaled ... that should not be able to blur out grains)
I am on 28.078 beta version though.
-
With MadVR i set target nits at 480. Doing 480 nits for Hable gives similar results where scenes are very bright, but dark scenes gets crushed.
Doing 100 nits for Hable gives similar to my MadVR, but then very bright scenes get "clipped".
Hable is not great for dark scenes, but in bright scenes it "feels" better. On the other hand, BT.2390 seems to perform better in dark scenes.
I'm going to look into BT.2390 and see if its bright scene behavior needs to be improved, because it should definitely be the favored algorithm.
If you are using a specific movie as an example, a clip or at least a timestamp would be nice though. :)
Generally would avoid reducing the target peak below the default of 203 though, as that will only amplify any shortcomings.
Instead of focusing only on Hable, maybe give BT.2390 a try and try to achieve an acceptable result with the target peak.
On one note, who is to say how its really supposed to look, though? :)
If, for example, you compare the SDR Blu-ray of that Harry Potter scene, its also quite overblown in brightness, similar to what you get with BT.2390, and very unlike to what you get from madVR.
-
It is a good point, we should be evaluating what looks good rather than a comparison to how madVR looks, or perhaps comparing it to HDR Passthrough to see how JRVR tonemapping works against the HW tonemapping that the HDR Displays are doing.
At present (for me), I find the blown highlights / oversaturation on BT.2390 to be more noticeable than the poorer black details on Hable. I have also found I end up running way higher than 203 nits (500 or even 750 on screens with higher NIT capabilities).
-
...not wanting to add more
complexity options but any thoughts on ACES filmic tone mapping?
-
I am not expert on tone mapping. And its very subjective on what's look good. Most ppl prefer oversaturated images - thats why demo TV in shops run very oversaturated images.
Without having reference monitor ... its hard for me to say whats right. Thats why i am sticking with comparing with MadVR (not beta ones). I recall MadVR forums compared to HD BD for lack of other references.
The Scenes I am using are from Batman v Superman Dawn of Justice (2016) time stamp 2:30:57
and Harry Potter and the Deathly Hallows Part 2 (2011) time stamp 1:31:36
Overall ... if really watching movie - then my choice will be BT as it handles both very bright and very dark scenes better
Though ... I prefer Hable pictures - gives more details (in Harry Potter screen shots - ceiling has more details in Hable and MadVR). But never know if nit settings gonna cause problem in dark or bright scene. Edit3: and hable seems to preserve hue better than BT.
Edit: JRVR seems to give greenish tint to Harry Potter bright areas - not so noticable in Hable ... but very noticable in BT (similar to what my LG E6 is doing)
Edit2: scratch that i dont see tint in Hable anymore ... at least i think so
-
Comparing against current tonemapping implementations that are thought to do a good job seems a sensible way to approach this overall (e.g. a recent lumagen, fairly recent madvr beta, jvc n series projector) given the absence of a reference implementation. It's probably a fair bit quicker than using subjective preference given the experience of that madvr tonemapping thread. From that it is easy to see that people have different preferences (though broadly appear to fall into a few different camps depending on what they prioritise), that looking at loads of content is important (and very time consuming) and that having a well calibrated display with a known peak output (and sharing this info) is important because you need to know how much work the tonemapping is having to do to judge how it performs.
-
Comparing against current tonemapping implementations that are thought to do a good job seems a sensible way to approach this overall (e.g. a recent lumagen, fairly recent madvr beta, jvc n series projector) given the absence of a reference implementation. It's probably a fair bit quicker than using subjective preference given the experience of that madvr tonemapping thread.
The problem with that is of course if people focus too much on comparing to madVR, we might as well miss a goal of a decent version just because it looks different to madVR. Afterall madVR has spent over two years doing nothing but tonemapping, and we just don't have that kind of time to invest, and we're not selling our tonemapping for 5k a pop. If users are looking for the best tonemapping you can get, madVR will continue to be supported, although you'll likely have to put in the work to figure out how to configure all the parameters in madVR.
I don't have the knowledge (or time) to invent a new custom algorithm, so I have to stick to published research in that field, and lean on other solutions, like the two options being presented here.
From what I can tell so far, the peak detection seems to be a bit too aggressive, if the peak is adjusted a bit then BT.2390 seems quite a bit happier with these bright scenes. So I'm talking with the author of the peak detection to see if there is a flaw we can address, or in the intepretation of the peak data in BT.2390, and see what's what.
For the record, the two BT.2390 screenshots posted above look pretty good to me.
Pass-through is also coming, and hopefully we can make that a reliable solution as well. Although some pre-requisite features are still missing, like overlays, otherwise you would get thrown out of HDR when you change the volume or such, which of course wouldn't be great.
-
The problem with that is of course if people focus too much on comparing to madVR, we might as well miss a goal of a decent version just because it looks different to madVR.
I'm in complete agreement. We're not trying to duplicate madVR.
-
Not sure if supposed to report other than picture quality issues but...
previously selected external subtitles are not drawn if playback is stopped and started again. OSD shows subtitles selected but they are not drawn until toggling subtitles to something other and then back.
-
Not sure if supposed to report other than picture quality issues but...
Functional problems like that are very important. Thanks.
-
Are BT.2390 and Hable to stay? or one of them will be dropped once the better one is identified?
Really like Hable when it works :)
-
Not unless something else proves to be superior everywhere. The problem with Hable is that it almost needs per movie config, if not per scene.
-
Yup Overlays are need to be done, but in my setup (OS HDR always on), I'm not sure that I'd be thrown out of HDR mode when using HDR Passthrought as I "think" Windows will tone map SDR Overlays anyway (just a guess).
-
Overlays also add Blu-ray menus (Windows only), and they avoid disrupting Fullscreen playback, which is the only way to get DWM to leave us alone for proper timing, so definitely coming first :)
-
Perfect! It will also make JRVR feature complete.
FWIW, I did a bunch of testing on HDR Passthrough (madVR) to my 1,000 Nit screens vs Tone Mapping with the same UHD HDR10 HEVC BT2020/P3 DCI @ 50fps 1,000nit clip encoded at 8 & 10 bit with both 4:2:0 and 4:4:4 colour space. My general impressions were:
- On high NIT HDR Displays - passthrough looks the best (there is no need to tonemap, or that the tonemapping done by the Display works well).... though I did not try clips encoded at 4,000 nits.
- There is a bunch of stuttering as the 4:4:4 10Bit clips start to play but it then settles down and I was surprised how much better it looked compared to 4:2:0 (I need to try this on a NUC as I noticed that render times seemed to also drop). I was surprised by this as I had always through we were not that sensitive to chroma (note: the original source is 4:2:2 then encoded in Resolve to either 4:2:0 or 4:2:2)
I feel that ToneMapping is a good / needed solution for those with Low Nit / SDR displays playing HDR Content (and hence why the madVR thread is all about Projectors). The good news could be that as screen brightness levels are pretty good on some models, tone mapping may not be needed, just passthrough.
Looking forward to seeing how passthrough goes and what works better on what setups.
-
Quick (off topic) Q: I thought modern GPUs supported HW Acceleration decoding for 4:4:4 HEVC, but I noticed my test clips all play using the CPU not GPU?
-
4:4:4 decoding is not exposed through DXVA/D3D11, so you can't use it unless you do vendor-specific things.
-
Thanks. Kills that idea off! ... and explains why HW accelerated encode/decode it works in Resolve. The i9 has enough horse power but the rest all flat line.
-
Here is an interesting HDR test pattern video for testing tone mapping - Direct Link to File --> https://drive.google.com/file/d/1yeWp53vi90resQMm_E8ir2TRxntF5qUm/view?usp=sharing , thread https://www.avsforum.com/threads/hdr10-test-patterns-set.2943380/
As the video plays, it ramps up the brightness on the dress so you can see where the clipping happens (and the crush of the dark details in the wall / floor). It also shows undesired tonal changes (like skin tones).
Here are some side by side examples where I had paused the video when the dress is at 1,000nits. In MC I then compared Hable and BT2390 at two different brightness levels (203 and 750nits). I also compared side by side with HDR Passthrough to see which ones look the closest to it (can't post a HDR screen shot unfortunately). Anyway, of the four, Hable @ 203 is the closest in terms of detail and skin tone (though the HDR passthrough version there is a lot more detail in the dress and even down to individual stones in the earrings). Interestingly, ramping up the brightness from 203 to 750nits helps the most on BT.2390 to get highlight detail back but then skin tones looks weird at these brightness levels for both look off.
-
Here is an interesting HDR test pattern video for testing tone mapping - Direct Link to File --> https://drive.google.com/file/d/1yeWp53vi90resQMm_E8ir2TRxntF5qUm/view?usp=sharing , thread https://www.avsforum.com/threads/hdr10-test-patterns-set.2943380/
As the video plays, it ramps up the brightness on the dress so you can see where the clipping happens (and the crush of the dark details in the wall / floor). It also shows undesired tonal changes (like skin tones).
Here are some side by side examples where I had paused the video when the dress is at 1,000nits. In MC I then compared Hable and BT2390 at two different brightness levels (203 and 750nits). I also compared side by side with HDR Passthrough to see which ones look the closest to it (can't post a HDR screen shot unfortunately). Anyway, of the four, Hable @ 203 is the closest in terms of detail and skin tone (though the HDR passthrough version there is a lot more detail in the dress and even down to individual stones in the earrings). Interestingly, ramping up the brightness from 203 to 750nits helps the most on BT.2390 to get highlight detail back but then skin tones looks weird at these brightness levels for both look off.
Interesting, jmone.
I played around with your test clip. Target nits at 600 with peak detection.
Basically took screenshot of clip at 500nit dress and 1000nit dress. Screenshot don't include dress - as its brightness ramp makes everything look darker - but look at the earing with brightness almost as dress.
1. BT - earing gets brighter while everything else stay almost intact - only earing gets brighter (but some details are lost in earings)
2. Hable - earing gets a bit brighter while everything else gets darker (earing details almost stay intact)
It feels like Hable try to preserve details in bright area by not going very bright ... and for viewer to perceive brightness dims everything else
EDIT: feels like BT is only compressing bright area (greater compressin in bright area results in detail lost) while Hable compresses everything (less compression in bright area gives more details there ... but compressing "normal" area results in dimming)
-
Yeah, there are lots of variations that can be used for testing. I picked the 1,000 nit dress as that can be a common HDR mastering spec (but so can 500, 2000, 4000 or ER up to 10000 so take your pick from the relative part of the test clip) which than needs to then be compressed down into a presumably smaller brightness range so I chose the default 203 and also a much higher one at 750 to better match what my screen is capable of but still requiring the mapping of 1,000 nit down to a lower value. I'm not sure that tone mapping of a 500nit scene to a 600nit setting would do anything? ..or is it expanding the range? Also as the MC brightness settings get closer to the nits of the scene then the more the two curves look the same, but I was surprised on the tonal shift.
-
Yeah, there are lots of variations that can be used for testing. I picked the 1,000 nit dress as that can be a common HDR mastering spec (but so can 500, 2000, 4000 or ER up to 10000 so take your pick from the relative part of the test clip) which than needs to then be compressed down into a presumably smaller brightness range so I chose the default 203 and also a much higher one at 750 to better match what my screen is capable of but still requiring the mapping of 1,000 nit down to a lower value. I'm not sure that tone mapping of a 500nit scene to a 600nit setting would do anything? ..or is it expanding the range? Also as the MC brightness settings get closer to the nits of the scene then the more the two curves look the same, but I was surprised on the tonal shift.
I mapped 500 to 600 exactly so there is no change ... to see what non bright area supposed to look ... then crank up to 1000
... and as mention above - BT doesnt alter non bright area (if it does - its not noticable) ... but Hable darkens it - quite noticably
EDIT: in picture i posted ... see some girl's hair highlight details get lost with Hable ... but remain imtact with BT
-
Guessing - BT use some sort of S curve
When target gamma is out ... might remedy Hable darkness ... can't wait to test
-
Anyway, of the four, Hable @ 203 is the closest in terms of detail and skin tone (though the HDR passthrough version there is a lot more detail in the dress and even down to individual stones in the earrings).
Personally, I feel like the skin is way underexposed on anything but BT 203nits. Yes, it loses detail in the dress, and even overexposes it a bit, but the skin looks like skin and actually lit up like you would a proper photo to be. Of course I'm watching this on screens in SDR mode with no specific setup to try to use extra brightness or anything, just setup for normal SDR viewing.
I think that point should be made clear of the expectations. The goal is to provide a good experience when watching on SDR screens. If your screen is bright enough that a target of 750 nits is even reasonable, you should probably just be using pass through. Not designing an alternative for TV tonemapping on HDR screens, but rather something to watch the content on PC screens or older TVs. If you want to replace HDR tonemapping on a HDR screen on your PC, madVR is likely the option you want to go for.
... and as mention above - BT doesnt alter non bright area (if it does - its not noticable) ... but Hable darkens it - quite noticably
Thats why I think BT.2390 is ultimately better, because you don't want your entire image to darken because some highlight gets brighter.
-
This might help in the comparison. I converted the Women in the White dress clip to BT709 using Davinci Resolve to see how they handle it. https://behome.dyndns.info/index.php/s/ZF5Ajj8B6WqoMHA
The dress does eventually blow out at over 1,000nits , but the rest of the frame looks to stay as it should. Pretty impressive and at least gives us what it could look like (eg below is the 1,000 nit dress converted to 709)
-
In looking at them again with the DR version
- The High 750 nit settings just looks poor for both Hable and BT.2390. Not only the the exposure look wrong, but I see a green? grey? colour cast.
- The BT.2390 @ 203nits does look good overall and the added pop to the skin tone is pleasing but the blown out whites on the dress is really poor (and gets worse as the brightest increase above 1,000 nits and there are plenty of high nit content on HDR discs)
- The Hable @ 203nits has a bunch of problems, with the skin tone underexposed and probably even the shadows details on the bottom half of the dress.
If possible I'd take BT.2390 if the blown highlights can be addressed, or Hable if the overall brightness could be increased for tone mapping down to 203 nits. I'm not sure either are fixable at 750nits, but as you say - tone mapping is for low NIT SDR Screens.
It's early days, but I'm thinking / hoping I'll land on JRVR with HDR Passthrough on bright HDR Displays, and JRVR tone mapping on the PJs.
-
If anyone has other problematic scenes (and I have the disc), I'm happy to convert that part to 709/SDR in Resolve for comparison shots.
-
Thats why I think BT.2390 is ultimately better, because you don't want your entire image to darken because some highlight gets brighter.
Atm it does seems so ... that test clip with white dress ... white dress starts at 200 goes up to 10000 then goes down to 200
Through out clip ... BT2390 keeps background (anything not dress and earrings) consistent at same brightness/contrast (if there are changes ... i cannot see it).
Habble ... starts to darken background as dress pass target brightness ... worst: once dress brightness starts to dim - the background ends up slightly darker than what it started with (hard to see side by side ... so post animated gif)
-
Now that's something i didn't expect. Hable has more low light level details.
Blade Runner 2049 ... timestamp 00:04:57
-
The next build enables the target gamut and gamma options, although both should just match your screen and viewing conditions, and can't really be used to dial in content.
Additionally, specifically for Hable there is a new option to control the boost it uses to recover brightness, which could help to obtain a more universally useful image out of Hable (the default of 1.0 disables the extra brightness boost)
With the dress test clip, these settings worked pretty neatly for me:
- Hable
- Max Boost: 3 to 4
- Desat: 0.75/1.5
Without the Desat change, the skin color would somehow feel washed out, especially compared to BT.2390. I have not tested it much yet with pure dark scenes though, but it does seem to do a decent job to preserve perceived brightness more or less in the dress clip, as well as not mess up the Harry Potter scene from before. The dress clip is a rather contrived example however, usually high brightness highlights wouldn't be quite as prominent and image filling in a scene.
Still also exploring ways to improve BT.2390 peak brightness behavior.
Last but not least, you can enable logging of frame times, to help analyse any issues with frame pacing/stuttering/etc. It'll write a neat CSV with all frame times into the log folder so I can see what might be up.
-
28.0.79
Just had a quick look. Incredible. Hable looks almost identical to MadVR 0.92.17 ... Batman v Superman Dawn of justice - no more crushing dark details ... Bladerunner 2049 - inside the house can see couch details well
BT.2390 also improve in Bladerunner 2049
BT.2390 is still not so good at high brightness scenes - details in highlights got lost ... Meg - the beginning helicopter flight ... details in bright skies gets lost - it just a bright patch in the sky (Hable and MadVR can see bright clouds)
Will do screen shot later.
One request - jump behavior in video currently is 5seconds ... near impossible to take screen shot for comparison ... especially in scenes that each frame changes brightness dramatically (Harry Potter Goblet of Fire - graveyard scene fight) ... can we have frame by frame skipping
Great job Hendrik
... also for target Gamut ... can we have DCI-P3?
EDIT: some shots from Meg ... 00:04:55
-
One request - jump behavior in video currently is 5seconds ... near impossible to take screen shot for comparison ... especially in scenes that each frame changes brightness dramatically (Harry Potter Goblet of Fire - graveyard scene fight) ... can we have frame by frame skipping
I think we support frame stepping (at least forward), but not sure JRVR supports that, as i'm not certain whats required to make that work. I can probably implement that, but it'll be after my vacation.
-
I think we support frame stepping (at least forward), but not sure JRVR supports that, as i'm not certain whats required to make that work. I can probably implement that, but it'll be after my vacation.
[SHIFT]+[Right Arrow] works with MadVR but not JRVR :(
Not high priority ... as rather see JRVR improvement
Attached is Meg from 3D BluRay (since its 3D ... its brightness might have been boosted during mastering to take into account 3D glasses)
EDIT: colors "details" looks very similar to Hable with low Desat values
-
- Hable
- Max Boost: 3.5
- Desat: 0.75/1.5
- Target Gamut/Gamma: Auto
- Target Peak Nits: 203
Great work! White dress clip looks good at all brightness levels without blowing out or weirdness in the background / shadows. Very pleasing skin tones (even if a bit more saturated). Did a run through of my 1,000 nit mastered HDR videos and they also looked great. I'm not sure if there is much more to wring out of Hable but this combination certainly produces a very good default setting that few would complain about. If you can tame the BT.2390 peak brightness behaviour it would be a good comparison.
I'll now have a look at some dark content with these settings.
Target Gamut: I did try 2020 and it gave everything an olive cast so went back to Auto (709). As tij suggested, DCI-P3 is probably the widest colour space that realistically can be supported anyway on consumer devices (as I see that UHD BD are typically mastered in 2020 but limited to DCI-P3 for this reason).
-
On dark scenes the difference between the two is more subtle (but using the same Hable setting above for both, just switching between Hable and BT.2390). Hable maybe has a bit more details in the shadow but it does handle the gradients in the highlights better (see Juniors throat). BT.2390 on the left, Hable on the right.
-
again, subtle difference. BT.2390 (on left) has more noise in the clouds and banding around the sun rise over the hills than Hable (right)
-
Target Gamut: I did try 2020 and it gave everything an olive cast so went back to Auto (709). As tij suggested, DCI-P3 is probably the widest colour space that realistically can be supported anyway on consumer devices (as I see that UHD BD are typically mastered in 2020 but limited to DCI-P3 for this reason).
The problem here isn't the color space to use, but what the TV expects. On my LG OLED I have an option to swap between BT.709 or BT.2020 for SDR signals (HDR is always BT.2020, I believe). The output of the renderer has to match that, there is no other options. So if I swap it in the TV to BT.2020, then the desktop gets super oversatured - as expected, but I presume JRVR would look just right if its in BT.2020 output mode (I didn't test that yet, but theory holds).
If you are using Windows HDR, DWM probably expects SDR BT.709/sRGB and converts to HDR BT.2020 for output - hence it expects JRVR to output BT.709/sRGB, like any normal desktop application would, but if you send BT.2020 instead then you get the typical under-saturated look with a slightly green hint - just as if your TV was expecting BT.709 and you send BT.2020.
Presumably Windows can be informed of the gamut you are sending, but thats a task for another day.
I don't know if any TVs can be set to expect DCI-P3. Maybe some slightly older models had that before BT.2020 properly established itself?
The only reason not to use BT.2020, if your TV can accept it, would be to avoid banding in 8-bit signals, due to the much wider colorspace and the same amount of bits. JRVR can't output 10-bit yet.
Its important to remember that both the Gamut and Gamma options are not about the source image, or your preference, its entirely only about what the display expects to be receiving (or if you use Windows HDR, what DWM expects) - and displays will expect BT.709 or BT.2020 - even if they can only display DCI-P3. Unless someone is going to tell me that you can also set your display to expect DCI-P3, then I can add it.
(Gamma can be a bit about preference, to be fair.)
-
Unless someone is going to tell me that you can also set your display to expect DCI-P3, then I can add it.
JVC projectors can and it is the recommended target to use when calibrating (and for 3dlut use) if the option is available to you. It would be good to add it here.
-
@ Hendrik - That makes sense. In resolve you can set a colour space (709 / 2020 / DCI-P3 etc etc) but you also have the option of setting a colour space like 2020 but then limit the range to DCI-P3, which is what most UHD BD have done (given no display can resolve all of 2020)..... & yes I'm testing on Win11 with OS HDR on all the time going to my high nit HDR Screens..... so I'll be seeing a different looking image that others, but it does fix the dropping in and out of HDR mode all the time. Then again, everyone will have a different combo of HW, SW etc etc.
Anyway, did some more testing on dark + high contrast dark / bright scenes (space shots, explosions etc). With the exception of the blown highlights in BT.2390 the rest of the frames look very similar unless I got down to pixel peeping. So for now I'd call the new Hable setup "good" (or "good enough") with your suggested settings for me for tone mapping. I'm sure there are endless variations and knob twiddling but I just don't see any glaring issue to report on Hable. That said, I'll need to test on the PJs next as the low NITs of this setup will be interesting to see.
@ mattkhan - I don't think I have a DCI-P3 option on my JVC 7500. I can set it to 2020 (then ST.2084 for Gamma) which worked very well in my last round of testing. I'll dig further tonight when it is dark.
-
@ Hendrik - That makes sense. In resolve you can set a colour space (709 / 2020 / DCI-P3 etc etc) but you also have the option of setting a colour space like 2020 but then limit the range to DCI-P3, which is what most UHD BD have done (given no display can resolve all of 2020
We're never going to expand the colorspace, just re-package it, so if it comes off of a UHD BD as DCI-P3 inside BT.2020, then we wouldn't change that when it gets output as BT.2020, still DCI-P3 inside BT.2020. Only if the envelope gets smaller will the colors have to be adjusted.
I just wanted to make sure those options are properly understood. But luckily it'll also look quite wrong if you set it wrong. I suppose there will need to be a proper wiki article at some point.
But if there are devices out there that can actually accept a DCI-P3 signal without the BT.2020 envelope, then I can certainly add it - although it'll be a bit, since thats part of the rendering library, and i need to re-build it for new values.
As for the tonemapping settings, if we don't find anything super bad, I might change the defaults and reset the tonemapping settings for everyone in a new build before I take a break for a week. It sounds like it might be good enough for a while so I can take my vacation and focus on other features. Feel free to also suggest changes to the settings I posted above.
-
I don't think I've seen any native DCI-P3 content, just DCI-P3 in 2020.
Unelss there is an "easy" fix to 2390 highlights, I'd also agree that (for now) moving on to add the other features like Overlays, Passthrough, Scaling Options etc makes sense. Tonemapping has consumed madVR for years and the endless combinations of content, HW permutations makes it hard to see when it would ever end.
-
Tested on the Epson TW9300 from a NUC Win11 OS HDR on in a dark room. Same Hable settings as previously. No apparent issues. Looked good.
-
Tested on the Sony OLED from a 1660ti Win11 OS HDR on in a light (but not bright) room. Same Hable settings as previously. No apparent issues. Looked good.
-
I have been looking into DCI-P3 values, and I noticed there are two options, so for anyone with a device that might care, are we talking about DCI-P3 (Cinema) or DCI-P3-D65/Display-P3 (which is DCI-P3 with a D65 white point)?
I would assume the D65 one would be more appropriate for PC usage, and its apparently also what madVR uses for its DCI-P3 mode.
-
While, I've only ever seen the description of the encoding being DCI-P3 in general not the DCI-P3-D60 and DCI-P3-D65 variants, which I think have white point changes for different display technologies. I see that wikipedia lists the differences as:
- P3-DCI (Theater): DCI-P3 uses a simple 2.6 gamma curve, a white luminance of 48 cd/m2, and a whitepoint with a correlated daylight temperature of ~6300K, though it is not on the Planckian locus and is slightly greener, the result of optimizing for best light output with xenon lamp projectors. Blue is the same as in BT.709.
- P3-D65 (Display): It uses the DCI-P3 primaries but with a D65 white point which is much more common among computer-display colorspaces It is also used for some of Netflix deliverables, including HDR and without BT.2020 container.
- P3-D60 (ACES Cinema): No idea
Not much help.... but I'd guess that as we don't use xenon lamp projectors, that PS-D65 would be the go.
-
...if you do implement it, I'll be able to feed it to the JVC and see what it reports.
-
...also found this description
What is Display P3? Display P3 is a combination of the DCI-P3 colour gamut with the D65 white point together with the sRGB gamma curve. It originated from the DCI-P3 colour gamut’s implementation in digital cinema projectors, as this standard offers more vibrant greens and reds than the traditional sRGB colour gamut. The white point of the original DCI-P3 is tinted green, and the gamma curve is 2.6. These parameters made it suitable for theatre viewing, but not for closer viewing, such as on monitors. Hence, Apple proposed changing the white point to D65 and the gamma curve to the sRGB curve, and named the new set of attributes “Display P3.”
Looks like I'll need to re-render my UHD footage to P3-D65 (I'd been using the older / original P3-DCI and I don't think my "content" is destined to ever be viewed in a Theatre!!!)... which thankfully is easy.
-
@ mattkhan - I don't think I have a DCI-P3 option on my JVC 7500. I can set it to 2020 (then ST.2084 for Gamma) which worked very well in my last round of testing. I'll dig further tonight when it is dark.
it's an option on the N series, I believe you needed to use autocal with a custom colour profile on the older range (e.g. as per the 1st post in https://www.avsforum.com/threads/jvc-calibration-software-v6-for-2015-models-x9000-x7000-x5000-rs400-rs500-rs600.2246658/) though I think it might be the cinema2 mode that is built in? I imagine the answer lies in one of those giant AVS threads somewhere :)
I have been looking into DCI-P3 values, and I noticed there are two options, so for anyone with a device that might care, are we talking about DCI-P3 (Cinema) or DCI-P3-D65/Display-P3 (which is DCI-P3 with a D65 white point)?
I would assume the D65 one would be more appropriate for PC usage, and its apparently also what madVR uses for its DCI-P3 mode.
yes it's the D65 one
-
...if you do implement it, I'll be able to feed it to the JVC and see what it reports.
It won't "report" anything, just receive different colors. There is no metadata attached, which is why its important to set these properly based on external information.
-
While, I've only ever seen the description of the encoding being DCI-P3 in general not the DCI-P3-D60 and DCI-P3-D65 variants....
I'm, wrong. I checked what MediaInfo reports on a bunch of the latest UHD Blurays and they are all reported as using
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0050 cd/m2, max: 1000 cd/m2
The stuff I'd been encoding was:
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : DCI P3
Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2
So Display P3-D65 it is!
-
Tested on the JVC 7500 from a 1660Ti Win11 OS HDR on in a dark room. Same Hable settings as previously. No apparent issues. Looked good.
-
it's an option on the N series, I believe you needed to use autocal with a custom colour profile on the older range (e.g. as per the 1st post in https://www.avsforum.com/threads/jvc-calibration-software-v6-for-2015-models-x9000-x7000-x5000-rs400-rs500-rs600.2246658/) though I think it might be the cinema2 mode that is built in? I imagine the answer lies in one of those giant AVS threads somewhere :)
Thanks - I've looked at the Autocal thread and even bought the Colourmeter for it..... but have always used a 3rd party calibration person so never done it on the PJ myself (but that was now some time ago, so it will have drifted).
I now have a DCI P3 and DCI P3 D65 (Display) version of one of my clips, so can test if I can even see a difference (when/if Hendrik adds it) and report back. I certainly can not see any difference using the latest Hable settings even with side by side screen shots.
-
Initial Testing comparing DCI P3-D65 vs 2020 vs 709 (all using the stock new Hable Settings + Auto for Gamma on my High Nit screens in Windows 10 with HDR OS on).
WOW - the P3-DCI call looks A+ , the comparison in order is:
- Off line Davinci Resolve Conversion to 709
- PS-D65 : Looks almost identical to DR, a bit more saturated but looks good
- 2020 : Less saturated with a olive tint to the skin tone, does not look great
- 709 : Much more saturated but has a nice "pop" for those that like the look
Need to run over some "real" content and maybe find some colour charts but a very worthy addition!
-
If you want tonemapping with a bit less saturation because you feel thats more faithful, you can tweak the desaturation parameters. Strength is the overall desaturation strength, and exponent controls how much it depends on the peak brightness of the image. The original of 0.9/0.2 would give you stronger desaturation with less dependence on the image - overall a bit less saturation. Don't use the colorspace to tweak for taste! :P
-
yeah - I started looking at colour chips, and quickly found there is all sorts of cross dependences and impacts between all the settings (both in JRVR, OS, HW)..... but I think there are plenty of options to tweak settings to dial in what someone wants (or likes) and no glaring issues.
-
...and I quite like the sRGB target gamma with 2020 and DCI P3-D65
-
I think P3 has a bit more pop (not too much like 709) ... i use it in MadVR for animated stuff ... it might not be faithful, but a bit of pop on animated stuff is nice (dont want to play with desat as it affects details in very bright scenes)
Overall ... i really think Hable is a winner - especially in preserving details in bright areas like skies.
Will do a bit more testing with darker scene ... and then some fire and explosion :)
... will try to test it on SD TV later on.
-
Yeah - I don't mind a bit of pop either, and it's a good point about aiming for a pleasant vs a 100% faithful image. For me it is:
- Skin Tones have to look "right" as we all know how they "should" look
- Not blowing out highlights to a wad of white
- Not crushing shadows to a lump of black
Apart from that I've stopped trying to look at colour chips, as I don't really care if the shade of red on a bike helmet is faithful to what it looked like on set as I will never know.
Looking forward to seeing how HDR Passthrough goes.
-
100% faithful is impossible with HDR unless your screen can do 100% BT2020 :) What we are doing is a compromise.
I agree with skin tones ... that part, i think, have to do with not shifting hues.
Blowing highlights ... that part, i think, has to do with desat ... my understanding is, you need to desat colors (add other colors without shifting hue) to boost brightness
Honestly ... hable is great atm ... MadVR still produces sharper details in higlights (i think due to options to tweak fire and highlight recovery) ... but hable is not limited to Windows, which is a big plus
Who knows ... one day Hable might get to where madvr is :) ... and it will be multiplatform
Question to Hendrik ... measuring peak luminance ... is that get used to adjust tonemapping to reduce compression?
-
Question to Hendrik ... measuring peak luminance ... does that get used to adjust tonemaping to reduce compression?
Yes, Peak Detect overrides the static metadata to limit compression and avoid brightness loss as good as it can.
Without it, it only has the static metadata to work with, and maybe the HDR10+ dynamic metadata if I hook that up, but that is rather uncommon to be found in files.
-
Tested on the Epson TW9300 from a NUC Win11 OS HDR on in a dark room. Same Hable settings as previously. No apparent issues. Looked good.
Why did you enable Windows HDR? I knew that it should always be left disabled and in fact, if I activate it, the colors are completely off; or maybe I got it wrong?
Or maybe with Win11 things have changed?
-
With Windows 11 you can leave it enabled constantly if you want. I'm not sure yet if I want to, on the other hand Netflix can't toggle it and it doesn't do HDR if its not enabled beforehand already, so that might be a nice solution to get it working as well.
-
Yes, Peak Detect overrides the static metadata to limit compression and avoid brightness loss as good as it can.
Is it frame by frame or has some scene detection algorithm?
-
Is it frame by frame or has some scene detection algorithm?
It does scene change detection as well as uses a IIR low-pass roll off to avoid too sudden changes and smooth the response.
-
Peak Detection works for sure
Blade Runner 2049 ... around 00:05:05
-
It does scene change detection as well as uses a IIR low-pass roll off to avoid too sudden changes and smooth the response.
Can it be called dynamic then? ... Or there are other criteria that needs to be fulfilled to be called dynamic?
HDR10+ metadata you mention can be interesting ... though not many titles have it ... i remember reading something about DV metadata parser - though not sure how useful those DV metadata can be if they are proprietary
-
Peak Detection makes the tonemapping rather dynamic indeed. It adapts to the actual scene brightness instead of sticking to what the metadata dictates.
-
A bit of a ramble.... but AFAIK, there are two parts to the compromises that may need to be made to watch "HDR" content like that found on UHD BD:
- HDR: ability to show an expanded luminance range (both with lower black level details well under 0.1nits and currently as high as 10,000 nits) than SDR (traditionally only encodes from 0.1 to 100nits)
- Colour Space: ability to cover a wider colour space (say 2020, DCI-P3) than 709. Note: you can have an SDR display with DCI-P3 coverage and accept a 2020 signal (aka 2020 SDR which is a "thing")
As we don't have domestic screens that can do 10,000 nits or cover a 2020 colour space we have to compromise on both aspects, and hence the work Hendrik is doing.
My thinking was that as a lot of UHD content has been mastered to DCI-P3 (in a 2020 wrapper) and max 1000nits;
- Use Passthrough with screens like my Phillips (DCI-P3 Coverage: 97.6%, DisplayHDR 1000 and UHDA certified),
- Tonemapping for the PJ and
- ?? for the OLED.
So to check what content I actually have, I ran SOT over my 250 odd UHD BDs and populated MC with the values for,
Color range: 100% were "Limited"
Color primaries: 3 were BT.709 and the rest were BT.2020
Transfer characteristics: 3 were BT.709 (same discs as above) and the rest were PQ
Matrix coefficients: 3 were BT.709 (same discs as above) and the rest were BT.2020 non-constant
Mastering display color primaries: 13 were BT.2020 and the rest were Display P3
Mastering display luminance: 103 had a max of 4000, 2 had a max of 1100, the rest were 1000
If I'm reading these tags correctly, it looks like 40+ % are mastered for 4,000 nits and 5% with a full BT2020 colourspace.... so tonemapping will still be needed (either JRVR or the displays in built tone mapper) and will be for sometime regardless of the display.
Anyway.... as I've now got this metadata into MC it could even potentially setup Zones based the Luminance Values / Color Primaries to switch between Tonemapping and Passthrough depending on the content.
To answer an earlier question is I'm trying out leaving OS HDR ON to prevent the display change that happens and let Windows Tone Map UP the Desktop and SDR content to HDR to the Display that is running in HDR. So far it seems to work pretty well and everything just looks "correct" (I guess it is easer to map up SDR to HDR levels than the other way around)..... but this is all a new concept.
-
- HDR: ability to show an expanded brightness range (both lower in the blacks and currently as high as 10,000 nits) than SDR (traditionally only 100nits)
The black level is determined by the display technology and both SDR and HDR can output to the lowest black level of any display. HDR is therefore not "lower in the blacks."
-
Now that 28.0.80 has been set loose ... would be interesting to hear some feedback on HDR tone mapping ... no need to comment that NGU of MadVR is sharper than JRVR ... we know that :)
If something is amiss ... movie title and time stamp of troubled scene as well as your JRVR settings would be most helpful
-
The black level is determined by the display technology and both SDR and HDR can output to the lowest black level of any display. HDR is therefore not "lower in the blacks."
I think SDR is typically encoded for 0.1 to 100nits while HDR can go much lower than 0.1 (eg if you look at the luminance encoding values in my pic above you can see min levels much lower than 0.1 and about 2/3rds of my UHD HDR discs are 0.005nits and the other 1/3rd go lower again). So more details and less banding in dark scenes if your display can resolve these additional dark gradients. SDR will map all content from 0-0.1 as Black, where HDR has many more shades.
-
I think the important distinction here is that while absolute black is certainly going to be equal in HDR and SDR (off is off), HDR can resolve more detail in low-light then SDR could, due to the different gamma curve the HDR PQ encoding offers.
Of course better black detail can only really be used on OLED screens, but HDR PQ is designed in such a way that the screen can tonemap to its physical capabilities, both for black and peak levels. SDR is more of an absolute signal.
-
The question I have from my earlier rambling : Say if you have a display capable of DCI-P3 Coverage and HDR1000 (more and more common) what would you use? Such displays met the required Colour Space coverage for most content (all but the few 2020 discs) and for half(ish) of the Luminance used (1000 nit vs 4000nit discs).
I've tried setting JRVR to PCI-P3 Display and 1,000 Nits but it is clearly still tonemapping HDR Content mastered to DCI-P3 with 1000nit max as HDR Passthrough on madVR has a much better picture.
Just thinking ahead on the "Just Works" HDR concept, could it be possible for the JRVR logic to only tonemap if needed, eg when the source material exceeds the display capability (else just passthrough)?
Hendrik enjoy your break!
-
Thanks - updated my earlier statement to "HDR: ability to show an expanded luminance range (both with lower black level details well under 0.1nits and currently as high as 10,000 nits) than SDR (traditionally only encodes from 0.1 to 100nits)"
-
Just thinking ahead on the "Just Works" HDR concept, could it be possible for the JRVR logic to only tonemap if needed, eg when the source material exceeds the display capability (else just passthrough)?
Maybe, but rather would just let passthrough happen in all cases then if thats a mode your display supports.
Tonemapping right now always targets SDR, which is very different to a HDR signal, even if you increase the target nits. Outputting a HDR signal after tonemapping to some degree is quite a different problem, and not something I'm currently interested in. Rather have people pass-through HDR then, or entirely tonemap to SDR.
In other words, you can't "pass through" in SDR, because HDR PQ always needs a certain amount of processing to make it SDR. By setting the gamut to BT.2020 or DCI-P3, and increasing the Target Nits, you can already very much limit the amount of compression it has to do.
So in the name of "just working", I would actually recommend either always pass-through or always SDR tonemapping, trying to do both based on some parameters gets .. complicated.
-
Just a thought as we wait for Passthrough.
FYI - for those wanting to see what your display can do, chances are it will be listed here:
- Brightness: https://www.rtings.com/tv/tests/picture-quality/peak-brightness : No surprise that modern LCD Flat Screen typically do above 1,000 nits in HDR Mode, and even OLED in the latest generations are creeping closing to 1,000 nits (HDR Real Screen Brightness)
- Colour Space: https://www.rtings.com/tv/tests/picture-quality/wide-color-gamut-rec-709-dci-p3-rec-2020 : Just about everything has pretty good DCI-P3 coverage but still way off on 2020.
-
Maybe....
So in the name of "just working", I would actually recommend either always pass-through or always SDR tonemapping, trying to do both based on some parameters gets .. complicated.
Got it - thanks!
-
SDR (traditionally only encodes from 0.1 to 100nits)"
But that isn't true either. :) Black isn't encoded at 0.1 nits on SDR. If it was, then the maximum contrast ratio of SDR would only be 1000:1. Again, black is determined by the display. An OLED can reproduce SDR black below .001 nits. My JVC RS500, 620, and NX7 could get close to that, too, with the dynamic iris. I can measure down to .0007 nits with my Colorimetry Research CR-100.
The following provides good information:
https://www.lightspace.lightillusion.com/uhdtv.html (https://www.lightspace.lightillusion.com/uhdtv.html)
-
...but I don't think in SDR you can specify any steps between 0 and 0.1. In HDR you can.
Edit, Sorry I'm not trying to suggest that black is 0.1 (it is obviously 0 in both HDR and SDR), but that brightness starts at 0.1nits on SDR material and much lower on HDR.... but I'm certainly no expert, just trying to get my head around it. From what I've read, HDR can resolve far more dark gradients than SDR (eg it's not all just how "bright" it can get, but also how many shades it can specify and at the dark end small nit changes are actually pretty large % changes).
-
OK, Hendrik's on vacation now for a week, so don't find any problems with JRVR.
-
Ahhh, we are way off topic and in the weeds anyway overthinking this (or at least I am)!
It will be good to see others test and report what they think of JRVR on their setups and with various media. As tij suggested feedback on what the clips are and timestamps of anything that does not look right (or does look right) would be great.
-
I'm trying the new V80 on my Tw9400 projector and I have to say that I am very satisfied with the image produced with 4K HDR movies.
I left almost everything by default except the gamut set to DCI-P3-D65 BT-709 and the Peak Nits target set to 180. About the latter, should not be set with the nits that reaches my projector and that is 65? If I do it, I burn the high lights.
A problem to report. I can't open an old 480p DVD that I copied to the hard disk: depends on the fact that I saved it as ISO? Or is the problem 480p definition?
-
As for me, it would be enough for me to add the possibility to see what is happening (the ctr+j of madvr) and the possibility to move the OSD from the bottom to the active area of the film.
-
I'm trying the new V80 on my Tw9400 projector and I have to say that I am very satisfied with the image produced with 4K HDR movies.
I left almost everything by default except the gamut set to DCI-P3-D65 and the Peak Nits target set to 180. About the latter, should not be set with the nits that reaches my projector and that is 65? If I do it, I burn the high lights.
A problem to report. I can't open an old 480p DVD that I copied to the hard disk: depends on the fact that I saved it as ISO? Or is the problem 480p definition?
I don't think nits setting are actual nits of source (madVR allows max to be 100 nits) ... i think JRVR principle for nits is similar to MadVR ... lower values makes image appear brighter (more details in shadow) ... while potentially blowing out highlights
Higher value deals better with bright higlights ... but can crush blacks for lower nits display.
I dont think i have problem with HD/DVD files ... but mine are in mkv ... i have not tested JRVR with disc menus (mostly because i don't rip them that way)
-
As for me, it would be enough for me to add the possibility to see what is happening (the ctr+j of madvr) and the possibility to move the OSD from the bottom to the active area of the film.
Hendrik plans to do those after his holiday
-
A problem to report. I can't open an old 480p DVD that I copied to the hard disk: depends on the fact that I saved it as ISO? Or is the problem 480p definition?
I don't have DVD menus to test ... but i have some DV UHD in folder format that awaits transfer to mkv (now that mkv supports DV)
I cannot play its disc menu with JRVR too (Casino Royale 2006) ... it just gives me black screen - both Hable and BT ... MadVR can play the menus
Something for Hendrik to look at when he is back
PS. Movie plays find from folder structure using JRVR .. it just cannot play disc menu ... anybody else can confirm disc menu playback?
-
DVD menus should work as long as you don't use Hardware Decoding (incompatible with D3D11 decoding right now, which would be fixed at some point in the future). Blu-ray menus are tied to the overlay functionality thats coming soon.
-
These screenshot is making me scratch my head (movie is Tenet ... and timestamp is on one of screen shots) ... seems that MadVR 0.92.17 is really showing its age in terms of tone mapping
Will try beta 113 to see what improvements madshi did (but even that is few years old ... and latest beta are time limited)
PS. JRVR are default settings at 480nits with peak detection ... MadVR matches Hable if set at around 200nits
PSS. Not sure how this scene suppose to look ... but prefer Hable at 480nits and MarVR at 200nits (unless Tenet creators really wanted to hide details of main characters)
-
Hi everyone,
Much, in fact most, of this thread is beyond me but I can report that using the new video rendering setting has fixed the problem I've had with incorrect colours being displayed when playing video.
This is a very good thing and I hope it will continue.
Many thanks to those developers who worked on the new renderer.
John
-
Hi,
I have the same "problems" of understanding everything ;D
But, I can report: on my system (Ryzen5 2600X, Win10/64, lame AMD GPU, MC v80/32), 4K HDR feeding my JVC X7900 with SDR, the convertion runs really good and flawless.
Only during standby or osd infos (like volume), the picture stutters and gets for a fraction of a second green or blue or only partly, it differs from one to the next.
Normal 1080p24 movies also works.
But I'm very happy that it works! Thank you Hendrik! Up and running only 3 weeks after the first demo.
Greetings,
Thorsten
-
The OSD and Overlays have not been integrated yet into JRVR, but will be soon.
-
I'm getting dropped frames / stuttering playing some GOT MPLS directly. I've attached a short frame log from around the 50min mark of 00800.mpls S3 D1 of GOT UHD. I don't get these issues with madVR, and can find with JRVR and pause/play will help but then at some point it stutters again. Let me know if you want any other testing. I'm also using VideoClock if that matters.
-
Ok, Now I have some issues:
-I resumed a 4K HDR film the next day. The movie starts, sound is coming but no picture (only the information of cursor control)
- 576i videos with 4:3 ratio have a green line approx. 10 pixels right to the 4:3 film and 1-2 pixel wide (Red hot chilli peppers - monkey funks)
- and their deinterlacing doesn't work at all...
-
Oh, one other thing: my Win-Desktop is 1080p24. If I start a 4K movie, the output resolution is still 1080p24. I don't mind as I'm not a fan of eshift.
PLayback settings -> display setting -> automatic change: off or on
-
Ok, Now I have some issues:
-I resumed a 4K HDR film the next day. The movie starts, sound is coming but no picture (only the information of cursor control)
Weird: 4 times out of 5 it works normally ... I can't find a schemata. Only on 4K (all my 4K are on a local hdd, no network)
-
Regarding the scaling: I switched the display resolution manually to 2160p and then the playback of uhd movie remained in this Resolution. Starting next a FullHD Movie didn‘t change the Resolution.
(I did the switching with madvr ;D )
So, still a lot to work….
-
Resolution switching is not a feature we are currently aiming for. We generally recommend using the native resolution of your screen and benefiting from the scaling features in JRVR.
-
Ah, ok
-
Oh, one other thing: my Win-Desktop is 1080p24. If I start a 4K movie, the output resolution is still 1080p24. I don't mind as I'm not a fan of eshift.
PLayback settings -> display setting -> automatic change: off or on
I have a 4K monitor, but my desktop is set to 1080p since most of my apps work better at that resolution. In JRiver I have Video > Display Settings > Display Settings Automatic Change Mode set to Custom and have all my resolutions set to 3820x2160. JRiver switches to 3820x2160 when playing a movie with JRVR and then switches back to 1080p when I stop the movie. I always have used this and never use madVR's switching.
-
+1 what mojave suggests is a really good option as the display rate is changed by MC prior to the building of the graph (which is a more reliable way to work).
-
I'm getting dropped frames / stuttering playing some GOT MPLS directly. I've attached a short frame log from around the 50min mark of 00800.mpls S3 D1 of GOT UHD. I don't get these issues with madVR, and can find with JRVR and pause/play will help but then at some point it stutters again. Let me know if you want any other testing. I'm also using VideoClock if that matters.
I pretty well get stuttering on most content after a while. A quick Pause / Play does not settle it down but a longer one does (say 1 sec).
Edit. I'm wondering if it is fighting with Video Clock? I'm now running with Video Clock turned off and so far so good
-
I haven't done any testing against VideoClock yet. So many things that interact, so little time. It'll definitely be on my list to checkout eventually. If you or others can confirm its fine without, and using it causes issues, that would be helpful.
Do you get audio or video issues when this happens? The frame time log didn't include anything meaningful, just one or two drops and one repeat or such, but nothing that would tell me there was a significant issue.
Also how long is "a while" to trigger this?
Are you playing on a perfectly matched refresh rate, or a mismatch?
-
I've never used VideoClock. I tried to today, and I haven't noticed any changes.
As soon as I can, I will watch a whole movie with VideoClock and see what happens
-
I run JRVR since two weeks as standard on my Workstation (output is UW to LG Monitor) and on my Media Renderer (output is 4k to LG OLED).
Video Clock is On on both.
On the workstation I have Display Settings automatic Change Mode =on (My LG Monitor only supports 60Hz and 59 Hz).
On the Media Renderer I have Display Settings = Custom.
Since the two weeks I have played all different types of video's: From 11kHz 4:3 160x120 12,02 FPS, DVD, BD rips with 29i, 23p, 50p .. up to some 4K HDR demo videos (I don't have UHD BD Rip's). Everythink worked so far - not a single issue.
-
Thanks for testing with Video Clock.
It was just a guess, trying to work out what is going on and I'll need to test more (most of the testing is on my Dual Screen 3090 setup on Win11 as I can leave MC run on one screen doing stuff on another). I do see some desync of Audio around the time the stuttering and checking I see I've also got a bit of AV Sync Correction set (50ms) so I'll try turning that off. FYI - I too also use MC's display rate changer to match the content (all frequencies).
-
Ran through a eps of GOT (50min). Got 3 instances of stuttering @ 19:30, 41:30, 43 mins. This time I did not intervein, just let it run and all times it settled down on it's own between 10 and 30sec. This was with VideoClock ON and Sync at 0ms.
-
Can you post a MC log as well as the frame time log of a full playback, ideally without pausing or seeking? Note that the frame time log is reset for every new video you play, so you have to be sure to get it after the first play.
Or mail it to me if it gets too big. I suppose an hour of video playback might accumulate somewhat of a frame time log, but the entire picture would be quite illuminating.
-
Will do. I'm currently running an EPS with VideoClock OFF and Sync at 0ms. Only got one very short set of stutters so far at the 23:30 mark.
-
Link to log sent by PM. Looked pretty good, only noticed some stuttering at the 23:30 mark for this run.
-
I should probably update the frame time logging so its not overwritten everytime a new playback is started, and instead just put a marker inside. Seems like any log I get is pretty short. :)
-
Mmmm I did grab the frame log right after stopping (well within a minute or so) and before I'd played anything else. Next time, I'll play a new EPS with VideoClock On with the folder containing the Log open and grab it straight away.
-
I have had minor issues playing 1080p content, specifically ATSC recordings made by NextPVR. I haven't played other type of video content with MC lately, so it may no be specific to that content. The problem is not frequent, maybe a dozen frames over a 45 minute period. It's random and not easily reproducible. What happens is that the image "blinks", as if frames from a different timeline of the program were inserted in the middle of the video. It is unfortunately quite noticeable to me when it happens.
I'm using a Ryzen 2700 CPU with GTX 1050 Ti, going through a Marantz SR7011 AVR and Optoma UHD65 projector, setup at 4K 60/8 bits.
-
Sent a PM with another Log (this time I turned JRVR logging it ON!!!!)
-
I looked over your frame time log, and something isn't happy with what happens when it needs to repeat a frame to handle clock drift, and it gets into a repeat/drop loop. I'm not sure why yet exactly, but I improved the repeat logging and cleaned some stuff up.
If you can, grab another frame time log with the next build, unless its magically fixed from the small improvements I did.
I couldn't easily reproduce locally, so let me know.
-
Will do (I'm away with work for a couple of days, so it may be later in the week).
-
Also improved accuracy for NTSC-style refresh rates specifically, so look for build 82 and hopefully the added accuracy will calm down the repeat/drop logic, as I think inaccurate VSYNC estimations pushed it into an unexpected VSYNC window. (Also even more frame logging improvements)
-
How I can implement an 3DLUT?
In the newest build is there a recommendation for one. I can create one with DisplayCal. Is there an option to use it?
-
How I can implement an 3DLUT?
In the newest build is there a recommendation for one. I can create one with DisplayCal. Is there an option to use it?
No 3DLUT atm for JRVR … don’t think it is planned too …
-
No 3DLUT atm for JRVR … don’t think it is planned too …
It is mentioned as a future feature in https://yabb.jriver.com/interact/index.php/topic,130657.msg905912.html#msg905912
-
3DLUT is indeed planned, although likely not in the first wave of features, and possibly not the madVR 3DLUT format, which seems underdocumented - but an alternate format also supported by tools like DisplayCal.
-
Not on Public Board
28.0.84 (11/16/2021)
3. Changed: JRVR will report the actual screen refresh rate to VideoClock for more accurate timing adjustments.
5. NEW: The Playback OSD is rendered natively with JRVR.
6. NEW: Support for Blu-ray Menu playback with JRVR
In some quick testing:
- OSD rendering works without dropping in or out of modes
- HDMV BD menus works!
- ...but I seem to have issues with Java BD Menus (see log) with playback terminating
- I'll send a log later today on the sync with VideoClock
Note: I did delete the "libplacebo64" folder to force a re-download incase it was still using the test library from the other day, but the same issue with Java BD Menus (or are there other folders I need to delete to force a re-download of required components??)
Thanks
Nathan
-
Are you sure this particular disc worked on other renderers?
-
Yup - here is log with it working in ROHQ, and not in JRVR on one title as an example (...and in the prior log it should have showed the issue on 3 Java BD discs (from memory))
-
FYI - If I turn off "HW Accel" then the menus work with JRVR
-
FYI - If I turn off "HW Accel" then the menus work with JRVR
Here is a log with JRVR, first play is with HW Accel On (and it fails), and then with HW Accel OFF (and it works)
-
3. Changed: JRVR will report the actual screen refresh rate to VideoClock for more accurate timing adjustments.
Sent the Frame Rate log. Looks good
-
Blu-ray Menu issues should be resolved in the next build (85 or newer)
- UHD Blu-ray Menus could terminate playback immediately (due to changing from 8-bit to 10-bit with D3D11 decoding and encountering an error)
- Menu Playback could get stuck on screen transitions
- Java-based loading animations wouldn't show reliably
-
Sent the Frame Rate log. Looks good
Indeed, looks just fine. There was a single glitch at around 10 seconds into playback, and nothing for the remainder of the entire file, with stable timing and no drops or repeats. Looks like VideoClock is doing its job now!
-
Yup looks great as well!
-
Wow! .84 is awesome! All the things I mentioned earlier are solved! Very good work, thanks a lot!
Also tested PAL DVD, menue works.
But, I also have this issue with uhd (not with fhd) Resolution is 2160p, hw acc on, Video clock off
I thought it is a heating problem of my rebuilt htpc, but everything is fine there.
I pretty well get stuttering on most content after a while. A quick Pause / Play does not settle it down but a longer one does (say 1 sec).
Edit. I'm wondering if it is fighting with Video Clock? I'm now running with Video Clock turned off and so far so good
-
You can't have that problem, because I fixed it. So you must have another problem. :)
The only way to diagnose such issues is for you to enable the frame time logging, play a video long enough for it to occur without disrupting playback (no pausing, seeking, etc), and sharing the log (you need to grab it manually, its not part of the logging zip file).
-
@thorsten: I'm not sure if I understand your issue correctly, but:
- Video Clock ON: I don't see any dropped or repeated frames as MC is resampling the audio to keep pace with the video. This only works of you are decoding the Audio (eg NOT bitstreaming)
- Video Clock OFF (or bit streaming audio): JRVR will drop/repeat the occasional single frame to keep pace with the Audio.
Note: Both the above assumes you are also using MC's Display Rate changer to match the frequency of the Monitor to that of the content being played.
-
Blu-ray Menu issues should be resolved in the next build (85 or newer)
- UHD Blu-ray Menus could terminate playback immediately (due to changing from 8-bit to 10-bit with D3D11 decoding and encountering an error)
- Menu Playback could get stuck on screen transitions
- Java-based loading animations wouldn't show reliably
Looking good. Only "odd" thing I could find is that sometimes when I stop playback, I get the coverart image with an MC overlay saying "Opening" as the graph is being broken down before going back to Theaterview (probably should say "Closing" or "Stopping" etc)
-
V86 Testing (not yet on Main Board)
iGPU Testing: Intel NUC7i5BNB with Intel Iris Plus Graphics 640 (iGPU), Windows 11 with HDR Set to ON all the time, JRVR HDR Passthrough to an LG OLED
I can hardly believe it.... but this 4 year old NUC (and its 640 iGPU) can play UHD HDR HEVC 23.976/50/59.94fps material without dropping frames using JRVR & HDR Passthrough! I mean 50 and 59.94fps HFR material, not just "std" UHD BD & the image looks great. I'll not pretend the NUC has anything left in the tank with HFR HEVC HDR material however... the little fan is screaming along and the NUC gets pretty warm. You also don't want to be doing anything else (even trying to view the performance monitor caused it to start dropping frames). I only watched about 10mins of a couple of HFR and it seemed fine and stable. Very Very Impressive and JRVR's performance gains over madVR and EVR should translate well to more modern iGPUs.
-
HDR-10 passthrough is working well on a range of different setups. On OLED and LCD TV/Monitors I think I prefer Passthrough over Tonemapping, but I'm in two minds on the JVC x7500. I'm going to need to play much more with the various options to see where I land on this one.
Seems to work well with both the various content I've tried, BD Menus, MC's own OSD. The only issue (as reported elsewhere) is the subtle pulse in the picture brightness when subtitles appear (but not when MC's own OSD appears - including TheaterView's OSD overlays).
-
I've not yet run through any test patterns to check, but any recommendations on if we should be using Limited or Full in the Video Drivers?
-
Very Very Impressive and JRVR's performance gains over madVR and EVR should translate well to more modern iGPUs.
VVI ! Thanks! And thanks for all the detailed testing. Immensely helpful.
-
Working on the subtitle HDR issue. Its a bit on the complex side for various math reasons and interacting components. But hopefully I can get a fix out soon.
-
Forgive the ignorance, but is HDR-10 passthrough only for TVs? I don't get anything good with the PJ.
Thanks for the ctr-j, but the characters are so small that to read I have to get up and get closer to the screen: is it possible to increase the size?
-
The font size problem should be fixed in the next build, probably next week.
Does your projector support it?
-
I've not yet run through any test patterns to check, but any recommendations on if we should be using Limited or Full in the Video Drivers?
....I thought I had overnight, is "Limited or Full" even a thing with HDR?
-
Does your projector support it?
Support what? If you are referring to HDR, yes.
-
We don't differentiate between projectors or TVs, but just switch the output to HDR mode and send the appropriate metadata. As long as the device is capable, as well as your OS/Driver, I would expect it to work.
-
Tomorrow I will do more in-depth tests, in the meantime remove me a doubt: on Win10 do I have to activate HDR?
The projector is an Epson TW9400 and with tonemapping I have a good result as opposed to passtrough
-
You either turn on HDR manually, or let JRVR turn it on by enabling the option to let it do so.
But you should also confirm that Windows offers you the option to enable HDR.
If it doesn't seem to work, you could manually enable HDR in the windows display settings and then try playback again, to see if that does something.
-
FWIW, I'm still trying to workout the best setup on the Epson TW9300. It supports up to UHD & HDR but..... it only has a 10ghz HDMI chipset so the combinations are...... awkward and limited to get it to work consistently across different media. I'm also driving it with a NUC8 so I'm also limited in what it can do with it's iGPU. The "best" compromise I've found so far is to output in 1080p and have JRVR tonemap to SDR but the NUC can't keep up with 59.94 HDR UHD content (consistently dropping frames) but the good news is 50fps HDR UHD content it only drops the odd set of frames here and there and "normal" 23.976 is fine. I'm aware this setup is very constrained by the HW limitations of the NUC and the PJ, but with JRVR there are plenty of options to now try.
-
One issue I'm seeing in my testing is that if in Theater View, I Left Arrow back a lot (to get to the start of a video for testing) then JRVR playack is then janky. I have to do a long Pause then play for it to work correctly again or even a Stop/Play.
-
One issue I'm seeing in my testing is that if in Theater View, I Left Arrow back a lot (to get to the start of a video for testing) then JRVR playack is then janky. I have to do a long Pause then play for it to work correctly again or even a Stop/Play.
I assume you just mean in fullscreen playback, eg. Display View. Its no different if you started it from theater view or standard view and just went fullscreen. :)
I have tried to reproduce it for the last couple minutes but it seems to recover fine. If you can make it happen reliably, perhaps a frame log might shed some light. Ideally trigger it, and then let it play for a short bit, and then terminate, so there is a phase of the issue. No need to "fix" it in the log.
-
Will do - I too just tried to force it and did not have the issue (and I did not have the log on before). ::)
-
Looks like VideoClock is doing its job now!
I also finally got around to testing some more scenarios. On my TV I usually watch at 120Hz, as it allows playing 24, 30 and 60 fps content without mode switches (and HDMI 2.1 has made it possible, yay), and I'm happy to say that both VideoClock and JRVR did their job fine, with no single frame drop or repeat throughout an entire TV episode (ignoring those drops at the start, isolalted to the first half second of playback), as well as perfectly stable timing hitting the right VSYNC window for every frame, and no micro-stutter.
-
Tomorrow I will do more in-depth tests
So, today I had time to do some tests.
By selecting HDR10 Passthrough and Enable OS HDR, the PJ automatically switches between SDR and HDR, but colors overall are somewhat dull despite trying the PJ's various HDR adjustments.
By selecting only HDR10 Passthrough, the PJ remained in SDR and therefore Tonemapping was active.
By pure chance I wanted to activate the passthrough "on the fly" that is with the video running, and at this point the HDR was activated but the strange thing was that it depended on how I positioned the mouse: sometimes it was active, sometimes not and it was sometimes active but the colors were exaggerated (people's faces, for example, were a fiery red). If I then let go of the mouse, it went back to SDR.
I hope I was able to make myself understood
-
Videoclock & JRVR is working well. Now I'm jealous of HDMI 2.1 but sooo much equipment to replace (GPUs, AVRs, TVs/PJs).
-
By pure chance I wanted to activate the passthrough "on the fly" that is with the video running, and at this point the HDR was activated but the strange thing was that it depended on how I positioned the mouse: sometimes it was active, sometimes not and it was sometimes active but the colors were exaggerated (people's faces, for example, were a fiery red). If I then let go of the mouse, it went back to SDR.
HDR pass-through on the fly changing is probably not something you should do. :) There is some initialization that is only done earlier.
-
...and to me the big benefit of Win11 is the ability to just leave HDR on all the time, none of this switching the mode back and forth.
-
The switching at start of playback is pretty transparent for me. Except that the latest TV Firmware update seems to have broken something and sometimes the signal dies when it switches (also with madVR) and i have to power cycle the TV. Hope that gets resolved in a future update.
Would have to update the CPU for Win11, not sure I want that right now.
-
What CPU do you have. I've upgraded a couple of Gen 7's to Win 11 so far without issue.
-
Its a 6th Gen, I think 6700k. I could probably force it bypassing the checks, but its also not really worth the hassle, as the switching works for me most of the time, its only in the last week that the silly TV update started causing these issues.
I might just upgrade it anyway, something like the 12600 looks rather interesting for a HTPC.
-
HDR pass-through on the fly changing is probably not something you should do. :) There is some initialization that is only done earlier.
You're right :)
But if I set passtrough first, the PJ doesn't detect it and stays in SDR mode unless you activate the HDR OS.
However, in my situation, I get EXCELLENT results with tonemapping, I am really satisfied.
I also discovered the excellent result with both BD and UHD menus.
This is something that I have never been able to get to work with madvr, but now I can start the movie with menus without any problem and this even using my custom resolutions.
At this point, I would miss the creation of the ICC profiles, hoping that when you activate this possibility, you will also explain to me how to do it. ;D
-
But if I set passtrough first, the PJ doesn't detect it and stays in SDR mode unless you activate the HDR OS.
HDR is only supposed to work if either you turn it on in the OS yourself, or let JRVR turn it on for you. If there are cases I missed that this doesn't cover, let me know. But if you run HDR pass-through without Windows having HDR enabled, it'll perform its low-quality tonemapping, which should be avoided.
In 87 I actually tightened the checks for this so these things are properly enforced when you toggle it at runtime.
-
In fact, the passtrough is only activated if it is activated in the OS. I also found that it does not activate in cases like mine where custom resolutions are used, but only with standard resolutions.
I take this opportunity to point out, even if you surely already know it, that using the zoom is very heavy both with a moving image and when paused.
-
V87 is out on the main board, and in my testing
- The subtitle brightness pulse is fixed
- the Ctrl+J OSD now scales nicely
-
I have a 720p Pearl Jam Unplugged DVD that has a 4:3 aspect ratio. There is a thin green line from top to bottom on the right-hand side that is persistent throughout. It fluctuates from being right next to the video with no gap, to being an inch or two away with a black bar in-between. I tried using the crop edges feature in MC and even set it to 6%, but it is still there.
I double checked and the line does not exist in madvr.
-
There is one feature, for me, that I think is missing before I can switch over to JRVR for all SDR content. While rare, I do have 11 videos out of over 600, that benefited from using madvr's custom filename blacklevel flag. These videos, for whatever reason, were washed out and benefit from lowering the black level.
I could use a zoneswitch with a custom playlist of just these files to play in madvr only, but it would be great if there was a way to set the black level/brightness on a per file basis.
-
I have a 720p Pearl Jam Unplugged DVD that has a 4:3 aspect ratio. There is a thin green line from top to bottom on the right-hand side that is persistent throughout. It fluctuates from being right next to the video with no gap, to being an inch or two away with a black bar in-between. I tried using the crop edges feature in MC and even set it to 6%, but it is still there.
I double checked and the line does not exist in madvr.
Curious. When you say 720p DVD, what file format is it? DVDs are typically 480p (NTSC) or 576p (PAL).
Can you make a small cut of that for testing? A binary cutting tool works with most file formats, eg. this tool: https://files.1f0.de/dgsplit12.zip (just set chunk size and stop after 1 chunk to cut from the beginning)
If its MP4, that won't work, unfortunately, but nearly all other formats will, as long as you cut from the front. If its an actual DVD ISO or structure rip, you could cut a small part of the first big .VOB file (typically VTS_01_1.VOB).
A few MB should be plenty as long as it reproduces the issue.
Also, what kind of GPU are you on?
-
Curious. When you say 720p DVD, what file format is it? DVDs are typically 480p (NTSC) or 576p (PAL).
Can you make a small cut of that for testing? A binary cutting tool works with most file formats, eg. this tool: https://files.1f0.de/dgsplit12.zip (just set chunk size and stop after 1 chunk to cut from the beginning)
If its MP4, that won't work, unfortunately, but nearly all other formats will, as long as you cut from the front. If its an actual DVD ISO or structure rip, you could cut a small part of the first big .VOB file (typically VTS_01_1.VOB).
A few MB should be plenty as long as it reproduces the issue.
Also, what kind of GPU are you on?
You are right. It is 720 x 480. I misspoke. :P
I've got an integrated chip on an AMD Ryzen 7 4800U.
Attached is the file.
Thanks!
-
One other feature request I thought of after testing more, is that I cannot shift subtitles globally, like you can in madvr.
-
You are right. It is 720 x 480. I misspoke. :P
I've got an integrated chip on an AMD Ryzen 7 4800U.
Attached is the file.
Thanks!
Thanks for the sample. Seems fine on my NVIDIA system, going to throw it at more hardware on monday!
-
One other feature request I thought of after testing more, is that I cannot shift subtitles globally, like you can in madvr.
Thats not exactly an easy feature right now in a generic way, and is going to be a while for such options.
We support shifting text subtitles on a per-movie basis, maybe in the meantime we can make a global default? It would only work with standard text subtitles, but maybe that would already be plenty. You could try on a movie and see if it works for what you need it to do.
-
Thats not exactly an easy feature right now in a generic way, and is going to be a while for such options.
We support shifting text subtitles on a per-movie basis, maybe in the meantime we can make a global default? It would only work with standard text subtitles, but maybe that would already be plenty. You could try on a movie and see if it works for what you need it to do.
I think that would work out great.
-
Thanks for the sample. Seems fine on my NVIDIA system, going to throw it at more hardware on monday!
I went ahead and tested this on a Ryzen 5 3400 with Radeon Vega 11 graphics. The green line did appear about 1" off the right side of the image. This was consistent over two different firmware levels; 21.8.2 and 21.10.2
-
A feature I would like is the possibility to have a Nit value for 1000, 4000 and 10000 Nits. With peak detection on I prefer in my setup a Target Peak Nits value much higher my really brightness are. We so have more flexibility for the different types of content.
-
Small one. It would be good if you could set the "Wait after change (use if display changes slowly)" when "Display Settings automatic change mode" is "On" instead of needing "Custom" as you then would not need to fill out all the frame rate settings to just get the delay set.
-
A feature I would like is the possibility to have a Nit value for 1000, 4000 and 10000 Nits. With peak detection on I prefer in my setup a Target Peak Nits value much higher my really brightness are. We so have more flexibility for the different types of content.
Not going to add specific options like that. If we get a settings profile system in the future, that might be a possibility to leverage.
Small one. It would be good if you could set the "Wait after change (use if display changes slowly)" when "Display Settings automatic change mode" is "On" instead of needing "Custom" as you then would not need to fill out all the frame rate settings to just get the delay set.
Sure, why not.
-
Small one. It would be good if you could set the "Wait after change (use if display changes slowly)" when "Display Settings automatic change mode" is "On" instead of needing "Custom" as you then would not need to fill out all the frame rate settings to just get the delay set.
I second this request.
-
Thats not exactly an easy feature right now in a generic way, and is going to be a while for such options.
We support shifting text subtitles on a per-movie basis, maybe in the meantime we can make a global default? It would only work with standard text subtitles, but maybe that would already be plenty. You could try on a movie and see if it works for what you need it to do.
This might work for me. I have a scoped projector screen where I use an Anamorphic lens. If we could have 2-3 presets to adjusting the subtitle text, this would be very helpful.
-
You are right. It is 720 x 480. I misspoke. :P
I've got an integrated chip on an AMD Ryzen 7 4800U.
Attached is the file.
Thanks!
Got that file fixed. The issue was as I expected, so easy to fix once I could reproduce on the right hardware. Thanks for the sample!
-
Glad to hear!
-
Now that I'm using JRVR full time, I am noticing some other oddities.
Sometimes when fast forwarding, the video slows to a crawl/gets choppy until I stop and resume.
Sometimes the audio won't work after skipping ahead and I'll have to restart playback to make it work.
Also, I just noticed at the beginning of a movie that the audio was garbled for a second or so.
These are all either 1080p or 4k blu-ray mkv rips.
I am bitsreaming and never had any problems when using madvr.
-
Hmm. I'm not sure how it would impact audio, especially when bitstreaming when VideoClock isn't even active, which would be the only link between video and audio. But I'll keep an eye out.
I have not noticed any of that so far, but then during daily use I don't bitstream.
It does all sound like audio related troubles, as the reference clock is driven by audio, and JRVR just reacts to it. But that doesn't really explain anything yet.
Are you using any other custom DirectShow settings? Not overriding our audio renderer, by any chance?
-
28.0.88 (11/30/2021)
1. Changed: "Video -> Display Settings -> Wait after change" can be used when Display Settings are set to On/Auto, instead of only in Custom mode.
Thanks
-
Hmm. I'm not sure how it would impact audio, especially when bitstreaming when VideoClock isn't even active, which would be the only link between video and audio. But I'll keep an eye out.
I have not noticed any of that so far, but then during daily use I don't bitstream.
It does all sound like audio related troubles, as the reference clock is driven by audio, and JRVR just reacts to it. But that doesn't really explain anything yet.
Are you using any other custom DirectShow settings? Not overriding our audio renderer, by any chance?
Definitely not. I'll keep an eye out and try to reproduce. I'll try without bitsreaming and see if it is any better.
-
On one of the test versions, I had some instances of choppy playback after doing fast rewinding but did not have logging on at the time..... and of course not an issue since turning it on (though I'm only using bit streaming on one HTPC setup and this was not the one with the issue). I also had on another system an issue with weird Audio after the display rate change but increasing the "Wait after change" value fixed that. There is also a "play silence at startup for hardware synchronization" that may help (though I've never needed it) in Options --> Audio--> settings
-
I'm seeing a faint white line at the very bottom of the screen. See screenshot attached. Happens on multiple movies that have completely black (or mostly) scenes and it is obvious in a dark room on an OLED. The line is not there when playing the same movies on madvr.
-
In the image, the line has a green tint to me, which is always a bit of a hint..
A few things to check:
- Can you test without hardware decoding?
- Can you test with another upscaler selected (which would affect Chroma)? Which one are you using? Try something trivial like Bilinear or such maybe.
I have a hunch but need to confirm.
-
Looks like that problem might have a small performance cost to fixing, hopefully it won't be very noticeable, but quality should win of course.
Got a potential fix in for the next build, let me know if it resolves the brighter line, and for everyone else, maybe check if you can notice any performance change with hardware decoding - not that it can really be avoided, but information is good.
Edit
89 is available now on beta, appreciate any testing!
-
Tested on:
- NUC7 and the update now pushes UHD HDR 59.94fps material passed it's processing power with frame drops (and I tried all the various scalers but no luck). UHD HDR 50fps is still fine however.
- NUC8 (outputting @ 1080p) also drops frames on UHD HDR 59.94fps (but it is occasional groups rather than all the time like the NUC7)
- 1660Ti & 3090: No performance impact I could see
On my HTPCs I did not see the "brighter line" issue, is there a specific combination that causes it? The reason I ask, is it would still be good to have a mode that is playable on such low end equipment (say the good old "Compromise Quality for Performance") if possible. I'll not die in a ditch over lack of 59.94fps playback on the NUC as I've only two of those but I suspect that with the rise of Videos from modern phones / cams that shoot HFR/HDR others will bump into it. Thankfully I shoot in 50fps frame rates and these still work.
-
It might depend on how the movie was encoded, and what exactly the GPU fills the out-of-frame image data with. In datdudes case it was apparently the treacherous "empty green" which is basically the value 0 for chroma. Chroma upscaling would then read some of these green pixel in the upscaling process, creating a faint green echo. Reading those can't really be prevented cleanly, as any reasonably fancy upscaler will read an area to determine the pixels, so the only solution is to cut them off, but that is mildly costly, especially when you are already barely making it.
In any case thats the theory whats going on, its in itself logical, but would need confirmation its fixed for datdude now.
Even if the outside pixel were black though, you might get a slightly darkened line along the bottom edge or such, which still wouldn't be great - even if much less obvious.
An option might be possible, but I'm weary about adding one thats not exactly quality, but a bug.
-
Thanks for the background. I'd personally select an option that may have the potential issue of the "empty green" than unwatchable stuttering (especially as I've not seen the issue). How about an option like as follows where Bilinear is still the default but a user can still select the old method if needed?
-
... keeping with the movie themes for naming stuff in MC (aka Red October), you could call it "Fast and Furious" mode! ;D
-
I might be able to turn it off when using the built-in bilinear scaler, since that one is rather predictable. But I'll need to do more testing. Would also be good to know which scaler datdude was using. Since the color extends into two lines actually, I would assume something more fancy with a bigger area.
-
Sounds fair, and it's not like these older iGPU's will ever be using anything more intensive than Bilinear anyway and those with a stronger GPU will be wanted to use a different scaler. The only issue is that the default is Bilinear which may not be a good idea if it uses the old method if the green line issue is present with Bilinear. Do you have a file that shows the issue and I'll run it up on the NUCs to see if it shows (that is if rolling back to V88 will use the old method)?
-
Is Jinc going to be the best upscaler JRVR will ever have?
Nothing like NGU is planned for the future?
When we have huge screens 145"+ NGU was still the best on madvr for qaulity....
-
More advanced scalers are planned for the future. NGU itself of course is specific to madVR, but there are alternatives, namely RAVU and FSRCNNX are in the running. RAVU is a medium-performance scaler, and FSRCNNX is a high-end quality scaler, which also needs a good GPU to run.
-
More advanced scalers are planned for the future. NGU itself of course is specific to madVR, but there are alternatives.
Ok thank you..... I just bought MC28 to try JRVR but really dont want to test it until it has something similar to NGU sharp. I used Jinc and higher on madvr before they developed NGU, so at this point in time I will just stick with madvr. I know NGU is limited to madvr, but for you to have something as high end as NGU, do you have to develop that or is there something similar off the shelf you can use soon?
Or are there limitaions with JRVR that will never allow high end scalers to be added.
Sorry for all the questions but I just dont want to waste time changing when NGU now is so fantastic.
-
Do you have a file that shows the issue and I'll run it up on the NUCs to see if it shows (that is if rolling back to V88 will use the old method)?
It seems to happen on most UHD BDs for me, but not on NVIDIA since they seem to color the outside black. Its particularly obvious on FastBicubic and other bigger area scalers, but I can still measure some discoloration even on Bilinear, which isn't great (screenshot and color picker, the last line has a slight green hint, the one above does not). It was particularly easy to see on my 16:10 display I use on my testing rig, because the aspect ratio letterboxes the image, and thus the line moves up from the bottom border.
-
OK - I'll have a look on the NUC driving an OLED, but I'll never see it on the other one as it is driving a PJ where the outside of the image is in the black velvet boarder (edit - this would only be true on 16:9 content which is my screen size). Both of these NUCs are using Bilinear.
-
FSRCNNX is a high-end quality scaler, which also needs a good GPU to run.
Is an RX580 considered a good GPU?
-
Rolled back the NUC7 to V87 and pixel peeping that bottom line (or two?) of the image is black (looks blacker than the letterbox). It is unnoticeable but if it was green that would be another story.
-
Also did the test on the 3090 with FastBicubic, took a screen shot and zoomed it 800%. I see some colour bleed into the letter box in parts of the image but the last line it is mostly black and completely unremarkable. I'm also running Win11 with HDR ON and passthrough if that matters. I've also only got nvidia and intel to test, but there is no issue I can see on these systems.
-
I'm thinking a "Fast and Furious" option makes sense. I get that quality is #1 but the other aim is to have JRVR run on as a wide a range of HW as possible including iGPU low powered devices. An option going to do so would be great as V87 just works on the NUCs with no discernible issues.
-
Is an RX580 considered a good GPU?
I wouldn't particularly call it very good, its getting a bit old afterall, but I can't judge how these will perform yet, we'll just have to wait and see (and try). There will likely also be multiple performance levels to pick from, and of course towards the top you have diminishing returns in quality as well.
I'm thinking a "Fast and Furious" option makes sense. I get that quality is #1 but the other aim is to have JRVR run on as a wide a range of HW as possible including iGPU low powered devices. An option going to do so would be great as V87 just works on the NUCs with no discernible issues.
I have changed LAV Video to color the frames entirely black before decoding to mitigate the impact from this, but until that rolls out I'm not really happy to offer an option that adds a potential green border (a slight darkening of the bottom border is far less observable, especially with most movies being letterboxed). So will just have to be patient for a while.
-
Nice idea. There is always more than one way to skin a cat! Now to test SuperRes :)
-
Sent some Logs as V90 is sometimes crashing for me when testing Superres (not always but often when starting a video playback, MC just disappears).
My first impressions is Superres certainly improved ringing artefacts on a broadcast TV eps.
I also noticed that Ctrl-J does not work with Live TV even though JRVR is in the filter chain.
With the dithering Algo's is Blue Noise the "Best" but most computationally expensive as I see in the notes that White is fast and noisy, and Ordered is balanced.
-
Yes, Blue Noise is both the highest quality and most computationally expensive (if something would be better and cheaper, we would just drop the expensive one :D). Blue Noise (https://en.wikipedia.org/wiki/Colors_of_noise#Blue_noise) is nice because it has reduced lower frequencies, which would be particularly distracting in dither noise. Ordered can show regular pattern which some people don't like, and White Noise is just a bit more noisy since it contains those low frequencies - but its fast.
I'm not sure how much of an impact it makes computationally, but since the option exists, might as well offer it.
PS:
The crash should be fixed in the next build. Thanks for the log.
-
Thanks for the info on Dithering.
Is the crash just related to Superres or should I roll back to V88/89?
-
Its just SuperRes related.
-
I have a new AMD 5700G APU and LG 34UC98-W PC-Monitor. With my old workstation I used only 8bit. The LG monitor allows also to use 10 bit = 8bit + A-FRC (Frame Rate Control) with leads in the AMD display settings to RGB 4:4:4 Full RGB.
Is A-FRC good for JRVR or should I go with 8-bit?
-
I noticed an issue with JRVR: it does not show external subtitles.
Test case 1:
- configure MC to use JRVR
- have a mkv or m2ts file with no internal subtitle
- have an external ass subtitle file
- start playback
-> the subtitle file is visible in the context menu, but is not displayed on screen
Test case 2:
- configure MC to use madVR
- have a mkv or m2ts file with no internal subtitle
- have an external ass subtitle file
- start playback
-> the subtitle file is visible in the context menu, and is displayed on screen
Test case 3:
- configure MC to use JRVR
- have a mkv or m2ts file with internal subtitles
- also have an external ass subtitle file
- start playback
-> all subtitles are visible in the context menu, with the external subtitle file being selected, but is not displayed over the video
- switch to an internal subtitle using the Subtitles context menu options, and then back to the external subtitle
-> now the external subtitle is displayed over the video !
-
The subtitle issue should be fixed for the next build.
-
Thanks - SuperRes crash is fixed in V91. Looks good.
-
Thank you for fixing the external subtitle issue!
-
The fix for the green line on 4:3 videos is gone and I haven't seen any lines for widescreen movies at the bottom.
SuperRes looks good and I haven't see any negative impact on performance.
Nice job all the way around!
-
Looking forward to loading up the GPU's in V92 and testing the new scalers out.... but I'm away with work for a couple of days :'( . Have fun
-
My feedback on JRVR after using it since HDR passthrough is available.
I've been using JRiver with madvr for the past 5 years at least, I accepted some slight issues not that problematic, like stutter when JRiver OSD is active, things like that...
This is using a LG C8 as my only display, watching mostly 720p mkvs and ripped BD / UHD BD.
All I can say for now, is that it just works. Setup is standard, Jinc everywhere, HDR passthrough + windows switch.
I don't feel I'm missing anything quality wise from madvr with NGU sharp high everywhere + Jinc (if needed).
Picture is just as sharp, colors are just as right, HDR seems about the same.
The OSD doesn't cause stuttering anymore which is very nice.
Madvr seems abandoned a bit in favor of Envy (which is of course logical), it is better moving forward to bet on a new renderer which is actively developed and... just works.
The only slight issue I'm seeing, is sometimes when TV switches to HDR the HDMI goes nuts and the TV displays static noise. I have to power cycle the TV to get it working again. I don't remember having that issue with madvr, but at the same time I did upgrade to W11, and all the drivers with it, so who knows.
Keep up the good work.
-
V93 Testing (on a 3090) with HDR Passthrough
WOW!
1. NEW: JRVR will show rendering performance metrics on the Info OSD (Ctrl-J).
Thanks - really helps in seeing what is going on. As others have mentioned the ability to reset the stats would be good.
2. NEW: Chroma upscaling in JRVR can be enhanced by using Bilateral scaling (Chroma upscaling guided by Luma).
This works really really well and gives a very good quality bump even on my UHD HFR HDR material. I know that many will say Chroma scaling is not that important (and hence the 4:2:0 encoding is used) but Bilateral scaling to bring it back to 4:4:4 is the best I've seen to date.
3. NEW: Image upscaling in JRVR can use advanced Image Doubling algorithms for enhanced quality when playing low resolution videos.
I tested on FSRCNNX16 across a range of low to high res material, and max the rendering time was only around 5ms with the 3090 so can't wait to see how the 1660Ti on the PJ goes when it gets darker.
One "issue" I did see was when the screen was not change refresh rate. The first 1 or 2 seconds (say 100 frames @ 50hz) would have a weird "rush" effect until it settled down (I've attached the log). It is hidden when change refresh rates (even with a delay on) but it looks a bit unsettling. It may be worth having a bit of a wait for the queue (or an option for this?)?
Small one: It would also be good to be able to get to the JRVR settings while the video is playing through Right Click --> Direct Show Filters --> JRVR (if possible) as it makes it easier for testing different settings as the image stays on the screen.
-
Tested on a 1660Ti using HDR Passthrough to an OLED.
FSRCNNX16 can be too demanding of some material, but FSRCNNX8 was fine and the image looked great.
-
One "issue" I did see was when the screen was not change refresh rate. The first 1 or 2 seconds (say 100 frames @ 50hz) would have a weird "rush" effect until it settled down (I've attached the log). It is hidden when change refresh rates (even with a delay on) but it looks a bit unsettling. It may be worth having a bit of a wait for the queue (or an option for this?)?
Waiting is not really feasible. madVR tried to do something like this and it just ended up rather buggy.
Its probably caused by compiling all the complex shaders, there is a shader cache planned that will help to improve startup time, but its quite a bit of work.
-
Fair enough.
-
With 28.0.92 available, I finally decided to also give it a try. Its main task is DVD upscaling (as >95% of my movies are on DVD, as *.iso on my server). With madVR, I had found a set of settings, organized in profiles, that would work very good with this SD content, while also taking care of the few BDs (also *.iso), and even fewer *.mkv and *.mp4.
I started with one of my worst case DVDs for upscaling (James Bond - The Spy Who Loved Me, original release, when there were still CRT TVs, no HDMI, but SCART etc.). And I must say, even with the highest scaling settings applied, it currently doesn't get close enough to madVR.
I have included two screenshots for comparison (cropped the black bars because of the file size limitations in the forum). Especially focus on the straight and high contrast lines on the Esprit's roof, windscreen frame, and door. Also, faces, Bond's right arm, and several other places. Overall, the picture doesn't look that natural and smooth, compared with madVR. In motion, it gets even worse. At first it looked awfully bad, but I found that, although I had selected OK after changing all the JRVR scaling settings, they were gone. I had to redo them, select Apply, and then OK, and finally, the high-end scaling selection persisted. Then, it was definitely better as before. But, currently, it's not working for me, DVD upscaling is too bad (compared to madVR), unfortunately.
-
Tested on a 1660Ti using HDR Passthrough to a 125" Screen (JVC x7500)
Looked good using Bilateral and FSRCNNX8.
I really like HDR Passthrough to OLED/LCD and letting the displays doing their own tonemapping. While I've currently got a pretty good image using HDR Passthrough with the JVC doing the tonemapping, I really need to spend more time using JRVR tonemapping as I get the feeling I'm leaving a lot on the table. Hopefully, we will see more PJ owners testing!
-
With my PJ I have tested BD and UHD with Bilateral, FSRCNNX16 and tonemapping and the result seems good to me provided I use standard resolutions. If I try with custom resolutions, my RX580 maxes out at RAVU.
I have to try the DVDs and the passtrough.
-
Thankfully, almost all my commercial videos are BD or UHD and the combo of Bilateral, and FSRCNNX works great for me. I still have bunch of old camcorder footage (even Super8 conversions done years ago) and music video clips where the original quality is simply dreadful and my expectations for these are much lower.
-
Thankfully, almost all my commercial videos are BD or UHD and the combo of Bilateral, and FSRCNNX works great for me. I still have bunch of old camcorder footage (even Super8 conversions done years ago) and music video clips where the original quality is simply dreadful and my expectations for these are much lower.
Yeah, that's an almost ideal case :) But for me, I'm not planning on replacing all these DVDs. Many of these aren't available on BD, and some are worse on BD than on DVD (massacred aspect ratio, oversaturated, too much contrast, odd colour tints etc.). So, I'm going to stick to these ;) Also, in many cases, the BD image is not what it looked like in cinemas. But that's personal preference of course.
I also have a few DVDs with even worse content (e.g. some NBA playoffs and finals from Bulls era), where no renderer achieved a really good result. Next time, I'll include these in the test suite too, I guess.
Oh, and I also don't have exaggerated expectations of course, for SD material. Matching madVR's results, that would be the moment, when I'll most likely be switching to JRVR permanently :) This time is not now, but JRVR is still so "young", and considering that, it has achieved a lot already :)
-
The DVD results look more like a deinterlacing shortcoming to me, which is a current limitation - its not using hardware deinterlacing when you play through the DVD menu due to problems with the menu rendering.
This will be addressed through the subtitle re-working coming in the future (which also handles the menu), as well as a small update to LAV Video.
If you want to expirment a bit, you could rip one of those movies to an MKV and see if the quality improves, as that then won't have that limitation.
-
The DVD results look more like a deinterlacing shortcoming to me, which is a current limitation - its not using hardware deinterlacing when you play through the DVD menu due to problems with the menu rendering.
This will be addressed through the subtitle re-working coming in the future (which also handles the menu), as well as a small update to LAV Video.
If you want to expirment a bit, you could rip one of those movies to an MKV and see if the quality improves, as that then won't have that limitation.
Interesting. I'll give the *mkv idea a try, either later today or tomorrow.
-
The DVD results look more like a deinterlacing shortcoming to me, which is a current limitation - its not using hardware deinterlacing when you play through the DVD menu due to problems with the menu rendering.
This will be addressed through the subtitle re-working coming in the future (which also handles the menu), as well as a small update to LAV Video.
If you want to expirment a bit, you could rip one of those movies to an MKV and see if the quality improves, as that then won't have that limitation.
Interesting. I'll give the *mkv idea a try, either later today or tomorrow.
I've just created a *.mkv from the DVD and was so curious I directly had to test it on that workstation :D It definitely looks better now! Way better! I'll make screenshots again, when I can test the *.mkv on the HTPC and compare to madVR (most likely tomorrow). Thanks, Hendrik :)
-
Yeah, that's an almost ideal case :) But for me, I'm not planning on replacing all these DVDs.
I've fallen into the "trap" of now even replacing BD's for UHD's (about 25% of my library is now in that format) and no movie DVDs.... but I do still have music clips ripped from my DVD's so FWIW & to join the pixel peeping, here is an example of an MPEG file pulled from a DVD mastered Music Video that I've always had issues with, and then I picked a frame that looked as bad as possible. On this content both JRVR and madVR show plenty of issues with combing (madVR is better) and random dots such as on Angus's top knuckle / tip of nose (JRVR is better). This is why I've replaced what I can as I don't think there is any magic that will make this content look good.
-
On the 007 theme (left if madVR, right is JRVR same settings as above) and the source is 1920x1080 BD so both Luma and Chroma scaling (all non HDR). From what I can see (on the PNG Screen Shots - the attachment below is JPEG as the PNG is too big):
- Black crush in the jacket is handled better by JRVR
- Chroma scaling around the edge of the shirt looks better in JRVR
- Background noise is better in madVR (I can see some patterns in the noise with JRVR such as on the wall to the left of the head or the wall under the chin for example)
Overall this is really pixel peeping on still frames. It looks good played in realtime.
-
Overall this is really pixel peeping on still frames. It looks good played in realtime.
Thanks for your comparison screenshots :) I'll add mine later, as soon as I've time to sit down in front of the TV. My example wasn't meant as pixel-peeping though, it did look even worse in motion. Wobbling lines, flickering edges (due to the aliasing), really bad. I agree 100%, the important part is what it looks like in motion, played at realtime speed. When one can't tell which version is madVR and which JRVR, then the image quality goal has been reached (for me) :)
This is why I've replaced what I can as I don't think there is any magic that will make this content look good.
The problem is, for a lot of content there are no better sources... And this highlights the biggest downfalls of our current display technology. Only a single resolution looks good. This has always bothered me once having to let go of CRT TVs (which have their own downfalls of course). This is a thing that has to be addressed via software, unfortunately, on lower resolution content, as the displays aren't capable of CRT like resolution flexibility. Unfortunately, this isn't a strong selling point (as the "consuming masses" always like "more", "higher" etc. better than having to actually understand the technology), otherwise we already would have something like that, instead of striving for ever higher resolutions without any content for it :D Also, that way they can sell the same content to the same person again and again, because that person "must" replace his/her BD with an UHD BD, and replace that with an HyperHD BD the next year ;) No offense, just joking and exaggerating :D
-
No offence at my end, and all very true. Image the size and weight of a 65" CRT however!
I too am not too keen on static comparo shots for the reasons you mention.... we don't watch video one frame at a time but in a flow of frames, and it's how the flow looks that is very important. One argument I'd have for the rebuy is if the studio is doing its job competently (big if), then their ability to re-encode in non real time "should" be better than what we can do in real time at home. Also, (and I'll be in the vast minority here) but I love the look of HFR, giving us additional temporal resolution running at 50 (or 60)fps (not just more pixels) and wish there were more directors like Ang Lee experimenting with this..... without the horror that is interlacing + it is fully compatible with all current displays and essentially a free doubling of (temporal) resolution. I'm now shooting all my Home Videos @ UHD HDR 50fps with 360 degree shutter (eg no shutter which keeps the same cadence of "film / PAL" shot at 180 degrees but with half the motion blur) and it looks great, but of relevance to this thread is that JRVR's efficiency means for the first time even lowly HTPC's like my NUC7 and NUC8 can play these back without dropping frames. This is something I could do with no other renderer.
Looking forward to HyperHD BD! Take my $$$$
-
I seriously doubt we'll see another incarnation of physical media unless some ground-breaking new technology emerges. Between 4K and 8K there are diminishing returns on the normal viewing distances at home, which makes it less desirable even for enthusiasts, never mind trying to market it to the masses. They are more likely to continue to do what they have done so far, and release re-masters of older content. Of course that might never reach every kind of niche content you might need to hang on to lower quality media for.
-
The only thing we can trust with the studios is they will chase a $ wherever they can find it. I've no idea if that includes new physical formats or not but they certainly shoot already on equipment capable of higher than 4k and likewise their production pipelines support higher resolution. I'd personally like to see the back of low 24fps material but I think that is also very unlikely. Anyway, for now we have plenty to work with on UHD content and as you point out the law of diminishing rewards is well and truly in play.
-
So, I did another check, now the DVD converted to *.mkv to remove the deinterlacing from the equation. Now, JRVR is relatively close to madVR in terms of image quality (in motion- as that's all that interests me). So, Hendrik was absolutely right. Once the menus and deinterlacing are fixed, this should work. It's still not where madVR is, but pretty close.
However, there are occurrences of scaling shortcomings which are more pronounced with JRVR. This time, look at the windscreen frame of the Esprit and its tailgate. In motion this is a flickering between relatively smooth and the aliased line you see on the screenshot. This also happens with madVR, but to a much lesser extend (I still notice it in motion, but it's not that distracting as it is with JRVR).
Overall, the picture is still smoother with madVR. But maybe, JRVR will be getting there, or even further... I can say, I'm impressed with what has already been achieved :) And although I'm not switching to JRVR right now, this might only be a matter of time. At least when the scaling for low resolution content will get better...
-
Do you use quadrupling in madVR to go from SD to 4K? I suppose that could still help to some degree, we don't currently allow that.
-
Do you use quadrupling in madVR to go from SD to 4K? I suppose that could still help to some degree, we don't currently allow that.
For SD, I'm using NGU Anti-Alias, with "high" for luma doubling and everything else on "let madVR decide".
Edit: Oh, and I don't use 4K. This is on a calibrated 1080p Panasonic WT50E. I'll only go higher in resolution when that TV dies some day. I don't need 4K or 8K for anything, so I'd refrain from buying something like that, but I want to calibrate my TV, so... I'll have to bite that bullet some day... Anyhow, I'm really happy with this TV, it's running for almost 10 years now, without any issues, and the calibration is the icing on the cake (for me).
-
Ok it was a tough ask but I tried jrvr on a onboard hdmi ivy bridge intel cpu and for 4k material it's just too much. LOL
Playing 1080p remux movie though works very well and is quite smooth.
I'm going to install a gtx 1650 super gfx card in there and see how it performs with 4k material again.
-
Yeah - I think the "bare minimum" iGPU for a HTPC these days is going to be Kaby Lake or later as this was when Intel added HW decoding of 264/265 UHD etc (so 7th Gen +). You should have no issues once adding a discreet GPU like the 1650 Super however.
-
Yeah - I think the "bare minimum" iGPU for a HTPC these days is going to be Kaby Lake or later as this was when Intel added HW decoding of 264/265 UHD etc (so 7th Gen +). You should have no issues once adding a discreet GPU like the 1650 Super however.
Yup, so last night I dropped in the gtx 1650 super and played some 4K movies with all scaling settings on maximum and judging by video, it looks buttery smooth. Very impressive. It's being used on a 1080p projector but I'll have a vava 4k UST projector coming in next week to see how it performs with JR DTM and also try HDR pass through.
-
According to the JRVR OSD stats my 4K rips (to 4K display) are being downscaled to 1080P? Is this correct?
(https://i.ibb.co/4jxwSLV/image.png)
I'm also having performance issues, may be related (unnecessary image downscaling)?
-
Yup - It looks like your 4K display is set to 1920x1080
-
The OSD doesn't lie. Either your resolution is 1080p, or you have multiple screens connected and the 4K one is not the primary one, which causes Windows to apply scaling, in effect making it as if it was 1080p. In this case, you can fix that by making the 4K screen the primary screen.
-
Watched a BD (1080p) upcasted to UHD with all the current JRVR goodies on and with VideoClock On. Not a dropped frame (after the first few seconds). Flawless.
-
you have multiple screens connected and the 4K one is not the primary one, which causes Windows to apply scaling, in effect making it as if it was 1080p. In this case, you can fix that by making the 4K screen the primary screen.
This is my issue. I had no idea Windows did this (I temporarily switched back from Linux on my HTPC to get madvr tonempapping, and now JRVR). The primary display is a 1080P dummy plug since I run this thing headless when the TV is not connected. Looks like I'm switching back to Linux now, Debian 10 does not have this problem (mixed resolutions), correct?
-
The OSD doesn't lie. Either your resolution is 1080p, or you have multiple screens connected and the 4K one is not the primary one, which causes Windows to apply scaling, in effect making it as if it was 1080p. In this case, you can fix that by making the 4K screen the primary screen.
I have the same problem with 2 screens but even if I make the 4k screen the primary screen I still have the wrong dimension of the window unless I come from display scaling 300% to 100% in windows parameters. But in that case I cannot read anything when I push a window from the small screen to the big 4k screen . I have not this problem with madvr.
-
I have not this problem with madvr.
The scaling behavior comes from Windows and is entirely independent of the renderer used. madVR might just show information differently to not make it as obvious.
Another reason it might happen is if you change resolution while MC is already running - we recommend to not do that and just run at the full resolution at all times, and let JRVR handle scaling.
-
The scaling behavior comes from Windows and is entirely independent of the renderer used. madVR might just show information differently to not make it as obvious.
Another reason it might happen is if you change resolution while MC is already running - we recommend to not do that and just run at the full resolution at all times, and let JRVR handle scaling.
I read somewhere that most video player programs ignore Windows scaling settings in order to display videos at full resolution. Anyway I just found a workaround on the internet, it is possible to disable windows scaling for JRiver only :Right-click the application, select Properties, select the Compatibility tab, and then select the Disable display scaling on high DPI settings check box. My other applications are still scaled and then readable and JRVR reports a 4K windows.
-
After switching primary monitors, JRVR is working correctly at 4K now. Unfortunately, the added pixels are pushing my embedded Vega 3 to its limit doing UHD peak detection. The interesting thing is that Windows only reports ~50% GPU utilization when frames are dropping. As this is an APU I suppose it could be a memory bandwidth issue or some other bottleneck in the pipeline.
As my main goal is getting tonemapped UHD without frame drops, I've turned all of the other quality settings to their "fastest" values (dither off, delayed peak detection, bilinear, sigmoidal light scaling off) and can go up to ~15 Mbps with default tonemapping settings + delayed peak detection. Will definitely need different hardware for my high bitrate stuff, I will do some testing on my 5600G later this week.
The other option is to cave and purchase a good HDR display so I can use HDR passthrough and reserve my precious GPU resources for scaling and other parlor tricks. Using HDR passthrough, I've been able to playback 100+ Mbps with bilinear chroma scaling and blue noise dithering (anyone know if native resolution content is dithered?). So the Vega 3 is sufficient for high bitrate 4K as long as tonemapping isn't involved.
-
As my projector does not tone mapping for HDR, I tried this.
I thought I had a powerful computer, but being a computer - nerd, I been sold a computer not well for video - playback. It says proudly GEFORCE GTX 16 series videocard, but in fact, I guess this is only used for gaming, because an Intel seems to do the job.
SSD 3RD Generation,16 G memory? AND a I7 processor, and nothing seems to work correctly, even the HDMI output is not compatible HDR. although the video card is 4K (HDR is banked out, in settings)
I tried J RIver decoder. With the MadVr on 27 version, I managed to have good results, even if HDR is of course altered to SDR.
With the new decoder, it seemed even better (though bit darker). I saw that last week, there was an upgrade. But since then I got stutters. It seemed to help to put the hardware acceleration off, but with other files, the issues came back. I not saw that on a previous version, or could there be another reason? Same recent HDMI cable though. MadVr is still fine, but I found the new decoder, sharper, better looking.
My projector is a Fenmi C2, I play through my Denon 1600. Also the OSD (CTRL + J) works on MadVr, not on the new decoder. What is wrong?
-
A recent HDMI cable doesn't necessarily mean one that works with HDCP. Try a Google search to learn more. I think user Park just solved a problem related to the cable spec.
-
Right Click during Playback, the Window menu. If I take a typical cinema movie in 2.35:1 with letterboxing (eg. 16:9 in 1920x1080 or 3840x2160):
- Crop Black Bars -> 2.35
- Crop Black Bars -> Untick "Crop Sides of Video to Fill Screen"
This should just allow the video to fill the screen if there is room without any bad cropping or scaling.
In some tests I've had aspect ratio issues, but right now I can't reproduce them anymore. Otheriwse Override Aspect Ratio is there to resolve those.
This entire sizing logic is not new to JRVR, its been in MC a long time for DirectShow playback.
the stretch option is also required when using an anamorphic lens but it looks ok to me
there is one major problem though, performance is massively worse if I restart playback with these changes applied
i.e.
start playback without settings in effect = ~20ms render time
make changes to crop/stretch etc = ~28s render time, looks ok
restart playback = ~45-50ms render time, looks ok but stuttering badly
I suspect the options provided don't support vertical compression anamorphic lens btw (don't have one myself so can't verify)
-
The JRVR OSD (Ctrl-J) doesn't work for me on Live TV or TV recordings, does work when playing other material though.
-
the stretch option is also required when using an anamorphic lens but it looks ok to me
For anamorphic lenses I suspect we may need to add an option to specify the factor of the lense so it can adapt the aspect ratio appropriately, without using the "Stretch" option which is a bit of a brute-force method - and a stretching factor would also support lenses in either direction.
-
Just to note, the performance delta was repeatable. It seems to be linked to that stretch option as removing that, when it was stuttering, bought things back into line.
-
A recent HDMI cable doesn't necessarily mean one that works with HDCP. Try a Google search to learn more. I think user Park just solved a problem related to the cable spec.
Ordered another cable, but that not explains, why I had no stuttering before the last JRiver 28 update. And it does NOT stutter on MadVR. But I find new JRiver decoder sharper.
-
Just to note, the performance delta was repeatable. It seems to be linked to that stretch option as removing that, when it was stuttering, bought things back into line.
Can you poste a screenshot of the Ctrl-J OSD when thats going on?
-
Can you poste a screenshot of the Ctrl-J OSD when thats going on?
3 pics attached, normal_stats shows the stats with no adjustments made, crop_stretch_stats shows the stats when you start playback normally then adjust crop/stretch and then finally crop_restart_stats_after_restart shows with the same scaling present and applied from playback start
taking the pics gave me a repeatable solution to the problem, after alt+tab'ing to another window and back, rendering time drops back to normal
-
Thanks. Alt-Tabbing changing the behavior sounds weird, but as does an increase just from changing the stretching, but i'll run some tests.
-
One other thing I noticed, subtitles are markedly higher up the display Vs madvr when running in this mode. Is that (moving them) also an option somewhere or should it happen automatically?
-
I should clarify that I've not had previous experience with HDR and have no HDR media. I've downloaded one of the Sony HDR clips to experiment with and have noticed something that I thought I should report.
When I set MC to use JRVR the clip plays with jerky video and stuttering audio. If I set MC to use Red October HQ both the video and audio are smooth and skipless. I've run this with a number of different settings for HDR in JRVR but it's always jerky playback. It's always smooth in HQ (and for that matter in VLC but without HDR of course).
I'm running MC 28.0.94 on Win 11 on an AMD Ryzen 5 3400 with Radeon Vega 11 set to 10 bit. This inputs to a Denon X4400H with 4K video set to Enhanced which feeds a LG 65OLEDB7 with color gamut on Auto.
If I can provide other info please let me know.
-
Have you tried enabling HDR passthrough to eliminate tonemapping? I doubt that iGPU can tonemap high bitrate UHD content without stuttering.
-
Sorry I don't have a solution but some of the HDR demo clips I have tried just don't play well on my system but UHD/HDR rips of movies play just fine. My only point is that using downloaded clips might not be the best test case. If this is a well known and widely used test clip then ignore this.
-
Caveat emptor, these tests were done on Fedora 35, but there are already enough JRVR threads so I'm sharing the results here instead of the Linux board. Since there is no OSD on Linux yet I'm basing my performance metrics on the eye test (obvious frame drops) and the radeontop graphics pipe monitor to get an idea of GPU load (I've found the GPU monitoring in Windows tends to under-report GPU load, 50-60% utilization reported by the task maanger is actually equivalent to ~90% pipe load according to radeontop). I've tested natively on X as well as Wayland with very similar performance. I actually think the Wayland experience is a little better OOTB because I had to enable TearFree in xorg.conf to eliminate tearing on X11. I'm using the open-source amdgpu module which is typically pretty close in performance to proprietary in most benchmarks.
Unless otherwise noted the tests are done using the default settings for scaling, tonemapping, and dithering.
65W 5600G (integrated Vega 7): It plays absolutely everything I have flawlessly, barely breaking over 75% on the graphics pipe metric with the default settings for UHD 105 MB/s files. I also tested Jinc upscaling for my high bitrate 1080P files and I can't see any frame drops. I haven't tested upscaling with HDR passthrough enabled yet but I must assume performance would be the same or even better.
I also enabled frame doubling w/ RAVU and tested some 720p files and while the graphics pipe is at ~90% I don't see any frame drops. Usually there are very subtle frame drops whenever the pipe is this full so I'll need the OSD to confirm (does log frame timing report frame drops?).
If anyone wants more specific benchmarks I can provide them, but for all intents and purposes the 5600G just works.
15-25W R1505G (integrated Vega 3): Slightly better performance than on Windows but tonemapping anything above 40 MB/s starts dropping frames even with all of the performance tradeoffs enabled. When using HDR passthrough I don't see any obvious frame drops w/ default settings but the pipe is pushing 85-90%. When performance is bogging I do see more A/V sync issues on Linux than on Windows (even pausing or forwarding does not resync the audio on Linux--videoclock issue?).
So, apparently the low-wattage sweet spot is somewhere between the 5600G and the R1505G (;D, very wide margin) to get flawless UHD tonemapping. Anyone that is using HDR passthrough should be fine on a Vega 3 up to around 125 MB/s or so by my estimates. CPU coolers seem to do a pretty good job at keeping Vega integrated GPUs cool so a passive heatsink should suffice for a silent 5600G rig that can handle UHD tonemapping. It would be great to see reports from other embedded APUs (a V1605B would be very interesting) or 35W APUs (AMD H-series). The V3000's on the horizon should be absolute beasts and fun for the projector guys to mess with, particularly the V3718.
In my case I'm going to bite the bullet and buy a new TV with credible HDR and eliminate tonemapping from the equation so I can keep using my existing low-powered hardware. With the chip shortages it's about the same price for a new fanless SFF box w/ Vega 8 or the equivalent vs a 10-bit panel with local dimming.
-
Thanks for the testing and the report, Bryan.
-
Thanks for the suggestions but I still see the problem in JRVR:
Have you tried enabling HDR passthrough to eliminate tonemapping? I doubt that iGPU can tonemap high bitrate UHD content without stuttering.
Trying all settings I get:
JRVR-
Passthrough - stuttering
Passthrough with OS help - stuttering
Tonemap - stuttering
HQ-
Passthrough - smooth
Tonemapping - smooth
Sorry I don't have a solution but some of the HDR demo clips I have tried just don't play well on my system but UHD/HDR rips of movies play just fine. My only point is that using downloaded clips might not be the best test case. If this is a well known and widely used test clip then ignore this.
I admit that might be possible or even that I have som setting somewhere arwy. Anyway if anyone has any suggestions of known good test clips I'd appreciate it.
-
There's some good ones here: https://jell.yfish.us/
Also, make sure that refresh rate switching is working properly for you (use the JRVR OSD to confirm) as mismatched refresh rates can cause stuttering.
For giggles, when you enable HDR passthrough and OS HDR support try also disabling peak detection in the HDR settings (it should be off since JRVR isn't tonemapping, but just to make sure for testing purposes).
Also, make sure you've tamed Windows Defender, I can't get smooth playback without excluding MC on some of my machines.
-
There's some good ones here: https://jell.yfish.us/
Also, make sure that refresh rate switching is working properly for you (use the JRVR OSD to confirm) as mismatched refresh rates can cause stuttering.
For giggles, when you enable HDR passthrough and OS HDR support try also disabling peak detection in the HDR settings (it should be off since JRVR isn't tonemapping, but just to make sure for testing purposes).
Also, make sure you've tamed Windows Defender, I can't get smooth playback without excluding MC on some of my machines.
This may be more related to the file. I did download a couple of the Jellyfish files (UHD h264 and HEVC) and some LG demos, one HDR and one not. The jellyfish file did stutter a bit at the beginning (HEVC worse) before smoothing out although it wasn't clear to me that they were HDR (but what do I know this is all quite confusing). The LG files appear to play smoothly although the HDR one would sometimes stutter a bit at the start.
Couldn't check the refresh rates as the JRVR OSD (ctrl-J, right?) would not display during these clips although it would when playing a movie out of my library.
I'm pretty sure I've got Defender excepting all of MC and my library/media storage locations.
Thanks again for the help
-
I've done some more extensive testing on my library and found that when using HDR passthrough there are some files that JRVR will occasionally drop frames on (that work fine in madVR). I've tried disabling dithering and sigmoidal light scaling without any effect (doesn't seem to be performance-related as not all of these files are super high bitrates).
-
When testing on Linux? I am not quite sure pass-through can currently work on Linux, so you might be using tonemapping.
-
When testing on Linux? I am not quite sure pass-through can currently work on Linux, so you might be using tonemapping.
No, this is back on Windows.
-
If you encounter stuttering that shouldn't be there based on performance, then a frame log would possibly shed light, you can turn it on in the JRVR settings. Be mindful that it'll overwrite it everytime you play a video, so you would have to move it out after the offending video was played.
We'll also look into hooking up the Ctrl-J OSD for TV and on Linux/Mac after the holidays.
-
Here you go. Ignore the startup drops, I don't care if it's a little messy at the beginning I just care about the frame drops that occur every 15-20s or so after the performance queues have filled up.
-
If you are sure thats not related to performance, which it seems to be too rare for, you might be suffering from rendering glitches. There aren't really universal fixes for that, on NVIDIA i know that disabling Multiplane Overlay (MPO) (https://nvidia.custhelp.com/app/answers/detail/a_id/5157) can help, but no idea about other vendors from the top of my head.
If you are using subtitles, make sure it doesn't coincide with subtitles showing up, as that can be a bit of a performance bottleneck currently (which we're working on to resolve).
-
This is on AMD. Any idea why these files would work fine in madVR but not JRVR? madVR uses more GPU resources but no rendering glitches/frame drops.
One thing I've noticed that might help: On Windows, if I have another window open in front of the MC video display (say, task manager and the task bar), I stop getting any frame drops. Why does JRVR start dropping frames when it is full screen? It's using about 70% of the GPU...maybe it's triggering some power save mode?
Edit: I've disabled LSPM and AMD Cool 'N Quiet and the problem persists.
-
Fullscreen uses a more efficient mode to work with DWM if possible for better control over presentation timing - which is also required for HDR pass-through to work properly. Theoretically its better for performance as well as stability, but you are at the mercy of the driver even more.
You could try the NVIDIA link above, its technically not NVIDIA related as it just turns MPO off inside DWM. I don't know if that issue also affects AMD.
We also fully use D3D11, madVR is still mostly on D3D9. Can't really compare them.
Presentation glitches are a bit out of our control though. We request an image to be shown, and the GPU for some reason doesn't manage the timing we requested, but shows it a frame late, which in turn means we have to drop at least one more frame, so the best case would already be that 2 frames are screwed up, in your case its actually 4 as it seems to have two glitches in a row. That is assuming there is no performance related issues to trigger it (a future update will add another metric to the frame log to help identify performance related issues as well, in case there was a short spike or whatever).
If its only on certain video files and not all of them, that would be suspicious though, and might point to an interaction perhaps with hardware decoding, which is really the only part that interacts with the source video. Once its decoded, all video is basically equal to the GPU, assuming the same resolution etc.
-
I tried the MPO fix without any luck. I guess I will stick with madVR for the time being on this machine, maybe it's a W11 or driver bug that will get worked out. I don't see it happening on my other machines, but one is 1080p and the other is significantly more powerful.
If anyone has access to a 15-25W Vega 8 (ex. 2500U) I'd be interested to hear their results. If not, I may buy a 2500U laptop motherboard to see if the Vega 3 just isn't powerful enough for JRVR.
Edit: I've got a 2500U w/ Vega 8 on the way to test in a week or so. I just need to get rid of frame drops on high bitrate files in JRVR. JRVR offers enough benefits (reliable resolution switching, 10-bit rendering even with Windows 11 HDR disabled) that it's worth the hardware upgrade.
-
Just got my hands on a Vega 8 (2500U) in the form of a Samsung 5 notebook.
I've abandoned tonemapping as I purchased a new HDTV with nice HDR reproduction, so I'm only interested in reliable HDR passthrough without frame drops.
With the default settings, I am still running into infrequent frame drops (once every 25 seconds) on high bitrate content (~100 MB/s) with the Vega 8, although anything below that works great (I would start running into issues at about 60 MB/s on the Vega 3).
By switching the dithering from blue noise to ordered I am able to eliminate the last of the frame drops on high-bitrate content. No jittery playback, and no need to manually mess with Windows HDR mode like on madVR!
-
a little quiet here....is there something new we can hope for?
If we get 3D LUT integration, is there a fix use of rec709 or will it possible to use an advanced colorspace, like P3? That would be a big advantage over madVR. That is locked at rec 709 internal, as I know
-
I do have one request, linked to SDR material playback while the display is in HDR mode (HDR activated in Windows 10).
I noticed movies look somewhat washed out compared to when the display is in SDR mode (HDR disabled in Windows 10). It's as if the overall tone mapping curve applied has a different gamma when the display is in HDR mode than when the display is in SDR mode. I imagine there should be some gamma compensation used when playing SDR material on a HDR display, in order for the overall display characteristic to be BT1886.
A second point regarding this is that JRVR should likely allow the user to configure what should be the brightness value (in cd/m^2) of the full white in the SDR video when displayed on a HDR display, and this value should be considered when performing the overall display gamma compensation mentioned above.
As a use case for this is UHD HDR BluRays. They often have extras in SDR despite the fact that the main movie is HDR, and those extras look quite bland when viewed with the display in HDR mode vs. when the display is in SDR mode.
-
I don't mind the SDR --> HDR process done by Win11 and think it looks "fine". I've no idea what curves MS are using this for this and apart from the "Brightness Slider" in the HDR config page there is little other control of the process. Have you tried playing with the "Brightness Slider"?
Another approach that may be possible for JRVR down the track is to implement a separate section /new feature for SDR --> HDR tone mapping that has a few more options than what we get with Windows.
-
I've got a file that is reporting "HDR 0 nits" in the OSD and seems too dark during playback. I can send a link if needed.
-
Files without metadata will result in a subpar experience, as they get treated as if they were 10000 nits, can't really be helped. Strictly speaking, those files are technically invalid.
-
Thanks, I'll try to find some replacements.
-
I suppose in absence of other data, they could be treated like 1000 instead of 10000, but if it actually goes beyond 1000 then it'll result in other problems.