Mebucom / News / Distribution / Audio and Video over IP

News: Distribution

Audio and Video over IP

Zu Audio and Video over IP fanden im Januar und März wieder Seminare im Hause des Codec- und Gateway-Spezialisten MAYAH Communications in Hallbergmoos statt. Das Thema ist sowohl für die interne Übertragung wie Reportagen oder Auslandszuspielungen, als auch für die Distribution zum Senderübergabepunkt und viele andere Anwendungen von Bedeutung. Nicht zuletzt durch die Veränderung der Kommunikationsnetzstrukturen wird es immer wichtiger werden.

Möglich wurde die globale Vernetzung via Internet durch eine Idee des kalten Kriegs. Man suchte nach einem Netz, was auch bei Teilausfall Daten zwischen Punkten übertragen kann. In den Jahren 1968 bis 1971 wurde eine solche Vernetzung zwischen mehreren amerikanischen Universitäten durchgeführt. 1974 entstand das erste Protokoll, das dann die Basis für das heutige Internet-Protocol darstellte. Im Jahr 1984 wurde dann die IP Version 4 (häufig als IPv4 bezeichnet) eingeführt. Soviel zum historischem Aspekt.

Das Internet und die dort verwendeten Protokolle haben sich ständig weiterentwickelt, und es gibt eine Vielzahl von neuen Protokollen und Verfahren. Diese werden in den so genannten RFCs (Request-For-Comments) vorgestellt und dann über die IETH (Internet-Engineering-Task-Force) standardisiert. Fast alles, was im Internet an Protokollen genutzt wird, ist über die öffentlich zugängigen RFCs festgeschrieben.

Um die Protokolle und Verfahren herstellerübergreifend besser definieren zu können, hat man ein Referenzmodell entwickelt, dass den Datentransport von der Leitung bis zur Anwenderapplikation in Schichten (Layer) einteilt. Man kann so das Zusammenspiel zwischen mehreren Protokollen mit unterschiedlichen Aufgaben besser beschreiben. Dieses von der ISO (International Organization for Standardization) 1983 festgelegte Referenzmodell nennt sich OSI Reference Model (Open-Systems-Interconnection-Reference-Model). Die unterste Schicht (1) ist zum Beispiel die physikalische Schicht und definiert Stecker und Kabeltypen, über den Datentransport via Internet gelangt man zu den drei oberen Schichten (5 bis 7), die der Anwendung zugeordnet sind – in unserem Falle also beispielsweise eine Software oder ein Audio- oder Videocodec.
Für die nachfolgenden Betrachtungen sind besonders die Schichten Network (Vermittlung), Transport und Session (Sitzung) von Bedeutung.

Internet-Protcol (IP)
Im Network-Layer befindet sich das Internet-Protocol (IP), welches über die RFC 791 definiert ist. Die Übertragung im Internet erfolgt paketorientiert, das heißt, es wird ein bestimmtes Datenpaket mit einem vorangestellten Kopf übertragen, der unter anderem IP-Version, Servicetyp, Quellen- und Zieladresse etc. enthält. Quelle und Ziel werden über die so genannte IP-Adresse festgelegt, die bei der IP Version 4 aus vier Zahlen (0 bis 255) bestehen. Geschrieben werden Sie mit Punkten getrennt (Dotted-Decimal-Notation), also zum Beispiel „186.70.120.1“.
Über diesen 32-Bit-Adresse lassen sich also theoretisch 4.294.967.296 verschiedene Quellen beziehungsweise Ziele adressieren. Jedoch werden die Adressen in fünf Klassen (A bis E) aufgeteilt. Die ersten ein bis vier Bits geben Aufschluss über die IP-Klasse. Die Klasse A ist besonders Anwendungen mit wenig Netzen und vielen Rechnern gedacht. Für Netze mit nur sehr wenigen Rechnern ist dagegen die Klasse C geeignet (bis zu 256 Host IDs in einem Netz).
Folgender Adressraum ist für private Netze reserviert: 10.0.0.0 bis 10.255.255.255, 172.16.0.0 bis 172.31.255.255 und 192.169.0.0 bis 192.169.255.255.

Diese lokalen Netze lassen sich über einen Router wieder an das Public-Internet anbinden. Die Verbindung zwischen lokaler und Internet-Adresse erfolgt über eine so genannte Networks-Address-Translation (NAT).
Die Klasse D ist ausschließlich für so genannte Multicast-Adressen vorgesehen. Man muss drei verschiedene Zustellungsarten der Datenpakete im Internet unterscheiden und zwar:
• Unicast – geht an den Empfänger,
• Broadcast – geht an jeden Host in einem Subnetz,
• Multicast – geht an eine Gruppe von Empfängern in mehrere Subnetze.
Der IPv4-Adressraum wird zunehmend knapp. Man hat sich daher schon vor Jahren an die Standardisierung des Nachfolgers, der IP Version 6 (IPv6) gemacht. Hier ist der Adressraum deutlich größer, denn die Adresse hat eine Länge von 128 statt 32 Bit. Die IPv6-Adressen werden übrigens in hexadezimaler Form mit notiert, wobei immer ein Wort aus 16 Bit zusammengefasst werden, wie zum Beispiel: 2001:0db2:83c2:04d4:1319:a6ff:001f:0001
Das IPv6 bietet aber darüber hinaus weitere Vorteile wie etwa eine direkte Unterstützung von Quality of Service und Multicast, um nur einige Funktionalitäten herauszugreifen.

Transmission-Control-Protocol (TCP)
Die nächste Schicht im OSI-Modell ist die Transportschicht. Hier ist man der eigentlichen Anwendung, der Übertragung von Audio und Video, schon viel näher.
Das gängige Transportprotokoll für die Dateiübertragung, ist das Transmission-Control-Protocol (TCP), ursprünglich im RFC 793 definiert und vielfach erweitert. Mit Hilfe des Protokolls wird ein viertueller Verbindungskanal (Socket) zwischen den beiden Verbindungspunkten eingerichtet. Der eigentliche Grund für den Aufbau des Internets war die Datensicherheit bei der Übertragung. Häufig findet man auch die Bezeichnung TCP/IP, und sie müssen auch nicht zwangsweise gemeinsam angewandt werden. Tatsächlich sind sie nach dem Referenzmodel in zwei verschiedenen Schichten einzuordnen. Im TCP-Kopf werden Quellen- und Ziel Ports, eine Sequenznummer, eine Checksum für die Fehlererkennung und diverse Flags (Statusbits) für den Verbindungsstatus, und im Anschluss an den Kopf die Daten übertragen. Die Ports stellen eine Verbindung zu den verschiedenen Applikationen her. So ist zum Beispiel für eine HTTP-Web-Applikation der Port 80 definiert. Es gibt neben den vielen Standard-Ports (0 bis 1023) auch Ports, die von einer bestimmten Software-Applikation eines Herstellers benutzt werden (maximal bis Port Nr. 65535). Gleiche Port-Nummern sind auch häufig mehrfach verschiedenen Applikationen zugeordnet. Die Länge eines TCP-Datentelegramms darf maximal so groß sein, dass es wiederum in ein IP-Datentelegramm (untere Schicht im OSI-Referenzmodell) passt.

Für die Empfangsbestätigung eines Paketes wird vom Empfänger nach Überprüfung der Checksum an den Absender ein Acknowledge (Empfangsbestätitung, Abkürzung ACK) geschickt. Der sendet dann den nächsten Datenblock. Bleibt der Acknowledge vom Empfänger aus, erfolgt bis zu einer bestimmten Anzahl eine Paketwiederholung und bei Überschreiten einer bestimmten Anzahl ein Verbindungsabbruch.

User-Datagram-Protocol (UDP)
Und genau das, was bei Nichtechtzeitdaten einen erheblichen Vorteil darstellt, ist ein großer Nachteil bei der Übertragung von Echtzeit-Audio/Videodaten. Hier möchte man auf keinen Fall einen Datenstau durch Paketwiederholungen oder gar einen fatalen Verbindungsabbruch haben. Aus diesem Grund hat man zum Beispiel für die Übertragung von Audio- und Videodaten ein alternatives Protokoll entwickelt, das User-Datagram-Protocol (UDP).

Der UDP-Kopf, beschrieben im RFC 768, ist sehr einfach gestaltet. Es enthält lediglich Quellen- und Empfänger-Ports, die Länge des Datentelegramms sowie eine Checksum für eine Fehlererkennung. Beim UDP gibt es keine Bestätigung vom Empfänger. Der Empfänger ist alleine dafür verantwortlich, aus den Daten etwas Brauchbares zu erzeugen. Es gibt auch keine Flow-Control im UDP-Übertragungsmechanismus. Das heißt, es kann vorkommen, dass Datenpakete nicht in der gleichen Reihenfolge beim Empfänger ankommen, wie sie abgeschickt wurden. Viele einfache Audio- oder Videoübertragungen im Internet nutzen das UDP.

