madVR - high quality video renderer (GPU assisted)

[cork_OS]

Yes, I think we really do need some good compression artifact reducer.
Great news!
My GPU can ran sXBR+SR1 or NGU-med, but not NNEDI3. So I vote for sXBR should remain until madVR get own denoiser/deblocker/demosquitoer.
BTW latest KNLMeansCL is fast enough for real-time SD (720x480) processing.

[huhn]

well i got in a huge problem with my GTX 960 with some very heavy slow downs (AVG 60 ms or more) using a 3D LUT and this is completely gone with the RX 480.

this could come back with a 1060 so i'm in a pickle one would say.
but that's not your problem.

ohh these drivers...

[burfadel]

Is FreeSync active? Can you totally disable it? Does that help?

No it doesn't :). I had it turned off by mistake actually! Probably from testing earlier. The screen is set at 72 Hz though as the base frequency (Samsung S27F350).

Is madVR DirectX 11.0? What's the difference in terms of madVR would there be between 11, 11.1, 11.2 (from Windows 8.1), and 11.3 (Windows 10)? Not suggesting that's why it's not working, they are just adding on the earlier versions so they are still supported.

Direct3D 11.4 (TH2, updated in RS1):
https://msdn.microsoft.com/en-us/library/windows/desktop/mt661819(v=vs.85).aspx

Direct3D 11.3 (Windows 10) additional features:
https://msdn.microsoft.com/en-us/library/windows/desktop/dn914596(v=vs.85).aspx

Direct3D 11.2 (Windows 8) additional features:
https://msdn.microsoft.com/en-us/library/windows/desktop/dn312084(v=vs.85).aspx

Direct3D 11.1 (Windows 7 with platform update, and later):
https://msdn.microsoft.com/en-us/library/windows/desktop/hh404562(v=vs.85).aspx

[flossy_cake]

That's why madVR presents (up to) 16 frames in advance.
Now compare that to a FreeSync/G-SYNC solution, where motion would already start stuttering if the CPU is blocked for just a couple of milliseconds!


You can prerender frames in gsync mode too (in the nvidia control panel "max prerendered frames") and it wont stutter anyway because you still thinking in vsync logic. In gsync you can have frame delivery like this 38ms->42ms->40ms->35ms->42ms and its perfectly smooth because interframe delta is so small compared to the average. But one dropped frame at 60hz is disasterous because it creates this massive 33.4ms spike delta.

[HillieSan]

I've no idea why the RX480 is so slow with NGU. I can only imagine that the drivers have issues with what my PS3.0 shaders are doing, for some weird reason. I might still try running the NGU shaders in D3D11, but I'm not convinced it will make a difference. I'm hopeful the problem might be fixed by newer drivers at some point. If you can't wait, it might make sense to replace the RX480 with an NVidia card, for the time being...

That said, I'm considering bringing back super-xbr next weekend.

Please, try the DXD11. Currently, madVR works best with DXD11 on RX480. DXD9 has issues with FSE. It only works (not stable though) when I clear all 'trade quality for perfomance' options.

[nevcairiel]

Fair enough. So you'd also like super-xbr to stay (or rather come back)?

Like I said before, I didn't have time to test NGU yet, so I can't really say if it would replace all my needs. But in general an alternative without the extra complexity of OpenCL might not be a bad idea.

it wont stutter anyway because you still thinking in vsync logic. In gsync you can have frame delivery like this 38ms->42ms->40ms->35ms->42ms and its perfectly smooth because interframe delta is so small compared to the average.

No, its you who is still thinking in gaming logic. Video frames are from an exact point in time, if you don't manage to present it at that exact point in time, it (micro-)stutters. No magic in the world can fix that. It needs to be shown at the precise point it was meant to be shown.
Matching V-SYNC to the video frame rate gives you that result perfectly. And as it happens, typical monitor refresh rates match the typical video frame rates. So all is well as it is!

Its not like V-SYNC drops plenty frames, if your system is setup properly you get flawless playback without a single dropped frame, so absolutely no stuttering.

[madshi]

BTW latest KNLMeansCL is fast enough for real-time SD (720x480) processing.
KNLMeansCL is a good denoiser, I think, but I'm not sure it's the right algo for compression artifact removal.

well i got in a huge problem with my GTX 960 with some very heavy slow downs (AVG 60 ms or more) using a 3D LUT and this is completely gone with the RX 480.
Argh.

No it doesn't :). I had it turned off by mistake actually! Probably from testing earlier. The screen is set at 72 Hz though as the base frequency (Samsung S27F350).
Ok. So the problem you're having is only in combination with the display being sent to sleep? As long as that doesn't happen everything's fine?

