I did more testing and I also see that in MF_SAMPLEGRABBERSINK_IGNORE_CLOCK mode the sample is processed regardless of pause state. As for async mode, the grabber indeed stores up to 4 samples in paused state (as seen by reference count). But then when resuming it seems not to depend on sample time but rather how the clock is restarted: if restart time is PRESENTATION_CURRENT_POSITION queued samples are processed (either with zero time or with the time in the future); otherwise (even if the resume time is the clock pause time) the samples are dropped and behaviour matches my previous patch version. I also briefly tested with calling _OnClockRestart / _OnClockStart grabber's sink callback directly to see if it responds to different callback type or to position special value, and it looks like _OnClockStart(...,PRESENTATION_CURRENT_POSITION) is the same as _OnClockRestart. The latter test is not integrated to my standalone test. Yet the updated one (attached) tests the different clock resuming modes and ignore_clock behaviour. v4 changes: - Add patch forcing sample processing while paused in ignore_clock mode; - Store samples received while paused (if not in ignore clock mode); - Replay stored samples if resumed with PRESENTATION_CURRENT_POSITION. [0001-mf-tests-Add-test-for-pausing-and-restarting-sample-.patch](/uploads/8e4a90ee04616f449a7d8d028452b302/0001-mf-tests-Add-test-for-pausing-and-restarting-sample-.patch) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/574#note_6239