基于A(yíng)RM的移動(dòng)視頻監控終端設計與實(shí)現

摘要：以S3C2440硬件平臺為核心基于Linux操作系統實(shí)現移動(dòng)視頻監控終端的設計。設計系統的硬件平臺和軟件方案，監控終端通過(guò)無(wú)線(xiàn)網(wǎng)絡(luò )實(shí)現RTP協(xié)議下接收H．264視頻流，在網(wǎng)絡(luò )不穩定情況下接收視頻包時(shí)亂序、丟包的處理方法。利用開(kāi)源解碼庫ffmpeg實(shí)現視頻流解碼，顯示監控畫(huà)面。通過(guò)實(shí)驗表明，移動(dòng)視頻監控終端具有靈活性高，便于攜帶等特點(diǎn)，對于QCIF分辨率有較好的實(shí)時(shí)監控效果。
關(guān)鍵詞：ARM；RTP傳輸協(xié)議；H．264解碼技術(shù)；監控終端

0 引言
隨著(zhù)人們對生活和工作環(huán)境的安全性的要求不斷提高，安全防范的重要性越來(lái)越突出。視頻監控技術(shù)在各個(gè)領(lǐng)域發(fā)揮著(zhù)越來(lái)越重要的作用，比如對森林、旅游景點(diǎn)、城市小區等通過(guò)視頻監控來(lái)實(shí)時(shí)監控現場(chǎng)發(fā)生的情況。將嵌入式技術(shù)和無(wú)線(xiàn)網(wǎng)絡(luò )技術(shù)應用于視頻監控終端，與傳統的有線(xiàn)視頻監控相比，無(wú)線(xiàn)視頻監控擺脫了網(wǎng)絡(luò )電纜的束縛，提高了視頻監控的靈活性和可擴展性。監控人員可以攜帶手持監控設備而不必在固定位置值守來(lái)監控現場(chǎng)。
在無(wú)線(xiàn)網(wǎng)絡(luò )環(huán)境下傳輸視頻，龐大的視頻信息量對有限的傳輸帶寬是難以承受的，成為阻礙其應用的瓶頸之一，因此，需要高效率的視頻壓縮標準來(lái)滿(mǎn)足無(wú)線(xiàn)傳輸帶寬的需求。新一代視頻壓縮標準H．264是面向Internet和無(wú)線(xiàn)網(wǎng)絡(luò )的視頻圖像編解碼技術(shù)，它不僅提高了壓縮效率，而且增加了網(wǎng)絡(luò )適應能力，降低了網(wǎng)絡(luò )帶寬的需求。H．264標準定義了視頻編碼層VCL(Video Coding Layer)和網(wǎng)絡(luò )提取層NAL(Network Abstraction Layer)。視頻編碼層主要采用幀內預測、幀間預測、變換和量化、熵編解碼等技術(shù)實(shí)現視頻壓縮功能，網(wǎng)絡(luò )提取層將編碼后的數據封裝成NALU單元，以適應在無(wú)線(xiàn)網(wǎng)絡(luò )中傳輸。
移動(dòng)視頻監控終端以ARM微處理器為核心，剪裁適合視頻監控終端的嵌入式Linux操作系統。通過(guò)配備無(wú)線(xiàn)網(wǎng)卡接收監控前端壓縮視頻數據，解碼、顯示監控前端發(fā)送的視頻流，實(shí)時(shí)顯示前端監控畫(huà)面。本文將重點(diǎn)闡述在視頻傳輸過(guò)程中采用RTP／UDP／IP協(xié)議時(shí)，出現的視頻包亂序、丟包處理方法，以及在ARM平臺上對H．264解碼器的移植和實(shí)現。

1 系統的硬件平臺
系統硬件平臺主要由嵌入式微處理器、NANDFLASH，SDRAM，IEEE802．11協(xié)議無(wú)線(xiàn)網(wǎng)卡、LCD模塊組成。本系統的微處理器選用三星公司ARM9內核的S3C2440，系統時(shí)鐘采用400 MHz的工作頻率。S3C2440內部集成了大量的功能單元，包括：存儲器控制器有8個(gè)Bank區間、LCD控制器、USB控制器以及豐富的外設接口資源，根據視頻監控終端的需求，在此基礎上進(jìn)行外圍電路的配置和擴展。視頻監控終端硬件框圖如圖1所示。

