madVR - high quality video renderer (GPU assisted)

[pankov]

oooh, madshi,
I see there is a new version just after I did a few hours of test of the old one
:(
I hope you won't skip my tests - I think you can find some meaningful information in them.

I guess I'll have to test again with the new one.
... but not now - I'm sick of moving lines and it's 02:00 in the morning here in Bulgaria so I'll leave it for another day ... or night.

I only want to share some final thoughts on Aero:
Guys, with all my testing I came to the conclusion that we need to let Windows/Aero know what's the real refresh rate of the display to get smooth playback with Aero ON. Sadly the ATI drivers allow only 23.976, 50.000 and 59.940 to be added as special "HDTV Support" resolutions. These are perfect for my projector but sadly my primary monitor (23" LCD ACER H233H) can't hadle anything bellow 49Hz so I have to somehow to officially add 71.928 so I can play movies on it too ... or have the monitor and the projector active at the same time and have them at refresh rates multiple of the movie so I can have Aero ON to avoid tearing. Does any body know how to do it? I started reading something about EDID override but I got lost :(

[cyberbeing]

madshi, I've PM'ed you another sample which causes a huge lag when using a 3DLUT.

[6233638]

But don't worry. With 0.19 on win7, the special Aero rendering mode was (ever so) slightly better for me, too.I find this very interesting as we both have the same gpu (9400M) and I found the Aero rendering path to be worse. Stats improved slightly but performance was worse. I do have Aero on in the W7 gui though and am in a single monitor environment.

Will test 0.20 shortly. Can stats be trusted? I have smooth playback with Bicubic75 now so the only way for me to test performance changes is to either look at render/present times or use upsampling options the gpu cannot handle and see which drops the least frames.

(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.All new settings seem to be reset on closing and reopening MPC-HC.

(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...What constitutes a high refresh rate? I run 48Hz. Is this just a refresh rate detection option or..?


As the settings are not remembered and performance is worse I am back using 0.19 for now. Can't really test this.

[Hypernova]

I did mention in my feedback that the Aero path seems to get rid of massive stuttering that include the non-video part i.e. the seekbar cursor, GUI elememt, etc. Well, since you already move on, time to play with the new verson I think :)

[evantreborn]

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 finally find out what caused the weird glitch and crash problem with madVR on my PC, it was the ATI powerplay that lowered my GPU and GPU memory clock, and crash my machine during playback with latest madVR. I lock the clocks in latest CCC and the problem is gone now. Thanks for all the kind people here and now I can well enjoy the latest madVR:thanks:

[lych_necross]

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 tried the new Aero rendering path on my single monitor system and I really couldn't notice a difference. It could be just my system, my eyes, the movie I played, position of the moon etc... but on or off, it looked pretty much the same.

My Specs:
Windows 7 64bit (Aero on)
MPC-HC 1.3.2050.0 (MadVR .19)
Nvidia Geforce 9800 GTX+ (257.21)
EDIT: I see this new rendering path was already dropped.

[nijiko]

The setting window is too high...
On my 1024*768, the bottom of window will not be displayed, such as OK or Cancel button...

[madshi]

For reference, which of these new options did previous versions of madVR already use in some fashion?
0.18:
Upload frames in render thread = off
Copy only 1 backbuffer at a time = off
Timing model = normal
Number of backbuffers = 3

0.19:
Upload frames in render thread = off
Copy only 1 backbuffer at a time = off
Timing model = high refresh rate
Number of backbuffers = 8

0.20 (defaults):
Upload frames in render thread = on
Copy only 1 backbuffer at a time = on
Timing model = normal
Number of backbuffers = 8

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.
Yeah, my fault, sorry. That's a result of a late change in the default state of these options. Please remember, though, that 2 of these options require a restart of the media player (or at least a reloading of the video file), that will still apply with the next madVR version.

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.
I already know that the timing model does influence tearing. The problem is that the timing model also very strongly influences dropped and delayed frames.

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"?
As I explained before, madVR does not even care to look for repeated frames. That's not how the current presentation model works. It is your responsibility to make sure that movie frame rate and display refresh rate match.

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 !?!?!?
Hmmmm... The "aero" stats are reported directly by Aero. Don't know why they would be negative.

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.
Yeah, well, if the display refresh rate is *lower* than the movie framerate, of course that can't work well...

4. Then I went back to the proper way of playing things
Thank God! :)

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).
Interesting. So Aero does not notice what PowerStrip does. Which means that combining Aero and PowerStrip is not a good idea, except maybe for very small adjustments.

"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?
That's pretty simple: Windowed mode rendering sucks balls big time. I've been trying to squeeze the last bit of performance out of this terrible MS solution in the last couple of weeks, but there are simply borders to what can be achieved.

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!?!?!?
Not sure where the stuttering came from. Maybe your PC was busy doing other things? In theory, playback should be fine with these settings.

"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 improved it. Never claimed to have fixed it. Others have reported that it was fixed for them. Which actually surprised me. The final fix for tearing is to either use Aero (and even that doesn't always seem to help) or finally fullscreen exclusive mode.

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.
Hmmmm... Will put that on my to do list. Not sure if there's anything I can do about it.

I'm tired of watching moving lines and looking for stuttering.
I can imagine. Thanks for the extensive tests and screenshots. I think what we can conclude from your tests is that Aero really only works well if movie frame rate and "official" refresh rate and composition rate all match (or are at least a multiply of each other).

You didn't say anything about whether the special Aero rendering mode was working better or not better for you than not using it?

oooh, madshi,
I see there is a new version just after I did a few hours of test of the old one
:(
I hope you won't skip my tests - I think you can find some meaningful information in them.
Don't worry, maybe (hopefully) 0.20/0.21 improves things a bit, but it won't change everything completely.

I guess I'll have to test again with the new one.
... but not now - I'm sick of moving lines and it's 02:00 in the morning here in Bulgaria so I'll leave it for another day ... or night.
If you rerun the tests, please don't bother testing non-matching combinations of movie framerate and display refresh rate. I mean it's interesting to see the results, but it's not really not worth the effort, cause it's very clear that movie framerate and display refresh rate should match as well as possible.

I only want to share some final thoughts on Aero:
Guys, with all my testing I came to the conclusion that we need to let Windows/Aero know what's the real refresh rate of the display to get smooth playback with Aero ON. Sadly the ATI drivers allow only 23.976, 50.000 and 59.940 to be added as special "HDTV Support" resolutions. These are perfect for my projector but sadly my primary monitor (23" LCD ACER H233H) can't hadle anything bellow 49Hz so I have to somehow to officially add 71.928 so I can play movies on it too ... or have the monitor and the projector active at the same time and have them at refresh rates multiple of the movie so I can have Aero ON to avoid tearing. Does any body know how to do it?
Does ATI not allow you to create a 72Hz custom refresh mode?

madshi, I've PM'ed you another sample which causes a huge lag when using a 3DLUT.
Thanks. I'll give it a try sooner or later. Unfortunately I don't really have much ideas on how to improve this problem. All madVR is doing is to upload the 3dlut to the GPU RAM, and then each pixel is fed into the 3dlut, by using a simple one line pixel shader command. There's not so much I can do here to change/improve performance. My best guess is that for those out of gamut pixels in your situation the GPU's texture cache fails to work, which might explain the drop in rendering performance. A newer/better GPU might not have this problem, or might have the reserves to deal with the problem without dropping frames.

I find this very interesting as we both have the same gpu (9400M) and I found the Aero rendering path to be worse. Stats improved slightly but performance was worse. I do have Aero on in the W7 gui though and am in a single monitor environment.
Well, testing is a bit problematic. E.g. sometimes pausing and restarting playback allows the madVR queues to fill up and afterwards rendering can run smoothly. That helps with some rendering modes, but less with others. Because of that it's really difficult to say which mode is ultimately better or worse. Some recover faster from a seek than others. Some need longer to achieve smooth playback, but are then better at keeping it smooth. It's really difficult to judge. But I can say that with 0.20, I've noticed a clear improvement with my 9400. It seems that especially the "upload frames in render thread" improves things - which I didn't really expect. It was just a funny thought that it might be worth a try...

Will test 0.20 shortly. Can stats be trusted? I have smooth playback with Bicubic75 now so the only way for me to test performance changes is to either look at render/present times or use upsampling options the gpu cannot handle and see which drops the least frames.
Don't trust rendering times for such an evaluation. I didn't have smooth playback with Bicubic75 chroma + luma resampling with 0.19, btw, at least not when the source was already 1080p24. Playing that back without luma scaling worked fine. But rescaling 1080p24 luma with Bicubic resulted in stuttering on my HTPC. With 0.20 things seem to have improved. If Bicubic for both chroma and luma already worked for you with 0.19, try checking if you can use Lanczos3 now, which consumes more performance than Bicubic.

What constitutes a high refresh rate? I run 48Hz. Is this just a refresh rate detection option or..?
The "high refresh rate" timing model is identical to the "normal" timing model, except if your display refresh rate is more than 2.3 * movie frame rate. In that case the high refresh rate timing model changes slightly.

I did mention in my feedback that the Aero path seems to get rid of massive stuttering that include the non-video part i.e. the seekbar cursor, GUI elememt, etc.
Yes, you did. But honestly, a stuttering seekbar is low on my list of important things... :)

I finally find out what caused the weird glitch and crash problem with madVR on my PC
Glad to hear that!

I tried the new Aero rendering path on my single monitor system and I really couldn't notice a difference. It could be just my system, my eyes, the movie I played, position of the moon etc... but on or off, it looked pretty much the same.
Thanks for the feedback.

The setting window is too high...
On my 1024*768, the bottom of window will not be displayed, such as OK or Cancel button...
Well, can't do anything about that for now. Except hopefully dropping some of the new options in a future release again, when we all agreed on how to configure them for best results. Sooner or later I'll redesign the settings dialog, then it should need less space.

[madshi]

madVR v0.21 released

http://madshi.net/madVR.zip

* fixed: some of the new tweak options weren't stored properly

[THX-UltraII]

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

It seems good for me to use. I don t use hardware acc. or DXVA so that won t be a problem. A have a ATI 5xxx card so GPU enough.

I just installed the latest version and installed Directvobsub and subtitles work ok with this.

Can you help me out how to set up my system for the best PQ resultst now that I use madVR?:

what does the option 3d lut do?
What are the best PQ scaling setting to pick (I don t want noticable ringing or other artifacts)?
What is tearing model?
No of backbuffers, should I pick here how many cores I have? So 4 for a coretoquad?
And what about the three last settings 'after......' What are they for?

[namaiki]

What are the best PQ scaling setting to pick (I don t want noticable ringing or other artifacts)?

Possibly one of the spline options, but the previous defaults were
Luma: softcubic50
Chroma: softcubic100
are probably even less for artifacts, but all of this will affect how subtitles look as well.

[djsolidsnake86]

is possible integrate madvr on terratec home cinema?

[madshi]

what does the option 3d lut do?
That's for display calibration (gamut and gamma correction), if you have a meter.

What are the best PQ scaling setting to pick (I don t want noticable ringing or other artifacts)?
There are no "best" settings. It's a matter of taste. If you don't want ringing, then don't use Lanczos. Maybe Spline works for you, but it rings a bit, too. If no ringing is very important for you, I'd suggest to try Mitchell. What I just wrote applies to Luma scaling. For chroma I suggest a softer scaler, e.g. one of the SoftCubic variants. But even that is a matter of taste...

What is tearing model?
No of backbuffers, should I pick here how many cores I have? So 4 for a coretoquad?
And what about the three last settings 'after......' What are they for?
These are all options that affect if there's stuttering or tearing. If madVR behaves perfectly with the default options for you, then just leave these options alone. If you have stuttering or tearing, you can try playing with these options to see if any of these improves things for you. FWIW, with your GPU some people have reported that setting all the "flush" comboboxes to "don't flush" works best, so you could try that...

is possible integrate madvr on terratec home cinema?
Currently madVR does not have any option to force itself into a media player which doesn't officially support it. So you'd have to ask the terratec guys to add madVR support.

[Razoola]

madshi, don't forget to add 021 to the first post :)

[Hypernova]

Yes, you did. But honestly, a stuttering seekbar is low on my list of important things... :)

