基于動(dòng)態(tài)策略的網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)

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

（吉林大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，長(zhǎng)春130012）

0 引 言

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

本文采用動(dòng)態(tài)策略，基于宏塊特征，實(shí)現(xiàn)幀內(nèi)預(yù)測(cè)模式的動(dòng)態(tài)選擇，并且分析網(wǎng)絡(luò)狀況信息，計(jì)算當(dāng)前網(wǎng)絡(luò)支持的最大傳輸碼率，自適應(yīng)地調(diào)整服務(wù)器的輸出碼率，從而提高編碼效率以及網(wǎng)絡(luò)的利用率。

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

1.1 幀內(nèi)預(yù)測(cè)模式的動(dòng)態(tài)選擇算法

1.1.1 幀內(nèi)預(yù)測(cè)模式

幀內(nèi)預(yù)測(cè)是利用當(dāng)前待編碼宏塊周圍的已編碼并重建的宏塊預(yù)測(cè)當(dāng)前宏塊的值。亮度塊幀內(nèi)預(yù)測(cè)根據(jù)亮度塊大小分為16×16和4×4兩種。

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

圖1 16×16亮度預(yù)測(cè)模式Fig.1 Brightness of 16×16prediction model

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

圖2 4×4預(yù)測(cè)模式的8種不同方向Fig.2 4×4prediction of 8different directional patterns

1.1.2 動(dòng)態(tài)選擇算法

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

本文對(duì)宏塊特征的計(jì)算受到了文獻(xiàn)［10，11］的啟發(fā)。對(duì)4種不同的16×16亮度預(yù)測(cè)模式分別進(jìn)行分析，垂直預(yù)測(cè)模式計(jì)算待編碼宏塊的像素點(diǎn)在垂直方向上的平滑度，這里采用方差來衡量平滑程度：

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

水平預(yù)測(cè)模式計(jì)算水平方向上的平滑度為：

式中：mx為宏塊第x 行像素點(diǎn)的均值。

DC預(yù)測(cè)模式計(jì)算宏塊整體的平滑度為：

式中：mxy為宏塊的所有像素點(diǎn)的均值。

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

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

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

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

由于16×16的預(yù)測(cè)方向在4×4中同樣會(huì)進(jìn)行預(yù)測(cè)，僅選擇可能性較高的模式作為當(dāng)前塊的候選模式，這樣可以在很大程度上減少幀內(nèi)模式的計(jì)算量。采用16×16預(yù)測(cè)模式中的預(yù)測(cè)方向?qū)?×4預(yù)測(cè)模式進(jìn)行分組，同時(shí)根據(jù)16×16的結(jié)果在4×4的預(yù)測(cè)模式中選出一組預(yù)測(cè)模式作為候選組，再在候選組中選出最佳的預(yù)測(cè)模式即可。由于DC預(yù)測(cè)是在任何條件下都能使用的預(yù)測(cè)模式［2］，于是將DC 預(yù)測(cè)加入到所有組中。接下來直接使用X264中提供的方法計(jì)算候選分組中的各個(gè)模式的代價(jià)，選擇出代價(jià)最低的預(yù)測(cè)模式作為最佳預(yù)測(cè)模式。

1.2 基于網(wǎng)絡(luò)狀況的碼率自適應(yīng)算法

1.2.1 傳輸速率調(diào)整方式

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

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

1.2.2 碼率自適應(yīng)算法

本算法所需參數(shù)主要依靠由接收端周期性向發(fā)送端發(fā)送的接收端報(bào)告RR 數(shù)據(jù)包。RR 包是RTCP數(shù)據(jù)包的一種，其中包含了間隔抖動(dòng)、已接收?qǐng)?bào)告數(shù)、累計(jì)丟包數(shù)等重要參數(shù)。服務(wù)器根據(jù)這些參數(shù)計(jì)算檢測(cè)當(dāng)前網(wǎng)絡(luò)狀況，并根據(jù)檢測(cè)結(jié)果進(jìn)行碼率的自適應(yīng)調(diào)整。本文的碼率自適應(yīng)算法主要使用丟包率Ploss和傳輸?shù)耐禃r(shí)間RTT。

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

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