Is madVR DirectX 11.0? What's the difference in terms of madVR would there be between 11, 11.1, 11.2 (from Windows 8.1), and 11.3 (Windows 10)?
Rendering is a mixture of D3D9, D3D11, DirectCompute and OpenCL. Presentation can be done in either D3D9 or D3D11. 11.1, 11.2, 11.3 doesn't make a difference for me.

You can prerender frames in gsync mode too (in the nvidia control panel "max prerendered frames")
And if you do prerender 3 frames in advance and present them in advance with G-SYNC, at which exact interval are they displayed on screen?

In gsync you can have frame delivery like this 38ms->42ms->40ms->35ms->42ms and its perfectly smooth because interframe delta is so small compared to the average.
No, 35ms vs 42ms is not perfectly smooth at all. It might be smooth with a game but not with a video. It seems to me you don't really understand the difference. With a game, if you have 10ms -> 10ms -> 10ms -> 40ms, then a car moving from the left side of the screen to the right side, will move a little -> little -> little -> lot. Because of that it's not a big problem if the exact frame intervals vary a bit. With video the situation is different. The position of the car is already defined by the recorded video. If you have 10ms -> 10ms -> 10ms -> 40ms, that would be a catastrophe for video, because the car moves the same amount in each frame. For video we need *perfect* frame intervals. And unless G-SYNC can deliver that, it's useless for video.

[burfadel]

Please, try the DXD11. Currently, madVR works best with DXD11 on RX480. DXD9 has issues with FSE. It only works (not stable though) when I clear all 'trade quality for perfomance' options.

That's funny! It's much the same for me but D3D11 doesn't work well! D3D9 actually runs quite beautifully.

It's not just the sleep that can trigger the D3D11 issue, it can happen any time. It seems to only affect D3D11, D3D9 is either unaffected or less affected. I don't mean full sleep mode either, just turning off the monitor after 5 minuutes (or setting it to trigger at a button press through power options). I think it's because it puts the card to sleep since it isn't used without needing to display anything, and madVR doesn't seem to like that.

In terms of performance though, the new version is much better on the RX 480. You mentioned a workaround with an earlier build for AMD cards and D3D11, I am wondering whether that workaround affects the RX 480 or at least is required any more, if it is still in place.

[leeperry]

You can disable chroma NGU by setting "chroma quality" to "normal". You can select luma NGU directly, not sure what you mean there.
Oh OK cool, this wasn't documented anywhere. I'll do my homework and read the OSD then :o

Is it? Why would the "image downscaling" settings page play any role when we actually upscale the video? I think you're stuck in the old way the settings worked. Once you understood it, it made sense, but it was kinda backwards. The new settings are very strict: The "image downscaling" options are now only used when we actually downscale the video. Every option that plays a role when we upscale the image is now actually in the "image upscaling" settings page. That is not confusing but more logical, IMHO, if you try to forget what you were used to from older madVR builds and look at this with a fresh set of eyes.

Well, I use CR AR LL to downscale doubled 720p@1080p and SSIM2D100LL+50%AB to downscale SD, this isn't possible anymore? No more AB for doubled upscale anymore? SR needs it badly you know :scared:

Why not using the "image downscaling" settings when downscaling doubled upscale? I really don't see the need for an extra "downscale quality" option there, especially when all it does is Bicubic150 AR and SSIM1D100 without AB :(

Most ppl messing with this will create automatic profiles anyway and as much as offering an option to set Jinc upscale when doubling didn't make sense I don't see the need for a "downscale quality" preset when the "image downscaling" panel will remain completely unused?

You said "For downscaling after doubling in most cases Bicubic150 AR should be good enough" but I certainly don't want that and I don't find SSIM2D overkill when downscaling doubled upscale as it's very sharp and retains a lot of resolution that Bicubic150 is certainly unable to provide. And again I very much need AB there when using SR on SD.

JFWIW, did you ask for super-xbr to stay when I asked for feedback when releasing v0.90.0/1?

I don't recall having to ask for things to stay hah, I only thought that SR would be ditched so I whined about that but several ppl claimed that sxbr worked better than NGU for them on noisy low-res so I didn't think you would dismiss it altogether. Anyway, I can see that others raised the subject so I would fully agree that sxbr can be useful at times.

[e-t172]

Here's one example used by Frafs Test Pattern app (DX9). You can use the command line argument to select a fps limit to engage the hires timer and turn on the scrolling bar to check for dropped frames.

