View Full Version : madVR - high quality video renderer (GPU assisted)
Xello
23rd March 2012, 23:53
Did Nv get HDMI output working as intended on the 680? I mean like
- no .inf fiddling anymore to get fullrange luma in stead of always being in TV-range,
- output frequency stable, so no more tweaking to scanlines/overscan with rivatuner to exact (or very near) 23.976xxxxx output rate ?
Cause on the HDMI output 'side of things'; AMD's cards work out of the box for me, on both video and audio (incl. high-res/lossless audio + bitstreaming). I find that up till now Nv's card are to much hassle to get just right, maybe thats changed. Hence the question.
Never experienced the issues you mention on the 580, and the 680 seems the same so far. They did switch from mini to full size hdmi out though, and no cable in the box this time so gonna have to order another one.
aufkrawall
24th March 2012, 00:25
I hope the fan doesn't raise when the card is in p0 state with just little load.
I wait for the Asus CUII design.
aufkrawall
24th March 2012, 01:15
Maybe I will temporary go back to the 296 driver to test it.
With 296 driver there's only tearing in windowed mode if Vsync is forced off.
In new FSE there's no tearing.
cyberbeing
24th March 2012, 02:35
Thanks for testing that on Win7 aufkrawall. Since you specified new FSE, was there tearing with old FSE?
I looked back in this thread, and it seems my last post on the subject was when I observed this behavior with the old FSE mode and VSync Forced-Off. The new FSE mode was always unusably slow on that GPU, so while I know I've tested the new FSE VSync behavior, it doesn't appear I made a meaningful record of it anywhere.
Confirmed, Black screens r us. Just got mine today, apart from this issue quite impressed with it so far :)
When you find time, could you post a madVR Debug log? Without at least that, madshi won't be able to begin troubleshooting the issue.
Could you also run madNV12Test (http://madshi.net/madNV12Test.zip)? Even though that test is very outdated, it'd still be interesting to see the performance results on Kepler.
I have bin having problems with some external subtitles displying wrong in mpc with madvr.
What language are the subtitles supposed to be? It looks like the character encoding of the subtitle file is set to a non-native ASCII encoding which is different form your regional settings. Could you upload the original subtitle file somewhere? To avoid such issue in the future, you should author your subtitles in a Unicode space such as UTF-8.
Xello
24th March 2012, 02:53
debug log:
https://rapidshare.com/files/2812914673/madVR_-_log.txt
that test:
http://pastebin.com/dF1HTFyk
cheers
Budtz
24th March 2012, 06:36
The subtitle is in english. Here it is. just remove the ".txt" extention. i tried to change the encode to utf-8 but it seems to have no effect. when i open it in a subtilte editor it is just gibberish regradles of what i change. how come vlc can read it?
cyberbeing
24th March 2012, 07:59
It's usually quicker to upload such files to mediafire or some other file hoster. Attachments sometimes take awhile to get approved.
If it's indeed an english subtitle, it seems possible that the subtitle was saved as UTF-16 or similar without a signature, causing it to incorrectly be viewed as ASCII or UTF-8 without conversion (gibberish). I'll take a look later after the attachment is accessible. It's possible that VLC (libass) may auto-detect and correct these sorts of encoding issues.
Budtz
24th March 2012, 08:10
here is a proper link for the subtitle file
http://www.mediafire.com/?36a2ujdps51fpx6
cyberbeing
24th March 2012, 08:15
Those were Bulgarian subtitles using Cyrillic (Windows-1251) ASCII encoding. Here they are converted to UTF-8:
http://www.mediafire.com/?memxydcxvo47jsd
Budtz
24th March 2012, 14:31
ah thx. i figured it out. the english subs were elsewere and my player was set up to use external files first.
CruNcher
24th March 2012, 15:43
I hope the fan doesn't raise when the card is in p0 state with just little load.
I wait for the Asus CUII design.
there are no p states anymore it's fully dynamic like with Sandy Bridge now ;)
debug log:
https://rapidshare.com/files/2812914673/madVR_-_log.txt
that test:
http://pastebin.com/dF1HTFyk
cheers
was Aero off or on ?
aufkrawall
24th March 2012, 17:01
there are no p states anymore it's fully dynamic like with Sandy Bridge now ;)
There are still p states but there's a dynamic turbo which can also lower clocks, if I'm not mistaken.
There are still classical desktop and video states.
Xello
24th March 2012, 18:04
there are no p states anymore it's fully dynamic like with Sandy Bridge now ;)
was Aero off or on ?
on should i run with it off?
CruNcher
24th March 2012, 18:33
on should i run with it off?
couldn't be wrong posting both results ;)
There are still p states but there's a dynamic turbo which can also lower clocks, if I'm not mistaken.
There are still classical desktop and video states.
yep you right they left the video and desktop states i guess those wont be dynamic @ all i wonder though how that plays out for things like MadVR when they use the Cuvid API (Decoding) and Direct3D (Rendering) @ the same time :D
aufkrawall
24th March 2012, 19:14
@ all i wonder though how that plays out for things like MadVR when they use the Cuvid API (Decoding) and Direct3D (Rendering) @ the same time :D
I guess it will jump into p0 state as usual.
But as long as the fan doesn't raise, I don't see any problem.
With "Thermi" Fermi it's not great fun. :(
Especially not when you've raised voltage...
Xello
24th March 2012, 20:41
aero off:
http://pastebin.com/vYbyGBcA
Gelatinous
25th March 2012, 01:24
Have there been any reported issues with madVR causing audio crackling issues? I've been struggling with it for a while, and hope someone could shed some light on whats happening.
This issue happens exclusively on my USB soundcard; my internal audio is fine (though i cant use earbuds with my internal audio, which is why i'm bothering with this at all).
When i use madVR with its internal h264 decoder disabled, the audio on many video files will begin to crackle. Its usually most noticeable when a person is talking, manifesting as a not-so-subtle crackle in the background; low pitched sounds and background music do not seem to trigger it. This happens with both FFDshow's video/audio decoder and LAV's video/audio decoder and all combinations of the two.
When madVR's internal decoder is enabled and preferred, the audio is perfectly fine. When another renderer is used - EVR/sync/CP, VMR9, Haali etc - along with h264 from FFDshow or LAV the audio is also perfectly fine.
I've downloaded builds as early as 0.62 (apparently the first release supporting 10 bit, which the sample below is) but the problem is still there.
The clip below seems to consistently present the issue for me
http://www.mediafire.com/?gqvb44nt2clyeya
Thanks for any help.
shimaflarex
25th March 2012, 03:46
This probably has something to do with the video decoder priority.
Try using WASAPI with Reclock if you aren't already.
agustin9
25th March 2012, 04:21
Have there been any reported issues with madVR causing audio crackling issues? I've been struggling with it for a while, and hope someone could shed some light on whats happening.
This issue happens exclusively on my USB soundcard; my internal audio is fine (though i cant use earbuds with my internal audio, which is why i'm bothering with this at all).
When i use madVR with its internal h264 decoder disabled, the audio on many video files will begin to crackle. Its usually most noticeable when a person is talking, manifesting as a not-so-subtle crackle in the background; low pitched sounds and background music do not seem to trigger it. This happens with both FFDshow's video/audio decoder and LAV's video/audio decoder and all combinations of the two.
When madVR's internal decoder is enabled and preferred, the audio is perfectly fine. When another renderer is used - EVR/sync/CP, VMR9, Haali etc - along with h264 from FFDshow or LAV the audio is also perfectly fine.
I've downloaded builds as early as 0.62 (apparently the first release supporting 10 bit, which the sample below is) but the problem is still there.
The clip below seems to consistently present the issue for me
http://www.mediafire.com/?gqvb44nt2clyeya
Thanks for any help.
Check your DPC Latency, i'm using ati and had problems with it
adam777
25th March 2012, 10:59
Hello all,
As a general rule, what are the advantages/disadvantages of setting the queues bigger/smaller in madVR?
:thanks:
namaiki
25th March 2012, 11:08
Guys, any suggestions for what settings to use for glitch free playback in exclusive mode?
I've tried many combinations of the 'don't use the following options unless you absolutely need them for glitch free playback' options and some options were better, but I couldn't seem to figure it out...
I have a single monitor at 1920x1080 at ~47.952Hz. Videos are 23.976fps. Graphics card is a GeForce 330M. I'm using Forceware 263.08 as I couldn't hack any newer drivers to allow hybrid graphics switching.
ryrynz
25th March 2012, 12:22
Try playing with the CPU and GPU queues values and frames to be presented in advance, they seemed like the most important values, at least when I had a 550Ti. Other than that, why not just stick to windowed mode? For me, FSE has never appeared to offer a smoother playback experience, just saying you could save some time and hassle that way, if it works well for you that is.
cyberbeing
25th March 2012, 12:22
namaiki, have you tried the FSE (old path) by unchecking 'Present Frames in Advance'? I'd test that out with various settings both with and without Aero. Use Reclock as well, if you're not already. FSE (old path) behaves more similarly to Windowed mode in that it only presents unique frames as needed, not every single VSync like FSE (new path).
In my experience, NVIDIA GPUs are unable to use the default FSE (new path) effectively, especially at higher refresh rates. They seems to run into presentation performance issues when presenting many frames in advance, resulting in either glitches or stuttering w/o glitches (frames silently dropped which are not reported by madVR). For peak performance with the default FSE (new path) and an NVIDIA GPU, you need to set the frames presented in advanced to a low value of 2 or 3 frames. At that point it's just matter of how sensitive you are to an occasional missed VSync.
I concur with ryrynz, that if you can't get FSE working well enough, there is nothing wrong with sticking with Windowed when using an NVIDIA GPU.
In general with NVIDIA GPUs, Windowed > FSE (old path) >>>> FSE (new path).
In general with ATI GPUs, FSE (new path) >> FSE (old path) >>> Windowed.
druneau
25th March 2012, 13:16
I have a question about the GPU flushing options + non 24hz refresh rates for 24p content.
I run a 120hz LCD, and watch 24p content@120hz. do those options affect how the frames are displayed on the screen?
What I'm wondering is if there is a way to display "frame, black black black black frame black black black black frame" or will the nature of things make it so it's always the same frame repeated ~5times (120/24) then the next frame drawn on the screen?
Thanks,
e-t172
25th March 2012, 15:09
I have a question about the GPU flushing options + non 24hz refresh rates for 24p content.
I run a 120hz LCD, and watch 24p content@120hz. do those options affect how the frames are displayed on the screen?
No. They affect internal details about the way the GPU is used.
What I'm wondering is if there is a way to display "frame, black black black black frame black black black black frame" or will the nature of things make it so it's always the same frame repeated ~5times (120/24) then the next frame drawn on the screen?
The latter. The former would be horrible and unwatchable, especially with 24p on a LCD.
namaiki
25th March 2012, 15:33
namaiki, have you tried the FSE (old path) by unchecking 'Present Frames in Advance'? I'd test that out with various settings both with and without Aero. Use Reclock as well, if you're not already. FSE (old path) behaves more similarly to Windowed mode in that it only presents unique frames as needed, not every single VSync like FSE (new path).
In my experience, NVIDIA GPUs are unable to use the default FSE (new path) effectively, especially at higher refresh rates. They seems to run into presentation performance issues when presenting many frames in advance, resulting in either glitches or stuttering w/o glitches (frames silently dropped which are not reported by madVR). For peak performance with the default FSE (new path) and an NVIDIA GPU, you need to set the frames presented in advanced to a low value of 2 or 3 frames. At that point it's just matter of how sensitive you are to an occasional missed VSync.
I concur with ryrynz, that if you can't get FSE working well enough, there is nothing wrong with sticking with Windowed when using an NVIDIA GPU.
In general with NVIDIA GPUs, Windowed > FSE (old path) >>>> FSE (new path).
In general with ATI GPUs, FSE (new path) >> FSE (old path) >>> Windowed.
Aaah! I can't believe I didn't even think of trying the old render path. It's like butter.
Disabling fullscreen exclusive mode and just using Aero is also just about perfect when using my laptop's nVidia GPU, but it's Intel GPU (old manual selectable/switchable graphics) is too slow to keep up when exclusive mode is disabled.
:thanks: a lot. I should be able to get through some more movies. Everytime I see a glitch (and they would always come up during pans) I would be extremely tempted to pause the movie and fiddle to test different settings.
Yup, disable Aero in fullscreen and reduce GPU queue size and it's surprisingly usable on the Intel HD graphics chip as well.
Owyn
25th March 2012, 17:41
Send bug report in madVR doesn't work, just opens this:
http://s45.radikal.ru/i109/1203/ef/8b36ad367ce7.png
So far had two errors, last one crash when I tried to fullscreen video, could sent none reports due to this shown on image.
dansrfe
25th March 2012, 18:45
I realize this may be off topic a bit but does anyone know what are the most accurate timings I can input for 23.976Hz on nvidia cpl? I find it weird that nvidia reports that my tv supports 23Hz, 24Hz, and 60Hz yet the 23Hz is more like 23.96Hz when using the default timings.
Kado
25th March 2012, 18:57
I've been checking the "black screen" issue....
I get black screen only in windowed mode (fullscreen has image) if:
general settings: (enabled) use a separate device for presentation + (enabled) use d3d11 for presentation
exclusive mode settings: (enabled) present several frames in advance
I get black screen windowed + fullscreen if:
general settings: (enabled) use a separate device for presentation + (disabled) use d3d11 for presentation
exclusive mode settings: (enabled) present several frames in advance
Disabling "present several frames in advance" fixes black screen for windowed + fullscreen
Hope this helps.
Windows 7 x64 + mpc hc latest + latest madvr + 301.10 + gtx 470
Kado
nevcairiel
25th March 2012, 19:06
Disabling "present several frames in advance" fixes black screen for windowed + fullscreen
I can confirm this, switching to the "old" exclusive mode fixes playback in both windowed and FSE on my 680 with the 301.10 driver.
With the new mode, even windowed is always just black.
Mosu
25th March 2012, 19:15
Feature request: an option to disable the global hotkeys.
I know you have them enabled because there are situations in which the player is not the active window for some kind of reason. I've also read that you have vague plans to make the hotkeys configurable sometime. I'd ask you to add an option to at least disable them completely. I don't use them -- at all! Don't have to, maybe never will.However, I'm programming in Emacs at the same time, and Ctrl-R and Ctrl-J are both often used keys that I simply cannot use while madVR is running.
Thanks.
Budtz
25th March 2012, 19:21
In general with NVIDIA GPUs, Windowed > FSE (old path) >>>> FSE (new path).
In general with ATI GPUs, FSE (new path) >> FSE (old path) >>> Windowed.
I this really correct? could Nev or Mad chime in here?
kalston
25th March 2012, 19:39
For me (GTX 275, latest WHQL drivers) it's old FSE >> Windowed (I always have Aero disabled if that matters) >>>>>>>>>>>>>> new FSE (even when messing around with all combinations of settings it's never glitch free for me).
TheShadowRunner
25th March 2012, 19:47
I think this has less to do with the videocard brand than it has to do with the OS.
On XP, old FSE = FSE > Windowed, but mostly all provide rock solid smoothness
Although of course FSE is rock solid with the certitude it won't mess-up during the entire length of the movie.
Windowed on the other hand.. i've seen tearing once or twice.
cyberbeing
25th March 2012, 21:00
For myself on WinXP and Win7 (Aero disabled), my NVIDIA GPUs behaved identically. Using my custom flush settings with Windowed Mode + ReClock was > ALL, offering perfect smoothness, and never tearing. FSE (old) would occasionally stutter on pans. FSE (new) was nearly completely unusable.
At this point I'd more suspect that there are just some odd-ball NVIDIA architectures, namely G8x & G9x which behave quite differently compared to G7x, GT2xx, GF1xx with madVR. That's just speculation though, but it's as good a guess as any. After-all, you have a G8x, and madshi was using a G9x (9600 GT) as his NVIDIA test GPU when he was coding the FSE modes (old and new).
It still continues to amaze me how often people come up with completely different madVR settings they find work the best. Too many unknown variables, not enough data.
Razoola
26th March 2012, 04:48
I this really correct? could Nev or Mad chime in here?
I think in a way it is (at least the nvidia part), it all depends on your flush settings. Dont flush, Dont flush, Dont flush,Flush and wait (sleep) is probably the best settings with the new render path, on my system set like that the new and old paths preform the same for my nvidia cards.
DragonQ
26th March 2012, 12:25
I realize this may be off topic a bit but does anyone know what are the most accurate timings I can input for 23.976Hz on nvidia cpl? I find it weird that nvidia reports that my tv supports 23Hz, 24Hz, and 60Hz yet the 23Hz is more like 23.96Hz when using the default timings.
"23 Hz" is supposed to be 23.976 Hz.
As for settings for exact timings, it depends on so many factors it's not worth suggesting anything. You just have to play around with it.
chros
26th March 2012, 20:55
In my experience, NVIDIA GPUs are unable to use the default FSE (new path) effectively, ...
... stuttering w/o glitches (frames silently dropped which are not reported by madVR).
I'm interested in this. Is it can be true?
Because if it's true there's no way to confirm that the playback is rock solid or not ... :(
nevcairiel
26th March 2012, 21:10
I get perfect playback on my NVIDIA with the new FSE, it just needs some patience to find the proper settings. This is only on Win7, and only with Fermi series cards. The only real problem with the new FSE is now with the new 300 series driver where it just doesn't work at all, but before that it worked just perfectly fine.
Windowed Mode without Aero would show Tearing during the first few minutes of a movie until it properly locked onto the VSync, with Aero it worked mostly fine. Never really compared old FSE because new worked just fine for me.
Of course there is always the possibility of some hidden issues (possibly also repeated frames, which madVR doesn't track), but i also had my fair share of problems with madVR on an ATI/AMD system, so its not really the universal solution to just switch.
chros
27th March 2012, 08:38
I get perfect playback on my NVIDIA with the new FSE, it just needs some patience to find the proper settings. This is only on Win7, and only with Fermi series cards.
Nev, can you tell us what are your settings?
(player, splitter, decoder, aero on/off, driver settings (default/custom), madvr settings)
Thank you!
cyberbeing
27th March 2012, 09:22
Because if it's true there's no way to confirm that the playback is rock solid or not ... :(
I've always confirmed if playback is rock solid enough through extensive testing with various panning scenes using my eyes. Even with madVR showing perfect stats, you can still have stuttering with the wrong Flush and other advanced madVR tweaks. Other times you can have perfect stats and never get things smooth. And yet other times you can find two settings, neither of which noticably stutter, yet one is still feels subjectively smoother than the other on certain panning scenes. I'd always recommend using Reclock give you a better chance of getting things perfect, since it can resolve various issue resulting from a bad reference audio clock (which D3D and madVR depend on), or a less than perfect refresh rate.
Windowed Mode without Aero would show Tearing during the first few minutes of a movie until it properly locked onto the VSync
I've used both GTX470 and GT440 DDR5 Fermi cards, and neither produced any tearing on Win7 with Aero disabled, as long as 'After Last Render Step' was set to Flush or Flush & Wait. You make it sound like the combination of your GPU and Monitor/TV is having trouble locking in the refresh rates. Do you see madVR's refresh rate reading fluctuate a lot for the first few minutes?
Who really knows, it could just be variations among different CPU architectures and motherboard chipsets, stranger things have happened. DPC and other types of latency can certainly vary widely from computer to computer. I'd also expect QueryPerformanceCounter readings could show slight accuracy differences among different architectures, especially in cases of bad BIOS/Chipset implementations.
i also had my fair share of problems with madVR on an ATI/AMD system, so its not really the universal solution to just switch.
I have as well. With my ATI 5750 1GB, I haven't been able to get it 100% stable with anything but FSE (new path). Windowed mode has intermittent stuttering no matter what settings I use. All things considered, I still favor NVIDIA cards for use with madVR.
Note: In case it's noteworthy, I have never used HDMI or 23.976Hz refresh rate on any of my setups. Always DVI and higher multiple refresh rates like 48Hz, 72Hz, 96Hz, 120Hz.
nevcairiel
27th March 2012, 09:30
I've used both GTX470 and GT440 DDR5 Fermi cards, and neither produced any tearing on Win7 with Aero disabled, as long as 'After Last Render Step' was set to Flush or Flush & Wait.
I probably didn't try those flushing options, tbh i only tried without Aero for a brief period when refresh rate switching would cause the compositor fps to be stuck at a wrong value, which was fixed now.
Regarding refresh rates, i did observe that running on high refresh rates increases the chance of playback problems with some configurations. 24p playback at 23.976Hz seems mostly fine, at the same time playing 25p at 50Hz had some minor glitches in the same config.
Doubt HDMI vs DVI would make such a big difference, but then my TV doesn't have DVI. ;)
magnusr
27th March 2012, 10:38
My GTX 680 findings with NVIDIA WHQL driver 301.10. Windows 7 X64 SP1. Connected to 63" Samsung Plasma using hdmi.
Had to do the inf fix for 0-255 rgb before install.
Madvr gave a blank picture (all black) if "use a separate device for presentation (Vista / Windows 7 only)" was checked. When that was unchecked everything worked as normal :)
shaolin95
27th March 2012, 17:36
So exclusively for Image Quality, if I am running 1080p bluray files, there is no IQ difference using an ATI, NVIDIA card or CPU even for as long as all settings are the same? I am trying to understand if the benefits of using a Nvidia card with hardware decoding is mostly for applying filters and the likes when upconverting files.
Thanks
sneaker_ger
27th March 2012, 20:09
So exclusively for Image Quality, if I am running 1080p bluray files, there is no IQ difference using an ATI, NVIDIA card or CPU even for as long as all settings are the same?
Correct.
I am trying to understand if the benefits of using a Nvidia card with hardware decoding is mostly for applying filters and the likes when upconverting files.
Using hardware decoding has no impact on image quality.
shaolin95
27th March 2012, 20:41
Correct.
Using hardware decoding has no impact on image quality.
Thank so since with my current setup I am using madvr but with the dxva native as my card cannot run copyback, I am still getting the most of it?
I was about to get a gtx460 for cuvid but if I am not going to improve my IQ at all then no point since performance wise, it runs perfectly smooth at ~47.956 for my projector.
Thanks
nevcairiel
27th March 2012, 20:47
If you use DXVA native, then you don't use madVR.
In that case, using madVR could potentially improve quality (on 1080p the difference is much smaller then when upscaling, though)
shaolin95
27th March 2012, 20:56
If you use DXVA native, then you don't use madVR.
In that case, using madVR could potentially improve quality (on 1080p the difference is much smaller then when upscaling, though)
A darn it, so I am not really using it at all :(
Ok well, I do have a gts 250 on my main computer. I can put it on my HTPC to see if it makes a difference as a test.
Thanks for the information! :)
sneaker_ger
27th March 2012, 21:01
Note that when you choose "DXVA2 (native)" in LAV Video, you will still use madVR. It's just that LAV will automatically fall back to pure software decoding. Players like MPC-HC allow you to see which filters are actually being used (if you can't identify the distinctive madVR OSD). Also madVR will display a tray icon when in use by default.
shaolin95
27th March 2012, 21:16
Note that when you choose "DXVA2 (native)" in LAV Video, you will still use madVR. It's just that LAV will automatically fall back to pure software decoding. Players like MPC-HC allow you to see which filters are actually being used (if you can't identify the distinctive madVR OSD). Also madVR will display a tray icon when in use by default.
Yes that was confusing me because I do see madvr icon on the tray and all that.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.