本文針對不同的局域網(wǎng)，提出一種通用的實時視頻傳輸?shù)慕鉀Q方案。在使用Divx編解碼的基礎(chǔ)上，提出了從壓縮、組幀、發(fā)送到接收、解壓整個流程的思想，具體實施方案和VC++實現(xiàn)核心源代碼以及傳輸控制策略，有效地保證了高質(zhì)量的實時視頻傳輸。

關(guān)鍵詞客戶/服務(wù)器；實時視頻傳輸；Divx

引言

在局域網(wǎng)內(nèi)部實時傳輸視頻已經(jīng)得到廣泛應(yīng)用。現(xiàn)在用以傳輸視頻的局域網(wǎng)大多數(shù)是有線局域網(wǎng)，因為有線局域網(wǎng)技術(shù)成熟，傳輸速度快，穩(wěn)定性好。但是視頻數(shù)據(jù)量大，有線網(wǎng)絡(luò)也會出現(xiàn)工作不穩(wěn)定，引起數(shù)據(jù)堵塞，時間久了會導(dǎo)致嚴重的延遲現(xiàn)象；如果工作的環(huán)境不固定，要求移動性，那么就要采用無線網(wǎng)絡(luò)，如今無線網(wǎng)卡的工作隨環(huán)境的變化而變得不穩(wěn)定，這樣會導(dǎo)致視頻傳輸?shù)馁|(zhì)量大幅度下降，容易引起畫面的重影、抖動、花屏等現(xiàn)象。本文針對不同的局域網(wǎng)，提出一種通用的實時視頻傳輸?shù)慕鉀Q方案，使用VC++自封裝的WindowsVFWSDK軟件開發(fā)包進行二次開發(fā)，通過Divx編解碼，按照制定的傳輸策略，能夠有效地解決由于網(wǎng)絡(luò)的局部不穩(wěn)定導(dǎo)致的視頻圖像重影、抖動、花屏等的問題。

局域網(wǎng)中實時視頻傳輸存在的問題

為了在局域網(wǎng)上有效的、高質(zhì)量的傳輸視頻流，需要多種技術(shù)的支持，包括視頻的壓縮、編碼技術(shù)，應(yīng)用層質(zhì)量控制技術(shù)等等。

網(wǎng)絡(luò)的帶寬是有限的，所以需要壓縮傳輸視頻圖像，MPEG-4被廣泛的應(yīng)用于網(wǎng)絡(luò)環(huán)境下的實時視頻傳輸，因為MPEG-4具有：可以達到很高的壓縮比；具有靈活的編碼和解碼復(fù)雜性；基于對象的編碼方式，允許視頻、音頻對象的交互；具有很強的容錯能力等優(yōu)點。本文采用Divx編解碼器對視頻進行編碼、壓縮，實際上Divx=（視頻）MPEG-4+（音頻）MP3。

應(yīng)用層質(zhì)量控制技術(shù)現(xiàn)在采用的是RTP/RTCP協(xié)議，以確保視頻流在網(wǎng)絡(luò)中低時延、高質(zhì)量地傳輸。RTP數(shù)據(jù)傳輸協(xié)議負責(zé)音視頻數(shù)據(jù)的流化和負載，RTCP負責(zé)RTP數(shù)據(jù)報文的傳輸控制。此協(xié)議是通過客戶端（接收方）反饋網(wǎng)絡(luò)的狀況，服務(wù)器端（發(fā)送方）來調(diào)整信息采集、發(fā)送的速度和壓縮率。但是，對于圖像采集速度固定，需要軟件進行壓縮、解壓，調(diào)整采集的速度會引起采集的數(shù)據(jù)來不及壓縮而直接丟棄，調(diào)整編碼器的壓縮率需要重新設(shè)置編碼器的參數(shù)，重啟編碼器，相應(yīng)的解碼器也要調(diào)整，這個過程中需要很長的時間，達不到實時的要求。所以本文沒有采用RTP/RTCP協(xié)議，而是從發(fā)送端出發(fā)，實時判斷網(wǎng)絡(luò)狀況，采用“停等”策略進行實時傳輸。

