• Hallo Gast, du kaufst gerne günstig ein und erfährst oft vor deinen Freunden von interessanten Angeboten? Dann kannst du dein Talent als Schnäppchenjäger jetzt zu Geld machen und anderen PCGH-Lesern beim Sparen helfen! Schau einfach mal rein - beim Test der Community Deals!

gesucht sind alle leute mit 16 oder gar 18 kerner mit ht

D

DBGTKING

Guest
Hi,warum ich das so geschrieben habe,ist klar.Nachdem mir die test leider nicht aussagekräftig genug sind weil ich nun mal nicht die settings fahre wie pcgh.Und weil ich nicht mal schnell ein system mit so vielen Kernen ausleihen kann um festzustellen wie viel wirklich ich an leistung erreicht hätte.Dachte ich mir ich frage einfach die entusiasten die wirklich so viele kernen hebn.ALso sprich einen i9 7960 oder gar 7980xs.
Um es besser mit meinem vergleichen zu können,lade ich die Aufnahmen dann wenn sich die richtigen Personen gemeldet haben und auch bereit sind mir zu helfen.Auch die settings damit es auch die selben sind,mit denen auch ich umwandle.Am ende sieht ihr bestimmt die Zeit,wie lange diese CPus gebraucht haben.Das hilft mir dann auch für die Zukunft weiter.Diese settings will ich auch in Zukunft bebehalten und weis dann ob es in zukunft sinnvoll ist auzurüsten oder es so wie es ist,bis zum nimmerleinstag zu lassen.Danke schon mal für eure antworten.
 

na DIE Glaskugel !

Software-Overclocker(in)
Also ich lehne mich mal ganz weit aus dem Fenster.... Ohne Die Programme zu nennen wovon du dir Ergebnisse erhofft bzw. sogar ohne zu Wissen wie gut Mehrkern optimiert die Anwendung ist geschweige denn skaliert wird dir kaum einer Helfen können.
Und des weiteren würde ich an deiner Statt den Threadripper mit den 32 Kernen ins Auge nehmen Es dürfte bei Entsprechendem Workload dein 16 oder 18 Kerner kaum in Reichweite bleiben.
 

DaHell63

Volt-Modder(in)
Ganz so einfach ist es nicht. Man kann die Anzahl der Kerne nicht 1:1 hochrechnen und damit die Leistung bestimmen.
Der TE verwendet -wenn ich mich nicht täusche- Handbrake (x264). Meinen Beobachtung zu Folge kann Handbrake zwar viele Cores nutzen, aber ab 16 Kerne nimmt der Ertrag rapide ab.

Ryzen 2600X 3.6-4.2GHz
encoded 250 frames, 31.41 fps, 29802.83 kb/s
R7-1700x@4.1Ghz - DDR4-3400 CL14-14-14-28 Win10x64
encoded 250 frames, 42.21 fps, 29799.51 kb/s
Wie man sieht steigt hier die Leistung noch linear mit den Kernen.

Was aber wenn man die Kernzahl verdoppelt? Doppelte Leistung?
Ryzen Threadripper 1950X@4GHz, 4x8GB@3200Mhz
encoded 250 frames, 62.75 fps, 29798.07 kb/s
Der Ertrag sinkt trotz doppelter Kernzahl auf unter 50%.

32C/64T, bei einem Prozessor der noch dazu niedriger getaktet ist als der Threadripper, da wird bei weitem nicht das rumkommen was Du Dir da vorstellst.
Solch ein Prozessor ist für andere Workloads bestimmt. Encoding via Handbrake gehört da sicher weniger dazu.
 

Incredible Alk

Moderator
Teammitglied
Es kommt extrem darauf an wie du solche CPUs benutzt. Ich greife mal das beispielo von DaHell auf.

Wie er richtig schreibt wird die Kernskalierung bei AVC/HEVC-Encoding mit steigender Kernzahl immer schlechter (amdahlsches Gesetz), so dass der Sprung von 4 auf 8 Kerne noch viel Mehrleistung bringt, der Sprung von 8 auf 16 Kerne aber nur noch wenig und von 16 auf 32 Kerne wirds kaum noch schneller (diese Steigerungen hängen übrigens auch von Material und Einstellungen ab - ein 4K-Video in harten HEVC10-Settings encoden skaliert viel besser als ein 720p-Video in YouTube-Formatpixelbrei umrechnen...).

