面向智慧礦山管控平臺的視頻點播技術(shù)①

楊 坤

1(煤炭科學技術(shù)研究院有限公司,北京 100013)

2(煤礦應(yīng)急避險技術(shù)裝備工程研究中心,北京 100013)

3(北京市煤礦安全工程技術(shù)研究中心,北京 100013)

智慧礦山管控平臺是實現(xiàn)智慧礦山建設(shè)的關(guān)鍵之路,它能夠集成、融合、分析與管控各煤礦業(yè)務(wù)系統(tǒng),通過“二三維GIS 一體化”“智能生產(chǎn)”“智慧管理”等業(yè)務(wù)模塊,全面輻射實現(xiàn)煤礦綠色、高效與安全生產(chǎn)的核心業(yè)務(wù)[1,2].視頻監(jiān)控系統(tǒng)作為實現(xiàn)煤礦智能化無人開采的關(guān)鍵系統(tǒng)與煤礦安全生產(chǎn)的多系統(tǒng)協(xié)同分析預(yù)處理的關(guān)鍵信息源,在智慧礦山管控平臺的建設(shè)中發(fā)揮著重要的作用[3,4].視頻監(jiān)控系統(tǒng)作為智慧礦山管控平臺的重要信息,其適用場景存在如下特點:

(1)跨平臺:智慧礦山管控平臺的部分重要場景需要同時在桌面端與移動端展示運行,因此內(nèi)嵌的視頻監(jiān)控信息源也必須滿足跨平臺的特性.

(2)協(xié)同分析:智慧礦山管控平臺是集成、融合、分析與管控煤礦各項業(yè)務(wù)的巨系統(tǒng),其信息來源包含煤礦安全生產(chǎn)的各個方面,且需要滿足多項信息的融、分析與聯(lián)動功能.例如,預(yù)警與報警信息與視頻信息的聯(lián)動就包含:煤礦瓦斯預(yù)警系統(tǒng)發(fā)出預(yù)警、煤礦安全監(jiān)控系統(tǒng)的測點報警與皮帶監(jiān)測系統(tǒng)預(yù)警時,相應(yīng)預(yù)警或報警地點的視頻信息自動彈出.因此,內(nèi)嵌的視頻監(jiān)控信息源無法采用SDK 開發(fā).

(3)無卡頓:智慧礦山管控平臺的視頻窗口彈出播放時,一般都是相關(guān)系統(tǒng)發(fā)出預(yù)警或報警信息.因此,內(nèi)嵌的視頻監(jiān)控信息源也必須滿足無卡頓播放的特性.

(4)多客戶端:智慧礦山管控平臺涉及到煤礦安全生產(chǎn)的各個部門,存在著多個客戶端同時彈出視頻信息的場景與點播視頻信息的場景.因此,內(nèi)嵌的視頻監(jiān)控信息源也必須滿足多客戶端的無卡頓播放的特性.

針對礦井視頻監(jiān)控系統(tǒng)在智慧礦山建設(shè)與煤礦安全生產(chǎn)領(lǐng)域的應(yīng)用得到了大量研究.例如,文獻[5]提出了一種地理信息與礦井視頻融合展示的理念,文獻[6]提出了一種安全檢測、人員定位、語音廣播與礦井視頻信息協(xié)同分析與聯(lián)動的理念.然而,現(xiàn)有的礦井視頻點播技術(shù)一般是基于插件或者專用SDK 來實現(xiàn),無法滿足視頻信息與其他信息系統(tǒng)的協(xié)同分析與處理的理念,造成了智慧礦山管控平臺各業(yè)務(wù)模塊中,無法直接嵌入視頻信息,進而無法實現(xiàn)視頻信息與其他信息系統(tǒng)的協(xié)同分析[7].因此,考慮到現(xiàn)有的智慧礦山管控平臺一般采用B/S 架構(gòu),本文基于HTTP的自適應(yīng)碼率流媒體傳輸協(xié)議與FFmpeg 開源庫設(shè)計了一種視頻點播技術(shù).通過引入hls.js 開源庫,該視頻點播技術(shù)可以將視頻信息嵌入到智慧礦山管控平臺各業(yè)務(wù)模塊,而且能夠滿足任意使用HTML5 技術(shù)的客戶端.

1 視頻點播關(guān)鍵技術(shù)

1.1 HLS

HLS (HTTP live streaming,基于HTTP的自適應(yīng)碼率流媒體傳輸協(xié)議)是蘋果公司開發(fā)的一種面向HTTP 漸進下載的代表性協(xié)議.該協(xié)議將視頻流和音頻流基于HTTP 協(xié)議發(fā)送到客戶端,它最初只是引用在蘋果公司的終端上,現(xiàn)在大多數(shù)桌面應(yīng)用也使用該協(xié)議,例如HTML5 直接支持該協(xié)議[8].

如圖1所示,基于HLS的多媒體技術(shù)一般由多媒體服務(wù)器、分發(fā)服務(wù)器和客戶端組成.多媒體服務(wù)器由編碼器和分割器組成,編碼器主要實現(xiàn)對多媒體信息進行編碼,使之符合HLS 協(xié)議的規(guī)范,能在相應(yīng)的客戶端播放;分割器主要實現(xiàn)對編碼后的多媒體信息進行分割,形成規(guī)定長度的多媒體文件片段和對應(yīng)的m3u8 索引文件.分發(fā)器主要是響應(yīng)客戶端的請求,向客戶端傳輸m3u8 索引文件和多媒體文件片段.客戶端主要是請求多媒體信息文件并重組,以多媒體流的形式展現(xiàn)多媒體信息[9].

圖1 基于HLS的多媒體技術(shù)棧圖

1.2 m3u8和ts

在基于HLS的多媒體技術(shù)中,多媒體服務(wù)器會將采集的音、視頻文件分別進行AAC和H.264 編碼,并將編碼后的數(shù)據(jù)封裝成符合MPEG-2 格式的TS 流文件,然后利用分割器對TS 流文件進行切分,生成一系列.ts 格式的固定長度的多媒體片段和對應(yīng)的.m3u8 格式的索引文件[10].

m3u8 格式的索引文件包含了一系列的多媒體文件的位置.

.ts 文件是以MPEG-2 格式封裝的多媒體流文件,該文件包含的多媒體信息中必須包含足夠的信息以使得解碼器完成初始化工作,且多媒體流文件之間必須包含時間戳與序列號,并在空缺部分加入DISCONTINUITY標簽,否則會引起視頻播放異常.

1.3 RTSP 協(xié)議

RTSP (real time streaming protocol,實時流傳輸協(xié)議)是實現(xiàn)多媒體串流傳輸控制的協(xié)議,其本身并不進行多媒體串流的傳輸,但是可以實現(xiàn)基于RTP (real-time transport protocol,實時傳輸協(xié)議)上的流媒體播放、快進、暫停等操作.RTSP 協(xié)議的作用是為了選擇和控制多個多媒體串流的傳輸通道,用于在客戶端和服務(wù)器之間創(chuàng)建和協(xié)商實時串流的會話,并且可以同時控制多個連續(xù)性的多媒體串流[11,12].

RTSP的消息類型有兩種:請求消息(客戶端對服務(wù)器)與回應(yīng)消息(服務(wù)器對客戶端),消息格式主要包含起始行、標題行、消息主體等.如圖2所示,為RTSP 請求消息格式;如圖3所示,為RTSP 回應(yīng)消息格式.

圖2 RTSP 請求消息格式圖

圖3 RTSP 回應(yīng)消息格式圖

1.4 FFmpeg 開源庫

FFmpeg是由Fabrice Bellard 發(fā)起的一個在Linux平臺上開發(fā)的跨平臺的開源項目.FFmpeg是一種比較領(lǐng)先的多媒體框架,能夠?qū)崿F(xiàn)音視頻的解碼、編碼、轉(zhuǎn)碼、混合、解密、等功能[13].

