基于實時推流工具的風(fēng)機葉片測試過程視頻監(jiān)控

烏建中，浦 睿

（同濟大學(xué)機械與能源工程學(xué)院，上海201804）

0 引言

風(fēng)電葉片是風(fēng)力發(fā)電機組的關(guān)鍵部件，所有新設(shè)計的葉片在投入批量生產(chǎn)前，都要進行全尺寸結(jié)構(gòu)試驗以確定葉片質(zhì)量是否符合設(shè)計要求。但是，在葉片加載測試現(xiàn)場，長期的監(jiān)控看管給企業(yè)帶來了較大的人力物力成本，同時葉片的遠(yuǎn)程認(rèn)證也有著諸多不便，葉片加載系統(tǒng)的實時監(jiān)控可改善的空間很大。傳統(tǒng)的遠(yuǎn)程監(jiān)控需要客戶安裝相應(yīng)軟件，雖然專用性強，但不利于升級維護。由于依賴于軟件的安裝，所以也不能實現(xiàn)隨時隨地的即時監(jiān)控。web瀏覽器作為互聯(lián)網(wǎng)用戶最經(jīng)常使用的客戶端程序，為各種網(wǎng)絡(luò)媒體數(shù)據(jù)的傳播提供了通用穩(wěn)定的渠道。將web和現(xiàn)場視頻監(jiān)控結(jié)合將會極大地提升監(jiān)控系統(tǒng)的便利性[1]。為了解決葉片測試現(xiàn)場實時監(jiān)控的實際工程問題，本文以Linux為平臺，提出了一個較為通用的基于web的遠(yuǎn)程視頻監(jiān)控方案，利用某型網(wǎng)絡(luò)攝像機的二次開發(fā)包，設(shè)計了一個與流媒體服務(wù)器對接的實時流推送工具。

1 系統(tǒng)方案設(shè)計

由于風(fēng)機葉片測試場地的多樣性和測試過程的持久性，存在不同的測試地點需要實時監(jiān)控以確保測試過程的安全進行，這就給系統(tǒng)提出了不同用戶低延時并發(fā)監(jiān)視不同地點的要求。而采用流媒體服務(wù)器作為實時視頻取流分發(fā)的中轉(zhuǎn)站將很好地滿足風(fēng)機葉片測試場景的需求。基于web的實時視頻監(jiān)控系統(tǒng)的服務(wù)器端向前直接連接大量瀏覽器的請求，向后連接各種實時視頻流源，提供流媒體協(xié)議轉(zhuǎn)換、實時流分發(fā)、預(yù)覽請求監(jiān)聽等功能，其性能直接影響到整個監(jiān)控系統(tǒng)的運行。

本文采用某型網(wǎng)絡(luò)攝像機（IPC）為底層視頻采集器，配有基于EHome協(xié)議的C語言SDK，已封裝好相應(yīng)產(chǎn)品的底層交互，并基于此SDK研究開發(fā)了一款多攝像頭推流的實時視頻流推送工具。整個實時視頻監(jiān)控系統(tǒng)總共分為三部分：瀏覽器客戶端、服務(wù)器端和底視頻采集端[2]，如圖1所示。

圖1 遠(yuǎn)程視頻監(jiān)控系統(tǒng)框架

其中服務(wù)器端由三部分組成：

（1）web服務(wù)器 采用穩(wěn)定輕量的HTTP服務(wù)器Nginx，負(fù)責(zé)接收瀏覽器端的用戶預(yù)覽監(jiān)控的請求，將此請求從前端傳至后端，最終傳給推流工具。

（2）流媒體服務(wù)器 在各流媒體傳輸協(xié)議中，RTMP協(xié)議與web兼容性最好，可基于flash實現(xiàn)無插件播放，采用Nginx的nginx-rtmp模塊，負(fù)責(zé)接收推流工具產(chǎn)生的RTMP視頻流，并通過瀏覽器中的flash播放器進行分發(fā)播放。

