AV1 Release | Hacker News Reader

AV1 Release

aomedia.org

312 pointsthemihai105 comments

I am more looking forward to future release. The current version is mostly a bitstream freeze. And it is anywhere from few hundred to few thousands times slower at encoding. While the current version isn't optimized at all, I wonder how long would it take them to reach, say within 5x the speed of x265.

In another news, we have xvc, which is taking most of the H.266 purposed ideas into its implementation. And it is already showing 30% better compression then AV1.

Note: AOMedia have also updated its website.[1] One thing i notice is Apple is the only one not using its Logo in the member site. And this feels a little strange.

[1]https://aomedia.org/membership/members/

I figured everyone understood this, but you are right, it bears spelling out:

Any modern [video] compression format is extremely flexible and allow great liberty for the compressor (whereas the decompressor is strictly defined). This means that there is ample room for work on improving the quality and efficiency of the compressor for years to come.

In other words, AV1, the spec, isn't some magical unicorn. It's the sandbox in which the 'corns can be raised.

Compressing a video looks like a huge decision tree to me, and newer standards add more interdependencies and more variables at each stage. I'd expect that the resulting optimization problems approximated by encoders are computationally difficult. (Which would explain why they always get better even after many years)

Short answer: yes Long answer: yes

My personal analogy for this is that video encoding standards are basically like toolkits for building houses, while encoding software is like a robot trained to build those houses using the tools in question. New standards bring new tools to the toolkit, but training the robots to use them effectively is going to take its time and is often even worse than the previous robots in the beginning simply because the older robots have gotten so proficient with their respective toolkits. x264 in particular is basically the top robot in this department and the standard which any new entrants should aim to beat both in quality (not necessarily too hard) and in time efficiency (which is the much bigger challenge).

I don't think time efficiency is the primary concern for the big encoders like Netflix and YouTube. They're more interested in lowering the bitrate while maintaining image quality and are willing to throw compute resources at slower encoders which achieve that. Netflix, for example, does multiple encodes per scene in multiple formats to get the best possible quality for each format for each scene.

VP9 outperforms H.264 (libvpx versus x264) for Netflix's use case. Here are some articles from the Netflix TechBlog on their experiences with VP9 and their encoding approach in general:

https://medium.com/netflix-techblog/optimized-shot-based-enc...

https://medium.com/netflix-techblog/more-efficient-mobile-en...

https://medium.com/netflix-techblog/netflix-downloads-on-and...

You're right, time efficiency certainly isn't as big of a concern for companies with effectively infinite resources to throw at encoding, but the rest of us probably want to finish our encodes within this decade :) (the reference AV1 encoder is extremely slow)

Time efficiency is still important for live streaming. Last time I checked (OK that was one year ago) x265 was way too slow for live, even at not so high resolution.

Bitmovin produced an AV1 live stream a year ago using 200 cores: https://bitmovin.com/bitmovin-supports-av1-encoding-vod-live...

And six months ago they had improved on that to do live streaming with 32 cores: https://bitmovin.com/constantly-evolving-video-landscape-dis...

So I'll be interested to read about any live streaming demos they do at NAB in the next couple of weeks.

It's impressive that AV1 allows so much parallelism. That's great news.

It is a concern even for Netflix. The number only starts to make sense assuming a 30% bitrate reduction and 5x speed encoding time. This means the current encoder needs to speed up anywhere from 50x to 500x to get to that point.

Imagine if Netflix spends 1M on encoding, even 5x is 4M more, and the current encoder is anywhere from 250M to 2.5B more. This is not a small sum of money.

I think before they talk about speed up, they just need to iron out all the bugs and bitstream freeze before we speak.

Netflix have said they'll roll it out once it's below 5x slower.

But they can start with only the most popular videos to get the most bang per buck, they'll also likely target geographic areas with low bandwidth but decent spec desktops, which means they're getting a return on investment by increasing reach, not just saving bandwidth.

So basically, there's plenty of niches where it makes sense almost as soon as the spec is frozen and they can expand the roll out as it proves itself and speeds up.

> I am more looking forward to future release. The current version is mostly a bitstream freeze.

