Eine Videodatei heißt:

interview.mp4

Auf den ersten Blick scheint die Sache eindeutig zu sein:

Das Video ist ein MP4.

Technisch beantwortet diese Dateiendung allerdings nur einen Teil der Frage.

Denn in einer Videodatei stecken mehrere unterschiedliche Ebenen.

Zum Beispiel:

Videobild
+
Ton
+
Untertitel
+
Zeitinformationen
+
Metadaten

Diese Bestandteile werden in einem Container zusammengefasst.

Das eigentliche Videobild innerhalb des Containers kann wiederum mit einem bestimmten Codec komprimiert sein.

Vereinfacht:

MP4-Datei
├── Videospur: H.264
├── Audiospur: AAC
├── Untertitel
└── Metadaten

Eine andere MP4-Datei könnte dagegen enthalten:

MP4-Datei
├── Videospur: H.265
├── Audiospur: AAC
└── Metadaten

Beide Dateien enden auf .mp4.

Der Videocodec ist trotzdem unterschiedlich.

Genau deshalb muss man Container und Codec getrennt verstehen.

Der Container ist die Verpackung

Ein Container ist zunächst eine Struktur, in der verschiedene Medienströme gemeinsam gespeichert werden können.

Man kann ihn sich wie eine Schachtel vorstellen:

Container
┌────────────────────────┐
│ Video                  │
│ Audio                  │
│ Untertitel             │
│ Kapitel                │
│ Metadaten              │
└────────────────────────┘

Der Container sorgt unter anderem dafür, dass ein Player weiß:

Welche Videospur gehört zur Datei?

Welche Audiospur?

Wann beginnt sie?

Welche Untertitel gehören dazu?

Wie lang ist das Video?

Der Codec bestimmt, wie Videodaten gespeichert werden

Das Wort Codec setzt sich gedanklich aus zwei Funktionen zusammen:

Coder
+
Decoder

beziehungsweise:

Encoder
+
Decoder

Beim Erstellen eines Videos werden Rohdaten kodiert.

Videoframes
↓
Encoder
↓
komprimierter Videostream

Beim Abspielen geschieht das Gegenteil.

komprimierter Videostream
↓
Decoder
↓
darstellbare Frames

Der Codec definiert Regeln dafür, wie diese Kompression und Rekonstruktion funktioniert.

Warum muss Video überhaupt komprimiert werden?

Ein einzelnes Foto kann bereits mehrere Megabyte groß sein.

Ein Video enthält dagegen jede Sekunde:

24,

25,

30,

50,

60

oder noch mehr Einzelbilder.

Nehmen wir beispielsweise UHD-4K:

3840 × 2160 Pixel

Das sind ungefähr:

8,3 Millionen Pixel

pro Frame.

Bei:

30 fps

müssen pro Sekunde etwa:

8,3 Millionen
×
30
≈
249 Millionen Pixelpositionen

beschrieben werden.

Und jeder Pixel benötigt wiederum Farbinformationen.

Unkomprimierte Videodaten wären daher enorm groß.

Ein einfaches Gedankenexperiment

Angenommen, jeder Pixel würde nur drei Bytes benötigen:

Rot
Grün
Blau
=
3 Bytes

Dann hätte ein unkomprimierter 4K-Frame ungefähr:

3840 × 2160 × 3
≈
24,9 MB

Bei 30 Frames pro Sekunde:

24,9 MB × 30
≈
747 MB pro Sekunde

Eine Minute läge bereits bei grob:

44 GB

Dabei ignoriert diese vereinfachte Rechnung noch viele reale technische Details.

Sie zeigt aber das grundlegende Problem:

Video braucht Kompression.

Warum lässt sich Video so stark komprimieren?

Weil Videos sehr viele wiederkehrende Informationen enthalten.

Stell dir ein Interview vor.

Im Hintergrund befindet sich eine weiße Wand.

Frame 1:

Person vor Wand

Frame 2:

Person vor fast derselben Wand

Frame 3:

Person vor fast derselben Wand

Die Wand muss nicht in jedem Frame vollständig neu beschrieben werden.

Zeitliche Redundanz

Viele Videocodecs nutzen aus, dass aufeinanderfolgende Frames einander ähneln.

Statt immer wieder zu speichern:

gesamte Wand
+
gesamte Person
+
gesamter Raum

kann vereinfacht gespeichert werden:

Bild ist fast wie vorher
+
Mund hat sich bewegt
+
Kopf etwas nach rechts

Diese zeitliche Ähnlichkeit ist einer der wichtigsten Gründe, warum Videokompression so effizient sein kann.

Räumliche Redundanz

Auch innerhalb eines einzelnen Frames existieren viele ähnliche Bereiche.

Ein blauer Himmel besteht vielleicht aus Millionen Pixeln mit sehr ähnlichen Farbwerten.

blau blau blau blau
blau blau blau blau
blau blau blau blau

Ein Codec muss diese Werte nicht zwingend völlig unabhängig voneinander speichern.

Auch innerhalb eines Frames kann daher stark komprimiert werden.

Videokompression arbeitet räumlich und zeitlich

Vereinfacht:

innerhalb eines Frames
→ räumliche Ähnlichkeit nutzen

und:

zwischen Frames
→ zeitliche Ähnlichkeit nutzen

Diese Kombination ermöglicht sehr kleine Dateien im Verhältnis zur ursprünglichen Datenmenge.

Verlustfreie und verlustbehaftete Kompression

Wie bei Bildformaten fürs Web muss zwischen zwei grundlegenden Prinzipien unterschieden werden.

Verlustfrei:

Originaldaten
↓
Kompression
↓
kleinere Datei
↓
vollständig rekonstruierbare Originaldaten

Verlustbehaftet:

Originaldaten
↓
Kompression
↓
bestimmte Informationen werden vereinfacht
↓
deutlich kleinere Datei

Die meisten normalen Videodistributionsformate arbeiten stark verlustbehaftet.

Warum ist verlustbehaftete Kompression sinnvoll?

Weil ein Video sonst sehr schnell gigantische Datenmengen erzeugen würde.

Der Encoder versucht deshalb, Informationen zu entfernen oder zu vereinfachen, die für den Betrachter möglichst wenig sichtbar sind.

Das Ziel lautet:

möglichst geringe Dateigröße
+
möglichst geringe sichtbare Qualitätsverluste

Nicht:

jedes ursprüngliche Bit erhalten

Kompression bedeutet immer einen Kompromiss

Mehr Kompression:

kleinere Datei
↓
größeres Risiko sichtbarer Artefakte

Weniger Kompression:

größere Datei
↓
mehr Bildinformation bleibt erhalten

Der ideale Punkt hängt vom Einsatzzweck ab.

Was ist H.264?

H.264 ist ein sehr verbreiteter Videokompressionsstandard.

Man begegnet dabei auch der Bezeichnung:

AVC, für Advanced Video Coding.

Vereinfacht kann man sich merken:

H.264
≈
AVC

Der Standard wird seit vielen Jahren für:

Webvideo,

Kameras,

Streaming,

Videodateien

verwendet.

Warum ist H.264 so erfolgreich?

Er bietet einen sehr brauchbaren Kompromiss aus:

