屏幕直播系統(tǒng)延遲優(yōu)化①

付鵬斌,任 衡,楊惠榮

(北京工業(yè)大學(xué) 信息學(xué)部,北京 100124)

智能手機(jī)的出現(xiàn)和移動(dòng)互聯(lián)網(wǎng)的崛起為觀看清晰的直播提供了基礎(chǔ)保障,然而,隨著直播并發(fā)量的驟增、網(wǎng)絡(luò)傳輸?shù)牟淮_定性等原因,在直播時(shí)會(huì)產(chǎn)生不同程度的畫面延遲.市面上基于HLS(HTTP Live Streaming)[1]協(xié)議的直播,理論延遲在10 s～30 s 之間,基于RTMP (Real Time Messaging Protocol)[2]協(xié)議的直播在多終端播放條件下延遲在5 s～10 s 之間,無法滿足實(shí)時(shí)直播的需求.所以如何降低直播延遲,增強(qiáng)直播的實(shí)時(shí)性體驗(yàn)成為一個(gè)關(guān)鍵性的技術(shù)挑戰(zhàn).

本文通過分析直播的各個(gè)環(huán)節(jié),從網(wǎng)絡(luò)推流、首幀打開時(shí)間、視頻編碼三個(gè)角度進(jìn)行了直播延遲優(yōu)化.一是依據(jù)網(wǎng)絡(luò)狀況自適應(yīng)調(diào)整直播推流碼率,優(yōu)化推流策略；二是設(shè)計(jì)實(shí)現(xiàn)關(guān)鍵幀緩存算法,降低首幀加載延遲；三是對(duì)x264 算法幀內(nèi)預(yù)測(cè)部分進(jìn)行改進(jìn),降低編碼延遲.最終實(shí)現(xiàn)了一個(gè)低延遲的屏幕直播系統(tǒng),增強(qiáng)了直播的實(shí)時(shí)性體驗(yàn).

1 網(wǎng)絡(luò)自適應(yīng)推流

網(wǎng)絡(luò)自適應(yīng)推流的作用是在網(wǎng)絡(luò)波動(dòng)較大的情況下,根據(jù)網(wǎng)絡(luò)帶寬條件調(diào)整碼流,使得視頻播放保持整體流暢.視頻碼率越高,視頻質(zhì)量越好,對(duì)網(wǎng)絡(luò)帶寬的消耗就會(huì)越大.因此當(dāng)弱網(wǎng)絡(luò)帶寬不足的情況發(fā)生時(shí),如果不對(duì)分辨率碼率等參數(shù)進(jìn)行調(diào)整,將會(huì)造成推流上行網(wǎng)絡(luò)的負(fù)載加大,進(jìn)而造成直播延遲.

1.1 網(wǎng)絡(luò)質(zhì)量評(píng)價(jià)

網(wǎng)絡(luò)質(zhì)量由上行網(wǎng)絡(luò)平均帶寬和平均往返時(shí)延兩個(gè)指標(biāo)確定,它們共同反映網(wǎng)絡(luò)的傳輸狀況.

上行網(wǎng)絡(luò)平均帶寬的值越大,代表網(wǎng)絡(luò)狀況越好.它的值由Jpcap[3]獲取,檢測(cè)過程如下：

(1) 獲取網(wǎng)絡(luò)接口列表：調(diào)用函數(shù)庫(kù)中的getDevice List()方法獲取本機(jī)網(wǎng)絡(luò)接口列表.

(2) 打開網(wǎng)絡(luò)接口：調(diào)用openDevice()方法對(duì)網(wǎng)絡(luò)接口進(jìn)行監(jiān)聽.設(shè)置每次最大捕獲數(shù)據(jù)包大小為65 535 Byte、開啟混雜模式接收所有類型的數(shù)據(jù)包、捕獲數(shù)據(jù)包超時(shí)時(shí)間設(shè)置為50 ms.

(3) 捕獲數(shù)據(jù)包：定義類MyPacketReceiver,它實(shí)現(xiàn)了PacketReceiver 接口,并實(shí)現(xiàn)接口中的receivePacket方法,然后調(diào)用loopPacket() 方法捕獲數(shù)據(jù)包,獲取數(shù)據(jù)包后會(huì)回調(diào)receivePacket() 方法對(duì)數(shù)據(jù)包做處理.

(4) 實(shí)時(shí)計(jì)算上行網(wǎng)絡(luò)平均帶寬：統(tǒng)計(jì)60 秒內(nèi)所捕獲的源IP 地址為視頻采集端的數(shù)據(jù)包大小,計(jì)算上行網(wǎng)絡(luò)平均帶寬.