It's not even a bitstream freeze. This 'release' was put out by the marking folks, and wasn't even discussed with people on the AOM list (I'm part of AOM via VideoLAN). The bitstream remains under development.

Near as I can tell this is just a PR piece before NAB.

Oh Christ. I thought they were fast, only last week they said they have a few bugs still left to be fixed. ( And only last month they said they were still listening to hardware makers on suggestions and changes to improve decoding speed )

Thanks for pointing this out.

One reason why I dont like / trust the folks at On2 / VP8, it is nice AOMedia now has folks like you to keep them honest and humble.

Have a nice day.

There is concerted effort on the AOM list to finish and close all bugs or features that require normative bitstream changes, so I would expect it isn't too much longer. The number of remaining issues is small-ish, but not zero.

The involvement of hardware people has been a boon, though tough for software people at times :).

Oh no :( I monitor the AV1 bugs, and repos and was indeed puzzled to see this. So it hasn't actually been released. OMG, this is really bad and could backfire.

Even following the things above, it can be pretty hard to see what's going on.

EDIT: mailing list is not accessibly, had some bits flipped in my wetware

I check bugs and repos often, but I don't know about the mailing list, where is it located?

The AOM engineering list and kavi tracker is restricted to members of organizations in AOM, as far as I am aware.

Oops, I mixed up TLS and AV1. Right, mailing list is off limits to me.

Potentially unrelated but having run events with Apple as a sponsor in the past, they are especially stringent on how/if they allow you to use their logo or branding. We were also forced to go this route.

I'm trying to make sense of the xvc licensing. Is it some sort of weird licensing joke?

It is if you think about it from a patents and licensing perspective. However I will try to take another spin to it which might be something they are trying to do without actually saying it.

They implement all the H.266 JVET ideas and tools into xvc. Not every one will make it into the standard due to speed, politics or whatever. Once the H.266 has been standardise, they now have a decent working encoder they could turn on the the features are in JVET and be the first JVET encoder on the market.

The JVET working group knows there is a threat in Royalty free codec like AV1. So I am hoping they take the patents and cost into account. But given how Qualcomm, Ericsson, Sharp has been acting in HEVC i am not entirely sure it will be smooth. Or if JVET has a future at all.

This is awesome. I started tracking AV1 and TLS 1.3 1.5 years ago and they arrived within days of each other.

I hope AV1 will get the kind of love that got us the x264 encoder.

EDIT: my timeline was slightly off and reworded is make it clear I understand the difference between spec and implementation.

It's a nitpick, but a necessary one.

x264 is a codec. An implementation of H.264 standard.

x264 is loved because it is very optimized and fine-tuned. There are plenty of H.264 implementations that aren't.

We're probably not going to see AV1 implementations on the same level as x264 for at least a few years.

I am COMPLETELY aware of the difference and I was deliberate in writing that. We need the kind of love, hard and excellent work on AV1 software (encoder is the harder, being open ended) that brought us the x264 encoder. AV1 decoders will come aplenty I have no doubt and I'm hoping for a good FPGA implementation.

That was entirely the point of the comment that you replied to correct.

It's correct that av1 based on vp9? So vp9 codecs exists and can be used as start for av1 implementation?

The base was VP10 + tools from Thor (Cisco) and Daala (Xiph.Org/Mozilla), and it evolved from there to AV1 through a process of "experiments", test, IP checks and then its enablement.

Assuming that VP10 shares a significant base design with VP9 it would not be surprising if some part of VP9 sillicons decoders could be leveraged on customer hardware, while awaiting for more dedicated circuits.

But on the software end, libaom (AOM reference implementation) is indeed a fork of libvpx. But this library is not broadly considered a good implementation, even for VP9. Pehaps the guys behind EVE for VP9 [1] will produce an AV1 implementation based of their codebase.

[1] https://www.twoorioles.com/eve-for-vp9/

Hopefully fast implementations won't be proprietary like EVE is.

>We're probably not going to see AV1 implementations on the same level as x264 for at least a few years.

True, on that note, over at the Doom9 forums, the x265 spokesperson there said that they will consider making a AV1 encoder should there be a market.

Given the massive amount of support gathered for AV1 from web and hardware giants, and how it's a royalty free codec and thus in a great position to be the next generation 'de facto' video standard on the web, I'd wager there is a good market for a third party encoder from excellent developers like those behind x265.

VideoLAN's president, jbkempf, was considering finding manpower to build an AV1 implementation a couple months ago. Not sure of the status now.

There's already a Rust AV1 encoder project you might want to look at: https://github.com/xiph/rav1e

Indeed! This implementation was started by some people working on AV1 to test libaom's specification implementation correctness. There was a presentation about it at VDD17, if I remember correctly.

Interesting, but since I could conceivably be exposed to a malicious AV1 stream, I'd value a Rust AV1 decoder even more (which might exist, I don't know).

