slashCAM Forum

Hallo Forum,

ich habe eine Frage zu BM DaVinci Resolve.

Bereits vor einigen Wochen hatte ich Resolve (v.15 free) unter Win 8.1 mit 8GB RAM getestet, aber das ging leider nur mit viel Geruckel und Gestotter im Schnitteditor.

Selbst wenn die Audiospur einmal nicht geruckelt hat, lief das Videomaterial teils mehrere zehntel Sekunden hinterher und es wurden auch eher Einzelbilder abgespielt denn ein flüssiges Video.

Nun habe ich bereits im Vorfeld gegoogelt und gelesen, das 16GB RAM und Win 10 hier durchaus weiterhelfen könnten.

Also habe ich auf 16GB RAM (2x8GB DDR3) aufgerüstet und Win. 10 pro gekauft und installiert.

Leider hat sich an der Problematik im Schnitteditor nichts geändert.

Nachdem ich dann weiter im net gesucht habe, fand ich zwei zunächst sehr interessant klingende Lösungsansätze in Form von optimized media und render cache.

Nun ist es aber so, das ich bei optimized media soweit mit den Einstellungen runter gehen muss bis es flüssig läuft, das daß footage selbst bei hd projekten einfach nur noch pixelig aussieht.

Dann dachte ich render cash sei die Lösung des Problems, da nach dem rendern alles flüssig lief.

Leider aber immer nur so lange, bis etwas im Editor bearbeitet wird und der langwierige Rendervorgang von vorne beginnt.

Sowohl optimized media, als auch render cache erscheinen mir persönlich daher nicht als Option für einen flüssigen workflow geeignet.

Würde ein upgrade auf die Studio Version evtl. Abhilfe schaffen, oder meint Ihr mein System ist einfach zu schlapp für einen flüssigen workflow mit Resolve?

Meine hardware: Asrock Z97 extreme6, Intel Core i7-4790K, Corsair Vengeance Pro 16GB DDR3 RAM, Gigabyte GeForce GTX970 Gaming G1 4GB GDDR5 RAM, Samsung 970 EVO 1TB NVMe M.2 (steckt auf dem ultra slott).

Weiß jemand Rat?

Lieben Gruß, Freddy

Das ist ja auch immer eine Frage des Materials, dass bearbeitet wird.

Hallo dienstag_01,

footage und timeline sind 1920 x 1080 HD.

Video Monitoring ist bereits auf HD 720p 24 gedrosselt.

Das Projekt hat insgesamt fünf Spuren teils mit Masken.

Gruß, Freddy

...Gigabyte GeForce GTX970 Gaming G1 4GB GDDR5 RAM...

Cuda unter Preferences -> Hardware Configuration -> GPU processing Mode schon ausgewählt? Falls nicht, dann liegt es wahrscheinlich daran.

Hi roki 100,

GPU processing mode steht auf CUDA.

Gruß, Freddy

Ist das hochkomprimiertes Video? Also kann es sein, dass der Rechner das Material gar nicht zu dekodieren schafft. CPU Auslastung?

dienstag_ 01, das war auch eine meiner Vermutungen.

Ich habe dann mal testhalber ein einfaches non footage Projekt mit nur drei parallelen Textebenen und zwei Audiospuren getestet und das ruckelt nativ leider auch.

Was heisst ruckeln? Aussetzer im Ton?

dienstag_01,

ja, Video läuft aber auch nicht flüssig.

Ich nutze das Zoom UAC-2 und hoffe nicht, das es der Grund für die Probleme ist, denn ich brauche das für Cubase Pro 10, weil es dort mit extrem niedrigen Latenzen perfekt seinen Dienst verrichtet.

frebe67 hat geschrieben: ↑Do 31 Okt, 2019 22:38 ...
Würde ein upgrade auf die Studio Version evtl. Abhilfe schaffen, oder meint Ihr mein System ist einfach zu schlapp für einen flüssigen workflow mit Resolve?

die studio-variante hat damit mW nix zu tun.

Prämissen:

Unterscheidung zw Perfomance-Schwäche und SysConfig-Probleme!

Perfomance-Schwäche sieht man unmittelbar im Taskmanager, wenn während des Ruckelns eine
Ressource (fast) an den Anschlag geht, also CPU-load, GPU-load, Disk-I/O-max usw

