服务器后端之视频数据接收与转发搭建解决方案Word格式文档下载.docx

上传人:b****5 文档编号:19525028 上传时间:2023-01-07 格式:DOCX 页数:23 大小:657.86KB
下载 相关 举报
服务器后端之视频数据接收与转发搭建解决方案Word格式文档下载.docx_第1页
第1页 / 共23页
服务器后端之视频数据接收与转发搭建解决方案Word格式文档下载.docx_第2页
第2页 / 共23页
服务器后端之视频数据接收与转发搭建解决方案Word格式文档下载.docx_第3页
第3页 / 共23页
服务器后端之视频数据接收与转发搭建解决方案Word格式文档下载.docx_第4页
第4页 / 共23页
服务器后端之视频数据接收与转发搭建解决方案Word格式文档下载.docx_第5页
第5页 / 共23页
点击查看更多>>
下载资源
资源描述

服务器后端之视频数据接收与转发搭建解决方案Word格式文档下载.docx

《服务器后端之视频数据接收与转发搭建解决方案Word格式文档下载.docx》由会员分享,可在线阅读,更多相关《服务器后端之视频数据接收与转发搭建解决方案Word格式文档下载.docx(23页珍藏版)》请在冰豆网上搜索。

服务器后端之视频数据接收与转发搭建解决方案Word格式文档下载.docx

数据传输是远端用户对视频文件有目的的检索后通过视频存储服务器的流媒体服务功能完成的,因此,后端视频处理的主要过程可以描述为如图3.2。

图3.2后端视频处理主要过程

从图3.2中可以看出,从网络中接收到前端传送过来的视频流后,视频存储服务器将其解码成RGB视频;

再将解码后的视频进行压缩,变成适合存储的数据格式,然后按照存储文件的组织策略将这些数据进行规范,完成后将数据存入硬盘;

用户可以根据自己的需要对存储的数据文件进行查找与回放,远程用户查找到的视频文件也能够以流媒体的形式通过网络传送至用户机,完成远程监控。

3.2视频存储服务器的结构

所设计的视频存储服务器要完成的主要功能是将前端传送过来的视频信号解码还原成RGB视频,并进行编码压缩,然后按照存储策略存入存储设备,用户根据自己的需要对存储设备中的视频数据进行检索与播放。

设计中对视频存储服务器功能划分为5个功能模块,得到其功能结构如图3.3所示。

图3.3视频存储服务器的主要功能构成

各模块的功能定义如下:

1)视频解码模块:

主要负责对系统前端通过网络传送来的压缩视频信号进行解压缩,还原成原始的RGB视频数据。

2)存储管理模块:

负责对解码后的RGB视频数据进行压缩,然后以制定的文件组织规范将压缩后的数据存放到存储设备上。

在数据存储时要求数据占用的空间尽量要小,同时要便于对视频文件进行检索回放。

3)检索回放模块:

为用户提供视频录像资源的快速检索接口,用户可以根据需要对视频文件进行检索调用。

当用户查找到所需要的文件时,将相应的文件从硬盘上读出,并将这些数据与相应的控制信息封装成支持既定协议的信息帧,通过网络通道传送到用户,供用户回放浏览。

4)日志管理模块:

主要是记录系统工作时间内的一些重要操作及事件信息,管理用户能够通过管理日志了解系统的工作情况和用户访问情况。

5)系统管理模块:

负责系统的初始化工作,主要完成对系统的参数配置、用户权限管理、设备信息管理、用户请求处理等。

3.3视频存储服务器核心模块设计

3.3.1解码模块的设计

系统前端编码器所采用的编码标准是H.264编码标准,因此,系统的解码模块同样采用H.264标准。

依照H.264标准,整个流程分为5个步骤:

帧间和帧内预测(Estimation)、变换(Transform)和反变换、量化(Quantization)和反量化、环路滤波(LoopFilter)、熵编码(EntropyCoding)。

在设计中按照各部分功能对解码器进行了设计,其功能框图如图3.4所示。

图3.4H.264解码器功能框图

从图3.4可以看出,解码器的基本流程设计为:

解码器从NAL中接收压缩的比特流,经过对码流进行熵解码获得一系列量化系数X;

这些系数经过反量化和反变换得到残差数据D;

解码器使用从码流中解码得到的头信息创建一个预测块PRED,PRED与残差数据D求和得到图像块数据uF;

最后每个uF通过去块滤波得到重建图像的解码块F。

监控系统的视频是由连续的图像帧组成的。

因此,某种意义上说视频解码就是对视频的图像帧进行解码,解码程序对视频段的解码也可以说是主程序反复调用帧解码函数的过程。

单帧图像的解码流程如图3.5所示。

图3.5解码器解码一帧图像过程

一帧图像经过视频编码层VCL编解码后产生的码流,在NAL中将这些码流分割成NAL单元,并对NAL单元进行边界检测,之后对各单元进行去块滤波处理,并在参考图像进行存储处理后重建图像帧;

NAL单元解码过程包含了不同类型片的解码,而对各类型的片解码首先从码流中读入一个片的编码数据,提取RBSP语法结构,产生宏块片组映射图,并根据当前图像类型对参考图像列表进行初始化,最后完成片的解码;

而进行片解码首先要对参考图像序号数据以及当前宏块解码设置进行初始化。

然后从NAL中读入当前宏块的语法元素,以便对宏块进行解码。

3.3.2存储模块设计

视频监控系统产生的视频流数据是海量的,这些海量的视频数据文件对系统的存储系统提出了严峻的考验。

为了制定一个合理的存储方案,本文对监控存储方案与以往存储方案进行了比较,结果如表3.1所示。

表3.1监控存储与传统存储文件特性比较

项目

以往存储

监控存储

数据库表

文本/图像

图像/音频

数据表现形

结构化(有序,可用

统一结构表示)

非结构化(无序、无

法用统一结构表示)

非结构化(无序、无法用统一结构表示)

数据组织方式

非结构化(无序,规

则性不强)

结构化(有序,规则性很强)

数据保存时间

无序,时长不定

有序,定期删除更新

数据更新方式

无序,方式不定

有序,从尾部顺序增加

数据读写方式

无序,反复多次读写

有序,一次写少量读/不读

存储块大小

8-64KB

512B-1MB

64KB-1MB(512Kb-8Mb)

性能要求

IOPS

IOPS、带宽

多路并发的带宽

存储热点

2/8原则,20%的数据承载80%的访问

均衡原则,数据访问的机会均等

数据重要度

重要,数据价值高

不定

大部分是无用数据

从表2中可以看出,监控存储虽然数据的表现形式和以往的图像存储一样,体现出无规则的非结构化特征,但是在组织方式上是结构化的,具有很强的规则性,这是其最大的特点,也是和传统存储模型不一样的地方。

鉴于监控视频体现出的非结构化的表现形式和结构化的组织方式,以及其在保存时间、读写方式和更新方式上的有序性,本文考虑从监控视频的自身特点出发,利用视频编码技术消除其数据上的冗余,减少无用数据占用存储空间,并充分利用监控视频数据的有序性特征将数据进行规范的组织,实现有序存储,便于对存储设备的均衡访问和对数据的管理,为录像文件检索与回放提供一种快捷有效的方式。

基于上述的思路,课题从视频压缩、文件组织和存储管理三个方面对系统的存储

模块进行设计。

1)监控视频的压缩编码

数据压缩是解决存储问题最基础最有效的的方法之一。

视频监控系统的海量数据的存储光靠硬件设备支持是远远不够的,所以必须对数据进行压缩处理,来减轻存储设备的负荷。

对数据进行压缩有三个方面的好处:

节省存储设备空间;

节省CPU处理时间;

节省数据的传输时间。

