Alliance for Open Media codecs

[foxyshadis]

The rest of the clip has Rav1e clearly deficient despite the large bitrate though. It constantly smoothes the solid/flat areas and generally can't keep the milder grain and texture (which is a flaw). So its psychovisual decisions probably still aren't ready for high quality transparent encoding. This is a general problem with any non x264/x265 encoder probably, even x265 would drop texture detail everywhere before it got aq and psyrdo.

It never ceases to astonish me how every single codec seems to prize PSNR over visual quality at the start, after all these years, and bolt on psychovisual as an afterthought. Also, how many codecs are designed with only low-bitrate in mind, assuming that high bitrate will automatically be transparent, so there's no reason to waste time on that. You'd think that Google would have, well, Googled for the successes and failures in this field before surging ahead. Or at least listened to Monty, since he's The Woz of codec design.

[marcomsousa]

Android Q introduces support for the open source video codec AV1. This allows media providers to stream high quality video content to Android devices using less bandwidth. In addition, Android Q supports audio encoding using Opus - a codec optimized for speech and music streaming, and HDR10+ for high dynamic range video on devices that support it.

The MediaCodecInfo API introduces an easier way to determine the video rendering capabilities of an Android device. For any given codec, you can obtain a list of supported sizes and frame rates using VideoCodecCapabilities.getSupportedPerformancePoints(). This allows you to pick the best quality video content to render on any given device.

[benwaggoner]

It never ceases to astonish me how every single codec seems to prize PSNR over visual quality at the start, after all these years, and bolt on psychovisual as an afterthought. Also, how many codecs are designed with only low-bitrate in mind, assuming that high bitrate will automatically be transparent, so there's no reason to waste time on that. You'd think that Google would have, well, Googled for the successes and failures in this field before surging ahead. Or at least listened to Monty, since he's The Woz of codec design.
PSNR may not be good, but it is easy to calculate.

And Google REALLY likes objective metrics. They trust a number from a computer more than their own eyes.

It's one of those "looking where the light is" kinds of problems.

[Nintendo Maniac 64]

They trust a number from a computer more than their own eyes.

Geez, no wonder people like Elon Musk are so concerned about certain tech companies going all-in on deep A.I.

[benwaggoner]

Say, does anyone know if the Android Q AV1 decoder has/will have PlayReady integration? If so, what level?

[Blue_MiSfit]

I strongly doubt it. If there is an integration I'd be shocked if it's not software based, which would max out at SL2000.

[marcomsousa]

Firefox 66 - Support for AV1 codec is activated on Windows by default.

[birdie]

Firefox 66 - Support for AV1 codec is activated on Windows by default.

It was already enabled (https://www.mozilla.org/en-US/firefox/65.0/releasenotes/) in Firefox 65.

[Nintendo Maniac 64]

It would seems that LAVFilters v0.74.1 and therefore also MPC-HC v1.8.6 are now using dav1d, resulting in similar performance gains that were seen in MPC-BE beta builds (which I previously measured as being ~50% faster than MPC-HC v1.8.4 and its included LAVFilters v0.73).

[Pushman]

https://github.com/Nevcairiel/LAVFilters/releases/tag/0.74

NEW: Using the dav1d AV1 decoder for significantly improved AV1 decoding performance

[Nintendo Maniac 64]

https://github.com/Nevcairiel/LAVFilters/releases/tag/0.74

Note, there's a newer 0.74.1 version of LAVFilters in case anybody is thinking that above link is the newest version (which it's not):

https://github.com/Nevcairiel/LAVFilters/releases

[mzso]

Hi!

Is there anything out there that can encode valid AVIF images?
Does (dev versions of) Chrome/Firefox support viewing AVIF images? (Anything else?)

[nevcairiel]

Hi!

Is there anything out there that can encode valid AVIF images?
Does (dev versions of) Chrome/Firefox support viewing AVIF images? (Anything else?)

You can encode with this tool, for example:
https://github.com/Kagami/go-avif (binary: https://ci.appveyor.com/project/Kagami/go-avif/build/artifacts)