Kompression,

Bildqualität,

Rechenaufwand,

breiter technischer Unterstützung.

Für viele normale Video-Workflows ist H.264 deshalb ein naheliegendes Austausch- beziehungsweise Auslieferungsformat.

H.264 ist kein Container

Eine Datei kann beispielsweise heißen:

video.mp4

und H.264 enthalten.

Aber:

MP4
≠
H.264

MP4 beschreibt die Verpackung.

H.264 beschreibt die Videokodierung.

H.264 kann auch in anderen Containern stecken

Abhängig vom konkreten System kann derselbe Videocodec in unterschiedlichen Containerformaten gespeichert werden.

Genau deshalb ist die Dateiendung allein keine vollständige technische Beschreibung.

Was ist H.265?

H.265 ist ein später entwickelter Videokompressionsstandard.

Er wird auch bezeichnet als:

HEVC, High Efficiency Video Coding.

Vereinfacht:

H.265
≈
HEVC

Das Ziel ist unter anderem, vergleichbare visuelle Qualität mit weniger Daten zu ermöglichen beziehungsweise bei ähnlicher Datenmenge höhere Qualität zu erreichen.

Warum braucht man effizientere Codecs?

Videoauflösungen und Bildraten steigen.

Aus:

1080p 25 fps

wird beispielsweise:

4K 50 fps

Wie im Artikel zu Videoauflösung und Bildrate erklärt, steigt damit die Informationsmenge enorm.

Effizientere Kompression hilft, diesen Datenzuwachs beherrschbar zu machen.

Höhere Effizienz hat einen Preis

Komplexere Kompression bedeutet typischerweise:

mehr Rechenaufwand beim Encoding,

mehr Anforderungen beim Decoding.

stärkere Kompressionseffizienz
↓
komplexere Berechnung

Ein kleineres Video kann beim Schnitt deshalb paradoxerweise anspruchsvoller sein als eine größere Datei mit einfacherem Aufbau.

Dateigröße und Rechenaufwand sind nicht dasselbe

Das ist eine der wichtigsten praktischen Erkenntnisse.

kleine Datei
≠
leicht zu bearbeiten

Ein stark komprimiertes Video benötigt beim Abspielen unter Umständen viele Berechnungen.

Ein weniger stark komprimiertes Schnittformat kann erheblich größer sein und trotzdem flüssiger bearbeitet werden.

Was ist AV1?

AV1 ist ein weiterer moderner Videocodec, der auf besonders effiziente Kompression für digitale Videoanwendungen abzielt.

Auch hier lautet die Grundidee:

hohe visuelle Qualität
+
möglichst geringe Datenrate

AV1 gehört damit in dieselbe grundlegende Problemklasse wie H.264 und H.265:

Wie lassen sich große Videodaten effizient speichern und übertragen?

Ein neuerer Codec ist nicht automatisch für jeden Workflow besser

Denn für praktische Nutzung sind mehrere Faktoren entscheidend:

Kompressionseffizienz
+
Encoding-Geschwindigkeit
+
Decoding-Leistung
+
Softwareunterstützung
+
Hardwareunterstützung
+
Zielplattform

Ein theoretisch effizienterer Codec kann unpraktisch sein, wenn die eingesetzte Produktions- oder Wiedergabekette ihn schlecht verarbeitet.

Codecwahl ist deshalb eine Systemfrage

Nicht:

Welcher Codec ist technisch der modernste?

Sondern:

Welcher Codec funktioniert
in meinem gesamten Workflow?

Encoder und Decoder

Ein Codecstandard beschreibt Regeln.

Der Encoder ist die konkrete Software beziehungsweise Hardware, die daraus einen komprimierten Stream erzeugt.

Frames
↓
H.264-Encoder
↓
H.264-Videostream

Der Decoder rekonstruiert das Material für die Wiedergabe.

H.264-Videostream
↓
H.264-Decoder
↓
Frames

Zwei Encoder können unterschiedliche Ergebnisse liefern

Auch wenn beide denselben Codec verwenden.

Warum?

Weil sie unterschiedliche Entscheidungen treffen können über:

Bewegungsanalyse,

Bitverteilung,

Qualitätsoptimierung,

Geschwindigkeit.

Deshalb bedeutet:

H.264

nicht automatisch:

immer exakt gleiche Bildqualität

Encoding braucht Zeit

Ein Encoder kann sehr schnell arbeiten.

Oder:

eine Szene intensiv analysieren.

Mehr Analyse kann bessere Kompressionsentscheidungen ermöglichen.

Deshalb gibt es häufig einen Zusammenhang zwischen:

Encoding-Geschwindigkeit
↔
Kompressionseffizienz

Ein langsamerer Export kann bei derselben Zielqualität kleinere beziehungsweise effizientere Dateien ermöglichen.

Echtzeitaufnahme braucht schnelle Entscheidungen

Eine Kamera nimmt gerade 4K mit 60 fps auf.

Sie kann nicht zehn Minuten überlegen, wie Frame 17 am effizientesten kodiert wird.

Die Daten müssen unmittelbar verarbeitet und auf die Speicherkarte geschrieben werden.

Offline-Encoding hat mehr Zeit

Beim späteren Webexport kann ein Rechner wesentlich länger analysieren.

fertiger Master
↓
langsame Analyse
↓
effizienter Webencode

Darum können Aufnahme- und Auslieferungsformate unterschiedliche Prioritäten haben.

Intra-Frame-Kompression

Eine Möglichkeit besteht darin, jeden Frame weitgehend für sich zu komprimieren.

Vereinfacht:

Frame 1
→ einzeln komprimiert

Frame 2
→ einzeln komprimiert

Frame 3
→ einzeln komprimiert

Man spricht konzeptionell von Intra-Frame-Kompression.

Vorteil für den Schnitt

Wenn Frame 387 benötigt wird, muss die Software weniger Informationen aus anderen Frames rekonstruieren.

Frame 387
↓
direkt dekodieren

Das kann Bearbeitung erleichtern.

Nachteil

Man nutzt weniger stark aus, dass benachbarte Frames einander ähneln.

Dadurch benötigt das Material typischerweise mehr Daten.

Inter-Frame-Kompression

Hier werden Beziehungen zwischen mehreren Frames genutzt.

Frame A
↓
Frame B beschreibt Unterschiede
↓
Frame C beschreibt weitere Unterschiede

Das kann erheblich effizienter sein.

Long GOP

Ein häufig verwendetes Prinzip ist eine Gruppe von Frames, innerhalb der verschiedene Bildtypen zusammenarbeiten.

GOP steht für:

Group of Pictures.

Vereinfacht:

I
B
B
P
B
B
P
...

Die genaue Struktur hängt vom Codec und den Encoding-Einstellungen ab.

Was ist ein I-Frame?

Ein I-Frame ist vereinfacht ein relativ eigenständig kodiertes Bild.

Man kann ihn als wichtigen Bezugspunkt innerhalb einer Framegruppe verstehen.

I-Frame
↓
relativ vollständige Bildinformation

Er benötigt keine vorherigen Videoframes, um in derselben Weise wie abhängige Frames rekonstruiert zu werden.

I steht für Intra

Der Frame wird primär aus Informationen innerhalb des eigenen Bildes aufgebaut.

Er ist konzeptionell näher an einem einzeln komprimierten Bild.

Was ist ein P-Frame?

Ein P-Frame kann Informationen aus bereits vorhandenen Referenzbildern nutzen.

Statt alles neu zu speichern, kann er vereinfacht beschreiben:

Bereich bleibt gleich
+
Person hat sich verschoben
+
Mund hat sich verändert

Dadurch braucht er weniger Daten.

Was ist ein B-Frame?

Ein B-Frame kann vereinfacht Informationen aus mehreren zeitlichen Richtungen beziehungsweise Referenzen nutzen.

Dadurch lässt sich häufig noch effizienter komprimieren.

Die genaue technische Funktionsweise moderner Codecs ist wesentlich komplexer als dieses Modell.

Für das Verständnis reicht:

I-Frame
→ relativ selbstständig

P-/B-Frames
→ nutzen andere Frames als Referenz

Warum spart das so viel Speicher?

Angenommen, ein Interview läuft zehn Sekunden.

Der Hintergrund verändert sich praktisch nicht.

Es wäre verschwenderisch, die Wand in jedem Frame vollständig neu zu speichern.

Stattdessen:

I-Frame
→ beschreibt Ausgangsszene

danach:

Folgeframes
→ beschreiben hauptsächlich Veränderungen

Warum erschwert das den Schnitt?

Du springst in der Timeline zu einem bestimmten Frame.

Der Decoder muss möglicherweise zuerst einen früheren Referenzframe finden und weitere Informationen rekonstruieren.

gewünschter Frame
↓
Referenz-I-Frame suchen
↓
abhängige Frames berechnen
↓
gewünschtes Bild darstellen

Bei vielen hochauflösenden Videospuren gleichzeitig kann das den Rechner stark belasten.

Deshalb gibt es schnittfreundliche Formate

Für die Bearbeitung werden häufig Formate beziehungsweise Codeceinstellungen bevorzugt, die:

leichter zu dekodieren,

framegenauer,

weniger stark voneinander abhängig

sind.

Dafür dürfen die Dateien größer sein.

Produktionscodec und Distributionscodec verfolgen unterschiedliche Ziele

Produktionsformat:

leichter Schnitt
+
hohe Qualität
+
große Dateien akzeptabel

Distributionsformat:

kleine Datei
+
effiziente Übertragung
+
gute Wiedergabe

Das ist ein fundamentaler Unterschied.

Was sind Proxies?

Wenn das Originalmaterial sehr schwer zu dekodieren ist, können Video-Grundlagen zufolge kleinere Arbeitskopien erzeugt werden.

Original
↓
Proxy-Transcoding
↓
leicht bearbeitbare Proxydatei

Der Schnitt verwendet:

Proxy.

Der finale Export greift wieder auf:

Original.

Proxy und Codec hängen eng zusammen

Ein Proxy kann:

niedrigere Auflösung,

niedrigere Datenrate

oder:

einen schnittfreundlicheren Codec

verwenden.

Dadurch reagiert die Timeline wesentlich flüssiger.

Was ist Transcoding?

Transcoding bedeutet, Videomaterial in eine andere Kodierung zu überführen.

Codec A
↓
dekodieren
↓
Frames
↓
Codec B
↓
neue Datei

Zum Beispiel:

Kameraformat
↓
Schnittformat

oder:

Master
↓
Webformat

Transcoding ist nicht einfach Dateiendung ändern

Aus:

video.mov

wird nicht durch Umbenennen:

video.mp4

eine technisch korrekt umkodierte MP4-Datei.

Container und Streams müssen tatsächlich neu organisiert beziehungsweise kodiert werden.

Rewrapping

Es gibt allerdings einen verwandten Vorgang:

Ein vorhandener Videostream kann unter bestimmten Voraussetzungen ohne erneute Videokompression in einen anderen Container verpackt werden.

Vereinfacht:

Videostream
↓
alter Container entfernen
↓
neuer Container

Dabei wird das Bild nicht zwangsläufig neu kodiert.

Das wird häufig als:

Rewrapping

bezeichnet.

Vorteil

Keine neue verlustbehaftete Videokompression.

Sehr schnell.

Aber es funktioniert nur, wenn:

der vorhandene Codec mit dem Zielcontainer beziehungsweise Zielsystem sinnvoll kompatibel ist.

Transcoding dagegen kann neu komprimieren

Das bedeutet bei verlustbehafteten Codecs:

erneuter Qualitätsverlust ist möglich.

Original
↓
verlustbehaftetes Encoding
↓
Version A
↓
erneutes Encoding
↓
Version B

Jede Stufe kann weitere Informationen verwerfen.

Generation Loss

Der Qualitätsverlust über mehrere verlustbehaftete Generationen wird häufig als Generation Loss bezeichnet.

Ähnlich wie beim wiederholten JPEG-Speichern.

Deshalb Master erhalten

Ein robuster Workflow:

hochwertiges Original
↓
Schnitt
↓
hochwertiger Master
├── Webversion
├── Socialversion
└── Präsentationsversion

Nicht:

Webversion
↓
Socialversion
↓
nochmal Webversion

Immer vom besten verfügbaren Master ableiten

Das verhindert unnötige Qualitätsverluste.

Bitrate und Codec

Wie im Grundlagenartikel erwähnt, beschreibt die Bitrate ungefähr die Datenmenge pro Zeiteinheit.

Zum Beispiel:

10 Mbit/s

oder:

50 Mbit/s

Die sichtbare Qualität hängt aber stark vom Codec ab.

Codec A
+
10 Mbit/s

kann anders aussehen als:

Codec B
+
10 Mbit/s

Bitrate ist kein universeller Qualitätswert

Auch innerhalb desselben Codecs spielen eine Rolle:

Auflösung,

Bildrate,

Bildinhalt,

Encoder,

Encoding-Einstellungen.

Ruhiges Interview

Relativ leicht zu komprimieren.

ruhiger Hintergrund
+
wenig Bewegung

Fußballspiel

Deutlich schwieriger.

Kamera bewegt sich
+
viele Spieler
+
Rasenstruktur
+
Publikum
+
schnelle Bewegung

Gleiche Bitrate kann beim Fußball wesentlich mehr sichtbare Artefakte erzeugen.

Constant Bitrate

Bei einer konstanten Bitrate, kurz CBR, soll die Datenrate über die Zeit relativ konstant bleiben.

Vereinfacht:

Sekunde 1
→ 10 Mbit

Sekunde 2
→ 10 Mbit

Sekunde 3
→ 10 Mbit

Das kann für bestimmte Übertragungs- und Echtzeitanwendungen nützlich sein.

Variable Bitrate

Bei VBR kann der Encoder komplexen Szenen mehr Daten geben und einfachen weniger.

ruhige Szene
→ wenig Daten

komplexe Action
→ mehr Daten

Das kann die verfügbare Dateigröße effizienter nutzen.

Zwei-Pass-Encoding

Bei bestimmten Offline-Encoding-Verfahren kann der Encoder das Video zunächst analysieren.

Erster Durchlauf:

