地鐵設(shè)備巡檢移動終端視頻實時傳輸應(yīng)用

傅 強 陳穎峰 柏 云 陸相成

(國電南瑞科技股份有限公司 南京 210061)

地鐵設(shè)備巡檢移動終端視頻實時傳輸應(yīng)用

傅 強 陳穎峰 柏 云 陸相成

(國電南瑞科技股份有限公司 南京 210061)

針對地鐵設(shè)備巡檢工作中對實時視頻信息采集的需求，研究在WiFi(無線通信)環(huán)境下， Android(安卓)平臺的地鐵設(shè)備巡檢移動終端的視頻實時傳輸功能。功能實現(xiàn)包括視頻采集端和視頻播放端，視頻采集端負責(zé)采集視頻數(shù)據(jù)、數(shù)據(jù)壓縮和數(shù)據(jù)包封裝，視頻播放端則負責(zé)接收解析數(shù)據(jù)包，將數(shù)據(jù)進行解碼播放。在H.264視頻壓縮技術(shù)，實時傳輸協(xié)議以及流媒體服務(wù)器等相關(guān)技術(shù)的基礎(chǔ)上，實現(xiàn)了WiFi環(huán)境下視頻實時傳輸、播放等功能，且傳輸過程中視頻傳輸流暢、延遲較小、丟包率低。

地鐵；設(shè)備巡檢；Android終端；視頻實時傳輸；視頻壓縮；實時傳輸協(xié)議

地鐵是典型的設(shè)備資產(chǎn)密集、安全要求很高的行業(yè)，設(shè)備巡檢是地鐵運營管理工作的重中之重，是保障設(shè)備安全、運行可靠的重要手段。

隨著越來越多地鐵線路的開通運營以及信息技術(shù)的不斷發(fā)展，以往基于文字臺賬形式的設(shè)備巡檢工作方式已不能滿足運營管理人員對現(xiàn)場設(shè)備運行情況的掌控需求。為了能有效掌控設(shè)備現(xiàn)場的運行情況，越來越多的運營管理人員提出了在設(shè)備巡檢過程中，能實時獲取現(xiàn)場設(shè)備運行狀態(tài)視頻數(shù)據(jù)的要求。

在此基礎(chǔ)上，將視頻算法運行于移動終端上，實現(xiàn)了視頻采集、編碼、傳輸?shù)裙δ?，視頻的播放及分析應(yīng)用也可于移動終端實現(xiàn)，替代了傳統(tǒng)的監(jiān)控顯示器[3]。

1 系統(tǒng)結(jié)構(gòu)

1.1 框架結(jié)構(gòu)

該系統(tǒng)可以分為攝像頭端(服務(wù)端)和監(jiān)控端(客戶端)兩大組成部分。在整個系統(tǒng)中，攝像頭端功能模塊有視頻數(shù)據(jù)采集、視頻實時存儲、智能視頻監(jiān)控、實時報警和實時通信；監(jiān)控端功能模塊有視頻實時顯示、報警視頻存儲、報警信息存儲和實時通信。

該系統(tǒng)主要實現(xiàn)了攝像頭端和監(jiān)控端之間視頻采集、視頻實時傳輸和視頻播放的功能，攝像頭端和監(jiān)控端之間通過無線網(wǎng)絡(luò)進行連接和數(shù)據(jù)傳輸。系統(tǒng)硬件結(jié)構(gòu)如圖1所示。

圖1 系統(tǒng)硬件結(jié)構(gòu)

1.2 軟件設(shè)計

在無線WiFi的網(wǎng)絡(luò)環(huán)境中，可以很容易地獲取各個終端的公網(wǎng)IP地址，所以用移動終端直連的方式就可以完成視頻傳輸，系統(tǒng)的軟件結(jié)構(gòu)如圖2所示。

圖2 系統(tǒng)軟件結(jié)構(gòu)

