FFmpeg Video komprimieren — Best Practices aus der Praxis

FFmpeg-Video-Komprimierung läuft auf drei Regler hinaus — CRF (Qualität), Preset (Geschwindigkeit) und Codec (Effizienz). Dieser tiefe Guide deckt alles ab: von der CRF-Mathematik über Two-Pass-Encoding, H.264 vs H.265 vs AV1 Benchmarks bis zu Praxisszenarien (Web, Social, Archivierung, HLS). Jeder Command hier ist Copy-Paste-bereit.

CRF (Constant Rate Factor) verstehen

CRF ist die wichtigste Einstellung für qualitätsbasiertes Komprimieren. Sie sagt dem Encoder: ziel auf eine konstante visuelle Qualität, lass die Bitrate variieren wie nötig. Niedrigeres CRF = höhere Qualität = größere Datei. Höheres CRF = niedrigere Qualität = kleinere Datei.

CRF-Werte für H.264 (libx264)

ffmpeg -i input.mp4 -c:v libx264 -crf 23 output.mp4

Die CRF-Skala für H.264 reicht von 0 (lossless) bis 51 (worst). Was die Werte produzieren:

CRF	Qualitätsniveau	Typischer Use Case	Dateigröße (vs CRF 23)
0	Lossless	Archiv, Editing-Master	10-50x größer
14	Near-Lossless	Professionelle Postproduktion	4-6x größer
18	Visuell verlustfrei	Hochwertige Auslieferung, Premium-Streaming	2-3x größer
20	Exzellent	Hochwertiges Web-Video	1.5-2x größer
23	Gut (Default)	Allzweck, Web-Delivery	1x (Baseline)
26	Akzeptabel	Social Media, Mobile	0.5-0.7x
28	Mäßig	Bandbreiten-limitierte Auslieferung	0.3-0.5x
32	Niedrig	Previews, Thumbnails	0.15-0.25x
40	Sehr niedrig	Extreme Kompression (kaum noch ansehbar)	0.05-0.1x
51	Schlechtester	Nie verwenden	Winzig

Der Sweet Spot für die meisten Anwendungen liegt bei CRF 18-28. Unter 18 verbrätst du Bits für Qualitätsunterschiede, die kein Zuschauer wahrnimmt. Über 28 werden Artefakte deutlich sichtbar.

CRF-Werte für H.265 (libx265)

H.265 erreicht die gleiche visuelle Qualität bei ungefähr 40-50 % weniger Bitrate als H.264. Aber die CRF-Skala verschiebt sich: CRF 28 in H.265 entspricht ungefähr CRF 23 in H.264.

ffmpeg -i input.mp4 -c:v libx265 -crf 28 output.mp4

CRF (H.265)	Äquivalent H.264 CRF	Qualitätsniveau
18	~14	Near-Lossless
22	~18	Visuell verlustfrei
24	~20	Exzellent
28	~23	Gut (Default)
32	~26	Akzeptabel
36	~30	Niedrig

Wie du das richtige CRF wählst

Praxistipp:

1. Mit dem Default starten (23 für H.264, 28 für H.265)
2. Output anschauen — ist die Qualität okay?
3. In 2-4er Schritten in eine Richtung anpassen
4. A/B-Test — die gleiche komplexe Szene mit zwei CRF-Werten encoden und vergleichen

Szenen, die Kompressionsartefakte am ehesten zeigen: schnelle Bewegung, feine Texturen (Gras, Stoff), Verläufe (Himmel, Nebel) und dunkle Szenen mit subtilen Details. Eine einsteigerfreundliche Einführung findest du in unserem Video-Komprimieren-mit-FFmpeg-Guide.

Encoding-Presets: Speed vs. Quality

Der preset-Parameter steuert, wie viel CPU-Zeit der Encoder ins Optimieren steckt. Langsamere Presets erreichen bessere Kompression (kleinere Dateien bei gleicher Qualität) — auf Kosten längerer Encoding-Zeit.

H.264 Preset Benchmark

Alle Tests unten mit CRF 23 auf einer 1080p 60fps Quelle (2 Minuten):