(5) 定時(shí)任務(wù)每隔10 min 重復(fù)步驟(3)和步驟(4).

平均往返時(shí)延的值越小,代表網(wǎng)絡(luò)狀況越好.它的值可以通過java 編程語言調(diào)用cmd 命令“ping ip Address -n pingTimes -l length”獲取,ipAddress 為Ngnix-rtmp 服務(wù)器主機(jī)IP,pingTimes 為向服務(wù)器發(fā)送的請(qǐng)求個(gè)數(shù),length 為每次發(fā)送的數(shù)據(jù)包大小.

使用網(wǎng)絡(luò)模擬工具Clumsy 調(diào)整網(wǎng)絡(luò)狀況,利用上行網(wǎng)絡(luò)平均帶寬和平均往返時(shí)延兩個(gè)指標(biāo)建立了表1三種網(wǎng)絡(luò)質(zhì)量模型.

表1 網(wǎng)絡(luò)質(zhì)量模型

1.2 自適應(yīng)推流

每隔一段時(shí)間對(duì)網(wǎng)絡(luò)狀況進(jìn)行檢測(cè)評(píng)價(jià).當(dāng)網(wǎng)絡(luò)優(yōu)秀時(shí),緩慢提升采集幀率和分辨率；當(dāng)網(wǎng)絡(luò)良好時(shí),保持原狀,不改變幀率和分辨率；當(dāng)網(wǎng)絡(luò)較差時(shí),大幅降低采集幀率和視頻分辨率,自適應(yīng)過程遵循“快降慢升”的原則.網(wǎng)絡(luò)自適應(yīng)推流策略如圖1所示.

圖1 網(wǎng)絡(luò)自適應(yīng)推流策略

如表2所示為6 種推流方案所對(duì)應(yīng)的幀率和分辨率.“快降慢升”的含義即當(dāng)網(wǎng)絡(luò)狀況較差時(shí),將當(dāng)前推流方案減2.比如當(dāng)推流端按照25 Fps@1280×720 推流時(shí)檢測(cè)到網(wǎng)絡(luò)較差,大幅度降低幀率和分辨率,調(diào)整為按照15 Fps@800×600 方式推流,減小對(duì)網(wǎng)絡(luò)帶寬的壓力；當(dāng)網(wǎng)絡(luò)狀況優(yōu)秀時(shí),若當(dāng)前推流方案小于6 時(shí),則推流方案加1,若當(dāng)前推流方案為6,則保持不變.比如當(dāng)推流端按照20 FPS@1024×768 推流時(shí)檢測(cè)到網(wǎng)絡(luò)優(yōu)秀,緩慢增加幀率和分辨率,按照25 FPS@1280×720方式推流.

表2 不同推流方案對(duì)應(yīng)的幀率和分辨率

2 首幀延遲優(yōu)化

2.1 首幀延遲

直播是實(shí)時(shí)視頻流,用戶以一個(gè)隨機(jī)的時(shí)間點(diǎn)接入視頻流進(jìn)行播放,接入時(shí)第一幀幀類型若不是關(guān)鍵幀[4],此時(shí)播放緩沖區(qū)為空,解碼器無法解碼只能丟幀.播放器等到下一個(gè)關(guān)鍵幀才能播放,等待時(shí)間若大于5 秒,會(huì)影響用戶體驗(yàn).如果接入直播流時(shí)首幀正好是關(guān)鍵幀,則可以快速顯示首幀畫面.

2.2 關(guān)鍵幀緩存算法

為此,服務(wù)器對(duì)關(guān)鍵幀進(jìn)行緩存,緩存過程如下：

(1) 推流端開啟雙路推流,一路視頻流推送到服務(wù)器,一路視頻流定時(shí)推送flv 小段視頻到本地.

(2) 讀取本地最新flv 視頻小段并解析.

(3) 遍歷每一個(gè)FLV Tag[5],獲取FLV Tag header[5]的第一個(gè)字節(jié),判斷值是否為0x09 即視頻類型,若是則進(jìn)入第(4)步,否則遍歷下一個(gè)FLV Tag.

(4) 獲取Tag header 的第二到第四個(gè)字節(jié),計(jì)算視頻數(shù)據(jù)長(zhǎng)度length.

