madVR - high quality video renderer (GPU assisted)

[6233638]

You mean "flush & wait (loop)" works better for you for "after render steps" than the default "flush" setting? In which way does it work better? Can you describe the improvement a bit more detailed, please?
I meant to say that was testing with Lanczos4 which is too slow for my 9400M.

I thought that testing with an algorithm that is too slow for the GPU would help in finding what flush settings are fastest because any improvement is obvious. It would be nice if there was some kind of standard benchmark though.


Did more testing after reading your other posts. It still plays smoother but I didnt noticed the CPU use. Explains why I was getting pops & clicks in the audio.

Dont flush
Flush & wait (sleep)
flush
dont
dont

seems tobe working well.

[ajp_anton]

(About the green bar at the top)

Thanks. But what is your HTPC setup? And especially: What is your decoder and splitter? On a quick check your sample plays fine for me. Whenever there are problems with specific video samples, I always need the decoder and splitter setup.
i7 920
HD 4850
Win 7 x64
MPC-HC 2010
Internal decoder & splitter

I just updated MPC-HC. Previously the green bar was the only problem. Now the video won't start if I start MPC-HC by double-clicking the video. I have to first start the player and then the video. Only with madVR.
Green bar is still there.

[madshi]

madVR 0.17 released

http://madshi.net/madVR.zip

* fixed: problem with very slow NVidia drivers, once again
* improved compatibility with some weird behaving decoders
Hope you guys won't expect 4 new madVR versions every weekend now! :eek:

[brokenmind]

thanks a lot for the new version...

GPU: ATI Radeon HD3650
OS: Win7 Ultimate x32
Aero: off
Player: Zoom Player + Reclock (vsync off)
Display resolution + refresh rate:
- 1st monitor: LCD 1280x1024 @ 75Hz
- 2nd monitor: (extended desktop) LCD-TV 1280x720 @ 50Hz

[...] Playback in ZP will not start ... video stays at 00:00, ZP shows a black screen [...]
If I then try to press stop after like 5 minutes of waiting for the video to appear, ZP sometimes becomes unresponsive.


I too see the problem of starting playback with ZP but I can hunt it down to windowed mode only. If playback is started from fullscreen (and player started prior to hitting 'play') everything seem to work out....

anyway, playback seems much smother now - especially no more stuttering (as with v0.13) on second screen with content beeing played at a not exact multiple of refresh rate.
seeking also improved, however, I find random hangs when trying to open several files in a row or windowed mode, but not constantly reproducible yet..
this is with default settings, I still have to do some more testing...

edit: *damn* this report is with v0.16 ... you are indeed too fast madshi.... :)

[ajp_anton]

All problems fixed. Thanks! =)
The only "issue" is that when switching between windowed and FS, the AR change with the black bars is a little slow (screen and video have different ARs). Started a few versions ago...

[kostik]

THANKSSS:) works great

[Razoola]

thanks for new release, no problems to report so far.

[leeperry]