Wenn viele rechenaufwändige Effekte auf den shots sind läuft es in der timeline bei jedem clip
anders (schlecht), das sieht man dann aber im Taskmanager.

wenn keine Perfomance-Schwäche vorliegt (alles unter ca 80%) kann das Problem an
unpassenden Sys-Modulen liegen. Ggf neue GPU-Treiber suchen, manchmal muss es auch eine ältere sein.
NVIDIA hat zT die Auswahl eines game-modus angeboten, evtl den versuchen.

Ich habe das ähnliche Problem, dass es in resolve HD aus dem media-pool normal läuft, aber
dasselbe clip in der timeline (ohne Effekte drauf!) humpelt. Dies Problem wird bisweilen
auch im BMG-forum genannt, eine klare Lösung habe ich nicht gefunden, habe aber wohl auch
mit AMD-GPU u Win8 eine (aus resolve-Sicht) ungesunde Kombination.
Mit anderen NLE-progs läuft es hingegen problemlos, also nehme ich die bis auf weiteres.

"Resolve 15 ruckelt bei der Wiedergabe im Schnitteditor"

Cache auf dem schnellsten Laufwerk einrichten, muss in dem Projekt-Setting
dann auch eingelinkt sein und ab geht die Post mit der ruckelfreien Wiedergabe!
Dazu muss man vor der Wiedergabe die Quell-Footage ohne irgendwelcher
Filter darauf halt cachen.
Im Kontexmenü der Timeline "Generate Optimized Media" und im Playback-Menü
die Option "Use Optimized Media if Available" aktivieren

CPU und RAM jedenfalls sollten eigentlich nicht der drückende Schuh sein...
Auf meinem 4770k mit 16GB RAM (allerdings mit zusätzlicher GTX 1070) konnte ich sowohl hochkomprimiertes (h.264 und teils h.265) Material zumindest in einer Spur ohne Effekte noch problemlos wiedergeben... Ohne optimized Media und das Material lag befand sich auf HDDs...

Zum Audio-Interface... Auf welcher Frequenz läuft das System denn? Nativ 48000 oder auf 44.100 etc?

Eigentlich sollte Windows das entsprechend problemlos hinbekommen und Up/Downsamplen - denke daher weniger das Dein Interface das Problem ist. Aber stöpsel es doch einfach Mal ab und dann siehst du doch ob es besser wird.

Mein Billo Behringer UMC 204 HD Interface jedenfalls funzt tadellos unter Resolve 16 Studio - und kommt jetzt am neueren Rechner in meiner DAW ebenfalls auf sehr kurze Latenzen. Dürfte aber Resolve wie gesagt nicht weiter tangieren... Das Problem wird woanders liegen.

Irgendwo weiter oben schreibst Du das Videomonitoring auf 24fps gestellt ist... Was genau für Material hast du denn nun? 25p? Oder irgendwas krummes? Und in welche Komprimierung liegt es vor.. besonders Action Cam oder andere Kameras liefern gelegentlich krumme Framerates die dann in Kombination mit anderen Material oder Timelinesettings korresponieren und Probleme verursachen können ...

Sehe ich auch so, prinzipiell sollte es kein Problem mit der Hardware sein, sondern eher was mit Konfiguration bzw. Workflow (24fps) zu tun haben. Also schön der Reihe nach alles ausprobieren ;)

rush hat geschrieben: ↑Fr 01 Nov, 2019 10:36 Auf meinem 4770k mit 16GB RAM (allerdings mit zusätzlicher GTX 1070) konnte ich sowohl hochkomprimiertes (h.264 und teils h.265) Material zumindest in einer Spur ohne Effekte noch problemlos wiedergeben... Ohne optimized Media und das Material lag befand sich auf HDDs...

man muss hier immer aufpassen, ob sich die aussage auf die frei verfügbare version oder die käufliche studio ausgabe bezieht!

erstere gleitet leider zusehends immer mehr in die praktische unbenutzbarkeit ab.

@mash... Ahhh okay das war mir nicht bewusst... Habe durch die Pocket 4k ja tatsächlich die Studio Version und kann entsprechend nur für diese sprechen. Hatte nicht im Blick welche Drawbacks die freie Version ggfs hat ..

