On Tue Aug 30 11:35:12 2022 +0000, R��mi Bernon wrote:
I've been looking into that, and I now think I better understand the logic. There's two different issues at play, one is the SA_READY_COMMAND, which is currently unconditionally queueing callbacks commands into the task queue, causing race conditions when other commands such as START or END are pending. I think this issue is solved by making the sample allocator ready notifications a separate callback. Then, there's the handling of the END command. I believe that regardless of how we keep track of the pending command, it'll still be racy the way it's currently done. For instance, consider the following sequence: Initially the command queue is empty, the session is playing.
- Thread 1 calls IMFMediaSession_Close.
- Thread 2 receives MEEndOfPresentation.
- Thread 1 enters session CS.
- Append a CLOSE command.
- Queue the callback task to Thread 3.
- Thread 1 leaves session CS.
- Thread 3 calls session_commands_callback_Invoke.
- Thread 2 enters session CS.
- Prepend a END command.
- Thread 2 leaves session CS.
- Thread 3 enters session CS.
- Removes the END command, does nothing.
- Thread 3 leaves session CS.
Thread 3 is now idle as no more callback task has been queued. Later, when either MEStreamSinkMarker event or any of the MEStreamSink* state events are received, the session will complete the pending command which is now the CLOSE command, but not actually execute it. I think the same can happen with commands other than Close, and I don't think having a separate pending command would actually change anything here.
I think this should be fixed now.