Logo Logo
/// 

Encoding per GPU vs. CPU: nVidia Turing-Encoding auf x264-Medium-Preset Niveau?



Noch was unklar? Dann in unserem Forum nachfragen
Zum Original-Thread / Zum News-Kommentare-Forum

Newsmeldung von slashCAM:



Nachdem bei uns im Forum immer wieder die Diskussion aufkommt, wie gut die Encoding-Qualität von GPUs hat, kann vielleicht nVidia selber auch ein bisschen Information daz...

Hier geht es zur Newsmeldung auf den slashCAM Magazin-Seiten:
Encoding per GPU vs. CPU: nVidia Turing-Encoding auf x264-Medium-Preset Niveau?




Antwort von Alf_300:

Wer also beim Videoschnitt GPU-Encoder zum Export seiner Videos benutzt, spart vielleicht etwas Zeit, bekommt aber keinesfalls die bestmögliche Qualität für seine Datenrate.

Oder, außer Spesen nix gewesen.



Antwort von motiongroup:

Na ja Du wartest für 5 Minuten video dafür keine 24 h Codingtime wenn sichs mal um 8k 60 / 10 BitBit im Glossar erklärt handeln muss :)





Antwort von Jörg:

Schön, dass ihr diesen Aspekt mal quasi amtlich gemacht habt.
Das ist zwar nichts Neues, aber für viele ist die "powerrendering"Engine GPU mittlerweile zum Kultstatus erwachsen.
Es war schon zu CS6 Zeiten so, dass der damals von mainconcept angelieferte CodecCodec im Glossar erklärt in zwei Versionen in den AME einfloss, einen für 1pass, der Zweite für 2pass Encoding.
Der Unterschied war sichtbar.
Wer das heute noch nicht glaubt, sollte mal H264 aus Resolve ausrendern (hier in knapp 40% Echtzeit),
das Ergbnis dann mit einem clip vergleichen, der aus Resolve uncomp rausgerechnet wird, und in Handbrake mit x264 in einer langsamen 2 pass Version erstellt wird...nach Möglichkeit auf amtlichen Wiedergabegeräten, der 500€ Monitor wird es ev. nicht darstellen.
Ähnlich war es damals in Edius, der clip, der aus dem NLE direkt rausgerechnet wurde war deutlich
schlechter, als das gleiche file via Procoder mit selbst ertesteten presets.
Was hat goldwingfahrer an diesen settings gebastelt, die Ergebnisse waren für mich ein Grund Edius zu kaufen.

motiongroup hat natürlich recht: wer sein Material für yt oä herstellt, oder auf Aktualität und Tempo angewiesen ist, wird die GPU nehmen.
Es ist immer erstaunlich, wie viel über 8/10 bit oder sonstwelche Indikatoren "gefachsimpelt" wird,
deren unbestrittene Vorteile dann aber im Dampfkessel Quicksinc verschludert werden ;-))



Antwort von Frank Glencairn:

Solange YT/Vimeo das nachher nochmal verwursten, dürfte der Unterschied nicht so wild sein.



Antwort von dienstag_01:


Schön, dass ihr diesen Aspekt mal quasi amtlich gemacht habt.
Das ist zwar nichts Neues, aber für viele ist die "powerrendering"Engine GPU mittlerweile zum Kultstatus erwachsen.
Es war schon zu CS6 Zeiten so, dass der damals von mainconcept angelieferte CodecCodec im Glossar erklärt in zwei Versionen in den AME einfloss, einen für 1pass, der Zweite für 2pass Encoding.
Der Unterschied war sichtbar.
Wer das heute noch nicht glaubt, sollte mal H264 aus Resolve ausrendern (hier in knapp 40% Echtzeit),
das Ergbnis dann mit einem clip vergleichen, der aus Resolve uncomp rausgerechnet wird, und in Handbrake mit x264 in einer langsamen 2 pass Version erstellt wird...nach Möglichkeit auf amtlichen Wiedergabegeräten, der 500€ Monitor wird es ev. nicht darstellen.
Ähnlich war es damals in Edius, der clip, der aus dem NLE direkt rausgerechnet wurde war deutlich
schlechter, als das gleiche file via Procoder mit selbst ertesteten presets.
Was hat goldwingfahrer an diesen settings gebastelt, die Ergebnisse waren für mich ein Grund Edius zu kaufen.

