carstenk

Ich würde es ja in 'Kopienbefunde' packen, aber im Allgemeinen ist die Größe der DCPs ja nun wirklich nicht wichtig. Aber der Größenunterschied zwischen der US/UK und den anderen europäischen AVATAR 3D Versionen ist nun vielleicht doch kein ganz uninteressanter Punkt: Hier nochmal die Zahlen von GW1972 für deutsche DCPs: Bloody Valentine 3D: 154 GB Ice Age 3D: 147 GB Final Destination 3D: 140 GB G-Force 3D: 117 GB Christmas Carol 3D: 107 GB Avatar 3D: 154 GB Fleischbällchen 3D: 148 GB Ein Franzose hat das hier beigesteuert: Ice Age 3D: 148 GB Christmas Carol 3D: 103 GB Avatar 2D: 186 GB Avatar 3D: 155 GB MeatBalls 2D: 106 GB Final Destination 2D: 131 GB G-Force 3D: 120 GB Der Unterschied zwischen AVATAR 2D und 3D scheint zwar auf den ersten Blick auffällig (je nach Sichtweise zu groß oder zu klein), ist aber vollkommen normal meiner Einschätzung nach. Ein Italiener berichtet ebenfalls von 156GByte für AVATAR 3D. Ein Finne berichtet von 149GByte für eine finnisch untertitelte 3D Version Hierbei muss man bedenken, dass das nachträgliche Untertiteln von 3D Filmen gar nicht so trivial ist und der in der DCI-Norm vorgesehene Standard-Ansatz mit Echtzeit-Untertitlung nicht geht, weil er kein 3D unterstützt. Man muss die Untertitel also in das Material reinrechnen, und auch das ist nicht einfach, weil man es nicht einfach irgendwo in die stereoskopischen Szenen platzieren kann. Es sei denn, grundsätzlich deutlich vor der Leinwandebene schwebend. Ich könnte mir auch vorstellen, dass man mit dem PNG/Subpicture Feature 3D Titel optional einblenden könnte. Aber auch die würden mit einiger Sicherheit die Stereoskopie heftig stören wenn sie nicht penibelst an die Szene angepasst würden. Streng genommen kann ich mir nachträgliche Untertitelung bei 3D Filmen nur UNTER dem Bild vorstellen. Weiss jemand, wie AVATAR in Holland diesbezüglich gespielt wird? Also unterm Strich sehen die 156GByte für 162min AVATAR im Vergleich zu den anderen DCPs eher normal aus als die 276GB für die US/UK Version. Hier habe ich EINE mögliche Erklärung: http://forum.filmvorfuehrer.de/viewtopi...&start=191 Die aber nicht erklärt, warum überhaupt für Europa ein erneutes Encoding durchgeführt wurde. Ausserdem: Es gab ja im Vorfeld des AVATAR Releases reichlich Verwirrung über die verschiedenen Bildseitenverhältnisse der div. AVATAR Versionen. Wenn ich das richtig gesehen habe, dann ist AVATAR aber doch in Deutschland mit Ausnahme von IMAX-3D überall in Scope gespielt worden, also sowohl 2D+3D DCI als auch 35mm? In USA gabs da wohl tatsächlich ein totales Formatdurcheinander. Jedes Kino sollte da wohl Versionen kriegen, die die verfügbare Leinwand maximal ausfüllen, je nachdem ob Top- oder Side-Masking benutzt wird. IMDB sagt: 1.78 : 1 (2K 3-D version, constant image width venues) 1.78 : 1 (IMAX 3-D version) 2.35 : 1 (2-D version) 2.35 : 1 (2K 3-D Version, constant image height venues) Hat irgendjemand in Deutschland die erste Version gespielt/gekriegt? - Carsten

Bis 2015 könnte das eng werden... - Carsten

Ja, das entscheidende ist halt, die richtigen einzustellen, und eben ggfs. ein Monitoring der Datenrate zu machen. Im Prinzip müsste man die Größe jedes Frames auf die von mir zitierten Werte aus der DCI spec checken und notfalls die Parameter dynamisch anpassen. Sicher nicht unmöglich, da die Bilder ja alle einzeln verarbeitet werden. Ein bißchen Luft ist da sicher drin, allzu präzise muss das sicher nicht eingehalten werden. Gegenwärtig kann man das ja notfalls durch einen nachfolgenden directory-check der J2Cs machen - der gestern von mir ausgepackte Werbetrailer schwankt z.B. zwischen 1100 und 600KByte pro Frame in den Realfilmanteilen - liegt also in den Spitzenwerten schon ziemlich nah an den 1,302,083 bytes per frame - obwohl das eigentlich ziemlich softes hochgerechnetes Video zu sein scheint. J2C Verzeichnis nach Größe sortieren, und wenn es da deutlich zu hoch wird, nochmal neu mit anderen Parametern. Von daher wäre es sinnvoll, wenn Du an irgendeiner Stelle einen Zugriff auf die Kompresionsparameter erlaubst, und wenn es vorläufig nur durch unmittelbaren Zugriff auf die cmdline parameter per ini-file o.ä. ist. - Carsten

