MuxMan Motion Menü läuft nicht richtig

  • Manche SA Player scheinen ein Problem mit per MuxMan (+GfD) erstellten Motion Menüs zu haben. Link zum Original-Thread (Englisch):
    http://forum.videohelp.com/viewtopic.php?t=321390

    Ich hab mir das mal schicken lassen, kann aber keinen 'Fehler' finden. Könnte sich das mal ein Profi (bigotti5 :winken: ) anschauen? Vielleicht kann man das Problem ja durch eine Änderung im mxp Skript lösen. ATM habe ich aber keine Ahnung, wo das Problem eigentlich ist...
    Symptom: Buttons sind nicht 'gehighlighted' und lassen sich nicht auswählen/starten

    Das Beispiel (gleiches Menü einmal mit dvdauthor + einmal mit MuxMan erstellt) als vollständige VIDEO_TS Ordner gibt es hier:
    http://www.boraxsoft.de/other/MuxManAniMenuProb.zip (13 MB)

  • Muxman:

    Button Highlight Information stimmen folgende Werte nicht:

    [0093] Highlight end time (PTM) 324349257
    [0097] Button selection end time 25257

    richtig wäre:

    0093] Highlight end time (PTM) 929160
    [0097] Button selection end time 929160


    Die "Highlight end time" kann nicht größer sein als das Menü selbst, ist hier aber eher nicht schuld sondern die "Button selection end time" mit 25257 (die Start PTM der ersten VOBU) hier wäre die Buttonauswahl mit dem Beginn der ersten VOBU schon wieder zu Ende.
    Warum schreibt ihr alle als Highlight Duration 01:00:00:00 und nicht die wirkliche Länge des Segments?
    Ebenso bei der "Select End Time" gehört die wirkliche Länge rein....oder wenn das ermitteln der Länge von der GUI nicht möglich ist solltest du auch bei "Button selection end time" 01:00:00:00 verwenden und damit testen ob die Player damit auch Probleme machen.



    z.b



    Dvdauthor:

    [0093] Highlight end time (PTM) -1 [ffffffff]
    [0097] Button selection end time -1 [ffffffff]

    GeFFFFt werden Highlight end time und Button selection end time nur wenn die Menücell eine Still Time zwischen 1 und 255 enthält, hier sollte in deinem Fall jeweils 949773 stehen

  • Bei Non-drop Streams hat jede Sekunde 30 Frames. NTSC wird aber mit 29,97 Frames pro Sekunde abgespielt. 18000 Frames (18000/30=600 Sekunden=10 Minuten) wären lt Non-drop Timecode 00:10:00:00, würde eine Stoppuhr mitlaufen wäre die aber bereits bei 00:10:00:18.
    Um das auszugleichen wurde der Drop-Frame Timecode eingeführt.
    Bei Drop-Frame Streams werden am Anfang jeder Minute (außer bei Null und jeder weiteren zehnten Minute: 0, 10, 20, 30 , usw.) die Frames 0 und 1 auf dem Time Code übersprungen. Dieser Vorgang findet damit nur beim Übergang auf die ganzen Minuten 1, 2, 3, 4, 5, 6, 7, usw. statt. Dabei werden aber nur die Frames 0 und 1 auf dem Video Time Code übersprungen - nicht die Frames 0 und 1 selbst.
    Zum Beispiel springt der Time Code von 00:01:59:29 auf 00:02:00:02 anstatt auf 00:02:00:00. Das Drop-Frame Flag stellt die Synchronisation mit der echten Uhrzeit sicher.
    Bei 10 Minuten sind dies genau 18 Frames, pro Stunde werden im Timecode 108 Frames übersprungen usw.

  • Klingt irgendwie extrem umständlich...
    GfD intern verwende ich für alle Zeitangaben ausschließlich Sekunden (als Float mit beliebig vielen Kommastellen). Um jetzt Kapitelmarken für MuxMan 'richtig' zu berechnen, muss ich also mit einer fps rate von 30 'rechnen', eine Kapitelmarke für den Zeitpunkt '20 Minuten' müsste dann also als 00:19:58.24 'übergeben' werden? Oder kann man MuxMan auch Drop-Frame Timecodes übergeben?
    Was steht eigentlich in den GOP Headern? Drop-Frame oder Non-Drop-Frame Timecodes?

  • Zitat

    Oder kann man MuxMan auch Drop-Frame Timecodes übergeben?


    Ja - aber imho nur bei den Subtitles und dieser wird dann nach ND konvertiert

    Zitat

    Time Code denotes the units used to specify Start, Display, and Duration. However, all times are non-drop format, "NTSC drop" is recognized, but translated to "NTSC non-drop".

    Zitat

    Was steht eigentlich in den GOP Headern? Drop-Frame oder Non-Drop-Frame Timecodes?


    Entweder oder...
    Wenn das erste Bit im GOP Header (die 4 Bytes nach 01 B8) gesetzt ist, ist es Drop Time-Code, ist es nicht gesetzt, dann Non-Drop Time-Code.

    Beispiel:
    GOP Header an Frame 4155
    (der Timecode bezieht sich immer auf das Frame mit der Temporal Reference = 0, bei offenen GOPs z.b auf das erste B-Frame)

    Drop
    00:02:18:19
    1--00000--000010--1--010010--010011--1--0--00000
    Drop/NondropFlag--Stunden--Minuten--(Marker Bit, immer 1)--Sekunden--Frames--Closed GOP--Broken GOP--(immer fünf Nullen)

    Non-Drop
    00:02:18:15
    0-00000-000010-1-010010-001111-1-0-00000

  • Uff, das muss ich erst mal 'verdauen'. Ich habe bisher einfach die Timecodes aus den GOP Headern ohne weitere 'Betrachtung' von Temporal Reference und Drop/NondropFlag als Kapitelmarken verwendet, was bei PAL auch problemlos funktioniert hat.
    Also gut...
    Drop/NondropFlag auslesen und dann ggf. in eine 'echte' Zeit umrechnen hab ich (glaub ich) verstanden. Kapitelmarken müssen für MuxMan mit NTSC non-drop Timecodes übergeben werden. Kapitelmarken müssen AFAIK an GOP Grenzen 'sitzen'. Brauche ich dann auch noch die Temporal Reference (die ist bei dem Beispiel oben ja immer 2, außer beim ersten Frame) um eine 'gültige' Kapitelmarke zu berechnen, oder kann man den Timecode aus dem GOP Header (ggf. nach 'Umrechnung' in einen non-drop Timecode) 'direkt' verwenden?
    Nochmal DANKE für die 'Nachhilfestunden' :)

  • Die Temporal Order ist nur dann interessant wenn der (direkte)Einsprung in ein Kapitel framegenau erfolgen muss, ansonsten ist es egal. Es werden nur die ersten zwei B-Frames nicht angezeigt. Ist bei PAL und NTSC gleich.
    Um framegenaue Kapitel (für den direkten Einsprung) zu erstellen muss man bereits beim Encoden an den besagten Stellen Closed GOPs erzeugen.

  • Ok. Fassen wir nochmal zusammen:
    Bei PAL Streams kann ich die Timecodes aus den GOP Headern 'einfach so' verwenden (sowohl zur Berechnung den Gesamtdauer als auch für Kapitel).
    Bei NTSC muss man das erste Bit im GOP Header prüfen, ob es sich um Timecodes im Drop oder Nondrop 'Format' handelt. Beim NTSC drop 'Format' kann man die Timecodes als 'echte' Zeit betrachten und ebenfalls 'einfach so' verwenden (auf ein oder zwei Frames kommt es ja meist nicht an).
    Beim Nondrop 'Format' muss man immer 'zurückrechnen', da der Timecode keine 'echte' Zeit darstellt, sondern einen virtuell auf 30 fps bezogenen Wert.
    Stimmt das etwa so?

  • Soweit ich mich erinnere, hatte mindestens eines der professionellen DVD-Authoringtools (Sonic DVD-Creator / Spruce DVD-Maestro / Daikin Scenarist ... vor Jahren) Probleme mit dem Import von Drop-NTSC gehabt, und da "nicht-kontinuierlichen Timecode" kritisiert. Verständlich: Der wird ja für Cell-Positionierung und FFwd-Features benötigt.

  • Zitat

    Du kannst aber auch jeden anderen NDF Stream sehr schnell mittels DGPulldown von Donald Graft auf DF Timecode umpatchen (siehe Bild 2).


    Stimmt, aber ich wollte gerne mal einen 'aus freier Wildbahn' testen...
    Außerdem patched DGPulldown auch immer alles auf progressiv (wobei das wahrscheinlich egal ist).
    Meine momentane Plannung sieht so aus:
    Alle Zeiten auf 'echte' hh:mm:ss:msec umrechnen (mind. bei Kapiteln und Gesamtdauer); dann beim 'übergeben' an MuxMan/dvdauthor auf NTSC non drop frame umrechnen (falls NTSC; bei PAL gibt es sowieso keine 'Handlungsbedarf'))

  • Stimmt, aber ich wollte gerne mal einen 'aus freier Wildbahn' testen...
    Außerdem patched DGPulldown auch immer alles auf progressiv (wobei das wahrscheinlich egal ist).
    Meine momentane Plannung sieht so aus:
    Alle Zeiten auf 'echte' hh:mm:ss:msec umrechnen (mind. bei Kapiteln und Gesamtdauer); dann beim 'übergeben' an MuxMan/dvdauthor auf NTSC non drop frame umrechnen (falls NTSC; bei PAL gibt es sowieso keine 'Handlungsbedarf'))

    Gilt das ganze Problem also nur für NTSC-DVDs?

    Wäre mir nur Recht, denn ich mag die Muxman-Engine lieber.

    Wenigstens bisher, bin noch nicht fertig mit Vergleichen ...


    Gruss,
    HdS

  • Soweit ich mich erinnere, hatte mindestens eines der professionellen DVD-Authoringtools (Sonic DVD-Creator / Spruce DVD-Maestro / Daikin Scenarist ... vor Jahren) Probleme mit dem Import von Drop-NTSC gehabt, und da "nicht-kontinuierlichen Timecode" kritisiert. Verständlich: Der wird ja für Cell-Positionierung und FFwd-Features benötigt.


    Meinst du etwa IFOEdit vor v.097?

    Ist das jetzt vielleicht das selbe Ding?

  • Ich glaube nicht, dass die Ifoedit NTSC Probleme mit den drop frame/non drop frame Timecodes zu zu hatten.
    Was mich allerdings noch wundert: Wenn man Audiotitlesets erstellt, wird ja aus dem Audiostream eine 'reale' Zeit ausgelesen. Diese wird bisher (ohne Rücksicht auf drop frame/non drop frame Timecodes) direkt an MuxMan übergeben (sowohl als Duration, als auch aufsummiert als Segment Scene Time). Trotzdem gibt es hier keine Probleme???
    Auch Mark's Tray DVD Player Professional hat nichts daran auszusetzen...
    (Ist ja richtig schwierig das Ding 'aufzutreiben', obwohl es laut Installation 'echte' Freeware ist?!)

Jetzt mitmachen!

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