Video analysieren
↓
komplizierte und einfache Stellen erkennen

Zweiter Durchlauf:

verfügbare Daten
optimaler verteilen

Das kostet mehr Zeit, kann aber besonders bei festem Dateigrößenziel effizient sein.

Qualitätsbasiertes Encoding

Statt eine fixe Bitrate vorzugeben, kann ein Encoder auch versuchen, eine bestimmte visuelle Qualitätsstufe zu halten.

Dann schwankt die Bitrate je nach Szenenkomplexität.

einfache Szene
→ kleine Datenrate

schwierige Szene
→ größere Datenrate

Für viele Datei- und Webworkflows kann dieses Prinzip sehr sinnvoll sein.

Was bedeutet Chroma Subsampling?

Videodaten enthalten nicht nur Helligkeit, sondern auch Farbinformation.

Die menschliche Wahrnehmung reagiert auf feine Helligkeitsdetails stärker als auf ebenso feine Farbauflösung.

Videocodecs können das nutzen.

Helligkeit und Farbe getrennt behandeln

Vereinfacht:

Luma
→ Helligkeitsinformation

Chroma
→ Farbinformation

Die Farbinformation kann räumlich niedriger aufgelöst werden, ohne dass der Qualitätsverlust bei normalen Bildern sofort stark auffällt.

4:4:4

Vereinfacht:

volle Farbinformation in Relation zur Helligkeitsabtastung.

4:2:2

Farbauflösung wird horizontal reduziert.

4:2:0

Farbinformation wird stärker reduziert.

Das ist bei Distributionsvideo sehr verbreitet.

Warum funktioniert 4:2:0 überraschend gut?

Ein normales Foto beziehungsweise Video besteht überwiegend aus:

natürlichen Flächen,

Haut,

Landschaft,

Bewegung.

Unsere Wahrnehmung toleriert geringere Farbauflösung dort relativ gut.

Wann wird hohe Farbauflösung wichtiger?

Zum Beispiel bei:

Greenscreen,

starker Farbkorrektur,

Compositing,

Grafiken,

feinen farbigen Kanten.

Greenscreen

Der Rand zwischen:

grünem Hintergrund

und:

Haar

muss möglichst präzise analysiert werden.

Mehr Farbinformation kann das Keying erleichtern.

mehr Chroma-Information
↓
präzisere Farbkante
↓
bessere Freistellung

Webauslieferung braucht diese Reserve häufig nicht

Beim fertigen Video ist die Komposition bereits abgeschlossen.

Für normale Wiedergabe kann stärker reduzierte Farbauflösung sehr effizient sein.

Wieder zeigt sich:

Produktionsformat
≠
Distributionsformat

Bittiefe bei Video

Wie bei RAW und JPEG bestimmt die Bittiefe, wie fein Werte abgestuft werden können.

Video begegnet häufig beispielsweise als:

8 Bit

oder:

10 Bit

pro Kanal beziehungsweise Signalstruktur.

Mehr Bittiefe bedeutet mehr Abstufungsreserve

Das kann besonders hilfreich sein bei:

Farbkorrektur,

Log-Aufnahmen,

Himmelverläufen,

starkem Grading.

8 Bit

Pro Kanalgröße stehen vereinfacht:

256 Abstufungen

zur Verfügung.

10 Bit

1024 Abstufungen

pro Kanalgröße.

Das sind viermal so viele Abstufungen pro Kanal.

Warum hilft das?

Ein weicher Himmelverlauf kann bei intensiver Bearbeitung schneller sichtbare Stufen zeigen, wenn zu wenige Zwischenwerte vorhanden sind.

Mehr Bittiefe bietet größere Bearbeitungsreserve.

Mehr Bittiefe ist nicht dasselbe wie mehr Dynamikumfang

Die Begriffe hängen im Workflow zusammen, sind aber nicht identisch.

Dynamikumfang beschreibt:

welchen Helligkeitsbereich die Aufnahme sinnvoll erfassen kann.

Bittiefe beschreibt:

wie fein Werte innerhalb eines dargestellten beziehungsweise gespeicherten Bereichs abgestuft werden können.

Ein 10-Bit-Video ist nicht automatisch besser belichtet

Auch hier gilt:

mehr technische Reserve ersetzt keine gute Aufnahme.

Codecprofile und Levels

Bei Codecs begegnen manchmal zusätzliche Angaben wie:

Profile

und:

Levels.

Sie beschreiben bestimmte Fähigkeits- beziehungsweise Komplexitätsgrenzen innerhalb eines Codecs.

Zum Beispiel können sie festlegen beziehungsweise begrenzen:

Auflösung,

Bildrate,

Bittiefe,

Decoding-Komplexität.

Muss man Profile auswendig lernen?

Für normale Contentproduktion:

meist nicht.

Wichtig ist das Prinzip:

Codecname allein
beschreibt noch nicht
jede technische Eigenschaft

Ein H.264-Stream kann unterschiedliche Parameter verwenden.

Hardware-Decoding

Moderne Prozessoren und Grafikeinheiten können bestimmte Videocodecs direkt in spezialisierter Hardware dekodieren.

Videostream
↓
Hardware-Decoder
↓
Frames

Das ist wesentlich effizienter, als jeden Schritt ausschließlich über allgemeine CPU-Berechnung auszuführen.

Warum ist das wichtig?

Ein Rechner kann einen modernen Codec theoretisch unterstützen.

Aber ohne Hardware-Decoding muss die CPU möglicherweise sehr viel Arbeit leisten.

Dann entstehen:

ruckelnde Timeline,

hohe CPU-Auslastung,

mehr Stromverbrauch.

Hardware-Encoding

Dasselbe Prinzip existiert beim Export.

Spezialisierte Hardware kann bestimmte Codecs sehr schnell kodieren.

Vorteil:

schneller Export.

Software-Encoding

Kann je nach Encoder mehr Rechenzeit investieren und möglicherweise andere Qualitäts- beziehungsweise Effizienzprioritäten besitzen.

Der optimale Weg hängt vom Ziel ab.

Schnellster Export ist nicht immer kleinste Datei

Hardware-Encoding kann hervorragend für:

schnelle Produktion,

Livestreaming,

Massenausgabe

sein.

Ein langsamer hochwertiger Offline-Encode kann für eine endgültige Webversion andere Vorteile besitzen.

Codec-Unterstützung ist eine ganze Kette

Ein Format muss nicht nur von der Kamera unterstützt werden.

Sondern gegebenenfalls auch von:

Kamera
↓
Schnittprogramm
↓
Betriebssystem
↓
GPU / CPU
↓
Exportsoftware
↓
Browser / Player
↓
Endgerät

Ein Problem an nur einer Stelle kann den Workflow erschweren.

Deshalb vorher testen

Bevor ein dreitägiger Dreh vollständig in einem exotischen Aufnahmeformat erfolgt:

Testclip aufnehmen
↓
auf Schnittrechner kopieren
↓
abspielen
↓
schneiden
↓
exportieren

Ein fünfminütiger Test kann massive Probleme verhindern.

Was ist MP4?

MP4 ist ein sehr verbreitetes Containerformat.

Es kann unter anderem enthalten:

Videostream,

Audiostream,

