Frage zu DCP-O-Matic

[egc]

Wenn ich das also richtig verstehe, kann ich anhand der Ausgabe der Videoplayer nicht erkennen, in welchem Farbraum das Video exportiert worden ist, sprich, yuv bedeutet nicht unbedingt rec709 (in der Regel schon, aber halt nicht immer).

Das ist jetzt nicht mehr so wichtig, aber nur aus Neugier: gibt es dann überhaupt ein Programm, das einem die Auskunft über den tatsächlichen Farbraum gibt?

 

LG

Andreas

[carstenk]

Ich schätze, die meisten Programme werden das nicht explizit kommunizieren, weil die ebenso selbstverständlich davon ausgehen, dass es rec709 ist.

 

Wie man an dem oben von mir eingebundenen Link nachlesen kann, gibt PRORES im Header nicht nur einfach sowas wie 'rec709' an, sondern sogar explizit die Farbraumparameter für HD und SD Formate. Ich kenne aber auch kein Programm, mit dem man sich die Header anzeigen lassen kann.

 

https://documentatio...on=4&tasks=true

 

ProRes unterstützt durchaus auch RGB, das ProRes4444 ist ja z.B. explizit für Compositing Anwendungen als RGBA Format ausgelegt.

 

Wie gesagt, in der Regel reicht es, rec709 anzunehmen. Wer für DCI Projektoren arbeitet, sollte sich das Material ohnehin auf einem Kinoprojektor incl. Ton anschauen und anhören, das ist sonst ziemlich fischen im Trüben.

 

- Carsten

Bearbeitet 24. April 2015 von carstenk (Änderungen anzeigen)

[magentacine]

Eine Frage zu DCP-O-MATIC Version 1.81.0 - 32bit:

 

Ich möchte einen kleinen Dokumentarfilm encodieren, der mir als Prores-File vorliegt. Wird erkannt, als 16:9 im 1.85-Container gepadded, alles soweit kein Problem.

 

Allerdings habe ich den Ton als WAV-Einzeldateien L-R-C-LFE-LS-RS geliefert bekommen. Ist es möglich, diese zu verwenden und wenn ja, wäre das hier der richtige Weg? Eigenschaften der Tondatei anwählen, dann auf den gewünschten Kanal mappen?

 

Für kundige Hilfe wäre ich dankbar... :rolleyes:

 

 

Oder welcher Weg ist sonst möglich?

Bearbeitet 8. August 2015 von magentacine (Änderungen anzeigen)

[magentacine]

Nachtrag: Habe inzwischen diesen Thread gelesen, wenn ich Carstens Erläuterung dort richtig verstehe, kommt es darauf an, die Zuordnung der Dateien genau einzustellen, damit sie nicht sequentiell in die Timeline eingefügt werden. Beim vorhandenen (2-Kanal)-Ton der Videodatei habe ich dementsprechend alle kanal-Kästchen weggeklickt.

[carstenk]

In der Timeline Ansicht kannst Du dann auch sehen, ob Du es richtig gemacht hast, die diskreten Kanäle liegen dann dort untereinander, nicht nebeneinander. Es gibt bei separaten Audiodateien keinen funktionierenden Automatismus, die einzelnen Kanäle in der Matrix zu belegen, das muss man dann in der Tat manuell zuweisen. Normalerweise positioniert DCP-o-matic reine Audiodateien immer parallel zum Video. Ansonsten kann man die unter 'Timing' auch alle auf Start=0 setzen.

 

 

Statt die existierenden eingebetten/interleaved audio Kanäle eine Composite Files in der Matrix auszuknipsen, kann man in der Timeline Ansicht auch einen Rechtsclick auf einen Stream machen und dort 'Remove' auswählen. Ist aber funktional das gleiche (Kann man auch später wieder in der Matrix reaktivieren). Ist manchmal ganz praktisch, das Interleaved file im Hintergrund zu behalten, falls man Synchronprobleme mit den separaten diskreten Dateien vermutet.

 

- Carsten

Bearbeitet 9. August 2015 von carstenk (Änderungen anzeigen)

[magentacine]

