Print

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

[SamuriHL]

Yes, I absolutely do split them. All my devices are connected to the VRROOM.  My receiver is 2.0a and doesn't support eARC.  So that's connected through HDMI out on the VRROOM and no video is passed to it.  Audio to the display is muted so it's only receiving a pure video signal.  This setup works extremely well for me.

[TheShoe]

Thanks both.  Interesting and something to research.

[Manni]

Just to say that I tested the latest nVidia studio driver 565.99 and if doesn't seem to drop frames with HDR passthrough, so it might be an option for some.

Unfortunately, my long Atmos freezes/drops are back with that branch, irrespective of the frame rate, so I'm back with 546.65. No frame drops in HDR passthrough, and only occasional micro audio drop (usually at most one per film, if any), as long as I'm in 4K119 (I haven't tested at 4K23 with 546.65).

It's annoying, but far less of an issue than the 3-5 seconds long freezes/drops that I get with more recent (and older) drivers, where the picture freezes for like 150-250 frames, I have no sound for that duration, then trhe picture catches up and I get the sound back. One is a slight annoyance, the other a dealbreaker.

I really wish that nVidia could get rid of this issue once and for all.

[SamuriHL]

Saves me the time to test it myself.    I'm sticking to the same driver for the moment until a new game requires a newer one.

[Manni]

Saves me the time to test it myself.    I'm sticking to the same driver for the moment until a new game requires a newer one.

Do you also have the long Atmos drops? If not, the latest driver might be an option for you. Many people with the same GPU (3090) don't have this issue with Atmos.

[SamuriHL]

Oh yes, I have the ATMOS issue with other drivers.  it drives me nuts.  3080 on my machine.

[Manni]

Oh yes, I have the ATMOS issue with other drivers.  it drives me nuts.  3080 on my machine.

Ah, sorry but good to know. Do you also have the micro audio drops (up to one per film) with 546.65?

[SamuriHL]

Yup.  I tend to get more than one usually 3 or 4 depending on the length of the film.  But they are there.  Definitely not as bad as the complete dropouts in other drivers.

[Manni]

Yup.  I tend to get more than one usually 3 or 4 depending on the length of the film.  But they are there.  Definitely not as bad as the complete dropouts in other drivers.

Good to know that our setup seems similarly afflicted, even if I'd prefer for you not have the issue. Indeed, it means that we can save each other's time! Please let me know if you ever find a way to fully fix it. I'll do the same...

[SamuriHL]

Yea definitely.  Will do.  I'm using my HTPC less and less these days for the reasons we already discussed so it's not as big of an issue anymore.  But it would be nice to solve it regardless.

[Manni]

Thanks for the new option to enable HDR early.

I've installed build 55, enabled the new option in setings/video/display, and disabled OS HDR.

I'm getting the following results with driver 546.65, playing a 4,000nits title (Pacific Rim) with a 1050nits target for HDR to HDR using BD folders and full menus (my default frame rate is 119p, so there is no refresh rate change) full screen:

- I always get the correct peak of 1050nits for the main title, but I still get empty/desktop metadata on the menu itself on occasions. It might be a VRROOM issue, so let's ignore that.
- It takes a lot longer for the picture to display after the HDMI resync when HDR is enabled, even though playback has started (I can hear the sound). At least 10 seconds, up to a minute. Usually the TV goes past the black screen and to a "can't get signal" screen. I never had this issue before. Note: I get the same long sync time when switching to HDR in the OS manually, so if JRVR is simply doing this automatically this is normal in my setup, but when I use OS HDR it only happens once, it's not before each title so it's less noticeable.
- If I disable the new option in the display settings, I don't get the correct metadata (1050nits) but NV HDR is enabled in a few seconds, as was the case previously.
- Either way, if I switch between HDR passthough and HDR to HDR while playing content using the menus, the correct metadata is still not sent (it should switch between 1050nits and 4,000nits) even after I close the settings. I haven't tried doing this with profiles because there is no way AFAIK to assign a profile to a hotkey.

If I enabled OS HDR before I start playback, the correct metadata is sent (1050nits) right away, as expected. However JRVR still doesn't send the correct metadata when you switch between HDR passthough and HDR to HDR, even after I close the settings.

Anyone getting different results? Does using the new option in display settings also significantly increase your HDMI sync going from SDR to HDR?

Although I'm very grateful for the new option, it's not usable here from a practical point of view, so I'm back to enabling OS HDR permanently, which also has the advantage of not causing any HDMI resync for 23p HDR titles if the default/desktop is set to 4K119p (or 4K23).

I thought about it and I don't think it's possible for JRVR to switch between HDR and SDR when the OS HDR is enabled, so I don't think there is a way for JRVR to bring SDR 3D LUT back when OS HDR is enabled.

As my current display is accurate enough in SDR without a 3D LUT and given that SDR played as HDR works fine since build 49, I'll therefore keep using the workaround of enabling OS HDR all the time.

However, is there a way to correct the wrong metadata that is sent when switching during playback between HDR to HDR and HDR passthrough? Or is this considered an edge use case that doesn't need fixing, as most people (including myself) would not switch between these modes during playback, except for testing the improvements brought by HDR to HDR tonemapping?

[Hendrik]

However, is there a way to correct the wrong metadata that is sent when switching during playback between HDR to HDR and HDR passthrough? Or is this considered an edge use case that doesn't need fixing, as most people (including myself) would not switch between these modes during playback, except for testing the improvements brought by HDR to HDR tonemapping?

JRVR always hands the correct metadata to Windows, if it changes every frame, or once in a settings change. It would be up to Windows to update the metadata send to the display - which it might not do, since HDR metadata like this is designed to be static, not dynamic.

[Manni]

JRVR always hands the correct metadata to Windows, if it changes every frame, or once in a settings change. It would be up to Windows to update the metadata send to the display - which it might not do, since HDR metadata like this is designed to be static, not dynamic.

Thanks. I checked and it's the same with madVR, so nothing worse with JRVR. Most likely the OS that doesn't update. I agree that these are not supposed to change.

[Manni]

Happy to confirm that 555.99 doesn't drop frames in HDR passthrough (or HDR to HDR). I have also found a couple of workarounds to the Atmos audio dropouts, but as this issue isn't specific to HDR passthrough, I've created a new thread to discuss it: https://yabb.jriver.com/interact/index.php/topic,139110.0.html.

If you experience the Atmos audio dropouts issue with a 3xxx GPU when going through an HDMI 2.1 AVR, please provide data and contribute.

[SamuriHL]

I'll update my driver at some point when I get a minute. That's good to know.

[Manni]

I'll update my driver at some point when I get a minute. That's good to know.

Make sure you make a system image before you do so. I only had micro Atmos dropout with 546.65, I got the long freezes again with the new driver and wasn’t able to get just the micro drop outs when I reverted to 546.65 (even after a clean install). The new driver has no frame drops in HDR passthrough, but it’s only usable because of the 8bit workaround I mention in the other post.
I could go back to my last system image if I wanted to, so make sure you have one.

[SamuriHL]

Maybe I'll just leave it alone for now.  LOL

[Manni]

Maybe I'll just leave it alone for now.  LOL

You could still test the two partial workarounds with 546.65 and report back if you don’t want to try the latest.

[SamuriHL]

You could still test the two partial workarounds with 546.65 and report back if you don’t want to try the latest.

I intend to.  Just need to find time.  This is going to be a very busy summer and time is going to be more limited for HTPC projects than I'd like.

[Manni]

I intend to.  Just need to find time.  This is going to be a very busy summer and time is going to be more limited for HTPC projects than I'd like.

No worries, I understand. Let's discuss in the other thread.

[Manni]

Just to say that I've done some testing with the 1080ti and the latest 555.99 driver and the correct metadata is never sent with HDR to HDR, whether the new option in display settings is selected or not, and whether OS ODR is selected or not before playback.

Same with HDR passthrough. The HDR metadata is always empty.

When the new option is enabled, the HDMI sync isn't longer as with the 3090, but it as no effect.

I'll try with the 4080 super tomorrow, let's hope it works otherwise I'll try to revert back to 546.65

[Manni]

I've received the 4080 Super and I'm happy to report that HDR metadat works fine with it in all situations. Plus, when OS HDR is disabled before playback, HDMI sync only takes a normal 3-5 secs, as expected, so that's entirely usable in order restore 3D LUT feature with SDR content.

I'll guess I'll set the OS HDR depending on what I'm watching primarily (HDR most of the time and SDR if watching an SDR TV Series or something).

Anyway, this is HDR metadata issue can be considered fully fixed with a recent 4xxx GPU. I assume that what I experience now is what Hendrik was experiencing.

Really weird that some GPUs behave differently in this regard, and can be as bad as the 1080ti, ie no HDR metadata ever.

This, along with the fact that the 1080ti started to display frequent and intermittent sparkles makes me less guilty about getting the 4080 super.

Happy to report that there are no frame drops with HDR passthrough with the 4080 super with the latest 555.99 driver.

Will now test the Atmos dropouts and will report back in the other thread.

[EDIT 22-jun-24: I've edited the first post and title to reflect the fact that all these issues are resolved with a 4xxx GPU]

[TheShoe]

"This, along with the fact that the 1080ti started to display frequent and intermittent sparkles makes me less guilty about getting the 4080 super"

Not exactly what your sparkles look like, but in the distant past, I had sparkles, particularly noticeable in very dark scenes (eg. a lot of blacks).  This was cured by setting the driver to limited color vs RGB.  Occurred with my 1080ti all the time - first time I noticed it was on my PS4 in games, and then as I was messing around with color settings in the nVidia control panel app, when I tried to set to RGB/Full I would get that effect.  Not in every movie.  My test to reproduce it was to run the intro to Labyrinth where the CGI owl is flying around the screen during the opening credits.  It was very noticeable there.   

Assuming we're talking about the same "sparkle" effect

For my 3000 and 4090, it's been a non-issue regardless of the color settings.

[Manni]

"This, along with the fact that the 1080ti started to display frequent and intermittent sparkles makes me less guilty about getting the 4080 super"

Not exactly what your sparkles look like, but in the distant past, I had sparkles, particularly noticeable in very dark scenes (eg. a lot of blacks).  This was cured by setting the driver to limited color vs RGB.  Occurred with my 1080ti all the time - first time I noticed it was on my PS4 in games, and then as I was messing around with color settings in the nVidia control panel app, when I tried to set to RGB/Full I would get that effect.  Not in every movie.  My test to reproduce it was to run the intro to Labyrinth where the CGI owl is flying around the screen during the opening credits.  It was very noticeable there.   

Assuming we're talking about the same "sparkle" effect

For my 3000 and 4090, it's been a non-issue regardless of the color settings.

Thanks but I never had that before with any of my GPUs, including the 1080ti. I think it's just getting old and is starting to fail.
What I call sparkles in this case are intermittent full wihite pixels that were there even on the windows desktop, so 100% not video levels related. More visible on dark background, so I could see them easily on the film covers in CMC, before I even launched a title.

In any case, the 4080 is gone and the 3090 is back in the HTPC, four films now without any drop (the last one was a DTS:X one for good measure).
The 1080ti is mostly used as a headless additional GPU in the E-GPU for the Dell XPS 17, so sparkles won't matter there

[TheShoe]

Roger that.  The problem ultimately is that there are too many links in the chain, and I suspect a lack of real adherence to "standards" - it must be a nightmare for JRiver, Microsoft, vendor X/Y/Z to ensure any consistency and reliability.

video card, AVRs, TVs, quality of HDMI cables (that is a thing!), splitters (in your case), various drivers, OS patch levels, various operating systems, and on and on...

This is why "good enough" or "good enough for government work" is the standard

But the nit pickers like you, me, others, and the high standards of a company like JRiver are important - because then "good enough" is darn good, and those willing to go the extra miles can really benefit

[JimH]

On behalf of JRiver, thanks TheShoe!

And thanks to manni and SamuriHL and others for their patience in finding solutions and sharing them.  It's very rewarding to watch.

[Manni]

Roger that.  The problem ultimately is that there are too many links in the chain, and I suspect a lack of real adherence to "standards" - it must be a nightmare for JRiver, Microsoft, vendor X/Y/Z to ensure any consistency and reliability.

video card, AVRs, TVs, quality of HDMI cables (that is a thing!), splitters (in your case), various drivers, OS patch levels, various operating systems, and on and on...

This is why "good enough" or "good enough for government work" is the standard

But the nit pickers like you, me, others, and the high standards of a company like JRiver are important - because then "good enough" is darn good, and those willing to go the extra miles can really benefit

Agreed that it's a miracle when it works. But even when that happens, it never does for long.

Family still banned from using the network, I just got 3 or 4 micro drops when watching an Atmos film.

I've decided to go back to my Oppo for watching critical 4K blurays with immersive sound (with the added advantage of full FEL profile 7 support with the Oppo, as you know), and only use the HTPC for series and blurays. I don't think we'll ever get perfection, and I barely have any drop outs with bluray and SDR TV series when bitstreaming, and definitely none when not bitstreaming. I use the MyMovies app on iOS as a front end of ther Oppo and the Dune, it's not as nice as CMC but at least I can get reference audio and picture quality.

By the way, for those interested, I've done some chroma tests with both the 4080 and my 3090, and when you don't use the OS HDR 4:4:4 chroma is downscaled behind the renderers back by my Samsung S90C (at least when using 4K100p+ in RGB 10bits with PC mode and game mode disabled to get filmmaker mode and good calibration). I only get 4:4:4 if the OS HDR is enabled, which means that I can't use a 3D LUT anyway for my SDR content.

[tkolsto]

Theshoe, I use supra hdmi cables and never had any problems with it, but that can change? Could buying a new cable be worth trying? and if so what cable do you use?

I use jrvr, hardware accelrated..and video clock set to off and I dont tick on "use the displays hdr" in jrvr. so in osd it says sdr 8 bit.

I usually get 1 to 3 framedrops during a movie and  1 or 3 repeated frames. If I am lucky I only get 2 repeated frames. This could be on the same movie too.
I have tried ticking off videoclock and so and also tick off hdr passthrough...but to no avail.

I understand Manny use complicated setup 3d Lut, which I dont use I do as little change as I can to not create problems for myself. But If I understand correctly, a rtx 4000 series gpu could solve my setup too?

I tend to stay away from hdr stuff as they create more artifacts(especially in difficult tricky motion or very fast motion) and microstutter.

I use local movie files that I have downloaded and try to stay to remux files. (no server too).

( I noticed a new box to tick under display settings; use hdr if available. why is there an option here for hdr? is this jrivers own hdr management instead of using the displays hdr capability? ..ok forget about this question, I tested it out and is was the same as to tick on hdr in jrvr settings.)

[JimH]

Toggle hardware acceleration.  It sometimes has problems, maybe driver related.

[TheShoe]

Theshoe, I use supra hdmi cables and never had any problems with it, but that can change? Could buying a new cable be worth trying? and if so what cable do you use?

I don't think replacing your cables will solve frame drops. 

My point was that poorly made cables can cause visual artifacts.  Not sure about frame drops.  I've had a few cables in the past that were just junk and replacing them solved the problems I was having at the time.  I cut the ends open to see what was inside and it was just really shoddy build quality, I know a little something about this stuff to recognize poor craftsmanship.  Since then, I've been using Audio Quest HDMI cables and have never had an issue with playback.

I've been watching a lot of shorter content lately and have not had frame drops I can recall.  The last couple movies we didn't have issues either, but the issue seems pretty random, and I know that no two setups are equal here.

[tkolsto]

What kind of artifacts did hdmi fix? was it artifacts due to motion? like around moving objects?(mostly in front of faces/heads or objects in motion)?

And may I ask which one of audioquest cable do you have?, there are many.

https://www.hifiklubben.no/kabler/hdmi-kabel/?brand=AudioQuest

[bogdanbz]

I am using a 6 bucks HDMI 2.1 cable for years and have no issue with a permanent 40Gbps (120Hz 10bit full RGB) connection (not 48Gbps as the TV can't handle 12 bit input). Never understood how people can spend so much for snake oil cables.

[rpro]

Regarding the frame drops in HDR passthrough, as explained in the first post in point #5, as far as I can see this is caused by a conflict between JRiver and whatever nVidia driver you're using. I reported it a while ago (when I was getting framedrops), then it got fixed by a later nVidia driver, then it got broken again recently... I'm currenty using 546.65 and I have no frame drops in HDR passthrough with JRiver. Did you try it? If you haven't, please try it and report back. Henrick has said in the past that he would try to implement options to try to deal with this (similar to the number of frames in advance etc in madVR, because madVR or MPC-VR don't have the issue), but he hasn't commented on this in this thread.

Yeah I've tried many drivers, even went back to an old driver that was suggested - that worked for a while, but after a month or two the framedrops came back.

So to mitigate them (and this worked for several months until recently, on the same driver!), I did some experiments. If I see a framedrop while watching a video (JRVR, 4K video in an MKV from a streaming source, although I've also seen it on regular Blu-ray remuxes), I would do the following until the framedrops went away:
1. Take JRiver out of fullscreen into windowed mode.
2. Right click anywhere in the video's viewport to get a popup menu to appear.
3. Go back to fullscreen.
This had worked for me in the past. It's almost like there is some problem with mouse input coupled with windowed/fullscreen that "resets" something. Perhaps mouse/keyboard input was being polled too fast, or the input polling (or maybe even GUI render of UI elements?) itself took time away from video frame generation, causing stutter? I don't know.

It is odd that this doesn't affect MadVR. I wonder if maybe JRiver is communicating in some way with JRVR, causing latency, that doesn't occur when using MadVR?

I also used Afterburner's frame time/latency OSD to verify the frame stutter - jagged-looking graphs until I do the above. Using MPC-HC and MadVR, they are smooth as butter.

[Manni]

Because the DV data doesn't actually communicate its level directly. It just says "do this to the image", and the levels are more of a marketing thing / a set of features. But I've added a check to disable processing if an Enhancement Layer is present, which should effectively disable Profile 7 entirely.
Of course this only worked in the first place if you remuxed a BD into MKV or something, because it then moved the DV data into the main video track, similar to how Profile 5 or 8 are setup, rather then a separate track on the actual Blu-ray, where its not seen unless you go specifically looking.

We don't use the DV tonemapping features, only the image transformation features (which is of most importance for Profile 5, which is otherwise unwatchable, but also results in an improved image with Profile 8 ). As long as its working properly, there should be no reason to want to turn it off.
The EL would fall into the same category - make a better HDR10 image (or would we call it HDR12 since it usually adds bitdepth?), but processing it is not supported yet.

This way it also benefits you when doing full pass-through, as it applies the DV improvements and creates an improved HDR10 image. (Why the HDR10 image wasn't just like this from the start, you ask? Partly compression advantages, partly to make DV sell more)

Not sure it will help or is relevant, but I recently found out that the correct way to process a DV title when FEL is present and you can't process it is to convert profile 7 to profile 8. This makes it possible to keep the DV metadata in order to help with the tonemapping, instead of discarding everything (including RPU) due to the possible brightness jumps.

Apparently, profile 7 has these flags in the RPU header:

"el_spatial_resampling_filter_flag": true,
"disable_residual_flag": false,

When processing Profile 7 DV without the EL, the RPU should be converted to Profile 8 and this has these flags set opposite in the header:

"el_spatial_resampling_filter_flag": false,
"disable_residual_flag": true,

Not sure it would make any difference now as you don't use the DV dynamic metadata in JRVR anyway, but I just thought I'd let you know as you said that you planned to take it into account in the future.

AFAIK, the above is the way recent media players with the Amlogic 928x chipset (new 8K Dune and Zidoo for example) handle DV titles with FEL, as they can't process the FEL due to the limitations in the DV implementation (even if the hardware would be capable as they have the processing ability to process the two streams concurrently). Of course UGOOs circumvent that with Corelec and handle FEL titles fully.