基于動態策略的網絡視頻監控系統

劉曉妮，盧奕南，潘 明，袁天文

（吉林大學 計算機科學與技術學院，長春130012）

0 引 言

隨著社會的進步，網絡視頻監控越來越被廣泛地應用到各個領域。文獻［1］提出了一個基于改進的H.264的視頻監控系統。目前主要通過縮小預測模式選擇范圍［2］的方式降低幀內預測模式選擇算法復雜度。文獻［3］通過宏塊的邊緣點預測邊緣方向，在幀內預測模式中，選擇與該預測方向相同的模式。文獻［4］首先根據預測方向進行分組，通過先計算出來的分組率失真和幀內預測方向的相關性，對剩余的預測方向中可能性小的模式不再計算，從而降低算法的復雜度。同時，很多學者對基于TCP的網絡多媒體也進行了大量的研究和改進［5］，林志勇等［6］分析了3G 網絡視頻傳輸中引入自適應調整碼率的必要性，提出了一種基于改進的AIMD 算法來調整視頻碼率的流量控制算法。左冬紅［7］提出了一種面向TCP流媒體傳輸的編碼碼率自適應算法（TCP＿RA），該算法根據流媒體發送應用層緩沖區讀寫指針差值調整流媒體發送端的編碼碼率適應網絡帶寬的變化。廖順和［8］探討了視頻監控系統在城市軌道交通安全等領域的應用，并重點介紹了H.264編碼標準和碼率控制基本原理。

本文采用動態策略，基于宏塊特征，實現幀內預測模式的動態選擇，并且分析網絡狀況信息，計算當前網絡支持的最大傳輸碼率，自適應地調整服務器的輸出碼率，從而提高編碼效率以及網絡的利用率。

1 關鍵技術

1.1 幀內預測模式的動態選擇算法

1.1.1 幀內預測模式

幀內預測是利用當前待編碼宏塊周圍的已編碼并重建的宏塊預測當前宏塊的值。亮度塊幀內預測根據亮度塊大小分為16×16和4×4兩種。

16×16亮度預測模式包括4 種不同的預測模式。如圖1所示，垂直預測模式是通過上一行的像素點得到待編碼宏塊的像素值；水平預測模式通過左一列的像素得到宏塊的像素值；DC 直流預測模式通過上一行和左一列的像素均值得到宏塊的像素點；平面預測模式利用“plane”函數、左一列像素點及上一行像素點得到宏塊的像素點［9］。

圖1 16×16亮度預測模式Fig.1 Brightness of 16×16prediction model

4×4亮度預測模式由8 種不同方向的預測模式和DC 直流預測模式組成［9］。圖2為除DC預測外的8種預測模式的方向。

圖2 4×4預測模式的8種不同方向Fig.2 4×4prediction of 8different directional patterns

1.1.2 動態選擇算法

采用基于宏塊特征和縮減預測模式選擇范圍的思想，實現幀內預測模式選擇速度的提升。首先根據宏塊特征對4種不同的16×16亮度預測模式進行判斷，選出能夠滿足宏塊特征的16×16幀內預測模式。如果沒有能夠滿足的，根據宏塊特征選擇合適的4×4亮度預測模式候選集，最后根據遍歷候選集中的亮度預測模式，求得最適宜的亮度預測模式。

本文對宏塊特征的計算受到了文獻［10，11］的啟發。對4種不同的16×16亮度預測模式分別進行分析，垂直預測模式計算待編碼宏塊的像素點在垂直方向上的平滑度，這里采用方差來衡量平滑程度：

式中：p（x，y）為宏塊（x，y）處的像素值；my為宏塊第y 列像素點的均值。

水平預測模式計算水平方向上的平滑度為：

式中：mx為宏塊第x 行像素點的均值。

DC預測模式計算宏塊整體的平滑度為：

式中：mxy為宏塊的所有像素點的均值。

平面預測模式適用于水平或垂直方向有傾斜紋理的圖像。這里分別使用兩條對角線及周圍的像素點的方差來預測平面模式的適用程度，公式為：

式中：ml為宏塊左上到右下對角線上像素點的平均值；mx0為宏塊從（x，0）點出發到底邊的與對角線平行的斜線上像素點的平均值；m0x為宏塊從（0，x）點出發到底邊的與對角線平行的斜線上像素點的平均值。