FFmpeg 包含 libavcodec、libavutil、libavformat、libavfilter、libavdevice、libswscale、libswresample 等庫文件,還包含了 ffmpeg、ffplay和ffprobe 等可以被終端用戶用于轉(zhuǎn)碼和播放的工具.

2 視頻點播整體架構(gòu)

視頻點播整體架構(gòu)是基于HLS 協(xié)議,將礦井監(jiān)控地點的攝像頭的多媒體信息或經(jīng)硬盤錄像機傳輸?shù)亩嗝襟w信息編碼為HLS 流媒體文件,并能夠響應(yīng)客戶端的多媒體請求,展現(xiàn)實時的多媒體信息.該系統(tǒng)分為客戶端模塊、Web 請求處理模塊、多媒體處理模塊、監(jiān)控視頻源,各個模塊的交互關(guān)系如圖4.視頻點播整體架構(gòu)如圖5所示.

圖4 各模塊交互圖

圖5 視頻點播平臺架構(gòu)圖

3 系統(tǒng)中各模塊詳細設(shè)計

3.1 監(jiān)控視頻源

針對礦井建設(shè)的實際情況,礦井下部署的攝像頭分為數(shù)字式網(wǎng)絡(luò)攝像頭與模擬攝像頭,數(shù)字式網(wǎng)絡(luò)攝像頭采集的環(huán)境信息,既可以直接以RTSP 視頻流的形式直接輸出,也可以接入數(shù)字式硬盤錄像機后,由數(shù)字硬盤錄像機以RTSP 視頻流的形式直接輸出.模擬攝像頭須由硬盤錄像機轉(zhuǎn)換接入后,以RTSP 視頻流的形式輸出多媒體信息.以?？诞a(chǎn)品為例,數(shù)字式攝像頭與數(shù)字式硬盤錄像機的RTSP 視頻流的獲取格式如表1所示.

表1 RTSP 取流格式表

3.2 多媒體處理模塊

多媒體處理模塊以FFmpeg 框架為核心,包括編碼器與分割器.

3.2.1 編碼器

編碼器主要是基于從礦井部署的數(shù)字攝像頭或數(shù)字式硬盤錄像機獲取的RTSP 視頻流重新封裝成符合MPEG-2 格式的TS 流文件,主要分為:解析流信息、編碼流信息、添加時間戳、添加附屬信息與封裝TS 流.

編碼器工作的具體流程如圖6所示:首先,從部署的數(shù)字式攝像頭或數(shù)字式硬盤錄像機中獲取的RTSP視頻流信息中解析出RTP (real-time transport protocol,實時傳輸協(xié)議)數(shù)據(jù)包,進一步從RTP 數(shù)據(jù)包中解析出多媒體ES (elementary stream,基本碼流);然后對基本的多媒體信息分別進行編碼:對視頻基本信息進行H.264 編碼,對音頻基本信息進行ACC 編碼;然后將多媒體信息的顯示時間值和解碼時間值添加到編碼后的多媒體基本信息中,形成分組ES;最后,將節(jié)目相關(guān)表、節(jié)目映射表、網(wǎng)絡(luò)信息表等解碼用的PSI (program specification information,節(jié)目專用信息)添加到分組ES,并瘋轉(zhuǎn)成符合MPEG-2 格式的TS 流文件[14].

圖6 編碼器工作流程圖

3.2.2 分割器

分割器主要是實現(xiàn)將符合MPEG-2 格式的TS 流文件按照指定的域指切割成固定大小、可以播放的ts 文件,并在切割的過程中創(chuàng)建一個保存一些列ts 文件地址的m3u8 索引文件.

分割器的工作流程如圖7所示:首先,獲取到符合MPEG-2 格式的TS 流文件與預(yù)設(shè)的分片閾值,查詢TS 傳輸流中是否還有流數(shù)據(jù),若有,則解析TS 流數(shù)據(jù)中每一幀的DTS (decoding time stamp,解碼時間值),當該DTS 值小于預(yù)設(shè)的分片閾值時,則寫入預(yù)定的ts 文件;當該DTS 值大于預(yù)設(shè)的分片閾值時,則關(guān)閉當前的ts 文件,重新打開一個新的ts 文件并寫入.

