一、前言
OpenMeetings是一个基于 Flash视频的视频会议系统，它的后台是基于开源的流媒体服务器 RED5做的二次开发，而前台实质上是一个采用 OpenLaszlo开发的 Flash。也就是说， OpenMeetings的客户端必须运行在 Flash环境下。因此，我们不妨把 PC机上的 Flash Player看作是一个 OS（操作系统），而把 OpenMeetings的前台（ swf文件）当作该操作系统下的一个可执行程序。这样的思路下，我们就可以理解，就如我们在 Windows下开发依赖于硬件的应用程序时必须要借助 WINDOWS API的支持一样， OpenMeetings的客户端也极度依赖 Flash环境所能提供的功能和性能，尤其是和音频视频相关的地方。
 

二、OpenMeetings流媒体采集和编码

Flash视频的客户端采集视频和音频信号后由 Flash插件完成音视频编码，编码算法是封闭的，据说采用的编码协议是 H.323（视频编码为 H.263），应用开发者无法优化这一块。
OpenMeetings调用摄像头时并创建一个广播流时，我们来看看 Flash做了哪些动作：
l         捕获摄像头信号
l         进行视频压缩编码
l         创建一个基于 RTMP协议的流与 RED5建立连接
l         将经过视频压缩编码后的数据按照 RTMP协议进行信道编码
l         将信道编码后的数据放入流中
 
我们可以发现， Flash自动帮我们完成了大部分的工作，所以开发基于 Flash的流媒体应用是一件相当轻松愉快的事情。然而，事物总是具备两面性的， Flash的封闭性使我们无从着手改进音视频的压缩编码算法，更谈不上改进 RTMP协议传输协议。能改善性能的地方都被牢牢地封闭在黑箱子里，就好比我们要参加汽车节油比赛时，却发现手里只有一辆纯自动档的汽车，让你空有一身车技却无用武之地时，郁闷更是无与伦比。
 

三、OpenMeetings公网上应用的带宽瓶颈

在国内，大多数家庭用户和中小型企业接入都采用 ADSL线路。我们知道， ADSL是一种不对称线路，即下行带宽大，而上行带宽很小，大约只占下行带宽的四分之一。 512K的 ADSL线路，上行带宽大约为 128Kbit，即不到 20KB的码流。
OpenMeetings默认用户视频设置参数为 30帧 /秒（ FPS）、分辨率为 320*240、质量为 90，要求稳定的上传带宽为 50KB左右，如果再加上 10Kb~20Kb的音频信号，就要求在 50KB~70KB的上行码流才能无损地向其它用户广播。
       Flash对于音频采集和编码的效率也很一般，采样速率为 22K时，其音频压缩编码后的码流速率一般为 10KB；采用默认采样率为 44K时，码流速率为 16KB左右。也就是说， 512K的 ADSL线路仅能保障较高质量的音频要求。
 
两者的差距巨大，因此，如果按照 OpenMeetings的默认设置部署在公网上，很多用户会感觉到别人的视频或音频非常卡，不流畅。其实这大多数情况不是你网络接收的问题，而是视频发布者的上行带宽不能适应系统的要求。我们知道，在网络上，流媒体数据一般是采用 UDP协议来传输的， UDP协议比 TCP的开销小，但更容易丢帧，其接受的数据包也不是顺序的，一旦由于带宽的问题导致客户端很长时间无法收全一个视频基帧数据，那么视频就会停顿，俗话叫卡死。
 
这样的性能在国内极其不稳定的网络条件下实在是差强人意，同时，前文也提到，我们无法去动它的编码算法，那么为了使 OpenMeetings能适应国内大多数的 512k adsl拨号上网线路，我们只能在音频视频的设置上下功夫，在保证音频和视频的质量勉强可以让人接受的前提下，来建立一个较为流畅的系统。
 

四、优化视频和音频参数以适应网络环境

OpenMeetings音视频信号采集和压缩编码相关的参数信号都可以在它的系统配置文件 config.xml中找到，其中音视频相关的部分如下：
   
   
30
   
16384   
   
49152
   
 
85    
      
90
   
22
   
