前面的不少博文都给大家、我自己带来了不少的压力，今天我们来看点轻松的东西，让我们兴奋、让我们愿意去do it的内容。那到底是什么？就是一点轻松的内容，Lync Server 2013在视频带宽上的巨大改进，这是不可磨灭的，因为当你使用Lync Server 2013和Lync Server 2010同样进行视频聊天、视频会议时，你会发现同样的服务器、同样的拓扑、同样的带宽环境，Lync Server 2013为什么可以做的这么好？
下面我们就先来看答案，相比奋斗N年为高考盼成绩，我们先来看成绩再去做，似乎确实要轻松些吧。
这篇文章和之前一篇写Lync Server 2010所需媒体流量带宽详解和计算是相关联的，如果不了解可以先看下：
好了下面我们就开始来关注新的带宽计算和参数。
我希望今天的内容尽可能的简单一点，少点字，可是这似乎比部署Lync还要复杂，因为真的想说的太多。但我们还是起一个简单的头，先来看看音频带宽需求，参考下表：
音频带宽需求
需要注意的是这里均是bit而非Byte，这里最耀眼的无非是G. 722 Stereo，因为它是绿色的。开个玩笑，可能有朋友对G. 722 Stereo这种音频编码不太熟悉，这是一种较为先进的视频会议音频编码，这种编码每秒钟将采集16000个样本，也就是16KHz，转换到比特率就是64K，而带Stereo可以同时捕捉两个声道，即立体声。所以我们在进行会议，并且使用更高级、更先进的音频硬件时我们可以获得更好的语音质量，这种优势在多人视频会议中尤显重要。然而我们来看音频负载本身这个参数也是没有意义的，因为我们还需要一个协议来将我们的内容实时的传输到其他的会议端，Lync Server使用SRTP协议来封装 音频流进行传输，SRTP是Lync Server传输的标准，全称为加密的实时传输协议，我们必须知道Lync无论在视频还是音频方面均是全加密的。
虽然我们不是那种可以听出火电、水电、风电、核电的金耳朵，但好的通话质量与差的通话质量我们还是能够分清，所以当进行多人视频时，我们可以立体声的采集，从而获得更加精确的音频，这还是让人值得do it的。
说的语音质量，可能很多朋友与我一样想去关注Lync Server是如何去纠正音频传输过程中在链路上发生的错误，其实这并不是什么先进的技术了，而之所以先进是即保证了无错、又没有消耗过高的带宽成本，这才是我们在流量、带宽上所关心的问题。Lync使用FEC来保证音频在传输过程中是被控制、无错的，但FEC并非一直在消耗流量，而是仅当音频数据在链路上传输时发生了错误，FEC才会进行纠错。所以FEC消耗的流量并非是一个固定值，而是根据线路质量、数据耗损、距离来定的，而这些值往往都是不可控的，然而消耗这部门流量去做这件事，是非常有意义的。
OK，下面我们来看下视频带宽方面的变化，视频带宽变化就比较大了，首先是支持的分辨率标准更多，这是大家看到下表最直观的，其次是看到表中有不少H.264字样，这也不是什么新鲜的东西了，但在Lync Server中还是比较新鲜的，我们来看看最大与最小值就知道了。
*注意，下表中的数据已经包含了视频纠错FEC所需要的带宽。
视频带宽需求
这里仍然是小b，但我们还是蛮喜欢拿小b来衡量视频会议的能耐的。比如我们经常说我们的带宽是多少多少兆，而不是说多少多少KB/s，因为这样确实可以快速比较，我们都懂这是什么意思，比如Lync Server 2013要进行1080P的点对点视频，占用的最大带宽只有4兆。其实通过上表已经能够非常好的诠释Lync Server 2013在带宽上的改善，我们可以看到Lync Server 2013在伸缩性上非常好，这使得我们在网络环境较好的时候能够获得更好的视频会议效果，而在网络环境较差的时候进行自行适应，从而使得网络环境较差的位置也能够获得相对流畅、清晰的视频会议效果。
在点对点场景：
两端仅当说话才会进行音频采集、传输，同样的仅当其他端有音频数据时才会接收。如果视频可用，则两端均会进行传输和接收。但当视频中变化的内容很少或部分时，编码器将只为变化的部分作采集和编码传输，自动跳过未变化的部分从而减少传输流量。
在会议场景：
会议端仅当说话才会进行音频采集和传输，但会实时接收其他端传输的音频数据，如果有说话的话。如果视频可用，那么所有端都将接收最多五处会议端的视频和一个全景视频传输的视频数据。如果多余五方，则根据说话频率自动显示最活跃的五方及全景，但也可以手动锁定想要接收视频的会议端到五方中，即使指定的会议端没有音频数据。并且每一处会议端至多可以向其他五端传输视频数据，传输视频的清晰度取决于带宽及CPU。另外需要注意的是如果有使用旧版客户端加入会议的用户，那么在会议过程中会同时传输两路视频流，一路RTVideo编码和一路H.264编码。以及可能出现传输分辨率不同的视频流。
这里我们再来说说动态码率，虽然这已经不是什么新鲜的事物，早在RMVB出来之初就已经流行的非常开，通过根据视频流不同的内容进行不同的码率编码，从而节省视频文件体积，这对视频会议来说就是节约流量和带宽。固定码率的很大一个问题就是无论什么样的画面都采用相同的码率去编码，这使得一些非常简单的画面也花费了大量码率去编码。
比如一个全黑色的图像，如果采用动态编码可以在对图像编码前先分析图像内容，当编码器发现内容只是一个纯黑色的画面，那么可以采用非常低的码率来编码，从而节省空间、流量；到另外一个极端，如果图像内容生动、颜色鲜艳，那么编码器在分析内容时可以得出这一结果，根据系统设置自动使用最佳的码率进行编码，从而获得好的效果，也不浪费带宽和空间。
在这里需要注意的是，上面的内容仅仅是视频、音频本身的带宽，由于要进行视频会议，不单单要考虑音视频本身的编解码，还需要考虑如果进行实时的会议，如何确保低延迟。这就又要提到我们的实时传输协议，视频和音频在传输过程中都将通过实时传输控制协议RTCP来实现。我们再来看看RTCP所占的带宽。
需要注意的是这里是指RTCP占用的最大带宽，而并非一个标准值，同样的这会根据内容自动适应从而减少RTCP带宽的占用。看到这里可能就有点头疼了，不是说很简单吗？那我们来看下实际环境吧，我们不用去计算什么RTCP加上视频、音频，又是否需要FEC什么的在实际情况中的带宽消耗。下面是点对点媒体的带宽占用。
分几种情况，Lync 2013到Lync 2013、Lync 2013到Lync 2010、OCS、Lync 2013到Lync 2013全景、Lync 2013到Lync 2010、OCS全景。
这里再说一下，FEC视频纠错的流量已经包含在了视频负载中，所以这里的不适用并非视频没有FEC功能。我们再来看看在会议场景的带宽情况，会议场景相比来说感觉更复杂一些，因为还单独的划分了发送和接收流量。
这里的主视频的接收的值是所有视频流的总和带宽值，发送则是分别的视频库流。这里我们还需要注意一点，会议场景的视频发送接收的典型带宽均比点对点少，但在最大媒体流带宽的发送接收则是点对点的两倍左右。典型带宽比点对点少，这是由于我们在进行视频会议时更多的是需要共享程序或共享PPT、进行演示等，我们的焦点并非是视频而是会议内容本身。这里的主视频发送和接收最大带宽是8000Kbs，这正是传入两路1080P视频所需的最大带宽。
对于全景视频的接收来说，典型带宽应用在960x144的全景会议场景，而最大带宽媒体流则是应用于1920x288的高清全景视频会议（我们可以发现这正是典型全景会议场景的4倍分辨率）。而发送的话则会稍复杂一些，这是由于可能会发送多种编码、分辨率，所以最大的媒体带宽要稍微大一些。
本文转自 reinxu 51CTO博客，原文链接：http://blog.51cto.com/reinember/1088899，如需转载请自行联系原作者