madVR - high quality video renderer (GPU assisted)

[Dodgexander]

What's the native resolution of your display? If you can't scale to that using any setting. Try the trade quality for performance options.if that doesn't work you can try to change the gpu and cpu queues in advance.

If you can't scale to your native resolution, even when using most simple settings and trade quality options then you are best just to use evr. Scaling to something other than your native resolution is only going to make it look worse, even with dithering.

The other option would be to switch resolution based upon your source, but still that's no answer to not being able to play 1080p with madVR

Sent from my Blade S using Tapatalk 2

[digitech]

What's the native resolution of your display? If you can't scale to that using any setting. Try the trade quality for performance options.if that doesn't work you can try to change the gpu and cpu queues in advance.

If you can't scale to your native resolution, even when using most simple settings and trade quality options then you are best just to use evr. Scaling to something other than your native resolution is only going to make it look worse, even with dithering.

The other option would be to switch resolution based upon your source, but still that's no answer to not being able to play 1080p with madVR

Sent from my Blade S using Tapatalk 2
My display is 1080p native but works with 720p too, i just asked in your opinion which is better, 720p with advanced upscaling methods like lanczos3 or Jinc chroma & image, vs 720p to 1080p with bilinear in both upscaling methods.

[cyberbeing]

1.) Tripod mount for your i1Pro
The one you linked doesn't really seem optimal for an i1pro w/ emissive display, where you'll get best results only with direct contact with the face plate to cut out all ambient light. Since I have no desire to ever own a projector, if I went the tripod route, I'd want a setup where the i1pro was mounted at the very tip of an arm.

I've seen images of DIY setups like that before in the past, but a quick google search is only coming up with this one option (http://www.controlcal.com/forum/showthread.php?t=614) as possibly available for purchase at the moment.

2.) Purchase a i1D3 colorimeter to profile against your i1Pro. *Best option IMO
I agree this is the best option, especially considering I own an i1pro already to profile against. I almost bought an i1d2 for this purpose years ago, but never got around to it. Whenever I get around to spending the cash to have my i1pro re-certified (esp. if it still needs to go to/from Switzerland), I'll probably drop down another ~$200 at the time to get an i1d3.


Not really - it does what it does. dispcal/dispread take the sequence into account. targen is just trying to minimise the extra read time this causes.
Ah, that make sense. And just a head-up that I probably am not going to get around to re-calibrating tonight (too tired), so it will likely be tomorrow night ~24 hours from now.

[fairchild]

I haven't been able to get 3dlut's to actually improve on my calibration done at the display level per the stats I get after trying to verify with HCFR. Using both ycms and argyll 3dluts causes strange anomalies in certain test patterns (such as the color clipping pattern on the AVS HD709 disc and the ramps pattern on the GCD disc) and then I get an increase in delta error's on my grayscale and hardly anything different in my colors.

Maybe my display is already as optimal as it's going to get... or maybe my Colormunki spectro is not as accurate and consistent as I had hoped.

[Graeme Gill]

Using both ycms and argyll 3dluts causes strange anomalies in certain test patterns (such as the color clipping pattern on the AVS HD709 disc and the ramps pattern on the GCD disc) and then I get an increase in delta error's on my grayscale and hardly anything different in my colors.

Maybe my display is already as optimal as it's going to get... or maybe my Colormunki spectro is not as accurate and consistent as I had hoped.

Hard to say without any details. Note that attempts to both calibrate displays using their in-built controls and profile them often don't work that well - the internal controls sometimes mess up the color behaviour in ways that can't be straightened out by profiling. So it's typically best to set internal controls to be as neutral as possible (ie. to alter the native behaviour of the display as little as possible) if the color is to be managed using profiles.

[fairchild]

Hard to say without any details. Note that attempts to both calibrate displays using their in-built controls and profile them often don't work that well - the internal controls sometimes mess up the color behaviour in ways that can't be straightened out by profiling. So it's typically best to set internal controls to be as neutral as possible (ie. to alter the native behaviour of the display as little as possible) if the color is to be managed using profiles.

That I didn't know, I guess I was hoping to calibrate as best as possible using my internal controls since I have 2 other sources that won't benefit from the 3dlut calibration. I thought that was the approach that other's have been using 3dlut's for, calibrate as good as possible then use the 3dlut to fix any problems which cannot be fixed using the TV's controls. :thanks:

[Graeme Gill]

I thought that was the approach that other's have been using 3dlut's for, calibrate as good as possible then use the 3dlut to fix any problems which cannot be fixed using the TV's controls.
It would be good if it worked that way, but it depends on the display. See http://www.lightillusion.com/display_calibration.html

Similar problems have been found with various comuter displays - some have "6 color" primary adjustments, but experience is generally bad - most don't seem to work, and they wreck the display behavior, and should be avoided for accurate profiling.

