dav1d accelerated AV1 decoder [Archive]

Nintendo Maniac 64

27th October 2019, 19:44

I wonder why dav1d developers have dedicated time to optimize for SSE2. Isn't SSSE3 already old enough? AMD has catched up and implemented SSSE3 in 2011.

AMD's non-DDR4 processors with SSSE3 were...underwhelming to say the least (the only exception being their Atom-competitor chips such as the Jaguar cores used in consoles, but it certainly wasn't their absolute performance that made them exceptions, far from it in fact).

A good amount of people saw no reason to upgrade from their SSE3-at-max AMD CPUs regardless of whether that was a Phenom II (especially those using the 6 core) or the first-gen "Llano" laptop APUs, worse still because of requiring different motherboards for either (AM3+ and FM2). Heck, when the first gen AM3+ FX CPU reviews landed, it was even common for people to instead upgrade to the Phenom II X6!

P.S. Few years ago I have tested 10 years old laptop with Pentium T4200 (SSSE3) which now rests unused. It could barely play Youtube VP9 720p videos while still dropped some frames

VP9 decoding in browsers was woeful back then. I was able to run YouTube's 1080p30 VP9 encodes on 2.0GHz first-gen Core 2 Duo (2MB L2 cache) and their 1080p60 VP9 encodes on a 2.4GHz second-gen Core 2 Duo (3MB L2 cache) if I ran the video stream through MPC-HC/LAVfilters, but the results were terrible in the browser. This was because the browsers at the time all used libvpx while MPC-HC/LAVfilters used ffvp9 (which actually for quite a while ran just as terribly if your CPU didn't support SSSE3 and/or you were using 32bit MPC-HC/LAVfilters, this however isn't the case anymore)

For reference your Pentium is the same exact architecture as a second-gen Core 2 Duo but has 1MB of L2 cache, so I would expect its IPC to be similar to a first-gen 2MB L2 Core 2 Duo.

Beelzebubu

28th October 2019, 03:00

I wonder why dav1d developers have dedicated time to optimize for SSE2.

SSSE3 is done. There was a comment by Steve Robertson (Youtube) at Video@Scale this year that 10% of their userbase on x86 has no SSSE3. So we're trying to explore whether this is meaningful.

1080p on SSE2 is not our goal. The goal is to have a baseline support so ~5 years (or even earlier?) from now, AV1 can be the baseline, not H.264. We don't know for sure, but this may imply some basic need for SSE2 support. So we're exploring what is possible and how much work it'd be.

NikosD

28th October 2019, 10:29

SSSE3 is doneAccording to the dAV1d team, latest version 0.5.0 is extremely fast.
Many times faster than libaom, even using SSSE3.
Based on the benchmarks below, what really surprises me is that depending on content and CPU implementation, SSSE3 code running on 128bit registers can be as fast as AVX2 code running on 256bit registers!
How is this even possible ?
I'm starting to believe that your AVX2 assembly optimizations could be optimized further.
BTW, any plans for AVX-512 in near future ?
Is there any benefit on this ?

https://i.postimg.cc/7h1nkFss/dav1d-0-5-x86-s.png

NikosD

28th October 2019, 11:17

Ok...So, I take a look at the single threaded performance and I see a 20% gain of AVX2 compared to SSSE3.

It is really amazing that the remaining non-optimized parts of the algorithm can impact the performance around 80% (!)

Does that mean that all these months of writing optimized AVX2 assembly are really contributing for 20% ?

I would really like to hear what the dAV1d team or other developers of software AV1 decoding say about that.

Do we really have an 80% non optimizable algorithm here ?

Looks like another implementation of Pareto law to me.

https://i.postimg.cc/3rt91v4z/1-0o-Wq-YLo1-A2x-Ho-Pa9-BSb3-SQ.png

NikosD

28th October 2019, 12:57

On what system (chipset)? I took it from "you"
http://www.jbkempf.com/blog/post/2019/dav1d-0.5.0-release-fastest

Beelzebubu

28th October 2019, 13:50

I took it from "you"
http://www.jbkempf.com/blog/post/2019/dav1d-0.5.0-release-fastest

Few things going on there:

YMM (e.g. AVX2) functions are never exactly 2x as fast as XMM (e.g. SSSE3) functions, even in theoretical conditions;
YMM upper lane use will cause CPU downclocking (but not on modern AMD CPUs, I'm being told);
certain code in SIMD functions does not use YMM upper lanes (effectively), usually because the block size is too small (width=4-8), but sometimes because we don't want a function-pointer-call overhead (multisymbol coding);
and obviously, a lot of code is not SIMD'ed at all, it's 50%-50% between SIMD and non-SIMD at best.

Together, that means the speedup is well below half of half, so 20% is not entirely unreasonable. Sucks a bit, but you can't beat reality.

Beelzebubu

29th October 2019, 01:23

TBH, I remembered ffvp9 to be one of the best optimized decoders ever and I thought it was due to AVX2 and not SSSE3 optimizations.

There's a reasonable (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/vp9dsp_init.c;h=837cce850819c1697132e23b97afe5b4ea9da2f9;hb=HEAD#l388) amount, but it's sort of the inverse as dav1d: we really did go all out in dav1d, doing everything-and-the-kitchen-sink in AVX2, and then we did SSSE3 later, doing most of it, but not quite everything. For ffvp9, it was the other way around, we did everything-and-more in SSSE3, and then did a couple of things (some MC, some inverse transforms) in AVX2, but the smaller inverse transforms and MC, as well as the loopfilters and most intra predictors, were never done. So it's fairly incomplete.

it seems that all decoders are doomed in the SSEx vs AVX2 battle.

That's a little negative. But yes, you won't get a 2x (or even 1.5x) speedup. 1.2x is nothing bad, though. And this i straight Haswell, newer chipsets (Zen2, Skylake) will get more, as will encoders.

excellentswordfight

29th October 2019, 13:28

dav1ds AVX2 is fine. If you want to properly compare SSSE3 vs AVX2, then you need to look at Single Threaded benchmarks. Multi-Threading is often limited in scaling, where such differences can "hide".
But you should also not expect twice the performance from AVX2, since once you optimize everything possible with SSSE3/AVX2, the remaining parts that cannot be optimized so easily will impact the performance the most.
What dav1d version does the stable 0.74.1 LAV filter use?

Tried to play that 2160p60 sample from netflix with 0.74.1 and mpc-be on an i7-7500U; 4 threads at 100% load at 3.2Ghz, could barely open the file, after 30s it started playing at 2-10fps (downscaled to 1080p). Not that I was expecting any smooth playback, but is this "normal" performance? HEVC 10bit sw decoding is about 3x faster on the same setup.

nevcairiel

29th October 2019, 14:30

What dav1d version does the stable 0.74.1 LAV filter use?

0.2.1, the newest available at the time. You can use a nightly version (https://files.1f0.de/lavf/nightly/) which would come with 0.5.1, the newest available right now.
That won't necessarily guarantee that 2160p60 will play on a mobile U-series CPU, but it got the best chances.

Just be careful not to pick the 10-bit variant of the Netflix Chimera video. 10-bit is not optimized at all yet, and its not representative of real-world content yet. YouTube for example only delivers AV1 8-bit so far.
And since there is no 8-bit 2160p variant of Chimera, thats your answer.

NikosD

29th October 2019, 20:40

I'm about to start a few benchmarks using various versions of dAV1d regarding SSSE3 and AVX2 progress on Core2Duo, Haswell, Skylake and Coffee Lake Refresh CPUs.

Is there a link with 1080p and 4K AV1 8bit sample videos to test ?

NikosD

30th October 2019, 11:04

OK, here we are.

Test Systems:
Skylake Core i5 6500 (TDP 65W) - Win 10 v1809 (17763.805) - 8GB DDR4-2133 MHz (1 DIMM - Single Channel)
All-core-turbo 3.3GHz

Haswell Core i3 4170 (TDP 54W) - Win 10 v1903 (18362.449) - 16GB DDR3-1600 MHz (Dual Channel 2x8GB)
Fixed 3.7GHz clock

Coffee Lake Refresh Core i3 9100F (TDP 65W) - Win 10 v1903 (18362.449) - 16GB DDR4-2400 MHz (Dual Channel 2x8GB)
All-core-turbo 4.0GHz

Merom Core2Duo T7600 (TDP 34W) - Win 10 v1809 (17763.805) - 4GB DDR2-667 MHz (Dual Channel Interleaved 2x2GB)
Fixed 2.33GHz clock

SW Tools:
DXVA Checker v4.2.1

LAV filters 0.74.1 (dAV1d 0.2.1 - 12/03/2019)
LAV filters 0.74.1-29 (dAV1d 0.5.1 - 26/10/2019)

During the whole benchmarking procedure, the Core i5 6500 never dropped its turbo clock of 3.3 GHz speed and Core i3 9100F never dropped its turbo clock of 4.0 GHz speed either.

Core i5 6500:
Max TDP for 1080p ~33W
Max TDP for 4K ~36W

Core i3 4170
Max TDP for 4K ~35W

Core i3 9100F
Max TDP for 4K ~54W

Core2Duo T7600
No tool can read Power Consumption

All video samples below are 8bit.

Chimera 1080p24fps sample is from Netflix
Dua Lipa 1080p25fps sample is from Youtube
Holi Festival 4K25fps sample is from Elecard (thanks @HolyWu)
Summer Nature 4K25fps sample is from Elecard

The numbers below represent FramesPerSecond (FPS) expressed as minimum/average/maximum.

1080p

Chimera ~6.6Mbps

Core i5 6500 86/134/290 CPU 87% -0.5.1
Core i5 6500 77/127/273 CPU 91% -0.2.1

Core2Duo T7600 10/19/94 CPU 72% -0.5.1
Core2Duo T7600 8/17/100 CPU 87% -0.2.1

Dua Lipa ~2.2Mbps

Core i5 6500 120/186/251 CPU 87% -0.5.1
Core i5 6500 112/186/255 CPU 91% -0.2.1

Core2Duo T7600 7/18/70 CPU 65% -0.5.1
Core2Duo T7600 7/18/69 CPU 84% -0.2.1

4K

Holi Festival ~14Mbps

Core i5 6500 34/43/61 CPU 94% -0.5.1
Core i5 6500 30/40/60 CPU 95% -0.2.1

Summer Nature ~23Mbps

Core i3 9100F 45/60/82 CPU 91% -0.5.1

Core i5 6500 32/43/57 CPU 93% -0.5.1
Core i5 6500 26/37/50 CPU 91% -0.2.1

Core i3 4170 21/30/46 CPU 92% -0.5.1
Core i3 4170 16/27/41 CPU 90% -0.2.1

Comments:

0) Sorry guys...dAV1d 0.5.1 has serious CPU utilization problem with my Core2Duo for laptop, essentially wiping out any optimization for SSSE3 set.
Dua Lipa has 0% gain over 0.2.1 and Chimera has only 11% on average.
The situation is a disaster for SSSE3 optimizations.

1) After 7 months of 0.2.1 release, I would say that dAV1d team certainly was not busy doing AVX2 optimizations.
It looks like 0.5.1 is only 0% - 8% faster than 0.2.1 on Skylake, besides the last 4K clip that gets a nice 16% gain.

2) Skylake Core i5 6500 is certainly not capable of decoding anything more than 4K30fps for AV1 up to ~20Mbps without dropping frames, even with the latest version.

3) Coffee Lake R Core i3 9100F is closer to 4K60fps, but still minimum frame rate is well below 60fps.

4) 0.5.1 dropped CPU utilization a little for Skylake (but enormously for Core2Duo) compared to 0.2.1, eating some of the performance optimizations of latest version for Skylake.

The only time that CPU utilization increased - compared to 0.2.1 - the gain was a good 16%.

5) Core i3 9100F vs Core i5 6500 results are showing that CFL-R is ~15% faster than its clock favor, probably due to a lot faster memory configuration.

Overall the results comparing 0.2.1 vs 0.5.1 were bad for both instruction sets of SIMD optimizations - SSSE3 and AVX2.

The last 7 months I see no progress according to my benchmarks and I really wonder where all those huge numbers of gain came from dAV1d team regarding 0.5.1 version vs 0.2.1

Is there a difference using a Core2Duo for desktop ?

Really looking forward for your tests and feedback.

NikosD

2nd November 2019, 06:20

SmilingWolf

2nd November 2019, 10:10

TLDR:
Win7 64bits, i7-4770k, 3.40GHz (stock), improvement between 0.2.1 and 0.5.1 using only SSSE3 accelerated routines, single thread:
Chimera: 33.2%
Dua Lipa: 34.9%

Included are some AVX2 tests too, because yes.

# time ./dav1d-0.2.1.exe -q -i Chimera-AV1-8bit-1920x1080-6736kbps.ivf --muxer yuv4mpeg2 --framethreads 1 --tilethreads 1 --cpumask ssse3 -o /dev/null

real 5m27,012s
user 0m0,000s
sys 0m0,000s

# time ./dav1d-0.5.1.exe -q -i Chimera-AV1-8bit-1920x1080-6736kbps.ivf --muxer yuv4mpeg2 --framethreads 1 --tilethreads 1 --cpumask ssse3 -o /dev/null

real 3m38,449s
user 0m0,000s
sys 0m0,000s

# time ./dav1d-0.5.1.exe -q -i Chimera-AV1-8bit-1920x1080-6736kbps.ivf --muxer yuv4mpeg2 --framethreads 1 --tilethreads 1 --cpumask avx2 -o /dev/null

real 3m5,282s
user 0m0,000s
sys 0m0,000s

# time ./dav1d-0.2.1.exe -q -i Dua_Lipa.ivf --muxer yuv4mpeg2 --framethreads 1 --tilethreads 1 --cpumask ssse3 -o /dev/null

real 2m42,726s
user 0m0,000s
sys 0m0,000s

# time ./dav1d-0.5.1.exe -q -i Dua_Lipa.ivf --muxer yuv4mpeg2 --framethreads 1 --tilethreads 1 --cpumask ssse3 -o /dev/null

real 1m45,987s
user 0m0,000s
sys 0m0,000s

# time ./dav1d-0.5.1.exe -q -i Dua_Lipa.ivf --muxer yuv4mpeg2 --framethreads 1 --tilethreads 1 --cpumask avx2 -o /dev/null

real 1m22,243s
user 0m0,000s
sys 0m0,000s

Overall the results comparing 0.2.1 vs 0.5.1 were good for both instruction sets of SIMD optimizations - SSSE3 and AVX2.

The last 7 months I see progress according to my benchmarks and I really don't have to wonder where all those huge numbers of gain came from dAV1d team regarding 0.5.1 version vs 0.2.1

SmilingWolf

2nd November 2019, 11:31

FFMpeg says it's going to use 4 frame threads and 3 tile threads to decode the files, so I'll be using those numbers.

Chimera: 34%
Dua Lipa: 29.7%

# time ./dav1d-0.2.1.exe -q -i Chimera-AV1-8bit-1920x1080-6736kbps.ivf --muxer yuv4mpeg2 --framethreads 4 --tilethreads 3 --cpumask ssse3 -o /dev/null

real 1m40,657s
user 0m0,000s
sys 0m0,000s

# time ./dav1d-0.5.1.exe -q -i Chimera-AV1-8bit-1920x1080-6736kbps.ivf --muxer yuv4mpeg2 --framethreads 4 --tilethreads 3 --cpumask ssse3 -o /dev/null

real 1m6,398s
user 0m0,000s
sys 0m0,000s

# time ./dav1d-0.5.1.exe -q -i Chimera-AV1-8bit-1920x1080-6736kbps.ivf --muxer yuv4mpeg2 --framethreads 4 --tilethreads 3 --cpumask avx2 -o /dev/null

