Ich habe den Test mit dem Demo-Film noch in zwei weiteren Varianten ausgeführt:

1. Nvidia RTX 4000 als GPU
2. CPU-only, also ohne GPU-Nutzung

In Variante 1 kommt die Nvidia zum Einsatz, wird aber nur vergleichweise wenig ausgelastet:

Die 630 läuft dabei noch mit etwas Grundrauschen mit:

Die CPU verhält sich hierbei wie bei der ausschliesslichen Nutzung der 630.

Der Export war mit 3:20 etwas schneller.

In Variante 2 fühlte sich die CPU offenbar bemüßigt, etwas mehr zu leisten, allerdings immer noch fern der Vollauslastung:

Trotzdem war der Export mit 2:54 nochmals etwas schneller!

Außer Konkurrenz hier noch ein Einblick, wie das bei DaVinci Resolve aussieht, natürlich mit einem komplett anderen Film und daher bezüglich der Exportzeiten nicht zu vergleichen:

Die CPU hat recht gleichmäßig über alle Kerne zu tun, ist aber ebenfalls nicht voll ausgelastet:

Dafür ist die Nvidia bis zum Anschlag ausgelastet, stellt also das schwächste Glied in der Kette dar:

Ein solches Testergebnis hätte ich auch für VdL erwartet. Doch dort scheint der Engpass woanders zu liegen - nur wo?

Du solltes es mit dem H.264 und nicht mit dem MXV versuchen, denn der Codec ist von Intel nicht von Magix.

was wäre denn eine Vollauslastung für dich?

Natürlich ein Wert nahe an 100%, so wie dies Resolve für die GPU realisiert.

Du solltes es mit dem H.264 und nicht mit dem MXV versuchen, denn der Codec ist von Intel nicht von Magix.

Ich habe MPEG-4 mit H.264 verwendet (Preset "MP4 UltraHD 3840x2160 25p").

Natürlich ein Wert nahe an 100%, so wie dies Resolve für die GPU realisiert.

niemals, denn da verstehst du Windows grundsätzlich nicht. Wenn du dir den Taskmanager anschaust, dann laufen zwischen 70 und 90 Prozesse im Hintergrund, die alle irgendwelche Dienste erfüllen, z.B. das Lesen und Schreiben der Daten auf die Festplatte, Verwaltung des RAM, Lauschen auf dem Netzwerk, WLAN, Firewall, Antivirensoftware, Prozessverwaltung ... und vieles mehr. Windows würde sofort stehen bleiben und chrashen, wenn du einem Prozess nahezu 100% CPU Zeit geben würdest. Sorry, aber 60-70% im Durchschnitt sind realistisch. Mit bestimmten Eingriffen in die Registry kannst du auch 80% erreichen. Übrigens zeigt dein Screenshot 54% an.

Oha, da bringst Du aber allerhand durcheinander!

Zuerst einmal: Ich habe auf die GPU-Auslastung verwiesen - nicht die der CPU, auf die Du Dich beziehst.

Zum anderen geht es ja nicht darum, einem Prozess fest 100% CPU zuzuweisen. Das macht der Scheduler des Betriebssystems (hier Windows) selbsttätig anhand von Kriterien wie Prozess-Priorität, etc.

Aber vereinfachen wir das Szenario etwas, um es übersichtlicher und verständlicher zu machen, und nehmen an, dass es nur eine CPU gibt, die für alle Berechnungen verantwortlich ist.

Wenn jetzt ein Prozess im Zustand "ready" ist (also bspw. nicht auf I/O wartet) und CPU-Instruktionen ausführen will (so wie dies beim Encoding der Fall ist), dann bekommt er vom Scheduler die CPU dafür auch komplett zugeteilt - dann ist er im Zustand "running". Erst sobald ein anderer, insbesondere ein höher priorisierter Prozess etwas tun möchte, wird diesem die CPU zugeteilt, aber dies sollte im Normalfall nur das 'Ruherauschen' des Systems sein.

In Summe sollte die CPU-Auslastung beim Encoding auf jeden Fall nahe 100% sein! Niedriger kann sie nur sein, wenn es nichts für die CPU zu tun gibt, weil alle Prozesse entweder auf einen Event, I/O, o.ä. warten. Das ist beim Encoding aber in Zeiten von schnellen SSDs praktisch nicht mehr der Fall!

