madVR - high quality video renderer (GPU assisted)

[bugmen0t]

If you disable the display mode switcher then madVR is not responsible for the refresh rate.
For me madVR does switch to 60p in FSE mode with display mode switcher off since v0.86.7 and before it switched to 59p.

[mark0077]

ah great thanks, I guess it reads the original frame rate rather than rate coming out from last filter? Its seeing the 60.000fps output from SVP as the original 24.000fps . Its not an issue, I will try to make a custom windows resolution to see can I get around it.

[madshi]

For me madVR does switch to 60p in FSE mode with display mode switcher off since v0.86.7 and before it switched to 59p.
It probably has in v0.86.7, but it should not in v0.86.8. The fix I implemented in v0.86.8 is now only supposed to be applied if the display mode switcher is turned on.

ah great thanks, I guess it reads the original frame rate rather than rate coming out from last filter?
If SVP sends 60.000fps but tells madVR that it's sending 24.000fps then complain to the SVP devs. Or if SVP is run via AviSynth (I don't know if it is) then it's probably an ffdshow problem. In any case, it's not madVR's fault.

[AGKnotUser]

86.8 creates a log file every time I start mpc-hc. Any way to turn that off? I couldn't see anything in the setup.

[bugmen0t]

It probably has in v0.86.7, but it should not in v0.86.8.
It does so with v0.86.8, too. However I don't see a problem with that.

EDIT: Was able to make it switch: Played a PAL DVD in FSE first, still at 60p. After that, if I load a BluRay it will switch to 59p in FSE. Quit MPC-HC. Restart it and load the BluRay again and it switches back to 60p (as it would have played at 60p without playing the DVD first). Really strange. (All with display rate changer off, of course.)

EDIT 2: That even holds true if I turn the display rate changer on and set it to 1080p60! Still switches to 59p if a PAL DVD was played before. :confused:

[madshi]

86.8 creates a log file every time I start mpc-hc. Any way to turn that off? I couldn't see anything in the setup.
When did you download v0.86.8? The first time I uploaded (some time yesterday) it was broken the way you report. However, I've fixed that in the meanwhile. Just re-download and you should be fine.

http://madshi.net/madVR.zip

It does so with v0.86.8, too.
Strange.

[AGKnotUser]

When did you download v0.86.8? The first time I uploaded (some time yesterday) it was broken the way you report. However, I've fixed that in the meanwhile. Just re-download and you should be fine.

http://madshi.net/madVR.zip


Strange.
That did the trick. Thanks.

[mark0077]

If SVP sends 60.000fps but tells madVR that it's sending 24.000fps then complain to the SVP devs. Or if SVP is run via AviSynth (I don't know if it is) then it's probably an ffdshow problem. In any case, it's not madVR's fault.

Ah right ok np. LAV seems to also incorrectly report its output rate. Eg without ffdshow / SVP, if I use LAV to deinterlace a 25i to 50p, it still says 25fps. I'll post on LAV thread.

[jmonier]

I'm getting strange results when using madTPG. I do not see any of this when going through the madVR pattern generator. I have verified it when using HCFR. There may also be problems with ArgyllCMS but I can't be sure at this point.

It's most obvious when I attempt to measure the uncalibrated response of my LG. I get reasonable results when I go through madVR. I get much worse results when I go through madTPG. The worst of these is a gamma of 2.7@10% going down to 1.4@90%. (The gamma when going through madVR is relatively flat.)

The states for "disable VideoLUT" and "disable 3dLUT" do not affect things at all.

I do have a 3dLUT generated from ArgyllCMS according to madshi's latest workflow. Except for gamma, it seems fairly good when I measure through madVR. (The gamma is approximately the shape of a BT.1886 curve but has values about 0.1 higher than the HCFR BT.1886 curve at it's high end.)

Whether or not the 3dLUT is enabled in madVR, I get the same bad results above (crazy gamma, etc.) when attempting to measure it via madTPG from HCFR. In other words, I can find no combination in which the 3dLUT affects things when I use madTPG.

[cyberbeing]