mash_gh4 hat geschrieben: ↑Fr 01 Nov, 2019 14:37 man muss hier immer aufpassen, ob sich die aussage auf die frei verfügbare version oder die käufliche studio ausgabe bezieht!

weist Du noch woher die Info stammt?

mW ist das für die Installation und customizing egal.
Nur die features der Einfachversion sind weniger (subset).
Ist auch insofern plausibel, weil es die Wartung der beiden Versionen vereinfacht.

IIRC hab ich das aus dem BMD-Forum (ist aber schon n paar Tage her)

dosaris hat geschrieben: ↑Fr 01 Nov, 2019 16:31 weist Du noch woher die Info stammt?

das problem ist leider ziemlich bekannt...

in der freien version nutzt resolve unter mac und und windows jeils nur die vom betriebssystem bereitgestellten codecs um mit den gängigen dateiformaten umzugehen, damit sie sich lizenzkosten sparen. in der studio version dagegen kommen codes von drittanbietern zum einsatz. der spürbare unterschied ergibt sich daraus, dass nur letztere div. hardwarebeschleunigungsmöglichkeiten unterstützen. natürlich könnten sie auch in der freien version derartige techniken nutzten, wie sie ja durchaus von den entsprechenden hardwareanbietern in ganz ähnlicher weise -- also im grunde mit den selben lizenzkosten wie bei den betriebssystem beigaben -- verfügbar sind. daran scheint aber BMD offenbar kein großes intreresse zu haben, weil die frei ausgabe ja leider doch nur eine hübsch getarnte demo version sein soll...

Hallo Forum,

sorry, das ich mich erst so spät melde, aber ich hatte heute volles Programm mit Familie und Verwandtschaft.

Vielen lieben Dank für die zahlreichen Tips und Anregungen, so etwas ist heute leider nicht mehr selbstverständlich.

Gebt mir bitte etwas Zeit, ich werde das alles Schritt für Schritt durcharbeiten und Euch dann feedback geben.

Vielen Dank noch einmal im voraus.

Gruß, Freddy

mash_gh4 hat geschrieben: ↑Fr 01 Nov, 2019 17:38

dosaris hat geschrieben: ↑Fr 01 Nov, 2019 16:31 weist Du noch woher die Info stammt?

das problem ist leider ziemlich bekannt...

in der freien version nutzt resolve unter mac und und windows jeils nur die vom betriebssystem bereitgestellten codecs um mit den gängigen dateiformaten umzugehen, damit sie sich lizenzkosten sparen. in der studio version dagegen kommen codes von drittanbietern zum einsatz. der spürbare unterschied ergibt sich daraus, dass nur letztere div. hardwarebeschleunigungsmöglichkeiten unterstützen. natürlich könnten sie auch in der freien version derartige techniken nutzten, wie sie ja durchaus von den entsprechenden hardwareanbietern in ganz ähnlicher weise -- also im grunde mit den selben lizenzkosten wie bei den betriebssystem beigaben -- verfügbar sind. daran scheint aber BMD offenbar kein großes intreresse zu haben, weil die frei ausgabe ja leider doch nur eine hübsch getarnte demo version sein soll...

Das ist Quatsch, DNxHD z. B. wird nicht vom Betriebssystem bereitgestellt, kann aber in Resolve free genutzt werden. Und Hardwarebeschleunigung ist für diese Rechneraustattung bei HD Video überhaupt kein Thema. Cuda funktioniert ja.

dienstag_01 hat geschrieben: ↑Sa 02 Nov, 2019 01:02

mash_gh4 hat geschrieben: ↑Fr 01 Nov, 2019 17:38 in der freien version nutzt resolve unter mac und und windows jeils nur die vom betriebssystem bereitgestellten codecs um mit den gängigen dateiformaten umzugehen, damit sie sich lizenzkosten sparen. [...]

Das ist Quatsch, DNxHD z. B. wird nicht vom Betriebssystem bereitgestellt, kann aber in Resolve free genutzt werden. Und Hardwarebeschleunigung ist für diese Rechneraustattung bei HD Video überhaupt kein Thema. Cuda funktioniert ja.

mit den "gängigen dateiformaten" war natürlich all das gemeint, was man gewöhnlich in MPEG files u.ä. vorfindet bzw. wofür man entsprechende hardwareunterstützung im consumer-umfeld angeboten bekommt, damit es auch auf geräten mit beschränkter rechenleistung vernünftig genutzt werden kann.

bei einfacheren formaten -- also bspw. DNxHD od Prores --, wo die kompressionseffizienz eine untergeordnete rolle spielt, ist das nicht so ein problem, weil die ohnehin aus einer zeit stammen, als die recher noch deutlich leistungsschwächer waren, heute dagegen aber verhältnismäßig einfach abgearbeitet werden können.

mash_gh4 hat geschrieben: ↑Sa 02 Nov, 2019 01:16

dienstag_01 hat geschrieben: ↑Sa 02 Nov, 2019 01:02

Das ist Quatsch, DNxHD z. B. wird nicht vom Betriebssystem bereitgestellt, kann aber in Resolve free genutzt werden. Und Hardwarebeschleunigung ist für diese Rechneraustattung bei HD Video überhaupt kein Thema. Cuda funktioniert ja.

mit den "gängigen dateiformaten" war natürlich all das gemeint, was man gewöhnlich in MPEG files u.ä. vorfindet bzw. wofür man entsprechende hardwareunterstützung im consumer-umfeld angeboten bekommt, damit es auch auf geräten mit beschränkter rechenleistung vernünftig genutzt werden kann.

bei einfacheren formaten -- als bspw. DNxHD od Prores --, wo die kompressionseffizienz eine untergeordnete rolle spielt, ist das nicht so ein problem, weil die ohnehin aus einer zeit stammen, als die recher noch deutlich leistungsschwächer waren, heute dagegen aber verhältnismäßig einfach abgearbeitet werden können.

Was für den TO interessant ist: wenn sein System die Leistung nicht bringen sollte, dann kann er entweder seine Hardware oder seine Software upgraden. Wenn er denn h264 o.ä. benutzt. Deshalb hatte ich ja nach der Kompression - dem Codec - gefragt.

Hallo Forum, noch einmal vielen Dank für die zahlreichen Tips und Anregungen.

Ich habe zwischenzeitlich noch fleißig weiter gegoogelt und las, das es durchaus hilfreich sein kann, wenn man Resolve und die drei Ordner CacheClip, .gallery und Capture physisch auf zwei Laufwerke aufteilt.

Ich habe daher noch eine zusätzliche kleinere SSD im Rechner verbaut und auf dieser Windows neu installiert.

Dort habe ich dann Resolve 15 neu aufgesetzt und auf der Samsung SSD die drei oben gennanten Ordner und ein Testprojekt angelegt.

Das Ergbnis war für mich angenehm überraschend.

In dem Testprojekt, habe ich mich spurweise an die Grenzen meiner Rechnerleistung herangetastet.

Am Ende lief das Projekt mit fünf Videospuren plus zwei separater Audiospuren flüssig im Schnitteditor und im Color mode.

Bei der sechsten Videospur, fing die Wiedergabe zwar an zu stolpern und zu stottern, aber fünf Spuren reichen mir für meine Projekte zum Schneiden und Bearbeiten aus.

Die fünf Videospuren (h.264) wurden zudem alle mit Masken, Bewegungseffekten (Zoomen/Verschieben/Drehen) und grading belastet.

Die CPU Auslastung lag hier bei ca. 77% im Resolve peak (laut Taskmanager) und bei ca. 78% im GPU Load (laut GPU-Z).

Ich bin wirklich froh, das mein Rechner noch nicht in den Elektroschrott Müll wandern muss.

Gruß, Freddy

Mal herzlich zurückbedankt, von solchen Erfahrungsberichten und aufgezeigten praktischen Lösungen (inkl. guter Kommunikation statt Jammern und Glaubenskriegen) lebt das Forum.

Hast du das System denn vorher auch schonmal komplett neu aufgesetzt gehabt, sprich Windows vollständig neu installiert?

Evtl war ja auch diese Maßnahme bereits die zielführende...

Das auslagern bestimmter Dateien auf eine weitere SSD ist sicherlich ebenfalls sehr gut - aber ich würde nicht ausschließen das es auch ohne diese Maßnahme funktionieren könnte wenn Resolve auf einer quasi frischen Windows Installation installiert wird und somit jegliche vorherigen Treiber/Software-Inkompatibilitäten von alten Systemdateien nicht mehr vorhanden sind.

Dennoch natürlich erfreulich wenn es jetzt so für Dich passt und läuft

cantsin, vielen Dank.

rush, nein das Betriebssystem wurde zu diesem Zeitpunkt nicht neu aufgesetzt.

Ich hatte zwar mehrmals Resolve neu aufgespielt, was aber zu keiner befriedigenden Lösung geführt hat.

Ich gebe Dir Recht, evtl. hätte eine Neuinstallation des Betriebssystems zu diesem Zeitpunkt bereits gute Ergebnisse ergeben, das kann man sicherlich nicht ausschließen.

In meinem Fall war es allerdings so, das ich bereits seit längerem über eine zweifach SSD Konfiguration nachdenke, in welcher Betriebssystem + Programme von den Projekten physisch getrennt sind.

Hier schien mir die Gelegenheit günstig, den cut zu machen.

Ein par kleine SSD Optimierungen z.B. durch Einsatz des Samsung NVMe M.2 Treibers und der Rechner scheint mir laut diverser Benchmarks durchaus noch für locker ein- bis zwei Jahre zu taugen.

Es müssen auch für Resolve nicht immer gleich 16 Kerne sein, das ist zu mindest mein vorläufiges Resumee.

Lieben Gruß, Freddy

cantsin hat geschrieben: ↑Mi 06 Nov, 2019 06:55 Mal herzlich zurückbedankt, von solchen Erfahrungsberichten und aufgezeigten praktischen Lösungen (inkl. guter Kommunikation statt Jammern und Glaubenskriegen) lebt das Forum.

Das möchte ich einfach mal unterschreiben. Dieser Thread zeigt eine gleichermaßen zielführende und respektvolle Kommunikation mit zahlreichen und hilfreichen Tipps. Danke dafür!

Alle reden immer nur von Systemoptimierung, hier mal mehr eine Software seitige Optimierung.
Vielleicht kann ja der da oben auch helfen, mir hat’s Video geholfen.
Es geht wirklich auch auf langsamen Computern.
Gruss Boris

Funktioniert tadellos aber erfogt das finale Rausrendern dann von diesen "Proxyfiles" oder von den Originalfiles?
Übrigens: beim Rausrendern der Originalfiles kann man unter H264-Export ja zwischen Youtube und H264 (default: best) wählen. Der Unterschied in den Dateigrößen ist ja unglaublich.
Bei H264 best komme ich auf 15270 Kb/s, bei YT auf 1368 Kb/s das sind nur 8,7% und dabei kann ich nicht mal gravierende Unterschiede erkennen -:)

Darth Schneider hat geschrieben: ↑Mo 02 Dez, 2019 07:56
Alle reden immer nur von Systemoptimierung, hier mal mehr eine Software seitige Optimierung.
Vielleicht kann ja der da oben auch helfen, mir hat’s Video geholfen.
Es geht wirklich auch auf langsamen Computern.
Gruss Boris

Ein echt tolles Video mit sehr guten Tipps und ein Lob an den hohen Informationsgehalt in diesem Threat. Jeder der mit dem Playback von Resolve Probleme hat, kann hier Hardware und Software technisches vieles rausholen und ausprobieren. Top.

Mir hat dieser Thread auch sehr geholfen. Bin auch noch mit einem alten i7 (4790) und der GTX 970 unterwegs (dazu 32GB RAM und 2 SSDs jeweils für System und Daten).
In Resolve 16 hatte ich im Edit keine Probleme h.264-UHD abzuspielen. Im Color-Bereich fing es dann aber schon unbearbeitet an zu stottern, sprich es wurden einfach nicht mehr die vollen 30 Bilder pro Sekunde abgespielt. Arbeiten konnte man trotzdem, aber im Task-Manager war zu sehen, dass der Prozessor auf Anschlag lief. In etwa 3 Wochen Einarbeitung in Resolve ist mir dann einmal beim rausrendern (2 Spuren h.264 mit Alphakanal und ein paar Masken nach DNxHD) der PC einfach ausgegangen. Kernel 41 hiess es glaub ich im Ereignisprotokoll. Wie gesagt das war nur einmal aber ein Keim für Sorge.
Jetzt habe ich (bestätigt durch Inhalte dieses Threads) von der Free- auf die Studio-Version gewechselt und bin begeistert. Plötzlich teilen sich CPU und GPU die Arbeit. In Edit- und Colortimeline läuft die CPU nur noch auf 50% Auslastung (vorher 100!) und beim Rausrendern wenigstens nicht mehr auf Anschlag (etwa 90%).
Ich nehme mal an, dass ein grösseres h.264-UHD-Projekt mit der Rechenpower nichts wird, aber um ein paar Clips oder einzelne Szenen zu bearbeiten und dann in ein beliebiges HD-Format zu wandeln scheint es zu reichen :-)

