madVR - high quality video renderer (GPU assisted)

[rbej]

Originally Posted by madshi

Ok, can you please make a debug log with this test build?

http://madshi.net/madVR895g.rar

Full screen and windowed.

http://www71.zippyshare.com/v/w9ImBFgK/file.html

[Asmodian]

Originally Posted by chros

What I can see on the images that Superres adds unwanted bright edges that can be visible at the red rectangles on the right side of the pictures.
Apart from this, I can't tell the difference between the tested 3 algos (NN, Jinc+AR, SX+AR), maybe the test video wasn't aproppriate for this.

In this situation I recommend you use Catmul-Rom or madVR's default of Bicubic 75, they are very close anyway.

These are quite fast/cheap but offer much improved quality compared to NN in past tests. Since you cannot see the difference even when using NN the more expensive algorithms are a waste of power but bicubic is low enough power the small improvements in scenes you haven't tested might be worth it.

Note: that 3-Color-Steps is probably one of the worst images to test chroma scaling options with. You want fine color details.

[XRyche]

Originally Posted by madshi

Thanks. Ok, it's official now: For some reason, creating the OpenCL command queue takes about 10 seconds on your PC. I don't know why, but that's how it is. This looks like a problem with your OpenCL installation. There's nothing I can do about it. It seems you can either try repairing your OpenCL installation somehow (I don't know how). Or alternatively you'll have to give up on NNEDI3 for now. I might offer a NNEDI3 option without OpenCL in the future.

Well that's disappointing to hear. When I upgraded to Windows 10 it must have messed up my OpenCL because it worked perfectly fine on Windows 8.1. Thanks for trying to fix my issue so diligently madshi.

I have an idea, might not be a good idea but it's an idea nonetheless.

Is anyone with NNEDI3 working on Windows 10 willing to give me a copy of their OpenCL.dll from their SysWOW64 folder?

[aufkrawall]

Has Display Driver Uninstaller been suggested before?
http://www.wagnardmobile.com/forums/...4a0da209cb9bc2

[XRyche]

Originally Posted by aufkrawall

Has Display Driver Uninstaller been suggested before?
http://www.wagnardmobile.com/forums/...4a0da209cb9bc2

I use that exact app every time I change display drivers. Thanks for the suggestion though.

[XRyche]

Unfortunately, the OpenCL.dll from someone's working NNEDI3 on Windows 10 didn't change anything. Anyone have any suggestions, besides rolling back to Windows 8.1?

[nevcairiel]

Originally Posted by XRyche

Unfortunately, the OpenCL.dll from someone's working NNEDI3 on Windows 10 didn't change anything. Anyone have any suggestions, besides rolling back to Windows 8.1?

Clean install, not upgrade.

[XRyche]

Originally Posted by nevcairiel

Clean install, not upgrade.

Well that's a pain. Oh well, I'd rather have NNEDI3 working properly so I guess I'll do just that. Thanks for the suggestion nevcairiel.

[aufkrawall]

Originally Posted by chros

Hhmmm... That's interesting. Maybe your card is so powerful, or it depends on lot's of things. Are you sure that you used D3D9 exlusive (old path)?

Yep. Probably it's really the slow hardware or driver for old hardware behaves differently.

[6ari8]

Originally Posted by XRyche

The first chroma entry is for chroma upsampling from 4:2:0 to 4:4:4. The second chroma entry is for chroma upscaling for matching the chroma to the luma upscaled resolution. I believe that's correct but if not fell free to correct me anyone.

If you're talking about this one then the resolution still doesn't match at the end since luma is downscaled whereas chroma is not.

Originally Posted by ryrynz

That's because madVR isn't displaying the quad superxbr scaling that happens automatically alongside the luma scaling.

It has to match before it gets displayed.

I think it shows it in the double chroma line version but what is confusing is that the components' resolution doesn't match if we go by the OSD (everything matches until Luma is downscaled).

Originally Posted by nevcairiel

If it says "Image" in the OSD, it refers to scaling both Luma and Chroma at the same time (otherwise it would say Luma)
So what it really does is only 2 steps

1) Double Chroma to 712x480, now matches Luma
2) Double the entire image twice (both Luma and Chroma) to 2848x1920, then downscale both components to 1920x1080

That's how I understood it when the OSD was like this (before 89.05):


But this one (89.05) doesn't make sense to me


because it doesn't match the luma and chroma resolutions.

Originally Posted by madshi

This looks like a bug. When using super-xbr, luma and chroma should be treated the same way, so I have to check why the OSD reports them with different scaling paths.

It's not limited to suber-xbr though. It shows the same info when choosing NEDI as well.