Source code of area where hires timer is implemented
https://sourceforge.net/p/frafstestpatt/code/HEAD/tree/trunk/_FrafsTestPattern.cpp#l872
https://sourceforge.net/p/frafstestpatt/code/HEAD/tree/trunk/src/FRHiResTimer.cpp

Note: cpu usage is quite high with the hires timer (~15% CPU load ). I was able to eliminate it by adding a 1ms sleep on line 916 of FrafsTestPattern.cpp.

Also
https://msdn.microsoft.com/en-us/library/aa964692(v=vs.85).aspx

This is a software timer that relies on a user-mode software thread to be woken up at precisely the right time. Which is not a viable option in a non-realtime OS such as Windows. The frame interval needs to be managed purely in hardware (i.e. the GPU, like in fixed VSync) to achieve high-quality playback. This is the only way to guarantee high precision of frame presentation times.

I think you are making an assumption about frame time deltas of 33.4ms (1 dropped frame at 60hz) and trying to apply that to a delta of +/- 5-10ms, which proves you don't own one of these variable monitors because if you did then you would already know that in D3D applications while the fps/hz meter is fluctuating up and down all over the place the motion is still seamless because the inter-frame delta is still much much lower than 1 dropped frame at 60hz. You are still thinking about everything snapping to the nearest 16.7ms which is not the case here. A rapid rise from say 24-90 in gsync will still have an average inter-frame delta that is very low and nowhere near the 33.4ms caused by 1 dropped frame at 60hz.

A delta of 5-10 ms is unacceptable for video playback (which is not the same as video games), and would be a regression from the current fixed VSync approach. I was not assuming deltas of 33.4ms.

Of course there are no guarantees. At the end of the day the CPU is still running the application regardless of the scenario and relies on not being interrupted by other processes. If the vsync implementation is done by the CPU (such as waiting for a vsync signal) then it will be vulnerable to the same problem if some other process interrupts it.
When you call Present , thats still a CPU command that could be blocked or delayed by the OS kernel for a few ms.

No, because these calls are made in advance. madVR is telling the GPU "hey, at the next VSync, present this frame, then, at the VSync after that, present this other frame, etc.". After that madVR's job is done, and the GPU just goes through the queue of pre-rendered frames on every VSync event, purely in hardware, with no software interrupts involved. As madshi explained, if the present call is delayed by a few milliseconds (or even tens of milliseconds), nothing bad happens, as long as there are still frames in the queue. In other words, frames are buffered in hardware, precisely to avoid the problem you're mentioning. You can even configure the size of that queue in the madVR settings.

Now, in theory it should be possible to do that with G-Sync too, but now you can't simply tell the GPU "hey, present this frame on next VSync" anymore, because there is no periodic VSync event anymore. Instead, madVR needs to tell the GPU "present this frame at this exact time" (relative to the GPU's hardware clock, presumably). Problem is, there is no API to do that. Hence, madshi cannot properly implement G-Sync in madVR.

Note that none of the above applies to video games. Which is why you should stop making comparisons to video games. It's not the same use case at all and the constraints are fundamentally different.

Matching V-SYNC to the video frame rate gives you that result perfectly. And as it happens, typical monitor refresh rates match the typical video frame rates. So all is well as it is!

Its not like V-SYNC drops plenty frames, if your system is setup properly you get flawless playback without a single dropped frame, so absolutely no stuttering.

That's not entirely true, though. In practice it is very difficult on PC to perfectly match the video refresh rate to the actual playback rate of the video, because playback is slaved to the audio clock, not the video clock, so you will always get a slight mismatch, which will cause quite a few dropped/repeated frames over the duration of a full-length movie. This is why we have things like ReClock or Smooth Motion, but these are basically hacks that shouldn't be needed in the first place.

G-Sync could help with this, because it would allow madVR to automatically compensate for clock mismatch by slightly adjusting presentation times based on an observed estimate (basically like ReClock, but operating on video timings, not audio timings). But, as madshi already pointed out in the new FAQ, that's only viable if there is a way to use G-Sync while still presenting multiple frames in advance (and having the GPU time the refresh in hardware), otherwise it's going to jitter like crazy and the slightest delay in madVR presentation thread scheduling is going to result in a visible hiccup.

[huhn]

nearly every g-sync monitor is HFR so just use smoothmotion.
smoothmotion at 120 hz or more is a totally save.
the audio clock mismatch is fixed this way too.

[HillieSan]

That's funny! It's much the same for me but D3D11 doesn't work well! D3D9 actually runs quite beautifully.

