OpenMeetings音视频参数设置及优化

OpenMeetins音视频参数

设置及优化

作者：老猫

日期：2010-9-17

一、前言

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做了哪些动作：

●捕获摄像头信号

●进行视频压缩编码

●创建一个基于RTMP协议的流与RED5建立连接

●将经过视频压缩编码后的数据按照RTMP协议进行信道编码

●将信道编码后的数据放入流中

我们可以发现，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与数据码流的关系，下面我们列出几个典型配置所需的带宽（经验值）：

●视频分辨率320*240，音频采用率44k，FPS30，带宽56KB+16KB

●视频分辨率240*180，音频采用率22k，FPS15，带宽32KB+10KB