This is ultimately a follow up for introducing d3d manager support in h264 decoder transform. The last patch avoids unneeded GPU to CPU copy when copying a memory sample to GPU sample (in particular, when sample copier is involved). There are a couple of things to fix on the way.
Patch 1 fixes the crash which otherwise happens in the test introduced in patch 2 due to memory corruption. Flipping the image instead of using absolute pitch will break the test in patch 2.
Patch 3 contradicts to what MS docs says [1] for MFCreate2DMediaBuffer, fBottomUp parameter: "If TRUE, the buffer's IMF2DBuffer::ContiguousCopyTo method copies the buffer into a bottom-up format.". That doesn't match the tests in patch 2. So far I see that fBottomUp parameter only affects what is returned from Lock2D as scanline0 and pitch. Thinking of it, the behaviour of ContiguousCopyFrom makes some sense to me as Lock2D (unlike Lock which converts to contiguous buffer) is not supposed to perform any copies and flips and return the underlying representation as is. And once scanline0 and pitch for that 2d buffer indicate it should be copied bottom up additionally flipping when converting from contiguous buffer wouldn't make much sense. Then, ContiguousCopyTo could flip it actually as the docs suggest, but the test seems to clearly show that it doesn't happen (there is a separate test for clarity showing that ContiguousCopyFrom / ContiguousCopyTo yields the same data).
1. https://learn.microsoft.com/en-us/windows/win32/api/mfapi/nf-mfapi-mfcreate2...