存儲器包括ROM和RAM兩部分，ROM配備了非線(xiàn)性結構的K9F1208UOM容量為64M×8 b的NAND FLASH芯片；RAM配備2片HY57V561620BT—H組成32位數據總線(xiàn)的SDRAM，適用監控終端處理龐大視頻數據的需求。在USB Host接口上外接一塊基于IEEE802．11協(xié)議的無(wú)線(xiàn)網(wǎng)卡，通過(guò)無(wú)線(xiàn)AP端點(diǎn)接收監控前端視頻數據。液晶屏選用TFT真彩液晶屏，并配備相應的觸摸屏實(shí)現人機交互的目的。

2 系統的軟件設計
移動(dòng)視頻監控終端軟件設計以嵌入式Linux操作系統為核心，作為一種開(kāi)源操作系統，Linux具有支持多種硬件平臺、豐富的設備驅動(dòng)和良好的網(wǎng)絡(luò )功能等特點(diǎn)。針對監控終端的具體應用對內核進(jìn)行配置，剪裁出合適的系統。監控終端應用軟件是建立在操作系統之上，為實(shí)現RTP／UDP／IP協(xié)議下接收H．264視頻流和ffmpeg解碼庫實(shí)時(shí)解碼視頻流。
2．1 H．264視頻流的傳輸
2．1．1 傳輸方式選擇
視頻的實(shí)時(shí)傳輸要求較低的時(shí)間延遲，并且允許一定的丟包率。由于TCP協(xié)議的3次握手以及丟包重傳機制會(huì )造成一定的延時(shí)，在實(shí)時(shí)監控系統中有一定缺陷，而UDP協(xié)議是面向無(wú)鏈接、不可靠的傳輸層協(xié)議，具有消耗資源小，傳輸速度快等特點(diǎn)，在視頻傳輸過(guò)程中偶爾丟包不會(huì )對監控畫(huà)面產(chǎn)生較大影響。UDP協(xié)議不提供數據包分包、封裝、數據包排序等缺點(diǎn)，為保障視頻流傳輸的可靠性，網(wǎng)絡(luò )傳輸部分采用建立在UDP協(xié)議之上的RTP(Real-time Transport Protocol)實(shí)時(shí)傳輸協(xié)議來(lái)實(shí)現，通過(guò)套接字與前端建立連接，以接收視頻流數據。RTP提供帶有實(shí)時(shí)特性的端對端數據傳輸服務(wù)，包括有效載荷類(lèi)型的定義、序列號、時(shí)間戳和傳輸檢測控制。基于RTP／UDP／IP協(xié)議傳輸視頻流封裝格式如圖2所示。

2．1．2 視頻流傳輸
采用UDP協(xié)議傳輸RTP包時(shí)會(huì )出現亂序的現象，所謂亂序就是監控終端接收到RTP包順序可能前端發(fā)送的順序不一致，因此，首先要對接收的RTP包排序。采用在內存中建立一個(gè)雙向鏈表來(lái)保存接收的RTP包，按照RTP報頭的序列號(Sequence Number)順序存放到鏈表中，雙向鏈表結構體定義如下，部分變量用于RTP分片封包模式。

每當接收到一個(gè)新的RTP包后，根據序列號從鏈表尾開(kāi)始搜索并插入到合適的位置，比如，接收到一個(gè)序列號SN=26的RTP包在鏈表中分配內存，找到位于25，27之間的位置插入該包，RTP包排序過(guò)程如圖3所示。

H．264視頻流NALU單元封裝成RTP包時(shí)，要遵循RTP負載格式標準，H．264負載格式定義了3種類(lèi)型的負載結構：?jiǎn)我籒ALU模式、組合封包模式、分片封包模式。單一NALU模式是一個(gè)RTP包僅由一個(gè)完整的NALU組成；組合封包模式是可能由多個(gè)NALU組成一個(gè)RTP包；分片封包模式是將一個(gè)NALU單元封裝成多個(gè)RTP包，采用分片封包模式的原因是網(wǎng)絡(luò )傳輸協(xié)議有最大傳輸單元(MTU)一般為1500B上限，如果NALU大于MTU，IP層將其自動(dòng)分割為幾個(gè)小于MTU的數據包，這樣無(wú)法檢測數據包是否有丟失，所以有必要采取分片封包模式，在接收端把擁有相同時(shí)間戳的多個(gè)RTP包按照序列號重組成一個(gè)完整的NALU。分片封包模式的RTP包格式如圖4所示。