Preset	Encoding-Zeit	Dateigröße	Quality (VMAF)
ultrafast	15s	85 MB	92.1
superfast	22s	62 MB	93.8
veryfast	30s	48 MB	94.5
faster	40s	42 MB	95.0
fast	52s	38 MB	95.3
medium	70s	35 MB	95.5
slow	120s	33 MB	95.7
slower	210s	31 MB	95.8
veryslow	450s	30 MB	95.9
placebo	1800s	29.5 MB	95.9

Was du mitnehmen solltest:

• medium ist der Default und der Sweet Spot für die meisten Workflows
• Von medium auf slow spart ~6 % Größe, kostet 70 % mehr Zeit
• Von medium auf veryslow spart ~14 %, kostet 6.4x mehr Zeit
• placebo bringt praktisch keine Verbesserung gegenüber veryslow — nie nutzen
• ultrafast produziert Dateien 2.4x größer als medium — nicht für finale Auslieferung

# Good default for most use cases
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset medium output.mp4

# When encoding time matters more than file size
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset fast output.mp4

# When file size matters more than encoding time
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset slow output.mp4

H.265 Preset-Verhalten

H.265-Presets folgen der gleichen Namenskonvention, aber das Encoding ist auf jeder Stufe deutlich langsamer:

Preset	H.264 Zeit	H.265 Zeit	H.265 Größe
fast	52s	180s	25 MB
medium	70s	300s	22 MB
slow	120s	600s	20 MB

H.265 dauert beim gleichen Preset ungefähr 3-5x länger als H.264, produziert aber 30-40 % kleinere Files bei gleichwertiger Qualität.

Two-Pass Encoding

