在直播源碼開(kāi)發完成後，技(jì)術(shù)人(rén)員不僅要測試代碼的完整性，還(hái)要考慮平台的兼容性，甚至要顧及到網絡對于直播的影(yǐng)響，因為(wèi)網絡不穩定是造成音(yīn)畫(huà)延遲的最主要因素。事實上(shàng)，一些(xiē)非網絡因素也能造成延遲，今天，小(xiǎo)編就和(hé)大(dà)家(jiā)一起來(lái)詳細了解下，直播源碼開(kāi)發過程中，所有(yǒu)造成音(yīn)畫(huà)延遲的因素都有(yǒu)哪些(xiē)。

一、網絡延時(shí)造成延遲

網絡延時(shí)指的是從主播端采集，到觀衆端播放之間(jiān)的時(shí)間(jiān)差。在信息從主播端傳送到觀衆端的“路程”上(shàng)，可(kě)能會(huì)經過很(hěn)多(duō)CDN節點，經過一次，就會(huì)産生(shēng)一次分發過程，而這種過程必然會(huì)造成延遲。另外，數(shù)據傳輸過程中還(hái)涉及到邏輯上(shàng)的交互，例如包的重傳以及确認，以及緩存上(shàng)的一些(xiē)邏輯等，會(huì)在這個(gè)基礎上(shàng)又增加很(hěn)多(duō)很(hěn)多(duō)。

二、網絡抖動造成延遲

受網絡抖動的影(yǐng)響，當數(shù)據包從開(kāi)始傳送到末尾的間(jiān)隔時(shí)間(jiān)不再平均時(shí)，就容易造成延遲。舉一個(gè)例子，在主播端發送50個(gè)數(shù)據包，每個(gè)包間(jiān)隔1s發出，結果第25個(gè)包在傳輸過程中遇到網絡擁塞，導緻包25不是緊跟着24到達的，而是延遲到第30包後面才到達。這種情況就會(huì)導緻接收端不能依照順序把內(nèi)容播放出來(lái)。然而，為(wèi)了不産生(shēng)失真現象，就不可(kě)避免的造成播放延遲。

三、網絡丢包造成延遲

直播中用到的RTMP、HLS等流媒體(tǐ)傳輸協議都是建立在TCP的基礎之上(shàng)。TCP有(yǒu)一個(gè)很(hěn)重要的特性就是其可(kě)靠性—不會(huì)發生(shēng)數(shù)據丢失的問題。為(wèi)了保證可(kě)靠性，TCP在傳輸過程中會(huì)有(yǒu)3次握手：首先客戶端會(huì)向服務端發送連接請(qǐng)求，服務端同意後，客戶端會(huì)确認這次連接，這就是3次握手。接着，客戶端就開(kāi)始發送數(shù)據，每次發送一批數(shù)據，在服務端的“收到”确認的信息後，會(huì)繼續發送下一批。那(nà)麽問題就來(lái)了，TCP為(wèi)了保證每組數(shù)據傳到，都會(huì)帶有(yǒu)自動重傳機制(zhì)。如果傳輸中發生(shēng)了丢包，沒有(yǒu)收到對端發出的“收到”信号，那(nà)麽發送端就會(huì)自動重傳丢失的包，一直到超時(shí)。網絡丢包是很(hěn)難控制(zhì)的因素，所以當網絡的丢包率開(kāi)始升高(gāo)時(shí)，重傳會(huì)導緻延時(shí)不斷增大(dà)。

四、RTMP累積造成延遲

雖然在流媒體(tǐ)傳輸協議中，RTMP用的無疑是最多(duō)的，但(dàn)是它也有(yǒu)一個(gè)比較顯著的弱點，即累積誤差。原因也比較簡單，就是RTMP基于TCP技(jì)術(shù)：當網絡狀态很(hěn)差時(shí)，服務器(qì)會(huì)将包緩存起來(lái)，從而導緻數(shù)據累積，當網絡狀況好了，就一起發給客戶端，這樣做(zuò)的對策就是，客戶端的緩沖區(qū)會(huì)變得(de)很(hěn)大(dà)，從而發生(shēng)延遲。

以上(shàng)，就是直播源碼開(kāi)發過程中，導緻音(yīn)畫(huà)延遲的幾個(gè)關鍵因素。當然，針對于某些(xiē)延遲情況，小(xiǎo)編也在之前的文章中更新過解決辦法，具體(tǐ)可(kě)以查看文章下方的相關閱讀。如果您對直播源碼開(kāi)發感興趣，歡迎咨詢官方客服。

 本文章聲明(míng)原創，轉載請(qǐng)注明(míng)出自雲豹科技(jì)www.yunbaokj.com