Rémi Bernon (@rbernon) commented about dlls/mfsrcsnk/tests/mfsrcsnk.c:
- hr = IMFRateControl_SetRate(rate_control, thin, rate);
- todo_wine_if(thin && hr == MF_E_THINNING_UNSUPPORTED)
- ok(hr == S_OK, "Unexpected hr %#lx.\n", hr);
- while (!got_stream_end && (event = event_callback_recv_event(callback, 1000)))
- {
hr = IMFMediaEvent_GetType(event, &type);ok(hr == S_OK, "Unexpected hr %#lx.\n", hr);hr = IMFMediaEvent_GetValue(event, &value);ok(hr == S_OK, "Unexpected hr %#lx.\n", hr);hr = IMFMediaEvent_GetStatus(event, &status);ok(hr == S_OK, "Unexpected hr %#lx.\n", hr);switch (type)
I think it is better to sequentially call then check for events in a lock step, making things more deterministic and better exhibiting the order things are supposed to happen. Of course in this case some events are received on the source, and some on the stream, so it's not 100% deterministic and you may wait for events in one order or the other but still.
Similarly, this would let you check for sample timestamps directly in sequence, without sorting them. This would make the test more strict and it would catch any possible mistake with the order samples are supposed to be sent.
Wrt timestamps, I would suggest to use an AVI sample format instead, which would allow (some) test to pass with exact timestamp values. You've maybe noticed that our MP4 media source doesn't have the right timestamps yet, and we're (GStreamer/FFmpeg is) probably missing some offset somewhere in the file. This isn't the purpose of this test though and using AVI instead would help avoiding this problem.
In short I think something like https://gitlab.winehq.org/rbernon/wine/-/commit/3dabfcd989a08f78822d8989f46b... would be better, what do you think?