問題背景：
在上一篇文章講了音視頻一些疑難問題的排查昨忆，其中一個比較重要的原則就是要將音視頻作為一個系統(tǒng)來看待惶洲，問題有可能只是表現(xiàn)在播放端，但是根因有可能在編碼端裹粤，也有可能發(fā)生在傳輸過程中终蒂。其實對于音視頻有些問題的優(yōu)化，有時也要整體優(yōu)化遥诉，比如延時這種問題拇泣。
下面我將會分析延遲的概念，延遲的產(chǎn)生和類型矮锈、延遲的優(yōu)化三大部分的內(nèi)容霉翔，最后再通過一兩個小例子分享下我在解決延遲問題的優(yōu)化實踐。你可以根據(jù)自己的需要苞笨，選擇性閱讀债朵。
延遲抖動：
延遲：是網(wǎng)絡(luò)傳輸中的一個重要指標子眶，測量了數(shù)據(jù)從一個端點到另外一個端點所需的時間。一般我們用毫秒作為其單位序芦。通常我們也把延遲叫做延時臭杰，但是延時有時還會表示數(shù)據(jù)包發(fā)送端到接受端的往返時間。這個往返時間我們可以通過網(wǎng)絡(luò)監(jiān)控工具測量谚中，測量數(shù)據(jù)包的發(fā)送時間點和接受到確認的時間點渴杆，兩者之差就是延時。單向時間就是延遲藏杖。
抖動：由于數(shù)據(jù)包的大小，網(wǎng)絡(luò)路由的路徑選擇等眾多因素脉顿，我們無法保證數(shù)據(jù)包的延遲時間是一致的蝌麸，數(shù)據(jù)包和數(shù)據(jù)包延遲的差異我們稱為抖動。也就是說因為數(shù)據(jù)包的延時值忽大忽小的現(xiàn)象我們稱為是抖動艾疟。
可以看出延遲會造成抖動来吩，但是抖動并不完全等價于延遲，所以有時我們分析實際問題時還是要加以區(qū)分蔽莱。
大學經(jīng)车芙看直播球賽，記得舍友用筆記本看盗冷，球都進了怠苔，我這邊用手機過了一會才看到剛才球進的畫面。這就是典型延時場景仪糖，其中各個行業(yè)對延時的容忍度不一樣柑司，像K歌合唱就對低延時要求非常高。如果歌伴都唱完了上半句锅劝，你由于沒有及時聽到攒驰，下半句還沒唱出來，對方是非常疑惑的故爵。
但是我們也不能一味的追求低延時玻粪，低延時是好，但是會帶來成本的上升诬垂。在實時傳輸領(lǐng)域有一個著名的三角理論劲室。
成本我們可以理解為購買服務(wù)器需要的硬件成本、軟件開發(fā)的人力成本和通訊帶寬的租賃費用结窘；延時就是上面理解的數(shù)據(jù)包端到端之間的時間差痹籍，質(zhì)量可以理解為視頻的清晰度和細節(jié)，音頻的高保真以及數(shù)據(jù)的完備性晦鞋。任何行業(yè)完成實時數(shù)據(jù)交互蹲缠，都要受這三方面的因素的限制棺克。如果過分追求低延時，要么我們要付出比較高的成本要么我們得下降我們的音視頻質(zhì)量线定。所以我們針對不同行業(yè)娜谊，選擇一個用戶能接受和不影響體驗的延時即可。
關(guān)于視頻的實時性歸納為三個等級：
偽實時：視頻消費延遲超過?3 秒斤讥，單向觀看實時纱皆，通用架構(gòu)是 CDN + RTMP + HLS，現(xiàn)在基本上所有的直播都是這類技術(shù)芭商；
準實時：視頻消費延遲 1 ~ 3 秒派草，能進行雙方互動但互動有障礙。有些直播網(wǎng)站通過 TCP/UDP + FLV 已經(jīng)實現(xiàn)了這類技術(shù)铛楣，YY 直播屬于這類技術(shù)近迁；
真實時：視頻消費延遲?< 1秒，平均 500 毫秒簸州。這類技術(shù)是真正的實時技術(shù)鉴竭，人和人交談沒有明顯延遲感。QQ岸浑、微信搏存、Skype 和 WebRTC 等都已經(jīng)實現(xiàn)了這類技術(shù)。
對于嚴格的音頻通話矢洲，當延時低于200ms時璧眠，就會影響到用戶體驗。達到400ms對方用戶就容易感知出來读虏，1s以上的延遲對于交互式實時直播就不能接受了蛆橡。下面有一個表格基本列舉了不同業(yè)務(wù)對于低延時的大致要求，當然即使是同一個業(yè)務(wù)掘譬，應用在不同的場景下對于低延時要求也經(jīng)常不一樣泰演，這就導致我們解決問題的技術(shù)手段也是不一樣的。在視頻監(jiān)控業(yè)務(wù)下這種差異更大葱轩，對于一些司法睦焕、監(jiān)獄和博物館，實時性要求很高靴拱，希望出現(xiàn)問題后立即能進行報警和進行查看垃喊，但是對于一些景區(qū)直播和學校社區(qū)實時性的要求就低很多。
延遲產(chǎn)生：
我們繼續(xù)看下一個完整直播系統(tǒng)的示意圖：
音視頻從生產(chǎn)到消費的各個環(huán)節(jié)都需要花費時間來處理袜炕，這些時間之和就造成了視頻觀看方看的視頻是視頻產(chǎn)生方幾秒之前產(chǎn)生的視頻本谜。我們對這些延時進行區(qū)分，會總結(jié)出以下四種類型的延時：
1.?處理延時：一般就是路由器要分析數(shù)據(jù)包頭決定這個數(shù)據(jù)包要送到下一站花費的時間偎窘；
2.?排隊延時：數(shù)據(jù)包從進入到路由器的發(fā)送隊列到被發(fā)送之間經(jīng)過的時間乌助，路由排隊算法和網(wǎng)絡(luò)都會影響這部分延時溜在。
3.?傳輸延時：將數(shù)據(jù)包傳入到線路花費的時間，跟數(shù)據(jù)包的大小和帶寬有關(guān)系他托。
4.?傳播延時：是指數(shù)據(jù)包第一個bit位從發(fā)送端到接收端的時間掖肋，其和傳輸距離和傳播速度有關(guān)系。
其實對于音視頻系統(tǒng)赏参，我們可以將上面講述的三種延時歸納為下面幾種：
設(shè)備端的延時：包括數(shù)據(jù)的采集志笼、前處理、編碼把篓、解碼纫溃、渲染等處理階段花費的時間。也就是A1和A5花費的時間韧掩。
音頻部分：
音頻從采集后紊浩，會經(jīng)過模數(shù)轉(zhuǎn)換，將傳統(tǒng)的模擬信號轉(zhuǎn)換成數(shù)字信號就會產(chǎn)生延時揍很，一般在10ms級別郎楼；采集后万伤，進行編碼窒悔，采用不同的音頻編碼器也會產(chǎn)生不同的延時，以O(shè)pus為例敌买，延時也在2.5ms-60ms級別简珠，可以參考上篇文章分析。發(fā)送前還需要進行3A算法（AEC虹钮、ANS聋庵、AGC）的處理，又需要十幾ms.
視頻部分：
從自然采光到成像芙粱，取決于CCD和CMOS的成像效率祭玉，不過一般也需要幾十ms.對采集的RGB數(shù)據(jù)要進行YUV轉(zhuǎn)換和編碼，如果還有B幀會產(chǎn)生比較大的編碼延時春畔，緊接著播放端的渲染也是需要一定時間的脱货。
無論音頻還是視頻，為了防止抖動我們一般會在播放端加上jitter buffer緩存律姨，數(shù)據(jù)從進入到緩存到出緩存以及當發(fā)生丟包時振峻，進行的一些傳輸算法處理也是需要一定的時間，大概會在幾十毫秒到幾百毫秒之間择份。
設(shè)備端和服務(wù)器的延時：也就是俗稱的第一公里和最后一公里的延時扣孟，包括了A1到A2推流產(chǎn)生的延時和A5向A4拉流的延時。這里的延時跟設(shè)備端距離服務(wù)器的物理距離荣赶，服務(wù)器和設(shè)備端的網(wǎng)絡(luò)運營商凤价，設(shè)備的網(wǎng)速和帶寬鸽斟，設(shè)備端自己的負載都有密切關(guān)系。
服務(wù)器之間的延時：包含了音視頻數(shù)據(jù)在網(wǎng)絡(luò)上進行再次轉(zhuǎn)碼料仗、切片湾盗、轉(zhuǎn)封裝和協(xié)議以及分發(fā)CDN等花費的時間，包含了A2到A4整個階段花費的時間立轧。這里要看設(shè)備的推流端和播放端是不是在同一個邊緣節(jié)點格粪，如果屬于同一個邊緣節(jié)點，那延時能小點氛改。國內(nèi)城市之間的傳播延時也在幾十毫秒帐萎，如果跨洲延時會達到百毫秒以上。
所以單就降低實時音視頻系統(tǒng)延時一項內(nèi)容胜卤，都不是靠只優(yōu)化一個節(jié)點或者一個階段就能達到你想要的預期效果疆导，必須站在音視頻整個系統(tǒng)來看待。
延遲測量：
測試方法1：
實際最簡單的做法就是：我們讓推流端也就是主播端比如手機或者IPC攝像頭對著一個在線秒表葛躏，然后同時我們用手機或者桌面播放器播放該路視頻澈段，然后得到了在線秒表顯示的時間，等穩(wěn)定一段時間后我們將在實際線秒表的時間減去播放器顯示的該時間舰攒，二者的差值就是當前的系統(tǒng)的延時败富。然后這種測試方法，每隔一段時間摩窃，測試多組兽叮，求其平均值就得到了當前負載下的音視頻延時。
測試方法2：
我們也可以在編碼端的視頻幀前面加上SEI幀猾愿，SEI的全稱是補充增強信息（Supplemental Enhancement Infomation）,提供了一種向視頻碼流中增加額外私有信息的方法鹦聪。我們可以隔一段時間就在I幀前面的SPS PPS后面增加SEI幀，私有信息就是這時我們編碼器的NTP標準時間蒂秘，當該SEI幀信息到達播放器端泽本，我們再計算下本地的NTP時間。這樣本地的值減去SEI的NTP時間姻僧，就是當前系統(tǒng)的延時规丽。前提條件，編碼器和播放器進行過NTP校時段化，保證毫秒級別的時間信息要一致嘁捷。
注：對于有些播放器如果增加SEI信息，可能會導致播放失敗显熏，所以解碼前我們可以將使用過的SEI幀丟掉雄嚣。
延遲優(yōu)化：
經(jīng)過以上的分析，我們就分析出延時產(chǎn)生的階段和節(jié)點，這樣優(yōu)化延時就有了方法缓升。延時會產(chǎn)生在：
1.?音視頻數(shù)據(jù)的前處理鼓鲁；
2.?音視頻數(shù)據(jù)的編解碼；
3.?音視頻數(shù)據(jù)的網(wǎng)絡(luò)傳輸港谊；
4.?為了防止抖動業(yè)務(wù)代碼中的緩沖區(qū)骇吭，包括推流服務(wù)、轉(zhuǎn)碼服務(wù)歧寺、播放器的緩存等燥狰；
5.?音視頻的渲染播放；
當然上面會產(chǎn)生延時的地方對于最終的延時影響權(quán)重是不一樣的斜筐，其中數(shù)據(jù)的前處理龙致、編解碼、渲染對于延時影響比較小顷链，而網(wǎng)絡(luò)傳輸和業(yè)務(wù)代碼的緩存對于延時影響非常大目代。所以優(yōu)化也要結(jié)合你的業(yè)務(wù)有重點進行。
優(yōu)化思路1：調(diào)整推流端和播放端的緩沖區(qū)大小嗤练，對于25fps的視頻流榛了，如果我們緩存25幀的數(shù)據(jù)，就會在播放時產(chǎn)生1s的延時煞抬。所以我們要動態(tài)調(diào)整我們的緩沖區(qū)霜大，對于推流上行區(qū)我們?nèi)绻麕挷粔蚓蜁a(chǎn)生網(wǎng)絡(luò)阻塞，這時發(fā)送端的數(shù)據(jù)就會積累此疹，最終延時不斷累加僧诚，導致延時變大遮婶。我們此時就需要有一套機制來能夠預測帶寬蝗碎，降低發(fā)送碼率，減低當前發(fā)送數(shù)據(jù)量旗扑，減少網(wǎng)絡(luò)阻塞蹦骑，等網(wǎng)絡(luò)好的時候再繼續(xù)增大數(shù)據(jù)發(fā)送量，增大碼率臀防。
上面說的這些算法有很多眠菇，其中WebRTC方案就采用了GCC算法，還有一些類似BBR的算法來實現(xiàn)上述想法袱衷。
對于播放端的緩存捎废，當網(wǎng)絡(luò)不好產(chǎn)生的延時比較大時，我們需要通過丟幀和加速播放方式快速消耗掉播放緩沖區(qū)的數(shù)據(jù)致燥，從而消除累計的延時登疗。
優(yōu)化思路2：優(yōu)化網(wǎng)絡(luò)傳輸，如果實時性要求很高的場景，你如果選用基于TCP承載的網(wǎng)絡(luò)傳輸協(xié)議辐益，無論你怎么優(yōu)化断傲，也很難降低延時。因為TCP會進行三次握手智政，而且它會對每一次發(fā)送的數(shù)據(jù)進行確認认罩，還要對丟包進行重傳，所以這些限制很不適合降低延時续捂。我們要優(yōu)化傳輸協(xié)議垦垂，我們可以將基于TCP的RTMP、HLS協(xié)議切換到基于UDP的RTP牙瓢、QUIC協(xié)議上乔外，或者自己開發(fā)基于UDP的私有協(xié)議棧，這樣我們就可以對一些TCP延時大的功能進行裁剪和修改一罩，對于一些不關(guān)重要的數(shù)據(jù)進行丟棄杨幼，優(yōu)先保障重要數(shù)據(jù)的傳輸。其中國內(nèi)B站聂渊、虎牙直播差购，在線k12教育等都進行了類似的處理；
優(yōu)化思路3：選擇優(yōu)質(zhì)的CDN加速服務(wù)汉嗽，保障傳輸?shù)木€路帶寬和線路資源欲逃，一般都會提供測速選線、動態(tài)監(jiān)測饼暑、智能路由等功能稳析。
優(yōu)化思路4：如果感覺自己的編解碼，前期處理等花費時間比較多弓叛，我們就需要選擇合適的音視頻編解碼器彰居，進行算法調(diào)優(yōu)降低延時，比如我們在播放端能支持硬解的優(yōu)先選擇硬解否則才選擇軟解撰筷。
上面所說的任何一種實踐方法用一兩篇文章都講述不完陈惰，特別對于一些GCC、BBR等網(wǎng)絡(luò)傳輸算法毕籽，依然是高校和大廠最前沿最熱門的研究領(lǐng)域抬闯，需要用心學習才能落地到工程項目上，這里只是簡單的提出关筒，有興趣的需要進一步搜索學習和實踐溶握。后面本公眾號也會進行逐漸介紹這些算法，敬請期待蒸播。
案例分享：
案例1：
問題：
前一陣我們做了一個項目睡榆，就是將自家消費類攝像頭的視頻投屏到像Alexa的智能音箱上，當然音箱就是帶屏幕那種，類似小度小度肉微。實際測試發(fā)現(xiàn)匾鸥，延時比較大，大概有七八秒鐘的樣子碉纳，但是對于Alexa這種智能音箱也就是播放器勿负，我們能干預的很有限，畢竟推動亞馬遜研發(fā)給你優(yōu)化這些都是不太可能的劳曹，但是我們想把自家攝像頭視頻投屏到Alexa后奴愉，這樣在他們商場上架我們產(chǎn)品可以加快我們的硬件海外出貨速度，同時還可以增加我們視頻云的套餐訂閱量铁孵。
措施：
最后我們采取了優(yōu)化轉(zhuǎn)分發(fā)服務(wù)器緩存的做法锭硼，采取了服務(wù)端主動追幀和丟幀的策略使服務(wù)器端的緩存能夠根據(jù)當前網(wǎng)絡(luò)狀態(tài)進行自動調(diào)節(jié)，讓Alexa播放器的播放緩存總是處于基本饑餓狀態(tài)蜕劝，經(jīng)過一番優(yōu)化后檀头，延時從七八秒降低到一二秒，達到了上架IPC攝像頭的條件岖沛。
所以服務(wù)端和播放端的緩存優(yōu)化是降低延時的一個比較重要手段暑始。
案例2：
問題：
還有一個項目采用了自動切換網(wǎng)絡(luò)傳輸協(xié)議的措施來降低延時，攝像頭的視頻一般要推送到云服務(wù)器上婴削，然后才能進行大規(guī)模的轉(zhuǎn)發(fā)和分發(fā)廊镜。這是因為攝像頭畢竟是嵌入式設(shè)備，并發(fā)量非常有限唉俗，能同時推送的視頻路數(shù)也就一兩路嗤朴，如何想無限制進行分發(fā)和允許多客戶端同時觀看，就需要先讓攝像頭的視頻上云到服務(wù)端的流媒體虫溜，再進行大規(guī)模的分發(fā)和轉(zhuǎn)發(fā)雹姊，這也是視頻監(jiān)控的基本玩法。但是我們攝像頭以前只支持TCP長鏈接方式向服務(wù)器推流吼渡，這樣當網(wǎng)絡(luò)不好就會丟包重傳容为，延時也逐漸積累增大乓序。甚至網(wǎng)絡(luò)非常不好時寺酪，延時會達到幾十秒，用戶體驗很不好替劈。
措施：
我們流媒體服務(wù)端會收集播放器的延時數(shù)據(jù)和丟包寄雀，然后當達到一定條件，我們通過信令服務(wù)器進行傳輸協(xié)議切換陨献，重新讓攝像頭推流盒犹。將TCP推流改成UDP推流，我們在流媒體服務(wù)器端重新實現(xiàn)組包和增加丟幀策略，降低播放端延時急膀，效果最后也得到了客戶的滿意沮协。
今天就說這么多，祝您心情愉快卓嫂，工作順利慷暂！
公眾號，了解更多：
往期回顧文章:
