madVR - high quality video renderer (GPU assisted)

[chros]

Originally Posted by aufkrawall

There's no difference for me. On the right side, there is new windowed path and on the left side, it's old FSE mode:

It's the same with old windowed path.
My test case was 1080p60 -> WQHD with Jinc3 + SuperRes 2 passes + Adaptive Sharpen.

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

Here're my results (see my signature for details):
0. I'd been done testing on the 1080p TV, using nvidia with DXVA-copyback in LAV video, dithering on, all trading performance are switched off, no smooth motion, no other processing. I tried to select the lowest gpu and memory freq where the queues are still full. (max values: gpu 745MHz, ram: 2000MHz)
1. I managed to use Overlay mode (finally): but only with iGPU (intel) and only when I was tested on TV (my AV receiver is recognized otherwise as a cloned display device, that's why I got blank picture when I tried it on my laptop screen )
2. 720p (1280x720) 25fps video, chroma Jinc+AR, luma Jinc+AR:
- D3D9 FSE new path: gpu 690MHz, mem 2000MHz (gpu usage: 90-92%)
- D3D9 FSE old path: gpu 450MHz, mem 800MHz !!! (gpu usage: 97-99%, but playback is without a problem)
3. 1080p (1920x1080) 23.976fps video, chroma super-xbr+AR:
- D3D9 FSE new path: gpu 490MHz, mem 900MHz (gpu usage: 90-92%)
- D3D9 FSE old path: gpu 405MHz, mem 405MHz !!! (gpu usage: 80-82%) This result is actually insane!!! -> we use the lowest settings in P8 state (P12->P8->P5->P0)
4. The above values are valid. Both GPU-Z and nvidiainspector shows them, plus the thermal monitor app for CPU and GPU is also right on both cases.
5. I noticed 1 more thing in my system: the new path is way more ram consuming then the old one. In both tests I had to raise the ram clock not just the gpu clock.
6. All the rest of the modes (FS Windowed new/old path, FS Overlay, FS D3D11) were about the same speed like FSE new path was (only D3D9 old path is different completely).
7. The results were similar when I tried it out on the intel iGPU (with different scaling algos, since it's not so powerful than the nvidia), D3D9 FSE old path was way faster than the rest.
8. conclusion: if you do care about performance AND you don't/can't use NNEDI3 AND you don't use 10bit output, then give the D3D9 old path a chance! You can test how it behaves within 5 minutes.

Madshi, what could cause such a big performance difference?

Originally Posted by madshi

It's a technical limitation and there's not much I can do about it, without totally rewriting the "old exclusive mode".

You don't need t worry about it, since it's the fastest mode for me, thanks!

Originally Posted by madshi

It's possible, but difficult, due to 2 reasons:
1) You'd need to find an image, ideally some high quality RGB photo, where different chroma upscaling algorithms would show clear differences. In order to find such an image, you need to know what to look for. E.g. dark content with lots of black and red usually is a good idea. You should use an RGB photo which has full resolution chroma, maybe even scale it down a bit in RGB, so that the chroma channels really have full resolution and quality.
2) You need to convert the image to YCbCr 4:2:0, and you can't do that by simple downscaling chroma. You need to use the correct chroma offset, too! The chroma channel is not in center position compared to luma channel. It's slightly offset for all newer video codecs (MPEG2, h264, VC-1, h265 etc). Maybe LAV Video Decoder applies the proper offset when forcing it to output NV12? I'm not sure. @nevcairiel?

Sorry, but this was like Chinese language to me
I made a chroma comparison test with the video "mp4.v2c\Misc Patterns\A - Additional\3-Color Steps.mp4" from AVS.HD.709.v2d.Calibration of AVSforum, in windowed fullscreen mode, the zipped pngs are here: http://www10.zippyshare.com/v/bDzpW31T/file.html
(NN: nearest neighbour, SX: super-xbr+AR, Jinc: Jinc+AR, SR: superres strenght1, SR2: superres strenght2)
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.

[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?