Untertitel,

Metadaten.

Ein typisches Beispiel:

video.mp4
├── H.264 Video
└── AAC Audio

Das ist eine verbreitete Kombination für digitale Auslieferung.

Was ist MOV?

MOV ist ebenfalls ein Containerformat.

Auch darin können unterschiedliche Codecs enthalten sein.

Die Dateiendung:

.mov

sagt daher ebenfalls nicht automatisch:

welche Videokompression verwendet wurde.

MOV ist nicht automatisch unkomprimiert

Ein häufiges Missverständnis lautet:

MOV
=
hochwertig

und:

MP4
=
komprimiert

So einfach ist es nicht.

Beide sind Container.

Der enthaltene Codec und dessen Einstellungen sind entscheidend.

Was ist MKV?

Matroska beziehungsweise MKV ist ein flexibles Containerformat, das unterschiedliche:

Video-,

Audio-,

Untertitelspuren

aufnehmen kann.

Es ist besonders praktisch, wenn mehrere Spuren beziehungsweise komplexe Medienkombinationen in einer Datei benötigt werden.

Was ist WebM?

WebM ist ein Containerformat, das speziell im Kontext offener Webmedien eine Rolle spielt.

Auch hier muss Container von Codec getrennt werden.

WebM
→ Container

Der enthaltene Video- und Audiocodec ist eine weitere Frage.

Dateiendung ist deshalb nur der Anfang

Wenn jemand sagt:

Schick mir das Video als MP4.

ist die technische Anforderung unvollständig.

Zusätzlich relevant könnten sein:

Videocodec
Audio-Codec
Auflösung
Bildrate
Bittiefe
Bitrate

Für einfache Alltagskommunikation ist „MP4“ oft ausreichend.

Für professionelle Übergaben sollte die Spezifikation genauer sein.

Audio besitzt ebenfalls Codecs

Eine Videodatei enthält nicht einfach „Ton“.

Die Audiospur kann ebenfalls komprimiert sein.

Ein verbreitetes Beispiel ist:

AAC.

Konzeptionell:

MP4
├── H.264 Video
└── AAC Audio

Video- und Audio-Codec sind voneinander unabhängig

Man könnte theoretisch denselben Videocodec mit unterschiedlichen Audiocodecs kombinieren, sofern Container und Wiedergabesystem dies unterstützen.

Mehrere Audiospuren

Ein Container kann beispielsweise enthalten:

Audio 1
→ Deutsch

Audio 2
→ Englisch

Audio 3
→ Audiodeskription

Das ist einer der Gründe, warum Container mehr sind als bloße Dateiendungen.

Untertitel

Auch Untertitel können als separate Spur beziehungsweise Ressource eingebunden werden.

Das ist flexibler als Text dauerhaft in das Videobild einzubrennen.

Video
+
Untertitelspur

Der Player kann sie:

anzeigen,

ausblenden,

wechseln.

Eingebrannte Untertitel

Sind dagegen Teil des Videobildes selbst.

Frame
↓
Text bereits in Pixeln

Sie können nicht einfach ausgeschaltet werden.

Metadaten

Container können zusätzliche Informationen enthalten.

Zum Beispiel:

Titel,

Erstellungszeit,

Kapitelinformationen,

technische Angaben.

Wie umfangreich das genutzt wird, hängt vom Workflow ab.

GOP-Länge und Suchbarkeit

Wenn ein Video nur selten I-Frames enthält, kann die Datei stärker komprimierbar sein.

Aber beim Springen zu einer bestimmten Stelle muss der Decoder möglicherweise mehr abhängige Frames verarbeiten.

Häufigere I-Frames

I P B I P B I

können beispielsweise Navigation beziehungsweise Schnitt erleichtern.

Dafür benötigen sie typischerweise mehr Daten.

Seltenere I-Frames

I B B P B B P B B P ...

können effizienter sein.

Wieder ein Kompromiss:

Kompression
↔
Zugriff / Bearbeitbarkeit

Keyframe im Webvideo

Bei Streaming beziehungsweise Wiedergabe spielen solche Referenzpunkte ebenfalls eine wichtige Rolle.

Wenn der Nutzer mitten im Video startet, ist ein geeigneter Einstiegspunkt notwendig.

Die konkrete Streamingarchitektur behandeln wir nicht bis ins Protokolldetail, aber die Grundidee lautet:

Videokompression
beeinflusst auch,
wie gut man innerhalb eines Videos navigieren kann

Schnitt auf Long-GOP-Material

Moderne Schnittprogramme können damit gut umgehen.

Bei:

mehreren 4K-Spuren,

hoher Bildrate,

aufwendigen Effekten

kann es trotzdem anstrengend werden.

Dann helfen:

Proxies

oder:

Transcoding in ein schnittfreundlicheres Format.

Warum Kameraformate manchmal riesige Bitraten haben

Eine Kamera muss Material zuverlässig in Echtzeit aufzeichnen.

Außerdem soll möglichst viel Bearbeitungsreserve bleiben.

Deshalb können Aufnahmebitrate und Dateigröße deutlich über einer späteren Webversion liegen.

Kamera-Master
→ hohe Qualität
→ große Datei

Website
→ kleinere Datei
→ fertiges Bild

Das ist kein Widerspruch.

Aufnahme und Distribution haben andere Anforderungen

Beim Dreh weiß man eventuell noch nicht:

wie stark das Material gecroppt,

farbkorrigiert,

stabilisiert

wird.

Deshalb lohnt Reserve.

Nach dem Schnitt sind diese Entscheidungen abgeschlossen.

Nun kann stärker komprimiert werden.

Ein typischer Video-Lebenszyklus

Kamera
↓
Aufnahmecodec
↓
Schnitt
↓
hochwertiger Master
↓
Web-Encoding
↓
Distributionscodec
↓
Browser / Player

Jede Stufe kann einen anderen Codec beziehungsweise andere Parameter verwenden.

Warum ein Master sinnvoll ist

Stell dir vor, du veröffentlichst heute eine:

1080p-Version.

In zwei Jahren brauchst du:

4K,

neues Format,

neuen Codec.

Wenn nur die alte stark komprimierte Webdatei existiert:

muss von schlechter Ausgangsbasis neu kodiert werden.

Mit Master

hochwertiger Master
├── heutiges Webformat
├── zukünftiges Webformat
└── neue Plattformversion

Das ist wesentlich robuster.

Master muss nicht zwangsläufig unkomprimiert sein

Unkomprimiertes Video kann gigantisch sein.

Ein Master kann durchaus komprimiert werden.

Entscheidend ist:

hohe Qualität,

geeignete Bearbeitungsreserve,

möglichst geringe vermeidbare Verluste.

Archivmaster und Produktionsmaster können unterschiedlich sein

Große Produktionen können verschiedene Ebenen unterscheiden.

Für normale Website- und Unternehmensproduktion reicht häufig ein einfacheres Modell:

Originalmaterial
+
Schnittprojekt
+
hochwertiger finaler Master
+
Webderivate

Originalmaterial trotzdem behalten?

Bei wichtigen Projekten häufig sinnvoll.

Denn der finale Master enthält nur:

den aktuellen Schnitt.

