slashCAM Forum

Habe mal ein 2K Schuß in 24p mit der FS700 intern und mit Inferno ProRes LT gemacht und dabei ist mir folgende fiese Sache aufgefallen.
Beim ProRes gibt es an bestimmten Stellen fiese bunte Klötzchen, hier mal bei einer Vergrößerung von 1000%.

Dagegen ist das lasche 24Mbit AVC erstaunlich clean, was ja meine These wieder untermauert, dass das interne AVC echt richtig gut ausschaut.
Werde das noch mal mit DNxHD probieren. Weiß jemand ob das am Codec oder Inferno liegt?

Danke! :-)

klusterdegenerierung hat geschrieben: ↑Do 30 Mai, 2024 19:16 Habe mal ein 2K Schuß in 24p mit der FS700 intern und mit Inferno ProRes LT gemacht und dabei ist mir folgende fiese Sache aufgefallen.
Beim ProRes gibt es an bestimmten Stellen fiese bunte Klötzchen, hier mal bei einer Vergrößerung von 1000%.

Dagegen ist das lasche 24Mbit AVC erstaunlich clean, was ja meine These wieder untermauert, dass das interne AVC echt richtig gut ausschaut.
Werde das noch mal mit DNxHD probieren. Weiß jemand ob das am Codec oder Inferno liegt?

Danke! :-)

ProRes LT ist ein bisschen wenig für die Datenrate. ProRes 422 oder ProRes 422 HQ sollte es schon sein.

Ja das kann sein, wobei die 4K variante in LT, wie ich gerade erst gesehen habe, dieses Problem nicht hat.
Dann ist es entweder die 2K oder die Auflösung. Das werde ich mal durchspielen.

LT ist eigentlich nur ein "Layout/Offline" Codec, aber nix zur Aufnahme - dafür sollte man immer das hochwertigste nehmen, was die Kamera her gibt.

Hatte ich mir auch gedacht, aber als ich 771Mbit bei 4k 120p in mediainfo gelesen habe, hatte ich mir gedacht das es soo schlecht nicht sein kein, denn das wären ja ca. 150Mbit bei 24p, zum 24Mbit intern ja immerhin ein Unterschied. ;-)

ProRes hat vereinfacht gesagt mehr Ähnlichkeit zu M-JPEG als zu H.264 AVC. Es ist viel einfacher aufgebaut, was bei eher geringen Datenraten schneller zu Qualitätsverlusten führt.

Man muss aber auch sagen, dass H.264 und die Nachfolger sehr darauf optimiert sind, unter erheblichem Aufwand quasi jedes verzichtbare Bit einzusparen.

Und wie sieht es mit ProRes HQ aus?

Ansonsten, "clean" HDMI-Ausgabe (bezogen nicht auf keine Menü auf externen Bildschirm usw. sondern): keine kamerainterne Verarbeitung wie z.B. Chroma NR.

ProRes LT würde ich nicht für wichtige Aufnahmen verwenden. Dasselbe gilt für die enstsprechende DNxHD-Seite. Unbrauchbar (finde ich nach Tests)!

Dann lieber einen guten Long GOP Codec mit vermutlich sogar weniger Datenrate, aber klar besserem Bild.

Ab ProRes HQ ist man ganz gut gerüstet für ein gutes und auch noch bearbeitbares Bild (z. B. auch entrauschen, falls man den glatteren Look der GOP-Codecs (H.264, H.265) bevorzugt, aber am Ende der Kette landet das Video ja normalerweise sowieso dort) und so wird es in Kameras , die es integriert haben, auch angeboten.
Danach kommt meist schon RAW (wenn nicht intern, dann extern).
ProRes ist ähnlich wie (M-)JPEG (wurde schon erwähnt) und "All-i", also lassen sich die Datenraten zur Voraus-Einschätzung des Bildes nicht direkt mit GOP-Codecs vergleichen, die viel stärker komprimieren und dabei die (visuelle) Bildqualität halten - ausser unter Codec-Stress bereits bei der Aufnahme wie bewegte Wasseroberflächen, zitterne Laufblätter im Wind, sehr schnelle Bewegung (z. B. in Action Cams) etc.. Und dann ist da noch das Editing mit schwächeren Computern und die Frage: Ruckelt es, oder nicht? versus die Frage: Habe ich genug Speicherplatz für grosse ProRes-Files?

ProRes ist eigentlich ein Primitiv-Codec mit Codec-Technologie aus den 90ern Jahren, bei dem gute Bildqualität nur durch extrem hohe Bitraten erzielt wird.

Weil er so primitiv ist, erfordert er kaum Rechenleistung beim Abspielen, selbst bei hohen Auflösungen, hohen Bittiefen und wenn nur per CPU decodiert wird.

