```
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.
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 ...
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.
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).
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).
> 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.
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:
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.
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.
> 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."
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?
> 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"?
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?
