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.
Antwort von dosaris:
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.
Antwort von rudi:
mash_gh4 hat geschrieben:
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.
Antwort von rudi:
dosaris hat geschrieben:
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.
Antwort von iasi:
mash_gh4 hat geschrieben:
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.
Antwort von mash_gh4:
iasi hat geschrieben:
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.
Antwort von Kamerafreund:
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?
Antwort von iasi:
mash_gh4 hat geschrieben:
iasi hat geschrieben:
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.
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.
Antwort von motiongroup:
hexeric hat geschrieben:
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
Antwort von Jörg:
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 ;-))
Antwort von Kamerafreund:
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..
Antwort von Framerate25:
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 ;)
Antwort von dienstag_01:
Kamerafreund hat geschrieben:
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 ;)
Antwort von Kamerafreund:
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.. ;)
Antwort von dienstag_01:
Kamerafreund hat geschrieben:
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.
Antwort von Kamerafreund:
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, HDR10 Tone Mapping and Open Source Media Shaders
Keine Ahnung, wann der so an seine Grenzen kommt.
dienstag_01 hat geschrieben:
Kamerafreund hat geschrieben:
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.
Antwort von motiongroup:
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.
Antwort von Frank Glencairn:
Bottom line: H264/65 sind kein Aufnahmecodecs.
Ich kann nicht verstehen, warum man sich sowas antut.
Antwort von iasi:
"Frank Glencairn" hat geschrieben:
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.
Antwort von Frank Glencairn:
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"
Antwort von iasi:
"Frank Glencairn" hat geschrieben:
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"
Antwort von Frank Glencairn:
Niemand hat dropped Frames, wenn er nicht die völlig falschen Medien benutzt.
Antwort von Jott:
Was allerdings Volkssport ist.
Antwort von iasi:
"Frank Glencairn" hat geschrieben:
Niemand hat dropped Frames, wenn er nicht die völlig falschen Medien benutzt.
Niemand hat ruckelndes Material, wenn er nicht die völlig falsche Hardware benutzt.
Antwort von Framerate25:
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... 🧐
Antwort von iasi:
Mehr Auflösung und höhere Frameraten - da sind wir dann eben nicht mehr nur bei der Speichergröße.
Schon bei 4k/60p streichen viele Speicher bei 3:1 RAW die Flagge.
Man muss also stärker komprimieren, will man z.B. 8k/60p wegschreiben.
Auch in ProRes HQ kommen übrigens reichlich Daten zusammen, wenn man einen 2 Stunden-Vortrag in 4k aufnimmt.
version 2 von HEVC reicht bis 444 16bit.
Warum sollte z.B. Main 4:2:2 12 nicht für"s Grading geeignet sein?
Weil der Komprimierungsalgorithmus besser arbeitet, als der des ollen ProRes?
Antwort von rudi:
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.
Antwort von Jörg:
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...
Antwort von Jott:
iasi hat geschrieben:
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?
Antwort von iasi:
Jott hat geschrieben:
iasi hat geschrieben:
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.
Antwort von Jott:
Der Genießer schmunzelt und schweigt.
Antwort von Kamerafreund:
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.
Antwort von Jott:
Sonys professionelles XAVC/XAVC-L gibt es schon seit 2012 (basierend auf H.264), so neu ist das also auch nicht gerade. Panasonic hatte sein AVC-Intra sogar schon viel früher. Wer mit H.264 heute noch Probleme hat, der muss eigentlich in einem Technikmuseum feststecken.
Sonys Nachfolger namens XEVC (basierend auf H.265) kommt noch dieses Jahr oder Anfang 2020 (NAB?). Wegen Sonys Marktmacht im Consumer- und vor allem auch professionellen Bereich wird das sicher keine Spielerei bleiben. In Mobiltelefonen ist H.265 ja auch schon millionenfach Standard.
Wie auch immer: man sollte sich doch wirklich ein Produktionsformat aussuchen, das man ohne Wandlung bearbeiten und archivieren kann. Alles andere ist Kokolores, es sei denn, einem ist langweilig.
Antwort von iasi:
Jott hat geschrieben:
Der Genießer schmunzelt und schweigt.
Aha - dann grinst du deinen Kunden also nur stumm an, wenn er fragt, warum es denn nur in HD auf seinem UHD-TV abspielt, was er bei dir bestellt hat. ;):)
Antwort von Frank Glencairn:
LOL - ist noch nicht so lange her, da haben die ganzen DSLR-Helden, die H264 oder ähnliches auf ihren Mühlen hatten, die Hersteller jahrelang in jedem Forum um raw und ProRes angebettelt, weil sie ja sonst überhaupt nicht vernünftig arbeiten könnten.
Da wurden Kameras gehackt undwasnichtalles für Kopfstände mit externen Recorden gemacht. Und jetzt....
mimimimi so viele Daten, das geht ja gar ned, ich will mein H264 zurück
Antwort von Kamerafreund:
Gut beobachtet! Und noch immer wird stattdessen mit mpeg2 gearbeitet. Erst kommt der Codec, dann Kameras mit dem Codec, dann die Hardwareunterstützung und Jahre später wird es vielleicht adaptiert. Dass gleich auf xevc umgestellt wird, wage ich zu bezweifeln.
Jott hat geschrieben:
Sonys professionelles XAVC/XAVC-L gibt es schon seit 2012 (basierend auf H.264), so neu ist das also auch nicht gerade. Panasonic hatte sein AVC-Intra sogar schon viel früher. Wer mit H.264 heute noch Probleme hat, der muss eigentlich in einem Technikmuseum feststecken.
Sonys Nachfolger namens XEVC (basierend auf H.265) kommt noch dieses Jahr oder Anfang 2020 (NAB?). Wegen Sonys Marktmacht im Consumer- und vor allem auch professionellen Bereich wird das sicher keine Spielerei bleiben. In Mobiltelefonen ist H.265 ja auch schon millionenfach Standard.
Wie auch immer: man sollte sich doch wirklich ein Produktionsformat aussuchen, das man ohne Wandlung bearbeiten und archivieren kann. Alles andere ist Kokolores, es sei denn, einem ist langweilig.
Antwort von Kamerafreund:
Und nochmal die Frage an alle: Hat irgendwer Mal Resolve Nur mit Quicksync ohne gesonderte Grafikkarte getestet? Bitte meldet euch! :))
Antwort von iasi:
"Frank Glencairn" hat geschrieben:
LOL - ist noch nicht so lange her, da haben die ganzen DSLR-Helden, die H264 oder ähnliches auf ihren Mühlen hatten, die Hersteller jahrelang in jedem Forum um raw und ProRes angebettelt, weil sie ja sonst überhaupt nicht vernünftig arbeiten könnten.
Da wurden Kameras gehackt undwasnichtalles für Kopfstände mit externen Recorden gemacht. Und jetzt....
mimimimi so viele Daten, das geht ja gar ned, ich will mein H264 zurück
aha - du bleibst also bei ProRes HQ, wenn dir stattdessen HEVC Main
4:2:2 12 oder gar Main 4:4:4 12 geboten wird?
Also lieber gute olle dicke 10bit 4:2:2 statt schlanke 12bit 4:2:2?
Also ich gehe lieber auch mal mit der Zeit. Es gibt schließlich mittlerweile elegantere Berechnungen, die zwar mehr Rechenleistung fordern, aber eben auch bessere Ergebnisse liefern.
Ach ja - es ging damals vor allem um mehr als 8bit mit 25 MBps.
Antwort von Frank Glencairn:
Ich dreh seit mindestens 7 Jahren quasi ausschließlich raw (Arri, Red, BM) - warum sollte ich da einen Rückschritt zu long GOP Codecs machen?
Und nein, Datenraten interessieren mich kein bisschen, solange die Medien jeden Tag größer, schneller und billiger werden.
Antwort von mash_gh4:
Kamerafreund hat geschrieben:
Und nochmal die Frage an alle: Hat irgendwer Mal Resolve Nur mit Quicksync ohne gesonderte Grafikkarte getestet? Bitte meldet euch! :))
unter linux startet das zeug ohne nvidia-karte nichteinmal, aber unter mac und windows hat es zumindest irgendwanneinmal funktioniert, was ja marketingtechnisch eh groß ausgeschlachtet wurde:
das decodieren der videofiles bzw. entsprechende hw-unterstützung ist aber natürlich nur eine sache, die grafikkarten werden ja auch für andere operationen benötigt. die meisten berechnungen beim colorgraden benötigen zwar gar nicht so übermäßig viel rechenleistung in relation zu anderen aufgabenstellungen, trotzdem kann es auch in dieser hinsicht gleich einmal eng werden, was allerdings im falle vom resolve leider meist eher mit dem recht unberechbaren bzw, ressourcenverschwendendem GPU speichermanagment zu tun hat...
Antwort von iasi:
"Frank Glencairn" hat geschrieben:
Ich dreh seit mindestens 7 Jahren quasi ausschließlich raw (Arri, Red, BM) - warum sollte ich da einen Rückschritt zu long GOP Codecs machen?
Und nein, Datenraten interessieren mich kein bisschen, solange die Medien jeden Tag größer, schneller und billiger werden.
Wie schon gesagt: Wer einen 2 Stunden-Vortrag oder ein Konzert filmt, wird sich die Frage schon stellen, ob er das in Raw oder vielleicht doch mit einem modernen effizienten Codec tut. Zumal, wenn mehrere Kameras parallel zum Einsatz kommen sollen.
Antwort von Framerate25:
iasi hat geschrieben:
"Frank Glencairn" hat geschrieben:
Ich dreh seit mindestens 7 Jahren quasi ausschließlich raw (Arri, Red, BM) - warum sollte ich da einen Rückschritt zu long GOP Codecs machen?
Und nein, Datenraten interessieren mich kein bisschen, solange die Medien jeden Tag größer, schneller und billiger werden.
Wie schon gesagt: Wer einen 2 Stunden-Vortrag oder ein Konzert filmt, wird sich die Frage schon stellen, ob er das in Raw oder vielleicht doch mit einem modernen effizienten Codec tut. Zumal, wenn mehrere Kameras parallel zum Einsatz kommen sollen.
Das würde ich so nicht unterschreiben. Kommt auf Dein System und Deinen Workflow an.
Wenn beides auf voll anwendbarer Basis ausgelegt sind, ist volles Material immer vorzuziehen!
Antwort von mash_gh4:
neben der intel quicksync lösung, die ja mehr für desktop und consumer anwendungen gedacht ist, gibt's von diesem hersteller übrigens auch noch eine andere video-de/encoding library schiene, die mehr für wirklich starke multicore server und data center anwendungen ausgelegt ist:
Wie schon gesagt: Wer einen 2 Stunden-Vortrag oder ein Konzert filmt, wird sich die Frage schon stellen, ob er das in Raw oder vielleicht doch mit einem modernen effizienten Codec tut. Zumal, wenn mehrere Kameras parallel zum Einsatz kommen sollen.
Die letzten beiden Konzertproduktionen (Jimmy Kelly & the Street Orchestra) haben wir mit einer RED und 4 BM Kameras gemacht - natürlich alles raw - warum auch nicht?
Antwort von Jott:
iasi hat geschrieben:
Jott hat geschrieben:
Der Genießer schmunzelt und schweigt.
Aha - dann grinst du deinen Kunden also nur stumm an, wenn er fragt, warum es denn nur in HD auf seinem UHD-TV abspielt, was er bei dir bestellt hat. ;):)
Wie kommst du auf HD? Kunden interessiert 4K zwar nicht die Bohne, wir drehen aber trotzdem alles in 4K, wegen der Vorteile in der Post Production. Nur halt nicht in raw oder ProRes, wenn es Quatsch ist. Die Welt da draußen ist um einiges vielfältiger, als dich deine Scheuklappen vermuten lassen! :-)
Antwort von Jott:
Kamerafreund hat geschrieben:
Dass gleich auf xevc umgestellt wird, wage ich zu bezweifeln.
Natürlich wird da nichts umgestellt, da würde der hiesige MPEG 2-Broadcaster ja unter lebensbedrohender Schnappatmung leiden. In zehn Jahren vielleicht.
Aber wenn man nach Japan schaut: die brauchen dort robuste und standardisierte 4K- und 8K-Aufzeichnung in ihren EB-Schultercams. Da wird Sony mit XEVC punkten können.
Und im Kleinen wird es bald Camcorder und Spiegellose geben, die mit gewohnt winzigen Datenraten erweiterte Möglichkeiten bieten.
Passt schon! :-)
Antwort von Jost:
Kamerafreund hat geschrieben:
Und nochmal die Frage an alle: Hat irgendwer Mal Resolve Nur mit Quicksync ohne gesonderte Grafikkarte getestet? Bitte meldet euch! :))
Ja, ist ein Lenovo-Firmen-Notebook, auf das ich mir vom Admin Resolve free habe aufspielen lassen. Intel 2-Kerner mit 620er. Für den absoluten Notfall. Wurde in DNxHR LT gewandelt, lief es unter Resolve 15.
Habe dann auf Version 16 updaten lassen. Resolve startete nicht mehr. Fehlermeldung war, dass eine Grafikkarte fehlte. Die 620er wurde nicht erkannt.
Ich vermag aber nicht zu sagen, ob
a. es an der Resolve Free-Version und/oder
b. an der frühen 16er Beta lag.
Hatte dann die Faxen dicke.
Grundproblem bei Intel ist, dass sich seit Jahren nicht viel an der Rechenleistung ihrer IGPUs getan an. Die 630er ist das stärkste Modell. Sie wird vom 2- bis zum aktuellen 8-Kerner verbaut.
Daneben gab es nach meiner Erinnerung einige halbherzige Versuche, die Peripherie zu stärken. Intel hatte eigentlich vor gehabt, die integrierten GPUs im Herbst 2018 zu modernisieren. Es sollte auch ein optimiertes Quicksync implementiert werden.Was bekanntlich nicht geschehen ist.
Am Ende ist von Intel dann eine Vega-Grafikeinheit von AMD eingebaut worden, die deutlich stärker als die 630er ist. Ob die integrierte AMD-Vega von Resolve überhaupt erkannt würde, vermag ich nicht zu sagen.
Die Vega-IGPUs findest Du bei Intel und AMD in den G-Prozessoren. Topmodell ist der Ryzen 5 3400G. Rein von der CPU-Leistung entspricht der etwa einem Intel 6700K. Vierkerner mit SMT.
Antwort von DeeZiD:
"Frank Glencairn" hat geschrieben:
Niemand hat dropped Frames, wenn er nicht die völlig falschen Medien benutzt.
Resolve 16 Studio laesst sich auf meinen Maschinen (1080 Ti oder 2080 MaxQ) selbst mit 6K 10Bit Material der GH5 ausbremsen... Selbes Material ist unmoeglich in Premiere zu bearbeiten.
Kannst gerne an die Entwickler weiterleiten. Haben fantastische Arbeit geleistet, was die Optimierung angeht. :)
Antwort von Knut55:
verstehe das Gedöns um HEVC nicht. HEVC 4k/60p vom Iphone kann ich in iMovie ( ja, ist ein primitives Drecksprogramm) auf einem ollen IPAD Pro Gen1 mit Vollgas hin und her scrubben, aber am PC ruckts das mir schlecht wird. Scheint also nicht an HEVC zu liegen.
Antwort von Grauer Tiger:
Knut55 hat geschrieben:
verstehe das Gedöns um HEVC nicht. HEVC 4k/60p vom Iphone kann ich in iMovie ( ja, ist ein primitives Drecksprogramm) auf einem ollen IPAD Pro Gen1 mit Vollgas hin und her scrubben, aber am PC ruckts das mir schlecht wird. Scheint also nicht an HEVC zu liegen.
Nein liegt nicht an HEVC. Liegt daran, dass dein iPad das vorher im Hintergrund transcodiert ;-) Nativ abspielen ginge genau so gut/schlecht wie am PC. Daher dieser Trick von Apple. Wenn du das am PC auch transcodierst, läuft das auch flüssig.
Antwort von mash_gh4:
DeeZiD hat geschrieben:
Resolve 16 Studio laesst sich auf meinen Maschinen (1080 Ti oder 2080 MaxQ) selbst mit 6K 10Bit Material der GH5 ausbremsen...
das liegt daran, dass es sich dabei vermutlich um 10bit h264 od. 4:2:2 footage handeln dürfte, für das es im normalfall keine hardwarebeschleunigung gibt (außer in div. sony und panasonic studio-hardware). mit 10bit h.265 4:2:0 dagegen hättest du dieses problem nicht, obwohl die komprimierung komplizierter zu decodieren ist -- wobei allerdings die größe (>UHD) im hinblick auf die hardwareunterstützung auch noch eine rolle spielen könnte. mittlerweile kommt aber neuere hardware mit derartigem zeug in der regel ganz gut klar.
Antwort von Jott:
"Grauer Tiger" hat geschrieben:
Nein liegt nicht an HEVC. Liegt daran, dass dein iPad das vorher im Hintergrund transcodiert ;-) Nativ abspielen ginge genau so gut/schlecht wie am PC. Daher dieser Trick von Apple.
Und das weißt du woher? Mach mal selber mit aktuellen Geräten und iOS 12. Da transcodiert nichts, wann denn? Es gibt auch keinen zusätzlichen Speicherbedarf, was dann ja der Fall wäre. Leicht nachzuprüfen für jedermann, dass dem nicht so ist.
Glaube Knut.
Antwort von motiongroup:
Alle Geräte mit ab Apple A9 Chip haben das h265 Decoding HW-Seitig implementiert... 8bit Encoding seit A10 welches auch im T2 Chip der Macs implementiert ist damit die iMac Pros die ja KEINE QSYNC Einheit verbaut haben HW Encodieren können.. aber nur in 8Bit..
Antwort von Axel:
Diese "angezogene Handbremse"-Geschichte kommt mir von H.264 bekannt vor. Ich nannte es damals "Schwimmen in Pattex". Es gibt drei Lösungsansätze:
1. Mit Proxy schneiden.
2. Neue Hardware (Faustregel: heute teuer, morgen Standardausstattung).
3. Auf HEVC verzichten.
Antwort von wolfgang:
4. warten bis die nvidia Karten mit mehr NVDEC Einheiten kommen. 2 davon hat heute gerade die Quadro RXT 5000, und die hat noch ein schmäleres Interface als die Consumervariante 2089Ti.
5. warten bis vermutlich gegen Ende des Jahres Intels neue iGPUs mit 10bit 422 Support kommen. Hoffentlich auch in 10, 14 und 16 Kernern? Angeblich auch in Xeons wie man so hört.
Teuer auf jeden Fall.
Antwort von Jott:
Bei Problemen: 1. und 3. sind kostenlos und sofort verfügbar.
Antwort von vaio:
"Frank Glencairn" hat geschrieben:
Ich dreh seit mindestens 7 Jahren quasi ausschließlich raw (Arri, Red, BM) - warum sollte ich da einen Rückschritt zu long GOP Codecs machen?
Und nein, Datenraten interessieren mich kein bisschen, solange die Medien jeden Tag größer, schneller und billiger werden.
Es ist nun wirklich so, dass alle paar Jahre die selbe Problematik da ist. Erst mit MPEG2 und DV, dann h264 und jetzt aktuell mit h265. Die Bearbeitung wird vermutlich erst mit der nächsten Hard-/Software-Generation ohne Transcodierung optimal laufen. Bei den verfügbaren Festspeicherkapazitäten und /-Preisen ist es heute sicherlich garnicht so weit her geholt, dass Material unkomprimiert bearbeiten zu wollen. Auch für die Zukunft. Allerdings bleibt für mich eine wesentliche Frage dabei unbeantwortet. Das ist der Arbeitsspeicher. Wie verhält es sich damit? Wie flüssig der Workflow mit den eingelesenen großen Dateien sein wird - oder eben auch nicht - ist jedenfalls auch Programmabhängig zu sehen. Dennoch ist es m.M. ein nicht vernachlässigter Faktor, von dem der User nichts schreibt. Dabei meine ich nicht die üblichen temporären Dateien, die ein Schnittprogramm anlegt, sondern ich meine die Programmstabilität und -Geschwindigkeit bezüglich der großen Files. Bearbeitet er - um mit seiner Sprache zu sprechen - nur "mimimini- Projekte", oder liest er immer nur einen gewissen Teil an Sequenzen ein? Das würde den Workflow aber entscheidend (negativ) beeinflussen. Oder spielt das alles keine Rolle? Eine (Arbeits-) Speicherauslagerung auf SSD's sehe ich nicht als Alternative, da man auch hier einen gewissen Geschwindigkeitsverlust - je nach Anbindung - in Kauf nehmen muss. Abgesehen davon, dass der Vorteil der verfügbaren Kapazitäten und günstigen Preise dahin wäre. Ein Raid-System bietet als weitere mögliche Lösung ebenfalls keinen nennenswerten Geschwindigkeitvorteil, da die "Köpfe" ständig mit dem suchen und schreiben beschäftigt sind.
Ist die Lösung für einen "normalen User" wie mich wirtschaftlich interessant, oder garnicht darstellbar? Wie sieht die Lösung aus und welche(s) Programm(e) sind empfehlenswert? Bitte kann jemand mal einen Tipp geben.
