madVR - high quality video renderer (GPU assisted)

[nlnl]

Nvidia IGP 9400 +512m, Intel 8300 2.83, Vista 32, AERO, ffdshow mt, MPC-НС 1065
madVR 0.7 reports:
AERO ON
3dlut off

luma - lancsoz3
chroma - softcubic100

1) Input - 1080x1920/23.976, video refresh rate (Nvidia control panel) - 23Hz.
Output - NO RESIZE, monitor resolution - 1920x1080

madVR 0.7 OSD says
display estimate 1: 24.97Hz
display estimate 2: 23.976Hz
display estimate 3: 23.976Hz (absolutly stable:)
avrg GPU rendering time - 25 (stable)
max GPU rendering time - 32 (stable :), but when AERO OFF max GPU rendering time is not stable and floating 32-62 and I can not get smooth playback )

2) Input - 1080x1920/23.976, video refresh rate (Nvidia control panel) - 23Hz.
Output - RESIZE 1920x1080 --> 132,0,1766,919

madVR 0.7 OSD says:

display estimate - the same
avrg GPU rendering time - 45
max GPU rendering time - 55-80

CPU load
OSD ON - 90-95%
OSD OFF - 65-72% :confused:

EVR CP 10bit, bicubic A=-1
RESIZE 1920x1080 --> 132,0,1766,919
CPU load - 45-55%

madshi
And why does OSD ON overload CPU :confused:?

[noee]

XPSP3, HD2600XT, CCC9.4, AMD X2 3.0Ghz, Reclock, MPC-HC, CoreAVC 1.9.5
Monitors: (Prim) Samsung 60Hz (1280x1024-PC levels) - (Sec) LG 37 24/60Hz (1080P-Video Levels)
Source material: SD = 23.976@24Hz AVC in MKV, HD = 29.970@60Hz AVCHD in M2TS (1080P)

Refresh detection is still working fine here, both primary and secondary, and on my secondary, it works fine whether I have it at 24Hz or 60Hz.

I have a decidedly older setup and it's certainly not high-performance, so these numbers are very encouraging (at least to me):

Lanczos4/SoftCubic100

SHader 36

SD
avg GPU rendering time: ~18.6ms
CPU Load: 12-18%
GPU Load: 45-50%

HD
avg GPU rendering time: ~15.4ms
CPU Load: 52-55%
GPU Load: 24-31%%


Shader 41

SD
avg GPU rendering time: ~18.4ms
CPU Load: 12-18%
GPU Load: 40-48%

HD
avg GPU rendering time: ~15ms
CPU Load: 52-55%
GPU Load: 27-30%

[dann23]

WMP11 can't load madVR at all.

it works. you have to set the merit to maximum and it works with wmp11. and with version 0.7 I get opening 3dlut file failed

[nijiko]

>>madshi

When I'm playing the RMVB files, which contains RV40 and RealAAC. It always crashes.
In first time I'm playing to 40 min, the screen change colors, and mplayerc.exe crashes with madVR.ax immed..
And I open the file again, and seek to 40 min, continue playing, when it play to 1 h 20 min, the problem occur again.

For the .bik files, can you tell me your email? I will send it to you. Also with decoders.

Sorry for my English. And thank you for your great works once more.

>>dann23

That's a really special way. I never try yet. And it's first time I hear about madVR used with WMP. Aha!

[Mike5]

Win7, HD4650, Catalyst 9.3, madVR 0.7
MPC-HC, 1920x1080@23.976, Refresh: 75Hz

Lines in stats:
1: 78.xxxx
2: 75.0xxx
3: 75-78 varying
4: same as 3

So the best estimate is 2.

But I get a new error. If I change decoder and open again the file, madVR gives the error "opening shader file failed". I have to close and open again MPC-HC to get rid of this error. It didn't occur with previous versions of madVR.

[dann23]

I created the lut files manually but now I get loading pixel shader failed.

[Mark_A_W]

If display refresh rate calculation doesn't work properly for you (open OSD by pressing "Ctrl+J"), please post the first 4 lines of the OSD.


display estimate 1 103.27xxxx hz
display estimate 2 95.9xxx hz (correct)
display estimate 2 135.3xxxhz (completely mental..sometimes hits 142hz)
display 135.3xxx hz (1s)


My display is running 95.904hz interlaced on an ATi HD2600XT, testing in Zoomplayer (CTRL-J is annoying as it is used in ZP).


Watching a 23.976fps MKV file (BD source) it is smooth with Reclock fully active. Not sure about Reclock set to slave....testing still (harder to see without reclock tearing test).

CPU usage is fine, max GPU rendering time is about 17ms.

Thanks Madshi

Cheers

Mark

[Mike5]

Win7, HD4650, Catalyst 9.3, madVR 0.7
MPC-HC, 1920x1080@23.976.

This time I tried with my projector at 50Hz.
1: 52.xxx
2: 50.00xx
3: 50.00xx
4: 50.00xx

and now seconds in line 4 are growing steadily. Sometimes the count goes back to 1.

If I change decoder and open again the file, madVR gives the error "opening shader file failed". I have to close and open again MPC-HC to get rid of this error.

Actually this occurs whatever filter I change, even if I enable/disable subtitles.

Nobody else gets this error ?

[tetsuo55]

Could you please try starting the batch from a command prompt, so that you can see (and report) the error message?

