Postproduktion allgemein Forum



Mastering Codec Mac für H265-Footage



Fragen rund um die Nachbearbeitung, Videoschnitt, Export, etc. (div. Software)
Antworten
andieymi
Beiträge: 1597

Mastering Codec Mac für H265-Footage

Beitrag von andieymi »

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?



Jott
Beiträge: 21782

Re: Mastering Codec Mac für H265-Footage

Beitrag von Jott »

Ich würde ja sagen fcp/Compessor, aber das ist ja alles Kindersoftware.

Im Ernst, wozu 4:4:2 am Ende der Kette? Gab es jemals an Blu-Rays (4:2:0) irgend etwas auszusetzen?



Frank Glencairn
Beiträge: 22219

Re: Mastering Codec Mac für H265-Footage

Beitrag von Frank Glencairn »

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.
Sapere aude - de omnibus dubitandum



cantsin
Beiträge: 13944

Re: Mastering Codec Mac für H265-Footage

Beitrag von cantsin »

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

Code: Alles auswählen

ffmpeg -i input.mxf -an -c:v libx265 -x265-params lossless=1 -pix_fmt yuv422p12le output.mov



andieymi
Beiträge: 1597

Re: Mastering Codec Mac für H265-Footage

Beitrag von andieymi »

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.



dienstag_01
Beiträge: 13310

Re: Mastering Codec Mac für H265-Footage

Beitrag von dienstag_01 »

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



andieymi
Beiträge: 1597

Re: Mastering Codec Mac für H265-Footage

Beitrag von andieymi »

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

Re: Mastering Codec Mac für H265-Footage

Beitrag von MK »

Am Ende läuft es wie bei den meisten: Die Erben werfen das Zeug weg...



andieymi
Beiträge: 1597

Re: Mastering Codec Mac für H265-Footage

Beitrag von andieymi »

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.



dienstag_01
Beiträge: 13310

Re: Mastering Codec Mac für H265-Footage

Beitrag von dienstag_01 »

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



andieymi
Beiträge: 1597

Re: Mastering Codec Mac für H265-Footage

Beitrag von andieymi »

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.



andieymi
Beiträge: 1597

Re: Mastering Codec Mac für H265-Footage

Beitrag von andieymi »

Ich habe gerade noch das M1 hardware-encodierte HEVC 10-Bit 422 (3,92GB) mit folgendem Verglichen, alles Voukoder unter Windows, direkt aus Resolve:

- X265 10-Bit 422 150Mbit/s Main 10 Intra 422 (ohne PSNR Tuning) - 3,85GB
- ProRes - 13,26GB
- ProRes LT - 9,39GB

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



dienstag_01
Beiträge: 13310

Re: Mastering Codec Mac für H265-Footage

Beitrag von dienstag_01 »

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



Bluboy
Beiträge: 4259

Re: Mastering Codec Mac für H265-Footage

Beitrag von Bluboy »

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 ;)
Hier steht was von LAV Filter

https://www.heimkinoverein.de/forum/thr ... gpu-nicht/



dienstag_01
Beiträge: 13310

Re: Mastering Codec Mac für H265-Footage

Beitrag von dienstag_01 »

Bluboy hat geschrieben: Do 07 Dez, 2023 11:31
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 ;)
Hier steht was von LAV Filter

https://www.heimkinoverein.de/forum/thr ... gpu-nicht/
Ja, hatte ich schon gelesen, ist mir aber zu unverständlich.



klusterdegenerierung
Beiträge: 27122

Re: Mastering Codec Mac für H265-Footage

Beitrag von klusterdegenerierung »

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?
"Wer weit geht, muß weit zurück laufen!"



dienstag_01
Beiträge: 13310

Re: Mastering Codec Mac für H265-Footage

Beitrag von dienstag_01 »

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)



andieymi
Beiträge: 1597

Re: Mastering Codec Mac für H265-Footage

Beitrag von andieymi »

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!



Frank Glencairn
Beiträge: 22219

Re: Mastering Codec Mac für H265-Footage

Beitrag von Frank Glencairn »

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.
Sapere aude - de omnibus dubitandum



andieymi
Beiträge: 1597

Re: Mastering Codec Mac für H265-Footage

Beitrag von andieymi »

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.



Frank Glencairn
Beiträge: 22219

Re: Mastering Codec Mac für H265-Footage

Beitrag von Frank Glencairn »

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.
Sapere aude - de omnibus dubitandum



klusterdegenerierung
Beiträge: 27122

Re: Mastering Codec Mac für H265-Footage