They also have a avif.js demo that can decode it using JavaScript (https://kagami.github.io/avif.js/). I don't think any browsers have native support yet, since the spec for AVIF was only officially signe-off a week ago or so.
Interestingly, the upcoming Windows 10 "19H1" seems to have native support, both in Explorer for thumbnails, as well as in Paint for importing - assuming the AV1 Video Extension is installed.

[Wolfberry]

AVIF is basically AV1 codec in HEIF container, so you can also use ffmpeg with libaom enabled (or ffmpeg + aomenc) to encode the pictures into ivf and then use MP4Box -add-image to convert the ivf files into avif.

[nevcairiel]

AVIF is basically AV1 codec in HEIF container, so you can also use ffmpeg with libaom enabled (or ffmpeg + aomenc) to encode the pictures into ivf and then use MP4Box -add-image to convert the ivf files into avif.

To be fair, any AVIF file is a HEIF file, but if your tool doesn't know what its doing, then a HEIF file with AV1 in it may not be valid AVIF (since it defines some constraints to make it easier on readers that only want to support AVIF and not the full HEIF spec).
That said, MP4Box actually supports AVIF however, but you should be passing "-brand avif" to make sure it makes a proper one.

Compatible software and some invocation commands are listed here:
https://github.com/AOMediaCodec/av1-avif/wiki

[Wolfberry]

Thanks for the link, SmilingWolf's script also adds -ab miaf, I guess that is optional?

[nevcairiel]

Thanks for the link, SmilingWolf's script also adds -ab miaf, I guess that is optional?

Yeah, sort of optional. The spec says it should be there, but its not clear to me if you need to use one of its profiles. You can have a whole list of alternate/compatible brands in such a file. The AVIF spec lists them:
https://aomediacodec.github.io/av1-avif/#profiles-constraints

"avif" from the AVIF spec itself.
"mif1" from HEIF
"miaf" from the MIAF spec
and finally "MA1B" or "MA1A" to identify the AV1 profile in use.
Or various alterations of the above for special types of images.

... this ISOBMFF image format stuff is a real mess. :)

[NikosD]

I did a small comparison between lib-aom and lib-dav1d earlier this week.

I used LAV Video 0.73.1-31 x64 for lib-aom and LAV Video 0.74.1-1 for lib-dav1d (no idea if LAV uses the latest versions of both libraries, but should be close to latest)

The two systems mentioned below have Win 10 October Update and I used DXVA Checker v4.20 for both of them.

The AV1 sample is Chimera - AV1 - 1080p - 8bit - 6.7Mbps file.

Skylake system:
Core i5 6500 (4C/4T) at 3.2GHz (All core turbo 3.3GHz) using 1x8GB DIMM of DDR4-2133 MHz RAM (Single channel)

Haswell system:
Core i3 4170 (2C/4T) at 3.7GHz (No Turbo) using 2x8GB DIMMs of DDR3-1600 MHz RAM (Dual channel)

Benchmark results:
(min/avg/max fps)

Skylake Core i5 6500:

libaom 30/48/149 CPU usage 65%
dav1d 77/128/282 CPU usage 91%

Haswell Core i3 4170:

libaom 21/37/153 CPU usage 71%
dav1d 53/91/240 CPU usage 90%


Comments:

For both AVX2 capable CPUs, the speedup is similar ~2.5 times faster for dAV1d than libaom (2.46 for Haswell and 2.67 for Skylake) and the CPU usage also goes to ~90% for both.
The difference is huge for multi-threaded systems.

Core i5 6500 manages to be faster from 30% (using libaom) to 41% (using dav1d) than Core i3 4170.

[dapperdan]

MSU HEVC/AV1/VP9 encoding test results:


http://compression.ru/video/codec_comparison/hevc_2018/

[soresu]

Did anyone see the SVT-AV1 announcement from Intel/Netflix.
Link here (https://www.phoronix.com/scan.php?page=news_item&px=Intel-SVT-AV1-Announced).

Still havent seen a comprehensive comparison of it compared to libaom, x265 and vp9 quality wise.

[tnti]

https://mp.weixin.qq.com/s?__biz=MzU1NTEzOTM5Mw==&mid=2247489793&idx=1&sn=6a148c57f2aa9885533f6b278ca3b94e&chksm=fbd9b12fccae3839d044c60fca9fa3a72dbf9b684562e1af7c3ef69ad78f1e3ad620416be03e&xtrack=1&scene=0&subscene=131&clicktime=1554775340&ascene=7&devicetype=android-27&version=2700033c&nettype=WIFI&abtest_cookie=BAABAAoACwASABMABQAjlx4AVpkeAMiZHgDZmR4A3JkeAAAA&lang=zh_CN&pass_ticket=fjjXRX43%2F5cmbhcL8uajT4nAMGLFrTTwZb7hV1Ggt4VVt5J1zgccAZAL4jdEkgDp&wx_header=1

关于对比rav1e和SVT-AV1，以下为来自Zoe Liu的回复：

“rav1e和SVT-AV1在github上的开源编码器，迄今为止还没有完成AV1标准中的最主要的编码工具集。对于任意一款AV1编码器，如果没有实现AV1标准的主要工具，只是在码流格式上符合AV1标准规范，而无法体现AV1的标准优势，其实还没有达到作为AV1编码器的基准要求。

我们对最新的SVT-AV1 github版本做了相对粗略的RD性能测试，其目前的编码效率还停留在AV1的前身VP9的大致水平。对这样开发阶段的编码器，放到AV1类别里面做编码性能与速度评估，不仅没有意义，对这样的开源项目也是不公平的。”

The following is the content of machine translation:
Regarding the comparison between rav1e and SVT-AV1, the following is a response from Zoe Liu:



"Rav1e and SVT-AV1 open source coders on GitHub have not yet completed the most important coding tool set in AV1 standard. For any AV1 encoder, if there is no main tool to implement the AV1 standard, it only conforms to the AV1 standard in bit stream format, but can not reflect the standard advantages of AV1. In fact, it has not reached the standard requirements as AV1 encoder.



We have done a relatively rough RD performance test for the latest version of SVT-AV1 github, and its coding efficiency is still at the approximate level of VP9, the predecessor of AV1. It is not only meaningless to evaluate the coding performance and speed of the coder in the AV1 category, but also unfair to such open source projects.

[hajj_3]

Intel to make their own AV1 software decoder:

https://www.phoronix.com/scan.php?page=news_item&px=Intel-TODO-AV1-Decode-FFmpeg
https://trello.com/c/oEZQai7L/26-av1-decoder

[utack]

Intel to make their own AV1 software decoder:

https://www.phoronix.com/scan.php?page=news_item&px=Intel-TODO-AV1-Decode-FFmpeg
https://trello.com/c/oEZQai7L/26-av1-decoder

Seems like they were not happy dav1d runs well on Ryzen :p

[hajj_3]

Seems like they were not happy dav1d runs well on Ryzen :p

Hopefully the dav1d decoder will copy any improvements that intel makes in their decoder. I have an intel kaby lake chip so i'm not complaining about intel making a new software decoder :P

[nevcairiel]

Seems like they were not happy dav1d runs well on Ryzen :p

Well dav1d certainly won't get slower through any of their efforts. :)
That said, dav1d puts a lot of effort into AVX2, which current-gen Ryzen doesn't even do particularly fast, so..

Additionally, that Trello "av1 decoder" task existed before dav1d was even a thing, and contrary to the Phoronix article, dav1d is actually quite decently fast on 8-bit content (work on speeding up 10-bit has started).
BUT, one should know that an encoder basically contains a decoder already, because it has to practically decode encoded frames to get accurate reference frame information, so splitting that out may always be an option.

[mandarinka]

Dav1d will be always better for us end users, I think that's almost certain. SVT encoders are kind enterprise code which likely won't be too receptive about various issues of users in the wild, who have weird needs like non-AVX2 CPUs, non-mod16/8/4 video (for example) and integration into various players which the coders of these server-side encoders for commercial use are not going to see as important or even be aware of.
Dav1d devs are going to be more in touch with this and generally, the ffmpeg circle sort of development has proved itself with decoders.

[foxyshadis]

Yeah, sort of optional. The spec says it should be there, but its not clear to me if you need to use one of its profiles. You can have a whole list of alternate/compatible brands in such a file. The AVIF spec lists them:
https://aomediacodec.github.io/av1-avif/#profiles-constraints

"avif" from the AVIF spec itself.
"mif1" from HEIF
"miaf" from the MIAF spec
and finally "MA1B" or "MA1A" to identify the AV1 profile in use.
Or various alterations of the above for special types of images.

... this ISOBMFF image format stuff is a real mess. :)

As I read it, "miaf" is required for AVIF, and defines a fair number of important constraints. I wish it was possible to view MIAF's draft standard, but if you aren't in MPEG, ISO, or IEC it looks like that's not possible at all for at least another month.

[Nintendo Maniac 64]

That said, dav1d puts a lot of effort into AVX2, which current-gen Ryzen doesn't even do particularly fast, so..

Though Intel does seem to like segmenting their CPU lineup with regards to AVX feature-set.

[NikosD]

Even the current Ryzen architecture is very fast using dAV1d probably due to the highly multi-threaded nature of both (dAV1d and Ryzen)

The multi-threaded gain seems to be more significant than the AVX2 loss for current-gen Ryzen.

[soresu]

