MP4-Container verstehen: moov, mdat und warum Videos brechen

Vorab: Dieser Artikel ist Engineering-tief. Wenn du nur dein Video reparieren willst, ist der komplette Reparatur-Guide der bessere Einstieg. Wenn du verstehen willst, warum Videos brechen und wie Tools sie reparieren — lies weiter.

Eine MP4-Datei ist nicht magisch. Sie ist ein simples Containerformat, das ein paar klare Regeln befolgt — und jeder, der die kennt, kann beschädigte Dateien viel besser einordnen, als jedes Marketing-Material es je könnte.

Was MP4 wirklich ist: ISO BMFF

“MP4” ist umgangssprachlich. Technisch heißt das Format ISO BMFF — ISO Base Media File Format, spezifiziert in ISO/IEC 14496-12. MOV (Apple QuickTime), 3GP, M4A, M4V und das HEIC-Bildformat sind allesamt Varianten desselben Standards. Sie unterscheiden sich nur im Brand-Identifier am Anfang und in der erlaubten Codec-Liste.

Das Format ist von 1991 (QuickTime), wurde 1998 ISO-standardisiert und seitdem nur marginal verändert. Es ist ein “Geh-mir-aus-dem-Weg”-Format: Die Spezifikation legt nur fest, wie man die Datei strukturiert, nicht was im Inneren steht.

Box-Struktur: das einzige Konzept, das du brauchst

Eine MP4-Datei besteht aus einer Sequenz von Boxes (Apple nennt sie Atoms — es ist exakt dasselbe). Jede Box hat denselben Header:

[4 Bytes: Box-Größe in Big-Endian, inkl. Header]
[4 Bytes: Box-Type als 4-Zeichen-ASCII]
[Body: Box-Größe minus 8 Bytes]

Das war’s. Die ganze ISO-BMFF-Spec ist konzeptionell nur diese Struktur, rekursiv geschachtelt.

Wenn du eine MP4 mit einem Hex-Editor öffnest, siehst du am Anfang typisch:

00 00 00 20 66 74 79 70  6D 70 34 32 00 00 00 00
^^^^^^^^^^^ ^^^^^^^^^^^
 size=32     "ftyp"

Die ersten 4 Bytes sagen “diese Box ist 32 Bytes lang”, die nächsten 4 sagen “ich bin vom Typ ftyp”. Dann kommt der Body — meistens ein Major-Brand-Identifier wie “mp42”, “isom”, “qt ” (für QuickTime).

Die wichtigen Top-Level-Boxes

In einer kompletten MP4 gibt es zigtausend mögliche Boxes. Du musst nur fünf kennen:

ftyp — File Type

Steht am Anfang. Sagt dem Decoder: “Ich bin eine MP4 vom Brand X”. Wenn ftyp fehlt, gibt der Decoder oft schon hier auf. Wenn ftyp mit dem Inhalt nicht übereinstimmt (z.B. qt Brand, aber MP4-Codecs), gibt’s Edge-Case-Verhalten.

moov — Movie Atom

Der Index. Enthält:

• mvhd — Movie-Header mit Total-Duration, Timescale
• trak — Track-Definitionen (typisch zwei: ein Video-Track, ein Audio-Track)
• In jedem trak: tkhd (Track-Header), mdia (Media-Container) mit minf (Media-Information) mit stbl (Sample-Table)
• Die Sample-Table ist das eigentliche Gold: stts (Decode-Times), stss (Sync-Samples, also Keyframes), stsc (Sample-To-Chunk-Mapping), stsz (Sample-Sizes), stco (Chunk-Offsets im File)

Ohne moov ist die Datei nicht abspielbar. Der Decoder weiß nicht, wo welcher Frame liegt, wie lang er ist, in welchem Codec er codiert ist.

mdat — Media Data

Die eigentlichen Bytes. Hier liegen alle Video-Frames und alle Audio-Samples hintereinander, in einer einfachen Bytestream-Sequenz. Die Sample-Table im moov zeigt mit Offsets in diesen Block.

mdat ist meistens 99% der Dateigröße. Wenn die Datei 1,4 GB groß ist, sind ~1,38 GB davon mdat.

free und skip

Padding-Boxes. Können ignoriert werden.

uuid

Erweiterungs-Boxes mit 128-Bit UUID statt 4-Char-Type. Sony, Canon und andere nutzen das für proprietäre Metadaten (Camera-Modell, Profil-Settings, XML-Sidecars). Bei DiskDrill-Recovery kann uuid Probleme machen, weil Bytes aus benachbarten Sektoren reingemischt werden — siehe Sony FX3 Karten-Crash.

Wo schreibt der Encoder den Index?

