Brendan McGrath (@redmcg) commented about dlls/mf/session.c:
return; }
unpause_seek = start_position->vt == VT_I8;if (unpause_seek)session_flush_nodes(session);
FYI - I just came up with a very similar fix to this: https://gitlab.winehq.org/redmcg/wine/-/commit/f44e24148a10a124865cb11537cc5...
It is required to fix stop/start when using AVPro in VRChat (under the hood it is doing a Pause/Start with a position of 0.0 seconds). I found your MR after trying to merge my change in to Proton (and running in to a conflict with your change there).
At the moment, `f44e241` is part of a branch with experimental fixes for the different timing issues that I've ran in to. But I do plan to upstream each fix eventually.
I have another change in that branch that resets `stream->requests` to zero in `session_flush_nodes`: https://gitlab.winehq.org/redmcg/wine/-/commit/425c4f08e593fd45794dfcd1d3b4a...
I don't believe we have a way of knowing the status of these requests when the flush takes place. The request might still be undelivered (i.e. in the initial queue), or it could have already resulted in a sample being produced and processed all the way to the very last transform. So I think it makes sense to set `requests` to zero when we flush. I was otherwise getting a scenario where the sink was flushing and requesting a new sample, but the media session wasn't passing it on because it was just incrementing `requests`. The problem was, the pending request had been flushed when we flushed the transforms. As a result, playback was frozen indefinitely.