madVR - high quality video renderer (GPU assisted)

[Fer]

What happens when you try use VSFilter 2.39?

Also, could you pretty please try~
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

Finally the VSFilter wors correctly. The problem has been resolved activating autoload VSFilter in the Haali Media Splitter.

With such flush options I have esentially the same good playback behaviour as with the default values. Nevertheless, and this is subjetive, I feel better the default values.


(1) GPU: ATI 2600XT
(2) OS: Windows XP
(3) Movies: 1080p mkv files, 23.976 fps (obtained from blurays with eac3to)
(4) Display resolution + refresh rate: 1920x1080, 23.976 with PowerStrip (I DO NOT use reclock!)
(5) Single monitor setup
(6) MPC Homecinema
(7) Video decoder: ffdshow (AVC: libavcodec, VC1: wmv9)
(8) madVR 0.18


Definitely something goes better in the 0.18 version. With the flush default values now I can manage near perfectly (smooth playback without dropped frames) Chroma resampling even with Lanczos4 and Spline64 (near perfect since I get 2 or 3 dropped frames during about 10 to 15 minutes of playback in some movies). This was not possible at all with the 0.17 versión. I think that with SoftCubic100 now the playback is solid smooth. Well done.

In all cases 0 delayed frames and presentation glitches.
I have observed that with the new version the rendering times has decreased about 3-4 ms.
Although I like SoftCubic100 a lot (natural image), Spline64 is an interesting alternative to certain kind of films.

[Peuj]

Hi mashi,

For knowledge, could give information/explanations about the madVR OSD information?
Like vsync interval, movie frame interval,...

Excepted based on our "impression about motion smoothness", should we have expected values for these information?

Thanks

GPU: nvidia 8600M GT with driver 257.15
OS: Vista
Aero: on
1920x1080 24Hz
Dual monitor PC/TV

[Mark_A_W]

You can always OCR them. You captures are VobSub subtitles, not text subtitles, it's normal that you don't see these issues.






Umm...why on earth would I do that?

It's working perfectly. It's the text based version which you are complaining about.

I'm getting the exact same result as the original movie :rolleyes:


Edit: I watched a movie last night with "normal" text subtitles. Using Zoom Player and VSFilter. They were white only, but they looked just fine.

The whole point of madVR is to NOT accept RGB32 from the decoder. I don't understand your obsession. It's working the way it is now.

[leeperry]

leeperry, please test for the stuttering after a seek.
much harder to reproduce than before, but it is still there: http://www.mediafire.com/file/gwzzrytniyy/madVR%20-%20log.rar

I see that when it'd usually completely miss the VSYNC fliptime, it's freezing a bit(like EVR CP does) now in an attempt not to...so it's less obvious than in 0.17 and also far more subtle, but it's still hiccuping a bit from time to time(in 96Hz) :o

[6233638]

Although I like SoftCubic100 a lot (natural image), Spline64 is an interesting alternative to certain kind of films.Softcubic is the unnatural one, reds and blues have much softer edges than greens using it. Bicubic/spline or maybe mitchell-netravali are much better choices. If you insist on softcubic use 50 but I don't recommend it.

Hmm... Something seems broken with your re-added delayed frame logic.

Playing back a 1920x1080 24fps video at 1920x1080 @120Hz, I'm getting a delayed frame almost exactly every second. 10 seconds = 10 delayed frames. 500 seconds = 500 delayed frames. Etc. Same thing happens no matter what flush settings I use, 3DLut enabled/disabled, dithering enabled/disabled, etc.

The problem occurs with numerous other resolutions above 1920x1080, including 2048x1152 @96Hz & 2560x1440 @72Hz.

The problem does not occur with numerous other resolutions below 1920x1080, including 1600x1200 @96Hz, 1600x900 @120Hz, or 1280x720 @120Hz.

I conclude that it is only happening when 1080p video is being displayed at 1920x1080 or above display resolution. When 1080p video is downscaled to a lower display resolution, the problem does not happen, even with high refresh rates.Does not happen here. 1920x1080, 48Hz gives me 0 dropped/delayed frames/presentation glitches, two whole films tested so far. (one or two dropped frames at the very start of each which I reset)

Maybe check your flush settings or try a less demanding chroma upsampling option.

[JarrettH]

