Sebstgebrannte BD kann nicht mehr vollständig gelesen werden

Started by Gloster, May 13, 2020, 10:29:52 PM

Previous topic - Next topic

Gloster

Mein Lösungsansatz bis dato :
1. Ein Image der BD erzeugen
2, Mit Hex-Editor das Image bis zum ersten sync Byte (0x47)einschließlich 4 Byte Präfix gelöscht.
3. Avidemux zum abspielen des Image verwendet
4. Avidemux kann den ersten Film einwandfrei abspielen

Leider bricht Avidemux nach dem ersten Film ab und leider sind immer die Filme am Rand der BD betroffen, das heißt die letzten Filme in der Playlist (mehrfaches reinigen der BD hat nicht geholfen).
Ich habe mir damit geholfen, das ich aufgrund von Abschätzungen Teile des Image gelöscht habe (wieder bis zum nächsten sync Byte usw. ). Mit Avidemux den Rest des Image abgespielt usw., bis ich den Film hatte, den ich retten wollte. Bei einem 23G Image ist das mühselig. Ich habe die geretteten Filme dann nur noch ein wenig mit Avidemux nachbearbeiten müssen.

So, nun meine Frage : Ist es möglich Avidemux so einzustellen, das es am Ende des ersten Films nach weiteren Filmen im Image sucht, also z.B. das nächste I-Frame ?

Hinsichtlich recovery Tool Tips bin ich reichlich versorgt.




eumagga0x2a

Ein Image – also ein Abbild des Dateisystems (UDF) einer Blu-ray-Scheibe? Wenn das so ist, dann ist dieses Image zu mounten, um die eigentlichen Dateien daraus an Anwendungen weiterzureichen. Das ist keine Aufgabe von Avidemux, das tut ein Dateisystemtreiber (gerne in userspace).

Oder geht es um das virtuelle Zusammenfügen von gestückelten Dateien? So wie viele Receiver Aufnahmen binär in 4 GiB große (plus ein kleinerer Rest) Fragmente aufsplitten, um die maximale Dateigröße von FAT32 nicht zu überschreiten – Avidemux lädt solche klar definierten, an ihrer Größe und sequenziellen Namen erkennbaren Fragmente als eine einzige Datei. Meines Wissens aber sind Videodateien auf Blu-rays keine Fragmente eines kontinuierlichen Datenstroms.

Gloster

Komplette Filme können nicht mehr gelesen werden. Brenn ein BD, lass diese 10 Jahre liegen und du hast das gleiche Problem.
Weder das mounted Image noch ein Datei explorer zeigt das entsprechen m2ts File an. Das weist auf einen Fehler in der FAT der BD hin. Das Image enthält aber den Film, bzw. das m2ts file.
Das Image enthält von oben nach unten gelesen z.B. 5 Filme. Avidemux liest aber nur die erste m2ts Datei ein.
Offensichtlich sind zwischen den Filmen keine "m2ts frames", vermutlich Steuerungen, wie zurück zur Playlist. Was auch sonst, sonst könnten die Filme nicht einzeln abgespielt werden.

Und ich fragte nach der Möglichkeit, das Avidemux diesen "Framelosen" Übergang in der Datei, dem Image, überliest und einfach nach dem nächsten I-Frame sucht, und das dann wieder im Monitor anzeigt (es ist eigentlich das was ich manuell gemacht habe).

Man hätte ein recovery tool mit Monitor

eumagga0x2a

Quote from: Gloster on May 14, 2020, 04:41:57 PM
Und ich fragte nach der Möglichkeit, das Avidemux diesen "Framelosen" Übergang in der Datei, dem Image, überliest und einfach nach dem nächsten I-Frame sucht

Es wäre einen Versuch wert, Avidemux aus dem Quelltext zu kompilieren (das ist trivial unter Linux) und zuvor den als MAX_SEARCH definierten Wert in avidemux_plugins/ADM_demuxers/MpegTS/dmxTSPacket.cpp:167 von jetzigen 2048 (2 kiB) anzuheben.

Ob es funktioniert und wie hoch MAX_SEARCH dafür sein muss, müsste ausprobiert werden.

Gloster

Mit https://avidemux.org/smif/index.php?topic=18371.0 und git submodule update --init --recursive
habe ich fehlerfrei compilieren können.
Called via  sh run_avidemux_template.sh brachte nicht das gewünschte Ergebnis. ich habe zwar kein Videosignal, ist jetzt aber nebensächlich.
Avidemux bricht nach wie vor nach dem ersten Film das "scannen" ab.
Der "Film-Zwischenraum" von etwa 10k ist offensichtlich nicht das Problem. Ich habe aus einem Image den ersten Film gelöscht und den "Zwischenraum" im Image gelassen. Avidemux (original) scanned den 2. Film einwandfrei aus dem restlichen Image.
In der Doku H.222 (ITU-T) habe ich bis dato auch nichts finden können.
Aber ich vermute im Stream des Films eine Art "EOF" Information.


