I have a quick question regarding changes here, what's the idea behind have a copier internally? Is it for the case when downstream node does not provide d3d samples?
This is mostly to do the same as in the video decoder, and the idea was to benefit from any sample copy optimization (Copy2DTo, etc) that could be implemented in the copier, without having to reimplement it in every transform.
Ultimately, it could perhaps be replaced by mapping the D3D buffers to memory and letting GStreamer write to it directly, but that requires more work to provide buffer stride information to GStreamer. In the meantime, we could also perhaps map the D3D buffers as contiguous memory, which may be equivalent to using the sample copier but possibly less efficient.
I'm not entirely sure how this is resolved on windows, I know that this happens:
source -> unware-mft -> evr ==> source -> unaware-mft -> copier -> evr
Then, if you have:
source-> aware-mft -> evr ==> does that use just one allocator from evr, or mft provides another one?
and in any case, does it get resolved to:
source -> copier -> aware-mft -> evr?
The tests from https://gitlab.winehq.org/wine/wine/-/merge_requests/5464 show that native may insert copiers right before sinks, *and only right before sinks*, in the following conditions:
1) sink exposes a device manager (d3d aware attribute has no effect), and
2.a) sink is immediately preceded by a d3d-unaware transform that allocates its own samples, or
2.b) sink is immediately preceded by a d3d-aware transform, but that transform advertises that it will allocate samples *without any prior device manager initialization* (which means that the d3d-aware transform might allocate non-d3d samples), and dxva topology initialization is not enforced (DXVA_MODE != FULL).
I understand that the copier is there to make sure that only D3D samples are passed to the sink, in the case where the preceding transform would have allocated non-D3D samples.
As far as I could see, no copier is inserted elsewhere, so I assume that even when they received a D3D device manager, transforms are supposed to support being fed with non-D3D buffers as input.
Source in general can support allocators I think, but there is a special API for those, and regular media formats sources don't have that.
I'm interested, which API is that?