本篇科技職稱論文發(fā)表分析智能視頻監(jiān)控系統(tǒng)中的網(wǎng)絡擁塞解決方案，隨著數(shù)字化智能化技術的發(fā)展，智能視頻監(jiān)控系統(tǒng)被廣泛應用于各行各業(yè)，因智能視頻監(jiān)控系統(tǒng)的數(shù)據(jù)均由網(wǎng)絡進行數(shù)據(jù)傳輸，這對網(wǎng)絡寬帶的數(shù)據(jù)傳輸能力提出了更高的要求，通過線程池技術解決現(xiàn)實中智能視頻監(jiān)控系統(tǒng)中的網(wǎng)絡擁塞問題，是本篇科技職稱論文發(fā)表的重點。

　　《應用科技》Applied Science and Technology(雙月刊)創(chuàng)刊于1974年，是工業(yè)和信息化部主管、哈爾濱工程大學主辦的學術期刊，國內外公開發(fā)行，郵發(fā)代號14-160。該刊集科學性、前沿性、實用性于一體，以高等院校、科研院所的研究人員為讀者對象。該刊依托高校辦刊的優(yōu)勢，針對高校科研項目多、科技成果密集的特點，刊發(fā)大量的高水平、實用性強的科技論文。

　　借鑒TFRC擁塞控制模型原理，提出一種網(wǎng)絡擁塞自適應解決策略，按照該網(wǎng)絡擁塞解決策略的要求，結合網(wǎng)絡視頻流傳輸相關技術為系統(tǒng)后臺服務端設計了一個網(wǎng)絡擁塞處理模塊。該模塊通過接收端反饋回來的網(wǎng)絡狀況報告，制定出平滑的數(shù)據(jù)傳輸帶寬，系統(tǒng)根據(jù)該傳輸帶寬對數(shù)據(jù)發(fā)送模塊和視頻編碼模塊運作進行指導。

　　關鍵詞：智能視頻監(jiān)控;網(wǎng)絡擁塞;網(wǎng)絡自適應;TFRC

　　近年來，伴隨技術的不斷進步，視頻監(jiān)控系統(tǒng)在人們日常生活中的應用越來越廣泛。當前，視頻監(jiān)控系統(tǒng)正朝著數(shù)字化、智能化方向發(fā)展，為用戶提供一個全面智能的安全防護解決方案尤為必要。各種報警傳感器和智能網(wǎng)絡攝像機地誕生為視頻監(jiān)控系統(tǒng)的發(fā)展提供了基本保障。然而，這些設備大多是通過網(wǎng)絡進行數(shù)據(jù)傳輸，現(xiàn)有的網(wǎng)絡體系結構只能提供盡力而為的傳輸服務，缺乏服務質量保障，這對網(wǎng)絡帶寬需求量最大的視頻流傳輸產生了嚴重影響。如何在網(wǎng)絡環(huán)境下為大量的視頻流傳輸提供可靠保證，已成為網(wǎng)絡視頻研究的熱點問題。

　　1視頻監(jiān)控系統(tǒng)網(wǎng)絡擁塞控制解決方案

　　本文提出的針對視頻監(jiān)控系統(tǒng)的網(wǎng)絡擁塞解決方案設計如圖1所示。視頻監(jiān)控系統(tǒng)主要由服務端和客戶端兩部分組成。

　　服務端通過視頻信息采集模塊，讀取來自視頻源的信息。讀入視頻信息后，由視頻解碼模塊負責對視頻信息作分析處理，將原始視頻數(shù)據(jù)轉換成可以重新編碼的視頻信息。隨后根據(jù)網(wǎng)絡擁塞控制模塊制定的相關編碼參數(shù)，進行視頻編碼工作，生成適合于網(wǎng)絡傳輸?shù)囊曨l數(shù)據(jù)，根據(jù)RTP協(xié)議格式要求把這些視頻數(shù)據(jù)連續(xù)發(fā)送給客戶端。傳輸過程中的差錯控制、傳輸速率控制由網(wǎng)絡擁塞處理模塊來實現(xiàn)。

　　客戶端在接收到數(shù)據(jù)包信息后，將它們加入到一個緩沖區(qū)中，再調用解碼庫進行解碼。解碼后獲得的視頻信息通過視頻分析處理模塊進行移動偵測、人臉識別等圖像分析工作后，再顯示給用戶觀看或者保存起來。

