Skip to content
This repository has been archived by the owner on Jul 30, 2019. It is now read-only.

Any plan to boost the AVIF encoding speed ? It's too slow for large images comapred to HEIF (libheif) #11

Open
dreampiggy opened this issue Jun 11, 2019 · 5 comments

Comments

@dreampiggy
Copy link

dreampiggy commented Jun 11, 2019

I know that this library is used for experience and is work-in-progress. But current tagged release v1.0.3, the encoding speed seems too slow. Even I setup to use the 2/4/8 threads for encoding.

The encoding speed is now 100x slower than other image format such as WebP (libwebp) or HEIF (libheif), for even 512*512, 24 Bits images. You can use this demo image to test on the HEIF and PNG compression, using the tool colorist

lena-512x512-avif.zip

The encoding speed runnnig on mobile iOS system is worse. Here is a simple codec plugin for iOS framework SDWebImageAVIFCoder, which have to mention this encoding speed, which means the AVIF encoding maybe not usable for users. However, the decoding speed is acceptable.

Test result:

<Decode> [PNG]: Time: 1.43 ms
<Decode> [JPEG]: Time: 0.39 ms
<Decode> [HEIC]: Time: 1.47 ms
<Decode> [HEIF]: Time: 102.06 ms
<Decode> [WebP]: Time: 24.00 ms
<Decode> [BPG]: Time: 39.60 ms
<Decode> [FLIF]: Time: 364.84 ms
<Decode> [AVIF]: Time: 154.54 ms
<Encode> [PNG]: Time: 39.63 ms
<Encode> [JPEG]: Time: 2.46 ms
<Encode> [HEIC]: Time: 65.51 ms
<Encode> [HEIF]: Time: 1799.63 ms
<Encode> [WebP]: Time: 168.42 ms
<Encode> [BPG]: Time: 2761.79 ms
<Encode> [FLIF]: Time: 6160.68 ms
<Encode> [AVIF]: Time: 346592.24 ms

"HEIC" means using Apple's built-in HEVC codec, "HEIF" means using libheif
@joedrago
Copy link
Owner

Hello!

libavif is responsible for BMFF reading/writing and some simple color math. Behind the scenes, libavif is simply invoking the AOM AV1 encoder, and its performance isn't really the scope of this project. I imagine they are making efforts to speed it up, but if you want to discuss this, I recommend making an issue with that project instead.

I will periodically update libavif to point at more and more recent builds of AOM as they polish it.

@joedrago
Copy link
Owner

You know, as a second note, there's a chance the Homebrew build for colorist has been building a non-Release variant for a bit (I'm not positive), which would significantly impact AV1 performance.

I've updated colorist to v0.0.44 which incorporates libavif v0.1.4, which incorporates AV1 encoder changes up to about 3 hours ago. I've also made sure Homebrew's colorist is making a release build.

Perhaps give one more pass with colorist v44 and see? There's a chance there is 0 difference, but enough variables changed here that I'm curious.

@joedrago joedrago reopened this Jun 11, 2019
@joedrago
Copy link
Owner

Also, I haven't exposed tiling options in either libavif or colorist, which allows the encoder to multithread much more nicely, at the (potential?) cost of a larger filesize at the end. I'm running tests now, but I'll probably expose this kind of thing soon as well.

@dreampiggy
Copy link
Author

dreampiggy commented Jun 12, 2019

Yes...The performance issue is mainly because of aom project.

I use another AVIF library in libheif avif branch. And use the same aom commit to test. It looks like their code can a little faster than current libavif.

And the libheif-avif support just use 100% CPU with one single thread.

See the result for same test:

<Decode> [PNG]: Time: 0.65 ms
<Decode> [JPEG]: Time: 0.32 ms
<Decode> [HEIC]: Time: 26.11 ms
<Decode> [HEIF]: Time: 103.01 ms
<Decode> [WebP]: Time: 18.84 ms
<Decode> [BPG]: Time: 29.75 ms
<Decode> [FLIF]: Time: 365.86 ms
<Decode> [AVIF]: Time: 156.47 ms
<Encode> [PNG]: Time: 43.70 ms
<Encode> [JPEG]: Time: 10.31 ms
<Encode> [HEIC]: Time: 144.58 ms
<Encode> [HEIF]: Time: 1781.97 ms
<Encode> [WebP]: Time: 167.17 ms
<Encode> [BPG]: Time: 2721.76 ms
<Encode> [FLIF]: Time: 6230.68 ms
<Encode> [AVIF]: Time: 227814.74 ms

Their speed is still slow (227814.74 ms), but compared to libavif(346592.24 ms) is a little faster, even they use the same aom dependency. Their code is here heif_encoder_aom.cc

Maybe we can do two things:

  1. Upgrade the aom dependency to the newest commit or tagged release ?
  2. Try to optimize the code which invode aom API ?

@theandrewbailey
Copy link

If you're looking for speed, it might be easier to replace libaom with rav1e, though I'm not sure what state their C API is in (looks like they're still making it).

https://github.com/xiph/rav1e

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants