楊 坤

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

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

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

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

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

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

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

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

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

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

1.1 HLS

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

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

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

1.2 m3u8和ts

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

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

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

1.3 RTSP 協(xié)議

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

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

圖2 RTSP 請(qǐng)求消息格式圖

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

1.4 FFmpeg 開源庫(kù)

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

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

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

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

圖4 各模塊交互圖

圖5 視頻點(diǎn)播平臺(tái)架構(gòu)圖

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

3.1 監(jiān)控視頻源

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

表1 RTSP 取流格式表

3.2 多媒體處理模塊

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

3.2.1 編碼器

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

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

圖6 編碼器工作流程圖

3.2.2 分割器

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

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

圖7 分割器工作流程圖

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

3.3 Web 請(qǐng)求處理模塊

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

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

圖8 Web 請(qǐng)求處理模塊的工作流程圖

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

3.4 客戶端

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

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

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

圖9 客戶端工作流程圖

4 方案設(shè)計(jì)驗(yàn)證

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

多媒體處理模塊的編碼器和分割器采用基于FFmpeg的開源框架,根據(jù)rtsp 地址參數(shù)與對(duì)應(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 索引文件存儲(chǔ)ts 文件地址最大個(gè)數(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 請(qǐng)求處理模塊是基于Tornado 框架來實(shí)現(xiàn)的,其中,Tornado是一個(gè)基于Python 語(yǔ)言編寫的Web 服務(wù)框架.該模塊接收視頻信息源的請(qǐng)求,并返回對(duì)應(yīng)的m3u8 索引文件;接收ts 流文件的請(qǐng)求,返回對(duì)應(yīng)的流文件內(nèi)容.

4.1 方案效果

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

圖10 示例場(chǎng)景圖

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

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

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

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

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

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

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

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

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

(3)播放數(shù)量?jī)?yōu)化

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

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

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

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

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

4.3 方案對(duì)比

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

表2 不同技術(shù)方案指標(biāo)對(duì)比表

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

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

5 結(jié)論

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