编码的主要任务是按照所设置的编码压缩参数来完成对这些视频的压缩编码。

编码参数主要包括编码器参数和图像编码参数。

其中编码器数数主要有源帧率、信道速率等;

图像编码参数主要有图像的格式、编码类型,是否允许非限制运动矢量模式等。

由此看来,对视频数据进行压缩是视频文件存储的一个重要环节。

课题中采用的是MPEG4压缩编码标准,因为MPEG4基于AV对象的压缩模式能够保证运动物体图像有比较高的图像质量,更适合于项目中其他任务对运动目标分析的要求。

根据MPEG4的编码原理,所设计的压缩编码框图如图3.6所示。

图3.6MPEG4的压缩编码框图

MPEG4编码器编码过程可以描述为:

当视频流输入到编码器,一方面编码器对视频进行场景分析和对象分割,划分为不同的VOP,将VOP进行形状编码,得到各个VOP的形状和位置信息,并用形状编码得到的信息来控制VOP的运动编码和纹理编码;

另一方面对宏块进行DCT变换和量化,量化后的宏块经过逆量化和反DCT变换,并将这些处理后的宏块进行运动编码,在运动编码过程中采用了运动预测/补偿法;

输入的VOP与帧存中的前一帧的VOP进行比较,得到当前块的运动矢量,然后对两帧VOP的差值进行DCT变换、量化和纹理编码,得到纹理信息,接着将得到的纹理信息与运动编码得到的运动信息以及形状编码得到的形状和位置信息进行合成,形成VOP的比特流。

分别对不同视频对象的VOP进行编码,得到不同的比特流,再经过视频多路合成,形成MPEG4视频流在信道上传输。

2)文件组织

文件组织结构设计的主要目的是为了便于系统对文件数据的存储和管理。

因此,本文对视频存储中的视频文件的命名规则和文件管理策略两个方面制定了可行的方案。

具体方案如下:

1)视频文件的命名规则:

考虑到在实际应用中,用户在查询录像文件时一般是按录像的时间、某个摄像机所在的通道以及录像性质为查找条件。

为此,课题中提出以“时间+通道+录像性质”作为录像文件的名称,其中时间是按年月日时分秒来记录的。

命名格式规范为图3.7所示。

图3.7文件名格式规范

操作中,可以按照录像的时间自动为录像文件生成文件名,在系统判断文件是否过期和用户对文件进行检索回放时,可以按照文件名来进行快速准确的操作。

2)文件管理策略:

用户会根据不同场所的不同要求对录像文件设定不同的保存期限,在文件过期后为被删除,留出更多的空间存储更多新的视频数据。

因此,录像文件的改变是相当频繁的,而且系统产生的视频数据量相当大,生成的文件更是一个天文数字。

为了实现对这些海量文件的高效管理,本文将硬盘进行分层管理,其管理模式如图3.8所示。

图3.8硬盘分层管理模式

从图3.8中可以看出,硬盘中为其他类型文件和视频文件分别划分了不同的区,而在视频文件中又为不同的通道的视频数据进行了划分,这种管理方式层次比较强,为海量数据的管理提供了有效的方案。

3)管理策略

在视频监控系统中,视频文件的存储是一个需要在系统设计中解决好的重要问题,也是衡量系统性能的一个重要指标。

存储管理策略要求有效可靠的存储、简单快捷的检索回放、合理高效的磁盘空间利用等,以满足用户不同的需求。

设计中需要系统中的存储管理能够完成以下四个主要方面的要求:

1)存储录像模式:

在视频监控系统中,在对文件存储录像的时候都是循环覆盖模式和线性提醒模式。

所谓循环覆盖模式(如图3.9所示),就是视频在存储过程中是按盘逐个进行的。

当所有磁盘空间都存储满时接下来的文件将自动覆盖最开始的文件。

所谓线性提醒模式(如图3.10所示)是指视频文件按磁盘逐个存储,当所有磁盘都存满时,系统提醒用户更换磁盘,这种模式要求存储设备具备热插拔功能。