　　客戶端QoS監(jiān)視模塊采集到的網(wǎng)絡信息，如包的丟失率、包延時時間及環(huán)路時間等，經(jīng)處理計算后，根據(jù)RTCP協(xié)議格式要求傳送給服務端，由服務端的網(wǎng)絡擁塞處理模塊對這些信息進行處理、分析，進而保障服務端視頻編碼及數(shù)據(jù)傳輸?shù)恼＿M行。實現(xiàn)視頻流自適應控制傳輸，為用戶提供一個可靠、穩(wěn)定、良好的視頻觀看環(huán)境。

　　2網(wǎng)絡擁塞控制模塊

　　發(fā)送端的網(wǎng)絡擁塞控制模塊主要依照TFEC模型來設計，其工作原理如圖2所示。TFRC的穩(wěn)態(tài)速率計算公式為：

　　其中，s代表TCP報文大小，單位是字節(jié);p代表丟失事件率，t0代表數(shù)據(jù)報文的超時時間，tRTT為數(shù)據(jù)報文的環(huán)路時間，b為一個應答所接收到的報文數(shù)數(shù)目(b規(guī)定為1)。通過式(1)就可以計算出一個傳輸數(shù)據(jù)流的穩(wěn)態(tài)發(fā)送速率B(p)。

　　發(fā)送端在準備需要發(fā)送的視頻信息后，將這些視頻信息按RTP協(xié)議要求打包，添加時間戳、狀態(tài)值，發(fā)送序號等一些網(wǎng)絡信息，接收端在收到這些視頻信息數(shù)據(jù)包后，除了解碼恢復出圖像信息外，還要提取出時間戳等信息，采用反饋控制法計算出包丟失率、環(huán)路時間、瓶頸帶寬等信息。這些網(wǎng)絡狀況信息交給接收端的網(wǎng)絡狀況反饋模塊，按照RTCP協(xié)議的要求打包傳輸給發(fā)送端。發(fā)送端根據(jù)這些反饋信息，依照網(wǎng)絡擁塞自適應控制模型，計算出當前的網(wǎng)絡帶寬，制定平滑的網(wǎng)絡數(shù)據(jù)傳輸速率調整方案，進行視頻編碼的相關參數(shù)調整，力求保證視頻服務質量。

　　2.1視頻編碼調整

　　視頻編碼調整的目的在于降低編碼碼率或是調整幀速，以適應當前網(wǎng)絡帶寬。本視頻監(jiān)控系統(tǒng)采用H.263+和MJPEG4兩種編碼標準。它們比較適合于局域網(wǎng)內的視頻傳輸。

　　2.2發(fā)送速率調整

　　發(fā)送端自適應控制模塊根據(jù)網(wǎng)絡擁塞控制模塊提供的網(wǎng)絡狀況信息，將發(fā)送速率逐步地調整到期望速率，力求和實際網(wǎng)絡帶寬相匹配，保障視頻流網(wǎng)絡傳輸?shù)恼＿M行。該過程是一個漸進過程，數(shù)據(jù)發(fā)送率不能發(fā)生大的跳變，否則對接收端的觀看效果影響很大。

　　(1)客戶端瓶頸帶寬計算。

　　如圖3所示，發(fā)送端在時間點為tTimestamp時向接收端發(fā)送了一個數(shù)據(jù)包，隨后在收到N個含有時間戳tTimestamp的數(shù)據(jù)包后，使用式(3)來計算瓶頸帶寬。

　　其中，BnBw為網(wǎng)絡瓶頸帶寬值，Packet[i]為第i個數(shù)據(jù)包的大小，單位為Byte，tTimestamp為數(shù)據(jù)包發(fā)送時間戳，tRecv_ClientN為接收到第N個數(shù)據(jù)包的時間，tRecv_Client1為接收到第一個數(shù)據(jù)包的時間。

　　使用式(2)計算出網(wǎng)絡的瓶頸帶寬BnBw可用作數(shù)據(jù)發(fā)送速率的上限值。以BnBw作為一個上限值，和TFRC算法計算出的帶寬值一起幫助制定發(fā)送速率，可以有效避免發(fā)送速率調整波動過大。

