title: Deep Dive into SVT-AV1's Evolution (Part 2): Encoder Parameters Revisited

description: Let's discover some new (and revisit some old) SVT-AV1 parameters!

title: Original Codec Wiki article

text: Introduction

anchor: introduction

text: SVT-AV1 v3.0.x Parameters Revisited

text: Variance Boost

anchor: variance-boost

text: Varboost Strength

anchor: varboost-strength

text: ...starting with --variance-boost-strength 1!

text: Let's continue with --variance-boost-strength 2, the default strength value in every iteration of SVT-AV1:

text: Now for --variance-boost-strength 3:

text: And lastly, --variance-boost-strength 4, which will print you a warning that this may be too aggressive in some usecases:

text: Varboost Octile

anchor: varboost-octile

text: ...starting with --variance-octile 1!

text: Let's look at --variance-octile 2:

text: Let's test --variance-octile 3:

text: And --variance-octile 4:

text: And --variance-octile 5!

text: What about --variance-octile 6, the default octile value in every iteration of SVT-AV1:

text: Following with --variance-octile 7 tests:

text: And lastly --variance-octile 8 testing:

text: Varboost Curve

anchor: varboost-curve

text: ...with the default settings first:

anchor: with-the-default-settings-first

text: Varboost Conclusion

anchor: varboost-conclusion

text: --tune

anchor: --tune

text: --luminance-qp-bias

anchor: --luminance-qp-bias

text: --sharpness

anchor: --sharpness

text: --tf-strength

anchor: --tf-strength

text: --lossless

anchor: --lossless

text: --fast-decode

anchor: --fast-decode

text: Preset 2

text: Preset 4

text: Preset 6

text: Fast Decode Conclusion

anchor: fast-decode-conclusion

text: Tiles

anchor: tiles

text: Statistics

anchor: statistics

text: Conclusion

text: Future

anchor: future

markdown:
# Introduction

Welcome to the second part of my SVT-AV1 testing analysis!

I received lots of kind words, including constructive feedback to improve on my methodology, I sincerely appreciate it! While I couldn’t incorporate those suggestions for this follow-up, stay tuned, because you’ll likely hear more from me before summer ends.

