問題背景：
在上一篇文章講了音視頻一些疑難問題的排查，其中一個比較重要的原則就是要將音視頻作為一個系統來看待，問題有可能只是表現在播放端，但是根因有可能在編碼端，也有可能發生在傳輸過程中。其實對于音視頻有些問題的優化，有時也要整體優化，比如延時這種問題。
下面我將會分析延遲的概念，延遲的產生和類型、延遲的優化三大部分的內容，最后再通過一兩個小例子分享下我在解決延遲問題的優化實踐。你可以根據自己的需要，選擇性閱讀。
延遲抖動：
延遲：是網絡傳輸中的一個重要指標，測量了數據從一個端點到另外一個端點所需的時間。一般我們用毫秒作為其單位。通常我們也把延遲叫做延時，但是延時有時還會表示數據包發送端到接受端的往返時間。這個往返時間我們可以通過網絡監控工具測量，測量數據包的發送時間點和接受到確認的時間點，兩者之差就是延時。單向時間就是延遲。
抖動：由于數據包的大小，網絡路由的路徑選擇等眾多因素，我們無法保證數據包的延遲時間是一致的，數據包和數據包延遲的差異我們稱為抖動。也就是說因為數據包的延時值忽大忽小的現象我們稱為是抖動。
可以看出延遲會造成抖動，但是抖動并不完全等價于延遲，所以有時我們分析實際問題時還是要加以區分。
大學經常看直播球賽，記得舍友用筆記本看，球都進了，我這邊用手機過了一會才看到剛才球進的畫面。這就是典型延時場景，其中各個行業對延時的容忍度不一樣，像K歌合唱就對低延時要求非常高。如果歌伴都唱完了上半句，你由于沒有及時聽到，下半句還沒唱出來，對方是非常疑惑的。
但是我們也不能一味的追求低延時，低延時是好，但是會帶來成本的上升。在實時傳輸領域有一個著名的三角理論。
成本我們可以理解為購買服務器需要的硬件成本、軟件開發的人力成本和通訊帶寬的租賃費用；延時就是上面理解的數據包端到端之間的時間差，質量可以理解為視頻的清晰度和細節，音頻的高保真以及數據的完備性。任何行業完成實時數據交互，都要受這三方面的因素的限制。如果過分追求低延時，要么我們要付出比較高的成本要么我們得下降我們的音視頻質量。所以我們針對不同行業，選擇一個用戶能接受和不影響體驗的延時即可。
關于視頻的實時性歸納為三個等級：
偽實時：視頻消費延遲超過?3 秒，單向觀看實時，通用架構是 CDN + RTMP + HLS，現在基本上所有的直播都是這類技術；
準實時：視頻消費延遲 1 ~ 3 秒，能進行雙方互動但互動有障礙。有些直播網站通過 TCP/UDP + FLV 已經實現了這類技術，YY 直播屬于這類技術；
真實時：視頻消費延遲?< 1秒，平均 500 毫秒。這類技術是真正的實時技術，人和人交談沒有明顯延遲感。QQ、微信、Skype 和 WebRTC 等都已經實現了這類技術。
對于嚴格的音頻通話，當延時低于200ms時，就會影響到用戶體驗。達到400ms對方用戶就容易感知出來，1s以上的延遲對于交互式實時直播就不能接受了。下面有一個表格基本列舉了不同業務對于低延時的大致要求，當然即使是同一個業務，應用在不同的場景下對于低延時要求也經常不一樣，這就導致我們解決問題的技術手段也是不一樣的。在視頻監控業務下這種差異更大，對于一些司法、監獄和博物館，實時性要求很高，希望出現問題后立即能進行報警和進行查看，但是對于一些景區直播和學校社區實時性的要求就低很多。
延遲產生：
我們繼續看下一個完整直播系統的示意圖：
音視頻從生產到消費的各個環節都需要花費時間來處理，這些時間之和就造成了視頻觀看方看的視頻是視頻產生方幾秒之前產生的視頻。我們對這些延時進行區分，會總結出以下四種類型的延時：
1.?處理延時：一般就是路由器要分析數據包頭決定這個數據包要送到下一站花費的時間；
2.?排隊延時：數據包從進入到路由器的發送隊列到被發送之間經過的時間，路由排隊算法和網絡都會影響這部分延時。
3.?傳輸延時：將數據包傳入到線路花費的時間，跟數據包的大小和帶寬有關系。
4.?傳播延時：是指數據包第一個bit位從發送端到接收端的時間，其和傳輸距離和傳播速度有關系。
其實對于音視頻系統，我們可以將上面講述的三種延時歸納為下面幾種：
設備端的延時：包括數據的采集、前處理、編碼、解碼、渲染等處理階段花費的時間。也就是A1和A5花費的時間。
音頻部分：
音頻從采集后，會經過模數轉換，將傳統的模擬信號轉換成數字信號就會產生延時，一般在10ms級別；采集后，進行編碼，采用不同的音頻編碼器也會產生不同的延時，以Opus為例，延時也在2.5ms-60ms級別，可以參考上篇文章分析。發送前還需要進行3A算法（AEC、ANS、AGC）的處理，又需要十幾ms.
視頻部分：
從自然采光到成像，取決于CCD和CMOS的成像效率，不過一般也需要幾十ms.對采集的RGB數據要進行YUV轉換和編碼，如果還有B幀會產生比較大的編碼延時，緊接著播放端的渲染也是需要一定時間的。
無論音頻還是視頻，為了防止抖動我們一般會在播放端加上jitter buffer緩存，數據從進入到緩存到出緩存以及當發生丟包時，進行的一些傳輸算法處理也是需要一定的時間，大概會在幾十毫秒到幾百毫秒之間。
設備端和服務器的延時：也就是俗稱的第一公里和最后一公里的延時，包括了A1到A2推流產生的延時和A5向A4拉流的延時。這里的延時跟設備端距離服務器的物理距離，服務器和設備端的網絡運營商，設備的網速和帶寬，設備端自己的負載都有密切關系。
服務器之間的延時：包含了音視頻數據在網絡上進行再次轉碼、切片、轉封裝和協議以及分發CDN等花費的時間，包含了A2到A4整個階段花費的時間。這里要看設備的推流端和播放端是不是在同一個邊緣節點，如果屬于同一個邊緣節點，那延時能小點。國內城市之間的傳播延時也在幾十毫秒，如果跨洲延時會達到百毫秒以上。
所以單就降低實時音視頻系統延時一項內容，都不是靠只優化一個節點或者一個階段就能達到你想要的預期效果，必須站在音視頻整個系統來看待。
延遲測量：
測試方法1：
實際最簡單的做法就是：我們讓推流端也就是主播端比如手機或者IPC攝像頭對著一個在線秒表，然后同時我們用手機或者桌面播放器播放該路視頻，然后得到了在線秒表顯示的時間，等穩定一段時間后我們將在實際線秒表的時間減去播放器顯示的該時間，二者的差值就是當前的系統的延時。然后這種測試方法，每隔一段時間，測試多組，求其平均值就得到了當前負載下的音視頻延時。
測試方法2：
我們也可以在編碼端的視頻幀前面加上SEI幀，SEI的全稱是補充增強信息（Supplemental Enhancement Infomation）,提供了一種向視頻碼流中增加額外私有信息的方法。我們可以隔一段時間就在I幀前面的SPS PPS后面增加SEI幀，私有信息就是這時我們編碼器的NTP標準時間，當該SEI幀信息到達播放器端，我們再計算下本地的NTP時間。這樣本地的值減去SEI的NTP時間，就是當前系統的延時。前提條件，編碼器和播放器進行過NTP校時，保證毫秒級別的時間信息要一致。
注：對于有些播放器如果增加SEI信息，可能會導致播放失敗，所以解碼前我們可以將使用過的SEI幀丟掉。
延遲優化：
經過以上的分析，我們就分析出延時產生的階段和節點，這樣優化延時就有了方法。延時會產生在：
1.?音視頻數據的前處理；
2.?音視頻數據的編解碼；
3.?音視頻數據的網絡傳輸；
4.?為了防止抖動業務代碼中的緩沖區，包括推流服務、轉碼服務、播放器的緩存等；
5.?音視頻的渲染播放；
當然上面會產生延時的地方對于最終的延時影響權重是不一樣的，其中數據的前處理、編解碼、渲染對于延時影響比較小，而網絡傳輸和業務代碼的緩存對于延時影響非常大。所以優化也要結合你的業務有重點進行。
優化思路1：調整推流端和播放端的緩沖區大小，對于25fps的視頻流，如果我們緩存25幀的數據，就會在播放時產生1s的延時。所以我們要動態調整我們的緩沖區，對于推流上行區我們如果帶寬不夠就會產生網絡阻塞，這時發送端的數據就會積累，最終延時不斷累加，導致延時變大。我們此時就需要有一套機制來能夠預測帶寬，降低發送碼率，減低當前發送數據量，減少網絡阻塞，等網絡好的時候再繼續增大數據發送量，增大碼率。
上面說的這些算法有很多，其中WebRTC方案就采用了GCC算法，還有一些類似BBR的算法來實現上述想法。
對于播放端的緩存，當網絡不好產生的延時比較大時，我們需要通過丟幀和加速播放方式快速消耗掉播放緩沖區的數據，從而消除累計的延時。
優化思路2：優化網絡傳輸，如果實時性要求很高的場景，你如果選用基于TCP承載的網絡傳輸協議，無論你怎么優化，也很難降低延時。因為TCP會進行三次握手，而且它會對每一次發送的數據進行確認，還要對丟包進行重傳，所以這些限制很不適合降低延時。我們要優化傳輸協議，我們可以將基于TCP的RTMP、HLS協議切換到基于UDP的RTP、QUIC協議上，或者自己開發基于UDP的私有協議棧，這樣我們就可以對一些TCP延時大的功能進行裁剪和修改，對于一些不關重要的數據進行丟棄，優先保障重要數據的傳輸。其中國內B站、虎牙直播，在線k12教育等都進行了類似的處理；
優化思路3：選擇優質的CDN加速服務，保障傳輸的線路帶寬和線路資源，一般都會提供測速選線、動態監測、智能路由等功能。
優化思路4：如果感覺自己的編解碼，前期處理等花費時間比較多，我們就需要選擇合適的音視頻編解碼器，進行算法調優降低延時，比如我們在播放端能支持硬解的優先選擇硬解否則才選擇軟解。
上面所說的任何一種實踐方法用一兩篇文章都講述不完，特別對于一些GCC、BBR等網絡傳輸算法，依然是高校和大廠最前沿最熱門的研究領域，需要用心學習才能落地到工程項目上，這里只是簡單的提出，有興趣的需要進一步搜索學習和實踐。后面本公眾號也會進行逐漸介紹這些算法，敬請期待。
案例分享：
案例1：
問題：
前一陣我們做了一個項目，就是將自家消費類攝像頭的視頻投屏到像Alexa的智能音箱上，當然音箱就是帶屏幕那種，類似小度小度。實際測試發現，延時比較大，大概有七八秒鐘的樣子，但是對于Alexa這種智能音箱也就是播放器，我們能干預的很有限，畢竟推動亞馬遜研發給你優化這些都是不太可能的，但是我們想把自家攝像頭視頻投屏到Alexa后，這樣在他們商場上架我們產品可以加快我們的硬件海外出貨速度，同時還可以增加我們視頻云的套餐訂閱量。
措施：
最后我們采取了優化轉分發服務器緩存的做法，采取了服務端主動追幀和丟幀的策略使服務器端的緩存能夠根據當前網絡狀態進行自動調節，讓Alexa播放器的播放緩存總是處于基本饑餓狀態，經過一番優化后，延時從七八秒降低到一二秒，達到了上架IPC攝像頭的條件。
所以服務端和播放端的緩存優化是降低延時的一個比較重要手段。
案例2：
問題：
還有一個項目采用了自動切換網絡傳輸協議的措施來降低延時，攝像頭的視頻一般要推送到云服務器上，然后才能進行大規模的轉發和分發。這是因為攝像頭畢竟是嵌入式設備，并發量非常有限，能同時推送的視頻路數也就一兩路，如何想無限制進行分發和允許多客戶端同時觀看，就需要先讓攝像頭的視頻上云到服務端的流媒體，再進行大規模的分發和轉發，這也是視頻監控的基本玩法。但是我們攝像頭以前只支持TCP長鏈接方式向服務器推流，這樣當網絡不好就會丟包重傳，延時也逐漸積累增大。甚至網絡非常不好時，延時會達到幾十秒，用戶體驗很不好。
措施：
我們流媒體服務端會收集播放器的延時數據和丟包，然后當達到一定條件，我們通過信令服務器進行傳輸協議切換，重新讓攝像頭推流。將TCP推流改成UDP推流，我們在流媒體服務器端重新實現組包和增加丟幀策略，降低播放端延時，效果最后也得到了客戶的滿意。
今天就說這么多，祝您心情愉快，工作順利！
公眾號，了解更多：
往期回顧文章:
