Frage von carstenkurz:Vielleicht gibts ja hier einen Besitzer eines i7-4930K Rechners, der Lust hat, ein paar Minuten mit einem Benchmark eines Programms zur DCP-Erstellung zu verschwenden. Zeitaufwand inkl. Download der Dateien etwa 5-10min.
Ist öffentlich verfügbare etablierte Software, da wird also nix untergeschoben. Wenn derjenige aus dem Raum Köln stammt, könnte ich auch was zur Kompensation anbieten, Kinokarte, oder eine Session auf unserem 4k Projektor...
Wenn Interesse besteht, hier melden, dann tauschen wir Emailadressen aus.
Es geht speziell um einen Multithread-Benchmark auf dieser i7-4930K CPU, die restliche Ausstattung des Systems ist egal.
- Carsten
Antwort von freezer:
Reicht Dir der Vorgänger Hexcore für den Test? Ich hätte den i7-980 mit 3,33 GHz.
Antwort von fsm:
kann die ergebnisse meines 3930k geben. 200MHz weniger.
Antwort von DV_Chris:
Hätte hier 2 x 6-Core Xeon zum Testen (24 logische Kerne).
zorronetwayat
Antwort von carstenkurz:
Ich bin natürlich auch an anderen CPUs interessiert.
Es gibt zwar für einige dieser Typen schon publizierte Benchmarks, aber die sind größtenteils mit einer sehr alten Version erstellt worden.
Und natürlich wäre speziell die Linie i7-980 -> i7-3930 -> i7-4930 ganz interessant ;-)
Chris - was für ein Xeon ist das genau? Im Grunde geht es mir genau um den Vergleich Xeon - 4930.
Ich kann Euch Links auf die Originalquellen geben, würde aber eventuell ein Komplettpaket Software und Testdateien aus meiner DropBox verlinken.
Da lege ich dann auch eine Anleitung rein.
Wie gesagt, viel Arbeit ist es nicht, und DCP-o-matic ist auch ne sehr schlanke Installation, die nix im System großartig manipuliert.
Man muss halt nur die wenigen elementaren Dinge befolgen, damit der Benchmark aussagekräftig ist, speziell, die richtige Anzahl an Threads im Programm einstellen. Der Benchmark selbst dürfte auf diesen Rennern nur 2min laufen, wer will kann ihn nochmal mit 1-2 anderen Threadsettings wiederholen (dazwischen muss man allerdings immer das gesamte vorher erzeugte DCP löschen, bis auf die Projektdatei und das Quellmaterial).
Zum Warm werden
http://dcpomatic.com/benchmarks/fps
- Carsten
Antwort von blickfeld:
Das verlinkte Proggi ist der letzte Mist. Unterstützt nicht wirklich Multiprozessing, man kann das Ziellaufwerk nicht selbst bestimmen, sehr sinnvoll, wenn man von raid-array 1 auf raid-array 2 encodieren möchte und auch gerne sein raid-array 3 als Cache nutzen möchte (oder ich bin zu doof dazu, was auch sein mag).
Für nen Benchmark 0 aussagekräftig.
Antwort von carstenkurz:
(oder ich bin zu doof dazu, was auch sein mag).
In diesem Fall wohl letzteres ;-) Es unterstützt Multithreading sehr effektiv, und natürlich kann man Quell- und Ziellaufwerk frei wählen. Da es typischerweise aus komprimierten Quellen IN komprimierte Quellen arbeitet, ist die Festplattenperformance auch ziemlich egal dabei, es benötigt so gut wie kein Festplattencaching, jedenfalls wenn der Rechner auch nur ansatzweise ne sinnvolle RAM Ausstattung hat. Vielleicht mal noch ein bißchen damit beschäftigen, dann sollte das klarer werden.
Im Übrigen geht es nicht um allgemeine Aussagen zu diesen Prozessoren, dafür gibts tausende Benchmarkseiten im Netz. Es geht gerade darum, wie DIESES Programm sich auf verschiedenen Prozessoren verhält.
- Carsten
Antwort von blickfeld:
(oder ich bin zu doof dazu, was auch sein mag).
In diesem Fall wohl letzteres ;-)
Dann sag mir doch bitte mal, wo man das Ziellaufwerk wählen kann.
Man kann ein Laufwerk wählen, wo das Projektangelegt wird und man kann die Quelldateien wählen.
Das Projektlaufwerk ist anscheinend auch automatisch das Ziellaufwerk, was impliziert, dass es KEINE Auswahl des Ziellaufwerks gibt.
Und ja, die Multiprosessornutzung ist schlecht. Außer Du willst andeuten, dass 64 GB RAM zu wenig sind ;). Der 3930K kommt auf schlechte 15 % Auslastung.
Antwort von carstenkurz:
Ich empfehle mal, die Einstellungen zu konsultieren...
Und ansonsten, deinem 3930K nur das Rechnen, aber nicht das Denken zu überlassen ;-)
-> Default Directory for new films.
Das Quellmaterial kann dort liegen, wo es auch immer liegt. Damit hast Du getrennte Pfade für Quelle(n) und Ziel. Aber wie gesagt, bei max 1MByte/frame und geschätzt max 6-8fps Encoding Geschwindigkeit ist da auch nicht viel zu optimieren was die Platten angeht, das schafft jede lahme Gurke. Es kommt wirklich maßgeblich auf die CPU an.
Und unter 'General' die Anzahl der Threads mindestens auf 12 stellen, ggfs. auch mehr.
Die Geschwindigkeit ist im Übrigen stark inhalteabhängig, es macht nur Sinn, einen der beiden 'offiziellen' Benchmark Trailer von der o.a. Site zu nehmen. Ich habe zwischen Vollschwarz und Farbrauschen einen Faktor 5 beim Encoding gemessen. Deswegen das verbindliche Testmaterial. Ausserdem sind beide Trailer unter CreativeCommons Lizenz und machen keinen Ärger beim Weitergeben. Der BigBuckBunny läuft nur ein paar Minuten. Der Sintel kann Stunden dauern, daher lieber den kleinen probieren. Aber wer Lust hat, kann natürlich auch den Sintel mal über Nacht durchjagen. Aber auch den bitte nur mit den 'offiziellen' Metadaten bzw. Projektfile, die Einstellungen beeinflussen die Geschwindigkeit natürlich ebenfalls drastisch.
Das Paket mit dem Installer, der Anleitung und den Testdaten ist gerade unterwegs in die Dropbox. In der Anleitung steht auch die Emailadresse, an die Ihr die Logs schicken könnt.
Wichtig - wenn man mehrere Durchläufe machen will, muss man zwischendurch immer alle Daten im Zielverzeichnis ausser dem Projektfile, den Quelldaten und dem Log löschen. Das Programm erlaubt Modifikationen bestimmter DCP Parameter OHNE Neuberechnen der J2K Bilder. Startet man einfach ein 'neues' Make DCP, werden nur die vorher berechneten Bilder kopiert und das Ding ist in wenigen Sekunden fertig.
- Carsten
Antwort von carstenkurz:
So, hier ist das Testpaket mit allen nötigen Dateien, hat ca. 38MByte, Download geht fix. Am besten das ZIP einfach auf den Desktop entpacken und alles dort abwickeln, dann bleibts übersichtlich. Das DCP, das erzeugt wird, hat etwa 550MByte Größe. Der Sintel wird natürlich deutlich größer (20GByte).
https://dl.dropboxusercontent.com/u/558 ... public.zip
- Carsten
Antwort von DV_Chris:
Wird morgen erledigt!
Antwort von TheBubble:
So, hier ist das Testpaket mit allen nötigen Dateien, hat ca. 38MByte, Download geht fix.
Was für Eingabefiles benutzt Ihr normalerweise? Auch Videofiles oder eher TIFF-Sequenzen bzw. DCDMs?
Antwort von DV_Chris:
Chris - was für ein Xeon ist das genau? Im Grunde geht es mir genau um den Vergleich Xeon - 4930.
Es werden 2 x Intel Xeon E5-2630 v2 (6x 2.60GHz) zum Test verwendet werden, die bis 3.10GHz übertakten können und nur 80W TDP haben.
Antwort von carstenkurz:
Was für Eingabefiles benutzt Ihr normalerweise? Auch Videofiles oder eher TIFF-Sequenzen bzw. DCDMs?
Das hängt davon ab. Die meisten standalone DCP-Generatoren benutzen ja nur Einzelbildsequenzen. Das ist in der Regel okay, wenn man mit entsprechend hochwertigem Material direkt aus einer Produktionsumgebung kommt.
Die Stärke von DCP-o-matic ist aber, dass es (u.a.) FFMPEG als Input-Frontend benutzt und daher sowohl Einzelbildsequenzen als auch beliebige Videocodecs direkt entgegen nehmen kann. Daher wird es vorrangig benutzt, um ohne Umweg über Einzelbildsequenzen existierendes Material wie Werbung, Trailer, Kurzfilme, etc. direkt in ein DCP zu konvertieren. Es ist dadurch auch sehr platzsparend, man kann sich vorstellen, wieviel Aufwand es z.B. ist, eine Bluray erstmal in unkomprimierte TIFFs zu schreiben und die dann durch einen DCP-Generator zu schicken.
Ursprünglich fing das Programm ja mal als DVD-o-matic an, als einfacher Direktkonvertierer für DVD Inhalte in DCPs. Viele Kinos benutzen das Programm nun, um die gelegentlich anfallenden BluRays für eine Vorführung in ein DCP zu konvertieren, weil sich damit über die Kinoserver zuverlässiger arbeiten lässt als über die tendenziell unzuverlässigen Scheiben/Player. Wir kriegen auch öfter mal Kurzfilme, Werbung, etc. in üblichen Codecs und machen die Konvertierung für unser Projektionssystem selbst.
Wir könnten das auch von einem PC abspielen, aber in der Regel ist die Einbindung von DCPs in unsere Abläufe einfacher und sicherer, es gibt keine Probleme mit Ruckeleien, falschen Bildraten, Asynchronitäten, etc., wie sie beim Abspiel über PCs immer mal wieder auftreten.
Die DCI-Kinoserver unterstützen ausschließlich ein sehr eng spezifiziertes J2C, so dass es damit im Grunde nie zu irgendwelchen Problemen kommt, die bei den ganzen üblichen Computercodecs gang und gäbe sind.
- Carsten
Antwort von carstenkurz:
Chris - was für ein Xeon ist das genau? Im Grunde geht es mir genau um den Vergleich Xeon - 4930.
Es werden 2 x Intel Xeon E5-2630 v2 (6x 2.60GHz) zum Test verwendet werden, die bis 3.10GHz übertakten können und nur 80W TDP haben.
Cool, merci!
- Carsten
Antwort von TheBubble:
@carstenkurz:
Danke für die Beschreibung, wie und woraus Ihr DCPs erzeugt.
Antwort von ralfkoeln:
sitze in köln carsten,
mit gesuchtem prozessor ;-)
werd ich morgen mal austesten!
grüsse,
ralf
Antwort von carstenkurz:
Ja prima! (wenn's dich interessiert - bist gerne mal nach Frechen in unser Kino eingeladen, ist ja nicht so weit von dir)
Habe heute schon erste Ergebnisse von Chris auf einem i7-980 bekommen. Da Männer ja gerne untereinander vergleichen ;-) und konkrete Zahlen die Sache interessanter machen, hier mal ein paar Werte zum Anteasen und besser machen, vielleicht fühlen sich ja noch mehr Leute herausgefordert.
Testdaten inkl. Programm, Anleitung und Emailadresse:
https://dl.dropboxusercontent.com/u/558 ... public.zip
Und, falls sich die Frage aufdrängt - nein, es gibt leider noch keine OPENJPEG Implementierung für GPUs, daher sind alle freien DCP-Konverter auf CPU-Power angewiesen.
Nach allem was ich weiss bringt das Programm seine Bibliotheken alle selbst mit und installiert keine fremden Codecs o.ä., etc. im System. Man muss also keine Angst haben, seinen Schnittrechner mit irgendwelchen halbgaren Komponenten auf Systemebene zu versauen.
- Carsten
Antwort von carstenkurz:
So, hier die Zahlen von Chris' DualXeon System, wie zu erwarten bisher der Spitzenreiter:
- Carsten
Antwort von DV_Chris:
Das schaut doch recht vernünftig für den Mini Xeon aus ;-) Die CPUs sind im übrigen luftgekühlt mit 40 Euro Standardlüftern, ATX Netzteil von bequiet und das alles in einem Midi Gehäuse.
Die Cinebench R15 Ergebnisse sind ebenfalls beeindruckend:
2 x Intel Xeon E5-2630v2
1 x GeForce GTX 760 2GB
64 GB Ram
Windows 7 Professional SP1
OpenGL = 89.86 fps
CPU = 1529 cb
CPU (Single Core) = 110 cb
==================
Mac Pro, anyone?
Antwort von fsm:
wie lade ich das angefuegte xml?
Antwort von DV_Chris:
wie lade ich das angefuegte xml?
Du musst den Ordner angeben, wo der File liegt.
Antwort von fsm:
kann bei Inhalt /
+ ordner hinzufügen -> kommt no valid images found
+ datei hinzufügen -> das 480p.mov klappt
+ datei hinzufügen -> das .xml fehler metadata.xml konnte nicht geöffnet werden
......
habs glaub ich, "einfach" bei öffnen den ordner angeben
Antwort von fsm:
hab einen durchlauf geschafft, wenn ich jetzt auf Bearbeiten/Einstellungen gehe stürzt er ab. gerade neu installiert, stürzt immer noch ab. das erste ergebnis schick ich mal ein.
Antwort von carstenkurz:
In der englischen Version unter 'File->Open' den Benchmark Ordner auswählen, in dem die Datei Metadata.xml liegt.
Dann sollte, sofern man alle Testdaten in den gleichen Ordner ausgepackt hat, die Datei trailer_480p.mov unter 'Content' erscheinen, eventuell (je nach Pfaden) mit einem 'Missing' davor. ggfs. Rechtsclick darauf und mit 'Find missing' die mov Datei noch einmal zeigen.
Dann nach einem Check der eingestellten threads unter 'Preferences' auf 'Jobs -> Make DCP'.
Was Du mir gerade geschickt hast, sieht aber gut aus, Ferenc.
Wenn Du noch Lust hast, lösch die erzeugten Dateien nochmal, bis auf metadata und den trailer, und versuch es nochmal mit 24 threads. Bei diesen CPUs hat sich 'Overthreading' bisher immer ausgezahlt, das kitzelt meistens nochmal so 10-20% mehr raus.
Ah, ich sehe gerade in deinen Logs, dass Du nicht die metadata.xml, also das Projektfile, geladen hast, sondern nur direkt unter 'Content' die Trailerdatei. Dadurch lief der Benchmark bei Dir mit den Grundeinstellungen des Programms, aber nicht mit den Projektvorgaben aus der Metadata.xml. Das macht es nicht ganz vergleichbar, weil anders skaliert und komprimiert wird. Wenn's nicht zuviel Mühe macht, probier es doch nochmal, so wie ich es Dir in der Mail geschrieben habe.
Typisch, man benutzt ein Programm schon lange und hält es für zwingend, dass es so zu bedienen ist wie man es gewohnt ist. Aber wenn gleich nach dem Programmstart auf dem Hauptbildschirm ein 'Add File' ganz oben liegt, ist es nachvollziehbar, dass man als Neueinsteiger erst mal damit startet.
Man sollte als Programmierer gelegentlich mal jemandem über die Schulter schauen, der das Programm zum ersten Mal startet ;-)
- Carsten
Antwort von Bodis.tv:
@DV_Chris
auch nicht schleicht deine kiste, habs mal auf meiner getestet.
2x Xeon E5 2690 2.9GHz mit 128GB RAM
bin auf 65 Sec gekommen
Die Cinebench R15 Ergebnisse sind ebenfalls beeindruckend:
2 x Intel Xeon E5-2690
1 x GeForce GTX 680
128 GB Ram
Windows 7 Professional SP1
OpenGL = 78,41 fps
CPU = 2186cb
CPU (Single Core) = 115 cb
Antwort von carstenkurz:
Huch, jetzt komme ich garnicht mehr hinterher mit dem Aktualisieren ;-) Neue Zahlen, die von bodis kommen gleich ...
Leider noch kein 4930k dabei, könnte aber noch kommen. Sieht spannend aus, diese Single-CPU 6kerner 980X/3930k schlagen sich ziemlich gut, und wenn man den Preis berücksichtigt... Leider konnte fsm keinen Test mit 24 und 36 threads machen, da käme der 3930 sicher in Richtung 9fps. Und gezielt übertakten ließen sich die Dinger ja auch noch, wenn man denn wollte...
Aber man sollte natürlich schon dazu sagen, dass das alles erstmal nur für dieses eine Programm gilt. Kommerzielle Applikationen werden sehr viel mehr Aufwand in die Auslastung von Mehr-CPU Systemen stecken können.
Ich habe ausserdem die Liste mal erweitert um eine Spalte HwThreads. Direkt vor EncThreads sieht man so das Verhältnis der (immer gleichen) Anzahl der logischen Kerne/Threads im Prozessor/System gegenüber den im Programm eingestellen Encoding-Threads.
Also nachvollziehbar, dass ein DualXeon6CoreHT System also 2CPU*6Cores*2HT = 24HwThreads 'hat'.
- Carsten
Antwort von carstenkurz:
So, weil die Liste zu umfangreich für's schnelle Überblicken wurde habe ich das Ganze mal eingedampft u.a. auf die Höchstwerte je Maschine und um weitere Aspekte wie Thread/Core Effizienz erweitert.
Wie zu erwarten ist bodis.tv Spitzenreiter, allerdings bleibt der 2*8Core etwas unter seinen Möglichkeiten. Habe auch gerade erst bemerkt, dass er ähnlich wie fsm bei seinem ersten Test nicht das Metadatenfile geladen hat, sondern nach Programmstart das Quellmaterial mit den Programmgrundeinstellungen gerendert hat (sehe ich im Log an der JPEG2000 Datenrate 100MBit/s statt 200MBit/s aus den Metadaten). Das verschafft ihm einen kleinen Vorteil. Ausserdem würde mit Sicherheit bei noch einmal verdoppelter Threadeinstellung noch mehr rauskommen.
Ich weiss aber von einem früheren Test mit einem Dual-2687 System, dass das Programm bei sehr vielen Cores diese nicht mehr optimal auslasten kann, weil nur das J2k Encoding effizient parallelisiert ist, nicht aber der Prä- und Postprozessor. Irgendwann so ab 12-15fps klemmt der, die vielen J2K-Threads 'verhungern' und dann lässt sich nur noch über die Taktrate eine Steigerung erzielen. Das konnte man bei dem Dual-2687 auch im CPU Monitor sehen, da dümpelten die logischen Cores alle nur so bei 35-50% Auslastung herum.
SingleCPU Spitzenreiter ist derzeit fsm mit dem 3930K. Warum der 4930k von Ralf dahinter zurück bleibt, kann ich nicht ganz nachvollziehen. Soweit ich weiss ist der 3930k von fsm nicht gezielt übertaktet sondern läuft mit der normalen 3.2GHz Grundfrequenz. Vielleicht bremst ein AV-Programm den 4930k oder sowas. Also wenn noch jemand anders mit einem 4930k mitliest, der Spitzenplatz für Single-CPU Systeme wäre fsm ggfs. noch abzujagen ;-)
Schonmal Danke an alle Teilnehmer unseres kleinen Wettkampfes ;-)
- Carsten
Antwort von Bodis.tv:
in deinem XML file sind bei mir 100MBit angegeben !
bei 200MBit komme ich auf 1:09
was ich nicht unterschreiben kann, das "große" Tools multiprozessing gut unterstützen. :-(
Premiere hat da gewaltige Schwächen.
z.B. denoiser (red) oder der Verkrümmungsstabilisierung (wer sich das Wort ausgedacht hat, gehört geschlagen)
Was ich aus meinen "Nutzungstest" sagen kann ist, das eine höhere Taktung in der Praxis immer noch mehr bringt als mehr Kerne
Antwort von ralfkoeln:
zum 4930er....er hatte das footage nicht auf der SSD liegen...kann es daran liegen? ansonsten war alles normal eingestellt, sagt der kollege.
gibts noch was zum benchmarken? macht spass ;-)
würde ja gerne mal einen vergleich geforce - quadro machen.
Antwort von fsm:
damit ich/wir nicht nur unsere rechner hinhalten sondern auch was dabei lernen mal zum programm selber eine Frage: so wie es aussieht, wandelt das programm etliche formate in jpg2000 verpackt in ein mxf op1a. Jetzt kann ich da nur 2k und 4k finden, für mich als"normalo TV zulieferer wäre eine wandlung nach op1a in HD wesentlich nutzbarer. Dann noch der naive wunsch in dnxhd oder avcintra. Gibts da versionen die das können oder kann man das irgendwo einstellen?
Antwort von carstenkurz:
Ahhh, das ist der richtige Sportsgeist ;-) - fsm hat seinen 3930k mal auf 4.2GHz hochgetaktet und kommt so auf knapp 9fps. Das ist gegenüber 3.2GHz bei gleicher EncThr Anzahl weniger Steigerung, als man aufgrund des Verhältnisses der Taktfrequenzen erwarten würde.
Möglicherweise ist die Kühlung bei dieser Frequenz und Volllast nicht mehr ausreichend, und die CPU taktet aus Sicherheitsgründen wieder runter?
Ich würde mal drauf tippen, dass unter optimalen Bedingungen ein auf 4-4.5GHz hochgetakteter 4930k die 10fps knapp knacken könnte?
- Carsten
Antwort von carstenkurz:
fsm - habe schon überlegt, ob ich als kleines Dankeschön mal ein Tutorial zum Programm schreiben sollte. Bisher gibts nur ne englischsprachige Anleitung, die der aktuellen Programmversion etwas hinterher hängt.
Ähm, zunächst mal, DCP-o-matic ist ja kein reiner J2k oder MXF Konverter, sondern erzeugt explizit nur die eng spezifizierten DCPs für die digitalen Kinoprojektoren. Die J2K/MXFs sind dabei nur ein Teil der erzeugten Pakete, der Rest sind die nicht unbedeutenden Metadaten.
Ein Kinoprojektor/Server kann keine MXFs direkt abspielen, er benötigt die XML Metadaten dazu.
Dabei ist nicht nur der Codec und das Codecprofil genau vorgeschrieben, sondern auch das Pixelformat. Daraus ergibt sich auch die Vorgabe, ausschließlich 2k oder 4k erzeugen zu dürfen. Alles andere würde die Spezifikationen verletzen. Farbcodierung ist 12Bit xyz. Dafür führt DCP-o-matic eine Matrixkonvertierung aus verschiedenen Quellfarbräumen durch (z.B. sRGB, REC709, etc.).
Innerhalb von 2k oder 4k gibt es dann jeweils drei zulässige sogenannte Containerformate:
2k:
1998*1080 ('flat', 1:1.85, das klassische Kino Breitwandformat)
2048*858 ('scope', 1:2.39, das klassische Kino Cinemascopeformat, im digitalen Kino allerdings ohne Anamorphot, also quadratische Pixel)
2048*1080 (der 'Full Container', der allerdings ausser für Tests kaum genutzt wird)
4k, entsprechend:
3996*2160 flat 1:1.85
4096*1716 scope 1:2.39
4096*2160 full
Alle anderen Formate - also speziell FHD/1080p und auch UHD mit 3840*2160 müssen fürs digitale Kino durch Letter- oder Pillarboxing auf diese Pixelabmessungen gebracht werden. Auch 4:3 ist im Kino üblicherweise 1998*1080, mit seitlichen schwarzen Balken.
Es gibt also formal im digitalen Kino 1920*1080 nativ nicht, ebensowenig wie UHD. Und auch keine anderen Codecs als J2K.
Allerdings werden abweichende Pixelformate von den Kinoservern toleriert, solange mindestens EINE Seite die offiziellen Pixelzahlen des Fullcontainers ausfüllt, also ENTWEDER 2048/4096 Breite ODER 1080/2160 Höhe. Daher ergibt sich auch die Zulässigkeit der Fullcontainer, die erfüllen beide Bedingungen.
1920*1080 ist also technisch möglich. Allerdings haben die meisten Kinos dafür kein sauberes Leinwandformat angelegt, man hat dann meistens die fehlenden Pixel zwischen 1920 und 1998 als schmale Balken links und rechts bis zur Kaschierung (sofern das Kino überhaupt noch eine Kaschierung hat).
Es gibt aus der Frühzeit der ersten digitalen Kinoprojektoren noch ein MPEG2/Interop (ohne Interlacing, mit sehr hohen Bitraten), das von den meisten Projektoren noch aus Kompatibilitätsgründen unterstützt wird. Das vergisst man aber am Besten gleich wieder.
@fsm: Wenn du andere Formate wie 1080p in J2k MXF wrappen willst, da gibt es J2K Encoder für Premiere. Für das Kino-MXF gibt es einen Commandlinewrapper, der vermutlich ungeachtet der Pixelformate das Wrappen übernehmen würde. Aber ich denke, da nimmt man besser andere Software, vor allem auch weil die Kinoformate/Wrapper grundsätzlich Video und Audio in separate MXFs packen. Es gibt im digitalen Kino also nicht wie im Computerbereich üblich 'interleaved'/verschachtelte Video/Audiofiles. Alles sind separate MXFs/Tracks: Bild, ggfs. mehrere Tonformate (z.B. 5.1/7.1), und auch Untertitel stecken in getrennten Dateien. Der Server, der das DCP abspielt, lädt die auch zur Laufzeit aus diesen getrennten Dateien.
- Carsten
Antwort von carstenkurz:
in deinem XML file sind bei mir 100MBit angegeben !
bei 200MBit komme ich auf 1:09
Sollte nicht so sein, ich habe das DropBoxFile mit den Testdaten auch nicht mehr angefasst seit dem ersten Upload.
Wenn man nach einer Neuinstallation DCP-o-matic zum ersten Mal startet, steht die JPEG2000 Datenrate auf 100MBit/s. Über das Laden (File->Open) der Metadata.xml sollte das auf 200MBit/s hochgesetzt werden.
Ausserdem setzt es das Scaling auf 16:9 und padded für 1998*1080 mit Schwarz, etc. Das ergibt leichte Abweichungen, gerade bei sehr vielen Cores. Dieser Teil, Skalieren, etc. ist halt gerade der, der nicht gut parallelisiert ist.
Wenn Du noch Lust hast, versuch es auch nochmal mit drastisch mehr Threads, z.B. 48 oder 64, und guck mal im Taskmanager/Performance Meter auf die Auslastung. Ich bin sicher, dass Du da nicht mehr auf 100% kommst.
- Carsten
Antwort von carstenkurz:
zum 4930er....er hatte das footage nicht auf der SSD liegen...kann es daran liegen? ansonsten war alles normal eingestellt, sagt der kollege.
Schnelle Speicher dürften kaum ne Rolle spielen, EIGENTLICH. Das Programm erzeugt bei diesem Benchmark ja komprimierte Daten AUS komprimierten Daten. Nur im Hauptspeicher werden pro Thread unkomprimierte Bitmaps rumgewirbelt, typisch bei 24 Threads etwa 24*6MByte. Das 11Mbyte große Quellfile passt ja komplett in den Cache, und der Output hat auch nur ca. 0.7Mbyte/frame, was bei 8fps gerade mal 5-6Mbyte/s Schreibrate ergibt. SSD oder nicht dürfte also im Grunde nichts ausmachen. Kleine Abweichungen zwischen aufeinanderfolgenden Durchläufen ohne Parameteränderung sind durchaus normal, aber ich hätte basierend auf dem 3930k mit 3.2GHz den 4930k mit 3.4GHz eher schon in Richtung 9fps geschätzt. Vielleicht läuft da ein Hintergrundthread, oder die Kühlung ist nicht ganz optimal. Bevor dein Kumpel da anfängt, rumzubasteln, warten wir vielleicht mal noch ab, ob ein weiterer 4930k sich 'meldet' ;-)
- Carsten
Antwort von carstenkurz:
So, die eine oder andere Nachmeldung kam noch, aber nichts Weltbewegendes mehr. Wenn alles verdatet ist, lade ich das Excel-File mal hoch.
Aber wenn noch jemand weiteres mit einem 4930K, ggfs. auch übertaktet, Zahlen liefern will, wie gesagt, die 9fps für SingleCPU gäbe es noch zu knacken.
https://dl.dropboxusercontent.com/u/558 ... public.zip
- Carsten