real 0m54,087s
user 0m0,000s
sys 0m0,000s

# time ./dav1d-0.2.1.exe -q -i Dua_Lipa.ivf --muxer yuv4mpeg2 --framethreads 4 --tilethreads 3 --cpumask ssse3 -o /dev/null

real 0m46,972s
user 0m0,000s
sys 0m0,000s

# time ./dav1d-0.5.1.exe -q -i Dua_Lipa.ivf --muxer yuv4mpeg2 --framethreads 4 --tilethreads 3 --cpumask ssse3 -o /dev/null

real 0m33,041s
user 0m0,000s
sys 0m0,000s

# time ./dav1d-0.5.1.exe -q -i Dua_Lipa.ivf --muxer yuv4mpeg2 --framethreads 4 --tilethreads 3 --cpumask avx2 -o /dev/null

real 0m25,912s
user 0m0,000s
sys 0m0,000s

SmilingWolf

2nd November 2019, 12:11

NikosD

2nd November 2019, 12:33

The tool is from the dav1d project, found here: https://code.videolan.org/videolan/dav1d/tree/master/tools

You can either compile it yourself (MABS can do that) or use my copy: https://mega.nz/#!op5gGSTD!JPyhq1IqJc8-aUksVl81YzHBl8sXMg8SyR2HbSTs7gk

Finding the best frame/tile threads numbers is a bit tricky. Fiddling can improve performance, and I made some quick tests that brought Dua Lipa down to 29 seconds on 0.5.1+SSSE3 using --framethreads 6 --tilethreads 2, but I did not want to post them because in the end almost no media player is going to let you stray from FFmpeg, and therefore LAVFilters, defaults. Then Houston we have a problem.
Because we have seriously contradicting results between multi-threaded performance of ffmpeg and LAV filters regarding dAV1d, according to your tests and mine.

Could be your compilations vs nevcairiel's compilations, could be the setup of LAV vs ffmpeg for dAV1d or the hyperthreading nature of 4770K.

If you don't want to raise the threads in order to reach 100% CPU utilization, you could close hyperthreading from BIOS and run again the tests with 4 threads.

Also, you could run LAV filters benchmark using GraphStudioNext or DXVA Checker on your Core i7 as is with hyperthreading ON and see how that's going.

SmilingWolf

2nd November 2019, 12:59

I can't use DXVA to check performance since the dav1d library inside the FFmpeg library inside the LAVfilters library would default to using AVX2, unless you know of a way to target a specific instruction set from within DXVA, or perhaps using an environment variable. OTOH, if you just want me to check how dav1d multithreading works in different versions of LAVFilters/ffmpeg, I can test that. But it won't be a 0.2.1 vs 0.5.1 SSSE3 benchmark anymore.

I'm not too sure why you think I'm not using all cores of my CPU. With the settings above, 4 frame 3 tile threads, I get peaks of 80% CPU usage, and an eyeballed average of around 70%.

Anyway, again just because, here is my best 0.5.1+SSSE3 Dua Lipa result so far:

# time ./dav1d-0.5.1.exe -q -i Dua_Lipa.ivf --muxer yuv4mpeg2 --framethreads 6 --tilethreads 3 --cpumask ssse3 -o /dev/null

real 0m28,737s
user 0m0,000s
sys 0m0,000s

Peaks at 92% CPU, hovers at around 85% average.

NikosD

2nd November 2019, 14:00

I can't use DXVA to check performance since the dav1d library inside the FFmpeg library inside the LAVfilters library would default to using AVX2, unless you know of a way to target a specific instruction set from within DXVA, or perhaps using an environment variable. OTOH, if you just want me to check how dav1d multithreading works in different versions of LAVFilters/ffmpeg, I can test that. But it won't be a 0.2.1 vs 0.5.1 SSSE3 benchmark anymore. I couldn't find a way to test specific instruction sets too, that's why I used 0.2.1 vs 0.5.1 on different hardware.
You could check SSSE3 using a Core2Duo or an AMD processor and AVX2 on any Haswell onwards or Ryzen 3000.
If you only have i7 4770K, just check AVX2.

I'm not too sure why you think I'm not using all cores of my CPU. With the settings above, 4 frame 3 tile threads, I get peaks of 80% CPU usage, and an eyeballed average of around 70%. Due to 8 threads capable CPU.
Waiting for your AVX2 LAV filters results 0.2.1 vs 0.5.1 preferably in the form of DXVA Checker min/avg/max and the average CPU utilization reported by DXVA Checker.

Beelzebubu

3rd November 2019, 01:04

@Beelzebubu
@nevcairiel

Guys, I posted a huge benchmark report regarding dAV1d decoder progress between 0.2.1 vs 0.5.1 versions, meaning for the last seven months and I see no replies or reactions from you since.

Can you confirm or reject my findings with yours, showing different things ?

I have seen a lot of huge numbers regarding dAV1d progress from the dAV1d team in the official release notes - which I couldn't confirm - but in here you are very quiet.

Waiting for your feedback!

Just to add to SmilingWolf's comments, I agree you and I have diverging results and I've been discussing with various people as for what could be the cause. I don't immediately have a solution or explanation, but I haven't forgotten about it either.

To be clear, we don't just do command-line interface tests. We test this in end-user applications such as VLC and Chrome/Firefox also, and we see the same performance improvements there that we also see in "dav1d" the commandline tool.

NikosD

3rd November 2019, 02:59

... I don't immediately have a solution or explanation, but I haven't forgotten about it either.

To be clear, we don't just do command-line interface tests. We test this in end-user applications such as VLC and Chrome/Firefox also, and we see the same performance improvements there that we also see in "dav1d" the commandline tool. Ok, but SmilingWolf and you, have tested different things than me.
Firstly, he posted single threaded performance difference and I posted multi-threaded performance difference, besides the obvious difference of the implementation.
VLC is a popular media player - no doubt about it - but here we mostly prefer other players (MPC-HC / MPC-BE / MPV.NET etc)
I don't think there is other way to find out what is going on, than to reproduce the tests by yourself.
Is it possible to test the two versions of LAV's implementation I posted above ?
Also, the huge gains of performance posted in various release notes of dAV1d are for single-threaded or multi-threaded performance ?
Thanks!

NikosD

3rd November 2019, 08:18

Conveniently forgetting about my two posts dedicated to multi threaded performance aren't we? Conveniently forgetting about my word "firstly" as you posted initially single-tnreaded performance only, while I was asking to confirm or reject my multi-threaded results, as I posted first, regarding this issue.
After my comment you posted multi-threaded results, not using the same tools and with different threading status.
Anyway, the point here is to understand what's going on and not once again playing with words or intensions.
You could try to delete the config file of DXVA Checker and uninstall and reinstall everything.
I'm still waiting for an answer if the publicly available reported gains between versions of dAV1d referred to single-tnreaded or multi-threaded performance.
BTW, how do you benchmark dAV1d with the two executables you posted here ?
There is no internal command in these.

NikosD

3rd November 2019, 18:38

There isn't a DXVA Checker report yet, afternoon spent trying to make it work notwithstanding, but as I said, CPU utilization goes between 70% and 90% with the two sequences used. The main issue of dAV1d progress between 0.2.1 and 0.5.1 is not CPU Utilization.
The drop of CPU utilization using Skylake was only 2% although using Core2Duo the drop was huge.
The main issue of dAV1d it's the loss of any single-thread gain in real-world multi-thread decoding for whatever internal reason.
In the end, the end user doesn't know and doesn't care for the reasons that Dua Lipa video has exactly the same decoding speed for both versions of dAV1d 0.2.1 and 0.5.1 for two different CPU architectures and instructions sets (Skylake using AVX2 / Core2Duo using SSSE3)
It is us that we are still searching why is this happening and under what circumstances.

SmilingWolf

3rd November 2019, 19:27

Oh but you seemed so worried about how much dav1d was using all my cores just one day ago.

But here, have a Chimera run:
LAVFilters 0.74.1-29:
CPU: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
GPU: NVIDIA GeForce GTX 1080
Decoder: LAV Video Decoder
Decoder Device: -
Frames: 8929
FPS: 170,234 [103-349]
CPU Usage: -
GPU Usage: 0 [0-1] %
GPU Video Engine Usage: 0 [0-0] %

LAVFilters 0.74.1:
CPU: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
GPU: NVIDIA GeForce GTX 1080
Decoder: LAV Video Decoder
Decoder Device: -
Frames: 8929
FPS: 139,201 [77-306]
CPU Usage: -
GPU Usage: 0 [0-1] %
GPU Video Engine Usage: 0 [0-0] %

And Dua Lipa:
LAVFilters 0.74.1-29:
CPU: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
GPU: NVIDIA GeForce GTX 1080
Decoder: LAV Video Decoder
Decoder Device: -
Frames: 5615
FPS: 260,815 [183-335]
CPU Usage: -
GPU Usage: 0 [0-1] %
GPU Video Engine Usage: 0 [0-0] %

LAVFilters 0.74.1:
CPU: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
GPU: NVIDIA GeForce GTX 1080
Decoder: LAV Video Decoder
Decoder Device: -
Frames: 5615
FPS: 248,936 [137-328]
CPU Usage: -
GPU Usage: 0 [0-0] %
GPU Video Engine Usage: 0 [0-0] %

NikosD

4th November 2019, 08:55

Oh but you seemed so worried about how much dav1d was using all my cores just one day ago. My worries were and still are, the same.
The very low gain of real-world multi-thread performance between versions 0.2.1 vs 0.5.1 of dAV1d decoder, as measured by me using the above systems and tools, compared to the advertised and publicly reported by dAV1d team regarding SSSE3 and AVX2 optimizations.
All the other comments by me, express my agony to explain by any means that huge difference.
Your results confirm mine in an absolute way regarding Dua Lipa video, but there is a small light in the end of the tunnel regarding Chimera (regardless the name of the video)
I think @nevcairiel could explain better and test LAV filter's dAV1d implementation.

NikosD

4th November 2019, 13:01

@nevcairiel
@Beelzebubu
@SmilingWolf

A few more interesting notes regarding LAV filters.

LAV filters v0.74.1 allows you to set Thread = 1 but it actually uses 50% something CPU utilization, which means 2 cores = 2 threads for AV1 (using dAV1d)

But for all the other codecs, it uses only 1 thread as it should, based on the selection.

LAV filters v0.74.1-29 doesn't even allow you to set Thread = 1 because if you set it to 1, it doesn't enumerate in DXVA Checker when trying to decode AV1 files, while it can be used for all the other codecs using only 1 thread.

So, there is definitely something different regarding dAV1d integration in LAV filters, compared to all the other codecs.

In LAV filters 0.74.1-29, when setting Thread = 4, it has exactly the same performance as Auto for my Core i5 6500.

sneaker_ger

4th November 2019, 13:43

LAV filters v0.74.1 allows you to set Thread = 1 but it actually uses 50% something CPU utilization, which means 2 cores = 2 threads for AV1 (using dAV1d)
I think in LAV dav1d tilethreads are hard-coded to 2.
https://github.com/Nevcairiel/LAVFilters/blob/7f4e6dd6a45e88cbcbf9ec8a0173a247550cfc12/decoder/LAVVideo/decoders/avcodec.cpp#L370

dav1d has 2 thread number settings but LAV only exposes 1 to the user so that's just how it is. I guess nev thinks this is good enough for playback.

SmilingWolf

4th November 2019, 21:00

All the other comments by me, express my agony to explain by any means that huge difference.
And explaining by any means would be nice IF you actually bothered to follow up with a sistematic approach to prove your hypothesis.
This would imply removing all the fluff, going down to the most basic level and doing tests going up from there:
- use the dav1d util, single threaded, on IVF files to reduce to the minimum the amount of non-concerned code that is executed, like container parsing
-- Does it not show gains? Then you're right, there haven't been improvements
-- Does it show gains? Then you're wrong, look elsewhere
- use the dav1d util, with multiple threads.
-- Does it eat the gains? Then the problem is multithreading overhead.
-- Does it show the same gains, like I have measured? Then the problem is not single vs multithreaded performance
- use ffmpeg+dav1d, always on IVF files, singlethreaded.
-- Does it eat the gains? Then your problem is in the dav1d+ffmpeg integration
-- Does it show gains? Then look elsewhere
- use ffmpeg+dav1d, always on IVF files, multithreaded.
-- Does it eat the gains? Then your problem is in the dav1d+ffmpeg integration and the way multithreading interacts in either or both tools. I had this happen with ffmpeg+libvmaf, where one of the two would simply hang waiting for data that would never come
-- Does it show gains? Then look elsewhere
[I'm not going to write the whole thing again for AV1 files inside MKV containers but, well, if that's all you have left to look at, why not]
-- Did ffmpeg+dav1d integrate well? Then look at LAVFilters
Etc. etc. etc.

compared to the advertised and publicly reported by dAV1d team regarding SSSE3 and AVX2 optimizations.
You're forgetting a whole host of volunteers who followed and helped during development: https://code.videolan.org/videolan/dav1d/issues/15

Your results confirm mine in an absolute way regarding Dua Lipa video, but there is a small light in the end of the tunnel regarding Chimera (regardless the name of the video)
The only thing my Dua Lipa results confirm is that most routines that would be weighting down decode performance for this particular encode had already been optimized in AVX2 by the time 0.2.1 was released. AVX2 optimization, I would like to remind you, was considered almost complete by the time 0.2.0 was released: https://code.videolan.org/videolan/dav1d/blob/bb160f09/NEWS#L96
Hell, if I have time I might even build every single tag leading to 0.2.1 to pintpoint the exact release that brought us to today's performance.

LAV filters v0.74.1-29 doesn't even allow you to set Thread = 1 because if you set it to 1, it doesn't enumerate in DXVA Checker when trying to decode AV1 files, while it can be used for all the other codecs using only 1 thread.

So, there is definitely something different regarding dAV1d integration in LAV filters, compared to all the other codecs.
Congrats, this might be your first correct conjecture in this whole hordeal.

Based on the line of code highlighted by sneaker_ger I'd say having the number of tile threads implicitly set to 2 makes dav1d bail on this line: https://code.videolan.org/videolan/dav1d/blob/b9d4630c/src/lib.c#L84
The problem, however, is not in LAVFilters, but in FFmpeg's formula for frame distribution between the two modes, starting here: https://github.com/FFmpeg/FFmpeg/blob/a34d062/libavcodec/libdav1d.c#L137
Just in case, the formula is: frame_threads = threads / tile_threads, with all numbers involved being integers. For 2 tile_threads, this solves to 0 frame_threads, as shown here: https://godbolt.org/z/cz65UY, which is below the minimum of 1 frame thread required by dav1d.
This is indeed a bug. The easiest fix would be to cast threads to float before doing the division, as shown here: https://godbolt.org/z/wBLYoo, to avoid having dav1d bail. Threads distribution will still be higher than selected, but at least it'll work.

NikosD

4th November 2019, 22:23

