許久沒寫博客了，似乎現(xiàn)在也很難靜下心來去寫東西，倒也不是心情浮躁，以前的寫blog用來收集網(wǎng)上文章，記錄自己的一些經(jīng)驗，后來假設了自己的文件服務器，用wiz做了筆記的server,收集什么東西用wiz就完成了，自己記錄點經(jīng)驗也不在乎格式，也都沒拿出來分享。這次辛辛苦苦做完一個項目，其中遇到一些問題，沒有網(wǎng)絡上的資料自己是很難解決的。因此整理點東西，與大家分享，也不能總受之與人吧。
終于做完了多畫面合成的項目，頗有心得，其間也遇到一些問題，沒有網(wǎng)絡上的資料自己是很難解決的，但也不是所有東西都能在網(wǎng)上找到辦法，使用ffmpeg遇到太多問題，許多只能通過閱讀源碼解決。如今做完了，拿出來與眾分享。
畫面合成器是將多個承載于UDP的TS流（MPTS，SPTS）解碼，將解碼后圖像縮放成小畫面，再將各個源合并成2x2,3x3,4x4等方式，實現(xiàn)電視墻的效果。
項目的需求是這樣的：
1.UDP輸入UDP輸出
2.提供源切換的接口，客戶會再某個時刻換掉某個源
3.良好的異常處理，某個UDP源斷流或恢復不影響現(xiàn)有節(jié)目。這不是客戶的要求，但有過大型項目經(jīng)驗的人知道，這是一定要考慮的
從實現(xiàn)層面來講，需要以下技術(shù)點：
1.UDP單播組播接收
2.TS封裝的H264與MPEG2視頻解碼為YUV
3.YUV縮放
4.YUV畫面拼接
5.合成后的YUV壓縮為H264
6.壓縮后的視頻打包TS
7.打包后的TS通過UDP發(fā)送
8.發(fā)送時需要進行流控，保證VLC可正常播放。
這些技術(shù)點不算難，真正的難點在于統(tǒng)籌運作，N個源各自的解碼后畫面輸出速度不同，雖然我們要求各源幀率相同。各解碼線程畫面輸出雖整體相同，但肯定會忽高忽低。如果每個源都正常的話，我們可以等待每個源都有畫面的時候才進行合成。但是我們需要考慮源斷流與恢復，就不能一直等待某個源。其二，為了支持源切換，我們應該涉及好運作模式，實現(xiàn)無縫切換，但這些只是我特定 業(yè)務的需要，接下來只講與ffmpeg相關技術(shù)。
先講上面提到的8個技術(shù)點，UDP收發(fā)就不用說了，值得一提的是接收需要使用異步模式，這個在后面會提到。除了YUV畫面拼接，其他都可以用ffmpeg sdk實現(xiàn)。因此主要討論使用ffmpeg進行解碼編碼，這種技術(shù)文章其實很多，但他們一般只有簡單的方案，對于這些比較常見的東西，我們也不做討論，只討論幾個重點，而又缺乏資料的問題，主要有：
1.對解碼及編碼自定義io回掉。UDP接收及發(fā)送不通過ffmpeg實現(xiàn)。對于UDP源來說，ffmpeg對MPTS支持不好。對于輸出UDP來說，ffmpeg沒有流控
有時我們希望ffmpeg的api打開的不是文件或某個協(xié)議的URL，直接傳遞數(shù)據(jù)緩沖給他，ffmpeg不支持傳遞數(shù)據(jù)指針給他，要求他編碼或解碼，這在ffmpeg api中的實現(xiàn)方式是IO回掉函數(shù)。他在需要的時候來調(diào)用你的函數(shù)來讀取或?qū)懭?。以解碼為例，下面為示例代碼：
AVIOContext *pb = avio_alloc_context(pbuf+1316, AVIO_BUF_SIZE-1316, 0, this, ReadDataCb, NULL, NULL);
if (av_probe_input_buffer(pb, &pinFmt, "", NULL, 0, MAX_PROBE_SIZE) < 0)
{
//error...
}
AVFormatContext *pFmtCt = avformat_alloc_context();
pFmtCt->pb = pb;
if (avformat_open_input(&pFmtCt, "", pinFmt, NULL) < 0)
{
//error...
}
讀取回掉原型如下：
static int ReadDataCb(void *opaque, uint8_t *buf, int buf_size);
實現(xiàn)理念一般應該是除非想要停止解碼，返回-1，否則返回數(shù)據(jù)長度。保證他讀到數(shù)據(jù)
不知道是出于內(nèi)存對齊還是什么原因，
uint8_t *pbuf = (uint8_t *)calloc(AVIO_BUF_SIZE,1);
pb = avio_alloc_context(pbuf+1316, AVIO_BUF_SIZE-1316, 0, this, ReadDataCb, NULL, NULL);
的時候第一個參數(shù)直接傳pbuf會崩潰，所以+1316
而若使用av_mallocz，雖可以直接傳pbuf,卻在av_free的時候崩潰，沒有找到原因。
2.由于需要實現(xiàn)切換，所以需要將某個源完全銷毀，不產(chǎn)生內(nèi)存泄露，不要小看這個問題，網(wǎng)上的很多代碼是不對的。
銷毀 AVFormatContext
正確銷毀方式：
/* close decoder for each stream */
for (int i = 0; i < pFmtCt->nb_streams; i++)
{
if (pFmtCt->streams[i]->codec->codec_id != AV_CODEC_ID_NONE)
{
THREAD_MUTEX_LOCK(&g_mutex_avcodec_oc);
avcodec_close(pFmtCt->streams[i]->codec);
THREAD_MUTEX_UNLOCK(&g_mutex_avcodec_oc);
}
}
avformat_close_input(&pFmtCt);
銷毀 AVIOContext
//不可使用avio_close
av_free(pb->buffer);
av_free(pb);
銷毀 AVFrame
AVFrame *pframe = avcodec_alloc_frame();
avcodec_free_frame(&pframe);
3.多線程使用ffmpeg sdk問題
avcodec_open/avcodec_close不是線程安全的，必須進行全局加鎖保護，或者其他同步方式。除了這兩個函數(shù)外，由于av_find_stream_info內(nèi)部調(diào)用了avcodec_open，也需要加鎖。但av_find_stream_info有可能執(zhí)行時間比較長，如果沒特別的必要，可以不使用此函數(shù)。對于解碼來說，有下面兩個函數(shù)：
av_probe_input_buffer
avformat_open_input
大部分情況下已經(jīng)可以正常解碼了。
關于壓縮
ffmpeg壓縮H264 TS時CBR并不好用，設置了mux_rate會導致TS封裝出錯。老老實實用VBR，不設置mux_rate
進行H264壓縮時一個選項一定要設置的：
preset
在壓縮效率和運算時間中平衡的預設值，可用選項：
ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow and placebo