ZitatMeinst Du mit "meine" Deine von Dir erzeugten BluRays oder die von Dir gekauften?
Wahrscheinlich meint er die,die er sich aus dem hintern gezogen hat.
Was soll er wohl meinen?
ZitatUnabhängig davon meine ich, dass es sicher nicht falsch wäre, wenn Du Dich bezüglich Deines Problemes an die Macher von MKVmerge wenden würdest.
Oh, das wird sicherlich ungemein weiterhelfen! :wacko:
Also wenn Du von nichts Ahnung hast, den solltest Du keine Beiträge schreiben.
Mosu hat eh sein forum dicht gemacht.
Zurück zum Thema das Problem besteht auch bei der 32Bit version von Windows.
Ich habe ein MKV mit MKVToolnix6.0.0 Remuxt. Das original hat das Problem nicht beim Remux friert es wie oben beschr. ein.
Allerdings nach einigen minuten läuft es weiter. Wenn das MKV Kapitel hat und man gleich zu begin in das letzte Kapitel springt, und einige minuten wartet (bis das einfrieren vorüber ist) dann läuft es auch mit dem MKV wieder normal.
Der Grund dafür ist ein BUG in VCL
(Two tickets have been opened in VLC's bug tracker for this issue: 7884 and 7887.)
Nähres unten (das Englische).
Wer nicht so gut Englisch kann oder einfach eine schnelle Antwort will..hier ist Sie:
Entweder mit MKVToolnix 5.8.0.0 muxen oder in VCL Player folgende Einstellung machen:
Einstellungen Alle -> Input/Codecs -> Demuxer -> Matroska -> Bei Dummys ein haken setzen
Playback does not work at all or seeking does not work with files created by mkvmerge 5.9.0
The problem
Two symptons:
- A player (mostly hardware devices like DVD or BluRay players) cannot play back a file muxed with mkvmerge 5.9.0 and later.
- VLC cannot seek properly (or not at all) anymore with files created by mkvmerge 5.9.0 and later.
In both cases muxing with 5.8.0 fixes the issue.
Reason and solution
This is a bug in your player VLC and not in mkvmerge. For both symptoms tt can be circumvented when creating the file with mkvmerge, and for VLC there's even a runtime option you can change in order to fix playback.
Starting with v5.9.0 mkvmerge writes two new elements that have recently been added to the Matroska specification: CueDuration and CueRelativePosition. While CueDuration is only written when a block's duration does not equal its default duration (e.g. with subtitles), CueRelativePosition is always written.
Unfortunately VLC and several other hardware players do not skip unknown elements by default. In VLC you can turn it on in VLC's preferences (the option is called "Dummy elements"). This causes VLC to abort reading the file at the very start of the cues resulting in not being able to seek (properly) in such a file.
Rationale for adding those two elements was actually to improve seeking in files by providing players exact locations where to seek to. The rationale is explained in two threads on the Matroska devel mailing list: for CueDuration and CueRelativePosition.
Workaround during playback with VLC
Turning on "Dummy elements" fixes this immediately; now seeking works as it has before. You can do that in VLC here see screenshot
Tools -> Preferences -> "Show settings: all" at the bottom left;
In the tree on the left side: Input/Codecs -> Matroska; make sure
"Dummy elements" is turned on.
Two tickets have been opened in VLC's bug tracker for this issue: 7884 and 7887.
Workaround with mkvmerge until player is fixed
You can prevent mkvmerge from writing these elements in the first place. This will make the file layout identical to the one written by 5.8.0.
See the corresponding FAQ entry.