Two-Pass Encoding gibt dir präzise Kontrolle über die Output-Bitrate, was essenziell ist, wenn du eine bestimmte Dateigrößen-Vorgabe treffen musst (z. B. „dieses Video muss unter 50 MB sein").

Wie das läuft

• Pass 1: FFmpeg analysiert das Video und schreibt eine Log-Datei mit Komplexitätsdaten
• Pass 2: FFmpeg nutzt das Log, um Bits optimal zu verteilen — mehr für komplexe Szenen, weniger für einfache

Basis-Two-Pass-Command

# Pass 1 — analyze (output is discarded)
ffmpeg -i input.mp4 -c:v libx264 -b:v 4M -pass 1 -f null /dev/null

# Pass 2 — encode using analysis data
ffmpeg -i input.mp4 -c:v libx264 -b:v 4M -pass 2 output.mp4

Ziel-Bitrate berechnen

Um eine Größenvorgabe zu treffen:

Video-Bitrate = (Zielgröße in Bits − Audiogröße in Bits) / Dauer in Sekunden

Beispiel: 10-Minuten-Video, 100 MB Ziel, 128kbps Audio:

Audio size = 128,000 bps × 600s = 76,800,000 bits = 9.6 MB
Video bitrate = (100 MB - 9.6 MB) × 8,000,000 / 600 = 1,205,333 bps ≈ 1.2 Mbps

ffmpeg -i input.mp4 -c:v libx264 -b:v 1200k -pass 1 -c:a aac -b:a 128k -f null /dev/null
ffmpeg -i input.mp4 -c:v libx264 -b:v 1200k -pass 2 -c:a aac -b:a 128k output.mp4

CRF vs. Two-Pass: Wann was

Ansatz	Geeignet für	Kontrolle
CRF	Konstante Qualität, unbekannte Dateigröße	Qualitäts-orientiert
Two-Pass	Zielgröße oder Bitrate	Größen-orientiert
CRF + maxrate	Qualität mit Bitraten-Deckel	Streaming

Für Streaming mit Bitrate-Cap:

ffmpeg -i input.mp4 -c:v libx264 -crf 23 -maxrate 4M -bufsize 8M output.mp4

Zielt auf CRF-23-Qualität, deckelt aber bei 4 Mbps — nützlich für Streaming, wo Bandbreite limitiert ist.

Codec-Vergleich: H.264 vs. H.265 vs. VP9 vs. AV1

Die Codec-Wahl ist ein Trade-off zwischen Kompressionseffizienz, Encoding-Geschwindigkeit und Wiedergabe-Kompatibilität.

Kompressionseffizienz

Bei gleichwertiger visueller Qualität (VMAF 95), relative Dateigrößen:

Codec	Relative Größe	Kompression vs H.264
H.264 (libx264)	100%	Baseline
H.265 (libx265)	55-65%	35-45% kleiner
VP9 (libvpx-vp9)	55-65%	35-45% kleiner
AV1 (libaom-av1)	40-50%	50-60% kleiner

Encoding-Geschwindigkeit

Relative Encoding-Zeit für eine 1080p 60fps Quelle bei gleichwertiger Qualität:

Codec	Zeit (relativ)	Anmerkung
H.264	1x	Schnell, gut optimiert
H.265	3-5x	Deutlich langsamer
VP9	5-10x	Sehr langsam (Default Single-Threaded)
AV1 (libaom)	20-50x	Extrem langsam
AV1 (SVT-AV1)	3-8x	Deutlich schnellere AV1-Implementierung

Wiedergabe-Kompatibilität (2026)

Codec	Browser	Mobile	Smart TVs	Hardware-Decode
H.264	99%+	99%+	99%+	Universal
H.265	Safari, Edge (teilweise)	iOS, Android 5+	Meiste moderne	Häufig
VP9	Chrome, Firefox, Edge	Android 5+	Eingeschränkt	Wachsend
AV1	Chrome, Firefox, Edge, Safari 17+	Flagship-Phones	Eingeschränkt	Im Aufkommen

Kommandos in der Praxis

# H.264 — maximum compatibility
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k output.mp4

# H.265 — 40% smaller, good mobile support
ffmpeg -i input.mp4 -c:v libx265 -crf 28 -preset medium -c:a aac -b:a 128k output.mp4

# VP9 — royalty-free, good for web
ffmpeg -i input.mp4 -c:v libvpx-vp9 -crf 30 -b:v 0 -row-mt 1 -c:a libopus -b:a 128k output.webm

# AV1 (SVT-AV1) — best compression, modern devices
ffmpeg -i input.mp4 -c:v libsvtav1 -crf 30 -preset 6 -c:a libopus -b:a 128k output.mp4

Welcher Codec für welchen Fall

Szenario	Empfohlener Codec	Warum
Maximale Kompatibilität	H.264	Spielt überall
Bandbreite sparen, Apple-Welt	H.265	Gute Kompression, iOS/macOS nativ
Web-First, lizenzfrei	VP9	Chrome/Firefox-Support, keine Lizenzgebühren
Zukunftssicher, beste Kompression	AV1 (SVT-AV1)	50%+ Ersparnis, wachsender Support
Gemischtes Publikum	H.264 mit H.265/AV1 als Fallback	Pro Gerät den besten Codec ausliefern

Mehr zum Wechsel zwischen Container-Formaten in unserem Video-Format-Konvertierungs-Guide.

Best Practices fürs Resolution Scaling

Video richtig herunterzuskalieren ist mehr als nur die Auflösung zu ändern.

Übliche Ziel-Auflösungen

Name	Auflösung	Typische Bitrate (H.264)	Typische Bitrate (H.265)
4K UHD	3840x2160	15-30 Mbps	8-15 Mbps
1440p	2560x1440	8-15 Mbps	4-8 Mbps
1080p Full HD	1920x1080	4-8 Mbps	2-4 Mbps
720p HD	1280x720	2-4 Mbps	1-2 Mbps
480p SD	854x480	1-2 Mbps	0.5-1 Mbps
360p	640x360	0.5-1 Mbps	0.3-0.5 Mbps

Skalieren mit Aspect Ratio

Nutze immer -1 für eine Dimension, um das Seitenverhältnis zu erhalten, und -2, um sicherzustellen, dass der Wert durch 2 teilbar ist (Pflicht bei den meisten Codecs):

# Scale to 720p width, auto-calculate height (divisible by 2)
ffmpeg -i input.mp4 -vf "scale=1280:-2" -c:v libx264 -crf 23 output.mp4

# Scale to 1080 height, auto-calculate width
ffmpeg -i input.mp4 -vf "scale=-2:1080" -c:v libx264 -crf 23 output.mp4

Qualität des Scaling-Filters

FFmpeg bietet mehrere Scaling-Algorithmen. Der Default (Bilinear) ist für die meisten Fälle okay, aber für beste Downscale-Qualität nimmst du Lanczos:

# High-quality downscale with Lanczos
ffmpeg -i input.mp4 -vf "scale=1280:720:flags=lanczos" -c:v libx264 -crf 23 output.mp4

Algorithmus	Speed	Downscale-Qualität	Geeignet für
fast_bilinear	Am schnellsten	Niedrig	Real-Time-Verarbeitung
bilinear	Schnell	Mittel	Default, allgemeine Verwendung
bicubic	Mittel	Gut	Mittlere Qualitätsansprüche
lanczos	Langsamer	Beste	Finale Auslieferung, qualitätskritisch
spline	Langsamer	Exzellent	Alternative zu Lanczos

Nicht hochskalieren

Faustregel: nie hochskalieren. 720p-Quelle als 1080p zu encoden verbrennt Bandbreite, ohne echtes Detail zu liefern. Wenn du musst, dann minimal — und mit Lanczos:

# If you must upscale (avoid when possible)
ffmpeg -i input_720p.mp4 -vf "scale=1920:1080:flags=lanczos" -c:v libx264 -crf 20 output.mp4

Audio-Komprimierung

Audio wird in Komprimierungs-Workflows oft übersehen, aber Optimierung kann signifikant Bandbreite sparen.

Empfohlene Audio-Settings

Use Case	Codec	Bitrate	Command
Allgemein Web-Video	AAC	128 kbps	-c:a aac -b:a 128k
Hochwertiges Video	AAC	192 kbps	-c:a aac -b:a 192k
Musik-Content	AAC	256 kbps	-c:a aac -b:a 256k
WebM/VP9 Video	Opus	128 kbps	-c:a libopus -b:a 128k
Podcast/Sprache	AAC	64 kbps	-c:a aac -b:a 64k
Podcast/Sprache (Opus)	Opus	48 kbps	-c:a libopus -b:a 48k

Audio-Lautstärke normalisieren

Inkonsistente Audiopegel über Videos hinweg sind ein häufiges Problem. FFmpegs loudnorm-Filter normalisiert auf Broadcast-Standards:

# Normalize to -16 LUFS (standard for streaming)
ffmpeg -i input.mp4 -c:v copy -af "loudnorm=I=-16:TP=-1.5:LRA=11" -c:a aac -b:a 128k output.mp4

Audio entfernen

Wenn du Audio gar nicht brauchst:

ffmpeg -i input.mp4 -an -c:v libx264 -crf 23 output.mp4

Audio kopieren ohne Re-Encode

Wenn das Audio bereits passend ist:

ffmpeg -i input.mp4 -c:v libx264 -crf 23 -c:a copy output.mp4

Praxisszenarien für Komprimierung

Web-Auslieferung (Allzweck)

Das häufigste Szenario — Video für Embedding auf Webseiten:

ffmpeg -i input.mp4 \
  -c:v libx264 -crf 23 -preset medium \
  -vf "scale=1920:1080:flags=lanczos" \
  -c:a aac -b:a 128k \
  -movflags +faststart \
  output.mp4

Wichtige Details:

• -movflags +faststart schiebt die Metadaten an den Anfang der Datei und ermöglicht Progressive Playback (essenziell fürs Web)
• CRF 23 liefert gute Balance aus Qualität und Größe
• AAC 128k reicht für die meisten Web-Inhalte

Social Media optimiert

Plattformen wie Twitter/X, Instagram und TikTok haben spezifische Anforderungen:

# Optimized for social platforms (H.264, AAC, fast start)
ffmpeg -i input.mp4 \
  -c:v libx264 -crf 23 -preset medium \
  -profile:v high -level:v 4.0 \
  -pix_fmt yuv420p \
  -vf "scale=1080:1920:force_original_aspect_ratio=decrease,pad=1080:1920:(ow-iw)/2:(oh-ih)/2" \
  -c:a aac -b:a 128k -ar 44100 \
  -movflags +faststart \
  output.mp4

• -profile:v high -level:v 4.0 sichert breite Kompatibilität
• -pix_fmt yuv420p garantiert Wiedergabe auf allen Geräten
• scale + pad erzeugt ein 9:16 Hochformat-Video mit Letterboxing

Archiv (Maximale Qualität, minimaler Verlust)

Für Langzeitspeicherung, wo die Dateigröße sekundär ist:

ffmpeg -i input.mp4 \
  -c:v libx264 -crf 16 -preset slow \
  -c:a flac \
  output.mkv

• CRF 16 erhält praktisch jedes visuelle Detail
• FLAC-Audio ist verlustfrei
• MKV-Container unterstützt mehr Codecs als MP4

Streaming (Adaptive Bitrate mit HLS)

Mehrere Qualitätsstufen aus der Quelle erzeugen:

ffmpeg -i input.mp4 \
  -map 0:v -map 0:a -map 0:v -map 0:a -map 0:v -map 0:a \
  -c:v libx264 -crf 22 \
  -c:a aac -b:a 128k \
  -var_stream_map "v:0,a:0 v:1,a:1 v:2,a:2" \
  -b:v:0 5M -maxrate:v:0 5.5M -bufsize:v:0 10M -s:v:0 1920x1080 \
  -b:v:1 2.5M -maxrate:v:1 2.75M -bufsize:v:1 5M -s:v:1 1280x720 \
  -b:v:2 1M -maxrate:v:2 1.1M -bufsize:v:2 2M -s:v:2 854x480 \
  -f hls -hls_time 6 -hls_list_size 0 \
  -master_pl_name master.m3u8 \
  stream_%v/playlist.m3u8

Batch-Komprimierungs-Skript

Für ein ganzes Verzeichnis:

#!/bin/bash
# 批量压缩目录下所有视频
for f in *.mp4; do
  ffmpeg -i "$f" \
    -c:v libx264 -crf 23 -preset medium \
    -c:a aac -b:a 128k \
    -movflags +faststart \
    "compressed_${f}"
done

Cloud-Komprimierung mit FFHub

Alle Commands aus diesem Guide funktionieren direkt mit FFHub.io — einfach per API schicken:

# Compress a video in the cloud (no local FFmpeg needed)
curl -X POST https://api.ffhub.io/v1/tasks \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "command": "ffmpeg -i https://example.com/input.mp4 -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k -movflags +faststart output.mp4"
  }'

Das verlagert die CPU-intensive Encoding-Arbeit in die Cloud und hält deine lokale Maschine oder deinen Server frei. Besonders nützlich für Batch Video Transcoding oder wenn FFmpeg auf deinem App-Server die Performance kosten würde.

Schnellreferenz

Einzeiler

# Good default compression
ffmpeg -i input.mp4 -c:v libx264 -crf 23 -c:a aac -b:a 128k -movflags +faststart output.mp4

# Aggressive compression (smaller file)
ffmpeg -i input.mp4 -c:v libx264 -crf 28 -preset fast -c:a aac -b:a 96k output.mp4

# High-quality compression (larger file)
ffmpeg -i input.mp4 -c:v libx264 -crf 18 -preset slow -c:a aac -b:a 192k output.mp4

# Maximum compression with H.265
ffmpeg -i input.mp4 -c:v libx265 -crf 28 -preset medium -c:a aac -b:a 128k output.mp4

# Future-proof with AV1
ffmpeg -i input.mp4 -c:v libsvtav1 -crf 30 -preset 6 -c:a libopus -b:a 128k output.mp4

Entscheidungsbaum

1. Maximale Kompatibilität nötig? H.264 nehmen
2. Kleinere Files? H.265 (Apple/Mobile) oder VP9 (Web)
3. Kleinste Files und Zeit übrig? AV1
4. Konkrete Dateigröße? Two-Pass Encoding
5. Konstante Qualität? CRF
6. Viele Files? Preset fast oder veryfast
7. Eine wichtige Datei? Preset slow