[Dodgexander]

My display is 1080p native but works with 720p too, i just asked in your opinion which is better, 720p with advanced upscaling methods like lanczos3 or Jinc chroma & image, vs 720p to 1080p with bilinear in both upscaling methods.

The latter is better. If you choose the former it should look notably worse because you are scaling the image twice.

Btw, can't you use dxva for the scaling also?I would have thought that would be better.

Sent from my Blade S using Tapatalk 2

[6233638]

While I have not had good results trying to create 3DLUTs using that Ti3 Parser tool, I am glad to hear that 3DLUT creation is now a part of ArgyllCMS, and I look forward to giving it a try when I have the time to set it up.

The one you linked doesn't really seem optimal for an i1pro w/ emissive display, where you'll get best results only with direct contact with the face plate to cut out all ambient light. Since I have no desire to ever own a projector, if I went the tripod route, I'd want a setup where the i1pro was mounted at the very tip of an arm.I forget where now, but at least one of the hundreds of technical papers I've read over suggests that you should be measuring a 25mm spot-size from a display, rather than having the meter on the glass.
At the very least, bringing the sensor off the surface of the display can considerably reduce thermal drift. While the newer meters like the new i1 Display, and the latest revision of i1Pro have good thermal compensation circuits (older meters such as the Chroma 5 did not work well in my experience) it's still much better to keep the temperature stable.

And while you can leave the sensor on the display for an hour as it warms up before calibration so that it's unlikely to drift any further, the sensors have less noise at cooler temperatures, so that's another reason to use a tripod mount.

For a 25mm spot size, an i1Pro needs to be roughly 18cm from the display, and the i1 Display Pro (i1D3/Chroma 6) needs to be about 13.5cm from the display.

The SpectraCal mounts are good and while you can bolt them together as people have shown, I prefer to use one at a time and ensure that the meters are pointed at exactly the same spot/angle, rather than have both on the same mount. It's less convenient, but more consistent.

I agree this is the best option, especially considering I own an i1pro already to profile against. I almost bought an i1d2 for this purpose years ago, but never got around to it. Whenever I get around to spending the cash to have my i1pro re-certified (esp. if it still needs to go to/from Switzerland), I'll probably drop down another ~$200 at the time to get an i1d3.Unless you are actually using the i1Pro in a professional environment where it needs to be NIST certified, if it passes the X-Rite diagnostics, chances are that the meter is good. The i1Pro design is very stable.
And a lot of people mistake certification for calibration - it's my understanding that if the meter does not meet spec, you will have to buy a new one. (though SpectraCal may be able to provide calibration tables for use within CalMAN so it's in spec when used there)

And for what it's worth, it is a good thing you passed on the i1D2. The i1D3 is significantly better than any other consumer-grade colorimeter I have used.
Actually, the Chroma 5 was being sold as a "pro" meter with a NIST certification, and it's a lot better than that, too. Same goes for the X-Rite Hubble. Prior to that, the best consumer-grade meter in my experience was the old DTP-94. It still outperforms just about anything else consumer-grade up to the i1D3. (I wouldn't recommend anyone buy one now though)

Note that attempts to both calibrate displays using their in-built controls and profile them often don't work that well - the internal controls sometimes mess up the color behaviour in ways that can't be straightened out by profiling. So it's typically best to set internal controls to be as neutral as possible (ie. to alter the native behaviour of the display as little as possible) if the color is to be managed using profiles.If you are unsure about what's going on inside your display, then this is generally good advice.

But when you only have 8-bit correction through a video card, I find that you are best to get gamma as close to correct as you can using the display's controls first, as it usually has at least 10-bit precision and should help reduce banding/posterization. (note: you are generally best to be "under" rather than "over" - measuring 2.1 at a point rather than 2.3, if your target is 2.2 for example)

Similarly, while I wouldn't recommend using CMS controls on your display unless you really know what you're doing, and how they interact with the LUT generation, if you have a "Wide/Normal" gamut toggle, sometimes that's the only way to reduce a wide gamut without introducing a ton of banding.

[Xaurus]

madshi,

It would be great if you could add the date to your first post where the info about the latest version is located.

[Guest]

Doesn't this line on the post give you the date:

Last edited by madshi; 22nd February 2013 at 14:28.

[MSL_DK]