視頻采集端分成4個模塊：視頻采集模塊、H.264視頻編碼模塊[4]、RTP(Real-time Transport Protocol，實時傳輸協(xié)議)打包模塊[5]、RTSP (Real Time Streaming Protocol，實時流傳輸協(xié)議)服務(wù)器。

視頻播放端分成4個模塊： RTSP響應(yīng)和解析模塊、RTP解包模塊、視頻解碼模塊、視頻播放模塊。

2 通信機制

2.1 軟件流程

視頻采集端和播放端的軟件工作流如圖3所示。

圖3 視頻傳輸系統(tǒng)工作流

利用Android移動終端的攝像頭作為視頻采集設(shè)備，獲得視頻數(shù)據(jù)后用H.264格式進行編碼，然后根據(jù)RTP協(xié)議加包頭，最后根據(jù)RTSP協(xié)議建立RTSP服務(wù)器。傳輸層使用UDP(user datagram protocol，用戶數(shù)據(jù)報協(xié)議)協(xié)議數(shù)據(jù)到達客戶端后，經(jīng)過RTSP響應(yīng)和解析、RTP解封裝、H.264解碼還原數(shù)據(jù)流，最后形成視頻在Android移動終端上播放。

2.2 視頻采集端

2.2.1 視頻采集

建在MediaRecorder類，設(shè)置視頻的輸出格式為THREE_GPP，視頻采集圖像頻率為24 fps，像素大小為640×480，視頻編碼是H.264。

創(chuàng)建一個錄制視頻的線程，使用Android OS自帶的本地套接字(LocalSocket)和本地服務(wù)器套接字(LocalServerSocket)進行視頻數(shù)據(jù)的緩存，服務(wù)器端和客戶端分別定義一個500 KB大小的LocalSocket，服務(wù)器端將攝像頭的數(shù)據(jù)緩存后發(fā)送給客戶端的LocalSocket，最后使用客戶端LocalSocket 中的數(shù)據(jù)作為RTP 封裝數(shù)據(jù)的來源，這樣采集端的緩存大小為2×500 KB。

2.2.2 RTP封裝實現(xiàn)

LocalSocket中的數(shù)據(jù)是H.264的原始數(shù)據(jù)流，必須剝離出每個網(wǎng)絡(luò)抽象單元(network abstract layer unit，NALU)，在每個NALU 前添加相應(yīng)的RTP 包頭，最后才能將包含RTP 包頭和NALU 的數(shù)據(jù)包發(fā)送出去[6]。由于以太網(wǎng)中最大傳輸單元(maximum transmission unit，MTU)大小1 500 B的限制，為了保證視頻數(shù)據(jù)傳輸?shù)耐暾?，本系統(tǒng)規(guī)定RTP 包最大的為20+1 400 B，20 B為RTP 的首部大小，1 400 B為NALU大小。

采用RFC3984提供的single NALU packet和fragmentation unit兩種打包方式，將小于1 400 B的NALU封裝到一個RTP包中，大于1 400 B的NALU進行拆包，拆成最大為1 400 B的NALU進行封裝[7]。具體打包流程如圖4所示。

圖4 RTP打包流程

2.2.3 RTSP服務(wù)器的實現(xiàn)

1) 客戶端給服務(wù)器端發(fā)送OPTION 請求消息，詢問服務(wù)器有哪些方法可用，服務(wù)器回復(fù)OPTION，回應(yīng)信息提供的所有可用方法。

2) 客戶端給服務(wù)器發(fā)送 DESCRIBE請求消息，要求得到服務(wù)器提供的媒體初始化描述信息，服務(wù)器的DESCRIBE 信息中回應(yīng)初始化描述信息SDP。

3) 客戶端給服務(wù)器發(fā)送SETUP請求消息，設(shè)置會話的屬性，以及傳輸模式，并提醒服務(wù)器建立會話，服務(wù)器的SETUP 回應(yīng)消息建立會話，返回會話標(biāo)識符以及會話相關(guān)信息。