(5) 獲取Tag data 的第一個(gè)字節(jié)前4 位,若值為0001 則為關(guān)鍵幀,從第二個(gè)字節(jié)開始獲取長(zhǎng)度為length的關(guān)鍵幀數(shù)據(jù),若不是關(guān)鍵幀則遍歷下一個(gè)FLV Tag.

(6) 查看緩存隊(duì)列是否含有關(guān)鍵幀,沒有則緩存,有則更新.

(7) 播放端從服務(wù)器內(nèi)存中先請(qǐng)求關(guān)鍵幀進(jìn)行播放,再請(qǐng)求正常的視頻流.

2.3 實(shí)驗(yàn)測(cè)試及分析

由于校園網(wǎng)白天和晚上的網(wǎng)絡(luò)流量是不同的,為了檢驗(yàn)算法在不同網(wǎng)絡(luò)條件下的效果,實(shí)驗(yàn)統(tǒng)計(jì)了校園網(wǎng)白天(10：00～17：00)和晚上(19：30～23：00)兩個(gè)時(shí)間段的三種視頻分辨率(1920*1080、1280*720、800*600)下的首屏打開時(shí)間,每種視頻分辨率下,共進(jìn)行200 次點(diǎn)擊播放操作,記錄每一次從點(diǎn)擊播放到首屏畫面加載出來的時(shí)間.實(shí)驗(yàn)結(jié)果如圖2、圖3、圖4所示.

圖2 首屏打開耗時(shí)對(duì)比(視頻分辨率1920×1080)

圖3 首屏打開耗時(shí)對(duì)比(視頻分辨率1280×720)

圖4 首屏打開耗時(shí)對(duì)比(視頻分辨率800×600)

對(duì)實(shí)驗(yàn)結(jié)果進(jìn)行分析,當(dāng)視頻分辨率為1920×1080 時(shí),如圖2所示,白天和晚上,優(yōu)化前首屏打開時(shí)間均在15～25 秒左右,優(yōu)化后首屏打開平均時(shí)間,白天為3133 ms,晚上為3010 ms；視頻分辨率為1280×720 時(shí),如圖3所示,優(yōu)化前首屏打開時(shí)間在10～25 秒左右,優(yōu)化后首屏打開平均時(shí)間,白天為3241 ms,晚上為3150 ms；當(dāng)視頻分辨率為800×600 時(shí),如圖4所示,白天或晚上均在10 s 以上,優(yōu)化后白天平均首屏打開時(shí)間為2864 ms,晚上為2915 ms.首屏打開時(shí)間明顯降低,提高了接入直播畫面的速度.

此外,觀察折線圖的走勢(shì),如圖2(a)中優(yōu)化前有3 次首屏打開時(shí)間在 5000 ms 以下,圖2(b)中優(yōu)化前有2 次首屏打開時(shí)間也在5000 ms 以下,圖3～圖4中也出現(xiàn)類似的情況.這是因?yàn)橛脩粢砸粋€(gè)隨機(jī)的時(shí)間點(diǎn)接入直播流,若首幀正好是關(guān)鍵幀,則可以快速加載播放.未優(yōu)化前,進(jìn)行200 次點(diǎn)擊播放操作,僅有10 次以下能做到快速打開,具有隨機(jī)性,進(jìn)一步說明了利用關(guān)鍵幀緩存算法對(duì)首幀打開時(shí)間進(jìn)行優(yōu)化的必要性,該算法保證了首幀正好是關(guān)鍵幀,避免了首幀類型不確定所導(dǎo)致的首屏長(zhǎng)時(shí)間等待.

3 編碼延遲優(yōu)化

3.1 H.264 幀內(nèi)預(yù)測(cè)及模式選擇

H.264 中4×4 亮度塊有9 種預(yù)測(cè)模式,16×16 亮度塊和8×8 色度塊都各有4 種預(yù)測(cè)模式[6,7].每一種宏塊的幀內(nèi)預(yù)測(cè)模式選擇都是遍歷所有的預(yù)測(cè)模式,找到率失真代價(jià)值最小的模式作為最優(yōu)幀內(nèi)預(yù)測(cè)模式進(jìn)行編碼,計(jì)算復(fù)雜度較大.

3.2 x264 幀內(nèi)預(yù)測(cè)分析

x264 是開源且大規(guī)模商用的視頻編碼器[8,9],因此本文選擇x264 作為屏幕直播系統(tǒng)的實(shí)時(shí)編碼器.