Das ist auch der einzige Grund, weshalb ProRes eingesetzt wird.

Das 2K Raw > ProRes der FS700 ist einfach bescheiden weiss auch nicht ob es an Sony oder Atomos liegt. Ist bei meinem Shogun7 auch so.

Prores LT habe ich noch kein einziges Mal benutzt, 422HQ ist der Standart, 444/4444 wenn es mehr sein muß oder der Alphakanal benötigt wird und 4444XQ kam auch schon vor, wenn ein Kunde glaubt das würde sich irgendwie im Ergebnis wiederspiegeln...

Ich habe dort in der Liste bei 2K geguckt und fand ca. 200Mbit dann nicht soo wenig, aber gut, wenn der Codec so oll ist und viel Data braucht, dann doch besser HQ.
Und DHxHD / DHxHR ist noch unbrauchbarer?

https://en.wikipedia.org/wiki/Apple_ProRes

klusterdegenerierung hat geschrieben: ↑Do 30 Mai, 2024 23:16 Ich habe dort in der Liste bei 2K geguckt und fand ca. 200Mbit dann nicht soo wenig, aber gut, wenn der Codec so oll ist und viel Data braucht, dann doch besser HQ.
Und DHxHD / DHxHR ist noch unbrauchbarer?

https://en.wikipedia.org/wiki/Apple_ProRes

Vergleichbar (habe es früher mit DNxHD mal getestet und mit ProRes verglichen).

Aber wie geschrieben: Beide fallen optisch nur auseinander, wenn die Datenraten zu gering sind -> wenn's geht, die HQ-Variante verwenden (Datenraten hier: https://de.wikipedia.org/wiki/ProRes)!

Ich mag diese Oldie-Codecs (cantsin nennt sie Primitiv-Codecs, sie werden aber auch als robuste Codecs bezeichnet) - als Mac User ProRes -, wegen ihrer Perfomance am (i)Mac: Mit keinem anderen Codec lässt sich so schnell scrollen (die Anzeigegeschwindigkeit der Bilder ist nur durch die eigene Scrollgeschwindigkeit begrenzt), wie mit ProRes (HQ) - und das gilt (bei mir am 8Kern-iMac Pro mit 8GB-Grafik) selbst für UHD_25p mit ProRes HQ in 1:1-Pixel-Ansicht mit QuickTime X.

klusterdegenerierung hat geschrieben: ↑Do 30 Mai, 2024 23:16 Ich habe dort in der Liste bei 2K geguckt und fand ca. 200Mbit dann nicht soo wenig, aber gut, wenn der Codec so oll ist und viel Data braucht, dann doch besser HQ.
Und DHxHD / DHxHR ist noch unbrauchbarer?

https://en.wikipedia.org/wiki/Apple_ProRes

2k LT hat keine 200mbit, eher 100.

Kommt drauf an ob FHD oder 2K und ob 25 oder 50.

klusterdegenerierung hat geschrieben: ↑Fr 31 Mai, 2024 00:31 Kommt drauf an ob FHD oder 2K und ob 25 oder 50.

Natürlich, aber oben steht 2k bei 24fps.

cantsin hat geschrieben: ↑Do 30 Mai, 2024 22:46 ProRes ist eigentlich ein Primitiv-Codec mit Codec-Technologie aus den 90ern Jahren, bei dem gute Bildqualität nur durch extrem hohe Bitraten erzielt wird.

Weil er so primitiv ist, erfordert er kaum Rechenleistung beim Abspielen, selbst bei hohen Auflösungen, hohen Bittiefen und wenn nur per CPU decodiert wird.

Das ist auch der einzige Grund, weshalb ProRes eingesetzt wird.

Außer für eine perverse Menge an Material oder die einen Online-Transfer in akzeptabler Zeit unmöglich macht, sehe ich heutzutage keinen Grund sich mit Codecs rumzuplagen, die selbst schnelle Computer zum Stottern bringen oder einfach technisch nicht praktikabel sind.
Ich habe ausserdem mal Prores 422HQ von abgetastetem 35mm Material mit sichtbarem Grain getestet was die Generationsverluste angeht - 10-faches rekodieren führte zu einer minimalen Zunahme von rotstichigem Rauschen, das aber selbst mit einer harten Maske direkt durchs Bild nicht zu erkennen war. Solange nichts kommt, was die Vorteile dieses (wie du zu recht sagtest - alten) Codecs übertreffen, wird er wohl eine Konstante bleiben.

Zumal, wenn man irgendwas mit Grain in der Post machen will, kommt man mit AVC Codecs sowieso nicht weit.
Was allerdings für Internetvideo auch wieder egal ist ;)