图3.9循环覆盖模式

图3.10线性提醒模式

2)检索回放:

监控系统的检索回放功能要求在视频文件存储的时候要高效、有序地对文件进行组织,能够按录像通道、录像时间及文件的类型等做好分类存储,以便用户能够快速有效的在大量文件中检索到自己所需的录像记录,对图像文件处理。

3)灵活的存储规模:

系统可以根据用户的需求进行存储规模的调整,既可以以单磁盘作为系统的存储介质,也可以选择用多个硬盘或磁盘阵列作为存储介质,以适应不同规模的系统在不同现场的存储要求。

为了便于对存储盘的管理,课题将硬盘可以划分为存放系统文件和数据的系统盘和存放视频监控录像的数据盘两种。

实际操作中,对于单盘存储的小规模系统,将盘划分为这两种逻辑区;

对于多个盘的系统,可将一个盘划分为系统盘,剩余的盘则作为数据盘。

系统大量的视频数据存储在数据盘中,必需一个有效的控制模式来完成对数据盘的管理才能满足系统对存储性能的要求。

为了适应监控系统大量视频数据的存储需要,设计将硬盘所有扇区划分为几个区:

管理控制区、文件结构区、索引文件区、数据区和日志管理区。

数据区又划分为若干个数据块,数据块的大小可以自由设置,并通过结构信息和索引文件来管理数据块。

各区之间的关系可以用图3.11表示。

图3.11各区之间的关系

1)管理控制区的位置相对比较固定,主要用于存放当前磁盘和文件系统的基本信息,如每个区域的具体位置和大小、各分区的使用情况、下一条可用索引单元的位置、下一个可用数据块的位置等.

2)日志管理区可以由用户根据磁盘空间来自由设定大小,是专门用来存放日志文件的区域,完成对日志的管理工作。

3)文件结构区主要是用来描述录像文件的结构,存放的是录像文件的相关信息,如录像起止时间、对应的索引块位置等,其中的信息文件结构和大小比较固定,通过结构文件的信息就能得到对应的索引信息的准确位置。

4)索引信息区用于存放数据块的索引。

因为一个录像文件可能会包含多个数据块,所以将索引区分成索引块,而每个索引块存放与文件包含的数据块数目相同的索引信息单元,每个索引信息单元与数据块一一对应,而每个索引块则与一个录像文件关联。

5)数据区是其他四个区划分完后所有剩余空间。

将其划分为若干个块,大小自由设定,以块作为存储录像数据的最小单元来保存监控视频。

块的结构定义如图3.12所示。

图3.12块的结构定义

设计思想概括为:

将数据区划分为若干个小的数据块,大小可以由用户自由设置,采用这些底层的数据块作为基本存储单元,每个数据块在索引区都有一个对应的索引单元,记录数据块的位置;

当用户给定文件长度后,可以确定一个文件所包含的数据块的个数N,当存储的数据块达到N时,在索引区生成一个索引块,记录下该文件开始的数据块的索引单元位置和文件所包含的块数目;

在文件结构区建立一个结构信息文件,将索引块的位置和录像文件开始与结束的时间等信息。

这种模式实际上是将录像文件的“形式外壳”存放在文件结构区,而实际数据则以数据块的形式存储在数据区内,它们是通过索引块和索引单元建立的链表相互关联,形成一个个视频文件。

这种设计的优点在于数据是以数据块的形式存放的,当进行数据覆盖时,不像以往存储方式是以大颗粒的录像文件进行覆盖,而是进行数据块覆盖,所以能够减少磁盘碎片的产生。

由于结构信息和索引文件需要占用一定的磁盘空间,并且与数据块的总数密切相

关,块总数可以根据空间大小与数据块大小得到。

由于这类文件所点空间都很小,

因此结构信息和索引文件所占用的磁盘空间在整个磁盘中只占很小的比例。

