(西安理工大學(xué) 自動(dòng)化與信息工程學(xué)院，西安 710048)

0 引言

如今視頻監(jiān)控技術(shù)取得了很大的進(jìn)步，用戶無論身在何處，只要能夠連接網(wǎng)絡(luò)就能夠隨時(shí)訪問監(jiān)控?cái)z像頭。由于網(wǎng)絡(luò)的開放性，視頻監(jiān)控在給人們提供信息的同時(shí)，視頻監(jiān)控的安全問題也逐漸顯現(xiàn)，日益威脅公眾隱私和治安管理[1]。顯然監(jiān)控視頻信息在傳輸過程中，存在外泄的可能，同時(shí)信息也可能被篡改而導(dǎo)致不完整[2]。因此，加強(qiáng)對(duì)監(jiān)控視頻信息安全的研究，擁有一個(gè)既能保證用戶使用便利又能保障信息安全的視頻監(jiān)控加密系統(tǒng)，對(duì)公眾而言具有重要的意義。

傳統(tǒng)的視頻監(jiān)控系統(tǒng)普遍使用實(shí)時(shí)傳輸協(xié)議(real-time transport protocol，RTP)傳輸監(jiān)控視頻，并配合使用實(shí)時(shí)流傳輸協(xié)議(real-time streaming protocol，RTSP)對(duì)視頻進(jìn)行控制。使用這些協(xié)議的流媒體系統(tǒng)，服務(wù)端需要專門的流媒體服務(wù)器支持，實(shí)現(xiàn)起來較為復(fù)雜[3]。另外支持RTP/RTSP協(xié)議的客戶端所需要的軟硬件資源較多，加密的視頻在瀏覽器端播放需要額外安裝Flash插件，并且Flash這種第三方插件安全性得不到保障[4]。隨著HTML5標(biāo)準(zhǔn)的興起，Web瀏覽器在各方面都有了很大的提升，其原生具有跨平臺(tái)的特性[5]。使用現(xiàn)代Web瀏覽器，借助在移動(dòng)端有良好支持的HTTP Live Streaming(HLS)流媒體傳輸協(xié)議[6]，可以同時(shí)在移動(dòng)端及個(gè)人計(jì)算機(jī)(personal computer，PC)端在不使用第三方插件的情況下直接播放加密監(jiān)控視頻。但是這些現(xiàn)有的系統(tǒng)在監(jiān)控視頻的安全防護(hù)方面還存在不足，這些系統(tǒng)要么僅僅采用權(quán)限控制的方式保護(hù)視頻，并沒有對(duì)視頻本身加密；要么使用HLS協(xié)議中AES-128加密方法對(duì)監(jiān)控視頻中所有數(shù)據(jù)都進(jìn)行了加密。然而這些視頻數(shù)據(jù)中有一些非必要的內(nèi)容是不需要加密的，只要將關(guān)鍵數(shù)據(jù)保護(hù)好就能保障視頻的安全。更多的加密量需要更多的加密周期，過多的加密周期進(jìn)而會(huì)產(chǎn)生不必要的資源消耗，特別是對(duì)資源有限的客戶端來說，在解密視頻過程中不可避免地占用過多的CPU及內(nèi)存資源，影響用戶體驗(yàn)。

針對(duì)以上問題的不足，本文對(duì)現(xiàn)有的視頻監(jiān)控加密系統(tǒng)進(jìn)行優(yōu)化設(shè)計(jì)，將HLS協(xié)議中的SAMPLE-AES加密方法應(yīng)用到系統(tǒng)中，對(duì)視頻中少量的關(guān)鍵數(shù)據(jù)進(jìn)行加密，對(duì)大量的非關(guān)鍵數(shù)據(jù)不加密。在保證安全性的同時(shí)，客戶端播放視頻時(shí)能夠有效減少CPU及內(nèi)存資源的占用，降低客戶端資源的消耗。并借助HTML5及媒體源擴(kuò)展(media source extensions，MSE)技術(shù)，實(shí)現(xiàn)加密監(jiān)控視頻在PC端、iOS移動(dòng)端、Android移動(dòng)端的瀏覽器中無插件地播放的目的。

1 視頻監(jiān)控加密系統(tǒng)整體架構(gòu)

