[PATCH v6 0/2] MR6059: mf: Retry PROCESSINPUTNOTIFY if TRANSFORM_TYPE_NOT_SET is returned.
Send INVALIDATEMEDIATYPE to allow the transform type to be set before retrying PROCESSINPUTNOTIFY.
-- v6: mf: Send MEError when IMFStreamSink_ProcessSample fails. mf: Retry PROCESSINPUTNOTIFY if TRANSFORM_TYPE_NOT_SET is returned.
From: Brendan McGrath bmcgrath@codeweavers.com
Send INVALIDATEMEDIATYPE to allow the transform type to be set before retrying PROCESSINPUTNOTIFY. --- dlls/mf/evr.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/dlls/mf/evr.c b/dlls/mf/evr.c index db7053a1405..a13c2d7e89b 100644 --- a/dlls/mf/evr.c +++ b/dlls/mf/evr.c @@ -416,7 +416,10 @@ static HRESULT WINAPI video_stream_sink_ProcessSample(IMFStreamSink *iface, IMFS }
if (SUCCEEDED(IMFTransform_ProcessInput(stream->parent->mixer, stream->id, sample, 0))) - IMFVideoPresenter_ProcessMessage(stream->parent->presenter, MFVP_MESSAGE_PROCESSINPUTNOTIFY, 0); + { + while (hr == S_OK && (hr = IMFVideoPresenter_ProcessMessage(stream->parent->presenter, MFVP_MESSAGE_PROCESSINPUTNOTIFY, 0)) == MF_E_TRANSFORM_TYPE_NOT_SET) + hr = IMFVideoPresenter_ProcessMessage(stream->parent->presenter, MFVP_MESSAGE_INVALIDATEMEDIATYPE, 0); + }
if (stream->flags & EVR_STREAM_PREROLLING) {
From: Brendan McGrath bmcgrath@codeweavers.com
--- dlls/mf/session.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/dlls/mf/session.c b/dlls/mf/session.c index 3c989249229..e24cc6376b4 100644 --- a/dlls/mf/session.c +++ b/dlls/mf/session.c @@ -3706,7 +3706,10 @@ static void session_deliver_sample_to_node(struct media_session *session, struct if (sample) { if (FAILED(hr = IMFStreamSink_ProcessSample(topo_node->object.sink_stream, sample))) + { WARN("Stream sink failed to process sample, hr %#lx.\n", hr); + IMFMediaEventQueue_QueueEventParamVar(session->event_queue, MEError, &GUID_NULL, hr, NULL); + } } else if (FAILED(hr = IMFStreamSink_PlaceMarker(topo_node->object.sink_stream, MFSTREAMSINK_MARKER_ENDOFSEGMENT, NULL, NULL)))
Hi,
It looks like your patch introduced the new failures shown below. Please investigate and fix them before resubmitting your patch. If they are not new, fixing them anyway would help a lot. Otherwise please ask for the known failures list to be updated.
The tests also ran into some preexisting test failures. If you know how to fix them that would be helpful. See the TestBot job for the details:
The full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=148184
Your paranoid android.
=== debian11b (64 bit WoW report) ===
ddraw: ddraw2.c:3814: Test failed: Expected (0,0)-(640,480), got (0,0)-(1024,768). ddraw2.c:3839: Test failed: Expected (0,0)-(640,480), got (0,0)-(1024,768). ddraw4.c:3969: Test failed: Expected message 0x5, but didn't receive it.
On Tue Sep 3 13:56:42 2024 +0000, Nikolay Sivov wrote:
I have a couple of comments, or maybe questions. Do you know how do we get in this state when it gets as far as ProcessSample(), but type is not set? SetCurrentMediaType() sets type both the mixer, and notifies the presenter. Do we need the same "loop" when other presenter methods fail similarly? Regarding MEError, is that only to unblock waits? What might be interesting to test is if all common error codes produce MEError and not MENonFatalError. Those are listed at IMFStreamSink::ProcessSample doc page.
The media type is set, but then the game clears it when `IMFTopologyServiceLookupClient::ReleaseServicePointers` is called. We are calling `ReleaseServicePointers` as a result of setting the presentation clock.
The MEError is passed to the application, I guess so it has some idea that an error occurred. The game I was looking at did not seem to use it though.
I tried those errors on the `IMFStreamSink::ProcessSample` doc page, and some don't send a message to the application at all. In all cases however, a `MFVP_MESSAGE_ENDSTREAMING` message is sent to the presenter.
The errors that didn't generate a message to the application were: - MF_E_INVALID_STATE_TRANSITION; - MF_E_INVALIDREQUEST; - MF_E_NO_CLOCK; - MF_E_SHUTDOWN; and - MF_E_STREAMSINK_REMOVED
All the rest send an MEError (including some random error codes I tried, so the list above seem to be exceptions).
I'll now try the other presenter methods with MF_E_TRANSFORM_TYPE_NOT_SET and see if any others enter a loop.
On Wed Sep 4 04:21:27 2024 +0000, Brendan McGrath wrote:
The media type is set, but then the game clears it when `IMFTopologyServiceLookupClient::ReleaseServicePointers` is called. We are calling `ReleaseServicePointers` as a result of setting the presentation clock. The MEError is passed to the application, I guess so it has some idea that an error occurred. The game I was looking at did not seem to use it though. I tried those errors on the `IMFStreamSink::ProcessSample` doc page, and some don't send a message to the application at all. In all cases however, a `MFVP_MESSAGE_ENDSTREAMING` message is sent to the presenter. The errors that didn't generate a message to the application were:
- MF_E_INVALID_STATE_TRANSITION;
- MF_E_INVALIDREQUEST;
- MF_E_NO_CLOCK;
- MF_E_SHUTDOWN; and
- MF_E_STREAMSINK_REMOVED
All the rest send an MEError (including some random error codes I tried, so the list above seem to be exceptions). I'll now try the other presenter methods with MF_E_TRANSFORM_TYPE_NOT_SET and see if any others enter a loop.
I could only get it to loop if I returned `MF_E_TRANSFORM_TYPE_NOT_SET` on `IMFVideoPresenter::ProcessMessage` with either `MFVP_MESSAGE_INVALIDATEMEDIATYPE` or `MFVP_MESSAGE_PROCESSINPUTNOTIFY`.
-
Brendan McGrath -
Brendan McGrath (＠redmcg)
-
Marvin