SVT-AV1: open-source AV1 encoder and decoder | Hacker News Reader

SVT-AV1: open-source AV1 encoder and decoder

netflixtechblog.com

169 pointsCharlesW44 comments

No further mention of rav1e from Mozilla/Xiph/Vimeo, which seems like the more relevant benchmark comparison than libaom.

Why? rav1e doesn't yet achieve the same quality as libaom.

I definitely got better quality with rav1e than libaom (via ffmpeg), before I gave up on the latter altogether.

Here are some measured results. rav1e is worse than libaom and SVT-AV1:

https://www.reddit.com/r/AV1/comments/f1h2u1/aom_vs_rav1e_vs...

https://forum.doom9.org/showthread.php?p=1893776#post1893776

In numbers, yes, but, quoting from reddit:

``` I agree AOM is the best quality now. But between Rav1e and SVT-AV1 it's not so clear for me. When you look metrics, SVT-AV1 is clearly the winner. But when I do side to side comparison ( e.g with online comparison tool like https://svt.github.io/vivict/ ) for me SVT-AV1 blur too much and don't have the same details retention than rav1e and I found rav1e much more pleasant ( my opinion) . I hope at some point there will be some real human a/b testing study. ```

Perhaps things have improved for libaom since the last time I tried it but my issue wasn’t overall quality so much as sections of videos that had way too many very much visible artifacts (to me it looked like there were likely bugs rather than a poor design).

YouTube is using libaom for its many, many AV1 encodes. Without knowing the version you used or the settings you used there isn't much that can be usefully talked about. What we can say is that libaom is good enough to be used on the world's biggest video website.

I agree with the OP’s assessment - as recently as two weeks ago, Libaom was too slow to even do quality testing on real footage. And that’s with forty modern Xeon cores.

The fact that YouTube uses it only proves the increasingly obvious business model they use in the space, namely the monopolization of the encoding ecosystem by literally throwing away money to steer people clear of rav1e.

The practical reality is that libaom is benchmarked against routinely. It is the benchmark.

See some benchmarks here:

https://videocodectracker.dev/

https://arewecompressedyet.com/

A personal use and a company with massive computing power is so different.

They're the real-production-use competitors to me, since it's a performance vs. quality trade-off game. libaom is slow! In reality I am going to use SVT or rav1e, so anything that helps me pick ...

If the question is speed then the answer is SVT-AV1. It already does well versus libvpx VP9 and x265 HEVC:

https://medium.com/@ewoutterhoeven/av1-is-ready-for-prime-ti...

rav1e has a ways to go to match it.

AV1 Encoding is ready for prime time. However hardware decoder is mostly absent, which blocks adoption in mobile apps. (Dav1d is great, but consumes too much power on mobile devices)

The encoding still isn't ready for user driven content sites. It's still too slow, even with the 16% savings shown with the new improvements this article talks about. For Netflix it's great as they have a significant amount of time before content goes live (weeks if not months), but for sites like youtube/vimeo/instagram/etc, it just isn't quite there yet. The turnaround time is simply too long.

That's just the UX bottleneck, but there's another elephant in the room: it's cost prohibitive. Encoding time is so slow that we're still measuring in frames per minute for most software encoders. If I want to move my whole video encoding pipeline to AV1 from h264, I need around 100x the horsepower to encode. That's 100x the server costs, and as someone who's looking heavily at using AV1 for the video site I'm working on now, it's simply cost prohibitive.

Don't get me wrong, the steps that Netflix are taking with SVT-AV1 are amazing. We're seeing a huge improvement from the 500x vs h264 it was showing last year, but it still needs a huge amount of effort before it's ready for prime time. I'm really hoping we see some early hardware encoding/decoding implementations for AV1 given the number of companies who are in support of it.

> The encoding still isn't ready for user driven content sites.

YouTube has lots of AV1 encodes. You've probably watched AV1 encoded content without realising it. Here are a few of examples. To verify that they're AV1 encoded, right-click on the video and select "Stats for Nerds". I'm playing them in Firefox 75 beta.

Halo trailer: https://www.youtube.com/watch?v=Fmdb-KmlzD8

Despacito music video: https://www.youtube.com/watch?v=kJQP7kiw5Fk

Porsche Taycan commercial: https://www.youtube.com/watch?v=92sXWVxRr0g

For some videos YouTube has AV1 encodes up to 480p, others are up to 1080p, and some are up to 4K.

To be fair YouTube isn't (or wasn't a few months ago) at the stage where AV1 was earning it's place. They project that it will save them money in the future (widespread hardware decoder will let them send bigger encodes to more people) but at their video symposium they said that they were doing this at the moment as in investment for the future.

Which is cool, but means other orgs that are only interested in cost savings may not want to jump in quite yet (though they should probably be preparing so they can switch it in when that point arrives).

Vimeo is also using it: https://press.vimeo.com/61553-vimeo-introduces-support-for-r...

An example video: https://vimeo.com/362164795

Any reason why YouTube only uses it for low(er) resolutions?

The YouTube video library is huge so they're prioritizing encodes based on encode time (AV1 takes longer to encode), the ability to play it (more systems can play 480p AV1 than can play 4K AV1), and the number of views a video gets (if a video has a low view count then it doesn't much matter what it's encoded in).

Decoding is cheaper at low resolution.

> I'm really hoping we see some early hardware encoding/decoding implementations for AV1 given the number of companies who are in support of it.

