latiose88 schrieb:
Hm es gibt auch welche die wollen die Video ernsthaft archivieren. Da ist es eher schlecht wenn jedes Video 25% größer ist. Mag ja sein das GPU auch umwandeln kann aber wenn es um eine Größe der Videos geht ,kann die GPU nicht mithalten.
Das ist irgendwie quatsch. Wenn es um ernsthafte "Archivierung" geht, dann rückt eigentlich normalerweise die File Size eher in den Hintergrund und die best mögliche Qualität im Verhältnis zum Aufwand des Encodings ist relevant.
Simples Beispiel. Was habe ich von CPU encodierten h.264 Files, die deutlich größer und aller bestenfalls qualitativ ähnlich sind wie GPU encodierte AV1 Files? Richtig. Gar nix...
Man wählt den effizientesten Weg um die Videos umzuwandeln ohne dabei sichtbar Qualität zu verlieren. Ja es ist so, dass GPU Encoding durchaus mehr Filesize im Endresultat bedeutet. Aber wenn du h.264 nutzt, ist das ziemlich outdated heutzutage.
Was man mMn machen kann ist via jüngerer Intel GPU (weil eben schneller und trotzdem kleiner als h.264@CPU) die Daten in AV1 zu wandeln und zu "archivieren". Wenn es dann Probleme beim Abspielen der Inhalte auf alten Geräten gibt, nimmt man idealerweise eine GPU zum decodieren in Echtzeit um das Ergebnis in das gewünschte Zielformat zu wandeln. Aber eben nicht den Platz zu benötigen oder die CPU Ressourcen, sondern nur bei Bedarf während des ansehens. Ich für meinen Teil nutze bspw. Jellyfin als Mediabackend im lokalen Netz und lasse eine kleine Intel N355 CPU bzw. besser, ihren GPU Teil diesen Wandeljob in Echtzeit machen. Das Teil schafft mehrere 4k Streams parallel bei Bedarf. Für maximal mögliche Qualität während der Wiedergabe kann man die Qualitätsparameter auch entsprechend hoch setzen. Die Daten werden eh verworfen wenn der Stream endet. Vorteil = maximal ungebunden und keine Anforderungen auf Clientseite. Das hat mich bspw. davon weg gebracht, Videos in h.264 abzulegen, weil der TV nur diesen alten Codec verstanden hat. Denn ich kann damit neuere/effizientere Codes nutzen und diese Vorteil mitnehmen, während beim Ansehen trotzdem der TV nicht überfordert wird. Der kleine NUC mit der CPU braucht dafür keine 10W im Betrieb. Was ein mMn sehr fairer Compromiss ist anstatt die Videos in Stundenlanger CPU Volllast-Orgie mit hunderten Watt Verbrauch in alten Formaten abzulegen.
Mal ne kleine Beispielrechnung. Bei 40 Cent die kWh (inkl. Grundgebühren!) würden ~333W PC Gesamtverbrauch während des CPU Encodings bedeuten, dass nach ungefähr 328 Tagen zu 8h pro Tag "Encoding" ca. 350€ verblasen wurden. Für 350€ bekommst du ne 12TB Disk.
Bei 10W Verbrauch im Beispiel oben - wären das in der selben Zeit 10,50€. Bei derart drastischer Differenz stellt sich klar die Frage, ob es sinniger ist, nicht einfach ne Disks mehr in den Pool zu setzen und den Verbrauch zu senken anstatt auf biegen und brechen irgendwie ein paar GB zu sparen?
latiose88 schrieb:
Aber bei h264 sehe ich schwarz das bei GPU noch was kommen wird. Es wird ja mehr h265 und co gepuscht. Naja du hast eben eine andere Anwendungsfall.
h.264 ist in dem Zusammenhang eigentlich quatsch, weil es große Files bei im Zweifel sogar schlechterer Qualität liefert. Es ergibt aus der Archiv-Sicht überhaupt keinen Sinn das Zeug in der Form abzulegen. Sondern eher einen effizienten Codec wählen und dann schauen, wie man die Massen von Videos halbwegs vertretbar in der Zeit überführt bekommt.
Btw. kostet jedes Umwandeln weiter Qualität. Wenn du also heute in das Format, morgen in das und übermorgen in ein drittes Format wandelst, verlierst du jedesmal Qualität. Irgendwann ist das sichtbar. Daher (siehe oben) wählt man als Speicherformat eine möglichst maximale Qualität. Die verlorenen Qualitätsmerkmale wird Niemand in Zukunft zurück holen können. Es sei denn, du hast die Original Quelle nochmal irgendwo liefen. BR/DVD im Schrank oder die Sendung kommt nochmal im TV und kann neu bezogen werden. Aber auch dabei wandeln sich die Codes über die Zeit im Zweifel.
MegatroneN schrieb:
Gibt es eigentlich Spiele die von sehr vielen Kernen profitieren? Falls ja, hat wer vielleicht einen 9950x3d, das in einem Spiel alle Kerne nutzt? Würde mich mal interessieren, ob doppelter 3d Cache trotz Latenz in Spielen einen Vorteil bringt.
Das wird man nicht pauschal sagen können. Faktisch ist der Zusammenhang aber eigentlich ganz einfach. Der Cache bringt dort was, wo Latenzkritische Tasks laufen und die CPU sich den Umweg über die langsame IF spart.
Games mit mehr als 8C/16T "Leistungsbedarf" setzen auf einem Dual MCM Konstrukt wieder andere Anforderungspunkte. Der Task, der für die FPS zuständig ist, wird in aller Regel nicht auf beiden Compute Dies laufen. Mehr FPS als vorher kann es also nur dann geben, wenn bisher dieser Job durch andere parallel auf dem selben Core ausgeführte Aufgaben gebremst wurde, die es mit einem Dual Cache MCM Konstrukt jetzt nicht mehr gibt. Damit kann dieser Frame-Erzeugungs-Job "frei" alle Ressourcen der/des Kerns nutzen, wo er drauf läuft. Ist damit dann also maximal schnell.
Aber ob das so häufig der Fall ist? Ich habe da starke Zweifel. Vor allem was den real praktischen Nutzen angeht. Also abseits 720p LowRes Labormessungen des Durchsatzes. Real praktisch sind die aller wenigsten Games in der Lage, mit der CPU Power in der Breite zu skalieren, weil bisher ein Punkt irgendwann erreicht ist, indem alle Aufgaben maximal schnell ausgeführt werden. (abseits Taktraten und IPC Verbesserungen)
Wenn ich eine Tasse Kaffee haben will, macht es keinen Sinn, zwei Kaffeemaschinen zu betreiben. Bildlich gesehen. Die eine Tasse Kaffee kommt nicht schneller raus als mit einer Maschine. Schneller wird es, wenn ich zwei Tassen brauch. - Das ist aber nicht so, wie Spiele funktionieren (heute). NPCs werden nicht schlauer oder Logik im Spiel nicht besser mit mehr CPU Leistung. Es bleibt also beim Bedarf der gleichen Anzahl an Kaffeetassen, egal wie viel Dies da Huckepack Cache bekommen.
. Schließlich ist es AMD, die es sich erlauben, so zu sein wie Intel es schon immer ist. Da ist eine hohe Leerlaufleistungsaufnahme der GPU zwingend nötig.
