FMS流媒体服务器设置

FMS流媒体服务器设置

众所周知，Macromedia Flash Communication Server和Macromedia Flash Player组合为视频会议应用提供了令人激动人心的可行性。在硬件的选择和软件参数设置上面依然是很繁重的和不可思议的。开发人员时常需要处理声音同步，画面突然定格以及延迟问题。甚至是经验丰富的Macromedia Flash开发人员，开发一个高质量的以Flash技术为基础视频会议应用也成为一个挑战，因为要面对眼花缭乱的摄像设备，网络环境和软件设置。

然而，当今很多的Flash Communication Server应用中，客户需要使用Flash技术来创造出高质量的视频会议系统。2004年，在为客户们开发这一类项目期间，我们对宽带交互视频应用的性能优化方面作了重要的研究，我们的目标是，在视频质量与音频质量之间找到一个好的平衡，限制CPU和带宽的占用，以减少跳帧、延迟和声音不同步等问题。我们很高兴将我们的发现以白皮书的形式推荐给Flash开发员社区

在Flash Communication Server开发领域是被公认的专家级的领导性公司。我们世界级的团队创造了很多的方案将那些限制变成可能。嵌入式开发，实时多用户模拟，快速的原型开发和实时商务协作应用方面，都是我们专攻的领域。

很多运行在桌面电脑上的视频会议应用在CPU占用和带宽上都非常的消耗资源。为了得到一个优化的结果，需要在视频会议应用的视频音频质量和资源消耗上面发现一个平衡点，同时不会出现跳帧，停滞，或者音频不同步等现象

硬件选择上的捉襟见肘和不恰当的软件设置经常会造成不愉快的视频会议体验，而且那么多复杂的选项看上去创造出一个高质量的视频会议体验几乎是不可能的，即使是提供了最好的开发工具。这使客户和开发人员都很气馁，可以确信甚至是在当今的技术条件下，视频会议应用也很难达到不同人群对丰富的音频和栩栩如生的视频的要求

优化硬件设置和软件设置是明智的选择，但是也会造成下面三个结果，要么是一个小故障不断的应用，要么是一个根本无法使用的应用，和一个让人感动的满足客户期望的高质量应用。在开发视频会议应用过程中我们采用了Macromedia的技术，在，我们为客户的视频协作项目花费了大量的时间来决定最好的选择和设置。我们通过在Flash开发员社区做出的分享，希望能够帮助更多的高质量的视频应用在将来成为现实

尽管在使用Flash技术实现的视频会议应用中，Flash Communication Server扮演了至关重要的角色，但是它主要的是起到了视频会议中从一个客户端到另外一个客户端数据流的中继器的作用。在我们的测试环境中，我们注意到即使是相当一般的服务器硬件配置，例如只有一个2.8GHz的奔腾4 CPU和512M内存的系统，在专业版许可的限制下也能够容易的胜任视频会议的环境需要。

对于视频会议的限制，主要的问题存在于客户端，因为在客户端的电脑有大量要处理的工作。当发布一个流的时候，客户端机器必须采集视频和音频数据，进行编码，然后通过网络将数据发送到服务器上，所有的这些都是实时的。并且在很多的视频交互环境中，同一个客户端机器需要将其他参与者发布的流下载到本机，进行解码，然后通过屏幕和扬声器或者耳机呈现出来，所有的这些都是实时进行，或跟实时非常接近。因此我们将优化工作的焦点完全放在客户端电脑上面。

根据各种客户需求，对一个应用的作出硬件的配置和建议是开发人员应当具备的能力。然而，我们发现挑选对视频会议应用具有影响的硬件非常的复杂。即使你正在开发一个基于Web 的视频会议应用，这个应用不对客户端硬件作任何设置，这也可能将对发现一个最小化的配置需求有帮助，对期望的客户端电脑配置和网络设置方面也是有帮助的。

我们的目标是作出有效的硬件选择，即达到高质量的音频视频流效果，又使客户端的CPU 和网络负担降到最小。在测试期间，我们发现CPU的高负载和低性能有很大的关系，由于

