i.MX6 VPU H.264 Encoder Quality Issues

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX6 VPU H.264 Encoder Quality Issues

Jump to solution
3,912 Views
chuck1
Contributor III

OS is: Yocto Project Linux 3.10.17

BSP is: apalis_imx6-angstrom-linux-gnueabi

IMX VPU library is: imx-vpu-3.10.17-1.0.0

To all of you VPU mavens out there,

I'm having difficulty setting up then running the VPU H.264 encoder in that the quality of the H.264 video encoded with the simple, single-threaded 'C' program that I have written.  Although I have lots of experience with the codecs for the Texas Instruments DaVinci family of digital media processors, I'm new to the i.MX6 and how to setup the H.264 encoder for the VPU.

Workflow:

BigBuckBunny_640x360.yuv (I420 YUV) file —> VPU H.264 encode —> BigBuckBunny_640x360.h264 file —> VLC player

Result:

When the GOP size = 1 or 2, i.e.,  IIII or IPIP..., the H.264 ES video quality is normal, i.e., I see some noisy macro-blocks in high motion areas but nothing that I consider problematic.  However, whenever GOP size > 2, the resulting H.264 ES video quality is unacceptable, e.g., I see areas, in a sequence of video frames, where a large group of contiguous macro-blocks—10% of the scene area or more—have incorrect YUV values relative to the surrounding scene such that the resulting video is unwatchable.  In addition, some sequences of video frames show missing macro-blocks as well as macro-block "tearing" around the edges of visual objects.

Things I've Tried / Looked Into:

   1. The YUV source file, i.e., BigBuckBunny_640x360.yuv with a YUV analysis tool and see that it is pristine.

   2. The versions of VLC are 2.0.8 on Ubuntu Linux 12.04 and 2.1.15 on OS X—video quality is the same on both.

   3. A huge number of different (reasonable) combinations of VPU H.264 encoder setup / operating parameters including

       bit rate, GOP size, QPMin / QPMax parameters, etc.

Except for changing the GOP size to either 1 or 2, nothing helps: what am I missing?  I hope the problem is a basic cockpit error so, hopefully, someone in the community can see the error(s) I've made.

Thanks,

-Chuck

Tags (2)
0 Kudos
Reply
1 Solution
1,296 Views
chuck1
Contributor III

All,

This issue was resolved by using the VPU test application as a pattern—importantly, video input and output frame buffers must be allocated properly—with this change I am now able to read a 1920x1080 YUV file, encode to H.264, and write the resultant video frames to a file while consuming between 15 - 20% of the processing power of (I assume, one core) the i.MX6 CPU.  Also, the quality of the H.264 encoded video is excellent when played back using VLC.

-Chuck

View solution in original post

0 Kudos
Reply
2 Replies
1,297 Views
chuck1
Contributor III

All,

This issue was resolved by using the VPU test application as a pattern—importantly, video input and output frame buffers must be allocated properly—with this change I am now able to read a 1920x1080 YUV file, encode to H.264, and write the resultant video frames to a file while consuming between 15 - 20% of the processing power of (I assume, one core) the i.MX6 CPU.  Also, the quality of the H.264 encoded video is excellent when played back using VLC.

-Chuck

0 Kudos
Reply
1,296 Views
endl
Contributor II

Hello, Charles

I think that for testing encoder quality with constant QP you should set this parameters:

bitRate = 0;

userQpMinEnable = 0;

userQpMaxEnable = 0;

RcIntervalMode = 0;

quantParam = VPU_DEFAULT_H264_QP;

Note: quantParam is used for all quantization parameters in case VBR (no rate control). When rate control is enabled, this field is ignored.