It might look weird why would someone try Direct3D mode with a DSP, which is not supposed to be Direct3D aware, but still. I am omitting the part why I even got to such scenario. The documentation says a few things about MFT_MESSAGE_SET_D3D_MANAGER:
- This message applies only to video transforms. The client should not send this message unless the MFT returns TRUE for the
MF_SA_D3D_AWAREattribute (MF_SA_D3D11_AWAREfor Direct3D 11). - Do not send this message to an MFT with multiple outputs.
- An MFT should support this message only if the MFT uses DirectX Video Acceleration for video processing or decoding.
- If an MFT supports this message, it should also implement the
IMFTransform::GetAttributesmethod and return the value TRUE… - If an MFT does not support this message, it should return
E_NOTIMPLfromProcessMessage. This is an exception to the general rule that an MFT can return S_OK from any message it ignores.
Frame Rate Converter DSP is a hybrid DMO/MFT, which in turn basically means that its “legacy” DMO upgraded to MFT using specialized wrapper. It is not supposed to be Direct3D aware, not documented as such.
However it could presumably normalize frame rate of Direct3D aware samples by dropping/duplicating samples respectively. It could easily be Direct3D aware since it does not need, in its simplest implementation, to change the data. It is easy to see that the MFT satisfies the other conditions: it is single output video transform.
The MFT correctly and expectedly does not advertise itself as Direct3D aware. It does not have transform attributes.
However, it fails to comply with documented behavior on returning E_NOTIMPL in MFT_MESSAGE_SET_D3D_MANAGER message. The message is defined to be an exception, however DSP implementation seems to be ignoring that. The wrapper could possibly be created even before the exception was introduced in first place.
The DSP does not make an exception, returns success code as if it does handle the message, and does not act as documented.