Ich nehme mal an, dass ein grösseres h.264-UHD-Projekt mit der Rechenpower nichts wird,

die Vermutung stand hier schon dutzendmal zur Debatte, die Lösung auch.
Wer in aller Welt schneidet UHD auf voller Auflösung?
Bearbeite das in FHD und deine Maschine sonnt sich draußen, statt im Studio zu schwitzen.

Seba Peh hat geschrieben: ↑Fr 10 Apr, 2020 08:56 Mir hat dieser Thread auch sehr geholfen. Bin auch noch mit einem alten i7 (4790) und der GTX 970 unterwegs (dazu 32GB RAM und 2 SSDs jeweils für System und Daten).
In Resolve 16 hatte ich im Edit keine Probleme h.264-UHD abzuspielen. Im Color-Bereich fing es dann aber schon unbearbeitet an zu stottern, sprich es wurden einfach nicht mehr die vollen 30 Bilder pro Sekunde abgespielt. Arbeiten konnte man trotzdem, aber im Task-Manager war zu sehen, dass der Prozessor auf Anschlag lief. In etwa 3 Wochen Einarbeitung in Resolve ist mir dann einmal beim rausrendern (2 Spuren h.264 mit Alphakanal und ein paar Masken nach DNxHD) der PC einfach ausgegangen. Kernel 41 hiess es glaub ich im Ereignisprotokoll. Wie gesagt das war nur einmal aber ein Keim für Sorge.
Jetzt habe ich (bestätigt durch Inhalte dieses Threads) von der Free- auf die Studio-Version gewechselt und bin begeistert. Plötzlich teilen sich CPU und GPU die Arbeit. In Edit- und Colortimeline läuft die CPU nur noch auf 50% Auslastung (vorher 100!) und beim Rausrendern wenigstens nicht mehr auf Anschlag (etwa 90%).
Ich nehme mal an, dass ein grösseres h.264-UHD-Projekt mit der Rechenpower nichts wird, aber um ein paar Clips oder einzelne Szenen zu bearbeiten und dann in ein beliebiges HD-Format zu wandeln scheint es zu reichen :-)

Ich weiß nicht, was für dich ein größeres Projekt ist, aber damit hat die Rechnerkonfiguration nur bedingt zu tun. Ausser natürlich die Festplatten ;)

dienstag_01 hat geschrieben: ↑Fr 10 Apr, 2020 11:11

Seba Peh hat geschrieben: ↑Fr 10 Apr, 2020 08:56 Mir hat dieser Thread auch sehr geholfen. Bin auch noch mit einem alten i7 (4790) und der GTX 970 unterwegs (dazu 32GB RAM und 2 SSDs jeweils für System und Daten).
In Resolve 16 hatte ich im Edit keine Probleme h.264-UHD abzuspielen. Im Color-Bereich fing es dann aber schon unbearbeitet an zu stottern, sprich es wurden einfach nicht mehr die vollen 30 Bilder pro Sekunde abgespielt. Arbeiten konnte man trotzdem, aber im Task-Manager war zu sehen, dass der Prozessor auf Anschlag lief. In etwa 3 Wochen Einarbeitung in Resolve ist mir dann einmal beim rausrendern (2 Spuren h.264 mit Alphakanal und ein paar Masken nach DNxHD) der PC einfach ausgegangen. Kernel 41 hiess es glaub ich im Ereignisprotokoll. Wie gesagt das war nur einmal aber ein Keim für Sorge.
Jetzt habe ich (bestätigt durch Inhalte dieses Threads) von der Free- auf die Studio-Version gewechselt und bin begeistert. Plötzlich teilen sich CPU und GPU die Arbeit. In Edit- und Colortimeline läuft die CPU nur noch auf 50% Auslastung (vorher 100!) und beim Rausrendern wenigstens nicht mehr auf Anschlag (etwa 90%).
Ich nehme mal an, dass ein grösseres h.264-UHD-Projekt mit der Rechenpower nichts wird, aber um ein paar Clips oder einzelne Szenen zu bearbeiten und dann in ein beliebiges HD-Format zu wandeln scheint es zu reichen :-)