Regarding madVR - ArgyllCMS. Please see this thread (http://www.avsforum.com/t/1471169/madvr-argyllcms/30#post_23295688) regarding "disable GPU gamma ramps."

SYS
Win7 x64
GPU: ATI HD 4850
madVR "fullscreen exclusive mode"

[digitech]

The latter is better. If you choose the former it should look notably worse because you are scaling the image twice.

Btw, can't you use dxva for the scaling also?I would have thought that would be better.

Sent from my Blade S using Tapatalk 2

Actually im using dxva for scaling i forgot to add, but i love the smooth motion function thats why i found in 1440x810 custom resolution it has no hiccups and no frames losts, when i do 1920x1080 only works fine if smooth motion is disabled, i think it finds the limits of my Nvidia ion gpu.

[Xaurus]

Doesn't this line on the post give you the date:

Last edited by madshi; 22nd February 2013 at 14:28.
Yeah, it gives me the date of when the post was updated. Since when is that equal to the date of the latest version?

[cyberbeing]

I forget where now, but at least one of the hundreds of technical papers I've read over suggests that you should be measuring a 25mm spot-size from a display, rather than having the meter on the glass.
If you ever find the source, I'd be interested in reading it.

The only benefit I could image from having a meter far enough away to measure a full 25mm patch all at once, would be to compensate for the extremely low pixel density of large screen TVs. Add that to the high heat output of most large TVs, and I could see why tripods at an ample distance would be the preferred method for professional ISF calibrations. Though I still think I'd favor an adjustable arm tripod mount compared to what spectracal offers, even if I was going to have my meter at certain distance from the display.

On computer displays with high pixel-density and significantly lower heat output, using a tripod from a distance probably isn't beneficial as much. And I can't say I ran into any notable issues with repeatability or drift when I did my initial calibration of my Panasonic plasma via ColorHFCR a few months ago using the default holder against the screen. At a certain point, a balance needs to be struck between cost, practicality, and diminishing returns.

And a lot of people mistake certification for calibration - it's my understanding that if the meter does not meet spec, you will have to buy a new one.
Probably depends how far out-of-spec the device actually is. I mean, the entire point of it getting sent to Switzerland, is so they have the facilities to update the firmware, perform minor repairs, and replace parts (extra charge) if need be. I'm sure it's probably fine, but considering my meter is now 5 years old, I'm reaching the point where I feel I need to get it re-certified for peace-of-mind that it is still functioning nominally, especially if I were going to calibrate an i1D3 or other meter against it as a reference.

Regarding madVR - ArgyllCMS. Please see this thread (http://www.avsforum.com/t/1471169/madvr-argyllcms/30#post_23295688) regarding "disable GPU gamma ramps."
...
"Something is wrong with madVR"

I'm not seeing how you came to the conclusion that something is wrong with madVR from that post.

If you use "collink -a tv.cal" you need to use a linear VideoLUT (fullscreen exclusive "disable GPU gamma ramps" or dispwin -c or Overlay mode)

If you use "collink" without that -a parameter you need load the tv.cal file into your VideoLUT (gamma ramps) and leave it enabled in madVR. Just remember that you cannot use Overlay mode.

[MSL_DK]

I'm not seeing how you came to the conclusion that something is wrong with madVR from that post.

If you use "collink -a tv.cal" you need to use a linear VideoLUT (fullscreen exclusive "disable GPU gamma ramps" or dispwin -c or Overlay mode)

If you use "collink" without that -a parameter you need load the tv.cal file into your VideoLUT (gamma ramps) and leave it enabled in madVR. Just remember that you cannot use Overlay mode.


If you use "collink -a tv.cal" you need to use a linear VideoLUT (fullscreen exclusive "disable GPU gamma ramps")

"disable GPU gamma ramps" does not work in this case. look here http://www.avsforum.com/t/1471169/madvr-argyllcms/30#post_23291899

But I was not aware that dispwin-c was for Overlay mode. No wonder I got a bad result

[cyberbeing]

"disable GPU gamma ramps" does not work in this case. look here http://www.avsforum.com/t/1471169/madvr-argyllcms/30#post_23291899

I'm still confused because in that post you said you ran dispwin -c, at which point madVR "disable GPU gamma ramps" isn't supposed to do anything.

In any case, your yellowish results seem to suggest a problem with the Argyll 3DLUT you created, not madVR. The only other thought is because you have an ATI/AMD video card, make sure you have disabled "Use Extended Display Identification Data" in your catalyst control panel, as that option seemed to be causing trouble for a few people on the Argyll mailing list recently.

But I was not aware that dispwin-c was for Overlay mode. No wonder I got a bad result
No, Overlay mode is an alternative to dispwin -c, since both will result in a linear VideoLUT.
madVR's "disable GPU gamma ramps" option should be equivalent to running dispwin -c, but affects Fullscreen Exclusive mode only (though possibly broken on WinXP from what Graeme has said).

[MSL_DK]

I'm still confused because in that post you said you ran dispwin -c, at which point madVR "disable GPU gamma ramps" isn't supposed to do anything.

In any case, your yellowish results seem to suggest a problem with the Argyll 3DLUT you created, not madVR. The only other thought is because you have an ATI/AMD video card, make sure you have disabled "Use Extended Display Identification Data" in your catalyst control panel, as that option seemed to be causing trouble for a few people on the Argyll mailing list recently.


No, Overlay mode is an alternative to dispwin -c, since both will result in a linear VideoLUT.
madVR's "disable GPU gamma ramps" option should be equivalent to running dispwin -c, but affects Fullscreen Exclusive mode only (though possibly broken on WinXP from what Graeme has said).

I am somewhat confused ... I have also tried to run collink "-a display.cal" without running dispwin -c and the result was precisely a yellowish tinge. (ON: fullscreen exclusive and "GPU gamma ramps")

But without collink "-a display.cal" and with dispwin display.cal do I get an almost perfect result. (ON: "fullscreen exclusive" OFF "GPU gamma ramps")

regarding dispwin ... Should dispwin-c, or dispwin "-a display.cal" run after every reboot of windows?

[Thunderbolt8]

Yeah, it gives me the date of when the post was updated. Since when is that equal to the date of the latest version?it usually is

[n3w813]

But without collink "-a display.cal" and with dispwin display.cal do I get an almost perfect result. (ON: "fullscreen exclusive" OFF "GPU gamma ramps")


This is the correct method!

I think you are still confused on when to use what....

*** First make sure FSE is enabled in MadVR. Make sure when viewing results MadVR is in FSE mode***

If you run "dispwin -c" Then
---Run collink.exe with "-a display.cal"
---"Disable gpu gamma ramps" checkbox in MadVR has no effect on image
End with expected results

If you run "dispwin display.cal" Then
---Run collink.exe without "-a"
---Uncheck "Disable gpu gamma ramps" checkbox
End with expected results

[FlashGordon]

madshi, is it possible to make the refreshRate file tags work even if the format isn't specified in the settings? For example, I currently only have 1080p24 as a display mode because I mostly watch films and NTSC DVDs were not triggering the change to 24hz. However, for the odd video file that I have, even if I tag it with [refreshRate=60], the display will still switch to 24hz because I don't have 1080p60 as a display mode in the settings. Is there a way you can make the filename tag override this and force the switch to whatever refreshRate is specified?

[flanger216]

The Nvidia control panel is able to switch to 24/60Hz correctly though, so it's not that the OS can't do 24/60Hz. Something must have changed with how refresh rate switching works though.

The "good" thing about this, is that your post finally confirms what I had been unable to get an answer for - the problem is not specific to Nvidia cards, and affects AMD (and likely Intel) too. Previously it had been suggested that this was a driver bug, but I find unlikely that both Nvidia and AMD have the same bug.

A "fix" for this is to run ReClock or JRiver's VideoClock which will eliminate the stuttering caused by the framerate/refreshrate mismatch.

But I wish someone could figure out why the refresh rate switcher isn't working correctly so that we can get 24/60 back.

23Hz on my card outputs 23.970.. but 24Hz is 24.0000.

I can also reconfirm this bug --- manually switching to 24hz or 60hz works fine, but madVR's automatic switcher will never switch to these rates, and instead always forces the display either to 23hz or 59hz. I'm also using Windows 8, and I'm running ATI.

The problem persists with the "Use 24p for PAL" setting. PAL content used to trigger a switch to 24hz, but now it switches to 23hz instead.

However, all of these issues also occur with MPC-HC's internal refresh switcher. So I suspect madVR and MPC-HC (and likely other media software) use the same process to initiate a refresh switch, and that process has become bugged or deprecated under Windows 8.

Currently the only solution does seem to be Reclock. Which is a bit too bad, as I get lower CPU usage and (somehow?) less clock drift when simply bitstreaming.

[MSL_DK]

This is the correct method!

I think you are still confused on when to use what....

*** First make sure FSE is enabled in MadVR. Make sure when viewing results MadVR is in FSE mode***

If you run "dispwin -c" Then
---Run collink.exe with "-a display.cal"
---"Disable gpu gamma ramps" checkbox in MadVR has no effect on image
End with expected results

If you run "dispwin display.cal" Then
---Run collink.exe without "-a"
---Uncheck "Disable gpu gamma ramps" checkbox
End with expected results

Thanks for the explanation :)

>>>>>>>>>>>>>>>>>>

I have a question regarding madVR - ArgyllCMS ... Could this be an indication of "black crush"?

https://dl.dropboxusercontent.com/u/111324524/Images%20for%20Sharing/ArgyllCMS/madvr_f.png

[nevcairiel]

Many meters are rather inaccurate at 10%, its not a clear indication for anything without knowing more.

[MSL_DK]

Many meters are rather inaccurate at 10%, its not a clear indication for anything without knowing more.

Thank you ... What information can I contribute? The instrument is a i1Display3

[cyberbeing]

Well I've been working on profiling again tonight, and I seem to be making progress. Changed my workflow yet again, notably I got rid of dispcal completely, and re-adjusted my GDM-F520 for the most consistent gamma response and white balance across the luminance range that I could manage via pre-calibration in ColorHFCR2 instead of Argyll's built-in method. Also pulled out the masking tape, so I wouldn't have to hold my meter for the large patch set.

dispwin -c

targen -v -d3 -s21 -g21 -m5 -f256 PreCond_256

dispread -v -w -H -F PreCond_256

colprof -v -qh PreCond_256

targen -v -d3 -G -e8 -s41 -g81 -m5 -f1084 -c PreCond_256.icm GDMF520_1084

dispread -v -w -H -F GDMF520_1084

colprof -v -qh GDMF520_1084

If anybody was wondering, my logic of using this combination of targen switches along with the use of the dispread -w switch, was so I'd actually have measurement data points which would be useful outside of Argyll. A good number level steps interlaced throughout my gamut as well, to ensure that Argyll would have little excuse for messing up what should be a predicable gamma & basic internal structure of my CRT's gamut cube. Though aside from my particular goals with a patch set formed in this way, most flat-panel displays would likely benefit more from replacing the multi-dimensional patches with full-spread patches in the larger set, similar to the command line example in Argyll's Scenarios documentation. YMMV.


Preconditioning set of 256:
-s21 = 20 levels (5% steps) Red, Green, Blue
-g21 = 20 levels (5% steps) Grayscale
-m5 = 4 levels (25% steps) Multi-dimensional [Red, Green, Blue channel mixtures]
-f256 = 64 full spread patches


LAB cLUT ICC profile created from 256 set to precondition the full 1084 patch set, basically a scaled up version:
-s41 = 40 levels (2.5% steps) Red, Green, Blue
-g81 = 80 levels (1.25% steps) Grayscale
-m5 = 4 levels (25% steps) Multi-dimensional
-f1084 = 768 full spread patches
-e8 = 8 White Point readings to better average out any bad readings when my i1pro catches my CRT refresh at a bad time



My main goal tonight was to see how well collink's BT.1886 gamma scaling would function when used alone. Now that I seem to have an extremely solid LAB cLUT monitor profile, likely in part because of the recent targen/dispcal/dispread changes Graeme made the other day, collink 3DLUT results seem more promising. Too tired now to actually take measurements to verify what values the 3DLUT is actually outputting, but I'm not noticing the same blatantly visible errors I was seeing with my first attempts using existing profiles created via dispcalGUI's workflow & bundled patch sets.


@Graeme
Files resulting from my profiling workflow tonight:
http://www.mediafire.com/?kgbsafbobjk1pc1

[Edit: I notice that a XYZ cLUT profile from this ti3 data continues to give poor tone smoothness (visible banding) on gradients compared to the LAB cLUT profile which is very smooth]

Some other night, I'll need to add dispcal back into the mix, and see if this level of quality can be maintained with my preferred gamma curve.

Possible Bug: If you use a RGB -> LAB cLUT as your ICC source device profile, collink generates an invalid 3DLUT. madVR outputs a black screen and complains the 3DLUT does not contain primary information. If you can't reproduce this, I must have made an error when creating the LAB cLUT device profile.

[Graeme Gill]

I have a question regarding madVR - ArgyllCMS ... Could this be an indication of "black crush"?

It depends on the details of how the 3dlut was created, but I would imagine that your just seeing your displays not quite perfectly neutral black coming through. The alternative is to boost the black point to be able to neutralize it, but I imagine that you probably would prefer to maintain your contrast ratio.

[6233638]

The only benefit I could image from having a meter far enough away to measure a full 25mm patch all at once, would be to compensate for the extremely low pixel density of large screen TVs. Add that to the high heat output of most large TVs, and I could see why tripods at an ample distance would be the preferred method for professional ISF calibrations.And those are useful benefits. It also helps reduce issues caused by narrow viewing angles. (LCD, OLED etc.)

At a certain point, a balance needs to be struck between cost, practicality, and diminishing returns.While I did end up buying the SpectraCal brackets because they are convenient, I just bought the cheapest 5 section tripod (or maybe it was 6?) so that it was very compact and folded down to less than a foot in length.
Before I bought the SpectraCal brackets I just used some large rubber bands to attach the meter to the quick mount plate on the tripod head.

You're not trying to take photographs with the thing, so cost doesn't really matter, it's more about getting it off the surface of the screen than anything else.


Probably depends how far out-of-spec the device actually is. I mean, the entire point of it getting sent to Switzerland, is so they have the facilities to update the firmware, perform minor repairs, and replace parts (extra charge) if need be. I'm sure it's probably fine, but considering my meter is now 5 years old, I'm reaching the point where I feel I need to get it re-certified for peace-of-mind that it is still functioning nominally, especially if I were going to calibrate an i1D3 or other meter against it as a reference.Well it's up to you, but as long as you've taken care of it (don't drop it, store it away from heat and sunlight, keep a desiccant in the box) and it is passing the X-Rite self-tests, I doubt meter certification is going to do anything other than send it back saying it's OK. They're very stable meters and I've seen ones older than that pass certification without any trouble.

