Jetzt reparieren
- Datei ablegen
- Reparatur läuft lokal
- Ergebnis herunterladen
Android-Telefone — Pixel, Samsung, Xiaomi, OnePlus und der Rest — nehmen Video über die Plattform-APIs MediaRecorder und MediaMuxer auf, die ein Standard-.mp4 im ISO-Base-Media-Container schreiben. Bild und Ton fließen während der Aufnahme in eine mdat-Box, aber das moov-Atom — der Index, der jedes Einzelbild abbildet — wird erst geschrieben, wenn die App am Ende MediaMuxer.stop() aufruft. Erreicht die App diesen Aufruf nie, bleibt dir eine Datei voller gültiger HEVC- oder H.264-Daten ohne Index, und jeder Player verweigert sie. Lege die Datei oben ab, und das Tool prüft genau darauf — in deinem Browser — und baut den Container neu auf, wenn das Material wiederherstellbar ist.
Warum Android ein .mp4 nicht finalisiert
Der Android-Media-Stack ist eindeutig darin, wann eine Aufnahme abspielbar wird. Während der Aufnahme hängt MediaRecorder (oder eine Kamera-App, die MediaCodec + MediaMuxer direkt nutzt) codierte Samples an das mdat an. Das moov-Atom — Sample-Größen, Chunk-Offsets, Timing-Tabellen und die Parametersätze des Codecs — wird im Arbeitsspeicher zusammengesetzt und erst dann ans Ende der Datei geschrieben, wenn stop() und release() laufen. Überspringt man diesen Schritt, sind die Bytes auf dem Datenträger ein kopfloses MP4: echte Einzelbilder, aber keine Karte.
Drei Unterbrechungen lösen das aus. Die Kamera-App ist abgestürzt oder wurde beendet. Ein Fehler — oder Androids Low-Memory-Killer, der unter Speicherdruck eine App im Hinter- oder Vordergrund zurückfordert — beendet den Prozess vor stop(), sodass nichts den Index schreibt. Der Speicher lief während der Aufnahme voll. 4K in HEVC schreibt schnell; wenn der interne Speicher oder die SD-Karte null freie Bytes erreicht, schlägt der Schreibvorgang des Muxers auf halbem Weg fehl und die Datei bleibt ohne moov abgeschnitten. Das Telefon hat sich ausgeschaltet. Ein leerer Akku oder ein erzwungener Neustart während der Aufnahme überspringt die Finalisierung auf dieselbe Weise.
Der Codec darin ist entweder HEVC/H.265 (die Voreinstellung für hochauflösende Modi auf den meisten modernen Android-Geräten, gewählt wegen seiner Effizienz) oder H.264/AVC (die kompatible Ausweichlösung). Das Container-Verhalten ist bei beiden identisch, und deshalb ist der Reparaturweg unabhängig vom Codec derselbe.
Was sich rekonstruieren lässt — und was nicht
Da die Einzelbilddaten im mdat erhalten bleiben, besteht die Lösung darin, den Index zu rekonstruieren, den MediaMuxer.stop() nie geschrieben hat. Das Tool durchsucht den erhaltenen Stream, gewinnt die Grenzen und das Timing jedes Einzelbilds zurück und baut die Sample-Tabellen neu auf, damit ein Player von Anfang an decodieren kann — so wird aus einer kopflosen Datei wieder ein normales, durchsuchbares MP4. Wo die Datei zusätzlich durch einen vollen Datenträger abgeschnitten wurde, rettet es die Einzelbilder, die vor dem Abbruch vollständig geschrieben wurden, und schließt einen abspielbaren Container um sie herum — ein Clip, der 80 % einer Aufnahme erfasst hat, gibt so diese 80 % zurück, statt komplett zu scheitern. All das läuft in deinem Browser, während die Datei aus dem Speicher gelesen wird.
Die ehrliche Grenze ist, dass Einzelbilder, die nach der Unterbrechung geschrieben worden wären, nicht existieren: Ein voller Datenträger stoppt den Schreibvorgang, ein Absturz stoppt den Encoder, und kein Tool kann Bytes erfinden, die nie gespeichert wurden. Wenn nur die abgeschnittene Kopie übrig ist, ist die Rettung der richtige Schritt; liegt die Originaldatei aber noch auf dem Telefon und lässt sich einfach sauber neu kopieren, tu das zuerst, denn eine gute Kopie schlägt jede Reparatur.
Warum ein Clip vom selben Telefon und derselben App hilft
Den Index neu aufzubauen ist am zuverlässigsten, wenn das Tool die genaue Codec-Konfiguration kennt, die die beschädigte Datei ausgelassen hat. Ein intakter Clip vom selben Telefon, aufgenommen mit derselben App im selben Modus, liefert genau das: die HEVC-Parametersätze (VPS/SPS/PPS) oder die SPS/PPS von H.264, dazu Auflösung und Bildrate — sodass die Rekonstruktion das Original nachbildet, statt es nur anzunähern.
In der Praxis: Nimm ein paar entbehrliche Sekunden mit derselben Kamera-App und denselben Qualitätseinstellungen auf und halte sie bereit. Achte darauf, dass der Codec übereinstimmt (eine HEVC-Referenz für einen HEVC-Clip, H.264 für H.264), dann wirst du nur danach gefragt, wenn die Reparatur es braucht. Eine Probe von einem anderen Telefon oder einer anderen App passt in der Regel nicht, weil die Parametersätze sich unterscheiden.
Was sich reparieren lässt und was nicht
Kann repariert werden
- Eine Aufnahme, die die Kamera-App oder eine Video-App nie finalisiert hat, weil sie vor MediaMuxer.stop() abgestürzt oder beendet wurde (fehlendes moov)
- Clips, die abbrechen, weil der interne Speicher oder die SD-Karte während der Aufnahme volllief
- Aufnahmen, die durch einen leeren Akku oder einen erzwungenen Neustart während der Aufnahme unterbrochen wurden
- HEVC- und H.264-.mp4-Dateien, die sich in Google Fotos, der Galerie, VLC oder einem Editor nicht öffnen lassen, obwohl sie echte Einzelbilder enthalten
Kann nicht repariert werden
- Material nach der Unterbrechung: Diese Einzelbilder wurden nie in den Speicher geschrieben
- Eine Datei, die sich nach einem fehlgeschlagenen Kopiervorgang oder einer defekten SD-Karte als 0 Bytes oder größtenteils Nullen liest
- DRM-geschützte oder verschlüsselte Inhalte
- Ein beschädigter HEVC-Clip ohne passende HEVC-Referenz vom selben Telefon und derselben App
Wenn eine Reparatur fehlschlägt, sagen wir dir warum (fehlende Daten gegenüber beschädigter Struktur), und für eine fehlgeschlagene Reparatur wird dir nie etwas berechnet.