式中：mr為宏塊右上到左下對角線上像素點的平均值；m′x0為宏塊（15－x，0）點出發到上邊的與對角線平行的斜線上像素點的平均值；m′0x為宏塊從（0，x）點出發到上邊的與對角線平行的斜線上像素點的平均值。

得到4種16×16的亮度預測模式的宏塊特征的計算公式之后，需要確定閾值來決定該16×16亮度預測模式是否適用，并且確定采用何種具體模式，即依次比較var＿dc、var＿v、var＿h與三個閾值大小來確定DC、垂直和水平三種模式之一。對于平面模式的選擇，是進一步地將var＿l、var＿r與兩個閾值比較大小，滿足其中一個條件就可以確定。若16×16模式不適用，則在4×4亮度預測模式候選組中選擇開銷最小的亮度預測模式作為最佳模式。通過比較4 個候選組｛0，5，7，2｝、｛1，6，8，2｝、｛4，5，6，2｝、｛3，7，8，2｝對應的var＿v、var＿h、var＿l和var＿r值，選擇值最小的對應組作為候選組。

由于16×16的預測方向在4×4中同樣會進行預測，僅選擇可能性較高的模式作為當前塊的候選模式，這樣可以在很大程度上減少幀內模式的計算量。采用16×16預測模式中的預測方向對4×4預測模式進行分組，同時根據16×16的結果在4×4的預測模式中選出一組預測模式作為候選組，再在候選組中選出最佳的預測模式即可。由于DC預測是在任何條件下都能使用的預測模式［2］，于是將DC 預測加入到所有組中。接下來直接使用X264中提供的方法計算候選分組中的各個模式的代價，選擇出代價最低的預測模式作為最佳預測模式。

1.2 基于網絡狀況的碼率自適應算法

1.2.1 傳輸速率調整方式

目前，根據網絡狀況進行傳輸速率調整的方法主要包括基于試探和基于預測兩種［12］。由于基于試探的傳輸速率調整方式在網絡狀態發生改變時速率改變過大，會引起比較明顯的網絡波動，對實時性要求較高的視頻數據的傳輸非常不利，所以本文選擇基于預測的傳輸速率調整方式作為擁塞避免階段的碼率自適應方法。這種方法主要根據網絡模型，使用預測公式來預測網絡的有效帶寬。當前應用最廣泛的是文獻［13］中提出的計算公式，如下：

式中：br 為傳輸速率；RTT 為往返時間；RTO 為重傳間隔，取4 倍的往返時間；Ploss為丟包率；PacketSize為發送的數據包的大小。

1.2.2 碼率自適應算法

本算法所需參數主要依靠由接收端周期性向發送端發送的接收端報告RR 數據包。RR 包是RTCP數據包的一種，其中包含了間隔抖動、已接收報告數、累計丟包數等重要參數。服務器根據這些參數計算檢測當前網絡狀況，并根據檢測結果進行碼率的自適應調整。本文的碼率自適應算法主要使用丟包率Ploss和傳輸的往返時間RTT。

計算丟包率Ploss首先需要獲取RR 數據包中的fraction lost字段，并將該字段數值除以256。往返時間RTT 的計算公式如下：

式中：T＿rev 為接收到該RR 包的時間；LSR 為RR 包中最新SR 的時間戳；DLSR 為從最新SR到發送RR 的時間間隔。

基于網絡狀況的碼率自適應是為了避免網絡擁塞，而TCP協議對于網絡擁塞進行的控制算法又是成熟而且得到實踐檢驗的，所以本文受到TCP協議的啟發，對數據傳輸過程細化為慢啟動和擁塞避免兩個階段。

（1）慢啟動階段。在此階段，將TCP 協議的慢啟動思想應用到監控視頻開始的傳輸階段。通過量化參數QP 的動態改變來實現碼率的調整。QP 值越大，碼率越小，圖像的質量越差，從圖像質量和性價比的角度考慮，設置QP＿MAX 和QP＿MIN 為量化參數最大值和最小值。

首先初始化QP ＝QP＿MAX，然后根據RTCP包反饋的丟包率Ploss進行操作選擇。當Ploss＝0時，使用公式：

