Method and device for deriving audio parameter values from an AES67-compatible audio information signal

A method and a device are provided for deriving audio parameter values from an AES67-compatible audio information signal, which AES67-compatible audio information signal is generated from a serial data stream of successive IP packets (IP(i)), the IP packets containing an IP header (IP HDR), a UDP header (UDP HDR), an RTP header (RTP HDR) and a data field (DATA), and wherein audio parameter values such as sampling frequency and number of channels are derived from information stored in the headers.

BACKGROUND OF THE INVENTION

The invention relates to a method and a device for deriving audio parameter values from an AES67-compatible audio information signal. Such an information signal, which is specified in the AES67 audio standard, is generated from successive IP packets and transmitted as a pure bitstream (audio over IP or audio over ethernet).

With the transmission of audio information over IP, as has been standardized in AES67, in live IP productions, there is also a changeover from circuit-switched to packet-switched networks. In order to guarantee an error-free function, it is particularly important that the streams are transmitted correctly in the network.

BRIEF DESCRIPTION OF THE INVENTION

The object of the invention is to significantly improve the transmission of data in the network. The method according to the preamble of claim1is heretofore characterized according to the characterizing measures of claim1. In the same way, the device according to the invention is characterized according to the features of the eleventh claim.

The invention dwells on the following knowledge.

If the above-specified correct switching of the streams is not implemented in the network, the fault would be found if the network administrator knew the properties of the information signal which is received over the network.

So far, however, the network administrator is not able to obtain information about the streams from the data which is provided by the network. This is because the IP packets only contain the user data and all configuration data is transmitted via another channel.

The measures according to the invention nevertheless enable the network administrator to derive audio parameter values, such as the sampling frequency and the number of audio channels, from the received IP packets. First, the number of samples per channel which are contained in an RTP packet is derived, in accordance with claims1and2.

Thereafter, the sampling frequency can be derived, in accordance with claim3. Or, the number of channels is derived, in accordance with claim4.

Another possibility would be to record data in the checksum field of the UDP headers in the audio information signal about the content of the audio information signal and then to derive this data from the UDP headers instead of or in combination with the above-mentioned measures, in accordance with the characterizing feature of claim5. This can be data as defined in claims6to10. This has the advantage that additional information about the type of stream is nevertheless transmitted with the streams, without reducing the number of payload bits.

DETAILED DESCRIPTION OF THE FIGURES

FIG. 1shows an exemplary embodiment of a system in which an audio recording of a live production takes place, the recorded audio information signal is converted into an AES67-compatible audio information signal and is then transmitted over the Internet to a remote processing studio or a remote sound control room.

FIG. 1shows a recording studio, indicated schematically by reference number100, in which an audio recording of a live production takes place. A processing studio104is provided which is normally remote from the recording studio. In this example, the recording is carried out in the recording studio100by means of four microphones, which are positioned, for example, front left, front right, rear left and rear right in the recording studio. The recorded (here four-channel) audio information signal is converted in a conversion unit124into an AES67-compatible audio information signal. The conversion takes place in accordance with the conditions specified in the AES67 standard specification (e.g. AES67-2015: AES standard for audio applications of networks—High performance streaming audio-over-IP interoperability) in a transmission signal that can be transmitted over the Internet. The AES-compatible audio information signal is available at an output104which is connected to the Internet.

The AES67-compatible audio information signal is generated from successive IP packets which contain the samples of the audio information signal in the (in this example: four) channels. However, the AES67-compatible audio information signal as available at output104does not contain any information about the audio-specific parameter values of the audio information signal, such as the sampling frequency and the number of transmitted audio channels, which are contained in the audio information signal to be transmitted. The AES67 specification provides a so-called ‘Multicast Session description’ file118which contains information about these audio-specific parameters. The file is provided at an output106and fed via the Internet to a server108and stored there.

The file118also contains, inter alia, the source address of the recording studio100such that the output104can be identified over the Internet.

If a sound technician in the sound control room102wants to receive the audio recording of the live program for further processing of the audio information signal so that it can be provided as a broadcast transmission signal to one or more transmitters, she/he gets the ‘Multicast Session description’ file118from the server108via the Internet, see the communication over the connection110between sound control room102and server108inFIG. 1.

FIG. 2shows an example of a ‘Multicast Session description’ file118, as is also described in chapter 8.5.1 of the AES67-2015 standard specification.

Parameter c in the file specifies the source address (in this example IP4 239.0.0.1732), parameter i the number of audio channels (in this example 8) and the sampling frequency (in this example 48 kHz) can be seen below.

With this information, the sound engineer can receive the AES67-compatible audio information signal. The transmission of the AES67-compatible audio information signal from output104of the recording studio100over the Internet to an input112of the sound control room102takes place inFIG. 1via the switches114and116.