基于網(wǎng)絡(luò)狀況的碼率自適應(yīng)是為了避免網(wǎng)絡(luò)擁塞，而TCP協(xié)議對(duì)于網(wǎng)絡(luò)擁塞進(jìn)行的控制算法又是成熟而且得到實(shí)踐檢驗(yàn)的，所以本文受到TCP協(xié)議的啟發(fā)，對(duì)數(shù)據(jù)傳輸過程細(xì)化為慢啟動(dòng)和擁塞避免兩個(gè)階段。

（1）慢啟動(dòng)階段。在此階段，將TCP 協(xié)議的慢啟動(dòng)思想應(yīng)用到監(jiān)控視頻開始的傳輸階段。通過量化參數(shù)QP 的動(dòng)態(tài)改變來實(shí)現(xiàn)碼率的調(diào)整。QP 值越大，碼率越小，圖像的質(zhì)量越差，從圖像質(zhì)量和性價(jià)比的角度考慮，設(shè)置QP＿M(jìn)AX 和QP＿M(jìn)IN 為量化參數(shù)最大值和最小值。

首先初始化QP ＝QP＿M(jìn)AX，然后根據(jù)RTCP包反饋的丟包率Ploss進(jìn)行操作選擇。當(dāng)Ploss＝0時(shí)，使用公式：

進(jìn)行QP 的調(diào)整（QP′為QP 的均值，τ為參數(shù)），由于QP 越大，發(fā)送到網(wǎng)絡(luò)上進(jìn)行傳輸?shù)囊曨l數(shù)據(jù)量越少，網(wǎng)絡(luò)狀況也就越好，QP 的變化速度在QP 越大的情況要快一些，所以設(shè)定的QP 變化公式中隨著QP 值變小，QP 變化速度是減慢的。否則，QP 不變，統(tǒng)計(jì)接下來連續(xù)5個(gè)RR 包中有3個(gè)丟包率非0或者QP 減小到QP＿M(jìn)IN，則進(jìn)入擁塞避免階段。

（2）擁塞避免階段。當(dāng)本算法碼率與網(wǎng)絡(luò)帶寬達(dá)到適應(yīng)后，進(jìn)入到擁塞避免階段。根據(jù)網(wǎng)絡(luò)狀況的變化進(jìn)行碼率的自適應(yīng)調(diào)整。

首先，根據(jù)求出的傳輸速率br 可計(jì)算得到當(dāng)前網(wǎng)絡(luò)狀況滿足的起始幀量化參數(shù)start＿qp［14］：

式中：a、b、c為常系數(shù)。

再根據(jù)start＿qp 和THR 對(duì)QP 的值進(jìn)行調(diào)整，當(dāng)start＿qp＜QP－THR 時(shí)，說明網(wǎng)絡(luò)處于輕載狀態(tài)，需要降低量化值，QP 取start＿qp 和QP＿M(jìn)IN 中較大值。當(dāng)start＿qp ＞QP ＋THR時(shí)，說明當(dāng)前網(wǎng)絡(luò)處于過載的狀態(tài)，需要提高量化值，QP 取start＿qp 和QP＿M(jìn)AX 中較小值。

當(dāng)QP－THR ≤start＿qp ≤QP＋THR 時(shí)，說明網(wǎng)路處于滿載狀態(tài)，無需改變編碼量化值。其中，THR 是調(diào)整QP 的閾值。設(shè)置THR 的計(jì)算公式為：

式中：κ為參數(shù)。

從式（8）可以看出，當(dāng)丟包率為0時(shí)，無法預(yù)測(cè)網(wǎng)絡(luò)的有效帶寬，所以當(dāng)本系統(tǒng)收到第一個(gè)丟包率為0的包，量化參數(shù)不變，當(dāng)收到后面連續(xù)丟包率為0的RR 數(shù)據(jù)包，再收到后續(xù)的丟包率為0的RTCP包后，則利用式（10）減小QP 的數(shù)值，從而提高網(wǎng)絡(luò)帶寬的利用率。

2 網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)結(jié)構(gòu)

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

圖3 網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)結(jié)構(gòu)圖Fig.3 Structure diagram of network video monitoring system

