Alliance for Open Media codecs

[mzso]

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.

Well, at least it maximizes it's single-thread cpu utiliztation. I get constant 8.32-8.33 CPU utilization on my 12 (virtual) core system. :)

[Blue_MiSfit]

^^ Is it just me, or does that sound extremely optimistic?

The bitstream was supposed to be frozen about 18 months ago I think? Maybe they should be a bit more conservative with timelines.

[WhatZit]

Maybe they should be a bit more conservative with timelines.

Remember that the fundamental purpose behind AV1's existence is to spit in the eye of HEVC.

Should the AoM have published credible timelines, HEVC would have had ample opportunity to dodge out of the way of any expectoration. Whether they'd have actually taken advantage of those opportunities is another matter.

As it currently stands, the decision facing the streaming industry is this: with the rapid uptake of UHD/HDR consumer displays (aka immediate demand), do you implement a UHD delivery system NOW using HEVC's absurd licensing, or in 3 years time using AV1's open license?

That decision should be a no-brainer... if it weren't for the likes of Velos being in the HEVC patent pool.

So, if the AoM were able to convince those decision makers that they need only wait 1 year (irrespective of the timeline's veracity), HEVC gets it in the eye again.

[iwod]

^^ Is it just me, or does that sound extremely optimistic?

The bitstream was supposed to be frozen about 18 months ago I think? Maybe they should be a bit more conservative with timelines.

Also remember they are still pretty much the guys from On2, ( Or at least half of them ) anyone who has been in Doom9 long enough would know what they are like.

[foxyshadis]

Also remember they are still pretty much the guys from On2, ( Or at least half of them ) anyone who has been in Doom9 long enough would know what they are like.

I don't think there's that many On2 employees left; I think it's more a general quality of the AV industry to overpromise and underdeliver, and Google itself is well-known for unfounded enthusiasm for eternal betas. Kind of a match made in heaven, there.

[Clare]

Added AV1 to my comparison: https://wyohknott.github.io/video-formats-comparison/

I had to run it at cpu-used=4 to get a reasonable encode time so it's not representative of the max quality that could be obtained.

You can see that the encode speed is still infinitesimal.

[Shevach]

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.

Rationales of many AV1 features seem me vague. Woo-Jin Han in LinkedIn forum "AV1 Learning" commented 1/8-pel precision:
" It was proven that high precision mc is only effective for low resolution. Beyond 1080p, even 1/4 pel seems not very effective to justify its complexity. I remember that 1/4 pel shows 30% coding gain for famous Mobile CIF sequence (low res, complex texture, slow motion, aliasing from inadequate down sampler) but average 5-8% over various test sequences. Very high frame rate with non hierarchical structure may change the situation but it seems clear that it is highly sequence dependent tool"

I remember a paper "Motion-Compensating Prediction with Fractional-Pel Accuracy", by B. Girod, 1993 . If we omit a mathematical part of the article and go to the conclusion part, it's written (in my wording): for blocks 16x16 of TV video resolution 1/4-pel motion accuracy appears to be sufficient.

[Shevach]

AV1 enables to omit transmission of skip flags. Indeed, there is the frame-header parameter 'skip_mode_present' and if this parameter equals to 1 then the skip flags are not signalled. The rationale is clear, if we know 'a priory' that encoding of a given frame will not produce skip blocks then it's redundant to transmit skip flags.
Let's look at the situation from another view, what's a penalty in transmission of skip flags provided that all blocks are non-skipped?
Because i am not completely familiar with AV1 entropy coding process i consider AVC/HEVC arithmetic engine instead.
In HEVC/AVC the maximal probability of a symbol is ~0.98 and hence the number of bits produced by encoding a symbol having the maximal probability is -log2(0.98) = ~0.02 bits.
Let's suppose that we know ahead that all MBs will be no-skipped (i.e. skip_flag = 0 for each MB) and consequently the skip_flag syntax element gets maximal probability 0.98. In such case the total number of bits consumed by all skip flags is ~0.02 x Number_Mbs.
For example, HD resolution frame has usually 8100 MBs (16x16 grid) and hence the total size of all skip_flag syntax elements is ~8100 x 0.02 = 162 bits. It's negligible in most cases.
Probably AV1 frame level parameter 'skip_mode_present' (to disable transmission of skip flags) has a minimal impact on coding efficiency, although it increases the decoding complexity (more 'if-else').

[Shevach]

Added AV1 to my comparison: https://wyohknott.github.io/video-formats-comparison/

I had to run it at cpu-used=4 to get a reasonable encode time so it's not representative of the max quality that could be obtained.

You can see that the encode speed is still infinitesimal.

What's sense to check codecs with PSNR values 45 dB and greater?
According to HVS research all video with PSNR above 45 dB look perceptual identical to the original.

[Djfe]

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?

Use the NL-Means filter on Handbrake instead ;) (way too slow for an encoder but beautiful/very good IMO)


