Dass ProRes eine dankbare Sache ist, ist ja inzwischen bekannt.
Interessant wird es für Viele halt beim Bearbeiten von stark komprimierenden Dingen wie h264, X-AVCS und Konsorten. Das sind die Formate, die von günstigen Kameras kommen. Dementsprechend sehen halt auch die Rechner aus, auf denen das Material geschnitten werden soll.
Das Ganze in ProRes/DNxHD umzuwandeln hat sich für mich auch noch nicht als sehr Praxistauglich erwiesen, weil die Proxy Import Funktion nicht automatisch die Framerate vom Quellmaterial übernimmt, bzw DNxHD 100+ fps garnicht unterstützt.
Davon abgesehen braucht man fürs Umwandeln Zeit und vor allem auch viel Platz, den ich garnicht habe.
In Premiere bzw After Effects fängt die Chose dann nach kurzer Zeit wunderbar zu Ruckeln an. Und ähnlich wie bei dem tollen Video hier, wenn er bei 4x Speed ist, ist die CPU weit entfernt von einer 100%igen Auslastung. Eher so bei 50 +-. Und das wiederum macht es schwer, den Admins gegenüber einen stärkeren Rechner zu rechtfertigen.
Von daher währe es schon sehr gut zu wissen was wann wie von Premiere gefordert wird.
canti hat geschrieben:Dass ProRes eine dankbare Sache ist, ist ja inzwischen bekannt.
Interessant wird es für Viele halt beim Bearbeiten von stark komprimierenden Dingen wie h264, X-AVCS und Konsorten. Das sind die Formate, die von günstigen Kameras kommen. Dementsprechend sehen halt auch die Rechner aus, auf denen das Material geschnitten werden soll.
Das Ganze in ProRes/DNxHD umzuwandeln hat sich für mich auch noch nicht als sehr Praxistauglich erwiesen, weil die Proxy Import Funktion nicht automatisch die Framerate vom Quellmaterial übernimmt, bzw DNxHD 100+ fps garnicht unterstützt.
Davon abgesehen braucht man fürs Umwandeln Zeit und vor allem auch viel Platz, den ich garnicht habe.
In Premiere bzw After Effects fängt die Chose dann nach kurzer Zeit wunderbar zu Ruckeln an. Und ähnlich wie bei dem tollen Video hier, wenn er bei 4x Speed ist, ist die CPU weit entfernt von einer 100%igen Auslastung. Eher so bei 50 +-. Und das wiederum macht es schwer, den Admins gegenüber einen stärkeren Rechner zu rechtfertigen.
Von daher währe es schon sehr gut zu wissen was wann wie von Premiere gefordert wird.
Man muss sich die Frage stellen:
Was muss denn der Rechner an Aufgaben leisten, wenn der GOP-Material in 4x abspielen muss - gerade im Vergleich zu einzelbildbasierten Codecs oder RAW?
Da tun sich dann auch beim Speicher (Arbeits- und Datenspeicher) schnell Flaschenhälse auf.
Eigentlich muss man weder sehr viel wissen, noch muss man sich irgendwas fragen. Man muss einfach nur testen ob neue hardware das System mit dem eigenen Workflow performanter macht oder nicht.
DenK hat geschrieben:Eigentlich muss man weder sehr viel wissen, noch muss man sich irgendwas fragen. Man muss einfach nur testen ob neue hardware das System mit dem eigenen Workflow performanter macht oder nicht.
Ja - dann testen wir also auch, ob sich ein Smart für eine Rally eignet?
Da darfst du dann sehr viele Varianten testen, wenn du nicht darüber nachdenkst, wo der Flaschenhals sein könnte.
Ja - dann testen wir also auch, ob sich ein Smart für eine Rally eignet?
ein typischer iasi...
genau wie bei Autos, wirds auch bei Rechnerconfigs keine Ideallösungen für alle Fälle geben.
Auch hier wird der Nutzer entscheiden müssen, WELCHE Aufgaben ein
Werkzeug erfüllen muss.
Dazu gehört ganz sicher nicht die 4x L oder 3xJ Option in erster Linie...
Es würde doch schon genügen, wenn ein Test belegen könnte, dass diese Karte in Premiere überhaupt einen Vorteil bringt. Auch gerne aus dem Bereich der Video-Bearbeitungs-Exotik. Wie im Slashcam-Tests, mit 20 Denoiser-Nodes übereinander in Resolve, wau ;)
dienstag_01 hat geschrieben:Es würde doch schon genügen, wenn ein Test belegen könnte, dass diese Karte in Premiere überhaupt einen Vorteil bringt. Auch gerne aus dem Bereich der Video-Bearbeitungs-Exotik. Wie im Slashcam-Tests, mit 20 Denoiser-Nodes übereinander in Resolve, wau ;)
Eigentlich ist es recht einfach: In Premiere dekodiert die CPU und das meistens auch sehr effektiv, dass man sogar mehrere 4K-Ströme auf nem 6 Core Rechner entpackt bekommt. Wenns ohne Effekte auf der Timeline ruckelt ist es die CPU.
GPU Decoding gibt es IMHO (wenn überhaupt) nur bei speziellen RAW-Formaten.
Effekte gibt es für CPU (in verschiedenen Farbtiefen) und GPU (immer Float 32). Wenn man nur GPU-Effekte stapelt, schafft man es meistens schon nicht Karten mit 3000 TFlops ans Limit zu bringen. Wer allerdings hier dennoch ein Ruckeln zu Gesicht bekommt, gewinnt mit der 1080 Ti.
Wenn man auch CPU-Effekte einsetzt wird es wild. Dann müssen nämlich die Grafikdaten im blödsten Fall zwischen RAM und GPU hin und hergeschoben werden und die CPU braucht noch viel mehr Rechenleistung für die zusätzlichen Effekte.
Und nein, wir haben noch nie Denoiser Nodes in Resolve gestapelt ;) Wir zählen nur die Frames, die ein einzelner 4K Denoiser schafft... Fürwahr...
rudi hat geschrieben:Und nein, wir haben noch nie Denoiser Nodes in Resolve gestapelt ;) Wir zählen nur die Frames, die ein einzelner 4K Denoiser schafft... Fürwahr...
rudi hat geschrieben:Und nein, wir haben noch nie Denoiser Nodes in Resolve gestapelt ;) Wir zählen nur die Frames, die ein einzelner 4K Denoiser schafft... Fürwahr...
Ah, stimmt, waren 22 Curved Nodes ;)
Und das halten wir tatsächlich für nicht so realitätsfremd wie es erstmal scheint. Wenn man viele Bereiche im Bild maskiert und getrennt korrigiert können 22+ Masken für manchen schon relevant sein (wenn auch nicht für unsere Projekte persönlich). Aber lacht uns nur aus. Irgendwann holt auch euch der große TFlops...
rudi hat geschrieben:Und das halten wir tatsächlich für nicht so realitätsfremd wie es erstmal scheint. Wenn man viele Bereiche im Bild maskiert und getrennt korrigiert können 22+ Masken für manchen schon relevant sein (wenn auch nicht für unsere Projekte persönlich). Aber lacht uns nur aus. Irgendwann holt auch euch der große TFlops...
Ist schon richtig, ich hatte es wirklich falsch in Erinnerung.
DenK hat geschrieben:Eigentlich muss man weder sehr viel wissen, noch muss man sich irgendwas fragen. Man muss einfach nur testen ob neue hardware das System mit dem eigenen Workflow performanter macht oder nicht.
Ja - dann testen wir also auch, ob sich ein Smart für eine Rally eignet?
Da darfst du dann sehr viele Varianten testen, wenn du nicht darüber nachdenkst, wo der Flaschenhals sein könnte.
Wie Ich sehe hast du dir nichtmal die Mühe gemacht "Smart Rally" zu googeln...
DenK hat geschrieben:Eigentlich muss man weder sehr viel wissen, noch muss man sich irgendwas fragen. Man muss einfach nur testen ob neue hardware das System mit dem eigenen Workflow performanter macht oder nicht.
Ja - dann testen wir also auch, ob sich ein Smart für eine Rally eignet?
Da darfst du dann sehr viele Varianten testen, wenn du nicht darüber nachdenkst, wo der Flaschenhals sein könnte.
Wie Ich sehe hast du dir nichtmal die Mühe gemacht "Smart Rally" zu googeln...
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