Hardware decoding is fine. Hardware encoding is fine if you want to live-capture something. But if you want to optimize for quality/byte then hardware encoders usually fall short and I assume they would do even more so with something as complex as AV1.

I'm more curious why encoders are all-CPU and not offloading some parts of the search to GPGPU code.

The 2020 iPhones are rumored to have hardware AV1 decoders.

I seriously doubt that.

I wouldn't seriously doubt it. It will be fast enough to do it in software anyway. Netflix has rolled out AV1 to Android and you can opt-in if you want:

https://netflixtechblog.com/netflix-now-streaming-av1-on-and...

Let's look at the basic facts:

Apple is a governing member of AOM (Alliance for Open Media).

A patent-free implementation of a hardware AV1 decoder is available right now.

Apple makes its own chips with significant revisions every year. Apple seems to like being on the forefront of mobile silicon and already stuffs its chips full of things orders of magnitude more elaborate than this.

Apple now runs their own streaming network and being able to offer AV1 encodes stretches their bandwidth further. Consider also that iPhone chips of today inevitably become the Apple TV chips of tomorrow.

But most importantly of all, there's no commercial or competitive incentive for Apple not to do it. All of its serious competitors license the patent encumbered codecs and would need to continue doing so indefinitely just like Apple.

Depends if paying the license fee means much for Apple or not but if they're doing their own streaming, perhaps it does.

There is no license fees for streaming HEVC content online.

License fees are only paid to Blu-Ray / disc and Encoder / Decoder per Unit.

> However hardware decoder is mostly absent, which blocks adoption in mobile apps.

But HEVC is already in silicon, and that's the only thing that would matter in long run.

Vendors kinda don't get why they need to waste silicon on AV1, and for whose money.

Hardware support from vendors has been a key consideration from the inception of the AV1 project. ARM, Apple, Intel, Nvidia, and Samsung are among the governing members of AOM (developers of AV1), and AMD, Broadcom, Chips&Media, Realtek, and others are among the general members.

>Hardware support from vendors has been a key consideration from the inception of the AV1 project.

If that was the case AV1 spec version 1.0 would not have been postponed multiple times simply because the spec did not had any hardware decoder cost / performance in mind. And then there was the errata to version 1.0 which makes it incompatible to AV1 1.0. [1] Those vendors being a member of AOM means literally just a member only. They may or may not share any common interest.

[1] https://codecs.multimedia.cx/2018/12/why-i-am-sceptical-abou...

> Hardware support from vendors has been a key consideration from the inception of the AV1 project.

This doesn't change the fact that HEVC got into silicon faster, and that was it.

> Vendors kinda don't get why they need to waste silicon on AV1, and for whose money.

I'm not an expert on HEVC or AV1 specifically, but in my experience the fundamental operations used by codecs are quite similar. You don't necessarily need significantly more silicon to add AV1-support.

Remember that power-consumption is the main driver in IC development these days. It's not unreasonable to keep some dark silicon around to save power when needed.

Why does Netflix publish articles on paywalled websites? Are they aware that users need to pay Medium to read their articles? I get this error: "You’ve reached the end of your free member preview for this month. Become a member now for $5/month to read this story and get unlimited access to all of the best stories on Medium."

The medium publishing flow is weird, let me look at this and see if i can fix it.

Edit: Update, it looks like the story is not opted into distribution / should not be part of the paywall.

Can anyone from Medium chime in?

Clear the cookies, and use it

Are you aware that users need to pay Netflix to watch their videos? They believe in pay-for-content. If it is right for their videos, why should it be wrong for their articles?

>Why does Netflix publish articles on paywalled websites?

Maybe nobody there can figure out how to set up a web server? Maybe they get a kickback from Medium subscriptions? So many questions.

You can usually bypass the paywall with the archiver: https://archive.ph/gv8T6

> Maybe nobody there can figure out how to set up a web server?

Huh? It's their business for sake.

Nice.

> For estimating encoding times, we used Intel(R) Xeon(R) Platinum 8170 CPU @ 2.10GHz machine with 52 physical cores and 96 GB of RAM, with 60 jobs running in parallel.

Would love to see some comparisons with amd, at some point.

Is there currently an easy way to run this on multiple machines? Back in the day, I'd probably try a single image cluster, like openmosix - but I'm not aware of anything similar for modern setups - neither self-host or "hardware on tap"?

> Would love to see some comparisons with amd

Here are some comparisons of various SVT-AV1 releases on Intel and AMD CPUs:

https://openbenchmarking.org/showdown/pts/svt-av1

Thanks. Nice to see 60fps 1080p is within reach for certain profiles. Anyone know how big the difference is up to 4k for typical video? Is it more or less than 4x?

>The results are presented for 1-pass mode with fixed frame-level QP offsets. A single-threaded compression mode is used.

Why is it 1-Pass? and if I may, use the word "again". Every time when it is compared to LibAOM, it is always one pass.

There's a 2 pass comparison in the article. The graph comes from their comparison site which uses 2 pass encoding for both SVT-AV1 and libaom:

https://videocodectracker.dev/

Seeing the title I thought this was something developed by the Swedish public service broadcasting company SVT, which also has a pretty extensive online streaming service and so it wouldn't be too far fetched an idea that they might work on something like this. Finally – I thought – taxpayer money being out to good use.

Anyway, cool tech, well done! Hope it takes off and hardware encoders/decoders start to become common place as well.

Reply on news.ycombinator.com