so far I still prefer 0.16 over 0.17...going FS>windowed is a bit laggy now(it's so amazingly smooth in 0.16) and it seems to lose the AR somehow during the transition, and it doesn't look as smooth as 0.16 from what I can see :o

But I'll run more tests.

[madshi]

so far I still prefer 0.16 over 0.17...going FS>windowed is a bit laggy now(it's so amazingly smooth in 0.16) and it seems to lose the AR somehow during the transition, and it doesn't look as smooth as 0.16 from what I can see :o
I've not changed that much between 0.16 and 0.17. Most changes are related to better decoder support (green lines, distorted image, crashes etc). I don't really see which of my changes could result in the problems you're reporting. In theory 0.17 should behave no different in terms of smoothness and FS>windowed switching compared to 0.16.

[leeperry]

I've not changed that much between 0.16 and 0.17. Most changes are related to better decoder support (green lines, distorted image, crashes etc). I don't really see which of my changes could result in the problems you're reporting. In theory 0.17 should behave no different in terms of smoothness and FS>windowed switching compared to 0.16.
I've compared them many times, going FS>windowed is smoother in 0.16 and getting buttersmooth video seems far easier w/ Reclock...I have to reseek many more times in 0.17, 0.16 is so effortless :)

[Thunderbolt8]

im not entirely sure, but could it be possible that madVR sometimes produces a very thin line at the top of the picture, right below the black bars? (e.g. with AR 2.35)? had this minor kind of irritation as can be seen on the US BD of minority report which was not present with EVR any more.

madVR017 left, EVR, right

http://thumbnails24.imagebam.com/8352/da2d5083514118.gif (http://www.imagebam.com/image/da2d5083514118) http://thumbnails8.imagebam.com/8352/8a346883514121.gif (http://www.imagebam.com/image/8a346883514121)


not exactly same frame, but doesnt need to be, as it is present throughout the whole scene.

[nlnl]

Mpc HC (Haali mkv spliter) + ATI 5400 (10.5) + Vista 32 + Aero on + 0.17 + monitor 1080p@23 (single)

No freezing when starting playback!!!
Thank you Madshi very much!
Very very smooth!

[ryrynz]

No fullscreen lag here with 0.17 on a Radeon 4890 and Radeon 4850 running windows 7, operating exactly as they did with 0.16. I have macrovision fail with 0.17 with R4 DVDs of Snakes On A Plane and Gladiator and perhaps many others.

[madshi]

I've compared them many times, going FS>windowed is smoother in 0.16 and getting buttersmooth video seems far easier w/ Reclock...I have to reseek many more times in 0.17, 0.16 is so effortless :)
I've just again compared the sources between 0.16 and 0.17, and I don't see how there can be a difference...

im not entirely sure, but could it be possible that madVR sometimes produces a very thin line at the top of the picture, right below the black bars?
That depends on the scaling algorithm. If you scale by using Lanczos, you'll get that kind of ringing artifact. If it bothers you, use a different scaling algorithm. E.g. Mitchell shouldn't ring (much). It's not as sharp as Lanczos, though.

No freezing when starting playback!!!
Thank you Madshi very much!
Very very smooth!
Glad to hear that!

I have macrovision fail with 0.17
That's a known problem, haven't had time to look into that yet.

[6233638]

Hope you guys won't expect 4 new madVR versions every weekend now! :eek:One is fine. ;) Seems to be working well so far.

Maybe the numbers are wrong, but:
dont flush
flush & wait (sleep)
flush
dont flush
dont flush

Shows the best times for me in the HUD compared to the default if they're right.

[Grafisher]

Your GPU is *painfully* slow with reporting scanline information. I'll have this worked around in the next build. But I'm not happy about NVidia drivers being so bad in this aspect.

Works fine in 0.17. Thanks a bunch!

[janos666]

Woow. It is interesting. I wrote it earlier that I could not see any changes when I disabled the default GPU flushing settings. And I still didn't noticed anything when I randomly played with these options.
Now, I set everything to "flush and wait (loop)" in v0.17 and it feels like I have a display at 72/96/120Hz or I applied some FRC filter with motion interpolation. (I played with some AviSynth plugins but they never worked well enough.)

I can not see any significant increase in CPU load, core0 isn't peaks at 100% and the overall load is ~25% (with 1080p24 source). GPU load is negligible (it shows 0% with some little peaks around 8% but my GPU clocks are always peaks at 775Mhz now - not a real problem for me, I have passive water cooling...)
Other settings: 3DLUT enabled (with gamut correction only), Spline64 resize (all 3), everything else unchecked.
Software: Windows 7 x64, MPC-HC 1.3.1906.0, FFDShow 3463 (custom icl11 build) without any filters (expect subtitle renderer), madVR 0.17
Hardware: HD5850 with 8.74 beta driver (more than 2 month old, but this is the latest leaked build at this time), Q6600 @ 3600Mhz, DVI attached monitor at 1920x1200@60Hz

I won't care about 72/96/120 Hz support anymore. (At least until I will be brainwashed that I need an LCD shutter glass and 3D - not until we get some PC monitor with IPS panel at 120Hz with a reasonable price. So, not in the "not so far as you think future". :cool:)

It is very funny if I think about the fact that it should have been working like this from the very beginning (but, at least with Vista and EVR...).

If you would remove these settings from the control panel then leave the switches in the settings.ini

[Hypernova]

Update: I take that(below) back. The play&pause only solve the problem for only 3-5 seconds. After that, it stutter again.

I don't know if this is different from 0.16, but with 0.17, it is possible to get no stuttering with only "flush & wait (sleep)" for "after render steps" as oppose to (loop) in my setup (don't flush on anything else). The thing that mess it up is when I skip around the file. Most of the time this will introduce stuttering, but can be eliminated by pause and then play again. If I use loop, there is no need for this. I would say I prefer to have the loop option though. Even after pause&play, it seems like this still is a little bit of stuttering, but I might just seeing things there.

Hope this sounds good. Thanks again for great release, madshi.

Info:
(1) ATi 3870 with 512mb ram
(2) Windows Server 2008 R2
(3) Aero on
(4) 2560x1600 + 60Hz (madVR stat say ~59.80).
(5) Single monitor setup.

[iSeries]

Is there a way to restore all the settings to default? I messed around with the flush settings so much I can't remember what the defaults were!

[LoRd_MuldeR]

Is there a way to restore all the settings to default? I messed around with the flush settings so much I can't remember what the defaults were!

Simply delete the "settings.ini" from your MadVR folder. Anyway, a "reset to defaults" button would be handy!

[janos666]

Is there a way to restore all the settings to default? I messed around with the flush settings so much I can't remember what the defaults were!

Delete the settings.ini file in your madVR install directory.

Did you try to set everything to "flush and wait (loop)"?

[iSeries]

Cheers janos666 - actually I've tried every combination. With the defaults it was mostly smooth but every now and again there'd be a stutter where it would drop a couple of frames. After trying all the settings it turns out the best settings for me is to set everything to 'Dont Flush'. I just watched an hour of a 1080p movie with the OSD on the screen and got 0 dropped frames (ATI 4550, W7, Aero off). Very happy :)