CPU要同时支持视频交互和其他的应用，因此导致了CPU的频率变得分散。

维持合理的网络负载是第二个重要的考虑方面，特别是低带宽条件下的设置，因为可用的网络带宽直接限制着客户端和Flash Communication Server之间的大量的数据传输。

视频会议应用中Camera摄像设备扮演着基本的采集视频信号的角色。然而，视频信号通常在提供给Flash Player使用之前也需要消耗一些CPU的运算。安装在操作系统上的Camera 驱动程序也同等重要，因为如果驱动程序编写的很差，将会给CPU造成更大的负荷。

大多数视频会议应用中，Camera的分辨率大于640x480帧频率大于30fps都是不必要的。而且，能够在视频会议应用中使用的消费级的Camera都很少能够超过这些值。所以，我们测试的重点放在消费级的Camera设备，而非科研和工业级，故测试中的Camera的分辨率不大于640x480，帧频不大于30fps。

大多数用户视频会议的摄像设备会采用以下两种总线架构，即接口方式，一个是USB2.0；另一种是火线接口，像我们都知道的IEEE1394接口。火线接口设备分为两种，一种是DV设备，提供压缩数据给电脑；另外一种是IIDC/DCAM设备，提供未经压缩的数据给电脑，并且可以通过火线提供对硬件本身的控制操作。

我们的测试和一些可用的文档都表明，用于将Camera数据传递到电脑的不同的传输协议对CPU的需求都有着显著的不同。为了测定不同的Camera对CPU需求的数据，我们选取了三个有代表性的使用不同总线和协议的Camera在客户端的机器上进行测试，测试的时候进行一系列的分辨率和帧频率设置并取数据。

为了试验，我们使用了下面几种Camera：Apple [size=+0]iS[size=+0]ight,一种[size=+0]I[size=+0]IDC/DCAM自适应的有着400Mb[size=+0]it火线的Camera设备；Sony DCR-TRV460，一部也是有着400Mb[size=+0]it火线消费级的DV机；和一个Creat[size=+0]ive Labs NX Ultra，采用了高速USB接口。

这些设备的制造商都标明他们的设备有着最大实时640x480图像分辨率和最高30fps的帧频率，除了Creat[size=+0]ive NX Ultra camera说明最大帧频率为15fps。虽然DV机也支持USB 连接，但是我们在测试中只使用它的火线连接。图表1提供了一个简单的说明。

测试CPU占用是通过在本地电脑上的右眼观察，见下文。为了离析出运算视频信号和导入到Flash后的CPU需求，我们完全运行一个本地Flash程序来进行测试，Flash Player的版本是7.0.19.0，并没有使用Flash Commun[size=+0]icat[size=+0]ion Server来进行测试。

上面是分辨率和帧频的测试项目，CPU占用通过W[size=+0]indows自带的任务管理器进行测量，每一项测试任务运行大概30秒。

虽然可以通过Camera.setMode的方法设定Camera的分辨率和帧频率，但是不是所有的Camera都支持设定的参数值，我们可以通过Camera对象的w[size=+0]idth、he[size=+0]ight 和currentFps属性来读取Camera实际的帧频率。当设定的分辨率和帧频率无法实现的时候，Flash将会使用较低的分辨率和帧频率来获取视频数据。

在这个例子中，对于分辨率240x180的设置，Creat[size=+0]ive Labs NX Ultra并不支持，Flash 采用了更低一些的分辨率来进行替代获取图像数据，然后放大到240x180大小，所以产生了一些马赛克效果。Apple [size=+0]iS[size=+0]ight则能够支持这一分辨率，并产生了较好的图像。

测试中的Camera不是都支持相同的分辨率和帧频率。所以我们将分析的注意力放在被大多数Camera支持的参数上面，即使会获得一大组数据。分辨率160x120,320x240和640x480，帧频率从1到15fps得到了所有Camera的支持。帧频率到达30fps后，只有DCR-TRV460和Apple [size=+0]iS[size=+0]ight支持。可以参考图表中的详细的对比数据。

我们对帧频率也作了测试，在使用创新的Camera作为测试对象的时候，Camera.fps属性值