進行QP 的調整（QP′為QP 的均值，τ為參數），由于QP 越大，發送到網絡上進行傳輸的視頻數據量越少，網絡狀況也就越好，QP 的變化速度在QP 越大的情況要快一些，所以設定的QP 變化公式中隨著QP 值變小，QP 變化速度是減慢的。否則，QP 不變，統計接下來連續5個RR 包中有3個丟包率非0或者QP 減小到QP＿MIN，則進入擁塞避免階段。

（2）擁塞避免階段。當本算法碼率與網絡帶寬達到適應后，進入到擁塞避免階段。根據網絡狀況的變化進行碼率的自適應調整。

首先，根據求出的傳輸速率br 可計算得到當前網絡狀況滿足的起始幀量化參數start＿qp［14］：

式中：a、b、c為常系數。

再根據start＿qp 和THR 對QP 的值進行調整，當start＿qp＜QP－THR 時，說明網絡處于輕載狀態，需要降低量化值，QP 取start＿qp 和QP＿MIN 中較大值。當start＿qp ＞QP ＋THR時，說明當前網絡處于過載的狀態，需要提高量化值，QP 取start＿qp 和QP＿MAX 中較小值。

當QP－THR ≤start＿qp ≤QP＋THR 時，說明網路處于滿載狀態，無需改變編碼量化值。其中，THR 是調整QP 的閾值。設置THR 的計算公式為：

式中：κ為參數。

從式（8）可以看出，當丟包率為0時，無法預測網絡的有效帶寬，所以當本系統收到第一個丟包率為0的包，量化參數不變，當收到后面連續丟包率為0的RR 數據包，再收到后續的丟包率為0的RTCP包后，則利用式（10）減小QP 的數值，從而提高網絡帶寬的利用率。

2 網絡視頻監控系統結構

本系統采用C／S 架構，主要由攝像頭、服務器以及分別用于Windows系統和Android系統的客戶端組成，如圖3所示。

圖3 網絡視頻監控系統結構圖Fig.3 Structure diagram of network video monitoring system

首先，服務器驅動攝像頭讀取監控視頻，然后服務器對監控視頻進行壓縮編碼處理；當存在客戶端通過RTSP 協議與服務器建立連接且向服務器發送了監控視頻播放請求時，服務器通過RTP協議向客戶端發送視頻數據，客戶端接收到視頻數據后進行解碼播放；在連接已建立期間，服務器與客戶端周期性地相互發送RTCP包，使兩端都能了解到當前的網絡狀況，本文根據這些網絡狀況信息對編碼器的輸出碼率進行調整，實現基于網絡狀況的碼率自適應調整。

3 系統各功能模塊的實現

3.1 服務器的設計實現

本系統服務器主要包括4個部分，如圖4所示。

圖4 系統服務器結構Fig.4 Structure diagram of system server

首先，服務器利用Linux關于視頻設備內核驅動V4L2（video4linux2）提供的接口，編寫驅動程序驅動攝像頭讀取視頻數據，再對視頻數據進行壓縮編碼；由于本系統編碼器是基于開源的H.264編碼器X264實現的，且X264要求輸入的視頻每幀圖像都為YUV420格式，所以在編碼前需要將讀入的YUYV 圖像格式視頻數據轉換成YUV420。然后，將轉換X264 分別對每幀YUV420格式的圖像進行編碼，編碼后即可得到標準H.264格式的視頻數據。將編碼后的視頻數據保存到服務器中作為回放的視頻數據，同時在有用戶請求實時監控視頻時，通過開源流媒體服務器Live555將內存中的視頻數據用于發送給用戶。

X264和Live555作為開源的解決方案面向的對象是視頻文件，而本系統需要實現的是實時視頻數據的處理，所以本系統對它們的輸入部分分別進行了修改。同時由于這兩個開源項目是相互獨立的，而本系統需要它們作為服務器整體的兩個部分，所以本系統通過多線程的方式對它們的工作過程進行調整，使用外部變量將使Live555能夠獲得X264編碼后的視頻數據。

3.2 客戶端的設計實現

本系統客戶端以開源項目VLC 為基礎，同時實現了Windows和Android兩個平臺下的客戶端播放器。首先對VLC 進行編譯，生成可調用的庫文件，然后通過調用VLC 庫函數實現客戶端的整體功能。

Windows系統下VLC播放器的編譯需要在由Cygwin仿真得到的Linux 環境下進行，圖5為編譯過程。

圖5 Windows系統下VLC編譯過程Fig.5 VLC compilation process in Windows system

