madVR - high quality video renderer (GPU assisted)

[Pat357]

I fail to see how those things matter (forgot to say I use LAV for decoding, not madVR's internal ones), as it's madVR that is using the CPU. LAV obviously does nothing when the video is paused, but here you go:
Tested on three clips just now, they all use the same 20-30% CPU:
Vid 1. 1920x1080 24p, x264-encoded, ~15Mbit/s
Vid 2. 320x240 25p, XviD, ~500kbit/s
Vid 3. 960x720 60p, x264 4:4:4 10bit, 10Mbit/s
Display is 1280x800.

If I look at these, it seems that something unrelated to playing the video is taking a lot of CPU cycles.
Say :
Vid 2 = 20% - some overhead = 15 %
Vid 1 en 3 are a lot "heavier" for decoding, scaling, anti-ring algo
The additional 10% doesn't seem correct, the difference should be much more CPU load (no HW decoding is used, right?)
Something seems completely wrong here...

Do you know Process Explorer from Sysinternals ?
Please download it and unpack it in an empty directory (doesn't need installation) and run it.
This gives you a more detailed view from your CPU consumption.

[Thunderbolt8]

I havent followed all this stuff for a while, is it actually possible to watch a 3D blu-ray (iso, if needed) with madvr and/or mpc-hc? if not which other players can I use for that?

[ajp_anton]

If I look at these, it seems that something unrelated to playing the video is taking a lot of CPU cycles.
Say :
Vid 2 = 20% - some overhead = 15 %
Vid 1 en 3 are a lot "heavier" for decoding, scaling, anti-ring algo
The additional 10% doesn't seem correct, the difference should be much more CPU load (no HW decoding is used, right?)
Something seems completely wrong here...

Do you know Process Explorer from Sysinternals ?
Please download it and unpack it in an empty directory (doesn't need installation) and run it.
This gives you a more detailed view from your CPU consumption.Again, decoding should have nothing to do with it, because the videos are *paused*. When running, I can't really say what CPU usage is reasonable or not, but when paused there is reason to see what's wrong.

Process Explorer is what I'm using to see that it's madVR that's causing it. The overwhelming majority is used by
madVR.ax!DllMain+0x24c10
whatever all that means.

[cyberbeing]

ajp_anton must be experiencing that strange high CPU load bug which has affected <1% of madVR users, supposedly since early versions. If madVR threads are shown as the source of the high CPU load in Process Explorer, maybe posting a madVR debug log would reveal something interesting.

[pie1394]

Process Explorer is what I'm using to see that it's madVR that's causing it. The overwhelming majority is used by
madVR.ax!DllMain+0x24c10
whatever all that means.

I have a mini-PC which the equipment and OS setup are very similar to yours. The only difference is between GeForce 320M (32sp) vs ION-LE (16sp). Yet your problem hasn't happened to my system for a very long time regardless of following combinations:

MPC-BE : 1.7.2.4360 (BE mod) , 1.0.0.833 / 933 / 942
madVR: 0.82.5 (w/i AntiRingPatch#6 ... But it doesn't matter) + Chroma Lanczos3 + Luma Bilinear
[General Setting] UnChk, Chk, Chk, Chk / Chk, Chk / Chk
[Window Mode] Queue=5, NF / F+W / NF / NF
[FSE Mode] Chk/Chk/UnChk, Queue=5, NF / F+W / NF / NF
LavFilter + LavVideo (no CUDA) + LavAudio: 0.51.3-18-g840eda7
GeForce Driver: 285.62 / 296.10 / 306.02
Display mode:
1920x1200 60 Hz with Dell U2412M 24" ,
1400x1050 60 Hz with Samsung 203B 20" (broken in the beginning of this year)



I recommend MPC-BE 1.0.0.833 in case that automatic Full-screen playback with madVR is needed. It has some broken issues on other versions. For example:

[MPC-HC BE Mod]
Player program may not be 100% terminated with madVR + auto-refresh rate changer if Alt-F4 is pressed during video playback. Madshi suggested it is MPC-HC's responsibility to deal with that. I agree with him since it does not have such issue with the MPC-BE 1.0.0.833.

[MPC-BE 1.0.0.933 / 942]
The playback will not be started at full-screen state with madVR. It needs to press Alt-Enter manually. (not quite convenient for HTPC usage)

[Nachbar]

Hello I have a .icm profile that came with my monitor and I have implemented the values according to the guide at: http://files.nyaa.eu/HOW_DID_I_PLAYED_BACK.txt

Basically it says

18. Color management using yCMS is always recommended, but it is only required if you use a wide gamut display.
This is done by selecting "calibrate this display by using yCMS" under "devices" -> [Display] -> "calibration" and
filling out at least the "primaries / gamut measurements" table on the "yCMS" tab.
If you do not have any suitable hardware, but you do have a proper ICC profile, you can acquire at least the XYZ values
for red, green, blue, and white point by using an application such as ICC Profile Inspector
- http://www.color.org/profileinspector.xalter - and double-clicking on rXYZ, gXYZ, bXYZ, and wtpt, respectively.
Change the format from Yxy to XYZ and fill out as appropriate. Click on "save".

Does this look correct? pic shows the red value
http://sadpanda.us/images/1195304-MKURSW4.jpg

Also since it is already set as the color profile in the color management does madvr still require this?

[turbojet]

Xello: in madvr settings check devices>[device]>properties and select pc levels. madvr doesn't support pixel shaders currently but in this case madvr is setup better if you have multiple displays that have different color range.

Speaking of cpu usage, I noticed process explorer shows 15-25% when paused while windows 7 task manager shows 0-1% but I think task manager is correct because a paused video doesn't slow down a 100% x264 encode. Maybe some process explorer bug.

MPC-BE not only broke auto fullscreen but also broke saving window size/positions. Been waiting months for official release before notifying the developers. BE 4360 until then.

[Xello]

Xello: in madvr settings check devices>[device]>properties and select pc levels. madvr doesn't support pixel shaders currently but in this case madvr is setup better if you have multiple displays that have different color range.

That's what i'm on, I tried switching to tv levels and it makes it even brighter so that's no good. Back to PC levels, but it's still too bright.

Did you try the EVR-CP fix for that 5 second clip? Can you achieve that result madVR?

thanks :)

[Keiyakusha]

Hello I have a .icm profile that came with my monitor and I have implemented the values according to the guide at: http://files.nyaa.eu/HOW_DID_I_PLAYED_BACK.txt

I'm not sure how it works but i have a feeling that profile you see on DVD with drivers only works for default factory settings. For example I use much lower brightness and when I do calibration I have to set gamma higher so reference picture will look right. Obviously profile that came out of this calibration is quite different from the one that comes with drivers. EDIT: but this is what microsoft's calibration suggests. other test images suggest different stuff and default icm profile actually works with them.

Also since it is already set as the color profile in the color management does madvr still require this?
This is mystery to me too. But I think if windows already uses correct profile, maybe you need to set "display already calibrated" or "disable calibration" in madvr. or maybe not! This is just something to think about. However maybe in exclusive mode madvr bypasses windows settings? That would explain why you still need specify profile. Personally I don't use exclusive mode.

[turbojet]

Did you try the EVR-CP fix for that 5 second clip? Can you achieve that result madVR?

thanks :)

Yes and it's too dark on other videos, like full range on a limited range tv. I'm not convinced the credits aren't supposed to have a gray background, it's not washed out. I watched Margin Call a few months ago and all I remember is it wasn't very good. Do the blacks during the movie look accurate?

If you want to darken the picture like that shader, you can increase gamma in madvr settings>device>color & gamma.

[Asmodian]

Also since it is already set as the color profile in the color management does madvr still require this?

There are three parts to calibration, white point, gamut, and gamma.

Setting up color management in Windows 7 only changes white point and gamma so setting it in MadVR is still helpful. You need to make sure you set the values to what they are with the current monitor and OS settings. I notice fairly different whites with different brightness/contrast settings but the primaries usually stay about the same. Gamma can be quite different but without a meter lets ignore it.

That looks about correct for the red primary, it is also almost exactly on sRGB so if your green and blue primaries are also so close you might just use Windows color management for the white point and set "already calibrated" in MadVR as your gamut is already correct (at least as far as the icm profile knows).

[Xello]

Yes and it's too dark on other videos, like full range on a limited range tv. I'm not convinced the credits aren't supposed to have a gray background, it's not washed out. I watched Margin Call a few months ago and all I remember is it wasn't very good. Do the blacks during the movie look accurate?

If you want to darken the picture like that shader, you can increase gamma in madvr settings>device>color & gamma.

The blacks on the credits are the black floor of the entire film, and the blacks during the film never get any darker than that if left alone. When I do the shader method with EVRCP it looks 100% right, the black floor is ref16 and the film looks great. Without the fix or on madVR the blacks are the greys (looks ref30 ish) you see in the credits which is wrong to me.

This is the 2nd film this has happened with so I anticipate it not being the last, which is why I was looking for a solution using madVR as it's annoying having to not use it. The previous film was japanese BD of 3:10 to Yuma, same issue, got the US version and it was fine though.

Is it possible the film was mastered in a different colorspace? I figured everything was 16-235. I did try the gamma processing option, even setting it to 2.6 the blacks are not black. And of course that messes up all calibration.

[yok833]

Hello Guys, I have a problem and I would like to know if I am the only one or if you can help me.. I'm using the last build of MADVR but sometimes during a movie in HD (play via MPC-HC) i have a nasty sound (BZZZZ like on the old TV before they explode..) and right after the screen becomes black or/and the image is divided in 2, but the sound continues normally behind... Then the only solution is to reboot and everything works perfectly a certain time before it happen again. I have a ATI 6850 + phenom X4 925.... Any ideas?????? My config is not good enough to handle MADVR????

[ryrynz]

Your system's hardware is fine but you have a problem that i think a full reinstall would likely fix.

[TheMoustic]

Hi everydoby!

I have followed the tutorial of Jeremy : http://www.homecinema-hd.com/intro_en.html.

I use : MPC-HC + LAV splitter + madVR + ffdshow + avisynth 2.6

I am encountering problems when I use madVR... I have a Sapphire 4890 connected by HDMI to my Xonar HDAV 1.3, which is connected to my receiver (Onkyo TX-NR709). When I try to play 1080p/i movies (BD or mkv) with HD audio (DDTHD or DTS-HD MA/HR) in bitstream or in LPCM, the sound is cutted and cracks. If I choose EVR custom pres. as video renderer, everything works fine.

I have noticed today that if I directly connect the graphic card to the receiver, I can decode DDTHD and DTS-HD and send it in LPCM wihtout any problem. I have then reconnected the graphic card to the sound card (the initial configuration) and now, LPCM and bitstream of HD audio works fine...

Note : sapphire 4890 doesn't support HD bitstream. I tried to uninstall the Audio HDMI driver of the ATI card but that doesn't help...

[Trib]

Switched my tv from iGPU Intel HD 3000 to my 6950 for more demanding scaling algorithms and was wondering when checking with the testpatterns and when using Pixel Format from Amd CCC, Full or Limited Range RGB, the colors.ytp testpattern showed a vertical line moving horizontally using 0-255 levels and any paned bit depth.

That got fixed with using either YCbCr 4:4:4 or 4:2:2 Pixel Format from CCC with 0-255 levels and 8-bit bit depth. But was wondering if it was ok to use YCbCr rather than RGB as madshi said in front page "Ok, e.g. in ATI's control panel with some graphics cards and driver versions you can activate YCbCr output, *but* it's rather obvious that internally the data is converted to RGB first and then later back to YCbCr, which is a usually not a good idea if you care about max image quality."

So was wondering should I rather use Full Range RGB with the line or YCbCr 4:4:4 or 4:2:2 with no problems in colors.ytp for playback.

[THX-UltraII]

I m using SVP frame interpolation. This is a heavy CPU usage real-time frame interpolation mode. In order to save more CPU i noticed that lowering the GPU and CPU queue saves quite some CPU power. Am I correct that I can lower them as much as possible without getting more dropped frames and pres. glitches?
EDIT: just put them on the minimum (both 4) and get not more dropped frames or pres. glitches then with the default settings (I think default was 12 and 8?)

[Nachbar]

Queuing frames shouldn't produce more dropped frames. Queuing means it is processing frames in advance so you won't drop them. The extra usage is because of this. However it should only have the extra usage at the beginning of play and chill out once they are queued. If your computer is really good then I guess it doesn't matter what it is set to.

Queuing is useful for when a section of video suddenly uses a lot of data (say an action scene). If it can queue the problem frames in advance you won't get any of the frames dropped.

[cyberbeing]

Am I correct that I can lower them as much as possible without getting more dropped frames and pres. glitches?

If your CPU or GPU experiences prolonged periods below real-time, lowering the queues as much as possible will be beneficial.
(Pushing the limits of a slower CPU/GPU)

If your CPU or GPU experiences extremely brief periods below real-time, raising the queues as much as possible will be beneficial.
(Lot of processing head-room with a faster CPU/GPU)

This is usually pretty clear-cut with madVR's CPU queue, but the GPU queue can require some experimentation, especially if you suffer from presentation glitches & dropped frames normally.

[dansrfe]

If your CPU or GPU experiences prolonged periods below real-time, lowering the queues as much as possible will be beneficial.
(Pushing the limits of a slower CPU/GPU)

If your CPU or GPU experiences extremely brief periods below real-time, raising the queues as much as possible will be beneficial.
(Lot of processing head-room with a faster CPU/GPU)

This is usually pretty clear-cut with madVR's CPU queue, but the GPU queue can require some experimentation, especially if you suffer from presentation glitches & dropped frames normally.

Process Explorer should be used to fine tune GPU queues. As a side note, I actually had to decrease my GPU queue down to the minimum of 4 and CPU at 8. This is for a Mobility Radeon HD 4570 with 512MB dedicated graphics memory and C2D @ 2.66Ghz and 4GB RAM.

[ShadowVlican]

If your CPU or GPU experiences prolonged periods below real-time, lowering the queues as much as possible will be beneficial.
(Pushing the limits of a slower CPU/GPU)

If your CPU or GPU experiences extremely brief periods below real-time, raising the queues as much as possible will be beneficial.
(Lot of processing head-room with a faster CPU/GPU)

This is usually pretty clear-cut with madVR's CPU queue, but the GPU queue can require some experimentation, especially if you suffer from presentation glitches & dropped frames normally.
would be awesome if there was some sort of auto-benchmark or test to set the correct queues automatically :cool:

[JMGNYC]

If your CPU or GPU experiences prolonged periods below real-time, lowering the queues as much as possible will be beneficial.
(Pushing the limits of a slower CPU/GPU)

If your CPU or GPU experiences extremely brief periods below real-time, raising the queues as much as possible will be beneficial.
(Lot of processing head-room with a faster CPU/GPU)

This is usually pretty clear-cut with madVR's CPU queue, but the GPU queue can require some experimentation, especially if you suffer from presentation glitches & dropped frames normally.

I can confirm this worked for me. I've a E4200 and an ATI 5570. Some BD rips I have have certain passages that stuttered like hell and drop a 100 or more frames.

Upping my CPU queue to 32 covered for this. During the difficuly passages it might go down to 12-16/32 out of 32 and then will shoot back up to 31-32/32. With a smaller CPU queue than 32 everything went to hell. With it large enough to cover the "slow" decoding bits playback is still smooth.

To handle 720p60 I had to drop my other queues down to 6 to get glitch free playback.

I've got Chroma upscaling to SoftCubic 50 and Luma to Spline 2 taps which are not easy algorithims AFAIK. So, even with my limited CPU and GPU playing with the queues really worked for me.

[THX-UltraII]

Ok, so just leave it on the default queues 12 and 8 cpu and gpu if I don t get any dropped frames/presentation glitches? Or set it a little higher to be sure? (I have a Intel 2600K oc-ed and a NVIDIA GTX460)

Don t know if it s allowed to ask or if I will get flamed but since it s been a really long time since a new madVR version was released, is the project complete/dead?

[aufkrawall]

New Nvidia WHQL driver:
http://www.geforce.com/drivers/results/48847

With it it shouldn't be neceassary anymore to mess around with workarounds to avoid presentation glitches.

[THX-UltraII]

With it it shouldn't be neceassary anymore to mess around with workarounds to avoid presentation glitches.
Why is that?

[aufkrawall]

Why is that?
With beta driver 304.48, the black screen bug was fixed.
Maybe they took a closer look and fixed the glitch issue too.

[THX-UltraII]

With beta driver 304.48, the black screen bug was fixed.
Maybe they took a closer look and fixed the glitch issue too.
Ok, so no need to do the BTB and WTW fix procedure anymore? (adding lines to the .inf file HKR,,SetDefaultFullRGBRangeOnHDMI,%REG_DWORD%,1)

[aufkrawall]

No, I was just referring to limiting render times.

[madshi]

New Nvidia WHQL driver:
http://www.geforce.com/drivers/results/48847

With it it shouldn't be neceassary anymore to mess around with workarounds to avoid presentation glitches.
Are you sure? That would be *awesome* news if true. Funny enough, I was planning to start working on a demo project tomorrow to demonstrate the glitches with NVidia drivers. So does that mean I can save the time and a demo isn't needed, anymore?

Could anybody please test and confirm whether the glitch problem is gone?

[Oline 61]

I was getting many (>30/minute) presentation glitches trying to play back 29.97 fps material with a 60 Hz refresh rate on a 9400GT. With the new drivers I am getting no glitches :).

[madshi]

@Oline 61: That sounds awesome! Can you try with all the glitch options (lowest 3 checkboxes in "rendering\exclusive mode settings") turned off in the madVR settings dialog? Still no glitches? Do you have the option "use a separate device for presentation" (rendering\general settings) checked? Can you also try with that option unchecked? Still no glitches? This could be a great *GREAT* day for NVidia/madVR users!

[ryrynz]

And a great day for more MadVR development :)