[6233638]

Cheers janos666 - actually I've tried every combination. With the defaults it was mostly smooth but every now and again there'd be a stutter where it would drop a couple of frames. After trying all the settings it turns out the best settings for me is to set everything to 'Dont Flush'. I just watched an hour of a 1080p movie with the OSD on the screen and got 0 dropped frames (ATI 4550, W7, Aero off). Very happy :)
Dropped frames are not a reliable indicator for smooth playback. If you have dropped frames theres obviously a problem but I can get non-smooth playback and 0 dropped frames depending on setup.

[pankov]

madshi,
I have to agree with 6233638
I was thinking about requesting one more indicator in the OSD - "repeated frames". I'm not exactly sure if it's possible to have meaningful indicator showing the repeated frames having in mind all the possible variations of the display refresh rate but I guess if you are able to add such an indicator we'll be able to objectively measure the "smoothness" of the playback. After all if there are no dropped frames and no repeated frames we have perfect playback, right?

[leeperry]

I set everything to "flush and wait (loop)" in v0.17 and it feels like I have a display at 72/96/120Hz or I applied some FRC filter with motion interpolation.
indeed, enabling them all to "flush and wait (loop)" looks really impressive! I'm not quite sure what to expect from those options tbh? is it supposed to be laggy w/ or w/o them? how to find the "best" combination? there's 5 options w/ 4 possible settings, that's a hell lot of combinations :devil:
I will re-read the technical details about those.

