mkv weiterentwicklung und abspielprobleme...

Welche Version funktioniert denn als letzte? Dann kann man es vielleicht anhand des Changelogs eingrenzen.

Neu ab 5.9.0 ist (was man auch abschalten und testen kann):

* mkvmerge, mmg: enhancement: Added options for turning off
writing "CueDuration" elements ("--engage no_cue_duration") and
"CueRelativePosition" elements ("--engage
no_cue_relative_positions").

Probier das mal aus, auch wenn es nicht sehr wahrscheinlich klingt.

mfg

Zitat von monarc99

* mkvmerge, mmg: enhancement: Added options for turning off
writing "CueDuration" elements ("--engage no_cue_duration") and
"CueRelativePosition" elements ("--engage
no_cue_relative_positions").

Probier das mal aus, auch wenn es nicht sehr wahrscheinlich klingt.

Doch, ich vermute, Du liegst mit Deinem Tip richtig. LG und Sony (sowie einige Software-Player wie VLC) scheinen damit teilweise Probleme zu haben.

Ne, changelog ist i.d.R. ja auch ausreichend.
Wenn Du so eine Liste erstellst und die Mosu schickst denke ich aber, dass er sie durchaus mit ins mkvtoolnix Wiki übernehmen würde.

Zitat von 3ds

Nun könnte ich die FAQ weiter durch gehen und eine Optionen nach der anderen durch probieren. Aber so richtig Lust habe ich dazu nicht.

Und? Hast du Lust dazu, einfach bei der letzten "funktionierenden" Version zu bleiben, statt sinnlos jedes Update mitzumachen? Mal abgesehen davon, kann man die neuen Features auch per Kommandozeilen-Paste in den neuen Versionen abstellen.

eventuell mag der Player auch keine simple blocks, audio lacing oder clusters im meta seek Teil,...
Bei https://trac.bunkus.org/wiki/FAQ%3AImp…lityWithPlayers stehen eigentlich immer eventuelle Optionen die Probleme mit Hardwareplayern machen könnten,...
--engage no_cue_duration
--engage no_cue_relative_position
--engage no_simpleblocks
--disable-lacing
--clusters-in-meta-seek
wären neben er header compression die typischen Optionen auf die man achten muss, wenn man für HardwarePlayer muxed,...

Zitat von 3ds

Nicht updaten verschiebt ja nur das eigentliche Problem...

Und welche wären das bei Dateien, die du mit 5.x gemuxt hast?

Zitat

IMHO wäre es besser, wenn die matroska Jungs Versionen verwenden und neue Features an diese Koppeln

Du wirst da die Matroska Spezifikation und die Features von mkvtoolnix durcheinander.

Zur Matroska Spezifikation:
Unter http://matroska.org/technical/specs/index.html werden alle existierenden Elemente von Matroska Dateien aufgeführt und wie man bei http://matroska.org/technical/specs/notes.html sehen kann, wird durch die Spalten auch klar welches Feature ab welcher Version in Matroska erlaubt ist bzw. existiert.
Mehr kann man, meiner Ansicht nach, doch eigentlich nicht verlangen.
Das Problem ist, dass die meisten (alle?) Hersteller sich nicht darum scheren und vermutlich keine der Spezifikationen richtig (= funktionierend und komplett) unterstützen, weshalb sie so etwas wie 'Matroska v3 - kompatible' nicht in ihre Spezifikationen der Geräte schreiben können.

Zu mkvtoolnix:
Ich stimme Dir zu, dass wenn die Hersteller es schaffen würden zu sagen, dass ihr Gerät voll kompatible zu Matroska Version X ist es sicher eine nette Option wäre, wenn man in z.B. mkvmerge einstellen könnte, dass ein file erstellt werden soll, welches Version X entspricht.

Bin mir nicht sicher, vermute aber, dass

|+ Doc type: matroska|+ Doc type version: 2|+ Doc type read version: 2

bei einem:

mkvinfo "pfad zu einem mkv file"

angibt welche Spezifikation das File verwendet.
Man könnte also zu einem existierenden File durchaus sehen welcher Spezifikation es entspricht.
Das einzige was Mosu (der MkvToolnix-Entwickler) machen könnte wäre eine Option in mkvmerge einbauen, welche sicherstellt, dass der Output zu Matroska Version X kompatibel ist.
(ich mach mal einen entsprechenden Eintrag im Matroska-Tracker gemacht: https://trac.bunkus.org/ticket/858#ticket)

=> meiner Ansicht nach ist das Problem aber wie gesagt nicht bei den Matroska/mkvtoolnix Entwickler(n) sondern viel mehr bei den Hardware-/Playerherstellern, welche einfach keinen guten Job machen.

Zitat

Aber so führen die einfach irgendwelche neuen Sachen ein und mal sehen ob es denn klappt... Das ist aus Anwendersicht irgendwie murks..

Ist der einzige Weg wie man Leute dazu bekommt sich mit Matroska/mkvtoolnix genauer zu beschäftigen.
Und ich bin mir sicher, wenn die Hardwarehersteller wirklich ehrlich sagen könnten, dass ihr Gerät die komplette Spezifikation X von Matroska unterstützt Mosu, das gewünschte Feature des 'Kompatibilitätserzwingens' implementieren würde.

Cu Selur

Das Problem ist, daß viele der aktuellen Features eigentlich auch mit älteren Playern kompatibel sein müßten. Als die Probleme mit der "Header Removal Compression" losgingen, war das Feature auch beileibe nicht neu, sondern mkvmerge hat es nur standardmäßig für einige Formate aktiviert. Hier wäre weniger wohl mehr gewesen, weil der Nutzen des Features derart minimal ist, daß man es der Einfachheit halber lieber hätte weglassen werden sollen.
cue_duration und cue_relative_position hingegen sind tatsächlich neu und wurden von den Opus-Entwicklern gefordert, bringen aber auch Vorteile für z.B. Untertitel. Allerdings ist Matroska so ausgelegt, daß Player unbekannte Elemente einfach ignorieren sollten, und wie man sieht, haben auch viele Player keinerlei Probleme mit den neuen Dateien: z.B. LAV oder die Samsung-Geräte, obwohl diese neuen Elemente für sie unbekannt sind. Über die Matroska-Version wird man das Problem nicht lösen können, weil die Features bzw. die Kompatibilität nicht unbedingt an Versionen gebunden sind. Ich gehe daher davon aus, daß Mosu das Ticket als "Invalid" schließen wird.

Zitat von 3ds

Doch woher kamen eigentlich meine Probleme?

Das hab ich dich weiter oben schon gefragt, aber ich kann es ja gerne noch mal machen: Welchen Grund hattest du, auf die neue MKVToolnix-Version zu wechseln, obwohl dir die 5.8 lauffähige MKVs erstellt hat?

Zitat von sneaker2

cue_duration und cue_relative_position hingegen sind tatsächlich neu und wurden von den Opus-Entwicklern gefordert, bringen aber auch Vorteile für z.B. Untertitel.

Welche zum Beispiel?

Zitat von sneaker2

Ich gehe daher davon aus, daß Mosu das Ticket als "Invalid" schließen wird.

Ich auch.

Zitat von Chetwood

Welche zum Beispiel?

Es bringt vor allem Vorteile beim Seeken. Wenn ich zum Beispiel zu einem bestimmten Kapitel springe und der Untertitel fängt einen Frame vor dem Kapitel an, so wird er mir nicht angezeigt, weil der Splitter nicht weiß, daß er eigentlich ein Untertitel-Paket von etwas weiter vorne holen müßte. Das wird dadurch behoben. Ähnliches gilt für Audio-Formate wie z.B Opus. Daß wir sagen, Tonspuren könnten überall geschnitten werden, weil sie praktisch nur "I-Frames" enthalten, ist eigentlich eine nicht ganz korrekte Vereinfachung. In Wirklichkeit brauchen viele Audio-Codecs für die korrekte Dekodierung auch Daten aus den vorhergehenden Paketen, weshalb wir häufig mit dem Encoder-Delay leben müssen. Auch hier wird durch das neue Feature dafür gesorgt, daß der Splitter dem Audio-Decoder alle benötigten Daten gibt, also bereits Daten kurz vor dem Seek liest. Im Moment ist der Vorteil allerdings theoretisch, weil ich kein Programm kenne, welches diese neuen Elemente bereits nutzen kann.

Ich bin auf den Beitrag gestoßen, weil ich mal schauen wollte, ob sich an der Problematik etwas getan hat, aber anscheinend werde ich die nächste Zeit noch bei der 5.8.0 hängen bleiben.

Wenn ich das ganze richtig verstanden habe war die Antwort auf Selurs ticket dass dem Entwickler bisher keine Player bekannt sind, welche eine frühere Version benötigen? Wenn ja ist das völliger Mumpitz. Alleine Google spuckt eine Menge Infos aus. Ich z.B. habe mit meinem BD390 von LG die PRobleme.

Klar kann der Entwickler meinen dass man so die Hersteller dazu bringt, neue Versionen zu unterstützen...aber ist es nicht ein wenig naiv zu denken, dass Hersteller noch Geräte, welche bereits 3-4 Jahre auf dem Buckel haben, mit Updates versorgen? Für mich birgt solch ein Verhalten eine gewisse "Arroganz". Leider gibt es zu dem Tool keine wirklich Alternative, sonst würden vielleicht gerade diese Nutzer abwandern.

Und als Entwickler kann ich sagen, dass eine Wahl für die Version nun nicht wirklich ein großer Aufwand ist. Auch wenn ich die Arbeit der Entwickler hier wirklich zu schätzen weiß, hat das ganze für mich eher etwas mit dem Durchdrücken eigener Ansichten zu tun. Das ist natürlich das Recht eines jeden Entwicklers, ob man sich damit einen Gefallen tut steht auf einem anderen Blatt...

"Getan" hat sich schon ab und zu was, aber meistens drum herum. So unterstützen die Programmierer von Konverter-GUIs oft kompatible Parameter-Kombinationen als Vorauswahl für ihren Multiplexprozess. Zum Beispiel kann man mit Zathor, dem aktuellen Programmierer der MeGUI, darüber gerne reden.

Zitat von Lapje

Klar kann der Entwickler meinen dass man so die Hersteller dazu bringt, neue Versionen zu unterstützen...aber ist es nicht ein wenig naiv zu denken, dass Hersteller noch Geräte, welche bereits 3-4 Jahre auf dem Buckel haben, mit Updates versorgen?

Genausowenig wie die Hardwarehersteller ewig ausgelaufene Gerätefamilien supporten, ist von den Softwareentwicklern zu erwarten, das die bis zum Sanktnimmerleinstag Schalter einbauen, um Kompatibilität zu Uraltversionen herzustellen und so ungewarteten "schlechten" Code mitschleppen. Wohin das führt siehst du am besten bei Windows.

@fryk
Der Vergleich hinkt wohl ein wenig. Es geht hier nicht um Geräte, welche 10 Jahre alt sind, sondern um welche, die gerade mal 3 Jahre oder so auf dem Buckel haben. Ich kann es mir jedenfalls in diesen Zeitsbständen neue Geräte nicht leisten. Und warum ist älterer Code direkt ungewartet und schlecht? Das eine hat mit dem anderen erst einnmal gar nichts zu tun.