If we don't use `stream_index`, then the first sample in the response queue is popped and delivered. However, this sample may not be from the stream that is making the sample request.
This fixes audio distortion in River City Girls. The video stream was hitting EOS prior to the audio stream. As a result, the video MFTs were drained and all the resultant samples were placed in the response. Then, when an audio sample was requested and then delivered, the `SOURCE_READER_ASYNC_SAMPLE_READY` operation was triggered which was delivering the first sample in that response queue; which was a video sample rather than the requested audio sample. As a result, the video data was rendered as audio (causing the audio distortion).
From: Brendan McGrath bmcgrath@codeweavers.com
If we don't use stream_index, then the first sample in the response queue is popped and delivered. However, this sample may not be from the stream that is making the sample request. --- dlls/mfreadwrite/reader.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/dlls/mfreadwrite/reader.c b/dlls/mfreadwrite/reader.c index 4d223f1de6e..139b8991da2 100644 --- a/dlls/mfreadwrite/reader.c +++ b/dlls/mfreadwrite/reader.c @@ -1571,7 +1571,8 @@ static HRESULT WINAPI source_reader_async_commands_callback_Invoke(IMFAsyncCallb case SOURCE_READER_ASYNC_SAMPLE_READY:
EnterCriticalSection(&reader->cs); - response = media_stream_pop_response(reader, NULL); + stream = &reader->streams[command->u.sample.stream_index]; + response = media_stream_pop_response(reader, stream); LeaveCriticalSection(&reader->cs);
if (response)
Yes, this makes sense. It looks like it might have worked before and has regressed in 4e72ea0f4a5f98c816e27ec1dbefb95a8c23c581.
This merge request was approved by Nikolay Sivov.