madVR - high quality video renderer (GPU assisted)

[ryrynz]

Originally Posted by 6233638

I agree, but when it's not dropping frames or showing other issues, I don't really have anything else to go on.

Chart GPU usage over a short period and compare, lower GPU usage should translate to faster processing.

[cyberbeing]

Until you implement a way for madVR Overlay to use the active calibrated GPU CLUT, as well as take screenshots post-resize & processing, I don't think you should even be considering it as a default.

[ikarad]

Originally Posted by Niyawa

Image Downscaling
Ultra-tier: Catmull-Rom. AR enabled, Linear enabled.
High-tier: Catmull-Rom. AR enabled, Linear enabled.
Mid-tier: Catmull-Rom. AR enabled, Linear disabled.
Low-tier: Catmull-Rom. AR disabled, Linear disabled.
Lowest-tier: Bilinear.

What do you guys think? Looks pretty sweet.

Why catmull rom and not lanczos?

With catmull rom, there is more aliasing than lanczos if you see red bars.

I don't understand why catmull rom would be better than lanczos.

catmull rom


lanczos

Originally Posted by madshi

madVR v0.85.5 released

http://madshi.net/madVR.zip

* fixed: DXVA deinterlacing: when GPU couldn't keep up, audio sync got lost
* fixed: odd source rectangles could result in "green" images (DXVA)
* fixed: display mode changer sometimes didn't work for DVDs
* slightly modified "use separate device for DXVA processing" behaviour
* changed scaling defaults once more (Bicubic75, Lanczos3, Catmull-Rom)
* disabled "perform deinterlacing in separate thread" by default
* DXVA NV12 conversion routine now uses 16bit float instead of 32bit (faster)
* up to 56% speed improvement for Jinc3    chroma upscaling
* up to 40% speed improvement for Jinc3 AR chroma upscaling
* up to 53% speed impr. for Jinc3/4     image upscaling with 2x scaling factor
* up to 47% speed impr. for Jinc3/4 AR  image upscaling with 2x scaling factor
* up to 39% speed impr. for non-Jinc    image upscaling with 2x scaling factor
* up to 27% speed impr. for non-Jinc AR image upscaling with 2x scaling factor
* up to 44% speed impr. for non-Jinc    image upscaling with 3x scaling factor

Please note that the speed improvements only apply in very specific circumstances. E.g. the Jinc chroma upsampling speed improvement only applies to 3-taps (with or without AR). There's no improvement for Jinc4/8 chroma upscaling. And all the other improvements only apply if there's an *exact* 2x or 3x scaling factor requested by the media player. With any other scaling factor there's no improvement at all for image scaling performance. The exact scaling factors of 2x and 3x allow me to write hard wired shader code which runs more efficiently, thus the speed improvement. There are no further similar improvements for other scaling factors planned. The 3x scaling factor improvements only apply when not using AR. There's no improvement for 3x AR image upscaling.


-------

Once again I need your FEEDBACK:

I'm trying to figure out again which defaults to use for a couple of options. I'm especially interested in these:

(1) "perform deinterlacing in separate thread". This was enabled in earlier madVR builds by default. It's now disabled by default in v0.85.5. With my AMD GPU, there's no difference. My NVidia GPU runs slightly better with this option disabled.

(2) "use a separate device for presentation". This was and still is enabled by default. It used to be a good method to reduce glitches with older NVidia drivers. I'm wondering if this option is still beneficial today with both NVidia and AMD GPUs. I've been told this option can make problems for NVidia Optimus, so I'm wondering whether I should disable it by default.

(3) "use a separate device for DXVA processing". This is a rather new option, introduced recently. I've got one report that it helped. So I wonder if I should enable it by default. But I guess this might also make problems with NVidia Optimus (because it's similar to (2), see above). Right now I'm wondering whether maybe I should combine options (2) and (3) into one, so that I'm either using only 1 device for everything, or 3 devices, one for rendering, one for presentation and one for DXVA processing. Thoughts?

(4) "enable windowed overlay". When I originally implemented overlay, it wasn't ready for prime time yet, so I disabled this by default. But since its introduction, I have applied lots of fixes, so now it seems to work very well (only for NVidia and Intel, unfortunately). It works so well IMHO that I'm reevaluating whether I should enable this by default (not for AMD, obviously). Any thoughts on this?

Please check which way these options work better for you, and let me know your test results. If you can't see a difference, please let me know that, too.

Thanks!