I meant to say that if there is a problem with Aero causing a global stutter (not just video) then the Aero path seems to fix it. But oh well. Let's move on :)

[madshi]

I meant to say that if there is a problem with Aero causing a global stutter (not just video) then the Aero path seems to fix it. But oh well. Let's move on :)
Then I misunderstood your report. But does the global stutter still occur with 0.21 with Aero timing mode and other options tweaked?

[pankov]

Interesting. So Aero does not notice what PowerStrip does. Which means that combining Aero and PowerStrip is not a good idea, except maybe for very small adjustments.
....
I think what we can conclude from your tests is that Aero really only works well if movie frame rate and "official" refresh rate and composition rate all match (or are at least a multiply of each other).
....
Does ATI not allow you to create a 72Hz custom refresh mode?
That's exactly the same conclusion I came to. So that's why I'm looking for a way to set windows/Aero to a good refresh rate. Sadly ATI doesn't allow any custom refresh rates. It only has a few predefined ones called "HDTV Support" and that's it. :(
And that's even worse with the new 5xxx cards which don't even work with PowerStrip.
So does any of you guys know how to make an EDID override and add a few resolution that I know my monitor supports but are not present in the Catalyst control panel?

Not sure where the stuttering came from. Maybe your PC was busy doing other things? In theory, playback should be fine with these settings.
That puzzles me too. I looked for processes that can cause it but there weren't any. And the interesting part was that 59.940 was absolutely stutter free and as far as know it's the tougher one.

