On Wed Apr 3 20:25:54 2024 +0000, Rémi Bernon wrote:
Well, after more investigation it seems likely after all that the session doesn't use an allocator itself but relies on the individual components being D3D aware. The same thing seems to happen with the source reader. Although it reports MF_SA_D3D11_AWARE (and MF_SA_D3D_AWARE on Win7 only), the video processor *is* D3D aware, and I intend to implement it. I also suspect that it is somehow involved in the D3D9 case even though it doesn't have the MF_SA_D3D_AWARE attribute on more recent Windows. Maybe MF_SA_D3D11_AWARE implies MF_SA_D3D_AWARE. As long as either a decoder or a video processor is present in the pipeline, there is no need for an external allocator or sample copier. Still, I'm not completely sure how video sample notifications are supposed to be used, or if they even are. It looks to me that if we can starve the allocator somehow, and without notifications, it could stall the pipeline.
Allocators are associated with stream sinks, and yes, they are provided by sink components normally I think. The situation with d3d11_aware could be different because there is no builtin d3d11 renderer, for some reason.
What happens if you do source -> decoder-with-optional-d3d-decoding -> sample grabber? Does that resolve to a topology with d3d(11)_aware attributes set? If it doesn't that still could mean that session enables it itself. That should be visible in final topology, or actually you can see that yourself by checking decoder attributes before are after.