madVR - high quality video renderer (GPU assisted)

[mark0077]

Does the renderer receive notifications of refresh rate changes, display changes that it could use to work when moved from one screen to another?

[Peuj]

Yes, I have MPC-HC set up to always run on my secondary...

How do you do this?
Thanks

[noee]

@Peuj:
1. MPC-HC has a command line switch "/monitor" (check the Help/Command Line), but this is not reliable, I've found
2. When you close MPC-HC on the secondary, the next time it's opened, it will start there by default.
3. I also have a script(AutoHotkey) which opens MPC-HC and sets the "X" position. My secondary is in "Extend Desktop Mode".
I guess you could use about any scripting language to do something like that...

; Run MPC, mode=1, run on primary, otherwise, run on secondary
MPC_Start(mode=1) {
global MPCPath

if (mode=1) {
mX := 80, mY := 50
}
else {
mX := 1950, mY := 50
}
DetectHiddenWindows On
IfWinNotExist ahk_class MediaPlayerClassicW
{
MPC_GetEnv()
Run, %MPCPath%,, Hide
WinWait, ahk_class MediaPlayerClassicW
}
WinRestore ahk_class MediaPlayerClassicW
WinMove, mX, mY
WinActivate
DetectHiddenWindows Off
Return
}

[fps]

Which splitter are you using? Does it only occur when using the MPC HC internal m2ts splitter? What happens if you use Haali's splitter? Or when you remux to MKV? My best guess right now is that it's a splitter problem, which some decoders and some renderers can work around.
Quite possible.
Thanks for the hint! It really is the internal MPCHC splitter (which I used before). With Haali the stuttering playback problem is gone.
Muxing it to mkv also solves the playback issue, works both with Haali's and MPCHC's internal splitter.

[Mark_A_W]

I'm getting a lot of delayed frames with v0.19.

When I first installed it they were chronic, one every second or so. Then they got a bit better (and reclock was resyncing - flashing red/green, for some strange reason).


Then it got better again over 5 minutes. Now I get one every now and again, compared to none with v0.18.


They seem CPU related in some way, although my CPU does not seem any more stressed than before in Task Manager (yes, I know it misses short peaks).

Reducing the CPU load by turning off digital room correction for the audio, and overclocking the PC, seems to help, but not fix it completely. With v0.18 I could run the room correction with the PC at stock speeds, no issues.


The other strange thing was after installing v0.19, the first time playback was a total stuttery mess. Then I noticed the madVR stats were cutoff. The video was zoomed past 100%, despite Zoom Player being in fullscreen. Picking fullscreen again fixed it, and playback became smooth (but with delayed frames). I rebooted just in case, but still get occasional delayed frames - one every minute or two.



Has anyone else noticed these issues?


(1) GPU: ATI 2600XT
(2) OS: Windows W7 x64
(3) Movies: 1080p mkv files, 23.976 fps (obtained from blurays with eac3to)
(4) Display resolution + refresh rate: 1920x1080, 95.904hz Interlaced with PowerStrip
(5) Dual monitor setup, playing on secondary, Aero OFF
(6) Zoom Player
(7) Video decoder: ffdshow (VC1: wmv9), CoreAVC
(8) madVR 0.19, all stock settings (except levels), 3DLUT off.
(9) Reclock, no V-sync

[LloydA]

Yes, same here. After approx. 1 minute playback starts to stutter and never recovers.

(1) GPU: ATI 5450
(2) OS: Windows 7 x64
(3) Movies: 1080p mkv files, 23.976 fps (obtained from blurays with eac3to)
(4) Display: 1920x1080, 60Hz
(5) Dual monitor setup, playing on primary, Aero off
(6) MPC-HC
(7) Video decoder: ffdshow (VC1: libavcodec), CoreAVC
(8) madVR 0.19, all stock settings, 3DLUT off
(9) Reclock (WASAPI), no V-Sync

[Peuj]

Thanks noee !!

I'll try it.

[janos666]

To be honest, I'm disappointed with the special Aero rendering path. I was hoping to get a much higher performance.

I tested it on my laptop and there is a slight performance increase. (It still can not handle anything but bilinear resize, but it is very close now. But bilinear is fine for a cheap TN display and TV shows...)

I don't really care about the performance (on my desktop PC). You are developing a renderer for quality enthusiasts. Where is the D3D Exclusive mode with DeepColor support? :D:o
(Ok, I do not have a 10 bit display anyway, yet. :) )

[Razoola]

I just wonder if anyone else is getting the same incorrect refresh rate problem as myself and noee in a multi monitor setup on the secondary monitor using the new test aero renderer path? At least I'm on nvidia drivers and noee is on ati so we know its not some gpu maker driver issue.

On the other side however when I run MPC-HC with the win7 compatability setting 'disable desktop composition' (no aero) and not use the madvr test aero renderer path I'm getting 100% perfect playback. This is with the default flush settings and reclock with its vsync options disabled. In windowed mode I get no stuttering or tearing, in fullscreen on either primary or secondary monitor I also get no stuttering or tearing. From this respect madVR is working 100%, its just aero that kills it for me.

[Hypernova]

I just wonder if anyone else is getting the same incorrect refresh rate problem as myself and noee in a multi monitor setup on the secondary monitor using the new test aero renderer path? At least I'm on nvidia drivers and noee is on ati so we know its not some gpu maker driver issue.

On the other side however when I run MPC-HC with the win7 compatability setting 'disable desktop composition' (no aero) and not use the madvr test aero renderer path I'm getting 100% perfect playback. This is with the default flush settings and reclock with its vsync options disabled. In windowed mode I get no stuttering or tearing, in fullscreen on either primary or secondary monitor I also get no stuttering or tearing. From this respect madVR is working 100%, its just aero that kills it for me.

I do. I get a bad tearing when Aero off though, so that's not an option for me. I somehow found a workaround for at least my setup, as I described in my post from last page. You might wanna check it out.

[leeperry]

