# Version 19.0.0 "Brave Captain" 2017-12-17
## New features and enhancements
* mkvmerge: splitting by duration, by timestamps or by timestamp-based parts:
mkvmerge will now consider the first key frame within 1ms of the requested
value to be eligible for splitting.Davon abgesehen: wenn mkvmerge eh nur mit 1ms speichert, reicht doch auch 1ms Genauigkeit fürs Splitten. Sehe das Problem nicht.
OK, aber für Bluray und DVD Material scheint es zu klappen, denn da gibt es keine VFR, oder?
Durch Soft-Pulldown könnte man trotzdem zu VFR kommen.
Aber Mosu sagte mir das die Anzeigen/Speicherung in Matroska an einigen Stellen auf Millisekunden begrenzt ist.
Weiterhin sagte er, wenn ich Nanosekunden haben möchte, müsste ich mir das selber aussrechnen, denn mkvmerge tut dies auch(Mosu's Worte). Nur gespeichert wird halt in ms.
Ja, aber mkvmerge nimmt sicher nicht ms aus einer mkv-Quelle und macht daraus ns. Sondern z.B. --default-duration 0:24000/1001fps wird intern in ns gerechnet und dann beim Abspeichern der Elemente auf ms gerundet.
Klar kann eines der beiden Werte falsch sein, aber ich gehe immer als erstes davon aus das Mosu dort alles richtig hat.
Für mich das "falsch". Also nicht strikt falsch, weil DefaultDuration halt überflüssig ist, aber ich hätte DefaultDuration auf 40ms gesetzt.
Wie hast Du die Datei denn erstellt? Direkt aus einer VOB mit mkvmerge? Vielleicht hat mkvmerge nur die Werte falsch von einem anderen mkv-Muxer kopiert.
Ich brauche die DefaultDurartion, da ich noch andere Möglichkeiten nutzen möchte um an die Video-Spieldauer(Zeiten) heranzukommen.
Hierzu möchte mit den Statistic Tags und den dort befindlichen NUMBER_OF_FRAMES Eintrag die Spieldauer errechnen.
MKV ist VFR. Funktioniert nicht.
Klar dort gibt es auch eine direkte DURATION für das Video, aber eben auch nur wieder auf Millisekunden genau.
Dann ist das halt so. Damit mußt Du leben.
Von dieser Idee, daß Du alles auf ns genau ermitteln könntest, solltest Du Dich verabschieden. Oder auch von der Idee, daß mkvmerge oder andere Muxer korrekt arbeiten. Und was die Player aus dem ganzen am Ende machen, ist wieder eine andere Sache.
Also alle Blöcke haben in der Datei 40ms BlockDuration, aber DefaultDuration ist 20ms? Dann ist wohl eins von beiden falsch. Bzw. wenn alle Blöcke ein Duration-Element haben, wird DefaultDuration halt eh nicht benutzt.
Kannst Du die Datei hochladen?
BlockDuration geht vor. Wenn die immer da ist, wird DefaultDuration ignoriert.
Die BlockDuration bezieht sich auf den ganzen Block, zu dem sie gehört.
In meinen test mkvs war dies FLAG Byte immer 0x00. Von daher kann ich ja dort auch keine Bilder ermitteln... also wenn dort alles 0 ist, dann gibt es nur 1 Bild?
Ja.
1. Siehe: https://www.matroska.org/technical/spec…block_structure
Also schauen, ob Lacing-Flag (Bits 5&6 von Flags) != 00 und falls ja, dann "0x00 Number of frames in the lace-1 (uint8)" auswerten.
2. Ja, wüßte nicht, warum nicht.
3. Ja. (falls DefaultDuration gesetzt)
3.1 Was meinst Du mit "ändern"? Nein. BlockDuration ist die BlockDuration. Die ändert sich nicht und ist IMHO "stärker" als n * DefaultDuration.
4.1 Ja
Die Bilder werden benutzt. Das sind nur von anderen Bildern nicht referenzierte Bilder. Die könnte ein Player theoretisch auslassen, wenn er z.B. nur im Schnellvorlauf durchs Video möchte. Beim "normalen" Abspielen werden die aber ganz normal dekodiert und angezeigt. Davon abgesehen ist das Flag eh häufig falsch gesetzt, daher sollte man das einfach ignorieren.
Ach, das geht für was anderes als MVC? Man lernt nie aus ...
DirectShow kümmert sich hier nur um die Dekodierung auf Deinem PC. Dein Fernseher hat keine Ahnung, ob Du dabei mit DSS, ffms oder sonstwas gearbeitet hat.
DirectShowSource mit LAV DXVA2 copy-back. (Habe keine Nvidia-Karte.)
L-Smash basiert ebenfalls auf ffmpeg.
Für DSS/DSS2 erst DirectShowSource in den Einstellungen aktivieren und LAV installieren.. Dann Tools->AVS Script Creator->Filter. Ich würde für LAV Video/Splitter/Audio auch in den jeweiligen Einstellungen das Tray-Icon aktivieren. Dann siehst Du, ob die wirklich geladen werden.
DirectShowSource produziert minderwertige Qualität.
Das ist nicht korrekt. Die Qualität ist normalerweise identisch zu den anderen Filtern. DirectShowSource kann manchmal problematisch sein, z.B. weil die Frames nicht 100% an der korrekten Position sind (ist mit LAV normalerweise aber kein Problem, insbesondere, wenn man nur ein Skript von Anfang bis Ende enkodiert, d.h. ohne Seeken wie Trim()). Außerdem ist schwer zu erkennen, welche Filter wirklich geladen werden. Es gibt noch einen DSS2-Mod, der dafür sorgt, daß nur LAV geladen wird.
Aus diesen Gründen wird normalerweise eben ffms2 oder l-smash empfohlen, aber bei VC-1 sind die halt buggy, so daß man ausnahmsweise DSS/DSS2 bevorzugt - zumindest ich sehe das so. (DGDecNV möchtest Du ja nicht.)
Haben beide das gleiche Verhalten, gäbe es noch eine weitere Chance (DSS2 im LAV-Filter-Modus).
VC-1 ist auch einer der wenigen Fälle, wo ich DSS/DSS2 mit LAV (DXVA2 copy-back oder Microsoft) gegenüber ffms vorziehen würde, weil ffmpeg mit VC-1 verbuggt ist.
OK, aber die Cues sind eben auch kein zwingendes muss. Von daher nicht so sicher oder?
Nicht 100% sicher, aber heute halt sehr üblich.
In den Cues scheint es immer eine Spurnummer für das Video zugeben, sind die Cues ausschliesslich für Video Spuren/Daten?
Nein, auch häufig bei Untertiteln.
x264cli macht das leider nicht.
Bleibt jetzt nur noch zu klären ob "DefaultDuration" und/oder "Blockduration" immer irgendiwe vorhanden sind, denn es sind beides keine "zwingenden" Elemente.
Nein, sind nicht immer vorhanden.
Hab noch einen alten Post von Mosu gefunden, bei dem er mit dem MediaInfo-Entwickler über das Problem spricht. Ist in manchen Fällen wie vermutet nicht definiert.
https://forum.doom9.org/showthread.php?p=1604014#post1604014
Ich kann mir vorstellen das für Video und Audio da werte enthalten sind, aber für die Subs wird das nicht wirklich gebraucht, daher nicht "zwingend".
Bei Subs kommt es auf das Format an. ASS und SRT ohne Blockduration gibt es nicht. Bei PGS/SUP werden die i.d.R. nicht genutzt, wegen dieses komischen Formats (leere "Zeile" beendet quasi vorherige "Zeile"). Bei IDX/SUB weiß ich es nicht aus dem Kopf.
Wenn, dann so:
A0 52 FF [COLOR='#00FF00']A1[/COLOR] [COLOR='#DAA520']52 F3[/COLOR] [COLOR='#0000FF']81[/COLOR] [COLOR='#EE82EE']01 90[/COLOR] [COLOR='#CC0000']00[/COLOR] 00 00 01 00 02 9F FF FB B8 00 00 01 B5 84Block
Block ElementGröße:
Spurnummer in EBML form. also Byte auslesen, führende "0"en zählen usw
Zeitstempel
Flags
Und das stimmt so auch, denke ich. Wie genau dieses "Size = 1 + (1-8) + 4 + (4 + (4)) octets. So from 6 to 21 octets" zustande kommt, weiß ich nicht, aber egal.
ElementID: 1
Größe: 1 (min)
Spurnummer: 1 (min)
Zeitstempel: 2
Flags: 1
(Lacing: min. 0)
Das wären dann 6. Oder er zählt statt ElementID den eigentlichen Inhalt mit. Denn ein Block ist ja nicht leer sondern enthält die eigentlichen Bild-/Ton-/Untertiteldaten mit min. 1 Byte. Letztendlich ist es egal, es muß so sein.
Ich verstehe das nicht. Ich hätte gedacht:
1 = ElementID ( [A3] )
(1-8) = Tracknummer
4 = timecode
...
Aber: Timecode soll ja signed int16 sein und 16 Bit sind in meiner Welt 2 Bytes, nicht 4 Bytes.
Oder 4 = timecode + Flags, aber das wären auch nur 2 Bytes + 1 Byte...
Oder doch wieder variable Länge? Ich suche gerade und finde nur widersprüchliche Informationen.
Also ja, aber doch irgendwe nein??
Ah, sorry, war wohl mißverständlich. Wollte sagen: wenn es so wäre, dann müßte man nur im letzten Cluster suchen. Da dem aber nicht so ist: nur im letzten Cluster zu suchen, ist nicht 100% sicher. (Bzw. die Cluster-Timecodes selbst könnten zwar geordnet sein, aber die Block-Timecodes sind ja beliebig versetzbar mit ihrem Offset, d.h. auch in "Bereiche" anderer Cluster hinein oder gar hinaus.)
Die Frage wäre jetzt, was die beste Strategie ist, den letzten Zeitstempel bzw. den letzten Start-Zeitstempel zu finden. Das weiß ich so nicht. Ich würde vermutlich zum letzten Cluster gehen und dann rückwärts die Cluster durchsuchen und da irgendwo bei 30 Frames oder so einfach aufhören. Das sollte dann für 99,99% aller Dateien in der Praxis reichen. Vielleicht fragst Du für sowas besser im englischen Forum.
OK, wo es in den Specs steht ist klar, im Track, aber auch dieses Element ist nicht "zwingend", was wenn es fehlt.
Einen Default wert gibt es nicht.
Ja, das ist nicht wirklich definiert, glaube ich. Ich würde da vermutlich den Unterschied zwischen letztem und vorletztem Frame nehmen, oder 0.
Display Order hat dann geordente Zeitstempel und Coding Order nicht?
Ja. Coding Order ist halt, wie es gespeichert ist. Und Display Order, wie wir Menschen uns das anschauen. Ist jetzt auch nicht wirklich relevant, außer halt überhaupt zu wissen, daß der letzte Block (von der Reihenfolge, wie er gespeichert ist, nicht unbedingt den letzten Frame (von der Anzeigezeit) enthält.
Das Element "ReferenceBlock" hat als Werte-Bereich "i" Signed Integer, was Nanosekunden sind. Es steht dort ja auch nur ein Zeitstempel, aber woher weis man dann ob es P oder B frames sind?
Wenn da eine positive Referenz ist, muß es ein B-Frame sein. Ist aber nicht wichtig zu wissen.
Kann ich aber davon ausgehen das die Cluster in Zeitreihenfolge geordnet sind, dann müsste man nur im letzten Cluster suchen.
Ja. (Sind sind aber nicht, also egal...)
Wo finde ich dann die Dauer für den SimpleBlock. Einen "Start" Zeitstempel sehe ich, und die Anzahl der Bilder.
Den Wert "DefaultDuration" verstehe ich noch nicht ganz. Wo finde ich diesen Default Wert?