I've improved it. Never claimed to have fixed it. Others have reported that it was fixed for them. Which actually surprised me. The final fix for tearing is to either use Aero (and even that doesn't always seem to help) or finally fullscreen exclusive mode.
Maybe the others didn't see the tear at the bottom of the screen ... or it was offscreen for them. Guys, anybody bothers to test again?
I've done some tests with 0.21 and sadly the tearing is present with all combinations of the new options. The only option that changes anything is the "Timing model" - whet it's set to "aero" the tear is placed around 1/3 from the bottom of the height of the screen and again it's not moving.
With Aero I've never seen tearing so I wonder what did Microsoft do to prevent it and why this can't be done by the renderer itself. For me ... and I suppose all ZoomPlayer users ... this will be the only solution, because ZP doesn't work ... at least not well ... in fullscreen exclusive mode. :(

Hmmmm... Will put that on my to do list. Not sure if there's anything I can do about it.
Don't bother - it's not important at all. I mentioned it so you know it and if it brings some clues to something else.

You didn't say anything about whether the special Aero rendering mode was working better or not better for you than not using it?
I thought I did, but nevertheless for me the special rendering path didn't improve or worsen anything.

...cause it's very clear that movie framerate and display refresh rate should match as well as possible.I totally agree but sadly matching them perfectly is not possible with all those different clocks in the media playback (the video card has one, the audio card has a different one, and the system clock is different from both .... and none of them are exact enough to not deviate over time).
I've read (as far as google translate helped me the German) the article from here
http://www.avpedia.org/wiki/HTPC_Bildfrequenz_Optimierung
and I'll try to do some improvements on my timings but I'll be glad if some of you can share their timings for
1080p @ 23.976 / 47.952 / 50.000 / 59.940 / 71.928

and does anybody has a very long (24 hours) samples for 23.976 and 29.970 cause the article only talks about 50.000 / 25.000.

[madshi]

With Aero I've never seen tearing so I wonder what did Microsoft do to prevent it and why this can't be done by the renderer itself.
I *think* that MS uses the hardware VSync interrupt, but I'm not really sure. Windowed mode rendering doesn't really have access to this. Only fullscreen exclusive mode makes use of the VSync hardware interrupt.

For me ... and I suppose all ZoomPlayer users ... this will be the only solution, because ZP doesn't work ... at least not well ... in fullscreen exclusive mode. :(
Which limitations does ZP have exactly, which prevents it from doing fullscreen exclusive mode (well)?

[pankov]

I *think* that MS uses the hardware VSync interrupt, but I'm not really sure. Windowed mode rendering doesn't really have access to this. Only fullscreen exclusive mode makes use of the VSync hardware interrupt.
Well that brings the question - isn't it possible for a media player (the render itself) to get access to the hardware VSync interrupt even when not using DirectShow/DirectX/MediaFondation APIs but some kind of more low level Windows API?