Fazit

Effektive Video-Komprimierung läuft auf das Verstehen und Ausbalancieren dreier Faktoren hinaus: Qualität (CRF), Speed (Preset), Dateigröße (Codec-Wahl). Starte mit den Defaults — CRF 23, medium, H.264 — und passe an deinen Anwendungsfall an. Teste mit deinem echten Content, weil Komprimierungsverhalten zwischen Talking-Head-Videos und Action-Sequenzen drastisch unterschiedlich ist.

Die Commands hier sind Standard-FFmpeg — sie laufen auf deiner lokalen Maschine, auf jedem Server, oder über einen Cloud-Service wie FFHub. Beherrsch die Grundlagen, und du kommst mit jeder Komprimierungsanforderung zurecht.

Häufige Fragen (FAQ)

Welcher CRF eignet sich für Streaming-Video?

Für HLS / DASH-Adaptive-Streaming ist CRF 21–23 mit -maxrate- und -bufsize-Limits Standard. CRF hält die Qualität bei wechselnder Komplexität konstant, das Bitraten-Limit schützt vor Bandbreitenspitzen beim Zuschauer. CRF 23 für die höchste Variante, CRF 24–25 für die mittlere, CRF 26–28 für die niedrigste.

Two-Pass vs CRF: wann nutze ich was?