[petran79]

I did upgrade the GPU, from an Nvidia GTS450 to a GTX660

Now in Windows 7 there are no issues with MadVR.

But on Windows XP, after the upgrade any video I play with MadVR shows dropped frames for like 10-15 seconds, then plays normally and after a while dropped frames appear again for the same length. If I choose other renderers videos play normally. If I choose lower settings in Madvr, delay may appear much later or not at all if the video is lower in quality.

No matter if its in MPC or Potplayer or any player.

With the lower tier GPU all videos played normally with MadVR on XP.

No big issue as I mostly use Windows XP for old games and play videos on Windows 7

this must be probably an Nvidia driver issue rather than MadVR.

[maco07]

Hi madshi. Can you share with us in wich new features are you working for next madVR version?

Great work!! I'm using madVR sin 0.3x!

[Dodgexander]

Hi madshi. Can you share with us in wich new features are you working for next madVR version?

Great work!! I'm using madVR sin 0.3x!

Too many to post I think ;)

Sent from my Blade S using Tapatalk 2

[leeperry]

I did upgrade the GPU, from an Nvidia GTS450 to a GTX660

Now in Windows 7 there are no issues with MadVR.

But on Windows XP, after the upgrade any video I play with MadVR shows dropped frames for like 10-15 seconds, then plays normally and after a while dropped frames appear again for the same length. If I choose other renderers videos play normally. If I choose lower settings in Madvr, delay may appear much later or not at all if the video is lower in quality.
"lower in quality" :confused:

