madVR - high quality video renderer (GPU assisted)

[Thunderbolt8]

from a first test with my pc screen (1680x1050 res. @60hz winxp ), I can say that from what it seems its not much different from the old path, but I'd say it might be a little better than before. 24fps stuff seems to be a tiny bit more smoothly. and I havent encountered any problems so far.

[yesgrey]

madVR v0.50 released
Thanks for the new version.

Now waiting for the true reasons behind this change... ;)

I have to say that I'm quite a bit disappointed in Direct3D. Or maybe it's the GPU drivers?
From my little experience with D3D I only can say that when we decided to use one 3D API with our main application our tests showed a big disadvantage of D3D vs OpenGL. The latter was much faster, hence our decision for it.

Recently I've read that now with D3D11 the D3D api finally is becoming better than OpenGL.

I know that at the current phase of madVR evolution a change to OpenGL would not be a very smart move, specially because in the end the change might not proof to be useful. However, maybe a change to D3D11 would be a good idea... the downside is breaking compatibility with XP.

Maybe the problem is that the current drivers are D3D11 ones and use some kind of emulation to still support D3D9, hence the problems showed?...

[alwyn]

Will 1080i25 be supported ??

[Razoola]

I have done a little more testing and apart from what I have already mentioned I can see with the new rendering path Im getting repeated frames compared to the old path. I have a feeling that this is due to the queues running dry. Im still getting the D3D errors duringplay playback but it seems disabling coreavc 2.5.1 allows it to go further before the error pops up.

[Gleb Egorych]

madshi, thanks for 0.50!
60fps videos are finally perfectly smooth on my PC (Win7, 8800GT) in CoreAVC software mode, with previous versions there were dropped frames. Though in CoreAVC CUDA mode number of dropped frames increased comparing to 0.49 I prefer software mode beacuse it is faster on modern CPUs.

[madshi]

I didn't get any drops on 1080p24, but backbuffer and present are running dangerously low.
FWIW, if I would print out a "present queue" statistics for the old rendering path, it would always be "0-1/1" or "1-1/1".

With 1080p60 sample: with the old path I get about 2 dropped frames per minute, the new path about 15.
1080p60 sample
Hmmmm... Unfortunately my 9400 GPU is too slow for 1080p60. And my development PC has a too slow CPU to decode that sample. Argh... :(

Is the decoder queue always full (enough)? Meaning does it ever go lower than e.g. 4 frames?

Is this somehow related to "Maximum pre-rendered frames", which can be selected (default is "3") in the NVIDIA drivers (under Manage 3D Settings)? If it is, did you try to play with those values a bit (0-8 can be selected)? Just wondering.
I'm not sure. From the description it sounds like it could be exactly the right option to tweak. But I've just tried and setting it to either 1 or 8 makes no difference at all. So I guess that's something different.

I can report that with the new exclusive rendering mode the CrossFire related issues are gone.
Good to hear.

It's still the same. Quite strange it doesn't fix a problem if by "WinSock initialization" you mean WSAStartup().
Yeah. Hmmmm... Ok, will check it out myself, when I find the time.

What about VSFilter in MPC? It should take just a few seconds to fix.
What do you mean? madVR has nothing to do with VSFilter.

1) When right-clicking madVR icon in the tray first time (without preliminary left-clicking) both madVR and taskbar menus appear overlaying each other. (WinXP)
I'm not sure what you mean. I can't reproduce any problems on my XPSP3 PC. Can you make a screenshot?

2) After closing file in MPC (but not MPC itself) madHcNet.dll remains locked by MPC.
That's by design. I plan to change it in a future version, though.

why no more "upload frames in render thread"? I thought this option was useful?
Most people reported that they had a better experience with this option turned off, while with some older madVR version on my 9400 I had a better experience with this option turned on. Now with the latest madVR version it's better for me with this option turned off, too. My impression is that it should be better for everyone now turned off. That's why I removed it.