Another topic:
Good video to explain people what av1 is, why it was created and by whom etc. (the whole story):
https://youtu.be/lEdqN22vaWs

[wiak]

fresh build today
https://awesome.nwgat.ninja/av1/av1-3db7530-x64-nwgat.ninja.7z

[LigH]

AOM 0.1.0-9348-g589bae879

[mzso]

So, a month passed since the (not quite true) news about the bitstream being frozen. Are they closer at least?

[iwod]

So, a month passed since the (not quite true) news about the bitstream being frozen. Are they closer at least?

Yes, they are much closer now, as it was last month, and early this year, and late last year......

/s

Honestly, I think it is actually good they delay it. The one thing you don't want is a standard being rushed.

[wiak]

finally newer git builds decode older av1 encoded files, yey for progress
:stupid:

[TD-Linux]

In HEVC/AVC the maximal probability of a symbol is ~0.98 and hence the number of bits produced by encoding a symbol having the maximal probability is -log2(0.98) = ~0.02 bits.
Let's suppose that we know ahead that all MBs will be no-skipped (i.e. skip_flag = 0 for each MB) and consequently the skip_flag syntax element gets maximal probability 0.98. In such case the total number of bits consumed by all skip flags is ~0.02 x Number_Mbs.
For example, HD resolution frame has usually 8100 MBs (16x16 grid) and hence the total size of all skip_flag syntax elements is ~8100 x 0.02 = 162 bits. It's negligible in most cases.
Probably AV1 frame level parameter 'skip_mode_present' (to disable transmission of skip flags) has a minimal impact on coding efficiency, although it increases the decoding complexity (more 'if-else').

For AV1 it's even smaller, 1/65535 of a bit. However you'll need do adapt to that probability, so you'll burn more bits at the beginning of a frame. That said, the skip_mode_present doesn't control the skip flag but rather the skip_mode flag, which itself is a way to signal that you're going to use a "default" predictor. Still, the gains are pretty small, it's more of a speed savings to not have to code this flag if it's unused.

[wiak]

hey TD-Linux fancy meeting you here and in other news mpv windows builds finally has av1 decoding
https://sourceforge.net/projects/mpv-player-windows/files/64bit/

[LigH]

The media-autobuild_suite (https://github.com/jb-alvarado/media-autobuild_suite/) can help you building your up-to-date mpv as well, based on ffmpeg sources. So if mpv can play it, then ffmpeg may handle it as well? ... Yes:

DEV.L. av1 Alliance for Open Media AV1 (decoders: libaom-av1 ) (encoders: libaom-av1 )

[nevcairiel]

Until the bitstream is actually finally frozen, excitement about inclusion in software seems misplaced, since any current binary may not work anymore tomorrow. That should always be kept in mind. :)

[mzso]

Until the bitstream is actually finally frozen, excitement about inclusion in software seems misplaced, since any current binary may not work anymore tomorrow. That should always be kept in mind. :)

Well, it already can't play a few av1 encodes from a few weeks ago. :)

[Mierastor]

https://twitter.com/bitmovin/status/996084579952836608

[Pushman]

