Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor II
158 Views

10 bits output is not actually P010

Jump to solution

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

0 Kudos

Accepted Solutions
Highlighted
New Contributor II
158 Views

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.

View solution in original post

0 Kudos
1 Reply
Highlighted
New Contributor II
159 Views

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.

View solution in original post

0 Kudos