曲洪權，譚 磊

(北方工業(yè)大學電子信息工程學院，北京 100144)

隨著城市的快速發(fā)展，地鐵在許多城市交通中擔負著主要的乘客運輸任務[1]，它的時效性和較大的客運容量使得城市發(fā)展更迅速，市民出行更便捷.但不可避免的是，高客流量給地鐵站的管理帶來了較嚴重的問題[2].在上下班高峰期，一些具有換乘功能的地鐵站經常發(fā)生擁擠甚至踩踏事故.為了解決這個問題，我國部分地鐵站安裝了客流監(jiān)控系統(tǒng)[3].在地鐵站的通道處安裝攝像頭，并安排工作人員在監(jiān)控室值守，在發(fā)生擁堵情況時派遣人員疏導客流，這樣既能保證通行的安全性，也能提高地鐵運行的效率.但是，這種傳統(tǒng)的地鐵監(jiān)控系統(tǒng)運行需要耗費較多的人力財力來維持，同時，傳統(tǒng)的人工監(jiān)控精確性得不到保障，工作人員的疏忽容易導致事故被忽略.為了更好地管理地鐵站內的設施，合理地調度引導人流的工作人員，保障客運的安全性，筆者擬提出基于C/S[4]架構的客流檢測系統(tǒng)，以期實時監(jiān)控地鐵站各個通行口的客流狀況，并通過深度學習算法[5]檢測跟蹤通行人員，計算且顯示通行人員的速度和密度等信息，準確地定位客流高密度低速度區(qū)域并發(fā)出警報.

1 客流檢測系統(tǒng)的總體設計

1.1 系統(tǒng)設計和組成

圖1 客流檢測系統(tǒng)總體設計Fig. 1 Design of Passenger Flow Detection System

客流檢測系統(tǒng)采用C/S架構，主要由服務端(Server)和客戶端(Client)組成.服務端接收外部網(wǎng)絡攝像頭的視頻碼流，經過檢測跟蹤算法處理和參數(shù)計算后，將數(shù)據(jù)存儲到數(shù)據(jù)庫；同時根據(jù)客戶端發(fā)送的請求，將視頻圖像及相關數(shù)據(jù)作為響應發(fā)送到客戶端.客戶端程序部署在用戶計算機上，負責展示客流數(shù)據(jù)和視頻，它通過與服務器交互來設置系統(tǒng)的相關參數(shù).客流檢測系統(tǒng)總體設計如圖1所示.

服務端負責處理大量數(shù)據(jù)，客戶端負責界面展示，這樣的C/S架構設計能合理地將計算任務分配到C/S兩端，分擔了服務器的壓力，讓服務端可以處理更多的視頻碼流數(shù)據(jù)，同時客戶端的運行不會占用大量資源，用戶體驗更加良好.

1.2 軟件架構和設計

系統(tǒng)將服務端的功能模塊化，各模塊通過系統(tǒng)內存進行通信[6].采用這種設計模式的優(yōu)點是，在某一模塊需要更新替換時，不需要修改接口代碼，只需替換對應模塊的程序；若某功能模塊發(fā)生異常退出，則無須重啟整個服務端程序，只要重啟該模塊即可.客戶端程序同樣采用模塊化設計，運行發(fā)生異常時方便查找問題所在.各功能模塊如圖2所示.

圖2 客流檢測系統(tǒng)各模塊Fig. 2 Module Diagrams of Passenger Flow Detection System

服務端程序主要包括攝像頭視頻碼流解碼模塊、深度學習算法檢測模塊、客流參數(shù)計算模塊、視頻服務器轉發(fā)模塊和客戶端通信模塊，這5個模塊獨立運行，互不干擾，各模塊間使用系統(tǒng)內存?zhèn)鬏敂?shù)據(jù)，通過配置文件來修改交互數(shù)據(jù)時的參數(shù).客戶端程序主要包括視頻接收模塊、數(shù)據(jù)顯示模塊、參數(shù)設置模塊、分屏顯示模塊、歷史數(shù)據(jù)模塊和回放下載模塊，各模塊擁有各自的獨立線程和用戶界面，運行效率高.

2 客流檢測系統(tǒng)的具體設計與實現(xiàn)

2.1 服務端部分設計

2.1.1 服務端主體流程設計 服務端主要處理后臺數(shù)據(jù)，包括實時獲取碼流解碼、檢測跟蹤算法處理、參數(shù)計算、數(shù)據(jù)庫存儲、視頻服務器編碼和與客戶端信息交互.各模塊相互獨立，通過共享內存和命名管道[7]的方式進行數(shù)據(jù)交互.服務端的主流程如圖3所示.

圖3 服務端主流程Fig. 3 Main Process of the Server

