Log in

View Full Version : hevcasm: a collection of permissively licensed assembler optimisations for HEVC


Parabola
2nd July 2014, 13:07
hevcasm: A collection of permissively licensed assembler optimisations for HEVC decoders and encoders

TLDR: don't get too excited, the project is on github (https://github.com/kupix/hevcasm) but it's empty!

Currently, like most other HEVC bitstream analysers, our commercial product "Parabola Explorer" uses HM for image decoding. This is slower and less flexible than we'd like. We also have our own specialised HEVC parser but only recently started optimising it for decoding. Several DSP routines now use Yasm/x86inc style and we are (slowly) writing more asm.

We would really like to share our work and invite others who'd join in aggregating optimisations under a permissive license. It seems crazy that every codec, open or closed, must re-implement this stuff.

The project will have a C-language wrapper that will form a library with optimised and unoptimised versions of all the functions and cpuid/dispatch. We're a C++11 house but are also pragmatists and appreciate that C99 is probably the highest common factor in this application. Encoder and decoder projects will be able to pull primitives from our library as function pointers (or tables of function pointers) and need not worry too much about optimisation.

Codec primitive function prototypes are often virtually identical between projects so we hope this library can be shared between many if not all of the various open-source HEVC encoder and decoder projects. I think there are at least half a dozen of these. This doesn't preclude said dependent projects having their own, specialised asm too.

Assuming critical mass achieved, I would hope that Intel and AMD might be motivated to contribute as this project could become a single place where they could influence HEVC performance in multiple codecs on their platforms.

For licensing, we're planning on using the lowest-common-factor for maximum uptake so propose BSD or a similar permissive license. I'm really hoping I'm not going to start an open-source-license advocacy flame thread.

The first step is boilerplate and that is the reason for this post. Autotools vs Cmake vs Scons vs nothing? What are good examples of boilerplate for a modern C/Yasm library+test executable?

Thoughts?

--John :)

Procrastinating
5th July 2014, 06:16
I'm all for it if it allows developers to more rapidly develop encoders in the future. The touch part will be encouraging developers to start bringing their code over initially.