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.
 
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.
 
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.
 
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.
 
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:
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.
 
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.
 
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
 
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:
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.
 
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.
 
Das dachte ich mir schon. Mir ging es halt darum, mal aufzuzeigen, dass die ganze Konvertiererei manchmal gar nicht notwendig ist...
 
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.
 
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.
 
@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?
 
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.
 
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.
 
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.
 
Zurück