Was sind die Audio over IP Standards AES67, SMPTE ST 2110, AMWA NMOS?
von Andreas Hildebrand, Artikel aus dem Archiv vom
AV-over-IP-Experte Andreas Hildebrand gibt in PROFESSIONAL SYSTEM einen Überblick über offene Standards und neueste Entwicklungen im Bereich netzwerkbasierter Echtzeitübertragung von professionellen Audio- und Videosignalen.
Bildkomposition: Sven Schuhen (Bild: Sven Schuhen)
In der AV-Branche ist das Thema Standards zurzeit in aller Munde. Zwei Ansätze lassen sich hierbei unterscheiden: Einerseits werden proprietäre Lösungen durch eine erhebliche Adaptionsquote zu einem Quasi-Standard, wie es Audinate mit Dante bereits geschafft hat oder wie es die SDVoE-Alliance mit dem BlueRiver-Chipsatz des Chipherstellers Semtech gerade vorantreibt. Letztere ist jedoch gestützt von einer großen Initiative von Herstellern, die sich in einer Non-Profit-Organisation vereint haben. Andererseits gibt es Bestrebungen offene Standards zu etablieren, die zum Teil ebenfalls durch herstellergetriebene Non-Profit-Verbände unterstützt bzw. mitgestaltet werden. Hierzu zählen neben der Milan-Initiative, welche auf Basis der AVB-Technologie ein angepasstes Anwendungsprotokoll entwickelt und über die wir in einem anderen Artikel dieser Ausgabe berichten, auch die Standards AES67, das auf AES67 basierende SMPTE ST 2110 und AMWA NMOS.
Der AES67 Standard der Audio Engineering Society (AES) zum „Austausch von hoch-performanten Audiosignalströmen über IP-Protokolle“ (so der etwas holprig übersetzte Titel), der im September 2015 veröffentlicht wurde, dürfte mittlerweile den meisten ein Begriff sein. AES67 definiert auf Grundlage standardisierter Protokolle sozusagen den „kleinsten gemeinsamen Nenner“ für den IP-basierten Austausch von Audiosignalen.
Zwischenzeitlich hat sich der Standard im Bereich der professionellen Audio-Anwendungen etabliert und wird von nahezu allen bekannten Technologien (Ravenna, Livewire, Q-Lan, Dante, WheatNet u. a.) unterstützt. Unter Einbeziehung der Dante-basierten Geräte haben die Anwender mittlerweile die Wahl aus über 1500 Produkten.
Der AES67 Standard wird seitens der AES Standards Community aktiv gepflegt; in der mittlerweile 3. Auflage von 2018 sind kleinere Unstimmigkeiten und missverständliche Formulierungen bereinigt worden; dabei ist auf vollständige Rückwärtskompatibilität zum ursprünglichen Standard von 2015 geachtet worden. Ein wesentliches Novum in der 2018er Edition ist jedoch die Aufnahme eines sog. „PICS“ , das es Herstellern, Systemplanern und Endanwendern gleichermaßen ermöglicht, die einzelnen Unterschiede und Freiheiten, die im AES67 Standard definiert werden (z. B. hinsichtlich der unterstützten Paketzeiten, zusätzlich unterstützter Abtastraten oder anderer optionaler Parameter), für die jeweiligen Geräte genau heraus zu filtern. Dabei werden sämtliche Anforderungen und Freiheiten, die im Standard – oftmals mit normativer Sprache verklausuliert – enthalten sind, einzeln tabellarisch aufgeführt und vom Hersteller entsprechend der spezifischen Eigenschaften des jeweiligen Gerätes dort vermerkt. Damit haben die Anwender wiederum die Möglichkeit, einzelne Geräte hinsichtlich ihrer über die im Standard festgelegten Mindestanforderungen hinausgehenden Möglichkeiten zu bewerten und so vorab zu vergleichen, ob zwei Geräte verschiedener Hersteller im Rahmen der gewünschten Operationsparameter miteinander kompatibel sind. Noch sind zwar nur für wenige Geräte entsprechende PICS veröffentlicht, es wird aber erwartet, dass die Hersteller hier entsprechend reagieren, zumal das PICS einen normativen Bestandteil des AES67 Standards darstellt.
Leider ist das Überschreiten von Grenzen zwischen Herstellern oder Technologien in der Praxis nicht ganz so einfach: Da AES67 ein Interoperabilitätsstandard und keine eigenständige Lösung ist, werden übergeordnete Systemfunktionalitäten wie Geräteerkennung, Verbindungsmanagement und eine einheitliche Geräteverwaltung, die eine vollständige Lösung ausmachen, zwar im Standard informativ erwähnt, aber eben nicht normativ vorgeschrieben. Im Prinzip kann jeder Hersteller für seine AES67-Schnittstellen entscheiden, wie er diese Dinge handhaben möchte – und dies auch tun. Um nun verschiedene AES67-fähige Geräte im gleichen Netzwerk miteinander nutzen zu können sind je nach Hersteller und Technologie verschiedene unterschiedliche Softwarelösungen erforderlich, um vorhandene Geräte und Datenströme zu erkennen und zu verwalten sowie um die Signale zwischen den unterschiedlichen Geräten zu routen.
AES67 ist dafür entwickelt worden, den kleinsten gemeinsamen Nenner zwischen Audiogeräten zu nutzen um eine Interoperabilität herzustellen. Da dies jedoch nur für den grundsätzlichen Aufbau des Audiostreams gilt, müssen externe Software-Lösungen her, die AES67 Geräte im Netz erkennen und das Routing der Audioverbindungen bewerkstelligen können. Sogenannte SIP-Server gibt es von verschiedenen Herstellern. (Bild: ALC NetworX)
Während in Ravenna die Funktion Discovery über das DNS-SD Protokoll (durchgehend in Form von mDNS, besser auch bekannt als „Bonjour“), erfolgt und der Verbindungsaufbau mittels RTSP eingeleitet wird, hat sich Audinate für den Dante AES67-Modus dazu entschieden, exklusiv das SAP-Protokoll zu verwenden. Da darüber hinaus im Dante-System auch keine Möglichkeit besteht, die benötigten SDP-Daten mittels manuellen Eingriffs zu extrahieren bzw. zu hinterlegen, muss bei der Verknüpfung von Geräten verschiedener Systemtechnologien also eine Protokollübersetzung stattfinden. Hierzu kann der von ALC NetworX entwickelte und auf der Ravenna Webseite frei zum Download verfügbare RAV2SAP-Konverter verwendet werden, der darüber hinaus auch noch die manuelle Eingabe von SDP-Daten ermöglicht, um auch Geräte anderer Systemtechnologien (z. B. Livewire oder Q-Lan) einbinden zu können.
NMOS bietet anders als AES67 und SMPTE ST 2110, die jeweils eine Technologie zum Transport von Audio- und Videodaten dar-stellen, eine komplette Lösung, die auch das Erkennen von NMOS-kompatiblen Geräten im Netzwerk und das Management der Verbindungen bietet. (Bild: AMWA)
Nachdem im Bereich der netzwerkbasierten Audiosignalübertragung mit AES67 nun ein weltweit anerkannter Standard vorlag, war es natürlich nur konsequent, auch einen vergleichbaren Standard für den Bereich der professionellen Videoproduktion zu erarbeiten. Dieses Themas hat sich die SMPTE (Society of Motion Picture and Television Engineers) angenommen, die aus den Vorgaben der VSF (Video Service Forum) den ST 2110 Standard zur „Übertragung von professionellen Medianinhalten“ über administrierte IP-Netze erarbeitet hat. Hierbei handelt es sich um einen Standard, der die synchronisierte Übertragung von individuellen Mediaessenzen in Form einzelner Streams innerhalb eines Netzwerkes definiert. So wird zum Beispiel ein SDI-Signal nicht wie bei SMPTE ST 2022-6 als ein gebündelter Stream bestehend aus Video-, Audio- und Metadaten (SDI ancillary data) übertragen, sondern in drei oder mehr eigenständige Signalströme aufgesplittet. Dabei werden die Videosignalanteile als sog. „Raw“-Daten, d. h. nur die aktiven Signalkomponenten (Bilddaten) ohne die typischerweise bei einem SDI-Signal in den horizontalen und vertikalen Austastlücken enthaltenen Audio- und Metadatenanteile, übertragen. Gleichermaßen werden die im SDI enthaltenen Audiosignale und erweiterten Metadaten in einem oder mehreren separaten Audiostreams sowie einem Ancillary Data Stream übertragen. Die Synchronisation der einzelnen Streams zueinander wird dabei über die Einbindung des Precision Time Protocols (PTP) ermöglicht. Die genaue Einbindung in den ST 2110 Standard wird dabei über einen weiteren SMPTE Standard – ST 2059 – definiert.
Aufgrund seines Umfangs und der Absicht, diesen Standard zeitnah an neue Anforderungen und Formate anpassen zu können, wurde er modular, d. h. in mehrere Dokumente aufgeteilt, aufgebaut. Nach Veröffentlichung der Basisdokumente Ende 2017 wurden im Verlauf des Jahres 2018 bereits weitere Teile veröffentlicht; aktuell umfasst der ST 2110 Standard folgende Dokumente:
ST 2110-10: System Timing & Definitions – definiert den Transport-Layer und die Synchronisation (SMPTE2059, Clocks, RTP, SDP etc.)
ST 2110-20: Uncompressed Active Video – definiert das Datenformat (Payload Format) für die Übertragung von aktivem, unkomprimierten Videoinhalt (RFC4175, RTP, SDP, Constraints)
ST 2110-21: Traffic Shaping and Delivery Timing for Uncompressed Active Video – definiert das Sendeverhalten und die Pufferanforderungen für Komponenten, die Videosignale nach ST 2110-20 übertragen (traffic shaping requirements)
ST 2110-30: PCM Digital Audio – definiert das Datenformat für die Übertragung von linearem PCM Audiosignalen (AES67, Constraints)
ST 2110-31: AES3 Transparent Transport – definiert das Datenformat für die bit-transparente Übertragung von AES3 Audiosignalen (basierend auf dem Ravenna AM824-Format)
ST 2110-40: Transport of SMPTE Ancillary Data – definiert das Datenformat für die Übertragung von SDI Begleitdaten (ancillary data – RFC 8331)
Ein Vergleich der verschiedenen AV over IP Technologien und welche Schichten des OSI-Layer Models sie dafür nutzen. (Bild: Andreas Hildebrand)
Weitere Dokumente (u. a. zur Übertragung von leicht-komprimierten Videodaten – light + mezzanine compression) sind bereits in Arbeit. Aus Sicht der Audio-Community stellt sich natürlich die Frage, inwieweit AES67-Komponenten in ST2110-Netzwerken eingesetzt werden können. Vorausschauenderweise hat hier die SMPTE nicht wieder einen eigenen Standard definiert, sondern verweist in ST 2110-30 auf AES67. Allerdings hat die SMPTE aufgrund spezifischer Anforderungen aus dem zugrunde liegenden Applikationsumfeld einige zusätzliche Festlegungen („Constraints“) definiert. Die kritischsten Änderungen betreffen dabei die Unterstützung der in ST 2110-10 und ST 2059-2 definierten veränderten Arbeitspunkte (operational parameters) für die Synchronisation. Zusätzlich wurden – über die entsprechenden Mindestanforderungen von AES67 hinaus – weitere optionale Paketformatierungen mit höheren Audio-Kanalzahlen sowie kürzeren Paketlatenzen (packet times) definiert. In der Praxis hat sich aber bereits gezeigt, dass diese Anforderungen von den meisten AES67-Implementierungen ohne Probleme erfüllt werden können. Eine genauere Betrachtung der Gemeinsamkeiten und Unterschiede sind in einem Whitepaper der A.I.M.S. zusammengetragen.
Beiden zuvor genannten Standards ist gemeinsam, dass sie ausschließlich die Synchronisation, den Transport, die Formatierung und die notwendige Beschreibung der jeweiligen Mediadaten definieren. Damit lassen sich zwar auf technischer Ebene die Datenströme zwischen Geräten verschiedener Hersteller austauschen, jedoch fehlen noch wesentliche Funktionalitäten, um vollständige Systeme bauen zu können. So werden vor allem Festlegungen in den Bereichen Advertising & Discovery, Connection Management und Network Control benötigt, um ein grundlegendes Zusammenspiel der verschiedenen Komponenten zu gewährleisten. Ohne gemeinsame Funktionsschnittstellen in diesen Bereichen wäre man gezwungen, hersteller-spezifische Methoden und Werkzeuge zu verwenden, wäre also defacto wieder auf einige wenige kooperierende Hersteller festgelegt.
Beispiel einer SMPTE ST 2110 Anwendung mit Veranschaulichung der unterschiedlichen Datenpakete im Netz. Alle Datenströme haben eine gemeinsame PTP Sync Basis. (Bild: SMPTE)
In diese Bresche springt jetzt die Advanced Media Workflow Association (AMWA) mit ihren NMOS-Spezifikationen. Im Rahmen der NMOS-Aktivitäten werden Spezifikationen und Schnittstellen für grundlegende, übergeordnete Systemfunktionalitäten in typischen ST 2110- und AES67-Netzwerkumgebungen erarbeitet und festgelegt. Dabei basieren die Festlegungen auf sogenannten „User Stories“, die die aus Anwendersicht notwendigen Funktionalitäten zum Betreiben entsprechender Systeme beschreiben. Wie auch schon in den entsprechenden AES- und SMPTE-Gremien arbeiten Vertreter vieler Hersteller und Anwender (vor allem aus dem Bereich der großen internationalen Rundfunkhäuser) gemeinsam in den verschiedenen Arbeitsgruppen. Im Gegensatz zu den Standardisierungs-Organisationen werden im Rahmen von NMOS-Workshops die jeweiligen Spezifikationen auch praxisrelevant auf Funktion und Interoperabilität getestet. Derzeit sind folgende NMOS-Spezifikationen von der AMWA offiziell verabschiedet worden:
Discovery and Registration Specification (IS-04) – ermöglicht übergeordneten Applikationen (z. B. Broadcast Management-Systemen) die Kenntnis von allen im Netz verfügbaren Geräten und Ressourcen
Device Connection Management Specification (IS-05) – ermöglicht einem Management-System für vorkonfigurierte Streams Verbindungen zwischen Sendern und Empfängern aufzubauen
Network Control Specification (IS-06) – realisiert eine Schnittstelle zwischen einem SDN Controller und einem Broadcast Manager, um die entsprechenden Datenströme (Routen) im Netzwerk aufsetzen und verwalten zu können
Event and Tally Specification (IS-07) – ermöglicht das zeitgesteuerte Übermitteln von Befehlen oder Statuszuständen, z. B. Schalten von IOs (Tally) oder Übermitteln von Sensordaten
Audio Channel Mapping (IS-08) – ermöglicht das zeitgesteuerte Patchen von Eingangs- und Ausgangskanälen (z. B. Routen eines Audioeingangs auf einen Stream-Kanal und umgekehrt)
An weiteren Funktionalitäten wird bereits intensiv gearbeitet und getestet. Tiefergehende Informationen sind auf der entsprechenden AMWA NMOS Übersichtsseite zu finden.
Die bereits mehrfach erwähnte „Alliance for Interoperable Media Systems“ (AIMS) spielt im Spannungsfeld zwischen AES67, SMPTE ST 2110 und AMWA NMOS eine wichtige Rolle, die hier kurz erläutert werden soll. Die AIMS ist eine Non-Profit Organisation, der mittlerweile mehr als 100 Mitglieder (Firmen) angehören. Darunter sind nicht nur alle größeren Firmen aus dem Videobereich (u. a. Evertz, EVS, Grass Valley, Imagine, Matrox, Ross Video, Sony), sondern auch die namhaften Hersteller von Netzwerkinfrastrukturprodukten (u. a. Arista, Cisco, Dell, Huawei, Juniper, Meinberg) sowie etliche Organisationen aus dem Endanwenderbereich (u. a. BBC, CBS, EuroMedia, NBC, ProSiebenSat.1, Swedish Radio, Walt Disney u. a.). Seit dem Merger mit der Media Networking Alliance (MNA) Ende 2017 sind auch über 30 reine Audiofirmen in der AIMS vertreten (u. a. Lawo, Riedel, Telos, Yamaha, Archwave, Bosch, Clear-Com, DirectOut, Focusrite, Genelec, Merging, StageTec).
Im ersten und zweiten Bild kann nur das Mischpult mit beiden Übertragungsformaten kommunizieren. Die einzelnen Endgeräte haben aber ansonsten keine Möglichkeiten Audiodaten auszutauschen. Erst mit einer AES67-Kompatibilität ist es allen Teilnehmern des Netzwerks möglich Audiodaten untereinander auszutauschen. (Bild: ALC NetworX)
Die AIMS hat es sich zur Aufgabe gemacht, die Adaption der oben genannten Standards voranzutreiben. Dazu werden einerseits die Technologien und die praktischen Anwendungsfelder öffentlichkeitswirksam auf verschiedenen Messen (NAB, IBC, InfoComm, AES etc.) dargestellt; außerdem werden eine Reihe ergänzender Materialen auf der AIMS Webseite bereitgestellt, die Anwendungen und Hintergründe weiter vertiefen (u. a. aimsalliance.org/white-papers/). Zum anderen werden in verschiedenen Arbeitsgruppen praxisrelevante Themen diskutiert und den entsprechenden Standardisierungsgremien Vorschläge zur Erweiterung und Verbesserung der jeweiligen Standards unterbreitet. So sind viele Teilaspekte des SMPTE ST 2110 Standards sowie verschiedene NMOS-Spezifikationen aus Eingaben der AIMS entstanden. Das dieser Prozess gut funktioniert ist u. a. sicher auch der Tatsache geschuldet, dass viele AIMS-Vertreter auch in den entsprechenden Gremien und Arbeitsgruppen von AES, SMPTE und AMWA mitarbeiten.
(Bild: Christiane Bangert)Andreas Hildebrand ist Senior Product Manager und Evangelist für die Ravenna Technologie von ALC NetworX und gilt mit über 25 Jahren Erfahrung in der Professional Audio und Broadcast Branche als Experte für AV over IP Systeme.
Nach seinem Diplom in Informatik arbeitete Hildebrand für viele Jahre als Softwareentwickler und Leiter der Entwicklungsabteilung für Unternehmen in Deutschland und den USA. Bevor er schließlich zu ALC NetworX kam, leitete er das Produktmanagement von David Systems, einem international tätigen Softwareunternehmen im Bereich Professional Audio / Broadcast.
Er ist Vollzeit-Teilnehmer in der AES-Arbeitsgruppe, die den AES67 Audio over IP Standard definiert und verwaltet. Außerdem ist er Co-Vorsitzender der Audio Subgroup der Alliance for IP Media Solutions (AIMS) und beteiligt sich an der SVIP-Standardisierung SMPTE ST 2110.
Kommentar zu diesem Artikel
Pingbacks