anyway it's a power-user VR, and it seems impossible to find a "unique" setup that does wonders on XP/W7 and nvidia/ATi, I hope madshi will keep all those settings...maybe by adding an "advanced" tab in the new GUI so newbies don't go overboard. One thing's for sure the "texture upload" option does wonders on my XP SP3/96SP 8800GS/197.77 forceware/Reclock/KMP/CoreAVC CUDA box!

BTW, I've got "combined writing" disabled in the XP graphic card config...I'll try to reenable it.

PS: Also, it never really worked to assign CTRL+J on one of my logitech wireless mouse buttons(tried again today)...sometimes I can make it appear but not disappear, but most of the times nothing happens. It worked perfectly w/ HR :o

[cyberbeing]

I did some more testing.

For a bare minimum configuration I need to use the following in order to not get tearing:
http://img52.imageshack.us/img52/3261/madvr17notear.png
Without After last step at least to "flush", I get very severe screen tearing.

The above isn't all that smooth, but adding Flush & Wait (loop) for both After backbuffer and After present in parallel (no apparent positive effect used individually), seems to make smoothness near-perfect.

As an added bonus, when used in parallel it reduces my present times by 25% with a 120Hz display refresh rate. The lower you set the refresh rate, the smaller the improvement in present times get, and eventually it starts increasing present times. Maybe you could explain to me why this is.

http://img132.imageshack.us/img132/8965/madvr17smooth.png

The more I test the more I'm beginning to believe that in order to get perfect smoothness you need both of the following to be true:

render time (avg) < movie frame interval
&
present time (avg) < vsync interval

I also believe that you can get away with max present/render times (5s) being greater than frame/vsync interval above ONLY if the spike lasts less time then it takes madVR to empty its queues. In other words you have 8 frames worth of time (333ms for 24fps) for render and only 3 frames worth of time (31ms for 96hz) for present.

In order to see if this theory is correct, madshi would need to add 'avg render time (over the past 333 milliseconds)' and 'avg present time (over the past 31ms)' to the CTRL+J stats. It would be very interesting to see if there was a stutter exactly when these values exceeded the frame/vsync intervals. Would making these stat changes have too large of a performance hit to make them useful?

I bring this up because I seem to be noticing stuttering whenever I set a windowed mode tweak which causes present time to be greater than vsync interval. Same goes for resize settings where I would get stuttering if they cause render time to be greater than movie frame interval (when stats are being reported correctly with After last step Flush & Wait of course). This began to make me wonder if the setting was at fault or if the present time increase was actually what was causing the issues.


BUGs
With madVR 0.17 I began getting MPC-HC hangs a lot of the time when opening a video, once again. Reclock has only detected the frame rate with no video resolution when the hang has occurred.

No matter what settings I use with madVR, I still seem to be getting the occasional 1 dropped frame here and there. Did you have any more thoughts about re-adding delayed frames? As I mentioned previously, it would be much preferred to have a delayed frame when using high refresh rates.

Windows XP SP3 x86
AMD X2 4800+ (939) @2.64Ghz (220Mhz x12)
2GB DDR400 @ 440Mhz 2-3-3-6 (1:1 ratio with CPU)
NVIDIA GTX 470 (PCI-E 1.0 w/ x8 link)
1920x1080 @120Hz (CRT Monitor)
MPC-HC w/ Reclock (100ms Pre-Buffer)
CoreAVC (Software mode), FFDshow Audio, VSFilter, Haali Media Splitter

[Razoola]

BUGs
With madVR 0.17 I began getting MPC-HC hangs a lot of the time when opening a video, once again. Reclock has only detected the frame rate with no video resolution when the hang has occurred.

I can confirm this (identical hang with reclock reporting no video frames found). I have had two hangs also from about seven starts. I have also had the MPC-HC task not closing down correctly once.

[Hypernova]

