H.265 alias HEVC spart bei der Aufzeichnung eine Menge Speicherplatz. Doch bei der Bearbeitung muss man für diesen Vorteil mit schlechter Schnitt Performance bezahlen. Wie wollten mal nachfühlen, wie der Wechselkurs aktuell steht...
Sobald man moderne HEVC-Streams mit 10 Bit 4:2:2 Codierung oder auch 50/60p ins Rennen schickt ziehen trübe Wolken auf.
das hängt sehr stark von der verwendeten hardwarebeschleunigungslösung ab, aber gerade der unscheinbare sprung von 4:2:0, das gewöhnlich kaum probleme macht, zu 4:2:2 bringt hier wirklich gravierende änderungen mit sich, da letzteres im falle von nivida gar nicht unterstützt wird und bei intel auch erst in der ice lake generation. natürlich kann man vor diesem umstand einfach die augen verschließen und weiterhin unnachgiebig auf formaten bestehen, die mit diesen vorgaben nicht vereinbar sind, oder aber man akzeptiert und berücksichtigt diese gegebenheiten (was im übrigen ohnehin auch die meisten kameras mit ähnlich gelagerten aufzeichnungseinschränkunken nahe legen) und wird dann halt auch mit vernünftiger benutzbarkeit belohnt.
Meine Interpretationsversuche zu den skizzierten Problemen können nur theoretisch sein
(hab's selber nicht gemessen). Mir ist auch klar, dass genaues Verifizieren der
Einfluss-Faktoren sehr aufwändig sein kann.
Aber:
mein Einwand wäre (ganz abstrakt betrachtet), ob hier nicht eine Scheinkausalität zu falschem Fazit führt.
Verglichen werden sollte mE footage in gleicher Qualität (Auflösung, Framerate, Bittiefe,etc) in jeweils
h.264 und h.265 encodiert. Dann könnten die Resulate vielleicht anders aussehen.
Hier müssen einfach seeehr viel Pixelei/sec durchgeschoben werden. Bei 4kP50 wären dies ca 400 Mpx/sec
bzw 1200 MB/sec bei interner 24Bit-Darstellung (RGB-8Bit). Bei 10Bit natürlich noch mehr.
Diese Datenmenge muss intern prozessiert werden, um sie überhaupt erstmal darstellen zu können,
hinzu kämen Rechenaufwand für Filter etc, aber eben unabhängig von der codierung (264/265).
Und Vorsicht hier:
die Angaben zum Durchsatz bei SSDs (selbst bei M2) sind immer peak-Werte, nicht sustained!
h.264 und h.265 sind eng verwandt.
Aber die h.264-Encoder haben einige Jahre Optimierungsvorsprung.
Umgekehrt lässt sich h.265 so parametrisieren (im Prinzip zumindest), dass faktisch kein Unterschied zu
h.264 mehr bleibt, aber eben auch keine kleineren Dateien mehr dabei rauskommen.
Ich gehe davon aus, dass die h.265-Encoder in den Cams aus den gleichen Gründen einige Kompromisse
beinhalten müssen, sonst wären Kühlkörper und Akkus doppelt so groß wie die Cam. Denn der Rechenaufwand
ist nunmal so groß, egal wie der erbracht wird.
Diese Kompromisse sind es dann wahrscheinlich, die unterschiedliche Encoder-Dialekte auf
der Decoderseite zum Humpeln bringen. Und hier kommt wieder der Optimierungsvorsprung der
h.264-Encoder zum tragen.
Grundsätzlich ist es vermutlich nicht der Unterschied zw h.264 u h.265 selber.
mash_gh4 hat geschrieben: ↑Di 02 Jul, 2019 11:14
das hängt sehr stark von der verwendeten hardwarebeschleunigungslösung ab, aber gerade der unscheinbare sprung von 4:2:0, das gewöhnlich kaum probleme macht, zu 4:2:2 bringt hier wirklich gravierende änderungen mit sich, da letzteres im falle von nivida gar nicht unterstützt wird
Wirklich großes Danke für diesen relevanten Nvidia Hinweis. Wir haben diesen Artikel nämlich in den letzten 2 Monaten schon dreimal umgeschrieben und immer wieder nachgetestet und haben festgestellt, dass man hierfür noch weitaus systematischer vorgehen müsste, um wirklich relevante Aussagen treffen zu können. In dieser Zeit hat nicht nur Edius einen neuen Decoder bekommen sondern auch AMD hat unter Resolve einen riesigen Sprung gemacht. Und dabei ging zwischen den Versionen immer mal wieder ein Format besser als das andere. Jetzt haben wir den Artikel einfach so raus gegeben, bevor er komplett für die Tonne ist.
Wir werden jetzt erst mal Formate sammeln, und dann vielleicht nochmal im Herbst mehr testen, wenn Resolve auch final ist und Premiere/Rush vielleicht etwas mehr in die Gänge gekommen sind.
dosaris hat geschrieben: ↑Di 02 Jul, 2019 11:42
interessanter Beitrag!
Danke dafür.
Meine Interpretationsversuche zu den skizzierten Problemen können nur theoretisch sein
(hab's selber nicht gemessen). Mir ist auch klar, dass genaues Verifizieren der
Einfluss-Faktoren sehr aufwändig sein kann.
Aber:
mein Einwand wäre (ganz abstrakt betrachtet), ob hier nicht eine Scheinkausalität zu falschem Fazit führt.
Verglichen werden sollte mE footage in gleicher Qualität (Auflösung, Framerate, Bittiefe,etc) in jeweils
h.264 und h.265 encodiert. Dann könnten die Resulate vielleicht anders aussehen.
Hier müssen einfach seeehr viel Pixelei/sec durchgeschoben werden. Bei 4kP50 wären dies ca 400 Mpx/sec
bzw 1200 MB/sec bei interner 24Bit-Darstellung (RGB-8Bit). Bei 10Bit natürlich noch mehr.
Diese Datenmenge muss intern prozessiert werden, um sie überhaupt erstmal darstellen zu können,
hinzu kämen Rechenaufwand für Filter etc, aber eben unabhängig von der codierung (264/265).
Und Vorsicht hier:
die Angaben zum Durchsatz bei SSDs (selbst bei M2) sind immer peak-Werte, nicht sustained!
h.264 und h.265 sind eng verwandt.
Aber die h.264-Encoder haben einige Jahre Optimierungsvorsprung.
Umgekehrt lässt sich h.265 so parametrisieren (im Prinzip zumindest), dass faktisch kein Unterschied zu
h.264 mehr bleibt, aber eben auch keine kleineren Dateien mehr dabei rauskommen.
Ich gehe davon aus, dass die h.265-Encoder in den Cams aus den gleichen Gründen einige Kompromisse
beinhalten müssen, sonst wären Kühlkörper und Akkus doppelt so groß wie die Cam. Denn der Rechenaufwand
ist nunmal so groß, egal wie der erbracht wird.
Diese Kompromisse sind es dann wahrscheinlich, die unterschiedliche Encoder-Dialekte auf
der Decoderseite zum Humpeln bringen. Und hier kommt wieder der Optimierungsvorsprung der
h.264-Encoder zum tragen.
Grundsätzlich ist es vermutlich nicht der Unterschied zw h.264 u h.265 selber.
Danke fürs Danke. Und wie schon im letzten Beitrag geschrieben: Sowas wirklich sinnvoll zu betrachten ist weitaus aufwändiger, als es erstmal scheint. Deine Gedanken dazu sind definitiv ein Teil dieses Problems.
Sobald man moderne HEVC-Streams mit 10 Bit 4:2:2 Codierung oder auch 50/60p ins Rennen schickt ziehen trübe Wolken auf.
das hängt sehr stark von der verwendeten hardwarebeschleunigungslösung ab, aber gerade der unscheinbare sprung von 4:2:0, das gewöhnlich kaum probleme macht, zu 4:2:2 bringt hier wirklich gravierende änderungen mit sich, da letzteres im falle von nivida gar nicht unterstützt wird und bei intel auch erst in der ice lake generation. natürlich kann man vor diesem umstand einfach die augen verschließen und weiterhin unnachgiebig auf formaten bestehen, die mit diesen vorgaben nicht vereinbar sind, oder aber man akzeptiert und berücksichtigt diese gegebenheiten (was im übrigen ohnehin auch die meisten kameras mit ähnlich gelagerten aufzeichnungseinschränkunken nahe legen) und wird dann halt auch mit vernünftiger benutzbarkeit belohnt.
Ist es nicht so, dass die "größeren" Nvidia-Karten nun auch version 2 von HEVC unterstützen?
version 1 bietet ja maximal nur 10bit 420.
Mir scheint, dass die Hardwareunterstützung von version2 und damit eben 10bit 422 (und mehr) erst langsam kommt. Und dann muss auch die Software erst mal darauf angepasst werden.
Wahrscheinlich nutzen viele Kameras (einschließlich ZCam) eben nur Hardware, welche version1 unterstützt.
Meine Vermutung.
iasi hat geschrieben: ↑Di 02 Jul, 2019 12:08
Ist es nicht so, dass die "größeren" Nvidia-Karten nun auch version 2 von HEVC unterstützen?
nein -- ich kenne zwar den wahren grund für diese einschränkung natürlich auch nicht, aber fehlende 4:2:2 unterstützung war im falle von nvidia auch schon bei h.264 in genau der gleichen weise der fall. und so wie dort die 10bit unterstützung bei praktisch allen verbreiteten hardwarebeschleunigungslösungen bis heute ausgeblieben ist, gilt es auch bei 4:2:2 nicht gar zu optimistisch im hinblick auf zukünftigen verbesserungen zu bleiben. im bezug auf hardwarebeschleunigung können die hersteller oft auch einfach nicht ganz so flexibel reagieren wie bei reinen software- bzw. treiber-updates. diesbezügliche einschränkungen bleiben also zumindest für eine chipgeneration weitestegehend unabänderlich. ich glaube aber, dass man es durchaus auch als ein vernünftiges abwägen von tatsächlichen vorteilen, entwicklungsaufwand und realen verfügbaren alternativen werten sollte, wenn hersteller manche dinge, wie eben 4:2:2 unterstützung oder 10bit-h.264, keine übermäßig große bedeutsamkeit beimessen bzw. ihre kräfte und innovationsbemühungen auf anderes konzentrieren.
Danke für den Test!!!! Ich gehe davon aus dass xavc-L also als h264 422 10 Bit bald zum Standard-Sendecodec wird. Die Hersteller sollten also ein Interesse dran haben. Den großen Vorteil von h265 sehe ich eh noch nicht unbedingt. Vor allem nicht fürs Rohmaterial. Klar ist er etwas effektiver aber die Einbußen an Rechenleistung sind noch so gewaltig dass sich h264 lange halten wird. Für das bisschen Speicherplatz mehr so ein Akt?
iasi hat geschrieben: ↑Di 02 Jul, 2019 12:08
Ist es nicht so, dass die "größeren" Nvidia-Karten nun auch version 2 von HEVC unterstützen?
nein -- ich kenne zwar den wahren grund für diese einschränkung natürlich auch nicht, aber fehlende 4:2:2 unterstützung war im falle von nvidia auch schon bei h.264 in genau der gleichen weise der fall. und so wie dort die 10bit unterstützung bei praktisch allen verbreiteten hardwarebeschleunigungslösungen bis heute ausgeblieben ist, gilt es auch bei 4:2:2 nicht gar zu optimistisch im hinblick auf zukünftigen verbesserungen zu bleiben. im bezug auf hardwarebeschleunigung können die hersteller oft auch einfach nicht ganz so flexibel reagieren wie bei reinen software- bzw. treiber-updates. diesbezügliche einschränkungen bleiben also zumindest für eine chipgeneration weitestegehend unabänderlich. ich glaube aber, dass man es durchaus auch als ein vernünftiges abwägen von tatsächlichen vorteilen, entwicklungsaufwand und realen verfügbaren alternativen werten sollte, wenn hersteller manche dinge, wie eben 4:2:2 unterstützung oder 10bit-h.264, keine übermäßig große bedeutsamkeit beimessen bzw. ihre kräfte und innovationsbemühungen auf anderes konzentrieren.
Nun hab ich aber eben diese Info gefunden, die immerhin besagt, dass Nvidias TU104 doch mehr kann, als 4:2:0:
On October 17, 2017, Microsoft removed HEVC decoding support from Windows 10 with the Version 1709 Fall Creators Update, making HEVC available instead as a separate download from the Microsoft Store. [100]
On November 2, 2017, Nvidia released the GeForce GTX 1070 Ti (GP104), which includes full fixed function HEVC Main10/Main12 hardware decoder.
2018
On September 20, 2018, Nvidia released the GeForce RTX 2080 (TU104), which includes full fixed function HEVC Main 4:4:4 12 hardware decoder.
seit macOS h265 integriert hat (high sierra) läuft es in fcpX von anfang an sehr gut und flüssig. adobe/avid kann man vergessen. beste optimierung ist eindeutig fcp.
hexeric hat geschrieben: ↑Di 02 Jul, 2019 16:39
seit macOS h265 integriert hat (high sierra) läuft es in fcpX von anfang an sehr gut und flüssig. adobe/avid kann man vergessen. beste optimierung ist eindeutig fcp.
Aber nur die 8bit Variante per igpu oder T2
Bei den 10bit Varianten rechnet sich apple nen wolf wie alle anderen auch egal ob mit Amd oder Nvidia
Bei den 10bit Varianten rechnet sich apple nen wolf wie alle anderen auch egal ob mit Amd oder Nvidia
genau das ist mein Kenntnisstand, erklärt von Leuten, die auf der Plattform arbeiten.
Ich denke, slashcam hat das gut im Fazit rüber gebracht:
es ist allerhand zu tun, flüssig läufts wohl nirgends.
Ich habe Tests mit Resolve gemacht, dann in freundlichen codec gerechnet, ist mir der Spaß wert, kostet Faktor 4 mehr Speicherplatz, den habe ich ;-))
Blöde Frage:
Wenn ich eine relativ starke Intel Quicksync CPU habe und nur eine gute Decoder-Performance brauche. (Also keine Effekte und höchstens leichtes Colorgrading). Brauche ich dann auch in Resolve keine starke Grafikkarte? NVDEC und Quicksync wäre ja doppelt gemoppelt..
Ja, das wird noch ein paar Updates dauern ehe das vernünftig funzt. Oder man lehnt sich entspannt zurück und wartet, in dem man erstmal drauf verzichtet. Die Verhältnismäßigkeit zwischen Speicherstrategie und Workflow ist noch nicht verhältnismäßig. Somit Useless ;)
Kamerafreund hat geschrieben: ↑Di 02 Jul, 2019 18:08
Blöde Frage:
Wenn ich eine relativ starke Intel Quicksync CPU habe und nur eine gute Decoder-Performance brauche. (Also keine Effekte und höchstens leichtes Colorgrading). Brauche ich dann auch in Resolve keine starke Grafikkarte? NVDEC und Quicksync wäre ja doppelt gemoppelt..
Probiere es aus. Für normale Workflows ohne spezielle Effekte (Debayering, Noise Reduction etc.) kommt Resolve sowieso ohne diese hier immer wieder herbeigeschriebene Grafikkartengigantomanie aus. Ich habe z.B. einige kleinere Sachen in HD mit einer GT und aktuell mit einer GTX950 gemacht. Ohne Probleme.
Und wenn dein Material von der iGPU unterstützt wird und du das nutzen willst, brauchst du hier eigentlich überhaupt niemanden zu fragen, scheint bisher niemand zu verwenden - haben sich alle mit 400 Euro Grafikkarten eingedeckt, geht ja auch ;)
Danke! Wäre trotzdem ein teures experiment. Bin gerade am überlegen ob neues Macbook oder gleich ein günstiger Desktop PC. Nur Gehäuse, Mainboard und Intel-CPU mit Onboard-Grafik wäre schon deutlich günstiger.. ;)
Kamerafreund hat geschrieben: ↑Di 02 Jul, 2019 22:55
Danke! Wäre trotzdem ein teures experiment. Bin gerade am überlegen ob neues Macbook oder gleich ein günstiger Desktop PC. Nur Gehäuse, Mainboard und Intel-CPU mit Onboard-Grafik wäre schon deutlich günstiger.. ;)
Naja, ausschließlich iGPU für Resolve hielte ich auch für ein bisschen sportlich ;)
Oder ist es nur HD?
Aber vielleicht findet sich hier ja doch noch einer, der Resolve mit Intel iGPU nutzt.
Das wäre echt mal spannend!
Der Plan wäre dann einfach ein Prozessor der Ice Lake generation.
Da wäre dann ja alles drin.
Version 7 (Ice Lake)
The Ice Lake (microarchitecture) adds VP9 4:4:4 decoding, VP9 encoding (up to 10-bit and 4:4:4), HEVC 4:2:2 and 4:4:4 decoding and encoding,[15] HDR10 Tone Mapping[16] and Open Source Media Shaders
Keine Ahnung, wann der so an seine Grenzen kommt.
dienstag_01 hat geschrieben: ↑Di 02 Jul, 2019 23:04
Kamerafreund hat geschrieben: ↑Di 02 Jul, 2019 22:55
Danke! Wäre trotzdem ein teures experiment. Bin gerade am überlegen ob neues Macbook oder gleich ein günstiger Desktop PC. Nur Gehäuse, Mainboard und Intel-CPU mit Onboard-Grafik wäre schon deutlich günstiger.. ;)
Naja, ausschließlich iGPU für Resolve hielte ich auch für ein bisschen sportlich ;)
Oder ist es nur HD?
Aber vielleicht findet sich hier ja doch noch einer, der Resolve mit Intel iGPU nutzt.
Das Verrückte bei Apple ist aber wenn kein HW Support vorhanden auf QSync oder T2 vorhanden ist aber eine Generation von Nv Karte verbaut ist die die 8bit Variante erlauben würde, wird es trotzdem nicht unterstützt. Noch viel krasser ist aber, dass ab dem Zeitpunkt des Fehlens NUR HEVC 10bit über CPU Enconding zu Verfügung steht und es kleine 8bit CPU Softwarelösung gibt.
Frank Glencairn hat geschrieben: ↑Mi 03 Jul, 2019 06:53
Bottom line: H264/65 sind kein Aufnahmecodecs.
Ich kann nicht verstehen, warum man sich sowas antut.
Warum sollen es keine Aufnahmecodecs sein?
Sie verlangen zwar höhere Rechenleistung, bieten dafür aber eben auch höhere Kompressionsraten bei gleicher Qualität.
Ich bin zwar RAW-Verfechter, aber lange Aufnahmen, bei denen keine große Nachbearbeitung rentabel ist, sind geringe Datenraten durch moderne Codecs ein Vorteil.
Die Hardwareunterstützung kommt, dadurch steht dann auch genügend Rechenleistung für die komplexeren Algorithmen zur Verfügung.
Die RedRaw-Bearbeitung erhielt durch Nividia-Unterstützung einen ordentlichen Schub.
Mehr Rechenpower ermöglicht eben nicht nur ein mehr an Pixeln und Framerate, sondern eben auch umfangreichere und damit bessere Berechnungen.
Weil wir das Jahr 2019 schreiben, und Datenspeicher so billig wie noch nie ist.
Aber bitte, wenn jemand unbedingt meint er müsse an DER Stelle sparen - be my guest.
Als nächstes lesen wir dann wieder den 12zigzillionsten Post "Hilfe mein Material ruckelt"
Frank Glencairn hat geschrieben: ↑Mi 03 Jul, 2019 07:55
Weil wir das Jahr 2019 schreiben, und Datenspeicher so billig wie noch nie ist.
Aber bitte, wenn jemand unbedingt meint er müsse an DER Stelle sparen - be my guest.
Als nächstes lesen wir dann wieder den 12zigzillionsten Post "Hilfe mein Material ruckelt"
Weil wir das Jahr 2019 schreiben, und CPUs und GPUs so viel Rechenleistung bieten wie noch nie.
Als nächstes lesen wir dann wieder den 12zigzillionsten Post "Hilfe ich habe Drop-Frames"
Aber mal ganz nüchtern, da kann man Frank nicht widersprechen. Bei den aktuellen Preisen macht ein Hype zu noch mehr Datenreduktion wenig Sinn.
Schon garnicht wenn mit dem Material nachher noch ordentlich in der Post hantiert werden soll.
Kann aber ja auch nur für mich sprechen. Mir braucht solches Material jedenfalls keiner auf den Tisch legen. Kann unbesichtet wieder mitgenommen werden... 🧐
Auch nicht zu vergessen:
Wenn man als Freier Cutter für andere schneidet, bekommt man ja unterschiedlichstes Material von diversen Kameras auf den Tisch und kann sich seinen Workflow nicht aussuchen. Das könnte man dann zwar auch transcodieren, aber wenn es flott gehen soll und es es viel Material ist, dann kann es schon mehr als praktisch sein, wenn man alles einfach auf die Timeline schmeißen und losschneiden kann.
Auch in ProRes HQ kommen übrigens reichlich Daten zusammen, wenn man einen 2 Stunden-Vortrag in 4k aufnimmt.
Ich begreife solche Einwände nicht...
Natürlich kommt da material zusammen.
na und?
Wenn ich 100 Kubik Holz transportiere, benötige ich halt das passende Fahrzeug...
kann ich auch nicht nölen, dass das alles viel zuviel ist.
Speicherplatz ist so was von billig, wenn ich an die 1G HDD von 1997 denke...
iasi hat geschrieben: ↑Mi 03 Jul, 2019 12:23
Auch in ProRes HQ kommen übrigens reichlich Daten zusammen, wenn man einen 2 Stunden-Vortrag in 4k aufnimmt.
Wie bescheuert müsste man sein, um so etwas zu tun?
iasi hat geschrieben: ↑Mi 03 Jul, 2019 12:23
Auch in ProRes HQ kommen übrigens reichlich Daten zusammen, wenn man einen 2 Stunden-Vortrag in 4k aufnimmt.
Wie bescheuert müsste man sein, um so etwas zu tun?
Leute wollen ihre Hochzeit in Hollywood-Qualität gefilmt haben. Da kommen dann mehrere Reds zum Einsatz - nebst Kran, Copter usw.
Also: Warum will wohl jemand im UHD-TV-Zeitalter auch UHD-Aufzeichnung?
Jedes Telefon kann das schließlich.
Und da sind wir dann eben bei der Frage, ob wir eingedampftes Telefon-UHD, dickes ProRes-4k oder z.B. handliches Main 422 10bit HEVC nehmen.
Problem ist dabei für mich zumindest auch das Archivieren. Das kann sich bei Dokus schon lohnen. Ich nehme zwar in prores auf, was zum schneiden super ist, muss aber nachher in z.b. HEVC transcodieren. Alles in Prores archivieren wäre für mich selbst bei billigen Platten der Wahnsinn. Alternative wäre komprimiert aufnehmen und in prores transcodieren oder eben gleich komprimiert schneiden. Mit h264 sehe ich da ehrlich gesagt auch gar nicht die Probleme, da die Hardwarebeschleunigung echt weit ist. Und da gibt es ja auch erste Standards wie xavc-L. Für HEVC sind die Rechner eben noch nicht so weit und der kompressionsgewinn steht in keinem Verhältnis zum Rechenaufwand. Also für mich entweder prores oder alter Sendestandard mpeg2 (xdcamhd) oder bald neuer Standard h264 (xavc-L). HEVC ist gerade eher noch Spielerei.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
