Print

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

[jmone]

Madshi has released a new version of MadVR that has a new Display Mode --> Custom Mode that can create Custom Video Mode timings that can keep the Video and Audio clocks in sync that will:
- Prevent Dropped / Repeated Frames
- Does not require MC's Video Clock audio resampler
- Work with Decoded and Bitstreamed Audio (good for me when using Atmos)

The setup is rather involved and takes time to tune it in.  Here is the Tutorial. 

FYI - On my NVidia setup, I did not have to create any "Missing Modes", simply unchecked the "show native res modes, only" box and I could see all my resolutions and refresh rates.  I'm still working through setting up my first "optimized timing parameters" and will report back.  If you are going to try this make sure you turn off "Video Clock" in MC first.

[RD James]

I wish he would support variable refresh rate displays. Using custom display modes for this is archaic.

[Hendrik]

Variable refresh rate is not a home cinema feature, its found in gaming monitors, not in TVs or projectors, so it would be rather pointless for many people. This feature works for everyone, and videos are not really VFR to begin with.

[jmone]

First Impressions - For most users I'd still suggest using Video Clock.  It works and requires no user input at all.... as long as you are happy to decode the audio and not bitstreaming.  The new MadVR Custom Video Mode does work well but it takes some time to try a few of the custom settings and you will need to do this for each refresh rate that you use.  If you are a bitstreamer then this will be an option you will want to try.  It is great to have the option.

[RD James]

Variable refresh rate is not a home cinema feature, its found in gaming monitors, not in TVs or projectors, so it would be rather pointless for many people. This feature works for everyone, and videos are not really VFR to begin with.

HDMI 2.1 adds VRR support so it's not going to be restricted to monitors for much longer.
Technically everything with support right now is a gaming display, but the 34" 2.39:1 IPS monitor I have is very nice for watching movies on.
 
The point of supporting VRR is not for playing VFR videos, but that you present the video at its native framerate and the display syncs the refresh rate to it exactly, automatically, and without any mode switching required.
You could have a video playing at 23.976 FPS, a game running at 60 FPS, and a desktop application updating at 100 FPS, and the refresh rate changes dynamically as you mouse over each window.
 
Custom video modes on NVIDIA GPUs are also incompatible with Dynamic Super Resolution. (downsampling)
You cannot have both features enabled at the same time, and it's not quick to switch between the two - especially if you're using custom DSR resolutions which require editing the registry and restarting the GPU.
None of the default refresh rates for this monitor are a multiple of 24 or 24/1.001 either. Only 50/60/80/85/90/95/100.
It will accept a custom 96 or 96/1.001 resolution, but only if I disable DSR.
 

First Impressions - For most users I'd still suggest using Video Clock.  It works and requires no user input at all.... as long as you are happy to decode the audio and not bitstreaming.  The new MadVR Custom Video Mode does work well but it takes some time to try a few of the custom settings and you will need to do this for each refresh rate that you use.  If you are a bitstreamer then this will be an option you will want to try.  It is great to have the option.

It's good to hear that it works well, but frustrating that this is how it works.
I plan to upgrade to an Atmos setup later this year, which requires bitstreaming.

[Hendrik]

HDMI 2.1 adds VRR support so it's not going to be restricted to monitors for much longer.

And TVs are not going to adopt it, because it offers no value to them. Any consumer video sources are fixed refresh rate and fixed frame rate, afterall.

Not to mention that all VRR handling is designed around 3D engines rendering at their maximum speed, presenting a frame when its done, not presenting frames at a precise and accurate time, so I'm quite sure this would be quite the challenge and prone to timing glitches, as Windows is not a real-time operating system (while presenting on a VSYNC interrupt is driven by a hardware interrupt, and therefor accurate).

If such a day comes that actual TVs and projectors have wide-spread adoption of such features, I'm sure madshi will be open to the possibility. For now, its just dreams on gaming monitors.

PS:
That custom resolutions are incompatible with DSR is not a physical limitation of any sort. You should ask NVIDIA to fix that if you care to use both features at the same time.

[RD James]

And TVs are not going to adopt it, because it offers no value to them. Any consumer video sources are fixed refresh rate and fixed frame rate, afterall.