Is the refresh rate properly detected? Is the problem still there with the old rendering path?

Anyway, thanks for the feedback as you are the second person mentioning that 660's are unusable with mVR on XP and I was just about to order one.....I guess I'll have to find the motivation to install and thorougly testbed W7/W8 before ordering a new GPU, bummer....but apparently W8 comes with its own bag of new problems, m$ doesn't want to release W7 SP2(critical hotfixes were released for audio & USB since SP1) and madshi might very well not care all that much about XP anymore. Oh well, don't fix it if it's ain't broken and I'll be saving money in the process too I guess ^^

Last time I checked everyone was saying you still couldn't us madVR with TV.
I'm wet dreaming about HD DVB-T with 1080@50i CUVID deinterlacing, J3AR scaling, inverse-palspeedup with Reclock to 24/48p and smooth-motion with mVR in 140Hz on top of it :scared: .....but if the 660 is no workee on XP with mVR then I'll have to bite the bullet and upgrade, hah.

I see that you can specify a DVB-T input device in PotP, and as a worst case scenario DragonQ told me that JRiver can do DVB-T with mVR.

[pie1394]

I'm wet dreaming about HD DVB-T with 1080@50i CUVID deinterlacing, J3AR scaling, inverse-palspeedup with Reclock to 24p and smooth-motion with mVR in 140Hz on top of it :scared: .....but if the 660 is no workee on XP with mVR then I'll have to bite the bullet and upgrade, hah.