Vielleicht wird später eine neue Version benötigt.

Dann braucht man:

Rohmaterial.

Webvideo ist kein Archiv

Eine stark komprimierte kleine Distributionsdatei erfüllt einen anderen Zweck.

Webversion
→ schnell ausliefern

nicht:

Webversion
→ maximale zukünftige Bearbeitungsreserve

Codecs und WordPress

WordPress kann eine Videodatei zwar grundsätzlich als Medienobjekt verwalten beziehungsweise einbetten, doch die entscheidende Frage ist nicht nur:

Kann WordPress diese Datei speichern?

Sondern:

Kann der Browser sie zuverlässig abspielen?

Ist die Datei effizient?

Passt die Auflösung?

Ist die Datenrate sinnvoll?

500-MB-Kamera-MP4 direkt hochladen

kann technisch möglich sein.

Ist aber kein guter Webworkflow.

Besser:

Kameraaufnahme
↓
Schnitt
↓
Master
↓
Webencode
↓
Website

Codecwahl und Webperformance

Ein effizienterer Codec kann Bandbreite sparen.

Doch die beste Kompression nützt wenig, wenn ein relevanter Teil der Zielgeräte das Material nicht problemlos wiedergeben kann.

Deshalb ist für Websites immer das Gesamtsystem wichtig:

Qualität
+
Dateigröße
+
Kompatibilität

Fallbacks

Ein Videosystem kann gegebenenfalls mehrere Varianten anbieten.

Variante A
→ moderner effizienter Codec

Variante B
→ breiter kompatibler Codec

Der passende Stream beziehungsweise die passende Datei kann abhängig vom Wiedergabesystem gewählt werden.

Das ist konzeptionell ähnlich zu modernen Bildformaten.

Responsive Bilder als Vergleich

Bei Bildern kann man beispielsweise mehrere Formate beziehungsweise Größen bereitstellen.

Der Browser wählt eine geeignete Variante.

Bei Video kann ein Streaming- beziehungsweise Playersystem ebenfalls mehrere:

Codecs,

Auflösungen,

Bitraten

bereitstellen.

Adaptive Bitrate Streaming

Bei längerem Video kann zusätzlich die Qualität während der Wiedergabe angepasst werden.

gute Verbindung
→ höhere Qualität

schwache Verbindung
→ niedrigere Qualität

Dafür werden typischerweise mehrere Varianten desselben Videos vorbereitet.

Codec allein löst Webvideo nicht

Man braucht zusätzlich Entscheidungen über:

Auflösung,

Bitrate,

Streaming,

Poster,

Autoplay,

Preload.

Deshalb bekommt Webvideo-Komprimierung den nächsten eigenen Artikel.

Warum Browser-Decoding Energie kostet

Ein Videostream muss fortlaufend dekodiert werden.

Auf einem Smartphone bedeutet das:

Rechenarbeit

und damit:

Energieverbrauch.

Hardware-Decoding kann erheblich effizienter sein.

Ein theoretisch kleinerer Codec kann deshalb praktisch schlechter sein

Wenn das Endgerät ihn nur ineffizient per Software dekodieren kann.

Dann spart man vielleicht Netzwerkdaten, verbraucht aber:

mehr CPU,

mehr Akku.

Codecwahl ist daher immer ein Systemkompromiss.

Codecs beim Livestreaming

Livevideo besitzt eine zusätzliche Einschränkung:

Der Encoder kann nicht minutenlang im Voraus analysieren.

Kamera
↓
jetzt kodieren
↓
jetzt übertragen

Encoding-Geschwindigkeit und geringe Verzögerung werden wichtiger.

Offline-Video

Hier kann ein Encoder mehr Zeit investieren.

fertiges Video
↓
lange Analyse
↓
optimierte Datei

Deshalb können dieselben Codecs bei Live- und Datei-Encoding unterschiedlich eingesetzt werden.

Latenz

Starke Kompression kann Frames zeitlich voneinander abhängig machen.

Das kann zusätzliche Puffer beziehungsweise Verarbeitung erfordern.

Für normales Video-on-Demand ist das meist unproblematisch.

Bei:

Videokonferenzen,

Livestream,

Remote-Steuerung

kann geringe Verzögerung sehr wichtig sein.

Codecwahl hängt damit auch von Interaktivität ab

Film ansehen
→ Kompression wichtiger

Videotelefonie
→ geringe Verzögerung wichtiger

Es existiert nicht der eine optimale Codec für jede Anwendung.

Videoeditor und Codec

Beim Schnitt sollte das Material möglichst angenehm reagieren:

Scrubbing,

Framewechsel,

Rückwärtswiedergabe,

mehrere Spuren.

Long-GOP-Kompression kann insbesondere Rückwärtsnavigation schwieriger machen.

Warum Rückwärtswiedergabe?

Ein P- oder B-Frame kann von anderen Frames abhängen.

Wenn die Timeline rückwärts bewegt wird, muss die Software eventuell komplizierte Referenzketten rekonstruieren.

Schnittcodec

Daher werden in professionelleren Workflows häufig Codecs verwendet, die für Bearbeitung optimiert sind.

Sie erzeugen größere Dateien, reduzieren aber Decoderarbeit.

Proxy oder Transcode?

Zwei unterschiedliche Strategien.

Proxy:

Original bleibt
+
kleine Arbeitskopie

Transcoding:

Original wird in
anderes Produktionsformat umgewandelt

Beides kann die Bearbeitung erleichtern.

Proxy ist besonders flexibel

Denn die finale Qualität kommt weiterhin aus dem Original.

Proxy
→ nur Schnitt

Original
→ finaler Export

Transcoding kann Workflow vereinheitlichen

Wenn Material aus:

mehreren Kameras,

Smartphones,

Screen Recordings

kommt, können unterschiedliche Quellformate zunächst auf einen gemeinsamen Produktionsstandard gebracht werden.

Quelle A
Quelle B
Quelle C
↓
gemeinsames Schnittformat

Das kann Stabilität erhöhen.

Screen Recordings und variable Framerate

Wie im Artikel über Bildraten beschrieben, können Bildschirmaufnahmen oder Smartphonevideos variable Framerate besitzen.

Transcoding in ein konstantes Schnittformat kann Synchronisationsprobleme beheben.

Codec-Probleme diagnostizieren

Video ruckelt im Schnitt.

Nicht automatisch:

Computer zu langsam

Vielleicht:

Codec schwer zu dekodieren.

Test

Proxy erzeugen.

Wenn der Schnitt plötzlich flüssig läuft:

liegt das Problem wahrscheinlich stark in:

Auflösung,

Codec

beziehungsweise:

Decoding-Aufwand.

Video spielt auf einem Gerät nicht

Mögliche Ursache:

Container erkannt
aber Codec nicht unterstützt

Die Datei erscheint also als:

.mp4

aber der enthaltene Stream kann problematisch sein.

Ton funktioniert, Bild nicht

Das ist ein typisches Zeichen dafür, dass:

Container und Audiocodec gelesen werden,

Videocodec aber nicht.

Bild funktioniert, Ton nicht

Umgekehrt kann der Audiocodec beziehungsweise die Audiospur das Problem sein.

