HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
AOMediaCodec
libavif
C2020–2026
AOMediaCodec / libavif

libavif

libavif - Library for encoding and decoding .avif files

10Distinct people
15Mentions
0Explicit recommenders
2.2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

libavif - Library for encoding and decoding .avif files

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year15 dated mentions

Observed mentions: 2020-06-23 14:59:31 UTC to 2026-10-16 19:16:11 UTC.

012342020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC303
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC303
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC413
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC202
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC000
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC202

What Hacker News says

15 sources
Odd, what are you using to create your avif's? I've done a bunch of work with them and the AVIF's were almost always significantly smaller than webp at equal or better quality. Encoding is a pain, to be sure; I ended up creating a workflow where my source would save things as PNG files (giant, but lossless) then running a avifenc (https://github.com/AOMediaCodec/libavif) to produce the avif, and trashing the PNG. Decoding though, all browsers have support, it's great.
In I guess I'm using WebP now?
> Have you seen this more recent data that includes AVIF? https://cloudinary.com/labs/cid22 The graph from Cloudinary uses libaom to do the encoding at speed preset 7 (aom s7), which is far from speed preset 0 and disables many AVIF coding tools. I do not know why this was chosen by the author, but it does not reflect AVIF performance. According to https://github.com/AOMediaCodec/libavif/issues/440#issuecomm... speed preset 8 loses 20-35% compression efficiency.
In JPEG XL and Google's War Against It
It's 2023, surely this is not yet another bug related to memory unsafety that could be avoided if we'd stop writing critical code that deals with extremely complex untrusted input (media codecs) in memory unsafe languages? Yep, of course it is: https://github.com/webmproject/libwebp/commit/902bc919033134... I guess libwebp could be excused as it was started when there were no alternatives, but even for new projects today we're still committing the same mistake[1][2][3]. [1] -- https://code.videolan.org/videolan/dav1d [2] -- https://github.com/AOMediaCodec/libavif [3] -- https://github.com/AOMediaCodec/libiamf Yep. Keep writing these in C; surely nothing will go wrong.
In Chrome: Heap buffer overflow in WebP
So a few dozen comments, but so far it doesn't look like any mention the immediate thing that jumped out at me which was the claims vs AVIF: >"In turn, what users will be given is yet another facet of the web that Google itself controls: the AVIF format." Huh? I'll admit I haven't been following codecs as super ultra closely as I used to, but I thought AOM was a pretty broad coalition of varying interests and AV1 an open, royalty free codec that was plenty open source friendly? I've heard plenty of reasonable arguments that JPEG XL has some real technical advantages over AVIF and as well as superior performance is much more feature rich and scalable. So I could see people being bummed for that. But this is the first time I've heard the assertion that it's somehow a Google project? I mean, AOM's libavif reference is BSD too [0]? I'd love s
Read the rest
ome more details on that from anyone who has been following this more closely. I can even understand if AOM isn't as community friendly and an accusation that it's dominated by big corps, but in that case why single out Google alone? From wiki: >The governing members of the Alliance for Open Media are Amazon, Apple, ARM, Cisco, Facebook, Google, Huawei, Intel, Microsoft, Mozilla, Netflix, Nvidia, Samsung Electronics and Tencent. Like, Google is certainly significant, but that's a lot of equally heavy hitters. And interesting that Mozilla is there too. ---- 0: https://github.com/AOMediaCodec/libavif
In FSF Slams Google over Dropping JPEG-XL in Chrome
To everyone who is interested, here is a part of my .shrivel.json including command line tools and parameters to shrink different kind of image formats (shrivel[1] is a task runner for shrinking images using command line tools, I recently built for my blog[2], unfortunately without release yet). "commands": { "svgo": ["/home/sandreas/.npm-packages/bin/svgo", "--multipass", "{source}", "-o", "{destination}"], "vips": ["vipsthumbnail", "{source}", "-s", "{size}", "-f", "{destination}[strip]", "--eprofile", "/usr/share/color/icc/colord/sRGB.icc", "--rotate", "--delete"], "vips_jpg": ["vipsthumbnail", "{source}", "-s", "{size}", "-f", "{destination}[optimize_coding,strip]", "--eprofile", "/usr/share/color/icc/colord/sRGB.icc", "--rotate", "--delete"], "vips_lossless": ["vipsthumbnail", "{source}", "-s", "{size}", "-f", "{des
Read the rest
tination}[strip]", "--eprofile", "/usr/share/color/icc/colord/sRGB.icc", "--rotate", "--delete"], "cwebp": ["cwebp", "-resize", "{size}", "0", "-q", "75", "{source}", "-o", "{destination}", "-quiet"], "docker-avifenc": ["docker", "run", "--rm", "-u", "1000:1000", "-v", "/home/sandreas/projects/pilabor/:/mnt", "shrivel", "avifenc", "--jobs", "all", "--min", "0", "--max", "63", "--yuv", "420", "-a", "end-usage=q", "-a", "cq-level=28", "-a", "tune=ssim", "--ignore-icc", "--speed", "0", "{source}", "{mappedDestination}"], "jpegoptim": ["jpegoptim", "--max=75", "--all-progressive", "--strip-all", "{destination}"], "pngquant": ["pngquant", "--quality", "70-99", "--skip-if-larger", "--quiet", "--ext", ".png", "--force", "{destination}"] }, Summary: - use svgo for svg compression - use vipsthumbnail instead of imagick (way faster) - use resized lossless png images as source for avifenc, since it does not support resize atm[3] - use cwebp or avif images wherever possible - use use avifenc with fine graned params (I use docker, beause avifenc did not compile on my server) - use jpegoptim to optimize jpegs inplace - use pngquant to optimize pngs inplace ("--ext .png --force") - for gifs I would use gifsicle, but I don't have gifs Then remove avif files with size > webp files (this can happen on smaller dimensions). And here is my according html snippet: <!-- wrapper element --> <picture> <!-- avif srcset: 1x, 2x, 3x as auto select higher quality images for higher screen resolutions --> <source srcset="/img/articles/iphone-3566282_235.avif 1x, /img/articles/iphone-3566282_235@2x.avif 2x, /img/articles/iphone-3566282_235@3x.avif 3x" type="image/avif"> <!-- webp srcset --> <source srcset="/img/articles/iphone-3566282_235.webp 1x, /img/articles/iphone-3566282_235@2x.webp 2x, /img/articles/iphone-3566282_235@3x.webp 3x" type="image/webp"> <!-- jpeg also as srcset to provide screen resolution based images --> <source srcset="/img/articles/iphone-3566282_235.jpg 1x, /img/articles/iphone-3566282_235@2x.jpg 2x, /img/articles/iphone-3566282_235@3x.jpg 3x" type="image/jpeg"> <!-- fallback image with loading=lazy, to load images only when visible --> <img src="/img/articles/iphone-3566282_235.jpg" alt="Access and recover files from an iPhone on Linux" title="Access and recover files from an iPhone on Linux" loading="lazy" class="size-235 raster ext-jpg" width="235" height="129"> </picture> [1]: https://github.com/sandreas/shrivel [2]: https://pilabor.com [3]: https://github.com/AOMediaCodec/libavif/issues/1034
In Losslessly Optimising Images

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.