JMF中可以实现RTP媒体流的回放(playback)和传输(transmission),主要由
javax.media.rtp
, javax.media.rtp.event
,和javax.media.rtp.rtcp
包中定义的API完成。JMF可以通过标准的JMF plug-in机制来实现支持特定的RTP格式和动态负载。
你可以在本地播放RTP数据流,或将其存储到本地文件。


整体流程图示:
1.
RTP
结构
1.1 SessionManager
在JMF架构中Session Manager对程序之间的会话进程进行控制和管理。Session Manager主要作用:
①明确每一个会话(session)中的所有参与者(participants)。
②管理每一个RTP会话。
③保存来自每一个发送或接收到的RTP和RTCP包中的统计信息。
JMF RTP Session结构图:

SessionManagr包含2个部分:Session Statistics和Session Streams。
1.1.1Session Statistics
统计量(Statistics)是记录基于每一条媒体流上的整个会话的统计信息。它包含:
①GobalReceptionStats:包含此会话的全局接收统计信息。
②GobalTransmissionStats:包含此会话的全局传输统计信息。
③RecetionStats:包含每一个参与者接收统计信息。
④TransmissionStats:包含每一个参与者的传输统计信息。
1.1.2Session Streams
①ReceiveStream:表示一个接收到的来自远端参与者的媒体流。
②SendStream:表示一个来自本地的媒体流。
1.2 RTP事件
如下图所示,通过继承JMF中MediaEvent的类,可以创建响应的RTP事件。

⑴SessionListener:通过它得到一个会话状态的改变。
①NewParticipantEvent:表示一个新的参与者加入会话。
②LocalCollisionEvent:表示参与者请求的同步资源正在使用。
⑵SendStreamListener:通过它得到一个正在传送的RTP数据流状态的改变。
①NewSendStreamEvent:表示本地参与者已经创建一个新的发送数据流。
②ActiveSendStreamEvent:表示从DataSource创建的数据流已经开始发送。
③InactiveSendStreamEvent:表示从本地DataSource创建的数据流已经停止。
④LocalPayloadChangeEvent:表示数据流格式已经开始改变。
⑤StreamClosedEvent:表示数据流已经停止。
⑶ReceiveStreamListener:通过它得到一个正在接收的RTP数据流状态的改变。
①NewReceiveStreamEvent:表示SessionManager已经创建了一个从新的侦测到的地址传来的接收数据流。
②ActiveReceiveStreamEvent: 表示数据的传送已经开始。
③InactiveReceiveStreamEvent:表示数据的传送已经停止。
④TimeoutEvent:表示数据传送超时。
⑤RemotePayloadChangeEvent:表示接收到的数据流格式已经改变。
⑥ApplicationEvent:表示收到了一个RTCP App数据包。
⑷RemoteListener:通过它得到远端会话参与者的时间或RTP控制信息。
①ReceiverReportEvent:表示接收到一个RTCP的RR包。
②SenderReportEvent:表示收到一个RTCP的SR包。
③RemoteCollisionEvent:表示两个远端的参与者使用了相同的SSRC 出错。
1.3
与RTP事件相对应的RTCP类型
表 RTCP的控制类型和JMF事件类的一致性
RTCP类型
|
JMF中的事件类
|
SR
| SendStreamEvent |
RR
| ReceiveStreamEvent |
SDES
| SenderReportEvent |
BYE
| ByeEvent |
APP
|
ApplicationEvent:
|
1.4
数据传输格式
在RTP传输中,如果还是用传统的AVI,MOV格式的话,将会增加服务器负荷,而且对网络要求特别高,因此需要将传统格式转化至易于传送,网络适应性好,抗丢包性能和抗误码性能好的编码格式。下表是JMF项目支持的视音频在RTP传送的压缩格式,也就是说经过定制后的输出视频流,还得进行一次转换,以便网络发送。
表 JMF支持的视音频在RTP传送中的格式
多媒体类别
|
RTP传输格式
|
音频
| JAUDIO_G711_ULAW/rtp,dvi/rtp ,g723/rtp ,gsm/rtp |
视频
| jpeg/rtp,h261/rtp,h263/rtp |
转化格式的关键代码及其分析(视频):
//从processor获得轨道控制器
TrackControl [] tracks = processor.getTrackControls();
//为每个轨道的格式进行转制
for (int i = 0; i < tracks.length; i++)
{
//此处省略获得轨道信息格式和支持格式代码
//下面一行为转制函数,需要参数为:轨道格式和轨道支持的格式
chosen = checkForVideoSizes(tracks[i].getFormat(), supported[0]);
//此处省略如果不能对轨道格式转变代码
}
//转制函数
/* 在传输视频信息时,对于JPEG编码格式,视频图像的宽和高是8像素的整数倍,对于
*H263编码格式,只支持三种图像的大小,即352X288,176X144,128X96像素,只要满
*足了这些条件,才可以正常传输视频信息,所以,需要对视频格式进行转制,
*不负荷条件的都需要转化,以满足正常传输。
*/
Format checkForVideoSizes(Format original, Format supported) {
int width, height;
Dimension size = ((VideoFormat)original).getSize();//获取视频图像的尺寸
Format jpegFmt = new Format(VideoFormat.JPEG_RTP);
Format h263Fmt = new Format(VideoFormat.H263_RTP);
if (supported.matches(jpegFmt)) {//如果是JPEG格式
//调整宽
width = (size.width % 8 == 0 ? size.width :(int)(size.width / 8) * 8);
//调整高
height = (size.height % 8 == 0 ? size.height :(int)(size.height / 8) * 8);
} else if (supported.matches(h263Fmt)) {//如果是H263格式
if (size.width < 128) {
width = 128;
height = 96;
} else if (size.width < 176) {
width = 176;
height = 144;
} else {
width = 352;
height = 288;
}
} else {
//对于其他格式不受理
return supported;
}
return (new VideoFormat(null,
new Dimension(width, height),
Format.NOT_SPECIFIED,
null,
Format.NOT_SPECIFIED)).intersects(supported);
|
2
.RTP媒体数据流的传输与接收
2.1 RTP
媒体数据流的传输过程

上图为Transmit的整个设计架构,Processor处理来自Capture Device的数据后,输入对方IP和Port,将数据传送到网络上等待接收端接收,其中音频的端口为视频的端口加2。
部分代码及分析:
①将转换格式后的数据放入一个DataSource
//获得转制后的DataSource
dataOutput = processor.getDa
|