Hier kommt das kritische Detail: ISO BMFF erlaubt drei verschiedene Layouts.

Layout A — moov hinten (Standard bei Live-Aufnahme):

[ftyp][mdat (alle Roh-Bytes)][moov (Index)]

Der Encoder weiß während der Aufnahme nicht, wie groß das Video wird. Er schreibt also ftyp an den Anfang, dann pumpt er kontinuierlich Frames in mdat, und ganz am Ende — wenn der User auf “Stop” drückt — schreibt er den Index. Vorteil: minimaler RAM-Verbrauch.

Genau hier kommt das Problem. Wenn die Aufnahme abgebrochen wird (Akku leer, Karte raus, Crash), wird moov nie geschrieben. Die Datei hat ftyp + mdat, aber keinen Index. Player können nichts damit anfangen.

Layout B — moov vorn (Streaming-Optimiert):

[ftyp][moov (Index, oft mit Platzhalter-Offsets)][mdat]

Bei -movflags faststart in ffmpeg, oder bei Web-Optimized-Files. Der Encoder berechnet im Voraus oder schreibt zuerst nach Layout A und remuxt dann. Diese Files sind robust gegen Aufnahme-Abbrüche, weil moov schon da ist — aber Camera-Aufnahmen sind selten so.

Layout C — Fragmented MP4 (Streaming-Live):

[ftyp][moov (Init-Segment, leer)][moof+mdat][moof+mdat][moof+mdat]…[mfra]

DASH/HLS-Streaming nutzt das. Jedes Fragment hat seinen eigenen Mini-Index (moof). Robust gegen Abbruch, aber komplexer. Camera-Aufnahmen verwenden das selten — manche Cinema-Cameras (RED, Sony Cinema) ja.

Die meisten kaputten Aufnahmen sind Layout A mit fehlendem moov. Das ist die statistische Realität.

Wie repariert man eine MP4 ohne moov?

Hier wird’s interessant. Der mdat-Block ist da — alle Frames sind drin. Was fehlt, ist der Index. Den muss man aus den Roh-Bytes rekonstruieren.

Schritt 1: Frame-Boundaries finden

In einem H.264- oder HEVC-Stream sind Frames durch NAL-Unit-Startcodes getrennt: 0x00 00 00 01 (4 Bytes) oder 0x00 00 01 (3 Bytes). Wenn man den mdat-Block durchläuft und nach Startcodes sucht, findet man jeden Frame-Anfang.

... 0F 3A 89 00 00 00 01 65 88 12 ...
                ^^^^^^^^^ NAL start
                       ^^ NAL-Header (Type=5 = IDR-Frame)

Aus dem NAL-Header kann man den Frame-Typ ablesen (I-Frame, P-Frame, B-Frame, SPS, PPS, IDR). Damit kann man eine vollständige Sample-Tabelle nachbauen.

Wichtig: Im MP4-Container sind die NAL-Units oft length-prefixed statt mit Startcodes codiert. Bei H.264 mit avc1-Tag und bei HEVC mit hvc1-Tag steht vor jedem NAL die Länge in 4 Bytes Big-Endian — keine Startcodes. Tools müssen das wissen, sonst finden sie keine Frames.

Schritt 2: Codec-Parameter rekonstruieren

Selbst wenn man alle Frame-Offsets hat, braucht der Decoder noch die Codec-Parameter: SPS (Sequence Parameter Set), PPS (Picture Parameter Set), bei HEVC auch VPS (Video Parameter Set). Diese stehen normalerweise im moov (im avcC oder hvcC Atom). Wenn das fehlt, gibt’s zwei Optionen:

(a) Aus dem Bitstream extrahieren. Wenn der Encoder die Parameter “in-band” geschrieben hat (NAL-Unit-Types 7/8 bei H.264, 32–34 bei HEVC), kann man sie aus dem mdat selbst lesen. Funktioniert oft bei H.264, seltener bei HEVC.

(b) Aus einer Referenz-Aufnahme klauen. Das ist die zuverlässige Methode. Eine intakte Aufnahme derselben Kamera mit identischen Settings hat exakt dieselben SPS/PPS — Codec-Profile, Level, Color-Primaries, Bit-Depth. Man kopiert die avcC/hvcC-Box aus der Referenz in das rekonstruierte moov des kaputten Files.

Schritt 3: Audio-Stream-Sync

Hier kommt der häufigste Fehler bei naiven Reparatur-Tools. Audio-Samples sind im mdat zwischen Video-Frames interleaved. Wenn man die Audio-Offsets falsch berechnet, läuft der Ton voraus oder hinterher.

