Bin an sich glaub ich nicht so unfit mit dem Codec-Thema im täglichen Gebrauch, aber irgendwie würde mich Input interessieren bzw. Langzeiterfahrungen von Menschen, die öfter mit H265-Source-Footage zu tun haben.
Teste gerade den Osmo Pocket 3 auf Herz und Nieren und bis jetzt gefällt alles daran. So gut, dass ich den sicher einfach sehr oft dabei haben werde um einfach zu dokumentieren, ist die perfekte Kamera wo man keine Ausrede mehr hat keine Kamera mitzunehmen, auch fürn Famlienausflug, Urlaub etc.
Und irgendwie bin ich beruflich einen sehr/eher(?) konservativen Mastering-Ansatz mit zumindest ProRes oder Raw-Ausgangsmaterial gewohnt:
- Wenn Kino(Spot) oder die Möglichkeit besteht und nicht ohnehin seperater DPX-Master vom Bild oder von vornherein DCP: DNxHR444 12Bit
- Wenn nur TV DNxHR: HQX 10-Bit (evtl. ProRes HQ)
- Wenn nur Web: Trotzdem HQX 10-Bit / ProRes HQ
Die Speicherplatz-"Kosten" von 20-250GB pro Master sind egal, zahlt eh der Kunde. Nur von allen 3-5min Familienkurzurlaubsvideo jetzt irgendwie einen DNxHR-Master rendern, geht sich halt irgendwie mit der Zeit auch nicht sinnvoll aus. Selbst ProRes422 nicht weils sich über die Länge (kein 20s Spot) summiert, und irgendwie macht LT wohl keinen Sinn mehr, vgl. mit was H265 jetzt mittlerweile "kann". Jetzt steh ich vor dem Problem, dass mir komplett die Erfahrung mit H265-Sub-Varianten fehlt. 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". Lacht mich ruhig aus, selbst wenn das Rohmaterial nur 4:2:0 ist :D Und irgendwie besteht da schon eine Lücke, gerade auch wenn ich an Fotos denk. Entweder man speichert die kompletten 16-Bit TIF (who needs 8-Bit TIF??!), von 10-12 Bit haben weder Lightroom noch Capture one viel gehört und so gibt's irgendwie auch keine wirklich Zwischenstufe zwischen gängigeren Mastering-Formaten und dann einfach H265 8-10-Bit 4:2:0. Kann man jetzt ruhig schreien, wo soll denn 4:2:2 herkommen? Aber mir ist es durchaus zuwieder, das immer nach 4:2:0 zu rendern. Jemand Erfahrung mit den hardwarebeschleunigten 10-Bit 4:2:2 unter Mac?
Ich bin ja auch ein Qualitätsfetischist, und mach Master deshalb ausschließlich komplett unkomprimiert, weil - warum nicht?
Und schneller ist es auch noch.
Allerdings auch nur um die verschiedenen Deliveries davon zu rechnen, danach wird das Master wieder gelöscht.
Sollte ich jemals wieder an das Material müssen, mach ich einfach das konsolidierte Projekt-Backup auf, und hab damit alle Möglichkeiten und Optionen.
Nix ist irgendwie eingebacken, und weniger Speicherplatz braucht es auch noch im Archiv.
Ob du so nen Workflow für irgendwelche Freizeitsachen machen willst, mußt du natürlich selbst wissen.
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".
Der Osmo Pocket 3 hat ja nur 10bit 4:2:0, insofern bringt da mehr Bittiefe oder Chroma Sampling nichts.
Der ideale Masteringcodec ist IMHO h265 mit lossless compression (gibt's, ist Teil des Standards, und geht auch mit ffmpeg). Nur die Rechenzeit fürs Encodieren spricht dagegen.
EDIT: Hab soeben mal einen Vergleich gemacht, bei einem kurzen Video mit ausschließlich Raw-Kameramaterial und relativ hohem Bildrauschen [Full Frame 3200 ISO ohne Rauschfilterung], also relativ anspruchsvoll für den Codec. Wenn man das in 12bit DNxHR 4:2:2 mastert, landet man bei 1,3 GB; bei 12bit 4:2:2 h265 lossless sind es 4,6 GB; unkomprimiert 12,6 GB.
Man kann also zwei Drittel des Speicherplatzes sparen, wenn man in h265 lossless statt unkomprimiert mastert.
Hier mal die ffmpeg-Kommandozeile fürs Selbermachen (ohne Audioencoding):
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.
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.
Was schwebt dir denn so vor, wenn du von Weiterverarbeitung "nach" Resolve sprichst? Für deine privaten Aufnahmen. Machst du Family-VFX ;)
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 ;)
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.
Aber zu einem ersten Test, mehr Input dazu gern:
Als Testframe habe ich einen Frame mit deutlichen Farbunterschieden (bis hin zu - ich würde es noch nicht Tonwertabrisse im DLog-M 10-Bit 4:2:0 nennen, aber wüsste man es nicht dass es im Rohmaterial auch ist, könnte man nach Grading davon ausgehen) im Schneeweiß gewählt (Preview im Anhang, ich lade alles in TIF noch auf WeTransfer, falls es jemanden interessiert). Schaut man links auf den Gehsteig ist Schnee im Schattten deutlich blauer als in Sonnenbereichen, der gelbe Schnee nach der Räumung wohl wirklich kontaminiert ;D
Als Ausgangsmaterial für den Test dienen 2 unterschiedliche Renderings der gleichen 3:31min UHD-Timeline. Ich schicke voraus, mich interessiert bei so Sachen mittlerweile Farbakkuratheit des Motivs oder der Osmo Footage Nüsse. Ich will Grain, ich will Halation, mich juckt Schärfe keinen Deut und wenn es am Ende irgendwie in Richtung 8-16mm geht kann ich gut damit leben, Hauptsache kein Handylook. Beide Renderings (am Ende 3,93GB groß - DNxHR hätte 19,22 lt. Aja Data Calc) mit der Resolve-Studio-H265 Ausgabe und einem M1 Mac - Profil Main 10 (4:2:0) bzw. Main 10 4:2:2, das geht in dem Fall lediglich mit der M1-Media-Engine hardwarebeschleunigt, Limiter auf 150000kbit/s, keine Optimierung für Speed, kein Multipass-Encode. Wie gesagt, Resolve "Hausmittel" wären ein Vorteil, Voukoder geht ja nicht unter Mac. Daraus resultieren 2 Files, beide exakt 3,93GB groß, Media Info attestiert 4:2:0 bzw. 4:2:2.
Ich habe mir erst einmal 3 Parameter angeschaut, zu den möglichen Testunzulänglichkeiten - beim Film Grain war "Optimized Mode" an und damit sind keine Grain-Berechnungs-Kompatibilität-Probleme, auch gibt es keinen irgendwie gearteten Seed-Regler, d.h. ich muss davon ausgehen, dass Resolve das Grain für jeden Frame bei jedem Rendering timelinespezifisch identisch rechnet. Das zeigt auch ein Teil der Resultate. Die beiden Renderings in eine Timeline gestapelt. Dann habe ich jeweils die Parameter verändert, die entsprechenden Stills gezogen, als TIFs über die Gallery exportiert und mir in Affinity Photo mittels Differenz-Ebenenmischung die Unterschiede angeschaut.
Test Parameter 1: Resolve - Primaries - Color Wheels - Temp Veränderung +500
Keine (visuellen) Unterschiede in Resolve, oder in den TIFs erkennbar, auch die Differenz-Ebenenmischung findet keine (auch nicht auf 100% Ansicht stichprobenartig in Affintiy, würde sich über weiße Pixel im schwarzen gemeinsamen Bereich zeigen, alles was ich seh ist, dass ich Monitor putzen sollte). Das zeigt auch, dass die Grain-Berechnung in Resolve tatsächlich keinen Seed oder Random Wert zu kennen scheint.
Test Parameter 2: Resolve - Curves - Hue vs Hue Veränderung InputHue 110, HueRotate -12
Keine (visuellen) Unterschiede in Resolve, oder in den TIFs erkennbar, auch die Differenz-Ebenenmischung findet keine (auch nicht auf 100% Ansicht stichprobenartig in Affintiy)
Test Parameter 3: Qualifier mit Werten wie im Qualifier.jpg angehängt, dann mittels Viewer den Key angezeigt. Da man scheinbar keine Stills mit Key-Anzeige exportieren kann, erstmal (die Unzulänglichkeit dessen ist mir bewusst, ich teste dass später noch quer, #5) einen Screenshot vom Vollformatigen Finder gemacht und diese in Affinity verglichen. Deutliche Unterschiede im Key, dass zeigt auch die Differenzanzeige.
Test Parameter 4: Qualifier mit Werten wie im Qualifier.jpg angehängt, dann mittels Viewer den Key angezeigt und "High Contrast" aktiviert. Unterschiede nehmen zu.
Test Parameter 5: Qualifier mit Werten wie im Qualifier.jpg angehängt, Key gezogen. Da die Screenshot-Vergleichsmethode unsauber ist, habe ich mir angeschaut was tatsächlich nach Weiterverarbeitung des Keys passiert. Dafür habe ich folgende Werte verändert Primaries - Color Wheels - Gamma - Rot 0.10 und Primaries - Color Wheels - Gamma - Gain - Grün 1.10 und anschließend wieder TIFs exportiert und diese verglichen.
Es ist nicht nichts, aber es ist auch nicht viel. Die farbveränderten Bereich nach dem Key sind im 422 TIF etwas begrenzter, beim 420 spillt die Farbe etwas flächiger. Dadurch scheint die Sättigung in den Bereichen höher zu sein, weil in Summe "flächigere" Farbverschiebungen (vgl. zum Original vor Key und Primary Korrektur. Es fällt tatsächlich im visuellen Vergleich fast mehr auf als in der Differenzdarstellung. Um wirklich in der Differenzanzeige was zu sehen braucht es kontrollierte Lichtumgebung und es beschränkt sich tatsächlich auf Bereiche, die im Keyer blockiger sind. Könnte damit zu tun haben, dass die letztendlich ein Schwarzweißresultat ausspuckt, wo die Unterschiede im fertigen TIF dann eigentlich eher auf einer Farb- als einer Luminanzebene auffallen.
Bitte hakt gern da ein, wenn ihr einen Schluss für verfehlt haltet oder euch noch was an der Methodik stört.
Bin eigentlich nicht viel schlauer als vorher. Die Unterschiede sind geringer als ich erwartet hatte, an der Grenze zu Placebo-Unterschide und das vor allem in der Praxis und trotzdem da. In der Anwendung ist es sicher für alles, was keinen Key braucht vernachlässigbar, gleichzeitig geht kein Speichermehrbedarf damit einher. Beim Keyen mit gleichen Parametern fallen dann Unterschiede auf. Ich kann nicht sauber genug versuchen so manuell zu adjustieren, dass das Resultat gleichwertig wird, weil das letztendlich die 1:1-Vergleichbarkeit irgendwie einschränkt, welche mit gleichen Parametern gegeben ist.
Schlauer macht einen das insofern nicht, da zumindest im Resolve-Mac-Hardware-Workflow per Bitraten-Limiting tatsächlich kein Größenunterschied zwischen 4:2:0 und 4:2:2 besteht. Also auch kein Größennachteil, sich für 422 zu entscheiden, aber auch nicht notwendigerweise ein großer Vorteil dadurch.
WeTransfer-Link zu den Originalgrößen-TIFs, falls es jemanden Interessiert: https://we.tl/t-Bf8qmsg15L
(Im Anhang ein Kontaktabzug von dem Downloadinhalt, nicht zur Beurteilung, nur ob sich jemand die Mühe machen will das runterzuladen und genauer zu pixelpeepen)
Letztendlich weiß ich auch, dass H265 lossless auch zu groß sein wird, wenn die Datenrate das 3-4 Fache von 12-Bit DNxHR HQX beträgt. Das wäre in dem Fall bei 3:31 dann zwischen 60 und 80GB.
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
MK hat geschrieben: ↑Mi 06 Dez, 2023 13:48
Die Erben werfen das Zeug weg...
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.
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.)
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.)
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.
Auf 100% sieht tatsächlich ProRes LT in detailreichen Bereichen am schlechtesten aus, gefolgt von ProRes. Nicht viel, auch fast Placebo. Die beiden H265/HEVC-Varianten nehmen sich gar nichts. Es scheint - das ist jetzt nur eine Interpretation, als würde HEVC beim Encodieren noch minimal "nachschärfen", jedenfalls ist auf 100% in gewissen Bereichen eine Kantenaufsteilung vorhanden, die ProRes nicht zeigt.
Summa summarum:
- Für Footage nach der Art Grading kein Vorteil höherer Datenraten als 150Mbit/s-Cap, es hängt eher an der individuellen Funktionweise des Codecs als allein an der Datenrate.
- HEVC 422 auch aus 420 Rohmaterial nach Grading zumindest dezent besser keybar als HEVC 420 Export.
Wird auf H265 10-Bit 422 rauslaufen, das funktioniert direkt aus Resolve mit Mac und Windows (Voukoder).
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 ;)
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 ;)
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 ;)
Hallo Andi, ich hoffe ich habe alles richtig verstanden und es geht um die geschnittenen Filmchen, denn das Rohmaterial ist ja wie es ist, das vorm archivieren künstlich aufzupumpen bringt ja nix.
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?
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 ;)
Funktioniert nicht im Player, man muss es unter Windows zuweisen.
(Der VLC will aber trotzdem die GPU nicht für HEVC 422 10bit verwenden, seltsam)
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?
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
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!
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.
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.
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. :D
Warum Konsolidierung jetzt nicht die Welt bringt:
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...
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.
Aber Du hast im Prinzip recht, das ist die einzige sinnvolle Lösung für das Problem, auch wenn es auf fast gar nichts wegschmeißen, sondern einfach Rohmaterial aufheben hinausläuft.
Dein Pocket-Rohmaterial ist ja schon extrem komprimiert, weniger als das wird's nicht mehr. Egal ob du das jetzt als einzelne Schnipsel aufhebst, oder am Stück, es sei denn du willst das komprimiert Material beim Rendern nochmal stärker komprimieren.
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.
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.
Geht mir manchmal auch so.
Allerdings bleibt das Argument „Schnittsoftwarewechsel“, bzw. „Generationsupgrade“ der SW.
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).
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. :-)
Konsolidieren heißt, daß nur das Material daß du tatsächlich in deiner Timeline benutzt hast übrig bleibt.
Somit ist dein Rohmaterial in h265 10Bit genau so groß, wie es ein fertiger Clip in h265 10Bit wäre.
Ich weiß was konsolidieren heißt, aber bei mir ist ein fertiger Clip weitaus kleiner, bzw in einer niedrigeren Bitrate als da Original.
Was soll ein gewöhnlicher Kunde mit einem Youtube Video von 2min in 600Mbit?
Das geht max in 50 raus und gut is und wenn ich eines für mich mache ist das nicht anders, sieht doch eh ausser uns keinen Unterschied.
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.
Deshalb hab ich ja oben auch geschrieben:
...es sei denn du willst das komprimiert Material beim Rendern nochmal stärker komprimieren.
Das Rauschen kommt bei zu wenig Licht, immer vom 1 Zoll Sensor, hab ich zumindest so in Erinnerung von der RX10…
Und bei der Pocket 3 kommt noch das sehr kleine Glas mit dazu..
Gruss Boris
@Kluster
Junge, Junge…
Typischer Kluster Daneben Spruch, mal wieder, mit 0 % Sozialkompetenz…;)
Anstatt deine Meinung auch zu begründen kommt einfach von dir nur voll was sinnloses beleidigendes…
Egal.
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.
Die Bilder aus der kleinen 600€ Dji sehen erstmal sicher toll aus, aber sehr flexibel wird das Material in Post wohl eher nicht sein….Woher denn auch, von der KI ?
Klipp klapp !!!
Gruss Boris
Zuletzt geändert von Darth Schneider am Fr 08 Dez, 2023 21:23, insgesamt 1-mal geändert.
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.
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.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