motiongroup hat natürlich recht: wer sein Material für yt oä herstellt, oder auf Aktualität und Tempo angewiesen ist, wird die GPU nehmen.
Es ist immer erstaunlich, wie viel über 8/10 bit oder sonstwelche Indikatoren "gefachsimpelt" wird,
deren unbestrittene Vorteile dann aber im Dampfkessel Quicksinc verschludert werden ;-))

Verschludert wird vor allem die Erkenntnis, dass Quicksync nicht nur für das Encoding, sondern auch für das Decoding zur Anwendung kommt (kommen kann). Damit verschludert man eigentlich ziemlich viel ;)



Antwort von Jörg:

war das Thema hier Encoding??



Antwort von dienstag_01:


war das Thema hier Encoding??

War das Thema Quicksync?



Antwort von Jörg:

;-)),
aber 2Pass vs 1pass, dann passt es wieder?



Antwort von pixler:


Solange YT/Vimeo das nachher nochmal verwursten, dürfte der Unterschied nicht so wild sein.

Ja ? Ob ein ProResProRes im Glossar erklärt oder ein 2Pass H264 bei Vimeo hochlade macht für mich einen gut sichtbaren unterschied, ich nehme an das der Unterschied zwischen 1 und 2 Pass ebenfalls deutlich sein dürfte - vor allem wenn es nochmals verwurstet wird.



Antwort von Jörg:

je niedriger die DatenrateDatenrate im Glossar erklärt sein muss, desto stärker der Unterschied.



Antwort von Jost:

Vielleicht irre ich mich, aber 2-Pass-Encoding wird meines Wissens nur sinnvoll genutzt, wenn man plant, mit einer festgelegten Bitrate oder Dateigröße zu arbeiten. Wenn zum Beispiel etwas auf eine DVD soll, deren Kapazität begrenzt ist.
Dann wählt man die variable Bitrate samt 2-Pass-Encoding.
Wenn man diese Beschränkung nicht hat und man stattdessen mit konstanter Qualität arbeiten will, ist es wurscht, ob 1-Pass- oder 2-Pass-Encoding verwendet wird. Die Qualität wird weder besser noch schlechter.
constant ratefactor (1pass) aka. (average quantization), compared to constant quantization, varies the quantizer on a block-by-block and scene-by-scene basis, so it is a 1pass encoding mode which working similiar to 2pass encoding, tying to keep a constant quality, but unlike 2pass encoding it does not care about the filesize, so it's mainly ment for people who know the want a specific quanity level but do not care about the filesize.

Und das geht natürlich auch mit NVEnc. Aber nicht mit Nvidia selbst, sondern mit NVEnc (FFmpeg):
zum Bild https://s17.directupload.net/images/190228/pay7dbqw.jpg
zum Bild https://s17.directupload.net/images/190228/cl2bnq86.jpg



Antwort von pixler:

Hmm ich hatte mal den Fall wo ich eine Video mit vielen Stroboeffekten mit keinem 2Pass Encoder hinbekam ohne das es massive ArtefakteArtefakte im Glossar erklärt hatte, lediglich ein Hardware Encoder war in der Lage dies ohne Bildfehler zu codieren - weiss aber nicht ob das 1- oder 2. Pass war (da ich es ausser Haus geben musste)



Antwort von motiongroup:

Und nun ? Wenn ichs auf den osx und ios Geräten verwirklichen müsste und ich es noch in diesem leben begutachten kann, müsste ich mir gleich das Leben nehmen ... what a fuck is going one der neue T2 chip nimmt mir das coding bis zu h265 ab wenn dieser vorhanden ist...

Sie habens wirklich getan .. in den imac pros mit den xeons erledigt das nun der T2 und nicht die amd gpu ... böse Vorzeichen wirklich böse..

Wobei krass das ist die übergangsgeräte ohne können den Schrott als Hevc nur in 10 bit warum auch immer und desshalb greift x265 via handbrake in 8bit und gut ists

