There seems to be something weird with the YUV format used by the Intel MSDK decoder. I have a conversion routine based on Microsoft's definition of the format:
"A format in which all Y samples are found first in memory as an array of unsigned char with an even number of lines (possibly with a larger stride for memory alignment), followed immediately by an array of unsigned char containing interleaved Cb and Cr samples (such that if addressed as a little-endian WORD type, Cb would be in the LSBs and Cr would be in the MSBs) with the same total stride as the Y samples. This is the preferred 4:2:0 pixel format."
Note the format says that the UV samples follow immediately after the Y samples. Therefore, I would expect the following to be true:
outSurface->Data.U - (outSurface->Data.Y + outSurface->Data.Pitch * outSurface->Info.Height) == 0
However this is not the case! Using two different test 1280x720 videos, there's an offset of 16 rows or 20480 bytes between the end of the Y samples and the start of the U samples. When I convert to RGB I get a 16-pixels wide band of green pixels at the top and the colors are all offset from the black and white values.
Moreover, I inspected the data in the debugger, and the gap between the Ys and UVs is just 0s.
I understand that I could use the UV pointer to obtain the UV location, but I've already got quite a bit of code in different places that assumes that an NV12 buffer is (3 * Height * Stride / 2) bytes which doesn't hold with these extra bytes there and it's going to be somewhat painful to change all that. Is there anything me or the Intel MSDK is doing wrong?