3G視頻監(jiān)控系統(tǒng)中關(guān)鍵技術(shù)的研究與實(shí)現(xiàn)
作者：
時(shí)間：2011-12-21
來(lái)源：網(wǎng)絡(luò)
收藏
加入技術(shù)交流群
掃碼加入
和技術(shù)大咖面對(duì)面交流
海量資料庫(kù)查詢(xún)
3 RTP協(xié)議封裝及改進(jìn)
本文采用RTP協(xié)議，提供了端對(duì)端傳輸服務(wù)的實(shí)時(shí)傳輸協(xié)議，用來(lái)支持在單播和多播網(wǎng)絡(luò)服務(wù)中傳輸實(shí)時(shí)數(shù)據(jù)，而實(shí)際數(shù)據(jù)的傳輸則由RTCP控制協(xié)議來(lái)監(jiān)視和控制。RTP協(xié)議一般要求與RTCP一起使用，來(lái)保證數(shù)據(jù)傳輸質(zhì)量。這種結(jié)構(gòu)在本次設(shè)計(jì)無(wú)線環(huán)境會(huì)遇到兩個(gè)問(wèn)題：
(1)如果增加RTCP，那么增加了復(fù)雜度，降低了實(shí)時(shí)性。
(2)RTP協(xié)議沒(méi)有加密信息，容易被非授權(quán)用戶(hù)瀏覽到視頻數(shù)據(jù)。
針對(duì)第一個(gè)問(wèn)題，本文提出一個(gè)策略，即在編碼端RTP打包時(shí)，在每個(gè)NAL單元頭的前面加上4個(gè)字節(jié)的幀的長(zhǎng)度，解碼端只要根據(jù)NAL單元的長(zhǎng)度，即可判斷是否在傳輸中有錯(cuò)誤，如果有將該NAL單元丟棄，此時(shí)無(wú)需采用RTCP來(lái)向監(jiān)控端反饋信息，從而降低實(shí)現(xiàn)復(fù)雜度；此時(shí)雖然丟棄了一個(gè)NAL單元，但是監(jiān)控端的幀率是20幀／s，根據(jù)人眼視覺(jué)殘留的效應(yīng)，這基本上不會(huì)引起人眼的察覺(jué)。這里還要說(shuō)明，當(dāng)NAL單元的幀長(zhǎng)大于MTU時(shí)，為了避免底層驅(qū)動(dòng)將其分包，需要應(yīng)用層采用分片打包方式，而此時(shí)只需在NAL單元的第一個(gè)分包增加4個(gè)字節(jié)的幀長(zhǎng)度信息，而無(wú)需在每個(gè)分包上都加上該字段。這樣在手機(jī)端無(wú)需返回RTCP包等反饋信息，降低了實(shí)現(xiàn)復(fù)雜度，增強(qiáng)了實(shí)時(shí)性。
針對(duì)第二個(gè)問(wèn)題，本文提出了一個(gè)簡(jiǎn)單加密方案，具體采用的策略是在關(guān)鍵幀后加上自定義加密信息，本設(shè)計(jì)為3 b的自定義信息，在解碼端只要判斷該RTP分包是關(guān)鍵幀，去掉RTP頭，然后去掉4個(gè)字節(jié)幀長(zhǎng)度信息，再去掉自定義3 b信息，而其他幀不做任何改變。當(dāng)解碼端收到RTP包時(shí)，對(duì)于非關(guān)鍵幀雖然能正常解包，但是它并不能獨(dú)立解碼，它必須依賴(lài)關(guān)鍵幀，因此關(guān)鍵幀加密后，只要關(guān)鍵幀不解密，其他幀都不能正常播放。這種方法無(wú)需在所有幀上都加入加密信息，只在關(guān)鍵幀RTP打包增加了幾個(gè)bit，就達(dá)到了比較好的加密效果，在應(yīng)用中要注意效率和復(fù)雜度的權(quán)衡來(lái)調(diào)整相應(yīng)方案。
4 無(wú)線視頻傳輸?shù)慕研匝芯?br /> 由于本文提出的視頻監(jiān)控系統(tǒng)，需要在3G無(wú)線網(wǎng)絡(luò)中傳輸，這勢(shì)必會(huì)受到各種因素的影響，這種干擾，輕微時(shí)不會(huì)淹沒(méi)正常圖像，而嚴(yán)重時(shí)圖像就無(wú)法觀看，或者由于無(wú)法捕捉到關(guān)鍵信息而無(wú)法顯示圖像。下面首先分析這種故障產(chǎn)生的原因：
(1)視頻編碼端本身的問(wèn)題。視頻編碼端傳輸線屏蔽性能差造成信號(hào)產(chǎn)生較大衰減。此外，編碼端也可能受到輻射、設(shè)施腐化等不定因素的影響，這也會(huì)產(chǎn)生同樣的問(wèn)題。
(2)無(wú)線傳輸環(huán)境的影響。無(wú)線信道中存在著Rayleigh衰減和多用戶(hù)干擾，會(huì)在傳輸位流中產(chǎn)生突發(fā)性錯(cuò)誤(Burst Error)。但壓縮后的碼流在無(wú)線信道中傳輸仍然存在一些棘手的問(wèn)題，一方面，這些壓縮后的碼流對(duì)信道比特誤碼非常敏感；另一方面，無(wú)線信道由于多徑反射和衰落引入了大量的隨機(jī)誤碼和突發(fā)誤碼，結(jié)果在解碼端將失去與編碼端的同步，同時(shí)預(yù)測(cè)編碼技術(shù)會(huì)將錯(cuò)誤擴(kuò)散到整個(gè)視頻序列中，降低了重建圖像的質(zhì)量。因此，為了實(shí)現(xiàn)良好質(zhì)量的視頻傳輸，必須結(jié)合無(wú)線信道的傳輸特性，采取一定的容錯(cuò)措施。
基于以上方面的考慮，以及斷續(xù)無(wú)法重連的問(wèn)題，本文提出一種方案，并在實(shí)踐中得到良好的驗(yàn)證，有效地解決了以上問(wèn)題：即在編碼端得到編碼序列后周期性地發(fā)送兩個(gè)參數(shù)集，即序列參數(shù)集和圖像參數(shù)集，由于它們包含了解碼需要的大部分關(guān)鍵信息，包括圖像大小、量化參數(shù)、NAL單元類(lèi)型等，因此即使在解碼端第一次無(wú)法與編碼端同步，也可以在后續(xù)過(guò)程中通過(guò)上述兩個(gè)參數(shù)集重新同步。未插入?yún)?shù)集之前、插入?yún)?shù)集之后的示意圖如圖3，圖4所示。本文引用地址：http://m.butianyuan.cn/article/187074.htm
本文的具體方案是在編碼端周期性地發(fā)送上面的兩個(gè)序列集，會(huì)遇到一個(gè)問(wèn)題，即發(fā)送間隔設(shè)置，這里提出H．264中一個(gè)重要概念I(lǐng)DR幀，由于編碼器算法是隔30幀編碼一個(gè)IDR幀，那么可以在這一個(gè)IDR幀之前加入上述兩個(gè)參數(shù)集，當(dāng)然也可以設(shè)置間隔為60，90幀，但這會(huì)引入更大延時(shí)，由于監(jiān)控產(chǎn)品嚴(yán)格的實(shí)時(shí)性要求，所以本文選定了隔30幀周期性發(fā)送，那么實(shí)際的關(guān)鍵幀間隔則變?yōu)?2幀。同時(shí)可以調(diào)整RTP協(xié)議里面的時(shí)間戳字段，使其配合關(guān)鍵幀間隔的變化。
評(píng)論