watcha! the 257.21 WHQL nvidia drivers are just so amazingly smooth on XP SP3 w/ 0.19...I'm currently trying "Dragon Hunters" in 96Hz, digital cartoons take a whole new meaning w/ mVR+Reclockhttp://forum-images.hardware.fr/images/perso/kornichon.gif

BTW, I've had some judder once after 15 mins...but I think it was my fault tbh, as one of my VST plugins GUI showed up right before I went FS....and I didn't succeed to reproduce the issue.

And I just tried W7 x86, I'm really not impressed...terrible GUI, WASAPI doesn't do anything ASIO4ALL/KS can't do, Aero is just more bloat between your files and your display...XP SP3 just "works", hah.

[iromeoi]

I've been using MadVR v0.14 for months with no real issues (besides some tearing) with KMplayer and MPC-HC.

After trying to upgrade to version v0.18 of madVR, every player set to use madVR freezes with a black screen(sometimes audio -- but always freezes) (normally shows movie duration) and hangs indefinately.

I tried to roll back to version to all versions (0.17-.09) and ONLY v0.09 will load video now.

Assuming some file/setting on my system had become corrupted, I did a FRESH WINDOWS XP SP3 install. I installed nothing but my motherboard drivers(audio/etc), ATI 10.5 video drivers, and madVR+MPC-HC...and **still* no version but 0.9 will load video even on this fresh install.

I can't imagine how anything could survive a hard drive wipe and continue influencing this. It's driving me mad only because it makes no sense. I *must* be missing something.

Trying to use the debug version crashes also while generating no log file.

I'm using Windows XP SP3, all hotfixes, ATI Catalyst 10.5, and an ATI HD3850. Note, I was experiencing this issue with ATI Catalyst 9.11 (previous to upgrading 10.5 -- I upgraded to 10.5 trying to solve the issue and still have the problem).

Please help!

[Razoola]

I do. I get a bad tearing when Aero off though, so that's not an option for me. I somehow found a workaround for at least my setup, as I described in my post from last page. You might wanna check it out.

Your solution does not work for me, the non smooth playback is still there.

[starla]

(4) there's no proper way to empty the queues, which results in artifacts when using trick play


PresentEx(NULL, NULL, NULL, NULL, D3DPRESENT_FORCEIMMEDIATE);

Shouldn't that allow you to discard the already queued samples?

http://msdn.microsoft.com/en-us/library/ee890072%28VS.85%29.aspx

[leeperry]

OK I've had some dropped frames right after 45 mins again, I can't really afford to let the logging run for so long on my C: drive...so I'm not sure how I could give clues :o

[Trigunflame]

The new Aero rendering path seems to drop a lot of frames, specifically if another window covers any part of the playing video (perhaps this is expected?).

(Aero: Enabled, Aero Rendering Path: Disabled)
http://a.imagehost.org/0041/1_114.png

(Aero: Enabled, Aero Rendering Path: Enabled)
http://a.imagehost.org/0536/2_28.png

OS: Win7 x64 ultimate
Aero: Enabled
CPU: i7 920 @ 3.8ghz
GPU: 8800gts 640mb g80 x2 (SLI)
Drivers: NV 257.21
Resolution/Refresh Rate: 1680x1050 59/60hz
Player: MPC-HC svn (r2018)
Codec: CoreAVC 2.0
Splitters/Filters: Internal MPC-HC MP4/MOV Splitter > CoreAVC2 > DirectVobSub > FFDSHOW audio > MADVR > DirectSound

[SpaceAgeHero]

Hey folks and hey madshi,

just a quick question. Is 1080i50 material not supported?
I can get no output when trying to play such a stream with madvr.
(1: VC-1, English, 1080i50 (16:9))

Thanks!

[namaiki]

Hey folks and hey madshi,

just a quick question. Is 1080i50 material not supported?
I can get no output when trying to play such a stream with madvr.
(1: VC-1, English, 1080i50 (16:9))

Thanks!

Try use Haali Media Splitter if you are not already. Also, please post a <40MB sample if you can.

[mark0077]

Madshi, Windows 7 64bit, GTX 295, Core i7. I have yet to really compare aero path vs non aero path. Present times falls to almost 0.5ms with aero path enabled :O Compared to something in the 20ms area with it off.

A huge problem though, with aero path on, the display and composition rate are incorrect. It should be 23.97~ but with aero path on it says display 47.92375, composition rate 50.0 hz. I have reclock changing refresh rate using vbs script on load event.

Perhaps this is driving the aero path crazy.......

[starla]

Madshi, Windows 7 64bit, GTX 295, Core i7. I have yet to really compare aero path vs non aero path. Present times falls to almost 0.5ms with aero path enabled :O Compared to something in the 20ms area with it off.

My guess is that EARO frame queue is causing this behavior. Present() calls aren't blocked until the frame is drawn and that is why it looks like it would be almost instantly to draw a frame.


A huge problem though, with aero path on, the display and composition rate are incorrect. It should be 23.97~ but with aero path on it says display 47.92375, composition rate 50.0 hz. I have reclock changing refresh rate using vbs script on load event.

AERO / DirectX won't currently manage the on-the-fly refresh rate changes within application life cycle. This was spotted with MediaPortal development. In my opinion this is a bug that MS should fix. As a work application can re-create the DirectX device when the refresh rate is changed. I think this was working "solution".

[mark0077]

But I know that reclock is able to hook in, to listen for changes to refresh rate, so perhaps the renderer should do this also?

[Mark_A_W]

I'm getting a lot of delayed frames with v0.19.

When I first installed it they were chronic, one every second or so. Then they got a bit better (and reclock was resyncing - flashing red/green, for some strange reason).


Then it got better again over 5 minutes. Now I get one every now and again, compared to none with v0.18.


They seem CPU related in some way, although my CPU does not seem any more stressed than before in Task Manager (yes, I know it misses short peaks).

Reducing the CPU load by turning off digital room correction for the audio, and overclocking the PC, seems to help, but not fix it completely. With v0.18 I could run the room correction with the PC at stock speeds, no issues.


