本站為廈門(mén)在線直播帶貨供應(yīng)鏈機(jī)構(gòu)官網(wǎng)
當(dāng)前位置：直播間新手常見(jiàn)技術(shù)問(wèn)題解答--延時(shí)高
延時(shí)高問(wèn)題分析
我們看看可能產(chǎn)生延時(shí)的模塊有哪些：
1）圖像處理延時(shí)，比如畫(huà)面剪裁、美顏、特效處理
2）視頻編碼/解碼延時(shí)
3）網(wǎng)絡(luò)傳輸?shù)难訒r(shí)
4）業(yè)務(wù)代碼中的緩沖區(qū)
一般圖像處理、數(shù)據(jù)拷貝、編解碼帶來(lái)的延時(shí)，都是 ms 級(jí)別的，真正會(huì)產(chǎn)生比較大延時(shí)的地方，一個(gè)是互聯(lián)網(wǎng)上的網(wǎng)絡(luò)傳輸延時(shí)，另一個(gè)就是業(yè)務(wù)代碼中的緩沖區(qū)了。
1 編碼延時(shí)
很多人可能不知道 H.264 的解碼器正常情況下會(huì)在顯示之前緩存一定的視頻幀，對(duì)于 QCIF 分辨率大小的視頻（176 × 144）一般會(huì)緩存 16 幀，對(duì)于 720P 的視頻則緩存 5 幀。對(duì)于第一幀的讀取來(lái)說(shuō)，這是一個(gè)很大的延遲。
視頻中 B 幀的解碼依賴(lài)于前后的視頻幀，會(huì)增加延遲。Codec 一般都會(huì)有低延遲優(yōu)化的開(kāi)關(guān)，對(duì)于 H.264 來(lái)說(shuō)其效果尤其明顯。
如果使用了 FFmpeg，降低「-probesize 」和「 -analyze duration」參數(shù)的值，這兩個(gè)值用于視頻幀信息監(jiān)測(cè)和用于監(jiān)測(cè)的時(shí)長(zhǎng)，這兩個(gè)值越大對(duì)編碼延遲的影響越大。
網(wǎng)絡(luò)傳輸延時(shí)
數(shù)據(jù)在網(wǎng)絡(luò)上傳輸，從一個(gè)節(jié)點(diǎn)經(jīng)過(guò)多級(jí)服務(wù)器轉(zhuǎn)發(fā)到達(dá)另一個(gè)節(jié)點(diǎn)，是不可避免有物理延時(shí)的，下面這個(gè)表格給出了理論上數(shù)據(jù)在光纖中的網(wǎng)絡(luò)傳輸?shù)臅r(shí)間（實(shí)際場(chǎng)景中的延時(shí)往往比這個(gè)要大很多，因?yàn)樯婕暗綆?、網(wǎng)絡(luò)抖動(dòng)等干擾）：
業(yè)務(wù)代碼中的緩沖區(qū)
業(yè)務(wù)代碼中的緩沖區(qū)，主要是推流端的緩沖區(qū)和播放端的緩沖區(qū)，一個(gè) 30 fps 的視頻流，緩沖區(qū)每滯留 30 幀，延時(shí)就會(huì)增大 1s，
那么，它們是怎么產(chǎn)生緩沖數(shù)據(jù)的呢 ？
推流端的數(shù)據(jù)怎么積累起來(lái)的呢 ？
采集 -> 編碼 -> 數(shù)據(jù)發(fā)送 -> 服務(wù)器
當(dāng)網(wǎng)絡(luò)產(chǎn)生抖動(dòng)的時(shí)候，數(shù)據(jù)發(fā)送會(huì)因此減慢，產(chǎn)生一定的阻塞，從而導(dǎo)致這些數(shù)據(jù)會(huì)被積累在了推流端的發(fā)送緩沖區(qū)中。
播放端的數(shù)據(jù)怎么積累起來(lái)的呢 ？
服務(wù)器-> 數(shù)據(jù)接收 -> 解碼 -> 渲染
當(dāng)網(wǎng)絡(luò)產(chǎn)生抖動(dòng)的時(shí)候，服務(wù)器的數(shù)據(jù)無(wú)法及時(shí)地傳輸?shù)讲シ哦?，而由?TCP 協(xié)議的可靠性，所有的數(shù)據(jù)都會(huì)被服務(wù)端積累起來(lái)，在網(wǎng)絡(luò)恢復(fù)良好的時(shí)候，會(huì)快速傳輸?shù)讲シ哦?，這些數(shù)據(jù)會(huì)被動(dòng)地積累在接收緩沖區(qū)中。
怎么消除業(yè)務(wù)緩沖區(qū)的累計(jì)延時(shí)呢 ？
推流端的發(fā)送緩沖區(qū)，可以在網(wǎng)絡(luò)恢復(fù)良好的時(shí)候，快送發(fā)送出去，從而消除掉這個(gè)累計(jì)延時(shí)。
播放端的接收緩沖區(qū)，可以通過(guò)丟幀或者加速播放的方式快速消費(fèi)掉緩沖區(qū)中的數(shù)據(jù)，從而消除累計(jì)延時(shí)。
協(xié)議延時(shí)
通常標(biāo)準(zhǔn)的直播協(xié)議有 RTMP，HLV，HLS 三種，一般 RTMP/HLV 協(xié)議的延時(shí)在 1～3s，HLS 協(xié)議的直播延時(shí)則會(huì)更大，注重延時(shí)的直播應(yīng)用，大都會(huì)選擇 RTMP/HLV 協(xié)議，這些協(xié)議均是基于 tcp 的協(xié)議，tcp 協(xié)議的多個(gè)特性導(dǎo)致其延時(shí)明顯要高于基于 udp 的私有協(xié)議，主要有如下方面：
? 建立連接的三次握手
? ACK 機(jī)制
? 丟包重傳
因此，如果想從本質(zhì)上解決直播延時(shí)問(wèn)題，還是要換成基于 udp 的私有協(xié)議來(lái)傳輸數(shù)據(jù)。
————————————————
版權(quán)聲明：本文為CSDN博主「步基」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/wangbuji/article/details/121661187
================================
【新聞】
中國(guó)e直播帶貨供應(yīng)鏈金融13306003307(V同），
一件代發(fā)共享云倉(cāng)：主播減去了自己先采購(gòu)囤貨的問(wèn)題，可以無(wú)壓力的開(kāi)播賣(mài)貨。主播只要選定生廠商的抖音小店產(chǎn)品鏈接或快手小店產(chǎn)品鏈接，在自己直播間上了鏈接就可以賣(mài)，賣(mài)完由廠家小店訂單結(jié)算，廠家網(wǎng)店直接收款；直播帶貨主播直接分傭金；MCN機(jī)構(gòu)直接分管理費(fèi)。
中國(guó)E直播帶貨供應(yīng)鏈機(jī)構(gòu)協(xié)調(diào)廠家按規(guī)則48小時(shí)內(nèi)一件代發(fā)！
