"Invalid data found when processing input"

Eine MP4- oder MOV-Datei ist ein Baum aus Boxen (auch Atome genannt). Jede Box beginnt mit einer 4-Byte-Größe und einem 4-Byte-Typ: ftyp deklariert die Marke (Brand), mdat enthält die rohen Audio- und Video-Samples, und moov ist der Index – die Sample-Tabellen, die angeben, wo jedes einzelne Bild liegt, welcher Codec es dekodiert und zu welchem Zeitstempel. Wenn ffmpeg die Datei öffnet, durchläuft es diesen Baum. Findet es kein kohärentes moov, oder kündigt eine Box eine Größe an, die über das Dateiende hinausläuft, oder sind die Bytes dort, wo der Header einer Box stehen sollte, Müll, dann hält es an und meldet "Invalid data found when processing input".

Und das Entscheidende: Die schweren Daten – das mdat mit deinem tatsächlichen Filmmaterial – können vollkommen intakt sein, während das passiert. Der Parser scheitert am Index, nicht an den Bildern. Deshalb kann dieselbe Datei, die "keine gültigen Daten" haben soll, voller einwandfreier Frames stecken, die auf einen Container warten, der sie korrekt beschreibt. Das überschneidet sich stark mit dem klassischen Fall "moov atom not found": Eine Aufnahme, die abgebrochen wurde, bevor die Kamera ihr moov geschrieben hat, hinterlässt genau diese Signatur.

Wenn die Samples überlebt haben, aber die Landkarte kaputt ist, lautet die Lösung remultiplexen (remux): die überlebenden Stream-Daten durchsuchen, die Sample-Tabellen rekonstruieren, die der Container braucht, und eine frische, wohlgeformte MP4 rund um dasselbe Filmmaterial schreiben. Dabei wird nicht neu kodiert, es gibt also keinen Qualitätsverlust – die Frames sind die Original-Frames, nur wieder korrekt indexiert. Wo das moov ganz fehlt, baut das Werkzeug es aus der Struktur des Medienstreams neu auf, damit der Player die Frame-Karte bekommt, nach der er gesucht hat.

Der andere häufige Auslöser ist eine nicht passende Dateiendung oder eine abgebrochene Übertragung. Eine Datei namens .mp4, die in Wirklichkeit als anderer Container gespeichert wurde, oder ein Clip, dessen Download auf halbem Weg gestoppt wurde – beide bringen ffmpeg dazu, sich an unerwarteten Bytes zu verschlucken. Das Werkzeug prüft anhand der Box-Signaturen und nicht anhand des Namens, was die Datei wirklich ist, und rettet den Teil, der angekommen ist. All das läuft in deinem Browser: ohne ffmpeg-Installation, ohne Kommandozeile und ohne dass jemals ein Server das Video erhält.

Den Container neu aufzubauen funktioniert nur, wenn der Container das Problem ist. Sind die zugrunde liegenden Mediendaten selbst zerstört oder überschrieben – eine Karte, die Nullen zurückgab, eine Datei, die von einem defekten Laufwerk zerfetzt wurde, eine Aufnahme, die die Kamera in einer Schleife überschrieben hat –, dann gibt es keine guten Frames zum Neuindizieren, und kein Werkzeug kann Filmmaterial rekonstruieren, das nicht auf der Platte liegt. Hol zuerst die rohen Bytes aus dem Speicher zurück und repariere danach.

Der andere ehrliche Aussichtslos-Fall ist eine Datei, die eigentlich gar kein Video ist: ein Dokument, ein Bild oder ein abgeschnittenes Fragment, das zufällig eine .mp4-Endung trägt. Dort ist "Invalid data" buchstäblich wahr, und kein Remux kann eine Nicht-Mediendatei in einen abspielbaren Clip verwandeln. Wenn das Filmmaterial aber vorhanden ist, bedeutet der reine Browser-Ansatz, dass sensible Aufnahmen – Beweismaterial, persönliche Videos, unveröffentlichte Arbeit – repariert werden, ohne irgendwohin kopiert zu werden. Öffne den Reiter Netzwerk (Network), und du kannst bestätigen, dass 0 Byte des Clips gesendet werden.