本視頻監(jiān)控加密系統(tǒng)基于HLS協(xié)議，能夠?qū)⒕W(wǎng)絡(luò)監(jiān)控?cái)z像頭中的視頻流實(shí)時(shí)編碼為HLS流媒體，同時(shí)對(duì)視頻中的關(guān)鍵數(shù)據(jù)進(jìn)行選擇性加密保護(hù)，經(jīng)過身份驗(yàn)證后客戶端能夠在全平臺(tái)瀏覽器無插件地播放監(jiān)控視頻。該系統(tǒng)分為監(jiān)控視頻源、服務(wù)端和客戶端，其中服務(wù)端包括編碼加密模塊、內(nèi)容分發(fā)模塊、身份認(rèn)證模塊。視頻監(jiān)控加密系統(tǒng)整體架構(gòu)如圖1所示。

圖1 視頻監(jiān)控加密系統(tǒng)整體架構(gòu)

如圖1可知，監(jiān)控視頻源為網(wǎng)絡(luò)監(jiān)控?cái)z像頭，采集視頻數(shù)據(jù)并向服務(wù)端提供視頻流。服務(wù)端通過攝像頭提供的視頻地址獲得視頻流，編碼器將視頻流進(jìn)行指定格式的編碼，同時(shí)調(diào)用加密器對(duì)視頻流進(jìn)行SAMPLE-AES加密，加密后封裝為MPEG-2傳輸流(transport stream，TS)。然后分割器將TS流切分為TS切片文件并產(chǎn)生索引列表文件，并提供給內(nèi)容分發(fā)模塊?？蛻舳讼胍シ乓曨l，首先通過統(tǒng)一資源定位符(uniform resource locator，URL)地址向內(nèi)容分發(fā)模塊發(fā)送請(qǐng)求，并經(jīng)過身份認(rèn)證模塊的驗(yàn)證。認(rèn)證通過后獲得所需文件，進(jìn)一步解密視頻，并轉(zhuǎn)換為瀏覽器指定的格式進(jìn)行播放。

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

2.1 監(jiān)控視頻源

監(jiān)控視頻源由RTSP網(wǎng)絡(luò)監(jiān)控?cái)z像頭提供，網(wǎng)絡(luò)監(jiān)控?cái)z像頭由模擬攝像模塊和網(wǎng)絡(luò)編碼模塊組成。在網(wǎng)絡(luò)監(jiān)控?cái)z像頭內(nèi)部，模擬攝像模塊采集模擬媒體信號(hào)，經(jīng)過編碼模塊變換成數(shù)字媒體流信號(hào)，然后將其編碼后封裝到RTP包中，并通過有線或無線以RTSP視頻流的形式輸出。

2.2 編碼加密模塊

編碼加密模塊包括編碼器、加密器和分割器。

2.2.1 編碼器

編碼器負(fù)責(zé)將從監(jiān)控視頻源接入的RTSP視頻流實(shí)時(shí)編碼并重新封裝。首先讀取來自網(wǎng)絡(luò)攝像頭的RTSP視頻流，解析視頻流中RTP數(shù)據(jù)包并得到原始基本流(elementary stream，ES)，將視頻ES基本流進(jìn)行H.264編碼，音頻ES基本流進(jìn)行AAC編碼。在編碼后的ES基本流的包頭中分別添加顯示時(shí)間標(biāo)記(presentation time stamp，PTS)、解碼時(shí)間標(biāo)記(decoding time stamp，DTS)并打包成分組基本流(packetized elementary streams，PES)。最后將節(jié)目專用信息(program specific information，PSI)加在PES流上并經(jīng)過復(fù)用器將視頻數(shù)據(jù)封裝到MPEG-2 TS傳輸流中。具體封裝過程如圖2所示。

圖2 封裝成TS流具體過程

如圖2所示，在將進(jìn)行了H.264編碼、AAC編碼之后的音視頻ES流打包之前要做一個(gè)判斷，如果監(jiān)控視頻不需要加密，則進(jìn)行下一步的打包封裝操作；如果需要加密，則調(diào)用加密器，對(duì)音視頻進(jìn)行加密后再進(jìn)行打包封裝操作。

2.2.2 加密器

加密器使用SAMPLE-AES樣本加密方法，先對(duì)音視頻ES基本流進(jìn)行加密再對(duì)其打包封裝。首先生成128位的密鑰文件用于加密并將URL地址發(fā)送給分割器，同時(shí)選擇需要加密的數(shù)據(jù)塊為下一步加密做準(zhǔn)備。H.264視頻加密塊是指定類型的網(wǎng)絡(luò)提取層(network abstraction layer，NAL)單元，音頻加密塊是音頻幀。每個(gè)需要加密的NAL單元或音頻幀都包含整數(shù)個(gè)16字節(jié)塊。然后使用128位密鑰文件采用AES加密算法[7]的密碼塊鏈接(cipher block chaining，CBC)模式對(duì)16字節(jié)數(shù)據(jù)塊進(jìn)行加密，無需填充，在每個(gè)NAL單元或音頻幀的開始處初始化向量(initialization vector，IV)被重置為其原始值。下一步的封裝及分割不會(huì)對(duì)加密的音視頻產(chǎn)生影響。

對(duì)H.264視頻具體加密過程如圖3所示，只加密類型為1和5的NAL單元，其他類型NAL單元不加密。

以下是加密的NAL單元的代碼格式：

Encrypted_nal_unit(){

nal_unit_type_byte // 1個(gè)字節(jié)

unencrypted_leader // 31個(gè)字節(jié)

while(bytes_remaining()> 0){

if(bytes_remaining()> 16){

encrypted_block // 16個(gè)字節(jié)

}

unencrypted_block //1-144字節(jié)

}

}

每個(gè)加密的NAL單元都包含防止二義性的前綴，即包含nal_unit_type值的字節(jié)和后面的31個(gè)字節(jié)，前綴不加密。未加密字節(jié)后面是需要加密的數(shù)據(jù)塊。任何長度不超過16個(gè)字節(jié)的數(shù)據(jù)塊都不需要加密，因此長度為48字節(jié)或更少的NAL單元是完全未加密的。

如圖3，使用10%跳過的加密方式對(duì)NAL單元數(shù)據(jù)塊加密。即先加密16個(gè)字節(jié)的數(shù)據(jù)塊，然后跳過剩下的90%，后面最多有9個(gè)16字節(jié)即144字節(jié)的數(shù)據(jù)塊不加密，第10個(gè)16字節(jié)數(shù)據(jù)塊繼續(xù)進(jìn)行加密，接下來加密形式以此類推。其他類型為1和5的NAL單元只要長度大于48字節(jié)，在被加密時(shí)，要在整個(gè)NAL單元上再次加上前綴。

圖3 H.264樣本加密流程圖

客戶端在解密H.264視頻時(shí)，首先需要識(shí)別類型為1和5同時(shí)長度大于48字節(jié)的NAL單元，然后除去防止二義性的前綴。最后定位到NAL單元的加密部分，并解密該部分的數(shù)據(jù)。

AAC音頻流的加密數(shù)據(jù)塊是包含音頻數(shù)據(jù)傳輸流(audio data transport，ADTS)頭的音頻幀，加密格式如下所示：

Encrypted_AAC_Frame(){

ADTS_Header // 7或9個(gè)字節(jié)

通過地面直達(dá)波或者反射波模型獲取土壤介質(zhì)的平均介電常數(shù)ε，即可以利用CRIM模型可以計(jì)算表層土壤的平均體積含水量：

unencrypted_leader // 16個(gè)字節(jié)

while(bytes_remaining()> = 16){

encrypted_block // 16個(gè)字節(jié)

}

unencrypted_trailer // 0-15個(gè)字節(jié)

}

ADTS頭可以是7或9個(gè)字節(jié)長，加上后面音頻幀的前16個(gè)字節(jié)，這些數(shù)據(jù)不加密，隨后的連續(xù)數(shù)據(jù)部分被加密。加密部分的大小必須是16字節(jié)的整數(shù)倍，并且可能為零。

2.2.3 分割器

分割器負(fù)責(zé)將編碼后的MPEG-2 TS流切分成一系列連續(xù)且播放時(shí)間相等的很小的TS切片文件，然后將其發(fā)送到內(nèi)容分發(fā)模塊進(jìn)行存儲(chǔ)。這些切片文件的大小由用戶提前設(shè)定。如圖4中所示，切分過程中要將DTS差值與用戶設(shè)定的時(shí)間長度進(jìn)行比較，只有達(dá)到用戶設(shè)定的長度時(shí)才生成當(dāng)前切片文件。在對(duì)TS傳輸流進(jìn)行具體分割時(shí)要注意每個(gè)切片文件中都必須含有一個(gè)節(jié)目關(guān)聯(lián)表(program association table，PAT)和一個(gè)節(jié)目映射表(program map table，PMT)，同時(shí)還要保證必須含有至少一個(gè)關(guān)鍵幀和序列頭等信息，從而完成解碼器的初始化。

圖4 TS切片文件生成流程圖

切分過程中要根據(jù)媒體流中每幀圖像的DTS值來計(jì)算DTS差值。DTS差值算法流程如圖5所示。每生成一個(gè)新的TS切片文件，都要記錄第一幀圖像的時(shí)間戳并記作LastTimestampInStream，將該時(shí)間戳作為該切片文件的起始時(shí)間。后續(xù)的圖像都要根據(jù)其當(dāng)前時(shí)間戳CurrentTimestampIntream減去起始時(shí)間LastTimestampInStream，從而計(jì)算出當(dāng)前TS切片文件的時(shí)長。當(dāng)DTS差值達(dá)到用戶提前設(shè)定的TS切片文件時(shí)長時(shí)，便關(guān)閉當(dāng)前TS切片文件，準(zhǔn)備進(jìn)行下一個(gè)TS切片文件的寫入。

圖5 DTS差值算法流程圖

在對(duì)TS傳輸流進(jìn)行分割的同時(shí)，分割器還要?jiǎng)?chuàng)建一個(gè)含有這些TS切片文件URL地址的M3U8索引列表文件，同樣發(fā)送到內(nèi)容分發(fā)模塊存儲(chǔ)。每當(dāng)分割器生成一個(gè)新的TS切片文件時(shí)，這個(gè)M3U8索引列表文件將會(huì)更新，新生成的TS切片的URL地址加入到索引列表文件末尾，同時(shí)時(shí)間最久的處于索引列表開頭部分的切片文件URL地址被移除。如果視頻數(shù)據(jù)被加密，還需要添加#EXT-X-KEY:METHOD=SAMPLE-AES,URI=”KEY文件的地址”標(biāo)簽，表示視頻已經(jīng)使用SAMPLE-AES加密方法加密，并指出相應(yīng)的加密密鑰文件的URL地址。

2.3 內(nèi)容分發(fā)模塊

內(nèi)容分發(fā)模塊是一個(gè)標(biāo)準(zhǔn)的Web服務(wù)器，負(fù)責(zé)將加密并分割后的TS切片文件、密鑰文件及M3U8索引列表文件通過HTTP傳輸協(xié)議發(fā)送到請(qǐng)求的客戶端。為了進(jìn)一步增加傳輸過程中的安全性，本系統(tǒng)中索引列表文件及密鑰文件采用HTTPS協(xié)議進(jìn)行傳輸層安全性協(xié)議(transport layer security，SSL)加密后發(fā)送給客戶端。要支持HLS協(xié)議規(guī)定的媒體類型文件的GET請(qǐng)求，只需要在Web服務(wù)器的媒體多用途互聯(lián)網(wǎng)郵件擴(kuò)展(multipurpose internet mail extensions，MIME)類型中添加如表1所示配置[8]。

表1 媒體MIME類型配置

2.4 身份認(rèn)證模塊

對(duì)于被加密的監(jiān)控視頻，由于其M3U8索引列表文件中直接列出了TS切片及密鑰文件的URL地址，只要獲得了索引列表文件，直接就能獲得密鑰文件并解密視頻。因此本系統(tǒng)對(duì)索引列表文件及加密密鑰文件同時(shí)設(shè)置了訪問權(quán)限驗(yàn)證，確保了由加密、傳輸以及訪問權(quán)限控制的整個(gè)過程的安全。

本模塊采用的是基于Token的身份認(rèn)證機(jī)制[9]，相對(duì)于傳統(tǒng)的Cookie/Session機(jī)制，Token認(rèn)證擴(kuò)展性更強(qiáng)、更安全，有支持跨域訪問、無連接狀態(tài)、去耦合化和更好的性能體驗(yàn)等優(yōu)勢。Token在服務(wù)端產(chǎn)生，客戶端使用用戶名和密碼向身份認(rèn)證模塊請(qǐng)求認(rèn)證，認(rèn)證成功后服務(wù)端為其頒發(fā)一個(gè)獨(dú)有的Token 憑證?？蛻舳丝梢栽诿看握?qǐng)求密鑰文件的時(shí)候在 HTTP 請(qǐng)求的頭部分附加Token證明自己的合法身份，Token認(rèn)證過程如圖6所示。為了保證用戶名、密碼在驗(yàn)證過程以及Token信息在傳輸過程的安全，采用HTTPS協(xié)議對(duì)其進(jìn)行SSL加密后傳輸。

圖6 Token認(rèn)證過程圖

2.5 客戶端

客戶端包括PC端、iOS移動(dòng)端、Android移動(dòng)端的Web瀏覽器，用戶在瀏覽器上首先經(jīng)過身份驗(yàn)證，認(rèn)證通過后通過指定的URL地址，基于HTTP請(qǐng)求來獲取和下載索引列表文件，并通過索引列表進(jìn)一步獲得TS切片文件和密鑰文件。接下來瀏覽器用密鑰文件解密TS切片并將解密后的TS切片直接便捷地使用HTML5中新增的

目前現(xiàn)代瀏覽器都支持MTHL5技術(shù)和MSE技術(shù)，但是PC端一些主流瀏覽器(如谷歌瀏覽器、火狐瀏覽器)還不支持HLS協(xié)議中的TS傳輸流。為了使這些主流瀏覽器也能夠無插件播放視頻，本系統(tǒng)在客戶端請(qǐng)求的網(wǎng)頁中嵌入了hls.js開源庫[10]。

開源庫hls.js基于HTML5和MSE技術(shù)，原理是通過調(diào)用MSE API來使用JavaScript不使用任何插件動(dòng)態(tài)地將MPEG-2 TS傳輸流轉(zhuǎn)換為MP4片段并提供給

3 系統(tǒng)實(shí)現(xiàn)及結(jié)果分析

3.1 系統(tǒng)實(shí)現(xiàn)及播放效果

本系統(tǒng)的開發(fā)環(huán)境為CentOS Linux 7操作系統(tǒng)，網(wǎng)絡(luò)攝像頭型號(hào)為?？低旸S-2CD1221D-I3，根據(jù)攝像頭的型號(hào)得到監(jiān)控視頻取流的RTSP地址，本系統(tǒng)采用默認(rèn)的用戶名密碼，地址為：rtsp://admin:12345@172.6.22.234:554/ Streaming/Channels/101?transportmode=unicast。然后將這個(gè)RTSP視頻流地址提供給服務(wù)端編碼加密模塊中的編碼器。

編碼加密模塊基于FFmpeg開源編解碼框架，首先通過調(diào)用AVInputFormat結(jié)構(gòu)體中的ff_rtsp_demuxer函數(shù)解析RTSP視頻流；然后調(diào)用AVCodec結(jié)構(gòu)體中的ff_libx264_encoder函數(shù)對(duì)視頻進(jìn)行編碼；最后調(diào)用AVOutputFormat結(jié)構(gòu)體中的ff_mpegts_muxer函數(shù)和ff_stream_segment_muxer函數(shù)將依次對(duì)視頻進(jìn)行封裝和切分。需要對(duì)其中ff_libx264_encoder函數(shù)中的X264_frame()函數(shù)進(jìn)行修改，在encode_nals()函數(shù)后添加擁有SAMPLE-AES加密功能的nal_sample_encrypt()函數(shù)，用于對(duì)編碼后NAL單元進(jìn)行加密。

內(nèi)容分發(fā)模塊采用內(nèi)存占用小、性能穩(wěn)定的Nginx作為Web服務(wù)器。身份認(rèn)證模塊沒有單獨(dú)另外搭建一個(gè)認(rèn)證服務(wù)器，而是通過將lua語言嵌入到高性能的Nginx服務(wù)器中，使Nginx可以高并發(fā)、非堵塞地處理Token認(rèn)證請(qǐng)求，并利用redis鍵值數(shù)據(jù)庫的超時(shí)機(jī)制設(shè)置Token時(shí)效性來控制Token的有效性。由于OpenResty是一個(gè)集成了Nginx與lua的高性能Web平臺(tái)[11]，因此本系統(tǒng)直接安裝OpenResty與redis，共同實(shí)現(xiàn)內(nèi)容分發(fā)及Token認(rèn)證的功能。安裝后需要編寫lua腳本實(shí)現(xiàn)Token驗(yàn)證，包含的主要腳本有：auth_req_headers.lua，請(qǐng)求頭校驗(yàn)?zāi)_本，失敗直接中斷請(qǐng)求；auth_token.lua，Token處理腳本；handle_cors.lua，請(qǐng)求跨域腳本；handle_request_provision.lua，請(qǐng)求handle入口腳本；redis_mcredis.lua，redis操作工具的封裝腳本；tool_dns_server.lua，域名解析，獲取域名對(duì)應(yīng)IP，并設(shè)置緩存的腳本。

系統(tǒng)搭建好之后，觀察播放效果，如圖7所示，PC端的谷歌瀏覽器，iPad端的Safari瀏覽器、Android端谷歌瀏覽器及微信端網(wǎng)頁各個(gè)平臺(tái)都能滿足使用HTML5技術(shù)直接無插件地播放加密監(jiān)控視頻。

圖7 各個(gè)平臺(tái)播放效果圖

3.2 安全性分析

NAL單元中最重要的單元類型是1和5，包含了所有的視頻數(shù)據(jù)。類型為5的NAL單元負(fù)載中包含的是立即刷新圖像(instantaneous decoding refresh，IDR)的圖像片段，類型為1的NAL單元負(fù)載包含的是非IDR幀的圖像片段，解碼器在收到IDR數(shù)據(jù)單元后會(huì)立即刷新所有圖像，并作為之后的所有數(shù)據(jù)的解碼參照。因此對(duì)這些最重要的包含了圖像片段的NAL單元類型進(jìn)行選擇性加密，即使其他類型不加密，非授權(quán)用戶也無法正確解碼視頻。并且加密過程采用的是AES加密算法，AES加密算法為新一代數(shù)據(jù)加密標(biāo)準(zhǔn)，能夠同時(shí)滿足強(qiáng)安全性、高效率、高性能、易用和靈活的特點(diǎn)[7]。AES加密算法是目前可獲得的最安全的對(duì)稱加密算法，密鑰長度達(dá)到128位就能達(dá)到保護(hù)機(jī)密信息的標(biāo)準(zhǔn)。另外NAL單元中相對(duì)固定的頭部信息沒有加密，可以有效防止明文攻擊。在沒有密鑰的情況下播放加密的監(jiān)控視頻效果如圖8所示。

圖8 加密后播放效果圖

同時(shí)，本系統(tǒng)采用高度安全的HTTPS協(xié)議對(duì)索引列表文件及密鑰文件進(jìn)行傳輸，給攻擊者增加了巨大的難度，根本無法獲得密鑰信息?？蛻舳瞬捎昧税踩愿叩幕赥oken的身份認(rèn)證機(jī)制有效攔截了非授權(quán)用戶的播放。

3.3 實(shí)驗(yàn)結(jié)果對(duì)比分析

將本系統(tǒng)與現(xiàn)有使用AES-128加密方法的其他監(jiān)控加密系統(tǒng)進(jìn)行對(duì)比，檢測客戶端播放加密視頻過程中的CPU占用率及內(nèi)存使用率。采用同一個(gè)監(jiān)控視頻源，相同播放平臺(tái)，都是借助HTML5進(jìn)行播放，不同的是監(jiān)控視頻在不同加密系統(tǒng)中使用不同加密方法加密。

本次實(shí)驗(yàn)的播放平臺(tái)選用內(nèi)存為16 GB，處理器為Inter i5-4590 CPU@3.30 GHz x 4的 PC端的谷歌瀏覽器。客戶端在播放視頻過程中CPU使用率對(duì)比結(jié)果如圖9所示，客戶端內(nèi)存占用率對(duì)比結(jié)果如圖10所示。

圖9 客戶端CPU消耗對(duì)比

圖10 客戶端內(nèi)存占用率對(duì)比

由圖10及圖11實(shí)驗(yàn)結(jié)果可知，本系統(tǒng)由于采用SAMPLE-AES加密方法，沒有對(duì)所有視頻數(shù)據(jù)都進(jìn)行加密，而是對(duì)監(jiān)控視頻中包含視頻片段的NAL單元進(jìn)行選擇性加密，從而有效減少加密周期，進(jìn)一步降低了客戶端解密過程的復(fù)雜度，減少了在CPU占用及內(nèi)存使用中而產(chǎn)生的不必要的消耗，用戶體驗(yàn)得到有效提升。

4 總結(jié)

本文對(duì)現(xiàn)有的視頻監(jiān)控加密系統(tǒng)進(jìn)行了優(yōu)化設(shè)計(jì)，將HLS協(xié)議中的SAMPLE-AES加密方法應(yīng)用在系統(tǒng)中，選擇性地加密視頻中的關(guān)鍵數(shù)據(jù)。與現(xiàn)有系統(tǒng)相比，在保證安全性的同時(shí)播放加密視頻的客戶端CPU及內(nèi)存消耗明顯

減少。并借助HTML5及MSE技術(shù)，實(shí)現(xiàn)了全平臺(tái)瀏覽器無插件地播放加密監(jiān)控視頻。這種視頻監(jiān)控加密系統(tǒng)在安防領(lǐng)域有廣泛的應(yīng)用前景。