Which limitations does ZP have exactly, which prevents it from doing fullscreen exclusive mode (well)?All the UI is not drawn to the video surface but is normal windows drawn over the video. This includes the play state notifications, the timeline/seek bar, Audio/mp3 tags and the most important one - the Media Library Navigator part of the Fullscreen navigation menu system. Sadly changing these will need a major overhaul of the player and the developers are not planning on making it. :(
If the user doesn't need those and uses the player for pure playback it can work with fullscreen exclusive ... at least it kind of did work with VMR9 exclusive.

[madshi]

Well that brings the question - isn't it possible for a media player (the render itself) to get access to the hardware VSync interrupt even when not using DirectShow/DirectX/MediaFondation APIs but some kind of more low level Windows API?
No. Windows user mode does not support interrupts at all. Interrupts can only be handled in driver land.

and the most important one - the Media Library Navigator part of the Fullscreen navigation menu system.
That sounds all Spanish to me. You mean "stop", "play" and "pause"? Or what do you mean exactly?

[pankov]

No. Windows user mode does not support interrupts at all. Interrupts can only be handled in driver land.
:(

That sounds all Spanish to me. You mean "stop", "play" and "pause"? Or what do you mean exactly?
No, I mean a nice UI for selecting which file/DVD/BD to play ... and some other function
look at the images bellow
http://img441.imageshack.us/img441/4468/mainmenu.th.png (http://img441.imageshack.us/i/mainmenu.png/) http://img15.imageshack.us/img15/268/medialibrary.th.png (http://img15.imageshack.us/i/medialibrary.png/) http://img256.imageshack.us/img256/3550/medialibrarytvcaptures.th.png (http://img256.imageshack.us/i/medialibrarytvcaptures.png/) http://img31.imageshack.us/img31/3411/timelinemediastate.th.jpg (http://img31.imageshack.us/i/timelinemediastate.jpg/)

[pankov]

madVR v0.20 released

http://madshi.net/madVR.zip

* fixed: Microsoft VC-1/WMV decoder didn't start playing in Windows 7
...

I see that you somehow fixed the problem with Microsoft VC-1/WMV decoder and I was wondering if you can fix a similar problem with the Microsoft DTV-DVD Video decoder and some H.264 or MPEG2 streams. For example with the sample bellow
http://www.mediafire.com/file/yzymdmnt3oz/RTL%20HD%20Trailer.ts
Zoomplayer can't build the graph with madVR while with EVR everything works fine. At the same time with ffdshow and madVR it works and the video isn't even interlaced ... as far as I can tell.
With another MPEG2 video in MPG file I get the following error
Pin Connection Error:
[Microsoft DTV-DVD Video Decoder].Video Output 1 ---> [madVR Video Renderer].Input
Code: There is no common media type between these pins. (80040207)

Is there anything you can do about it? If you want I can provide a .log file.

[namaiki]

The MS Decoder seems to be wanting to output NV12, or YUY2, or I420, or DXVA only.

Also, I believe the video is interlaced content according to MediaInfo. http://pastebin.com/9A8xqwJs

When I was using DirectVobSub, with the MS Decoder and MadVR, it was converting I420 from the MS Decoder and outputting YV12 to MadVR.

According to: http://www.fourcc.org/yuv.php
IYUV and I420: These formats are identical to YV12 except that the U and V plane order is reversed. They comprise an NxN Y plane followed by (N/2)x(N/2) U and V planes. Full marks to Intel for registering the same format twice and full marks to Microsoft for not picking up on this and rejecting the second registration.

[leeperry]

madVR v0.20 released [..]
* you can now put an empty log file in madVR's folder to overwrite the log path
Thanks for the new version! I will try more movies, and hopefully come back w/ some relevant logs. I just watched a 90 mins 23.976fps@96Hz movie w/ those settings in PotPlayer/Reclock/XPSP3 and it went just fine :)

http://thumbnails30.imagebam.com/8520/d4b50d85199834.jpg (http://www.imagebam.com/image/d4b50d85199834)

Which limitations does ZP have exactly, which prevents it from doing fullscreen exclusive mode (well)?
Well, most players won't be able to show their OSD/transport bar I think...so a hotkey for windowed/FS would be fine, go windowed if you wanna seek, go FS if you wanna watch the movie.

BTW, the CTRL+J hotkey hardly works when I assign it within my Logitech Setpoint drivers...sometimes I can get mVR's OSD to show if I'm lucky. It was working perfectly fine w/ HR :o

Hopefully, if you set a hotkey to go FS/windowed, that'd be nice if it worked more reliably w/ the Logitech drivers if any possible :)
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
Can't really tell and now that I double-checked, the movie that was hiccuping after 45 mins w/ 0.19 was actually 24fps...When I used to have this problem w/ EVR, it would constantly drop frames and require a reseek, in HR it would slowly drop more and more frames randomly if its jitter figure was >7ms....that's what happened w/ mVR, it was slowly dropping frames randomly...hard to miss on slow pans.

[pie1394]

Hi madshi,

About the bottom side tearing at 23.976 and 59.94 fps for FILM contents under Windows 7, I almost can confirm it is due to the slightly too early presenting of next frame.

When there are quick moving objects from big to small, it can be observed that bottom part of objects always become smaller earier than their rest parts.

When it is changed to Aero timing mode w/o Aero, my experience is just like some people's condition - The tearing line goes up near middle of vertical position.

[JarrettH]

can you tell me more about the two new options for windowed mode? upload frames in render thread and copy only 1 backbuffer at a time

what are number of backbuffers?

if i'm running Aero should I presume to want to use the special Aero mode?

Also, it's back to taking several seconds (at least 4-5 in a lot of situations) to pause a video, switch, and even my cursor takes several seconds to reappear on the screen during playback.

Annnddddd finally! Call this silly, but why the focus on windowed mode when we all playback in fullscreen afterwards?

:thanks:

[starla]

Can't really tell and now that I double-checked, the movie that was hiccuping after 45 mins w/ 0.19 was actually 24fps...When I used to have this problem w/ EVR, it would constantly drop frames and require a reseek, in HR it would slowly drop more and more frames randomly if its jitter figure was >7ms....that's what happened w/ mVR, it was slowly dropping frames randomly...hard to miss on slow pans.

That sounds like audio and video HW clocks drifting away. Something that either audio renderer should be correcting by resampling the audio stream to match or video renderer to do some workarounds, like madshi has proposed few weeks ago when I brought up the issue (which I doubt are providing good results)

[starla]

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

True, but supporting Vista is quite "useless" since I bet almost everyone who uses Vista have been upgraded to Windows 7 and who used XP aren't affected.


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

Yep, it will require different logic. But there is also one extra benefit. If you look closely to the D3DSWAPEFFECT_FLIPEX documentation you will notice that without it GPU will have one extra texture copy step when it is presenting the video (or any other) texture when AERO is enabled.

[makakam]

I get dropped and delayed frames in m2ts files only. In other formats everything is perfect. Is it only me?
I use TV LCD(single display), aero ON, reclock, and my GPU is rather good ATI 5770

[namaiki]

I get dropped and delayed frames in m2ts files only. In other formats everything is perfect. Is it only me?
I use TV LCD(single display), aero ON, reclock, and my GPU is rather good ATI 5770

What decoder and splitter? Try use Haali Media Splitter.

[Hypernova]

Then I misunderstood your report. But does the global stutter still occur with 0.21 with Aero timing mode and other options tweaked?

I'm still don't get a chance to play much with all the tweak, but the Aero timing does not get rid of the global stuttering problem like Aero path did. I also want to let you know that that weird behavior where the global stuttering disappear after I open OSD at least once is still there. I really have no idea how this happen. It's clearly reproducible in my setup, and truly unique for madVR. At least EVR Custom & Sync renderer does not do this.

Additional info: this effect got "reset" only after the player is restart. The global stutter disappear even after re-opening the file. In fact, there is no global stutter even if I change the renderer to something else. Maybe it does not have much to do with madVR, but the madVR OSD triggered "something". Maybe I should cross post this in the Aero thread too?

Info
(1) ATi 5770
(2) Windows Server 2008 R2
(3) Aero on
(4) 2560x1600/60Hz + 1920x1080/24p
(5) Dual monitor setup. 1st on DisplayPort, 2nd on HDMI

[madshi]

No, I mean a nice UI for selecting which file/DVD/BD to play ... and some other function
look at the images bellow
Oh well, there's nothing I can do about that. Maybe Blight could switch into fullscreen exclusive mode, only for playing the files, and switch back to normal mode (e.g. by destroying and recreating the renderer on the fly) when he wants to show this GUI stuff?

I was wondering if you can fix a similar problem with the Microsoft DTV-DVD Video decoder and some H.264 or MPEG2 streams.

"There is no common media type between these pins."
The MS Decoder seems to be wanting to output NV12, or YUY2, or I420, or DXVA only.
Yeah, seems like that decoder doesn't want to output YV12.

Well, most players won't be able to show their OSD/transport bar I think...
FWIW, madVR could show its own seek bar.

BTW, the CTRL+J hotkey hardly works when I assign it within my Logitech Setpoint drivers...
In a future version I will probably make the OSD key adjustable.

Can't really tell and now that I double-checked, the movie that was hiccuping after 45 mins w/ 0.19 was actually 24fps...When I used to have this problem w/ EVR, it would constantly drop frames and require a reseek, in HR it would slowly drop more and more frames randomly if its jitter figure was >7ms....that's what happened w/ mVR, it was slowly dropping frames randomly...hard to miss on slow pans.
Were the drops visible in the OSD stats as dropped or delayed frames?

About the bottom side tearing at 23.976 and 59.94 fps for FILM contents under Windows 7, I almost can confirm it is due to the slightly too early presenting of next frame.

When there are quick moving objects from big to small, it can be observed that bottom part of objects always become smaller earier than their rest parts.

When it is changed to Aero timing mode w/o Aero, my experience is just like some people's condition - The tearing line goes up near middle of vertical position.
Yes, I know. But as I said before, if I move presentation to a later time, there's increased danger of getting dropped/delayed frames. The "Aero" timing mode already presents at scanline 1 for the next vsync. That's as early as possible. Of course, if your GPU doesn't behave as it should, this will result in tearing. However, if Aero is activated, presenting this early means that there's less chance of the frame getting lost due to too late presentation. So for Aero it might be a good idea to present that early. That's why I called this timing model "aero".

can you tell me more about the two new options for windowed mode? upload frames in render thread and copy only 1 backbuffer at a time

what are number of backbuffers?
"Upload frames in render thread" defines in which thread the decoded video frames are uploaded to the GPU. If you check this option, they're uploaded in the same thread which renders the frames. If you uncheck this option, the video frames are uploaded in a dedicated upload thread. I thought that using a dedicated upload thread would give better results, so that's what madVR always did up to v0.19. But now after playing with this new tweak option in v0.20/0.21, my impression is that it's preferable to upload in the render thread. But that's just on my PC. It might be different for you. So please give it a try for yourself and report back whether you get better results with this option on or off.

madVR has a render thread, which is doing the render work. And a vsync thread which is looking for scanlines, vsyncs, and which is copying the rendered frames to the backbuffers and is presenting them. If you have "copy only 1 backbuffer at a time" checked, madVR will copy one rendered frame to a free backbuffer at a time, and then check whether it can present a frame again. If you have this option unchecked, madVR will copy 2 rendered frames to free backbuffers (if available) at a time, before checking whether it can present a frame again. madVR up to v0.19 copied 2 frames, but now I actually think it's better to only copy 1 frame at a time.

"number of backbuffers" defines how many DirectX backbuffers are used by madVR. XP only supports up to 3 backbuffers. Vista and Windows 7 support up to 30 backbuffers, but madVR is using max 8. I don't think that this option will have much effect (unless you set it lower than 3 or 2), but I wanted you to be able to play with it, because some people reported stuttering problems with v0.19 which they didn't have in v0.18, and I increased the number of backbuffers from v0.18 to v0.19 from 3 to 8. I think having 8 backbuffers instead of 3 shouldn't hurt, but may sometimes help. But I'm not 100% sure...

if i'm running Aero should I presume to want to use the special Aero mode?
Not necessarily. The timing modes specify at which scanline madVR presents the next frame. The Aero mode always presents very early. Which means that madVR may have to wait (= is blocked) for a long time until the presetation is completed. But on the positive side, there's less danger of missing a frame due to too late presentation. The other 2 timing modes vary presentation time, depending on how full the queues are. The fuller the queues are, the earlier frames are presented. When the queues are empty, presentation is moved back. Moving presentation back increases the danger of getting delayed/dropped frames (= motion stutter), but allows the queues to fill again.

For me, when using Aero, the "aero" timing model produces the best results. However, I can also see that most of the madVR queues are stuck at 1-2 frames for me, when using the "aero" timing mode, while the queues fully fill up when using the other timing modes. So the aero timing mode has its own problems. Still, it produces the best subjective results on my PC, when using Aero. Might be different for you, though.

Also, it's back to taking several seconds (at least 4-5 in a lot of situations) to pause a video, switch, and even my cursor takes several seconds to reappear on the screen during playback.
I never understood where the problem came from. And I also never understood why it was suddenly gone for you. And finally, I don't understand why its back now... :)

But anyway, can I have a log of such a situation, please?

Annnddddd finally! Call this silly, but why the focus on windowed mode when we all playback in fullscreen afterwards?
You mean fullscreen exclusive? There's a difference between fullscreen (which is still windowed mode) and fullscreen exclusive. Anyway, there are several reasons. Here are just some examples:

(1) Some people hate fullscreen exclusive mode, because most GUI stuff doesn't work there, anymore.

(2) Even if you prefer fullscreen exclusive mode for movie watching, if you want to check something during remuxing, or if you want to watch a music video on your work PC, or [...] windowed mode is often preferred, because it's simply more user friendly.

(3) Many of the tweaks and optimizations for windowed mode may also help fullscreen exclusive mode.

(4) I like to do one step at a time. Windowed mode was not really perfect yet, so I want to get it as good as it gets first, before moving on to fullscreen exclusive mode.

(5) Fullscreen exclusive mode doesn't make sense if I don't offer a subtitle/OSD input pin, or at least draw my own seek bar control. So fullscreen exclusive mode has some extra requirements.

Etc etc...

But windowed mode is near finished now. I just need some feedback on the new tweak options. I'll wait until that's sorted out, then I'll move on to fullscreen exclusive mode. If you guys are fast with feedback on the new tweak options, I might be able to deliver a first (not fully optimized yet) fullscreen exclusive mode version in 1-2 weeks from now. But I will not do so, before we've properly cleaned up the windowed tweak options. So it's up to you guys how quickly I can deliver the first fullscreen exclusive mode version. One step at a time...

That sounds like audio and video HW clocks drifting away. Something that either audio renderer should be correcting by resampling the audio stream to match or video renderer to do some workarounds, like madshi has proposed few weeks ago when I brought up the issue (which I doubt are providing good results)
Well, audio/video clock drift can be slow or fast, but the drift should usually be more or less constant. So if madVR is able to achieve smooth video playback for 45 minutes, I don't really see why it shouldn't be possible to drop/repeat a frame (if necessary) after 45 minutes and then go back to show smooth motion for another 45 minutes. If the audio/video drift is too strong, madVR shouldn't even be able to achieve smooth playback for 5 minutes.

Or in other words: If audio/video clocks don't match, madVR will be forced to drop (or repeat, depending on which clock is faster than which) a frame in specific intervals. But between these specific drop/repeat intervals, madVR should provide smooth playback.

[madshi]

True, but supporting Vista is quite "useless" since I bet almost everyone who uses Vista have been upgraded to Windows 7 and who used XP aren't affected.
True. But then, having good support for Vista in addition to XP and Windows 7 wouldn't hurt...

Yep, it will require different logic. But there is also one extra benefit. If you look closely to the D3DSWAPEFFECT_FLIPEX documentation you will notice that without it GPU will have one extra texture copy step when it is presenting the video (or any other) texture when AERO is enabled.
Yes, that's true. I will look into FLIPEX for fullscreen exclusive mode support. Once I've got that working, I can check whether that solution will also work well for Windows 7 windowed mode. In theory it should...

I get dropped and delayed frames in m2ts files only. In other formats everything is perfect. Is it only me?
I use TV LCD(single display), aero ON, reclock, and my GPU is rather good ATI 5770
Does that happen with both h264 and VC-1 m2ts files? Which splitter are you using? Try switching between MPC HC internal splitter and Haali. Also try all the "windowed mode tweak" options in the madVR settings dialog. E.g. try turning off all the flushes. And try switching to "aero" timing mode.

I'm still don't get a chance to play much with all the tweak, but the Aero timing does not get rid of the global stuttering problem like Aero path did. I also want to let you know that that weird behavior where the global stuttering disappear after I open OSD at least once is still there. I really have no idea how this happen. It's clearly reproducible in my setup, and truly unique for madVR. At least EVR Custom & Sync renderer does not do this.

Additional info: this effect got "reset" only after the player is restart. The global stutter disappear even after re-opening the file. In fact, there is no global stutter even if I change the renderer to something else. Maybe it does not have much to do with madVR, but the madVR OSD triggered "something". Maybe I should cross post this in the Aero thread too?
Do you see lots of dropped/repeated frames when you open the OSD, after you got that stuttering? Have you tried playing with the flush options? I've found that flushing after "render steps" and/or after "last step" often helps getting rid of that kind of stuttering. Which is your display refresh rate, what is your composition rate and are you using Reclock and/or PowerStrip?

[JarrettH]

Actually I didn't know that fullscreen was also a windowed mode too. I'll re-read your post when I'm more awake. Thank you :cool:

[leeperry]

Humm, using the aforementioned settings I'm really impressed by the smoothness of "A Bug's Life" BD...I don't think I ever saw it this smooth in 0.19, might be placebo though..but still very very impressive in 96Hz :eek:
Were the drops visible in the OSD stats as dropped or delayed frames?
Not as far as I can tell...but I'll do my homework next time!
madVR could show its own seek bar.
oh, wow! I wonder how that'd work w/ KMP/PotP seamless playback.
I can't remember the name but there was an old player that had a very slick exclusive mode interface...too bad you had to import graphedit files for each new container, and MKV had never worked for me.
In a future version I will probably make the OSD key adjustable.
I don't think it's a matter of what key, it's more a matter of how the SetPoint Logitech drivers send it and how mVR captures it...I guess there must be zillion ways to do that, and it works perfectly fine w/ HR/MPC-HC/KMP/PotP's built-in hotkeys but fails w/ mVR :o

[leeperry]

BTW, I've uploaded 3 logs here: http://www.mediafire.com/?kwmigolxmxm

in the two first I've tried to go FS before the picture showed up in the latest PotP/ICL11 ffdshow audio+video/Reclock/XP forceware/DX9 update, PotP is frozen and nothing happens...I have to kill its windows process.

In the last one, I've waited for the picture to show up before going FS...and everything works fine.

I can reproduce this problem 100% of the time, and I don't think it ever happened in older builds...I can also reproduce it in KMP.

[Hypernova]

Do you see lots of dropped/repeated frames when you open the OSD, after you got that stuttering? Have you tried playing with the flush options? I've found that flushing after "render steps" and/or after "last step" often helps getting rid of that kind of stuttering. Which is your display refresh rate, what is your composition rate and are you using Reclock and/or PowerStrip?

Before the first OSD turn on: 22 drop frames
vs.
After the first OSD turn on: 1 drop frame

These are from madVR stat.

I've play around with flushing a bit, and indeed what best for this setup now is loop/flush/don't/don't, with the first being sleep will be slightly worse. There is stuttering sometimes, but far and few in-between. I'll keep playing with flushing and other new tweak. Right now I'm on No check/High refresh rate/8/loop/flush/don't/don't

Display: 23.999Hz
Composition rate 60.000Hz (clearly wrong)

No Reclock/PowerStrip

Info
(1) ATi 5770
(2) Windows Server 2008 R2
(3) Aero on
(4) 2560x1600/60Hz + 1920x1080/24p
(5) Dual monitor setup. 1st on DisplayPort, 2nd on HDMI
(6) MPC-HC/No Reclock/PowerStrip

[cyberbeing]

Well it turns out that the GTX 470 didn't have unique flush settings. Everything is just as smooth with the same settings on my 7800GTX 512.

use managed upload textures=0
flush after intermediate rendering steps=don't flush
flush after final rendering step=flush
flush after copy to backbuffer=flush & wait (loop)
flush after present=flush & wait (loop)
upload frames in render thread=1
copy only 1 backbuffer at a time (instead of 2)=1
timing model=high refresh rate
no of backbuffers=8

General Comments

The copy only 1 backbuffer at a time (instead of 2) setting doesn't appear to make any noticeable difference, but I've left it enabled for the time being, since you've made it a default.

The upload frames in render thread setting doesn't appear to make any noticeable difference, but I've left it enabled for the time being, since you've made it a default.

The timing models high refresh rate and normal appear to behave identically. On WinXP, Aero mode is slightly worse. Since I assume high refresh rate mode is theoretically better at high refresh rates, I'll continue using that mode.

The no of backbuffers set to 1 appears to behave identically to it being set to 8. I've left it at 8, since I assume it should improve present stability.

Bug
Either the OSD stats are broken or the no of backbuffers setting is broken.

If you set the no of backbuffers to 4, 5, 6, 7, or 8, the OSD stats remain at 2-3/3. Bug.

Yet if you reduce the no of backbuffers to say 1, the OSD stats will reflect the change and show 0-1/1. No bug.

In other words, assuming the OSD stats are correct, the maximum number of backbuffers are never being set above 3.

Windows XP SP3
AMD X2 4800+ (939)
7800GTX 512 (Forceware 197.90)
Single Monitor CRT
1600x1200 @ 96.0005 Hz | 1920x1080 @ 119.9556 Hz
MPC-HC w/ Reclock

[nevcairiel]

Bug
Either the OSD stats are broken or the no of backbuffers setting is broken.

If you set the no of backbuffers to 4, 5, 6, 7, or 8, the OSD stats remain at 2-3/3. Bug.

Yet if you reduce the no of backbuffers to say 1, the OSD stats will reflect the change and show 0-1/1. No bug.


XP only supports up to 3 backbuffers. Only Vista/7 allow more (up to 30, in theory)

[madshi]

I don't think it's a matter of what key, it's more a matter of how the SetPoint Logitech drivers send it and how mVR captures it...I guess there must be zillion ways to do that, and it works perfectly fine w/ HR/MPC-HC/KMP/PotP's built-in hotkeys but fails w/ mVR :o
Well, I'm installing a global keyboard hook. No idea why it wouldn't work with Logitech drivers!? But we can work on that later...

BTW, I've uploaded 3 logs

in the two first I've tried to go FS before the picture showed up in the latest PotP/ICL11 ffdshow audio+video/Reclock/XP forceware/DX9 update, PotP is frozen and nothing happens...I have to kill its windows process.
Hmmmm... Will check if I can see something in the logs...

Before the first OSD turn on: 22 drop frames
vs.
After the first OSD turn on: 1 drop frame

These are from madVR stat.
Ah, so it appears that the stuttering does show as dropped frames in the stats, right?

I've play around with flushing a bit, and indeed what best for this setup now is loop/flush/don't/don't, with the first being sleep will be slightly worse. There is stuttering sometimes, but far and few in-between. I'll keep playing with flushing and other new tweak. Right now I'm on No check/High refresh rate/8/loop/flush/don't/don't
Try enabling the two new tweak options "upload in render thread" and "copy 1 backbuffer". Maybe that helps further improving things? Also try the "aero" timing mode.

Display: 23.999Hz
Composition rate 60.000Hz (clearly wrong)

(3) Aero on
(4) 2560x1600/60Hz + 1920x1080/24p
Why are you using Aero with that setup? Do you get tearing otherwise? Using Aero in this situation is problematic. I think fullscreen exclusive mode should help you.

Well it turns out that the GTX 470 didn't have unique flush settings. Everything is just as smooth with the same settings on my 7800GTX 512.

use managed upload textures=0
flush after intermediate rendering steps=don't flush
flush after final rendering step=flush
flush after copy to backbuffer=flush & wait (loop)
flush after present=flush & wait (loop)
upload frames in render thread=1
copy only 1 backbuffer at a time (instead of 2)=1
timing model=high refresh rate
no of backbuffers=8

General Comments

The copy only 1 backbuffer at a time (instead of 2) setting doesn't appear to make any noticeable difference, but I've left it enabled for the time being, since you've made it a default.

The upload frames in render thread setting doesn't appear to make any noticeable difference, but I've left it enabled for the time being, since you've made it a default.

The timing models high refresh rate and normal appear to behave identically. On WinXP, Aero mode is slightly worse. Since I assume high refresh rate mode is theoretically better at high refresh rates, I'll continue using that mode.

The no of backbuffers set to 1 appears to behave identically to it being set to 8. I've left it at 8, since I assume it should improve present stability.
Interesting. Maybe these tweaks only show affect with really slow GPUs (like my integrated NVidia 9400)? Anyway. You reported earlier that you'd have a delayed frame once in a while. Do you still have that with v0.21 with the settings above?

You said you'd be able to test with a Radeon 5xxx soon. Could you please check whether the v0.19 special Aero rendering mode works better with 5xxx than anything you can achieve with v0.21? If so, I guess I might reintroduce the Aero special rendering mode, because that would make you the 2nd person needing that option (in addition to Hypernova). Please with Aero compare the "aero" and "high refresh rate" timing modes. They should behave pretty differently, at least they do on my PC. Thanks.

Bug
Either the OSD stats are broken or the no of backbuffers setting is broken.

If you set the no of backbuffers to 4, 5, 6, 7, or 8, the OSD stats remain at 2-3/3. Bug.

Yet if you reduce the no of backbuffers to say 1, the OSD stats will reflect the change and show 0-1/1. No bug.

In other words, assuming the OSD stats are correct, the maximum number of backbuffers are never being set above 3.
XP only supports up to 3 backbuffers. Only Vista/7 allow more (up to 30, in theory)
nevcairiel is right.

[cyberbeing]

Anyway. You reported earlier that you'd have a delayed frame once in a while. Do you still have that with v0.21 with the settings above?
I'll have to get back to you on that in a few days.

You said you'd be able to test with a Radeon 5xxx soon. Could you please check whether the v0.19 special Aero rendering mode works better with 5xxx than anything you can achieve with v0.21? If so, I guess I might reintroduce the Aero special rendering mode, because that would make you the 2nd person needing that option (in addition to Hypernova). Please with Aero compare the "aero" and "high refresh rate" timing modes. They should behave pretty differently, at least they do on my PC. Thanks.
Will do. The 5750 should arrive in about 12 hours, but I probably won't be able to do any real testing until the next day.

I guess I should also test the 0.19 special aero path with my 7800GTX 512 as well. I have yet to do any Win7 testing with this GPU and madVR.

nevcairiel is right.
For some reason I was thinking that setting was similar to the max pre-rendered frames vsync setting within the NVIDIA drivers, which defaults to 3 and has a maximum of 8.
So I guess the number of backbuffers setting controls something completely different and I should just be setting it to 3 within madVR when using WinXP?
http://img10.imageshack.us/img10/7618/maxprerendered.png

[leeperry]

So I guess the number of backbuffers setting controls something completely different and I should just be setting it to 3 within madVR when using WinXP?
yeah, is that a good idea to mess w/ those settings?

like: http://img52.imageshack.us/img52/2245/kmp3d.png

Haali thought it was better to leave it as is and let HR do its thing...forcing 16X AF would make it stutter like hell sometimes IME.

[madshi]

I guess I should also test the 0.19 special aero path with my 7800GTX 512 as well. I have yet to do any Win7 testing with this GPU and madVR.
It would be interesting. But if your tests with the Radeon already clarify the situation then it might not be necessary to retest with the 7800GTX. I mean I wouldn't mind (at all) to hear the test results, but I don't really want to burden you with too many time consuming tests...

For some reason I was thinking that setting was similar to the max pre-rendered frames vsync setting within the NVIDIA drivers, which defaults to 3 and has a maximum of 8.
So I guess the number of backbuffers setting controls something completely different and I should just be setting it to 3 within madVR when using WinXP?
The setting defines the number of DirectX backbuffers used by madVR. Since XP only supports 3 backbuffers, setting madVR to anything between 3 and 8 will give 100% identical results on XP. There's no need to manually set it to 3, but it doesn't harm, either.

Don't know what that NVidia driver settings does.

[madshi]

yeah, is that a good idea to mess w/ those settings?
I don't think tweaking those settings will bring any benefit. It might be possible misconfigure these settings, though. In that case you should "tweak" these settings in that way that you remove the misconfiguration. But don't ask me which settings should be set how. I'd stick with the default settings.

[Hypernova]

Ah, so it appears that the stuttering does show as dropped frames in the stats, right?

I think so. I can't say for sure since as soon as I activate the OSD the global stutter disappear.

Try enabling the two new tweak options "upload in render thread" and "copy 1 backbuffer". Maybe that helps further improving things? Also try the "aero" timing mode.

Aero timing mode make things worse. It introduces more stuttering even after the global stutter is gone. The two new tweak options also seems to make things worse, which is why I deactivated them. I have to test it again though.

Why are you using Aero with that setup? Do you get tearing otherwise? Using Aero in this situation is problematic. I think fullscreen exclusive mode should help you.


I do get tearing when Aero is off, but bigger reason is really for testing. When I actually sit down and watch something for real, I use Sync renderer with exclusive mode for now. Switching to a single monitor is not good for me since sometimes it messed up my applications' Windows position/size on the main display when I switch back since it got a bigger resolution.

As I report before, exclusive mode in seems to get rid of this problem completely, so I'm waiting for that one too. I will however keep reporting what I found on this setup unless you don't need it. After that OSD trick it's actually very close to smooth, with only a few drop frame once in a while, so I still have hope. Please let me know if you're not interest in making this kind of setup work though. :cool:

[makakam]

Quote:
Originally Posted by makakam
I get dropped and delayed frames in m2ts files only. In other formats everything is perfect. Is it only me?
I use TV LCD(single display), aero ON, reclock, and my GPU is rather good ATI 5770

Does that happen with both h264 and VC-1 m2ts files? Which splitter are you using? Try switching between MPC HC internal splitter and Haali. Also try all the "windowed mode tweak" options in the madVR settings dialog. E.g. try turning off all the flushes. And try switching to "aero" timing mode.

I only have H264 m2ts files and it happens with mpc hc internal splitter and Haali. I tried windowed mode tweaks and turning off all the flushes and switching aero timing mode but it stays the same, well maybe it's slightly postponed

[Shii]

Trying latest madVR. MPC-HC and ZP freezes at start when I select 1080i mode at my TV. With 720p mode video plays fine. Changing madVR options did not help.

Tested with CoreAVC 2.0 and MPC Video decoder. Same results.

Windows 7 Ultimate 32bit
AMD 64 X2 3800
A8N-E
2Gb RAM
GeForce 9600 GT 512Mb

[cyberbeing]

Well I did a bit of testing tonight with the new Core i5-750, ATI 5750 computer. All I can say is that there is no major stuttering and Aero is actually quite smooth. The special Aero path seems broken with this ATI card, with madVR's display refresh rate calculation jumping around to random values above the actually refresh rate. Likely because of this, the special Aero path is worse then just plain Aero.

Yet there are still way too many unknown variables. FFDshow vs CoreAVC. AMD X2 vs Core i5. ATI vs NVIDIA. I would assume it's the ATI card that just behaves better in Aero then the NVIDIA cards, but that is just speculation.

It seems I'll need to do some testing with the 7800GTX 512 + AMD X2 on Win7 and see if I get the same behavior with the special aero path as the GTX 470. If I do, I guess I'll plop in the ATI 5750 in my AMD X2 PC to detirmine once and for all if this is an ATI vs NVIDIA thing or an AMD CPU vs Intel CPU thing.

__________
On a completely unrelated rant, Catalyst Control Center 10.6 is utterly horrible. If I connect my 2048x1536 @85Hz CRT by VGA the CCC only allows me to use a single resolution. The 5:4 aspect ratio 1280x1024 @60Hz! Since you know that is such a great resolution on a 4:3 aspect ratio, high resolution, high refresh rate CRT :rolleyes:. What crap is that. If I instead hook it up by BNC, it only gives me resolutions with a max refresh rate of 60Hz up to 1920x1080... The only way I was able to test 1600x1200 @96Hz was by finding a way to trick the buggy CCC into behaving how it should. If I first connect by VGA, have CCC detect the monitor, then quickly connect the BNC and detect the monitor again, then CCC decides to give me every resolution under the sun up to 2048x1536 @ 160Hz. Success? Only short-lived. The problem is that everything reverts to the prior 60Hz max, broken behavior after reboot. :mad: This crap has now reminded me why I swore 10 years ago to never buy an ATI card again because of their horrible drivers. Luckily this PC was built for someone else, and it'll only be connected to a 60Hz LCD.

Please don't let me derail this thread, but if someone using a CRT over VGA or BNC with their ATI 5000 series has experienced similar problems and knows how to fix it, I'm all ears.

[starla]

Well, audio/video clock drift can be slow or fast, but the drift should usually be more or less constant. So if madVR is able to achieve smooth video playback for 45 minutes, I don't really see why it shouldn't be possible to drop/repeat a frame (if necessary) after 45 minutes and then go back to show smooth motion for another 45 minutes. If the audio/video drift is too strong, madVR shouldn't even be able to achieve smooth playback for 5 minutes.

Or in other words: If audio/video clocks don't match, madVR will be forced to drop (or repeat, depending on which clock is faster than which) a frame in specific intervals. But between these specific drop/repeat intervals, madVR should provide smooth playback.

Problem might appear when the EVR mixer schedules the samples to be presented to close to the v-sync and the EVR presenter then schedules the frames on "both sides of the correct v-sync". Such could happen at least with 1:2 / 1:3 material where every second (or third) v-sync should receive new frame.

It would require some extra logic (hysteresis control) at least from the EVR presenter to be able to pull or push the frames to happen on the correct v-sync period (as scheduling is not 100% accurate and rendering a frame might take +/- few ns it the presentation target can start to jump between different v-sync intervals and it could cause long lasting juddering when A/V clocks have caused the presentation position to drift too close to the actual v-sync).

Since the renderer is closed source I can just make some educated guesses based on peoples reports and your comments :)

