On Mon Apr 20 21:30:04 2026 +0000, Yuxuan Shui wrote:
check divisibility? And that was how I was figuring out the stride. Brief explanation of my observations: Video I used: yuv420p pixel format, size 162x120. I create source reader then set output type to YV12. I check the `MF_MT_DEFAULT_STRIDE` and the bitmap info stride, both are 162. I then `IMFMediaBuffer::Lock` it. The buffer size reported by `Lock` is `33792`. I calculated the Y plan size: `33792 / 3 * 2 = 22528`, and realized that it's not divisible by 162: `22528 = 162*139+10`. So I tried rounding up to 8-bytes `22528 / 168`, doesn't work. Then rounding up to 16-bytes `22528 / 176 = 128`. Oh interesting. I was curious how the `IMF2DBuffer::ContiguousCopyFrom` and `IMF2DBuffer::ContiguousCopyTo` methods would work in this case and that led me to this:
https://learn.microsoft.com/en-us/windows/win32/api/mfobjects/nn-mfobjects-i... That states:
Every video format defines a contiguous or packed representation. This representation is compatible with the standard layout of a DirectX surface in system memory, with no additional padding.
So maybe that's where the 16-byte alignment comes from. But that would break compatibility with older MFTs that aren't aware to check for the `IMF2DBuffer` interface (in order to determine which rule is being used). Edit: Although I guess if the media type for the output has `MF_MT_DEFAULT_STRIDE` and that is honoured by the MFT, then it would still work. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10654#note_137177