Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD AND DEVICE FOR DERIVING AUDIO PARAMETER VALUES FROM AN AES67-COMPATIBLE AUDIO INFORMATION SIGNAL
Document Type and Number:
WIPO Patent Application WO/2019/011981
Kind Code:
A1
Abstract:
The invention relates to a method and a device for deriving audio parameter values from an AES67-compatible audio information signal formed from a serial data stream of successive IP packets (IP(i)), in which the IP packets contain an IP header (IP HDR), a UDP header (UDP HDR), an RTP header (RTP HDR) and a data field (DATA), and audio parameter values, such as sampling rate and number of channels, are derived from information stored in the headers.

Inventors:
BAUMANN FRANZ (DE)
RENJEWSKI FELIX (DE)
Application Number:
PCT/EP2018/068781
Publication Date:
January 17, 2019
Filing Date:
July 11, 2018
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
INST RUNDFUNKTECHNIK GMBH (DE)
International Classes:
H04J3/06; G10L19/16; H04L29/06
Foreign References:
Other References:
SCHMIDT FLORIAN ET AL: "A heuristic header error recovery scheme for RTP", 2013 10TH ANNUAL CONFERENCE ON WIRELESS ON-DEMAND NETWORK SYSTEMS AND SERVICES (WONS), IEEE, 18 March 2013 (2013-03-18), pages 186 - 190, XP032476924, ISBN: 978-1-4799-0747-2, [retrieved on 20130812], DOI: 10.1109/WONS.2013.6578345
REHA CIVANLAR M: "Protocols for real-time multimedia data transmission over the Internet", ACOUSTICS, SPEECH AND SIGNAL PROCESSING, 1998. PROCEEDINGS OF THE 1998 IEEE INTERNATIONAL CONFERENCE ON SEATTLE, WA, USA 12-15 MAY 1998, NEW YORK, NY, USA,IEEE, US, vol. 6, 12 May 1998 (1998-05-12), pages 3809 - 3812, XP010279676, ISBN: 978-0-7803-4428-0
SCHULZRINNE H ET AL: "RTP: A Transport Protocol for Real-Time Applications", NETWORK WORKING GROUP REQUEST FOR COMMENTS, XX, XX, no. 3550, 5 April 2004 (2004-04-05), pages 1 - 104, XP002356069
None
Attorney, Agent or Firm:
KOPLIN PATENTANWALTSGESELLSCHAFT MBH et al. (DE)
Download PDF:
Claims:
ANSPRÜCHE

1. Verfahren zum Ableiten von Audioparameterwerten aus einem AES67 kompatiblen Audioinformationssignal, welches als AES67 kompatibles Audioinformationssignal aus einem seriellen Datenstrom von aufeinanderfolgenden IP-Paketen aufgebaut ist, wobei die IP-Pakete einen IP-Header, einen UDP-Header, einen RTP-Header und ein Datenfeld enthalten, und wobei aus Information gespeichert in wenigstens zwei RTP-Headern von wenigstens zwei IP- Paketen einen Wert N abgeleitet wird, wobei der Wert N gleich der Anzahl von Abtastungen pro Kanal ist, die im Datenfeld eines IP-Pakets enthalten sind.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass dazu aus dem RTP-Header von zwei IP-Paketen im seriellen Datenstrom je ein Timestamp abgeleitet wird, und der Wert N berechnet wird mittels der Formel N = {TS(j) - TS(i)}/(p+l), wobei TS(i) und TS(j) gleich die Werte der zwei abgeleiteten Timestamps sind und p gleich die Anzahl der zwischen den zwei IP-Paketen (IP(i), IPG)) in seriellen Datenstrom liegenden IP-Paketen ist, wobei p eine ganze Zahl grösser gleich Null ist.

3. Verfahren gemäß Anspruch 1 oder 2, dadurch gekennzeichnet, das zum Ableiten der Abtastfrequenz, gemessen wird wieviele IP-Pakete M in einem bestimmten Zeitintervall T empfangen werden, und das die Abtastfrequenz hauptsächlich gleich N.M/T ist.

4. Verfahren gemäß Anspruch 1 oder 2, dadurch gekennzeichnet, dass zum Ableiten der Anzahl der Kanäle, zuerst aus einem UDP-Header eine Länge L, ausgedrückt in Bytes des Datenfeldes des IP-Pakets, abgeleitet wird, und dass die Anzahl der Kanäle gleich L/N', wobei N' gleich N.k, und k die Länge eines Abtastwerts ist, ausgedrückt in Anzahl von Bytes.