nachtrag schaut so aus als ob auch handbrake nun den T2 chip unterstützt

https://discussions.apple.com/thread/250022225



Antwort von Jost:


je niedriger die DatenrateDatenrate im Glossar erklärt sein muss, desto stärker der Unterschied.

Habe mal 1-Pass vs 2-Pass gebenchmarkt

PSNR
zum Bild https://s17.directupload.net/images/190228/gxexj2yc.jpg

SSIM
zum Bild https://s17.directupload.net/images/190228/yx4t3htc.jpg

Es stimmt schon, 2-Pass sorgt für ein besseres Ergebnis.
Aber das spielt sich im Zehntel-Prozent-Bereich ab.
Danach ist der Unterschied vergleichsweise sehr gering und dennoch sehr groß, weil man (ich) mit anderen Einstellungen und 1-Pass/Variable-Bitrate- nicht am 2-Pass/Variable-Bitrate-Ergebnis vorbei kommt.
Aber das sind akademische Spielereien, die nur für die höchst wichtig sind, die DVDs oder Blue Rays brennen wollen.

Hier gibt es übrigens den ganzen Vergleich zwischen CPU- und Nvidia-GPU-Encoding
https://devblogs.nvidia.com/turing-h264 ... d-quality/

H.265 fehlt leider. Was wohl daran liegt, dass man Turing-GPUs erst seit zwei Wochen vollständig zum Encodieren ansprechen kann. Und das auch nur per FFmpeg. Von Haus aus kann die Turing mittlerweile zwar B-Frames, aber immer noch kein 4:2:2. Das geht nur über FFmpeg. GUIs dafür kenne ich noch keine. X265.org und Hybrid werden wohl den Anfang machen.

Um der Wahrheit die Ehre zu geben: CPU und GPU laufen im Nvidia-Test beide unter FFmpeg und beide mit dem Preset "Medium". Der Test ist auch schon etwas älter. FFmpeg ist bereits seit November 2018 bei Version 4.1. Der Test läuft mit Version 4.02. Der verwendete 415er-Nvidia-Treiber stammt aus Oktober 2018. Das ganze Turing-Potential setzt man erst ab Version 418 frei.



Antwort von Jörg:

danke für den Test, Jost.
Zu Zeiten der SVCDSVCD im Glossar erklärt und der nachfolgenden Datenträgerverwendungen war der Zuwachs an sichtbarer Qualität deutlich stärker wahrnehmbar, auch heute würde mein visueller Eindruck nicht einen zehntelprozent Vorteil vermuten.



Antwort von Jost:


danke für den Test, Jost.
Zu Zeiten der SVCDSVCD im Glossar erklärt und der nachfolgenden Datenträgerverwendungen war der Zuwachs an sichtbarer Qualität deutlich stärker wahrnehmbar, auch heute würde mein visueller Eindruck nicht einen zehntelprozent Vorteil vermuten.

Im Stillen hatte ich gehofft, man könnte mit 1-Pass und trickreichen Einstellungen 2-Pass schlagen. Das ist mir nicht gelungen.
Ich hatte sogar das Preset "Placebo" versucht - wurde nicht besser.
Aber ob 1-Pass oder 2-Pass, ob Preset "Fast" oder "Placebo" - das spielt bei den SSIM- oder PSNR-Ergebnissen nur eine höchst untergeordnete Rolle. Jedenfalls bei meinen Tests.
Wenn man die SSIM-Ergebnisse Richtung 1 (verlustfrei) erhöhen will, geht das nur über Datenmenge. Fast verlustlos (0,989) ist bei mir unter UHD der Quantifizierungsfaktor 13. Dann ist ein UHD-Clip-X.264 mit 2:38 Minuten Länge sagenhafte 4,8 GB groß.
Mehr als 0,99 ergab der Quantifizierungsfaktor 12. Dann war das Video 5,2 GB groß. Zu groß für Vimeo Plus, das nur 5 GB die Woche zulässt.
Verglichen wurde freilich auch mit DNxHR HQ (25GB). Das hatte ich aus 4,6k CDNG gewandelt. Wenn H.264 Vergleichsmaterial ist, wird man wohl früher auf hohe SSIM-Werte kommen.

