Zum Inhalt springen

Frankz

Mitglieder
  • Gesamte Inhalte

    24
  • Benutzer seit

  • Letzter Besuch

Alle erstellten Inhalte von Frankz

  1. Hast Du ein DCP zum Testen? Doremi 2000 kann ich anbieten. Server-Key per PM? Andernfalls fehlt mir - verdammt - wieder einmal die Zeit ...
  2. 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 ...
  3. 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.)
  4. 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.
  5. 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]
  6. Du hast, da Du hier sehr willkommener Wiese gerade vorbei schaust, nicht zufällig eine Idee, was dem Doremi fehlt? :roll:
  7. 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:
  8. 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 :)
  9. 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 :)
  10. 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
  11. Für Linux-Freunde gibt's hier einen thematisch benachbarten Thread: http://forum.filmvorfuehrer.de/viewtopic.php?t=14634
  12. 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 :)
  13. 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?
  14. 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 :)
  15. 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.
  16. Soweit ich das jetzt habe abklären können, geht es um den Zugriff auf den Projektor - also nicht auf den Server, so wie mir das dargestellt wurde. Der Service-PC solle nötig sein, um systemkritische Operationen auf dem Christie-Projektor ausführen zu können, was der Support eher nicht würde remote machen wollen, so die Auskunft von FTT Düsseldorf. Auf meine Frage, wie häufig ein solcher Zugriff nötig wäre, meinte der Supportler: "Sehr häufig". Die Alternative zum Service-PC bestehe darin, so der Mann weiter, ohne Fernzugriff zu leben und Vororteinsätze zu riskieren - mit entsprechenden zeitl. Verzögerungen. Wer denkt sich so etwas aus? Ein Christie mit Ethernetanschluss, der nur über einen Vorort-PC fernwartbar sein soll??? Warum nicht gleich ein Rechenzentrum vorschalten? Das würde noch mehr Umsatz bringen. EDIT: Habe daraufhin jetzt den Titel des Threads angepasst.
  17. FTT Linz. Ich werde denen mal berichten, dass es auch gegenteilige "Erfahrungen" gibt. Danke jedenfalls für die Rückmeldung. Wäre schön, wenn das noch jmd. aus eigener Erfahrung so bestätigen könnte; aber generell kommt auch mir das neben Pudding's Bericht sehr, sehr logisch vor, dass es ohne gehen muss.
  18. Danke für die Antwort - gemeint war aber eigtl. wohl nicht, dass das nun "zum Betrieb" notwendig sei, sondern die Begründung ging eher dahin, "dass der Remote-Support sich aufschalten" und quasi im Notfall softwareseitig so etwas reparieren könne. Ist eine solche Konstellation denkbar? Ich will ja gar nichts Schlechtes denken, nur verstehen würde ich die Argumentation gern.
  19. Hallo Doremi-Maintainer, könnt Ihr bestätigen, dass für einen Doremi ein externer Support-PC notwendig ist, der vor den Server geschaltet werden muss, weil da irgendwelche Datenbanken drauf laufen? Mir kommt das schräg vor, da es aus netzwerktechnischer Sicht doch völlig egal ist, ob der Support-PC beim Server steht oder 200km weiter weg beim Support (also da. wo er hingehört, wie ich finde). Ich frage, denn wir sollen diesen "notwendigerweise vorzuschaltenden Remote-PC" nämlich kaufen müssen - und natürlich: teuer ist er dazu :(
  20. Lass Dir doch beim Programmieren helfen! Ich könnte das übernehmen, wenn Du willst.
  21. Danke, jetzt funktioniert es; und meine Version war tatsächlich eine ältere, das Flat-CS-Feature gibt's nun also auch - super: Du machst ja Updates wie Brezeln. Da nun ohnehin für eine Diashow eine audio.mxf erstellt wird. könnte man doch eigentlich auch eine vorhandene wav verwenden und unterlegen, meinst Du nicht, reptile? Fände ich sehr brauchbar; zumal man mit der Framelänge im Dateinamen Bild und Ton gut aufeinander abstimmen könnte. So wäre sogar ein "Folien"-Vortrag möglich. Oder Werbedias könnten mit zusätzlichem Text unterlegt sein. EDIT: nicht mal CineAsset kann das mit den Standbildern. Einziger Wermutstropfen beim DCPC ist für mich, dass das mit einem UI nicht unter Linux funktioniert (ich arbeite selber eigtl. nur dann mit Win, wenn es gar nicht anders geht, so wie hier).
  22. Ja, wie versprochen ein Statement: die DCPs laufen also auf dem XDC G3 gut. ist ja sicher auch schon bekannt, so exklusiv ist der G3 ja nicht. Ich habe allerdings ein neues Problemchen beim Erstellen einer Diashow; das Feature "mehrere Bilder" erstellt bei mir kein DCP, es sei denn ich will Schwarzframes und hakle das an. Dann sind aber auch nur diese zu sehen. Es werden auch keine Standbildzeiten abgefragt (habe ich da überhaupt was falsch verstanden?) Es gibt keine Fehlermeldung, nur den obligaten Hinweis, dass das DCP durchaus auch nicht erstellt sein kann. Wahr in diesem Falle; aber warum? Die Tiff's haben die richtige Größe und jedes einzelne davon läßt sich als Einzelbild-DCP erstellen. Noch eine Verständnisfrage: warum ist optional Flat 1998 x 1080 nicht möglich?
  23. Oha - ich bin neugierig, das kann gut sein, dass ich das tmp_2 im Explorer offen hatte... Danke für den Tipp.
  24. Hallo allerseits, bin soeben dazugestoßen - sowohl zum Forum als auch zur digitalen Projektion (XDC G3). 8) Nach ausgiebiger Recherche zum Thema "DCP erstellen" (und zwar zu einem vernünftigen Nichtabzockpreis) kann ich mich dem allgemeinen Dank an REPTILE wirklich nur anschließen. Das ist wirklich genial, REPTILE, wie Du da der Berufsgenossenschaft da aus der Patsche hilfst! Wirklich ganz persönlich 1.000 Dank dafür auch von mir - obwohl ich meine ersten, mit den Tools und der Anleitung hier erstellten DCPs noch gar nicht auf dem G3 getestet habe - Bericht aber folgt! Meine ersten Erfahrung beim Erstellen eines 8-sec.-Standbilds und einer 15-sec-Filmsequenz waren gut. Ich bin dann mutiger geworden und wollte einen 3min-Film erstellen - allerdings ist dann REPTILE's Creator.exe gegen Ende kurz vor dem Fertigwerden gnaden- und vorbehaltlos abgestürzt. Nach 4 Stunden fröhlichem Rechnen. Grund dafür (falls ich so hoffentlich zum Debugging beitragen kann) war, denke ich, das Multithreading. Da ist nämlich der Thread 2 schneller fertig gewesen als Thread 1 (2-Kern-Rechner): Thread 2 hatte dann schnell noch alle seine erstellten j2c-Dateien in den Zielordner für die mxf-Erstellung verschoben und leider zugleich die langwierig erstellten tif's gelöscht, aber unmittelbar danach wohl ist der Creator davon ausgegangen, dass alles fertig ist und ist abgestürzt. Kann es also sein, dass da für den Fall asynchroner Fertigstellung in "falscher" Reihenfolge durch die Threads noch ein Ready-Check fehlt? Ich fände es gut, solange wir alle noch Erfahrungen mit dem Tool sammeln und Debugging wahrscheinlich ist, wenn REPTILE's Creator.exe in eine Art Wiederaufnahmemodus gebracht werden könnte (vielleicht einfach über eine Checkbox), wo dann in solchen Fällen die Erstellung einfach fortgesetzt werden kann und die rechenintensiven Vorgänge (tif- und j2c-Erstellung) als schon erledigt erkannt werden. Da hätte ich Film und Rechenaufwand noch retten können ... Insgesamt: ein tolles Tool und nochmals Dank!
×
×
  • Neu erstellen...

Filmvorführer.de mit Werbung, externen Inhalten und Cookies nutzen

  I accept

Filmvorfuehrer.de, die Forenmitglieder und Partner nutzen eingebettete Skripte und Cookies, um die Seite optimal zu gestalten und fortlaufend zu verbessern, sowie zur Ausspielung von externen Inhalten (z.B. youtube, Vimeo, Twitter,..) und Anzeigen.

Die Verarbeitungszwecke im Einzelnen sind:

  • Informationen auf einem Gerät speichern und/oder abrufen
  • Datenübermittlung an Partner, auch n Länder ausserhalb der EU (Drittstaatentransfer)
  • Personalisierte Anzeigen und Inhalte, Anzeigen- und Inhaltsmessungen, Erkenntnisse über Zielgruppen und Produktentwicklungen
Durch das Klicken des „Zustimmen“-Buttons stimmen Sie der Verarbeitung der auf Ihrem Gerät bzw. Ihrer Endeinrichtung gespeicherten Daten wie z.B. persönlichen Identifikatoren oder IP-Adressen für diese Verarbeitungszwecke gem. § 25 Abs. 1 TTDSG sowie Art. 6 Abs. 1 lit. a DSGVO zu. Darüber hinaus willigen Sie gem. Art. 49 Abs. 1 DSGVO ein, dass auch Anbieter in den USA Ihre Daten verarbeiten. In diesem Fall ist es möglich, dass die übermittelten Daten durch lokale Behörden verarbeitet werden. Weiterführende Details finden Sie in unserer  Datenschutzerklärung, die am Ende jeder Seite verlinkt sind. Die Zustimmung kann jederzeit durch Löschen des entsprechenden Cookies widerrufen werden.