　　(2)數(shù)據(jù)發(fā)送速率制定。由TFRC穩(wěn)態(tài)速率公式(式1)可知，穩(wěn)態(tài)發(fā)送速率B(p)是伴隨丟失事件率等參數(shù)的變化而改變的。但是擁塞控制模型并不是直接將B(p)值用以調整數(shù)據(jù)的發(fā)送速率。事實上，發(fā)送速率的調整應當是一個緩慢變化的過程，這樣可以避免引起大波動，影響到接收端視頻觀看的效果。數(shù)據(jù)發(fā)送速率可參照式(3)-(6)制定：

　　Sendrate=B(p)(3)

　　Sendrate=0.75×Sendrate+0.25×PreSendrate(4)

　　Sendrate=min(Sendrate，BnBw)(5)

　　PreSendrate=Sendrate(6)

　　其中，B(p)為TFRC穩(wěn)態(tài)速率計算公式中計算得出的網(wǎng)絡帶寬，Sendrate為數(shù)據(jù)的發(fā)送速率，PreSendrate為前一次的數(shù)據(jù)發(fā)送速率，BnBw為根據(jù)客戶端反饋計算得出的網(wǎng)絡瓶頸帶寬。參照TFRC模型，網(wǎng)絡視頻流的傳輸既能保證與TCP流的友好，又可以使數(shù)據(jù)傳輸速率較為平滑，為網(wǎng)絡視頻數(shù)據(jù)流的傳輸提供了良好保證。

　　3客戶端緩沖

　　數(shù)據(jù)從發(fā)送端到達接收端的過程中會遇到很多突發(fā)情況，雖然RTP協(xié)議為RTCP協(xié)議提供了一定的服務質量保證，但是包丟失和包失序的情況不可能消除，所以接收端必須有相應的一些策略來對丟失和包失序進行處理。本文設計的視頻監(jiān)控系統(tǒng)解決該問題的做法是在數(shù)據(jù)被提交給上層處理之前，利用RTP數(shù)據(jù)包頭信息中的序列號對數(shù)據(jù)包進行重排，為此，在期望的數(shù)據(jù)包到達接收端之前，接收端將非期望數(shù)據(jù)包暫時保存于一個緩沖區(qū)中，然后不斷進行檢測，一旦需要的包全部到齊，則按順序提交給上層處理。對于緩沖區(qū)的使用，系統(tǒng)要面對的主要有兩個問題：緩沖區(qū)容量和緩沖區(qū)管理策略。

　　3.1緩沖區(qū)容量

　　將當前送往上層處理的數(shù)據(jù)包的序列號記為Sp，當前接收到的數(shù)據(jù)包的序列號記為Se。在出現(xiàn)失序時，Se>Sp+1;只有在Se=Sp+1 時，序列號等于Se的數(shù)據(jù)包才是上層期望得到的。如果在該序列號等于Se的數(shù)據(jù)包到達之前，就已經(jīng)有N個包到達了接收端，那么緩沖區(qū)必須能夠容納下這N個包。假定每個數(shù)據(jù)包的平均長度是L，則要保存下這N個包所需的緩沖區(qū)的大小應該是N*L。緩沖區(qū)的實際大小記為Bs，很明顯，Bs不能夠僅僅是等于 N*L，因為如果N很大，則N*L將趨近于無窮大(在包丟失的情況下，N實際上等于無窮大)。如何確定下一個適當?shù)腂s值，對于接收端的觀看效果影響是很大的。Bs值如果取得太小，則由于不同網(wǎng)路之間的延遲等情況而造成的遲到包不能被保存下來，這會導致大量的數(shù)據(jù)包在接收端被丟棄掉。若Bs值太大，則計算機需要分配很大的緩沖區(qū)，造成資源浪費。況且Bs越大，聲音和圖像的延遲也會越大，并造成后面的數(shù)據(jù)包由于得不到及時處理而被丟棄。

　　3.2緩沖區(qū)容量調整算法

　　本文設計的視頻監(jiān)控系統(tǒng)采用一種反饋方式來動態(tài)調整緩沖區(qū)容量。該算法經(jīng)實踐檢驗，能有效地解決視頻流在網(wǎng)絡傳輸過程中的包失序現(xiàn)象。算法具體流程描述如下：

　　(1)首先設定兩個參數(shù)值，緩沖區(qū)最大值Nmax，緩沖區(qū)最小值Nmin。