Zufrieden war ich mit dem Vimeo-Ergebniss dennoch nicht. In einem Clip des Videos hatte ich plötzlich wabbernde Strukturen. Es war ausgerechnet der Test-Clip, mit dem ich die SSIM-Ergebnisse getuned hatte und der ständig auf optische Fehler kontrolliert wurde. Die der Clip vor dem Upload nicht hatte.
Weiß der Henker ...



Antwort von kling:

Endlich schreibt das mal jemand so deutlich! Man kann die unkritischen PR-Aussagen zur angeblichen Hardware-Encodierung schon langsam nicht mehr hören.



Antwort von Jost:


Endlich schreibt das mal jemand so deutlich! Man kann die unkritischen PR-Aussagen zur angeblichen Hardware-Encodierung schon langsam nicht mehr hören.

Ich wäre da nicht so voreilig. Wenn es heißt: "Encoding per GPU vs. CPU: nVidia Turing-Encoding auf x264-Medium-Preset Niveau?",
dann könnten Schnell-Leser auf die Idee kommen: Mit nVidia Turing-Encoding sei nicht mehr drin, als x264-Medium-Preset Niveau.

Tatsächlich wird in beiden Fällen mit den Preset "Medium" encodiert.
zum Bild https://s17.directupload.net/images/190301/4a5xvwsh.jpg

Es steht Dir frei, per FFmpeg auch mit dem Preset "Slow" oder "Very Slow" mittels Nvidia-Encoding zu arbeiten.
Weil die Presets nach meinen Tests wenig an den PSNR-Ergebnissen ändern, käme man am Ende wohl zum Ergebnis:

"Encoding per GPU vs. CPU: nVidia Turing-Encoding auf x264-Very-Slow-Preset Niveau?"

Das sind übrigens die Ergebnisse:
zum Bild https://s17.directupload.net/images/190301/e6nv5q2y.jpg

Sie sind uneinheitlich. Betrachtet man allein die Grafik 7, dann ist der Vorteil von nVidia-Encoding mit identischem Preset schon richtig groß.



Antwort von Whazabi:

Also ich finde der Vergleich zwischen NVENC und x264 hinkt schon ein bisschen.
Ich meine im einen Fall hat man einen ASIC der, wie ihr ja schreibt, darauf ausgelegt ist Video in Echtzeit zu enkodieren.
Auf der anderen Seite steht eine Software die man nach eigenem Belieben bis in letzte Detail konfigurieren kann, aber keine Echzeit Anforderungen erfüllen muss.

Ein fairer Vergleich wäre entweder NVENC mit QuickSync. Da muss man sagen liefert die CPU ein weitaus schlechteres Ergebnis ab, da NVidia mittlerweile viel Arbeit in den eigenen Encoder
gesteckt hat und er deswegen für einen Echtzeit Encoder auch ein erstaunlich gutes Ergebnis hinbekommt.
Oder man vergleicht Software Encoder. Und da gibt es bei gleicher Implementierung auch keine Unterschiede in der Qualität, weil beide male der selbe Algorithmus angewendet wird, vollkommen unerheblich ob er auf einer GPU oder auf einer CPU läuft.
Lediglich ist die GPU dann um ein Vielfaches schneller fertig, weil sich große Teile des Prozesses parallelisieren lassen und GPU Architekturen eben genau darauf ausgelegt sind.

Dazu muss man allerdings auch erwähnen, dass es nur wenige Ansätze für einen Software Encoder auf CUDA Basis gibt und die mir bekannten kosten teuer Geld. Die meisten GPU Encoder verwenden NVENC und ja daher kann ich auch verstehen, weshalb man diesen Vergleich so zieht. Fair ist er in meinen Augen trotzdem nicht, denn das eigentliche Problem liegt nicht in der GPU, sondern darin einen freien umfangreichen Encoder zur Verfügung zu stellen, der nicht auf dem NVENC SDK aufsetzt.



Antwort von joje:

Hmm, wie ist das zu verstehen, das es mit einer GPU kein 2-pass Encoding gibt? Was macht dann Premiere oder der Media Encoder, wenn ich ein h.264 als 2-pass rendere und die GPU aktiviert ist? Laut Auslastung rendert sie schon bei beiden Pässen mit.



Antwort von Jost:


Also ich finde der Vergleich zwischen NVENC und x264 hinkt schon ein bisschen.
Ich meine im einen Fall hat man einen ASIC der, wie ihr ja schreibt, darauf ausgelegt ist Video in Echtzeit zu enkodieren.
Auf der anderen Seite steht eine Software die man nach eigenem Belieben bis in letzte Detail konfigurieren kann, aber keine Echzeit Anforderungen erfüllen muss.

Auch unter NVEnc per FFmpeg kann man das Encoding nach eigenem Belieben bis ins letzte Detail konfigurieren, es gibt keinen Unterschied zum Encodieren per CPU.
Es werden dazu freilich Erfahrungen mit Kommandozeile oder mit GUIs wie Hybrid erwartet. Normalen Schnittprogrammen wie Davinci, Premiere oder Magix fehlen solche Möglichkeiten.
Der Vergleich ist schon fair, zumal er auch von Nvidia ausging, nur die Schlussfolgerung hier ist optimierungsfähig.



Antwort von macaw:


Und nun ? Wenn ichs auf den osx und ios Geräten verwirklichen müsste und ich es noch in diesem leben begutachten kann, müsste ich mir gleich das Leben nehmen ... what a fuck is going one der neue T2 chip nimmt mir das coding bis zu h265 ab wenn dieser vorhanden ist...

Sie habens wirklich getan .. in den imac pros mit den xeons erledigt das nun der T2 und nicht die amd gpu ... böse Vorzeichen wirklich böse..

Wobei krass das ist die übergangsgeräte ohne können den Schrott als Hevc nur in 10 bit warum auch immer und desshalb greift x265 via handbrake in 8bit und gut ists

nachtrag schaut so aus als ob auch handbrake nun den T2 chip unterstützt

https://discussions.apple.com/thread/250022225

Hast Du Google translator benutzt? Ich verstehe (ganz ehrlich) nicht so richtig was diese Melange an Worten bedeuten soll...



Antwort von Whazabi:


Auch unter NVEnc per FFmpeg kann man das Encoding nach eigenem Belieben bis ins letzte Detail konfigurieren, es gibt keinen Unterschied zum Encodieren per CPU.
Es werden dazu freilich Erfahrungen mit Kommandozeile oder mit GUIs wie Hybrid erwartet. Normalen Schnittprogrammen wie Davinci, Premiere oder Magix fehlen solche Möglichkeiten.
Der Vergleich ist schon fair, zumal er auch von Nvidia ausging, nur die Schlussfolgerung hier ist optimierungsfähig.

Ja klar kann man NVENC auch anpassen. Aber nur in so weit wie das die Hardware zulässt, weil es eben ein Hardware Encoder ist. Sämtliche Features, die in Hardware nicht implementiert sind, kann man demenstprechend auch nicht nutzen und da die Hardware auf Echtzeitfähigkeit ausgelegt ist, wurden bisher auch viele Features die dafür nicht erforderlich sind weggelassen oder nur rudimentär umgesetzt. Kann sein, dass sich das von Architektur zu Architektur gebessert hat, dann benötigt man aber auch eine Grafikkarte der entsprechenden Generation, um die neuen Möglichkeiten nutzen zu können.



Antwort von dienstag_01:

Ich finde den Vergleich toll. Und auch den Artikel dazu ;)
Man sollte vielleicht anfügen, dass, wenn man wirklich an Qualität interessiert ist - und nicht nur an einer nichtssagenden *besten Qualität für diese Datenrate* - dann nimmt man einfach kein Preset *Medium* und beschränkt sich für 1080p1080p im Glossar erklärt auch nicht auf 10mbit. Im Ergebnis wird man vielleicht wirklich sowas wie Qualität haben. Wenn das Ausgangsmaterial es hergibt, natürlich ;)



Antwort von Jost:



