地鐵設備巡檢移動終端視頻實時傳輸應用

傅 強 陳穎峰 柏 云 陸相成

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

地鐵設備巡檢移動終端視頻實時傳輸應用

傅 強 陳穎峰 柏 云 陸相成

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

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

地鐵；設備巡檢；Android終端；視頻實時傳輸；視頻壓縮；實時傳輸協議

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

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

在此基礎上，將視頻算法運行于移動終端上，實現了視頻采集、編碼、傳輸等功能，視頻的播放及分析應用也可于移動終端實現，替代了傳統的監控顯示器[3]。

1 系統結構

1.1 框架結構

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

該系統主要實現了攝像頭端和監控端之間視頻采集、視頻實時傳輸和視頻播放的功能，攝像頭端和監控端之間通過無線網絡進行連接和數據傳輸。系統硬件結構如圖1所示。

圖1 系統硬件結構

1.2 軟件設計

在無線WiFi的網絡環境中，可以很容易地獲取各個終端的公網IP地址，所以用移動終端直連的方式就可以完成視頻傳輸，系統的軟件結構如圖2所示。

圖2 系統軟件結構

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

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

2 通信機制

2.1 軟件流程

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

圖3 視頻傳輸系統工作流

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

2.2 視頻采集端

2.2.1 視頻采集

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

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

2.2.2 RTP封裝實現

LocalSocket中的數據是H.264的原始數據流，必須剝離出每個網絡抽象單元(network abstract layer unit，NALU)，在每個NALU 前添加相應的RTP 包頭，最后才能將包含RTP 包頭和NALU 的數據包發送出去[6]。由于以太網中最大傳輸單元(maximum transmission unit，MTU)大小1 500 B的限制，為了保證視頻數據傳輸的完整性，本系統規定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服務器的實現

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

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

3) 客戶端給服務器發送SETUP請求消息，設置會話的屬性，以及傳輸模式，并提醒服務器建立會話，服務器的SETUP 回應消息建立會話，返回會話標識符以及會話相關信息。

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

2.3 視頻播放端

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

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

2.3.1 流媒體數據接收

從流媒體服務器獲取媒體數據信息包括前期會話協商部分和數據緩沖部分。

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

2.3.2 RTP數據包解析

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

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

2.3.3 H.264 解碼播放

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

3 實驗結果

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

圖5為WiFi環境下視頻實時傳輸的效果圖，兩圖分別使用了兩組手機進行測試，左側手機為視頻采集端，右側手機為視頻播放端，視頻實時傳輸過程中播放無延遲，圖像清晰。

圖5 WiFi環境下視頻實時傳輸效果

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

通過Wireshark自帶的RTP分析軟件分析RTP包，圖7為RTP丟包率檢測，在46.82 s內總共抓取了RTP包2 659個，丟包數為0，在WiFi環境下本系統的RTP丟包率為0。

圖6 wireshark抓包

圖7 RTP丟包率檢測

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

圖8 系統傳輸速率檢測

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

表1 WiFi環境下傳輸性能

4 結語

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

[1] 何奇.基于移動終端的視頻監控系統的設計與實現[D].成都：電子科技大學，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

傅強，男，碩士，高級工程師，從事軌道交通綜合監控及設備運維管理系統研究，fuqiang2@sgepri. sgcc.com.cn.

TP273.5

A