Fraunhofer zeigt erste JPEG XS Implementierung auf der // NAB 2018

[slashCAM]

Produktionsfirmen und Studios versuchen seit geraumer Zeit spezielle Kabel, Switches und Schnittstellen für die Videoübertragung also in erster Linie SDI durch kommerziel...

Hier geht es zur Newsmeldung auf den slashCAM Magazin-Seiten:
Fraunhofer zeigt erste JPEG XS Implementierung auf der // NAB 2018

[WoWu]

Vielleicht zur besseren Einordnung und Verständnis, warum ein neuer Codec vor dem Hintergrund erweiterter Anforderungen entwickelt wurde, hier der Vergleich mit „Stand der Technik“ Algorithmen.

JPEG-LS und JPEG sowie sein Nachfolger JPEG-XT der eine rückwärtskompatible Unterstützung höherer Bittiefen bietet, erschweren eine präzise Ratensteuerung, und typische Implementierungen zeigen eine Latenz von einem Frame.
JPEG 2000 verwendet einen komplexen Entropie-Coder, der viele Hardware- und Softwareressourcen für Echtzeit-Implementierungen impliziert.
HEVC als Verteilungs-Codec benötigt eine große Kodierungskomplexität, ohne die Robustheit mehrerer Generationen zu gewährleisten.
VC-2 hingegen ist von geringer Komplexität, aber die angewandte Technologie liefert nur ein begrenztes BildQualität.
ProRes, wie in einem SMPTE-Offenlegungsdokument (RDD 36) dargestellt, basiert auf Makroblöcken von 16x16 Pixeln, was eine Implementierung mit niedriger Latenz unter 32 Zeilen unmöglich macht. Darüber hinaus macht die symbolische Entropiecodierung schnelle CPU-Implementierungen zu einer Herausforderung. DSC zielt schließlich auf eine ASIC-basierte Display-Komprimierung ab, was eine effiziente Implementierung auf FPGAs und GPUs schwierig macht.

Aufgrund solcher Unzulänglichkeiten der bestehenden Codecs ist JPEG XS entwickelt, der eine präzise Ratensteuerung mit einer Latenz von weniger als 32 Zeilen bietet und in ein kostengünstiges FPGA passt.
Die Komprimierungsqualität sollte VC-2 überlegen sein und gleichzeitig die Implementierung auf verschiedenen Plattformen unterstützen.

"Es dient wirklich nur dazu über ein Netzwerk einen Live-Videostream mit geringerer DatenrateDatenrate im Glossar erklärt zu übertragen ohne, dass man mit dem bloßen Auge gegenüber einer kompressionslosen Übertragung einen Unterschied wahrnimmt."

Das muss sich erst noch zeigen denn die Datenraten gestatten das durchaus.
Und ProRes war auch nichts Anderes als ein JPEG, noch dazu aus dem DCT Zweig.
Damit ist bei Xs Schluss.
Vielleicht ist PRR ja nur die Panic Reaktion vor einer möglichen Alternative ?

[iasi]

"Es dient wirklich nur dazu über ein Netzwerk einen Live-Videostream mit geringerer DatenrateDatenrate im Glossar erklärt zu übertragen ohne, dass man mit dem bloßen Auge gegenüber einer kompressionslosen Übertragung einen Unterschied wahrnimmt."

Das muss sich erst noch zeigen denn die Datenraten gestatten das durchaus.
Und ProRes war auch nichts Anderes als ein JPEG, noch dazu aus dem DCT Zweig.
Damit ist bei Xs Schluss.
Vielleicht ist PRR ja nur die Panic Reaktion vor einer möglichen Alternative ?

Die RAW-Vorteile bietet XS aber eben nicht - weshalb also XS statt eines RAW-Codec?

[Jott]

wowu glaubt/spekuliert, ProRes Raw sei JPEG XS. Warum auch immer.

[Jan]

WoWu spekuliert selten, in der Regel weiß er es.

[Jott]

Klar doch.

[WoWu]

