madVR - high quality video renderer (GPU assisted)

[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+Reclock

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]

Originally Posted by Hypernova

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]

Originally Posted by madshi

(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/libr...8VS.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

[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)


(Aero: Enabled, Aero Rendering Path: Enabled)


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]

Originally Posted by 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!

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]

Originally Posted by 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.

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.

Originally Posted by mark0077

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]

Originally Posted by 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]

Originally Posted by Razoola

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.

Originally Posted by noee

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)

Originally Posted by Hypernova

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.

Originally Posted by mark0077

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.

Originally Posted by starla

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?

Originally Posted by 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?

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.

Originally Posted by LloydA

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?

Originally Posted by iromeoi

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).

Originally Posted by starla

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.

Originally Posted by 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

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.

Originally Posted by 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?).

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.

Originally Posted by SpaceAgeHero

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.

Originally Posted by mark0077

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?

Originally Posted by starla

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...

Originally Posted by 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?

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...

Originally Posted by Mark_A_W

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]

Originally Posted by madshi

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]

Originally Posted by 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?

That would be Microsoft. Unfortunately I don't have much hope to get this fixed by MS.

Originally Posted by mark0077

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.

Originally Posted by LloydA

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.

Originally Posted by Razoola

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.