rav1e VS SVT-AV1

Sure. You'll see it very often in codec implementations. From rav1e, a fast AV1 encoder mostly written in Rust: https://github.com/xiph/rav1e/tree/master/src/x86

Large portions of the algorithm have been translated into assembly for ARM and x86. Shaving even a couple percent off something like motion compensation search will add up to meaningful gains.

Or the current reference implementation of JPEG: https://github.com/libjpeg-turbo/libjpeg-turbo/tree/main/sim...

You can speed up the sampling process with --vmaf n_subsample=5, which in my experience works more accurately than either 2 or 4, possibly due to this bug/feature present in multiple encoders. You might also need to manually set the number of threads used for VMAF calculation with --vmaf n_threads=16, but YMMV.

That remember me of https://github.com/xiph/rav1e which is an AV1 encoder

It's getting there.. Initial steps for FFmepg: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8444 rav1e: https://github.com/xiph/rav1e/pull/3000

I doubt much will be done on such an exotic feature any time soon. Progress has been slow on rav1e, it's missing a lot of features, and only supports tile threading.

rav1e is quite well maintained, the fix for the lint was merged days after the ilog PR merged. But the 0.5.1 release of rav1e was one year ago, in December 2021, while the ilog rename was end of August 2022. There hadn't been a release though of rav1e until end of November 2022, which was also a semver incompatible one. Users had only 2-ish months of time to get to the new rav1e version without experiencing breakage.

The rav1e encoder for AV1 has more assembly in it than Rust, which also doesn't bode well for memory-safe video codec implementations. But this might change once Rust provides portable and memory-safe explicit SIMD.

1. Compile this: https://gitlab.com/AOMediaCodec/SVT-AV1

2. ffmpeg -i infile.mp4 -map 0:v:0 -pix_fmt yuv420p10le -f yuv4mpegpipe -strict -1 - | SvtAv1EncApp -i stdin --preset 6 --keyint 240 --input-depth 10 --crf 30 --rc 0 --passes 1 --film-grain 0 -b infile.ivf

3. ffmpeg -i infile.ivf -i infile.mp4 -map 0:v -map 1:a:0 -c copy outfile.mp4

In these tests SVT-AV1 beats x265 on quality:

- FullHD: http://compression.ru/video/codec_comparison/2022/main_repor...

- FullHD 10-bit: http://compression.ru/video/codec_comparison/2022/10_bit_rep...

- 4K: http://compression.ru/video/codec_comparison/2022/4k_report....

SVT-AV1 has seen a number of speed ups in recent releases:

https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases

Handy list of 1.6.0 of pre-compiled binary's: https://gitlab.com/AOMediaCodec/SVT-AV1/-/pipelines/911865688

I find it interesting that you know the project well enough to get to the pre-compiled binaries page, yet somehow missed that the merge request explictly calls out a VMAF LOSS for the SSIM tune by several percentage points.

SVT-AV1 has no NEON.

Any code experts want to look at the commits between 1.6 and 1.5 and see how this speedup was achieved? https://gitlab.com/AOMediaCodec/SVT-AV1/-/commits/master

Binaries (incl. FFmpeg) should be here: https://gitlab.com/AOMediaCodec/SVT-AV1/-/pipelines/907000565

I am on Win10, use it from CLI. The most recent ffmpeg 6.0 will have svt-av1 1.4.1 version , for the newest build 1.5.0 you can get it from https://gitlab.com/AOMediaCodec/SVT-AV1/-/pipelines/850420031, search for ffmpeg.

I believe --hierarchical-levels is the setting to change the mini-gop. Most of the time you don't want to change it from the default, though.