I tried it like this and it installed fine.

So it appears that only doubeclick and rightmouseclick "run as admin"do not work

I tried to test 0.7 on a Geforce4 MX 440 AGP 8x and i get "power of 2 errors" on every file i try :( (was hoping to provide some info to get better support for older cards)

[cyberbeing]

In madVR 0.6 the resampling isn't working properly when video resolution = display resolution. By that I mean it is for some reason resampling textures when no resize is needed. The resampling textures latency when changing between resize algorithms will change drastically even in this no resize situation. Since this causes latency (resample + render time) to go above frame interval on 1920x1080 video it's a major problem. It seems 0.4 has a similar, but much less noticeable problem, since it only resamples the chroma (~5ms avg | ~14ms max) when source resolution = display resolution, while 0.6 resizes both luma and chroma (~20ms avg | ~30ms max) with the specified settings when source resolution = display resolution. This is not the desired behavior. A workaround is manually changing the resize algorithm to bilinear.
I can't reproduce this.

WinXP SP3 x86 | MPC-HC rev1065 | 7800GTX 512MB

I can reproduce this 100% of the time.
http://img509.imageshack.us/img509/2456/resamplebug.pnghttp://img11.imageshack.us/img11/9079/resamplebug2.png

As you see in the first screenshot, the movie resolution = display resolution. No resizing is going on, yet the textures are still being resampled with rather moderate latency, why? If I disable resampling (Bilinear/Bilinear in second screenshot) then correctly(?) the textures aren't resampling.

At least I assume no resampling should be going on in this situation. Is this supposed to happen? Is it normal for always some sort of texture resampling going on with madVR?

Can no one else reproduce this? Could someone else post their resampling times with Spline64/Spline64 set when watching a 1920x1080 video on a 1920x1080 screen? Is everybody else really getting 0ms resampling times when source resolution = display resolution?

Maybe there is some function you are using that isn't supported by older 7 series NVIDIA GPUs which is causing this to break?
__________
On a side note, only Display Estimate 3 is correct for my refresh rate, and madVR seems to correctly pick it.

[Egh]

New OSD values are interesting.

On the CRT monitor run @100Hz, values are as follows:
1: 105.8x-106.0x
2: 99.95x-100.0x
3: 99.98x
4: 99.985x

New method seems to lock on the 100Hz, not sure if it is exact timing but at least it doesn't reset every 6-7s.
Also, if the movie is paused, the third value is 0.00000 :)

On the same monitor but @85Hz (note: I myself consider 85Hz being one of the best rates for 23.976 movies, it seems smoother than 100Hz, not only in mVR).

1: 89.2x-89.3x
2: 85.26x-85.27x
3: 85.268-85.269x
4: 85.26860 or 85.26861.

So I'm right -- 85Hz seems to be a better option, as here the difference between 2) and 3) is very minor. Seems 2) fluctuates about +/-0.005Hz around 4) value, which is nearly perfect.


IMHO output level control is what we really need, because 99.99% of all content has video input levels, anyway. So controls for input levels is mostly useless, as far as I can see...


You are correct. However there are two scenarios a) some filter in the chain (or codec itself) does TV->PC correction (whilst still in YV12/YUY2 colourspace). Built-in MPEG2 codec in MPCHC for example can do that. b) The video may be encoded in full range, for instance nothing stops you from using fullrange in avc (in fact it is better compared to video levels, however people still stick to the video levels).

[nijiko]

Surprisingly in 0.7.

Can't render AVI files...
And rendering a FLV file, screen is full of green...

See in Attachs.

[KoD]

madshi managed some excellent improvements in v0.7.

- with this version, I have the lowest rendering times from all the versions so far. I've finally got downsizing from 1920x1080 to 1440xsomething going smoothly, without often spikes in rendering times, and the most fluid motion so far.

- the mkv files that were not resized upon opening in ZoomPlayer are now properly resized and scaled to the proper AR.

