10 bits output is not actually P010

[BMart1]

According to https://docs.microsoft.com/en-us/windows/desktop/medfound/10-bit-and-16-bit-yuv-video-formats P010 stores values left shifted 6 bits, as if the values were originally 16 bits, but Intel Media SDK doesn't shift the values.  Bot HW and SW decoding in kaby lake behave the same.  https://software.intel.com/en-us/forums/intel-media-sdk/topic/731469 mentions that HW decoding used to be correct. Repro:

curl http://jell.yfish.us/media/jellyfish-3-mbps-hd-hevc-10bit.mkv --output jelly.mkv
ffmpeg -i jelly.mkv -vcodec copy -an -bsf hevc_mp4toannexb -vframes 1 jelly.265
simple_decode_hevc10.exe jelly.265 mfx.yuv
ffmpeg -i jelly.265 -pix_fmt p010le p010le.yuv
ffmpeg -i jelly.265 -pix_fmt yuv420p10le yuv420p10le.yuv
ffmpeg -i jelly.265 -pix_fmt yuv420p16le yuv420p16le.yuv

mfx.yuv should equal p010le.yuv but actually equals yuv420p10le.yuv (the Y plane is identical but mfx.yuv interleaves U/V like NV12 and yuv420p10le.yuv stores all Us before all Vs).  As expected the Y plane of yuv420p16le.yuv equals the Y plane of p010le.yuv, while the later interleaves U/V.

Bruno

[BMart1 · Accepted solution]

I just solved this: mfxFrameInfo::Shift (a bool) indicates whether the 10 bits are stored as the least or most significant bits in the whole 16 bits. HW uses the most significant bits and SW the least. The tutorials scale the values for HW before writing to disk.