Alliance for Open Media codecs [Archive] - Page 3

soresu

11th January 2020, 03:51

Xhe-aac didn't steal anything. The biggest video platform YouTube uses opus not he-aac. Second. We no longer live in 56k modem era to care that much about audio compression. 64kbps opus already sounds better than old MP3 128kbps joint-stereo. I really do not care If xhe-aac will achieve the same quality at even lower bitrate (48kbps). The same can be seen with image compression. Ancient jpg is still good enough and file size is not a problem when you have at least 1Mbps connection

Sadly even in developed countries there are plenty of rural areas with terrible data connections using ancient ADSL tech on lines miles from the nearest telephone exchange.

In less developed countries the problem is even worse still, so even a few dozen kilobits still count.

The coming satellite broadband internet solutions will likely diminish the problem somewhat globally, but even then the content providers are still thinking in terms of millions to billions of served video and audio streams/files per day - from which even 64 kbps will accumulate quickly, so they will continue to push the advancement in compression on all fronts too, simply to reduce what they have to pay for serving their content.

soresu

11th January 2020, 05:46

I think xHE-AAC has stolen Opus's thunder, since the licensing and code is free for any AAC licensee. Plus it outperforms Opus some.

Opus is getting on a bit, and represents only an early stab at using ML in audio codecs - I think we might expect the current focus on ML techniques with AV2 and VVC to bear fruit in a new audio codec sooner or later.

The xiph site called "Monty's Demo Pages" has an article about a "Real-Time Wideband Neural Vocoder at 1.6 kb/s Using LPCNet", I think done by JM Valin who also worked on Daala and AV1.

Link here (https://people.xiph.org/~jm/demo/lpcnet_codec/).

Whether this turns into anything concrete is uncertain, but it is certainly interesting.

Atak_Snajpera

11th January 2020, 12:13

In less developed countries the problem is even worse still, so even a few dozen kilobits still count.
Seriously? Do you really think that saved 16kbps will change anything? IT is 2020 . Mobile network 3g is already fast enough for 64kbps audio streaming. Audio streaming is no longer a problem. Video on other hand is a different story...

IgorC

11th January 2020, 20:26

Sadly even in developed countries there are plenty of rural areas with terrible data connections using ancient ADSL tech on lines miles from the nearest telephone exchange.

Nowdays You get at least ~ 1-1.5 Mbit in worst case or you get nothing. And that's with an old ADSL2+. 10% of that bitrate budget will go for audio. That's 128 kbps.

xHE-AAC is very low bitrate format and it doesn't present any advantage at 96 kbps and higher comparing to an old LC-AAC. (go check official MPEG tests).

In less developed countries the problem is even worse still, so even a few dozen kilobits still count.

No.
https://ispspeedindex.netflix.com/country/india/

Somebody saying that xHE-AAC is gaining market fast and letting another audio formats in dust, it isn't just not true. It's a bald-face lie.

Companies don't want to pay for low bitrate xHE-AAC license simply because LC-AAC patents have expired and they don't need to stream 32-48 kbps where xHE-AAC would make sense.

Spotify (web app), Tidal , Apple Music, Netflix, they all don't need to pay anymore for LC-AAC licensing.

xHE-AAC was developed 7 years ago. Since then it has faced stiff competition from Opus and patent expiration of MP3, LC-AAC, Dolby Digital AC3 formats. Today it belongs same place as another failed audio format, MPEG Surround, which hasn't seen any meaningful adoption.

Atak_Snajpera

11th January 2020, 23:04

xhe-aac is just another variant optimized for speech
https://www.youtube.com/watch?v=yArrLvMYng8

benwaggoner

13th January 2020, 21:09

Seriously? Do you really think that saved 16kbps will change anything? IT is 2020 . Mobile network 3g is already fast enough for 64kbps audio streaming. Audio streaming is no longer a problem. Video on other hand is a different story...
There are hundreds of millions of people in developing countries who often connect with 2G. And streaming video is streaming video + audio, so every bit saved from audio means the minimum bitrate for AV is that much lower.

If you're talking rural mobile delivery, saving 16 Kbps from audio really does make a material difference.

This is why lower speed mobile in developing countries might be one of the most viable markets for AV1, since it truly is a lot better than H.264 for very low bitrates. Of course, that is dependent on getting performant SW decoders or HW decoders on low-cost devices. Which often run an ASOP derivative versus actual Google-endorsed Android with all those requirements. If we see low-cost chipsets with HW AV1 become ubiquitous, that would be a big market that has rapid turnover for new models.

benwaggoner

13th January 2020, 21:24

Nowdays You get at least ~ 1-1.5 Mbit in worst case or you get nothing. And that's with an old ADSL2+. 10% of that bitrate budget will go for audio. That's 128 kbps.
For a household, maybe. For those who have that connection. But that gets shared across multiple users, and probably neighbors too.

xHE-AAC is very low bitrate format and it doesn't present any advantage at 96 kbps and higher comparing to an old LC-AAC. (go check official MPEG tests).
"Not better, but lower bitrate" is a pretty big advantage. Plus xHE allows for seamless audio bitrate switching, which wasn't possible between LC/HEv1/HEv2.

https://ispspeedindex.netflix.com/country/india/
Obviously Netflix customers are pre-selected as people who have enough bandwidth to stream Netflix.
The Netflix ISP Speed Index is a measure of prime time Netflix performance on particular ISPs (internet service providers) around the globe, and not a measure of overall performance for other services/data that may travel across the specific ISP network.

Somebody saying that xHE-AAC is gaining market fast and letting another audio formats in dust, it isn't just not true. It's a bald-face lie.
It's getting built into the major OSes and mobile platforms already. There is no extra cost to add it for anyone who is already a Fraunhofer AAC SDK licensee. Whenever someone updates to the recent version, they'd have to comment out xHE in order to not support it. And it's pretty trivial for anyone doing adaptive streaming to offer multiple audio codecs to support backwards compatibility.

Companies don't want to pay for low bitrate xHE-AAC license simply because LC-AAC patents have expired and they don't need to stream 32-48 kbps where xHE-AAC would make sense.

Spotify (web app), Tidal , Apple Music, Netflix, they all don't need to pay anymore for LC-AAC licensing.
Citation that they don't pay for it? There's no royalty for any of that per hour streamed or something like that. The cost of AAC licensing is really immaterial.

xHE-AAC was developed 7 years ago. Since then it has faced stiff competition from Opus and patent expiration of MP3, LC-AAC, Dolby Digital AC3 formats. Today it belongs same place as another failed audio format, MPEG Surround, which hasn't seen any meaningful adoption.
MPEG Surround has been supplanted by MPEG-H, which is the default ATSC 3.0 codec in many markets, including South Korea. It's increasingly built into mass market devices. And Android has had it built in for a while now.

MPEG-H is really an Atmos/AC-4 competitor, though; not for low bitrate stereo. I see it growing a lot in living room devices, less in North America than in Asia.

benwaggoner

13th January 2020, 21:29

xhe-aac is just another variant optimized for speech
https://www.youtube.com/watch?v=yArrLvMYng8
I don't know about "just." It's a codec that supports both speech-focused and general-purpose encoding tools, and can mix and match those as is most appropriate for bitrate and content. It's really the same concept as Opus, with the same strengths.

The big difference is that it fits into the existing audio codec and MPEG ecosystems better. Not that Opus had any fundamental technical reasons why it couldn't, but there just weren't proponents pushing for it the same way and with the same resources.

Web/PC oriented technologies can innovate quickly and powerfully, but it's way harder to migrate from there to consumer electronics and living room than people imagine. Same reason why VP8/9 never had much traction outside of user generated content on the web. Premium content interoperable across all material endpoints requires a huge, huge effort from many, many stakeholders.

IgorC

13th January 2020, 21:35

There are hundreds of millions of people in developing countries who often connect with 2G
Those hunders of millions of people don't use their 2G connection to watch Netflix (to begin with)! In fact most of these people care more about an access to drinking water rather than to high speed internet connection. Netflix isn't priority there.

More advanced codecs like HEVC, VP9, AV1, Opus, xHE-AAC won't bring possibility to use services like Netflix or Spotify on 2G or 3G as such limited speeds and, most importantly, traffic cap make these services hardly affordable for people with low incomes in developing countries.

Also there is no terrific difference bettween speed of developed/developing countries https://ispspeedindex.netflix.com/

It doesn't support your theory of 2G in developing countries. :rolleyes:

Atak_Snajpera

13th January 2020, 21:53

IgorC

13th January 2020, 22:24

@Atak_Snajpera
+1

MPEG Surround has been supplanted by MPEG-H...
How does it change the fact that MPEG Surround hasn't seen meaningful adoption?

MPEG Surround is standard since 2007 as MPEG-H is since 2015.

So a period of supplantation took 8 years (?) Ben, really?

soresu

13th January 2020, 22:48

MPEG-H is really an Atmos/AC-4 competitor, though; not for low bitrate stereo. I see it growing a lot in living room devices, less in North America than in Asia.

You put Atmos and AC-4 in the same place there.

Is AC-4 the coding scheme for all Atmos? Or is that just for web streams using Atmos?

birdie

14th January 2020, 01:04

Is this a topic about AV1? I'm not sure I'm at the right forum.

Perhaps some people want to continue here: https://hydrogenaud.io/index.php?board=54.0 ;-)

skal

14th January 2020, 10:17

There are only two I can think of
[LIST]
despite being technically more advanced you can still lose to a decades old legacy format when your encoder is terrible

Do you have a concrete example? Why is the encoder terrible?

it does not matter that your format is worse than the legacy competition,

Sample?

Seriously the only area where it might be a tiny bit better is for ultra-high compression where it does not start falling apart as badly as jpeg, for any sane (mid ot high) image quality range the vast array of jpeg encoders are doing a significantly better job of retaining detail

Could be it because you're trying to recompress an already jpeg-encoded source? (aka, spurious resonance). This seems like an overly broad statement, otherwise.

skal/

Tadanobu

14th January 2020, 17:21

Those hunders of millions of people don't use their 2G connection to watch Netflix (to begin with)! In fact most of these people care more about an access to drinking water rather than to high speed internet connection.

Exactly! People in those countries do not give a f about some streaming services If you have nothing to eat and drink!
Not to even mention about Electricity...

Guys, I don't mean to be rude but you really sound like people who do not know much about these countries and these people. I live in Madagascar and I don't quite agree with you.

You will find people in very remote places with no water and no electricity but with phones. Not necessarily smartphones, but with an access to 2G/3G/4G. It's widely used to communicate, send money and other stuff. There are small, cheap solar panels to easily charge these phones. Also, a part of the internet is free. Depending on your ISP, you'll have free access to Facebook, Wikipedia and other sites. Most of the time, there are restrictions like no images or no videos. Believe me, there are many many young people who will just buy some credit/data as soon as they have money. They won't buy food or water because these people don't buy food or water. They grow their own food and fetch water at the well or the river. Pocket money is mostly for entertainment so they will buy cigarettes, candies or whatever.

Anyway, back on topic. In the big cities, you have great connections. I'm working 160km South from the capital city and I have 4G+. But as soon as you leave the biggest area, you end up with 2G and sometimes no network at all. And people love streaming here. Well, they have no TV, no newspaper, no nothing. But they have a phone and an access to internet. Of course they want to see pictures and watch videos. Not Netflix of course, but Facebook is absolutely huge, Youtube is not very important here. The real problem here is the cost of the data. It's damn expensive. Browsing text can be fairly inexpensive. Images are quite expensive. Video is really a rich people thing. Personally, I'm not poor but I disable all images when I browse the internet. And I can't afford more than a few minutes of videos per week. Also, keep in mind that people don't care about quality at all. They don't want better quality for same size, they want same quality at lower bitrate, so they can save data and therefore money. So AV1 will be very very useful. Easier to stream in remote areas, less expensive, allowing better quality... Africa, South-East Asia and other areas are big markets that are growing a lot. Hardware is way behind, but apart from that it's all the same (selfie sticks, filters, nomophobia... you name it). It doesn't concern 100% of the population yet, but for the younger generation it's already a wide majority.

benwaggoner

14th January 2020, 22:32

Those hunders of millions of people don't use their 2G connection to watch Netflix (to begin with)! In fact most of these people care more about an access to drinking water rather than to high speed internet connection. Netflix isn't priority there.
There are absolutely lots of people watching premium video over 2G networks. The experience isn't great, but it can be better than not being able to watch anything.

More advanced codecs like HEVC, VP9, AV1, Opus, xHE-AAC won't bring possibility to use services like Netflix or Spotify on 2G or 3G as such limited speeds and, most importantly, traffic cap make these services hardly affordable for people with low incomes in developing countries.
Perhaps not in theory, but it is in practice :sly:! Replacing AAC-LC at 96 Kbps with xHE-AAC at 24 Kbps is a whole extra 64 Kbps to either lower minimum bandwidth requirements or increase video bitrate.

Also there is no terrific difference between speed of developed/developing countries https://ispspeedindex.netflix.com/
Self selected to people using Netflix. Netflix has substantially higher minimum bitrates compared to some other services, particularly those local to lower-bandwidth regions. That said, people in developed countries still ride in subways or are in rural areas, so being able to ramp down to very low bitrates with a "better than nothing" experience on mobile devices is valuable worldwide.

AV1 proponents should hope this is a viable market, because it's probably where AV1 would have the biggest differential advantage over H.264 and a market where rapid turnover and Android-centric mobile markets could result in >50% HW decoder installed base by 2025.

Nintendo Maniac 64

15th January 2020, 03:52

LG announced (http://www.lgnewsroom.com/2020/01/lg-to-unveil-2020-real-8k-tv-lineup-featuring-next-gen-ai-processor-at-ces-2020/) that their new 8K TVs will support AV1.

As far as I know these are the first TVs with AV1 hardware decoding. I wonder if they will also support Opus.

These TVs will feature quite powerful SoCs and Opus is a very low complexity codec, so I see no reason not to support it.

Besides, YouTube started using it years ago along with VP9 and each device which supports YT must support Opus by default.

I think he may have meant ASIC support?

As you say it's low complexity so it wouldn't require an ASIC to run it in a wall powered device like a high end 4K TV, but anything that reduces thermal output is welcome, it's annoying hearing a fan coming from a TV.

I'm a bit late on this, but I was able to confirm from a family friend with an E9 TV that the 2019 LG OLEDs already support VP9+Opus WebM files played from a USB HDD.

And decoding complexity isn't always the reason for lacking format support because I was also able to confirm that, while the 2019 E9 OLED also supports VP8 + vorbis in a WebM as well as VP9 + AAC in an MKV, it does not support VP8 + AAC in an MKV.

Here's the full list of tested formats and combinations that I was able to confirm that worked (all video codecs are 8bit unless otherwise noted):

AVI: Xvid + MP3
AVI: AVC + MP3
MKV: HEVC + AAC
MKV: VP9 + AAC
MP4: AVC + AAC
MP4: Xvid + AAC
MP4: Xvid + MP3
WebM: VP8 + Vorbis
WebM: VP9 + Opus
WebM: VP9 + Vorbis

And the things that didn't work (all video codecs are 8bit unless otherwise noted):

MKV: VP8 + AAC
MKV: AVC 10bit + FLAC
MP4: AV1 (video only)
WebM: AV1 + Opus

Unfortunately I didn't provide a test file that combined AVC 10bit and FLAC with other known-working codecs, like AVC 8bit + FLAC as well as AVC 10bit + AAC, so it's uncertain whether it's the AVC 10bit or the FLAC that the TV is unable to play back (though this logic doesn't apply to the MKV with VP8 + AAC as it's able to support all 3 things in other combinations, just not together).

EDIT: I've since confirmed that FLAC audio is in fact supported (at least up to 192KHz 24bit, same goes for LPCM as 32float LPCM failed to work) and, as expected, it's the 10bit AVC (not a typo) that is completely unsupported on LG's 2019 OLEDs.

...though more surprising to me was that it not only supported multi-audio MKVs/MP4s with an according GUI-based audio track switcher, but even supported freaking SubStation Alpha subtitles in an MKV also with an according GUI-based toggle.

benwaggoner

15th January 2020, 23:52

Unfortunately I didn't provide a test file that combined AVC 10bit and FLAC with other known-working codecs, like AVC 8bit + FLAC as well as AVC 10bit + AAC, so it's uncertain whether it's the AVC 10bit or the FLAC that the TV is unable to play back (though this logic doesn't apply to the MKV with VP8 + AAC as it's able to support all 3 things in other combinations, just not together).
That's the thing about consumer electronics devices. The only way to really know if something works is to actually try it. Something can support all the individual components, but not in particular combinations. Something may work via streaming or an app but not as a file in the native player. Everything might work most of the time except if some esoteric parameter exceeds some internal limit even though it is permitted by the spec.

Something that works on a thing is easy. Something interesting that works on EVERYTHING is a nail-biting adventure.

hajj_3

17th January 2020, 10:12

new rav1e build is out: https://github.com/xiph/rav1e/releases/tag/p20200115

nakTT

22nd January 2020, 18:27

new rav1e build is out: https://github.com/xiph/rav1e/releases/tag/p20200115
Hi, do we have GUI for this encoder? Something like MeGUI or anything? Thank you in advance.

paul97

22nd January 2020, 18:48

https://moisescardona.me/rav1e-gui/
https://ffmpeg.zeranoe.com/builds/

Download rav1e gui.
Download the static ffmpeg with the date. (exe)
Copy the ffmpeg in rav1e gui folder that you extracted (with 7-zip or winrar).
Disable pipes (right at the centre that is a checkbox). If it causes problems.
It still could have different aspect ratio and different framerate not PAL (.vob file) 23.9976
It supports anything with ffmpeg, and ffmpeg converts to yuv. Pipes are to not generate .yuv file.
For a GUI there is also Hybrid GUI (with aomenc - svt appveyor you can download) and Svt GUI, the last by Moises (same developer as rav1e gui).

nakTT

22nd January 2020, 19:22

paul97

22nd January 2020, 19:32

https://www.reddit.com/r/AV1/comments/bnn184/where_find_latest_av1_build/
I asked the question on Reddit some months ago. Here it is.

nakTT

22nd January 2020, 19:38

https://www.reddit.com/r/AV1/comments/bnn184/where_find_latest_av1_build/
I asked the question on Reddit some months ago. Here it is.
Thanks for the reply.

I'm starting the encoding process now.

Thanks again.:thanks:

paul97

22nd January 2020, 21:39

You're welcome.
Rav1e has still 80% 120% 340% difference in quality/bitrate in videos on arewecompressed.yet AWCY. A site that codec developers use to test. SVT is too far from libaom as encoder if you see Mrsmilingwolf's user test on Reddit or on Doom9 like comparable to VP9 a bit not better. I don't know if he tests with anime or like action.

Also FFmpeg has included a build of encoders (Libaom) which you check the readme file in the archive (.zip) or in lower section "Other Downloads" by clicking Readme to see which version it is. Handbrake GUI doesn't support the encoding because it's too slow and AV1 support it's only in beta.
But it supports dav1d (Videolan) decoding, only 8bit is completed on general SIMD, 10 bit lacks support, so it runs without SIMD instructions.
If you use a GUI like Hybrid other than ffmpeg, to encode with libaom you will need aomenc.exe.
Artificial noise isn't possible with a GUI, you need ffmpeg and use libaom.

benwaggoner

23rd January 2020, 00:47

You're welcome.
Rav1e has still 80% 120% 340% difference in quality/bitrate in videos on arewecompressed.yet AWCY. A site that codec developers use to test.
What do those percentages mean specifically?

SVT is too far from libaom as encoder if you see Mrsmilingwolf's user test on Reddit or on Doom9 like comparable to VP9 a bit not better. I don't know if he tests with anime or like action.
Given the configurability of SVT-AV1 in terms of quality/perf and tuning, it's hard to know what to make of encoder versus encoder comparisons. There are literally dozens of values that could impact quality. It would be more useful to compare quality at known best parameters, or quality at same bitrate and encoding time on a given system config.

It seems that there should be scenarios and highly multicore systems where SVT-AV1 would beat libaom in quality @ bitrate @ perf, just because it would have so many more MIPS/pixel available.

user1085

31st January 2020, 04:15

Thank you so much for the reply.

How do I check that I get the latest AV1 encoder?

Thank you in advance.https://www.singhkays.com/blog/docker-image-av1-ffmpeg-libaom/

I compile a docker image with the latest libaom source + ffmpeg every weekend

soresu

5th February 2020, 21:10

Optimisation for dav1d happening for 16 bpc on ARM64 apparently - whether that means everything between 16 and 8 I don't know.

Apparently Netflix are pushing out AV1 now too (possibly even sponsoring the new optimisation efforts?).

Are we finally at the point where AV1 deserves its own sub forum?

hajj_3

6th February 2020, 00:07

https://netflixtechblog.com/netflix-now-streaming-av1-on-android-d5264a515202

dapperdan

6th February 2020, 01:08

Optimisation for dav1d happening for 16 bpc on ARM64 apparently - whether that means everything between 16 and 8 I don't know.

Apparently it means code written for both 10 and 12 bit at the same time, but since they don't fit into 8 bit, they jump to 16.

Nintendo Maniac 64

6th February 2020, 05:02

Is YouTube starting to roll out AV1 for less popular videos and/or YouTubers?

I noticed AV1 encodes on the following video with less than 100k views that's only 5 days old: https://www.youtube.com/watch?v=g6NvMpzRoyU

Also I always found it a bit odd that YouTube used MP4 rather than WebM for AV1. I realize MKV and therefore WebM support was not available when YouTube started introducing AV1, but considering they themselves created WebM (albeit not from scratch as it's a derivative of MKV), and they previously chose to use WebM rather than MP4 for VP9 tells me that they would prefer WebM when given the choice...

(personally I greatly prefer the WebM and by extension MKV container vs MP4 when it comes to streaming assuming the codec used is the same, but I realize that for 99.9999% of people WebM/MKV vs MP4 container would make absolutely no impact on how they consume video)

Blue_MiSfit

6th February 2020, 06:38

Probably wider support for fMP4 on various platforms. What benefits does WebM offer over fMP4 for ABR streaming via DASH?

Nintendo Maniac 64

6th February 2020, 10:06

What benefits does WebM offer over fMP4 for ABR streaming via DASH?

So the following is a super niche use-case... (this is even why I specifically said "99.9999%" to 4 decimal places rather than the more typical "99.9%" or "99.99%", because I'm fully aware just how super niche this use-case is).

I notice that opening an incomplete DASH MP4 stream in MPC-HC or mpv that is downloading via youtube-dl will have the video stream eventually stop at whatever point the video had downloaded when you launched the file even if the download is finished (thereby requiring you to relaunch the video).

With YouTube's DASH WebM encodes though, if you open an incomplete but still downloading DASH WebM video in MPC-HC or mpv, it's able to completely play through the video without issue as long as it's downloading quicker than you're viewing it.

It is worth noting however that sometimes I notice that a rare DASH WebM video will instead be downloaded into individual chunks via youtube-dl which are then reassembled into a single file as it downloads. These are notable in that trying to watch the reassembled albeit still downloading video gives you the exact same behavior as the DASH MP4 videos.

birdie

6th February 2020, 10:06

Is YouTube starting to roll out AV1 for less popular videos and/or YouTubers?

I noticed AV1 encodes on the following video with less than 100k views that's only 5 days old: https://www.youtube.com/watch?v=g6NvMpzRoyU

720p only. 1080p is still distributed using VP9.

https://netflixtechblog.com/netflix-now-streaming-av1-on-android-d5264a515202

This announcement makes no sense: I don't know a single mobile SoC which supports AV1 HW decoding acceleration right now which means the poor users who will watch AV1 content will decimate their battery life.

Nintendo Maniac 64

6th February 2020, 10:09

720p only. 1080p is still distributed using VP9.

1080p AV01 (fmt 399) is listed in youtube-dl though and does indeed successfully download.

I don't know a single mobile SoC which supports AV1 HW decoding acceleration right now which means the poor users who will watch AV1 content will decimate their battery life.

I would imagine they're probably only using it for SD, likely with a focus on markets where bandwidth speed and the like is quite low (think maybe less than 1mbps?)

birdie

6th February 2020, 10:12

1080p AV01 (fmt 399) is listed in youtube-dl though and does indeed successfully download.

Yet both Google Chrome and Mozilla Firefox defaulted to VP9 when I switched to 1080p.

Nintendo Maniac 64

6th February 2020, 10:15

Yet both Google Chrome and Mozilla Firefox defaulted to VP9 when I switched to 1080p.

Perhaps YouTube is "holding back" on playing more than 720p AV1 in browsers because they know that no hardware decode support is available on PCs?

They did something similar back when they were rolling out VP9 whereby it would fallback to AVC if your user agent listed Windows XP (one of the few cases of user agent sniffing that I feel is not actually terrible)

Also here's a youtube-dl screenshot for reference showing the 1080p AV1:

https://archive.is/E7aDh/da109c997e6ecad3a0d2914d7c566f8272c8577f.png

Funky080900

6th February 2020, 10:44

Yet both Google Chrome and Mozilla Firefox defaulted to VP9 when I switched to 1080p.

I get 1080p AV1 in Firefox on Windows

birdie

6th February 2020, 11:17

I get 1080p AV1 in Firefox on Windows

Are you sure about that?

Firefox 72, UA: Windows 10 64: https://i.imgur.com/nkZRiUZ.png

Are_

6th February 2020, 11:42

Am I sure?
https://imgur.com/WG8icgu

Jokes aside that's probably a setting somewhere on the YouTube account, I kind of remember something like that.

birdie

6th February 2020, 11:52

Am I sure?
https://imgur.com/WG8icgu

Jokes aside that's probably a setting somewhere on the YouTube account, I kind of remember something like that.

Yeah, and I didn't touch it (https://www.youtube.com/account_playback), so in terms of defaults YouTube does not yet offer AV1 for 1080p videos.

benwaggoner

7th February 2020, 19:20

Probably wider support for fMP4 on various platforms. What benefits does WebM offer over fMP4 for ABR streaming via DASH?
Exactly. There's SO much stuff for MP4 as a container format, and such a huge infrastructure around it. WebM just doesn't have the same ecosystem or any particular standout features.

benwaggoner

7th February 2020, 19:25

This announcement makes no sense: I don't know a single mobile SoC which supports AV1 HW decoding acceleration right now which means the poor users who will watch AV1 content will decimate their battery life.
Has anyone looked at what the power draw of AV1 decode looks like on different devices/platforms. Like using a Kill-a-watt on a charged laptop or a desktop and comparing AV1 playback versus a HW decoded bitstream?

Obviously there is a lot of other power draw happening for the screen, UX, system. But getting a delta would be helpful.

Back in the day with Silverlight, I remember finding the HW decoder could save 20 watts over the SW decoder on a laptop of the era. Obviously with much less powerful CPUs than we have now, but also with a much less complex decoder (H.264 in this case).

"How many hours of playback" is an important metric for premium video content players.

Nintendo Maniac 64

7th February 2020, 21:55

Exactly. There's SO much stuff for MP4 as a container format, and such a huge infrastructure around it. WebM just doesn't have the same ecosystem or any particular standout features.

Opus does not use the MP4 container on YouTube though and does in fact use WebM.

Nevertheless, follow-up question.

As someone that has no concept of what goes into the software back-end required for delivering video, does it in fact still improve the ease of implementation to use a container that is already widely used if it's a completely new codec anyway?

Blue_MiSfit

7th February 2020, 23:20

Yes, it does, because you still have to package it (and encrypt it, often). There's often an established ecosystem to do this in a way that meets business requirements. Sometimes it's even done dynamically. Adding support for a new codec in that tooling is likely easier than having to implement support for a whole new container format as well.

Same thing on the clients, honestly. I don't see anything about WebM that adds value to the adaptive streaming use case, but I may be missing something.

benwaggoner

8th February 2020, 02:19

Same thing on the clients, honestly. I don't see anything about WebM that adds value to the adaptive streaming use case, but I may be missing something.
And media format code is pretty low level, so needs to get lots of fuzz testing and security checks. People remember how often big security bugs (Stagefright for example) come from media playback stacks.

So there's little desire to take on new code for such mission critical task.

Nintendo Maniac 64

8th February 2020, 09:35

foxyshadis

8th February 2020, 11:01

So yeah uh...then why the heck are they using WebM for Opus? I mean, isn't splitting the video and audio between separate MP4 and WebM containers even worse than just having both in a WebM container let alone both in an MP4 container?

The whole point of DASH is that you can cherrypick your favorite video and audio, and swap in alternates at any time depending on bandwidth. You can swap languages without having to download all languages. The container they're delivered in doesn't matter, but they still need something. That necessitates that every stream is packaged separately, but fortunately, WebM/MKV and MP4 are very low-overhead containers. The penalty is well under 1% for most videos.

I think there's a combination of institutional inertia in keeping Opus on WebM instead of tearing down the whole stack, and that no one wants to be the guy who accidentally broke YouTube while changing it over.

MoSal

8th February 2020, 13:47

It is worth noting however that sometimes I notice that a rare DASH WebM video will instead be downloaded into individual chunks via youtube-dl which are then reassembled into a single file as it downloads. These are notable in that trying to watch the reassembled albeit still downloading video gives you the exact same behavior as the DASH MP4 videos.

Try passing --youtube-skip-dash-manifest to youtube-dl.

MoSal

8th February 2020, 13:54

I think Instagram were already shipping a VP9 software decoder on Android I don't think they were even using the fast ffmpeg decoder, just libaom.

Ouch, that's just being bloody minded to user battery life that is.

Not really. libvpx (not libaom) has good NEON optimizations and performs much better than ffvp9 on ARM.

hajj_3

8th February 2020, 17:58

rav1e 0.3.0 has been released: https://github.com/xiph/rav1e/releases/tag/v0.3.0

soresu

8th February 2020, 20:33

Not really. libvpx (not libaom) has good NEON optimizations and performs much better than ffvp9 on ARM.

Ah my mistake, I took it as a given the ff**** decoders were usually better optimised.

Also didn't realise that libvpx had another incremental version in december - v1.8.2 "Pekin Duck".

Does libaom have official version names/numbers yet?

utack

9th February 2020, 19:23

Does anyone know why libaom and vmaf are not compatible on an arch linux system?

cmake ../aom -DCONFIG_TUNE_VMAF=1

make
home/jakob/Downloads/aom/aom_dsp/vmaf.c:13:10: fatal error: libvmaf/libvmaf.h: No such file or directory
13 | #include <libvmaf/libvmaf.h>

pacman -Ql vmaf | grep libvmaf
vmaf /usr/include/libvmaf.h

so if I edit it to #include <libvmaf.h> it builds, but why is the path different than what libaom asks for?

SmilingWolf

10th February 2020, 17:42

Does anyone know why libaom and vmaf are not compatible on an arch linux system?

Packaging differences. Compiling from sources and using "ninja -vC release install" puts the header(s) under <somewhere>/include/libvmaf/<headers>.h
Arch's package maintainer probably follows in the footsteps of the Debian package (https://debian.pkgs.org/10/multimedia-main-amd64/libvmaf-dev_1.3.14-dmo3_amd64.deb.html), that leaves the header under /usr/include/libvmaf.h

SmilingWolf

11th February 2020, 18:30

Anyway, the last time (~18 months ago) I tried linking libvmaf to ffmpeg, I got runtime crashes after I managed to find a version that compiles. So I figured the library is not really reliable API/ABI wise for external linkage use-cases. So I opted to just script around the provided executable vmafossexec.

The timeframe look just about right to be about https://github.com/Netflix/vmaf/issues/177, which has since been fixed by http://ffmpeg.org/pipermail/ffmpeg-devel/2018-August/233012.html

hajj_3

12th February 2020, 00:43

Samsung galaxy s20 has been announced, no mention of AV1 support which i'm a little surprised at.

nevcairiel

12th February 2020, 00:48

Samsung galaxy s20 has been announced, no mention of AV1 support which i'm a little surprised at.

Its Android 10, at the very least it has a built-in software decoder.

Otherwise, its just Snapdragon 865, we already knew its media support - which does not include AV1. It won't be in the mainstream until the end of the year, if not 2021.

Blue_MiSfit

12th February 2020, 01:44

Yeah, ooof. At least yet another cycle in front of us before we see a premium mobile phone with hardware AV1 decoding.

Blue_MiSfit

13th February 2020, 06:04

Surely streaming only low bitrate SD, with just acceptable quality (since it's a low bandwidth opt-in feature).

Still, a great fit for davi1d!

sneaker_ger

13th February 2020, 13:09

Cool that they seem to go 10 bit even for mobile. It's time companies start to see 10 bit as a coding tool increasing compression instead of using it for HDR only. I would hope they start using AV1 10 bit for desktop, too. I'm temporarily on a slow (5~6 Mbps) connection and there can be horrible banding (among other artifacts) when viewing via Chrome (I assume H.264 8 bit).

utack

13th February 2020, 20:59

I have finished three encodes matching up "vmaf_without_preprocessing" against x265 placebo, and I am completely stunned.
The new vmaf tuning has definitely put libaom in first place not only in metrics but clearly in visual quality!
I hope they will manage to speed it up in the future

benwaggoner

13th February 2020, 21:43

Surely streaming only low bitrate SD, with just acceptable quality (since it's a low bandwidth opt-in feature).

Still, a great fit for davi1d!
There's no HW DRM for AV1 on any mobile device yet, so premium content above SD would presumably not be allowed in any case.

Blue_MiSfit

14th February 2020, 03:45

Mr_Khyron

14th February 2020, 13:07

AVIF for Next-Generation Image Coding
https://netflixtechblog.com/avif-for-next-generation-image-coding-b1d75675fe4
TL; DR
We need an alternative to JPEG that
a) is widely supported
b) has better compression efficiency and
c) has a wider feature set. We believe AV1 Image File Format (AVIF) has the potential.
Using the framework we have open sourced, AVIF compression efficiency can be seen at work and compared against a whole range of image codecs that came before it.

Blue_MiSfit

14th February 2020, 18:46

That was a great posting, tbh. AVIF shows serious advantages over WebP which I think is the only JPEG alternative format that's gotten any traction on the web from what I can tell.

dapperdan

16th February 2020, 00:31

That was a great posting, tbh. AVIF shows serious advantages over WebP which I think is the only JPEG alternative format that's gotten any traction on the web from what I can tell.

JPEG XL is a strong contender. It seems to have buy in from a similarly diverse set of implementors as AV1, but one key advantage is that it can seamlessly and losslessly upgrade existing JPEG content, which would probably make it attractive to web deployment even if it didn't offer anything else. If it's well integrated with HTTP2 and browsers then progressive loading is a second "killer app" it provides and again that alone could probably justify its rollout as the subjective improvement in partial loading display would be dramatic even if the objective improvements were equal or even negative.

benwaggoner

16th February 2020, 19:09

Interesting, correct me if I'm wrong but it's not really a matter of DRM "supporting AV1" as much as it is AV1 having a defined mapping into fMP4 with common encryption (CENC), right? Once that's all set then any DRM that supports CENC would work, be it software Widevine L3 or hardware Widevine L1 or PlayReady SL3000 etc?

Is that mapping still really not done for AV1??
The mapping is done. But it is really challenging to robustly secure a software-only decoder. It can be done in Trust Zone, but not all devices allow full CPU use for that. And there is still more risk SW being hacked; so much fuzz testing from malformed bitstreams is required, and DRM robustness competes with decode for compute optimization.

Major studios generally require HW DRM integrated with HW decoders for premium HD content. And lots of platforms straight up doing allow their SW codecs to use the HW DRM features. For example, iOS has HEVC software decoders for all device supported by the iOS version that introduced HEVC playback. But FairPlay DRM straight up won't work on the device without the HW decoder.

benwaggoner

16th February 2020, 20:00

JPEG XL is a strong contender. It seems to have buy in from a similarly diverse set of implementors as AV1, but one key advantage is that it can seamlessly and losslessly upgrade existing JPEG content, which would probably make it attractive to web deployment even if it didn't offer anything else. If it's well integrated with HTTP2 and browsers then progressive loading is a second "killer app" it provides and again that alone could probably justify its rollout as the subjective improvement in partial loading display would be dramatic even if the objective improvements were equal or even negative.
HEIF is also a good contender here, and is very well supported in the Apple ecosystem at least. Mostly as HEVC frames. That's the default way to shoot pictures on iPhones now.

But HEVC and patents. AV1 is a strong still image codec, and the patent exposure elminating all the interframe stuff is even smaller. Screen coding tools. And SW decode is a lot more feasible for just images, and DRM is rarely a requirement for them too.

Broad AVIF support in browsers seems like something that could happen quite quickly, and be of use with much less infrastructure than video. A PhotoShop export component and integration into ImageMagick and we'd be ready to go.

Blue_MiSfit

16th February 2020, 21:40

Broad AVIF support in browsers seems like something that could happen quite quickly, and be of use with much less infrastructure than video. A PhotoShop export component and integration into ImageMagick and we'd be ready to go.

Seems like a great fit, agreed. Dynamic server-side versioning of images with tools like ImageMagick is a common thing, so this would indeed be an easy win.

Major studios generally require HW DRM integrated with HW decoders for premium HD content

Yep! I work for one of them ;)

FairPlay DRM straight up won't work on the device without the HW decoder

I actually didn't realize this, but it totally makes sense.

marcomsousa

20th February 2020, 17:14

rav1e 0.3.1 released

25-40% faster speed levels 2 to 5
This is accomplished by disabling costly coding tools
**Fine directional prediction
**Intra block transform splitting in inter frames
Encoding quality is slightly inferior (1-2%), but more in line with the target speed levels

https://github.com/xiph/rav1e/releases

Nintendo Maniac 64

23rd February 2020, 09:53

Unfortunately I didn't provide a test file that combined AVC 10bit and FLAC with other known-working codecs, like AVC 8bit + FLAC as well as AVC 10bit + AAC, so it's uncertain whether it's the AVC 10bit or the FLAC that the TV is unable to play back.

That's the thing about consumer electronics devices. The only way to really know if something works is to actually try it. Something can support all the individual components, but not in particular combinations. Something may work via streaming or an app but not as a file in the native player. Everything might work most of the time except if some esoteric parameter exceeds some internal limit even though it is permitted by the spec.

Something that works on a thing is easy. Something interesting that works on EVERYTHING is a nail-biting adventure.

Apologies for the off-topic post, but I just wanted to give an update on the final conclusion - I just confirmed today that FLAC audio is in fact supported (at least up to 192KHz 24bit, same goes for LPCM as 32float LPCM failed to work) and, as expected, it's the 10bit AVC (not a typo) that is completely unsupported on LG's 2019 OLEDs.

...though more surprising to me was that it not only supported multi-audio MKVs/MP4s with an according GUI-based audio track switcher, but even supported freaking SubStation Alpha subtitles in an MKV also with an according GUI-based toggle.

That is all, and I will refrain from going on about this subject farther.

BTW SmilingWolf, if you're reading this, I got to watch our waifu2x-upscaled UBW Vita OP the LG E9 OLED TV (65" model).

10/10 would recommend.

sneaker_ger

24th February 2020, 00:17

No AV1 with Tiger Lake? I get that right?

foxyshadis

24th February 2020, 07:25

No AV1 with Tiger Lake? I get that right?

Big delays might open an opportunity to add a decoder, but otherwise, it's going to be implemented in gpu, not fixed-function. It'll look the same to software, it just won't perform the same.

Nintendo Maniac 64

24th February 2020, 09:31

nevcairiel

24th February 2020, 12:22

It'll look the same to software, it just won't perform the same.

Historically, those have been entirely unusable, especially from Intel. So I hope they won't waste their time on it.

MoSal

24th February 2020, 19:33

Apologies for the delayed response and for another somewhat off-topic post, but it was only just now that I came across a video with the according WebM-in-chunks formatting that I previously mentioned in this thread and I didn't think it'd be wise to make a whole new thread for a discussion that will probably last all of like two posts.

This does not seem to work on the following video's 1080p VP9 encode:

https://www.youtube.com/watch?v=K60qpDSSnJU

(assuming that I'm not doing something wrong of course, which is always a possibility)

Yep. You get a URL that upon request returns a 404 error. Maybe that's intentional. Maybe not. We would know for sure if their backend stops spitting such URLs.

Or it could be some boring reason, like the video server requiring certain headers, or the server is, for some reason, tied to a specific old quic/http3 draft. Who knows.

Well, at least audio/Opus unfragmented streams still work.

hajj_3

26th February 2020, 12:19

AOM newsletter: https://aomedia.org/wp-content/uploads/2020/02/AOMedia-Non-Member-Newsletter-February-2020-upadated.pdf

mzso

27th February 2020, 11:56

Yes.

Could you elaborate on what sort of system (CPU chipset etc.), and where you got the content from? In particular, it'd be interesting to know the respective bitrates for the AV1 & VP9 files/streams, but knowing the encoder settings might also be somewhat useful.

Playback speed correlates a lot with bitrate. The 30% numbers that we've shown at conferences and in blogs are for same-quality encodes, where VP9 has a higher bitrate than AV1. If the files are same-bitrate, the performance difference goes up. On easy content, the postfilters also require a higher % of runtime (compared to e.g. inverse transform or predictors), and since AV1 has more postfilters, that means the difference will grow on low-complexity content, and will be smaller on high-complexity content. The 30% was also without film grain (since we assume the GPU will do that for free), but there is currently no browser that does that correctly yet.

(I have a Ryzen 5 1600, with a B350 board)

I just played youtube videos, with AV1 enabled and disabled, nothing scientific.
But roughly that's what I experienced in cpu usage use.

Beelzebubu

27th February 2020, 14:34

(I have a Ryzen 5 1600, with a B350 board)

What browser/version, and on what platform/OS?

I just played youtube videos, with AV1 enabled and disabled, nothing scientific.
But roughly that's what I experienced in cpu usage use.

I think Youtube is known to do significantly higher bitrates for AV1 than for VP9, so that could be part of why...

benwaggoner

2nd March 2020, 01:49

I think Youtube is known to do significantly higher bitrates for AV1 than for VP9, so that could be part of why...
Really? Do you have any documentation?

This would be odd since a key point of AV1 is to be able to use lower bitrates than VP9. And as a performance-heavy SW decoder, lower bitrates help performance as well.

Toggleton

2nd March 2020, 11:31

Really? Do you have any documentation?

This would be odd since a key point of AV1 is to be able to use lower bitrates than VP9. And as a performance-heavy SW decoder, lower bitrates help performance as well.

https://www.reddit.com/r/AV1/comments/dxqr8k/answer_to_why_av1_videos_on_youtube_use_higher/

But i think that is not true anymore. Have seen more mixed results and av1 was most of the time smaller.
Will look, if we can collect data about it once new AV1 encoded videos are available(no new AV1 encoded video since 2020-02-23 in the "Popular Right Now" playlist)

Tracker how many AV1 encoded videos are in the "Popular Right Now" playlist per day
https://htmlpreview.github.io/?https://github.com/thulle/yt-av1/blob/master/yt-av1.html

utack

2nd March 2020, 21:11

marcomsousa

2nd March 2020, 23:51

AOMedia Member Spotlight with Netflix’s Manager, Android Player Infrastructure, Jeff Watts (http://aomedia.org/aomedia-member-spotlight-with-netflixs-manager-android-player-infrastructure-jeff-watts/)I am most excited to see AV1 appear in the mobile chipsets. With hardware support, we can start pushing our AV1 support into higher resolutions. Because we have an AV1 pipeline ready, we are in a good position to help evaluate this hardware as it becomes available. I look forward to sharing our learnings with the first AV1 hardware when it comes out.

Marco Sousa

benwaggoner

3rd March 2020, 00:48

https://www.reddit.com/r/AV1/comments/dxqr8k/answer_to_why_av1_videos_on_youtube_use_higher/

But i think that is not true anymore. Have seen more mixed results and av1 was most of the time smaller.
Will look, if we can collect data about it once new AV1 encoded videos are available(no new AV1 encoded video since 2020-02-23 in the "Popular Right Now" playlist)

Tracker how many AV1 encoded videos are in the "Popular Right Now" playlist per day
https://htmlpreview.github.io/?https://github.com/thulle/yt-av1/blob/master/yt-av1.html
I can see that making sense. Given how YouTube distributes encoding, it would be hard to run AV1 at higher quality/efficiency levels with libaom. So at the same MIPS/pixel, they may have needed to use a higher bitrate than with vp9 to deliver the higher quality they wanted to with AV1. Which makes sense as their goal was to push AV1, not to use it to deliver lower bitrate or higher quality content overall (then they would have just raised vp9 bitrates).

As we're getting faster and better encoding, I would expect the AV1 bitrates to drop while maintaining quality.

Blue_MiSfit

6th March 2020, 02:02

Excellent! Good to see more comprehensive 10+ bit optimization being done. This is mandatory for HDR :)

benwaggoner

10th March 2020, 22:45

Excellent! Good to see more comprehensive 10+ bit optimization being done. This is mandatory for HDR :)
Yeah, fast ARM 10-bit will make HDR feasible on 2020 mobile devices. For user generated content at least; premium studio content will still require HW DRM.

It's be nice to have some benchmarks with details beyond "Up to 2.5x faster" - is that only in some edge cases, or is ~2x speedup a practical expectation?

nevcairiel

10th March 2020, 23:21

The optimizations covered quite a lot of very commonly used functions (MC, Loopfilter, CDEF), so I would expect quite decent improvements for the majority of clips. I believe a proper announcement with example benchmarks is still being worked on.

NikosD

11th March 2020, 17:27

It also brings new AVX-512, AVX2 and SSSE3 optimizations and improves the existing optimizations on all platforms.Insignificant gains for 8 bit video according to Phoronix for modern CPU architectures.
Probably that's why they didn't announce performance differences from previous versions as they always do.
But huge gains for 10 bit video, as they actually begin optimizations for this colour depth for the first time, starting with this version.

motbob

14th March 2020, 00:32

I discovered a quirk of aom that might be of interest to some people.

Sometimes keyframes in aom look really bad even in constant quantizer mode and a cq level of 20. Examples: https://slow.pics/c/GaddIUgb

I believe this happens when the encoder looks ahead and sees that the keyframe (or parts of the keyframe) is pretty useless because not a lot depends on it.

You can fix these low quality keyframes, if you want, with --enable-keyframe-filtering=0. Obviously, this will use more bitrate.

IgorC

14th March 2020, 17:59

Netflix - SVT-AV1: an open-source AV1 encoder and decoder (https://netflixtechblog.com/svt-av1-an-open-source-av1-encoder-and-decoder-ad295d9b5ca2)

hajj_3

16th March 2020, 22:19

AMD's new 7nm zen2 based ryzen 4000 'renoir' laptop chips were announced today, they don't support AV1 :(

image: https://images.anandtech.com/doci/15624/2%20AMD%20Ryzen%20Mobile%20Tech%20Day_General%20Session_Architecture%20Deep%20Dive-page-009.jpg

marcomsousa

16th March 2020, 22:53

Zen2 based...
Also AMD is always slow on HW codec, or instructions.

Is much more important on the next mobile SoC.

Marco Sousa

hajj_3

17th March 2020, 00:01

Zen2 based...
Marco Sousa

Zen 2 based doesn't require them to use any specific video decode block. They can release zen 2 chips with a newer video decode block that can decode av1.

soresu

17th March 2020, 05:07

Zen 2 based doesn't require them to use any specific video decode block. They can release zen 2 chips with a newer video decode block that can decode av1.

Unlikely, the 'Renoir' 4000 series APU with Zen2 cores is likely to be the last major design with Zen2, with following low cost and embedded designs likely to be derivative.

It seems likely that the Zen3 based Cezanne APU (like 5000 series) will have AV1 decoding blocks, perhaps maybe the new discrete GPU's expected later this year too.

nevcairiel

17th March 2020, 09:30

Media features are typically part of the GPU, not the CPU, as such Zen2 or Zen3 wouldn't make the key difference, but the Vega graphics on them would - which isn't even RDNA yet, so its rather old.

NikosD

17th March 2020, 12:31

Renoir SoC has a special version of Vega at 7nm that has borrowed multimedia engine from Navi aka RDNA.

We have to actually run DXVAChecker to see real features and decoding speed.

marcomsousa

17th March 2020, 18:39

OnePlus 8 Lite will support AV1 HW decode.

The normal or the PRO version doesn't because Qualcomm do not support it.

https://uploads.tapatalk-cdn.com/20200317/336a0c4c2f62f9be392066cf5b90aa1b.jpg

Marco Sousa

utack

18th March 2020, 10:51

What is Qualcomms deal at this point?
Are they silently preparing another Patent Pool for AV1 like Sisvel, or are they just lazy and indecisive

hajj_3

18th March 2020, 18:31

new macbook air has been released, it uses a 10th gen intel processor, no info about AV1 decoding or not: https://www.apple.com/uk/macbook-air/specs/

birdie

19th March 2020, 08:43

new macbook air has been released, it uses a 10th gen intel processor, no info about AV1 decoding or not: https://www.apple.com/uk/macbook-air/specs/

10th gen Intel CPUs don't support HW accelerated anything in regard to AV1.

benwaggoner

19th March 2020, 18:28

What is Qualcomms deal at this point?
Are they silently preparing another Patent Pool for AV1 like Sisvel, or are they just lazy and indecisive
AV1 decode takes a lot of transistors, which are expensive. Are consumers willing to pay an extra $5-10 for a phone with AV1?

AV1 really didn't get anywhere near the kind of tweaking and tuning needed to make for efficient HW and SoC decoders like the MPEG codecs have. I'd expect AV2 to be a lot better in this regard. But VVC will provide better compression efficiency than AV1, with less of an incremental cost increase than AV1. Even if VVC costs $1 a unit in codec licensing, it likely would still be cheaper to a SoC vendor than AV1.

Plus Qualcomm spent all those resources on VP8/9 to never see it being used meaningfully outside of YouTube, and not providing any customer benefit beyond what H.264 already delivered.

soresu

19th March 2020, 19:55

AV1 really didn't get anywhere near the kind of tweaking and tuning needed to make for efficient HW and SoC decoders like the MPEG codecs have. I'd expect AV2 to be a lot better in this regard. But VVC will provide better compression efficiency than AV1, with less of an incremental cost increase than AV1. Even if VVC costs $1 a unit in codec licensing, it likely would still be cheaper to a SoC vendor than AV1.

Eh? Wasn't AMD and nVidia involved in AV1 development + several mobile SoC developers?

From that alone it would seem AV1 had more input from actual hardware vendors vs a theoretical hardware/transistor cost in MPEG development schemes as I've never heard of hardware vendors being involved previously.

Of course time itself was a significant constraint on AV1 development.

nevcairiel

19th March 2020, 23:11

Honestly noone really expected wide-spread hardware deployment before middle/end of this year. That one SoC already has it and another doesn't seems perfectly normal to me. Adoption takes time, SoC development cycles take years. Something that is available today would've planned to include AV1 over a year ago.

utack

20th March 2020, 09:04

AV1 really didn't get anywhere near the kind of tweaking and tuning needed to make for efficient HW and SoC decoders like the MPEG codecs have.

People were also ranting that VP9 is even worse for hardware implementation
Lo and behold, Youtube started using it and every cheap chinese SOC managed to implement it

Blue_MiSfit

21st March 2020, 09:36

Still very much hoping for hardware decode.

This definitely can't be seen as anything other than a major blow towards AV1 adoption. If the latest Qualcomm SoC doesn't support it, why should anyone else care? :|

Maybe next gen? But I mean.. The bitstream spec has been out for years. I know there was an eratta that kind of reset the clock not that long ago but.... yikes.

If I was all-in on AV1 I'd be very nervous right about now. HEVC is delivering great results today, and LC-EVC and VVC both look quite promising in the near future, and hardware support is completely guaranteed for VVC.

huhn

21st March 2020, 14:00

just wait for nvidia this year.

and microsoft has to do there part too.

it took 19 month to get VP9 hardware decoding on maxwell the decoder was just not accessible just to show how this worked and there was no word about it too the card where just able to do that from one driver to another and the windows update 19 month after it release date...

BTW that 3 years after VP9 was released.

i don't see a reason to get nervous.
in the end it doesn't matter if youtube and/or what ever are forcing this type of content the hardware decoder will follow.

Yups

22nd March 2020, 13:01

Intels upcoming Xe architecture presumably supports 12 Bit AV1 according to a new leak: https://videocardz.com/newz/exclusive-intel-rocket-lake-s-features-pci-express-4-0-xe-graphics

https://abload.de/img/intel-rocket-lake-s-vy5ktm.jpg

RKl-S will use the smaller GT1 from Intels Gen12LP.

marcomsousa

22nd March 2020, 17:52

AV1 Encoding Now Available with AWS Elemental MediaConvert

https://aws.amazon.com/about-aws/whats-new/2020/03/av1-encoding-now-available-with-aws-elemental-mediaconvert/?nc1=h_ls

Pricing https://aws.amazon.com/mediaconvert/pricing/

Marco Sousa

Blue_MiSfit

22nd March 2020, 22:04

Now THAT is some good news (Intel). Even if it's decode only.

marcomsousa

25th March 2020, 20:06

AOMedia Member Spotlight with Twitch’s(Amazon) Principal Research Engineer, Video, Yueshi Shen

http://aomedia.org/aomedia-member-spotlight-with-twitchs-principal-research-engineer-video-yueshi-shen/

Marco Sousa

benwaggoner

30th March 2020, 06:43

Tadanobu

4th April 2020, 06:02

@benwaggoner I can't help you with compiling but in case it may be useful here are the Windows builds most of us are using over at AV1 Discord : https://jeremylee.sh/bin.html

benwaggoner

4th April 2020, 21:56

Awesome, thank you both!

hajj_3

10th April 2020, 02:23

Is this an extra download or does Win10 comes with this AV1 extension decoder ?

If it is an extra download, any url ?

https://www.microsoft.com/en-us/p/av1-video-extension-beta/9mvzqvxjbq9v?activetab=pivot:overviewtab

littleD

12th April 2020, 07:35

i have actualized recently (not remember a day) av1 extension from store and decoding is stilll slow.

soresu

12th April 2020, 23:52

i have actualized recently (not remember a day) av1 extension from store and decoding is stilll slow.

SIMD optimisations for 10+ bpc content on x86 are still completely missing, you might get better performance on a recent W10 on ARM laptop due to the NEON optimisations for ARM64 added more recently.

With 8 bpc content though both the ARM64 and x86 platforms are mostly done now for SIMD optimisation (excepting AVX512), I would not expect any dramatic speedups for that now without adding more cores.

benwaggoner

13th April 2020, 23:46

With 8 bpc content though both the ARM64 and x86 platforms are mostly done now for SIMD optimisation (excepting AVX512), I would not expect any dramatic speedups for that now without adding more cores.
I'd be surprised to see material perf improvements by adding AVX512, at least on current gen CPUs, due to aggressive thermal throttling.

This will hopefully change over time, just like we saw AVX2 become much more useful in the second major generation of implementations.

VincAlastor

15th April 2020, 08:22

Beelzebubu

15th April 2020, 16:04

Unfortunately you still can't search/skip the svt-av1 stream quickly if you use the default value --irefresh-type 1 (CRA; Open GOP).

Since there is no hint if it is a svt-av1 encoder or dav1d decoder problem, I tested the latest version.

Does anyone have a hint?

How did you mux the file? The problem suggests that the muxer did not mark the keyframes in the container index.

VincAlastor

16th April 2020, 09:07

How did you mux the file? The problem suggests that the muxer did not mark the keyframes in the container index.

i muxed with mp4box Feb 2020 and mkvmerge 45.

mkvmerge i tested --cues iframes and --cues all

nothing was working.

Beelzebubu

16th April 2020, 12:50

i muxed with mp4box Feb 2020 and mkvmerge 45.

mkvmerge i tested --cues iframes and --cues all

nothing was working.

You need to file a bug report (or feature request) with mp4box to add support for invisible keyfames, which is how AV1 calls non-IDR / open-GOP keyframes.

benwaggoner

16th April 2020, 20:38

i have actualized recently (not remember a day) av1 extension from store and decoding is stilll slow.
They have updated the extension pretty regularly, alas without release notes.

Blue_MiSfit

21st April 2020, 20:14

https://www.blog.google/products/duo/4-new-google-duo-features-help-you-stay-connected/

Pretty cool, Google has announced using AV1 in their Duo voice chat app, targeting 30 Kbps!

soresu

21st April 2020, 21:19

https://www.blog.google/products/duo/4-new-google-duo-features-help-you-stay-connected/

Pretty cool, Google has announced using AV1 in their Duo voice chat app, targeting 30 Kbps!

Wow 30 kbps, that is pretty incredible, even old 2-2.5g mobile networks and ancient DSL could field that, which is probably exactly the point.

Sounds like they are also trying to compete with that Zoom app and Skype for group video calls with the current demand for it skyrocketing.

Even with them looking to expand to 12 participant group calls it would only be 330 kbps down and 30 kbps up.

Blue_MiSfit

21st April 2020, 21:41

Yeah I wonder what encoder they're using (presumably libaom), and how it's configured! I imagine they're doing like 15 fps and some very small frame size like 240x430 or 160x284

soresu

21st April 2020, 22:33

Yeah I wonder what encoder they're using (presumably libaom), and how it's configured! I imagine they're doing like 15 fps and some very small frame size like 240x430 or 160x284

Even with a small frame size they may have a dynamic res DNN scaler to sweeten the pot given their AI/ML focus in the last decade.

utack

21st April 2020, 22:55

Blue_MiSfit

22nd April 2020, 00:28

Even with a small frame size they may have a dynamic res DNN scaler to sweeten the pot given their AI/ML focus in the last decade.

That very much makes senes, though I wonder how good these can really be.... LC-EVC seems to be a much better solution than smart upscaling.

soresu

22nd April 2020, 03:33

That very much makes senes, though I wonder how good these can really be.... LC-EVC seems to be a much better solution than smart upscaling.

If it only needs to work for a phone size screen, or at worst a 10 inch tablet then it won't be much of an issue anyways.

benwaggoner

22nd April 2020, 19:55

Yeah I wonder what encoder they're using (presumably libaom), and how it's configured! I imagine they're doing like 15 fps and some very small frame size like 240x430 or 160x284
Video chat content is generally quite simple to encode. No camera motion, faces don't move that fast. So pixels/bit can typically be a lot higher than for TV/film content.

384x288 24 fps at 30 Kbps of video chat is feasible with a good HEVC and persumably AV1 encoder. Not pretty, but with lip sync and some sense of non-verbal communication. Lower frame rate and fps mean a lot of MIPS/pixel so AV1's broader encoding speed challenges shouldn't be a substantial issue.

marcomsousa

30th April 2020, 15:32

YouTube for Android TV enable AV1 video codec support on capable plaforms
https://www.xda-developers.com/youtube-for-android-tv-adopts-av1-video-codec-in-certain-devices/

hbbs

30th April 2020, 15:39

YouTube for Android TV enable AV1 video codec support on capable plaforms
https://www.xda-developers.com/youtube-for-android-tv-adopts-av1-video-codec-in-certain-devices/Just tested on my Nvidia Shield TV.

Only getting VP9. Also, apparently, there is no way to enable AV1 on the app settings.

Sent from my Moto Z3 Play using Tapatalk

hajj_3

30th April 2020, 15:55

Just tested on my Nvidia Shield TV.

Only getting VP9. Also, apparently, there is no way to enable AV1 on the app settings.

Sent from my Moto Z3 Play using Tapatalk

I assume it is just for android tv devices that have an av1 hardware decoder or maybe it is only used for low resolutions if your internet connection is slow.

foxyshadis

30th April 2020, 23:30

Just tested on my Nvidia Shield TV.

Only getting VP9. Also, apparently, there is no way to enable AV1 on the app settings.

Sent from my Moto Z3 Play using Tapatalk

Based on a look through the decompiled source, it does seem to require hardware support, and also requires Android 10. I don't think the Shield has either.

Blue_MiSfit

1st May 2020, 00:12

Shield definitely does not have a hardware AV1 decoder. It's an nVidia Tegra X1 / X1+ SOC.

soresu

1st May 2020, 03:32

YouTube for Android TV enable AV1 video codec support on capable plaforms
https://www.xda-developers.com/youtube-for-android-tv-adopts-av1-video-codec-in-certain-devices/

I believe this is pre emptive support for the rumoured Android TV powered Chromecast Ultra supposedly coming out later this year - if it uses Amlogic S905x4 as I believe it would, it should do 4K AV1 in hardware.

If that happens I would expect a ramp up in AV1 content on Youtube, Google Play Movies/TV, and Vimeo.

foxyshadis

1st May 2020, 05:28

Shield definitely does not have a hardware AV1 decoder. It's an nVidia Tegra X1 / X1+ SOC.

I would've loved to have been a fly on the wall on the meetings held over whether the AV1 block would be ready in time to meet the already delayed X1+ tape-out or not. "Just two more weeks, it's almost done!"

Selur

1st May 2020, 18:25

Is there an alternative to https://aomedia.googlesource.com/aom/+/master/examples/noise_model.c to build a film grain table for aomenc?
Preferably something that does only support humongous raw yuv files as input.
Having to:
1. create a raw yuv file from the source and from a denoised version of the source
2. create the film grain table with noise_model
(3. encode using the film grain table)
just seems like too much pain for this to be usable for anything but small samples.

So does anyone know a better tool or a better workflow to create the filmgrain tables? (may be a modified ffmpeg version?)

Cu Selur

marcomsousa

1st May 2020, 19:14

Libaom have a new branch applejack some people are saying that this is for Libaom 2.0? Anyone know anything about this?

Marco Sousa

marcomsousa

3rd May 2020, 07:45

Libaom have a new branch applejack some people are saying that this is for Libaom 2.0? Anyone know anything about this?

Marco Sousa

OK, so this branch is new branch from master some time ago, to make it stable and release libaom 2.0.0

https://bugs.chromium.org/p/aomedia/issues/detail?id=2545

Beelzebubu

3rd May 2020, 12:57

Scope

3rd May 2020, 15:20

AVIF (AV1 Image File Format): experimental support
https://bugzilla.mozilla.org/show_bug.cgi?id=1625363

Firefox 77.0a1 (2020-05-03)
https://i.imgur.com/uonsh58.png
https://i.imgur.com/5awSd0t.png

Tadanobu

3rd May 2020, 21:11

aomenc --denoise-noise-level= does the same as a FFT denoiser + examples/noise_model + aomenc --film-grain-table=.

Are you sure ? I thought --denoise-noise-level adds the same amount everywhere while the film grain table would calculate how much it adds for each frame/scene.

Beelzebubu

4th May 2020, 13:54

Are you sure ?

Yes.

I thought --denoise-noise-level adds the same amount everywhere while the film grain table would calculate how much it adds for each frame/scene.

That depends on the film grain table in the input argument. But generally speaking, if the film grain table was generated using examples/noise_model, then it invokes the exact same code as --denoise-noise-level= for film grain table generation.

Selur

4th May 2020, 16:45

Thanks for the info. :)

mzso

5th May 2020, 01:34

benwaggoner

5th May 2020, 03:46

Can I get FFmpeg with all AV1 encoders?
It seems like media autobuilds is something like that, but it also looks like a worthless POS. Spams me with a hundred questions (with stuff I don't care for maybe don't even know what they are) only to fail at the first step of trying to do anything.

What I mainly want is ffmpeg with all AV1, HEVC encoders. (and maybe other non-free good codecs)
media-autobuild-suite is the only way to get it I know of other than finding someone who's already made a binary. That said, media-autobuild-suite has something wrong that keeps it from fully building about 85% of the time....

LigH

5th May 2020, 07:59

MABS allows you to configure the set of linked codec libraries with a file build/ffmpeg_options.txt where all known supported options are listed, grouped and partially disabled due to known issues or your choice to disable codecs during your configuration of MABS as a whole (stored in build/media-autobuild_suite.ini).

mzso

5th May 2020, 10:11

media-autobuild-suite is the only way to get it I know of other than finding someone who's already made a binary. That said, media-autobuild-suite has something wrong that keeps it from fully building about 85% of the time....

I only got to:
- Download and install msys2 basic system

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------

- Downloading and unpacking msys2 basic system

-------------------------------------------------------------------------------
The Win32 internal error "Egy rendszerhez csatlakoztatott eszkÃ¶z nem mÅ±kÃ¶dik" 0x1F occurred while writing to the console output buffer at
the current cursor position. Contact Microsoft Customer Support Services.

'7za' is not recognized as an internal or external command,
operable program or batch file.

Even though nothing is specified as requirement besides OS, RAM/diskspace and Powershell.

At the very fist step it actually tries to do something, after wasting me a quarter hour asking questions for nothing.

Rumbah

5th May 2020, 22:41

Did you enable Powershell script execution?

stax76

5th May 2020, 23:03

For non-free codes you have to build it yourself then, because the resultant binary will be unredistributable. Anyone distributes that binary (like what Patman is doing) is illegal.

Which codec?

mzso

6th May 2020, 10:45

Did you enable Powershell script execution?

I don't know what that entails. I ran the .bat in powershell.

Rumbah

6th May 2020, 16:25

I don't know what that entails. I ran the .bat in powershell.

Then that might be the problem. Nowadays Powershell blocks scripts by default. And the bat file calls a .ps1 script.

You can test it by callingGet-ExecutionPolicyin Powershell.

If it says restricted you have to change it.

You have to open a Powershell window as Administrator and set the policy to unrestricted with Set-ExecutionPolicy Unrestricted
Then you can close it and try to start them MABS bat again. (I just tested MABS and on the first run it got stuck but closing it and then starting it again it downloaded everything and worked)

You can set the setting back to restricted in an admin shell by Set-ExecutionPolicy Restricted

But generally you don't have to worry much as this whole blocking thing is no security feature. There are many ways to circumvent it and it's more for admins to not hurt themselves by accident.

PS: If you only build for yourself you can try replacing "-mtune=generic" with "-march=native" in media-autobuild_suite.bat to optimize for your CPU.

LigH

8th May 2020, 07:57

MPC-HC v1.5.5

Are you sure? My current version is 1.9.2, released by clsid (https://github.com/clsid2/mpc-hc/releases).

hajj_3

8th May 2020, 09:32

Are you sure? My current version is 1.9.2, released by clsid (https://github.com/clsid2/mpc-hc/releases).

oh, i mean't MPC-BE, sorry about that.

marcomsousa

10th May 2020, 23:46

If you don't want to compile your self ffmpeg and all you have already here a docker image with that: https://hub.docker.com/r/singhkays/ffmpeg-av1-libaom (updated every day)
ARG nasm_version=2.14.02
ARG x264_version=master
ARG x265_version=3.2.1
ARG libvpx_version=v1.8.2
ARG fdk_aac_version=v2.0.1
ARG lame_version=3.100
ARG opus_version=v1.3.1
ARG libaom_version=master
ARG vmaf_version=v1.3.15
ARG ffmpeg_version=4.2.2

If you want to compile you self you have here the script: https://github.com/singhkays/docker-ffmpeg-av1-libaom/blob/master/Dockerfile (Ubuntu Bionic)

mzso

11th May 2020, 14:37

Then that might be the problem. Nowadays Powershell blocks scripts by default. And the bat file calls a .ps1 script.

You can test it by callingGet-ExecutionPolicyin Powershell.

If it says restricted you have to change it.

You have to open a Powershell window as Administrator and set the policy to unrestricted with Set-ExecutionPolicy Unrestricted
Then you can close it and try to start them MABS bat again. (I just tested MABS and on the first run it got stuck but closing it and then starting it again it downloaded everything and worked)

You can set the setting back to restricted in an admin shell by Set-ExecutionPolicy Restricted

But generally you don't have to worry much as this whole blocking thing is no security feature. There are many ways to circumvent it and it's more for admins to not hurt themselves by accident.

PS: If you only build for yourself you can try replacing "-mtune=generic" with "-march=native" in media-autobuild_suite.bat to optimize for your CPU.

I did that. It still failed at the first step with the same error:
PS E:\autobuild\media-autobuild_suite-master_2020-05-02> .\media-autobuild_suite.bat
-------------------------------------------------------------------------------

- Download and install msys2 basic system

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------

- Downloading and unpacking msys2 basic system

-------------------------------------------------------------------------------
The Win32 internal error "Egy rendszerhez csatlakoztatott eszkÃ¶z nem mÅ±kÃ¶dik" 0x1F occurred while writing to the cons
ole output buffer at the current cursor position. Contact Microsoft Customer Support Services.

'7za' is not recognized as an internal or external command,
operable program or batch file.
PS E:\autobuild\media-autobuild_suite-master_2020-05-02>

Greenhorn

11th May 2020, 20:44

I've experienced the same problem in the past.

Either it's got an invisible dependency on 7Zip, or it's trying to download MinGW and failing, without retrying on failure.

Rumbah

13th May 2020, 16:22

I did that. It still failed at the first step with the same error:
PS E:\autobuild\media-autobuild_suite-master_2020-05-02> .\media-autobuild_suite.bat
-------------------------------------------------------------------------------

- Download and install msys2 basic system

-------------------------------------------------------------------------------
-------------------------------------------------------------------------------

- Downloading and unpacking msys2 basic system

-------------------------------------------------------------------------------
The Win32 internal error "Egy rendszerhez csatlakoztatott eszkÃ¶z nem mÅ±kÃ¶dik" 0x1F occurred while writing to the cons
ole output buffer at the current cursor position. Contact Microsoft Customer Support Services.

'7za' is not recognized as an internal or external command,
operable program or batch file.
PS E:\autobuild\media-autobuild_suite-master_2020-05-02>

Are you on a NTFS drive? You need NTFS.

If that does not help just open a github issue with the required log files. They help pretty fast.

hajj_3

17th May 2020, 20:12

DXVA Checker 4.3.0 has been updated to add support for AV1.

Changelog:

Added the following alternative names of Decoder Device
AV1_VLD_Profile0
AV1_VLD_Profile1
AV1_VLD_Profile2
AV1_VLD_12bit_Profile2
AV1_VLD_12bit_Profile2_420
Minor fix

nevcairiel

18th May 2020, 08:17

Added the following alternative names of Decoder Device
AV1_VLD_Profile0
AV1_VLD_Profile1
AV1_VLD_Profile2
AV1_VLD_12bit_Profile2
AV1_VLD_12bit_Profile2_420

AV1 support was added to DXVA (Microsofts hardware acceleration API) in the Windows 10 2004 SDK update, hence where those come from. But no indication of hardware that uses them quite yet.
The other typical structures to convey codec information to the hardware are still suspiciously absent however, so it may not be fully finalized.

LigH

18th May 2020, 08:19

Your build is the last implementation dor VPx?

Will post new releases of VPx, AOM, etc. when time permits ... maybe today?

mzso

18th May 2020, 09:07

Are you on a NTFS drive? You need NTFS.
Yes, I am.

Sagittaire

18th May 2020, 12:04

Will post new releases of VPx, AOM, etc. when time permits ... maybe today?

I can find recente realise for x265, aom ... but not for VPx

hajj_3

19th May 2020, 10:37

Libaom v2.0.0 "Applejack" has been released: https://aomedia.googlesource.com/aom/+/refs/tags/v2.0.0

First official release of libaom.
This release includes new real-time mode and SVC support.
- Upgrading:
AOM_SET_POSTPROC, AOM_CODEC_CAP_POSTPROC and AOM_CODEC_USE_POSTPROC are
removed.
AOM_SET_DBG_* is removed.
Multi-resolution encoding is removed.
put_frame and put_slice callbacks are removed.
- Enhancements:
Full-sweep document update for codec controls.

LigH

19th May 2020, 11:01

Sorry for the delay: A bug in shaderc blocked the suite until I disabled mpv temporarily... / VPx is here (https://forum.doom9.org/showthread.php?p=1912629#post1912629).

The media-autobuild suite did not yet build an aomenc binary that reports itself as v2.0.0, maybe a merge to master is missing?

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 10.1.0)

AOM v1.0.0-errata1-avif-893-g9c38f3b0f (https://www.mediafire.com/file/nt60ej3kez3gu0y/aom_v1.0.0-errata1-avif-893-g9c38f3b0f.7z/file)

rav1e 0.3.0 (02018bf / 2020-05-19) (https://www.mediafire.com/file/lhzqyc2yba6dw91/rav1e_0.3.0_2020-05-19_02018bf.7z/file)

dav1d 0.7.0 (cbe05cf / 2020-05-19) (https://www.mediafire.com/file/w4z9snnnoi0406f/dav1d_0.7.0_2020-05-19_cbe05cf.7z/file)

marcomsousa

19th May 2020, 20:25

I generated one time build for libaom v2.0.0 stable branch.
https://ci.appveyor.com/project/marcomsousa/build-aom/builds/32987143/artifacts

stax76

20th May 2020, 08:42

I generated one time build for libaom v2.0.0 stable branch.
https://ci.appveyor.com/project/marcomsousa/build-aom/builds/32987143/artifacts

Thanks for the build.

Has this encoder something like a github repo?

It seems there is absolutely no version information provided by the encoder.

LigH

20th May 2020, 08:56

If you use the media-autobuild suite:
In the media-suite_compile.sh you can read that it is downloaded from https://aomedia.googlesource.com/aom by a helper function do_vcs() in media-suite_helper.sh which handles a variety of methods.

Apparently there is a git repo behind this URL, which appears as website with an own design in a browser. There are branches (MABS uses the "master" branch usually) and tags. Their relation is not very obvious, though. I am not sure but I believe there was an additional shell script which collects required information to store the version information as "tag+updatecount" in a header file...

stax76

20th May 2020, 09:55

Thanks for the info LigH, so no issue tracker. Maybe a developer reads here and bookmarks this post as feature request, I would like to suggest providing version info, examples:

Desktop> x265 --help
x265 [info]: HEVC encoder version 3.3+27-g4780a8d99
x265 [info]: build info [Windows][GCC 11.0.0][64 bit] 8bit+10bit+12bit

Syntax: x265 [options] infile [-o] outfile
infile can be YUV or Y4M
outfile is raw HEVC bitstream

Executable Options:
-h/--help Show this help text and exit
--fullhelp Show all options and exit
-V/--version Show version info and exit

Desktop> nvencc64 --help
NVEncC (x64) 5.01 (r1507) by rigaya, May 7 2020 12:04:16 (VC 1916/Win/avx2)
[NVENC API v9.1, CUDA 10.1]
reader: raw, y4m, avi, avs, vpy, avsw, avhw [H.264/AVC, H.265/HEVC, MPEG2, VP8, VP9, VC-1, MPEG1, MPEG4]
Usage: NVEncC.exe [Options] -i <input file> -o <output file>

Input can be avi, avs, raw YUV, YUV4MPEG2(y4m).
When Input is in raw format, fps, input-res is required.

Ouput format will be in raw H.264/AVC or H.265/HEVC ES.

Example:
NVEncC -i "<avsfilename>" -o "<outfilename>"
avs2pipemod -y4mp "<avsfile>" | NVEncC --y4m -i - -o "<outfilename>"

Information Options:
-h,-? --help print help
-v,--version print version info

marcomsousa

20th May 2020, 10:30

Thanks for the build.

Has this encoder something like a github repo?
It seems there is absolutely no version information provided by the encoder.

Encoder git repo: https://aomedia.googlesource.com/aom/+/refs/tags/v2.0.0

Build script for vs2019 git repo: https://github.com/marcomsousa/build_aom

In every libaom commit (in master branch) a build is automatically generated: https://ci.appveyor.com/project/marcomsousa/build-aom/history
Now it goes with v2.0.0-255-ge0be17e7f

The version you can see if you perform:
aomenc.exe --help
(...)
Included encoders:
av1 - AOMedia Project AV1 Encoder 2.0.0 (default)
Use --codec to switch to a non-default encoder.

aomenc.exe --help
(...)
Included encoders:
av1 - AOMedia Project AV1 Encoder 2.0.0-255-ge0be17e7f (default)
Use --codec to switch to a non-default encoder.

hydra3333

20th May 2020, 10:33

no issue tracker.
is this it ?
https://bugs.chromium.org/p/aomedia/issues/list
google look at and respond in it, eg by addressing a couple of very trivial things I may have raised.

LigH

20th May 2020, 15:17

There must have been a merge in the meantime.

AOM v2.0.0-255-ge0be17e7f (https://www.mediafire.com/file/pfpmduhd8xuh79l/aom_v2.0.0-255-ge0be17e7f.7z/file)

And yes, the bug tracker should match.

benwaggoner

21st May 2020, 22:35

AV1 support was added to DXVA (Microsofts hardware acceleration API) in the Windows 10 2004 SDK update, hence where those come from. But no indication of hardware that uses them quite yet.
The other typical structures to convey codec information to the hardware are still suspiciously absent however, so it may not be fully finalized.
There aren't any GPUs out or (IIRC) announced with HW AV1 decode. I'm confident they're being worked on, of course, although it's speculation as to when, which, and how universally across product lines.

birdie

22nd May 2020, 16:04

Yups

22nd May 2020, 16:50

I was hoping for encoding as well but it seems not so easy to implement. Is it correct that Gen12 only supports 4K video decoding?

Blue_MiSfit

22nd May 2020, 18:05

Source for those captures?

Yups

22nd May 2020, 18:32

Momomo_us posted this: https://twitter.com/momomo_us/status/1263818639423074304

He didn't reveal the original source.

benwaggoner

22nd May 2020, 18:56

Looks like Tiger Lake will be the first x86 uArch to support AV1 HW decoding:

https://pbs.twimg.com/media/EYn7NM0VAAEnkO8?format=png&name=orig
https://pbs.twimg.com/media/EYn7f9BUEAAs-Io?format=png&name=orig
https://pbs.twimg.com/media/EYn72cxUEAgq_zV?format=png&name=orig
https://pbs.twimg.com/media/EYn8WKXU0AAV42f?format=png&name=orig

I do hope NVIDIA will support it as well in Ampere.
Looks like a good media unit for a non-discreet GPU. I think 12-bit HEVC decode is new as well. I wonder what use cases the 12-bit support is; NVidia has had it for a few years as well. I can see it being used for high-bitrate mezzanine files or something. Can't imagine a 12-bit VP9 scenario, though.

I note they don't list bit depths for AV1. Does that imply 8-bit only? They don't list it for AVC either, does Intel support >8-bit AVC decode, or only with more advanced codecs.

Yups

22nd May 2020, 19:07

I note they don't list bit depths for AV1. Does that imply 8-bit only? They don't list it for AVC either, does Intel support >8-bit AVC decode, or only with more advanced codecs.

There are bit depths listed but it's not clear to me. One the left it says profile0 (8 bit and 10 bit 4:2:0) 4k60 video, 16K still. The text on the right side is confusing. Intel only supports 8 bit for AVC by the way.

hajj_3

22nd May 2020, 19:37

Looks like a good media unit for a non-discreet GPU. I think 12-bit HEVC decode is new as well. I wonder what use cases the 12-bit support is; NVidia has had it for a few years as well. I can see it being used for high-bitrate mezzanine files or something. Can't imagine a 12-bit VP9 scenario, though.

I note they don't list bit depths for AV1. Does that imply 8-bit only?

12bit av1 with rocket lake, tiger lake and their standalone graphics card:

https://cdn.wccftech.com/wp-content/uploads/2020/03/Intel-12th-Generation-Rocket-Lake-S-Desktop-CPU-Lineup-Platform-Details-1480x720.jpg

Yups

22nd May 2020, 19:50

12bit av1 with rocket lake, tiger lake and their standalone graphics card:

This is an RKL-S slide, you can never know if there is a newer decoder build in for RKL-S because it comes about half a year later than TGL-U. Also this slide isn't as detailed as today's leak, it could be a mistake there. 12 bit HEVC but not for AV1, it could be.

Yups

22nd May 2020, 20:41

10 bit sure but do we really need 12 bit?

Beelzebubu

23rd May 2020, 00:09

it would be disappointing if they didn't support 8K, 12-bit and 4:4:4 like VP9 hardware decoder does in Gen12/Xe.

It says profile 0 only, which is 4:2:0 and 8+10bit only. 4:4:4 is profile 1, 12-bit is profile 2 (along with 4:2:2 for 8+10bit).

benwaggoner

23rd May 2020, 01:43

10 bit sure but do we really need 12 bit?
Dolby Vision is internally 12-bit, and does tricks with dual layers or a non-backwards compatible base layer and metadata to reconstruct the video in an internal 12-bit format. If we had 12-bit decoders when DoVi was coming out, we'd probably just have a HDR-12 base layer + metadata.

Only current use of 12-bit for anything I can think of is in intermediate post production or high end mezzanine formats like J2K IMF.

soresu

23rd May 2020, 08:10

Dolby Vision is internally 12-bit, and does tricks with dual layers or a non-backwards compatible base layer and metadata to reconstruct the video in an internal 12-bit format. If we had 12-bit decoders when DoVi was coming out, we'd probably just have a HDR-12 base layer + metadata.

Only current use of 12-bit for anything I can think of is in intermediate post production or high end mezzanine formats like J2K IMF.

Isn't all this pointless when hardly any TVs actually support 12 bit though?

Yups

23rd May 2020, 12:25

It says profile 0 only, which is 4:2:0 and 8+10bit only. 4:4:4 is profile 1, 12-bit is profile 2 (along with 4:2:2 for 8+10bit).

Even in this leak there is a discrepancy. In the table there is 10 bit for video but the text says it's 8 bit for video. I'm keen to believe the table in this case but not sure. In the RKL-S slide there is 12 bit AV1, it could be just a mistake (confused with 12 Bit HEVC), it could refer to still image or it could be that the Gen12LP in RKL-S uses a newer decoding unit than TGL-U.

Beelzebubu

23rd May 2020, 19:50

Even in this leak there is a discrepancy. In the table there is 10 bit for video but the text says it's 8 bit for video.

I think you're misreading a table converted to text. The table says "profile 0 (8-bit and 10-bit 4:2:0) 4k60 video, 16k still (HW decode)". The text says "AV1 codec support<newline>Profile 0 (10-bit 4:2:0)<tab>16k (still picture)<newline>Profile 0 (8-bit 4:2:0)<tab>4k x 2k (video)". I inserted the <tab> because it matches what the table says: 4k60 (4k x 2k) video, 16k still (picture) and each supporting profile 0 (8-bit & 10-bit, 4:2:0).

Sagittaire

23rd May 2020, 20:41

aomenc --denoise-noise-level= does the same as a FFT denoiser + examples/noise_model + aomenc --film-grain-table=.

Well seem not work. I have denoise but seem not have FGM in output.

You have command line exemple?

Beelzebubu

23rd May 2020, 20:54

Well seem not work. I have denoise but seem not have FGM in output.

Please show your commandlines.

Sagittaire

23rd May 2020, 21:15

Please show your commandlines.

for exemple.

aomenc.exe -o ToS-1000.ivf C:\ToS_1920x800_xdither.y4m --ivf --i420 --width=1920 --height=800 --fps=25000/1000 --passes=2 --pass=1 --fpf=stats.log --target-bitrate=960 --maxsection-pct=4000 --buf-sz=12000 --buf-initial-sz=8000 --buf-optimal-sz=10000 --end-usage=vbr --cpu-used=3 --verbose --tune=ssim --psnr --q-hist=30 --bit-depth=10 --bias-pct=75 --kf-max-dist=120 --aq-mode=2 --test-decode=fatal --limit=1332 --skip=214 --denoise-noise-level=25

aomenc.exe -o ToS-1000.ivf C:\ToS_1920x800_xdither.y4m --ivf --i420 --width=1920 --height=800 --fps=25000/1000 --passes=2 --pass=2 --fpf=stats.log --target-bitrate=960 --maxsection-pct=4000 --buf-sz=12000 --buf-initial-sz=8000 --buf-optimal-sz=10000 --end-usage=vbr --cpu-used=3 --verbose --tune=ssim --psnr --q-hist=30 --bit-depth=10 --bias-pct=75 --kf-max-dist=120 --aq-mode=2 --test-decode=fatal --limit=1332 --skip=214 --denoise-noise-level=25

the noise is dithering. Perhaps not adapted denoising value for that? I try with --denoise-noise-level=5,10,50 and no result.

Beelzebubu

24th May 2020, 03:42

for exemple.

the noise is dithering. Perhaps not adapted denoising value for that? I try with --denoise-noise-level=5,10,50 and no result.

Dithering should be fine. Does --help include a description for --denoise-noise-level? It might be built without CONFIG_DENOISE (in which case the --help output will be missing also). Otherwise I'm not entirely sure, it has worked fine for me. Does it work on 8-bit material?

Sagittaire

25th May 2020, 23:58

Dithering should be fine. Does --help include a description for --denoise-noise-level? It might be built without CONFIG_DENOISE (in which case the --help output will be missing also). Otherwise I'm not entirely sure, it has worked fine for me. Does it work on 8-bit material?

well seem work only if you have noise_model.exe in same directory than aomenc.exe ... ?

benwaggoner

26th May 2020, 01:50

Isn't all this pointless when hardly any TVs actually support 12 bit though?
Certainly for the moment, yes. Perhaps 12-bit could become a default with VVC or AV2.

soresu

26th May 2020, 17:42

Oh man, the new Cortex X1 CPU core has twice the NEON units of the A78 and previous Axx cores.

At 4x 128 bit units that's some real grunt for an off the shelf design, should be noice for encoding.

mzso

17th June 2020, 09:41

What kind of beast of a computer would you need to play 8k AV1?
I wanted to check out a few 8k videos on Youtube, but I accidentally downloaded AV1 streams, and the videos ate up my R5 1600. Even VP9 did...
I wonder if any mere mortal will have such a machine in the next decade.

ChaosKing

17th June 2020, 11:28

Beast machine? You used the wrong player!
In my browser it is almost smooth, with some dopped frames
In mpv it is perfect with ~ 55% cpu

My pc: ryzen 2600 (no oc) + gtx 1070
8K Video: https://www.youtube.com/watch?v=ChOhcHD8fBA

huhn

17th June 2020, 11:36

your GPU can decode this video...

ChaosKing

17th June 2020, 12:58

gtx 1070 does not have a HW AV1 decoder...
And mpv uses the dav1d decoder which works on cpu only.

nevcairiel

17th June 2020, 16:52

benwaggoner

18th June 2020, 02:04

My 7900X (OC) can also play that video in 8K without drops, at 40% usage at most - straight in Chrome 83. Make sure its not your GPU that struggles downscaling the 8K video.

With Ryzen making 8 cores available to "mere mortals" for relatively low pricing, I don't think you need any particular "beast" right now, nevermind the next decade.
How well are the fast SW decoders scaling with multiple cores? VP9 struggled to get much parallelism due to some unfortunate serialization in the loop filters and the lack of a clear reference structure that allowed for parallel decoding of non-reference frames.

AV1 is certainly going to be more parallizable than VP9. But how far have the best decoders gone so far?

huhn

18th June 2020, 04:00

gtx 1070 does not have a HW AV1 decoder...
And mpv uses the dav1d decoder which works on cpu only.

the video is as far as i can see only VP9 8 bit.
if there is a AV1 version i could try it with an R7 3700X which could yield up to ~2.5x more performance then a r5 2600 in this special case
How well are the fast SW decoders scaling with multiple cores? VP9 struggled to get much parallelism due to some unfortunate serialization in the loop filters and the lack of a clear reference structure that allowed for parallel decoding of non-reference frames.

AV1 is certainly going to be more parallizable than VP9. But how far have the best decoders gone so far?
this doesn't seam to be the case anymore or it's not as bad as it was in the past. while the microsoft VP9 decoder has issues using more then 8 threads ffmpeg in lavfilter doesn't have this issues easily using 70-90% CPU usage on a 8 core 16 thread CPU. it sometimes falls to 50% or lower CPU usage but with usually over 100 FPS.

ChaosKing

18th June 2020, 08:17

I think I activated AV1 on YT, it was under /testtube or so. Just google it.
I used youtube-dl.exe to download the video, it was the av1 version.

@nevcairiel I use Vivaldi and have currently over 100 tabs open xD It can have an effect on performance

AV1 is certainly going to be more parallizable than VP9. But how far have the best decoders gone so far?

https://www.phoronix.com/scan.php?page=news_item&px=Dav1d-0.7-Performance

Over 300fps for 4k is not bad
I hope 10bit decoding will be faster on ARM soon too. My 4k fire tv stick struggles with 1080p 10bit video

huhn

18th June 2020, 09:26

i'm still confused by YTDL doesn't showing it before. but this make far more sense now to me.
the stream is very easy to decode i get about 40~ FPS with 50% CPU usage using lavfilter from mpc-hc 1.9.4.

soresu

18th June 2020, 11:41

I hope 10bit decoding will be faster on ARM soon too. My 4k fire tv stick struggles with 1080p 10bit video

10 bit isn't likely to get much better on ARM64 as most of the NEON asm has been written at this point - the problem is that all Fire TV products use 32 bit ARM Android as a base due to laziness on their part IMHO, therefore you won't get as much performance out of it as a phone or tablet with the same HW spec.

They probably will fill out the ARM32 NEON asm over time, though I'm not sure if the performance will match the ARM64 equivalent code path.

10 bit on x86 is another matter entirely - as far as I am aware there are zero SIMD assembly optimisations currently for AVX2, SSSE3 or SSE2 where 10+ bpc video is concerned.

Beelzebubu

18th June 2020, 13:35

How well are the fast SW decoders scaling with multiple cores? VP9 struggled to get much parallelism due to some unfortunate serialization in the loop filters and the lack of a clear reference structure that allowed for parallel decoding of non-reference frames.

AV1 is certainly going to be more parallizable than VP9. But how far have the best decoders gone so far?

I don't think this is true. From a decoder's point-of-view, the reference structure (most notably the cross-frame entropy dependency) and postfilter dependency (tile-crossing) between VP9 and AV1 are the same, and equally parallelizable. dav1d uses the same techniques for frame threading as FFmpeg's native VP9 decoder (ffvp9) and achieves siimilar concurrency multipliers as dav1d. Tile threading works the same. See e.g. graphs at https://youtu.be/WgfklAi50nM?t=1378 (VP9 vs. AV1) and https://youtu.be/WgfklAi50nM?t=345 (AV1 tile vs. frame vs. both multithreading), and note that these results are over a year old, dav1d has surpassed ffhevc (SW) decoding speed since then. See also the documentation for the threading model (https://code.videolan.org/videolan/dav1d/-/wikis/Threading-model) in dav1d.

The practical problem in ffvp9 is that it decided (to fit in FFmpeg's more static design) to only allow one threading type (frame or tile) instead of multiple concurrently (frame and tile) like dav1d does. That's the only reason dav1d scales better with multi-threading. We could have resolved that, but it was decided that ffvp9 was fast enough and it wasn't worth it.

(I can explain libaom's and libvpx' threading models if you want to learn more, but since they are a subset of dav1d/ffvp9, I was assuming this would be enough. I'm not familiar with gav1's threading model.)

Blue_MiSfit

20th June 2020, 04:04

Great post! ^

Mr_Khyron

21st June 2020, 15:03

MainConcept Brings Fast, Efficient AV1 Encoding to More Video Platforms
https://www.prnewswire.com/news-releases/mainconcept-brings-fast-efficient-av1-encoding-to-more-video-platforms-301071452.html
SAN DIEGO, June 10, 2020 /PRNewswire/ --
MainConcept, a leading provider of codec and streaming technology to the professional and broadcast industries, today announced it has worked with Intel Corporation to integrate Scalable Video Technology for AV1 (SVT-AV1) encoder into the MainConcept codec portfolio. This move will allow content producers to better leverage the increased compression capacity of AV1 and bring high-performance, scalable and efficient encoding for video-on-demand (VOD) streaming to the ever-growing video delivery marketplace.

https://code.videolan.org/videolan/dav1d/-/tags/0.7.1
dav1d 0.7.1 'Frigatebird' the fast and lean AV1 decoder

This is a minor update of the dav1d decoder, from the 0.7.x branch.

This release increases the speed of decoding on ARM32 by up to 28%,
adds some SSE2 optimizations, some AVX2 for MC scaled
and fixes a couple of minor issues.

soresu

23rd June 2020, 16:44

And mpv uses the dav1d decoder which works on cpu only.

It has some code that can run on the GPU, but from what I can gather it only increases power efficiency on mobile systems.

Whether this is because they only tested 8 bpc content which is optimized up the yin yang on most CPU SIMD ISA's at this point I don't know, I have yet to see a more comprehensive testing of the GPU code shown which encompasses 8 bpc and 10+bpc content separately.

From what I can gather there is also not much code that runs on the GPU at this point, this could always change in the future.

benwaggoner

23rd June 2020, 22:26

It has some code that can run on the GPU, but from what I can gather it only increases power efficiency on mobile systems.

Whether this is because they only tested 8 bpc content which is optimized up the yin yang on most CPU SIMD ISA's at this point I don't know, I have yet to see a more comprehensive testing of the GPU code shown which encompasses 8 bpc and 10+bpc content separately.

From what I can gather there is also not much code that runs on the GPU at this point, this could always change in the future.
GPU accelerated decode tends to only be a tactical thing used in the early days of a codec. If it catches on, it gets implemented in hardware (CPU, GPU, SoC). Otherwise CPUs get fast enough all software decode gets used.

Stuff like CABAC is not well suited to run on a GPU, so an all GPU compute decoder hasn't really been feasible or worthwhile.

NikosD

26th June 2020, 14:38

If it catches on, it gets implemented in software. You mean hardware, obviously.

benwaggoner

26th June 2020, 19:13

You mean hardware, obviously.
Oops. yes indeed. Thanks for the catch, and I have corrected.

mzso

28th June 2020, 10:52

My 7900X (OC) can also play that video in 8K without drops, at 40% usage at most - straight in Chrome 83. Make sure its not your GPU that struggles downscaling the 8K video.

With Ryzen making 8 cores available to "mere mortals" for relatively low pricing, I don't think you need any particular "beast" right now, nevermind the next decade.

Well, I have an RX 580 with the R5 1600 and it's the CPU is what I see saturated. Both AV1 and VP9. And madVR shows decoder queue 1-4/4 upload/render 1-2/4, present 0-1/4

It doesn't seem like the GPU gets a chance to be too slow.

By the way I tried these videos' 8k AV1/VP9 streams:
https://www.youtube.com/watch?v=zCLOJ9j1k2Y
https://www.youtube.com/watch?v=1La4QzGeaaQ

huhn

28th June 2020, 11:41

zen 1 and 1+ have a bad AVX/AVX2 implementation they need 2 cycles to do such a operation unlike intel and zen 2 which can do that in 1 giving them 2x the ipc in decoding of modern codecs.

these are 8k 60 this is to much for my CPU too it's not even close.
edit:i take it back i get it barely working with EVR-CP.

marcomsousa

1st July 2020, 18:17

Chrome 85 will have AVIF support by default (Beta Jul 23, release Aug 25)

Yups

9th July 2020, 21:57

As for Intels Gen12 their Open source driver did enable AV1 decoding: https://github.com/intel/media-driver/commit/9491998f40d496fc458d282f213c0e9e945b8062

In one file (https://github.com/intel/media-driver/blob/7249f5c0d5185950da66ba9cd3d94defc19e2468/media_driver/agnostic/gen12/codec/shared/codec_def_common_av1.h) it says MaxTile is 4096x2304, this coincides with the leak about Tigerlake 4k60 video.

huhn

10th July 2020, 00:10

great there can't be enough hardware decoder for promising codecs.

Yups

10th July 2020, 15:52

benwaggoner

10th July 2020, 17:22

Not even 8K 12 bit sounds strange, there is no real need for 12 bit. Actually it's similar to Gen9.5 which supports 8/10 Bit 4:2:0 VP9/HEVC, even though it did support 8K afaik. Apparently it's not a trivial VP9 copy and paste, you should be happy that at least one major GPU IHV is going to support AV1 this year even if it's not the super highest possible variant.
AV1 is a pretty complex bitstream to decode.

For moving image content for humans to watch at a distance where they can comfortably see the action in all four corners of the screen, 8K is pretty much indistinguishable from 4K. No one is actually mastering premium content in 8K (some 8K cameras get used, but all post is done in 4K, and often 2K for VFX).

12-bit has some theoretical value, but it's not like there are native 12-bit panels to watch it on. Given all the dithering that goes on, 10-bit is sufficient in most cases. 12-bit's value would mainly to be to not have to worry about dithering in post and encoding with HDR, like how 10-bit pretty much eliminates those concerns with SDR.

All that said, has anyone seen any compelling research on AV1 encoding in HDR or 4K? Pretty much everything I've read at outside of marketing and demos has been SDR and 1080p or lower.

LigH

15th July 2020, 14:54

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 10.1.0)

AOM v2.0.0-608-gcae201b6c (https://www.mediafire.com/file/hbra3g35y4eob50/aom_v2.0.0-608-gcae201b6c.7z/file)

rav1e 0.3.0 (01052fc / 2020-07-15) (https://www.mediafire.com/file/pdwer0ky1s7s8ep/rav1e_0.3.0_2020-07-15_01052fc.7z/file)

dav1d 0.7.1 (1317e61 / 2020-07-15) (https://www.mediafire.com/file/3jxrkg62tbp4c3t/dav1d_0.7.1_2020-07-15_1317e61.7z/file)

marcomsousa

17th July 2020, 13:39

Youtube is giving me AV1 videos without changing configuration on a fresh Windows 10 installed in Chrome without login in Youtube on a i5-1035G1 CPU - 499€ Laptop.

Justing clicking on the first 5 videos from the main page. 3 are AV01 at 1080p and the other VP9.

hbbs

17th July 2020, 13:54

Since AOM AV1 2.0.0 was released a couple of months ago. Have anyone seen a YouTube AV01 video encoded using it?

I always thought AV01 meant AOM 1.X.X

Sent from my Moto Z3 Play using Tapatalk

marcomsousa

17th July 2020, 14:01

AV01 = AOM (AV1)
The next AV2, would be AV02 in youtube.

Also Is normal that Google isn't executing exacly the same version as in the Web. Normal a big company adds small changes to source code for specific Google Platform or backporting fixes.

Note: libaom 2.0.0 is nothing related with AV02 is just an improved version ov AV01 encoder.

hbbs

17th July 2020, 14:14

AV01 = AOM (AV1) - the version encoded will not be shared (Also, is normal they adds small changes to source code for specific Google Platform)

The next AV2, would be AV02 in youtube.Thanks for replying it.

Since you mentioned AV2. Now that VVC is out. Is there anything shared about the developments of AV2?

I remember reading somewhere that Apple was pushing AV2 since they joined AOM late in the game.

Sent from my Moto Z3 Play using Tapatalk

nevcairiel

17th July 2020, 14:22

AV2 development has practically only just started, it'll be a while before anything substantial can be said about it.

mzso

18th July 2020, 08:52

AV2 development has practically only just started, it'll be a while before anything substantial can be said about it.

Will they do the same old? Stick with the basics and make it more convoluted and computation heavy?

(Somehow I doubt they'll try something different, like Daala did with lapped transforms)

benwaggoner

18th July 2020, 22:26

Will they do the same old? Stick with the basics and make it more convoluted and computation heavy?

(Somehow I doubt they'll try something different, like Daala did with lapped transforms)
More years of patents will have expired, so there are likely patented techniques they couldn't use in AV1 which are now available to use in AV2. Plus they have experience seeing what limitations there are holding back encoders and decoders, and they can engineer around those. Getting more HW decoder vendors involved early could help a LOT. MPEG codecs get way, way more input on how to optimize bitstream design to allow for low-cost HW implementations than AV1 did.

For all the complexity of VVC on the encode side, from everything I've heard it'll still be able to have cheaper, simpler decoders than AV1 can.

mzso

26th July 2020, 18:47

More years of patents will have expired, so there are likely patented techniques they couldn't use in AV1 which are now available to use in AV2. Plus they have experience seeing what limitations there are holding back encoders and decoders, and they can engineer around those. Getting more HW decoder vendors involved early could help a LOT. MPEG codecs get way, way more input on how to optimize bitstream design to allow for low-cost HW implementations than AV1 did.

For all the complexity of VVC on the encode side, from everything I've heard it'll still be able to have cheaper, simpler decoders than AV1 can.

One would hope that there's something better out there than making decades old heritage ever more complicated. Just because wavelets and lapped transforms didn't quite work out, it doesn't mean there isn't a better way to encode video.

Honestly, creating another similar (but more complicated) format AV2 seems really pointless at this point. Either create something revolutionary or keep optimizing AV1 encoding/decoding. AVC has been around for many years and will remain for many more. MPEG-2 and ASP didn't die out yet either.

marcomsousa

26th July 2020, 20:06

AV1 will continue to be optimized for the next 5-10 years without changing format.

Changing format is AV2. The development format process will takes 2 to 3 years+5 years for HW decoder+encoder. So developing the new AV2 can be started anytime now.

If software patents expired in 20 years, so AV2 can have a lot of old technics.

Marco Sousa

benwaggoner

27th July 2020, 02:12

One would hope that there's something better out there than making decades old heritage ever more complicated. Just because wavelets and lapped transforms didn't quite work out, it doesn't mean there isn't a better way to encode video.

Honestly, creating another similar (but more complicated) format AV2 seems really pointless at this point. Either create something revolutionary or keep optimizing AV1 encoding/decoding. AVC has been around for many years and will remain for many more. MPEG-2 and ASP didn't die out yet either.
Well, the thing is that iterations and refinement of block-based frequency transform coding keep on showing bigger potential gains than the Big Idea alternative transforms. Some of this could be because of the momentum of R&D around the traditional stuff. Or it could be that we luckily hit upon the right essential transform that balances spatial and temporal prediction better than available alternatives. Arguably modern compression is reallly "just" elaborations of JPEG and H.261. But oh, how elaborate!

mzso

27th July 2020, 15:03

Well, the thing is that iterations and refinement of block-based frequency transform coding keep on showing bigger potential gains than the Big Idea alternative transforms. Some of this could be because of the momentum of R&D around the traditional stuff. Or it could be that we luckily hit upon the right essential transform that balances spatial and temporal prediction better than available alternatives. Arguably modern compression is reallly "just" elaborations of JPEG and H.261. But oh, how elaborate!

"Or it could be that we luckily hit upon the right essential transform that balances spatial and temporal prediction better than available alternatives."

I highly doubt it. I think it's more likely the illusion of familiarity and the blinders that come with it.

"Some of this could be because of the momentum of R&D around the traditional stuff."

It certainly seems like that alternatives got only limited efforts on them.

benwaggoner

27th July 2020, 20:47

"Or it could be that we luckily hit upon the right essential transform that balances spatial and temporal prediction better than available alternatives."

I highly doubt it. I think it's more likely the illusion of familiarity and the blinders that come with it.

"Some of this could be because of the momentum of R&D around the traditional stuff."

It certainly seems like that alternatives got only limited efforts on them.
Yeah. It's really hard to disprove the hypothesis that there could be better fundamental ways of encoding.

That said, wavelets sure got a lot of attention for image and motion coding. Good for images, but no one figured out an efficient motion compensation strategy for it.

Daala had a lot of really intriguing notions, but the most interesting stuff in it never really got to a promising proof of concept. Sure, maybe with 10 years of 1000 engineers something could be found. Any alternative transforms have to compete with decades of refinement of block-based frequency coding.

A lot of promising ideas get figured out how to port into a block-based structure. For example, HEVC's transform skip mode can make anime, graphics, and text way easier to encode at low bitrates and high quality. So new features, like have been seen in VVC and AV1, can get included as tools. Arguably, once you have 64x64 or bigger blocks, you've pretty much got all the advantages of wavelet coding already, within a block based model. And intra-frame prediction brings a lot of the potential value of fractal encoding.

One exciting thing (to me at least) about Daala that didn't make it into AV1 was doing frequency-domain prediction, so there was no need to rasterize a frame that wasn't going to get displayed, and dithering didn't need to be included in quantization. It didn't work out for reasons I don't quite recall.

nhw_pulsar

29th July 2020, 20:17

Hello,

Thank you for your nice comment about wavelets for images (as I have also made a wavelet image codec, called NHW...).

You said: "but no one figured out an efficient motion compensation strategy for it". Do you think this is this aspect that prevents organizations such as Alliance for Open Media from starting and supporting a wavelet codec?

Cheers,
Raphael

foxyshadis

1st August 2020, 11:13

Arguably, once you have 64x64 or bigger blocks, you've pretty much got all the advantages of wavelet coding already, within a block based model.
I remember in the late 90's, first working with codecs in code, thinking that 8x8 must be some kind of fundamental limit of DCT, and wavelets must be superior since they can go from 128x128 all the way to 4096x4096 in JPEG2000. No, it turns out engineers were just excited about the new hotness instead of extending the old battleaxe, DCT, plus it would take at least until SSE2 to really be able to optimize transforms larger than 8x8.

I still think that *lets, curvelets, ridgelets, etc, could help further reduce still images/I-frames, but all the new prediction modes have really put a huge dent in how residuals look.

One exciting thing (to me at least) about Daala that didn't make it into AV1 was doing frequency-domain prediction, so there was no need to rasterize a frame that wasn't going to get displayed, and dithering didn't need to be included in quantization. It didn't work out for reasons I don't quite recall.

From the Graveyard of Dead Tools post (https://jmvalin.ca/daala/revisiting/), it just never worked as well as spatial-domain, since it was another NP-hard idea. It's notable that most of the dead tool ideas came from audio coding, which is Monty's real wheelhouse, but Xiph still managed to push the state of the art and conjure up a real codec; I'm still waiting for a good intra paint plugin for Photoshop, because that tool is amazing.

nhw_pulsar

2nd August 2020, 10:28

LigH

3rd August 2020, 07:43

Dead tools and video codecs and wavelets ... hmm ... I believe I still have a copy of Rududu.

nhw_pulsar

3rd August 2020, 09:33

I did not test Rududu video codec, but I have tested the latest Rududu Image codec (RIC) and it is very good.If I remember correctly, RIC is kind of enhanced and state-of-the-art SPIHT, which is a different technology from NHW.-For the little story, when Rududu author released RIC in march 2008, I was totally blown away by its very impressive results on objective metrics like PSNR and by its very good precision, and then I realized that I could not be at that level of PSNR and precision with NHW, and so then I definitely decided to orientate NHW towards neatness and visual aspect.-

To come back on-topic, yes possibly in the late 90's with JPEG2000, wavelets were the hotness, but frankly since 2001, DCT block-based intra prediction+residual coding is really the main research focus of the industry.Wavelet compression research has been abandoned for years (by industry) actually, the last release of Dirac was in 2008, the last release of Rududu was also in 2008, Snow is around 2008, and most of the main ideas of NHW were also made in 2008...

Who believes organizations like AOM could restart wavelet compression technology today?

Cheers,
Raphael

Yups

7th August 2020, 01:25

A new slide appeared on imgur with the media capabilities of Tigerlake-U.

https://i.imgur.com/Udoa851.png

Previously it was 4k60 and here it's 8k30 AV1.

NikosD

7th August 2020, 05:15

A new slide appeared on imgur with the media capabilities of Tigerlake-U. They have increased the speed - from 8K30 to 8K60 - of HEVC/VP9 decoder too.
They have added 12bit HEVC/VP9 decoding.
Also, that SCC of the table means Screen Content Coding and it's a HEVC profile/extension, optimized for screen captured content.
It could be used by streaming apps/services like YouTube, Skype, Zoom, Netflix etc but I don't know the real use of this extension.
And it's the first time I see this in the supported features of any decoder.

foxyshadis

7th August 2020, 06:35

Hello @foxyshadis,

Hope that I am not trolling too much, I of course agree on the technical side with you and the other impressive reference members here, but I contacted you about Xiph as you seem to know well Monty and this organization.

Do you think Xiph can be interested in the NHW Project? Unfortunately I can not have contact with them, and maybe just like Alliance for Open Media, Xiph is not interested in NHW because it does not work for any image resolution? And that's why my submissions at Xiph and AOM are ignored? I thought that NHW could be a good project for Xiph... (that's only my opinion of course), and certainly a better fit than AOM, but maybe Xiph also only supports excellent codecs and they don't estimate that NHW is one of them?

Many thanks.
Cheers,
Raphael

If you have something that pushes the state of the art, especially if it can be dropped in to a small code segment, not the whole codebase, and you are willing to give it away patent-free and can verify that no one else has patents on it, AOM wants to hear from you.

But they had to deal with getting things encoded and decoded in a reasonable time. AV1 seems slow, but it's miles ahead of what it could have been. Like MPEG, it chops out anything that isn't fast enough to make the cut, and maybe a refinement will make it next generation.

nhw_pulsar

7th August 2020, 09:14

If you have something that pushes the state of the art, especially if it can be dropped in to a small code segment, not the whole codebase, and you are willing to give it away patent-free and can verify that no one else has patents on it, AOM wants to hear from you.

But they had to deal with getting things encoded and decoded in a reasonable time. AV1 seems slow, but it's miles ahead of what it could have been. Like MPEG, it chops out anything that isn't fast enough to make the cut, and maybe a refinement will make it next generation.

Many thanks for your answer.

Yes, I think there are new ideas/processings in the NHW Project that can give interesting "state-of-the-art" results, I don't think they are patended because I never saw them described in the Internet nor in the litterature, and so I am totally willing to give them to AOM patent-free.

The "big" problem is that these new ideas/processings are completely tailored for wavelet coding and wavelet decomposition, I don't think they are adaptable/transposable to DCT AV1 codebase for example... And so that's maybe why AOM always answered me that they were not interested in NHW?

Cheers,
Raphael

nhw_pulsar

9th August 2020, 17:59

Hello,

Just a quick reply, it seems that wavelets are not well-suited for current highly-efficient video codecs with block-based motion compensation/estimation, and so I don't think AOM wants to include then NHW in one of its video codec...

However NHW seems well-suited for an image codec, because it has state-of-the-art results for 0.4bpp to 2bpp which is the Internet range (NHW is not good for extreme compression for now, which can also be a problem for a video codec...), it is also very fast which is an advantage for mobile devices...

Again I am totally open to give my technology to AOM for free, and maybe they'll review it, but for now, all the answers I had from AOM, Google, are: "sorry, we are not interested" or "sorry, we don't have time to study your work"... This is very brief... @foxyshadis, I am very sorry for my impoliteness, maybe you would have contact within AOM and maybe you could inform me what's blocking with NHW? What would need to be changed/improved? Because it would help me a lot to have such advice, and to eventually know what to improve and maybe then become of consideration/interest for AOM?

Cheers,
Raphael

benwaggoner

11th August 2020, 00:27

From the Graveyard of Dead Tools post (https://jmvalin.ca/daala/revisiting/), it just never worked as well as spatial-domain, since it was another NP-hard idea. It's notable that most of the dead tool ideas came from audio coding, which is Monty's real wheelhouse, but Xiph still managed to push the state of the art and conjure up a real codec; I'm still waiting for a good intra paint plugin for Photoshop, because that tool is amazing.
Anyone who has some idea they are sure is brilliant in video coding needs to read that Graveyard of Dead Tools post to see how all sorts of smart ideas wind up not being of practical advantage. It's a good reinforcer of humility.

++ on the intra paint plugin idea!

nhw_pulsar

11th August 2020, 10:16

Anyone who has some idea they are sure is brilliant in video coding needs to read that Graveyard of Dead Tools post to see how all sorts of smart ideas wind up not being of practical advantage. It's a good reinforcer of humility.

++ on the intra paint plugin idea!

Yes, I have also theoretical ideas for a wavelet video codec, but I also fear that they turn out of no practical advantage.

Very quickly, I wanted to rectify my previous post because I completely forgot that an engineer from Google told me that NHW has serious aliasing and discoloration artifacts that must be corrected.For aliasing, I thought about a post-processing function in the decoder which will detect aliasing and remove it from the decoded Y luma comp, but I must admit that I am ultra lazy and also demotivated for now... For discoloration, it can be corrected but I want to do this with Chroma from Luma technique because it will also save quite a lot of bits.

So yes NHW has some drawbacks, and there is a reason why the industry has chosen AVIF and JPEG XL as the new image compression standards.I think they have certainly evaluated the pros and the cons of the different solutions/codecs, and so made that choice, and I totally respect it of course because they are a lot more skilled than me to evaluate it.

Just to finish, if I can advertise my skills, I think I have a good knowledge of wavelet coding, and if you would have such projects, I am very interested and could work on it with a freelance contract for example... Image/video compression is a passion for me (and also as I struggle hard with jobs here), and I would like to live of it now...

I will try not to pollute that much the AOM thread now.

Cheers,
Raphael

benwaggoner

13th August 2020, 20:05

So yes NHW has some drawbacks, and there is a reason why the industry has chosen AVIF and JPEG XL as the new image compression standards.I think they have certainly evaluated the pros and the cons of the different solutions/codecs, and so made that choice, and I totally respect it of course because they are a lot more skilled than me to evaluate it.
There is also a HUGE advantage to technologies that get broadly implemented in HW decoders. The long term trend is absolutely towards using IDR frames of video codecs for still image encoding to maximize decode speed and reliability. JPEG in software is okay because it is very simple and fast to decode. But with more complex and efficient image coding, decoding complexity goes up and HW has an advantage. While an individual frame isn't such a big deal, but doing things like generating lots of thumbnails from JPEG can be quite slow even on fast computers today.[/QUOTE]

Just to finish, if I can advertise my skills, I think I have a good knowledge of wavelet coding, and if you would have such projects, I am very interested and could work on it with a freelance contract for example... Image/video compression is a passion for me (and also as I struggle hard with jobs here), and I would like to live of it now...
For an individual contributor, the real money is in better implementation of standards than in trying to create new standards or formats. Figuring out how to tune video encoders for better still images would be a valuable offer as a contractor. While the bitstream is the same, there's lots of stuff that an encoder does to optimize for moving images that isn't appropriate for still images. Once interframe coherancy is irrelevant, lots of different choices become optimal. For example, x264's --tune stillimage mode really:

- stillimage (psy tuning):
--aq-strength 1.2
--deblock -3:-3
--psy-rd 2.0:0.7
And even those didn't get much emperical testing

Given the huge increase in tools available in AV1, HEVC, and VVC, I'm sure optimal tunings would be correspondingly more complex. And improving content adaption is a huge deal. Coding a pure natural image photograph is very different from encoding a screen shot, which is different from an iamge that combines rendered text, graphics, and natural photography.

nhw_pulsar

13th August 2020, 20:47

There is also a HUGE advantage to technologies that get broadly implemented in HW decoders. The long term trend is absolutely towards using IDR frames of video codecs for still image encoding to maximize decode speed and reliability. JPEG in software is okay because it is very simple and fast to decode. But with more complex and efficient image coding, decoding complexity goes up and HW has an advantage. While an individual frame isn't such a big deal, but doing things like generating lots of thumbnails from JPEG can be quite slow even on fast computers today.

Yes, I agree with you and HW decoders have an advantage.But I still wanted to emphasize that NHW is extremely fast to encode/decode, and I even think that software NHW decoder will be very faster than hardware HEVC, AV1, VVC decoders.For example with the same level of (software) optimization, NHW is around 15x faster to decode than x265 (optimized HEVC)!

For an individual contributor, the real money is in better implementation of standards than in trying to create new standards or formats. Figuring out how to tune video encoders for better still images would be a valuable offer as a contractor. While the bitstream is the same, there's lots of stuff that an encoder does to optimize for moving images that isn't appropriate for still images.

Yes, it could be very interesting to tune video encoders for better still images, because I generally find that they lack of neatness, at least as a still image.And I have also developed processings that enhance neatness and that are not related to wavelet coding, and so transposable to any compression scheme.Yes neatness is very subjective, but really for me, despite NHW has far and far worse PSNR and SSIM scores than x265, AVIF, I still find that its results are visually more pleasant.So I do think that psychovisual tuning for still image is very important, and it would be great to work on it.
-For the little story, I did not intend to create a new standard, it's just I had very interesting course at university on wavelets in 2004-2005, and I absolutely did not have knowledge on DCT, and so naturally I orientated towards wavelets and played at home with them to try to see how far they can go...-

Many thanks again for your answer and your time Sir.
Cheers,
Raphael

foxyshadis

21st August 2020, 05:46

Many thanks for your answer.

Yes, I think there are new ideas/processings in the NHW Project that can give interesting "state-of-the-art" results, I don't think they are patended because I never saw them described in the Internet nor in the litterature, and so I am totally willing to give them to AOM patent-free.

The "big" problem is that these new ideas/processings are completely tailored for wavelet coding and wavelet decomposition, I don't think they are adaptable/transposable to DCT AV1 codebase for example... And so that's maybe why AOM always answered me that they were not interested in NHW?

Cheers,
Raphael

Unfortunately, before they're willing to consider the technical merits of your idea, you have to prove the legal merits, namely that it is not patented, that it's different enough from similar patents, or that you own a patent to the technology that you'll willing to sign over to AOMedia. "Haven't seen it before" isn't enough of a guarantee, because there are just way too many niche things in journals and patents out there.

AV1 does have a few pieces that really were designed specifically to benefit non-standard use cases, like still images and desktop streaming, so it's not entirely done for. But they won't take anything for AV2 that doesn't pass the patent minefield.

And yeah, you'll have to make some attempt at integrating the tool to prove it can help some use case, otherwise it's just another idea on the Mount Everest of ideas.

nhw_pulsar

21st August 2020, 08:37

Unfortunately, before they're willing to consider the technical merits of your idea, you have to prove the legal merits, namely that it is not patented, that it's different enough from similar patents, or that you own a patent to the technology that you'll willing to sign over to AOMedia. "Haven't seen it before" isn't enough of a guarantee, because there are just way too many niche things in journals and patents out there.

AV1 does have a few pieces that really were designed specifically to benefit non-standard use cases, like still images and desktop streaming, so it's not entirely done for. But they won't take anything for AV2 that doesn't pass the patent minefield.

Yes, you're right and I completely understand the very deep imperatives of AOM concerning patents.Just, for example, searching the whole US patents database website for prior art/patents will be quite of a hard task for me... and also I don't have the money to pay for a patent lawyer for that unfortunately... Do you think I can receive some help for that task? Also the thing that will be hard to defend is that most of the main ideas of NHW were done in 2007-2008, but from 2007 to 2012, NHW was close-source, it's just from 2012 that it was open-source, but really the main ideas are of 2007/2008.

>AV1 does have a few pieces that really were designed specifically to benefit non-standard use cases

That's great news, and it gives me a little hope now with AOM, thank you for letting me know, even if I know that it will be very difficult.But first how can I clear the patent concern?

And yeah, you'll have to make some attempt at integrating the tool to prove it can help some use case, otherwise it's just another idea on the Mount Everest of ideas.

Quite frankly, it will be very diffcult for me to integrate NHW or some of his tools in the AV1 code... For the tools, the main idea not related to wavelets that comes to mind, is to perform a pre-sharpening (with laplacian kernel, quite old technique) of the Y comp (at the very begining just after colorspace conversion) to enhance neatness of the results, but I don't know if it'll work with AV1, because I have read that DCT quantization naturally tends to sharpen image...

Cheers,
Raphael

nhw_pulsar

21st August 2020, 23:26

@foxyshadis (and to the other members),

I have read your post today that SVT-AV1 will become the AV1 "production" encoder because of its reasonable complexity, and you also wrote: "aomenc will continue as a research codec for AV2 development."

So AV2 will be based on aomenc and so I guess encoding time won't certainly be the problem.I have even read that a AOM founding member researcher said that for AV2, they are deeply devoted to really introduce ML/AI, for example for the good representation(/segmentation) of objects/shapes and better understand their motion and so further improve compression.

So from my understanding, AV2, based on aomenc, will be an experimental research codec that will further compress over AV1 and VVC and so will have exceptional PSNR and SSIM scores at the expense of a very "huge" encoder(/decoder) complexity/time.When I try to think about NHW in that picture, it seems contrary actually, because NHW strong point is extremely fast encoder/decoder with very good visual aspect but poor PSNR and SSIM scores.

So I start to have big doubts again that AOM could be interested in NHW for AV2, plus all the negative answers I had from AOM these last years, all this makes me very pessimistic again...

@foxyshadis, could you confirm what you said and do you really think AOM could be interested in NHW for few non-standard use cases like still image?

It would be great if you could give me your point of view for NHW and AOM codecs, even if it would be severe and negative (would still help me).

Cheers,
Raphael

LigH

25th August 2020, 14:46

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 10.2.0)

AOM v2.0.0-762-g7e235b0d9 (http://www.mediafire.com/file/sagnq98kntawgzr/aom_v2.0.0-762-g7e235b0d9.7z/file)

rav1e 0.3.0 (325ae51 / 2020-08-25) (http://www.mediafire.com/file/r7b7yrwz94ym9nk/rav1e_0.3.0_2020-08-25_325ae51.7z/file)

dav1d 0.7.1 (d0e50cac / 2020-08-25) (http://www.mediafire.com/file/jktbrkz8cts36iv/dav1d_0.7.1_2020-08-25_d0e50cac.7z/file)

LigH

26th August 2020, 07:10

avif-0.8.1 p20200818-10-g325ae515 (http://www.mediafire.com/file/4w4v9blzisya9kf/avif-0.8.1_p20200818-10-g325ae515.7z/file) (MSYS2/MinGW, GCC 10.2.0, current rust for rav1e library)

hajj_3

28th August 2020, 08:46

Chrome 85 can now view .AVIF files. Microsoft Edge 85 cannot view .AVIF files which is a little strange as they both use chromium, i guess microsoft decided not to adopt that functionality right away.

LigH

28th August 2020, 09:15

Vivaldi 3.3.2022.6 is based on Chrome/85.0.4183.84 and displays the Netflix samples (http://download.opencontent.netflix.com/?prefix=AV1/Chimera/AVIF/).

Firefox 80.0 does not.

birdie

29th August 2020, 00:22

Vivaldi 3.3.2022.6 is based on Chrome/85.0.4183.84 and displays the Netflix samples (http://download.opencontent.netflix.com/?prefix=AV1/Chimera/AVIF/).

Firefox 80.0 does not.

It does if you set image.avif.enabled to True.

foxyshadis

29th August 2020, 08:39

It does if you set image.avif.enabled to True.

Nice, flipping that right now! Looking at the bug history (particularly #1625363 (https://bugzilla.mozilla.org/show_bug.cgi?id=1625363)), it looks like turning it on by default was held up first because they wanted to switch to dav1d, and now because they're overhauling the entire media handling stack and it's sort of in limbo until that's done. At least there's an easy way to test it out, though.

LigH

31st August 2020, 07:53

:thanks:

You are right, birdie.

Yups

1st September 2020, 17:55

https://images.anandtech.com/doci/16060/20200901173558.jpg

Nvidia confirms AV1 hardware decoding on Ampere GPUs.

Stream and playback videos at 8K HDR using the new AV1 decoder on GeForce RTX 30 Series GPUs, which enables more efficient playback of 8K HDR YouTube videos. With much more efficient compression than H.265, AV1 dramatically lowers the internet bandwidth requirements you need to stream high resolution video.

Good news for AV1 in general having AV1 support from Intel and Nvidia in their next gen GPUs. Only AMD is missing, we have to wait for RNDA2 if it supports AV1 as well.

hajj_3

1st September 2020, 18:19

great news :)

benwaggoner

1st September 2020, 18:34

Good news for AV1 in general having AV1 support from Intel and Nvidia in their next gen GPUs. Only AMD is missing, we have to wait for RNDA2 if it supports AV1 as well.
This is a big deal!

AMD does typically lag NVidia for a year or more in video capabilities, so I wouldn't make any assumptions about their next gen before they announce something.

At this point, it's really Qualcomm and AMD needed. Although given the much slower replacement rate of PCs these days, it'll still be at least a decade before it'll be safe to assume all PCs would have HW AV1 decode. IIRC, it was around 2012 before it was quite rare to have a PC without HW H.264.

benwaggoner

2nd September 2020, 21:26

https://newsroom.intel.com/news-releases/11th-gen-tiger-lake-evo/

Intel has launched Tiger Lake CPUs.
Intel and NVidia down. AMD to go.

And everything supported 10-bit decode that I know of, so we may finally have a codec that can be 10-bit always (although SW decoders are still somewhat slower with 10-bit).

soresu

3rd September 2020, 01:58

At this point, it's really Qualcomm and AMD needed.

Didn't Samsung throw their hat in with AV1 awhile ago now?

They usually announce their next Exynos flagship SoC around the end of the year, so we might see some action with them too.

The COVID business slowdown seems to have impacted the production timeline of Rockchip RK3588 and perhaps the Amlogic S908X which also have AV1, but I think that there are at least weaker S905X4 chips in the wild with AV1 capabilities too.

I'm still holding out hope that the newly awaited "Sabrina" Android TV dongle from Google will use S905X4, despite early claims it uses the older S905X2.

hajj_3

3rd September 2020, 09:30

Didn't Samsung throw their hat in with AV1 awhile ago now?

They usually announce their next Exynos flagship SoC around the end of the year, so we might see some action with them too.

The COVID business slowdown seems to have impacted the production timeline of Rockchip RK3588 and perhaps the Amlogic S908X which also have AV1, but I think that there are at least weaker S905X4 chips in the wild with AV1 capabilities too.

I'm still holding out hope that the newly awaited "Sabrina" Android TV dongle from Google will use S905X4, despite early claims it uses the older S905X2.
Pretty sure it uses the S905Y2 which doesn't even have ethernet.

Blue_MiSfit

3rd September 2020, 19:55

Qualcomm really is the elephant in the room... without hardware decode on popular Android devices AV1 will be a tough sell for OTT service operators I think.

NikosD

5th September 2020, 17:09

An interesting slide from nVidia.

Using latest Chrome M85 and YouTube 8K HDR 60fps AV1 content, a Core i9 9900K managed to decode in SW only 28fps with a 85% CPU utilization whereas an Ampere AV1 HW decoder manages real-time performance of 60fps without bothering CPU at only 4% utilization.

The only thing missing is the HW decoder's utilization during the achievement.

https://i.postimg.cc/3NDXdz1K/NVIDIA-Ge-Force-RTX-30-Series-Deep-Dive-RTX-3080-RTX-3090-RTX-3070-Ampere-GA102-Ampere-GA104-GPU-Grap.png

Blue_MiSfit

7th September 2020, 09:39

No surprises there. 8kp60 AV1 decode is absolutely punishing, especially considering the mention of HDR which means 10 bit...

It's extremely impressive that the new RTX 30 series will handle it in hardware!

Yups

7th September 2020, 13:27

This is why a hardware decoder is so important for mobile devices with limited power, thermal headroom and fewer cores.

benwaggoner

7th September 2020, 19:04

This is why a hardware decoder is so important for mobile devices with limited power, thermal headroom and fewer cores.
And for premium content licensed with HW DRM requirements. AV1 would be useful for YouTube and Twitch way before premium services. Particularly as most premium playback devices already have HEVC, but YouTube and Twitch are mainly watched in browsers, which are mainly Chrome and Firefox, and only have H.264 as a baseline.

unlord

8th September 2020, 00:36

... but YouTube and Twitch are mainly watched in browsers, which are mainly Chrome and Firefox, and only have H.264 as a baseline.

Chrome and Firefox have had AV1 decode for nearly 2 years now, sheesh.

hbbs

8th September 2020, 00:53

https://www.phoronix.com/scan.php?page=news_item&px=AV2-Video-Codec-In-Research

Sent from my Moto Z3 Play using Tapatalk

benwaggoner

8th September 2020, 18:35

Chrome and Firefox have had AV1 decode for nearly 2 years now, sheesh.
Not with studio-grade DRM. And with SW decode and the performance/power challenges thereof.

GTPVHD

14th September 2020, 11:34

https://www.microsoft.com/en-us/download/details.aspx?id=101577

DirectX Video Acceleration Specification for AV1 Video Coding.

nhw_pulsar

15th September 2020, 13:37

Hello,

Just a very quick message to let you know that I finally could have an answer from a AOMedia founding member company, and I thank them very much for their time, and so no surprise, they confirmed me that NHW is not of consideration/interest for AOMedia.NHW could have been a tool for AV1/AV2, but the tools quality is evaluated with PSNR and SSIM curves, and NHW has very too bad PSNR and SSIM results -but again despite this, I still find that it is visually more pleasant because it has more neatness...-.

So NHW will definitely stay a hobby (will have to slow down my work on it in the next months), but if you found time to take a look at NHW and if you would have advice/suggestion about it, do not hesitate to post it on the NHW thread, or send me an email.

Cheers,
Raphael

hajj_3

15th September 2020, 20:42

AMD RX 6000 gpu's will have AV1 hardware decoding support :) - https://www.phoronix.com/scan.php?page=news_item&px=AV1-Decode-For-AMD-VCN-3.0

Mr_Khyron

16th September 2020, 13:24

https://github.com/xiph/rav1e/releases/tag/v0.4.0-alpha
- This is a new big release of rav1e after 7 months making the encoder sensibly faster and better.

Yups

16th September 2020, 15:43

AV1-decoding with RTX 3080 compared to GTX 1080 and RTX 2070: https://youtu.be/lTRbLnWdqwk

NikosD

16th September 2020, 16:28

How smart to compare HW decoding of AV1 using 3080 to CPU AV1 decoding using 1080 and 2070 Super which the video subtitles say it's a 2080 card.
And HW AV1 decoding is not using NVENC that this incompetent guy thinks.
It's using NVDEC.
The NVENC part (HW encoding) of Ampere cards is identical to Turing cards.
The only thing useful of this generally useless clip is that YouTube's AV1 8K60fps clips utilize about 47% to 54% of AV1 HW decoder of Ampere card which I think is impressive and a metric for AV1 HW decoder of Tigerlake Xe GPU and AMD RX 6000 series to beat.

foxyshadis

20th September 2020, 11:21

NikosD

20th September 2020, 14:19

Benchmark seems legit even if they don't know the lingo. Damn, the 3080 is one hot, power-hungry card. Hopefully it'll be optimized in drivers eventually. No need to buy 3080, I'm sure they are going to release 3060 and possibly 3050 card.
And there is also Xe from Intel.
Personally, I'm going to wait for a budget RDNA2 card hoping for at least 4K 10bit AV1 acceleration or even better (like 8K60fps)

excellentswordfight

22nd September 2020, 08:43

Benchmark seems legit even if they don't know the lingo. Damn, the 3080 is one hot, power-hungry card. Hopefully it'll be optimized in drivers eventually.
I'm a bit curious to what you are referring to?

From what I've seen, yes the power draw is high under load, but efficiency is rather good for an top of the line card, although its not that impressive for an die shrink generation, and both stock cooler and third party seems to keep it under 80 degrees at rather low noise levels.

https://tpucdn.com/review/asus-geforce-rtx-3080-tuf-gaming-oc/images/performance-per-watt_3840-2160.png

No need to buy 3080, I'm sure they are going to release 3060 and possibly 3050 card.
And there is also Xe from Intel.
Personally, I'm going to wait for a budget RDNA2 card hoping for at least 4K 10bit AV1 acceleration or even better (like 8K60fps)
It's a bit of a shame that CUDA for GPGPU and Nvenc is so superior (at least at an software support level), havnt been able to consider an AMD card for years.

NikosD

22nd September 2020, 09:20

It's a bit of a shame that CUDA for GPGPU and Nvenc is so superior (at least at an software support level), havnt been able to consider an AMD card for years. nVidia managed to sabotage OpenCL leveraging nVidia's Vice President who is also the President of Khronos group, which is in charge of OpenCL.
He literally butchered the latest version of OpenCL in order to make CUDA the single greatest GPGPU API.
But all these are just malpractice and market manipulation very well known to be handled by the leather-jacket-man.
Regarding HW encoding SW, I could easily say that VCEEnc app for AMD cards is on par with NVEnc and QSVEnc for nVidia and Intel.
But I was referring to AV1 HW decoding here, which all of the modern GPUs support.
And Ampere's HW encoding is exactly the same like Turing.
They didn't change it.

birdie

24th September 2020, 12:11

NUC's are great except they are extremely overpriced. Quite often you can buy a laptop with the same configuration a lot cheaper than the NUC.

Blue_MiSfit

24th September 2020, 19:29

excellentswordfight

24th September 2020, 19:56

True. Still, NUCs are pretty well made, and offer 100% Intel hardware and drivers. Depending on the application this can be very preferable to a laptop. The integrated display, keyboard, mouse, and battery of a laptop can also be preferable in certain cases ;)
Not only that, cheap laptops does not come with great io like this (especially Thunderbolt), and the sku:s with the higher end igpu.

Tbh were i live nuc have always offered rather good value tbh, i got a kaby lake one on release, I dont even think there were any laptops with hdmi 2.0 port at that point, which was pretty much a must for that machine.

butterw2

24th September 2020, 20:30

Nuc is a nice concept, but ultimately a failed one, because they didn't push it hard enough. I'm surprised they even continue making these. The volumes are low and Intel isn't a motherboard/bios manufacturer...

Yups

30th September 2020, 16:42

On windows there is no AV1 decoding support in the driver at the moment, the first public driver 27.20.100.8778 don't support it.

Mr_Khyron

30th September 2020, 19:56

Twitch has a 120fps/1440p 8mb/s av1 vod on this channel
https://www.twitch.tv/videos/637388605

hajj_3

30th September 2020, 20:48

Amlogic S905X4 android tv 10 boxes available October 30th. (which can hardware decode AV1): https://www.mecoolonline.com/collections/all/km6#MainContent

hajj_3

3rd October 2020, 16:22

https://blog.cloudflare.com/generate-avif-images-with-image-resizing/

Adonisds

3rd October 2020, 16:41

What's the die size of an AV1 hardware decoder?

Yups

4th October 2020, 00:24

https://www.pcworld.com/article/3576298/tested-av1-performance-in-11th-gen-tiger-lake-vs-10th-gen-ice-lake-and-comet-lake-ryzen-4000.html

https://images.idgesg.net/images/article/2020/09/core_i7_1185g7-100859833-orig.jpg

AV1 hardware decoding works fine, not sure why Computerbase couldn't get it to work.

https://www.computerbase.de/2020-09/intel-tiger-lake-test/2/#abschnitt_av1beschleunigung

They might have used the launch review driver which is older than the public driver but supports AV1 for some reason. Or it could have been a specific Google Chrome/VLC issue, PC World didn't use Chrome/VLC. But of course may be Computerbase did something wrong, not sure.

hajj_3

7th October 2020, 21:03

GIMP 2.10.22 can now import and export .AVIF files.

benwaggoner

8th October 2020, 01:00

What's the die size of an AV1 hardware decoder?
I've not seen any hard numbers, but from what I've heard from insiders, it's relatively quite large. Bigger than estimates for VVC's decoders, and quite a bit bigger than HEVC and likely EVC.

This is a probable driver for why HW AV1 decode has been slow coming for mobile devices. Until it's in the Qualcomm 400 series SoC, it won't be on track for becoming universal.

Hopefully someone here has more specifics.

LigH

8th October 2020, 07:44

May the patent-free algorithms be more complex in machine code form?

GTPVHD

10th October 2020, 09:00

https://techcommunity.microsoft.com/t5/media-at-microsoft/av1-hardware-accelerated-video-on-windows-10/ba-p/1765451

soresu

14th October 2020, 21:18

Amlogic S905X4 android tv 10 boxes available October 30th. (which can hardware decode AV1): https://www.mecoolonline.com/collections/all/km6#MainContent

Noice.

I had hopes that Chromecast 4 would use that chip but alas it only has the S905D3.

With luck the next Fire TV Stick 4K model will use a similar chip to the S905X4.

Gravitator

17th October 2020, 14:37

Are there any AOM developers here? It's like talking to a wall...

Dark Eiri

19th October 2020, 05:12

There seems to be an increase in AV1 availability on Youtube these last days... where until yesterday I rarely bumped into an AV1 enabled video, today I found a lot by simply watching the channels I usually watch. Maybe it's replacing VP9 sooner than we thought?

NikosD

19th October 2020, 05:45

Probably due to the increased availability of hardware decoders.

I expect Netflix to follow the trend of AV1 stream availability due to the quality per bandwidth gain.

Blue_MiSfit

19th October 2020, 18:09

YouTube's AV1 encodes are even worse than their VP9 encodes when it comes to grain, unfortunately... :(

benwaggoner

19th October 2020, 18:15

Probably due to the increased availability of hardware decoders.

I expect Netflix to follow the trend of AV1 stream availability due to the quality per bandwidth gain.
Unlike YouTube, Netflix has premium content, much or all of which has DRM requirements. AV1's gains versus HEVC aren't that big at best, so it's the gains versus H.264 that's the real game changer, and the only material platforms that have AV1 but can't use HEVC are Chrome and Firefox (pretty much all current Android phones have HW HEVC decode, just not from Chrome). Premium content also has a smaller usage share of browsers versus apps/TVs/streaming media device.

YouTube also has much lower quality expectations than premium content, so they can get away with consistently suboptimal encoding. One people are paying for a service or content, their expectations go way higher. The general expectation is to not have any distracting artifacts. When someone is paying extra to subscribe to or buy UHD or HDR content, expectations go even higher.

YouTube being free can cut a whole lot of corners. Pretty much all video game footage on YouTube has painful artifacts, for example. Encoding AV1 at high-quality while at low enough bitrates to justify adding another encoding target is slow. If one's willing to spend that amount of time to make AV1 look good, one could also do x264 --preset placebo and x265 --preset veryslow.

One of the biggest AV1 features that was supposed to save bits versus H.264 and HEVC was its film grain modeling. But that only works for moderate degrees of grain. With the really heavy

So, YouTube is pretty much the ideal AV1 platform for the moment, as it targets lower quality SW decode without DRM. It's utility for premium content is a lot lower for the moment due to lack of HW DRM, broader availability of HEVC, and high quality bar.

Obviously trends are going in the right direction, as all the major CPU companies have announced AV1 HW decode support and AV1 quality-at-perf-at-bitrate has improved enormously in the last 12 months. But we're still several years away from having even 50% of PCs having HW AV1 support.

A ROI justification for AV1 would be very hard to make right now. I imagine YouTube is spending far more to encode and store AV1 than they are saving in bandwidth at this point; it's not like they can stop encoding and storing the H.264 streams anytime soon.

dapperdan

19th October 2020, 18:51

I've not investigated it myself yet, but I did see someone complaining recently that new Youtube videos were VP9 and AV1 only, not H.264

Dont know if that's related to Apple rolling out VP9. Or if its possibly just a change in which one gets encoded first. But we must be pretty close to Youtube not having to bother with H.264 anymore.

They claim to no longer support IE11 and push people towards chrome. The fraction of people who can't view VP9 must be pretty small and shrinking.

NikosD

19th October 2020, 19:49

YouTube also has much lower quality expectations than premium content, so they can get away with consistently suboptimal encoding. One people are paying for a service or content, their expectations go way higher. The general expectation is to not have any distracting artifacts. When someone is paying extra to subscribe to or buy UHD or HDR content, expectations go even higher.

YouTube being free can cut a whole lot of corners. Pretty much all video game footage on YouTube has painful artifacts, for example. Being a customer of Netflix's 4K/HDR most expensive and premium subscription for the last few years, I have never seen such disturbing and distracting artifacts from Netflix like this period of time.

Netflix provides 4K at very low bitrates using new techniques like shot based encodings which are the worst thing I have ever seen on my 4K TV despite what they say here:
https://netflixtechblog.com/optimized-shot-based-encodes-for-4k-now-streaming-47b516b10bbb

I mean YouTube is many times better in encoding quality than these new "optimized" techniques.

It's a nightmare and a legacy of Spring-Summer COVID bandwidth restrictions that they decided to fight using these failed new encodings in order to keep bandwidth low, especially in 4K content.

As you work in the industry, is it possible to shake briefly their heads in order to open their eyes and see the mess they have caused ?

I wonder when this nightmare of limited bandwidth will be over, hopefully before the unlimited COVID lockdowns.

benwaggoner

20th October 2020, 18:37

Being a customer of Netflix's 4K/HDR most expensive and premium subscription for the last few years, I have never seen such disturbing and distracting artifacts from Netflix like this period of time.

Netflix provides 4K at very low bitrates using new techniques like shot based encodings which are the worst thing I have ever seen on my 4K TV despite what they say here:
https://netflixtechblog.com/optimized-shot-based-encodes-for-4k-now-streaming-47b516b10bbb

I mean YouTube is many times better in encoding quality than these new "optimized" techniques.
You need to watch some more YouTube. I see some pretty egregious stuff there. Although their 4K VP9 encodes seem to have improved in quality somewhat recently.

It's a nightmare and a legacy of Spring-Summer COVID bandwidth restrictions that they decided to fight using these failed new encodings in order to keep bandwidth low, especially in 4K content.
The COVID spike lead to increased concern about bandwidth utilization across the streaming industry. IIRC, some European government(s) stated concern that streaming was going to use up all the bandwidth.

As you work in the industry, is it possible to shake briefly their heads in order to open their eyes and see the mess they have caused ?
I actually helped design the original Silverlight + VC-1 adaptive streaming encodes with Netflix that they originally launched. But I don't know that they'll take my opinion more seriously than customers' (or VMAF's) at this point.

I wonder when this nightmare of limited bandwidth will be over, hopefully before the unlimited COVID lockdowns.
My unlimited bandwidth from Comcast ended a few months ago. I don't know that we'll ever stop worrying about bandwidth. People still want to watch HDR on tablets in subways :sly:.

The current codec wars are a challenge, as many aren't adopting HEVC (which is broadly available outside of Chrome/Firefox) in favor of using H.264 now and hoping for AV1. HEVC can lower bandwidth by around 40% versus H.264 at similar quality with today's encoders. HEVC would be the best way to drop aggregate bandwidth/increase top bitrate quality in 2020-2021 while people wait for HW AV1 decoders to become common.

benwaggoner

20th October 2020, 18:40

I note that the RDNA 2 GPU that the Xbox Series S/X and the PlayStation 5 have customized versions of include AV1 HW decoders. Those might be the first high-volume AV1 HW decoder devices to the market. Game consoles get used a lot for premium content streaming.

NikosD

20th October 2020, 19:40

The current codec wars are a challenge, as many aren't adopting HEVC (which is broadly available outside of Chrome/Firefox) in favor of using H.264 now and hoping for AV1. HEVC can lower bandwidth by around 40% versus H.264 at similar quality with today's encoders. HEVC would be the best way to drop aggregate bandwidth/increase top bitrate quality in 2020-2021 while people wait for HW AV1 decoders to become common. Talking about Netflix, it uses HEVC 10bit for 4K/HDR streams with highest HW DRM possible and the system doesn't offer any other codec for such content .

So, Netflix is already on the boat of HEVC 10bit since the beginning of 4K in 2014.

The artifacts I'm talking about have nothing to do with low bandwidth or codec of 4K content, but with the change in encoding type as Netflix mentioned in its article.

As I said before, the problem is not low bandwidth by itself but the way Netflix is trying to handle it using the "optimized" techniques of 4K re-encoding during the last few months.

Blue_MiSfit

20th October 2020, 20:11

Where did you see that the PS5 / XBS have hardware AV1 decoding? I wasn't aware of this!

hbbs

20th October 2020, 20:16

@benwaggoner please. I'd love to know that myself.

Sent from my Moto Z3 Play using Tapatalk

unlord

21st October 2020, 04:25

Are there any AOM developers here? It's like talking to a wall...

AOM developer here. There is also a healthy community of AV1 developers, users and codec enthusiasts on IRC. I recommend #daala and #dav1d on irc.freenode.org if you still have questions.

Unfortunately, I don't recognize many of the names on doom9 from the AV1 process, but please speak up if I'm mistaken.

benwaggoner

21st October 2020, 19:19

Where did you see that the PS5 / XBS have hardware AV1 decoding? I wasn't aware of this!
They use a customized RDNA 2 GPU, which has been announced (https://optocrypto.com/amd-big-navi-rdna-2-will-have-support-for-av1-video-decoding/#:~:text=AMD%20Big%20Navi%2C%20RDNA%202%20will%20have%20support,support%20AV1%20decoding%20in%20the%20new%20Radeon%20series.) as having AV1 decode support.

I suppose it's possible one or both cut AV1 as a cost savings measure, but I can't imagine it's a material addition to a GPU of that complexity. It's more in the mobile SoC space where transistors and power are a such a high premium that adding AV1 could be a material cost hit.

I guess I better get on a preorder for both and try them out.

benwaggoner

21st October 2020, 19:27

AOM developer here. There is also a healthy community of AV1 developers, users and codec enthusiasts on IRC. I recommend #daala and #dav1d on irc.freenode.org if you still have questions.

Unfortunately, I don't recognize many of the names on doom9 from the AV1 process, but please speak up if I'm mistaken.
Doom9 is more user than developer centric, so that's not surprising.

Cross-pollination between the communities is always a really good idea. Any decent encoder development needs a lot of experienced eyes for subjective quality evaluation and tuning. There's been a historical bias towards objective metric tuning in the VPx and then AV1 development (PSNR first, now VMAF) which misses lots of psychovisual tuning opportunities. And VMAF is just not a sufficiently sensitive instrument to compare different adaptive quantization approaches.

That's more an issue with the training set used for VMAF's machine learning, which was limited to x264 without much variation in AQ modes or strengths. Especially because AV1 itself and libaom were both tuned using VMAF, we'd really need a new set of subjective ratings of real-world AV1 encodes using a variety of different psychovisual tunings. That ground truth data would then make for a much better-trained VMAF for AV1 evaluation.

As it is, the VMAF tuning baked in during AV1 and libaom development results in AV1 yielding VMAF scores that overestimate its subjective quality ratings versus, say x265 HEVC. That bias will go away if VMAF is retrained on subjective ratings of actual AV1 output.

benwaggoner

22nd October 2020, 19:30

https://forums.anandtech.com/threads/intel-to-develop-discrete-gpus.2526376/page-29#post-40323361
That's the 2nd gen of Intel's discreet GPUs for 2021-2022 launch?

Greenhorn

22nd October 2020, 20:01

That's the 2nd gen of Intel's discreet GPUs for 2021-2022 launch?

First, not second. Speculation leans towards mid-2021, but that just seems to be people spitballing a Computex launch.

(DG2 = Xe-HPG/high-power Gen12 discrete; DG1 = Xe-LP/low-power Gen12 discrete)

hajj_3

23rd October 2020, 08:35

That's the 2nd gen of Intel's discreet GPUs for 2021-2022 launch?

https://www.anandtech.com/show/16190/intel-dg1-gpu-now-shipping-xehpg-dg2-gpu-in-labs

hajj_3

24th October 2020, 08:45

Paint.NET now has full read/write .avif capability: https://blog.getpaint.net/2020/10/23/paint-net-4-2-14-is-now-available/

NikosD

25th October 2020, 11:38

For the owners of Ampere cards (haha it was a joke) there is a new version of NVEnc excellent transcoder by rigaya (the developer) who added AV1 HW decode in his app.

Obviously, you can't use the app for playback but only to transcode in HW even an AV1 clip.

Give it a try, you two unique owners of Ampere cards:

https://github.com/rigaya/NVEnc/issues/273

hajj_3

29th October 2020, 17:42

AMD's RX6000 gpu's can decode AV1, presumably fully hardware decode rather than hybrid decode: https://www.amd.com/en/products/graphics/amd-radeon-rx-6800-xt

Blue_MiSfit

29th October 2020, 18:46

VincAlastor

30th October 2020, 01:00

Very exciting to see 4kp60 4:2:0 10 bit AV1 hardware encoding in the next gen Intel 11th Gen!

https://www.anandtech.com/show/16205/intels-11th-gen-core-rocket-lake-detailed-ice-lake-core-with-xe-graphics

I wonder if their encoder implementation is any good

looks like there was a mistake (?!) by Intel

https://www.reddit.com/r/intel/comments/jkapv5/fresh_new_confirmed_details_on_intels_11th_gen/gahs822/

Decoders:
1x 4k60 8b 4:2:0 AVC

4K60 12b 4:2:2/4:4:4 HEVC/VP9/SCC

4K60 10b 4:2:0 AV1

Encoders

4K60 8b 4:2:0 AVC

4K60 10b 4:4:4 HEVC/SCC/VP9, RA

benwaggoner

30th October 2020, 01:57

Blue_MiSfit

30th October 2020, 07:39

Aw geez Intel! Yeah, I was pretty shocked to see this in the first place. Too bad it was a typo :)

benwaggoner

30th October 2020, 21:20

As Ice Lake is now shipping and we're getting some results from it, I've started a new Sticky to cover hardware AV1 decoding. As usage ramps up, having a single AV1 thread won't be practical before long.

https://forum.doom9.org/showthread.php?t=182011

soresu

30th October 2020, 21:37

They use a customized RDNA 2 GPU, which has been announced (https://optocrypto.com/amd-big-navi-rdna-2-will-have-support-for-av1-video-decoding/#:~:text=AMD%20Big%20Navi%2C%20RDNA%202%20will%20have%20support,support%20AV1%20decoding%20in%20the%20new%20Radeon%20series.) as having AV1 decode support.

This slide would seem to refute that assumption:

https://pics.computerbase.de/9/4/4/1/1/9-1080.62f89bc5.jpg

The GPU shader/CU microarchitecture and the VCN encoder/decoder architecture are not fused to each other from what I can gather about it, especially as it has been said that the design of at least one console SoC was already set in stone 2 years ago when AV1 had only just become standardised.

Having said that both consoles do have an 8 core CPU that could easily handle 4K24p for 8 bit content using dav1d.

Sadly davi1d still has not so much as a lick of 10/12/16 bit SIMD assembly for AVX2 or SSSE3.

My Zen1 based R7 1700 can barely manage some 10 bit 4K24p clips without skipping frames, but the Zen2 based CPU in the new consoles should fair a bit better, though I doubt it could even come close to managing 4K60p unless either Sony or Microsoft has made their own decoder with optimised 10 bit SIMD assembly (which itself is not a great stretch of imagination considering their massive resources).

soresu

30th October 2020, 22:23

soresu

1st November 2020, 03:40

https://newsroom.intel.com/news/iris-xe-max-discrete-graphics-deep-link/

AV1 isn't mentioned in that announcement at all?

Yups

1st November 2020, 13:43

My understanding is that none of the new gen GPUs have HW AV1 encoding. Given its complexity, it may be pretty hard to get meaningful compression efficiency gains out of the mm^2 a GPU vendor is willing to devote to encode. The quality@perf math can be very different for a GPU.

I have to add that according to Notebookcheck (https://www.notebookcheck.net/Intel-Tiger-Lake-H-Alder-Lake-P-and-Alder-Lake-S-detailed-Alder-Lake-to-offer-up-to-8C-16T-configs-with-Xe-LP-DDR5-4400-RAM-Wi-Fi-6E-and-PCIe-Gen5-support.496197.0.html) Alder Lake will support AV1 accelerated encode and as we know it's still based on Xe LP. On a further note in the Intel graphics driver since a month there is a file called "Intel Hybrid AV1 Encoder MFT".

As Ice Lake is now shipping and we're getting some results from it, I've started a new Sticky to cover hardware AV1 decoding. As usage ramps up, having a single AV1 thread won't be practical before long.

https://forum.doom9.org/showthread.php?t=182011

You made a mistake there. Icelake doesn't support AV1, it's Tigerlake.

VincAlastor

10th November 2020, 00:28

Amlogic S905X4 Android TV & RDK developer kit ships with ATSC, DVB, or ISDB tuners
Video Decoding

AV1 MP-10 L5.1 up to 4Kx2K @ 60fps

https://www.cnx-software.com/2020/11/05/amlogic-s905x4-android-tv-rdk-developer-kit-ships-with-atsc-dvb-or-isdb-tuners/

LigH

17th November 2020, 09:24

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 10.2.0)

AOM v2.0.0-1023-gd198b8e9f (https://www.mediafire.com/file/rz84pbopamz56ef/aom_v2.0.0-1023-gd198b8e9f.7z/file)

rav1e 0.4.0-alpha (9569901a / 2020-11-16) (https://www.mediafire.com/file/dgd28bpkd5l51eo/rav1e_0.4.0-alpha_2020-11-16_9569901a.7z/file)

dav1d 0.7.1 (ffd052b / 2020-11-16) (https://www.mediafire.com/file/tso76qebiie9eze/dav1d_0.7.1_2020-11-16_ffd052b.7z/file)

avif 0.8.3-bf58fe7 (https://www.mediafire.com/file/od25do5r1mnff0q/avif-0.8.3_bf58fe7.7z/file)
dav1d [dec]:0.7.1, aom [enc/dec]:2.0.0-1020-geda52bb92, rav1e [enc]:0.4.0-alpha (p20201110-4-g9569901a)

benwaggoner

17th November 2020, 22:26

Anyone get a Xbox Series X|S or PS5 and had a chance to try to play back any AV1 content yet?

I would try it in a .mp4 container as it is less likely Sony/Microsoft added demuxing for others.

LigH

17th November 2020, 23:11

I may ask among the Twitch gamers I know (but doubt they know the AV1 video codec at all)...

soresu

25th November 2020, 23:16

Anyone get a Xbox Series X|S or PS5 and had a chance to try to play back any AV1 content yet?

I would try it in a .mp4 container as it is less likely Sony/Microsoft added demuxing for others.

It seems I was wrong and there indeed is an AV1 decoder for all XB1+ models in the works, mostly using the GPU for maximum CPU offload (you know, cos Jaguar is so great and all).

Link here (https://aomedia.googlesource.com/av1-xbox-one/)to the repo on googlesource.

soresu

25th November 2020, 23:19

The Xbox decoder seems rooted to UWP and HLSL, but I imagine it could probably be reworked to use GLSL and a more cross platform software architecture than UWP.

soresu

25th November 2020, 23:39

Ah, someone on the AV1 discord got the me the Xbox decoder PDF through the git clone SW - good thing as I'm useless with that stuff.

Link here (https://drive.google.com/file/d/1fPYK0yewbWeCxm1HfbxRyoGOFcvKtLXm/view?usp=sharing).

hajj_3

2nd December 2020, 17:02

benwaggoner

3rd December 2020, 02:00

Qualcomm announced their new snapdragon 888 today, it is the new name for the snapdragon 875. Unfortunately it doesn't support hardware decoding of AV1 :(
https://www.anandtech.com/show/16271/qualcomm-snapdragon-888-deep-dive/4
https://www.qualcomm.com/news/releases/2020/12/02/qualcomm-redefines-premium-flagship-snapdragon-888-5g-mobile-platform
This was a surprise to me, as I had thought Google was requiring HW AV1 decode in this time frame.

Given Qualcomm's market share, this is really going to limit the utility of AV1 in mobile until 2022 at the earliest. Especially for premium content with HW DRM requirements.

And it was really at the low bitrates used in mobile where AV1's potential efficiency improvements were the most promising and relevant.

For 2021, I have a hard time seeing all that much value in doing AV1 other than for targeting Firefox or Chrome, which artificially block the use of HEVC HW decoders available to the underlying system. The Chromium/WebKit derived Edge and Safari can play HEVC content just fine. Switching from H.264 to AV1 clearly can offer big efficiency/quality improvements. But is adding a whole new codec any easier than asking users to use the default browser or a native Windows/Mac app? It's not like H.264 can be deprecated yet.

For everywhere but browsers, HEVC support is pretty universal, and I've yet to see compelling demonstrations of big-enough to bother improvements going from HEVC-to-AV1. HEVC can look pretty darn good given as much encoding time as AV1.

Film grain removal/parameterization/synthesis is a very promising feature for some classes of content, but there isn't production-grade robust tooling available to even really estimate the value of it, let alone use it by default in high-volume content publishing.

If AV1 misses 2021, 2022+ is quite likely will have competition from VVC and EVC.

birdie

3rd December 2020, 08:55

This was a surprise to me, as I had thought Google was requiring HW AV1 decode in this time frame.

888 will able to decode 4K 8bit 30fps AV1 in software just fine though battery life will be hugely affected.

Qualcomm often adds new codecs in their lower tier SoCs, so I guess 7XX/6XX/5XX/4XX/whatever SoC which they will release next year will support HW AV1 decoding.

hajj_3

3rd December 2020, 10:26

Qualcomm often adds new codecs in their lower tier SoCs, so I guess 7XX/6XX/5XX/4XX/whatever SoC which they will release next year will support HW AV1 decoding.

They might never support av1, they might be trying to force EVC to get some marketshare.

Blue_MiSfit

3rd December 2020, 11:31

Echoing what both Ben and I have said several times on this forum - hardware DRM requires hardware decode, and is mandatory for premium content. That's a big deal.

hbbs

3rd December 2020, 11:38

I think you're onto to something. Because dragging its feet like they clearly did this time. Not only they are creating an opportunity to position EVC against AV1. But also as a "reasonable alternative" to VVC when time comes.

Let's see if Google will play hardball with them. What I'm about to post is from last April.

https://www.axios.com/scoop-google-readies-its-own-chip-for-future-pixels-chromebooks-e5f8479e-4a38-485c-a264-9ef9cf68908c.html

Sent from my Moto Z3 Play using Tapatalk

soresu

3rd December 2020, 12:01

For 2021, I have a hard time seeing all that much value in doing AV1 other than for targeting Firefox or Chrome, which artificially block the use of HEVC HW decoders available to the underlying system. The Chromium/WebKit derived Edge and Safari can play HEVC content just fine. Switching from H.264 to AV1 clearly can offer big efficiency/quality improvements. But is adding a whole new codec any easier than asking users to use the default browser or a native Windows/Mac app? It's not like H.264 can be deprecated yet.

For everywhere but browsers, HEVC support is pretty universal, and I've yet to see compelling demonstrations of big-enough to bother improvements going from HEVC-to-AV1. HEVC can look pretty darn good given as much encoding time as AV1.

If AV1 misses 2021, 2022+ is quite likely will have competition from VVC and EVC.

A lack of prevalent VP9 HW support didn't stop Google from pushing it for Youtube, and I doubt it will be any different for AV1.

Especially when there is already far better SW decoding for AV1 than VP9 had at the equivalent time from release, coupled with far more performant mobile CPU cores to decode it with - Apple aside the best ARM core at the time was A57 at around 2 Ghz, now we have X1 at around 2.84 Ghz which has to be more than 3x faster at least.

I imagine that Qualcomm didn't want to support VP9 either to begin with, but it eventually ended up in there as will AV1 in good time - whether that actually happens before AV2 is released is a different story.

It's also worth noting that for all Qualcomm's market dominance elsewhere, China and India's market will probably be populated with many handsets that use Mediatek SoC's that do support AV1 - and their combined populations/potential market are not something to sniff at for sure.

foxyshadis

3rd December 2020, 12:40

I've moved dav1d-specific posts to dav1d accelerated AV1 decoder (https://forum.doom9.org/showthread.php?t=182128), beginning from a bit over a year ago. There's still plenty of room for a general decoders comparison thread, and of course an encoders face-off thread.

benwaggoner

3rd December 2020, 23:52

A lack of prevalent VP9 HW support didn't stop Google from pushing it for Youtube, and I doubt it will be any different for AV1.

Especially when there is already far better SW decoding for AV1 than VP9 had at the equivalent time from release, coupled with far more performant mobile CPU cores to decode it with - Apple aside the best ARM core at the time was A57 at around 2 Ghz, now we have X1 at around 2.84 Ghz which has to be more than 3x faster at least.
Yeah, in many ways AV1 is already more mature than any VPx implementation ever got to. There certainly are a lot more encoder vendors competing on making better looking and faster encoders, which is a huge deal.

SW DRM is simply not allowed for lots of premium content, however. AV1 is a lot more practical for user-generated and other non-commercial content than for professional licensed content.

Also, the reduced battery life of using a SW decoder matters a lot more when watching a two hour movie than short-form content.

I imagine that Qualcomm didn't want to support VP9 either to begin with, but it eventually ended up in there as will AV1 in good time - whether that actually happens before AV2 is released is a different story.
AV2 is in pretty early stages. EVC and VVC are the next two standardized codecs that HW vendors are going to be deciding whether to put in.

It's also worth noting that for all Qualcomm's market dominance elsewhere, China and India's market will probably be populated with many handsets that use Mediatek SoC's that do support AV1 - and their combined populations/potential market are not something to sniff at for sure.
Yeah, another divide between "Hollywood" content that is globally licensed and more regional content where DRM rules can be much more relaxed. A lot of those markets use ASOP not Google Android, and so might not include all the software decoders like AV1.

As a content creator, if one is choosing one codec beyond H.264, HEVC certainly offers a much bigger audience for 2021 except for Firefox and Chrome.

el Filou

4th December 2020, 15:10

Firefox or Chrome, which artificially block the use of HEVC HW decoders available to the underlying system.Oh wow, I had no idea about that. So is that the actual reason why UHD isn't available on Chrome & Firefox for those streaming services that offer it? I always assumed it was because of stronger DRM in Edge.

ksec

4th December 2020, 20:09

A lack of prevalent VP9 HW support didn't stop Google from pushing it for Youtube, and I doubt it will be any different for AV1.

It's also worth noting that for all Qualcomm's market dominance elsewhere, China and India's market will probably be populated with many handsets that use Mediatek SoC's that do support AV1 - and their combined populations/potential market are not something to sniff at for sure.

VP9 has had hardware support from nearly Day 1 through many different IP vendors along with HEVC as VP9 and HEVC are similar. And it was relatively simple and doesn't cost much in extra die space when HEVC was "the" requirement ( at least at the time ).

All the current hardware decoder including those in Laptops have a much higher power usage allowance, i.e You could have a hardware decoder working in 1+W range without problem. Compare to a mobile phone where it is expected to operate in few hundred mW range. This time around it isn't so simple because VVC has barely finished and on the surface doesn't seems to share that much with AV1. How this translate to hardware decoding block differences remains to be seen, especially when the power requirement is much more stringent. I have previously written this will change with 5nm SoC as both transistor budget and power usage improves, I was referring to TSMC's 5nm, the Sanpdragon 888 based on Samsung 5nm, which has a lower transistor density so it isn't quite there yet.

Finally Mediatek only has one chip that has AV1 decoder. And that is their High End flagship. 90% of Mediatek volume are low to mid range SoC. And transistor budget are even tightener in those segment.

I just wish people are more mindful of different interest in video codec, from hardware to software and from users to producers.

benwaggoner

5th December 2020, 01:15

Oh wow, I had no idea about that. So is that the actual reason why UHD isn't available on Chrome & Firefox for those streaming services that offer it? I always assumed it was because of stronger DRM in Edge.
Nope, HEVC decode actually did work by default in both browsers before it was explicitly blocked. Which was done for political, not technical reasons.

This is partly a reflection of the strong focus on user-generated content to Google (YouTube) and Facebook.

Among other things, this is why there's no browser-based HDR premium content. While AV1 technically can do HDR, no one has released an encoder with mature HDR tuning. x265 needed quite a lot of feature development to get optimal HDR encoding, since PQ and 709 have some pretty foundational differences and different optimization requirements.

The net effect is we'll probably see premium content playback on Windows/Mac continue to shift away from browsers towards apps. The large majority of PC and Mac systems can decode 10-bit HEVC in HW.

rubait

18th December 2020, 06:07

Any idea if DXVA Checker supports AV1 decode yet. I tried opening some files with it but doesn't seem to recognize it.

hajj_3

18th December 2020, 12:06

Any idea if DXVA Checker supports AV1 decode yet.

It does: https://bluesky-soft.com/en/DXVAChecker.html

rubait

18th December 2020, 18:13

It does: https://bluesky-soft.com/en/DXVAChecker.html

I tried it but it doesn't recognize the file, as it doesn't give me the option to choose a decoder when I open the file. Has anyone tried it on a Tiger Lake and does it require any special container. I have tried .MP4

Jamaika

24th December 2020, 11:31

Is loopfilter mask function {CONFIG_LPF_MASK} needed in the av1 codec? Seems neglected and buggy.

utack

6th January 2021, 16:33

https://videocardz.com/newz/lenovo-confirms-geforce-rtx-3050-ti-6gb-rtx-3050-4gb-and-rtx-3060-12gb
https://cdn.videocardz.com/1/2020/12/Legion-Lenovo-Legion-R5-28IMB05-RTX3050-RTX3060.png
https://psref.lenovo.com/Product/Lenovo_Legion_R5_28IMB05?ViewSpec=true

RTX 3050 4GB GDDR6 leaked by Lenovo, the cheapest Nvidia card with AV1 fixed-function hardware decoding when released next year.

Not sure if ffmpeg currently works inefficently but mpv with an 8K AV1 Video it allocates just over 4000MB VRAM for me, so that would not work
Could someone cross-check with the native Windows Video Player?

Greenhorn

6th January 2021, 22:47

Not sure if ffmpeg currently works inefficently but mpv with an 8K AV1 Video it allocates just over 4000MB VRAM for me, so that would not work
Could someone cross-check with the native Windows Video Player?

don't have MPV installed to test, but testing with a 8K60 HDR clip downloaded from Youtube shows the native media player allocating ~800 megabytes. (MPC-BE with madVR allocates ~2.1 gigabytes.) 1660 TI with a 6GB buffer.

8K is going to have huge memory requirements regardless of the codec, though; I'd expect it to basically scale by the number of frames prerendered by the player rather with additional codec overhead being negligible. I almost wonder if the suspiciously low numbers are due to decoding being too slow to fill some internal buffer, with the MS (libaom) decoder being slower than dav1d in MPC.

benwaggoner

7th January 2021, 02:23

Not sure if ffmpeg currently works inefficently but mpv with an 8K AV1 Video it allocates just over 4000MB VRAM for me, so that would not work
Could someone cross-check with the native Windows Video Player?
There are about 34M pixels in an 8K video frame. And there's no point in non-HDR 8K and HDR will be 10-bit minimum. With 4:2:0 and assuming no bit alignment overhead, that's 2.5 bytes per pixel, about 85M per frame. Of course, there is always bit alignment overhead, and internal high precision frequency transforms could easily make for 48 bits/pixel. Frame-parallel decoding could involve several of those. And a few RGB decoded frames for buffer could be way bigger than that. 16-bits per channel at RGBA 444 would be 272 MB/frame.

HW decoders have an easier time of it because they don't need frame-level parallel decoding nor RGB buffers since they can write 420 straight to GPU. But yeah, 4GB for 8K SW decoder seems quite plausible for me if a decent number of frames need to be buffered at different stages.

None of that is specific to AV1, but AV1 is the only thing people are talking about doing 8K SW decode with. My own research hasn't found any content that actually looks better at 8K than 4K, so there's a whole lot of solution looking for a problem going on in that scenario. 8K YouTube looks better than 4K YouTube because YouTube is bit-starved at every resolution and bitrate

benwaggoner

7th January 2021, 02:29

soresu

9th January 2021, 04:01

And there's no point in non-HDR 8K and HDR will be 10-bit minimum.

Arguably there's no point in >10bpc content.

I've seen plenty 8bpc content without banding so it clearly isn't inherent and I doubt that the average human could tell the difference between 10 and 12 bpc content at all.

takla

10th January 2021, 15:08

soresu

11th January 2021, 03:34

Yikes. I can already see the headlines for laws being passed (in EU countries anyway)

With products capable of 8K AV1 decode already on the market, by the time they passed a law there would be far more in consumer hands making the law redundant - I'd take it as a given someone willing to waste money buying an 8K TV probably would be willing to shell out for the latest and greatest PC and gfx card too.

That being said, the Samsung 8K TV models already have terrible power efficiency even without other issues coming in to play - I'm not sure whether it is to do with them having more FALD zones or just higher peak nits (or a combo of both) but the lowest efficiency rating their 4K QLED TVs have is B, whereas their 8K TV's can go as low as D (A being the best rating).

There's also the hybrid decoder recently committed for XB1 and later consoles using DX shaders and UWP, it would be interesting to see what the power consumption on the XSX doing 8k AV1 decode when using that.

takla

11th January 2021, 04:53

With products capable of 8K AV1 decode already on the market, by the time they passed a law there would be far more in consumer hands making the law redundant

Yeah true. I thought about it some more and came to the same conclusion.

soresu

12th January 2021, 15:43

It seems that at least Samsung's mobile division is pushing AV1 support going by their latest reveal at CES of the new Exynos 2100 SoC destined for Galaxy S21.

Given reports put AV1 support in 2020 QLED models I will wait until actual hardware is in reviewers hands before I dance for joy.

benwaggoner

13th January 2021, 00:08

Arguably there's no point in >10bpc content.

I've seen plenty 8bpc content without banding so it clearly isn't inherent and I doubt that the average human could tell the difference between 10 and 12 bpc content at all.
The problem is dithering doesn't encode very well. A smooth gradient from Y'=64 to Y'=72 across a 1920x1080 frame is going to have banding in 8-bit without really good dithering that actual frequency-transform compression tends to lose.

And HDR with 8-bit is much harder. Just encoding Rec 2100 content in 8-bit yields a horrible mess.

And it's challenging to detect full 4K detail in SDR for natural images, and in many cases impossible even by expert viewers. HDR is what makes 4K generally worthwhile for natural images. Seeing the difference between carefully selected 4K and 8K HDR moving images is only possible by expert viewers with 20/10 vision and only on a minority of "stress test" clips.

Higher resolutions pay off a lot more for computer games, but that's more about the limitations of anti-aliasing technology and the much greater local contrast of synthetic graphics. Rendering games at 4K and downscaling to 1080p still looks a lot better than native 1080p gaming.

benwaggoner

13th January 2021, 00:15

With products capable of 8K AV1 decode already on the market, by the time they passed a law there would be far more in consumer hands making the law redundant - I'd take it as a given someone willing to waste money buying an 8K TV probably would be willing to shell out for the latest and greatest PC and gfx card too.

That being said, the Samsung 8K TV models already have terrible power efficiency even without other issues coming in to play - I'm not sure whether it is to do with them having more FALD zones or just higher peak nits (or a combo of both) but the lowest efficiency rating their 4K QLED TVs have is B, whereas their 8K TV's can go as low as D (A being the best rating).

There's also the hybrid decoder recently committed for XB1 and later consoles using DX shaders and UWP, it would be interesting to see what the power consumption on the XSX doing 8k AV1 decode when using that.
TVs don't have the horsepower for SW decode in any case. The big power differential is with computers which can provide lots of peak compute in exchange for much more power draw. And we're talking 2022 before even half of new PCs have AV1 HW decode, and 2025+ before the installed based could be even 50%. YouTube using any codec that doesn't have a HW decoder on a system that does have some HW decoders must hugely add up. Plus the encoding power needed is also a lot higher.

The XSX decoder is probably better, but consoles are power beasts in general. Xbox and PS consoles generally draw >100 watts to just have something on the screen. Compare to things like Roku or Fire TV which draw <10 watts running full blast.

Of course, when doing streaming over 4/5G, higher bandwidths also mean more antenna power, so there's some tradeoff there somewhere.

Environmental organizations should really come out with a browser plugin to force YouTube et all to only stream the best codec that has a HW decoder.

soresu

13th January 2021, 09:03

Environmental organizations should really come out with a browser plugin to force YouTube et all to only stream the best codec that has a HW decoder.

Most new PC's have VP9 HW decoding and obviously all have H264 HW too - if you lack AV1 capable HW then all you have to do in Firefox to only use HW decoders is to disable AV1 playback in the about:config page.

I'm not sure if Chrome has an equivalent easily found switch to control AV1 playback capability.

soresu

13th January 2021, 09:40

And HDR with 8-bit is much harder. Just encoding Rec 2100 content in 8-bit yields a horrible mess.

And it's challenging to detect full 4K detail in SDR for natural images, and in many cases impossible even by expert viewers. HDR is what makes 4K generally worthwhile for natural images. Seeing the difference between carefully selected 4K and 8K HDR moving images is only possible by expert viewers with 20/10 vision and only on a minority of "stress test" clips.

Ah sorry, I didn't mean using HDR or Rec 2100 for 8 bit.

When I wrote ">10 bpc" I only meant above 10 bpc, not 10 bpc and above.

Some people write > to mean 'more than or equal to', for me it just means 'more than', and >= means 'more than or equal to'. Linguistic consequence of Python dabbling I think.

As to the difference between 2K and 4K being visible without HDR, I would say that depends upon display size and the viewing distance.

IMHO many people get screens too small to even appreciate the resolution uptick from SD to 1080p, and often sit too far away from the screen which only makes the issue worse.

I have a 40 inch 1080p TV which I use as a PC monitor (50 cm away at most), and I can just about see the screen door effect of the pixel separation.

Obviously this gets much worse for a 4K screen, and 8K is never going to be anything but a placebo to the consumer, unless viewing through VR with insane pixel res per eye and the right optics to capitalise on it.

hajj_3

14th January 2021, 13:52

rav1e v0.4.0 is out: https://github.com/xiph/rav1e/releases/tag/v0.4.0

benwaggoner

14th January 2021, 18:55

Ah sorry, I didn't mean using HDR or Rec 2100 for 8 bit.

When I wrote ">10 bpc" I only meant above 10 bpc, not 10 bpc and above.

Gotcha. And yes, I've not seen many cases where >10-bit is needed for final consumer delivery presuming that good dithering was done. Things are simpler with more precision, because various dithering stages can be skipped (dithering-on-encoding is just one; the playback device can often have at least 2 rounds of dithering post-decode). In content creation, at least 2 bits more than deliver should be used so that dithering isn't required in all the intermediate steps.

As to the difference between 2K and 4K being visible without HDR, I would say that depends upon display size and the viewing distance.
Those can also be limiting factors. But the fundamental limitation is the human visual system and the content. For >2K to look better, you'll need content with frequencies greater than Nyquist to have material that can use more pixels. Lots of sources won't really have that, and a lot more sources will only have that in grain (source or synthetic). Most 4K studio content we see has lots of 2K + grain shots.

IMHO many people get screens too small to even appreciate the resolution uptick from SD to 1080p, and often sit too far away from the screen which only makes the issue worse.
Very true. For years I've been telling people that often the best upgrade to their TV experience would be pushing their couch forward.

I have a 40 inch 1080p TV which I use as a PC monitor (50 cm away at most), and I can just about see the screen door effect of the pixel separation.
Yeah, that's WAY too close! If you're looking at the center of the screen, the viewing angle to the edges of the screen are going to be terrible. You actually need to move your head around to see different parts, and push your chair back to see the whole image at once.

Obviously this gets much worse for a 4K screen, and 8K is never going to be anything but a placebo to the consumer, unless viewing through VR with insane pixel res per eye and the right optics to capitalise on it.
And with VR, only because the optics reduce the actual worse case detail delivered. Its really more about the fundamental limits of how small an arc we can resolve visually.

Blue_MiSfit

14th January 2021, 21:14

Another aspect of VR is that when it comes to pre-produced content you're effectively rendering a 360 degree scene and then using equirectangular projection to fit that into a standard video frame size. During playback the player wraps that video inside a sphere and drops your viewport inside of that sphere. This means that you actually look at a small piece of the video. With a ~4K video and a ~2.5K head mounted display / headset with a typical FOV you're going to be looking at maybe 1/4 of the encoded resolution. The player of course has to upscale to hit the native HMD display. All of this means that you're basically watching sub HD video on a very dense screen as close as your eyes can focus :)

360 video is generally pretty boring, but to really maximize the potential you'd basically want a 16k video. Some companies (Pixvana) tried to get around this by cutting the video into slices and only streaming one or two at a time. This theoretically lets you get higher resolution during playback and lower bandwidth (since you're not streaming / decoding / processing everything you can't see). Ultimately 360 video just does not scale though, and the lack of parallax is disturbing and uncomfortable for many. Here's hoping for lots of neat developments in light field capture, compression, and delivery. The guys at Lytro were doing wild and crazy stuff a few years ago before they ran out of money. I wonder what Google is doing with all that IP...

benwaggoner

15th January 2021, 19:24

Yeah, I've got ~7 patents on VR encoding and playback, and it's not something I see a way to make work for customers for scripted content. Video games are obviously a good fit for some genres, and some experiences more like museum curation can be great. But VR is mainly a new thing, not a new way to deliver old things.

And video quality is at least 15 years behind what we can do with a 2D flat screen.

hajj_3

17th January 2021, 14:57

Google to require all new android tv device model released after march 31st 2021 must include AV1 decode support: https://www.xda-developers.com/google-requires-new-android-tv-av1-video-decoding/

We will therefore see all new android tv box models having support and also some tv's also use android tv so they will support av1 too.

soresu

18th January 2021, 10:06

Here's hoping for lots of neat developments in light field capture, compression, and delivery. The guys at Lytro were doing wild and crazy stuff a few years ago before they ran out of money. I wonder what Google is doing with all that IP...

I asked a VFX industry vet who worked on The Jungle Book about lightfield camera tech at a 3D animation and VFX conference held at our uni.

His impression was that it was potentially amazing (especially for potentially rendering green screen filming redundant), but that the processing and storage hardware was reminiscent of the early days of computers size wise, and not at all practical for production film use at that time (this was maybe early 2018).

Google may well be simply concentrating on downsizing the technologies problems at the moment.

Decreasing compute and storage demands to a reasonable level would go a long way towards making it viable for wider use, even if just for the VFX industry to begin with.

OTOH if Lytro's patents are broad enough they may just be sitting back and waiting for a gold mine to mature when some other company does all that R&D heavy lifting for them.

As someone who had to monkey about with messy green screen footage in NUKE I'm definitely excited by the possibilities in lightfield capture - though I would probably settle for just high res depth map data captured for each frame of video.

benwaggoner

19th January 2021, 18:11

I asked a VFX industry vet who worked on The Jungle Book about lightfield camera tech at a 3D animation and VFX conference held at our uni.

His impression was that it was potentially amazing (especially for potentially rendering green screen filming redundant), but that the processing and storage hardware was reminiscent of the early days of computers size wise, and not at all practical for production film use at that time (this was maybe early 2018).

Google may well be simply concentrating on downsizing the technologies problems at the moment.
Lytro ramped down all their feature film R&D after they were acquired. Whatever Google is doing with them, it's not trying to create the next Panavision or Arri.

The stuff was really complex on-set. It made early 3-strip Technicolor look simple. And while some components could be shrunk down, fundamentally you need a lot of lenses over a pretty wide area for the tech to work.

soresu

19th January 2021, 21:44

The stuff was really complex on-set. It made early 3-strip Technicolor look simple. And while some components could be shrunk down, fundamentally you need a lot of lenses over a pretty wide area for the tech to work.

Metalens tech developments might solve the lens problem.

They not only increase the versatility of lenses (much lighter, thinner, and even achromatic focusing in a single lens element) but make them much easier to manufacture en masse.

Making a metalens is more like manufacturing a computer chip with photolithography processes, rather than the cutting and polishing of conventional curved lenses used today.

It makes sense to make a big change all at once for lightfield capture considering LF itself is a big change from conventional camera technology - might as well make a clean break.

benwaggoner

19th January 2021, 22:47

We should probably start a "Encoding for VR" thread.

hajj_3

27th January 2021, 11:32

PotPlayer 1.7.21419 released today adds support for DXVA hardware decoding of AV1.

benwaggoner

27th January 2021, 21:43

PotPlayer 1.7.21419 released today adds support for DXVA hardware decoding of AV1.
The version on their site is still from September 2020. Where are you finding daily builds?

hajj_3

27th January 2021, 21:58

The version on their site is still from September 2020. Where are you finding daily builds?

The version on their website is the new version, they just haven't updated the changelog on their website yet.

Yups

30th January 2021, 13:20

PotPlayer 1.7.21419 released today adds support for DXVA hardware decoding of AV1.

They should add D3D11 as well.

LigH

17th February 2021, 12:57

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 10.2.0)

AOM v2.0.1-1254-gdb9ae9d7a (http://www.mediafire.com/file/ap3sh7gywzrdqer/aom_v2.0.1-1254-gdb9ae9d7a.7z/file)

rav1e 0.5.0-alpha (1869a8b2 / 2021-02-15) (http://www.mediafire.com/file/16v5ipiidfvqny8/rav1e_0.5.0-alpha_2021-02-15_1869a8b2.7z/file)

dav1d 0.8.1-70 (gb768fdb / 2021-02-15) (http://www.mediafire.com/file/wcf0bbjazur7006/dav1d_0.8.1-70-gb768fdb.7z/file)

avif 0.8.4-ac14571 (http://www.mediafire.com/file/422r0t15hvjo5bn/avif-0.8.4_ac14571.7z/file)
dav1d [dec]:0.8.1-61-g2e73051, aom [enc/dec]:2.0.1-1224-g89fc93496, rav1e [enc]:0.4.0 (p20210202-11-gbc17f485)

marcomsousa

22nd February 2021, 12:56

dav1d 0.8.2 'Eurasian hobby' the fast and lean AV1 decoder

This is a middle-size update of the dav1d decoder, from the 0.8.x branch.This release adds most of the remaining NEON optimizations for ARM, especially for 10/12bit bitdepth, in both ARM32 and ARM64.This release also split the post-filters into their own threads.

This release speeds up quite a bit the desktop version, notably in the coefficient decoding and the MSAC parts. It also introduces the first 10bit optimizations for x86.

Finally, this release improves the speed in numerous parts of the decoder, improves the player shipped and brings other fixes.

Marco Sousa

marcomsousa

23rd February 2021, 12:34

Avif feature in Firefox next release will been delayed because of an important bug.

Marco Sousa

Mr_Khyron

19th March 2021, 03:03

benwaggoner

19th March 2021, 06:00

NETINT Announces the World’s First Commercially Available Hardware AV1 Encoder for the Data Center
https://netint.ca/netint-announces-the-worlds-first-commercially-available-hardware-av1-encoder-for-the-data-center/
Wow, their web page seems so atavistic. They're talking about replacing SW for ASIC encoding for advanced encoders. It's like rewinding the last 20 years of compression evolution.

In general, the more complex the codec, the bigger advantage SW encoders have had in quality over HW. AV1 is the most complex video codec, ever. It's hard for me to imagine how an ASIC could deliver competitive quality.

But maybe they've found magic! I look forward to seeing its output.

VincAlastor

23rd March 2021, 21:22

Does someone know why there is no SVT-AV1 release since [0.8.6] - 2020-11-28? Also auto builds are no longer published since 2021-02-16.

Mr_Khyron

24th March 2021, 01:26

https://aomedia.googlesource.com/aom/+/v3.0.0
Release v3.0.0 Braeburn

2021-03-23 v3.0.0 Braeburn

This release includes compression efficiency improvement, speed improvement
for realtime mode, as well as some new APIs.

- Upgrading:

Support for PSNR calculation based on stream bit-depth.

New encoder control IDs added:
- AV1E_SET_ENABLE_RECT_TX
- AV1E_SET_VBR_CORPUS_COMPLEXITY_LAP
- AV1E_GET_BASELINE_GF_INTERVAL
- AV1E_SET_ENABLE_DNL_DENOISING

New decoder control IDs added:
- AOMD_GET_FWD_KF_PRESENT
- AOMD_GET_FRAME_FLAGS
- AOMD_GET_ALTREF_PRESENT
- AOMD_GET_TILE_INFO
- AOMD_GET_SCREEN_CONTENT_TOOLS_INFO
- AOMD_GET_STILL_PICTURE
- AOMD_GET_SB_SIZE
- AOMD_GET_SHOW_EXISTING_FRAME_FLAG
- AOMD_GET_S_FRAME_INFO

New aom_tune_content enum value: AOM_CONTENT_FILM

New aom_tune_metric enum value: AOM_TUNE_VMAF_NEG_MAX_GAIN

Coefficient and mode update can be turned off via
AV1E_SET_{COEFF/MODE}_COST_UPD_FREQ.

New key & value API added, available with aom_codec_set_option() function.
Scaling API expanded to include 1/4, 3/4 and 1/8.

- Enhancements:

Better multithreading performance with realtime mode.

New speed 9 setting for faster realtime encoding.

Smaller binary size with low bitdepth and realtime only build.

Temporal denoiser and its optimizations on x86 and Neon.

Optimizations for scaling.

Faster encoding with speed settings 2 to 6 for good encoding mode.

Improved documentation throughout the library, with function level
documentation, tree view and support for the dot tool.

- Bug fixes:
Aside from those mentioned in v2.0.1 and v2.0.2, this release includes the
following bug fixes:

Issue 2940: Segfault when encoding with --use-16bit-internal and --limit > 1

Issue 2941: Decoder mismatch with --rt --bit-depth=10 and --cpu-used=8

Issue 2895: mingw-w64 i686 gcc fails to build

Issue 2874: Separate ssse3 functions from sse2 file.

Mr_Khyron

30th March 2021, 21:20

http://downloads.aomedia.org/assets/pdf/AOMedia%20Non%20Member%20Newsletter%20-%20Q12021.pdf

NETINT Technologies Joins the Alliance for Open Media
https://aomedia.org/press%20releases/netint-technologies-joins-the-alliance-for-open-media/

Marsu42

3rd April 2021, 11:28

Does someone know why there is no SVT-AV1 release since [0.8.6] - 2020-11-28? Also auto builds are no longer published since 2021-02-16.

Rumor has it that it's due to the bus factor (https://en.wikipedia.org/wiki/Bus_factor).

Yups

8th April 2021, 21:52

The rumor isn't really new but according to sources from Moore's Law Is Dead, Intels Xe HPG will come with AV1 encoding support.

https://youtu.be/84IV8VmQoY4?t=607

The fps comparison with RTX 3080 is a bit silly, I mean it must be CPU encoding, there is no hardware support from RTX 3080.

Mr_Khyron

22nd April 2021, 01:12

benwaggoner

23rd April 2021, 19:14

Google supercharges YouTube with a custom video chip
https://www.cnet.com/news/google-supercharges-youtube-with-a-custom-video-chip/
https://blog.youtube/inside-youtube/new-era-video-infrastructure
https://dl.acm.org/doi/pdf/10.1145/3445814.3446723
Looks interesting, and makes sense given YouTube's pixels/watt economic needs. I note they don't have an AV1 implementation yet, but are working on one.

Processors like this should be able to deliver better pixels/watt for relatively high bits/pixel, but with complex modern codecs like AV1 and HEVC, I'm doubtful they'll be able to get within 10% the bitrate a good software encoder is capable of for a given visual quality. But I've not deep-dived on their design much yet.

hajj_3

24th April 2021, 11:07

Looks interesting, and makes sense given YouTube's pixels/watt economic needs. I note they don't have an AV1 implementation yet, but are working on one.

Processors like this should be able to deliver better pixels/watt for relatively high bits/pixel, but with complex modern codecs like AV1 and HEVC, I'm doubtful they'll be able to get within 10% the bitrate a good software encoder is capable of for a given visual quality. But I've not deep-dived on their design much yet.

They don't need to be that great for the majority of youtube videos as many videos only have 1 view in which case encoding using a cpu is a waste. So cpu encoding for popular videos and use hardware for videos with few views.

benwaggoner

27th April 2021, 18:01

They don't need to be that great for the majority of youtube videos as many videos only have 1 view in which case encoding using a cpu is a waste. Some cpu encoding for popular videos and use hardware for videos with few views.
Right. A good fit for the YouTube use case. If I was designing YouTube, I'd use a system like this for the initial encodes, and then reencode with SW to improve quality if content starts getting a lot of views. I imagine YouTube has 1% of content accounting for >90% of views.

It's interesting to see Google talking about power savings in the cloud, which would be a lot smaller than the added power draw of YouTube's forced software VP9 and AV1 decode. I'm sure MW are being spent globally to decode VP9/AV1 in SW on devices that support H.264/HEVC in hardware. Even 10 extra watts per viewer at YouTube's scale is enormous.

butterw2

27th April 2021, 19:50

Looks interesting, and makes sense given YouTube's pixels/watt economic needs. I note they don't have an AV1 implementation yet, but are working on one.

According to the Cnet article, they have began deployment of the 2nd Gen Argos hw encoder VCU (with AV1 support) in recent months.

dapperdan

27th April 2021, 20:56

It's interesting to see Google talking about power savings in the cloud, which would be a lot smaller than the added power draw of YouTube's forced software VP9 and AV1 decode. I'm sure MW are being spent globally to decode VP9/AV1 in SW on devices that support H.264/HEVC in hardware. Even 10 extra watts per viewer at YouTube's scale is enormous.

If we're jumping straight to eco-communism and forcing giant corporations to spend millions of dollars in a specific way for the good of the planet then I have many suggestions that will have a deeper impact than YouTube using HEVC.

Even if we stick within video codecs, it would seem that corporations behind HEVC not charging for using math that they claim the legal rights to licence would be a more obvious target for anger and activism in this regard. Especially as they're currently pushing 3.5 new competing codecs. Wouldn't it be better for the ice caps if they just adopted AV1?

benwaggoner

28th April 2021, 00:29

According to the Cnet article, they have began deployment of the 2nd Gen Argos hw encoder VCU (with AV1 support) in recent months.
I hope there will be a followup publication about that version.

There's been a fair amount of R&D around assisted encoding, using HW encoders for coarse motion estimation, frame type decisions, that sort of thing. MCW saw about a 20-25% speedup in x265 using that, which wasn't really worth it in the end. If the Gen2 processor is better suited to that, perhaps they can combine some higher level algorithmic tuning to get a bigger share of the potential efficiency of codecs.

However, the way they've leaned into optimization for memory bandwidth would preclude much low-level tweaking. But maybe a faster hybrid mode as mentioned above? Maybe try encoding each frame different ways on different processors and then synthesize the data for a final pass?

benwaggoner

28th April 2021, 00:35

If we're jumping straight to eco-communism and forcing giant corporations to spend millions of dollars in a specific way for the good of the planet then I have many suggestions that will have a deeper impact than YouTube using HEVC.
Sure, be my guest! But this is something that can make a different within the domain of this forum.

Even if we stick within video codecs, it would seem that corporations behind HEVC not charging for using math that they claim the legal rights to licence would be a more obvious target for anger and activism in this regard. Especially as they're currently pushing 3.5 new competing codecs. Wouldn't it be better for the ice caps if they just adopted AV1?
Pretty much every phone, tablet, and PC has supported HEVC HW decode for years now. Using a SW decoder on devices that have a HEVC HW decoder is wasting watts. I'd imagine by 2025 we'd have the majority of new devices have AV1 decode and the math would change. But there's no way to add HW decoder to devices that already shipped or will ship without HW AV1.

An argument certainly can be made on purely an environmental basis that HEVC and VVC should get much more H.264 like licenses so that Chrome and Firefox could use those codecs and YouTube and Facebook would encode for them.

Alas, that is the domain of lawyers and MBAs, and I only get to give them my opinions, not tell them what to do.

Mr_Khyron

4th May 2021, 10:04

https://aomedia.googlesource.com/aom/+/562fcd4ab0aa2c49c12df4bd2b76dca7a837ad4c
Release v3.1.0 Celestia

2021-05-03 v3.1.0
This release adds an "all intra" mode to the encoder, which
significantly speeds up the encoding of AVIF still images at speed 6.

- Upgrading:
All intra mode for encoding AVIF still images and AV1 all intra
videos: AOM_USAGE_ALL_INTRA (2) can be passed as the 'usage'
argument to aom_codec_enc_config_default().

New encoder control IDs added:
- AV1E_SET_ENABLE_DIAGONAL_INTRA: Enable diagonal (D45 to D203)
intra prediction modes (0: false, 1: true (default)). Also
available as "enable-diagonal-intra" for the
aom_codec_set_option() function.

New aom_tune_metric enum value: AOM_TUNE_BUTTERAUGLI. The new aomenc
option --tune=butteraugli was added to optimize the encoder’s
perceptual quality by optimizing the Butteraugli metric. Install
libjxl (JPEG XL) and then pass -DCONFIG_TUNE_BUTTERAUGLI=1 to the
cmake command to enable it.

Addition of support for libvmaf 2.x.

- Enhancements:
Heap memory consumption for encoding AVIF still images is
significantly reduced.

- Bug fixes:
Issue 2601: third_party/libaom fails licensecheck

Issue 2950: Conditional expression for rc->this_key_frame_forced is
always true in find_next_key_frame()

Issue 2988: "make install" installs the aom.h header twice

Issue 2992: Incorrectly printing the temporal_id twice in dump_obu
tool

VincAlastor

9th May 2021, 09:23

https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases

[0.8.7] - 2021-05-08

Encoder

Feature optimizations: creating new mode decision / encode-decode feature levels allowing better speed / quality trade-off granularity
Preset repositioning after adopting new levels
Preset 8 achieving similar speed levels to that of x265 medium in the VOD (shot-based encoding) use-case while maintaining quality gains
New 1-pass and 2-pass VBR implementation ported from libaom and adapted to the SVT architecture - still a WIP
Cleaned up old VBR and CVBR RC code along with the lookahead mechanism associated with them
Improvements for TPL algorithm to handle long clips and easy content
Added HDR support and color primaries SEI signaling (off by default until integrated with ffmpeg)
Memory optimizations, cleaning up data structures to reduce memory usage up to 2x memory reduction in multi-threaded VBR environment
Additional AVX2 and AVX512 optimizations
Cleaned up unused command line parameters except the config params that are linked to ffmpeg
Update user guide and documentation

Build and Testing

Bug fixes
Improve CI coverage
Improve Unit Test Coverage
Address C vs asm mismatches
Fix static analysis warnings / errors

hajj_3

13th May 2021, 12:20

mediatek dimensity 900 was announced today, it can hardware decode AV1.

benwaggoner

13th May 2021, 18:48

hajj_3

13th May 2021, 23:00

benwaggoner

14th May 2021, 00:58

There is no hardware decoder in at least 1 of the consoles, i read it somewhere official a few weeks ago, can't remember where though.
Share the link if you can find it!

soresu

17th May 2021, 20:24

Anyone know anything about this AV1 decoder for Xbox Series S|X? https://www.microsoft.com/en-us/p/av1-video-extensions/9p13g73d7rmz

The AMD GPU in both the PS5 and Xbox Series has AV1 HW decode in its PC GPU implementations. Have we ever found out whether the HW is there on the new game consoles?

We went through this months ago when I brought up the AOM GPU software decoder branch for XB1 which uses shaders to work.

Both Sony and MS consoles share the base raster/RT/compute µArch of RDNA2, with each having semi custom optimisations of their own + either their own designed video unit, or an iteration of the AMD VideoCoreNext (VCN) block that predates what went into the PC RDNA2 line up of GPU dies.

Only VCN3 forwards has this support.

That means NV2x currently for AMD, and the upcoming Van Gogh and Rembrandt APUs known to have it from early driver code commits.

This is sadly not that surprising as even the AMD Zen3 Cezanne APU launched just this year still lacks HW ASIC support in its VCN block.

I would expect any Slim or Pro type mid cycle console variants using new chips to have AV1 support though, that would seem a serious blunder if not.

That being said dav1d 0.9 was just released with a massive AVX2 SIMD asm dump for 10+ bpc content, so the current consoles should be more than enough to decode it with 8 Zen2 CPU cores - at least for content like Youtube (or Twitch later) not requiring DRM which is still going to be the majority of AV1 content for some time I think.

Facebook and Netflix sponsored most of the big new AVX2 dump - so clearly they have their eyes on using it for their own BW reducing purposes.

For Xbox you can currently use Kodi v19 which uses an older dav1d 0.8.x release - but there may well be a Kodi v19.x update to come with the 0.9 release of dav1d somewhere down the road.

benwaggoner

17th May 2021, 21:48

We went through this months ago when I brought up the AOM GPU software decoder branch for XB1 which uses shaders to work.

Both Sony and MS consoles share the base raster/RT/compute µArch of RDNA2, with each having semi custom optimisations of their own + either their own designed video unit, or an iteration of the AMD VideoCoreNext (VCN) block that predates what went into the PC RDNA2 line up of GPU dies.

Only VCN3 forwards has this support.

That means NV2x currently for AMD, and the upcoming Van Gogh and Rembrandt APUs known to have it from early driver code commits.

This is sadly not that surprising as even the AMD Zen3 Cezanne APU launched just this year still lacks HW ASIC support in its VCN block.

I would expect any Slim or Pro type mid cycle console variants using new chips to have AV1 support though, that would seem a serious blunder if not.
That is great info, thanks!

That being said dav1d 0.9 was just released with a massive AVX2 SIMD asm dump for 10+ bpc content, so the current consoles should be more than enough to decode it with 8 Zen2 CPU cores - at least for content like Youtube (or Twitch later) not requiring DRM which is still going to be the majority of AV1 content for some time I think.

Facebook and Netflix sponsored most of the big new AVX2 dump - so clearly they have their eyes on using it for their own BW reducing purposes.

DRM requirements for consoles can be more flexible than for Mac/Win/Android due to the strong virtualization and locked-down nature. One can't run WireShark or a debugger against someone else's code! 720p HD content was allowed on both Xbox 360 and PS3 despite not having fixed-function decoders.

LigH

18th May 2021, 21:04

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 10.3.0)

AOM v3.1.0-220-g5b35124c3 (https://www.mediafire.com/file/kctapqixgtp8cjo/aom_v3.1.0-220-g5b35124c3.7z/file)

rav1e 0.5.0-alpha (df8b712b / 2021-05-16) (https://www.mediafire.com/file/oyeszn22ds1fx7a/rav1e_0.5.0-alpha_df8b712b.7z/file)

dav1d 0.9.0-0 (g8636b4f / 2021-05-16) (https://www.mediafire.com/file/2ewbyzu9l668wca/dav1d_0.9.0-0-g8636b4f.7z/file)

avif 0.9.0_917cc2c (https://www.mediafire.com/file/rkm4ub71m33mx89/avif-0.9.0_917cc2c.7z/file)
dav1d [dec]:0.9.0-0-g8636b4f, aom [enc/dec]:3.1.0-218-ga862e2058, rav1e [enc]:0.5.0-alpha (p20210511-46-gdf8b712b)

BlueLane

20th August 2021, 17:41

Coming to think of it, SW AV1 decoding is actually going to have an impact on global CO2 emissions. A CPU can easily draw 20 more watts in SW decode versus HW decode. 500K simultaneous YouTube viewers watching AV1 could be another 5 MWatt more power consumption and emissions than if YouTube used HEVC. Even assuming low-emissions NG plants, that would be around an extra megaton of global CO2 emissions an hour.

Yowza.

This was wildly incorrect. It's disappointing to see people spreading this kind of misinformation, and that not a single person caught it. It's a huge error to not catch.

Natural gas plants emit about 1 pound of CO2 per kWh, so 1,000 lbs per MWh. I'm being generous and overestimating it a bit – it's more like 0.9 and 900 lbs. (Source: https://www.eia.gov/tools/faqs/faq.php?id=74&t=11) But being conservative, this amounts to 5,000 lbs of CO2 from 5 MWh. You said a "megaton". That's a million tons. The actual figure is less than 2.5 tons. Big difference.

And your 5 MWh figure is wrong if you're basing it on the 20 watt difference you mentioned. 20 watts × 500,000 people × 1 hour = 10 MWh, not 5. So we're up maybe 5 tons now, compared to the 1,000,000 tons you claimed.

Moreover, no numbers here would be relevant to a rational knower without some context that made them relevant. You committed the Large Number Fallacy, which is just to handwave with large, or large-sounding, numbers like a million, megatons, etc., without providing any information that would make those numbers relevant to the non-gullible. In this case, the fallacy is heightened because a megaton of CO2 is trivial in the context of Earth's climate – there are well over 1,000 gigatons of CO2 in Earth's atmosphere, so a single megaton isn't going to matter much, even if it was hourly. Of course, your megaton claim was off by a factor of 200, so the actual amount definitely doesn't matter.

Ideologies and religions reliably corrode people's grip on reality. Caring about mild, long-term climate change predictions is definitely optional, and probably irrational. False inflated stats only serve to amplify the irrational impulses and arbitrary abstractions that are already doing harm. In any case, don't assume everyone else subscribes to your religion, or that everyone is obligated to conform to its dictates.

Mr_Khyron

5th September 2021, 02:44

AV1: Still The Current Future Of Video
https://blog.xaymar.com/2021/08/19/av1-still-the-current-future-of-video/
All the way back in December 2020, I decided it was time to try out how far AV1 had progressed. At the time, SVT AV1 was the only encoder that produced reasonable results with near realtime performance, however that has changed now. A lot of work went into AOM AV1, and it is now capable of encoding in the “frames per second” realm instead of “frames per minute”. So why not take another look at things?

For the tests I used footage I captured myself, as that way I have no problems figuring out who actually owns the distribution rights. As for versions of the encoder, NVIDIA NVENC was run with Driver version 471.41 on a RTX 3090, AOM AV1 was compiled at v3.1.2, and SVT AV1 was on compiled at v0.8.6-76-g44486d23. The tests were run with the following settings:........

RanmaCanada

5th September 2021, 09:12

This was wildly incorrect. It's disappointing to see people spreading this kind of misinformation, and that not a single person caught it. It's a huge error to not catch.

Natural gas plants emit about 1 pound of CO2 per kWh, so 1,000 lbs per MWh. I'm being generous and overestimating it a bit – it's more like 0.9 and 900 lbs. (Source: https://www.eia.gov/tools/faqs/faq.php?id=74&t=11) But being conservative, this amounts to 5,000 lbs of CO2 from 5 MWh. You said a "megaton". That's a million tons. The actual figure is less than 2.5 tons. Big difference.

And your 5 MWh figure is wrong if you're basing it on the 20 watt difference you mentioned. 20 watts × 500,000 people × 1 hour = 10 MWh, not 5. So we're up maybe 5 tons now, compared to the 1,000,000 tons you claimed.

Moreover, no numbers here would be relevant to a rational knower without some context that made them relevant. You committed the Large Number Fallacy, which is just to handwave with large, or large-sounding, numbers like a million, megatons, etc., without providing any information that would make those numbers relevant to the non-gullible. In this case, the fallacy is heightened because a megaton of CO2 is trivial in the context of Earth's climate – there are well over 1,000 gigatons of CO2 in Earth's atmosphere, so a single megaton isn't going to matter much, even if it was hourly. Of course, your megaton claim was off by a factor of 200, so the actual amount definitely doesn't matter.

Ideologies and religions reliably corrode people's grip on reality. Caring about mild, long-term climate change predictions is definitely optional, and probably irrational. False inflated stats only serve to amplify the irrational impulses and arbitrary abstractions that are already doing harm. In any case, don't assume everyone else subscribes to your religion, or that everyone is obligated to conform to its dictates.

The problem with your post is believing everyone is using Natural Gas. Coal is still used in the majority of the world. In fact almost 40% of the world's electricity is created with coal powered plants.

Sorry.

birdie

10th October 2021, 10:14

AV2 is already showing serious bitstream savings: https://ottverse.com/av2-video-codec-evaluation/

benwaggoner

13th October 2021, 00:34

AV2 is already showing serious bitstream savings: https://ottverse.com/av2-video-codec-evaluation/
I only saw ~7% BD-rate savings in the proposed intra tools under research.

Which is totally fine at such an early state of development. This is all fixed QP, fixed-GOP, no rate control testing comparing the averages of per-frame scores. It's nearly impossible to extrapolate from this early stage what real world savings might be like in practice. I'm sure AV2's gains over AV1 will be >>7%, but we won't know how it compares to VVC in practice until a couple of years after the AV2 standard is completed.

hajj_3

15th October 2021, 15:21

Libaom v3.2.0

This release includes compression efficiency and perceptual quality improvements, speedup and memory optimizations, as well as some new features.
- New Features
* Introduced speeds 7, 8, and 9 for all intra mode.
* Introduced speed 10 for real time mode.
* Introduced an API that allows external partition decisions.
* SVC: added support for compound prediction.
* SVC: added support for fixed SVC modes.
- Compression Efficiency Improvements
* Intra-mode search improvement.
* Improved real time (RT) mode BDrate savings by ~5% (RT speed 5)
and ~12% (RT speed 6). The improvement was measured on the video
conference set.
* Improved real time mode for nonrd path (speed 7, 8, 9): BDrate
gains of ~3-5%.
* Rate control and RD adjustments based on ML research in VP9.
Gains of ~0.5-1.0% for HD.
- Perceptual Quality Improvements
* Added a new mode --deltaq-mode=3 to improve perceptual quality
based on a differential contrast model for still images.
* Added a new mode –deltaq-mode=4 to improve perceptual quality
based on user rated cq_level data set for still images.
* Weighting of some intra mode and partition size choices to better
manage and retain texture.
- Speedup and Memory Optimizations
* Further improved 2-pass good quality encoder speed:
o Speed 2 speedup: 18%
o Speed 3 speedup: 22%
o Speed 4 speedup: 37%
o Speed 5 speedup: 30%
o Speed 6 speedup: 20%
* Optimized the real time encoder (measured on the video conference
set):
o RT speed 5 speedup: 110%
o RT speed 6 speedup: 77%
- Bug Fixes
* Issue 3069: Fix one-pass mode keyframe placement off-by-one error.
* Issue 3156: Fix a bug in av1_quantize_lp AVX2 optimization.

benwaggoner

20th October 2021, 19:11

nhw_pulsar

20th October 2021, 20:03

Looks like a good point release, particularly for real-time encoding.

I do get nervous about deltaq modes based on still image research, though, as still-image algorithms generally need some tweaking for use with moving images.

You do get nervous maybe also because inter-frame/motion prediction residuals absolutely don't look like a natural still image.

Still image research is not done for motion prediction residuals, for example my wavelet codec (NHW) puts forward neatness of (natural) images, but I don't know if it'll work as-is with inter-frame residuals which have completely different properties.-It would be challenging (for me) to know if wavelet image codecs could be effectively tuned to work well with a motion prediction scheme and its residuals-... Btw, I'm also waiting eagerly to evaluate this new version of AV1 in AVIF.

Cheers,
Raphael

rwill

20th October 2021, 20:49

Looks like a good point release, particularly for real-time encoding.

I do get nervous about deltaq modes based on still image research, though, as still-image algorithms generally need some tweaking for use with moving images.

I am getting nervous when there are quite a couple of deltaq modes to choose from and the encoder developers didn't eliminate all but the 'best overall' for me.

benwaggoner

22nd October 2021, 04:24

I am getting nervous when there are quite a couple of deltaq modes to choose from and the encoder developers didn't eliminate all but the 'best overall' for me.
Well, different modes can be better for different sorts of content. Grainy versus clean film/video versus cel animation/anime versus text/graphics, for example.

The dream is to have those auto-adapt to the content instead of having to pick the least-wrong one for an entire title.

Yups

1st December 2021, 20:53

Very concerned about the future of AV1!
No public support on Snapdragon 8 Gen 1 or Apple A15 still.
The two highest volume flagship SoCs lack support.
While Samsung, MediaTek, and Intel have adopted it in latest SoCs, AMD also will not support it in the upcoming Rembrandt APU.
https://twitter.com/dylan522p/status/1465887898092425220

What is going on with AV1, why is there such a lacklustre support from some major players?

ksec

2nd December 2021, 00:59

https://twitter.com/dylan522p/status/1465887898092425220

What is going on with AV1, why is there such a lacklustre support from some major players?

It has been explained quite a few times in this thread for the past 2-3 years. But basically die size, cost, ( and profits ) engineering, power usage and politics.

Although I do think Qualcomm would support it next year along side with VVC. The A14 is capable of software decoding 4K AV1 under 1 watts. So if google really want to push it there is no reason why they cant turn on AV1 support on A15 or A16 with software update. But for reference the same 4K on VP9 and HEVC would only require ~150mW on Hardware decoder.

benwaggoner

2nd December 2021, 23:47

It has been explained quite a few times in this thread for the past 2-3 years. But basically die size, cost, ( and profits ) engineering, power usage and politics.

Although I do think Qualcomm would support it next year along side with VVC. The A14 is capable of software decoding 4K AV1 under 1 watts. So if google really want to push it there is no reason why they cant turn on AV1 support on A15 or A16 with software update. But for reference the same 4K on VP9 and HEVC would only require ~150mW on Hardware decoder.
The biggest problem for SW decode is that premium content really drives adoption and usage of new codecs, because quality and efficiency are at a premium and content is of much longer duration. And premium content requires solid HW DRM for HD, and even more secure for 4K. There are platforms where it possible to integrate a SW decoder into DRM, but many can't at all.

And watching 2 hour movie, just one extra watt on a phone can materially reduce battery life.

YouTube, delivering non-DRM'ed, shorter clips with a much lower quality expectation, can use SW decode where streaming service providers like Netflix and Disney+ cannot.

RanmaCanada

7th December 2021, 01:54

It has been explained quite a few times in this thread for the past 2-3 years. But basically die size, cost, ( and profits ) engineering, power usage and politics.

Although I do think Qualcomm would support it next year along side with VVC. The A14 is capable of software decoding 4K AV1 under 1 watts. So if google really want to push it there is no reason why they cant turn on AV1 support on A15 or A16 with software update. But for reference the same 4K on VP9 and HEVC would only require ~150mW on Hardware decoder.

There is also the fact that almost no one is paying the programmers to work on it, as most of the development appears to have been done by the community. If Google, MS, Netflix et al were actually serious about this, you figure they would hire a literal army of programmers to solve this. There is also the fact that any encoding to be done with it, is extremely confusing as there is almost no documentation.

BlueSwordM

15th December 2021, 17:33

What are you talking about?

Most of the people working on AV1 are indeed paid developers by Google, Netflix, Facebook, Visonular, Videolan, Two-Orioles, Intel, etc.

Mr_Khyron

30th December 2021, 11:39

https://github.com/obsproject/obs-studio/releases/tag/27.2.0-beta1

Added AOM AV1 and SVT-AV1 encoders (note that these are currently considered experimental, work best with CPUs that have many cores, and are only accessible for recording in advanced output mode)

mzso

7th January 2022, 01:13

Hmm. I thought AV1 would be further along by now. Did an encode with ffmpeg "-c:v libaom-av1 -crf 35 -cpu-used 3 -tiles 4x3 output.mkv" The output was almost the same size as libx264 -superfast at crf 18. But it took a lot longer and it looks worse.

Blue_MiSfit

8th January 2022, 02:32

Something is going wrong then. libaom and svt-av1 absolutely crush x264 at equivalent bitrates as long as you're not using the fastest possible speed presets.

Gravitator

12th January 2022, 11:12

What settings does Youtube use for encoding for AV1?

benwaggoner

12th January 2022, 18:28

What settings does Youtube use for encoding for AV1?
I am sure they are heavily biased toward speed over quality. Has anyone tried a bitstream analyzer?

GTPVHD

17th February 2022, 17:18

https://www.intel.com/content/www/us/en/newsroom/news/intel-technology-roadmaps-milestones.html

Arctic Sound-M – Arctic Sound-M brings the industry’s first hardware-based AV1 encoder into a GPU to provide 30% bandwidth improvement and includes the industry’s only open-sourced media solution. The media and analytics supercomputer enables leadership transcode quality, streaming density and cloud gaming. Arctic-Sound M is sampling to customers and will ship by mid-2022.

https://www.anandtech.com/show/17266/intels-arctic-soundm-server-accelerator-to-land-mid2022-with-hardware-av1-encoding

Interestingly, this also implies that hardware AV1 encoding is a native feature of (at least) the large Alchemist die. Though given the potential value of the first hardware AV1 encoder, it remains to be seen whether Intel will enable it on their consumer Arc cards, or leave it restricted to their server card.

https://www.anandtech.com/show/17264/intel-meteor-lake-client-processors-to-use-arc-graphics-chiplets

Looks like Intel Meteor Lake and later CPUs will get AV1 hardware encoder also since they have Intel Arc Tile GPU.

Losko

18th February 2022, 09:51

AOMenc 3.3.0 released, with nice speed improvements

https://www.phoronix.com/scan.php?page=news_item&px=AOM-AV1-3.3-Encoder

Yups

18th February 2022, 13:26

https://www.intel.com/content/www/us/en/newsroom/news/intel-technology-roadmaps-milestones.html

https://www.anandtech.com/show/17266/intels-arctic-soundm-server-accelerator-to-land-mid2022-with-hardware-av1-encoding

https://www.anandtech.com/show/17264/intel-meteor-lake-client-processors-to-use-arc-graphics-chiplets

Looks like Intel Meteor Lake and later CPUs will get AV1 hardware encoder also since they have Intel Arc Tile GPU.

Consumer cards could also come with AV1 encoding support, it's known from the driver. However Intel could disable it artificially for the consumer DG2 similar to the AVX512 blocking with latest bios updates.

benwaggoner

18th February 2022, 18:31

Looks like Intel Meteor Lake and later CPUs will get AV1 hardware encoder also since they have Intel Arc Tile GPU.
Promising. And Intel's never kept codec features to higher-end chips IIRC. The problem has been more the reverse; for years there were no GPUs in high-end Xeons so everything had to be done in software.

GTPVHD

30th March 2022, 16:42

https://twitter.com/IntelGraphics/status/1509186521953415179
https://www.intel.com/content/www/us/en/products/docs/arc-discrete-graphics/creator.html

Intel Arc is the world’s first GPU with hardware-accelerated encoding for AV1, the next-gen and royalty-free video codec. With the largest online video platforms adopting AV1 as the future of video, be ready to create, stream, share, and consume high quality AV1 content, up to 8K resolution, with new levels of performance and efficiency. Get equipped for the future of media with Intel Arc graphics.

Intel confirms AV1 hardware encoder in Intel Arc Alchemist GPUs.

Yups

31st March 2022, 11:10

It's a pure fixed function AV1 engine and not just a hybrid, this is good news.

Here is a game stream demo versus H264.

https://youtu.be/MvlKaUdfkyo

rin

7th April 2022, 18:45

Its a pure fixed function of AV1 engine This is very good news to me, The stream of demo versus h264 is on youtube (https://youtu.be/MvlKaUdfkyo). Someone informed me about this on my JTWhatsApp APK (https://cop23.com.fj/jtwhatsapp/)

LigH

28th May 2022, 22:53

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 12.1.0)

AOM v3.3.0-685-g664f04d74 (https://www.mediafire.com/file/n9bcna1yhzv8vn1/aom_v3.3.0-685-g664f04d74.7z/file)

rav1e 0.5.0-gd1d1dbe1 (https://www.mediafire.com/file/u2d3z25k75r2bo1/rav1e_0.5.0_d1d1dbe1.7z/file)

dav1d 1.0.0-24-gebeaac6 (https://www.mediafire.com/file/elphwgt0wp6k01l/dav1d_1.0.0-24-gebeaac6.7z/file)

avif 0.10.1_a2e109f (https://www.mediafire.com/file/py6mzpiz9lpu7eh/avif-0.10.1_a2e109f.7z/file)
dav1d [dec]:1.0.0-24-gebeaac6, aom [enc/dec]:3.3.0-685-g664f04d74, rav1e [enc]:0.5.0 (p20220510-126-gd1d1dbe1)

GTPVHD

15th June 2022, 06:29

https://www.intel.com/content/www/us/en/newsroom/article/intel-arc-a380-graphics-available-china.html
https://www.intel.com/content/www/us/en/products/docs/arc-discrete-graphics/3.html
https://ark.intel.com/content/www/us/en/ark/products/227959/intel-arc-a380-graphics.html

Intel Arc A380 graphics card with AV1 hardware decoder and encoder officially launched.

Yups

26th June 2022, 16:33

I found two performance tests versus CPU.

https://abload.de/img/3031klg.png
https://www.expreview.com/83796.html

https://abload.de/img/310wkvo.png
https://youtu.be/8NtGWP6bHeI?t=511

benwaggoner

28th June 2022, 02:39

Do we have any info about Intel's quality, or quality @ perf?

Blue_MiSfit

28th June 2022, 21:21

I haven't seen anything yet, but am eagerly looking forward to getting some of this info.

rwill

30th June 2022, 08:23

Yeah, I wish someone at a company that could use this info professionally would investigate.

GTPVHD

7th July 2022, 05:39

https://www.igorslab.de/en/intel-meteor-lake-u-p-and-h-exclusive-block-diagram-of-mobile-14-generation-leak/
https://www.igorslab.de/wp-content/uploads/2022/07/MTL-01.png

Leaked slide confirms Intel Meteor Lake have low power AV1 hardware encoder.

https://lists.freedesktop.org/archives/intel-gfx/2022-July/301011.html

Meteorlake is a new client platform following RPL S. Meteorlake
introduces version 14 for Display, version 13 Media and version
12.70 for Graphics.

OrangeColaJuice

14th July 2022, 22:53

https://twitter.com/Loeschzwerg_3DC/status/1547595162670338049
https://twitter.com/Loeschzwerg_3DC/status/1547605297425829889
Someone who got his hands on an a380 doing some encodings.

hajj_3

24th July 2022, 16:05

AVIF support is going to be in safari on macosx and ios16: https://www.cnet.com/tech/mobile/apple-endorses-new-avif-photos-for-a-faster-web-on-ios-16/

ChaosKing

24th July 2022, 16:27

https://twitter.com/Loeschzwerg_3DC/status/1547595162670338049
https://twitter.com/Loeschzwerg_3DC/status/1547605297425829889
Someone who got his hands on an a380 doing some encodings.

For the AV1 encode (hevc 380.93 fps)
encoded 11708 frames, 334.49 fps, 2418.42 kbps, 140.64 MB
encode time 0:00:35, CPU: 51.6, GPU: 48.1, VD: 74.9

I hope the slower preset gives much better quality :p

LigH

30th July 2022, 20:00

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 12.1.0)

AOM v3.4.0-196-g68a071086 (https://www.mediafire.com/file/asd8gskchll537u/aom_v3.4.0-196-g68a071086.7z/file)

rav1e 0.5.0-ga0328612 (https://www.mediafire.com/file/ep5zgndb2ztm5lt/rav1e_0.5.0_ga0328612.7z/file)

dav1d 1.0.0-45-ga029d68 (https://www.mediafire.com/file/y4tx1q7i6mbephm/dav1d_1.0.0-45-ga029d68.7z/file)

avif 0.10.1_3c12bb6 (https://www.mediafire.com/file/ippoqot289atswk/avif_0.10.1-3c12bb6.7z/file)
dav1d [dec]:1.0.0-45-ga029d68, aom [enc/dec]:3.4.0-196-g68a071086, rav1e [enc]:0.5.0 (p20220726-8-g9c4b2972)

SVT-AV1 v1.1.0-157-g8db44adf (https://www.mediafire.com/file/7i7i7pt0jxs0o5r/SVT-AV1_v1.1.0-157-g8db44adf.7z/file)

Yups

3rd August 2022, 00:40

Intel's WORLD FIRST GPU AV1 encoder was worth the hype

https://youtu.be/ctbTTRoqZsM

Very good AV1 result from the Arc A380 in this test.

ChaosKing

3rd August 2022, 08:14

Finally the one area the arc gpus are good at ^^"

Mr_Khyron

4th August 2022, 15:46

SSIM Comparison for Intel Arc A380 QSV
https://rigaya34589.blog.fc2.com/blog-entry-1501.html

Yups

4th August 2022, 23:08

SSIM Comparison for Intel Arc A380 QSV
https://rigaya34589.blog.fc2.com/blog-entry-1501.html

It's struggling at higher bitrates. Unfortunately he only tested ICQ and didn't check out CBR/VBR/CQP as well as MBBRC and ExtBRC, MB or Ext BRC can sometimes improve the quality.

He says HEVC and H264 encoder on Arc improved over ADL-S iGPU by the way.

It remains to be seen if AV1 QSV can improve over software improvements. oneVPL AV1 support looks rough at the moment.

EposVox made a mistake by not choosing the same gop length in his test, Intel AV1 QSV has a 1s seeking in his samples, means he uses a gop length of 60 (videos are 60 fps). VCE, Intel h264, x264 have a 10s seeking in his encoded videos. As for Intel h264 or h265 QSV a gop increase from 60 to 600 gop should improve the VMAF score by roughly 1 point.

Intel hardware AV1 performs really good at 3500 Kbit relative to the others in this test. It's a blocky mess in motion on NVENC or Intel h264. On higher bitrates Intel AV1 QSV detail preservation is quite poor, that's why it's losing relative to the others at higher bitrates.

Here is a frame example at 3500Kbit

Intel H264 QSV (https://abload.de/img/h264vzjos.png)
Nvidia H264 NVENC
(https://abload.de/img/nvencx8jjp.png)AMD H264 VCE (https://abload.de/img/vce27jlz.png)
Intel AV1 QSV (https://abload.de/img/intelav1u3j2a.png)
x264 very slow (https://abload.de/img/x264veryslows6kmu.png)

benwaggoner

9th August 2022, 18:39

It's struggling at higher bitrates. Unfortunately he only tested ICQ and didn't check out CBR/VBR/CQP as well as MBBRC and ExtBRC, MB or Ext BRC can sometimes improve the quality.
And average SSIM is not a particularly well subjectively correlated metric, particularly for HDR.

It remains to be seen if AV1 QSV can improve over software improvements. oneVPL AV1 support looks rough at the moment.
It's been well over a decade since any HW or even GPU-based encoding quality/efficiency wasn't notably worse than the best available software encoder, and the gap has been increasing as codecs get more complex. With so many modes available, making lots of tight loops with low-latency feedback and early exits is key to performance, and the waterfall processing style of GPU and fixed-function implementations harms quality much more than the theoretical performance edge helps. And a modern CPU with lots of cores and power AVX2+ SIMD can do lots of GPU-style encoding all in the same L3 cache.

HW encoders get used when watts/encode is really constrained, hard realtime is required, or for applications where bitrates aren't particularly constrained, like mezzanine encoding.

EposVox made a mistake by not choosing the same gop length in his test, Intel AV1 QSV has a 1s seeking in his samples, means he uses a gop length of 60 (videos are 60 fps). VCE, Intel h264, x264 have a 10s seeking in his encoded videos. As for Intel h264 or h265 QSV a gop increase from 60 to 600 gop should improve the VMAF score by roughly 1 point.
And can vary quite a bit with content type.

Intel hardware AV1 performs really good at 3500 Kbit relative to the others in this test. It's a blocky mess in motion on NVENC or Intel h264. On higher bitrates Intel AV1 QSV detail preservation is quite poor, that's why it's losing relative to the others at higher bitrates.
I think we're looking at the graphs differently. I see QSV on 12900 HEVC beat all other contenders by a healthy margin in both 8-bit and 10-bit. It was also the slowest option, so not exactly apples-to-apples. For "quality" all HEVC and most H.264 options beat the Arc AV1; the one exception being 12900 H.264 FF. Some chunk of that is from the GOP duration mismatch, of course.

Or maybe I'm looking at the data weird. It seems ARC HEVC normal beats quality, which I would not expect.

Yups

12th August 2022, 17:24

I think we're looking at the graphs differently. I see QSV on 12900 HEVC beat all other contenders by a healthy margin in both 8-bit and 10-bit.

You just misread my posting. There is no HEVC comparison in the test made by EposVox. This part is not related to the rigaya test.

https://youtu.be/ctbTTRoqZsM

rwill

12th August 2022, 19:41

Intel's WORLD FIRST GPU AV1 encoder was worth the hype

https://youtu.be/ctbTTRoqZsM

Very good AV1 result from the Arc A380 in this test.

Are we looking at the same graphs ?

If I am looking at the ones at 11:50 I think, well, looks like Intel's GPU is getting beaten by a large margin compared to the Intel software encoder set to realtime mode. Also looks like H.264 cannot keep up at 3500k due to higher bitstream overhead but this normalizes out somewhat at 6000k. Only 3 sample points for a graph are suboptimal too, I'd have used 5+. Also keep in mind, H.264 is 20 years old and 1080p@60hz with 3500k comes out to ~1600k at 24hz for non motion blurred content.

Hardly what I would call 'worth the hype' but I made no flashy YouTube video about yet to deliver my opinion to my followers.

GTPVHD

16th August 2022, 16:13

https://www.asrock.com/Graphics-Card/Intel/Intel%20Arc%20A380%20Challenger%20ITX%206GB%20OC/index.us.asp
https://www.newegg.com/asrock-arc-a380-a380-cli-6g/p/N82E16814930076

Intel Arc A380 will be available soon in US, hopefully someone can test the AV1 hardware encoder.

GTPVHD

24th August 2022, 17:17

https://www.intel.com/content/www/us/en/newsroom/news/introducing-intel-data-center-gpu-flex-series.html

filler56789

25th August 2022, 21:09

I was bored :) so I built the SVT-AV1 encoder version 1.2.1.

NOTICE: running "svtav1encapp --version" returns

"SVT-AV1 v1.2.0 (release)" :confused:

But I tested the .EXE against a Version.avs file and it worked :-|

https://www.mediafire.com/file/h14la9bjqn96xrt/SVT-AV1-1.2.1.rar/file

benwaggoner

30th August 2022, 18:37

Are we looking at the same graphs ?

If I am looking at the ones at 11:50 I think, well, looks like Intel's GPU is getting beaten by a large margin compared to the Intel software encoder set to realtime mode. Also looks like H.264 cannot keep up at 3500k due to higher bitstream overhead but this normalizes out somewhat at 6000k. Only 3 sample points for a graph are suboptimal too, I'd have used 5+.
Yeah, the graph looks impressive, but its utility goes down the more one tries to get applicable information out of it.

Also keep in mind, H.264 is 20 years old and 1080p@60hz with 3500k comes out to ~1600k at 24hz for non motion blurred content.
Bitrate has a less-than-linear increase with frame rate, same as with frame size. With a higher frame rate less happens between frames, so individual frame predictions are more accurate. Also, any visual defect is visible for less time and so less noticeable. Also, as IDR placement is generally in seconds, not frames, higher frame rates mean a lower IDR percentage, which also improves efficiency.

Motion blur is a whole other matter. 60p stuff tends to have a 1/60th of a second shutter at the slowest, and can be much, much faster for daylight shoots. 24p, except for cell animation, almost always used a 1/48th of a second shutter. Generally more motion blur is helpful for encoding, although there are complexities that sometimes confound that.

My rule of thumb is that doubling the frame rate requires a 20-40% increase in bitrate, content dependent. If it's the same content (like encoding a 60p source at 60p and 30p), it's on the lower end of the range.

rwill

8th September 2022, 20:12

Motion blur is a whole other matter. 60p stuff tends to have a 1/60th of a second shutter at the slowest, and can be much, much faster for daylight shoots. 24p, except for cell animation, almost always used a 1/48th of a second shutter. Generally more motion blur is helpful for encoding, although there are complexities that sometimes confound that.

My rule of thumb is that doubling the frame rate requires a 20-40% increase in bitrate, content dependent. If it's the same content (like encoding a 60p source at 60p and 30p), it's on the lower end of the range.

Oops I did not see the reply.

I agree for normal shot content but the R/D graph I meant was for captured video game content. So most likely no motion blur + hard edges/contrast + small detail. My guess is that it requires a ~80% increase in rate to keep the same quality when doubling the frame rate. The only thing I can see it saving is motion vector length really.

LigH

10th September 2022, 11:21

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 12.2.0)

AOM v3.4.0-397-gaeee77c48 (https://www.mediafire.com/file/mqky45o1zqkpw7j/aom_v3.4.0-397-gaeee77c48.7z/file)

rav1e 0.5.1_g25f6c0f (https://www.mediafire.com/file/u1zg2zjxn6h2w1r/rav1e_0.5.1_g25f6c0f.7z/file) Clang 14.0.6

dav1d 1.0.0-61-g5247319 (https://www.mediafire.com/file/inr8lx8tgqn0xrg/dav1d_1.0.0-61-g5247319.7z/file)

SVT-AV1 v1.2.1-17-g470e1823 (https://www.mediafire.com/file/ubodoa4ieudfbjn/SVT-AV1_v1.2.1-17-g470e1823.7z/file)

avif 0.10.1_6624e76 (https://www.mediafire.com/file/8v8b9i38n3904w6/avif_0.10.1-6624e76.7z/file)
dav1d [dec]:1.0.0-61-g5247319, aom [enc/dec]:3.4.0-397-gaeee77c48, rav1e [enc]:0.5.0 (p20220906-3-g25f6c0f)

benwaggoner

16th September 2022, 18:06

Oops I did not see the reply.

I agree for normal shot content but the R/D graph I meant was for captured video game content. So most likely no motion blur + hard edges/contrast + small detail. My guess is that it requires a ~80% increase in rate to keep the same quality when doubling the frame rate. The only thing I can see it saving is motion vector length really.
That said, there can be a lot of static elements on-screen in a game, depending on the time. The HUD and GUI, for example. Also, since any temporal errors last only half as long when frame rate doubles, one can get away with somewhat higher QPs.

benwaggoner

16th September 2022, 18:09

I was a little surprised by how little discussion of AV1 there was at IBC this year. Support was mentioned here and there, but I certainly saw a lot more VVC demos, and discussion of real-world VVC products.

8K talk was also quite muted, and VR/AR wasn't as prominent either. Sustainability was talked about way more than ever before, as Europe faces a winter energy crisis due to Russia this winter.

GTPVHD

20th September 2022, 16:32

https://nvidianews.nvidia.com/news/nvidia-delivers-quantum-leap-in-performance-introduces-new-era-of-neural-rendering-with-geforce-rtx-40-series

Dual NVIDIA Encoders (NVENC) cut export times by up to half and feature AV1 support. The NVENC AV1 encode is being adopted by OBS, Blackmagic Design DaVinci Resolve, Discord and more.

https://www.nvidia.com/en-us/geforce/news/rtx-40-series-and-studio-updates-for-content-creation/

GeForce RTX 40 Series graphics cards feature our eighth generation NVIDIA video encoder, NVENC for short, now with support for AV1.

For livestreamers, the new AV1 encoder delivers 40% better efficiency. This means livestreams will appear as if bandwidth was increased by 40% — a big boost in image quality. AV1 also adds support for advanced features like high dynamic range.

https://developer.nvidia.com/nvidia-video-codec-sdk

Introducing AV1 encoding with Video Codec SDK 12.0 on NVIDIA’s Ada architecture. AV1 is the state of the art video coding format that supports higher quality with better performance compared to H.264 and HEVC. On Ada, multiple NVENC coupled with AV1 enables encoding 8k video at 60fps alongside a higher number of concurrent sessions.
For livestreamers, the new AV1 encoder delivers 40% better efficiency. This means livestreams will appear as if bandwidth was increased by 40% — a big boost in image quality. AV1 also adds support for advanced features like high dynamic range.

benwaggoner

20th September 2022, 18:13

https://nvidianews.nvidia.com/news/nvidia-delivers-quantum-leap-in-performance-introduces-new-era-of-neural-rendering-with-geforce-rtx-40-series

https://www.nvidia.com/en-us/geforce/news/rtx-40-series-and-studio-updates-for-content-creation/

https://developer.nvidia.com/nvidia-video-codec-sdk
Big news! Sounds like it has a lot of great stuff for gamers and content creators.

I wish claims like "For livestreamers, the new AV1 encoder delivers 40% better efficiency." would specify "compared to." ;)! If it is only 40% over AVC, that's a bit underwhelming. There's lots of good tools in AV1 for encoding game content that probably aren't being used by the hardware.

Yups

20th September 2022, 20:50

For livestreamers, the new AV1 encoder delivers 40% better efficiency.

It sounds like it's compared to h264 because livestreamers are using/have to use h264.

nevcairiel

21st September 2022, 06:49

benwaggoner

22nd September 2022, 01:20

The 40% is a comparison against H264 at 1080p, since that what majority of streaming is using right now, and what they hope to push AV1 into, since HEVC never took off in that space.

Higher resolutions would of course benefit more, but due to H264 still being prevalent there, it was not used often. Maybe that'll change when modern codecs take over?
I think H.264 remained the standard as it was the one universally compatible codec. Using anything else for upload means the ingest stream needs to be reencoded for some customers. Which can be a good thing if the reencode still looks better due to a higher quality source. More advanced codecs have tools not in H.264 that can really help for gaming style content. Variable partition sizes is big. Transform Skip can be a big help for really sharp lines and text. Tiles to break HUD from 3D viewport for faster encoding. SAO in HEVC can be very effective in reducing ringing from sharp details at high QP.

Of course streaming is a special use-case for encoding wanting extra low latency, which precludes some features, and hardware encoding also tends to avoid some features that are not well suited to hardware processing. But 40% improvements for streaming should still be quite nice.
And 40% would be just the start, I think.

Yups

22nd September 2022, 14:49

SSIM Comparison for Intel Arc A380 QSV
https://rigaya34589.blog.fc2.com/blog-entry-1501.html

Update with gop-ref-dist 4: https://twitter.com/rigaya34589/status/1572932789628186627

Quality is quite a bit better now.

Losko

23rd September 2022, 08:45

https://aomedia.googlesource.com/aom/+/refs/tags/v3.5.0

GTPVHD

27th September 2022, 19:01

https://www.intel.com/content/www/us/en/products/docs/arc-discrete-graphics/7.html
https://www.intel.com/content/www/us/en/products/sku/229151/intel-arc-a770-graphics-16gb/specifications.html
https://www.intel.com/content/www/us/en/products/sku/227955/intel-arc-a770-graphics-8gb/specifications.html
https://www.intel.com/content/www/us/en/products/sku/227954/intel-arc-a750-graphics/specifications.html

https://www.intel.com/content/www/us/en/products/docs/arc-discrete-graphics/3.html
https://www.intel.com/content/www/us/en/products/sku/227958/intel-arc-a310-graphics/specifications.html

Intel announced the Arc A770 and A750 today and quietly put the A310 specs on their website, all have AV1 hardware decoding and hardware encoding.

LigH

28th October 2022, 12:17

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 12.2.0)

AOM v3.5.0-341-g889f22f6b (https://www.mediafire.com/file/5vce6uvp7z71cgs/aom_v3.5.0-341-g889f22f6b.7z/file)

rav1e 0.6.0 g76cfbea (https://www.mediafire.com/file/kj3vvqwbx3h9hmp/rav1e_0.6.0_g76cfbea.7z/file) Clang 15.0.3

dav1d 1.0.0-86-g8a4932f (https://www.mediafire.com/file/qjfvaaefdsx6tfb/dav1d_1.0.0-86-g8a4932f.7z/file)

SVT-AV1 v1.3.0-g91b94efb (https://www.mediafire.com/file/nynzl6ol6qjsgn5/SVT-AV1_v1.3.0-g91b94efb.7z/file)

avif 0.11.1-6079987 (https://www.mediafire.com/file/tawzbn5xqk4phtj/avif_0.11.1-6079987.7z/file)
dav1d [dec]:1.0.0-85-g3e7886d, aom [enc/dec]:3.5.0-339-g208cec6c3, rav1e [enc]:0.6.0 (p20221025-1-g76cfbea)

GTPVHD

6th November 2022, 11:32

https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/5c288a44ad16087c3d3a7563490cb634790e751f

avcodec/nvenc: add AV1 encoding support

GTPVHD

10th November 2022, 09:52

https://developer.nvidia.com/nvidia-video-codec-sdk/download

Support for AV1 encoding on NVIDIA Ada Lovelace architecture.

LigH

28th November 2022, 18:52

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 12.2.0)

AOM v3.5.0-474-g39715dcbb (https://www.mediafire.com/file/0n8n6k29nt9wci9/aom_v3.5.0-474-g39715dcbb.7z/file)

rav1e 0.6.0 g33f359e (https://www.mediafire.com/file/md370zvoa6izxnh/rav1e_0.6.0_g33f359e.7z/file) Clang 15.0.5

dav1d 1.0.0-90-g4b9f5b7 (https://www.mediafire.com/file/l1fvssqtaczaas1/dav1d_1.0.0-90-g4b9f5b7.7z/file)

SVT-AV1 v1.3.0-47-g996b619f (https://www.mediafire.com/file/v6nuf1tbubqelhn/SVT-AV1_v1.3.0-47-g996b619f.7z/file)

avif 0.11.1-789b01b (https://www.mediafire.com/file/scczlwmzkd0m290/avif_0.11.1-789b01b.7z/file)
dav1d [dec]:1.0.0-90-g4b9f5b7, aom [enc/dec]:3.5.0-474-g39715dcbb, rav1e [enc]:0.6.0 (p20221123-1-g33f359e)

hajj_3

2nd December 2022, 15:49

SVT-AV1 v1.4.0: https://gitlab.com/AOMediaCodec/SVT-AV1/-/tags/v1.4.0

Jamaika

3rd December 2022, 16:28

libavif Version: 0.11.1 AVX (aom [enc]:3.5.0-77ef3a9, svt [enc]:1.4.0-5cca0f0)
libavif Version: 0.11.1 (dav1d [dec]:1.0.0-4b9f5b7, libgav1 [dec]:0.18.0, aom [dec]:3.5.0-77ef3a9)
libwebp2/webp/tiff->libavif/av1 Version: 0.11.1 AVX (aom [enc]:3.5.0-77ef3a9, svt [enc]:1.4.0-5cca0f0)
https://www.sendspace.com/file/vjgr0b

gosen11

4th December 2022, 16:00

Mod APK (https://relaxmodapk.com/)https://www.intel.com/content/www/us/en/newsroom/article/intel-arc-a380-graphics-available-china.html
https://www.intel.com/content/www/us/en/products/docs/arc-discrete-graphics/3.html
https://ark.intel.com/content/www/us/en/ark/products/227959/intel-arc-a380-graphics.html

Intel Arc A380 graphics card with AV1 hardware decoder and encoder officially launched.

Thanks for your kind info keep share with us.

Jamaika

11th December 2022, 13:02

problem with SIMD functions.
specialize qw/aom_masked_sad4x32x4d ssse3/;
c:/gcc1130/bin/../lib/gcc/x86_64-w64-mingw32/11.3.1/../../../../x86_64-w64-mingw32/bin/ld.exe: av1dsp\aom_dsp_rtcd.o:aom_dsp_rtcd.c:(.rdata$.refptr.aom_masked_sad4x32x4d_ssse3[.refptr.aom_masked_sad4x32x4d_ssse3]+0x0): undefined reference to `aom_masked_sad4x32x4d_ssse3'
c:/gcc1130/bin/../lib/gcc/x86_64-w64-mingw32/11.3.1/../../../../x86_64-w64-mingw32/bin/ld.exe: av1dsp\aom_dsp_rtcd.o:aom_dsp_rtcd.c:(.rdata$.refptr.aom_masked_sad4x32x4d_c[.refptr.aom_masked_sad4x32x4d_c]+0x0): undefined reference to `aom_masked_sad4x32x4d_c'
collect2.exe: error: ld returned 1 exit status

How to assign x3d functions?
specialize qw/aom_sad8x8x3d;
#define aom_sad8x8x3d aom_sad8x8x4d_c ???

benwaggoner

12th December 2022, 22:09

Yups

13th December 2022, 16:59

The new Radeon 7900 GPUs also support AV1 HW encoding. Has anyone had a chance to test the quality?

https://arstechnica.com/gadgets/2022/12/review-amds-radeon-rx-7900-gpus-are-great-4k-gaming-gpus-with-caveats/

I've not found anything online with any details about the encoder updates.

There is a OBS sneak peek here: https://youtu.be/HAc7BKnVD6Y?t=175

OBS however not the best for source video encodes, there are missing options affecting the quality.

BlueSwordM

13th December 2022, 21:38

For those not in the know, AMD's Navi 31 RDNA3 (7900XT and 7900XTX) AV1 HW encoder supports Profile 0 and Profile 1.
That means you can transcode in AV1 4:4:4 10-bit using an encoder that isn't aomenc or rav1e now.

Barough

15th December 2022, 14:34

AOM AV1 v3.5.0-620-g917568ca2
Built on December 22, 2022, GCC 12.2.0
https://www.mediafire.com/file/i0na2lgnat6vds2

dav1d v1.0.0-105-ged63a74
Built on December 15, 2022, GCC 12.2.0
https://www.mediafire.com/file/9bdu0582p2580us

rav1e v0.6.1 (p20221206-1-g9b74158)
Built on December 13, 2022, CLANG v15.0.4
https://www.mediafire.com/file/rm4zloi4d5miy6d

Jamaika

18th December 2022, 22:04

libavif 0.11.1.0-93035c1 / libwebp2avif b80553d / libheifavif 1.14.0.0-e886cb5 (aom v3.5.0-582d2fd, svt-av1 1.4.1-91832ee)
https://www.sendspace.com/file/gpm9pr

Yups

21st December 2022, 00:35

The new Radeon 7900 GPUs also support AV1 HW encoding. Has anyone had a chance to test the quality?

https://arstechnica.com/gadgets/2022/12/review-amds-radeon-rx-7900-gpus-are-great-4k-gaming-gpus-with-caveats/

I've not found anything online with any details about the encoder updates.

Rigaya tested AV1 quality 10 bit with one sample and VMAF+SSIM metrics:

https://rigaya34589.blog.fc2.com/blog-entry-1607.html

In this it's worse than Nvidia+Intel.....and slower.

James_b

23rd December 2022, 12:13

LigH

23rd December 2022, 13:07

Because it requires a lot more encoding efforts, will usually take longer than x265 with comparable options. And decoding is more demanding as well, so it's harder to play UHD in real time without enough CPU power or GPU support.

BlueSwordM

23rd December 2022, 18:07

Regarding AV1
Does anyone know why this encoder is not more common? it is not in any of my programs by default and as far as I know it should be able to give the same image as hevc but with almost half the size. Fantastic in my opinion, who always export everything with max quality. :thanks:

There actually is an interesting reason for why aside from the usual encoding speed reasons, HW decoding support(for DRM purposes) and MPEG inertia: current encoders don't have deep psycho-visual pipelines outside of a few specific cases.

That means you can't use AV1 encoders to completely replace all use cases of previous most used encoders(x264, x265).

Jamaika

7th January 2023, 18:57

GCC 11.3.1 20221229 without _GLIBCXX_HAS_GTHREADS,
libavif 0.11.1.0-93035c1 / libwebp2avif b80553d (aom v3.5.0-305db30, svt-av1 1.4.1-91832ee)
https://www.sendspace.com/file/l0acha

foxyshadis

16th January 2023, 14:51

benwaggoner

17th January 2023, 19:07

There actually is an interesting reason for why aside from the usual encoding speed reasons, HW decoding support(for DRM purposes) and MPEG inertia: current encoders don't have deep psycho-visual pipelines outside of a few specific cases.

That means you can't use AV1 encoders to completely replace all use cases of previous most used encoders(x264, x265).
x264 was very unique in encoder history. It was the first broadly-used open source encoder, written and optimized by many eyeballs in the piracy scene. No encoder ever had a fraction of the test corpus or focus on real-world scenarios like x264 had, resulting in some decade-ahead-of-its-time psychovisual optimizations. One other encoder vendors saw what x264 could do, they could they reverse engineer from it. x265 inherited that psychovisual foundation, which other HEVC vendors were also able to reverse engineer from.

Porting those algorithms to an VPx derived codec was not straightforward due to some fundamental differences in how the codecs worked (the downside of all the oddnesses of that series to get around existing patents). Some of the learnings from x264 are applicable and have been applied, but others don't have a direct equivalent.

So a lot of work will need to get done over that, say, VVC, can inherit a lot more of.

nhw_pulsar

17th January 2023, 20:54

benwaggoner

17th January 2023, 22:14

Compression bodies final goal/quest seems to ever and ever increase PSNR/SSIM, they seem to figure out that if you increase PSNR for example of +0.5dB then you automatically increase visual quality, but I also think that if you make psychovisual development, you can decrease PSNR of -0.5dB or more but you'll have an even better visual quality.

(Disclaimer: I speak for image compression, and I am tired that experts told me that my work is bad because it has bad PSNR...)
I think the thought is that if you have good PSNR, you can add psychovisual tweaks easily enough. But if you can't do good PSNR as a baseline, it'd be hard to make psychovisual optimizations catch up. Which is sorta kinda true, with lots of caveats.

For example, the codec needs to have well-tuned features to enable that kind of psychovisual optimization. It's easy to have some promising-sounding features to improve psychovisually, but they need to be really tested at tuned to make sure they work well.

My classic example of a failure of this is VC-1 adaptive quantization. Like a lot of things, adaptive quantization in VC-1 is handled by a RLE bitmask. Each frame has a frame QP, and then any offset from the frame QP is handled as a PCM. 0 is same a frame QP, -2 would be two lower, +3 would be three higher. Then that gets run length encoded, imagining that there would be long runs of 0. But in a case where every macroblock gets its own QP, there's no RLE, and one can easily wind up with 4 bits of overhead per macro block. A 1080p frame has 8100 macro blocks, which would be about 4 Kbps per frame. 1080p60 could have up to 240 Kbps of QP offset, which can be enough that just using a fixed frame QP would result in better quality on net. It didn't matter for a VC-1 HD DVD or Blu-ray, but sure could at then-web bitrates.

So you wound up with tricks like using Adaptive Quant on just I frames, and never on B frames. Or adaptive quant algorithms that minimize QP variations below what would be psychovisually optimal in order to get better improvements on net. And there never was a VC-1 encoder that included all the best tools, so different encoder implementations got used for different use cases. It was a mess.

nhw_pulsar

17th January 2023, 22:43

I think the thought is that if you have good PSNR, you can add psychovisual tweaks easily enough. But if you can't do good PSNR as a baseline, it'd be hard to make psychovisual optimizations catch up. Which is sorta kinda true, with lots of caveats.

Ok, you're certainly right.But personally I only develop for visual quality from the start and I don't use PSNR at all... to the point that I think I have invented the anti-PSNR codec..., that has extremely low PSNR but very better visual quality than it however suggests...

Cheers,
Raphael

foxyshadis

18th January 2023, 00:06

Emulgator

18th January 2023, 02:28

benwaggoner

18th January 2023, 20:40

VC-1...Good work and I still value it. The VC-1 blu-rays I have dont fall behind their AVC counterparts.
Just for fun I installed Silverlight and encoded under a slightly starving scenario (50% of what would be appropriate):
A normally grainy 213Mbps M8Y0 FHD restored Film source (playing duration 1h48m)
into a 15Mbps VC-1 Blu-ray Stream, 12,3GB, so 1/2 BD-25. Parameters all-in, no shortcuts allowed.
Took quite long, like 6x realtime, very well threaded, saturated all cores of i9-11900K 100%.
Quality awesome, the minor compression artifacts were slightly increased grain patches,
eye-friendly and only to spot if I stopped and pixelpeeped the frame.
The VC-1 PEP/CineVision PSE (sic?) toolchain was really good for it's time. The Adaptive Quant overhead issue wasn't that material; only about ~100 Kbps for 24p with ABR >15 Mbps. VC-1 had a quite advanced adaptive deadzone algorithm for its time, in part to get similar value to adaptive quant without the signaling overhead. HD DVD was limited to 14 frame GOPs, so there was a lot of smartness around I-frame placement and rate control. Blu-ray was a lot easier, with 24 frame GOPs and 40 Mbps peak.

The xscalar utility provided with the tools was also a big boost to the whole product. It supported excellent and configurable dithering modes back when truncation was the default. This really helped prevent banding with the 8-bit only Blu-ray. I'd say xscalar was the single biggest reason VC-1 discs often looked better than H.264 discs in the early days.

XScaler was written by Spears and Munsil (http://spearsandmunsil.com), later purveyors of fine video test materials.

nhw_pulsar

20th January 2023, 21:24

VMAF has taken over as the base metric for all major tool decisions, with PSNR relegated micro-optimizations of internal decisions (like selecting the best of a bunch of similar candidate blocks for the motion vector) because that's where it actually works. It took Netflix's clout to change old engineering attitudes. VMAF is still not perfect, it has its own severe failure modes, but it's at least a lot less imperfect than PSNR for overall picture perception.

Hi @foxyshadis,

Thank you for your information.This confirmed what I noticed recently, as I downloaded the latest build of AVIF and compared it to a previous version from 5/6 months ago.I quickly tested and measured on 5 images and apparently it seems that the last version has worse PSNR, but better visual quality.I was still however surprised that AOM published a new version with worse PSNR, but thank you for letting me know that they develop for VMAF, hence the visual quality improvement despite PSNR drop.

When you say VMAF has become the reference metric in the industry, you speak for AOMedia? Because it seems that MPEG with VVC, ECM for example, still develop for PSNR?

benwaggoner

21st January 2023, 00:25

When you say VMAF has become the reference metric in the industry, you speak for AOMedia? Because it seems that MPEG with VVC, ECM for example, still develop for PSNR?
I see VMAF used a lot in encode tuning (picking the right encoder settings), some in encoder development (implementation of a given codec), and not much in codec development itself.

VMAF really isn't an "objective metric" in the classic sense. VMAF is a collection of machine learning models trained to predict subjective ratings using ground truth of a bunch of x264 encoded variations. The training data is a set of simple objective metrics paired with the objective scores for clips with those values.

Thus there is no "one right way" to calculate VMAF like there is like PSNR and SSIM. There have been many different versions of the models, and there are different ones for different output resolutions. So the same file could have substantially different VMAF scores depending on which VMAF version is being used, and which model of each version has been selected.

Also, VMAF is only as accurate as the training data. It hasn't been trained on still images or HDR content or VVC style motion artifacts or AV1 grain sythesis, so it's more luck than a natural property if it winds up being a useful metric for those out-of-scenario uses.

Which is why I get really nervous about tools being overly tuned towards VMAF, because VMAF absolutely has areas it's not good at. For example, it only looks at luma, not chroma, so content could have U and V flipped and still get a good VMAF score! A fully automated encoder tuning using just VMAF would naturally jack chroma QPs up to the maximum to lower luma QP a little, for a much worse subjective experience.

I've seen other in-development metrics approach that combine bitstream analysis and full reference to provide much higher correlation to subjective quality than VMAF, especially for HDR, so VMAF isn't some sort of theoretical maximum. It was revolutionary and the least-bad metric we'd had to date.

Jamaika

21st January 2023, 11:48

nhw_pulsar

21st January 2023, 20:09

It hasn't been trained on still images or HDR content or VVC style motion artifacts or AV1 grain synthesis

As I am only trained on still image artifacts, I am rather fascinated by people who talk about motion artifacts, as I have no knowledge on it.

So VVC has its own style of motion artifacts? If you have time, could you or another expert let us know if VVC style motion artifacts are visually more pleasant than AV1 motion artifacts for example?

Cheers,
Raphael

benwaggoner

23rd January 2023, 03:58

As I am only trained on still image artifacts, I am rather fascinated by people who talk about motion artifacts, as I have no knowledge on it.

So VVC has its own style of motion artifacts? If you have time, could you or another expert let us know if VVC style motion artifacts are visually more pleasant than AV1 motion artifacts for example?
VVC has some really great tools to keep high QP inter prediction from revealing underlying block structure, which keeps highly compressed motion looking a lot more natural.

AV1 has some nice features in the same area as well, which provide good visible benefits at high compression ratios. I've not compared AV1 and VVC them in depth in this regard. It's kind of hard to separate any one tool out of the general codec and encoder alchemy*. Bit-for-bit, VVC is clearly a stronger codec than either AV1 or HEVC, although the ecosystem is still 1-2 years from broad deployment.

*A good 20+ years ago Touradj Ebrahimi told me that making a codec is "10% science, 20% alchemy, and 70% SUN worship."

In that we start with some good theory about how to get improvements with new tools, kind of mash them together in different ways and see what seems to work, and then simulate the heck of it to tune quant tables and symbols for optimum entropy coding and all that.

Obviously, that was from a post MPEG-4 part 2, pre H.264, SPARC for high performance compute era. But still some deep truths in there. Today it'd be machine learning instead of SUN worship.

megalol

29th January 2023, 10:49

GCC 11.3.1 20221229 without _GLIBCXX_HAS_GTHREADS, SIMD AVX
libavif 0.11.1.0-62f8095 / libwebp-->avif b80553d (aom v3.5.0-9c91575, svt-av1 1.4.1-ad82cde) / libheif-->avif 96a114f (aom v3.5.0-9c91575, svt-av1 1.4.1-ad82cde)
https://www.sendspace.com/file/4kd4ud
Hi, thanks, useful tools but its has very big problem that converted to avif webp images with av1enc_avx.exe looks much darker (tried with older version posted here also and different settings). If I do the same with libvips or imagemagick for example then it has the same brightness.

foxyshadis

30th January 2023, 09:39

Hi, thanks, useful tools but its has very big problem that converted to avif webp images with av1enc_avx.exe looks much darker (tried with older version posted here also and different settings). If I do the same with libvips or imagemagick for example then it has the same brightness.

av1enc is a gstreamer test application that assumes a number of properties that often don't apply to images. If you think it should, report the error to gstreamer. (But I'm pretty sure I've seen this in their tracker.) I wouldn't touch it with a six-foot pole for avif, even if it's great for streaming and playback.

avifenc or heifenc are proper image encoders that offer the full suite of detection and override options. libvips and ImageMagick both use libheif, though in a different way than these command-line tools.

megalol

30th January 2023, 11:13

av1enc is a gstreamer test application that assumes a number of properties that often don't apply to images. If you think it should, report the error to gstreamer. (But I'm pretty sure I've seen this in their tracker.) I wouldn't touch it with a six-foot pole for avif, even if it's great for streaming and playback.

avifenc or heifenc are proper image encoders that offer the full suite of detection and override options. libvips and ImageMagick both use libheif, though in a different way than these command-line tools.
I wouldn't use av1enc either if there would be direct webp->avif support in avifenc because I agree that its best tool for avif.

LigH

23rd February 2023, 01:01

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 12.2.0)

AOM _v3.6.0-252-gdfbaa9891 (https://www.mediafire.com/file/ymur3t2t2nwdwxp/aom_v3.6.0-252-gdfbaa9891.7z/file)

rav1e 0.6.1-4-gf178e97 (https://www.mediafire.com/file/mnb3e0bkjfpf421/rav1e_0.6.1-4-gf178e97.7z/file)

dav1d 1.1.0-0-g9593e62 (https://www.mediafire.com/file/tytfd8cs8ncj7mk/dav1d_1.1.0-0-g9593e62.7z/file)

SVT-AV1 v1.4.1-79-gaef9ee9e (https://www.mediafire.com/file/an357kp5ddgg9uv/SVT-AV1_v1.4.1-79-gaef9ee9e.7z/file)

avif 0.11.1-86d66f0 (https://www.mediafire.com/file/mbd892t3npiuxyw/avif_0.11.1-86d66f0.7z/file)
dav1d [dec]:1.1.0-0-g9593e62, aom [enc/dec]:3.6.0-252-gdfbaa9891, rav1e [enc]:0.6.1 (p20230214-4-gf178e97)

hajj_3

29th March 2023, 08:46

Youtube is adding AV1 livestream uploading using RTMP+ - https://www.tomshardware.com/news/av1-live-streaming-is-finally-coming-to-youtube

FranceBB

2nd April 2023, 00:33

Eh, for streamers, not for those who actually watch those streams, which is my use case... :(
This means that although you'll be able to stream in AV1 and save some bitrate yourself instead of streaming in H.264, unfortunately YouTube will still re-encode to VP9...
In other words, although it's a good thing for streamers, it's not really going to affect viewers that much... at least not in my use case.
This is because my use case is pretty peculiar: we stream a 20 Mbit/s H.264 FULL HD 25p 8bit live feed containing news which Google re-encodes to a crappy low bitrate VP9, thus nullifying the whole thing.
I'm sure this is the case for plenty of other news broadcasters who picked YouTube to stream their contents for free.
What I'd like to see is AV1 actually being served to viewers in live streams so that they'll be able to enjoy a much better quality.
Anyway, allowing streamers to actually stream in AV1 is a first step...

The only side-effect of YouTube's implementation is that videos will still get transcoded to VP9. This means AV1 live streams will be re-coded to YouTube's VP9 codec.

birdie

2nd April 2023, 14:03

FranceBB

3rd April 2023, 08:22

YouTube's offline VP9 encoder is actually really good but the one they use for streaming is outright horrible. Dunno why.

Ah, so it wasn't just me and my eyes. Thanks for confirming.
It's a shame, really... :(

benwaggoner

3rd April 2023, 17:39

YouTube's offline VP9 encoder is actually really good but the one they use for streaming is outright horrible. Dunno why.
Real-time encoding has real-time requirements. They can't use the "split the source up across lots of temporarily idle Google servers" tactic, but dedicate fixed compute for the duration of the session. If low latency is also a goal, that can limit use of lookahead and out-of-order encoding. High quality live encoding requires a lot of dedicated fast cores, so the stream needs to have enough revenue potential to make up for the much higher $/minute costs, and those costs go up quickly with better quality. The VP9 encoders never had that great multithreading, so that can also limit best results.

Real professional-grade live transcoding can get expensive quickly: https://aws.amazon.com/medialive/pricing/.

birdie

3rd April 2023, 17:49

Real-time encoding has real-time requirements. They can't use the "split the source up across lots of temporarily idle Google servers" tactic, but dedicate fixed compute for the duration of the session. If low latency is also a goal, that can limit use of lookahead and out-of-order encoding. High quality live encoding requires a lot of dedicated fast cores, so the stream needs to have enough revenue potential to make up for the much higher $/minute costs, and those costs go up quickly with better quality. The VP9 encoders never had that great multithreading, so that can also limit best results.

Real professional-grade live transcoding can get expensive quickly: https://aws.amazon.com/medialive/pricing/.

That makes a lot of sense, thanks. AV1 is also very hard to parallelize (unless as you said encoding chunks of video separately offline), and I wonder why after VP9 Google did not address this major shortcoming. It seemingly bit them in the buttocks.

benwaggoner

3rd April 2023, 18:24

That makes a lot of sense, thanks. AV1 is also very hard to parallelize (unless as you said encoding chunks of video separately offline), and I wonder why after VP9 Google did not address this major shortcoming. It seemingly bit them in the buttocks.
VP9 was mostly on YouTube, where they did single-threaded encoding of short chunks distributed on otherwise idle Google cloud instances. That mode is all about throughput per watt, which single-threaded encoding is best at. Live is all about throughput per minute, so multithreading is really important.

VP9 was particularly poor for multithreading as frame encoding and decoding were (accidentally, I gather) serialized due to how in-loop filtering was structured. Shared entropy coding context across frames also limited decoder threading. VP9 was definitely a codec designed to run on a fast x86-64 core without a lot of consideration for multithreaded hardware or software implementations. AV1 is somewhat better, but is still more complex to decode than even VVC.

HEVC's Wavefront Parallel Processing is great and elegant, allowing for one thread per 64 pixels tall of the video. WPP yields better compression efficiency than slices, tiles, and frame threading. The more traditional IPBb reference frame hierarchy of H.264 and HEVC makes for more straightforward frame threading, although there is always some risk of quality regressions.
Some frame threading is feasible in AV1 doing tricks with golden frames. SVT-AV1 is a good demonstration of an AV1 encoder that can do a lot of threading (although quality isn't great). It'd be interesting to compare SVT-HEVC and SVT-AV1's parallelization.

Fragment/GOP level threading has challenges due to higher latency and making sure VBV state is compliant across fragment boundaries. But the encoders are well optimized for that as that's YouTube's primary encoding model.

I hope AV2 focuses more on architectural support for highly parallelized encoding and decoding.

Beelzebubu

4th April 2023, 12:12

AV1 is also very hard to parallelize

This statement is unsupported by facts. SVT-AV1 for encoding and dav1d for decoding demonstrate the opposite.

Beelzebubu

4th April 2023, 12:25

frame encoding and decoding were (accidentally, I gather) serialized due to how in-loop filtering was structured.

It's just how big the deblock filter is in VP9: writing 7 pixels on each side, making the luma delay 7+64 lines, but because downsampled chroma has the same filter length, it has the same delay (i.e. 7+32 lines in memory), the ultimate delay is 14+64=80 lines. In AV1, the line buffer is 8+128=136 (luma) lines (or 4+64 for downsampled chroma). Note that this is not less than VP9. HEVC is only a few lines better than VP9 in this respect, and VVC is no different from AV1.

Shared entropy coding context across frames also limited decoder threading.

... but can be disabled by setting the frame-parallel bit in the header, and helps several percent (!!) in compression efficiency when enabled. In fact, this "tool" was (from what I hear) proposed for HEVC - but rejected. I can't comprehend why, and have heard similar (depressed) comments about this feature from other HEVC/MPEG contributing members. It should have made it in.

birdie

4th April 2023, 17:59

This statement is unsupported by facts. SVT-AV1 for encoding and dav1d for decoding demonstrate the opposite.

And SVT-AV1 is nowhere near close to libaom (almost single-threaded) in terms of quality. Right.

benwaggoner

4th April 2023, 19:51

... but can be disabled by setting the frame-parallel bit in the header, and helps several percent (!!) in compression efficiency when enabled. In fact, this "tool" was (from what I hear) proposed for HEVC - but rejected. I can't comprehend why, and have heard similar (depressed) comments about this feature from other HEVC/MPEG contributing members. It should have made it in.
IIRC it made the decoders too complex, and added a lot of latency for random access. It's also something that mostly helped with easy to encode content while not helping hard content much which improvements are most valuable.
I believe a feature like that could be architected in a way that doesn't cause those issues (only follow context of frames that need to be referenced to decode the given frame anyway).

takla

5th April 2023, 00:54

Eh, for streamers, not for those who actually watch those streams, which is my use case... :(
This means that although you'll be able to stream in AV1 and save some bitrate yourself instead of streaming in H.264, unfortunately YouTube will still re-encode to VP9...
In other words, although it's a good thing for streamers, it's not really going to affect viewers that much... at least not in my use case.
This is because my use case is pretty peculiar: we stream a 20 Mbit/s H.264 FULL HD 25p 8bit live feed containing news which Google re-encodes to a crappy low bitrate VP9, thus nullifying the whole thing.
I'm sure this is the case for plenty of other news broadcasters who picked YouTube to stream their contents for free.
What I'd like to see is AV1 actually being served to viewers in live streams so that they'll be able to enjoy a much better quality.
Anyway, allowing streamers to actually stream in AV1 is a first step...

I seriously hate how youtube re-encodes all videos. I really wish they'd have an option that leaves the video as is. I understand that they do this for bandwidth savings, obviously, but they could simply have strict bitrate requirements in place and probe the stream...

YouTube's offline VP9 encoder is actually really good but the one they use for streaming is outright horrible. Dunno why.

You can pick 1 of 3 speed settings in the youtube streamer dashboard. The setting with the highest delay offers the 'best' image quality. By default it is set to low latency, which is worse but most people don't change it.

RanmaCanada

5th April 2023, 22:55

This statement is unsupported by facts. SVT-AV1 for encoding and dav1d for decoding demonstrate the opposite.

SVT-AV1 is garbage. No matter how many times I try to use anything but, I can't get it to work with multi-threading and it just uses 1 core (SVT-AV1 is the only encoder that uses all my cores, for clarity). This shows just how broken the codec is. I've argued with bluesword a lot over this and the only answers I ever get is "use these" never "this is why it's a single threaded encoder".

There is far too much gatekeeping on the documentation, and far too much "why isn't this working".

If they really want this to take over HEVC and in the future VVC, things need to fixed and addressed. Blindly defending it without addressing it's massive shortcomings and serious problems won't make it any better.

hajj_3

6th April 2023, 13:49

I seriously hate how youtube re-encodes all videos. I really wish they'd have an option that leaves the video as is.
recently youtube has been testing a high bitrate 1080p setting option.

Beelzebubu

6th April 2023, 14:55

IIRC it made the decoders too complex, and added a lot of latency for random access.
[..]
I believe a feature like that could be architected in a way that doesn't cause those issues (only follow context of frames that need to be referenced to decode the given frame anyway).

Ah, yes! The random access argument is interesting, and I'd very much agree with the second sentence. I've used the following argument before: I think we'd both agree entropy dependency vs. seeking is essentially an identical problem to actual pixel dependencies from reference structures vs. seeking. The fact that MPEG allows pixel dependencies in complex frame ordering structures (a.k.a. inter frame coding) and knows how to seek bit-exactly and efficiently in it demonstrates how easily the entropy can be solved, too. Because: it is the same problem.

Maybe part of the problem is that MPEG folks tend to like formalizing rules for this sort of stuff and picking at theoretical inconsistencies. I personally find that quite uninteresting once the problem itself is already solved.

It's also something that mostly helped with easy to encode content while not helping hard content much which improvements are most valuable.

I don't believe it's quite that simple. Whether content is "simple" or "hard", entropy is typically quite correlated over time. You're right that after entropy convergence, you're still spending bits on the actual signal, but at least entropy is optimal coming in to each frame. Therefore, you'll get gains across the board.

To get more practical, I compared --frame-parallel=0/1 encodes at -q 30/40/50/60 to obtain BDRATE-PSNR differences, and observed a -2.5% average difference on the cif clipset (https://media.xiph.org/video/derf/) from Xiph. These were only partially complexity-ordered. Husky, for example, gained "only" -1.0% on average, but football, soccer, foreman & harbour each gained -2.5%. Same on the easy end: clips like akiyo an students are "only" -2.0% each, whereas news and bowing are -2.5%. The best clips (around -4.0% each) are bridge_far, crew, sign_irene and highway, which are by no means the easiest clips in the set. I also checked for "bitrate" bias: gains are quite evenly distributed across all -q values for each clip.

Based on this data, I don't accept the hypothesis that entropy carry-over between frames only help easy clips.

birdie

6th April 2023, 16:30

recently youtube has been testing a high bitrate 1080p setting option.

Lossy (re-)encoding always deceases quality. Period. Are you new to audio/video encoding?

dapperdan

6th April 2023, 16:53

https://www.anandtech.com/show/18805/amd-announces-alveo-ma35d-media-accelerator-av1-video-encode-at-1w-per-stream

Xilinx based hardware encode for servers from AMD now supporting AV1.

benwaggoner

6th April 2023, 17:06

Based on this data, I don't accept the hypothesis that entropy carry-over between frames only help easy clips.
Yes, I concur interframe entropy coding, properly structured, is definitely of value. I was trying to recapitulate the original MPEG thinking as I recalled it, not justify it.

hajj_3

6th April 2023, 19:48

https://www.anandtech.com/show/18805/amd-announces-alveo-ma35d-media-accelerator-av1-video-encode-at-1w-per-stream

Xilinx based hardware encode for servers from AMD now supporting AV1.

quality sounds great:

https://i.imgur.com/KVzQFmP.png

benwaggoner

6th April 2023, 20:39

quality sounds great:
It is weird they are comparing to H.264 Baseline VeryFast, which is a lot faster than realtime these days. I presume the relative savings would be a lot lower compared to real world encodes.
Matching x265 slow with high density hardware encoding with AV1 is really impressive. High quality live AV1 has been a challenge so far.

Blue_MiSfit

7th April 2023, 18:47

Matching x265 slow with high density hardware encoding with AV1 is really impressive. High quality live AV1 has been a challenge so far.

QFT. I've been impressed with how much better NVENV AV1 is relative to NVENC HEVC, but it's still maybe only close to fast x265 presets. Great for what it is, but that's NOT the same as ~matching x265 slow at 1W per stream. If that's to be believed it's bonkers good. Fabulous for live ABR encoding!

I could see this being popular in the cloud IaaS providers soon. It would _smoke_ the older NVIDIA hardware that's usually available there e.g. Ampere in AWS g5 instances.

benwaggoner

8th April 2023, 01:25

Ayumu111

25th April 2023, 09:22

Premium quality ABR live streaming still requires a whole lot of fast cores. I doubt we'll ever see a fixed-function hardware encoder be quality-competitive again, given the ever-rising complexity of modern codecs.
I concur with Ben that high-quality adaptive bitrate (ABR) live streaming requires powerful hardware to attain high-quality compression. As codec standards and standards become increasingly complex, hardware encoders may find it difficult to keep up. Software-based streaming solutions that leverage the power of fast core processors will continue to be the preferred method for high-quality live streaming.

Spyros

13th June 2023, 14:15

The AOMedia Research Workshop Europe 2023 will take place in a few days (June 19th), in Ghent, Belgium.

The conference program is in the image below, more details about each presentation can be found at the official website (https://sites.google.com/view/qomex2023/workshops/aomedia-research-workshop-europe-2023).

The focus seems to be on AV2 and a retrospective of AV1 development and the technologies that were used in it.

https://i.imgur.com/Fgd9mdY.png

nisha_gomes

14th July 2023, 15:51

It is weird they are comparing to H.264 Baseline VeryFast, which is a lot faster than realtime these days. I presume the relative savings would be a lot lower compared to real world encodes. (https://aeroapp.net/fmwhatsapp-download-apk/)
Matching x265 slow with high density hardware encoding with AV1 is really impressive. High quality live AV1 has been a challenge so far.

The progress in comparing AV1 with highly efficient encoding methods like H.264 Baseline VeryFast and x265 slow is impressive, especially considering the historical challenges in achieving high-quality live AV1 encoding.

LigH

17th July 2023, 22:07

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 13.1.0)

AOM v3.6.1-843-g93ca91b96 (https://www.mediafire.com/file/c9umcoe48zwg4ni/aom_v3.6.1-843-g93ca91b96.7z/file)

rav1e 0.6.1 p20230711-1-g2447fcc (https://www.mediafire.com/file/flmjlxalvwwbn6n/rav1e_0.6.1_p20230711-1-g2447fcc.7z/file)

dav1d 1.2.1-43-g9278a14 (https://www.mediafire.com/file/iw9rxno50123621/dav1d_1.2.1-43-g9278a14.7z/file)

SVT-AV1 v1.6.0-2-gba18204e (https://www.mediafire.com/file/qthhdy89die1rv1/SVT-AV1_v1.6.0-2-gba18204e.7z/file)

avif 0.11.1-41ed914 (https://www.mediafire.com/file/jgfpe95o0v7zvdi/avif_0.11.1-41ed914.7z/file)
dav1d [dec]:1.2.1-43-g9278a14, aom [enc/dec]:3.6.1-842-gff3c4c8a6, rav1e [enc]:0.6.1 (p20230711-1-g2447fcc)

mzso

2nd August 2023, 14:58

Hi!
Is Youtube still the only notable user of AV1 nowadays?

butterw2

2nd August 2023, 15:20

Just like VP9 ?

mzso

2nd August 2023, 16:06

Just like VP9 ?

Not sure how that's relevant.

benwaggoner

2nd August 2023, 20:05

Not sure how that's relevant.
It is historically relevant, as YouTube has been the primary user and driver of VP8, 9, and 10/AV1. VP8 and VP9 were really limited by the reference/sample encoder being highly tuned for YouTube scenarios and not well suited for for other use cases, like highly parallelized encoding of premium content. That caused some chicken/egg problems that prevented VP9 from getting encoders nearly as refined as those for H.264 and HEVC. I don't think VP9 as a bitstream could have outperformed HEVC in real-world applications, but VP9 encoders weren't able to capture as much of the potential of the bitstream as H.264 and HEVC encoders have, as the market for those commercial encoders is orders of magnitude higher.

For example, VP8/9 had very serialized decoding and limited on encoding. Which was fine for YouTube, which encodes in little slices of times on lots of different edge compute nodes as available. But premium content where time-to-publish is essential and encoding 3x more slowly to reduce bitrate by 10% is excellent ROI, it's a big limitation. And when secure DRM is a hard requirement and dropped frames cause cancelled subscriptions or purchase/rental refunds, having reliably fast decoders, preferably HW, are much more important.

While user generated content gets a lot of eyeball hours, the economic value of improved quality and speed/efficiency tradeoffs are very different, and the $/hour invested are a tiny fraction of what premium content gets.

AV1 has a much healthier ecosystem than any prior VPx version (going back to VP3 even), with more and better encoders available. So it's a compare and contrast.

CodecWar

3rd August 2023, 22:28

Hello! Today, I bring some exciting news about the AV2 codec developed by the AVM team. As many of you might be aware, AV2 is the successor to AV1 and aims to provide even better video compression and quality. In this post, I'll be discussing the recent advancements in AV2 and how it compares to its predecessor, AV1.

Active Development of AV2 Codec:
The AVM team has been hard at work, continuously refining the AV2 codec to enhance its performance. Over the last couple of years, they have released several research tags to showcase their progress. In August 2021, the research2 tag was unveiled, followed by research3 in May 2022, and research4 in April 2023.

Comparative Analysis on AOM AV2 CTC Streaming Classes:
Recently, a comprehensive report was published that compared the performance of these three AV2 implementations on AOM AV2 CTC Streaming classes, namely A5, A4, A3, and A2, focusing on resolutions up to FullHD. The objective was to evaluate the quality metrics of PSNR (Peak Signal-to-Noise Ratio), VMAF (Video Multi-Method Assessment Fusion), and SSIM (Structural Similarity Index) for the different research releases.

Steady Quality Improvements:
The results of the study were nothing short of impressive. Across all quality metrics, there was a consistent improvement as the research progressed from version 2 to version 4. For example, the PSNR: Y (luma) with BD-Rate data aggregation showed a remarkable 8.76% improvement between research3 and research4. This demonstrates the commitment of the AVM team to refining their codec and pushing the boundaries of video compression technology.

Spread and Variance:
It's important to note that while the best and worst results also improved with each iteration, the spread and variance between different video streams increased. This suggests that the AV2 codec is becoming more specialized in handling certain types of video content optimally.

Conclusions from the Study:
Based on the findings of this study, some significant conclusions were drawn:

On average, the AOM_post-AV1 (research 3 released in 2022 ) codec showed an 8.76% improvement over the AOM_post-AV1(research 2 released in 2021) reference codec across all video streams.
Comparing the average performance on all video streams, the AOM_post-AV1 (research 4 - Apr23) codec outperformed the AOM_post-AV1 (research 3 - 2022) reference codec by an impressive 15.15%.
In summary, the AV2 codec is showing immense promise and dedication from the AVM team. As the development progresses, it is evident that AV2 is significantly surpassing its predecessor, AV1, in terms of video quality and compression efficiency. However, with the increasing specialization, the codec might perform differently depending on the content being encoded.

It's an exciting time for video compression enthusiasts, and we can't wait to see how AV2 evolves further. Feel free to share your thoughts and insights in the comments below! Let's discuss the future of video codecs together.

Source: https://codecwar.com/compare/av2-research-evolution

benwaggoner

4th August 2023, 22:30

If all we are seeing on net is a 15.15% efficiency improvement, that is very overwhelming. A new codec needs a plausible path to around a 100% efficiency improvement (same quality, half the bitrate) to displace a prior one, or needs to add a substantial and compelling new feature (like broadcast-grade interlaced SD and HD video for MPEG-2, HDR for HEVC). 15% over AV1 is still a lot worse compared to VVC, which will have HW decoders shipping in products by end of 2023. It's also lower than the delta from VVC to current post-VVC test implementations from MPEG.

hajj_3

5th August 2023, 14:10

If all we are seeing on net is a 15.15% efficiency improvement, that is very overwhelming.

*underwhelming. AV2 isn't being ratified right now, so i wouldn't pay much attention that it is only 15% better. In a year i'm sure it will be more than that.

Beelzebubu

6th August 2023, 13:39

On average, the AOM_post-AV1 codec showed an 8.76% improvement over the AOM_post-AV1 reference codec across all video streams.
Comparing the average performance on all video streams, the AOM_post-AV1 codec outperformed the AOM_post-AV1 reference codec by an impressive 15.15%.

So X outperformed X by 8.76% and 15.15%? I assume some "AOM_post-AV1" labels above are meant to be something else?

CodecWar

8th August 2023, 07:33

So X outperformed X by 8.76% and 15.15%? I assume some "AOM_post-AV1" labels above are meant to be something else?

I've updated the post to make it clear that it compares the same codec in 3 releases :
research2 Aug21,
research3 - May22,
research 4 - Apr22

benwaggoner

8th August 2023, 20:11

*underwhelming. AV2 isn't being ratified right now, so i wouldn't pay much attention that it is only 15% better. In a year i'm sure it will be more than that.
Yeah, no one would release a new codec with that small a delta. Us graybeards remembered what happened when MPEG-4 pt 2 came out with only maybe 20-30% more efficiency than MPEG-2. Just not worth the hassle.

Hence H.264, which was a pretty ground-up rethink of how to encode video that could deliver on 100% efficiency improvements.

benwaggoner

8th August 2023, 20:15

I've updated the post to make it clear that it compares the same codec in 3 releases :
research2 Aug21,
research3 - May22,
research 4 - Apr22
Thank you for the clarification.

I'm still surprised that the rate of improvement isn't higher, though. Lots of H.264 patents have expired, and thus don't have to be worked around, plus years more of academic research and work on the specific codec.

I am guessing that the ML stuff isn't refined enough to deliver material benefits yet. That's probably the make or break for AV2. I find myself atypically unsure of how big a real-world difference that could make. We could well wind up still not knowing even at release, as there are SO many new ways an encoder can be tuned and can optimize a bitstream with ML as an option. Incorporating ML model overhead into rate control alone is a chewy interesting challenge.

hajj_3

29th August 2023, 10:00

avif 1.0.0 has been released: https://github.com/AOMediaCodec/libavif/releases/tag/v1.0.0

ksec

29th August 2023, 17:26

Conclusions from the Study:
Based on the findings of this study, some significant conclusions were drawn:

On average, the AOM_post-AV1 (research 3 released in 2022 ) codec showed an 8.76% improvement over the AOM_post-AV1(research 2 released in 2021) reference codec across all video streams.
Comparing the average performance on all video streams, the AOM_post-AV1 (research 4 - Apr23) codec outperformed the AOM_post-AV1 (research 3 - 2022) reference codec by an impressive 15.15%.
In summary, the AV2 codec is showing immense promise and dedication from the AVM team. As the development progresses, it is evident that AV2 is significantly surpassing its predecessor, AV1, in terms of video quality and compression efficiency. However, with the increasing specialization, the codec might perform differently depending on the content being encoded.

Source: https://codecwar.com/compare/av2-research-evolution

This doesn't make any sense.

the AOM_post-AV1 (research 4 - Apr23) codec outperformed the AOM_post-AV1 (research 3 - 2022) reference codec by an impressive 15.15%.

So R4 outperform R3 by 15.15%. Except your link below shown

AOM_post-AV1 codec is better than AOM_post-AV1 reference codec by 15.15%, in average on all video streams.

The Reference is R2. i.e R4 is 15.15% better than R*2*.

Improvement in percentage also doesn't make sense. It is BD-Rate ( Which the report actually suggest ). i.e Reduction. ( Which is why I assume benwaggoner was confused and mentioned 100% improvement as in efficiency as 50% BD-Rate )

Now if I remember correctly, R2 is something like 10% BD-Rate on AV1. So that is 15.5% on top of 10%, multiply to less than 25%.

Which if I have to guess AV2 at R4 isn't even at VVC level. On the other hand, latest H.267 development is already at 30%+ on top of VVC.

Did I mention AV2 was suppose to be out in ( *cough* ) 2020.

So yes, I do think it is quite underwhelming. Previously Google was so fixated that next gen video codec being ML based and doesn't seems to offer any alternative. I wonder if R1- R4 is still ML based.

Gravitator

29th August 2023, 20:35

On the other hand, latest H.267 development is already at 30%+ on top of VVC.
Привет!
Will they go above blocks 128?

benwaggoner

30th August 2023, 16:25

Which is why I assume benwaggoner was confused and mentioned 100% improvement as in efficiency as 50% BD-Rate )
Yeah, this is a place where we could be crisper in the industry on the terminology. A reduction in bitrate is the reciprocal of an improvement in efficiency. So, a 100% improvement in compression efficiency IS a 50% reduction in bitrate. A 300% improvement in compression efficiency is a 75% reduction in bitrate. We could save some real confusion if we clearly specified which we meant when we are talking % better.

So yes, I do think it is quite underwhelming. Previously Google was so fixated that next gen video codec being ML based and doesn't seems to offer any alternative. I wonder if R1- R4 is still ML based.
I gather that there was some demonstration of value in some ML tool in the latest tests, but shy of 2%. AV2 doesn't seem to have any big organizing principle for how to make a big jump in compression efficiency, or any novel tools that would really have a big impact.

I'd hoped that the expiration of so many H.264 and other patents since AV1 would allow the use of tools AOM had wanted to use in AV1 but couldn't. It doesn't seem to have been the case. Perhaps the VPx core structure to avoid patents was so far off from the MPEG codec development process that tools weren't easily reusable?

hajj_3

2nd September 2023, 19:11

libaom 3.7 is out: https://aomedia.googlesource.com/aom/+/refs/tags/v3.7.0

Boulder

2nd October 2023, 15:49

Question regarding --chroma sample position: is it 2 for HDR?

Description of the parameter in the help text: "The chroma sample position when chroma 4:2:0 is signaled: unknown, vertical, colocated"

benwaggoner

4th October 2023, 18:45

Question regarding --chroma sample position: is it 2 for HDR?

Description of the parameter in the help text: "The chroma sample position when chroma 4:2:0 is signaled: unknown, vertical, colocated"

It is 2 for UHD HDR Blu-ray. Although I'm skeptical that end-to-end support is reliably implemented; a number of devices ignore the metadata and assume it is 0 like everything was forever. At 2160p getting it wrong is nigh invisible. I do worry about a 360p OTT HDR stream, though, as a half pixel is a 720p pixel.

oibaf

8th December 2023, 12:18

libaom 3.8.0 was released:

2023-11-30 v3.8.0
This release includes new codec interfaces, compression efficiency and
perceptual improvements, speedup and memory optimizations and many bug
fixes. This release is ABI compatible with the last release.
- New Features
* New codec controls:
* AV1E_SET_MAX_CONSEC_FRAME_DROP_CBR: Set the maximum number of
consecutive frame drops allowed for the frame dropper in 1 pass
CBR mode.
* Run-time CPU feature detection for all Arm platforms:
CRC, DotProd, I8MM and SVE CPU feature presence is detected at run
time and code paths making use of these features are selected
dynamically. These code paths provide meaningful performance gains
for standard bitdepth RTC and VoD encoding: up to 10% and 20%
respectively, over the Armv8.0-A baseline build.
* RTC: Frame-dropper support added to the rate control library.
* RTC Rate control improvements for low bitrate and for SVC.
- Compression Efficiency Improvements
* Improved accuracy of cost estimation for loop restoration and
global motion.
* Improved selection of loop restoration unit size - full search up
to (non-realtime) speed 2, retuned static selection at higher
speeds.
* RTC Screen content mode: 3-5% bdrate gains across speeds 7 - 10.
* Good-quality mode: 0.2 - 0.5% bdrate gains across speeds 1 - 4.
- Perceptual Quality Improvements
* RTC Screen: Improved visual quality for scrolling.
* RTC: Improved color quality for both screen and video mode.
- Speedup and Memory Optimizations
* Good-quality, single-thread encoder speedups:
o 15% improvement for speed 5.
o 12% improvement for speed 6.
* Arm standard bitdepth VoD (--good):
o 8% speedup for speeds 0 and 1.
o 20% speedup for speed 2.
o 27% speedup for speed 3.
o 30% speedup for speed 4.
o 38% speedup for speeds 5 and 6.
* Arm high bitdepth VoD (--good):
o 206% speedup for speeds 0 and 1.
o 180% speedup for speed 2.
o 51% speedup for speeds 3 and 4.
o 68% speedup for speed 5.
o 72% speedup for speed 6.
* RTC Screen content: 2-6% speedup across speeds 7-10.
* RTC: 2-3% speedup for temporal layers.
* RTC: Speedups to reference scaling in nonrd pickmode.
* Good-quality mode: Simplified global motion estimation, saving
~1200 lines of code and 1KB of tables while improving quality.
- Bug Fixes
* Fixes to improve libaom stability in case of memory allocation
failures.
* Fixes to SIMD functions (x86 AVX2/SSE2 and ARM Neon).
* b/310457427, b/310766628: Bug fixes to only use rec_sse in CBR
mode.

oibaf

8th December 2023, 14:21

Also, post 3.8.0: https://aomedia.googlesource.com/aom/+/0152ba993998cdb45b88d17622b898add3dca65b

rtc: Speed 11 for video mode, for resoln < 720p.

This is a very aggressive fast speed setting for
video in real-time mode (RTC).

-force single reference
-aggressive cdef skip
-selective cdf_update
-turn off motion interpolation filter search
-use only DC for intra-modes
-increase thresholds for source_sad and transform
skipping test
-faster partitioning - fixed per superblock

bdrate and IC change from speed 10 rtc_derf:
~29% IC speedup and ~26% bdrate loss

To be tuned/adjusted further.

oibaf

13th December 2023, 13:02

SVT-AV1 1.8.0 was released:

[1.8.0] - 2023-12-11

Encoder
Improve the tradeoffs for the random access mode across presets:
Speedup CRF presets M6 to M0 by 17-53% while maintaining similar quality levels
Re-adjust CRF presets M7 to M13 for better quality with BD-rate gains ranging from 1-4%
Improve the quality and speed of the 1-pass VBR mode
Improve Multi Pass VBR algorithm for better quality with BD-rate gains of ~3% on average
More details on the per preset improvements can be found in MR !2143
Add API allowing to update bitrate / CRF and Key_frame placement during the encoding session for CBR lowdelay mode and CRF Random Access mode
ARM Neon SIMD optimizations for most critical kernels allowing for a 4.5-8x fps speedup vs the c implementation
Cleanup and bug fixes and documentation

Various cleanups and functional bug fixes
Update the documentation for preset options and individual features

GTPVHD

14th December 2023, 18:34

https://www.intel.com/content/www/us/en/newsroom/news/core-ultra-client-computing-news-1.html

Intel Core Ultra Meteor Lake officially launched, Intel's first processor family with AV1 hardware encoder.

Yups

16th December 2023, 18:37

hajj_3

19th December 2023, 17:38

birdie

19th December 2023, 17:54

mozilla has removed AV1 support from firefox 121 on windows and now requires you to install the Microsoft AV1 Video Extension from microsoft store instead: https://www.mozilla.org/en-US/firefox/121.0/releasenotes/

This is likely due to avanci demanding royalties from AV1 streaming.

They didn't remove anything.

AV1 software decoding is still there. The extension is required for HW decoding. Windows LTSC doesn't have the extension installed by default and millions of people use this version of Windows because it's the version to use. Unfortunately MS for some reasons decided not to include HW video decoding with this Windows SKU.

hajj_3

20th December 2023, 00:22

Microsoft Edge 121 Beta has enabled AVIF decoding support by default.

hajj_3

26th January 2024, 11:27

Microsoft Edge 121 has just been released. av1 and avif now work by default.

Barough

24th February 2024, 18:02

AOM AV1 v3.8.1-290-g0414f4e9ab
Built on February 24, 2024, GCC 13.2.0

https://aomedia.googlesource.com/aom

DL :
https://www.mediafire.com/file/5qhcvuaz26w4h9g

LigH

1st March 2024, 22:09

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 13.2.0)

AOM v3.8.1-302-g14010c6f0f (https://www.mediafire.com/file/zxz6o0fg0i2v1hq/aom_v3.8.1-302-g14010c6f0f.7z/file)

rav1e 0.7.0 p20240227-g5eaae62e (https://www.mediafire.com/file/xs7wxk9ivz9udzn/rav1e_0.7.0_p20240227-g5eaae62e.7z/file)

dav1d 1.4.0-67-g85a1035 (https://www.mediafire.com/file/qzduyj6h4g1txap/dav1d_1.4.0-67-g85a1035.7z/file)

SVT-AV1 v1.8.0-43-g2bd950a9 (https://www.mediafire.com/file/1o94xnmusfuqcfu/SVT-AV1_v1.8.0-43-g2bd950a9.7z/file)

avif 1.0.4-8db5d51 (https://www.mediafire.com/file/jeyua48g348wy2l/avif_1.0.4-8db5d51.7z/file)
dav1d [dec]:1.4.0-67-g85a1035, aom [enc/dec]:3.8.1-302-g14010c6f0f, rav1e [enc]:0.7.0 (p20240227)

LigH

21st May 2024, 18:59

It seems to me that avifenc may support SVT-AV1 as one of several encoders. A recent build v1.0.4 does contain strings with related messages. But I doubt it contains code, and the help output doesn't mention it either. Does anyone know facts?

PS: The repo readme (https://github.com/AOMediaCodec/libavif) suggests that it has to be enabled in CMake options... maybe M-AB-S can do that for the 64-bit version.

PPS: Well, that was simple.

LigH

21st May 2024, 21:17

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 14.1.0)

AOM v3.9.0-146-g4637f5d7 (https://www.mediafire.com/file/88yih37kbl19zco/aom_v3.9.0-146-g4637f5d7.7z/file)

rav1e 0.7.0 p20240423-1-g1c4fcd8 (https://www.mediafire.com/file/yqh99nyms3t5fwq/rav1e_0.7.0_p20240423-1-g1c4fcd8.7z/file)

dav1d 1.4.1-66-g3623543 (https://www.mediafire.com/file/phu2u316bzqhb1c/dav1d_1.4.1-66-g3623543.7z/file)

SVT-AV1 v2.1.0-bbcff78 (https://www.mediafire.com/file/mfg5c9pswvj2fvj/SVT-AV1_v2.1.0-bbcff78.7z/file)

avif 1.0.4-99c288a (https://www.mediafire.com/file/6wemdr3sg65mhyl/avif_1.0.4-99c288a.7z/file)
Version: 1.0.4 (dav1d [dec]:1.4.1-66-g3623543, aom [enc/dec]:3.9.0-146-g4637f5d7, rav1e [enc]:0.7.0 (p20240423-1-g1c4fcd8), svt [enc]:v2.1.0)
libyuv : available (1887)
Note: SVT-AV1 encoder in avifenc only available in 64-bit build

LigH

19th July 2024, 19:46

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 14.1.0)

AOM v3.9.1-289-gb90f9011 (https://www.mediafire.com/file/adow5lrvv63x49l/aom_v3.9.1-289-gb90f9011.7z/file)

rav1e 0.7.0 p20240612-2-ge34e772 (https://www.mediafire.com/file/om45wvs3ndaucm0/rav1e_0.7.0_p20240612-2-ge34e772.7z/file)

dav1d 1.4.2-15-g2355eeb (https://www.mediafire.com/file/lrkkmvssr7xkfid/dav1d_1.4.2-15-g2355eeb.7z/file)

SVT-AV1 v2.1.2-52-gb13aec2 (https://www.mediafire.com/file/y4miln5g829aueb/SVT-AV1_v2.1.2-52-gb13aec2.7z/file)

avif 1.0.4-132b02c (https://www.mediafire.com/file/t1y395bwdfancge/avif_1.0.4-132b02c.7z/file)
Version: 1.0.4 (dav1d [dec]:1.4.1-66-g3623543, aom [enc/dec]:3.9.0-146-g4637f5d7, rav1e [enc]:0.7.0 (p20240612-2-ge34e772), svt [enc]:v2.1.0)
libyuv : available (1887)
Note: SVT-AV1 encoder in avifenc only available in 64-bit build

LigH

14th September 2024, 10:02

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 14.2.0)

AOM v3.10.0-83-g8d4d4d8f (https://www.mediafire.com/file/r8w1opijar0zc0i/aom_v3.10.0-83-g8d4d4d8f.7z/file)

rav1e 0.7.0 p20240612-5-g7ab0de1 (https://www.mediafire.com/file/qc43geq28pu40fd/rav1e_0.7.0_p20240612-5-g7ab0de1.7z/file)

dav1d 1.4.2-54-gdd32cd5 (https://www.mediafire.com/file/5co0qnigzqv9erd/dav1d_1.4.2-54-gdd32cd5.7z/file)

SVT-AV1 v2.2.1-51-gf80d0e5 (https://www.mediafire.com/file/bo00xvq8v0qtl6r/SVT-AV1_v2.2.1-51-gf80d0e5.7z/file)

avif 1.1.1-8aab77e (https://www.mediafire.com/file/do8jyvmr67vteon/avif_1.1.1-8aab77e.7z/file)
Version: 1.1.1 (dav1d [dec]:1.4.2-54-gdd32cd5, aom [enc/dec]:3.10.0-83-g8d4d4d8f, rav1e [enc]:0.7.0 (p20240612-5-g7ab0de1), svt [enc]:v2.2.1-51-gf80d0e5)
libyuv : available (1887)
Note: SVT-AV1 encoder in avifenc only available in 64-bit build

oibaf

16th September 2024, 13:27

aom 3.10.0 was recently released:
https://aomedia.googlesource.com/aom/

2024-08-27 v3.10.0

This release includes new codec interfaces, compression efficiency and
perceptual improvements, speedup and memory optimizations and many bug
fixes. This release is ABI compatible with the last release.
The definitions of the internal macros AOM_INLINE and AOM_FORCE_INLINE
have been removed from the public header aom/aom_integer.h.
- New Features
* New codec controls:
* AV1E_SET_AUTO_TILES
* AV1E_GET_HIGH_MOTION_CONTENT_SCREEN_RTC
* AV1E_SET_POSTENCODE_DROP_RTC: Post encode frame drop feature.
* AV1E_SET_MAX_CONSEC_FRAME_DROP_MS_CBR
* New key-value pair for aom_codec_set_option():
* "auto-tiles": equivalent to the new codec control
AV1E_SET_AUTO_TILES.
- Deprecated Features
* Deprecated codec control:
* AV1E_SET_MAX_CONSEC_FRAME_DROP_CBR: Use the new codec control
AV1E_SET_MAX_CONSEC_FRAME_DROP_MS_CBR instead.
* The sframe_mode field in the aom_codec_enc_cfg_t struct is not
implemented.
- Compression Efficiency Improvements
* BD-rate gain of 0.7 - 1.3% (by enabling global motion tool) for
speed 5 and speed 6 with ~5% encode time increase.
* RTC speed 11 video: ~3-5% BD-rate gain for VGA and QVGA.
- Perceptual Quality Improvements
* RTC quality improvements for slide changes and scrolling content.
- Speedup and Memory Optimizations
* RTC screen content speedups:
* ~2x speedup for high motion content for speed 11.
* ~2x speedup on key frame coding for speed >= 10.
* Arm: Significant uplifts in speed in this release (vs v3.9.1) have
come from tuning the various convolutions according to filter size
(doing 8-tap when only 2-tap is required is inefficient) and also
deploying Armv8.6 USMMLA instructions in 6-tap and 12-tap standard
bitdepth convolutions.
* Standard bitdepth RTC:
* speed 5: +5%
* speed 6: +4%
* speed 7: +5%
* speed 8: +4%
* speed 9: +6%
* speed 10: +6%
* Standard bitdepth VoD:
* speed 0: +9%
* speed 1: +12%
* speed 2: +9%
* speed 3: +3%
* speed 4: +3%
* speed 5: -9% (expected due to global motion changes)
* speed 6: -3% (expected due to global motion changes)
* High bitdepth VoD:
* speed 0: +4%
* speed 1: +19%
* speed 2: +23%
* speed 3: +1%
* speed 4: +1%
* speed 5: -8% (expected due to global motion changes)
* speed 6: -3% (expected due to global motion changes)
* Standard bitdepth 2x1 horizontal super-resolution/scaling
encoding: +101%
- Other Improvements
* Reduce bit rate overshoot on slide content.
- Bug Fixes
* rtc: Bug fix for active_maps with sb_size=128.
* b:343429036: rtc: Fix source_sad setting near boundary.
* Fix to QP for temporal enhancement after key frame.
* b:343429192: rtc: Condition QP adjustment on rc->q_1/2_frame > 0.

oibaf

24th September 2024, 12:40

Enhancing Screen Sharing with AV1 in Microsoft Teams (https://techcommunity.microsoft.com/t5/microsoft-teams-blog/enhancing-screen-sharing-with-av1-in-microsoft-teams/ba-p/4096056)

It looks like they are using RTC screen content improvements in latest releases of aom.

hajj_3

18th October 2024, 12:06

dav1d decoder v1.5.0:

- AArch64: Optimize Armv8.0 NEON for HBD horizontal filters and 6-tap filters
- Power9: Optimized ITX till 16x4.
- Loongarch: numerous optimizations
- RISC-V optimizations for pal, cdef_filter, ipred, mc_blend, mc_bdir, itx
- Allow playing videos in full-screen mode in dav1dplay

LigH

8th November 2024, 14:14

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 14.2.0)

AOM v3.10.0-186-g2d2f644e (https://www.mediafire.com/file/hvmf71vix5c8293/aom_v3.10.0-186-g2d2f644e.7z/file)

rav1e 0.7.0 p20241015-release (https://www.mediafire.com/file/ckulebxdoq7ma23/rav1e_0.7.0_p20241015-release.7z/file)

dav1d 1.5.0-16-g93f12c1 (https://www.mediafire.com/file/dxs0hq1c7d4i3pc/dav1d_1.5.0-16-g93f12c1.7z/file)

SVT-AV1 v2.3.0-39-gfdcb885 (https://www.mediafire.com/file/hlyuyvchjm6am6f/SVT-AV1_v2.3.0-39-gfdcb885.7z/file)

avif 1.1.1-1cdeff7 (https://www.mediafire.com/file/h0u2ek1ou7llzgy/avif_1.1.1-1cdeff7.7z/file)
dav1d [dec]:1.5.0-16-g93f12c1, aom [enc/dec]:3.10.0-184-g6418c21b, rav1e [enc]:0.7.0 (p20241015), svt [enc]:v2.3.0-29-g8d9f4ff
libyuv : available (1887)
Note: SVT-AV1 encoder in avifenc only available in 64-bit build

LigH

7th December 2024, 12:09

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 14.2.0)

AOM v3.11.0-120-gdedba6a7 (https://www.mediafire.com/file/hxegdl23jpw4qql/aom_3.11.0-120-gdedba6a7.7z/file)

dav1d 1.5.0-46-gd242c47 (https://www.mediafire.com/file/i9kkffptl2hm78k/dav1d_1.5.0-46-gd242c47.7z/file)

SVT-AV1 v2.3.0-72-g8f1f1b0 (https://www.mediafire.com/file/lasjt9synfgruj9/SVT-AV1_v2.3.0-72-g8f1f1b0.7z/file)

avif 1.1.1-3196438 (https://www.mediafire.com/file/blhvh1zmb59ljcp/avif_1.1.1-3196438.7z/file)
dav1d [dec]:1.5.0-46-gd242c47, aom [enc/dec]:3.11.0-114-g6a1c5562, rav1e [enc]:0.7.0 (p20241015), svt [enc]:v2.3.0-64-g425e4bd
libyuv : available (1887)
Note: SVT-AV1 encoder in avifenc only available in 64-bit build

LigH

20th March 2025, 19:20

New uploads: (MSYS2; MinGW32 / MinGW64: GCC 14.2.0)

AOM v3.12.0-29-gc5e1e39e (https://www.mediafire.com/file/a2gt8xgt1wo6ljr/aom_v3.12.0-29-gc5e1e39e.7z/file)

rav1e 0.7.0 p20250225 g38879ab (https://www.mediafire.com/file/ay8qp2rkgmv10h6/rav1e_0.7.0-p20250225-g38879ab.7z/file)

dav1d 1.5.1-5-g8d95618 (https://www.mediafire.com/file/7xbzbm0xjw52ju8/dav1d_1.5.1-5-g8d95618.7z/file)

SVT-AV1 v3.0.1-20-g7bc96cc (https://www.mediafire.com/file/uv370sezhhuo1kb/SVT-AV1_v3.0.1-20-g7bc96cc.7z/file)

avif 1.2.1-1d46986 (https://www.mediafire.com/file/9lml9a99jl56qzt/avif_1.2.1-1d46986.7z/file)
dav1d [dec]:1.5.1-5-g8d95618, aom [enc/dec]:3.12.0-29-gc5e1e39e, rav1e [enc]:0.7.0 (p20250225), svt [enc]:v3.0.1-20-g7bc96cc
libyuv : available (1905)
Note: SVT-AV1 encoder in avifenc only available in 64-bit build

oibaf

20th March 2025, 20:45

2025-02-10 v3.12.0
This release includes new codec interfaces, compression efficiency and
perceptual improvements, speedup and memory optimizations, and bug
fixes. This release is ABI compatible with the last release.
Five internal functions (aom_free, aom_malloc, aom_wb_bytes_written,
aom_wb_write_bit, aom_wb_write_literal) that were exported by mistake
are no longer exported from the libaom shared library. The removal of
these internal functions from the ABI is a bug fix and does not break
ABI compatibility.
Acknowledgments: The image quality optimizations in the new tuning
mode AOM_TUNE_IQ were originally developed for SVT-AV1-PSY by
Cole Ogaard, Gianni Rosato, Julio Barba, and Zakaria Djebrouni.
- New Features
* New tuning mode AOM_TUNE_IQ (image quality) for the
AOME_SET_TUNING codec control (--tune=iq) in all-intra mode. The
feature detection macro AOM_HAVE_TUNE_IQ, if defined, indicates
that AOM_TUNE_IQ is available. The image quality optimizations in
AOM_TUNE_IQ were developed by using the SSIMULACRA 2 metric for
guidance and validated with subjective visual quality checks.
* New value 6 for the AV1E_SET_DELTAQ_MODE codec control
(--deltaq-mode): use modulation for all intra using Variance
Boost. Variance Boost is a variance adaptive quantization
implementation that modulates qindex depending on the ratio of
low-variance to high-variance 8x8 subblocks within a 64x64
superblock, as well as the actual variance of the subblocks
themselves.
* New value 3 for the AV1E_SET_ENABLE_CDEF codec control
(--enable-cdef): Enable CDEF adaptively based on frame qindex.
* In all-intra mode, the AOME_SET_SHARPNESS codec control now also
sets the loop_filter_sharpness syntax element in the bitstream.
Larger values increasingly reduce how much the filtering can
change the sample values on block edges to favor perceived
sharpness.
* In all-intra mode, the default value of the AV1E_SET_QM_MIN codec
control is decreased to 4, and the default value of the
AV1E_SET_QM_MAX codec control is increased to 10. The default
values in good-quality and realtime modes remain unchanged (5 and
9, respectively).
- Compression Efficiency Improvements
* Tuning mode AOM_TUNE_IQ improves image compression efficiency on
the CLIC dataset by up to 12% for the same SSIMULACRA 2 score, up
to 14% for the same DSSIM score, and up to 17% for the same
Butteraugli score.
* ~3% BD-rate gains for speed 11 VGA camera mode.
* ~5% BD-rate gains for speed 11 on scroll clips screen mode.
- Perceptual Quality Improvements
* Adjust temporal filter strength for better visual quality.
* RTC screen: visual quality improvements for scrolling and for
scene/slide changes.
* RTC camera mode: visual quality improvements for speed 11 VGA.
- Speedup and Memory Optimizations
* Optimize the Arm Neon implementation of the loop filter functions
with an average uplift of 15 - 25% in microbenchmarks.
* Add the CDEF optimization for RISC-V.
* Help the compiler generate better vectorized code for variance
calculation and warped motion in generic CPU builds.
* Make several arrays const.
- Other Improvements
* Binary size reduction: 1 - 2% compared with last release, with
CONFIG_REALTIME_ONLY enabled, CONFIG_AV1_DECODER and
CONFIG_AV1_HIGHBITDEPTH disabled.
* Build: compile source files in parallel under MSVC.
- Bug Fixes
* Fix bug where metadata added with aom_img_add_metadata was lost
when frame scaling was used.
* Bug b:383306740: RTC: Fix to issues with scrolling for screen
content.
* Bug b:382465458: RTC: Fix to artifact for grayscale input.
* Bug b:380247338: RTC: Fix to encode_time spikes on scene/slide
changes.
* RTC: Fix to rate correction factor update for VBR screen mode.
https://groups.google.com/a/aomedia.org/g/av1-discuss/c/nJxECdg-7P8
* Bug b:378401081: RTC: Fix to cyclic refresh update for external RC
(rate control).

mzso

12th April 2025, 11:45

Hi!

Is there any notable use of AV1 outside Youtube? (And I guess Netflix, of which I'm not a subscriber of)

ksec

12th April 2025, 12:47

Hi!

Is there any notable use of AV1 outside Youtube? (And I guess Netflix, of which I'm not a subscriber of)

I think Twitch was testing it but I dont think it is implemented as default yet. But other than that Not really. Which is despite why AOM supporter have been saying for the past 5 years as if AV1 is *everywhere*.

Beelzebubu

12th April 2025, 13:24

Hi!

Is there any notable use of AV1 outside Youtube? (And I guess Netflix, of which I'm not a subscriber of)

Meta has talked about using AV1 (link1 (https://engineering.fb.com/2023/02/21/video-engineering/av1-codec-facebook-instagram-reels/), link2 (https://www.streamingmedia.com/Articles/News/Online-Video-News/Metas-David-Ronca-Talks-Benchmarking-and-Deploying-AV1-in-the-Android-Ecosystem-168126.aspx)).

mzso

12th April 2025, 13:56

Oh well, I guess over time it still might become the web video de-facto standard. As HW support improves and SW codecs become more efficient. (At least the situation is not as big of a mess as with JPEG-XL)

oibaf

13th April 2025, 14:37

Beelzebubu

13th April 2025, 14:38

That reminds me, Cisco's WebEx also uses AV1: https://blog.webex.com/engineering/the-av1-video-codec-comes-to-webex/

nevcairiel

14th April 2025, 10:39

Discord can stream in AV1 as well, although it being a live-encoding scenario they only use it when HW encoding is available. https://support.discord.com/hc/en-us/articles/12158692510743-Video-Codec-FAQ#h_01GRYP1FMKTKBCHQ198JCPM0Q1

birdie

18th April 2025, 13:02

Microsoft Teams: https://techcommunity.microsoft.com/blog/microsoftteamsblog/enhancing-screen-sharing-with-av1-in-microsoft-teams/4096056
Google Meet: https://aomedia.org/av1-adoption-showcase/google-story/
Jitsi Meet: https://jitsi.org/blog/av1-and-more-how-does-jitsi-meet-pick-video-codecs/

Yeah, nice links. Now have you actually confirmed these apps use AV1 encoding?

Because something tells me everything still uses H.264.

hajj_3

18th April 2025, 14:07

Yeah, nice links. Now have you actually confirmed these apps use AV1 encoding?

Because something tells me everything still uses H.264.

google meet uses av1: https://webrtchacks.com/the-hidden-av1-gift-in-google-meet/

birdie

22nd April 2025, 16:30

google meet uses av1: https://webrtchacks.com/the-hidden-av1-gift-in-google-meet/

Someone in 2023 on some hardware confirmed that.

What about you though?

LigH

11th May 2025, 14:41

New uploads: (MSYS2; MinGW32 / MinGW64; GCC 15.1.0)

AOM v3.12.1-135-gb9f374fa (https://www.mediafire.com/file/tgnctc7gdtjz6gb/aom_v3.12.1-135-gb9f374fa.7z/file)

rav1e 0.8.0 p20250429 gcda1298 (https://www.mediafire.com/file/p3co5ve8090os7l/rav1e_0.8.0-p20250429-gcda1298.7z/file)

dav1d 1.5.1-5-g8d95618 (https://www.mediafire.com/file/7xbzbm0xjw52ju8/dav1d_1.5.1-5-g8d95618.7z/file)

SVT-AV1 v3.0.2-49-g5def505 (https://www.mediafire.com/file/u7o0t2wuu5shtje/SVT-AV1_v3.0.2-49-g5def505.7z/file)

avif 1.3.0-da9d727 (https://www.mediafire.com/file/ol07jqfejtuvez6/avif_1.3.0-da9d727.7z/file)
dav1d [dec]:1.5.1-5-g8d95618, aom [enc/dec]:3.12.1-135-gb9f374fa, rav1e [enc]:0.8.0 (p20250429), svt [enc]:v3.0.2-49-g5def505
libyuv : available (1905)
Note: SVT-AV1 encoder in avifenc only available in 64-bit build

benwaggoner

12th May 2025, 17:09

Someone in 2023 on some hardware confirmed that.
It could be that some very old hardware without the power to encode AV1 falls back to older codecs in some scenarios. That doesn't mean that AV1 isn't used by default or most of the time. Or in everything in 2025.

oibaf

24th November 2025, 21:16

Decoding Netflix's AV1 Streams: Here are 10 things I found (https://singhkays.com/blog/netflix-av1-decode/)

VoodooFX

25th November 2025, 00:42

Decoding Netflix's AV1 Streams: Here are 10 things I found (https://singhkays.com/blog/netflix-av1-decode/)

It talks about "quality" without actual quality analysis. Mostly about bitrates. Set lower bitrate on any codec - less bitrate - more "quality". :)

For some content, Netflix’s AV1 encodes are so focused on quality that they actually use more data than the HEVC equivalent.

Why not:
"For some content, Netflix’s AV1 encodes are so bad on quality that they actually use more data than the HEVC equivalent."

The Catch (There’s Always a Catch)

AV1 isn’t a magic bullet. It has two major hurdles:
Encoding Cost: AV1 is computationally expensive to encode. This requires a massive, ongoing investment in server infrastructure for any streaming service.
Device Support: Hardware decoding for AV1 is still not ubiquitous. This is a classic chicken-and-egg problem that will take a few more years of device refresh cycles to resolve.

Highly questionable...