首先，服務(wù)器驅(qū)動(dòng)攝像頭讀取監(jiān)控視頻，然后服務(wù)器對(duì)監(jiān)控視頻進(jìn)行壓縮編碼處理；當(dāng)存在客戶端通過RTSP 協(xié)議與服務(wù)器建立連接且向服務(wù)器發(fā)送了監(jiān)控視頻播放請(qǐng)求時(shí)，服務(wù)器通過RTP協(xié)議向客戶端發(fā)送視頻數(shù)據(jù)，客戶端接收到視頻數(shù)據(jù)后進(jìn)行解碼播放；在連接已建立期間，服務(wù)器與客戶端周期性地相互發(fā)送RTCP包，使兩端都能了解到當(dāng)前的網(wǎng)絡(luò)狀況，本文根據(jù)這些網(wǎng)絡(luò)狀況信息對(duì)編碼器的輸出碼率進(jìn)行調(diào)整，實(shí)現(xiàn)基于網(wǎng)絡(luò)狀況的碼率自適應(yīng)調(diào)整。

3 系統(tǒng)各功能模塊的實(shí)現(xiàn)

3.1 服務(wù)器的設(shè)計(jì)實(shí)現(xiàn)

本系統(tǒng)服務(wù)器主要包括4個(gè)部分，如圖4所示。

圖4 系統(tǒng)服務(wù)器結(jié)構(gòu)Fig.4 Structure diagram of system server

首先，服務(wù)器利用Linux關(guān)于視頻設(shè)備內(nèi)核驅(qū)動(dòng)V4L2（video4linux2）提供的接口，編寫驅(qū)動(dòng)程序驅(qū)動(dòng)攝像頭讀取視頻數(shù)據(jù)，再對(duì)視頻數(shù)據(jù)進(jìn)行壓縮編碼；由于本系統(tǒng)編碼器是基于開源的H.264編碼器X264實(shí)現(xiàn)的，且X264要求輸入的視頻每幀圖像都為YUV420格式，所以在編碼前需要將讀入的YUYV 圖像格式視頻數(shù)據(jù)轉(zhuǎn)換成YUV420。然后，將轉(zhuǎn)換X264 分別對(duì)每幀YUV420格式的圖像進(jìn)行編碼，編碼后即可得到標(biāo)準(zhǔn)H.264格式的視頻數(shù)據(jù)。將編碼后的視頻數(shù)據(jù)保存到服務(wù)器中作為回放的視頻數(shù)據(jù)，同時(shí)在有用戶請(qǐng)求實(shí)時(shí)監(jiān)控視頻時(shí)，通過開源流媒體服務(wù)器Live555將內(nèi)存中的視頻數(shù)據(jù)用于發(fā)送給用戶。

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

3.2 客戶端的設(shè)計(jì)實(shí)現(xiàn)

本系統(tǒng)客戶端以開源項(xiàng)目VLC 為基礎(chǔ)，同時(shí)實(shí)現(xiàn)了Windows和Android兩個(gè)平臺(tái)下的客戶端播放器。首先對(duì)VLC 進(jìn)行編譯，生成可調(diào)用的庫文件，然后通過調(diào)用VLC 庫函數(shù)實(shí)現(xiàn)客戶端的整體功能。

Windows系統(tǒng)下VLC播放器的編譯需要在由Cygwin仿真得到的Linux 環(huán)境下進(jìn)行，圖5為編譯過程。

圖5 Windows系統(tǒng)下VLC編譯過程Fig.5 VLC compilation process in Windows system

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

對(duì)于本系統(tǒng)中Windows系統(tǒng)下的客戶端的實(shí)現(xiàn)，首先需要?jiǎng)?chuàng)建一個(gè)MFC 的工程；然后，將VLC的核心庫、插件庫以及客戶端實(shí)現(xiàn)所需的頭文件都加入到項(xiàng)目中；接下來即可基于VLC 和MFC進(jìn)行代碼實(shí)現(xiàn)。

客戶端的代碼實(shí)現(xiàn)過程如下：

（1）調(diào)用libvlc＿new 函數(shù)創(chuàng)建并初始化一個(gè)libvlc對(duì)象。

（2）調(diào)用libvlc＿media＿new＿path 函數(shù)根據(jù)libvlc對(duì)象和媒體路徑（可以是多媒體文件的文件存儲(chǔ)路徑，也可以是流媒體文件的網(wǎng)絡(luò)路徑，如：rtsp：／／192.168.3.111／test.264）創(chuàng)建可播放的媒體對(duì)象。

（3）調(diào)用libvlc＿media＿player＿new 函數(shù)，根據(jù)libvlc對(duì)象創(chuàng)建播放器對(duì)象。

（4）調(diào)用libvlc＿media＿player＿set＿media函數(shù)，將播放器對(duì)象與媒體對(duì)象進(jìn)行連接。