Kann man sicherlich etwas streamlinen - da es ja ein intraframe codec ist, reicht ja schon ein einzelnes Bild. Rauschen ist ja traditionell problematisch für diese Codecs. Aber natürlich wäre ein bißchen real-life footage schöner. Vielleicht kann man die Programmierer des J2C codecs auch mal daraufhin anhauen, die werden sicher eher mit den Parametrisierungen der DCI spec was anfangen können. Solange man nur 'für den eigenen Server' kodiert, ist das ja noch kein Problem, kann man ja alles testen, aber wenn man dann womöglich mal was verbreitet aus einer echten FullHD Quelle und beim einen oder anderen Server wird dann der Decoder überfahren und steigt aus... Ich bin ziemlich sicher, dass die Server sich nicht strikt auf die DCI-Toleranzen festlegen lassen. Sprich, beim einen mag ne höhere Datenrate kein Problem sein, beim anderen mag es aussetzen sobald man deutlich über 30MByte/s geht. Allein das wäre ja mal lustig auszutesten mit ein paar abgestuften Testsequenzen, die man rumschickt und auf die verschiedenen Server lädt. Soviele verschiedene Server gibts ja glücklicherweise nicht. Jetzt noch ne Scarlet, ein FinalCut-System (mit Bootcamp Windows ;-)... - Carsten

Ich muss mich doch mal endlich näher mit den Einzelkomponenten des Paketes befassen, aber welche Optionen bietet denn die J2C Komprimierung darin überhaupt an? In der DCI-Spezifikation stehen die Codestream Specs ziemlich detailliert drin, aber das geht deutlich über meinen diesbezüglichen Background Ob man aus dem normgemäßen DCI-Testfilm ggfs. die 'richtigen' Parameter reverse-engineeren kann? Irgendwann hatte ich mir sowas mal runtergeladen, jetzt scheint es das Ding nur noch gegen Kohle auf Datenträgern zu geben. Man könnte natürlich auch irgendein anderes DCP aus 'offiziellen' Quellen nehmen. - Carsten

Das ist doch ein Fake! 'Schwabe investiert'.... tss, tss... ;-) - Carsten

Ich glaube nicht, dass man das J2C in den DCPs bei 12Bit ausschließlich in der verlustlosen Variante einsetzen kann. Das haut nicht hin mit den Datenratenlimits der DCI spec. Selbst wenn man optimal packt sind 2k bei 12Bit 10Mbyte/frame. Erlaubt sind aber maximal 30Mbyte pro Sekunde/24frames. Ohne verlustbehaftete Komprimierung geht da nix. Bei den bisherigen Versuchen hat vermutlich noch niemand Material benutzt, was datenratenmäßig an die Grenze geht? ---- For a frame rate of 24 FPS, a 2K distribution shall have a maximum of 1,302,083 bytes per frame (aggregate of all three color components including headers). Additionally, it shall have a maximum of 1,041,666 bytes per color component per frame including all relevant tile-part headers. • For a frame rate of 48 FPS, a 2K distribution shall have a maximum of 651,041 bytes per frame (aggregate of all three color components including headers). Additionally, it shall have a maximum of 520,833 bytes per color component per frame including all relevant tile-part headers. • A 4K distribution shall have a maximum of 1,302,083 bytes per frame (aggregate of all three color components including headers). Additionally, the 2K portion of each frame shall satisfy the 24 FPS 2K distribution requirements as stated above. Note: For information purposes only, this yields a maximum of 250 Mbits/sec total and a maximum of 200 Mbits/sec for the 2K portion of each color component ---- Wie läuft das denn gegenwärtig - Du kannst keine Maximalrate garantieren in der Konvertierung, oder? Wäre sicherlich sinnvoll, wenn man ein Check-Fenster mitfloaten ließe, das bei Überschreiten der erlaubten Datenrate Alarm schlägt? Ist ja alles sehr zeitaufwendig und je früher man bei Problemen benachrichtigt wird, desto besser. Pre- oder Postflight-Check hatten wir ja grade schonmal andiskutiert. Ist schon wichtig, denn wir erzeugen hier ja zeitintensiv ein Produkt, dass man nicht mal eben am eigenen Rechner durchtesten kann. Bevor man damit auf einen Server geht, sollten die offensichtlichsten Probleme schon ausgeräumt sein. Jedenfalls wenn das Tool mal Leute benutzen, die nicht jeden Tag einen DCI-Server in der Nähe haben. - Carsten

