Alliance for Open Media codecs

[mzso]

av1 is less than 1%
:stupid:

So row-mt would improve it to 2%? What relevance does that have? So far it had zero performance optimizations. (As far as I know)

[wiak]

So row-mt would improve it to 2%? What relevance does that have? So far it had zero performance optimizations. (As far as I know)

hehe its so slow even time would be waiting for it to end before the universe does :D

[mandarinka]

The EVE vp9 encoder claims to have better compression and offer faster encode times than x265.

Treat those claims like you would any marketing speak. It might be made by FFmpeg/open source guy, but it is still a vendor marketing pitch, he obviously only states things that make Eve look good.

After all, the thing is not publicly available, so nobody can really prove the claims.

[hajj_3]

Treat those claims like you would any marketing speak. It might be made by FFmpeg/open source guy, but it is still a vendor marketing pitch, he obviously only states things that make Eve look good.

After all, the thing is not publicly available, so nobody can really prove the claims.
They seem to imply that google and netflix use the eve encoder.

[Djfe]

might be, it's probably not that hard to improve vp9 for someone like him, and he worked at Google creating vp8 and vp9.

it certainly can be better, but that doesn't proof that it's always better (how he implies it), since the test samples can be constructed to get the statistics he wants.

"I only believe in statistics that I doctored myself"

I'm very certain, that it's better than libvpx in every way so it's likely that Google and especially Netflix (being big content providers) are interested in these gains.
but that doesn't make his statistics into a proof.

[mandarinka]

Yeah, it should definitely be better than libvpx, that's why Ronald Bultje (the author) wrote it after all! Not sure if Google uses it. At least for youtube they used to stick to libpvx and just didn't seem to care much about problems it has/had.

(Note that I didn't want to suggest the claims are outright dirty lies, just that thing the authors would claim tend to be one-sided, be it with On2, AV1, this case, x264/MCW...)

[Mystery Keeper]

libvps does have problems though.
I reported this critical bug a year ago, and they still haven't gotten to fixing it.
https://bugs.chromium.org/p/webm/issues/detail?id=1380&q=component%3Alibvpx&colspec=ID%20Pri%20mstone%20ReleaseBlock%20Type%20Component%20Status%20Owner%20Summary

[mzso]

By the way. Is AVIF getting finalized in parralel with AV1?
Or is that something that will happen later, if at all?

[bstrobl]

By the way. Is AVIF getting finalized in parralel with AV1?
Or is that something that will happen later, if at all?

I think they are standardising an AV1 still frame so that hardware decoders can be used to decode images in future. Container support in AVIF will come later since video is a priority.

[bstrobl]

New Xiph blog post:

https://people.xiph.org/~xiphmont/demo/av1/demo1.shtml

[mzso]

I think they are standardising an AV1 still frame so that hardware decoders can be used to decode images in future. Container support in AVIF will come later since video is a priority.
The mention "animation" for AVIF. So they're going to do that with I frames?
This sounds remarkably counter-intuitive to me. Take only the I frames of a video codec, then make a half-assed video format ("animation") out of it.

[bstrobl]

The mention "animation" for AVIF. So they're going to do that with I frames?
This sounds remarkably counter-intuitive to me. Take only the I frames of a video codec, then make a half-assed video format ("animation") out of it.

From what I can tell the still image header is optional and mainly designed to save a few bytes: https://aomedia-review.googlesource.com/c/aom/+/54781

I am going to take an educated guess and say that they will include Inter-frame compression for timed image sequences, just like HEIF/HEIC does, as it would be silly to waste storage not including it while reclaiming a few bytes in the header. It is possible that the logic for those components will be shifted to the P frames themselves to allow very basic decoders to deal with single frame images, as each frame is stored separately.

[Clare]

AV1 beats x264 and libvpx-vp9 in practical use case

https://code.facebook.com/posts/253852078523394/av1-beats-x264-and-libvpx-vp9-in-practical-use-case/

[foxyshadis]

New Xiph blog post:

https://people.xiph.org/~xiphmont/demo/av1/demo1.shtml

Whoa, awesome. Monty's posts are some of the best reading out there on the state of the art of AV compression, glad to see him back.

AV1 beats x264 and libvpx-vp9 in practical use case

https://code.facebook.com/posts/253852078523394/av1-beats-x264-and-libvpx-vp9-in-practical-use-case/

Interesting how they didn't even bother with x265. They've obviously rejected it for licensing reasons, even if they haven't ever said so. The encoding time increase for AV1 though... wow.

[iwod]

Interesting how they didn't even bother with x265. They've obviously rejected it for licensing reasons, even if they haven't ever said so. The encoding time increase for AV1 though... wow.

I think somewhere along the line of HEVC licensing, one or all of the HEVC guys ( MPEG / HEVC Advance or Valos ) must have seriously pissed off these companies. I can literally smell and taste their hatred on HEVC, and vowed not to use it in their life time sort of attitude.

[Shevach]

AV1 supports 1/8-pel motion precision (optional, specified by frame header parameter - allow_high_precision_mv). i wonder what's a gain in coding efficiency to exploit high MV precision? In HEVC and AVC the precision is 1/4-pel (for luma). In case of high-frequency video (HFR) or even for 60 fps 1/8-pel probably is redundant. Perhaps, 1/8-pel MV precision is beneficial for 4K resolution with 30 fps rate?
Unlike to HEVC development (where all was public and all discussions/contributions were located at jct-vc repository), some AV1's decisions are non-graspable to me. Who knows - under what circumstances 1/8-pel motion vector precision is beneficial vs. 1/4 pel one?

[Shevach]

Maybe for low-resolutions and low frequency sub-pixel movements achieve the 1/8 granularity?

[ianken]

With a current FFMPEG build I get 0.2 fps on 1080p content. And that's a single stream.

To use this for next-day TV VOD it needs to be...faster. Or, maybe the ffmpeg integration is not fully baked? The CPU certainly is not loaded in any appreciable way. It's not even clocking up.

[Tommy Carrot]

The bitstream is not frozen, so you should use av1 only for testing... but currently it's too slow even for that. ;) Once it is frozen, i expect the speed optimizations will come fairly quickly. Their stated goal is around a hundred times faster encoding speed at the end of the year. Hopefully with not significant quality drop.

[vidschlub]

Could you tell me where I can find this filter on x265? I went through its documentation and found nothing applicable.

You might need to set a +film flag or disable 'nograin' I honestly can't recall, I'm really a newbie at best, others here can help.

I've done a lot of side by side comparisons and if you don't have the side by side, you can trick yourself into thinking it's better, but a lot of detail is lost and washed out.

Someone here will know for sure.

[foxyshadis]

AV1 supports 1/8-pel motion precision (optional, specified by frame header parameter - allow_high_precision_mv). i wonder what's a gain in coding efficiency to exploit high MV precision? In HEVC and AVC the precision is 1/4-pel (for luma). In case of high-frequency video (HFR) or even for 60 fps 1/8-pel probably is redundant. Perhaps, 1/8-pel MV precision is beneficial for 4K resolution with 30 fps rate?
Unlike to HEVC development (where all was public and all discussions/contributions were located at jct-vc repository), some AV1's decisions are non-graspable to me. Who knows - under what circumstances 1/8-pel motion vector precision is beneficial vs. 1/4 pel one?

Doesn't seem to have ever been discussed in public. I bet it was a test an engineer inserted and it was just never removed; I wonder if it's ever been used in real life.

[nevcairiel]

VP9 already had 1/8 pel MV precision, it was probably just inherited from there.

[colinhunt]

Harmonic showed a comparison demo at NAB, pitting AV1, AVC, HEVC and JVET against each other. At the equivalent bitrate of 1.9 Mbps they got the following results:

Codec -- PSNR -- VMAF

AVC -- 32.7 -- 58
HEVC -- 36.7 -- 80
AV1 -- 37.2 -- 83
JVET -- 38.5 -- 88

That's all the info I got.

[LigH]

They still use PSNR? :rolleyes: Don't we prefer SSIM/dB today? Well, VMAF is more like that.

What does it prove? ... More computational complexity is the solution? We need more supercomputers. :o

This statement might contain sarcasm.

[iwod]

Harmonic showed a comparison demo at NAB, pitting AV1, AVC, HEVC and JVET against each other. At the equivalent bitrate of 1.9 Mbps they got the following results:

Codec -- PSNR -- VMAF

AVC -- 32.7 -- 58
HEVC -- 36.7 -- 80
AV1 -- 37.2 -- 83
JVET -- 38.5 -- 88

That's all the info I got.

VMAF 80 vs 83......

Um.....

[LigH]

For this one selected sample, maybe? Many show demos pick the one comparison with the results making the own preferred product look best. I do not even see any link to this show here (maybe colinhunt was there in person?).

[colinhunt]

^ No, I wasn't, just happened to bump into a short video of the demo (and the scores) on Twitter.

[enctac]

AV1 vs x265 / libvpx-vp9 / x264 / QSV(H.264,LA-ICQ)

Clip: Animation, 1920x1080, 335frames(13.972sec)
Metric: VMAF, SSIM

https://i.imgur.com/9l5xVZX.jpg

[mzso]

AV1 vs x265 / libvpx-vp9 / x264 / QSV(H.264,LA-ICQ)

Clip: Animation, 1920x1080, 335frames(13.972sec)
Metric: VMAF, SSIM

16311

The attachment will never get approved, you need to upload it somewhere else.

[iwod]

That is x265 doing surprisingly well.

[Phanton_13]

enctac for Vp9 in comparisons I recomend to disable frame-parallel as is at outdated feature and use row-mt because in my tests it don't hurt quality and inprove speed (in reality row-mt has highther metrics but the variation is so low that statistically is insignicant, it has a variance of 0.0002 for ssim scores and 0.04 for vmaf scores). Plus apart of CPU 0 is also interesting to use CPU 1 an least one time in the comparison.

[dissory]

Can anyone please explain this for dummies?

How good is AV1 in comparison to HEVC in terms of quality and size right now (and will these get better over time or are they pretty much done with most major improvements)?

[LigH]

As usual, it is impossible to give a guaranteed ratio of efficiency between two codecs, it always depends on the material processed with it, as well as how annoying a specific person rates the loss.

The development of both HEVC (x265) and AV1 is not yet done, and AV1 is in a much earlier stage (it has not even many speed-up techniques implemented yet). But it is already considerably more efficient than x265. Unfortunately, it also requires a lot more time to encode.

[dissory]

But it is already considerably more efficient than x265.

Any rough estimate % on how much more efficient on average?

[LigH]

At its current speed, I don't have the patience to run elaborate test sequences, they would probably take months without using a "render park".

And how much difference does it mean to you whether it is 10% or 15% or 20%? Where is your personal threshold for ... which action?

[mzso]

What are the odds that youtube won't use AV1's increased efficiency to decrease bandwidth further instead of increasing the crummy quality?
I expect they're not good.

[LigH]

Because AV1 software is not yet mature enough, neither as encoder nor as decoder. If you have a device which has a hard time playing FullHD HEVC and can't handle UHD HEVC in real time, then do not even consider trying to play AV1.

The AOM is just even in the process to release specifications. There was no time yet to speed-optimize any software implementation. And without specifications being officially finalized, no hardware producer would be a fool to already release accelerating decoder chips.

[Blue_MiSfit]

Clearly a very long way to go.

Development of psy is of course critical in getting good subjective quality. In the tests I've seen the encoder still favors blurring heavily which smells a lot like simple PSNR tuning ;)

Also, hopefully AV1 avoids the pitfall of VP9 - terrible rate control.

Provided these issues are handled, the encoding speed comes up and fast software decoders plus hardware decoders come out, I'd see AV1 being quite useful on the web - specifically in Chrome and Firefox, since these will likely never get HEVC support.

As a premium OTT service operator, I struggle to see the value in it, however, since DRM standards only allow for delivery of 480p (and in some cases 720p) on Chrome and Firefox due to the insecurity of Widevine on these platforms. One of the biggest value propositions for using a new codec is being able to deliver high resolution video. If my DRM requirements prevent this, there's less incentive to spend the cost to make yet another video format.

The way I see it, we'll have to keep making H.264 basically forever, we have to make HEVC today to deliver UHD + HDR video to all the 10 foot endpoints plus some mobile devices, and that is an increasingly mature ecosystem with high quality today. VP9 is an option, but it's moot for us since everything that supports VP9 also supports HEVC, and practical HEVC encoders are better than libvpx.

What does adding AV1 get me?

[iwod]

Can anyone please explain this for dummies?

How good is AV1 in comparison to HEVC in terms of quality and size right now (and will these get better over time or are they pretty much done with most major improvements)?

If you look at the graph, it is not too hard to tell, at 5Mbps or below, x265 is about the same ( or better ) as AV1 in terms of quality for this clip. ( Anime )

My Personal Opinion, judging from small amount of testing and limited information, AV1 is the same or ( 10 - 20% ) better. ( Bitrate Reduction ). That is at the expense of 500x to 1000x+ encoding time. And as said, AV1 encoder is not optimised for speed yet, expect the final to be around 6 - 10x encoding time.

[MoSal]

If you look at the graph, it is not too hard to tell, at 5Mbps or below, x265 is about the same ( or better ) as AV1 in terms of quality for this clip. ( Anime )


Look closer (--cpu-used=2 and --cpu-used=1).

[user822]

I would say that the film grain synthesis is something that no one has really looked at yet in tests, that will be a huge advantage over HEVC.
Screenshots below are from

Bluray Source (125MB H264)
aom-master 2pass cq-level=40 (cpu-used=2 film-grain-test=1 bit-depth=10) (8.3MB)
x265-master 2pass bitrate=2025 (preset=placebo output-depth=10) (8.0MB)

Frame 1:
Src (https://i.imgur.com/sGlSjgF.png), x265 (https://i.imgur.com/4dxUOZD.png), aom (https://i.imgur.com/619PaXz.png)
Frame 2:
Src (https://i.imgur.com/x4PWzw9.png), x265 (https://i.imgur.com/MJX4FPc.png), aom (https://i.imgur.com/8VeGM8t.png)

[mzso]

I would say that the film grain synthesis is something that no one has really looked at yet in tests, that will be a huge advantage over HEVC.
Screenshots below are from

Bluray Source (125MB H264)
aom-master 2pass cq-level=40 (cpu-used=2 film-grain-test=1 bit-depth=10) (8.3MB)
x265-master 2pass bitrate=2025 (preset=placebo output-depth=10) (8.0MB)

Frame 1:
Src (https://i.imgur.com/sGlSjgF.png), x265 (https://i.imgur.com/4dxUOZD.png), aom (https://i.imgur.com/619PaXz.png)
Frame 2:
Src (https://i.imgur.com/x4PWzw9.png), x265 (https://i.imgur.com/MJX4FPc.png), aom (https://i.imgur.com/8VeGM8t.png)

I still think it's the worst idea ever. Time would have been better spent creating an extraordinary grain filter that leaves useful detail intact. (as much as realistically possible)

Out of curiosity, can the synthesis part (but not the removal.) be disabled (or defeated) to see how it looks without it?

[sneaker_ger]

I still think it's the worst idea ever. Time would have been better spent creating an extraordinary grain filter that leaves useful detail intact.
That can be done purely as an encoder-side feature and it's not like degraining filters are something new. No need to have something done for the bitstream freeze.

[MoSal]

I would say that the film grain synthesis is something that no one has really looked at yet in tests, that will be a huge advantage over HEVC.


If content providers use it.

I definitely look for the day where I no longer need to use the sharpening filter shortcuts I added to my player configuration.

[mzso]

If content providers use it.

I definitely look for the day where I no longer need to use the sharpening filter shortcuts I added to my player configuration.

How is that? I only feel the need to disable sharpening if the video is atrociously grainy/noisy. This keep-grain feature doesn't help with this at all. It might make it worse though.

[MoSal]

How is that? I only feel the need to disable sharpening if the video is atrociously grainy/noisy. This keep-grain feature doesn't help with this at all. It might make it worse though.


I don't disable sharpening. I enable sharpening as I can't stand the smoothness of many videos.

I basically have this in ~/.mpv/input.conf:


k add sharpen +0.25
K add sharpen -0.25


Values between 0.75 and 1.25 look good for my eyes.

And I already use ewa_lanczossharp for scaling.

[Barough]

AOM AV1 v0.1.0-9264-gbce84eb0b (http://www.mediafire.com/file/zaq4vp3j7b9cf3n/)
Built on April 19, 2018, GCC 7.3.0

https://aomedia.googlesource.com/aom

[foxyshadis]

HM and JM both had a rudimentary implementation of FGM, and they never made it into any of the commercial or major free encoders or decoders. I hope AV1's makes it into the wild, because that's one of the features I most sorely miss for mid-to-low bitrate encoding. There wouldn't be such a thing as "too smooth" at normal bitrates anymore; HEVC has really suffered among video enthusiasts because of that.

[mzso]

With a current FFMPEG build I get 0.2 fps on 1080p content. And that's a single stream.

To use this for next-day TV VOD it needs to be...faster. Or, maybe the ffmpeg integration is not fully baked? The CPU certainly is not loaded in any appreciable way. It's not even clocking up.

Oh, cool, at least we won't need to wait for it to get into ffmpeg. I missed this comment before. Although I think I'll hold back on trying it until some performance improvements land.

(BTW, It's been mentioned a bunch of times that they didn't do any performance optimizations in libaom.)

[LigH]

AOM v0.1.0-9271-gd6499b0cd