Zum Inhalt springen

carstenk

Mitglieder
  • Gesamte Inhalte

    14.208
  • Benutzer seit

  • Tagessiege

    97

Alle erstellten Inhalte von carstenk

  1. Das geht schneller als man glaubt wenn man mit mehreren Versionen oder Filmen arbeitet und das nicht auf mehrere Verzeichnisse verteilt. Wenn Du das mit dem Log machst - pack die jeweiligen Systemzeiten vielleicht zu jedem Eintrag dazu, dann kann man auch sehr schnell ein Eindruck von der Performance einzelner Module kriegen und da vielleicht noch etwas rumtricksen. Ich vermute, dass gegenwärtig die J2K Kompression am meisten Zeit kostet? Wie sieht es mit der Farbtransformation aus? Angeblich ist Graphicsmagick signifikant schneller als Imagemagick und besser an Mehrprozessorsysteme angepasst. Ließe sich wohl wahlweise einsetzen, oder? - Carsten
  2. Das hier habe ich grade gefunden: 'If you use large numbers of files in an NTFS folder (300,000 or more), disable short-file name generation for better performance, and especially if the first six characters of the long file names are similar.' Könnte recht schnell relevant werden, wenn man seine Verzeichnisse nicht sauber hält respektive mit mehrere Versionen arbeitet. - Carsten
  3. @Reptile: Logfunktion einbauen, dann kann man vielleicht einfacher sehen, woran es hakt bei den div. Modulen, also Aufrück, Rückgabe, etc. in eine Datei schreiben. - Carsten
  4. carstenk

    35mm - 3D

    Nunja, es ist ja schon so, dass dieses Verfahren von einem KOPIERWERK respektive einem Kopierdienstleister entwickelt und angeboten wird und die werden vermutlich kaum der Billigkonkurrenz die Arbeit überlassen. Und natürlich denken die sich bei over/under oder side_by_side schon höhere Kopierqualitäten aus. Sooo fundamental ist der Auflösungsunterschied zwischen over/under und einer BW/Flat Kopie grundsätzlich sicher nicht, zumal wenn Technicolor die Kopierqualität sicherstellt. Die Billigheimer müssen halt draussen bleiben, das ist doch grade die Idee, die Technicolor dabei hat. Nur sollten die dann eben nicht noch Unsummen für die Grundausstattung fordern. - Carsten
  5. http://www.mein-einkaufsladen.de/multim...zAodBgz_RQ
  6. Das geht natürlich - uns war es aber wichtig, auch sehr kurzfristig Änderungen einbauen zu können. Bei uns fliegt z.B. zweimal in der Woche ein Vorschaudia aus der laufenden Präsentation raus und neue kommen rein. Ausserdem brauchen wir in einer anderen Präsentation wahlfreien Zugriff auf bestimmte Dias. Das geht mit einer Videodatei nicht ohne das jedesmal wieder neu zu rendern. - Carsten
  7. Zumindest einer der Kino-Modi benutzt wohl ein lichtschluckendes Filter. Der Dynamik Modus verwendet volle Lampenleistung und maximalen Kontrast. Letzten Endes wirst Du zumindest DVD/BluRay wohl immer im Dynamik-Modus fahren wollen. In diesem Test hier gibts detaillierte Infos zum TW700: http://www.cine4home.de/tests/projektor...00Test.htm Schau Dir vor allem weiter unten im Test mal die Tabelle mit den Helligkeiten an. Bei allen Beamern sind die hellsten Modi von der Farbsättigung her total übertrieben. Faktisch macht das bei Werbung nix, und selbst bei Filmen ist es so, dass durch die geringere Helligkeit bei dieser Leinwandgröße diese Sättigung nicht mehr so übertrieben wahrgenommen wird, das Auge geht da schon langsam ins Nachtsehen über. Siehe auch die Diskussionen über die Projektionshelligkeit 2D/3D. Automatik-Blende IMMER an! Sonst überstrahlt das Beamer-Bild in die 35mm Projektion, solltest Du im Vorprogramm mal beide Geräte gleichzeitig an haben. Wir spielen bei uns überhaupt nicht mehr an den Projektorsettings rum. - Carsten
  8. Immer drauf achten, dass das Ding im hellsten Modus läuft. Der Beamer schaltet bestimmte Einstellungen je nach gewählter Eingangsquelle um bzw. hat Speicher für jeden Eingang. Die muss man zu Anfang besser mal alle auf den hellsten Modus setzen. Die Software für DualScreen kann man sich an einer Hand abzählen, das ist leider nicht so viel. In der Doku zur Aquasoft Diashow sehe ich nirgendwo erwähnt, dass eine explizite Ausgabe auf den sekundären Monitor möglich ist. Probier halt mal mit der Testversion rum, dann wirst Du schon sehen. Wir haben bei uns gelegentlich die Geräte durch die Projektionsfenster bedienen können, wenn wir sie darauf hin positioniert hatten, aber das war immer Bastelei. Es gibt billige Infrarot-Verlängerungen im Hifi/Video Zubehör, um z.B. in Schränken untergebrachte Geräte von außen bedienen zu können. Da kann man sich einen Empfänger in den Saal und ggfs. mehrere Sender in den BWR verkabeln, dann kann man ggfs. Beamer und Player/PC aus dem Saal fernbedienen. - Carsten
  9. Hast Du irgendwo ne Übersicht? Ich meine, dass 2D/3D grundsätzlich schon die anderen Formate doppelt, ist ja nicht wirklich ner Erwähnung Wert, oder? - Carsten
  10. carstenk

    Kinogeburten

    Wenn das Ding wirklich schon entkernt ist wird ihm nichts anderes übrig bleiben. Aber vielleicht benennt er das Kino ja auch um in 'Loft-Kino Hamburg' ;-) - Carsten
  11. 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
  12. 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
  13. Geht hier weiter: http://forum.filmvorfuehrer.de/viewtopic.php?t=13952 - Carsten
  14. 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
  15. 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
  16. Bis 2015 könnte das eng werden... - Carsten
  17. 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
  18. 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
  19. 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
  20. carstenk

    Kinogeburten

    Das ist doch ein Fake! 'Schwabe investiert'.... tss, tss... ;-) - Carsten
  21. 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
  22. 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
  23. 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
  24. Unter welchen Umständen gibts 35mm Massenware denn überhaupt legal zu erwerben? Unter gar keinen, oder? - Carsten
  25. Die Interlock-Nummer könnte man doch den 'Kinderchen' sogar mal zeigen, oder? - Carsten
×
×
  • 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.