基于ARM的移動視頻監(jiān)控終端設(shè)計與實現(xiàn)
摘要:以S3C2440硬件平臺為核心基于Linux操作系統(tǒng)實現(xiàn)移動視頻監(jiān)控終端的設(shè)計。設(shè)計系統(tǒng)的硬件平臺和軟件方案,監(jiān)控終端通過無線網(wǎng)絡(luò)實現(xiàn)RTP協(xié)議下接收H.264視頻流,在網(wǎng)絡(luò)不穩(wěn)定情況下接收視頻包時亂序、丟包的處理方法。利用開源解碼庫ffmpeg實現(xiàn)視頻流解碼,顯示監(jiān)控畫面。通過實驗表明,移動視頻監(jiān)控終端具有靈活性高,便于攜帶等特點,對于QCIF分辨率有較好的實時監(jiān)控效果。
關(guān)鍵詞:ARM;RTP傳輸協(xié)議;H.264解碼技術(shù);監(jiān)控終端
0 引言
隨著人們對生活和工作環(huán)境的安全性的要求不斷提高,安全防范的重要性越來越突出。視頻監(jiān)控技術(shù)在各個領(lǐng)域發(fā)揮著越來越重要的作用,比如對森林、旅游景點、城市小區(qū)等通過視頻監(jiān)控來實時監(jiān)控現(xiàn)場發(fā)生的情況。將嵌入式技術(shù)和無線網(wǎng)絡(luò)技術(shù)應(yīng)用于視頻監(jiān)控終端,與傳統(tǒng)的有線視頻監(jiān)控相比,無線視頻監(jiān)控擺脫了網(wǎng)絡(luò)電纜的束縛,提高了視頻監(jiān)控的靈活性和可擴(kuò)展性。監(jiān)控人員可以攜帶手持監(jiān)控設(shè)備而不必在固定位置值守來監(jiān)控現(xiàn)場。
在無線網(wǎng)絡(luò)環(huán)境下傳輸視頻,龐大的視頻信息量對有限的傳輸帶寬是難以承受的,成為阻礙其應(yīng)用的瓶頸之一,因此,需要高效率的視頻壓縮標(biāo)準(zhǔn)來滿足無線傳輸帶寬的需求。新一代視頻壓縮標(biāo)準(zhǔn)H.264是面向Internet和無線網(wǎng)絡(luò)的視頻圖像編解碼技術(shù),它不僅提高了壓縮效率,而且增加了網(wǎng)絡(luò)適應(yīng)能力,降低了網(wǎng)絡(luò)帶寬的需求。H.264標(biāo)準(zhǔn)定義了視頻編碼層VCL(Video Coding Layer)和網(wǎng)絡(luò)提取層NAL(Network Abstraction Layer)。視頻編碼層主要采用幀內(nèi)預(yù)測、幀間預(yù)測、變換和量化、熵編解碼等技術(shù)實現(xiàn)視頻壓縮功能,網(wǎng)絡(luò)提取層將編碼后的數(shù)據(jù)封裝成NALU單元,以適應(yīng)在無線網(wǎng)絡(luò)中傳輸。
移動視頻監(jiān)控終端以ARM微處理器為核心,剪裁適合視頻監(jiān)控終端的嵌入式Linux操作系統(tǒng)。通過配備無線網(wǎng)卡接收監(jiān)控前端壓縮視頻數(shù)據(jù),解碼、顯示監(jiān)控前端發(fā)送的視頻流,實時顯示前端監(jiān)控畫面。本文將重點闡述在視頻傳輸過程中采用RTP/UDP/IP協(xié)議時,出現(xiàn)的視頻包亂序、丟包處理方法,以及在ARM平臺上對H.264解碼器的移植和實現(xiàn)。
1 系統(tǒng)的硬件平臺
系統(tǒng)硬件平臺主要由嵌入式微處理器、NANDFLASH,SDRAM,IEEE802.11協(xié)議無線網(wǎng)卡、LCD模塊組成。本系統(tǒng)的微處理器選用三星公司ARM9內(nèi)核的S3C2440,系統(tǒng)時鐘采用400 MHz的工作頻率。S3C2440內(nèi)部集成了大量的功能單元,包括:存儲器控制器有8個Bank區(qū)間、LCD控制器、USB控制器以及豐富的外設(shè)接口資源,根據(jù)視頻監(jiān)控終端的需求,在此基礎(chǔ)上進(jìn)行外圍電路的配置和擴(kuò)展。視頻監(jiān)控終端硬件框圖如圖1所示。
存儲器包括ROM和RAM兩部分,ROM配備了非線性結(jié)構(gòu)的K9F1208UOM容量為64M×8 b的NAND FLASH芯片;RAM配備2片HY57V561620BT—H組成32位數(shù)據(jù)總線的SDRAM,適用監(jiān)控終端處理龐大視頻數(shù)據(jù)的需求。在USB Host接口上外接一塊基于IEEE802.11協(xié)議的無線網(wǎng)卡,通過無線AP端點接收監(jiān)控前端視頻數(shù)據(jù)。液晶屏選用TFT真彩液晶屏,并配備相應(yīng)的觸摸屏實現(xiàn)人機(jī)交互的目的。
2 系統(tǒng)的軟件設(shè)計
移動視頻監(jiān)控終端軟件設(shè)計以嵌入式Linux操作系統(tǒng)為核心,作為一種開源操作系統(tǒng),Linux具有支持多種硬件平臺、豐富的設(shè)備驅(qū)動和良好的網(wǎng)絡(luò)功能等特點。針對監(jiān)控終端的具體應(yīng)用對內(nèi)核進(jìn)行配置,剪裁出合適的系統(tǒng)。監(jiān)控終端應(yīng)用軟件是建立在操作系統(tǒng)之上,為實現(xiàn)RTP/UDP/IP協(xié)議下接收H.264視頻流和ffmpeg解碼庫實時解碼視頻流。
2.1 H.264視頻流的傳輸
2.1.1 傳輸方式選擇
視頻的實時傳輸要求較低的時間延遲,并且允許一定的丟包率。由于TCP協(xié)議的3次握手以及丟包重傳機(jī)制會造成一定的延時,在實時監(jiān)控系統(tǒng)中有一定缺陷,而UDP協(xié)議是面向無鏈接、不可靠的傳輸層協(xié)議,具有消耗資源小,傳輸速度快等特點,在視頻傳輸過程中偶爾丟包不會對監(jiān)控畫面產(chǎn)生較大影響。UDP協(xié)議不提供數(shù)據(jù)包分包、封裝、數(shù)據(jù)包排序等缺點,為保障視頻流傳輸?shù)目煽啃?,網(wǎng)絡(luò)傳輸部分采用建立在UDP協(xié)議之上的RTP(Real-time Transport Protocol)實時傳輸協(xié)議來實現(xiàn),通過套接字與前端建立連接,以接收視頻流數(shù)據(jù)。RTP提供帶有實時特性的端對端數(shù)據(jù)傳輸服務(wù),包括有效載荷類型的定義、序列號、時間戳和傳輸檢測控制。基于RTP/UDP/IP協(xié)議傳輸視頻流封裝格式如圖2所示。
2.1.2 視頻流傳輸
采用UDP協(xié)議傳輸RTP包時會出現(xiàn)亂序的現(xiàn)象,所謂亂序就是監(jiān)控終端接收到RTP包順序可能前端發(fā)送的順序不一致,因此,首先要對接收的RTP包排序。采用在內(nèi)存中建立一個雙向鏈表來保存接收的RTP包,按照RTP報頭的序列號(Sequence Number)順序存放到鏈表中,雙向鏈表結(jié)構(gòu)體定義如下,部分變量用于RTP分片封包模式。
每當(dāng)接收到一個新的RTP包后,根據(jù)序列號從鏈表尾開始搜索并插入到合適的位置,比如,接收到一個序列號SN=26的RTP包在鏈表中分配內(nèi)存,找到位于25,27之間的位置插入該包,RTP包排序過程如圖3所示。
H.264視頻流NALU單元封裝成RTP包時,要遵循RTP負(fù)載格式標(biāo)準(zhǔn),H.264負(fù)載格式定義了3種類型的負(fù)載結(jié)構(gòu):單一NALU模式、組合封包模式、分片封包模式。單一NALU模式是一個RTP包僅由一個完整的NALU組成;組合封包模式是可能由多個NALU組成一個RTP包;分片封包模式是將一個NALU單元封裝成多個RTP包,采用分片封包模式的原因是網(wǎng)絡(luò)傳輸協(xié)議有最大傳輸單元(MTU)一般為1500B上限,如果NALU大于MTU,IP層將其自動分割為幾個小于MTU的數(shù)據(jù)包,這樣無法檢測數(shù)據(jù)包是否有丟失,所以有必要采取分片封包模式,在接收端把擁有相同時間戳的多個RTP包按照序列號重組成一個完整的NALU。分片封包模式的RTP包格式如圖4所示。
FU indicator的Type字段表示RTP采用的負(fù)載結(jié)構(gòu),28,29時表示采用分片封包模式,NRI字段的值根據(jù)NALU的NRI值設(shè)置。FU header的S位置1時表示該包是NALU的起始分片,E位置1時表示該包是NALU的結(jié)束分片。
2.1.3 RTP丟包處理
由于網(wǎng)絡(luò)穩(wěn)定性原因,可能造成RTP丟包的情況。針對單一NALU模式和組合封包模式丟包不會影響解碼器的正常工作,會導(dǎo)致監(jiān)控畫面花屏或跳幀想象,但對于實時監(jiān)控是在可承受的范圍。對于分片封包模式丟包會造成接收端收到一個不完整的NALU,對一個不完整的NALU解碼可能造成解碼失敗,甚至系統(tǒng)崩潰。因此,對于分片封包模式的RTP包需要判斷接收的NALU是否丟包。
傳輸分片封包模式的NALU時,一個NALU分割封裝成若干個RTP包具有相同的時間戳、依次遞增的序列號。對接收的RTP包根據(jù)FU header頭信息做不同的處理:接收到起始分片(S=1),根據(jù)序列號在鏈表中添加節(jié)點,保存視頻數(shù)據(jù)、起始分片序列號,計數(shù)器加1;接收到中間分片,在鏈表中找到時間戳相同的節(jié)點,將此RTP包序列號與起始序列號相減,計算出視頻數(shù)據(jù)在鏈表的相對偏移,存儲視頻數(shù)據(jù)到鏈表相應(yīng)位置,計數(shù)器加1;接收到結(jié)束分片(E=1),同中間分片一樣,但還需要保存結(jié)束分片序列號。每接收一個RTP包后判斷NALU完整性,在接收到起始分片、結(jié)束分片的前提下,結(jié)束分片序列號與起始分片序列號之差是否等于計數(shù)器的值,以此判斷一個NALU是否接收完整,若接收到所有分片,置位結(jié)構(gòu)體中FrameCompelere,解碼器可根據(jù)此位判斷NALU完整性。
2.2 H.264解碼器的實現(xiàn)
監(jiān)控終端通過網(wǎng)絡(luò)接收到H.264視頻流后,需要移植H.264的解碼庫實現(xiàn)實時解碼。在眾多解碼器中經(jīng)對比和分析,選用ffmpeg開源解碼器來實現(xiàn)。ffmpeg庫為音視頻數(shù)據(jù)分離、轉(zhuǎn)換、解碼提供了完整解決方案,其中兩個重要庫libavformat和libavcodec,分別支持各種音視頻文件格式和音視頻解碼器。
利用ffmpeg的API函數(shù)進(jìn)行視頻流解碼,先做好解碼前的準(zhǔn)備工作。調(diào)用av_register_all()函數(shù)注冊所有的文件格式和編解碼器的庫,也可以只注冊特定的解碼器。關(guān)于解碼器的信息在AVCodecContext結(jié)構(gòu)體中,它包含解碼器所有信息,查找H.264解碼器CODEC_ID_H264,通過avcodec_open()函數(shù)打開解碼器。用avcodec_alloc_frame()函數(shù)分配一幀的存儲空間,存儲解碼后輸出的數(shù)據(jù)。
在雙向鏈表中已經(jīng)保存了接收的視頻流,從鏈表頭讀取NALU進(jìn)行解碼,每讀取一個NALU將鏈表頭指向下一個單元,釋放已讀取NALU占有的內(nèi)存。NALU的頭信息定義了視頻流所屬類型,一般包括增強信息(SEI)、序列參數(shù)集(SPS)、圖像參數(shù)集(PPS)、條帶(Slice)等。先將SPS、PPS參數(shù)集通過解碼器解碼出來設(shè)置解碼圖像尺寸、片組數(shù)、參考幀數(shù)、量化和濾波參數(shù)等。依次從鏈表頭讀取NALU,調(diào)用avcodec_decode_ video()函數(shù)解碼輸出到分配的存儲空間,當(dāng)完成一幀的解碼,就需要對解碼后的圖像顯示到液晶屏。解碼輸出的圖像格式為YUV420P,可以采用ffmpeg提供的sws_seale()把圖像格式轉(zhuǎn)換為RGB格式顯示,也可以采用其他SDL之類的庫直接YUV覆蓋顯示。整個解碼流程如圖5所示。
3 結(jié)語
系統(tǒng)采用S3C2440硬件平臺和嵌入式Linux操作系統(tǒng)相結(jié)合,設(shè)計了移動視頻監(jiān)控終端,重點闡述了用RTP協(xié)議在網(wǎng)絡(luò)中通過套接字傳輸視頻流,結(jié)合開源解碼庫ffmpeg實時解碼H.264視頻流的解決方案。經(jīng)測試,對于QCIF分辨率監(jiān)控畫面具有較好的實時性和可靠性。當(dāng)視頻分辨率增大時,解碼器的解碼性能成為視頻監(jiān)控終端的瓶頸。因此,本文的后續(xù)工作就是針對ffmpeg解碼庫在ARM9平臺的優(yōu)化,提升解碼性能。
linux相關(guān)文章:linux教程
評論