FIG. 3shows the structure of an AES67-compatible audio information signal that is provided via the Internet, switches114and116, to the input112of the sound control room102. The AES67 compatible audio information signal is made up of successive IP packets . . . IP (i), IP (i+1), IP (i+2), . . . . An IP packet contains an IP header IP-HDR, a UDP header UDP HDR, an RTP header RTP HDR, and a data field DATA. The AES67-compatible audio information signal can now be transmitted to the sound control room102and processed there.

What can possibly still happen is that a faulty transmission of data can occur between the output104of the recording studio100and the input112of the processing studio/sound control room102.

For once, the sound engineer may have downloaded an incorrect ‘Multicast Session description’ file118from server108. Or it may be that there is no ‘Multicast Session description’ file.

In order to eliminate such transmission problems, a network administration unit120is provided for monitoring the data which is transmitted over the Internet. To this end, this network administration unit120is in this case coupled to the network via the switch114and is configured to receive all AES67-compatible information signals from the recording studio100.

Because the AES67-compatible audio information signal, as already stated above, does not contain any information about the audio-specific parameter values of the audio information signal, such as, for example, the sampling frequency and the number of transmitted audio channels, which are contained in the to-be-transmitted audio information signal, it is not possible for the network administration unit120to derive these audio-specific parameter values directly from the AES67-compatible audio information signal.

In accordance with the invention, some suggestions are now described which make it possible to nevertheless derive these audio-specific parameter values from the AES67-compatible audio information signal.

First, the number N of samples per channel, which are contained in the data field DATA of an IP packet, is derived from the AES67-compatible audio information signal. This is achieved as follows.FIG. 3shows that there is a time stamp field TS(i) in the RTP header of the IP packet IP(i) and a time stamp field TS(i+1) in the RTP header of the IP packet IP(i+1). The network administration unit120derives the timestamp values TS(i) and TS(i+1) of these successive IP packets from the RTP headers of these packets. Then, N is derived by subtracting: TS(i+1)−TS(i)=N. As an example: TS(i)=n and TS(i+1)=n+2. This means that the data field DATA of the IP packets contains (n+2−n=) two samples per channel.

Another possibility of deriving the number N of samples per channel contained in a data field of an IP packet is as follows. The time stamps TS(i) and TS(j) are derived from the RTP headers of the IP packets IP(i) and IP(j). N is calculated as follows:
N={TS(j)−TS(i)}/(p+1),
where p is equal to the number of IP packets between the two IP packets (IP(i), IP(j)) in the serial data stream, p being an integer greater than or equal to zero.

FIG. 3shows an example of the content of the data field of the IP packet IP(i). It contains two samples s(1,1), s(1,2) of a first channel, then two samples s(2,1), s(2,2) of a second channel, then two samples s(3,1), s(3,2) of a third channel, and then two samples s(4,1), s(4,2) of a fourth channel. The data field DATA of the IP packet IP(i+1) contains eight samples: two samples s(1,3), s(1,4) of the first channel, then two samples s(2,3), s(2,4) of the second channel, then two samples s(3,3), s(3,4) of the third channel, and then two samples s(4,3), s(4,4) of the fourth channel.

In order to derive the number of channels which are transmitted in the AES67-compatible audio information signal, a value L′ is derived from the UDP header UDP HDR, as inFIG. 5. This value L′ specifies the length of the RTP packet (which is equal to the length of the RTP header and the data field DATA) expressed in bytes. Because the length of the RTP header RTP HDR is defined by default, the length L of the data field DATA thus can be derived from L′. Now, the number of channels is given by: L/N′, where N′=N·p, and p is the length of a sample, expressed in the number of bytes. p is also defined by default and is, for example, equal to 3 bytes.

To derive the sampling frequency, it is determined how many IP packets M are received in a specific time interval T. The sampling frequency can then be calculated as equal to N·M/T. M can be derived in different ways. First, M could be derived by counting the number of IP packets received in the given time interval. Second, one could also derive the sequence number of the first IP packet and the last IP packet that is received in the time interval and then calculate M by subtracting the two values. These sequence numbers are stored in the RTP header.

The network administrator can then pass this desired information to the sound engineer so that the transmitted AES67b compatible audio information signal can be received and decoded. Because the network administrator receives all information signals from the recording studio, as stated above, the network administrator can also derive the source address from the IP header of the AES-compatible audio information signal and forward it to the sound engineer.

FIG. 4shows a first exemplary embodiment of a device for deriving audio parameter values from the AES67-compatible audio information signal. The device includes an input122for receiving the AES67-compatible audio information signal. The device is provided with a derivation unit400for deriving information, in this example for deriving timestamps TS(i) and TS(j), of at least two RTP headers from at least two IP packets in the serial data stream of the AES67 which are output at two outputs and fed to inputs of a calculation unit402.

The number of channels N is calculated in the calculation unit402according to the following formula:
N={TS(j)−TS(i)}/(p+1)
where TS(i) and TS(j) are equal to the values of the two derived timestamps and p is the number of IP packets between the two IP packets (IP(i), IP(j)) in the serial data stream, where p is an integer greater than or equal to zero.