And explaining by any means would be nice IF you actually bothered to follow up with a sistematic approach to prove your hypothesis...Then look at LAVFilters
Etc. etc. etc. I really like your analytical thought, but we need 2 lifes to check all these.
And if all this procedure was so clear for you, why didn't you do it?
We have to suggest things that are feasible in real world, not just crazy detailed procedures.
The only thing my Dua Lipa results confirm is that most routines that would be weighting down decode performance for this particular encode had already been optimized in AVX2 by the time 0.2.1 was released. AVX2 optimization, I would like to remind you, was considered almost complete by the time 0.2.0 was released: https://code.videolan.org/videolan/dav1d/blob/bb160f09/NEWS#L96
Hell, if I have time I might even build every single tag leading to 0.2.1 to pintpoint the exact release that brought us to today's performance. Unfortunately there are two issues here.
Firstly, I have already said that for 7 months not a lot things have been added to AVX2 optimizations according to my tests although if we followed every release notes after 0.2.1 up to 0.5.1 we should see a lot more AVX2 gain than 5%.
The second more important issue is that according to my tests using LAV filters with Core2Duo in multi-thread mode, there is no difference using SSSE3 optimizations between 0.2.1 and 0.5.1 which is really bad according to release notes.
Congrats, this might be your first correct conjecture in this whole hordeal.
Based on the line of code highlighted by sneaker_ger I'd say having the number of tile threads implicitly set to 2 makes dav1d bail on this line: https://code.videolan.org/videolan/dav1d/blob/b9d4630c/src/lib.c#L84...This is indeed a bug. The easiest fix would be to cast threads to float before doing the division, as shown here: https://godbolt.org/z/wBLYoo, to avoid having dav1d bail. Threads distribution will still be higher than selected, but at least it'll work. I'm here to point to bugs, to discover bugs or even make developers think that something is going wrong that could be a bug, so I'm happy that I discovered one.
But certainly I'm not here to fix it, as I'm not a developer.
Still, the way I understand the bug and the fix presented by you, I'm not sure if it's going to recover the multi-thread "loss" or whatever other reason exists that 0.2.1 is so close to 0.5.1 using LAV for both AVX2 and SSSE3 according to my tests.
So, are we still looking for answers or case closed after fixing the bug ?

SmilingWolf

4th November 2019, 22:43

Well that procedure is the only certain way to find the source of the slowdown. It should't take more than one afternoon to run those tests, especially with some scripting and logging thrown in the mix.

And the reason I didn't follow my own procedure is that I can't reproduce your results, and have nothing to diagnose. I'm seeing between 4% (Dua Lipa) and 18% (Chimera) improvements in AVX2, and above 30% in SSSE3.
That's far above anything you're seeing on your computers, and more or less in line with what was announced:
- 0.3.0: http://www.jbkempf.com/blog/post/2019/dav1d-0.3-release%3A-even-faster%21 - "a gain of 15%-25% on SSSE3 processors; and even a 5% gain on AVX-2 processors"
- 0.5.0: http://www.jbkempf.com/blog/post/2019/dav1d-0.5.0-release-fastest - "a gain of 22%-40% on SSSE3 processors; and another gain of 4-7% on AVX-2 processors"
- 0.5.1: http://www.jbkempf.com/blog/post/2019/dav1d-0.5.1 - posted for completeness sake only, there's no mention of SSSE3 or AVX2 speedups

Is there a specific figure you were expecting?

Still, the way I understand the bug and the fix presented by you, I'm not sure if it's going to recover the multi-thread "loss" or whatever other reason exists that 0.2.1 is so close to 0.5.1 using LAV for both AVX2 and SSSE3 according to my tests.
So, are we still looking for answers or case closed after fixing the bug ?
That's correct, no case closed yet.

From where I'm standing, the problem is that you are the only one with access to those troublesome systems.
If you want me to help by compiling different versions dav1d or ffmpeg for Windows, I'm game, but that's as far as I can go from here.

nevcairiel

4th November 2019, 22:46

Based on the line of code highlighted by sneaker_ger I'd say having the number of tile threads implicitly set to 2 makes dav1d bail on this line: https://code.videolan.org/videolan/dav1d/blob/b9d4630c/src/lib.c#L84
The problem, however, is not in LAVFilters, but in FFmpeg's formula for frame distribution between the two modes, starting here: https://github.com/FFmpeg/FFmpeg/blob/a34d062/libavcodec/libdav1d.c#L137

LAV Filters was actually meant to avoid the calculation logic in FFmpeg entirely, but since I last looked at it, it was changed again (previously it directly took framethreads = threads). So I've adjusted how LAV configures ffmpeg-dav1d, and it should never use their calculations - and it'll now also disable all threading if you set it to 1.

NikosD

5th November 2019, 09:17

And the reason I didn't follow my own procedure is that I can't reproduce your results, and have nothing to diagnose. I'm seeing between 4% (Dua Lipa) and 18% (Chimera) improvements in AVX2, and above 30% in SSSE3. Using what tools to achieve those figures and in what mode, single-thread or multi-thread ?
That's far above anything you're seeing on your computers, and more or less in line with what was announced:
- 0.3.0: http://www.jbkempf.com/blog/post/2019/dav1d-0.3-release%3A-even-faster%21 - "a gain of 15%-25% on SSSE3 processors; and even a 5% gain on AVX-2 processors"
- 0.5.0: http://www.jbkempf.com/blog/post/2019/dav1d-0.5.0-release-fastest - "a gain of 22%-40% on SSSE3 processors; and another gain of 4-7% on AVX-2 processors"
- 0.5.1: http://www.jbkempf.com/blog/post/2019/dav1d-0.5.1 - posted for completeness sake only, there's no mention of SSSE3 or AVX2 speedups

Is there a specific figure you were expecting? You got it all wrong here.
To be more scientifically accurate, allow me to correct you according to the publicly available release notes:

- 0.2.2 :
SSSE3 +10% of 0.2.1
AVX2 +5% of 0.2.1

- 0.3.0 :
SSSE3 +12% of 0.2.2
AVX2 +5% of 0.2.2

- 0.5.0 :
SSSE +40% of 0.3.0
AVX2 +(4-7%), for my calculations I take 5% on average of 0.3.0

So, if you do the math correctly we are expecting a gain between 0.2.1 and 0.5.1 versions as follows:

SSSE3 ~72%
AVX2 ~16%

Even your troublesome calculations, as you mixed single-thread mode with multi-thread mode and dAV1d executables with lower than expected number of threads and LAV filters without managing to run DXVA Checker properly, couldn't reach those figures.
From where I'm standing, the problem is that you are the only one with access to those troublesome systems. From where I'm standing I'm the only one with four and not two video samples measured (for both 1080p and 4K), with proper measurements using LAV filters in multi-thread mode and correct DXVA Checker results.
TBH, I'm the only one who even noticed the issue of false reporting the gains between versions, at least using LAV filters in multi-thread mode and as I proved just above, you also confirmed my claims even using dAV1d executables and without wanting to.

I'm not sure what is your connection with dAV1d team, but you are certainly not offering a good job as their unofficial "lawyer"

I'm still waiting for an answer from you or any other member of dAV1d team regarding that 16% gain of AVX2 and 72% gain of SSSE3 between 0.2.1 and 0.5.1 reported in the release notes, is it for single-thread or multi-thread mode ?

NikosD

5th November 2019, 14:19

Comparisons between LAV 0.74.1 and later nightly versions are flawed since the threading strategy changed in FFmpeg, which resulted in 0.74.1 using more frame threads then the later nightlies, making 0.74.1 artificially faster. As such, all your results are invalidated.
This is why you should use as little software as possible to do benchmarking (ie. go as close to the core as possible), as you never know what changes might interfer with your conclusions. So...It seems that the inconsistency of LAV filters between the threading management of 0.74.1 (0.2.1 dAV1d) and 0.74.1-29 (0.5.1 dAV1d) caused a lot of troubles for benchmarking.

Also, your decision to reject single-thread decoding for 0.74.1 and 0.74.1-29, didn't allow me and still doesn't allow me to test this kind of performance gain (single-thread)

But, as I said before, the end user using a Media Player couldn't care less for single-thread performance/gain.

It's the real-world multi-thread decoding that does matter.

I've also once again changed the thread distribution in 0.74.1-30 from last night, and while its going to use more threads again now, similar to the old logic, its not going to be identical to 0.74.1 in all cases (because I added more tile threads on high core-count CPUs) OK, let's move on to new benchmarks using multi-thread performance of 0.74.1-30.

1080p

Chimera ~6.6Mbps

Core i5 6500 95/144/285 CPU 92% -0.5.1 (LAV 0.74.1-30)
Core i5 6500 86/134/290 CPU 87% -0.5.1 (LAV 0.74.1-29)
Core i5 6500 77/127/273 CPU 91% -0.2.1 (LAV 0.74.1)

Core2Duo T7600 12/22/103 CPU 87% -0.5.1 (LAV 0.74.1-30)
Core2Duo T7600 10/19/94 CPU 72% -0.5.1 (LAV 0.74.1-29)
Core2Duo T7600 8/17/100 CPU 87% -0.2.1 (LAV 0.74.1)

Dua Lipa ~2.2Mbps

Core i5 6500 135/194/255 CPU 91% -0.5.1 (LAV 0.74.1-30)
Core i5 6500 120/186/251 CPU 87% -0.5.1 (LAV 0.74.1-29)
Core i5 6500 112/186/255 CPU 91% -0.2.1 (LAV 0.74.1)

Core2Duo T7600 11/22/62 CPU 84% -0.5.1 (LAV 0.74.1-30)
Core2Duo T7600 7/18/70 CPU 65% -0.5.1 (LAV 0.74.1-29)
Core2Duo T7600 7/18/69 CPU 84% -0.2.1 (LAV 0.74.1)

4K

Holi Festival ~14Mbps

Core i5 6500 34/43/62 CPU 94% -0.5.1 (LAV 0.74.1-30)
Core i5 6500 34/43/61 CPU 94% -0.5.1 (LAV 0.74.1-29)
Core i5 6500 30/40/60 CPU 95% -0.2.1 (LAV 0.74.1)

Summer Nature ~23Mbps

Core i5 6500 31/42/55 CPU 92% -0.5.1 (LAV 0.74.1-30)
Core i5 6500 32/43/57 CPU 93% -0.5.1 (LAV 0.74.1-29)
Core i5 6500 26/37/50 CPU 91% -0.2.1 (LAV 0.74.1)

Comments:

1) Unfortunately not a lot changed regarding AVX2 optimizations in general.

For 4K clips the decoding performance didn't change at all and there is also a slight regression for Summer Nature

But for 1080p we have a gain of 13% for Chimera and 4% for Dua Lipa comparing 0.2.1 vs 0.5.1, still far away from 16% of expected gain according to release notes.

2) I'm now 100% sure that dAV1d team should be a lot more cautious regarding publicly reported gains of their versions in release notes.

IMO, they should always include real-world multi-thread gains on multiple content and resolutions (at least 1080p and 4K)

3) SSSE3 optimizations give 22% and 29% gain for 0.5.1 vs 0.2.1 on Core2Duo CPU, which of course is far away than optimal 72% but a lot better than previous badly configured LAV filters 0.74.1-29.

4) LAV filters 0.74.1-30 and 0.74.1 have the same CPU utilization, so the bug of LAV 0.74.1-29 has been fixed and we can finally compare apples to apples.

clsid

5th November 2019, 15:48

You can find the exact benchmark results from Ewout in the individual MRs. There is a link to a spreadsheet with all test results and system spec. Example:
https://code.videolan.org/videolan/dav1d/merge_requests/792

SmilingWolf

5th November 2019, 18:34

Using what tools to achieve those figures and in what mode, single-thread or multi-thread ?
You got it all wrong here.
To be more scientifically accurate, allow me to correct you according to the publicly available release notes:

- 0.2.2 :
SSSE3 +10% of 0.2.1
AVX2 +5% of 0.2.1

- 0.3.0 :
SSSE3 +12% of 0.2.2
AVX2 +5% of 0.2.2

- 0.5.0 :
SSSE +40% of 0.3.0
AVX2 +(4-7%), for my calculations I take 5% on average of 0.3.0

So, if you do the math correctly we are expecting a gain between 0.2.1 and 0.5.1 versions as follows:

SSSE3 ~72%
AVX2 ~16%

No, once again it's you who got it all wrong: https://code.videolan.org/videolan/dav1d/compare/0.2.2...0.3.0
A grand total of 4 commits between 0.2.2 and 0.3.0, with a stability fix, some docs updates, and no performance related commits whatsoever.

And if you had bothered to read the resources I linked to, you would have seen the numbers refer to 0.3.0 vs 0.2.1, as shown by the image on JBKempf's blog:
http://www.jbkempf.com/blog/public/VideoLAN/dav1d/0.3_SSSE3.png

So if YOU do the math correctly, you get:
- 0.3.0: http://www.jbkempf.com/blog/post/201...even-faster%21 - "a gain of 15%-25% on SSSE3 processors; and even a 5% gain on AVX-2 processors"
- 0.5.0: http://www.jbkempf.com/blog/post/201...elease-fastest - "a gain of 22%-40% on SSSE3 processors; and another gain of 4-7% on AVX-2 processors"
So, for SSSE3, max: 75%, min: 40% if you consider the numbers in the TLDR, or 37% if you consider the lowest range given within the 0.3.0 blogpost.
And for AVX2: max: 12,4%, min: 109,2%

I have already shown that, with SSSE3, I can get a 29% improvement in "FFmpeg multithread" mode on Dua Lipa, and 38,8% if playing some more extensively with the thread settings.
29% figure: http://forum.doom9.org/showthread.php?p=1889274#post1889274, 0.2.1 SSSE3 = 46,972s, 0.5.1 SSSE3 = 33,041s
38,8% figure: http://forum.doom9.org/showthread.php?p=1889289#post1889289, 0.5.1 SSSE3 with "nonstandard" thread settings: 28,737s
Admittedly close to the low end of the promised speedups, but definitely within the given range.

The 4% and 18% figures come from this post: http://forum.doom9.org/showthread.php?p=1889442#post1889442
Your beloved DXVA checker, LAVFilters 0.74.1 vs 0.74.1-29, AVX2, default multithreading, basically same conditions as you:
Chimera average FPS: 139,201 -> 170,234 = 18,2% slowdown when going from the most recent to the older, or 22% speedup when doing the opposite
Dua Lipa average FPS: 248,936 -> 260,815 = 4.6% slowdown when going from the most recent to the older, or 4.8% speedup when doing the opposite

