On Thu Apr 24 11:02:43 2025 +0000, Nikolay Sivov wrote:
It was calling `OnClockStart`, but it turns out that was because I had
hard-coded the value in my `MESourceStarted` and `MEStreamStarted`
events. After changing these events to instead use `pvarStartPosition`
passed in `IMFMediaSource::Start`, I get:
1330.024952|10088|source_mock_Start: format:
{00000000-0000-0000-0000-000000000000} (GUID_NULL) position: <EMPTY>
1330.025598|10088|clock_sink_OnClockRestart: system time 13300255028
So sending those events with a hard-coded `VT_I8` value of zero caused
`OnClockStart` to be called, but now those events have a value of
`VT_EMPTY` and `OnClockRestart` is called.
I see, this is something we do differently. We are using original
session Start() timestamp when restarting the clock, and Windows
apparently is using whatever source reports. I think there is a value in
doing the same - the idea here I'm guessing is to adjust to the source
time, which could deviate both ways from the time client asked for. What
we'll need to figure out is which stamp we should actually be using for
the new clock position. You can have multiple sources with multiple
streams, so number of events with timestamps is potentially number of
streams across all sources + number of sources.
I think Windows' approach has merit if we are requesting a new start time, but for resumption I don't think it does. They don't perform any of the flushing in this scenario. So if the source changes the position significantly, then all the sinks and MFTs will have stale data. I guess they just rely on the source not doing that on resumption.
But the other issue is, as you say, there will now be multiple sources of truth. If we get different values from all the different streams, which one is correct?