On Tue Nov 26 23:40:30 2024 +0000, Brendan McGrath wrote:
That's right. I wrote the following tests to explore what Windows was doing: [svr_tests.patch](/uploads/445c54d660f272fde21e8eef710509db/svr_tests.patch) I found Windows requests two samples as part of a pre-roll, and then will request a new sample every-time it returns `S_OK` to `IMFMediaEngineEx::OnVideoStreamTick`. If it drops a sample (due to the second sample being "ready"), then it will request a second sample on receipt of the first.
Even if it's always going to be just two pending samples at most, this needs generic logic to handle queue of any size. Unless that's what it already does, and I'm just missing something.
What do you mean by supply? Make available to OnVideoStreamTick/Transfer* ?
My understanding is that during playback, if say we don't request frames temporarily, on next OnVideoStreamTick we'd compare those queued timestamps with current time, and drop every outdated sample. Then we pick one that's closest to current time, is that the idea? Then on Transfer* call, do we need to reevaluate pts of those closest sample again and potentially drop it?
What you're describing sounds like sample 1 could be either ahead or behind sample 2? How is that possible? On seeking we are most likely supposed to clear the queue, and reversed playback would still supply samples in temporal order. So with fifo queue, popped sample would be the "oldest", and we only need to check if it's behind current time to drop it, and pick next one. This is similar to what happens in EVR, that's why I suggest using queue logic from there.