Feature request: Add AV1 Encode / Decode support

[amboris]

Please describe the problem or feature request in detail:

it makes no sense to support old VP8 and Theora or the VP9 when google and others have now a coop and created AV1 as http://aomedia.org/ for free to use.

Developer Note:

Implemented:

• Encode Support
• Decode Support (Available in nightly build)

[bradleysepos]

We'll look at this when it's practical to implement (once our upstream projects have full support).

[sr55]

It'll be interesting to if this gets the proper backing or not. Even now, VP9 isn't in the realm of usability for most people so what effectivly would be VP10 doesn't hold much promise :(

[jstebbins]

Theora is scheduled for the chopping block. We only keep it because the alternatve codecs vp8 and vp9 are relatively new to HandBrake and we wanted to give everyone ample time to update their custom presets before ripping it out from under them.

[dveldhoen]

Any update on this? AV1 has been officially released for some time now (March 2017).

[galad87]

Until they complete it there is little use for it, because they are still changing the bitstream, so encoded files won't be compatible with the final version of the codec.

[horstle]

According to golem.de there was a bitstream freeze recently. Any plans?

(german)
https://www.golem.de/news/videocodec-av1-ist-eingefroren-und-30-prozent-besser-als-vp9-1803-133457.html

[jjanusch]

@horstle Per the official website, AV1 was officially released today. https://aomedia.org/the-alliance-for-open-media-kickstarts-video-innovation-era-with-av1-release/

[sr55]

It'll be some time before encoders for this mature to the point of being acceptable for the project. So it'll probably be a good year or two based on past experience with previous encoders.

Either way, once we see a decent encoder become available, we'll look and decide when we want to add it.

[jstebbins]

If you read the full official announcement you would see that the only code available at this time is "Unoptimized, experimental software decoder and encoder to create and consume the bitstream". This is unlikely to yield an acceptable user experience, but when I get some time I will run some tests to see for myself.

Official announcement is here for those that are interested:
https://aomedia.org/the-alliance-for-open-media-kickstarts-video-innovation-era-with-av1-release/

[adamhotep]

AV1 has been deemed "practical" by Facebook, who demonstrated it's compression is 30% better than VP9. Their tests were mostly on SD and HD, but note that higher resolutions are supposed to be even more performant.

Quoting the article:

These results should give engineers confidence in how AV1 performs and speed up the adoption of AV1 in production systems. Based on our findings, software developers can look to add support for AV1 knowing it outperforms its efficiency targets in these real-world conditions.

Facebook will continue to promote the adoption of AV1 in our production systems. We plan to gradually serve AV1 content on web for popular Facebook videos once major web browsers such as Chrome and Firefox implement AV1 support. Users watching AV1 content will enjoy better quality at the same bit rate or see 30% to 50% less buffering at the same quality compared with VP9 or H.264/AVC content.

[bradleysepos]

@adamhotep Fair enough, but please note that HandBrake is an international team of developers you can count on one hand. Patches welcome.

[jstebbins]

Please, read the articles you are quoting. Facebooks definition of "practical" is that it's quality to file size ratio beats x264. As I said in my previous post, the available encoder is unoptimized, meaning it is SLOW. So I'll say this again. This is unlikely to yield an acceptable user experience.

From the article you linked:

On the other hand, the encoding computational complexity (in terms of encoding run time) of AV1 compared with x264 main, x264 high and libvpx-vp9 for CRF/QP mode was increased by factors of 5721.5x, 5869.9x and 658.5x, respectively, as shown in Figure 4.

I.e. The AV1 encoder is nearly 6000 times slower than x264.

[adamhotep]