Seems that rav1e is prioritising chunked/segment encoding early on to maximise parallelism, they just opened a new project list to target specific tasks. Link here (https://github.com/xiph/rav1e/projects/9).

[IgorC]

Xiph update on one year of AV1 (slides from NAB 2019) [PDF]
https://people.xiph.org/~negge/NAB2019.pdf

[user1085]

Seems that rav1e is prioritising chunked/segment encoding early on to maximise parallelism, they just opened a new project list to target specific tasks. Link here (https://github.com/xiph/rav1e/projects/9).How does chunked/segment encoding work?

[soresu]

Much like the name suggests, by splitting the file to be encoded by chunks/segments, each being encoded in a separate instance of the encoder, but each also having the lower parallelism of tile or frame based encoding on top of that.

Its more beneficial for systems like servers, or dual socket workstations with large core counts, where the WPP, tile and frame parallel techniques are not enough on their own to saturate all cores with work.

Apparently it has its own problems such as memory consumption and chiefly the time taken to initialise each instance.

Also the segments would have to be chosen based on detected scene change otherwise you could have some very obvious bitrate changes visible mid shot.

I dont think it is suitable for real time encoding, unless you have a significant time delay on transmission to detect scene changes before carving up a new segment to be encoded possibly?

[Dyomich]

MSU HEVC/AV1/VP9 encoding test results:


http://compression.ru/video/codec_comparison/hevc_2018/

dapperdan, thank you for the link. Here is more information about the results:

MSU received many requests on the results of announced AV1 participation in comparison.
AV1 is quickly being developed, but still too slow to participate in our usual fast-universal-ripping use cases.
This is why AV1 was included only in this special report (so as in 2017).

Download free PDF report: http://compression.ru/video/codec_comparison/hevc_2018/pdf/MSU_HEVC_AV1_comparison_2018_P4_HQ_encoders.pdf

This part of the comparison usually releases later because of much lower encoding speed than in other use cases (formal limit was 0.005 fps but actually unlimited).
According to only quality scores, the places of the competitors are the following:

AV1
VP9, x265 and sz265
sz264 and x264

On the speed-quality chart there are four Pareto-optimal participants: AV1, VP9, x264, and SIF Encoder:

http://compression.ru/video/codec_comparison/hevc_2018/figures/speed_quality_av1_2018.png

You can compare the latest results to the results from out similar comparison in 2017 (http://compression.ru/video/codec_comparison/hevc_2017/),
(Important note: in 2017 we used VBR mode for AV1 encoder, and in 2018 constant QP was used, as VBR was several times slower).

[SmilingWolf]

Status report!
"MSU preceded me" edition

1st edition: https://forum.doom9.org/showthread.php?p=1852449#post1852449
2nd edition: https://forum.doom9.org/showthread.php?p=1857587#post1857587
3rd edition: https://forum.doom9.org/showthread.php?p=1860475#post1860475
Whatever paragraph I don't repeat here can be assumed to be the same as in the aforementioned post

First of all: graphs!
Click to enlarge

Y axis: chosen metric
X axis: bits per pixel

720p:
https://i.ibb.co/Sxr5vnm/hvmaf-720.png (https://ibb.co/Sxr5vnm) https://i.ibb.co/vXJCNvM/msssim-720.png (https://ibb.co/vXJCNvM) https://i.ibb.co/XDQ82Xs/psnrhvsm-720.png (https://ibb.co/XDQ82Xs)

1080p:
https://i.ibb.co/sKXkrZV/hvmaf-1080.png (https://ibb.co/sKXkrZV) https://i.ibb.co/PTvVsvN/msssim-1080.png (https://ibb.co/PTvVsvN) https://i.ibb.co/F7mM4YX/psnrhvsm-1080.png (https://ibb.co/F7mM4YX)

BD rates for 720p:
Codecs ladder: | x264 relative:
x264 -> svtav1 | x264 -> svtav1
RATE (%) DSNR (dB) | RATE (%) DSNR (dB)
MSSSIM -3.28672 0.142426 | MSSSIM -3.28672 0.142426
PSNRHVS -4.36439 0.235114 | PSNRHVS -4.36439 0.235114
HVMAF -7.28468 0.186648 | HVMAF -7.28468 0.186648
----------------------------|-----------------------------
svtav1 -> vp9 | x264 -> vp9
RATE (%) DSNR (dB) | RATE (%) DSNR (dB)
MSSSIM -14.9778 0.624669 | MSSSIM -21.5937 1.19737
PSNRHVS -17.0162 0.881864 | PSNRHVS -23.6381 1.70941
HVMAF -17.6481 0.768638 | HVMAF -21.7739 2.36707
----------------------------|-----------------------------
vp9 -> x265 | x264 -> x265
RATE (%) DSNR (dB) | RATE (%) DSNR (dB)
MSSSIM -5.14321 0.226527 | MSSSIM -25.8745 1.38639
PSNRHVS -8.41874 0.455384 | PSNRHVS -30.4345 2.09471
HVMAF -13.8727 0.673276 | HVMAF -31.395 3.32434
----------------------------|-----------------------------
x265 -> av1 | x264 -> av1
RATE (%) DSNR (dB) | RATE (%) DSNR (dB)
MSSSIM -17.7008 0.800381 | MSSSIM -36.613 2.16722
PSNRHVS -14.1648 0.748597 | PSNRHVS -37.5985 2.80939
HVMAF -12.6967 0.474379 | HVMAF -39.7078 2.87016

BD rates for 1080p:
Codecs ladder: | x264 relative:
x264 -> svtav1 | x264 -> svtav1
RATE (%) DSNR (dB) | RATE (%) DSNR (dB)
MSSSIM -2.03138 0.058404 | MSSSIM -2.03138 0.058404
PSNRHVS 3.95915 -0.147954 | PSNRHVS 3.95915 -0.147954
HVMAF -4.05114 -0.0123967 | HVMAF -4.05114 -0.0123967
-----------------------------|------------------------------
svtav1 -> vp9 | x264 -> vp9
RATE (%) DSNR (dB) | RATE (%) DSNR (dB)
MSSSIM -29.5206 1.00448 | MSSSIM -33.7275 1.65389
PSNRHVS -32.951 1.40212 | PSNRHVS -33.0678 2.11895
HVMAF -34.7504 1.33459 | HVMAF -33.0663 3.73028
-----------------------------|------------------------------
vp9 -> x265 | x264 -> x265
RATE (%) DSNR (dB) | RATE (%) DSNR (dB)
MSSSIM 6.91124 -0.232017 | MSSSIM -30.515 1.24701
PSNRHVS 2.12517 -0.103003 | PSNRHVS -32.954 1.71647
HVMAF -5.87407 0.106315 | HVMAF -35.0935 3.13962
-----------------------------|------------------------------
x265 -> av1 | x264 -> av1
RATE (%) DSNR (dB) | RATE (%) DSNR (dB)
MSSSIM -28.0678 0.994389 | MSSSIM -47.6133 2.2674
PSNRHVS -23.2568 0.966762 | PSNRHVS -45.5839 2.73622
HVMAF -24.6825 0.769329 | HVMAF -50.6976 3.39944

Encoders:
x264 157-2935-545de2f
x265 3.0-1-ed72af837053
libvpx-vp9 1.8.0-374-gb758ba795
SVT-AV1 0.0.1-525-5a8b857e
libaom 1.0.0-1605-g64a2ffb72

Cmdlines:
x264 --preset veryslow --tune ssim --crf 16 -o test.x264.crf16.264 orig.i420.y4m
x265 --preset veryslow --tune ssim --crf 16 -o test.x265.crf16.hevc orig.i420.y4m
vpxenc --codec=vp9 --frame-parallel=0 --tile-columns=1 --auto-alt-ref=6 --good --cpu-used=0 --tune=psnr --passes=2 --threads=2 --end-usage=q --cq-level=20 --test-decode=fatal --ivf -o test.vp9.cq20.ivf orig.i420.y4m
SvtAv1EncApp.exe -i orig.i420.yuv -b test.svtav1.cq20.ivf -w 1280 -h 720 -q 20 -enc-mode 3 -fps-num 24000 -fps-denom 1001 -intra-period 23
aomenc --frame-parallel=0 --tile-columns=1 --auto-alt-ref=1 --cpu-used=4 --tune=psnr --passes=2 --threads=2 --row-mt=1 --end-usage=q --cq-level=20 --test-decode=fatal -o test.av1.cq20.webm orig.i420.y4m
VMAF: model used: vmaf_v0.6.1, pooling: harmonic_mean

Notes:
TearsOfSteel720 and TheFifthElement, two clips in the 720p category, have a vertical resolution incompatible with SvtAv1EncApp (not divisible by 8), so they have been excluded from all measurements this time.
Next time they will be padded, all the encodes re-made and quality measurements re-taken.
Meanwhile, rav1e has got a nasty bug that makes it bloat encodes, which brings up to 25% BD rate regression, so it has been excluded from this edition.
I'll try to post an amendment when the above problems have been fixed.

This concludes this report.
As always, I'm open to any kind of feedback to improve my comparisons and my encodes.

[Nintendo Maniac 64]

Status report!

Good to see you're not dead - you hadn't logged in for nearly 4 months. :p


Anyway quick question - since dav1d seems to be pretty much the standard go-to AV1 decoder nowadays, I don't suppose you'd be interested in the possibility of more decoder performance tests?

Basically I'm thinking how that Presage Flower video clip you had me test is going to have pretty outdated results regarding AV1's relative CPU software decoding requirements (https://forum.doom9.org/showthread.php?p=1859536#post1859536) seeing as dav1d is like 50% faster even on CPUs that don't support AVX (I've not yet tested it on CPUs without SSE4.1 and/or SSSE3 however).

[singhkays]

Status report!

Glad to see this! I'm working on a sub-500Kbps comparison myself for AV1/x264/VP9 (this is to replace GIF with the smallest video that'll play natively in a browser)

Do you know how these new commandline options in ffmpeg affect quality/speed for AV1?

enable_cdef, enable_global_motion, and intrabc

https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/995889abbf31389aa0f002ea6599c7c89526d1d6

[marcomsousa]

1) Comparision of libaom, SVT-AV1 and rav1e for still-image coding on subset1 from derf's collection. JPEG files are also encoded with libjpeg for the reference.
https://github.com/Kagami/av1-bench/raw/master/graphs/still1.png
https://github.com/Kagami/av1-bench

2) go-avif comes with handy CLI utility avif. It supports encoding of JPEG and PNG files to AVIF
Static 64-bit builds for Windows, macOS and Linux are available at releases page.
https://github.com/Kagami/go-avif


3) AVIF (AV1 Still Image File Format) polyfill for the browser
https://github.com/Kagami/avif.js
demo https://kagami.github.io/avif.js/