https://streaminglearningcenter.com/codecs/netflix-on-av1.html

Ronca: "We think that initial AV1 computational complexity of 4-10x vs. libvpx would be usable in production. There is a lot of work underway to improve the performance, and we are hopeful that the performance goals will be achieved."

[vidschlub]

Well, it already can't play a few av1 encodes from a few weeks ago. :)

Seriously? That sounds like it's really not ready for prime time.

[nevcairiel]

Seriously? That sounds like it's really not ready for prime time.

Its quite simply not done yet. We keep repeating that here regularly. :)
Until its finalized, noone should be using it outside of experimentation/testing.

[vidschlub]

Its quite simply not done yet. We keep repeating that here regularly. :)
Until its finalized, noone should be using it outside of experimentation/testing.

I got the impression from the news announcement that they'd frozen some element of the design, which was a big milestone?

I (wrongly?) assumed, it would just be optomisations and performance from here on out.

I look forward to it dominating, but maybe it's going to be several years?

[Phanton_13]

Actually from why I heard AV1 is frozen at the level of features, now they are working out implementations bugs and the only thing that is really work on is the bitstream.

[Blue_MiSfit]

^^ Where did you hear this?

[Phanton_13]

^^ Where did you hear this? More that heard is read as it was in a discusion on IRC but I'm not sure on the channel.

[bstrobl]

More that heard is read as it was in a discusion on IRC but I'm not sure on the channel.

https://freenode.logbot.info/aomedia/20180514

[foxyshadis]

I wish they'd taken a look at the eighth-pel issue before going into informal feature freeze, that's going to completely hamstring 4K adoption and probably hurt even at 1080p. Just performing the equivalent search as AVC or HEVC will take so much longer, just due to much higher memory pressure, even if you pretend it's q-pel and only look at every other pixel.

[nevcairiel]

Luckily encoders can choose to not use some feature if its deemed too slow, especially since 8-pel is optional anyway and has to be signaled in the frame header.

[foxyshadis]

Luckily encoders can choose to not use some feature if its deemed too slow, especially since 8-pel is optional anyway and has to be signaled in the frame header.

Ah, I'd been under the impression that it was a required feature. With a permissive spec, it doesn't matter.

[LigH]

AOM v0.1.0-9559-g59d2aa958

[TD-Linux]

I remember a paper "Motion-Compensating Prediction with Fractional-Pel Accuracy", by B. Girod, 1993 . If we omit a mathematical part of the article and go to the conclusion part, it's written (in my wording): for blocks 16x16 of TV video resolution 1/4-pel motion accuracy appears to be sufficient.

Others are correct in that 1/8-pel is inherited from VP9. That said, there are many reasons why the results from that 1993 paper may no longer be valid - for example, VP9 operates on up to 64x64 blocks (and 128x128 for AV1), meaning that spending an extra bit for a more precise MV can potentially have a much bigger payoff than in a codec limited to 16x16 prediction blocks.

It's also a relatively cheap feature to add - the subpel filters are already pretty large, so it's just adding another set of taps.

[Shevach]

Others are correct in that 1/8-pel is inherited from VP9. That said, there are many reasons why the results from that 1993 paper may no longer be valid - for example, VP9 operates on up to 64x64 blocks (and 128x128 for AV1), meaning that spending an extra bit for a more precise MV can potentially have a much bigger payoff than in a codec limited to 16x16 prediction blocks.

It's also a relatively cheap feature to add - the subpel filters are already pretty large, so it's just adding another set of taps.

The problem is not spending additional 'bin' per vector component but how many comparisons are added for motion estimation in 1/8-pel MV precision?

[LigH]

AOM 0.1.0-9658-g265d15d46

New CLI option:

--enable-fwd-kf=<arg> Enable forward reference keyframes

[mzso]

AOM 0.1.0-9658-g265d15d46

New CLI option:

--enable-fwd-kf=<arg> Enable forward reference keyframes

What does it do?

[benwaggoner]

What does it do?
Something like Open GOP or RADL, I'd guess.

[Mierastor]

