基于FFmpeg 多線程編碼的智能交通監控系統設計

戚義盛，張正華，吳 宇，蘇 權，蘇 波，趙天林，劉國澍

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

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

視頻流監控因直觀性高、信息量大等優點成為安全監測系統的研究熱點[2]。用戶體驗QoE(Quality of Experience)通常被作為實時視頻通信的優化目標[3]，即更低的系統延遲和更高的視頻質量。而傳統的遠程交通視頻流傳輸系統，其傳輸數據量龐大，信息冗余多，常常會出現圖像模糊、延遲高、穩定性差等問題。

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

1 關鍵技術

1.1 率失真理論模型

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

圖1 率失真曲線示意圖

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

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

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

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

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

1.2 FFmpeg多線程編碼加速

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

圖2 FFmpeg模塊結構圖

GPU 硬件加速的關鍵在于多線程執行，不同于CPU，GPU 擁有眾多的計算核[13]，可以將執行相同指令的數據合理劃分到不同的內核上，實現大規模并行處理。基于眾核特性，得到多線程執行的FFmpeg編碼流程圖，如圖3 所示。

圖3 FFmpeg編碼流程圖

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

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

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

2 視頻流傳輸方案設計

交通視頻流監控系統主要包括原始音視頻流數據采集、多線程編碼、合并推流、流媒體服務器中繼轉發、以及客戶端拉流播放等功能模塊，系統的總體網絡架構如圖5 所示。

圖5 視頻流監控網絡架構

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

具體傳輸方案如下：

1）交通管理設備現場的攝像頭將采集的原始視頻流數據通過光纖內網傳輸到交通監控中心的視頻處理服務器上；

2）將nginx-rtmp-module 模塊部署在阿里云服務器端，通過修改nginx.conf 文件，配置好RTMP 服務，實現RTMP 視頻數據的中繼轉發功能；

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

4）PC 端和移動端均可使用支持拉流和解碼的軟件，從Nginx 服務器獲取視頻流，實現對交通管理設備的實時監控。

3 系統集成測試

3.1 基本功能實現

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

圖6 軟件界面

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

監控系統的播放測試結果如圖7 所示。系統支持PC 端和移動端兩種用戶播放方式，均可使用PotPlayer 拉流播放。輸入拉流地址，鏈接到Nginx 服務器后，即可實現交通視頻監控，經測試，系統滿足設計之初的基本需求，完成了整個視頻流數據的傳輸通道，監控無卡頓、畫質清晰。

圖7 PC端及移動端測試結果

3.2 系統性能測試

為了更好地對比GPU 宏塊級多線程編碼和傳統CPU 軟件編碼的性能。該文重點對監控系統的畫質、延遲、穩定性進行測試。

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

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

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

表1 測試序列基本信息

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

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

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

圖8 碼率-質量（PSNR）曲線

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

圖9 碼率-質量（SSIM）曲線

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

表2 編碼效率和加速比

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

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

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

圖10 CPU編碼的測試結果

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

圖11 GPU多線程加速后的測試結果

根據對圖10 和圖11 的分析，系統的平均延遲降低了近1.7 s，并最終控制在1 s 以內，監控的實時性得到了大幅度增強。

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

表3 系統穩定性測試結果

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

4 結束語

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

該系統采用多線程加速編碼的方法，在提高編碼速度，有效降低系統延遲的前提下，依然保持了優秀的率失真特性，保證了視頻的高質量傳輸。經測試，系統整體傳輸延遲控制在1 s 以內，實時性高，且十分穩定。

下一步將繼續研究Nginx 流媒體分發環節和解碼播放環節的延遲優化，進一步降低系統的最終傳輸延遲。