[Nintendo Maniac 64]

Any comparisons for lossless AVIF?

[marcomsousa]

Chrome will use dav1d by default for decoding.
Chromium 74 [1] (week of 2019-Apr-23)
https://chromium.googlesource.com/chromium/src.git/+/ede4345734371ac35b4e50cea7ef3332dabd54d5%5E%21/

[SmilingWolf]

Any comparisons for lossless AVIF?

I've got you covered... somewhat. My comparison was made with a mix of CG wallpapers and Pixiv anime fanart. Here: https://docs.google.com/spreadsheets/d/1bG-CSTn_L79MtS7A-wR572H5_W_3kb2xX5AWagKn1ak/
The numbers are 3 months old but I don't think they have moved too much.

Yup, not ded, but busy :)

Unless dav1d has started adding 10bit asm or has made big improvements in the multithreading department I don't think there'll be much to see w.r.t. improvements against my Presage Flower encode (10bit YUV420P), but you're very welcome to try and prove me wrong of course, benchmarks are always good!


Do you know how these new commandline options in ffmpeg affect quality/speed for AV1?
https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/995889abbf31389aa0f002ea6599c7c89526d1d6
I never tested any of that flags with the exception of frame_parallel, which I always set to 0 (disabled).
I'd imagine one would want to leave the CDEF filter on, but I have hardly any idea what most of the others do.

