JMF 的音视频聊天实现

java media framework  （JMF ）为java 在多媒体领域的开发提供了便利的平台。本文基于JMF 遵从RTP 协议对音/视频聊天进行了实现，解决了会话的管理和流媒体的发送、接收、播放等关键问题。

1.引言

如今VoIP  已经成为一种经济高效的通讯方式。不过只有语音方面的交互已经不能满足人们的需求。只闻其声不见其人显得过于单调。音/视频聊天在这种需求下应运而生。音/视频聊天的关键是实时性和同步。因此RTP（实时传输协议）就作为其底层传输协议的不二之选。

Sun公司所推出的java 凭借其面向对象、跨平台、安全、多线程等性能成为现今最流行的网络编程语言。Sun在java 的基础上针对多媒体的播放与传输开发了JMF。本文基于JMF对音/视频聊天进行实现。

2.   RTP与JMF

2. 1 RTP与RTCP

RTP 是由IETF  的AVT 工作组针对流媒体开发的协议，它位于传输层之上但并不要求 传输层协议使用UDP(用户数据报协议)，不过迄今为止UDP 是最常用的RTP 的底层协议。由于UDP 是面向无连接的不可靠协议，这使其更适于流媒体传输。UDP 作为轻量级的传输协议并不保证传输质量但实现了高效的盲目传输。QOS  由UDP  的上层协议RTP  实现。针对UDP 的无连接传输所导致的误码、丢失、乱序问题，RTP 规定了其组成。

RTP 包由两部分组成：包头和负载。包头中含有负载类型、序号、时间戳、同步源标识等。负载存储了包头指定的流媒体数据。

RTCP  （实时传输控制协议）为RTP 连接提供了QOS 信息并维持各个参与者的状态信息。RTCP 共有五个组成部分：RR （接收端报文）、SR （发送端报文）、SDES （信源描述）、 BYE（结束报文）和AS（应用程序特定）。

其中RR 是由RTP 包的接收端发给每一个参与者的接收反馈报文。报文中包含丢包数、所接受到RTP  包的最高序号以及用来估算发送端与接收端之间延迟的时间信息。这些信息可供参与者估计当前网络状况进行拥塞控制保证QOS。SR 是由RTP  发送端发给接收端。发送端报文包含发送端所发送的总包数与字节数以及时间同步信息。并把发往接收端的RR 内嵌其中。SDES  是为参与者定义的一个规范名。还有一些其它识别信息，如e－mail、电 话等信息。参与者依靠SSRC 与标准名的映射关系完整多媒体流的复用与解复用。BYE  作为一个参与者退出会话的结束报文，其中包含了自定义的退出原因。当一个参与者退出所在会话时，它将发送BYE 给会话中的所有参与者。AS 则为应用程序传送信息定义了一种方式。

RTP 有一个虚拟环境—— Session（会话），是由多个参与者所组成的联盟。每个参与者都设定一个RTP 端口和一个RTCP 端口。每当有参与者加入会话都会发出RTCP 报文通知会话中的其它参与者。一个参与者可加入多个会话，接收端根据参与者的规范名对参与者在不同会话中的媒体流进行同步。

RTCP 包是一个复合包，它至少含有两个包。一般第一个包为报文（SR 或RR），第二个包为源描述（SDES）。如果退出会话还要在SDES 包后面添加结束报文（BYE）。

2. 2 JMF

JMF对RTP协议进行了包装，为流媒体的传输及播放提供了简洁便利的应用程序接口。 JMF为会话管理、参与者、媒体流及RTP事件监听都设定了对应类。利用JMF进行流媒体的发送、接收、播放基本框架如图1所示。

图1 JMF 流媒体传输框架

JMF  针对 RTP   的媒体传输类型相当有限，只有一种内容描（ContentDescriptor ） RAW_RTP。JMF 所支持的RTP 负载类型也非常有限，如表1 所示 

                         表1 JMF 所支持的RTP 传输FORMAT

3．系统实现的关键问题

基于JMF 实现音/视频聊天的主要步骤如图2 示：

                         图2  基于JMF 实现音/视频聊天流程

3. 1 初始化RTP管理器（RTPManger）

为音/视频分别创建一个RTPManger。一般所有参与者选择一致的端口号，以便于管理。创建一个会话分为两步：初始化本地地址和添加目的地址。如果是组播IP 地址则本地与目的地址均设为组播IP  地址。在初始化RTPManager时，可通过BufferControl 来设置接收buffer，以提高播放质量。

RTPManager   mgr = (RTPManager) RTPManager.newInstance(); 
… 
mgr.initialize(localAddr); 
BufferControl bc = (BufferControl) mgr.getControl("javax.media.control.BufferControl"); 
… 
mgr.addTarget(destAddr);