so that 10% GPU usage really is in the more extreme situations.
It is indeed, but that 10% is actually a bit deceptive, since it actually bottlenecks my GPU slightly and makes my queue unstable once GPU load hits ~50% if I also had something like AR enabled, while if I disable it my queues are stable up to ~95% load. This is why I keep it disabled, but overall I don't care what the default is, as long as there is still a trade-quality option to toggle it off. In motion, I cannot even see the difference between enabled/disabled anyway.

My GT440 DDR isn't that weak, as it's ~2x as powerful as the Intel HD4000 iGPU, it's just that there are certain shader operations like linear light conversions which have a rather bad performance:quality trade-off compared to faster GPUs. Could I use much heavier settings than I do with 23.976 content, sure, but I value stability over all else. I usually tune my madVR settings so they never exceed 99% load or drop frames even under the most extreme cases, which I may only experience ~1% of the time. And yes, this usually means I'm usually sitting at ~20% GPU load normal case (Spline36 AR Luma + Catmull-Rom Chroma + 3DLUT).

[madshi]

I'm getting strange results when using madTPG. I do not see any of this when going through the madVR pattern generator. I have verified it when using HCFR.
I've just tried on my LCD computer monitor, and HCFR produces the same results for me, regardless of whether I use MPC-HC+madVR for test pattern generation or whether I use madTPG. Did you test both in the same mode (windowed vs. fullscreen exclusive)?

[jmonier]

I've just tried on my LCD computer monitor, and HCFR produces the same results for me, regardless of whether I use MPC-HC+madVR for test pattern generation or whether I use madTPG. Did you test both in the same mode (windowed vs. fullscreen exclusive)?