網(wǎng)絡(luò)通信有兩種協(xié)議TCP和UDP，UDP更適合于網(wǎng)絡(luò)環(huán)境下的視頻傳輸，但是它不提供檢錯和糾錯功能，一旦網(wǎng)絡(luò)出現(xiàn)堵塞時，大量的數(shù)據(jù)報文會丟失。對于Divx編解碼技術(shù)，是以幀為單位進行編解碼的，分為關(guān)鍵幀和非關(guān)鍵幀。在傳輸過程中，由于壓縮率比較高，只要一幀中錯一比特位，將影響其它幾百甚至幾千的比特位，直接造成圖像的模糊、花屏等現(xiàn)象。只有等到下一次關(guān)鍵幀的到來才有可能恢復(fù)圖像的清晰。為了保證傳輸?shù)恼_性，自己需要在應(yīng)用層制定協(xié)議。如此一來，UDP的優(yōu)勢蕩然無存。所以本文選擇使用TCP來進行網(wǎng)絡(luò)通信。綜合使用VFW技術(shù)、流媒體技術(shù)，輔助以“停等”控制策略，較好的解決局域網(wǎng)中實時視頻傳輸容易引起的重影、抖動、花屏的問題。

實時視頻傳輸實現(xiàn)

為了達到視頻傳輸?shù)膶崟r性，總的思想是最少的發(fā)送冗余信息，最大程度上發(fā)送最新的視頻。

局域網(wǎng)實時視頻傳輸采用服務(wù)器/客戶機模式，利用VC++實現(xiàn)。其工作流程如圖1所示。

視頻采集采用AVICap從視頻采集卡捕獲視頻圖像，得到的是位圖型式的視頻幀，然后用Divx編碼器進行壓縮，通過Winsock實現(xiàn)壓縮后的視頻數(shù)據(jù)在局域網(wǎng)中的實時傳輸，接收完的數(shù)據(jù)交給Divx解碼器解壓，最后實現(xiàn)視頻顯示。

在VC++中，采用VFW技術(shù)，客戶端通過capSetCallbackOnFrame()注冊回調(diào)函數(shù)，當(dāng)采集卡采集到一幅圖像后，系統(tǒng)就會自動調(diào)用回調(diào)函數(shù)，然后再回調(diào)函數(shù)中使用ICSeqCompressFrame()函數(shù)進行壓縮。然后再通過Winsock將壓縮后的數(shù)據(jù)發(fā)送到服務(wù)器端。服務(wù)器端接收完一幀以后，交給ICDecompress()解壓，最后用SetDIBitsToDevice()將圖像顯示出來。

1、視頻幀的組建

視頻采集的數(shù)據(jù)是位圖型式的視頻幀，Divx編碼器壓縮以后形成以幀為格式的Mpeg4流。Divx解碼器也是以幀的格式解壓。所以提出以幀為單位發(fā)送視頻數(shù)據(jù)流。為了在接收端能夠方便地提取出一幀，提出如所示的格式組建幀。

幀開始標志

幀大小

幀編號

幀類型

幀數(shù)據(jù)

視頻幀格式

完整的一幀由5個字段組成，各個字段的意義幀開始標志，標志著一幀地開始，占用4個字節(jié)的空間。不妨設(shè)為0xffffffff。幀大小，表示整個幀的大小，包括5個字段的大小，占用4個字節(jié)的空間。幀編號，表示幀的順序編號，占用4個字節(jié)的空間。幀類型，標志此幀是否是關(guān)鍵幀，占用1個字節(jié)的空間。幀數(shù)據(jù)，存放壓縮后一幀的完整數(shù)據(jù)。

2、視頻幀的發(fā)送

實時視頻傳輸為了實時，要不斷地將壓縮好的數(shù)據(jù)發(fā)送到接受端。所以在發(fā)送端創(chuàng)建一個線程，專門用來發(fā)送數(shù)據(jù)。同時主線程仍然不停的采集數(shù)據(jù)并進行壓縮。發(fā)送線程的工作流程如圖3所示。

不妨假設(shè)創(chuàng)建的線程名為sendThread，核心代碼實現(xiàn)

while(1)