Yes, that's funny. Are you using the latest software? (MPC-HC+LAV+madVR+AMD Drivers). What Windows version are you using?

A few months ago I couldn't use DXD9 at all. Now after a few updates of AMD drivers, madVR and blueskyFRC it seems that DXD9 works. I can't tell who caused/fixed this problem. However, sometimes I get a black screen when switching to FSE. I use now DXD11 and it works well.

BTW I use Windows 10 and I have no DXD9 game installed. Windows 10 includes DXD11. Would it made a difference if I had installed an DXD9 game?

[leeperry]

Why would the "image downscaling" settings page play any role when we actually upscale the video?

Because we are downscaling double resolution? 1280x720>2560x1440>1920x1080 = downscale.

Having more thoughts about it, you might as well add a "downscale quality: use image downscaling settings instead" suboption if it really makes sense to you to leave them unused for some reason, so newbies can still use the three existing presets and experts can still go the older way : everyone's happy :)

I very much would like to still be able to run CR AR LL to downscale doubled 720p@1080p and SSIM2D100LL+50%AB to downscale SD :(

[StinDaWg]

Not sure I'm crazy about the limited presets for downscaling after image doubling either. I always used AR+LL for downscaling, but you are saying with these presets that LL is "wrong" or that it is "placebo"? I can see the difference between LL on and off, especially with white text, but I don't know which is "correct". I thought the consensus was that you were supposed to use LL for downscaling?

If it's not needed then it's not needed, just would like some clarification.

[leeperry]

^ +1, I've A/B'ed a number of times and I much prefer LL for downscaling whatever sxbr or NGU. I think my proposition in my previous post will make everyone happy, hopefully madshi will not objecthttp://forum-images.hardware.fr/images/perso/zigg.gif

[Crimson Wolf]

well i got in a huge problem with my GTX 960 with some very heavy slow downs (AVG 60 ms or more) using a 3D LUT and this is completely gone with the RX 480.

this could come back with a 1060 so i'm in a pickle one would say.
but that's not your problem.

ohh these drivers...

I'm just curious about your problem with the GTX 960. Have you monitored your gpu/mem clock while you were experiencing these slow downs? IIRC, a few drivers ago, the "optimized power" settings limited my gpu/mem clock to 650mhz/800mhz even though my madvr settings were high load playing with MPC-HC64. I had switched to adaptive power and it was fine, until I played a x265 8-bit 720p to 1080p (using doubling) and it went back to the lower power setting again for some strange reason. Another x264 file did not have this issue. I have now set MPC-HC64 to be max performance.

[Gagorian]

I'm just curious about your problem with the GTX 960. Have you monitored your gpu/mem clock while you were experiencing these slow downs? IIRC, a few drivers ago, the "optimized power" settings limited my gpu/mem clock to 650mhz/800mhz even though my madvr settings were high load playing with MPC-HC64. I had switched to adaptive power and it was fine, until I played a x265 8-bit 720p to 1080p (using doubling) and it went back to the lower power setting again for some strange reason. Another x264 file did not have this issue. I have now set MPC-HC64 to be max performance.

I concur with this. On my GTX 1070 playback is stuttering without max performance forced in the NVIDIA control panel. Driver updates also seem to revert this setting back.

[burfadel]

Yes, that's funny. Are you using the latest software? (MPC-HC+LAV+madVR+AMD Drivers). What Windows version are you using?

A few months ago I couldn't use DXD9 at all. Now after a few updates of AMD drivers, madVR and blueskyFRC it seems that DXD9 works. I can't tell who caused/fixed this problem. However, sometimes I get a black screen when switching to FSE. I use now DXD11 and it works well.


I use Windows Insider 14971, Crimson 16.11.4, latest MPC-HC BE and LAVFilters.

I think you may have a similar issue to me just a lot less extreme. I do actually get the black screen when it switches to full screen mode now... with D3D 11. However, now it doesn't like D3D 9 either and freezes. Most of the time MPC then becomes locked, and sometimes you can play the video again, but requires me to usually hard reset (hold the power button). I can't keep doing that in testing since it won't do the computer any good continuously restarting.

So, same settings, I've now gone from D3D9 exclusive to D3D11 windowed. When it works it works beautifully, but ironically if I play around with the settings and it freezes, the same settings may not work the same again even if I reset madVR, clear the shader cache (I disabled it anyway but didn't help). I even tried a different install location of madVR.

So, not sure what's going on. I can't pinpoint it to any specific setting. It's damned annoying that I can't just close it off and reopen (hard reset required).

