曾永安,康韋曉,單亞飛,敦科翔
(1.國網(wǎng)江西省電力公司撫州供電分公司,江西 撫州 344000; 2.河北遠東通信系統(tǒng)工程有限公司,河北 石家莊050002)
視頻監(jiān)控系統(tǒng)發(fā)展了短短二十幾年時間,從19世代80年代的模擬監(jiān)控到火熱的數(shù)字監(jiān)控再到方興未艾的網(wǎng)絡視頻監(jiān)控,發(fā)生了翻天覆地的變化[1]。從技術角度出發(fā),視頻監(jiān)控系統(tǒng)發(fā)展劃分為:第一代模擬視頻監(jiān)控系統(tǒng);第二代基于“PC+多媒體卡”數(shù)字視頻監(jiān)控系統(tǒng);第三代完全基于IP網(wǎng)絡視頻監(jiān)控系統(tǒng)[2]。全IP視頻監(jiān)控系統(tǒng)[3]有如下的優(yōu)勢:① 簡便性——所有攝像機都通過經(jīng)濟高效的有線或者無線以太網(wǎng)簡單連接到網(wǎng)絡,使您能夠利用現(xiàn)有局域網(wǎng)基礎設施;② 強大中心控制——一臺工業(yè)標準服務器和一套控制管理應用軟件就可運行整個監(jiān)控系統(tǒng);③ 易于升級與全面可擴展性——輕松添加更多攝像機,將來中心服務器亦能夠方便升級到更快速處理器、更大容量磁盤驅(qū)動器以及更大帶寬等;④ 全面遠程監(jiān)視——任何經(jīng)授權客戶機都可直接訪問任意攝像機;⑤ 堅固冗余存儲器——可同時利用SCSI、RAID以及磁帶備份存儲技術永久保護監(jiān)視圖像不受硬盤驅(qū)動器故障影響[4]。
現(xiàn)在的視頻監(jiān)控系統(tǒng)正朝著高清化、集成化和智能化的方向發(fā)展。華為海思的海思芯片Hi3531A,內(nèi)置ARM A9雙核處理器和高性能的H.264視頻編解碼引擎,集成了包含多項復雜圖像處理算法的高性能視頻/圖像處理引擎,能夠提供HDMI/VGA高清顯示輸出能力。因此,本文提出了一種基于Hi3531A芯片和流媒體服務器的視頻監(jiān)控系統(tǒng)。
本系統(tǒng)主要分3部分:編解碼器模塊、流媒體服務器模塊和客戶端模塊。編解碼器模塊以Hi3531A芯片為核心主要用來完成視頻采集和視頻編碼的任務;流媒體服務器模塊在EasyDarwin[5]流媒體的基礎上增加錄像部分主要用來接收編解碼器發(fā)送的視頻流并保存和轉(zhuǎn)發(fā);客戶端模塊主要是利用libvlc.dll動態(tài)庫編碼來顯示實時視頻。流媒體服務器支持RTP/RTCP/RTSP協(xié)議,編解碼器、客戶端和流媒體之間都通過此協(xié)議來進行通信。系統(tǒng)的總設計圖如圖1所示。
圖1 系統(tǒng)總設計
編解碼器采用HI3531A芯片[6],集成多項復雜圖像處理算法的高性能視頻/圖像處理引擎,提供HDMI/VGA高清顯示輸出能力。編解碼能力為8x1080p@30fps H.264編碼+8xCIF@30fps H.264編碼+4x1080p@30fps H.264解碼+8x1080p@2fps JPEG編碼。
編解碼器的工作原理:
① 視頻輸入單元通過 ITU-R BT.601/656 接口接收由 VADC 輸出的數(shù)字視頻信息,并通過 AHB 總線把接收到的原始圖像寫入到外存(SDR SDRAM 或 DDR SDRAM)中;
② 視頻編解碼器從外存中讀取圖像,進行運動估計(幀間預測)、幀內(nèi)預測、DCT 變換、量化、熵編碼DCT 變換、反量化及運動補償?shù)炔僮鳎詈髮⒎?H.264 協(xié)議的裸碼流和編碼重構幀寫入到外存中;
③ 視頻輸出單元從外存中讀取圖像數(shù)據(jù)并通過 ITU-R BT.601/656接口送給 VDAC 進行顯示,應用的需求不同,視頻輸出單元從外存中讀取的圖像內(nèi)容也不同,當需要對輸入圖像進行預覽時,視頻輸出單元從外存中讀取原始圖像,當需要觀察視頻編碼器的編碼效果時,視頻輸出單元從外存中讀取編碼重構幀;
④ ARM 對視頻編碼器輸出的碼流進行協(xié)議棧的封裝,然后送給網(wǎng)口發(fā)送。
編解碼器的工作流程主要分為MPP媒體處理和RTP/RTCP封裝和拆解。
2.1 MPP媒體處理
海思提供的媒體處理軟件平臺(Media Process Platform,MPP),可支持應用軟件快速開發(fā)。該平臺對應用軟件屏蔽了芯片相關的復雜的底層處理,并對應用軟件直接提供MPI(MPPPrograme Interface)接口完成相應功能。
海思媒體處理平臺的主要內(nèi)部處理流程如圖2所示,主要分為視頻輸入(VI)、視頻處理(VPSS)、視頻編碼(VENC)、視頻解碼(VDEC)、視頻輸出(VO)、音頻輸入(AI)、音頻輸出(AO)、音頻編碼(AENC)、音頻解碼(ADEC)以及區(qū)域管理(REGION)等模塊。
圖2 MPP工作原理
2.2 RTP/RTCP封裝和拆解
本設計采用ARICENT公司的RTP/RTCP協(xié)議棧,RTP/RTCP協(xié)議棧的接口以API和回調(diào)函數(shù)的形式存在。
當視頻幀較大時,需要將一幀圖像拆成多個RTP進行傳遞,具體分包規(guī)則按照RFC3984標準進行。視頻的RTP處理流程如圖3所示。
圖3 RTP處理流程
流媒體服務器模塊是基于開源EasyDarwin流媒體軟件框架進行開發(fā)的[7]。EasyDarwin是由國內(nèi)開源流媒體團隊維護和迭代的一整套開源流媒體視頻平臺框架[8],從2012年12月創(chuàng)建并發(fā)展至今,開辟了諸多的優(yōu)質(zhì)開源項目,能更好地幫助廣大流媒體開發(fā)者和創(chuàng)業(yè)型企業(yè)快速構建流媒體服務平臺,更快、更簡單地實現(xiàn)最新的移動互聯(lián)網(wǎng)(安卓、iOS、H5、微信)流媒體直播與點播的需求,尤其是安防行業(yè)與互聯(lián)網(wǎng)行業(yè)的銜接[9]。它的RTSP開源流媒體直播服務,高效、穩(wěn)定、可靠、功能齊全,支持RTSP流媒體協(xié)議,支持安防行業(yè)需要的攝像機流媒體轉(zhuǎn)發(fā)功能、支持互聯(lián)網(wǎng)行業(yè)需要的多平臺(PC、Android、IOS)RTSP直播(H.264/MJPEG/MPEG4、AAC/PCMA/PCMU/G726)功能,底層(Select/Epoll網(wǎng)絡模型、無鎖隊列調(diào)度)和上層(RESTful接口、WEB管理、多平臺編譯)、遠程運維等方面優(yōu)化,這些都是全代碼完全開源的[10]。
它的核心部分是由一個父進程所fork出的一個子進程構成,該父進程就構成了整個流媒體服務器[11]。父進程會等待子進程的退出,如果在運行的時候子進程產(chǎn)生了錯誤從而退出,那么父進程就會fork出一個新的子進程。可以看出,網(wǎng)絡客戶和服務器直接的對接是由核心服務器來完成的。網(wǎng)絡客戶RTSPoverRTP來發(fā)送或者接受請求。服務器就通過模塊來處理相應的請求并向客戶端發(fā)送數(shù)據(jù)包。核心流媒體服務通過創(chuàng)建4種類型的線程來完成自己的工作[12],具體如下:
① 服務器自己擁有的主線程。當服務器需要關閉檢查,以及在關閉之前記錄相關狀態(tài)、打印相關統(tǒng)計信息時,一般都是通過這個線程來完成的。
② 空閑任務線程。這個任務線程是用來對一個周期任務隊列的管理,主要管理2種任務,即超時任務和Socket任務。
③ 事件線程。套接口相關事件由事件線程負責監(jiān)聽,當有RTSP請求或者收到RTP數(shù)據(jù)包時,事件線程就會把這些實踐交給任務線程來處理。
④ 任務線程。任務線程會把事件從事件線程中取出,并把處理請求傳遞到對應的服務器模塊進行處理,比如把數(shù)據(jù)包發(fā)送給客戶端的模塊,在默認情況下,核心服務器會為每個處理器核創(chuàng)建一個任務線程。
本文在此基礎上增加了保存錄像功能,主要原理是在主線程接受到編解碼器推送來的視頻流后自動開啟一個RTSP客戶端線程;客戶端和服務器之間的連接是基于RTP/RTCP/RTSP協(xié)議,此線程在接收到視頻流后,按幀打包,再調(diào)用libmp4v2.dll來將H.264視頻流保存成MP4格式。在系統(tǒng)中MP4文件大小設計為每到整點和30分時自動保存一次,同時為了保障服務在服務異常斷開使MP4文件損壞時,仍然能夠得到有用的視頻信息,會同時生成一個H.264文件。當MP4文件保存正常時,對應H.264文件會刪除,否則會保存H.264文件。在大量的試驗中發(fā)現(xiàn)只有機器異常斷電時,由于程序不能正常退出會造成MP4文件不完整無法播放,而H.264文件是由純粹加了頭的sps、pps和幀數(shù)據(jù)組成,不會被損壞。本系統(tǒng)選擇MP4格式的原因是它幾乎能被所有播放器識別,方便用戶使用,而H.264文件只能被極少數(shù)播放器播放(例如,VLC播放器正常模式不能播放H.264文件,但選擇“工具—首選項—(左下)全部—輸入/編解碼器中的去復用器—選擇H.264去復用器—確定”就可以播放H.264文件了),因此只作為特殊情況的備用項。圖4為流媒體服務器模塊的主要框架圖。
圖4 流媒體服務器框架
流媒體服務器在運行時,接受流和發(fā)送流都是通過RTSP協(xié)議來進行,它們之間的流程如圖5所示。
圖5 RTSP流程
C表示rtsp客戶端,S表示rtsp服務端。
① C→S: ANNOUNCE request ∥提交媒體初始化描述信息(SDP)給S;
S→C: ANNOUNCE response ∥ S回應該提交的信息;
② C→S:SETUP request ∥設置會話的屬性,以及傳輸模式,提醒S建立會話;
S→C:SETUP response ∥S建立會話,返回會話標識符,以及會話相關信息;
③ C→S:RECORD request ∥C請求錄像;
S→C: RECORD response ∥S回應該請求的信息;
④ C→S: PLAY request ∥C請求播放(拉);
S→C: PLAY response ∥回應請求(拉);
⑤ C→S:發(fā)送流媒體數(shù)據(jù)(推模式;);
S→C:接受流媒體數(shù)據(jù)(拉模式);
⑥ C→S:TEARDOWN request ∥C請求關閉會話;
S→C:TEARDOWN response ∥S回應該請求。
如圖6所示,客戶端模塊是在Windows平臺上運行的一個實時視頻播放程序,采用VC++開發(fā),與流媒體服務器模塊之間通過RTP/RTCP/RTSP協(xié)議連接,主要通過調(diào)用libvlc.dll庫來實現(xiàn)[13]。
圖6 RTSP流程
本系統(tǒng)支持多個客戶端接入,通告配置流媒體服務器IP地址,客戶端可在任意Windows電腦播放監(jiān)控視頻。系統(tǒng)研制過程中解決因緩存小而出現(xiàn)的播放高清視頻錄像時的半屏現(xiàn)象。原因是libvlc.dll接受視頻幀緩存初始值比較小,當存儲1080P高清視頻時,I幀數(shù)據(jù)超過緩存大小,系統(tǒng)先丟掉多余數(shù)據(jù)后再將緩存翻倍,這樣視頻的前幾秒會出現(xiàn)半屏現(xiàn)象。改進方法是在接受數(shù)據(jù)時判斷幀大小,根據(jù)需要設置緩存大小,同時重新設置緩存初始值,重新編譯libvlc.dll,解決了播放高清視頻時的短暫半屏的問題。
本系統(tǒng)設計的視頻監(jiān)控系統(tǒng)經(jīng)過測試能夠播放和保存1080P、720P、4CIF、VGA、CIF以及QCIF等6種分辨率的視頻,并且客戶端播放實時監(jiān)控視頻延時小于1 s,滿足絕大部分使用要求。本系統(tǒng)特地制作了分屏模式,能夠?qū)?個視頻制作成一個視頻實現(xiàn)分屏播放,經(jīng)測試視頻播放流暢,系統(tǒng)穩(wěn)定。此方案不僅可以部署在交通道路、商場、銀行等固定場所使用,也可以作為公安應急、森林防護以及部隊演習等野外作業(yè)的現(xiàn)場與中心通信的臨時指揮系統(tǒng)來使用。
[1] 鐘辰.平安城市網(wǎng)絡視頻監(jiān)控組網(wǎng)解決方案以及發(fā)展趨勢研究[D].南京: 南京郵電大學,2015.
[2] 陳浩鑫.城市治安視頻監(jiān)控系統(tǒng)設計與實現(xiàn)[D].長沙:湖南大學,2014.
[3] 古前疆.基于IP網(wǎng)絡的視頻監(jiān)控系統(tǒng)的設計與實現(xiàn)[D].大連: 大連理工大學,2013.
[4] 王亞沛.面向智慧社區(qū)的智能視頻監(jiān)控系統(tǒng)設計與應用研究[D].杭州:浙江理工大學,2015.
[5] 潘明.基于H.264的網(wǎng)絡視頻監(jiān)控系統(tǒng)的研究與實現(xiàn)[D].長春: 吉林大學,2014.
[6] 鄭陽.基于Hi3516A處理器的KVM終端軟件設計[D].杭州: 浙江工業(yè)大學,2016.
[7] 高春雷.視頻直播系統(tǒng)設計與實現(xiàn)[J].科技風,2016(18): 103.
[8] 文力.基于Android和云平臺的幼教系統(tǒng)的設計與實現(xiàn)[D].武漢: 華中師范大學,2016.
[9] 向華.流媒體服務系統(tǒng)核心技術的研究與實現(xiàn)[D].西安:西安電子科技大學,2014.
[10] 陳廣東.流媒體服務器集群負載均衡算法研究[D].武漢: 華中師范大學,2006.
[11] 林洪藝.流媒體組播服務器的構建及軟件開發(fā)[D].廈門: 廈門大學,2008.
[12] 張洪宇.基于RTP協(xié)議流媒體服務器的研究[D].成都:電子科技大學,2007.
[13] 冀龍濤.基于Android手機的家用機器人控制技術研究[D].哈爾濱: 哈爾濱工業(yè)大學,2013.