CRF wenn dir konstante Qualität wichtig ist (jedes Web- oder Archivierungs-Workflow). Two-Pass wenn du eine konkrete Dateigröße treffen musst (Discord 25MB-Cap, Broadcast-Spec, Werbeformat-Spec). Two-Pass dauert etwa 2x länger als CRF, gibt aber präzise Größenkontrolle. Für Streaming mit Bitraten-Limit aber qualitätszentrierter Logik kombiniere CRF mit -maxrate und -bufsize.

Warum ist H.265 so viel langsamer als H.264?

H.265 wertet deutlich mehr Blockgrößen, Prediction-Modi und Bewegungsvektoren pro Frame aus, um seinen 30–40 % Komprimierungsvorteil zu erreichen. Die HEVC-Spec ist absichtlich komplexer als H.264 — Komplexität gegen Effizienz. In der Praxis: H.265 mit libx265 -preset medium ist bei gleicher Ausgabequalität etwa 3–5x langsamer als H.264.

Ist AV1 2026 produktionsreif?

Für die Auslieferung ja, mit Einschränkungen. AV1-Hardware-Decoder sind inzwischen auf Flagship-Smartphones, aktuellen Konsolen und Apple Silicon verbreitet, aber ältere Geräte brauchen weiterhin einen H.264-Fallback. Beim Encoding ist SVT-AV1 (libsvtav1) die praktische Wahl — 3–8x langsamer als H.264 bei gleicher Qualität, gegenüber 20–50x langsamer bei libaom-av1. Netflix, YouTube und Vimeo liefern AV1 bereits an fähige Clients aus.

Wie komprimiere ich Videos im Batch mit konstanter Qualität über verschiedene Quellen?

Nutze CRF-Modus, nicht Bitraten-Modus — CRF passt sich an die Komplexität jeder Quelle an. Eine einfache Shell-Schleife mit -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k -movflags +faststart liefert über gemischte Eingaben einheitlich wahrgenommene Qualität. Brauchst du zusätzlich eine harte Dateigrößen-Obergrenze, leg -maxrate und -bufsize drauf (z. B. -maxrate 4M -bufsize 8M).

Macht -preset slow Dateien wirklich kleiner?

Ja, aber mit abnehmendem Ertrag. Von medium → slow sparst du etwa 6 % Dateigröße bei gleicher Qualität, aber die Encoding-Zeit steigt um ~70 %. medium → veryslow spart ~14 % bei 6,4-facher Encoding-Zeit. placebo ist praktisch identisch zu veryslow — nimm placebo nicht. Praxistauglich sind medium (Default), slow (Overnight-Batches, finale Auslieferung) und fast (Echtzeit oder Proxy).

Verwandte Artikel

• Wie du Video mit FFmpeg komprimierst - Einsteigerfreundlicher Guide zum Reduzieren der Videogröße
• Wie du Videoformat mit FFmpeg konvertierst - Wechsel zwischen MP4, MKV, WebM und anderen Containern mit Codec-Kontrolle
• Batch Video Transcoding API - Großskalige Video-Komprimierung über eine Cloud API automatisieren