elva

    終于做完了多畫面合成的項(xiàng)目，頗有心得，其間也遇到一些問題，沒有網(wǎng)絡(luò)上的資料自己是很難解決的，但也不是所有東西都能在網(wǎng)上找到辦法，使用ffmpeg遇到太多問題，許多只能通過閱讀源碼解決。如今做完了，拿出來與眾分享。
畫面合成器是將多個(gè)承載于UDP的TS流（MPTS，SPTS）解碼，將解碼后圖像縮放成小畫面，再將各個(gè)源合并成2x2,3x3,4x4等方式，實(shí)現(xiàn)電視墻的效果。
項(xiàng)目的需求是這樣的：
1.UDP輸入U(xiǎn)DP輸出
2.提供源切換的接口，客戶會再某個(gè)時(shí)刻換掉某個(gè)源
3.良好的異常處理，某個(gè)UDP源斷流或恢復(fù)不影響現(xiàn)有節(jié)目。這不是客戶的要求，但有過大型項(xiàng)目經(jīng)驗(yàn)的人知道，這是一定要考慮的
從實(shí)現(xiàn)層面來講，需要以下技術(shù)點(diǎn)：
1.UDP單播組播接收
2.TS封裝的H264與MPEG2視頻解碼為YUV
3.YUV縮放
4.YUV畫面拼接
5.合成后的YUV壓縮為H264
6.壓縮后的視頻打包TS
7.打包后的TS通過UDP發(fā)送
8.發(fā)送時(shí)需要進(jìn)行流控，保證VLC可正常播放。
這些技術(shù)點(diǎn)不算難，真正的難點(diǎn)在于統(tǒng)籌運(yùn)作，N個(gè)源各自的解碼后畫面輸出速度不同，雖然我們要求各源幀率相同。各解碼線程畫面輸出雖整體相同，但肯定會忽高忽低。如果每個(gè)源都正常的話，我們可以等待每個(gè)源都有畫面的時(shí)候才進(jìn)行合成。但是我們需要考慮源斷流與恢復(fù)，就不能一直等待某個(gè)源。其二，為了支持源切換，我們應(yīng)該涉及好運(yùn)作模式，實(shí)現(xiàn)無縫切換，但這些只是我特定 業(yè)務(wù)的需要，接下來只講與ffmpeg相關(guān)技術(shù)。
先講上面提到的8個(gè)技術(shù)點(diǎn)，UDP收發(fā)就不用說了，值得一提的是接收需要使用異步模式，這個(gè)在后面會提到。除了YUV畫面拼接，其他都可以用ffmpeg sdk實(shí)現(xiàn)。因此主要討論使用ffmpeg進(jìn)行解碼編碼，這種技術(shù)文章其實(shí)很多，但他們一般只有簡單的方案，對于這些比較常見的東西，我們也不做討論，只討論幾個(gè)重點(diǎn)，而又缺乏資料的問題，主要有：
1.對解碼及編碼自定義io回掉。UDP接收及發(fā)送不通過ffmpeg實(shí)現(xiàn)。對于UDP源來說，ffmpeg對MPTS支持不好。對于輸出UDP來說，ffmpeg沒有流控

有時(shí)我們希望ffmpeg的api打開的不是文件或某個(gè)協(xié)議的URL，直接傳遞數(shù)據(jù)緩沖給他，ffmpeg不支持傳遞數(shù)據(jù)指針給他，要求他編碼或解碼，這在ffmpeg api中的實(shí)現(xiàn)方式是IO回掉函數(shù)。他在需要的時(shí)候來調(diào)用你的函數(shù)來讀取或?qū)懭搿Ｒ越獯a為例，下面為示例代碼：
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);
實(shí)現(xiàn)理念一般應(yīng)該是除非想要停止解碼，返回-1，否則返回?cái)?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í)候第一個(gè)參數(shù)直接傳pbuf會崩潰，所以+1316
而若使用av_mallocz，雖可以直接傳pbuf,卻在av_free的時(shí)候崩潰，沒有找到原因。

2.由于需要實(shí)現(xiàn)切換，所以需要將某個(gè)源完全銷毀，不產(chǎn)生內(nèi)存泄露，不要小看這個(gè)問題，網(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不是線程安全的，必須進(jìn)行全局加鎖保護(hù)，或者其他同步方式。除了這兩個(gè)函數(shù)外，由于av_find_stream_info內(nèi)部調(diào)用了avcodec_open，也需要加鎖。但av_find_stream_info有可能執(zhí)行時(shí)間比較長，如果沒特別的必要，可以不使用此函數(shù)。對于解碼來說，有下面兩個(gè)函數(shù)：
av_probe_input_buffer
avformat_open_input
大部分情況下已經(jīng)可以正常解碼了。

關(guān)于壓縮
ffmpeg壓縮H264 TS時(shí)CBR并不好用，設(shè)置了mux_rate會導(dǎo)致TS封裝出錯(cuò)。老老實(shí)實(shí)用VBR，不設(shè)置mux_rate
進(jìn)行H264壓縮時(shí)一個(gè)選項(xiàng)一定要設(shè)置的：
preset
在壓縮效率和運(yùn)算時(shí)間中平衡的預(yù)設(shè)值，可用選項(xiàng)：
ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow and placebo