- regarding the avi file with xvid video I've mentioned in one of my posts (which would open, but there would be no image) I found there was a ffdshow setting that was causing this behavior. If the following setting is enabled in ffdshow, the behavior I've experienced happens: ffdshow Options -> Output -> Allow output format changes during playback = enabled. (the state of the sub-option "Connect to compatible filters only" doesn't matter). If that option is enabled (checked) then, indeed, there will be no image during playback just like I've experienced. If that option is either disabled (unchecked) or set to the intermediary state, then playback will be fine, with proper image.

- regarding the mpg file: using the Microsoft MPEG1 decoder (from WinXP), there will be no playback. Using ffdshow for MPEG1 video decoding, playback will work. So this issue is still standing, as there seems to be an incompatibility between the Microsoft MPEG1 decoder and madVR.

As a conclusion: excellent work on the improvements !

And now, new things to consider:
- once again, if I stop (press the Stop button) the current playing file in ZoomPlayer, and open a new one (right click on the video surface -> Open File), I'm greeted by the "opening shader file failed" error message. The only way to overcome this is to close ZoomPlayer and run ZoomPlayer again.

As for the refresh rate detection, I had this odd behavior the first time I used madVR (and in fact, opened a video file at all):

detection rates were, only for a brief moment:
60.someting
59.something
59.something

then they very quickly changed to:
60.40909
0.0
0.0
display 59.something

I've paused the file, opened XnView to make a screenshot (desktop capture). The capture recorded those values.

Now, when XnView popped after it took the screenshot, the numbers on the madVR OSD changed although I haven't resumed playback, to:
60.38465
59.59440
0.00000
display 59.59929

And they stayed like that until I closed the file.

Funny thing is, now every time I open the file, I get
- first, for a very brief time:
60.something
59.something
59.something

- and then the values change to
60.something
59.something
0.00
display 59.something (I'm not getting 0.00 for the second value anymore after taking that XnView screenshot)

Weird, right ?

I'd say the second set of timings is the most accurate in my case, just like for the others.

[KoD]

Actually, I've managed to understand why the third value is 0.00: whenever the seconds counter to the right of the display value is reset, that third timing is set to 0.00. And it will only be changed to another value only if the seconds counter is not reset again.

Must say, if I let the player play the file instead of just opening, watching, and closing it quickly, the display value soon reaches a value where the seconds counter just keeps on counting. It does happen to get reset after a while, but after quite some time.

[madshi]

The difference is that the EVR version plays 100% smooth, while the madVR version plays slightly jerky. This is quite surprising, as my GTX 260 should have enough power for madVR, I guess. If not, what monstrosity of a GPU do I need to use that renderer?
P.S: Please reread the first few posts of this thread. There you will find this comment:

"Currently madVR is *not* optimized yet for smooth motion playback. That is on my to do list for a future version."

A GTX 260 will do more than fine, once madVR is feature complete and polished.

When I run at 50Hz the first 4 lines are:

display estimate 1: 50Hz
display estimate 2: 50Hz
display estimate 3: usually 75Hz, rarely 50Hz
display : usually 75Hz, rarely 50Hz
Win7, HD4650, Catalyst 9.3, madVR 0.7
MPC-HC, 1920x1080@23.976, Refresh: 75Hz

Lines in stats:
1: 78.xxxx
2: 75.0xxx
3: 75-78 varying
4: same as 3

So the best estimate is 2.
display estimate 1 103.27xxxx hz
display estimate 2 95.9xxx hz (correct)
display estimate 2 135.3xxxhz (completely mental..sometimes hits 142hz)
display 135.3xxx hz (1s)

My display is running 95.904hz interlaced on an ATi HD2600XT, testing in Zoomplayer
That's very interesting! For all of you the 2nd estimate is right on the money while the 3rd estimate is off. I will have to revisit my calculation logic. It seems that it works great for some people and fails for you guys. Or maybe I should just use the 2nd estimate which seems to work for everyone - but is not as exact as I'd like...

Hey madshi, great work.
Just one tiny remark, if you would please correct the label background colors, attached screenshot.
You probably keep your Windows at Classic colors so that is not seen but if you enable Visual styles you'll see it too.
Simple change label/checkbox FlatStyle property to System instead of Standard, then it will support Visual style coloring as well.
I wish fixing this bug was as easy as that! There is no "FlatStyle" property in MSVC++ 2005. The real problem is that the visual designer in MSVC++ 2005 does not allow to place controls as childs of another control. Because of that the background color of all controls is off in madVR. The "Visual" in MSVC++ is a bad joke IMHO.

Nvidia IGP 9400 +512m, Intel 8300 2.83, Vista 32, AERO, ffdshow mt, MPC-НС 1065
madVR 0.7 reports:
AERO ON
3dlut off

luma - lancsoz3
chroma - softcubic100

1) Input - 1080x1920/23.976, video refresh rate (Nvidia control panel) - 23Hz.
Output - NO RESIZE, monitor resolution - 1920x1080

madVR 0.7 OSD says
display estimate 1: 24.97Hz
display estimate 2: 23.976Hz
display estimate 3: 23.976Hz (absolutly stable:)
avrg GPU rendering time - 25 (stable)
max GPU rendering time - 32 (stable :), but when AERO OFF max GPU rendering time is not stable and floating 32-62 and I can not get smooth playback )

2) Input - 1080x1920/23.976, video refresh rate (Nvidia control panel) - 23Hz.
Output - RESIZE 1920x1080 --> 132,0,1766,919

madVR 0.7 OSD says:

display estimate - the same
avrg GPU rendering time - 45
max GPU rendering time - 55-80
Thanks! So it seems that with the current madVR shader load, the NVidia 9400 IGP can playback 1080p24 content just fine, as long as you don't need to scale the image in any way. If you do need to scale, Lanczos3 is too much of a burden. Maybe a less demanding scaling filter would work, but it would be borderline. Well, maybe at some time I can find some performance improvements, but probably not anytime soon.

why does OSD ON overload CPU :confused:?
Because doing exact GPU rendering time measurements eats CPU.

I have a decidedly older setup and it's certainly not high-performance, so these numbers are very encouraging (at least to me)
Yep, looks surprisingly good! However, if you went 1080p display resolution, things would change slightly: SD content would eat more GPU power, HD content would eat more resources when scaling and less when displaying 1:1.

When I'm playing the RMVB files, which contains RV40 and RealAAC. It always crashes.
Will need a sample for that, too. My email is dear (at) madshi (dot) net.

How about GPU load? Weren't you one of the people reporting much higher GPU load with madVR 0.6 compared to 0.4? How does 0.7 behave for you? Have you tried the different shader compiler versions?