44 
 
       framesPerSecond：视频信号每秒的帧数， FPS
       bandwidth：带宽要求（单路视频的带宽）
       camQuality：每个视频帧信号压缩后的质量，无压缩的视频质量为 100%
microphoneRate：麦克音频信号的采样率
 
       在 OpenMeetings中，我们必须根据用户的线路特点来设计默认的音频视频参数，才能使大多数用户能在一个相对流畅的条件下参与视频会议，前文已经大致介绍了视频分辨率、音频采用率、 FPS与数据码流的关系，下面我们列出几个典型配置所需的带宽（经验值）：
l         视频分辨率 320*240，音频采用率 44k， FPS30，带宽 56KB+16KB
l         视频分辨率 240*180，音频采用率 22k， FPS15，带宽 32KB+10KB
l         视频分辨率 160*120，音频采用率 22k， FPS5，带宽 16KB+10KB
 
如果我们采用的设置与实际线路的上行带宽不一致，会出现什么情况呢？我们分析的结果以及实际测试的结果是一致的，即延时会越来越长，直到超过了缓冲，然后直接出现大跨度的跳帧，然后又开始延时，周而复始。
 
       在做二次开发的时候，我们尝试着将默认的  FPS参数改为 5，并且在客户端让客户可以根据自己的线路状况调节。将默认的视频分辨率设置为 240*180，同时提供 320*240和 160*120高低两种选择；另外，将音频采样率默认为 22K，同时提供 44K和 11K两种选择。
 
经过这样的改造后，基本可以满足各种线路的接入带宽要求。即使最差的 512KADSL线路，选用最低的设置也能和其它线路的用户比较流畅地视频和音频交互。

五、OpenMeetings的延时和RED5缓存

       上一节提到， OpenMeetings的延时主要是音视频质量与带宽不匹配或者线路质量原因引起的。同时，它也和 RED5的缓存设置存在一定的联系。
我们知道， RED5缓存的设置有助于改善视频和音频质量，比如设置一定的接收缓存，可以将客户端上行的 UDP数据包更好地组装，最终使得转发的数据更完整。但缓存过大，在网络接入状态不稳定的时候，会使系统延时逐渐增加，最好因为不同客户端的同步原因而不得不丢弃部分数据，直接造成跳帧。
因此，我们的建议是，根据部署的环境及大部分用户的接入线路来设置 RED5的缓存。如果我们部署在较好的网络环境下，如局域网，或者用户的接入线路大部分都是光纤线路，我们可以设置比较小的缓存，以避免延时造成的困惑。而在线路状况不佳的情况、音频视频丢帧或失真比较严重，不妨设置比较大的缓存，以改善质量。
 
RED5的缓存参数设置文件： /red5/conf/red5. properties。红色字体部分时相关的缓存设置参数。
 
# RTMP
rtmp.host=0.0.0.0
rtmp.port=1935
rtmp.event_threads_core=16
rtmp.event_threads_max=64
# event threads queue: -1 unbounded, 0 direct (no queue), n bounded queue
rtmp.event_threads_queue=0 
rtmp.event_threads_keepalive=60
rtmp.send_buffer_size=200
rtmp.receive_buffer_size=200
rtmp.ping_interval=5000
rtmp.max_inactivity=60000
rtmp.tcp_nodelay=true
 

六、OpenMeetings对虚拟视频MvBox的支持问题

       Flash对虚拟视频 MvBox的支持有点 Bug，这个问题主要出现在 FireFox中，很容易引起整个 Flash的崩溃。经过多次试验，发现 Flash For FireFox的版本只有在视频分辨率设置宽高比为 4:3时才不会引起崩溃。
 

七、后记

与当前 C/S架构下的视频会议普遍采用 H.264或者 MPEG4编码的情况相比， Flash对 Webcam视频的编解码已大大落后了，从带宽和画质目前都无法和 C/S架构相比。当然，从发展的角度来讲， FMS和 RED5都已经相继开始支持 h.264编码， Adobe也推出了自己的支持 H.264的编码器可用于和 FMS或 RED5配合实现高质量的直播，看来在视频会议的 webcam采集和编码上将来也应该会支持 H.264，这将会给 OpenMeetings真正在公网上进入实用阶段打下坚实的基础，但愿这个将来不会太遥远。