Alliance for Open Media codecs

[benwaggoner]

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]

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]

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]

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]

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]

AV2 is already showing serious bitstream savings: https://ottverse.com/av2-video-codec-evaluation/

[benwaggoner]

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]

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]

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.

[nhw_pulsar]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

What settings does Youtube use for encoding for AV1?

[benwaggoner]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Do we have any info about Intel's quality, or quality @ perf?

[Blue_MiSfit]

I haven't seen anything yet, but am eagerly looking forward to getting some of this info.

[rwill]

Yeah, I wish someone at a company that could use this info professionally would investigate.

[GTPVHD]

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]

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]

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]

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]

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]

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]

Finally the one area the arc gpus are good at ^^"

[Mr_Khyron]

SSIM Comparison for Intel Arc A380 QSV
https://rigaya34589.blog.fc2.com/blog-entry-1501.html

[Yups]

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]

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]

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]

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]

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]

https://www.intel.com/content/www/us/en/newsroom/news/introducing-intel-data-center-gpu-flex-series.html

[filler56789]

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