上一篇博客《网络语音视频技术浅议（一）》向大家介绍了网络语音视频技术的基础知识。
未阅读过上篇博客的朋友建议先移步至《网络语音视频技术浅议（一）》，这样更能利于从总体上把握知识，也更利于理解本篇所介绍的内容。
一.引论
我们知道，在诸如即时通讯、视频会议、远程医疗、远程教育、网络监控等等网络多媒体应用系统都离不开网络语音视频技术，而且这些网络多媒体应用系统往往对于音、视频的实时性与流畅性有着较高的要求。
虽然，在我们的直观印象中好像我们就是直接的访问到了对方的摄像头，麦克风、显示器、声卡等等设备，但是实际上，在相关的语音视频呈现在我们面前之前，相关的硬、软件其实需要完成大量的工作。
就拿我最近正在研究的 OMCS 语音视频框架来说，其提供了摄像头连接器、麦克风连接器、桌面连接器、电子白板连接器等API，能让我们就像访问本地设备一样访问远程设备。程序员在使用的过程中不禁感觉到，所谓的远程设备，其实跟本地设备并没有什么两异，即使事实上远隔千山万水，但是对于我们使用起来而言也是“天涯若比邻”。因为底层的那些实现对于程序员而言是透明的。所以我们看不到背后的采集、编码、网络传送、解码、播放等大量的繁难的工作，我们只看到客户端的几个连接器，嗖的一下就连接到了远程的机器的设备上。
就如同下图所示：
但是我们要知道，OMCS 正是把艰难困苦留给了自己，简单清晰的API才能让我们带走。这些艰难困苦不仅包括回音消除、静音检测、噪声抑制、混音算法等等难题，还包括对于实时性和流畅性的处理与保障。虽然 OMCS 使用起来已经如此方便，但是作为程序员的我们仍然有必要了解其背后的相关原理，尤其是这些最基本的原理。 正是因为这些原理很基本，所以才具有普遍性，掌握了这些基本原理，我们的收货就不止是用熟了几个API，而是具有了自己研发创造的潜力！
二.实时性
所谓实时性就是指远程语音视频通讯的过程中，发送方发送的音、视频和接收方接收到的音、视频在时间上要具有一致性。比如在即时通讯、视频会议、远程教育等应用中，都需要进行语音视频会话，而如果系统的实时性达不到要求，那么就会出现发送方说话说完了好久，对方才听到然后回应；接受者看到的视频图像，其实并不是当前正在发生的画面——这样的用户体验自然是相当糟糕的！当然，完全的实时性是难以实现的，所以我们的任务就是尽量使得收发两方的时间差小，小了又小！
那么，影响语音视频通讯的实时性的因素是什么呢？那就是网络延迟。网络延迟越小，语音视频通讯的实时性就越好；反之，则越差。所以，为了保证足够的实时性，我们必须从减小网络延迟入手。但是，网络的延迟主要取决于网络的速度和通话双方的物理位置的距离，单纯从软件的角度进行优化，优化的可能性很小。
三.流畅性
所谓流畅性指的就是远程语音视频通讯的过程中，接收方接收到的音、视频流畅平稳，不会出现卡顿或者突然变快的情况。同样，如果网络多媒体通讯系统的流畅性达不到要去，所带来的用户体验也是极为糟糕的！所以我们要尽量保证语音视频通讯的流畅性，比流畅更流畅！
那么，影响语音视频通讯的流畅性的因素是什么呢？那就是网络抖动。所谓网络抖动就是指网络的忽快忽慢，网络越平稳，抖动就越小，反之则大。所以，为了保证足够的流畅性，我们必须从减小网络抖动手。不同于实时性难以从软件上优化，网络的抖动的优化从软件上我们有办法。所以，即便是网络本身的质量不佳，抖动很大，但是我们也不用害怕，“若是那豺狼来了，我们有猎枪！”
四.实时性与流畅性的权衡
在稍后的分析中我们将看到，实时性与流畅性在某种意义上是一对矛盾，二者不可得兼。具体二者如何成为了矛盾，这里不做具体的论述，稍后的分析中我们会看出端倪，这里姑且不严谨地作为结论。
既然二者是一对矛盾，那么兼爱与兼得自然是无法实现了，所以我们必须进行权衡取舍。那么这个权衡取舍的标准又是什么呢？这个标准就是用户体验！旧用户体验的角度来说，流畅性的要求往往要高于实时性——音、视频的卡顿与忽快忽慢是难以忍受的，而音、视频有所延迟常常是可以接受的。
因此，我们应该优先保障流畅性。
五.如何优化流畅性
既然实时性从软件上难以优化，而且从用户体验的角度而言我们也应该优先保障流畅性，那么我们就集中精力来优化流畅性。可是如何优化流畅性呢？
既然影响流畅性的因素是网络的抖动，那么减小网络的抖动便是办法的所在。方法如下：
1.硬件优化，即改善网络状况。
2.软件优化，增加缓冲区。
这里我主要是探讨软件的优化。
所谓增加缓冲区是什么意思呢？
我们可以以水流作为比喻。请看下图
第一根箭头代表一根水管，箭头方向代表了水流的方向，箭头处代表水流出口，这里就假设为水龙头。第二根箭头类似，只不过中间加了一个水箱。
对于第一根水管而言，水流的速度处处一致，当水流快时，水龙头出水也快；水流慢时，水龙头出水也慢。
对于第二根水管而言，水流的速度在水箱之前那段处处一致。假设水龙头阀门恒定，则水流快时，水箱储水，而水龙头放水速度恒定；水流慢时，水箱出水，则水龙头放水速度亦恒定。
所以，所谓的增加缓冲区就是增加一个类似于水箱的装置。
在程序中，我们的缓冲区就是一个队列。如下图所示：
这就好比是一个空水箱。当网速变快时，网络中之前未及时传输的音、视频数据会涌向接收方，而接收方将其存储在缓冲队列中，从而不至于播放变快。如下图所示：
假设目前接收到的是第7、8、9帧数据，但是由于播放是按照一定的帧频从队列中取数据，所以第7、8、9帧数据暂时存放在队列中。当网速变慢时，接收方一段时间内都没有接收到相应的数据，此时播放仍是按照一定的帧频从队列中取数据，于是第7、8、9帧数据被依次取出播放，从而不至于音、视频中断。
这就是缓冲区保障流畅性的基本原理。
六.保障流畅性所付出的代价
之前说过，流畅性与实时性在某种意义上是一对矛盾，在这里我们就可以看出端倪。再看看这幅图： 
我们发现，发送方已经发出了第9帧数据，而接收方正在播放的还是第6帧数据，所以，缓冲队列实际上造成了额外的延迟。
1.未设置缓冲区时
语音视频数据的总延迟 = 网络本身的延迟
2.设置了缓冲区后
语音视频数据的总延迟 = 网络本身的延迟 + 缓冲区造成的额外的延迟
所以说，我们是以牺牲了部分实时性的代价换取了相应的流畅性。
但是，这个牺牲也不能过大。所以，我们不能让因为设置缓冲区而造成的延迟无限大。也就是说，我们要为这个额外延迟设置上限，那么设置上限上限意味着什么呢？或者说这个上限与什么因素有关呢？
很容易想到，这个上限与缓冲队列的大小有关。当队列满时，延迟达到上限。如下图所示：
所以，为了控制延迟，我们必须控制缓冲区的大小。如何控制呢？一刀切肯定不好，最好是根据网络抖动的情况动态的来调整。OMCS语音视频框架正是采用了这种策略。这样一来，实时性与流畅性就达到了矛盾的统一，彼此之间形成一种和谐状态。
六.结语
最后还是要感谢知名博主zhuweisky，感谢他对我在网络语音视频技术方面的指点，即便是本文，也是我对其本人的博文《浅谈网络语音技术》中的相关内容的一个阐释与发挥。也希望zhuweisky以后能与我们分享更多的技术与心得。
我个人在以后的深入学习过程中也会与大家分享更多的知识与心得，所以，希望朋友们不吝点赞，以资鼓励！先谢谢大家！