If it is insider build related, even though it was like it in the last build too, you have to keep in mind that RS2 is due in 4 months, so if it is compatibility related it needs to be quashed. Since on the same build it worked with the R9-280X and not with the RX 480 (and the new monitor), I think it's not related to that.

[wanezhiling]

http://forum.doom9.org/showthread.php?p=1787718#post1787718
@madshi, plz check.

[HillieSan]

I use Windows Insider 14971, Crimson 16.11.4, latest MPC-HC BE and LAVFilters.

I think you may have a similar issue to me just a lot less extreme. I do actually get the black screen when it switches to full screen mode now... with D3D 11. However, now it doesn't like D3D 9 either and freezes. Most of the time MPC then becomes locked, and sometimes you can play the video again, but requires me to usually hard reset (hold the power button). I can't keep doing that in testing since it won't do the computer any good continuously restarting.

So, same settings, I've now gone from D3D9 exclusive to D3D11 windowed. When it works it works beautifully, but ironically if I play around with the settings and it freezes, the same settings may not work the same again even if I reset madVR, clear the shader cache (I disabled it anyway but didn't help). I even tried a different install location of madVR.

So, not sure what's going on. I can't pinpoint it to any specific setting. It's damned annoying that I can't just close it off and reopen (hard reset required).

If it is insider build related, even though it was like it in the last build too, you have to keep in mind that RS2 is due in 4 months, so if it is compatibility related it needs to be quashed. Since on the same build it worked with the R9-280X and not with the RX 480 (and the new monitor), I think it's not related to that.

I have only DXD11 presentation and V-sync enabled. You can also enable exclusive full screen mode. I disabled all 'quality for perfomance' options (may not be necessary). I use DVXA copy-back or none in LAV Video. DXVA native was buggy.

I had instability problems after updating madVR, and I had to run 'install.bat' (in admin mode) once after every update of madVR.

[Budtz]

I cant find upscaling settings now. does it only show now if it is needed?

[tFWo]

Well, madVR is in danger of literally going MAD and developing a split personality. :devil:

On one hand we have things like the profile system that lets power users configure everything to their liking.

On the other there is the need to streamline/simplify options for normal users.

