On Thu Nov 13 11:17:25 2025 +0000, Rémi Bernon wrote:
Also note that calling `IMFRateControl_SetRate` multiple times quickly sends as many `MESourceRateChanged` events but if thinning mode is toggled back and forth there's no `MEStreamThinMode` sent with the last sample request.
I've implemented this locally now and I understand why it makes sense on its own and solves the problem/test you describe, but it doesn't seem to solve the problem that the discussed code snippet aims to solve.
Your suggested change is concerned with at what point rate/thin are updated and when MEStreamThinMode & MESourceRateChanged are sent, but regardless of when it happens, the first sample after a MEStreamThinMode is still affected by the source having operated in thin=true mode previously, even when the source was changed to thin=false and MESourceRateChanged was successfully received before the sample was requested - and this is asymmetric, a previous thin=false does not affect the next requested sample after a thin=true change.
It only really makes sense when you think of it as the source buffering the next sample and subjecting it to thin-discarding both when it is about to be returned, and when looking for the next sample to buffer after a previously buffered sample was just returned. My code snippet just emulates this behavior. Perhaps it would be better to actually implement it in the way I suspect windows does it.