Before we continue, if you haven’t seen Part 1 yet, I recommend giving it a quick look! It covers the test methodology, sample clips, and base encoder settings in detail. The only change to this Part is my decision to remove the *full* graphs in an attempt to cut down on bloat. If you really want to, you can still access them on the repository where we upload pictures for the blog posts [here](https://github.com/av1-community-contributors/images).

Now, without further ado, let’s dive right back in where we left off!

## SVT-AV1 v3.0.x Parameters Revisited

Today, we are looking at **8 encoder features** present in SVT-AV1 v3.0.x! Although we won't be revisiting *every* encoder parameter like we did back in the first deep dive on v1.8.0, we are going to concentrate on a few important ones, some of them coming straight from the *SVT-AV1-PSY* project!

Let's start with the feature you are likely most exciting about: *varboost*!

### Variance Boost

The author of variance boost made a highly visual explanation of the feature in the official SVT-AV1 documentation you can find [here](https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/Appendix-Variance-Boost.md). This overview will probably do a better job than me in describing what it does, but in a few words, *varboost* allocates more bits to low-contrast areas in a frame.

You can enable varboost via the `--enable-variance-boost` parameter and control its behavior by changing its `--variance-boost-strength` or its `--variance-octile` setting. Basically, the strength controls how much areas are to be boosted, while octile controls how much of the area needs to be deemed low-contrast before being boosted.

> *In every graph of this section, you will notice `vbs_o_` in the legend. The `vb` stands for `varboost`, the `s` stands for `strength` and lastly the `o` stands for octile. In the last subsection, you will even see `vbs_o_c_` with the `c` standing for `curve`. To take one example, `vbs1o4c2` means `varboost at strength 1 and octile 4 on the 2nd curve`.*

---
#### Varboost Strength

We're going to test all 4 available *strengths* values, with *octile* as the variable...

##### ...starting with `--variance-boost-strength 1`!

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

At HQ, on almost all metrics (excepted VMAF which is more inconsistent here), all octile values are more efficient than *varboost disabled*. With one notable exception in *octile 8* which often scores the same or worse than *no varboost* depending on the clip. The lower octiles seem to score increasingly better here.

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

At LQ, the results tend to be the same, however there are more outliers and overall the octile value seem to be more negligible. *No varboost* often scores better than many octile values on VMAF, which is an interesting behavior to observe.

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

In terms of speed, we won't be surprised to learn that the lower octile you go, the slower the encoding instance will be, as the output filesize is bigger and that *tends* to slow down SVT-AV1. By bitrate normalizing, we would get closer performance between all options.

---> Interpretation:

`1` is the most conservative strength value, so we expect reasonable results from varboost here. All octile values consistently provide efficiency improvements except for `--variance-octile 8`. It is counter-intuitive to see lower octiles score better in efficiency so far, but we'll see if that changes as we increase the strength.

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/mVtRwupm) | [Avatar (LQ)](https://slow.pics/c/Qoa3amhs) |
| [Ducks (HQ)](https://slow.pics/c/LpnpWeCh) | [Ducks (LQ)](https://slow.pics/c/Ei6cY7hT) |
| [Fallout (HQ)](https://slow.pics/c/HzcmlT95) | [Fallout (LQ)](https://slow.pics/c/H4lJgTSZ) |
| [Minecraft (HQ)](https://slow.pics/c/EcRac2q1) | [Minecraft (LQ)](https://slow.pics/c/7zucoraP) |
| [Sol Levante (HQ)](https://slow.pics/c/Ra474TKQ) | [Sol Levante (LQ)](https://slow.pics/c/dfo9gMIX) |
| [Suzume (HQ)](https://slow.pics/c/HF6ls9AW) | [Suzume (LQ)](https://slow.pics/c/RaZ0Q6SM) |
| [Mandalorian (HQ)](https://slow.pics/c/0vwqi52J) | [Mandalorian (LQ)](https://slow.pics/c/9dBsnQaJ) |

##### Let's continue with `--variance-boost-strength 2`, the default *strength* value in every iteration of SVT-AV1:

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

The picture is consistent with what we've previously seen, so I won't repeat myself. However, we must keep in mind that the higher strength and the lower octile we go, the more the curve is shifted to the top right, which *may not* paint the most fair picture of the situation and might skew our interpretation in favor of the one end of the graph or another. That being said, except for VMAF which behaves a bit differently with varboost, we see the default of `--variance-boost-strength 2 --variance-octile 6` always increases efficiency over *no varboost* across basically all clips and metrics, so we can confidently say it does live up to its promise.

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/ij7c8xbT) | [Avatar (LQ)](https://slow.pics/c/I8VX0gmb) |
| [Ducks (HQ)](https://slow.pics/c/SRIm1hoy) | [Ducks (LQ)](https://slow.pics/c/SR3f3YWp) |
| [Fallout (HQ)](https://slow.pics/c/7NeqER2Z) | [Fallout (LQ)](https://slow.pics/c/CQFdBB9C) |
| [Minecraft (HQ)](https://slow.pics/c/crBjBTvx) | [Minecraft (LQ)](https://slow.pics/c/hfA0CXrp) |
| [Sol Levante (HQ)](https://slow.pics/c/3l2dOaoE) | [Sol Levante (LQ)](https://slow.pics/c/cSDSKnv7) |
| [Suzume (HQ)](https://slow.pics/c/pSVfrZSK) | [Suzume (LQ)](https://slow.pics/c/1B0Af0Ta) |
| [Mandalorian (HQ)](https://slow.pics/c/t6MEfwHh) | [Mandalorian (LQ)](https://slow.pics/c/UJmCWT1T) |

##### Now for `--variance-boost-strength 3`:

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

It's more of the same, varboost at *strength 3* tends to perform better in efficiency at higher quality targets though there can still be gains at lower qualities depending on the content at hand.

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/l1PSZy1m) | [Avatar (LQ)](https://slow.pics/c/6XyZa5m2) |
| [Ducks (HQ)](https://slow.pics/c/HfgyEtI6) | [Ducks (LQ)](https://slow.pics/c/vNb218sk) |
| [Fallout (HQ)](https://slow.pics/c/lTxBGS4h) | [Fallout (LQ)](https://slow.pics/c/Zb1SsMXo) |
| [Minecraft (HQ)](https://slow.pics/c/t7pX8SGu) | [Minecraft (LQ)](https://slow.pics/c/dKcQDN48) |
| [Sol Levante (HQ)](https://slow.pics/c/q98rqqlx) | [Sol Levante (LQ)](https://slow.pics/c/fiTECJdJ) |
| [Suzume (HQ)](https://slow.pics/c/xAcvt1gg) | [Suzume (LQ)](https://slow.pics/c/pZxBf9s9) |
| [Mandalorian (HQ)](https://slow.pics/c/0dhkMBkj) | [Mandalorian (LQ)](https://slow.pics/c/ab9AOw54) |

##### And lastly, `--variance-boost-strength 4`, which will print you a warning that this may be too aggressive in some usecases:

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

So, what does this unusual varboost strength have in store for us? Well, nothing as dangerous as we're led to believe. In fact, by in large, we observe the same things as the other three strengths. You may have noticed this yourself, as we've increased the strength, Butteraugli has tended to highlight *lower octiles* more and more at high quality and *no varboost* more and more at low quality. Still, *varboost on* often provides great gains and the optimal octile depends a lot on the sample. The default *octile 6* is a fine, safe default.

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/qUhijQqk) | [Avatar (LQ)](https://slow.pics/c/fLvog0BW) |
| [Ducks (HQ)](https://slow.pics/c/DCX9HCno) | [Ducks (LQ)](https://slow.pics/c/M8PcEi4T) |
| [Fallout (HQ)](https://slow.pics/c/yfF24i4L) | [Fallout (LQ)](https://slow.pics/c/1aCFxgND) |
| [Minecraft (HQ)](https://slow.pics/c/bTHqdZS3) | [Minecraft (LQ)](https://slow.pics/c/0vk3SJ0C) |
| [Sol Levante (HQ)](https://slow.pics/c/hYRDUXh1) | [Sol Levante (LQ)](https://slow.pics/c/DcIxPyX2) |
| [Suzume (HQ)](https://slow.pics/c/FaTSgkNC) | [Suzume (LQ)](https://slow.pics/c/1exzpYov) |
| [Mandalorian (HQ)](https://slow.pics/c/RARbCDOr) | [Mandalorian (LQ)](https://slow.pics/c/SMe5q0Kv) |

---
#### Varboost Octile

Now, let's do the contrary and test all 8 *octile* values while solely adjusting the *strength*...

##### ...starting with `--variance-octile 1`!

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

For an octile value that supposedly should boost too many blocks in frames, `1` scores pretty consistently better than *no varboost*, especially at high quality. What's more, even though it can be argued all varboost curves are extremely close to one another, higher strengths are ever so slightly better performing than lower ones at high quality, while the contrary is more often observed at low quality though not always! Fallout seems to benefit less from varboost, heck it can be harmful at low quality according to some metrics. You will be unsurprised to hear that the higher the strength the slower encoding tends to be. Again, speed is affected by the resulting output filesize.

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/GzZ0xiAW) | [Avatar (LQ)](https://slow.pics/c/ZuIOSRed) |
| [Ducks (HQ)](https://slow.pics/c/jUNbTEHV) | [Ducks (LQ)](https://slow.pics/c/bknKSeOY) |
| [Fallout (HQ)](https://slow.pics/c/zvc0jqvt) | [Fallout (LQ)](https://slow.pics/c/ongtADY8) |
| [Minecraft (HQ)](https://slow.pics/c/NKeFM3q4) | [Minecraft (LQ)](https://slow.pics/c/8LTGKKGa) |
| [Sol Levante (HQ)](https://slow.pics/c/CB3GU6g5) | [Sol Levante (LQ)](https://slow.pics/c/h3jJaTAG) |
| [Suzume (HQ)](https://slow.pics/c/kCJj6jDP) | [Suzume (LQ)](https://slow.pics/c/fpzkIsUb) |
| [The Mandalorian (HQ)](https://slow.pics/c/ZeVlmDlS) | [The Mandalorian (LQ)](https://slow.pics/c/PVvi6EWQ) |

##### Let's look at `--variance-octile 2`:

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

**Octile 2**'s results are similar to *1*, that is to say close curves between all strengths, with a tendency for higher strengths to be better at high quality, for lower strengths to be at times preferable at low quality, and for varboost to overall be beneficial over it disabled, except according to VMAF.

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/ImqHaKb7) | [Avatar (LQ)](https://slow.pics/c/EhkP5ZaF) |
| [Ducks (HQ)](https://slow.pics/c/0CRmG4s9) | [Ducks (LQ)](https://slow.pics/c/lkB0foeJ) |
| [Fallout (HQ)](https://slow.pics/c/TlQCQoeH) | [Fallout (LQ)](https://slow.pics/c/ZSxW0PTv) |
| [Minecraft (HQ)](https://slow.pics/c/KuqBscxE) | [Minecraft (LQ)](https://slow.pics/c/fZL3hiWK) |
| [Sol Levante (HQ)](https://slow.pics/c/eLZy8Fjv) | [Sol Levante (LQ)](https://slow.pics/c/B77FJMuy) |
| [Suzume (HQ)](https://slow.pics/c/zvkKQTHO) | [Suzume (LQ)](https://slow.pics/c/5B82eyRP) |
| [The Mandalorian (HQ)](https://slow.pics/c/80ofSD0W) | [The Mandalorian (LQ)](https://slow.pics/c/ZWSi8W6G) |

##### Let's test `--variance-octile 3`:

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

It can be summarized the same as *octile 1* and *2*.

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/WriHrzHL) | [Avatar (LQ)](https://slow.pics/c/bXA4FPus) |
| [Ducks (HQ)](https://slow.pics/c/RwggDVq4) | [Ducks (LQ)](https://slow.pics/c/Z8MERQqW) |
| [Fallout (HQ)](https://slow.pics/c/Cnsx12Ct) | [Fallout (LQ)](https://slow.pics/c/KUFUrvhX) |
| [Minecraft (HQ)](https://slow.pics/c/SxnyNTDr) | [Minecraft (LQ)](https://slow.pics/c/GTydHu65) |
| [Sol Levante (HQ)](https://slow.pics/c/iJFd4qzD) | [Sol Levante (LQ)](https://slow.pics/c/gVNXWh7C) |
| [Suzume (HQ)](https://slow.pics/c/kYGB1IWf) | [Suzume (LQ)](https://slow.pics/c/yGLJnHAB) |
| [The Mandalorian (HQ)](https://slow.pics/c/ryzIi6Ky) | [The Mandalorian (LQ)](https://slow.pics/c/er2a3xNi) |

##### And `--variance-octile 4`:

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

I swear it's not just me getting lazy, there's not much more to say than as already been said!

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/bn1iUk8T) | [Avatar (LQ)](https://slow.pics/c/S40uaj7w) |
| [Ducks (HQ)](https://slow.pics/c/5auZYNLd) | [Ducks (LQ)](https://slow.pics/c/OH59amm8) |
| [Fallout (HQ)](https://slow.pics/c/PppdU8Cp) | [Fallout (LQ)](https://slow.pics/c/LWF9w3KG) |
| [Minecraft (HQ)](https://slow.pics/c/Z3Rl51sK) | [Minecraft (LQ)](https://slow.pics/c/UdptXCxk) |
| [Sol Levante (HQ)](https://slow.pics/c/ySMBddAM) | [Sol Levante (LQ)](https://slow.pics/c/tNrgSJSR) |
| [Suzume (HQ)](https://slow.pics/c/9FVioL5x) | [Suzume (LQ)](https://slow.pics/c/WWCDsBGc) |
| [The Mandalorian (HQ)](https://slow.pics/c/pOCex4aG) | [The Mandalorian (LQ)](https://slow.pics/c/2IiO8loM) |

##### And `--variance-octile 5`!

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

Cf. previous interpretations.

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/xfux0wc3) | [Avatar (LQ)](https://slow.pics/c/4wUXeENY) |
| [Ducks (HQ)](https://slow.pics/c/byPkfKGV) | [Ducks (LQ)](https://slow.pics/c/jhr4SelN) |
| [Fallout (HQ)](https://slow.pics/c/XlWDEMlG) | [Fallout (LQ)](https://slow.pics/c/PoElCuV3) |
| [Minecraft (HQ)](https://slow.pics/c/gFx0OGXz) | [Minecraft (LQ)](https://slow.pics/c/5mFpmbqq) |
| [Sol Levante (HQ)](https://slow.pics/c/XcpyeAfl) | [Sol Levante (LQ)](https://slow.pics/c/elhMkf3h) |
| [Suzume (HQ)](https://slow.pics/c/pBXnSGgh) | [Suzume (LQ)](https://slow.pics/c/1ZmKPN5Y) |
| [The Mandalorian (HQ)](https://slow.pics/c/xSNu2fAK) | [The Mandalorian (LQ)](https://slow.pics/c/ICwJ27DI) |

##### What about `--variance-octile 6`, the default *octile* value in every iteration of SVT-AV1:

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

The default octile value tends, again, to perform better on higher strengths at high quality, and sometimes lower strengths at low quality. We notice it is getting easier to distinct between strengths as we've increased octile, which can be good depending on how you see things. Something we haven't discussed until now is how higher strengths tend to be more inconsistent according to SSIMU2 as you get closer to the *CRF40-50* range, which could be problematic depending on your usecase, and thus something to keep in mind.

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/uh1kwBCy) | [Avatar (LQ)](https://slow.pics/c/BhXRytzk) |
| [Ducks (HQ)](https://slow.pics/c/45p8EDsI) | [Ducks (LQ)](https://slow.pics/c/7xCXSvO2) |
| [Fallout (HQ)](https://slow.pics/c/4xqrsZJ9) | [Fallout (LQ)](https://slow.pics/c/lvmSA3XE) |
| [Minecraft (HQ)](https://slow.pics/c/w2OOsRQF) | [Minecraft (LQ)](https://slow.pics/c/VCsRWnKr) |
| [Sol Levante (HQ)](https://slow.pics/c/9Cbo7ua5) | [Sol Levante (LQ)](https://slow.pics/c/r1tP3s25) |
| [Suzume (HQ)](https://slow.pics/c/oZ61IBgw) | [Suzume (LQ)](https://slow.pics/c/UhzGesBH) |
| [The Mandalorian (HQ)](https://slow.pics/c/u5atwJ8W) | [The Mandalorian (LQ)](https://slow.pics/c/eXAZ1p0g) |

##### Following with `--variance-octile 7` tests:

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

Cf. previous interpretations.

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/dPYDMxXt) | [Avatar (LQ)](https://slow.pics/c/1bOEH4Ts) |
| [Ducks (HQ)](https://slow.pics/c/22BsOu46) | [Ducks (LQ)](https://slow.pics/c/gzuNDayw) |
| [Fallout (HQ)](https://slow.pics/c/LnrHCX4b) | [Fallout (LQ)](https://slow.pics/c/JOTbCI5m) |
| [Minecraft (HQ)](https://slow.pics/c/RfMprkEY) | [Minecraft (LQ)](https://slow.pics/c/whW5d55t) |
| [Sol Levante (HQ)](https://slow.pics/c/qcR6vp2Q) | [Sol Levante (LQ)](https://slow.pics/c/cGoytwwE) |
| [Suzume (HQ)](https://slow.pics/c/f7cPlcI0) | [Suzume (LQ)](https://slow.pics/c/S20TviAL) |
| [The Mandalorian (HQ)](https://slow.pics/c/x736Wk54) | [The Mandalorian (LQ)](https://slow.pics/c/f3hZchK5) |

##### And lastly `--variance-octile 8` testing:

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

Well, here we are, *octile 8* barely provides any gains and can be (quite) harmful depending on the clip and metric, especially at low qualities, so this can hardly ever be recommended.

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/qsJDQuH9) | [Avatar (LQ)](https://slow.pics/c/sSjtrfV7) |
| [Ducks (HQ)](https://slow.pics/c/AkPNi9tB) | [Ducks (LQ)](https://slow.pics/c/Ovc74G5T) |
| [Fallout (HQ)](https://slow.pics/c/wftx5BS3) | [Fallout (LQ)](https://slow.pics/c/zhaFrhou) |
| [Minecraft (HQ)](https://slow.pics/c/DgxYKGC3) | [Minecraft (LQ)](https://slow.pics/c/QUTIHXJo) |
| [Sol Levante (HQ)](https://slow.pics/c/H9IjcZdh) | [Sol Levante (LQ)](https://slow.pics/c/D3gA2BNr) |
| [Suzume (HQ)](https://slow.pics/c/OfIcrFq3) | [Suzume (LQ)](https://slow.pics/c/o28ioyrm) |
| [The Mandalorian (HQ)](https://slow.pics/c/rdZTAUJn) | [The Mandalorian (LQ)](https://slow.pics/c/RVprUbv4) |

---
#### Varboost Curve

We will be comparing all 3 available varboost curves...

##### ...with the default settings first:

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

We observe that all three curves tend to be blurred together, with the notable exception of *curve 2* scoring non-negligibly better on a few clips, consistently across all metrics. Speed-wise, I would argue it's a tie as all three curves are sometimes situationally slightly slower or faster.

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/F44iAZvt) | [Avatar (LQ)](https://slow.pics/c/OsPifnca) |
| [Ducks (HQ)](https://slow.pics/c/UdPvmsZd) | [Ducks (LQ)](https://slow.pics/c/MWvE2PhS) |
| [Fallout (HQ)](https://slow.pics/c/mE4DPv4b) | [Fallout (LQ)](https://slow.pics/c/imXOhRu3) |
| [Minecraft (HQ)](https://slow.pics/c/0M03K6Td) | [Minecraft (LQ)](https://slow.pics/c/vtXMiDX4) |
| [Sol Levante (HQ)](https://slow.pics/c/0HkpGRVh) | [Sol Levante (LQ)](https://slow.pics/c/eUFlYP4S) |
| [Suzume (HQ)](https://slow.pics/c/4pPMQEHl) | [Suzume (LQ)](https://slow.pics/c/tc6t8142) |
| [Mandalorian (HQ)](https://slow.pics/c/CrjP7X1t) | [Mandalorian (LQ)](https://slow.pics/c/hdxcVqCC) |

##### I also conducted the tests with a different combination of varboost settings I have used on occasion:

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

The winner is less clear here, this time we can say it's a tie. Such results are why testing with a different combination of settings can be educative.

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/PPInVFpH) | [Avatar (LQ)](https://slow.pics/c/3ddsAMj8) |
| [Ducks (HQ)](https://slow.pics/c/r4N2mCXD) | [Ducks (LQ)](https://slow.pics/c/eVvOPXBr) |
| [Fallout (HQ)](https://slow.pics/c/6EzFC57R) | [Fallout (LQ)](https://slow.pics/c/EUZWdHKu) |
| [Minecraft (HQ)](https://slow.pics/c/Gz32ytoJ) | [Minecraft (LQ)](https://slow.pics/c/UKpTJkzI) |
| [Sol Levante (HQ)](https://slow.pics/c/DkIz3Ti1) | [Sol Levante (LQ)](https://slow.pics/c/agKlz4Ul) |
| [Suzume (HQ)](https://slow.pics/c/1XL15C39) | [Suzume (LQ)](https://slow.pics/c/daIcH6Bh) |
| [Mandalorian (HQ)](https://slow.pics/c/52CQl8aI) | [Mandalorian (LQ)](https://slow.pics/c/gFNSbm5v) |

---
#### Varboost Conclusion

We have seen that, in SVT-AV1 v3.0.x, **__varboost on__ more often than not provides consistent improvements whatever the combination of settings**, though we see better gains at high qualities and/or with higher strengths and lower octiles, less gains at low qualities and/or with lower strengths and higher octiles.

> It is best to stay on the **default `--variance-boost-strength 2 --variance-octile 6`** unless you want to hyper-tune for your content, or you want to encode at lower than *CRF20* where I guess a combination like `--variance-boost-strength 3 --variance-octile 3` *can* provide more consistent efficiency gains.

`--variance-boost-strength 4` is still clearly better than *no varboost* and sometimes lower strengths too, but it often performs worse than *3*. `--variance-octile 1 & 2` often came out on top, but they may be too aggressive or inflate filesizes too much, so a more conservative value is advised.

> My last recommendation would be to remember to **adjust __CRF__ in consequence**, as enabling varboost, increasing the strength and decreasing octile can drastically boost filesizes. If you understand how these graphs work, then you know you aren't compromising anything by increasing *CRF* to compensate for the filesize increase.

---
### `--tune`

The original SVT-AV1 implementation offers three tunes to choose from:
- **`--tune 0` (VQ - Visual Quality)**: Favors sharper decisions, reducing blur but potentially introducing artifacts.
- **`--tune 1` (PSNR - Peak Signal-to-Noise Ratio)**: The **default** in mainline SVT-AV1.
- **`--tune 2` (SSIM - Structural Similarity Index Measure)**: The previous efficiency champion.

Has the dynamics between tunes changed since we last tested them on SSIMULACRA2 almost a year and a half ago? Let's see!

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

In most cases, on most metrics, *tune 1* comes out on top in efficiency, with *tune 2* sometimes trading blows and even winning. Tune 0 is usually quite a bit behind, except on XPSNR. In terms of speed, all tunes seem to perform closely from one another, without a clear winner.

For most users, **sticking with the default (tune 1)** is recommended, as it provides the best balance of everything. However, **tune 0** can be worth experimenting with if you prefer sharper outputs. Just be aware of the potential trade-offs in artifacting.

>#### **Specialized Tunes in SVT-AV1 Forks**
>The SVT-AV1-PSY based forks introduced new tunes to catter to new usecases. We won't be testing these forks today but I'm mentioning them for reference purposes. Note that the following two `--tune 3` modes are entirely different depending on the encoder variant!
>- **`--tune 3` (_SVT-AV1-PSY(EX)_ exclusive)**: A psychovisual enhancement of `--tune 2`, borrowing some features from `--tune 0` and other tweaks. A general-purpose psychovisual tune for a wide range of content.
>- **`--tune 3` (_SVT-AV1-HDR_)**: Acts as a *grain-optimized* mode, disabling CDEF, restoration, and temporal filtering while applying aggressive psychovisual adjustments. Best suited for **noisy live-action content**.

We may want to confirm our findings with a visual analysis on the encoded samples:

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/KoZYGlBL) | [Avatar (LQ)](https://slow.pics/c/CDMgkOVT) |
| [Ducks (HQ)](https://slow.pics/c/eiklaXqz) | [Ducks (LQ)](https://slow.pics/c/kLeCUR5k) |
| [Fallout (HQ)](https://slow.pics/c/3lzjEFEX) | [Fallout (LQ)](https://slow.pics/c/u9Wx37CU) |
| [Minecraft (HQ)](https://slow.pics/c/gQPbq4j0) | [Minecraft (LQ)](https://slow.pics/c/FGGpyjeZ) |
| [Sol Levante (HQ)](https://slow.pics/c/9B9lOQ1c) | [Sol Levante (LQ)](https://slow.pics/c/Nr2DBM1m) |
| [Suzume (HQ)](https://slow.pics/c/RTlTjyW4) | [Suzume (LQ)](https://slow.pics/c/kV5XUUi1) |
| [Mandalorian (HQ)](https://slow.pics/c/CO81FwdN) | [Mandalorian (LQ)](https://slow.pics/c/IxDW70kW) |

Lastly, my own opinion regarding the tunes is that it probably does not matter as much as you think. Again, unless you're willing to hyper-tune, which implies testing parameters each time you encode a new source, no one can guess in advance what's going to be best for that content because it depends on an almost infinite amount of variables. The thing with psychovisual approaches is that metrics may be saying something and your eyes something else. Plus it is wildly subjective: my eyes may disagree with yours, or anyone else's. Don't fret too much over the tune.

---
Let's continue with the newly introduced parameters of v3.0.0, starting out with an important feature in the context of AV1: luma bias!

### `--luminance-qp-bias`

Anyone familiar with AV1 for long enough is aware that its encoders have struggled on dark scenes forever. As the encoder implementations mature, performance in such scenes naturally improve, however in many cases they persist in allocating insufficient bits to these darker scenes. This setting changes (almost) everything! It effectively applies a dumb qp offset to frames of lower overall brightness. The higher the value, the stronger the effect is. This implementation has one advantage and one weakness: it gives the user control over the bitrate balancing between bright and dark frames, however if only parts of the frame are dark and the rest is fairly bright, it may not fix cases of localized detail loss or blurring.

So let's see the effect it can have on efficiency and visuals!

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

On the HQ graphs, we can see no luma-bias tends to score last or at least lower than conservative luma-bias values.
On the LQ graphs, we usually observe the opposite, that is to say that no luma-bias tends to barely come out on top, with increasing luma-bias values decreasing efficiency ever so slightly.

If we look at performance, the impact of luma-bias is negligible at lower *CRF* values, but gradually increases with higher *CRF* values for the simple reason that the frames whose QP will be reduced will take a bit more time to encode, as is the expected behavior of any encoder. The effect on QP, and thus performance, is going to be more important the higher base *CRF* you start with.

Let's look at some BD-rate numbers directly, to try and clarify the graphs:

| Luma-Bias Effect | LB0 | LB10 | LB20 | LB30 | LB40 | LB50 | LB60 | LB70 | LB80 | LB90 | LB100 |
|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
| Avatar | 0% | <span style={{color:'red'}}>+0.18%</span> | <span style={{color:'red'}}>+0.59%</span> | <span style={{color:'red'}}>+0.74%</span> | <span style={{color:'red'}}>+0.89%</span> | <span style={{color:'red'}}>+1.11%</span> | <span style={{color:'red'}}>+1.28%</span> | <span style={{color:'red'}}>+1.45%</span> | <span style={{color:'red'}}>+1.63%</span> | <span style={{color:'red'}}>+1.73%</span> | <span style={{color:'red'}}>+1.94%</span> |
| Ducks | 0% | <span style={{color:'red'}}>+1.33%</span> | <span style={{color:'red'}}>+2.34%</span> | <span style={{color:'red'}}>+3.04%</span> | <span style={{color:'red'}}>+3.76%</span> | <span style={{color:'red'}}>+4.43%</span> | <span style={{color:'red'}}>+5.02%</span> | <span style={{color:'red'}}>+5.74%</span> | <span style={{color:'red'}}>+6.29%</span> | <span style={{color:'red'}}>+6.82%</span> | <span style={{color:'red'}}>+7.43%</span> |
| Fallout | 0% | <span style={{color:'green'}}>-0.31%</span> | <span style={{color:'red'}}>+0.79%</span> | <span style={{color:'red'}}>+1.29%</span> | <span style={{color:'red'}}>+1.84%</span> | <span style={{color:'red'}}>+2.56%</span> | <span style={{color:'red'}}>+2.72%</span> | <span style={{color:'red'}}>+3.04%</span> | <span style={{color:'red'}}>+3.40%</span> | <span style={{color:'red'}}>+3.73%</span> | <span style={{color:'red'}}>+4.06%</span> |
| Minecraft | 0% | <span style={{color:'red'}}>+0.69%</span> | <span style={{color:'red'}}>+1.43%</span> | <span style={{color:'red'}}>+1.99%</span> | <span style={{color:'red'}}>+2.64%</span> | <span style={{color:'red'}}>+3.10%</span> | <span style={{color:'red'}}>+3.47%</span> | <span style={{color:'red'}}>+3.87%</span> | <span style={{color:'red'}}>+4.26%</span> | <span style={{color:'red'}}>+4.59%</span> | <span style={{color:'red'}}>+5.06%</span> |
| Sol Levante | 0% | <span style={{color:'green'}}>-0.09%</span> | <span style={{color:'green'}}>-0.12%</span> | <span style={{color:'orange'}}>-0.02%</span> | <span style={{color:'red'}}>+0.21%</span> | <span style={{color:'red'}}>+0.29%</span> | <span style={{color:'red'}}>+0.44%</span> | <span style={{color:'red'}}>+0.42%</span> | <span style={{color:'red'}}>+0.53%</span> | <span style={{color:'red'}}>+0.60%</span> | <span style={{color:'red'}}>+0.75%</span> |
| Suzume | 0% | <span style={{color:'green'}}>-0.45%</span> | <span style={{color:'orange'}}>-0.43%</span> | <span style={{color:'orange'}}>-0.34%</span> | <span style={{color:'orange'}}>-0.31%</span> | <span style={{color:'orange'}}>-0.30%</span> | <span style={{color:'orange'}}>-0.21%</span> | <span style={{color:'orange'}}>-0.11%</span> | <span style={{color:'orange'}}>-0.07%</span> | <span style={{color:'red'}}>+0.02%</span> | <span style={{color:'red'}}>+0.08%</span> |
| Mandalorian | 0% | <span style={{color:'red'}}>+0.57%</span> | <span style={{color:'red'}}>+0.91%</span> | <span style={{color:'red'}}>+1.29%</span> | <span style={{color:'red'}}>+1.56%</span> | <span style={{color:'red'}}>+1.80%</span> | <span style={{color:'red'}}>+2.24%</span> | <span style={{color:'red'}}>+2.30%</span> | <span style={{color:'red'}}>+2.53%</span> | <span style={{color:'red'}}>+2.78%</span> | <span style={{color:'red'}}>+3.03%</span> |

Unfortunately, I couldn't easily separate the BD-rate numbers at low quality and the ones at high quality, so we can't exactly reproduce what I interpreted from the graphs earlier. Still, this gives insightful data, which showcase that the BD-rate across the entire quality range is improved the most on the anime clips and tends to be harmful on live action and gaming clips, again across the entire quality range, not when isolating a smaller range where we could make luma-bias look way more appealing.

Luma-bias is no magic, it simply offsets a frame QP depending on its average luminance. So unless rate control is badly tuned, the feature is not expected in theory to bring any efficiency improvements.

My advice for choosing a luma-bias value is to simply isolate a test sample in your source and test out a few values (like 10, 30, 50...), look at the bitrate balance between dark and bright frames by checking the impact on visuals and filesizes, and finally decide what you prefer. On that note, you cannot go wrong by using a conservative value below 50 in my opinion.

Beware that the author of the feature warned me it isn't suited for the PQ transfer used in most UHD blu-rays! Use luma-bias exclusively on SDR and HDR HLG videos.

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/NUsH5vl0) | [Avatar (LQ)](https://slow.pics/c/dxkop5sv) |
| [Ducks (HQ)](https://slow.pics/c/oWY5nMIr) | [Ducks (LQ)](https://slow.pics/c/Ai0GXaAZ) |
| [Fallout (HQ)](https://slow.pics/c/cWT7QhiL) | [Fallout (LQ)](https://slow.pics/c/hskxyERo) |
| [Minecraft (HQ)](https://slow.pics/c/yRa03RAb) | [Minecraft (LQ)](https://slow.pics/c/DLp6cOsW) |
| [Sol Levante (HQ)](https://slow.pics/c/Z8XcDPxn) | [Sol Levante (LQ)](https://slow.pics/c/kUemyTCw) |
| [Suzume (HQ)](https://slow.pics/c/WZPOKhQt) | [Suzume (LQ)](https://slow.pics/c/kc2Zgskv) |
| [Mandalorian (HQ)](https://slow.pics/c/D1QSRGhy) | [Mandalorian (LQ)](https://slow.pics/c/eXysNAjI) |

---
### `--sharpness`

Sharpness is a straighforward parameter, though it may not do exactly what you'd assume it to do. It does not affect the encodes' clarity but rather impacts the deblocking filter sharpness, which can lead to increased fidelity.

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

Like luma-bias, this feature can only be useful if the deblocking filter isn't properly tuned for all usecases to begin with. On surface, it looks like there is not much room for improvements. It does depend on the metric and clip, but in many of these, all sharpness values perform extremely closely from each another, apart from 3 (a bit lower or higher) and 4+ (usually noticeably lower).

Speed wise, negative sharpness values perform closely to the default of 0, and increasing positive values become slower and slower, but as we can see on the x axis, it's rather negligible.

Again, there are so many data points that a BD-rate table will help visualize stuff differently:

| Sharpness Effect | -7 | -6 | -5 | -4 | -3 | -2 | -1 | 0 | +1 | +2 | +3 | +4 | +5 | +6 | +7 |
|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|:-:|
| Avatar | 0% | <span style={{color:'green'}}>-0.04%</span> | <span style={{color:'green'}}>-0.05%</span> | <span style={{color:'orange'}}>-0.04%</span> | <span style={{color:'green'}}>-0.16%</span> | <span style={{color:'orange'}}>-0.04%</span> | <span style={{color:'orange'}}>-0.03%</span> | <span style={{color:'orange'}}>-0.02%</span> | <span style={{color:'green'}}>-0.03%</span> | <span style={{color:'orange'}}>-0.01%</span> | <span style={{color:'red'}}>+1.07%</span> | <span style={{color:'red'}}>+3.44%</span> | <span style={{color:'red'}}>+6.05%</span> | <span style={{color:'red'}}>+8.28%</span> | <span style={{color:'red'}}>+9.65%</span> |
| Ducks | 0% | <span style={{color:'green'}}>-0.05%</span> | <span style={{color:'green'}}>-0.09%</span> | <span style={{color:'green'}}>-0.10%</span> | <span style={{color:'green'}}>-0.14%</span> | <span style={{color:'orange'}}>-0.10%</span> | <span style={{color:'orange'}}>-0.09%</span> | <span style={{color:'orange'}}>-0.06%</span> | <span style={{color:'red'}}>+0.04%</span> | <span style={{color:'red'}}>+0.06%</span> | <span style={{color:'red'}}>+2.14%</span> | <span style={{color:'red'}}>+8.94%</span> | <span style={{color:'red'}}>+14.24%</span> | <span style={{color:'red'}}>+18.19%</span> | <span style={{color:'red'}}>+20.74%</span> |
| Fallout | 0% | <span style={{color:'green'}}>-0.05%</span> | <span style={{color:'green'}}>-0.07%</span> | <span style={{color:'green'}}>-0.13%</span> | <span style={{color:'green'}}>-0.16%</span> | <span style={{color:'orange'}}>-0.15%</span> | <span style={{color:'orange'}}>-0.13%</span> | <span style={{color:'orange'}}>-0.13%</span> | <span style={{color:'red'}}>+0.01%</span> | <span style={{color:'red'}}>+0.01%</span> | <span style={{color:'red'}}>+0.99%</span> | <span style={{color:'red'}}>+5.62%</span> | <span style={{color:'red'}}>+10.23%</span> | <span style={{color:'red'}}>+13.68%</span> | <span style={{color:'red'}}>+16.00%</span> |
| Minecraft | 0% | <span style={{color:'green'}}>-0.04%</span> | <span style={{color:'green'}}>-0.08%</span> | <span style={{color:'green'}}>-0.12%</span> | <span style={{color:'green'}}>-0.17%</span> | <span style={{color:'orange'}}>-0.11%</span> | <span style={{color:'orange'}}>-0.08%</span> | <span style={{color:'orange'}}>-0.01%</span> | <span style={{color:'red'}}>+0.21%</span> | <span style={{color:'red'}}>+0.26%</span> | <span style={{color:'green'}}>-1.14%</span> | <span style={{color:'red'}}>+0.88%</span> | <span style={{color:'red'}}>+3.88%</span> | <span style={{color:'red'}}>+5.60%</span> | <span style={{color:'red'}}>+6.83%</span> |
| Sol Levante | 0% | <span style={{color:'green'}}>-0.03%</span> | <span style={{color:'green'}}>-0.07%</span> | <span style={{color:'green'}}>-0.10%</span> | <span style={{color:'orange'}}>-0.02%</span> | <span style={{color:'orange'}}>-0.01%</span> | <span style={{color:'green'}}>-0.17%</span> | <span style={{color:'orange'}}>-0.06%</span> | <span style={{color:'orange'}}>-0.05%</span> | <span style={{color:'red'}}>+0.04%</span> | <span style={{color:'green'}}>-3.61%</span> | <span style={{color:'green'}}>-3.61%</span> | <span style={{color:'orange'}}>-2.65%</span> | <span style={{color:'orange'}}>-1.89%</span> | <span style={{color:'orange'}}>-1.53%</span> |
| Suzume | 0% | <span style={{color:'green'}}>-0.03%</span> | <span style={{color:'green'}}>-0.07%</span> | <span style={{color:'green'}}>-0.15%</span> | <span style={{color:'orange'}}>-0.13%</span> | <span style={{color:'green'}}>-0.17%</span> | <span style={{color:'green'}}>-0.20%</span> | <span style={{color:'orange'}}>-0.13%</span> | <span style={{color:'green'}}>-0.75%</span> | <span style={{color:'green'}}>-0.77%</span> | <span style={{color:'orange'}}>-0.46%</span> | <span style={{color:'red'}}>+2.73%</span> | <span style={{color:'red'}}>+5.87%</span> | <span style={{color:'red'}}>+7.89%</span> | <span style={{color:'red'}}>+8.91%</span> |
| Mandalorian | 0% | <span style={{color:'green'}}>-0.02%</span> | <span style={{color:'green'}}>-0.04%</span> | <span style={{color:'orange'}}>-0.01%</span> | <span style={{color:'green'}}>-0.17%</span> | <span style={{color:'orange'}}>-0.13%</span> | <span style={{color:'orange'}}>-0.06%</span> | <span style={{color:'green'}}>-0.20%</span> | <span style={{color:'green'}}>-0.95%</span> | <span style={{color:'green'}}>-1.07%</span> | <span style={{color:'green'}}>-1.86%</span> | <span style={{color:'orange'}}>-0.49%</span> | <span style={{color:'red'}}>+1.09%</span> | <span style={{color:'red'}}>+2.16%</span> | <span style={{color:'red'}}>+2.65%</span> |

The same disclaimer is applicable: BD-rate numbers across such a wide quality range are bound to not be representative of smaller ranges, and doing such average across all 4 metrics could reduce the impact of outliers and make the situation look better than it actually is. Which is why this information is important to pair with the individual graphs, and the visual comparisons.

Anyway, on average we can see in the table above that negative sharpness values (-7 to -1) generally show minor BD-rate improvements or neutral effects, while positive sharpness values (+1 to +7) can show decent, consistent BD-rate improvements or neutral effects with 1 & 2, and either bigger gains or significant degradations with 3 and above.

We notice that *"Sol Levante"* loves sharpness (any value really), whereas the gaming clips and *"ducks take off"* rather dislike it.

So, what effect does sharpness have on visuals:

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/ygCCh0bq) | [Avatar (LQ)](https://slow.pics/c/Y4qtod2v) |
| [Ducks (HQ)](https://slow.pics/c/iNLdFEQl) | [Ducks (LQ)](https://slow.pics/c/Ks9N1GI0) |
| [Fallout (HQ)](https://slow.pics/c/pI7ijRcy) | [Fallout (LQ)](https://slow.pics/c/E8dfmTz7) |
| [Minecraft (HQ)](https://slow.pics/c/gJPslpwr) | [Minecraft (LQ)](https://slow.pics/c/XWc5abmS) |
| [Sol Levante (HQ)](https://slow.pics/c/SMMOEbcj) | [Sol Levante (LQ)](https://slow.pics/c/F0invSsk) |
| [Suzume (HQ)](https://slow.pics/c/J1esnTPE) | [Suzume (LQ)](https://slow.pics/c/Wc22o61r) |
| [Mandalorian (HQ)](https://slow.pics/c/65LP89UX) | [Mandalorian (LQ)](https://slow.pics/c/g0vG4p8B) |

---
### `--tf-strength`

Temporal filtering in SVT-AV1 combines information from multiple nearby video frames to create cleaner reference pictures with reduced noise, which helps improve compression quality especially for noisy source material.

The feature was often considered too strong and often created unavoidable blocking on keyframes, so we historically disabled temporal filtering. Thankfully, a strength parameter
has been introduced which has allowed to tame its effects.

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

On this corpus of clips, we instantly notice *tf-strength 4* performs very poorly and should probably never be used. Lower strengths than the default 3 tend to score increasingly better, though we seem to hit a ceiling below 2. *No temporal filtering* is competitive with low *tf-strength*s, though it still gets beaten slightly at times. There is an interesting outlier in Minecraft where low strengths and especially no tf perform noticeably worse for some reason. The difference in speed between all options is overall negligible.

From this, it is recommended at a minimum to **reduce `--tf-strength`** from its default `3` **to 1**, or below, to at least completely eliminate the tf blocking issue.

> #### **Additional Parameter in SVT-AV1 Forks**
> The SVT-AV1-PSY based forks include an additional `--kf-tf-strength` parameter which decouples tf strength on keyframes, and allows the user to concurrently fix the blocking issue and use a stronger tf strength on all other frames if they want. In mainline SVT-AV1, tf-strength is the same between keyframes and other frames, unless you use tune 0 in which case tf-strength on keyframes will be 1 value lower than on other frames (so for example *1* on keyframes if `--tune 0 --tf-strength 2` is set, the strength being capped at a minimum of 0 in any case).

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/SgZuDVbk) | [Avatar (LQ)](https://slow.pics/c/WHh361VL) |
| [Ducks (HQ)](https://slow.pics/c/LbanU7Yl) | [Ducks (LQ)](https://slow.pics/c/pbfa7YFg) |
| [Fallout (HQ)](https://slow.pics/c/tL86eXXv) | [Fallout (LQ)](https://slow.pics/c/fVKdbsw4) |
| [Minecraft (HQ)](https://slow.pics/c/juHcIEFk) | [Minecraft (LQ)](https://slow.pics/c/9M9u6Srw) |
| [Sol Levante (HQ)](https://slow.pics/c/DsXaFYfg) | [Sol Levante (LQ)](https://slow.pics/c/Et2cKCt0) |
| [Suzume (HQ)](https://slow.pics/c/LIwgjH4w) | [Suzume (LQ)](https://slow.pics/c/nOLPdxus) |
| [Mandalorian (HQ)](https://slow.pics/c/CVqDrlrX) | [Mandalorian (LQ)](https://slow.pics/c/zHxREyku) |

---
### `--lossless`

SVT-AV1 finally added a lossless mode in v3.0.0! Until then, aomenc was the only AV1 software encoder capable of doing lossless encoding, as both rav1e and SVT-AV1 wouldn't allow you to set *Q0*/*CRF0*. It probably shouldn't be expected to see better lossless compression out of SVT-AV1, rather, the encoder aims to achieve feature parity with aomenc, but can it do it fast?

I initially intended this section to compare aomenc to SVT-AV1, but complications quickly arose from my testing as you'll soon be able to see. Obviously, there is no question of efficiency graphs here as the metrics are expected to always be maxed out with lossless enabled. Anyway, no graphs will be needed here.

In fact, SVT-AV1 lossless mode isn't actually *mathematically* lossless. Rather, the feature was designed to reach a PSNR of 100 more often than not (not inf!), as we can see in the [Merge Request](https://gitlab.com/AOMediaCodec/SVT-AV1/-/merge_requests/2312) that introduced the feature.

Running `--preset 4 --lossless 1` proves it on my test samples:

| "Lossless" Test | PSNR (average) | PSNR (min) | PSNR (max) |
|:-:|:-:|:-:|:-:|
| Avatar      | 96.616006 | 86.680008 | inf |
| Ducks       | inf | inf | inf |
| Fallout     | 104.378402 | 92.930594 | inf |
| Minecraft   | 96.263052 | 87.993916 | inf |
| Sol Levante | 119.890723 | 106.868980 | inf |
| Suzume      | 116.226350 | 102.759654 | inf |
| Mandalorian | 102.546893 | 91.381363 | inf |

> *XPSNR and W-VMAF are not included here as the numbers were nonsensical due to the chroma weighting at play. As for Butteraugli's different intensity multiplier and SSIMULACRA2's harmonic scoring, they are not expected to affect the score of a lossless frame, however the GPU implementation itself isn't 100% score accurate to their original's so they can't be considered reliable for this specific usecase. Therefore, regular ffmpeg's PSNR filter was used here.*

Sure, the scores are high, but not lossless-like! Funnily enough, the anime clips' average score a bit higher. That makes SVT-AV1 more lossless on anime than on live action! Is this confirmation that SVT-AV1 is a weeb encoder? You tell me. Anyway, for some reason, *"ducks take off"* is the only clip that is properly lossless out of SVT-AV1 here.

What's even more concerning is that even though the outputs are not mathematically lossless, the filesizes are often bigger than `libx264 -preset veryfast -qp 0`, the latter of which is properly lossless:

| "Lossless" Test | x264 Filesize | SVT-AV1 Filesize |
|:-:|:-:|:-:|
| Avatar      | 282,198,409 o | 280,441,784 o <span style={{color:'green'}}>(-0.6%)</span> |
| Ducks       | 244,077,992 o | 234,884,891 o <span style={{color:'green'}}>(-3.8%)</span> |
| Fallout     | 272,838,887 o | 278,457,794 o <span style={{color:'red'}}>(+2.1%)</span> |
| Minecraft   | 382,935,638 o | 473,884,851 o <span style={{color:'red'}}>(+23.8%)</span> |
| Sol Levante | 438,207,769 o | 448,937,567 o <span style={{color:'red'}}>(+2.4%)</span> |
| Suzume      | 372,844,589 o | 384,223,861 o <span style={{color:'red'}}>(+3.1%)</span> |
| Mandalorian | 182,526,455 o | 185,680,771 o <span style={{color:'red'}}>(+1.7%)</span> |

Needless to say the AV1 encodes took at least 10x longer to encode as well!

Considering that *"Ducks"* is mathematically lossless and a few percents smaller, it shows that the format is in fact capable of compression gains in this department. Simply, the current iteration is either broken or misleading in its true intentions.

While the encodes are not *mathematically* lossless, I doubt anyone can see any difference with our bare eyes, but I still made comps so you can see for yourself.

---> Visual Comparisons:

- [Avatar](https://slow.pics/c/B5ITVoCV)
- [Ducks](https://slow.pics/c/yAjveP75)
- [Fallout](https://slow.pics/c/M9F6GgKB)
- [Minecraft](https://slow.pics/c/Hqx6vb5X)
- [Sol Levante](https://slow.pics/c/Hqx6vb5X)
- [Suzume](https://slow.pics/c/F3wXKV3g)
- [Mandalorian](https://slow.pics/c/Makytom1)

---
### `--fast-decode`

SVT-AV1 ships with its own built-in method for reducing decoding bottlenecks by smartly tuning down or disabling specific internal tools that trade off some efficiency for decoding performance.

The encoder offers two `--fast-decode` levels, with `2` being more aggressive. The default is `0`.

Three presets have been tested with the feature to quantify what the effects would be for different usecases. Due to some hardware-related issues, all the encodes in this section were re-run, so the speed numbers of disabled *fast-decode* encodes are different from before, however this ensured there would be no impact on my subsequent analysis.

#### Preset 2

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

The efficiency impact of *fast-decode* is clearly visible, be it at low or high quality targets. Beware of the much different scales on the y-axix between the HQ and LQ graphs, which could mislead you into thinking the effect at low quality is lesser, even though that's not the case.

We observe that *fast-decode* can non-negligibly influence the speed of your encoding instances, with **1** appearing slower than *0* and **2** being faster than both. There's an exception in *"Sol Levante"* where *0* and *1* perform the same.

Let's look at the effects on decoding speed with data I nicely aggregated into tables!

>Decoding speeds were collected using ffmpeg 7.1.0 from Arch's official repository using: `ffmpeg -hide_banner -benchmark -i "" -f null - > /dev/null`. The tests were repeated 5 times and the performance numbers you'll see are the average of these 5 runs. I can say with confidence the speed deviation was *largely* negligible, but better safe than sorry!

| Preset 2 Decoding Test (CRF12) | FD0 | FD1 | FD2 |
|:-:|:-:|:-:|:-:|
| Avatar      | 197fps | 204fps <span style={{color:'green'}}>*(+3.6%)*</span> | 212fps <span style={{color:'green'}}>*(+7.6%)*</span> |
| Ducks       | 118fps | 126fps <span style={{color:'green'}}>*(+6.8%)*</span> | 125fps <span style={{color:'orange'}}>*(+5.9%)*</span> |
| Fallout     | 65fps | 67fps <span style={{color:'green'}}>*(+3.1%)*</span> | 68fps <span style={{color:'green'}}>*(+4.6%)*</span> |
| Minecraft   | 82fps | 85fps <span style={{color:'green'}}>*(+3.7%)*</span> | 91fps <span style={{color:'green'}}>*(+11.0%)*</span> |
| Sol Levante | 98fps | 105fps <span style={{color:'green'}}>*(+7.1%)*</span> | 107fps <span style={{color:'green'}}>*(+9.2%)*</span> |
| Suzume      | 360fps | 401fps <span style={{color:'green'}}>*(+11.4%)*</span> | 397fps <span style={{color:'orange'}}>*(+10.3%)*</span> |
| Mandalorian | 326fps | 348fps <span style={{color:'green'}}>*(+6.7%)*</span> | 340fps <span style={{color:'orange'}}>*(+4.3%)*</span> |

In our *high quality* target, `--fast-decode 1` provides a `+6%` decoding performance increase on average, while `--fast-decode 2` provides `+7.5%`.

| Preset 2 Decoding Test (CRF33) | FD0 | FD1 | FD2 |
|:-:|:-:|:-:|:-:|
| Avatar      | 429fps | 465fps <span style={{color:'green'}}>*(+8.4%)*</span> | 482fps <span style={{color:'green'}}>*(+12.4%)*</span> |
| Ducks       | 341fps | 366fps <span style={{color:'green'}}>*(+7.3%)*</span> | 342fps <span style={{color:'orange'}}>*(+0.3%)*</span> |
| Fallout     | 131fps | 140fps <span style={{color:'green'}}>*(+6.9%)*</span> | 140fps <span style={{color:'orange'}}>*(+6.9%)*</span> |
| Minecraft   | 182fps | 211fps <span style={{color:'green'}}>*(+15.9%)*</span> | 217fps <span style={{color:'green'}}>*(+19.2%)*</span> |
| Sol Levante | 194fps | 211fps <span style={{color:'green'}}>*(+8.8%)*</span> | 210fps <span style={{color:'orange'}}>*(+8.2%)*</span> |
| Suzume      | 684fps | 766fps <span style={{color:'green'}}>*(+12.0%)*</span> | 770fps <span style={{color:'green'}}>*(+12.6%)*</span> |
| Mandalorian | 885fps | 912fps <span style={{color:'green'}}>*(+3.1%)*</span> | 946fps <span style={{color:'green'}}>*(+6.9%)*</span> |

At *CRF33*, `--fast-decode 1`'s decoding speeds were faster of about `+8.9%` and `--fast-decode 2` of about `+9.5%`.

Sure, `--fast-decode 2` doesn't provide substancial decoding benefits over `1`, heck even over `0` at times, however it also acts as a "fast-encode" parameter, so it can be argued it has its purpose.

Before we continue with the visual comparisons, I will add that we are not on a low powered device, so the importance of such gains may not be immediately visible nor perfectly accurate to be honest.

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/mHlwNgCj) | [Avatar (LQ)](https://slow.pics/c/3W7ELwA1) |
| [Ducks (HQ)](https://slow.pics/c/BeiJQRSs) | [Ducks (LQ)](https://slow.pics/c/rj4jFQGb) |
| [Fallout (HQ)](https://slow.pics/c/WPqNeTjN) | [Fallout (LQ)](https://slow.pics/c/ZcKpdvBR) |
| [Minecraft (HQ)](https://slow.pics/c/1ElnTugb) | [Minecraft (LQ)](https://slow.pics/c/ODFp1HmP) |
| [Sol Levante (HQ)](https://slow.pics/c/E84J2Jdc) | [Sol Levante (LQ)](https://slow.pics/c/xKIDF42q) |
| [Suzume (HQ)](https://slow.pics/c/vaQ57EY2) | [Suzume (LQ)](https://slow.pics/c/UJCsXDmV) |
| [Mandalorian (HQ)](https://slow.pics/c/Qy1roRVu) | [Mandalorian (LQ)](https://slow.pics/c/vwAg1glu) |

---
#### Preset 4

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

It can be observed the gaming clips's efficiency is less affected by the *fast-decode* feature, if at all. Even then, `--fast-decode 2` continue to provide encoding performance benefits.

As we move to faster presets, the resulting streams are expected to be less complex and thus easier to decode. Is that assumption correct? And if so, does it imply that *fast-decode* will have a smaller impact when using preset 4?

| Preset 4 Decoding Test (CRF12) | FD0 | FD1 | FD2 |
|:-:|:-:|:-:|:-:|
| Avatar      | 185fps | 202fps <span style={{color:'green'}}>*(+9.2%)*</span> | 203fps <span style={{color:'green'}}>*(+9.7%)*</span> |
| Ducks       | 117fps | 126fps <span style={{color:'green'}}>*(+7.7%)*</span> | 121fps <span style={{color:'orange'}}>*(+3.4%)*</span> |
| Fallout     | 67fps | 71fps <span style={{color:'green'}}>*(+6.0%)*</span> | 70fps <span style={{color:'orange'}}>*(+4.5%)*</span> |
| Minecraft   | 87fps | 95fps <span style={{color:'green'}}>*(+9.2%)*</span> | 94fps <span style={{color:'orange'}}>*(+8.0%)*</span> |
| Sol Levante | 91fps | 100fps <span style={{color:'green'}}>*(+9.9%)*</span> | 99fps <span style={{color:'orange'}}>*(+8.8%)*</span> |
| Suzume      | 324fps | 372fps <span style={{color:'green'}}>*(+14.8%)*</span> | 360fps <span style={{color:'orange'}}>*(+11.1%)*</span> |
| Mandalorian | 312fps | 336fps <span style={{color:'green'}}>*(+7.7%)*</span> | 326fps <span style={{color:'orange'}}>*(+4.5%)*</span> |

Looking at the FD0 column of the below and above table, compared to the *preset 2* ones, my claim seems to barely apply and only consistently at low quality levels at that. We'll see how it goes for *preset 6* in the next sub-section.

Anyway, the average decoding speed impact at *HQ* is as follow:
- `+9.2%` for `--fast-decode 1`,
- `+7.1%` for `--fast-decode 2`.

| Preset 4 Decoding Test (CRF33) | FD0 | FD1 | FD2 |
|:-:|:-:|:-:|:-:|
| Avatar      | 432fps | 494fps <span style={{color:'green'}}>*(+14.4%)*</span> | 499fps <span style={{color:'green'}}>*(+15.5%)*</span> |
| Ducks       | 354fps | 394fps <span style={{color:'green'}}>*(+11.3%)*</span> | 375fps <span style={{color:'orange'}}>*(+5.9%)*</span> |
| Fallout     | 143fps | 156fps <span style={{color:'green'}}>*(+9.1%)*</span> | 146fps <span style={{color:'orange'}}>*(+2.1%)*</span> |
| Minecraft   | 197fps | 258fps <span style={{color:'green'}}>*(+31.0%)*</span> | 254fps <span style={{color:'orange'}}>*(+28.9%)*</span> |
| Sol Levante | 200fps | 224fps <span style={{color:'green'}}>*(+12.0%)*</span> | 217fps <span style={{color:'orange'}}>*(+8.5%)*</span> |
| Suzume      | 696fps | 811fps <span style={{color:'green'}}>*(+16.5%)*</span> | 763fps <span style={{color:'orange'}}>*(+9.6%)*</span> |
| Mandalorian | 902fps | 981fps <span style={{color:'green'}}>*(+8.8%)*</span> | 999fps <span style={{color:'green'}}>*(+10.8%)*</span> |

`--fast-decode 1` gives a hefty `+14.7%` increase in decoding performance at *lower quality* targets, as certain clips like *"Minecraft"*  greatly benefit from it.
`--fast-decode 2` brings a more modest `+11.6%` improvement.

The trade-offs are quite a bit different than at *preset 2* which is quite fascinating, but `--preset 4` seems to draw more benefit from *fast-decode*!

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/z063QyOe) | [Avatar (LQ)](https://slow.pics/c/fjOkslFE) |
| [Ducks (HQ)](https://slow.pics/c/mUdjpzQE) | [Ducks (LQ)](https://slow.pics/c/PJFYyxwC) |
| [Fallout (HQ)](https://slow.pics/c/pBUEwMuo) | [Fallout (LQ)](https://slow.pics/c/Rk9yKcOL) |
| [Minecraft (HQ)](https://slow.pics/c/0M6hKQxg) | [Minecraft (LQ)](https://slow.pics/c/ZNovZDlt) |
| [Sol Levante (HQ)](https://slow.pics/c/sodLtXq2) | [Sol Levante (LQ)](https://slow.pics/c/5Oqc0ljs) |
| [Suzume (HQ)](https://slow.pics/c/IdFzXbrh) | [Suzume (LQ)](https://slow.pics/c/pUqrSDSp) |
| [Mandalorian (HQ)](https://slow.pics/c/HvpNGjj7) | [Mandalorian (LQ)](https://slow.pics/c/JKLlXygr) |

---
#### Preset 6

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

The efficiency situation here is the same as on *preset 4*, however we notice `--fast-decode 1` is no longer slower than disabled. Instead, it places itself in-between *0* and *2* in terms of performance, offering another kind of trade-off again!

What influence on decoding speeds can we expect at `--preset 6`?

| Preset 6 Decoding Test (CRF12) | FD0 | FD1 | FD2 |
|:-:|:-:|:-:|:-:|
| Avatar      | 218fps | 216fps <span style={{color:'red'}}>*(-0.9%)*</span> | 228fps <span style={{color:'green'}}>*(+4.6%)*</span> |
| Ducks       | 128fps | 127fps <span style={{color:'red'}}>*(-0.8%)*</span> | 130fps <span style={{color:'green'}}>*(+1.6%)*</span> |
| Fallout     | 76fps | 74fps <span style={{color:'red'}}>*(-2.6%)*</span> | 77fps <span style={{color:'green'}}>*(+1.3%)*</span> |
| Minecraft   | 110fps | 106fps <span style={{color:'red'}}>*(-3.6%)*</span> | 112fps <span style={{color:'green'}}>*(+1.8%)*</span> |
| Sol Levante | 100fps | 104fps <span style={{color:'green'}}>*(+4.0%)*</span> | 107fps <span style={{color:'green'}}>*(+7.0%)*</span> |
| Suzume      | 382fps | 381fps <span style={{color:'red'}}>*(-0.3%)*</span> | 394fps <span style={{color:'green'}}>*(+3.1%)*</span> |
| Mandalorian | 343fps | 343fps <span style={{color:'orange'}}>*(0.0%)*</span> | 357fps <span style={{color:'green'}}>*(+4.1%)*</span> |

This time, be it at high or low quality, the base decoding speed without fast-decode is almost always faster.

At *CRF12*, `--fast-decode 1` and `--fast-decode 2` respectively deliver a `-0.6%` decoding speed regression and a `+3.4%` speed improvement.

| Preset 6 Decoding Test (CRF33) | FD0 | FD1 | FD2 |
|:-:|:-:|:-:|:-:|
| Avatar      | 468fps | 480fps <span style={{color:'green'}}>*(+2.6%)*</span> | 508fps <span style={{color:'green'}}>*(+8.5%)*</span> |
| Ducks       | 358fps | 364fps <span style={{color:'green'}}>*(+1.7%)*</span> | 382fps <span style={{color:'green'}}>*(+6.7%)*</span> |
| Fallout     | 169fps | 168fps <span style={{color:'red'}}>*(-0.6%)*</span> | 177fps <span style={{color:'green'}}>*(+4.7%)*</span> |
| Minecraft   | 278fps | 303fps <span style={{color:'green'}}>*(+9.0%)*</span> | 335fps <span style={{color:'green'}}>*(+20.5%)*</span> |
| Sol Levante | 209fps | 215fps <span style={{color:'green'}}>*(+2.9%)*</span> | 221fps <span style={{color:'green'}}>*(+5.7%)*</span> |
| Suzume      | 667fps | 694fps <span style={{color:'green'}}>*(+4.0%)*</span> | 715fps <span style={{color:'green'}}>*(+7.2%)*</span> |
| Mandalorian | 878fps | 912fps <span style={{color:'green'}}>*(+3.9%)*</span> | 950fps <span style={{color:'green'}}>*(+8.2%)*</span> |

The gains at low qualities are more appealing, at `+3.4%` for `--fast-decode 1` and `+8.8%` for `--fast-decode 2`.

`--preset 6` benefits less from *fast-decode*, especially mode *1*, probably due to a shift in the decoding bottlenecks past this point.

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/P1ghVYLa) | [Avatar (LQ)](https://slow.pics/c/FtUPq8PL) |
| [Ducks (HQ)](https://slow.pics/c/sNribSBQ) | [Ducks (LQ)](https://slow.pics/c/MYYl1GBK) |
| [Fallout (HQ)](https://slow.pics/c/3GXE1MYP) | [Fallout (LQ)](https://slow.pics/c/YtIF51Xn) |
| [Minecraft (HQ)](https://slow.pics/c/ccPFfGsI) | [Minecraft (LQ)](https://slow.pics/c/3hsSuzSD) |
| [Sol Levante (HQ)](https://slow.pics/c/0MBOG9TK) | [Sol Levante (LQ)](https://slow.pics/c/NOIjeZkg) |
| [Suzume (HQ)](https://slow.pics/c/6ghzI8QM) | [Suzume (LQ)](https://slow.pics/c/ktntjOqm) |
| [Mandalorian (HQ)](https://slow.pics/c/0hv7XLQv) | [Mandalorian (LQ)](https://slow.pics/c/kVc5GHuR) |

---
#### Fast Decode Conclusion

In performance constrained scenarios, like low power ARM devices, fast-decode could come in handy to help smooth out your playback experience, at the possible cost of some efficiency.

Keep in mind it has been observed that the output of *fast-decode* modes can be more prone to macro-blocking depending on source characteristics, so proceed with caution.

---
### Tiles

AV1 tiles are a straightforward method of splitting the video frame into independent tiles of equal size to hopefully increase encoding and decoding thread-ability. In SVT-AV1, tiles don't increase encoding speeds but they can help devices (especially low-powered ones) to software decode AV1 more easily. We are going to challenge these claims.

> *In the following graphs and tables, `c` refers to `--tile-columns` and `r` refers to `--tile-rows`. For instance, `c2r1` can be read as `--tile-columns 2 --tile-rows 1`.*

---> Compression efficiency graphs, *"high quality"* range (CRF10 -> 23):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Compression efficiency graphs, *"low quality"* range (CRF28 -> 50):

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Speed graphs:

> **Interactive comparison:** [Open the complete media manifest](/media/articles/svt-av1-fourth-deep-dive-p2.json).

---> Interpretation:

Except on *"Suzume"*, and to some extent on *"Mandalorian"* at low qualities, where we see the higher number of tiles start to impact efficiency, the effect of tiles on efficiency is by in large negligible. It does seem like encoding speeds aren't particularly impacted by tiles in this encoder.

Let's also look at decoding speeds, as we did with *fast-decode*!

What follows are the relative decoding speed improvements relative to `c0r0`, starting with tests at *CRF12*:

| Tiles Decoding Test (CRF12) | c0r0 | c1r0 | c1r1 | c2r0 | c2r1 |
|:-:|:-:|:-:|:-:|:-:|:-:|
| Avatar      | 185fps | 335fps <span style={{color:'green'}}>*(+81%)*</span> | 446fps <span style={{color:'green'}}>*(+141%)*</span> | 477fps <span style={{color:'green'}}>*(+158%)*</span> | 487fps <span style={{color:'green'}}>*(+163%)*</span> |
| Ducks       | 117fps | 224fps <span style={{color:'green'}}>*(+91%)*</span> | 330fps <span style={{color:'green'}}>*(+182%)*</span> | 348fps <span style={{color:'green'}}>*(+197%)*</span> | 410fps <span style={{color:'green'}}>*(+250%)*</span> |
| Fallout     | 67fps | 125fps <span style={{color:'green'}}>*(+87%)*</span> | 186fps <span style={{color:'green'}}>*(+178%)*</span> | 202fps <span style={{color:'green'}}>*(+201%)*</span> | 223fps <span style={{color:'green'}}>*(+233%)*</span> |
| Minecraft   | 87fps | 164fps <span style={{color:'green'}}>*(+89%)*</span> | 223fps <span style={{color:'green'}}>*(+156%)*</span> | 256fps <span style={{color:'green'}}>*(+194%)*</span> | 267fps <span style={{color:'green'}}>*(+207%)*</span> |
| Sol Levante | 91fps | 162fps <span style={{color:'green'}}>*(+78%)*</span> | 205fps <span style={{color:'green'}}>*(+125%)*</span> | 219fps <span style={{color:'green'}}>*(+141%)*</span> | 217fps <span style={{color:'orange'}}>*(+138%)*</span> |
| Suzume      | 324fps | 544fps <span style={{color:'green'}}>*(+68%)*</span> | 679fps <span style={{color:'green'}}>*(+110%)*</span> | 732fps <span style={{color:'green'}}>*(+126%)*</span> | 729fps <span style={{color:'orange'}}>*(+125%)*</span> |
| Mandalorian | 312fps | 520fps <span style={{color:'green'}}>*(+67%)*</span> | 631fps <span style={{color:'green'}}>*(+102%)*</span> | 681fps <span style={{color:'green'}}>*(+118%)*</span> | 688fps <span style={{color:'green'}}>*(+121%)*</span> |

The same tests were conducted at *CRF33* to quantify the differences in impact between two very distinctive quality targets:

| Tiles Decoding Test (CRF33) | c0r0 | c1r0 | c1r1 | c2r0 | c2r1 |
|:-:|:-:|:-:|:-:|:-:|:-:|
| Avatar      | 432fps | 698fps <span style={{color:'green'}}>*(+62%)*</span> | 780fps <span style={{color:'green'}}>*(+81%)*</span> | 816fps <span style={{color:'green'}}>*(+89%)*</span> | 758fps <span style={{color:'orange'}}>*(+75%)*</span> |
| Ducks       | 354fps | 650fps <span style={{color:'green'}}>*(+84%)*</span> | 845fps <span style={{color:'green'}}>*(+139%)*</span> | 860fps <span style={{color:'green'}}>*(+143%)*</span> | 920fps <span style={{color:'green'}}>*(+160%)*</span> |
| Fallout     | 143fps | 259fps <span style={{color:'green'}}>*(+81%)*</span> | 355fps <span style={{color:'green'}}>*(+148%)*</span> | 375fps <span style={{color:'green'}}>*(+162%)*</span> | 386fps <span style={{color:'green'}}>*(+170%)*</span> |
| Minecraft   | 197fps | 346fps <span style={{color:'green'}}>*(+76%)*</span> | 432fps <span style={{color:'green'}}>*(+119%)*</span> | 489fps <span style={{color:'green'}}>*(+148%)*</span> | 481fps <span style={{color:'orange'}}>*(+144%)*</span> |
| Sol Levante | 200fps | 295fps <span style={{color:'green'}}>*(+48%)*</span> | 285fps <span style={{color:'orange'}}>*(+43%)*</span> | 312fps <span style={{color:'green'}}>*(+56%)*</span> | 292fps <span style={{color:'orange'}}>*(+46%)*</span> |
| Suzume      | 696fps | 991fps <span style={{color:'green'}}>*(+42%)*</span> | 1020fps <span style={{color:'green'}}>*(+47%)*</span> | 1082fps <span style={{color:'green'}}>*(+55%)*</span> | 1008fps <span style={{color:'orange'}}>*(+45%)*</span> |
| Mandalorian | 902fps | 1183fps <span style={{color:'green'}}>*(+31%)*</span> | 1164fps <span style={{color:'orange'}}>*(+29%)*</span> | 1207fps <span style={{color:'green'}}>*(+34%)*</span> | 1128fps <span style={{color:'orange'}}>*(+25%)*</span> |

No, you aren't dreaming! We immediately realize that the impact of tiles is significantly greater than either of the *fast-decode* modes, an especially appealing outcome given their relatively minor effect on compression efficiency. Decoding speeds improve even further at higher quality settings, with the smallest gain reaching **+67%** at *CRF12*. That kind of difference can turn an unplayable file into one that runs smoothly. A single additional tile can have important consequences.

*Tile-rows* on average offer less benefit than *tile-columns*, and in some cases even cause slight regressions at lower qualities. Still, seeing up to +250% improvements in decoding speed is nothing to scoff at. [Dav1d](https://code.videolan.org/videolan/dav1d/)’s performance is genuinely impressive, now exceeding **1000fps** on certain clips!

---> Visual Comparisons:

| HQ | LQ |
|:-:|:-:|
| [Avatar (HQ)](https://slow.pics/c/6ZctTOwN) | [Avatar (LQ)](https://slow.pics/c/bHKBXQsC) |
| [Ducks (HQ)](https://slow.pics/c/psvcfJR0) | [Ducks (LQ)](https://slow.pics/c/dYIJoDX9) |
| [Fallout (HQ)](https://slow.pics/c/9cImaJgO) | [Fallout (LQ)](https://slow.pics/c/lfD5I54d) |
| [Minecraft (HQ)](https://slow.pics/c/TG61F71o) | [Minecraft (LQ)](https://slow.pics/c/HVRceUiN) |
| [Sol Levante (HQ)](https://slow.pics/c/rWdmd8dP) | [Sol Levante (LQ)](https://slow.pics/c/I9H4Akva) |
| [Suzume (HQ)](https://slow.pics/c/uC13Y3J7) | [Suzume (LQ)](https://slow.pics/c/zL4abWSW) |
| [Mandalorian (HQ)](https://slow.pics/c/cnUI9sTu) | [Mandalorian (LQ)](https://slow.pics/c/5WlGC4R6) |

If I had to give recommendations based on what we saw, for a good balance between losses in efficiency and increased decoding performance, consider the following tile settings:
- `--tile-columns 1 --tile-rows 0`: for 1080p and above
- `--tile-columns 2 --tile-rows 0`: for 4K and above

Of course, if decoding speed isn’t a concern at all, you can stick with the default `--tile-columns 0 --tile-rows 0`. But even then, I believe enabling tiles is worth considering for future-proofing purposes.

One can combine *fast-decode* and tiles to decrease decoding complexity further.

## Statistics

Who doesn't love a bunch of random and useless stats? Well, if you recognize yourself in this, I got you. I compiled a few, though I only included stuff that ended up being used in these two parts. Yes, test encodes, test graphs or test comps figures are *not* included here.

Here's this deep dive in numbers:
- **10577** total AV1 encodes...
- ...which account for a total size of **294GB**...
- ...which makes for an average of about **28MB** per file
- **3928** total graphs
- **2030** total decoding runs
- **483** slow.pics comps...
- ...for a grand total of about *12000* distinct screenshots uploaded!

Even I was flabbergasted when I discovered the actual scope of this benchmarking session!

## Conclusion

In this second part, we took a deep dive into several key SVT-AV1 encoding parameters, re-evaluating them in today's context. The goal was mainly to explore how these settings impact efficiency and encoding speeds, but at times also decoding performance or practical usability. While I could have revisited even more parameters, the sheer time investment required means I had to draw the line somewhere. I made sure to go **really in-depth** with the ones that mattered most in my opinion.

As always, your mileage may vary regarding any kind of speed figures. The key is to **test things yourself**, with your own clips, workflows, and goals in mind. What works for one setup might not suit another, and that’s what makes this kind of testing both challenging... and somewhat rewarding too.

This wraps up Part 2, but there’s more to come. I'm always thinking about what to explore next, and your feedback helps shape that direction. So if you have suggestions, requests, or thoughts to share, I’d love to hear them, in the usual places.

Thanks again for reading, and I hope you found this deep dive insightful!

## Future

~~First of all, I do not consider this testing complete. I have been told some comps had issues, and while re-generating them, I ended up rate-limited by slow.pics again, though only temporarily fortunately. As you can imagine, even with scripts, preparing and uploading these takes quite a while already, but I'm taking even more precautions to avoid getting banned again. I decided not to delay this Part further, so you wouldn't have to wait more, but I'll ask you to be patient a bit longer for me to add the fixed comps for Part 1 and the varboost octiles comps for this Part. I expect to be able to update both articles before the end of the week.~~

**EDIT (July 4):** These concerns have been addressed. Thanks for your patience.

As I alluded to in the last section, I have ideas for future blog posts. First of all, **SVT-AV1 v3.1.0 is right around the corner**, and it is touted to be quite an update especially for VBR and realtime usecases! It could be the occasion for me to do the long awaited *target bitrate* tests and compare efficiency with CRF on our test samples...

Second, most of the ideas I proposed in past articles remain valid possibilities and I still want to test other AV1 encoders in this format. AV2 is approaching too so it would be interesting to make some early comparisons of AV1 with AVM, if there's enough time for that.

Third, there's still so much that could be improved in my methodology, to make it more robust and precise, so I will continue experimenting as usual to find a better overall formula!

Lastly, I’ve also been working on a few AV1-related projects behind the scenes, including one that involves SVT-AV1 directly... I’m looking forward to sharing more about it in the future, so stay tuned!

I want to extend my thanks a second time to the people who contributed, directly or indirectly, to the making of this article, including [Gianni Rosato (gb82)](https://github.com/gianni-rosato), [Line (Lumen)](https://codeberg.org/Line-fr), [Soda](https://github.com/GreatValueCreamSoda), [Emre](https://github.com/emrakyz), [Bolu](https://github.com/0xb01u/), [Julio Barba](https://github.com/juliobbv-p), the people behind slow.pics for hosting thousands of screenshots each time I make these articles, the SVT-AV1 dev team for the work on this amazing encoder, and probably others I'm forgetting...

---
*Consider supporting me by making a donation on [my Ko-Fi page](https://ko-fi.com/nekotrix).*

{}