View Full Version : madVR - high quality video renderer (GPU assisted)
huhn
4th April 2014, 13:06
I still can't get my head around how 4 GB/s is limiting the performance of the video card when using NNEDI. It must be a very poor/slow implementation on AMD's part for the OpenCL/Direct3D interop, an issue they apparently don't have when it is DirectCompute/Direct3D. At least I can still watch DVD/480p content using luma doubling/quadrupling, where it makes a bigger difference. Since my computer is relatively modern and high spec, I never thought I would run into an issue like this :( I just don't see AMD fixing this any time soon, if ever.
it looks like amd didn't have a interop for D3D <-> OpenCl it looks like it goes over the cpu else the pci-e speed wouldn't matter at all for this.
it looks like amd didn't have a interop for D3D <-> OpenCl it looks like it goes over the cpu else the pci-e speed wouldn't matter at all for this.
If that is what is actually happening then it sounds like it goes through some emulation layer or something. A very bad idea/implementation for their part.
leeperry
4th April 2014, 14:20
it looks like amd didn't have a interop for D3D <-> OpenCl it looks like it goes over the cpu else the pci-e speed wouldn't matter at all for this.
What's even more obvious is that we're throwing money out the window when the real-world yield fps rate is so low....whatever power consumption or graphic card price-wise. Should the interop be a non-issue even the lowest grade AMD boards would be NNEDI monsters, possibly with passive cooling too :o
So how do 660's score with NNEDI then? Anyone's with a 660 around please?
SecurityBunny
4th April 2014, 16:15
Are you sure you didn't mess with your player settings to cause this?
For example, MPC-HC should be set to Video Frame -> "Touch from inside" and "Keep Aspect Ratio", as well as Pan&Scan should be off (use "Reset" to clear any settings).
Sounds to me like you have it set to "Touch from outside" instead.
Thank you so much! I don't believe I've changed any settings and can't find any in options menu. However, I hit reset, disabled lav decoding again, re-enabled madvr (and the such) and it all displays properly now! I must have hit a shortcut key if one exists.
Thunderbolt8
4th April 2014, 19:36
has the OpenCL rendering dialog moved to general settings? (use OpenCL to process DXVY NV12 surfaces)
michkrol
4th April 2014, 20:05
has the OpenCL rendering dialog moved to general settings? (use OpenCL to process DXVY NV12 surfaces)
Not sure what you mean, but it has nothing to do with NNEDI scaling/doubling (which uses OpenCL).
This option is only used if you're using DXVA Native decoding. It speeds up rendering in some cases.
Anime Viewer
4th April 2014, 20:38
NNEDI3 behaves strangely depending on the neuron and scaling combinations IMO. For example I have two of the same video I was testing it with - one a 480p version, and the second a 720p version. If I set NNEDI3 chroma upscaling to 63 neurons and expand the video to full screen (1920x1080) it runs fine with no dropped frames, but if keep the settings the same and play the 720p version at full screen (again 1920x1080) it drops frames like crazy. I would think it would be more work for it to upscale the 480, but that doesn't seem to be the case. I don't suppose its a bug, is it? Anyone care to explain why upscaling from 480 to 1080p is easier for it to do than upscaling from 720p to 1080p?
I've come across two options to prevent dropped frames given the situation (since going in and changing the neurons every time I want to watch a 720p video is impractical).
One is to add 720p60 and 720p59 to devices (its the built in notebook screen, so 60hz and 59hz are the only settings it accepts) -> name of screen -> display modes -> list of all display modes madVR may switch to: area in madVR settings (in which case no up-scaling is done, but video playback quality isn't as good (more blurry looking) since its not the screens native resolution. The second is to turn neurons down to 32 from the 64 (and leave the 720p options off the switchable display mode settings) which also causes a drop in visual quality.
Which do you think is the better way to run?
Leave NNEDI3 neurons at 64, and allow screen sizing of 720p, or drop to 32 neurons and keep everything upscaling to 1080p?
nevcairiel
4th April 2014, 20:42
Anyone care to explain why upscaling from 480 to 1080p is easier for it to do than upscaling from 720p to 1080p?
Scaling performance depends on the number of pixels to process, not strictly on the scaling factor.
More input pixels takes more time - similar, more output pixels would take more time (ie. higher target resolution), but if the target resolution is the same, smaller source video is just faster, because it has less input to process.
Which do you think is the better way to run?
Leave NNEDI3 neurons at 64, and allow screen sizing of 720p, or drop to 32 neurons and keep everything upscaling to 1080p?
Don't change the resolution, your TV/Screen will then do the scaling and it'll be terrible.
Instead, setup profiles!
Setup one profile with 64 neurons for SD content, and a second profile for 32 neurons for 720p content. Problem solved! :)
Anime Viewer
4th April 2014, 21:16
Instead, setup profiles!
Setup one profile with 64 neurons for SD content, and a second profile for 32 neurons for 720p content. Problem solved! :)
Based on your suggestion I did the following (tell me if this sounds like the wrong way to do it):
I right clicked on scaling algorithms, and clicked the create profile group button (and checked the box for chroma upscaling).
(A new folder appeared which I named "upscaling per content")
In that new folder there were two folders (named Profile 1 and Profile 2), I renamed the top to "480p" and inside that I set chromas upscaling to NNEDI3 and 64 neurons. I clicked on the button that says edit shortcut and pressed "4". I renamed the bottom Profile to "720p" and inside that I set chromas upscaling to NNEDI3 and 32 neurons. I clicked on the button that says edit shortcut and pressed "7".
Now I need to remember to press 4 when viewing 480p content and 7 when viewing 720p content...
iSunrise
4th April 2014, 21:25
Which do you think is the better way to run?
Leave NNEDI3 neurons at 64, and allow screen sizing of 720p, or drop to 32 neurons and keep everything upscaling to 1080p?
For 720p content and your 1080p output size, NNEDI3 with 32 neurons is more than enough. I even lower that to 16 if I want to use smooth motion for 720p content to still have some breathing room. I would go as far to say that 64 is already overkill in your specific case.
Use a good quality dithering and NNEDI3 chroma upscaling and doubling. The higher neuron counts may give you benefits in still pictures, but if you don't zoom or your source isn't of very low resolution, just be sure to use NNEDI3 for both and don't focus that much on just the neurons.
I personally would trade neurons for more features active at any time.
janderclander14
4th April 2014, 21:30
I'm currently using an anamorphic lens in my projection setup so I need to perform a vertical stretch of the picture (2.35 to 16:9) in order to maintain the aspect ratio after the horizontal stretch of 1.33x performed by the lens. I'm using the latest MadVR and MPC-HC as player.
Currently, I'm doing the vertical stretch (2.35 to 16:9) by using the MPC-HC option "video-frame->override aspect ratio->16:9", which correctly modifies the aspect ratio. The question is: with this option is MadVR doing the vertical stretch or it is the media player which stretches the picture a priori? If the latter was the case, is there any option to force MadVR to do the stretch in order to benefit from the high quality upscaling?
I think NNEDI3 is ideal in such scenario because with a 720p 2.35 movie which usually has a resolution of 1280x540, the upscaling to 1080p 16:9 in the anamorphic setup (1980x1080) will exactly double the vertical resolution (540->1080) thus avoiding from any posterior vertical downscaling (horizontal resolution will be also doubled to 2560 so that it still requires from downscaling). Am I right? Is there any way to crop the vertical resolution of any video to 540 (in case it was 544 or something like this) in order to avoid any vertical downscaling (such as 544 ->NNEDI3-> 1088 ->Downscaling-> 1080)?
madshi
4th April 2014, 21:49
I must precise again that these errors only show up with High10.
Well, I'm not sure what to say, it sounds quite weird. High10 content could slow uploading down, but then the upload queue should be empty. If it's not empty, I don't see how it could be a problem. So I don't quite understand why High10 should behave differently to other sources. At this point I'm not sure what to suggest other than trying to reinstall the drivers, or maybe try a different GPU driver version. If that doesn't help, upload a debug log, maybe I can see something (but I doubt it).
While experimenting around with different forms of combinations it looks like optimus (and manybe AMD's hybrid) may be able to run in a hybrid state. While using the force registry key to Nvidia, and selecting the Intel gpu for MPC-HC in Nvidia control panel it looks like it may have used a combination of the two gpu. The NNEDI3 continued to render using the Nvidia because the screen didn't turn green and render times didn't shoot up drastically (like when I force the Intel in the registry), but the render times did increase ~5-7ms over the times when run with Nvidia control panel and the registry set to Nvidia. Potentially if other things besides OpenCL could be forced (like DirectCompute) people with dual gpu systems could eliminate the weaker of the two gpu's when it comes to using certain features. People with hybrid amd/intel systems might be able to get around the OpenCL interop bug if they set their systems to force the Intel in the registry, but tell their system to use the AMD for MPC-HC (or whatever other video player - like POT - they may be using).
I can only force OpenCL, and I'm surprised even that worked.
Just reporting in to say the OpenCL registry tweak does the trick for my HD 4000 / GT 650M.
Good to hear!
for people like me with crap gpu's and not much (or any) expendable income (i.e.: me). fse provides much more stable performance with far less frame drops/presentation glitches (at least on my rig)
FWIW, the question was not whether FSE mode was still needed, it most definitely is. The question was whether the *old* (outdated) FSE rendering mode was still needed. There's a new and an old mode. The new mode is enabled by default.
So how do 660's score with NNEDI then? Anyone's with a 660 around please?
According to nevcairiel a bit faster than with the 750, but it runs error diffusion slower than a 750. So if wanted to go NVidia now I'd get a 750Ti. Or wait for faster Maxwell cards.
Thank you so much! I don't believe I've changed any settings and can't find any in options menu. However, I hit reset, disabled lav decoding again, re-enabled madvr (and the such) and it all displays properly now! I must have hit a shortcut key if one exists.
The setting is in MPC-HC when you right click on the video and then "Video Frame -> ...". You probably accidently had that changed to "touch window from outside".
One is to add 720p60 and 720p59 to devices (its the built in notebook screen, so 60hz and 59hz are the only settings it accepts) -> name of screen -> display modes -> list of all display modes madVR may switch to: area in madVR settings (in which case no up-scaling is done, but video playback quality isn't as good (more blurry looking) since its not the screens native resolution.
If you play a 720p video with a 720p output mode, NNEDI3 will not be used at all. You'd get better image quality by simple disabling NNEDI3, or using a lower neuron count.
Based on your suggestion I did the following (tell me if this sounds like the wrong way to do it)
You don't need to use keyboard shortcuts. You can use the "profile autoselect rules" to make madVR autoswitch the profiles according to your needs.
Currently, I'm doing the vertical stretch (2.35 to 16:9) by using the MPC-HC option "video-frame->override aspect ratio->16:9", which correctly modifies the aspect ratio. The question is: with this option is MadVR doing the vertical stretch or it is the media player which stretches the picture a priori?
The media player never stretches the video. It's always the video renderer doing all the work. All the media player does is tell the video renderer how to stretch.
I think NNEDI3 is ideal in such scenario because with a 720p 2.35 movie which usually has a resolution of 1280x540, the upscaling to 1080p 16:9 in the anamorphic setup (1980x1080) will exactly double the vertical resolution (540->1080) thus avoiding from any posterior vertical downscaling (horizontal resolution will be also doubled to 2560 so that it still requires from downscaling). Am I right? Is there any way to crop the vertical resolution of any video to 540 (in case it was 544 or something like this) in order to avoid any vertical downscaling (such as 544 ->NNEDI3-> 1088 ->Downscaling-> 1080)?
Once you've upscaled video to twice its resolution, the resulting image is soft enough that some small additional scaling operations won't do much harm to the image (at least when using a reasonably good algorithm). So you don't really need to worry about avoiding additional vertical scaling, IMHO.
tp4tissue
4th April 2014, 21:53
hi dudes.. i keep seeing this opencltesttool come up... finally decided to dl it.. er... can't get it to run? does it have to be ran through commandline?
Anime Viewer
4th April 2014, 23:02
You don't need to use keyboard shortcuts. You can use the "profile autoselect rules" to make madVR autoswitch the profiles according to your needs.
:eek:That's excellent to hear (less user work, and no worry about other hotkeys being conflicted with or overwritten). If I'd looked more extensively into how profiles worked I probably would have figured that out. :o At least this way other people learning to setup profiles, and reading the posts here might have more information going in, and less questions.
Based on the the description and naming convention I described before (I also added a profile for 360p content using 128 neurons) something as simple as:
if (srcWidth = 360) "360p"
else if (srcWidth = 480) "480p"
else "720p"
in the upscaling per content profile auto select rules should work. (or do I have to include srcHeight every time I use scrWidth?)
Should it be displaying a grey transparent pop-up bubble displaying the rule when the video opens (similar to how it displays the tile when opening a file, or how the pressing the shortcut key pops up the bubble)? (If so I'm not seeing it with that auto rule set when opening the different resolution videos).
If you play a 720p video with a 720p output mode, NNEDI3 will not be used at all. You'd get better image quality by simple disabling NNEDI3, or using a lower neuron count.
I'm a bit confused by that statement. If we've got 720p video playing on a 720p output, or 1080p video playing on a 1080p output all the upscaling and doubling (in scaling algorithms) should be disabled by default (I understand that), but are you saying there is some other way/place NNEDI3 should be disabled as well?
Asmodian
5th April 2014, 00:36
if (srcWidth = 360) "360p"
else if (srcWidth = 480) "480p"
else "720p"
in the upscaling per content profile auto select rules should work. (or do I have to include srcHeight every time I use scrWidth?)
You don't have to use srcHeight with srcWidth but I would use >= or <= for the comparison. Videos often have had small crops off the standard resolutions. In your script "720p" would be used for a video with a width of 356.
Should it be displaying a grey transparent pop-up bubble displaying the rule when the video opens (similar to how it displays the tile when opening a file, or how the pressing the shortcut key pops up the bubble)? (If so I'm not seeing it with that auto rule set when opening the different resolution videos).
No rule display, the rule is bolded in the settings it is in use though.
Which do you think is the better way to run?
Leave NNEDI3 neurons at 64, and allow screen sizing of 720p, or drop to 32 neurons and keep everything upscaling to 1080p?
I'm a bit confused by that statement. If we've got 720p video playing on a 720p output, or 1080p video playing on a 1080p output all the upscaling and doubling (in scaling algorithms) should be disabled by default (I understand that), but are you saying there is some other way/place NNEDI3 should be disabled as well?
If you are watching a 720p video on a native 1080p screen you would get much better quality by leaving the display mode at 1080p and letting madVR do the scaling. Turn off NNEDI entirely if you have to but do not use a non-native resolution. Monitors or laptop screens usually do not have good scalers, this "(more blurry looking) since its not the screens native resolution" is much worse than using Jinc3 instead of NNEDI. It looks like you are figuring out profiles so maybe this is a non issue now. :)
Guest
5th April 2014, 01:05
hi dudes.. i keep seeing this opencltesttool come up... finally decided to dl it.. er... can't get it to run? does it have to be ran through commandline? Please give the download link. I cannot find it with a search on this forum for "opencltesttool".
Audionut
5th April 2014, 01:09
Here Don. http://forum.doom9.org/showthread.php?p=1676116#post1676116
Guest
5th April 2014, 01:19
Thanks. I was able to run it by double clicking and through CLI. In both cases it crashed. :(
Anyway it seems OT for this thread.
madshi
5th April 2014, 08:31
Thanks. I was able to run it by double clicking and through CLI. In both cases it crashed. :(
I had written that tool because someone in this thread had claimed to have contact to an AMD employee willing to look into the slow OpenCL <-> D3D9 interop problem. This tool should work fine on Intel and AMD GPUs, but it will crash on NVidia GPUs because the tool depends on OpenCL 1.2 being available, and NVidia doesn't support OpenCL 1.2.
The tool was more useful than I thought, though, in that it helped identify that the interop speed seems to depend on the PCIe version/speed. Basically it seems that AMD is currently doing the interop by copying the GPU RAM to CPU RAM and then back to GPU RAM. Ouch.
John Carmack
5th April 2014, 12:17
If it can help, here is another AMD radeon OpenCLSpeedTest result. With a R9 280X (renamed 7970 Ghz).
http://t.imgbox.com/6qMW1eXN.jpg (http://imgbox.com/6qMW1eXN)
madshi
5th April 2014, 12:21
Here's a new test build:
http://madshi.net/madVRwindowedTest.rar
This test build implements a new windowed presentation path, which is pretty much identical to the way FSE works. Meaning, I'm presenting several frames in advance. This used to not work in windowed mode in older OSs. But beginning in Windows 7, with Aero turned on, it seems to work reasonably well. I'm getting slightly more reliable playback in windowed mode on Windows 8.1 x64 here with this new windowed mode presentation path, compared to the old path.
Give it a try and let me know how it works for you!
The new presentation path only works in Windows 8/8.1, or in Windows 7 with Aero/DesktopComposition enabled. You can detect which mode is used by looking at the debug OSD (Ctrl+J). The old windowed mode path shows a "backbuffer queue", the new path shows a "present queue". You can select which path to use by checking/unchecking the "present several frames in advance" in the windowed mode settings page.
vivan
5th April 2014, 12:21
if (srcWidth = 360) "360p"
else if (srcWidth = 480) "480p"
else "720p"You don't have to use srcHeight with srcWidth but I would use >= or <= for the comparison. Videos often have had small crops off the standard resolutions. In your script "720p" would be used for a video with a width of 356.Also I would add that "360p" is video with 360 pixels height (e.g. 640x360), not width (360x204?).
So you probably should use srcHeight instead.
if (srcHeight <= 360) "360p"
else if (srcHeight <= 480) "480p"
else "720p"
John Carmack
5th April 2014, 12:42
Here's a new test build:
http://madshi.net/madVRwindowedTest.rar
This test build implements a new windowed presentation path, which is pretty much identical to the way FSE works. Meaning, I'm presenting several frames in advance. This used to not work in windowed mode in older OSs. But beginning in Windows 7, with Aero turned on, it seems to work reasonably well. I'm getting slightly more reliable playback in windowed mode on Windows 8.1 x64 here with this new windowed mode presentation path, compared to the old path.
Give it a try and let me know how it works for you!
The new presentation path only works in Windows 8/8.1, or in Windows 7 with Aero/DesktopComposition enabled. You can detect which mode is used by looking at the debug OSD (Ctrl+J). The old windowed mode path shows a "backbuffer queue", the new path shows a "present queue". You can select which path to use by checking/unchecking the "present several frames in advance" in the windowed mode settings page.
It actually solves my issues, wonderful. It brings (me) better performances than FSE while suppressing the UI lag.
ryrynz
5th April 2014, 12:59
It actually solves my issues, wonderful. It brings (me) better performances than FSE while suppressing the UI lag.
Shouldn't FSE mode be the better of the two? Madshi, any idea's what might be hampering FSE mode in comparison to the new windowed mode at least in John's case?
6233638
5th April 2014, 12:59
This test build implements a new windowed presentation path, which is pretty much identical to the way FSE works. Meaning, I'm presenting several frames in advance. This used to not work in windowed mode in older OSs. But beginning in Windows 7, with Aero turned on, it seems to work reasonably well. I'm getting slightly more reliable playback in windowed mode on Windows 8.1 x64 here with this new windowed mode presentation path, compared to the old path.
Give it a try and let me know how it works for you!Overlay mode is broken for me in this build, but regular Windowed Mode seems to be working fine.
It did not solve the issue I had where certain things changing the video LUT during playback (e.g. f.lux (http://justgetflux.com/) set to a 60 minute transition) would cause it to drop frames though, which only FSE manages to avoid.
ryrynz
5th April 2014, 13:20
Madshi, the new windowed mode in full screen on my HD4000/Windows 7 PC using MPC-BE, there's lowish render and present queues (f.lux disabled) 2 or 3-4/8 and 5-6/8, simply pausing video and pressing play brings them both up to 7-8/8 where they remain rock solid.
Is it normal that the queues get reloaded when going from windowed to full screen windowed mode?
John Carmack
5th April 2014, 13:28
Shouldn't FSE mode be the better of the two? Madshi, any idea's what might be hampering FSE mode in comparison to the new windowed mode at least in John's case?
Yes, it should have been worse than FSE, but I have some problems with FSE bringing me presentation glitches and stuttering. These gains are probably only personals. The FSE UI lag isn't imaginary, though.
leeperry
5th April 2014, 14:10
According to nevcairiel a bit faster than with the 750, but it runs error diffusion slower than a 750. So if wanted to go NVidia now I'd get a 750Ti. Or wait for faster Maxwell cards.
OK sounds good! But the 750Ti won't be available before a few months and it'll remain overpriced for quite some time....within a few weeks it'll be +35°C in my area, I guess I'll have to seriously mod the heatsink of my 7850 with proper thermal paste and an oversized slow fan.
BTW, I guess this might help seeing clear through AMD's lies:
HD 7770 -> R7 250X
HD 7790 -> R7 260X
HD 7850 -> R7 265
HD 7870 -> R9 270X
HD 7950 v2 -> R9 280
HD 7970 GHz Edition -> R9 280X
At this point, the non-Maxwell nvidia's seem lagged out for our needs, current AMD's are essentially overpriced 78xx's......it's a good bet that the next AMD boards will also suffer from the interop lag so basically Maxwell is where the party will be early/mid next year.
The tool was more useful than I thought, though, in that it helped identify that the interop speed seems to depend on the PCIe version/speed.
Is there any way you could recompile it with a less exotic VC++ runtime please? Or possibly add the required DLL's to the redist? I get a SideBySide error message even though I've got the VC++ 2005/2010/2012/2013 runtime libraries installed :o
James Freeman
5th April 2014, 14:14
Here's a new test build:
http://madshi.net/madVRwindowedTest.rar
Give it a try and let me know how it works for you!
I works, even better than the regular windowed mode, and faster.
But it also broke the Overlay mode which I like using with 3DLUT.
Also, is something wrong with the official madVR.zip on the first post?
Its now a bad zip, I can't revert back to 87.9.
iSunrise
5th April 2014, 14:37
Here's a new test build:
http://madshi.net/madVRwindowedTest.rar
This test build implements a new windowed presentation path, which is pretty much identical to the way FSE works. Meaning, I'm presenting several frames in advance. This used to not work in windowed mode in older OSs. But beginning in Windows 7, with Aero turned on, it seems to work reasonably well. I'm getting slightly more reliable playback in windowed mode on Windows 8.1 x64 here with this new windowed mode presentation path, compared to the old path.
Thanks, sounds good.
Did some testing:
Very good job. On my system, the new windowed mode is definitely faster. Watching a 720p 23.976fps movie I get an average of 0.06ms and max stats 0.09ms with the new windowed mode path. After enabling (and restarting the player and the movie to make it comparable) the old windowed mode I get present times of 0.10ms and 0.11/0.12ms. Nice improvement. Stats also seem more stable, but don't take that as granted, just an observation by looking at the stats for several seconds.
You can select which path to use by checking/unchecking the "present several frames in advance" in the windowed mode settings page.
There seems to be a bug when disabling and re-enabling the "present several frames in advance" checkbox. At least on my system the renderer comes to a complete halt and only shows a still picture and video doesn't advance anymore (even though audio continues in the background). That's 100% reproducible, tried MPC-HC and PotPlayer.
OK sounds good! But the 750Ti won't be available before a few months and it'll remain overpriced for quite some time....within a few weeks it'll be +35°C in my area, I guess I'll have to seriously mod the heatsink of my 7850 with proper thermal paste and an oversized slow fan.
Must be a local problem then, because the 750Ti is widely available. And overpriced is like saying "better", it's all relative. If you like very low power consumption and good performance, there's not much else on the market right now that can rival it out of the box.
michkrol
5th April 2014, 15:04
Here's a new test build:
http://madshi.net/madVRwindowedTest.rar
Give it a try and let me know how it works for you!
On a quick test, smooth motion seems to like this new windowed mode better than the old one on my Intel HD4000. I used to get some kind of judder in windowed (with SM), that's gone with the new mode. Render times seem lower, but it's within measurement error (like 4,30ms down to 4,15ms).
Overall it works as good or better than the old mode for me.
Also, is something wrong with the official madVR.zip on the first post?
Its now a bad zip, I can't revert back to 87.9.
Just checked and it works correctly. There were reports of some false-positives with antivirus software, so be sure to check that.
leeperry
5th April 2014, 15:53
Must be a local problem then, because the 750Ti is widely available. And overpriced is like saying "better", it's all relative. If you like very low power consumption and good performance, there's not much else on the market right now that can rival it out of the box.
Oh, good point. I read some lenghty review stating it would only be available by this summer or a bit later.
So nobody took the plunge yet?
Overpriced as in "it will lose 50% of its value within 6 months so you're essentially paying a premium for being an early adopter".
James Freeman
5th April 2014, 16:21
Just checked and it works correctly. There were reports of some false-positives with antivirus software, so be sure to check that.
Nope, its still a corrupt zip file.
But here (http://www.videohelp.com/tools/madVR/old-versions) everything is fine.
madshi can you please check it?
nevcairiel
5th April 2014, 16:30
I downloaded the zip just now and it unpacks perfectly. Something must be screwy on your end.
John Carmack
5th April 2014, 16:51
Is there any way you could recompile it with a less exotic VC++ runtime please? Or possibly add the required DLL's to the redist? I get a SideBySide error message even though I've got the VC++ 2005/2010/2012/2013 runtime libraries installed :o
I had it too. Here's what you must download. https://www.microsoft.com/en-us/download/confirmation.aspx?id=26347
I'm currently using an anamorphic lens in my projection setup so I need to perform a vertical stretch of the picture (2.35 to 16:9) in order to maintain the aspect ratio after the horizontal stretch of 1.33x performed by the lens. I'm using the latest MadVR and MPC-HC as player.
Currently, I'm doing the vertical stretch (2.35 to 16:9) by using the MPC-HC option "video-frame->override aspect ratio->16:9", which correctly modifies the aspect ratio. The question is: with this option is MadVR doing the vertical stretch or it is the media player which stretches the picture a priori? If the latter was the case, is there any option to force MadVR to do the stretch in order to benefit from the high quality upscaling?
Definitely MadVR doing the work because I notice the rendering times increase for me when I'm playing 2.35:1 content vs 1.78/1.85:1 where I don't do that stretch.
I use the Pan&Scan>Scale to 16x9 to do the vertical stretch, however. Not sure there's any difference in the end result.
fairchild
5th April 2014, 17:11
New windowed test works fine here. I still need to use FSE though, since sometimes the desktop composition stays stuck in a previous Hz which causes massive frame drops. Only FSE picks up the correct refresh rate of the monitor. Not sure why/how this bug happens or if there is a workaround. example: play a file that has a 23.976 frame rate, which causes the composition rate to be 23.976Hz, which then causes frame drops since the display device is actually at 60hz. So the desktop composition would need to be 60hz to prevent frame drops when playing a 23.976 fps file on the 60hz display. I know I've brought this up in the past, and the bug keeps happening so FSE for life. :)
leeperry
5th April 2014, 17:47
I had it too. Here's what you must download. https://www.microsoft.com/en-us/download/confirmation.aspx?id=26347
Thanks but this won't install for some reason, I get an error message while installing assembly «Microsoft.VC80.ATL,type="win32",version="8.0.50727.6195",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="x86"».
That's too bad coz I'd love to put a figure on my interop lag.
burfadel
5th April 2014, 17:57
Thanks but this won't install for some reason, I get an error message while installing assembly «Microsoft.VC80.ATL,type="win32",version="8.0.50727.6195",publicKeyToken="1fc8b3b9a1e18e3b",processorArchitecture="x86"».
That's too bad coz I'd love to put a figure on my interop lag.
Open an elevated command prompt, and type:
fsutil resource setautoreset true C:\
then reboot. It should then work.
wolfman2791
5th April 2014, 18:10
@madshi. On the new test build, i get the message "madvr reports: -creating Direct3D device failed (8876086c)"when i enable windowed overlay. I'm running windows 8.1 x64 with a i5-3470 and a gtx 660 with 8gb RAM.
Edit: i don't think it has anything to do with the test build since the new feature is working. I just happened to check the windowed overlay box because i'd never tried it and i got this message. Not gonna miss it wince i never used this feature... but i thought i'd let you know.
nikola
5th April 2014, 19:50
Here's a new test build:
http://madshi.net/madVRwindowedTest.rar
Same error as others reported (Direct3D Device creation failed) when overlay is enabled, on a Haswell HD 4600 iGPU.
When switching off overlay, it works but with vsync issues, which I didn't notice in the latest stable release.
yok833
5th April 2014, 20:03
Is it possible to create a profil in madvr that takes the bit rate of the video in consideration? With bluray content I can't use 32 neurons chroma upscaling + error diffusion but I have no problem with any1080p MKV....
Envoyé de mon GT-I9300 en utilisant Tapatalk
aufkrawall
5th April 2014, 20:54
New windowed mode works well here with every sample I got. I will definitely keep using it as long as no issues appear.
cyberbeing
5th April 2014, 21:37
Visually unpleasing black flashes with madVRwindowedTest when resizing the video window, though I guess something like that is necessary side-effect of presenting in advance? If you could somehow mask what I assume is madVR flushing the present queue on resize, that would be nice.
turbojet
5th April 2014, 21:47
New windowed test works fine here. I still need to use FSE though, since sometimes the desktop composition stays stuck in a previous Hz which causes massive frame drops. Only FSE picks up the correct refresh rate of the monitor. Not sure why/how this bug happens or if there is a workaround. example: play a file that has a 23.976 frame rate, which causes the composition rate to be 23.976Hz, which then causes frame drops since the display device is actually at 60hz. So the desktop composition would need to be 60hz to prevent frame drops when playing a 23.976 fps file on the 60hz display. I know I've brought this up in the past, and the bug keeps happening so FSE for life. :)
Thought I was the only one that had this issue. The other workarounds that I found were disabling aero (madvr can do it) or restarting aero with admin rights: net stop uxsms & net start uxsms. Luckily it's not a problem with windows 8. Madvr osd doesn't even show composition rate, I wonder if the same could be applied with windows 7.
Same results as everyone else with the new test build, overlay broken but presenting frames in advance window mode finally 0 dropped frames over a 42 minute episode, never seen that before. Madvr was also using ivtc with 0 cadence breaks which is more impressive.
nevcairiel
5th April 2014, 21:51
Luckily it's not a problem with windows 8. Madvr osd doesn't even show composition rate, I wonder if the same could be applied with windows 7.
Desktop Composition was quite improved with Windows 8, I've personally encountered quite a few issues with the Windows 7 composition mode (which can be solved by restarting the compositor) that just went away when testing on Windows 8 instead.
QBhd
5th April 2014, 22:27
Desktop Composition was quite improved with Windows 8, I've personally encountered quite a few issues with the Windows 7 composition mode (which can be solved by restarting the compositor) that just went away when testing on Windows 8 instead.
Agreed... I made the switch to 8.1 from 7 and now I only check "delay playback start until render queue is full" and "enable automatic fullscreen exclusive mode". With Windows 7 I always needed to disable desktop composition, but not anymore with 8.1
QB
Anime Viewer
5th April 2014, 22:49
Here's a new test build:
http://madshi.net/madVRwindowedTest.rar
This test build implements a new windowed presentation path, which is pretty much identical to the way FSE works. Meaning, I'm presenting several frames in advance. This used to not work in windowed mode in older OSs. But beginning in Windows 7, with Aero turned on, it seems to work reasonably well. I'm getting slightly more reliable playback in windowed mode on Windows 8.1 x64 here with this new windowed mode presentation path, compared to the old path.
Give it a try and let me know how it works for you!
The new presentation path only works in Windows 8/8.1, or in Windows 7 with Aero/DesktopComposition enabled. You can detect which mode is used by looking at the debug OSD (Ctrl+J). The old windowed mode path shows a "backbuffer queue", the new path shows a "present queue". You can select which path to use by checking/unchecking the "present several frames in advance" in the windowed mode settings page.
So far its worked well in my testing on single screens, and when displaying on multiple monitors (notebook screen and tv) if I use an HDMI cable directly between them. However when I try to use Intel Widi/Miracast it drops frames quite quickly in both extend and duplicate modes whenever its set to present frames in advance (regardless of if its one or sixteen). I'll continue to experiment, and see if I can find a workaround for Widi/Miracast that doesn't involve shutting off the presenting frames in advance feature. Edit: Duplicate mode starts dropping them right at the start of the video, but Extend mode seems to go just short of 1 minute before it starts dropping frames.
(I was hoping the frames in advance feature might eliminate the issue of tearing on secondary monitors when using duplicate mode when using direct HDMI cables, but it looks like it unfortunately still exists).
SecurityBunny
6th April 2014, 00:16
Here's a new test build:
http://madshi.net/madVRwindowedTest.rar
This test build implements a new windowed presentation path, which is pretty much identical to the way FSE works. Meaning, I'm presenting several frames in advance. This used to not work in windowed mode in older OSs. But beginning in Windows 7, with Aero turned on, it seems to work reasonably well. I'm getting slightly more reliable playback in windowed mode on Windows 8.1 x64 here with this new windowed mode presentation path, compared to the old path.
Give it a try and let me know how it works for you!
The new presentation path only works in Windows 8/8.1, or in Windows 7 with Aero/DesktopComposition enabled. You can detect which mode is used by looking at the debug OSD (Ctrl+J). The old windowed mode path shows a "backbuffer queue", the new path shows a "present queue". You can select which path to use by checking/unchecking the "present several frames in advance" in the windowed mode settings page.
Using windows 8.1, I seem to be getting slightly better performance than FSE mode with this build! Although, only marginally better by .20-40 ms.
Checking and unchecking 'use a separate device for presentation' didn't seem to affect performance either way, so leaving that disabled.
Bumped windowed mode 'frames in advance' to 16, so queues are respectfully 24/20/16. Queues remained full, didn't receive any dropped frames except when starting the playback and going fullscreen.
I didn't notice any visual glitches with smooth motion enabled. I'm loving the new build and windowed mode, just for the performance and a responsive seek bar!
Is there any specific advantage to FSE that it should be used instead of windowed mode? I also do not have 'windowed overlay' enabled. Is there any advantage to enabling that option?
kasper93
6th April 2014, 00:55
@madshi: With new windowed mode, either with SM FRC enabled or disabled madVR draw 60fps. I guess it's expected? Before without SM it was just drawing at movie framerat IIRC.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.