📄 rtpextending.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:13">
<title>Creating Custom Packetizers and Depacketizers </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="RTPExporting.html">PREV </a> |
<a href="JMFApp-Applet.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="98700"> </a><font size="3" face="Palatino, Times New Roman, Times, serif">12 <br></font>
</div>
<div align="right">
<h2>
<a name="99690"> </a><font color="#003366" face="Palatino, Times New Roman, Times, serif">Creating Custom Packetizers and Depacketizers </font>
</h2>
</div>
<p>
<a name="99005"> </a><font face="Palatino, Times New Roman, Times, serif">Note: <em>The RTP 1.0 API supported custom packetizers and depacketizers through RTP-specific APIs. These APIs have been replaced by the generic JMF plug-in API and any custom packetizers or depacketizers created for RTP 1.0 will need to be ported to the new architecture. </em></font>
</p>
<p>
<a name="98737"> </a><font face="Palatino, Times New Roman, Times, serif">RTP <em>packetizers</em> are responsible for taking entire video frames or multiple audio samples and distributing them into packets of a particular size that can be streamed over the underlying network. Video frames are divided into smaller chunks, while audio samples are typically grouped together. RTP <em>depacketizers </em>reverse the process and reconstruct complete video frames or extract individual audio samples from a stream of RTP packets.</font>
</p>
<p>
<a name="99165"> </a><font face="Palatino, Times New Roman, Times, serif">The RTP session manager itself does not perform any packetization or depacketization. These operations are performed by the <code>Processor</code> using specialized <code>Codec</code> plug-ins.</font>
</p>
<a name="99170"> </a><font size="1" face="Palatino, Times New Roman, Times, serif"> <img src="images/RTPExtending2.gif" height="204" width="483">
<br></font>
<a name="99709"> </a><font size="2" face="Palatino, Times New Roman, Times, serif">Figure 12-1: JMF RTP architecture.<br></font>
<p>
<a name="98909"> </a><font face="Palatino, Times New Roman, Times, serif">To determine what RTP packetizer and depacketizer plug-ins are available, you can query the <code>PlugInManager</code> by calling <code>getPlugInList(CODEC)</code>. The input and output formats of a particular plug-in can be determined through the <code>getSupportedInputFormats</code> and <code>getSupportedOutputFormats</code> methods.</font>
</p>
<p>
<a name="98833"> </a><font face="Palatino, Times New Roman, Times, serif">To receive or transmit any format not supported by one of the standard plug-ins, you need to implement a custom plug-in to perform the necessary conversions. The formats of the data streamed by the <code>DataSource</code> created by the session manager are well-defined to facilitate packetization and depacketization of the formatted data. </font>
</p>
<p>
<a name="99066"> </a><font face="Palatino, Times New Roman, Times, serif">For a custom plug-in to work, there must be either a standard or custom plug-in available that can handle the output format it generates. In some cases, if the necessary encoder or decoder is available, you might only need to write a packetizer or depacketizer. In other cases, you might need to provide both the encoder/decoder and packetizer/depacketizer. </font>
</p>
<p>
<a name="99224"> </a><font face="Palatino, Times New Roman, Times, serif">Custom packetizers and depacketizers can be combined with custom encoders and decoders, or you can implement independent packetizer and depacketizer plug-ins. For example, a depacketizer-only plug-in might advertise DVI_RTP as its input format and DVI as its output format.</font>
</p>
<a name="99434"> </a><font size="1" face="Palatino, Times New Roman, Times, serif"> <img src="images/RTPExtendinga.gif" height="293" width="580">
<br></font>
<a name="99206"> </a><font size="2" face="Palatino, Times New Roman, Times, serif">Figure 12-2: Data flow with a custom depacketizer plug-in.<br></font>
<p>
<a name="99726"> </a><font face="Palatino, Times New Roman, Times, serif">A combined depacketizer-decoder plug-in that decompressed DVI to linear audio would advertise DVI_RTP as its input format and AUDIO_LINEAR as its output format.</font>
</p>
<a name="99744"> </a><font size="1" face="Palatino, Times New Roman, Times, serif"><img src="images/RTPExtending3.gif" height="258" width="507">
<br></font>
<a name="99219"> </a><font size="2" face="Palatino, Times New Roman, Times, serif">Figure 12-3: Data flow with combined depacketizer/decoder plug-in.<br></font>
<h3>
<a name="99748"> </a><font color="#003366" face="Palatino, Times New Roman, Times, serif">RTP Data Handling<a href="#99212"><sup>1</sup></a></font>
</h3>
<p>
<a name="98194"> </a><font face="Palatino, Times New Roman, Times, serif">Data is transferred between the session manager and a <code>Player</code> or <code>Processor</code> using the <code>Buffer</code> object. Therefore, all <code>DataSources</code> created by the <code>Processor</code> with an RTP-specific format are buffer<code> DataSources</code>. Similarly, all <code>DataSources</code> created by the session manager and handed over to the <code>Manager</code> for <code>Player</code> creation are buffer<code> DataSources</code>. </font>
</p>
<p>
<a name="97872"> </a><font face="Palatino, Times New Roman, Times, serif">All RTP-specific data uses an RTP-specific format encoding as defined in the <code>AudioFormat</code> and <code>VideoFormat </code>classes. For example, gsm RTP encapsulated packets have the encoding set to <code>AudioFormat.GSM_RTP</code>, while jpeg-encoded video formats have the encoding set to<code> VideoFormat.JPEG_RTP</code>. </font>
</p>
<p>
<a name="98664"> </a><font face="Palatino, Times New Roman, Times, serif"><code>AudioFormat</code> defines four standard RTP-specific encoding strings:</font>
</p>
<pre>
<a name="98515"> </a>public static final String ULAW_RTP = "JAUDIO_G711_ULAW/rtp";
public static final String DVI_RTP = "dvi/rtp";
public static final String G723_RTP = "g723/rtp";
public static final String GSM_RTP = "gsm/rtp";
</pre>
<p>
<a name="98590"> </a><font face="Palatino, Times New Roman, Times, serif"><code>VideoFormat</code> defines three standard RTP-specific encoding strings:</font>
</p>
<pre>
<a name="98602"> </a>public static final String JPEG_RTP = "jpeg/rtp";
public static final String H261_RTP = "h261/rtp";
public static final String H263_RTP = "h263/rtp";
</pre>
<p>
<a name="98508"> </a><font face="Palatino, Times New Roman, Times, serif"><code>Buffers</code> that have an RTP-specific encoding might have a non-null header defined in <code>javax.media.rtp.RTPHeader</code>. Payload-specific headers are not part of the <code>RTPHeader</code>. Instead, payload headers are part of the data object in the <code>Buffers</code> transferred between the <code>Player</code> or <code>Processor</code> and the session manager. The packet's actual RTP header is also included as part of the <code>Buffer</code> object's data. The <code>Buffer </code>object's<code> </code><em>offset</em> points to the end of this header.</font>
</p>
<p>
<a name="99311"> </a><font face="Palatino, Times New Roman, Times, serif">For packets received from the network by the <code>SessionManager</code>, all available fields from the RTP Header (as defined in RFC 1890) are translated to appropriate fields in the <code>Buffer</code> object: timestamp and sequence number. The marker bit from the RTP header is sent over as flags on the <code>Buffer</code> object, which you can access by calling the<code> Buffer getFlags </code>method. The flag used to indicate the marker bit is <code>Buffer.FLAG_RTP_MARKER</code>. If there is an extension header, it is sent over in the header of be <code>Buffer</code>, which is a <code>RTPHeader</code> object. The format of the <code>Buffer</code> is set to <code>AudioFormat.GSM_RTP.</code> </font>
</p>
<p>
<a name="98278"> </a><font face="Palatino, Times New Roman, Times, serif">All source streams streamed out on RTP <code>DataSources</code> have their content descriptor set to an empty content descriptor of <code>"" </code>and their format set to the appropriate RTP-specific format and encoding. To be able to intercept or depacketize this data, plug-in codecs must advertise this format as one of their input formats.</font>
</p>
<p>
<a name="97783"> </a><font face="Palatino, Times New Roman, Times, serif">For packets being sent over the network, the <code>Processor's</code> format must be set to one of the RTP-specific formats (encodings). The plug-in codec must advertise this format as one of its supported output formats. All <code>Buffer</code> objects passed to the <code>SessionManager</code> through the <code>DataSource</code> sent to <code>createSendStream</code> must have an RTP-specific format. The header of the <code>Buffer</code> is as described in <code>javax.media.rtp.RTPHeader</code>.</font>
</p>
<h4>
<a name="97966"> </a><font color="#003366" face="Palatino, Times New Roman, Times, serif">Dynamic RTP Payloads</font>
</h4>
<p>
<a name="99147"> </a><font face="Palatino, Times New Roman, Times, serif">The <code>SessionManager</code> has a provision for entering information on dynamic RTP payloads. For more information about how dynamic payloads are used in RTP, refer to IETF RFC 1890, the RTP Audio-Video profile<a href="#99151"><sup>2</sup></a> that accompanies the RTP specification. </font>
</p>
<p>
<a name="98344"> </a><font face="Palatino, Times New Roman, Times, serif">The dynamic RTP-payload information typically contains a mapping from a predetermined RTP payload ID to a specific encoding. In the JMF RTP API, this information is passed via the <code>Format</code> object. To enable playback or transmission of dynamic RTP payloads, you must associate a specific <code>Format</code> with an RTP payload number. This information can be sent to the session manager in two ways:</font>
</p>
<ul>
<li><a name="98345"> </a><font face="Palatino, Times New Roman, Times, serif">Through the<code> RTPControl</code> <code>addFormat </code>method--every RTP <code>DataSource</code> exports an <code>RTPControl</code> that can be retrieved through the <code>DataSource</code> <code>getControl</code> method. A handle for the <code>DataSource</code> is typically obtained by calling the <code>Processor getDataOutput </code>method or the <code>Manager createDataSource(MediaLocator) </code>method. The <code>RTPControl's</code> <code>addFormat</code> method can be used to enter the encoding Information. See <code>javax.media.rtp.RTPControl </code>for more information.</font>
<li><a name="98408"> </a><font face="Palatino, Times New Roman, Times, serif">Through the <code>SessionManager addFormat</code> method--if you use the JMF RTP API but do not use the <code>Manager</code> to create players or send streams, the dynamic payload information can be entered using the <code>addFormat</code> method of the <code>SessionManager</code> interface. For playback, this must be done prior to calling <code>startSession</code> since the session manager must be configured with dynamic payload information before data arrives. For transmission, this must be done prior to calling <code>createSendStream</code> since the session manager must be configured with dynamic payload information before attempting to send data out.</font>
</ul>
<h3>
<a name="99078"> </a><font color="#003366" face="Palatino, Times New Roman, Times, serif">Registering Custom Packetizers and Depacketizers</font>
</h3>
<p>
<a name="99079"> </a><font face="Palatino, Times New Roman, Times, serif">Whenever custom packetizers or depacketizers are used, a new payload number must be associated with the RTP format in the session manager's registry. For RTP transmission, you need to call <code>addFormat</code> on the <code>SessionManager</code> to register new formats. For RTP reception, you can either:</font>
</p>
<ul>
<li><a name="99080"> </a><font face="Palatino, Times New Roman, Times, serif">Call <code>addFormat</code> on the <code>RTPControl</code> associated with the <code>DataSource</code>.</font>
<li><a name="99081"> </a><font face="Palatino, Times New Roman, Times, serif">Call <code>addFormat</code> on the <code>SessionManager</code>.</font>
</ul>
<a href="#99748"><sup>1</sup></a>
<a name="99212"> </a><font size="2" face="Palatino, Times New Roman, Times, serif">See the IETF RTP payload specifications for more information about how particular payloads are to be carried in RTP. <br></font>
<a href="#99147"><sup>2</sup></a>
<a name="99151"> </a><font size="2" face="Palatino, Times New Roman, Times, serif">This document is being revised in preparation for advancement from Proposed Standard to Draft standard. At the time of publication, the most recent draft was http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-new-06.txt. <br></font>
</blockquote>
<br clear="all">
<hr>
<a href="JMFTOC.html">CONTENTS</a> |
<a href="RTPExporting.html">PREV </a> |
<a href="JMFApp-Applet.html">NEXT</a> |
<a href="JMFIX.html">INDEX</a></td>
<br>
<hr>
<em>
<a href="copyright.html">Copyright</a> ©
1998-1999 Sun Microsystems, Inc. All Rights Reserved.
</em>
</body>
</html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -