slashCAM
Administrator
Administrator
Beiträge: 11259

Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von slashCAM » Di 02 Jul, 2019 10:45


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



Hier geht es zu Artikel auf den slashCAM Magazin-Seiten:
Erfahrungsberichte: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019




mash_gh4
Beiträge: 2993

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von mash_gh4 » Di 02 Jul, 2019 11:14

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.




dosaris
Beiträge: 872

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von dosaris » 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.




rudi
Administrator
Administrator
Beiträge: 1158

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von rudi » Di 02 Jul, 2019 12:00

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.




rudi
Administrator
Administrator
Beiträge: 1158

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von rudi » Di 02 Jul, 2019 12:03

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.




iasi
Beiträge: 13269

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von iasi » Di 02 Jul, 2019 12:08

mash_gh4 hat geschrieben:
Di 02 Jul, 2019 11:14
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.




mash_gh4
Beiträge: 2993

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von mash_gh4 » Di 02 Jul, 2019 12:26

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.




Kamerafreund
Beiträge: 347

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von Kamerafreund » Di 02 Jul, 2019 14:49

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
Beiträge: 13269

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von iasi » Di 02 Jul, 2019 15:21

mash_gh4 hat geschrieben:
Di 02 Jul, 2019 12:26
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.


https://en.wikipedia.org/wiki/High_Effi ... _licensing

Was das nun in der Praxis bedeutet: ??????




dienstag_01
Beiträge: 9568

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von dienstag_01 » Di 02 Jul, 2019 15:33

Zur Hardwareunterstützung von Nvidia erfährt man am meisten bei Nvidia selbst ;)
https://developer.nvidia.com/video-enco ... ort-matrix
4:2:2 scheint die allgemein nicht so zu interessieren.




hexeric
Beiträge: 45

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von hexeric » 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.




motiongroup
Beiträge: 2979

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von motiongroup » Di 02 Jul, 2019 17:02

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




Jörg
Beiträge: 7310

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von Jörg » Di 02 Jul, 2019 17:17

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




Kamerafreund
Beiträge: 347

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von Kamerafreund » 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..




Framerate25
Beiträge: 910

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von Framerate25 » Di 02 Jul, 2019 18:50

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 ;)
Einfach mal anders machen - alles andere gibts schon.




dienstag_01
Beiträge: 9568

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von dienstag_01 » Di 02 Jul, 2019 21:37

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




Kamerafreund
Beiträge: 347

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von Kamerafreund » 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.. ;)




dienstag_01
Beiträge: 9568

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von dienstag_01 » 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.




Kamerafreund
Beiträge: 347

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von Kamerafreund » Di 02 Jul, 2019 23:34

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.




motiongroup
Beiträge: 2979

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von motiongroup » Mi 03 Jul, 2019 04:49

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
Beiträge: 9385

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von Frank Glencairn » Mi 03 Jul, 2019 06:53

Bottom line: H264/65 sind kein Aufnahmecodecs.
Ich kann nicht verstehen, warum man sich sowas antut.




iasi
Beiträge: 13269

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von iasi » Mi 03 Jul, 2019 07:50

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.




Frank Glencairn
Beiträge: 9385

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von Frank Glencairn » 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"




iasi
Beiträge: 13269

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von iasi » Mi 03 Jul, 2019 08:00

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"




Frank Glencairn
Beiträge: 9385

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von Frank Glencairn » Mi 03 Jul, 2019 08:57

Niemand hat dropped Frames, wenn er nicht die völlig falschen Medien benutzt.




Jott
Beiträge: 16279

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von Jott » Mi 03 Jul, 2019 09:37

Was allerdings Volkssport ist.




iasi
Beiträge: 13269

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von iasi » Mi 03 Jul, 2019 10:18

Frank Glencairn hat geschrieben:
Mi 03 Jul, 2019 08:57
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.




Framerate25
Beiträge: 910

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von Framerate25 » Mi 03 Jul, 2019 10:53

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... 🧐
Einfach mal anders machen - alles andere gibts schon.




iasi
Beiträge: 13269

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von iasi » Mi 03 Jul, 2019 12:23

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?




rudi
Administrator
Administrator
Beiträge: 1158

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von rudi » Mi 03 Jul, 2019 12:37

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.




Jörg
Beiträge: 7310

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von Jörg » Mi 03 Jul, 2019 12:42

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




Jott
Beiträge: 16279

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von Jott » Mi 03 Jul, 2019 12:44

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
Beiträge: 13269

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von iasi » Mi 03 Jul, 2019 12:59

Jott hat geschrieben:
Mi 03 Jul, 2019 12:44
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.




Jott
Beiträge: 16279

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von Jott » Mi 03 Jul, 2019 13:02

Der Genießer schmunzelt und schweigt.




Kamerafreund
Beiträge: 347

Re: Mit angezogener Handbremse: H.265/HEVC Decoding und Scrubbing im Jahre 2019

Beitrag von Kamerafreund » Mi 03 Jul, 2019 13:06

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.




Social Media

       
 Aktuelle Beiträge [alle Foren]
 