（5）獲取播放窗口的句柄，調(diào)用libvlc＿media＿player＿set＿h(yuǎn)wnd將播放器對(duì)象與播放窗口進(jìn)行關(guān)聯(lián)。

（6）調(diào)用libvlc＿media＿player＿play函數(shù)，發(fā)送播放命令，接收視頻數(shù)據(jù)進(jìn)行播放。

以上就是基于VLC實(shí)現(xiàn)Windows系統(tǒng)下客戶端的主要步驟，并且這些步驟有嚴(yán)格的先后順序。

4 實(shí)驗(yàn)結(jié)果及分析

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

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

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

在不同網(wǎng)絡(luò)帶寬狀況下，將無碼率自適應(yīng)算法與本文基于網(wǎng)絡(luò)狀況的碼率自適應(yīng)算法進(jìn)行碼率對(duì)比。該測(cè)試在同一個(gè)內(nèi)網(wǎng)下的兩臺(tái)計(jì)算機(jī)上進(jìn)行，因此網(wǎng)絡(luò)狀況可以得到保障。本文對(duì)采用碼率自適應(yīng)算法的服務(wù)器與使用固定編碼量化參數(shù)分別為25、35和45的服務(wù)器輸出碼率的狀況進(jìn)行了對(duì)比。同時(shí)，在第75、130、175s三個(gè)時(shí)間點(diǎn)，將網(wǎng)絡(luò)的流量限制分別設(shè)置為1000、500、1000kbit／s，測(cè)試在網(wǎng)絡(luò)狀況發(fā)生變化時(shí)本文的碼率自適應(yīng)算法的響應(yīng)情況。

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

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

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

5 結(jié)束語

本文結(jié)合H.264視頻編碼技術(shù)和RTSP 協(xié)議等流媒體技術(shù)，實(shí)現(xiàn)了網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)。針對(duì)編碼效率和網(wǎng)絡(luò)資源合理化利用的兩點(diǎn)不足，提出了幀內(nèi)預(yù)測(cè)模式的動(dòng)態(tài)選擇算法策略和基于網(wǎng)絡(luò)狀況的碼率自適應(yīng)策略。實(shí)驗(yàn)結(jié)果驗(yàn)證了方案的可行性，并收到了較好的監(jiān)控效果，實(shí)現(xiàn)了網(wǎng)絡(luò)視頻監(jiān)控。

［1］毛劍飛，張杰，蔣莉，等.基于改進(jìn)的H.264的視頻監(jiān)控系統(tǒng)［J］.計(jì)算機(jī)系統(tǒng)應(yīng)用，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 編碼標(biāo)準(zhǔn)模式選擇快速算法研究［D］.重慶：重慶大學(xué)通信與信息系統(tǒng)學(xué)院，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 視頻傳輸中碼率自適應(yīng)調(diào)整算法［J］.東南大學(xué)學(xué)報(bào)：自然科學(xué)版，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 的流媒體傳輸編碼碼率自適應(yīng)算法［J］.中國(guó)圖象圖形學(xué)報(bào)，2011，16（4）：510－515.Zuo Dong－h(huán)ong.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在城市軌道交通視頻監(jiān)控中碼率控制的研究［D］.上海：東華大學(xué)計(jì)算機(jī)應(yīng)用技術(shù)學(xué)院，2008.Liao Shun－h(huán)e.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 編碼算法的若干關(guān)鍵技術(shù)研究［D］.上海：上海交通大學(xué)電子信息與電氣工程學(xué)院，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 快速幀內(nèi)模式?jīng)Q策［J］.計(jì)算機(jī)工程與應(yīng)用，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］牛平宏.面向?qū)崟r(shí)壓縮的H.264 優(yōu)化研究［D］.西安：西安電子科技大學(xué)計(jì)算機(jī)應(yīng)用技術(shù)學(xué)院，2006.Niu Ping－h(huán)ong.Researches on H.264encoder optimization for real time compression［D］.Xi＇an：Applied Computer Technology Institute，Xidian University，2006.

［12］于溯，盛彥瑾，黃凱，等.RTP 自適應(yīng)傳輸控制算法的研究［J］.計(jì)算機(jī)工程與科學(xué)，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，F(xiàn)iroiu 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協(xié)議H.264視頻流傳輸QoS保證的研究［J］.裝甲兵工程學(xué)院學(xué)報(bào)，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.