3.3.3检索回放模块设计

文件系统的设计是为了对随机读写的数据进行管理。

在以往的监控系统中,视频录像以文件进行存储,在录像检索时首先要根据摄像头、检索的时间查找到相应的文件,然后再手动定位具体的时间点,再从该时间点回放录像。

检索过程中的最小单位是文件,颗粒度太大,精确度很低,检索效率也比较低,对于一个规模较大的监控系统来说,存储的视频文件数将以百万计,检索难度是非常大的。

设计中为方便用户对视频数据的检索,索引采用了分级设计,在索引文件区中建立索引块,与录像文件关联,记录录像文件的开始数据块的索引位置和文件所包含的索引单元的个数N,在索引块下又分N个索引单元,分别与文件所包含的数据块对应,通过索引块和索引单元中的信息构成一个链表,用户通过链表即可找到所需要的数据。

其中索引单元的结构如图3.13所示

图3.13索引单元结构

在方案中,在文件结构中结构信息文件是严格按照“时间+通道+录像类型”进行命名的,所以在进行视频检索时可以采用二分法快速查找到指定条件的文件结构信息,再根据结构信息中的索引块的信息,找到对应的索引块,因为索引块中给出了录像文件开始数据块的索引信息,在索引信息中又包含了下一个索引单元的位置,所以根据索引块和索引单元所建立的索引链表即可找到用户需要的录像数据块。

理论上,如果数据块设置恰当,利用这种检索模式可以准确定位到某一秒,甚至可以定位到某一帧图像,从而实现快速、精确的检索。

其步骤如图3.14所示。

图3.14录像文件检索步骤

整个搜索方案描述为:

首先读取用户所设置的检索条件,按照条件中的通道条件

找到通道相关的文件结构信息;

接着从搜索结果中找出与条件中录像性质一致的结

构信息;

然后从结果中找出包含所给时间条件的结构信息;

查找出满足用户条件的

结构信息后,再根据结构信息中的索引文件信息找出对应的索引文件,然后根据索

引单元的时间信息定位到与查找条件最匹配的索引单元,最后按照索引单元读取相

应数据块中的数据。

3.4本章小结

本章首先介绍了课题中视频监控系统的框架,从系统框架引入视频存储服务器,

并对其结构进行了分析,阐明了视频存储服务器各模块的功能,然后对各功能模块

提出了设计方案和思路,存储模块作为整个设计的重点,在本章中也对其进行了重

点阐明。

4视频存储服务器的实现

本章根据上一章的设计方案,介绍了视频存储服务器的实现,从编解码模块、视频录像存储模块和检索回放模块三个方面介绍了实现的具体过程。

4.1编解码模块的实现

4.1.1解码模块的实现

从解码器的框图中可以得知,解码器从网络提取层NAL中接收压缩位流,数据元素经过熵解码和重新排序后产生一组量化系数X。

利用从位流中解码的头信息调整这些系数,并经过反量化、反变换得到残差数据D,解码器创建的预测块PRED与D相加,得到一个重构的块uF,将uF经过滤波得到每个块的解码F[36]。

基于这种思路,本文从NAL单元解码、熵解码、参考帧列表的重排序、反变换和量化、帧间预测的解码处理和帧内预测的解码处理6个方面给出实现的过程。

1)NAL单元的解码过程

NAL单元解码的过程如图4.1所示。

图4.1NAL单元解码过程

首先从位流中获取NAL单元,从NAL单元的数据中提取RBSP语法结构,然后根据NAL单元的类型进行解码处理,其输入的是NAL单元,得到的解码后的当前图像(CurrPic)的样点值;

H.264规范文档中规定:

对同一码流,所有解码器必须产生数值上相同的结果,必须符合规范定义的解码过程标准。

在NAL单元的解码过程中,要将NAL单元数据转换成RBSP,程序中定义了函数NALUtoRBSP()完成此功能。

函数定义为:

2)熵解码

H.264支持两种熵编码方法:

上下文自适应的可变长编码(CAVLC)和内容自适应编码(CABAC)。

为了能够有效地传送量化的变换系数,CAVLC是一个比较有效的方法,而且在CAVLC方案中,对于各种语法元素的VLC码表按照已经传送的语法元素可以进行切换,改善了熵编码的性能。

CAVLC的解码过程是:

首先是初始化,依据所输入的参数得到块的类型,并输入数据的个数等相关参数。

然后求变量NC,并通过NC值来确定所要查找的表格,其中NA表示与当前块相邻的左边块中非零系数的个数,NB表示与当前块相邻的上面块中非零的个数。

以Coeff_token语法元素为入口函数,查表得到非零系数的个数TotalCoeffs、拖尾系数的个数TrailingOnes。

以TotalCoeffs为入口函数,查表可以得到TotalZero值。

通过函数readSymtaxElement_NumCoeffTrailingOnes()读入NumCoeff/TrailingOnes的码字。

3)参考帧列表的重排序重

排序的流程如图4.2所示

图4.2参考帧列表的重排序流程

参考帧列表的重排序主要是为了节省码流。

解码器根据片头码流中的相关语法元素,如ref_pic_list_reordering_flag_10、ref_pic_list_reordering_flag_11、reordering_of_pic_nums_dic、abs_diff_pic_num_minusl等的规定,进行列表的重排序。

参考图像的重排序信息由函数ref_pic_list_reordering()读入。

4)反变换和量化

与其他的视频编码标准相似,H.264标准采取的是预测残余变换编码。

但H.264变换是施加在4X4块上的,没用采用DCT变换,而是用与DCT类似特性的整数变换ICT,因而反变换没有误差。

直流亮度系数的反变换和量化由函数itrans_2(structimg_par*img)实现,函数voidcopyblock_sp(structimg_par*img,intblock_x,intblock_y)负责将反变换和量化的结果写入解码的亮度帧。

5)帧内预测的解码处理

在帧内预测中,当前编码的宏块上方和左方的宏块用于计算当前宏块的预测值。

当前宏块与其预测值的差值进一步编码,将其传到解码器。

在该比特流中包含了表示预测方式的相关比特和解码出的残差信号的比特,解码器利用这些相关的比特计算出当前宏块的预测值,并以这个预测值来恢复图像原始像素值。

在帧内预测中,宏块有4种预测方式:

4x4亮度块的帧内预测(Intra_4x4)、16x16亮度块的帧内预测(Intra_16x16)、8x8色度块的帧内预测(Intra_chroma),以及PCM的预测方式(I_PCM)。

每个块可选择四种方式其中之一进行帧内预测,所有的类型都支持两级帧内编码:

INTRA-4X4和INTRA-16X16。

前者分别预测每个4X4亮度块,比较适合于描述图像细节部分,而后者则是将整个16X16亮度块进行预测,比较适合于图像较平滑区域。

对这两种预测类型的色度则进行单独预测。

在程序中,帧内模式下4x4块的重构由函数intrapred()完成。

其定义如下:

6)帧间预测的解码处理

在解码端,P宏块和B宏块解码时需要进行帧间预测解码处理,处理后输出帧间预测像素矩阵,包括一个16X16的亮度矩阵PREDL和两个色度8X8矩阵:

PREDcr和PREDcb。

调用函数BType2CtxRef()来设置参考帧的上下文,该函数定义如下:

在亮度模块中,通过对相邻块的预测得到非零系数的数字。

此功能由函数predict_nnz(structimg_par*img,inti,intj)来完成。

4.1.2编码模块的实现

视频编码是一个反复对图像帧进行编码的过程。

本文将编码程序的分为三个步骤:

为编码器创建一个实例、反复调用编码函数对图像帧进行编码、销毁编码器。

为此定义了三个函数enc_

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 外语学习 > 其它语言学习

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1