We'll see. Gaming is big business these days.
Being able to support any framerate within the range of refresh rates supported by the display, without requiring mode-switching has benefits for video - especially as HFR sources are introduced.
There's still no consumer release of The Hobbit films at their native 48 FPS due to this.
If you think of VRR as enabling the display to support 24-120Hz rather than fixed 24/50/60/120Hz rates, you might start to see its benefits beyond gaming applications.
 
I'm surprised at how much resistance there seems to be towards VRR support in the AV community though. "They'll never support it", "There's no benefit to it" etc.
Then again, this is an industry where low framerates are celebrated and even many people even prefer them over high framerates.
 

Not to mention that all VRR handling is designed around 3D engines rendering at their maximum speed, presenting a frame when its done, not presenting frames at a precise and accurate time, so I'm quite sure this would be quite the challenge and prone to timing glitches, as Windows is not a real-time operating system (while presenting on a VSYNC interrupt is driven by a hardware interrupt, and therefor accurate).

That doesn't seem to be a problem for games if you cap the framerate, but I'm not a developer.
 

PS: That custom resolutions are incompatible with DSR is not a physical limitation of any sort. You should ask NVIDIA to fix that if you care to use both features at the same time.

It's not, but it's the reality of the situation right now.

[Hendrik]

I'm surprised at how much resistance there seems to be towards VRR support in the AV community though. "They'll never support it", "There's no benefit to it" etc.

The resistance is against wasting time on extremely complex things that only work on high-end gaming setups, instead of just being happy that people try to solve problems we have today, and not problems we might have in 5 years. :p
Its always important to remember that one doesn't preclude the other, but this will help people today - and that is the reality of the situation.

Certainly being able to use any refresh rate might be nice, but there is just no point because there is no content. There willl always be common fixed frame rates, and if they are common then screens will support them. Un-common/non-standard rates will never be used until they would actually be able to be played on a wide range of systems. Its far more likely that future HFR content will be in 60 fps than screens starting to support 48 Hz (or VRR for that matter).

[RD James]

The resistance is against wasting time on extremely complex things that only work on high-end gaming setups, instead of just being happy that people try to solve problems we have today, and not problems we might have in 5 years. :p
Its always important to remember that one doesn't preclude the other, but this will help people today - and that is the reality of the situation.

Sorry, my issue was with people in the AV community arguing that there is no point in displays supporting VRR.
I understand why software may not support it until it is mainstream.
I'm not saying it's a bad thing that MadVR can set up custom resolutions now, just disappointed that Madshi has no interest in VRR support when it's a true solution to this problem instead of another workaround.
I certainly hope it doesn't take another five years, because G-Sync will be almost a decade old at that point.

Certainly being able to use any refresh rate might be nice, but there is just no point because there is no content. There will always be common fixed frame rates, and if they are common then screens will support them. Un-common/non-standard rates will never be used until they would actually be able to be played on a wide range of systems. Its far more likely that future HFR content will be in 60 fps then screens starting to support 48 Hz (or VRR for that matter).

There already is content. Sure, if you're only looking at movies, there is a limited amount of content right now, but it still exists, and more HFR content is being made.
I do agree that 60 FPS makes more sense than 48 FPS, since virtually all TVs can support it, but filmmakers like their multiples of 24 for some reason.
As we transition over to displays supporting HFR content (120Hz) it is very important that they also support VRR. It would be stupid to move from 60Hz to 120Hz without it. Fixed refresh rates are a legacy feature carried over from CRT displays.

[jmone]

VRR support would be nice if it removed the issue of the time it takes a TV to resync when you change refresh rates, but I don't see that it is designed to fix the issue of dropping/repeating frames due to the drift between the Audio and Video Clock.  We now have two solutions:
1) VideoClock (resample audio to keep in sync with the video refresh rates.... but only works with decoded audio and some will not like that it is resampled)
2) Custom Refresh Rates (fine tune the out of the box refresh rates to be closer to the Audio Clock rate - this needs to be done on a PC by PC basis as the clocks on every PC will be different.  MadVR now gives us this ability to tune the Refresh Rate.  Works with Bitstreaming as well as decoded audio and does not require either the Audio or the Video streams to be altered as they now both play in sync for hours).