圖5 中第4 步需要清理的第三方庫提供的Linux可執行文件都位于／usr／win32／bin文件夾中，它們是moc、rcc和uic。第5步中源碼和第三方 庫 存 放 的 位 置 為／cygwin／home／username（username為登陸的用戶目錄）。經過最后一步make package－win32－base后，即可得到客戶端實現 所 需 的 動 態 庫 文 件libvlc.dll、axvlc.dll、libvlccore.dll和npvlc.dll，同時還生成了VLC的插件庫。

對于本系統中Windows系統下的客戶端的實現，首先需要創建一個MFC 的工程；然后，將VLC的核心庫、插件庫以及客戶端實現所需的頭文件都加入到項目中；接下來即可基于VLC 和MFC進行代碼實現。

客戶端的代碼實現過程如下：

（1）調用libvlc＿new 函數創建并初始化一個libvlc對象。

（2）調用libvlc＿media＿new＿path 函數根據libvlc對象和媒體路徑（可以是多媒體文件的文件存儲路徑，也可以是流媒體文件的網絡路徑，如：rtsp：／／192.168.3.111／test.264）創建可播放的媒體對象。

（3）調用libvlc＿media＿player＿new 函數，根據libvlc對象創建播放器對象。

（4）調用libvlc＿media＿player＿set＿media函數，將播放器對象與媒體對象進行連接。

（5）獲取播放窗口的句柄，調用libvlc＿media＿player＿set＿hwnd將播放器對象與播放窗口進行關聯。

（6）調用libvlc＿media＿player＿play函數，發送播放命令，接收視頻數據進行播放。

以上就是基于VLC實現Windows系統下客戶端的主要步驟，并且這些步驟有嚴格的先后順序。

4 實驗結果及分析

將未被修改的X264編碼器與采用幀內預測編碼算法的編碼器進行編碼性能對比，選定峰值信噪比、編碼速度和輸出碼率作為性能對比參數。ΔPSNR 為峰值信噪比增量百分比，ΔV 為編碼速度增量百分比，ΔBR 為輸出碼率增量百分比，公式如下：式中：old和new 分別表示未被修改的X264編碼器和采用本文算法修改的編碼器得到的數據。

測試用例選用5 個常用于測試的CIF 格式視 頻 序 列，包 括bridge－cif.yuv、coastguard－cif.yuv、hall－cif.yuv、highway－cif.yuv、silent－cif.yuv。本次測試將編碼的量化參數設置為跨度適中且能較好地反映編碼器性能變化的3個值：20，30，40，同時設置QP＿MAX ＝45，QP＿MIN ＝25，τ＝1.5，κ＝20。

從表1可以看出：本文的幀內預測模式選擇算法在編碼速度上提升明顯，而編碼質量和輸出碼率都只受到了比較小的影響。

在不同網絡帶寬狀況下，將無碼率自適應算法與本文基于網絡狀況的碼率自適應算法進行碼率對比。該測試在同一個內網下的兩臺計算機上進行，因此網絡狀況可以得到保障。本文對采用碼率自適應算法的服務器與使用固定編碼量化參數分別為25、35和45的服務器輸出碼率的狀況進行了對比。同時，在第75、130、175s三個時間點，將網絡的流量限制分別設置為1000、500、1000kbit／s，測試在網絡狀況發生變化時本文的碼率自適應算法的響應情況。

表1 量化參數為20、30和40的性能比較結果Table 1 Performance comparison results of quantization parameter 20，30and 40

如圖6所示，本文算法能夠較快地達到較高的傳輸速率，同時對網絡狀況的變化反應也能夠較快地做出回應。在慢啟動階段，由于有足夠的網絡帶寬支持，本文算法能夠較快地得到量化值的下限，然后進入擁塞避免階段。在擁塞避免階段，對于網絡帶寬迅速下降和上升，本文算法都能做出較快的反應。

圖6 碼率自適應算法與固定編碼質量的傳輸速率對比Fig.6 Transmission rate comparison between rate adaptive and fixed coding quality algorithms

5 結束語

本文結合H.264視頻編碼技術和RTSP 協議等流媒體技術，實現了網絡視頻監控系統。針對編碼效率和網絡資源合理化利用的兩點不足，提出了幀內預測模式的動態選擇算法策略和基于網絡狀況的碼率自適應策略。實驗結果驗證了方案的可行性，并收到了較好的監控效果，實現了網絡視頻監控。