Gut, dann können wir ja wieder auf die Sachebene zurückkommen. Denn gottseidank lassen sich Aussagen durch einfache Tests leicht prüfen.

Hier mein System im Ruhezustand mit über 100 laufenden Prozessen:

Die CPU räkelt sich gemütlich herum - so wie es sein sollte.

Dann habe ich XMedia Recode mit einem Recoding von H.264 nach H.265 beschäftigt. Dabei war die CPU-Priorität sogar "Niedriger als normal" gewählt:

Die CPU kommt mit allen Kernen kräftig ins Schnaufen - so wie es sein sollte.

Soviel zur "niemals" möglichen Auslastung, die ich auch für VdL erwartet hätte (egal ob CPU oder GPU).

Die verbleibenden Fragen sind:

Tritt die von mir beobachtete vergleichsweise geringe CPU- und GPU-Auslastung beim Export durch VdL auch bei anderen Anwendern mit anderen Systemen auf? (Am besten mit dem gleichen Testfall prüfen.)

Falls nicht, müsste ich die Ursache in meinem System suchen. Und dies wohl primär im Umfeld von VdL, denn Resolve und XMedia Recode verhalten sich ja wie erwartet. Dann wäre eine Beschreibung der Systeme interessant, die dieses Verhalten nicht zeigen (gerne auch ohne die Build-Nummer von Windows ;-))

Oder wird die geringe Auslastung bei VdL womöglich als 'normal' angesehen, so wie FredW dies offenbar tut. Dann hätte ich gerne eine nachvollziehbare Erläuterung dafür.

Über konstruktive Hinweise würde ich mich freuen.

Du solltest mal mit einen anderen Quellmaterial (H.264) das probieren, ob sich ein Unterschied zeigt, bei mir schon.

Du solltest mal mit einen anderen Quellmaterial (H.264) das probieren, ob sich ein Unterschied zeigt, bei mir schon.

OK, H.264 als Quellmaterial ist wohl praxisnäher als MXV, wobei dann mangels eines allgemein verfügbaren Demo-Projektes die Vergleichbarkeit verloren geht. Dennoch ist dies auf jeden Fall einen Test wert.

Daher habe hierfür ein typisches meiner Projekte genommen und von H.264 nach H.264 in UHD rendern lassen.

Erster Testlauf mit der 630 als GPU ...

Dabei zeigt die CPU etwas mehr Auslastung als beim Demo-Projekt:

Die 630 hat als GPU deutlich weniger als beim Demo-Projekt zu tun:

Die 4000 läuft in etwa gleicher Auslastung ebenfalls mit:

Zweiter Testlauf mit der 4000 als GPU ...

Die CPU ist wieder deutlich geringer ausgelastet, etwa wie beim Demo-Projekt:

Die 630 läuft ebenfalls etwas mit:

Die 4000 hat hier als GPU mit rund 45% Auslastung etwa 10% mehr zu tun, als beim Demo-Projekt:

Zusammenfassung: Die Anteile von CPU und der beiden GPUs haben sich mit dem H.264-basierten Material etwas geändert. Eine weitgehende Auslastung zumindest einer der Komponenten erfolgt aber auch hier nicht.

@geschi, deckt sich dies mit Deinen Tests? Wie sieht dabei die Anzeige im Task-Manager aus?

@All: Kann irgendjemand beim Export durch VdL eine Nutzung von CPU oder GPU erreichen, wie dies mit Resolve oder XMedia Recode möglich ist?