That's a very good point. I chose Rust more to get ergonomics and more reliable threading - security was not the primary motivation. That said, the encoder is exposed directly to the web via the MediaRecorder API.

> There's already a Rust AV1 encoder

80% of codebase is C. How is that Rust encoder? Seems like a binding to C AV1 encoder.

The C part is mostly for low-level functions and was brought in to help bootstrap development (it's easier to work on improving a working encoder than one that doesn't work yet). The amount of Rust code is expected to increase a lot over time, while the amount of C code is expected to either decrease or remain constant.

The github counter is misleading - it is counting auto-generated C headers used for calling assembly code. The repo also contains a libaom submodule, but the only parts that are used are initialization tables and the transforms.

This hits me too on some projects of mine. Infuriating. I find wrong stats worse than no stats.

The stats aren't wrong. If it isn't 'real code' then you shouldn't store it in your repository, you should autogenerate it as part of your build process.

Isn't AoMedia supposed to provide a reference implementation? Is there any reason not to use it (an patch it along the way)?

It’s crap and slow as molasses built off an inferior earlier encoder’s codebase. It proves the concept, but it’s not something you want to need rely on in production.

Can't edit anymore, but as Daemon404 points out. It's a paper release. Nothing to see here, move along.

What is missing in the announcement is a link to a quality / bitrate comparison with perceptual quality. Netflix seems to have a good automated perceptual metric. PSNR is still a popular metric because it's "objective", but codecs optimized for PSNR produce ugly, blurry results, like all the VPx codecs. That said, a codec with great PSNR can probably be tuned for great perceptual results.

The Vorbis people, who were involved in AV1, have produced some impressive perceptual improvements even with inferior technology (Ogg Theora, based on VP3.2), so they know what to do and how: https://people.xiph.org/~xiphmont/demo/theora/demo9.html

It's not going to be decipherable without some help to point you to what to compare and how to read the charts, but https://arewecompressedyet.com/ contains many such comparisons and is what they use to evaluate branches and features, etc. The Daala team has mostly focused on four metrics, of which PSNR is just one and probably the least valued. PSNR-HVS-M is the "hardest" one, but it also includes SSIM and another SSIM variant.

I'm sure one of the team will chime in shortly pointing to some recent results.

Moscow State University's most recent codec comparison included subjective evaluations of image quality:

http://www.streamingmedia.com/Articles/News/Online-Video-New...

It is anywhere between 20% to 45% improvement depending on sources and metric used, at the cost of 100s to 1000s time slower encoding speed.

Note current encoder isn't optimized for speed yet.

I noticed a while back AV1 flag was added to Chrome Canary, but I can't find any videos on the web to test it on.

Firefox Nighly can play https://demo.bitmovin.com/public/firefox/av1/

try http://reference.dashif.org/dash.js/v2.6.5/samples/dash-if-r... on canary

Works, thx. Is that video the only one available? Also, it's capped at 720p 800kbps, anything higher? Would love to see how it does at 4k.

This will shake up the digital media industry. You can safely bet on this format, it's going to stay for long and promisses extremely good compression quality ratio.

> This will shake up the digital media industry. You can safely bet on this format…

(1) Maybe (2) Not today, and realistically not for a few years (if ever). "Standard" (whether de jure or de facto) compressed media formats (e.g. MP3, AAC, H.264) depend on an ecosystem of supporting products and services, and the existence of that ecosystem for any given format can't be assumed.

