全站搜索
自定内容

文章正文
某电视台晚会多机位特殊视频修复案例
作者:管理员    发布于:2018-07-01 05:54:24    文字:【】【】【
摘要:文件格式:MP4 故障描述: 两个损坏的视频文件,一个为400多M,一个为1.3G左右。某晚会使用多机位进行录制,数据通过摄像机采集后直接保存到存储设备中,当天录制了很多个文件,这两个文件也在其中,但是最后发现其它文件均正常,这两个文件无法播放!

文件格式:MP4

故障描述:

两个损坏的视频文件,一个为400M,一个为1.3G左右。某晚会使用多机位进行录制,数据通过摄像机采集后直接保存到存储设备中,当天录制了很多个文件,这两个文件也在其中,但是最后发现其它文件均正常,这两个文件无法播放!

故障分析:

直接播放文件,直接报错,如下图:

看这个报错信息,播放器连编码都解析不了直接成了不可识别文件,估计是文件结构体没有封装完毕,而视频、音频的编码是保存在文件结构体中的,在WINHEX中查看文件后证明了之前的猜测!

让客户提供样本文件进行分析,分析后发现这种视频和普通摄像机的结构有很大差异。

视频格式比较常见,但是音频却使用了非高清且是压缩率较高的编码,一般来说这种现场录制的音频多偏向于使用高清方案,很显然这个是个例外(这也是为何文件容量如此小的原因,压缩率高了,占的空间自然少了);视频竟然没有使用统一的逻辑长度值,而是使用动态逻辑长度VBR(注:这个逻辑长度并非原始帧长度,虽然原始长度本就是动态的,但在视频的逻辑层如时间轴一般是使用VBE静态长度的方案),这个让人比较疑惑,因为逻辑长度VBR从文件结构来讲是允许的但是却会增加解码时的开销(解一帧就要获取一帧的逻辑长度)。这个奇葩的方案让人很困惑,后来我仔细想,可能是这些摄像机仅仅是负责采集,并没有打包封装文件结构的功能,这些工作最后是交给那台存储设备来完成,从这一点讲那台存储设备是参与了打包封装工作的,一边收集采集信息,一边打包,所以逻辑长度最后全部采用了动态方案这可能是唯一合理的解释!

 

修复方案:

这方面不多说,CHS数据实验室早就有成熟的视频修复方案,而且开发出了程序,直接让程序搞定结构体部分!这部分比较麻烦的就是音频块的确认,由于压缩率极高而且没有很明显的规律所以要不断调节程序,把一大堆音频HEX值分拣成一条一条的有序音频,所以这儿消耗了不少时间,当然最后的效果是极其完美的!

上图:重新生成结构体

 

搞定音频后,比较棘手的就是视频的逻辑长度VBR了,前边说过想要把视频块物理长度和逻辑长度对应是极其困难的,这个估计只有打包程序自己知道(采集指令是其发出,所以控制时长对它来说是很简单的事儿),经过艰难的处理,最终成功解决这个问题!

 

 

 

上图:修复后的效果

脚注信息
 晋ICP备12008728号-1   客服邮箱:cpx-cym@163.com  客服QQ1:490476236   客服QQ2:908138976
51客服