AV1 Video Codec

[boxerab]

Video on current state of open source royalty-free codec poised
to take over the web (once hardware is released in 2019)

https://gstconf.ubicast.tv/videos/av...arly-complete/

[Jyrki Alakuijala]

Video on current state of open source royalty-free codec poised
to take over the web (once hardware is released in 2019)

https://gstconf.ubicast.tv/videos/av...arly-complete/

Khavish shows it's very good performance with photographs at https://encode.su/threads/2814-Psych...e-codecs/page3

On SSIMULACRA it is the winner, on Butteraugli only PIK and Guetzli can beat it.

I have done quite some eye balling of PIK and AV1, and I like PIK a lot better at high quality (>1 bpp) and AV1 better at low quality (<1 bpp). PIK is quite a lot more simple and is currently around 200x faster to decode on software using a single core. If we add some post-processing (like adaptive Gaussian blurring) into PIK, we can make it competitive at lower bpp, too, but then the speed advantage reduces to around 10-20x faster than AV1.

[Darek]

https://wccftech.com/open-source-cod...specification/
I don't know if it's something new in AV1 topic but I've just found it.

[load]

i don't know anything about it, but i did encode a very small (about 70 seconds and about 240p) movie with it, and boy, it was ridiculously slow.
took almost an hour. i know this isn't optimized for speed at all yet, but still...

maybe i have done something wrong, but AFAIR people @doom9 said about the same a while back.

[jethro]

i don't know anything about it, but i did encode a very small (about 70 seconds and about 240p) movie with it, and boy, it was ridiculously slow.
took almost an hour. i know this isn't optimized for speed at all yet, but still...

maybe i have done something wrong, but AFAIR people @doom9 said about the same a while back.

No, it is mega slow and quality is not amazing either. I would even say that will take many years (min. 3) before it could compete with x265 in practical uses. And maybe we will have to wait some more to achieve that with AV2.

[WinnieW]

The AV1 codec is not primarly inteded for home users. It's for commercial use cases, because they can afford encoding via cloud computing. The main advantage of AV1 is the companies don't have to pay any license fees to use that codec.
The competing HEVC codec is not for free.
Netflix stated they can save millions of Dollars by using AV1 instead of HEVC.

[load]

No, it is mega slow and quality is not amazing either.

exactly. first i thought there's something wrong with my compile.

The AV1 codec is not primarly inteded for home users.

that's what i thought too.
but how about decoding speed? i couldn't find a player that was able to play what i encoded, i did compile the newest source, only about 10 days ago.

Netflix stated they can save millions of Dollars by using AV1 instead of HEVC.

maybe they only calculated the bandwith, but not how much it will take to encode?
but i guess for some million $$ you can get a lot of CPU power or whatever will be needed.

[WinnieW]

but how about decoding speed?

I don't know for sure. The developers of AV1 claim "comparable to HEVC", iirc. But I've to do a search first to find that statement again.

maybe they only calculated the bandwith, but not how much it will take to encode?

The statement of Netflix was about saving license fees for HEVC. Encoding has to be done only once, but saving a few Mbyte of data per stream and user can save a lot of money too.

[quikee]

The AV1 codec is not primarly inteded for home users. It's for commercial use cases, because they can afford encoding via cloud computing. The main advantage of AV1 is the companies don't have to pay any license fees to use that codec.
The competing HEVC codec is not for free.
Netflix stated they can save millions of Dollars by using AV1 instead of HEVC.

That's naive thinking. Even when they own data centers (Google for example) it is much more cost effective to optimize the encoder so they can encode more things in the same time frame or encode the video in shorter time and use the CPU power for other things like renting it to others. One of the first users of AV1 will be youtube where it is quite important to get the video rendered in a reasonable time (1-2 hour, not days). Then there is cisco which is mostly just interested in real-time encoding for their web conferencing solutions, so is Google (for hangouts) and Microsoft (Skype), where the encoder needs to be speeded up so much to be able to encode a 720P or 1080P video in real time. Also as for Netflix, they already invested in VP9 to optimize the encoder for more speed (more efficient multi-threaded encoding) so of course optimizing for speed is important for everyone.

The reason the encoder is currently slow is that optimizing for speed is mainly getting in the way and would be meaningless (why model something when it could change the next day) until the bitstream is frozen and this is quite normal in the codec design. Also BTW the bitstream isn't frozen yet (not as long the specs have a "draft" marker) but in a "soft" freeze (looking for bugs and finishing the specs).

Anyway, AV1 complexity wise is estimated to be about 30% more complex than VP9 so encoding and decoding. Anyway aomenc will be speed up to a reasonable speeds, but also other codecs will emerge which are faster and have better quality. My hope currently is on rav1e.

[WinnieW]

I don't have any insider information, but there must be both a reason and a motivation for companies to invest a lot of money in the development of a new video codec.

I see that the codec have to be both capable of real-time encoding as well as efficient offline encoding. In the real-time encoding mode the coding effiency drops inevitably.
There is still not enough info about AV1 for video-conferencing.