圖7 分割器工作流程圖

此外,在分割TS 流文件時,會生成一個保存ts 文件的地址的m3u8 索引文件.當產(chǎn)生一個新的ts 文件時,會在m3u8 索引文件的末尾插入一個ts 地址信息,并刪除首部的一個最舊的ts 文件地址信息.

3.3 Web 請求處理模塊

Web 請求處理模塊主要是基于HTTP 協(xié)議響應(yīng)客戶端的請求,在本文設(shè)計的視頻點播平臺中主要實現(xiàn):1)根據(jù)視頻源信息,調(diào)用多媒體處理模塊,生產(chǎn)請求的視頻源信息的m3u8 文件與ts 文件,并返回視頻信息的m3u8 索引文件;2)根據(jù)m3u8 索引文件,返回ts 文件.

Web 請求處理模塊的工作流程如圖8所示,Web 請求處理模塊一直監(jiān)聽客戶端的請求,當監(jiān)聽到客戶端的處理視頻請求就時,首先獲取到src 參數(shù),即rtsp://admin:admin123@192.168.21.5/streaming/channels/10(以某硬盤錄像機,第1 通道的視頻源信息為例),將src 參數(shù)做一個sha256 加密運算,生成一個固定長度的m3u8 文件名,如:“e79e68f070cdedcfe63eaf1a2e-92c83b4cfb1b5c6bc452d214c1b7e77cdfd1c7-playlist.m3u8”,以src 值與m3u8 文件名為參數(shù)調(diào)用多媒體處理模塊,然后檢測文件夾中是否生成了預(yù)設(shè)名稱的m3u8 文件,若生成了,則將m3u8 文件信息返回給客戶端.當客戶端獲取到m3u8 文件信息中ts 文件地址后,則根據(jù)文件地址返回ts 文件信息.

圖8 Web 請求處理模塊的工作流程圖

此外,針對Web 處理模塊中多媒體處理進程與m3u8 文件檢測異常的處理流程為:當檢測到多媒體處理進程工作異常時,則返回給客戶端異常信息;當檢測不到預(yù)設(shè)的m3u8 文件名時,等待1 s,繼續(xù)檢測;當檢測m3u8 文件名的次數(shù)大于20 次時,則拋出異常信息.

3.4 客戶端

結(jié)合現(xiàn)有的智礦山管控平臺的客戶端場景,本文設(shè)計的視頻點播平臺的客戶端以瀏覽器為主.現(xiàn)有的一些瀏覽器還不支持基于HLS 協(xié)議的傳輸多媒體的方式,為使本文設(shè)計的視頻點播平臺兼容所有的瀏覽器,本文在視頻點播場景中使用hls.js 開源庫.

開源的hls.js是一個JavaScript 庫,hls.js 基于HTML5和MSE 技術(shù),實現(xiàn)無插件的方式將MPEG-2 格式的TS 流文件轉(zhuǎn)換成MP4 視頻流,使得TS 流文件可以在HTML5 中的＜Video＞標簽和＜audio＞標簽中播放,從而實現(xiàn)了視頻信息無插件的播放的目的.

基于開源的hls.js 庫實現(xiàn)視頻信息的播放的工作流程如圖9所示,啟動播放窗口后,首先獲取視頻源信息,其格式為:rtsp://admin:admin123@192.168.21.5/streaming/channels/101 (以某硬盤錄像機,第1 通道的視頻源信息為例),將視頻源信息添加到Web 服務(wù)器請求路徑形成組合請求地址,其格式為:http://192.168.21.15:8000/streams/?src=rtsp://admin:admin123@192.168.2 1.5/streaming/channels/101,隨后獲取到返回的最新的m3u8 索引文件,并對其進行解析;然后根據(jù)m3u8 索引文件獲取ts 文件,將獲取到的ts 文件轉(zhuǎn)碼存入ArrayBuffer,并在Media Source 中將ts 文件合流,轉(zhuǎn)換成視頻信息輸出.

