Frankz

Hast Du ein DCP zum Testen? Doremi 2000 kann ich anbieten. Server-Key per PM? Andernfalls fehlt mir - verdammt - wieder einmal die Zeit ...

Also die DCP's so, wie eingangs beschrieben, laufen auf dem Doremi DCP-2000 ohne Probleme. Auch ohne Ton. Wer sich mit Linux auskennt, sollte auf jeden Fall Doremi in die engere Wahl nehmen. Ich bin - im direkten Vergleich mit XDC - begeistert. Allein die Tatsache, dass der Doremi ein zusätzliches redundantes Netzteil eingebaut hat (der XDC nicht) spricht Bände. Das Zusammenspiel mit dem Christie macht einen flüssigeren Programmablauf möglich, braucht z.B. für Formatumschaltungen viel weniger Zeit. Der XDC macht z. B. ungefragt eine (völlig überflüssige) 10-sec-Formatumschaltung bei gleichem Bildformat, wenn ein stummes DCP auf ein normales 6-Kanal-DCP folgt, der Doremi nicht. Nach nur einem Tag kann ich sagen: Mann, bin ich froh, dass ich das Windows-XP-Chkdsk beim Hochfahren nicht mehr sehen muss :D Dazu kommt, dass ich die Programme im Büro an meinem Arbeitsplatz-PC schreiben kann, da ich mich per VNC direkt vor den Doremi beamen kann. Mal ganz abgesehen davon, dass SSH-Zugang selbstverständlich ist. Ihr merkt schon, ich bin schon ganz off topic ...

Wie ist der Stand der Dinge bei Dir? Hast Du noch etwas probiert oder geht's immer noch nicht? (Wir bekommen in ca. 1-2 Wochen auch einen Doremi, dann kann ich mir das direkt ansehen.)

Oh, danke für den Anstoß - natürlich sind Hardlinks in diesem Fall viel besser! (Sorry für späte Antwort, aber ich komme zufällig vorbei und habe gar keine Benachrichtigungsmails mehr bekommen - auch für andere Threads nicht :( ) Dein Projekt zu testen muss ich leider verschieben - ist momentan etwas eng mit der Zeit.

Da steht in der ASSETMAP nicht noch zufällig file:/// bei den Dateipfaden? (Schritt 5 der Anleitung oben, vorletzte Zeile => sed evtl. misslungen?) Poste bitte mal den Inhalt der ASSETMAP[.xml]

Du hast, da Du hier sehr willkommener Wiese gerade vorbei schaust, nicht zufällig eine Idee, was dem Doremi fehlt? :roll:

Müssen muss er sicher nie. Aber er kann bei seinem Chef eine wohlwollende Aufmerksamkeit forcieren, wenn der plötzlich nach einem Trailer unerwartet ein kurzes Nachstandbild sieht: "Ab 15. Juli in den Breitenseer Lichtspielen" :idea:

Es geht ja in diesem Thread um "Film"-Herstellung nach einer digitalen Vorlage. Das ist nun nicht eigentlich das Brot des "Filmvorführers", eher das der Zulieferer seines Brotherrn. Und naja, einen 35mm-Film konntest Du ohne Kopierwerkskosten doch nie bekommen - hier im digitalen Bereich geht es gewissermaßen darum, wie "Vorführer" hinsichtlich der einen oder anderen Anforderung das Kopierwerk und dessen Kosten auslassen können - was zweifellos ihren Marktwert steigert, aber nicht unbedingt ausmacht :)