Watched about half an hour of a BluRay (1080p/24) on my GTS 450, and everything is super smooth, no dropped frames at all.
Good to hear. Did you have dropped frames before?

madshi could i ask which Nvidia drivers you use for developing currently ?
I'm currently using the CUDA 4.0 RC development drivers (version 270.32).

For me the new rendering path is a bit of a disaster. The render queue is extreamly limited (1-2 or 2-3) and I get a black screen and D3D error after about 10 to 20 seconds (always). Going back to the old rendering path gives me a 7-8 render queue and no D3D error.

gtx295, 270.51 drivers win7 x64 SP1.

MadVR log at http://unibios.free.fr/madlog.rar
Hmmmm... Interesting log. You're running 120Hz, it seems? Does the image come back after that D3D error if you wait long enough? Or does it stay frozen/black? Would you mind creating 2-3 more logs for me from the same situation? Thanks!

when are you planning on providing DVD support?
When I've reached that point in my todo list.

Now waiting for the true reasons behind this change... ;)
What you mean? The reason for the new exclusive mode rendering path? The simple reason for that is that the old rendering path was always a compromise. I just didn't have the time to implement the new one until now.

From my little experience with D3D I only can say that when we decided to use one 3D API with our main application our tests showed a big disadvantage of D3D vs OpenGL. The latter was much faster, hence our decision for it.

Recently I've read that now with D3D11 the D3D api finally is becoming better than OpenGL.

I know that at the current phase of madVR evolution a change to OpenGL would not be a very smart move, specially because in the end the change might not proof to be useful. However, maybe a change to D3D11 would be a good idea... the downside is breaking compatibility with XP.

Maybe the problem is that the current drivers are D3D11 ones and use some kind of emulation to still support D3D9, hence the problems showed?...
I doubt that the presentation logic will behave much different in D3D10/11. Maybe OpenGL would behave different, I don't know. But then, from what I remember, at least some GPU manufacturers build OpenGL on top of D3D.

Will 1080i25 be supported ??
What do you mean?

madshi, thanks for 0.50!
60fps videos are finally perfectly smooth on my PC (Win7, 8800GT) in CoreAVC software mode, with previous versions there were dropped frames. Though in CoreAVC CUDA mode number of dropped frames increased comparing to 0.49 I prefer software mode beacuse it is faster on modern CPUs.
Interesting. How many frame drops are there with CUDA in v0.50 compared to v0.49? How does the decoder queue behave? Does it ever go below 4?

[Razoola]

Hmmmm... Interesting log. You're running 120Hz, it seems? Does the image come back after that D3D error if you wait long enough? Or does it stay frozen/black? Would you mind creating 2-3 more logs for me from the same situation? Thanks!

Yes I'm running at 120hz. The image does not come back if I wait a while but in one case after a ctrl+alt+delete and closing MPC-HC the program stayed open and the image did appear momentarity looping through a few frames before it closed.

Here are another 4 logs (not including the first log you already have). New logs 1 and 4 gave the D3D error. 2 and 3 did not, I just stopped playback after a short time in those cases.

http://unibios.free.fr/madlog1-4.rar

In case you did not see my other post it appears not using coreAVC to use CUDA to decode seems to stop the D3D error. I left it on for the logs above.

[bjd]

@Madshi

Definite performance hike on my system below with Nvidia Beta 270.51.

[cvrkuth]

No more HAM - ATI stream in FSE (the new exclusive mode rendering path). CPU load is equal for HAM and SW modes now.
In the window mode CPU load is /3

[SamuriHL]

No more HAM - ATI stream in FSE (the new exclusive mode rendering path). CPU load is equal for HAM and SW modes now.
In the window mode CPU load is /3

Ya know I didn't even think to check software mode with the Cyberlink Decoder vs HAM. That's pretty sweet! I'll check it out myself. Thanks!

[yesgrey]

What you mean? The reason for the new exclusive mode rendering path?
Sorry, I've missed the words "exclusive mode". :o

[madshi]

