戚義盛，張正華，吳 宇，蘇 權(quán)，蘇 波，趙天林，劉國澍

（1.揚州大學(xué)信息工程學(xué)院（人工智能學(xué)院），江蘇揚州 225000；2.揚州國脈通信發(fā)展有限責(zé)任公司，江蘇揚州 225000）

近年來，智能交通系統(tǒng)(ITS)飛速發(fā)展[1]，諸如電子警察、誘導(dǎo)屏等眾多交通管理設(shè)備得到廣泛應(yīng)用，而在安全監(jiān)測方面，傳統(tǒng)的人工巡查方式，工作量大且流于表象。因此，對交通管理設(shè)備實現(xiàn)高效準(zhǔn)確地監(jiān)控具有重要意義。

視頻流監(jiān)控因直觀性高、信息量大等優(yōu)點成為安全監(jiān)測系統(tǒng)的研究熱點[2]。用戶體驗QoE(Quality of Experience)通常被作為實時視頻通信的優(yōu)化目標(biāo)[3]，即更低的系統(tǒng)延遲和更高的視頻質(zhì)量。而傳統(tǒng)的遠(yuǎn)程交通視頻流傳輸系統(tǒng)，其傳輸數(shù)據(jù)量龐大，信息冗余多，常常會出現(xiàn)圖像模糊、延遲高、穩(wěn)定性差等問題。

針對以上問題，該文改進了FFmpeg 的編碼流程[4]，利用GPU 的專用硬件處理單元，實現(xiàn)宏塊（Macroblock）行級[5]的并行編碼加速處理，有效地降低了監(jiān)控系統(tǒng)整體的延遲。該文引入率失真理論（Rate Distortion Theory）模型[6]，通過率失真曲線特性來衡量和對比編碼器的性能。

1 關(guān)鍵技術(shù)

1.1 率失真理論模型

如圖1 所示，率失真曲線[7]的理論值是一條單調(diào)遞減的凸函數(shù)，D為編碼視頻的失真，R為所消耗的碼率，Rc為最大允許碼率。對于同一壓縮算法來說，雖然碼率越高，圖像質(zhì)量越好，失真越小，但同時也會占用更多存儲空間，增加了網(wǎng)絡(luò)傳輸壓力。因此，率失真曲線的理論值由碼率與失真的最佳平衡點構(gòu)成。

圖1 率失真曲線示意圖

該文從率失真優(yōu)化（Rate Distortion Optimization）的角度[8]來衡量不同編碼方案下的率失真特性。從圖1 的虛線上看，當(dāng)給定Rc時，失真D理論上最小的點落在曲線上的A點。因此，該文以特定的編碼方案，在不同的Rc下，對視頻進行編碼，計算編碼后的失真，就可以得到一個個實際可操作的R-D點，當(dāng)這些離散的R-D點擬合而成的曲線越靠近理論值的曲線時，說明率失真特性越好，即編碼的性能越高[9]。

該文采用峰值信噪比（PSNR）和結(jié)構(gòu)相似性（SSIM）視頻質(zhì)量評價指標(biāo)[10]，對編碼失真D進行量化。PSNR 值越大，表明圖像質(zhì)量越好，失真越小[11]，計算PSNR 需要先計算均方誤差（MSE），公式如下：

式中，I和K分別代表原始圖像和目標(biāo)圖像，M和N分別表示圖像的高度和寬度。則得到PSNR 的計算公式如下：

式中，MAXI是圖像的最大可能像素值。考慮到人眼的視覺特性，SSIM 算法從圖像亮度、對比度和結(jié)構(gòu)的相似性三個維度來衡量圖像質(zhì)量。取值范圍為[0,1]，值越大圖像失真越小[12]。SSIM 數(shù)學(xué)表達式如下：

式中，L(X,Y)、C(X,Y)、S(X,Y)分別為亮度、對比度和結(jié)構(gòu)的相似性，α、β、γ分別為三者的權(quán)重值。

1.2 FFmpeg多線程編碼加速

現(xiàn)在的顯卡硬件編碼是利用GPU 集成的專用硬件單元進行計算，其效率遠(yuǎn)高于通用計算，該文選用NVIDIA 的NVENC 進行多線程加速。如圖2 所示，F(xiàn)Fmpeg（Fast Forward Mpeg），一共有8 個常用庫，h264_nvenc 作為FFmpeg 硬件加速處理的API,包含在編解碼庫AVCodec 中。

圖2 FFmpeg模塊結(jié)構(gòu)圖

GPU 硬件加速的關(guān)鍵在于多線程執(zhí)行，不同于CPU，GPU 擁有眾多的計算核[13]，可以將執(zhí)行相同指令的數(shù)據(jù)合理劃分到不同的內(nèi)核上，實現(xiàn)大規(guī)模并行處理?；诒姾颂匦裕玫蕉嗑€程執(zhí)行的FFmpeg編碼流程圖，如圖3 所示。

圖3 FFmpeg編碼流程圖

FFmpeg 支持基于片（Slice）的并行算法，將每幀圖像劃分為多個Slice，同一幀的各個Slice 之間沒有數(shù)據(jù)依賴，以此為基礎(chǔ)可以實現(xiàn)并行編碼。但由于每幀的Slice 數(shù)量較少，通常僅有1～4 個，因此，Slice并行編碼的可擴展性會受到限制。該文專注于提高使用多線程編碼器的效率，所以，將宏塊行級并行化的方法應(yīng)用到開源FFmpeg 的實現(xiàn)中，直接對宏塊行實現(xiàn)并行編碼，最大化編碼的速率。宏塊行級多線程編碼流程如圖4 所示。

圖4 宏塊行級多線程編碼流程

每個GPU 核心可單獨處理同一行上所有宏塊的預(yù)測、變換、量化、反量化、反變換、去塊濾波和圖像重構(gòu)，其中預(yù)測包括幀內(nèi)預(yù)測和幀間預(yù)測[14]。為了實現(xiàn)最大加速，最佳內(nèi)核數(shù)應(yīng)等于宏塊行數(shù)。該方法將整幀圖像的最終熵編碼與預(yù)測、變換、量化、濾波等環(huán)節(jié)并行處理，同步運行，大幅度節(jié)省了CPU 計算最終熵編碼所需的時間，從而顯著提升FFmpeg 編碼器整體的計算效率，降低交通視頻流的傳輸延遲。

2 視頻流傳輸方案設(shè)計

交通視頻流監(jiān)控系統(tǒng)主要包括原始音視頻流數(shù)據(jù)采集、多線程編碼、合并推流、流媒體服務(wù)器中繼轉(zhuǎn)發(fā)、以及客戶端拉流播放等功能模塊，系統(tǒng)的總體網(wǎng)絡(luò)架構(gòu)如圖5 所示。

圖5 視頻流監(jiān)控網(wǎng)絡(luò)架構(gòu)

Nginx 是一種高性能HTTP 反向代理服務(wù)器[15]，該文采用基于RTMP（Real Time Messaging Protocol）的Nginx 服務(wù)器作為流媒體服務(wù)平臺。并采用FFmpeg 封裝音視頻數(shù)據(jù)，通過RTMP 流媒體協(xié)議以直播流的形式將數(shù)據(jù)推送出去[16]。

具體傳輸方案如下：

1）交通管理設(shè)備現(xiàn)場的攝像頭將采集的原始視頻流數(shù)據(jù)通過光纖內(nèi)網(wǎng)傳輸?shù)浇煌ūO(jiān)控中心的視頻處理服務(wù)器上；

2）將nginx-rtmp-module 模塊部署在阿里云服務(wù)器端，通過修改nginx.conf 文件，配置好RTMP 服務(wù)，實現(xiàn)RTMP 視頻數(shù)據(jù)的中繼轉(zhuǎn)發(fā)功能；

3）將基于FFmpeg 自主開發(fā)的音視頻處理軟件部署在視頻處理服務(wù)器上，通過FFmpeg 調(diào)用多線程編碼模塊，連接高性能GPU 進行并行運算[17]。最后對壓縮后的多路視頻流進行合并和封裝，并通過單路推流至具有公網(wǎng)IP 的Nginx 云服務(wù)器端；

4）PC 端和移動端均可使用支持拉流和解碼的軟件，從Nginx 服務(wù)器獲取視頻流，實現(xiàn)對交通管理設(shè)備的實時監(jiān)控。

3 系統(tǒng)集成測試

3.1 基本功能實現(xiàn)

