视频监控存储

一、背景介绍

不管是传统视频监控领域还是逐步普及的家用网络摄像头,视频内容的录像存储都是一个比较有挑战的课题。传统的监控录像分为摄像机终端上的卡录、NVR/CVR上的存储两种场景。随着数字化和智能化的发展需要,越来越多的场景会把视频流实时的上传到云端进行存储。视频监控内容因为其数据量大、特殊的访问模式等因素,需要有针对性的进行设计。视频监控的存储系统是一个专门为垂直场景而设计的,必须先要了解数据的特性、存储介质、访问模式等,这样才能针对场景做一些Tradeoff,获得想要的表现。

视频数据特性

存储的视频数据是通过视频编码算法(比如H264、H265)压缩后的数据,以帧为单位来处理的。每一帧都有一个对应的时间戳。视频压缩算法原理主要是利用图像在时间和空间上的冗余特性来降低传输的数据量。特别的对于时间上冗余主要就是相邻的画面之间大部分信息都是重复的,只有移动的对象有微小的变化。在视频编码里就充分利用这些冗余特性,采用帧内预测、帧间预测、运动估计等手段,极大了提升了视频的压缩效率。这样就造成了帧和帧之间并不是完全独立编码的,帧之间存在一定的参考和依赖关系。

在H.264/H.265编码里,视频帧可以分成I帧,P帧和B帧。I帧可以独立解码,但是对于P帧和B帧就需要依赖其他的帧。如果一个I帧之后的所有帧都不依赖这个I帧之前的帧,那么这样的I帧就是IDR帧。一般情况下视频解码必须要从某一个IDR帧开始解码,一个IDR和对依赖它的一组帧形成一个组(GOP)。GOP越大,压缩的效率可能会越高,但是随即访问时,就需要从IDR帧开始解码到所需要访问的时间点。一般情况下,当画面变化比较大的情况下(比如场景切换),编码器会重新生成一个I帧。在监控或直播的场合下,因为要保障用户能快速看到画面,通常2到4秒就会强制刷新一个IDR帧。

存储介质(磁盘)的特性

对于普通的大容量存储,机械盘还是最常见的选择。而对于嵌入式设备,则通常使用的是基于NAND Flash的存储介质。传统机械盘因为有机械装置,有寻道的过程,所以对于顺序读写和随机读写的性能差别非常大。而对于Flash介质,比如SD卡或固态硬盘,随机读写的性能就不会受到那么大的影响。不过,Flash介质也有它自己的特性,在每次写入的时候需要进行擦除操作,而设备的寿命受限与于实际的擦写次数,通常Flash设备的控制器会自动进行磨损平衡。

用户访问特性

对于视频监控来说,录像存储只需要记录一次,而在使用的时候,则可能被多次反复的读取。访问的模式通常是从某个时间点按顺序提取数据,提取的粒度通常是某个视频通道,持续的时长则根据实际的场景情况有较大差异。如果读取是用播放器来播放,播放器还支持倍速、前进、回退、跳帧播放等。总体概括起来就是小范围连续,大范围跳跃,按时间检索

二. 视频存储场景

现实场景中,根据数据的存储位置,大概可以分成三个层次:设备上的卡录存储、边缘NVR存储和云端存储。存储的介质和对应的存储系统都有所不同。这些存储系统一方面要满足通用的功能,比如支持按时间来访问录像内容,并支持倍速、seek以及trick模式的播放,支持对磁盘空间的合理应用、最大化吞吐,支持掉电后最大程度的恢复数据以及数据方便导出与利用等,另一方面不同场景下又会有各自独特的挑战需要去应对,下面来分别讨论一下。

设备端卡录

设备端的卡录是把录像数据存储到设备本地的存储卡上,当存储满后进行循环淘汰覆盖,始终保持最新的录像数据。例如一个16GB的卡,如果码率是512kbps,7×24小时录像,大约可以存储3天的时长。不管是FAT32还是ext3/ext4文件系统,都可以分为meta信息部分和真实的数据区部分。在读写非常频繁、设备掉电等多种情况下,会导致meta信息与数据的不一致。对于Flash存储设备,频繁或非法的读写还会导致进入写保护状态,无法继续写入录像数据。在普通pc和服务器上可以有一些fsck之类的工具进行修复,但对于嵌入式系统,我们需要尽量避免这种情况的出现,尽量减少对文件系统meta信息的改变。