[RD James]

VRR support would be nice if it removed the issue of the time it take a TV to resync when you change refresh rates, but I don't see that it is designed to fix the issue of dropping/repeating frames due to the drift between the Audio and Video Clock.  We now have two soln:
1) VideoClock (resample audio to keep in sync with the video refresh rates.... but only works with decoded audio an some will not like that it is resampled)
2) Custom Refresh Rates (fine tune the out of the box refresh rates to be closer to the Audio Clock rate - this needs to be done on a PC by PC basis as the clocks on every PC will be different.  MadVR now gives us this ability to tune the Refresh Rate.  Works with Bitstreaming as well as decoded audio and does not require either the Audio or the Video streams to be altered as they now both play in sync for hours).

VRR flips around the way that video sync happens, which eliminates the need for mode switching.
Instead of the display refreshing at a fixed update rate which the computer (or any other device) has to synchronize its output to, it only refreshes when it has been sent a new frame.
Since these displays don't flicker like CRTs did, it can seamlessly change "refresh rate" without the viewer being aware of it.
If you send it a frame every 40ms, the display is refreshing at "25Hz". Send it a frame every 10ms and it is refreshing at "100Hz". But this can change every frame.
If a frame is presented slightly early or late, you don't get dropped/repeated frames or stutters like you would with a fixed refresh rate display - the VRR display just updates slightly earlier or later, completely in sync with it.
 
That's why the focus has mainly been on gaming thus far.
With video, you're syncing up a fixed framerate source to a fixed refresh rate display - you just have to get the two close enough that they don't go out of sync over the course of 1-3 hours.
With games, the workload placed on the GPU is highly dynamic. To lock a game to 60Hz with V-Sync enabled, you might need 30% overhead to prevent it ever dropping below 60 FPS and stuttering.
With a VRR display you can unlock the framerate and let the game run at 60-78 FPS instead (assuming 30% overhead), and it will appear completely smooth since the monitor is updating in sync with the framerate.
It enables you to take full advantage of your GPU instead of having to keep that overhead, and you get a better experience since the average framerate is much higher.
It also means you're far less likely to notice if the framerate drops below 60 too. You could have a game running at 54-70 FPS instead - still keeping the average above 60 FPS, but relaxing the requirements somewhat.
 
So it is a much bigger deal for gaming, but having a video player/renderer which supports it has advantages too - especially looking forward to things like HFR content which adds more framerates to the mix.
We already have HFR content running at 48 FPS which current televisions cannot display - despite that being within the range of 24Hz and 60Hz that they do support.
Hopefully that explanation makes it clear why trying to sync up the output from a computer to the display is so chaotic, compared to simply presenting frames to the display and having it update as soon as they are received, and why all displays should support VRR going forward - even for video.

[jmone]

So I get that VRR can present the frame for as long as needed, the bit I don't get is the ability of the VRR to keep the two clocks in sync with the precision required to either not start dropping/repeating either the audio or video samples over a couple of hours.  I ??presume?? that at some point when the clocks drift out of sync by some ??margin?? it simply displays the next video frame for a longer or shorter period to bring them back into sync.  If so it will depend on how coarse these adjustments would be and how accurately the system will measure both clocks.

[RD James]

So I get that VRR can present the frame for as long as needed, the bit I don't get is the ability of the VRR to keep the two clocks in sync with the precision required to either not start dropping/repeating either the audio or video samples over a couple of hours.  I ??presume?? that at some point when the clocks drift out of sync by some ??margin?? it simply displays the next video frame for a longer or shorter period to bring them back into sync.  If so it will depend on how coarse these adjustments would be and how accurately the system will measure both clocks.

The reason audio and video gets out of sync on a PC is because video has to be presented to match the refresh rate exactly or else you have to drop/repeat a frame which causes it to stutter.
Since the refresh rate is typically not exactly matched to the video's framerate (which is what these custom display modes try to achieve) you have to adjust the video's speed to match the refresh rate - which throws it out of sync from the audio if you are bitstreaming.
 