The other strange thing was after installing v0.19, the first time playback was a total stuttery mess. Then I noticed the madVR stats were cutoff. The video was zoomed past 100%, despite Zoom Player being in fullscreen. Picking fullscreen again fixed it, and playback became smooth (but with delayed frames). I rebooted just in case, but still get occasional delayed frames - one every minute or two.



Has anyone else noticed these issues?


(1) GPU: ATI 2600XT
(2) OS: Windows W7 x64
(3) Movies: 1080p mkv files, 23.976 fps (obtained from blurays with eac3to)
(4) Display resolution + refresh rate: 1920x1080, 95.904hz Interlaced with PowerStrip
(5) Dual monitor setup, playing on secondary, Aero OFF
(6) Zoom Player
(7) Video decoder: ffdshow (VC1: wmv9), CoreAVC
(8) madVR 0.19, all stock settings (except levels), 3DLUT off.
(9) Reclock, no V-sync



madshi, I went back to v0.18 and all was well again, my delayed frame number does not constantly increase.

So for me, either v0.19 is broken, or 0.18 wasn't reporting the delayed frames :)

And remember, I'm using 96hz, Aero off. From the notes, you tweaked for high refresh rates using windowed playback...that's me.

Thanks

Mark

[madshi]

If I do what you suggest the display rate is correct but the aero rate is reported at 60hz.

I have taken it one step further and done the above test again after first changing the primary refresh rate from 120hz to 100hz. Again the display rate is correct but the aero rate is reported at 100hz.
With primary at 60Hz and secondary at 24Hz (playback on secondary), I get a the typical nasty juddering Check out the stats and the queues and note the wrong detection of refresh rate (reclock reports it properly at 24Hz)
I have the same wrong detection of refresh rate as noee said. I made sure MPC-HC is fullscreen on the secondary monitor before open the file.
A huge problem though, with aero path on, the display and composition rate are incorrect. It should be 23.97~ but with aero path on it says display 47.92375, composition rate 50.0 hz. I have reclock changing refresh rate using vbs script on load event.
AERO / DirectX won't currently manage the on-the-fly refresh rate changes within application life cycle.
Hmmmm... So we have 3 issues with Aero:

(1) On 2 monitor setups, the composition rate is often chosen in such a way that playback on secondary monitor has motion judder.

(2) On 2 monitor setups, even the refresh rate information for the secondary monitor is sometimes wrong.

(3) If refresh rate is modified while Aero/DirectX is already running, Aero/DirectX won't notice/adapt.

That's really bad. I'd say that for 2 monitor setups Aero seems to be pretty much useless. But how about single monitor setups? Does anybody, who is using Aero with a single monitor setup, have problems with incorrect refresh rate or composition rate detection, when using madVR's new Aero rendering path?

Does the renderer receive notifications of refresh rate changes, display changes that it could use to work when moved from one screen to another?
Such notifications exist, but madVR doesn't really make use of it. Well, a change in refresh rate should be noticed by madVR (at least when not using Aero), but a move to another monitor during playback is currently ignored by madVR.

Yes, same here. After approx. 1 minute playback starts to stutter and never recovers.

(5) Dual monitor setup, playing on primary, Aero off
Is that stutter after 1 minute playback with Aero off? Is that problem new with v0.19 and doesn't occur with v0.18?

After trying to upgrade to version v0.18 of madVR, every player set to use madVR freezes with a black screen(sometimes audio -- but always freezes) (normally shows movie duration) and hangs indefinately.
Weird. Please upload a madVR log for me.

And please make sure that you try different videos, different splitters and different decoders. Such problems can be caused by any of them (or madVR itself).

PresentEx(NULL, NULL, NULL, NULL, D3DPRESENT_FORCEIMMEDIATE);

Shouldn't that allow you to discard the already queued samples?
Yes, that's exactly what FORCEIMMEDIATE was made for. There are a number of problems with it, though:

(1) It only works in combination with D3DSWAPEFFECT_FLIPEX, which is only supported in Windows 7 and not in Vista. So basically, if madVR's Aero rendering path wants to support Vista, there's no way to empty the queue.

(2) I've played with D3DSWAPEFFECT_FLIPEX and it generally seems to work, but if you use it, some (most?) of the DWM APIs like e.g. "DwmGetCompositionTimingInfo" don't work as intended, anymore. E.g. if you use FLIPEX, the DWM timing information always claims that the Aero queue is empty. So seemingly FLIPEX doesn't use the DWM queue, but uses its own queue somehow. Which means that I can't use the DWM APIs, anymore, but I have to totally switch to FLIPEX logic by using "GetPresentStatistics" etc instead. And the FLIPEX logic is quite different from the DWM logic. So basically it's not as easy as using DWM in Vista and FLIPEX in Windows 7. I'd have to write 2 totally different render paths, one for DWM and one for FLIPEX. For now I've only implemented a DWM one, because it should work in both Vista and Windows 7. But when using DWM, there's no way to empty the queues.

OK I've had some dropped frames right after 45 mins again, I can't really afford to let the logging run for so long on my C: drive...so I'm not sure how I could give clues :o
Argh, too bad. Can you reproduce this on your win7 machine, too? Then you could create a symlink to redirect the log file to another drive (mklink "c:\yourDesktopPath\madVR - log.txt" "d:\redirectedLog.txt"). In XP this doesn't work.

The new Aero rendering path seems to drop a lot of frames, specifically if another window covers any part of the playing video (perhaps this is expected?).
How does the new rendering path compare subjectively to not using the new rendering path? Do you think it's better or worse? Dropped frames in the statistic are not nice, but it doesn't really matter so much what the stats say if another window covers a part of the playing video! What's more important is if you notice any non-smooth motion when nothing is covering the video.

just a quick question. Is 1080i50 material not supported?
I can get no output when trying to play such a stream with madvr.
(1: VC-1, English, 1080i50 (16:9))
It seems that in Windows 7, the MS VC-1 and WMV decoder currently doesn't want to play nice with madVR. Don't know why yet. Generally interlaced content should work fine with madVR. However, I'd strongly recommend to deinterlace it before feeding it to madVR, because madVR does not deinterlace itself.