基于FFmpeg 開源庫編寫的音視頻處理軟件，編譯環(huán)境為Visual Studio 2019，使用QT15.5 搭建軟件界面，以方便交通監(jiān)控中心進行場景選擇和推流設(shè)置。軟件界面如圖6 所示。

圖6 軟件界面

Nginx 流媒體服務(wù)搭建完成后，可在Windows 端打開并運行，輸入推流地址，點擊“開始推流”按鈕，軟件通過h264_nvenc 自動調(diào)用GPU 多線程編碼，封裝多路視頻流并推送至Nginx 服務(wù)器。

監(jiān)控系統(tǒng)的播放測試結(jié)果如圖7 所示。系統(tǒng)支持PC 端和移動端兩種用戶播放方式，均可使用PotPlayer 拉流播放。輸入拉流地址，鏈接到Nginx 服務(wù)器后，即可實現(xiàn)交通視頻監(jiān)控，經(jīng)測試，系統(tǒng)滿足設(shè)計之初的基本需求，完成了整個視頻流數(shù)據(jù)的傳輸通道，監(jiān)控?zé)o卡頓、畫質(zhì)清晰。

圖7 PC端及移動端測試結(jié)果

3.2 系統(tǒng)性能測試

為了更好地對比GPU 宏塊級多線程編碼和傳統(tǒng)CPU 軟件編碼的性能。該文重點對監(jiān)控系統(tǒng)的畫質(zhì)、延遲、穩(wěn)定性進行測試。

在編碼質(zhì)量方面，根據(jù)1.1 節(jié)中對率失真理論模型的分析，該文分別采用PSNR 和SSIM 作為視頻質(zhì)量指標(biāo)來繪制“碼率-質(zhì)量”曲線，即R-D 曲線，用來比較編碼性能和畫質(zhì)表現(xiàn)。

在編碼效率方面，使用加速比作為性能指標(biāo)，計算公式如下：

式中，Ts表示libx264(CPU)的運行時間，Tp表示h264_nvenc(GPU)的運行時間，SP 表示加速比。該文選用6 個不同的YUV 視頻序列作為測試樣本。測試序列信息如表1 所示。

表1 測試序列基本信息

實驗運行在Windows 10操作系統(tǒng)上，CPU型號為AMD Ryzen 75800H，3.20 GHz，GPU 型號為NVIDIA RTX 3070，其中，GPU 一共包含2 944 個流處理器。

為得到不同視頻壓縮碼率下的PSNR 值和SSIM值，該文通過FFmpeg 編碼模式中的恒定量化器模式（Constant Quantizer）來實現(xiàn)壓縮碼率從低到高的控制，該模式通過設(shè)定qp 值（0～51 的數(shù)字）來量化畫質(zhì)，其中，51 代表最低畫質(zhì)，對應(yīng)最低碼率，0 代表最高畫質(zhì)，對應(yīng)最高碼率。根據(jù)式（2）和式（3）將不同qp 值下編碼得到的有損文件，通過FFmpeg 命令與原始文件進行比對運算，即可得到PSNR 和SSIM。

該文選取幀數(shù)最多的life.yuv 測試序列，分別使用CPU（libx264）和GPU 多線程(h264_nvenc)進行編碼，并選取12 個典型的qp 值進行測試，得到由低到高各自對應(yīng)的12 組“碼率-PSNR 值”和12 組“碼率-SSIM 值”。根據(jù)率失真理論，這些“碼率-質(zhì)量”的數(shù)據(jù)組由實際的R-D點組成，再使用Matlab 獲取所有R-D點構(gòu)成的坐標(biāo)，擬合出“碼率-質(zhì)量”的率失真曲線，如圖8-9 所示。

圖8 碼率-質(zhì)量（PSNR）曲線

分析圖8 可以發(fā)現(xiàn)h264_nvenc 的率失真特性總體優(yōu)于libx264，直到碼率達到約18 000 kbps 時，libx264 的PSNR 值才追平h264_nvenc。分析圖9 同樣發(fā)現(xiàn)，當(dāng)碼率小于22 000 kbps 時，h264_nvenc 的SSIM 值更高，即失真會更小。而對于幀率為30 fps的1 080P 視頻流，碼率的需求一般在4 000～8 000 kbps 之間。因此，在相同碼率輸出的要求下，該文的加速編碼方案編碼質(zhì)量并未降低，而且畫質(zhì)有小幅度的提升，失真更小。

圖9 碼率-質(zhì)量（SSIM）曲線

為得到編碼消耗的時間，該文通過PowerShell 來分別調(diào)用FFmpeg 中的libx264 和h264_nvenc 編碼器，對6 個幀率均為30 fps 的YUV 文件分別進行編碼，通過“-b:v 8000k”命令，固定壓縮碼率為8 000 kbps，然后進行測試，記錄編碼時間，計算加速比SP，以此來對比開啟GPU 多線程編碼前后的編碼效率，測試結(jié)果如表2 所示。

表2 編碼效率和加速比

分析表2可知，Ts均明顯高于Tp，說明h264_nvenc多線程編碼的表現(xiàn)遠(yuǎn)好于libx264，視頻分辨率1 080 P 和720 P 的平均加速比分別達到了4.11 和3.74。雖然分辨率越高，相同幀數(shù)的視頻消耗時間也會越多，但是GPU 多線程編碼的加速優(yōu)勢卻更明顯，例如601 幀720 P 的序列FourPeople 加速編碼消耗時間為1 189 ms，而760 幀1 080 P 的序列red_kayak 消耗了2 213 ms，時間更長，但是加速比卻從3.68 提高到了4.12。

然后測試整個監(jiān)控系統(tǒng)的延遲，即推流端發(fā)送數(shù)據(jù)到收流端播放數(shù)據(jù)所需要的時間。該文對啟用FFmpeg 多線程編碼前后，分別進行100 次系統(tǒng)延遲測試。

傳統(tǒng)CPU編碼的測試結(jié)果如圖10所示，系統(tǒng)延遲在2 500～2 580 ms之間波動，平均延遲為2 540.93 ms。

圖10 CPU編碼的測試結(jié)果

調(diào)用h264_nvenc 多線程加速編碼后的測試結(jié)果如圖11 所示，系統(tǒng)延遲明顯降低，波動范圍在801～892 ms 之間，且始終維持在1 s 以內(nèi)，平均延遲為845.10 ms。

圖11 GPU多線程加速后的測試結(jié)果

根據(jù)對圖10 和圖11 的分析，系統(tǒng)的平均延遲降低了近1.7 s，并最終控制在1 s 以內(nèi)，監(jiān)控的實時性得到了大幅度增強。

最后，測試系統(tǒng)的穩(wěn)定性，記錄交通監(jiān)控系統(tǒng)在長期工作運行下的狀態(tài)。該文的直播視頻流輸出設(shè)置分辨率為1 080 P，碼率為8 000 kbps，幀率為30 fps。測試得到的系統(tǒng)平均延遲和丟包率如表3所示。

表3 系統(tǒng)穩(wěn)定性測試結(jié)果

測試結(jié)果表明，監(jiān)控系統(tǒng)可持續(xù)正常工作，且沒有因延遲而出現(xiàn)幀丟失或跳過的情況，因為該文使用的RTMP 是基于底層可靠的TCP 協(xié)議建立的連接，不會存在丟包現(xiàn)象。24 h 連續(xù)測試后，系統(tǒng)的平均延遲依然穩(wěn)定，可以滿足智能交通背景下長期穩(wěn)定的監(jiān)控需求。

4 結(jié)束語

該文基于FFmpeg 設(shè)計的視頻流傳輸系統(tǒng)，成功實現(xiàn)了對交通管理設(shè)備的實時監(jiān)控。市場上的視頻流傳輸方式，大多是以犧牲視頻質(zhì)量為代價換取較低延遲，或者以傳輸時延過大為前提，提高視頻質(zhì)量。

該系統(tǒng)采用多線程加速編碼的方法，在提高編碼速度，有效降低系統(tǒng)延遲的前提下，依然保持了優(yōu)秀的率失真特性，保證了視頻的高質(zhì)量傳輸。經(jīng)測試，系統(tǒng)整體傳輸延遲控制在1 s 以內(nèi)，實時性高，且十分穩(wěn)定。

下一步將繼續(xù)研究Nginx 流媒體分發(fā)環(huán)節(jié)和解碼播放環(huán)節(jié)的延遲優(yōu)化，進一步降低系統(tǒng)的最終傳輸延遲。