Dennoch kann man hier auch einen 32-Kern Threadripper2 voll auslasten und nahezu perfekt die Mehrleistung ausnutzen - wie ist einfach:
Da Der Encoder nur gut skaliert bis sagen wir mal 8 Kerne, du aber 32 Kerne hast startest du 4 Instanzen von Handbrake gleichzeitig, weist ihnen explizit die kerne zu und codierst 4 Clips gleichzeitig. Zack, 100% Auslastung und (fast) 4x so schnell wie ein 8-Kern Ryzen. So kann man beinahe beliebig viele Kerne/Threads gut ausnutzen (irgendwann limitiert die Speicherbandbreite) und das ist auch der Anwendungsfall solcher CPUs. Wer den passenden Workload hat und weiß wie er solche Hardware nutzt kann entgegen aller Unkenrufe im Netz ("ööhh dafür gibts gar keine Software!!!11eins") auch 128 kerne voll auslasten.
 

DaHell63

Volt-Modder(in)
Stimmt, encoding über mehrere Instanzen lasten den Prozzi natürlich besser aus. Aber woher soll ich das ganze Material nehmen um die 32 Kerne immer auf Trap zu halten?:D

Wenn die CPU besser genutzt wird (x265) kann der Threadripper gegenüber dem 1700X seinen Vorsprung von unter 50% (x264) auf über 77% ausbauen.
Der richtige Workload ist, wie Incredible Alk schon gesagt hat, enorm wichtig damit sich so eine große CPU lohnt.
 
Zuletzt bearbeitet:

DaHell63

Volt-Modder(in)
Ist die Qually inzwischen besser geworden, wenn man mit der GPU ancodiert? Außer den größeren Datein hatte man ja auch noch verminderte Qualität zur Cpu.
 
TE
D

DBGTKING

Guest
Ich benutze kein handbrake. Benutze hybrid, xmedia recode und advidmux.

Nur eines dieser programme kann mehrer aufnahmen gleichzeitig umwandeln. Auch das immer mehr erhöhehen bringt ja nix. Auf 2-3 aufnahmen gleichzeitig komme ich auch auf 100 % auch ohne ein hd video zu haben weil es niedriger ist. Steigerte ich es auf 6-8 gleichzritig kamen fehlerhafte umwandlungen raus. Ich habe auch keine lust immer noch mehr programme gleichzeitig laufen zu lassen. Wollte nur wissen ob man linear zu den steigenden kernen auch die anzahl der umwandlungen erhöhen kann.

Und ich merke schon, das es mir einer für mich ausprobieren kann, das wird nix, schade. Bekomme aber bald die chance bei einem zumindest treadripper auszuprobieren. Hat zwsr nur 16 kerne, kann es aber aufgrund von meinen zum threadripper und dann mehr gut hochrechnen.
 

JackTheHero

Software-Overclocker(in)
Ach ja, Encoden über GPU. Das mache ich nur noch so und dann über NVENC x265. Die Dateien sind deutlich kleiner (ca. die Hälfte vom BR Original) und Qualität für mich nahezu identisch. Die Zeiten sind vorbei wo man deutliche Qualitätsunterschiede sah. Es ist einach nicht das gleiche wie man mit mit der GPU streamen will bei Twitch, wie ich auch mal versucht hab. Das Bild ist dann totaler Müll, aber das hat dann andere Gründe. Beim Encodieren gibt es für den Normalo keinen ernsten Grund mehr das bewusst über CPU zu machen..

Den of Thieves:

10 Mbit constant Bitrate h265 mit xmedia Recode.

14-07-_2018_11-43-13.png
 
TE
D

DBGTKING

Guest
Ich werde mal meine einstellungen posten. Steht ja alles wunderbar in der umgewandelten aufnahme drinnen. Nur nicht das ich deinterlacing linienblendong gemacht hatte. Das kostet leider auch etwas zeit. Aber wenn man halt 50 halbbilder hat, dann geht das halt nicht anders, wenn man zumindest halbwegs gute optik haben will.Ich hoffe ihr könnt mit alldem was anfangen.





Format : MPEG-4
Format-Profil : JVT
Codec-ID : avc1 (isom/avc1)
Dateigröße : 189 MiB
Dauer : 21 min 11s
Modus der Gesamtbitrate : variabel
Gesamte Bitrate : 1 246 kb/s
Kodierungs-Datum : UTC 2018-07-07 21:25:47
Tagging-Datum : UTC 2018-07-07 21:25:47
Kodierendes Programm : Hybrid 2018.06.23.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format-Profil : Main@L3
Format-Einstellungen : CABAC / 4 Ref Frames
Format-Einstellungen für CABAC : Ja
Format-Einstellungen für RefFrames : 4 frames
Codec-ID : avc1
Codec-ID/Info : Advanced Video Coding
Dauer : 21 min 11s
Source_Duration/String : 21 min 11s
Bitrate : 996 kb/s
maximale Bitrate : 6 222 kb/s
Breite : 720 Pixel
Höhe : 576 Pixel
Bildseitenverhältnis : 4:3
Modus der Bildwiederholungsrate : konstant
Bildwiederholungsrate : 25,000 FPS
Standard : PAL
ColorSpace : YUV
ChromaSubsampling/String : 4:2:0
BitDepth/String : 8 bits
Scantyp : progressiv
Bits/(Pixel*Frame) : 0.096
Stream-Größe : 151 MiB (80%)
Source_StreamSize/String : 159 MiB (84%)
verwendete Encoder-Bibliothek : x264 core 155 r2901 7d0ff22
Kodierungseinstellungen : cabac=1 / ref=4 / deblock=1:0:0 / analyse=0x1:0x131 / me=hex / subme=7 / psy=1 / psy_rd=0.60:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=4 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=5 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=10 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=2:1.00
Kodierungs-Datum : UTC 2018-07-07 21:25:47
Tagging-Datum : UTC 2018-07-07 21:25:50
colour_range : Limited
matrix_coefficients : BT.709

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format-Profil : LC
Codec-ID : mp4a-40-2
Dauer : 21 min 11s
Bitraten-Modus : variabel
Bitrate : 192 kb/s
maximale Bitrate : 224 kb/s
Kanäle : 2 Kanäle
Kanal-Positionen : Front: L R
Samplingrate : 48,0 kHz
Bildwiederholungsrate : 46,875 FPS (1024 SPF)
Stream-Größe : 29,2 MiB (15%)
Titel : AAC#audio:lang=de@GPAC0.7.2-DEV-rev563-g3096514bb-ab-suite
Sprache : Deutsch
Kodierungs-Datum : UTC 2018-07-07 21:25:49
Tagging-Datum : UTC 2018-07-07 21:25:50




Als ich constant bitrate von im moment 18 auf 16 erhöht hatte,war die Aufnahme genausogroß gewesen und hatte auch die selbe qualität gehabt.Aber auf 20 merkte man sehr gut die geminderte Qulität.Das sind alles 720x576 mpeg 2 Ts aufnamen.Alle so 21 minuten lang.Die Beframes zu veringern kostete anscheinend geschwindigkeit.Und die reframes auf 3 zu reduzieren brachte auch nix weil das Programm hybrid bei der einstellung dennoch mit 4 Reframes gerechnet hatte.Irgendwie hat es meine einstellungen untergraben.Weil oben 3 reframes und unten 4 reframes stand.Das ist unsportlich meine settings einfach zu korrigieren.Dachte immer ich würde damit zeit einsparen und dennoch die Perfekte optik draus zu ziehen.

Auch hat es die suche von Umheginal zu hex umgeändert.Das war so nicht geplant.
In wirklichkeit stelle ich mir das ja so vor


cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x1:0x131 / me=umh / subme=7 / psy=1 / psy_rd=0.60:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=4 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=5 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=10 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=2:1.00
 
Zuletzt bearbeitet:

gaussmath

Lötkolbengott/-göttin
Wenn ich Desktop Videos mache, Programmier-Tutorials für Youtube beispielsweise, konvertiere ich gar nicht mehr. Einfach OBS anschmeißen und den Hardware (NVENC) Kodierer + Ununterscheidbare Qualität verwenden, gut ist.
 
TE
D

DBGTKING

Guest
dieser tipp ist zwar gut,bringt mir leider nix,weil ich die videos nicht selber erstelle.Ich nehme die nur vom Tv auf.Somit werden videos erzeugt.Ich habe also nicht s viele optionen.Ich kann es nartürlich auch so lassen,aber wenn ich das mit dem Bluray player wiedergebe,dann sind da soviele artefakten usw,das kann man sich kaum antuen.Somit tue ich das damit entgegen wirken.
 

gaussmath

Lötkolbengott/-göttin
Das dachte ich mir schon. Mir ging es halt darum, mal aufzuzeigen, dass die ganze Konvertiererei manchmal gar nicht notwendig ist...
 
