Alliance for Open Media codecs

[Greenhorn]

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]

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]

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.

[soresu]

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]

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.
Yikes. I can already see the headlines for laws being passed (in EU countries anyway)

[soresu]

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]

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]

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]

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]

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]

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]

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]

rav1e v0.4.0 is out: https://github.com/xiph/rav1e/releases/tag/v0.4.0

[benwaggoner]

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]

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]

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]

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]

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]

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]

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]

We should probably start a "Encoding for VR" thread.

[hajj_3]

PotPlayer 1.7.21419 released today adds support for DXVA hardware decoding of AV1.

[benwaggoner]

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]

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]

PotPlayer 1.7.21419 released today adds support for DXVA hardware decoding of AV1.


They should add D3D11 as well.

[LigH]

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]

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]

Avif feature in Firefox next release will been delayed because of an important bug.

Marco Sousa

[Mr_Khyron]

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/

[benwaggoner]

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]

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]

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]

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]

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]

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]

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

[benwaggoner]

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]

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]

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]

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]

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]

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]

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]

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]

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]

mediatek dimensity 900 was announced today, it can hardware decode AV1.

[benwaggoner]

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?

[hajj_3]

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?

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.

[benwaggoner]

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]

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.