Moreover, you keep yelling at a whole bunch of clouds (https://i.kym-cdn.com/news_feeds/icons/mobile/000/019/234/3ad.jpg): it has been shown that a bunch of different projects have undergone a bunch of changes that make both your and my DXVA Checker measurements completely unreliable to find out about dav1d improvements or lack thereof, yet you insist.

Meanwhile, all explanations (but your own), offers of help and alternative, more reliable solutions have been met with utter hostility. At this point, all resources are exhausted. You're right. dav1d is crap, the developers are incompetent, and you can live in your happy world where you can be mad at something.

OR you could start doing as suggested, and MAYBE we'll find out exactly where the problem lies, and possibly fix it.

NikosD

6th November 2019, 11:15

No, once again it's you who got it all wrong: https://code.videolan.org/videolan/dav1d/compare/0.2.2...0.3.0
A grand total of 4 commits between 0.2.2 and 0.3.0, with a stability fix, some docs updates, and no performance related commits whatsoever.

And if you had bothered to read the resources I linked to, you would have seen the numbers refer to 0.3.0 vs 0.2.1, as shown by the image on JBKempf's blog I really like names like Jean-Baptiste or Jesus from Nazareth, but I like more to read the official release notes than specific blogs: https://code.videolan.org/videolan/dav1d/-/releases

So, what do we have here ?
0.2.2 brings large improvements in speed on ARM64 and SSSE3 (more than 10% speed increase) and even manages to gain around 5% on the already fast AVX-2 implementation. 10% for SSSE3 and 5% for AVX2 using 0.2.2 compared to previous version aka 0.2.1 0.3.0 brings large improvements in speed on ARM64 (15% speedup) and SSSE3 (more than 12% fps increase) and even manages to gain around 5% on the already fast AVX-2 implementation. Another 12% for SSSE3 and 5% for AVX2 using 0.3.0 compared to previous version aka 0.2.2 0.5.0 brings large improvements in speed on SSSE3 CPU (up to 40% speedup), new speed improvements on AVX-2 (for 4-7%) and ARM64 (up to 10%) and ARM32. It introduces some VSX, SSE2 and SSE4 optimizations. Another 40% for SSSE3 and 4-7% for AVX2 using 0.5.0 compared to previous version aka 0.3.0.

Once again, please do the math.

It's ~72% from 0.2.1 to 0.5.1 regarding SSSE3 optimizations and ~16% for AVX2, according to the official, publicly released notes.
I have already shown that, with SSSE3, I can get a 29% improvement in "FFmpeg multithread" mode on Dua Lipa, and 38,8% if playing some more extensively with the thread settings.

Admittedly close to the low end of the promised speedups, but definitely within the given range. I have updated my previous post regarding benchmarks and I get 22% and 29% for Chimera and Dua Lipa using my Core2Duo, still too far away from 72%

Moreover, you keep yelling at a whole bunch of clouds (https://i.kym-cdn.com/news_feeds/icons/mobile/000/019/234/3ad.jpg): it has been shown that a bunch of different projects have undergone a bunch of changes that make both your and my DXVA Checker measurements completely unreliable to find out about dav1d improvements or lack thereof, yet you insist.

Meanwhile, all explanations (but your own), offers of help and alternative, more reliable solutions have been met with utter hostility. At this point, all resources are exhausted. You're right. dav1d is crap, the developers are incompetent, and you can live in your happy world where you can be mad at something. SmilingWolf with a Big Mouth, I could easily add.
You can find the exact benchmark results from Ewout in the individual MRs. There is a link to a spreadsheet with all test results and system spec. Example:
https://code.videolan.org/videolan/dav1d/merge_requests/792 Interesting specs...2 x Xeon with AVX2, DDR4 etc= 2x14cores = 28 cores with hyperthreading for testing SSSE3.

He has an average gain of ~23% which is in the range of my 22% to 29% gain, but I don't understand how the build versions used by him are connected to final versions (0.2.1, 0.2.2 etc)

But his results made me struggle to understand what is really going on with SSSE3 and propose something different.

My first Haswell processor was a Pentium with artificially disabled AVX/AVX2 instructions.

So, I remembered late yesterday night and confirmed with my 2013 (!) benchmark results that my 128bit SIMD (SSEx) benchmarks running on Pentium Haswell, were a lot faster at the same clock than my desktop Core2Duo E7300, unusually faster and not justified by the architecture differences.
It was like running 128bit instructions on 256bit registers and I say that because of the huge difference.

My suggestion:
@Beelzebubu, dAV1d team, x265/x264 fans, @doom9 and every other people running benchmarks on different SIMD optimizations.

If you want to benchmark specific 128bit SIMD optimizations and your target group is not only Pentiums/ Celerons with disabled AVX/AVX2 sets, but legacy hardware with SSEx only SIMD, then I suggest to run the tests on REAL SSEx-only (128bit only) capable hardware (e.g Core2Duo, Core2Quad or Core iX first generation) and not an emulation like running 128bit SSEx code with artificially disabled 256bit SIMD optimizations, but on a lot faster DDR4 and 256bit register capable CPU like 2 x Xeon (!)

I think you are going to be surprised by the results and these results could explain some performance difference.

Beelzebubu

6th November 2019, 15:30

My suggestion:
@Beelzebubu, dAV1d team [..]

If you want to benchmark specific 128bit SIMD optimizations and your target group is not only Pentiums/ Celerons with disabled AVX/AVX2 sets, but legacy hardware with SSEx only SIMD, then I suggest to run the tests on REAL SSEx-only (128bit only) capable hardware (e.g Core2Duo, Core2Quad or Core iX first generation) and not an emulation like running 128bit SSEx code with artificially disabled 256bit SIMD optimizations, but on a lot faster DDR4 and 256bit register capable CPU like 2 x Xeon (!)

That's a fair request, we can look into doing that.

marcomsousa

8th November 2019, 13:14

AOMedia Research Symposium 2019 Videos
https://www.youtube.com/playlist?list=PL97T7zfqOOF3YKvniyywewtWKpxXky8iI

Adding some titles

Youtube - https://www.youtube.com/watch?v=dqpEcNB6ltw
Facebook - https://www.youtube.com/watch?v=fgztbt6HLs4
Netflix - https://www.youtube.com/watch?v=M1vwnI0vbMI
Dav1d and Eve-AV1 - https://www.youtube.com/watch?v=Jy_89NcVpk4
SVT-AV1 - https://www.youtube.com/watch?v=zXvoBVZmkHs
AV1 in RT - https://www.youtube.com/watch?v=Uf90zOw6rcE
AV1 in RT in WebRTC https://www.youtube.com/watch?v=McmR8MhjbQk
Deep Neural Network Based Frame Reconstruction For AV2 - https://www.youtube.com/watch?v=QIoJfY9IIH0
Deep Learning - https://www.youtube.com/watch?v=WJd9qF4OceI
Lesson learnt from WebP - https://www.youtube.com/watch?v=zogxpP2lm-o
V1: Nits, Nitpicks and Shortcomings [Things we should fix for AV2] Mozilla - https://www.youtube.com/watch?v=Paf8JcO682Y

soresu

20th November 2019, 17:24

stadia "works" with pretty much every device. you don't need a chromecast a phone can do it so can a web browser on the PC. there is missing support for iOS and such but what ever.

It would drain battery tout suite, but dav1d 0.5.1 is more than fast enough to decode 1080p60 on any iPhone or iPad from the last 2-3 years, perhaps even 4K (though 4K60 seems doubtful).

Even the less impressive Cortex big cores on Snapdragon could handle 1080p60.

Obviously lacking ASIC decoder support is not ideal, but at least it is some support rather than nothing.

Heres hoping future improvements to the GPU code in dav1d will make decoding even more efficient for pre-ASIC devices than the initial GSoC 2019 efforts.

utack

3rd December 2019, 22:47

Beating a dead horse at this point maybe, but dav1d having a milestone for better PPC support and no word about adding basic 10bit support seems extremely odd
Netflix has signalled they are only interested in 10bit content, Youtube started encoding 10bit for their new higher resolution videos as well.
It should clearly be a priority over armv7 and PPC assembly, and imho all the "make it fast" milestones are not reached yet.

Blue_MiSfit

4th December 2019, 02:29

I also hope that the dav1d team focuses more on 10 bit soon. I think social media / user generated content is a huge use case for AV1, and most of that content is 8 bit for now.

benwaggoner

4th December 2019, 23:06

I also hope that the dav1d team focuses more on 10 bit soon. I think social media / user generated content is a huge use case for AV1, and most of that content is 8 bit for now.Do we have any evidence that 8-bit sources encode better in 10-bit than 8-bit in AV1? While that was true for H.264, it was much less so for HEVC, and I don't see why AV1 would have any regressions versus HEVC in that regard.

SW encoding and decoding of >8-bit content is always at least 25% slower, and can be more depending on the bottlenecks. And there's really not much point in doing >8-bit unless the source or display controller can do more than that. Most social media is consumed on phones and computers, for which very few end-to-end >8-bit pipelines exist. And with really high ppi, dithering is nigh invisible.

10-bit is much more valuable on living room screens, which are much larger and have native >8-bit support.

I think everything is going to go half float linear light for internal processing next decade, to make tone mapping, particularly of mixed color space content, way easier and better.

Sent from my SM-T837V using Tapatalk

hajj_3

5th December 2019, 01:56

Dav1d v0.5.2 'Asiatic Cheetah' changelog:

ARM32 optimizations for loopfilter, ipred_dc|h|v
Add section-5 raw OBU demuxer
Improve the speed by reducing the L2 cache collisions
Fix minor issues, including compilation on some OSes

soresu

5th December 2019, 12:58

I also hope that the dav1d team focuses more on 10 bit soon. I think social media / user generated content is a huge use case for AV1, and most of that content is 8 bit for now.

It's a shame Google pursued gAV1 rather than shunting engineer time to dav1d, they could work much faster on all fronts with some serious money behind them.

I get the whole competition is good angle, but it doesn't seem to have made much of a difference, other than prompting dav1d to shore up their ARM32 priorities - from which it seems dav1d are soundly ahead on all fronts again.

soresu

5th December 2019, 13:00

dapperdan

7th February 2020, 09:02

This announcement makes no sense: I don't know a single mobile SoC which supports AV1 HW decoding acceleration right now which means the poor users who will watch AV1 content will decimate their battery life.

They note that they're using Dav1d and supporting development of 10-bit assembly speedups so that's what wil be used until hardware arrives.

Currently it's opt in, you need to flick the pre-existing switch that says you want to save data when watching on mobile. I assume most of the time this just reduced file size and therefore quality, but now they have the extra option of switching codec as well.

It would be nice if they'd run the numbers and publish them, but against the backdrop of mobile streaming and a phone screen fully on, I'm not sure the lack of hardware decode will be that noticeable. I think Instagram were already shipping a VP9 software decoder on Android I don't think they were even using the fast ffmpeg decoder, just libaom.

soresu

7th February 2020, 17:21

I think Instagram were already shipping a VP9 software decoder on Android I don't think they were even using the fast ffmpeg decoder, just libaom.

Ouch, that's just being bloody minded to user battery life that is.

Here (https://code.videolan.org/videolan/dav1d/issues/215)'s the gitlab issue link for dav1d NEON, 4 opts for 16bpc already merged, 2 more lined up it seems.

Nintendo Maniac 64

8th February 2020, 23:39

dav1d v0.5.0 performance on Ubuntu Linux 20.04 LTS snapshot with the new 64core/128thread Threadripper 3990X: https://www.phoronix.com/scan.php?page=article&item=3990x-threadripper-linux&num=2

MoSal

10th February 2020, 19:32

Ouch, that's just being bloody minded to user battery life that is.

Here (https://code.videolan.org/videolan/dav1d/issues/215)'s the gitlab issue link for dav1d NEON, 4 opts for 16bpc already merged, 2 more lined up it seems.

Packaging differences. Compiling from sources and using "ninja -vC release install" puts the header(s) under <somewhere>/include/libvmaf/<headers>.h
Arch's package maintainer probably follows in the footsteps of the Debian package (https://debian.pkgs.org/10/multimedia-main-amd64/libvmaf-dev_1.3.14-dmo3_amd64.deb.html), that leaves the header under /usr/include/libvmaf.h

Arch's package maintainer is not (https://git.archlinux.org/svntogit/community.git/plain/trunk/PKGBUILD?h=packages/vmaf) following anyone's footsteps other than upstream. It''s just the Makefile (https://github.com/Netflix/vmaf/blob/e434247f8bf8f5ec36ba87062656583c073394fd/Makefile) from v1.3.15 predates the changes that made the new Makefile (https://github.com/Netflix/vmaf/blob/82a86e040371f2ca8665d6c210e3d1d2d608a636/Makefile) just a wrapper around meson/ninja.

Anyway, the last time (~18 months ago) I tried linking libvmaf to ffmpeg, I got runtime crashes after I managed to find a version that compiles. So I figured the library is not really reliable API/ABI wise for external linkage use-cases. So I opted to just script around the provided executable vmafossexec.

NikosD

12th February 2020, 14:06

Netflix starts using AV1 initially on Android mobile for offline viewing, leveraging dAV1d 10 bit optimized app.

Interesting.

-- Netflix --

Today we are excited to announce that Netflix has started streaming AV1 to our Android mobile app. AV1 is a high performance, royalty-free video codec that provides 20% improved compression efficiency over our VP9† encodes. AV1 is made possible by the wide-ranging industry commitment of expertise and intellectual property within the Alliance for Open Media (AOMedia), of which Netflix is a founding member.

Our support for AV1 represents Netflix’s continued investment in delivering the most efficient and highest quality video streams. For our mobile environment, AV1 follows on our work with VP9, which we released as part of our mobile encodes in 2016 and further optimized with shot-based encodes in 2018.

While our goal is to roll out AV1 on all of our platforms, we see a good fit for AV1’s compression efficiency in the mobile space where cellular networks can be unreliable, and our members have limited data plans. Selected titles are now available to stream in AV1 for customers who wish to reduce their cellular data usage by enabling the “Save Data” feature.

Our AV1 support on Android leverages the open-source dav1d decoder built by the VideoLAN, VLC, and FFmpeg communities and sponsored by the Alliance for Open Media. Here we have optimized dav1d so that it can play Netflix content, which is 10-bit color. In the spirit of making AV1 widely available, we are sponsoring an open-source effort to optimize 10-bit performance further and make these gains available to all.

As codec performance improves over time, we plan to expand our AV1 usage to more use cases and are now also working with device and chipset partners to extend this into hardware.

Nintendo Maniac 64

14th February 2020, 23:39

Phononix has 16core verses 32core vs 48c vs 64c vs 64c+SMT scaling comparisons in dav1d v0.5.0 and SVT-AV1 v0.8 on Windows 10 Pro, Win10 Enterprise, and Clear Linux (all on a Threadripper 3990X):
https://www.phoronix.com/scan.php?page=article&item=3990x-windows-linux&num=3

And regarding their choice of Linux distro:
https://www.phoronix.com/scan.php?page=article&item=3990x-clear-linux&num=1[/url]"]One of the interesting takeaways from my pre-launch briefing with AMD on the Ryzen Threadripper 3990X was AMD representatives actually recommending Clear Linux for use on this 64-core / 128-thread HEDT processor and the platform to which they've found the best performance. Yet, Clear Linux is an Intel open-source project.

The Clear Linux recommendation for the Threadripper 3990X was hardly a surprise to me given my experience with the platform, just a bit surprising AMD representatives acknowledging the Intel open-source software creation during a briefing. We've been benchmarking Clear Linux for years and were the ones to initially shine the public spotlight on its impressive performance capabilities -- that includes for AMD platforms too with numerous tests on different platforms we've performed the past few years.

mzso

17th February 2020, 20:45

Beelzebubu

17th February 2020, 21:59

Is Dav1d likely to get significantly faster?

Yes.

I tried it a bit in Firefox Nightly and there's a sizable gap to VP9 decoding in CPU usage (2x or more). I tried with 4k videos so the CPU usage would be more obvious.

Could you elaborate on what sort of system (CPU chipset etc.), and where you got the content from? In particular, it'd be interesting to know the respective bitrates for the AV1 & VP9 files/streams, but knowing the encoder settings might also be somewhat useful.

Playback speed correlates a lot with bitrate. The 30% numbers that we've shown at conferences and in blogs are for same-quality encodes, where VP9 has a higher bitrate than AV1. If the files are same-bitrate, the performance difference goes up. On easy content, the postfilters also require a higher % of runtime (compared to e.g. inverse transform or predictors), and since AV1 has more postfilters, that means the difference will grow on low-complexity content, and will be smaller on high-complexity content. The 30% was also without film grain (since we assume the GPU will do that for free), but there is currently no browser that does that correctly yet.

benwaggoner

17th February 2020, 22:23

Is Dav1d likely to get significantly faster?
I tried it a bit in Firefox Nightly and there's a sizable gap to VP9 decoding in CPU usage (2x or more). I tried with 4k videos so the CPU usage would be more obvious.It'll get somewhat faster. But given equal levels of opimization, VP9 is going to decode a lot faster than AV1 beause AV1 is a lot more complex. This is how it always is. About every decade we get a new bitstream that offers an eventual ~50% reduction in bitrate for about a 100% increase in decoder complexity as long as you spend ~10x more on encoding to take avantage of all the new features.

Codec development is all about turning Moore's law improvements into better compression efficiency. There are all kinds of features that could have been used in AV1/HEVC/VVC that offer small improvements for bigger complexity requirements. And each generation it's a trade off for what a reasonable complexity cost is, and people design the most capable bitstream format within that reasonable decoder complexity envalope.

Sent from my SM-T837V using Tapatalk

mzso

1st March 2020, 17:45

What browser/version, and on what platform/OS?

I think Youtube is known to do significantly higher bitrates for AV1 than for VP9, so that could be part of why...

I was testing Dav1d on Firefox Nightly. On Windows 8.1

hajj_3

6th March 2020, 01:03

dav1d 0.6.0 'Gyrfalcon'

0.6.0 brings major improvements in 10/12bit decoding on ARMv8 CPUs, up to 2.5 times faster than 0.5.2. It also brings new AVX-512, AVX2 and SSSE3 optimizations and improves the existing optimizations on all platforms. Finally, it also fixes some decoder mismatches and minor crashes.

soresu

11th March 2020, 00:15

Yeah, fast ARM 10-bit will make HDR feasible on 2020 mobile devices. For user generated content at least; premium studio content will still require HW DRM.

It's be nice to have some benchmarks with details beyond "Up to 2.5x faster" - is that only in some edge cases, or is ~2x speedup a practical expectation?

The bottom post on this gitlab issue has some benchmarks done by an AOM community member.

Link here (https://code.videolan.org/videolan/dav1d/issues/15).

Mr_Khyron

11th March 2020, 02:49

Dav1d 0.6 AV1 Video Decoder benchmark
https://phoronix.com/scan.php?page=news_item&px=Dav1d-0.6-AV1-Benchmarks

benwaggoner

3rd April 2020, 17:51

I'm wanting to test av1 and some other new encoders, and have been using media-autobuild-suite to try and build a ffmpeg with it. It keeps failing trying to install cargo-c as part of rav1e. I've deleted the folder. I've removed rav1e from the build list, but it keeps always trying to compile it and then failing. It's been happening for a couple of weeks now, and has persisted despite several rav1e updates in that time period.

Any suggestions?

dav1d git .................................................. [Up-to-date]
Running git clone for rav1e...
┌ rav1e git .......................................... [Recently updated]
├ Running submodule...
├ Running install-cargo-c...
Likely error (tail of the failed operation logfile):

error: aborting due to previous error

error: failed to compile `cargo-c v0.6.2`, intermediate artifacts can be found at `C:\Users\benwagg\AppData\Local\Temp\cargo-installyZ6Pas`

Caused by:
could not compile `cargo-c`.

To learn more, run the command again with --verbose.
install-cargo-c failed. Check C:/Users/benwagg/Desktop/media-autobuild_suite-master/build/rav1e-git/ab-suite.install-cargo-c.log
This is required for other packages, so this script will exit.
Creating diagnostics file...

All relevant logs have been anonymously uploaded to https://0x0.st/iuKh.zip
Copy and paste [logs.zip](https://0x0.st/iuKh.zip) in the GitHub issue.
Make sure the suite is up-to-date before reporting an issue. It might've been fixed already.
Try running the build again at a later time.

hajj_3

9th April 2020, 22:01

The windows 10 av1 extension decoder now uses the dav1d decoder! An update was just released on the microsoft store.

hajj_3

9th April 2020, 23:29

vlc player 3.0.9.2 is out, the first update in 8 months. Pretty sure it includes the latest dav1d decoder.

Pat357

10th April 2020, 00:30

The windows 10 av1 extension decoder now uses the dav1d decoder! An update was just released on the microsoft store.

Is this an extra download or does Win10 comes with this AV1 extension decoder ?

If it is an extra download, any url ?

hydra3333

10th April 2020, 07:45

The windows 10 av1 extension decoder now uses the dav1d decoder! An update was just released on the microsoft store.

Thanks !!

hajj_3

7th May 2020, 09:43

MPC-BE v1.5.5 (build 5274) beta has been released, the first non-nightly release in 5 months. It includes dav1d git-0.6.0-80-g114e8f0 and ffmpeg git-n4.3-dev-2815-gda44bbefaa.

LigH

13th May 2020, 07:47

New builds in MABS will delay a bit: meson has some issues with GCC 10.1 and posix_memalign (https://code.videolan.org/videolan/dav1d/-/issues/337) as reported for dav1d. MSYS2 update pending.

Sagittaire

16th May 2020, 10:23

New builds in MABS will delay a bit: meson has some issues with GCC 10.1 and posix_memalign (https://code.videolan.org/videolan/dav1d/-/issues/337) as reported for dav1d. MSYS2 update pending.

Your build is the last implementation dor VPx?

Spyros

20th May 2020, 18:01

dav1d 0.7.0 'Frigatebird' the fast and lean AV1 decoder (https://code.videolan.org/videolan/dav1d/-/releases/0.7.0)

This is a major update of the dav1d, the fast and lean AV1 decoder, codename 'Frigatebird'.

This release improves, once again, the speed on all platforms.

A rewrite of refmv made an important speed boost on x86 while reducing RAM usage. It should improve the speed on every platform.

A large number of assembly optimizations went for ARM64 for 8/10/12bit, a few for x86, notably for film grain and AVX-512 optimizations for CDEF.

And from the changelog (https://code.videolan.org/videolan/dav1d/-/blob/master/NEWS):

Changes for 0.7.0 'Frigatebird':
------------------------------

0.7.0 is a major release for dav1d:
- Faster refmv implementation gaining up to 12% speed while -25% of RAM (Single Thread)
- 10b/12b ARM64 optimizations are mostly complete:
- ipred (paeth, smooth, dc, pal, filter, cfl)
- itxfm (only 10b)
- AVX2/SSSE3 for non-4:2:0 film grain and for mc.resize
- AVX2 for cfl4:4:4
- AVX-512 CDEF filter
- ARM64 8b improvements for cfl_ac and itxfm
- ARM64 implementation for emu_edge in 8b/10b/12b
- ARM32 implementation for emu_edge in 8b
- Improvements on the dav1dplay utility player to support 10 bit,
non-4:2:0 pixel formats and film grain on the GPU

unlord

20th May 2020, 18:57

Timed with the dav1d 0.7.0 release, I just ran a multi-threaded performance comparison of libgav1 and dav1d on the 8-bit and 10-bit Chimera encodes (which are at roughly equivalent rate):

https://docs.google.com/spreadsheets/d/19byTEMMVuyOpqqF59eT1mwAi-W1Fhhtcqj1_4js9jSo

benwaggoner

21st May 2020, 22:37

dav1d 0.7.0 'Frigatebird' the fast and lean AV1 decoder (https://code.videolan.org/videolan/dav1d/-/releases/0.7.0)

And from the changelog (https://code.videolan.org/videolan/dav1d/-/blob/master/NEWS):
Exciting progress! And one of the first practical uses of AVX-512 in the video world (x265 supports it, but with current Intel thermal throttling, it rarely turns into any real world perf improvement).

I'd be curious to see the pref delta between an AVX-512 and an AVX2-only build.

Beelzebubu

22nd May 2020, 00:48

Exciting progress! And one of the first practical uses of AVX-512 in the video world (x265 supports it, but with current Intel thermal throttling, it rarely turns into any real world perf improvement).

I'd be curious to see the pref delta between an AVX-512 and an AVX2-only build.

It targets different CPUs. x265 targets skylake. dav1d targets icelake. I should clarify here that this is because - as @benwaggoner already pointed out - we expect avx512 would not ever be faster on skylake compared with avx2. Performance (avx512 vs. avx2 on icelake) is slightly faster multi-threaded, and slightly slower single-threaded, more detailed notes will follow when it's more complete. Because we don't have consistently faster results yet, avx512 is currently disabled by default, and you need to specify --cpumask=avx512icl to enable it.

hajj_3

22nd May 2020, 08:00

http://www.jbkempf.com/blog/post/2020/dav1d-0.7.0-mobile-focus

hajj_3

27th November 2020, 22:13

DAV1D v0.8.0 changelog:

- Improve the performance by using a picture buffer pool; The improvements can reach 10% on some cases on Windows.
- Support for Apple ARM Silicon
- ARM32 optimizations for 8bit bitdepth for ipred paeth, smooth, cfl
- ARM32 optimizations for 10/12/16bit bitdepth for mc_avg/mask/w_avg, put/prep 8tap/bilin, wiener and CDEF filters
- ARM64 optimizations for cfl_ac 444 for all bitdepths
- x86 optimizations for MC 8-tap, mc_scaled in AVX2
- x86 optimizations for CDEF in SSE and {put/prep}_{8tap/bilin} in SSSE3

soresu

29th November 2020, 05:40

Great strides for ARM32 playback in dav1d 0.8 which will benefit most streamers on the market which are limited to ARM32 OS's by their RAM capacity, at this point the ARM64 code path is almost completely optimised save for film grain.

Still outstanding though is 10+ bpc SIMD code for AVX2 and SSSE3, which seems a bit silly now after Netflix started churning out 10 bit HDR AV1 content earlier in the year.

benwaggoner

2nd December 2020, 02:51

soresu

3rd December 2020, 11:21

888 will able to decode 4K 8bit 30fps AV1 in software just fine though battery life will be hugely affected.

There's no reason that 10 bit 4K should be a problem at this point with the level of asm/SIMD optimisation for NEON that has been achieved in dav1d already from ARM64, which is basically everything but film grain and one other feature of the codec.

Even ARM32 is closing the gap to the ARM64 now.

There is also the GPU work in the Xbox One decoder which may well be translatable to GLES/Vulkan and Android* - though it should probably work fine for Windows on ARM with little changes, given it is UWP and DX12 code.

*There is already some GPU decoding work done in dav1d and the AOM Xbox One decoder branch may provide some pointers/reference for future work filling in the remaining gaps - though I doubt that it will dramatically affect decoding speed, probably more battery life, but that is what they would be after anyways for mobile use cases.

soresu

3rd December 2020, 19:23

Are they using it for PC/Mac playback, though? Netflix is going to have some HW DRM requirements from their content licensors.

True, though production problems of this year aside they have been steadily transitioning to their own content above anything else on the platform.

AMD and nVidia are also starting to push AV1 decoding hardware into the PC platform with RX 6000 and RTX 3000.

I'm not sure if those ASIC in GPU solutions will be compatible with DRM requirements but its certainly a start - there's also the new Intel SoC's coming that will decode and even encode AV1 in hardware.

benwaggoner

3rd December 2020, 23:53

Good thread!

I'm curious if anyone has deep dived on the decoder performance benefits of using more tiles, relative to the number of available threads to decode on.

benwaggoner

3rd December 2020, 23:57

True, though production problems of this year aside they have been steadily transitioning to their own content above anything else on the platform.
Yeah. Although they still need to support full studio-approved DRM if they have any licensed content. I suppose they could use AV1 only on a subset of the library.

AMD and nVidia are also starting to push AV1 decoding hardware into the PC platform with RX 6000 and RTX 3000.
Also Intel Xe/11th Gen Core! Which is the only thing that seems to be shipping in material volume so far.

I'm not sure if those ASIC in GPU solutions will be compatible with DRM requirements but its certainly a start - there's also the new Intel SoC's coming that will decode and even encode AV1 in hardware.
All the GPU solutions are absolutely supposed to support HW DRM playback. Windows has had good hooks for leveraging that for many years now.

I've not heard of anyone actually doing adaptive bitrate AV1 with DRM targeting actual consumer HW decode yet, though. Lots of talk about it, but I've not been able to find a single demo package or web site anywhere.

dapperdan

9th December 2020, 18:29

Yeah. Although they still need to support full studio-approved DRM if they have any licensed content. I suppose they could use AV1 only on a subset of the library.

I think this is a standard part of their rollout. I seem to recall VP9 being used first for downloadable content, which was often their in-house stuff.

Blue_MiSfit

9th December 2020, 20:47

Downloadable content is often SD to reduce size for product reasons:

"oops I'm at the airport gate and forgot I want some shows to watch! I want them ASAP! Also my connection is currently congested WiFi / LTE"

DRM requirements for SD are quite lax (software DRM is usually fine), so new codecs with software decoders are often okay there :)

hajj_3

9th December 2020, 22:48

mpc-be 1.5.6.5797 beta has been released which includes dav1d 0.8.0 it also adds lots of other av1 related things: https://sourceforge.net/p/mpcbe/code/HEAD/tree/trunk/docs/Changelog.txt

benwaggoner

10th December 2020, 01:58

for dav1d 0.8.0, what's the per-thread decoder perf difference for 8-bit and 10-bit content these days?

sneaker_ger

10th December 2020, 12:56

On SSSE3 like factor 5 or something? There still isn't optimization for 10 bit AVX2 nor 10 bit SSSE3.

benwaggoner

10th December 2020, 18:04

On SSSE3 like factor 5 or something? There still isn't optimization for 10 bit AVX2 nor 10 bit SSSE3.
I hope that optimization gets done and is effective. With AV1 we finally have a codec with mandatory 10-bit support, but it's too slow to be practical on the platforms where AV1 is most advantageous. The big 2021 win with AV1 would be Chrome/Firefox as it's an upgrade from H.264. Without 10-bit, there's no HDR, and no option to look better than H.264, just lower bitrate.

soresu

19th December 2020, 07:58

I hope that optimization gets done and is effective. With AV1 we finally have a codec with mandatory 10-bit support, but it's too slow to be practical on the platforms where AV1 is most advantageous. The big 2021 win with AV1 would be Chrome/Firefox as it's an upgrade from H.264. Without 10-bit, there's no HDR, and no option to look better than H.264, just lower bitrate.

Unfortunately unless a private entity sponsors x86 10 bpc SIMD asm as Netflix did for ARM64 NEON I would not expect it to happen soon as it is a pretty low priority on the dav1d roadmap - below even AVX512 8 bpc work, which is not even close to as far along as AVX2 or SSSE3 for completeness right now.

With any luck Netflix might take pity on us desktop users and get someone to do the x86 10 bpc work after their current hire has finished doing the ARM32 10 bpc optimisations which are coming along pretty well at the moment.

sneaker_ger

19th December 2020, 09:01

Unfortunately unless a private entity sponsors x86 10 bpc SIMD asm
They supposedly do have that sponsorship already (https://www.reddit.com/r/AV1/comments/k2azsb/dav1d_080_is_out/gdvf690/) but as you say it's not the highest priority.

It's good 10bpc is mandatory in the most basic profile but they should have taken it one step further and just got rid of 8bpc coding altogether.

Jamaika

19th December 2020, 12:56

nevcairiel

20th December 2020, 11:19

Maybe someone knows how to set config parameters dav1d 0.8.0-7424f8e for gcc windows 16bit with SSE2.
For 8bit the decoder works but for 16bit no. Maybe increase memory size.
WINVER=0x0602, _WIN32_WINNT=0x0602, ARCH_X86_64=1, CONFIG_16BPC, BITDEPTH=16, HAVE_ALIGNED_MALLOC

AV1 does not support 16-bit. its only 8, 10 and 12. Hence a decoder cannot support anything that the codec does not provide.

If you build it with full default settings, dav1d will support all these bitdepths natively out of the box. You can turn off 8 bit or 10/12 bit, but unless you are very much size constrained, there is no reason to do so.

Jamaika

20th December 2020, 13:14

AV1 does not support 16-bit. its only 8, 10 and 12. Hence a decoder cannot support anything that the codec does not provide.

If you build it with full default settings, dav1d will support all these bitdepths natively out of the box. You can turn off 8 bit or 10/12 bit, but unless you are very much size constrained, there is no reason to do so.
For dav1d there are no settings to define 10 or 12bit only for total of 10,12,16bit. I understand that in practice dav1d doesn't support 10.12bit

nevcairiel

20th December 2020, 17:41

I understand that in practice dav1d doesn't support 10.12bit

You are wrong. dav1d supports the entire AV1 spec fully.

Jamaika

20th December 2020, 19:52

You are wrong. dav1d supports the entire AV1 spec fully.
Well then how to set the config. BITDEPTH value can't be 10 or 12.

nevcairiel

20th December 2020, 19:56

Just build dav1d with default config, no changes, and it'll support everything.

Blue_MiSfit

20th December 2020, 22:13

Unfortunately unless a private entity sponsors x86 10 bpc SIMD asm as Netflix did for ARM64 NEON I would not expect it to happen soon as it is a pretty low priority on the dav1d roadmap - below even AVX512 8 bpc work, which is not even close to as far along as AVX2 or SSSE3 for completeness right now.

I'm honestly pretty surprised there's so little interest. Why is this? Is it just that the real hope for short term AV1 adoption via software decode is wide/shallow engagement content like social / user generated?

I suppose in this world it matters more to have comprehensive optimization for 8 bit content across even very old hardware. Seems odd to prioritize AVX512 for 8 bit over something like AVX2 for 10 bit tho :/

Of course all hollywood content is mastered in 10+ bit (even SDR) and is frequently delivered in 10 bit HEVC today. If I was building an AV1 encoding pipeline it sure would be ideal if I could just encode 10 bit and not worry about 8 bit at all..

nevcairiel

21st December 2020, 00:21

If I had to make a guess, I would say that desktop PC media consumption is not a priority for Netflix, Amazon etc, and a large part of their traffic is mobile or straight to TV or streaming devices, while YouTube sees a larger share on PC consumption.

foxyshadis

21st December 2020, 00:54

People watching on a PC/laptop generally won't click away just because the fans spin up, either, they'll just turn it up if they aren't already wearing headphones. Big difference from stuttering.

I wonder if SVT-AV1's assembly routines could be adapted; I don't know nearly enough about dav1d to know if Rust or the way data is set up would be a blocker, but at least the licensing is taken care of since the move.

sneaker_ger

21st December 2020, 08:26

Rust? I think you have dav1d confused with Rav1e. Both SVT-AV1 and dav1d are written in C (+assembly/intrinsics).

foxyshadis

21st December 2020, 09:59

Rust? I think you have dav1d confused with Rav1e. Both SVT-AV1 and dav1d are written in C (+assembly/intrinsics).

Brain fart, yes.

hajj_3

21st December 2020, 10:44

I'm honestly pretty surprised there's so little interest. Why is this? Is it just that the real hope for short term AV1 adoption via software decode is wide/shallow engagement content like social / user generated?

I suppose in this world it matters more to have comprehensive optimization for 8 bit content across even very old hardware. Seems odd to prioritize AVX512 for 8 bit over something like AVX2 for 10 bit tho :/

Of course all hollywood content is mastered in 10+ bit (even SDR) and is frequently delivered in 10 bit HEVC today. If I was building an AV1 encoding pipeline it sure would be ideal if I could just encode 10 bit and not worry about 8 bit at all..

Few people have HDR monitors or 10bit monitors. I'm sure that 10bit support will be good at some point next year.

Blue_MiSfit

21st December 2020, 22:52

Few people have HDR monitors or 10bit monitors. I'm sure that 10bit support will be good at some point next year.

To the contrary, 4k TVs are widely popular, and they all have 10 bit HDR & WCG panels.

I'll agree that the vast majority of PC / Mac systems do not have HDR / 10 bit displays ;)

hajj_3

22nd December 2020, 00:07

To the contrary, 4k TVs are widely popular, and they all have 10 bit HDR & WCG panels.

I'll agree that the vast majority of PC / Mac systems do not have HDR / 10 bit displays ;)

hardly anyone with an x86 desktop/laptop is connected to a tv therefore it isn't a priority for netflix.

soresu

24th December 2020, 21:12

hardly anyone with an x86 desktop/laptop is connected to a tv therefore it isn't a priority for netflix.

Speak for yourself, not everyone has perfect vision and can use a sub 30 inch monitor to read with.

I'm using a 40 inch HDTV and even with that I still need to scale up the text/dpi just to read without getting a splitting headache.

I'm just hoping that when I finally upgrade to a UHDTV that all the relevant software I use has dynamically scaling UI now as many didn't when I first started noticing my vision loss 9 years ago.

soresu

24th December 2020, 21:21

To the contrary, 4k TVs are widely popular, and they all have 10 bit HDR & WCG panels.

I'll agree that the vast majority of PC / Mac systems do not have HDR / 10 bit displays ;)

Oddly not all 4K TVs are either 10 bit or HDR capable, something that took sometime to figure out as my dad kept getting a 'downscaling' message on his 2015 Panasonic 4k TV when he was playing a 4K bluray.

As it turned out his TV had been made before the HDR part of the 4K UHD Bluray standard had been set in stone, so it basically just does 2160p resolution, no 10 bpc (native or 8 bpc + FRC) or HDR to be had.

It does have a Displayport connector though as well as the standard HDMI, which is a considerable oddity for a TV model.

As 4K TV's were being made well before my dad bought his I can only guess that before the full 4k UHD standard was hammered out it was somewhat like the pre 'Full HD' phase of HDTV's that had 720p and other such sub 1080p resolutions that poor people were duped into en masse.

Blue_MiSfit

24th December 2020, 23:29

Sure, there's some outliers. 2015-2016 is when things really solidified. 4K UHD TVs before 2015 were extremely rare and expensive. I'd say your dad's is in that edge territory :)

foxyshadis

27th December 2020, 01:31

hardly anyone with an x86 desktop/laptop is connected to a tv therefore it isn't a priority for netflix.

I wouldn't be surprised if they'd love to flip a switch and have HDR on all PCs, if it wasn't for gpu drivers that can't HDR their way out of a wet paper bag, and create new bugs every version since they don't use video as a regression test case at all. It's a bit of a catch-22, since gpu driver teams only put any effort into anything other than games when it becomes critical mass and they can't ignore it anymore.

soresu

27th December 2020, 02:17

Sure, there's some outliers. 2015-2016 is when things really solidified. 4K UHD TVs before 2015 were extremely rare and expensive. I'd say your dad's is in that edge territory :)

Or just plain unreliable.

The TV broke less than 6 months shy of the 5 year warranty going kaput last year - thankfully the new motherboard inside not only works fine but boots the TV 3-4 times faster from standby than the old one

I'm pretty sure that it was also a 2014 model on very reduced price sale to clear stock, so not quite so expensive - I'm hoping to get that myself for a Samsung Q80T 55 inch to finally upgrade from my basic HDTV I'm using for a monitor.

soresu

27th December 2020, 20:27

dav1d is finally getting some x86 10 bpc AVX2 SIMD by porting some recent work for rav1e, no idea what sort of gains it will get yet but I'll leave the gitlab issue links in case the info gets posted there.

https://code.videolan.org/videolan/dav1d/-/merge_requests/1110

https://code.videolan.org/videolan/dav1d/-/merge_requests/1111

soresu

3rd January 2021, 19:22

Mostly more ARM32 NEON assembly.

At this point 1080p should be pretty viable on more recent streaming devices like Fire TV and Chromecast.*

*that's Chromecast 4 with A55 cores mind you.

Spyros

11th February 2021, 19:14

Blue_MiSfit

12th February 2021, 04:47

Excellent news!

benwaggoner

12th February 2021, 21:44

Some 10-bit assembly from rav1e was merged in dav1d, seemingly resulting in 25-30%+ better performance in AVX2 systems

https://i.redd.it/3u1jjjg5hgg61.png

Source + more details (https://old.reddit.com/r/AV1/comments/lg3x15/more_rav1e_hbd_assembly_ported_to_dav1d/)
What's the system these results are being measured on?

And is anyone keeping track of how PC power utilization is impacted by using SW AV1 versus a HW decoder? Back in the Silverlight days, I saw ~20 watts extra on a beefy laptop with H.264 SW decode versus HW decode. I imagine the gap is lower now, but it could be a pretty significant net environmental impact if 10M people are watching YouTube at an extra 10 watts each. Everything that can push that down is helpful.

unlord

13th February 2021, 01:09

What's the system these results are being measured on?

Author of the AVX2 patches (and graph) here. This experiment was conducted on a 3970x with a single core running at 3.7GHz. I can provide the sequences if you'd like to repeat the test on another system.

benwaggoner

13th February 2021, 02:57

Author of the AVX2 patches (and graph) here. This experiment was conducted on a 3970x with a single core running at 3.7GHz. I can provide the sequences if you'd like to repeat the test on another system.
Thank you.

Why single-core for testing, just curious? There aren't any AVX2 CPUs without at least 4 cores IIRC.

unlord

13th February 2021, 03:22

Why single-core for testing, just curious? There aren't any AVX2 CPUs without at least 4 cores IIRC.

Conducting a multi-threaded decoder comparison across implementations requires controlling for more variables. It is outdated now, but here is a comprehensive multi-threaded configuration study I ran in May 2020 comparing just dav1d to libgav1:

https://docs.google.com/spreadsheets/d/19byTEMMVuyOpqqF59eT1mwAi-W1Fhhtcqj1_4js9jSo

Note the Thread Configurations table.

hajj_3

15th February 2021, 22:15

dav1d v0.8.2:

- ARM32 optimizations for ipred and itx in 10/12bits, completing the 10b/12b work on ARM64 and ARM32
- Give the post-filters their own threads
- ARM64: rewrite the wiener functions
- Speed up coefficient decoding, 0.5%-3% global decoding gain
- x86: rewrite the SGR AVX2 asm
- x86: improve msac speed on SSE2+ machines
- ARM32: improve speed of ipred and warp
- ARM64: improve speed of ipred, cdef_dir, cdef_filter, warp_motion and itx16
- ARM32/64: improve speed of looprestoration
- Add seeking, pausing to the player
- Update the player for rendering of 10b/12b
- Misc speed improvements and fixes on all platforms
- Add a xxh3 muxer in the dav1d application

benwaggoner

17th February 2021, 01:49

Conducting a multi-threaded decoder comparison across implementations requires controlling for more variables. It is outdated now, but here is a comprehensive multi-threaded configuration study I ran in May 2020 comparing just dav1d to libgav1:

https://docs.google.com/spreadsheets/d/19byTEMMVuyOpqqF59eT1mwAi-W1Fhhtcqj1_4js9jSo

Note the Thread Configurations table.
Makes sense, and thank you!

Do you have any rough estimate for the gap in perf of a 10-bit and an 8-bit decode with equally optimized decoders?

savage747

17th February 2021, 09:42

There aren't any AVX2 CPUs without at least 4 cores IIRC.

My notebook with an i5 4300U would like to make its existence known ;-)

(2 Cores, 4 Threads, AVX2, 1.9 to 2.9 GHz)

Intel *really* loved selling dual-core mobile CPUs with similar nametags as quad-core desktop CPUs...

LigH

17th February 2021, 13:28

Hyper-Hyper threading FTW :sly:

benwaggoner

17th February 2021, 19:43

My notebook with an i5 4300U would like to make its existence known ;-)

(2 Cores, 4 Threads, AVX2, 1.9 to 2.9 GHz)

Intel *really* loved selling dual-core mobile CPUs with similar nametags as quad-core desktop CPUs...
I stand corrected!

There weren't any single core AVX2 processors at least, right?

savage747

17th February 2021, 21:01

There weren't any single core AVX2 processors at least, right?

Well, not really, as far as I know.

The closest to a single-core processor with AVX2 I know of would be the AMD A6-9500 for the current AM4 platform or the AMD A6-7480 for the old FM2+ platform. Those are marketed as two cores and two threads, but they're using AMD's ill-fated Bulldozer module architecture - so there is only one "module" (and thus only one FPU/vector unit to process AVX instructions) with two integer cores sharing the FPU/vector unit and parts of the frontend and memory system.

soresu

15th May 2021, 23:23

Massive speed up for 10 bpc content on AVX2 CPUs landed in the dav1d master recently:

https://code.videolan.org/videolan/dav1d/-/merge_requests/1195

As well as another separate commit for AVX2 mc.emu_edge on 10 bpc content:

https://code.videolan.org/videolan/dav1d/-/merge_requests/1196

The work for the main (huge) commit was sponsored by Facebook and Netflix according to the merge request.

It will be part of the dav1d 0.9 release which is likely to land pretty soon - this will also include numerous NEON asm for film grain synthesis on 8 bpc content, and the beginnings of the same for 10+ bpc content.

This release will render most 4K 10 bpc content pretty playable on many 8 core AVX2 capable CPU's, so even those that bought AMD Renoir and Cezanne based NUCs should still manage pretty well even without the AV1 ASIC coming for Van Gogh and Rembrandt APUs onward.

soresu

16th May 2021, 23:29

davi1d 0.9 (Golden Eagle) was officially released:

https://code.videolan.org/videolan/dav1d/-/releases/0.9.0

x86 (64bit) AVX2 implementation of most 10b/12b functions, which should provide a large boost for high-bitdepth decoding on modern x86 computers and servers.
ARM64 neon implementation of FilmGrain (4:2:0/4:2:2/4:4:4 8bit)
New API to signal events happening during the decoding process

benwaggoner

17th May 2021, 21:49

quietvoid

17th May 2021, 22:05

Is there any perf data yet on real-world decode fps after these changes?

https://www.phoronix.com/scan.php?page=news_item&px=AVX2-dav1d-0.9-Benchmarks

The changes also increased rav1e's encoding speed by 3x (with AVX2), since they share much of the ASM.

Beelzebubu

18th May 2021, 12:37

https://www.phoronix.com/scan.php?page=news_item&px=AVX2-dav1d-0.9-Benchmarks

The changes also increased rav1e's encoding speed by 3x (with AVX2), since they share much of the ASM.

The phoronix numbers look pretty good. Keep in mind that the Chimera clip they used has filmgrain in the 10bit version but not in the 8bit, and they enabled filmgrain application in the decoder, so it's not a perfect comparison.

In most software-decoder players, I would expect the film grain to be added in the GPU directly. dav1d contains an example (dav1dplay) that demonstrates how to do this (using libplacebo), and you will get some speed-up from this. To emulate this using the dav1d binary, use --filmgrain=0 (or in ffmpeg: -filmgrain 0). In gav1, you'd use --post_filter_mask 0xf. This is especially important because 10-bit filmgrain has no Neon SIMD optimizations yet (but 8-bit Neon/SSSE3/AVX2 and 10-bit AVX2 is present). So keep this in mind when running comparisons.

LigH

18th May 2021, 21:24

dav1d 0.9.0-0 (g8636b4f / 2021-05-16) (https://www.mediafire.com/file/2ewbyzu9l668wca/dav1d_0.9.0-0-g8636b4f.7z/file) (MSYS2 / MinGW, GCC 10.3.0)

I guess the "patches after release" increment is wrong...

soresu

19th May 2021, 07:06

This is especially important because 10-bit filmgrain has no Neon SIMD optimizations yet (but 8-bit Neon/SSSE3/AVX2 and 10-bit AVX2 is present). So keep this in mind when running comparisons.

Even the big 10 bpc AVX2 dump only covers film grain for 420 content, but as that covers probably everything currently on Youtube or any other commercial source using AV1 significantly it should be fine for most people.

There is also the beginnings of 10 bpc NEON optimisations though which was added just before 0.9 - so I would expect either a 0.9.1/0.9.2 to cover it all before too long since it was only a couple of months from the first NEON 8 bpc FG patch to the last.

benwaggoner

24th May 2021, 18:38

benwaggoner

24th May 2021, 18:42

Even the big 10 bpc AVX2 dump only covers film grain for 420 content, but as that covers probably everything currently on Youtube or any other commercial source using AV1 significantly it should be fine for most people.
Yeah, I don't see any reason why content distribution beyond 4:2:0 10-bit would happen in the 2020s. Especially where software decode may be required, as 444 is about half the speed without any quality advantage in >99% of content.

There is also the beginnings of 10 bpc NEON optimisations though which was added just before 0.9 - so I would expect either a 0.9.1/0.9.2 to cover it all before too long since it was only a couple of months from the first NEON 8 bpc FG patch to the last.
I would anticipate that 8-bit will be standard for where SW decode is needed, and 10-bit for HW, unless the perf overhead of 10-bit drops to <25% over 8-bit.

hajj_3

20th July 2021, 09:30

Dav1d 0.9.1 changelog:

- 10/12b SSSE3 optimizations for mc (avg, w_avg, mask, w_mask, emu_edge),
prep/put_bilin, prep/put_8tap, ipred (dc/h/v, paeth, smooth, pal, filter), wiener,
sgr (10b), warp8x8, deblock, film_grain, cfl_ac/pred for 32bit and 64bit x86 processors
- Film grain NEON for fguv 10/12b, fgy/fguv 8b and fgy/fguv 10/12 arm32
- Fixes for filmgrain on ARM
- itx 4x4 for SSE4
- Misc improvements on SSE2, SSE4

benwaggoner

20th July 2021, 21:38

Spyros

2nd August 2021, 14:01

Optimizations coverage

With 0.9.1, we've done most of the optimizations for 8/10/12bit on the following platforms:

Desktop CPUs with AVX2 (64bit)
Desktop CPUs with SSSE3 in 32bit
Desktop CPUs with SSSE3 in 64bit
ARM CPU in 32bit, ARMv7
ARM CPU in 64bit, ARMv8

There are still some minor optimizations left to do, but they won't change much the overall performance of the decoder.
For example, intra z1/z2/z3, 12bit SGR or 12bit itxfm are not done, but their usefulness is debatable :)

Please note also, that some optimizations were done for SSE4 and not SSSE3.

Assembly size

The portion of code in dav1d written in assembly is now reaching 140000 lines of code.

This code is composed of:

90000 lines for x86 (AVX2, SSSE3-32, SSSE3-64);
50000 lines for ARM (32bit and 64bit).

This is very large for handwritten assembly, and for comparison, this is more assembly than what there is in FFmpeg (for all codecs).

And yes, this code is faster than what the compilers can generate by themselves. :)

Source: jbkempf.com (http://www.jbkempf.com/blog/post/2021/dav1d-0.9.1-a-ton-of-asm)

benwaggoner

2nd August 2021, 20:19

That's some impressive optimization work there!

Looks like about 2x faster on Ryzen 5 and 3x faster on recent Intel.

Do we have a comparison between 8-bit and 10-bit decode performance?

Beelzebubu

6th August 2021, 13:54

Do we have a comparison between 8-bit and 10-bit decode performance?

From memory, on the starting scene (past frame 120) Chimera, same content, same tools, same bitrate, same resolutioin, I saw a ~20% drop on a Haswell laptop, single-threaded. Overall, this will depend on content complexity or bitrate: high-complexity content or low-quantizer/high-bitrate encodes tend to have a smaller drop than low-complexity content or high-quantizer/low-bitrate encodes. If you want more accurate numbers, you'll have to give some insight in what you're looking for in terms of bitrate/complexity/quantizer/resolution/etc. - and probably also type of device.

(Reason: things like coefficient decoding are basically identical between 8bit and 10bit, but things like prediction are slower because they require twice the memory. Therefore, overall slowdown depends on ratio between things that require double the memory (like prediction) and things that don't (like coef decoding). Because overall memory usage is cumulative between threads, you'll see a slightly larger drop-off with more threads.)

soresu

14th August 2021, 21:41

That's some impressive optimization work there!

Looks like about 2x faster on Ryzen 5 and 3x faster on recent Intel.

Do we have a comparison between 8-bit and 10-bit decode performance?

The SSSE3 path is currently missing CDEF filter for 10/12 bit which is currently in the merge request line up on the dav1d gitlab, as a major compute hog for AV1 that will give the next release (1.0.0) another step up again, and some optimisations made for that particular commit will have equivalent additions to the current AVX2 CDEF filter asm.

As well as that they just landed what I think is the last of the 10 bit film grain asm (gen_grain) for ARM64 NEON.

All told 1.0.0 should be pretty much every significant SIMD path fairly well optimised for 8 and 10 bpc content minus AVX512.

lvqcl

4th September 2021, 14:05

dav1d 0.9.2 (https://code.videolan.org/videolan/dav1d/-/releases/0.9.2)

0.9.2 is a small update of dav1d on the 0.9.x branch, focusing on adding SIMD on numerous small cases:

x86: SSE4 optimizations of inverse transforms for 10bit for all sizes
x86: mc.resize optimizations with AVX2/SSSE3 for 10/12b
x86: SSSE3 optimizations for cdef_filter in 10/12b and mc_w_mask_422/444 in 8b
ARM NEON optimizations for FilmGrain Gen_grain functions
Optimizations for splat_mv in SSE2/AVX2 and NEON
x86: SGR improvements for SSSE3 CPUs
x86: AVX2 optimizations for cfl_ac

This mostly concludes SIMD for SSSE3 (32+64), AVX2 and NEON (32+64). The rest are scaled-related and z1/z2/z3 and should not bring significant improvements in speed for most cases.

hajj_3

1st March 2022, 12:23

Changes for 1.0.0 'Peregrine falcon':
-------------------------------------

1.0.0 is a major release of dav1d, adding important features and bug fixes.

It notably changes, in an important way, the way threading works, by adding
an automatic thread management.

It also adds support for AVX-512 acceleration, and adds speedups to existing x86
code (from SSE2 to AVX2).

1.0.0 adds new grain API to ease acceleration on the GPU.

Finally, 1.0.0 fixes numerous small bugs that were reported since the beginning
of the project to have a proper release.

nevcairiel

1st March 2022, 13:00

1.0.0 has not been released yet. Keep your pants on :p

Spyros

18th March 2022, 19:07

dav1d 1.0.0 was released today. (Tag (https://code.videolan.org/videolan/dav1d/-/tags/1.0.0))

Changes for 1.0.0 'Peregrine falcon':
-------------------------------------

1.0.0 is a major release of dav1d, adding important features and bug fixes.

It notably changes, in an important way, the way threading works, by adding
an automatic thread management.

It also adds support for AVX-512 acceleration, and adds speedups to existing x86
code (from SSE2 to AVX2).

1.0.0 adds new grain API to ease acceleration on the GPU, and adds an API call
to get information of which frame failed to decode, in error cases.

Finally, 1.0.0 fixes numerous small bugs that were reported since the beginning
of the project to have a proper release.

.''.
.''. . *''* :_\/_: .
:_\/_: _\(/_ .:.*_\/_* : /\ : .'.:.'.
.''.: /\ : ./)\ ':'* /\ * : '..'. -=:o:=-
:_\/_:'.:::. ' *''* * '.\'/.' _\(/_'.':'.'
: /\ : ::::: *_\/_* -= o =- /)\ ' *
'..' ':::' * /\ * .'/.\'. '
* *..* :
* :
* 1.0.0

Source: NEWS (https://code.videolan.org/videolan/dav1d/-/blob/master/NEWS)

benwaggoner

23rd March 2022, 03:54

[QUOTE=Spyros;1965983]dav1d 1.0.0 was released today. (Tag (https://code.videolan.org/videolan/dav1d/-/tags/1.0.0))
Do we know how much speedup AVX512 provided? We've not seen it to be particularly useful in encoder performance, so it'd be interesting if it helps more on the decode side.

lvqcl

23rd March 2022, 18:41

8-bit video: SSE4.1 vs AVX2 vs AVX-512 (on 8C/16T Rocket Lake) - https://code.videolan.org/videolan/dav1d/-/merge_requests/1301

Beelzebubu

23rd March 2022, 18:56

Do we know how much speedup AVX512 provided? We've not seen it to be particularly useful in encoder performance, so it'd be interesting if it helps more on the decode side.

dav1d uses the icelake subset (AWS: m6i/c6i, or: F, CD, VL, DQ, BW, IFMA, VBMI, VBMI2, VPOPCNTDQ, BITALG, VNNI, VPCLMULQDQ, GFNI, VAES), not skylake subset (AWS: m5*/c5*, or: F, CD, VL, DQ, BW). Icelake's performance of AVX512 instructions is in general much better than Skylake's, but the wider instruction subset also allows for certain additional code optimizations.

Extreme example of the latter: 8-bit film grain (https://code.videolan.org/videolan/dav1d/-/merge_requests/1374) is more than 3x as fast with AVX512 compared to AVX2.

benwaggoner

23rd March 2022, 20:05

Wow, those are some very impressive speedups with AVX512! The new instructions are making at least as much of a difference than the "AVX2, but 2x wider" instructions.

Of course, Icelake CPUs don't have that much market share yet, but these kinds of speedups are quite promising in the long term for software decoding.

Beelzebubu

24th March 2022, 12:21

Of course, Icelake CPUs don't have that much market share yet, but these kinds of speedups are quite promising in the long term for software decoding.

... and software encoding!

Spyros

15th February 2023, 19:53

dav1d 1.1.0 was released yesterday. (Tag (https://code.videolan.org/videolan/dav1d/-/tags/1.1.0))

Changes for 1.1.0 'Arctic Peregrine Falcon':
-------------------------------------------

1.1.0 is an important release of dav1d, fixing numerous bugs, and adding SIMD

New function dav1d_get_frame_delay to query the decoder frame delay
Numerous fixes for strict conformity to the specs and samples
NEON and AVX-512 misc fixes and improvements
Partial AVX2 12bpc transform implementations
AVX-512 high bit-depth cdef_filter, loopfilter, itx
NEON z1/z3 optimization for 8bpc
SSSE3 z1 optimization for 8bpc

"From VideoLAN with love"

hajj_3

3rd May 2023, 07:43

Changes for 1.2.0 'Arctic Peregrine Falcon':
-------------------------------------------

- Improvements on attachments of props and T.35 entries on output pictures
- NEON z1/z3 high bit-depth optimizations and improvements for 8bpc
- SSSE3 z2/z3 8bpc and SSSE3 z1/z3 high bit-depth optimziations
- refmvs.save_tmvs optimizations in SSSE3/AVX2/AVX-512
- AVX-512 optimizations for high bit-depth itx (16x64, 32x64, 64x16, 64x32, 64x64)
- AVX2 optimizations for 12bpc for 16x32, 32x16, 32x32 itx

hajj_3

4th June 2023, 21:57

Changes for 1.2.1 'Arctic Peregrine Falcon':
-------------------------------------------

- Fix a threading race on task_thread.init_done
- NEON z2 8bpc and high bit-depth optimizations
- SSSE3 z2 high bit-depth optimziations
- Fix a desynced luma/chroma planes issue with Film Grain
- Reduce memory consumption
- Improve dav1d_parse_sequence_header() speed
- OBU: Improve header parsing and fix potential overflows
- OBU: Improve ITU-T T.35 parsing speed
- Misc buildsystems, CI and headers fixes

Barough

5th October 2023, 20:54

Changes for 1.3.0 'Tundra Peregrine Falcon (Calidus)':
------------------------------------------------------

1.3.0 is a medium release of dav1d, focus on new APIs and memory usage reduction.

- Reduce memory usage in numerous places
- ABI break in Dav1dSequenceHeader, Dav1dFrameHeader, Dav1dContentLightLevel structures
- new API function to check the API version: dav1d_version_api()
- Rewrite of the SGR functions for ARM64 to be faster
- NEON implemetation of save_tmvs for ARM32 and ARM64
- x86 palette DSP for pal_idx_finish function

Barough

5th October 2023, 21:02

dav1d v1.3.0-3-g47107e3
Built on October 05, 2023, GCC 13.2.0

https://code.videolan.org/videolan/dav1d

DL :
dav1d v1.3.0-3-g47107e3 (https://www.mediafire.com/file/yduyam6uwu6oi57/dav1d-1.3.0-3-g47107e3_Win_GCC132.7z/file)

hajj_3

14th February 2024, 17:21

Changes for 1.4.0 'Road Runner':
------------------------------------------------------

1.4.0 is a medium release of dav1d, focusing on new architecture support and optimizations

- AVX-512 optimizations for z1, z2, z3 in 8bit and high-bit depth
- New architecture supported: loongarch
- Loongarch optimizations for 8bit
- New architecture supported: RISC-V
- RISC-V optimizations for itx
- Misc improvements in threading and in reducing binary size
- Fix potential integer overflow with extremely large frame sizes

benwaggoner

14th February 2024, 20:19

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

9th March 2024, 17:41

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

20th April 2024, 21:22

Beelzebubu

22nd April 2024, 16:28

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

24th April 2024, 20:02

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

24th April 2024, 20:47

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

nevcairiel

24th April 2024, 21:27

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

21st May 2024, 21:57

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

25th May 2024, 19:31

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

26th May 2024, 14:01

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

26th May 2024, 17:22

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

birdie

27th May 2024, 15:20

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

Everything but dav1d is dead slow.

BlueSwordM

15th June 2024, 19:07

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

20th January 2025, 17:23

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

23rd January 2025, 20:37

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."

Z2697

3rd May 2026, 20:09

-DCONFIG_8BPC -DCONFIG_16BPC -DBITDEPTH=8

?????
Are you trying to be smarter than the build system (but failed).

Jamaika

3rd May 2026, 21:11

?????
Are you trying to be smarter than the build system (but failed).
I wanted to use an 8-bit and a 10/12/14/16-bit decoder. What's so strange about that?

After the latest patch, it stopped working.
https://code.videolan.org/videolan/dav1d/-/commit/f995e1fbf9379027367a93aafd2b5711ba76f81e

Z2697

4th May 2026, 01:43

I wanted to use an 8-bit and a 10/12/14/16-bit decoder. What's so strange about that?

After the latest patch, it stopped working.
https://code.videolan.org/videolan/dav1d/-/commit/f995e1fbf9379027367a93aafd2b5711ba76f81e

Because they should be defined by build system as needed, not you.
No that commit has nothing to do with this error.
The relative code that gets triggered by your erroneous use exists since 402b54fcaecd424726b3f1292b4fea3c5b1d8e35 Tue Feb 1 17:44:26 2022 +0100.
You try to manually grind through the building process without using the official build system, that's very... endeavourous, but please keep it to yourself.

Jamaika

4th May 2026, 06:44

rwill

4th May 2026, 07:19

...

This is so amazing. Jamaika copy/pasted some compile error without ANY hints or comment of why and what he wants and you narrowed it down to him wanting to do strange things again.

I wish I could read minds like that.

Jamaika

4th May 2026, 09:07

I was surprised it worked before. I see this interesting thread. As far as I'm concerned, there are no programming enthusiasts here, only weirdos, trolls, or their own advertising geeks. The rest are idiots. Your comment contributed nothing. I didn't want to register on another dav1d page. The question remains: what's the purpose of CONFIG_16BPC? Maybe delete it.

Z2697

4th May 2026, 16:23

So there will only be an 8-bit decoder. -DCONFIG_8BPC -DBITDEPTH=8
Overall, things are getting interesting. Two decoders, one 8-bit and one 16-bit, and two decoders, one av1 and one av2, meaning four plugins. It'll be interesting to see how they share common functions.

NO.

Both CONFIG_8BPC and CONFIG_16BPC are defined in the generated config.h file as 1 in a normal meson build.

BITDEPTH is supplied by the build comamnd(s) in the generated ninja build file but it is not defined for this file.

For (some of) other files, same files with different BITDEPTH are defined and compiled multiple times.

Use the goddayuum build system.
Or at least, learn from it, if you insist on grinding.

foxyshadis

5th May 2026, 10:27

Jamaika's build is pointlessly manual, but the highlighted defines are not the source of his problem, since it generally actually did work for some time. I strongly suspect there's either been a bad merge based on something he edited in a source file, since it builds fine by the official supported method, or that a new define was added somewhere along the way and is only now being used in a way that breaks the build otherwise. Which would simply not be a problem if you re-ran meson before every build.

Jamaika, unless you have a compelling reason to post a problem, like a major bug you've spotted, please don't post it here. Fix your build system on your own, instead of trying to make it someone else's problem yet again. Actually don't even post major bugs here until you've reported them on videolan as well, since it does no one any good to hear about them here when Videolan is the only one who can do anything about them. And if you don't want to sign up for the official home of the software, I don't know what to tell you, just don't pretend this is a proxy for it.

Z2697

5th May 2026, 11:37

Jamaika's build is pointlessly manual, but the highlighted defines are not the source of his problem, since it generally actually did work for some time.

I actually tried that define (BITDEPTH) with the "initial commit" I mentioned and it fails.
So the reason it had worked is a mystery. Probably Jamaika's process actually changed.

CONFIG_8BPC and CONFIG_16BPC don't actually matter since they are always defined as 1 in config.h (in default setting), but that's generated by meson.
This header was never there unless meson is ran, and source files include config.h. How Jamaika deals with it is another question...

Beelzebubu

15th June 2026, 01:34

The question remains: what's the purpose of CONFIG_16BPC? Maybe delete it.

The idea of CONFIG_xBPC is to be able to generate a build of dav1d that supports only high-bitdepth ("16bpc") or only low-bitdepth ("8bpc") instead of one that supports both. Internally, what will happen (in e.g. the case where you want only a LBD-decoder) is that the build disables building all 16bpc-related objects, and all templated build files (which are normally compiled twice; once for 8bpc and once for 16bpc) are now only built once, for the desired bitdepth.

This worked at some point and should still work, I thought we had CI tests for that, but maybe it broke. If it's broken, please submit a bug report on dav1d's gitlab.

[edit] -DBITDEPTH=x is how the templating works internally. You should not define -DBITDEPTH by yourself, it will conflict with how the build uses this define.

Jamaika

15th June 2026, 06:18

The idea of CONFIG_xBPC is to be able to generate a build of dav1d that supports only high-bitdepth ("16bpc") or only low-bitdepth ("8bpc") instead of one that supports both. Internally, what will happen (in e.g. the case where you want only a LBD-decoder) is that the build disables building all 16bpc-related objects, and all templated build files (which are normally compiled twice; once for 8bpc and once for 16bpc) are now only built once, for the desired bitdepth.

This worked at some point and should still work, I thought we had CI tests for that, but maybe it broke. If it's broken, please submit a bug report on dav1d's gitlab.

[edit] -DBITDEPTH=x is how the templating works internally. You should not define -DBITDEPTH by yourself, it will conflict with how the build uses this define.

First of all, I can't log in to Videolan. This is apparently the only mirror. Apparently I'm not an employee.

This split was suggested for dav1d. Logically, I was adding 16-bit. What does only 8-bit mean? For example, I wanted to downscale 10/12-bit video to 8-bit. It turns out that this is an error in my reasoning.

This is a strange error that has been occurring for years when I've been manually merging for both 8bit and 16bit, for dav1d and dav2d. In dav2d, these errors are more common for 16bit.
ts->frame_thread[p].cf = f->frame_thread.cf ?
(coef*)((uint8_t*)f->frame_thread.cf +
(((size_t)tile_start_off * size_mul[0]) >> !f->seq_hdr->hbd)) :
NULL;
Why should I annoy the developers that I don't use cmake? That's an automatic ban. It is what it is and sometimes I complain.

This isn't possible for dav2d. It only theoretically supports 8-bit. Furthermore, the description states that the AVM codec is 10-bit. Inputdepthinternal is always 10bit. Why would anyone need an 8-bit decoder?

And one more thing for the future. If someone wanted to add two decoders, one 8-bit and one 16-bit, to FFMPEG, it turns out they share common functions.

Viewing AOM HDR video is unreal by dav1d 8bit in ffmpeg.
https://pixeldrain.com/u/WKoG8vZc

Beelzebubu

15th June 2026, 12:15

First of all, I can't log in to Videolan. This is apparently the only mirror. Apparently I'm not an employee.

If your account doesn't work, go on IRC and ask on the relevant IRC channels, e.g. #videolan (on Libera).

Videolan is not for employees only.

This split was suggested for dav1d. Logically, I was adding 16-bit.

I don't know what to make of this. dav1d already supports high-bitdepth (10/12-bit) decoding. There is no 16bit in AV1.

What does only 8-bit mean? For example, I wanted to downscale 10/12-bit video to 8-bit. It turns out that this is an error in my reasoning.

If your AV1 video is 10/12bit, and you want to decode it using dav1d, it will only use the high-bitdepth code path. Whatever you do after that with this video in your processing pipeline (such as downscaling to 8bit) is completely independent of AV1 decoding. dav1d plays no part in that. dav1d has no built-in up/down-scaler/sampler or any other processing frameworks not directly part of AV1 decoding.

This is a strange error that has been occurring for years when I've been manually merging for both 8bit and 16bit, for dav1d and dav2d. In dav2d, these errors are more common for 16bit.
ts->frame_thread[p].cf = f->frame_thread.cf ?
(coef*)((uint8_t*)f->frame_thread.cf +
(((size_t)tile_start_off * size_mul[0]) >> !f->seq_hdr->hbd)) :
NULL;
Why should I annoy the developers that I don't use cmake? That's an automatic ban. It is what it is and sometimes I complain.

You should learn to be more utalitarian in your complaining.

In the end, if you want a custom build script, you'll still have to grab the relevant info from `meson.build`. You will find 5 lists of object files for 4 types of source files:
- objects that are built from source files, and that are specific to low-bitdepth decoding only. These will be built if CONFIG_8BPC is set.
- objects that are built from source files, and that are specific to high-bitdepth decoding only. These will be built if CONFIG_16BPC is set.
- objects that are built from source files, common to all decodeable bitdepths.
- objects that are built from *templated* source files. These will be built if CONFIG_8BPC is set, and when building the templated source files, they will define -DBITDEPTH=16 or -DBITDEPTH=8 to generate either low-bitdepth object files or high-bitdepth object files. The object files generated from these source files will get a 8bpc or 16bpc suffix, e.g. recon_tmpl.c becomes recon_8bpc.o or recon_16bpc.o.

If you want to use your own build system, just re-create this pattern. For your convenience, we have named all source files that are templated something like x_tmpl.c (e.g. recon_tmpl.c). This way, it should be easy to figure out which files should be with -DBITDEPTH=x and which files don't need that. We know of several people using this pattern-matching system. (This doesn't work for unit tests.) The final library built is a collection of object files to support whatever bitdepth(s) you desired, this can be low-bitdepth or high-bitdepth only, but by default it's (obviously) both.

This isn't possible for dav2d.

dav2d uses the same general rules for the build system, but we have not tested these kind of build rules yet, so you'll need more expertise to get this to work.

It only theoretically supports 8-bit.

This is obviously not true.

Furthermore, the description states that the AVM codec is 10-bit. Inputdepthinternal is always 10bit. Why would anyone need an 8-bit decoder?

To be faster. If your content is low-bitdepth, your pixels fit in 8bit types. This means that an AVX2 register (32bytes) can contain 32pixels. If we used a high-bitdepth codepath, the same AVX2 register would only contain 32bytes=16pixels. Do the math on expected decoding speed.

And one more thing for the future. If someone wanted to add two decoders, one 8-bit and one 16-bit, to FFMPEG, it turns out they share common functions.

The decoder - by default - supports both bitdepths, so the use case of 2 decoders, one for each bitdepth, is not one that we see as being necessary and is therefore not supported.

Z2697

15th June 2026, 12:26

Jamaika is usually hard to understand...
But that "no programming enthusiasts" sentence is, well, pretty clear.
How so?

Jamaika

15th June 2026, 14:08

I don't know what to make of this. dav1d already supports high-bitdepth (10/12-bit) decoding. There is no 16bit in AV1.
When calling the reference encoder, --qp shall be used to specify the qindex directly within the
following valid range:
● 8 bit: [0, 255]
● 10 bit: [-48, 255]
● 12 bit: [-96, 255]
Encoder internally will add a proper offset (48 for 10 bit and 96 for 12 bit) to get the final qindex
encoded in the bitstream.

https://aomedia.org/docs/CWG-F384o_AV2_CTC_v8.pdf
Honestly, I don't know. The AV1 decoder has numerous fixes. Currently, the AV1 decoder doesn't show information about what's being output. I don't know if it's a 10/12-bit movie in an 8-bit container.
I know that for AV2 12bit input gives 12bit output and I can confirm it using ffmpeg.
Input #0, image2, from 'output_avm_12bit.av2':
Duration: 00:00:00.04, start: 0.000000, bitrate: 1192055 kb/s
Stream #0:0: Video: av2 (libavm-av2), yuv444p12le(tv), 4000x3000 [SAR 1:1 DAR 4:3], 25 fps, 25 tbr, 25 tbn
9.04 M-V: 0.000 fd= 0 aq= 0KB vq= 0KB sq= 0B

Jamaika

15th June 2026, 14:11

If your AV1 video is 10/12bit, and you want to decode it using dav1d, it will only use the high-bitdepth code path. Whatever you do after that with this video in your processing pipeline (such as downscaling to 8bit) is completely independent of AV1 decoding. dav1d plays no part in that. dav1d has no built-in up/down-scaler/sampler or any other processing frameworks not directly part of AV1 decoding.
This is understandable.

Jamaika

15th June 2026, 14:14

In the end, if you want a custom build script, you'll still have to grab the relevant info from `meson.build`. You will find 5 lists of object files for 4 types of source files:
- objects that are built from source files, and that are specific to low-bitdepth decoding only. These will be built if CONFIG_8BPC is set.
- objects that are built from source files, and that are specific to high-bitdepth decoding only. These will be built if CONFIG_16BPC is set.
- objects that are built from source files, common to all decodeable bitdepths.
- objects that are built from *templated* source files. These will be built if CONFIG_8BPC is set, and when building the templated source files, they will define -DBITDEPTH=16 or -DBITDEPTH=8 to generate either low-bitdepth object files or high-bitdepth object files. The object files generated from these source files will get a 8bpc or 16bpc suffix, e.g. recon_tmpl.c becomes recon_8bpc.o or recon_16bpc.o.

If you want to use your own build system, just re-create this pattern. For your convenience, we have named all source files that are templated something like x_tmpl.c (e.g. recon_tmpl.c). This way, it should be easy to figure out which files should be with -DBITDEPTH=x and which files don't need that. We know of several people using this pattern-matching system. (This doesn't work for unit tests.) The final library built is a collection of object files to support whatever bitdepth(s) you desired, this can be low-bitdepth or high-bitdepth only, but by default it's (obviously) both.
I already know that. Unfortunately, gcc won't create a dav1d or dav2d decoder for CONFIG_8BPC. I had to add the above patch.

Jamaika

15th June 2026, 14:17

The decoder - by default - supports both bitdepths, so the use case of 2 decoders, one for each bitdepth, is not one that we see as being necessary and is therefore not supported.
For AV1, perhaps yes, if it's not 10/12 bit.
For AV2, that's a problem in my understanding.

Edit:
AV1 can be 10/12bit:
ffmpeg_vulkan_avx2.exe -loglevel warning -y -i "input.mp4" -frames:v 100 -vf "scale=1280:720,format=yuv420p12le" -f yuv4mpegpipe -strict -1 __REF.y4m
aomenc.exe --verbose --threads=16 --cpu-used=8 --end-usage=cbr --target-bitrate=3000 -o __AV1.webm __REF.y4m

Input #0, ivf, from '__AV1.ivf': 0KB vq= 0KB sq= 0B
Duration: 00:00:01.67, start: 0.000000, bitrate: 2497 kb/s
Stream #0:0: Video: av1 (libdav1d) (Professional) (AV01 / 0x31305641), yuv420p12le(tv), 1280x720 [SAR 1:1 DAR 16:9], 60 tbr, 60 tbn

To my surprise, the old dav1d 1.5.0-40ff2a1 version in ffmpeg from two years ago played the file without any problems. It wasn't pure dav1d 8bit.
https://www.sendspace.com/file/clays8

Beelzebubu

15th June 2026, 14:24

I already know that. Unfortunately, gcc won't create a dav1d or dav2d decoder for CONFIG_8BPC.

I just double checked to make sure, and we do indeed have bitdepth-specific builds as part of our CI (https://code.videolan.org/videolan/dav1d/-/blob/master/.gitlab-ci.yml?ref_type=heads#L175). So any problem is in your build system alone.

Let's be practical here: what is the *actual* build step (e.g. what is the full gcc commandline invocation) that is failing in your custom build process, and what is the *full and uncut* error message you're getting? I don't mind helping you along in your journey of using dav1d, but I need a lot more information than the few fragments you've been sharing so far.

Z2697

15th June 2026, 16:25

Somehow I feel that if you are hardcore enough to bypass the build system then those problems should be nothing...
Like, where's the learning curve?

hajj_3

21st July 2026, 18:00

dav1d 1.5.4 was released a week ago, here is the changelog:

Support for OS/2, including API exports and assembly

Switch to external checkasm

Add Armv9.3-A GCS (Guarded Control Stack) support

AArch64: optimize ipred_v, ipred_h and ipred_smooth_* 8bpc functions, and reduce .text size

ARM32: optimize prep_neon

RISC-V: ipred_(dc, h, v, pal) optimizations for 8 and 16bpc,
generate_grain_y for 8bpc, and optimizations (prep/put_8tap, 6-tap and copy paths)

Portability improvements for non-POSIX systems (signal() fallback)

Schedule tile tasks for all passes at once, improving threading

Precompute the quantization matrix tables at build time

Move loop-invariant computations out of hot loops

Jamaika

22nd July 2026, 10:31

I just double checked to make sure, and we do indeed have bitdepth-specific builds as part of our CI (https://code.videolan.org/videolan/dav1d/-/blob/master/.gitlab-ci.yml?ref_type=heads#L175). So any problem is in your build system alone.

Let's be practical here: what is the *actual* build step (e.g. what is the full gcc commandline invocation) that is failing in your custom build process, and what is the *full and uncut* error message you're getting? I don't mind helping you along in your journey of using dav1d, but I need a lot more information than the few fragments you've been sharing so far.
Is this my mistake? I won't admit it, although I don't use CMake. It bothers me that when I accidentally add another AV1 decoder, ff_libaom_av1_decoder or ff_av1_decoder, ffmpeg crashes and shows nothing. It seems to me that this worked before and selected the default decoder.

Oh admits to a conscious error. I add 16-bit DAV1D to 8-bit FFmpeg to be able to play 10/12-bit HDR videos. For this I had to modify DAV1D.
I see that on ffmpeg websites they also have dav1d 16bit HDR, but apparently it works correctly for clang.
My second mistake was that despite running a test by the creators of the av1 codec, it didn't show an error regarding the lack of adding the SIMD aom_highbd_quantize_(sse2,avx2) function. The config here is complicated.
I know some people are saying there's no point in adding encoders and decoders to the outdated ffmpeg. Use them separately.

I admit that the latest holiday versions of GCC 16(rev5) / mingw64 14 msys2 ucrt don't work properly with av1/dav1.