Danke, Carsten!

 

Ich war etwas unsicher, weil die farbigen Balken in der Timeline bei mir nicht dargestellt werden, die Dateinamen stehen aber wie in Deinem Screenshot ordentlich untereinander, Startpunkt ist auch für alle Null. Ein Grafikproblem, das sich demnächst hoffentlich mit Installation eines neuzeitlichen Betriebssystems und neuer Hardware lösen wird.

Bearbeitet 9. August 2015 von magentacine (Änderungen anzeigen)

[carstenk]

Das Timelinefenster ist übrigens nicht nur eine Übersicht, sondern enthält auch Drag'ndrop- und andere Funktionalitäten, man kann die einzelnen Elemente dort also auch grafisch mit der Maus anordnen:

 

 

 

- Carsten

Bearbeitet 9. August 2015 von carstenk (Änderungen anzeigen)

[magentacine]

So, bin einen Schritt weiter: Alle 6 Einzelfiles wurden korrekt zu einem 6-Kanal-Audio-MXF zusammengerechnet, das DCP geschrieben. Alle üblichen dateien liegen im Zielverzeichnis. Im Stereoscopic Player funktioniert Abspielen prima, beim Ingesten auf dem Doremi DCP-2K4 kommt aber folgende Fehlermeldung:

 

failed to scan index table

failed to open jpeg2000 mxf

(folgt eine Zeile mit Pfad zum J2K-MXF)

mxf_indexify failed

ingest errors detected

 

Also habe ich die beiden MXFs mittels DCPC re-wrapped. Doremi verweigert wieder mit gleicher Meldung.

 

Nach einigem Überlegen fiel mir ein, daß die Audiodateien vorn 2 Sekunden und hinten 24 Frames länger waren. Ich hatte alle 6 Audiospuren auf

 

Trim from Start = 0:0:1:24

 

gestellt. Den "Überhang hinten habe ich ignoriert.

 

Eben habe ich nun zusätzlich

 

Trim from End= 0:0:0:24

 

gesetzt. Die unten angezeigte Gesamtlänge ist jetzt für Videodatei und Audiodaten framegenau identisch.

 

Lasse jetzt das DCP neu erstellen - trotzdem schon mal die Frage: Mache ich einen Fehler? Oder ist es die bessere Vorgehensweise, die Tonspuren ungetrimmt zu lassen und einfach 2 Sekunden Schwarzclip vor dem Hauptfilmblock einzusetzen?

 

Wenn auch nach einem Rewrapping der Fehler auftritt, auf welche Eigenschaft(en) der MXFs könnte es noch zurückzuführen sein?

 

Fragen über Fragen...ich danke herzlich für Antworten und Vorschläge...

Bearbeitet 12. August 2015 von magentacine (Änderungen anzeigen)

[carstenk]

Dubios. DCP-o-matic sorgt selbst dafür, dass Audio und Video korrekte Länge haben - normalerweise... Jegliche Trimmwerte sollten normalerweise nur zu einem mehr oder weniger synchronen Ton führen, aber nicht zu einem ungültigen DCP.

 

Wenn Du mir die Metadaten des problematischen Projektes mal zukommen lässt, kann ich Carl mal drauf ansetzen.

 

Obwohl sich die Fehlermeldung eher danach anhört, als ob das Video-MXF einen Strukturfehler enthält.

 

- Carsten

[magentacine]

Wenn es mit der neuen Version nicht klappt, würde ich morgen etwas zusammenstellen. Einstweilen danke!

[carstenk]

Wie lang ist der Bildteil denn? In der Regel wird man durch strukturiertes Probieren da weiterkommen - z.B. den Bildteil mal neu, ganz ohne Ton rechnen (DCP-o-matic erzeugt dann selbst eine stille Tonspur). Dann sehen, was passiert. Hängt freilich davon ab, wie lange das dauert respektive wie schnell der eigene Rechner ist.

 

