松下p2卡MXF恢复过程与思路

太原某电视台松下机器拍摄的P2卡,误操作导致数据全部丢失,因为拍摄的节目需要播出,只能加班至此恢复数据,一般松下的格式化话或许删除之后数据直接清零的居多,客户运气还算较好,底层数据没被清除!

P2卡的音频以及视频是分别存储在不同目录的,但是在物理层面是连续存储在一个未分段的数据块内,因此统一对这些数据块进行提取,算是完成第一阶段的工作,然后,我们根据客户提供的样本进行了存储结构分析,发现存储有一定的存储规律,但是遗憾的是根据规律恢复的数据是失败的,因为提取出来的数据100%全部存在问题,出现花屏以及马赛克问题。因此进一对样本内的文件进行分析,根据mxf文件分析我们发现mxf的文件结构可以作为视频碎片提取的根据,但是这一方案提取恢复出来的视频均为小碎片,但是无奈客户对视频完整度要求极高这样的小碎片是无法满足需求的,因此放弃这一方案。

通过对mxf的音频以及视频的分析,由于视频和音频采用编码方式不同,音频采用的G711A编码,因此这给分离视频以及音频创造了可能,我们将视频进行32KB的簇大小切块,并且采用信息熵算法将数据块进行取值运算。

通过信息熵的算法,我们获取到了音频以及视频的存储边界信息,但是发现,部分音频信息量巨大,无法和视频明确分离,导致组合出来的碎片大概有30%左右的视频是会花屏的,因此我们根据G711编码特征,加入第二种统计算法,根据信息熵以及统计值进行二次运算,获取了更加准确的边界信息,将准确率提高到95%以上,另外5%由人工完成。

然后写个组合程序对生成的边界文件进行视频以及音频的分离提取,顺利完成整个工作。

恢复客户需要的音视频文件,46.9GB

视频文件播放无问题,完整度100%。

甲驭数据恢复中心:www.uuhf.net    研发产品站:www.sysfix.cn

时间: 2024-10-28 20:27:42

松下p2卡MXF恢复过程与思路的相关文章

raid-6磁盘阵列损坏导致数据丢失的恢复过程(图文教程)

一.故障描述机房突然断电导致整个存储瘫痪,加电后存储依然无法使用.经过用户方工程师诊断后认为是断电导致存储阵列损坏.整个存储是由12块日立硬盘(3T SAS硬盘)组成的RAID-6磁盘阵列,被分成一个卷,分配给几台Vmware的ESXI主机做共享存储.整个卷中存放了大量的Windows虚拟机,虚拟机基本都是模板创建的,因此系统盘都统一为160G.数据盘大小不确定,并且数据盘都是精简模式. 二.备份数据将故障存储的所有磁盘和备份sss数据的目标磁盘连入到一台Windows Server 2008的

mysqldunp增量恢复过程及详解

Mysql增量恢复必备条件 1.开启mysql log-bin日志功能 MySQL数据库开启了log-bin 参数记录binlog日志功能下: 小结:增量恢复的条件: 存在一份全备加上全备之后的时刻到出问题时刻的所有增量binlog文件备份. 创建模拟环境 [[email protected] 3306]# grep log-bin /data/3306/my.cnf log-bin = /data/3306/mysql-bin [[email protected] 3306]# mkdir -

Ubuntu 14.04 安装nVidia驱动后不能进入图形界面的恢复过程

想要解决Ubuntu14.04的风扇不停的转的问题.由于ubuntu本身不支持双显卡切换,导致集显独显都处于开启状态,发热量和耗电量居高不下. 1. 安装驱动过程 参考[1]中的步骤,做了如下的操作. (1)首先用管理员权限更改/etc/modprobe.d/blacklist.conf,把开源的 Nouveau 驱动加入黑名单. gedit /etc/modprobe.d/blacklist.conf 在文件末尾加上blacklist nouveau (2)安装驱动和Prime apt-get

