On Thu Nov 13 17:22:54 2025 +0000, Charlotte Pabst wrote:
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.
Hmm I think the reason is rather that when disabling thinning, it probably needs to skip to the next keyframe before starting outputting samples again, to make sure the decoder can start from a clean point. Also this seems to be a per-stream requirement, and would need to be implemented as such.
Another thing I noted from varying the test snippet above is that MEStreamThinMode is sent only *if* some samples have been skipped. If the next sample to be read was a keyframe already, `IMFMediaStream_RequestSample` would not trigger the thinning mode change and only the next request would. This could also confirm your buffering analysis, where each stream has its next sample read in advance and decides whether thinning mode is to be updated based on its properties.