@Iasi
Du hast es ja in der Zunahme der Bandbreitenerforderniss mit einem generellen Problem zu tun, dass sich von der Kamera bis hin zum Endverbraucher zieht.
Am vorderen Ende aber stellt sich eben die Frage, wie geht man mit 80 GBit um.
Selbst HDMI macht in seiner derzeit maximalen Ausformung 18GBit.
Wenn Du im Endgerät ohnehin nur Bruchteile des Bildes darstellen kannst, stellt sich die Frage, wo Du vorne anfängst zu reduzieren.
Dass es zukünftig immer schwerer, bis unmöglich wird, 8K in 120F 12Bit in der Kamera durchweg zu verarbeiten und als RGB raus zu geben, bedeutet, dass in dem Fall bereits ein Codec erforderlich wäre, der sich kaum mehr unter den derzeit vorhandenen findet und selbst in den heute üblichen Verarbeitungen zunehmend schwierig ist.
Die Frage stellt sich also nach Alternativen ziemlich heftig, auch im Kamerabereich, wenn man das De-Mosaicing, (aus welchen Gründen auch immer) nicht auslagern will.
Bei RAW stellt sich ebenfalls die Frage nach der Reduktion, selbst wenn man nur ein Luminanzsignal pro Pixel herausgibt.
Mit 120p und 4/8 K führt aber selbst das die heutigen Schnittstellen an ihre Limits.
Vornehmlich natürlich bei den Kameras im unteren und mittleren Preissegment denn ich weiß nicht, ob man Endverbrauchern den Umgang mit Glasfaserübertragung noch zumuten möchte.
Man muss also bereits hier über die entsprechende Reduktion nachdenken.
Aber man käme eben rd. mit einem Drittel der Menge hin, was immernoch immens ist.
Stellt sich also die Frage, an welcher Stelle man den Workflow aufbricht bzw. ob es überhaupt noch sinnvoll erscheint oder ob nicht die fertige Kompression als IP Signal hier Vorteile hat, wenn hinterher ohnehin im 12 Bit Bereich geblieben wird.
(ich gebe zu bedenken, dass 12Bit heute noch von kaum jemandem gearbeitet wird und sowas RAW vorbehalten ist, zukünftig aber Endverbrauchet Signal (PQ) ist (sein soll)).
Die Sache mit dem Weißabgleich ist schon heute bei vielen Kameras Schall und Rauch, weil die Quanteneffizienz in den meisten Kameras bereits vor dem RAW Signal ausgeglichen wird. Bliebe also nur die Farbraumneutralität, die sich in den neuen (zukünftigen) Farbräumen auch nicht mehr wirklich stellt.
Letztlich bleibt als RAW Vorteil dann nur noch die neutrale Archivierung.
Aber es gibt ja ohnehin nur wenige Firmen, die (auch in der Vergangenheit (echte)) RAW Signale ausgegeben haben denn was in zahlreichen „Entwicklungsprogrammen“ so vor sich ging, hatte auch nichts mit De-Mosaicing zu tun.
Insofern ist gar nicht auszuschließen, dass sich in der Bildverarbeitung ein Paradigmenwechsel vollzieht.
Und wie man das nun labelt ist ziemlich egal. Das haben die Firmen früher auch nicht so genau genommen und irgendwas auf ihre Verpackungen gedruckt.
Fakt ist eben, wie eingangs erwähnt, dass die Schere zwischen Anforderungen und Machbarem immer weiter auseinander geht und das offenbar auch in der verfügbaren Codierentwicklung irgendwo Grenzwerte in Bezug auf Speicherhandhabung (Latenzen) erreicht sind.
Ob XS nun die endgültige Lösung sein wird, kann bestimmt noch niemand sagen, aber es deutet zumindest gangbare Lösungen an, deren Richtung sich schon eine ganze Weile abzeichnen (Übergang auf IP Infrastrukturen).

[domain]

Mit der DCT-Transformation ist es wohl endgültig vorbei, Wavelet macht das Rennen, wie aus folgendem interessanten Artikel hervorgeht:

https://www.ibc.org/download?ac=3823

Außerdem:
"... the JPEG XS codec maintains the initial quality and can thus be used for compressed workflows in broadcast and video production pipelines.
All other codecs show much stronger quality decay, causing that JPEG XS delivers the best quality from all codecs."