macaw hat geschrieben: ↑Fr 31 Mai, 2024 09:35 Solange nichts kommt, was die Vorteile dieses (wie du zu recht sagtest - alten) Codecs übertreffen, wird er wohl eine Konstante bleiben.

Der Punkt ist ja, das alles, was mit ProRes geht (inkl. 12bit 4:4:4 Intraframe) auch mit h265 geht, und zwar mit weniger Qualitätsverlusten bei identischer Bitrate, bzw. messbar gleicher Qualität mit niedrigerer Bitrate. Du kannst mit h265 sogar lossless encodieren, was garantiert besser ist als ProRes.

Der einzige Grund, warum das niemand macht, ist, dass ProRes weniger Resourcen beim En- und Decodieren braucht (wobei ich mir nicht sicher bin, ob die Unterschiede zu h265 All-I bei hohen Bitraten noch so dramatisch sind), und außerdem bei h265 im Gegensatz zu ProRes kein harter Mindeststandard festgelegt ist.

Wenn Du also z.B. in einem kollaborativen Workflow mit anderen Post-Buden bist, und ihr eignet Euch auf ProRes HQ als Codec, ist praktisch garantiert, dass es keinen Müll geben wird.

Während bei h265 nur jemand mal versehentlich die 10- oder 12bit-Option vergessen muss oder aus Schlampigkeit eine zu niedrige Bitrate wählen kann, und dann nur noch Streaming-Qualität übrigbleibt.

Prinzipiell könnte man das alles vermeiden, wenn es für h265 genau wie bei ProRes und DNxHR definierte Qualitätsstufen für die Postproduktion gäbe, also etwa [hypothetisch] "h265 Pro LT" mit 10bit 4:2:2 und 150 Mbit/s für FullHD, "h265 Pro HQ" mit 300 Mbit/s und "h265 Pro HQX" mit 500 Mbit/s 12bit 4:4:4, und das dann entsprechend als Menüpunkte integriert in alle gängigen NLEs und sonstige PostPro-Software.

Kann man das losless-h265 mit Bordmitteln aus Resolve ausgeben?

dienstag_01 hat geschrieben: ↑Fr 31 Mai, 2024 14:26 Kann man das losless-h265 mit Bordmitteln aus Resolve ausgeben?

Nee... Schreib' mal an Blackmagic... Wobei die h265-Unterstützung in Resolve sowieso lückenhaft ist, weil BM die Patent-Lizenzkosten für h265 vermeidet und daher nur die limitierten On-Board-h265-Codecs von Windows und MacOS verwendet.

Aber es sollte mit Voucoder gehen, das ja nur ein Plugin für ffmpeg ist. Mit ffmpeg (bzw. darauf basierenden Tools wie ShutterEncoder) kann man h265 lossless problemlos encodieren.

cantsin hat geschrieben: ↑Fr 31 Mai, 2024 14:28

dienstag_01 hat geschrieben: ↑Fr 31 Mai, 2024 14:26 Kann man das losless-h265 mit Bordmitteln aus Resolve ausgeben?

Nee... Schreib' mal an Blackmagic... Wobei die h265-Unterstützung in Resolve sowieso lückenhaft ist, weil BM die Patent-Lizenzkosten für h265 vermeidet und daher nur die limitierten On-Board-h265-Codecs von Windows und MacOS verwendet.

Aber es sollte mit Voucoder gehen, das ja nur ein Plugin für ffmpeg ist. Mit ffmpeg (bzw. darauf basierenden Tools wie ShutterEncoder) kann man es problemlos encodieren.

Seltsamerweise vergisst du solche „Nebensächlichkeiten“ gern.

dienstag_01 hat geschrieben: ↑Fr 31 Mai, 2024 14:32 Seltsamerweise vergisst du solche „Nebensächlichkeiten“ gern.

Nee, ich hatte ja weiter oben geschrieben, dass das Problem die Standardisierung (h265 mit definierten Qualitätsstandards für PostPro) sowie die Implementierung in GUIs ist (Integration dieser Qualitätsstandards in die GUIs der Postpro-Software).

Wobei Resolve ja sowieso bei Codecs sehr wählerisch ist. Unter Windows und Linux geht mit Resolve ja auch kein ProRes-Export, also scheidet da eigentlich auch ProRes als Workflow-Codec aus.

Dafür gibt’s dann unter Windows den vergleichbaren DNxHR. Und ein h265, der losless o.ä. ist, ist mir überhaupt noch nie untergekommen, auch in anderen Applikationen nicht. Wahrscheinlich übersehen.
(H264 hat ja das gleiche Problem)

Wirklich performant ist ProRes mit Grafik-Beschleunigung, auf den größeren M-Chips oder mit der 2019 MP „Afterburner“-Karte. Auf M1 Mini war H.265 schneller als ProRes (!), auf Studio Max verdoppelt es in etwa die mögliche Leistung, z.B. bei Effekte-Echtzeit in Resolve.

