madVR - high quality video renderer (GPU assisted)

[mindz]

Generally with scaling algorithms, as the number of taps increases, sharpness goes up, aliasing goes down, and ringing increases.

While madVR's anti-ringing filter is great, I wouldn't recommend anything more than 3-tap filters for optimal image quality. (maybe 4-tap at a push with some filters)

So the reason for not using 4 or 8 taps is solely the increase of ringing? So if i wouldnt be to bothered about the ringing and find sharpness important, i should use 4 or 8 taps?

Also.

I know this has been asked a 1000 times and I tried a search but didnt come up with 1 specific option i need to know (Dynamic Range in CCC).

I know madshi says to have everything in the chain set to to 0-255. But for ATI users there is another setting in the CCC called 'Dynamic Range' where there is also is an option for 16-235 or 0-255. Which of the 2 do i set here (I always thought 16-235)?

The idea of setting the Dynamic Range in CCC to 16-235 is so that madVR does the upsampling from 16-235 to 0-255.

So the chain would be source (16-235) -> splitter -> lav video (16-235) -> ATI (16-235) -> madvr (16-235 -> 0-255) -> ATI RGB Full Pixel format (untouched).

If i set the Dynamics Range to 0-255 the upsampling is done by the videocard and not madVR, has this recommendation changed?

[mindz]

Double

[G_M_C]

So the reason for not using 4 or 8 taps is solely the increase of ringing? So if i wouldnt be to bothered about the ringing and find sharpness important, i should use 4 or 8 taps?

Also.

I know this has been asked a 1000 times and I tried a search but didnt come up with 1 specific option i need to know (Dynamic Range in CCC).

I know madshi says to have everything in the chain set to to 0-255. But for ATI users there is another setting in the CCC called 'Dynamic Range' where there is also is an option for 16-235 or 0-255. Which of the 2 do i set here (I always thought 16-235)?

The idea of setting the Dynamic Range in CCC to 16-235 is so that madVR does the upsampling from 16-235 to 0-255.

So the chain would be source (16-235) -> splitter -> lav video (16-235) -> ATI (16-235) -> madvr (16-235 -> 0-255) -> ATI RGB Full Pixel format (untouched).

If i set the Dynamics Range to 0-255 the upsampling is done by the videocard and not madVR, has this recommendation changed?

In relation to the CCC settings; I've switched all advanced settings off. Set everything to application preference (or what it's called in English). This way the player/renderer chain handles all conversion, and the GPU does nothing. In my experience this is the way to go.

[secvensor]

madVR 0.84.7
http://i48.fastpic.ru/big/2012/1119/35/23d9aac915d262d7032bac5dfd5a3535.png
Badly works with changeable interlejsing video :/
http://www.sendspace.com/file/3t3aju

[6233638]

madVR 0.84.7
http://i48.fastpic.ru/big/2012/1119/35/23d9aac915d262d7032bac5dfd5a3535.png
Badly works with changeable interlejsing video :/
http://www.sendspace.com/file/3t3ajuThis is film-type content (cadence detected as 3:2) and you are forcing video deinterlacing.

[secvensor]

3:2?
I don't fink so:
Format : BDAV
Format/Info : Blu-ray Video
File size : 7.49 GiB
Duration : 27mn 13s
Overall bit rate mode : Variable
Overall bit rate : 39.4 Mbps
Maximum Overall bit rate : 48.0 Mbps

Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : 27
Duration : 27mn 13s
Bit rate mode : Variable
Bit rate : 36.3 Mbps
Maximum bit rate : 39.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : MBAFF
Bits/(Pixel*Frame) : 0.584
Stream size : 6.90 GiB (92%)
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
______________________________________________
48859 frames
______________________________________________
Pair of sites(3:2/1:3/rnd(1~5~9):1):
http://www.sendspace.com/file/8nlraj

[6233638]

3:2?
I don't fink soWell madVR is detecting a 3:2 cadence, and it appears to deinterlace correctly when you use film-type deinterlacing:

http://www.abload.de/img/statsonpin.gif

If I let madVR auto-detect, it reports "video" but I am not convinced that madVR's auto detection is working correctly. (it can detect a 3:2 cadence if it's in film mode, but doesn't report a cadence in video mode)
Either way, I don't get any combing in the video.

[NicolasRobidoux]