This means that the calculation unit contains a subtraction unit406for subtracting the two timestamp values from one another and a dividing unit408for dividing the result of the subtraction unit406by p+1.

The value N is then available at the output404of the dividing unit404.

To derive the sampling frequency Fs, the device contains a counting unit410and a timer unit412. The timer unit412determines a time interval T, and within this time interval T the counting unit counts the number M of IP packets which are received at the input122within this time interval T. The value M is available at the output414of the counter unit410and is provided to the calculation unit402. The value of the time interval T is also fed to the calculation unit402. The calculation unit402contains a sampling frequency calculation unit416, which receives the values N, M and T and derives the sampling frequency Fs therefrom, according to the formula: Fs=N M/T.

As already stated above, the unit410could instead be configured as a counting unit for reading out the sequence number of the first and last IP packet which is received within this time interval T. The unit could then then subtract the two sequence numbers from one another to derive the value M.

The derivation unit400is further configured to derive a length L expressed in bytes of the data field of the IP packet, from the UDP header. A value L′ is stored in the length field500of a UDP header, as shown inFIG. 5. This value L′ corresponds to the length of the RTP packet (that is, the length of the RTP header RTP HDR and the data field DATA, seeFIG. 3). Since the length of the RTP header is known, the length L of the data field DATA can thus be derived. This value L is also fed to the calculation unit402. A calculation is carried out in the calculation unit402in block418, wherein the number of channels NCH is calculated according to the following formula:
NCH=L/N·k
where k is the length of a sample expressed in number of bytes. The AES67 standard specification states that k can be 3.

As already mentioned above, this information can be passed on to the sound engineer so that she/he is able to receive and decode the transmitted AES-compatible audio information signal.

FIG. 5shows a UDP header as it is contained in the IP packets. The UDP header consists of four fields: a 16-bit source address (SRCE PORT), a 16-bit destination address (DEST PORT), the 16-bit length field L′500already described above and a 16-bit CHECKSUM field. The CHECKSUM field is intended to identify and, if necessary, correct bit errors in the UDP header, in the RTP header and in the DATA data field. In other protocols, this is used to request retransmission of an incorrectly transmitted packet again. However, as this is not envisaged for UDP, the CHECKSUM field is often set to ‘null’, which means that it is not used.

According to the invention, it is proposed to use the CHECKSUM field of the UDP header to transmit information data to a media stream. Data could be stored in the CHECKSUM field that further identifies the to-be-transmitted information signal. This could be done in case of an AES67-compatible information signal, for instance, but could also be feasible when transmitting other information signals over a network.

The coding in the 16 bits available in the CHECKSUM field could look as follows:

Bits0,1(bits48and49inFIG. 5): transmission type such as AES67, TR01, TR03 and SMPTE2110, where Tr stands for Technical Recommendation.

Bits2,3(bits50and51inFIG. 5): type of data, such as audio, video and metadata.

FIG. 6shows an exemplary embodiment of a device for receiving an AES67-compatible information signal, which is provided at an input122. This device contains a 16-bit shift register600for storing the content of the 16-bit CHECKSUM field of a UDP header. Outputs of the memory locations of bits0and1(bits48and49inFIG. 5) are fed to a first detection unit602. The detection unit602derives the transmission type TRM TYPE from the bit values of bits0and1. Outputs of the memory locations of bits2and3are fed to a second detection unit604. The detection unit604derives from the bit values of bits2and3(bits50and51inFIG. 5) the type of data DATA TYPE to be transmitted. The output of the memory location of bit4is fed to a third detection unit606. The detection unit606derives from the bit value of bit4(bit52inFIG. 5) whether the information signal has been compressed or not COMP Y/N. Outputs of the memory locations of bits5and6are fed to a fourth detection unit608. The detection unit608derives the coding type COD TYPE from the bit values of bits5and6(bits53and54inFIG. 5).

Device for deriving signal-specific identifiers from a serial data stream, which serial data stream is constructed from successive IP packets, the IP packets containing an IP header, a UDP header, an RTP header and a data field, the device comprising an input for receiving the serial data stream, a checksum field being present in the UDP header in the IP packets of the serial data stream, in which indicators are stored about the content of the serial data stream to be transmitted, the device being provided with a derivation unit to derive these indicators from the checksum field of an IP packet.

These indicators can indicate the content of the data transmission signal, the transmission type and/or the type of data transmission signal and/or the type of compression and/or the type of coding. At least two bits of the checksum field, preferably the first two (bits0,1), can indicate the following transmission types: AES67, Tr01, Tr03 and SMPTE2110.

Or at least two bits of the checksum field, preferably the second two bits (bits2,3), can specify the following types of data in the data transmission signal: audio, video and metadata.

Or, at least one bit of the checksum field, preferably the fifth bit (bit4), could indicate the following types of compression: compressed and uncompressed. Or, at least two bits of the checksum field, preferably the sixth and seventh bit (bits5,6), could indicate the following types of coding: JPEG2000 and TICO. The device could then look exactly like the device inFIG. 6.