1 引言 基于IP網絡的嵌入式視頻服務器以體積小、功耗低、便攜、安裝方便等優點,成為前端視頻采集設備的監控系統。 本文介紹了自主開發的嵌入式視頻服務器方案。該方案采用嵌入式處理器Hi3510和操作系統μC1inux,通過自行開發的視頻服務器軟件,使客戶端完成與視頻服務器的通信和對云臺、攝像頭等設備的控制。論文介紹了服務器端軟件的總體結構以及視頻存儲(多磁盤調度算法)、RTP傳輸模塊的實現和發送緩沖區的結構設計,并進行了實驗測試。實驗結果表明,系統采用H.264編碼技術在保證視頻傳輸質量的同時具有良好的帶寬適應能力。 2 H.264視頻編碼技術 H.264是ITU-T視頻編碼專家組(VCEG)和ISO/IEC活動圖像編碼專家組(MPEG)的聯合視頻組(JVT)開發的一個新的數字視頻編碼標準。 在技術上,H.264標準有很多優勢,如統一的VLC符號編碼。高精度、多模式的位移估計,基于4*4塊的整數變換、分層的編碼語法等。這些措施使得H.264算法具有很高的編碼效率,在相同的重建圖像質量下,能夠比H.263降低50%左有的碼率。H.264的碼流結構網絡適應性強,增加了差錯恢復能力,能夠很好地適應IP和無線網絡。 H.264能以較低的數據速率傳送基于IP的視頻流,在視頻質量、壓縮效率和數據包恢復丟失等方面,超越了現有的MPEG-2、MPEG--4和H.26x視頻通訊標準,更適合窄帶傳輸,是目前監控系統最為理想的信源壓縮編碼標準。 3 視頻監控系統總體結構 如圖1所示,攝像頭將采集到的視頻傳送到視頻服務器,視頻服務器對視頻進行格式轉換與編碼后,通過Internet傳送到客戶端。通過客戶端軟件可以調整云臺的轉動和攝像頭的焦距、光圈等。 圖1視頻監控系統構成 圖1中的視頻服務器主要由4個模塊構成:視頻采集和模數轉換、H.264編碼、視頻存儲、RTP傳輸。從攝像頭采集到的多路視頻信號是模擬信號,視頻服務器需要將其轉化為數字信號,并將多路信號合成一路。H.264編碼模塊負責對輸入的圖像進行壓縮編碼。視頻存儲模塊負責將視頻流存儲在外接硬盤上,傳輸模塊基于RTP協議,負責將H.264視頻流傳送到遠程視頻終端。 服務器支持PC客戶端和手機客戶端同時瀏覽,大大增強了監控的移動性。服務器可外掛多個硬盤,具備硬盤錄像機的功能。安全性方面——支持異常檢測功能,當發現異物闖入時,自動報警并將發牛異常的場景網像以彩信的方式發至手機。 4 各模塊設計與實現 4.1視頻存儲多磁盤調度算法 為了增強視頻服務器的性能.增加了視頻存儲模塊,使之同時具有硬盤錄像機的功能。設計方面,通過在服務器上外掛多個硬盤來解決磁盤空間需求量大的問題。但這也帶來了另外一個問題:在多個硬盤的情況下如何進行有效的存儲調度,使得監控系統的多路同時存儲,保證有很高的效率。 本文參考文獻4的算法思想來解決多磁盤的有效存儲調度,即通過計算各磁盤剩余空間百分比和訪問線程數來確定新的存儲線程應該訪問的磁盤。算法描述如下: 1.計算各磁盤剩余空間大小。 2.計算各磁盤剩余空間的百分比:剩余空間,剩余總空間。 3.計算各磁盤訪問的最大線程數:最大線程數等于各磁盤剩余空間的百分比乘以系統總的存儲路數。并計算出1/2最大訪問線程數。 4.如果剩余空間百分比最大且未達到1/2最大訪問線程數,選擇此磁盤進行存儲.同時當前訪問線程數加1;如果達到或超過l/2最大訪問線程數,則選擇其它剩余空間百分比中最大且未達到1/2最大訪問線程數的磁盤。 5.如果所有硬盤的訪問線程數均達到1/2最大訪問線程數,則選擇剩余空間百分比最大且未達到最大訪問線程數的磁盤進行存儲。 6.如果每個硬盤都達到了最大訪問線程數.則無可用磁盤。 該算法利用各磁盤剩余空間百分比和當前訪問線程數來確定存儲的硬盤,避免了小空間硬盤不久就被用完,而最終所有視頻都存儲一個硬盤的情況。 4.2 RTP傳輸 視頻監控系統的關鍵是將視頻流通過Internet傳輸到遠程客戶端進行實時瀏覽,所以服務器端軟件傳輸部分的設計至關重要。由于TCP協議“三次握手”和數據重傳機制導致的延遲使其不適用于實時監控系統的視頻傳輸。本文采用目前流媒體廣泛采用的RTP傳輸協議,通過和UDP共同完成傳輸層協議功能。 RTP本身并不能為按順序傳送的數據包提供可靠的傳送機制,也不提供流量控制或擁塞控制,它依靠RTCP提供這些服務。在RTP會話之問周期地發送一些RTCP包,RTCP包中含有丟失的數據包的數量、傳輸延遲等統計資料。因此,服務器可以利用這些信息動態地改變編碼碼率。RTP和RTCP配合使用,能以有效的反饋和最小的開銷使傳輸效率最佳化,因而特別適用于實時監控系統。 圖2 反饋控制原理圖 如圖2所示,丟包率統計模塊生成接收報文并定期通過RTCP將報文發回服務器的反饋控制模塊,報文中含有丟包率和傳輸延遲等數據。反饋控制模塊根據報文評估當前網絡狀況,通知編碼器對碼率做出適當調整。 丟包率的計算: I.丟包大小的計算 計算在第n個周期丟包的大小:L(n)=S(n)一R(n); L(n)是第n個周期丟包的大小,S(n)是第n個周期服務器發送的包大小(包大小依據RTP包的序號獲得),R(n)是第n個周期客戶端收到的包大小。 II.丟包率P(n)=L(n)/S(n) 服務器端反饋控制模塊根據丟包率判斷當前網絡狀況.但為了避免頻繁地調整碼率不能只參考一個P(n)值。這里采用一種線性的數學方法來計算丟包率:計算5個P(n)值的平均值A(n)。 A(n)=(P(n)+P(n-1)+P(n-2)+P(n-3)+P(n-4))/5,n)=5 將網絡狀態分為三種情況:無負載(unloaded),負載(1oaded),擁塞(congested)。如果A(n)小于數值a網絡狀態為unloaded,介于a和b(包括a)之間為loaded,否則為congested。數值a和b的大小可以參考其它一些文獻。 4.3 發送緩沖區的設計 服務器將采集到的視頻數據編碼后放入緩沖區隊列,并發送給客戶端;客戶端接收視頻數據到接收緩沖區隊列,立即回放(如圖3)。 圖3視頻傳輸及緩沖區結構圖 在服務器端,首先使用SDK提供的GetStream函數獲得編碼碼流,在此,我們定義了視頻編碼碼流緩沖區的數據結構,用于記錄視頻編碼碼流數據。 struct VENC_STREAM_S{ usigned int DataNum; /* 產一幀碼流的所有片的個數 */ usigned int DataLen; /* 產一幀碼流的所有片長度總和 */ VENC_DATA_S struData [VENC_MAX_NALU_NUM_IN_FRAME]; /* 獲取碼流結構*/ VENC_STREAM_INFO_S struDataInfo; /* 嚴碼流信息 */ }; 5 系統測試及實驗結果分析 服務器對CIF和QCIF格式的視頻實現了實時傳輸,且很好地保證了視頻的質量。實驗主要測試了在不同碼率、GOP的條件下,視頻傳輸幀率和Y分量的PSNR值。實驗結果如表1所示。 表1不同碼率、GOP下的PSNR-Y的比較 從實驗結果可以看出,相同格式的視頻,在碼率相同的情況下,GOP小的視頻質量較好,這說明插入1幀可以有效地改善視頻的質量;而碼率的降低對視頻的傳輸和質量影響較大,產生了一定延遲。 6 結論 本文介紹了視頻服務器存儲(多磁盤調度算法)、RTP傳輸模塊的實現和發送緩沖區的結構設計,給出了軟件設計的基本思想。實驗表明,應用本文所設計的視頻服務器軟件,成功實現了視頻的實時傳輸,在保證視頻質量的同時具有良好的帶寬適應能力。 本文作者創新點:開發完成了嵌入式視頻服務器軟件的設計,加入了網絡傳輸反饋機制,增強了視頻服務器網絡帶寬的自適應性,保證了視頻的傳輸質量。 作者:李曉丹,周兵 來源:《微計算機信息》(嵌入式與SOC)2009年第3-2期 |