Beitrag von klusterdegenerierung »

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.
"Wer weit geht, muß weit zurück laufen!"



Bluboy
Beiträge: 4259

Re: Mastering Codec Mac für H265-Footage

Beitrag von Bluboy »

In Wahrheit kann man 50 oder 100 Euro sparen wenn man Daten eindampft, ob sih das wirklich lohnt ?



Frank Glencairn
Beiträge: 22219

Re: Mastering Codec Mac für H265-Footage

Beitrag von Frank Glencairn »

klusterdegenerierung hat geschrieben: Fr 08 Dez, 2023 13:23
.. oder das Rohmaterial irgendwann doch mal löschen möchte.
Geht mir manchmal auch so.
Da das consolidierte Rohmaterial genau so groß ist wie der fertige Clip (oder - je nach Codec sogar kleiner), macht das nur wenig Sinn.
Sapere aude - de omnibus dubitandum



klusterdegenerierung
Beiträge: 27122

Re: Mastering Codec Mac für H265-Footage

Beitrag von klusterdegenerierung »

Frank Glencairn hat geschrieben: Fr 08 Dez, 2023 14:28
klusterdegenerierung hat geschrieben: Fr 08 Dez, 2023 13:23
.. oder das Rohmaterial irgendwann doch mal löschen möchte.
Geht mir manchmal auch so.
Da das consolidierte Rohmaterial genau so groß ist wie der fertige Clip (oder - je nach Codec sogar kleiner), macht das nur wenig Sinn.
Wenn ich 50GB an Rohmaterial habe und mein fertiger h265 10Bit Clip 2,5GB groß ist, ist das irgendwie nicht das gleiche. :-)
"Wer weit geht, muß weit zurück laufen!"



vaio
Beiträge: 1064

Re: Mastering Codec Mac für H265-Footage

Beitrag von vaio »

klusterdegenerierung hat geschrieben: Fr 08 Dez, 2023 15:18
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.
Wenn ich 50GB an Rohmaterial habe und mein fertiger h265 10Bit Clip 2,5GB groß ist, ist das irgendwie nicht das gleiche. :-)
Beim Konsolidieren wird nur das Material verwendet, dass im Projekt für die Ausgabe auch relevant ist. Alles andere wird gelöscht.

Allerdings bleibt das Argument „Schnittsoftwarewechsel“, bzw. „Generationsupgrade“ der SW.
Zurück in die Zukunft



cantsin
Beiträge: 13944

Re: Mastering Codec Mac für H265-Footage

Beitrag von cantsin »

vaio hat geschrieben: Fr 08 Dez, 2023 15:35 Allerdings bleibt das Argument „Schnittsoftwarewechsel“, bzw. „Generationsupgrade“ der SW.
....und auch möglich verwendeter Plugins, nicht zu vergessen...



vaio
Beiträge: 1064

Re: Mastering Codec Mac für H265-Footage

Beitrag von vaio »

cantsin hat geschrieben: Fr 08 Dez, 2023 15:36
vaio hat geschrieben: Fr 08 Dez, 2023 15:35 Allerdings bleibt das Argument „Schnittsoftwarewechsel“, bzw. „Generationsupgrade“ der SW.
....und auch möglich verwendeter Plugins, nicht zu vergessen...
Dann muss man’s wieder „in Hand nehmen“. Vielleicht aber auch der Zeitpunkt sich zu trennen…
Zurück in die Zukunft



Frank Glencairn
Beiträge: 22219

Re: Mastering Codec Mac für H265-Footage

Beitrag von Frank Glencairn »

vaio hat geschrieben: Fr 08 Dez, 2023 15:35

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.
Sapere aude - de omnibus dubitandum



klusterdegenerierung
Beiträge: 27122

Re: Mastering Codec Mac für H265-Footage

Beitrag von klusterdegenerierung »

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.
"Wer weit geht, muß weit zurück laufen!"



Frank Glencairn
Beiträge: 22219

Re: Mastering Codec Mac für H265-Footage

Beitrag von Frank Glencairn »

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.
Sapere aude - de omnibus dubitandum



Darth Schneider
Beiträge: 18639

Re: Mastering Codec Mac für H265-Footage

Beitrag von Darth Schneider »

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



klusterdegenerierung
Beiträge: 27122

Re: Mastering Codec Mac für H265-Footage

Beitrag von klusterdegenerierung »

Das sehr kleine Glas dazu? Whaaaat?
Junge Junge, jetzt rauscht hier schon das Glas klipp klapp.

So viel saufen kann ich tatsächlich nicht!!
"Wer weit geht, muß weit zurück laufen!"



