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

關(guān)鍵詞：智能視頻監(jiān)控；網(wǎng)絡(luò)擁塞；網(wǎng)絡(luò)自適應(yīng)；TFRC

DOIDOI：10.11907/rjdk.151262

中圖分類號(hào)：TP393

文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1672-7800（2023）007-0166-03

0 引言

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

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

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

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

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

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

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

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

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

B（p）=stRTT2bp3+t0min（1，33bp8）p（1+32p2）（1）

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

圖2 網(wǎng)絡(luò)擁塞控制模塊工作原理

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

2.1 視頻編碼調(diào)整

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

2.2 發(fā)送速率調(diào)整

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

（1）客戶端瓶頸帶寬計(jì)算。

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

BnBw=∑Ni=1packet[i]tRecv_ClientN-tRecv_Client1（2）

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

圖3 數(shù)據(jù)包收發(fā)

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

（2）數(shù)據(jù)發(fā)送速率制定。由TFRC穩(wěn)態(tài)速率公式（式1）可知，穩(wěn)態(tài)發(fā)送速率B（p）是伴隨丟失事件率等參數(shù)的變化而改變的。但是擁塞控制模型并不是直接將B（p）值用以調(diào)整數(shù)據(jù)的發(fā)送速率。事實(shí)上，發(fā)送速率的調(diào)整應(yīng)當(dāng)是一個(gè)緩慢變化的過程，這樣可以避免引起大波動(dòng)，影響到接收端視頻觀看的效果。數(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)速率計(jì)算公式中計(jì)算得出的網(wǎng)絡(luò)帶寬，Sendrate為數(shù)據(jù)的發(fā)送速率，PreSendrate為前一次的數(shù)據(jù)發(fā)送速率，BnBw為根據(jù)客戶端反饋計(jì)算得出的網(wǎng)絡(luò)瓶頸帶寬。參照TFRC模型，網(wǎng)絡(luò)視頻流的傳輸既能保證與TCP流的友好，又可以使數(shù)據(jù)傳輸速率較為平滑，為網(wǎng)絡(luò)視頻數(shù)據(jù)流的傳輸提供了良好保證。

3 客戶端緩沖

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

3.1 緩沖區(qū)容量

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

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

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

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

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

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

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

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

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

4 接收端圖像分析處理

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

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

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

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

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

5 結(jié)語

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

參考文獻(xiàn)：

[1] 黎洪松.數(shù)字視頻技術(shù)及其應(yīng)用[M].北京：清華大學(xué)出版社，1997.

[2] 袁野.基于嵌入式技術(shù)的網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)[J].通訊世界，2002（4）：62-63.

[3] SIMON ROBINSON，CHRISTIAN NAGEL.C#高級(jí)編程[M].第3版.北京：清華大學(xué)出版社，2005.

[4] 劉富強(qiáng).數(shù)字視頻監(jiān)控系統(tǒng)開發(fā)及應(yīng)用[M].北京：機(jī)械工業(yè)出版社，2003.

[5] 馬喜廷，孟榮芳.IP網(wǎng)絡(luò)攝像機(jī)[J].電視技術(shù)，2003（5）：84-85.