But even though the scaling paths are treated differently, doesn't it show that the luma and chroma resolutions are not matched?

Video resolution: 712x480, 4:2:0
chroma > super-xbr                                                | 356x240 > 712x480
luma > super-xbr > super-xbr < Catmull-Rom AR                     | 712x480 > 1424x960 > 2848x1920 < 1920x1080
chroma > super-xbr > super-xbr                                    | 712x480 > 1424x960 > 2848x1920

[madshi]

Originally Posted by rbej

Full screen and windowed.

http://www71.zippyshare.com/v/w9ImBFgK/file.html

Does this build work better?

http://madshi.net/madVR895j.rar

Originally Posted by 6ari8

It's not limited to suber-xbr though. It shows the same info when choosing NEDI as well.

As I already said, it looks like a bug. Try any of the recent test builds, it should already be fixed in there.

[rbej]

Originally Posted by madshi

Does this build work better?

http://madshi.net/madVR895j.rar

Now works perfect on full screen. Thanks!!

[madshi]

madVR v0.89.6 released

http://madshi.net/madVR.zip

* updated AdaptiveSharpen to latest version
* added support for ISubRenderCallback3 interface
* optimized DXVA fullscreen playback performance
* fixed: freezes when closing media player, or switching to different monitor
* fixed: another DXVA related crash
* fixed: subtitle positioning was sometimes incorrect with MPC-HC/MPC-BE
* fixed: disabling desktop composition was broken
* fixed: slow switching between two h264 TV stations with identical resolution
* fixed: OSD scaling information was sometimes incorrect
* fixed: "setZoomOffsetX = -1" resulted in madVR totally stopping to work

[rafi.hamid]

for gtx 980ti and i5 4690 what is the best settings?
thanks


Sent from my iPad using Tapatalk

[James Freeman]

The best of the best or only the best?
madVR is the best of the best of the best, so it has a point where you get diminished returns and a huge electrical bill with the best of the best of the best settings.


Start here: http://forum.doom9.org/showthread.php?t=171787

[panetesan2k6]

Originally Posted by James Freeman

The best of the best or only the best?

Best answer I can give you is to read this and form your own opinion:

http://forum.doom9.org/showthread.php?t=171787

[rafi.hamid]

thanks for help
that link is to complicated for me because I am a beginner and also not good enough in English language.
what you think about below link is it good for me?
https://imouto.my/madvr/


Sent from my iPad using Tapatalk

[James Freeman]

Originally Posted by rafi.hamid

what you think about below link is it good for me?
https://imouto.my/madvr/

Yes, good enough.

It's important to emphasize that there is a point where madVR will use a LOT of resources without visible difference.
Especially "Image Doubling".

Use Nvidia Inspector to look at how much % of the GPU and Memory is used.
Ctrl+J in the player will open madVR OSD that will show stats, look for dropped frames.

Go slowly and observe.

[Siso]

Speaking of settings, how do you guys determine which mode is best for your configuration old path, new path, overlay, frames in advance, back buffer queue etc. What is the criteria? Average stats-rendering times, present?

[aufkrawall]

Thanks for the bugfixes and especially the new AS version.

I know that I don't tell you anything new when I speak of the brightness issue the sharpen algorithms have.
This example doesn't have a great video quality, but I think it shows the issue well enough (1080p -> WQHD):

madVR SuperRes (strength 2, radius 0.66):


madVR SuperRes + 0.2 AS (after SR):


Even with this low sharpen strength, some things get noticeably brighter in an inconvenient way and madVR's SuperRes alone doesn't fight the upscaling blur (I don't want to use super-XBR with high sharpness since it has big problems with ringing of the source). FS or LS are even worse.

Shiandow's SuperRes makes the image crispy without altering the brightness in some areas too much:


It has the problem of boosting some lines too much and this can look weird, yes.
But I think this is mostly a problem with very low res content. It's hardly noticeable with 1080p -> WQHD, unlike the increasing brightness with AS.

madVR SuperRes + AS:


Shiandow SuperRes:


For this reasons, I'd be very thankful if you could offer Shiandow's algorithm as an alternative option (e.g. replace the mostly useless radius option with it). Maybe it would be possible to improve sharpens algorithms to prevent brightness issue, but this might consume a lot of time and success maybe isn't granted.
Another reason would be that AS isn't quite cheap. It has been ported to ReShade and it eats up 15% performance of GTX 980 OC, which is a lot on top of SuperRes.
I hope it wouldn't cost too much time to implement it (e.g. in comparison to improving sharpen algorithms), otherwise I wouldn't ask for it.