[Nintendo Maniac 64]

I've got you covered... somewhat. My comparison was made with a mix of CG wallpapers and Pixiv anime fanart. Here: https://docs.google.com/spreadsheets/d/1bG-CSTn_L79MtS7A-wR572H5_W_3kb2xX5AWagKn1ak/


a30.png
a_cs03.png

Gee that file name formatting sure looks familiar... ＊double checks the contents of "bgimage.xp3"＊ yup, knew it.


Also it's kind of neat that one can access the source pixiv artwork's page with nothing more than just the file name since it's the same set of numbers used in both the file name and in a given artwork's web page URL.


Unless dav1d has started adding 10bit asm or has made big improvements in the multithreading department I don't think there'll be much to see w.r.t. improvements against my Presage Flower encode (10bit YUV420P)
Oh derp, I completely forgot about it being 10bit. However, dav1d apparently does scale across multiple CPU threads extremely well.

[singhkays]

I never tested any of that flags with the exception of frame_parallel, which I always set to 0 (disabled).
I'd imagine one would want to leave the CDEF filter on, but I have hardly any idea what most of the others do.

Actually, after I posted I found more info in the AV1 paper here https://jmvalin.ca/papers/AV1_tools.pdf

Intra Block Copy: AV1 allows its intra coder to refer backto previously reconstructed blocks in the same frame, in a mannersimilar to how inter coder refers to blocks from previous frames.It can be very beneficial for screen content videos which typicallycontain repeated textures, patterns and characters in the same frame.Specifically, a new prediction mode named IntraBC is introduced, andwill copy a reconstructed block in the current frame as prediction. Thelocation of the reference block is specified by a displacement vector ina way similar to motion vector compression in motion compensation.Displacement vectors are in whole pixels for the luma plane, andmay refer to half-pel positions on corresponding chrominance planes,where bilinear filtering is applied for sub-pel interpolation.