5. Verfahren gemäß einem der vorgehenden Ansprüchen, dadurch gekennzeichnet, dass im UDP-Header im AES67 kompatiblen Audioinformationssignal ein Checksumfeld vorhanden ist, in welchem Checksumfeld Daten über den Inhalt des zu übertragenden Informationssignals gespeichert und in welchem Daten aus dem AES67 kompatiblen Audioinformationssignal abgeleitet werden.

6. Verfahren gemäß Anspruch 5, dadurch gekennzeichnet, dass die Daten über den Inhalt des Audioinformationssignals den Übertragungstyp und/oder die Art der zu übertragenden Daten im Informationssignal und/oder die Art der Komprimierung und/oder die Kodierungsart angeben.

7. Verfahren gemäß Anspruch 6, dadurch gekennzeichnet, dass wenigstens zwei Bits, vorzugsweise die ersten zwei (Bits 0,1), folgende Übertragungstypen angeben: AES67, TrOl, Tr03 und SMPTE2110.

8. Verfahren gemäß Anspruch 6, dadurch gekennzeichnet, dass wenigstens zwei Bits, vorzugsweise die zweiten zwei Bits (Bits 2,3), folgende Arten der Daten im zu übertragenden Informationssignal angeben: Audio, Video und Metadaten.

9. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass wenigstens ein Bit, vorzugsweise das fünfte Bit (Bit 4), folgende Komprimierungsarten angeben: komprimiert und unkomprimiert.

10. Verfahren nach Anspruch 6, dadurch gekennzeichnet, dass wenigstens zwei Bits, vorzugsweise das sechste und siebte Bit (Bits 5,6), folgende Kodierungsarten angeben: JPEG2000 und TICO.

11. Einrichtung zum Ableiten von Audioparameterwerten aus einem AES67 kompatiblen Audioinformationssignal, welches als AES67 kompatible Audioinformationssignal aus einem seriellen Datenstrom von aufeinanderfolgenden IP-Paketen aufgebaut ist, wobei die IP-Paketen einen IP-Header, einen UDP-Header, einen RTP-Header und einen Datenfeld enthalten, wobei die Einrichtung einen Eingang enthält zum Empfangen des AES67 kompatiblen Audioinformationssignals, dadurch gekennzeichnet, dass die Einrichtung versehen ist mit einer Ableitungseinheit (400) zum aus wenigstens zwei RTP-Headern von wenigstens zwei IP- Paketen im seriellen Datenstrom Ableiten von Information, und eine Berechnungseinheit enthält zum Ableiten aus dieser Information eines Werts N welcher Wert N gleich der Anzahl von Abtastungen pro Kanal ist, die im Datenfeld eines IP-Pakets enthalten sind.

12. Einrichtung gemäß Anspruch 11, dadurch gekennzeichnet, dass die Ableitungseinheit (400) weiter eingerichtet ist zum aus den RTP-Headern von zwei IP-Paketen im seriellen Datenstrom Ableiten von Timestamps, und die Berechnungseinheit eingerichtet ist zum Berechnen von N gemäß folgender Formel:

N = {TS(]) - TS(i)}/(p+l),

wobei TS(i) und TS(j) gleich der Werte der zwei abgeleiteten Timestamps sind und p gleich der Anzahl der zwischen den zwei IP-Paketen (IP(i), IPG)) in seriellen Datenstrom liegenden IP-Paketen ist, wobei p eine ganze Zahl grösser gleich Null ist.

13. Einrichtung gemäß Anspruch 11 oderl2, dadurch gekennzeichnet, dass die Einrichtung weiter versehen ist mit einer Einheit (410,412) zum Bestimmen der Anzahl M von IP-Paketen die in einem bestimmten Zeitintervall T empfangen werden, und die Berechnungseinheit weiter eingerichtet ist zum Ausführen einer Berechnung N.M/T, welches Ergebnis gleich die Abtastfrequenz ist.

14. Einrichtung gemäß Anspruch 11 oder 12, dadurch gekennzeichnet, dass die Ableitungseinheit (400) weiter eingerichtet ist zum aus dem UDP-Header Ableiten einer Länge L, ausgedrückt in Bytes, des Datenfeldes des IP-Pakets, und weiter versehen ist mit einer Berechnungseinheit zum Ausführen einer Berechnung L/N', wobei N' gleich N.k, und k die Anzahl der Bytes eines Abtastwerts ist, welches Ergebnis gleich die Anzahl der Kanäle ist.