I get a new error. If I change decoder and open again the file, madVR gives the error "opening shader file failed". I have to close and open again MPC-HC to get rid of this error. It didn't occur with previous versions of madVR.
Actually this occurs whatever filter I change, even if I enable/disable subtitles.

Nobody else gets this error ?
That's a stupid bug in madVR, introduced by loading the shaders from an external file. Will be fixed in the next build.

I created the lut files manually but now I get loading pixel shader failed.
You may need to restart the media player, see Mike5's bug reports (see above). If all else fails, disable the 3dlut for now in the madVR settings.

I tried to test 0.7 on a Geforce4 MX 440 AGP 8x and i get "power of 2 errors" on every file i try :( (was hoping to provide some info to get better support for older cards)
I guess the MX 440 is *too* old... ;)

I can reproduce this 100% of the time.

As you see in the first screenshot, the movie resolution = display resolution. No resizing is going on, yet the textures are still being resampled with rather moderate latency, why?
Probably because chroma needs to be upsampled, which is one part of "texture resampling".

What you should test is this: If you keep the chroma resampling setting at the same value, does changing the luma resampling setting do anything? It should not, if you are at 1:1 (movie res = display res). If you keep the luma setting the same, changing the chroma setting should result in changes, depending on which filtering method you choose. Nearest Neighbor and Bilinear are easiest on the GPU. Next comes everything except Lanczos and Spline. Next are Lanczos3 and Spline36. Next Lanczos4 and Spline64. Highest GPU load has Lanczos8.

Is it normal for always some sort of texture resampling going on with madVR?
Chroma is always resampled. Even if you display a movie at exactly a quarter of the resolution, so that chroma in theory would already have the right resolution, madVR would still resample it. There are 2 reasons for that: (1) Chroma placement for modern codecs is not at the center of 4 luma samples, but it's "left center". (2) Resampling chroma reduces aliasing/jaggies.

Luma should strictly only be resampled if you scale. Also Luma should only be resampled in that directions which are necessary. E.g. if you display a 1440x1080 movie in 1920x1080, the source should only be resampled in X direction, but no in Y direction. But if you manually zoom in a little, luma resampling should be done in both directions.

On a side note, only Display Estimate 3 is correct for my refresh rate, and madVR seems to correctly pick it.
Estimate 2 should somewhat oscillate around estimate 3. So it should be correct, too, just more oscillating and slightly less exact.

So I'm right -- 85Hz seems to be a better option, as here the difference between 2) and 3) is very minor. Seems 2) fluctuates about +/-0.005Hz around 4) value, which is nearly perfect.
How much difference there is between estimates 2 and 3 does not say much (if anything) about which refresh rate is "better". I'm sure that you're right that 85Hz works better in your setup. But a little tweaking with PowerStrip might already change things. Or not. Much depends also on which refresh rate your display/projector likes best. So it can be different for everyone, depending on which hardware they have...

You are correct. However there are two scenarios a) some filter in the chain (or codec itself) does TV->PC correction (whilst still in YV12/YUY2 colourspace). Built-in MPEG2 codec in MPCHC for example can do that. b) The video may be encoded in full range, for instance nothing stops you from using fullrange in avc (in fact it is better compared to video levels, however people still stick to the video levels).
That's why I wrote "99.99%" and not "100%"... :) I'm aware that there are some funny situations where input can have PC levels. But these are usually exceptions and really rare. Personally, I've never had such a case yet. As I said, settings for such things may come at a later time, but not now.

Surprisingly in 0.7.

Can't render AVI files...
And rendering a FLV file, screen is full of green...
Please make sure that the decoder you're using is able to output YV12 - and that it outputs it correctly. madVR only accepts YV12 and nothing else. That already exposed a bug in the MPC HC decoders which nobody detected before. It may expose bug in other decoders, too. And the graph may fail to render at all, if the decoder does not support YV12 at all.

- with this version, I have the lowest rendering times from all the versions so far. I've finally got downsizing from 1920x1080 to 1440xsomething going smoothly, without often spikes in rendering times, and the most fluid motion so far.
Too be honest, I'm not sure why 0.7 behaves different than 0.6 for you. In theory both use the same shader code and the same Direct3D compiler version. But maybe something else has changed, I'm not 100% sure...

- the mkv files that were not resized upon opening in ZoomPlayer are now properly resized and scaled to the proper AR.
Great!

