Wenn Sie Videos erstellen, vorhandene Dateien konvertieren oder Videoinhalte für eine Website vorbereiten, gehört die Wahl des passenden Formats und der richtigen Komprimierungseinstellungen zu den wichtigsten Entscheidungen. Die kleinstmögliche Datei ist nicht unbedingt die beste. Sie muss auch in Browsern zuverlässig abspielbar sein, auf Smartphones funktionieren, effizient dekodiert werden und für ihren Einsatzzweck eine ausreichende Bildqualität bieten.
Ich habe mich mit MP4, WebM, H.264, H.265/HEVC, VP9, AV1, FFmpeg, den Encoder-Presets von x264, der Browserkompatibilität, der Hardwaredekodierung auf Mobilgeräten und der Messung der Videoqualität beschäftigt. Außerdem habe ich praktische Komprimierungsversuche durchgeführt: Ich habe dasselbe Ausgangsvideo mit unterschiedlichen CRF-Werten kodiert und die Ergebnisse sowohl visuell als auch anhand objektiver Messwerte verglichen.
Meine endgültige Entscheidung fiel auf MP4 mit H.264, wenn eine einzige Videodatei auf möglichst vielen Browsern, Smartphones und in externen Anwendungen funktionieren soll.
Für kurze Videos, die hauptsächlich auf Mobilgeräten angesehen werden und bei denen schnelles Laden und kleine Dateien wichtiger sind als jedes letzte Detail, habe ich mich für x264 mit CRF 30 entschieden. Selbst auf einem großen Desktop-Monitor konnte ich bei normaler Wiedergabe keinen nennenswerten Unterschied zwischen CRF 22 und 30 erkennen.
Diese Entscheidung muss jedoch klar eingegrenzt werden: CRF 30 ist keine Empfehlung für Spielfilme, hochwertige Videoproduktionen oder Aufnahmen, bei denen es auf maximale Bildtreue ankommt. Hier kann ein deutlich konservativerer Wert, häufig etwa CRF 20, der bessere Ausgangspunkt sein. Ich habe keine vergleichbare Untersuchung mit Spielfilmen oder hochwertigem Kinomaterial durchgeführt. Diese Einstellungen sind deshalb lediglich Ausgangspunkte für eigene Tests.
In diesem Artikel erläutere ich die technischen Überlegungen, die tatsächlichen Komprimierungsergebnisse und deren Grenzen. Außerdem zeige ich, wie Sie das passende Videoformat und die geeignete Qualitätseinstellung für Ihr Projekt auswählen können.
1. Videocontainer und Codecs sind nicht dasselbe
Bevor man MP4 und WebM vergleicht, muss man den Unterschied zwischen einem Container und einem Codec verstehen.
Ein Container fasst Video, Audio, Zeitstempel und Metadaten in einer Datei zusammen. Ein Videocodec legt fest, wie die einzelnen Videobilder komprimiert und dekodiert werden.
Eine MP4-Datei kann beispielsweise H.264-, HEVC- oder AV1-Videodaten enthalten. Obwohl die Dateiendung gleich ist, unterscheiden sich diese Kombinationen in der Komprimierung und den Anforderungen an die Geräte.
| Komponente | Beispiele | Aufgabe |
|---|---|---|
| Videocontainer | MP4, WebM, MOV, MKV | Fasst Video, Audio und Zeitinformationen zusammen |
| Videocodec | H.264, HEVC, VP9, AV1 | Komprimiert und dekomprimiert Videobilder |
| Audiocodec | AAC, Opus, MP3 | Komprimiert und dekomprimiert Audiodaten |
| Videoencoder | x264, x265, SVT-AV1, libvpx-vp9 | Implementiert die Videokomprimierung |
Wenn Sie eine Datei von .webm in .mp4 umbenennen, wird dadurch nicht der Videocodec konvertiert. Ebenso wird ein in MP4 gespeichertes AV1-Video auf Geräten ohne AV1-Dekodierung nicht plötzlich abspielbar.
Bei der Beurteilung der Kompatibilität zählt immer die gesamte Kombination aus Container, Videocodec, Audiocodec, Codec-Profil, Bittiefe und Wiedergabeumgebung.
2. MP4 oder WebM: Was eignet sich besser für Videos im Web?
MP4 und WebM sind beide moderne, etablierte Videocontainer. Keiner ist grundsätzlich überlegen, denn ihre praktischen Eigenschaften hängen von den enthaltenen Codecs ab.
MP4 mit H.264: größtmögliche praktische Kompatibilität
MP4-Dateien mit H.264-Video und AAC-Audio zeichnen sich seit Langem durch außergewöhnlich breite Kompatibilität aus. Sie werden von gängigen Desktop- und Mobilbrowsern, Videoplayern der Betriebssysteme und zahlreichen Drittanbieterprogrammen unterstützt.
Auch die Hardwaredecoder in Smartphones und Computern unterstützen diese Kombination häufig. Im Vergleich zur Softwaredekodierung kann die Hardwaredekodierung die CPU entlasten, die Wiedergabe effizienter machen und den Stromverbrauch senken.
Der wichtigste Nachteil ist die Komprimierungseffizienz: Neuere Codecs erzielen bei vergleichbarer wahrgenommener Qualität oft niedrigere Bitraten.
Dennoch bleibt H.264 eine ausgezeichnete Wahl, wenn zuverlässige Wiedergabe wichtiger ist als die absolut kleinste Datei.
WebM mit VP9: effizient und gut für Browser geeignet
WebM enthält üblicherweise Videodaten in VP8, VP9 oder AV1. Für Audio kommen meist Opus oder Vorbis zum Einsatz.
VP9 komprimiert bei vergleichbarer Bildqualität häufig effizienter als H.264. Aktuelle Browser unterstützen den Codec weitgehend, darunter auch moderne Safari-Versionen.
Es wäre falsch zu behaupten, Safari unterstütze WebM oder VP9 grundsätzlich nicht. Die Browserkompatibilität hat sich im Laufe der Zeit erheblich verbessert.
Die wichtigere Einschränkung liegt außerhalb des Browsers. Native Betriebssystemanwendungen, ältere Geräte und Drittanbieterprogramme gehen mit WebM möglicherweise weniger zuverlässig um als mit herkömmlichen H.264-MP4-Dateien.
Für reine Browseranwendungen mit kontrollierbaren Wiedergabefähigkeiten ist WebM eine gute Option. Wenn Besucher Videos herunterladen und in beliebigen Programmen öffnen sollen, ist MP4/H.264 weiterhin die berechenbarere Wahl.
Der praktische Unterschied
| Anforderung | MP4 + H.264 | WebM + VP9 |
|---|---|---|
| Wiedergabe in modernen Browsern | Ausgezeichnet | Sehr gut |
| Unterstützung älterer Browser und Geräte | Im Allgemeinen besser | Stärker von der Umgebung abhängig |
| Kompatibilität heruntergeladener Dateien | Im Allgemeinen besser | In nativen Anwendungen weniger berechenbar |
| Komprimierungseffizienz | Gut | Häufig besser |
| Hardwaredekodierung | Sehr weit verbreitet | Häufig vorhanden, aber geräteabhängig |
| Am besten geeignet für | Eine breit kompatible Datei | Effiziente Webauslieferung an bekannte Clients |
Entscheidend ist nicht, ob WebM ein gutes Format ist, sondern ob seine Vorteile bei der Komprimierung die Kompromisse bei der Kompatibilität in Ihrer konkreten Umgebung rechtfertigen.
3. H.264, H.265, VP9 oder AV1: Welchen Codec sollten Sie wählen?
Jeder wichtige Videocodec bietet eine andere Balance zwischen Komprimierungseffizienz, Rechenaufwand beim Kodieren, Hardwareunterstützung, Softwarekompatibilität und Lizenzierung.
| Codec | Komprimierungseffizienz | Praktische Kompatibilität | Typischer Einsatz |
|---|---|---|---|
| H.264 / AVC | Gut | Ausgezeichnet | Allgemeine Webvideos, mobile Wiedergabe, Downloads |
| H.265 / HEVC | Im Allgemeinen besser als H.264 | Umgebungsabhängig | Kompatible Apple-Geräte, kontrollierte Umgebungen, hochauflösende Videos |
| VP9 | Im Allgemeinen besser als H.264 | Sehr gut in modernen Browsern | Videobereitstellung im Browser |
| AV1 | Potenziell ausgezeichnet | Zunehmend besser, mit Einschränkungen bei älteren Geräten | Modernes Streaming und kompatible Geräte |
Das sind qualitative Vergleiche und keine allgemeingültige Rangliste nach Bitrate. Die tatsächliche Effizienz hängt vom Videomaterial, der Encoder-Implementierung, der angestrebten Qualität, dem Preset und dem Messverfahren ab.
H.264: ausgereift, schnell zu dekodieren und breit unterstützt
H.264 ist stark optimiert und wird von sehr vielen Hardware- und Softwarelösungen unterstützt. Diese Reife ist ein Vorteil, wenn ein Video ohne spezielle Wiedergabesoftware zuverlässig funktionieren soll.
Sein Schwachpunkt ist die häufig höhere Komprimierungseffizienz neuerer Codecs. Außerdem sind bei H.264 Patente und Lizenzfragen zu beachten, die für entsprechende kommerzielle Verbreitungsszenarien geprüft werden sollten.
H.265 / HEVC: bessere Komprimierung mit Kompatibilitätskompromissen
HEVC kann die Bitrate gegenüber H.264 bei ähnlicher Qualität deutlich reduzieren. Besonders interessant ist das bei hochauflösenden Inhalten und in Umgebungen, in denen die Gerätekompatibilität kontrolliert werden kann.
Viele Apple-Geräte unterstützen HEVC sehr gut. In Browsern und externen Anwendungen unterscheidet sich die Unterstützung jedoch je nach Betriebssystem und installierten Decoderkomponenten. Auch die Lizenzierung spielt eine Rolle.
HEVC kann eine ausgezeichnete Wahl sein. Ich würde es aber nicht automatisch als einziges Downloadformat für eine allgemeine Website einsetzen.
VP9: eine praktische offene Alternative
VP9 bietet gute Komprimierung und breite Unterstützung durch moderne Browser. Wenn Videos ausschließlich im Browser bleiben und die Wiedergabeumgebung vorhersehbar ist, ist der Codec eine überzeugende Option.
Für meinen Einsatzzweck lag der größte Nachteil in der Unsicherheit beim Herunterladen und Öffnen in nativen Anwendungen, die WebM oder VP9 möglicherweise nicht durchgängig unterstützen.
AV1: ausgezeichnete Effizienz, aber noch keine universelle Hardwareunterstützung
AV1 gehört zu den vielversprechendsten modernen Videocodecs. Gegenüber älteren Codecs kann er erhebliche Bitrateneinsparungen erzielen, und die Unterstützung für Hardwaredekodierung nimmt weiter zu.
Älteren Geräten fehlt jedoch möglicherweise ein AV1-Decoder, sodass eine Softwaredekodierung nötig wird. Bei hoher Auflösung kann diese deutlich mehr CPU-Leistung und Akkustrom benötigen und auf schwächeren Geräten Wiedergabeprobleme verursachen.
Wenn Sie die Wiedergabeumgebung kontrollieren können, sollten Sie AV1 ernsthaft in Betracht ziehen. Muss dagegen eine einzige Datei auf alten und neuen Geräten sowie in gewöhnlichen externen Videoplayern funktionieren, bleibt H.264 die sicherere Standardwahl.
Der MDN-Leitfaden zu Videocodecs bietet hilfreiche Details zu diesen Codecs und ihren Anforderungen an Browser.
4. Ein Videoformat oder mehrere Varianten?
Das ist eine der wichtigsten Architekturentscheidungen bei der Videobereitstellung.
Wenn mehrere Varianten möglich sind, kann eine Website AV1 oder VP9 für kompatible Geräte anbieten und in anderen Umgebungen auf H.264 zurückgreifen. So lässt sich die Komprimierung verbessern, ohne eine breite Abspielbarkeit aufzugeben.
Mehrere Varianten bedeuten allerdings auch zusätzlichen Aufwand für Kodierung, Speicherung, Caching, Validierung und die Auswahl des passenden Formats bei der Wiedergabe.
Wenn Sie pro Ausgangsvideo genau eine fertige Videodatei benötigen, ist es oft sinnvoller, zuerst auf Kompatibilität zu achten.
Ich habe MP4/H.264 gewählt, weil ich eine einzelne Datei wollte, die in den großen Browsern, auf Smartphones und beim üblichen Herunterladen und Abspielen funktioniert, ohne alternative Formate vorauszusetzen.
Damit behaupte ich nicht, dass MP4/H.264 die beste Komprimierung bietet. Ich gewichte lediglich die vorhersehbare Wiedergabe höher als den möglichen Größenvorteil eines neueren Codecs.
5. Warum mobile Videos andere Prioritäten haben
Die Videokomprimierung sollte sich danach richten, wie die Inhalte tatsächlich genutzt werden.
Ein kurzer Clip, der überwiegend auf einem Smartphone angesehen wird, stellt andere Anforderungen als ein Spielfilm auf einem großen Fernseher. Im ersten Fall können schnelles Laden und geringer mobiler Datenverbrauch wichtiger sein als feinste Bilddetails. Im zweiten Fall steht möglicherweise die Bildqualität an erster Stelle.
Bei kurzen Videos für Mobilgeräte bieten kleinere Dateien mehrere Vorteile:
- Vor dem Abspielen müssen weniger Daten übertragen werden.
- Bei eingeschränkter Verbindung können Downloads schneller abgeschlossen werden.
- Auf dem Gerät wird weniger Speicherplatz benötigt.
- Nutzer verbrauchen weniger mobiles Datenvolumen.
- Bei niedrigerer kodierter Bitrate kann die Wiedergabe mit begrenzter Übertragungsrate besser zurechtkommen.
Allerdings garantiert eine kleinere Datei nicht, dass ein Video niemals puffern oder stocken wird. Auch schwankende Netzqualität, Bitratenspitzen, Serververhalten, Wiedergabepuffer und die Dekodierleistung des Geräts spielen eine Rolle.
Die mobile Kompatibilität hängt von mehr als der Dateiendung ab: Hardwaredekodierung, Codec-Profil und -Level, Bittiefe, Chroma-Subsampling, Auflösung, Bildrate und Spitzenbitrate sind ebenfalls wichtig. Ein Video, das mit 390 CSS-Pixeln Breite dargestellt wird, kann auf einem hochauflösenden Smartphone-Display erheblich mehr physische Pixel einnehmen. Ein auf 390 Pixel verkleinertes Einzelbild zu betrachten, entspricht daher nicht unbedingt der Anzeige des Originalvideos auf diesem Smartphone. Testen Sie auf echten Geräten unter realistischen Wiedergabebedingungen.
CRF steuert die Qualität, setzt aber keine exakte Obergrenze für die Bitrate. Selbst eine insgesamt relativ kleine Datei kann bei komplexen Videoinhalten hohe Bitratenspitzen aufweisen. Wenn die zuverlässige Wiedergabe über besonders langsame Verbindungen entscheidend ist, sollten Sie explizite Bitraten- oder VBV-Grenzen, geeignete Auflösungsbeschränkungen und Tests unter realistischen Netzbedingungen in Betracht ziehen.
Das Grundprinzip ist einfach: Optimieren Sie für das gewünschte Seherlebnis, nicht für einen abstrakten Anspruch auf maximale Qualität.
6. x264 und CRF verstehen: niedriger bedeutet höhere Qualität, höher bedeutet kleinere Dateien
Nach der Entscheidung für H.264 stellt sich die Frage, wie stark das Video komprimiert werden soll.
Bei x264 bestimmt der Constant Rate Factor, kurz CRF, den Kompromiss zwischen erhaltenen Bilddetails und Dateigröße.
Ein niedrigerer CRF liefert im Allgemeinen hochwertigere, größere Dateien. Ein höherer CRF führt meist zu kleineren Dateien mit stärkeren Komprimierungsverlusten.
CRF legt weder eine genaue Bitrate noch eine feste Ausgabegröße fest. Der Encoder verteilt die Bits abhängig vom Ausgangsmaterial. Deshalb können eine einfache und eine äußerst detailreiche Szene bei identischem CRF sehr unterschiedlich große Dateien ergeben.
Auch die grundlegende Decoderkompatibilität wird nicht durch CRF festgelegt. Zwei korrekt kodierte H.264-Videos mit CRF 22 beziehungsweise CRF 30 können denselben Codec, dasselbe Profil, Level, Pixelformat, dieselben Abmessungen und dieselbe Bildrate aufweisen.
Der Unterschied liegt vor allem in der Komprimierungsqualität und den Bitrateneigenschaften.
Wichtig ist außerdem: CRF-Werte sind zwischen unterschiedlichen Codec-Implementierungen nicht direkt vergleichbar. CRF 30 bei x264 entspricht nicht derselben Bildqualität wie CRF 30 bei einem AV1-Encoder.
7. Mein praktischer Komprimierungsversuch: CRF 22 bis 32
Ich wollte herausfinden, wie stark sich ein Video komprimieren lässt, bevor die Unterschiede bei normaler Wiedergabe relevant werden.
Als Ausgangsmaterial diente ein kurzes, bereits komprimiertes Video. Daraus erzeugte ich H.264-Vergleichsdateien mit CRF 22, 24, 26, 28, 29, 30, 31 und 32.
Wichtige Videoeigenschaften blieben erhalten, darunter Auflösung, Bildrate, Laufzeit und Anzahl der Einzelbilder. Auch die Encoder-Einstellungen waren konsistent, sodass sich die Auswirkungen des geänderten CRF-Werts beurteilen ließen.
Die Dateigrößen unterschieden sich deutlich.
| CRF | Ungefähre Größe im Verhältnis zum Original | Bedeutung |
|---|---|---|
| 22 | 63% | Zurückhaltendere Komprimierung mit besserem Detailerhalt |
| 24 | 49% | Kleinere Datei bei moderatem zusätzlichem Qualitätsverlust |
| 26 | 38% | Weitere Einsparungen bei weiterhin vielen erhaltenen Details |
| 28 | 30% | Kompakte Ausgabe mit vergleichsweise hoher Ähnlichkeit zum Ausgangsmaterial |
| 29 | 26% | Stärkere Komprimierung |
| 30 | 23% | Mein bevorzugter Kompromiss für das getestete Material |
| 31 | 21% | Weitere Einsparungen bei geringerer Bildtreue |
| 32 | 19% | Kleinste getestete Datei und größter gemessener Qualitätsverlust |
Diese Prozentwerte beziehen sich auf die getestete Quelldatei und dürfen nicht als typische Einsparungen für beliebige Videos verstanden werden. Die Tabellenwerte wurden jeweils separat gerundet. Für genaue relative Einsparungen sollten Sie die zugrunde liegenden Dateigrößen verwenden, statt die gerundeten Prozentzahlen durcheinander zu dividieren.
Am meisten überraschte mich, dass ich zwischen CRF 22 und CRF 30 bei normaler Wiedergabe keinen nennenswerten Bildunterschied erkennen konnte, selbst auf einem großen Desktop-Monitor.
Ich habe mir auch stärker komprimierte Varianten bis hin zu CRF 32 angesehen, ohne beim normalen Abspielen dieses konkreten Clips einen deutlichen Unterschied festzustellen.
Diese Beobachtung war für mich wichtig, weil die Videos vor allem für kleinere Smartphone-Displays gedacht waren. Wenn mich die Qualitätsminderung auf meinem Desktop-Monitor nicht störte, sah ich wenig Grund, für zusätzliche Details, die das beabsichtigte Seherlebnis nicht verbesserten, erheblich größere Dateien in Kauf zu nehmen.
Allerdings war das eine subjektive Beobachtung an einer bestimmten Art von Ausgangsmaterial. Daraus folgt nicht, dass alle Nutzer, Smartphones oder Videos dieselben Ergebnisse liefern. Displays mit hoher Pixeldichte und geringe Betrachtungsabstände können Artefakte sichtbar machen, insbesondere in feinen Details oder Farbverläufen.
8. Objektive Messungen bestätigten den tatsächlichen Qualitätsverlust
Dass man bei der Wiedergabe keinen Unterschied sieht, bedeutet nicht, dass zwei Videos mathematisch identisch sind.
Ich habe die kodierten Dateien auch anhand objektiver Bildqualitätsmetriken verglichen. Mit steigendem CRF nahm ihre Ähnlichkeit zum Ausgangsmaterial ab.
Für einen einheitlich herunterskalierten Vergleich, der die Darstellung auf einem hochauflösenden Smartphone annähern sollte, ergaben sich beispielhaft folgende SSIM-Werte:
| CRF | Ungefährer SSIM-Wert | Dateigröße im Verhältnis zu CRF 28 |
|---|---|---|
| 22 | 0.9934 | 2.13× |
| 28 | 0.9869 | 1.00× |
| 30 | 0.9837 | 0.79× |
| 32 | 0.9795 | 0.63× |
Der Trend ist eindeutig: Stärkere Komprimierung senkte die gemessene Bildtreue. Bei genauer Betrachtung zeigten sich außerdem feine Unterschiede an Linien und Texturen.
Bei normaler Wiedergabe blieb der Bildeindruck des getesteten Videos dennoch sehr ähnlich. Genau deshalb sollte man objektive Messwerte und subjektive Beurteilung gemeinsam nutzen.
SSIM misst Bildähnlichkeit, nicht das gesamte menschliche Seherlebnis. Zeitliche Artefakte, wahrgenommene Schärfe, Bewegungsdarstellung und die subjektive Bedeutung einzelner Details werden damit nicht vollständig erfasst.
Eine weitere nützliche Metrik für die wahrgenommene Qualität ist VMAF. Netflix veröffentlichte im Juni 2026 die VMAF-v1-Modelle, darunter ein Modell für die Betrachtung auf Smartphones. Diese Modelle berücksichtigen ausdrücklich, dass die wahrgenommene Qualität unter anderem von der Bildschirmgröße und dem relativen Betrachtungsabstand abhängt.
Eine konservativ kodierte Testdatei erreichte in der Untersuchung einen berichteten mittleren VMAF-Wert von ungefähr 95. Für die aggressiveren CRF-Einstellungen lag jedoch keine durchgehende VMAF-Messreihe vor. Daher habe ich anhand von VMAF nicht behauptet, CRF 30 oder 32 erreiche einen allgemeingültigen Qualitätsgrenzwert.
Das praktische Fazit ist enger gefasst: Das getestete kurze Video vertrug bei normaler Wiedergabe eine sehr starke H.264-Komprimierung ausgesprochen gut.
9. Warum ich für kurze mobile Videos CRF 30 gewählt habe
Nach dem Vergleich der Dateien entschied ich mich für CRF 30 bei ähnlichen kurzen Videos, die überwiegend auf Mobilgeräten angesehen werden.
Die Gründe waren einfach:
- Die Videos waren kurz und sollten keine Bildqualität auf Kinoniveau bieten.
- Schnelles Laden und kleinere Downloads waren wichtig.
- Zwischen CRF 22 und 30 sah ich auf einem großen Desktop-Monitor keinen nennenswerten Unterschied.
- CRF 30 erzeugte deutlich kleinere Dateien als konservativere Einstellungen.
- Auch CRF 32 wirkte beim getesteten Beispiel visuell akzeptabel, bot aber weniger Sicherheit für komplexeres Material.
Gegenüber CRF 28 verringerte CRF 30 die Größe der getesteten Ausgabedatei um ungefähr 21 %. Gegenüber CRF 22 lag die Einsparung bei mehr als 60 %.
Für kurze mobile Clips, bei denen ein ansprechendes Bild, schnelles Laden und ein vernünftiger Bandbreitenverbrauch zählen, war das ein lohnender Kompromiss.
Die Einschränkung ist jedoch entscheidend: Ich habe CRF 30 wegen des tatsächlichen Einsatzzwecks und der Ergebnisse mit dem getesteten Material gewählt – nicht, weil 30 grundsätzlich der beste CRF-Wert für Smartphones wäre.
Ein Smartphone benötigt nicht CRF 30. Es kann auch deutlich hochwertiger kodierte Videos problemlos anzeigen. CRF 30 ist eine bewusste Entscheidung, etwas Bildtreue gegen kleinere Dateien einzutauschen, sofern dieser Kompromiss akzeptabel ist.
Bevor ich diese Einstellung auf eine Sammlung mit sehr unterschiedlichen Inhalten übertragen würde, würde ich mehrere repräsentative Clips testen, darunter schwierige Bewegungen, dunkle Szenen, Farbverläufe, Text und feine Texturen.
10. Warum ich CRF 30 nicht für Filme oder hochwertige Videos empfehle
Das ist die wichtigste Einschränkung meines Experiments.
Übertragen Sie mein Ergebnis mit CRF 30 nicht ungeprüft auf Spielfilme, hochwertige Videoinhalte, professionelle Aufnahmen oder Videos für große Bildschirme.
Solche Inhalte können feine Farbverläufe, Filmkorn, schwach beleuchtete Szenen, komplexe Bewegungen, detailreiche Oberflächen und sorgfältig abgestimmte Farben enthalten. Diese Details zu erhalten, kann wichtiger sein, als vergleichsweise wenig Bandbreite einzusparen.
Bei gewöhnlichen hochwertigen 1080p-Videos würde ich mit einer deutlich konservativeren x264-Einstellung, etwa CRF 20, beginnen und je nach Material auch höhere und niedrigere Werte prüfen.
Wenn Bildtreue wichtig ist, könnte CRF 18–22 ein sinnvoller Ausgangsbereich sein. Der passende Wert kann je nach Auflösung, Inhalt und Anforderungen jedoch auch außerhalb davon liegen.
Dieser Vorschlag stimmt mit verbreiteten Empfehlungen zur Videokodierung überein. Beispielsweise empfiehlt die HandBrake-Dokumentation zur Qualitätseinstellung für viele 1080p-Anwendungen mit x264 ungefähr RF 20–24.
Ich habe keine entsprechende kontrollierte Untersuchung mit Spielfilmen oder hochwertigem Kinomaterial durchgeführt. Deshalb kann ich weder behaupten, dass CRF 20 grundsätzlich optimal ist, noch dass CRF 22 immer ausreicht oder ein bestimmter Film mit CRF 30 zwangsläufig schlecht aussehen würde.
Die richtige Vorgehensweise besteht darin, repräsentative Szenen auszuwählen, mehrere Qualitätsstufen zu kodieren, sie auf dem vorgesehenen Bildschirm zu vergleichen und herauszufinden, ab wann zusätzliche Komprimierung sichtbar schadet.
Soll das Video archiviert, später erneut bearbeitet oder als Quelle weiterer Kodierungen verwendet werden, sollte neben der komprimierten Auslieferungsdatei eine hochwertige Masterdatei aufbewahrt werden.
11. Warum ich das x264-Preset veryslow verwendet habe
CRF steuert einen Aspekt der Komprimierungsqualität. Das x264-Preset bestimmt dagegen, wie viel Rechenaufwand der Encoder bei der Suche nach effizienten Kodierungsentscheidungen betreibt.
x264 bietet Presets von sehr schnell bis sehr langsam. Langsamere Presets benötigen im Allgemeinen mehr CPU-Zeit, können bei vergleichbarer Bildqualität aber effizienter komprimieren.
Ich habe medium und veryslow mit demselben Ausgangsvideo verglichen. Bei der getesteten Qualitätseinstellung erzeugte veryslow eine kleinere Datei.
Wenn ein Video einmal offline kodiert und danach häufig wiederverwendet wird, kann sich die zusätzliche Rechenzeit lohnen.
Deshalb habe ich -preset veryslow gewählt.
Universell optimal ist es allerdings nicht. Müssen Videos sofort verarbeitet werden, ist CPU-Leistung teuer oder wartet ein enormer Rückstau auf Verarbeitung, können slow oder medium betrieblich die bessere Balance bieten.
Das Preset beeinflusst vor allem den Rechenaufwand beim Kodieren und die Komprimierungseffizienz. Es macht aus H.264 keinen anderen Codec und sorgt nicht von sich aus für eine Inkompatibilität mit Mobilgeräten.
12. Bei Anime-Videos verwende ich die Animation-Optimierung von x264
Bei gezeichneten Animationen oder Bildern im Anime-Stil verwende ich mit x264 -tune animation.
Diese Einstellung ist vom CRF-Wert zu unterscheiden. Ein Tune verändert bestimmte Entscheidungen des Encoders passend zu besonderen Bildeigenschaften. Die Animation-Optimierung ist für gezeichnete Konturen, einfarbige Flächen und stilisierte Bewegungen gedacht.
Ich bevorzuge daher folgende Einstellungen:
- Anime oder gezeichnete Animationen:
-preset veryslow -tune animation. - Gewöhnliche Realfilmaufnahmen: Die Animation-Optimierung nicht automatisch einschalten; zunächst die Encoder-Standardeinstellungen verwenden oder einen passenden Tune gesondert testen.
Die Wirkung eines Tunes darf man nicht falsch verstehen. -tune animation garantiert weder sichtbar bessere Qualität noch kleinere Dateien. Die Einstellung verändert das Verhalten des Encoders; das Ergebnis hängt vom Material ab.
Ich habe die Animation-Optimierung in einem separaten Vergleich bei festem CRF getestet. In genau diesem Vergleich wurde die Datei mit aktiviertem Tune ungefähr 6 % größer, während sich die gemessene Bildähnlichkeit leicht verbesserte. Visuell war der Unterschied gering.
Der Hauptvergleich der Dateigrößen bei CRF 22–32 erfolgte ohne Animation-Tune. Daher sollte man nicht davon ausgehen, dass die dort ermittelten Größen und Komprimierungsverhältnisse mit aktiviertem -tune animation exakt gleich bleiben.
Für Anime-Material bevorzuge ich trotzdem diese spezielle Optimierung und bewerte die resultierende Größe und Qualität als Teil des jeweiligen Kodierprofils.
Encoder-Tuning ist stets eine materialabhängige Anpassung und keine allgemeingültige Qualitätsverbesserung.
13. Meine empfohlenen FFmpeg-Einstellungen für kurze Anime-Videos auf Mobilgeräten
Für ein gewöhnliches SDR-Anime-Video, das tatsächlich neu kodiert werden muss, würde ich folgenden Befehl als Ausgangspunkt verwenden:
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset veryslow \
-tune animation \
-crf 30 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 128k \
-movflags +faststart \
output.mp4Der Befehl legt die wichtigsten Entscheidungen ausdrücklich fest:
-c:v libx264verwendet den H.264-Softwareencoder.-preset veryslowgibt der Komprimierungseffizienz Vorrang vor der Kodiergeschwindigkeit.-tune animationaktiviert Anpassungen für animiertes Bildmaterial.-crf 30setzt das für diese Art kurzer Videos gewählte aggressive Ziel konstanter Qualität.-profile:v highwählt ein von modernen Geräten häufig unterstütztes H.264-Profil.-pix_fmt yuv420perzeugt 8-Bit-Video mit 4:2:0-Chroma-Subsampling.-map 0:v:0wählt den ersten Videostream.-map '0:a:0?'wählt optional den ersten Audiostream.-c:a aac -b:a 128kkodiert vorhandenes Audio als übliches AAC mit der angegebenen Bitrate.-movflags +faststartverschiebt die Initialisierungsmetadaten der MP4-Datei an deren Anfang.
Das ist ein Beispiel, kein universeller Befehl für jedes Ausgangsmaterial. Die jeweiligen Quelldateien können zusätzliche Verarbeitung erfordern.
Insbesondere HDR- und 10-Bit-Material sollte ohne geeignetes Farbmanagement nicht einfach in 8-Bit-SDR umgewandelt werden. Andernfalls drohen falsche Farben, verlorene Details in hellen Bildbereichen oder sichtbare Abstufungen in Farbverläufen. Auch Rotationsmetadaten, variable Bildraten, Pixel-Seitenverhältnisse, Zeilensprungmaterial, ungewöhnliche Audiokanalbelegungen und nicht unterstützte Auflösungen müssen berücksichtigt werden.
Wenn Bildrate und Abmessungen der Quelle bereits passen, vereinfacht es Vergleiche und vermeidet unnötige Größen- oder Bewegungsänderungen, sie beizubehalten. Eine variable Bildrate sollte nur bei Bedarf erzwungen in eine konstante umgewandelt werden: Dabei können Frames verdoppelt oder verworfen werden. Beim Skalieren sind das Anzeige-Seitenverhältnis und mit dem gewählten 4:2:0-Pixelformat kompatible Abmessungen zu beachten. Sehr hohe Auflösungen, Bildraten oder H.264-Level können die Dekodiergrenzen älterer Geräte überschreiten. Für Kompatibilität muss man deshalb manchmal bewusst die Auflösung oder Bildrate senken.
14. Ein konservativerer FFmpeg-Ausgangspunkt für hochwertige Videos
Wenn die Bildtreue wesentlich wichtiger ist als die Dateigröße, beginnen Sie mit einem niedrigeren CRF-Wert und prüfen Sie das Ergebnis.
Für herkömmliche SDR-Realfilmaufnahmen ist der folgende Befehl beispielsweise ein vernünftiger experimenteller Ausgangspunkt:
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset slow \
-crf 20 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 192k \
-movflags +faststart \
output.mp4Das Preset slow dient hier als praxistauglicher allgemeiner Ausgangspunkt; damit behaupte ich nicht, dass es veryslow übertrifft. Wenn zusätzliche Kodierzeit akzeptabel ist, kann auch veryslow sinnvoll sein.
Dieses Profil für hohe Qualität ist eine Einstellung zum Ausprobieren, keine durch meinen Kurzvideoversuch bestätigte Konfiguration.
Testen Sie für besonders hochwertige Videos etwa CRF 18, 20 und 22 und entscheiden Sie anhand der sichtbaren Ergebnisse. Schwieriges Filmkorn oder komplexe Bewegungen können andere Werte erfordern; für Archivmaster kann eine deutlich geringere Komprimierung angebracht sein.
15. Videos nicht ohne Grund erneut kodieren
Verlustbehaftete Videokomprimierung hat ihren Preis. Bereits komprimierte Dateien erneut zu kodieren, kann zusätzliche Artefakte erzeugen, selbst wenn die Ausgabe dem Ausgangsmaterial ähnlich erscheint.
Prüfen Sie vor einer Neukodierung, ob die vorhandene Datei nicht bereits Ihre Anforderungen an Kompatibilität, Größe und Qualität erfüllt.
Enthält sie bereits kompatibles H.264-Video und AAC-Audio und sind keine Bildänderungen nötig, kann das direkte Kopieren der Streams besser sein als eine weitere verlustbehaftete Kodierung.
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c copy \
-movflags +faststart \
output.mp4Bei diesem Vorgang werden die komprimierten Streams ohne erneute Kodierung kopiert. Die Anordnung im Container kann sich ändern, ohne dass eine weitere Generation von Komprimierungsverlusten entsteht.
Dadurch ergeben sich normalerweise nicht dieselben Größenersparnisse wie durch eine Neukodierung mit niedrigerer Qualität.
Ist das vorhandene Video bereits kompakt, kompatibel und visuell zufriedenstellend, ist es womöglich die beste Optimierung, es unverändert zu lassen.
16. Kodierte Videos prüfen statt nur auf die Dateigröße zu vertrauen
Ein erfolgreicher FFmpeg-Exitcode beweist nicht automatisch, dass ein Video alle Anforderungen erfüllt.
Untersuchen Sie zunächst die Ausgabestreams mit FFprobe:
ffprobe -v error \
-show_entries stream=codec_name,profile,pix_fmt,width,height,avg_frame_rate,nb_frames:format=duration,size \
-of json output.mp4Überprüfen Sie Codec, Pixelformat, Abmessungen, Bildrate, Laufzeit und Audiostreams.
Dekodieren Sie danach die gesamte Ausgabe, um bestimmte Beschädigungen oder Dekodierfehler zu erkennen:
ffmpeg -v error -xerror -i output.mp4 -f null -Bei Komprimierungsversuchen sollten Sie Dateien vergleichen, die aus demselben Ausgangsmaterial entstanden sind. Halten Sie die wichtigen Variablen konstant und verändern Sie jeweils nur eine wesentliche Einstellung.
Sehen Sie sich das Ergebnis in Bewegung an, untersuchen Sie feine Details und achten Sie auf Farbverläufe, dunkle Bildbereiche, bewegte Objekte und Text.
Ergänzen Sie visuelle Vergleiche nach Möglichkeit um objektive Metriken wie SSIM, PSNR oder VMAF. Ein einzelner hoher Wert beweist nicht, dass sämtliche Artefakte unsichtbar sind.
Testen Sie das Video abschließend auf repräsentativen Geräten und auch nach dem Herunterladen. Angaben zur Browserunterstützung sind hilfreich, doch wenn Kompatibilität im Vordergrund steht, sind echte Wiedergabetests besonders wichtig.
17. MP4-Dateien richtig ausliefern
Gute Kodierungseinstellungen können eine schlechte Auslieferung über das Web nicht ausgleichen.
Für die normale progressive MP4-Wiedergabe sollte der Header Content-Type: video/mp4 korrekt gesetzt sein. Unterstützen Sie außerdem HTTP-Byte-Range-Anfragen, wenn Teilabrufe und das Springen innerhalb des Videos erforderlich sind.
Die FFmpeg-Option +faststart verschiebt die Initialisierungsinformationen einer gewöhnlichen MP4-Datei nach vorn. Das erleichtert progressives Laden, verbessert aber weder die Bildqualität noch verringert es die Bitrate.
Ein einfaches HTML-Videoelement kann eine einzelne H.264-MP4-Datei einbinden:
<video controls playsinline preload="metadata">
<source src="/media/video.mp4" type="video/mp4">
</video>Das Attribut preload ist für den Browser ein Hinweis, keine strikte Obergrenze für Downloads. Je nach Autoplay-Regeln des Browsers muss ein Video außerdem stummgeschaltet sein oder keine Tonspur enthalten.
Wenn eine Seite mehrere Videos enthält, sollten nicht alle sofort heruntergeladen werden. Laden Sie sie erst bei Bedarf, um mobilen Datenverbrauch zu sparen und die wahrgenommene Reaktionsgeschwindigkeit zu verbessern.
Bei kurzen mobilen Clips kann eine kluge Downloadplanung ebenso wichtig sein wie eine kleinere kodierte Datei.
18. Welches Videoformat und welche Qualität sollten Sie wählen?
Die richtige Antwort hängt davon ab, was Sie optimieren möchten.
| Ihr Ziel | Empfohlener Ausgangspunkt |
|---|---|
| Eine breit kompatible Web- und Download-Datei | MP4 + H.264 + AAC, sofern Audio vorhanden ist |
| Moderne Browser mit mehreren Formatvarianten | AV1 oder VP9 mit H.264 als Fallback |
| Maximale Komprimierung auf unterstützten Geräten | AV1 testen |
| Kontrollierte HEVC-kompatible Wiedergabeumgebung | MP4 + HEVC in Betracht ziehen |
| Kurze mobile Clips, bei denen die Dateigröße entscheidend ist | x264 CRF 30 nach repräsentativen Tests erwägen |
| Anime oder gezeichnete Animation | x264 mit -tune animation testen |
| Hochwertige Filme oder Premiumvideos | Mit einem konservativeren CRF um 20 beginnen und testen |
| Offline-Kodierung, bei der CPU-Zeit weniger wichtig ist | x264 slow oder veryslow erwägen |
| Schnelle Verarbeitung bei begrenzter CPU-Leistung | x264 medium oder slow erwägen |
| Vorhandenes Video erfüllt bereits alle Anforderungen | Behalten oder ohne Neukodierung neu verpacken |
| Archivierung oder spätere Bearbeitung | Hochwertige Masterdatei getrennt von Auslieferungsdateien aufbewahren |
19. Meine endgültige Entscheidung und was das Experiment tatsächlich gezeigt hat
Nach der Untersuchung von Videoformaten, Kompatibilität, Kodierungseffizienz und realen Komprimierungsergebnissen habe ich ein praxistaugliches Auslieferungsprofil für kurze mobile Videos gewählt.
Als Format habe ich MP4 mit H.264 gewählt, weil mir die vorhersehbare Kompatibilität mit Browsern, Smartphones, Downloads und externen Anwendungen wichtiger war als die kleinstmögliche Datei mit einem neueren Codec.
Als Encoder habe ich libx264 mit dem Preset veryslow gewählt, weil die Videos offline kodiert werden konnten und die zusätzliche Rechenzeit akzeptabel war.
Für Anime-Videos nutze ich den Animation-Tune, wohl wissend, dass er das Encoderverhalten verändert, aber weder kleinere Dateien noch grundsätzlich bessere Bilder garantiert.
Für kurze mobile Videos habe ich CRF 30 gewählt, weil mein Vergleich eine erhebliche Verringerung der Dateigröße zeigte, ohne dass bei normaler Wiedergabe ein nennenswerter visueller Unterschied auffiel – selbst auf einem großen Desktop-Monitor.
Das bedeutet nicht, dass CRF 30 ideal für Filme oder hochwertige Aufnahmen ist. Wenn feine Details, Farbverläufe, Filmkorn und die allgemeine Bildtreue wichtiger sind, würde ich Tests bei etwa CRF 20 oder einem anderen angemessen konservativen Wert beginnen. Da ich kein entsprechendes kontrolliertes Experiment mit Kinomaterial durchgeführt habe, stelle ich diesen Wert nicht als experimentell bestätigtes Optimum dar.
Die wichtigste Erkenntnis lautet: Es gibt keinen Codec, kein Format und keinen CRF-Wert, der für alle Videos gleichermaßen optimal ist.
Wenn maximale Kompatibilität im Vordergrund steht und Sie nur eine Datei möchten, ist MP4/H.264 ein guter Standard. Können Sie alternative Formate als Fallback bereitstellen und wünschen eine bessere Komprimierung, sollten Sie VP9 und AV1 prüfen. Bei kurzen Videos, die hauptsächlich auf Smartphones angesehen werden, testen Sie, ob ein höherer CRF ausreichend kleine Dateien ergibt, ohne das gewünschte Seherlebnis zu beeinträchtigen. Bei Filmen oder hochwertigen Aufnahmen sollten Sie konservativere Qualitätswerte verwenden und diese sorgfältig überprüfen.
Bestimmen Sie zuerst die Anforderungen an die Wiedergabe, wählen Sie dann den Codec und zuletzt die Komprimierungsqualität. Prüfen Sie das Ergebnis anschließend auf den tatsächlich relevanten Geräten und unter realistischen Bedingungen. Das ist zuverlässiger, als einen Codec oder CRF-Wert ungeprüft zu übernehmen, nur weil er neuer, effizienter oder häufig empfohlen ist.