Realtime-Transportation-Protocol (RTP) und Realtime-Streaming-Protocol (RTSP)
Beim Betrachten des UDP-Mechanismus wird schnell klar, dass für Echtzeitübertragungen mit professionellem Anspruch, mehr Funktionalität in der Transportschicht wünschenswert ist. Daher hat man ein weiteres Protokoll entwickelt, das Realtime-Transportation-Protocol (RTP), definiert in dem RFC 1889, was wiederum auf UDP basiert. Es ist ein sehr junges Protokoll und wurde erst 1996 auf den Weg gebracht. Der Protokoll-Overhead ist kleiner als beim TCP. Mit dem RTP wird eine Sequenznummer übermittelt, um beim Empfänger die ursprüngliche Paketreihenfolge wieder herstellen zu können, und es wird auch ein Echtzeit-Timestamp übertragen.

Über das Realtime-Streaming-Protocol (RTSP) lässt sich die Übertragung der audiovisuellen Datenströme bidirektional steuern. Es wurde im Sommer 2003 im RFC 3550 definiert. RTPS ist so eine Art Fernbedienung für A/V-Streaming. Funktionalitäten ist etwa die Synchronisation von Events. Über RTSP lässt sich zum Beispiel ein Remote-Editing realisieren. Der Quick-Time-Streaming-Server ist beispielsweise RTSP-fähig.

Session-Initiation-Protocol (SIP) und Session-Description-Protol (SDP)
Und der Protokolle nicht genug. Für die nächste OSI-Schicht hat man mit dem Session-Initiation-Protocol (SIP) ein Protokoll für den definierten Aufbau einer Verbindung geschaffen. Als Port wird häufig 5060 verwendet. Das SIP kann mit UDP und TCP, aber auch mit anderen Protokollen zusammenarbeiten. Definiert ist es in der RFC 3261. Es steht im Wettbewerb mit dem H.323, welches aber mehr für Telekommunikationsanwendungen verwendet wird und daher auch von der ITU spezifiziert wurde.
Dieses Protokoll ist zwar ebenfalls schon 1996 definiert worden, aber erst jetzt wird es zunehmend in die Endgeräte implementiert. Die Daten zum Verbindungsaufbau werden in Textform übermittelt. Dies erleichtert die Interpretation beim Monitoring eines Verbindungsaufbaus. Statt Telefonnummern wird ein Adressformat wie bei E-Mails verwendet und zwar das so genannte URI-Format, definiert als RFC 2806. Eine typische Mail-Adresse sieht so aus: „mailto:fritz@mayah.com“ und bei SIP eben so: „sip:fritz@mayah.com“. Alternativ gibt es noch das tel-URI-Format, was sich an Telefonnummern orientiert, wie zum Beispiel „tel:+49-811-551699“.

Der Aufbau der Verbindung kann auch über einen externen Registration-Server erfolgen. Dies hat den Vorteil, dass man ein Verbindungsmanagement realisieren kann. Ein mobiler Client A registriert sich auf dem Registration-Server. Wenn nun ein Client B eine Verbindung zum Client A aufbauen will kann er dies über den Registration-Server tun, der ja Kenntnis darüber hat, wo Client A sich gerade im Netz befindet. Das SIP bietet also auch einen Mobilitätsvorteil. Ein weiterer Vorteil ist die Sicherstellung von Quality of Service. Es ist für professionelle Echtzeitanwendungen sehr wichtig, bestimmte Qualitätsparameter für die Übertragung sicherzustellen, wie etwa eine entsprechend nötige Mindestbandbreite.
Mit Hilfe des Session-Description-Protols (SDP), was wiederum SIP nutzt, lassen sich weitere Funktionalitäten verwirklichen, etwa Konferenzen beziehungsweise Multicast-Verbindungen. Dieses Protokoll wird im RFC 4566 beschrieben. SDP arbeitet mit dem SIP zusammen, und über SDP lassen sich zum Beispiel zu verwendende Codecs zwischen den SIP-Gegenstellen aushandeln.

