文件格式:MP4
故障描述:
兩個損壞的視頻文件，一個爲400多M，一個爲1.3G左右。某晚會使用多機位進行錄製，數據通過攝像機採集後直接保存到存儲設備中，當天錄製了很多個文件，這兩個文件也在其中，但是最後發現其它文件均正常，這兩個文件無法播放！
故障分析：
直接播放文件，直接報錯,如下圖:
看這個報錯信息，播放器連編碼都解析不了直接成了不可識別文件，估計是文件結構體沒有封裝完畢，而視頻、音頻的編碼是保存在文件結構體中的，在WINHEX中查看文件後證明了之前的猜測！
讓客戶提供樣本文件進行分析，分析後發現這種視頻和普通攝像機的結構有很大差異。
視頻格式比較常見，但是音頻卻使用了非高清且是壓縮率較高的編碼，一般來說這種現場錄製的音頻多偏向於使用高清方案，很顯然這個是個例外（這也是爲何文件容量如此小的原因，壓縮率高了，佔的空間自然少了）；視頻竟然沒有使用統一的邏輯長度值，而是使用動態邏輯長度VBR（注：這個邏輯長度並非原始幀長度，雖然原始長度本就是動態的，但在視頻的邏輯層如時間軸一般是使用VBE靜態長度的方案），這個讓人比較疑惑，因爲邏輯長度VBR從文件結構來講是允許的但是卻會增加解碼時的開銷（解一幀就要獲取一幀的邏輯長度）。這個奇葩的方案讓人很困惑，後來我仔細想，可能是這些攝像機僅僅是負責採集，並沒有打包封裝文件結構的功能，這些工作最後是交給那臺存儲設備來完成，從這一點講那臺存儲設備是參與了打包封裝工作的，一邊收集採集信息，一邊打包，所以邏輯長度最後全部採用了動態方案這可能是唯一合理的解釋！
修復方案：
這方面不多說，CHS數據實驗室早就有成熟的視頻修復方案，而且開發出了程序，直接讓程序搞定結構體部分！這部分比較麻煩的就是音頻塊的確認，由於壓縮率極高而且沒有很明顯的規律所以要不斷調節程序，把一大堆音頻HEX值分揀成一條一條的有序音頻，所以這兒消耗了不少時間，當然最後的效果是極其完美的！
上圖：重新生成結構體
搞定音頻後，比較棘手的就是視頻的邏輯長度VBR了，前邊說過想要把視頻塊物理長度和邏輯長度對應是極其困難的，這個估計只有打包程序自己知道（採集指令是其發出，所以控制時長對它來說是很簡單的事兒），經過艱難的處理，最終成功解決這個問題！
上圖：修復後的效果