1)In "trade qualtiy for performance", only "store custom pixel shader results in 16bit buffer insted of 32 bit buffer" is checked on.

Is it usefull to turn off or is better to turn off?

For the max quality other option must be turn off or tunr on?



2)In exclusive mode settings what is the interest of "present several frames in advance" option?

I must turn on or tunr off?

Thanks.

[aufkrawall]

Originally Posted by madshi

(1) "perform deinterlacing in separate thread". This was enabled in earlier madVR builds by default. It's now disabled by default in v0.85.5. With my AMD GPU, there's no difference. My NVidia GPU runs slightly better with this option disabled.

My 670 runs slightly worse with this option disabled.
With disabled I have a less stable GPU usage. It can be lower, but there can be also spikes (~60% instead of ~50%).
That's why I think it should stay enabled by default.

Originally Posted by madshi

(2) "use a separate device for presentation". This was and still is enabled by default. It used to be a good method to reduce glitches with older NVidia drivers. I'm wondering if this option is still beneficial today with both NVidia and AMD GPUs. I've been told this option can make problems for NVidia Optimus, so I'm wondering whether I should disable it by default.

I have no problems when it's disabled. If there are no other drawbacks, imho it can be disabled by default.

Originally Posted by madshi

(3) "use a separate device for DXVA processing". This is a rather new option, introduced recently. I've got one report that it helped. So I wonder if I should enable it by default. But I guess this might also make problems with NVidia Optimus (because it's similar to (2), see above). Right now I'm wondering whether maybe I should combine options (2) and (3) into one, so that I'm either using only 1 device for everything, or 3 devices, one for rendering, one for presentation and one for DXVA processing. Thoughts?

This option doesn't give me any advantage, instead it raises rendering times. I think it should be disabled by default.

Originally Posted by madshi

(4) "enable windowed overlay". When I originally implemented overlay, it wasn't ready for prime time yet, so I disabled this by default. But since its introduction, I have applied lots of fixes, so now it seems to work very well (only for NVidia and Intel, unfortunately). It works so well IMHO that I'm reevaluating whether I should enable this by default (not for AMD, obviously). Any thoughts on this?

I have no problems with this option. Maybe enable it (+ solution for more instances) by default and if it makes trouble disable it again?

[madshi]

Originally Posted by 6233638

I agree, but when it's not dropping frames or showing other issues, I don't really have anything else to go on.

Well, you said:

> it means that more demanding videos are dropping
> frames, so I would have to lower my settings if I
> disabled "use a separate device for presentation".

I suppose this was a guess based on the rendering time numbers reported by madVR. What you could do is to actually test whether you can find a situation where there are actually dropped frames in real life with "use a separate device for presentation" turned off while there are no frame drops with it turned on.

Originally Posted by 6233638

Using DXVA2 Native, this kills performance on my system using the GT610

Did you test all this with v0.85.5? Or did you test with v0.85.4 (or older)? The reason I'm asking is that I did a small change in v0.85.5 which affects the way "use a separate device for DXVA processing" works. So it's important to test this with v0.85.5.

Originally Posted by cca

EDIT: No it wasn't it, I needed to activate deinterlacing in a separate thread for proper results.

Originally Posted by aufkrawall

My 670 runs slightly worse with this option disabled.
With disabled I have a less stable GPU usage. It can be lower, but there can be also spikes (~60% instead of ~50%).
That's why I think it should stay enabled by default.

Ok, it seems that "perform deinterlacing in separate thread" works better for most of you guys. So now I'm actually considering going the opposite way and removing this option and turn it always on.

Originally Posted by cyberbeing

Until you implement a way for madVR Overlay to use the active calibrated GPU CLUT, as well as take screenshots post-resize & processing, I don't think you should even be considering it as a default.

Oh well. I'll put these two issues on my "Overlay problems" list.

Originally Posted by ikarad

Why catmull rom and not lanczos?

With catmull rom, there is more aliasing than lanczos if you see red bars.

I don't understand why catmull rom would be better than lanczos.

Do you have a sample video where Lanczos looks better than Catmull-Rom for downscaling?

Generally I agree with you that Lanczos is better for downscaling than Catmull-Rom. However, the situation is a bit different when using linear light. There Lanczos simply produces too many ringing artifacts, even with AR enabled. When not using linear light, Lanczos is probably better than Catmull-Rom, but also slower. Now the question is whether the benefit of linear light downscaling is higher or the benefit of lower aliasing with Lanczos.

Originally Posted by ikarad

