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

烏建中，浦 睿

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

0 引言

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

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

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

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

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

其中服務器端由三部分組成：

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

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

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

2 推流工具框架設計

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

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

圖2 HIKPusher軟件框架

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

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

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

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

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

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

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

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

3.1 預覽請求服務器模塊

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

圖3 預覽請求服務器模塊軟件流程圖

在epoll輪詢處理中加入了請求心跳包檢測機制來判斷當前是否有用戶在預覽。web前端若有用戶在預覽頁面，就會一直有請求心跳包通過調(diào)用后端PHP socket客戶端程序發(fā)送給預覽請求服務器，若離開預覽頁面，請求心跳則消失。檢測機制首先獲得當前的系統(tǒng)時間，若有請求預覽指令到來，則將當前時間記錄下來作為最新請求時間。另外通過設置epoll_wait（）函數(shù)的時間間隔參數(shù)來實現(xiàn)每隔一定時間跳出阻塞，檢測每個IPC的上一個請求心跳包時間和當前系統(tǒng)時間之差，若大于一定的時間，則判定為web端已經(jīng)沒有用戶在預覽頁面了?？紤]到葉片測試現(xiàn)場的特殊網(wǎng)絡環(huán)境，此心跳機制能夠?qū)崟r響應用戶的預覽請求，并且適時地釋放預覽資源，從而節(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包起始的標志：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作為起始標志來界定分割，NALU頭的長度為一個字節(jié)，低5位為此NALU的類型，有即時解碼刷新（IDR）、序列參數(shù)集（SPS）、圖像參數(shù)集（PPS）等。

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

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

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

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

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

當前幀時間戳=上一幀時間戳+1000/fps

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

4 實際應用及效果

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

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

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

圖7 延時性實驗結果

5 結論

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