Auch unter NVEnc per FFmpeg kann man das Encoding nach eigenem Belieben bis ins letzte Detail konfigurieren, es gibt keinen Unterschied zum Encodieren per CPU.
Es werden dazu freilich Erfahrungen mit Kommandozeile oder mit GUIs wie Hybrid erwartet. Normalen Schnittprogrammen wie Davinci, Premiere oder Magix fehlen solche Möglichkeiten.
Der Vergleich ist schon fair, zumal er auch von Nvidia ausging, nur die Schlussfolgerung hier ist optimierungsfähig.

Ja klar kann man NVENC auch anpassen. Aber nur in so weit wie das die Hardware zulässt, weil es eben ein Hardware Encoder ist. Sämtliche Features, die in Hardware nicht implementiert sind, kann man demenstprechend auch nicht nutzen und da die Hardware auf Echtzeitfähigkeit ausgelegt ist, wurden bisher auch viele Features die dafür nicht erforderlich sind weggelassen oder nur rudimentär umgesetzt. Kann sein, dass sich das von Architektur zu Architektur gebessert hat, dann benötigt man aber auch eine Grafikkarte der entsprechenden Generation, um die neuen Möglichkeiten nutzen zu können.

Klar, eine GPU, die nicht H.265 unterstützt, wird man nie dazu überreden können, H.265-Encoding zu beschleunigen.

Dass man viele Encoding-Features aber unter NVEnc/FFmpeg weggelassen oder nur rudimentär umgesetzt hat, ist mir neu. Möglicherweise hast Du darin eine viele größer Erfahrung als ich.
Die FFmpeg-Befehlssätze sind definiert. Zu den NVEnc/FFmpeg-Befehlssätzen habe ich nichts gefunden.
Kannst Du mal ein Beispiel nennen, welcher FFmpeg-Befehlssatz unter NVEnc/FFmpeg nicht akzeptiert wird?



Antwort von Whazabi:


Klar, eine GPU, die nicht H.265 unterstützt, wird man nie dazu überreden können, H.265-Encoding zu beschleunigen.

Dass man viele Encoding-Features aber unter NVEnc/FFmpeg weggelassen oder nur rudimentär umgesetzt hat, ist mir neu. Möglicherweise hast Du darin eine viele größer Erfahrung als ich.
Die FFmpeg-Befehlssätze sind definiert. Zu den NVEnc/FFmpeg-Befehlssätzen habe ich nichts gefunden.
Kannst Du mal ein Beispiel nennen, welcher FFmpeg-Befehlssatz unter NVEnc/FFmpeg nicht akzeptiert wird?

Naja es ist kein wirklicher Befehlssatz. Eher Konfigurations-Parameter. Aber lass uns nicht über Begrifflichkeiten streiten.
Ich meine welche Kodierungsoptionen prinzipiell zur Verfügung stehen legt der offizielle h.264 bzw h.265
Standard fest. Ein paar davon müssen zwangsläufig umgesetzt werden damit das ganze überhaupt läuft, aber es gibt auch viele optionale Möglichkeiten, die zwar die KompressionKompression im Glossar erklärt verbessern können, aber nicht in jeder Implementierung vorhanden sind.

Wie das bei aktuellen Architekturen aussieht weiß ich gerade nicht, weil es tatsächlich nicht mein Spezialgebiet ist die h.265 Spezifikation auswendig zu kennen ;)
Aber zB konnten die NVIDIA Karten bis Maxwell keine adaptive Quantisierung. Dementsprechend war das in NVENC auch nicht drin.



Antwort von MK:


Klar, eine GPU, die nicht H.265 unterstützt, wird man nie dazu überreden können, H.265-Encoding zu beschleunigen.

Ginge natürlich per CUDA oder Open CL... H.264 gab es in Totalcode früher mal mit CUDA-Beschleunigung, wurde aber aus unbekanntem Grund wieder komplett rausgeschmissen.



Antwort von kling:



Endlich schreibt das mal jemand so deutlich! Man kann die unkritischen PR-Aussagen zur angeblichen Hardware-Encodierung schon langsam nicht mehr hören.

Ich wäre da nicht so voreilig. Wenn es heißt: "Encoding per GPU vs. CPU: nVidia Turing-Encoding auf x264-Medium-Preset Niveau?",
dann könnten Schnell-Leser auf die Idee kommen: Mit nVidia Turing-Encoding sei nicht mehr drin, als x264-Medium-Preset Niveau.

