Logo Logo
/// 

Was müsste ein Intermediate-Codec in der Zukunft können?



Noch was unklar? Dann in unserem Forum nachfragen
Zum Original-Thread / Zum Postproduktion allgemein-Forum

Frage von TheBubble:


Der Titel sagt eigentlich schon alles: Ich würde gerne wissen, was für Eure Anforderungen an einen Intermediate-Codec wären, der für die nächsten Jahre in der Postprooduktion und unter Umständen für Archivzwecke geeignet ist.

Kurz: Welche Features er haben sollte, insbesondere gegenüber zur Zeit gebräuchlichen Codecs.

Ich möchte die Frage aber unbedingt von Codecs abgrenzen, die speziell auf Anforderungen aus dem Bereich Compositing/FX eingehen, wie z.B. OpenEXR.

Ihr könnt auch gerne Dinge aufschreiben, die derzeit in bestehenden Workflows keine Rolle spielen, da sie mit den bestehenden Codecs eventuell nicht gut umsetzbar sind.



Antwort von WoWu:

Hallo Bubble.

Eigentlich musst Du doch nur mal die Codeentwicklung (beispielsweise von AVC, anschau'n und das Ganze in die I-only Welt übersetzen und das mit den Vorgaben bezüglich kommender Formatempfehlungen abgleichen. Wenn Du das ganze dann realistisch durchrechnest, wirst Du spätestens an irgend einem Parameter drehen müssen, um nicht zu "platzen".
Das wird dann wohl das I-Frame sein, das auf der Strecke bleibt.
Ach ja ... noch etwas. Es ist auch zweifelhaft, ob sich ein proprietärer CodecCodec im Glossar erklärt unbedingt empfiehlt, wenn man mal auf die Rückwärtskompartibilität abhebt.
Es sollte also schon so etwas wie ein Standard sein, der zumindest in der Archivierungsform etwas Endgültiges hat denn niemand wird sein Archiv alle paar Jahre umkopieren.

Das wäre mein Vorschlag. An den einzelnen Parametern wird man "drehen" müssen, je nachdem, wie verarbeitbar der CodecCodec im Glossar erklärt sich bis dahin rechnet.
Damit wären wir auch schon bei einer möglichen Verarbeitungsarchitektur, die der CodecCodec im Glossar erklärt unterstützen muss ... und natürlich auch die Betriebssysteme der Rechner. Die Rechnerhardware dürfte heute nicht mehr das Nadelöhr sein.

Stellt sich also jetzt die Frage: meinst Du einen "quasi neu zu erschaffenden" CodecCodec im Glossar erklärt oder die Kombination bzw. die Auswahl an vorhandenen Codecs abgeändert; denn neu zu schaffen aus einem "wünsch Dir was", dürfte nicht ganz so einfach sein, wenn man bedenkt dass an MPEG4 seit 20 Jahren gearbeitet wird und es derzeit über 1.300 Patente dazu gibt und mehr als 300 Softwarenetwickler in (ich glaube) 70 Firmen mitwirken.

Zuletzt stellt sich natürlich auch noch die Frage einer skalierung des Codecs, also der Auflösbarkeit in verschiedenen "Layern", wenn wir schon bei "Zukunft" sind.

Wohin soll Dein "Zug" also fahren ?

Übrigens wollte Panasonic in 2014 auch einen neuen Intermediate auf der Basis von AVC rausbringen ... warte ich heute noch drauf.
Aber das wäre doch wenigstens ein guter und zeitgemässer Ansatz gewesen.



Antwort von TheBubble:

Hallo WoWu,

Hallo Bubble.
Wohin soll Dein "Zug" also fahren ?

Ich habe versucht die Frage erstmal möglichst offen zu formulieren. Ich interessiere mich dabei für die Wünsche möglichst vieler filmschaffender Anwender, egal ob an kleinen oder großen Produktionen beteiligt, die ihre Bedürfnisse auch aus rein handwerklicher Sicht sehen dürfen.

Als Beispiel dachte ich daher zunächst an eher allgemeine Antworten wie

- es muss 4:4:44:4:4 im Glossar erklärt möglich sein,
- ich brauche nur 4:2:24:2:2 im Glossar erklärt,
- gut für eine FarbkorrekturFarbkorrektur im Glossar erklärt zu gebrauchen,
- ich brauche einen Alpha-KanalAlpha-Kanal im Glossar erklärt,
- (langzeit)archivfähig,
- leicht in eigene Programme zu integrieren,
- usw.

Ich möchte mit den Beispielen nicht vorgreifen, jeder soll schreiben, was ihm wichtig ist. Selbstverständlich wären auch Antworten wie "Ich will keine Intermediate-Codecs nutzen müssen." sinnvoll.

Ich habe natürlich auch eine Wunschliste, will aber erstmal nicht vorgreifen. :-)

Wobei, in einem Punkt greife ich vielleicht doch vor: Ich würde einen Intermediate-Codec favorisieren, der eher einfach und verständlich aufgebaut ist, auch auf Kosten der Dateigröße.





Antwort von Paralkar:

hmm also geil wäre n CodecCodec im Glossar erklärt, der wie h264 frei skalierbar ist (Datenrate & Auflösung), aber gern wie Prores Presets hat (Proxy, hq etc.)

Er muss 444, 422, 420 in 12, 10/8 und 8 bit liefern können

Mit einer aktuellen bzw. modernen KompressionKompression im Glossar erklärt (h264 bzw. h265), damit die DatenrateDatenrate im Glossar erklärt möglichst gering bleibt

Probleme mit dem Gammashift wie bei Prores sollte er auch nicht haben

Aces unterstützen,

Was nice wäre ist, wenn er ein Metadatenprofil und eine XML mit eingebettet hätte, so das ich gleich Schnitt automatisch setzen lassen kann nach diesem Protokoll

Das wären so meine Ideen



Antwort von Frank Glencairn:

IMHO zeichnet sich ein Intermediate CodecCodec im Glossar erklärt vor allem dadurch aus, daß er Verlustfrei (oder wenigstens Optisch Verlustfrei) ist, sonst brauch ich keinen Intermediate.

Dadurch fallen schon mal alle GOP basierten Codecs durch das Raster.

Ideal sind Tiff basierte Formate wie raw, EXR, DPX usw.
Kann man ja bei Bedarf verlustfrei komprimieren, wenn man Plattenplatz sparen will.

Zweite Wahl wäre ein Wavelett basierter CodecCodec im Glossar erklärt, wie Red's R3D, Cineform, CineformRaw, JPEG2000

Dann kommen DCTDCT im Glossar erklärt basierte wie Motion JPEG, ProResProRes im Glossar erklärt oder DNXHD - die wären mir persönlich aber schon zu verlustbehaftet.

Mit einer aktuellen bzw. modernen KompressionKompression im Glossar erklärt (h264 bzw. h265), damit die DatenrateDatenrate im Glossar erklärt möglichst gering bleibt

...

Aces unterstützen,

90% der ursprünglichen Information wegkomprimieren und dann ACES unterstützen? Mit was soll ACES denn arbeiten, wenn du vorher das meiste aus dem Fenster geworfen hast?

H264/65 sind und bleiben Delivery Codecs.



Antwort von Paralkar:

Naja, ich sag ja nur die Kompressionsart, soll ja kein h264 oder h265 CodecCodec im Glossar erklärt sein, da hast du Recht, die sind als Delivery Formate gedacht.

aber ist DCTDCT im Glossar erklärt nicht einfach alt, da würde doch mehr gehen, wenn man sich XAVC ansieht.

Ja aber dafür würd ich ja bleiben bei Tiff, EXR, DPX bzw. 2te Wahl Wavelet Kompression.

Es wäre für mich der Ablöser von Prores und DNXHD



Antwort von DV_Chris:

Die eigentliche Frage ist doch, ob in Zukunft überhaupt noch Intermediate CodecsIntermediate Codecs im Glossar erklärt notwendig sein werden? Die Grösse der Speichermedien und die Rechenleistung nehmen drastisch zu. Die Zeit wird kommen, wo man in Echtzeit durch eine TimelineTimeline im Glossar erklärt scrollt mit Spuren voll 4K RAW und es sich anfühlt wie DV25.



Antwort von Frank Glencairn:

Seh ich genauso. Plattenplatz ist heute schon deutlich billiger als früher DigibetaDigibeta im Glossar erklärt Bänder - Tendenz fallend.

Aktuell arbeite ich von der Aufnahme bis zum Master durchgehend mit komprimiertem raw. Ausnahme sind VFX Teile, da ist es DPX/EXR.

Flutscht alles problemlos.



Antwort von freezer:

Wichtig wäre für mich, dass der CodecCodec im Glossar erklärt OpenSource ist, denn wenn der Entwickler keine Lust mehr hat, oder die Softwarefirma hoppsgeht, dann hat man irgendwann ein Problem. Für einen Archivierungscodec interessant wäre noch die Möglichkeit Wiederherstellungsinformationen mitzuspeichern, falls ein paar Speicherbereiche nicht mehr richtig lesbar sind, so wie es bei WinRAR möglich ist: das Archiv wird um ein paar Prozent größer, dafür können kleine Fehler repariert werden.

Wichtig auch die Unterstützung von 8 bzw. 16bit-Alphakanälen.



Antwort von WoWu:

Die eigentliche Frage ist doch, ob in Zukunft überhaupt noch Intermediate CodecsIntermediate Codecs im Glossar erklärt notwendig sein werden? Die Grösse der Speichermedien und die Rechenleistung nehmen drastisch zu. Die Zeit wird kommen, wo man in Echtzeit durch eine TimelineTimeline im Glossar erklärt scrollt mit Spuren voll 4K RAW und es sich anfühlt wie DV25.
Die Frage ist, was schneller in die Höhe geht, die Rechnerleistung oder die Qualitätsanforderung.
ACES hat beispielsweise die 4-fache Filegrösse der heute üblichen RAW Formate und wenn man zukünftig tatsächlich eher in 12 als in 8 BitBit im Glossar erklärt denkt und Frameraten eher in Richtung 120-300 als in Richtung 50 gehen und Auflösungen zu eher zu 8K als zu 2K tendieren, dann werden die Rechnerleistungen immer hinterher hinken und man wird um eine KompressionKompression im Glossar erklärt nicht wirklich herum kommen. Die Effizienz muss nur da sein und wenn man berücksichtigt, dass EHVC ein vielfaches Effizienter als beispielsweise MPEG2MPEG2 im Glossar erklärt ist, das den meisten derzeitigen Intermediäres noch zugrunde liegt, dann stellt sich die Frage nicht mehr wirklich.

@Frank
H264/65 sind und bleiben Delivery Codecs.
Mach Dich mal von solchen Blog-Slogans frei.
Lediglich die unteren Profiles & level werden für Distribution genutzt.
Darüber gibt es aber P&Ls, die bis mehr als 900 MB/sMB/s im Glossar erklärt arbeiten und mit Distribution nichts zu tun haben.
Nach der Denke wäre nämlich ProResProRes im Glossar erklärt auch ein reiner Distributionscodec, weil er sogar auf einer viel schlechteren DCTDCT im Glossar erklärt aufsetzt, als die neuen Codecs.
Das ist einwenig so, als würdest Du einen Porsche als Lieferfahrzeug bezeichnen, nur weil er eine Anhängerkupplung hat und weil man auch langsam damit fahren kann.