TTBOMK, the first EWA Jinc-windowed Jinc implementation that was both "correct" and widely avaiable (in ImageMagick) is barely over two year old. (There was an almost certainly correct implementation of EWA Jinc-windowed Jinc 2 in a Masters thesis before that but I think Gustafsson's code immediately went the abandonware route.)

So, again TTBOMK, Madshi's is the first correct implementation outside of ImageMagick of EWA Jinc-windowed Jinc 3 (and above).

Now: The comment I want to make is that you should not assume that what you know about the tensor Lanczoses (what most of you call Lanczos) carries over to the EWA Lanczoses (what most of you now call "Jinc"). In particular, changing the number of lobes has a different effect with Jinc than with Lanczos. For example, my impression is that odd numbers of lobes are significantly better than even ones, at least for moderate numbers of lobes. (When there's lots of lobes, all the schemes should be pretty much the same.) For example, I think the early implementation of "Jinc 2" went nowhere because it was a 2-lobe method. But I'm not sure.

In any case, don't assume: Try things.

And I'm not even talking about the effects of deblurring and Madshi's Anti-Ring filter...

[ryrynz]

Nicolas, the general consensus is that Jinc with 3 taps and anti-ringing is the best upscaling option available within MadVR. In your opinion have you encountered anything which could surpass it?

[turbojet]

How does this differ from Spline in madVR?

madVR uses Spline36 (3-tap 6x6) and Spline64 (4-tap 8x8)



I know I suggested the sharper splines ~3 months ago, and I still think it would be interesting to test with madVR anti-ringing.

One thing I can say though is that Wilbert's spline implementation in that plugin is different from madshi's in madVR. The plugin's Spline100 (5-tap 10x10) has extremely soft results similar to madVR's Mitchell-Netravali, while the Spline144 (6-tap 12x12) results are extremely sharp surpassing even madVR's Lanczos8 sharpness by a large margin. It makes me question whether the sharper splines were implemented correctly, or if Wilbert is using a different type of spline compared to madVR. Even so, I'd be interested what a madVR Spline144 w/ anti-ringing would look like.

I recognized you mentioning them back in August in my first post. (http://forum.doom9.org/showthread.php?p=1599341#post1599341)

A quote from wilbert's website (http://www.wilbertdijkhof.com/)
SplineResize: This plugin contrains two kinds of spline based resizers:
The first ones are the (cubic) spline based resizers from Panorama tools that fit a spline through the sample points and then derives the filter kernel from the resulting blending polynomials. See this thread for the details. Spline100Resize (using 10 sample points) and Spline144Resize (using 12 sample points) are added here. Other ones are available in AviSynth itself.
The second ones are natural cubic splines that use the kernel itself as a spline. The theory can be found here.
It seems spline100/144 are based on a different theory explained here (pdf) (http://online.redwoods.cc.ca.us/instruct/darnold/laproj/Fall98/SkyMeg/Proj.PDF) which might explain the difference between the common splines and 100 and 144.

Too sharp for my tastes, though I've only looked at 144 ATM. Wouldn't mind seeing it with MadVR's anti-ringing on it.

144 is definitely sharp, 100 is a lot softer but both are between Lanczos 4 and 8 in cpu load. If the same is true on gpu would be usable by most, unlike Jinc unfortunately.

Just checked these spline resizers:
Spline144. It is sharper compared to spline36 but it adds like 40% sharpness, 60% artifacts. So don't see any use for it. By using bicubic with sharpening on top of it I can achieve same sharpness with almost no artifacts.
Spline100 to me looks like bicubic+lots of aliasing. Don't see any use for it either. Maybe it is not that surprising that they are unpopular?
I was upscaling anime vector-based image rendered at 720x480 resolution (non-square pixels) to 1920x1080. On less perfect sources artifacts may be amplified...

I only view live action content with Finesharp().f3kdb() pre-resize. With spline144 some aliasing stands out more (on shoulders for example) but also some aliasing is completely eliminated (chrome on cars) compared to bicubic75. Here's a comparisons of a typical us mpeg2 hd broadcast, this is a little higher quality then most. Bicubic75-ffdshow vs Spline144 (http://screenshotcomparison.com/comparison/159112)

ffdshow and/or avisynth plays a part in some of the edge artifacts Bicubic75-madvr vs Bicubic75-ffdshow (http://screenshotcomparison.com/comparison/159110)

In this particular frame Jinc3 seems to be a lot closer to Spline144 then Bicubic75, same kind of artifacts comparison. (http://screenshotcomparison.com/comparison/159114) Taking ffdshow edge artifacts into account they might be pretty close in terms of artifacts, one a bit sharper.

These are the reason I hadn't heard about it until recently:
- google search had 64 results, only 2 of which were relevant, neither had comparisons
- it's thread (http://forum.doom9.org/showthread.php?t=147117) is filled with technical jargon I don't understand
- xvid4psp is the only program that supports it (not a gui user though)
- splineresize is my 3rd choice in avisynth behind bicubic and lanczos, another spline isn't attractive

[Keiyakusha]

I only view live action content with Finesharp().f3kdb() pre-resize. With spline144 some aliasing stands out more (on shoulders for example) but also some aliasing is completely eliminated (chrome on cars) compared to bicubic75. Here's a comparisons of a typical us mpeg2 hd broadcast, this is a little higher quality then most. Bicubic75-ffdshow vs Spline144
The main problem with spline144 is ringing, I didn't noticed that much aliasing. It was spline100 whose only difference from avisynth's bicubic (its like Mitchell-Netravali in madvr, no?) is amount of aliasing. Ringing may look like sharpness for live action. But if you somehow remove ringing, spline144 will lose half of its "sharpness". As to your screenshots, I can't really say anything. I watch live action rarely so never tried to learn how to make it look better. But still with such low quality source I don't see much reason to be picky with resize, whatever will do... Especially if you do use separate sharpening. You may consider using more sharpening instead. Probably masked sharpening, because sharping these artifacts even more is a no go.

[ryrynz]

In this particular frame Jinc3 seems to be a lot closer to Spline144 then Bicubic75, same kind of artifacts


Spline144 crosses the mark IMO, edges start to unnaturally stand out against the lower resolution/softer backgrounds. I couldn't use it on anything without anti-ringing on it, Perhaps Madshi can satisfy our curiosity at some point.

[madshi]

madshi, I have an issue highlighting some DVD menus. My issue is the highlightable / selectable area with the mouse seems to be off in the vertical axis by perhaps 100px, hard to know exactly by how much.

I can only reproduce on some DVD's which is weird, some are perfectly fine. Is there any information I could give, if you wanted to check it out at any point.
Can you please upload samples for me? See LAV Filters thread to see which files to upload. Don't remember which right now. If possible from 2 or 3 DVDs showing this problem. Thanks!

Has anyone else messed around with spline100 and spline144 resizers from splineresize.dll (http://www.wilbertdijkhof.com/)?

Cyberbeing suggested them back in August. (http://forum.doom9.org/showthread.php?p=1586987&highlight=spline144#post1586987) I've been using them lately through ffdshow and it looks promising, very sharp with minimal artifacts, cpu load is between lanczos4 and lanczos8, here's a parking meter comparison to some other madvr resizers. (http://megaload.it/g7colcw3obbt) It was made with windowed fullscreen print screen with bicubic75 chroma. Is this interesting enough to consider for a future release?
I'm not sure. Spline100 looks overly soft to me. Why using 5 taps when the result is so soft? Spline144 looks over-sharpened too me. I don't think either Spline100 nor Spline144 are just higher taps versions of Spline36/64. There's something very different about Spline100 and Spline144, which make me wonder if there's either something wrong, or maybe they're based on a completely different logic.

I notice quite a difference between lanczos3 in madvr and ffdshow, specifically more artifacts in the latter. Could this be caused by chroma being upsampled twice? MadVR is definitely upsizing chroma, load changes when resizer change but what's ffdshow doing with it?
Don't know...

Also what are the avisynth equivalent to madvr's spline resizing? Is it splineresize(taps=3-4) or spline36/64?
I've no idea. I don't know the avisynth source code.

newbie here, how come my composition rate from 60hz change to 30hz after updated madvr 0.84.7? thanks..
There should be no difference between v0.84.7 and v0.84.6. Or which older version did you use before? What is your screen refresh rate? The composition rate isn't really chosen by madVR, so there's probably nothing I can do about this, anyway.

Could you please tell me where the config is stored? I tried writing a batch file to replace settings.bin but it doesn't affect the options. I have a switchable graphics system so Intel HD can't handle Lanczos resizing (maybe Ivy Bridge can)
Check out the "restore default settings.bat" batch file. It shows you how to change settings via batch. The settings are stored both in the registry and in the madVR folder (if madVR has write access to it). The easiest way to switch settings is to delete the settings in the registry and then switch the "settings.bin" file.

If 3d vision is activated, madshi crashes.
When 3d vision is deactivated, madshi works.

Please, let me know how send the crash report, as it's too long (52955 characters), so I can't report here.

http://pastebin.com/W2AyMJnF
Looks like a bug/crash inside of the NVidia driver. There's probably nothing I can do about it. It seems to dislike the way madVR renders the video for some weird reason.

Honestly, most auto-generated LUTs aren't that good in my experience.

You would think that programs would be best at doing this algorithmically rather than taking the time to hand-tune things, but most of the time tolerances just aren't strict enough or the emphasis is on speed and making a "good enough" profile. It isn't worthwhile if your display drifts a lot, but if your display is good enough, it's definitely worth putting the effort in. (please, no-one suggest ArgyllCMS...)
I still think that auto-creating a "perfect" 3dlut should be possible, at least if your display's gamut isn't too small. The current yCMS version tries to do a lot of things, based on math formulas, and these formulas have some limitations. So for some things yCMS improves, maybe other things could get worse. I've had an idea for a totally different concept for yCMS v2 which yesgrey plans to implement sooner or later which should hopefully create perfect 3dluts. But it might take a while until we got to that. For now we'll have to live with the limitations of yCMS v1.

madshi, is there any way a donation can help speed up the 3D support? :)
No. But it's not too far away, anyway. Probably the next big thing I'll be working on, after v0.85 is released, with the new v0.85 features (which I'm not telling yet).

The Problem: If I am opening a video for the first time after the PC boots up, the switch to FSE seems to take like 6-8 seconds. I see a pure black screen and can hear audio going on in the background as this is going on. I can see madVR drops no frames, just I basically miss the first few seconds of the clip.
This sounds like a driver specific behaviour. There's probably nothing I can do about it.

BTW, I'm officially through with LCD TV sets so I will now finally follow your advice to try plasma's, hopefully finding a set that *works* won't end up being a headache as it's been with CCFL and edge led LCD's so far. I've tried half a dozen sets and winning the panel/clouding lottery seems plain impossible.....
I'm back on CRT atm and prolly gonna buy a cheap 720p DLP so Jinc3 AR downscaling would be amazing if any possible indeed.
What happened to your plan to try a Plasma? From what I've read you had like 200 different LCD sets at home, not being really happy with any of them. It seems you were able to return every one of them. So what stops you from trying one Panasonic Plasma, just to give it a chance? If you don't like it (and maybe you won't), you can return it just like those hundreds of LCD sets you already tried...

That said, projection is great, of course, at least if you have total light control.

@Madshi
Problem with madvr0.84.7

statistics menus in mpc-hc has disappeared.

The problem doesn't exist with madvr0.80
v0.80 did report some statistics but they were wrong, which is why I removed it. The next build will report some statistics again, but this time correct stats.

madvr/processing/decoding/ffmpeg
When support of filters will be entered?
Probably not ever. I don't think ffmpeg has any filters worth supporting. Adding support for avisynth processing would make much more sense than adding support for ffmpeg filters, but I don't plan to do that, either.

madvr/scaling_algoritms/image_downcaling
When Jink will be support?
I don't know if it will ever be supported. Maybe. Maybe not. It seems Catmull-Rom AR downscaling in Linear Light works very well. The visual difference to Jinc downscaling would probably be very small.

A GTX 670 should be able to handle all of madVR's max upscale/downscale settings, particularly upscaling from 1080p -> 2560 x 1440 @ 60Hz right?
I would guess so, at least when using Jinc3 AR for chroma/luma upscaling. I don't think Jinc4 AR is worth the added computational power. It looks almost identical to Jinc3 AR to my eyes.

However, we're just talking about *current* algorithms. I might add other algorithms in the future, and I don't know how much GPU power they might need.

I think you are really underestimating how good Catmull-Rom is with the anti-ringing filter and linear light scaling enabled.

I would be surprised if Jinc is an improvement over it, particularly when using linear light scaling. (Linear light scaling is very important when downsampling.)
I believe Jinc should result in slightly lower aliasing and moire compared to Catmull-Rom, but for real-time playback the benefit would probably be very small indeed. And maybe ringing would be stronger when using linear light, I'm not sure.

I have a problem using PotPlayer.

With "delay playback start..." enabled, resuming play after pausing takes too long, while in mpc it doesn't. This happens in FSE.
Can I have a log from PotPlayer, please, which shows this problem? Please try to keep it as short as simple. Meaning: Start PotPlayer, reproduce the issue quickly, then close PotPlayer quickly. Thanks.

With Madvr i read in input a 3840x2160 resolution , so i can use madvr to downscale to full hd with bicubic 100 setting. Than i can joke with chroma parameters (another bicubic 100) and exclusive mode setted all flushed. Can i know your opinion? Do you think i have to use the new jinc algoritm for chroma and downscaling?The power of the pc or vga is not a problem for me , i only want the best image possible.
I can't say much about your upscaling and sharpening settings. But for downscaling it seems the current favorite it Catmull-Rom with Anti-Ringing enabled, in linear light. If you absolutely need the highest sharpness and don't care much about other artifacts, you could of course also use bicubic100 AR instead of Catmull-Rom. Jinc can currently only be used for upscaling, and it isn't as sharp as Lanczos. So if sharpness is your highest priority, I'd suggest Lanczos4 AR for Chroma upscaling and Catmull-Rom AR (or one of the Bicubic variants with AR) with Linear Light for downscaling.

i am getting problem playing file in MPC-HC with madVR..

My PC Specs if required:
No graphic card except internal 256MB (pixelshader 2.0)
If you look at the first page of this thread, it says that madVR needs hardware support for PS3.0. And that's still true, unfortunately.

ok thanks as said im open to suggestions , btw yes ive just looked at the madvr charts lols xD, btw i guess lanczos3 it is then for downscaling ey or Catmull-Rom with the anti-ringing filter and linear light scaling as suggested? or what you really think catmull-rom is best? never seen it in real but those charts look scary , lol
Those charts are mostly for *up*scaling. I haven't really tested downscaling much.

So I'm on the 306.81 drivers/XPSP3 and using the new rendering path, presentation glitches keep increasing every few secs just as they did before when OTOH the old rendering path works like a charm...so please be so kind as to not toss it :o
I don't plan to remove it, but I might sooner or later move it to a "funny tweaks" section or something like that, so that it doesn't both the average user.

I'm surprised that you still have presentation glitches. Maybe the NVidia fix only applies to Vista/win7? I don't know...

Found a small bug in v0.84.7: If you open the downscaling settings screen once the Jinc RadioButton stays disabled even if you switch to upscaling pages.
I can't seem to reproduce this problem here. Can you give me a step-by-step guide to reproduce the problem?

For those that want the 'natural look' of Jinc but can't use it due to hardware requirements or those wishing Jinc was sharper or those just looking for another resizer to mess with there's the little known spline100/144 (http://www.wilbertdijkhof.com/SplineResize_v02.zip).
Those wishing Jinc was sharper could try that. But those wanting the "natural look" won't be happy with Spline100/144.

Asked already, but can that that has changed.
Whether it is possible to use it in madVR?
http://www.twcenter.net/forums/showthread.php? t=536904
http://mrhaandi.blogspot.com/p/injectsmaa.html
This makes no sense at all for video playback.

So the reason for not using 4 or 8 taps is solely the increase of ringing? So if i wouldnt be to bothered about the ringing and find sharpness important, i should use 4 or 8 taps?
I would say this is true for all algorithms except Jinc. With Jinc some people say 4 taps isn't even sharper than 3 taps. For my eyes 4 taps are slightly sharper than 3 taps and 8 taps sharpest. But not everybody agrees. Just try them and trust your eyes. My recommendation is Jinc3 AR because I think there's just not enough benefit to go with more taps, compared to the added power requirements and maybe added ringing.

The idea of setting the Dynamic Range in CCC to 16-235 is so that madVR does the upsampling from 16-235 to 0-255.
Changing the levels is not "upsampling". It's just a range conversion. The recommendations have not changed.

Badly works with changeable interlejsing video :/
Can be please be more specific? What exactly do you mean with "badly works"? Does your computer explode? Or do you mean something else? I can't read your mind, you know...

Now: The comment I want to make is that you should not assume that what you know about the tensor Lanczoses (what most of you call Lanczos) carries over to the EWA Lanczoses (what most of you now call "Jinc"). In particular, changing the number of lobes has a different effect with Jinc than with Lanczos. For example, my impression is that odd numbers of lobes are significantly better than even ones, at least for moderate numbers of lobes. (When there's lots of lobes, all the schemes should be pretty much the same.) For example, I think the early implementation of "Jinc 2" went nowhere because it was a 2-lobe method. But I'm not sure.

In any case, don't assume: Try things.
I agree, trying is the best idea. My impression is that with AR activated Jinc3 and Jinc4 look very very similar.

I start playing file using DTS HD MA audio track at 23 hz (film), then switch to 59 (v) and have audio stuttering.

I guess that 23 (f) -> 59 (v) switch is responsible (or 59 (v) -> 23 (f)). The proplem does not occur starting playback with 59 (v).
Hmmmm... I can't really see much problems in the log file. madVR seems to do its job fine and switching display modes and deinterlacing modes seems to work fine, too.

So after the problem occurs, you can close MPC-HC and restart it, and the problem keeps occuring, until you either reboot or manually change the refresh rate via CCC. Is that correct? That sounds really weird to me. Have you tried a different ATI driver version? I'm not sure if there's anything I can do about this. The problem doesn't really seem to be my fault, but rather a driver problem or something like that.

What happens if you disable Aero? Does the problem go away then? Maybe you can try playing with the Aero disable options in the madVR settings to see if that makes a difference?

[NicolasRobidoux]

Nicolas, the general consensus is that Jinc with 3 taps and anti-ringing is the best upscaling option available within MadVR. In your opinion have you encountered anything which could surpass it?>>In my opinion,<< for general purpose, no. I really really really like Jinc 3 ("EWA LanczosSharp here: http://www.imagemagick.org/Usage/filter/nicolas) and Anti-Ringing seems to do a very good job with it.

[madshi]

It depends a bit on the content, but my personal opinion is that NNEDI3 clearly beats Jinc3 AR in many situations. Unfortunately NNEDI3 can sometimes look a bit "funny" (e.g. with grass and trees), but maybe that's something that can be fixed externally. I've no idea how well NNEDI3 would run on a GPU, though.

[6233638]

I still think that auto-creating a "perfect" 3dlut should be possible, at least if your display's gamut isn't too small. The current yCMS version tries to do a lot of things, based on math formulas, and these formulas have some limitations. So for some things yCMS improves, maybe other things could get worse. I've had an idea for a totally different concept for yCMS v2 which yesgrey plans to implement sooner or later which should hopefully create perfect 3dluts. But it might take a while until we got to that. For now we'll have to live with the limitations of yCMS v1.My main concern is that a calculated LUT, when there is no user/meter interaction, assumes the display behaves linearly, which is often not the case. I just find that I'm often fighting with automated systems to get them to behave the way I want them to, rather than finding it to be a benefit. But I look forward to seeing what yCMS 2 brings, even if it’s a long way off.

This makes no sense at all for video playback.I can think of one or two examples where anti-aliasing could potentially improve video quality, but chances are that implementing SMAA would not be worth the development time, as post-process AA has a habit of smoothing over sharp areas too. (Though SMAA is considerably better than FXAA or MLAA in this regard)

[leeperry]

What happened to your plan to try a Plasma? From what I've read you had like 200 different LCD sets at home, not being really happy with any of them. It seems you were able to return every one of them. So what stops you from trying one Panasonic Plasma, just to give it a chance? If you don't like it (and maybe you won't), you can return it just like those hundreds of LCD sets you already tried...

That said, projection is great, of course, at least if you have total light control.
Well, for all the reasons explained at the end of this very post (http://forum.doom9.org/showpost.php?p=1600195&postcount=15437), such as this really scary youtube video and the 350W power comsuption. I read a fairly detailed technical review of that panny, and the reviewer said that he could always see vertical banding on clear backgrounds on all the latest Panny's he tried, and VB turns me CRAZY. It's also said to emit a buzzing noise on clear pictures, which is also highly annoying to me.

And locally from shops with a return policy, I can only source Sammy plasma's that seem to offer very low CR from what lesnumeriques.com are saying.

I also read that Sammy suffer from a ridiculously small yielding rate on their $8K 9000 OLED serie so prices aren't going to drop anytime soon.....and when I was just about to give it all up and get a $300 used 720p DC3 DLP, the forthcoming BenQ W1070 (http://chinese.vr-zone.com/38449/benq-w1070-fullhd-projector-released-10202012/) appeared to be the answer to all my problems: DC3 1080p, short throw and high brightness so I could project onto a 2.5m wide projection screen easily, so bright that I could even use a gray screen for improved blacks, a TOTL ISF xyY CMS (http://www.audiovideohd.fr/i/imgs/17106-4.jpg), pretty darn sharp optics (http://www.audiovideohd.fr/tests/344-Benq-W1070-5.html), 6X CWS, vertical lens shift, 200W consumption in eco mode (http://projector.zol.com.cn/332/3327897.html)(1200 ANSI lumens :eek: ) and last but not least a 750€ price tag (http://www.idealo.de/preisvergleich/OffersOfProduct/3604320_-w1070-benq.html), a 150€ spare lamp(w/o being forced to order it from pricejapan ^^) and some very favorable warranty terms :scared:

The parcel itself will weight 4kg or less so I can easily send it back for a refund if need be, a whole different story from a 20/30kg 50 incher ;)

I always felt conned by Sammy and their bs lottery and I don't think that any flat screen will ever make happy(especially for 1K€..1K€ for this ****, seriously? :confused: )....also yCMS in yRGB appears to be a WIP, for some odd reason you refuse to allow us to input custom gamut coordinates into your own CMS and I really miss the killer colors I was getting on that vertical banding Hitachi 46" TV(that was pretty much dead-on Rec.709) :(

Rolling gamuts from within mVR with a mouse click makes my eyes very very happy >>>> so I will calibrate that BenQ pj to perfectly abide to Rec709 and joy will be back again :D

The BenQ works in 12bit internally so I bet that its xyY CMS will look stunning(and not like the bs RGB CMS Sammy put in their >6100 series :angry: ).

All this said, I've been playing around with LCD/CRT and soon DLP and I don't mean to repeat myself as I'm sure you are well aware of my opinion on this matter but all those technologies seem to react quite differently to dither and noise and I would indeed welcome the ability to finetune the amount of dither noise mVR uses if any possible please.....some controllers add a dither of their own, some will amplify it, try to clean it somehow(Sammy's DNIE) or worst case scenario add their own dither on top of mVR's....I really don't think that there is such as thing as a "one size fits all" dither value that will look equally good on any given display and any kind of content(real world, anime, etc) either :o

[AndreaMG]

Probably the next big thing I'll be working on, after v0.85 is released, with the new v0.85 features (which I'm not telling yet).
Let me guess: pixel shaders support?:D

[Mixer73]

Well, for all the reasons explained at the end of this very post (http://forum.doom9.org/showpost.php?p=1600195&postcount=15437), such as this really scary youtube video and the 350W power comsuption. I read a fairly detailed technical review of that panny, and the reviewer said that he could always see vertical banding on clear backgrounds on all the latest Panny's he tried, and VB turns me CRAZY. It's also said to emit a buzzing noise on clear pictures, which is also highly annoying to me.


leeperry:

Different size Panasonics are made in totally different plants. The only Panasonic plasmas that are special are the Neo models which have the Pioneer Kuro technology. I suspect the top model of the 50" is the only one. 55" and 85" are both made by Hitachi and I believe the 65" uses the older Panasonic technology.

Also power usage regarding flat panels is a great big bit of FUD. Plasma manufacturers are forced to publish peak power usage which only happens when you show peak white on the screen! A properly calibrated screen on normal content uses MUCH less, and mostly much less than a LCD or LED which basically runs at peak no matter what content is on the screen.

Banding can come down to calibration and content too. Buzzing can be a normal part of the plasma drive.

Personally, you can never get any LED to match the skin tones of a plasma, nor can you get such natural motion or black levels. Emissive technology is just inherently better IMO, and if OLED ever gets commercialized in large sizes I'll eat my underwear.

Sadly though the LED manufacturers won the propoganda war with their ridiculous over-processing and clearly cherry-picked review samples, and blatant cheating to sway power consumption tests, literally making up their own tests to make CR claims, etc etc.

[leeperry]

well, I'm talking about real world power comsumption measurements, not peak ones given as a worst case scenario by the manufacturer. I'm not expecting any vertical banding or buzzing whatsoever when I'm asked to pay 1K€, and I'm tired of that bs lottery where I always seem to lose for some reason ;)

As long as your display is spot-on the right gamut, calibrated at D65 with a 2.4<>2.2 gamma and that your saturations are within a 10% tolerance or less, I think you're good to go.

PS: oh, and posterizing is/can be quite a big issue with those Panny's as well apparently.

[NicolasRobidoux]

NNEDI3 is really impressive, but I do not like the way it fails when it fails, and IMHO it is more about creating a good looking alternate reality than a "faithful" one.

[NicolasRobidoux]

...
I agree, trying is the best idea. My impression is that with AR activated Jinc3 and Jinc4 look very very similar...Makes sense. AR changes the game.
Without AR, however, I'd never use Jinc4 over Jinc3.

[madshi]

@Guys, could we please *not* have another LCD vs. Plasma discussion in this thread? We've already had enough of that a while ago. Let's all just agree to disagree there, ok? Thanks.

@NicolasRobidoux, maybe analyzing an image and running NNEDI3 only on specific areas could do the trick?

[NicolasRobidoux]

Mathias: Yes, local content adaptivity---meaning that the blend of methods used locally will not only depend on the geometrical transformation (like for the Lohalo method in the GEGL library and bleeding edge GIMP, which is designed to robustly handle wild warps without adding any haloing or being overly compute intensive) but also on the content (like for DDL = Data Dependent Lanczos, like in the SAR Image Processor)---is clearly the way things will eventually be done.

[agustin9]

Can I have a log from PotPlayer, please, which shows this problem? Please try to keep it as short as simple. Meaning: Start PotPlayer, reproduce the issue quickly, then close PotPlayer quickly. Thanks.

Yes, of course.

madvr - log 2012-11-20 PotPlayer (http://bayfiles.com/file/sLhz/2l5GE4/madVR_-_log_2012-11-20_PotPlayer.rar)
Alternative Download Link (http://www.freefilehosting.net/madvr-log2012-11-20potplayer)

Thanks!!

[Razoola]

I dont want to derail the thread but the 2012 panasonic plasmas are a total letdown. I had the VT50 and it had three big issues...

1) vertical band down right side of screen.
2) suffered bad linebleed
3) image retention and burn in issues.

Don't get me wrong the picture was fantastic although very low lightoutput in professional modes. The above three issues however forced me to return the panel for a refund. The F1 logo burnin on the panel after a 2hour formula1 race was the last straw for me. And yes it was burnin and not retention.

(edit)
sorry madshi, I read you post after I put this one.

[ryrynz]

Don't plan on derailing either ;) but I have an ST30 and I love it :D it's no VT but it's good enough.

[leeperry]

Well, I believe madshi really wanted to avoid pages of Plasma Vs LCD arguments but quite frankly those flat screens are prolly great to watch the news while eating, play videogames or watch a movie once in a while.....but for video nutcases like us, they are a no-go IMHO...except if you manage to score a golden sample somehow, or are willing to accept visible/audible defects(clouding, posterizing, buzzing, vertical banding, you name it) :angry:

QA at the slovakian factory of Sammy seems very very poor(if it turns on = it can be sold :D) and asking 1K€ for those fubar TV's is ludicrous. Do they realize that this is the monthly salary for many/most ppl in western europe? I guess someone has to pay for their 3y on site warranty one way or the other.

I see that in the US they can get 40 inchers for $180 (https://blackfriday.bestbuy.com/door+busters/product/4758734/toshiba++40quot+class++lcd++1080p++60hz++hdtv), then yeah OK shoot! I won't be nitpicking (too) much for 140€ but for a grand it'd better be purrfect, especially when TI are releasing cheap DC3 1080p chips that will soon flood the market....it took them while to wake up, huh! They promised affordable DC4's for everyone (http://www.avsforum.com/t/1424116/what-happened-to-darkchip-4-dlp-products-announces-new-darkchip-4-2007/0_100) years ago but nothing ever showed up under $10K. I guess they've managed to improve the yielding rates and lower their manufacturing costs so they are ready to deliver large quantities for a low price :)

[Mangix]

I can think of one or two examples where anti-aliasing could potentially improve video quality, but chances are that implementing SMAA would not be worth the development time, as post-process AA has a habit of smoothing over sharp areas too. (Though SMAA is considerably better than FXAA or MLAA in this regard)

Wouldn't you be better off using some AviSynth filter or something? doing Anti-Aliasing on a video makes no sense. In games, it makes sense to smooth out the edges since they're generated during rasterization and should be eliminated to make the image more appealing. But video? If you have a properly done video clip, why anti-alias?

[ryrynz]

Because it can at times improve overall quality. I've given it a go in Avisynth and it's quite resource consuming it also wiped out some fine line detail so I ditched it.
When you're dealing with sharpening low quality content anti-aliasing can be a very nice addition to the arsenal.

[schweinsz]

Does the madVR support 3D rendering?

[turbojet]

The main problem with spline144 is ringing, I didn't noticed that much aliasing. It was spline100 whose only difference from avisynth's bicubic (its like Mitchell-Netravali in madvr, no?) is amount of aliasing. Ringing may look like sharpness for live action. But if you somehow remove ringing, spline144 will lose half of its "sharpness". As to your screenshots, I can't really say anything. I watch live action rarely so never tried to learn how to make it look better. But still with such low quality source I don't see much reason to be picky with resize, whatever will do... Especially if you do use separate sharpening. You may consider using more sharpening instead. Probably masked sharpening, because sharping these artifacts even more is a no go.

I misread your post a bit, thought you meant aliasing was the problem with both spline's not just 100. I picked a complicated scene and it was probably a bframe but it was intentional. Complexity for more to discuss, bframe so the artifacts would stand out more. A majority of the aliasing was from bicubic75ar chroma upsampling, switching to lanczos3ar eliminated a lot of it with the rest of the picture looking nearly identical. Almost all eliminated with softcubic100ar but the picture is way too soft. These same artifacts were in the Jinc3 pic as well. Ringing I don't have a problem with spline144 on hd sources, on sd->hd there's some but a lot less then bicubic75/100 or lanczos 3/4. I sharpen pre-resize so resizer artifacts aren't sharpened. Do you know of a resizer that's just as sharp as Finesharp but reduces the edge artifacts?

My experience with other sharpeners is: LSF/LSFMod isn't nearly as sharp and it's inconsistent, a face can go from sharp to blurry just by turning a little, it's better with edge artifacts though. SeeSaw from what I remember years ago was mainly an edge sharpener with quite a few edge artifacts, not nearly as sharp non-edge details as Finesharp. SharpenComplex PS, Unsharp, Xsharp are basically edge sharpeners that when tuned up to finesharp's strength are full of edge artifacts.


I'm not sure. Spline100 looks overly soft to me. Why using 5 taps when the result is so soft? Spline144 looks over-sharpened too me. I don't think either Spline100 nor Spline144 are just higher taps versions of Spline36/64. There's something very different about Spline100 and Spline144, which make me wonder if there's either something wrong, or maybe they're based on a completely different logic.

Thanks for replying, they are based on a different theory. Spline16/36/64 are natural cubic splines explained in this pdf. (http://online.redwoods.cc.ca.us/instruct/darnold/laproj/Fall98/SkyMeg/Proj.PDF) Spline100/144 theory is explained in this doom9 thread. (http://forum.doom9.org/showthread.php?t=147117) You showed interest in the theory in 2009 before 100/144 dll was published, the coeffecients including 256 are there as well. Might you renew your interest in them at some point? Splineresize I can't find documentation on what it really is, but my guess is based on natural splines (spline16/36/64)

Those wishing Jinc was sharper could try that. But those wanting the "natural look" won't be happy with Spline100/144.

The 'natural look' excludes Jinc in that post, which resizer do you think is more natural in that case?

My thoughts are all the bicubic variations blur non-edges a sharpens or blurs it's edges, not very natural to me, it also has a tendency to smear grain quite a bit but it's the only MadVR PS resizer I can use with BD's. Spline36/64 is a bit blurry and has some inaccuracy problems, I notice blocks in faces that shouldn't be there, even on fairly clean sources, and a bit of grain smear. Lanczos3/4/8 handle grain fairly well but with a ton of ringing (AR helps) and grainy faces have a bunch of dots on them (even with AR) which is really ugly and unnatural. Nearest neighbor and bilinear don't really require discussion do they? Some avisynth compare() of the resizers might be required to show which best represents the source. Better to go up/down 16,9px or is large up/down a more realistic test?

[Mangix]

Does the madVR support 3D rendering?

not at the moment

[madshi]

Thanks for replying, they are based on a different theory. Spline16/36/64 are natural cubic splines explained in this pdf. (http://online.redwoods.cc.ca.us/instruct/darnold/laproj/Fall98/SkyMeg/Proj.PDF) Spline100/144 theory is explained in this doom9 thread. (http://forum.doom9.org/showthread.php?t=147117) You showed interest in the theory in 2009 before 100/144 dll was published, the coeffecients including 256 are there as well. Might you renew your interest in them at some point?
Maybe, but not now.

Yes, of course.

madvr - log 2012-11-20 PotPlayer (http://bayfiles.com/file/sLhz/2l5GE4/madVR_-_log_2012-11-20_PotPlayer.rar)
Alternative Download Link (http://www.freefilehosting.net/madvr-log2012-11-20potplayer)

Thanks!!
The reason for the delay is that PotPlayer is asking madVR to redraw the current video frame over and over again. PotPlayer does that so that it can draw animated GUIs. The only way for madVR to handle this is to drop all rendered frames and render them again. So basically while playback is paused with PotPlayer, the madVR rendering queues stay empty. MPC-HC does not draw animated GUIs and doesn't ask madVR to rerender the same frame all the time, so the madVR rendering queues can stay full with MPC-HC. So when you resume playback, with MPC-HC all queues are already full and playback can resume immediately. But with PotPlayer, the queues are empty and must be filled before playback can resume (since you asked madVR to delay playback start until all queues are full).

The 'natural look' excludes Jinc in that post, which resizer do you think is more natural in that case?
I think no other resizer is as "natural" looking as Jinc. Of course a lot depends on the source material and the scaling factors.

Some avisynth compare() of the resizers might be required to show which best represents the source. Better to go up/down 16,9px or is large up/down a more realistic test?
A long time ago I compared different resizers by doing 400% upscale, then 400% downscale, and the only algorithm where the final downscale looked almost identical to the original source was Lanczos.

Does the madVR support 3D rendering?
Not yet, but I plan to work on this soon.

[madshi]

Today's date is 21.11.12, and we've reached page 777. I think this is a good time to announce the first madVR version which has no significant limitations compared to VMR/EVR, anymore. So here we go:

http://forum.madshi.net/images/smilies/icon_redBalloon.gifhttp://forum.madshi.net/images/smilies/icon_greenBalloon.gifhttp://forum.madshi.net/images/smilies/icon_blueBalloon.gif

madVR v0.85.0 released

http://madshi.net/madVR.zip

* added support for external DXVA2 decoders
* added support for DXVA2 scaling
* added support for custom pixel shaders (pre- and post-scaling)
* added support for media player color controls (IVMRMixerControl9)
* added support for "IQualProp" interface for media player statistics display
* added (crappy) support for high-bitdepth, 4:2:2 and 4:4:4 DXVA2 deinterlacing
* changed default scaling settings
The list of changes appears to be small, but the changes are quite important. Let me add some comments:

(1) External DXVA2 decoders should now work just fine in native mode without needing "copyback". This should improve performance, especially for ATI/AMD users.

(2) DXVA2 scaling uses the GPU hardware/drivers to do image scaling. Scaling is done from NV12 -> NV12, so the GPU has to scale both luma and chroma, but madVR still has to upscale chroma to full resolution afterwards. Unfortunately most GPUs don't support YCbCr 4:4:4 output, so I can't do it any other way. Ok, I could let the GPU convert to 8bit RGB, but we really don't want that because then the GPU does the color conversion, in low bitdepth, without dithering.

Since scaling is done by the GPU hardware/drivers, scaling quality will differ depending on the GPU hardware/drivers. Also I've been told (not sure if it's true) that Intel has dedicated hardware circuits to do the scaling while NVidia and AMD are using pixel shaders instead. So it's possible that the performance benefit on Intel hardware might be bigger than on NVidia/AMD hardware. Please test this and let me know the quality of the scaling algorithms, and the performance compared to madVR scaling algorithms with your GPU. Please also note that the video settings in the GPU control panel may very well affect DXVA2 scaling results.

(3) Custom pixel shaders in MPC-HC should work just fine now with madVR. However, a new MPC-HC build will be necessary. I'll make the necessary changes available to the MPC-HC devs later today. For now I've uploaded a custom MPC-HC build here, so you can start playing with it:

http://madshi.net/mpc-hc.zip

Please note that madVR always runs custom pixel shaders in R'G'B' with black at 16.0/255.0 and white at 235.0/255.0. I'm not sure how EVR/VMR runs custom pixel shaders. Maybe I'll need to adjust this to match EVR/VMR, we'll have to wait and see.

(4) madVR now supports media player color controls (brightness, contrast, saturation and hue). Currently you can't adjust these settings inside of madVR, the media player has to do that, by using the official IVMRMixerControl9 interface.

For brightness and contrast, I'm not using the usual algorithms. The standard GPU brightness control adds a fixed value to every RGB channel, so it increases both the black and white levels by the same amount. The standard GPU contrast control stretches the data, so white and black levels move away from (or nearer to) each other. While these standard GPU controls appear somewhat intuitive, using them means that brightness and contrast fight with each other. When setting up your display, you have to change both all the time and go back and forth.

The madVR brightness control only modifies the white level, but keeps the black level identical. The madVR contrast control only modified the black level, but keeps the white level identical. The name "brightness" somewhat fits to what madVR does, but the "contrast" name doesn't really fit well. It's more like "blackness" or "black level". I decided to implement it this way because I think it makes setting up the displays easier. But this is open for discussion: If you don't like madVR's brightness/contrast behaviour, let me know, maybe we can find a better solution together.

The madVR saturation and hue settings work as usual, however I'm performing the modifications in linear light (which is the only correct way to do saturation/hue adjustments), while the other renderers and GPU drivers usually adjust these things in gamma corrected light.

(5) DXVA2 deinterlacing (and DXVA2 scaling, too) now works with all YCbCr formats which madVR supports, regardless of bitdepth and chroma format. *However*, since all GPUs perform the best deinterlacing only with NV12, madVR automatically converts all YCbCr formats down to NV12, when doing DXVA2 deinterlacing. And madVR does not contain high-quality downconversion routines for this yet. It's a simple round down at the moment. This might be improved in a (far away) future build. For now you might get slightly better quality by letting LAV Video Decoder downconvert to NV12. IIRC nevcairiel has implement some nice downconversion routines with dithering etc...

(6) When using any DXVA2 related functionality with madVR, there's a small blur added to the chroma channel, when using NVidia or Intel hardware. This does not happen with AMD hardware. Currently I've no way to fix this. But it has always been this way and nobody complained until now, so it doesn't seem to be much of a problem. I have it on my to do list to fix this, but it will require a new CUDA version from NVidia and I'll need Sandy Bridge hardware (which I currently don't have) to test a possible fix for Intel.

(7) The new default scaling settings are Lanczos3 AR for image upscaling, Catmull-Rom AR with Linear Light for downscaling and Bilinear for Chroma. I've selected these algorithms with an eye on performance, as well as quality. If your GPU is fast enough, you definitely want to use something better than Bilinear, but for users with slow GPUs the best quality compromise IMHO is to use Bilinear chroma upsampling. Just my personal opinion, of course, and everybody please feel free to disagree. For really fast GPUs my recommended settings now would be Jinc3 AR for both chroma and image upscaling and Catmull-Rom AR with Linear Light for image downscaling.

Since many of these features are brand new, please expect a couple new bugs. I haven't tested especially DXVA2 decoding and scaling too much yet, so me might have to do some polishing before everything works perfectly.

Oh yes, and before anybody asks why this isn't v1.0 yet: While madVR now has no major limitations compared to VMR/EVR, anymore, I still don't consider it feature-complete. There's still a list of things I want to add. Afterwards there'll be a period of tweaking and polishing. Then some kind of manual. And then maybe it's time for v1.0. But that's still some time away...

[leeperry]

w00t, :thanks: for the new build!

oh, PS script need to be invoked from within the media player, gonna have to whine to the coder of PotP this time(PS: email sent ^^) :D

PS scripts work in 0-255 in MPC AFAIK, but I might have misunderstood what you wrote.

[SamuriHL]

WOW, madshi. Very impressive!!!

[crotecun]

Thanks, madshi! Testing both the new madVR build and the custom mpc-hc build.

[wanezhiling]

Oh god... Great!!!!!!! :D:D:D

[Octo-puss]

wow, just wow

[AndreaMG]

today's date is 21.11.12, and we've reached page 777. I think this is a good time to announce the first madvr version which has no significant limitations compared to vmr/evr, anymore. So here we go:

http://forum.madshi.net/images/smilies/icon_redballoon.gifhttp://forum.madshi.net/images/smilies/icon_greenballoon.gifhttp://forum.madshi.net/images/smilies/icon_blueballoon.gif

madvr v0.85.0 released

Thank you!!!!!!!!!!!!!:D

[madshi]

PS script work in 0-255 in MPC AFAIK
That's what I thought, too, but after talking to Jan-Willem about it, I'm not so sure, anymore. He's saying that scripts do work in 0-255 when using 8bit textures, but in that case BTB and WTW are clipped. He says when using higher quality textures, the shaders run in 16-235 instead, but in XYZ color space. I'm not sure yet if I understood him correctly, though. Still waiting for confirmation. I think there should be an official spec for which colorspace and levels custom shaders run in. Maybe we'll have to create that spec, if it doesn't exist yet.

[leeperry]

OK, fair enough! I guess we'll have to see how the scripts written for VRM9/EVR will behave. This said, talking about writing a new spec, allowing access to N-1 frames would allow all kinds of temporal processing and most likely attract a new coders community that gave up on PS scripts because they wouldn't allow any kind of frames interpolation scripts for instance. I've got no idea how difficult this would be technically speaking, though :o

[madshi]

I'm currently focused on delivering all important stuff with the minimum of needed features. Adding access to N-1 frames would not be compatible to the MPC-HC shader editor, so I'd have to write my own shader editor and that would cost a lot of time. In the same way some other features are rather limited right now, too. E.g. screenshots, refresh rate changer etc could all be better than they are now. But they work, and there are still some things missing, so the missing things are more important now. In the same way I first wanted to make shaders work the same way they work in VMR/EVR because doing that didn't cost too much time. Adding new features to all this stuff might happen some time in the future, but now's not the time for that. Or let me say it in different words: If I had implemented a much more extensive shader solution with access to N-1 frames etc, you would have had to wait a month or 2 more for v0.85.0 to appear, furthermore you'd not have DXVA2 decoding and scaling support at all.

[TheLion]

Thank you so much for the update!

I tried it with MC18, Win8 on a ATI 5870 board. After updating madVR the image is "washed out"/elevated black level. What sounds like a beginners user error turns out to be not fixable by 16/325 0/255 options in madVR as well as limited or full RGB in Catalyst driver. It is also completely independed from the used decoder and options in the decoder.

Downgrading to the previous madVR as well as using EVR is the only way to fix it atm. Very strange indeed.

[ajp_anton]

The list of changes appears to be small, but the changes are quite important.No kidding! And finally madVR is competitive on long flights where battery life ("DXVA native") is important.
Thanks!

[Razoola]

Would I be right in thinking any MPC-HC build later than 1.6.5.6205 will work correctly with madvr 085?

[Xaurus]

Thanks madshi!

[madshi]

I tried it with MC18, Win8 on a ATI 5870 board. After updating madVR the image is "washed out"/elevated black level. What sounds like a beginners user error turns out to be not fixable by 16/325 0/255 options in madVR as well as limited or full RGB in Catalyst driver. It is also completely independed from the used decoder and options in the decoder.
So it happens with software decoding, too? Please make sure you have all DXVA2 related stuff turned off. That means: Decoding, Deinterlacing and Scaling. Does that fix the problem?

[madshi]

Would I be right in thinking any MPC-HC build later than 1.6.5.6205 will work correctly with madvr 085?
Not sure what you mean. What is so special about build 6205?