carstenk

Nee, die DCI spec sagt ja, dass bei 3D jedes Bild nur noch halb so groß sein darf wie bei 2D. Die Qualität geht also auch etwas runter. Bei 2D knapp 1.3MByte/frame, bei 3D 650KByte/frame. Hier aus der Doku zu OpenJPEG2000: * Maximum Bit rate for entire frame = 1302083 bytes for 24 fps, 651041 bytes for 48fps Du hast also die gleiche Datenrate wie bei 2D. Und gerade vor diesem Hintergrund ist es eben merkwürdig, dass unsere AVATAR Version dann soviel kleiner ist als die US. Aber im Vergleich zu den anderen genannten 3D Filmen scheint es von der Länge her dann eher normal zu sein. Man darf also für 3D auf keinen Fall zwei 'normale' 2D Codestreams erzeugen und dann interleaven, die müssen auf jeden Fall mit der Option 'Cinema2k 48' erzeugt werden, sonst hast Du die doppelte Datenrate. Hast Du das bei der Dual-Prozessorvariante so gemacht? Wenn Du von Oceanic mal Testmaterial kriegst, kannst Du ja mal schauen, was für Datenraten das liefert. Ich denke im Übrigen schon, dass es kein Problem wäre, für jedes Bild einen optimalen Parametersatz zu verwenden. Innerhalb einer Sequenz unterscheiden sich die Signalkomponenten ja nicht großartig voneinander. Nur bei sehr schnellen Bildänderungen würden die Kompressionsparameter also drastisch wechseln. Und da wechselt ja auch unser Auge seinen 'Blick' ohnehin massiv. Und obendrein liegen die Kompressionsartfekate bei JPEG2000 und diesen Kompressionsraten ja ohnehin noch deutlich unter der Wahrnehmungsschwelle. Und wenn sowas bei extremeren Anforderungen deutlich sichtbarer wäre, müsste man es halt glätten, die Parameteränderungen also fließend gestalten. Bei hochwertiger MPEG2 Konvertierung für DVD ist das ja auch durchaus kritisch, da werden auch szenenbasiert die Kompressionsparameter angepasst. Pro Bild geht da natürlich nicht mehr, weil es ja auch ein interframe codec ist. image_to_j2k kennt aber auch nunmal immer 'nur' das aktuelle Bild und weiss nichts vom vorhergehenden oder folgenden, von daher müsste man sowas eben extern nachrüsten. Muss mal ein bißchen mehr damit rumspielen um zu sehen, was da passiert mit den Datenraten. Grundsätzlich ist JPEG2000 ja so aufgebaut, dass man nicht erst einen kompletten Kompressionsvorgang abwarten muss um die resultierende Datenmenge durch Neukompression variieren zu können. Der zeitaufwendige Teil ist ja die Wavelet-Transformation. Erst danach findet durch geeignete Wahl der Parameter die Entscheidung statt, was weggelassen wird. Und offensichtlich macht image_to_J2k das eben dort. Ausserdem hat JPEG2000 im Unterschied zu JPEG auch eine Möglichkeit, direkt einen Kompressionsgrad vorzugeben, mit der '-r' Option ('Each value is a factor of compression, thus 20 means 20 times compressed.') Bei normalen JPEG gibt es nur einen etwas abstrakten Qualitätsparameter, der aber keine Zieldatenrate garantiert. - Carsten

Hmm, also wenn dein Tool immer noch image_to_j2k.exe verwendet, was auf OpenJPEG basiert, und wenn man hier: http://www.openjpeg.org/index.php?menu=doc Mal nach unten scrollt und bei den Cinema2K/4K profiles liest, dann garantiert zumindest dieser JPEG2000 Encoder mit diesen settings, dass die zulässige Datenrate nicht überschritten wird. Wie auch immer er das macht. Also wohl kein Problem. - Carsten

Geht hier weiter: http://forum.filmvorfuehrer.de/viewtopic.php?t=13952 - Carsten

Nee, der J2C codestream enthält keinerlei separate Informationen mehr darüber, welche Parameter verwendet wurden, wobei mit Sicherheit einiges an Information dennoch aus dem Muster extrahiert werden könnte, wenn man richtig Ahnung von diesem Algorithmus hat Aber das mit dem Datenratenmonitoring ist doch nicht ganz uninteressant, wenn Du mal überlegst, wie das irgendwann mal mit Material in Filmlänge und aus echten 2k Quellen aussehen würde, von 4k mal ganz abgesehen. Du kannst nicht einfach davon ausgehen, dass das schon passt, bzw., je nach verwendeten Parametern verschenkst Du eben Qualität. Schau Dir mal den thread 'DCP Größen/AVATAR' an. Da geht's um den bisher unerklärlichen Größenunterschied zwischen der deutschen/europäischen und der US/UK Version (156GByte/276GByte). Wenn es dafür keine anderen Erklärungen gibt - Ich versuche mal eine: Beim europäischen Encoding hat man eine konservative Kompression gewählt, die bei konstanten Kompressionsparametern an keiner Stelle im Film die erlaubte maximale Datenrate übersteigt. Daraus ergibt sich eine mittlere Datenrate von 16MByte/s bzw. 670kByte/3Dframe. An einigen Stellen im Film können die erlaubten 30Mbyte/s durchaus erreicht worden sein. Der größte Teil des Films liegt aber deutlich darunter. Die US Version erreicht konstante 28Mbyte/s - das heisst aber, sie kann in keinem Bereich wesentlich höher oder niedriger als 1180KByte/3Dframe liegen. Das geht über 162min Realfilm, egal wie hoch der CG Anteil da ist, nur, wenn man JEDES Bild optimal auf eine Zieldatenrate komprimiert. Anders lässt sich eine mittlere Datenrate so dicht unter dem erlaubten Maximalwert nicht realisieren. Das wäre jedenfalls mal meine Vermutung. Mag sein, dass professionelle Software dafür eine zeitsparende Prädiktionsfunktion hat, im anderen Falle müsste der Kompressor sich ggfs. durch Mehrfachkompression an die richtigen Parameter rantasten. Also im Prinzip hat man bei der US/UK Version eine ConstantBitrate Kompression durchgeführt, und bei der europäischen eine VariableBitrate Kompression. Da JPEG2000 das als intraframe Kompression nicht direkt unterstützt, muss man das eben durch externes Monitoring und ggfs. Rekompression machen. Für allgemeine Anwendungen scheint das ein sehr hoher Zeitaufwand zu sein, aber für eine Produktion wie AVATAR und mit den dafür verfügbaren Tools ist sowas natürlich kein Kriterium. - Carsten

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