Ich weiß nicht, was für dich ein größeres Projekt ist, aber damit hat die Rechnerkonfiguration nur bedingt zu tun. Ausser natürlich die Festplatten ;)

Meinst Du, dass es dem am Limit arbeitenden Rechner nichts ausmacht, wenn sich die Zahl der Spuren, Effekte etc. deutlich steigert. Das wäre ja super. Ich bin halt eher davon ausgegangen, dass die 3,5 oder 4GB der GTX 970 nicht für UHD/4K-Projekte ausreichen, so wie ich es überall im Netz gelesen habe. Ach stop.. meine Graka hatte ja noch Luft nach oben, der Prozessor war am Anschlag.. Hmm.. Von Premiere kenn ich es halt, dass die Rechnerstabilität ab ein paar Minuten mehrspurigem, mit Effekten beladenen Material in der Timeline nicht mehr so dolle war.

Seba Peh hat geschrieben: ↑Fr 10 Apr, 2020 13:44 Von Premiere kenn ich es halt, dass die Rechnerstabilität ab ein paar Minuten mehrspurigem, mit Effekten beladenen Material in der Timeline nicht mehr so dolle war.

Wobei das ein deutliches Zeichen ist, dass bei Deiner Hardware etwas nicht stimmt (unterdimensioniertes Netzteil, unzureichende Kühlung, defekter RAM). Dass ein Rechner bei Überlastung lahmt, ist normal - dass er abstürzt, nicht.

cantsin hat geschrieben: ↑Fr 10 Apr, 2020 14:12

Seba Peh hat geschrieben: ↑Fr 10 Apr, 2020 13:44 Von Premiere kenn ich es halt, dass die Rechnerstabilität ab ein paar Minuten mehrspurigem, mit Effekten beladenen Material in der Timeline nicht mehr so dolle war.

Wobei das ein deutliches Zeichen ist, dass bei Deiner Hardware etwas nicht stimmt (unterdimensioniertes Netzteil, unzureichende Kühlung, defekter RAM). Dass ein Rechner bei Überlastung lahmt, ist normal - dass er abstürzt, nicht.

Ich tippe auf das Netzteil. Über einen detaillierten Kalkulator bin ich auf etwa 490-495W gekommen und da ist es bei meinem 500er halt schon ungesund eng. Ich hab mir überlegt die GTX 970 durch eine RTX 2070 Mini zu ersetzen, die zieht nicht ganz so viel Strom und liefert die empfohlenen 8GB für UHD mit Resolve. (Aber eigentlich müsste ein neuer Rechner her, weil Prozessor zu alt, Netzteil zu schwach...und da jetzt noch 400-500 Euro investieren.. eher nicht.)
Im Moment schau ich aber erst mal, wie sich die Sache nach dem Upgrade auf Resolve-Studio entwickelt. Ich hab ja eigentlich nur deshalb hier geschrieben, weil ich so positiv überrascht war über die Lastverteilung beim h.264 entschlüsseln nach dem Upgrade.
Wenn mir aber noch jemand einen Tipp geben könnte, was ich bei meinem jetztigen Setting (i7-4790/32GB/GTX970/500W/Decklink Mini/2,5 Monitore/AG03...) tun könnte um das Netzteil vor Überlastung zu schützen, wäre ich sehr empfänglich ;-) Ich weiss nicht wie sich der Stromverbrauch unter Volllast verhält. Gibt's da Spitzen, die entstehen können und dann über dem vom Hersteller angegebenen maximalen Stromverbrauch der einzelnen Komponenten liegen?