Alliance for Open Media codecs

[benwaggoner]

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]

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]

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]

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]

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]

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]

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]

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]

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?

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.

[benwaggoner]

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]

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]

https://aomedia.googlesource.com/aom/+/refs/tags/v3.5.0

[GTPVHD]

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]

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]

https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/5c288a44ad16087c3d3a7563490cb634790e751f

avcodec/nvenc: add AV1 encoding support

[GTPVHD]

https://developer.nvidia.com/nvidia-video-codec-sdk/download

Support for AV1 encoding on NVIDIA Ada Lovelace architecture.

[LigH]

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]

SVT-AV1 v1.4.0: https://gitlab.com/AOMediaCodec/SVT-AV1/-/tags/v1.4.0

[Jamaika]

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]

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]

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]

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.

[Yups]

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]

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]

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]

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]

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]

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:

[LigH]

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]

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]

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]

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).

It's disappointing that re-inventing the wheel every generation seems to be de rigueur for every new encoder, and only some codecs ever get to that point at all. Alas.

[benwaggoner]

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]

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...)

[benwaggoner]

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]

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]

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...)

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.

[Emulgator]

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.

[benwaggoner]

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]

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]

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]

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

[nhw_pulsar]

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]

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]

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]

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]

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]

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]

Youtube is adding AV1 livestream uploading using RTMP+ - https://www.tomshardware.com/news/av1-live-streaming-is-finally-coming-to-youtube

[FranceBB]

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.