The AV2 Video Standard Has Released (Final v1.0 Specification)

Post by circuit10 » Mon, Jun 01, 2026, 11:08 AM UTC

sylware wrote: post #167

circuit10 wrote: post #132

Earlier quoted context omitted.

Screen recording is not niche, anyone who works remotely probably does video calls daily and the others are somewhat more niche but I'd guess that at least 50-70% of people do at least one of these things

I think, screen recording is ultra-niche, and I don't know why, I feel better when I know my OS is unable to do just that. (As a side project, I am writting my walyand compositor, and I know that if it supports screen recording, that's going to be something certainly hacky and I can disable at compile time).

Post by BoingBoomTschak » Mon, Jun 01, 2026, 4:15 PM UTC

ChadNauseam wrote: post #165

BoingBoomTschak wrote: post #118

Earlier quoted context omitted.

I really don't. 1. Lossless AVIF is a joke often beaten by WebP and even PNG. Even worse for grayscale. 2. Chroma subsampling remains a bad idea for still images unless the resolution is high enough to hide the artifacts. 3. Tooling is the worst part, AV1 encoders are basically focused 99% on video and leave a measly 1% to image; unlike JXL, of course. SVT-AV1 still doesn't do YUV444 and libaom was unusable. Fortunat…

> 2. Chroma subsampling remains a bad idea for still images unless the resolution is high enough to hide the artifacts. Hmm, I don't think so. I think at a fixed file size, chroma subsampling usually allows you to have fewer noticeable artifacts. Humans are so much more sensitive to luma that it doesn't make sense to treat it equally to chroma with respect to lossy compression. That said, if you don't like it, AVIF s…

Post by BoingBoomTschak » Mon, Jun 01, 2026, 4:39 PM UTC

BoingBoomTschak wrote: post #173

ChadNauseam wrote: post #165

Earlier quoted context omitted.

> 2. Chroma subsampling remains a bad idea for still images unless the resolution is high enough to hide the artifacts. Hmm, I don't think so. I think at a fixed file size, chroma subsampling usually allows you to have fewer noticeable artifacts. Humans are so much more sensitive to luma that it doesn't make sense to treat it equally to chroma with respect to lossy compression. That said, if you don't like it, AVIF s…

> Hmm, I don't think so. I think at a fixed file size, chroma subsampling usually allows you to have fewer noticeable artifacts At low bpp, certainly. Though "certainly" is to be quantified since chroma is quite cheap in AV1, thanks to CfL. > Humans are so much more sensitive to luma that it doesn't make sense to treat it equally to chroma with respect to lossy compression The problem is that this is completely depen…

  $ real_time() { command time -p sh -c '{ "$@"; } 2>&3 >&2' argv0 "$@" 3>&2 2>&1 | sed -n 's#^real ##p'; }
  $ magick identify DSC00191.ppm
  DSC00191.ppm PPM 5492x3672 5492x3672+0+0 8-bit sRGB 57.6972MiB 0.090u 0:00.042
  $ for s in 0 3 6; do real_time magick DSC00191.ppm -quality 100 -define heic:chroma=444 -define heic:cicp=1/13/0/1 -define heic:speed=$s DSC00191_s$s.avif; done
  76.71
  12.80
  1.73
  $ real_time magick DSC00191.ppm -quality 0 DSC00191.jp2
  3.315
  $ real_time sh -c 'magick "$1" -define png:compression-level=0 "$2" && oxipng -q -o2 -s "$2"' argv0 DSC00191.{ppm,png}
  7.746
  $ for e in 3 6 9; do real_time magick DSC00191.ppm -quality 100 -define jxl:effort=$e DSC00191_e$e.jxl; done
  0.53
  1.33
  7.71
  $ for m in 0 3 6; do real_time magick DSC00191.ppm -quality 100 -define webp:lossless=true -define webp:method=$m DSC00191_m$m.webp; done
  5.86
  10.41
  46.03
  $ du -k DSC00191* | sort -n
  20068   DSC00191_e9.jxl
  20608   DSC00191_e6.jxl
  21324   DSC00191_m6.webp
  21340   DSC00191_m3.webp
  21772   DSC00191_e3.jxl
  23744   DSC00191.jp2
  23848   DSC00191_s0.avif
  23896   DSC00191_s3.avif
  24212   DSC00191_s6.avif
  24556   DSC00191.png
  26428   DSC00191_m0.webp
  59084   DSC00191.ppm

Post by ksec » Mon, Jun 01, 2026, 7:26 PM UTC

Andrex wrote: post #103

dannyw wrote: post #87

Earlier quoted context omitted.

Yeah, no production or large scale VC system is running software AV1 encoders on smartphones. You will drain a full phone battery in 1-2 hours of calls. It just doesn’t make sense and will result in extraordinary power/battery drainage at best, or output that’s worse than hardware encoding. The only way you could get AV1 to software encode in realtime AND low latency on a mid-range Android chip is by disabling or ski…

So, status remains quo, the commons remain tragic, and glory to H.264 forever?

Post by ksec » Mon, Jun 01, 2026, 7:53 PM UTC

jjcm wrote: post #144

adgjlsfhk1 wrote: post #3

Earlier quoted context omitted.

Based on AV1's trajectory, hardware encode isn't necessary (though it is nice). The current encoder is a reference encoder. Now that the spec is finalized, expect significant speed improvements from production encoders (realtime likely won't happen until we get it in hardware though)

I strongly disagree with it not being required. I run a small social news site - AV1 is still prohibatively expensive both for the server and clients for software encoding/decoding. Without hardware encoding, the tradeoff for better compression ratios in exchange for massive battery use + very long processing times for encoding simply isn't worth it. In order to get AV1 out, I have to often process a h264 version of…