6.1: Multimedia Networking Applications
Chapter 6: Multimedia NetworkingIn this chapter we consider networking applications whose data contains audioand video content. We refer to these applications as multimedia networkingapplications. Multimedia networking applications are typically highly sensitive todelay but are loss tolerant. After surveying and classifying different types ofmultimedia applications, we examine their deployment in a best-effort network,such as today’s Internet. We explore how a combination of client buffers, packetsequence numbers and timestamps can greatly alleviate the effects of networkinduced delay and jitter. We also study how forward error correction and packetinterleaving can improve user perceived performance when a fraction of packetsare lost or significantly delayed. We examine the RTP and H.323 protocols forreal-time telephony and video conferencing in the Internet. We then look at howthe Internet can evolve to provide improved QoS (Quality of Service) to itsapplications. We identify several principles for providing QoS, including packetmarking and classification, isolation of packet flows, efficient use of resources,and call admission. We survey several scheduling and policing mechanisms thatprovide the foundation of a QoS network architecture. We then discuss newInternet standards for QoS, including the Integrated Services and theDifferentiated Services standards.Online Book6.1: Multimedia Networking ApplicationsHaving completed our journey down the protocol stack in Chapter 5, wenow have a strong grounding in the principles and practice of computernetworking. This foundation will serve us well as we turn in this chapter to atopic that cuts across many layers of the protocol stack: multimedianetworking.The last few years have witnessed an explosive growth in the developmentand deployment of networked applications that transmit and receive audioand video content over the Internet. New multimedia networkingapplications (also referred to as continuous media applications)-entertainment video, IP telephony, Internet radio, multimedia WWW sites,teleconferencing, interactive games, virtual worlds, distance learning, andmuch more--seem to be announced daily. The service requirements ofthese applications differ significantly from those of traditional data-orientedapplications such as the Web text/image, e-mail, FTP, and DNSapplications that we examined in Chapter 2. In particular, multimediaapplications are highly sensitive to end-to-end delay and delay variation,but can tolerate occasional loss of data. These fundamentally differentservice requirements suggest that a network architecture that has beendesigned primarily for data communication may not be well suited forsupporting multimedia applications. Indeed, we’ll see in this chapter that a
number of efforts are currently underway to extend the Internet architectureto provide explicit support for the service requirements of these newmultimedia applications.We’ll begin our study of multimedia networking in a top-down manner (ofcourse!) by describing several multimedia applications and their servicerequirements in Section 6.1. In Section 6.2, we look at how today’s Webservers stream audio and video over the Internet to clients. In Section 6.3we examine a specific multimedia application, Internet telephony, in detail,with the goal of illustrating some of the difficulties encountered (andsolutions developed) when applications must necessarily use today’s besteffort Internet transport service. In Section 6.4 we describe the RTPprotocol, an emerging application-layer standard for framing and controllingthe transmission of multimedia data.In the second half of this chapter we turn our attention toward the futureand towards the lower layers of the protocol stack, where we examinerecent advances aimed at developing a next-generation networkarchitecture that provides explicit support for the service requirements ofmultimedia applications. We’ll see that rather than providing only a singlebest-effort service class, these future architectures will also include serviceclasses that provide quality-of-service (QoS) performance guarantees tomultimedia applications. In Section 6.5 we identify key principles that will lieat the foundation of this next generation architecture. In Section 6.6 weexamine specific packet-level scheduling and policing mechanisms that willbe important pieces of this future architecture. Sections 6.7 and 6.9introduce the so-called Intserv and Diffserv architectures, emerging Internetstandards for the next generation QoS-sensitive Internet. In Section 6.8, weexamine RSVP, a signaling protocol that plays a key role in both Intservand Diffserv.In our discussion in Chapter 2 of application service requirements, weidentified a number of axes along which these requirements can beclassified. Two of these characteristics--timing considerations and toleranceto data loss--are particularly important for networked multimediaapplications. Multimedia applications are highly delay sensitive. We willsee shortly that packets that incur a sender-to-receiver delay of more than afew hundred milliseconds (for Internet telephony) to a few seconds (forstreaming of stored multimedia) are essentially useless. On the other hand,multimedia networking applications are also typically loss tolerant-occasional loss only causes occasional glitches in the audio/videoplayback, and these losses can be often partially or fully concealed. Theseservice requirements are clearly different from those of elastic applicationssuch as Web text/image, e-mail, FTP, and Telnet. For these applications,long delays are annoying but not particularly harmful, and the integrity oftransferred data is of paramount importance.
6.1.1: Examples of Multimedia ApplicationsThe Internet carries a large variety of exciting multimedia applications. Inthe following sections, we consider three broad classes of multimediaapplications.Streaming, Stored Audio and VideoIn this class of applications, clients request on-demand compressed audioor video files that are stored on servers. Stored audio files might containaudio from a professor’s lecture (you are urged to visit the Web site for thisbook to try this out!), rock songs, symphonies, archives of famous radiobroadcasts, or archived historical recordings. Stored video files mightcontain video of a professor’s lecture, full-length movies, prerecordedtelevision shows, documentaries, video archives of historical events,cartoons, or music video clips. There are three key distinguishing featuresof this class of applications. Stored media. The multimedia content has been prerecorded and isstored at the server. As a result, a user may pause, rewind, fastforward or index through the multimedia content. The time fromwhen a client makes such a request until the action manifests itselfat the client should be on the order of 1 to 10 seconds for acceptableresponsiveness. Streaming. In most stored audio/video applications, a client beginsplayout of the audio/video a few seconds after it begins receiving thefile from the server. This means that the client will be playing outaudio/video from one location in the file while it is receiving laterparts of the file from the server. This technique, known asstreaming, avoids having to download the entire file (and incurring apotentially long delay) before beginning playout. There are manystreaming multimedia products, including RealPlayer fromRealNetworks [RealNetworks 2000] and Microsoft’s Windows Media[Microsoft Windows Media 2000]. There are also applications suchas Napster [Napster 2000], however, that require an entire audio fileto be downloaded before playout begins. Continuous playout. Once playout of the multimedia begins, it shouldproceed according to the original timing of the recording. This placescritical delay constraints on data delivery. Data must be receivedfrom the server in time for its playout at the client; otherwise, it isconsidered useless. In Section 6.3, we’ll consider the consequencesof this requirement in detail. The end-to-end delay constraints forstreaming, stored media are typically less stringent than those forlive, interactive applications such as Internet telephony and videoconferencing (see below).
Real Networks: Bringing Audio to the Internet ForegroundRealNetworks, pioneers in streaming audio and video products, was the first company tobring audio to the Internet mainstream. The company began under the name ProgressiveNetworks in 1995. Its initial product--the RealAudio system-- included an audio encoder, anaudio server, and an audio player. The RealAudio system enabled users to browse, selectand play back audio content on demand, as easily as using a standard video cassetteplayer/recorder. It quickly became popular for providers of entertainment, information, andnews content to deliver audio on demand services that can be accessed and played backimmediately. In early 1997, RealNetworks expanded its product line to include video aswell as audio. RealNetwork products currently incorporate RTP and RTSP protocols.Over the past few years, RealNetworks has seen tough competition from Microsoft (which also has minority ownership ofRealNetworks). In 1997 Microsoft began to market its own streaming media products, essentially setting the stage for a"media-player war," similar to the browser war between Netscape and Microsoft. But RealNetworks and Microsoft havediverged on some of the underlying technology choices in their players. Waging the tug of war in the marketplace and inInternet standards groups, both companies are seeking to have their own formats and protocols become the standard forthe Internet.Streaming of Live Audio and VideoThis class of application is similar to traditional broadcast radio andtelevision, except that transmission takes place over the Internet. Theseapplications allow a user to receive a live radio or television transmissionemitted from any corner of the world. (For example, one of the authors ofthis book often listens to his favorite Philadelphia radio stations from hishome in France. The other author regularly listened to live broadcasts of hisuniversity’s beloved basketball team while he was living in France for ayear.) See [Yahoo!Broadcast 2000] and [NetRadio 2000] for Internet radiostation guides.Since streaming live audio/video is not stored, a client cannot fast forwardthrough the media. However, with local storage of received data, otherinteractive operations such as pausing and rewinding though livemultimedia transmissions are possible in some applications. Live,broadcast-like applications often have many clients who are receiving thesame audio/video program. Distribution of live audio/ video to manyreceivers can be efficiently accomplished using the multicasting techniqueswe studied in Section 4.8. At the time of the writing of this book, however,this type of distribution is more often accomplished through multipleseparate unicast streams. As with streaming stored multimedia, continuousplayout is required, although the timing constraints are less stringent thanfor live interactive applications. Delays of up to tens of seconds from whenthe user requests the delivery/playout of a live transmission to when playoutbegins can be tolerated.Voice over the InternetGiven the worldwide popularity of the telephone system, since the late 1980s manyInternet visionaries have repeatedly predicted that the next Internet killer application wouldbe some sort of voice application. These predictions were accompanied with Internet
telephony research and product development. For example, researchers created Internetphone prototypes in the 1980s, years before the Web was popularized. And numerousstartups produced PC-to-PC Internet phone products throughout the 1990s. But none ofthese prototypes or products really caught on with mainstream Internet users (even thoughsome were bundled with popular browsers). Not until 1999 did voice communication beginto get popularized in the Internet.Three classes of voice communication applications began to see significant usage in the late 1990s. The first class is thePC-to-phone applications, which allow an Internet user with an Internet connection and a microphone to call any ordinarytelephone. Two companies active in the PC-to-phone space are Net2Phone [Net2Phone 2000] and Dialpad [Dialpad2000]. These PC-to-phone services tend to be free and hence enormously popular with people who love to talk but areon a budget. (Dialpad, which launched in October 1999, claims to have attracted over 3 million users in less than threemonths). The second class of applications consists of the voice chat applications, for which many companies currentlyprovide products, including Hearme [Hearme 2000], Firetalk [Firetalk 2000], and Lipstream [Lipstream 2000]. Theseproducts allow the members in a chat room to converse with their voices, although only one person can talk at a time.The third class of applications is that of asynchronous voice applications, including voice e-mail and voice messageboards. These applications allow voice messages to be archived and browsed. Some of the companies in this last spaceinclude Wimba [Wimba 2000], Onebox [Onebox 2000], and RocketTalk [RocketTalk 2000].Real-time Interactive Audio and VideoThis class of applications allows people to use audio/video to communicatewith each other in real time. Real-time interactive audio is often referred toas Internet phone, since, from the user’s perspective, it is similar totraditional circuit-switched telephone service. Internet phone can potentiallyprovide PBX, local, and long-distance telephone service at very low cost. Itcan also facilitate computer-telephone integration (CTI), group real-timecommunication, directory services, caller identification, caller filtering, andmore. There are many Internet telephone products currently available. Withreal-time interactive video, also called video con ferencing, individualscommunicate visually as well as orally. There are also many real-timeinteractive video products currently available for the Internet, includingMicrosoft’s NetMeeting. Note that in a real-time interactive audio/videoapplication, a user can speak or move at anytime. For a conversation withinteraction among multiple speakers, the delay from when a user speaks ormoves until the action is manifested at the receiving hosts should be lessthan a few hundred milliseconds. For voice, delays smaller than 150milliseconds are not perceived by a human listener, delays between 150and 400 milliseconds can be acceptable, and delays exceeding 400milliseconds can result in frustrating, if not completely unintelligible, voiceconversations.6.1.2: Hurdles for Multimedia in Today’s InternetRecall from Chapter 4 that today’s Internet’s network-layer protocolprovides a best-effort service to all the datagrams it carries. In otherwords, the Internet makes its best effort to move each datagram fromsender to receiver as quickly as possible. However, best-effort service doesnot make any promises whatsoever about the end-to-end delay for anindividual packet. Nor does the service make any promises about thevariation of packet delay within a packet stream. As we learned in Chapter3, because TCP and UDP run over IP, neither of these protocols can makeany delay guarantees to invoking applications. Due to the lack of anyspecial effort to deliver packets in a timely manner, it is an extremely
challenging problem to develop successful multimedia networkingapplications for the Internet. To date, multimedia over the Internet hasachieved significant but limited success. For example, streaming storedaudio/video with user-interactivity delays of five-to-ten seconds is nowcommonplace in the Internet. But during peak traffic periods, performancemay be unsatisfactory, particularly when intervening links are congestedlinks (such as congested transoceanic links).Internet phone and real-time interactive video has, to date, been lesssuccessful than streaming stored audio/video. Indeed, real-time interactivevoice and video impose rigid constraints on packet delay and packet jitter.Packet jitter is the variability of packet delays within the same packetstream. Real-time voice and video can work well in regions wherebandwidth is plentiful, and hence delay and jitter are minimal. But qualitycan deteriorate to unacceptable levels as soon as the real-time voice orvideo packet stream hits a moderately congested link.The design of multimedia applications would certainly be morestraightforward if there were some sort of first-class and second-classInternet services, whereby first-class packets are limited in number andreceive priority service in router queues. Such a first-class service could besatisfactory for delay-sensitive applications. But to date, the Internet hasmostly taken an egalitarian approach to packet scheduling in router queues.All packets receive equal service; no packets, including delay-sensitiveaudio and video packets, receive special priority in the router queues. Nomatter how much money you have or how important you are, you must jointhe end of the line and wait your turn! In the latter half of this chapter, we’llexamine proposed architectures that aim to remove this restriction.So for the time being we have to live with best-effort service. But given thisconstraint, we can make several design decisions and employ a few tricksto improve the user-perceived quality of a multimedia networkingapplication. For example, we can send the audio and video over UDP, andthereby circumvent TCP’s low throughput when TCP enters its slow-startphase. We can delay playback at the receiver by 100 msecs or more inorder to diminish the effects of network-induced jitter. We can timestamppackets at the sender so that the receiver knows when the packets shouldbe played back. For stored audio/video we can prefetch data duringplayback when client storage and extra bandwidth is available. We caneven send redundant information in order to mitigate the effects of networkinduced packet loss. We’ll investigate many of these techniques in the restof the first half of this chapter.6.1.3: How Should the Internet Evolve to Better SupportMultimedia?Today there is a tremendous--and sometimes ferocious--debate about howthe Internet should evolve in order to better accommodate multimedia trafficwith its rigid timing constraints. At one extreme, some researchers arguethat it isn’t necessary to make any fundamental changes to best-effort
service and the underlying Internet protocols. Instead, they argue that it isonly necessary to add more bandwidth to the links (along with networkcaching for stored information and multicast support for one-to-many realtime streaming). Opponents of this viewpoint argue that additionalbandwidth can be costly, and that as soon as it is put in place it will beeaten up by new bandwidth-hungry applications (for example, highdefinition video on demand).At the other extreme, some researchers argue that fundamental changesshould be made to the Internet so that applications can explicitly reserveend-to-end bandwidth. These researchers feel, for example, that if a userwants to make an Internet phone call from host A to host B, then the user’sInternet phone application should be able to explicitly reserve bandwidth ineach link along a route from host A to host B. But allowing applications tomake reservations and requiring the network to honor the reservationsrequires some big changes. First we need a protocol that, on the behalf ofapplications, reserves bandwidth from the senders to their receivers.Second, we must modify scheduling policies in the router queues so thatbandwidth reservations can be honored. With these new schedulingpolicies, not all packets get equal treatment; instead, those that reserve(and pay) more get more. Third, in order to honor reservations, theapplications must give the network a description of the traffic that t
applications. Multimedia applications are highly delay sensitive. We will see shortly that packets that incur a sender-to-receiver delay of more than a few hundred milliseconds (for Internet telephony) to a few seconds (for streaming of stored multimedia) are essentially useless. On the other hand, multimedia networking applications are also .
Introduction to Multimedia (continued) Multimedia becomes interactive multimedia when a user is given the option of controlling the elements. Interactive multimedia is called hypermedia when a user is provided a structure of linked elements for navigation. Multimedia developers develop multimedia projects.
Learn the phases involved in multimedia planning, design and production; Be able to use various multimedia authoring tools Be able to design and create interactive multimedia products Develop competencies in designing and producing instruction-al multimedia Apply contemporary theories of multimedia learning to the development of multimedia .
Multimedia Networking (Networked) Multimedia Applications Definition: Networked applications that employ . *Source: Cisco Visual Networking Index: Forecast and Methodology, 2016– . Cisco) Comparison of bit rate requirements of three internet applicatio
MULTIMEDIA TECHNOLOGY UNIT – I Multimedia an overview: Introduction The word ‗multimedia‘ comes from the Latin words multus which means ‗numerous‘ and media which means ‗middle‘ or center. Multimedia therefore means ‗multiple intermediaries‘ or ‗multiple means‘. Multimedia
MULTIMEDIA V.S MULTIMEDIA INTERAKTIF Multimedia adalah penggunaan berbagai jenis media (teks, suara,grafik,animasi,danvideo). Multimedia interaktif menambahkan elemen ke-enam yaitu aspek interaktif Pada multimedia non-interaktif, user bertindak pasif dan menyaksikan adegan demi adegan secara berurut
multimedia contexts and for converting one file format to another. Multimedia Editing Tools- These tools are used for creating and editing digital multimedia data. Multimedia Authoring Tools- These tools are used for combing different kinds of media formats and deliver them as multimedia contents. Graphic and Image Editing Software
3 Chapter 7 outline 7.1 Multimedia Networking Applications 7.2 Streaming stored audio and video 7.3 Real-time Multimedia: Internet Phone study 7.6 Beyond Best Effort 7.7 Scheduling and Policing Mechanisms 7.8 Integrated Services and 7: Multimedia Networking 7-13
A. ASTM International (ASTM). 1. ASTM C167 - [2009], Standard Test Method for Thickness and Density of Blanket or Batt Thermal Insulations. 2. ASTM C356 - [2010], Standard Test Method for Linear Shrinkage of Preformed High-Temperature Thermal Insulation Subjected to Soaking Heat. 3. ASTM C423 - [2009a], Standard Test Method for Sound Absorption and Sound Absorption Coefficients by the .
