EVR(CP) renderer cannot be connected properly when custom filter output format is P010

[TianZerL]

I'm developing a video scaling filter.
I found that if the output is P010, EVR(CP) will not be connected, and it will connect to VideoRenderer (is it VMR?). But it will work if EVR(CP) renderer directly connect to decoder.
My filter will copy the header information from input and only modify the output size. And I tested my filters in MPC-BE and Potplayer, they were all OK to connect to EVR(CP) renderer.
Any ideas?

[clsid2]

EVR(CP) refuses P010 input because that does not work properly with EVR in some cases (bug in Windows and/or drivers).
https://github.com/clsid2/mpc-hc/blob/develop/src/filters/renderer/VideoRenderers/IPinHook.cpp#L164

Your filter should ideally copy all supported mediatypes of the upstream filter and reconnect based on the mediatype used by downstream filter.

For good P010 support you should use madVR or MPCVR as renderer.

[TianZerL]

Thanks your reply, but why can EVR(CP) accept the P010 from decoder like LAV? Sorry, I didn't read the code carefully😂.

[chainikdn]

bug in Windows and/or drivers

Is this bug really exists now?
From MPC-BE's sources: https://github.com/CollinChaffin/MPC-BE/blob/73cf893c1085a4c269f43c79dd06b910996fcd2e/src/filters/renderer/VideoRenderers/IPinHook.cpp#L115

Windows 10 support software P010 input

[clsid2]

With some drivers P010 (non-DXVA) gives bad results on Windows 10. That is why I disabled it. Also, it typically gets converted to RGB32 in the renderer, so you might as well do conversion to 8-bit earlier in the chain and be able to apply dithering.

[clsid2]

Mostly Intel which was buggy if I remember correctly.

Converting to 8-bit with in your filter would probably be best, as you can then still do high bitdepth processing. It also avoids having to do a reconnect.

[chainikdn]

gives bad results on Windows 10 ... Mostly Intel which was buggy if I remember correctly

that was 6 years ago after all, and since allowing P010 in Win10 is good for MPC-BE, why it isn't good for MPC-HC?

even if it "gives bad results" with EVR then right now it falls back to the "Video Renderer" which just "hangs" (i.e. doesn't render anything at all)

[clsid2]

MPC-BE has a much smaller userbase, so they get less bug reports. I also know that the devs also don't have any Intel GPUs themselves.

If should only fallback if P010 is the only output format that you offer in your filter. Also, wouldn't the same fallback problem exist on Windows 7 where P010 isn't supported?

[chainikdn]

wouldn't the same fallback problem exist on Windows 7 where P010 isn't supported?

speaking of the userbase, in the last two months I only have 1.8% of non-Windows-10 users. i.e. 98.2% are using Win10 ;)

[clsid2]

I see stats of around 78% Win10. But fact remains that some of those systems are buggy.

Plus there could theoretically also be other filters behind yours in the graph that only support 8bit. So being able to do 10/16bit input and 8bit output is advisable.

[CrendKing]

Does anyone have Intel chip that can still reproduce the issue in Windows 10? If test shows Windows 10's EVR would work with P010, can you put the conditional check in so that at least in Windows 10 we don't need to special handling? If not, I guess not much we could do other than send a bug report to Intel?

Also, to only activate the special handling on MPC-HC, how do we reliably check if the player is MPC-HC? Matching the process name to be mpc-hc*.exe seems unreliable.

[clsid2]

The solution is simple. When your filter connects with P010/P016 input, you set P010/P016 + NV12 as mediatypes in your output pin. In CompleteConnect you check which mediatype was chosen by the downstream filter. If that is NV12 you perform colorspace conversion in the filter.

That will works with any player and with all downstream filter/renderer.

[clsid2]

Or if you prefer to let LAV Video do the conversion, then re-connect the input pin once you know the output is going to be NV12.