[madshi]

Aero timing mode make things worse. It introduces more stuttering even after the global stutter is gone. The two new tweak options also seems to make things worse, which is why I deactivated them. I have to test it again though.
Yeah, please test the other new tweak options separately. Thanks.

As I report before, exclusive mode in seems to get rid of this problem completely, so I'm waiting for that one too. I will however keep reporting what I found on this setup unless you don't need it. After that OSD trick it's actually very close to smooth, with only a few drop frame once in a while, so I still have hope. Please let me know if you're not interest in making this kind of setup work though. :cool:
To be honest, I'm not really sure how useful your reports are with dual screen Aero. It's clear that Aero is "confused" by your setup, so there are some forces working against smooth playback on your setup and it's hard to say for me who's at fault (Aero or madVR). Furthermore, if I optimize madVR for your setup, it might actually run worse for "proper" setups. On the other hand, if we can get madVR to work well even on bad setups - without any negative side effects on proper setups - why not? So I'm not really sure...

But right now I tend to think that I don't want to invest too much further time into windowed mode. So I'd say let's ignore dual screen Aero setups for now, it's not recommended to use that, anyway.

I only have H264 m2ts files and it happens with mpc hc internal splitter and Haali. I tried windowed mode tweaks and turning off all the flushes and switching aero timing mode but it stays the same, well maybe it's slightly postponed
Is it possible that your CPU is borderline too slow for decoding? You know, when using madVR, the video is not decoded via DXVA, but must be decoded by software. Have you tried different decoders? E.g. try CoreAVC, ffdshow, DivX and DiAVC.

