madVR - high quality video renderer (GPU assisted)

[leeperry]

I've got a dllhost.exe that doesn't want to die since I've installed the new beta...maybe it's unrelated

[madshi]

Originally Posted by Thunderbolt8

hm stats from a movie (quite grainy movie)

display 59.XXXHz
movie 23.976 fps
1920, 1080
vsync interval 16.73ms
movie frame interval 41.71ms
avrg gpu rendering time 47.XXms
max gpu rendering time 47.XXms

doesnt run smoothly on that c2q with 7600GT (AGP), so how can I determine this from the numbers? is it like that that the avrg gpu rendering time value has to be lover than the movie fram interval value for fluent playback?

edit: when I enable all those "performance for quality settings" then the avrg gpu rendering time drops to ~30ms and it looks almost fluent (max gpu rendering time sometimes still higher than movie framerate interval; creating 10bit textures fails, uses 8bit instead)

Grainy or not doesn't matter to madVR. You'd get the same stats even with a static test pattern... Only source resolution and framerate matters to madVR.

Well, that is one slow GPU you have there! I take it you have scaling disabled (1:1 display)? If so, could you please zoom a little and post the average GPU rendering time then? Does it go to 100ms per frame then?

If you want to give madVR even a chance to achieve smooth playback you have to achieve an "average gpu rendering time" that is a notch lower than the "movie frame interval". I'd say it should not be higher than 35ms for 23.976 playback. Now the optimal configuration for madVR is if you drive the display with the same refresh rate the source is in (in your case 23.976Hz). If you have to use 59.940Hz, things get slightly more difficult for madVR. In that case you may have to bring "average gpu rendering time" down even more. But madVR is not optimized for this situation yet, so even if you do manage to bring gpu rendering time down, don't expect perfect smoothness with the current madVR version.

I'm not sure yet how much influence "max gpu rendering time" will have. Could be that high spikes in that area may result in frame drops. Or maybe not, if I find a way to smoothen things out...

Originally Posted by rica

tried to open an avs file including a dga created by neuron's DGAVCDecodeNV in MPC-HC. (Sure CUVID server is opened)
Here are the results:

with EVRCustom Presenter CPU utilization is 20 to 35%
with madVR, it is 50 to 75 %.

.03 didn't change the CPU usage.

Hmmmmmm... I still don't know why CPU utilization is higher with madVR than it is with EVR/VMR/Haali. In theory there shouldn't really be much difference... Maybe I will find out one day. But for now I have different priorities, so CPU consumption will have to wait...

Originally Posted by leeperry

so my custom timings are not as spot-on as I initially thought...that's w/ CoreAVC CUDA :

I should be getting an ideal frame interval of 41.67, and it's 41.71...I guess it can't get any better than that just yet

You are misinterpreting the OSD information. The "frame interval" is for the movie source framerate. It's not for the display refresh rate. For the display refresh rate look at the first line in the OSD, that looks quite good. Or look at "vsync interval", which is basically half of 41.67 (due to using 48Hz instead of 24Hz), so you should be happy.

Originally Posted by leeperry

now if you could add an option to force triple buffering

Things are not as easy as that. There's more to smooth playback than just enabling triple buffering. Actually triple buffering can be bad in some situations. Anyway, I don't want to talk about smooth motion playback improvements right now because (as I said multiple times), that feature is simply not implemented yet.

Originally Posted by leeperry

and let us fake the GUID to improve compatibility in third party players

No plans for that right now. Please ask those 3rd party players to support madVR.

Originally Posted by leeperry

maybe making the OSD white would make it more readable too..

The OSD layout is not final yet. Only few things in madVR are final right now...

[STaRGaZeR]

Refresh rate detection is working properly here. However I'm experiencing the typical "colors are washed out" situation. My monitor expects PC levels and it seems that madVR is sending TV levels. All other renderers are fine. To have proper levels with madVR I've to use ffdshow's levels filter. BTW could you provide with a brief description of each resizer? I know a few of them but not the others.

[leeperry]

Originally Posted by leeperry

I've got a dllhost.exe that doesn't want to die since I've installed the new beta...maybe it's unrelated

apparently it comes from the "ComSysApp" COM+ service, did you use that to create the LUT's from yesgrey's app or sumthing? if so, it might need to be closed afterwards.

Originally Posted by madshi

look at "vsync interval", which is basically half of 41.67 (due to using 48Hz instead of 24Hz), so you should be happy.
[...]
I don't want to talk about smooth motion playback improvements right now because (as I said multiple times), that feature is simply not implemented yet.
[...]
No plans for that right now. Please ask those 3rd party players to support madVR.
[...]
The OSD layout is not final yet. Only few things in madVR are final right now...

1)I am happy, no worries
2)got it, just an idea
3)I did, but the main KMP coder is AWOL...and I tried to hexedit the GUID in both your renderer and kmp.exe w/o succeeding
4)yet it looks really good already

