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

[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?

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

[motiongroup]

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

[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 Codec 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 ;-))

[Frank Glencairn]

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

[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 Codec 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 ;)

[Jörg]

war das Thema hier Encoding??

[dienstag_01]

war das Thema hier Encoding??

War das Thema Quicksync?

[Jörg]

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

[pixler]

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

Ja ? Ob ein ProRes 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.

[Jörg]

je niedriger die Datenrate sein muss, desto stärker der Unterschied.

[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):

[pixler]

Hmm ich hatte mal den Fall wo ich eine Video mit vielen Stroboeffekten mit keinem 2Pass Encoder hinbekam ohne das es massive Artefakte 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)

[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

[Jost]

je niedriger die Datenrate sein muss, desto stärker der Unterschied.

Habe mal 1-Pass vs 2-Pass gebenchmarkt

PSNR



SSIM


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.

[Jörg]

danke für den Test, Jost.
Zu Zeiten der SVCD 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.

[Jost]

danke für den Test, Jost.
Zu Zeiten der SVCD 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 ...

[kling]

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

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


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:


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

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

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

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

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

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

[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 1080p auch nicht auf 10mbit. Im Ergebnis wird man vielleicht wirklich sowas wie Qualität haben. Wenn das Ausgangsmaterial es hergibt, natürlich ;)

[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?

[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 Kompression 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.

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

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


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:


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.

[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!

[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

[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 VBR Encoden... also Minimum 2x länger als Echtzeit + die Spulzeiten.

[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 VBR Encodes... so minimum 2x longer than real time + the winding times.

geht doch habe ich voll verstanden

[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! :)