On Thu Apr 4 17:36:30 2024 +0000, Rémi Bernon wrote:
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.
Actually the remark about Windows 8 test might be wrong, it may just be a side effect of running in a VM with a D3D device that doesn't actually support video processing. Maybe the transform simply incorrectly returns success from ProcessMessage.