圖9 客戶端工作流程圖

4 方案設(shè)計驗證

本文設(shè)計視頻點播平臺實際的開發(fā)環(huán)境選用Ubuntu 20.04 操作系統(tǒng),數(shù)字式硬盤錄像機選用?？低暷承吞柕脑O(shè)備,測試攝像頭連接的硬盤錄像機的通道號為01,其獲取多媒體信息流的RTSP 地址為:rtsp://admin:admin123@192.168.21.5/streaming/channels/101.

多媒體處理模塊的編碼器和分割器采用基于FFmpeg的開源框架,根據(jù)rtsp 地址參數(shù)與對應(yīng)的m3u8 文件地址參數(shù)調(diào)用多媒體處理模塊,其主要格式為:“ffmpeg-copytb 1-r 100-crf 25-preset faster-maxrate 500k-bufsize 1500k-codec copy-hls_time 2-hls_list_size 5-hls_flags delete_segments-start_number 1 619 004 890-y/static/streams/e79e68f070cdedcfe63eaf1a2e92c83 b4cfb1b5c6bc452d214c1b7e77cdfd1c7-playlist.m3u8-i rtsp://admin:admin123@192.168.21.5/streaming/channels/101”,其中,設(shè)定分頻閾值的格式為:-hls_time 2;m3u8 索引文件存儲ts 文件地址最大個數(shù)的指定方式為:-hls_list_size 5;m3u8 文件地址指定方式為:-y/static/streams/e79e68f070cdedcfe63eaf1a2e92c83b4cfb1 b5c6bc452d214c1b7e77cdfd1c7-playlist.m3u8,ts 文件的存放文件夾為/static/streams/;碼流原始文件的獲取地址指定方式為:-i rtsp://admin:admin123@192.168.21.5/streaming/channels/101.

Web 請求處理模塊是基于Tornado 框架來實現(xiàn)的,其中,Tornado是一個基于Python 語言編寫的Web 服務(wù)框架.該模塊接收視頻信息源的請求,并返回對應(yīng)的m3u8 索引文件;接收ts 流文件的請求,返回對應(yīng)的流文件內(nèi)容.

4.1 方案效果

視頻點播平臺搭建完畢后,通過引入hls.js 開源庫,能夠滿足任意使用HTML5 技術(shù)的客戶端,并且可以嵌入智能礦山平臺中任意使用場景.如圖10所示,3D-GIS、2D-GIS、視頻集中展示場景中都可以嵌入本文設(shè)計的視頻點播窗口.

圖10 示例場景圖

4.2 視頻延時優(yōu)化

考慮到HLS 協(xié)議實現(xiàn)方式的限制,基于HLS的視頻播放技術(shù)中存在著播放延時,其理論延時時間如式(1)所示.

為了進一步減少延時的影響,針對理論延時的限制,從以下3 個方面對該點播技術(shù)在智慧礦山管控平臺中的場景做了部分優(yōu)化:

(1)視頻源設(shè)置

視頻分辨率強制為1280×960:針對現(xiàn)有智慧礦山建設(shè)情況的調(diào)研,現(xiàn)有的礦井的攝像頭的分辨率最低為1280×960,將其強制設(shè)置成固定分辨率,可以優(yōu)化多媒體處理模塊動態(tài)化擴展視頻分辨率所占用的資源.

幀數(shù)設(shè)置為25 fps:考慮到人眼的識別率,將現(xiàn)有的礦井的攝像頭的播放幀設(shè)置為25.

I 幀間隔設(shè)置為50 fps:關(guān)鍵幀I 幀設(shè)置為每2 s 包含1 幀,可以對容錯與壓縮進行最大程度的優(yōu)化.

(2)切片優(yōu)化