Ist merkwürdig, ich erzeuge im Testbetrieb und für andere Projekte sehr viele DCPs, auch mit kruden Optionen aber hatte noch nie Probleme mit dem Ingest, wenn ich mich recht erinnere. Eigentlich ist DCP-o-matic, von gelegentlichen Bugs natürlich abgesehen, sehr solide darin, gültige DCPs zu erzeugen.

 

- Carsten

[magentacine]

Ja, ich hatte bei unzähligen Trailern, Kurzfilmen und zwei (für ein Festival) untertitelten und neugerechneten Langfilmen auch kein Problem damit. Ich lasse jetzt das Bild neu rendern, auch wenn es anderthalb Tage dauern wird.

 

Der Film hat 82 Minuten, kommt aus einem Prores-MOV mit 25 B/s, der Ton von sechs Mono-WAV-Dateien (vom Tonstudio, das die 5.1.-Mischung gemacht hat).

 

Eine Frage, die ich weder im Manual noch im Forum finden konnte: Was hat es eigentlich mit der "Signiert"-Option auf sich, wann soll man sie anwählen und wann nicht?

 

Und wäre es möglich, in zukünftige Versionen von DCP-O-MATIC eine Validationsfunktion zu integrieren, damit man das erstellte DCP schon prüfen kann, bevor es auf den Server geht?

[HaraldSchaefer]

Hallo Magentacine

 

Ich würde ein DCP immer mit einer anderen Software als der zur Erstellung genutzten prüfen. Nur so können systematische Fehler erkannt werden. Ein gutes Tool ist DCP-Inspect. Das ist ein Befehlszeilen Skript und läuft unter Linux. Tammo hatte aber vor einigen Tagen gepostet, dass sie ein GUI dafür gebaut haben. Damit sollte die Bedienung dann einfacher werden.

 

DCP Inspect hat ganz nebenbei den Vorteil im Quelltext verfügbar zu sein. Sollte es Probleme geben, so kann man sie auch versuchen selbst zu beheben.

 

Gruß Harald

[carstenk]

Eine Frage, die ich weder im Manual noch im Forum finden konnte: Was hat es eigentlich mit der "Signiert"-Option auf sich, wann soll man sie anwählen und wann nicht?

Im Grunde ist die ausserhalb kommerzieller DCP Erstellung nicht essentiell. Sie fügt den Metadaten eine Signatur hinzu, über die sich nötigenfalls prüfen lässt, ob das DCP auf dem Weg von der authorisierenden Quelle zum Ziel manipuliert wurde. Mögliche Szenarien dafür sind z.B. die Unterscheidung internationaler von lokalisierten Versionen, Einhaltung von FSK Freigaben, VPF Abrechnung, etc, Selbst im kommerziellen Kinoumfeld spielt das aber kaum eine Rolle. Im Falle von DCP-o-matic ist es ohnehin so, dass ein Zertifikat des Programms verwendet wird, das auf den Programmierer zurück geführt wird, nicht auf denjenigen, der das DCP damit erstellt hat. Man könnte freilich auch seine eigene Zertifikatskette einbauen, wenn man das für nötig hält, bei kommerziellen Masteringtools ist das üblich. Ich habe bisher nie erlebt, dass die Option eine Rolle gespielt hat beim Ingest. Ich habe sie standardmäßig angehakt. Bei verschlüsselten DCPs ist es keine Option mehr, da muss grundsätzlich signiert werden.

 

Ausserdem würde ich gegenwärtig immer noch Interop erzeugen. In deinem Fall ist es allerdings 25p Material, da muss man sich entscheiden, ob man die formale Verletzung der Interop-Spec mit 25fps in Kauf nimmt, auf 24fps verlangsamt, oder ein korrektes SMPTE DCP mit 25fps anlegt. Offenbar haben die zuletzt kommerziell verteilten 25fps Interop-DCPs aber kaum zu Problemen geführt (nur der alte DSS100/DSP100 hat ein Problem damit). Von daher darf man im Grunde guten Gewissens 25fps Interops erzeugen.

 

 

Ansonsten: Ja, DCP Inspect, mit oder ohne GUI, ist das Mittel der Wahl.

 

- Carsten

Bearbeitet 14. August 2015 von carstenk (Änderungen anzeigen)