Ganz verstehe ich deinen Ansatz nicht.
Ziel kann doch nicht sein, die CPU möglichst stark auszulasten.
Ziel sollte doch sein, egal ob durch die CPU oder welche GPU auch immer, einen schnellen, qualitativ hochwertigen Export sicher zu stellen, ohne dass der Rechner dabei blockiert ist.
Mein Knecht ist, denke ich, nicht schlecht aufgestellt, auch wenn er in EDV-Zeit gemessen nicht mehr der taufrischeste ist. Dennoch kann ich während eines Exports in 1080 50P locker weiter arbeiten und 30 Minuten Video sind in 20-30 Minuten exportiert. Abhängig von den verwendeten Effekten. Das reicht mir noch lange und wenn ich dein Eingangspost betrachte, wärst du wahrscheinlich sehr glücklich über diesen Zustand.
Es kann durch Quicksync bei der GPU-Auslastung der 630-er schon mal Spitzen von 60-70% geben. Dass ohne Hardwareunterstützung die CPU-Auslastung am Anschlag ist, ist auch klar, aber wohl keine Option.

Ich habe lange Zeit fast regelmäßig alle 3 bis max. 4 Jahre einen neuen Rechner angeschafft. Vom versprochenen Performance-Gewinn war ich regelmäßig enttäuscht. Einen gewaltigen Schub hat es durch Qicksync gegeben und ich glaube, wenn du (bei FHD, H264) darauf setzt, sind die zusätzlichen Zeitgewinne durch die allerneueste und allerbeste aller CPUs marginal. Meine Meinung.
Bei UHD und H265 kann ich wenig sagen. H265 scheint durch die Nvidia auch sehr performant zu sein. Kann ich aber aktuell nicht belegen und halte mich daher da raus.

Ziel kann doch nicht sein, die CPU möglichst stark auszulasten.

Doch genau das!

Vielleicht hilft Folgendes für das Verständnis: Um einen Film zu rendern, ist eine genau definierte Abfolge von CPU/GPU-Instruktionen ('Berechnungen') erforderlich, die sich aus dem Material, dem Algorithmus des Encoders, usw. ergibt. Dieser definierte 'Job' von vielen Milliarden Instruktionen kann am Stück erfolgen, ohne weitere Interaktion mit dem Benutzer (außer er bricht das Encoding ab).

Am schnellsten wird dieser Job natürlich verarbeitet, wenn sich die CPU/GPU komplett darum kümmert, also mit möglichst 100% ihrer Leistung, abzüglich von vielleicht 5%, die vom Betriebssystem, Virenscanner, Task-Manager usw. benötigt werden.

Im Idealfall ist die CPU/GPU also zu 100% beschäftigt. Alles was darunter liegt, bedeutet, dass sie mit der Abarbeitung auf etwas warten muss, bevor sie die Instruktionen weiter abarbeiten kann. Im schlimmsten Fall ist dies eine I/O-Operation, für die der Lesekopf einer Festplatte mechanisch zur korrekten Spur geführt werden muss, was im Vergleich zur I/O-Operation einer SSD natürlich um ein Vielfaches länger dauert. Aber dieses Problem ist bei aktuellen, korrekt konzipierten Systemen kaum noch relevant. Höchstens beim 'Scrubbing' über eine längere Timeline, wo schnell und nichtsequentiell auf große Datenmengen zugegriffen werden muss, die vielleicht auf einer FDD liegen.

Als Analogie: Wenn ich einem Handwerker eine definierte Aufgabe gebe, dann will ich ja auch nicht, dass er zwischendurch ständig Pausen macht.

Ziel sollte doch sein, egal ob durch die CPU oder welche GPU auch immer, einen schnellen, qualitativ hochwertigen Export sicher zu stellen, ohne dass der Rechner dabei blockiert ist.

Das Blockieren des Systems durch umfangreiche Rechnenjobs vermeidet man nicht, indem man die CPU/GPU Pausen machen lässt. Vielmehr reduziert man die Priorität eines solchen Prozesses im Vergleich zu solchen, die eine schnelle Reaktion z.B. auf Benutzereingaben erfordern. Wenn bspw. nebenbei eine Textverarbeitung läuft, dann bekommt diese sofort die CPU/GPU zugeteilt, sobald der Anwender eine Taste drückt. Dann wird das entsprechende Zeichen ausgelesen und auf den Bildschirm gepinselt, aber anschliessend ist gleich wieder der Hintergrundjob dran, weil bis zum nächsten Tastendruck ein paar Millionen Instruktionen abgearbeitet werden können.

