SETIT 2005 3rd International Conference: Sciences of Electronic, Technologies of Information and Telecommunications March 27-31, 2005 – TUNISIA Tutorial on Multicast Video Streaming Techniques Hatem BETTAHAR Heudiasyc, Université de Technologie de Compiègne, France [email protected] Abstract: This tutorial gives a survey of actual used techniques for multicast streaming video. We first discuss important issues in video streaming namely video compression techniques and video compression standards. We then present the challenges in multicast video streaming and we give a detailed description of recent proposals for multicast video streaming. We classify these solutions into four approaches depending on the techniques used to adapt the reception video quality and on the source/receiver/network role . Key words: QoS adaptation, multicast, multimedia applications, video streaming streaming and we classify these solutions into four 1. Introduction approaches depending on the techniques used to adapt the reception video quality and on the role of the Multicast communication is an efficient solution source, the receivers and the network. for group applications in the Internet. Multicast conserves the network bandwidth by constructing a spanning tree between sources and receivers in the 2. Video streaming session. A single copy of the date is send to all the 2.1. Vide o streaming architecture receivers through the multicast tree. Most multiparty applications over the internet are multimedia oriented. A typical multicast streaming scheme is Applications such as videoconferencing, distant represented in Figure 1. A multicast source learning or network games use video, audio and data implements a streaming server which is responsible traffic. This traffic is bandwidth consumer. In addition, for retrieving, sending and adapting the video stream. the current best effort service and the uncontrolled Depending on the application, the video may be dynamic state in the internet require multimedia encoded on-line for a real-time transmission or pre- adaptation techniques to overcome these problems. encoded and stored for an on demand transmission. For these reasons, combining multicast and video rate Applications such as video conferencing, live adaptation technique seams to be a suitable solution broadcast or interactive group games require real-time for video streaming over the internet. However, a set encoding. However, applications such as video on- of open issues, such as receiver heterogeneity and demand require pre-encoded video. Whence the feedback implosion, should be treated in order to have multicast session is initialized, the streaming server an efficient and viable solution for multicast video retrieves the compressed video and begins the streaming. streaming with the adequate bit-stream rate. This tutorial is organized as follows: in section 2 Streaming Server we give an overview of video streaming, and we stress Video Input the requirements for an efficient and streaming Receiver architecture over IP networks. In the section 3 we Codec present some important issues in video compression. Video Storage Codec This is essential, because compression techniques are QoS Control the base of many multicast streaming proposals. In QoS Control Transport Protocol section 4 we study the challenges in multicast video Transport Protocol streaming: rate control, playout buffer and error control. Finally in section 5 we give a detailed description of recent proposals for multicast video Internet SETIT2005 terminate multimedia sessions such as Internet telephony calls (VOIP). SIP can also invite participants to already existing sessions, such as Figure 1. Video Streaming Architecture multicast conferences. RTSP establishes and controls 2.2. Streaming protocols and standards either a single or several time-synchronized streams of continuous media such as audio and video. It acts as a In this section we give a brief description of the "network remote control" for multimedia servers. network protocols for video streaming over the RTSP provides an extensible framework to enable Internet. Figure 2 resumes the set of protocols controlled, on-demand delivery of real-time data, such described below. as audio and video. Sources of data can include both live data feeds and stored clips. RTSP is intended to control multiple data delivery sessions, provide a SDP SAP means for choosing delivery channels such as UDP, multicast UDP and TCP, and provide a means for SIP RTSP RTCP RTP choosing delivery mechanisms bases upon RTP Session description: SDP TCP UDP The Session Description Protocol (SDP) describes IPv4, IPv6 multimedia sessions, for example whether it is video or audio, the specific codec, bit rate, duration, etc, for Figure 2. Streaming Protocols Stack the purpose of session announcement, session invitation and other forms of multimedia session monitoring. Session directories assist the Real-Time transmission control: RTP/RTCP advertisement of conference sessions and The Real-time Transport Protocol (RTP) and Real- communicate the relevant conference setup time Control Protocol (RTCP) (Schulzrinne &al. information to prospective participants. SDP is 1996) are IETF protocols designed to support designed to convey such information to recipients. streaming media. RTP is designed for data transfer and SDP is purely a format for session description - it does RTCP for control messages. Note that these protocols not incorporate a transport protocol, and is intended to do not enable real-time services, only the underlying use different transport protocols as appropriate network can do this, however they provide including the Session Announcement Protocol (SAP). functionalities that support real-time services. RTP does not guarantee QoS or reliable delivery, but Session Announcement: SAP provides support for applications with time constraints Session Announcement Protocol (SAP) is an by providing a standardized framework for common announcement protocol that is used to assist the functionalities such as time stamps, sequence advertisement of multicast multimedia conferences numbering, and payload specification. RTP enables and other multicast sessions, and to communicate the detection of lost packets. RTCP provides feedback on relevant session setup information to prospective quality of data delivery in terms of number of lost participants. A SAP announcer periodically multicasts packets, inter-arrival jitter, delay, etc. RTCP specifies an announcement packet to a well-known multicast periodic feedback packets, where the feedback uses no address and port. A SAP listener learns of the more than 5 % of the total session bandwidth and multicast scopes it is within (for example, using the where there is at least one feedback message every 5 Multicast-Scope Zone Announcement Protocol) and seconds. The sender can use the feedback to adjust its listens on the well known SAP address and port for operation, e.g. adapt its bit rate. The conventional those scopes. In this manner, it will eventually learn of approach for media streaming is to use RTP/UDP for all the sessions being announced, allowing those the media data and RTCP/TCP or RTCP/UDP for the sessions to be joined. control. Often, RTCP is supplemented by another feedback mechanism that is explicitly designed to provide the desired feedback information for the 3. Video compression techniques specific media streaming application. Other useful In this section we describe briefly important issues in functionalities facilitated by RTCP include inter- video compression. This is useful to understand some stream synchronization and round-trip time multicast streaming solutions described in the fifth measurement. section. 3.1. Video Compression overview Session control: SIP/RTSP Video compression is the process in which the amount The Session Initiation Protocol (SIP) and the Real- of data used to represent video is reduced to meet a bit Time Streaming Protocol (RTSP) are used to control rate requirement for a given application. This is media streaming sessions. SIP is an application-layer achieved by exploiting temporal redundancy between control protocol that can establish, modify, and SETIT2005 consecutive frames in a video sequence as well as widespread acceptance was the ITU H.261 [11], which spatial redundancy within a single frame. In addition was designed for videoconferencing over the only video features that are perceptually important for integrated services digital network (ISDN). H.261 was human are coded. In current video compression adopted as a standard in 1990. It was designed to standards, such as MPEG and H261 families, temporal operate at p = 1,2, ..., 30 multiples of the baseline redundancy is exploited by applying Motion ISDN data rate, or p x 64 kb/s. In 1993, the ITU-T Compensation techniques and the special redundancy initiated a standardization effort with the primary goal is exploited by applying the DCT transormation of videotelephony over the public switched telephone (Discrete Cosine Transform). Using DCT, picture network (PSTN), where the total available data rate is frames are first separated into square blocks of size only about 33.6 kb/s. The video compression portion 8x8. Each block is DCT transformed, resulting in of the standard is H.263 and its first phase was another 8x8 block in frequency domain, whose adopted in 1996 [12]. An enhanced H.263, H.263 coefficients are then quantized and coded. Most of the Version 2 (V2), was finalized in 1997, and a quantized high-frequency