　　(2)緩沖區(qū)大小的初始值設定為n，且要求n=Nmin。

　　(3)如果連續(xù)3次因為緩沖區(qū)太小，后繼到達的期望數(shù)據(jù)包被丟失，那么要求緩沖區(qū)增加一個單元(這里的單元含義是：根據(jù)所有數(shù)據(jù)分組而計算出來的平均長度)，即n=n+l;如果n已經(jīng)增加達到設定的最大值Nmax，則保持n=Nmax，不再增加。

　　(4)如果連續(xù)3次，期望數(shù)據(jù)包Se和當前正在處理的數(shù)據(jù)包之間的間隔(也稱為Se的失序程度)都小于當前的緩沖區(qū)容量n，那么要求緩沖區(qū)容量減少掉一個單元，即n=n-1，;如果n減小到最小值Nmin，保持n=Nmin不再減少。

　　根據(jù)實際測試中的經(jīng)驗，通常Nmin值設定為2或3。Nmax的值一般不能太大，設置為10左右比較合理，根據(jù)服務器的硬件配置可作適當調整。

　　接收端緩沖區(qū)可以被理解成一個擁有上限值和下限值的滑動窗口，按照當前網(wǎng)絡狀態(tài)的變化，該滑動窗口做自適應的放大、縮小。

　　4接收端圖像分析處理

　　借助于數(shù)字視頻處理等技術，視頻監(jiān)控系統(tǒng)的發(fā)展正朝著智能化方向發(fā)展，本文設計的視頻監(jiān)控系統(tǒng)借助于OpenCV庫，實現(xiàn)了對視頻流的目標跟蹤和人臉檢測。

　　接收端啟動后，若成功與發(fā)送端建立連接，將開啟3個主要線程用于視頻的接收、顯示、圖像分析、視頻保存。

　　第一個線程，即數(shù)據(jù)接收線程。主要負責網(wǎng)絡通信，在接收到發(fā)送端傳來的數(shù)據(jù)后，這些數(shù)據(jù)將全部加入到緩沖區(qū)，隨后按數(shù)據(jù)包序號有序地傳送給圖像解碼/顯示線程，同時還承擔網(wǎng)絡狀況計算和反饋的功能。

　　第二個線程，即圖像解碼/顯示線程。主要功能是對視頻數(shù)據(jù)進行解碼，得到可以用于編輯、顯示的視頻數(shù)據(jù)。若用戶只要求觀看發(fā)送端傳來的原始視頻數(shù)據(jù)，圖像解碼/顯示線程就可以直接滿足其需要，另外一個圖像處理線程將處于掛起狀態(tài)，以節(jié)約計算機資源。

　　第三個線程，即圖像處理線程。針對視頻流進行圖像分析，提供諸如人臉識別、目標跟蹤等職能輔助功能，其核心是利用數(shù)字圖像分析技術來對圖像進行分析、處理，OpenCV是一個很好的開源視覺庫，支持VC++，經(jīng)常重新分裝的OpenCV庫頁能支持C#等其它編程語言。OpenCV自身就提供了豐富的圖像處理函數(shù)，開發(fā)人員也可以根據(jù)自己的要求，自行開發(fā)新的功能。OpenCV具有通用的視頻/圖像載入、保存、獲取模塊，經(jīng)OpenCV處理后的視頻、圖像可以按照多種編碼格式保存。

　　5結語

　　本文關于視頻監(jiān)控系統(tǒng)的研究從搭建一個最簡單的視頻監(jiān)控平臺開始，最初的開發(fā)目標只要求能滿足同時接收多路攝像機視頻流，并顯示給用戶觀看即可。隨著開發(fā)的逐步深入，整個系統(tǒng)功能得到了極大擴展，成為一個穩(wěn)定、可靠、功能較為齊全的視頻監(jiān)控平臺。在開發(fā)過程也遇到了各種困難，經(jīng)過大量的嘗試和失敗后，最終找到了問題的解決辦法，如程序中擁有10個線程導致CPU占用率高達90%，而且線程間經(jīng)常出現(xiàn)不同步現(xiàn)象等。伴隨著線程池等技術的應用，程序 CPU占用率過高的問題得到了解決，線程池技術對多線程的管理也起到了積極作用。