- regarding the avi file with xvid video I've mentioned in one of my posts (which would open, but there would be no image) I found there was a ffdshow setting that was causing this behavior. If the following setting is enabled in ffdshow, the behavior I've experienced happens: ffdshow Options -> Output -> Allow output format changes during playback = enabled. (the state of the sub-option "Connect to compatible filters only" doesn't matter). If that option is enabled (checked) then, indeed, there will be no image during playback just like I've experienced. If that option is either disabled (unchecked) or set to the intermediary state, then playback will be fine, with proper image.

- regarding the mpg file: using the Microsoft MPEG1 decoder (from WinXP), there will be no playback. Using ffdshow for MPEG1 video decoding, playback will work. So this issue is still standing, as there seems to be an incompatibility between the Microsoft MPEG1 decoder and madVR.
Let me postpone these problems to a later version. Since it's possible to workaround these problems by modifying the filter chain or decoder settings, I'll work on other things first.

And now, new things to consider:
- once again, if I stop (press the Stop button) the current playing file in ZoomPlayer, and open a new one (right click on the video surface -> Open File), I'm greeted by the "opening shader file failed" error message. The only way to overcome this is to close ZoomPlayer and run ZoomPlayer again.
Yes, new bug, will be fixed in next build.

As for the refresh rate detection, I had this odd behavior the first time I used madVR (and in fact, opened a video file at all):

detection rates were, only for a brief moment:
60.someting
59.something
59.something

then they very quickly changed to:
60.40909
0.0
0.0
display 59.something

I've paused the file, opened XnView to make a screenshot (desktop capture). The capture recorded those values.

Now, when XnView popped after it took the screenshot, the numbers on the madVR OSD changed although I haven't resumed playback, to:
60.38465
59.59440
0.00000
display 59.59929

And they stayed like that until I closed the file.

Funny thing is, now every time I open the file, I get
- first, for a very brief time:
60.something
59.something
59.something

- and then the values change to
60.something
59.something
0.00
display 59.something (I'm not getting 0.00 for the second value anymore after taking that XnView screenshot)

Weird, right ?

I'd say the second set of timings is the most accurate in my case, just like for the others.
Yes, it seems that 2nd estimate is the most reliable. Too bad, in theory the 3rd estimate should be a lot more exact than the 2nd estimate. Practically, it doesn't quite seem to work... <sigh>

-------------

What about those people who had higher GPU load with v0.6 compared to v0.4? How does v0.7 behave for you?

Haven't got any feedback on that yet. Thanks.

[nijiko]

Black srceen with some MP4 format flash video. (See attach.)

I mentioned all above are working fine in WMR9.

But worth mentioning, in most video testing, 0.7 is more smoothly than any one before. Thank you very much!

[KoD]

madshi, I'm certain rendering times are much improved over 0.6, and I'm not seeing things. Playback is now smooth for files that were not at all with 0.6 (I had to use 0.4 till now), and playback was very bad for low resolution xvid files. Maybe it's not a matter of shader code, but the method you were using to figure the refresh rate in v0.6 ? Even with 0.7, until madVR figures out what refresh rate my screen has, the image is stuttering pretty badly. Or maybe CPU load is lower with this version ?

Actually, a feature request: can we have back the previous version's "madVR is now initializing, please wait..." message and start of playback after that initialization is done ? Because right now playback starts immediately, but the first moments are badly stuttering.

[noee]

Yep, looks surprisingly good! However, if you went 1080p display resolution, things would change slightly: SD content would eat more GPU power, HD content would eat more resources when scaling and less when displaying 1:1.

Madshi, just FYI, the numbers I reported above were played back on my sec. monitor (LG37 HDTV), which is a 1080P and my HD2600XT is set for 1920x1080x32 for that monitor. So, my HD numbers above were 1:1 and the SD numbers obviously were with madVR upscaling.

So, even better, I'd say.

[KoD]

Arr, the reason why playback seemed smoother was that I was using Lanczos3 instead of Lanczos4. Because, with Lanczos4, the smoothness situation hasn't changed compared to v0.6, I'm still having timings going over 50ms now and then (once I've seen 90ms on that 1920x1080 dowscaling). I don't seen to have the same kind of issues when upscaling, though.

One more note: the seconds counter resets very few times. It does reset when there's a big rendering time spike. The difference in rendering times between Lanczos3 and Lanczos4 when downsizing is high. The difference in smoothness of the image between being just below the frame rendering time (Lanczos3) and being higher more often than the frame rendering time (Lanczos4) is impressive.

[nijiko]

>>568>>KoD

I also found some problems with the versions after 0.4.
The files which not work fine are ever working fine in 0.4.

[cyberbeing]

Probably because chroma needs to be upsampled, which is one part of "texture resampling".

What you should test is this: If you keep the chroma resampling setting at the same value, does changing the luma resampling setting do anything? It should not, if you are at 1:1 (movie res = display res). If you keep the luma setting the same, changing the chroma setting should result in changes, depending on which filtering method you choose. Nearest Neighbor and Bilinear are easiest on the GPU. Next comes everything except Lanczos and Spline. Next are Lanczos3 and Spline36. Next Lanczos4 and Spline64. Highest GPU load has Lanczos8.


Chroma is always resampled. Even if you display a movie at exactly a quarter of the resolution, so that chroma in theory would already have the right resolution, madVR would still resample it. There are 2 reasons for that: (1) Chroma placement for modern codecs is not at the center of 4 luma samples, but it's "left center". (2) Resampling chroma reduces aliasing/jaggies.

Luma should strictly only be resampled if you scale. Also Luma should only be resampled in that directions which are necessary. E.g. if you display a 1440x1080 movie in 1920x1080, the source should only be resampled in X direction, but no in Y direction. But if you manually zoom in a little, luma resampling should be done in both directions.

What about those people who had higher GPU load with v0.6 compared to v0.4? How does v0.7 behave for you?

Haven't got any feedback on that yet. Thanks.
http://img25.imageshack.us/img25/3460/35237305.pnghttp://img23.imageshack.us/img23/6619/06a.pnghttp://img22.imageshack.us/img22/4273/06b.pnghttp://img19.imageshack.us/img19/5003/12518259.png

Since chroma is always supposed to be resampled, it seems the luma being resampled when it shouldn't be problem was fixed in 0.7. Now the question is, why is madVR 0.4 ~3 times faster in resampling in these conditions then 0.6 & 0.7? Where is that extra 10ms of latency coming from?
________________
http://img524.imageshack.us/img524/6778/complex.png
Another thing I'm curious about is if it is normal for your render time to spike by 15-25ms during complex panning scenes? The scene at the beginning of the Advent Children Complete Blu-ray really seems to cause a huge render latency spike.
Sample of problem area: http://www.sendspace.com/file/7n0cee or http://www.mediafire.com/?4yfmjzxmnww

[nijiko]

Actually, a feature request: can we have back the previous version's "madVR is now initializing, please wait..." message and start of playback after that initialization is done ? Because right now playback starts immediately, but the first moments are badly stuttering.

Madshi ever said the init. is not for playing video well.
It's something not care about rendering.

[KoD]

Ok, final post for now, because it looks like I'm flooding this thread:

- very smooth playback when upscaling, and very low rendering times when upscaling, even with Lanczos4 (for luma, using the default value for chroma)
- very jerky playback when downscaling from 1920x1080 to 1440xsomething when using Lanczos4 for luma. Smooth playback when using Lanczos3 for luma. I'm figuring out the jerkyness is largely due to the rendering times going over the frame rendering time, rather than anything else.

- replacing the shaders.dat file with the shaders36.dat one (and renaming it to shaders.dat, of course), doesn't give the good timings v0.4 had on that 1920x1080 file when downsized using Lanczos4. I've just checked now, timings rarely go over 41ms with v0.4, but they get to high spikes (50ms+, even 90ms+) pretty often with v0.6.

- I'd say when upscaling timings are not as good as with v0.4 either, but the difference is minor (also checked it with the shaders36.dat and the default shaders.dat). More like it spikes more often with v0.6 than it did with v0.6, but still keeping in reasonable values. (or maybe you changed the method of measuring the rendering times between v0.4 and v0.6, and spikes are obvious in the way you measure them in v0.6 but were not in the way you measured them in v0.4)

- refresh rate detection works: it keeps on increasing the seconds timer on most files an doesn't reset (unless in the awful situation with that 1920x1080 downscaling when using Lancszos4). However, there is one file on which I constantly get very bad refresh rate detection (how come it's file dependent ?) madshi, do you still have that avi file I've sent you ? Play it... and look how sometimes, after some time, the second timing goes to 0.00, and how the third timing almost never changes from 0.00. I don't understand how this can be file dependent, but I'm not getting this with other files. (I'm using ZoomPlayer, the Microsoft AVI splitter, ffdshow for xvid decoding, and the Windows XP (Fraunhoffer) mpeg3 decoder for audio). Who knows, maybe it's splitter + decoders dependent.

- the slight judder at the beginning of playback is random. It doesn't happen most of the times.

[madshi]

Actually, a feature request: can we have back the previous version's "madVR is now initializing, please wait..." message and start of playback after that initialization is done ? Because right now playback starts immediately, but the first moments are badly stuttering.
I'm not sure why there is stuttering now at the beginning. In theory madVR still waits until initialization is done. Will work on that later...

Arr, the reason why playback seemed smoother was that I was using Lanczos3 instead of Lanczos4.
That makes sense!

I also found some problems with the versions after 0.4.
The files which not work fine are ever working fine in 0.4.
I need samples for files which work with v0.4, but not with v0.7.

Now the question is, why is madVR 0.4 ~3 times faster in resampling in these conditions then 0.6 & 0.7? Where is that extra 10ms of latency coming from?
You're using "Spline" for Chroma resampling, which is consuming more resources than SoftCubic100 (which was used by 0.4 for chroma resampling). Please retry with SoftCubic100 for chroma resampling. I think that produces the best image quality, anyway. I prefer SoftCubic100 over any other filtering method for chroma upsampling (but not for Luma!).

If you get worse rendering times with 0.7 compared to 0.4 even with SoftCubic100 for chroma resampling, then please try different shader compilers (see "shaders" subfolder).

Another thing I'm curious about is if it is normal for your render time to spike by 15-25ms during complex panning scenes? The scene at the beginning of the Advent Children Complete Blu-ray really seems to cause a huge render latency spike.
Sample of problem area: http://www.sendspace.com/file/7n0cee
That sounds weird. madVR should not depend on image content. Of course video decoding is likely to consume more CPU during panning scenes. Maybe that has a strange side effect on rendering times, but it shouldn't really have. Will have a look at that...

[madshi]

- replacing the shaders.dat file with the shaders36.dat one (and renaming it to shaders.dat, of course), doesn't give the good timings v0.4 had on that 1920x1080 file when downsized using Lanczos4. I've just checked now, timings rarely go over 41ms with v0.4, but they get to high spikes (50ms+, even 90ms+) pretty often with v0.6.
Could you please post exact rendering numbers for (1) v0.4, (2) v0.7 with shaders41.dat, (3) v0.7 with shaders36.dat? Please use 3dlut processing, because that's what v0.4 did, too.

Thanks!

[iSunrise]

madshi, thanks for v0.7.

madVR 0.7 now correctly displays AR again in ZoomPlayer and all videos/movies I have tested were correctly resized again. Unfortunately there are some new bugs in this build which kind of make testing various files with e.x. ZoomPlayer kinda hard.

1. When enabling 3dluts, I get an error message "- opening 3dlut file failed". madVR 0.6 worked perfectly in that regard.
2. While playing a movie, switching between 3dluts und shaders doesn´t work (it crashes the player), most probably because of 1.
3. When playing a movie and opening another one madVR gives an error message "- opening shader file failed".

It seems like all of these bugs are somehow connected.

Like I already reported, I am using a CRT@100Hz. Display estimate 3 seems to be the most accurate ("99.98636Hz"), however, display estimate 3 is also is the only estimate that occasionally fails to recognize my display refresh rate and will then show "0.00000Hz". Whenever that happens, the counter will reset to "0s" again.

[cyberbeing]

Please retry with SoftCubic100 for chroma resampling.
This does fix it. 0.4 then equals 0.7.

That sounds weird. madVR should not depend on image content. Of course video decoding is likely to consume more CPU during panning scenes. Maybe that has a strange side effect on rendering times, but it shouldn't really have. Will have a look at that...
CPU use doesn't seem to go above ~50% when decoding that scene with CoreAVC on my dual-core. It does spike a bit higher then non-panning scenes, but it's not like it is running out of CPU resources. I hope you can figure out what is wrong. From what I remember it happens with or without using a 3dlut. I normally use a 3dlut with custom output primaries though.

[KoD]

- regarding the avi file with xvid video I've mentioned in one of my posts (which would open, but there would be no image) I found there was a ffdshow setting that was causing this behavior. If the following setting is enabled in ffdshow, the behavior I've experienced happens: ffdshow Options -> Output -> Allow output format changes during playback = enabled. (the state of the sub-option "Connect to compatible filters only" doesn't matter). If that option is enabled (checked) then, indeed, there will be no image during playback just like I've experienced. If that option is either disabled (unchecked) or set to the intermediary state, then playback will be fine, with proper image.


Slight correction here, for those following this thread:
- make sure to disable (uncheck) that "Allow output format changes during playback" option in ffdshow, for playback to work with certain files.

I've just tested a mpeg2 in mkv file (just muxed the vob to a mkv) which wouldn't start playing with that option in the intermediate state. It only works when it's disabled.

[nijiko]

WMV files are working fine with VMR9 but not with madVR.

[KoD]

Could you please post exact rendering numbers for (1) v0.4, (2) v0.7 with shaders41.dat, (3) v0.7 with shaders36.dat? Please use 3dlut processing, because that's what v0.4 did, too.

Thanks!
Exact rendering times are hard to get, you know... :) maybe the renderer would need to keep a log somehow, and write it to disk at the end of playback, because following numbers on the screen is not very reliable. :)