Some more info about AV1:
http://www.streamingmedia.com/Articl...in-124134.aspx

A quote from the linked article:

Encoding times are currently about 100X slower than VP9, which ... will drop to 5X by the end of the year. For decode, AOM is currently about 5X slower then VP9 on the x86 platform, which should drop to 2X by the end of 2018.

...and I guess there is a lot of potential to speed up the process both of encoding and decoding by using the calculation power of GPU and DSP.
ARM, AMD, Intel and nVidia are members of AOM.

[Jarek]

https://codecs.multimedia.cx/2018/12...cal-about-av1/

[xcrh]

https://codecs.multimedia.cx/2018/12...cal-about-av1/

Let's partially disagree. As for me, if I would be allowed to select just one single, most annoying and troublesome misfeature of certain community or group, for encode.su it would be TUNNEL VISION. Look, almost everyone of local experts got their minds totally stuck on damned PC, the very particular CPU/GPU model(s)/feature sets/api they have, often overinclined on one vendor/api, and so on. As the result, tunnel vision strikes as bad as it could. People start to optimize their algos for some very particular corner case - damn PC they have. Utterly ignoring any other use cases around and how their algos perform there, etc. Eventually it leads to overspecialized algos & programs that only perform reasonably under very particular assumptions. Which may or may not happen and surely not a good approach for general-purpose video codec or something like this.

Somehow, looking into activity in AOM git, I think group around AOM managed to become waaaaaay more balanced and diverse thanks to inclusion of HW vendors, caring about non-x86 archs like ARM and to less extent others, etc. I wonder why some ppl think it is okay to disregard all these concerns and use cases, only caring how that thing performs on their PC here and now, while not really bothering e.g. what it takes to implement it in hardware or make it faster on something different than their overgrown i7 CPU, etc, or what happens if GPU is from different vendor, etc. Development around AOM is rather interesting showcase on how to develop software the way it also "convenient" to be turned into HW blocks, and overall rather interesting attempt on trying to balance vastly different requirements and priorities.

As for politic games... well, Apple still holds considerable market share on mobile devices. Users do use these to watch videos online. Should apple not be part of the process, mission is somewhat failed - since it wouldn't be enough to put just one kind of file on server to be playable everywhere. Even if it plays everywhere but apple devices, it implies everyone have to store some "fallback content", grossly suboptimal and duplicate. Or face rage of millions of apple devices users. Historically apple has been extremely troublesome and uncooperative patent troll, so if some politics manages to downconvert them into something less toxic than that, it probably good overall, even if takes debatable action.

As for ecosystem, are there any better ones? ISO fell into utterly corrupt decision making schemes, only serving patent trolls fat incomes and screwing even that, as seen on h.265 example. They dare to release abstract specs as "so called standard", others have to spend plenty of efforts implementing something real on their own - while dodging or feeding patent trolls, "because ISO lacks resources" (a really lame excuse of patent troll representatives). ISO is solely responsible for miserable situation with video in the web. That organization has managed to stiffle progress, innovations and services for more than 10 years.

I would agree decision making could be improved, but so far, compared to ISO it gone way further than just feeding patent trolls while calling it "standards" and releasing totally unworkable reference software under some really lame excuses. AV1 is a big step forward in this regard.

As for performance and encode farms, blahblah, more recent versions got rather heavy tuning and optimizations, being considerably faster and using less mem than 1.0. So speaking for myself I managed to encode (uncompressed) 480p BBB to shy 500kbps target without easily noticeable artifacts and TOS3k 1080p sequence to 1Mbps target. I would not readily name any other codec on the planet capable of this level of compression vs quality tradeoff. And it isn't like if I'm really excited to see what ISO could spit out if they would keep their weird processes in place like it happened to h.26x family of codecs and also some image compression, it seems.

I'm pretty sure things could be improved further, like Daala's PVQ, etc - that seems to be dropped mostly due to timing constraints and amount of efforts needed to get it performing reasonably with rest of codec core. If one sticks on improving things for too long, it eventually leads to yet another fail of software development: nothing would be released, ever. It's possible to chase perfect state of things forever. So at some point this chase have to stop and whateve is already here is to be released to avoid this fate. Even if it looks somewhat imperfect and could be improved.

[Jyrki Alakuijala]

I agree with this. AV1 can offer incredible quality for the bitrate, especially so in the low bitrates. The reference implementation is impractically slow however.

[comp1]

Not to hijack the thread, but what about xvc?
https://github.com/divideon/xvc

I played around with it about a year ago and it if I remember correctly, it was better than AV1 at low bitrates.

[Jyrki Alakuijala]

Not to hijack the thread, but what about xvc?
https://github.com/divideon/xvc

I played around with it about a year ago and it if I remember correctly, it was better than AV1 at low bitrates.

Interesting. Better at what? For example, on SSIM, PSNR or on human rater(s)?

[Sportman]