Tatsächlich wird in beiden Fällen mit den Preset "Medium" encodiert.
zum Bild https://s17.directupload.net/images/190301/4a5xvwsh.jpg

Es steht Dir frei, per FFmpeg auch mit dem Preset "Slow" oder "Very Slow" mittels Nvidia-Encoding zu arbeiten.
Weil die Presets nach meinen Tests wenig an den PSNR-Ergebnissen ändern, käme man am Ende wohl zum Ergebnis:

"Encoding per GPU vs. CPU: nVidia Turing-Encoding auf x264-Very-Slow-Preset Niveau?"

Das sind übrigens die Ergebnisse:
zum Bild https://s17.directupload.net/images/190301/e6nv5q2y.jpg

Sie sind uneinheitlich. Betrachtet man allein die Grafik 7, dann ist der Vorteil von nVidia-Encoding mit identischem Preset schon richtig groß.

Nein, es geht doch darum, ob jemand mit 2pass, also mit Content-Analyse vor dem eigentlichen Encoding arbeitet.



Antwort von kling:



Und nun ? Wenn ichs auf den osx und ios Geräten verwirklichen müsste und ich es noch in diesem leben begutachten kann, müsste ich mir gleich das Leben nehmen ... what a fuck is going one der neue T2 chip nimmt mir das coding bis zu h265 ab wenn dieser vorhanden ist...

Sie habens wirklich getan .. in den imac pros mit den xeons erledigt das nun der T2 und nicht die amd gpu ... böse Vorzeichen wirklich böse..

Wobei krass das ist die übergangsgeräte ohne können den Schrott als Hevc nur in 10 bit warum auch immer und desshalb greift x265 via handbrake in 8bit und gut ists

nachtrag schaut so aus als ob auch handbrake nun den T2 chip unterstützt

https://discussions.apple.com/thread/250022225

Hast Du Google translator benutzt? Ich verstehe (ganz ehrlich) nicht so richtig was diese Melange an Worten bedeuten soll...

Stimmt. Tatsächlich nur schrägestes Nerd-Chinesisch!



Antwort von motiongroup:

Macht nichts probiert’s das gelesene nicht verstandene wieder ins Denglish zu übersetzen und schon ist alles gut ;)
Mannn muss schon verstehen können wollen auch;)

Now what? If I had to realize it on the osx and ios devices and I can still examine it in this life, I would have to take my life right away ... what a fuck is going one the new T2 chip takes the coding up to h265 from me if it is available...

You really did it ... in the imac pros with the xeons the T2 does it now and not the amd gpu ... bad sign really bad...

Whereby crank this is the transition devices without can the scrap as Hevc only in 10 bit why ever and therefore x265 grabs via handbrake in 8bit and is good

supplement looks like handbrake now supports the T2 chip as well

https://discussions.apple.com/thread/250022225



Antwort von MK:

Fun-Fact: Sonic SD-2000 Hardwareencoder für DVD anno 2003... 2-pass Encoding hat da bedeutet Analysepass = Einmal das Band (z.B. Digibeta) mit RS422-Steuerung durchlaufen lassen und analysieren, und dann nochmal durchlaufen lassen und auf Basis der Analysedaten VBRVBR im Glossar erklärt Encoden... also Minimum 2x länger als Echtzeit + die Spulzeiten.



Antwort von motiongroup:

Fun-Fact: Sonic SD-2000 hardware encoder for DVD anno 2003... 2-pass Encoding means analysis pass = Once the tape (e.g. Digibeta) with RS422 control run through and analyze, and then run through again and based on the analysis data VBRVBR im Glossar erklärt Encodes... so minimum 2x longer than real time + the winding times.

geht doch habe ich voll verstanden



Antwort von Kamerafreund:

Fazit: Sieht für mich so aus als ob ich einfach beim GPU Export 2-3 Mbits mehr einstelle und inklusive Upload und Sicherung deutlich schneller fertig bin bei gleicher Qualität. Ist für mich die Diskussion nicht unbedingt wert. Trotzdem danke für den Hinweis! :)




