I'm looking for guidance both on how IMFSeekInfo should be used and how it should be implemented by third parties. In particular, I'm interested in what should be returned in the last output parameter of IMFSeekInfo::GetNearestKeyFrames.
The documentation for GetNearestKeyFrames says this for the last two parameters:
pvarPreviousKeyFrame: Receives the position of the nearest key frame that appears earlier than pvarStartPosition. The units for this parameter are specified by pguidTimeFormat.
pvarNextKeyFrame: Receives the position of the nearest key frame that appearsearlier than pvarStartPosition. The units for this parameter are specified by pguidTimeFormat.
There are two things I'm not sure of. First, I believe there might be a documentation bug and that pvarNextKeyFrame ought to return alater key frame rather than an earlier one. That would be consistent with the name of the parameter and what Microsoft's IMFSeekInfo implementation for H264 encoded MP4 video streams does.
More importantly, again for the pvarNextKeyFrame output parameter, there are some cases where the implementation of IMFSeekInfo for H264 encoded MP4 streams sometimes returns a frame that is earlier than the requested one. I can't find any documentation as
to why but my guess is that it is intended to provide a downstream deinterlacer with an additional frame prior to the frame that is being seeked to.
Specifically, this is what I have observed. Suppose an H264 video stream in an MP4 file has 300 frames total, has a frame rate of 1 frame per second and the first frame is at time 0s. It has key frames at time 0s, time 100s and time 200s. For brevity, I will
use seconds as the units of time.
Say one requests the nearest next key frame corresponding to either time 50s, 99s or time 100s. There is a key frame at time 100s and, as expected, 100s will be returned as the nearest next frame time. The surprising thing is what happens when one requests
the nearest next key frame for time 101s. One might expect the key frame at 200s to be returned but actually 100s is returned, even though 100s < 101s. When one requests the next key frame corresponding to time 102s, only then is the key frame at 200s returned.
My theory is this ensures a downstream deinterlacer would have at least one extra frame prior to the requested frame to work with. If IMFSeekInfo did not make this adjustment, and the video stream was interlaced, the client would likely have to make the adjustment
itself. Is this guess right?
Assuming my guess is right, from the point of view of a client of the IMFSeekInfo interface that might be dealing with interlaced video, may it assume that all implementations of IMFSeekInfo will make this kind of allowance for interlaced video or, if there
is a possibility of interlaced video, should they make their own allowance for it? If not, may they assume that specific implementations of IMFSeekInfo, such as Microsoft's implementation for H264/MP4 video, will always make this allowance?
Should third parties copy this behaviour when implementing IMFSeekInfo? How about if they know that a video stream is not interlaced?