H.264 標(biāo)準(zhǔn)中幀內(nèi)預(yù)測(cè)模式的選擇采用全搜索算法,計(jì)算復(fù)雜度較大.x264 針對(duì)預(yù)測(cè)模式全搜索算法做出了優(yōu)化：x264 中在對(duì)4×4 塊9 種預(yù)測(cè)模式進(jìn)行循環(huán)遍歷時(shí)采取提前終止策略,提前退出循環(huán)終止計(jì)算.以下對(duì)x264 算法的優(yōu)化即在這個(gè)基礎(chǔ)上通過減少候選模式的數(shù)量進(jìn)一步減少計(jì)算復(fù)雜度.

3.3 幀內(nèi)預(yù)測(cè)模式快速選擇算法

對(duì)于4×4 宏塊,基于圖像的紋理方向,降低候選模式的數(shù)量.具體的算法流程和代碼如下：

(1) 定義4 個(gè)視頻紋理方向0°,45°,90°,135°,用變量Angle0、Angle45、Angle90、Angle135 表示[10].

(2) 將4×4 亮度塊平均分成4 個(gè)2×2 的子塊,它們的像素按照行優(yōu)先的順序分別表示為S1、S2、S3、S4,每個(gè)像素值由其包含的4 個(gè)像素求均值得到[10].

int16_t S1=(*(p_src_by)+*(p_src_by+1)+*(p_src_by+16)+*(p_src_by+17))＞＞2；

int16_t S2=(*(p_src_by+2)+*(p_src_by+3)+*(p_src_by+18)+*(p_src_by+19))＞＞2；

int16_t S3=(*(p_src_by+32)+*(p_src_by+33)+*(p_src_by+48)+*(p_src_by+49))＞＞2；

int16_t S4=(*(p_src_by+34)+*(p_src_by+35)+*(p_src_by+50)+*(p_src_by+51))＞＞2；

其中,p_src_by=p_src+block_idx_xy_fenc[idx],p_src 為編碼幀,idx 為16 個(gè)4×4 塊的序號(hào),經(jīng)過計(jì)算得出宏塊所包含的第一個(gè)4×4 塊的左上角元素首地址即像素A 的地址p_src_by.

(3) 計(jì)算紋理系數(shù)Angle0、Angle45、Angle90、Angle135.

int16_t Angle0=abs(S2-S1)+abs(S4-S3)；

int16_t Angle45=abs(S1-S4)+abs(S4-S1)；

int16_t Angle90=abs(S1-S3)+abs(S2-S4)；

int16_t Angle135=abs(S2-S3)+abs(S3-S2)；

(4) 計(jì)算八種預(yù)測(cè)模式的紋理方向值,對(duì)應(yīng)關(guān)系如表3所示.

表3 八種預(yù)測(cè)模式對(duì)應(yīng)的紋理方向值

(5) 對(duì)紋理方向值進(jìn)行排序,選取紋理方向值最小的兩種模式作為候選模式.此外,如表4所示,四種視頻序列在實(shí)際編碼中使用頻率最高的是模式0～模式2,故將這三種模式也作為候選模式.考慮到紋理方向值最小的兩種模式可能已包含模式0 或者模式1,故最終的候選模式最少3 種,最多5 種.

(6) 對(duì)3～5 種候選模式進(jìn)行率失真代價(jià)值計(jì)算,選取值最小的預(yù)測(cè)模式為最優(yōu)的預(yù)測(cè)模式.

表4 4×4 亮度塊9 種預(yù)測(cè)模式編碼使用比例(%)

3.4 實(shí)驗(yàn)測(cè)試及分析

由于文章已實(shí)現(xiàn)了網(wǎng)絡(luò)自適應(yīng)推流,使得輸出碼率大小與網(wǎng)絡(luò)相適應(yīng),視頻編碼算法的優(yōu)化主要關(guān)注編碼速度和視頻質(zhì)量.編碼速度由編碼幀率和編碼時(shí)間來衡量,編碼幀率越大、編碼時(shí)間越短則算法效果越好.圖像客觀質(zhì)量psnr[11]值越大表示圖像質(zhì)量越好.

3.4.1 編碼參數(shù)確定

屏幕直播系統(tǒng)編碼參數(shù)設(shè)置如表5所示.

表5 屏幕直播系統(tǒng)編碼參數(shù)

3.4.2 改進(jìn)的算法實(shí)驗(yàn)對(duì)比

在屏幕直播系統(tǒng)中錄制500 幀YUV(4：2：0)格式的ppt 教學(xué)視頻,視頻特點(diǎn)是視頻變化較為平緩,局部紋理細(xì)節(jié)豐富,能代表屏幕直播系統(tǒng)中大部分應(yīng)用場(chǎng)景的視頻特點(diǎn).此外,選擇與該視頻特點(diǎn)相似的兩個(gè)官方測(cè)試序列news和highway 進(jìn)行測(cè)試.