Noch was unklar? Dann in unserem Forum nachfragen
Zum Original-Thread / Zum News-Kommentare-Forum

Antworten zu ähnlichen Fragen:
Encoding per GPU vs. CPU: nVidia Turing-Encoding auf x264-Medium-Preset Niveau?
VP9 multithreaded encoding
Live Encoding für Mac OS X
Adobe Media Encoder - 2 pass encoding
F: Langsamste Geschwindigkeit für Hardware-MPEG-Encoding
Lohnt sich AMD64 fü r Videobearbeitung (MPEG-Encoding)
Kein Smart Encoding mit NeroVison Express
Cinegy Cinescore - Gut gemachter Video Encoding Benchmark
Virtualdubmod und XVID1.1.3 -> Probleme beim 2-Pass-Encoding
SAT-Karte mit Hardware oder Software-Encoding
Lohnt sich AMD64 für Videobearbeitung (MPEG-Encoding)
Blackmagic DaVinci Resolve Update 15.2.4 bringt u.a. besseres H.264/H.265 Encoding
Netflix spart 30% Daten durch Encoding-Optimierungen und VP9 Codec
Experte / Berater für Live Encoding und Bildmischung gesucht! (Blackmagic)
Blackmagic Design: Atem Mini Pro Switcher mit integriertem H.264-Encoding für Live-Streaming
Nvidia RTX 2070 Turing-Variationen und Probleme mit RTX 2080 Ti?
CPU/GPU Premiere
"Phantomschmerz" - Produktion auf Kino-Niveau - gedreht auf Ursa Mini Pro und Sigma Cine Primes
Hyperlapse auf hohem Niveau
Leistungsplus durch neue CPU/GPU?
AMD Zeppelin CPU mit 32 Cores und Vega GPU
Intels nächste CPU kommt mit integrierter AMD GPU!
Sehr nidrige CPU und GPU-Auslastung beim rendern
Einstellungen für AE/ Cuda/ GPU+CPU nur max 15% Auslastung?
Adobe Premiere - 720x576 Material auf Blu-Ray - welches Preset?
AMD oder NVidia GPU für Photoshop/DaVinci Resolve?

















weitere Themen:
Spezialthemen


16:9
3D
4K
ARD
ARTE
AVCHD
AVI
Adapter
Adobe After Effects
Adobe Premiere Pro
After effects
Akku
Akkus
Apple Final Cut Pro
Audio
Aufnahme
Aufnahmen
Avid
Band
Bild
Bit
Blackmagic
Blackmagic Design DaVinci Resolve
Blende
Book
Brennen
Cam
Camcorder
Camera
Canon
Canon EOS 5D MKII
Canon EOS C300
Capture
Capturing
Cinema
Clip
ClipKanal
Clips
Codec
Codecs
DSLR
Datei
Digital
ENG
EOS
Effect
Effekt
Effekte
Export
Fehler
Festplatte
File
Film
Filme
Filmen
Filter
Final Cut
Final Cut Pro
Firmware
Format
Formate
Foto
Frage
Frame
HDMI
HDR
Hilfe
Import
JVC
Kabel
Kamera
Kanal
Kauf
Kaufe
Kaufen
Kurzfilm
Layer
Licht
Live
Lösung
MAGIX video deLuxe
MPEG
MPEG-2
MPEG2
Mac
Magix
Magix Vegas Pro
Menü
Mikro
Mikrofon
Mikrophone
Monitor
Movie
Musik
Musikvideo
NAB
Nero
News
Nikon
Objektiv
Objektive
PC
Panasonic
Panasonic GH2
Panasonic HC-X1
Panasonic S1 mit V-Log
Pinnacle
Pinnacle Studio
Player
Plugin
Plugins
Premiere
Projekt
RAW
RED
Recorder
Red
Render
Rendern
Schnitt
Software
Sony
Sound
Speicher
Stativ
Stative
Streaming
Studio
TV
Test
Titel
Ton
USB
Umwandeln
Update
Vegas
Video
Video-DSLR
Videos
Videoschnitt
Windows
YouTube
Zoom