系統(tǒng)接入的視頻圖像分辨率為1 280*720，幀率為25幀/s，碼率上限為2 048 Kbps，視頻編碼為H.264，I幀間隔為50.接收到接入的RTSP碼流之后，對其進行解碼，將解碼之后的每幀視頻圖像通過共享內存的通信方式傳遞給下一檢測跟蹤流程.同時，ffmpeg視頻碼流解碼模塊具有斷線檢測和重新連接功能.該模塊封裝成單獨的應用程序，方便今后解碼模塊的更新迭代.從共享內存中獲取解碼圖像后，進入檢測跟蹤模塊.檢測跟蹤模塊與ffmpeg模塊一樣，設計成獨立的應用程序.檢測跟蹤的輸入是每幀圖像的RGB編碼數(shù)據(jù)，輸出是在原圖像上加入檢測跟蹤效果之后的圖像，以及每一個檢測框的坐標信息.檢測跟蹤模塊運行在GPU上，采用深度學習算法，而且支持多個視頻圖像同時輸入，對性能要求較高.檢測跟蹤輸出的圖像，繼續(xù)通過共享內存的方式傳遞給視頻服務器，同時，輸出的檢測框信息通過命名管道的方式傳遞給下一參數(shù)計算模塊.視頻服務器的主要功能是對檢測跟蹤處理后的圖像重新編碼，通過RTSP協(xié)議轉發(fā)給客戶端接收.視頻服務器可以同時接收所有檢測跟蹤處理后的多路圖像，對所有線路的圖像進行編碼，再轉發(fā)給客戶端接收.參數(shù)計算模塊通過命名管道接收檢測跟蹤處理之后的檢測框信息，包括檢測框的數(shù)量和坐標，再對其進行計算，輸出客流量、速度、密度和事件信息.數(shù)據(jù)庫存儲模塊調用參數(shù)計算提供的公共接口，對計算出來的數(shù)據(jù)進行存儲，同時存儲對應的時間，以供客戶端查詢.為了提高硬盤讀寫效率，避免對數(shù)據(jù)庫頻繁操作，數(shù)據(jù)庫存儲模塊設有緩存機制，對所有接入攝像頭進行緩存后一次性存入數(shù)據(jù)庫.

圖4 檢測跟蹤算法流程Fig. 4 Flow Chart of Detection and Tracking Algorithm

2.1.2 檢測跟蹤處理流程 服務端是整個系統(tǒng)的核心，檢測跟蹤處理和與客戶端交互都在服務端完成.在接入大量攝像頭的情況下，如果對接入的每個攝像頭的每一幀圖像都進行檢測跟蹤處理，勢必會耗費大量的計算資源.鑒于這種情況，為了保證系統(tǒng)的正常、高效運行，系統(tǒng)的檢測跟蹤算法采取抽幀檢測模式，即處理1幀之后，跳過若干幀再處理下一幀.檢測跟蹤處理流程如圖4所示.

檢測跟蹤模塊啟動時，先初始化檢測跟蹤算法中需要用到的關鍵參數(shù)、待檢測圖像的分辨率、檢測跟蹤處理的置信度和抽幀幀數(shù)等.參數(shù)初始化完成之后，將參數(shù)送至檢測處理算法初始化模塊進行算法初始化，根據(jù)輸入?yún)?shù)調整相關計算數(shù)值.初始化完成后等待待處理圖像的接入，抽幀操作完成后開始檢測跟蹤算法處理，識別圖像中的行人.根據(jù)識別的結果，在圖像上繪制檢測框.如果檢測到是同一目標的檢測框，就根據(jù)框的中心位置繪制一條行進軌跡，并將位置信息輸出到參數(shù)計算模塊.信息完全輸出后重置跟蹤器，如果不需要繼續(xù)處理，就釋放算法占用的資源，退出檢測跟蹤算法模塊.

圖5 通信消息體Fig. 5 Communication Message Body

2.1.3 模塊間通信設計 系統(tǒng)采用分離式設計開發(fā)，需要一種合理的通信方式來銜接各模塊，使各模塊之間能進行高效穩(wěn)定、大數(shù)據(jù)量的通信.考慮到這一點，系統(tǒng)采取命名管道的方式來橋接各相對獨立的模塊.命名管道以字節(jié)流的方式傳輸數(shù)據(jù)，發(fā)送端將需要傳輸?shù)臄?shù)據(jù)以Unicode編碼成字節(jié)數(shù)組發(fā)送，接收端反編碼成需要的字符串.考慮到發(fā)送和接收兩端為不同模塊，所以約定一種如圖5所示的特定通信格式.

數(shù)據(jù)體的最上層和中間有發(fā)送和接收兩端的同步標記，這樣能保證通信兩端準確獲取所需的信息.每個數(shù)據(jù)段約定指定長度，既減少了通信中獲取錯誤信息的可能，又提高了傳輸效率.采用統(tǒng)一約定的傳輸格式發(fā)送和接收數(shù)據(jù)，保證了系統(tǒng)內模塊間的通信穩(wěn)定性，同時這種傳輸方式在進程間通信中安全性高、效率快.