15. Einrichtung gemäß Anspruch 11, dadurch gekennzeichnet, dass im UDP-Header im AES67 kompatiblen Audioinformationssignal ein Checksumfeld vorhanden ist, in welchem Checksumfeld Daten über den Inhalt des Audioinformationssignals gespeichert sind, und die Einrichtung weiter versehen ist mit einer Ableitungseinheit zum Ableiten der im Checksumfeld gespeicherten Daten.

Description:
Titel: VERFAHREN UND EINRICHTUNG ZUM ABLEITEN VON AUDIOPARAMETERWERTEN AUS EINEM AES67 KOMPATIBLEN AUDIOINFORMATIONSSIGNAL

BESCHREIBUNGSEINLEITUNG

Hintergrund der Erfindung

Die Erfindung bezieht sich auf ein Verfahren und eine Einrichtung zum Ableiten von Audioparameterwerten aus einem AES67 kompatiblen Audioinformationssignal. Ein derartiges Informationssignal, welches in dem AES67 Audio Standard spezifiziert ist, ist aus aufeinanderfolgenden IP-Paketen aufgebaut und wird als ein reiner Bitstream übertragen (audio over IP oder audio over ethernet).

Mit der Übertragung von Audioinformation über IP, wie es in AES67 standardisiert worden ist, in Live-IP-Produktionen, geht auch eine Umstellung von Leitungsvermittlern zu Paketvermittelnden Netzen einher. Um eine fehlerfreie Funktion zu garantieren ist es von besonderer Bedeutung, dass die Streams im Netzwerk richtig übertragen werden.

Kurzbeschreibung der Erfindung

Die Erfindung hat sich zur Aufgabe gestellt die Datenübertragung im Netzwerk wesentlich zu verbessern. Das erfindungsgemäße Verfahren gemäß dem Oberbegriff des 1. Anspruchs ist dazu gemäß den kennzeichnenden Massnahmen des 1. Anspruchs gekennzeichnet. In gleicher Weise ist die erfindungsgemäße Einrichtung gemäß den Merkmalen des elften Anspruchs gekennzeichnet.

Die Erfindung bezieht sich auf folgender Kenntnis.

Wenn das oben angegebene richtige Schalten der Streams im Netzwerk nicht realisiert wird, wäre den Fehler zu finden, wenn der Netzwerkadministrator die Eigenschaften des Informationssignals, welches über das Netzwerk empfangen wird, kennen würde.

Bis jetzt ist es jedoch dem Netzwerkadministrator nicht möglich aus den Daten die ihm vom Netzwerk bereitgestellt werden, Informationen über die Streams zu erhalten. Dies liegt daran, dass die IP-Pakete nur die Nutzdaten beinhalten und alle Konfigurationsdaten über einen anderen Kanal übertragen werden. Die erfindungsgemäßen Maßnahmen ermöglichen es dem Netzwerkadministrator trotzdem aus den empfangenen IP-Paketen Audioparameterwerte, wie Abtastfrequenz und Anzahl der Audiokanäle, abzuleiten. Zuerst wird dazu gemäß Anspruch 1 und 2, die Anzahl von Abtastungen pro Kanal, welche in einem RTP Paket enthalten sind, abgeleitet.

Danach kann, gemäß Anspruch 3 die Abtastfrequenz abgeleitet werden. Oder, es wird gemäß Anspruch 4, die Anzahl der Kanäle abgeleitet.

Eine andere Möglichkeit wäre es, anstatt oder in Kombination mit den obengenannten Massnahmen, gemäß dem kennzeichnenden Merkmal des Anspruchs 5 im Checksumfeld der UDP-Header im Audioinformationssignal Daten über den Inhalt des Audioinformationssignals aufzunehmen und diese Daten dann aus den UDP Headern abzuleiten. Es kann sich dabei um Daten, wie sie in den Ansprüchen 6 bis 10 definiert sind handeln. Dies hat den Vorteil dass, ohne die Anzahl von Nutzbits zu senken trotzdem zusätzliche Informationen über die Art des Streams mit den Streams zu übertragen.

Kurzbeschreibung der Figuren

Die Erfindung wird in der Figurbeschreibung näher erläutert. Darin zeigt

