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.
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 Codec 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 Codec sich bis dahin rechnet.
Damit wären wir auch schon bei einer möglichen Verarbeitungsarchitektur, die der Codec 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" Codec 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.
WoWu hat geschrieben: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:4 möglich sein,
- ich brauche nur 4:2:2,
- gut für eine Farbkorrektur zu gebrauchen,
- ich brauche einen Alpha-Kanal,
- (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.
hmm also geil wäre n Codec, 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 Kompression (h264 bzw. h265), damit die Datenrate 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
IMHO zeichnet sich ein Intermediate Codec 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 Codec, wie Red's R3D, Cineform, CineformRaw, JPEG2000
Dann kommen DCT basierte wie Motion JPEG, ProRes oder DNXHD - die wären mir persönlich aber schon zu verlustbehaftet.
Paralkar hat geschrieben:
Mit einer aktuellen bzw. modernen Kompression (h264 bzw. h265), damit die Datenrate 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?
Die eigentliche Frage ist doch, ob in Zukunft überhaupt noch Intermediate Codecs notwendig sein werden? Die Grösse der Speichermedien und die Rechenleistung nehmen drastisch zu. Die Zeit wird kommen, wo man in Echtzeit durch eine Timeline scrollt mit Spuren voll 4K RAW und es sich anfühlt wie DV25.
Wichtig wäre für mich, dass der Codec 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.
DV_Chris hat geschrieben:Die eigentliche Frage ist doch, ob in Zukunft überhaupt noch Intermediate Codecs notwendig sein werden? Die Grösse der Speichermedien und die Rechenleistung nehmen drastisch zu. Die Zeit wird kommen, wo man in Echtzeit durch eine Timeline 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 Bit 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 Kompression nicht wirklich herum kommen. Die Effizienz muss nur da sein und wenn man berücksichtigt, dass EHVC ein vielfaches Effizienter als beispielsweise MPEG2 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/s arbeiten und mit Distribution nichts zu tun haben.
Nach der Denke wäre nämlich ProRes auch ein reiner Distributionscodec, weil er sogar auf einer viel schlechteren DCT 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.
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 PAL 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 Codec ist für mich entweder sowas wie DNxHD, 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 ProRes gebe ich dir Recht, auch das ist für mich ein reiner Delivery Codec, weil ich an der Stelle nicht mehr danach frage was der effizienteste Codec ist, sondern nur welcher Codec kann von meinem Kunden problemos angesehen werden und sieht dabei noch recht gut aus, beides trifft auf ProRes zu.
-------------------------------------------------------
leave the gun take the cannoli
------------------------------------------------------- www.movie-grinder.com
Was spricht eigentlich dagegen, jetzt schon h264 High Profile mit Intraframe-Kompression und den bei ProRes üblichen Bittiefen und -raten als Intermediate zu verwenden? Die Bildqualität dürfte, bei gleicher Bitrate, wegen der moderneren Algorithmen besser sein als bei ProRes, DnXHD & Co. Hardware- bzw. GPU-beschleunigte Wiedergabe müsste doch ebenfalls mit allen modernen NLEs funktionieren?
Bei Hubbles Frage nach "Zukunft"s Codec 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 Format 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 Codec 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 Codec verwechseln.
Heute würde ich beispielsweise jeden I-Frame only aus AVC einem I-Frame aus Pro Res vorziehen, weil der Codec ganz erheblich verbessert ist und bei identischer Datenrate 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 Codec 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 Codec 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 Kompression 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 Codec zugreifen muss, dann doch lieber einen Standard, der nicht alle naselang von Firmen geändert wird.
cantsin hat geschrieben:Was spricht eigentlich dagegen, jetzt schon h264 High Profile mit Intraframe-Kompression und den bei ProRes üblichen Bittiefen und -raten als Intermediate zu verwenden? Die Bildqualität dürfte, bei gleicher Bitrate, wegen der moderneren Algorithmen besser sein als bei ProRes, 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.
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 Format (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 Codec 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.
-------------------------------------------------------
leave the gun take the cannoli
------------------------------------------------------- www.movie-grinder.com
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 Codec 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 Kompression 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 Codec wird (deutlich) mehr Speicherplatz verbrauchen dürfen, als andere sehr stark Komprimierende.
WoWu hat geschrieben:
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 Codec 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 Codec zugrunde liegen, es dürfen ruhig auch (realistische) Wünsche sein, die nur durch eine Neuentwicklung erfüllbar sind.
@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:0, die bleiben in 12 Bit 4:2:0 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 Bit 4:2:0 oder 16 Bit 4:2:2, 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:2 zu machen wenn das Ziel 4:2:0 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 Lossless Variante unbezahlbar und die Unterschiede zu komprimierten Formaten die bearbeitet wurden SIND am Ende sichtbar. Weiterhin beanspruchen die RAW und Lossless Varianten die Hardware kaum da gute Karten diese RAW Formate nativ unterstützen.
Was soll nun ein "neuer" Intermediate Codec noch können ? Nun, will man das beste Ergebnis so bleibt eigentlich nur die RAW oder Lossless 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 Codec 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 Codec und warum ? Weil Apple Rechner und QuickTime das nativ verarbeiten können. Warum glaubst du ist nur noch der Intel I420/IYUV Codec 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 Codec Frage eher sehr individuell und daher kaum auf jeden Nutzer anwendbar. Möchtest du etwa einen neuen Codec 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 Codec der Welt wird das zurückholen.
Daher finde ich den Ansatz hier falsch denn es gibt genug Intermediate Codecs, 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 Format zu bleiben um die Qualität oben zu halten.
Ein altes, aber immer noch aktuelles Format ist DV. Digital vom Band über Firewire 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 Farbkorrektur in knapp 5 Minuten, mit Farbkorrektur in etwa 15 Minuten durch, in HD zwischen 35 bis 50 Minuten.
Fazit:
Man kann es auch übertreiben nach der Jagd nach noch mehr Pixel, 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.
Nee, Mickey, gar nicht.
Nur die Bestellung, dass H265/265 ausschliesslich ein Delivery Codec ist, würde ich bestreiten, denn dem ist nicht so.
Wenn jemand H264/265 lediglich als Delivey Codec 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 Format ist DV. Digital vom Band über Firewire 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..
@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:0 (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 Codec ist: Wenn ich ein 4:2:0 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 Codec, 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 Format und Parametern der Aufnahme wieder speichern, das meinte ich ;)
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- Codec 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 Codec 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.
MLJ hat geschrieben:
Was soll nun ein "neuer" Intermediate Codec 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 Codec 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 ProRes 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 ProRes 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 Codec unterstützen, denn so verwenden z.B. schon im Privatbereich verbreitete HD-Kameras Codecs von MPEG-2 über H.264 bis inzwischen H.265 in diversen Varianten. Irgendwo müsste also ein Umwandlungsvorgang davor stehen, wenn man nur einen Codec 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 Pixel 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 Codec 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-2, H.264, H.265, ProRes, 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.
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.
WoWu hat geschrieben:
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 Kompression hinnehmen.
Was die Dekorrelation durch Basenwechsel angeht: Die "echte" DCT (JPEG, DV, MPEG-2, ...) 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.
WoWu hat geschrieben:
Einen neuen Codec, 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 DCT, falls das beruhigt.
WoWu hat geschrieben:
Vielleicht kannst Du nochmal den genau neu zu schreibenden Umfang beschreiben.
Letztlich die Umwandlung einer RGB 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.
Zuletzt geändert von TheBubble am Mo 23 Mär, 2015 00:59, insgesamt 1-mal geändert.
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.
WoWu hat geschrieben: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.
WoWu hat geschrieben: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 Quantisierung der Parameter nach der Transformation in die Frequenzdomain.
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.
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.
TheBubble hat geschrieben: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 Codec 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 Codec besser.
Wenn man mit einem Apple arbeitet wird man wohl ProRes 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 Codec 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.
wolfgang hat geschrieben:
Wenn man mit einem Apple arbeitet wird man wohl ProRes 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 ProRes 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 Codec inzwischen in ihre Kameras integrieren.
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:2 erforderlich ist. Sollte man sehr hochwertig arbeiten und 4:4:4 verwenden, dann stellt sich die Frage nach einer Farbunterabtastung natürlich erst gar nicht.
Allerdings muss man nicht zwingend 4:2:2 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?
Aber das Goal ist doch ganz sicher nicht, einen Codec 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 Interface dafür auch nicht aus dem Auge verlieren. Nicht jede Datenrate und jedes Bildformat ist über jede Schnittstelle zu bringen.
Wenn Du also über ein neues Format nachdenkst, würde ich bei den Anforderungen von UHD Phase 2 anfangen, nachzudenken, sonst ist er alt, vor er fertig ist.
Rechtliche Notiz: Wir übernehmen keine Verantwortung für den Inhalt der Beiträge
und behalten uns das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
