madVR - high quality video renderer (GPU assisted)

[Prinz]

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]

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 :)

:thanks:

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]

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]

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.

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.

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.

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]

Green line at the top of the screen when using DXVA scaling and any kind of decoding, including madVR's own.

http://ajpanton.se/sample.mkv

Win7 x64, MPC-HC 6240, Intel HD3000.

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]

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]

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.

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]

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]

Known profil error. Change the LAV Video Decoder.videodecoder

Thanks!

[madshi]

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]

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 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)

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. (http://www.abload.de/img/1rko10.jpg)
Just over the threshold. (http://www.abload.de/img/2lopbw.jpg)


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 (http://www.abload.de/img/withoutalql1.jpg), After (http://www.abload.de/img/with0urid.jpg)

[crotecun]

@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]

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! :D

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 :)

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 :cool:

[egur]

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.
Can you specify what the problem is?

[TheShadowRunner]

All of that talks about how to write a DXVA1 decoder, not a renderer. (..) It's not documented anywhere how VMR passes the DXVA1 bitstream packets to the GPU for decoding, so I don't know how to do that.
Ahhh OK, I get it.
I guess how Overlay passes DXVA1 bitstream packets to the GPU isn't documented either?

Anyway, DXVA decoding on XP is problematic, anyway. It's always been very unstable (blue screens etc) on my XP PC. And there's a fundamental problem when resizing the window, too. Resizing the window results in madVR trying to reset the D3D9 device, but in XP that is only possible if all GPU resources are destroyed first. That makes things very very complicated when using external DXVA decoders, because they hold some GPU resources, as well.
Hmm when I resize the ZoomPlayer window, or the video surface using the zoom function when playing back MPEG2 contents using Cyberlink decoder in DXVA mode, with any of the compatible renderers (overlay, VMR7/9), there is no issue whatsoever compared to sofware decode..
I never had a BSOD when DXVA decoding (mpeg2) either ^^;

Even if suddenly documentation for writing a DXVA1 renderer showed up, I'd probably not support it for XP because of the D3D9 device reset problem.
Damn.. guess DVD DXVA decode + perfect madVR vsync won't ever happen then :/

FWIW, I fully support DXVA2 deinterlacing and scaling on XP and it works very stable for me.
Wait.. what? Typo? XD

[nevcairiel]

Damn.. guess DVD DXVA decode + perfect madVR vsync won't ever happen then :/


CUVID in LAV is the only accelerated decoding thats available for madVR on XP.
I've also heard rumors of some people actually getting DXVA2 Decoding to work on XP, not sure if there is truth in that.

[JarrettH]

What does the change log mean by external DXVA2 decoders? Hasn't LAV always had DXVA2 decoding or did it not work properly until now?

[TheShadowRunner]

CUVID in LAV is the only accelerated decoding thats available for madVR on XP.
Yes Nev, but no equivalent of DXVA's Pixel Adaptive deinterlacing when going the CUVID way, right?


I've also heard rumors of some people actually getting DXVA2 Decoding to work on XP, not sure if there is truth in that.
Interestingu.. ^^;

[nevcairiel]

Yes Nev, but no equivalent of DXVA's Pixel Adaptive deinterlacing when going the CUVID way, right?

Deinterlacing is independent of decoding. If you can get DXVA Deinterlacing to work in madVR (it should work according to madshi), then you can also use software decoding if you want.

[madshi]

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.
Whether there's a big difference or not depends a lot on the source material and the scaling factor.

any idea why some files work while others don't?
No. The log clearly says that madVR is not receiving VSync scanline information. I don't know why madVR would receive them for some videos but not for others. In any case, I don't think there's anything I can do about it... :(

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.
Interesting! Could you make that test video available to me, please?

FWIW, I'm asking DXVA2 to scale NV12 -> NV12, so I'm wondering why NVidia thinks it should do a matrix change!

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 (http://www.abload.de/img/withoutalql1.jpg), After (http://www.abload.de/img/with0urid.jpg)
Yeah, "After" definitely looks better...

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?
What do I know? Ask them!

Ahhh OK, I get it.
I guess how Overlay passes DXVA1 bitstream packets to the GPU isn't documented either?
Correct.

Damn.. guess DVD DXVA decode + perfect madVR vsync won't ever happen then :/
Of course it will. Just update to win7.

Wait.. what? Typo? XD
Typo? Why? DXVA2 deinterlacing and scaling is supported on XP, just not DXVA2 decoding.

What does the change log mean by external DXVA2 decoders? Hasn't LAV always had DXVA2 decoding or did it not work properly until now?
It was working, but only when using "copy-back", not "native" mode. And all the other DXVA2 decoders didn't work at all with madVR cause they don't have a "copy-back" mode. With the new madVR build now LAV works in native mode, too, and all the other DXVA decoders should now work, too (at least in theory).

Can you specify what the problem is?
Sure. When rendering with D3D9, the usual way to do things is to first call IDirect3DDevice9::BeginScene(), then you initialize the texture samplers by calling IDirect3DDevice9::SetTexture(), then you do some other stuff and finally you call IDirect3DDevice9::EndScene().

Now the first problem is: IDirect3DDevice9::SetTexture() wants a texture. It doesn't accept a surface. So I can't use the NV12 surface I got from DXVA2 here. Which means I need to convert the DXVA2 surface to a texture somehow. And here comes the next problem: Textures don't support NV12. So I can't just create an NV12 texture and copy the surface to the texture. Simply not possible. I could try to create a YUY2 or UYVY texture, which the GPU might (or might not) support. But YUY2 and UYVY are 4:2:2, so if I copy the NV12 surface to the YCbCr texture, the GPU driver already has to upsample chroma from 4:2:0 to 4:2:2 somehow and I have no control over how that is done. But the problems don't end here. If I use IDirect3DDevice9::SetTexture() with any kind of YCbCr texture, my pixel shaders (which do all the work) will never see the true YCbCr data. Instead Direct3D will convert the YCbCr data into RGB behind my back. So again chroma upsampling is done from 4:2:2 to 4:4:4 behind my back, and on top also YCbCr -> RGB conversion with an unknown color matrix.

What I really want is to be able to access the original YCbCr data in my pixel shaders. But there's no clean way to do this. When using software decoding, madVR stores the original YCbCr data into an RGB texture. The GPU doesn't know it's actually YCbCr data, only madVR knows that. So I can process the data without someone converting the hell out of the data behind my back. Unfortunately this only works by using the CPU to force the NV12 data into an RGB texture. DXVA2 stores its results in GPU RAM, so if I want to use the CPU to force the NV12 data untouched into an RGB texture, I have to use "copy-back" which is bad for performance.

I believe I can solve this with Intel by using OpenCL, and with NVidia by using CUDA. I don't see any other solution. If the Intel drivers have a secret "SplitNv12SurfaceToRgbTextureWithoutTouchingTheData" API then please let me know... :D

[madshi]

Deinterlacing is independent of decoding. If you can get DXVA Deinterlacing to work in madVR (it should work according to madshi), then you can also use software decoding if you want.
Yes, DXVA2 deinterlacing and scaling in highest supported GPU quality works perfectly fine in XP. Stable and (relatively) good quality. At least with my AMD 3850 and 7770 cards.

(You have to install .NET 3.0 or higher to get DXVA2 working on XP at all.)

[6233638]

Interesting! Could you make that test video available to me, please?

FWIW, I'm asking DXVA2 to scale NV12 -> NV12, so I'm wondering why NVidia thinks it should do a matrix change!http://www.datafilehost.com/download-4fdb9a1d.html

[mbordas]

I believe I can solve this with Intel by using OpenCL, and with NVidia by using CUDA.


Don't the latest nvidia drivers support OpenCL? So you could add support for both with one implementation?

[madshi]

http://www.datafilehost.com/download-4fdb9a1d.html
Thanks. This is really bad. I've changed my code to explicitely tell DXVA2 that source and destination matrix/gamut/transfer/levels are identical, but still NVidia insists on switching matrix, depending on resolution. Not sure if there's any way for me to work around this. Fortunately this doesn't seem to happen with AMD. Not tested with Intel yet.

Don't the latest nvidia drivers support OpenCL? So you could add support for both with one implementation?
NVidia supports OpenCL, but only an outdated version which doesn't support the features I need. That said, the current CUDA version doesn't support what I need, either (bug report posted to NVidia a couple of weeks ago). <sigh>

[leeperry]

What do I know? Ask them
I couldn't get any further detail apart from some broken english repeating me that "it cannot work". You provided details on how to not break FSE in the mVR distribution files IIRC and you said that you were in contact wih them so I thought that you could raise the subject someday, nothing more. If it doesn't break the D3D exclusive mode of EVR, it should be possible to do the same with mVR :o

[tetsuo55]

I've also heard rumors of some people actually getting DXVA2 Decoding to work on XP, not sure if there is truth in that.
Depending on hardware and driver versions you can get DXVA2 in XP
However it is usually limited to only one of the codecs. In my case my hd 4770 only had VC1 DXVA2 on XP.

There is no real technical limit afaik, it is just that the drivers don´t support the capability. Rumors back then where that this was on purpose to push vista.

[JarrettH]

Keep meaning to tell you, but since 0.85 MPC acts as if the window is always on top. I have to click minimize to get it out of the way. Is there a way to change this behaviour?

[ajp2k11]

No. The log clearly says that madVR is not receiving VSync scanline information. I don't know why madVR would receive them for some videos but not for others. In any case, I don't think there's anything I can do about it... :(


It seems to manifest mostly with 1080p files, although some work. Especially fullscreen 16/9 1080p seems hard. Very weird, didn't have any problems at all with Win7. any suggestions where I should start looking? I'm desperate... :scared:

Anybody? :o

[rahzel]

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.
AMD rig:

Every time native DXVA2 decoding is on, colors look different from reference (2 and 4). Colors / gamma, everything look the same between 1 and 3, and 2 and 4. As far as I can tell, DXVA2 scaling looks similar to Bilinear scaling. (edit: nm, no scaling was done, video was 1920x1080 on a 1080p display)

Driver: 12.10 with AMD Vision CP installed
GPU: MSI Radeon 5570
OS: Win 7 64-bit

----------------------------------------

Intel Rig:

This one was a bit more interesting. My AMD rig is connected to a 1080p display. I took my screenshots using a 1920x1080 video so no scaling was ever done. The color differences were caused by the software vs DXVA2 decoding.

My Intel rig is connected to a 32" 1360x768 native LCD TV but supports up to 1080p. At first I took all of my screenshots at my display's native resolution (1360x768) and every screenshot (2, 3 and 4) had different colors than the reference #1 shot. I thought that was odd since my AMD rig, only the screenshots using DXVA2 decoding had different colors. Because DXVA2 scaling takes screenshots in its display/scaled resolution and madVR's bilinear scaling took the screenshot in its native resolution, I thought that maybe the DXVA2 scaling caused the differences in color. So I then switched my display to 1080p and took screenshots, so no scaling was done. Sure enough, just like my AMD rig, 1 and 3 looked the same and 2 and 4 looked the same.

Something else I noticed that on my Intel rig, when I used DXVA2 scaling, I saw a green bar at the top.

Driver: 9.17.10.2867
GPU: Intel HD 4000
OS: Win 7 64-bit

FWIW, because you have to right-click to take a screenshot, every screenshot wasn't taken in FSE mode but in full-screen non-exclusive mode.

[crotecun]

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.

The reference is (1) for colors, brightness, contrast and gamma. This is how the image must look. Please check which of (2), (3) and (4) are different from the reference and which are identical. Also please check if maybe (4) is even more different than (2) and (3) are.

(I don't need screenshots.)

Please also list your GPU, your drivers, and your OS.

Thank you!!!



DXVA2 decoding and software decoding has no difference in colors/gamma. Scaling in DXVA2 looks slightly but noticeably sharper/clearer than bilinear scaling.

GPU: Radeon HD 5670
Driver: 11.5 without Catalyst, default driver from MS update
OS: Windows 7 64-bit

[DragonQ]

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.
Can't test 2 & 4 on the material I was testing since it doesn't work with DXVA2 for me (576p/25). 3 has different colours (yellower) to 1, and 3 is also slightly squished horizontally compared to 1 (a few pixels at most).

Using Windows 8, nVidia GTS 250, latest drivers (306.97).

[crotecun]

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.

What counts as "casual hardware" anyway? And with these settings, what types of content could we expect to play smoothly on this hardware?

[turbojet]

Green line at the top here too with intel hd3000. Something that may help track the problem is it's not limited to resizing. If madvr isn't image resizing but dxva resizer is selected the green line shows up when decoding with intel quicksync, switch to another decoder and it disappears. Also happens when resizing no matter what the decoder. MPC also takes about twice as long to start up with madvr 0.85.x as it does with 0.84.x and EVR on intel hd3000, after initial start it's quick again when switching files. With nvidia startup is about the same speed it was with 0.84.x.

DXVA resize is pretty impressive on nvidia 9500GT though, sharp with very few artifacts. Chroma resize is the culprit for most of the artifacts, switching to softcubic100 greatly reduced them but caused other image problems so switched back to lanczos3ar. Is it planned to have dxva available for chroma resizing?

As for defaults, dxva is the 2nd largest load on the 2 gpu's here, so unless it can scale with performance of the gpu it might not be good for preventing slide shows, nor is lanczos really. Any of the bicubic's are about half the load as lanczos but maybe more important then default resizer is gpu queue. While process explorer doesn't show a significant load or ram increase using 8 gpu queues frame drops start around 60% load, while 4 gpu queues starts around 80%. Then there's the problem I had way back when with frozen player with default queues, luckily was able to drop them to 4 after a few minutes and issue disappeared. Is there any advantage to using 8 over 4? Drops frames at a lower load, noticeably slower startup and seeks on lower end hardware are disadvantages. 6/4 queues has never been a problem for me.

[DragonQ]

Is it planned to have dxva available for chroma resizing?
I'm pretty sure DXVA2 chroma resizing is terrible.

[trip_let]

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.


Seems like the colors are the same to me for all four. At first I thought 3-4 had very slightly different colors, but I think it was just the scaling + processing.

DXVA2 scaling looks a lot like bilinear, except it's sharpened. Testing on something very low resolution with white text on black background and upscaling a lot, it definitely looked like a linear interpolation. All in all, something like bicubic75 + AR has greater sharpness, usually less ringing, and less aliasing (a success for madVR, if I dare say). On some material, the DXVA2 scaling shifts the whole image down-right a couple pixels, resulting in a black bar at the edge.

GPU: Mobility Radeon HD 3650
Driver: Catalyst 12.1
OS: Win7 32-bit


Lanczos 3 for default upscaling may have too much ringing on some material without AR turned on, at least in my opinion. I vote for something between Bicubic 50 to 75. It's even easier than Lanczos to handle, anyway.

[nx6]

Heree heree!

Requesting these new color controls added in 0.85 support Gamma adjustment! :D

[6233638]

Requesting these new color controls added in 0.85 support Gamma adjustment! :DThere's already a gamma control in madVR under devices > color & gamma. You can set keyboard shortcuts for it as well.

[nx6]

There's already a gamma control in madVR under devices > color & gamma. You can set keyboard shortcuts for it as well.

Yes, but the adjustment range is a bit more limited than my media player's built-in controls. It seems to expect to need to lower the gamma much more than raise it.

[ajp2k11]

No. The log clearly says that madVR is not receiving VSync scanline information. I don't know why madVR would receive them for some videos but not for others. In any case, I don't think there's anything I can do about it... :(


Madshi,

sorry for pestering you like this but could this have anything to do with the problems I'm having playing certain files? Copy from LAV slpitter pin info trying to play regular 1080p mkv file (h264).

Filter : LAV Splitter Source - CLSID : {B98D13E7-55DB-4385-A33D-09FD1BA26338}

- Connected to:

CLSID: {EE30215D-164F-4A92-A4EB-9D4C13390F9F}
Filter: LAV Video Decoder
Pin: Input

- Connection media type:

Video: MPEG4 Video (H264) 1920x1080 23.976fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: Unknown GUID Name {31435641-0000-0010-8000-00AA00389B71}
formattype: FORMAT_MPEG2_VIDEO {E06D80E3-DB46-11CF-B4D1-00805F6CBBEA}
bFixedSizeSamples: 0
bTemporalCompression: 1
lSampleSize: 1
cbFormat: 165

VIDEOINFOHEADER:
rcSource: (0,0)-(1920,1080)
rcTarget: (0,0)-(1920,1080)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 417084

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 16
dwPictAspectRatioY: 9
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

MPEG2VIDEOINFO:
dwStartTimeCode: 0
cbSequenceHeader: 33
dwProfile: 0x00000064
dwLevel: 0x00000029
dwFlags: 0x00000004

BITMAPINFOHEADER:
biSize: 40
biWidth: 1920
biHeight: 1080
biPlanes: 1
biBitCount: 12
biCompression: AVC1
biSizeImage: 3110400
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 80 07 00 00 38 04 00 00 ........€...8...
0010: 00 00 00 00 00 00 00 00 80 07 00 00 38 04 00 00 ........€...8...
0020: 00 00 00 00 00 00 00 00 3c 5d 06 00 00 00 00 00 ........<]......
0030: 00 00 00 00 00 00 00 00 10 00 00 00 09 00 00 00 ................
0040: 00 00 00 00 00 00 00 00 28 00 00 00 80 07 00 00 ........(...€...
0050: 38 04 00 00 01 00 0c 00 41 56 43 31 00 76 2f 00 8.......AVC1.v/.
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070: 00 00 00 00 21 00 00 00 64 00 00 00 29 00 00 00 ....!...d...)...
0080: 04 00 00 00|00 18 67 64 00 29 ac d9 40 78 02 27 ......gd.)¬Ù@x.'
0090: e5 84 00 06 5d 3c 01 31 2d 02 3c 60 c6 58 00 05 å„..]<.1-.<`ÆX..
00a0: 68 e9 3b 2c 8b hé;,‹

- Enumerated media type 0:

Set as the current media type

[madshi]

You provided details on how to not break FSE in the mVR distribution files IIRC and you said that you were in contact wih them so I thought that you could raise the subject someday, nothing more.
Sorry, but how the PotPlayer GUI works is not really very interesting to me. I'm not in a position to talk to the PotPlayer devs about this since I'm not using PotPlayer myself and I don't even know which problems are there exactly. And no, I'm not interested to find out. If the PotPlayer devs have questions about how to do something, they can contact me and ask. But I'm not going to contact them about something I have no knowledge of and no interest in myself.

Keep meaning to tell you, but since 0.85 MPC acts as if the window is always on top. I have to click minimize to get it out of the way. Is there a way to change this behaviour?
Can anybody reproduce this? I don't have this problem on my PCs, from what I can see. Are you sure this is a new problem with v0.85.x? Does it always occur or just when using the new features (DXVA2 decoding and/or scaling)?

It seems to manifest mostly with 1080p files, although some work. Especially fullscreen 16/9 1080p seems hard. Very weird, didn't have any problems at all with Win7. any suggestions where I should start looking?
Well, as I said, it looks like a driver problem to me. There's nothing I can do about it. Maybe you should just go back to win7.

AMD rig:

Every time native DXVA2 decoding is on, colors look different from reference (2 and 4). Colors / gamma, everything look the same between 1 and 3, and 2 and 4. As far as I can tell, DXVA2 scaling looks similar to Bilinear scaling. (edit: nm, no scaling was done, video was 1920x1080 on a 1080p display)

Driver: 12.10 with AMD Vision CP installed
GPU: MSI Radeon 5570
OS: Win 7 64-bit
Thanks. Could you please double check the effects of DXVA2 scaling? Does that change colors, too?

Intel Rig:

My Intel rig is connected to a 32" 1360x768 native LCD TV but supports up to 1080p. At first I took all of my screenshots at my display's native resolution (1360x768) and every screenshot (2, 3 and 4) had different colors than the reference #1 shot.
Ok, so 2, 3 and 4 are all different compared to 1. But are 2, 3 and 4 different to each other? Or all 2, 3 and 4 all identical?

DXVA2 decoding and software decoding has no difference in colors/gamma. Scaling in DXVA2 looks slightly but noticeably sharper/clearer than bilinear scaling.

GPU: Radeon HD 5670
Driver: 11.5 without Catalyst, default driver from MS update
OS: Windows 7 64-bit
So no color/gamma difference with DXVA2 scaling, either? Just a difference in sharpness, correct?

Can't test 2 & 4 on the material I was testing since it doesn't work with DXVA2 for me (576p/25). 3 has different colours (yellower) to 1, and 3 is also slightly squished horizontally compared to 1 (a few pixels at most).

Using Windows 8, nVidia GTS 250, latest drivers (306.97).
Can I have a sample with which the image is horizontally squished? When you have the horizontal squishing, which "target rectangle" does the madVR debug OSD show?

Could you please also try DXVA2 decoding with some different material to test whether that also makes the colors look different? Thanks!

Green line at the top here too with intel hd3000. Something that may help track the problem is it's not limited to resizing. If madvr isn't image resizing but dxva resizer is selected the green line shows up when decoding with intel quicksync, switch to another decoder and it disappears.
I do think this problem is limited to resizing. Probably the video you tested with needed an anamorphic stretch, which also falls into the resizing category.

MPC also takes about twice as long to start up with madvr 0.85.x as it does with 0.84.x and EVR on intel hd3000, after initial start it's quick again when switching files.
How long is twice as long? Half a second? 10 seconds? Can anybody else reproduce this?

Is it planned to have dxva available for chroma resizing?
It wasn't planned. But right now I'm not sure how to solve the color difference problems, so I don't know which exact solution I'll end up with.

As for defaults, dxva is the 2nd largest load on the 2 gpu's here, so unless it can scale with performance of the gpu it might not be good for preventing slide shows
I don't really understand what you mean here. Could you please clarify?

but maybe more important then default resizer is gpu queue. While process explorer doesn't show a significant load or ram increase using 8 gpu queues frame drops start around 60% load, while 4 gpu queues starts around 80%. Then there's the problem I had way back when with frozen player with default queues, luckily was able to drop them to 4 after a few minutes and issue disappeared. Is there any advantage to using 8 over 4? Drops frames at a lower load, noticeably slower startup and seeks on lower end hardware are disadvantages. 6/4 queues has never been a problem for me.
Well, unfortunately the queue size has a different effect for different users. E.g. on my NVidia 9400 PC I only get smooth results if I increase the default queue sizes.

Seems like the colors are the same to me for all four. At first I thought 3-4 had very slightly different colors, but I think it was just the scaling + processing.
Ok, thx.

On some material, the DXVA2 scaling shifts the whole image down-right a couple pixels, resulting in a black bar at the edge.
Could you upload a small sample of such a material with which you see a shifted image? And please write down the "target rectangle" in the madVR debug OSD (Ctrl+J) when you see that shifting, so that I can reproduce it here. Thanks!

Requesting these new color controls added in 0.85 support Gamma adjustment! :D
I can't find any Microsoft interface which allows gamma adjustments. So there isn't any way for me to let the media player control gamma, unless I add a private interface for that. Anyway, I'm planning to change the media player controls soon. "Brightness" is going to do gamma adjustments. More about that later...

[Aikibana]

Noticed a small bug with the latest version of Madvr: when using 'DXVA2 native' (LAV decoder), subtitles won't appear when playing DVD's.
Switching back to 'DXVA2-CB' or 'None' (software) the subs are displayed correctly.
Anybody else noticed this?

Another question: I can understand the benefit of 'DXVA2 native' compared to 'Copy-Back'.
But what does the brand new DXVA-option in the scaling menu do exactly?
How does it compare to all the other settings (Jinc, spline, ...) which are perfectly parameterizable to any taste?
What's best if CPU/GPU power is not an issue?

I assumed all Madvr-processes (including scaling) were already handled by the GPU when using the C-B method...

[noee]

Noticed a small bug with the latest version of Madvr: when using 'DXVA2 native' (LAV decoder), subtitles won't appear when playing DVD's.
Switching back to 'DXVA2-CB' or 'None' (software) the subs are displayed correctly.
Anybody else noticed this?


TEsting with jRiver MC18 and subs on DVDs with DXVA2 decode (LAV:54.0) are working fine.

[kasper93]

But what does the brand new DXVA-option in the scaling menu do exactly?
It use DXVA2 to scale image instead of madshi's shaders implemented in madVR.

What's best if CPU/GPU power is not an issue? 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.

But it's matter of taste some people like sharper image with artifacts, some more blurred clear image. It's up to you :)