基于上述的原因,通常采用的方式是固定块循环覆盖写的方式。例如每个文件是固定的512MB(可配置),初次创建的时候,可以不预先占用空间,等逐步写入视频数据后逐步增加大小,一旦写满后,文件就不再删除,通过循环覆盖的方式淘汰旧的历史数据。不过这种写入方式适合流式访问的视频容器,典型的是PS格式,整体overhead不算太高,又支持流式的写入,中间有数据丢失也比较容易恢复(PS格式有用来同步的头)。不过PS格式的缺点就是没有索引,播放时不方便进行Seek操作。

1)全时段录像 vs. 事件触发型

由于全时段录像需要大量的存储空间,带来比较高的成本。而实际情况下,视频画面在很多场景下并没有任何有用的信息,比如一个无人的室内场景,画面绝大部分时间都是静止的,但是录像还是一直在存储,浪费存储空间。一个可行的办法就是当画面的内容有变化或者有感兴趣的事件发生时,才对视频流进行录像存储。典型的方式是加上移动侦测算法或人脸、人体检测算法,当有事件触发时,录像立即开启。这种方式即不会漏掉事件,也不会浪费存储空间。

2)磁盘空间管理

由于存储设备的容量是有限的,随着时间的推移,录像数据一定会装满整个存储区域。当存储空间耗尽后,需要有一定的方式对老的存储空间进行重复利用。另外,除了视频录像,还有一些额外的信息也需要存储,比如截图,业务数据和日志之类的。存储模块的磁盘管理需要支持多样的模式来管理磁盘空间。

  • 最大使用空间:存储录像的部分不会超过这个限制容量
  • 最小保留空间:始终要保留一个固定容量的空间,比如512MB
  • 最小保留比例:始终要保持超过10%的剩余空间

NVR上的存储

NVR上的存储与IPC上的卡录存储最大的区别有两个方面:存储介质和存储路数。普通的IPC上的卡录存储一般只需要存储一路最清晰的码流,而NVR一般是接入很多个前端设备。存储介质上,IPC上的存储卡通常是基于Flash的,但在NVR上出于成本考虑通常会采用SATA盘,而且NVR还需要支撑足够多的容量,所以还会使用很多块磁盘形成阵列。SATA盘是机械盘,会有随机读写效率差的问题,多路的实时交叉写入则会进一步加剧这种随机读写的问题。相对IPC设备上的存储而言,NVR上的存储系统设计要困难的多。

对于存储设备,通常是按Sector/Block来管理的,一个逻辑文件通常包含很多个扇区,随着文件的创建、删除、修改,会让整个磁盘的扇区使用情况形成诸多碎片。碎片一方面会导致读取时带来随机访问降低吞吐,另外一方面在写入时也需要花费更多的时间来分配合适的扇区写入新的数据。

1)多通道管理

音视频数据一般是以比较均匀的频率(FPS是固定的)来写入数据的,视频数据的I、P、B帧的大小差异较大,音频的数据帧大小则比较接近。通常有两种方式来组织数据存储,一种是每个码流写独立的文件,另一种是不同的码流都写入同一个文件,不同码流间的数据是以帧为单位交错的。但是从磁盘角度看,多个文件独立写,其实等价一种随机写,也是不利于机械盘的整体吞吐的。合并写入到一个文件流的方式则不会带来随机写和碎片问题,但代价是只读取某个通道数据时对应的代价稍大。前面也提到过视频录像存储的特性其实是写多读少,对于多通道的模式,其实更适合多通道的数据合并写入。

2)多磁盘管理

在NVR的场景,通常会挂载多块硬盘。为了提升整体的吞吐,需要把码流的写入分摊到多块磁盘上,并行写入。为了简化设计,一般一个固定的通道被分配在一个固定的物理磁盘上,比如6路码流3块磁盘,我们就可以每块磁盘上写入2路视频流。常规情况下,这种分配相对固定,但是在频流路数和磁盘设备数有增减时,需要重新调整分配策略。另外一个比较麻烦就是这个分配的结果也是需要记录下来的,如果只记录在一块磁盘上,当这块磁盘损坏时就会导致信息丢失,所以最好的方式是有多副本,还要处理好数据一致性和淘汰问题,这个机制也是一个很复杂的问题,这里不做过多的阐述。

3)数据冗余(RAID)