Darth Schneider
Beiträge: 18639

Re: Mastering Codec Mac für H265-Footage

Beitrag von Darth Schneider »

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



cantsin
Beiträge: 13944

Re: Mastering Codec Mac für H265-Footage

Beitrag von cantsin »

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.



 Aktuelle Beiträge [alle Foren]
 
» Topaz Video/AI jetzt als Resolve Plugin
von Frank Glencairn - So 19:28
» Neues Musikvideo Team Drama Doppelsternsystem
von Darth Schneider - So 19:19
» OpenAI Sora - das ist der KI-Video Gamechanger!
von iasi - So 19:07
» Paramount: Kahlschlag bei deutschen Produktionen
von markusG - So 18:56
» Neues von Atomos - OS11 Upgrade für Ninja (V), Feature Packs und Andeutungen
von roki100 - So 18:30
» JVC digitaler und Mini DV Camcorder GR-DVL357E Probleme SD Karte und AV-Kabel
von gunman - So 18:29
» Stop-Motion Musikvideo
von Darth Schneider - So 18:08
» Fotocash Erfahrungen
von jmueti1940 - So 18:05
» Sony PDT-FP1 - stabile und einfache Datenübertragung beim Dreh
von MarcusG - So 18:03
» Was hörst Du gerade?
von roki100 - So 17:08
» Die Zukunft der Videobearbeitung 2026 - Alles Echtzeit in der Cloud (gegen Aufpreis)
von wolfgang - So 16:17
» Blackmagic Videoassist 5 Zoll SDi
von bassnick - So 16:12
» Dauert konvertieren überall gleich lang?
von Axel - So 15:00
» Was schaust Du gerade?
von 7River - So 14:30
» Neues Musikvideo // Trebor "Alles brennt"
von macaw - So 14:24
» f0.3 – The Impossible Lens – Building a Large Format DoF movie camera
von iasi - So 12:27
» Apple Vision Pro: Verkaufsstart (USA) ab Februar für 3.499,- Dollar + neuer Werbeclip
von cantsin - So 11:22
» AI Render Engine für Cinema 4D
von Phil999 - So 4:49
» Laowa: Nanomorph Zoom auf Indiegogo - erste erschwingliche, anamorphotische Zooms?
von Frank Glencairn - Sa 22:05
» Untertitel in FCPX bei vorhandener Textdatei?
von Frank Glencairn - Sa 19:39
» Licht how to:
von Darth Schneider - Sa 19:32
» Elevenlabs bietet demnächst auch KI-generierte Soundeffekte an
von slashCAM - Sa 12:02
» CapCut
von Rusco - Sa 10:49
» Schweiz RED Kaufen / MwSt.....?
von soulbrother - Fr 23:07
» Nach 7 Jahren mit der OG BMPCC finde ich das Bild noch immer schön.
von roki100 - Fr 23:05
» SmallRig bringt umfassendes Retro-Zubehörsystem für Fujifilm X100VI
von slashCAM - Fr 18:36
» Panasonic stellt weltweit kleinstes und leichtestes Superzoom vor: LUMIX S 28-200mm F4-7.1 MACRO O.I.S.
von Frog1 - Fr 18:07
» OKTAVA MK 012 direkt in die Blackmagic 6K Pro
von Frank Glencairn - Fr 16:23
» Stable Diffusion 3 - erste Beta vorgestellt
von Frank Glencairn - Fr 15:22
» Was hast Du zuletzt gekauft?
von klusterdegenerierung - Fr 14:31
» Blackmagic URSA Broadcast G2 mit Cloud Upload und geringerer SDI-Latenz
von slashCAM - Fr 10:48
» Video Pro X stürzt beim Multi Cam Schnitt ab
von wabu - Fr 10:02
» Updates (24.2) für Premiere Pro und After Effects - "Sprache verbessern" und Color Fonts
von Frank Glencairn - Fr 9:51
» Tragischer Unfall am Set trotz Filmwaffe: Kamerafrau stirbt nach Schuß von Alec Baldwin
von Darth Schneider - Fr 8:11
» Sony stellt 5G Modem/Monitor für Cloud und Live vor
von rush - Fr 7:30
 
neuester Artikel
 
Die Zukunft der Videobearbeitung 2026

Ein Planspiel zum Thema KI-Anwendungen und Rechenleistung: Wenn man Eins und Eins zusammenzählt, sieht man bereits heute sehr deutlich, wohin uns die Reise der Videobearbeitung in den nächsten Jahren führen wird... weiterlesen>>