Every piece of software in the history of the universe has failed at balancing these two hands. Unfortunately I can see the same thing happening to madVR. :( Power users end up disappointed with the lack of options (compared to the earlier builds) and normal users never have enough knowledge to not be confused with the remaining options. It has all happened zillion times before.

Limiting the choices for downscaling after image doubling is a great example of this problem. You are taking away the choice from the power user AND you are making your own profile system less useful. If the end goal is completely removing the profile system, then I can understand this. But I don't recall you mentioning it.

On the other side I doubt that the normal user is less confused with this new option. You still have a downscale option in the upscaling/doubling section. Without a proper explanation (tooltip?) the normal user still has no idea what that thing does.

As others have already suggested a simple "downscale quality: use image downscaling settings instead" would fix this for the power user. For the normal user I am afraid that only a complete settings UI overhaul will make things less confusing.

P.S. sxbr should stay! It’s still the performance/quality ratio king for slower cards (haven’t tried new ngu low yet)

[StinDaWg]

Is there such a thing as a "normal" user in regards to madVR though? No one I know in real life has ever used or has a clue what madVR is.

I'm not sure why the new shift to catering towards "normal" users is for. madVR is only used by super nerdy videophiles. And super nerdy videophiles want to customize everything.

[flossy_cake]

With video the situation is different. The position of the car is already defined by the recorded video.

Game physics usually decoupled from the rendering so the car moves the same amount as it does in 2d video. The scenario you describe is like the whole physics engine slowing down to match the render rate which is extremely rare to find a game like that.


No, 35ms vs 42ms is not perfectly smooth at all. It might be smooth with a game but not with a video.

I can repeatably witness it smooth with my own eyes. I cannot deny my own senses otherwise I'd have to be radically sceptical about everything. Do you believe it when people witness smooth motion on the variable gsync framerate demos such as the windmill/pendulum demo or do you think they are all just stupid and just can't detect judder? Because that is one hell of a conspiracy if you believe it. Gsync is for people who are allergic to judder, it's the complete opposite of everything you are making it out to be. It's the solution, not the problem.


And if you do prerender 3 frames in advance and present them in advance with G-SYNC, at which exact interval are they displayed on screen?

Maybe you could tell me because MadVR is producing 50fps gsync on my European video files in full screen mode.

My guess is that your code already implements an accurate timer of some sort or the display driver is taking care of it somehow.

otherwise it's going to jitter like crazy and the slightest delay in madVR presentation thread scheduling is going to result in a visible hiccup.

I find it offensive to even use jitter and gsync in the same sentence :D

This is a software timer that relies on a user-mode software thread to be woken up at precisely the right time.
Which is not a viable option in a non-realtime OS such as Windows.

The frame interval needs to be managed purely in hardware (i.e. the GPU, like in fixed VSync) to achieve high-quality playback. This is the only way to guarantee high precision of frame presentation times.

Apparently the Windows high precision timer uses a dedicated hardware clock called HPET.
https://en.wikipedia.org/wiki/High_Precision_Event_Timer
You may need to enable it at the windows command line with the "bcdedit /set useplatformclock true" command.

[FreeFall]

Just another vote in favor of giving advanced users back control of the upscaling / downscaling and chroma settings used with image doubling.

Cheers.

[mueslibrown]

Well, madVR is in danger of literally going MAD and developing a split personality. :devil:

On one hand we have things like the profile system that lets power users configure everything to their liking.

On the other there is the need to streamline/simplify options for normal users.

Every piece of software in the history of the universe has failed at balancing these two hands. Unfortunately I can see the same thing happening to madVR. :( Power users end up disappointed with the lack of options (compared to the earlier builds) and normal users never have enough knowledge to not be confused with the remaining options. It has all happened zillion times before.

Limiting the choices for downscaling after image doubling is a great example of this problem. You are taking away the choice from the power user AND you are making your own profile system less useful. If the end goal is completely removing the profile system, then I can understand this. But I don't recall you mentioning it.

On the other side I doubt that the normal user is less confused with this new option. You still have a downscale option in the upscaling/doubling section. Without a proper explanation (tooltip?) the normal user still has no idea what that thing does.

As others have already suggested a simple "downscale quality: use image downscaling settings instead" would fix this for the power user. For the normal user I am afraid that only a complete settings UI overhaul will make things less confusing.

P.S. sxbr should stay! It’s still the performance/quality ratio king for slower cards (haven’t tried new ngu low yet)

Tend to agree (full disclosure I'm not a software developer nor a UI specialist) ... without knowing madshi's timeline for v1.0 release or what features/functionality comprise that event, I'd be inclined to continue catering to the power users after all they are going to provide the best critique of features and the most difficult to please (as most geeks are ...). The normal user and I include myself here will have to muddle through for now. At a later stage changes to the UI and providing a wizard or relevant presets could be layered on for the 'joe public' user - assuming madshi is going mainstream as thats where the actual money will be ... Just my uninformed view.

[aufkrawall]

Have to agree with twfo. I finely tuned everything with different profiles for every scaling factor, and now that kind of control is simply not possible anymore.
If we have to make a clean cut, then I'd vote for making the UI even simpler by deleting lots more of it. But then on the other hand, we need complete commandline/script control for advanced users, still offering every possible configuration. Otherwise, imho we end up with something just crippled.

I haven't tested yet if new NGU low is a good replacement for s-xbr. Dunno if low + low quadrupling is even possible atm. Can test at home later.

[Ver Greeneyes]

I'm not sure why the new shift to catering towards "normal" users is for. madVR is only used by super nerdy videophiles. And super nerdy videophiles want to customize everything.
Because even super nerdy videophiles can shoot themselves in the foot, as evidenced by (among other things) people either forgetting to disable NGU chroma doubling or disabling it but using an expensive algorithm for image upscaling.

I'm not saying the new system is perfect (I haven't played with it yet), but I can understand the desire for clarity and reducing the amount of useless combinations.

[leeperry]

"chroma quality: automatic" chooses Bicubic60 AR for doubling chroma, except when using NNEDI3-128/256 or NGU-VeryHigh. In that case NNEDI3-16 respectively NGU-Med is used instead.
Well, I'd like to use Jinc AR for chroma if I have chroma NGU disabled and prefer to beef up luma NGU.....Not possible anymore either? But you said that NGU-low is just as fast as Jinc so I'll have a go at all this ASAP :)

[GCRaistlin]

I think that GUI should suggest good decisions in some way but definitely not prevent an user to make his/her own ones, even if they seem to be incorrect.

[paranoya7]

v0.91.3 and v0.91.2 cant find any scaling algorithms now. "These settings are unknown to this version of the settings browser." What is that problem and what should i do? v0.91.1 setting come back.

[FreeFall]

paranoya7,

Try re-installing madVR and then run the restore default settings.bat file and see if that fixes the problem.

[burfadel]

I have only DXD11 presentation and V-sync enabled. You can also enable exclusive full screen mode. I disabled all 'quality for perfomance' options (may not be necessary). I use DVXA copy-back or none in LAV Video. DXVA native was buggy.

I had instability problems after updating madVR, and I had to run 'install.bat' (in admin mode) once after every update of madVR.

Really? Sounds like in some respects yours is as bad as mine. My old R9-280X can handle these settings and NGU, the RX 480 definitely should! I do tweak it for quality that I like.

You definitely should not have to have anything under the performance options enabled, and be able to use NGU, DX11 dither, image enhancements such as thin edges, enhance detail, adaptive sharpen, anti-ringing, add grain (under upscaling refinement), and smooth motion on the 480 since a 280X can handle it fine!

It's not so much performance now (massively improved but still not ideal in v0.91.3, its the instability. Everything else works fine :).

[jkauff]

@madshi, I've been testing 0.91.3 this morning, and just like with 0.91.1, I can use higher settings with D3D9 than with D3D11 enabled.

GPU is GTX 1060 6GB running on Win 10 build 1607.

Doesn't bother me to use D3D9, but I'm curious why the performance difference?


EDIT: I'm a UX Designer, and I think the changes you've made to the Settings UI are very good and quite well thought out. If you wanted, you could even add an "Easy" mode for beginners, with an Image Enhancement page with only Low, Medium, High, and Very High choices. The defaults are that good (assuming use of NGU).

[nevcairiel]

I can repeatably witness it smooth with my own eyes. I cannot deny my own senses otherwise I'd have to be radically sceptical about everything. Do you believe it when people witness smooth motion on the variable gsync framerate demos such as the windmill/pendulum demo or do you think they are all just stupid and just can't detect judder? Because that is one hell of a conspiracy if you believe it. Gsync is for people who are allergic to judder, it's the complete opposite of everything you are making it out to be. It's the solution, not the problem

You are once again and repeatedly ignoring the fact that those demos are rendered in real-time, they are not recorded videos.
Videos do not work like real-time rendered 3d scenes, which is the entire point several of us have been trying to bring across to you for several posts.

If a video was recoded at 24p, then its frames are exactly 41.6ms apart. Exactly that. No other interval is acceptable. Not 40ms, and not 43ms, and certainly not 35 or 50ms.

G-SYNC and FreeSync are awesome for 3D rendering in games and the like, the increase in smoothness is extremely noticeable. I have a screen myself. However, video playback is not a 3d game - that is the entire and only point everyone has been trying to make.

[Backflash]

Well, I'd like to use Jinc AR for chroma if I have chroma NGU disabled and prefer to beef up luma NGU.....Not possible anymore either? But you said that NGU-low is just as fast as Jinc so I'll have a go at all this ASAP :)