Antwort von Peppermintpost:

@Wowu

das wir Richtung 8k oder 100fps+ tendieren sehe ich zur Zeit eigendlich nicht. Obwohl 4k ja jetzt schon seit Jahren beworben wird gibt es praktisch keinen Kontent. Die hohen Frameraten fordern Broadcaster auch seit Jahren aber auch da sehe ich nicht das sich das durchsetzt, im Gegenteil. Seit wir uns von PALPAL im Glossar erklärt verabschiedet haben drehen die meisten doch mit 24/25fps.

Ich will nicht ausschliessen das 8k in 120fps kommt, aber das ist genau so wahrscheinlich das 2k-24fps als Standart kommt. Es ist einfach nur spekulativ.

Ich stimme Frank eigendlich 100% zu. Ein intermediate CodecCodec im Glossar erklärt ist für mich entweder sowas wie DNxHDDNxHD im Glossar erklärt, das dann allerdings ausschliesslich als Proxie dient, um z.B. flüssig schneiden zu können.
Ansonsten denke ich auch das einzige was Sinn macht ist DPX oder EXR, wobei ich da schon kompl auf EXR umgestiegen bin. DPX war sehr gut, aber halt vor 10 Jahren, EXR ist in allen Belangen überlegen also benutze ich das seit einigen Jahren ausschliesslich.

Das es h264/h265 Versionen gibt die hohe Datenraten und minimale Verluste können, das mag ja sein. Aber praktisch wird es von 99.99% aller Nutzer so benutzt um einen Film der 10Gigabyte gross ist auf 100mb runter zu dampfen, und das ist ja was Frank meint.

Bei ProResProRes im Glossar erklärt gebe ich dir Recht, auch das ist für mich ein reiner Delivery CodecCodec im Glossar erklärt, weil ich an der Stelle nicht mehr danach frage was der effizienteste CodecCodec im Glossar erklärt ist, sondern nur welcher CodecCodec im Glossar erklärt kann von meinem Kunden problemos angesehen werden und sieht dabei noch recht gut aus, beides trifft auf ProResProRes im Glossar erklärt zu.



Antwort von cantsin:

Was spricht eigentlich dagegen, jetzt schon h264 High Profile mit Intraframe-Kompression und den bei ProResProRes im Glossar erklärt üblichen Bittiefen und -raten als Intermediate zu verwenden? Die Bildqualität dürfte, bei gleicher Bitrate, wegen der moderneren Algorithmen besser sein als bei ProResProRes im Glossar erklärt, DnXHD & Co. Hardware- bzw. GPU-beschleunigte Wiedergabe müsste doch ebenfalls mit allen modernen NLEs funktionieren?



Antwort von WoWu:

@ Peppermintpost

Bei Hubbles Frage nach "Zukunft"s CodecCodec im Glossar erklärt habe ich mich ganz bewusst mal vom Stand "heute" gelöst und ob etwas heute nachgefragt wird.
REC 2020 empfiehlt ganz deutlich andere Qualitäten und weil Broadcaster bisher solchen Vorschlägen weitestgehend gefolgt sind und es bisher keine gegenteiligen Bestrebungen gibt, gehe ich mal von 120 fps und den andern Vorgaben aus. Zukunft ist ja ein weiter Begriff und darf sicher nicht mit "Heute oder Morgen" verwechselt werden.

Was EXR angeht, gibt es das FormatFormat im Glossar erklärt eigentlich nur für Einzelbildverarbeitung, einschließlich dem eingeschränkten Matedatenumfang.
Deshalb ist ja ACES daraus entwickelt worden und stellt also .exr im Videosektor dar. Aber nicht jedes .exr ist ein ACES aber jedes ACES ist ein .exr.
Darüber hinaus hat aber das Ganze nichts mit einem CodecCodec im Glossar erklärt zu tun sondern ist quasi das, was früher eine RAW Verarbeitung war.
Bubble fragt aber nach einem Codec.

Das es h264/h265 Versionen gibt die hohe Datenraten und minimale Verluste können, das mag ja sein. Aber praktisch wird es von 99.99% aller Nutzer so benutzt um einen Film der 10Gigabyte gross ist auf 100mb runter zu dampfen, und das ist ja was Frank meint.
Dann soll er es auch so schreiben.
Man darf aber eben eine Anwendung nicht mit einem CodecCodec im Glossar erklärt verwechseln.
Heute würde ich beispielsweise jeden I-Frame only aus AVC einem I-Frame aus Pro Res vorziehen, weil der CodecCodec im Glossar erklärt ganz erheblich verbessert ist und bei identischer DatenrateDatenrate im Glossar erklärt erhebliche Performanzvorteile aufweist.
Man darf nur einen nicht "Apples mit Birnen" vergleichen.

Und wen Bubble nach einem Zukunftscodes fragt, dann meint er wahrscheinlich nicht, was Kunden abfragen werden sondern so, wie ich ihn verstanden habe wohl eine Frage nach Verarbeitungsmöglichkeiten beinhalten soll. Das impliziert aber, dass ein bestehender CodecCodec im Glossar erklärt zugrunde liegen muss.

Da wäre für mich ganz deutlich ein Produktionslager aus H264 oder HEVC der Favorit, mit einer vorgelagerten ACES Verarbeitung.
Der CodecCodec im Glossar erklärt wäre dann nur noch das Übergabeformat bzw. die Archivierung, auch weil man ziemlich sicher sein kann, dass Player auch in Zukunft noch rückwärts kompatibel sind, mehr als alle proprietären Player und erst Recht als Open Source.
Wenn ich also schon eine KompressionKompression im Glossar erklärt archivier(n muss) dann will ich nicht alle paar Jahre umkopieren müssen.
Gedacht ist dafür ja ACES, aber wenn die Formate so voluminös werden, dass man auf einen CodecCodec im Glossar erklärt zugreifen muss, dann doch lieber einen Standard, der nicht alle naselang von Firmen geändert wird.



Antwort von WoWu:

Was spricht eigentlich dagegen, jetzt schon h264 High Profile mit Intraframe-Kompression und den bei ProResProRes im Glossar erklärt üblichen Bittiefen und -raten als Intermediate zu verwenden? Die Bildqualität dürfte, bei gleicher Bitrate, wegen der moderneren Algorithmen besser sein als bei ProResProRes im Glossar erklärt, DnXHD & Co. Hardware- bzw. GPU-beschleunigte Wiedergabe müsste doch ebenfalls mit allen modernen NLEs funktionieren?

Oder gleich in I-Frame aufnehmen.
Machen wir seit 2004 in AVC-I
Aufnehmen, schneiden, archivieren - und gleich in 10 Bit.
Deswegen können wir auch heute noch Footage benutzen, das sich seit 11 Jahren rechnet.



Antwort von Peppermintpost:

@Wowu

bei deiner letzten Ausführung wiederspreche ich nicht.

Das wiederspricht auch nicht dem was Frank schreibt.
Sein Ansatz ist ja nur die maximal mögliche Qualität des Footage zu erhalten und entsprechend ein intermediate FormatFormat im Glossar erklärt (keinen Codec) zu benutzen was diese Anforderung sicherstellt.
Die Nachteile von sehr hohen Datenraten und der Nachteil das das alles nicht mehr in Realtime abgespielt werden kann, wird bewusst in kauf genommen um keine Abstriche ber der Qualität hinnehmen zu müssen.

Ausserdem schreibt er ja ebenfalls, das das im Grunde nur für Shots zum tragen kommt die eine aufwendigere Post brauchen z.B. VFX Shots, sonst greift er auf die original Kamera Files zu solange das möglich ist.

Und am ende kommt dann h.264 oder ein anderer Kompressions CodecCodec im Glossar erklärt nur als Delivery zum tragen.

Ich finde diesem Workflow wunderbar, er garatiert höchst mögliche Qualität bei handhabbaren Datenmengen. Und das ist jetzt nur meine Meinung, in Zeiten wo ein GB Festplattenplatz nur noch 3Cent kostet sind mir Datenmengen wirklich egal.



Antwort von WoWu:

Offen gesagt ist es mir ziemlich egal, wie jemand zwischen den Codecs hin und her transponiert.
Diese Aussage:
H264/65 sind und bleiben Delivery Codecs.
ist jedenfalls falsch.
Dann hätte er schreiben sollen, .... "benutze ich nur als" ...



Antwort von TheBubble:

Ich habe Eure Kommentare gelesen. Bevor ich gleich noch auf einige eingehen will, möchte ich noch um Eure Einschätzung der Folgenden Aussagen bitten:

- Ein neuer Intermediate-Codec sollte (zur Verbesserung der Kompression) anfangs verlustbehaftet arbeiten dürfen, unveränderte Regionen sollten aber ohne weitere Verluste immer wieder neu komprimiert werden können.

- Um (Farb-/Helligkeits-)Korrekturen rückgängig machen zu können, sollte der CodecCodec im Glossar erklärt für alle Farbkanäle Werte außerhalb von Schwarz und der max. Helligkeit speichern können.

- Er sollte genug Bittiefe verwenden können, um größere RGB-Farbräume (als sRGB/REC.709) vernünftig abzudecken.

- Interlace-Unterstütung ist (A) gar nicht erforderlich (B) nur für ausgewählte "Legacy-Auflösungen" (SD, HD, vor allem bei der Verarbeitung von Archivmaterial) nötig oder (C) für zukünftige Projekte (Auflösung egal) noch immer von Bedeutung.

- Um die Verbreitung zu fördern, sollte die Spezifikation und deren Umsetzung auch für durchschnittliche Entwickler/Programmierer so verständlich sein, dass sie die Spezifikation ohne unglaublichen Arbeitsaufwand in verschiedenen Programmiersprachen umsetzen können. Dies kann auch zu Lasten dessen gehen, was sonst an KompressionKompression im Glossar erklärt möglich wäre.

- Eine Umsetzung des Codecs sollte sich einfach (von Entwicklern) in Programme integrieren lassen, um die Verbreitung zu fördern. (Also nicht nur in den großen NLEs und Compositing-Suiten, es geht darum auch sehr spezialisierte Programme ohne aufwendige Verrenkungen in Workflows integrieren zu können).

