Warum ist xmediarecode so langsam?

EmmaL

Lieutenant
Registriert
Apr. 2020
Beiträge
758
Hallo, ich möchte ein UHD Video zu 1080p h265 umwandeln und ich frage mich warum meine CPU und Grafikkarte nur 10 % bzw. 4% ausgelastet ist? Müsste das nicht alles auf 100% laufen? Die Konvertierung braucht voraussichtlich 4 Stunden für 8 Stunden Videomaterial.

1625859655033.png
 
Das könnte am verwendeten Programm liegen
Nimm als Programm Handbrake, das lastet meinen 5950 X bei UHD Material fast vollständig aus,
 
  • Gefällt mir
Reaktionen: FreedomOfSpeech
Es kann sein, dass er es ueber den Encoder der GPU berechnet, das taucht dann nicht als reine Grafikauslastung auf, da es besondere Hardware auf der Grafikkarte ist.
 
EmmaL schrieb:
und ich frage mich warum meine CPU und Grafikkarte nur 10 % bzw. 4% ausgelastet ist?
Kommt drauf an auf was du gerade encodest. Scheinbar ist der Hardwareencoder auf der GPU ja voll ausgelastet.
Screenshot 2021-07-09 at 21-44-44 Warum ist xmediarecode so langsam .png

Schneller gehts also nicht, es sein denn deine CPU wäre bei derselben Qualitätseinstellung schneller. Aber das ist unwarscheinlich.
 
EmmaL schrieb:
Müsste das nicht alles auf 100% laufen?
Ja, das tut es auch. Allerdings musst du dann XmediaRecode auch die entsprechenden Ressourcen zur Verfügung stellen. Sonst dümpelt es nur nebenher, um dein System nicht (voll) auszulasten. Du kannst bei XmediaRecode sogar alle CPU Ressourcen zum Rendern freigeben, der Punkt nennt sich "Echtzeit"

Ich verwende das nur und bin vollauf zufrieden, das Teil rennt wie Schmidts Katze. Handbrake ist übrigens fast genauso aufgebaut, beinahe ein Clone von Xmedia.
Ergänzung ()

ghecko schrieb:
Kommt drauf an auf was du gerade encodest. Scheinbar ist der Hardwareencoder auf der GPU ja voll ausgelastet.
Anhang anzeigen 1100058
Schneller gehts also nicht, es sein denn deine CPU wäre bei derselben Qualitätseinstellung schneller. Aber das ist unwarscheinlich.
XmediaRecode will die CPU zum Rendern. Damit gehts sicher besser.
 
xy_Tux schrieb:
XmediaRecode will die CPU zum Rendern.
Gerade wird offensichtlich auf dem Hardwareencoder der GPU encodiert, da fällt nur wenig "Arbeit" für die CPU selbst an.
Xmediaencode nutzt das, was ihm zugeteilt wird. Und es ist mit Nichten schneller auf der CPU, die können nicht zaubern. Ein spezialisierter Hardwareencoder ist bei derselben Qualität immer schneller als generische CPU-Hardware, die das in Software ausführt.

Und das versteht der TE nicht. Er denkt, wenn er encodiert wird fröhlich die Last auf die CPU und die GPU verteilt. Was nicht der Fall ist. Entweder es läuft auf der CPU oder auf dem Encoder der GPU. Und je nach API werden Teilschritte beim Hardwareencoding auch auf die Shader oder auf die CPU ausgelagert, das sieht man teilweise an seiner CPU-Auslastung. Einen Kombimodus, der alle vorhandenen Ressourcen zu 100% nutzt, gibt es nicht.
https://en.wikipedia.org/wiki/Video_Coding_Engine
https://en.wikipedia.org/wiki/Nvidia_NVENC
https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: HisN und xy_Tux
Die nutzen beide ffmpeg unter der Haube.
Beispiel batch
Code:
for %%a in ("*.*") do ffmpeg -i "%%a" -c:v libx265 -crf 22 -c:a aac -b:a 320k "newfiles\%%~na.mp4"
 
4 Stunden für 8 Stunden Videomaterial in h.265 muß auf der GPU laufen. Das Enkoding läuft mit Faktor 2, das schaffst du in Software auf der CPU nicht. Mein Ryzen 9 mit 8 Threads schafft in Software etwa Echtzeit.
GPU nur wenn Geschwindigkeit notwendig ist. Für Qualität in Software auf der CPU.
 
  • Gefällt mir
Reaktionen: I'm unknown und ghecko
NameHere schrieb:
Die nutzen beide ffmpeg unter der Haube.
Beispiel batch
Code:
for %%a in ("*.*") do ffmpeg -i "%%a" -c:v libx265 -crf 22 -c:a aac -b:a 320k "newfiles\%%~na.mp4"
Bei dem Beispiel wird der x265-Encoder verwendet, der die CPU benutzt, und nicht der Hardware-Encoder der GPU. Bspw. für NVENC müsste man den Parameter -c:v hevc_nvenc verwenden. Mehr dazu hier.
Afaik ist Handbrake auch keine GUI für ffmpeg, sondern benutzt nur für bestimmte Codecs ffmepg zum Encoding/Decoding. Der Funktionsumfang überschneidet sich natürlich teilweise, ist aber nicht gleich. Bspw. die ganzen Filterfunktionen von ffmpeg sind in Handbrake nicht enthalten.

