On Fri May 2 17:55:41 2025 +0000, Elizabeth Figura wrote:
I guess native is supposed to not block in that case
That's a good point. If we have two streams call
`IMFMediaStream::RequestSample`, then we will process them in sequence rather than in parallel. That is, one stream will have to wait for the other to receive data (as we block all other streams once the source cs is acquired in `source_async_commands_Invoke`).
This MR will at least unblock a stream when there is no more data, but
Windows probably delivers data for the other stream immediately (i.e. it can deliver data for one stream, even if the other was already waiting). And I believe I recall seeing audio latency in Wine as a result of this. From memory, it was a 4K video, so delivery of the video sample took a while and as a result the audio fell behind. We should probably look to lock the individual streams rather than the entire source when possible. Hrm, I didn't think we had a locking problem, but if we do that should be fixed, yeah.
I'll have a think about how I can test this. I might be able to craft a file that'll delay one of the streams long enough, that whilst waiting for a sample, I can reliably request and receive a sample on the other.
Thanks for the review.