- Die obigen Aussagen sowie akzeptable Hardwareanforderungen sind wichtiger, als die bestmögliche Kompression. (D.h. der CodecCodec im Glossar erklärt wird (deutlich) mehr Speicherplatz verbrauchen dürfen, als andere sehr stark Komprimierende.



Antwort von TheBubble:


Und wen Bubble nach einem Zukunftscodes fragt, dann meint er wahrscheinlich nicht, was Kunden abfragen werden sondern so, wie ich ihn verstanden habe wohl eine Frage nach Verarbeitungsmöglichkeiten beinhalten soll. Das impliziert aber, dass ein bestehender CodecCodec im Glossar erklärt zugrunde liegen muss.
Nicht unbedingt. Vielleicht habe ich es nicht klar genug ausgedrückt, aber meine Frage nach Anforderungen ist allgemein. Es muss also kein existierender CodecCodec im Glossar erklärt zugrunde liegen, es dürfen ruhig auch (realistische) Wünsche sein, die nur durch eine Neuentwicklung erfüllbar sind.



Antwort von MLJ:

@TheBubble
Auch wenn ich wohl gleich richtig Prügel von "WoWu" beziehen werde, für mich ist und bleibt H264 ein Delivery Codec. Sicher kann man damit I-Frame machen aber man sollte sich immer eines vor Augen führen: Jede Formatwandlung ist verlustbehaftet, egal welche. Man kann nicht etwas dazu zaubern was vorher nicht da war und umgekehrt.

Ich kenne niemandem im CdC der ein Master für eine BluRay oder DVD in einem anderen Farbraum bearbeitet, hier 4:2:04:2:0 im Glossar erklärt, die bleiben in 12 BitBit im Glossar erklärt 4:2:04:2:0 im Glossar erklärt RAW bis das Master steht und in RAW exportiert wurde, erst DANN geht es zum H264/MPEG-2 Encoder für die Scheiben, vorher nicht.

Ich mache das nicht anders, RAW 12 BitBit im Glossar erklärt 4:2:04:2:0 im Glossar erklärt oder 16 BitBit im Glossar erklärt 4:2:24:2:2 im Glossar erklärt, kann Frame-genau schneiden und nehme DVSD/H264/MPEG-2 (4:2:0) oder Xvid/HuffYUV/MJPEG (4:2:2) ganz am Schluss wenn alles fertig ist, je nach Klient und seinen Wünschen. Es macht Null Sinn alles in 4:2:24:2:2 im Glossar erklärt zu machen wenn das Ziel 4:2:04:2:0 im Glossar erklärt ist oder umgekehrt. Wer mal mit Leuten in Master Labs gesprochen hat oder kennt wird wissen wovon ich spreche.

Das macht sich besonders bemerkbar wenn das Material noch korrigiert werden muss, da ist eine RAW oder LosslessLossless im Glossar erklärt Variante unbezahlbar und die Unterschiede zu komprimierten Formaten die bearbeitet wurden SIND am Ende sichtbar. Weiterhin beanspruchen die RAW und LosslessLossless im Glossar erklärt Varianten die Hardware kaum da gute Karten diese RAW Formate nativ unterstützen.

Was soll nun ein "neuer" Intermediate CodecCodec im Glossar erklärt noch können ? Nun, will man das beste Ergebnis so bleibt eigentlich nur die RAW oder LosslessLossless im Glossar erklärt Variante. Aber was ist mit den verschiedenen Plattformen ? Wie oft sollen Projekte neu codiert werden damit es jedes Programm und Plattform öffnen kann ? Wie oft soll das Rad denn noch neu erfunden werden ? Gibt es denn nicht genug davon ? Was soll ein neuer Intermediate CodecCodec im Glossar erklärt anders oder besser machen als die, die es bereits gibt ?

Jedes mal wenn ich deutsches Öffi-TV sehe bekomme ich das grausen. Verzerrte Linien, Klötzchen, falsches Interlacing, ruckeln, Banding in den Mitteltönen, mal zu Hell, mal total abgesoffen, vom Ton ganz zu schweigen, "Arte" bleibt aber ein Genuss. Das soll die neue H264 HD Welt sein auf die alle schwören ? Tolle Aussichten wenn dem so sein sollte aber so würde ich das Material hier niemals raus geben. In den Technischen Richtlinien der Öffis steht etwas ganz anderes, nur so nebenbei.

Doch zurück zum Thema:
I420, IYUV, UYVY oder YUY2 nur um einige zu nennen, kann problemlos von jedem System verarbeitet werden, zurück bis ins Jahr 1990 ! Microsoft unterstützt derzeit nur noch I420 und das identische IYUV unter Windows als CodecCodec im Glossar erklärt und warum ? Weil Apple Rechner und QuickTime das nativ verarbeiten können. Warum glaubst du ist nur noch der Intel I420/IYUV CodecCodec im Glossar erklärt aktuell unter Windows zu finden ?

Interlaced ist und bleibt meiner Meinung nach wichtig, auch wenn es für viele hier scheinbar "veraltet" ist und eine verlustbehaftete Komprimierung ist für ein optimales Ergebnis kaum brauchbar, "Goldwingfahrer" hat es in diesem Forum schon oft genug erwähnt wenn es um das digitalisieren von Analogem Material geht und schließe mich dem an.

Zitat:
"...es dürfen ruhig auch (realistische) Wünsche sein, die nur durch eine Neuentwicklung erfüllbar sind."
Zitat ende.

Derzeit sehe ich keinen "Wunsch" der nicht schon erfüllt wurde durch bereits existierende Codecs. Insgesamt ist die CodecCodec im Glossar erklärt Frage eher sehr individuell und daher kaum auf jeden Nutzer anwendbar. Möchtest du etwa einen neuen CodecCodec im Glossar erklärt entwickeln ? ;)

@All
Ihr wollt das beste an Qualität in höchster Auflösung auf kleinstem Raum und geringster Hardware Anforderung aber wollt dafür am Ende doch auf Qualität verzichten weil es am besten 35:1 komprimiert sein soll ? Das macht für mich keinen Sinn denn, was weg ist ist weg und keine Bitrate oder CodecCodec im Glossar erklärt der Welt wird das zurückholen.

Daher finde ich den Ansatz hier falsch denn es gibt genug Intermediate CodecsIntermediate Codecs im Glossar erklärt, auch solche die verlustfrei arbeiten. Auch für Archive gibt es genug Lösungen. Der Ansatz sollte eher sein ab der Aufnahme über den Import ins NLE bis zur Ausgabe im gleichen Farbraum und FormatFormat im Glossar erklärt zu bleiben um die Qualität oben zu halten.

Ein altes, aber immer noch aktuelles FormatFormat im Glossar erklärt ist DV. Digital vom Band über FirewireFirewire im Glossar erklärt in den PC ohne Verluste transferieren, im NLE Importieren, bearbeiten, schneiden, speichern oder zurück auf Band, fertig, ganz einfach und keine Verluste. So sollte das sein denn optimaler und schneller geht es nicht und ist ein bewährter Workflow.

Kleines Beispiel:
Ich verwende diesen "DV" Workflow und ein 90 minütiger Film in SD (RAW, nicht DV) ist bei mir ohne FarbkorrekturFarbkorrektur im Glossar erklärt in knapp 5 Minuten, mit FarbkorrekturFarbkorrektur im Glossar erklärt in etwa 15 Minuten durch, in HD zwischen 35 bis 50 Minuten.

Fazit:
Man kann es auch übertreiben nach der Jagd nach noch mehr PixelPixel im Glossar erklärt, Auflösung und Frameraten denn ich finde es gibt genug Codecs die sich über viele Jahre bewährt haben und so bleibt es am Ende eine Frage der eigenen Präferenz. Aber, wie immer, das ist nur MEINE Meinung zu diesem Thema, okay ?

Cheers

Mickey

P.S.: Mit "RAW" meine ich Unkomprimiert und NICHT Foto-RAW Dateien.



Antwort von WoWu:

Nee, Mickey, gar nicht.
Nur die Bestellung, dass H265/265 ausschliesslich ein Delivery CodecCodec im Glossar erklärt ist, würde ich bestreiten, denn dem ist nicht so.
Wenn jemand H264/265 lediglich als Delivey CodecCodec im Glossar erklärt benutzt, ist ja in Ordnung.
Aber was Du sehr richtig erwähnst, ist die Qualitätseinbusse bei Transcodierungen jeglicher Art, aber wenn Du von RAW kommst ... wo soll da das Problem sein ?

@Bubble

Ist denn bei einem solchen Vorhaben auch der Übergang in den Frequenzraum neu zu gestalten oder wird auf die bereits entwickelten DWTs, DSTs oder DWTs zurück gegriffen ?

Edit:
@Michey
Ein altes, aber immer noch aktuelles FormatFormat im Glossar erklärt ist DV. Digital vom Band über FirewireFirewire im Glossar erklärt in den PC ohne Verluste transferieren, im NLE Importieren, bearbeiten, schneiden, speichern oder zurück auf Band, fertig, ganz einfach und keine Verluste. So sollte das sein denn optimaler und schneller geht es nicht und ist ein bewährter Workflow.
DV ist da ein ganz schlechtes Beispiel, weil die Streuung bei der Implementierung leider so gross war, dass durch die unterschiedlichen Implementierungen bereits das Bild so drastisch beschädigt wurde, dass man bei den Implementierungsvorschriften deutlich an Präzision zulegen musste, um nicht dieselben Fehler, wie im Redbook zu wiederholen..



Antwort von MLJ:

@WoWu
Also ist der Kelch noch einmal in Sachen Prügel an mir vorbei gezogen ? Uff, da bin ich aber froh. :) Sicher, man kann H264 auch als Intermediate nutzen aber findest du wirklich das sich H264 besser eignet als RAW ? Ich denke nur an die Bitrate, bei RAW ist diese hoch und Konstant, ein großer Vorteil wenn man das ganze mit 2-Pass Variabler Bitrate als Ziel in ein H264/MPEG-2 codieren möchte.

Was den Punkt "Delivery Codec" angeht so kann ich nicht bestreiten das man auch H264 als I-Frame mit hoher und konstanter Bitrate verwenden kann nur haben mir die bisherigen Tests damit nicht wirklich gefallen, besonders in 4:2:04:2:0 im Glossar erklärt (I420/IYUV/YV12) da in diesem Farbraum immer wieder "Banding" auf ebenen mittenbetonten Flächen auftraten, was bei RAW nicht passiert. Ich verwende immer den passenden Farbraum, es wird also nicht z.B. YUY2 zu I420 konvertiert. Im TV ist das auch immer wieder zu sehen.

Nun der Grund warum H264 für mich (!) ein Delivery CodecCodec im Glossar erklärt ist: Wenn ich ein 4:2:04:2:0 im Glossar erklärt RAW an den H264 Encoder gebe, dann ist es sauber, kein Banding oder sonstige Störungen. Gebe ich allerdings ein H264 I-Frame Master in den H264 Encoder so treten die besagten Störungen stellenweise auf, warum, habe ich bisher nicht herausfinden können. Eine Idee ? ;)

Und dennoch gebe ich dir Recht: H264 ist nicht ausschließlich ein Delivery CodecCodec im Glossar erklärt, nur eben für meinen Geschmack, soll aber andere nicht davon abhalten H264 insgesamt für eine ganze Produktion zu verwenden statt nur am Schluss. Es ist und bleibt eben eine reine Geschmackssache, nicht mehr und nicht weniger.

Dein Edit in Sachen DV:
Das ist mir bekannt und meinte damit eigentlich nur den Workflow und nicht das DV-Format. Gerade wenn ein NLE IntelliRendering oder SmartRendering bietet ist dieser Workflow unschlagbar. Aufnahmeformat rein, bearbeiten, schneiden und mit dem gleichem FormatFormat im Glossar erklärt und Parametern der Aufnahme wieder speichern, das meinte ich ;)

Cheers

Mickey



Antwort von WoWu:

Das Problem liegt eben im Workflow.
Ich bin, da, wo es angesagt ist auch ein RAW Verfechter, wenn die blöden Formate nicht so unterschiedlich wären.
Wobei ich nicht alles, was sich RAW nennt, auch für RAW halte denn wenn bereits ein fertiges Videosignal dabei herauskommt, fehlen mir wesentliche RAW typische Elemente. Insofern ist RAW auch mit Vorsicht zu geniessen.

Was den sonstigen Aufnahmecodes bzw. einen Intermediatecodec betrifft, so sollte man sich, speziell im Hinblick auf die Bewegungsschatzung schon sehr genau die Unterschiede anschauen und wenn ich in ohnehin weiss, dass ich in eine AVC basiert Delivery gehe, dann werde ich -sofern ich nicht aus einer kompressionslosen Codierung komme, immer die Vorteile (in der Farbverarbeitung und der Bewegunsschätzung- von vorn herein nutzen.
Wie Du sagst ... was vorher schon weg ist, kommt auch nicht wieder.
Habe ich also im Intermediate mit grossen Macroblöcken gearbeitet oder meine Farbverarbeitung bereits eingschränkt, nutzt mir hinterher ein ausgeklügelter Deliverycodec gar nix mehr.
Daher spricht alles für ein durchgängiges AVC -auch als Intermediate-und nicht umsonst schwenkt auch Sony auf XAVC.
Der Vorcodec hat also immer etwas mit dem Zielcodes zu tun bzw. mein Endprodukt lässt sich deutlich verbessern, wenn man solche Umstände im gesamten Workflow berücksichtigt.

Daher stellt sich die Frage auch, welche Verwendung ein solcher, von Bubble angesprochener, neuer -verlustbehafteter- CodecCodec im Glossar erklärt haben soll, denn mit einem Intermediate macht man sich manchmal mehr an Qualität kaputt, als man denkt, weil man den Intermediate als Stand der Qualität ansieht und gar nicht bemerkt, was man eigentlich schon bei der Benutzung vermasselt hat.
Und weil AVC reichlich Vorteile aufweist, sollte man auch sehen, dass sie einem nicht im Workflow verloren gehen.
Wie gesagt, von RAW nach H.264 liegt nicht das Problem, solange man nicht die Schraubzwinge dazwischen hat und das hat nicht nur was mit I-Frame only oder nicht I-Frame zu tun sondern mit den Tools, die im CodecCodec im Glossar erklärt zur Anwendung kommen und mit Fehleranhäufungen.
Dabei spielt die GoP oft nur eine untergeordnete Rolle die bei heutigen Hard- und Softwarearchitekturen nicht mal mehr sosehr zum Tragen kommt.



Antwort von TheBubble:


Was soll nun ein "neuer" Intermediate CodecCodec im Glossar erklärt noch können ?

Dann werde ich mal auf meine Vorstellungen näher eingehen.

Im Grunde will ich: Ein offenes Austauschformat, das jeder ohne große Klimmzüge (d.h. einfach) in Software plattformübergreifend (Windows, Linux, Mac) verwenden kann und das eine bestimmtes Qualitätslevel garantiert. Der CodecCodec im Glossar erklärt soll klar definierte Dinge können, soll aber nicht unnötig flexibel und damit kompliziert sein.

Was ich nicht will: Diverse Codecs in jedem Tool, egal wie klein, unterstützen müssen.

Bestehende Codecs, im Grunde egal ob heutige Intermediates oder nicht, sind häufig nicht offengelegt oder aus anderen Gründen nicht praktikabel einsetzbar. Derzeit ist ProResProRes im Glossar erklärt sicher der von der Favorit der breiten Masse, man braucht nur mal die Erwähnungen der letzten Wochen hier im Forum zu zählen, allerdings ist ProResProRes im Glossar erklärt auch nicht wiklich offengelegt, die einzig wirklich breit genutzen Umsetzungen sind vermutlich die von Apple selbst.

Codecs wie H.264 oder H.265 sind technisch toll, aber unglaublich kompliziert. Wer sie in eigenen Programmen lesen oder schreiben will, kann das nicht selbst umsetzen. Insbesondere das Schreiben wird schnell unberechenbar: Je nach verwendeter Codec-Umsetzung kann das Ergebnis qualitativ toll oder miserabel sein.

Praktisch völlig beliebig verwendbare Umsetzungen (wie z.B. für JPEG) gibt es nicht. Auch müsste man weit mehr als einen CodecCodec im Glossar erklärt unterstützen, denn so verwenden z.B. schon im Privatbereich verbreitete HD-Kameras Codecs von MPEG-2MPEG-2 im Glossar erklärt über H.264 bis inzwischen H.265 in diversen Varianten. Irgendwo müsste also ein Umwandlungsvorgang davor stehen, wenn man nur einen CodecCodec im Glossar erklärt bzw. nur ein Dateiformat zum Austausch unterstützen will.

Deswegen RGB-Bitmaps gleich einfach unkomprimiert oder nur mit Codecs wie HuffYUV zu speichern wird aufgrund der Datenraten jedoch schnell zu einem Problem: Egal was man hier im Forum prognostiziert, 4K-HFR und 8K werden kommen. Nicht heute, nicht morgen, aber es wird kommen. Auch größere Farbräume als sRGB werden kommen (bzw. sind bei Filmproduktionen schon da), für sie reichen die 8-Bit pro Kanal von HuffYUV nicht mehr aus.

Auch selbst wenn Massenspeicher immer günstiger wird, der Durchsatz beim Datenaustausch (z.B. in lokalen Netzen) wird sich nicht entsprechend schnell erhöhen lassen. Der Datentransfer ist eine der großen Bremsen, in der Zeit muss die CPU häufig warten.

Ein anderes Problem, zumindest für meine Wünsche, liegt darin, das in der Regel nur darstellbare Farben gespeichert werden. Wenn ich also in Arbeitsschritt A die Helligkeit aller 8-Bit PixelPixel im Glossar erklärt verdopple, dann werden spätestens Pixelwerte über 255 abgeschnitten. Es gibt keinen Raum nach oben, ebensowenig Raum nach unten. Im Arbeitsschritt B (mit einer anderen Software durchgeführt) kann man daher auf die superhellen Werte nicht mehr zugreifen. Ein gewisser begrenzter Spielraum bis Werte abgeschnitten werden wäre wünschenswert, es muss dazu nicht gleich mit Floats gearbeitet werden.

OpenEXR könnte viele Probleme vom Prinzip her lösen. Leider ist OpenEXR auch umfangreich. OpenEXR bietet eine Menge Flexibilität und viele Features, die für Compositing, Effekte und Renderings nützlich, für einen Austausch von Film-Clips aber nicht nötig sind. Die offizielle Umsetzung (die man verwenden kann) ist von weiteren Bibliotheken abhängig und war zumindest in der Vergangeheit leider nicht unter jedem relevanten OS ganz so einfach zu bauen, wie man es sich erhoffen würde.

Natürlich ist der CodecCodec im Glossar erklärt nicht die einzige Baustelle, ein einfaches Dateiformat, welches zugehörige Tonspuren und ein paar zusätzliche Daten mit unterbringt, ist auch nötig. Aber da gibt es schon Formate, auf die man aufsetzen kann.

Ich würde daher den folgenden Ablauf vorschlagen:

1. Import aus {DV, MPEG-2MPEG-2 im Glossar erklärt, H.264, H.265, ProResProRes im Glossar erklärt, RAW, ...} ins Intermediate.

2a. Verarbeitung mit Programm A (z.B. Vorverarbeitungen, wie entrauschen).
2b. Verarbeitung mit Programm B (z.B. Schnitt).
2c. Verarbeitung mit Programm C (z.B. Farbanpassungen).
...
3. Ausgabe in ein hochwertiges Ausgabe- bzw. Archivformat. Das könnte auch der Intermediate-Codec sein, muss es aber nicht.
4. Umwandlung in die jeweiligen Vertriebsformate.



Antwort von Goldwingfahrer:

Codecs wie H.264 oder H.265 sind technisch toll.

H.264 ist kein CoDec sondern ein Kompressionsverfahren.

Alle (theoretischen) Standards der ITU-T beginnen mit einem Großbuchstaben und einem Punkt,
gefolgt von drei Ziffern - z.B.: H.261, H.263, H.264 (Video-Komprimierung), G.723 (Audio-Komprimierung) u.v.m.

Die (praktische) Implementierung als Software z.Bsp.namens x264 /x265 dagegen beginnt mit einem Kleinbuchstaben ohne Punkt.

H.264 ist als Kompressionsverfahren ein Teil des umfassenden Standards "MPEG-4 AVC", das wäre ein Videoformat. MP4 wäre ein Kontainerformat, in dem AVC enthalten sein darf.



Antwort von TheBubble:


Ist denn bei einem solchen Vorhaben auch der Übergang in den Frequenzraum neu zu gestalten oder wird auf die bereits entwickelten DWTs, DSTs oder DWTs zurück gegriffen ?

Wenn möglich und sinnvoll, dann ist gegen einen Rückgriff auf Bekanntes erstmal nichts auszusetzen. Ich würde aber ggf. radikal vereinfachen und entschlacken wollen, lieber erstmal möglichst überschaubar und verständlich und dafür eine schlechtere KompressionKompression im Glossar erklärt hinnehmen.

Was die Dekorrelation durch Basenwechsel angeht: Die "echte" DCTDCT im Glossar erklärt (JPEG, DV, MPEG-2MPEG-2 im Glossar erklärt, ...) würde ich (wie die DFT auch) vermeiden wollen, da sie Fließkommaartithmetik erfordert und damit nicht eindeutig umkehrbar ist. Es dürfte wohl auf eine oder mehrere Transformationen hinauslaufen, die in Integer-Arithmetik exakt umkehrbar sind.

Wavelets haben halt das Problem, dass sie sinnvoll auf große Kacheln (oder ganze Frames) angewendet werden sollten. Dies kann Umsetzungen schnell langsamer machen. Daher würde ich momentan blockbasierte Verfahren favorisieren.



Antwort von TheBubble:


Einen neuen CodecCodec im Glossar erklärt, incl. dem Übergang in den Frequenzraum zu entwerfen, halte ich schlichtweg für schwierig, um nicht den Begriff "unmöglich" zu benutzen, weil nicht nur die Ressourcen fehlen sondern weil auch der Weg dorthin mit bestehenden Patenten gepflastert ist.

Glücklicherweise ist Mathematik (zumindest hier) nicht patentfähig. :-)
Es gibt diverse Transformationen, die in Frage kämen, AFAIK teils "älter" als die DCTDCT im Glossar erklärt, falls das beruhigt.

Vielleicht kannst Du nochmal den genau neu zu schreibenden Umfang beschreiben.
Letztlich die Umwandlung einer RGBRGB im Glossar erklärt Bitmap in ein komprimiertes BLOB und zurück. Die wesentlichen Bestandteile hängen vom Design ab, das kann man so pauschal nicht sagen. Mit am Aufwendigsten ist sicher die Entropiecodierung.



Antwort von WoWu:

Schau Dir mal die ICT von H.264 an, da hast Du, eigentlich was Du suchst. Sie kommt mit 45 Additionen und 18 Shifts aus und stellt so eine echte Reproduktion sicher.



Antwort von TheBubble:

Schau Dir mal die ICT von H.264 an