Better at what? For example, on SSIM, PSNR or on human rater(s)?

https://xvc.io/concept/performance/
https://www.ietf.org/archive/id/draf...tvc-xvc-01.txt

[moisesmcardona]

I've been doing a couple of encoding tests using rav1e. You can see them at my site:

https://moisescardona.me/rav1e-encod...-2019-01-14-15
https://moisescardona.me/rav1e-encod...-2019-01-13-14

Needs an AV1-compatible web browser (Edge with the AV1 extension, Firefox or Chrome)

[WinnieW]

There is also Versatile Video Coding (VVC) which is the official successor to HEVC / H.265.
AV1 and VVC share the same drawback. A lot of processing power is needed for encoding.

I found a presentation on YT about VVC


It seems to me that some features in VVC are ideas taken from AV1. AV1 is even mentioned in the video a few times .

[comp1]

Interesting. Better at what? For example, on SSIM, PSNR or on human rater(s)?

I believe it won in SSIM comparisons. It may have also won with PSNR.

Sorry I don't remember and I do not have results anymore. But for very low bitrates, xvc is worth testing and comparing.

[moisesmcardona]

There is also Versatile Video Coding (VVC) which is the official successor to HEVC / H.265.
AV1 and VVC share the same drawback. A lot of processing power is needed for encoding.

I found a presentation on YT about VVC


It seems to me that some features in VVC are ideas taken from AV1. AV1 is even mentioned in the video a few times .

And let's not forget that AV1 is royalty free codec

[WinnieW]

I know that AV1 is royalty free... but... there is one area you don't have a choice. I you want to watch videos from a content provider the provider already made the choice which codec to use; your only choice is stop watching videos from the content provider.

[Jarek]

Wow, even more intraprediction vectors and split modes next decade ... while meanwhile, a few person WaveOne went from image to video compression in 1.5 years: http://www.wave.one/video-compression/
(thread: https://encode.su/threads/3023-Machi...ion-(GAN-VAE-) ).

For example finally doing motion prediction right - not block based, but as interpolated continuous vector field:
... but most importantly no longer relying on engineers manually increasing the number of options, but neural networks directly optimizing parameters based on datasets of real images - to directly encode in the space of real images, which is muuuch smaller than the space of all bitmaps.
Sorry but the old way is blind alley ...

[xcrh]

I agree with this. AV1 can offer incredible quality for the bitrate, especially so in the low bitrates. The reference implementation is impractically slow however.

Actually, it got improved hell a lot since last time I've gave it a try. So if trend continues this way, it would become usable for me in foreseeable future. Well, if I've encoded some sequences without being lucky owner of encode farms, it isn't THAT impractical, right? It already started to remind me early VP9. Not to mention videos are often encoded just once but then stored forever, copied more than once or served hell a lot. So ppl did "release early" part properly, releasing slow coded. But now they probably should also "release often", no? Like AOM 1.1 or at least 1.01 or so. Guess current version is faster/better enough for that.

[xcrh]

I know that AV1 is royalty free... but... there is one area you don't have a choice. I you want to watch videos from a content provider the provider already made the choice which codec to use; your only choice is stop watching videos from the content provider.

Then, most logical thing to do would be to obey decisions of your masters and don't bother self about codecs I guess. You'll do whatever they tell anyway - so what's the point?

[WinnieW]

The point is that the content provider has to pay license fees for using commerical codecs either. For the big players that can be millions of Dollar per years.
So the have to make a decision. Use a "good enough" free codec or pay license fee for a codec that has some benefits for them or the costumers.
For a content provider it's very difficult to use a codec that no consumer device support out of the box.

Encoding video in AV1 is not a reasonable idea for consumers, right now. Because there is no efficient AV1 encoder at that date.

[Sportman]

https://github.com/OpenVisualCloud/SVT-AV1

[dado023]

https://github.com/OpenVisualCloud/SVT-AV1

its a bit tricky to test, due to requirements for CPU Xeon® CPUs, E5-v4 or newer, and ram :\

[Jyrki Alakuijala]

its a bit tricky to test, due to requirements for CPU Xeon® CPUs, E5-v4 or newer, and ram :\

I'd be interested in reading about experiences with it.

[dado023]

I'd be interested in reading about experiences with it.

Well, according to their spec....
copy/paste from github:


The hardware i have is AMD 16 threads with 16GB, which would be enough for 1080p.
I am curios to test it, if anyone could compile it for WIN 64bit

[moisesmcardona]

I did a test but the video came out with frame rate problems.

See here:

Encoded with SVT-AV1: https://drive.google.com/file/d/1x3R...ew?usp=sharing
Encoded with rav1e: https://drive.google.com/file/d/1BtT...ew?usp=sharing

I posted a reddit post with more details here: https://www.reddit.com/r/AV1/comment...vs_rav1e_test/

it's not a fair comparison because the settings between rav1e and SVT-AV1 are different, but still, it's nice to see another encoder around

I hope they improve it