Softcubic is the unnatural one, reds and blues have much softer edges than greens using it. Bicubic/spline or maybe mitchell-netravali are much better choices. If you insist on softcubic use 50 but I don't recommend it.

which scaling setting are you talking about?

what do you guys use anyway? for luma upscaling, i do like Spline36 for videos that benefit from it (high bitrates) and in other cases Mitchell-Netravali (XviD, lower bitrates, won't accentuate film grain as much). for chroma resampling, i'm not so sure what to use!

[cyberbeing]

Hmm... Something seems broken with your re-added delayed frame logic.

Playing back a 1920x1080 24fps video at 1920x1080 @120Hz, I'm getting a delayed frame almost exactly every second. 10 seconds = 10 delayed frames. 500 seconds = 500 delayed frames. Etc. Same thing happens no matter what flush settings I use, 3DLut enabled/disabled, dithering enabled/disabled, etc.

The problem occurs with numerous other resolutions above 1920x1080, including 2048x1152 @96Hz & 2560x1440 @72Hz.

The problem does not occur with numerous other resolutions below 1920x1080, including 1600x1200 @96Hz, 1600x900 @120Hz, or 1280x720 @120Hz.

I conclude that it is only happening when 1080p video is being displayed at 1920x1080 or above display resolution. When 1080p video is downscaled to a lower display resolution, the problem does not happen, even with high refresh rates.Hmmmm... Thanks for the logs, I'll look into them later.

I figured out what was causing the problem. It was the Windows XP /3GB boot.ini switch which I just so happened to have set last night to test something unrelated.

Solution A: Leave the /3GB switch enabled in the boot.ini, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management , and set SystemPages to ffffffff.

Solution B: Remove the /3GB switch from the boot.ini

madshi, now that I found the cause, you'll have to fill me in about how this was causing the delayed frame problem with madVR. I went and tested madVR 0.11 which also had delayed frame code, but it wasn't having the same issue. It must have been introduced along with the massive re-write of your code starting with 0.12. It may still be worth looking into in case there really is a bug in your code related to how madVR handles memory.

In 0.13 you made the following changes:
* changed timing to improve rendering performance
* changed texture allocation to improve rendering performance

Since it was only happening at 1920x1080 and above, how madVR is handling large textures, as it relates to user & kernel memory usage may be where to start looking.

[flanger216]

Umm...why on earth would I do that?

It's working perfectly. It's the text based version which you are complaining about.

I'm getting the exact same result as the original movie :rolleyes:


Edit: I watched a movie last night with "normal" text subtitles. Using Zoom Player and VSFilter. They were white only, but they looked just fine.

The whole point of madVR is to NOT accept RGB32 from the decoder. I don't understand your obsession. It's working the way it is now.

Agreed. I mean, color me crazy, but I'm pretty sure end-all-be-all subtitles and gamut correcting Quake captures are not quite the stated goals of madVR.

Bug reports are useful. Continually insisting on the inclusion of a feature fundamentally in opposition to the basic concept behind the renderer is... not as useful.

[namaiki]

Madshi: I can reproduce the thing with WMV file opening, but black screen and the counter doesn't move and no audio during playback.

Black screen with wmvideo decoder: http://www.mediafire.com/file/gzzmn23zdol/dmo.txt
Normal playback with ffdshow video: http://www.mediafire.com/file/yg1vnjznyom/ffdshow.txt

For both logs, I opened the video and let it play for ~10secs and closed mpc-hc with Alt+F4. If you would me to try anything else, I can post up a new log.

[leeperry]

black screen and the counter doesn't move and no audio during playback.
I also get this problem from time to time, that's essentially when I try to go windowed>FS before the picture even showed up...so now I just wait :D

[madshi]

The graph is created using multiple video decoder instances (one for MPEG2, another for H.264,...) to allow switching channels without having to rebuild the whole graph. I was not aware that multiple renderer instances were running at the same time.
Yeah. Well, only during initialization for a short time, but it's enough to confuse the current madVR version.

i notice very slight stuttering with any settings which is not recognized by madVR's statistics, neither dropped nor delayed frames. EVR and HVR suffer under this too.
What is your display refresh rate and your movie frame rate? There are 2 possible causes for the type of stutter you're describing:

(1) If the display refresh rate is not an even multiple of the source frame rate, you get slight stuttering.
(2) Movie/film is shot with only 24fps. That's a rather low frame rate and introduced some slight stuttering on its own. The only way to fix this would be to do some sort of frame interpolation, which is very hard to do and often introduces artifacts on its own.

Definitely something goes better in the 0.18 version.
Glad to hear that!

For knowledge, could give information/explanations about the madVR OSD information?
Like vsync interval, movie frame interval,...
vsync interval is 1000ms / display refresh rate. Basically its the time between two vsync interrupts.

movie frame interval is 1000ms / movie frame rate. Basically it's the time each movie frame is supposed to be visible on screen.

These 2 values are fixed and depend only on display refresh rate and movie frame rate.

much harder to reproduce than before, but it is still there: http://www.mediafire.com/file/gwzzrytniyy/madVR%20-%20log.rar

I see that when it'd usually completely miss the VSYNC fliptime, it's freezing a bit(like EVR CP does) now in an attempt not to...so it's less obvious than in 0.17 and also far more subtle, but it's still hiccuping a bit from time to time(in 96Hz) :o
Is it the same thing as before? I mean, after a seek, do you get non-smooth playback forever, until you seek again? Do you get delayed or dropped frames when this happens with 0.18?

The logs look clean to me. The logs tell me how long each frame was displayed (in vsyncs). The logs tell me that each and every one of your frames was shown for exactly 4 vsyncs. So motion should have been perfectly smooth. There's no "synchronized blabla" error, according to the logs. FWIW, the 0.17 logs showed that in the non-smooth playback situation, the video frames were sometimes shown for 4 vsyncs, sometimes for 3 vsyncs and sometimes for 5. It was like 4, 4, 3, 5, 4, 4, 3, 5. Of course that was not smooth. This problem appears to be completely fixed in 0.18, at least according to your 0.18 log.

Softcubic is the unnatural one, reds and blues have much softer edges than greens using it. Bicubic/spline or maybe mitchell-netravali are much better choices.
This all heavily depends on the content. In some situations Softcubic looks worse than other resamplers, in other situations it looks better. I would be careful with absolute judgements like "xxx is much better than yyy".

I figured out what was causing the problem. It was the Windows XP /3GB boot.ini switch which I just so happened to have set last night to test something unrelated.
Strange.

madshi, now that I found the cause, you'll have to fill me in about how this was causing the delayed frame problem with madVR.
I've no idea. But the presentation timing in windowed mode is so sensitive that even small things can make problems. That's the big argument for Aero and fullscreen exclusive modes, because they're much more robust.

I went and tested madVR 0.11 which also had delayed frame code, but it wasn't having the same issue. It must have been introduced along with the massive re-write of your code starting with 0.12. It may still be worth looking into in case there really is a bug in your code related to how madVR handles memory.
I don't think it has anything to do with memory. It probably has to do with some changes I did to the timing code. I had to do some changes to improve playback with Aero and especially to get rid of tearing with 24Hz. These changes might have made things more sensitive for high refresh rates. I'll add a special timing tweak for high refresh rates to the next build...

Anyway, since you got the problem fixed, what is your judgement about the improved "flush & wait (sleep)"? Does it work just as fine as "loop" for you now? I'd like to get rid of the "loop" option. And how does 0.18 compare to 0.17? You told me that with 0.17 you still had a dropped frame once in a while. Does that still happen with 0.18? Or do you get a delayed frame once in a while now? Is it a visible improvement?

Madshi: I can reproduce the thing with WMV file opening, but black screen and the counter doesn't move and no audio during playback.
Hmmmm... Must be win7 related. Will try it out in win7.

[leeperry]

Is it the same thing as before? I mean, after a seek, do you get non-smooth playback forever, until you seek again? Do you get delayed or dropped frames when this happens with 0.18?

The logs look clean to me. The logs tell me how long each frame was displayed (in vsyncs). The logs tell me that each and every one of your frames was shown for exactly 4 vsyncs. So motion should have been perfectly smooth. There's no "synchronized blabla" error, according to the logs. FWIW, the 0.17 logs showed that in the non-smooth playback situation, the video frames were sometimes shown for 4 vsyncs, sometimes for 3 vsyncs and sometimes for 5. It was like 4, 4, 3, 5, 4, 4, 3, 5. Of course that was not smooth. This problem appears to be completely fixed in 0.18, at least according to your 0.18 log.
Yes, same as before but far more subtle...the hiccup was unbearable in 0.17(exactly as you're explaining it). When I tried in 0.18 it was still there, but far less "jittery".

OK logs look fine humm, I'll try again..

I'll try to make a log w/ this problem too: http://forum.doom9.org/showpost.php?p=1407152&postcount=3169

[cyberbeing]

The following are the only flush settings which increase madVR's CPU usage on my system:

After Render Steps
Flush.........................+10-16% madVR CPU Usage
Flush & Wait (Loop)......+10-16% madVR CPU Usage

After Last Step
Flush & Wait (Sleep).....+1-2% madVR CPU Usage
Flush & Wait (Loop)......+12-17% madVR CPU Usage

All of the rest of the flush settings including Flush & Wait (Loop) for After Backbuffer & After Present, don't appear to increase CPU usage at all.

Anyway, since you got the problem fixed, what is your judgement about the improved "flush & wait (sleep)"? Does it work just as fine as "loop" for you now? I'd like to get rid of the "loop" option.

Flush & Wait (Sleep) still doesn't feel as smooth as Flush & Wait (Loop) for After Backbuffer and After Present. I assume this is because both get called so quickly and often that the extra delay from Flush & Wait (Sleep) slows things down when there is no reason to.

Using Process Explorer to examine the madVR.ax thread's CPU usage (make sure to add the CPU usage from all madVR threads), does anybody find Flush & Wait (Loop) to be using any more CPU then Flush & Wait (Sleep) for After Backbuffer and After Present only?
I know I see identical CPU usage between the two, but I'm curious if it is the same for others.

And how does 0.18 compare to 0.17? You told me that with 0.17 you still had a dropped frame once in a while. Does that still happen with 0.18? Or do you get a delayed frame once in a while now? Is it a visible improvement?
I now get a delayed frame once in awhile (instead of a drop like 0.17), and it does seem to be an improvement.

Edit: Almost forgot.
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 occurredI 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.
Here is a debug log from when madVR hanged on video open: http://www.mediafire.com/?q123omkt0jy

[vucloutr]

What is your display refresh rate and your movie frame rate? There are 2 possible causes for the type of stutter you're describing:

(1) If the display refresh rate is not an even multiple of the source frame rate, you get slight stuttering.
(2) Movie/film is shot with only 24fps. That's a rather low frame rate and introduced some slight stuttering on its own. The only way to fix this would be to do some sort of frame interpolation, which is very hard to do and often introduces artifacts on its own.

source fps is 24000/1001 and display refresh rate was 71.999Hz.
so it was not a perfect match. i tried 71.911Hz now, i can't get nearer to 71.928Hz and my first impression is that it got better.
i'll observe this from now on.
source is CGI with perfect motion, that is why it is my test clip. :p

[madshi]

The following are the only flush settings which increase madVR's CPU usage on my system:

After Render Steps
Flush.........................+10-16% madVR CPU Usage
Flush & Wait (Loop)......+10-16% madVR CPU Usage
Flush alone increases CPU usage? That's hard to believe!

After Last Step
Flush & Wait (Sleep).....+1-2% madVR CPU Usage
Flush & Wait (Loop)......+12-17% madVR CPU Usage
That makes sense.

All of the rest of the flush settings including Flush & Wait (Loop) for After Backbuffer & After Present, don't appear to increase CPU usage at all.
The backbuffer copy is executed rather quickly, so the wait time for that is really low. Not sure what flushing after Present does at all. So it makes sense that the loop doesn't have to wait very long after these two flushes.

Flush & Wait (Sleep) still doesn't feel as smooth as Flush & Wait (Loop) for After Backbuffer and After Present. I assume this is because both get called so quickly and often that the extra delay from Flush & Wait (Sleep) slows things down when there is no reason to.
Are you sure about that?

With 0.17, "sleep" was waiting max 1.0 ms too long for every flush. I can imagine that this wasted time might be a problem sometimes. But now with 0.18, "sleep" is waiting max 0.05 ms too long for every flush. That's 20 times lower. Considering that rendering times are in the range of maybe several milliseconds, it sounds doubtful to me that a wasted time of 0.05 ms would have any noticeable effect. But then, weirder things have happened in the past...

Here is a debug log from when madVR hanged on video open: http://www.mediafire.com/?q123omkt0jy
Don't see anything wrong in that log. :( Except for that playback simply doesn't start for unknown reasons...

[djsolidsnake86]

madshi can i suggest you to try win 7 64bit (and make yoru default os because is nearly perfect) and install these http://www.codecguide.com/ with the default codecs (that are the best selected by clsid) and use your render for find bugs and optimize madvr ;)

[leeperry]

The logs look clean to me.
ok, this time not my imagination..it was jerky as hell after seeking(23.976@96Hz w/ Reclock/CoreAVC CUDA/madflac/PotPlayer): http://www.mediafire.com/file/izzjo2y2eno/madVR%20-%20log.rar

[madshi]

madshi can i suggest you to try win 7 64bit (and make yoru default os because is nearly perfect) and install these http://www.codecguide.com/ with the default codecs (that are the best selected by clsid) and use your render for find bugs and optimize madvr ;)
My HTPC is actually win7 x64, but my development PC is still XPSP3. It's not that easy to change the OS on my dev PC, cause there's so much software installed on this PC.

ok, this time not my imagination..it was jerky as hell after seeking(23.976@96Hz w/ Reclock/CoreAVC CUDA/madflac/PotPlayer): http://www.mediafire.com/file/izzjo2y2eno/madVR%20-%20log.rar
The log looks clean again... :(

2 questions:

(1) No delayed & dropped frames in the OSD during the jerky playback?

(2) What are you current flush settings? If you have them all turned off ("don't flush"), please try going back to the default settings. Maybe that fixes the issue?

At least I can say that (according to the log) the problem does not seem to be the synchronized blabla problem, but something else. The synchronized blabla problem would be visible in the log, but the log looks clean.

[cyberbeing]

The following are the only flush settings which increase madVR's CPU usage on my system:

After Render Steps
Flush.........................+10-16% madVR CPU Usage
Flush & Wait (Loop)......+10-16% madVR CPU Usage
Flush alone increases CPU usage? That's hard to believe!

Don't ask me why, but it was using the exact same amount of CPU as Flush & Wait (Loop). I re-checked multiple times. Bug?

The backbuffer copy is executed rather quickly, so the wait time for that is really low. Not sure what flushing after Present does at all. So it makes sense that the loop doesn't have to wait very long after these two flushes.
http://img693.imageshack.us/img693/9669/afterpresent.png
Well Beliyaal, the guy who originally coded Accurate VSync & Alternative VSync for MPC-HC, seemed to think it was useful for something with VMR9/EVR.

Are you sure about that?

With 0.17, "sleep" was waiting max 1.0 ms too long for every flush. I can imagine that this wasted time might be a problem sometimes. But now with 0.18, "sleep" is waiting max 0.05 ms too long for every flush. That's 20 times lower. Considering that rendering times are in the range of maybe several milliseconds, it sounds doubtful to me that a wasted time of 0.05 ms would have any noticeable effect. But then, weirder things have happened in the past...


All settings set to Flush & Wait (Sleep) 1920x1080 @120hz no-resize Spline64
Render: 14.4ms avg & 15.6ms max (5s)
Present: 6.83 ms avg & 6.89 ms max (5s)

All settings set to Flush & Wait (Loop) 1920x1080 @120Hz no-resize Spline64
Render: 11ms avg & 12ms max (5s)
Present: 6.4ms avg & 6.8ms max (5s)

Render avg Difference: ~3.4ms
Present avg Difference: ~0.6ms



All settings set to Flush & Wait (Sleep) 1600x1200 @96hz Resize 1280x720 Spline64/Spline64
Render: 8.98ms avg & 10.47ms max (5s)
Present: 9.17ms avg & 9.78ms max (5s)

All settings set to Flush & Wait (Loop) 1600x1200 @96hz Resize 1280x720 Spline64/Spline64
Render: 7.07ms avg & 9.46ms max (5s)
Present: 8.12ms avg & 8.37ms max (5s)

Render avg Difference: 1.91ms
Present avg Difference: 1.05ms



It still seems to be adding delay in the OSD stats, and much more time then 0.05ms is being wasted somewhere.

Subjectivity, Flush & Wait (Sleep) does seem improved in 0.18, but I'm still seeing tiny stutters when compared to Flush & Wait (Loop).

I would be more inclined to have you remove Flush & Wait (Sleep) for After Backbuffer & After Present since it doesn't offer any advantages.

[webs0r]

Hey guys I'm no expert on this. But hasn't ar-jar gone through a lot of this thinking already? Can it be re-used for madVR?
Maybe using a similar approach and letting the user set a defined millisecond offset rather than inserting various delays here and there gives more control?

[Mark_A_W]

Umm...madshi...

I think you've nailed it.

I just watched a whole movie (1080p 24), zero dropped frames, zero delayed frames, zero glitches (stats reset straight after startup, then left alone).

No visible issues either.

However I did not seek or pause. Just pressed play, reset the stats, and let it roll.


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

[Thunderbolt8]

questions regarding refresh rate: when changing it with powerstrip, I only have to change the value 'refresh rate' and not 'scan rate' as well, right?

with my screen I can almost exactly get 23,976 x2 refresh rate. so would this be recommended over the 'recommended' native resolution & refresh rate of 60Hz@1680x1050?
what could be disadvantages of that lower refresh rate of my choice, could the lower refresh rate be bad for your eyes (as those old screens used to be), more flickering?

[namaiki]

could the lower refresh rate be bad for your eyes (as those old screens used to be), more flickering?

Not for LCD or Plasma screen.

[gooolist]

This is really a amazing software, i really love to use it in the future. Thanks to give the information about that.

registry cleaners (http://www.ip-lock.com/)
hair loss products (http://www.haircareetc.com/)
work at home job (http://www.germiny.com/)

[6233638]

It still seems to be adding delay in the OSD stats, and much more time then 0.05ms is being wasted somewhere.

Subjectivity, Flush & Wait (Sleep) does seem improved in 0.18, but I'm still seeing tiny stutters when compared to Flush & Wait (Loop).

I would be more inclined to have you remove Flush & Wait (Sleep) for After Backbuffer & After Present since it doesn't offer any advantages.
Your present stats seem very high compared to render times, they should be under 1ms. Typically under 0.2ms here with a 9400M which is much worse than your GTX 470.

Try flush, sleep, flush, dont. After a lot of testing those are the best settings on this card.

Umm...madshi...

I think you've nailed it.

I just watched a whole movie (1080p 24), zero dropped frames, zero delayed frames, zero glitches (stats reset straight after startup, then left alone).

No visible issues either.I agree, though it is fine for me with pause/resume too. Maybe a couple of dropped/delayed frames like starting a film but that's normal.

Not for LCD or Plasma screen.Most plasmas flicker more with 24Hz, running at 48/96Hz. Which is lower than they display 50/60hz content at. Should not be a problem though.

[namaiki]

Didn't know about plasma screens.


Madshi: Could you please consider making a checkbox to enable or disable delayed frames? I'm getting a little bit of stutter for 60fps video where I wasn't before, I'm not sure what's causing it though. (it is and was dropping/delaying tons of frames, but there wasn't stutter before - may or may not be related to delayed frames, but GPU usage seems to be ever so slightly lower, but with stutter compared to before)

[cyberbeing]

Your present stats seem very high compared to render times, they should be under 1ms. Typically under 0.2ms here with a 9400M which is much worse than your GTX 470.
You are using Windows 7, with Aero. Using Aero reduces present times to <1ms because it is special. madshi has said this many times and how he is still unsure if it is a good thing or a bad thing.

I'm on Windows XP and what I'm seeing is quite normal for present times.

Try flush, sleep, flush, dont. After a lot of testing those are the best settings on this card.
Absolutely horrible on Windows XP. Here the only settings which are really smooth are don't, flush, loop, loop. Flush for After Last Step to eliminate tearing. Flush & Wait (Loop) for After Backbuffer & After Present for smoothness. Using any flush setting for After Render, and any Wait setting for After Last Steps, makes things worse.

[techer]

:)
Thanks so much, madshi.
I always liked the quality of video that madVR enables, but didn't like it because it was always crashing when pausing or seeking video.
Now, it seems stable.
Thanks and please keep of the development of it.:D

:confused:One question for anyone that can answer. When a new version comes out, it is better to uninstall an older version (via uninstall.bat) b4 installing the new version? Or, is it just as good to just click on the install.bat in the new version without uninstalling an older version first?

[Mark_A_W]

madshi, any chance of a tray icon for madVR? (And madFLAC?)

It's not a high priority, but it helps usability, and it's a nice touch.


Cheers

Mark

[mark0077]

Hi madshi. Still very impressed with 0.18. Just still has the tiny niggle when switching from windowed to fullscreen. It seems to be a visually two step process ie maximize horizontally. Then 0.2seconds pause (1 frame maybe?). Then maximize vertically.

Not a big deal just looks weird :) other renderers switch horizontally and vertically fullscreen in one step it seems.

[namaiki]

Yo, cyberbeing and others, could you please what I currently use with MadVR v0.18 on your system.

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

If it is horrible (inb4), after back buffer and or after present can set to flush, but not flush and wait.


Also, I'm all ears for testing your flush settings (inb4 don't flush for everything) as well. (read: I would like to)

[ryrynz]

:)
When a new version comes out, it is better to uninstall an older version (via uninstall.bat) b4 installing the new version? Or, is it just as good to just click on the install.bat in the new version without uninstalling an older version first?

Just copy the new version over the old and install with the batch file, there is no need to uninstall. I double check by launching the MADVR options under filters in MPC-HC and look at the version number displayed at the bottom.

[leeperry]

The log looks clean again... :(

2 questions:

(1) No delayed & dropped frames in the OSD during the jerky playback?

(2) What are you current flush settings? If you have them all turned off ("don't flush"), please try going back to the default settings. Maybe that fixes the issue?

At least I can say that (according to the log) the problem does not seem to be the synchronized blabla problem, but something else. The synchronized blabla problem would be visible in the log, but the log looks clean.
(1) nope

(2) even when I set the flush settings to default, I'd swear I still see it slightly hiccuping from time to time...some logs trying to capture the problem: http://www.mediafire.com/file/mozdxjy0njy/log.rar

The sample I've been using: http://www.mediafire.com/file/xidjiztwrmv/Tokyo.mkv

Yes, I had all the flush settings disabled. The thing is that it's not perfectly smooth after the trains keyframe, and when the flush settings are set to default it becomes dead obvious!

Anyway, I've watched a few 90 mins movies(all flush settings disabled)...no dropped frames after 45/60 mins whatsoever anymore, and the uber-smoothness is quite eye-popping tbh in 96Hz :eek:

You might just have managed to reconcile me w/ my HTPC, I'll fire up my HC3100 pj later this week...and see how that goes in 48Hz http://forum-images.hardware.fr/images/perso/1/eler.gif

PS: you said "dithering is done by using shader math now"...it'd be nice to have PS based gamut mapping too, if any possible! my displays are perfectly calibrated, all I need is gamut mapping and it'd open faster/be more convenient than dealing w/ 100MB LUT files :o

[namaiki]

leeperry: could you try the following with your setup? I'm really curious what *you* think about it. If it turns out crap or only so so (besides the 'seek bug'), I wouldn't mind knowing.

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

also 'after backbuffer' and/or 'after present' can set to flush, but not flush and wait|sleep or loop. (no difference for me)

inb4 I actually asked you before and forgot what you wrote :P

[leeperry]

leeperry: could you try the following with your setup? I'm really curious what *you* think about it. If it turns out crap or only so so (besides the 'seek bug'), I wouldn't mind knowing.

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

also 'after backbuffer' and/or 'after present' can set to flush, but not flush and wait|sleep or loop. (no difference for me)
OK, I'll check it out! But at those levels of smoothness, real world footage can't really help anymore...I'll fire up "Space Chimps", no telecine involved(direct digital transfer to 24p) and this cartoon is awfully smooth AFAICR.

[PatchWorKs]

Just discovered this software: really cool !!!

Only some questions:

could be used in transcoding appliances too ?
I mean: could its output quality be piped into an encoder or it's just a "playback" tool ?
It's possible to have a "standalone" renderer to pipe into ffmpeg/mencoder/hcenc ?


Thanks in advice !

[mark0077]

leeperry, what gfx card do you have, nvidia? I have had crazy stuttering from time to time, using nvidia gtx295, with any renderer really, evr or madvr. It happens and no frames are shown as being dropped. I am just thinking perhaps it could be an nvidia bug, looks like 12frames per second or something. Even the evr-cp graph can be completely flat and perfect, yet I can get crazy slow motion stuttering effect which most of the time resolves itself after 10 - 20 seconds, back to perfect smoothness.

Just thought it might be worth mentioning incase you have an nvidia card, and no frames are being reported as being dropped in madVR.

[buzzqw]

@PatchWorKs

1) i doubt.. since it's a renderer not a decoder
2) .. i think it's too tied with windows environment... and isn't ffmpeg but ffplay, isn't mencoder but mplayer.. and hcenc isn't a playback application

BHH

[nlnl]

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

I can not tell any difference between don't flush,flush,flush and wait|sleep settings. Pio 5090 monitor is doing 24 (23)--> 72 (23*3) Hz, 50 --> 75 Hz conversion.
Everything is perfectly smooth :):).

