I believe that the uncompressed 4:2:0 output of the sample_decode project is not as described at http://www.fourcc.org/yuv.php#NV12 or as descibed in the IPP documentation (consistent with the description at fourcc). The output is actually three planes: a Y, followed by a U then a V plane. Not (as described in the documentation) a Y plane followed by a lane of interleaved U/V samples.
Can someone confirm this?
PS - This may be the issue with using the ipp resize as in a previous post.
Hi,
The Intel Media SDK NV12 format matches exactly the well established http://www.fourcc.org/yuv.php#NV12 format.
NV12 is a hybrid planar format consisting of a Y plane, followed by a UV plane (interleaved U, V chroma values).
You seem to be referring to YV12 format which is a pure planar format consisting of Y,V and U planes separately.
Regards,
Petter
Hi Petter, thanks for the quick response.
My issue is that the sample_decode project that is distributed with the Intel mediaSDK is decoding the H264 streams into the YV12 format rather than the NV12 format.
I recorded a Red only mp4 video using a video signal generator(1920x1080 frames), split it into an elementary stream with Yamb, then ran it through the sample_decode program.
The output clearly shows separate planes for the U and the V. I've attached files from hexedit to show the transitions for the first frame.
(Note the offsets are off by 8 bytes b/c I modified sample_decode to write the width and height of the frame at the beginning of the output).
| Anhang | Größe |
|---|---|
Herunterladen  EndYstartU.jpg | 389.31 KB |
| Herunterladen EndUStartV.jpg | 390.49 KB |
Hi,
The reason you're getting YV12 format output from "sample_decode" is purely for convenience. YV12 is a much more common raw format for sharing raw image content, and many YUV viewers support it. NV12 is not commonly supported by YUV tools.
If you need NV12 to be written to file instead just change the file writer class and remove the NV12->YV12 conversion, instead implementing a writer for NV12 directly.
Note that "sample_encode" supports both NV12 and YV12 (default) raw input.
Regards,
Petter
Thanks Petter - rt*m on my part. Note 2 in the readme-decode.rtf specifies this!