1)In "trade qualtiy for performance", only "store custom pixel shader results in 16bit buffer insted of 32 bit buffer" is checked on.

Is it usefull to turn off or is better to turn off?

For the max quality other option must be turn off or tunr on?

For max quality all options in "trade quality for performance" should be off. However, the difference in quality is rather small for some of those options. So the question is how fast your GPU is. If it's plenty fast, uncheck all those options.

Originally Posted by ikarad

2)In exclusive mode settings what is the interest of "present several frames in advance" option?[/URL]
I must turn on or tunr off?

For most users having it turned on is the better solution. Leave it that way if you have no problems with it.

[mzso]

Hi!
Is there a freeware player that can play dvd-s (preferably from image file) with menu-s and all and also can use madvr? (No luck with mpc-hc and potplayer)

What about the same for blu-rays?

[pie1394]

Originally Posted by madshi

I don't think I can do a faster hardwired Jinc shader for 1.5x. I've also not been able to do a faster 3x Jinc shader. Only 2x seems possible for Jinc, due to the way Jinc resampling works. Maybe it would be possible to create 1.5x hardwired shaders for non-Jinc scaling algorithms, but I'm not sure it's worth the effort...

I am a little bit interested the way how you deal with generic scaling ratio...
Does madVR just pre-calculate all (possible combinations of) coefficients at all pixel positions for the set ratio, and the pixel shader code just feeds them into registers according processed pixel position upon doing inner-product calculation?


With my ION (GF9300) in window mode, it is also noticed one minor situation still exists since 0.85.3 (if I don't remember it wrong...) . If MPC-BE v1.0.3.1 is terminated with Alt-F4 during playback, the red message read like dxva decoding surface failure often pops up. If the playback is paused or has ended, there is no such red text during player window closing.

My HTPC system (GTX260+) is set with full-screen-exclusive playback by default. It may be the reason why I never notice the same text on it even MPC-BE is terminated in the same way.

[iSunrise]

madshi, I really like that you optimized Jinc 3, especially for chroma. Is there anything that can be done to improve performance with Jinc 8 on chroma or luma? I know that this is still rarely used (mainly because of it´s performance), but from 6233638´s testing some pages back, it really looks very good in comparison to the other algorithms. It seems pretty useful for some SD content (where you need higher scaling factors).

I am refering to this post from him.

PS: For some reason, after replacing 0.85.4 with 0.85.5 (I always copy and replace all files in the madVR folder) the option "store custom pixel shader results in 16bit buffer instead of 32bit" was set, even though I am pretty sure I didn´t activate it in 0.85.4. Since I couldn´t reproduce it with replacing 0.85.4 with 0.85.5 again, maybe I accidentally activated it before.

PPS: I wish you a happy new year in advance and thanks a lot for your time and dedication developing this great renderer!

[madshi]

Originally Posted by pie1394

I am a little bit interested the way how you deal with generic scaling ratio...
Does madVR just pre-calculate all (possible combinations of) coefficients at all pixel positions for the set ratio

Yes.

Originally Posted by pie1394

With my ION (GF9300) in window mode, it is also noticed one minor situation still exists since 0.85.3 (if I don't remember it wrong...) . If MPC-BE v1.0.3.1 is terminated with Alt-F4 during playback, the red message read like dxva decoding surface failure often pops up. If the playback is paused or has ended, there is no such red text during player window closing.

Yeah, sometimes saw that myself. I consider it a minor cosmetical issue right now. It will surely be fixed at some point, just not now.

Originally Posted by iSunrise

Is there anything that can be done to improve performance with Jinc 8 on chroma or luma? I know that this is still rarely used (mainly because of it´s performance), but from 6233638´s testing some pages back, it really looks very good in comparison to the other algorithms. It seems pretty useful for some SD content (where you need higher scaling factors).

I haven't even been able to make Jinc4 get faster for chroma upsampling, let alone Jinc8. And honestly, Jinc8 is not a good algorithm to use. It adds too much ringing. It works well on some content, but performs incredibly slow and adds lots of ringing. I consider Jinc3 a much better choice.

[Niyawa]

Originally Posted by madshi

Hmmmm... I'm not sure what the media player has to do with this. It shouldn't really affect overlay playback. Sounds quite weird. Are you sure that madVR is really used by both media players? (You can turn on the debug OSD with Ctrl+J to make sure).

Yes, I'm sure both PotPlayer and MPC-HC were using madVR.

Originally Posted by madshi

What you're describing as "shaking video": Do you mean tearing? Tearing means that one part of the image is one frame ahead of the rest of the image all the time. Or do you mean that frames appear to be shown out of order, so that movement goes back and forth all the time?

It's not tearing, as you said, tearing is when one frame is ahead of other, in this case, is not a "crop" in the image that happens, but rather a distortion in loop, which causes the shaking effect. It has a fixed pattern (shaking in vertical). It's hard for me to reproduce since it can happen with any 8-bit video that has DXVA2 and Overlay enabled and as I said, it's not -always-. I have to open and re-open so that can sometimes happen.

Try with this little sample that I used in LAV thread which seems to be the one where it happens often.

Originally Posted by madshi

In any case, the problem goes away if you disable the Overlay option? Are you using DXVA decoding? Maybe it helps disabling that?

The problem is only there when I'm using DXVA2 with Overlay, and it goes away if I turn DXVA2 or Overlay itself. It seems that repeatedly using the Play/Pause button also can make it go away, and make it come back as well.

Originally Posted by madshi

I do plan to write a full documentation, but not right now. madVR is still not feature complete. Documentation will be done as the last step before releasing v1.0.

Oh okay, makes sense, since there's still a lot to implement and change, thanks.

Originally Posted by ikarad

Why catmull rom and not lanczos?

It's just like madshi said, I did try with Lanczos but the results were not really what I expected. 6233638 also pointed out that Catmull-Rom is the most accurate downscaling algorithm to date.

[ikarad]

Originally Posted by madshi

Do you have a sample video where Lanczos looks better than Catmull-Rom for downscaling?

Generally I agree with you that Lanczos is better for downscaling than Catmull-Rom. However, the situation is a bit different when using linear light. There Lanczos simply produces too many ringing artifacts, even with AR enabled. When not using linear light, Lanczos is probably better than Catmull-Rom, but also slower. Now the question is whether the benefit of linear light downscaling is higher or the benefit of lower aliasing with Lanczos.

I don't have any sample.
I just refer to the red and green bars in madvr for result.
With lanczos red bars are less important than with catmull.
It's why I ask.

Maybe you can correct red bars with lanczos because it can bring mistake understanding.

For max quality all options in "trade quality for performance" should be off. However, the difference in quality is rather small for some of those options. So the question is how fast your GPU is. If it's plenty fast, uncheck all those options.

I have a gtx560.

For most users having it turned on is the better solution. Leave it that way if you have no problems with it.

Thanks.

[ikarad]

Originally Posted by Niyawa

It's just like madshi said, I did try with Lanczos but the results were not really what I expected. 6233638 also pointed out that Catmull-Rom is the most accurate downscaling algorithm to date.

Even if it's not related directly with madvr, I have two questions about your guide for mpc-hc,madvr and reclock

1) on http://www.homecinema-hd.com/reclock.html
guide tell that sampling rate must be at 96khz. In your guide, it's 48khz.


I would like to know why there is any difference between the two advice.

What is the better? 48 or 96khz?

I have sound blaster xfi titanium.


2) in your guide your said about reclock:

Note: If you're going to use madVR, then don't install this. madVR's own Vsync can enter in conflict with ReClock's one resulting in worse pattern of playback. This only aplies to 24p@60Hz but for now it's better to be safe until this is fixed in future versions of madVR.

I use reclock and mavr since many years and I don't see any problem.
What are the problems with reclock combined with madvr?

Have you seen any problem with reclock? Have you an example to see if I have thse same problem with my PC?

[noee]

Some low-end Llano feedback:

SD material (interlaced video and NTSC film) upscaling to 1600x900, using Jinc3/AR for image up, Jinc3 chroma up.

I'm simply watching queues, dropped frame count and playback

(1) I don't see a difference with SD content. However, interlaced video source requires that I drop AR or change to Lanczos4/AR for trouble-free playback.

(2) Same as above.

(3) Does not appear to have any impact that I can see under these scenarios (though obviously NTSC film with DXVA2 decoding is not available)

I can just say, awesome perf improvements. Jinc/AR was not usable on this machine previously for image up with SD material. Seems very solid now. Great work.

[Prinz]

Originally Posted by madshi

Interesting. Which GPU/OS? What happens if you disable/enable the "use a separate device for DXVA processing" and "perform deinterlacing in a separate thread"? Does that fix the problem with exclusive mode?

ATI 2600 XT, Win7 x64

The Options don't make a difference.

[Niyawa]

Originally Posted by ikarad

I would like to know why there is any difference between the two advice.
What is the better? 48 or 96khz?