Audio/Video-Real-Time-Streaming
Die Codierung von Audio- und Videodaten ist ein eigenes Thema und darüber wurde schon vielfach berichtet. Wir möchten hier aber trotzdem noch ein paar wichtige Informationen vermitteln.
Die klassische Tonkodierung erfolgte bisher mit MPEG-2 Layer 2 oder Layer 3. Jedoch gibt es neue effizientere Codierungsmethoden. Eine ist HE-AAC (High-Efficiency-Advanced-Audio-Coded), ein verbessertes AAC-Verfahren, welches besonders bei kleinen Bitraten sehr effizient arbeitet. Bei lediglich einem Viertel der Bitrate von MPEG-2 Layer-2 bekommt man eine etwa gleiche Qualität. Mit 64 kBit/s ist eine wirklich beeindruckende Qualität möglich. Dies wurde auch auf dem MAYAH-Seminar zu Gehör gebracht. Aber auch bei den Video-Codecs werden immer bessere Verfahren entwickelt, wie zum Beispiel H.264.

Forward-Error-Correction (FEC)
Eine Möglichkeit, um eine höhere Datensicherheit bei Echtzeitanwendungen zu erreichen, ist, die Daten mit Redundanz zu übertragen. Ein Standard ist hier der PRO-MPEG FEC. FEC bedeutet Forward-Error-Correction. Dabei werden Daten so mit Redundanz angereichert (ein oder zwei zusätzliche Datenströme), dass bei Ausfall von Daten aus dem Datenstrom die ursprünglichen Daten wieder errechnet werden können. PRO MPEG FEC ist im RFC 2733 beschrieben und ist auch in den Geräten von MAYAH Communications implementiert. Zur Zeit ist die Anwendung des FEC-Algorithmus auf MPEG-TS Sitzungen beschränkt.

MAYAH Communications-Produkte
MAYAH wurde 1997 gegründet. Der Standort der Firma ist in Hallbergmoos bei München. Die Entwicklung der Produkte erfolgt in Flensburg. Die Firma ist in Privatbesitz. Die beiden Geschäftsführer sind Jörg Rimkus und Detlef Wiese. MAYAH Communications ist im gesamten Gebiet der Audio- und Video-Kodierung beziehungsweise Übertragung tätig von Contribution bis Distribution und von SNG bis hin zu Senderübergabe.
Auf dem MAYAH-Seminar wurde auch auf die Produkte eingegangen. In drei Workshops bekamen die Teilnehmer einen Einblick über die Funktionalität und den praktischen Einsatz.
Der MERK II ist ein portabler Audio-Codec mit integriertem und programmierbarem Audiomischer für den Reportageeinsatz. Das Gerät kann sowohl für Audioübertragungen via ISDN als auch via Internet eingesetzt werden. So kam es zum Beispiel beim Eurovisions Song Contest 2006 in Athen zum Einsatz. Die Gerätekonfiguration lässt sich über eine Software ferneinstellen. Das Gerät ist zu vielen anderen Codecs kompatibel.

Die Geräte der Serie CENTAURI II sind Audio-Codecs und Gateways für verschiedenste Anwendungen. Die Produkte unterstützen eine Vielzahl von Codecs wie G.711, G.722, MPEG Leyer 2 und 3, AAC, aacPlus, apt-X, Eapt-X, mp3Pro, AAC 5.1, HE ACC 5.1/7.1 sowie Eapt-X 5.1/7.1. Über die MAYAH FlashCast-Technologie ist auch eine Verbindung zu Geräten anderer Hersteller beziehungsweise Codecs möglich. Nach dem Verbindungsaufbau handeln die Geräte hierüber automatisch den geeigneten Codec aus.
Mit den ganymed 1002A und PRO wird auch ein reiner IP-Audio-Decoder/Encoder beziehungsweise mit dem ganymed 1102 ein IP Gateway Codec angeboten. Die Geräte IO 8000 und 8001 sind Audio/Video Encoder und Decoder, zum Beispiel für mobile TV-Anwendungen. Neben MPEG-4 SP und ASP werden auch Codecs nach MPEG-4 Part 10 (H.264) unterstützt.
Für alle MAYAH-Geräte wird übrigens eine Remote-Software angeboten. Mehr zu der Gerätekompatibilität folgt in der nächsten Ausgabe von MEDIEN BULLETIN. Dann wird über das Audio over IP-Seminar der ARD-ZDF-Medienakademie berichtet, in dem es auch um dieses und andere aktuelle Themen ging.
Peter Kaminski (MB 04/07)

Zurück