Fig. 1 eine Anlage wobei eine Audioaufnahme einer Live-Produktion in einem AES67 kompatiblen Audioinformationssignal umgesetzt wird und über Internet an ein entferntes

Verarbeitungsstudio übertragen wird und wobei eine Netzwerkadministrationseinheit vorgesehen ist zum Überwachen der über das Internet übertragenen Daten,

Fig. 2 den Aufbau einer 'Multicast Session description' Datei,

Fig. 3 den Aufbau eines AES67 kompatiblen Audioinformationssignals,

Fig. 4 ein erstes Ausführungsbeispiel einer Einrichtung zum Ableiten von

Audioparameterwerten aus dem AES67 kompatiblen Audioinformationssignal,

Fig. 5 den Aufbau eines UDP-Headers, und

Fig. 6 ein zweites Ausführungsbeispiel einer Einrichtung zum Ableiten von Audioparameterwerten aus dem AES67 kompatiblen Audioinformationssignal.

Detaillierte Figurbeschreibung.

Fig. 1 zeigt ein Ausführungsbeispiel einer Anlage wobei eine Audioaufnahme einer Live Produktion stattfindet, das aufgenommene Audioinformationssignal in einem AES67 kompatiblen Audioinformationssignal umgesetzt wird und danach über Internet an ein entferntes Verarbeitungsstudio oder einen entfernten Tonregieraum übertragen wird.

Fig. 1 zeigt ein Aufnahmestudio, schematisch durch die Referenznummer 100 angedeutet, in dem eine Audioaufnahme einer Live-Produktion stattfindet. Ein Verarbeitungsstudio 104 ist vorgesehen das sich normalerweise entfernt von dem Aufnahmestudio befindet. Im Aufnahmestudio 100 wird in diesem Beispiel die Aufnahme mittels vier Mikrofone durchgeführt, die z.B. links vorne, rechts vorne, links hinten und rechts hinten im Aufnahmestudio positioniert sind. Das aufgenommene (hier vierkanälige) Audioinformationssignal wird in einer Umsetzungseinheit 124 in ein AES67 kompatiblen Audioinformationssignal umgesetzt. Die Umsetzung findet dabei statt und zwar gemäß den in der AES67 Standard Spezifikation (z.B. AES67-2015: AES Standard for audio applications of networks - High Performance Streaming audio-over-IP interoperability) festgelegten Bedingungen in einem Übertragungssignal, welches über das Internet übertragen werden kann. An einem Ausgang 104, der mit dem Internet verbunden ist, steht das AES kompatible Audioinformationssignal zur Verfügung.

Das AES67 kompatible Audioinformationssignal ist aus aufeinanderfolgenden IP-Paketen aufgebaut, die die Abtastungen des Audioinformationssignals in den (in diesem Beispiel: vier) Kanälen enthalten. Das AES67 kompatible Audioinformationssignal wie es am Ausgang 104 zu Verfügung steht, enthält jedoch keine Information über die audiospezifische Parameterwerten des Audioinformationssignals, wie z.B. die Abtastfrequenz und die Anzahl der übertragenen Audiokanälen die im zu übertragenen Audioinformationssignal enthalten sind. Die AES 67 -Spezifikation sieht dafür eine sogenannte TVIulticast Session description' Datei 118 vor, in welcher Information über diese audiospezifische Parameter enthalten sind. Die Datei wird an einem Ausgang 106 angeboten und über das Internet an einen Server 108 zugeführt und dort gespeichert.

Die Datei 118 enthält auch u. A. die Quelladresse des Aufnahmestudios 100, damit der Ausgang 104 über das Internet identifiziert werden kann.

Wenn ein Tontechniker im Tonregieraum 102 die Audioaufnahme des Liveprogramms zur weiteren Verarbeitung des Audioinformationssignals empfangen will, sodass es als Broadcastübertragungssignal einem oder mehreren Sendern angeboten werden kann, holt er sich über das Internet vom Server 108 die TVIulticast Session description' Datei 118, siehe die Kommunikation über die Verbindung 110 zwischen Tonregieraum 102 und Server 108 in Fig. 1.

Fig. 2 zeigt ein Beispiel einer TVIulticast Session description 'Datei 118, wie es auch in Kapitel 8.5.1 der AES67-2015 Standard-Spezifikation beschrieben ist.