My 4 years-old HTPC's MB just suddenly becomes unstable. But it is not a good timing to buy new PC components since DDR3 becomes twice expensive and Intel next-generation CPU will come out soon.

Anyway I have no choice but to upgrade the CPU+MB+RAM from

C2D E8400 + Gigabyte EP45-UD3P + Kingbox DDR2-1066 2GB *4

to

i5-3570K + MSI Z77A-G41 + Transcend Axe DDR3-2400 XMP 4GB * 2.
(about US$420 in my country, 5% tax included)

It is not cheap for this upgrade, but guaranteed to handle super-high bit-rate FHD H.264 Hi10, H.264 / HEVC 4K contents -- and new games with my previously upgraded Lantic HD7970.

Hyperthreading and extra 2 MB L3 cache on E3-1230v2 will not show the obvious advantage over i5-3570K for multimedia / gaming purposes. Instead the higher boosted clock rate on i5-3570K gains more actual speed. So I still decided to choice the later one.

Actually Haswell will not have big gain on CPU part's calculation performance unless the program contains a lot of AVX SQRT calculation. The current Sandy/Ivy-bridge's are not fully 256-bit implementation for all AVX instructions. Multi-threads > 4 on 4-core/8-HT CPU will NOT boost the SSE4/AVX performance either since all-HT in the same core still shares the same set of SSE4/AVX arithmetic units. Only those cheap-cost scalar instructions get extra arithmetic units.

I feel the main improvement on Haswell x86 part is for multi-threaded and multi-processed program. The common mutex / semaphore / critical section operations are implemented as x86 instructions now. It is no more needed to perform EXTERNAL memory bus locking / reading access in order to check if a mutex is locked by any other CPU core. So other cores running totally different memory access will not be held/blocked for unnecessary CPU cycles.

