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