FU indicator的Type字段表示RTP采用的負載結構，28，29時(shí)表示采用分片封包模式，NRI字段的值根據NALU的NRI值設置。FU header的S位置1時(shí)表示該包是NALU的起始分片，E位置1時(shí)表示該包是NALU的結束分片。
2．1．3 RTP丟包處理
由于網(wǎng)絡(luò )穩定性原因，可能造成RTP丟包的情況。針對單一NALU模式和組合封包模式丟包不會(huì )影響解碼器的正常工作，會(huì )導致監控畫(huà)面花屏或跳幀想象，但對于實(shí)時(shí)監控是在可承受的范圍。對于分片封包模式丟包會(huì )造成接收端收到一個(gè)不完整的NALU，對一個(gè)不完整的NALU解碼可能造成解碼失敗，甚至系統崩潰。因此，對于分片封包模式的RTP包需要判斷接收的NALU是否丟包。
傳輸分片封包模式的NALU時(shí)，一個(gè)NALU分割封裝成若干個(gè)RTP包具有相同的時(shí)間戳、依次遞增的序列號。對接收的RTP包根據FU header頭信息做不同的處理：接收到起始分片(S=1)，根據序列號在鏈表中添加節點(diǎn)，保存視頻數據、起始分片序列號，計數器加1；接收到中間分片，在鏈表中找到時(shí)間戳相同的節點(diǎn)，將此RTP包序列號與起始序列號相減，計算出視頻數據在鏈表的相對偏移，存儲視頻數據到鏈表相應位置，計數器加1；接收到結束分片(E=1)，同中間分片一樣，但還需要保存結束分片序列號。每接收一個(gè)RTP包后判斷NALU完整性，在接收到起始分片、結束分片的前提下，結束分片序列號與起始分片序列號之差是否等于計數器的值，以此判斷一個(gè)NALU是否接收完整，若接收到所有分片，置位結構體中FrameCompelere，解碼器可根據此位判斷NALU完整性。
2．2 H．264解碼器的實(shí)現
監控終端通過(guò)網(wǎng)絡(luò )接收到H．264視頻流后，需要移植H．264的解碼庫實(shí)現實(shí)時(shí)解碼。在眾多解碼器中經(jīng)對比和分析，選用ffmpeg開(kāi)源解碼器來(lái)實(shí)現。ffmpeg庫為音視頻數據分離、轉換、解碼提供了完整解決方案，其中兩個(gè)重要庫libavformat和libavcodec，分別支持各種音視頻文件格式和音視頻解碼器。
利用ffmpeg的API函數進(jìn)行視頻流解碼，先做好解碼前的準備工作。調用av_register_all()函數注冊所有的文件格式和編解碼器的庫，也可以只注冊特定的解碼器。關(guān)于解碼器的信息在A(yíng)VCodecContext結構體中，它包含解碼器所有信息，查找H．264解碼器CODEC_ID_H264，通過(guò)avcodec_open()函數打開(kāi)解碼器。用avcodec_alloc_frame()函數分配一幀的存儲空間，存儲解碼后輸出的數據。
在雙向鏈表中已經(jīng)保存了接收的視頻流，從鏈表頭讀取NALU進(jìn)行解碼，每讀取一個(gè)NALU將鏈表頭指向下一個(gè)單元，釋放已讀取NALU占有的內存。NALU的頭信息定義了視頻流所屬類(lèi)型，一般包括增強信息(SEI)、序列參數集(SPS)、圖像參數集(PPS)、條帶(Slice)等。先將SPS、PPS參數集通過(guò)解碼器解碼出來(lái)設置解碼圖像尺寸、片組數、參考幀數、量化和濾波參數等。依次從鏈表頭讀取NALU，調用avcodec_decode_ video()函數解碼輸出到分配的存儲空間，當完成一幀的解碼，就需要對解碼后的圖像顯示到液晶屏。解碼輸出的圖像格式為YUV420P，可以采用ffmpeg提供的sws_seale()把圖像格式轉換為RGB格式顯示，也可以采用其他SDL之類(lèi)的庫直接YUV覆蓋顯示。整個(gè)解碼流程如圖5所示。

3 結語(yǔ)
系統采用S3C2440硬件平臺和嵌入式Linux操作系統相結合，設計了移動(dòng)視頻監控終端，重點(diǎn)闡述了用RTP協(xié)議在網(wǎng)絡(luò )中通過(guò)套接字傳輸視頻流，結合開(kāi)源解碼庫ffmpeg實(shí)時(shí)解碼H．264視頻流的解決方案。經(jīng)測試，對于QCIF分辨率監控畫(huà)面具有較好的實(shí)時(shí)性和可靠性。當視頻分辨率增大時(shí)，解碼器的解碼性能成為視頻監控終端的瓶頸。因此，本文的后續工作就是針對ffmpeg解碼庫在A(yíng)RM9平臺的優(yōu)化，提升解碼性能。