indeed, enabling them all to "flush and wait (loop)" looks really impressive! I'm not quite sure what to expect from those options tbh? is it supposed to be laggy w/ or w/o them? how to find the "best" combination? there's 5 options w/ 4 possible settings, that's a hell lot of combinations :devil:
I will re-read the technical details about those.


From madshi's replies, I think the loop option is the best one in term of chance to get smoothness if you need flushing, but you'll waste a lot of CPU cycles (and power, I think). Setting every choice to loop seems to be the best for me too, but the minimum is "after render steps"

[namaiki]

IMO what we're trying to do is find a default list of flush settings that will produce smooth playback on any PC. (if that is at all possible)

So, all flushes off would be ruled out as some people have had issues with it.

Could someone give me bad news(try it and say that it produces stutter for you or the like) in regards to:
"After render steps: flush and wait (sleep) (yes, loop will produce stutter)
after last step: flush"
which is the only combination that I know of that works on my PC (changing any one of the two above options will produce stuttering or lag).

[Hypernova]

IMO what we're trying to do is find a default list of flush settings that will produce smooth playback on any PC. (if that is at all possible)

So, all flushes off would be ruled out as some people have had issues with it.

Could someone give me bad news(try it and say that it produces stutter for you or the like) in regards to:
"After render steps: flush and wait (sleep) (yes, loop will produce stutter)
after last step: flush"
which is the only combination (nothing else works at all) that works on my PC (changing any one of the two options will produce stuttering or lag).

Yes it does give me stuttering. As I mentioned in my post, I need loop in "after render steps". Sleep will give a smooth playback for 3-5 seconds after pause&play, then it will stutter.

Info:
(1) ATi 3870 with 512mb ram
(2) Windows Server 2008 R2
(3) Aero on
(4) 2560x1600 + 60Hz (madVR stat say ~59.80).
(5) Single monitor setup.

[namaiki]

Do you have "flush" set for "after last step" as well as "After render steps: flush and wait (sleep)" set?

You said that you have all other flushes off.

ie:
me
after render steps: flush and wait|sleep
after last step: flush
after backbuffer: don't flush
before present: don't flush
after present: don't flush

you
after render steps: flush and wait|sleep
after last step: don't flush
after backbuffer: don't flush
before present: don't flush
after present: don't flush

[Hypernova]

Do you have "flush" set for "after last step"?

Yes, I do.

[namaiki]

Well, that's my dream gone. :P

If I set after render steps: flush and wait|loop, I get stutter.


Appreciate it, for you trying this out right now.

[JarrettH]

I'm getting pretty serious switching lag between full screen, windowed, and seeking also; often several seconds or it just becomes a slideshow at random. I remember being much more content with 0.12 and 0.13 before all this flushing stuff came about. I hope we find some fast settings and resolve this soon :)

