IMFSourceReader::ReadSample() misbehaviour for high frame rates (returns wrong bitmap)

Question

I think there is a bug in IMFSourceReader::ReadSample() when the frame rate is high.

[context]

I am a regular user of Windows Media Foundation, and I know how to write proper code involving media source, samples decoding, and so on. This is not a beginner's question.

I have written a custom code to decode avi files containing H264-encoded samples and render then as decoded RGB bitmaps, frame by frame.

It works under Windows 7+, and it can even handle timestamps using B-frames (where the order of timestamps does not always match the display order)

I am familiar with the concepts of key frames/delta-frames (matching I and P frames of H264) , stream repositionning, and so on.

[the context data]

I have an avi sequence containing H264 samples. For some reason, it cannot be decoded under W7, it requires W10 (Windows Media Player cannot read it under W7 either, this is not because of my code)

This sequence has only one specificity : a high native frame rate of 300fps (because it was recorded with a high speed camera). Otherwise, it does not have B-frames, it is a standard spatial size, a standard H264 profile.

[the bug]

My problem is that :

1. at first everything runs fine : if I decode samples in order (t1, t2, t3, t4...), I get samples in order (S1, S2, S3, S4...)
2. I don't even have to perform repositioning, ReadSample() is advancing naturally for this sequence with only I and P frames
3. but when I display the bitmaps (B1, B2, B3, B4, ...), it happens more than often than the bitmap does not change (B2 == B3 == B4), while it should

[What I checked]

Obviously, I checked that the frames were indeed different, using another player allowing frame-by-frame stepping (VLC).

And I have observed that the bug disappears if I open the SourceReader with a custom frame rate like 30 fps. In that case, bitmaps are OK. (but in that case timestamps become harder to use properly when repositionning)

I do not want to enter a dummy frame rate, I need to handle the raw information.

[My interpretation]

My interpretation is that there is some hidden setting in the (implicit) IMFTransform pipeline that try to spare time by NOT updating decoded bitmaps for very close timestamps.

I could not access any drop frame setting (IMFQualityAdvise is not available for such a source reader), and don't know what to look for.

I am not even sure that this interpretation is correct.

Any idea ?