madVR - high quality video renderer (GPU assisted)

[Prinz]

Originally Posted by madshi

So you get drops with bilinear but not with more demanding scalers? That's weird...

That would be weird. I have to set all to bilinear, all higher algos bring frame drops sometimes.

[madshi]

Ah ok, had misunderstood you.

[ryrynz]

Madshi, using native DXVA2 and having a high CPU queue causes freezes and a few second delay when opening a file. Upon seeking I have MPC freeze when the queue is set around 16 or higher, the higher the queue the easier it is to freeze one or two seeks with the CPU queue at 32 will do it, at 15 it's fairly hard to freeze. HD4000 2875 driver on Win7x64 latest MPC/BE.

[TheLion]

My thoughts regarding defaults scalers:

As long as DXVA scaling isn't 100% stable and predictable I would vote for Catmull-Rom for all scaling as default. Bilinear defeats the purpose of using a high quality renderer. And the more elaborate algorithms may be too demanding for "casual hardware". I think Catmull-Rom (+ AR?) is the sweetspot here.

[leeperry]

Originally Posted by madshi

the levels custom shaders run in are still under discussion. So it really doesn't make much sense to discuss it here in the forum now.

Alright, fair enough! Thanks for the detailed explanation and it might have to do with the known issue that those pesky m$ renderers seem to output 16-235 when fed anything else than RGB32. This has been a well known issue with VMR9 IIRC, and I think that PS script support in MPC was here before EVR as well.....so maybe it inherited some legacy (broken) code.

Casimir666 told me that PS scripts were processed in 32fp in his EVR CP builds FWIW. Anyway, it all goes quite a bit above my head and I was only hoping that the gamut mapping PS script that was proven to work as it currently implemented in MPC could work equally well in mVR....but I'm sure you'll work it out



PS: OTOH, the coder of PotP doesn't really understand english so if it also requires a fix, that'll most likely be a dead-end.

[Prinz]

Originally Posted by ryrynz

Madshi, using native DXVA2 and having a high CPU queue causes freezes and a few second delay when opening a file. Upon seeking I have MPC freeze when the queue is set around 16 or higher, the higher the queue the easier it is to freeze one or two seeks with the CPU queue at 32 will do it, at 15 it's fairly hard to freeze. HD4000 2875 driver on Win7x64 latest MPC/BE.

I think my problem is related with this. If I change the cpu query to 4 the audio starts (video is still black). And some more files work...

[madshi]

Originally Posted by ryrynz

Madshi, using native DXVA2 and having a high CPU queue causes freezes and a few second delay when opening a file. Upon seeking I have MPC freeze when the queue is set around 16 or higher, the higher the queue the easier it is to freeze one or two seeks with the CPU queue at 32 will do it, at 15 it's fairly hard to freeze. HD4000 2875 driver on Win7x64 latest MPC/BE.

With which decoder? LAV Video Decoder has 2 small bugs in it, one of which might be related to this. nevcairiel already mentioned that he plans to release a new build soon.

Originally Posted by TheLion

My thoughts regarding defaults scalers:

As long as DXVA scaling isn't 100% stable and predictable I would vote for Catmull-Rom for all scaling as default. Bilinear defeats the purpose of using a high quality renderer. And the more elaborate algorithms may be too demanding for "casual hardware". I think Catmull-Rom (+ AR?) is the sweetspot here.

How about Lanczos3 for upscaling, Catmull-Rom for downscaling and Bilinear for chroma? All without AR and without linear light. That should be fast enough for most (but not all) GPUs.

Originally Posted by leeperry

Casimir666 told me that PS scripts were processed in 32fp in his EVR CP builds FWIW.

The processing itself is running in 32bit+ floating point per component. That's the native bitdepth of D3D9 pixel shaders. However, the results of every pixel shader pass need to be stored in a temp buffer, and this temp buffer appears to be integer and not floating point by default, when using EVR-CP. Which results in BTB and WTW being cut off, when having black at 0 and white at 255.

Originally Posted by leeperry

the coder of PotP doesn't really understand english so if it also requires a fix, that'll most likely be a dead-end.

I've been in email contact with him for a while and there don't seem to be any major language problems, as far as I can say.

[ajp_anton]

Originally Posted by madshi

Which "target rectangle" does the madVR debug OSD (Ctrl+J) show when the green line shows up? Does the green line appear no matter which zoom factor you're using? Does it occur with every video, or just with some? Tnx.

Investigated further now that I'm awake =).

It seems to happen with an odd number of vertical pixels.
MPC-HC's auto-zoom: 0,0,1462,801
Fullscreen: 0,0,2560,1421

Yes, it seems to happen with every video, but this was the only one I found yesterday that showed an odd number of pixels "by default".
If I manually resize the window vertically, the green line will switch on and off for every pixel.

[toniash]

Originally Posted by madshi

I've been in email contact with him for a while and there don't seem to be any major language problems, as far as I can say.

Can you tell him what he needs to do in order to support PS with MadVR? Thanks a lot!

[madshi]

Originally Posted by ajp_anton

Investigated further now that I'm awake =).

It seems to happen with an odd number of vertical pixels.
MPC-HC's auto-zoom: 0,0,1462,801
Fullscreen: 0,0,2560,1421

Yes, it seems to happen with every video, but this was the only one I found yesterday that showed an odd number of pixels "by default".
If I manually resize the window vertically, the green line will switch on and off for every pixel.

Ah thanks, that kinda makes sense.

Originally Posted by toniash

Can you tell him what he needs to do in order to support PS with MadVR? Thanks a lot!

I don't need to, he already has it working.

[egur]

I performed a few tests on my system:
Windows 7 sp1 x64.
Intel HD2000 (i7-2600) (15.26.64.2879)
AMD Radeon HD 6950 (12.10)

Used ffdshow as decoder. LAV doesn't work for me with MadVR under ZoomPlayer in DVD mode.

Used an old test DVD displaying the standard SMPTE bars.
All tests were run with DXVA scaling in MadVR. Made sure all video processing on both AMD and Intel were off.

EVR(AMD): OK
MadVR (AMD): OK
EVR (Intel): OK
MadVR (Intel): Greens and yellow were slightly darker (luma lower by 2 levels). The rest of the primaries and secondaries as well as grays (black, greys and white) were OK.

I didn't notice any image shift between 4 tests. It seems that EVR (intel) and MadVR (Intel) use slightly different scalers (chroma only). This might be due to the fact that the content was interlaced.

[Prinz]

Originally Posted by egur

LAV doesn't work for me with MadVR under ZoomPlayer in DVD mode.

Known profil error. Change the LAV Video Decoder.videodecoder from:

DefineFilter(LAVVideo.ax)
VideoDecoder(Name=LAV Video Decoder,CLSID={EE30215D-164F-4A92-A4EB-9D4C13390F9F},VidInPin=Input,SubInPin=Subtitle Input,VidOutPin=Output,CCOutPin=None)

to:

DefineFilter(LAVVideo.ax)
VideoDecoder(Name=LAV Video Decoder,CLSID={EE30215D-164F-4A92-A4EB-9D4C13390F9F},VidInPin=Input,SubInPin=Subtitle Input,VidOutPin=Out,CCOutPin=None)

[egur]

Originally Posted by Prinz

Known profil error. Change the LAV Video Decoder.videodecoder

Thanks!

[madshi]

Originally Posted by egur

I performed a few tests on my system:
Windows 7 sp1 x64.
Intel HD2000 (i7-2600) (15.26.64.2879)
AMD Radeon HD 6950 (12.10)

Used ffdshow as decoder. LAV doesn't work for me with MadVR under ZoomPlayer in DVD mode.

Used an old test DVD displaying the standard SMPTE bars.
All tests were run with DXVA scaling in MadVR. Made sure all video processing on both AMD and Intel were off.

EVR(AMD): OK
MadVR (AMD): OK
EVR (Intel): OK
MadVR (Intel): Greens and yellow were slightly darker (luma lower by 2 levels). The rest of the primaries and secondaries as well as grays (black, greys and white) were OK.

I didn't notice any image shift between 4 tests. It seems that EVR (intel) and MadVR (Intel) use slightly different scalers (chroma only). This might be due to the fact that the content was interlaced.

The key problem I'm currently facing is that DXVA2 outputs its NV12 results in IDirect3DSurface9 and I can't directly access that in my HLSL PixelShader rendering pipeline. I have a complicated conversion routine implemented which tries to make the NV12 surfaces available to my pipeline without too much conversion loss, but it's difficult to do this on the GPU. With ATI it works well, with NVidia and Intel not so much. I think that this is probably the cause of the brightness difference you're noticed. Of course madVR also uses its own chroma upsampling algorithm, that's why chroma looks different. But with chroma the same conversion problem described above also applies. I'm considering using some kind of copy-back as a temp workaround until I find a better solution. The long term solution will probably be to use OpenCL for Intel and CUDA for NVidia to perform the conversion without loss. But that's not easy to develop, so it will take some time. Also I don't have Ivy Bridge hardware, so I can't test OpenCL at the moment. OpenCL is unfortunately not available for Sandy Bridge.

[mindbomb]

with regards to scaling defaults, I was happy with the old lanczos and softcubic.
I liked that the quality was pretty high out of the box.

also, using the minimum cpu queue fixed my crash on seeking problem with dxva. lav filters, dxva scaling, bilinear chroma, cat 12.8 radeon 6310

[DragonQ]

Madshi, I'll do those colour tests later tonight for you.

It'll be interesting seeing the difference between, say, Jinc3 and DXVA2 luma scaling, once the differences in cropping and colours are fixed. I bet I won't notice any difference, lol. Might depend on the GPU though - I imagine my GT 430 has better scaling than my GTS 250, especially since its deinterlacing algorithm is better.

[ajp2k11]

Originally Posted by ajp2k11

The windowed backbuffer setting is already at it's default 3? I switched to fullscreen because I wanted that logged too, didn't work either. It seems some files are harder to get to play than others, the one I'm testing with now seems impossible... others work after a while if I leave it alone or switch between windowed and fullscreen a couple of times, at least I think so...

EDIT: Some files play ok but some files just refuse to play...? They play fine using EVR/CP + LAV...

Madshi,

any idea why some files work while others don't? They are normal 720p mkv files. Never had this problems on Win7, noticed it after installing a fresh copy of Win8... the screen just goes black and the audio plays then after a while even the audio cuts out too I think...

[6233638]

Originally Posted by madshi

Originally I was planning to use DXVA2 scaling as the new default option, because that should (hopefully) run smooth on even rather slow GPUs. But then with the original v0.85.0 DXVA2 scaling wasn't working well at all, so I decided to use different defaults. But now with v0.85.1 DXVA2 scaling seems to work fairly well and it seems that the scaling algorithms offered by Intel especially, but maybe also by ATI and NVidia might be acceptable as a default option for budget GPUs. What do you think? I would really like the first impression of new users to be positive. It can't be positive if the first impression is that madVR produces a slide-show. So maybe using DXVA2 scaling as default option might be a good idea?

If you can fix the colour decoding issues with DXVA2 scaling, this might be best, even though DXVA doesn't look that great in my limited testing. (it appeared to have a lot of ringing, though I have edge enhancement set to 0 in the Nvidia control panel)

Originally Posted by madshi

Can you guys please test the following:

(1) Use software decoding and e.g. Bilinear scaling.
(2) Use native DXVA2 decoding and e.g. Bilinear scaling.
(3) Use software decoding and DXVA2 scaling.
(4) Use native DXVA2 decoding and DXVA2 scaling.

On my system with Nvidia, DXVA2 scaling is resulting in the wrong colours. DXVA native decoding is fine, when compared to software decoding.

It looks like it could be a colour matrix issue. (switching matrix in madVR doesn't fix it)
It appears to be using the BT.709 matrix on BT.601 content once it's scaled over a certain size.

Just below the threshold.
Just over the threshold.


Now that I know it's working correctly, I also ended up using the new saturation control last night, and it seems to do a good job.

While I am generally in the "watch the film as accurately as possible" group, there are some films where I wonder what kind of display they were mastered on, because colour looks dead and lifeless. (they tend to be shot on digital, often Red) A slight bump in saturation seems to help.

Before, After

[crotecun]

Originally Posted by kasper93

@crotecun:
Using old Microsoft drivers is just wrong :< And you don't need to uninstall CCC in order to disable video enhance features. Just disable everything and turn off demo mode, and that's all.

If you compare the screenshots I posted, there is still some difference between the 'unaltered' video with CCC installed and the video when CCC is absent and only the drivers from microsoft update are installed. It seems even when everything is disabled in CCC some unwanted video post-processing still occur.

[leeperry]

Originally Posted by madshi

The processing itself is running in 32bit+ floating point per component. That's the native bitdepth of D3D9 pixel shaders. However, the results of every pixel shader pass need to be stored in a temp buffer, and this temp buffer appears to be integer and not floating point by default, when using EVR-CP. Which results in BTB and WTW being cut off, when having black at 0 and white at 255.

Well, I understood from Casimir666 that they were processed in 32fp onto an RGB surface...anyway, it's already giving me a headache and FWIU you said that there is no BTB or WTW in 0-255 RGB so if the PS script was set to be used "after scaling" you could feed 0-255 RGB32 at the very last stage to the damn thing and we should end up with the very same colors as in VMR9/EVR?

Anyway, you'll work it out and I'll wait patiently this time...no more questions on this matter, promised!

I'm currentlly pretty bored, eagerly awaiting the darn BenQ pj to be released(1 or 2 weeks to go) so I can calibrate its primaries and secondaries to Rec.709 and come back with HCFR measurements of mVR's gamut mapping..hopefully that'll give me 0% drifting spot-on saturations in HCFR too, I've never had a display with a serious CMS....I think a 12bit ISF xyY CMS should be as good as it gets as these ppl actually ask $1K for a calibration, so that should rock hard

Originally Posted by madshi

I've been in email contact with him for a while and there don't seem to be any major language problems, as far as I can say.

Great! Well, it seems that there are several coders on the PotP project and some of them would command english better than others.

I recently asked if they could get the D3D GUI of PotP to work with mVR, the replied "D3D UI cannot work with madVR".....it seems to be working with EVR(and possibly VMR9, not sure), so why not mVR? That'd be pretty darn cool if the transport bar didn't constantly break FSE