GPU Encoding

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Dissidius schrieb:

    Ist die Qualität des Videos schlechter, wenn ich statt mit der CPU mit der GPU rendere?


    Qualität ist gleich. Je nach GPU verkürzt sich im Vergleich zur CPU allerdings die Renderdauer, da auf den GPUs normalerweise immer schneller DDR5-Speicher im Vergleich zum DDR3-RAM sitzt, mit dem die CPU arbeitet. Oder anders ausgedrückt: Seitdem ich über die GPU rendere, hat sich meine Renderzeit um 50% verkürzt.
    Aktuelle Projekte:
    Amnesia: The Dark Descent Playlist
  • FreshFries schrieb:

    Die Qualität ist genauso @Dissidius Problem wird nur die Dauer des Rendervorgangs sein.

    War es nicht so, dass es eher andersherum war? Die Encodezeit verkürzt sich und dafür leidet die Qualität darunter, da die CPU die Berechnungen sauberer ausführt. Deswegen sollte man es tunlichst vermeiden per GPU zu encoden, wenn man den x264 effizient einsetzen möchte.

    Zumindest war dsa bis vor 1-2 Jahren noch die gängige Standard aussage, oder hat sich daran mittlerweile etwsa geändert?
  • Major Brot schrieb:

    Zumindest war dsa bis vor 1-2 Jahren noch die gängige Standard aussage, oder hat sich daran mittlerweile etwsa geändert?

    Daran wird sich auch erst mal nix ändern.

    Siehe den Link in meinen letzten Beitrag. Dort erklärt der Fachmann warum und wieso GPU schlecht ist für Encodierungen.


    Jedoch (Und das sollte man wissen) sollte man das etwas trennen.

    Es ist ein Unterschied ob man via GPU berechnen lässt und via CPU encodiert oder ob man via GPU berechnen lässt und via GPU encodiert. Es gibt auch die Möglichkeit alles über CPU zu machen.

    Und diese 3 Konstellationen sollte man kennen. Vorausgesetzt man wirft das Wort "Rendern" nicht in einen Pott mit Enodieren. Das sind zwei verschiedene Sachen. Und daher können diese beiden Sachen auch ganz seperat GPU oder auch CPU nutzen.

    Als Beispiel:
    Blender. Wäre unlogisch es via CPU alles zu berechnen. Daher findet die Berechnung (eng. rendern) via GPU statt, wärend man die Videospeicherung via CPU encodieren lässt.

    Das können NLEs auch.

    Genauso erlauben einige NLEs das encodieren via GPU. CUDA von NVidia ist da eine Methode. Shadowplay lässt grüßen.
    Solche Encodings sollte man vermeiden.

    Daher... bitte nicht Rendern und Encodieren in ein Pott werfen. Ich weiß das NLEs das so darstellen. Aber es ist in NLEs ganz anders gemeint ^^

    In einer NLE wird erst mal bearbeitet und wenn das Projekt fertig ist, soll es berechnet werden. Daher wird das ganze "Rendern" genannt. Die Frage ist dann aber (was auch logisch ist) wo es hineinberechnet werden soll. Diesen Part nennt man Encodierung. Das ist dann wenn gefragt wird welchen Codec und/oder welches Videoformat man wählen möchte. Das hat dann nix mit Rendern zu tun.

    Das sieht man bei AVISynth und einen externen Encoder eindeutig wie das lang geht ^^

    Wie gesagt: Das Berechnen (Rendern) darf gerne via GPU sein. Das Encodieren allerdings sollte via CPU laufen.

    Ich poste aber gerne noch mal die Erklärung dazu hier rein, die ja schon in meinen letzten Beitrag stand: computerbase.de/forum/showthre…185&p=9557413#post9557413

    Er erklärt das ausführlicher.
  • FreshFries schrieb:

    Die Qualität ist genauso

    Amano schrieb:

    Qualität ist gleich


    Nein ist sie nicht.

    computerbase.de/forum/showpost.php?p=9557413&postcount=9
    computerbase.de/forum/showpost.php?p=9947207&postcount=46
    computerbase.de/forum/showpost.php?p=9952783&postcount=52

    Von daher bitte erstmal informieren bevor man solche Behauptungen rausschmeißt^^
    Aktuelle Projekte/Videos


  • Amano schrieb:

    da auf den GPUs normalerweise immer schneller DDR5-Speicher im Vergleich zum DDR3-RAM sitzt, mit dem die CPU arbeitet.

    Kleiner Tipp, das ist auch in Wirklichkeit nur umgelabelter DDR3. Ein "G" steht davor (es heißt also "GDDR5"), damit es keiner mit "echtem" DDR5 (den es nämlich erst 2018 geben soll) verwechselt.

    DDR4 existiert übrigens seit diesem Jahr tatsächlich, Grafikkarten setzen aber vorerst noch auf modifizierten DDR3. :P

    Zitat: "Like its predecessor, GDDR4, GDDR5 is based on DDR3 SDRAM memory."
    Quelle: en.wikipedia.org/wiki/GDDR5
    ——YouTube————————————————————————————————————————————
    — Endlos-Projekte: Minecraft (SinglePlayer), Craft The World, Banished, Besiege, Sims4
    — ..Abgeschlossen: Leisure Suit Larry 6+7, Dishonored, Surface 2+3, Mirrors Edge, uvm
    — . Kurz- Projekte: The Tower, Fighting Is Magic, Euro Truck Simulator 2, uvm
    — ......Retro-Ecke: Day Of The Tentacle, Flight Of The Amazon Queen, NFS: HP2, uvm
    ————————————————————————————————————————————TbMzockt.de—
  • Sagaras hat da recht, Rendern und Encodieren nicht verwechseln.

    @Wombi "Exportieren" als Begriff ist ja noch etwas schwammiger. Was wir ddenn bei dem Export Vorgang getan ? Bereits gerendertes Material Encodiert oder gerendert und danach encodiert ? Zudem kommt darauf an, falls beides geschieht, wird nur das Rendering GPU gestützt oder nicht ?

    Das Einzige was mir an der verlinkten Erklärung von Sagaras nicht gefällt ist die Sache mit der Genauigkeit. Tatsächlich sind GPUs im gegensatz zu CPUS auf Flusskommazahlen Berechnung optimiert um sogar präzisier zu arbeiten. Der Punkt ist, sobald Flusskommazahlen ins Spiel kommen, kommt Rundung mit ins spiel. Und das wird auch gemacht, nicht nur gerundet sondern ordentlich eines jeden Hirn verarscht ;)
    Computer Graphik hat heut zu Tage viel mehr mit der Physiologie des Menschlichen Hirnes und mit Physik zu tun als viele Annehmen. :)
    "Semper Fi!" - United States Marine Corps
    "Who dares, wins!" - British SAS
  • Wäre mir neu das MagicYUV, Lagarith oder UTVideo mit GPU laufen. Die arbeiten alle auf CPU.

    CUDA ist eine Methode die von NVIDIA via GPU läuft.

    Hmm... wie soll ich euch das erklären am besten?

    GPU Encodierungen sind folgende Codecs:
    Intel Quick Sync, Nvidia NVEnc und AMD VCE

    Diese 3 Sachen laufen und arbeiten viel mehr beim Encodieren mit GPU, statt CPU.
    Diese 3 Sachen sollte man auf jedenfall vermeiden wenn man sie sieht. ;D

    MSI Afterburner hat zur Aufnahmeauswahl den Intel Quick Sync. Ein reiner GPU Encoder.
    Shadow Play nutzt den Nvidia NVEnc. Auch GPU bedingt.

    Einige NLE Encoder können diese 3 GPU Encoder auch ansteuern. Sie alle sind oftmals für H264 konstruiert, weshalb man diese Methoden auch bei den H264 Einstellungen in einer NLE finden kann.

    Wie gesagt: Das ganze beruht auf das Encodieren. Und dort sollte GPU vermieden werden.


    Beim Rendern (deu. Berechnen) aber wird ja keine Encodierung verwendet. Das Rendern bezieht sich auf die Bildsynthese hin. Sprich wenn Effekte und Co. die Frames beeinflussen. Bei AVISynth z.B. kann man das ganze Teilweise umgehen, da AVISynth ja auch noch ein Frameserver darstellt.
    Bei einer NLE jedoch müssen Zwangsläufig die Frames neu berechnet werden.

    Diese Berechnung von Effekten und Co. kann gerne via GPU berechnet werden.


    Daher sagte ich ja das ihr das unbedingt trennen solltet die Begriffe.
    Das eine hat mit dem anderen nix zu tun. Es ist eigentlich nur das Unwissen das viele Menschen glauben macht das Rendern und Encodieren das gleiche sind. Dem ist aber nicht so. ^^

    SuicideSnoman schrieb:

    Das Einzige was mir an der verlinkten Erklärung von Sagaras nicht gefällt ist die Sache mit der Genauigkeit. Tatsächlich sind GPUs im gegensatz zu CPUS auf Flusskommazahlen Berechnung optimiert um sogar präzisier zu arbeiten. Der Punkt ist, sobald Flusskommazahlen ins Spiel kommen, kommt Rundung mit ins spiel. Und das wird auch gemacht, nicht nur gerundet sondern ordentlich eines jeden Hirn verarscht

    Joa... mir wäre aber neu das bei Video Encodierungen bei der GPU und der CPU andere Fließkommazahlentypen genutzt werden ^^ Und wenn du die Rundungen nur meinst... also ehrlich gesagt hab ich noch niemanden auf der Welt gesehen der ein Rundungsunterschied von 0,00000000001 unterscheiden kann. Nein, mal ehrlich... eine CPU rundet da auch gut genug. Und allein bei der Videoencodierung sind es wenn schon Fließkommazahlen deren Rundungen nicht ins Gewicht fallen. Oftmals werden nur bis max. 4 Stellen nach dem Komma genommen bei Enodiervorgängen.

    Zudem lassen sich Kommaberechnungen auch gerne ins Ganzzahlsystem übertragen.
    29.97 muss man doch gar nicht schreiben ^^ Reicht doch schon wenn man 2997 nimmt ^^

    Also bei Encodierungen wäre es mir neu wenn es dort hohe Fließkommazahlen geben würde. Zumal alle Kommazahlen auch ins Ganzzahlsystem übertragen werden können.

    Nix desto trotz wird die GPU bei Encodierungen aufgrund der nichtausführung oder geringen Nutzung von Parallelisierungen der CPU unterlegen sein bei Viedeo Encodings.

    Fakt ist auch ein GPU Encode sieht im Endeffekt schlechter aus als ein CPU Encode, aufgrund das die Hersteller dieser GPU Encodes die Settings dafür runtergedreht haben.
    Daher sind GPUs sehr schnell, aber Qualitativ nicht Hochwertig wie sie es bei CPU Encodern genutzt werden hätten können.

    Und wenn ich ein CPU Encoder ebenfalls so schlecht einstelle das sie einem GPU Encoder gleicht, habe ich mit dem CPU Encoder genauso oder sogar schnellere Geschwindigkeit beim Encodieren.

    Das ganze gilt aber nur bei Videoencodierungen und gegebenfalls Audioencodierungen. Solche Prozesse lassen sich nicht einfach so beschleunigen.

    In anderen Bereichen sind solche Parallelisierungen gewünscht. Und das ist das Rendern. Sprich die Bildsynthese. Das ist in Grafikprogrammen so und auch in Spielen. Aber bei Videoencodierungen sehr mies ;D
  • @Sagaras
    Das mit dem Runden war ja auch nicht negativ gemeint. Bei Grafik Anwendung fallen Rundungen ja nicht ins Gewicht da die Genauigkeit gar nicht gebraucht wird. Mit Optimierung meinte ich nicht optimiertes Runden, sondern bessere Perfomance bei der Ausführung von Flusskommaberechnungen. ^^
    War vielleicht blöde ausgedrückt :/

    So Spontan fällt mir jetzt nämlich auch kein Codec ein der FKZ nutzt. Selbst im TV Bereich nicht. Da wird ja Standard Mäßig YCrCb genutzt und je nach Verfahren über mehrere Pixel die Chroma Werte gemittelt um Bandbreite bei der Übertragung ein zu sparen (Sub Sampling). Entsprechend bringt eine besser Performance bei FKZ ja auch in diesem Fall nichts beim Encodieren.
    "Semper Fi!" - United States Marine Corps
    "Who dares, wins!" - British SAS
  • Alle Encoder basieren auf CPU Encoding. Natürlich bis auf die bereits genannten Intel Quick Sync, Nvidia NVEnc und AMD VCE die dann via GPU betrieben werden.

    GPU Rendering sollte so ziemlich jede gute NLE oder Grafikprogramm anbieten können.

    Ein kleiner Nachteil an AVISynth, da AVISynth oftmals nur CPU Filter nutzen kann.
    Sprich Sachen wie Motion Blur wird in AVISynth via CPU berechnet.

    In einer NLE aber können Berechnungen via GPU geschehen. Einige haben sogar die Auswahl zwischen GPU Berechnung und CPU Berechnung.

    x264vfw ist ein CPU Encoder
    x264cli wie er in MeGUI genutzt wird ist ein CPU Encoder

    AVISynth basiert ledeglich auf CPU Berechnung

    Bedeutet: Wenn eine NLE in der Lage ist GPU beim Berechnen zu nutzen, so kann man dies gerne nutzen.

    Warten muss man sowieso da sich das ganze dann anstauchen tut vor dem CPU Encoder.

    Sprich: Video -> NLE -> GPU Rendering -> CPU Encoding (x264) -> fertiges Video

    Was einen AVISynth aber als Vorteil gibt ist der das die Videos nicht umkonvertiert werden. Eine NLE macht das so oder so. Darum fungiert AVISynth als Frameserver deutlich schneller als eine NLE, obwohl es via CPU läuft.

    AVISynth kann nur geschlagen werden wenn eine NLE oder ein Grafikprogramm mit massiven Effekten kommt die auf GPU Ebene berechnet werden. Dann wäre die NLE oder das Grafikprogramm deutlich schneller.

    AVISynth ist aber dank seiner Filter und der CPU Nutzung sehr Detailfreudig. Weshalb es auch zur Restauration oder Feinausgleich genutzt wird von vielen Profis. Das was NLEs nicht so sauber hinbekommen. ;D

    Also ich weiß z.B. das Vegas die Möglichkeit besitzt mit GPU zu berechnen und natürlich weiß ich zu 100% das das Teil mit CPU encodieren kann ^^ Wie jede NLE mit CPU encodieren kann halt xD

    Aber ob eine NLE GPU Rendering besitzt oder nicht, das sollte man selbst mal nachschauen. ^^

    After Effects wäre ohne GPU Nutzung seeeeeehr langsam was die Berechnung mit Motion Tracking angehen würde ^^

    Wie gesagt... schaut selbst mal nach ^^

    SuicideSnoman schrieb:

    So Spontan fällt mir jetzt nämlich auch kein Codec ein der FKZ nutzt. Selbst im TV Bereich nicht. Da wird ja Standard Mäßig YCrCb genutzt und je nach Verfahren über mehrere Pixel die Chroma Werte gemittelt um Bandbreite bei der Übertragung ein zu sparen (Sub Sampling). Entsprechend bringt eine besser Performance bei FKZ ja auch in diesem Fall nichts beim Encodieren.

    Jeder Codec sollte FKZ nutzen können ^^
    Wenn ich mir so die Formeln mal anschaue für Farbmatrizen für YUV Farbräume ^^
    YCrCb ist ein reines YUV Format. Bestehend aus Luma (Y) und jeweiligen Chromaanteilen (UV)
    Bei YCrCb sind es Chroma rot und Chroma blau.
    Bei Komponentenkabel werden sie als RGB Kabel auch oft bezeichnet ^^
    R - Chroma (Rot-Grün Anteil) = Cr
    G - Luma (Helligkeitsanteil) = Y
    B - Chroma (Blau-Gelb Anteil) = Cb

    CrCb ist dann der UV Anteil

    Also reines YUV sozusagen. Oftmals liefert ein Komponenten Kabel YUV420

    Dennoch... die Farbmatrix und generell der Farbraum wird in Gleitkommazahlen berechnet. Jeder Farbanteil. Diese können auch Negativwerte annehmen.

    z.B.:
    Y mit 0.5
    Cr mit -1
    Cb mit -1
    wäre dann ein normales sattes Grün.

    Oder
    Y mit 1
    Cr mit 0.11242
    Cb mit -0.11021
    wäre ein etwas bräunlicher Ton

    Mittelpunkt wäre wenn Cr und Cb 0 wären. Dann würde Y von 0 bis 1 alle Grautöne darstellen.

    Dann kommt noch die Farbunterabtastung hinzu.
    Beim Encodieren kommen GOP Größen und Einteilungen vor. Quantizer Berechnungen etc. pp.

    Also ein durchaus komplexes Gebilde. Ich selbst werde da auch nicht alles verstehen. Aber ich würde mal einfach behaupten das es ohne diese Fließkommazahlen oder Gleitkommazahlen nicht gehen würde ^^

    Und trotzdem wird der GPU Encode langsamer verlaufen als der CPU Encode. Und was die Rundungsfehler betrifft, die fallen einen eh nicht auf. Gerade weil GPU Encodes so dermaßen schlecht konfiguriert sind, ist das sowieso total belanglos.

    Du kannst mir glauben... beim Rendern von Spielen oder anderen Grafischen Sachen ist GPU top. Aber bei Encodierungen ein flop ;D Ist einfach so. Den größten Teil hat ja schon Tom Keller erklärt in den Links die wir ganz oben schon gepostet hatten ^^

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Sagaras ()