Core 2 Duo E6600
2GB DDR3
7600GT 256MB DDR3, 197.45 drivers
MPC-HC (last official, I haven't tried any beta releases)

I run the combination of Mitchell-Netravali (Luma Upscaling) and SoftCubic50 (Chroma Resampling)

I'm trying namaiki's flush & wait (sleep), flush, don't, don't, don't...back a few pages. Seems to work better than the defaults, I don't want to comment on what setting is better than another (besides madvr defaults). Is all this for ReClock? Personally I have no interest in it and I can just see these five options becoming some obsession now that they exist.

[namaiki]

Hypernova and others, could you please try:

after render steps: flush and wait|sleep
after last step: flush
after backbuffer: flush
before present: flush
after present: flush

On my setup it seems that the bottom three options can be set to don't flush or flush (individually and with all is fine).

Please try setting the bottom three options individually and in combination to flush and see if it will remove the stuttering.
Please to do testing with the OSD off and on.

[madshi]

The above isn't all that smooth, but adding Flush & Wait (loop) for both After backbuffer and After present in parallel (no apparent positive effect used individually), seems to make smoothness near-perfect.
Which means that I will probably not be able to remove the flush options, because it seems that everybody needs different settings... :(

Can everybody please test whether the flush option "Before present" does any good? If not, maybe I can at least remove that one.

The more I test the more I'm beginning to believe that in order to get perfect smoothness you need both of the following to be true:

render time (avg) < movie frame interval
&
present time (avg) < vsync interval

I also believe that you can get away with max present/render times (5s) being greater than frame/vsync interval above ONLY if the spike lasts less time then it takes madVR to empty its queues. In other words you have 8 frames worth of time (333ms for 24fps) for render and only 3 frames worth of time (31ms for 24fps) for present.
Yes, I would agree with your thoughts here. 3 frames worth of time are 125ms, though.

In order to see if this theory is correct, madshi would need to add 'avg render time (over the past 333 milliseconds)' and 'avg present time (over the past 31ms)' to the CTRL+J stats.
The OSD currently only updates once per second. So such stats wouldn't be useful, unless I updated the OSD much more often (which costs performance). I also doubt that your eyes/brain work fast enough to follow 8 OSD updates for "avg present time (over the past 125ms)" per second. Or am I misunderstanding your request?

I bring this up because I seem to be noticing stuttering whenever I set a windowed mode tweak which causes present time to be greater than vsync interval.
Present times are not expected to be bigger than the vsync interval. madVR asks Direct3D to present a frame a bit less than 1 vsync before the scheduled time. Which means that if present times are higher than the vsync interval then Direct3D sometimes skips a vsync against the will of madVR. I think this will happen if Direct3D is still blocked by rendering, while it wants to present.

All this trouble will be gone in fullscreen exclusive mode. The only problem that will exist in that mode is that stuttering will happen if rendering speed simply can't keep up at all.

BUGs
With madVR 0.17 I began getting MPC-HC hangs a lot of the time when opening a video, once again. Reclock has only detected the frame rate with no video resolution when the hang has occurred.
I don't seem to get this here. Can you try to find out the circumstances under which it occurs most often? Maybe it's specific kinds of video files? Maybe it only occurs with Reclock enabled (I have it disabled in the moment)? Etc...

No matter what settings I use with madVR, I still seem to be getting the occasional 1 dropped frame here and there. Did you have any more thoughts about re-adding delayed frames? As I mentioned previously, it would be much preferred to have a delayed frame when using high refresh rates.
I have on my to do list to consider reimplementing delayed frames. But to be honest, I'm so sick of windowed mode. I finally want to move on to write special rendering paths for Aero and fullscreen exclusive mode, which are expected to be much less sensitive compared to windowed mode.

I'm getting pretty serious switching lag between full screen, windowed, and seeking also; often several seconds or it just becomes a slideshow at random. I remember being much more content with 0.12 and 0.13 before all this flushing stuff came about. I hope we find some fast settings and resolve this soon :)
The flushing options aren't responsible for switching lags and such kind of bugs. These bugs must be caused by something else.

Core 2 Duo E6600
2GB DDR3
7600GT 256MB DDR3, 197.45 drivers
MPC-HC (last official, I haven't tried any beta releases)
OS? Aero on/off?

Can you please create a log for me which shows the switching lag between fullscreen <-> windowed? In order to do this, simply close MPC-HC, then rename madVR.ax to something else and "madVR [debug].ax" to "madVR.ax". Then open MPC-HC, try to reproduce the problem. If you were able to reproduce it, stop MPC-HC at once (without doing another fullscreen <-> windowed switch!!) and zip & upload the file "yourDesktop\madVR - log.txt". If you are not able to reproduce it on the first try, please stop MPC-HC again, delete the log file and try again. It would be nice if you could try to keep the log file as small as possible. Which means the quicker (after video playback start) you can reproduce the problem, the better for me.

[namaiki]

I'm trying namaiki's flush & wait (sleep), flush, don't, don't, don't...back a few pages. Seems to work better than the defaults, I don't want to comment on what setting is better than another (besides madvr defaults). Is all this for ReClock? Personally I have no interest in it and I can just see these five options becoming some obsession now that they exist.

Well, I could not play 60fps video without immense lag in the previous madvr versions and same for the current version until I accidentally stumbled upon the two options and there no longer was lag. As such, it's been the best thing since sliced bread for me.(from a performance point of view?)

FWIW, I don't even know the difference between jitter and judder (though I can notice repeated frames every 5 frames or so, and I can notice stuttering) and the refresh rate of my screen isn't even matched to my video.


...but I do have Reclock running at default settings + WASAPI.

[JarrettH]

I'm using Windows 7 Pro 32-bit and Aero, yup
also ffdshow ICL10 rev3316 with ffmpeg-mt

Into the Universe - Stephen Hawking (2 of 3), 720p
http://www.megaupload.com/?d=Y89DRWS4

I started the clip, double-clicked to full, double-clicked to windowed, paused once the lag was gone and closed MPC-HC

Ran, 720p
http://www.megaupload.com/?d=1XX2LRD1

I started the clip, skipped to a random part in the movie, double-clicked to full, double-clicked to windowed, paused once the lag was gone and closed MPC-HC

I hope these are useful for you and that you continue with three releases per weekend :D

[Luv]

Huge thanks for this superb software,Madshi ! The progresses have been incredible lately !

So:
XP SP3
x2 4200+
HD 4770,10.2
Zoomplayer 5.02
Haali 1.7.401.3 (07/12,that's right)
1280*1024@85 Hz CRT
Latest DirectX (10/02)

Using version 0.17,all flushing disabled,3dlut activated.
x264 1080p and 720p smooth as butter,windowing stuttering is gone (Still,I loose a few frames when I open a mkv.Normal ? But tolerable for me since I can't see any kind of corruption...)

Now the big problem is the dvds.Very little work :black screen but sound and I can't recover= I have to kill the zp process.
Madshi,I have to say that I have 100 % success with the Haali renderer.
Other pbs same symptoms and full success with the Haali renderer:
-divx in .avi doesn't work,
-avc in .m2ts doesn't work (But mpeg2 and vc1 using the Ms WMP11 decoder in .m2ts works and the quality is plain fantastic !)
What's you splitter for zp,Madshi and wich version of zp are you using,please ? Does it have an incidence because I remember somebody from Inmatrix mentioning on this thread that madVR was now supported in zp 6.00.What did he mean ?

[JarrettH]

Nevermind...I can't suggest switching to EVR because you are on XP :p

[iSeries]

@ 6233638 - I'm not completely simple, I watched the movie too. I think I would have noticed any problems. Next you'll be telling me Santa doesn't exist :)

[cyberbeing]

(31ms for 24fps) for present.Yes, I would agree with your thoughts here. 3 frames worth of time are 125ms, though.
I was actually thinking it would be vsync interval x3, which was ~31ms for 96Hz or ~25ms for 120Hz. I mistyped when I wrote 24fps, in that post it should have been (31ms for 96Hz).

Is it incorrect to think the Backbuffer queue gets emptied every by 1 every Vsync Interval?


The OSD currently only updates once per second. So such stats wouldn't be useful, unless I updated the OSD much more often (which costs performance). I also doubt that your eyes/brain work fast enough to follow 8 OSD updates for "avg present time (over the past 125ms)" per second. Or am I misunderstanding your request?
You are not misunderstanding, but that is a good point. Your eye would probably noticed a large spike (since present time usual stays quite stable), but making out what it said would indeed be difficult. For it to be useful you would probably need to have the debug build log this information as well. Possibly only being logging it if the value was higher than the Vsync/Frame interval and maybe a total for how many times that happened during playback?

I don't seem to get this here. Can you try to find out the circumstances under which it occurs most often? Maybe it's specific kinds of video files? Maybe it only occurs with Reclock enabled (I have it disabled in the moment)? Etc...
Yeah, I'll need to look into this further as it seems to be somewhat random. Usually it seems to happen with large MKV files. The first thing that comes to mind is that maybe the madVR source filter which is querying the file information is crashing. On that build of madVR which was insta-crashing a few revisions back (which you fixed), the insta-crash appeared to be caused by long file/directory names with multiple files with long names in said directory with a long name. No clue if that is anyway related to this though. I'll have to get back to you when I have more solid info.

Another Bug
Another problem I've noticed is that I get some very minor tearing near the center of the screen, during extremely high motion scenes when resizing 1920x1080 video to 2560x1440 @72Hz. I'm not sure what is causing it, since it even happens with bilinear resizing and 3DLUT disabled.

[Hypernova]

@namaiki,

I didn't do extensive testing. (Start to get sick of my testing file after watching it so many times this weekend :) ) But the last three options really don't do anything for me. Changing them to some flushing seem to only make thing worse if "after render steps" is not the loop. OSD make things even worse.

@madshi,

As I mentioned above, before present doesn't do any good for my setup

Info:
(1) ATi 3870 with 512mb ram
(2) Windows Server 2008 R2
(3) Aero on
(4) 2560x1600 + 60Hz (madVR stat say ~59.80).
(5) Single monitor setup.

[namaiki]

Hypernova:

I didn't do extensive testing. (Start to get sick of my testing file after watching it so many times this weekend :) )
......
My 3 testing files are credits and a promotional video. D:

But the last three options really don't do anything for me.
......
Same for me, unfortunately. At least the number of option combinations for 3 items is quite limited.

OSD make things even worse.
.....
I do all my testing with OSD off as I can't get smooth playback when it is enabled.

Madshi: I have no idea how the presenting frames code works, but could you try make a build with timings slightly tighter?
Like say instead of accepting numbers 22-33 inclusive, it would be accept numbers 23-32 instead.
I can't get 24fps video smooth, but it could be judder, but I don't know.. sometimes there is a bit of a constant jump in the video, but if I seek it will go away.

[leeperry]

sometimes there is a bit of a constant jump in the video, but if I seek it will go away.
most likely due to Reclock and that ole' VSYNC fliptime problem. I think only hardware VSYNC control w/ FS exclusive mode can fix that...and possibly Aero too.

[noee]

Can everybody please test whether the flush option "Before present" does any good? If not, maybe I can at least remove that one.

I see no impact one way or another with this settings options.

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

[namaiki]

I see no improvement when using flush before present, but I do get lag when using flush + wait.

By the way Madshi, did you change what was flushing in v0.12 to v0.13?

[leeperry]

Smoothness is very subjective, and the humain brain is a poor measuring tool :rolleyes: ...yet, I can't seem to be able to detect a diff between having all flush disabled or set to "flush and loop"(the latter slightly increases the CPU load, though). I think they're all equally smooth, I'm only forced to enable the "texture upload" thingie otherwise going FS>windowed is extremely laggy(this time it's not placebo!).

I'm also going to disable "write combining" again(in the XP troubleshoot config) coz I find it to make other apps(windows explorer/IE) laggy when they open for the first time. Basically, if I got it right disabling this option makes sure that XP doesn't flood the video buffer w/ asychronous data. It'd appear to be old useless legacy stuff from the W98 days(it was called "USWC" in old mobo BIOS I think)

3dmark's give the same results whether it's enabled or not. I'm just specifying it because it might be the reason for some of my test results(unchecking "texture upload" and going FS>windowed is still laggy even if it's enabled ;))

[namaiki]

leeperry, try play a video with higher fps and there should be a difference.

[leeperry]

try play a video with higher fps and there should be a difference.
ok, but I only play 23.976/24/25/29.97 videos...I use some heavy Avisynth scripting on all my videos so I really have no use for >29.97fps videos :p

I'll try for troubleshooting sake's, though!