Aha, der erste Doremi-Versuch :) Die Fehlermeldung beanstandet etwas nicht Zugehöriges zum mx format; hast Du alles genau so gemacht wie eingangs beschrieben? Vielleicht hat die Meldung ja aber auch zu bedeuten, dass ihm eine Audio-MXF fehlt?! Ich hatte das für das stumme Standbild-Beispiel weggelassen, weil es beim XDC G3 einfach so (auch ohne Audio-MXF) funktioniert - versuch einmal, eine 240 Frames lange wav-Audiodatei zu erstellen (geht gut mit Audacity) und dazuzutun. Dieses "Dazutun" von Audio gestaltet sich, unter der Annahme, dass ein beliebige 10 Sek. lange (passend zur Standbild-Zeit) Stereo-wav-Datei im aktuellen Ordner liegt, z.B. so: Zwischen Schritt 3 und 4 (s. Eingangsbeitrag): AUDIO=`ls | grep wav` # convert to PCM 24bit at 48k and create audio.mxf ffmpeg -i $AUDIO -ar 48000 -acodec pcm_s24le -ac 2 $AUDIO asdcp-test -v -L -c audio.mxf $AUDIO Sollte jetzt eine Klage über eine unvollständige Framelänge die Folge sein, so ist dies völlig normal. Es bedeutet, dass die Anzahl der Audio-Frames evtl. um 1 kürzer ist als die Anzahl der Bild-Frames; dann muss man im j2c-Ordner vor Erstellung des Video-MXF das letzte Bild-Frame löschen, denn Audio und Video müssen unbedingt die gleiche Frame-Anzahl aufweisen. Mittels asdcp-test -i -H audio.mxf | grep ContainerDuration: | cut -d' ' -f3 kannst Du vor Erstellung des Video-MXF die Audio-Främelänge in Deinem Script testen. Bei mir lautet die komplette diesbzgl. Routine nach Erstellung des Audio-MXF so: if [ `ls j2c | wc -l` -gt `asdcp-test -i -H audio.mxf | grep ContainerDuration: | cut -d' ' -f3` ] then rm `ls j2c | tail -n1` # remove last created j2c picture if [ `ls j2c | wc -l` -gt `asdcp-test -i -H audio.mxf | grep ContainerDuration: | cut -d' ' -f3` ] then echo "Unexpected error: number of audio and video frames has to be equal!" echo "audio frames: `asdcp-test -i -H audio.mxf | grep ContainerDuration: | cut -d' ' -f3`" echo "video frames: `ls j2c | wc -l`" echo "You have to adjust the length of your audio source file $AUDIO" rm audio.mxf exit 1 fi fi Schritt 5 mit Audio: mkdir Dia_Show mv video.mxf Dia_Show/video.Dia_Show.mxf mv audio.mxf Dia_Show/audio.Dia_Show.mxf cd Dia_Show mkcpl --kind feature --issuer my@e-mail.de --title Dia_Show --annotation Dia_Show \ --norating video.Dia_Show.mxf audio.Dia_Show.mxf > Dia_Show.cpl.xml mkpkl --issuer my@e-mail.de --annotation Dia_Show video.Dia_Show.mxf audio.Dia_Show.mxf Dia_Show.cpl.xml > Dia_Show.pkl.xml mkmap --issuer my@e-mail.de video.Dia_Show.mxf audio.Dia_Show.mxf Dia_Show.cpl.xml Dia_Show.pkl.xml sed -i 's/file:\/\/\///' ASSETMAP.xml cd .. Schließlich kann auch noch sein, dass Doremi anstatt einer ASSETMAP.xml und einer VOLINDEX.xml Dateien dieses Namens erwartet: ASSETMAP und VOLINDEX, also schließlich: mv ASSETMAP.xml ASSETMAP mv VOLINDEX.xml VOLINDEX Lasset hören :)

Hallo Michael, genau: denn nach der letzten Zeile des 3. Schrittes oben: cd j2c; rm $tmp_files ; cd .. wird ja zum Schluss wird wieder in das übergeordnete Verz. von "j2c/" gewechselt, was Du evtl. übersehen hast. Interessant für mich wäre, ob und unter welcher Servertype das bei Dir geklappt oder auch nicht geklappt hat. Ich selbst kann dzt. nur auf einem XDC G3 für 2D testen. Schöne Grüße

Für Linux-Freunde gibt's hier einen thematisch benachbarten Thread: http://forum.filmvorfuehrer.de/viewtopic.php?t=14634