"The new V76 is essentially the successor to Arm’s previous high-end video block, the Mali-V61, which was announced back in 2016. Understandably the world of video encoding and decoding doesn’t evolve at quite as brisk a pace as GPUs, so Arm generally only revises their video blocks at about half the frequency. ... this processor will not include any support for the upcoming AV1 codec. While the bitstream specification for the eagerly anticipated codec was released a couple of months back, the timing was unfortunately after Arm had already completed the V76 RTL (never mind the fact that the specification isn’t closed yet). So it’s going to have to be the next video block after the V76 before Arm can include AV1 decode support. ... The very high encoding requirements of AV1 also mean that even after a decoder ships in a phone, we’re unlikely to see a full-featured encoder in a phone any time soon."

https://www.anandtech.com/show/12835/arm-announces-maliv76-video-processor-planning-for-the-8k-video-future

[nevcairiel]

Its fascinating how the PR stunt from AOM managed to mislead everyone into thinking the bitstream is actually done. And months later, its still not actually done!

[Blue_MiSfit]

I guess it's still "wait and see".

I'm still not sure why I'd use AV1 as an OTT operator delivering 4k content. I have to make HEVC for everything that exists today. Even if AV1 ends up being a bit more efficient (and this comes down to encoder implementation) it will still cost me a huge amount of money to encode my library in both formats, so why would I?

I guess it all depends on what clients end up supporting it.

[Mr_Khyron]

Socionext Implements AV1 Encoder on FPGA over Cloud Service
http://socionextus.com/pressreleases/socionext-implements-av1-encoder-over-cloud-service/

[LigH]

AOM v0.1.0-9742-g4e7b6f08f

Somewhat related to AV1: Google would like to patent (r)ANS, a speed optimized kind of Arithmetic Coding, specifically for its use in a video codec – despite Jarek Duda (its main inventor) having released this algorithm already to Public Domain in 2014...

[iwod]

Its fascinating how the PR stunt from AOM managed to mislead everyone into thinking the bitstream is actually done. And months later, its still not actually done!

May be I am Old? Does any one remember On2? I mean if anyone who has been on Doom9 long enough should know. On2's "marketing", has been the same for years, even after it has been acquired by Google, and even many of the On2 employees left ( May be only the engineering left and not their marketing? ), their marketing hasn't changed a bit. And now it is Open Media Alliance, which is still pretty much ( Google + Mozilla ) + many others, with Av1, google is taking the majority of responsibility.

I guess it's still "wait and see".

I'm still not sure why I'd use AV1 as an OTT operator delivering 4k content. I have to make HEVC for everything that exists today. Even if AV1 ends up being a bit more efficient (and this comes down to encoder implementation) it will still cost me a huge amount of money to encode my library in both formats, so why would I?

I guess it all depends on what clients end up supporting it.

One of the reason were HEVC Advance were changing OTT operator % per stream. Which was ridiculous. It wasn't until this march did they decide to stop this terms. And Youtube ( Google ) and Netflix has a huge incentive to stop using HEVC because of this. Not to mention HEVC listening is a bag of hurt. Google and Netflix want to provide uses AVC as base and use VP9 / AV1 for everything else. So as a consumer if you want Youtube or Netflix 4K content you will have to buy a STB that support Vp9 or Av1. They won't be doing ANY HEVC content. One of the interesting thing is both Youtube and Netflix cant be watched in China, and while many "new" or "info" likes to claim they are the biggest in the "world". That "world" does not include China. Similar to how Amazon or eBay likes to claim they are the biggest X in the world, when compared to China they are at least 4 - 5 times smaller in sales volume. Since China is in Region 2, they paid much less and most of the devices are already shipped with HEVC, in fact they are already streaming HEVC whenever they can.


Somewhat related to AV1: Google would like to patent (r)ANS, a speed optimized kind of Arithmetic Coding, specifically for its use in a video codec – despite Jarek Duda (its main inventor) having released this algorithm already to Public Domain in 2014..

This has been mentioned multiple times, not sure if they are really against patent codec or against codec that don't use their patents portfolio.

Anyway I really hate this licensing terms and price discovery period. It has happened with AVC, and it is happening again with HEVC. The group or their members want to extract maximum outrageous prices, and waited for years of failure in market before they relent. I sometimes wonder if there are any more thing we could do with AVC to further improve it as an baseline.

[benwaggoner]

I guess it's still "wait and see".

I'm still not sure why I'd use AV1 as an OTT operator delivering 4k content. I have to make HEVC for everything that exists today. Even if AV1 ends up being a bit more efficient (and this comes down to encoder implementation) it will still cost me a huge amount of money to encode my library in both formats, so why would I?

I guess it all depends on what clients end up supporting it.
Assuming the prior codec has full penetration,
codec_value=decoder_penetration * quality_@_perf advantage

So AV1's success is driven by decoder_penetration and quality_@_perf. The latter is important; 15% better at 10x encoding time doesn't really count unless encoding time was already more than fast enough. When live encoding is needed, or if encoding compute is a limit, MIPS/pixel is the limiting factor, and so AV1 implementations will compete with H.264, VP9, and HEVC at the same MIPS/pixel.

If devices wind up providing just H.264 and AV1, than the decision driver is whether the added compute, storage cost, and cache dilution is worth it. Even if compute was free, at a large scale supporting another codec is a huge operational expense and system complexity increase.

[benwaggoner]

So as a consumer if you want Youtube or Netflix 4K content you will have to buy a STB that support Vp9 or Av1. They won't be doing ANY HEVC content.
Netflix is certainly delivering UHD on devices that don't have VP9 hardware decoder support. And VP9 is a particularly challenging bitstream format for software decoding without high single-core CPU performance (this is much improved in AV1).

Tons of SmartTV and STB-like devices have way less CPU than a typical phone, so software decoding at 2160p is a non-starter. And replacement cycles are way slower for TVs and STBs than for phones and tablets.

Even if AV1 is an incredible success, companies would still have to deliver HEVC for legacy living room devices in 2025+. Heck, they will still have to deliver H.264 in 2025 for a number of device categories.

Personal computers and phones/tablets are by far the easiest markets for fast integration of new codec support. And lots of enterprises were still doing corporate content in WMV/VC-1 until they'd deprecated XP and Vista.

Massively improved technologies get the market moving, but even the best improvements can take a long time to become universally available in many markets.

[amichaelt]

So as a consumer if you want Youtube or Netflix 4K content you will have to buy a STB that support Vp9 or Av1. They won't be doing ANY HEVC content.

So your claim is that Netflix will cut off the 10s of millions (though probably actually more) of devices that are already streaming 4K HEVC from their service? Yeah, right... :rolleyes: People are not going to buy a new TV or STB because of some silly codec war.

[IgorC]

It's not like VP9 isn't supported by any smart TVs.

I have bought 1,5 years ago LG smartTV. This year after upgrading the Youtube aplication it starts to support VP9 (stats for nerds reports it) and plays Youtube 4K without single drop.

[Blue_MiSfit]

Even if AV1 is an incredible success, companies would still have to deliver HEVC for legacy living room devices in 2025+. Heck, they will still have to deliver H.264 in 2025 for a number of device categories.

Exactly, and this is why (unless CDN delivery costs are the vast majority of your opex) I don't see why a premium OTT VOD service would use AV1 anytime soon.

[iwod]

So your claim is that Netflix will cut off the 10s of millions (though probably actually more) of devices that are already streaming 4K HEVC from their service? Yeah, right... :rolleyes: People are not going to buy a new TV or STB because of some silly codec war.

Well I should have removed Netflix from that sentence, I am not sure if all of their Catalog are in HEVC already. But Youtube certainly aren't doing any HEVC at all. ( At least for now )

Yes, The point is, HEVC is already included in most TV or STB.

Exactly, and this is why (unless CDN delivery costs are the vast majority of your opex) I don't see why a premium OTT VOD service would use AV1 anytime soon.

I wish we don't have the same problem with VVC.