Premiere .prproj-Datei-Ticks driften um 1/1000 im Vergleich zu Timecodes

Ich bin Programmierer und verarbeite Adobe Premiere- .prprojDateien. Ich lese die enthaltenen XML-Daten, um herauszufinden, wo <Media>die Videodatei eines Elements beginnt.

Ich habe ein Video, das mit einem Timecode aufgenommen wurde, der bei 10:00:00:00 beginnt, dh genau 10 Stunden oder 36000 Sekunden. Diesen Timecode zeigt Premiere für den Anfang der Datei an.

Die entsprechenden Daten in der Projektdatei sind:

<Media ...>
    ...
    <Start>9153720576000000</Start>
</Media>

Dieser Wert verwendet Ticks als Einheit.

Nun gehe ich davon aus, dass eine Sekunde 254016000000 Ticks entspricht. Denn wenn ich zum Beispiel eine Sequenz mit 25 FPS habe, gibt ihr FrameRate-Element im XML 10160640000 Ticks an, und das ist genau eine 25stel Sekunde.

Aber wenn ich den <Start>Wert 9153720576000000 durch 254016000000 dividiere, bekomme ich 36036 Sekunden und nicht wie erwartet 36000 Sekunden.

Durch Lesen der XML-Werte erfahre ich also, dass das Video um 10:00:36:00 beginnt.

Seltsamerweise ist dieser Unterschied genau das 1001/1000-Verhältnis des NTSC-Drop-Frame-Timings, richtig?

Wie verstehe ich nun die Daten in der Premiere-Projektdatei? Einerseits identifiziert die Tick-Basis von 254016000000 genau die verwendeten Bildraten in derselben Datei, also muss es der richtige Wert für Ticks pro Sekunde sein . OTOH, es ist für Zeitcodes um 1 ms pro Sekunde ausgeschaltet.

Wie soll ich die Tick-Werte in der Datei interpretieren? Soll ich sie alle um einen Faktor von 1,001 anpassen, um den tatsächlichen Zeitcode zu erhalten, oder wo ist mein Fehler bei all dem?

Oder ist es bekannt, dass Timecodes nicht auf tatsächlichen Sekunden, sondern auf 1,001 Sekunden basieren?

Mit anderen Worten, bedeutet 10:00:00:00, dass es tatsächlich bei 36036 Sekunden beginnt?

Aktualisieren

Es scheint, dass es tatsächlich eine Drift mit Timecodes gegenüber der Echtzeit gibt, aber nur, wenn die Aufzeichnung laut diesem Artikel gebrochene FPS wie 29,97 oder 23,976 (= 23,98) verwendet .

Und tatsächlich wurde die fragliche Mediendatei mit 23,98 FPS aufgezeichnet.

Gehe ich also richtig in der Annahme, dass ich bei jeder Interpretation eines Timecodes auch die beteiligten FPS betrachten muss, und wenn es sich um einen Bruchteil handelt, muss ich 1 ms pro Sekunde zur berechneten Zeit hinzufügen, um auf lange Sicht genauer zu sein ? (Die Einzelbildgenauigkeit ist mir egal, daher spielt es keine Rolle, wann ich die Driftkorrektur anwende, es ist nur eine Frage, wann ich sie überhaupt anwende.)

Antworten (1)

Lassen Sie mich zunächst sagen, dass ich keine Ahnung habe, was Premiere mit seinen Werten macht oder was ein „Häkchen“ in ihren Begriffen bedeutet. Ich kann nur allgemein sprechen.

Die Video-Framerate sollte mit der Timecode-Rate übereinstimmen, aber für Drop-Frame-Timecodes ist die Beziehung nicht perfekt linear. Es gibt bestimmte Timecode-Nummern, die nie in der Sequenz auftauchen – diejenigen, die „ausgelassen“ werden. Für solche Codes kann man also nicht einfach rechnen, man muss die Drops berücksichtigen.

Im Laufe von 1 Stunde gibt es 108000 Frames bei 30 fps, aber der Drop-Frame-Code erzeugt nur 107892 eindeutige Zahlen. Beide Uhren stimmen darin überein, dass "die Zeit" 1:00:00:00 ist.

Wenn Sie nur Timecodes verwenden, um jeden Frame mit einer eindeutigen Nummer zu kennzeichnen, reicht jedes Schema aus. Wenn Sie die Tageszeit abgleichen müssen, müssen Sie die ausgelassenen Zahlen berücksichtigen. Was müssen Sie mit Ihren Werten tun?

Ich hätte beachten sollen, dass die Startzeit von 10 Stunden keine Dauer, sondern nur eine Markierung ist, daher wird sie als Konstante oder Offset behandelt. Das Video begann nicht bei 36036 Sekunden, sondern bei 0 Sekunden. Der erste Frame ist mit 10:00:00:00 beschriftet, aber das ist alles, was TCs sind: Etiketten.
Was ich versuche, ist Folgendes: Ich finde Kommentarmarken im Premiere-Projekt und suche dann den/die entsprechenden Videoclip(s). Dann muss ich herausfinden, wie weit dieser Marker im Clip gesetzt ist, und diesen Offset verwenden, um mit einem anderen Programm (z. B. ffmpeg) einen Screenshot aus dem Video zu extrahieren. Für ein Video mit Start um 10 Uhr sagt mir das Premiere-XML, dass es 36036 Sekunden sind. Ich verwende diesen Wert in meiner Marker-Offset-Berechnung und lande 36 Sekunden zu früh in der Videodatei. Bei einem 24 fps Video habe ich dieses Problem nicht. Ich sollte wahrscheinlich mehr Daten in meiner Frage angeben.
@ThomasTempelmann - Es tut mir leid, ich weiß nicht, wie Premiere interne Dauern usw. notiert, da dies mit diesen Informationen einfach zu lösen sein sollte. Sie müssen wahrscheinlich feststellen, wann ein Video mit einer nicht ganzzahligen Bildrate codiert ist, und die DF-Korrektur (1000/1001) anwenden, aber der Teufel steckt im Detail. Wenn Sie Beispiele für alle konstanten Werte angeben könnten, die Sie sowohl aus einem 30-fps- als auch aus einem 29,97-Metadatensatz ('Ticks' usw.) extrahieren könnten, dann auch einige Dauerwerte von jedem und die Codes, die sie angeben, können wir sicher herauskitzeln die Infos.
Ich habe jetzt festgestellt, dass ich einige wichtige Informationen ausgelassen habe, und das ist auch die Lösung für mein Problem: Das Problem wird dadurch verursacht, dass ich auch eine von Premiere erstellte EDL einlese und dieser EDL die Information fehlt, ob ein Clip DF oder NDF ist. Wenn mir also mitgeteilt wird, dass der Clip mit 23,976 FPS um 10:00:00:00 beginnt und die Projektdatei von Premiere sagt, dass er um 10:00:36:00 ist, habe ich eine Diskrepanz. Ich habe an der falschen Stelle nach einer Lösung gesucht. Die Lösung besteht darin, die EDL vollständig zu ignorieren - dann gibt es kein Problem.
Premiere .prproj-Datei-Ticks driften um 1/1000 im Vergleich zu Timecodes
AntwortenHierDatenschutz-Bestimmungen1y, 0v