the measured refresh rate slightly oscillates from time to time, no wonder Reclock is mandatory for smooth playback..

[yesgrey]

Originally Posted by madshi

Hmmmmmm... I still don't know why CPU utilization is higher with madVR than it is with EVR/VMR/Haali.

Are you sure all your buffers are created in the GPU memory? Maybe it's using some of the RAM of the computer, which should slow things down and increase CPU usage...

[rica]

Hmmmmmm... I still don't know why CPU utilization is higher with madVR than it is with EVR/VMR/Haali. In theory there shouldn't really be much difference... Maybe I will find out one day. But for now I have different priorities, so CPU consumption will have to wait...

OK, thanks, sure we have time for this

But i should remind you when i open an m2ts with any SW based decoder (like arcsoft), CPU consumption is 75 to 100%.
My trials were based on DGAVCDecodeNV as you know.

[STaRGaZeR]

Originally Posted by yesgrey3

Are you sure all your buffers are created in the GPU memory? Maybe it's using some of the RAM of the computer, which should slow things down and increase CPU usage...

I get ~309MB of RAM usage with madVR vs ~105MB with EVRCP.

Any chance of a x64 build?

[KoD]

madshi, I've sent you a PM with a small anamorphic sample displayed by the renderer with wrong AR . Source is DVD.

[ice25]

CPU usage is still very high when i use the secondary display for madVR, but according to the stats it's detecting the refresh rate from the primary screen while i'm using the secondary display. So i guess refresh detection for secondary display is bugged atm, cpu usage should be fixed once you get around fixing that.

[madshi]

Originally Posted by STaRGaZeR

could you provide with a brief description of each resizer? I know a few of them but not the others.

Check out this page:

http://audio.rightmark.org/lukin/gra...house_more.htm

In my source code I've added the following comments. They might help here, too:

aliasing (negative): the lower the better
additional ringing (negative): the lower the better
hide source ringing (positive): the higher the better
sharpness (positive): the higher the better

Bilinear (2 tap)
- aliasing = 5
- additional ringing = 0
- hide source ringing = 3
- sharpness = 5

Catmull-Rom = Bicubic50, Bicubic60, Bicubic75 (2 tap)
- aliasing = 4.5, 3.5, 3
- additional ringing = 1, 2, 3.5
- hide source ringing = 0
- sharpness = 7.25, 7.50, 7.75

Mitchell-Netravali (2 tap)
- aliasing = 4
- additional ringing = 1
- hide source ringing = 1
- sharpness = 5

SoftCubic80, SoftCubic70, SoftCubic60, SoftCubic50 (2 tap)
- aliasing = 0.25, 1, 2, 2.5 
- additional ringing = 0, 0.25, 0.5, 0.75
- hide source ringing = 7, 6, 3, 1
- sharpness = 2, 3, 3.5, 4

Lanczos3 (3 tap), Lanczos4 (4 tap)
- aliasing = 2, 1
- additional ringing = 6, 8
- hide source ringing = 0
- sharpness = 8.5, 9

Spline36 (3 tap), Spline64 (4 tap)
- aliasing = 2.5, 2.3
- additional ringing = 4.5, 5
- hide source ringing = 0
- sharpness = 8, 8.1

Please note that these numbers are just my personal opinion. There's nothing scientific about these numbers.

Originally Posted by leeperry

apparently it comes from the "ComSysApp" COM+ service, did you use that to create the LUT's from yesgrey's app or sumthing?

madVR has nothing to do with COM+.

Originally Posted by leeperry

the measured refresh rate slightly oscillates from time to time, no wonder Reclock is mandatory for smooth playback..

Refresh rate measurements are not an exact science. It is to be expected that the measurement oscillates. That does not mean that the real refresh rate does that, too. It just means that the measurement is not perfect. Not too much of a problem, though. madVR doesn't need perfection in this case, if it's reasonably close (as in < 1% from true value), that's good enough.

Originally Posted by yesgrey3

Are you sure all your buffers are created in the GPU memory? Maybe it's using some of the RAM of the computer, which should slow things down and increase CPU usage...

In theory all buffers used for the rendering should be on the GPU, I've intentionally done it that way.

Originally Posted by STaRGaZeR

I get ~309MB of RAM usage with madVR vs ~105MB with EVRCP.

madVR stores 16 decoded frames in RAM.

Originally Posted by STaRGaZeR

Any chance of a x64 build?

Not for now, maybe later, when 32bit is more or less complete...

Originally Posted by ice25

CPU usage is still very high when i use the secondary display for madVR, but according to the stats it's detecting the refresh rate from the primary screen while i'm using the secondary display. So i guess refresh detection for secondary display is bugged atm, cpu usage should be fixed once you get around fixing that.

Too bad, I had hoped that was fixed. Can't properly test it cause I don't have a secondary display at the moment. So I guess the fix will have to wait a while...

[noee]