Wenn ich mit Resolve arbeiten würde, würde ich das Mainconcept Plugin probieren

dienstag_01 hat geschrieben: ↑Fr 31 Mai, 2024 14:56 Dafür gibt’s dann unter Windows den vergleichbaren DNxHR.

Oder Cineform, was natürlich nochmal besser ist weil Wavelet - also quasi in der RED-Code Liga.
Nehm ich eigentlich für alles, was nicht unbedingt unkomprimiert sein muß.

Bluboy hat geschrieben: ↑Fr 31 Mai, 2024 15:22 Wenn ich mit Resolve arbeiten würde, würde ich das Mainconcept Plugin probieren

Hab das gerade auf MacOS ausprobiert. Zumindest die Testversion kann ausschließlich in 16:9 und 4:3 ausgeben und produziert bei mir Fehler im Audio-Rendering. Ergebnisse sind völlig unbrauchbar. Würde ich mir jetzt erstmal eher nicht kaufen.

Sicki hat geschrieben: ↑Fr 31 Mai, 2024 17:20

Bluboy hat geschrieben: ↑Fr 31 Mai, 2024 15:22 Wenn ich mit Resolve arbeiten würde, würde ich das Mainconcept Plugin probieren

Hab das gerade auf MacOS ausprobiert. Zumindest die Testversion kann ausschließlich in 16:9 und 4:3 ausgeben und produziert bei mir Fehler im Audio-Rendering. Ergebnisse sind völlig unbrauchbar. Würde ich mir jetzt erstmal eher nicht kaufen.

Mir fällt auch keine einziger Grund ein warum man das nutzen sollte.

Frank Glencairn hat geschrieben: ↑Fr 31 Mai, 2024 15:38

dienstag_01 hat geschrieben: ↑Fr 31 Mai, 2024 14:56 Dafür gibt’s dann unter Windows den vergleichbaren DNxHR.

Oder Cineform, was natürlich nochmal besser ist weil Wavelet - also quasi in der RED-Code Liga.
Nehm ich eigentlich für alles, was nicht unbedingt unkomprimiert sein muß.

Cineform ist allerdings proprietär und wird vom Eigentümer GoPro AFAIK nicht mehr gepflegt. Läuft das z.B. überhaupt nativ auf Macs mit M-Chip?!?

Während es von ProRes und DNxHR vollständige Open Source-Implementationen gibt (als Teil der libavcodec, die u.a. von ffmpeg und mpv genutzt wird), so dass da die Abspielbarkeit praktisch bis zum Ende der Menschheit gesichert ist, auch wenn Apple und Avid irgendwann die Entwicklung und den Software-Support der Codecs einstellen sollten.

Cineform wurde schon vor lager Zeit als SMPTE ST 2073 VC-5 standardisiert, und läuft auf so ziemlich jedem Rechner völlig problemlos.

GoPro hat CineForm bereits 2017 als open source unter MIT License und Apache License 2.0 freigegeben.

Frank Glencairn hat geschrieben: ↑Fr 31 Mai, 2024 18:22 Cineform wurde schon vor lager Zeit als SMPTE ST 2073 VC-5 standardisiert, und läuft auf so ziemlich jedem Rechner völlig problemlos.

GoPro hat CineForm bereits 2017 als open source unter MIT License und Apache License 2.0 freigegeben.

Danke für die Korrektur, hatte ich nicht auf dem Schirm!

Aaalsoo!
Eben noch mal ein paar Prores Tests gemacht und auch in 422 HQ lassen sich diese fiesen Artefakte finden!!!

Dabei ist es egal ob es 24p oder 240p ist, allerdings ist der Effekt in 240p natürchlich größer.
Das lässt vermuten das es an 2K liegt, denn bei 4K tritt es nicht auf!

Leider kann man Raw Slomo nicht gleichzeitig mit Intern aufzeichnen, ich muß also das gleiche Morgen nochmal mit internem Slomo probieren.
Wenn es dann intern auch auftritt, dann liegt es ja wohl eher an Slomo, denn bei 24p intern taucht es nicht auf und 4K intern kann sie ja leider nicht!

Bin schon sehr gespannt, denn es könnte ja auch der Infrno bzw das ProRes sein was das footage vergeigt.

So hier noch mal 24p in AVC intern und in ProRes 422HQ!
Shit, es ist also egal ob Slomo oder nicht, zumindest was das ProRes anbelangt!

Könnte aber auch daran liegen, dass bei AVC-Aufnahme Objektivkorrekturen greifen, die auch die starken CAs/das purple fringing wegfilteren, während die ProRes-Aufnahme weniger gefiltert ist und die CAs den Codec stressen.