AVIF‑Encoder‑Vergleich 2025 — SVT‑AV1 / libaom / rav1e zu Qualität und Tempo

Einführung

AVIF ist sehr effizient, doch Encoder (SVT‑AV1 / libaom / rav1e) unterscheiden sich in Qualität/Tempo/Stabilität. Nicht nur Dateigröße zählt: visuelle Artefakte, Dekodierzeit, CI‑Laufzeit und Paramater‑Stabilität fließen in die Entscheidung ein. Dieser Artikel beschreibt ein Datenset und eine Bewertungsachse für belastbare Praxisempfehlungen.

Hintergrund: Ultimative Bildkompressions-Strategie 2025 – Praxisleitfaden zur Qualitätswahrung bei maximaler Performance, Kompressionsartefakte Audit 2025 — Was prüfen, wann es schlimmer wird und wie vermeiden

TL;DR

• Kompatibel/stabil: libaom; schnell: SVT‑AV1; Charakter/Referenz: rav1e
• WebP als Basis, AVIF zusätzlich prüfen (Haut/Text/Verlauf), LCP‑Kandidaten nach Dekodierzeit bewerten

Datenset und Bewertungsachsen

Datenset (Beispiel):

• Porträt (Haut/Bokeh) ×3
• Text/UI (feine Linien/hoher Kontrast) ×3
• Landschaft (feines Laub/Ziegel) ×3
• Gradienten (Himmel/Flächen) ×3

Bewertung:

• Visuelle Artefakte (Banding bei Haut/Verlauf, Ringing, Texturhaltung)
• Dateigröße (repräsentative Breiten: 640/960/1280/1536)
• Encode‑Zeit (Durchschnitt/CI‑Durchsatz)
• Decode‑Zeit (relevant für LCP)

SSIM/PSNR als Hilfsmetrik, finale Entscheidung visuell.

Vergleichskriterien

• Artefakte (Kanten/Haut/Gradient/Noise)
• Dateigröße (3–5 Breiten vergleichen)
• Encode/Decode‑Zeit (Server/Klient‑Last)

Weitere Punkte:

• Parameter‑Stabilität (Streuung bei gleichem q/speed)
• Portabilität (CLI/Lib/Hosting)

Befehlsbeispiele

# libaom (avifenc)
avifenc --min 28 --max 32 --speed 6 input.png out-libaom.avif

# SVT-AV1
aomenc --good --cpu-used=6 -q 35 -o out-svt.ivf input.y4m
# → anschließend mit geeignetem Tool zu AVIF packen

# rav1e
rav1e input.y4m -s 6 -q 35 -o out-rav1e.ivf

In der Praxis dominiert Batch‑Verarbeitung via GUI/Bibliotheken – stabiler Toolchain und CI‑Laufzeit Gewicht geben.

Preset‑Anhaltspunkte (Stills)

• libaom: --min 28 --max 32 --speed 6 (qualitätsorientiert, stabil)
• SVT‑AV1: -q 34–38 --cpu-used=6 (Tempo/Größe balanciert)
• rav1e: -q 34–38 -s 6 (für Vergleich/Validierung)

UI/Text: 4:4:4/Lossless erwägen. Fotos: meist 4:2:0 ausreichend.

Vorgehen in Projekten

1. WebP/AVIF auf repräsentativen Szenen vergleichen, SSIM/Butteraugli als Hilfen
2. Bei Artefakten WebP bevorzugen; sonst AVIF übernehmen
3. LCP‑Bilder mit priority/preload kombinieren und Dateigröße vs. Decode‑Zeit ausbalancieren

Tuning‑Flow

1. WebP als Basis (q=75–80)
2. AVIF mit q=34–38 testen (Haut/Text/Verlauf prüfen)
3. Probleme → WebP oder q schrittweise erhöhen
4. LCP → ggf. q um 2–4 senken und Breitenwahl optimieren

Next.js‑Einbettung

<Image
  src="/img/hero-1280.avif"
  alt="Hero"
  width={1280}
  height={720}
  sizes="(max-width: 768px) 100vw, 768px"
  priority
  fetchPriority="high"
  // Nicht‑Hero: loading="lazy" decoding="async"
/>

• 3–5 Breiten × WebP/AVIF
• sizes exakt zum Layout
• Nur LCP‑Kandidat priorisieren

Benchmark‑Pipeline (Automation‑Gerüst)

1. Datenset fixieren (12–20 Szenen, Versionierung bei Änderungen)
2. Raster: Encoder × Breite × q/speed generieren
3. Messen: Größe/Encode‑Zeit/SSIM/Butteraugli sammeln
4. Visualisieren: Vergleichsseite (Artefakte sichtbar machen)
5. Empfehlung: Schwellenwert‑basiert Presets wählen und in CI anwenden

Snippet (Node):

import { execFile } from 'node:child_process';
function run(cmd: string, args: string[]) {
  return new Promise((res, rej) => execFile(cmd, args, (e, o) => e ? rej(e) : res(o)));
}

Praxisnotizen (Stolpersteine)

• rav1e: gelegentliche Schwankungen → Version pinnen
• SVT‑AV1: schnell, aber Artefaktbild hängt von q‑Stufen ab
• libaom: stabil, aber CI‑Zeit und Parametrisierung beachten
• CDN‑Seite: Re‑Compression/Packaging ausschließen (Double‑Compression vermeiden)

QA‑Checkliste

• [ ] Keine sichtbaren Artefakte bei Haut/Text/Gradient/High‑Freq
• [ ] Breiten/sizes konsistent mit dem Layout
• [ ] LCP‑Kandidaten nach Decode‑Zeit feinjustiert (q)
• [ ] CI‑Laufzeit akzeptabel

FAQ

F. Welchen Encoder zuerst?

A. Basis mit libaom, bei Zeitdruck SVT‑AV1 testen; für Beobachtung rav1e dazunehmen.

F. Kleine Artefakte, aber große Größen‑Differenz?

A. LCP/Decode‑Zeit/Operations‑Stabilität mitbewerten; zählt es spürbar für Nutzer?

Auswahlrichtschnur

• „Im Zweifel WebP, mit Puffer AVIF testen“ – sichere, realistische Migration
• Motivabhängigkeit beachten: wenn AVIF bei Haut/Text/Gradient patzt, WebP vorziehen
• CI‑Zeit/Hosting‑Kompatibilität/Decode‑Zeit mit im Blick behalten

Zusammenfassung

Encoder differieren, aber die Entscheidung bleibt eine Kombination aus visueller Prüfung und Betriebsrealität. WebP stabil betreiben, AVIF schrittweise einführen.