And yes, you were right, I haven't compared the numbers with "3dlut" enabled in v0.7.

Notes:
- when I said "rendering times", I was referring to the "max gpu rendering time" that the OSD displays.
- when I say I'm using v0.4, it means I'm using the v0.4 package from back then (and not the madvr 0.4.ax from the v0.7 package)

So here goes:
- v0.4, the old package: that max gpu rendering time most often stays around 41ms, going as low as 38ms, and as high as 44ms

-v0.7, using shaders41.lut and "3dlut" disabled: times are 38-39 ms up to 42-44ms, but have spikes to 50ms now and then, and even 80,90ms sometimes

-v0.7, using shaders36.lut and "3dlut" disabled: times are worse than with shaders41.lut: they are mostly 40-50ms, rarely going to 37-38, and more often going to 60ms+.

-"3dlut" enabled: just like it was said, when using this I get the error message with "can't load shader file..."


This is the best I can do. Really, the values have a lot of variance when using v0.7 and it's not easy to follow them on the screen. I have the impression they're not exactly the same each time I play the file, either (and that's most likely true, as they're averages, right ?). It might very likely be that shaders36.lut and shaders41.lut give the same numbers, just that I'm being biased or that I just happen to see some (slightly) different values in one run than in the previous one.

[Mike5]