JPEG nur als Kompatibilitätskompromiss. Ausserdem ist J2C ja auch komprimiert ;-) Vielleicht kannst Du dir ja ffmpeg mal anschauen. Das erledigt sicher auch noch ein paar andere Aspekte an der Konvertierung, Audio, etc. Grundsätzlich kann die Bildkonvertierung aus Bewegtbild ja als Einzelbildpipeline arbeiten - also immer nur ein Bild als Zwischenprodukt, statt die komplette Sequenz vorhalten zu müssen. Bei verlustfrei komprimierten 2k Einzelbildsequenzen überschlage ich grob 50MByte pro 24p-Sekunde. Bei den meisten Anwendern sind zwar regelmäßig die Platten gähnend leer, aber das ergibt dennoch 3GByte/min und 180GByte/h nur für ein nicht wirklich benötigtes Zwischenprodukt. Mir ist klar, dass Unterstützung für Videoformate ein Fass ohne Boden ist, aber grundsätzlich sollte ffmpeg ja gehen, und das erledigt dann alles an Codecunterstützung. Aber ich habe da sicherlich auch nicht alle technischen Aspekte der Einzelmodule und Abläufe auf dem Schirm. Mal ein bißchen für Verbreitung sorgen und Feedback abwarten. Wer sind die Zielgruppen: Hier aus dem Forum resultierend Kinobetreiber/Vorführer mit eher geringen Anforderungen - Standbilder, Pausendias, ggfs. gelegentlich mal Trailer/Werbekonvertierung. Die andere Zielgruppe sind semiprofessionelle bis professionelle Videoleute, die neben den üblichen Videoformaten ggfs. jetzt auch mal fürs Kino arbeiten, ohne die großen Pakete kaufen zu wollen. In der Regel wird man bei diesem Qualitätsanspruch dann eher ungern auf ein verlustbehaftetes Zwischenformat setzen wollen. Die werden gegenwärtig eher direkt Einzelbilder aus dem Schnittprogramm ausgeben lassen oder einen verlustlosen bzw. sehr gering komprimierenden Intermediate Codec mit hoher Farbquantisierung nehmen. Ausserdem muss man natürlich bei längeren Sequenzen auch bedenken, dass effektive verlustbehaftete oder auch verlustfreie Komprimierungen enorme zusätzliche Rechenzeiten, wiederrum NUR für ein Zwischenprodukt bedeuten. Wenn man sich den Platz leisten kann, wäre also ein optionales Format sinnvoll, das am schnellsten geschrieben und gelesen werden kann. - Carsten

Nochmal drüber grübeln, was da von der Masse am ehesten wirklich gebraucht wird und was übliche Plattformen von Haus aus können. Grundsätzlich ist es natürlich wichtig, dass die Anwendung durchgängig 16 bzw. 12Bit unterstützt, aber das eine oder andere 'normale' Format sollte der Einfachheit halber schon drin. JPEG z.B. für Digiknipsen wäre schon sinnvoll - wie gesagt, viele werden einen gewissen Bedarf an DCP-Standbildern oder einfachen Bildsequenzen haben, ohne dafür Videoschnittsoftware o.ä. bemühen zu wollen. Das wäre also das 'kleine' Anforderungsprofil. Anderer Aspekt: Sobald man anfängt, Bewegtbild zu konvertieren werden Einzelbildsequenzen in 2k enorm groß. In JPEG2000 zu ertragen, aber die verlustfrei komprimierten Zwischenformate aus der Video->Einzelbildkonvertierung tragen ganz schön auf, wenn man das z.B aus ner FullHD Quelle bezieht. Siehst Du ne Möglichkeit, eine direkte Anbindung für irgendwelche Videoformate oder einen universellen Konverter anzuflanschen - z.B. ffmpeg? - Carsten

Unter welchen Umständen gibts 35mm Massenware denn überhaupt legal zu erwerben? Unter gar keinen, oder? - Carsten

Die Interlock-Nummer könnte man doch den 'Kinderchen' sogar mal zeigen, oder? - Carsten

Alles nur ne Frage von Leinwandgröße und Sehabstand. Und Anspruch. Ich würde keine DVD zeigen, wenn 35mm zum gleichen Preis zu kiegen ist. Interlock ist natürlich ein gewisser Zusatzaufwand, aber unter solchen Aufführungsumständen überwiegt da der sportliche Aspekt, oder? - Carsten