一次心惊肉跳的服务器误删文件的恢复过程

经历了两天不懈努力,终于恢复了一次误操作删除的生产服务器数据.对本次事故过程和解决办法记录在此,警醒自己,也提示别人莫犯此错.也希望遇到问题的朋友能找到一丝灵感解决问题. 事故背景 安排一个妹子在一台生产服务器上安装Oracle,妹子边研究边安装,感觉装的不对,准备卸载重新安装.从网上找到卸载方法,其中要执行一行命令删除Oracle的安装目录,命令如下: rm -rf $ORACLE_BASE/* 如果ORACLE_BASE这个变量没有赋值,那命令就变成了 rm -rf /* ==||,妹子使用

MySQL崩溃恢复过程常见错误分析

最近在和一个同事争论MySQL崩溃恢复中的一些常见错误时出现了一些分歧,他认为一些参数的设置会导致MySQL出现崩溃后恢复不起来的问题,但对此,我却不认同,虽然一些参数的设定会导致数据丢失,但应该不会引起数据库崩溃之后无法恢复的情况,因此,就想整理出MySQL崩溃恢复的过程来加深学习! 图一 mysql WAL过程 在正常情况下,数据写入会先写入redo_buffer_pool,然后在写入redo_log_file,这中间如果由于参数设置不当,可能会发生丢失,但不影响主机的崩溃恢复,但有以下两种

记录SQL Server2008日志文件损坏的恢复过程

记录SQL Server2008日志文件损坏的恢复过程: 环境:系统Windows Server2003 数据库SQL Server2008 故障原因:通过mstsc链接同一服务器时,用户界面不一致.决定重启服务器,未正确关闭应用程序的情况下(程序在访问数据库),导致数据库日志文件损坏,自然也就无法访问mdf文件!(都是微软自家的产品,重启服务器为什么不能检查数据库的状态,将数据库设置在安全状态后在重启呢??所以,要养成良好的习惯.关闭现有数据库链接,再重启服务器) 故障表现:无法访问数据文件,

SQL Server 恢复过程

在恢复过程中.只会分析那些自最后一个检查点之后发生的更改,以确定是否需要重做还是撤销. 在最后一个检查点之前完成的操作都会精确的反应到数据文件中,恢复过程不需要做其它的事. 第一阶段: 分析. 这个阶段构造脏页表.也会构造包涵未提交的活动事务表. 第二阶段: 重做. 从最早打开的活动事务开始.这样可以获得必要的锁. 第三阶段: 回滚. 在sql server 停止时任何没有提交的事务都会被撤销. --------------------------------------------------

MySQL数据库恢复过程

MySQL数据库恢复过程 某客户更新数据的时候,误删了数据库的内容,因为数据库做了主从,但是没有做备份(备份很重要啊!)幸好开启了bin-log.之后只好把整个日志的记录拿回来本地进行恢复.之后自己也做了一个简单的测试,对数据进行恢复,具体如下: binlog是什么? binlog日志用于记录所有更新且提交了数据或者已经潜在更新提交了数据(例如,没有匹配任何行的一个DELETE)的所有语句.语句以"事件"的形式保存,它描述数据更改 1.新建一个表 CREATE TABLE `lynn`

MySQL · 引擎特性 · InnoDB 崩溃恢复过程

MySQL · 引擎特性 · InnoDB 崩溃恢复过程 在前面两期月报中,我们详细介绍了 InnoDB redo log 和 undo log 的相关知识,本文将介绍 InnoDB 在崩溃恢复时的主要流程. 本文代码分析基于 MySQL 5.7.7-RC 版本,函数入口为 innobase_start_or_create_for_mysql,这是一个非常冗长的函数,本文只涉及和崩溃恢复相关的代码. 在阅读本文前,强烈建议翻阅我们之前的两期月报:1. MySQL · 引擎特性 · InnoDB