Der Osmo Pocket 3 hat ja nur 10bit 4:2:0, insofern bringt da mehr Bittiefe oder Chroma Sampling nichts.andieymi hat geschrieben: ↑Di 05 Dez, 2023 17:13 Nicht so unbedingt mit H265 wenn's drum geht was möglichst klein zu kriegen, aber hier geht's nicht um minimal fürs Web, sondern klein genug. Geht ja mittlerweile auch in 10-Bit 4:2:2, leider aus Resolve unter Mac nur Hardwarebeschleunigt(?) und Voukoder gibt's dann nur unter Windows, irgendwie wäre ein Workflow praktisch, der am Macbook und am Windows-Rechner läuft. Und nicht dann erst Recht vom DNxHR Master erfolgt.
Ich weiß, Lösung für ein unwichtiges Kanonen auf Spatzen Problem, aber irgendwie sträub ich mich gegen 8-10-Bit 4:2:0 "Mastering".
Code: Alles auswählen
ffmpeg -i input.mxf -an -c:v libx265 -x265-params lossless=1 -pix_fmt yuv422p12le output.mov
Was schwebt dir denn so vor, wenn du von Weiterverarbeitung "nach" Resolve sprichst? Für deine privaten Aufnahmen. Machst du Family-VFX ;)andieymi hat geschrieben: ↑Mi 06 Dez, 2023 10:22 Danke schon mal für eure Inputs, ich spiel da mal ein paar Sachen zurück. Bitte nicht als Mimimi verstehen, so wirklich "die" Lösung war noch nicht dabei.
Unkomprimiert Mastern und dann löschen wäre sicher einfach eine Option, dagegen spricht einfach der Zeitaufwand und eigentlich sogar das Fehlen eines klassischen "Delivery" vom Master Workflows, das Material muss nicht irgendwo im Web abspielbar sein, braucht keinem Kunden geschickt werden, theoretisch kann ich auch nur mit einem ohnehin etwas komprimierten Master leben. Hatte auch nie Probleme mit der DNxHR Kompression, bei den Datenraten finde ich im Gegensatz fast unkomprimiert schon overkill für vieles, selbst in einem kommerziellen Workflow. Was mir gleichzeitig relativ wichtig ist, wäre schon die Möglichkeit einer Weiterverarbeitung, selbst wenn die Originalfootage mal nicht mehr vorhanden sein sollte - da es sich da größtenteils um einzelne Takes handelt, wovon oft fast alle verschnitten werden (1-2:1 Dreh - Schnitt Ratio) und keine Schauspielertakes, wo nur jeder 3.-8. irgendwie bei einer Konsolidierung überbleibt, bringt da eine Konsolidierung auch nicht die Welt...
Problem mit Franks-Vorschlag ist eigentlich der zusätzliche Renderschritt für etwas (webkompatible Delivery), dass es für mich nicht zwangsläufig braucht. Und für mich wäre halt auch hauptsächlich spannend, wenn es auf Mac UND Windows direkt aus Resolve funktioniert. Für ffmpeg oder Handbrake braucht es dann ja quasi wieder einen erstmaligen Schritt um den Schnitt aus Resolve rauszubringen.
Von Bit-Tiefen-"Hochrendern" halte ich auch icht viel, auch wenn es in verlustfreien VFX-Roundtrips (die mir üblicherweise nicht ich ausdenke, sondern wo die Anforderungen von den VFXlern kommen) gang und gäbe und definitiv best practice ist.
Aber können wir mal Chroma-Subsamspling vor dem Hintergrund Bearbeitung im 32-Bit-Resolve & zukünftige Weiterverarbeitung diskutieren? 4:2:0 aus Pocket 3 ist klar, die Leier von UHD 4:2:0 zu FHD 4:2:2, die öfter in der Übergangszeit von FHD zu UHD diskutiert wurde, habe ich immer skeptisch betrachtet. Was ich allerdings auch einfach skeptisch sehe - sich im Fall von 4:2:0 Ausgangsmaterial vielleicht auch nicht vermeiden lässt - wäre ein bis zu 3-maliges Rendern von H265 mit gleicher Bit-Tiefe (da würde ich am wenigsten ändern) und gleichem Chroma-Subsampling.
Das 4:2:0 in der Ausgangsfootage liegt meinem Verständnis nach ab dem Moment des Processings in Resolve im 32-Bit-Gleitkomma-YRGB ohne Chroma Subsampling und ohnehin damit quasi im Hintergrund interpoliert vor. Mir ist auch bewusst, dass da keine motivbestimmte erweiterte Farbauflösung dazukommt, die im Rohmaterial nicht da war. Kann auch nicht. Ab dem Moment, wo - völlig unabhängig von "realer", auf irgendwelchen Motivfarben basierender Farbauflösung - allerdings Farbänderungen passieren, das kann Halation sein, das könnten theoretisch FX sein (das macht es als Beispiel und Trennung von der Originalfootage irgendwie klarer?), spielt das Chroma Subsampling des Rohmaterials doch nur mehr eine Rolle, wenn mir an der Farbauflösung von möglichst akkuraten Motivfarben gelegen ist. Wenn es darum geht die verarbeitete Footage mit einem Master etwas zu future-proofen, dann hab ich es beim Export mit einem erneuten Subsampling von einem interpolierten subsamplingfreien Zwischenstand zu tun (wo ich weiß, dass keinerlei Farbauflösung interpoliert worden ist, die nicht in der Originalfootage da ist, wo allerdings sämtliche Änderungen für sich gesehen subsamplingfrei vorliegen)?
Ich merke, ich steh an dem Punkt auch argumentativ an, ich werde das einfach mal testen und mir mal auf die Schnelle einfach ein H265 10-Bit 4:2:2 und H265 10-Bit 4:2:0 aus Resolve spielen und das weiterverarbeiten, ob sich da unterschiedliche Punkte zeigen wo das Material zerbricht.
Berechtige Frage. Wenn Rohmaterial einmal nicht mehr vorhanden sein sollte, einmal neu verschneiden und minimal an der Farbtemperatur drehen (denke Resolve - Primaries - Color Wheels - Temp), vielleicht einen Farbton mit dem Picker (Curves - Hue vs Hue) in die eine oder andere Richtung verziehen? Letztendlich kenn ich das Problem hauptsächlich von privaten Fotos, wo sich die 50MB-Raws stapeln und summieren, und es aber eigentlich keine befriedigende Lösung für eine Neubearbeitung Jahre später gibt: Entweder das Raw aufbewahren, etwaige Änderungen sind meist softwaremäßig nicht adäquat sidecarmäßig mitführbar (erst Recht nicht seit AI-Tools mit neueren Updates, cross-sofware-Kompatibilität sowieso nicht) und jede Archivierierung als 16-Bit TIF (8-Bit sinnlos, LZW-Kompressino bringt nicht den mordsmäßigen Speicherplatzvorteil) hat den Nachteil, dass im Endeffekt der Speicherverbrauch vgl. mit Raw sogar um ca. 400% steigt. Was bleibt dann? 8-Bit JPG, das erachte ich irgendwie nicht als Weiterbearbeitungstauglich, wenn ich sag ok ich hätte gern noch ca. 300K weniger und etwas weniger Magenta in den Schatten, fals mir mal fad ist und ich mich da nochmal ransetzt nach Jahren. Reckt mich oft, dass ich mir denke was mich da in der Post eigentlich geritten hat.dienstag_01 hat geschrieben: ↑Mi 06 Dez, 2023 10:55 Was schwebt dir denn so vor, wenn du von Weiterverarbeitung "nach" Resolve sprichst? Für deine privaten Aufnahmen. Machst du Family-VFX ;)
Das können sie ruhig, ich mach mir keinerlei Illusionen, dass das irgendjemanden für die Nachwelt interessiert, aber was mach ich den sonst irgendwann in der Pension, mir wär doch langweilig. Außer vielleicht eh immer weiterarbeiten, mach mir eigentlich Null Hoffnung auf einen ruhigen, arbeitsarmen Ruhestand.
Ersetzte "Besseres Ergebnis" mit "weniger schlechtes Ergebnis" nach erneutem Rendering von H265 und du triffst die Hypothese. Schaut aber wohl so aus, testbar ja, sichtbar quasi nicht.dienstag_01 hat geschrieben: ↑Mi 06 Dez, 2023 15:40 Ich finde ja schon die Annahme wenig überzeugend, 420-Material zu bearbeiten und mit 422-Ausgabe ein besseres Ergebnis zu erhalten, als mit 420-Ausgabe.
Meine Annahme wäre da, messtechnisch nachweisbare Unterschiede ja, sichtbare nein. (Das würde ich übrigens auch annehmen, wenn das Ausgangsmaterial 422 ist. Wer will da einen Unterschied erkennen.)
Hier steht was von LAV Filterdienstag_01 hat geschrieben: ↑Do 07 Dez, 2023 11:27 Kleine Zwischenfrage: Weiß jemand, wie man MPC-BE zum Verwenden der internen GPU überreden kann. Hintergrund ist, dass HEVC 422 10bit von der Nvidia nicht ubterstützt wird.
Oder gibt es einen anderen Player unter Windows, wo man die GPU-Auswahl konfigurieren kann?
Wiedergabe gehört ja auch irgendwie zum "richtigen" Codec ;)
Ja, hatte ich schon gelesen, ist mir aber zu unverständlich.Bluboy hat geschrieben: ↑Do 07 Dez, 2023 11:31Hier steht was von LAV Filterdienstag_01 hat geschrieben: ↑Do 07 Dez, 2023 11:27 Kleine Zwischenfrage: Weiß jemand, wie man MPC-BE zum Verwenden der internen GPU überreden kann. Hintergrund ist, dass HEVC 422 10bit von der Nvidia nicht ubterstützt wird.
Oder gibt es einen anderen Player unter Windows, wo man die GPU-Auswahl konfigurieren kann?
Wiedergabe gehört ja auch irgendwie zum "richtigen" Codec ;)
https://www.heimkinoverein.de/forum/thr ... gpu-nicht/
Funktioniert nicht im Player, man muss es unter Windows zuweisen.dienstag_01 hat geschrieben: ↑Do 07 Dez, 2023 11:27 Kleine Zwischenfrage: Weiß jemand, wie man MPC-BE zum Verwenden der internen GPU überreden kann. Hintergrund ist, dass HEVC 422 10bit von der Nvidia nicht ubterstützt wird.
Oder gibt es einen anderen Player unter Windows, wo man die GPU-Auswahl konfigurieren kann?
Wiedergabe gehört ja auch irgendwie zum "richtigen" Codec ;)
Nur leider nicht unter Mac. Aber scheinbar nimmt sich bei den (relativ hohen) Bitraten für HEVC - verglichen mit den üblichen Mini-Web-Datenraten - Hardware-Encoding nichts zu Voukoder, die 150Mbit/s sind visuell nicht zu unterscheiden.klusterdegenerierung hat geschrieben: ↑Do 07 Dez, 2023 12:16 Im ersteren Fall und mit der Sicht auf die Größe des Material, würde ich Dir zu Voukoder raten, denn in dem kannst Du 10Bit 422 oder höher auch als h265 raus rendern, fürs gute Gefühl. ;-)
Oder habe ich Dich missverstanden?
Wie läuft es denn mit dem Pocket3 und Deinem eigenen Testamterial?
Ich werde in den anderen Thread drüber heute mal ein bisschen was posten!klusterdegenerierung hat geschrieben: ↑Do 07 Dez, 2023 12:16 Wie läuft es denn mit dem Pocket3 und Deinem eigenen Testamterial?
Du hast ja völlig recht, das wär die einfachste Variante und löst eigentlich das Problem, außer dass ich mir anschauen muss, wo so mein Monats-Datenbedarf liegt. Im Moment steh ich bei ca. 50GB pro Woche (nach N=einer Woche). Sind auch nur 2,6TB im Jahr, das wär auch als reines Hobby inkl. Backup finanzierbar. :DFrank Glencairn hat geschrieben: ↑Fr 08 Dez, 2023 09:11 Warum du dich überhaupt künstlich einschränkst und einen Clip in dem alles unveränderlich für immer eingebrannt ist raus renderst, statt einfach ein Consolidate des Projekts zu archivieren, versteh ich immer noch nicht.
Im Endeffekt kann ich das Material maximal um 25-30% reduzieren (N=2 Schnitte), ich mach üblicherweise nicht 5 Takes vom gleichen Motiv, wo dann 4 bei der Konsolidierung fliegen, sondern halt einen oder zwei.andieymi hat geschrieben: ↑Mi 06 Dez, 2023 10:22 ... - da es sich da größtenteils um einzelne Takes handelt, wovon oft fast alle verschnitten werden (1-2:1 Dreh - Schnitt Ratio) und keine Schauspielertakes, wo nur jeder 3.-8. irgendwie bei einer Konsolidierung überbleibt, bringt da eine Konsolidierung auch nicht die Welt...
Vermutlich weil er in 10-15 nicht mer mit dem NLE arbeitet oder es nicht mehr backward kompatibel ist, oder das Rohmaterial irgendwann doch mal löschen möchte.Frank Glencairn hat geschrieben: ↑Fr 08 Dez, 2023 09:11 Warum du dich überhaupt künstlich einschränkst und einen Clip in dem alles unveränderlich für immer eingebrannt ist raus renderst, statt einfach ein Consolidate des Projekts zu archivieren, versteh ich immer noch nicht.
Da das consolidierte Rohmaterial genau so groß ist wie der fertige Clip (oder - je nach Codec sogar kleiner), macht das nur wenig Sinn.klusterdegenerierung hat geschrieben: ↑Fr 08 Dez, 2023 13:23
.. oder das Rohmaterial irgendwann doch mal löschen möchte.
Geht mir manchmal auch so.
Wenn ich 50GB an Rohmaterial habe und mein fertiger h265 10Bit Clip 2,5GB groß ist, ist das irgendwie nicht das gleiche. :-)Frank Glencairn hat geschrieben: ↑Fr 08 Dez, 2023 14:28Da das consolidierte Rohmaterial genau so groß ist wie der fertige Clip (oder - je nach Codec sogar kleiner), macht das nur wenig Sinn.klusterdegenerierung hat geschrieben: ↑Fr 08 Dez, 2023 13:23
.. oder das Rohmaterial irgendwann doch mal löschen möchte.
Geht mir manchmal auch so.
Beim Konsolidieren wird nur das Material verwendet, dass im Projekt für die Ausgabe auch relevant ist. Alles andere wird gelöscht.klusterdegenerierung hat geschrieben: ↑Fr 08 Dez, 2023 15:18Wenn ich 50GB an Rohmaterial habe und mein fertiger h265 10Bit Clip 2,5GB groß ist, ist das irgendwie nicht das gleiche. :-)Frank Glencairn hat geschrieben: ↑Fr 08 Dez, 2023 14:28
Da das consolidierte Rohmaterial genau so groß ist wie der fertige Clip (oder - je nach Codec sogar kleiner), macht das nur wenig Sinn.
Dann muss man’s wieder „in Hand nehmen“. Vielleicht aber auch der Zeitpunkt sich zu trennen…
Ja, wobei völlige Inkompatibilität mit Projektfiles aus der Vorgängerversion extrem selten sind, und wenn man eine Abo Software hatte, dann kann man das ja vorher auf die neue konvertieren (oder einfach gar nix machen, und sollte man das irgendwann tatsächlich nochmal brauchen, einfach das Material auf die Timeline einer neuen NLE werfen und fertig).
Konsolidieren heißt, daß nur das Material daß du tatsächlich in deiner Timeline benutzt hast übrig bleibt.klusterdegenerierung hat geschrieben: ↑Fr 08 Dez, 2023 15:18
Wenn ich 50GB an Rohmaterial habe und mein fertiger h265 10Bit Clip 2,5GB groß ist, ist das irgendwie nicht das gleiche. :-)
Deshalb hab ich ja oben auch geschrieben:klusterdegenerierung hat geschrieben: ↑Fr 08 Dez, 2023 19:28 Ich weiß was konsolidieren heißt, aber bei mir ist ein fertiger Clip weitaus kleiner, bzw in einer niedrigeren Bitrate als da Original.
...es sei denn du willst das komprimiert Material beim Rendern nochmal stärker komprimieren.
Nee, das Objektiv der Pocket 3 hat Blende 2.0 und ist damit genau doppelt so lichtstark wie das der Sony RX10, was wiederum die ISO bzw. das Bildrauschen halbiert. Als Festbrennweitenobjektiv ist es möglicherweise auch optisch besser. Zudem hat der Pocket 3-Sensor einen größeren Pixelpitch.Darth Schneider hat geschrieben: ↑Fr 08 Dez, 2023 20:42 Alber bei meiner alten RX10 war zumindest ein ziemlich fettes, hochwertiges, sogar motorisiertes Zeiss Zoom Glas mit F 2.8 vor dem Sensor.
Wüsste jetzt nicht was dieser Fakt mit Alkoholkonsum zu tun haben soll..;)
Das bietet die kleine Dji Cam wohl sicher nicht.
So ein klitzekleines billig Glas wie auf der Dji könnte logischerweise theoretisch auch mehr Rauschen verursachen, 10 Bit hin oder her.