(转载自闪客帝国）
[原文出处]
http://www.adobe.com/devnet/flashcom/articles/opt_videoconf.html
[简介]
www.architekture.com 来自新加坡，做过一些世界上著名的公司的案例。
有兴趣的朋友，可以看一下他们的官方网站。
他们经过大量的实验，从硬件到软件方面给出了具有参考价值的内容和数据。
[翻译]
在这里，仅将认为重要的内容翻译出来。
重要的内容，以黄色标记突出显示需要翻译的原文。
以蓝色的文字在原文旁追加中文翻译。
请参考www.vistaden.com相关栏目。
翻译水平有限，有错误遗漏之处，欢迎指正。
Email: dj@vistaden.com
[版权]
原文所有版权归原作者所有。
翻译内容，转载时请注明引用来源。
（以下开始正文）
众所周知，Macromedia Flash Communication Server和Macromedia Flash Player组合为视频会议应用提供了令人激动人心的可行性。在硬件的选择和软件参数设置上面依然是很繁重的和不可思议的。开发人员时常需要处理声音同步，画面突然定格以及延迟问题。甚至是经验丰富的Macromedia Flash开发人员，开发一个高质量的以Flash技术为基础视频会议应用也成为一个挑战，因为要面对眼花缭乱的摄像设备，网络环境和软件设置。
然而，当今很多的Flash Communication Server应用中，客户需要使用Flash技术来创造出高质量的视频会议系统。2004年，在为客户们开发这一类项目期间，我们对宽带交互视频应用的性能优化方面作了重要的研究，我们的目标是，在视频质量与音频质量之间找到一个好的平衡，限制CPU和带宽的占用，以减少跳帧、延迟和声音不同步等问题。我们很高兴将我们的发现以白皮书的形式推荐给Flash开发员社区
Architekture.com在Flash Communication Server开发领域是被公认的专家级的领导性公司。我们世界级的团队创造了很多的方案将那些限制变成可能。嵌入式开发，实时多用户模拟，快速的原型开发和实时商务协作应用方面，都是我们专攻的领域。
很多运行在桌面电脑上的视频会议应用在CPU占用和带宽上都非常的消耗资源。为了得到一个优化的结果，需要在视频会议应用的视频音频质量和资源消耗上面发现一个平衡点，同时不会出现跳帧，停滞，或者音频不同步等现象
硬件选择上的捉襟见肘和不恰当的软件设置经常会造成不愉快的视频会议体验，而且那么多复杂的选项看上去创造出一个高质量的视频会议体验几乎是不可能的，即使是提供了最好的开发工具。这使客户和开发人员都很气馁，可以确信甚至是在当今的技术条件下，视频会议应用也很难达到不同人群对丰富的音频和栩栩如生的视频的要求
优化硬件设置和软件设置是明智的选择，但是也会造成下面三个结果，要么是一个小故障不断的应用，要么是一个根本无法使用的应用，和一个让人感动的满足客户期望的高质量应用。在开发视频会议应用过程中我们采用了Macromedia的技术，在Architekture.com，我们为客户的视频协作项目花费了大量的时间来决定最好的选择和设置。我们通过在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 iSight,一种IIDC/DCAM自适应的有着400Mbit火线的Camera设备；Sony DCR-TRV460，一部也是有着400Mbit火线消费级的DV机；和一个Creative Labs NX Ultra，采用了高速USB接口。
这些设备的制造商都标明他们的设备有着最大实时640x480图像分辨率和最高30fps的帧频率，除了Creative NX Ultra camera说明最大帧频率为15fps。虽然DV机也支持USB连接，但是我们在测试中只使用它的火线连接。图表1提供了一个简单的说明。
测试CPU占用是通过在本地电脑上的右眼观察，见下文。为了离析出运算视频信号和导入到Flash后的CPU需求，我们完全运行一个本地Flash程序来进行测试，Flash Player的版本是7.0.19.0，并没有使用Flash Communication Server来进行测试。
上面是分辨率和帧频的测试项目，CPU占用通过Windows自带的任务管理器进行测量，每一项测试任务运行大概30秒。
虽然可以通过Camera.setMode的方法设定Camera的分辨率和帧频率，但是不是所有的Camera都支持设定的参数值，我们可以通过Camera对象的width、height和currentFps属性来读取Camera实际的帧频率。当设定的分辨率和帧频率无法实现的时候，Flash将会使用较低的分辨率和帧频率来获取视频数据。
在这个例子中，对于分辨率240x180的设置，Creative Labs NX Ultra并不支持，Flash采用了更低一些的分辨率来进行替代获取图像数据，然后放大到240x180大小，所以产生了一些马赛克效果。Apple iSight则能够支持这一分辨率，并产生了较好的图像。
测试中的Camera不是都支持相同的分辨率和帧频率。所以我们将分析的注意力放在被大多数Camera支持的参数上面，即使会获得一大组数据。分辨率160x120,320x240和640x480，帧频率从1到15fps得到了所有Camera的支持。帧频率到达30fps后，只有DCR-TRV460和Apple iSight支持。可以参考图表中的详细的对比数据。
我们对帧频率也作了测试，在使用创新的Camera作为测试对象的时候，Camera.fps属性值表明Flash可以成功的设定Camera以30fps的频率进行视频采集，但是Camera的说明书上表示最高支持15fps，他们猜想可能使驱动程序的问题或者是软件层的问题。
虽然Apple iSight官方说明并不支持在Windows系统使用，但是我们使用微软对1394接口的驱动后，能够达到最高15fps的频率。使用第三方Unibrain Fire-i IIDC/DCAM驱动程序的时候，就能够达到30fps的频率了。
另外需要注意的是，在测试期间，创新的Camera对CPU的占用会比较显著，我们怀疑是其他的USB设备在同时使用USB总线造成的，例如USB键盘和鼠标等等。
同样参数设置的情况下，使用Unibrain Fire-i作为驱动程序的Apple iSight Camera对CPU的占用大概只有其他两个Camera的一半，微软的驱动程序达不到这样的效果。
CPU占用方面，使用320X240分辨率的时候，sony的设备比创新的占用少一些。然后，使用640X480的时候，sony的占用是最多的。
和预期的一样，随着分辨率和帧频率的增加，CPU的占用越大。
从硬件的出发点，我们推荐使用IIDC/DCAM-compliant类型的Camera，因为未经压缩的数据流将会显著的减少对CPU的占用，这对配置较低，或者需要运行丰富界面，或者多人在线的视频会议应用有明显的好处。
图片2是实验结果，使用了各种分辨率，帧频率分别是15，24和30fps，CPU占用越低越好。这里要注意的是，除了160x120,320x240和640x480以外，其他的分辨率对于不同的硬件之间是没有直接可比性的。
在视频会议应用中，麦克风的回声和背景噪音是一个常见的问题，这是我们不希望出现的。虽然Flash提供了软件的方法来消除回声，我们仍然发现通过选择恰当的麦克风硬件，可以达到好的回声和噪音消除效果。我们需要让视频会议达到一个好的效果。
我们通过对不同的硬件进行试验，实验对象有传统的头戴式耳麦、USB接口头戴式耳麦和独立麦克风与扬声器的组合，我们发现，USB接口的头戴式耳麦效果最好。
其他的音频方面的改进，稍候我们将从软件方面讨论。
我们的网络会议应用，面向的是高带宽的企业内部网。所以，我们测试的环境是100M带宽的以太网。在我们的实验中，有5个实际的参与者来模拟出10人在线的会议，我们没有发现任何的网络问题。在局域网的环境里面，一个100M的网络设置能够完全满足视频会议的需求。我们没有测试其他类似802.11的网络环境，但是结果应该与我们试验的结果相似。
即使是几个与会者同时采用320x240的高分辨率，在高带宽的以太网内实现高质量的实时视频会议是可能的。而且，带宽占用可以维持在一个合理的低水平，例如每个流每秒钟38,400 bytes，通过明智的视频参数设置，将不会产生显著的视频质量的丢失，稍候我们将作详细描述。
对于低带宽的情况，例如通过Internet，可利用的带宽比局域网将显著的降低，并且延迟将会明显增加。当我们开发面向Internet应用的时候就会面对这些问题。不过，他们可以将带宽占用最小化和允许一些延迟。
需要注意的是在很多的视频会议中，带宽的需求随着与会者的数量成指数级增长。当在伸缩性上考虑了网络限制之后，我们将更深一步的讨论这个问题。在带宽局限上这是一个特别的例子，但是当处理与会者数量增加的交互的视频会议应用时，这也是重要的考虑因素。
我们针对使用Flash Player 7作为播放器的是视频会议应用作了大量的软件设置实验，并且在这一章节以文档的形式给出了我们的报告。特别要说的是，在实验过程中我们发现，很多的小故障都可以通过改变客户端通讯对象的设置来解决。我们也回顾了在建设视频会议应用中遇到的其他有趣的问题。
在Flash Player内，主要的操作Camera对象的方法有setMode(),setQuality()和setKeyFrameInterval()。由于Camera对象用于产生大量的数据，并在Flash Communication Server之间传递，所以它的设置将对视频质量和整体的视频会议体验有着重要的影响。
我们将依次考虑每一个方法，讨论可能的选项和我们的观测结果、测试结果，以及我们对视频会议应用的推荐设置。
Camera.setMode()方法可以给采集的视频数据制定期望的分辨率和帧频率。当然，只有某些分辨率和帧频率对相应的摄像设备是有效的。如果指定的参数摄像设备不支持，Flash Player将会指定一个相近的设置参数给硬件。采集参数将更改到默认的数值，但是采集选项能够通过favorSize标示进行设置。当设置的参数不能够被支持的时候，我们将能够看到如图1种那样的像素失真，即马赛克的效果。
从经验中得知，分辨率为160 x 120和320 x 240是比较好的，因为这样在视频会议应用中能够被大多数的摄像设备支持，并且能够很好的进行编码。通过编程对只读属性width,height和currentFps的读取，我们可以精确的检测出指定的分辨率和帧频率是否被摄像设备采用。
在没有网络传输的情况下，从我们的测试情况得知，分辨率和帧频率越低CPU的占用也越小。所以，我们推荐尽可能的在应用中使用低的参数设置。对于宽带企业内部网的应用，我们发现分辨率320x240和帧频率24fps将能够很好的适应5人同时在线的应用。如果是通过互联网，相关的参数设置则需要相应的降低。
Camera.setQuality() 允许指定视频流最大的上传带宽和采集的视频质量。缺省的参数值分别为16384和0。这两个参数允许根据需要设定不同的数值。
任何一个参数设置为0，Flash Player将自使用尽可能多的带宽资源来维持指定的视频质量，或避免过度的使用带宽而压制视频质量。视频质量也可以设置成100以使用无损压缩格式。所以，精确的带宽限制和视频质量参数的指定是同等重要的。
我们不能测定在各种参数设定下CPU利用率的显著区别。然而，我们的经验显示那些在某些限制下必须牺牲质量或者带宽的边缘案例对CPU的利用有着显著的区别。这里我们仅将注意力放在高带宽的企业内部网方面。
在那些指定高带宽和帧频率的案例中，我们发现带宽限制在每秒400,00和900,00字节，帧频率在60到85之间，将会得到一个不错的结果，平滑的视频并且没有声音不同步的问题。
和预期的一样帧质量越低产生的视频失真就越严重。然而，低带宽的限制就会产生跳帧，这和camera对象的文档描述的一样。
我们也注意到在一些案例里面，当我们选择了一个高带宽参数后，实际的上传带宽使用总是接近设定的带宽最大值，却不会超过这个值。例如，我们观察到在分辨率为320x240帧频为24fps的应用中，带宽很少超过每秒250,000字节，尽管我们设定一个较高的值。
当把帧质量和带宽的使用设置交给Flash来控制，我们做了一系列的实验来检测精确的带宽使用和观测到的视频质量，这些是在模拟视频会议的条件下使用了各种帧质量设置，发布视频和自己播放同这一个视频流，设置方面我们被推荐参考了来自Giacomo "Peldi" Guilizzoni 的博客的相关内容。
图表4显示了我们获得的每一种帧质量设置产生的结果。输出的每秒带宽占用和CPU占用试验时间平均超过30秒，模拟视频会议间隔的音频输入和相关的少量的镜头图像移动。
Table 4: Variable Frame Quality Results
Frame Quality Bandwidth/Sec. CPU Util. (%) Subjective Findings
100 250,000 33 Excellent picture, marked frame skipping
90 68,000 29 Excellent picture, some frame skipping
80 36,000 30 Excellent picture, occasional frame skipping
70 24,000 Not Measured Faint pixelization, smooth playback
60 19,000 Not Measured Mild pixelization, smooth playback
50 13,000 Not Measured Medium pixelization, smooth playback
40 11,000 Not Measured Loss of fine detail, smooth playback
30 10,000 Not Measured Moderate loss of detail, smooth playback
20 9,000 Not Measured Severe loss of detail, smooth playback
10 8,000 27 Loss of gross detail, smooth playback
随着帧质量的减少，CPU的占用也在慢慢的下降。高的帧质量产生很好质量的图像，但是会有跳帧的现象。反之，低的帧质量将会产生很顺畅的播放效果。最佳的位置是，帧质量在70到80之间的时候。
一个有趣的现象，当帧质量设置为100的时候，这时候采用的是无压缩的编码造成了很大的带宽消耗，但是CPU占用仅仅比低质量的帧设置高一点。
使用类似的设置将帧质量设定为80，然后指定各种带宽，我们重复了实验，获得的数据如下图表5。
Table 5: Variable Bandwidth Results
Sp ec. Bandwidth CPU Use (%) Subjective Findings
19,200 30 Smooth, significant pixelization upon movement
38,400 Not Measured Smooth, some pixelization upon movement
51,200 Not Measured Occasional frame skips, pixelization on gross movement
76,800 Not Measured Frequent frame skips, pixelization with extreme movement
128,000 Not Measured Frequent frame skips, high-quality picture
192,000 Not Measured Frequent frame skips, high-quality picture
256,000 Not Measured Very frequent frame skips, high-quality picture
384,000 30 Constant frame skip, high-quality picture
这里，选择的平衡似乎应当偏向于流畅的视频胜过像素失真方面。如果视频图像一直是静止的，那么在指定的带宽范围内将会产生高质量的图像。然而，这又有一点不切实际，在大多数的视频会议中，人们总会有一定的动作产生。最佳的位置是，帧质量设置为80，带宽设置为每秒38,400到 51,200字节，然而如果你在一个视频会议应用中不太介意偶尔的像素失真，每秒38,400字节是十分合适的。
在需要的情况下允许Flash来调节帧质量有着很大的好处，在不出现明显的图像损失的情况下可以将带宽的占用维持在一个比较低的水平上。这一点对于低带宽的互联网应用，以及对于有着庞大参与者数量的企业内部网应用，都是特别的重要。这也是我们首选的设置，相对于不可预知的频繁的跳帧来说瞬间的像素失真是可以接受的。
但是，通过实验每一个应用在不同带宽和帧质量的设置下有着不同的好处用处，这些要根据不同的需求和参数选择。另外，Guilizzoni提供了一个更方便的计算方法，用来选择不同的设置参数。
关键帧间隔指定了多久在视频流内发布一个不压缩关键帧，和通过编码产生的帧相反。Flash允许的值是从1到48，缺省的值是15，即每第十五个帧是一个关键帧。通过详细的测试表明，参数值越低越会造成调帧的现象，也会增加额外的带宽，尽管过大的值设置能减少跳帧，但是使视频正常化的时间加长，因为这些案例中帧质量会受到限制以响应图像动作的变化。对于需要高质量视频的应用，我们特别的将帧间隔参数设置值大于等于我们的帧频率，因为我们感觉到这样虽然产生偶尔的低质量的帧，但总好过于频繁的跳帧。
Flash里面有几处地方可以设定麦克风对象。特定的有，rate采样率，gain增益值，silence level检测音量和超时时间，以及是否使用音频编码来压制回声。这些设置对发布到Flash Communication Server的声音的采集和编码都产生影响。
这个方法指定麦克风采集声音的采样频率，单位是KHz，千赫。Flash允许设定的值是5，8，11，22和44KHz，在大多数案例中缺省为8KHz。一般而言，采样率越高音质越接近自然，带宽占用也越高。我们通常使用22或者44KHz来达到高质量的声音效果，因为没有注意到使用了低采样率会给性能带来什么提高。
麦克风的增益gain是对声音输入的一个增压倍数，很类似音量调节按钮的原理，值设定为0表示麦克风会不停的检测，缺省的50表示对输入的声音不进行改变，超过50的值应当在100以内。这个参数设置配合silence level一同使用，silence level是用来设定一个界限值，用于激活麦克风数据采集动作。
作为可选，Microphone.setSilenceLevel()方法也能设定一个秒值来指定静音的超时时间，即timeout，这个值以毫秒为单位，译者注：该参数指定必须经过多少毫秒的不活动时间，Flash才能认为声音已停止并调用Microphone.onActivity(false)。
我们发现经常会遇到一个问题，就是无法恰到好处的设置silence的值，在一些案例中，最佳的位置是设置silence level值为一个个位数，太低的值会造成不断的采集噪音，太高的值会无法在视频会议中精确的激活音频采集动作。
适当的gain和silence level参数选择，看上去在不同的电脑和麦克风配置之间是不同的，我们不能对实验以外的具体的硬件给出详细的参数值。然而，我们推荐在每一个案例程序里面设置一个指示灯，用于向用户显示他正在广播的音频信号状态。经常我们能在一个视频应用案例里面看到参与者痛苦的脸贴在屏幕上，却不知道麦克风也没有运作了。
如果在一个应用里面放置一个按钮用于点击之后便能够发言，也就是说需要响应很低的麦克风音量输入，那么将gian的值设置成0即可。然而，我们没有发现将gain值设置到100有什么效果，应为需要非常大声说话才能将麦克风的活动水平提高到100从而超过这个界限。
Flash允许通过Actionscript来可选择的利用音频编码来抑制回声。虽然我们已经通过硬件的选择有效的减少了回声，例如选择带有降噪功能的USB耳麦或者分开独立的麦克风和扬声器设备，但是我们依然使用这个方法获得好的效果。这个方法可以在噪音影响Flash之前将它们很好的过滤掉，使silenceLevel设置更加正确。
NetStream对象允许在发布端和播放端设置缓冲时间，但是却有着不同的效果。如果在发布端，它指定了数据上传的最大缓冲值，如果缓冲满了将会导致丢失帧。Macromedia的文档陈述说在高带宽的连接下这个不存在问题，我们的案例证明了这个结论。在播放端，缓冲时间表示在播放前的缓冲数据量。我们将这两个值都设置成0，在我们的视频会议应用中获得了很好的结果。
我的经验表明，内置视频对象的大小当与视频流的分辨率大小一致的时候，对CPU造成的负担最小。在实验中，无论将视频对象大小设置的大于或者小于视频流分辨率大小的时候，我们测量到CPU的占用都是增加了。假设发布端的电脑上Camera的分辨率设置很容易改动，我们建议在播放端的视频对象的大小要跟视频流的分辨率大小一致。在播放端可以利用编程的方法确定视频流的分辨率大小。
为了控制播放的流的声音，一个开发人员会使用MovieClip.attachAudio()的方法通过一个MovieClip来控制，就象帮助文档写的那样。然而我们的经验告诉我们当这个方法提供了声音控制的同时，也产生了不太好的声音不同步的趋势。我们还没有发现一个有效的解决方法，所以我们建议不要在视频会议中使用这个方法。
在视频会议环境中反应时间会是一个重要的问题，他会在发布端电脑和播放端的电脑上面造成延时。由于没有自带检测延迟的方法，我们通过使用NetStream.send()方法在发布端广播出一条消息，然后再自己从初始化开始播放这个流并测定时间。当时用这个方法测量反应时间的时候，我们所有的测量结果迄今为止和视频反应时间是一致的。因此，我们将这种反应时间作为视频反应时间来解释。
在研究的过程中，我们注意到在实时播放的流上面，当完全没有音频的时候反应时间在50毫秒以下。然而在播放回放的音频流的时候，反应时间将会快速的增长到几百毫秒，并且很少恢复到之前的反应时间，即使是音频数据结束之后。我们也观测了一些持续音频的例子，例如由于silence level被设置的很低导致了麦克风一直在工作，测量到的反应时间慢慢的持续增长。
虽然在很多例子中反应时间在200到400毫秒的水平，这是我们能够接收到的，但是反应时间有时候会增长到好几秒钟，从而造成了很低质量的视频会议体验。虽然我们能够关闭正在播放的流然后重新播放来达到将反应时间恢复到低水平，但是这不是一个好的方法，因为重新的连接会打断视频和音频几秒钟的时间。到现在为止，我们还没有发现一个有效的方法将反应时间限制在一个可接受的程度。
值得注意的是，我们还没有发现一个好的解决方法来自动测量音频反应时间，除了使用一个可疑的硬件解决方法，例如将扬声器的接口插到麦克风的接口处，然后来监测音频的活跃水平,之外我们对测量音频反应时间没有什么办法。一个能够自动测定音频的方法将是非常有用的，因为这样我们就可以解决音频同步的问题了。
虽然创建出两个人用的高质量的视频会议是容易的，随着网络和电脑的飞速增长，对应用的需求要适应更多人同时使用。特别的是，支持多人对多人的网络会议的带宽是以指数增加的，例如n个人同时参加的时候流的个数就是n的2次方。如果你希望了解更多关于带宽使用的信息，可以参考Brian Hock的Macromedia白皮书，名字叫做Calculating Your Bandwidth and Software License Needs for the Macromedia Flash Communication Server MX。另外，每一个客户端将消耗额外的资源用于对播放的流进行解码。
在一个视频会议应用中需要同时支持的参与者的数量由下面几个因素，FCS Server，网络结构支持的带宽和客户端电脑的性能。
Flash Communication Server每一个许可证允许每秒钟10Mbit或2500个并发连接，所以随着视频会议的参与者人数的增长而需要扩展Flash Communication Server的时候，适合的许可证数量是我们主要考虑的事项。
对于视频会议应用来说，在达到2500并发连接之前，每秒10Mbit的峰值带宽就会到达限制。对于流的数量是没有什么限制的，只是针对峰值带宽和并发连接数。
单个专业版的许可证提供了每秒10Mbit，或者可以换算成每秒1.19M字节的可用带宽。举例说明，让我们假设一个典型的高带宽视频会议，视频流最大的带宽是每秒38,400byts，音频采样频率是44KHz。用实验的方法，这大概占用了每秒50K字节的带宽。
使用每秒50K Bytes的带宽占用作为我们评估的数据，对于不断增加的使用者，我们能够计算出流的总数和估算的最大的每秒带宽利用。见图表6。
Table 6: Example Bandwidth Calculations for n Participants
Participants Total Streams Max. Bandwidth (Bytes per Sec.)
2 4 200,000
3 9 450,000
4 16 800,000
5 25 1,250,000
6 36 1,800,000
7 49 2,450,000
8 64 3,200,000
9 81 4,050,000
10 100 5,000,000
当然，这些数字只是一个大概德估算并且在多人数的值那边存在一些误差，因为我们计算的时候是假设这些流同时达到了最大的带宽峰值。然而，我们可以使用这些数据来估算Flash Communication Server带宽的负荷。
做一个初步的假设，当有4到5个参与者的时候，一个专业版的许可证将很有可能达到饱和。为了增加更多的用户，Flash Communication Server的最大带宽限制将需要增加，这样就需要从Macromedia那里购买添加更多的许可证或者购买更高增容许可证。
实际上，精确的带宽使用取决于设置和应用被褥和使用。就象随着参与者人数的增加客户端分辨率设置也应当减小一些，所以我们推荐一个策略，那就是随着参与者的增加要减少每个流对带宽的占用，可以通过降低流的分辨率和帧频率、视频带宽参数或者帧质量来达到这个目的。
甚至是使用了一个无限增容的许可证，服务器的硬件，操作系统和CPU性能都最终会对视频会议的应用带来瓶颈。
我们将研究的焦过多地放在了拥有高带宽环境的企业内部网。然而视频会议应用应当对带宽
的限制考虑全面一些，特别是那些需要经过互联网的环境。同样的，当比较Flash Communication Server报告的带宽使用和实际物理带宽使用上，实际的带宽会高一些，例如大报数据，中转数据包和消息控制上。
以我们的经验，视频会议在企业内部网的设置下运行的很好。然而在繁忙的本地网络环境下，你还要为那些非视频会议的应用作考虑，例如Email、网页浏览和文件传输等，他们也需要一定的带宽。依据本地的流量和网络架构，你可能会遇到比预想重要糟糕的低带宽和低质量的服务。
虽然我们在100Mbit以太网联接环境下的视频会议应用还没有遇到由于网络的原因造成的问题，我们仍然建议对应用将要运行的环境进行测试来确保运行正常。
当视频应用被引入到互联网环境的时候，其他的因素将会开始起作用。首先是更高的延迟，和比在本地网络运行时更低的带宽，甚至是用户使用了宽带连接。而且用户们可能有着不同的上传下载容量。这些限制对传递给每一个客户端的流的分辨率以及质量造成了约束。Guilizzoni and Hock向大家推荐，基于互联网应用的会议系统有必要降低采集视频的分辨率、带宽参数和视频质量。
客户端电脑上面需要考虑的首要问题是，随着参与者人数的增加电脑需要对流进行的解码并显示。在合理的带宽和质量设置情况下，我们模拟进行了一个客户端播放10个实时视频的测试，结果是这样做没有明显的问题。在我们测试用的电脑上使用的设置在对10个流解码播放时产生了比较可接受的顺畅播放的性能。具体的设置参考图表7。
Table 7: Recommended 10-Participant Settings
Bandwidth: 38400
FPS: 15
Favor Size: 0
Frame Quality: 0
Key Frame Interval: 30
Camera Width: 160
Camera Height: 120
Buffer Time: 0
Audio Rate: 22 MHz
按照图表7的设置，平均的CPU占用仅在36%，表明10个参与者的高质量视频会议应用在当前的系统配置下使用Macromedia Flash 技术是可行的。我们也进行了其他参数设置的测试，发现这套参数是最好的选择。
我们想确定一个对于CPU的占用有效的流分辨率，和确定不同数量的参与者情况下优化的分辨率。使用匹配的流分辨率来发布和播放，我们在测试的电脑上测量到平均的CPU占用是60%到90%，模拟出的视频会议的4、6和8个流，测试使用了比例为4:3的各种分辨率。参考图表8
图片里面的X轴的表示方式有点奇怪，这里解释一下，是使用了流的分辨率面积作为单位。举例说明，一个视频分辨率
是320x240，那么产生的面积就是76.8K像素，即320x240=76,800。将面积转换成宽x高的方式可以这么做，将面积除以12获得一个基数，即根，然后按照4x3的比例分别乘以这个基数，4乘以基数等于宽，3乘以基数等于高。使用面积整数是为了对不同的分辨率有一个直观的对比。具体的数据清参考附录B。
大多数在视频会议应用中使用到的Camera都支持分辨率160x120和320x240，为了方便阅读我们也在图片中进行了标注。
目前，我们对Flash压缩视频的编码算法产生怀疑，因为随着分辨率设置真实而显著的变化CPU占用却保持的相当稳定。但是我们没有足够的信息来最后的确定是否是这样。
