付鵬斌,任 衡,楊惠榮

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

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

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

1 網絡自適應推流

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

1.1 網絡質量評價

網絡質量由上行網絡平均帶寬和平均往返時延兩個指標確定,它們共同反映網絡的傳輸狀況.

上行網絡平均帶寬的值越大,代表網絡狀況越好.它的值由Jpcap[3]獲取,檢測過程如下：

(1) 獲取網絡接口列表：調用函數庫中的getDevice List()方法獲取本機網絡接口列表.

(2) 打開網絡接口：調用openDevice()方法對網絡接口進行監(jiān)聽.設置每次最大捕獲數據包大小為65 535 Byte、開啟混雜模式接收所有類型的數據包、捕獲數據包超時時間設置為50 ms.

(3) 捕獲數據包：定義類MyPacketReceiver,它實現了PacketReceiver 接口,并實現接口中的receivePacket方法,然后調用loopPacket() 方法捕獲數據包,獲取數據包后會回調receivePacket() 方法對數據包做處理.

(4) 實時計算上行網絡平均帶寬：統(tǒng)計60 秒內所捕獲的源IP 地址為視頻采集端的數據包大小,計算上行網絡平均帶寬.

(5) 定時任務每隔10 min 重復步驟(3)和步驟(4).

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

使用網絡模擬工具Clumsy 調整網絡狀況,利用上行網絡平均帶寬和平均往返時延兩個指標建立了表1三種網絡質量模型.

表1 網絡質量模型

1.2 自適應推流

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

圖1 網絡自適應推流策略

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

表2 不同推流方案對應的幀率和分辨率

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

2.1 首幀延遲

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

2.2 關鍵幀緩存算法

為此,服務器對關鍵幀進行緩存,緩存過程如下：

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

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

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

(4) 獲取Tag header 的第二到第四個字節(jié),計算視頻數據長度length.

(5) 獲取Tag data 的第一個字節(jié)前4 位,若值為0001 則為關鍵幀,從第二個字節(jié)開始獲取長度為length的關鍵幀數據,若不是關鍵幀則遍歷下一個FLV Tag.

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

(7) 播放端從服務器內存中先請求關鍵幀進行播放,再請求正常的視頻流.

2.3 實驗測試及分析

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

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

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

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

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

此外,觀察折線圖的走勢,如圖2(a)中優(yōu)化前有3 次首屏打開時間在 5000 ms 以下,圖2(b)中優(yōu)化前有2 次首屏打開時間也在5000 ms 以下,圖3～圖4中也出現類似的情況.這是因為用戶以一個隨機的時間點接入直播流,若首幀正好是關鍵幀,則可以快速加載播放.未優(yōu)化前,進行200 次點擊播放操作,僅有10 次以下能做到快速打開,具有隨機性,進一步說明了利用關鍵幀緩存算法對首幀打開時間進行優(yōu)化的必要性,該算法保證了首幀正好是關鍵幀,避免了首幀類型不確定所導致的首屏長時間等待.

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

3.1 H.264 幀內預測及模式選擇

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

3.2 x264 幀內預測分析

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

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

3.3 幀內預測模式快速選擇算法

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

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

(2) 將4×4 亮度塊平均分成4 個2×2 的子塊,它們的像素按照行優(yōu)先的順序分別表示為S1、S2、S3、S4,每個像素值由其包含的4 個像素求均值得到[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 個4×4 塊的序號,經過計算得出宏塊所包含的第一個4×4 塊的左上角元素首地址即像素A 的地址p_src_by.

(3) 計算紋理系數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) 計算八種預測模式的紋理方向值,對應關系如表3所示.

表3 八種預測模式對應的紋理方向值

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

(6) 對3～5 種候選模式進行率失真代價值計算,選取值最小的預測模式為最優(yōu)的預測模式.

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

3.4 實驗測試及分析

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

3.4.1 編碼參數確定

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

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

3.4.2 改進的算法實驗對比

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

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

將3 種測試序列實驗結果按照式(1)～(3)進行計算,最終3 種序列的測試結果如表6所示.

表6 改進x264 算法與未改進x264 算法比較

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

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

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

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

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

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

5 結論與展望

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