System.ArgumentOutOfRangeException: 索引和长度必须引用该字符串内的位置。 参数名: length 在 System.String.Substring(Int32 startIndex, Int32 length) 在 zhuanliShow.Bind() 一种基于大容量视音频电子证据存储与协同查阅方法技术_技高网

一种基于大容量视音频电子证据存储与协同查阅方法技术

技术编号:40558451 阅读:7 留言:0更新日期:2024-03-05 19:20
本发明专利技术涉及电子证据存储及查阅技术领域,具体为一种基于大容量视音频电子证据存储与协同查阅方法,包括以下步骤:前端使用VUE2.0构建用户界面,使用WebUploader组件提供文件上传功能,然后使用xgplayer提供在线播放MP4视频。本发明专利技术在证据移送方面,依托本技术,证据通过平台上传,网路流转,不受日夜限制,全流程零次跑,平均每个案件节约1‑2个工作日;在证据保管方面,依托本技术支持,电子证据在线保存,通过案件码、校验值保证其前后安全、完整、一致,全流程使用无损坏、保管等风险;在证据审查方面,依托本技术,实现视频在线播放审查、无需光盘等介质,提升工作效率;在证据示证方面,依托本技术,实现与法庭示证系统结合,提升庭审效率。

【技术实现步骤摘要】

本专利技术涉及电子证据存储及查阅,具体为一种基于大容量视音频电子证据存储与协同查阅方法


技术介绍

1、现阶段电子证据格式主要分为视频、文件、图片和压缩包等格式,电子证据的大小根据所涉及的内容而定,其大小可达几十gb甚至上百gb,缺乏对大容量电子证据的长久有效防篡改保存,和在线查阅电子证据方式。此外,电子证据材料通过光盘形式线下移送,效率较低。

2、阶段由于电子证据文件过大主要有两种方式存储,一、利用光盘和移动硬盘保存移送;二、采用ftp上传至服务器保存流转。

3、对于大文件电子证据采用光盘,在证据移送方面,存有大容量数字证据的光盘等介质需要当面移送下一单位,全流程至少跑2次或更多次;在证据保管方面,一来存储空间受限,二来光盘介质在各环节的使用存在损坏、保管等风险,受存放环境影响较大,不易于长久有效保存,如果通过移动硬盘则无法最大化利用其存储空间。若采用ftp上传至服务器,用户端需要ftp客户端软件,而且电子证据无法进行完整性原始性校验,也不利于在线查看,影响审查和示证效率和效果;在证据审查方面,视频证据审查播放时,每次需要光盘等介质插入,且无法快速定位上次审查确定的关键点;在证据示证方面,音视频等证据庭审示证时,需要配套播放设备和光盘等介质,配套使用操作较为复杂。


技术实现思路

1、本专利技术的目的在于提供一种基于大容量视音频电子证据存储与协同查阅方法,以解决上述
技术介绍
中提出的问题。

2、为实现上述目的,本专利技术提供如下技术方案:

<p>3、一种基于大容量视音频电子证据存储与协同查阅方法,包括以下步骤:

4、步骤一:前端使用vue2.0构建用户界面,使用webuploader组件提供文件上传功能,并且支持电子证据断点续传、暂停、继续、取消功能,然后使用xgplayer提供在线播放mp4视频,且支持视频倍数、打点功能;

5、步骤二:后端采用java语言使用springboot框架,提供rest api服务;

6、步骤三:确定需要上传的电子证据;

7、步骤四:前端通过上传组件获取电子证据基本信息,按照系统配置分块大小和电子证据大小,计算总共需要分块计算md5数;

8、步骤五:使用html5的filereader接口按md5分块大小按序以字节形式读取电子证据内容,结果用arraybuffer对象表示,读取的分块利用spark-md5进行md5计算;

9、步骤六:根据当前计算md5值分块数量计算当前md5值进度情况;

10、步骤七:在电子证据整体md5计算完成后,前端触发上传电子证据事件,向后端传入计算后的md5值,获取已上传该电子证据的分片列表;

11、步骤八:服务端根据传入的md5值查询数据库查询该电子证据已上传的临时分片编号,并返回给前端;

12、步骤九:前端将电子证据按系统配置的分片大小从1开始编号,根据后台返回的已上传分片列表,将未分片的分片数据按编号作为文件名通过多线程传输到后台,并根据当前上传的数量计算上传进度和上传速度;

13、步骤十:服务端接收前端上传的分片,并判断是否上传电子证据的分片,如果还未上传过该电子证据的分片的话,则以该电子证据的md5值在存储服务器创建电子证据的临时文件夹,并将上传的文件夹存储在该临时目录下,如果已上传则直接存储分片即可;

14、步骤十一:当前端上传完成所有的分片数据,向服务端发起合并分片请求;