Chroma setting are in chroma upscaling and you can set jinc there no problem.
chroma that is in image upscaling is for double chroma

I will say this again, it took me a while to understand as well.

The only thing that changed is doubling settings, now it's simply condenced in one menu,, and they haven't changed that much you still have same options there as before.
LL for SSIM is one of two things you can't set for double resolution downscaling.
And other thing is superxbr in doubling. No idea why would we need xbr for doubling anymore with new low for NGU though, maybe didn't test enough SD sources.
There is still a lot of confusion how to adjust other settings for NGU, because it conflicts with a lot of refinements and people think that it's worse than tested algorithms when it's in the very least it's equal PQ wise if set up properly.

[pose]

madshi, some really needed changes with the new build! I like the new interface a lot! NGU works smoother on my RX470 now.

[MariaX9]

I also like the new GUI way more.

[aufkrawall]

Uff, it's impossible now to do any kind of NGU quadrupling with 2x the same NGU settings.
I can't test quality like this, this is really bad. :(

[Backflash]

Uff, it's impossible now to do any kind of NGU quadrupling with 2x the same NGU settings.
I can't test quality like this, this is really bad. :(

Wait, it didn't work in previous builds anyway, because it's not finished as far as I remember, and you still can do that for NNDI3.

[flossy_cake]

G-SYNC and FreeSync are awesome for 3D rendering in games and the like, the increase in smoothness is extremely noticeable. I have a screen myself. However, video playback is not a 3d game - that is the entire and only point everyone has been trying to make.

I see no reason why it should make a difference, both ways we are just presenting a final 2D raster at a certain time interval.

I'm out of this thread because it's giving me cancer. Bye.

[aufkrawall]

Wait, it didn't work in previous builds anyway, because it's not finished as far as I remember, and you still can do that for NNDI3.
It worked in previous builds.
I was talking about the classic quadruple (aka 2x double), not new one-step quadruple madshi currently is working on for NGU.