Trying latest madVR. MPC-HC and ZP freezes at start when I select 1080i mode at my TV. With 720p mode video plays fine. Changing madVR options did not help.
Hmmmm... There is a problem sometimes when resizing the media player window before the video starts playing, which can result in a freeze. But other than that, I'm not aware of any startup freeze problems. Can you create & upload a log?

Well I did a bit of testing tonight with the new Core i5-750, ATI 5750 computer. All I can say is that there is no major stuttering and Aero is actually quite smooth. The special Aero path seems broken with this ATI card, with madVR's display refresh rate calculation jumping around to random values above the actually refresh rate. Likely because of this, the special Aero path is worse then just plain Aero.
Interesting. FWIW, Aero seems to work well with my onboard NVidia 9400 and also with my laptop's Radeon X1800.

Yet there are still way too many unknown variables. FFDshow vs CoreAVC. AMD X2 vs Core i5. ATI vs NVIDIA. I would assume it's the ATI card that just behaves better in Aero then the NVIDIA cards, but that is just speculation.
FWIW, did you compare special rendering path vs. normal rendering path by using madVR 0.19? Or did you compare special rendering path 0.19 vs. normal rendering path 0.21?

It seems I'll need to do some testing with the 7800GTX 512 + AMD X2 on Win7 and see if I get the same behavior with the special aero path as the GTX 470. If I do, I guess I'll plop in the ATI 5750 in my AMD X2 PC to detirmine once and for all if this is an ATI vs NVIDIA thing or an AMD CPU vs Intel CPU thing.
Of course this all may also be related to the high refresh rate you're using. Not sure if Aero was really intended to be used for such high refresh rates? Maybe ATI's driver is better optimized for that than NVidias, when using Aero?

Problem might appear when the EVR mixer schedules the samples to be presented to close to the v-sync and the EVR presenter then schedules the frames on "both sides of the correct v-sync".
madVR does not use EVR at all. madVR behaves like a game, using pure Direct3D. madVR also decides which video frames will be shown at which vsync and the presentation is always done at (nearly) the same scanline. So the problem you're describing does not apply to madVR. Presentation is never done in such a way that it can land on "both sides of the correct v-sync". Of course there can be a bug in madVR's algorithm which decides which frame is shown at which vsync. But so far the logs I've seen look clean.