<input id="meie2"></input>
嚴(yán)以律己,寬以待人. 三思而后行. GMail/GTalk: yanglinbo#google.com; MSN/Email: tx7do#yahoo.com.cn; QQ: 3 0 3 3 9 6 9 2 0 .
用FFMPEG SDK進(jìn)行視頻轉(zhuǎn)碼壓縮的時(shí)候，轉(zhuǎn)碼成功后去看視頻的內(nèi)容，發(fā)現(xiàn)音視頻是不同步的。這個(gè)的確是一個(gè)惱火的事情。我在用FFMPEG SDK做h264格式的FLV文件編碼Filter的時(shí)候就碰到了這個(gè)問(wèn)題。
經(jīng)過(guò)研究發(fā)現(xiàn)，F(xiàn)FMPEG SDK寫(xiě)入視頻的時(shí)候有兩個(gè)地方用來(lái)控制寫(xiě)入的時(shí)間戳，一個(gè)是AvPacket, 一個(gè)是AvFrame。 在調(diào)用avcodec_encode_video的時(shí)候需要傳入AvFrame的對(duì)象指針，也就是傳入一幀未壓縮的視頻進(jìn)行壓縮處理，AvFrame包含一個(gè)pts的參數(shù)，這個(gè)參數(shù)就是當(dāng)前幀將來(lái)在還原播放的時(shí)候的時(shí)間戳。而AvPacket里面也有pts，還有dts。說(shuō)起這個(gè)就必須要說(shuō)明一下I,P,B三種視頻壓縮幀。I幀就是關(guān)鍵幀，不依賴(lài)于其他視頻幀，P幀是向前預(yù)測(cè)的幀，只依賴(lài)于前面的視頻幀，而B(niǎo)幀是雙向預(yù)測(cè)視頻幀，依賴(lài)于前后視頻幀。由于B幀的存在，因?yàn)樗请p向的，必須知道前面的視頻幀和后面的視頻幀的詳細(xì)內(nèi)容后，才能知道本B幀最終該呈現(xiàn)什么圖像。而pts和dts兩個(gè)參數(shù)就是用來(lái)控制視頻幀的顯示和解碼的順序。
pts就是幀顯示的順序。
dts就是幀被讀取進(jìn)行解碼的順序。
如果沒(méi)有B幀存在，dts和pts是相同的。反之，則是不相同的。關(guān)于這個(gè)的詳細(xì)介紹可以參考一下mpeg的原理。
再說(shuō)說(shuō)AvPacket中包含的pts和dts兩個(gè)到底該設(shè)置什么值？
pts和dts需要設(shè)置的就是視頻幀解碼和顯示的順序。每增加一幀就加一，并不是播放視頻的時(shí)間戳。
但是實(shí)踐證明經(jīng)過(guò)rmvb解碼的視頻有時(shí)候并不是固定幀率的，而是變幀率的，這樣，如果每壓縮一幀，pts和dts加一的方案為導(dǎo)致音視頻不同步。
那怎么來(lái)解決音視頻同步的問(wèn)題呢？
請(qǐng)看如下代碼段。
lTimeStamp 是通過(guò)directshow 獲取的當(dāng)前的視頻幀的時(shí)間戳。
m_llframe_index為當(dāng)前已經(jīng)經(jīng)過(guò)壓縮處理的幀的數(shù)量。
首先av_rescale計(jì)算得到當(dāng)前壓縮處理已經(jīng)需要處理什么時(shí)間戳的視頻幀，如果該時(shí)間戳尚未到達(dá)directshow當(dāng)前提供的視頻幀的時(shí)間戳，則將該幀丟棄掉。
否則進(jìn)行壓縮操作。并設(shè)置AVPacket的pts和dts。這里假設(shè)B幀不存在。
因?yàn)樵趯?lái)播放的時(shí)候視頻以我們?cè)O(shè)定的固定播放幀率進(jìn)行播放，所以需要根據(jù)設(shè)定的播放幀率計(jì)算得到的視頻幀時(shí)間戳和directshow提供的當(dāng)前視頻幀的時(shí)間戳進(jìn)行比較，設(shè)定是否需要進(jìn)行實(shí)施延緩播放的策略。如果需要延緩播放，則將pts增加步長(zhǎng)2，否則以普通速度播放，則設(shè)置為1.dts與之相同。
posted on 2012-09-17 11:09 楊粼波 閱讀(2179) 評(píng)論(0) 編輯 收藏 引用 所屬分類(lèi): C++ 、Windows
Powered by: C++博客 Copyright © 楊粼波
<pre id="egomg"></pre>