Intel SVT-AV1

[ShortKatz]

SVT-AV1 has now a tune=4 which is a Multi-Scale Structural Similarity (MS-SSIM) and SSIMULACRA2 optimized mode. Is this only meant for pictures, because it was included in the still image MR? Or can this also be useful for videos?

[benwaggoner]

Originally Posted by ShortKatz

SVT-AV1 has now a tune=4 which is a Multi-Scale Structural Similarity (MS-SSIM) and SSIMULACRA2 optimized mode. Is this only meant for pictures, because it was included in the still image MR? Or can this also be useful for videos?

They would be more useful that PSNR and SSIM, because they are more perceptually accurate metrics. But those are all still single-frame metrics, which means they'll have a lot of false positives and false negatives when used for moving image content. This can be improved partially but not completely with really good analysis of variations between per-frame quality ratings, but there will still be things like grain strobing that this sort of metric is bad at detecting.

[Z2697]

Use tune 0 for better detail (or just switch to x265/4), use tune 1 for "smoosh eye candy/cer". tune 2 feels like something in between.
tune 3 and 4 are for AVIF.
The metrics name in the tune name mean nothing.

If bitrate is high, always prefer tune 0, with low bitrate, it kinda depends on how you or the audience think about "more detail but more noticeable artefact" versus "less detail but smooth and 'clean'"

[hajj_3]

https://gitlab.com/AOMediaCodec/SVT-...eleases/v4.0.0

Release notes
[4.0.0] - 2026-1-23

API updates:

Major release with new API updates that are not backwards compatible.
Extended the crf range to 70 reducing the impact or QP scaling allowing the encoder to reach lower bitrates
Added quarter steps between crf increments to allow for further granularity in qp selection
Added support for setting a custom global logger for library consumers (!2570 (merged), !2579 (merged))
Cleaned up public API headers including removal of deprecated macros, structs, and fields (!2565 (merged), !2568 (merged))
Additionally cleaned up anything marked using SVT_AV1_CHECK_VERSION().
Added ability to calculate per-frame PSNR and SSIM metrics (!2521 (merged))
Allow sending more than 1 but less than 4 frames with avif mode (This is not for AVIF image sequence, but for encoding an alpha layer) (!2551 (merged), !2560 (merged))
Added tune IQ and MS-SSIM for Still Image coding mode

Encoder:

Significant improvements in AVIF and still image modes (!2552 (merged),!2567 (merged)):
~5-8x speedup M11-M0 at the same quality levels with tune MS-SSIM
~5-8% BD-Rate improvements at the same complexity with tune MS-SSIM
Tradeoff improvements for the RTC modes (!2558 (merged)):
~5-15% speedup at similar quality levels in --rtc mode across presets 7 - 11
Tradeoff improvements for the Random Access mode (VOD use case) showing a 10-25% speedup across presets M7 down to M0 for --fast-decode 1 and 2 (!2558 (merged))
Major feature updates for the visual quality mode with the completion porting all SVT-AV1-PSY applicable features for --tune vq for video and --tune iq for avif (!2484 (merged), !2489 (merged), !2491 (merged), !2494 (merged), !2496 (merged), !2503 (merged), !2504 (merged), !2507 (merged), !2514 (merged), !2522 (merged) , !2561 (merged), !2562 (merged), !2576 (merged)):
Added AC Bias, a psychovisual feature that improves detail preservation and film grain retention
Update S-Frame support to allow setting it in a specific decode order option and with more qp options (!2477 (merged) !2523 (merged) !2534 (merged))
Further Arm Neon and SVE2 optimizations that improve high bitdepth encoding by an average of ~5% in low resolutions
Cleanup, Build and bug fixes, testing and documentation

General code cleanup, bugfixes, documentation and console output changes:

Bugfixes: Fixed an issue with the encoder hanging when given an input with a height of 24 pixels or less (!2518 (merged))
Bugfixes: Fixed a bug that results in encoding an invalid bitstream when using rtc with a high QP value (!2502 (merged))
Bugfixes: Fixed a hang with VBR encoding (#2300 (closed), !2535 (merged))
Bugfixes: Fixed a hang when using recon output with low delay mode (#2315 (closed), !2544 (merged))
Bugfixes: Fixed an encoder crash when using RTC with resolutions not divisible by 16 and presets >= 11 (#2301 (closed), !2547 (merged))
Bugfixes: Fixed bitstream level tier compliance with AV1 specification (#2332 (closed), !2577 (merged), !2581 (merged), !2587 (merged))
Cleanup: Removed in-tree gstreamer plugin (!2586 (merged))
Cleanup: Code specific cleanup for slimmer binary sizes (!2476 (merged))
Testing: Added CI coverage for compiling FFmpeg on macOS Arm (!2536 (merged))
Testing: Added a python based testing framework for comparing codec performance and quality (!2532 (merged), !2550 (merged), !2556 (merged), !2563 (merged), !2564 (merged), !2566 (merged))

[benwaggoner]

Was that really 5-8x speedup with MS-SSIM, not 5-8%?

[Z2697]

Not impossible I'd say, considering it's AVIF specific, and how video encoder might be (very) unoptimized for single frame encoding before.
Easy to test out but I don't care...

[hajj_3]

https://gitlab.com/AOMediaCodec/SVT-...eleases/v4.0.1

Release notes [4.0.1] - 2026-01-28:

Fixed a missing version bump for shared library and pkg-config (!2593 (merged))
This is now tied to the CMake project version and should not happen again.
Added a CI check to verify this going forward (!2594 (merged))
Fixed tf-strength's default value in the help output (!2595 (merged))
Cleaned up some old debug prints and fixed some Windows build warnings (!2596 (merged))
Fixed bug in incorrect plane selection in quantize_inv_quantize (!2597 (merged))
Fixed hang caused by incorrect update of looping variable in pic_manager_process (!2600 (merged))

[Z2697]

It's been 6 or 7 years. I wonder how good x264 was when it's 6 or 7 years old.

[Blue_MiSfit]

That's about how old x264 was when it started to get really good (VAQ, Psy RD/RDOQ, MB Tree etc) in the late 00s. Kind of apples to apples though

[charliebaby]

new Version SVTAV1APP.EXE 4.0.1

https://www.mediafire.com/file/20qru...v4.01.rar/file

[VoodooFX]

Originally Posted by Z2697

It's been 6 or 7 years. I wonder how good x264 was when it's 6 or 7 years old.

I would say it took ~5 years for x264 to surpass XviD in all scenarios.

AV1, with all zilliards backing it, is still struggling against x265 after ~7 years...

[rwill]

Originally Posted by VoodooFX

I would say it took ~5 years for x264 to surpass XviD in all scenarios.

AV1, with all zilliards backing it, is still struggling against x265 after ~7 years...

It is interesting that recent subjective quality improvements of SVT-AV1 can be traced back to some community forks which copied code and concepts from x264. From what I can tell these even had to fight to get their improvements into the main version. These community forks also tend to weaken or outright disable AV1 tools which gave AV1 that VMAF edge against x265 when YouTube creators pushed the new "patent free" format years ago.

I also start to feel offended by the amount of "just lower CRF" recommendations people get that ask how to improve their detail decimated AV1 encodes....

Rather sad state.

[GeoffreyA]

Originally Posted by rwill

It is interesting that recent subjective quality improvements of SVT-AV1 can be traced back to some community forks which copied code and concepts from x264. From what I can tell these even had to fight to get their improvements into the main version. These community forks also tend to weaken or outright disable AV1 tools which gave AV1 that VMAF edge against x265 when YouTube creators pushed the new "patent free" format years ago.

I also start to feel offended by the amount of "just lower CRF" recommendations people get that ask how to improve their detail decimated AV1 encodes....

Rather sad state.

They've done good work on the forks, but one gets the feeling that they're up against the format itself. Perhaps there are legacy issues in the design, considering that AV1 descends from On2's TrueMotion and VPx codecs.

[Z2697]

Originally Posted by rwill

I also start to feel offended by the amount of "just lower CRF" recommendations people get that ask how to improve their detail decimated AV1 encodes....

Lowering CRF is an efficient way to improve quality in x264/5 though.

But current AV1 encoder (mainline ones, at least) can't guarantee that, I mean lowering CRF does increase the quality within this codec, but does not make a difference that's comparable to x264/5.
So maybe the answer should be "just switch to x265". (unless they are somehow forced to use AV1) (and maybe not allowed in an AV1 subreddit or something)

But if one wants something low bitrate and still OK to watch, AV1 it the choice, maybe give some credit to that?
Maybe your private HEVC encoder can do that as well, but that's not available to the public.

[rwill]

So when someone needs smaller streams is "just raise CRF" a valid answer?

[Z2697]

I guess technically yes...
That's one way of doing it. (and the most direct one)

[rwill]

I think I can match AV1 quality with Xvid by "just lowering CRF" and match AV1 file sizes with Xvid by "just raising CRF", but at that point what are we even talking about...

[charliebaby]

this test SVT-AV1 v4.01 + Me Setting :-)

[Boulder]

In v4, they did some terrible decisions to make the encoder apparently faster. A lot of quality improving settings were shifted to much lower presets than P2, which has been a sweet spot for a long time. The people working on the forks are actively reverting these changes

[VoodooFX]

Originally Posted by charliebaby

this test SVT-AV1 v4.01 + Me Setting :-)

Here is x264 test using rwill settings:

Originally Posted by rwill

I think I can match AV1 quality with Xvid by "just lowering CRF" and match AV1 file sizes with Xvid by "just raising CRF", but at that point what are we even talking about...

That's ungraspable for lowbrains.