Configuración narrativa

Videoconferencing systems provide a framework to send/receive audio and video streams. On the other hand there are also some clients who do not need to send streams to interact with another client but only receive a stream. These clients can receive streams with some delay since there is no need to interact with other clients. Also these clients do not want flickering in the video or noise in the audio if the bandwidth to the client is variable. Streaming provides a framework to deliver media across large distances over the Internet while minimizing the problems that clients may have.

Streaming media aims to improve the quality of service of the stream, by using various streaming codecs and a buffering mechanism to reduce the jitter. The buffering mechanism causes the stream to be delayed for some time. Hence, streaming media does not provide a good interactive environment compared to the interactivity in a videoconferencing system, but the stream quality is improved.

Another feature of streaming that distinguishes it from conferencing is that streaming uses compression algorithms that cause streams to be compressed more so that less bandwidth is required in order to transmit a stream across the network. The side effect of this is that compression/decompression requires high CPU utilization because it involves much computation. Also the buffer delay in streaming is much longer than the

buffer delay in conferencing. While in conferencing it is recommended that mouth-to-ear delay of audio be less than 300 msec [64], the delay in streaming buffer in today’s streaming players is around 2 – 15 sec.

2.2.1

Real Time Streaming Protocol

A streaming client connects to a streaming server primarily using Real Time Streaming Protocol (RTSP) [14], to establish a session and receive the stream. Streaming is primarily used for Media-On-Demand that is receiving media that resides on a streaming server whenever a client wants to play. RTSP is a client-server multimedia presentation control protocol and is stateful. It provides VCR-like control, so that clients can pause, fast forward, reverse, and absolute position etc.

Figure 2-3: RTSP states

RTSP is a protocol specified in the Internet Engineering Task Force’s RFC 2326 for control over the delivery of live or stored data with real-time properties. RTSP is similar in syntax and operation to HTTP/1.1 [65], which allows RTSP to be extended by HTTP, but as opposed to HTTP, RTSP maintains state by default. States involved in

RTSP are init, ready, playing/recording. Basic RTSP control functionalities are play, pause, seeking (absolute positioning to a specific point in the stream) etc. While some methods cause state change, some do not. RTSP states are shown in Figure 2-3.

RTSP uses Session Description Protocol (SDP) [66] to describe the multimedia session. It is also used for session announcements and session invitation. SDP is a text based protocol. Some of the metadata included in the SDP description are multimedia session owner information, stream information such as media type and media format, human readable session description, session begin time and end time, URLs for session resources.

RTSP does not mandate any data packet format for sending media to client but usually standard Real-Time Transport Protocol (RTP) [15] is used. Some vendors like RealNetworks may have their own data packet formats, RealNetworks’ Real Data Transport (RDT) [67]. This information is exchanged during RTSP session setup.

There are other streaming protocols such as Windows Media Services HTTP 1.1 (WMS HTTP 1.1) [68] which is also an extension of HTTP 1.1 with similar functionality to RTSP.

Figure 2-4 displays RTSP signaling between client and server. State of the connection describes which methods the client can request. Depending on the state, client may be limited to some of the methods provided to it.

Any type of media format can be used for data. RTSP Server is responsible for sending data to client. In this case it has to be capable of understanding the media format of the stream, that is, it has to support the format otherwise it cannot process the request.

In case of a heavy load on the server, the server can redirect the client to another RTSP server. The client needs to be provided with the address of the new RTSP server in order to make requests to the new server. RTSP does not describe any load balancing mechanism among servers; the client needs to find one that can accept its request through trial and error.

!"# $$ "$

% &$ $$ "$

Figure 2-4: A typical RTSP session

2.2.2

Handling Streaming Formats

Streaming servers may support different media formats and encodings such as RealNetworks’ RealMedia [39-41], Apple’s QuickTime [22], Microsoft’s WindowsMedia [69] or Moving Picture Experts Group (MPEG) audio and video formats

streaming servers while other encodings may be supported by any streaming server. But streaming servers are not required to support all of the formats and encodings. For this reason, vendors have their own specific clients to play their specific formats and encodings.

A streaming server may use files or multimedia storages to archive and replay streams. Multimedia storages are special type of storage designed specifically to achieve high performance during retrieval of multimedia files. Audio and video data consists of frames that must be retrieved in sequence in order to play continuously. So media frames need to be grouped into storage blocks in a continuous manner to improve storage performance. There are two approaches to store multimedia data described below.

In the first approach the media server needs to know the details of the encoding and the format in order to map media frames to storage blocks. For example, an MPEG- encoded video contains I, B, and P frames. While I frames can be decoded independently, P frames depend on the previous I frame and B frames depend on the preceding and the following I or P frame. Consequently the multimedia server needs to know the details of the standard.

In the second approach a multimedia file is considered as a stream of bytes and is partitioned into fixed size storage blocks. In this case during replay the average compression ratio of the multimedia file, which also depends on the media format and encoding, is taken into account while reading the storage blocks during the delivery of the media to the client.