文件格式:MP4
故障描述:
兩個(gè)損壞的視頻文件，一個(gè)為400多M，一個(gè)為1.3G左右。某晚會(huì)使用多機(jī)位進(jìn)行錄制，數(shù)據(jù)通過攝像機(jī)采集后直接保存到存儲(chǔ)設(shè)備中，當(dāng)天錄制了很多個(gè)文件，這兩個(gè)文件也在其中，但是最后發(fā)現(xiàn)其它文件均正常，這兩個(gè)文件無法播放！
故障分析：
直接播放文件，直接報(bào)錯(cuò),如下圖:

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

修復(fù)方案：
這方面不多說，CHS數(shù)據(jù)實(shí)驗(yàn)室早就有成熟的視頻修復(fù)方案，而且開發(fā)出了程序，直接讓程序搞定結(jié)構(gòu)體部分！這部分比較麻煩的就是音頻塊的確認(rèn)，由于壓縮率極高而且沒有很明顯的規(guī)律所以要不斷調(diào)節(jié)程序，把一大堆音頻HEX值分揀成一條一條的有序音頻，所以這兒消耗了不少時(shí)間，當(dāng)然最后的效果是極其完美的！

上圖：重新生成結(jié)構(gòu)體

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

上圖：修復(fù)后的效果

轉(zhuǎn)載于:https://blog.51cto.com/chs163/2134727

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。