在局域網(wǎng)內(nèi)部實時傳輸視頻已經(jīng)得到廣泛應(yīng)用

在局域網(wǎng)內(nèi)部實時傳輸視頻已經(jīng)得到廣泛應(yīng)用

ID:30806766

大?。?8.00 KB

頁數(shù):7頁

時間:2019-01-03

在局域網(wǎng)內(nèi)部實時傳輸視頻已經(jīng)得到廣泛應(yīng)用_第1頁
在局域網(wǎng)內(nèi)部實時傳輸視頻已經(jīng)得到廣泛應(yīng)用_第2頁
在局域網(wǎng)內(nèi)部實時傳輸視頻已經(jīng)得到廣泛應(yīng)用_第3頁
在局域網(wǎng)內(nèi)部實時傳輸視頻已經(jīng)得到廣泛應(yīng)用_第4頁
在局域網(wǎng)內(nèi)部實時傳輸視頻已經(jīng)得到廣泛應(yīng)用_第5頁
資源描述:

《在局域網(wǎng)內(nèi)部實時傳輸視頻已經(jīng)得到廣泛應(yīng)用》由會員上傳分享,免費(fèi)在線閱讀,更多相關(guān)內(nèi)容在教育資源-天天文庫

1、.在局域網(wǎng)內(nèi)部實時傳輸視頻已經(jīng)得到廣泛應(yīng)用?,F(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)致嚴(yán)重的延遲現(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ā)包進(jìn)行二次開發(fā),通過Divx編解碼,按照制定的傳輸策略,能夠有效地解決由于網(wǎng)絡(luò)的局

2、部不穩(wěn)定導(dǎo)致的視頻圖像重影、抖動、花屏等的問題?! 【钟蚓W(wǎng)中實時視頻傳輸存在的問題  為了在局域網(wǎng)上有效的、高質(zhì)量的傳輸視頻流,需要多種技術(shù)的支持,包括視頻的壓縮、編碼技術(shù),應(yīng)用層質(zhì)量控制技術(shù)等等?! 【W(wǎng)絡(luò)的帶寬是有限的,所以需要壓縮傳輸視頻圖像,MPEG-4被廣泛的應(yīng)用于網(wǎng)絡(luò)環(huán)境下的實時視頻傳輸,因為MPEG-4具有:可以達(dá)到很高的壓縮比;具有靈活的編碼和解碼復(fù)雜性;基于對象的編碼方式,允許視頻、音頻對象的交互;具有很強(qiáng)的容錯能力等優(yōu)點。本文采用Divx編解碼器對視頻進(jìn)行編碼、壓縮,實際上Divx=(視頻)MPEG-4+(音頻)MP3。  應(yīng)用層質(zhì)量控制技術(shù)現(xiàn)在采用的是RTP/RTCP

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

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

5、  實時視頻傳輸實現(xiàn)  為了達(dá)到視頻傳輸?shù)膶崟r性,總的思想是最少的發(fā)送冗余信息,最大程度上發(fā)送最新的視頻?! 【钟蚓W(wǎng)實時視頻傳輸采用服務(wù)器/客戶機(jī)模式,利用VC++實現(xiàn)。其工作流程如圖1所示。圖1實時視頻傳輸工作流程  視頻采集采用AVICap從視頻采集卡捕獲視頻圖像,得到的是位圖型式的視頻幀,然后用Divx編碼器進(jìn)行壓縮,通過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ù)

6、,然后再回調(diào)函數(shù)中使用ICSeqCompressFrame()函數(shù)進(jìn)行壓縮。然后再通過Winsock將壓縮后的數(shù)據(jù)發(fā)送到服務(wù)器端。服務(wù)器端接收完一幀以后,交給ICDecompress()解壓,最后用SetDIBitsToDevice()將圖像顯示出來?! ?、視頻幀的組建  視頻采集的數(shù)據(jù)是位圖型式的視頻幀,Divx編碼器壓縮以后形成以幀為格式的Mpeg4流。Divx解碼器也是以幀的格式解壓。所以提出以幀為單位發(fā)送視頻數(shù)據(jù)流。為了在接收端能夠方便地提取出一幀,提出如圖2所示的格式組建幀。幀開始標(biāo)志幀大小幀編號幀類型幀數(shù)據(jù)圖2...視頻幀格式  完整的一幀由5個字段組成,各個字段的意義如下

7、:幀開始標(biāo)志,標(biāo)志著一幀地開始,占用4個字節(jié)的空間。不妨設(shè)為0xffffffff。幀大小,表示整個幀的大小,包括5個字段的大小,占用4個字節(jié)的空間。幀編號,表示幀的順序編號,占用4個字節(jié)的空間。幀類型,標(biāo)志此幀是否是關(guān)鍵幀,占用1個字節(jié)的空間。幀數(shù)據(jù),存放壓縮后一幀的完整數(shù)據(jù)?! ?、視頻幀的發(fā)送  實時視頻傳輸為了實時,要不斷地將壓縮好的數(shù)據(jù)發(fā)送到接受端。所以在發(fā)送端創(chuàng)建一個線程,專門用來發(fā)送數(shù)據(jù)。同時主線程仍然不停的采集數(shù)據(jù)并進(jìn)

當(dāng)前文檔最多預(yù)覽五頁,下載文檔查看全文

此文檔下載收益歸作者所有

當(dāng)前文檔最多預(yù)覽五頁,下載文檔查看全文
溫馨提示:
1. 部分包含數(shù)學(xué)公式或PPT動畫的文件,查看預(yù)覽時可能會顯示錯亂或異常,文件下載后無此問題,請放心下載。
2. 本文檔由用戶上傳,版權(quán)歸屬用戶,天天文庫負(fù)責(zé)整理代發(fā)布。如果您對本文檔版權(quán)有爭議請及時聯(lián)系客服。
3. 下載前請仔細(xì)閱讀文檔內(nèi)容,確認(rèn)文檔內(nèi)容符合您的需求后進(jìn)行下載,若出現(xiàn)內(nèi)容與標(biāo)題不符可向本站投訴處理。
4. 下載文檔時可能由于網(wǎng)絡(luò)波動等原因無法下載或下載錯誤,付費(fèi)完成后未能成功下載的用戶請聯(lián)系客服處理。