madVR - high quality video renderer (GPU assisted)

[leeperry]

the Monster DVI cable is what really makes the difference
I usually plug it and unplug it everyday, I needed a sturdy cable...they're so cheap on ebay, why bother w/ noname stuff huh...but this was a very smart comment, one well deserved internet for you :D

[madshi]

I think I read that in a game like Crysis every single pixel would get through at least 100 PS scripts...a far cry(pun intended) from mVR?
madVR currently doesn't do much shader math, instead there's loads of texture accesses. Future algorithms will use more math.

my 8800GS can provide 25.2 GTexel/s, apparently the more TMU the higher the texture fillrate:
HD4850 has 20.8 GTexel/s [..] the 8800GTS G92 has 41.6 GTexel/s
Yeah, but with unfiltered texture reads the 4850 doubles its texture read performance, while the 8800G(T)S does not. Also the 4850 has 1000 GLOPS, while your 8800GS only has 396 GFLOPS. Seems to me the 4850 should be roughly twice has fast as your GPU, when using madVR.

Your GPU may be plenty fast enough for madVR today. But that may change tomorrow (or not).

[droc]

subtitles not supported. When will be release madvr with subtitles, and what is the exclusive full screen (may be i don`t understand, my mpc-hc open all files with fullscreen madvr)

[leeperry]

Your GPU may be plenty fast enough for madVR today. But that may change tomorrow (or not).
We still have no idea of what's in the works(or not) http://forum-images.hardware.fr/images/perso/piksou.gif

frame interpolation à la "trimension DNM"? highly complicated sharpening algorithm? degraining for those who like clay movies? I'm out of imagination on what could possibly require so much GPU power in order to play movies :o

[namaiki]

subtitles not supported.

Subtitles are kind of supported. Use DirectVobSub, or FFDShow video subtitle renderers.

[cyberlolo]

cyberbeing said: "As for GPU usage reporting, GPU-Z seems broken in detecting GPU usage with Cat 10.6. I fired up Everest Ultimate and it was still able to detect GPU usage just fine."

You're right! I used Everest and now I get GPU usage (between 5%-25%) when using madVR. So problem was GPU-Z.

Thanks!!

[Grmpf]

We still have no idea of what's in the works(or not) http://forum-images.hardware.fr/images/perso/piksou.gif

frame interpolation à la "trimension DNM"? highly complicated sharpening algorithm? degraining for those who like clay movies? I'm out of imagination on what could possibly require so much GPU power in order to play movies :o

4k resolution isn't that far away ... welcome to constant scaling from 1080p to 4k, luma + chroma in this case, atm most are doing chroma upscaling only (1080p content on a 1080p display), or are scaling SD/720p content - 4k will be a new league for madVR.

[DigitalLF]

i got a spanking new 5750 today... thank you guys for the help... :P

[dansrfe]

The 3DLUT feature is mainly for people who have their own meter, so they can do a "perfect" display calibration (gamma and gamut correction).


So if I have a hardware monitor calibration system then this will help me calibrate my colors and gamma correctly? Also I can't get MPC-HC's internal Subtitle renderer to work with madVR though I would prefer it to.

[JarrettH]

I'm on a GT 240 now. Would be curious to know people's settings for all the buffers :thanks:

[pankov]

Originally Posted by pankov
After I posted the problem I remembered that someone here in the forum said that those <1ms times are fake reports from Aero which made me think what if I stop using "aero" timing mode and go back to "normal". I'm happy to report that this fixed it ... or at least I'm not able to reproduce those high present time values. Now I get ~6ms present times which lead to a perfectly smooth 40 minutes of playback.
So the question now is: what does "aero" mode do different from "normal" mode and that's not working every time?


Hmmmmm... "aero" timing mode always presents at scanline 1, while the "normal" timing mode presents at a later scanline (varying, depending on the queue fullness). Maybe scanline 1 is too early? Maybe it should make it screenHeight / 10 or something like that...

madshi,
this night I did some more testing on these strange timings and now I'm pretty lost but I'll try to explain in details what I did and what were my results and I hope you'll find some useful info in it.
First I tried to use Reclock (VSync correction off) but then I had ~20ms times in 19 out of 20 attempts. When I got the ~0.1ms present times I jumped ahead in the file and the times went to ~20ms ... for about an minute or so it was slowly raising. I guess Reclock is somehow delaying madVR's detection of the VSync even though I've turned off the correction in ReClock's settings.

Then I tried using a Direct Sound Device and with it each time I start a file just after I've started the player I get ~20ms times. If I start the file over or start another file it's back to ~0.1ms. And this was the case in all 30+ attempts except one. In it the playback started with ~6ms present time but just after I jumped ahead in the file (55 seconds) it went back to ~0.1ms but again slowly.

The other "strange" thing I noticed ... once or twice ... on the first playback after the player was started was that if I was quick enough to show the OSD right after I play the file it starts with small times and just when it shows the composition rate (inserts the line in the OSD) the times jump to ~20ms.
Does this ring any bells?

And one more thing - can you add an option (no interface just in the INI file) to start playback with the OSD on? It will be very convenient for such testing purposes.

[Mark_A_W]

mashi, some more results. There were no dropped frames. Stats reset after playback settles, reclock used (no v-sync), V0.18 style settings. A new video timing for a new CRT projector (coming in a touch over ideal at 95.906hz..I can't get 95.904..but it shouldn't matter).

No MMCSS

Test 1: 15 mins = 10 delayed

Test 2: 15 mins = 34 delayed



No present stats

Test 1: 68 mins = 7 delayed

Test 2: 15 mins = 22 delayed, then 35 mins = 24 delayed

v0.18

Test 1: 10 mins = 18 delayed, then 20 mins = 30 delayed

Test 2: 15 mins = 19 delayed


On other occasions v0.18 has been rock solid (before I messed with my video timings, but they are very close).

I watched "Pandorum" (loved it) last night at standard v0.21, at default settings was not good with a handful of dropped frames and over 800 delayed frames.


The best I can say is the results are inconsistent....I'm sorry.

[noee]

madshi, I have not been able to test lately, but now I've tried some SD and HD sources and here are the results. I decided to simply watch and not use the stats at all, fwiw:

SD sources (spline64/spline64/softcubic80) 23.976fps @ 24Hz

(1) Which backbuffer count works best for you? Which is maybe not best, but still acceptable? Which doesn't work at all for you?
- I cannot see a difference with any setting above 3. I did not test below 3.

(2) Which timing mode works best for you? Which is maybe not best, but still acceptable? Which doesn't work at all for you?
- Normal seems to work best. Aero mode gives me tearing.

(3) How about "upload frames in render thread" and "copy 1 backbuffer at a time"?
- I see no difference with this on or off.

HD sources (spline64/spline64/softcubic80) 29.970fps @ 60Hz

(1) Which backbuffer count works best for you? Which is maybe not best, but still acceptable? Which doesn't work at all for you?
- I cannot see a difference with any setting above 3. I did not test below 3.

(2) Which timing mode works best for you? Which is maybe not best, but still acceptable? Which doesn't work at all for you?
- I see no diff between Aero mode and Normal mode.

(3) How about "upload frames in render thread" and "copy 1 backbuffer at a time"?
- I see no difference with this on or off.

HD2600XT(512MB), CCC10.3, Win7 x64, Aero OFF, dual-mon (primary 60Hz, sec 24Hz and 60Hz, both 1920x1080)
HMS/FFDshow/Reclock/madVR/MPC-HC
3Dlut OFF
flush|flush and wait(sleep)|don't|don't


Additionally, all playback is on the secondary, I have reclock vsynch OFF and I am using reclock to resample/re-encode to AC3, even 2-channel audio. I also went back to .18 and reviewed some motion scenes and I see no diff in smoothness to .21 (both very smooth).

[leeperry]

4k resolution isn't that far away ... welcome to constant scaling from 1080p to 4k, luma + chroma in this case, atm most are doing chroma upscaling only (1080p content on a 1080p display), or are scaling SD/720p content - 4k will be a new league for madVR.
Hehe, I haven't even caught up w/ 1080p as most BD's don't even justify >720p if you downscale then rescale....and we don't even have xvyCC/Deep Color movies yet(16-235 SMPTE-C über alles :D)

If the hypothetical "mad" speed requirement is due to 4K scaling(which I personally doubt), then my 8800GS should entirely suffice for my own needs...but I guess madshi prolly has a secret weapon in the works :devil:
The best I can say is the results are inconsistent
Maybe you do need a Monster Cable after all http://forum-images.hardware.fr/images/perso/mrbrelle.gif

[madshi]

We still have no idea of what's in the works(or not) http://forum-images.hardware.fr/images/perso/piksou.gif

frame interpolation à la "trimension DNM"? highly complicated sharpening algorithm? degraining for those who like clay movies? I'm out of imagination on what could possibly require so much GPU power in order to play movies :o
I don't plan to implement intermediate frame interpolation stuff like Trimension DNM.

i got a spanking new 5750 today... thank you guys for the help... :P
Hope you like it!

So if I have a hardware monitor calibration system then this will help me calibrate my colors and gamma correctly?
Yes.

Also I can't get MPC-HC's internal Subtitle renderer to work with madVR though I would prefer it to.
This is not implemented in madVR yet, but it's on my to do list (along with a lot of other important stuff).

this night I did some more testing on these strange timings and now I'm pretty lost but I'll try to explain in details what I did and what were my results and I hope you'll find some useful info in it.
First I tried to use Reclock (VSync correction off) but then I had ~20ms times in 19 out of 20 attempts. When I got the ~0.1ms present times I jumped ahead in the file and the times went to ~20ms ... for about an minute or so it was slowly raising. I guess Reclock is somehow delaying madVR's detection of the VSync even though I've turned off the correction in ReClock's settings.

Then I tried using a Direct Sound Device and with it each time I start a file just after I've started the player I get ~20ms times. If I start the file over or start another file it's back to ~0.1ms. And this was the case in all 30+ attempts except one. In it the playback started with ~6ms present time but just after I jumped ahead in the file (55 seconds) it went back to ~0.1ms but again slowly.

The other "strange" thing I noticed ... once or twice ... on the first playback after the player was started was that if I was quick enough to show the OSD right after I play the file it starts with small times and just when it shows the composition rate (inserts the line in the OSD) the times jump to ~20ms.
Does this ring any bells?
Not really. Is this all with "aero" timing mode again? And all of this does not happen with the other timing modes?

And one more thing - can you add an option (no interface just in the INI file) to start playback with the OSD on? It will be very convenient for such testing purposes.
v0.22.

mashi, some more results. There were no dropped frames. Stats reset after playback settles, reclock used (no v-sync), V0.18 style settings. A new video timing for a new CRT projector (coming in a touch over ideal at 95.906hz..I can't get 95.904..but it shouldn't matter).

No MMCSS

Test 1: 15 mins = 10 delayed

Test 2: 15 mins = 34 delayed



No present stats

Test 1: 68 mins = 7 delayed

Test 2: 15 mins = 22 delayed, then 35 mins = 24 delayed

v0.18

Test 1: 10 mins = 18 delayed, then 20 mins = 30 delayed

Test 2: 15 mins = 19 delayed

On other occasions v0.18 has been rock solid (before I messed with my video timings, but they are very close).

I watched "Pandorum" (loved it) last night at standard v0.21, at default settings was not good with a handful of dropped frames and over 800 delayed frames.

The best I can say is the results are inconsistent....I'm sorry.
Hmmmm... These results give us no real clue. So I seems v0.18 is not better after all. At least not during your tests. The delayed frames should go away (or at least improve) in fullscreen exclusive mode.

madshi, I have not been able to test lately, but now I've tried some SD and HD sources and here are the results. I decided to simply watch and not use the stats at all, fwiw:

SD sources (spline64/spline64/softcubic80) 23.976fps @ 24Hz

(1) Which backbuffer count works best for you? Which is maybe not best, but still acceptable? Which doesn't work at all for you?
- I cannot see a difference with any setting above 3. I did not test below 3.

(2) Which timing mode works best for you? Which is maybe not best, but still acceptable? Which doesn't work at all for you?
- Normal seems to work best. Aero mode gives me tearing.

(3) How about "upload frames in render thread" and "copy 1 backbuffer at a time"?
- I see no difference with this on or off.

HD sources (spline64/spline64/softcubic80) 29.970fps @ 60Hz

(1) Which backbuffer count works best for you? Which is maybe not best, but still acceptable? Which doesn't work at all for you?
- I cannot see a difference with any setting above 3. I did not test below 3.

(2) Which timing mode works best for you? Which is maybe not best, but still acceptable? Which doesn't work at all for you?
- I see no diff between Aero mode and Normal mode.

(3) How about "upload frames in render thread" and "copy 1 backbuffer at a time"?
- I see no difference with this on or off.

HD2600XT(512MB), CCC10.3, Win7 x64, Aero OFF, dual-mon (primary 60Hz, sec 24Hz and 60Hz, both 1920x1080)
HMS/FFDshow/Reclock/madVR/MPC-HC
3Dlut OFF
flush|flush and wait(sleep)|don't|don't


Additionally, all playback is on the secondary, I have reclock vsynch OFF and I am using reclock to resample/re-encode to AC3, even 2-channel audio. I also went back to .18 and reviewed some motion scenes and I see no diff in smoothness to .21 (both very smooth).
Thanks. Seems that with your machine most of the tweak options don't really do much.

[madshi]

madVR v0.22 released

http://madshi.net/madVR.zip

* fixed: incompatability with some decoders/videos (corrupted chroma display)
* fixed: incompatability with some decoders/videos (playback doesn't start)
* fixed: incompatability with DirectVobSub (playback doesn't start)
* fixed: incorrect aspect ratio with some decoders/videos
* implemented support for realtime video resolution change
* added workaround for buggy MPC HC m2ts VC-1 splitter (shuffled timestamps)
* improved frame drop/delayed behaviour when decoder is too slow
* removed "copy only 1 backbuffer at a time" option -> now always set
* added option "use managed 3dlut texture (XP only)", default true
* OSD state (on/off) survives media player restarts now
* OSD statistics reset (Ctrl+R) now also works if OSD is not turned on
* media player window is not moved to front by madVR, anymore
@cyberbeing: Can you please test whether unchecking the new option "use managed 3dlut texture" improves the problem you reported with Avatar and Evangelion? I can't see a difference with that option on/off on my XPSP3 machine. Average and max rendering times seem to be comparable. But this is the only thing I could think of to improve the problem. So please give it a try. If it doesn't work there's nothing I can do. BTW, my relatively modest HD 3850 breezes through Evangelion without any problems without 3dlut file. Don't know, maybe it's a problem specific to the way NVidia's texture cache works (or doesn't work)?

@Everyone: Would everybody be ok with me removing the "timing model" option and setting it forced to "high refresh rate"? I've revisited your feedback on the timing models and it seems that most people can't see a difference between normal and high refresh rate timing models, while some people say that high refresh rate works better. And most people report that the "aero" timing model is equal or worse (with only 1-2 exceptions).

[leeperry]

Thanks for the new version!
Would everybody be ok with me removing the "timing model" option and setting it forced to "high refresh rate"?
Well, I'm having much more stable playback in 96Hz on XP w/ 0.21 when it's set to "normal"...maybe you could leave it but set it to "high refresh rate" by default? I'll run more tests, but these tests take forever :o

I haven't used 3DLUT's in a while, but I'll try the new XP-only option and report back.

[droc]

Thanks Madshi!!! (MadVr 0.22)
No more green screen with Cyberlink decoder, speed is very smooth now on Aero!!!

[pankov]

Not really. Is this all with "aero" timing mode again? And all of this does not happen with the other timing modes?
madshi,
my last results were all with "normal" timing mode. I dumped aero timing mode when I firstly saw the ~20ms present times. I guess it was just more often with it, now that I saw it with normal mode too ... or when using reclock.
I'll do some testing with v0.22 now. Do you want me to test something special or do some logging of this strange ~20ms vs 0.1ms present times behavior?
my general conclusion is that if I get ~0.1 present times everything is 100% smooth but if it's ~20ms I get occasional stutter.

[madshi]

Well, I'm having much more stable playback in 96Hz on XP w/ 0.21 when it's set to "normal"... maybe you could leave it but set it to "high refresh rate" by default? I'll run more tests, but these tests take forever :o
Argh. Of course I can keep all tweak options, it's just so complicated for new users. I'd prefer to remove as many options as possible. But if some options are really necessary, I'll have to keep them.

I haven't used 3DLUT's in a while, but I'll try the new XP-only option and report back.
This option is mainly a test for a problem reported by cyberbeing. I don't think anybody else will have use for this option right now. I will probably remove it in the next build again, because I don't think that it will help at all.

Thanks Madshi!!! (MadVr 0.22)
No more green screen with Cyberlink decoder, speed is very smooth now on Aero!!!
I didn't actually test the Cyberlink decoder, but it's good to hear that this problem is fixed, too!

my last results were all with "normal" timing mode. I dumped aero timing mode when I firstly saw the ~20ms present times. I guess it was just more often with it, now that I saw it with normal mode too ... or when using reclock.
I'll do some testing with v0.22 now. Do you want me to test something special or do some logging of this strange ~20ms vs 0.1ms present times behavior?
my general conclusion is that if I get ~0.1 present times everything is 100% smooth but if it's ~20ms I get occasional stutter.
Don't really know why present times are so strange for you. But then, they may not be measured correctly if you don't "flush & wait" after the presentation. So I'm not really sure how much stock you can put into these measurements. Also I don't really see what I could change in madVR to affect it. I can only say that in fullscreen exclusive mode present times will be always ~0.1 (unless I present with a all backbuffers already in use).

[Trigunflame]

I can't tell any difference between timing models on my system, so do what you think is best.

Any luck with those AR sample videos on Win7?
Reading the notes on v0.22, I had thought it was fixed :p Sadly, it still refuses to size properly :/

[Razoola]

Thanks for the new version... Testing over this weekend.

[121sea]

whats this button do?

(1) Creating madVR instance:

DEFINE_GUID(CLSID_madVR, 0xe1a8b82a, 0x32ce, 0x4b0d, 0xbe, 0x0d, 0xaa, 0x68, 0xc7, 0x72, 0xe4, 0x23);

(2) Activating fullscreen exclusive mode:

[uuid("51FA8F61-1444-4597-996E-7495405753E6")]
interface IMadVRFullscreen : public IUnknown
{
STDMETHOD(ActivateFullscreenMode)(void) = 0;
};

[madshi]

I can't tell any difference between timing models on my system, so do what you think is best.

Any luck with those AR sample videos on Win7?
Reading the notes on v0.22, I had thought it was fixed :p Sadly, it still refuses to size properly :/
On my XPSP3 machine all renderers show these 2 samples with incorrect ARs - except madVR v0.22, which now shows them with correct AR. E.g. for the first sample I'm now getting:

dwPictAspectRatioX: 13
dwPictAspectRatioY: 10
So I thought it would be fixed in win7, too. Haven't actually tested it in win7, though. Are you sure that you actually tried with v0.22? Sometimes the browser gives you an older file from the cache. Does the version number in the madVR settings dialog read "0.22"?

Edit: Screw that, now all other renderers show correct AR on my XPSP3 PC, too. But madVR does also. I think it also depends on the decoder. Before today I had ffdshow set up to not contain the aspect ratio in the media type. I think now that this was responsible for me getting incorrect AR all the time. But as I said, it works fine for me now with madVR. Both your samples show correct AR on my PC with madVR 0.22.

[madshi]

whats this button do?
Button? Which button? There is no such button.

[Trigunflame]

On my XPSP3 machine all renderers show these 2 samples with incorrect ARs - except madVR v0.22, which now shows them with correct AR. E.g. for the first sample I'm now getting:

dwPictAspectRatioX: 13
dwPictAspectRatioY: 10
So I thought it would be fixed in win7, too. Haven't actually tested it in win7, though. Are you sure that you actually tried with v0.22? Sometimes the browser gives you an older file from the cache. Does the version number in the madVR settings dialog read "0.22"?

Edit: Screw that, now all other renderers show correct AR on my XPSP3 PC, too. But madVR does also. I think it also depends on the decoder. Before today I had ffdshow set up to not contain the aspect ratio in the media type. I think now that this was responsible for me getting incorrect AR all the time. But as I said, it works fine for me now with madVR. Both your samples show correct AR on my PC with madVR 0.22.

I always make sure to "Check" which version I'm using, before I report back.
I did all of the following testing using a Fresh install with all involved variables (MPC-HC, MadVR & FFDSHOW-Tryouts).
Note though, I did uncheck "Use managed 3dlut texture (XP only)" in this MadVR build (v0.22). I'm not sure why it would be defaulting to enabled on a Win7 system, if it's XP only....

On my end, it makes no difference whether it utilizes MPC-HC's internal libavcodec filters or ffdshow's, the Output (AR) result is just the same.
The pins are still reporting Incorrect AR info. Again, this does Not occur with EVR or even Haali.

http://i.imagehost.org/0186/1_118.jpg

I think it's imperative that the testing be done on Win7.
However, I'll try and test this on WinXPSP3 myself and see what results I find.

Update:
I just did a Fresh Install of XPS3 x86.
Updated to the newest drivers, installed all available windows updates, updated to the newest directx runtimes, etc.
Also, fresh install of MPC-HC r2099 & FFDSHOW-Tryouts r3488, MadVR v0.22 & Haali 1.10.175.0 (which isn't registered for AVI anyway).

The results are Just the same as on Windows7 x64. EVR, EVR-Custom & Haali work fine - MadVR does not. Screens following:

Haali
http://i.imagehost.org/0251/haali.jpg

MadVR v0.22
http://j.imagehost.org/0622/madvr.jpg

So it's obviously not specific to Win7 either.
There has to be a way to track down what is causing this.

I'm going to go back through all the of the MadVR versions, as well as go back to the older 19x.xx Nvidia Drivers & see if it makes a difference.
If you think there is a better way to debug this on my end, let me know.

[Grafisher]

There is a new problem in 0.22. In fullscreen, when the cursor is hidden, and you move it within the renderer area, the cursor remains hidden (it should show up). If you move it outside the renderer area, it shows up again. This also happens when the video is loaded and the cursor is under the video area.

No other issues so far. Great!

Zoom Player, Win7, Aero on

[cyberbeing]

@cyberbeing: Can you please test whether unchecking the new option "use managed 3dlut texture" improves the problem you reported with Avatar and Evangelion? I can't see a difference with that option on/off on my XPSP3 machine. Average and max rendering times seem to be comparable. But this is the only thing I could think of to improve the problem. So please give it a try. If it doesn't work there's nothing I can do. BTW, my relatively modest HD 3850 breezes through Evangelion without any problems without 3dlut file. Don't know, maybe it's a problem specific to the way NVidia's texture cache works (or doesn't work)?

It doesn't seems to help the problem at all. I still get massive delayed/dropped frames for that scene on Avatar with my NVIDIA card.

As you saw for yourself, and I also tested with the ATI 5750 awhile back, ATI cards don't have this problem at all. Absolutely no slowdown for ATI cards in the sections which NVIDIA cards (7800GTX, GTX 470) had massive rendering time spikes. It does seem to be NVIDIA specific, so I shouldn't be the only NVIDIA user to see this issue. If anybody else wants to test, the major 3DLUT delayed/dropped frames occurs at 01:21:40 - 01:22:10 when played back at a 1920x1080 desktop resolution. Problem does not occur with a 1920x1080 video played back at a 1280x720 desktop resolution.



madshi, I still suspect the problem lies with NVIDIA cards potentially have some sort of limitation on the number pixels of a large texture (i.e. 1920x1080) which can be accessed/modified simultaneously, or some such. Would there be any way for you to break down madVR feeding the graphics card the 3DLUT into multiple operations?

Maybe doing something like splitting each frame into red, green, and blue channels and applying a LUT individually to each channel?

Or how about splitting each frame into multiple smaller textures, applying the 3DLUT to each, and stitching them back together before display?

What about trying something where madVR always does the 3DLUT processing in real-time without creating a queue of completed frames, in a way where madVR is never processing a 3DLUT for a future frame and displaying the current frame at the same time, but always in succession, as needed. Since you always seem to claim 3DLUT rendering times should be constant, is a queue of completed frames in the current madVR even needed? Either your GPU is fast enough or it isn't, correct? There shouldn't be any variability from frame to frame.

Related to this, I guess the question is, does madVR currently process future frames with a 3DLUT at the exact same time it is presenting the current frame? Could things would better if madVR was only having the GPU do a single operation at any given time, and waiting for completion of said operation before issuing the next, waiting for completion of said operation before issuing the next, and so on?

Ever thought about creating an OpenGL version of madVR? OpenGL also supports shader math, so shouldn't everything your doing with LUT, resizing, and dithering also be possible with OpenGL. I've even seen someone port a standard denoiser to an OpenGL accelerated denoiser for Photoshop, so things such as that are also possible. Ever since Photoshop choose OpenGL over Direct3D, I've been curious if it offered some sort of advantage over Direct3D for applying LUTs via ICC profiles and color management. Who knows, maybe all these problems are just Direct3D related or something, and distancing yourself from DirectX would help.

Just trying to brainstorm ideas, no clue if any of the above would actually help without knowing what the real cause is.



BUG
I've been getting resetting Direct3D device failed (8876086c) when going from windowed to fullscreen and fullscreen to windowed. Actually it seems to happen whenever the window is resized and it also hangs the player. New problem introduced in 0.22 using MPC-HC 1.3.0.2099.0 from xvidvideo.ru .

BUG UPDATE
I updated MPC-HC to 1.3.0.2110 built by Aleksoid1978, rebooted, and above error doesn't happen any longer. Must have been a MPC-HC bug *shrug*. I'll keep my eye on it to see if it comes back.


Edit: I just noticed that ever since MPC-HC changeset 2068, the D3D Fullscreen checkbox has become available for madVR. The option does appear to force madVR to be locked to Fullscreen in a D3D Fullscreen fashion, but I assume you still need to make some more changes to madVR for Fullscreen Exclusive mode to actually be fully functional and useful?

[leeperry]

Argh. Of course I can keep all tweak options, it's just so complicated for new users. I'd prefer to remove as many options as possible. But if some options are really necessary, I'll have to keep them.
I just watched two 90 mins movies in 96.000Hz, they were butter smooth from start to end...yes, I'd like to keep the "normal" timings if any possible please. Now that everything works like a charm(I still rest my case that Reclock can get in the way sometimes), I'd rather keep this config if any possible. I've had bad experiences w/ the "high refresh rate" timings, but OK I'll run more tests if needed.

I'm not sure I'd see any point running in D3D FS exclusive mode, but if you can just set a hotkey to toggle it...why not! :cool:

[mark0077]

Hi. Just noticed a tiny niggle that won't really bother anyone too much but worth mentioning

I notice in windows 7 when I have a movie playing not in fullscreen and when I hover over the taskbarnicon for mpc. I see a preview of the window. That's fine but if I then hover on that preview which I think brings the mpc to foreground then the preview plays but video stops updating on the main mpc window. Actually video stops in the main window except perhaps 50 pixel tall strip at the bottom of the window.

Jus thought I should mention as I can't reproduce outside of madvr.

[Trigunflame]

Would any of the regular visitors to this thread (besides Madshi), be so kind as to test these two sample as well & see what results you get?
I've been testing this specific case for Days & we don't seem to be making any headway. Please be sure to post your specs as well.

Test procedure using MPC-HC (preferably a recent SVN version).
1) Select EVR as the renderer.
2) Play both samples windowed (make sure that the Video Frame > Keep Aspect Ratio option is enabled)
3) Select Haali as the renderer.
4) Repeat #2 again.
5) Select MadVR as the renderer.
6) Repeat #2 again.
7) Note if any of the renderers exhibit a problem with AR.

Download samples here:
http://www.multiupload.com/HJ5JISVUJB

Sample.avi should be played @ 13:10 like so:
http://i.imagehost.org/0181/0_7.jpg

Sample2.avi should be played @ 16:9 like so:
http://a.imagehost.org/0368/2_49.jpg

[27049215]

Small thing to report:
The settings page is too large for my monitor

I have an old 15" LCD using 1024x768 resolution. The madvr settings page's cancel, apply button is right under the taskbar, not possible to click these buttons by mouse

maybe group some similar options and move it into a new tab
:thanks:

[cyberbeing]

Would any of the regular visitors to this thread (besides Madshi), be so kind as to test these two sample as well & see what results you get?

Both play with the correct aspect ratio in madVR when using XVID as the video decoder or the MPC-HC internal decoder.

Both play with the incorrect aspect ratio in madVR when using FFDshow as the video decoder.

VMR9, EVR, and Haali Renderer all play with the correct aspect ratio with FFDShow, XVID, and the MPC-HC internal decoder.

madVR is unique, being the only renderer which has an aspect ratio issue with FFDshow as the decoder. FFDshow bug or madVR bug?

WinXP SP3 x86

[madshi]

There is a new problem in 0.22. In fullscreen, when the cursor is hidden, and you move it within the renderer area, the cursor remains hidden (it should show up). If you move it outside the renderer area, it shows up again. This also happens when the video is loaded and the cursor is under the video area.
Weird! Will have a look at that.

It doesn't seems to help the problem at all.
Ok, so I'll remove that option again.

I still suspect the problem lies with NVIDIA cards potentially have some sort of limitation on the number pixels of a large texture (i.e. 1920x1080) which can be accessed/modified simultaneously, or some such.
The 3dlut texture is not modified, it's only accessed, so it would have to be the accessing. Also the slowdown only seems to occur during some specific scenes, which means that the 3dlut accessing normally seems to work just fine with your NVidia card, too. This makes me believe that the NVidia texture cache doesn't work properly for the 3dlut, for whatever reason. However, the 3dlut is 96MB big. So it's not realistic to expect the texture cache to do wonders, anyway. So I'm really not sure what the problem is...

Would there be any way for you to break down madVR feeding the graphics card the 3DLUT into multiple operations?

Maybe doing something like splitting each frame into red, green, and blue channels and applying a LUT individually to each channel?
That would be possible, but it would slow things down, because we'd need 3 texture accesses for every pixel instead of only 1. Maybe eventually it could help in these specific scenes of Avatar and Evangelion, but it would harm in all other scenes.

Or how about splitting each frame into multiple smaller textures, applying the 3DLUT to each, and stitching them back together before display?
Again, it would be possible, but here I don't even see any potential for improvement. I think the overall processing time would not go down, it would only increase.

What about trying something where madVR always does the 3DLUT processing in real-time without creating a queue of completed frames, in a way where madVR is never processing a 3DLUT for a future frame and displaying the current frame at the same time, but always in succession, as needed. Since you always seem to claim 3DLUT rendering times should be constant, is a queue of completed frames in the current madVR even needed? Either your GPU is fast enough or it isn't, correct? There shouldn't be any variability from frame to frame.

Related to this, I guess the question is, does madVR currently process future frames with a 3DLUT at the exact same time it is presenting the current frame? Could things would better if madVR was only having the GPU do a single operation at any given time, and waiting for completion of said operation before issuing the next, waiting for completion of said operation before issuing the next, and so on?
I would have expected rendering time to be pretty much identical for every video frame with current madVR algorithms. But I think it's possible that the texture cache could come into play and in that case if a specific video frame accesses parts of the 3dlut which are rarely used, it might harm performance. In that case some frames might need more processing times than others. Of course I could limit the rendering queue to 1 item. But how would that help if the processing of specific video frames takes longer than the vsync period? Limiting the rendering queue wouldn't change that.

BTW, madVR does never render two video frames at the same time. madVR always only renders one video frame, then moves to the next. The rendering results are then stored in the rendering queue. If you want madVR to wait after every rendering action before moving on, just set all flush values to "flush & wait".

Ever thought about creating an OpenGL version of madVR?
I thought about it in the beginning, when starting madVR development. I could have chosen OpenGL over Direct3D. But then I did not see any valid reason for doing so. Some OpenGL drivers are written in such a way that internally they map back to Direct3D, anyway. Other drivers may not be written that way. But since most games use Direct3D instead of OpenGL, I would generally expect Direct3D drivers to be better optimized than OpenGL drivers. Also, Direct3D will always give me access to the latest Windows features like e.g. 10bit RGB output. Don't know if OpenGL supports that. Anyway, switching to OpenGL would cost me *MAJOR* work. So it's no really an option.

Also, I don't really think OpenGL would bring any improved performance. The 3dlut lookup is done by the GPU and the GPU does not care what SDK (Direct3D or OpenGL) the game is using. Makes no difference to the GPU.

Edit: I just noticed that ever since MPC-HC changeset 2068, the D3D Fullscreen checkbox has become available for madVR. The option does appear to force madVR to be locked to Fullscreen in a D3D Fullscreen fashion, but I assume you still need to make some more changes to madVR for Fullscreen Exclusive mode to actually be fully functional and useful?
madVR has a new programming interface which MPC-HC accesses to switch madVR into fullscreen exclusive mode. But madVR does not actually go into fullscreen exclusive mode yet. The change in MPC-HC is just a preparation for a future madVR version.

I just watched two 90 mins movies in 96.000Hz, they were butter smooth from start to end...yes, I'd like to keep the "normal" timings if any possible please. Now that everything works like a charm(I still rest my case that Reclock can get in the way sometimes), I'd rather keep this config if any possible. I've had bad experiences w/ the "high refresh rate" timings, but OK I'll run more tests if needed.
I think back when you tested the high refresh rate model, you were using different settings for many other tweak options. Maybe you could switch to high refresh rate model for the next 2 movies, just to see if it really is worse? Maybe it's just as good as the normal timing model now?

Hi. Just noticed a tiny niggle that won't really bother anyone too much but worth mentioning

I notice in windows 7 when I have a movie playing not in fullscreen and when I hover over the taskbarnicon for mpc. I see a preview of the window. That's fine but if I then hover on that preview which I think brings the mpc to foreground then the preview plays but video stops updating on the main mpc window. Actually video stops in the main window except perhaps 50 pixel tall strip at the bottom of the window.
That's really weird! Not sure what's going on there...

Small thing to report:
The settings page is too large for my monitor
The settings dialog will be redesigned in a future madVR version.

I did all of the following testing using a Fresh install with all involved variables (MPC-HC, MadVR & FFDSHOW-Tryouts).

On my end, it makes no difference whether it utilizes MPC-HC's internal libavcodec filters or ffdshow's, the Output (AR) result is just the same.
The pins are still reporting Incorrect AR info. Again, this does Not occur with EVR or even Haali.
When using ffdshow, could you please make sure that in ffdshow's output settings page the options "set pixel aspect ratio in media type" and "allow output format changes during playback" are checked and that the option "connect to compatible filters only" is unchecked? With these settings I definitely get the correct AR here on XPSP3 with ffdshow. With the internal MPC Video decoder (older version, though) playback doesn't even start here. With VMR9 and the internal MPC Video decoder audio playback starts, but video is stuck on the first frame with incorrect AR.

[madshi]

Both play with the correct aspect ratio in madVR when using XVID as the video decoder or the MPC-HC internal decoder.
What is this "XVID" video decoder?

Both play with the incorrect aspect ratio in madVR when using FFDshow as the video decoder.
As I replied to Trigunflame:

When using ffdshow, could you please make sure that in ffdshow's output settings page the options "set pixel aspect ratio in media type" and "allow output format changes during playback" are checked and that the option "connect to compatible filters only" is unchecked? With these settings I definitely get the correct AR here on XPSP3 with ffdshow.

[Trigunflame]

Ok madshi, (it's late as hell btw, ~3:00am) & I'm on another PC (I'll test my primary sometime tomorrow evening).

My initial tests on this PC were a little different (It's an 64 x2 6000+, HD 4550 & Catalyst 10.6 drivers).
MadVR worked fine utilizing the internal MPC-HC filters & presented the correct AR (I'm stumped as to Why? Considering it didn't on the other setups. Possibly Nvidia related??)
However, when switching to FFDSHOW, the AR problems were identical as to those seen on my other setups (Win7 x64 & XPSP3 x86 on primary PC).

Good news being, it seems as if configuring FFDSHOW in the way you suggested seemed to have alleviated the problem.
It seems as if by default the FFDSHOW options are configured to "Smartly" adjust their connection methods; but for some reason they weren't doing so when used with MadVR. Possibly a bug on their end? It might be handy to mention this in a FAQ somewhere for the time being.

[cyberbeing]

That would be possible, but it would slow things down, because we'd need 3 texture accesses for every pixel instead of only 1. Maybe eventually it could help in these specific scenes of Avatar and Evangelion, but it would harm in all other scenes.

Again, it would be possible, but here I don't even see any potential for improvement. I think the overall processing time would not go down, it would only increase.
Yes, I realized my ideas would cause an overall slowdown, but how much of a slowdown are we talking about?

My rendering time at 1920x1080 without resizing is only ~10ms, even with my ancient 7800GTX 512. That gives me an entire 30ms of wiggle room for 24fps content where things could get slower and still playback perfectly. Stability is more important then speed. Low render times mean nothing when a watching a movie gets ruined by 100+ frames being dropped during random scenes in random movies. If making such changes fixed the NVIDIA rendering spike bug, any overall slowdown would be totally worth it as long as it stayed below the movie frame interval.



BTW, madVR does never render two video frames at the same time. madVR always only renders one video frame, then moves to the next. The rendering results are then stored in the rendering queue. If you want madVR to wait after every rendering action before moving on, just set all flush values to "flush & wait".

I think you misunderstood what I was saying a bit. I was throwing around the idea that possibly the queues could be causing this problem for NVIDIA cards.

In other words, if you completely eliminated the queues and had the GPU only store AND work on a single frame at any give time.

So instead of something like:

Decode Frame 1 through 3 -> Queue -> Render frame 1 ->Queue ->Render Frame 2 ->Queue -> Present Frame 1 -> Decode frames 4 through 6 -> Queue -> Render Frame 3 -> Queue -> Present Frame 2


Do the following instead:

Decode Frame 1 -> Render Frame 1 -> Present Frame 1 -> Decode Frame 2 -> Render Frame 2 -> Present Frame 2.

At any give time, only the 3DLUT and a single movie frame would be stored in GPU memory. At any given time, only a single operation would be performed on that single frame. If the problem really is related to GPU memory and cache access, couldn't completely eliminating the queues and going from Decode to Render to Present sequentially, in real-time, potentially help with this issue? Of course, if this doesn't work, it would make everything much much worse.


If it's not too much work, it would be nice to at least try out some impractical ideas, just to see if any actually fix the issue.

Have you considered opening communication with NVIDIA, to see if one of their engineers could offer you any help or insight? I seem to remember neuron2 was in contact with an NVIDIA engineer when he was working on his CUDA decoder. You never know, maybe someone at NVIDIA would be willing to help you create a workaround this issue. They know their GPUs best after-all.

What is this "XVID" video decoder?
I hope that is a joke. Next thing, you'll tell me you don't know what DIVX is.
http://www.xvid.org/
http://en.wikipedia.org/wiki/Xvid


As I replied to Trigunflame:

When using ffdshow, could you please make sure that in ffdshow's output settings page the options "set pixel aspect ratio in media type" and "allow output format changes during playback" are checked and that the option "connect to compatible filters only" is unchecked? With these settings I definitely get the correct AR here on XPSP3 with ffdshow.

That works. Which means this is a FFDshow bug, since it isn't aware that madVR supports 'output format changes' using its auto mode.

[madshi]

Yes, I realized my ideas would cause an overall slowdown, but how much of a slowdown are we talking about?
I've no idea. I'll have to talk to yesgrey about whether splitting the 3dlut into 3 separate streams would cause any IQ trouble, before I can even start to think about implementing such a change.

My rendering time at 1920x1080 without resizing is only ~10ms, even with my ancient 7800GTX 512. That gives me an entire 30ms of wiggle room for 24fps content where things could get slower and still playback perfectly. Stability is more important then speed. Low render times mean nothing when a watching a movie gets ruined by 100+ frames being dropped during random scenes in random movies. If making such changes fixed the NVIDIA rendering spike bug, any overall slowdown would be totally worth it as long as it stayed below the movie frame interval.
Yes.

I think you misunderstood what I was saying a bit. I was throwing around the idea that possibly the queues could be causing this problem for NVIDIA cards.
I did understand what you mean. But I don't really see any potential benefit. You've said yourself that the max rendering times go through the roof. They will also go through the roof if I do what you suggested. If at all, the queues should help hiding the problem a bit. I think without the queues it will only be worse.

But I was planning to add an option to select the queue size in a future madVR version, anyway. So you can simply set it to 1 and see if that improves things. I'm fairly certain it won't, though.

If it's not too much work, it would be nice to at least try out some impractical ideas, just to see if any actually fix the issue.
Let's first wait for fullscreen exclusive mode. If that already fixed the issue (I don't think so, but who knows) it would save me a lot of time.

Have you considered opening communication with NVIDIA, to see if one of their engineers could offer you any help or insight? I seem to remember neuron2 was in contact with an NVIDIA engineer when he was working on his CUDA decoder. You never know, maybe someone at NVIDIA would be willing to help you create a workaround this issue. They know their GPUs best after-all.
I've already had a very hard time getting some NDA documentation from NVidia. Took me months to get it. Without a proper contact I see no hope. I think neuron2 had luck because he did his development work when NVidia was actively pushing CUDA development. So he had contact to a determined CUDA NVidia developer. Unfortunately developer support for relatively unknown people like me is really bad with both NVidia and ATI.

I hope that is a joke. Next thing, you'll tell me you don't know what DIVX is.
I know what xvid is. But I already have about 5 decoders on my PC which can decode it. I wasn't aware that there was an "official" up-to-date xvid decoder, too.

My initial tests on this PC were a little different (It's an 64 x2 6000+, HD 4550 & Catalyst 10.6 drivers).
MadVR worked fine utilizing the internal MPC-HC filters & presented the correct AR (I'm stumped as to Why? Considering it didn't on the other setups. Possibly Nvidia related??)
cyberbeing has an NVidia card and for him AR is always correct (if ffdshow is configured correctly). Don't know why your NVidia PC made such problems. Ok, we know why ffdshow + madVR didn't work, but I don't understand why you had problems with the other decoders, too. Is it possible that when using the other decoders, maybe you had an ffdshow raw video processor instance in your graph? That would explain it.

However, when switching to FFDSHOW, the AR problems were identical as to those seen on my other setups (Win7 x64 & XPSP3 x86 on primary PC).

Good news being, it seems as if configuring FFDSHOW in the way you suggested seemed to have alleviated the problem.
Note: (only "allow output format changes during playback" needed to be changed from squared to checked. "connect to compatible filters only" could be left checked as well as leaving "set pixel aspect ratio in output media type" squared.

It seems as if by default the FFDSHOW options are configured to "Smartly" adjust their connection methods; but for some reason they weren't doing so when used with MadVR. Possibly a bug on their end? It might be handy to mention this in a FAQ somewhere for the time being.
That works. Which means this is a FFDshow bug, since it isn't aware that madVR supports 'output format changes' using its auto mode.
Let me explain the technical background a bit:

These AVI samples are a bit weird in that the decoder connects to the renderer with AR 11:10. Only after playback started, the decoder notices: "Oh, this is AR 13:10". You can see that the media player window starts as AR 11:10 for half a second or so, and then changes to 13:10, with all renderers. Now DirectShow knows several different methods how a decoder can notify a renderer about a changed AR. Would be too easy if there was only one method, wouldn't it? :mad: Anyway, earlier madVR builds only supports one method. But it seems that most decoders are using a different method, so madVR 0.22 now suppports that, too. Which means that AR should now be correct with most decoders and most videos with madVR 0.22.

ffdshow is a bit special in that it doesn't even *try* to notify the video renderer about a changed AR, unless ffdshow knows that the video renderer supports the AR change (or unless you force ffdshow to send the AR change by configuring it accordingly). madVR didn't support ffdshow's way of signaling an AR change until now, so that's why madVR is not in ffdshow's list of "compatible filters" yet. With the release of 0.22, I've already notified the ffdshow devs that madVR should now be added to that list. So the problem should be fixed in a future ffdshow version.

[cyberbeing]

I did understand what you mean. But I don't really see any potential benefit. You've said yourself that the max rendering times go through the roof. They will also go through the roof if I do what you suggested. If at all, the queues should help hiding the problem a bit. I think without the queues it will only be worse.

But I was planning to add an option to select the queue size in a future madVR version, anyway. So you can simply set it to 1 and see if that improves things. I'm fairly certain it won't, though.

Which of the following takes more resources?

A) GPU attempting to render a difficult frame, at the same time stressing to fill multiple queues which are being emptied faster then it can fill them, all while trying to present frames at correct times.

B) GPU only rendering the difficult frame while doing absolutely nothing else at the same time.

That said, could you make the minimum queue size 0 (just as a test) instead of 1 being the minimum?


I know what xvid is. But I already have about 5 decoders on my PC which can decode it. I wasn't aware that there was an "official" up-to-date xvid decoder, too.

I was using the XVID 1.2.2 Koepi build here, which is an up-to-date build of the official codec source-code:
http://www.koepi.info/Xvid-1.2.2-07062009.exe

[brokenmind]

There is a new problem in 0.22. In fullscreen, when the cursor is hidden, and you move it within the renderer area, the cursor remains hidden (it should show up). If you move it outside the renderer area, it shows up again. This also happens when the video is loaded and the cursor is under the video area.

I can confirm this one (win7 32bit/aero off) - it's not a big deal and only seems to happen with ZP; to reproduce:
- play video in ZP and go fullscreen
- wait until mouse cursor is hidden
- now move the cursor;
- it will only show again after leaving rendered area

and regarding the XVID decoder - madVR shows 'unknown fps' for 'movie' section in the OSD when using it in the filter chain - but maybe it's just a cosmetical thing...

[Trigunflame]

cyberbeing has an NVidia card and for him AR is always correct (if ffdshow is configured correctly). Don't know why your NVidia PC made such problems. Ok, we know why ffdshow + madVR didn't work, but I don't understand why you had problems with the other decoders, too. Is it possible that when using the other decoders, maybe you had an ffdshow raw video processor instance in your graph? That would explain it.
I wish I could say that were the case, and I'll make double sure to observe that possibility when I test again on that PC. Though, I'm almost positive that it wasn't the case being that I haven't touched the raw decoder setting in FFDSHOW in years. I specifically even tested without FFDSHOW installed the other day and the issue occurred still, while utilizing the internal MPC filters. I honestly have NO clue whatsoever, as to why the Video AR worked out-of-the-box with MadVR/MPC-HC on this PC but not on either OS setup on the primary (the Win7x64 being an days old install & the XPx86 one being Fresh)


Let me explain the technical background a bit:

These AVI samples are a bit weird in that the decoder connects to the renderer with AR 11:10. Only after playback started, the decoder notices: "Oh, this is AR 13:10". You can see that the media player window starts as AR 11:10 for half a second or so, and then changes to 13:10, with all renderers. Now DirectShow knows several different methods how a decoder can notify a renderer about a changed AR. Would be too easy if there was only one method, wouldn't it? :mad: Anyway, earlier madVR builds only supports one method. But it seems that most decoders are using a different method, so madVR 0.22 now suppports that, too. Which means that AR should now be correct with most decoders and most videos with madVR 0.22.

ffdshow is a bit special in that it doesn't even *try* to notify the video renderer about a changed AR, unless ffdshow knows that the video renderer supports the AR change (or unless you force ffdshow to send the AR change by configuring it accordingly). madVR didn't support ffdshow's way of signaling an AR change until now, so that's why madVR is not in ffdshow's list of "compatible filters" yet. With the release of 0.22, I've already notified the ffdshow devs that madVR should now be added to that list. So the problem should be fixed in a future ffdshow version.
Very insightful. Glad to hear that the devs have been notified.
Thankfully, the solution that you provided seems to work for FFDSHOW & can be used until the appropriate changes are made on their end.
Thanks again for helping out; I know it must have been annoying sifting through all of my posts, lol.

[madshi]

Which of the following takes more resources?

A) GPU attempting to render a difficult frame, at the same time stressing to fill multiple queues which are being emptied faster then it can fill them, all while trying to present frames at correct times.

B) GPU only rendering the difficult frame while doing absolutely nothing else at the same time.
The queue is filled *by* the rendering. While the rendering is in progress, the queue is not being worked on. Except if you upload frames in a separate thread. You can disable that by checking the option "upload frames in render thread". That way the queue is absolutely idle while a frame is being rendered. The only exception, obviously, is the presentation. I once tried to present only after rendering a frame is done, in the same thread as the rendering. That didn't work well at all. Because max uploading times + max rendering times are sometimes simply too high to achieve smooth playback. The purpose of the queues is to smooth out the max times spikes.

What you seem to miss is that uploading + rendering + presenting are 3 things which can partially be done at the same time. If you force madVR to do them one after the other, what you achieve is worse performance, not better performance. Of course it's more stressful to try to do 3 things at once. But then if you actually manage to do 3 things at once, you're done with the task much sooner. If you do those 3 things one after the other, the stress is smaller, but it takes much more time overall.

Would you rather have GPU consumption at 10% instead of 50%, if that results in 5x higher rendering times?

That said, presentation and rendering sometimes fight with each other. But not in that way that GPU consumption is higher. They simply block each other sometimes, not letting the other do its job. So you could say that trying to present takes away time from the rendering. But then please make yourself clear that madVR is only trying to present, if a frame was already rendered completely. So if the try to present blocks further rendering, that's not good, but it's exactly what you're asking for. Without the queues madVR can't even start to render the next frames, until the presentation of the previous frame was completed. With the queues, madVR will start rendering sooner, giving the rendering more time. So once again I don't think that removing the queues will bring any benefit.

That said, could you also at an option for 0 queue size instead of 1 being the minimum?
Settings queues to 0 would mean that madVR can't render at all, because there's no place to store the rendering results, or even to upload frames to. Basically if you set queues to 1 and enable the option "upload frames in render thread" you will get exactly what you're asking for.

I can confirm this one (win7 32bit/aero off) - it's not a big deal and only seems to happen with ZP; to reproduce:
- play video in ZP and go fullscreen
- wait until mouse cursor is hidden
- now move the cursor;
- it will only show again after leaving rendered area

and regarding the XVID decoder - madVR shows 'unknown fps' for 'movie' section in the OSD when using it in the filter chain - but maybe it's just a cosmetical thing...
madVR does not really use the movie fps yet, so it's cosmetical right now.

[madshi]

Thanks again for helping out; I know it must have been annoying sifting through all of my posts, lol.
Actually I'm happy that the problem is (more or less) fixed. And working on it, I found fixes for some other incompatabilities, too. So overall I'm quite happy with the compatability improvements in v0.22.

[cyberbeing]

Would you rather have GPU consumption at 10% instead of 50%, if that results in 5x higher rendering times?

I hear what your saying, you are are likely correct that what I'm suggesting flat-out won't work at all, especially if you have already tested it yourself.

When it comes to the question above, I guess it's just wishful thinking on my part, that my GPU will somehow be fast enough to make it work, and somehow that will magically fix the problem since nothing else does. Once I see how horrible the results are first-hand, I'm sure I'll never bring up such crazy ideas ever again. :p

[iSunrise]

Some quick feedback for madVR 0.22.

I also had the "wrong" aspect ratio with the samples that Trigunflame posted. I solved it by just checking "allow output format changes during playback". Nothing else was changed. Thanks for the hint.

@cyberbeing:
Could you please post (or PM) a sample to reproduce, as I´m having absolutely no problem at all with a lot of bought blu-ray content (M2TS container and H.264 or VC-1) with madVR and an NVIDIA card. madVR is butter smooth on my end with my Geforce GTX260. I get no spiking at all. My stats always are below 0.12 ms for rendering and 0.25 ms for present with my scaling options and these are both extremely stable throughout the whole movie, no matter what content I throw at madVR.

Are you getting this behaviour with CoreAVC and ffdshow or just with CoreAVC? Are you playing the M2TS off of your HDD, directly from a blu-ray or over a LAN connection?

It is "possible" that avatar utilizes a lot of the theoretically available bitrate since their encoding team specifically wanted to create an amazing looking picture and that can only be achieved with very good encoding know-how and high bitrates on MPEG4 AVC (H.264).

From my experience, madVR only ever drops frames directly:

1) after the playback starts (1 or 2, which doesn´t really matter)
2) when going from windowed mode to fullscreen or going from fullscreen to windowed mode
3) when it doesn´t get fed the needed data from the decoder for whatever reason for a short amount of time

@madshi:
Is there a specific reason, why you´ve changed the OSD color to "extremely bright red" instead of the "mild red" color in 0.21? I find it a little annoying, to be honest.

[madshi]

@cyberbeing:
Could you please post (or PM) a sample to reproduce, as I´m having absolutely no problem at all with a lot of bought blu-ray content (M2TS container and H.264 or VC-1) with madVR and an NVIDIA card.
FWIW, the problem only occurs for cyberbeing when using a custom made 3dlut. He has posted samples earlier in this thread. One for Avatar and one for Evangelion. I think you can find them with a search.

@madshi:
Is there a specific reason, why you´ve changed the OSD color to "extremely bright red" instead of the "mild red" color in 0.21? I find it a little annoying, to be honest.
The OSD was half transparent in older madVR versions, which resulted in the mild red color. madVR 0.22 draws the OSD opaque. There's a very specific reason for this change, but the reason is secret for now... :p That said, it's no problem to change the font color...

[cyberbeing]

I PM'ed you those samples madshi, so they won't be found on the forums.

Sent you a PM iSunrise.

[iSunrise]

FWIW, the problem only occurs for cyberbeing when using a custom made 3dlut. He has posted samples earlier in this thread. One for Avatar and one for Evangelion. I think you can find them with a search.
Already did a search for the keyword "cyberbeing" for this thread and looked through every post, but could not find the link.

The OSD was half transparent in older madVR versions, which resulted in the mild red color. madVR 0.22 draws the OSD opaque. There's a very specific reason for this change, but the reason is secret for now... :p That said, it's no problem to change the font color...
Ok, that explains it, let´s not hope for more secrets then :D If it´s no problem to change the font color, I´m satisfied. Looking forward to your new ideas with madVR.

@cyberbeing:
Thanks for the PM!

1) I just played back your sample with various combinations of media players and decoders. I first used MPC-HC and PotPlayer, with ffdshow (ffmpeg-mt) and PotPlayer´s internal H.264 decoder (it´s a threaded ffmpeg-mt, like ffdshow) with my custom 3DLUT file and I could not see any spiking, skipping or dropped frames. I also tested with CoreAVC as the decoder both with and without CUDA acceleration. With both your sample worked flawlessy, no skipping or dropped frames.

2) I then switched my custom 3DLUT with your PMed 3DLUT and did the same as in 1). Same result, no dropped frames at all. I also tried both Haali and PotPlayers internal MKV splitter/filter and got no dropped frames. I can´t reproduce it with my config.

However, just by looking at the sample, I feel confirmed that there´s very high movement in that specific sample and this means that there must be a bottleneck somewhere in your config.

There must be something very specific in that decoding chain you are using that is responsible for the results you´re getting. It doesn´t seem to be graphics card related since you also had the problems with a GTX470, which is an extremely fast card.

Here´s a screenshot while playing the sample with PotPlayer and CoreAVC (with CUDA enabled):
http://www.abload.de/thumb/fullscreen_avatar_madv9ecd.png (http://www.abload.de/image.php?img=fullscreen_avatar_madv9ecd.png)

[cyberbeing]

Your GPU may already be fast enough to power through that section without dropped frames. The GTX 470 was also able to power through that section without dropped frames, but there was still a rendering time spike.

Since you are on Vista/Win7, please disable Aero, enable Flush and Wait for 'After Last Step' (so you can see the actual render times), set Chroma resampling to Spline64 (to make rendering time changes more obvious), and run through that section again watching for a render time spike when those orange spinning things appear on screen.

If you still see no change, I guess I really need to motivate myself to put this 7800GTX 512 in the Core i5-750 computer, and the ATI 5750 in my AMD X2 4800+ computer and re-test. There is always the possibility it is just some quirk with this particular AMD X2 computer. Yet, I could have swore I saw the same issue with the GTX 470 on the Core i5-750 computer, but I really can't remember all that well now.

[madshi]

Just to be safe: cyberbeing is talking about *max* rendering times. The average rendering times don't help much here, cause they're not affected that much by spikes.