Calling these displays "variable refresh rate" is misleading because you shouldn't think of them as having a refresh rate at all.
The GPU doesn't send a signal to the display saying "run at 60Hz, now run at 59Hz, now run at 61Hz" etc.
It sends frames to the display and the display updates as soon as one is received.
So the framerate determines when the display refreshes, you shouldn't think of the display itself as having a "refresh rate" at all.*
 
So you don't get that desync between video and audio because you are not having to adjust the video speed to sync it up with a refresh rate in order to prevent dropped/repeated frames.
You present the video at its original framerate and the display syncs itself to that.
Even if there are timing errors, those timing errors result in slightly late/early frames rather than dropped/repeated frames, which would be imperceptible.
I believe it would be kept within ±0.5ms, while a frame at 23.976 FPS is 41.7ms, and you can get several frames out of sync by the end of a movie on a fixed refresh rate display if you do not drop/repeat frames to minimize the desync.




*It gets more complicated than this, but I'm trying to keep the explanation simple. For our intents and purposes, there's no "refresh rate" to deal with.

[jmone]

Ok, Got it.  So we have 3 options:
1) VideoClock : Easy, works, and has been available for years (minus bitstreaming)
2) MadVR Custom Video Mode : Available now to tweakers, not yet part of MC.  Takes some setting up but works (decoding and bitstreaming audio)
3) HDMI 2.1 VRR : Does not yet exist in the real world for AVR setups.  Once/If it is supported you will need all new GPU, AVR, TV.  Will then also need the Video Renderer to support it.

[RD James]

Ok, Got it.  So we have 3 options:
1) VideoClock : Easy, works, and has been available for years (minus bitstreaming)
2) MadVR Custom Video Mode : Available now to tweakers, not yet part of MC.  Takes some setting up but works (decoding and bitstreaming audio)
3) HDMI 2.1 VRR : Does not yet exist in the real world for AVR setups.  Once/If it is supported you will need all new GPU, AVR, TV.  Will then also need the Video Renderer to support it.

G-Sync/FreeSync/VESA Adaptive-Sync displays all support it right now, and G-Sync has been around for 4 years at this point.
G-Sync/VESA Adaptive-Sync work over DisplayPort 1.2, FreeSync works over DisplayPort 1.2a or HDMI 1.2. (yes, 1.2)
 
We just don't have televisions or projectors which support HDMI 2.1 yet, since the spec was only announced earlier this year.
I'd expect to see them at CES in January. LG have been demoing 120Hz OLEDs for the past year or so.
It's unknown whether HDMI 2.1 will actually be required to support the VRR spec.
The Xbox One X has announced VRR support yet it only has HDMI 2.0 hardware. There's really nothing which should require HDMI 2.1 to support VRR, it's just that the feature is being introduced with it.
 
With Sony in the business of producing games consoles, Samsung having recently added Steam Link (in-home game streaming) to their televisions, and LG focusing heavily on improving Game Mode on their televisions in the past few years, I'm not expecting it to be an overlooked feature as some people have suggested.

[madshi]

@RD James, you seem to be missing a crucial problem:

Let's say madVR renders video frame 1. Rendering is complete. So it's sent to the display immediately. Now madVR renders video frame 2. Then, 5ms later, rendering for frame 2 is complete. However, it's a 23.976fps movie, so frame 2 is supposed to be shown exactly 1000/24*1.001 = 41.708333333ms after frame 1. Now how does FreeSync/G-Sync help here? If I do what games would do, namely present frame 2 as soon as rendering is complete, the movie would playback at about 10x playback speed. Do you find that useful? I don't.

So how to solve this problem? Once rendering of video frame 2 is complete, madVR basically would have to wait until exactly 41.70833333ms have passed after frame 1 was shown. However, Windows is not a real time OS, so it's impossible to make something happen at an exact point in time. If madVR would try to wait for exactly the right time, sometimes the frame would be shown slightly too late. If the CPU is busy doing something else for a few milliseconds (and that *can* happen!!!), with FreeSync/G-Sync, frame 2 would suddenly be shown after maybe 50ms instead of 41.70833333ms. And such timing changes are brutally visible to the human eye. Because of this problem using FreeSync/G-Sync like games do simply doesn't work for video playback.