{

isOK=true;//準備就緒

SuspendThread(sendThread);//掛起線程

isOK=false;//線程正在發(fā)送數(shù)據(jù)

intlength=frameLength;//待發(fā)數(shù)據(jù)長度

if(length<50000){//判斷數(shù)據(jù)是否正常

intn=0;

intsendCount=0;

while(length>0){

n=send(sock，(char*)imageBuf+sendCount，length，0);//發(fā)送數(shù)據(jù)，

//imageBuf是指針，指向待發(fā)數(shù)據(jù)幀

if(n==SOCKET_ERROR)//網(wǎng)絡(luò)出現(xiàn)異常，則退出線程

break;

length-=n;

sendCount+=n;

}

}

}

線程中發(fā)送的數(shù)據(jù)幀是按照上一節(jié)中的方法組建好的數(shù)據(jù)幀。這種方法能夠保證正在發(fā)送的當(dāng)前幀能夠完整地到達接收端。

注意此線程中剛開始或者每當(dāng)發(fā)送完一幀以后，線程就轉(zhuǎn)到掛起狀態(tài)，等待外界喚醒。這個任務(wù)由回調(diào)函數(shù)完成，在回調(diào)函數(shù)中，判定如果發(fā)送線程準備就緒（處于掛起狀態(tài)），則進行圖像壓縮，然后喚醒線程發(fā)送壓縮完的數(shù)據(jù)，否則直接跳出，等待下一次調(diào)用回調(diào)函數(shù)，這種策略稱之為“停等”策略，在后面有詳細介紹。

3、視頻幀的接收

接收端最重要的是從接受的數(shù)據(jù)流中提取出完整的一幀。方法的思想是：首先從數(shù)據(jù)流中尋找?guī)_始標志，再從緊挨后面的數(shù)據(jù)中提取出幀的大小，然后再從接收緩沖區(qū)中讀入該幀剩余的數(shù)據(jù)。再尋找下一幀的開始標志，如此往復(fù)。圖4是接收端的工作流程。

同樣接收端創(chuàng)建一個線程專門用來執(zhí)行數(shù)據(jù)接收。不妨假設(shè)線程名為recThread，核心代碼實現(xiàn)

while(temp!=SOCKET_ERROR)

{

if(!isStart){//幀數(shù)據(jù)是否開始，true表示開始

if(endNum>3)//endNum紀錄當(dāng)前接收未處理的數(shù)據(jù)

endNum=0;

temp=recv(clisock，(char*)(recBuf+endNum)，1000，0);//從緩沖區(qū)讀取數(shù)據(jù)

startPos=serchStr(temp+endNum);//查找?guī)_始標志

if(startPos!=-1){

isStart=true;

endNum=temp+endNum-startPos-4;

memcpy(imageBuf，recBuf+startPos+4，endNum);//保存幀數(shù)據(jù)

}

else{

memcpy(recBuf，recBuf+temp+endNum-3，3);//保存最后三個字節(jié)的數(shù)據(jù)

endNum=3;

}

}

else{

if(endNum<4){//判定緊跟開始標志的數(shù)據(jù)，如果小于4表示不能獲得幀大小

temp=recv(clisock，(char*)(recBuf)，1000，0);//讀入數(shù)據(jù)

memcpy(imageBuf+endNum，recBuf，temp);//保存數(shù)據(jù)

endNum+=temp;

if(endNum<4)

continue;

frameSize=*((int*)imageBuf);//獲得幀大小

if(frameSize<500frameSize>50000){//異常處理（幀大小非法）

isStart=false;//丟棄數(shù)據(jù)重新查找?guī)_始標志

endNum=0;

continue;

}

frameSize-=endNum+4;

}

else{

while(frameSize>0&&temp!=SOCKET_ERROR){//獲得完整幀的剩余數(shù)據(jù)

temp=recv(clisock，(char*)(imageBuf+endNum)，frameSize，0);

endNum+=temp;

frameSize-=temp;

}

if(frameSize<=0){//幀結(jié)束置位，解壓

isStart=false;

endNum=0;

deCompress();//判斷數(shù)據(jù)的有效性，調(diào)用ICDecompress進行解壓

}

}

}

}

