Dav1d, fast AV1 decoder, version 1.0

https://code.videolan.org/videolan/dav1d/-/blob/1.0.0/NEWS

by coldpie • 4 years ago

216 108 4 years ago

code.videolan.org

kfarr• 4 years ago

Congratulations on a major milestone! So cool to see the continued evolution of AV1

WithinReason5• 4 years ago

How good is the performance? Is 4K60 on a phone possible? 1080p60? Hard to find numbers on this

iso16315• 4 years ago

Trying to imagine how close you would have to be to the screen to tell the difference between 1080 and 4k...

true_religion• 4 years ago

Surely, sitting in front of a laptop or iMac would make it easy to tell.

WithinReason5• 4 years ago

It's hard to tell for uncompressed, but easy for compressed YouTube videos

throw0101a• 4 years ago

I think that for most of these libraries software-only performance is a moot point: the library is there for other software to use to be able to parse the files, and the library/decoder will simply offload the heavy compute to the (hopefully eventually-available) decoding hardware instructions.

To a certain extent it's just a place holder so folks can start writing software against it so that when the CPU vendors ship everyone can hit the ground running.

WithinReason5• 4 years ago

Wouldn't that only be true of the reference encoder libaom?

This is the description the dav1d page gives:

dav1d is the fastest AV1 decoder on all platforms :)

Targeted to be small, portable and very fast.

Since they use the word fast twice I was wondering how fast.

daneel_w8• 4 years ago

It's bad. As a reference, I tried decoding a measly 2 mbit/s test clip on an older Core 2 Duo MacBook Pro (which has no issues playing back the same in H.264 purely with software decoding), and it stuttered a lot. I don't see this thing taking off until there's decent GPU acceleration in place. "Fast decoder" is highly relative.

clouddrover5• 4 years ago

I tried decoding a measly 2 mbit/s AV1 test clip on a 2014 MacBook Pro with a 2.2 GHz Quad-Core Intel Core i7 and it was buttery smooth.

jbk8• 4 years ago

older Core 2 Duo MacBook Pro

Core 2 Duo are processors from 16 years ago...

Mobile phones are more powerful than those machines...

ksec4• 4 years ago

Is 4K60 on a phone possible?

Depends on SoC. A15? or low end UniSoC SoC? But generally speaking a modern Smartphone should be able to play 1080P 25fps 1mbps AV1 video on their phone without dropping frames. You will just be burning away your battery life.

powersnail2• 4 years ago

What's the state of the art AV1 encoder right now? Is it practical to encode hours-long videos on regular personal computers now?

ksec4• 4 years ago

If you want quality your choice is still limited to the reference encoder libaom.

coldpie2• 4 years ago

svtav1 is the best I've found, personally. Unlike libaom, it's parallelized, which obviously helps massively. I use it at quality profile 20 (as given to ffmpeg params), but I'm not an expert here.

goombacloud• 4 years ago

There is also https://github.com/xiph/rav1e

rie_t2• 4 years ago

SVT-AV1 has massively improved encoding speed. I was getting ~4x encode speed with some heavy compression (barely any noticeable quality drop) on 1080p/24fps footage on my Ryzen 7 3700X just yesterday.

powersnail2• 4 years ago

4x means that you can encode with 1/4 the time of the video, right? That sounds nice, a lot more practical than when I tried before.

webmobdev• 4 years ago

To get a rough idea - is it faster or slower than HEVC encoding on a CPU (without any hardware encoder)?

zanny2• 4 years ago

I use either aom for trying to make "optimized" encodes of things to get quality at the smallest file size or svt for fast encodes that aren't really any more efficient than h265, just with the better codec.

I just transcoded some movies with vmaf of 98% from 4k hdr blurays this last week. Takes about two days of mostly single core work with cpu-used=4 on a 5950x but they get average bitrates of around 4400 kbps. Which is like, really, really good for hitting that quality target.

The trick is that since its mostly single core I just do 16 movies at a time, or 24 on my server.

jaytaylor• 4 years ago

I was like "wtf is vmaf?!"

Turns out it's $NFLXs OSS automated encoding quality assessment tool. Pretty cool!

https://github.com/Netflix/vmaf

p.s. zanny, nice casual stealth drop you did there ;)

yupyup54133• 4 years ago

Best way to encode video is to use a scene detect algorithm to chunk up the video into multiple parts, configure your encoder to encode those parts with a single CPU thread, and spin off one thread per scene to your CPU's max amount of threads. You then just concat the scenes together afterwards.

elabajaba• 4 years ago

For anyone actually wanting to do this, Av1an handles all of it automatically for you.

https://github.com/master-of-zen/Av1an

ksec4• 4 years ago

Using the Netflix 1080P AV1 2Mbps Test clip, my old Macbook 2015 with a Intel Core i5-5287U ( Broadwell Dual Core 3.3Ghz ) just manage to play that at about 70% of the total CPU.

bertman• 4 years ago