A huge problem though, with aero path on, the display and composition rate are incorrect. It should be 23.97~ but with aero path on it says display 47.92375, composition rate 50.0 hz. I have reclock changing refresh rate using vbs script on load event.
Single or 2 monitor setup? On a single monitor setup, the refresh and composition rate should be correct (at least if you don't change it during playback). Maybe it's not 24Hz, but 48Hz interlaced?

My guess is that EARO frame queue is causing this behavior. Present() calls aren't blocked until the frame is drawn and that is why it looks like it would be almost instantly to draw a frame.
I wish Present() calls would really not block. My logs tell me a different story, though. I've told Aero to use a 8 frame queue, but according to my logs, Present() calls are still often blocking, long before the queue is filled. At least on my PC... :(

But I know that reclock is able to hook in, to listen for changes to refresh rate, so perhaps the renderer should do this also?
madVR reports the refresh rate correctly, if you don't use the new Aero rendering path, doesn't it? With the new rendering path, madVR stops trying to figure the refresh rate itself, but instead relies on Aero. Seems that this is a bad idea... :mad:

madshi, I went back to v0.18 and all was well again, my delayed frame number does not constantly increase.

So for me, either v0.19 is broken, or 0.18 wasn't reporting the delayed frames :)

And remember, I'm using 96hz, Aero off. From the notes, you tweaked for high refresh rates using windowed playback...that's me.
That's a pity. I'm not sure which change is reponsible for the problem, though. Could be either the timing change or the increased backbuffer size (8 instead of 3). I'll revert the timing change for the next build, then we'll know for sure.

[mark0077]

I'm using one monitor madshi. Yeah when switching refresh rate with aero path enabled, madvr doesn't realize I'm no longer at 50hz, but at 24~hz. So either madvr should not rely on the graphics card / aero here to get the refresh rate, or a bug report should be sent out to whoever is responsible for the problem. Nvidia or microsoft perhaps?

Another example of not putting trust in anything but your own code I suppose, in this case relying on microsoft / nvidia to send updates of refresh to you renderer isn't a good idea.

Also, is the present time stat accurate enough to be used in the gui. As you see my present time jumps to 0.5~ms with aero path enabled. starla says My guess is that EARO frame queue is causing this behavior. Present() calls aren't blocked until the frame is drawn and that is why it looks like it would be almost instantly to draw a frame.

[Razoola]

Hmmmm... So we have 3 issues with Aero:

(1) On 2 monitor setups, the composition rate is often chosen in such a way that playback on secondary monitor has motion judder.

(2) On 2 monitor setups, even the refresh rate information for the secondary monitor is sometimes wrong.

(3) If refresh rate is modified while Aero/DirectX is already running, Aero/DirectX won't notice/adapt.

That's really bad. I'd say that for 2 monitor setups Aero seems to be pretty much useless. But how about single monitor setups?

Yup thats it.

I think in a dual monitor setup your ok with AERO providing your playing back on the primary display only, there can be tearing issues however. Most people with duel monitor have the primary set to a PC monitor and the secondary set to either HDTV or projector so they want playback on the secondary.

Fo me at least AERO is fine providing the secondary monitor is disabled. Maybe its possible to have something in madVR which can detect a dual monitor configuration against a single monitor and maybe somehow optimise itsself for each case?? Just what you would do in each case I don't know however.

I feel that from your prospective and what you have already mentioned about AERO limitation with queues etc that maybe it would be better to give up on AERO and see what you can do with exclusive mode :) I think many people with single or dual monitors at least will use exclusive mode over anything else.

[LloydA]

Is that stutter after 1 minute playback with Aero off? Is that problem new with v0.19 and doesn't occur with v0.18?

Yes, Aero off. And yes, I didn't experience it with 0.18 or any version before.

[madshi]

I'm using one monitor madshi. Yeah when switching refresh rate with aero path enabled, madvr doesn't realize I'm no longer at 50hz, but at 24~hz. So either madvr should not rely on the graphics card / aero here to get the refresh rate, or a bug report should be sent out to whoever is responsible for the problem. Nvidia or microsoft perhaps?
That would be Microsoft. Unfortunately I don't have much hope to get this fixed by MS.

Also, is the present time stat accurate enough to be used in the gui. As you see my present time jumps to 0.5~ms with aero path enabled.
I don't know for sure. More important, anyway, is how movie playback works for you in real time. Sometimes I'm tempted to remove the stats from the OSD again, because I think some people judge too much by looking at stats, and not enough by trusting their eyes.

Yes, Aero off. And yes, I didn't experience it with 0.18 or any version before.
Ok, thanks. Please try again with 0.20, once it's out (not yet, maybe not this weekend, not sure) and let me know if the problem is gone.

I feel that from your prospective and what you have already mentioned about AERO limitation with queues etc that maybe it would be better to give up on AERO and see what you can do with exclusive mode :) I think many people with single or dual monitors at least will use exclusive mode over anything else.
Everyone: I'm still hoping for more feedback from people about the new Aero rendering path.

Most feedback I received was from people with multi monitor setups. We already knew before that Aero doesn't work well in that situation. But how does the new rendering path work for single monitor users? I want/need to know if it's any good. If it isn't a noticeable improvement, then I'll likely trash it, to make configuration easier...

[mark0077]

All looks perfectly smooth to me :) I shall be using non aero path because of incorrect detection of display rate in aero path. I assume that stat being incorrect does indicate skips will happen as madvr doesn't know the correct display rate..... Let me know if I can run any more tests with GTX 295.

[evantreborn]

Hi madshi~I got a very weird glitch and crash situation when playing 1080p x264@vc1 mkv files with madVR from 0.13 to 0.19 (0.12 for my HTPC was absolutely glith and crash free, nearly perfect,
only with some frame drop&delay problems, ). I can play them smoothly and perfectly for a while, around 10-20 minutes, and then glitches may show, and crash happens and I have to restart my HTPC, I've tried all I could to avoid this, os settings, mpchc&ffdshow latest and older versions, try different madvr settings, even after reinstalling the OS the problem was still there. I am well aware that 99% people here don't have this weird problem with latest madVR, so I'm open to all suggestions and willing to try all the possible ways:)

