[FFmpeg-devel] [PATCH] 8-bit hevc decoding optimization on aarch64 with neon

Rafal Dabrowa fatwildcat at gmail.com
Tue Nov 21 16:24:23 EET 2017

On 11/21/2017 11:51 AM, Shengbin Meng wrote:
>> On 19 Nov 2017, at 01:35, Rafal Dabrowa <fatwildcat at gmail.com 
>> <mailto:fatwildcat at gmail.com>> wrote:
>> This is a proposal of performance optimizations for 8-bit
>> hevc video decoding on aarch64 platform with neon (simd) extension.
> Nice to see the work for aarch64!
> We are also in the process of doing NEON optimization for HEVC 
> decoding. 
> (http://ffmpeg.org/pipermail/ffmpeg-devel/2017-October/218233.html)
> Now we are just about to finish arm 32-bit work and ready to send some 
> patches out. Looks like for aarch64 we can join force:) What do you think?
Why not. I started to work on aarch64 because my device, although has 
VPU, but the VPU does not support hevc. Hence the h264 format, even full 
HD one is played smoothly but playback of hevc looks poorly. I was 
curious how much hevc decoding might be optimized. I optimized one 
function, then another one...

Currently I'm focused on patch size reduction. But I'm open to cooperation.

>> The patch contains optimizations for most heavily used qpel, epel, 
>> sao and idct
>> functions.  Among the functions provided for optimization there are two
>> intensively used, but not optimized in this patch: 
>> hevc_v_loop_filter_luma_8
>> and hevc_h_loop_filter_luma_8. I have no idea how they could be optimized
>> hence I leaved them without optimizations.
> I see that optimization for loop filter already exists for arm 32-bit 
> code. Why not use that algorithm?

Maybe... Although optimization for aarch64 is a different story. I have 
noticed that gcc with -O3 option on aarch64 produces really good code. I 
was surprised how much the code execution time is reduced in some cases. 
Sometimes it is hard to optimize code better than compiler does.

Rafal Dabrowa

More information about the ffmpeg-devel mailing list