Audio Client

This section applies to the following Dallmeier HD cameras that are equipped with an analog Audio OUT interface:

Box Camera

• DF4620HD-DN Dome Camera

• DDF4620HDV-DN

In the “Audio client” tab, the processing of audio data, sent to the device by external applications using the User Datagram Protocol (UDP), is configured.

The available settings allow you to activate the output of the received audio data on the analog Audio OUT interface of the device.

Fig. 4-5

Note the following requirements for the output of audio data on the analog Audio OUT interface:

• The audio format of the audio source and the audio format defined in the audio client of the camera (“Mode” drop-down list) must be compatible.

• The defined destination port in the audio source and the port registered in the audio client of the camera (input field “Port (1024 … 65535)”) must be identical.

• With unicast, the audio source must transmit to the IP address of the camera and the IP address of the audio source (“Source IP address”) must be registered in the audio client of the camera.

• With multicast, the IP multicast address used by the audio source must be identical with the

“Multicast IP address” registered in the audio client of the camera.

For descriptions about the different transfer methods unicast and multicast, see section

“Transfer Method” on page 35.

If UDP is used to transmit the audio data, the settings in the audio client of the camera must be config-ured manually.

If the DaVid Protocol is used to control the audio output, the necessary information is sent to the audio client of the camera automatically.

Note that the settings in the “Audio client” tab are disabled if the audio output is con-trolled using the DaVid Protocol (e.g. with SMAVIA Viewing Client).

Controlling the Audio Output with SMAVIA Viewing Client

To control the audio output with SMAVIA Viewing Client, proceed as follows:

⇨ In SMAVIA Viewing Client, right-click the split of the respective camera.

⇨ In the context menu, select the required audio format and bit rate via “Recorder” > “Transmit Audio”.

SMAVIA Viewing Client will then transmit incoming audio data (e.g. from the microphone input of the PC) over the network to the audio client of the camera using the DaVid Protocol.

The camera decodes the receiving audio data and outputs the generated analog audio signals on the analog Audio OUT interface of the camera (e.g. on a connected speaker).

4.3.4 RTSP

The Real Time Streaming Protocol (RTSP) is used to control the continuous transmission of multime-dia content over IP based networks (memultime-dia streams).

RTSP uses a direct (bidirectional) communication with the RTSP streaming server of the camera.

On the one hand to determine the appropriate transmission protocol for the RTP data transfer (UDP or TCP). On the other hand to transmit control actions of IP-based RTSP applications (players) such as the starting and stopping of video transmissions.

The encoding, packaging and transport of the data streams from server to client is carried out unidirec-tionally using the Real-Time Transport Protocol (RTP).

Usually, RTP transmissions of streaming content are realized by using UDP (User Datagram Protocol).

However, RTSP transmissions are realized over a TCP connection (TCP = Transmission Control Proto-col).

The following points need to be considered for RTP transmissions using UDP:

• UDP is a so-called “unreliable” and connectionless communication protocol.

No connection is established to the receiver/client prior to the data transmission.

The receiver/client does not acknowledge the receipt of data.

During data transmissions over UDP, packet loss (lack of images) may occur.

Lost packets will not be sent again.

• Usually, UDP packets sent from the Internet to your Local Area Network (LAN) are blocked by Internet routers/firewalls in general.

• UDP allows for smooth and fast data transmissions with relatively low delays, i.e. with low packet delay variation (low “jitter”).

• Each RTSP/RTP transmission over UDP requires three ports to be open: A static port for the RTSP control commands (standard port number: 554) and two dynamic ports for the RTP data stream.

The following points need to be considered for RTP/RTSP transmissions over TCP:

• TCP is a so-called “reliable” and connection-oriented communication protocol.

A connection to the receiver/client is established prior to the data transmission.

The receiver/client confirms the receipt of each IP data packet by sending an acknowledge packet.

During data transmissions over TCP, usually, no packet loss occurs (unless in the case of a buffer overload in the camera due to a permanent network overload).

However, data transmissions over TCP may be slower than data transmissions over UDP.

• Usually, only the RTSP port must be open at the Internet router or the firewall to receive data trans-missions of RTP/RTSP/TCP packets sent from the Internet to your Local Area Network (LAN).

• RTSP allows you to embed the transmission of RTP streams into the existing RTSP/TCP connec-tion; a separate UDP transmission or an additional port for the RTP data stream is not necessary.

In the “RTSP” tab, you can configure the RTSP server in the camera.

Fig. 4-6

The standard port number for RTSP is 554.

In the “RTSP server port” field, the port number can be changed according to your requirements.

To generally prevent access to the RTSP server in the camera, i.e. not to allow any RTSP transmission, the corresponding check box can be unchecked.

RTP over RTSP Buffer

Note that the following section only applies to RTP transmissions over RTSP/TCP.

If the network is busy or if a switch within the network, respectively the receiver/client, no longer ac-cepts additional data, the camera can no longer send further image data. The result is a so-called “data backlog” in the camera.

In order to prevent a loss of images, the yet unsent image data can – at least for a short time – be saved in an internal RTSP buffer (default capacity 1024 kBytes).

Only in case of a buffer overload are all saved images lost.

Persistent network overload results in a delay in displaying the images at the client. The delay is propor-tional to the set size of the buffer (amount of images saved).

A large RTSP buffer is only recommended in case of short-term network overloads.

In case of a persistent network overload, a smaller buffer as well as lower bit rates are recommended for the individual encoder settings.

Chapter 5:

Video