Repertoire gibts halt noch selten als DCP, und seltenere Sachen noch nichtmal auf BluRay. Und für den Verleih ist das indiskutabel, dann extra ein DCP zu erstellen. Die werden sicher kein DI im Zugriff haben. Der Film muss gescannt und der Ton bearbeitet, das ganze gemastert werden, etc. Und die DVD will man wohl nicht wirklich zeigen. Da die Rechte für 35mm eh das gleiche kosten, würde ich da sicher 35mm vorziehen. - Carsten

Der Windows mplayer ist auch der einzige, der bei uns hier eingesetzt wird. - Carsten

Den gibts auf dem sekundären Monitor glücklicherweise nicht. - Carsten

BluRay Player gibt ab 100 Euro. Wenn das ne einmalige Sache ist, ist 35mm sicherlich die billigere Variante. Ton muss ja auch angebunden werden. Ausserdem müssten ja beide Projektoren in jedem Fall HDMI/HDCP können. Wie weit sind die Projektoren denn voneinander entfernt, gemeinsamer BWR? Unterschätz mal nicht den Aufwand einen kompletten Film in 'ordentlicher' Qualität zu transcodieren. Das dauert ewig und Du brauchst vermutlich auch mehrere Anläufe. Und wie gesagt eine 100 Euro teure und dennoch illegale Software zum Rippen der BluRay. - Carsten

Dafür musst Du erstmal illegale Software kaufen, um die BluRay auszulesen. Aber spätestens das macht doch sowieso keinen Sinn mehr - da schließt man direkt den Player an den Projektor an. - Carsten

Genau solche Sachen sind eben die Nachteile. Alles kein Problem, wenn man selbst das Ding bedient, aber wir haben da halt wechselndes Personal. Solange die Leinwand durch Fehlbedienungen schlimmstenfalls dunkel bliebe, wäre das kein Problem, aber wenn das Publikum da Rumhampeleien mit Fenstern und Maus zu sehen kriegt, nee sowas ist dann nix für den Alltagsbetrieb. - Carsten

Klar, einbauen kann man es, aber es wäre dann halt immer noch ein vollkommen eigenständiges Modul, weil es nichts mit der eigentlichen Konvertierung mehr zu tun hat. Da ist halt die Frage, ob man das nicht lieber als commandlinetool entwickelt und dann aus deiner 'Hauptanwendung' aufruft. Da es streng genommen keines der anderen Konvertierungsmodule benötigt, wäre es schlanker und ohne die 'Vollinstallation' zu benutzen. Was sicher sinnvoll für deinen Konverter wäre: Die wesentlichen Parameter und beigesteuerten Dateien schon vor dem Beginn der Konvertierung zu analysieren und ggfs. auf problematische Aspekte hinzuweisen, also einen Parametercheck, das spart dann vielen sicherlich lange Wartezeiten auf Dateien, die dann hinterher sicher doch Ärger machen. - Carsten

Wenn es in deinem Tool drinsteckt, würde zumindest vom gegenwärtigen Arbeitsablauf her ja nur das vom Tool selbst erstelle DCP 'kommentiert'. Wäre aber doch gerade auch nützlich, fremd erstellte DCPs auf die wesentlichen Parameter hin checken zu können.

Und, gibts dazu schon was Neues? - Carsten

Es gibt halt einige Anwender, die schlicht annehmen, das jeweils verwendete Tool würde automatisch 24Bit erzeugen. Das macht aber wohl selbst der teure FHG EasyDCP nicht und beschwert sich wohl auch nicht, wenn man ihm 16Bit zu fressen gibt. Wenn Du eh schon dabei bist - mach doch noch so einen einfachen 'Analyser', der zu einem DCP die naheliegendsten Infos ausspuckt, einfaches Commandline Tool. - Carsten

Ich würde für Dolby jedenfalls sicherstellen, dass es 24Bit Stereo sind. 16Bit scheint jedenfalls auf dem Dolby Server nicht zu klappen, und auf Mono würde ich noch weniger wetten. - Carsten

Haben die Dinger Ton? Kürzlich wurde mal erwähnt, dass die Dolbys scheinbar sehr anspruchsvoll sind was die genaue Einhaltung des Tonformates angeht. Kann der EasyDCP Player die Dinger anzeigen? Vielleicht mal sicherheitshalber nicht als MPEG2/Interop erstellen. - Carsten

http://oscar.go.com/nominations/films Wie erwartet oder erhofft Christoph Waltz als bester Schauspieler in einer Nebenrolle in Inglourious Basterds (Wer hatte eigentlich ne Hauptrolle in dem Streifen...;-) 'Das weisse Band', wie Preston schon im AVATAR thread schrieb, ist nominiert für bester ausländischer Film und beste Kamera. - Carsten