文件格式:MP4
故障描述:
兩個損壞的視頻文件，一個為400多M，一個為1.3G左右。某晚會使用多機位進行錄制，數據通過攝像機采集后直接保存到存儲設備中，當天錄制了很多個文件，這兩個文件也在其中，但是最后發現其它文件均正常，這兩個文件無法播放！
故障分析：
直接播放文件，直接報錯,如下圖:

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

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

上圖：重新生成結構體

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

上圖：修復后的效果

轉載于:https://blog.51cto.com/chs163/2134727

總結

以上是生活随笔為你收集整理的某电视台晚会多机位特殊视频修复案例的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。