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.
To be fair, MS docs say things like "Events from the media source are not synchronized with events from the media streams." [1], so I figured it'd be more reliable to wait for source and stream events at the same time in any scenario where they could theoretically be delivered in arbitrary order - independently of if I'm able to observe a certain order on windows reliably or not (Hence also the different design from mf's test_callback - I adapted it from test_callback originally but changed it to this to support doing BeginEvent on multiple event sources in parallel).
For many of these cases (like the start events), our MF media session code also accounts for arbitrary order.
The issues I see with testing unspecified windows behavior more precisely especially when it comes to event order is that:
1. Some things might be racy on windows and simply be likely but not guaranteed to be delivered in a certain order, especially when the docs explicitly say that the order is not defined. 2. The windows implementation might change, and since most of this stuff go through the more robust media session, it wouldn't break applications. 3. A test that relies on less implementation details could potentially be adapted to run with a bigger matrix of different files or configurations.
Which is why I've tried to mostly just rely on behavior that is either documented or something that we know games actively need. Essentially, treating the unit tests as a sort of specification.
Especially some of the things like waiting for the first sample and then expecting the `MESourceRateChanged` and `MEStreamThinMode` event and updated timestamps afterwards seems incorrect - implementations may buffer a bunch of samples (I think winegstreamer does, actually? And I vaguely remember having related issues with the windows mp4 source, too), so it's not exactly guaranteed when the transition will happen - marking that is what `MEStreamThinMode` exists for. (Sidenote: if we don't rely on when the transition happens, we also can't use exact timestamp tests, which is why in this case it wouldn't matter whether we're dealing with avi or mp4. And the game I'm implementing this for also happens to just rely on the interval between timestamps being correct).
And (hypothetically) what if that first sample we request takes a while to load and the `MESourceRateChanged` event goes through first?
I'm also a bit wary of testing for the next event to match something. What if new, unrelated events are added and somehow get in the way?
Another concern: Why make the check for `MEStreamThinMode` depend on `MESourceRateChanged` delivering `VT_R4` values? That's just an unrelated bug/oversight in wine, this MR doesn't even fix it, and at that point I'd rather check for `winetest_platform_is_wine` again.
I'm not that big of a fan of wine checks anyway tho, I'd much rather just make sure to not "eat" random events in case a certain expected event doesn't get delivered.
My initial approach for these tests was much more sequential and I've changed it to what it is now after considering many of these problems.
Well, these are my concerns, I'm less knowledgeable/experienced in this matter so maybe I'm just overthinking things. I'm not against using your approach instead.
[1] https://learn.microsoft.com/en-us/windows/win32/api/mfidl/nf-mfidl-imfrateco...