Parameter c in der Datei gibt die Quelladresse an (in diesem Beispiel IP4 239.0.0.1732), Parameter i die Anzahl der Audiokanälen (in diesem Beispiel gleich 8) und darunter ist die Abtastfrequenz (in diesem Beispiel 48 kHz) zu sehen.

Mit dieser Information kann der Tontechniker das AES67 kompatible Audioinformationssignal empfangen. Die Übertragung des AES67 kompatiblen Audioinformationssignal vom Ausgang 104 des Aufnahme Studios 100 zu einem Eingang 112 des Tonregieraums 102, über das Internet, findet in Fig. 1 statt über die Switches 114 und 116.

Fig. 3 zeigt den Aufbau eines AES67 kompatiblen Audioinformationssignals das über das Internet, die Switches 114 und 116, an den Eingang 112 des Tonregieraums 102 angeboten wird. Das AES67 kompatible Audioinformationssignal ist aus aufeinanderfolgenden IP-

Paketen IP(i), IP(i+l), IP(i+2), aufgebaut. Ein IP-Paket enthält einen IP-Header IP-

HDR, einen UDP-Header UDP HDR, einen RTP-Header RTP HDR, und ein Datenfeld DATA. Das AES67 kompatible Audioinformationssignal kann jetzt an den Tonregieraum 102 übertragen werden und dort weiter verarbeitet werden.

Was möglicherweise trotzdem passieren kann, ist das eine fehlerbehaftete Übertragung von Daten zwischen dem Ausgang 104 des Aufnahmestudios 100 und dem Eingang 112 des Verarbeitungsstudios/Tonregieraums 102 auftreten kann.

Zum einen, könnte der Tontechniker eine falsche TVIulticast Session description' Datei 118 vom Server 108 heruntergeladen haben. Oder es kann sein dass kein Multicast Session description" Datei vorliegt.

Um derartige Übertragungsprobleme zu beseitigen ist eine Netzwerkadministrationseinheit 120 zum Überwachen der über das Internet übertragenen Daten vorgesehen.

Dazu ist diese Netzwerkadministrationseinheit 120 in diesem Fall über den Switch 114 mit dem Netzwerk gekoppelt und ist eingerichtet um alle AES67 kompatiblen Informationssignale vom Aufnahmestudio 100 zu empfangen.

Dadurch dass das AES67 kompatible Audioinformationssignal, wie oben bereits angegeben, keine Information über die audiospezifische Parameterwerten des Audioinformationssignals, wie z.B. die Abtastfrequenz und die Anzahl der übertragenen Audiokanälen die im zu übertragenen Audioinformationssignal enthalten sind; ist es für die Netzwerkadministrationseinheit 120 nicht möglich diese audiospezifische Parameterwerte direkt aus dem AES67 kompatiblen Audioinformationssignal abzuleiten.

Erfindungsgemäß werden jetzt einige Vorschläge beschrieben die es ermöglichen doch noch diese audiospezifische Parameterwerte aus dem AES67 kompatiblen Audioinformationssignal abzuleiten.

Dazu wird zuerst aus dem AES67 kompatiblen Audioinformationssignal die Anzahl N von Abtastungen pro Kanal, welche im Datenfeld DATA eines IP-Pakets enthalten sind, abgeleitet. Dies wird wie folgt realisiert. In Fig. 3 ist ersichtlich das im RTP-Header des IP-Pakets IP(i) ein Timestampfeld TS(i) und im RTP-Header des IP-Pakets IP(i+l) ein Timestampfeld TS(i+l) vorhanden ist. Die Netzwerkadministrationseinheit 120 leitet die Timestampwerten TS(i) und TS(i+l) von diesen aufeinanderfolgenden IP-Paketen aus den RTP-Headern dieser Pakete ab. Danach wird durch Differenzbildung N abgeleitet: TS(i+l) - TS(i) = N. Als Beispiel: TS(i) = n und TS(i+l) = n+2. Dies bedeutet dass im Datenfeld DATA der IP Paketen (n+2 - n =) zwei Abtastungen pro Kanal enthalten sind.

Eine andere Möglichkeit zum Ableiten der Anzahl N von Abtastungen pro Kanal, die in einem Datenfeld eines IP-Pakets enthalten sind, ist wie folgt. Jetzt wird aus den RTP-Headern der IP- Paketen IP(i) und IP(j) die Timestamps TS(i) und TS(j) abgeleitet. N wird jetzt wie folgt berechnet:

N = {TS(]) - TS(i)}/(p+l),