［1］毛劍飛，張杰，蔣莉，等.基于改進的H.264的視頻監控系統［J］.計算機系統應用，2014，23（4）：84－90.Mao Jian－fei，Zhang Jie，Jiang Li，et al.Video monitoring system based on improved H.264［J］.Computer Systems ＆Applications，2014，23（4）：84－90.

［2］李豐娟.H.264／AVC 編碼標準模式選擇快速算法研究［D］.重慶：重慶大學通信與信息系統學院，2010.Li Feng－juan.Study on fast mode selection algorithm for the coding standard H.264／AVC［D］.Chongqing：Communication and Informantion System Institute，Chongqing University，2010.

［3］Pan Feng，Lin Xiao，Susanto R，et al.Fast mode decision for intra prediction［C］∥Joint VideoTeam（JVT）Go13，7th Meeting：PattayaII，Thailand，2003.

［4］Cheng C C，Chang T S.Fast here step intra prediction algorithm for 4×4blocks in H.264［J］.ISCAS，2005，2（5）：1509－1512.

［5］Huang Y X，Huang G.Adaptive AIMD rate control for smooth multimedia streaming［C］∥IEEE the 12th International Conference on Computer Communications and Networks，Dallas，TX，2003：171－177.

［6］林志勇，葉樺，孫曉潔，等.3G 視頻傳輸中碼率自適應調整算法［J］.東南大學學報：自然科學版，2012，42（1）：45－50.Lin Zhi－yong，Ye Hua，Sun Xiao－jie，et al.Adaptive bitrate adjustment algorithm of video transmission based on 3Gnetwork［J］.Journal of Southeast University（Natural Science Edition），2012，42（1）：45－50.

［7］左冬紅.面向TCP 的流媒體傳輸編碼碼率自適應算法［J］.中國圖象圖形學報，2011，16（4）：510－515.Zuo Dong－hong.An algorithm for encoding rate adaptive streaming media transmitting based on TCP［J］.Journal of Image and Graphics，2011，16（4）：510－515.

［8］廖順和.H＿264在城市軌道交通視頻監控中碼率控制的研究［D］.上海：東華大學計算機應用技術學院，2008.Liao Shun－he.The research of H.264rate Control in video surveillance for urban rail transportation［D］.Shanghai：Applied Computer Technology Institute，Donghua University，2008.

［9］劉碩.H.264／AVC 編碼算法的若干關鍵技術研究［D］.上海：上海交通大學電子信息與電氣工程學院，2009.Liu Shuo.Investigations on key techniques of H.264／AVC encoder［D］.Shanghai：School of Electronic Information and Electrical Engineering，Shanghai Jiaotong University，2009.

［10］張久玲，練秋生.利用宏塊特征的H.264／AVC 快速幀內模式決策［J］.計算機工程與應用，2012，48（14）：190－194.Zhang Jiu－ling，Lian Qiu－sheng.Fast intra mode decision for H.264／AVC using features of macro block［J］.Computer Engineering and Applications，2012，48（14）：190－194.

［11］牛平宏.面向實時壓縮的H.264 優化研究［D］.西安：西安電子科技大學計算機應用技術學院，2006.Niu Ping－hong.Researches on H.264encoder optimization for real time compression［D］.Xi＇an：Applied Computer Technology Institute，Xidian University，2006.

［12］于溯，盛彥瑾，黃凱，等.RTP 自適應傳輸控制算法的研究［J］.計算機工程與科學，2005，27（11）：52－56.Yu Su，Sheng Yan－jin，Huang Kai，et al.Research on the algorithm of RTP adaptive transmission control［J］.Computer Engineering＆Science，2005，27（11）：52－56.

［13］Padhye J，Firoiu V，Towsley D，et al.Modeling TCP throughput：a simple model and its empirical validation［J］.Computer Communication Review，1998，28（4）：303－314.

［14］陶桂東，張占軍.基于RTP協議H.264視頻流傳輸QoS保證的研究［J］.裝甲兵工程學院學報，2006，20（5）：58－61.Tao Gui－dong，Zhang Zhan－jun.Research on the QoS guarantee for H.264video stream transmission based on RTP［J］.Journal of Academy of Armored Force Engineering，2006，20（5）：58－61.