15、步骤十二:服务端处理前端发起的合并请求,校验上传电子证据数量是否正确,若不正确则返回上传失败,若数量正确则处理合并请求,将临时分片文件按文件名编号按序合并成最终电子证据,当后端合并完成后,将电子证据信息存入数据库中;

16、步骤十三:前端定时查询数据合并情况,如果合并完成,则刷新前端界面;

17、步骤十四:服务端定时对上传且在服务端未计算md5值的电子证据进行服务端md5计算,并校验服务端和前端md5值是否相同,如果相同则表示电子证据完整,且未被篡改;

18、步骤十五:服务端对存入数据库的电子证据按格式类型进行异步转码和解压处理;

19、步骤十六:服务端对视频格式电子证据利用ffmpeg进行异步转码成mp4格式,其中视频编码采用h264编码,音频编码采用aac编码;

20、步骤十七:当用户需要在线播放视频时,前端利用xgplayer组件加载转码后的mp4视频,也可以直接下载原电子证据查看;

21、步骤十八:服务端针对压缩包格式电子证据利用apache commons compress进行异步解压,解压生成文件目录在原电子证据同级目录下并以uuid命名文件夹名称;

22、步骤十九:当用户需要访问相关压缩文件时候可直接在线查看压缩文件即可,也可以下载原电子证据查看。

23、优选的,所述xgplayer为带解析器、节省流量的html5视频播放器。

24、优选的,所述rest api服务是基于http协议和一组简洁原则的软件架构风格和通信协议。

25、优选的,所述步骤十六中,支持转码格式avi、mpg、wmv、mov、asf、flv、mkv、nsf格式。

26、优选的,所述spark-md5计算步骤如下:

27、s1:填充原始消息,使其长度对512bits取余为448bits;

28、s2:将第一步填充后的消息和64位表示原始消息长度的数拼接到一起,形成一个新的消息,新的消息被划分为若干个512bits的分组,每个分组进行额外运算得到128位的输出;

29、s3:对每个分组进行一系列转换操作,逐个更新状态(128位矢量),最终生成最终状态的输出;

30、s4:将第三步得到的128位的十六进制数转化为32位的字符串,即为md5值。

31、与现有技术相比,本专利技术的有益效果是:

32、该基于大容量视音频电子证据存储与协同查阅方法,基于浏览器采用先对电子证据采用spark-md5进行md5计算,然后从服务端获取分片上传情况,对未上传的文件分片采用多线程进行上传,所有分片都上传完成后进行md5校验保证电子证据上传的完整性。上传完成后,服务器端对于不同格式的电子证据进行异步处理且不修改原电子证据,例如视频利用ffmpeg进行转码成mp4支持在线播放,以及原视频下载,压缩包利用apache commonscompress支持tar、zip、7z进行在线解压并支持在线查看,以及原压缩包下载,在证据移送方面,依托本技术,证据通过平台上传,网路流转,不受日夜限制,全流程零次跑,平均每个案件节约1-2个工作日;在证据保管方面,依托本技术支持,电子证据在线保存,通过案件码、校验值保证其前后安全、完整、一致,全流程使用无损坏、保管等风险;在证据审查方面,依托本技术,实现视频在线播放审查、无需光盘等介质,提升工作效率;在证据示证方面本文档来自技高网...

【技术保护点】

1.一种基于大容量视音频电子证据存储与协同查阅方法,其特征在于,包括以下步骤:

2.根据权利要求1所述的基于大容量视音频电子证据存储与协同查阅方法,其特征在于:所述xgplayer为带解析器、节省流量的HTML5视频播放器。

3.根据权利要求1所述的基于大容量视音频电子证据存储与协同查阅方法,其特征在于:所述REST API服务是基于HTTP协议和一组简洁原则的软件架构风格和通信协议。

4.根据权利要求1所述的基于大容量视音频电子证据存储与协同查阅方法,其特征在于:所述步骤十六中,支持转码格式avi、mpg、wmv、mov、asf、flv、mkv、nsf格式。

5.根据权利要求1所述的基于大容量视音频电子证据存储与协同查阅方法,其特征在于:所述Spark-md5计算步骤如下:

【技术特征摘要】

1.一种基于大容量视音频电子证据存储与协同查阅方法,其特征在于,包括以下步骤:

2.根据权利要求1所述的基于大容量视音频电子证据存储与协同查阅方法,其特征在于:所述xgplayer为带解析器、节省流量的html5视频播放器。

3.根据权利要求1所述的基于大容量视音频电子证据存储与协同查阅方法,其特征在于:所述rest api服务是基于htt...

【专利技术属性】
技术研发人员:傅晓峰徐清莫林凡姚志恒孙云涛
申请(专利权)人:杭州云杉信息科技有限公司
类型:发明
国别省市:

相关技术
    暂无相关专利
网友询问留言 已有0条评论
  • 还没有人留言评论。发表了对其他浏览者有用的留言会获得科技券。

1