But how good is the quality? I watched the Mozilla Demo and at the 30 second mark the "Robot Hand" distorted the green trees in the Background. Even at 720p@800kbps. Haven't noticed this with other hevc encodes at similar bitrates.

https://demo.bitmovin.com/public/firefox/av1/

Bitmovin's comparison: https://bitmovin.com/av1-multi-codec-dash-dataset/

MSU's comparison from a couple of months ago: http://www.streamingmedia.com/Articles/News/Online-Video-New...

The x265 guys complained about the recent MSU test: http://www.x265.org/x265-incorrectly-represented-msus-2017-c...

Judging a codec by any one single frame isn't really good enough.

The samples _and_ performance metrics used have to be quite varied.

That is a really weird distortion effect. I don't know if I would have noticed without you pointing it out, but it almost made me feel seasick.

Actually had to double check this to make sure it wasn't in the sources. It seems the the encoder basically sees the trees as only having a small difference, but really visually it's quite large. The solution is a better distortion function in the encoder - libaom's is simple but dumb. (luckily this means no decoder or format changes)

I can only hope that AV1 is gonna get some traction. It's hard to believe since MPEG-4 and HEVC are already everywhere.

I know that the AOMedia foundation was created in response to MPEG-4 HEVC licensing... Having an alternative might help getting rid of the HEVC!

> It's hard to believe since MPEG-4 and HEVC are already everywhere.

HEVC is far from being everywhere. Huge services like Youtube, Amazon Video, Netflix and others are going to use AV1, not H.265. H.265 is already dead, it just didn't admit defeat yet.

And Apple joining AV1 group was probably the nail in the coffin.

I don't think HEVC will go away; there's already a lot of fixed-function embedded hardware out there with HEVC decoders that will never get AV1 support. All the streaming players have to support those for the foreseeable future.

Hardware gets obsolete. Fees for HEVC do not, so new hardware won't be using it. For the legacy support, video services will use H.264 like Youtube does now. They just won't offer higher resolution in such cases, which is fine.

There's already tons of devices with H.265 encoders and decoders in hardware. Those aren't going anywhere anytime soon. Plenty of high resolution security cameras use H.265.

> There's already tons of devices with H.265 encoders and decoders in hardware.

Most of such devices also support H.264, which can be used as fallback for those who don't yet support AV1. H.265 isn't needed at all.

There will be some period when H.265 will linger around, but it will eventually die out.

Heh, is not that easy. The reason is simple: high resolution. iirc, for example, Netflix uses h.265 for 2k+ resolutions. They don't even allow 2k+ on hardware that do not have h.265 hardware decoder for that reason.

YouTube 4k also just use VP9 iirc. No H.264.

Not using high resolution for legacy cases, would be an incentive to update devices to those which support AV1. So it only helps this. Youtube does exactly that already.

> They don't even allow 2k+ on hardware that do not have h.265 hardware decoder for that reason.

So Netflix will swap this requirement from H.265 to AV1. Problem solved.

They don't do it for a long time, because that means they will have to KILL support for TVs, Xbox and laptops that already have 4k support. They just use hardware deciding (because of DRM).

Not kill, will just reduce the resolution for them and limit them to H.264 which they support. That would be an incentive to get a device which supports AV1 sooner if someone really needs that high resolution. I'm sure all AV1 backers will do it at some point.

Netflix and I assume Amazon already use H.265, so at best they can use AV1 in addition to H.265 in the future.

They'll simply drop H.265 when they'll deploy AV1. There would be no reason for them to waste all that money.

Netflix can't just drop support for my TV.

Oddly enough, the actual link to download the specification, reproduced below for your perusal, seems to link to outlook.com and includes a bunch of other interesting data:

https://na01.safelinks.protection.outlook.com/?url=https%3A%...

The URL embedded within, however, is directly accessible:

https://aomediacodec.github.io/av1-spec/av1-spec.pdf

Edit: I started reading the spec and found that the bulk of it it appears to be mostly fragments of de-semicolon'd C code and plenty of lookup tables; in other words, a lot of "how" but not much in the way of "why" or "what". There's a noticeable lack of diagrams as well --- IMHO very important for describing something as visual as a video codec. For comparison, I certainly found the H.264 spec to be much more understandable than this AV1 one.

