Having support for asynchronous transforms would be nice, but my concerns are about compatibility:
- there is a documented way to assign queues to branches with MF_TOPONODE_WORKQUEUE_ID. I imagine that having async processing on the same branches will violate that;
As far as I can see this only applies to source nodes, although maybe it applies to all the downstream chain? I'm also not sure to understand how it matters what happens internally. Decoders might already create internal threads to process frames in parallel. What matters is that the samples are then delivered to the client from the proper queues.
- quality manager has callbacks for ProcessInput()/ProcessOutput() that are visible to applications, I believe those are blocking and again might differ if we introduce additional queues;
Although it might be interesting to check how true async MFT behave if they are even supported, I think that here again we can simply consider an async MFT wrapper will behave as a synchronous one from the session perspective, except for the notifications.
The session will still call ProcessInput / ProcessOutput, and notify the quality manager about it synchronously. If this blocks, then the session will not call ProcessOutput again until it returns. The async MFT wrapper might still continue to process some frames in background, but will eventually becomes idle as the session will not be pushing input either.
- async transforms require additional resolution steps to enable them, and additional flag to enumerate. Is there an evidence that the loader enumerates async transforms automatically and sets them up?
I don't know, I haven't done any test with actual async MFT. I don't even know if they are supported, and none of the builtin MFT I have seen so far are supporting the async mode.
- resolved topology contains references to transform objects, which in this case will be wrappers. This is clearly visible to client application;
The wrapper is only kept in the session topo_node, the topology still has the original transform object.