Print

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

[Hendrik]

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.

[jmone]

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. 

[BryanC]

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?

[abrise]

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.

[Hendrik]

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.

[abrise]

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.

[BryanC]

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.

[indieke]

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?

[JimH]

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.

[mattkhan]

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)

[rpalmer68]

The JRVR OSD (Ctrl-J) doesn't work for me on Live TV or TV recordings, does work when playing other material though.

[Hendrik]

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.

[mattkhan]

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.

[indieke]

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.

[Hendrik]

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?

[mattkhan]

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

[Hendrik]

Thanks. Alt-Tabbing changing the behavior sounds weird, but as does an increase just from changing the stretching, but i'll run some tests.

[mattkhan]

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?

[davelr]

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.

[BryanC]

Have you tried enabling HDR passthrough to eliminate tonemapping? I doubt that iGPU can tonemap high bitrate UHD content without stuttering.

[rec head]

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.

[BryanC]

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

[JimH]

Thanks for the testing and the report, Bryan.

[davelr]

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.

[BryanC]

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.

[davelr]

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

[BryanC]

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

[Hendrik]

When testing on Linux? I am not quite sure pass-through can currently work on Linux, so you might be using tonemapping.

[BryanC]

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.

[Hendrik]

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.

[BryanC]

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.

[Hendrik]

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

[BryanC]

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.

[Hendrik]

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.

[BryanC]

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.

[BryanC]

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!

[tensionfire]

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

[bogdanbz]

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.

[jmone]

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.

[BryanC]

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.

[Hendrik]

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.

[BryanC]

Thanks, I'll try to find some replacements.

[Hendrik]

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.