[plasma]

I am in favor of the simplifications of the gui. My account may be new but I have been using madvr since more than a year.

[plasma]

I see no reason why it should make a difference, both ways we are just presenting a final 2D raster at a certain time interval.

I'm out of this thread because it's giving me cancer. Bye.

The cognitive dissonance is astounding. How dare you use gaming hw such as freesync monitors. Madvr is for HTPC. But requiring high end gaming graphics cards is totally fine

[Betroz]

@ madshi

I have tried the newest madVr version and I miss the ability to set the upscaling settings like before. With the max awailable NGU settings, it does'nt fully utilize my GTX 1080 card anymore. This is my settings (with Chroma Upscaling set to NGU-VeryHigh) :

http://bildr.no/thumb/NTFHK2Nx.jpeg (http://bildr.no/view/NTFHK2Nx)

Here is a OSD screen of a 480p, 29 fps clip :

http://bildr.no/thumb/SjljMzJJ.jpeg (http://bildr.no/view/SjljMzJJ)

Max 8.34ms rendering... I could have used much higher settings, but with newest madvr, that is not possible.

Here is a OSD screen of a 720p, 23 fps clip :

http://bildr.no/thumb/bU9vRjJ2.jpeg (http://bildr.no/view/bU9vRjJ2)

Same here. Am I missing something here? My image quality was better with 0.91.1 version of madvr with my (higher) settings there.

[pose]

Betroz, you are example of why the changes were made. Smh...

[Betroz]

Betroz, you are example of why the changes were made. Smh...

Uhhhh explain please...

[fedpul]

Hi, I want to report a bug, I can't select chroma quality very high when using luma NGU High. (I just was testing different profiles and discovered it), looks almost the same with automatic.

I also would like to say that I really like the new GUI, found it more intuitive than before, and easier to use for noobs or starters. But as usual you need to know what you are doing!

[e-t172]

Apparently the Windows high precision timer uses a dedicated hardware clock called HPET.
https://en.wikipedia.org/wiki/High_Precision_Event_Timer
You may need to enable it at the windows command line with the "bcdedit /set useplatformclock true" command.

That's not enough, though. You don't just need a hardware timer, you also need a solution that will quickly take the appropriate action when that timer fires (in this case, triggering a screen refresh). HPET will not do that for you, as it knows nothing about video. Sure, you could use HPET to wake up a software thread that does the refresh (using a present call, I presume), but then you're at the mercy of Windows thread scheduling delays, which translates to jitter. HPET is great for measuring time, but it's not very helpful for triggering actions, because it doesn't fix the thread scheduling problem (and other sources of delays such as in the GPU driver).

This issue does not apply to traditional fixed VSync because the GPU is in charge of refreshing the screen on every VSync interval, and that refresh is both timed and acted upon entirely in hardware by the GPU output circuitry itself, with no software components involved. This guarantees that screen refreshes will occur on time and with negligible jitter.

The cognitive dissonance is astounding. How dare you use gaming hw such as freesync monitors. Madvr is for HTPC. But requiring high end gaming graphics cards is totally fine

Again, G-Sync/FreeSync would be great for video playback in theory. In practice however, it is not viable for video playback unless GPU manufacturers provide an API for presenting frames in advance with hardware-enforced timestamps in G-Sync/Freesync mode (see madshi's FAQ). This is not about a lack of interest, it's about technical feasibility.

Also, not everyone uses madVR with "high end graphics cards". There are people, such as me, who use madVR mostly for its reliable, smooth playback and features such as dithering, 3DLUT support and Smooth Motion, and have little interest in extreme power-hungry upscaling algorithms. Just because most of the discussion in this thread is about upscaling does not mean everyone cares about upscaling.

[Crimson Wolf]

@flossy_cake

It seems perfectly clear to me why madvr can't use adaptive sync tech (freesync/g-sync). You seem to assume madvr can generate in between frames in a video file when it's impossible. It's like setting pre-rendered frame to infinite. If you record a ball flying across the air on a video, if you examine all the frames individually frame by frame, you see it in a certain position as it moves along the screen. If a frame is delayed by half a frame, you can't generate where to ball should be in half a frame delay. For a game, it's easy since it "knows" where the ball should be at ANY TIME.

Unless everyone here that has been trying to explain to you is wrong about the way adaptive sync works, there's no simple and easy way to implement support in madvr.

EDIT: "bcdedit /set useplatformclock true" is bad advice. Just leave it to windows to choose which timer it should use.