Edit:
T00L schrieb:
Das Enkoding läuft mit Faktor 2, das schaffst du in Software auf der CPU nicht. Mein Ryzen 9 mit 8 Threads schafft in Software etwa Echtzeit.
Das stimmt so allgemein einfach nicht. Es kommt stark auf das Videomaterial (v.a. Auflösung und Bildwiederholrate), den Encoder und die Encoder-Einstellungen an.
Ich habe das gerade mal schnell mit meinem alten i5-2400 (Sandy Bridge) und einem Musikvideo von Youtube in 1920x1080 (24 fps) getestet und mit x265 und der Voreinstellung ultrafast erreiche ich durchschnittlich eine Encodiergeschwindigkeit von ca. 30 fps (1,25*Echtzeit), mit x264 (ebenfalls Voreinstellung ultrafast) sogar 145 fps (6*Echzeit).
Mit einer modernen CPU sollten 2*Echtzeit mit x265 und Voreinstellung ultrafast dann kein Problem sein.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: NameHere
Wenn nur der DEDIZIERTE Hardware-Encoder auf der Graka genutzt wird (und kein Shaderbasierter Encoder), dann läuft die Graka nur auf 10%.
Sieht man wann man Shadowplay benutzt oder alles andere das NVENC utilisiert.
Noch nie aufgefallen?

Und die CPU langweilt sich derweil. Eine "hybride" Lösung. Also eine Software die alles gleichzeitig nutzen kann und dann das Ergebnis von CPU-Encode, Graka-Encode und NVENC zusammenmischt ist mir nicht bekannt.
Wobei das bestimmt nicht ganz blöd wäre, denn bei "schwarz" ist der Nvidia-Encoder nicht immer supersauber.

Wenn Du es "nur" über die CPU machst, dann geht die bestimmt auch ordentlich auf Last und braucht trotzdem deutlich mehr Zeit als der Graka-Encoder.
 
  • Gefällt mir
Reaktionen: EmmaL
Je nach Tool das du braucht werden nur 1 oder 2 Kerne voll ausgelastet und der Rest der cpu wird nicht benutzt, ergibt volle Auslastung der 2 Kerne aber nur 20% der Gesamtkapazität. Es gibt Tools die können das auf mehrer Kerne verteilen, manche nicht .
 
Ok, also ich habe jetzt das Programm 2x gestartet und kovertiere zwei Videos gleichzeitig. Die Auslastung von GPU und CPU ist nun doppelt so hoch und das Konvertieren geht nicht langsamer pro Video. Also läuft die CPU und GPU tatsächlich nur bei ca 7 bzw. 4 % Auslastung.
 
EmmaL schrieb:
Ok, also ich habe jetzt das Programm 2x gestartet und kovertiere zwei Videos gleichzeitig. Die Auslastung von GPU und CPU ist nun doppelt so hoch und das Konvertieren geht nicht langsamer pro Video. Also läuft die CPU und GPU tatsächlich nur bei ca 7 bzw. 4 % Auslastung.
Hast du dir auch die Antworten hier durchgelesen? Dir wurde mehrfach erklaert, woher diese Auslastung kommen kann...
 
  • Gefällt mir
Reaktionen: brianmolko
SJAFNWEIF schrieb:
Edit:
Das stimmt so allgemein einfach nicht. Es kommt stark auf das Videomaterial (v.a. Auflösung und Bildwiederholrate), den Encoder und die Encoder-Einstellungen an.
Ich habe das gerade mal schnell mit meinem alten i5-2400 (Sandy Bridge) und einem Musikvideo von Youtube in 1920x1080 (24 fps) getestet und mit x265 und der Voreinstellung ultrafast erreiche ich durchschnittlich eine Encodiergeschwindigkeit von ca. 30 fps (1,25*Echtzeit), mit x264 (ebenfalls Voreinstellung ultrafast) sogar 145 fps (6*Echzeit).
Mit einer modernen CPU sollten 2*Echtzeit mit x265 und Voreinstellung ultrafast dann kein Problem sein.
Wenn ich UltraFast einsetze, kann ich gleich auf die GPU gehn.
Ich rede von qualitativ guten 1080p aufwärts Enkodings bei mind. slow. Genau da komme ich auf die ca. Echtzeit mit 8 Threads ausgelastet bei Handbrake.
 
Ah interessant also ich kriege nen 16 Kerner voll ausgelastet naja zu 93 % weil ich ebenso 2 die selbe Software gestartet habe. Und warum es bei gpu schlechter aussieht liegt daran das die gpu keine crf beherrscht, denn dann wäre sie ja gleich bei der Bildqualität wie bei CPU.
 
GPU sieht schlechter aus bzw. braucht für gleiche Qualität mehr Bitrate, da die Hardwareencoder einfach für andere Anwendungsfälle ausgelegt sind, nämlich primär Geschwindigkeit. (Kamera, Smartphones, Streaming etc.)

CPU Encoding mit einem Ryzen 3700x:
x265 1080p Preset Slow ~10-15 fps
x264 1080p Preset Veryslow ~20-30 fps

Ist natürlich auch ganz schön Bitratenabhängig.

Bei x265 1080p und darunter empfiehlt sich ctu=32 zu setzen, bringt nochmal etwas Geschwindigkeit. Bis zu 5 fps mehr, je nach Einstellungen. CPU-Auslastung von 60% auf 98. Der Standardwert von 64 ist bei bei Auflösungen <UHD viel zu hoch gesetzt.
Oft hat man bei x265 das Problem, dass CPUs ab 8 Kerne nicht richtig ausgelastet werden.

4 Stunde für 8 Stunden Videomaterial ist also in dem Fall, den der TE beschreibt, nicht langsam, sondern schon blitzschnell^^
 
Zuletzt bearbeitet:
Ja da hast du recht, das Problem habe ich zum glück nicht. Zumal ich nur in 720x576, 1280x720 selten und in 1920x1080 super selten umwandle. Alles wandle ich in h264 um weil das am schnellsten vom codec her ist. Habe settings auf eher niedriger gestellt weil mir Geschwindigkeit sehr wichtig war. Profil medium weil höher kostet geschwigkeit. Vielleicht sollte wenn er es schnell haben will nur von 4k nur in Full HD abskrollen. Oder geht es primär nur darum das zu niedrige auslastung herrscht. Klar könnte man auch 3x starten 2 auf CPU und 1 rein nur auf gpu aber ist halt die Frage was dem thread Ersteller wichtiger ist Bildqualität oder Geschwindigkeit. Es sei denn man stellt es so für sich um, m beides zu haben. Ich musste auch es in direkt Vergleich schauen wo ich herunter stellen konnte und wo nicht. Habe direkt Bilder in B, P und inter also der Übergang gemacht und direkt mit einander verglichen. So hatte ich herausgefunden gehabt was viel Zeit gekostet hatte und was am wenigsten für die Bildqualität gebraucht hatte. Dadurch konnte ich den besten Kompromiss für beides herausfinden. Klar ist es sowas zeitfressend aber wenn man sowas will also beide Richtungen geht es eben nicht anderst. Und klar liegt der Schwerpunkt bei höheren Auflösung auch woanderst. Ich habe das große Glück keine so schweren schützen zu fahren.

Was mir ebenfalls aufgefallen ist das es zwischen 720x576 und 1280x720 nicht mehr cpu auslastung bei 1 fährt. Darum sind 2 bei mehr als 8 Kernen unabdingbar für die optimale CPU auslastung. Darum habe ich es ja so auch gemacht gehabt.
 
Zuletzt bearbeitet:
Schoene Anekdoten, aber der Thread ist 5 Monate alt.
Der Ersteller hatte scheinbar auch kein so großes Interesse am Thema.
 
ich belebe diesen alten Thread mal wieder da ich ein ähnliches Problem habe. Das mit der Auslastung habe ich schon verstanden, aber bei mir ist es (trotz flotter Hardware) noch extremer.

ich möchte ein 30min Video konvertieren
Quelle: 2160p 60fps 38mbit HEVC
Ziel: 1440p 60fps 20mbit HEVC
Dauer: knapp 3 Stunden mit Einstellung "Echtzeit"

CPU: Ryzen 9 5900X
GPU: RTX 3080TI
PCIe3 NvMe SSD

aktuell scheint die GPU zu dekodieren, somit ist die CPU Einstellung "Echtzeit" ja wertlos oder? Wenn ich es richtig verstanden habe soll die CPU flotter beim dekodieren sein. Wie stelle ich das in xmedia um?

anbei meine Einstellungen. Es ist alles auf default, nur die Bitrate ändere ich manuell


Danke sehr
 

Anhänge

  • Unbenannt.jpg
    Unbenannt.jpg
    55,3 KB · Aufrufe: 104
Zuletzt bearbeitet:
Also es ist bewiesen das echtzeit keine große Verbesserung mehr macht. Es kostet nur unnötig mehr Rechenleistung. Ich habe es meist auf hoher als normal.

Achja setzte bei Bitrate Modus lieber zu effizienter wie constante Bitrate, wie halt crf. Das ist deutlich effizienter und die CPU kann hier sich vollends entfalten. Aber Vorsicht nicht zu niedrige Zahl eingeben weil das kostet wiederum sehr viel leistung. Bei mir ist gpu auch schneller als die CPU.
Du willst also das die CPU und nicht die gpu umwandelt, dann heißt es wohl einen anderen codec zu verwenden. Man kann es ganz leicht wechseln.

Oder wie meinstest du das denn sonst?
 
Zurück
Oben