3 ms·
You can't fault MS for [their documentation](https://docs.microsoft.com/en-us/windows/win32/api/mfobjects/nf-mfobjects-imfmediabuffer-lock#remarks https://docs.
by Diggsey 6y ago
You can't fault MS for [their documentation](https://docs.microsoft.com/en-us/windows/win32/api/mfobjects/nf-mfobjects-imfmediabuffer-lock#remarks https://docs.microsoft.com/en-us/windows/win32/api/mfobjects...)...
> This method may internally allocate some memory, so if the buffer supports the IMF2DBuffer interface, you should use the IMF2DBuffer::Lock2D method to lock the buffer instead. For 2-D buffers, the Lock2DSize method can be more efficient than the Lock method, depending on the MF2DBuffer_LockFlags value you specify. Calling Lock2DSize with MF2DBuffer_LockFlags_Read won’t incur a copy back when the buffer is unlocked and calling it with MF2DBuffer_LockFlags_Write won’t incur a copy from the internal buffer. Calling Lock2DSize with LockFlags_ReadWrite behaves the same as Lock and Lock2D and will incur a both copy from and copy back when unlocked. The general guidance for best performance is to avoid using IMFMediaBuffer and IMF2DBuffer whenever possible and instead use IMF2DBuffer2 with the minimum required lock flags. Note that if the buffer is locked using Lock2D, the Lock method might return MF_E_INVALIDREQUEST.
- LegionMammal978 6y agoIt looks like that was added in response to this issue. See comment 1 on the Chromium issue[0] and the associated PR on the documentation[1]. [0]: https://bugs.chromium.org/p/chromium/issues/detail?id=1071180 https://bugs.chromium.org/p/chromium/issues/detail?id=107118... [1]: https://github.com/MicrosoftDocs/sdk-api/pull/207 https://github.com/MicrosoftDocs/sdk-api/pull/207