TE
D

DBGTKING

Guest
achso,ja bei deinem einsatzzweck ist es auch ein anderer fall.Da habe ich schon gewusst.Aber hilft aber nix.Letzendlich habe ich ja nicht das was ich mir vorgestellt hatte für ne aktion ,nichts gebracht.Dann kann ich halt den treadripper x1920x ja mal selber testen.Mal sehen wie viel in meinem einsatz wirklich raus reist.Höhere settings werde ich allerdings nicht mehr machen.Ich will es so wie es ist,auch dort testen.Der wechel von i7 3770k zu i7 6950x gab darum ne ordentliche leistungssteigerung weil ich zuvor ja die settings angehoben hatte.Aber es gleich zu lassen,ändert wohl schon was beim verhältnis.
 

Incredible Alk

Moderator
Teammitglied
Und dann kommt irgendeiner mit einer 1080 Ti und enkodiert 10x so schnell. ;)

Ja - und nutzt 5% der Fähigkeiten des HEVC-Encoders was in deutlich schlechterer Bildqualität oder wahlweise viel größerer Zeildatei resultiert.

Wenn ich auf einem Threadripper oder vergleichbarem die Settings so runterdrehe dass das Ergebnis vergleichbar zum CUDA-Encoder ist ist die CPU auch nicht mehr langsamer (eher schneller). Alleine schon, dass der NVENC beim HEVC-Encoding maximal Treeblocksizes von 32x32 kann ist ein Witz. Gerade die Unterstützung von 64x64er Blocks macht den HEVC effizient (im Gegensatz zum AVC mit 16x16) und genau dieses Hauptfeature kann eine GPU nicht umsetzen. Oder genauer: Die GPU kanns schon, NVidia wills nur nicht unterstützen... denn wenn die GPU das berechnen würde wäre sie nicht mehr nennenswert schneller als eine flotte CPU und dann ist der schöne Werbeeffekt ja weg... ;)


GPU-Encoding ist sinnvoll für Letsplays und vergleichbares wos nicht auf besonders hohe Qualität oder kleine Dateien ankommt da es eh auf YT hochgeladen wird (und von denen nochmal konvertiert und...). Aber wenns gut werden soll würde ich niemals auf einer GPU Videokompression betreiben.
 

gaussmath

Lötkolbengott/-göttin
@Incredible Alk: Wenn ich deinen Beitrag so lese, stelle ich fest, dass ich mich mal ein wenig mit der Theorie der Videokonvertierung beschäftigen sollte. Es ist halt wirklich so, dass ich keinen Unterschied zwischen GPU und CPU feststellen kann hinsichtlich der Qualität. Wenn jetzt allerdings beides letztlich gleichwertig sein soll, dann muss bei höherer Geschwindigkeit was anderes leiden, wenn die Qualität nahezu gleich ist. Ist es die/der Dateigröße/Komprimierungsgrad? Und du definierst Effizienz aber schon als Qualität/Dateigröße?
 
TE
D

DBGTKING

Guest
vermutlich wird bei gpu konvertieren auch der visuelle effekt ,also die tiefe reduziert.Weshalb details verloren gehen.Wenn du das auch bei cpu runter stellst,klar siehtst du dann keinen unterschied mehr.Wenn man bei cpu crf 20 oder so einstellt ,dann schwindet der unterschied immer mehr zwischen cpu und gpu.Da ich aber 18 einstelle,merkte ich sehr wohl einen unterschied.Besonders bei standbildern sieht man es am besten.Die artefakten nehmen zu.
Ist ja nicht so das ich gpu nicht auch ausprobiert hätte.Ist für einige bestimmte einätze durchaus sinnvoll.Das streitet also niemand ab.Zum Umgewandelte sachen archivieren,will man aber dann doch echte Qualität.Weil wer schaut sich das nach so vielen jahren nicht mal wieder an.Ich schaue gewisse sachen öfter an.Besonders bei animes wo eh nicht über so viele details verfügen,diese dann noch schwächen duch gpu.Es sieht auch schon so schon etwas verwaschen aus und mit der Gpu wird es so unerträglich.Es sieht so aus als ob meine Brille total verdreckt wäre,ich noch verschlafen wäre oder sonst was.Und das dann permanent.Nach einigen minuten tuen mir dann die augen weh,so sehr das ich aufhören muss.