4) 建立好會話后，客戶端可以提出PLAY請求播放信息，服務(wù)器回應(yīng)PLAY回應(yīng)該請求信息，然后服務(wù)器便可以給客戶端發(fā)送流媒體數(shù)據(jù)。

2.3 視頻播放端

由于Android平臺不能解碼高壓縮比例的H.264，故本系統(tǒng)移植了當(dāng)前被應(yīng)用最廣泛的編解碼軟件庫FFMPEG進行解碼播放。FFMPEG[10]是基于Linux 系統(tǒng)開發(fā)的使用C 語言實現(xiàn)的，可以被集成到各種PC軟件和嵌入式設(shè)備中。

使用NDK 自帶的交叉編譯器對FFMPEG進行移植，移植步驟為：替換FFMPEG里的Makefile 文件為NDK中的Android.mk文件；依次編譯FFMPEG的3個主要函數(shù)庫libavutil.a，libavcodec.a和libvformat.a。

2.3.1 流媒體數(shù)據(jù)接收

從流媒體服務(wù)器獲取媒體數(shù)據(jù)信息包括前期會話協(xié)商部分和數(shù)據(jù)緩沖部分。

數(shù)據(jù)緩沖部分使用FFMPEG底層接受RTP包，為了防止因為網(wǎng)絡(luò)情況變化引起的RTP數(shù)據(jù)包延時或者抖動情況，系統(tǒng)中為流媒體播放器分配了一個視頻緩沖區(qū)，當(dāng)網(wǎng)絡(luò)中的RTP包到達接收端后，緩沖區(qū)中的數(shù)據(jù)包按照RTP的序號遞增方式、雙向循環(huán)隊列的數(shù)據(jù)結(jié)構(gòu)存儲。當(dāng)一個RTP數(shù)據(jù)包傳入時，首先判斷隊列中是否有RTP包，若隊列為空則直接將RTP包插入隊列，若隊列不為空則采用插入排序的方式，按照序號遞增方式排序，若在查找期間找到序列號相同的RTP包，則說明當(dāng)前的RTP為重復(fù)數(shù)據(jù)包，直接舍棄。

2.3.2 RTP數(shù)據(jù)包解析

RTP數(shù)據(jù)包解析模塊負責(zé)在接收到順序的RTP數(shù)據(jù)包后，調(diào)用函數(shù)庫解析RTP包，將視頻數(shù)據(jù)封裝成FFMPEG的幀格式，并從RTP包得出數(shù)據(jù)信息解碼時所需要的參數(shù)。

通過判斷時間戳和相鄰數(shù)據(jù)包的序號，順序地將隊列中屬于同一幀的包連接到一起直到某個RTP包的M位為1(表示該包是當(dāng)前要組合幀的最后一個數(shù)據(jù)包)，說明一幀的數(shù)據(jù)信息已經(jīng)完整，封裝并記錄該幀的時間戳，放入緩沖隊列等待上層解碼播放。

2.3.3 H.264 解碼播放

采集端使用的是H.264編碼的視頻數(shù)據(jù)，因此視頻播放端獲得RTP解析后的幀數(shù)據(jù)后，需要調(diào)用FFMEPG解碼接口對幀數(shù)據(jù)進行解碼，最后將解碼后的數(shù)據(jù)放入播放緩沖區(qū)，供播放器進行播放。

3 實驗結(jié)果

實驗使用了真機進行測試，將視頻實時傳輸軟件安裝在兩臺Android手機上，一臺運行攝像頭端應(yīng)用程序，另一臺運行監(jiān)控端應(yīng)用程序，以無線路由器為熱點建立無線局域網(wǎng)，通過WiFi將兩臺手機連接到無線局域網(wǎng)中，并通過輸入攝像頭端Android手機的IP地址，將兩部手機建立點對點直連。通過監(jiān)控端的Android手機，可實現(xiàn)遠程視頻預(yù)覽。

