mkvmerge - Tonspur muxen geht nicht - Bitte um Hilfe!

Eigentlich nur, dass ich Mosu mal hierauf aufmerksam mache - der bastelt ja die mkvtoolnix zusammen, da wird er sicher auch wissen, wer sich das mal näher anschauen kann, bzw. was für Informationen er dafür noch braucht.

Meine Laien-Analyse so weit: Wenn malloc() ein NULL zurückliefert, dann konnte wohl nicht genug RAM bereitgestellt werden, damit mkvmerge sich das alles merken kann, was es zu tun hat... Da fehlt allerdings noch das Wobei und Warum.

Zitat

Meine Laien-Analyse so weit: Wenn malloc() ein NULL zurückliefert, dann konnte wohl nicht genug RAM bereitgestellt werden, damit mkvmerge sich das alles merken kann, was es zu tun hat...

Das stimmt soweit, ist aber nur das Symptom, nicht die Ursache.

Vorsicht, langer Text mit Erläuterungen zu den Innereien von mkvmerge folgt Lösungsansätze fangen im vorletzten Absatz ab "Was kannst du nun tun?" an.

mkvmerge merkt sich im Lauf des Muxes jede Menge Dinge. Dazu gehören z.B. die Position der einzelnen Cluster für den Index. All diese Datei sorgen dafür, dass mkvmerge im Laufe des Muxvorganges immer mehr Speicher benötigt. Allerdings ist dies im Normalfall recht wenig speicher. Bei mehreren GB an Daten, die es zu muxen hat, sollte mkvmerge am Ende des Muxprozesses eigentlich nicht mehr als vielleicht 100 MB an Hauptspeicher benötigen -- das ist also nicht der Grund.

Was ich schon häufiger hatte, sind aber andere Gründe bzw. Bugs, die dazu führen, dass mkvmerge ungehemmt Speicher frisst.

Um die Zieldatei richtig muxen zu können, müssen ja alle Pakete nach ihrem Zeitstempel sortiert in die Ausgabedatei geschrieben werden. mkvmerge versucht dies, durch Puffern der Eingabedaten sicherzustellen. Nun kann es mehrere Situationen geben, in denen dieses Puffern dazu führt, dass mkvmerge immer mehr Speicher frisst.

1. Matroska-Quelldateien mit riesigen Lücken in Tracks. Wenn eine Quelldatei in einem Track, z.B. einem Untertiteltrack, sehr lange Zeit lang keine Pakete enthält, so liest mkvmerge diese Quelldatei immer weiter und immer weiter auf der Suche nach einem Paket dieses Tracks. Die dabei gefundenen Pakete der anderen Tracks werden alle gepuffert, sodass mkvmerge dafür sehr viel Speicher allokiert.

Dieses Phänomen versuche ich mit zwei Maßnahmen zu begrenzen: hat mkvmerge auf der Suche nach einem Untertitelpaket 20 MB gepuffert, so wird angenommen, dass hier eine Lücke ist, und die Suche wird beendet. Für Audio- und Videotracks liegt diese Grenze deutlich höher, nämlich bei 512 MB.

Insofern vermute ich, dass das bei dir nicht zutrifft.

2. Eine weitere Möglichkeit sind überlaufende Zeitstempel. Mir ist das zuletzt bei sehr großen PCM-Dateien passiert. Intern rechnet mkvmerge mit 64bit Integerwerten für die Zeitstempel. Das mag viel klingen, aber die Zeitstempel haben ja auch Nanosekundenpräzision. Für die Zeitstempel bei PCM bedeutet das z.B., dass sich der Zeitstempel wie folgt berechnen lässt:

Anzahl_gelesener_Bytes * 1000000000 / Anzahl_Bytes_pro_Sekunde

Nun ja, diese simple Berechnung hat schon bei 8GB-Dateien dafür gesorgt, dass ich einen Integerüberlauf hatte, wodurch die Paketsortierung gründlich in die Hose ging, mkvmerge unheimlich viel gepuffert hat und der ganze Prozess dann irgendwann abbrach.

So etwas könnte ich mir bei dir ebenfalls vorstellen, nur halt mit anderen Tracks.

Was kannst du nun tun? Als Erstes musst du mal rausfinden, welche(r) Track(s) die Probleme hervorrufen. Versuche nacheinander, jeden Track nur einzeln zu muxen, also alle anderen zu deaktivieren. Schau dir danach mit mkvinfo die Zeitstempel der Zieldatei an. Es sollte reichen, jeweils mit gesundem Menschenverstand die Zeitstempel am Ende der Datei anzuschauen -- wenn die überlaufen, dann sind sie natürlich deutlich kleiner als die Gesamtlänge der Ursprungsdatei.

Ja, das ist ein ziemlich langwieriger Prozess. Aber nur so werde ich dann später den Bug finden können, fürchte ich, weil ich hier leider überhaupt keine so großen Dateien zum Testen habe.