I always use madVR fullscreen exclusive. I did use madTPG fullscreen (and I'm assuming that is exclusive as well). I am using both on a secondary monitor (I move madTPG to that monitor) for what that's worth.

In HCFR I always do a Measures/Configure before each run (because of the bug previously reported). The only other thing I can see in HCFR is "Blank Screen during Measure" which I left checked.

I'm using ZoomPlayer rather than MPC-HC but, of course, it's working fine there.

Did you check whether the "Disable VideoLUT" and "Disable 3dLUT" have any effect? What exactly are they supposed to do (since I don't see any effect)?

Do the madVR settings have any effect on madTPG? If not, how would madTPG know where to find the 3dLUT?

I will check further on HCFR. Right now, I'm doing an ArgyllCMS calibration using madVR. The numbers I'm seeing from dispcal (while in progress) are significantly different (and probably better) than I saw when doing it using madTPG.

EDIT: I only entered the 3dLUT path into REC709 and left the others blank. Is that right?

One more thing: ArgyllCMS says it has no access to the VideoLUT. Is that normal?

And another thing: I have an AMD/ATI card. I'm wonder if there could be a driver issue.

[madshi]

I always use madVR fullscreen exclusive. I did use madTPG fullscreen (and I'm assuming that is exclusive as well). I am using both on a secondary monitor (I move madTPG to that monitor) for what that's worth.

In HCFR I always do a Measures/Configure before each run (because of the bug previously reported). The only other thing I can see in HCFR is "Blank Screen during Measure" which I left checked.

I'm using ZoomPlayer rather than MPC-HC but, of course, it's working fine there.

Did you check whether the "Disable VideoLUT" and "Disable 3dLUT" have any effect? What exactly are they supposed to do (since I don't see any effect)?

Do the madVR settings have any effect on madTPG? If not, how would madTPG know where to find the 3dLUT?

I will check further on HCFR. Right now, I'm doing an ArgyllCMS calibration using madVR. The numbers I'm seeing from dispcal (while in progress) are significantly different (and probably better) than I saw when doing it using madTPG.

EDIT: I only entered the 3dLUT path into REC709 and left the others blank. Is that right?
That sounds all quite weird to me. Could you do some more tests, trying to find out where the problem comes from? E.g. could you please try windowed mode instead of fullscreen mode for both madVR and madTPG and see if that makes a difference? Also please check with your primary monitor to check if it works ok there. Thanks.

[jmonier]

That sounds all quite weird to me. Could you do some more tests, trying to find out where the problem comes from? E.g. could you please try windowed mode instead of fullscreen mode for both madVR and madTPG and see if that makes a difference? Also please check with your primary monitor to check if it works ok there. Thanks.

OK, here's what is happening:

If madTPG opens on the primary monitor and is then moved to the secondary monitor, everything is OK (including operation of the "Disable 3dLUT")

If madTPG opens on the secondary monitor (because it was closed on that monitor) you get the problems that I described.

Note that the 3dLUT needs to be enabled in madVR for it to be used in madTPG. I presume that this is by design (either explicitly or implicitly). Any more info on the use of the Disable buttons in madTPG would be appreciated.

One more note about HCFR: I had problems with it measuring the primary monitor until I turned off "Blank screen during measure". I don't think that had anything to do with the primary problem but I'm going to leave it off from now on.

[madshi]

Interesting. What happens if you run "dispwin -c -d2" in the situation where you get weird results in madTPG. Does that fix the issue? Or what happens if you call "dispwin -c -d2" in the situation where you get *good* results in madTPG. Does that reproduce the problem?

Edit: The buttons are supposed to do with their caption says. If you have a 3dlut configured for the display madTPG runs on, the "disable 3dlut" button is supposed to disable the 3dlut (only for madTPG, nor for madVR).

[jmonier]

Interesting. What happens if you run "dispwin -c -d2" in the situation where you get weird results in madTPG. Does that fix the issue? Or what happens if you call "dispwin -c -d2" in the situation where you get *good* results in madTPG. Does that reproduce the problem?

I'm not sure that I understand. To begin with, what I call the secondary monitor is the one that is not the main or primary display and does not have the taskbar. That ends up being #1 on most of my systems. So, I think you mean -d1 rather than -d2.

Or did you want to clear the VideoLUT on the main display while madTPG runs on the secondary display?

Beyond that, did you want me to do this once madTPG is positioned on the secondary display (but before running HCFR), either by opening there (*bad* results) or being moved there (*good* results)?

[jmonier]

Beyond what I said above, I'm not sure that I understand how the VideoLUT is used in conjunction with madVR. I always use fullscreen exclusive so I'm primarily interested in that case.

Is it active when madVR is used?

Does it get loaded when the 3dLUT is used?

In your workflow, should dispcal.cal be loaded into the videoLUT or is it included in the 3dLUT?

Should dispcal.cal be loaded into the VideoLUT for use by players that can't use madVR?

[tobindac]

Program needs some kind of easy way to check what version you've installled.

Not that one can't just force a reinstall or check the changelog, but it's weird it doesn't have an About on the main interface.

edit: Oh, there is one, bottom-left corner. Easy to miss, too used to About messages.

[dansrfe]

Is there a tool out there that can selectively turn off displays in a multi-display setup? While watching a movie on one monitor at night, for example. It would be easier than turning off the monitor manually since the power button is in an awkward spot behind the monitors.

[tobindac]

Does anyone know if SVP's 60FPS affects madVR's output image quality? I LOVE 60FPS because it just makes everything lively (and I don't accept the "home video" arguments personally). I noticed madVR does properly show a nasty result on "Nearest Neighbor" and a properly nice result on other algorithms, but I wonder if I miss something.

[kasper93]

Is it active when madVR is used?

It depend on "Disable GPU gamma ramps" setting.

Does it get loaded when the 3dLUT is used?

It's already loaded in GPU before you even start madVR, but you can disable it by checking "Disable GPU gamma ramps" setting.

In your workflow, should dispcal.cal be loaded into the videoLUT or is it included in the 3dLUT?

When using madVR you should disable videoLUT to gain best quality. Command dispread -v -dmadvr -K dispcal.cal dispread will include dispcal.cal file while reading display. And with "collink -a" parameter you include .cal file into .3dlut.

Should dispcal.cal be loaded into the VideoLUT for use by players that can't use madVR?

That's is the only way to calibrate display for those players, so yes it should be loaded.

[madshi]

I'm not sure that I understand. To begin with, what I call the secondary monitor is the one that is not the main or primary display and does not have the taskbar. That ends up being #1 on most of my systems. So, I think you mean -d1 rather than -d2.

Or did you want to clear the VideoLUT on the main display while madTPG runs on the secondary display?

Beyond that, did you want me to do this once madTPG is positioned on the secondary display (but before running HCFR), either by opening there (*bad* results) or being moved there (*good* results)?
I'm still trying to figure out where the problems you have are coming from. My current guess is that maybe your secondary display (the one you do the measurements on) might have a VideoLUT loaded sometimes which would affect the measurements. That's why I suggested experimenting with "dispwin -c". Of course dispwin should be run for the monitor you measure on, otherwise it won't have any effect on your measurements. You can run "dispwin -c" at any time, but my suggestion would be to first start madTPG, then check with HCFR, then run "dispwin -c" while madTPG still runs, then check again with HCFR. Do this with both ways to start madTGP (starting it on the first or secondary monitor). Does "dispwin -c" make any difference in any situation at all? If you're not sure whether to use "dispwin -d1" or "dispwin -d2" then simply do both! :)

Also, as I said before, please also test in windowed mode. I don't care if you always use fullscreen exclusive mode. These tests are not supposed to be of use for your calibration, they only serve the purpose to find out where the madTPG problems you're having are coming from. So knowing whether windowed mode affects the results is quite important to me. E.g. maybe madTPG never goes to FSE mode for you, and maybe that's the key difference? I don't know, and madTPG currently doesn't really show whether it's in FSE more or not.

Does anyone know if SVP's 60FPS affects madVR's output image quality?
It does not, it just makes life harder for madVR because processing 60fps in madVR consumes more GPU power than processing 24fps. If your GPU is fast enough: No problem.

[chros]

Need Feedback:

The recent versions (v0.86.7 and v0.86.8) are supposed to fix refresh rate switching in Windows 8, when entering fullscreen exclusive mode. Without that fix, switching to 60.000Hz resulted in 59.940Hz being used, and switching to 24.000Hz resulted in 23.976Hz being used by Direct3D in FSE mode. The fix works for me with my Intel HD4000, resulting in 60.000Hz and 24.000Hz being used in FSE mode. However, I've received a report that it doesn't work in the madVR bug tracker.

So all you Windows 8 users: Could you please check whether you can get 60.000Hz and 24.000Hz to work with v0.86.8 in FSE mode, when using the madVR display mode switcher? Please mention whether your OS is x86 or x64, and which GPU you're using.

Thanks!!
Unfortunately not working for me, neither one. (I also filed a bug comment.)
And we thank You! :)

[jmonier]

I'm still trying to figure out where the problems you have are coming from. My current guess is that maybe your secondary display (the one you do the measurements on) might have a VideoLUT loaded sometimes which would affect the measurements. That's why I suggested experimenting with "dispwin -c". Of course dispwin should be run for the monitor you measure on, otherwise it won't have any effect on your measurements. You can run "dispwin -c" at any time, but my suggestion would be to first start madTPG, then check with HCFR, then run "dispwin -c" while madTPG still runs, then check again with HCFR. Do this with both ways to start madTGP (starting it on the first or secondary monitor). Does "dispwin -c" make any difference in any situation at all? If you're not sure whether to use "dispwin -d1" or "dispwin -d2" then simply do both! :)


dispwin - c (either -d1 or -d2) has no effect on the problem (either FSE or windowed). It's still bad where it was bad before and good where it was good.

Also, as I said before, please also test in windowed mode. I don't care if you always use fullscreen exclusive mode. These tests are not supposed to be of use for your calibration, they only serve the purpose to find out where the madTPG problems you're having are coming from. So knowing whether windowed mode affects the results is quite important to me.

My mention of FSE was only with regard to my questions about the VideoLUT. I was not objecting to running in windowed mode. I'm happy to do whatever tests you want.

kasper93 answered my questions. I'm presuming that you have no further comment on his answers.

E.g. maybe madTPG never goes to FSE mode for you, and maybe that's the key difference? I don't know, and madTPG currently doesn't really show whether it's in FSE more or not.


I believe that it goes to FSE. It certainly changes to full screen and if I move another window to that monitor, that window does not appear even when it has the focus.

[madshi]

dispwin - c (either -d1 or -d2) has no effect on the problem (either FSE or windowed). It's still bad where it was bad before and good where it was good.
Did you test madVR (not madTPG) in windowed mode, too? And it works alright? Do you have VideoLUTs active on any monitor at any time (that you're aware of)?

[jmonier]

Did you test madVR (not madTPG) in windowed mode, too? And it works alright? Do you have VideoLUTs active on any monitor at any time (that you're aware of)?

I only tested madVR in FSE mode and everything was OK. I'll try it in windowed mode later today.

I haven't done anything specifically with the VideoLUTs prior to today. madVR is (and has been) set to "Disable gamma ramps" (which I believe disables the VideoLUT) and "Disable VideoLUT" is set in madTPG. If your Argyll-madVR workflow doesn't change them behind the scenes, they should have been at whatever Win7 sets them to (and I haven't loaded any specific monitor drivers or ICC profiles).

Right now dispwin -c is in effect on both monitors and I'll leave it that way unless you want it to be different.

[jmonier]

Did you test madVR (not madTPG) in windowed mode, too? And it works alright? Do you have VideoLUTs active on any monitor at any time (that you're aware of)?

I tested madVR in a window, full screen windowed mode and FSE. I got identical results in all.

[madshi]

Too bad, so I'm a bit lost about what the problem could be right now. When testing with madVR, do you start the media player directly on the secondary monitor? Or do you start it on the primary and then move it to the secondary? Are both monitors served by the same GPU? Finally: Are both displays setup with the same levels (PC vs TV) in both the GPU control panel and in madVR?

[dansrfe]

Just noticed that switching from windowed/overlay to FSE has significant lag with v0.86.7/8... Delay switch to exclusive mode by 3 seconds is off. For some reason this wasn't happening until I added a couple of new refresh rates through nvidia cpl however the lag is present even when the refresh rate switcher doesn't switch the refresh rate (e.g. stays at 59.94Hz)

Windows 7 x64, GTX 670

EDIT: The switch seems to lag ONLY when the refresh rate is NOT switched. When the refresh rate is switched then windowed/overlay to FSE is pretty smooth.

[jmonier]

Too bad, so I'm a bit lost about what the problem could be right now. When testing with madVR, do you start the media player directly on the secondary monitor? Or do you start it on the primary and then move it to the secondary?

It always starts directly on the secondary in Full Screen. The primary is 1280x1024 so it is not really suitable.

Are both monitors served by the same GPU?
Yes

Finally: Are both displays setup with the same levels (PC vs TV) in both the GPU control panel and in madVR?

The primary does not have that option available in the GPU since it has no TV resolutions in the EDID. I do have madVR set to PC for both (which should be correct for the primary).

[htpc66]

@madshi

May I ask if there is a way to use customized profiles eg. like "ini" used by mpc-hc. Thanks

[madshi]

Just noticed that switching from windowed/overlay to FSE has significant lag with v0.86.7/8... Delay switch to exclusive mode by 3 seconds is off. For some reason this wasn't happening until I added a couple of new refresh rates through nvidia cpl however the lag is present even when the refresh rate switcher doesn't switch the refresh rate (e.g. stays at 59.94Hz)

Windows 7 x64, GTX 670

EDIT: The switch seems to lag ONLY when the refresh rate is NOT switched. When the refresh rate is switched then windowed/overlay to FSE is pretty smooth.
Please create a bug entry in the tracker, and add a debug log from v0.86.8.

It always starts directly on the secondary in Full Screen. The primary is 1280x1024 so it is not really suitable.
Ok, here's a madTPG test build. Does this one fix the issue?

http://madshi.net/madTPG.rar

It's just a try, though, I'm not sure if it will help.

May I ask if there is a way to use customized profiles eg. like "ini" used by mpc-hc.
You can run "restore default settings.bat" and afterwards copy in a saved "settings.bin" file.

[jmonier]

Ok, here's a madTPG test build. Does this one fix the issue?

http://madshi.net/madTPG.rar

It's just a try, though, I'm not sure if it will help.

This gives me an immediate error with a read of address 00000

Another thing that I just noticed with the original madTPG (NOT this test version):

Disable VideoLUT doesn't seem to work. If a cal file is loaded into the VideoLUT, it's effect is seen whether or not whether or not the"Disable VideoLUT" button is activated.

[madshi]

Yeah, got your crash report. Try this one:

http://madshi.net/madTPG2.rar

[tobindac]

Why don't I see any reasonable difference on chroma upscaling settings even if I use nearest neibhor? What do I miss?

Should I just avoid using a good algorithm and save the GPU power for image upscaling?

[huhn]

if you don't see it why not? Nearest Neighbor got "ok" results when x4 the resolution and this should be the case i nearly all cases.

[madshi]

Chroma upscaling quality is only visible in specific situations. For most scenes in a movie, there's not such a big difference between the algorithms. However, in certain scenes, or with certain content types, the difference can be very obvious. If you're short on GPU power, I'd recommend to use at least Bilinear for chroma upscaling. It's pretty much the same speed as Near Neighbor, but with much better quality. Of course if you have GPU power to spare, there's no reason not to use a better algorithm, just in case.

[6233638]

While chroma upscaling may not be the most obvious thing, using Nearest Neighbor should be.
If you don't see the difference, I suspect your display is smoothing over chroma and processing in 4:2:2.
But I agree, you should still use at least Bilinear.

[chros]

@madshi: what about my last comment in this ticket? :) http://bugs.madshi.net/view.php?id=90
Thanks!

[iaTa]

Using any Intel drivers from the recent 15.31.x releases (15.31.1.3006 to 15.31.2.3055) I have an issue with the info panels (volume, play, stop etc) being left onscreen in the black bar areas.

I'm running a Clevo P150EM laptop with Intel HD 4000 and Nvidia 680M.

If I can do anything to assist with troubleshooting let me know.

This is still a problem on multiple machines that I run. Even the very latest Intel HD v15.31.14.3220 driver dated 3rd July '13 exhibits the same issue.

If the video I am playing is 16:9 and fills the entire screen there's no problem. It only occurs when the video is of an aspect ratio that any info panels are situated in the black blank space.

Turning exclusive mode off does not fix it but it does allow you to minimize and then full screen the window to remove any info panels. If exclusive mode is on the 'Exclusive Mode' panel pops up and then stays on screen. Same for changing volume, stop, play etc.

Rolling back to the latest of the older 15.28 branch (v15.28.17.64.3190) fixes the issue. Any chance you could have a look at this madshi?

[toomyzoom]

madshi, can you tell me what happen with the manual refresh rate changer?

A lot of of idiots out there encode 23.976fps video with the the tag of 29.970fps video. I used to be able to put 23p in the filename or folder name to force my refresh rate to 48hz. However, recent versions of madVR seems disabled it.

Wrong refresh rate introduces judders and it's kind of irritating. Wish madVR can read framerate straight from reclock because most of the time, it was wrong when madVR read it from metadata.

My version is 0.86.8.

Thank you for your work.

[madshi]

@madshi: what about my last comment in this ticket? :) http://bugs.madshi.net/view.php?id=90
Thanks!
What about it? I'll comment in the bug tracker when I look into it. There's nothing I can say atm.

This is still a problem on multiple machines that I run. Even the very latest Intel HD v15.31.14.3220 driver dated 3rd July '13 exhibits the same issue.

[...]

Rolling back to the latest of the older 15.28 branch (v15.28.17.64.3190) fixes the issue. Any chance you could have a look at this madshi?
As was reported earlier, this seems to be a bug in the Intel drivers. You can work around it by disabling the madVR option "use a separate device for presentation". If you want this fixed, complain to Intel.

madshi, can you tell me what happen with the manual refresh rate changer?

A lot of of idiots out there encode 23.976fps video with the the tag of 29.970fps video. I used to be able to put 23p in the filename or folder name to force my refresh rate to 48hz. However, recent versions of madVR seems disabled it.
I've changed the file name tag syntax, because simply putting 23p or 24p in the file name was too prone for unintentional tag interpretations. Search the changelog.txt for "tag" and you'll find how to do tags with newer madVR builds.

[toomyzoom]

I've changed the file name tag syntax, because simply putting 23p or 24p in the file name was too prone for unintentional tag interpretations. Search the changelog.txt for "tag" and you'll find how to do tags with newer madVR builds.

Thanks. The new tagging system is much better than the old one.

Keep up your good work.

[iaTa]

As was reported earlier, this seems to be a bug in the Intel drivers. You can work around it by disabling the madVR option "use a separate device for presentation". If you want this fixed, complain to Intel.

Ok, thank you.

[egandt]

I wish to used MadVr with both Zoomplayer with refresh rate changing and with MPC HC without it, since with MPC I use SVP (mostly for animation). Is there a way to have to profiles for 2 different software products, or else based on the filter used to connect?

Thanks,
ERIC

[webs0r]

Hey how do the new options for the different 3DLUT colourspaces work?

I fired up some SD content (guessed as SMPTE C) while having only a 3DLUT loaded in the BT.709 option.
Changing this 3DLUT affected the picture.
When I add a LUT into the SMPTE C option, it doesn't affect the picture.
I thought having one in there specifically would override the BT.709 option given that madVR assumed SMPTE C primaries?

Also is this correct: I can produce additional LUTs via Argyll's collink.exe for the other colourspaces - would that be higher quality than just putting my REC.709 LUT in and letting madVR handle the gamut changes?

[tobindac]

Chroma upscaling quality is only visible in specific situations. For most scenes in a movie, there's not such a big difference between the algorithms. However, in certain scenes, or with certain content types, the difference can be very obvious. If you're short on GPU power, I'd recommend to use at least Bilinear for chroma upscaling. It's pretty much the same speed as Near Neighbor, but with much better quality. Of course if you have GPU power to spare, there's no reason not to use a better algorithm, just in case.
Hrm. Thanks.

I wonder what the circumstances are that make chroma upscaling being bad (e.g. nearest neighbor) a problem.

Perhaps sudden changes on discreetly colorful content? (e.g. anime)

[madshi]

I wish to used MadVr with both Zoomplayer with refresh rate changing and with MPC HC without it, since with MPC I use SVP (mostly for animation). Is there a way to have to profiles for 2 different software products, or else based on the filter used to connect?
Profiles are currently not supported. I guess you could manually do something like that by creating two "settings.bin" files (madVR settings are stored to "settings.bin" in the madVR folder, if madVR has write access to that folder), one for MPC and one for ZP. Then you could execute "restore default settings.bat" and copy one of the "settings.bin" files to the madVR folder to automatically swich to other settings. That should be possible to achieve with one batch file on your desktop.

Hey how do the new options for the different 3DLUT colourspaces work?

I fired up some SD content (guessed as SMPTE C) while having only a 3DLUT loaded in the BT.709 option.
Changing this 3DLUT affected the picture.
When I add a LUT into the SMPTE C option, it doesn't affect the picture.
I thought having one in there specifically would override the BT.709 option given that madVR assumed SMPTE C primaries?
That is how it's supposed to work. If you provide both a BT.709 and an SMPTE C 3dlut then madVR should automatically use the one that matches the source primaries. Now sure why that didn't work for me. It did work on my PC when I tested it. If you can reproduce that it doesn't work, please create a new bug issue in the madVR bug tracker, and if the problem only occurs with some files but not with all, maybe attach a small video sample (has to be zip).

Also is this correct: I can produce additional LUTs via Argyll's collink.exe for the other colourspaces - would that be higher quality than just putting my REC.709 LUT in and letting madVR handle the gamut changes?
Letting Argyll create one 3dlut for each source format should provide slightly better results, or at least that's what Graeme tells me. So that's why I added these options now. Of course you can still use just one BT.709 3dlut and madVR will happily do the gamut conversion for you.

I wonder what the circumstances are that make chroma upscaling being bad (e.g. nearest neighbor) a problem.

Perhaps sudden changes on discreetly colorful content? (e.g. anime)
Sharp and highly saturated edges against a gray/black/white background. E.g. red fonts on black background.

[dansrfe]

Is it considered strange for FRC with 59Hz to appear smoother than without FRC on 48Hz? And is there any disadvantage to sticking with the former, irrespective of refresh rates? Essentially turning off the display mode switcher and using the highest refresh rate possible with FRC.

[e-t172]

Is it considered strange for FRC with 59Hz to appear smoother than without FRC on 48Hz?

I have an hypothesis that in some cases FRC could appear smoother than using the correct refresh rate. madshi disagrees. Are you sure that your display isn't lying to you when you're setting it to 48Hz (i.e. are you sure it's not repeating frames internally)?