[WoWu]

Jedenfalls diese alte DCT ist weg vom Fenster.
H264 hatte ja schon eine andere.
Das war nur noch ProRes von den derzeit so üblichen Codecs, das mit der ursprünglichen DCT gearbeitet hat, die auch in den alten JPEGs werkelt.
JPEG hatte ja schon in den „calls for paper“ für H265 mit angeboten, könnte aber damals keine Echtzeitfunktionalität auf ihrer WDT darstellen.
Sonst hätten wir XS wahrscheinlich schon früher gehabt.

Wir werden sehn, wie sich das alles entwickelt.

[TheBubble]

Jedenfalls diese alte DCT ist weg vom Fenster.
H264 hatte ja schon eine andere.

Nicht grundsätzlich, es kommt immer auf die Anwendung an. H264 hat eine Integer-Approximation festgelegt, auch um die Akkumulation von Rundungsfehlern im Rahmen der temporalen Kompression zu vermeiden. Z.B. bei MPEG-2 war das Problem dabei auch nie die DCT (II) selbst, sondern weil nie festgelegt wurde, wie Decoder (und Encoder) die Gleitkommaberechnungen durchzuführen hatten.

Bei Intraframe-Codecs spielt das nur eine viel geringere Rolle, da mit den Ergebnissen im Rahmen des Codecs nicht weitergearbeitet wird.

Eine DWT profitiert davon, auf viel größere Bereiche angewendet zu werden als die häufig genutzten 8x8 Blöcke. Klar könnte man auch auf viel größere Blöcke die DCT anwenden, aber der Rechenaufwand würde enorm steigen.

XS setzt vermutlich auf eine DWT, da man vor allem innerhalb der gleichen Zeile arbeiten will. Es soll ja für Live-Anwendungen geeignet sein, wo möglichst kurze Zeitverzögerungen gewünscht sind.

[mash_gh4]

Jedenfalls diese alte DCT ist weg vom Fenster.
H264 hatte ja schon eine andere.
Das war nur noch ProRes von den derzeit so üblichen Codecs, das mit der ursprünglichen DCT gearbeitet hat, die auch in den alten JPEGs werkelt.

ich glaub, da freust du dich ein bisserl zu früh!

NDI, das ja vermutlich neben den unkomprimierten AVoIP varianten gegenwärtig den größten bzw. realistischsten marktanteil und ein erfreuliches wachstum unter den hier angesprochen studio-übertragunsglösungen verzeichnen dürfte, basiert auch wieder nur auf ausgesprochen einfachen techniken, die aber für diese einfachen broadcast-zweck ausreichen dürften. ich selbst war darüber richtig erstaunt, wie simple das technisch abgewickelt wird:

https://wiki.multimedia.cx/index.php/SpeedHQ

in der praxis scheint das aber trotzdem ganz gut zu funktionieren, so wie halt auch prores/dnxhr/hqx, obwohl sie technisch eigentlich alle heillos überholt sind, wie wir alle wissen.

[WoWu]

Das ist richtig, deswegen hatte ich oben auch „derzeit so übliche“ geschrieben.
Dass es immernoch Exoten gibt, die darauf aufsetzen, wird sich wohl auch nicht ändern ... und es ist ja auch nicht so, dass solche Bilder unbrauchbar wären.
Hat man ja bei den ganzen MPEG 2 Verfahren und auch bei PR gesehen.
Es ist nur eben so, dass sich Anforderungen ändern und alte Verfahren häufig solchen Anforderungen im direkten Vergleich nicht mehr Stand halten.
Aber den Fehlern solcher Verfahren wird wohl keiner hinterher weinen.
Aber neue (andere) Verfahren sind nun mal auch nicht fehlerfrei. Wenn ich aber damit weiterreichende Anforderungen begegnen kann, ist das wenigstens ein Schritt nach vorn.

[Jott]

ProRes ist weg vom Fenster. Arri ist tot. Externe Recorder sind ebenso tot wie ihre Hersteller. Weltweiter Stillstand in der gesamten Film- und TV-Branche. An Tausenden von Highend-Projekten kann nicht weiter gearbeitet werden. Armageddon! :-)