Warped Motion Compensation: Warped motion models areexplored in AV1 by enabling two affine prediction modes, globaland local warped motion compensation [10]. The global motiontool is meant for handling camera motions, and allows conveyingmotion models explicitly at the frame level for the motion betweena current frame and any of its reference

Constrained Directional Enhancement Filter (CDEF): CDEFis a detail-preserving deringing filter designed to be applied afterdeblocking that works by estimating edge directions followed byapplying a non-separable non-linear low-pass directional filter of size5×5 with 12 non-zero weights [14]. To avoid extra signaling, thedecoder computes the direction per 8×8 block using a normative fastsearch algorithm that minimizes the quadratic error from a perfectdirectional pattern

I tested out these options with the following CLI however, I saw no change in the average bitrate of the output file, speed of encoding or any difference in VMAF scores of different files.

./ffmpeg -i scene3.mp4 -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-rows 0 -tile-columns 2 -row-mt 1 -threads 8 -pass 1 -f mp4 -y /dev/null &&
./ffmpeg -i scene3.mp4 -pix_fmt yuv420p -movflags faststart -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-rows 0 -tile-columns 2 -row-mt 1 -threads 8 -pass 2 -hide_banner ./av1/av1_200k-none.mp4

./ffmpeg -i scene3.mp4 -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-rows 0 -tile-columns 2 -enable-cdef 1 -enable-global-motion 1 -enable-intrabc 1 -row-mt 1 -threads 8 -pass 1 -f mp4 -y /dev/null &&
./ffmpeg -i scene3.mp4 -pix_fmt yuv420p -movflags faststart -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-rows 0 -tile-columns 2 -enable-cdef 1 -enable-global-motion 1 -enable-intrabc 1 -row-mt 1 -threads 8 -pass 2 -hide_banner ./av1/av1_200k-all.mp4

./ffmpeg -i scene3.mp4 -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-rows 0 -tile-columns 2 -enable-cdef 1 -row-mt 1 -threads 8 -pass 1 -f mp4 -y /dev/null &&
./ffmpeg -i scene3.mp4 -pix_fmt yuv420p -movflags faststart -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-rows 0 -tile-columns 2 -enable-cdef 1 -row-mt 1 -threads 8 -pass 2 -hide_banner ./av1/av1_200k-cdef-only.mp4

./ffmpeg -i scene3.mp4 -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-rows 0 -tile-columns 2 -enable-global-motion 1 -row-mt 1 -threads 8 -pass 1 -f mp4 -y /dev/null &&
./ffmpeg -i scene3.mp4 -pix_fmt yuv420p -movflags faststart -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-rows 0 -tile-columns 2 -enable-global-motion 1 -row-mt 1 -threads 8 -pass 2 -hide_banner ./av1/av1_200k-globmotion-only.mp4

./ffmpeg -i scene3.mp4 -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-rows 0 -tile-columns 2 -enable-intrabc 1 -row-mt 1 -threads 8 -pass 1 -f mp4 -y /dev/null &&
./ffmpeg -i scene3.mp4 -pix_fmt yuv420p -movflags faststart -c:v libaom-av1 -b:v 200k -filter:v scale=720:-1 -strict experimental -cpu-used 1 -tile-rows 0 -tile-columns 2 -enable-intrabc 1 -row-mt 1 -threads 8 -pass 2 -hide_banner ./av1/av1_200k-intrabc-only.mp4

[soresu]

Wow, I suspected SVT-AV1 to have lower quality, but not so bad as this - it barely seems to pass x264 and is worse at some resolutions and bitrates.

Wasnt rav1e supposed to have passed x264 quality some time ago?

If these graphs match to VMAF too, I cant see why Netflix would announce support for SVT-AV1 when they already have a performant VP9 solution which presumably at least matches libvpx quality, if not better with EVE-VP9.

[marcomsousa]

I cant see why Netflix would announce support for SVT-AV1 when they already have a performant VP9 solution which presumably at least matches libvpx quality, if not better with EVE-VP9.

Netflix choose SVT-AV1 because of architecture, language and how scalable it is.

"SVT-AV1 uses parallelization at several stages of the encoding process."
"However, rav1e is written in Rust programming language, whereas an encoder written in C has a much broader base of potential developers."

The quality is a matter of time.


Introducing SVT-AV1: a scalable open-source AV1 framework by Netflix
https://medium.com/netflix-techblog/introducing-svt-av1-a-scalable-open-source-av1-framework-c726cce3103a

[SmilingWolf]

Wasnt rav1e supposed to have passed x264 quality some time ago?