wobei p gleich die Anzahl der zwischen den zwei IP-Paketen (IP(i), IPG)) in seriellen Datenstrom liegenden IP-Paketen ist, wobei p eine ganze Zahl grösser gleich Null ist.

Fig. 3 zeigt ein Beispiel des Inhalts des Datenfeldes des IP-Pakets IP(i). Darin sind zwei Abtastungen s(l,l), s(l,2) eines ersten Kanals enthalten, danach zwei Abtastungen s(2,l), s(2,2) eines zweiten Kanals, danach zwei Abtastungen s(3,l), s(3,2) eines dritten Kanals, und danach zwei Abtastungen s(4,l), s(4,2) eines vierten Kanals. Im Datenfeld DATA des IP-Pakets IP(i+l) sind dann auch wieder acht Abtastungen enthalten: zwei Abtastungen s(l,3), s(l,4) des ersten Kanals enthalten, danach zwei Abtastungen s(2,3), s(2,4) des zweiten Kanals, danach zwei Abtastungen s(3,3), s(3,4) des dritten Kanals, und danach zwei Abtastungen s(4,3), s(4,4) des vierten Kanals.

Zum Ableiten der Anzahl der Kanäle die im AES67 kompatiblen Audioinformationssignal übertragen werden, wird aus dem UDP-Header UDP HDR einen Wert I , siehe Fig. 5, abgeleitet. Dieser Wert 1/ gibt die Länge des RTP-Pakets (ist gleich der Länge des RTP- Headers und des Datenfeldes DATA), ausgedrückt in Bytes, an. Weil die Länge des RTP- Headers RTP HDR standardgemäß festgelegt ist, ist somit auch die Länge L des Datenfeldes DATA aus L' abzuleiten. Jetzt ist die Anzahl der Kanäle zu berechnen durch: L/N', wobei N'= N.p, und p die Länge eines Abtastwerts ist, ausgedrückt in Anzahl von Bytes, p ist auch standardgemäß festgelegt und ist z.B. gleich 3 Bytes.

Zum Ableiten der Abtastfrequenz, wird bestimmt wieviel IP-Pakete M in einem bestimmten Zeitintervall T empfangen werden. Die Abtastfrequenz kann dann berechnet werden als gleich N.M/T. M kann dabei auf verschiedenen Weisen abgeleitet werden. Erstens, könnte M abgeleitet werden durch Zählen der Anzahl der IP-Pakete die im bestimmten Zeitintervall empfangen werden. Zweitens, könnte mann auch die Reihennummer (sequence number) des ersten IP-Paket und des letzten IP-Paket das im Zeitintervall empfangen wird ableiten und dann durch Subtraktion der beiden Werten M berechnen. Diese Reihennummern sind im RTP- Header gespeichert.

Der Netzwerkadministrator kann dann diese gewünschte Information an den Tontechniker weiterleiten, damit das übertragene AES67b kompatible Audioinformatonssignal empfangen und dekodiert werden kann. Weil der Netzwerkadministrator, wie oben bereits angegeben, alle Informationssignale vom Aufnahmestudio empfängt, kann der Netwerkadministrator aus dem IP-Header des AES kompatiblen Audioinformationssignals auch die Quelladresse ableiten und an den Tontechniker weiterleiten.

Fig. 4 zeigt ein erstes Ausführungsbeispiel einer Einrichtung zum Ableiten von Audioparameterwerten aus dem AES67 kompatiblen Audioinformationssignal. Die Einrichtung enthält einen Eingang 122 zum Empfangen des AES67 kompatiblen Audioinformationssignals. Die Einrichtung ist versehen mit einer Ableitungseinheit 400 zum aus wenigstens zwei RTP-Headern von wenigstens zwei IP-Paketen im seriellen Datenstrom des AES67 kompatiblen Audioinformationssignals Ableiten von Information, in diesem Beispiel zum Ableiten von Timestamps TS(i) und TS(j), die an zwei Ausgängen abgegeben werden und an Eingängen einer Berechnungseinheit 402 zugeführt werden.

In der Berechnungseinheit 402 wird die Anzahl der Kanäle N berechnet gemäß folgender Formel:

N = {TS(]) - TS(i)}/(p+l)

wobei TS(i) und TS(j) gleich der Werte der zwei abgeleiteten Timestamps sind und p gleich die Anzahl der zwischen den zwei IP-Paketen (IP(i), IP(j)) in seriellen Datenstrom liegenden IP- Paketen ist, wobei p eine ganze Zahl grösser gleich Null ist.

