上一篇博客《網絡語音視頻技術淺議（一）》向大家介紹了網絡語音視頻技術的基礎知識。
未閱讀過上篇博客的朋友建議先移步至《網絡語音視頻技術淺議（一）》，這樣更能利於從總體上把握知識，也更利於理解本篇所介紹的內容。
一.引論
我們知道，在諸如即時通訊、視頻會議、遠程醫療、遠程教育、網絡監控等等網絡多媒體應用系統都離不開網絡語音視頻技術，而且這些網絡多媒體應用系統往往對於音、視頻的實時性與流暢性有着較高的要求。
雖然，在我們的直觀印象中好像我們就是直接的訪問到了對方的攝像頭，麥克風、顯示器、聲卡等等設備，但是實際上，在相關的語音視頻呈現在我們面前之前，相關的硬、軟件其實需要完成大量的工作。
就拿我最近正在研究的 OMCS 語音視頻框架來說，其提供了攝像頭連接器、麥克風連接器、桌面連接器、電子白板連接器等API，能讓我們就像訪問本地設備一樣訪問遠程設備。程序員在使用的過程中不禁感覺到，所謂的遠程設備，其實跟本地設備並沒有什么兩異，即使事實上遠隔千山萬水，但是對於我們使用起來而言也是“天涯若比鄰”。因為底層的那些實現對於程序員而言是透明的。所以我們看不到背后的采集、編碼、網絡傳送、解碼、播放等大量的繁難的工作，我們只看到客戶端的幾個連接器，嗖的一下就連接到了遠程的機器的設備上。
就如同下圖所示：
但是我們要知道，OMCS 正是把艱難困苦留給了自己，簡單清晰的API才能讓我們帶走。這些艱難困苦不僅包括回音消除、靜音檢測、噪聲抑制、混音算法等等難題，還包括對於實時性和流暢性的處理與保障。雖然 OMCS 使用起來已經如此方便，但是作為程序員的我們仍然有必要了解其背后的相關原理，尤其是這些最基本的原理。 正是因為這些原理很基本，所以才具有普遍性，掌握了這些基本原理，我們的收貨就不止是用熟了幾個API，而是具有了自己研發創造的潛力！
二.實時性
所謂實時性就是指遠程語音視頻通訊的過程中，發送方發送的音、視頻和接收方接收到的音、視頻在時間上要具有一致性。比如在即時通訊、視頻會議、遠程教育等應用中，都需要進行語音視頻會話，而如果系統的實時性達不到要求，那么就會出現發送方說話說完了好久，對方才聽到然后回應；接受者看到的視頻圖像，其實並不是當前正在發生的畫面——這樣的用戶體驗自然是相當糟糕的！當然，完全的實時性是難以實現的，所以我們的任務就是盡量使得收發兩方的時間差小，小了又小！
那么，影響語音視頻通訊的實時性的因素是什么呢？那就是網絡延遲。網絡延遲越小，語音視頻通訊的實時性就越好；反之，則越差。所以，為了保證足夠的實時性，我們必須從減小網絡延遲入手。但是，網絡的延遲主要取決於網絡的速度和通話雙方的物理位置的距離，單純從軟件的角度進行優化，優化的可能性很小。
三.流暢性
所謂流暢性指的就是遠程語音視頻通訊的過程中，接收方接收到的音、視頻流暢平穩，不會出現卡頓或者突然變快的情況。同樣，如果網絡多媒體通訊系統的流暢性達不到要去，所帶來的用戶體驗也是極為糟糕的！所以我們要盡量保證語音視頻通訊的流暢性，比流暢更流暢！
那么，影響語音視頻通訊的流暢性的因素是什么呢？那就是網絡抖動。所謂網絡抖動就是指網絡的忽快忽慢，網絡越平穩，抖動就越小，反之則大。所以，為了保證足夠的流暢性，我們必須從減小網絡抖動手。不同於實時性難以從軟件上優化，網絡的抖動的優化從軟件上我們有辦法。所以，即便是網絡本身的質量不佳，抖動很大，但是我們也不用害怕，“若是那豺狼來了，我們有獵槍！”
四.實時性與流暢性的權衡
在稍后的分析中我們將看到，實時性與流暢性在某種意義上是一對矛盾，二者不可得兼。具體二者如何成為了矛盾，這里不做具體的論述，稍后的分析中我們會看出端倪，這里姑且不嚴謹地作為結論。
既然二者是一對矛盾，那么兼愛與兼得自然是無法實現了，所以我們必須進行權衡取舍。那么這個權衡取舍的標准又是什么呢？這個標准就是用戶體驗！舊用戶體驗的角度來說，流暢性的要求往往要高於實時性——音、視頻的卡頓與忽快忽慢是難以忍受的，而音、視頻有所延遲常常是可以接受的。
因此，我們應該優先保障流暢性。
五.如何優化流暢性
既然實時性從軟件上難以優化，而且從用戶體驗的角度而言我們也應該優先保障流暢性，那么我們就集中精力來優化流暢性。可是如何優化流暢性呢？
既然影響流暢性的因素是網絡的抖動，那么減小網絡的抖動便是辦法的所在。方法如下：
1.硬件優化，即改善網絡狀況。
2.軟件優化，增加緩沖區。
這里我主要是探討軟件的優化。
所謂增加緩沖區是什么意思呢？
我們可以以水流作為比喻。請看下圖
第一根箭頭代表一根水管，箭頭方向代表了水流的方向，箭頭處代表水流出口，這里就假設為水龍頭。第二根箭頭類似，只不過中間加了一個水箱。
對於第一根水管而言，水流的速度處處一致，當水流快時，水龍頭出水也快；水流慢時，水龍頭出水也慢。
對於第二根水管而言，水流的速度在水箱之前那段處處一致。假設水龍頭閥門恆定，則水流快時，水箱儲水，而水龍頭放水速度恆定；水流慢時，水箱出水，則水龍頭放水速度亦恆定。
所以，所謂的增加緩沖區就是增加一個類似於水箱的裝置。
在程序中，我們的緩沖區就是一個隊列。如下圖所示：
這就好比是一個空水箱。當網速變快時，網絡中之前未及時傳輸的音、視頻數據會涌向接收方，而接收方將其存儲在緩沖隊列中，從而不至於播放變快。如下圖所示：
假設目前接收到的是第7、8、9幀數據，但是由於播放是按照一定的幀頻從隊列中取數據，所以第7、8、9幀數據暫時存放在隊列中。當網速變慢時，接收方一段時間內都沒有接收到相應的數據，此時播放仍是按照一定的幀頻從隊列中取數據，於是第7、8、9幀數據被依次取出播放，從而不至於音、視頻中斷。
這就是緩沖區保障流暢性的基本原理。
六.保障流暢性所付出的代價
之前說過，流暢性與實時性在某種意義上是一對矛盾，在這里我們就可以看出端倪。再看看這幅圖： 
我們發現，發送方已經發出了第9幀數據，而接收方正在播放的還是第6幀數據，所以，緩沖隊列實際上造成了額外的延遲。
1.未設置緩沖區時
語音視頻數據的總延遲 = 網絡本身的延遲
2.設置了緩沖區后
語音視頻數據的總延遲 = 網絡本身的延遲 + 緩沖區造成的額外的延遲
所以說，我們是以犧牲了部分實時性的代價換取了相應的流暢性。
但是，這個犧牲也不能過大。所以，我們不能讓因為設置緩沖區而造成的延遲無限大。也就是說，我們要為這個額外延遲設置上限，那么設置上限上限意味着什么呢？或者說這個上限與什么因素有關呢？
很容易想到，這個上限與緩沖隊列的大小有關。當隊列滿時，延遲達到上限。如下圖所示：
所以，為了控制延遲，我們必須控制緩沖區的大小。如何控制呢？一刀切肯定不好，最好是根據網絡抖動的情況動態的來調整。OMCS語音視頻框架正是采用了這種策略。這樣一來，實時性與流暢性就達到了矛盾的統一，彼此之間形成一種和諧狀態。
六.結語
最后還是要感謝知名博主zhuweisky，感謝他對我在網絡語音視頻技術方面的指點，即便是本文，也是我對其本人的博文《淺談網絡語音技術》中的相關內容的一個闡釋與發揮。也希望zhuweisky以后能與我們分享更多的技術與心得。
我個人在以后的深入學習過程中也會與大家分享更多的知識與心得，所以，希望朋友們不吝點贊，以資鼓勵！先謝謝大家！