以上程序執(zhí)行的結(jié)果是將完整的一幀（除幀開始標志）保存在imageBuf中。

4、“停等”控制策略

如果局域網(wǎng)通信速率很高，而且工作穩(wěn)定，則按照以上說的方法進行實時視頻傳輸，不需要任何控制策略，就可以達到非常好的效果。但是在很多情況下，網(wǎng)絡(luò)會出現(xiàn)異常，這樣會導(dǎo)致數(shù)據(jù)傳輸率明顯下降，造成發(fā)送端數(shù)據(jù)積壓，等待發(fā)送的數(shù)據(jù)不能正常發(fā)出去。此時就要采取一定的策略來控制發(fā)送端，以達到實時性的要求。

上文發(fā)送程序中，變量isOK是用來表示發(fā)送端當(dāng)前幀有沒有發(fā)完，如果發(fā)完則置為true，同時也表示發(fā)送端準備就緒，可以繼續(xù)發(fā)送數(shù)據(jù)，否則為false。那么可以用isOK來通知視頻采集和壓縮線程，如果isOK為true，則可以采集視頻并且壓縮，然后喚醒發(fā)送線程繼續(xù)發(fā)送新來的幀數(shù)據(jù)，否則一直等待，直到網(wǎng)絡(luò)可以繼續(xù)發(fā)送數(shù)據(jù)（isOK為true）。當(dāng)然，視頻采集一直不停的進行，那么當(dāng)網(wǎng)絡(luò)發(fā)生數(shù)據(jù)堵塞時，只要不讓編碼器進行壓縮則可解決；當(dāng)網(wǎng)絡(luò)恢復(fù)正常時，繼續(xù)進行壓縮傳輸，換句話說，當(dāng)網(wǎng)絡(luò)發(fā)生堵塞時，直接拋棄等待發(fā)送的幀，保證一旦網(wǎng)絡(luò)恢復(fù)時，發(fā)送最新的壓縮幀。當(dāng)然要保證一旦有一幀開始發(fā)送，就要將其完全發(fā)出。

按照這樣的“停等”策略進行實時視頻傳輸，只會帶來一個問題：當(dāng)網(wǎng)絡(luò)質(zhì)量差時，接收端畫面中的移動目標會出現(xiàn)瞬間移動的現(xiàn)象。但是這種策略會保證不會出現(xiàn)重影，抖動，花屏等現(xiàn)象。

結(jié)論

提出的實時視頻傳輸方案在100M的局域網(wǎng)、10M局域網(wǎng)和11M無線局域網(wǎng)中進行了測試。測試時讓一個目標在鏡頭前（發(fā)送端）移動，觀察接收端視頻的顯示。在不同的局域網(wǎng)中進行了多次測試，每次測試時間從10分鐘到30分鐘不等，并且改變目標的運動速度進行實驗。最后將數(shù)據(jù)匯總，得出統(tǒng)計結(jié)果。測試結(jié)果如表1所示。

表1不同局域網(wǎng)下的測試結(jié)果

劇烈運動

正常運動

緩慢運動

100M局域網(wǎng)

圖像清晰，很流暢

圖像清晰，很流暢

圖像清晰，很流暢

10M局域網(wǎng)

偶爾出現(xiàn)停頓，丟幀率1%左右

圖像清晰，人眼感覺流暢

圖像清晰，很流暢

11M無線局域網(wǎng)

經(jīng)常出現(xiàn)停頓，丟幀率5%-6%

經(jīng)常出現(xiàn)停頓，丟幀率2%-3%

偶爾出現(xiàn)停頓，丟幀率1%左右

其中，

注：11M無線網(wǎng)卡是通過USB1.0接口和PC機連接的，如果采用USB2.0接口效果會更好。

從實際測試的結(jié)果看，效果是良好的，除了出現(xiàn)瞬間移動外，圖像能夠保持清晰，消除了由于網(wǎng)絡(luò)質(zhì)量差而導(dǎo)致的重影、抖動等現(xiàn)象，對于不同的局域網(wǎng)都能滿足實時傳輸?shù)囊蟆?/p>

總結(jié)

以上是生活随笔為你收集整理的利用VC++实现局域网实时传输的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。