Konkretes Beispiel: Bei Sony XAVC mit 24-bit-PCM-Audio gibt es einen 480ms-Drift zwischen Audio und Video, weil der Audio-Stream bei XAVC mit einem Pre-Roll beginnt, der nicht im Standard-Sample-Table-Format ankommt. untrunc-Standard liefert diese Files mit 480ms Audio-Vorlauf zurück. Haven misst die Drift durch Cross-Korrelation mit der Referenz-Aufnahme und korrigiert sie automatisch — siehe Audio-Drift im Video beheben.

Warum die hvcC-Box besonders empfindlich ist

Bei HEVC gibt es ein zusätzliches Problem: Die hvcC-Box enthält nicht nur SPS/PPS, sondern auch:

• lengthSizeMinusOne — Länge des Length-Prefix in den NAL-Units (typisch 3, also 4-Byte-Prefix)
• arrays[] — VPS/SPS/PPS NAL-Units als binäre Blobs
• chromaFormat — 4:2:0 (0), 4:2:2 (1), 4:4:4 (3)
• bitDepthLumaMinus8 und bitDepthChromaMinus8 — 8-bit (0) oder 10-bit (2)
• avgFrameRate und constantFrameRate — Frame-Rate-Hinweise

Wenn auch nur ein Byte dieser Box falsch ist (z.B. weil DiskDrill aus dem falschen Sektor gelesen hat), schlägt die Decoder-Initialisierung fehl, und der Player zeigt nur ein leeres Bild — selbst wenn alle Frames im mdat intakt sind.

Bei HEVC kommt zusätzlich der hev1/hvc1-Tag-Unterschied dazu:

• hvc1: SPS/PPS/VPS sitzen ausschließlich in der hvcC-Box (out-of-band)
• hev1: SPS/PPS/VPS können auch in-band im Bitstream sitzen

Wenn ein Tool eine Datei von hev1 nach hvc1 umpackt, ohne die Parameter aus dem Bitstream in die hvcC-Box zu kopieren, ist das Resultat ein File mit leerer hvcC — und schwarzer Wiedergabe.

Was Reparatur-Tools intern wirklich tun

Wenn du jetzt ein generisches Reparatur-Tool öffnest und auf “Reparieren” drückst, läuft folgendes ab:

1. Scan: Lies die Datei in Blöcken von ein paar MB. Suche nach Box-Headern. Identifiziere ftyp, mdat, moov (falls vorhanden), uuid.
2. Diagnose: Welche Top-Level-Boxes fehlen? Wenn moov fehlt → Pfad A (Index-Rekonstruktion). Wenn moov da, mdat aber kürzer als erwartet → Pfad B (mdat-Reparatur). Wenn beide da, aber Codec-Parameter fehlen → Pfad C (Codec-Patch).
3. Pfad A (häufigster Fall): NAL-Unit-Scanner durch mdat laufen lassen, alle Sample-Boundaries finden. Aus der Referenz SPS/PPS/VPS extrahieren. Neue moov-Struktur synthetisieren. Datei mit neuem Layout schreiben.
4. Verifikation: Eigene Decode-Pipeline öffnet die rekonstruierte Datei, prüft, dass der erste IDR-Frame decodierbar ist und dass Audio-Samples geliefert werden.

Bei diesem Prozess gibt es 100 Stellen, an denen ein Tool Detail-Fehler machen kann. Die Erfahrung mit verschiedenen Kameras (Sony XAVC vs GoPro HEVC vs iPhone Cinematic) ist genauso wichtig wie der Code selbst — siehe die geräte-spezifischen Anleitungen unter Reparieren.

Was du als User mitnehmen kannst

Drei Erkenntnisse, die dich bei jedem Reparatur-Tool zum besseren Käufer machen:

1. Eine kaputte MP4 ist meistens reparierbar, weil 99% der Datei intakt sind. Was fehlt, ist der kleine Index am Ende.
2. Eine Referenz-Aufnahme erhöht Erfolgsquoten dramatisch. Wenn ein Tool ohne Referenz-Option angeboten wird, ist es entweder sehr generisch (niedrigere Erfolgsquote) oder es behauptet Magie zu können, die es nicht hat.
3. “KI-Reparatur” ist Marketing-BS. Video-Reparatur ist deterministische Container-Rekonstruktion. Wenn ein Anbieter mit “KI” wirbt, frage konkret nach der Methodik — oft ist es einfach untrunc unter neuer Marke.

Fertig — was als nächstes?

• Du willst die kompletten Reparatur-Strategien sehen? → Beschädigtes Video reparieren — der komplette Guide
• Du willst sehen, wie der spezifische moov-Atom-Fehler behoben wird? → moov-Atom fehlt — Anleitung
• Du willst dein Video direkt prüfen? → Kostenlose Online-Diagnose (lokal im Browser, kein Upload)