Dies bedeutet dass die Berechnungseinheit eine Subtraktionseinheit 406 enthält zum

Subtrahieren der zwei Timestampwerten voneinander und eine Dividiereinheit 408 zum

Dividieren des Ergebnis der Subtraktionseinheit 406 durch p+1.

Der Wert N steht dann am Ausgang 404 der Dividiereinheit 404 zur Verfügung.

Zum Ableiten der Abtastfrequenz Fs enthält die Einrichtung eine Zähleinheit 410 und eine

Timereinheit 412. Die Timereinheit 412 bestimmt ein Zeitintervall T, und die Zähleinheit zählt innerhalb dieses Zeitintervalls T die Anzahl M von IP-Paketen die in diesem Zeitintervall T am Eingang 122 empfangen werden. Der Wert M steht am Ausgang 414 der Zählereinheit 410 zur Verfügung und wird an die Berechnungseinheit 402. Auch der Wert des Zeitintervalls T wird an die Berechnungseinheit 402 zugeführt. Die Berechnungseinheit 402 enthält eine Abtastfrequenzberechnungseinheit 416, die die Werte N, M und T empfängt und daraus die Abtastfrequenz Fs ableitet, gemäß der Formel: Fs = N M/T.

Wie bereits oben angegeben, könnten die Einheit 410 stattdessen als eine Zählereinheit zum Auslesen der Folgenummer des ersten und letzten IP-Pakets eingerichtet sein, welches in diesem Zeitinterval T empfangen wird. Die Einheit könnte dann danach die zwei Folgenummern zum Ableiten des Werts M voneinander subtrahieren.

Die Ableitungseinheit 400 ist weiter eingerichtet zum aus dem UDP-Header Ableiten einer Länge L, ausgedrückt in Bytes des Datenfeldes des IP-Pakets. Im Längenfeld 500 eines UDP- Headers ist ein Wert L 'gespeichert, wie in Fig. 5 gezeigt ist. Dieser Wert L' stimmt überein mit der Länge des RTP-Pakets (also, der Länge des RTP-Headers RTP HDR und des Datenfeldes DATA, siehe Fig. 3). Da die Länge des RTP-Headers bekannt ist, kann somit die Länge L des Datenfeldes DATA abgeleitet werden. Dieser Wert L wird ebenfalls an die Berechnungseinheit 402 zugeführt. In der Berechnungseinheit 402 wird eine Berechnung ausgeführt im Block 418 wobei die Anzahl der Kanäle NCH berechnet wird gemäß folgender Formel:

NCH = L/N.k

wobei k die Länge eines Abtastwerts ist, ausgedrückt in Anzahl der Bytes. Im AES67 Standard- Spezifikation ist angegeben dass k gleich 3 sein kann.

Wie oben bereits erwähnt, kann diese Information an den Tontechniker weitergeleitet werden, damit er imstande ist das übertragene AES kompatible Audioinformationssignal zu empfangen und zu dekodieren.

Fig. 5 zeigt ein UDP-Header, wie es in den IP-Paketen enthalten ist. Der UDP-Header besteht aus vier Felder: eine 16-Bit Quellenadresse (SRCE PORT), eine 16-Bit Empfangsadresse (DEST PORT), das oben bereits beschriebene 16-Bit Längenfeld L' 500 und ein 16-Bit CHECKSUM Feld. Das CHECKSUM Feld ist gedacht um Bitfehler im UDP-Header, im RTP- Header und im Datenfeld DATA zu finden und ggf. zu korrigieren. Bei anderen Protokollen wird dies dazu genutzt ein fehlerhaft übertragenes Paket erneut anzufordern. Da dies jedoch bei UDP so nicht vorgesehen ist, wird das CHECKSUM-Feld häufig auf 'null' gesetzt, was bedeutet das es nicht genutzt wird.

Erfindungsgemäß wird jetzt vorgeschlagen das CHECKSUM Feld des UDP-Headers zur Übertragung von Informationsdaten zu einem Mediastream zu nutzen. Dabei könnten im CHECKSUM-Feld Daten gespeichert werden die das zu übertragende Informationssignal weiter kennzeichnen. Dies könnte z.B. bei einem AES67 kompatiblen Informationssignal angewendet werden, könnte jedoch auch bei Übertragung von anderen Inf ormations Signalen über ein Netzwerk von Nutzen sein.