The static V-Sync raster is somewhat archaic. But for HTPCs is really comes to the rescue, because we absolutely do need a fixed raster for video playback, because in order to achieve motion that looks perfectly smooth to the human eye, we need totally constant frame intervals, and the fixed V-Sync raster helps working around the problem that Windows (and Linux, for that matter) are not real time OSs. Technically, the reason why V-Sync works is that it's based on a hardware interrupt, and that's pretty much the only thing that helps OSs like Windows or Linux to achieve real time like attributes.

All that said, FreeSync may have a feature that allows to specify a new static refresh rate. Using that might actually be an option for madVR, but I'm not 100% sure it works the way I would need it. Furthermore, I've not found any such feature in the G-Sync documentation. So while it might be possible to make FreeSync work for video playback, it seems impossible with G-Sync atm.

Furthermore, I don't have the money to buy a FreeSync + G-Sync monitor for testing. Feel free to donate one to me, if this is so important to you.

[maid]

I am trying to set this up but the problem is my lg tv does not show up in the devices my Onkyo does?

[madshi]

It's not really a problem. If you have a receiver between HTPC and TV, it's always the receiver which shows up.

[maid]

but the tutorial states that we need this data to work with the setup.

Before we get busy, let's first have a quick look at the EDID (Extended Display Identification Data) block of my LCD monitor, which we will be working with in this tutorial:

[madshi]

Well, look at the EDID block of the receiver, then. Hopefully it passes all relevant information through from the display to the HTPC.

[maid]

There is no information there is only about 6 items all relation to the Onkyo
field edid version manufacturer id manufacturer name product code product name and manufacture date

No resolution or anything else

[madshi]

Then you're most probably using an outdated madVR version.

[maid]

I am about to update madvr as I am still using jriver 21.
Is there any easy step by step instructions anywhere???

[JimH]

I am about to update madvr as I am still using jriver 21.

Please don't.  We don't support this.

[maid]

ahh ok so i should upgrade jriver first?
   

[JimH]

What is your objective?

You could install the trial version of MC23 and then decide?

[madshi]

The objective is to use the new(ish) custom mode feature that was introduced in madVR v0.92.0.

[mojave]

maid, if you upgrade to JRiver 23.0.65 or newer you will have a madVR version that supports the custom mode feature.

23.0.65 (9/27/2017)
2. Changed: Red October HQ updated to madVR 0.92.4.

[maid]

Its been a long time since I upgraded and need help to upgrade painlessly as last time I did it I managed to screw up my library.

[Awesome Donkey]

In MC21 do a library backup, install MC23 and start it and restore a library backup. Easy peasy lemon squeezy!

[maid]

lol very funny hehe thanks
I didnt update this time as JRiver already does everything for me BUT and theres always a but.
I get jerky video at times.
I wanted to try the new madvr but it sounds complicated to set up
I use bitstreaming and my onkyo shows as the display not my tv

[madshi]

I get jerky video at times.

Does that jerky video problem go away when using Video Clock? If so, creating an optimized custom mode may help. If you still get jerky video with Video Clock, then the problem is probably something else and custom modes will probably not help, either.

[maid]

Cant use video clock as I am bitstreaming

[madshi]

That's fine. It's just meant as a quick test to see if custom modes even have a chance to fix that jerkyness. So basically enabling Video Clock (just as a test) will show you if custom modes can help fix the problem or not.

[maid]

Hi I have updated to version 23.
Can someone tell me do I use the display that I have highlighted?

[maid]

Which settings should i use here in general settings.

enable windowed overlay (Windows 7 and newer)

Changes the way that windowed mode is rendered, and will generally give you better performance. The downside to windowed overlay is that you cannot take screenshots of it with the Print Screen key on your keyboard. Other than that, it's mostly a “free” performance increase for people running Windows 7/8. It does not work with AMD graphics cards. D3D9 Only.

enable automatic fullscreen exclusive mode

[maid]

That's fine. It's just meant as a quick test to see if custom modes even have a chance to fix that jerkyness. So basically enabling Video Clock (just as a test) will show you if custom modes can help fix the problem or not.

voices go out of sync if I use video clock