On Wed May 14 10:04:10 2025 +0000, Rémi Bernon wrote:
Or this either, I would expect `provide_timestamps` to be somehow exclusive or orthogonal to input sample timestamps? Is this really supposed to update the `decoder->sample_time`? ie: `MFSampleExtension_WG_Timestamp` is meant to carry the matching input sample timestamps to its output samples right? So, is an input sample with a timestamp going to update any future unrelated output sample timestamp too if their input samples don't have one?
I just pushed a new branch to my repo: [bm_cw_24708_mft_wip](https://gitlab.winehq.org/redmcg/wine/-/commits/bm_cw_24708_mft_wip)
It's the same as this branch but includes an additional commit: https://gitlab.winehq.org/redmcg/wine/-/commit/4300469a46db06ca97c7f2788dc54...
That commit includes tests for when sample PTS and duration are not provided for some input. For H.264, Windows will provide values. For WMV, Windows does not. So `provide_timestamps` doesn't seem to be determined by `preserve_timestamps`.
But I found with those tests that we still don't match Windows behavior. It seems like Windows will provide a PTS and duration on Input (for H.264) if it is missing. So that the duration is the same value of the previous input sample. I figure it's not worth fixing in this MR though (as, in practice, it's unlikely a sample will be missing those values, and if it is, it's unlikely the `MF_MT_FRAME_RATE` won't match the duration). But let me know if you agree.