eumagga0x2a

Welche Werte für MAX_SEARCH wurden bis dato ausprobiert? Die müssen natürlich höher sein als der Zwischenraum zwischen den Dateien.

Ein Problem dürfte allerdings selbst im Fall einer erfolgreichen Überbrückung dadurch entstehen, dass die Zeitstempel in der zweiten Datei bestimmt wieder zurückgesetzt sind statt die von der ersten nahtlos fortzuführen.

Gloster

Mehrere Versuche von 100000 - 500 000 000 weil ich zwei Fliegen mit einer Klappe schlagen wollte um nicht mehr einen Hex-Editor einzusetzen.
Im Image ist ein Offset von etwa 450 MB bis zum 1. Film, das hatte ich noch nicht angesprochen. Bis dato habe ich den Offset immer gelöscht.
Wenn ich den Offset nicht lösche, bekomme ich auch mit der Einstellung MAX=500 000 000 nach wie vor die Meldung "Demuxer konnte nicht gefunden werden", d.h. beim einlesen der Datei ist offensichtlich eine andere Stelle im code relevant.

Wie gesagt, ich habe etwa 5 Frames vom vorherigen Film gelassen, trotzdem wurde der folgende Film einwandfrei scanned.
Ich werde mal 10MB vom vorherigen Film belassen, mal sehen was dann passiert.


eumagga0x2a

Quote from: Gloster on May 17, 2020, 11:14:47 PM
Wenn ich den Offset nicht lösche, bekomme ich auch mit der Einstellung MAX=500 000 000 nach wie vor die Meldung "Demuxer konnte nicht gefunden werden", d.h. beim einlesen der Datei ist offensichtlich eine andere Stelle im code relevant.

Richtig, das wird mit PROBE_SIZE aus avidemux_plugins/ADM_demuxers/MpegTS/ADM_tsPlugin.cpp:46 geregelt, und dieser Wert darf nicht beliebig über 1 MiB hinaus erhöht werden, denn das ist die Größe des Puffers, den Avidemux zum Einlesen der Datei beim Betriebssystem mit dem Operator new [ ] anfordert – Fehler also nicht vorgesehen.

Ich schätze, es läuft alles darauf hinaus, weiterhin mit dd (oder wie zuvor direkt mit einem Hexeditor) die interessanten Teile aus dem Image von einem Offset beginnend (bs=<units> skip=<offset in units> count=<length of output in units>) in eine neue Datei zu schreiben.

Gloster

Ich habe mir die Stelle angeschaut. Der Input Buffer muss nicht erhöht werden, nur das Abbruchkriterium für diesen speziellen Fall angepasst werden. Leider ist auch das nicht ausreichend, d.h. ohne Debugger Möglichkeiten kein Weiterkommen.
Ich habe zum Aufbau einer IDE usw. folgendes gefunden : https://avidemux.org/smif/index.php?topic=16298.0
Mein gegenwärtiges Konzept :
1. Globales Flag einführen um die Änderungen nur für "recovery TS-File" einzuschalten (evtl. Menu Werkzeuge Eintrag usw.)
2. Der TS-scan müsste für alle Filme nacheinander erfolgen, .evtl mehrere idx-files erzeugen lassen, alle sichtbaren Filme werden verworfen(user Input) und nur den in der FAT nicht eingetragenen Film scannen lassen mit abschließender Speicherung.
Alles in Allem keine Programmierarbeit von 5 Minuten.
Alternativ habe ich mein Verfahren verbessert :
1. Den letzten "sichtbaren Film" im Hex-editor einlesen, von diesem den Anfang vom letzten Frame kopieren,z.B.:  37 0B 99 6B 47 18 A6 1E 88...
2. Im gesamten BD-Image mit einem Hex-Editor (gute Ergebnisse mit HxD erzielt) den Hex-String suchen und alles darüber im Image löschen. Ich weiß nicht ob es möglich ist mit "dd" einen String, s.o. zu suchen wie mit dem HxD tool und bis zu dieser Stelle ein "skip" einzutragen. Auf jeden Fall muss der skip Eintrag auf +/- 10k genau sein.
3. Mit Avidemux dann das Rest-Image einlesen und einfach scannen lassen mit anschließender Nachbearbeitung.