Hab' ich schon. :-) An H.264 schreckt mich aber ein wenig die komplizierte Verrechnung der nötigen Gewichtsfaktoren ab.

Interessant könnte auch die etwas andere Realisierung in JPEG XR sein. Einen aufwendigen Filter zur Vermeidung von Blockrändern braucht man vielleicht nicht, wenn man eh auf hohe Datenraten setzt.

Letztlich kann man sich aber auch eine eigene Realisierung einer DCT-artigen mit Integerrn arbeitenden Transformation herleiten.



Antwort von Goldwingfahrer:

Schau Dir mal die ICT von H.264 an, da hast Du, eigentlich was Du suchst. Sie kommt mit 45 Additionen und 18 Shifts aus und stellt so eine echte Reproduktion sicher.

DCT nach ICT sollte erst mal lossless möglich sein, bei einem Reencoding wirst Du aber Verluste haben, wenn Du nicht H.264s lossless mode verwendest,..

Die Transformationen an sich sind zunächst verlustlos; was am Ende Verluste bringt, ist die QuantisierungQuantisierung im Glossar erklärt der Parameter nach der Transformation in die Frequenzdomain.



Antwort von WoWu:

Dank der dir Hinweise. Hier geht es aber speziell um den Unterschied zwischen den einzelnen DCTen und im Speziellen darum, dass die, in H.264 angewandte Transformation, anders, als in andern Verfahren, verlustlos rückgewandelt werden kann, wo sonst Rundungsfehler zwischen Encoding und Decoding auftreten.
Das erlaubt u.A. eine erheblich verbesserte Vorhersage von Bildteilen, weil sich keine architekturbedingten Rundungsfehler mehr aufschaukeln können.

Was die Semantic betrifft, besteht wohl kein Problem in der Kommunikation zwischen Bubble und mir.
Dennoch, danke für die ergänznden Hinweise.



Antwort von TheBubble:

Ich würde gerne noch einmal auf die Fragen der aus Anwendersicht wünschenswerten Features zurückkommen und würde mich weiter über Feedback zu den oben von mir aufgeschriebenen denkbaren Features freuen.

Ich würde die interessanten Fragen zur Mathematik der Umsetzung daher gerne noch so lange zurückstellen oder in einen zweiten Thread auslagern, bis es noch etwas mehr Feedback aus Anwendersicht gegeben hat.



Antwort von wolfgang:

Im Grunde will ich: Ein offenes Austauschformat, das jeder ohne große Klimmzüge (d.h. einfach) in Software plattformübergreifend (Windows, Linux, Mac) verwenden kann und das eine bestimmtes Qualitätslevel garantiert. Der CodecCodec im Glossar erklärt soll klar definierte Dinge können, soll aber nicht unnötig flexibel und damit kompliziert sein.

Was ich nicht will: Diverse Codecs in jedem Tool, egal wie klein, unterstützen müssen.

So erstrebenswert dieses Ziel ist - so weit sind wir meines Erachtens mit der Hinwendung von UHD/4K mit 10bit und besseren Farbsampling von diesem Ziel entfernt. Verschiedene Plattformen verwenden verschiedene Codecs und Formate - und je nach Tool und Plattform ist halt mal der, oder mal der CodecCodec im Glossar erklärt besser.

Wenn man mit einem Apple arbeitet wird man wohl ProResProRes im Glossar erklärt nutzen. Wenn man in der Windows-Welt arbeitet, wird man etwa in Edius derzeit Codecs wie XAVC oder dem Canopus HQX den Vorzug geben. Und in Vegas etwa wird man gerne zu XAVC oder dem Cineform CodecCodec im Glossar erklärt greifen. Und für raw wird man wieder andere Werkzeuge wählen und umgekehrt.

Fragen der Dekodierfähigkeit in 10bit oder besser aber auch die Vorschaufähigkeiten sind in verschiedenen Systemumgebungen verschieden und werden damit unterschiedliche Antworten finden.

Aus meiner Sicht hatten wir die Einheitlichkeit noch nie und ich sehe auch nicht dass wir sie für alle Werkzeuge bekommen. Ich sehe darin aber auch kein großes Problem, bis auf den Umstand dass die Antworten auf diese Frage zumindest derzeit einfach unterschiedlich ausfallen.



Antwort von TheBubble:


Wenn man mit einem Apple arbeitet wird man wohl ProResProRes im Glossar erklärt nutzen. Wenn man in der Windows-Welt arbeitet, wird man etwa in Edius derzeit Codecs wie XAVC oder dem Canopus HQX den Vorzug geben.
Ich vermute, dass bisher ProResProRes im Glossar erklärt auf gutem Weg ist, ein Austauschformat zu sein. Leider nur für Mac-Nutzer. Das der Bedarf besteht, sieht man schon daran, dass Kamerahersteller diesen CodecCodec im Glossar erklärt inzwischen in ihre Kameras integrieren.



Antwort von TheBubble:

Wir können IMO auch gerne wieder zu den Fragen der Umsetzung eines neuen Codecs zurückkehren.

Eine der scheinbar einfachsten Dinge ist eine Farbunterabtastung. Die gängige Meinung scheint zu sein, dass in der Postproduktion mindestens 4:2:24:2:2 im Glossar erklärt erforderlich ist. Sollte man sehr hochwertig arbeiten und 4:4:44:4:4 im Glossar erklärt verwenden, dann stellt sich die Frage nach einer Farbunterabtastung natürlich erst gar nicht.

Allerdings muss man nicht zwingend 4:2:24:2:2 im Glossar erklärt in den beiden gängigen Varianten machen. Es kommen noch weitere Muster in Betracht (4:4:0, Schachbrettmuster, die beiden Chroma-Werte zueinander versetzen, ...).

Hierbei stellt sich nun die Frage: Welches Muster verwenden?



Antwort von WoWu:

Aber das Goal ist doch ganz sicher nicht, einen CodecCodec im Glossar erklärt zu kreieren, der mal gerade einen eingeschränkten Teil von UHD abdeckt sondern etwas über den Tellerrand hinaus zu gehen und das betrifft ja die Framrate, Farbraum, Dynamic , ja sogar in Bezug auf den Ton.
Und wenn man über Austauschformate nachdenkt, sollte man das InterfaceInterface im Glossar erklärt dafür auch nicht aus dem Auge verlieren. Nicht jede DatenrateDatenrate im Glossar erklärt und jedes Bildformat ist über jede Schnittstelle zu bringen.
Wenn Du also über ein neues FormatFormat im Glossar erklärt nachdenkst, würde ich bei den Anforderungen von UHD Phase 2 anfangen, nachzudenken, sonst ist er alt, vor er fertig ist.



Antwort von TheBubble:


Wenn Du also über ein neues FormatFormat im Glossar erklärt nachdenkst, würde ich bei den Anforderungen von UHD Phase 2 anfangen, nachzudenken, sonst ist er alt, vor er fertig ist.
Natürlich. Allerdings beabsichtige ich über den Tellerrand zu schauen und zumindest jede Festlegung und Vorgehensweise (auch wenn sie noch so einfach erscheint) zu hinterfragen und nicht einfach nur zu übernehmen, weil man es seit längerem einfach so macht.

Die Farbunterabtastung ist einer der ersten Schritte, darum möchte ich sie gleich am Anfang detailierter betrachten. Augenblicklich bin ich von der Idee eines Schachbrettmusters aus Chroma-Werten angetan und beabsichtige dies erst mal zu testen. Ich erhoffe mir damit eine bessere Qualität bei der Rückwandlung (Interpolation). Das ich damit inkompatibel zu allen bisher gängigen Farbunterabtastungsvaianten wäre, ist mir schon klar. Ob die Idee praktikabel ist, müsste sich erst zeigen, vielelicht macht sie auch erst bei den späteren Abläufen im CodecCodec im Glossar erklärt Probleme.

Wenn Interesse besteht, kann ich die Idee näher erläutern.

Als einzige definitiv zu unterstützende Schnitstelle betrachte ich unkomprimierte RGB-Bitmaps. Ich beabsichtige im Moment nicht einmal definitiv eine YCbCr-Schnittstelle zum CodecCodec im Glossar erklärt (habe mich aber noch nicht festgelegt). Aber viele Fragen, auch im Bezug zur Schnittstelle, sind für mich noch ungeklärt.



Antwort von WoWu:

Du bürdest Dir damit aber auch eine Last auf, die sich nicht mal die Sonys, Apples oder Panasonic dieser Welt aufgeladen haben.
Die haben einfach was Vorhandenes genommen und ein paar proptietär Daten dazu gepackt, um es als eigenes Produkt verwursten zu können.



Antwort von TheBubble:

Du bürdest Dir damit aber auch eine Last auf, die sich nicht mal die Sonys, Apples oder Panasonic dieser Welt aufgeladen haben.
Das mag durchaus sein. :-)

Ich habe noch einmal nachgedacht: Die Kernfrage waere, ob man unbedingt YCbCr nach REC 2020 transportieren koennen will, oder ob R'G'B' reicht. Wenn ja, dann sollte man auch die "gaengigen" Varianten der Farbunterabtastung unterstuetzen. Wenn nein, dann haette man sich erstmal alle Moeglichkeiten offen gelassen.

Nebenbei ueberlege ich auch, ob man InterlacedInterlaced im Glossar erklärt evtl. nur in einfacher Form unterstuetzen sollte, als reine Notloesung fuer altes Material, um die entscheidenden Teile vom CodecCodec im Glossar erklärt selbst moeglichst einfach zu halten.



Antwort von WoWu:

@Bubble

Ich bin da ein ganz schlechter Ratgeber weil ich Standards zu schätzen gelernt habe und für mich Intermediates nur eine Krücke sind, um schwachbrüstige Rechner dazu zu bewegen überhaupt in der Bildverarbeitung in halbwegs vertretbarer Zeit klar zu kommen.
Austauschformate gibt es auch standardisiert und mit den meisten, heutigen Rechnern ist es auch kein Problem mehr in qualitativ hochwertigen, reduzierten Verfahren zu arbeiten und damit selbst erweiterten Bildanforderungen in der Verarbeitung gerecht zu werden.
Wie du weisst haben wir bereits vor mehr als zehn Jahren auf 10 bit I- FrameFrame im Glossar erklärt AVC gesetzt der sowohl in der Akquisition also auch in der Nachbearbeitung und auch als Austauschformat zu den Sendern dient.
Damit haben wir nie zu einer Intermediat "Krücke" greifen müssen und können heute noch auf ein umfangreiches Archiv uneingeschränkt zugreifen ohne dass wir zwischenzeitlich auch nur einmal umkopieren mussten und ohne dass uns die Qualität über die Transcodierung flöten geht.
Das hat uns bisher nur Vorteile gebracht, die kein Intermediate hätte leisten können.
Unser Vorteil war immer, von vornherein genügend Rechenpower und Software zu haben, die mehr als proprietäre Formate unterstützt.
Das ist heute leichter als je zuvor, denn leistungsfähige Rechner gibt es mittlerweile für wenig Geld und auch Software, die mehr kann als nur ein Format.
Daher stellt sich mir die Frage, was ein neuer (noch proprietärer) CodecCodec im Glossar erklärt bringen soll, was es noch nicht gibt.