（3）推流工具 命名為HIKPusher，負(fù)責(zé)瀏覽器端的預(yù)覽請求監(jiān)聽，遠(yuǎn)端葉片測試現(xiàn)場IPC的注冊和連接管理，流媒體協(xié)議轉(zhuǎn)換等，是服務(wù)器端及整個實時視頻監(jiān)控系統(tǒng)的核心。

2 推流工具框架設(shè)計

通過推流工具的使用場景分析，確定了對外需要接受web端的預(yù)覽請求并將其轉(zhuǎn)化為IPC的預(yù)覽指令，對內(nèi)需要實現(xiàn)流媒體協(xié)議的轉(zhuǎn)化以便發(fā)送給流媒體服務(wù)器的需求[3]。HIKPusher主要模塊劃分如圖2所示。

意識形態(tài)作為一種價值觀和思想體系，應(yīng)該反映和表現(xiàn)社會成員的共同利益，并以特定的道德觀念加以強化，以達(dá)成共識、消弭紛爭，具有政治整合、制度合法性支持以及政治社會化的作用。正如馬克斯·韋伯所指出的:“一切經(jīng)驗表明，沒有任何一種統(tǒng)治自愿地滿足于僅僅以物質(zhì)的動機或者僅僅以情緒的動機，或者僅僅以價值合乎理性的動機，作為其繼續(xù)存在的機會。毋寧說，任何統(tǒng)治都企圖喚起并維持對它的‘合法性’的信仰。”?可見，制度合法性信仰的建構(gòu)對于國家統(tǒng)治的穩(wěn)固尤為重要。國民黨執(zhí)政時期，對于穩(wěn)固自身統(tǒng)治及與中共競逐，意識形態(tài)因素都扮演著重要的角色。

圖2 HIKPusher軟件框架

整個框架主要分為五大模塊：

（1）預(yù)覽請求服務(wù)器模塊 負(fù)責(zé)監(jiān)聽web瀏覽器端的用戶預(yù)覽請求，將請求傳送給注冊管理模塊進行后續(xù)處理。

（2）注冊管理模塊 是推流工具中直接與IPC對接的模塊，負(fù)責(zé)IPC的注冊和連接管理，下發(fā)各種指令等。

（3）視頻分發(fā)模塊可看作一個小型流媒體服務(wù)器，負(fù)責(zé)接收原始RTP流并交給協(xié)議轉(zhuǎn)換模塊進行后續(xù)處理。

（4）協(xié)議轉(zhuǎn)換模塊是整個推流工具的核心模塊，負(fù)責(zé)IPC的RTP流到RTMP流的協(xié)議轉(zhuǎn)換，是連接IPC和流媒體服務(wù)器的橋梁。

（5）其它模塊比如日志記錄模塊，用于推流工具運行信息查詢等。

其中，注冊管理模塊和視頻分發(fā)模塊屬于EHomeSDK中的原生模塊，采取了線程池的方式來同時處理多路IPC的實時流，從而實現(xiàn)風(fēng)機葉片多測試地點的并發(fā)推流。RTMP流推送部分采用了在流媒體項目中廣泛使用的librtmp開源第三方庫。

3 推流工具主要模塊實現(xiàn)

3.1 預(yù)覽請求服務(wù)器模塊

預(yù)覽請求服務(wù)器模塊的主要功能是C/S模型下的請求監(jiān)聽，由于可能在某個時刻會同時有多個用戶的預(yù)覽請求，所以采取了多路I/O復(fù)用機制中的epoll模型。程序流程圖如圖3所示。

圖3 預(yù)覽請求服務(wù)器模塊軟件流程圖

