局域網(wǎng)視頻傳輸

千里之行，始于腳下。第2頁(yè)/共2頁(yè)精品文檔推薦局域網(wǎng)視頻傳輸利用VC++實(shí)現(xiàn)局域網(wǎng)實(shí)時(shí)視頻傳輸(圖)

平安中國(guó).更新時(shí)光:2023-05-2700:32:16責(zé)任編輯:ShellExp

熱點(diǎn)：

方式，允許視頻、音頻對(duì)象的交互；具有很強(qiáng)的容錯(cuò)能力等優(yōu)點(diǎn)。本文采納Di編解碼器對(duì)視頻舉行編碼、壓縮，實(shí)際上Di=（視頻）MPEG-4+（音頻）MP3。

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

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

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

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

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

圖1實(shí)時(shí)視頻傳輸工作流程

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

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

1、視頻幀的組建

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

幀開(kāi)頭標(biāo)志幀大小幀編號(hào)幀類(lèi)型幀數(shù)據(jù)

圖2視頻幀格式

完整的一幀由5個(gè)字段組成，各個(gè)字段的意義如下：幀開(kāi)頭標(biāo)志，標(biāo)志著一幀地開(kāi)頭，占用4個(gè)字節(jié)的空間。不妨設(shè)為0xffffffff。幀大小，表示囫圇幀的大小，包括5個(gè)字段的大小，占用4個(gè)字節(jié)的空間。幀編號(hào)，表示幀的挨次編號(hào)，占用4個(gè)字節(jié)的空間。幀類(lèi)型，標(biāo)志此幀是否是關(guān)鍵幀，占用1個(gè)字節(jié)的空間。幀數(shù)據(jù)，存放壓縮后一幀的完整數(shù)據(jù)。

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

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

圖3發(fā)送線程工作流程

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

while(1)

{

isOK=true;//預(yù)備就緒

SuspendThread(sendThread);//掛起線程

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

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

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

intn=0;

intsendCount=0;

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

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

3、視頻幀的接收

接收端最重要的是從接受的數(shù)據(jù)流中提取出完整的一幀。辦法的思想是：首先從數(shù)據(jù)

流中尋覓幀開(kāi)頭標(biāo)志，再?gòu)木o挨后面的數(shù)據(jù)中提取出幀的大小，然后再?gòu)慕邮站彌_區(qū)中讀

入該幀剩余的數(shù)據(jù)。再尋覓下一幀的開(kāi)頭標(biāo)志，如此往復(fù)。圖4是接收端的工作流程。

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

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

4、“停等”控制策略

假如局域網(wǎng)通信速率很高，而且工作穩(wěn)定，則根據(jù)以上說(shuō)的辦法舉行實(shí)時(shí)視頻傳輸，不需要任何控制策略，就可以達(dá)到十分好的效果。但是在無(wú)數(shù)狀況下，網(wǎng)絡(luò)會(huì)浮現(xiàn)異樣，這樣會(huì)導(dǎo)致數(shù)據(jù)傳輸率顯然下降，造成發(fā)送端數(shù)據(jù)積壓，等待發(fā)送的數(shù)據(jù)不能正常發(fā)出去。此時(shí)就要實(shí)行一定的策略來(lái)控制發(fā)送端，以達(dá)到實(shí)時(shí)性的要求。

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

根據(jù)這樣的“停等”策略舉行實(shí)時(shí)視頻傳輸，只會(huì)帶來(lái)一個(gè)問(wèn)題：當(dāng)網(wǎng)絡(luò)質(zhì)量差時(shí)，接收端畫(huà)面中的移動(dòng)目標(biāo)會(huì)浮現(xiàn)眨眼移動(dòng)的現(xiàn)象。但是這種策略會(huì)保證不會(huì)浮現(xiàn)重影，顫動(dòng)，花屏等現(xiàn)象。

結(jié)論

本文提出的實(shí)時(shí)視頻傳輸計(jì)劃在100M的局域網(wǎng)、10M局域網(wǎng)和11M無(wú)線局域網(wǎng)中舉行了測(cè)試。測(cè)試時(shí)讓一個(gè)目標(biāo)在鏡頭前（發(fā)送端）移動(dòng)，觀看接收端視頻的顯示。在不同的局域網(wǎng)中舉行了多次測(cè)試，每次測(cè)試時(shí)光從10分鐘到30分鐘不等，并且轉(zhuǎn)變目標(biāo)的運(yùn)動(dòng)速度舉行試驗(yàn)。最后將數(shù)據(jù)匯總，得出統(tǒng)計(jì)結(jié)果。測(cè)試結(jié)果如表1所示。

表1不同局域網(wǎng)下