avif
avif copied to clipboard
joedrago
Any plan to boost the AVIF encoding speed ? It's too slow for large images comapred to HEIF (libheif)
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
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
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.
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.
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.
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:
- Upgrade the aom dependency to the newest commit or tagged release ?
- Try to optimize the code which invode aom API ?
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