3. 2 定位捕捉媒体源（MediaLocator）

在安装捕捉设备之后，利用JMF  自带的JMF   Registry 对捕捉设备进行检测和添加。查找捕捉设备有两种策略：通过设备名称或者通过设备所支持的Format。

如果能够确定捕捉设备名称可利用如下方法获得捕捉设备信息。
 CaptureDeviceInfo audioDevice =CaptureDeviceManager.getDevice("DirectSoundCapture");

如果不能确定捕捉设备名称可用如下方法返回所有可捕捉指定Format  的捕捉设备信息 向量。
Vector videoDevices = CaptureDeviceManager.getDeviceList(new VideoFormat(null)); 
在得到捕捉设备信息之后即可获得媒体源定位标示符。
 MediaLocator audioLocation = audioDevice.getLocator();

3. 3 根据MediaLocator创建处理器（Processor）

为音/视频媒体源标示各创建一个Processor，下面是创建音频Processor。
 audioProcessor =Manager.createProcessor(audioLocation);

3. 4 根据需要设定媒体输出格式（Format）

设定媒体输出格式时必须使Processor 进入Configured 状态，在进入Configured 之后才 能获得轨道控制。通过设定Processor 输出ContentDescriptor 之后，可以窄化轨道所支持的Format。然后从轨道所支持的Format 中选择恰当的Format 设定为此轨道的输出Format。 TrackControl[] tracks = audioProcessor.getTrackControls(); audioProcessor.setContentDescriptor(new ontentDescriptor(ContentDescriptor.RAW_RTP)); 
Format [] supported= tracks[i].getSupportedFormats(); 
tracks[i].setFormat(chosen);

在选择音频输出Format时，如果想设定为MPEGAUDIO_RTP,JMF 要求捕捉设备的采样频率与所支持FORMAT  的采样频率相同并且Endian 位设为BIG_ENDIAN。当选择其它Format  时没有此限制。而对于选择视频输出Format  时要注意分辨率的设置。H263_RTP 只支持三种分辨率：128*96、176*144、352*288。而JPEG_RTP  只支持长与宽均是8的整数倍的视频。MPEG_RTP  在分辨率方面不做要求。根据视频输入的分辨率选择恰当的输出分辨率，Processor 会自动进行转码,将分辨率调整到所选值。

3. 5 根据输出源确定发送流（SendStream）

从 Processor 获取输出源，根据输出源所包含的输出流来创建 SendStream 并开启              SendStream。通过设定index 来选择输出dataOutput，index=0 表示选择第一轨道作为发送流，依次类推。
DataSource dataOutput=AudioProcessor.getDataOutput();
SendStream sendStream = mgr.createSendStream(dataOutput, index); 
sendStream.start();

3. 6 注册监听器

     的监听器监听是否有新的particpant 加入会话，当有新particpant 发送媒体流过来时，触发事件得到媒体流的DataSource 用于创建播放器。 
mgr.addReceiveStreamListener(new ReceiveStreamListener(){ 
public synchronized void update(ReceiveStreamEvent evt) { 
… 
if (evt instanceof NewReceiveStreamEvent) { 
 ReceiveStream stream = ((NewReceiveStreamEvent) evt).getReceiveStream(); 
DataSource ds = stream.getDataSource();} 
…});

4．运行结果

如图3 所示为音/视频聊天界面，其中可设置视频与音频会话的IP 地址、端口号与生存时间。Add session 初始化RTPManager 加入了一个双方事先约定好的会话。Start receive 开始接收远端音/视频流媒体数据并播放。Start send 开始发送本地捕捉设备的流媒体数据。Stop session 停止发送和接收并退出会话。

                                图3  音/视频聊天用户界面

如图4、5 所示分别为视频和音频播放器，由于音/视频开始采集的时间不同所以播放器上所显示的播放时间不同，但通过RTCP 中SR 报文可使音/视频严格同步。

                                  图4  视频播放界面

                                  图5  音频播放界面

5．结论

本文实现了基于JMF的音/视频聊天系统,并解决了系统实现过程中的诸多关键问题。基于JMF的聊天系统能够很好地支持多媒体的同步播放，但对于流媒体的实时传输延时较大，这对于实时聊天是致命瓶颈。产生延时的方面很多如编解码延迟、复用解复用延迟、网络延迟等。其中网络延迟对于较好的网络非常小，其它的延迟原因主要是JMF的处理速度还有待于提高。期望在下一版本的JMF会改善时延问题。

本文转自 fanxiaojun 51CTO博客，原文链接：http://blog.51cto.com/2343338/439406，如需转载请自行联系原作者