Transmission of MPEG-2 Streams over Non-Guaranteed Quality of Service Networks

ABSTRACT: The explosive growth of the Internet andthe intranets attracted a great deal of attention to theimplementations and performances of networkedmultimedia services, which involve the transport ofreal-time multimedia streams over non-guaranteedquality of service (QoS) networks. In this paper, wediscuss some issues related to the transport of MPEG-2streams over such networks by means of the most recenttransport protocols compliant with the Real-TimeTransport Protocol (RTP) [1] defined by the InternetEngineering Task Force (IETF). MPEG-2 encodedaudio and video transmission is important for severalapplications including high quality video-on-demand asa part of information-on-demand and high qualityvideo conferencing using the existing networkinfrastructures.1. INTRODUCTIONMultimedia transport protocols play an important role inthe effective delivery and networking of multimediadata. In recent years, several application and transportprotocols have been developed. In this context, theMPEG committee has developed the program and thetransport streams for the delivery of several MPEG-2encoded video and audio programs together withgeneral purpose data. The program stream (PS) isintended for mostly error free environments. Thetransport stream (TS), on the other hand, addresses theneeds of relatively error prone systems such as point-to-point, dedicated transmission systems for televisionprogram distribution, cable systems for set-top boxes,etc. [2]. The ubiquity of the Internet and the continuous increasein the computing power of the desktop computerstogether with the availability of relatively inexpensiveMPEG-2 codec hardware in the form of computer plug-in boards have made MPEG-2 based, high quality videocommunications an interesting possibility for thedesktop computers. The biggest challenge inimplementing such systems is to be able to sustaincontinuous playback under high packet losses withoutlosing the multicasting functionality provided by thesenetworks.The RTP is designed to deliver various kinds of realtime data over packet networks that include non-guaranteed quality-of-service (QoS) networks. RTPaddresses the needs of real-time data transmission onlyand relies on other well established network protocolsfor other communications services such as routing,multiplexing and timing. This way, we don’t need to re-define these services, which are proven to besatisfactory in general, for each payload type.Additionally, RTP is based on the Application LevelFraming (ALF) and Integrated Layer Processing (ILP)[3][4] principles, which dictate using the properties ofthe payload in designing a data transmission system asmuch as possible. For example, if we know that thepayload is MPEG video, we should design ourpacketization scheme based on “slices” because they arethe smallest independently decodable data units forMPEG video. This approach provides a much moresuitable framework for MPEG-2 transmission overnetworks with high packet loss rates.The next section describes the services provided byRTP for MPEG transmission. Section 3 discussesspecific MPEG-2 payload types and their advantagesand disadvantages. Section 4 describes a system modelthat we used in our implementations. Section 5discusses the results from our early experiments.2. RTPThe services provided by the RTP include payload typeidentification, sequence numbering, time stamping anddelivery monitoring. RTP typically runs on top of UserDatagram Protocol (UDP) [5] to make use of itsmultiplexing and checksum services. This is in additionto the basic networking services provided by theunderlying IP layer. However, RTP may be used withother suitable underlying network or transportprotocols. Also, RTP supports data transfer to multipledestinations using multicast distribution if thisfunctionality is supported by the underlying network asin TCP/IP networks.