直播間新手常見技術(shù)問題解答--延時(shí)高

直播間新手常見技術(shù)問題解答--延時(shí)高

    延時(shí)高問題分析

我們看看可能產(chǎn)生延時(shí)的模塊有哪些：

1）圖像處理延時(shí)，比如畫面剪裁、美顏、特效處理

2）視頻編碼/解碼延時(shí)

3）網(wǎng)絡(luò)傳輸?shù)难訒r(shí)

4）業(yè)務(wù)代碼中的緩沖區(qū)


一般圖像處理、數(shù)據(jù)拷貝、編解碼帶來的延時(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ì)于第一幀的讀取來說，這是一個(gè)很大的延遲。


視頻中 B 幀的解碼依賴于前后的視頻幀，會(huì)增加延遲。Codec 一般都會(huì)有低延遲優(yōu)化的開關(guān)，對(duì)于 H.264 來說其效果尤其明顯。


如果使用了 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)過多級(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(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ù)怎么積累起來的呢 ？


采集 -> 編碼 -> 數(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ù)怎么積累起來的呢 ？


服務(wù)器-> 數(shù)據(jù)接收 -> 解碼 -> 渲染


當(dāng)網(wǎng)絡(luò)產(chǎn)生抖動(dòng)的時(shí)候，服務(wù)器的數(shù)據(jù)無法及時(shí)地傳輸?shù)讲シ哦?，而由?TCP 協(xié)議的可靠性，所有的數(shù)據(jù)都會(huì)被服務(wù)端積累起來，在網(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ū)，可以通過丟幀或者加速播放的方式快速消費(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í)問題，還是要換成基于 udp 的私有協(xié)議來傳輸數(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

================================

【新聞】

999999.jpg

微信圖片_20230804194631.jpg

   中國(guó)e直播帶貨供應(yīng)鏈金融13306003307(V同），
一件代發(fā)共享云倉(cāng)：主播減去了自己先采購(gòu)囤貨的問題，可以無壓力的開播賣貨。主播只要選定生廠商的抖音小店產(chǎn)品鏈接或快手小店產(chǎn)品鏈接，在自己直播間上了鏈接就可以賣，賣完由廠家小店訂單結(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ā)！

1633584154541554.png