Oh it absolutely did, as far back as 4 months ago (https://forum.doom9.org/showthread.php?p=1860475#post1860475) already.
Unfortunately there's a bug (#1081 (https://github.com/xiph/rav1e/issues/1081)) that is currently badly damaging the BD rates, so no comparison from me until that's fixed. One of the PRs (#1215 (https://github.com/xiph/rav1e/pull/1215)) seems promising in that regards, after some ironing out it should bring the encoding efficiency back on track.

[mandarinka]

Nice metrics in those curves are nice, but in reality, is the ability to keep the visual quality good there?

That said, I don't think it's even fair to expect miracles until there's adaptive quantization. I don't think there has been a good encoder without adaptive quantization yet (and psyrdo too possibly?) so if we're just assuming Rav1e won't need it, that might be kind of unwarranted.

[benwaggoner]

Much like the name suggests, by splitting the file to be encoded by chunks/segments, each being encoded in a separate instance of the encoder, but each also having the lower parallelism of tile or frame based encoding on top of that.

Its more beneficial for systems like servers, or dual socket workstations with large core counts, where the WPP, tile and frame parallel techniques are not enough on their own to saturate all cores with work.

Apparently it has its own problems such as memory consumption and chiefly the time taken to initialise each instance.
This isn't too bad if you use >>10 second chunks. Not how YouTube does it, but more common common for premium content

Also the segments would have to be chosen based on detected scene change otherwise you could have some very obvious bitrate changes visible mid shot.
This is the bigger problem. Beyond scene changes, ensuring VBV compliance at splice points requires either very conservative rate control near splice points, or risk out of comformance spikes. This isn't a huge deal with SW decoders (although a bitrate spike will likely result in dropped frames in a complex high motion scene where dropped frames are most visible). But it can be a serious issue with HW decoders; either they can't handle existing content, or the die size and cost has to increase to handle out-of-spec streams. This was a big deal ~10 years ago when x264 didn't enforce levels requirement, and a 1080p flagged as Level 4.0 could still have 9 reference frames and break decoders.

I dont think it is suitable for real time encoding, unless you have a significant time delay on transmission to detect scene changes before carving up a new segment to be encoded possibly?
Best-case, latency increases by max chunk duration. So you get into quality/latency tradeoffs. Definitely not feasible for videoconferencing!

Note that "real" encoders get around these issues by using frame-level parallelism. x265 can saturate a good number of cores at 1080p.

[benwaggoner]

1) Comparision of libaom, SVT-AV1 and rav1e for still-image coding on subset1 from derf's collection. JPEG files are also encoded with libjpeg for the reference.
https://github.com/Kagami/av1-bench/raw/master/graphs/still1.png
https://github.com/Kagami/av1-bench
VMAF isn't a still image metric. Has anyone run a correlation for VMAF against subjective testing for still images? If not, I wouldn't trust it as a metric for this use case. Nor PSNR or SSIM.

2) go-avif comes with handy CLI utility avif. It supports encoding of JPEG and PNG files to AVIF
Static 64-bit builds for Windows, macOS and Linux are available at releases page.
https://github.com/Kagami/go-avif
With PNG in there, wouldn't we be comparing YUV<>RGB?

[benwaggoner]

Nice metrics in those curves are nice, but in reality, is the ability to keep the visual quality good there?
Since libaom's encoding was tuned with VMAF, we'd expect it to have a higher VMAF at any given subjective quality than other encoders that weren't tuned against it. There have been several papers that have shown HEVC or VVC's reference encoders delivering subjectively superior quality than AV1 even when VMAF predicts AV1 will look better.

VMAF is our least-bad objective metric ever, and keeps on getting better. But like any ML system, it is fundamentally a statistics-driven system that tries to give the same answer given similar data as the data-answer pairs it was trained on. So VMAF isn't going to be great at discriminating between AV1 and VVC artifacts without a lot of double-blind subjective ratings of AV1 and VVC artifacts.

This isn't a bug in VMAF; it's just the way that systems like that work.

That said, I don't think it's even fair to expect miracles until there's adaptive quantization. I don't think there has been a good encoder without adaptive quantization yet (and psyrdo too possibly?) so if we're just assuming Rav1e won't need it, that might be kind of unwarranted.

Right, and VMAF is insensitive to lots of adaptive quant psychovisual optimizations. For example, it doesn't do a good job of picking up on gradients or banding in darker scenes, for example. I'm guessing they didn't have a lot of variations of adaptive quant modes in their test set, so VMAF didn't get trained to distinguish between them.

And even with HVMAF, keyframe strobing will be hard to notice as it is just one bad frame per GOP. I don't know how many IDR frames VMAF was tested against; lots of codec tests wind up being a single long GOP, or scene-adaptive IDR only. So cases where a shot is longer than the max GOP duration may not have been sampled much.