On Tue Jul 8 19:11:08 2025 +0000, Charlotte Pabst wrote:
changed this line in [version 2 of the diff](/wine/wine/-/merge_requests/8505/diffs?diff_id=191619&start_sha=1f7ea7c23ea2f4da1938f41504eaccea3761bcb9#9c89a7a7f07e43f18328b43c0445ed822d60bd2a_663_607)
I've replaced the tests by your commit with minor modifications now. It took some time to make winegstreamer conform properly, I've basically changed the approach on that implementation (out of necessity, this also fixes the previously mentioned problem of the delta frame flag being dropped by the decoder now). I've also added a frame of artificial latency for the thinning change to propagate in mfsrcsnk to pass the tests (It's funny - winegstreamer buffers a lot and needs to have the pipeline flushed to pass, mfsrcsnk buffers nothing and needs to essentially do the opposite to pass. I still feel like it's a bit sad we're trying to match windows behavior so closely, because if we just followed what's legal as per MSDN, neither would be necessary).
Also, it seems like winedmo doesn't give us timestamps for AVI yet, so I've added a commit to generate them to pass the tests - this is also important to thinning because previously in an actual pipeline those missing timestamps would be added by the video decoder MFT later on, which in the case of thinning would assign incorrect timestamps because its timestamping logic assumes that samples are continuous.
This could potentially be a bit problematic tho, there might be a reason why video decoder does what it does, so if the winedmo/mfsrcsnk changes aren't fine yet, it could make sense to get the winegstreamer changes merged first and send the mfsrcsnk changes in a separate MR.