My current HTPC:
CPU:AMD635 X4@2.9G GPU:ATI HD5670(512m)@catalyst 10.5
OS: win7 32bit, Aero on, 1920x1080@23hz
MPCHC&FFDshow latest, ffmpeg-mt for AVC, wmv9 for VC1, Bitstreams dtshd&truehd audios
madVR 0.19 default settings
single plasma TV

What i'm crazy to find out is that why madVR 0.12 could run with zero glitch and crash while since version 0.13, even the latest 0.19, glitch and crash always happen on my HTPC. It makes no sense that the changes and improvements after 0.12 lead to such a big problem. It's no doubt that latest madVR works fine for most people here, at least without problems serious like glitch and crash, so what's wrong with my PC, I've tried all the possible changes even reinstall a pure win7 32, but nothing works, is there any significant change I could make to solve this problem? Thanks~:)

[mark0077]

Hi evantreborn, just a guess but when I hear about crashes / problems after X minutes, with any piece of software I always have to suggest checking temperatures.....

I had a problem with GTA 4 game for months, after 15 mins or so, only to realize my gpu was throttling back to keep itself cool with the stress it was getting.... Worth checking if 0.13 is stressing your machine out more than older versions...

Long shot though.

[evantreborn]

Thanks for your kind advice mark0077:) You made a good point that it may be the hardware pieces that produce this problem.
Actually I have checked the temps a lot, nothing unusual, the highest part GPU is below 52'c when playing AVATAR bluray remux with madVR.
Anyway I'm quite lost, I just hope it would be just not that complicated:p

[Razoola]

Everyone: I'm still hoping for more feedback from people about the new Aero rendering path.

Most feedback I received was from people with multi monitor setups. We already knew before that Aero doesn't work well in that situation. But how does the new rendering path work for single monitor users? I want/need to know if it's any good. If it isn't a noticeable improvement, then I'll likely trash it, to make configuration easier...

I disabled my second monitor to do some testing just for you :)

To be totally honest I don't see any difference with or without the aero renderer path. This is gong off visual appearence only and not stats. Like mark0077 I have a gtx295 so the card can handle the workload. The OSD reported some frame drop / repeats when the aero path was enabled but I did not see them during playback (maybe happened on non panning scenes). I got no drops or repeats when the aero path was disabled.

[Razoola]

Thanks for your kind advice mark0077:) You made a good point that it may be the hardware pieces that produce this problem.
Actually I have checked the temps a lot, nothing unusual, the highest part GPU is below 52'c when playing AVATAR bluray remux with madVR.
Anyway I'm quite lost, I just hope it would be just not that complicated:p

I would suggest if its not tempreture then test your system memory and gpu menory. There are freeware programs that can do this. I would advise overnight tests of both. A good few hours of prime95 at maximum stress might be a good idea also.

If you are using reclock then please do some tests without it to see if the crash stops (I know you may not get smooth playback but its just to see if the crash stops). I personally have had some trouble with system lockups with it in the past due to the resampler code it uses in newer versions. Since then I always use bitstreaming only with it or go back to a version with the old resampler (1.8.5.8 is the last version with it).

[leeperry]

Argh, too bad. Can you reproduce this on your win7 machine, too? Then you could create a symlink to redirect the log file to another drive
Sorry, I quickly gave up on W7...Many of my devices lack drivers and my XP box works like a charm w/ 0.18, maybe the culprit is 0.19 somehow? I run my tests in 23.976fps@96Hz...I tried many movies in 0.18 and never got any judder after 45 mins. Also, why 45 mins?! One of the mysteries of computing I guess...I've been plagued w/ that problem since forever, and many other ppl get this problem in windowed mode on XP+Reclock as well.

Maybe you could just put the logfile in the same dir as madvr.ax? It'd be more convenient IMHO.

[mark0077]

Leeperry. Just wondering is 45 mins an indication of something. I did a bit of calculating and notice 45 x 60 seconds =2700 seconds. 96 / 2700 = 0.03555556

Could the difference between 23.976 and 24 (~0.03) adding up over 45 minutes. And only then causing the renderer to catch up so to speak. Causing the niggles your seeing after that happens. Just trying to see what combination of periods of time could suggest something around 45 mins.

[evantreborn]

I would suggest if its not tempreture then test your system memory and gpu menory. There are freeware programs that can do this. I would advise overnight tests of both. A good few hours of prime95 at maximum stress might be a good idea also.

