MPC-HC doesn't load vsfilter on Win7 unless it is set as a preferred filter.
That is a MPC-HC bug/limitation. Other media players on Windows 7 which use standardized DirectShow graph building, unlike MPC-HC, are able to auto-load VSFilter just fine without doing anything special.
It is a 'feature' of Win7 to try to connect things to the renderer as soon as possible. How can MPC-HC even force something into a graph?
MPC-HC doesn't build DirectShow graphs in the standard Win7 way. How does MPC-HC force something into a graph? It creates a custom graph with VSFilter + a incompatible DXVA decoder using its internal merit system and lets it it fail.
If a filter properly refuses a connection, it won't connect. It really seems to me there is a bug. If a reconnect is tried, connection can still be refused again if the mediatype is incompatible, or am I wrong?
The first connection is always 'accepted' since that is the only way xy-VSFilter can be aware of the formats supported by the Decoder and adapt it to the formats supported by the video renderer. This isn't going to change, but the problem is likely caused the the fact that in xy-VSFilter only the '2nd connection' will be refused/fail.
You'll need to ask the MPC-HC devs why this behavior causes graph building with their internal DXVA decoder to break. It would sound like either they are initializing DXVA too soon, or MPC-HC is only capable of recovering a DXVA graph if the first connection fails. Though as I mentioned, the latest versions of MPC-HC automatically fallback from the internal DXVA decoder to the internal Software decoder, so they may already be aware of the problem and that is their solution.
The only thing I'm curious about is why all version of VSFilter 2.39/2.40/xy are detected as supporting Any_type/Any_type in MPC-HC external filters. I'll have x_xy_y2 look into why that happens and if it's needed in xy-VSFilter, since removing it appears to avoid the issue with MPC-HC's internal DXVA decoder.
Bug: unchecking "follow preferred order of upstream filter" on the colors tab causes a crash.
Are you using the Vertical Padding setting with either FFDShow or the XVID decoder? If so, neither of these decoders support the vertical padding setting when xy-VSFilter reconnects with a non-default colorspace as decribed here
. If you must use the Vertical Padding setting, you'll need to use it with a decoder which properly supports it on format change like LAV Video.
If this happens even with Vertical Padding set to Original Height, please provide more details about the filters and versions being used.
Media Player (any internal decoders enabled which support your video?)
Decoder (which output formats are enabled/preferred?)
Splitter (forced VSFilter auto-loading enabled/disabled if supported? custom media type enabled/disabled?)
Renderer (if madVR, any internal decoders enabled which support your video?)
GPU Brand (NVIDIA, AMD, Intel)
Native color format of the video (YV12, YUY2, RGB, etc.). 8-bit or 10-bit?
xy-VSFilter version (18.104.22.168 both 2.4MB and 1.2MB version?)
If changed, please list your custom color preference order in xy-VSFilter + any disabled formats.