Deshalb Medieninformationen prüfen

Eine technische Analyse einer Videodatei sollte mindestens zeigen:

Container
Videocodec
Audiocodec
Auflösung
Bildrate
Bitrate
Bittiefe

Damit lässt sich wesentlich gezielter diagnostizieren.

„MP4 funktioniert nicht“ ist technisch zu ungenau

Eine bessere Fehlerbeschreibung wäre beispielsweise:

MP4-Container
H.265 Video
AAC Audio
4K
50 fps
10 Bit

Nun weiß man wesentlich mehr über die Datei.

Video-Kompressionsartefakte

Bei zu starker Kompression können unterschiedliche Fehler sichtbar werden.

Blockbildung

Flächen zerfallen in sichtbare rechteckige Strukturen.

Besonders:

dunkle Bereiche,

schnelle Bewegung,

geringe Bitrate.

Banding

Feine Farb- beziehungsweise Helligkeitsverläufe werden zu sichtbaren Stufen.

Zum Beispiel:

Himmel,

Nebel,

Studiohintergrund.

Mosquito Noise

Um harte Kanten können flimmernde beziehungsweise körnige Kompressionsstrukturen entstehen.

Zum Beispiel rund um:

Text,

Äste,

feine Konturen.

Detailverlust

Gras,

Haare,

Blätter,

Gewebe

werden zu weich beziehungsweise matschig.

Temporale Artefakte

Details können über mehrere Frames:

wabern,

verschwinden,

nachziehen.

Das entsteht, wenn zeitliche Kompression bei komplexer Bewegung an Grenzen kommt.

Dunkle Szenen sind oft schwierig

Dunkle Bereiche enthalten:

Rauschen,

feine Tonwertunterschiede.

Rauschen verändert sich von Frame zu Frame und ist dadurch schwer zu komprimieren.

Sensorrauschen
→ ständig neue kleine Muster
→ Codec muss viel Veränderung beschreiben

Rauschreduzierung vor Encoding

Kann deshalb manchmal nicht nur das Bild glätten, sondern auch die Komprimierbarkeit verbessern.

Aber:

zu starke Rauschreduzierung vernichtet Details.

Filmkorn

Künstlich hinzugefügtes Filmkorn besitzt ebenfalls zufällige Veränderungen.

Das kann Videokompression erheblich erschweren.

Ein schöner Grain-Look kann deshalb die benötigte Bitrate erhöhen.

Konfetti ist Codec-Hölle

Viele kleine bewegte Details.

Ähnlich:

Schnee,

Regen,

Wasser,

Blätter,

Menschenmengen.

Solche Szenen brauchen typischerweise mehr Daten für saubere Darstellung.

Statische Grafiken sind leicht

Ein Präsentationsvideo mit:

großen einfarbigen Flächen

und:

wenig Bewegung

lässt sich dagegen sehr effizient komprimieren.

Aber Text braucht saubere Kanten

Bei Bildschirmtutorials und Präsentationen ist ein anderes Problem wichtig:

kleine Schrift.

Zu starke Kompression kann Text unscharf machen.

Deshalb sollte die Kodierung zum Bildinhalt passen.

Bildschirmaufnahme und Kameraaufnahme sind unterschiedlich

Kamera:

organische Strukturen
+
Rauschen
+
Bewegung

Screen Recording:

scharfe Kanten
+
Text
+
Flächen

Ein optimaler Encode für beide kann unterschiedliche Einstellungen benötigen.

Mehr Bitrate löst nicht alles

Wenn das Ausgangsmaterial bereits:

unscharf,

überbelichtet,

stark verrauscht

ist, macht eine gigantische Bitrate daraus kein gutes Video.

guter Codec
≠
gute Aufnahme

Umgekehrt kann schlechte Kodierung gutes Material zerstören

Hochwertiges Master:

perfekt.

Webexport:

viel zu starke Kompression.

Nun sieht der Nutzer nur:

Artefakte.

Die Produktionsqualität wurde am letzten Schritt verschenkt.

Deshalb Encoding als Teil der Gestaltung betrachten

Der Webexport ist nicht nur:

technischer Abschluss.

Er entscheidet, welche Qualität tatsächlich beim Nutzer ankommt.

Codecs bei generativem Video

Auch KI-generierte Videos müssen am Ende gespeichert und übertragen werden.

Das Modell erzeugt möglicherweise intern Frames beziehungsweise Videodaten.

Für die Veröffentlichung gelten danach dieselben Fragen:

Auflösung
↓
Bildrate
↓
Codec
↓
Container
↓
Bitrate
↓
Webauslieferung

Generative Herkunft ersetzt den klassischen Medienworkflow nicht.

KI-Videos können besonders schwer komprimierbar sein

Wenn ein generiertes Video feine ständig wechselnde Strukturen besitzt:

Haare,

Partikel,

Texturen,

Rauschen,

kann ein Codec hohe Datenmengen benötigen.

Generative Inkonsistenz und Kompressionsartefakt unterscheiden

Ein Objekt verändert plötzlich seine Form.

Das kann ein:

KI-Generierungsfehler

sein.

Ein Detail zerfällt nur während schneller Bewegung in Blöcke:

eher Kompression.

Für Qualitätskontrolle müssen diese Fehlerarten getrennt werden.

Automatisiertes Transcoding

Bei vielen Videos sollte niemand jedes Webformat einzeln per Hand exportieren müssen.

Eine Pipeline könnte beispielsweise funktionieren:

Mastervideo
↓
Analyse
↓
1080p-Version
↓
720p-Version
↓
verschiedene Codecs
↓
Posterbild
↓
Untertitel
↓
Website

Das lässt sich gut automatisieren

Denn viele Parameter sind deterministisch.

Zum Beispiel:

Zielauflösung,

Codec,

Bitrate beziehungsweise Qualitätsmodus,

Dateiname,

Speicherpfad.

Qualitätskontrolle bleibt sinnvoll

Nach Encoding kann automatisiert geprüft werden:

Datei vorhanden?

Laufzeit korrekt?

Auflösung korrekt?

Tonspur vorhanden?

Dekodierbar?

Visuelle QA

Fortgeschritten kann zusätzlich geprüft werden:

offensichtliche Artefakte,

schwarze Frames,

Ton-/Bild-Synchronität,

falsches Seitenverhältnis.

Ein systematischer Video-Asset-Workflow

Rohmaterial
↓
Schnitt
↓
Master
↓
Transcoding-Pipeline
├── Web 1080p
├── Web 720p
├── Mobile
└── Archiv

Das skaliert wesentlich besser als:

jedes Video
irgendwie manuell exportieren

Welche Codec-Ebene sollte ein digitaler Selbstmacher verstehen?

Man muss keine Bewegungsvektoren mathematisch berechnen.

Aber man sollte fünf Fragen beantworten können:

Was ist der Container?

Welcher Videocodec steckt darin?

Welcher Audiocodec?

Ist die Datei für Schnitt oder Distribution gedacht?

Welche Qualitäts-/Größenanforderung gibt es?

Damit lassen sich sehr viele Videoprobleme einordnen.

Codecwahl für die Aufnahme

Hier sind besonders wichtig:

Bildqualität,