Here are another 4 logs (not including the first log you already have). New logs 1 and 4 gave the D3D error. 2 and 3 did not, I just stopped playback after a short time in those cases.
Thanks!

In case you did not see my other post it appears not using coreAVC to use CUDA to decode seems to stop the D3D error. I left it on for the logs above.
Did it stop the error completely? Or just delayed it? From your other post it seemed to me that the error was only delayed? How about frame drops without CUDA? Still worse than the old rendering path?

[Andy o]

Feedback on 9200M GS and 1080p60 sample:
While the decoder queue was very stable in the old path and drops very low in new path, the overall number of dropped frames has decreased significantly using the new path: from about 250 to about 100.

Same observation as on my desktop:
present queue looks dangerously low, often at 0-4/4 even for 1080p24. But no dropped frames on 1080p24 (same as old path).

??? You CAN use a 9200m GS with madVR? I have to use Overlay mixer on mine, not even EVR-CP works smoothly at 1080p!

[sneaker_ger]

FWIW, if I would print out a "present queue" statistics for the old rendering path, it would always be "0-1/1" or "1-1/1".

I figured as much, "dangerously" was probably not the correct choice.

Hmmmm... Unfortunately my 9400 GPU is too slow for 1080p60. And my development PC has a too slow CPU to decode that sample. Argh... :(

If only someone would write a renderer with DXVA support. :devil:
Here's that sample re-encoded to use less CPU:
http://rapidshare.com/files/456971676/wipeout_fastdecode.mkv

Is the decoder queue always full (enough)? Meaning does it ever go lower than e.g. 4 frames?

It never fell below 4 frames.
I redid the tests (both new and old path) over and over again now, with different clocks (forced to 200/300, forced to 725/1000 and "free"), AA on and off (was left on accidentally from my last tests) and with and without GPU-Z noting clocks in the background. The results were not consistent. I had some runs in which the new path also didn't drop any frames. The influence of the clocks is marginally at best, but the most runs without drops were with the old path and full clocks (and no AA and closed GPU-Z, as is probably advised to minimize any harms). It seems like the difference between the paths was not as big as I originally thought and the neck of the bottle is almost wide enough.
I think I will try out going back to Catalyst 10.6 next, as this seemed to improve window mode performance significantly.

[Razoola]

Thanks!

Did it stop the error completely? Or just delayed it? From your other post it seemed to me that the error was only delayed? How about frame drops without CUDA? Still worse than the old rendering path?

Yes without CUDA its still worse than the old rendering path. I don't think the problem is dropped frames though, it appears to be repeating frames.

I think the D3D error is only delayed but I will need to do more testing before I can be sure if the error is delayed or stopped all together.

I have had a little play with refresh rates and it seems if I drop the refresh rate at 60 hz (the lowest this monitor will go) the queues fill up better (still not full though). Would I be right in assuming the problem I have with low queues is due to the shorter time between vblank and your new render path does not account for this yet? I have noticed that at the lower refresh rate I seem to no longer get the repeating frames so I feel that issue is related to the queues maybe.

[SamuriHL]

No more HAM - ATI stream in FSE (the new exclusive mode rendering path). CPU load is equal for HAM and SW modes now.
In the window mode CPU load is /3

I just did some tests on my main HTPC. HAM is still *SIGNIFICANTLY* lower CPU usage. MPC-HC hits 25% without it. It hits 8% or less with it. :)

[sneaker_ger]

??? You CAN use a 9200m GS with madVR? I have to use Overlay mixer on mine, not even EVR-CP works smoothly at 1080p!

