📄 rtprealtime.html
字号:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<meta name="GENERATOR" content="Quadralay WebWorks Publisher 5.0.2">
<meta name="TEMPLATEBASE" content="Portable HTML">
<meta name="LASTUPDATED" content="11/23/99 11:48:08">
<title>Working with Real-Time Media Streams </title>
</head>
<body link="#3366CC" vlink="#9999CC" text="#000000" alink="#0000CC" bgcolor="#FFFFFF"
background="images/backgrnd.gif">
<table width="100%" border="0" align="left" cellpadding="0" cellspacing="0">
<tr>
<td><a href="JMFTOC.html">CONTENTS</a> |
<a href="Part2.html">PREV </a> |
<a href="RTPArchitecture.html">NEXT</a> |
<a href="JMFIX.html">INDEX</a></td>
<td align="right"><em>JMF 2.0 API Guide</em>
</tr>
</table>
<p><br clear="all">
</p>
<hr align="left">
<blockquote>
<div align="right">
<a name="997545"> </a><font size="3" face="Palatino, Times New Roman, Times, serif">7 <br></font>
</div>
<div align="right">
<h2>
<a name="998894"> </a><font color="#003366" face="Palatino, Times New Roman, Times, serif">Working with Real-Time Media Streams</font>
</h2>
</div>
<p>
<a name="998532"> </a><font face="Palatino, Times New Roman, Times, serif">To send or receive a live media broadcast or conduct a video conference over the Internet or Intranet, you need to be able to receive and transmit media streams in real-time. This chapter introduces streaming media concepts and describes the Real-time Transport Protocol JMF uses for receiving and transmitting media streams across the network.</font>
</p>
<h3>
<a name="998533"> </a><font color="#003366" face="Palatino, Times New Roman, Times, serif">Streaming Media</font>
</h3>
<p>
<a name="997721"> </a><font face="Palatino, Times New Roman, Times, serif">When media content is streamed to a client in real-time, the client can begin to play the stream without having to wait for the complete stream to download. In fact, the stream might not even have a predefined duration--downloading the entire stream before playing it would be impossible. The term <em>streaming media</em> is often used to refer to both this technique of delivering content over the network in real-time and the real-time media content that's delivered.</font>
</p>
<p>
<a name="997728"> </a><font face="Palatino, Times New Roman, Times, serif">Streaming media is everywhere you look on the web--live radio and television broadcasts and webcast concerts and events are being offered by a rapidly growing number of web portals, and it's now possible to conduct audio and video conferences over the Internet. By enabling the delivery of dynamic, interactive media content across the network, streaming media is changing the way people communicate and access information.</font>
</p>
<h4>
<a name="997631"> </a><font color="#003366" face="Palatino, Times New Roman, Times, serif">Protocols for Streaming Media</font>
</h4>
<p>
<a name="997746"> </a><font face="Palatino, Times New Roman, Times, serif">Transmitting media data across the net in real-time requires high network throughput. It's easier to compensate for lost data than to compensate for large delays in receiving the data. This is very different from accessing static data such as a file, where the most important thing is that all of the data arrive at its destination. Consequently, the protocols used for static data don't work well for streaming media.</font>
</p>
<p>
<a name="997764"> </a><font face="Palatino, Times New Roman, Times, serif">The HTTP and FTP protocols are based on the Transmission Control Protocol (TCP). TCP is a transport-layer protocol<a href="#997807"><sup>1</sup></a> designed for reliable data communications on low-bandwidth, high-error-rate networks. When a packet is lost or corrupted, it's retransmitted. The overhead of guaranteeing reliable data transfer slows the overall transmission rate.</font>
</p>
<p>
<a name="997771"> </a><font face="Palatino, Times New Roman, Times, serif">For this reason, underlying protocols other than TCP are typically used for streaming media. One that's commonly used is the User Datagram Protocol (UDP). UDP is an unreliable protocol; it does not guarantee that each packet will reach its destination. There's also no guarantee that the packets will arrive in the order that they were sent. The receiver has to be able to compensate for lost data, duplicate packets, and packets that arrive out of order. </font>
</p>
<p>
<a name="997986"> </a><font face="Palatino, Times New Roman, Times, serif">Like TCP, UDP is a general transport-layer protocol--a lower-level networking protocol on top of which more application-specific protocols are built. The Internet standard for transporting real-time data such as audio and video is the Real-Time Transport Protocol (RTP).</font>
</p>
<p>
<a name="997987"> </a><font face="Palatino, Times New Roman, Times, serif">RTP is defined in IETF RFC 1889, a product of the AVT working group of the Internet Engineering Task Force (IETF).</font>
</p>
<h3>
<a name="997973"> </a><font color="#003366" face="Palatino, Times New Roman, Times, serif">Real-Time Transport Protocol</font>
</h3>
<p>
<a name="997974"> </a><font face="Palatino, Times New Roman, Times, serif">RTP provides end-to-end network delivery services for the transmission of real-time data. RTP is network and transport-protocol independent, though it is often used over UDP.</font>
</p>
<a name="998002"> </a><font size="1" face="Palatino, Times New Roman, Times, serif"><img src="images/RTPRealTimea.gif" height="157" width="478">
<br></font>
<a name="998012"> </a><font size="2" face="Palatino, Times New Roman, Times, serif">Figure 7-1: RTP architecture.<br></font>
<p>
<a name="998901"> </a><font face="Palatino, Times New Roman, Times, serif">RTP can be used over both unicast and multicast network services. Over a <em>unicast</em> network service, separate copies of the data are sent from the source to each destination. Over a <em>multicast</em> network service, the data is sent from the source only once and the network is responsible for transmitting the data to multiple locations. Multicasting is more efficient for many multimedia applications, such as video conferences. The standard Internet Protocol (IP) supports multicasting. </font>
</p>
<h4>
<a name="997958"> </a><font color="#003366" face="Palatino, Times New Roman, Times, serif">RTP Services</font>
</h4>
<p>
<a name="998064"> </a><font face="Palatino, Times New Roman, Times, serif">RTP enables you to identify the type of data being transmitted, determine what order the packets of data should be presented in, and synchronize media streams from different sources. </font>
</p>
<p>
<a name="998131"> </a><font face="Palatino, Times New Roman, Times, serif">RTP data packets are not guaranteed to arrive in the order that they were sent--in fact, they're not guaranteed to arrive at all. It's up to the receiver to reconstruct the sender's packet sequence and detect lost packets using the information provided in the packet header. </font>
</p>
<p>
<a name="998114"> </a><font face="Palatino, Times New Roman, Times, serif">While RTP does not provide any mechanism to ensure timely delivery or provide other quality of service guarantees, it is augmented by a control protocol (RTCP) that enables you to monitor the quality of the data distribution. RTCP also provides control and identification mechanisms for RTP transmissions.</font>
</p>
<p>
<a name="998113"> </a><font face="Palatino, Times New Roman, Times, serif">If quality of service is essential for a particular application, RTP can be used over a resource reservation protocol that provides connection-oriented services.</font>
</p>
<h4>
<a name="998047"> </a><font color="#003366" face="Palatino, Times New Roman, Times, serif">RTP Architecture</font>
</h4>
<p>
<a name="998153"> </a><font face="Palatino, Times New Roman, Times, serif">An RTP <em>session</em> is an association among a set of applications communicating with RTP. A session is identified by a network address and a pair of ports. One port is used for the media data and the other is used for control (RTCP) data. </font>
</p>
<p>
<a name="998216"> </a><font face="Palatino, Times New Roman, Times, serif">A <em>participant</em> is a single machine, host, or user participating in the session. Participation in a session can consist of passive reception of data (receiver), active transmission of data (sender), or both. </font>
</p>
<p>
<a name="998146"> </a><font face="Palatino, Times New Roman, Times, serif">Each media type is transmitted in a different session. For example, if both audio and video are used in a conference, one session is used to transmit the audio data and a separate session is used to transmit the video data. This enables participants to choose which media types they want to receive--for example, someone who has a low-bandwidth network connection might only want to receive the audio portion of a conference.</font>
</p>
<h5>
<a name="998049"> </a><i><font color="#003366" face="Palatino, Times New Roman, Times, serif">Data Packets</font></i>
</h5>
<p>
<a name="998222"> </a><font face="Palatino, Times New Roman, Times, serif">The media data for a session is transmitted as a series of packets. A series of data packets that originate from a particular source is referred to as an <em>RTP stream</em>. Each RTP data packet in a stream contains two parts, a structured header and the actual data (the packet's <em>payload</em>). </font>
</p>
<a name="998453"> </a><font size="1" face="Palatino, Times New Roman, Times, serif"><img src="images/RTPRealTime2.gif" height="216" width="368">
<br></font>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -