Herkömmliche Video-over-IP Lösungen für den Studiobetrieb führen entweder zu einem hohen Bandbreitenbedarf bei der Übertragung unkomprimierter Daten oder zu einer spürbaren Verzögerung aufgrund der für die Kompression erforderlichen Verarbeitungszeit. Bei 4k- und 8k-Videos ist dies eine noch größere Herausforderung als bei HD, da ein Datenstrom unkomprimiert sehr leistungsstarke Ethernet-Netzwerke von 25–100Gbit/s erfordert oder zur Kompression spezielle Hardware für die Implementierung benötigt wird. Mit JPEG XS wurde ein Mezzanine-Kompressionscodec entwickelt, der eine extrem niedrige Latenz besitzt und in Software mit Standardgeräten implementiert werden kann. Allerdings muss bei der Softwareimplementierung darauf geachtet werden, wie die zu verarbeitenden Daten auf mehrere parallele Rechenprozesse (Threads) verteilt werden und wie groß die Anzahl der Threads ist, um eine optimale Latenz zu erreichen. Anhand einer Fallstudie für 4k Video-over-IP wird in diesem Beitrag erläutert, wie ein solches System mit COTS (Commercial Of The Shelf)-Komponenten implementiert werden kann, welche Softwarearchitektur erforderlich ist und wie weit die Latenz reduziert werden kann.
Einführung
In den letzten Jahren sind Studios, Broadcaster und Streamingdienste in der Videoproduktion vermehrt von SDI-Leitungen auf IP-basierte Netzwerke umgestiegen. Dies ermöglicht eine höhere Flexibilität im Workflow, bei der Verbindung zwischen Geräten und erlaubt auch die direkte Anbindung von Workflows an Cloud-Dienste. Um diese hohe Flexibilität zu erhalten, werden COTS-Geräte und softwarebasierte Workflows empfohlen.
Die Herausforderung besteht dabei darin, niedrige Latenzzeiten bei gleichzeitig hohem Durchsatz mit den softwarebasierten Kompressionseinheiten zu gewährleisten. Dies ist besonders wichtig für Live-Produktionen, bei denen Überwachung, Steuerung und Fernsteuerung stattfinden. Solange die Datenpipeline nicht vollständig auf einen IP-basierten Workflow umgestellt wurde, müssen auch hybride Systeme mit SDI-Eingang, -Ausgang und IP-Übertragung in Betracht gezogen werden, die dem Workflow zusätzliche Verzögerungen hinzufügen. In diesem Beitrag werden beide Herausforderungen behandelt, der Wechsel zwischen hybriden Workflows und die Latenz von softwarebasierten Kompressionssystemen.
JPEG XS als neuer Mezzanine-Codec
Mit JPEG XS wurde kürzlich ein optimierter Mezzanine-Bildcodec bei der ISO standardisiert [1], der eine algorithmische Latenz von maximal 16 Zeilen bei der Kodierung und 16 Zeilen bei der Dekodierung besitzt, in einigen speziellen Modi sogar weniger. In der Praxis kann diese Latenz mit speziellen Hardware-Implementierungen (ASIC, FPGA) umgesetzt werden, aber solche Ansätze eliminieren den Vorteil der Verwendung von Standardgeräten.
Die niedrige algorithmische Latenz von JPEG XS wird im Allgemeinen durch eine asymmetrische Wavelet-Transformation und eine Ratenberechnung für jeweils 16 Zeilen mit einem begrenzten Vorausschaubereich erreicht. Für Software-Implementierungen ist ein solches Design allein jedoch nicht ausreichend, da JPEG XS nicht in der Lage ist, den Durchsatz für 4k oder 8k Bilder in Echtzeit auf nur einem Prozessorkern zu erreichen. Die Systemarchitektur muss daher weiter verfeinert werden, um eine Parallelisierung auf mehrere Prozessorkerne zu ermöglichen. Glücklicherweise besitzt JPEG XS ein inhärent paralleles Design, das es erlaubt, die Quellbilder nach der Wavelet-Transformation in Scheiben (Slices) von 16 Zeilen Höhe aufzuteilen und die Ratenkontrolle für diese Scheiben unabhängig voneinander durchuführen. Eine ausführlichere Erläuterung der Merkmale und der Funktionsweise von JPEG XS ist in [3] zu finden.
Für diesen Artikel ist es wichtig zu wissen, dass die Slices unabhängig voneinander von einzelnen Software-Threads verarbeitet werden können. Bei einem 4k Video (3840 x 2160 Pixel) zum Beispiel kann das Bild in 2160/16 = 135 Slices aufgeteilt werden. Um einen hohen Verwaltungsaufwand durch die Thread-Verwaltung zu vermeiden, können mehrere aufeinanderfolgende Slices zu Slice-Gruppen zusammengefasst werden, die von demselben Thread verarbeitet werden, wodurch die Anzahl der Threads reduziert wird. In diesem Beitrag wird das richtige Gleichgewicht zwischen der Anzahl der Slices in einer Slice-Gruppe, der Anzahl der Threads und der damit verbundenen Latenzzeit erläutert.
Aufbau
In dieser Fallstudie wird ein typisches Setup mit Computerservern und 10GbE Netzwerk für eine Videoverarbeitungspipeline (siehe Abbildung 1) verwendet.
- Eine Videoquelle erzeugt einen Videostrom an einer SDI-Schnittstelle (12G SDI).
- Server 1 ist mit einer SDI-Capture-Karte am Eingang und einer 10 GbE-Ethernet-Schnittstelle am Ausgang ausgestattet. Die Datenübertragung für die IP-Übertragung basiert auf RTP-Paketen gemäß RFC 9134 [6] und SMPTE ST 2110-22 [4]. Im Inneren des Systems findet eine Videoverarbeitung und -kodierung statt, um die Daten an den nächsten Verarbeitungsknoten weiterzuleiten. Da nur die E/A- und Kodierungslatenzen bewertet werden sollen, fehlen im Weiteren Angaben zur Videoverarbeitungszeit.
- Auf Server 2 geschieht das Entgegengesetzte: Die Daten werden über eine IP-Schnittstelle empfangen, dekodiert und dann über eine SDI-Playout-Karte wieder ausgegeben.
In einem ersten Schritt (Design 1) wird nun die Latenz bei älteren E/A-Karten und einer sequentiellen Verarbeitung ermittelt, in einem zweiten Schritt wird ein neues Design (Design 2) mit aktuellsten E/A-Karten und einer gestaffelten Verarbeitungspipeline verwendet.
Design 1 (Standardausführung)
Die typische Verarbeitung ist bildbasiert und sequentiell (Abbildung 2) [2]. Das bedeutet, dass die SDI-Eingangskarte zunächst ein komplettes Videobild erfasst, bevor eine Datenübertragung in den PC-Speicher eingeleitet wird. Die Datenübertragung erfolgt in der Regel über Direct Memory Access (DMA) Transfer Methoden. Bei einem 4k Bild kann die Datenübertragung über eine PCIe 2.0 x8-Schnittstelle bis zu einem Drittel eines Bildes bei 60 Hz dauern. Dann wird eine Kodierung eingeleitet, die ebenfalls bis zu einem Bild dauern kann, je nach Leistung des Computers. Länger darf sie nicht dauern, da sonst die Rechenleistung des Servers für den Dauerbetrieb nicht ausreicht. Am Ende der Datenverarbeitung in Server 1 werden die Daten paketiert und über einen IP-Stack an der Ethernet-Schnittstelle an das Netzwerk gesendet. Die Gesamtlatenzzeit beträgt etwa 5 Bilder.
Die Latenzen für Design 1 sind in Tabelle 1 zusammengefasst.
Design 2 (Ausführung mit extrem niedriger Latenzzeit)
Wie bereits erwähnt, verfügt JPEG XS über das Konzept der Slice-basierten Verarbeitung, bei der die Slices unabhängig voneinander kodiert werden. Dies kann für die parallele Kodierung und Dekodierung des Bildes genutzt werden [5]. Für ein Design mit extrem niedriger Latenzzeit sollten die SDI-Eingangs- und Ausgangskarten Subframe-DMA-Übertragungen ermöglichen. Das heißt Teile des Bildes sollten bereits während der Erfassung des Bildes weitergeleitet werden können. Ein Subframe ist idealerweise eine ganzzahlige Anzahl von Slices, z. B. 3 Slices mit 3*16=48 Zeilen. Dadurch können die ersten Zeilen (z. B. eine Slice-Gruppe mit drei Slices) in den PC-Speicher übertragen werden, während der Rest des Bildes erfasst wird.
Ein erster Kodierungs-Thread (Thread 1) bei Design 2 kann gestartet werden, wenn die ersten beiden Slice-Gruppen in den PC-Speicher übertragen wurden. Der nächste Thread (Thread 2) kann gestartet werden, wenn die nächste DMA-Übertragung abgeschlossen ist und so weiter. Nachdem die erste Slice-Gruppe von Thread 1 kodiert wurde, kann sie paketiert und an die IP-Schnittstelle gesendet werden. Ein oder mehrere separate Threads für die Bearbeitung der Bilddaten ermöglichen ein paralleles Arbeiten bei der Kodierung und Übertragung. Dadurch wird eine Art Daten-Wasserfall Konzept realisiert.Hinweis: Einige Kodierungs-Threads können schneller sein als andere und ihre Arbeit früher beenden, auch wenn sie später gestartet wurden. Wenn ein nach Bildteil geordneter Transport von Paketen erwünscht ist (In-Order), muss ein Synchronisationspunkt oder eine Neuordnung der Daten für die Paketierung, die Datenübertragung und das Traffic Shaping zur IP-Schnittstelle eingerichtet werden. Das JPEG XS RTP-Protokoll ermöglicht jedoch auch einen ungeordneten Transport, bei dem komplett berechnete Bildteile sofort übertragen werden (Out-of-Order). Der Empfänger hat dann die Aufgabe, den Datenstrom (die Bildteile) wieder in der richtigen Reihenfolge zusammenzusetzen. Dies ist möglich, da JPEG XS RTP-Pakete in ihrem Header die Zielposition im Bild tragen.Die Latenzen sind in Tabelle 2 zusammengefasst (Beispiel mit einer Slice-Gruppe von drei Slices).
Die Verzögerung vom SDI-Eingang bis zum SDI-Ausgang ohne IP-Behandlung und Übertragung kann zu folgenden Werten addiert werden: 0,71 ms + 0,06 ms + 1,72 ms + 1,15 ms + 0,06 m s = 3,7 msDies bietet genügend Reserve für die IP-Behandlung und die Synchronisierung auf das nächste Bild bei 60 Bildern pro Sekunde (Bilddauer: 16,6 ms @60fps).
Kompressionsperformance
Die Leistungstests wurden auf einem AMD Threadripper 3970X durchgeführt, um den durchschnittlichen Durchsatz pro Prozessorkern für die Kodierung und Dekodierung zu berechnen.
Für das Fraunhofer JPEG XS SDK 4.1 führte dies zu den folgenden Werten:
Implementierung
Fraunhofer implementierte ein JPEG XS System mit extrem niederiger Latenz, das auf den oben genannten Prinzipien basiert und einen AMD Threadripper sowohl für die Kodierung als auch für die Dekodierung verwendet. Das Quellmaterial wird dabei von einer 4k Kamera erzeugt. Um eine ordnungsgemäße Synchronisierung von Encoder-Eingang und Decoder-Ausgang zu gewährleisten, erzeugt ein Taktgenerator ein Tri-Level-Sync-Signal, auf das sich die Kamera und die Playout-Karte synchronisieren. Die JPEG XS-Implementierungen bei Encoder und Decoder verwenden jeweils nur ein einzelnes Slice pro Slice-Gruppe und nutzen 16 Threads sowohl für die Codierung als auch für die Decodierung. Dieses Design sorgt für eine möglichst geringe Latenzzeit, da jedes Slice von einem eigenen Prozessorkern verarbeitet wird. Allerdings entsteht durch die überlappende Wavelet-Transformation ein gewisser zusätzlicher Overhead. Für den Transport wird ein RTP-basierter JPEG XS-Stream verwendet, der der neuesten IETF-Spezifikation [6] folgt. Das bedeutet, dass die Encoder-Threads die kodierten Daten an das Netzwerk weiterleiten, sobald sie verfügbar sind, und der Decoder die Pakete in der richtigen Reihenfolge wieder zusammensetzen muss. Messungen mit einem IP-Analysator (Tektronic prism) haben gezeigt, dass dieses System eine Ende-zu-Ende-Latenz (Encoder-in bis Decoder-out) von 180 Zeilen erreicht.
Da die Verarbeitungskette bildsynchron laufen soll, wird die Playout-Karte als Bildpuffer genutzt und das Bild genau 1 frame nach dem Eingang an der SDI-Capturekarte an der Playout-Karte wieder ausgegeben.
Fazit
Es wurde ein Prototyp eines 4k JPEG-XS softwarebasierten Systems mit extrem niedriger Latenzzeit entwickelt. Durch sorgfältiges Design und Zuweisung von Verarbeitungsthreads auf eine Multicore-CPU können Latenzen von weit unter 1 Bild erreicht werden. Dies kann durch Aufteilung der Arbeitslast auf einer Slice- oder Slicegruppen-Granularität mit mehreren Threads realisiert werden. Die Anzahl der Threads und die Latenz können an die verfügbare Anzahl von CPU-Kernen und die Leistung pro Kern angepasst werden.
Für die Datenübertragung über das IP-Netzwerk wurde eine slicebasierte Paketierung und eine Out-of-Order-Übertragung gewählt. Dies ermöglicht die direkte Verpackung in IP-Pakete und den sofortigen Versand nach Abschluss der Codierungsaufgabe. Auf der Empfängerseite werden die Slices neu sortiert und in das Bild eingefügt.In einem synchronisierten System (mit einer Bildsynchronisation an der Playout-Karte) kann daher eine Verzögerung von nur einem Bild zwischen Eingang und Ausgang der Übertragungskette erreicht werden.
