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