Als Analogie: Der Handwerker soll ohne Pausen seine Aufgabe erledigen ohne dabei ständig auf sein Händi zu schauen, ob vielleicht sein Chef zwischenzeitlich angerufen hat. Wenn der Chef dann aber bimmelt, dann hat der Anruf die höhere Priorität und wird bearbeitet, bis nach dessen Abschluss dann die eigentliche Aufgabe fortgeführt wird.

Das sind alles seit Jahrzehnten allgemeingültige Grundlagen für die Prozeßverarbeitung durch den Scheduler von Betriebssystemen, egal ob Windows, MacOS oder Linux.

Sorry, wenn das etwas oberlehrerhaft rüberkommt, aber ohne dass solche Grundlagen allgemein akzeptiert sind, ist keine zielführende Diskussion möglich.

wobei dann mangels eines allgemein verfügbaren Demo-Projektes die Vergleichbarkeit verloren geht.

@LightCatcher

Du kannst dir das Demo-Projekt doch über Zusatzinhalte herunterladen. Ist gar nicht so schwer und die CPU wird auch nicht groß belastet. 😁

Du kannst dir das Demo-Projekt doch über Zusatzinhalte herunterladen. Ist gar nicht so schwer und die CPU wird auch nicht groß belastet. 😁

@BilderMacher, das hatte ich für meine erste Testreihe doch gemacht!

Dann hatte @geschi vorgeschlagen, es mit H.264-Material als Input zu versuchen. Das Demo-Projekt enthält aber nur MXV-Material.

Daher habe ich die zweite Testreihe mit eigenem Material durchgeführt.

Im Zweifelsfall bitte einfach nochmals nachlesen.

Auf dem Handy ist das zu viel Text, da scrollt man sich ja einen Wolf. 😐

@LightCatcher

Das sind alles seit Jahrzehnten allgemeingültige Grundlagen für die Prozeßverarbeitung durch den Scheduler von Betriebssystemen, egal ob Windows, MacOS oder Linux.

Diese Dinge sind mir durchaus bekannt. Neu ist mir, dass jemand als Anwender eines Programmes (nicht als Programmierer) darauf Einfluss nehmen möchte oder könnte, wie die Tasksteuerung zu arbeiten hat. Du sagst es doch selbst: das ist Sache des Betriebssystems.
Ich sehe das eher pragmatisch: eine GPU ist dazu da, die CPU zu entlasten. Wenn sich eine Last auf zwei Schultern verteilt, hat jeder weniger zu tragen, erreicht also die gewünschten 100% nicht mehr. Der Vergleich hinkt, das ist mir klar. Es kann ja so viel "zu tun" geben, dass dann jeder immer noch 100% erreicht.
Du nennst Resolve als Beispiel für eine bessere Auslastung. Darauf kommt es aber meiner Meinung nach nicht an. Wenn ich die Hardwarebeschleunigung bei VdL ausschalte, wird die CPU auch besser ausgelastet, bringt aber nichts.
Entscheidendes Kriterium müsste für dich eigentlich sein, welches Programm bei identischem Quellmaterial, identischer Clipbearbeitung in der NLE und identischen Exporteinstellungen die Arbeit am schnellsten erledigt. Und wenn sich beim Sieger CPU und/oder GPU dabei langweilen, ist das egal. Mir zumindest.
Also stelle doch für ein paar NLEs ein paar Clips für ein Testprojekt zusammen und teste dann den Export. Das würde mich wirklich interessieren, wenn auch nur wegen der Theorie. Wobei mir aber auch klar ist, das die Magix-Produkte beim Export nicht die schnellsten sind.

Ich habe deinen Test mit dem Demoprojekt auch nachgestellt. Mein Ergebnis deckt sich ziemlich gut mit dem, was du mit Nvidia RTX 4000 als GPU erreicht hast. Exportzeit: 3:18.
Das beruhigt mich und bestätigt mich in meiner oben gemachten Aussage, dass die Performancegewinne durch Rechneraufrüstung alle paar Jahre eher enttäuschend sind.

3:08 mit der HD 630, ab der Mitte gegen Ende läuft die CPU häufig mit 100%, OHNE "Videoeffekte auf der GPU berechnen".

4:00 mit "Videoeffekte auf der GPU berechnen":