» Lock&Load von Coremelt, Vergleich zu FCPX
von Sunbank - Di 8:26
» Z Cam E2G, E2C, E2-6F, E2-S6, E2-F8
von Axel - Di 8:18
» HDR Anfängerfrage zur "Leuchtkraft"
von Mediamind - Di 7:53
» Vidoe8 vs. Hi8
von Valentino - Di 1:18
» Rot ist eigentlich nicht meine Farbe
von klusterdegenerierung - Di 0:10
» Sehenswert Familie Braun
von klusterdegenerierung - Di 0:06
» Blackmagic DaVinci Resolve Micro Panel
von rvaneeden - Mo 22:30
» Was schaust Du gerade?
von roki100 - Mo 22:29
» JOKER - Teaser Trailer
von Saint.Manuel - Mo 22:23
» Sigma fp -- 4K RAW-Kamera demnächst für 1899 Dollar verfügbar
von iasi - Mo 22:23
» Blackmagic Pocket Cinema Camera 6K Erfahrung
von iasi - Mo 22:06
» Was war Eure erste Digicam?
von klusterdegenerierung - Mo 21:33
» Markt für Kleinproduzenten - ein „totes Pferd“?
von nic - Mo 21:12
» Dynamikumfang: Panasonic S1H vs Sony A7 III: V-Log vs S-Log Vollformat Vergleich
von DeeZiD - Mo 21:00
» BMPCC (original, 4K, 6K) und ext. Steuerung?
von Frank Glencairn - Mo 19:50
» Horror Kurzfilm "Witching Hour"
von -paleface- - Mo 19:47
» Sony PXW Z100
von Peter Friesen - Mo 17:52
» Was hörst Du gerade?
von klusterdegenerierung - Mo 17:48
» Lavalier Befestigung - Tips Verbrauchsmaterialien
von pillepalle - Mo 17:19
» Versteckt in vielen Hollywood Filmen: Die vier Noten des Todes
von Funless - Mo 16:21
» Mocha Pro 2020 verfügbar mit OCIO, Mega Plates und neuem Area Brush Tool
von slashCAM - Mo 14:51
» 1080/50M für Fernseher störungsanfällig?
von fabchannel - Mo 14:46
» Rolling Shutter Werte von Blackmagic, Canon, Fuji, Nikon, Panasonic, Kinefinity und Sony
von MrMeeseeks - Mo 13:22
» Frame.io plant Cloud-basierte Echtzeit-Workflows von der Kamera bis zum Schnitt
von ChillClip - Mo 13:20
» Dynamikumfang: Blackmagic Ursa Mini Pro G2 vs Panasonic S1 - 4K RAW S35 vs 10 Bit V-Log Vollformat
von Rick SSon - Mo 12:42
» Funkstrecke Audio
von K.-D. Schmidt - Mo 11:07
» Videomaterial zippen empfehlenswert?
von MarcoCGN80 - Mo 11:06
» Nikon Z50 vorgestellt: Erste spiegellose 20.9 MP APS-C Kamera mit Z-Mount, 4K Video und 30p 8MP Video Mode
von rush - Mo 10:38
» Nvidia zeigt Echtzeit Greenscreen Keyer ohne Greenscreen sowie Facetracker
von rainermann - Mo 9:59
» Die visuell besten Musikvideos
von klusterdegenerierung - So 23:37
» Audioanlage Kirche
von gunman - So 22:53
» Semiprofessioneller Camcorder von Panasonoc, überwiegend FULL HD
von holger_p - So 19:27
» Warum glauben so viele, dass Gemini Man ein Flop wird?
von Benutzername - So 16:16
» Euer Lieblings Style-Over-Substance-Film
von Benutzername - So 12:37
» Umzug mit Corel VS X3 von einem PC zu anderem
von BerndL - So 11:47
 
neuester Artikel
 
Rolling Shutter Werte von Blackmagic, Canon, Fuji, Nikon, Panasonic, Kinefinity und Sony

Wir messen schon länger die Sensor-Auslesezeiten der von uns getesteten Kameras. Nun wollen wir einmal einen ersten kommentierten Überblick wagen... weiterlesen>>

Dynamikumfang: Panasonic S1H vs Sony A7 III

Die Panasonic S1 gehört in Sachen Dynamikumfang (genauer: Belichtungsspielraum) zu den besten von uns bislang getesteten Kameras. Wie schlägt sich die populäre Sony A7 III beim Thema Dynamikumfang gegen die nochmals videoafinere Panasonic S1H? Kann der Panasonic 10 Bit Codec seine höhere Farbtiefe gegenüber dem 8 Bit Sony Codec beim Log-Material ausspielen? weiterlesen>>

neuestes Video
 

Aktuelles Video:
Deep in the Guatemalan Jungle with my FPV Drones

Hals- oder vielleicht besser gesagt rotorbrecherische Flugaufnahmen gibt es hier zu bestaunen -- extrem gekonnt lässt der offensichtlich Racing-geschulte Pilot seine kleine Drohne durch die Luft wirbeln (Danke ans Forum für den Hinsweis).