Lync Server 2013音视频网络流量带宽优化51CTO博客 - 凯时娱乐

Lync Server 2013音视频网络流量带宽优化51CTO博客

2019年04月06日15时20分09秒 | 作者: 若翠 | 标签: 带宽,视频,流量 | 浏览: 2252

前面的不少博文都给咱们、我自己带来了不少的压力,今日咱们来亮点轻松的东西,让咱们振奋、让咱们乐意去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倍分辨率)。而发送的话则会稍杂乱一些,这是因为或许会发送多种编码、分辨率,所以最大的媒体带宽要略微大一些。
版权声明
本文来源于网络,版权归原作者所有,其内容与观点不代表凯时娱乐立场。转载文章仅为传播更有价值的信息,如采编人员采编有误或者版权原因,请与我们联系,我们核实后立即修改或删除。

猜您喜欢的文章