Nikolay Sivov (@nsivov) commented about dlls/mfmediaengine/tests/mfmediaengine.c:
- hr = IMFMediaEngineEx_OnVideoStreamTick(notify->media_engine, &pts);
- ok(hr == S_OK, "Unexpected hr %#lx.\n", hr);
- hr = IMFMediaEngineEx_TransferVideoFrame(notify->media_engine, (IUnknown *)texture, NULL, &dst_rect, NULL);
- ok(hr == S_OK, "Unexpected hr %#lx.\n", hr);
- hr = IMFMediaEngineEx_OnVideoStreamTick(notify->media_engine, &pts);
- todo_wine
- ok(hr == S_FALSE, "Unexpected hr %#lx.\n", hr);
- /* sleep until third frame is ready */
- while (IMFMediaEngineEx_GetCurrentTime(notify->media_engine) < 2./30.)
Sleep(1);
- hr = IMFMediaEngineEx_OnVideoStreamTick(notify->media_engine, &pts);
- ok(hr == S_OK, "Unexpected hr %#lx.\n", hr);
This doesn't look like it could be made reliable, even if it works in practice. It's not clear if e.g. next frame might be ready already after TransferVideoFrame() and before OnVideoStreamTick().
The most important part as @besentv found was that no requests are made before OnVideoStreamTick() (or was it Transfer*?) is called for the first time. So when video stream is present, playback does not start automatically, then on first api call the clock-driven audio stream start to play, while video stream requests are still controlled by user calls.