View Full Version : madVR - high quality video renderer (GPU assisted)
nevcairiel
30th August 2011, 10:26
Somebody should bring it to their attention, dammit!
Its not like its a small "bug", their overall design by choosing OpenCL is severly limited, its doubtful that they'll design a new interface just like that. You can do the same with DXVA2, including deinterlacing, even without a renderer - except that its damn slow for ATI/AMD cards because of the limited GPU->CPU transfer speed.
I don't know if its a driver or a hardware problem, but i'm quite sure it affects all GPU->CPU transfers. AMD/ATI isn't all that famous for their HPC/GPGPU capabilities.
If they want to fix something, they should work on the transfer speed issue, and make using DXVA2-renderless support a viable alternative.
pankov
30th August 2011, 10:32
How often do you change background wallpapers during video playback? :eek:
I believe that he is not changing them manually but letting Windows 7 do it automatically (like I did before). There is such an option in the Desktop background configuration window.
Sadly it interferes with madVR even in Exclusive mode so I disabled it ... it was a nice feature otherwise.
madshi,
in the last few days I've noticed some random dropping of frames without any of the queues dropping low. They moved from 7-8/8 to 6/8 but not lower and despite this I got 5-9 dropped frames maybe in series of 3 for 2-3 seconds.
Sadly the problem is random and not reproducible
:(
I haven't change any settings in past few months and I'm pretty sure this problem didn't exist in v0.73.
I'll try to confirm if it's only v0.74 that has it but does anybody else experiencing the same and have any idea what could be wrong?
betaking
30th August 2011, 10:33
To madshi
If madvr.ax where the folder does not contain libmfxsw32.dll avcodec-53.mvr avutil-51.mvr these three files, then do not enable internal decoder! or put this seeting to Registry not to bin file! thanks!
madshi
30th August 2011, 10:37
Somebody should bring it to their attention, dammit!
I tried.
Its not like its a small "bug", their overall design by choosing OpenCL is severly limited, its doubtful that they'll design a new interface just like that. You can do the same with DXVA2, including deinterlacing, even without a renderer - except that its damn slow for ATI/AMD cards because of the limited GPU->CPU transfer speed.
I don't know if its a driver or a hardware problem, but i'm quite sure it affects all GPU->CPU transfers. AMD/ATI isn't all that famous for their HPC/GPGPU capabilities.
If they want to fix something, they should work on the transfer speed issue, and make using DXVA2-renderless support a viable alternative.
It seems that AMD wants to go after GPGPU with their next generation. Maybe there's hope they'll have improved their transfer speeds then.
If only they implemented OpenCL <-> D3D9 interop. That would make a lot of things easier. And it should be possible with the current hardware, too. Some earlier version of their SDK actually had limited OpenCL <-> D3D9 interop, but then they suddenly dropped it, without any explanations.
in the last few days I've noticed some random dropping of frames without any of the queues dropping low. They moved from 7-8/8 to 6/8 but not lower and despite this I got 5-9 dropped frames maybe in series of 3 for 2-3 seconds.
Sadly the problem is random and not reproducible
:(
I haven't change any settings in past few months and I'm pretty sure this problem didn't exist in v0.73.
I'll try to confirm if it's only v0.74 that has it but does anybody else experiencing the same and have any idea what could be wrong?
I doubt it could be v0.74. Try creating a log. The log contains the exact reason for why the frames were dropped.
If madvr.ax where the folder does not contain libmfxsw32.dll avcodec-53.mvr avutil-51.mvr these three files, then do not enable internal decoder! or put this seeting to Registry not to bin file! thanks!
Ah, I understand! Will do that...
TheElix
30th August 2011, 11:13
Its not like its a small "bug", their overall design by choosing OpenCL is severly limited, its doubtful that they'll design a new interface just like that. You can do the same with DXVA2, including deinterlacing, even without a renderer - except that its damn slow for ATI/AMD cards because of the limited GPU->CPU transfer speed.
I don't know if its a driver or a hardware problem, but i'm quite sure it affects all GPU->CPU transfers. AMD/ATI isn't all that famous for their HPC/GPGPU capabilities.
If they want to fix something, they should work on the transfer speed issue, and make using DXVA2-renderless support a viable alternative.Oh, if only you were in AMD development team :rolleyes:
Thunderbolt8
30th August 2011, 11:18
I'd guess at least it wouldnt getting any worse then
ajp_anton
30th August 2011, 11:23
Depends on the algorithm. When using linear resamplers (as offered by madVR) the original pixels will not be there. Linear resamplers resample every single pixel. There are algorithms which do integer multiple upscales and leave the original pixels untouched and just interpolate the "missing" pixels. Examples for such algorithms are Nearest Neighbor, NEDI, NNEDI3, ICBI etc...
Well, in Avisynth for example you can shift by .25 pixels while resizing in order to preserve the original pixels, which IMO results in better quality.
madshi
30th August 2011, 11:57
Well, in Avisynth for example you can shift by .25 pixels while resizing in order to preserve the original pixels, which IMO results in better quality.
That shift trick would work only with Bilinear sampling, but not with any other linear filter (Bicubic, Lanczos, Spline etc). And I think Lanczos3 with no shift will still look noticeably better than Bilinear with a 0.25 shift. Preserving the original pixels is very much overrated, IMHO. But if you think you can improve on madVR scaling quality with a simple Avisynth linear resampler with a 0.25 shift, then post some comparison screenshots that proof that and I'll consider implementing it.
pirlouy
30th August 2011, 12:23
AMD/ATI isn't all that famous for their HPC/GPGPU capabilities.
Neither nVidia. ;)
Your GPU decoder is surely nice, but nVidia drivers also have lots of problems.
nevcairiel
30th August 2011, 13:02
Neither nVidia. ;)
Your GPU decoder is surely nice, but nVidia drivers also have lots of problems.
Eh? That comment wasn't referring to consumers and their issues, or video decoding at all.
NVIDIA GPUs are used for HPC (High-performance computing) and GPGPU tasks all over the world. They even have a dedicated card just for that (the Tesla).
The key point was that GPGPU tasks typically also need good performance of GPU->CPU transfers, similar to how a CUDA decoder works, or a DXVA2-renderless decoder would - but its nothign you need for "normal" video playback or games, usually you just sent it to the GPU for display, you don't want to get it back.
Between AMD/ATI and NVIDIA, thats a clear win for NVIDIA. Which is why AMD trys to push into that world with their next generation, but IMHO they are too late. CUDA is basically an industry standard by now, and OpenCL is only very slowly catching up (and is handy-capped to some degree)
PS:
Regarding driver issues - why is it that i always read on eg. AVSForums about the latest Catalyst breaking someones playback chain, but very rarely about NVIDIA drivers doing something like that?
Sure, the drivers are not perfect (which software is?), and i could name several key points that need fixing myself, but at least there is some progress without huge regressions.
STaRGaZeR
30th August 2011, 13:06
PS:
Regarding driver issues - why is it that i always read on eg. AVSForums about the latest Catalyst breaking someones playback chain, but very rarely about NVIDIA drivers doing something like that?
Because you don't read enough. Or because you don't have enough first hand experience with both camps :p
madshi
30th August 2011, 13:08
There is a *HUGE* regression with newer NVidia drivers, though: Presentation glitches when playing back content at a higher refresh rate. E.g. playing back 25fps content at 50Hz is really bad here on my 9400. I have to switch to D3D11 presentation and play with the tweaks to make the presentation glitches go away. From reading through this thread it appears that AMD users don't have this problem.
nevcairiel
30th August 2011, 13:16
There is a *HUGE* regression with newer NVidia drivers, though: Presentation glitches when playing back content at a higher refresh rate. E.g. playing back 25fps content at 50Hz is really bad here on my 9400. I have to switch to D3D11 presentation and play with the tweaks to make the presentation glitches go away. From reading through this thread it appears that AMD users don't have this problem.
I also get the glitches in the OSD, but i don't see them (video remains smooth for me). I did however apply some tweaks to get rid of them anyway.
Do you actually get non-smooth video?
Speaking of DX11, i noticed the desktop/mpc-hc is not properly re-drawn if i exit FSE mode directly to windowed mode via hotkey (or double-click in MPC-HC). It works properly if i bring up a context menu in full-screen first to exit exclusive mode, and then double click to get into windowed mode.
Works all fine with DX9.
PS:
I don't consider that huge, huge would be breaking playback completely, or making any kind of material unwatchable, without a screw i can turn to simply fix it.
madshi
30th August 2011, 13:51
I also get the glitches in the OSD, but i don't see them (video remains smooth for me). I did however apply some tweaks to get rid of them anyway.
Do you actually get non-smooth video?
In DX9, or without tweaks: Yes. With DX11 and carefully tweaked options I can get playback smooth, though.
Speaking of DX11, i noticed the desktop/mpc-hc is not properly re-drawn if i exit FSE mode directly to windowed mode via hotkey (or double-click in MPC-HC). It works properly if i bring up a context menu in full-screen first to exit exclusive mode, and then double click to get into windowed mode.
Works all fine with DX9.
Yeah, DX11 is a bit unstable, will have to work on that sooner or later.
I don't consider that huge, huge would be breaking playback completely, or making any kind of material unwatchable, without a screw i can turn to simply fix it.
Well, you have to consider how much time I spent to implement all those nasty tweaks to work around the problem. It was probably around 2-3 full weeks of my programming time, no exaggeration, just to work around NVidia driver problems. And even through the tweaks do seem to help, users being forced to play around with those tweaks is very ugly, especially because it seems that everybody needs different tweaks. Personally, I do consider this problem "huge". In theory exclusive mode presentation was supposed to be rock stable. In real life it's quite the opposite, with NVidia at least.
nevcairiel
30th August 2011, 13:55
Well, you have to consider how much time I spent to implement all those nasty tweaks to work around the problem. It was probably around 2-3 full weeks of my programming time, no exaggeration, just to work around NVidia driver problems. And even through the tweaks do seem to help, users being forced to play around with those tweaks is very ugly, especially because it seems that everybody needs different tweaks. Personally, I do consider this problem "huge". In theory exclusive mode presentation was supposed to be rock stable. In real life it's quite the opposite, with NVidia at least.
Wait, didn't this regression appear quite recently (270 series drivers or such?), well after you implemented all those options?
Before those drivers, i didn't really need any tweaks, default settings worked quite smooth.
madshi
30th August 2011, 14:03
Wait, didn't this regression appear quite recently (270 series drivers or such?), well after you implemented all those options?
Before those drivers, i didn't really need any tweaks, default settings worked quite smooth.
I'm not sure with which driver version exactly the issue was introduced. When I first implemented the "final exclusive mode rendering path" several months ago, some people already had problems and some people did not. Of course different people were using very different driver versions. Personally, I was using the latest CUDA beta driver versions. Anyway, my general impression was that AMD users had no big trouble with presentation glitches, while NVidia users had. That was a few months ago. Maybe the situation got even worse with 270 drivers now? Or maybe those months ago some people were already using very new beta drivers? I don't really know for sure...
Qaq
30th August 2011, 14:20
Its just because AMD users are "scared to death" to change the drivers. I am at least.
robpdotcom
30th August 2011, 14:50
First of all you should leave your GPU set to RGB full in either case. Furthermore, of course madVR's level setting must match the display's level setting. If these two requirements are met, image quality should be just fine. Now should you use video levels or PC levels? That's a good question. There's an argument for both. If you use video levels, the processing is somewhat less extensive, so there's an ever so slight chance that the output might be smoother. Thanks to dithering this should not really make any visible difference in the real world though. There's also a good argument for using PC levels: Using PC levels allows you to have correct blacks and whites for video playback, gaming and photos/applications at the same time. So pick your poison. Personally, I'm currently using PC levels.
Thanks for the clarification, madshi.
dansrfe
30th August 2011, 15:05
I believe that he is not changing them manually but letting Windows 7 do it automatically (like I did before). There is such an option in the Desktop background configuration window.
Sadly it interferes with madVR even in Exclusive mode so I disabled it ... it was a nice feature otherwise.
Yeah it's automatic every 1 minute for me.
mzso
30th August 2011, 15:27
The AMD API has 2 big problems:
(1) It doesn't support any kind of deinterlacing.
(2) It requires the use of OpenCL, and AMD doesn't support OpenCL <-> D3D9 interop.
Add to that the fact that DXVA deinterlacing is based on D3D9. The end result is that using the AMD API makes no sense at all for interlaced content. I don't really know what AMD is thinking. The missing OpenCL <-> D3D9 interop is a major problem, but AMD doesn't seem to care. They don't seem to know what they're doing, IMHO.
Layman question. Isn't OpenCL designed to interoperate with OpenGL?
madshi
30th August 2011, 15:40
Layman question. Isn't OpenCL designed to interoperate with OpenGL?
There is an official OpenCL extension to interop with OpenGL, and there's another official OpenCL extension to interop with D3D10. There is no official extension for interop with D3D9, unfortunately. Still, it's quite possible to do, and NVidia offers OpenCL <-> D3D9 interop. Only AMD does not. And then AMD releases their OpenVideo Decode OpenCL API, without deinterlacing functionality and with no way to connect to DXVA... :confused:
Thunderbolt8
30th August 2011, 15:56
ATI/AMD is uselss. I'd not buy any of their current cards if its about (directshow) video. not having proper deinterlacing hardware support sucks.
noee
30th August 2011, 15:58
And then AMD releases their OpenVideo Decode OpenCL API, without deinterlacing functionality and with no way to connect to DXVA...
Good ole fashioned piss-poor product management, it's got to be the fact that whoever is defining goals/objectives/constraints is not getting to the critical subject matter experts.
But, I must be an outlier as far as AMD/ATI is concerned. I've built up at least 7 machines recently using various AMD GPU configurations and with the 11.x drivers and have never had a single issue, though 4 of these machines were for friends/family (HD4770/HD5670/HD5770) and the rest are for my internal use (HD2600XT/HD6570). Even with the "one-off" 4770, AFAIK, it's handling some minor HTPC duties and has been updated to the latest 11.x CCC.
I have a 6520G in a Llano notebook and have just put in a second HD6570 passive in a test machine, both perform as expected with madVR. One caveat, I am not a gamer, so the only stress my machines get is with madVR....
madshi
30th August 2011, 16:19
I do like AMD myself, due to good performance per watt, due to *not* having those presentation glitch problems and due to a freely available frame packed HDMI 3D output SDK. Unfortunately neither NVidia nor AMD are really perfect at this time. I wish it were possible to combine the best of NVidia and AMD into one new HTPC graphics card.
JustinChase
30th August 2011, 16:59
I wish it were possible to combine the best of NVidia and AMD into one new HTPC graphics card.
Too bad you're not in the US; you could claim to be a "too big to fail" company, and they'd give you a few $ Billion, then you could make it yourself :)
if only your business was in the US, and had former executives in the government. Maybe you could get Goldman Sacks to help; they get whatever they want here :devil:
(rumor is that Goldman Sacks is considering a "merger" with the US Government, but they have to get a bit more dirt on the regulators first to assure they approve the deal)
I miss Liberty :mad:
6233638
30th August 2011, 17:01
You're only checking for chroma resolution/detail, though, not for aliasing, are you? Of course it's a matter of taste if chroma resolution is more or less important than avoiding/removal of aliasing. Personally, I hate aliasing, so I prefer to use a softer chroma upscaling algorithm.I hate aliasing too - it's why I use SoftCubic 70 on Luma upscaling. I've yet to see any noticeable chroma aliasing from using Bicubic 75 though.Oh well, maybe I should implement *normal* screenshots first, before even thinking about such "special" features... ;)Absolutely, I don't expect anything like that to be a priority, was just throwing the idea out there.How often do you change background wallpapers during video playback? :eek:My guess would be Windows 7's automatic changer.Actually that's open for discussion. There's a thread on AVSForum which extensively analyzed this and the end result wasn't 100% clear. But those who were convinced that WTW shouldn't be clipped at the start of the thread weren't so convinced, anymore, at the end of the thread.The EBU specifies that a display must not clip values above 235 to be suitable for use as a reference monitor. 235 is calibrated to your desired brightness (80 nits under ideal conditions specified by the EBU) with 255 ending up at 100 nits in those conditions. Unfortunately this is awkward from a HTPC perspective, as it means video white, which will be the brightest thing in most sources, will look dull compared to the white seen in a browser window etc.IIRC the EDID doesn't say anything about 16-235 vs 0-255.Well, however it is that it's communicated between the source and display. (it has to be done somehow, as some displays will auto-switch correctly with some sources. (e.g. many Sony displays paired with a PS3)
There is a *HUGE* regression with newer NVidia drivers, though: Presentation glitches when playing back content at a higher refresh rate. E.g. playing back 25fps content at 50Hz is really bad here on my 9400. I have to switch to D3D11 presentation and play with the tweaks to make the presentation glitches go away. From reading through this thread it appears that AMD users don't have this problem.This was never a problem with my system when it was using a 9400, but when I switched over to a GTX 570 it surfaced. It appears that whatever changed must now be affecting older cards too.
Strangely though, I just went back to finish watching Wonders of the Universe the other day, which is what I had originally been using to test for this as it's one of the few 25p sources I have that should be played back at 50Hz rather than 24Hz, and I did not encounter any presentation glitches with the latest nVidia drivers. (280.26) I believe the only changes I have made to the rendering settings are increasing the buffer sizes to maximum (memory is not an issue here) enabling D3D11 presentation and enabling the "limit rendering times to avoid glitches" option.
This config, or something similar at least, helped before, but I still encountered presentation glitches, which were shown as visible stutters (despite no dropped/delayed frames) just less frequently.
Previously, I would have to switch between the new and old rendering methods depending on whether I was playing 24p @ 24Hz, or 30@60Hz/25@50Hz for completely smooth playback.
It may have been fixed sooner than 280.26, but this is the first time I've tried to play back 25@50 in quite some time, and it's worked without having to switch between the new & old rendering paths.
Andy o
30th August 2011, 18:17
I believe that he is not changing them manually but letting Windows 7 do it automatically (like I did before). There is such an option in the Desktop background configuration window.
Sadly it interferes with madVR even in Exclusive mode so I disabled it ... it was a nice feature otherwise.
I use it too, mostly cause I run a plasma and when I had static images I'd get some slight burn-in or ghosting, whatever that was. Try disabling Aero (desktop composition) in the madVR settings. The changes won't stop, but they won't have the nice fade that cause the drops. I myself am not experiencing any trouble though, it might be underpowered cards.
BatKnight
30th August 2011, 20:01
There is a *HUGE* regression with newer NVidia drivers, though: Presentation glitches when playing back content at a higher refresh rate. E.g. playing back 25fps content at 50Hz is really bad here on my 9400. I have to switch to D3D11 presentation and play with the tweaks to make the presentation glitches go away. From reading through this thread it appears that AMD users don't have this problem.
I have that problem too with 280.26 and my GTX460. I solved it by enabling "limit rendering times to avoid glitches" only.
Does this do any other harm to be always on? I mainly watch 24fps at 24Hz though, and don't need that option enabled when at 24Hz.
Bat
Xaurus
30th August 2011, 20:33
That doesn't seem right, not using ReClock is usually the cause of that. (either that or audio sync problems)
I would suggest trying ReClock again. Make sure it is selected as the audio renderer in your player, and not added as an external filter.
http://img231.imageshack.us/slideshow/webplayer.php?id=79075040.png
Note: My sound pre-buffer & max latency settings probably won't work well on most HTPCs, it's only giving the CPU 4ms to process the audio before you start getting pops & clicks. Works fine on a system my spec, probably terrible on others. I'd try 200-300ms and 5%. (basically as low as you can get without audio problems)
Sample rate & format should be set as high as your device allows.
Hi 6233638 and anyone else it might concern,
I have now reinstalled Reclock and fiddled with it for a few hours on my main display device (the plasma).
Windowed mode screenshot below, note that there is no
stutter nor dropped frames and the reclock sync symbol is
almost at the absolute bottom left corner. The screenshot
was taken after about 5 minutes of play after seeking:
windowed mode screenshot (http://home.halden.net/mordor/windowed.png)
Fullscreen mode screenshot below. The screenshot was
taken after about one minute and there are already
4 dropped frames, so my previous comment of stutter each
15-30 seconds seems to be very explainable. The reclock
vsync symbol is in the (exact) middle left, very different from
windowed mode:
fullscreen mode screenshot (http://home.halden.net/mordor/fullscreen.png)
Conclusion:
Windowed mode = no stutter
Fullscreen exclusive mode = stutter
Here are all settingss:
All reclock settings (http://home.halden.net/mordor/reclock.png)
Filters in use (http://home.halden.net/mordor/filters.png)
madvr general settings (http://home.halden.net/mordor/madvr_general.png)
madvr windowed settings (http://home.halden.net/mordor/madvr_windowed.png)
madvr fullscreen settings (http://home.halden.net/mordor/madvr_fullscreen.png)
madvr quality settings (http://home.halden.net/mordor/madvr_quality.png)
Using Nvidia drivers 280.36 (same thing with 280.26) for the 570 GTX. CPU is Core i7 980x @ 4 GHz.
edit: Reclock is set as the renderer in the mpc-hc drop-down list. I have absolutely no sound problems of any kind feeding a 24/96 external 2-channel DAC through SP/DIF.
Best,
X
nevcairiel
30th August 2011, 20:37
You should disable any ReClock VSYNC correction when using madVR.
6233638
30th August 2011, 22:00
I have that problem too with 280.26 and my GTX460. I solved it by enabling "limit rendering times to avoid glitches" only.
Does this do any other harm to be always on? I mainly watch 24fps at 24Hz though, and don't need that option enabled when at 24Hz.Previously, it was causing problems for me with 24p@24Hz, but that no longer seems to be an issue, so it should be fine.
I've just tested a few things after resetting madVR settings to the defaults.
"limit rendering times to avoid glitches" on its own does not fix things.
"use D3D11 for presentation" on its own significantly reduces presentation glitches.
Combining the two eliminates them. Nothing else needs changed from the defaults.
You should disable any ReClock VSYNC correction when using madVR.Bingo. I would also suggest not overriding the file's framerate unless you know for certain that "Automatic" is making a mistake.
EDIT: Oh, and don't "give high CPU priority to player." (if anyone is doing this with Haali's Splitter, they should disable that too)
Let ReClock adjust the audio more than 1% in speed as well, I suggest 5% up/down.
I would also recommend not setting all madVR flush settings to "flush and wait (loop)" unless it's necessary on your system. (the defaults seem to be fine for me now, after trying various configurations in old versions)
I've also had a chance to try madVR's refresh rate changer again, and it seems to be working now. (previously, I was stuck with a black screen) Not sure if it's driver related, or because I just did a clean install of Windows 7.
However, if the refresh rate changes from 60 to 24Hz, going from fullscreen to windowed mode has the video play back at a very low framerate and it's constantly dropping frames.
DVD playback is stuck at 60Hz rather than switching to 24Hz.
Looks like I'm still going to be switching manually.
TheElix
30th August 2011, 23:51
However, if the refresh rate changes from 60 to 24Hz, going from fullscreen to windowed mode has the video play back at a very low framerate and it's constantly dropping frames.Finally, someone with the same problem as me. Confirmed. But I don't even use framerate changer, I'm used to switching refresh rates manually (swapping CCC's profiles with a hotkey). But even then I have this stuttering when going from 60 to 24 Hz at the start of a video. This is healed by opening madVR's properties window in filters 100% of the time. Then video flows smoothly.
ajp_anton
30th August 2011, 23:55
That shift trick would work only with Bilinear sampling, but not with any other linear filter (Bicubic, Lanczos, Spline etc). And I think Lanczos3 with no shift will still look noticeably better than Bilinear with a 0.25 shift. Preserving the original pixels is very much overrated, IMHO. But if you think you can improve on madVR scaling quality with a simple Avisynth linear resampler with a 0.25 shift, then post some comparison screenshots that proof that and I'll consider implementing it.The shift works well with all resize methods. However, I just did some comparisons and while there is a tiny difference (shift+original pixels looks sharper but more aliasing), it's so small it's not even worth the trouble posting screens =).
I was just thinking of getting a 30-inch screen, and thought of the upscaling of 720p videos, but apparently they will be just fine as it is =).
BatKnight
31st August 2011, 00:00
"limit rendering times to avoid glitches" on its own does not fix things.
For me, that one is enough...
"use D3D11 for presentation" on its own significantly reduces presentation glitches.
I can't use D3D11 because it's not compatible with MPC-HC's refresh rate changer. And I still don't use madVR's refresh rate changer because it lacks the option to do it only when going fullscreen.
I don't need my refresh rate changed when I am just previewing videos on window mode. I would like it to be able to change the refresh rate when I go fullscreen to watch the movie. MPC-HC allows that, madVR doesn't... yet (I hope.. I keep bugging madshi about it, though)
Bat
Hprd
31st August 2011, 00:12
I think the glitches happened on the 275 nvidia drivers, with one tweak (overshoot latency or w/e), playback was perfect on any resolution with any video FPS before, now that tweak doesn't work (only limit rendering times works now, but not perfectly), and playback is only perfect at resolutions that are the same as the video fps.
Also, the DX11 path according to the osd should be perfect, as it shows about the same amount of frames in the present que on 48/60hz as the regular path on 24/30hz (same on 24/30hz though, so something must not be working? Also 24/30hz playback is fine), but it has a decent amount of glitches (about same as dx9 path without any tweaks), reguardless of tweaks (none of them work)... I have noticed this for quite some time (even with older nvidia drivers if i recall), and was wondering what to make of it?
And as for refresh changing, i usually just take stuff out of the "line" on madvr when i'm not watching something seriously. Generally if i'm going to sit down "kick back" and get into something, it's not that big of a deal (for me anyways) to add/change or w/e on madvr the resolution settings to make playback as seamless as possible. Because for just general/casual video watching, or "previewing", i usually don't care too much. And of course it's most convienent to not have the screen resolution changing all the time. (of course an option like mentioned above to only change when switching to fullscreen wouldn't hurt ;))
zefiend
31st August 2011, 00:21
For those that are looking for an alternative refresh rate changer, there's Autofrequency (http://www.homecinema-hd.com/down.php?file=autofrequency). Works very well for me. Here's (http://www.homecinema-hd.com/autofrequency_en.html) some info on its use.
mindbomb
31st August 2011, 03:09
I have a question, anyone have experience using madvr with an intel hd 3000 gpu or hd 2000 gpu?
I imagine it would work fine as long as you keep the scaling to bilinear or something.
CruNcher
31st August 2011, 03:26
I think the glitches happened on the 275 nvidia drivers, with one tweak (overshoot latency or w/e), playback was perfect on any resolution with any video FPS before, now that tweak doesn't work (only limit rendering times works now, but not perfectly), and playback is only perfect at resolutions that are the same as the video fps.
Also, the DX11 path according to the osd should be perfect, as it shows about the same amount of frames in the present que on 48/60hz as the regular path on 24/30hz (same on 24/30hz though, so something must not be working? Also 24/30hz playback is fine), but it has a decent amount of glitches (about same as dx9 path without any tweaks), reguardless of tweaks (none of them work)... I have noticed this for quite some time (even with older nvidia drivers if i recall), and was wondering what to make of it?
And as for refresh changing, i usually just take stuff out of the "line" on madvr when i'm not watching something seriously. Generally if i'm going to sit down "kick back" and get into something, it's not that big of a deal (for me anyways) to add/change or w/e on madvr the resolution settings to make playback as seamless as possible. Because for just general/casual video watching, or "previewing", i usually don't care too much. And of course it's most convienent to not have the screen resolution changing all the time. (of course an option like mentioned above to only change when switching to fullscreen wouldn't hurt ;))
Did someone take into account that maybe the P-state changes (for G200 and newer Cards) depending on the load might be responsible for such hicups also with MadVR and Nvidia Cards ?
The 280 drivers have according to Nvidia a faster Response time also then 275 in those regards.
6233638
31st August 2011, 04:30
Well so much for that. Despite not making any other changes to my system (other than watching a couple of other films) madVR's refresh rate changer has started to cause MPC-HC to crash on startup again after changing the display mode. (solid black screen until I hit CTRL ALT DEL and start the task manager)
Did someone take into account that maybe the P-state changes (for G200 and newer Cards) depending on the load might be responsible for such hicups also with MadVR and Nvidia Cards ?
The 280 drivers have according to Nvidia a faster Response time also then 275 in those regards.I don't think that's the case. With LAV CUVID, my GPU is stuck in P0 (full power) unless I override that with nVidia Inspector's multi display power saver tool. Happens regardless of P-state.
ced007
31st August 2011, 11:32
For me, that one is enough...
I can't use D3D11 because it's not compatible with MPC-HC's refresh rate changer. And I still don't use madVR's refresh rate changer because it lacks the option to do it only when going fullscreen.
I don't need my refresh rate changed when I am just previewing videos on window mode. I would like it to be able to change the refresh rate when I go fullscreen to watch the movie. MPC-HC allows that, madVR doesn't... yet (I hope.. I keep bugging madshi about it, though)
Bat
Hello,
there is a third way to have the auto refresh rate: the free software AutoFrequency.
Forum link: http://www.homecinema-hd.com/phpBB3/viewforum.php?f=20
Download link: http://www.homecinema-hd.com/down.php?file=autofrequency
I use it with mpc-hc and madVr (in D3D11) and it works really fine.
ajp_anton
31st August 2011, 12:31
I have a question, anyone have experience using madvr with an intel hd 3000 gpu or hd 2000 gpu?
I imagine it would work fine as long as you keep the scaling to bilinear or something.
I have an i7 2600K, don't know how its HD3000's clocks compare to others. Works fine using spline36 (3 taps).
On a 1920x1200 screen, rendering times for SD video is about 19ms, 720p is 22ms. That's enough for regular ~24fps movies.
I also have some 384x288 60fps videos at 11ms which seems to be just enough to keep the queue half-filled (no drops), though I never watch these in fullscreen anyway.
nevcairiel
31st August 2011, 12:35
I made the same observation on my HD3000.
Its about fast enough for 24p/25p content, but 50p/60p will not work properly if you use expensive upscaling.
For the HD2000, it'll be slower. How much? I cannot comment on that.
I was kind of hoping that the next generation Intel iGPU might be fast enough for all upscaling, but we would need a 100% performance increase on shader performance to be on the safe side, and i don't see that happening yet. :(
sneaker_ger
31st August 2011, 12:37
I also have some 384x288 60fps videos at 11ms which seems to be just enough to keep the queue half-filled (no drops)
Which queue is only half filled? Don't forget this:
The present queue is limited by the size of the other queues. If movie frame rate and display refresh rate are identical, the present queue can't be higher than the other queues. So it can never go higher than 8. If the movie frame rate is *lower* than the refresh rate, things are different. E.g. with a 24fps movie on a 60Hz display, madVR presents every movie frame 2-3 times. So basically every frame in the render queue is presented multiple times. That's why in this specific situation the presentation queue can go up to 2.5 * render queue size.
ajp_anton
31st August 2011, 12:46
Which queue is only half filled? Don't forget this:
The render queue.
nand chan
31st August 2011, 13:31
madVR requires "Input_Primaries". Also the words "RGB_PC" and "YCbCr" are *not* allowed to be used.
Edit: Disregard this post, I've moved all LutScript to the new .3dl2 format instead and created an application to generate a madVR-compatible .3dlut from a .3dl2 instead
Do you think you could add “Full” to that list? Currently, I'm using !Input_Range(Full) and !Output_Range(Full) to set a 3dlut as limited or full range, but whitespace between words and case is ignored (it could be “!input_range ( full )” as well). I don't know if simply using “Full” will trigger any false positives though.
If you already use regexes to search for strings, then it should be a triviality to add: /!(input|output)_range\s*\(\s*full\s*\)/i
If that's too much of a hassle I could try !Input_Range(RGB_PC) as well.
I was actually thinking of extending the range function further, allowing things like !Input_Range(16, 235) so you could pick any numbers you want, but I suppose that might be too much of a hassle for you to check easily, especially since it might be something like 16.0 or 235.00.
As a work-around, would you like me to simply pad madVR compatibility information via comments, eg. # RGB_PC YCbCr at the end?
To match your YCbCr checking I will rename my ConvertToRGB() function to ConvertFromYCbCr(). Keep in mind, again, that these names are not case-sensitive.
I'm still thinking about how to encode input primaries in my LutScript format, mainly because all of my color functions are currently essentially unaware of its colorspace, I might just tag it to sRGB primaries manually, again using comments.
Perhaps in future I will allow manual color space conversions, and then the tagged primaries will simply be the input space of the first conversion function, or sRGB if none are given.
madVR doesn't actually look for the Input_Range command at all. madVR simply assumes that the 3dlut is limited range.
Okay.
BatKnight
31st August 2011, 14:31
Hello,
there is a third way to have the auto refresh rate: the free software AutoFrequency.
Forum link: http://www.homecinema-hd.com/phpBB3/viewforum.php?f=20
Download link: http://www.homecinema-hd.com/down.php?file=autofrequency
I use it with mpc-hc and madVr (in D3D11) and it works really fine.
I'll take a look...
But I would still prefer madshi would add an option to change the refresh rate only when going fullscreen, on madVR... Who's with me?
Bat
CruNcher
31st August 2011, 15:52
I made the same observation on my HD3000.
Its about fast enough for 24p/25p content, but 50p/60p will not work properly if you use expensive upscaling.
For the HD2000, it'll be slower. How much? I cannot comment on that.
I was kind of hoping that the next generation Intel iGPU might be fast enough for all upscaling, but we would need a 100% performance increase on shader performance to be on the safe side, and i don't see that happening yet. :(
Yep you don't need MadVR though to let it brake away EVR + Sharpen Complex 2 @ 1080p 23.976 fps is already enough to slow it down significantly here on a I-5 2400 HD 2000 (default clocks) :(
http://img692.imageshack.us/img692/5986/gpushadercg.th.png (http://img692.imageshack.us/img692/5986/gpushadercg.png)
PS: Hmm with Aero Off its more performant in those regards, actually it's smooth so without the Aero overhead windowed it works :)
Xaurus
31st August 2011, 16:08
Hi everyone,
After planning on continuing the Reclock experiment today, I realized that Nvidia has f***** up the 23.976 refresh rate somehow.
No matter what I do I can only get 24.02 Hz now with any custom resolution set up as 23.976 and this is starting to piss me off. Does anyone have any idea of why this would happen?
6233638
31st August 2011, 17:27
Hi everyone,
After planning on continuing the Reclock experiment today, I realized that Nvidia has f***** up the 23.976 refresh rate somehow.
No matter what I do I can only get 24.02 Hz now with any custom resolution set up as 23.976 and this is starting to piss me off. Does anyone have any idea of why this would happen?It looks like Nvidia now uses the correct timings on Auto, so make sure you haven't changed them. (but if you want 23.976, you will have to edit the exact refresh rate manually)
24.000 is ideal, especially if you are using ReClock. Most PCs will not hit any clock exactly though - it's part of why ReClock exists.
Xaurus
31st August 2011, 20:53
It looks like Nvidia now uses the correct timings on Auto, so make sure you haven't changed them. (but if you want 23.976, you will have to edit the exact refresh rate manually)
24.000 is ideal, especially if you are using ReClock. Most PCs will not hit any clock exactly though - it's part of why ReClock exists.
Hi,
Well yes my point is that when I edit the exact refresh rate manually it just changes to 24.02 no matter what I do. I have even deleted the custom resolution and added it again, over and over without success.
Honestly, the Nvidia hardware seems great but their software drivers are anything but great.
So in any case, you would advocate a pure 24.000 refresh rate instead of 23.976, even for 23.976 material?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.