Bearbeitungsreserve,

Speicherkartenleistung,

Kamerafähigkeiten,

Schnittsystem.

Eine kleinere Datei ist nicht immer vorteilhaft, wenn der Schnitt dadurch quälend langsam wird.

Codecwahl für den Schnitt

Hier zählen:

Dekodierbarkeit,

Framezugriff,

Qualitätsreserve.

Dateigröße darf größer sein.

Codecwahl für den Master

Hier zählen:

hohe Qualität,

langfristige Nutzbarkeit,

geringe unnötige Verluste.

Codecwahl für das Web

Hier zählen besonders:

visuelle Qualität
+
kleine Datenmenge
+
Kompatibilität

Diese Abwägung vertiefen wir im nächsten Beitrag.

Häufige Missverständnisse über Video-Codecs

„MP4 ist ein Codec“

Nein.

MP4 ist ein Container.

„H.264 ist eine Dateiendung“

Nein.

H.264 ist ein Videokompressionsstandard.

„MOV ist bessere Qualität als MP4“

Nicht automatisch.

Beide sind Container. Entscheidend sind die darin enthaltenen Medienstreams.

„Kleine Videodatei ist leichter zu schneiden“

Nicht unbedingt.

Starke Long-GOP-Kompression kann erheblichen Decoding-Aufwand erzeugen.

„Höhere Bitrate bedeutet immer bessere Qualität“

Nur unter vergleichbaren Bedingungen. Codec, Encoder, Auflösung und Bildinhalt spielen ebenfalls eine Rolle.

„Wenn ein Video schon MP4 ist, kann es auf jeder Website abgespielt werden“

Nicht zwangsläufig. Der enthaltene Codec und dessen Parameter müssen ebenfalls unterstützt werden.

„Transcoding ändert nur die Dateiendung“

Nein. Beim echten Transcoding wird Medieninformation neu kodiert.

„Rewrapping und Transcoding sind dasselbe“

Nein. Rewrapping verändert primär die Verpackung, ohne den Videostream zwangsläufig neu zu komprimieren.

„Jede erneute Kodierung ist unsichtbar“

Verlustbehaftetes Re-Encoding kann Qualitätsverluste kumulieren.

„4:2:0 ist automatisch schlechte Farbe“

Nein. Für fertige Distributionsvideos kann reduzierte Farbauflösung sehr effizient und visuell völlig ausreichend sein.

„10 Bit bedeutet automatisch HDR“

Nein. Bittiefe und Dynamikumfang beziehungsweise HDR sind unterschiedliche Konzepte.

„Der modernste Codec ist immer die beste Wahl“

Nein. Ein Codec muss in der gesamten Produktions- und Wiedergabekette funktionieren.

Ein praktischer Entscheidungsweg

Zuerst fragen:

Welche Stufe des Workflows?

Aufnahme?

Schnitt?

Master?

Web?

Für die Aufnahme

Qualität
+
Kamerakompatibilität
+
Speicher
+
Schnittbarkeit

abwägen.

Für den Schnitt

Wenn das Material ruckelt:

Proxy
oder
schnitttaugliches Transcoding

prüfen.

Für den Master

hohe Qualität
+
keine unnötige starke Kompression

priorisieren.

Für das Web

Qualität
+
Dateigröße
+
Kompatibilität

optimieren.

Ein sinnvoller Gesamtworkflow

Kamera
↓
Aufnahmeformat
↓
Originale sichern
↓
gegebenenfalls Proxies
↓
Schnitt
↓
hochwertiger Master
↓
Web-Encoding
↓
Distributionsdateien

Das ist der wichtigste praktische Zusammenhang des gesamten Themas.

Was du dir über Container merken solltest

Ein Container organisiert verschiedene Medienbestandteile in einer Datei.

Zum Beispiel:

Container
├── Video
├── Audio
├── Untertitel
└── Metadaten

Typische Containerbezeichnungen sind beispielsweise:

MP4,

MOV,

MKV,

WebM.

Die Dateiendung sagt jedoch nicht automatisch, welcher Videocodec enthalten ist.

.mp4
≠
automatisch H.264

Was du dir über Codecs merken solltest

Ein Codec definiert, wie Medieninformationen kodiert und dekodiert werden.

Videoframes
↓
Encoder
↓
komprimierter Stream

und beim Abspielen:

komprimierter Stream
↓
Decoder
↓
Videoframes

Häufige Videocodecs beziehungsweise Standards sind unter anderem:

H.264/AVC,

H.265/HEVC,

AV1.

Sie verfolgen unterschiedliche Kompromisse zwischen:

Kompression,

Bildqualität,

Rechenaufwand,

Kompatibilität.

Videocodecs sparen besonders durch Ähnlichkeiten

Innerhalb eines Bildes:

räumliche Redundanz

und zwischen Bildern:

zeitliche Redundanz

werden ausgenutzt.

Dadurch muss nicht jeder Frame vollständig neu gespeichert werden.

I-, P- und B-Frames helfen dabei

Vereinfacht:

I
→ relativ eigenständiger Frame

P
→ verwendet Referenzinformationen

B
→ kann weitere Referenzbeziehungen nutzen

Das reduziert Dateigröße, erhöht aber unter Umständen den Decoding-Aufwand.

Deshalb kann stark komprimiertes Video schwer zu schneiden sein

kleine Datei
+
komplexe Frameabhängigkeiten
↓
hoher Decoding-Aufwand

Proxies beziehungsweise schnittfreundliche Zwischenformate lösen dieses Problem häufig.

Produktionsformat und Webformat sollten getrennt werden

Für den Schnitt:

große Datei
+
leicht dekodierbar
+
hohe Qualität

kann sinnvoll sein.

Für die Website:

kleine Datei
+
effizient komprimiert
+
breit abspielbar

Das sind unterschiedliche Anforderungen.

Auch Bittiefe und Farbauflösung spielen hinein

Mehr Bearbeitungsreserve kann entstehen durch:

höhere Bittiefe
+
höhere Farbauflösung

Das ist vor allem während:

Color Grading,

Greenscreen,

Compositing

wertvoll.

Das fertige Distributionsvideo kann anschließend stärker optimiert werden.

Transcoding gehört zum normalen Videoworkflow

Aufnahme
↓
Schnitt
↓
Master
↓
Transcoding
↓
Website

Es ist kein Zeichen dafür, dass das ursprüngliche Format falsch war.

Unterschiedliche Produktionsstufen benötigen schlicht unterschiedliche Dateien.

Der Master bleibt die Quelle

Ein besonders wichtiger Grundsatz lautet:

Master
├── Website
├── Social
├── Präsentation
└── zukünftige Formate

Nicht:

kleine Webversion
↓
immer wieder neu kodieren

Damit werden Generation Loss und unnötige Qualitätsverluste vermieden.

Der zentrale Merksatz lautet:

Der Container bestimmt, wie Video, Ton und weitere Informationen gemeinsam verpackt werden. Der Codec bestimmt, wie diese Medieninformationen komprimiert und wieder dekodiert werden. Eine gute Videodatei entsteht erst dann, wenn Codec, Container, Qualität, Dateigröße und Zielsystem sinnvoll zusammenpassen.