Bilinear resizing. (Didn't test scaling performance with 0.50 yet, madshi claims it has improved on his 9400 card)
EVR-CP and others might be conflicting with the various nvidia drivers - they had a lot of problems. You might want to try uncustomized EVR.

[sybia123]

Just wanted to say that 0.50 completely fixed 60fps playback for me. Decoder, upload and render queue stay at 7-8/8 without dropping down at all. Nice work!

Also, I switch between CoreAVC and ffdshow and CoreAVC works perfectly for me in both software and CUDA mode. No dropped/delayed/repeat frames in either mode.

[Mr Alpha]

I have to say that I'm quite a bit disappointed in Direct3D. Or maybe it's the GPU drivers? Can't say for sure. According to the Direct3D documentation I *should* have been able to render and present 30 video frames in advance, without having to wait for the VSync interrupt - ever. Unfortunately in real life I can only present 3 video frames in advance. Trying to present the 4th frame blocks. With both NVidia and ATI. Sometimes presentation even blocks before the 4th frame. Sometimes presentation blocks for even more than 1 whole vsync duration (e.g. > 40ms for 25fps). Getting this all to work at all was very painful. And I'm still not sure it's all working as expected.Thinking about this, I'm pretty sure the GPU drives have a setting that enforces the max number or frames you can render ahead, and the default is 3 in order to minimize input lag.

EDIT: Some googling led me to an old discussing on Nvidia quad-SLI and DirectX 9. Apparently you need DX10 or higher to be able to render more than three frames ahead.

[cvrkuth]

I just did some tests on my main HTPC. HAM is still *SIGNIFICANTLY* lower CPU usage. MPC-HC hits 25% without it. It hits 8% or less with it. :)

In Full Screen exclusive mode too?

[Qaq]

Thanks for new release.
My setup is Win7 x86, ATI 5450 (512Mb, DDR3).
Just tried 0.50 with 720p/24 video. Display is 1080p/24. Found that CPU usage is huge (~60%), playback is not smooth, OSD shows 1 dropped frames per hour or so. Scalers do not any help.
Went back to 0.49. Everything is fine here: CPU load is ~12%, playback is smooth.
Sorry, didn't pay attention to any "decoder queue" and other stuff (there was no need for that untill now). If some log is needed, I'll try to learn how to make it.

[Andy o]

madshi, I'm getting a cpu spike with the new exclusive mode. 1 or 2 cores (out of 4 in Intel Q9450) visibly spike when going full-screen. It doesn't happen either in windowed mode or with the old mode. Is it supposed to work like this?

[Andy o]