Die Kodierung in den so zur Verfügung stehenden 16 Bit im CHECKSUM Feld könnte wie folgt aussehen:

Bits 0,1 (die Bits 48 und 49 in Fig. 5): Übertragungstyp, wie z.B. AES67, TR01, TR03 und SMPTE2110, wobei Tr steht für Technical Recommendation.

Bits 2,3 (die Bits 50 und 51 in Fig. 5): Art der Daten, wie z.B. Audio, Video und Metadaten. Bit 4 (Bit 52 in Fig. 5): komprimiert ja/nein

Bit 5,6 (die Bits 53 und 54 in Fig. 5): Kodierungsart, wie z.B. JPEG2000 und TICO (tiny codec) Fig. 6 zeigt ein Ausführungsbeispiel einer Einrichtung zum Empfangen eines AES67 kompatiblen Informationssignals, das an einem Eingang 122 angeboten wird. Diese Einrichtung enthält ein 16-Bit langes Schieberegister 600, zum Speichern des Inhalts des 16- Bit CHECKSUM-Feldes eines UDP-Headers. Ausgänge der Speicherplätze der Bits 0 und 1 (die Bits 48 und 49 in Fig. 5) werden an eine erste Detektionseinheit 602 zugeführt. Die Detektionseinheit 602 leitet aus den Bitwerten der Bits 0 und 1 den Übertragungstyp TRM TYPE ab. Ausgänge der Speicherplätze der Bits 2 und 3 werden an eine zweite Detektionseinheit 604 zugeführt. Die Detektionseinheit 604 leitet aus den Bitwerten der Bits 2 und 3 (die Bits 50 und 51 in Fig. 5) die Art der übertragenden Daten DATA TYPE ab. Der Ausgang des Speicherplatzes des Bits 4 wird an eine dritte Detektionseinheit 606 zugeführt. Die Detektionseinheit 606 leitet aus dem Bitwert des Bits 4 (das Bit 52 in Fig. 5) ab ob das Informationssignal komprimiert wurde oder nicht COMP Y/N. Ausgänge der Speicherplätze der Bits 5 und 6 werden an eine vierte Detektionseinheit 608 zugeführt. Die Detektionseinheit 608 leitet aus den Bitwerten der Bits 5 und 6 (die Bits 53 und 54 in Fig. 5) den Kodierungsart COD TYPE ab.

Einrichtung zum Ableiten von signalspezifischen Kennzeichen aus einem seriellen Datenstrom, welche seriellen Datenstrom aus aufeinderfolgenden IP-Paketen aufgebaut ist, wobei die IP- Paketen einen IP-Header, einen UDP-Header, einen RTP-Header und einen Datenfeld enthalten, wobei die Einrichtung einen Eingang enthält zum Empfangen des seriellen Datenstroms, dass im UDP-Header in den IP-Paketen des seriellen Datenstroms ein Checksumfeld vorhanden ist, in welchem Checksumfeld Kennzeichen über den Inhalt des zu übertragenden seriellen Datenstroms gespeichert sind, und wobei die Einrichtung versehen ist mit einer Ableitungseinheit zum aus dem Checksumfeld eines IP-Pakets Ableiten dieser Kennzeichen.

Diese Kennzeichen können den Inhalt des Datenübertragungssignals, den Übertragungstyp und/oder die Art des Datenübertragungssignals und/oder die Art der Komprimierung und/oder die Kodierungsart angeben. So können wenigstens zwei Bits des Checksumfeldes, vorzugsweise die ersten zwei (Bits 0,1), folgende Übertragungstypen angeben: AES67, TrOl, Tr03 und SMPTE2110.

Oder es können wenigstens zwei Bits des Checksumfeldes, vorzugsweise die zweiten zwei Bits (Bits 2,3), folgende Arten der Daten im Datenübertragungssignal angeben: Audio, Video und Metadaten.

Oder, wenigstens ein Bit des Checksumfeldes, vorzugsweise das fünfte Bit (Bit 4), könnte folgende Komprimierungsarten angeben: komprimiert und unkomprimiert. Oder, es könnten wenigstens zwei Bits des Checksumfeldes, vorzugsweise das sechste und siebte Bit (Bits 5,6), folgende Kodierungsarten angeben: JPEG2000 und TICO. Die Einrichtung könnte dan genauso aussehen wie die Einrichtung in Fig. 6.