Is there any artificial test clip for smoothness?

[leeperry]

leeperry, what gfx card do you have, nvidia? I have had crazy stuttering from time to time, using nvidia gtx295, with any renderer really, evr or madvr. It happens and no frames are shown as being dropped. I am just thinking perhaps it could be an nvidia bug, looks like 12frames per second or something. Even the evr-cp graph can be completely flat and perfect, yet I can get crazy slow motion stuttering effect which most of the time resolves itself after 10 - 20 seconds, back to perfect smoothness.
all that using Reclock w/ a low enough ppm jitter in its config? the lowest you can reach is 0.17 ppm IME.

I've had that massive frame drop problem after 45/60' since forever...even on ATi cards, and actually my former Sapphire HD3850 had much worse jitter in HR than my current 8800GS...which led me to believe that the PLL clock was far more jittery on the Sapphire. Maybe some day they'll use 1ppm/low jitter milspec clocks on graphic cards? It's always been Seb.26's wet dream :p

I actually think that it was due to that synchronized fliptime thingie, and I believe madshi fixed that for good in 0.18...more than likely now I only need to finetune the flush options, but this is nitpicking at this point :devil:

[namaiki]

mark0077, leeperry: have you tried the Forceware 256/257 drivers? apparently they fix something around that area.

[mark0077]

