On Wed Apr 3 20:31:55 2024 +0000, Rémi Bernon wrote:
I will try that, but fwiw I'm pretty sure that every MFT has its own allocator, initialized from the device manager that is passed on initialization. I'm not sure that sinks even need or have one. This has visible side effect that after receiving a device manager, the MFT (h264 decoder, video processor, etc...) changes its stream properties to indicate that it will allocate its output samples itself (from the internal allocator it has initialized). It also uses the MFT attributes and output stream attributes (that application can, and do modify through IMFTransform_GetAttributes and IMFTransform_GetOutputStreamAttributes) to control the allocator initialization parameters.
Opened https://gitlab.winehq.org/wine/wine/-/merge_requests/5464 with a test case.
In theory it is possible that some components advertise being D3D-aware, but then still being unable allocate samples themselves. The test I added in https://gitlab.winehq.org/wine/wine/-/merge_requests/5459 with the video processor transform alone shows that it behaves like that on Windows 8.
In such case and because we can still see D3D9/DXGI buffers on the output end, I assume that the session/source reader will create an external sample allocator on behalf of the transform, but I don't think we need to support that scenario as long as we ensure that all our transforms (decoder and processor) support internal allocations.