基于嵌入式前端服務器的音視頻監控系統設計

張紀寬， 彭 力 ， 陳志勇

(江南大學 物聯網工程學院，江蘇 無錫214122)

普通的網絡視頻監控系統流程是前端設備采集視頻，經特定服務器轉發，客戶端接收視頻數據［1-3］。隨著嵌入式技術的成熟，嵌入式前端設備完全擁有充當服務器的能力。如果省略中間環節，直接把服務器部署在采集視頻的前端設備上，不僅節約成本而且增強實時性。而隨著智能手機等PDA 用戶的持續增多，城市無線WiFi 覆蓋域的擴大，普通的網絡視頻監控系統已經無法滿足用戶在任何時間、任何地點觀看監控信息的需求［4］。因此，文中設計并實現了一個以DaVinci 架構DM365 處理器為前端服務器的監控系統，客戶端可工作在PC 或者Android 系統的可移動設備上，實現了實時音視頻監控。

1 監控系統總體設計

文中實現的系統主要由前端服務器，無線WiFi模塊和客戶端組成。系統前端服務器采用TMS320DM365 多媒體處理器，對攝像頭采集的音視頻數據分別進行H.264 和g711 編碼，RTP 封包，通過管道給live555 流媒體服務器等待轉發;WiFi 模塊采用基于IEEE802.11b 的無線協議;同時采用RTP/RTCP，RTSP 協議為客戶端提供實時音視頻流。客戶直接向前端服務器發送請求，接收音視頻流，進行同步處理后解碼播放;客戶端可工作在PC或者Android 可移動設備平臺，采用開源的VLC 播放器實現音視頻同步播放。系統總體結構如圖1所示。

圖1 監控系統總體結構Fig.1 Structure of the monitoring system

2 監控系統硬件開發平臺

系統硬件平臺以Techvdm365 開發板為核心，采用TMS320DM365 處理器。DM365 是TI 推出的基于DaVinci 技術的新一代ARM+DSP 雙核架構的視頻處理器。支持H.264，MPEG-4，JPEG 等編解碼器，靈活性好，使用簡單，操作方便［5］。音視頻信號處理可以分為兩個層次:信號處理層(SPL)和應用程序處理層(APL)。SPL 對應著DSP 核，主要完成音視頻的壓縮編碼;APL 對應著ARM 核，將SPL 各個硬件編解碼器抽象為Codec Engine 對象，并把對音視頻的相關操作封裝為API 函數DMAI，方便完成音視頻的處理［6］。開發板硬件資源包括512 MBytes NAND Flash 存儲器，128 MBytes DDR2，533 MHz SDRAM，10 M/100 Mb/s 網卡，EMAC，SD/MMC 接口，UART 接口［7］。無線模塊使用USR-WIFI232-X WIFI 模塊。系統硬件結構見圖2。

圖2 系統硬件結構Fig.2 Structure of hardware

3 前端服務器軟件設計

監控系統軟件分為3 個模塊:音視頻信號處理模塊、音視頻數據打包模塊、流媒體服務器轉發模塊。音視頻信號處理模塊主要負責音視頻數據的采集、壓縮編碼、本地存儲、本地顯示并將處理好的音視頻數據流存放指針傳給打包模塊;音視頻打包模塊獲得數據流后進行RTP 打包，并將打包后的數據存放指針賦給流媒體服務器轉發模塊;當流媒體服務器轉發模塊接收到客戶端的請求即可將打包好的數據轉發給客戶端。系統上電后流媒體服務器轉發模塊始終監聽客戶端連接請求，信號處理模塊將音視頻數據存為本地文件，當有客戶端連接請求后數據打包模塊才會工作。

3.1 基于DVSDK 的音視頻信號處理

數字視頻軟件開發套件(DVSDK)是TI 推出的C 語言軟件開發包，功能上可劃分為編解碼引擎(CE)、應用程序接口(DMAI)、編解碼框架組件(FC)、數字視頻測試平臺(DVTB)、算法標準(xDAIS)［8］。

利用DVSDK 軟件開發包開發音視頻信號處理程序只需在應用程序層(APL)調用應用程序接口便可操作信號處理層(SPL)對視頻圖像的壓縮編碼。音視頻信號處理程序分為Capture，Video，Display，Write，Speech 5 個線程，共同完成數據的采集、編碼、存儲、顯示。線程工作流程如圖3 所示。