XPSP3, HD2600XT, CCC9.4, AMD X2 3.0Ghz, Reclock, MPC-HC (int decoders)
Monitors: (Prim) Samsung 60Hz (PC levels) - (Sec) LG 37 24/60Hz (Video Levels)
Source material: SD = 23.976@24Hz AVC in MKV, HD = 29.970@60Hz AVCHD in M2TS (1080P)

1. Still getting tearing on secondary, SD and HD
2. madVR displaying 60Hz on my secondary (LG) when the monitor is set for 24Hz

Not getting the automatic creation of the LUT's. I ended up creating them myself with modified config files.
I have retained the folder structure from the zip with "cr3dlut" folder in a "madVR" folder.

[madshi]

Originally Posted by noee

1. Still getting tearing on secondary, SD and HD
2. madVR displaying 60Hz on my secondary (LG) when the monitor is set for 24Hz

Yeah, seems that madVR still thinks it's running on primary.

Originally Posted by noee

Not getting the automatic creation of the LUT's.

What did you get instead? Any error messages? Or a crash? Or what?

[yesgrey]

Originally Posted by madshi

In theory all buffers used for the rendering should be on the GPU, I've intentionally done it that way.

Originally Posted by madshi

madVR stores 16 decoded frames in RAM.

So the frames are stored in RAM instead of GPU memory?
If they are, when you process them with the GPU are you accessing them via the AGP/PCI-E or via the CPU? Could this be the source of the high CPU usage?...

[madshi]

madVR v0.3 released *again*

http://madshi.net/madVR.zip

* updated cr3dlut templates

Sorry guys, please redownload. madVR itself is unchanged, but yesgrey3 has been so kind to provide me with some preconfigured cr3dlut templates. Mine has been wrong, it seems.

Please delete "out16.3dlut" (in case you still have it) and "SD/HD.3dlut". Then rerun madVR. Hopefully that will clear any and all complaints about washed out colors.

BTW, there are also templates for video levels now. If you need video levels, replace the files "SD/HD.txt" with "template - SD/HD - Video.txt", then delete "SD/HD.3dlut" and rerun madVR.

[Xorp]

30mbps avg Blu-ray remuxed to mkv with eac3to, weird resolution reported (its 1920x1080)



framerate stays around 18fps according to zoomplayer's stats
graphics card is 8800GTS-640MB

[madshi]

Originally Posted by yesgrey3

So the frames are stored in RAM instead of GPU memory?

No. I'm uploading every frame to GPU memory before processing it, of course.

[madshi]

Originally Posted by Xorp

30mbps avg Blu-ray remuxed to mkv with eac3to, weird resolution reported (its 1920x1080)

Strange! How does the pin connection info look like?

Not sure why you only get 18fps. Might be due to madVR consuming too much CPU so that your decoder chokes (the frame queue is only at 3/16, usually it should be 16/16, having it at so low value means that the decoder is not delivering frames fast enough). But your gpu rendering times are also quite heavy.

Do you happen to have another filter running (e.g. ffdshow) which upscales the video to double resolution? That would explain the strange movie resolution report and also the high gpu rendering times.

[noee]

Sorry, yeah, the msg I get is:

madVR Reports:
opening 3dlut file fails

[madshi]

Originally Posted by noee

madVR Reports:
opening 3dlut file fails

Do you happen to use a non-ansi char path? That's the only cause I can imagine right now. Lazy as I am I used ansi chars instead of unicode... Or is your overall madVR directory path extremely long (> 260 chars)?

[Thunderbolt8]

Originally Posted by madshi

Grainy or not doesn't matter to madVR. You'd get the same stats even with a static test pattern... Only source resolution and framerate matters to madVR.

Well, that is one slow GPU you have there! I take it you have scaling disabled (1:1 display)? If so, could you please zoom a little and post the average GPU rendering time then? Does it go to 100ms per frame then?

just wanted to indicate grainy = high bitrate file here

yes, the card is quite old. I have the same one (as PCIE though) in my own C2D system, might be a tiny bit faster, but not much I guess.

the display I used here has 1680*1050 res, so its not 1:1 (the other screen on my own system has 1280*1024). so you still want me to try zoom? but how can I do that, have no clue about zooming options :S

Originally Posted by madshi

If you want to give madVR even a chance to achieve smooth playback you have to achieve an "average gpu rendering time" that is a notch lower than the "movie frame interval". I'd say it should not be higher than 35ms for 23.976 playback. Now the optimal configuration for madVR is if you drive the display with the same refresh rate the source is in (in your case 23.976Hz). If you have to use 59.940Hz, things get slightly more difficult for madVR. In that case you may have to bring "average gpu rendering time" down even more. But madVR is not optimized for this situation yet, so even if you do manage to bring gpu rendering time down, don't expect perfect smoothness with the current madVR version.

hm so your advise would be to change it to 24 (or exactly 23.976?)Hz? how can I do that, in my graphic card options when I rightclick on windows screen and then properties (only have the option to choose either 59 or 60Hz there)? or do I need to change that in ffdshow?