From what I know more khz generally does give best results, but I've never tested anything above 48, so I can't exactly give you a proper response. I put 48 khz as default because it's the safe bet. If you set anything higher than what you card supports, it may make a mess.

Originally Posted by ikarad

I have sound blaster xfi titanium.

Then I guess it's a good go.

Originally Posted by ikarad

I use reclock and mavr since many years and I don't see any problem.
What are the problems with reclock combined with madvr?
Have you seen any problem with reclock? Have you an example to see if I have thse same problem with my PC?

There's not really "problems". madshi explained that madVR isn't optimal for 24p@60hz, and since this was the very reason it was in the guide, I'm going to remove it. Using it won't make any difference to the video pattern it seems, so you can keep using it like nothing happened too.

[ikarad]

Originally Posted by Niyawa

From what I know more khz generally does give best results, but I've never tested anything above 48, so I can't exactly give you a proper response. I put 48 khz as default because it's the safe bet. If you set anything higher than what you card supports, it may make a mess.

Thanks.

Originally Posted by Niyawa

There's not really "problems". madshi explained that madVR isn't optimal for 24p@60hz, and since this was the very reason it was in the guide, I'm going to remove it. Using it won't make any difference to the video pattern it seems, so you can keep using it like nothing happened too.

I have 120hz lcd.

[Niyawa]

Originally Posted by ikarad

I have 120hz lcd.

You basically don't need ReClock to begin with. 23.976 and 29.970 fits perfectly in a 120hz screen. Unless you watch DVD with 25fps, that ReClock would adapt to 24.

Btw, could you tell me what is your monitor? I'm planning to import a 120 hz soon, so I kinda searching for some reasonably cheap prices. Send me through private messages, let's not spam this thread with non-related stuff.

[ikarad]

Originally Posted by Niyawa

You basically don't need ReClock to begin with. 23.976 and 29.970 fits perfectly in a 120hz screen.

Even with blueray (23.976fps) I see differences with reclock with my 120hz. Some scrollings are more smooth even at 120fps with reclock.

I don't know why but I noticed it.

Btw, could you tell me what is your monitor? I'm planning to import a 120 hz soon, so I kinda searching for some reasonably cheap prices. Send me through private messages, let's not spam this thread with non-related stuff

I have asus VG236H and Benq xl2420T two 120Hz LCd TN unfortunately (I hope that ips 120 hz or oled 120hz will arrive as soon as possible).

[Niyawa]

Originally Posted by ikarad

Even with blueray (23.976fps) I see differences with reclock with my 120hz. Some scrollings are more smooth even at 120fps with reclock.

I don't know why but I noticed it.

Interesting indeed. The difference between 23.976 in a 120hz screen shouldn't been too much, good for you I guess.

Originally Posted by ikarad

I have asus VG236H and Benq xl2420T two 120Hz LCd TN unfortunately (I hope that ips 120 hz or oled 120hz will arrive as soon as possible).

I said PM sir, but okay. Those are expensive as fuck, and that Asus doesn't seem to compensate for the price. At least not in the reviews I saw. Thanks either way, I wonder if I'll ever find a 120 hz monitor between $200~250.

[AndreaMG]

Originally Posted by madshi

madVR v0.85.5 released
Once again I need your FEEDBACK:

(1) "perform deinterlacing in separate thread". This was enabled in earlier madVR builds by default. It's now disabled by default in v0.85.5. With my AMD GPU, there's no difference. My NVidia GPU runs slightly better with this option disabled.

(2) "use a separate device for presentation". This was and still is enabled by default. It used to be a good method to reduce glitches with older NVidia drivers. I'm wondering if this option is still beneficial today with both NVidia and AMD GPUs. I've been told this option can make problems for NVidia Optimus, so I'm wondering whether I should disable it by default.

(4) "enable windowed overlay". When I originally implemented overlay, it wasn't ready for prime time yet, so I disabled this by default. But since its introduction, I have applied lots of fixes, so now it seems to work very well (only for NVidia and Intel, unfortunately). It works so well IMHO that I'm reevaluating whether I should enable this by default (not for AMD, obviously). Any thoughts on this?

Please check which way these options work better for you, and let me know your test results. If you can't see a difference, please let me know that, too.
Thanks!

Testing a 1080i mpeg2 video:

1) Mine too (the difference is however minimal).

2) The GPU load is the same and I have no glitches with it being on or off.

4) I think while disabled GPU load is slightly worse (the difference however it seems to be VERY minimal).