For those that want to test decoding, here are the Netflix test clips: http://download.opencontent.netflix.com/?prefix=AV1/Chimera/

clouddrover5• 4 years ago

Or you can use YouTube with a browser which uses Dav1d like Firefox.

An AV1 example at 1080p50: https://www.youtube.com/watch?v=YhXtJWi2PjI

You can verify if YouTube videos are playing back in AV1 by right clicking on the video and choosing Stats for Nerds. The codec is av01 for AV1 video.

metadat• 4 years ago

Does this number doesn't mean anything by itself? How does the 2015 MBP i5 performance compare with other machines?

I didn't see benchmarks mentioned in TFA, please let me know if I've missed or overlooked something.

jbk8• 4 years ago

Tbh, those results are a bit surprising. We have much better results with similar hardware...

How are you testing? Is that dav1d 1.0? 8bit or 10bit content?

If you tested before 1.0 and 10bit content, you should run it again, since we pushed new optimizations for this.

ksec4• 4 years ago

We have much better results with similar hardware...

I should have included in the original comment this machines needs 60% to 70% CPU to play VP9 on similar bitrate / bit / frames. i.e Decoding on VP9 and AV1 are on a similar level of CPU usage. Considering the complexity of AV1, I thought this was an incredible achievement. ( It actually blows my mind this can be done )

I tested it on with 8 and 10 bit content the result aren't that much different. ( This is just eyeballing CPU usage in Activity Monitor ) The 3.3 Ghz was turbo, so it really should be 2.9Ghz Dual Core Broadwell CPU.

rie_t2• 4 years ago

I'm praying that Apple starts supporting AV1 soon...

mimsee2• 4 years ago

Apple is not really friend of royalty-free video formats. They hold some patents on h264/hvec and might see av1 as a competition.

galad872• 4 years ago

