G
gaussmath
Guest
Das mag sein. Ich habe so große Qualitätsunterschiede noch nicht getestet.
@JackTheHero: Hast du das schon getestet?
Das mag sein. Ich habe so große Qualitätsunterschiede noch nicht getestet.
@JackTheHero: Hast du das schon getestet?
Korrekt.
Moderne Videocodecs arbeiten mit einem "Qualitätsrating" um die nötige Bitrate zu bestimmen. Früher hat man eine konstante Bitrate eingestellt - das Ergebnis war größenmäßig vorhersehbar aber die Videos waren schlecht komprimiert - ruhige Szenen waren hübsch, bewegte Szenen hässlich. Danach kam averagebitrate und 2pass - im ersten Schritt schaun für welche Szenen man viel Bitrate braucht und wo weniger und dann entsprechend komprimieren. Besser aber noch immer nicht optimal.
Heite nutzen Codecs den CRF (ConstantRateFactor) und bestimmen während des Komprimiervorgangs durch geschickte Algorithmen, wie viel Bitrate nötig ist, um ein gewünschtes Bildqualitätslevel zu halten. Du sagst beispielsweise dem Encoder "CRF=20" und er wird die Bitrate in jeder Sekunde so wählen dass das Ergebnis sehr ansehnlich ist. Sagst du "CRF=25" wirds weniger hübsch, dafür die Datei kleiner. Blöderweise weiß man hier im Vorraus nicht mehr wie groß die Zieldatei wird - ein Actionfilm wird bei CRF 20 viel größer werden als eine Dokumentation mit CRF 20.
Nun kommt die Effektivität ins Spiel. Ein heutiger Encoder hat Hunderte von Funktionen und mathematischen Tricks, um die Bildqualität möglichst effizient in eine Datei zu packen (hier gibts ne Liste der Einstellungen: Command Line Options — x265 documentation). Je mehr man davon verwendet und je stärker man die einstellt desto rechenaufwendiger wird der komprimiervorgang und desto effektiver wird die Komprimierung. Wenn ich den CRF bei 20 lasse und sehr aufwendige Einstellungen wähle wird die Datei entsprechend deutlich kleiner als wenn ich sehr lasche Einstellungen wähle - das Ergebnis ist qualitativ dasselbe (CRF ist ja immer 20), nur ist einmal die Datei viel kleiner und die benötigte Rechenzeit viel höher. Die Codecs lassen dir also die Wahl ob du schnell sein willst oder ob du effizient sein willst im Komprimierungsgrad ohne dass die Qualität beeinflusst wird.
Und genau hier setzen die GPU-Encoder an. Die leute haben in der Mehrzahl absolut keine Ahnung von dem was ich da grade erklärt habe und sehen nur die fps-Anzeige. Also stellt man beim GPU-Encoding die Einstellungen sehr sehr simpel ein. Bedeutet die Zieldatei wird sehr groß aber man kann extrem schnell komprimieren - und letzteres ist eben entsprechend werbewirksam.
Es hat auch technische Gründe warum man das so machen muss - denn GPUs sind im gegensatz zu CPUs nicht dazu geeignet, sehr komplexe Rechenoperationen durchzuführen. GPUs können nur vergleichsweise einfache Dinge tun, diese aber extrem parallelisiert und schnell mit ihren tausenden von Shadereinheiten. Deswegen wäre es sehr ineffektiv, die mathematisch "hochwertigen" Funktionen eines modernen Encoders auf einer GPU auszuführen, sie würde wegen der Komplexität der Berechnungen sehr, sehr langsam werden. CPUs sind für sowas gebaut, die haben mit Komplexität kein Problem, sind aber weniger effizient wenns sehr simpel wird (deswegen ist eine GPU bei "billigen" Einstellungen schneller als eine CPU).
Deswegen ists so, dass man ein Video das eine GPU komprimiert hat mit guten Einstellungen auf deiner CPU in aller Regel problemlos auf die Hälfte bis ein Drittel der Dateigröße runterbrechen kann ohne sichtbaren Qualitätsverlust (also mit gleichem CRF), nur ist das viel langsamer (ich hatte das für einen User hier mal mit einem seiner Minecraft-Clips gemacht der das nicht glauben wollte - seine Datei von ein paar Hundert MB aus Shadowplay hatte danach noch iirc ~60 MB und sah gleich aus
).Wenn ich dagegen die billigen Einstellungen auch auf der CPU wähle ist meine TitanX nicht mehr nennenswert schneller als der 5960X.
Richtig. Der oben beschriebene Effekt wird umso deutlicher, je geringer die akzeptable Bitrate eingestellt ist. Denn wenn die Kodiereffizienz nicht gut ist (wie bei GPUs) ist das weniger schlimm wenn ich eben die Bitrate hochballern kann. Darf der Encoder das nicht wirds hässlich. Da die GPU keine Möglichkeit hat, mehr Informationen pro Byte abzulegen wie die CPU es mit überlegenen Algorithmen kann wird das Ergebnis sehr unschön - in aller Regel sieht man das schnell durch "blocking"/Artefakte.
Kommt auf die Zielsetzung an. Wie gesagt wenns drum geht Videos für YT zu machen ist GPU-Encoding super. Es ist schnell und die Bitrate/Dateigröße ist eh wurscht weils YouTube speichern muss und nicht du. Willst du dagegen dein Hochzeitsvideo für die Nachwelt sichern würde ich den Teufel tun und die GPU da ranlassen. Da wäre ein HEVC10 + slow preset / CRF18 ein vernünftiger Anfang.
Zuletzt bearbeitet:
TE
TE
DBGTKING
Guest
Willst du dagegen dein Hochzeitsvideo für die Nachwelt sichern würde ich den Teufel tun und die CPU da ranlassen
Der Satz stimmt schon so wie er da steht. "Den Teufel tun" bedeutet "garantiert nicht [so] machen". Ich würde es garantiert nicht mit der GPU machen.
Persönlich würde ich nebenbei gar nicht auf einer GPU konvertieren. Selbst Pixelbrei für YouTube nicht. Wenns schnell gehen muss gibts eben HEVC preset veryfast - selbst das nutzt schon 64er CTUs und ist einer GPU weit überlegen - und nicht viel langsamer auf ner sehr flotten CPU.
Persönlich würde ich nebenbei gar nicht auf einer GPU konvertieren. Selbst Pixelbrei für YouTube nicht. Wenns schnell gehen muss gibts eben HEVC preset veryfast - selbst das nutzt schon 64er CTUs und ist einer GPU weit überlegen - und nicht viel langsamer auf ner sehr flotten CPU.
Zuletzt bearbeitet:
JackTheHero
BIOS-Overclocker(in)
Pixelbrei haste auf YT nur wenn du unter 4K hochlädst. Am besten jedes Video auf 8K hochskalieren, dan haste auch Bitrate und ordentliches Bild.
TE
TE
DBGTKING
Guest
Hi ich weis nun wo das problem liegt. Ich stelle ume ein das programm gibt hex aus. Ich stelle 3 ref ein, er gibt 4 ref aus. Das programm hybrid will mich anscheinend ärgern. Es macht was es will. Ich frage mich wozu es die stapel funktion hat wenn es dann 6-8 videos gleichzeitig, das es dann fehlerhafte sachen umwandeln. Die enwickler haben in den letzten monaten da was optimiert. Aber anscheinend in die falsche richtung. Sie sind auch nicht mehr das, was sie mal waren. Bin dann kurzerhand wieder zurück zu xmedia recode gegangen. Ich habe die zwei mal ausgeführt, siehe da auch 100 % auslastung. Bei hybrid brauche ich da schon 3 damit ich 100 % habe. Ich dachte die programme funktieren bei h264 alle gleich. Aber da scheine ich mich geirrt zu haben. Hmm.
XMedia Recode wird sicher der ein oder andere nutzen, aber wenn Du keinen Test Clip hochlädst und die dazu gehörigen Einstellungen postest, ist es einfach unmöglich Dir einen Vergleich zu deiner CPU zu bieten.
Es gibt tausende verschiedener DLL-Bibliotheken und Versionen zu h264 oder h265 Codecs und alle funktionieren sie anders. Die Programme die du nutzt (xmediarecode, Handbrake,...) sind nur GUIs und haben mit dem was im Hintergrund passiert gar nichts zu tun. Deine Programme sind nur hübsche grafische Oberflächen die es einem ungeübten Nutzer erlauben, die Kommandozeilenparameter für den eigentlichen Encoder mit Mausklicks zu erstellen.
xmediarecode oder handbrake und wie sie alle heißen haben üblicherweise den x264/x265 Standardencoder implementiert. Sobald du auf start klickst startet das Programm die x.264.exe mit den eingestellten Parametern - Beispiel:
h.265-Settings schrieb:
Viele dieser Einstellungen hast du wie du siehst händisch sicher nicht eingestellt. Die werden automatisch generiert - und das abhängig davon wie der Programmierer von Handbrake oder xMediaRecode es für am sinnvollsten erachtet hat. Das ändert sich entsprechend mit Programmversionen - deswegen sind die Ergebnisse nie gleich - es sei denn du setzt deine Kodierparameter wirklich alle manuell von Hand im CLI.
G
gaussmath
Guest
Ja, lade doch mal ein Beispiel hoch. Ich habe übrigens einen Threadripper mit 16 Kernen und könnte was testen für dich, wenn du willst.
TE
TE
DBGTKING
Guest
Ähm hör mal die dazu verwendeten settings habe ich sehr wohl schon gepostet, nur eines fehlt, die dateien die zum testen sind. Werde das aber gerne noch nachholen. Werde die settings jeweils von hybride und xmedia recode aber gerne noch seperart posten. Ich weis nicht wie lange 560 mb datein zum uploaden braumuchen werden. Werde aber erst am abend dazu kommen. Aber einstellungen von hybride sind schon gepostet.
G
gaussmath
Guest
Hat einer von euch die neuste Version von XMedia Recode installiert? Ich sag' nur Bugs des Todes, es geht gar nichts!
Ich konvertiere übrigens gerade ein Gameplay von Earthfall mit dem x265 Codec in AVC Professional:
Die Auslastung ist jetzt nicht berauschend, aber geht eigentlich.
Ich konvertiere übrigens gerade ein Gameplay von Earthfall mit dem x265 Codec in AVC Professional:
Die Auslastung ist jetzt nicht berauschend, aber geht eigentlich.
Zuletzt bearbeitet von einem Moderator:
TE
TE
DBGTKING
Guest
Oh wie sieht denn die neueste version von xmedia recode aus, das ist ja schrecklich. Das disn ja ein fail. Zum glück habe ich ich nicht die neueste version. Ich wusste es doch das die software immer schlechter wird. Egal ob optisch oder stabilität weil bei leistung ändert sich ja nix mehr.
Passt sich den Anforderungen der Masse an. Alle wollen nur idiotensicher und bunt. Das ist nunmal die Zielgruppe.
Wenn du ernsthaft professioneller mit Videokompression arbeitest benutzte sowieso die (ggf. kostenpflichtige) Version von x265 im Kommandozeilenfenster (und hast dadurch noch so manch anderen erwähnenswerten Vorteil wie beispielsweise AVX512-Unterstützung - deswegen sind die Reviews im Netz teilweise so unterschiedlich zwischen SkylakeX und Threadripper weil die tester selbst oft nicht wissen was sie da genau tun - wenn der Encoder AVX512-Unterstützung hat und die Settings entsprechend sind zerreißt ein SkylakeX jeden Threadripper in der Luft, selbst mit vielen Kernen weniger - ohne AVX hat der Threadripper wegen mehr Kernen bei vergleichbarer IPC dagegen meist den Vorteil).
Die mächtigste freie Variante ist die da: http://msystem.waw.pl/x265/x265-2.8+42-8bf51aa_vs2015-AVX2.7z
Zuletzt bearbeitet:
G
gaussmath
Guest
Code:
C:\Users\marcf\Downloads\SC_bench_mem.py>SC_bench_mem.py
Generate test data of size 16777216
Traceback (most recent call last):
File "C:\Users\marcf\Downloads\SC_bench_mem.py\SC_bench_mem.py", line 12, in <module>
testdata=array('c',[chr(random.randint(1,255)) for k in range(Testsize)])
ValueError: bad typecode (must be b, B, u, h, H, i, I, l, L, q, Q, f or d)Muss ich zwingend Cpython 2.7 verwenden? Ich habe 3.6 installiert.
Siehe Anbei
Testläufe mit Python2.7 kann man nicht mit Testläufen mit Python 3.x. vergleichen.
Ich frage mich, ob der Zufallszahlengenerator überall das Selbe liefert...
(Falls nicht, gibt es einen Fehler)
SC_bench_memPy3x.py, CPython >=3.5
larslrs i5-5200U (Linux): Runtime in seconds: 61.5
G
gaussmath
Guest
Das sieht nicht gut aus:
Code:
C:\Users\marcf\Downloads\SC_bench_memPy3x.py>SC_bench_memPy3x.py
Generate test data of size 16777216
Checking, if test data is correct
Running the test
Runtime in seconds: 112.45331597328186Machst Du noch irgend etwas anderes nebenbei? (Fast) alle Programme zu?
Ich hab an patches meltdown SpectreV1, und V2 schon drauf.
G
gaussmath
Guest
Das läuft doch nur auf einem Kern?!
Ja, aber:
Cache, Speicherinterface, Kontextwechsel, ...
Bei Deiner CPU habe ich auf die Größenordnung "nahe einstellig" gehofft.
Ähnliche Themen
- Frage
