ARM Community: x264 on ARM: Bringing a wider application of video conferencing (Part 2) - ARM Community

In part one of this series, we introduced the video encode requirement and target development environment. In this part, we start by examining benchmarking result of h.264 encode using x264 on a development host rather than the ARM target. This enables us to perform some initial tuning of the encode settings for our target use case of video conferencing.

1 Benchmarking
For video conferencing, we want low bit rate, but at the same time we must maintain at least a 15 fps frame rate so that video quality is acceptable. So we focus on balancing bit rate, frame rate and video quality when investigating the performance of x264 encoder. In x264, there are many options for enabling and tuning the performance of the encoder. So we test the various combinations and evaluate resultant bit rate and video quality. Since relative bit rate and video quality are facets of the encode algorithm and independent of the hardware platform, we first test x264 using our desktop development host.

1.1 Bit rate and video quality testing
1) Description
We test the different combinations of options which x264 support. We focus on bit rate, frame rate and video quality. Video quality is measured by PSNR (Peak Signal-To-Noise Ratio). PSNR is most commonly used as a measure of quality of reconstruction of lossy compression codec. Normally a higher PSNR would indicate that the reconstruction is of higher quality.

2) Platform information:


1.1.1 Test Result of option (x264 support)

1.1.1.1 Selected options
In x264, there are many options. We chose the following options to investigate, which significantly impact bit rate, frame rate and quality


1.1.1.2 me
This option is used to set the full-pixel motion estimation method. There are five choices:
1). List of option


2). Result

3). Conclusion
According to the test above, we can summarize: “dia” is the simplest search method. Its operations are the minimum, but its bit rate is a little higher than others. “tsea” is the most complex search method. Its operations are the maximum, and it improves the bit rate only a little.

1.1.1.3 rc-lookahead
This option is used to set number of frames for frame type look ahead. Increasing the frame count generates better results, but is also slower.
1). List of option


2). Result


3). Conclusion
According to the data above, we can summarize: when rc-lookahead is set to 1, the bit rate is the minimum. At the same time, the frame rate is the maximum.

1.1.1.4 ref
This option is used to set the number of reference frames. This option controls the size of the DPB (Decoded Picture Buffer). The range is from 0-16. In short, this value is the number of previous frames each P-frame can use as references. (B-frames can use one or two fewer, depending on if they are used as references or not.) The minimum number of refs that can be referenced is 1.
1). List of option


2). Result


3). Conclusion
According to the data above, we can summarize: when the number of reference frames is set to 1, the frame rate is the maximum, but bit rate is higher.

1.1.1.5 subme
This option is used to set the subpixel estimation complexity. Higher numbers mean better video quality. Levels 1-5 simply control the subpixel refinement strength. Level 6 enables RDO for mode decision, and level 8 enables RDO for motion vectors and intra prediction modes. RDO levels are significantly slower than the previous levels. Using a value less than 2 will enable a faster and lower quality look ahead mode.
1). List of option


2). Result


3). Conclusion
According to the data above, we can summarize: when subme is set to 0, the frame rate is the maximum; but bit rate is higher. We’ll need to find the trade-off between bit rate and frame rate.

1.1.1.6 preset
This option is used to trade off compression efficiency against encoding speed.
1). List of option


2). Result


3). Conclusion
According to the data above, we can summarize: “veryfast” mode has higher frame rate and lower bit rate than the default.

1.1.2 Testing Combined Settings
According to the result of the previous discrete tests, we tune the combination of options based on "--preset veryfast", which results in our optimal settings to use for video conferencing.

1). List of Combinations Tested


2). Result


In the next blog entry we examine the impact of our optimal settings on target ARM hardware and continue to tune x264 settings for a balanced mix between bit rate, frame rate and underlying hardware capabilities.

Blog Series: x264 on ARM: Bringing a wider application of video conferencing
Part 1

Yang Zhang, Home Software engineer - Home Software Enabling team, ARM, Yang has several years of experience working on projects related to video codec, including H.264/AVC, H.263, MPEG4, MPEG2, VC-1 and AVS. She has a deep understanding of video codec algorithm. Being Home Software Engineer , she specializes in the digital multimedia system for ARM Home. Yang graduated from Zhejiang University with the degree of Master. She is currently based in Shanghai, China.

张洋(Yang Zhang) 是ARM的家庭软件工程师. 她拥有多年工作经验并致力于视频编解码领域， 曾经参与了H.264/AVC, H.263, MPEG4, MPEG2, VC-1和AVS等相关项目的开发， 深入理解视频编解码算法。作为家庭软件工程师，她专注于和家庭相关的ARM数字多媒体系统架构技术。 Yang 硕士毕业于浙江大学。 她的工作地点在中国上海.