圖3 線程工作流程Fig.3 Flowchart of thread

3.2 基于RTP 的H.264 視頻流打包算法

H.264 每個NALU 單元由起始碼(Start Code)，NALU 頭(NALU Header)，原始字節序列(NALU Payload)3 部分依次組成。利用Start Code 標識一個NALU 單元，一般為數值1，占用3 個或者4 個字節;NALU Header 用以說明NALU 單元類型，共1 Byte;NALU Payload 為原始字節序列負荷(RBSP)。NALU 單元格式如圖4 所示。

圖4 單個NALU 單元格式Fig.4 Single cell form of NALU

使用RTP 協議進行流媒體傳輸，需要把H.264格式視頻數據封裝成一系列RTP 數據包。由于網絡接收最大數據包為1 500 Bytes，且RTP 協議承載于UDP 協議傳輸，還需要加上UDP，IP 頭約52 Bytes，因此文中使用了一種高效靈活的視頻流打包算法。當NALU 單元長度小于1 400 Byte 時采用單一NALU 單元封包模式;當NALU 單元長度大于1 400 Byte 時采用分片封裝模式。分片封裝模式時RTP 數據格式為［FU idicator］［FU Header］［Payload］［9］。利用FU Header 區分當前包是NALU 分割片的第幾片，使接收端能夠正確地重新組合一個NALU 單元。音視頻數據處理模塊的video 線程把編碼后的數據存放到內存緩沖區中，在每次打包前需要先判斷此緩沖區中有幾個NALU 單元，然后根據NALU 單元的大小選擇不同的RTP 封包模式。具體程序流程如圖5 所示。

圖5 視頻打包程序流程Fig.5 Flowchart of video package

3.3 基于live555 的RTSP 服務器構建

流媒體數據轉發服務器模塊主要作用是監聽客戶端的連接請求，實現RTSP 監聽。該模塊工作在阻塞模式，一旦獲得客戶端的IP 和端口，就會創建RTP 會話，并向數據打包模塊發送RTP 數據請求，促使其對信號處理模塊緩沖區中的數據進行RTP打包，并把數據轉發給客戶端。服務器主要流程如圖6 所示。

圖6 服務器程序流程Fig.6 Flowchart of server program

文中通過移植live555 到前端設備DM365 中實現RTSP 流媒體服務器。live555 是一個為流媒體提供解決方案的跨平臺C ++ 開源項目，完成對標準媒體 傳 輸 協 議RTP/RTCP，RTSP 等 的 支 持［10］。Live555 整體框架主要包括4 個重要模塊:UsageEnvironment 模塊對系統環境的抽象，包括抽象 類 UsageEnvironment 和 TaskScheduler;Basic UsageEnvironment 模塊是UsageEnvironment 的一個控制臺應用的實現，即針對控制臺的輸入輸出和信號響應進行具體實現;GroupSock 模塊用于實現數據包的發送和接收;LiveMedia 模塊是Live555 最重要的模塊， 包括如下派生類:RTSPClient，MediaSession，RTCPInstance，Source 和Sink。類圖結構如圖7 所示。

4 客戶端設計

客戶端主要負責接收流媒體數據并進行解碼播放，由于監控系統實現的是音視頻監控，需要對接收到的音視頻數據進行同步處理。關于音視頻同步標準參考文獻［11］，同步算法參考文獻［1］。

RTP_video 和NTP_video 分別為視頻會話的RTP 和NTP 時間戳，RTP_audio 和NTP_audio 分別為音頻會話的RTP 和NTP 時間戳，Clock 為媒體的時鐘頻率。

在NTP_audio 時刻，視頻的RTP 時間戳應為

RTP_video_audiotime = RTP_video +

設當前時刻視頻和音頻的RTP 時間戳分別為:RTP_video_cur，RTP_audio_cur，如果媒體間保持同步，必須滿足下式:

設實際收到視頻的RTP 時間戳為RTP_video_real，音視頻可通過下式判斷是否同步:

其中，T = 80 ms/Clock_audio。

同步程序流程如圖8 所示。

圖7 live555 類圖結構Fig.7 Structure of live 555

圖8 音視頻同步程序流程Fig.8 Flowchart of audio and video synchronization program

5 監控系統測試

文中已實現監控系統所有模塊，前端服務器IP地址為172.18.168.63，RTP 音視頻會話端口分別為9 000 和8 000。分別在PC 端和Android 手機端測試如下:

先運行前端服務器，串口調試助手顯示"We use port 8550 for optional RTSP tunneling"，在Android 端運行VLC，打開網絡，輸入:RTSP://172.18.168.63:8550/，點擊播放。音視頻實時性良好，音視頻同步效果良好，VLC 顯示如圖9 所示。

圖9 Android 和PC 端顯示Fig.9 Display of android and PC

VLC 播放器可以查看播放音視頻的統計信息，如圖10 所示。從圖10 的數據可以看出，音視頻串流碼率可達523 kb/s，此時丟包率分別為3/17 259 =0.017%，5/8 482 = 0.059%，對監控系統不造成任何影響。由于傳輸的都是經過編碼壓縮后的音視頻數據流，大大降低了網絡壓力。由于音頻數據量小于視頻，每包為固定的160 Byte，不需重新合成，因此解碼的幀數大于視頻幀。收到視頻幀后要經過重新合成NALU 后再解碼播放，而且同步時以音頻為主線，因此顯示的幀要多于解碼的幀，證明有一部分幀由于視頻超前被重復播放。前端服務器是邊采集邊打包發送的，減小了接收端同步程序的壓力，多次測試未出現由于無法同步而重新申請服務器的現象。

6 結 語

文中提出了一種基于嵌入式前端服務器的音視頻監控系統，直接利用前端設備作為服務器，提高實時性，節約成本。利用嵌入式多媒體處理器DM365，開源的live555 和H.264 高性能視頻編解碼技術，實現了音視頻的實時監控。該技術為后續前端設備直接對采集的視頻進行算法處理實現智能監控打下了基礎。

圖10 VLC 統計信息Fig.10 Statisticsl of VLC

［1］劉君亮.基于TMS320DM365 的音視頻傳輸及智能視頻分析系統的設計與實現［D］. 南京:南京郵電大學，2012:4-5，56-58.

［2］周司.基于TCP 傳輸的嵌入式流媒體播放系統［D］.南京:南京理工大學，2014:15-16.

［3］惠曉威，王克.移動視頻監控系統的實現［J］.計算機應用與軟件，2014，31(1):148-150.

HUI Xiaowei，WANG Ke.Realisation of mobile video surveillance system［J］.Computer Applications and Software，2014，31(1):148-150.(in Chinese)

［4］張雅楠，楊璐，鄭麗敏.基于Android 手機的遠程視頻監控系統的設計與開發［J］.計算機應用，2013，33(S1):283-286.

ZHANG Yanan，YANG Lu，ZHENG Limin.Remote video surveillance system based on Android mobile phone［J］.2013，33(S1):283-286.(in Chinese)

［5］Texas Instruments Incorporated. TMS320DM36x Digital Media System-on-chip (DMSoC)ARM Subsystem Users Guide［M］.Dallas，Texas:Texas Instruments Incorporated，2009.

［6］Texas Instruments Incorporated. Davinci Multimedia Application Interface (DMAI)User Guide［M］. Dallas，Texas:Texas Instruments Incorporated，2009.

［7］Deepu Talla，Jeremiab Golston. Using DaVinci technology for digital video device［J］. IEEE Computer Socity，2007，40(10):63-61.

［8］Texas Instruments Incorporated.Codec Engine Application Developer＇s Guide［M］.Dallas，Texas:Texas Instruments Incorporated，2009.

［9］李校林，劉利權，張杰.基于RTP 的H.264 視頻流實時打包傳輸的研究［J］.計算機工程與科學，2012，34(5):168-171.

LI Xiaolin，LIU Liquan，ZHANG Jie.Research on the H.264 real-time video＇s packaged transport based on RTP［J］. Computer Engineering and Science，2012，34(5):168-171.(in Chinese)

［10］劉暢欞，包杰，王寧國.基于Live555 的網絡視頻監控系統設計與實現［J］.現代電信科技，2012，42(12):38-42.

LIU Changlin，BAO Jie，WANG Ninggou. Design and implement of network video monitoring system based on Live555［J］.Modern Science and Technology of Telecommunications，2012，42(12):38-42.(in Chinese)

［11］王風純，魯靜.基于RTP/RTCP 的音視頻同步方法研究［J］.軟件，2011，32(6):78-80.

WANG Fengchun，LU Jing. A method of audio and video synchronization control based on RTP/RTCP［J］. Software，2011，32(6):78-80.(in Chinese)