在epoll輪詢處理中加入了請求心跳包檢測機制來判斷當(dāng)前是否有用戶在預(yù)覽。web前端若有用戶在預(yù)覽頁面，就會一直有請求心跳包通過調(diào)用后端PHP socket客戶端程序發(fā)送給預(yù)覽請求服務(wù)器，若離開預(yù)覽頁面，請求心跳則消失。檢測機制首先獲得當(dāng)前的系統(tǒng)時間，若有請求預(yù)覽指令到來，則將當(dāng)前時間記錄下來作為最新請求時間。另外通過設(shè)置epoll_wait（）函數(shù)的時間間隔參數(shù)來實現(xiàn)每隔一定時間跳出阻塞，檢測每個IPC的上一個請求心跳包時間和當(dāng)前系統(tǒng)時間之差，若大于一定的時間，則判定為web端已經(jīng)沒有用戶在預(yù)覽頁面了。考慮到葉片測試現(xiàn)場的特殊網(wǎng)絡(luò)環(huán)境，此心跳機制能夠?qū)崟r響應(yīng)用戶的預(yù)覽請求，并且適時地釋放預(yù)覽資源，從而節(jié)約傳輸流量。

3.2 協(xié)議轉(zhuǎn)換模塊

實際傳輸中，EHomeSDK中取到的IPC實時視頻流為私有RTP協(xié)議，并且荷載的是PS流。視頻編碼方面，由于H264編碼使用廣泛，原生RTMP協(xié)議本身對于H265（HEVC）并不支持，考慮到平臺環(huán)境兼容性，配置IPC為H264編碼。故而整個協(xié)議轉(zhuǎn)換模塊的思路就是從IPC的私有RTP流中剝出PS流，再取出H264裸流，然后使用librtmp庫對H264數(shù)據(jù)進行封裝傳輸[4]。

協(xié)議轉(zhuǎn)換的實現(xiàn)基于PS解析器和H264解析器這兩個解析程序段。此私有RTP流中RTP頭由40個字節(jié)組成，將其剝?nèi)ゾ偷玫搅撕奢d的PS流，而PS流由多個PES包組成，其格式如圖4所示。

圖4 PES包格式

由此可見，只需要找到PES包起始的標(biāo)志：00 00 01 E0，并根據(jù)其中的長度信息就能解析出荷載的H264裸流。PS解析器核心解析函數(shù)如下：

int PS_ParserPES（char**pack，int*pack_len，char**payload，int*payload_len）；

四個入口參數(shù)均為傳入傳出參數(shù)，其中pack為PES包處理前起始位置和處理后下一個包的位置，payload為PES包中荷載的H264裸流的位置。由于函數(shù)外PS流的內(nèi)存空間已分配，為了節(jié)省內(nèi)存空間和降低拷貝時間消耗，函數(shù)內(nèi)部沒有分配內(nèi)存空間，只是做指針值的修改，從而減少了內(nèi)存泄露等問題的產(chǎn)生。

H264裸流由許多NAL單元組成，而NALU由NAL頭和原始字節(jié)序列載荷組成，一般情況下，NALU會以00 00 01或00 00 00 01作為起始標(biāo)志來界定分割，NALU頭的長度為一個字節(jié)，低5位為此NALU的類型，有即時解碼刷新（IDR）、序列參數(shù)集（SPS）、圖像參數(shù)集（PPS）等。

RTMP封裝視頻部分的數(shù)據(jù)格式如圖5所示。視頻包頭中高四位為后面NALU幀類型，主要分為關(guān)鍵幀和非關(guān)鍵幀。在一個H264圖像序列中，第一個I幀為IDR幀，當(dāng)解碼器收到此類幀時，會立即將參考幀隊列清空，重新查找參數(shù)集并開始新序列，所以IDR幀作為關(guān)鍵幀傳輸。同時解碼器需要重新讀入?yún)?shù)集，即SPS幀和PPS幀，所以在發(fā)送IDR幀前也需要將這兩種幀作為關(guān)鍵幀重新發(fā)送。

圖5 RTMP視頻包數(shù)據(jù)格式