@jstebbins Some of us don't care about encoding time, we care about the output. I didn't say AV1 was perfect, nor (to @bradleysepos's point) that I "expect" it presently. I merely called it out as something that would be nice to have and that should be added to the roadmap for when there is time to work on it. We're several years out from handbrake being seen as behind the ball for lacking it.

(Also, everything newer than x264 is notably slower to encode. VP9 is even an order of magnitude slower than x265.)

[jstebbins]

AV1 is already on our roadmap. I am simply making is clear where I believe it fits in that roadmap. And making it clear to others reading this thread how far AV1 has to go before HandBrake will consider inclusion.

When VP9 was first deemed "practical" by the various organizations pushing VP9, it was so slow that it literally would have taken a month to encode your typical feature length movie. We concluded this wasn't practical for the typical HandBrake user and therefore postponed integration of VP9 into HandBrake until it was made faster. Overnight encodes are acceptable I think. Week long encodes I think justify exclusion. It took the VP9 developers over 2 years to reach the state were inclusion in HandBrake was acceptable.

I haven't tried the AV1 encoder myself yet (but I will). Given the published numbers though, it sounds like encoding a feature length HD movie would take about 9000 hours (aka 1 year).

[kellerkindt]

@jstebbins I dont understand what encoding times have to do with the handbrake inclusion. Looking at the binary of handbrake with ldd, it shows me that its linked dynamically to the codecs (libmp3lame.so.0, libx264.so.148, libvorbis.so.0 and so on). So performance gains can be achieved and applied independently from the handbrake development? Looking at how long it can take for a new version of handbrake (or many other packages) to reach the end user, in ubuntu for example, I would appreciate an "early"-isch adoption.

I really appreciate the handbrake project and all your efforts and I am really happy using it! 👍
... I just dont get why slow encoders are blocking the AV1 integration (as it seems?)

[jstebbins]

@adamhotep I think you are looking at Table 3 where they are comparing quality metrics (PSNR and SSIM). The run time metrics are in Figure 4 (above table 3) and stated in a couple of paragraphs.

I see 2 places where they discuss "run time" comparisons. First is for CRF/QP encoding where they state AV1 is about 6000x slower than x264 (which is the passage I quoted earlier). Second is for ABR encoding where they state that AV1 is 8000x slower than x264.

You can find both passages easily by searching for "run time" in the article.

[Worldofmatthew]

jstebbins, You say that AV1 should not be in handbrake because of speed but why can't it be put into nightly?

[jstebbins]

Given the published numbers though, it sounds like encoding a feature length HD movie would take about 9000 hours (aka 1 year).

[kellerkindt]

Given the published numbers though, it sounds like encoding a feature length HD movie would take about 9000 hours (aka 1 year).

Yeah, but that is going to be improved. Why does it need to be fast before its integrated? Nobody expects it to be top priority, but please make the decision/scheduling independently from the encoding times.

[jstebbins]

You say that AV1 should not be in handbrake because of speed but why can't it be put into nightly?

If I get bored or someone contributes a clean patch with proper ifdef'ery to easily disable AV1 for release builds, then this is a possibility.

[Worldofmatthew]

My point is that nightly is more for the beta testers, the people who are perfectly fine with slower encode speeds. You never gave the other person why it matters that encoding speeds are slow for early adopters.

It appers to me that you have your fingers in your ears.

[sr55]

API surface changes, which makes improvements will likely not become available over time as you suggest. You can't for example, take an older HandBrake build with early x265 support and use a newer x265. The API changed.

I won't support adding this until it gets to a reasonable state.

[jstebbins]

You never gave the other person why it matters that encoding speeds are slow for early adopters.

Well, I thought it clear that an encode that takes a year to complete would be unhelpful to anyone but a developer that is working on AV1 to improve it. And AV1 developers probably aren't going to be using HandBrake as a frontend for their development.

[bradleysepos]

Well, I thought it clear that an encode that takes a year to complete would be unhelpful to anyone but a developer that is working on AV1 to improve it. And AV1 developers probably aren't going to be using HandBrake as a frontend for their development.

My thoughts exactly.

It appers to me that you have your fingers in your ears.

We're listening. We're just not agreeing this is a good use of our time at the moment.

[jstebbins]

Yeah, but that is going to be improved.

Maybe AV1 will be different. But as I already said (getting a bit bored of repeating myself), VP9 took 2 years to become usable in any meaningful way. Keeping something in the codebase for years as a toy for "advanced users" to play with isn't a productive use of the very limited HandBrake developers time.

[jstebbins]

It appers to me that you have your fingers in your ears.

Right back at-ya. I've had to repeat myself multiple times in this thread already. Seems nobody reads.

[jstebbins]

Why does it need to be fast before its integrated?

I NEVER said it needed to be fast. In fact what I said was:

Overnight encodes are acceptable I think. Week long encodes I think justify exclusion.

Greater than overnight and less than a week is a pretty generous margin and quite the opposite of "fast"

[DeeDeeG]

Hi all,

The aom repo has a v1.0.0 tag now. And the specification document for AV1 no longer claims to be a draft, instead basically saying "This version of the spec is tied to the v1.0.0 tag at the aom repo."

There is no official announcement from AOMedia about this yet, and I'm not even sure all the developers know of this milestone... but nonetheless it seems like a good opportunity to use the v1.0.0 tag if you all do decide to av1 support. If everyone does this, we can get some good interoperability going between all the programs than can encode/decode AV1.

Just my thoughts. Thanks for making HandBrake!

[jstebbins]

When it's ready, we'll work on it. It's not ready.

A new tag doesn't mean there's been any meaningful change. In fact I would be exceptionally surprised if much (if any) headway has been made on the speed of this encoder. These things just don't happen overnight. I expect this to take a year or more. And as I have said already (again repeating myself sigh) we will be monitoring progress and evaluating it's inclusion into HandBrake as things develop. Asking for support repeatedly changes nothing. So please, stop it.

[sr55]

I'm going to limit this topic to collaborators for now as it's not adding any value to the discussion with the repetition.

We will post updates if and when there are any meaningful changes that would indicate we are getting close to a usable encoder.

Thanks

[bradleysepos]

Decode support added by #1864 which is now merged.

[bradleysepos]

Info about SVT encoder(s) on #2313. TL;DR faster than most, requires more RAM than most consumer machines have in total.

[galad87]

Encode support has been added in 2763cb8, and there is an open pull request for rav1e.