由于磁盘是有一定损坏概率的,为了保障数据可靠性,NVR通常会采用带一定冗余的磁盘阵列(RAID)来存储数据。RAID分很多种级别和使用方式,不过大部分的RAID都是以硬件RAID卡的方式来实现的,保持对软件系统的透明与简化。这里也不做过多的讨论。

云端存储

卡录和NVR存储有着成本低廉的优势,但是无法应对盗抢和损坏问题。犯罪分子发现有摄像头时一般就会第一时间去破坏摄像头,导致无法通过监控录像来提供线索抓捕犯罪分子。普通的存储卡在多次插拔和一定时间的写入后,特别容易损坏。云端存储的方式则不受这些影响。另外,数据存储到云端,还可以进行有效的分析和处理,提取出更有效的信息,提升追溯问题时的效率。比如视频通过结构化分析处理后,就可以很方便的去搜索人、车和物品信息,并能快速、准确的定位到具体的时间和地点。同时,这些数据还能同其他业务数据形成数据湖,实现协同的价值。云端的存储也分很多种类,适合视频文件存储的则是最常见的对象存储,最经典的就是AWS的S3服务。这里我们不去讨论高可用、高可靠、海量存储的S3服务如何实现的,只要知道它好用可靠就行。

把摄像头的实时视频数据上传到云端,有多种实现方式,下面是最重要的几个考虑因素

1)流式传输 vs. 切片文件

摄像头的视频流本身是流式的,但是一般的云存储都是对象存储,并不是一个无始无终的流式文件,必须要把流式的视频流切割成一个个的文件。通常可以把流式的文件切割后存储成特定的容器格式,比如MP4和TS。因为MP4文件的写入通常涉及到索引的处理,需要seek到文件头进行索引位置的更新操作,并不适合边传输边写入。TS则比较方便,无需索引位置的更新,不过TS文件的overhead相对mp4来说要高一些。

2)设备端直接上传 vs. 云端切片上传

虽然最终都需要对视频流进行切片,但是切片在设备上完成还是在服务器上完成,还是可以选择的。IPC设备上直接切片上传的好处是无需服务端处理,IPC设备侧完成所有的逻辑,缺点则是需要本地缓存一定量的数据,在切片没有缓存完成前,无法进行上传操作。如果切片在云端进行,那么就需要把码流推送到云端的服务器主机上(或者服务端主动去拉流),由这个服务器主机来对视频流进行切片和上传的云存储里。云端切片的方式能节省IPC设备端的缓存开销,IPC只需把流数据发送出来,就不用做任何其他事情了。

3) 云端Meta信息存储

视频录像的切片存储到云存储后,还需要对meta信息进行管理。由于这些数据是一系列的时间序列,可以用时序数据库进行存储。对于直接播放的场景,服务端可以根据请求的时间段动态拼成m3u8文件返回给终端进行播放。如果需要导出,也可以转封装。

4)数据的加密存储

如果是存储到云端,就会存在一些安全隐私问题。当然存储管理系统会提供很多的访问控制来保障安全,但是如果是第三方提供的云存储服务,你并不能保障别人不会触碰你的数据。常规的对数据进行保护的方式分两大类:信源加密信道加密,比如我们使用TLS的连接的传输数据就属于信道加密。因为视频录像数据的存储和消费是解耦的,信道加密肯定是Hop By Hop的方式进行,网络上虽然无法嗅探和篡改数据内容,但是Hop By Hop的中间节点拿到的数据却是明文的。要解决这个问题,就只能采用信源加密的方式,数据在传输前就进行加密处理,即使中间节点能拿到加密数据内容,那也因为没有秘钥而无法获得明文数据。

这里还要提到的一点就是对于视频文件加密,也有多种方式。一种是通用的加密方式,并不关心是什么文件格式;另外一种是保留容器格式的方式。两者的差别在于后者只加密音视频帧本身,从而保留容器格式,方便其它不需要真正解码的转换处理(比如转换协议和容器格式、提取Meta信息等)。

三. 最后

本文讨论了不同场景下的视频监控存储系统的设计问题,虽然没有太涉及具体的细节,但是主要核心的问题都有所提及。存储系统对于任何一个业务都是至关重要的,而视频数据的特性又带来特殊的挑战。随着智能化的重要性逐步提升,还会诞生面向视频分析和智能压缩的存储系统,我们拭目以待。

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