On Tue Aug 8 11:41:47 2023 +0000, Nikolay Sivov wrote:
Tests are of course useful to figure out how it works internally, we can have them as long as they are reliable. Because there is not a lot of reason to chase exact patterns, MFT docs define how these should be used, and internal details do not matter much to us. Regarding WORKQUEUE_ID, this is interesting in principle, yes. Mostly for the case when branches meet in multi-input MFTs. Otherwise it's probably a matter of returning correct queue id from "IMFAsyncCallback::GetParameters()", could be more complicated. Do we know if something is actually using this attribute?
Nothing that I know about is using it but I thought it could be useful to figure how it works if we want to parallelize transform processing. Right now one blocker point is that all the session async operations are serialized anyway because of the session CS.
However, having written more tests I can also see that the native session default behavior is to serialize everything, including possibly concurrent transform processing when there's completely separate streams (Note: when WORKQUEUE_ID attributes are set, you can have concurrent transform processing).
This feels a bit ineffective and I'm a bit worried that serializing decoders could hurt the playback experience, but maybe I should just wait and see how it goes.