That first link looks like it came from email that went through Office 365, probably copy pasted. We see the same in our Office 365 environment, links are re-written to redirect through outlook.com's safelinks service.

Congratulations! Now we need more adoption of hardware decoders for it. And then patented stuff will start being phased out everywhere.

> AOMedia Supporting Quotes

It's interesting, how Apple are notably missing from there. It's as if they want to keep their support quiet.

> And then patented stuff will start being phased out everywhere.

JPEG is patented, VP9 is patented, and AV1 is patented. Luckily, baseline JPEG is licensed under royalty-free terms and so are VP9 and AV1. The issue is never the patents but rather the licensing of those patents.

Patented as in patent rolls demanding fees for it. AV1 is not patented, as in trolls can get lost.

It's great to see all these companies working together on this.

All the more disappointing to see both Google and Microsoft embrace HEIF for images in their next operating system versions. They really couldn't wait another couple of years to develop an open AV1-based image format? Come on.

Who cares about what Apple does or doesn't do? Apple certainly doesn't seem to care what Google and Microsoft do, which is why it continues to ignore open standards like Vulkan and now went ahead and adopted another one of MPEG-LA's proprietary and patent-encumbered formats.

Because they couldn't wait, now we may be stuck with another proprietary standard for the web for another 20 years. Not to mention there could still be others besides MPEG-LA to claim patents on HEIF and accuse developers of infringement, just like it happened with HEVC. This mess could have been avoided with a little bit of patience.

> All the more disappointing to see both Google and Microsoft embrace HEIF for images

HEIF itself is a container format. It currently supports JPEG, H.264, and H.265 bitstreams:

https://github.com/nokiatech/heif

Nothing precludes AV1 from being contained in a HEIF file.

Nothing practical is precluding AV1 from being included, however:

> HEIF is a visual media container format standardized by the Moving Picture Experts Group (MPEG)

So corporate politics will surely prevent it from happening. That being said I did file a bug report:

https://github.com/nokiatech/heif/issues/46

Netflix is ahead of you:

https://aomediacodec.github.io/av1-avif/

Honestly, couldn't they just adapt WEBP for it? It's basically just an RIFF container with a VP8 key frame. Then again, it's WebP, and there's no need to bloat that thing anymore.

Edit: Nevermind, I see. Going by the document, it's meant to be an exact mirror to HEIF, but for AV1. Some interesting features too.

Translation: You still have to pay for the H.264/5 patents to read HEIF files.

No, the container format is independent of any video format patents. Nokia licenses their HEIF implementation under royalty-free terms:

https://github.com/nokiatech/heif/blob/master/LICENSE.TXT

My point is that if you claim to read HEIF files you need to read all possible HEIF files, including ones that contain H.264/5 data. Don't claim to support a standard if you don't support the most commonly-used part of it.

One thing I'd love to see follow from this is an image format based on its intra coding. The companies involved expressed interest (https://www.cnet.com/news/google-mozilla-av1-photo-format-co...), and tests (https://people.xiph.org/~tdaede/av1stilldemo/) look great.