Of course it still needs these OS API call or program itself implemented in the new instruction set to gain the advantage.

[JarrettH]

I don't know who else is using Intel HD Graphics here, but I just lowered my rendering times by 10 ms on this PC:

Intel i3 2100
4GB DDR3
Intel HD Graphics 2000 on latest drivers
Win 7 64-bit
latest official mpc, madvr, lav (quicksync)

madvr settings

image scaling: DXVA2
chroma scaling: bicubic75 with AR

general settings: cpu queue 8, gpu queue 4 <<< that made a tremendous difference from the default of 12/8

backbuffers: 4
present queue: 6

smooth motion: on <<< allowing me to now turn on smooth motion

[digitech]

I don't know who else is using Intel HD Graphics here, but I just lowered my rendering times by 10ms on this PC:

Intel i3 2100
4GB DDR3
Intel HD Graphics 2000
Win 7 64-bit
latest official mpc, madvr, lav (quicksync)

madvr settings

image scaling: DXVA2
chroma scaling: bicubic75 with AR

general settings: cpu queue 8, gpu queue 4 <<< that made a tremendous difference from the default of 12/8

backbuffers: 4
present queue: 6

smooth motion: on <<< allowing me to now turn on smooth motion
Nice tip, i'd like to know what kind of files you usually play, sd, 720p to 1080p? thanks

[JarrettH]

Mostly 720p. Standard definition stuff (720 x 400...ish) my rendering times were 12 ms lower.

I should have mentioned they are only being scaled up to 1680x1050. Does going to 1080p have a bigger impact? This isn't my home machine.

[iSunrise]

Mostly 720p. Standard definition stuff (720 x 400...ish) my rendering times were 12 ms lower.

I should have mentioned they are only being scaled up to 1680x1050. Does going to 1080p have a bigger impact? This isn't my home machine.
FYI, it´s not important of your rendering times are 12ms lower, when you don´t actually have dropped frames or other performance problems with the default settings. Decreasing your queues is only useful for tweaking on high-performance CPUs or graphics hardware, where you have a lot of headroom left. I would stay away from altering the settings if all you accomplish is lowering your rendering times. The only positive side-effect is that decreasing your queues (on capable hardware) leads to faster switching and skipping.

The higher your source:target resolution difference, the more taxing it is for your hardware, as madVR needs to upscale a lot more. Depeding on your scaling (quality) settings, madshi implemented optimized algorithms that are especially fast if you only need to scale certain factors like 2x. If you need to scale to some uncommon factors, you could potentialy lose a lot of speed.

[digitech]

Mostly 720p. Standard definition stuff (720 x 400...ish) my rendering times were 12 ms lower.

I should have mentioned they are only being scaled up to 1680x1050. Does going to 1080p have a bigger impact? This isn't my home machine.

You should try the 1680x945 custom ratio to avoid any distortion if your primary monitor belongs to the 16:9 standard, actually i have a 1440x810 custom resolution with lanczos3 and anti ringing option activated in chroma, dxva with image, only in that resolution i can get away with the smooth motion functionality, if i try 1680x945 i have lots of ghosting and too much dropped and delayed frames. I have an nvidia ion gpu and a intel atom htpc, a little too low to be able to handle more demanding upscaling methods and resolutions, but the compromise looks awesome to my eyes, I think if you are going for the 1080p route you can have dropped frames but try it maybe tour gpu/cpu can handle it, i recommend to try setting up your resolution in a 100 pixel increase/decrease basis so you can find a sweet spot where you can have a smooth playback.

[JarrettH]

FYI, it´s not important of your rendering times are 12ms lower, when you don´t actually have dropped frames or other performance problems with the default settings. Decreasing your queues is only useful for tweaking on high-performance CPUs or graphics hardware, where you have a lot of headroom left. I would stay away from altering the settings if all you accomplish is lowering your rendering times. The only positive side-effect is that decreasing your queues (on capable hardware) leads to faster switching and skipping.

The higher your source:target resolution difference, the more taxing it is for your hardware, as madVR needs to upscale a lot more. Depeding on your scaling (quality) settings, madshi implemented optimized algorithms that are especially fast if you only need to scale certain factors like 2x. If you need to scale to some uncommon factors, you could potentialy lose a lot of speed.

I was only tweaking because I wanted to use smooth motion on this PC. Before I couldn't because with smooth motion on, it was over the movie frame interval time which I think you're supposed to be under for proper playback.

[fallengt]

Disable Gamma Ramps in madvr doesn't for me so I use http://www.xrite.com/product_overview.aspx?ID=789&Action=support&SoftwareID=546 to reset GPU gamma curve. Does it work the same way as "dispwin -c" ?