In my set avi files are Ok, wmv are Ok, flv have a greenish band in the lower half and several yellowish vertical bands.

I checked the ouput of decoder and the input of madVR are YV12.

[Xorp]

What priority is being able to take screenshots at?

[Mike5]

Yes, it seems that 2nd estimate is the most reliable. Too bad, in theory the 3rd estimate should be a lot more exact than the 2nd estimate. Practically, it doesn't quite seem to work... <sigh>

Apparently it also depends on the frequency. For me at 50Hz the third estimate is perfect, but at 75Hz the second is quite precise, but the third says 75 with jumps to 76 and even 78Hz.

[yesgrey]

What priority is being able to take screenshots at?
Use PrtScr key and copy paste. It works wonderfully.:)

[tetsuo55]

Use PrtScr key and copy paste. It works wonderfully.:)

And it captures the actual displayed aspect ratio :D

[Xorp]

Prior to installing 0.7, I uninstalled 0.6 and deleted all its files. Installed 0.7 and checked use 3dlut. However it doesn't seems to be creating new 3dlut files (aren't in cr3dlut folder), it says "madVR reports: -opening 3dlut file failed".

[KoD]

Finally, those values might just not mean much by themselves. The CPU is probably at its limit (this is a laptop... and even the 9600M GT GPU has a 128 bit memory bus compared to 256bit for its desktop counterparts), and v0.6 just goes a little bit over that limit and that's why chaos ensures, while 0.4 kept it a little bit under.