Gpu ist somit nichts für mich.Mag vielleicht bei sehr hochwertige sachen wo man sagt,ok ist eh schon so gut.Selbst wenn man bischen was verliert stört das nicht aber zwischen schlecht und sehr schlecht ist schon gravierend.Und stelle ich das wieder höher um das abzufedern,dann habe ich meinen vorteil bei der GPU wieder dahin und kann es genauso auch gleich bei der cpu bleiben.
Ohne brille sehe ich warlich keinen unterschied,weil ich halb blind bin,aber mit brille sieht die sache schon anders aus.
 

JackTheHero

Software-Overclocker(in)
CPU ist sicher ohne Frage schon etwas besser, aber ist der Unterschied wirklich so relevant, dass man sich den Unterschied im Zeit- und Energieaufwand geben will? Für mich hört sich das hier an, als ob einem die Artefakte ins Gesicht springen. Ich sehe da so gut wie gar keinen Unterschied mehr, wenn ich Encode mit GPU.
 
TE
G

Gimmick

Guest
Ganz ehrlich? Ich erkenne da keinen Unterschied. Einige behaupten, dass es Unterschiede gäbe, die aber sehr gering sein sollen.

Die Unterschiede steigen mit abnehmender Bitrate bzw. zunehmender QUalitätseinstellung beim CPU-Encoding. Das sieht man dann sehr deutlich.
 

Incredible Alk

Moderator
Teammitglied
Wenn jetzt allerdings beides letztlich gleichwertig sein soll, dann muss bei höherer Geschwindigkeit was anderes leiden, wenn die Qualität nahezu gleich ist.
Korrekt.

Ist es die/der Dateigröße/Komprimierungsgrad? Und du definierst Effizienz aber schon als Qualität/Dateigröße?
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 :-D).
Wenn ich dagegen die billigen Einstellungen auch auf der CPU wähle ist meine TitanX nicht mehr nennenswert schneller als der 5960X.

Die Unterschiede steigen mit abnehmender Bitrate bzw. zunehmender QUalitätseinstellung beim CPU-Encoding. Das sieht man dann sehr deutlich.
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.

CPU ist sicher ohne Frage schon etwas besser, aber ist der Unterschied wirklich so relevant, dass man sich den Unterschied im Zeit- und Energieaufwand geben will?

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
D

DBGTKING

Guest
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.

Willst du dagegen dein Hochzeitsvideo für die Nachwelt sichern würde ich den Teufel tun und die CPU da ranlassen
 

Incredible Alk

Moderator
Teammitglied
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.
 
Zuletzt bearbeitet:

JackTheHero

Software-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
D

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.
 

DaHell63

Volt-Modder(in)
Aber hilft aber nix.Letzendlich habe ich ja nicht das was ich mir vorgestellt hatte für ne aktion ,nichts gebracht.Dann kann ich halt den treadripper x1920x ja mal selber testen.Mal sehen wie viel in meinem einsatz wirklich raus reist.Höhere settings werde ich allerdings nicht mehr machen.Ich will es so wie es ist,auch dort testen.Der wechel von i7 3770k zu i7 6950x gab darum ne ordentliche leistungssteigerung weil ich zuvor ja die settings angehoben hatte.Aber es gleich zu lassen,ändert wohl schon was beim verhältnis.
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.
 

Incredible Alk

Moderator
Teammitglied
Ich dachte die programme funktieren bei h264 alle gleich. Aber da scheine ich mich geirrt zu haben. Hmm.

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:
frame-threads=4 / numa-pools=16 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x1080 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=24 / keyint=240 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=5 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-reuse-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=18.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-mv-type=0 / copy-pic=1

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.
 
TE
D

DBGTKING

Guest
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.

Ä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.
 

gaussmath

Lötkolbengott/-göttin
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:

Screenshot_4.png

Die Auslastung ist jetzt nicht berauschend, aber geht eigentlich.
 
Zuletzt bearbeitet:
TE
D

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.
 

Incredible Alk

Moderator
Teammitglied
Oh wie sieht denn die neueste version von xmedia recode aus, das ist ja schrecklich.

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:

gaussmath

Lötkolbengott/-göttin
Ja bitte.
i5-5200U: Runtime in seconds: 72.212706089

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.
 

larslrs

Komplett-PC-Aufrüster(in)
[/CODE]
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
 

Anhänge

  • SC_bench_memPy3x.py.zip
    647 Bytes · Aufrufe: 51

gaussmath

Lötkolbengott/-göttin
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.45331597328186
 
Oben Unten