[DragonQ]

The higher your source:target resolution difference, the more taxing it is for your hardware, as madVR needs to upscale a lot more. Depeding on your scaling (quality) settings, madshi implemented optimized algorithms that are especially fast if you only need to scale certain factors like 2x. If you need to scale to some uncommon factors, you could potentialy lose a lot of speed.
Is it? I thought 1440x1080i was generally the most taxing when outputting at 1080p.

[dansrfe]

Sometimes the render queue inexplicably drops to 0/8 when I go from exclusive to windowed mode. In order to resolve this I either have to pause the video for 5 - 10 seconds and play or I have to restart the player. I think this may be connected to some bug in the smooth motion but I'm not really sure.

[callannn]

Hi, first time poster here so please bear with me. I've been using MPC-HC and madVR for a while now but know next to little about it, and have used Niyawa's Guide (http://myanimelist.net/forum/?topicid=516729) exclusively for anime playback. I'll give you the specs of my laptop

Samsung NPC700G7C
Intel Core i7 3610QM @2.30GHz
16.0GB RAM Dual Channel DDR3
NVIDIA GeForce GTX 675M

I have followed Niyawa's guide to the word apart from a few things (I don't use ffdshow and have Smooth Motion turned off) and I am using the Highest settings under scaling algorithms. I recently had a few problems with dropped/delayed frames getting into the hundreds but realised that was due to me not disabling f.lux. Now I have 0 dropped/delayed frames during playback, but I have noticed another problem. When I play 480p and lower content and lower, my average rendering time seems to skyrocket, but when I watch 720p/1080p content, it stays at around 4-6ms depending on if i'm watching 8bit or 10bit content. Surely it should be a lot than this?
I also seem to be having problems with exclusive mode. Now, even though I don't particularly use it, I was just wondering why when I switch to it the playback becomes sluggish and redering time skyrockets once again? Would this be because I haven't changed anything under 'exclusive mode' in madVR settings?

Thank you

[iSunrise]

Is it? I thought 1440x1080i was generally the most taxing when outputting at 1080p.
I didn´t say what is the most taxing, I said that the higher your source:target resolution difference is, the more taxing it is for your hardware. That is only true for the cases JarettH has mentioned, though, not in general. The higher your source resolution, the more pixels your hardware has to process and if you add interlaced resolutions that need to be converted to progressive, that is going to tax your hardware even more, which should be obvious. You don´t need your PC for that though, deinterlacing can also be accomplished with your display, so you have more headroom for scaling in madVR.

[nevcairiel]

I didn´t say what is the most taxing, I said that the higher your source:target resolution difference is, the more taxing it is for your hardware

But thats not true.
The performance requirements for scaling 1919x1079 to 1920x1080 is a lot higher then scaling 192x108 to 1920x1080

The more input pixels it has to read for scaling, the more taxing it will be. A higher scaling factor doesn't matter much.

[iSunrise]

But thats not true.
The performance requirements for scaling 1919x1079 to 1920x1080 is a lot higher then scaling 192x108 to 1920x1080

The more input pixels it has to read for scaling, the more taxing it will be.
So it is not true that scaling SD or 720p to 1080p instead of 1680x1050 is more taxing? This is not about a general rule, my posts were specifically directed to JarettH, who asked about performance requirements if you would scale to 1080p instead of 1680x1050. Please stop selectively taking apart my post by quoting only one sentence of it and as a result, quoting me completely out of context.

Mostly 720p. Standard definition stuff (720 x 400...ish) my rendering times were 12 ms lower.

I should have mentioned they are only being scaled up to 1680x1050. Does going to 1080p have a bigger impact? This isn't my home machine.

[nevcairiel]

A higher target resolution increases the cost as well of course. The performance depends pretty much always on the number of pixels, both input and output. More = slower.
The difference between the two isn't that big, though.

Your post didn't make it clear, and it sounded quite different to your revised version now.

[iSunrise]

A higher target resolution increases the cost as well of course. The performance depends pretty much always on the number of pixels, both input and output. More = slower.
The difference between the two isn't that big, though.
I guess I should have made the bolded part more clear in my answers. You had me there for a moment.

It´s quite the bad habit that I always see mistakes only after I clicked on submit. And when I want to perfect my posts, there´s always the risk of someone that jumps at me and points to mistakes, even before I have time to correct my mistakes. It´s not intentional at all.

[MSL_DK]

Disable Gamma Ramps in madvr doesn't for me so I use http://www.xrite.com/product_overview.aspx?ID=789&Action=support&SoftwareID=546 to reset GPU gamma curve. Does it work the same way as "dispwin -c" ?

No ...

[e-t172]

No ...

I believe it does. It probably just calls SetDeviceGammaRamp() just like "dispwin -c". What makes you think it doesn't?