Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Add AV1 Encode / Decode support #457

Open
amboris opened this Issue Dec 28, 2016 · 30 comments

Comments

@amboris
Copy link

amboris commented Dec 28, 2016

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

@bradleysepos bradleysepos added this to the Unscheduled milestone Dec 28, 2016

@bradleysepos

This comment has been minimized.

Copy link
Member

bradleysepos commented Dec 28, 2016

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

@sr55

This comment has been minimized.

Copy link
Member

sr55 commented Dec 28, 2016

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

This comment has been minimized.

Copy link
Contributor

jstebbins commented Dec 28, 2016

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.

@Factuursimpel

This comment has been minimized.

Copy link

Factuursimpel commented Aug 24, 2017

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

@galad87

This comment has been minimized.

Copy link
Contributor

galad87 commented Aug 24, 2017

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

This comment has been minimized.

Copy link

horstle commented Mar 21, 2018

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

This comment has been minimized.

Copy link

jjanusch commented Mar 28, 2018

@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

This comment has been minimized.

Copy link
Member

sr55 commented Mar 28, 2018

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

This comment has been minimized.

Copy link
Contributor

jstebbins commented Mar 29, 2018

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

This comment has been minimized.

Copy link

adamhotep commented Apr 11, 2018

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

This comment has been minimized.

Copy link
Member

bradleysepos commented Apr 11, 2018

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

@jstebbins

This comment has been minimized.

Copy link
Contributor

jstebbins commented Apr 11, 2018

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

This comment has been minimized.

Copy link

adamhotep commented Apr 11, 2018

@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

This comment has been minimized.

Copy link
Contributor

jstebbins commented Apr 11, 2018

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

This comment has been minimized.

Copy link

kellerkindt commented Apr 11, 2018

@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

This comment has been minimized.

Copy link
Contributor

jstebbins commented Apr 11, 2018

@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

This comment has been minimized.

Copy link

Worldofmatthew commented Apr 11, 2018

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

@jstebbins

This comment has been minimized.

Copy link
Contributor

jstebbins commented Apr 11, 2018

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

@kellerkindt

This comment has been minimized.

Copy link

kellerkindt commented Apr 11, 2018

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

This comment has been minimized.

Copy link
Contributor

jstebbins commented Apr 11, 2018

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

This comment has been minimized.

Copy link

Worldofmatthew commented Apr 11, 2018

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

This comment has been minimized.

Copy link
Member

sr55 commented Apr 11, 2018

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

This comment has been minimized.

Copy link
Contributor

jstebbins commented Apr 11, 2018

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

This comment has been minimized.

Copy link
Member

bradleysepos commented Apr 11, 2018

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

This comment has been minimized.

Copy link
Contributor

jstebbins commented Apr 11, 2018

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

This comment has been minimized.

Copy link
Contributor

jstebbins commented Apr 11, 2018

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

This comment has been minimized.

Copy link
Contributor

jstebbins commented Apr 11, 2018

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

This comment has been minimized.

Copy link

DeeDeeG commented Jul 7, 2018

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

This comment has been minimized.

Copy link
Contributor

jstebbins commented Jul 8, 2018

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

This comment has been minimized.

Copy link
Member

sr55 commented Jul 8, 2018

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

@HandBrake HandBrake locked and limited conversation to collaborators Jul 8, 2018

@sr55 sr55 changed the title Feature request: AV1 support Feature request: Add AV1 Encode / Decode support Dec 20, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.