Videokompression und Schnitt - Erfahrungen

  • Nachdem ich im anderen Thread festgestellt habe das so einige sich damit beschäftigen, dachte ich mir das man hier vielleicht etwas Erfahrungen diesbezüglich austauschen kann.

    Ich experimentiere derzeit mit Handbrake herum und wenn es da andere gute und gut bedienbare Alternativen gibt bin ich da natürlich offen.


    Ich habe auf meinen System mit einem Intel 12700KF nebst NV 3080Ti mal folgende Erfahrungen gemacht zum Thema Umkomprimierung.

    Test Ausgangsdatei:

    "For all Mankind S3E01" 1080p x264 4,96GB bei 057:22 Spielzeit


    Handbrake mit x265 Kompressionseinstellung:

    Zeitaufwand 15:33 bei RF23 und einer Filegröße von 0,86 GB


    Handbrake mit x265NVEnc Kompressionseinstellung (inkl. Verwendung der GPU):

    Zeitaufwand 03:32 bei RF23 und einer Filegröße von 2,13 GB

    Es scheint wohl ein gängiges Problem zu sein das GPU Komprimierung deutlich längere Files erzeugt ?



    Mein erwähntes Problem mit "Zickzack" Effekten (in der Animation besser sichtbar😏) bei speziellen Szenen habe ich übrigens lösen können, es lag an dem Default aktiven Interlacefilter "decomb", deaktiviert ist die Welt in Ordnung.

    Quelle:

    x265:

  • Generell lässt sich sagen, dass die CPU fast alles über Software kodiert, das bedeutet, dass je nach Software und Encoder alles auf dessen aktuellem Stand ist und die Ausgabequalität einzig von den in der Software verwendeten Algorithmen abhängt.


    Dass deine CPU das in nur 15 Minuten kodiert hat und die Dateigrößé auch viel kleiner ist würde ich jedoch einer geringeren Bitrate bei der Kodierung zuschreiben. Auch kann es sein, dass du bei einem vielleicht nur 1-Pass Kodierung gemacht hast und beim anderen 2-Pass was auch Auswirkungen auf die Qualität hat.

    Auch der GOP ist ein wichtiger Wert, also die Bildgruppe wo ein Bild komplett verarbeitet wird und dann nach einigen Frames erst das nächste komplette Bild und dazwischen halt nur die Unterschiede.


    Wie gesagt, leider nutze ich kein Handbreak, werde vielleicht aber wenn ich Zeit habe doch mal wieder reinschauen. Mir war das damals jedenfalls zu kompliziert.

  • Generell lässt sich sagen, dass die CPU fast alles über Software kodiert,

    Sorry könnt euch gerne weiter ungestört von mir hier austauschen.

    Zum zitierten Text JEIN:

    1. äh wie sonst sollte eine CPU das machen das ist ihr Job.

    2. Ich würde das nicht alles über SW, sondern als Brute-Force bezeichnen.

    3. Man kann HW und damit auch CPUs auch so gestalten das sie bestimmte SW besonders effizient berechnen kann. Aber wenn man eben eine CPU für alle SW haben will, kann die halt nicht nur auf wenige Fälle spezialisiert sein.

    Im Falle von Video-de-/und Video-en-coding muss der Codec unterstützt werden. (BTW Decoden = das Video in dem Packformat zu erzeugen, Encoden = Das Video aus dem Format wieder herausholen, meist um es abzuspielen)

  • Zu Punkt 3, du meinst man kann eine CPU so gestalten, dass sie bestimmte Algorithmen besonders effizient berechnen kann. Was aber eben dem Punkt 1 und 2 widerspricht, da letztlich eben doch nicht alles mit "Brute Force" berechnet wird.

    Gerade AMD CPUs unterstützen die Video De- und Kodierung durch entsprechend eingebaute Algorithmen und somit Unterstützung für modernere Codecs sind aber weit von der Unterstützung in GPUs entfernt.


    Es ist übrigens spannend, auf Android kann man in Playern wie VLC oder MX Player auswählen ob ein Video mit "Brute Force" rein in Software abgespielt werden soll, ob mittels der in der CPU verbauten Algorithmen in Hardware oder mittels Unterstützung des Grafikchips Hardware+. Die Auswahl besteht, weil diese ARM Chips wohl nicht alle Codecs unterstützen. Die Wiedergabe in Software von hochbittigen 4k Videos kann man auf den meisten Smartphones dann aber auch vergessen, die sind zu schwach um das flüssig zu können. Da zeigt sich eben auch deutlich, dass X86 Desktop PCs von der reinen Rechenpower in ganz anderen Regionen spielen.


    Wobei mein über zehn Jahre altes Notebook mit Single Core i3 aus der ersten (?) Generation das inzwischen auch nicht mehr hinkriegt.

  • Dass deine CPU das in nur 15 Minuten kodiert hat und die Dateigrößé auch viel kleiner ist würde ich jedoch einer geringeren Bitrate bei der Kodierung zuschreiben. Auch kann es sein, dass du bei einem vielleicht nur 1-Pass Kodierung gemacht hast und beim anderen 2-Pass was auch Auswirkungen auf die Qualität hat.

    Die Arbeitsdurchgangseinstellungen waren in beiden Fällen 100% identisch, ich habe nur die genutzten Kompressionsroutinen sind verändert.


    Als ich mich vor ein paar Jahren mal mit Videokompression beschäftigt habe (andere Software, bin mir nicht mehr sicher 'Welche) war dieser Umstand das GPU deutlich schneller aber signifikant größere Files erzeugt ebenfalls vorhanden. 🤨


    Wenn man da bei Google sucht, stößt man immer wieder auf das "Phänomen".

    Logisch sind die Routinen bzw. die Ansätze dort (mit GPU) anders, aber trotzdem irritiert mich das bei der Ausführung, letztendlich sollten die Ergebnisse mMn schließlich deutlich näher beisammen sein.


    Leider gibt es für den optischen Eindruck des Ergebnisses ebenfalls keine Bestimmung eines ultimativen/besseren Ergebnis.

    Wie oben schon mit dem Abgasstrahl gezeigt war die Darstellung (abgesehen von dieser Szene) über jeden Zweifel erhaben und diverse Vergleichsframes brachten da keinen relevanten Unterschied zu Tage. 🤨

  • Ne das war allgemeiner von mir gedacht, du kannst HW, also CPUs direkt auf spezifische SW hin optimieren oder anders gesagt eine CPU entwickeln die genau immer diese SW gut berechnet sprich RISC-HW, ein bekannteres Praxisnahes Beispiel sind reine Cryptomaschinen wie so was:


    Da ist keine generische CPU oder GPU drin sondern ein RISC-Prozessor der besonders effizient(=bei geringerem Stromverbrauch) Cryptos mined, dafür kostet ein so ein Teil aber auch massig(=vierstelliger Betrag) und es dauert bis der sich refinanziert hat. Was anderes kann der so gut wie gar nicht. Und jeder Zusatz was der könnte würde das Teil vergrößern, verteuern, mehr Strom verbrauchen, dann nehmen wir doch gleich CISC und landen bei ARM, x86 usw CPUs.

    Was Videocodecs betrifft, gibt es da ja diverse und die werden häufiger auch mit in der "allgemeineren" HW integriert. Das liegt daran was machen Leute oft mit Videos auf CPUs und GPUs? Sie schauen Sie. Und damit diese(=CPUs+GPUs) das können wird der Codec primär zum encoden hinzugefügt.

    Intel hatte für das Videorendern(!Nicht ans x.??? decoden denken!) lange einen Vorteil, alle CPUs hatten ja immer die integrierte GPU und konnte dank Quicksync besser(=effizienter) Videos rendern als der CPU-Teil und damit AMD und Co. Erst mit der starken IPC-Steigerung und der Anzahl der Cores in Zen 3, ist ein Threadripper wesentlich schneller(= 200%+) als ne kack i3-CPU mit Quicksync. Das ist recht speziell wer rendert täglich Videos vom Raw Format unter Adobe-SW und co.?


    Zum MX Player keine Ahnung, aber im VLC konntest du imo schon immer den Videorenderer von SW(=CPU Brute Force) auf HW(= Codec in HW gebacken) unterstützt ändern. Und das unabhängig vom OS.

    Aber das ist ja das coole RL Beispiel und warum ich fragte was du beim x.265 meintes mit besserer CPU. Modernere ARM Prozessoren haben Unterstützung für den x.265 Codec und können einwandfrei Videos damit wiedergeben Intel/AMD CPUs haben denn nicht und machen das entweder per Brute Force oder benutzen die modernere GPU(HW encoding), die die Codec Unterstützung hat(außer die RX 6400 der Rohrkrepierer, das ist ja einer der Kritikpunkte). Älteren CPU fehlte die Puste zum dauerhaften Brute Forcen, und/oder die Kernanzahl um nebenher noch anderes zu tun.