Vielleicht habe ich den Zweck ja noch nicht so ganz verstanden, aber ich kann den unverzichtbaren Vorteil wirklich nicht erkennen.
Im professionellen Umfeld wird das ohnehin nichts denn ein solcher CodecCodec im Glossar erklärt würde die Hürde der Akzeptanz nicht nehmen oder vermutlich erst in 10 -oder mehr- Jahren.
Selbst die bekannten "klassischen", wie ProResProRes im Glossar erklärt & Co haben fast 10 Jahre dazu gebraucht und auch das nur, weil sie auf dem MPEG2MPEG2 im Glossar erklärt Standard aufsetzen.
Etwas Neues wird es also sehr viel schwerer haben.



Antwort von TheBubble:


Ich bin da ein ganz schlechter Ratgeber weil ich Standards zu schätzen gelernt habe und für mich Intermediates nur eine Krücke sind, um schwachbrüstige Rechner dazu zu bewegen überhaupt in der Bildverarbeitung in halbwegs vertretbarer Zeit klar zu kommen.

Ich habe absolut nichts gegen Standards, ich hoffe das ist nicht falsch angekommen, und würde einen guten, offenen und frei verfügbaren Standard analog zu den Erfolgen von PNG und JPEG gut finden. Der Erfolg der letztgenannten beruht aber zu großen Teilen auch darauf, dass die Standards einerseits nicht irrsinnig kompliziert sind und es andererseits eine kostenfrei ohne nennenswerte Auflagen nutzbare, im Source vorliegende, Umsetzung gibt.

Leider gibt es im Videobereich noch immer nichts vergleichbares.

AVC ist gut, leider gibt es keine gute, kosten- und auflagenfrei einsetzbare Implementierung (wie es sie z.B. für PNG und JPEG gibt). Auch ist AVC viel zu umfangreich, um es "mal eben" selbst umzusetzen.

Wie du weisst haben wir bereits vor mehr als zehn Jahren auf 10 bit I- FrameFrame im Glossar erklärt AVC gesetzt der sowohl in der Akquisition also auch in der Nachbearbeitung und auch als Austauschformat zu den Sendern dient.

Nur wie lange wird es dauern, bis I-Frame AVC von Softwareherstellern kostenfrei um- bzw. eingesetzt werden kann?

Das es z.B. bis heute kaum freie/kostenlose NLEs gibt, hat IMO sehr mit der Verfügbarkeit und den Eigenheiten der Standard-Codecs zu tun. Die Kosten für die Verbreitung des inzwischen alten MPEG-2MPEG-2 im Glossar erklärt sind anscheinend noch immer so hoch, dass z.B. Windows 8 diesen CodecCodec im Glossar erklärt nicht mehr mitbringt.

Auch kommen ständig neue Standard-Codecs hinzu. Nehmen wir nur mal den Privatbereich: Vor ca. 20 Jahren gab es noch die Analogtechnik, dann kam DV und ein wenig MPEG-2MPEG-2 im Glossar erklärt in Standard Definition, gefolgt von MPEG-2MPEG-2 im Glossar erklärt in Form von HDV. Es folgte der für Full-HD erforderliche Schritt nach AVCHDAVCHD im Glossar erklärt bzw. H.264. Es wird bald H.265 folgen. Von all diesen Codecs gibt es noch diverse Untervarianten, gerne für professionelle Ausrüstung genutzt, sowie Containerformate, in denen sie stecken können.

D.h. jedes heute und in näherer Zukunft sinnvoll einsetzbares Programm müsste mindestens DV, MPEG-2MPEG-2 im Glossar erklärt, H.264 und H.265 im Im- und Export plus der gängigen Containerformate beherrschen. Jeder Anwender müsste geschult werden, wie er die unterschiedlichen Encoder der Programme so bedient, dass bei den erforderlichen Zwischendateien kein zu großer Qualitätsverlust eintritt.

Ein wiklich beliebig einsetzbarer Intermediate könnte für viele Programme das Austauschproblem lösen. Klar, man könnte auch schon heute Sequenzen als JPEGs exportieren, mit weiterer Software bearbeiten und wieder ins NLE importieren, aber wirklich schön ist das nicht. So steckt derzeit jeder Anwender weitestgehend in seinem NLE fest und kann nicht so leicht auf zusätzliche Spezialprogramme zurückgreifen.

Daher stellt sich mir die Frage, was ein neuer (noch proprietärer) CodecCodec im Glossar erklärt bringen soll, was es noch nicht gibt.

Siehe oben. :-)

Was aber schon der Versuch definitiv bringt: Mehr Wissen und Verständis, da man sich intensiv mit dem Themengebiet beschäftigen muss. :-)

Selbst die bekannten "klassischen", wie ProResProRes im Glossar erklärt & Co haben fast 10 Jahre dazu gebraucht und auch das nur, weil sie auf dem MPEG2MPEG2 im Glossar erklärt Standard aufsetzen.
Etwas Neues wird es also sehr viel schwerer haben.
Das wird tatsächlich so sein. Wobei ich glaube, das der Erfolg von ProResProRes im Glossar erklärt nichts mit MPEG-2MPEG-2 im Glossar erklärt zu tun hat, sondern mit erfolgreicher Vermarktung. Es ist mir durchaus klar, dass es schon Versuche in die Richtungen Intermediate und hochqualitatives Archiv gab, die allerdings nie die Verbreitung von z.B. ProResProRes im Glossar erklärt erreicht haben. So gibt es z.B. von Dirac eine für Intermediates geeignete Variante.

Aber wie gesagt, auch wenn ein neuer CodecCodec im Glossar erklärt praktisch ungenutzt bleibt, kann man am Entwurf viel lernen.



Antwort von WoWu:

D.h. jedes heute und in näherer Zukunft sinnvoll einsetzbares Programm müsste mindestens DV, MPEG-2MPEG-2 im Glossar erklärt, H.264 und H.265 im Im- und Export plus der gängigen Containerformate beherrschen. Jeder Anwender müsste geschult werden, wie er die unterschiedlichen Encoder der Programme so bedient, dass bei den erforderlichen Zwischendateien kein zu großer Qualitätsverlust eintritt.
Ich denke, genau an dieser Stelle liegt einer der springenden Punkte, weil allein der Sprung in der DCTDCT im Glossar erklärt von MPEG2MPEG2 im Glossar erklärt nach H.264 und nochmals, was die 4x4 in H.265 angeht, ziemlich massive Probleme bereiten dürfte, in einem CodecCodec im Glossar erklärt befriedigend abgehandelt zu werden.
Von einem Intermediate erwarte ich aber auf alle fälle, dass es keine Einschränkungen in der Bildqualität bezüglich meines Original"Footages gibt.
Das bedeutet aber, dass eben auch die Vorzüge de H.265 beinhaltet sein müssen.
Ich weiss, dass sich viele vom Aufdruck "visual lossless" beeindrucken lassen, aber ich denke, Du gehörst nicht dazu und weisst um die Verbesserungen.
Ich wüsste im Augenblick aber eben nicht, wie man solche Entwicklungen in einen neuen CodecCodec im Glossar erklärt einfliessen lassen könnte.
Nur würde ich als Anwender in einem neuen CodecCodec im Glossar erklärt nicht darauf verzichten wollen, weil sonst der Originalcodes wieder die bessere Option wäre.

Also ... wenn Intermediate, käme für mich nur einer in Frage, bei dem ich nicht 3 Schritte in der Bildqualität zurück muss, weil ich dann vielleicht ein paar Sekunden schneller arbeiten kann oder mir einen anständigen Rechner spare.
Intermediate ist und bleibt für mich eine Krücke und wenn Hersteller nicht die Standards unterstützen, dann wäre das für mich eher ein Grund das NLe zu wechseln, als den Codierstandard.
Klar kosten die MPEGs -speziell die neuen- reichlich Geld aber wenn das bei den Billigpreisen der NLEs nicht vom Hersteller aufgebracht werden kann, muss ich mir dafür nicht den mühsam erkämpften Bildstandard in Bezug auf die Qualität versauen lassen.
Zumal es sowohl gute Codecs gibt als auch ausreichend schnelle Rechner und gute, Software.
Vielleicht ist der "free" Markt in Bezug auf Software ein anderer, aber das ist nicht mein Ding, da kann ich nicht mitreden.
Nur hat es sich ja auch in der Vergangenheit gezeigt, dass nicht alles, wo "free" oder "open" draufsteht, auch kostenlos drin steckt.

So ein CodecCodec im Glossar erklärt, wie Du ihn in Angriff nimmst, ist ganz sicher nicht billig. Wenn Du aber den Markt adressierst, wird das schwierig.



Antwort von TheBubble:

Von einem Intermediate erwarte ich aber auf alle fälle, dass es keine Einschränkungen in der Bildqualität bezüglich meines Original"Footages gibt.
Das bedeutet aber, dass eben auch die Vorzüge de H.265 beinhaltet sein müssen.
Ich weiss, dass sich viele vom Aufdruck "visual lossless" beeindrucken lassen
An dieser Stelle will ich auch gar keine falschen Erwartungen aufkommen lassen: Jeder nicht sowieso völlig verlustlos arbeitender CodecCodec im Glossar erklärt (Spezialfälle mal aussen vor) wird in der Praxis mindestens durch die erstmalige Rekompression einen gewissen Qualitätsverlust bedeuten. Auch wenn das bei vernünftiger Vorgehensweise (=hohe Datenraten, aber geringer als un- oder verlustfrei-komprimiert) kaum jemand merkt, braucht man das nicht schönzureden.

Man muss aber weder den Qualitätsverlust durch kleine DatenrateDatenrate im Glossar erklärt ausufern lassen noch Panik vor kleinen Abweichungen verbreiten. Ein PNG kann als JPEG in hoher Qualitätsstufe gespeichert werden und niemand wird den Unterschied als unzumutbar empfinden.



Antwort von WoWu:

Das ist wohl wahr, wenn das die einzige Transformation im Workflow ist, dann mag das unbemerkt bleiben.
Ist es aber unglücklicherweise meistens nicht und weil so gut wie alles mit irgendwelchen Verlusten behaftet ist, kommen hinterher di Wundertüteninhalte dabei heraus.
Man müsste sich für ein solches Vorhaben also schon sehr genau die Workflows ansehen, um die Auswirkungen auf das jeweilige Codec-Tool festzustellen.
Sowas ist aber mehr die Arbeit einer mittleren Forschungsgruppe.
Wobei ja ein Grossteil davon schon gemacht wurde. Nicht umsonst gibt es ja in neueren Codes entsprechende Änderungen und Anpassungen.

Ich will damit nur sagen, dass der CodecCodec im Glossar erklärt allein vielleicht noch den "nicht sichtbaren" Verlust bringt, aber das Verhalten im Workflow dennoch (fast) unberechenbar.
Dieses "visual lossless" ist einfach Augenwischerei, mit der die Hersteller die Anwender blenden.
In Wirklichkeit müssten sie auch die Nebnwirkungen in einem komplexen Workflow beschreiben, die ihr "lossless" CodecCodec im Glossar erklärt anrichtet denn die sind alles Andere als "lossless".



Antwort von cantsin:

Noch mal naiv gefragt: Warum nicht einfach XAVC Intra 200 nehmen? (Was ja nichts anderes ist als Sonys Marketingbezeichnung für 10bittiges Intraframe-h264 in der höchsten Qualitätsstufe, im MXFMXF im Glossar erklärt OP1A-Container.) Ausser höherer CPU-/GPU-Last ggü. ProRes/DNxHD/Cineform spricht doch alles dafür?!?



Antwort von WoWu:

Ich halte das fúr eine ausgesprochen gute Lösung.
Nun hat Sony leider ein Feature implementiert, das zwar als Option im Standare vorgesehen ist und zur Bildoptimierung beiträgt, aber eben als Option, sodass es nicht jeder Player, der nach dem Standard implementiert ist, lesen können muss und das FormatFormat im Glossar erklärt zurückweist.
Deshalb braucht man auch immer ein Plug-In dafür, das zunächst diese Daten abstreift, um wieder standardkonform zu sein.
Deswegen würde ich gleich ein standard I-Frame AVC vorziehen.
Und weil die Luft nach oben hin selbst für HD bis 900 Mbit/sMbit/s im Glossar erklärt offen ist, hat man wohl im Augenblick damit das, was man an Intermediate überhaupt haben kann, solange es das nicht skalierbar in 265 gibt.-Und das sehen wir voraussichtlich noch eine ganze Weile nicht.



Antwort von TheBubble:

@WoWu (es dürfen sich auch alle Anderen angesprochen fühlen):

Eine Sache konnte ich bisher nicht völlig zufriedenstellend klären. Das hat zwar erst einmal nur indirekt mit einem CodecCodec im Glossar erklärt zu tun, ist aber dennoch von Bedeutung:

So beschreibt z.B. Rec. BT.709 eine Übertragungsfunktion für den linearen Eingangswertebereich von 0 bis 1,0. Die Grenzen werden explizit erwähnt, für 1,1 ist streng genommen nichts definiert.

Was aber tun, wenn man plötzlich wirklich mit "Superweiß" konfrontiert wird? Wie also z.B. 1,1 abbilden, wenn ein Abschneiden explizit nicht erwünscht ist, um Spielraum für weitere Bearbeitungsschritte zu erhalten?

Der umgekehrte Fall ist fast noch unangenehmer, auch hier ist nur ein Bereich von 0 bis 1,0 festgelegt:

Was mit "Superweiß" und "Tiefschwarz" (d.h. Integer-Werte über 235 bzw. unterhalb von 16) machen? Solche Werte sind tatsächlich anzutreffen.

Den Fall, dass eine Kamera explizit "Full Range" verwendet, d.h. nicht Werte von 16-235 sondern von 0(schwarz)-255(weiß) für die Integer-Darstellung und diese korrekt abgebildet werden können, möchte ich für die Frage ausschließen. Es geht mir um die unklaren Fälle.

Die Frage ist also, wie die Übertragungsfunktion im Zweifelsfall am pragmatischsten fortsetzen. Einfach die Grenzen erweitern und oben den exponentiellen Verlauf fortsetzen? Oder oben und unten jeweils mit der letzten festgelegten Steigung linear fortsetzen?

Oder doch lieber einfach Werte ausserhalb des erlaubten Bereichs abschneiden (dürfte viele Anwender nicht unbedingt freuen)?



Antwort von WoWu:

Farbraumtransformation ist das magische Wort, wenn man all die Probleme vermeiden möchte, die es im Amateurbereich immer wieder gibt, weil Farbräume munter gemischt werden.
Der seriöse Umgang mit solchen Werten ist doch in der Literatur weitreichend dokumentiert.



Antwort von TheBubble:

Nein, es geht mir nicht um die Farbräume, die haben damit nichts zu tun. Es geht ums reine "Gamma"-Encoding und die korrekte Entfernung des solchen, um linear weiterarbeiten zu können.

Klar ist das dokumentiert, aber konkrete Ratschläge, wie sich Software verhalten soll, wenn Werte, die offensichtlich ausserhalb einer Spezifikation liegen, verwendet werden, habe ich noch nichtgefunden.

Man wird hier aber wohl eh mit der ein oder anderen Ungenauigkeit rechnen müssen. So sind die nichtlinearen Transformationen der ganzen "flachen" Aufnahmemodi diverser Kameras ja leider auch eher schlecht dokumentiert.



Antwort von MLJ:

@TheBubble
Dein Vorhaben in allen ehren aber ich denke "WoWu" hat Recht was die Etablierung eines neuen Intermediate CodecsIntermediate Codecs im Glossar erklärt angeht, besonders wenn die Qualität nicht leiden soll. Auch was "Lossless" oder "Visual Lossless" angeht so wird hier etwas entscheidendes vergessen: Unter allen Windows Versionen gibt es diese ITU/EBU Standards nicht da die Microsoft Codecs für YUVYUV im Glossar erklärt (UYVY, YUY2, YVYU) nur DEKODIEREN und das im Full Range, ganz zu schweigen von dem uraltem Bug des Color Bleedings, besonders sichtbar bei Rot, der nie korrigiert wurde.

HuffYUV, Lagarith, MagicYUV und UtVideo arbeiten nur "Lossless" solange der Farbraum nicht geändert wird, also RGBRGB im Glossar erklärt nicht als YUY2 komprimiert werden soll, lediglich YUY2 zu YUY2 funktioniert "Lossless", alles andere nicht trotz hoher Datenraten denn jeder Formatwandel bringt Verluste mit sich, auch bei "Lossless" Codecs.

Lediglich I420 und IYUV können mit dem Intel YUVYUV im Glossar erklärt CodecCodec im Glossar erklärt komprimiert und dekomprimiert werden der aus 12 BitBit im Glossar erklärt am Eingang in 24 BitBit im Glossar erklärt umwandelt, Full Range, da bleibt also auch nichts verlustfrei. Wenn du nun einen CodecCodec im Glossar erklärt entwickeln möchtest der das alles in Betracht zieht, dann musst du zuerst ganz zurück an die Basis, besonders wenn der neue Intermediate auf allen Systemen laufen soll.

Zitat:
Nein, es geht mir nicht um die Farbräume, die haben damit nichts zu tun. Es geht ums reine "Gamma"-Encoding und die korrekte Entfernung des solchen, um linear weiterarbeiten zu können.

Klar ist das dokumentiert, aber konkrete Ratschläge, wie sich Software verhalten soll, wenn Werte, die offensichtlich ausserhalb einer Spezifikation liegen, verwendet werden, habe ich noch nichtgefunden.

Man wird hier aber wohl eh mit der ein oder anderen Ungenauigkeit rechnen müssen. So sind die nichtlinearen Transformationen der ganzen "flachen" Aufnahmemodi diverser Kameras ja leider auch eher schlecht dokumentiert.

Zitat ende.

Gamma und Alpha sind stark von der verwendeten GraKa abhängig, nicht jede ist da gleich und ist stark abhängig von den Einstellungen und den Treibern. Und was Kameras angeht so würde ich mich mal auf die Suche nach den "White Papern" machen, da findest du solche Sachen :) Manche Hersteller geben diese frei wenn man sie höflich darum bittet, nur so am Rande ;)

Spezifikationen ? Richtlinien ? Ich bitte dich, da halten sich nicht einmal TV Sender dran und machen was sie wollen, alles Augenwischerei. Sicher, man sollte diese Dinge einhalten aber wenn etwas von Haus aus "Super White" oder "Total Black" ist kannst du nur mit einer Korrektur im NLE Schadensbegrenzung betreiben denn was so schon aufgenommen wurde korrigiert kein CodecCodec im Glossar erklärt dieser Welt in einen Standard, hier ist Hand anlegen angesagt.

Nehmen wir mal QuickTime für Windows: Nehme einen Motion-JPEGMotion-JPEG im Glossar erklärt CodecCodec im Glossar erklärt, egal von wem und öffne das mal im Windows Media Player, egal welche Version. Resultat: Full Range (0-255). Den gleichen Film öffnest du jetzt in QuickTime. Resultat: Limited Range (16-235). Windows ist da ganz anders als QuickTime und du fragst dich jetzt warum das wichtig ist ?

Ganz einfach: Fast alle Video und Animations Programme "bedienen" sich bei diesen Playern um Filme darzustellen und greifen auf die registrierten Module der Player zu. Ist schon seit 1998 so und hat sich bis heute nicht geändert und ist ein Aspekt den du dabei in Betracht ziehen solltest. Warum glaubst du sind die erforderlichen Versionen den Programmen beigelegt ? ;)

Dir mag es vielleicht "zu viel" an Optionen zu geben für die bereits angesprochenen Intermediate CodecsIntermediate Codecs im Glossar erklärt, aber man muss sich damit beschäftigen und vor allem auch verstehen, dann kann man sie richtig Anwenden. Daher mein Tipp an dich an dieser Stelle: Mache dich damit vertraut und tauche noch tiefer hinein denn wenn du das ganze erst einmal ab der Basis verstanden hast ist die Welt nur noch halb so wild.

Bitte verstehe mich nicht falsch, ich wollte nicht damit sagen das du keine Ahnung hast. Ich glaube nur das du das ganze falsch angehst da du diverse Optionen am liebsten ausblenden möchtest die wichtig sind und sich nicht von alleine lösen oder automatisch korrigieren lassen.

Diese ganzen Optionen und Möglichkeiten gibt es deswegen, weil diese Codecs so vielseitig sind aber die meisten sich nicht damit auseinander setzen und nicht einmal das Handbuch zu ihren Programmen vollständig lesen. Also wenn du dich da wirklich mit diesen hohen Ansprüchen an so ein Projekt wagen möchtest wünsche ich dir viel Glück, meinen Respekt hast du, ehrlich.

Cheers

Mickey

P.S.: Scheinbar ist schon eine Firma auf diese Idee von dir gekommen:

http://www.ispreview.co.uk/index.php/20 ... dband.html

http://www.digitaltveurope.net/346362/v ... echnology/

Website der Firma:
http://www.v-nova.com/en/products-and-technology.html

Etwas Skepsis ist hier angesagt denn es handelt sich um Meldungen vom 1.April 2015, könnte also ein Scherz sein.



Antwort von WoWu:

@Bubble

Ich halte es auch weniger für eine Frage des Codecs, als vielmehr für eine Frage des Workflows. Gerade mit solchen Problemen "dealt" ja ACES, wenn es darum geht, unterschiedliche Formate, in Bezug auf Farbraum und Dynamik, miteinander zu kombinieren, indem (auch) innerhalb eines Arbeitsraumes die SW/und WS Werte an die zugeordneten Stellen transformiert werden, um dann über RRT bzw. ODT an die richtigen Zielpunkte zu gelangen.
Man kann natürlich solche Transformationsprozesse auch einem CodecCodec im Glossar erklärt vorschalten, aber man verliert die Flexibilität.
Daher denke ich, sie sind im Workflow besser angesiedelt.

Es gibt doch für die IDTs Implementierungsguidelines. Schau doch mal nach, wie die das gemacht haben.
Ich habe leider keinen Link, sonst hátte ich ihn gepostet, aber ACES ist ja open und das könnte zumindest einen klugen Hinweis geben.
Ich halte ACES ja auch (gerade deswegen) für einen sehr guten Ausgangspunkt einer Kompression.



Antwort von TheBubble:

So, ich habe mich wieder etwas mit dem Codec-Projekt beschäftigen können.

Einer der anfänglichen Fragen war ja, ob Chroma-Subsampling (z.B. 4:2:2) verwendet werden soll. Der Idealfall wäre natürlich gar kein Chroma-Subsamlpling zu verwenden (also 4:4:4). Das würde ich auch grundsätzlich empfehlen.

Nehmen wir aber mal an, dass es dennoch zum Einsatz kommen soll. Der Einfachheit halber gehe ich im Folgenden nur auf 4:2:24:2:2 im Glossar erklärt ein.

Der erste Schritt ist die Unterabtastung, also von 4:4:44:4:4 im Glossar erklärt nach 4:2:24:2:2 im Glossar erklärt, d.h. aus (RGB)(RGB)(RGB)(RGB) wird z.B. (YUV)(Y)(YUV)(Y) oder (Y)(UV)(Y)(Y)(UV)(Y). Hier kommen mehrere Vorgehensweisen in Betracht:

- Point-sampling/Nearest-neighbor, ohne Tiefpassfilterung. Im Grunde eine Einladung an Chroma-Aliasing. Hat jedoch den großen Vorteil, dass die jeweiligen Chroma-Werte über beliebig viele 4:4:44:4:4 im Glossar erklärt -> 4:2:24:2:2 im Glossar erklärt -> 4:4:44:4:4 im Glossar erklärt Zyklen erhalten werden können. Ein weiterer Vorteil ist, dass die Chroma-Werte immer direkt über einem Luma-Wert liegen. Rekonstruktion (Interpolation) der fehlenden Werte auf beliebige Art möglich.

- Box-sampling. Gewisser Tiefpasseffekt, jedoch nicht optimal. Etwas besser, was Aliasing angeht. Die Chroma-Werte liegen mittig zwischen zwei Luma-Werten. Wird z.B. von HuffYUV verwendet. Es sind beliebig viele Zyklen ohne ArtefakteArtefakte im Glossar erklärt möglich, sofern zur Rekonstruktion Nearest-neighbour verwendet wird. Andere Rekonstruktionsverfahren müssen die Lage der Chroma-Werte berücksichtigen, werden aber zur Akkumulation von Fehlern beim Durchlaufen von vielen Zyklen neigen.

- Gewichtetes-sampling (z.B. Zeltfunktion, Gaussfunktion). Gute Filterung zur Vermeidung von Aliasing möglich, allerdings werden alle Werte in jedem Zyklus verändert, was zur Akkumulation von Fehlern führt. Chroma-Werte können direkt über einem Luma-Wert liegen.

Als Rekonstruktionsverfahen kommen in Betracht:

- Nearest-neighbour: Im Zusammenspiel mit Box-Sampling beliebig viele Zyklen ohne weitere Verluste möglich. Als Artefakt können treppenförmige Stufen an Farbkanten auftreten.

- Linear/höhere Ordnung/adaptiv: Besserer Gesamteindruck, keine Stufenbildung. Nachteil: Bei jeder Unterabtastungsmethode ausser Point-Sampling akkumulieren sich die Defekte über alle durchlaufenen Zyklen.

Die Frage, was man verwendet, liegt stark in der Prioritätensetzung. Box-Subsampling mit Nearest-neighbour-Interpolation ist beliebt, bildet aber unter Umständen Treppenstufen und ist nicht komplett frei von Aliasing. Point-Subsampling hingegen kann mit besseren Interpolatoren kombiniert werden, kann jedoch leichter Aliasing erzeugen.

Die "korrekten" Vorgehensweisen hingegen akkumulieren über mehere Zyklen hinweg Fehler und sind für einen Intermediate-Codec daher nicht unproblematisch und evtl. nur beim Ausspielen (z.B. vor der Umwandlung in ein Vertriebs-Format wie H.264) anzuwenden.

Ich tendiere dazu, für hohe Ansprüche Chroma-Subsampling abzuschreiben. Viele (in der Regel ignorierte) Probleme für eine gute Rekonstruktion nach 4:4:44:4:4 im Glossar erklärt kommen noch hinzu, diese habe ich hier noch nicht einmal ansatzweise angesprochen. Ich experimentiere aber noch mit einem anderem Unterabtastsystem, dass Datenmengen wie 4:2:24:2:2 im Glossar erklärt erzeugt, aber die Samples anders verteilt.



Antwort von WoWu:

Moin Bubble.

Stellt sich die Frage nach der Unterabtastung nicht erst, wenn man mal eine Datenratenbilanz gemacht hat und für seinen CodecCodec im Glossar erklärt genauer festgelegt hat, in welchem Bereich man arbeiten will ?
Wenn ich eine Zieldatenrate von 150-200 Mbit/sMbit/s im Glossar erklärt favorisiere habe ich schon fast keine wirklichen Optionen mehr, jedenfalls deutlich weniger, als wenn ich 300-400 Mbit/sMbit/s im Glossar erklärt anpeile.



Antwort von TheBubble:

Hallo WoWu,

Stellt sich die Frage nach der Unterabtastung nicht erst, wenn man mal eine Datenratenbilanz gemacht hat und für seinen CodecCodec im Glossar erklärt genauer festgelegt hat, in welchem Bereich man arbeiten will ?
welche Datenraten für eine bestimmte Qualität möglich sind, kann man im Anfangsstadium nur schwer voraussagen. Das hängt sehr stark vom Erfolg bzw. vom Ineinandergreifen der Schritte Prediktion, Dekorrelation und Entropiekodierung ab.

Verlustbehaftet arbeiten kann man im Prinzip auch ohne Unterabtastung, indem man z.B. nach einer Transformation (z.B. DCT) einfach mehr Koeffizienten wegwirft. Das hätte theoretisch sogar den Vorteil, dass man bei Bedarf auch mehr Details speichern könnte. Bei der verlustbehafteten Chromaunterabtastung sehe ich als Vorteil, dass sie im Vergleich sehr wenig Rechenleistung erfordert.

Für den Anfang werde ich erstmal eine konstante Qualität bei welchselnder DatenrateDatenrate im Glossar erklärt anstreben. Das ist einfacher.



Antwort von WoWu:

Hallo Bubble,
mir schon klar, nur das Nachdenken über einen neuen Intermediate fängt -nach meinem subjektiven Verständnis- doch eigentlich am Einsatzort an, also im NLE mit all seinen Unzulänglichkeiten und da fällt die verarbeitbare DatenrateDatenrate im Glossar erklärt zumindest massgeblich ins Gewicht.
Sonst könnte man sich ja immer auf "transparent" einlassen und bräuchte gar keinen Intermediate mehr.

Ich habe übrigens über die Fragestellung bezüglich des Mappings nochmal -erfolglos- nachgedacht und in dem Zusammenhang einmal versucht herauszufinden, wie bei ACES damit umgegangen wird.
Leider gibt es da keine verwertbaren Einlassungen zu. -Jedenfalls habe ich -trotz intensiver Bemühungen, keine gefunden.
Das könnte im Umkehrschluss bedeuten, dass auch ACES mit solchen "Spezialitäten" -z.B. Überschwinger aus begrenzten Bereichen oder IR Offsets- seine Probleme haben könnte.
Wäre also nicht uninteressant, wenn hier im Forum jemand ist, der da genauere Informationen, über die Erstellung solcher IDTs, speziell aus nicht standardkonformen Signalen, hätte.




Noch was unklar? Dann in unserem Forum nachfragen
Zum Original-Thread / Zum Postproduktion allgemein-Forum

Antworten zu ähnlichen Fragen:
ORBX: der freie Video-Codec der Zukunft? Das Tor zur Cloud?
Intermediate Codec Qualitäts-Vergleich - ProRes, DNxHD and Cineform
Kameras werden in Zukunft Dinge erkennen können
Ein Blick in die Zukunft: Scharfstellbare Displays statt Brillen?
Ist Netflix ein Modell für die Zukunft des Fernsehens?
Kino der Zukunft
kino der zukunft?
Der Zeichensatz der Zukunft
Film müsste auf DVD passen, ABER...
Zukunft der V(DSLR) - LEICA CEO im Interview
DNS als ultimatives Speichermedium der Zukunft
ZEITREISEN - SPUREN AUS DER ZUKUNFT? Doku ??
Sounds für "Die Stadt der Zukunft"
Colorgrader/in gesucht für zusammenarbeit in der zukunft
WVIL – Konzept-Kamera der Zukunft von Artefact?
One-Girl Production - Vorbild für das TV der Zukunft?
News: AMD Kaveri - günstiger Vorbote der PC-Zukunft?
Trailer zu meinem Film "Die Stadt der Zukunft"!
4K 3D 120fps: Douglas Trumbulls Vision der Zukunft des Filmemachens
Editorials: Popcorn Time - Zukunft oder Verderben der Filmindustrie?
Die Zukunft der Visual Effects im Kino: Lebensecht gerenderte Menschen?
Dolby Cinema mit HDR und Atmos-Sound: Das Kino der Zukunft?
Vorschau von Intermediate Datei nicht flüssig
Intermediate Format nach Cinema DNG Bearbeitung
Kurznews: Der Sony XAVC Codec erklärt
Suche zuverlässige Lösung der DSLR Codec Interpretation...

















weitere Themen:
Spezialthemen


16:9
3D
4K
ARD
ARTE
AVCHD
AVI
Adapter
Adobe After Effects
Adobe Premiere Pro
After effects
Akku
Akkus
Apple Final Cut Pro
Audio
Aufnahme
Aufnahmen
Avid
Band
Bild
Blackmagic
Blende
Book
Brennen
Cam
Camcorder
Camera
Canon
Canon EOS 5D MKII
Capture
Capturing
Clip
ClipKanal
Clips
Codec
Codecs
DSLR
Datei
Digital
ENG
EOS
Effect
Effekt
Effekte
Export
Fehler
Festplatte
File
Film
Filme
Filmen
Filter
Final Cut
Final Cut Pro
Format
Formate
Frage
Frame
HDR
Hilfe
Import
JVC
Kabel
Kamera
Kanal
Kauf
Kaufe
Kaufen
Layer
Licht
Live
Lösung
MAGIX video deLuxe
MPEG
MPEG-2
MPEG2
Mac
Magix
Magix Vegas Pro
Menü
Mikro
Mikrofon
Mikrophone
Monitor
Movie
Musik
Musikvideo
Nero
News
Objektiv
Objektive
PC
Panasonic
Panasonic GH2
Panasonic HC-X1
Pinnacle
Pinnacle Studio
Player
Premiere
Projekt
RED
Recorder
Red
Render
Rendern
Schnitt
Software
Sony
Sound
Speicher
Stativ
Stative
Streaming
Studio
TV
Test
Titel
Ton
USB
Umwandeln
Update
Vegas
Video
Video-DSLR
Videos
Videoschnitt
Windows
Zoom

Specialsschraeg
17-22. Oktober / Braunschweig
Internationales Filmfest Braunschweig
21-22. Oktober / Konstanz
Konstanzer KURZ.FILM.SPIELE
6. November / Cottbus
15. FilmSchau Cottbus
9-19. November / Mannheim/Heidelberg
Internationales Filmfestival Mannheim-Heidelberg
alle Termine und Einreichfristen