2.2 客戶端部分設計

客戶端主要接收服務器的視頻碼流，以及定時獲取并顯示客流參數(shù).同一時刻，客戶端主界面實時顯示一個主碼流，在分屏顯示功能中可以選擇最多9個碼流進行解碼顯示.用戶在客戶端上選擇需實時播放的攝像頭編號，客戶端開始對視頻服務器發(fā)送的碼流進行解碼并顯示.同時，客戶端每隔5 s與服務端進行通信，將獲取到的當前時間數(shù)據(jù)以表格、折線圖等形式顯示.如果查詢到報警信息，就彈窗報警.客戶端主界面如圖6所示.

圖6 客戶端界面Fig. 6 Client Interface

由于系統(tǒng)對實時性要求較高，因此客戶端采用支持IPv4協(xié)議和RTSP協(xié)議實時解碼的開源播放器插件.對插件的核心代碼進行二次封裝，使其滿足系統(tǒng)的功能要求.考慮到上述問題，在對比多個方案后，確定采用VLC(VideoLAN)播放器[8]作為解碼模塊的核心.VLC播放器基于FFmpeg解碼器開發(fā)，支持當前主流媒體文件和網(wǎng)絡碼流的播放，是一款優(yōu)秀的開源播放器.系統(tǒng)調用VLC實現(xiàn)實時解碼的流程如圖7所示.

圖7 VLC解碼流程Fig. 7 VLC Decoding Flow Chart

程序在收到用戶播放操作指令后調用VLC解碼模塊，創(chuàng)建VLC資源索引，根據(jù)程序配置的播放參數(shù)創(chuàng)建libvlc_media_player_t播放器.至此，VLC的播放器初始化完畢.用戶界面?zhèn)鬟f播放窗口的句柄和目標資源的URL給解碼模塊，根據(jù)此句柄設置VLC的播放句柄并綁定播放器資源；再調用VLC的核心播放模塊對指定URL進行解碼，將獲取的實時視頻圖像根據(jù)用戶界面的窗口句柄輸出到指定播放窗口.此時，解碼播放完成.為了減小程序占用的計算資源，釋放不需要使用的播放器資源.測試結果表明，本方案能夠流暢穩(wěn)定地實現(xiàn)解碼播放功能.

3 實驗分析

為了測試系統(tǒng)的性能，實驗人員搭建了一個模擬地鐵環(huán)境，在人流量較大的通道處架設網(wǎng)絡攝像頭，接入局域網(wǎng).在服務器上部署服務端程序，PC機上部署客戶端程序.在搭建的模擬地鐵環(huán)境下，對行人檢測的準確率、數(shù)據(jù)計算的準確度和程序資源占用情況進行測試.

模擬地鐵運行環(huán)境中，攝像頭分辨率為1 280*720，幀率為25幀/s，服務端單個顯卡接入5路攝像頭碼流進行抽幀實時跟蹤檢測.在攝像頭無遮擋、光線正常和無異常外部因素影響下，測試結果見表1.由表1可知，系統(tǒng)檢測跟蹤的平均準確度高于90%.

表1 檢測跟蹤的準確度

實際應用中，除了要考慮滿足檢測性能指標，還要考慮系統(tǒng)的資源占用情況，為此實驗人員進行了軟件性能測試.在模擬環(huán)境下，服務端部署在WinServer操作系統(tǒng)服務器上，服務器CPU為雙CPU，Intel-E5-2620，2.10 GHz，安裝內存128 G，32核，4塊NVIDIA GeForce GTX1080Ti顯卡，采用PCIe X16 3.0總線接口技術，顯存11 264 MB；客戶端部署在Windows7操作系統(tǒng)下，Intel-I5-3210M CPU，2.5 GHz，安裝內存4 G，NVIDIA GeForce GT630M顯卡，1 G顯存.性能測試結果見表2.由表2可知，客戶端服務端的資源占用不大，波動幅度在可控范圍之內，硬件壓力較小.

表2 系統(tǒng)性能

4 結語

本系統(tǒng)實現(xiàn)了基于C/S架構的客流檢測功能.在模擬地鐵環(huán)境中進行的性能測試結果表明，系統(tǒng)具有較高的檢測準確度和大量視頻數(shù)據(jù)的實時處理能力，在實現(xiàn)所有功能的前提下，占用服務器資源和客戶機資源較低，且具有很強的擴展性和可維護性.對比傳統(tǒng)的人工監(jiān)控系統(tǒng)，基于C/S架構的客流檢測系統(tǒng)具有高效、穩(wěn)定和準確的優(yōu)點.