dav1d accelerated AV1 decoder

[benwaggoner]

RISC-V is interesting. It's starting to go into a lot of embedded things. License free (unlike ARM) and a very elegant architecture.

[hajj_3]

v1.4.1 'Road Runner':
--------------------------------

- Optimizations for 6tap filters for NEON (ARM)
- More RISC-V optimizations for itx (4x8, 8x4, 4x16, 16x4, 8x16, 16x8)
- Reduction of binary size on ARM64, ARM32 and RISC-V
- Fix out-of-bounds read in 8bpc SSE2/SSSE3 wiener_filter
- Msac optimizations

[dapperdan]

dav1d pushed as part of a Google update going out to Android 12+

https://twitter.com/videolan/status/1781025929659392360

Apps will still use the Google developed alternative libgav1 unless they opt in though.

[Beelzebubu]

dav1d pushed as part of a Google update going out to Android 12+

https://twitter.com/videolan/status/1781025929659392360

Apps will still use the Google developed alternative libgav1 unless they opt in though.

See also: https://www.linkedin.com/feed/update/urn:li:activity:7186235577493544960/

"Apps need to opt into dav1d to benefit for now yet soon it will become the default av1 software decoder. "

[benwaggoner]

dav1d pushed as part of a Google update going out to Android 12+

https://twitter.com/videolan/status/1781025929659392360

Apps will still use the Google developed alternative libgav1 unless they opt in though.
The odds of Apple shipping someone else's precompiled binary in any of their OSes is very low these days. For security, portability, and optimization reasons.

They may leverage dav1d source code, but with their own tweaks and compile.

[Ritsuka]

Apple has been shipping dav1d for years. The arm64 version is compiled with pointer authentication codes enabled.

[nevcairiel]

The odds of Apple shipping someone else's precompiled binary in any of their OSes is very low these days. For security, portability, and optimization reasons.

They may leverage dav1d source code, but with their own tweaks and compile.

Why would anyone with a serious distribution ever ship someone elses binary for an open-source project, instead of just compiling it for your target? Am I missing context for this comment?

Obviously they compile their own. As does Google for Android. And Microsoft for Windows.

[LigH]

dav1d 1.4.1-66-g3623543 (https://www.mediafire.com/file/phu2u316bzqhb1c/dav1d_1.4.1-66-g3623543.7z/file) (MSYS2; MinGW32 / MinGW64: GCC 14.1.0)

[hajj_3]

Changes for 1.4.2 'Road Runner':
--------------------------------

1.4.2 is a small release of dav1d, improving notably ARM, AVX-512 and PowerPC
- AVX2 optimizations for 8-tap and new variants for 6-tap
- AVX-512 optimizations for 8-tap and new variants for 6-tap
- Improve entropy decoding on ARM64
- New ARM64 optimizations for convolutions based on DotProd extension
- New ARM64 optimizations for convolutions based on i8mm extension
- New ARM64 optimizations for subpel and prep filters for i8mm
- Misc improvements on existing ARM64 optimizations, notably for put/prep
- New PowerPC9 optimizations for loopfilter
- Support for macOS kperf API for benchmarking

[Beelzebubu]

The 6-tap optimizations for AVX2/512 were inspired by an earlier patch-set (provided by someone from Arm) doing the same on arm platforms. On both Arm (included in the previous release already) and x86 (in this release), on affected sequences (particularly these encoded using faster presets in encoders, which is what you'd find on Youtube etc.) this can provide a ~10% overall performance improvement. Pretty spectacular at this stage of dav1d's life cycle.

[oibaf]

Interesting. Is there a recent comparison of AV1 decoders? I remember there were in the past.

[birdie]

Interesting. Is there a recent comparison of AV1 decoders? I remember there were in the past.

Everything but dav1d is dead slow.

[BlueSwordM]

The main reason libgav1 existed is that Google temporarily suffered from the NIH (Not In Here) syndrome.
Some stuff from libgav1 made its way into dav1d and everything else is now history :)

[hajj_3]

Changes for 1.5.1 'Sonic':
--------------------------

1.5.1 is a minor release of dav1d, focusing on optimizations and stack reduction:

- Rewrite of the looprestoration (SGR, wiener) to reduce stack usage
- Rewrite of {put,prep}_scaled functions

Now, the required stack space for dav1d should be: 62 KB on x86_64 and
58KB on arm and aarch64.

- Improvements on the SSSE3 SGR
- Improvements on ARM32/ARM64 looprestoration optimizations
- RISC-V: blend optimizations for high bitdepth
- Power9: blend optimizations for 8bpc
- Port RISC-V to POSIX/non-Linux OS
- AArch64: Add Neon implementation of load_tmvs
- Fix a rare, but possible deadlock, in flush()

[benwaggoner]

Everything but dav1d is dead slow.
A fine illustration of how much low-level optimization can improve signal processing performance. We can still see 4x improvements between "a lot of optimization" and "great optimization."