MPLS Structure

    ich eröffne hier mal ein neues thema.

    (mein english ist nicht so dolle^^)

    ich habe eine tolle, sehr ausführliche Spec-Dokumentation zu Blurays bekommen. unteranderem ist dort recht gut definiert wo alle bytes in einer mpls auftauchen und was sie bedeuten.

    ganz den durchblick habe ich noch nicht aber ich werde mich einlesen.

    @bigotti
    deine tipps sind bis jetzt sehr sehr hilfreich (die mpls liest sich für mich jetzt schon recht deutlich).

    in erster linie denke ich geht es um das Playitem welches in seamless branching vorliegt. (mit den subplayitems habe ich mich noch nicht befasst. weis also noch nicht genau was das ist und was sie bedeuten)

    in erster linie gehts mir ja nur um die passenden kapitelmarken.

    Bei mpls mit mehreren Clips sind die Kapitel nicht direkt auszulesen. Erst bestimmst du die Dauer der einzelnen Clips aus Out_time minus In_time.
    Die Kapitelmarken sind dann am Ende der Playlist. Der dortige Timecode bezieht sich ausschließlich auf den Playitem in dem der Chapter vorkommt.
    Aus diesen Timecodes und der Dauer der Clips kannst du die Kapitel berechnen.
    Beispiel:

    Code
    C_ID  In Time        Out time       Dauer000   00:00:11.650   00:00:57.988   00:00:46.338001   00:00:11.650   00:01:12.753   00:01:01.102002   00:00:11.650   00:02:14.982   00:02:03.331003   00:00:11.650   00:00:31.670   00:00:20.019004   00:00:11.650   00:03:54.164   00:03:42.513....


    Bei den Chaptermarks steht immer erst der Playlistindex dann der Timecode

    Code
    [COLOR=#ff0000]00 00[/COLOR] [COLOR=#0000ff]00 07 ff f8 [/COLOR]ff ff[COLOR=#0000ff]
[/COLOR][COLOR=#ff0000]00 01[/COLOR] [COLOR=#0000ff]00 25 69 76 [/COLOR]ff ff[COLOR=#0000ff]
[/COLOR][COLOR=#ff0000]00 04 [/COLOR][COLOR=#0000ff]00 21 42 63 [/COLOR]ff ff[COLOR=#0000ff][/COLOR]


    In Clip 0,1 und 4 kommen Kapitel vor, in 2 und 3 nicht.
    Von den Timecodes muss noch die In_time des jeweiligen Clips abgezogen werden um die MPLS Kapitelzeit zu errechnen.
    Kapitel 1: aus Clip 0; 11,650 minus 11,650 -> 00:00:00,000 
    Kapitel 2: aus Clip 1: 54,485 minus 11,650 plus 46,338 (Dauer Clip 0) -> 00:01:29,123
    Kapitel 3: aus Clip 4; 48,437 minus 11,650 plus 46,338 + 61,102 + 123,331 + 20,019 (Dauer Clip 0,1,2,3) -> 00:04:47,577

    ok, das klingt einleuchtend. ist dann ein klein wenig schwerer zu programmieren aber denke auch kein beinbruch.

    ich bin gerade am drübernachdenken wie man dann am besten durch die datei(binär) durch geht.
    die daten liegen dann im speicher und soweit ich das programmiertechnisch verstehe springt man dann von byte zu byte (also ganz spezielle bytestellen).

    Code
    [COLOR='#FF0000']4D 50 4C 53[/COLOR] [COLOR='#008080']30 32 30 30[/COLOR]

    die ersten 4 bytes stehen für MPLS
    die nächsten 4 für die versionsnummer 0200

    die nächsten 4 bytes stehen für die PlayList_start_address: als beispiel habe ich da

    Code
    [COLOR='#FF8C00']00 00 00 3A[/COLOR]

    was dem dezimalwert 58 entspricht.
    bedeutet das, das man an dem 58. byte hinspringen muss/kann und ab dort dann diese PlayList_start findet?

    in dem beispiel wäre das 58. byte

    Code
    [COLOR='#FF8C00']00[/COLOR]

    die nächsten 4 bytes (12-15) stehen für die PlayListMark_start_address:

    Code
    [COLOR='#008000']00 00 00 E6[/COLOR]


    was dann dem 230. byte entsprechen würde.


    hier mal ein bild dazu.
    es ist eine mpls ohne seamless branching.
    mpls.JPG

    das ist super nett von dir. diese grafik ist recht gut gelungen ich hatte da auch schon an eine schöne übersicht gedacht.

    denn diese mpls ist ja nur eine von ziemlich vielen möglichkeiten.

    mit subitem, mit conection_condition, mit seamless branching usw.

    die meisten bytes konnte ich, ebenfalls wie du es beschreibst, selbst herrausfinden. dank der tollen spec-documentation.
    ich denke das ich die kommenden tage anfangen werde den parser zu schreiben.


    edit: bei der bezeichnung "Beginn der STN_table"(in deinem überarbeiteten bild) steht in den specs: 00 7E ist die länge der stn-table in dem fall 126 bytes. die position ist 103 also ab 104 + 126 kommt man ebenfalls bei byte 230 raus wo dann die playlistmark_table beginnt.

    das byte nach 00 7E, also 00 ist reserviert für future use.

    MPLS Structure Seit einiger Zeit beschäftige ich mich auch mit diesem Thema. Der von ts zu BDMV gemuxte Stream ist nur mit TSRemux durchgängig synchron. Mit TSMuXer steigt die Asynchronität mit der Länge des Streams. TSRemux setzt aber nur feste Kapitel. Diese will ich ändern BDEdit beschädigt die 0000.mpls, wenn ich die Änderungen speichere. In den Ausfürungen von bigotti5 wird die Kapitelstruktur kurz angesprochen. Allerdings ist mir der Zudsammenhang zwischen den Time Codes und den Hex-Einträgen in der Playlist nicht klar. Beispiel von bigotti5: C_ID In Time Out time Dauer 000 00:00:11.650 00:00:57.988 00:00:46.338 001 00:00:11.650 00:01:12.753 00:01:01.102 002 00:00:11.650 00:02:14.982 00:02:03.331 003 00:00:11.650 00:00:31.670 00:00:20.019 004 00:00:11.650 00:03:54.164 00:03:42.513 -> Code: 00 00 00 07 ff f8 ff ff 00 01 00 25 69 76 ff ff 00 04 00 21 42 63 ff ff Mein Beispiel aus TSRemux angezeigt mit BDEdit und Hex-Editor: Start-Time 000: 00:04:01.680 -> Adresse: A0-A3, Code 00 05 F2 D0 z.B.Kapitel 004: 00:24:01.680 -> Adresse: CA-CD, Code 03 0F ED F0 Wie kann man aus den gewünschten Time-Angaben den erforderlichen Code berechnen?

    zu erst kommt es darauf an ob eine Spielfilm aus mehreren PlayItems betsteht oder nicht.
    ist es nur ein PlayItem so ist es recht simple. alle Kapitelmarken beziehen sich ja nur auf das eine PlayItem und die zeit lässt sich dann simple auslesen.

    In der KapitelmarkenListe findest du immer wieder diese "FF FF" und die 4 bytes davor sind die timecodebytes.
    du ermittelst den Integerwert aus diesen 4 Bytes und dividierst durch 45000 (45000 ist die Clock mit der die time s codiert werden)

    besteht ein Spielfilm aus mehreren PlayItems musst du für jedes Playitem die IN un OUT time bestimmen, so bekommst du die spiellänge jedes Playitems.
    dann gehst du wieder zu den Kapitel marken.

    Code
    C_ID  In Time        Out time       Dauer000   00:00:11.650   00:00:57.988   00:00:46.338001   00:00:11.650   00:01:12.753   00:01:01.102002   00:00:11.650   00:02:14.982   00:02:03.331003   00:00:11.650   00:00:31.670   00:00:20.019004   00:00:11.650   00:03:54.164   00:03:42.513....


    Bei den Chaptermarks steht immer erst der Playlistindex dann der Timecode

    Code
    [COLOR=#ff0000]00 00[/COLOR] [COLOR=#0000ff]00 07 ff f8 [/COLOR]ff ff[COLOR=#0000ff]
[/COLOR][COLOR=#ff0000]00 01[/COLOR] [COLOR=#0000ff]00 25 69 76 [/COLOR]ff ff[COLOR=#0000ff]
[/COLOR][COLOR=#ff0000]00 04 [/COLOR][COLOR=#0000ff]00 21 42 63 [/COLOR]ff ff[COLOR=#0000ff][/COLOR]

    du musst dann jede kapitelmarke untersuchen, zu welchem playitem die marke gehört. dann ziehst du von der kapitelmarke die IN-time des zugehörigen Playitems ab. und addierst alle spiellängen der Playitems welche vorher noch kommen.

    also eine kapitelmarke welche zum Playitem 4 gehört müssen alle spiellängen von Playitem 1 und 2 und 3 noch dazu addiert werden.

    Vielen Dank für Deine schnelle Antwort. Es tut mir leid, dass mein Text bei diesem ersten Versuch als Grünschnabel so schlecht lesbar war. Ursprünglich war er sauber formatiert. Die Formatierung war beim Kopieren verloren gegangen. Es handelt sich bei mir in jedem Fall um einen PlayItem. Dass die Sprungmarken vor den FF FF stehen war mir bekannt. ... Du ermittelst den Integerwert aus diesen 4 Bytes und dividierst durch 45000 ... Ist der Integerwert der Dezimalwert? Wie sieht das nun bei meinen Beispielen aus? Start-Time 000: 00:04:01.680 -> Adresse: A0-A3, Code 00 05 F2 D0 z.B.Kapitel 004: 00:24:01.680 -> Adresse: CA-CD, Code 03 0F ED F0 Der Dezimalwert aus 05 F2 D0 ist 389840. Das geteilt durch 45000 ist 8. Weit entfernt von der tatsächlichen Strartzeitangabe 00:04:01.680. Was mache ich falsch?

    Das ist für mich das erste Mal, dass ich Fragen in einem Forum stelle. Ich bin begeistert, wie hilfsbereit insbesondere hubblec4 ist. Vielen Dank. Zunächst war mir völlig unbekannt, dass man durch 45.000 teilen muss. Jetzt bin ich doch schon wieder reingefallen. Mein Windows-Rechner hat im Programmierer-Modus bei Dezimal-Anzeige nach der Division nur den Integer-Wert. angezeigt und nicht die Dezimalstellen. Für die Lage des InTime-Wertes habe ich das farbige Hex-Bild von Euch verwendet. Der Wert sollte auf Adresse 052-055 stehen. Der Code ist bei mir 00 A5 F2 D0, ergibt einen Dezimalwert von 10875600. Wenn ich diesen Wert jetzt auch durch 45000 teile, bekomme ich 241,68. Dies geteilt durch 60 ist 4:01.680. -> Wahnsinn !!! Das bedeutet, dass der Time-In-Wert mit der Startzeit identisch ist. Und nun zu meinem zweiten Beispiel: Kapitel 001: 05:14.380, Adresse AE-FF1 Code: D7 DE 22, dez: 14147106, geteilt durch 45.000 = 314,380, dividiert durch 60 = 05:14.380 -> Nochmals Wahnsinn !!! Also war in meinem Beispiel für die Start-Time die Adresse A0-A3 Code, 00 05 F2 D0 falsch. Was ist das dann aber für ein Wert? Wie kann ich meine mpls-Datei posten?

    ich habe erst für ein paar tagen mir selber einen mpls parser geschrieben, daher stehe ich da bissl in der materie (aber auch noch nicht komplett).

    das erste kapitel sollte immer 0 ergeben, da die Spieldauer des PlayItem identisch mit der ersten kapitelmarke ist.

    ohne deine datei zu sehen wird es schwer werden da genau aussagen zu machen welche bytes du uns da zeigst.

    TSRemux bringt zwangsläufig das erste Kapitel nicht mit 0, sondern mit einem Wert,
    der zwischen 0 und 10 Min liegt.

    Ich habe versucht, den Wert an Adresse 052 bis 055 auf 0 zu setzen, um die Startadresse
    auf 0 zu bekommen. BDEdit zeigt aber unverändert den Wert 04:01.680 an.
    Anscheinend spielt hier noch der Eintrag auf Adresse A0-A3 mit, Code 00 A5 F2 D2.
    Kannst Du hierzu etwas sagen?

    Warum ist es mir nicht möglich meinen Text formatiert eizugeben.
    Wenn ich Ihn in die Antwortseite einkopiere, ist er formatiert, wenn ich auf "Antworten" klicke,
    ist er es nicht mehr.
    Hier ist meine mpls-Datei.

    Falls es jemand interessiert, ich habe noch einen anderen Weg gefunden, um mein Problem zu lösen.
    Anfangs sagte ich, dass beim TSMuxer im BDMV-Ordner der m2ts-Stream gegen Ende immer stärker asynchron wird.
    Beliebige Kapiteleingaben werden aber vom TSMuxer fehlerfrei verarbeitet.
    Muxe ich mit TSRemux nach BDMV, bleibt der m2ts-Stream synchron. Also habe ich am Anfang etwa ein Drittel
    des m2ts-Streams vom TSMuxer verwendet und zwei Drittel des m2ts-Streams von TSRemux angehängt.
    Dadurch ist der m2ts-Stream ist bis zum Ende synchron und die Kapitel stimmen auch. Geschnitten habe ich
    mit SmartCutter, das m.E. das einzige Programm ist, das HD-Streams bildgenau schneiden kann.

    Zitat von Eichhost

    Warum ist es mir nicht möglich meinen Text formatiert eizugeben.
    Wenn ich Ihn in die Antwortseite einkopiere, ist er formatiert, wenn ich auf "Antworten" klicke,
    ist er es nicht mehr.

    Keine Ahnung, nur mal spekuliert: Auf alten Macs (MacOS bis Version 9) wurde für Zeilenumbrüche ein anderes Zeichen verwendet (#13, CR) als das, worauf PHP bei Unix-Varianten wie Linux und BSD (#10, LF) reagiert, um es zu einem HTML-konformen Umbruch zu konvertieren (<BR>). Moderne MacOS-Versionen basieren aber auch auf einem Unix-artigen Betriebssystem, und aktuelle Textprogramme sollten da einheitlich oder flexibel arbeiten. Windows (seit MS-DOS) ist in der Hinsicht praktisch sicher, das verwendet eine Kombination aus beiden (#13#10, CR LF).

    Deshalb werden im ASCII-Übertragungsmodus (cooked) im Internet meist die CR-Zeichen gelöscht, um es dem Linux-Standard anzugleichen (nur LF); wenn Macs nur allein das CR verwendet hatten, ging dabei jeder Zeilenumbruch völlig verloren... allerdings nur bei FTP-Datei-Uploads, dachte ich. Würde mich überraschen, wenn HTTP-Formular-POSTs das auch so machen.

    Warum kopierst du deinen Text überhaupt aus einem fremden Textprogramm heraus? Kannst du ihn nicht direkt im Forum eintippen? Medizinische Probleme mit der Optik, Lesbarkeit, Textgröße?

    Das Problem mit der Textformatierung ist gelöst. Ebenso, dass es mir zunächst nicht möglich war, meine mpls-Datei zu posten. Das entsprechende Fenster ging nicht auf. Das sind Fehler im Avantbrowser. Mit IE 11 funktionierte es einwandfrei.

    Vielen Dank für Deine Arbeit. Die Zusammenhänge waren mir eigentlich schon klar.

    Was mich irritiert, dass die Werte für In-Time und das erste Kapitel praktisch gleich sind.
    Sie unterscheiden sich nur im 4. Byte um 2 Punkte. Gibt es dafür eine Erklärung?

    Ist es möglich die In-Time auf "0" zu setzen, oder muss man noch weitere Werte ändern?
    Wie bereits gesagt, hat sich bei BDEdit der Wert für Kapitel 0 nicht geändert.

    ahh jetzt wo du es sagst sehe ich es auch das in_time und erste kapitel marke nicht identisch sind.
    ich denke das sollte aber nicht ins gewicht teilen, denn wenn man durch 45000 teilt ist der unterschied sehr gering und weit hinter dem komma.
    so sollte der ste kapitel dennoch 00:00:00.000 sein.


    nein die in_time kann man nicht einfach ändern.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden