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)