Fehlerhafte Aufnahmen reparieren

Mein Tipp: wenn alles fehlschlägt - so lange VLC es abspielen kann, kann man es mit diesem auch neu kodieren (z.B. x264 lossles)

Ansonsten kann man sehr schnell mit ffmpeg neu muxen

ffmpeg -i input.avi -c:v copy -c:a copy output.avi

der Container wird durch die endungen bestimmt so kann z.B. auch mov in mp4 gemuxt werden oder so:

ffmpeg -i input.mov -c:v copy -c:a copy output.mp4

@GrandFiredust
Die Struktur konnte ich schon wiederherstellen. Nur der Video Stream war nicht in Ordnung.

Sprich ich konnte den Videostream nicht dekodieren, da hat er sich aufgehangen. Entweder war es der falsche Farbraum, falsche Einstellungen des Codecs oder whatever.

Weil alle Angeben zur Dekodierung des Videos im VideoStream Header stehen in der AVI.

Mit anderen Worten bei dir hat der ULH2 Codec von UTVideo vllt. gar nicht gestimmt.

Ich kann mir jetzt 3 Sachen vorstellen.

• Entweder hat der UTVideo Header nicht gepasst zwecks falscher Farbraum, Farbmatrix, Encodierungsmethode
• oder die Indextabelle war so beschädigt am Ende das der Video Datenblock nicht decodiert werden konnte und es halt falsche Adressen gab dadurch.
• Der Video Datenblock war beschädigt und die Indextabelle in Ordnung. Was dann halt auch zum Crash führt, da auch hier falsche Adressen von der Indextabelle zum Video Datenblock zugeordnet sind.

Eine Indexrekonstruktion von AVI Files geht nur, wenn bestimmte Angaben noch vorhanden sind. Entweder im Header oder in eines der Index Tabellen am Ende der Datei.

Bei einem Lossless Video geht meist der Austausch des Headers, da die Frames meist alle I-Frames sind. Halt Schlüsselbilder und diese somit auch gleiche Index Muster auch haben.

Wie gesagt, Audio war ja bei dir noch komplett Intakt gewesen bei dem File. Nur der Videostream nicht. Entweder beschädigter Datenblock oder falsche Indextabelle schon.

Daher: Wenn eine Datei Defekt sein sollte, nicht einfach blöd den Header austauschen. Wenn, dann macht lieber eine Sicherheitskopie des Headers den ihr überschreibt. Weil wenn es nicht gehen sollte, kann man die Ursprüngliche Datei wiederherstellen und das Problem anders angehen.

Ansonsten ist das wirklich wie eine Nadel im Heuhaufen.

PCM Audio auszulesen ist z.B. kein Ding. Das Teil ist unkomprimiert und hat somit eine feste Größe. Aber UTVideo ist ein Kompressionscodec. Und wenn da bestimmte Infos fehlen, aber zum Video notwendig sind, dann kann man nur raten.

Zitat von GrandFiredust

Niemals die kaputte AVI Datei löschen nachdem man eine neue mit dem Hexeditor erstellt hat.

Wieso?

Die Methode einfach einen neuen Header in die kaputte Datei zu kopieren und auf gut Glück durch Virtual Dub indexieren zu lassen ist sehr unsicher und kann im Zweifelsfall dem Video noch mehr Schaden zufügen als vorher, sodass es komplett unabspielbar ist.
Das Problem an der ganzen Sache ist, dass nicht jede kaputte AVI gleich ist und ganz verschiedene Gründe haben, warum sie nicht abspielbar sind. Bei manchen fehlt der Header komplett, bei anderen nur ein Teil oder es liegt ein ganz anderes Problem vor.

Wo sind die Nachteile an der von De-M-oN/Sem erstellten Methode?

• Wenn man z.B. eine fehlerfreie 10sek Aufnahme nimmt, um dort den Header in die kaputte 1-2h Aufnahme zu kopieren kann es sein, dass der Header gar nicht zu der Aufnahme passt. Ab einer gewissen Dateigröße kann ein anderer Headertyp genutzt werden, was bedeutet dass das kaputte Video nichts mit dem neuen, nicht passenden Header anfangen kann.
• Die Zeit kann ebenfalls falsch sein und kann auch nicht durch VirtualDub wieder aus dem Stream-Header herausgelesen werden. Wenn man also einen Header von einer 30min Aufnahme in ein 1h Video reinsetzt, dann indexieren Programme wie VirtualDub nur bis 30min und erkennen das restliche Video nicht.
• Wenn man richtig Pech hat, dann sind die Indexverweise durch den neuen Header durcheinander gekommen. Dann kann kein Programm mehr die Datei rekonstruieren. Wenn man das technische Wissen dahinter hat, kann man den AVI-Header/Container im Hexeditor entschlüsseln und versuchen dort die Daten manuell zu reparieren. Wenn man aber auch der codecinterne Videoheader fehlerhaft ist, dann ist das die Suche nach der Nadel im Heuhaufen.

Was ich damit sagen will ist nur, dass diese "Standardmethode" nicht immer funktioniert und dass man, wenn man sich mit der Materie nicht auskennt, vielleicht eher zu weniger radikalen Methoden greift und einen Profi über die defekte Aufnahme drüberschauen lässt.
Erspart einem sehr viel Arbeit und Nerven...

Alles anzeigen

Virtualdub findet bei weitem weniger als l-smash oder ffmpeg/ffms2. Aber das wäre für den Laien deutlich schwieriger.

Punkt 2 kann ich dir allerdings in keinsterweise zustimmen. Ich nahm als Reperaturdatei meist nur wenige Sekunden und das ging.

Und selbstverständlich sollte der Header nicht überschrieben werden, wenn einer existent ist. Das ist eig. klar.

Zitat von GrandFiredust

Laut SagaraS lag das daran dass im neuen Header nicht genug Bits zur Verfügung standen für eine große Zeitangabe - wenn ich mich richtig erinnere.

Nein. Da habe ich es nur geschätzt, weil ich mich gewundert habe das nicht mehr zur Verfügung stand, aber die AVI arbeitet ja ganz anders.

Funktionieren tut es wie folgt:

Segment1 - ca. 1GB
Segment2 - ca. 2GB
Segment3 - ca. 2GB
usw. mit 2GB

2GB = 2147483648 Byte = 8000 0000 Hex

Und dann passt das schon mit jeweils 4 Byte für die Größenangabe.

Jedes Segment steht für sich selbst, bezieht aber seine Infos aus einem Header.

Das heißt du kannst die Segmente mit den jeweiligen allgemeinen Header auch so aufspalten.

Hmm... Ist das normal?

Ich hab ein kaputtes Video. Ich weiß nicht, wie es passiert ist. Ich hab die Aufnahme beendet, dann ist beim Schließen das Spiel abgesoffen. Irgendwie lässt sich nun die Datei nicht öffnen (war MSI AB).

Ich hab es jetzt in den Hex Editor gepackt, aber die fehlerhafte Videodatei scheint eine Million Zeilen Kode zu haben, bis movi00 kommt! Kann das sein? Mir tun die Finger weh...

Aaah, vielen Dank! So hat es funktioniert, ohne dass ich hier bis Mitternacht sitze. Danke.