The .heic format now used by iPhones is the same idea (https://en.wikipedia.org/wiki/High_Efficiency_Image_File_For...). But wider use of that is going to be constrained by the cost problem HEVC has in general (two patent pools to deal with). Some of WebP is based on VP8 (not VP9) intra coding too.

There are a lot of tools packed in AV1's intra coding (and HEVC's, though I've read less about that). Block sizes range from 4x4 to 64x64 and there's a mix within one image, so the encoder can use the right size for the level of detail in each area. There are more ways to predict a block's content from what's to the top and left, which leaves less work for the JPEGish DCT part. There's clever de-ringing post-processing that, in effect, blurs away many of the attention-getting JPEG-y DCT artifacts around edges, while 1) being aware of the direction of the main edge itself to avoid blurring that away and 2) using contrast thresholds to preserve as much other legitimate detail as it can--more about deringing at https://people.xiph.org/~jm/daala/deringing_demo/ .

(There's some good detailed discussion at https://parisvideotech.com/wp-content/uploads/2017/07/AOM-AV... and in Wikipedia's page at https://en.wikipedia.org/wiki/AV1 )

Relatedly, given the complexity, I wouldn't expect this to, like, take the world by storm in the next three months. The unoptimized encoder is still _really_ slow. Google has designed a hardware implementation, but of course hardware designs take time to get integrated, fabbed, and into shipping products. Given who's involved, I'm hopeful it does get wide support. (Would love to hear Apple's plans given their current support for x265; their decision to join AOMedia is a good sign at least.) Anyway, looking forward to seeing the results.

Good image formats for movie frames aren't necessarily good for stand-alone still images though...

There are differences--you're often willing to do more work decoding a still than a frame, say--and in the first story I linked there's a quote from a Googler wondering about whether to make the image format exactly track AV1 or to tweak it. So, there's a real question.

That said, the still demo at https://people.xiph.org/~tdaede/av1stilldemo/ is really encouraging, and Apple's seen a win in doing something parallel with HEVC/.heic. AV1's already gone through a lot of optimization and IP vetting (patents caused trouble for previously proposed replacements for JPEG), and has a hardware decoder design and a lot of companies signed on. Like everyone I just have to wait and see what they do, but I'm more or less on team "ship it" here.

On the other hand the bar for still images is very low due JPEGs dominance. That's why it makes sense to use video encoders for stills even if they are not ideal, you are still going to get much better results than JPEG.

There are at least 3-4 pools plus individual patent holders.

> Some of WebP is based on VP8 (not VP9) intra coding too

Quite an understatement. "Some" here means WebP is literally a single VP8 frame shoved into a RIFF container :D

Back in the day (holy shit 8 years ago already!) there was a script that added WebP support to WebM-supporting browsers by literally changing the container. Here it is: https://github.com/antimatter15/weppy/blob/master/weppy.js

These days there's a WebAssembly build of libwebp which enables WebP support in browsers which don't support it natively:

https://webmproject.github.io/libwebp-demo/webp_wasm/index.h...

I think it's an ideal use case for WebAssembly. It'd be a good way to roll out any future AV1-based image format until native support arrived in all browsers.

> "Some" here means WebP is literally a single VP8 frame shoved into a RIFF container :D

Though it's less used than the lossy format, lossless WebP is a thing too; if I said WebP was exactly VP8 intra someone might nitpick that. There's no winning, haha!

Heh, fun consequence I just realized is that, in theory, you don't even have to wait for video-based still formats to be standardized and deployed if you're willing to play some games with single-frame videos.

So, like, h.264-based "images" can be shown in most browsers now, and VP9-based in many (but not Safari or IE). And you can fake AV1 images as soon as you get AV1 video.

Using video decoding in an odd way like that probably isn't especially practical or wise, but fun that the capability's there/reachable.

Been a long time coming. Hoping to see some benchmarks and reviews soon.

Is ffmpeg able to encode to AV1?

No. With the bitstream only just frozen, I expect decoder/encoder wrappers for libaom to take a few months.

Is it expected that libaom will be the de facto standard open source enoder, like x264 is for h.264?

Who knows? But ffmpeg should be able to include multiple different encoding libraries for av1 regardless. libaom would be one of them at least.

The bitstream isn't frozen yet.

As an aside: A wrapper within FFmpeg for libaom is only a few hours work, but if you want to play with it Right Now, VLC has support. A native decoder will indeed take significantly longer though.

A wrapper within FFmpeg for libaom is only a few hours work

Batteries and bikeshedding on the Devel ML not included...

I was mistaken, one is already written, but not merged.

So we're already in bikeshed mode ;)

Mea culpa.

Already added - http://git.videolan.org/?p=ffmpeg.git;a=commit;h=0dc11d8bbd4... and http://git.videolan.org/?p=ffmpeg.git;a=commit;h=99cc3cf7a26...

No, but it has been added to VLC git master (cf. changelog [1]) as an experimental feature using libaom.

[1] https://git.videolan.org/?p=vlc.git;a=blob_plain;f=NEWS;hb=H...

GStreamer has support for AV1 in 1.14 if you want to use it today.

Reply on news.ycombinator.com