Actually yes I don't think I have seen it yet with the first 257 driver so maybe that solved it. I'll report back If i reproduce. It was like the graphics card just threw away half of the frames it got from the renderer.

[starlight2]

Hello, today I tried madvr with Intel HD grapics processor i5 650. Unfortunately it in spurts but worse. Do you have any suggestions for me? Thanks

[JarrettH]

Will we see 0.21 before Sunday? :cool::p

[namaiki]

Hello, today I tried madvr with Intel HD grapics processor i5 650. Unfortunately it in spurts but worse. Do you have any suggestions for me? Thanks

Try change scalers to bilinear or something around there and bicubic.

[leeperry]

I run the latest 197.77 WHQL drivers, I've had bad experiences w/ beta nvidia drivers :o

so I've run more tests w/ Space Chimps...whatever I set for the flush options doesn't seem to matter(everything set to "don't"/default/namaiki's settings), but from time to time when I seek back and forth quickly I can get a dropped frame..or can I say late/delayed? It doesn't increment in mVR's OSD.

Here are some logs in 23.976@96Hz, each time I've closed PotPlayer there was one of those frames a few seconds earlier(I used Space Chimp's intro w/ the probe on the moon at the very beginning): http://www.mediafire.com/file/zwwnw0zzuwh/logs.rar

The difference I see is that in <0.18, if your seeking point was missed..it was completely missed, the video was jerky until you manually re-sought. Now, very rarely, a seek can make a delayed frame occur...it quickly gets back in time and doesn't require a reseek. This is trivial at this point, well done!

[pirlouy]

Finally I have tearing whatever flush options I choose.

[leeperry]

Finally I have tearing whatever flush options I choose.
either there's one too much or one missing word.

also, I need more time to make sure that the jerky playback after 45/60 mins problem is gone...but so far I haven't seen it happening :)

and I rest my case that it's hard to judge on this level of smoothness w/ real world footage that went through a telecine transfer and all. I thought I saw some jerky playback in Kill Bill 1(the beginning of the scene in the hospital) but no human/railed video camera can be as smooth as a cartoon...Space Chimps looks like 48fps in mVR :devil:

[namaiki]

Finally I have tearing whatever flush options I choose.

Make sure you have at least one, or the top two options set to flush.

[starlight2]

thanks Namaiki, I changed luma and chroma upscaling and downscaling with bilinear and it works. but what I should be selected in Luma upscaling, downscaling luma and chroma resampling? What changes between lanczos bilinear etc etc?
Thank you very much