Apple is a "Founding Member" of Alliance for Open Media (which doesn't really mean they are actually a founding member). I think Apple main issues with VP9 was that it was a Google codec by all means. Apple already supports FLAC and Opus in macOS and iOS, and VP9 in Safari.

It could be that they are waiting to see if AV1 will actually get a marketshare outside Youtube or not.

zionic• 4 years ago

It's a shame. 90+% of their customers would hear "AV1" and think "Apple Video 1".

daneel_w8• 4 years ago

I'd say they are, but the real issue to Apple is how this or that format will affect their users and how it will portray their products. That is, whether or not they can decode the format without the device running hot, noisy and out of battery in 45 minutes. They like H.264/H.265 because users can decode them with high power-efficiency due to GPU- and dedicated hardware support. This is one of the greater benefits of formats that the whole world accepts and adopts.

The_rationalist4• 4 years ago

I'm praying they start supporting h266 soon because mankind progress matters more than politics.

sergiotapia2• 4 years ago

I'm thinking about buying the latest Roku Ultra because it says it support AV1 media format. Does it have a hardware decoder or how does it manage to do it when even my nvidia Shield Pro doesn't direct play av1 content?

https://www.roku.com/products/roku-ultra

thegoleffect• 4 years ago

The Ultra 2020 edition and onwards use the Realtek RTD1319 for av1 decoding.

(disclaimer: I used to work there)

at_a_remove• 4 years ago

I am so curious about the Roku and what is under the hood. They really do have a lot of value for the cost. Quirky at times, though.

sergiotapia2• 4 years ago

Thank you just ordered the device.

ac29• 4 years ago

my nvidia Shield Pro doesn't direct play av1

Even the newest Shield Pro is based on a 2015 SoC (Tegra-X1) with an integrated 2014 Nvidia GPU (Maxwell). Not surprising it doesnt support av1.

pantalaimon2• 4 years ago

Are there even any CPUs left with AVX-512?

mimsee2• 4 years ago

Alder lake has it and Apparently Zen 4 will have AVX-512 too

https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512

zucker42• 4 years ago

Alder lake's AVX-512 comes with a significant asterisk. It's only in the P-cores (so can only be turned on if you disable the E-cores), isn't officially supported, and can't be turned on in some motherboards IIRC.

We should be seeing better AVX-512 support with CPUs in the coming years though.

einpoklum• 4 years ago

According to that link, Zen 4 will only have a very limited kind of AVX-512 instructions, for working with half-precision floats. It won't even have the base AVX-512 instructions (the F set).

pantalaimon2• 4 years ago

had

It’s physically disabled in new CPUs

https://www.tomshardware.com/news/intel-nukes-alder-lake-avx...

rbultje• 4 years ago

Icelake and tigerlake. On AWS, this is m6i/c6i. [edit] earlier AWS machines (c5/m5) have AVX512 also, but not the subsets required by dav1d's assembly.

jbk8• 4 years ago

(President of VideoLAN here)

What you should really look at on dav1d is the fact that the code has now around 186 kLoC of hand-written assembly in .S and .asm files…

I think this is quite a feat (this is more asm than the whole FFmpeg) and this is very rare those days to write so much asm.

eikenberry2• 4 years ago

Reading this it sounds like you are discouraging using it due to the implementation being big and hard to maintain. Did you mean it this way?

jbk8• 4 years ago

I really can't see how you read anything else that "it's very optimized" in my message, tbh.

sethigh• 4 years ago

No. Most encoders/decoders need assembly to get last drop of performance. Most of the times it comes down to when you give up. The team here was quite relentless to build a usable AV1 decoder. A few years ago this was a pipe dream and jbk and team have done a tremendous job.

zbobet2012• 4 years ago

In addition to other noting that decoders and encoders almost all have an enormous amount of hand optimized code because they are literally the most demanding applications most people run (which is why most codecs today are hardware accelerated and they are used in almost all CPU benchmarks) 186k LOC (given that it's assembler which is nearly always "vertical code") is also relatively small for decoders.

People don't really get how complex video codecs are.

lta2• 4 years ago

It's not they're writing a library full of assembly for the sake of it. Reading the readme, one can discover they have dedicated optimised implementations for a large range of processors, which in turns means there's a lot of assembly involved

littlestymaar• 4 years ago

186 kLoC of hand-written assembly

That's for x86_64(SSE3, AVX2), ARMv7 and ARMv8 right? Is the 186kLoC equally distributed between those arch or is there one arch that has most of the optimization focus?

Is it all hand-written, or do you have some kind of script/macros to create a good part of this assembly (like OpenSSL does IIRC)?

jbk8• 4 years ago

All arch have the same level of optimizations, but AVX2 might have a couple functions more. AVX-512 is still behind…

Hand written with some macros, notably for the x86 mess (windows calling convention, ssse being 32 and 64b).

fulafel2• 4 years ago

I hope there's someone fuzzing all those variants well to find vulnerabilities, that's a lot of hand written code parsing untrusted data.

zinekeller• 4 years ago

It is tested by Google's OSS-Fuzz among others: https://github.com/google/oss-fuzz/tree/master/projects/dav1...

One of the bugs found by OSS-Fuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=11464

rurban• 4 years ago

pretty damning state of current compilers, I would conclude. I thought that they got much better in the meantime.

but having a look at clang or GCC, I can confirm. still baby steps, years ahead for proper optims.

FrostKiwi• 4 years ago

libdav1d when it was included in MPV was such an incredible experience. Prior to, my QX9300 Thinkpad didn't manage double digit fps with anything AV1 regardless of bitrate. The love and attention put into supporting older Vector extensions is insane and suddenly it managed playback of 8bit content without framedrops. Though I'm sure anything high-bitrate will smother that QX9300.

sylware2• 4 years ago

AV1 is for h265 and now h266 is "ready", I guess AV2 should see the light soon, shouldn't it? In the future, once mainstream CPUs cannot software decode in realtime compressed video/audio and only a specialized hardware block will be fast enough, will it be a "patent encumbered" format with tons of royalties?

edflsafoiewq• 4 years ago

This endless churn of video formats isn't sustainable if every one needs to have specialized hardware.

sylware2• 4 years ago

I was refering to the future: when the silicium will have hit its "best" (in a mass production context) and the video/audio compressed format of this future would not be able to be "software decoded" in real time by such "best silicium" CPUs: only a specialized hardware block would be able to decode such video/audio compressed format in real time.

The danger is this block only implementing the decoding of a non-royalty free/patent encumbered format à la mpeg, presuming the "intellectual property" was not globally fixed and still toxic like nowdays.

lta2• 4 years ago

Kudo to jbk, videolab and all the great people involved. Thanks folks ! Also the licensing approach is great <3

jonesnc• 4 years ago

Unrelated, but I'm curious if console emulators could gain performance by hand-writing certain parts of it in assembly (the JIT recompiler, for example).

tracker1• 4 years ago

As far as I know, a lot of console emulators have optimized assembly in places.

Eventually computing overcomes the need for optimized assembly and understandable code become more desired.

syntheweave• 4 years ago

As the number of code paths go up, the percentage of run-once code does too. Most findings agree that optimization increasingly tends towards a small number of hot loops which could benefit from hand optimization.

In modern codebases his has the effect of micro-optimization of the "rewrite in assembly" sort mattering a great deal in heavy lifting library code like codecs, CPU emulation, rasterizers, VMs etc, and not at all in other areas. Emulation is a decent candidate in this regard but it also massively benefits from higher level simplifying assumptions(e.g. not polling for I/O changes at the true device frequency). It can be hard to notice differences in emulation quality where high level techniques are applied well.

On old 8-bit architectures it was rather the opposite: you couldn't be high level about anything because you had to design towards micro-efficiency. Therefore most of your problems were solved with very simple data structures and algorithms that heavily favored either space(by recomputing the intermediate results) or time (by precomputing all answers in a LUT), and then given a very tight cycle-shaving, code-golfing implementation.

Dav1d, fast AV1 decoder, version 1.0

Related Stories