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