[madshi]

I can confirm that on my HTPC (NVidia 9400 mainboard) the glitches seem to be gone with all tweak options disabled, without DX11 presentation, and even without "use a separate device for presentation". So this looks reaaaaally promising!

[SamuriHL]

Guess I better get my drivers updated then. Very nice!

Sent from my Xoom using Tapatalk 2

[nevcairiel]

I should switch back to an NVIDIA maybe, i've been getting weird audio dropouts with my AMD, i can't stand their weird drivers <.<

/me looks for a good passive (or very silent) 650. :)

[madshi]

Yeah, the 650 looks quite tempting. Slightly slower than a 7750, but also slightly lower power consumption, it seems. So a very good HTPC choice, I think.

[Oline 61]

@madshi: My previous post was referring to behavior with default settings (no tweaks, separate device checked). I will test again tonight with separate device unchecked and let you know what happens.

[jmone]

FYI - CUDA/OpenCL?? Video Encoding using Power Director seems to have been broken by 306.23 (http://forum.cyberlink.com/forum/posts/list/24570.page) - :( fix one thing, break another!

[Keiyakusha]

FYI There is some OpenCL applications that stopped working with new drivers too (not all GPUs affected though)... I can't upgrade :( fix one thing, break two other!

[Oline 61]

Good news! I am presentation glitch free with separate device unchecked as well.

[pie1394]

Ok, so no need to do the BTB and WTW fix procedure anymore? (adding lines to the .inf file HKR,,SetDefaultFullRGBRangeOnHDMI,%REG_DWORD%,1)

It is still needed...

The Geforce driver's INF file formt keeps changed, and I am too lazy to rewrite it for new version. It should be more convenient just to create a "geforce_hdmi_full_range.reg" file with following contents. If the display adapter # is not 0000, it needs to be adjusted. Of course an OS reboot action is needed to make this setting taken effect.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}\0000]
"SetDefaultFullRGBRangeOnHDMI"=dword:00000001


To my Hitachi P42A01A, somehow the visible brightness range is increased below 16 and above 235 --- about 3 additional ones at each direction. But I am curious what causes it. If I don't remember it wrong, the visible brightness range has been calibrated just within 16 ~ 235 at least for 0.5 year and I never touch this TV's HDMI settings again.

[madshi]

@pie1394, should that reg file work for everybody, even after installation of the drivers without the tweak? If so, that would be an even better solution than the tweak, but tweaking the inf files before installing the drivers is really painful!

[ranpha]

@pie1394, should that reg file work for everybody, even after installation of the drivers without the tweak? If so, that would be an even better solution than the tweak, but tweaking the inf files before installing the drivers is really painful!

Use the nVidia RGB Full/Limited Range Toggler from http://blog.metaclassofnil.com/?p=83 then, it makes dealing with this problem easier!

[madshi]

Cool, maybe I should add a tweak page to the madVR settings dialog to do something similar...

[fastplayer]

If the display adapter # is not 0000, it needs to be adjusted. Of course an OS reboot action is needed to make this setting taken effect.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}\0000]
"SetDefaultFullRGBRangeOnHDMI"=dword:00000001

I'd replace ControlSet001 with CurrentControlSet which is a pointer/reference to the actual registry key and could very well point to ControlSet002 or ...003 after a "Last Known Good" configuration.

[pie1394]

I'd replace ControlSet001 with CurrentControlSet which is a pointer/reference to the actual registry key and could very well point to ControlSet002 or ...003 after a "Last Known Good" configuration.

Thanks for the correction. It is indeed better to modify the CurrentControlSet version.


@pie1394, should that reg file work for everybody, even after installation of the drivers without the tweak? If so, that would be an even better solution than the tweak, but tweaking the inf files before installing the drivers is really painful!

It is the same on both of my GTX260+ and ION platforms under Win7 x64.

I sometimes used this method when I was too lazy to modify the driver's INF file. The modification in geforce driver's INF file just instructs the installer to do the same action. :)

Such registry's UUID is obviously for display adapter. Yet the display adapter # is not always 0000. In my system there is also the VNC mirror display driver which owns 0001 ID. It was installed after the geforce driver at that moment.


Cool, maybe I should add a tweak page to the madVR settings dialog to do something similar...

It is mentioned that such post modification by registry patch requires an OS reboot action. If the method can be found for this Geforce driver setting change on the fly just like control panel UI button [Apply], it becomes 100% convenient. :D Yet I wonder nVidia provides the API to change this setting via any user-mode program.

A fully display driver reinitialization is more possible. The geforce driver version change under Win7 does not require an OS reboot. (Added since version 250?)

[aufkrawall]

A fully display driver reinitialization is more possible. The geforce driver version change under Win7 does not require an OS reboot. (Added since version 250?)
Driver can be restarted by Nvidia Inspector with "-restartdisplaydriver".
It should do this via NVAPI, so the range changing tool could do the same?

[madshi]

I don't see any way to restart the GPU with NVAPI.

[aufkrawall]

What about dis- and reconnecting device via Windows?

[madshi]

That sounds kinda dangerous. I don't want the OS to be tempted to try to install a different driver or anything.