對(duì)三種視頻序列的編碼時(shí)間變化率(△time)、編碼幀率變化率(△fps)、圖像客觀質(zhì)量變化(△psnr)進(jìn)行比較,計(jì)算方法如下：

將3 種測(cè)試序列實(shí)驗(yàn)結(jié)果按照式(1)～(3)進(jìn)行計(jì)算,最終3 種序列的測(cè)試結(jié)果如表6所示.

表6 改進(jìn)x264 算法與未改進(jìn)x264 算法比較

從實(shí)驗(yàn)結(jié)果可以看出,改進(jìn)后的x264 算法壓縮屏幕直播系統(tǒng)中的ppt 視頻序列,編碼時(shí)間下降了8.26%,編碼幀率提高了8.79%.對(duì)于官方測(cè)試序列,news 序列編碼時(shí)間下降3.74%,編碼幀率提高4.16%；highway序列編碼時(shí)間下降了21.94%,編碼幀率提高了27.9%.3 種序列視頻質(zhì)量基本沒有損失.改進(jìn)后的x264 編碼算法應(yīng)用到屏幕直播系統(tǒng)中,有效的降低了編碼時(shí)間,提高了編碼的效率.

4 系統(tǒng)延遲測(cè)試

基于以上研究,設(shè)計(jì)并實(shí)現(xiàn)屏幕直播系統(tǒng),系統(tǒng)總體架構(gòu)分為推流端、流媒體服務(wù)器、播放端、業(yè)務(wù)服務(wù)器四部分.運(yùn)行屏幕直播系統(tǒng),使用13 臺(tái)平板電腦(內(nèi)存2 GB)進(jìn)行播放,統(tǒng)計(jì)系統(tǒng)在800×600、1024×768、1280×720、1920×1080 四種分辨率下的直播延遲情況.網(wǎng)絡(luò)路由器為華為企業(yè)級(jí)路由器AR111-S,AP 為華為無線AP 3010DN-V2.推流端和服務(wù)器為筆記本電腦,CPU 配置信息為Intel(R) Core(TM)i5-3230 M,雙核2.6 Ghz,內(nèi)存為8 GB.

每隔100 幀視頻統(tǒng)計(jì)一下直播延遲,一共測(cè)試50 次共計(jì)5000 幀,將直播延遲數(shù)據(jù)實(shí)時(shí)寫入SD 卡的文本文件中,最終的實(shí)驗(yàn)結(jié)果如圖5所示.

圖5 屏幕直播系統(tǒng)在四種分辨率下的延遲測(cè)試結(jié)果

對(duì)實(shí)驗(yàn)結(jié)果進(jìn)行分析,當(dāng)推流分辨率為800×600、1024×768、1280×720 時(shí),系統(tǒng)延遲穩(wěn)定在1 s～3 s 之間.與優(yōu)化前5 s～10 s 的延遲相比,經(jīng)過優(yōu)化后的屏幕直播系統(tǒng)在1280×720 甚至更低分辨率下延遲較低,能夠滿足實(shí)際教學(xué)中課堂屏幕共享需求.對(duì)于1920×1080超清分辨率的屏幕直播,系統(tǒng)的延遲較高且隨著播放幀數(shù)增多產(chǎn)生累積延遲,出現(xiàn)延遲上升的趨勢(shì),后續(xù)工作需要進(jìn)一步研究超清視頻序列的特點(diǎn),有效地降低超清視頻直播場(chǎng)景下的系統(tǒng)延遲.

5 結(jié)論與展望

如何在現(xiàn)有直播架構(gòu)下進(jìn)行直播延遲優(yōu)化對(duì)增強(qiáng)用戶實(shí)時(shí)性體驗(yàn)有很大的現(xiàn)實(shí)意義.文章從網(wǎng)絡(luò)推流、首幀延遲、編碼延遲三個(gè)角度對(duì)直播延遲問題進(jìn)行分析和優(yōu)化,實(shí)現(xiàn)了低延遲的屏幕直播系統(tǒng),并將該系統(tǒng)應(yīng)用于課堂屏幕共享教學(xué)中,能高效實(shí)時(shí)的進(jìn)行課件展示、應(yīng)用軟件教學(xué)等操作,提高了課堂效率,具有很高的應(yīng)用價(jià)值.