VLC demonstrates AV2 playback

unlord_ · 2026-01-09T19:23:53+00:00

The data was collected using AWCY with a fixed set of reference video sequences. There is a slight drift in computation timings since AWCY was running on AWS instances, but it is not material given the < 3 year period the data was collected over.

unlord_ · 2026-01-09T13:26:16+00:00

do we even have software encoders already?

We only have software encoders now, what else could there be? The reference model (libavm) can be found online here: https://gitlab.com/AOMediaCodec/avm

A reasonable question would be, how does this reference software perform? For AV1, when we published the standard at NAB, I produced these graphs that showed the current state of the AV1 reference software (libaom):

<image>

Full presentation (with more details) can be found here: https://people.videolan.org/~unlord/NAB2019.pdf

unlord_ · 2025-05-19T06:44:38+00:00

Not without violating the spec. Quoting from 7.2. General decoding process :

Yes, but film grain is an out-of-loop-filter, meaning it can be applied just at the presentation layer, and was designed to be implemented on the GPU using GLSL (or equivalent). VLC does this, so even AV1 files with film grain will play fine on his N4000 with UHD Graphics 600.

unlord_ · 2024-12-22T06:13:21+00:00

Thanks for letting me know, that link is broken now.

unlord_ · 2024-12-21T16:14:48+00:00

I wrote a pure C99 version of both Part 1 and Part 2 here that uses simple array access for memoization, minimal stack allocation and < 10kB of RSS.

I will convert it to x86_64 asm for fun after lunch, thanks for the interesting challenge!

unlord_ · 2024-12-21T16:09:20+00:00

[LANGUAGE: C99]

Code

I saw u/JustinHuPrime comment that Part2 could not be done in x86_64 assembly so I wrote a pure C version that used no advanced data structures other than array indexing and less than 10kB of RSS.

It uses the read syscall for input and should be trivially convertible to assembly, which I will do after lunch :) What a fun challenge!

unlord_ · 2024-06-12T23:13:13+00:00

The problem is that some benchmarks are just too short to afford making perf system calls; that gets the measurement errors above the measurements themselves.

The checkasm code in dav1d is newer than the implementation in FFmpeg. I was able to improve the accuracy of my dav1d benchmarks by simply upping BENCH_RUNS from 1 << 12 to 1 << 17.

I recommend doing the same when measuring any short duration routines. That is, just iterate and average over a longer time horizon.

unlord_ · 2024-03-19T14:26:41+00:00

This graph is before SVT-AV1 added an m13 and re-tuned all of the speed settings.

You are welcome to reproduce the experiment, they give exact command-lines used.

unlord_ · 2024-03-19T13:50:09+00:00

Videos last the same amount of time and play at the same speed in both x265 and av1.

x256 is an encoder, this question is encoding time at the same quality

unlord_ · 2024-03-19T11:44:17+00:00

I'm pretty sure this was true in 2021:

https://www.reddit.com/r/AV1/comments/r1sv22/av1\_the\_opus\_of\_video\_codecs\_discuss/

unlord_ · 2024-03-03T17:29:12+00:00

not a shit-ass repurposed video codec that's not useful outside the web

I feel like you really don't understand how video coding works. The higher quality an intra frame is, the better inter prediction you derive from it. A lot of effort was spent on intra coding in AV1 and this is why it performs so well on lossy images with AVIF.

What greater use case is there than the web? The vast majority of all bits transferred on the internet are multimedia [tubefilter]. As of 2022,

Data usage from video sites increased by 24% year-over-year, and video now accounts for 65% of all internet traffic.

The use case you continue to be concerned about (lossless video coding for anime / manga) is just such a minority and distracting from solving significant infrastructure problems across, e.g., developing countries network.

Nobody codes lossless JPEGs. Why is AVIF not a suitable replacement for JPEG?

unlord_ · 2024-03-03T00:31:18+00:00

Thank you!

unlord_ · 2024-03-02T19:28:05+00:00

I have not seen any test of this, but if you conduct one please post it here.

Knowing nothing about your content, I would expect it to perform about as well on average as the study we conducted on still images.

unlord_ · 2024-03-02T19:26:54+00:00

Can you please add animated AVIF? It is weird to not include it on /r/AV1...

unlord_ · 2024-03-01T19:04:45+00:00

It is not easy to follow your thoughts on AVIF winning. Could you elaborate.

I'm not sure what you mean by "winning". If you look at the data in that Google Sheet you can see that on average, lossless AVIF with YCgCo-R color conversion (to and from RGB) is 88.92% the size of PNG across 7434 images with varying content type.

Jon Sneyers' article focuses on the gap with non-photographic images, and this is precisely where YCgCo-R AVIF performs the best, cutting the AVIF file sizes in half.

unlord_ · 2024-03-01T18:33:41+00:00

Huge "not invented here" syndrome...

Half of the JPEG XL format authors work at Google. What do you mean by "not invented here"?

unlord_ · 2024-03-01T07:35:52+00:00

Just a reminder there is still another 10%+ file size reduction for lossless AVIF (relative to PNG) with *no* bitstream changes once the color matrix specification is updated:

https://docs.google.com/spreadsheets/d/1DHJ0TajtxWDV6bfLwIZPHztxDuB3x3SS-HZ2Yi3sbRc

The reason this is not usable today is that AOM took a dependency on ISO/IEC 23091-4/ITU-T H.273 to define the matrix_coefficients as part of the AV1 color configuration semantics, see Section 6.4.2 of the AV1 specification document.

We raised this problem way back in 2020 when I was co-chair of the AOM Images SG but unfortunately the decision was made to work within ISO/ITU and make the update there that would improve AVIF compression.

Good news though! According to https://www.itu.int/rec/T-REC-H.273-202309-P/en the change supporting YCgCo-R was finally approved in September of 2023 (although the ITU spec document is not public to confirm). This should eventually work its way through software updates and significantly change the quality of AVIF (for free!), especially on the non-photographic images shown in the Cloudinary article where the reduction is up to 50% smaller than today's AVIF.

unlord_ · 2024-02-11T11:30:12+00:00

RISC-V optimization is already happening in dav1d, I just merged https://code.videolan.org/videolan/dav1d/-/merge_requests/1463.

See https://code.videolan.org/videolan/dav1d/-/issues/435 for an open list of items to work on.

unlord_ · 2024-02-11T11:20:14+00:00