<div dir="ltr"><div>Peter,<br><br>interesting benchmark, do you have fps benchmarks also taking memory accessing into account?<br><br></div>Did you need to modify Makefiles / compiler settings much, and if so, are you able to share these modifications?<br><br>Regards,<br><br>Leon<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 4, 2014 at 5:12 AM, Peter Lawrence <span dir="ltr"><<a href="mailto:majbthrd@gmail.com" target="_blank">majbthrd@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I wanted to share some possibly interesting x264 benchmark numbers for a processor that I couldn't find any previous mention of on the mailing list.<br>
<br>
I've been porting x264 to run on an ARM Cortex-M4 (ARMv7E-M instruction set) to determine how viable it would be for low resolution, low frame rate applications. The following figures might be of interest to someone contemplating the same notion.<br>
<br>
The Cortex-M4 does have some DSP instructions that are nowhere near as useful as NEON is for x264, but might offer some small increase in performance. (For example, dual 16-bit multiplies and additions per instruction.) However, these tests are just with the generic C code without using any processor-specific optimizations (other than the one for endian_swap32).<br>
<br>
Source material is the "carphone" video sequence at QCIF (176 x 144) in I420 format.<br>
<br>
x264 presets are "ultrafast" plus "zerolatency"; profile is "baseline".<br>
<br>
I wanted to see if defeating the chroma encoding would save an appreciable amount of CPU time. To my surprise, it actually seems to make it worse.<br>
<br>
Given these parameters:<br>
<br>
param.i_bitrate = 80,<br>
param.rc.i_vbv_max_bitrate = 80<br>
param.rc.i_vbv_buffer-size = 100<br>
param.rc.i_rc_method = X264_RC_ABR<br>
<br>
Here is how many million processor clock cycles were consumed for each of the first ten frames of the "carphone" video sequence:<br>
<br>
chroma ostensibly defeated (and analyse.b_chroma_me = 0)<br>
22 27 26 30 30 27 30 29 31 31<br>
<br>
default mode<br>
24 18 20 21 22 22 26 22 27 25<br>
<br>
(For default mode with analyse.b_chroma_me = 0, the numbers are essentially those shown for "default mode".)<br>
<br>
That disabling chroma made things worse made no sense to me. Then, I excitedly thought perhaps disabling it freed enough bits to cause the rate control to reduce the quantization and thus decrease the number of zeros in the DCT (perhaps increasing the complexity for the VLC encoder), so I tried another test in constant quality mode:<br>
<br>
param.rc.qp_constant = 37<br>
param.rc.i_rc_method = X264_RC_CQP<br>
<br>
Here is how many million processor clock cycles were consumed for each of the first ten frames of the "carphone" video sequence:<br>
<br>
chroma ostensibly defeated (and analyse.b_chroma_me = 0)<br>
18 22 23 23 23 22 22 22 23 24<br>
<br>
default mode<br>
20 16 13 16 15 14 17 16 18 19<br>
<br>
So, under this (flawed?) test setup, it seems worse to defeat chroma in both rate control scenarios.<br>
<br>
The output bitstream with chroma ostensibly defeated is marginally smaller (9238 bytes versus 9262 bytes) in the constant quality mode. (Comparing file sizes in a rate control mode seemed pointless, since the rate control should rightfully use any spare bits.) Moreover, the output supposedly without chroma decodes in Video Lan Client as grayscale images (versus color for the normal mode).<br>
<br>
Surely my method of defeating chroma must be flawed. I did it by forcing "chroma" to zero inside x264_macroblock_encode_<u></u>internal(), which *looked* like it would disable computing the chroma DCTs and generation of the associated VLC coding.<br>
<br>
Specifics of the test environment are:<br>
<br>
Target is a STM32F429 Discovery Kit (180MHz STM32F429 with 8MBytes of SDRAM).<br>
<br>
The code is running on "bare-metal" (e.g. not some Linux "embedded" application).<br>
<br>
I needed practically all of the 8MBytes of SDRAM to hold all the x264 data structures. The STM32F429 has a sizable 2MBytes of flash, so I used the upper 1MByte to store 27 frames of the "carphone" video sequence and the lower half for code storage. (The video frames were memcpy-ed from flash to the x264_picture_t structure prior to each x264_encoder_encode() call, rather than accessing them directly in place.)<br>
<br>
Code was compiled using Clang v3.4.1 (-O1 optimization) in the Rowley Crossworks for ARM development environment.<br>
<br>
______________________________<u></u>_________________<br>
x264-devel mailing list<br>
<a href="mailto:x264-devel@videolan.org" target="_blank">x264-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x264-devel" target="_blank">https://mailman.videolan.org/<u></u>listinfo/x264-devel</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Leon
</div>