Frage von gutentag3000:Wir brauchten einen neuen Schnittrechner und haben das vermeintlich stärkste genommen, was gerade da war: TR 3970x, 64GB, MP600 2TB. Dazu die GTX 1070 aus dem alten Schnittsystem.
Wir schneiden meist auf Premiere. Abspielen eines GH5 4K 100 Mbits Clip ohne Effekt bei 100% Qualität klappt bei 5 % CPU Last und 12% GK Last. Aber: Wenn man einfach Lumetrie drüberlegt (nur Gradations-Kurve RGB und Rot verändert, zum Testen) steigt ie CPU Last auf 50% und die GK auf ca 17%. Dazu fängt er bei 100% Qualität an, Frames zu droppen.
50% CPU Last und die Frames beginnen zu droppen? Ja.
Runterschalten auf 1/2 Qualität: 25 % CPU Last, Film läuft flüssig.
Bin für Hilfe dankbar. Ich möchte eigentlich OHNE Proxys arbeiten, deshalb wollte ich einen starken Rechner.
Hat jemand Erfahrungen damit? Kann ich was optimieren?
Antwort von Jörg:
ähnliches Material auf einem fast nur ein drittel so leistungsfähigem 8 Kerner Intel Core i7-7820X.
Diverse Lumetris drauf, läuft ohne frame dropping stundenlang, wenn es sein müsste...
Allerdings auf CC 2017, welche Version nutzt du?
Mercury playback ist aktiv?
Antwort von gutentag3000:
Jörg hat geschrieben:
welche Version nutzt du?
Mercury playback ist aktiv?
aktuelle version (2020)
ohne mercury wäre doch die gk völlig ohne belastung, oder? ich bin nachher nochmal im büro und werde die einstellungen checken.
Antwort von Framerate25:
gutentag3000 hat geschrieben:
ohne mercury wäre doch die gk völlig ohne belastung, oder?
Die GPU wird dezitiert in Effekten und weiteren Prozessen genutzt, nicht aber Uni. ;)
Ich hab das bei mir auch auf "software" laufen. Flutscht wie hulle. Sollte bei Dir auch - wenn nicht grundsätzlich der Wurm im System ist.
Grüßle
FR25
Antwort von mash_gh4:
gutentag3000 hat geschrieben:
Abspielen eines GH5 4K 100 Mbits Clip ohne Effekt bei 100% Qualität klappt bei 5 % CPU Last und 12% GK Last. Aber: ...
ich nehme an, du sprichst von h.264 material in 10bit und 4:2:2 sprichst, also genau das, wo alle üblichen beschleunigungslösungen aussteigen und die ganze rechenarbeit im zuge des decodierens tatsächlich auf der CPU erfolgen muss. in der weiteren verarbeitungskette spielt es dann ohnehin keine rolle mehr.
im prinzip sollte das natürlich trotzdem auf den aktuellen AMD prozessoren mit ihrer üppigen zahl an kernen ganz gut bewältigbar sein, trotzdem ist es leider in der praxis weiterhin so, dass die umgebende software infrastruktur (math. verarbeitungs-libraries und vektorisiertes video-processing) hier immer wieder deutlich schlechter optimiert und lückenhaft erscheint, wenn man sie mit dem intel gegenstück vergleicht.
als endbenutzer von programmen, die nicht im quellcode vorliegen, ist man dem völlig hilflos ausgeliefert. in wahrheit kann man in einem solchen fall nichteinmal die tatsächlich verantwortlichen flaschenhälse in der verarbeitung von außen ausmachen...
Antwort von rush:
H.264 422 10bit soll der drückende Schuh sein? Mhhh...
Wie sieht es dann erst mit h.265 10bit aus?
Vielleicht ist da in der Tat Premiere eher etwas ungünstig aufgestellt und kommt ins Straucheln?
Ggfs Mal Resolve / Edius etc aufspielen und schauen ob es dort bei einem ähnlichen Workflow mit leichter Farbkorrektur auch zu Problemen kommt?
Womöglich ist Lumetri nicht entsprechend optimiert und bremst am Ende alles unnötigerweise aus - würde mich bei Premiere tatsächlich nicht wundern...
Vielleicht gibt es ja Nutzer die entsprechende Premiere Versionen mit dem genannten Codec fahren und entsprechend berichten können.
Antwort von Jörg:
würde mich bei Premiere tatsächlich nicht wundern...
mich schon ;-((
aber ich arbeite ja auch damit, und fasele nicht nur darüber.
Antwort von mash_gh4:
rush hat geschrieben:
H.264 422 10bit soll der drückende Schuh sein? Mhhh...
Wie sieht es dann erst mit h.265 10bit aus?
deutlich besser! -- und zwar, weil im fall von h.265 normalerweise auch 10bit-unterstützung in den meisten hardwarebeschleunigten lösungen zur verfügung steht!
diesr unterschied hat damit zu tun, dass h.265 einfach neuer ist und 10bit-unterstützung hauptsächlich für HDR auch im consumer umfeld unverzichtbar wurde.
allerdings kann man diese vorteile schnell wieder verspielen, wenn man unbedingt 4:2:2 statt 4:2:0 nutzen will. dann funktioniert das ganze nämlich selbst mit dem modernen h.265 wieder nicht.
Antwort von rush:
Jörg hat geschrieben:
würde mich bei Premiere tatsächlich nicht wundern...
mich schon ;-((
aber ich arbeite ja auch damit, und fasele nicht nur darüber.
Ich habe auch lange mit Premiere gearbeitet - zwar nicht mehr mit den letzten CC Varianten aber insbesondere in komplizierten Codec/Renderingprozessen hat mich Premiere durchaus hier und da schon manchmal genervt.
Und irgendwo muss der Schuh ja drücken wenn das Playback ohne Lumetri bei sehr geringer Last problemlos läuft - dann aber beinahe unmittelbar zu Drop Frames führt... Ob ein entsprechendes Intel System das ganze besser handlen würde (quicksync und co) oder es ein generelles Systemproblem ist kann ich nicht beurteilen, daher der Hinweis es mal mit alternativer Software gegenzuchecken um zu sehen wie sich das Material und der Rechner dabei verhält.
Antwort von gutentag3000:
Update: weiß nicht warum, aber ich nach einem Rechnerneustart läuft es besser.
Bei 4k Play in Timeline mit Lumetri: CPU 4%, GK. 21% ohne dropped Frames.
Ohne Effekte bleibt dei CPU bei 4%, GPU geht auf ca 6%
also annehmbar.
Ich hab mal spaßeshalber einen Export aus der Timeline gemacht: 1 min Material mit Lumetri Gradation. Der Rechner braucht 38 Sekunden - ok.
ABER:
Der exakt gleiche Clip mit gleichem Effekt auf meinem Dell XPS15 6 Core/12 Thread und halb so viel RAM braucht auch nur 56 Sekunden.
Hatte mir den Performance-Schub etwas heftiger vorgstellt :)
CPU-Bottlenecks scheint es im TR 3970x System nicht zu geben, Cinebench R20 gehen mit gut 17000 Punkten durch, das ist fett.
Aber Premiere ist bis jetzt nicht so deeer Burner.
Antwort von MK:
Prüfe mal während dem Arbeiten mit LatencyMon ob es auf dem System Latenzprobleme gibt:
https://www.resplendence.com/latencymon
Antwort von motiongroup:
https://www.pugetsystems.com/labs/artic ... -Pro-1519/
https://www.pugetsystems.com/labs/artic ... -Gen-1629/
Versuche dich mal am Puget Benchmark, da erkennst gleich ob irgendwo der Wurm drinn ist
Antwort von gutentag3000:
Update: hab die Video-Datei jetzt nochmal mit VBR und ZWEI (2) Durchgängen "benchmark"-gerendert.
Der Laptop mit 6 Core i7 8750H brauchte dafür exakt 4 mal so lang (5:24 Min) wie der TR 3970X (01:21 Min)
Das sind Zahlen mit denen ich leben kann :)
Da scheint sich der Threadripper also zu lohnen. Ich glaub aber auch, dass das TR System locker 10 Mal so viel Strom verbraucht.
Das werde ich dann demnächst auch nochmal messen :)
Antwort von Frank Glencairn:
Daß Premiere nicht gerade dafür bekannt ist viele Kerne effizient zu nutzen, ist jetzt auch nicht wirklich ein Geheimnis.
Antwort von motiongroup:
zumindest unter osx betrifft das die komplette Suite...