Bilinear resizing. (Didn't test scaling performance with 0.50 yet, madshi claims it has improved on his 9400 card)
EVR-CP and others might be conflicting with the various nvidia drivers - they had a lot of problems. You might want to try uncustomized EVR.

Thanks, I can get away with fancier scaling than bilinear with ffdshow and overlay mixer though, so I'm getting OK quality. It's my laptop anyway, don't use it for HTPC.

[Plutotype]

Hi madshi,

What has exactly changed in the old a new rendering path from 0.49 to 0.50, that:

- CPU usage on my i7 980x 6-Core went down from 10-12% ( 0.49) to 5-7% (0.50 )?
- GPU load on ati5670 went down from 35%(0.49) to 27% (0.50)?

Tested on MPC-HC 3016, first 2minutes of Batman Begins BD ( untouched m2ts stream VC-1+trueHD ), LAVsplitter/LAVaudio 0.22, ffdshow 3815. I use Softcubic 80 for chroma, Spline 4taps for Luma up/down.

Hope there is no quality loss, because this is a very big step regarding efficiency. Amazing.

Thanks for explanation.
Pluto

NOT VALID ANYMORE - ITS ALL THE OTHER WAY

[madshi]

Here's that sample re-encoded to use less CPU
Thanks! With old rendering path I get 1 frame drop with my XPSP3 + Radeon 6850 development PC. With new rendering path 0 frame drops.

I redid the tests (both new and old path) over and over again now, with different clocks (forced to 200/300, forced to 725/1000 and "free"), AA on and off (was left on accidentally from my last tests) and with and without GPU-Z noting clocks in the background. The results were not consistent. I had some runs in which the new path also didn't drop any frames. The influence of the clocks is marginally at best, but the most runs without drops were with the old path and full clocks (and no AA and closed GPU-Z, as is probably advised to minimize any harms). It seems like the difference between the paths was not as big as I originally thought and the neck of the bottle is almost wide enough.
I think I will try out going back to Catalyst 10.6 next, as this seemed to improve window mode performance significantly.
Ok, let me know what you find.

I don't think the problem is dropped frames though, it appears to be repeating frames.
What makes you say that?

I think the D3D error is only delayed but I will need to do more testing before I can be sure if the error is delayed or stopped all together.
Let me know when you're sure. Thanks.

I have had a little play with refresh rates and it seems if I drop the refresh rate at 60 hz (the lowest this monitor will go) the queues fill up better (still not full though). Would I be right in assuming the problem I have with low queues is due to the shorter time between vblank and your new render path does not account for this yet? I have noticed that at the lower refresh rate I seem to no longer get the repeating frames so I feel that issue is related to the queues maybe.
FWIW, the new rendering path is trying to "present" a new frame for every VSync. So in your case it has to present 120 frames per second. madVR is not really rendering 120 frames per second on your PC, though. Instead it's just copying the rendered frames so it can present at 120Hz. Obviously doing so puts a slightly higher strain on madVR and that might make things worse. I didn't think of this as a problem beforehand because I thought I could pre-render more than just 3 frames. With only max 3 frames pre-rendered, the new rendering path might not be optimal for high refresh rates. But well, maybe I can tweak it a bit to at least match the old rendering path. FWIW, the old rendering path didn't present at refresh rate, but instead at movie frame rate. However, the old path could only ever present one frame at a time. So the old path was quite timing sensitive because the presentation had to be done at exactly the right time. The new path has it a bit easier in this regard because it simply renders one frame after the next and relies on the VSync to sort things out.

Just wanted to say that 0.50 completely fixed 60fps playback for me. Decoder, upload and render queue stay at 7-8/8 without dropping down at all. Nice work!
Good to hear! Which GPU? Which OS?

Thinking about this, I'm pretty sure the GPU drives have a setting that enforces the max number or frames you can render ahead, and the default is 3 in order to minimize input lag.
This was suggested just a couple of posts before. I've tried tweaking this option in the NVidia control panel but it made zero difference to me.

[Mr Alpha]

This was suggested just a couple of posts before. I've tried tweaking this option in the NVidia control panel but it made zero difference to me.Some googling suggest that: Max Frames to Render Ahead / Flip Queue Size controls the number of frames the CPU prepares in advanced of being rendered by the GPU. It may not be what you are looking for.

And old Anandtech article (http://www.anandtech.com/show/2403/2), which I just barely remembered, says this:2) The best performing games with Quad SLI used AFR (Alternate Frame Rendering) to divide up the rendering workload, where each GPU was responsible for rendering its own frame. The result is that GPU 1 would render frame 1, while GPU 2 would work on the next frame, GPU 3 would work on the third and GPU 4 would work on the fourth. DirectX 9 unfortunately only allowed for a 3-frame render ahead, meaning that this AFR mode wouldn't work. With the vast majority of games being DX titles, this posed a significant problem to Quad SLI performance.Suggesting that the 3 frame limit is due to Dx9.

[madshi]

My setup is Win7 x86, ATI 5450 (512Mb, DDR3).
Just tried 0.50 with 720p/24 video. Display is 1080p/24. Found that CPU usage is huge (~60%), playback is not smooth, OSD shows 1 dropped frames per hour or so. Scalers do not any help.
Went back to 0.49. Everything is fine here: CPU load is ~12%, playback is smooth.
That sounds bad... :( I wonder why experiences differ so much? For some people it's a noticeable improvement, for others it's worse.

I'll see if I can reproduce the higher CPU usage.

I'm getting a cpu spike with the new exclusive mode. 1 or 2 cores (out of 4 in Intel Q9450) visibly spike when going full-screen. It doesn't happen either in windowed mode or with the old mode. Is it supposed to work like this?
Do they spike just for a moment? Or do they stay higher throughout exclusive mode rendering?

What has exactly changed in the old a new rendering path from 0.49 to 0.50, that:

- CPU usage on my i7 980x 6-Core went down from 10-12% ( 0.49) to 5-7% (0.50 )?
- GPU load on ati5670 went down from 35%(0.49) to 27% (0.50)?

Tested on MPC-HC 3016, first 2minutes of Batman Begins BD ( untouched m2ts stream VC-1+trueHD ), LAVsplitter/LAVaudio 0.22, ffdshow 3815. I use Softcubic 80 for chroma, Spline 4taps for Luma up/down.

Hope there is no quality loss, because this is a very big step regarding efficiency. Amazing.
How weird can things be? You're reporting lower CPU. Two other guys are reporting much higher CPU. I'm confused.

The new rendering path is simply a lot different to the old path. But as I said, the new path is kinda experimental. So some problems are to be expected. Hopefully I can clear them all up.

@Plutotype, there should be no quality loss.

[madshi]

And old Anandtech article (http://www.anandtech.com/show/2403/2), which I just barely remembered, says this:Suggesting that the 3 frame limit is due to Dx9.
D3D9 is limited to max 3 backbuffers. However, Vista and Windows 7 introduced a slightly extended D3D9 version ("D3D9Ex") which supports up to 30 backbuffers. The new exclusive mode rendering path uses D3D9Ex and I can successfully create those 30 backbuffers. But I can only render 3 frames without being blocked until the next VSync.

[SamuriHL]

In Full Screen exclusive mode too?

I'm not sure how to test that one. Simply because if I'm in full screen I can't check the cpu utilization with the tools I have. I wondered the same thing though. Any ideas on how I can test that theory?

[Andy o]

I took a screenshot. It stays high the whole time. Here you can see it. Where it goes down, I changed to the old exclusive mode, restarted MPC-HC and played the same part of the video. Using a 5770 with Cat 11.4 preview on Win 7-64 if that matters. I switched the task manager refresh rate to slow to show it more uniformly, so that's actually more than a couple of minutes' worth of video for each new/old renderings.

http://photos.smugmug.com/photos/1248453864_YkuAv-O.png

[cvrkuth]

I'm not sure how to test that one. Simply because if I'm in full screen I can't check the cpu utilization with the tools I have. I wondered the same thing though. Any ideas on how I can test that theory?
Have Task manager on my first display while Potplayer runing on the socond display.

[scoz]

D3D9 is limited to max 3 backbuffers. However, Vista and Windows 7 introduced a slightly extended D3D9 version ("D3D9Ex") which supports up to 30 backbuffers. The new exclusive mode rendering path uses D3D9Ex and I can successfully create those 30 backbuffers. But I can only render 3 frames without being blocked until the next VSync.

Would doing a test implementation in DX10 be too much work? And even if it was successful in presenting to a ton of backbuffers would it be possible to do a DX9 and 10 renderer on the same code base without getting too unwieldy? I know theres a bunch of people still using XP so you can't drop 9.

[sneaker_ger]

Thanks, I can get away with fancier scaling than bilinear with ffdshow and overlay mixer though, so I'm getting OK quality. It's my laptop anyway, don't use it for HTPC.

Just did a short test and it seems that performance isn't actually that bad. In fact I'm watching 1280x640 -> 1366x768 (Laptop display) with the standard settings right now. (SoftBicubic + 2x Lanczos)
1920x800 with 3 times SoftBicubic also works. Can't test performance for 1080p display right now, but this should give you the idea that not all is lost.

[Plutotype]

Sorry folks / madshi, I have to recall my previous post. Its all the other way:(: Same experience here as Andy:
0.50 WITH OLD RENDERING PATH (http://img808.imageshack.us/f/050oldrenderingpath.png/)
0.50 WITH NEW RENDERING PATH (http://img845.imageshack.us/f/050newrenderingpath.png/)

Win7, ATI5670 11.2 Catalyst.
Tested on MPC-HC 3016, first 2minutes of Batman Begins BD ( untouched m2ts stream VC-1+trueHD ), LAVsplitter/LAVaudio 0.22, ffdshow 3815. I use Softcubic 80 for chroma, Spline 4taps for Luma up/down.

Do you also see the different behaviour in RAM usage? The old path required more RAM, but with less CPU. The new rendering path eats more CPU, but with less RAM.

Pluto

[Andy o]

I didn't see any significant difference in RAM usage in my test above.

[pankov]

madshi,
I suppose I'll be the third person reporting high CPU usage with the new rendering path.
On my i5-750@3.2GHz the CPU usage jumps from ~10% (using Software mode of CoreAVC) with the old rendering path to ~35-40% with the new.
This is for a 720p/24Hz TV show @ 1080p/24Hz display.
If I enable CoreAVC's CUDA Mode (on my new GTX 460 SE with 270.51 drivers) I get <5% CPU usage with the old mode and almost the same ~31-36% with the new.
I've also noticed that the CPU usage stays around 15-20% even if I pause the video while with the old one it goes to idle (0-1.5%).

I'm using 32bit Windows 7 with SP1

[SamuriHL]

My Athlon X2 machine is also showing higher CPU utilization which is bad for that machine. It's pushing 82% in one case which is really high and comes close to breaking the machine. It was lower with the old path, but, I don't know how much lower at the moment.

[sybia123]

Just wanted to say that 0.50 completely fixed 60fps playback for me. Decoder, upload and render queue stay at 7-8/8 without dropping down at all. Nice work!

Also, I switch between CoreAVC and ffdshow and CoreAVC works perfectly for me in both software and CUDA mode. No dropped/delayed/repeat frames in either mode.

Good to hear! Which GPU? Which OS?


Using a GTX 460 1GB with Windows 7 64 bit, now madVR works perfectly for me and I can get around to watching some movies :D

EDIT: Oh yeah, I noticed the higher CPU usage also. My i5 760 @ 3.8 GHz goes up to 30% usage while using the new fullscreen exclusive mode vs. 7-8% using the old mode. FWIW I would rather have higher CPU usage and no dropped frames than the other way around :)

[Qaq]

I also have to confirm big CPU/low RAM usage for new path and low CPU/big RAM usage for old path.

[sneaker_ger]

New tests with 10.6:
at 725/1000: both paths always perfect
at 200/300: old always perfect, new path sometimes perfect, sometimes not

The only thing that's better with the new path for me is that the number of dropped frames right at the start of the clips have decreased vastly.

Btw.: Does anyone have a sample clip to control whether motion is fluid? To easily spot judder from pulldown for example.

/edit:
Totally forgot to mention: With 10.6 all queues are filled, even present is usually at 3-4/4.

[pankov]

here you can find such clips for different framerates
http://www.avforums.com/forums/streamers-network-media-players/1175436-files-judder-test.html

[sneaker_ger]

Thanks.

[sneaker_ger]

Seeking does not work when paused?

[namaiki]

Would it be accurate in saying that neither the current nor previous madVR is affected(for instance, Aero composition is 60Hz, but screen is 72Hz) by Aero composition while in exclusive mode? In short, Aero doesn't affect madVR's exclusive mode?

Just making sure, but if it helps I've had a cold and headaches the past few days. :C

[SamuriHL]

That is ENTIRELY dependent on your hardware. It affects some people's machines while others don't make any difference at all.

[Hypernova]

Report back on the old issue: I think the disappeared lines is gone now (since your fixed, not 0.50).

[Rain1]

Hi, I've just downloaded and test sneaker_ger's 1080p/60 clip (http://forum.doom9.org/showthread.php?p=1491639#post1491639). Here's my results between old & new rendering path (playback 5 times each way):

Old path:
* Dropped frames: 30 37 34 40 41
* GPU & CPU numbers:
http://i6.photobucket.com/albums/y244/rain1/test_oldpath.jpg

New path:
* Dropped frames: 4 2 2 4 4 :)
* GPU & CPU numbers:
http://i6.photobucket.com/albums/y244/rain1/test_newpath.jpg

Notes:
* Bottom 3 graphs for CPU, top 2 graphs for GPU
* Load measured on Core 0, Usage on overall CPU,
* Decoder: ffmpeg-mt

Looks like your new rendering path improve playback quality at the cost of CPU power.

[G_M_C]

Madshi: I have never got madVR to work on my win-64 setup. I download and use the .bat included in the zip. but de madVR renderer never shows up in MPC-HT (32-bit version). What am i missing ? (i'm sure its probably something stupid, but i want to ask this question anyway :p )

[madshi]

Would doing a test implementation in DX10 be too much work? And even if it was successful in presenting to a ton of backbuffers would it be possible to do a DX9 and 10 renderer on the same code base without getting too unwieldy? I know theres a bunch of people still using XP so you can't drop 9.
Creating a full DX10 rendering path for madVR would be quite a lot of work, I think, because I think the shaders would all have to be rewritten. Not 100% sure, though. Never looked into DX10 yet. What I should be able to do is a quick test, though, if I can present more than 3 frames without blocking. Another problem with DX10 is, though, that DXVA is strictly DX9. So if I should ever implement DXVA support, having madVR be DX10 would be a bit problematic. It's somewhat possible to share surfaces between DX9 and DX10, so it wouldn't be impossible to do, but it'd mean added complication which I'd like to avoid if it's not really necessary.

Sorry folks / madshi, I have to recall my previous post. Its all the other way:(: Same experience here as Andy
That's ok. At least you're all on one page now. That's actually easier for me to understand/handle.

I suppose I'll be the third person reporting high CPU usage with the new rendering path.
My Athlon X2 machine is also showing higher CPU utilization
I noticed the higher CPU usage also.
I also have to confirm big CPU/low RAM usage for new path and low CPU/big RAM usage for old path.
I think you have me convinced now... :D

Using a GTX 460 1GB with Windows 7 64 bit, now madVR works perfectly for me and I can get around to watching some movies :D
Good to hear!

New tests with 10.6:
at 725/1000: both paths always perfect
at 200/300: old always perfect, new path sometimes perfect, sometimes not

The only thing that's better with the new path for me is that the number of dropped frames right at the start of the clips have decreased vastly.

Totally forgot to mention: With 10.6 all queues are filled, even present is usually at 3-4/4.
Are all queues filled even in that very moment when you get non-perfect playback with the new rendering path? If so, I'd like a log. If the queues do go low at the moment when you get problems, a log is not necessary. Does the OSD note dropped frames when the get non-perfect playback?

Seeking does not work when paused?
Don't know, will check.

Report back on the old issue: I think the disappeared lines is gone now (since your fixed, not 0.50).
Thanks for the heads up!

Hi, I've just downloaded and test sneaker_ger's 1080p/60 clip (http://forum.doom9.org/showthread.php?p=1491639#post1491639). Here's my results between old & new rendering path (playback 5 times each way)
Now this is what I call a professional test... :) Well done, and thanks.

Looks like your new rendering path improve playback quality at the cost of CPU power.
I don't think it will stay this way. It should be possible to get CPU consumption down to the old levels - at least when refresh rate and movie frame rate are identical. If you have a high refresh rate, CPU consumption *may* (not 100% sure) be slightly higher once I'm finished tweaking. Shouldn't be much, though.

Madshi: I have never got madVR to work on my win-64 setup. I download and use the .bat included in the zip. but de madVR renderer never shows up in MPC-HT (32-bit version). What am i missing ? (i'm sure its probably something stupid, but i want to ask this question anyway :p )
Make sure you don't move/delete the madVR folder after installation. Does that fix the problem?

[namaiki]

Anyone experience a certain issue (when using multiple monitors - default madVR settings) where a dialog box randomly gets 'stuck' on one monitor when playing a video in full screen exclusive on the other monitor?