MKV läuft nach splitting nicht mehr

**MrMADDY** · 17. 04. 2011, 19:19

Hallo liebes Forum,

habe schon ewige Stunden mit der Suche auf diversen Plattformen verbracht und finde leider keine Lösung für mein Problem.

Meine Hardware: LG HB905SP Heimkinosystem.

Problemstellung: Sämtliche MKV-Dateien (Videos, meist 1080p oder 720p mit 5.1-Ton) laufen zunächst problemlos über USB-Stick oder direkt per LAN. Wenn ich die Dateien jedoch archivieren möchte, ist oftmals ein Splitten in zwei Teile nötig, damit sie auf eine DVD9 passen. Dies mache ich mit mkvmerge. Ich gebe einfach dann die entsprechende Dateigröße an und verändere sonst nichts. Manchmal entferne ich noch Tonspuren die ich nicht brauche, aber das scheint keinen Unterschied zu machen bezogen auf das Endergebnis. Nach dem Muxen ist dann die Datei auf dem BluRay-Player nicht mehr abspielbar. Er versucht, die Datei zu öffnen, nach wenigen Sekunden schwarz auf dem TV lande ich jedoch wieder im Player-Menü.

Was läuft hier also falsch bzw. was kann ich tun? Meiner Einschätzung nach verändert sich doch an der MKV-Datei an sich nichts, bis auf die Aufteilung auf zwei Dateien?

Danke schonmal für Tipps und Hilfe.

Grüße
Maddy

**Terminator20** · 17. 04. 2011, 20:19

Ds liegt daran das die zlib Headerkomprimierung standardmäßig aktiviert ist, die musst du abstellen, geh einfach in mkvmerge auf komprimierung und stell auf "keine" dann läufts

**MrMADDY** · 17. 04. 2011, 22:25

Zitat von Terminator20

Ds liegt daran das die zlib Headerkomprimierung standardmäßig aktiviert ist, die musst du abstellen, geh einfach in mkvmerge auf komprimierung und stell auf "keine" dann läufts

Genau das war es. Hab es eben getestet und nun funktioniert es. Vielen vielen Dank!

Thema somit erledigt, Thread kann geschlossen werden.

LG
Maddy

**Brother-John** · 17. 04. 2011, 22:45

Der Vollständigkeit halber: zlib-Kompression (für manche Untertitelformate) und Header-Kompression (für Audio/Video) sind zwei komplett unterschiedliche Sachen. Die Header-Kompression ist die, die den Stress macht. Kann man in den Optionen auch global abschalten: »Disable header removal compression...«

**Claymore** · 18. 04. 2011, 03:30

@B-J: Nachdem du ja mehr in den Foren wie doom9 und Gleitz unterwegs bist: Hast du eine Erklärung, weswegen dieser (meiner Meinung nach) Nonsens überhaupt eingebaut wurde? Viel bringt es ja nicht (soweit ich das bisher selbst getestet habe). Auch wenn es hin und wieder ein paar MB bringen sollte - so haben doch vermehrt auch neuere Abspielgeräte nur Probleme damit.
Weiters stellt sich mir die Frage, warum die Komprimierung standardmäßig aktiviert ist. Dieses Feature sollte meines Erachtens nach deaktiviert und nur per Benutzerhand - also manuell - anwendbar sein.

mfg Claymore

**Brother-John** · 18. 04. 2011, 18:16

Ich kann da auch nur spekulieren. Müsstest du Mosu fragen, warum er’s eingebaut und sich so lange komplett gehen einen globalen Schalter dafür gewehrt hat. Es steht jedenfalls in den Matroska-Specs, von daher kann man MKVToolnix erstmal keinen Vorwurf machen, wenn es das auch benutzt. Und wer sich »Matroska« auf die Fahnen resp. Player schreibt, sollte halt auch mit dem Container zurecht kommen.

Deswegen kann ich es schon verstehen, dass die Kompression nach wie vor standardmäßig aktiviert ist. Ich würde mich auch nur ungern der Trägheit und Gleichgültigkeit der Playerhersteller unterwerfen.

**Claymore** · 18. 04. 2011, 18:31

Nunja. Der Speicherplatzgewinn hält sich in keiner Relation zur Mehrdauer des Muxens. Mindestens mit aktivierter Komprimierung kann es durchaus sein, dass die Fertigung mindestens 1/3 länger dauert, als ohne. Ich mache MKVToolnix keinen Vorwurf - da würde ich mir ins eigene Bein schießen. Was wäre ich ohne

.
Werde dann auf deinen Ratschlag eingehen, und direkt nachfragen. Normalerweise sollte es ja irgendwo geschrieben stehen, weswegen man bereits hochkomprimierte Daten nochmals komprimieren soll (Untertitel sind davon ausgenommen, da meist in SRT und folglich unkomprimiert). Eine Spekulation wäre, dass die Titelsuche eventuell durch die Headerkompression beschleunigt wird, da weniger Daten übertragen werden müssen. Eine andere Theorie wäre, dass es ein Vorbote auf die Menüfunktion sein kann - da würde es eventuell wirklich eine Beschleunigung geben. Aber ob das Komprimieren der Audio- & Videospur wirklich dermaßen viel bringt? Bin mir da ziemlich unsicher ob der Relevanz.

Naja, wie gesagt: Nachfragen bringt hoffentlich eine Klärung, falls sich da nichts sinnvolles finden lässt. Ob mir die Antwort jedoch gefallen wird, steht natürlich auf einem komplett anderen Blatt. Vielen Dank jedenfalls für deine Antwort, B-J

.

mfg Claymore

**doc-mabuse** · 19. 04. 2011, 15:26

Zitat von Claymore

Der Speicherplatzgewinn hält sich in keiner Relation zur Mehrdauer des Muxens. Mindestens mit aktivierter Komprimierung kann es durchaus sein, dass die Fertigung mindestens 1/3 länger dauert, als ohne.

Bitte?

Es macht bei mir überhaupt keinen Unterschied.
Die Header sind doch nur ein handvoll Byte groß, das diese Komprimierung nennenswert Zeit bräuchte, wäre nur ein Zeichen, das der Rechner hoffnungslos veraltet ist.

Zugegeben: Bringen tut's auch nichts, einstellige kB bei Filmen um ein GB . . .

Und alle Player mit dem Sigma-Chipsatz verstehen's nicht, und so wie ich die Sache sehe ist das der derzeitige Standard.

**eikira** · 12. 01. 2012, 13:38

Bringen tut es schon was.
Wenn man bei audio und video zlib wählt spart man 3-5% Speicherplatz.

Das dumme daran ist halt wirklich dass einige Player dann ihr wahres Gesicht zeigen und mit MKV doch nicht so viel anfangen können wie sie behaupten.

**Brother-John** · 12. 01. 2012, 14:07

Zitat von eikira

Wenn man bei audio und video zlib wählt spart man 3-5% Speicherplatz.

Audio und Video? Sicher nicht. Wenn du dort zlib erzwingst, wird die Datei eher größer als ohne. Auf die eh schon komprimierten Spuren noch einen zusätzlichen Komprimierer draufzuschmeißen, macht keinen Sinn.

Das einzige, was sich sinnvoll komprimieren lässt, sind die typischen Grafikuntertitel. Für Vobsubs ist zlib auch standardmäßig aktiv. Komprimierbarkeit gilt auch für PGS, ich weiß aber nicht, ob für die auch zlib Standard ist.