Wer die Kommandozeile mag, kann sich DCP's - zur Gänze mithilfe von OpenSource-Software - auch unter Linux erstellen. Hier stelle ich eine mögliche Methode vor, um die benötigten Programme unter Ubuntu Karmic Koala (9.10) oder Ubuntu Lycid Lynx (10.4 LTS) zu installieren. Banal genug, sind dazu nur 3 Zeilen in der Shell notwendig: sudo add-apt-repository ppa:tim-klingt/opencinematools sudo apt-get update sudo apt-get install ffmpeg imagemagick openjpeg-tools opencinematools Die benötigte asdcplib wird dabei als von den opencinmatools abhängiges Paket automatisch mitinstalliert. ffmpeg ist nötig, um Filme in Einzelbilder umzuwandlen, notwendige Audio-Extraktionen vorzunehmen und/oder Audiodateien in das benötigte uncompressed 24bit-PCM umzuwandeln. Wer will, kann sich jetzt völlig freispielen: Standbilder, Filme, Formate, Zielplattformen, Audio - alles ist über Parameter steuerbar und kann, einmal in Shell-Scripts gespeichert, mit ein oder zwei kurzen Befehlen je nach den eigenen Bedürfnissen schnell zum benötigten DCP führen. Im Folgenden gebe ich ein Beispiel, wie ein oder mehrere 10-Sek.-Standbilder im gängigen Flat-Format 1:1,85 (bzw. 1998x1080) für die 2k-Plattform in 2D produziert werden können. Ich gebe die einzelnen Schritte an (ein Skript an dieser Stelle wäre wohl zu wenig flexibel): Ausgangsmaterial sind hier die (möglichst gut aufgelösten) Bilder im jpg-, tiff-, bmp-, png-Format in einem Unterverzeichnis namens tiff. Aus diesen Bildern wird eine stumme "Diashow" erstellt, die im Kino gezeigt werden soll, während z. B. die Pausenmusik noch weiterläuft. Schritt 1: Vorbereitungen ls tiff sollte uns das gewünschte Ausgangsmaterial listen: bild.png zeitung.tiff demnaechst.jpg Wir errzeugen zudem ein temporäres Verzeichnis für die zur Video-mxf-Erstellung benötigten j2k-Dateien: mkdir j2c Schritt 2: Konvertierung des Bildmaterials Jetzt werden die im Verz. tiff gefundenen Bilder in einem Schritt auf die richtige Größe gebracht, in den XYZ-Farbraum konvertiert, und, sofern das Seitenverhältnis nicht zum Flat-Format passt, auf schwarzem Hintergrund zentriert. Dieser Schritt muss bei einem Film einmal je Frame passieren und ist dann sehr rechenintensiv und zeitaufwendig. Wir machen das aber hier nur einmal je Bild (es geht ja nur um Standbilder): for f in $(ls tiff) do echo -n "Converting tiff/$f ... " convert -compress none -resize 1998x1080 -alpha Off -depth 12 -gamma 0.454545 \ -recolor "0.4124564 0.3575761 0.1804375 0.2126729 0.7151522 0.0721750 0.0193339 0.1191920 0.9503041" \ -gamma 2.6 -type truecolor tiff/$f -background black -gravity center -extent 1998x1080 tiff/$f.tiff image_to_j2k -cinema2K 24 -i tiff/$f.tiff -o j2c/$f.j2c > /dev/null 2>&1 rm tiff/$f.tiff > /dev/null 2>&1 echo Ready. done Schritt 3: Erzeugung der benötigten Frames in j2c Dieser Schritt spart eine Menge Rechenzeit: die nur einmal je Standbild erzeugten j2k-Bilder werden je nach gewünschter Standzeit in Sekunden mit 24 multipliziert, entsprechend oft vervielfältigt und schließlich durchnummeriert (hier hartkodiert 240 Mal je Bild): tmp_files=`ls j2c` typeset -i round=0 typeset -i no=0 echo -n "Multiplying files inside j2c dir ... " for file in $tmp_files do round+=1 for c in $(seq 1 1 240) do no+=1 cp j2c/$file j2c/`printf %06d $no`_Dia${round}_$file done done echo Ready. cd j2c; rm $tmp_files ; cd .. In der letzten Zeile oben werden die nicht mehr benötigten j2k-Ausgangsbilder, die nötig für den Kopiervorgang waren, innerhalb des Verz. "j2c" gelöscht, da sie bei der Erstellung des mxf-Videos stören würden. Schritt 4: Erstellung der mxf-Datei Nach diesem Schritt sind wir fast schon durch: asdcp-test -v -L -c video.mxf j2c Schritt 5: Erstellung des DCP Ich gebe hier dem Paket einmal den Titel "Dia_Show" und erstelle es mit folgenden Befehlen im gleichnamigen Unterverz.: mkdir Dia_Show mv video.mxf Dia_Show/video.Dia_Show.mxf cd Dia_Show mkcpl --kind feature --issuer my@e-mail.de --title Dia_Show --annotation Dia_Show \ --norating video.Dia_Show.mxf > Dia_Show.cpl.xml mkpkl --issuer my@e-mail.de --annotation Dia_Show video.Dia_Show.mxf Dia_Show.cpl.xml > Dia_Show.pkl.xml mkmap --issuer my@e-mail.de video.Dia_Show.mxf Dia_Show.cpl.xml Dia_Show.pkl.xml sed -i 's/file:\/\/\///' ASSETMAP.xml cd .. Die vorletzte Zeile entfernt das störende file:/// aus der ASSETMAP, da windowsbasierte Server darauf allergisch reagieren. Den Ordner Dia_Show kopiert ihr jetzt auf Euren Stick und könnt das dann gemütlich auf den Server bringen. Vielleicht gibt es ja hier noch mehr OpenSource-Freunde - dann würde ich mir wünschen, dass das hier zu einem Ort lebhaften Skripttauschens wird. Denn mit ffmpeg und den hier genannten Tools lassen sich avi's, DVD's, Quicktime-Dateien und weiß-der-Geier-was auf die Bildwand bringen :)

Du willst sagen: Ihr setzt so etwas ein?! In welcher Konstellation? Ein Remote-Rechner für mehrere Christies (oder einer je Christie)? Wie sind Eure Zugriffe auf den selbstgestellten Rechner limitiert? Oder dürft Ihr Euch etwa mit Euren gekauften Remote-Rechnern auf Eure gekauften Christie's aufschalten - mit allen Rechten?

Bei XDC-Servern hat es den Anschein, als würden die Dinger sehr viel öfter getauscht werden müssen als Doremi's. Vielleicht kann das ja wer dementieren :)

Das Ganze ist übrigens bei einem Christie/XDC-Pärchen sowieso gegeben, da von der XDC-Windows-Kiste aus mithilfe von Windows-Programmen (um die geht es dabei wohl) direkt per Eth.-Kabel auch Remote-Zugriffe auf den Projektor durchgereicht werden. Bei Doremi geht das nicht, weil diese Progrämmchen auf Linux halt nicht laufen :) - daher dann die "Forderung" nach einem Vorschaltrechner.