If you are using reclock then please do some tests without it to see if the crash stops (I know you may not get smooth playback but its just to see if the crash stops). I personally have had some trouble with system lockups with it in the past due to the resampler code it uses in newer versions. Since then I always use bitstreaming only with it or go back to a version with the old resampler (1.8.5.8 is the last version with it).
I used to use reclock on another PC, but it sometimes caused some crashes so I gave it up(I wasn't using madVR then), and I don't think I'll need reclock again.

When it comes to GPU memory, I have long been wondering if the Powerplay of ATI HD series would have anything to do with the glitch and crash problem in my situation? ATI users here are you doing fine with latest madVR with powerplay activated?

[janos666]

Sometimes I have some random V-sync problem and I have to restart the player to solve it. It happens since I use v0.14 and later versions (currently v0.19).
I am using the new Aero patch now but this is not a new problem. It existed before the new renderpatch and flush options. (But I didn't checked the OSD earlier...)

Today I hit ctrl+j when it happened and it showed me that my display is clocked to 72Hz while composition rate was 60Hz and my LCD worked at 60Hz (~59.9 Hz as reported by the display's OSD. It can't work at 72Hz.)
I restarted the player and left the OSD activated. The display clock is slowly but continuously increased during the playback. It was correct when I started the movie (23.976 fps Blu-Ray) but it is 65,20 Hz after ~10 minutes.
I restarted the player again and I could finish the movie without V-sync problem, the displayed value was constant 59.95Hz now. (So, it is random.)

[nlnl]

Mpc HC (Haali mkv splitter, CoreAVC, WMVideo Decoder DMO) + ATI 5400 (10.6) + Vista 32 + Aero on + 0.19 + monitor input 1080p@23, 24, 50 (single)

Aero path is slightly worse for my config. Madvr is loosing more frames when player switches audio tracks and seeks.

And I notice that Reclock and Madvr are not good friends :). Reclock is sometimes the reason of delayed and dropped frames!
Default Direct Sound device output (for HDMI) is better.

[iSunrise]

Thanks madshi for 0.19.

Since you specifically requested it, I did some rather extensive tests on my single monitor setup with 0.19 and aero mode. According to my results, your windowed mode already is close to perfect. Aero mode introduced in 0.19 is a completely different story, though.

That's really bad. I'd say that for 2 monitor setups Aero seems to be pretty much useless. But how about single monitor setups? Does anybody, who is using Aero with a single monitor setup, have problems with incorrect refresh rate or composition rate detection, when using madVR's new Aero rendering path?
I did some tests with various display refresh rates using powerstrip to check this and from what the madVR OSD shows I can definately say that there´s something wrong.

Using Aero mode:

madVR always reports a display refresh rate 2 times higher than my actual display refresh if the actual display refresh is <=30Hz. Example: If I play a 24fps movie at a 24.024Hz display refresh, madVR reports my display refresh to be 48.4xxHz-48.6xxHz (and it´s constantly adjusting like crazy). Also the vsync interval changes constantly, too. When my display refresh is set to 29.975Hz and I play a 29.970fps movie, same thing. The madVR OSD shows a display refresh of 58.xxxHz. The composition rate shown by the OSD is always at 60.000Hz, too. Also, Aero mode drops frames a lot when the reported display refresh by the OSD is not a multiple of the movie´s fps.

Using windowed mode:

Windowed mode always reports my display refresh correct, no matter what I set it to. It is always where it should be (where I set it with powerstrip). What is strange, though, is that the composition rate also stays at 60.000Hz (like with Aero mode) all the time, no matter the content or my actual display refresh. However, this doesn´t seem to be a problem at all, since the end result is _always_ smooth playback without any single hiccup I can detect. 24fps at 24.024Hz works like a charm, 29.970fps at 29.975Hz and so on. No stutters. It looks like in windowed mode, the composition rate doesn´t matter when looking at the end result. I´m not sure what to make of this.

madVR reports the refresh rate correctly, if you don't use the new Aero rendering path, doesn't it? With the new rendering path, madVR stops trying to figure the refresh rate itself, but instead relies on Aero. Seems that this is a bad idea... :mad:
From what I can tell after these tests, your refresh rate detection algorithm in windowed mode is extremely stable and reliable. It is always showing me what I set with powerstrip. I have not yet seen it fail once on my setup.

Specs:
(1) Geforce GTX 260-216 [Nvidia Quadro 258.49 WHQL]
(2) Windows Vista x64
(3) Aero on
(4) 1920x1200@59.940Hz (normal use)
(5) PotPlayer, KMPlayer or MPC-HC
(6) ffdshow video and audio decoder
(7) Haali Media splitter

madVR settings:
(1) Use 3DLUT
(2) Bicubic75, Spline64, Bicubic75
(3) No other options ticked
(4) don´t flush for everything

[mark0077]

Hi madshi, is the macrovision errors with dvd's anywhere near high on your priority list. Just showing off HTPC to an old friend today, and launched a backed up DVD through XMBC -> External Player -> MPC-HC, but of course it just gave black screen with madVR..... I was like..... bust have been a bad disk.... :P

[THX-UltraII]

what are the benefits of using madVR as DirectShowVideo instead of EVR Custom?

[Thunderbolt8]

better PQ :p

[madshi]

All looks perfectly smooth to me :) I shall be using non aero path because of incorrect detection of display rate in aero path. I assume that stat being incorrect does indicate skips will happen as madvr doesn't know the correct display rate.....
Yeah, if the display rate is shown incorrectly, that cries for problems.

I got a very weird glitch and crash situation when playing 1080p x264@vc1 mkv files with madVR from 0.13 to 0.19 (0.12 for my HTPC was absolutely glith and crash free, nearly perfect,
only with some frame drop&delay problems, ). I can play them smoothly and perfectly for a while, around 10-20 minutes, and then glitches may show, and crash happens and I have to restart my HTPC, I've tried all I could to avoid this, os settings, mpchc&ffdshow latest and older versions, try different madvr settings, even after reinstalling the OS the problem was still there.
Don't really know what to say. You seem to be the only one having this specific problem, so I agree with the others that this *might* be hardware related. You could try to update the BIOS on your GPU. Also try the latest drivers. And try what the others suggested.

I disabled my second monitor to do some testing just for you :)
Thanks... :)

To be totally honest I don't see any difference with or without the aero renderer path. This is gong off visual appearence only and not stats. Like mark0077 I have a gtx295 so the card can handle the workload. The OSD reported some frame drop / repeats when the aero path was enabled but I did not see them during playback (maybe happened on non panning scenes). I got no drops or repeats when the aero path was disabled.
Ok, thanks.

Sometimes I have some random V-sync problem and I have to restart the player to solve it. It happens since I use v0.14 and later versions (currently v0.19).
I am using the new Aero patch now but this is not a new problem. It existed before the new renderpatch and flush options. (But I didn't checked the OSD earlier...)

Today I hit ctrl+j when it happened and it showed me that my display is clocked to 72Hz while composition rate was 60Hz and my LCD worked at 60Hz (~59.9 Hz as reported by the display's OSD. It can't work at 72Hz.)
I restarted the player and left the OSD activated. The display clock is slowly but continuously increased during the playback. It was correct when I started the movie (23.976 fps Blu-Ray) but it is 65,20 Hz after ~10 minutes.
That's weird. That's with the new Aero rendering path enabled? How does the OSD behave with it disabled?

Aero path is slightly worse for my config. Madvr is loosing more frames when player switches audio tracks and seeks.
Thanks for the feedback.

Since you specifically requested it, I did some rather extensive tests on my single monitor setup with 0.19 and aero mode. According to my results, your windowed mode already is close to perfect. Aero mode introduced in 0.19 is a completely different story, though.

I did some tests with various display refresh rates using powerstrip to check this and from what the madVR OSD shows I can definately say that there´s something wrong.

Using Aero mode:

madVR always reports a display refresh rate 2 times higher than my actual display refresh if the actual display refresh is <=30Hz. Example: If I play a 24fps movie at a 24.024Hz display refresh, madVR reports my display refresh to be 48.4xxHz-48.6xxHz (and it´s constantly adjusting like crazy). Also the vsync interval changes constantly, too. When my display refresh is set to 29.975Hz and I play a 29.970fps movie, same thing. The madVR OSD shows a display refresh of 58.xxxHz. The composition rate shown by the OSD is always at 60.000Hz, too. Also, Aero mode drops frames a lot when the reported display refresh by the OSD is not a multiple of the movie´s fps.
Thanks for the testing and feedback. That's really weird. On my NVidia 9400 integrated GPU on win7 x64, when I set graphics mode to 23.976 output then both display refresh rate and Aero composition rate are shown as 23.976, and I get smooth playback. I'm really confused why so many of you guys have so weird results.

But anyway, I think I got enough feedback now. It seems that the new Aero rendering path doesn't work as well as I hoped, or even any better than the normal windowed rendering path. So I'll simply drop it again.

Hi madshi, is the macrovision errors with dvd's anywhere near high on your priority list.
It's one of many things high on my priority list. I don't like to work on many fronts at the same time, though, and right now I'm concentrated on finally nailing windowed and Aero rendering modes. Once that's done, I can move on to the next thing (not sure which yet).

what are the benefits of using madVR as DirectShowVideo instead of EVR Custom?
There are some benefits and (with the current madVR version) some disadvantages. So you will have to decide for yourself whether the benefits or disadvantages are bigger for you:

benefits:
+ highest quality chroma upsampling
+ highest quality scaling
+ highest quality color space conversion
+ full 16bit rendering path, with dithering
+ full control over PC vs. video levels, BTB/WTW is never cut off by GPU drivers
+ quality is independent of OS, driver version and even GPU
+ very smooth motion playback (provided your PC/GPU is powerful enough)
+ can do gamma and gamut correction (in combination with yCMS)

disadvantages:
- needs a fairly powerful GPU
- currently doesn't support DXVA hardware video decoding
- currently doesn't support hardware deinterlacing
- currently doesn't support hardware noise reduction
- currently doesn't support hardware detail enhancement
- doesn't have a subtitle input pin, yet (subtitles work with DirectVobSub, though)
- currently can't playback DVD menus etc on newer OSs
- currently isn't supported by PowerDVD, ArcSoft etc
- may still have some compatability problems with some videos or decoders

Some of the disadvantages may vanish sooner or later...

[madshi]

madVR v0.20 released

http://madshi.net/madVR.zip

* fixed: Microsoft VC-1/WMV decoder didn't start playing in Windows 7
* got rid of special Aero rendering mode (didn't work as well as expected)
* added 4 new tweak options
* you can now put an empty log file in madVR's folder to overwrite the log path
Please play with the new tweak options and report back which options work best for you in which situation.

Please note:

(1) You need to restart the video player for the options "upload video frames in render thread" and "no of backbuffers" to show effect. The other two options get effective immediately.

(2) I've named the 3 different timing modes with their original purpose. I'm not 100% sure, though, whether the description is really accurate. E.g. I've found that the timing mode named "aero" also works really well on my fixed refresh rate 60Hz LCD in XPSP3. I rather doubt that it will work well in non-aero mode when using a low refresh rate, though. But I'm not really sure. Just give it a try...

(3) It's possible that the new tweaks influence which flush settings are best. So you may want to revisit the flush settings, too.

[cyberbeing]

You got rid of the special rendering mode already? I was too busy to make a post the last few days, but through the little testing I did with madVR 0.19 on Win7, the special Aero rendering mode was an improvement. It seemed to eliminate the massive stutters which I was getting in madVR 0.18. Guess that means using madVR with Aero is once again unwatchable until you think up of something better. Yet this isn't really a big deal for me since WinXP is still my primary OS for the time being, and madVR was working well with Aero disabled on Win7. (I have yet to test madVR 0.20)

[madshi]

You got rid of the special rendering mode already? I was too busy to make a post the last few days, but through the little testing I did with madVR 0.19 on Win7, the special Aero rendering mode was an improvement. It seemed to eliminate the massive stutters which I was getting in madVR 0.18. Guess that means using madVR with Aero is once again unwatchable until you think up of something better.
Well, I didn't really receive *any* feedback which said that the new rendering mode was a noticeable improvement. So why should I have kept it? Your feedback is too late... :p

But don't worry. With 0.19 on win7, the special Aero rendering mode was (ever so) slightly better for me, too. But with the new tweaks in 0.20, I compared and got best results without the special Aero rendering mode - better than 0.19 with the special Aero rendering mode. Just give it a try for yourself. If all else fails I can reintroduce the special rendering mode again. The code is still there, it's just not used in 0.20.

The new tweaks might also help with your high refresh rate XPSP3 windowed playback, btw.

[cyberbeing]

For reference, which of these new options did previous versions of madVR already use in some fashion?

Upload frames in render thread?
Copy only 1 backbuffer at a time?
Timing model? (Is the only new one Aero mode? Wasn't the High-refresh mode already in 0.19?)
Number of backbuffers? (Backbuffer queue in the stats doesn't change from 3, so is this something different?)

I'm back to using my 7800GTX 512 once again on my AMD X2 4800+ computer. The GTX 470 got returned yesterday. On Monday I will have a secondary Core i5-750, ATI 5750, Win7 computer which I'll also be able to test.

[pirlouy]

I think there's an option which does not work: number of backbuffers. It seems not to apply settings.

For my tearing problem: there's still tearing, but I've noticed something. If I choose "aero" for "timing model", the tearing is more important: the line is higher.

It's the only setting which changes something (concerning tearing). Maybe there's a clue.

[cyberbeing]

I think there's an option which does not work: number of backbuffers. It seems not to apply settings

The settings for Number of Backbuffers, Upload frames in Render Queue, and Copy only 1 Backbuffer at a time aren't being remembered.

Edit: It seems the above are sometimes being recorded within the settings.ini, but the OSD reports something completely different. I have no clue what settings madVR is using in that case.

[pankov]

HI, madshi,
I've been following the madVR development for a long time now and had mixed results with the different versions.
Finally I found the time this afternoon to do extensive testing with my configuration.
Currently I'm using
(1) GPU: ATI Radeon 4670
(2) OS: Windows 7 32bit
(3) Movies: different test samples including some nice Judder tests in different refresh rates
(4) Display resolution + refresh rate: 1920x1080 @ 23.976 / 47.952 / 50.000 / 59.940 / 71.928 - all the refresh rates are as close as I can get with or without PowerStrip - usually withing 0.001 of the proper refresh rate
(5) For the test I disabled my primary monitor so I should say "Single monitor" with both Aero ON and OFF
(6) Zoom Player
(7) Video decoder: ffdshow, CoreAVC, Microsoft DTV-DVD Video Decoder
(8) madVR 0.19, default flush settings, 3DLUT off.
(9) Default DirectSound Device (NO Reclock)

While testing I looked for stutterfree playback without tearing. In most cases the OSD numbers showed exactly what my eyes see except a few combinations of refresh rates and Aero which gave me stuttery playback without any dropped or delayed frames in the OSD.
I've made a lot of screenshots which I've combined in one archive uploaded here
http://www.mediafire.com/file/kx5rmwkywmn/madVR_test_result_images.zip
and I'll explain most/all of them now.

I've tried to make the names as explanatory as possible but if there is anything unclear I'll try to clarify it more later.
The "naming convention" is this:
"movie refresh rate @ windows refresh rate + PowerStrip refresh rate (only if dfferent from windows refresh rate)".
In all the cases that there is noting special mentioned in the file name I had Aero turned ON and the special Aero path disabled.

1. "23.976@59.940.png" - this one seemed OK - only the normal telecine judder (I'm not sure this is the correct calling for the constant microstutters that I see but it's not as fluid as when using an exact multiple of the 23.976). The OSD didn't show any flaws which reminds me of a request that I made before - is it really not possible to detect and measure "repeated frames"?
2. "23.976@59.940+PS71.928.png" - strange_aero_delayed_frames.png" - this one shows a strange thing - "aero delayed frames = -2" when I used PowerStrip (prior to starting playback) to set the display at 71.928. How is this possible !?!?!?
3. "59.940@50.000.png" and "59.940@50.000_AeroPath_ON.png" show the absolutely expected thing - huge amount of dropped frames either by madVR or by Aero when using the Aero path. It totally matches what my eyes saw. Here are a few more at other refresh rates
* "59.940@23.976_AeroPath_ON.png" - shows the exact same thing - stuttering as a result of the dropped rames.
* "59.940@23.976+PS47.952.png" - stutter + ocasional tear floating up every 5 seconds or so. The same tearing is visible every time I use 47.952 as a refresh rate.
On a note - this refresh rate is always applied with PowerStrip and is always different from the one known by Windows/Aero.

4. Then I went back to the proper way of playing things - at the correct refresh rate and tried 59.940@59.940. Both with Aero path ON and OFF - the playback was perfect. ("59.940@59.940.png" and "59.940@59.940_AeroPath_ON.png" and "59.940@59.940+PS59.940_AeroPath_ON.png" and
"25.000@50.000.png")

5. Then I started experimenting with different refresh rates for Aero (what windows knows) and the actual refresh rate set by PowerStrip and confirmed by the projector's info screen.
* "59.940@23.976+PS59.940.png" - massive stutter (dropped frames).
* "59.940@23.976+PS59.940+AeroOFF.png" - high rendering times + almost smooth playback except the dropped frames - Only with OSD turned ON - with OSD OFF it's OK. I dug into this and found that it's caused by spline64 Chroma upload. When I go down to Spline36 or anything less it's OK even with OSD ON. This made me fire up the GPU-Z app to see if it was the GPU that's failing and I was amazed to see that it wasn't - it got only ~50% GPU usage ... and it (Spline64) works just fine at other refresh rates. So I'm confused - what could be the cause?
* "23.976@23.976+PS47.952.png" gave me fluid motion + occasional tear floating up at every 5 seconds or so. It was the same with Aero OFF

6. I came back to exact refresh rates but this time with movies (23.976@23.976) and I had mixed results:
* "23.976@23.976+PS23.976.png" - almost fluid motion + occasional stuter !?!?!? Then I did second test (a few hours later) without restarting the PC or changing anything (only a few refresh rate changes) and I got perfect playback "23.976@23.976+PS23.976_2.png"
* "23.976@23.976_AeroPath_ON.png" - smoother than 23.976@23.976 without PowerStrip but still some stutter. Again a few hours later it was perfect!?!?!?
* "23.976@23.976_AeroOFF.png" - absolutely fluid motion + constant tear fixed at 50 pixels from the bottom of the screen. I tried all (OK - many) possible flush options but nothing helped. Any ideas why there is tearing with madVR? I thought you've already fixed it.


I've noticed a couple of strange things while doing my tests
- every time I take a screenshot (pressing the "Print Screen" button) madVR drops a frame. Is this normal?
- I have massive tearing and stutter when ZoomPlayer's popup menu visible and I have Aero turned OFF. Is this one normal? It's not present with Aero turned ON.

That's all for now.
I'm tired of watching moving lines and looking for stuttering.