圖5為WiFi環(huán)境下視頻實時傳輸?shù)男Ч麍D，兩圖分別使用了兩組手機進行測試，左側(cè)手機為視頻采集端，右側(cè)手機為視頻播放端，視頻實時傳輸過程中播放無延遲，圖像清晰。

圖5 WiFi環(huán)境下視頻實時傳輸效果

圖6為使用網(wǎng)絡(luò)封包分析軟件Wireshark在系統(tǒng)運行過程中進行抓包，WiFi環(huán)境下采集端和播放端IP地址均為路由器分配私網(wǎng)地址，視頻采集端IP為192.168.1.102，端口為55421，視頻播放端IP為192.168.1.101，端口為25070。視頻傳輸協(xié)議為RTP，RTP包大小1 400 B以及RTP協(xié)議的序號、類型、時間戳、載荷等信息。

通過Wireshark自帶的RTP分析軟件分析RTP包，圖7為RTP丟包率檢測，在46.82 s內(nèi)總共抓取了RTP包2 659個，丟包數(shù)為0，在WiFi環(huán)境下本系統(tǒng)的RTP丟包率為0。

圖6 wireshark抓包

圖7 RTP丟包率檢測

在視頻采集端記錄系統(tǒng)運行時間，同時記錄下已發(fā)送的數(shù)據(jù)量，用已發(fā)送數(shù)據(jù)總量除以系統(tǒng)運行時間算出數(shù)據(jù)的發(fā)送速率，顯示效果如圖8所示。

圖8 系統(tǒng)傳輸速率檢測

表1為視頻實時傳輸系統(tǒng)性能測試結(jié)果，在WiFi環(huán)境中，移動終端的分辨率為640×480，傳輸幀率為24 fps，根據(jù)H.264進行編碼、壓縮后，傳輸速率在40 KB/s左右，丟包率為0，基本滿足系統(tǒng)的性能要求。

表1 WiFi環(huán)境下傳輸性能

4 結(jié)語

本系統(tǒng)基于Android平臺的地鐵設(shè)備巡檢移動終端，將視頻采集端與視頻播放端的功能集合在一個應(yīng)用程序中，實現(xiàn)了WiFi環(huán)境下的兩臺移動終端間的視頻實時傳輸功能。經(jīng)測試，視頻傳輸質(zhì)量較高，丟包率低，達到了預(yù)期的流暢性、低延遲的要求。同時，如果將該功能在實際工程中進行應(yīng)用，需要處理好與地鐵中無線信號的隔離問題，后期過程中可考慮加入音頻的傳輸，使得實時信息采集的功能更加完善可靠。

[1] 何奇.基于移動終端的視頻監(jiān)控系統(tǒng)的設(shè)計與實現(xiàn)[D].成都：電子科技大學(xué)，2011.

(編輯：郝京紅)

Fu Qiang Chen Yingfeng Bai Yun Lu Xiangcheng

(NARI Technology Development Limited Company, Nanjing 210061)

A real-time video transmission function was researched in WiFi environment on metro equipment inspection terminal with android-based platform in line with the requirements of real-time video collecting in metro equipment inspection. The function consists of a video capture terminal and a video playback terminal. The former is mainly responsible for collecting video data, data compression and data packing, and the latter for receiving and analyzing data packets, decoding the video data and playing back videos. On the basis of H.264 video compression technology, real-time transmission protocol, streaming media servers and other related technologies, the system implements the functions of real-time video transmission and playback with a smooth video transmission and low dropout rate.

metro; equipment inspection; android terminal; real-time video transmission; video compression; real-time transport protocol

傅強，男，碩士，高級工程師，從事軌道交通綜合監(jiān)控及設(shè)備運維管理系統(tǒng)研究，fuqiang2@sgepri. sgcc.com.cn.

TP273.5

A