如式(1)所示,T1越小,T越小,因此,理論上T1設(shè)置的越小越好.但是,考慮到礦井井下網(wǎng)絡(luò)的有波動時,T1過小會造成監(jiān)視圖像中出現(xiàn)灰色輪廓或綠色區(qū)域.根據(jù)關(guān)鍵幀I 設(shè)置為2 s 包含,最終確定T1為2 s.

(3)播放數(shù)量優(yōu)化

如式(1)所示,num1越小,T越小,因此,理論上num1設(shè)置的越小越好.考慮到分段音視頻文件的無縫連接,最終確定num1為2.

(4)客戶端拉流優(yōu)化

針對Web 服務(wù)端的響應(yīng)無法立即在Header 中確定響應(yīng)內(nèi)容大小時,服務(wù)器一般不會提供Content-Length的頭信息,而是會采用HTTP1.1的Transfer-Encoding:chunked.考慮到HLS 協(xié)議的m3u8和ts 文件是動態(tài)生成,在響應(yīng)的過程中可以設(shè)置Transfer-Encoding:chunked,此時,對于分片ts 文件來說,它的生產(chǎn)和發(fā)送就可以實現(xiàn)同步.從而進一步降低播放延時,此時的播放延時時長如式(2)所示.當我們把滿足播放的最小切片個數(shù)設(shè)置為1時,即可實現(xiàn)生產(chǎn)、發(fā)送和播放同步.

其中,T表示延時時間,T1表示生成1 個切片的時長,num1表示滿足播放的最小切片個數(shù),T0表示其他影響因素,且此部分的影響因素一般無法優(yōu)化.

通過以上的優(yōu)化,實驗表明該視頻點播技術(shù)的播放延時可以優(yōu)化到3-4 s,基本可以滿足智慧礦山管控平臺的視頻點播要求.

4.3 方案對比

為了進一步說明該方案在智慧礦山管控平臺的適用特點,如表2所示為本文設(shè)計的視頻點播技術(shù)與現(xiàn)有的主流的Web 視頻點播技術(shù)的相關(guān)指標的測試對比.其中,本文設(shè)計的視頻點播技術(shù)滿足智慧礦山管控平臺的跨平臺、無插件、協(xié)同分析、無卡頓的適用場景;基于?？礢DK 開發(fā)的視頻點播技術(shù)不支持跨平臺與協(xié)同分析,并且在客戶端數(shù)量過多時,存在卡頓現(xiàn)象;基于插件開發(fā)的Web 視頻點播技術(shù)依賴插件,且不滿足協(xié)同分析的要求,并且在客戶端數(shù)量過多時,存在卡頓現(xiàn)象.

表2 不同技術(shù)方案指標對比表

表3的測試環(huán)境為:礦井網(wǎng)絡(luò)帶寬為千兆,攝像頭數(shù)量50 個,在正常生產(chǎn)環(huán)境(其他系統(tǒng)正常運行)下,選取16 路測試視頻集中播放.其結(jié)果如表3所示,其中,在客戶端數(shù)量超過一定限制后,由于基于?？礢DK開發(fā)的Web 視頻點播技術(shù)與基于插件開發(fā)的Web 視頻點播技術(shù)采用直接從攝像頭獲取視頻流的方式播放,存在著卡頓現(xiàn)象,不太適合與智慧礦山管控平臺的適用場景.

表3 不同方案的卡頓現(xiàn)象對比表

5 結(jié)論

本文結(jié)合現(xiàn)有的智慧礦山管控平臺的架構(gòu)特點,基于HLS 協(xié)議與FFmpeg 開源庫,設(shè)計一種面向智慧礦山管控平臺建設(shè)的視頻點播技術(shù).通過引入hls.js 開源庫,該技術(shù)可以在任何使用HTML5 技術(shù)的客戶端中實現(xiàn)視頻信息的點播,實現(xiàn)了智慧礦山管控平臺的跨終端瀏覽器、多業(yè)務(wù)模塊、去插件的嵌入視頻信息,滿足了視頻信息與煤礦安全生產(chǎn)的各業(yè)務(wù)信息的融合展示與協(xié)同分析的需求.