I've just tested with a file that the CPU simply can't decode in software mode (except when using one of the Microsoft renderers), and v0.4 had those nice 41ms times while v0.6 went all over the place with its timings, but both renderers were badly lagging behind the audio, with the queue at 2/16 almost all the time. Interesting that the audio never stuttered when using v0.4 (although it was not in sync with the video), while it did stutter with v0.6 now and then. Also, v0.4 was updating the OSD even while playback was paused (?!?), while v0.6 doesn't do this (or am I seeing things?).

[nijiko]

I'm back again.
Bug report:
When I pause for a long long time. Probability mplayerc.exe will crash with madvr.ax.
.........

[brokenmind]

first, thanks madshi for this fine piece of software; it's doing great on my system, however, there's one problem that occurs to me with a couple of avi files (xvid). I use koepi's xvid decoder (1.2.1) and get some weird colors (small sample file uploaded @
http://tinyurl.com/d6wo44) although I'm using YV12 output forced in the decoder settings;
can someone reproduce this? thanks a lot in advance...

---
SW: XP SP3, CCC 9.3, ZP6 + Reclock
HW: ATI HD 3650 512MB, two LCDs connected (1st one via VGA & 2nd one - Panasonic LCD TV - via HDMI)

[TripleH]

I still can't get madVR to play video without tearing.

I enabled the OSD and from some reason it can't detect my refresh rate correctly (it gives strange numbers like 48.9xxx, 56.xxxx, 42.xxx hz), while reclock detects it right.

Maybe it has something to do with the problem.

[yesgrey]

I still can't get madVR to play video without tearing.
What's your graphics card?

[yesgrey]

Here are my refresh rate results, with my crt monitor set to 72.000Hz:
1: 74.98894
2: 72.01135
3: 72.00076
4: 72.00027 (77s)
With the monitor set to 75.000 Hz I got the same relations. The mode 1 is showing always more 3Hz than the set rate.

[madshi]

1. When enabling 3dluts, I get an error message "- opening 3dlut file failed". madVR 0.6 worked perfectly in that regard.
Prior to installing 0.7, I uninstalled 0.6 and deleted all its files. Installed 0.7 and checked use 3dlut. However it doesn't seems to be creating new 3dlut files (aren't in cr3dlut folder), it says "madVR reports: -opening 3dlut file failed".
That problem is caused by madVR 0.7 shipping with cr3dlut v2.1 instead of v2.0. And cr3dlut v2.1 changed some parameters which broke my templates. Will be fixed in the next madVR build.

- when I said "rendering times", I was referring to the "max gpu rendering time" that the OSD displays.
The average time is the important one. How does that one compare? I don't care that much about the "max" times right now.

I have the impression they're not exactly the same each time I play the file, either (and that's most likely true, as they're averages, right ?)
No, the "max" values are not averages. They're the highest values that occurred in one second worth of playback time.

What priority is being able to take screenshots at?
Middle priority. Definitely after smooth playback. Also for your AVSForum screenshot thread :) I'm not sure if you want to use madVR, because the dithering used by madVR will greatly increase PNG file size! Well, of course you could turn dithering of for screenshot creation...

When I pause for a long long time. Probability mplayerc.exe will crash with madvr.ax.
How long is "long long" in minutes?

there's one problem that occurs to me with a couple of avi files (xvid). I use koepi's xvid decoder (1.2.1) and get some weird colors
That sample does play weird. Not sure whether the bug is in the decoder or in madVR, will need to check that...

[TripleH]

What's your graphics card?

Radeon HD 4670 512MB GDDR3

[yesgrey]

Radeon HD 4670 512MB GDDR3
That should be enough for using madVR... post your statistics (Ctrl+J) and also try setting both resamplings to bilinear.

[nijiko]

How long is "long long" in minutes?

I can't confirm. And it's probably.
But in fact, it crashed two times in pausing video.
(I was pausing video and checking the playback info. at that time)

And for testing the versions of shaders with many videos, I found 40 is the best.
My video card is GF6600 standard version, 128bit 128MB, fully DX9 support.

[madshi]

And for testing with the versions of shaders, I found 40 is the best.
My video card is GF6600 standard version, 128bit 128MB, fully DX9 support.
Could you please be a bit more specific? How much better is 40? How good are 41 and 36 in comparison? Of course I'd like to simply use the newest compiler version, which would be 41.

[nijiko]

Could you please be a bit more specific? How much better is 40? How good are 41 and 36 in comparison? Of course I'd like to simply use the newest compiler version, which would be 41.

I found 36 is the same with 41.
I don't know so much tech. about video playback. I'm only a green hand in this field.
I judge it only by playing the high rate and high resolution videos which will use most resource.
40 is the most smooth in all of these.

[madshi]

madVR 0.8 released

http://madshi.net/madVR.zip

* fixed: only the first movie played fine, a 2nd movie stayed black
* 3dlut creation should work again now (broken in v0.7)
* minor improvement in display refresh rate calculation
* some minor changes in window management
Just some small bug fixes...

[nijiko]

Faster to slower:
40, ... ,31, 34, 24, 41=36, 39.

Testing with smoothing and CPU usage.

I suggest to leave those diff. versions in the package.
Then everyone can choose the best for him to use.