看這個報錯信息，播放器連編碼都解析不了直接成了不可識別文件，估計是文件結構體沒有封裝完畢，而視頻、音頻的編碼是保存在文件結構體中的，在WINHEX中查看文件後證明了之前的猜測！
讓客戶提供樣本文件進行分析，分析後發現這種視頻和普通攝像機的結構有很大差異。
視頻格式比較常見，但是音頻卻使用了非高清且是壓縮率較高的編碼，一般來說這種現場錄制的音頻多偏向於使用高清方案，很顯然這個是個例外（這也是為何文件容量如此小的原因，壓縮率高了，占的空間自然少了）；視頻竟然沒有使用統一的邏輯長度值，而是使用動態邏輯長度VBR（註：這個邏輯長度並非原始幀長度，雖然原始長度本就是動態的，但在視頻的邏輯層如時間軸一般是使用VBE靜態長度的方案），這個讓人比較疑惑，因為邏輯長度VBR從文件結構來講是允許的但是卻會增加解碼時的開銷（解一幀就要獲取一幀的邏輯長度）。這個奇葩的方案讓人很困惑，後來我仔細想，可能是這些攝像機僅僅是負責采集，並沒有打包封裝文件結構的功能，這些工作最後是交給那臺存儲設備來完成，從這一點講那臺存儲設備是參與了打包封裝工作的，一邊收集采集信息，一邊打包，所以邏輯長度最後全部采用了動態方案這可能是唯一合理的解釋！

修復方案：
這方面不多說，CHS數據實驗室早就有成熟的視頻修復方案，而且開發出了程序，直接讓程序搞定結構體部分！這部分比較麻煩的就是音頻塊的確認，由於壓縮率極高而且沒有很明顯的規律所以要不斷調節程序，把一大堆音頻HEX值分揀成一條一條的有序音頻，所以這兒消耗了不少時間，當然最後的效果是極其完美的！

上圖：重新生成結構體

搞定音頻後，比較棘手的就是視頻的邏輯長度VBR了，前邊說過想要把視頻塊物理長度和邏輯長度對應是極其困難的，這個估計只有打包程序自己知道（采集指令是其發出，所以控制時長對它來說是很簡單的事兒），經過艱難的處理，最終成功解決這個問題！

上圖：修復後的效果

某電視臺晚會多機位特殊視頻修復案例