最近用javaCV的ffmpeg包的FFmpegFrameGrabber幀捕捉器對捕捉到的音頻幀和視頻幀做了同步的播放。采用的同步方法是視頻向音頻同步。

程序和源碼

具體的思路如下：

(1)首先介紹ffmpeg是如何捕捉視頻文件的圖像和聲音的

FFmpegFrameGrabber fg = new FFmpegFrameGrabber("a video file path or a url); 

得到幀捕捉器對象后，調用它的grab()方法就會返回捕捉到的Frame對象。這個Frame可以是視頻幀或者是音頻幀，這是因為音視頻幀時按照時間戳在播放時間先上排列的。當然捕捉到的幀都是已經(jīng)譯碼過的，并且存儲在java.nio.Buffer對象中，對于視頻幀，Buffer是儲存圖像的像素數(shù)據(jù)比如RGB，然后通過

BufferedImage bi = (new Java2DFrameConverter()).getBufferedImage(f); 

就可以得到圖片，得到的圖片可以進行一系列的處理或者不處理直接顯示在swing組件上。對應音頻幀，Buffer是儲存音頻的PCM數(shù)據(jù)，這個PCM可以是float或者short的，然后用java.sounds.sample里面的sourceDataLine.write方法就可以將這些音頻PCM數(shù)據(jù)寫入到揚聲器中。

(2)接著介紹如何不斷得將得到的幀播放出來。首先是單獨播放視頻:

while(true) 
{ 
  Frame f = fg.grab();  
  if(f.image!=null) 
  label.setIcon(new ImageIcon((new Java2DFrameConverter()).getBufferedImage(f))); 
  Thread.sleep(1000/視頻幀率);  
} 

單獨播放音頻同理，將數(shù)據(jù)寫入到聲卡即可。例子

(3)生產(chǎn)消費者模式。

上圖是程序實現(xiàn)的方法，采用生產(chǎn)者模式將捕獲到的幀進行判斷，如果是視頻幀就生產(chǎn)到視頻FIFO中，如果是音頻幀就生產(chǎn)到音頻FIFO中，然后音頻播放線程和視頻播放線程分別從各自的幀倉庫消費里面的幀。之所以采用生產(chǎn)消費者模式是因為幀捕獲的速度是大于幀的消耗的，所以我們優(yōu)先捕獲幀來緩沖，或者進一步對捕獲的幀進行預處理，而視頻和音頻播放線程只需要將處理過的幀直接播放顯示即可。

(4)實現(xiàn)音視頻同步的方法：播放兩幀音頻里面的所有視頻幀。

想要實現(xiàn)音視頻同步，必須要有幀的時間戳，這里捕獲到的幀只有播放的時間戳PTS，沒有譯碼時間戳DTS，所以我們只需要根據(jù)播放時間戳來決定播放即可。

程序的實現(xiàn)是根據(jù)上圖來的， 當音頻線程開始播放音頻幀A1時，就調用視頻線程的setRun方法，并且傳遞當前要播放的音頻幀時間戳curTime和下一幀音頻幀A2的時間戳nextTime給處于wait態(tài)的視頻線程，然后視頻線程啟動，開始從視頻FIFO中取出視頻幀G1，然后計算G1和A1的時間差，作為播放的延時，Thread.sleep(t1)后，視頻線程就將圖片顯示在swing組件上，比如JLabel.setIcon(image)。然后視頻線程再取出一幀圖像G2，比較G2的時間戳和A2的時間戳，如果G2時間戳小于A2，那么視頻線程繼續(xù)延時t2以后，播放這個G2圖像，接著G3同理，直到取得G4，和A2比較發(fā)現(xiàn)G4時間戳大于A2，那么視頻線程就進入wait態(tài)，等待下一次啟動。然后音頻線程播放完A1音頻幀以后，就從倉庫取出音頻幀A3，然后將A2的時間戳和A3的時間戳傳遞給視頻線程，然后開始播放A2，然后堵塞的視頻線程同理繼續(xù)播放。

(5)動態(tài)調節(jié)延時時間

由于個人PC都不是實時操作系統(tǒng)，也就是Thread.sleep是不精確的，并且受到聲卡播放聲音的制約，所以上面的基本實現(xiàn)思路是需要加以完善的。首先java的sourceDataLine的方法是依照一定的速度從內部緩沖區(qū)取出音頻線程寫入的數(shù)據(jù)，如果音頻寫入的數(shù)據(jù)被取光了，那么音頻播放就會發(fā)生卡頓，但是如果一次音頻數(shù)據(jù)寫入過多，那么就會發(fā)生音視頻可能就會不同步，所以要確保sourceDataLine的內部緩沖區(qū)是留有一定數(shù)據(jù)的，否則就會造成卡頓，但是數(shù)據(jù)量又不能過多，所以我們在G3到A2這段時間來進行聲音播放的調節(jié)，由于延時的不精準性，寫入的A1幀的數(shù)據(jù)可能時間還沒滿t6就可能被聲卡取光了，所以在播放完G3圖像以后，聲音線程會判斷根據(jù)sourceDataLine.available()返回的數(shù)據(jù)量進行判斷，如果數(shù)據(jù)量快要完了，就減少G3到A2的延時時間t4。這樣子就可以保證數(shù)據(jù)量是不會變?yōu)?造成聲音卡頓。

(6)下面是程序在window64下測試和ubuntu14下測試的結果圖:  播放是比較流暢的，同步也是可以的，但是開著播放比企鵝在IDE如IDEA中寫代碼的話，會卡，畢竟IDEA也是用java開發(fā)的，所以IDEA的運行會影響其他java程序，但是其他進程不會影響。

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論