包頭中低四位為解碼此視頻包的解碼器種類，本文中為AVC（H264）。包類型常見有AVC序列頭和AVC NALU.AVC序列頭為解碼器解碼所需的重要信息，即SPS幀和PPS幀。由于librtmp發(fā)送時需要另外指定時間戳，此處相對時間戳一般全為0.

以上分析得到了在發(fā)送RTMP包時整個視頻數(shù)據(jù)包的結(jié)構(gòu)，包括重要字節(jié)中標(biāo)志位的選取。通常情況下H264碼流的第一個NALU是SPS幀，第二個NALU是PPS幀，緊接著就是多個I幀，后續(xù)碼流以此結(jié)構(gòu)形式循環(huán)。在取出了RTP流中的H264裸流之后，H264解析器只需要根據(jù)此結(jié)構(gòu)形式將每個NALU解析后按照圖5的格式插入進包尾即可。

librtmp庫對于RTMP流的底層發(fā)送已封裝成RTMP_SendPacket（）函數(shù)，核心入口參數(shù)為 RTMPPacket結(jié)構(gòu)體。其中需要說明的是m_nTimeStamp結(jié)構(gòu)體成員，本文中使用絕對時間戳對視頻流進行標(biāo)記，時間戳計算公式為：

當(dāng)前幀時間戳=上一幀時間戳+1000/fps

一般視頻時間戳可以從0開始計算，則每一幀的時間戳每次只需加上一個常量即可。fps為視頻幀率，可以根據(jù)H264相關(guān)文檔從SPS幀中解析獲得。在填寫好所有主要結(jié)構(gòu)體參數(shù)之后，將前面所述的視頻數(shù)據(jù)包內(nèi)容拷貝進結(jié)構(gòu)體中m_body數(shù)組，即可調(diào)用RTMP_SendPacket（）函數(shù)向流媒體服務(wù)器進行最后發(fā)送。

4 實際應(yīng)用及效果

將推流工具部署在一臺擁有公網(wǎng)ip地址的2核8G云服務(wù)器上，操作系統(tǒng)為Ubuntu 16.04.實際監(jiān)控場景為上海某工廠葉片疲勞測試現(xiàn)場，用戶登錄系統(tǒng)后選擇相應(yīng)的葉片測試地點，并點擊現(xiàn)場視頻界面即可進入視頻監(jiān)控。頁面采用了JW Player開源播放器從流媒體服務(wù)器實時拉取RTMP視頻流進行解碼播放，監(jiān)控網(wǎng)頁如圖6所示。

圖6 視頻監(jiān)控顯示頁面

一般地，評價視頻監(jiān)控性能的主要指標(biāo)是實時性，并通過延遲時間來體現(xiàn)。視頻延遲是指圖像從底層IPC采集完成經(jīng)服務(wù)器端中轉(zhuǎn)，通過播放器顯示給用戶的時間差。對整個葉片測試視頻監(jiān)控系統(tǒng)的實時性進行測試，試驗一共進行了200組，結(jié)果如圖7.可以看出延遲時間為2 s左右，考慮到工業(yè)現(xiàn)場網(wǎng)絡(luò)狀況，此結(jié)果滿足葉片測試視頻監(jiān)控要求。

圖7 延時性實驗結(jié)果

5 結(jié)論

本文基于librtmp庫和EHomeSDK自行開發(fā)了一款支持多攝像頭注冊，響應(yīng)多路預(yù)覽請求，并分別向流媒體服務(wù)器推流的實時視頻流推送工具。很好地改善了風(fēng)機葉片測試現(xiàn)場的監(jiān)控環(huán)境，有效地節(jié)省了人力物力，保障了測試過程的安全性，為葉片遠(yuǎn)程認(rèn)證提供了一種可能途徑。同時，其軟件架構(gòu)也方便擴展和移植更多功能，為其它基于web的視頻監(jiān)控場景提供了一種有效的方案。