轉(zhuǎn)載自:http://blog.csdn.net/bluestn/article/details/2068351
我在用FFMPEG 開發(fā)在DirectShow 環(huán)境下生成FLV的篩選器(Filter)的時(shí)候，碰到了一個(gè)比較古怪的問題。因?yàn)樵摵Y選器的輸入格式需要支持常見的RGB，和YUV格式。但是在輸入是RGB格式的時(shí)候，最終生成的視頻圖像是翻轉(zhuǎn)的。而用YUV格式確實(shí)沒有問題的。
分析了一下程序，因?yàn)閒fmpeg支持的最終存入FLV的格式是YUV420P，需要調(diào)用sws_scale進(jìn)行圖像的格式轉(zhuǎn)換，應(yīng)該是調(diào)用sws_scale進(jìn)行圖像格式轉(zhuǎn)換的時(shí)候發(fā)生的圖像反轉(zhuǎn)。雖然問題很顯然，但是卻一直找不到好的辦法，這個(gè)問題困擾了好久，也查看了ffmpeg的源代碼。本想也一段代碼，先把RGB格式的圖像先手工做一次反轉(zhuǎn)，再通過sws_scale進(jìn)行處理，那樣負(fù)負(fù)得正正好解決問題，當(dāng)然實(shí)現(xiàn)這樣的反轉(zhuǎn)代碼也比較簡(jiǎn)單，稍微花點(diǎn)時(shí)間就可以搞定。但是進(jìn)行編解碼處理的程序關(guān)鍵是性能，這樣處理，因?yàn)閳D像反轉(zhuǎn)操作，白白損失了大量的CPU。后來發(fā)現(xiàn)其實(shí)，有一個(gè)非常巧妙的方法可以解決這個(gè)問題?；蛟Sffmpeg在開發(fā)的時(shí)候，他們?cè)缫芽紤]到了這個(gè)問題，已經(jīng)預(yù)留了這個(gè)后門了。
辦法是這樣的：
先看看sws_scale的函數(shù)定義
int sws_scale(struct SwsContext *ctx, uint8_t* src[], int srcStride[],
int srcSliceY, int srcSliceH, uint8_t* dst[], int dstStride[])
其中src和srcStride定義了輸入圖像的四個(gè)平面的數(shù)據(jù)起始指針和四個(gè)平面中每一行包含的像素的個(gè)數(shù)。
dst和dstStride是輸出變量，定義的是輸出圖像的四個(gè)平面的數(shù)據(jù)起始指針和四個(gè)平面包含的數(shù)據(jù)的大小。
為什么一個(gè)圖像有四個(gè)平面，可以找一下YUV格式的一些詳細(xì)介紹就可以明白。
當(dāng)然，RGB格式是按照緊湊格式進(jìn)行編碼的，因此只有一個(gè)平面，也就是說只要設(shè)置src[0]就可以，src[1],src[2],src[3]都為NULL。
我們就在設(shè)置src[0]和srcStride[0]的地方做文章。
按照一般處理src[0]和srcStride[0]分別設(shè)置為起始圖像數(shù)據(jù)的開始和圖像每一行的像素個(gè)數(shù)。
那如果把src[0] 設(shè)置為 width * ( height - 1) srcStride[0] = -height 結(jié)果會(huì)如何呢？是不是就會(huì)把圖像倒過來呢？
實(shí)際確實(shí)如此。進(jìn)行圖像倒置的操作盡然如此簡(jiǎn)單。這樣避免了人為再添加一次圖像的反轉(zhuǎn)操作，提高了編碼的性能。