Not the first, not the last. A Direct3D 11 enabled Media Foundation transfer fails to transfer sample attributes while doing the conversion.
Why attributes are important in first place? Because we can associate data with samples/frames and have them passed through attached to specific frame as the conversion goes and as the data transits through the pipeline.
There is no strict rule whether a transform needs to copy attributes from input to output samples. Attributes are flexible and in this case it’s so flexible that it is not clear what the transforms actually do. Microsoft attempted to bring some order with
MFPKEY_EXATTRIBUTE_SUPPORTED property. Let us have a look at what documentation says about the processing model:
The input samples might have attributes that must be copied to the corresponding output samples.
- If the MFT returns
MFPKEY_EXATTRIBUTE_SUPPORTEDproperty, the MFT must copy the attributes.
- If the
MFPKEY_EXATTRIBUTE_SUPPORTEDproperty is either
VARIANT_FALSEor is not set, the client must copy the attributes.
Words “client must copy the attributes” should be read as this: MFT does not give a damn about the attributes and go copy them yourself the way you like.
Needless to say that Video Processor MFT itself has not faintest idea about this
MFPKEY_EXATTRIBUTE_SUPPORTED attribute in first place, and so is the behavior it defines.
Microsoft designed Video Processor MFT as a Swiss army knife for basic conversions. The MFT has zero degrees of customization and has multiple code paths inside to perform this or that conversion.
All together it means that small bugs inside are endless and MFT behavior is not consistent across different conversions.
So I approached the bug itself: unlike other scenarios when the MFT does pixel format conversion it fails to copy the sample attributes. I feed a sample with attributes attached and I get output with zero attributes.