decoder_decode_frame(ff_ffplay.c)

int decoder_decode_frame(FFPlayer *ffp, Decoder *d, AVFrame *frame, AVSubtitle *sub)

這部分代碼是ffmpeg軟解視頻和音頻pkt的時候被調(diào)用的代碼塊灭贷。

• avcodec_send_packet將pkt發(fā)送給ffmpeg
• avcodec_receive_frame獲取解碼后的frame

如果視頻存在B幀的情況下温学，avcodec_send_packet與avcodec_receive_frame并不會是嚴(yán)格按交錯順序調(diào)用成功（因?yàn)锽幀要依賴后面的幀才能解碼），有可能是avcodec_send_packet多個pkt后avcodec_receive_frame才能獲取到幀甚疟，也有可能你需要avcodec_receive_frame把幀讀出來后仗岖，才能繼續(xù)avcodec_send_packet（這時會返回EAGAIN）。

代碼塊中的packet_pending就是用來處理上面的情況的览妖。

avcodec_send_packet返回EAGAIN表示當(dāng)前還無法接受新的packet轧拄，還有frame沒有取出來：

d->packet_pending = 1;
av_packet_move_ref(&d->pkt, &pkt);

把這個packet存到d->pkt，在下一個循環(huán)里讽膏，先取frame檩电，再把packet接回來，接著上面的操作：

if (d->packet_pending) {
    av_packet_move_ref(&pkt, &d->pkt);
    d->packet_pending = 0;
}

注意：因?yàn)镮OS硬解帶B幀視頻時，回調(diào)輸出的視頻幀并不是按pts排序的俐末，所以接收需要自己排序料按，ijkplayer里的處理如下：

        pthread_mutex_lock(&ctx->m_queue_mutex);
        volatile sort_queue *queueWalker = ctx->m_sort_queue;
        if (!queueWalker || (newFrame->sort < queueWalker->sort)) { //若隊(duì)列為空或者newFrame的pts比隊(duì)列所有的元素都大
            newFrame->nextframe = queueWalker;
            ctx->m_sort_queue = newFrame;
        } else {  //找到合適的位置把newframe插進(jìn)去
            bool frameInserted = false;
            volatile sort_queue *nextFrame = NULL;
            while (!frameInserted) {
                nextFrame = queueWalker->nextframe;
                if (!nextFrame || (newFrame->sort < nextFrame->sort)) {
                    newFrame->nextframe = nextFrame;
                    queueWalker->nextframe = newFrame;
                    frameInserted = true;
                }
                queueWalker = nextFrame;
            }
        }
        ctx->m_queue_depth++;
        pthread_mutex_unlock(&ctx->m_queue_mutex);

//省略      

//當(dāng)隊(duì)列的長度大于max_ref_frames時，才可以開始渲染(max_ref_frames由sps解析得到)
        if ((ctx->m_queue_depth > ctx->fmt_desc.max_ref_frames)) {
            QueuePicture(ctx);
        }

即鹅搪，使用一個排序隊(duì)列來接收VTB的輸出站绪，當(dāng)隊(duì)列的長度超過max_ref_frames時遭铺，才從排序隊(duì)列取出到frame隊(duì)列丽柿。max_ref_frames是從sps里面解析出來的：

num_ref_frames規(guī)定了可能在視頻序列中任何圖像幀間預(yù)測的解碼過程中用到的短期參考幀和長期參考幀、互補(bǔ)參考場對以及不成對的參考場的最大數(shù)量魂挂。num_ref_frames 的取值范圍應(yīng)該在0到MaxDpbSize甫题。

sps已經(jīng)告訴了B幀的最大參考數(shù)量為num_ref_frames，所以我們的排序隊(duì)列只要取這么大涂召，就一定能把輸出的幀嚴(yán)格按PTS排序坠非。

音頻播放格式協(xié)商(IOS端為例)

音頻播放使用AudioQueue:

• 構(gòu)建AudioQueue：AudioQueueNewOutput
• 開始AudioQueueStart,暫停AudioQueuePause,結(jié)束AudioQueueStop
• 在回調(diào)函數(shù)IJKSDLAudioQueueOuptutCallback里，調(diào)用下層的填充函數(shù)來填充AudioQueue的buffer果正。
• 使用AudioQueueEnqueueBuffer把裝配完的AudioQueue Buffer入隊(duì)炎码，進(jìn)入播放。
  秋泳。

上面這些都是AudioQueue的標(biāo)準(zhǔn)操作潦闲，特別的是構(gòu)建AudioStreamBasicDescription的時候，也就是指定音頻播放的格式迫皱。格式是由音頻源的格式?jīng)Q定的歉闰，在IJKSDLGetAudioStreamBasicDescriptionFromSpec里看，除了格式固定為pcm之外卓起，其他的都是從底層給的格式復(fù)制過來和敬。這樣就有了很大的自由，音頻源只需要解碼成pcm就可以了戏阅。

而底層的格式是在audio_open里決定的昼弟，邏輯是：

• 根據(jù)源文件，構(gòu)建一個期望的格式wanted_spec,然后把這個期望的格式提供給上層奕筐，最后把上層的實(shí)際格式拿到作為結(jié)果返回私杜。一個類似溝通的操作，這種思維很值得借鑒
• 如果上傳不接受這種格式救欧，返回錯誤衰粹，底層修改channel數(shù)、采樣率然后再繼續(xù)溝通笆怠。
• 但是樣本格式是固定為s16,即signed integer 16,有符號的int類型铝耻，位深為16比特的格式。位深指每個樣本存儲的內(nèi)存大小，16個比特瓢捉，加上有符號频丘，所以范圍是[-2^15, 215-1],215為32768，變化性足夠了泡态。
  搂漠。

因?yàn)槎际莗cm,是不壓縮的音頻，所以決定性的因素就只有：采樣率某弦、通道數(shù)和樣本格式桐汤。樣本格式固定s16，和上層溝通就是決定采樣率和通道數(shù)靶壮。

這里是一個很好的分層架構(gòu)的例子怔毛，底層通用，上層根據(jù)平臺各有不同腾降。

音視頻同步

1拣度、同步鐘以及鐘時間的修正
同步鐘的概念： 音頻或者視頻，如果把內(nèi)容正確的完整的播放螃壤，某個內(nèi)容和一個時間是一一對應(yīng)的（PTS）抗果，當(dāng)前的音頻或者視頻播放到哪個位置瓢湃，它就有一個時間來表示控轿，這個時間就是同步鐘的時間萝招。所以音頻鐘的時間表示音頻播放到哪個位置堪侯，視頻鐘表示播放到哪個位置晒喷。

因?yàn)橐纛l和視頻是分開表現(xiàn)的璃赡，就可能會出現(xiàn)音頻和視頻的進(jìn)度不一致宫峦，在同步鐘上就表現(xiàn)為兩個同步鐘的值不同血公，如果讓兩者統(tǒng)一辕录，就是音視頻同步的問題睦霎。

因?yàn)橛辛送界姷母拍睿粢曨l內(nèi)容上的同步就可以簡化為更準(zhǔn)確的：音頻鐘和視頻鐘時間相同走诞。

這時會有一個同步鐘作為主鐘副女，也就是其他的同步鐘根據(jù)這個主鐘來調(diào)整自己的時間。滿了就調(diào)快蚣旱、快了就調(diào)慢碑幅。

compute_target_delay里的邏輯就是這樣，diff = get_clock(&is->vidclk) - get_master_clock(is);這個是視頻鐘和主鐘的差距：

//視頻落后超過臨界值塞绿，縮短下一幀時間
if (diff <= -sync_threshold)
    delay = FFMAX(0, delay + diff);
//視頻超前沟涨，且超過臨界值，延長下一幀時間
else if (diff >= sync_threshold && delay > AV_SYNC_FRAMEDUP_THRESHOLD)
    delay = delay + diff;
else if (diff >= sync_threshold)
    delay = 2 * delay;

為什么不都是delay + diff,即為什么還有第3種1情況：

延時直接加上diff,那么下一幀就直接修正了視頻種和主鐘的差異异吻，但有可能這個差異已經(jīng)比較大了裹赴，直接一步到位的修正導(dǎo)致的效果就是：畫面有明顯的停頓喜庞，然后聲音繼續(xù)播，等到同步了視頻再恢復(fù)正常棋返。

而如果采用2*delay的方式延都，是每一次修正delay,多次逐步修正差異，可能變化上會更平滑一些睛竣。效果上就是畫面和聲音都是正常的晰房，然后聲音逐漸的追上聲音，最后同步射沟。

至于為什么第2種情況選擇一步到位的修正殊者，第3種情況選擇逐步修正，這個很難說躏惋。因?yàn)锳V_SYNC_FRAMEDUP_THRESHOLD值為0.15幽污，對應(yīng)的幀率是7左右嚷辅，到這個程度簿姨，視頻基本都是幻燈片了，我猜想這時逐步修正也沒意義了簸搞。

2扁位、同步鐘時間獲取的實(shí)現(xiàn)

再看同步鐘時間的實(shí)現(xiàn)：get_clock獲取時間， set_clock_at更新時間趁俊。

解釋一下：return c->pts_drift + time - (time - c->last_updated) * (1.0 - c->speed);域仇，為啥這么寫?

上一次顯示的時候，更新了同步鐘寺擂，調(diào)用set_clock_at,上次的時間為c->last_updated,則：

c->pts_drift + time = (c->pts - c->last_updated)+time;

假設(shè)距離上次的時間差time_diff = time - c->last_updated暇务，則表達(dá)式整體可以變?yōu)椋?/p>

c->pts+time_diff+(c->speed - 1)*time_diff

合并后兩項(xiàng)變?yōu)?

c->pts+c->speed*time_diff.

我們要求得就是當(dāng)前時間時的媒體內(nèi)容位置，上次的位置是c->pts,而中間過去了time_diff這么多時間怔软，媒體內(nèi)容過去的時間就是：播放速度x現(xiàn)實(shí)時間垦细，也就是c->speed*time_diff。

舉例：現(xiàn)實(shí)里過去10s,如果你2倍速的播放挡逼，那視頻就過去了20s括改。所以這個表達(dá)式就很清晰了。

在set_clock_speed里同時調(diào)用了set_clock,這是為了保證從上次更新時間以來家坎，速度是沒變的嘱能，否則計(jì)算就沒有意義了。

3虱疏、視頻顯示時的時間控制

static void video_refresh(void *opaque, double *remaining_time)
{
    //……
    //lastvp上一幀惹骂，vp當(dāng)前幀 ，nextvp下一幀

    last_duration = vp_duration(is, lastvp, vp);//計(jì)算上一幀的持續(xù)時長
    delay = compute_target_delay(last_duration, is);//參考audio clock計(jì)算上一幀真正的持續(xù)時長

    time= av_gettime_relative()/1000000.0;//取系統(tǒng)時刻
    if (time < is->frame_timer + delay) {//如果上一幀顯示時長未滿做瞪，重復(fù)顯示上一幀
        *remaining_time = FFMIN(is->frame_timer + delay - time, *remaining_time);
        goto display;
    }

    is->frame_timer += delay;//frame_timer更新為上一幀結(jié)束時刻对粪，也是當(dāng)前幀開始時刻
    if (delay > 0 && time - is->frame_timer > AV_SYNC_THRESHOLD_MAX)
        is->frame_timer = time;//如果與系統(tǒng)時間的偏離太大，則修正為系統(tǒng)時間

    //更新video clock
    //視頻同步音頻時沒作用
    SDL_LockMutex(is->pictq.mutex);
    if (!isnan(vp->pts))
        update_video_pts(is, vp->pts, vp->pos, vp->serial);
    SDL_UnlockMutex(is->pictq.mutex);

    //……

    //丟幀邏輯
    if (frame_queue_nb_remaining(&is->pictq) > 1) {
        Frame *nextvp = frame_queue_peek_next(&is->pictq);
        duration = vp_duration(is, vp, nextvp);//當(dāng)前幀顯示時長
        if(time > is->frame_timer + duration){//如果系統(tǒng)時間已經(jīng)大于當(dāng)前幀，則丟棄當(dāng)前幀
            is->frame_drops_late++;
            frame_queue_next(&is->pictq);
            goto retry;//回到函數(shù)開始位置衩侥，繼續(xù)重試(這里不能直接while丟幀国旷，因?yàn)楹芸赡躠udio clock重新對時了，這樣delay值需要重新計(jì)算)
        }
    }
}

主要思路就是如果視頻播放過快茫死，則重復(fù)播放上一幀跪但，以等待音頻；如果視頻播放過慢峦萎，則丟幀追趕音頻屡久。實(shí)現(xiàn)的方式是，參考audio clock爱榔，計(jì)算上一幀（在屏幕上的那個畫面）還應(yīng)顯示多久（含幀本身時長）被环，然后與系統(tǒng)時刻對比，是否該顯示下一幀了详幽。

這里與系統(tǒng)時刻的對比筛欢，引入了另一個概念——frame_timer〈狡福可以理解為幀顯示時刻版姑，如更新前，是上一幀的顯示時刻迟郎；對于更新后（is->frame_timer += delay）剥险，則為當(dāng)前幀顯示時刻。

上一幀顯示時刻加上delay（還應(yīng)顯示多久（含幀本身時長））即為上一幀應(yīng)結(jié)束顯示的時刻宪肖。具體原理看如下示意圖：

1.jpg

這里給出了3種情況的示意圖：

• time1：系統(tǒng)時刻小于lastvp結(jié)束顯示的時刻（frame_timer+dealy）表制，即虛線圓圈位置。此時應(yīng)該繼續(xù)顯示lastvp
• time2：系統(tǒng)時刻大于lastvp的結(jié)束顯示時刻控乾，但小于vp的結(jié)束顯示時刻（vp的顯示時間開始于虛線圓圈么介，結(jié)束于黑色圓圈）。此時既不重復(fù)顯示lastvp阱持，也不丟棄vp夭拌，即應(yīng)顯示vp
• time3：系統(tǒng)時刻大于vp結(jié)束顯示時刻（黑色圓圈位置，也是nextvp預(yù)計(jì)的開始顯示時刻）衷咽。此時應(yīng)該丟棄vp鸽扁。

至此，基本上分析完了視頻同步音頻的過程镶骗，簡單總結(jié)下：

• 基本策略是：如果視頻播放過快桶现，則重復(fù)播放上一幀，以等待音頻鼎姊；如果視頻播放過慢骡和，則丟幀追趕音頻相赁。
• 這一策略的實(shí)現(xiàn)方式是：引入frame_timer概念，標(biāo)記幀的顯示時刻和應(yīng)結(jié)束顯示的時刻慰于，再與系統(tǒng)時刻對比钮科，決定重復(fù)還是丟幀。
• lastvp的應(yīng)結(jié)束顯示的時刻婆赠，除了考慮這一幀本身的顯示時長绵脯，還應(yīng)考慮了video clock與audio clock的差值。
• 并不是每時每刻都在同步休里，而是有一個“準(zhǔn)同步”的差值區(qū)域蛆挫。

seek的處理

seek就是調(diào)整進(jìn)度條到新的地方開始播，這個操作會打亂原本的數(shù)據(jù)流妙黍，一些播放秩序要重新建立悴侵。需要處理的問題包括：

• 緩沖區(qū)數(shù)據(jù)的釋放，而且要重頭到位全部釋放干凈
• 播放時間顯示
• “加載中”的狀態(tài)的維護(hù),這個影響著用戶界面的顯示問題
• 剔除錯誤幀的問題

流程
1拭嫁、外界seek調(diào)用到ijkmp_seek_to_l可免，然后發(fā)送消息ffp_notify_msg2(mp->ffplayer, FFP_REQ_SEEK, (int)msec);,消息捕獲到后調(diào)用到stream_seek,然后設(shè)置seek_req為1，記錄seek目標(biāo)到seek_pos噩凹。

2巴元、在讀取函數(shù)read_thread里毡咏，在is->seek_req為true時驮宴，進(jìn)入seek處理,幾個核心處理:

• ffp_toggle_buffering關(guān)閉解碼，packet緩沖區(qū)靜止
• 調(diào)用avformat_seek_file進(jìn)行seek
• 成功之后用packet_queue_flush清空緩沖區(qū)呕缭，并且把flush_pkt插入進(jìn)去堵泽，這時一個標(biāo)記數(shù)據(jù)
• 把當(dāng)前的serial記錄下來

if (pkt == &flush_pkt)
        q->serial++;

所以serial的意義就體現(xiàn)出來了，每次seek,serial+1,也就是serial作為一個標(biāo)記恢总，相同代表是同一次seek里的迎罗。

3、到decoder_decode_frame里：

• 因?yàn)閟eek的修改是在讀取線程里片仿，和這里的解碼線程不是一個纹安，所以seek的修改可以在這里代碼的任何位置出現(xiàn)。

• if (d->queue->serial == d->pkt_serial)這個判斷里面為代碼塊1砂豌，while (d->queue->serial != d->pkt_serial)這個循環(huán)為代碼塊2厢岂，if (pkt.data == flush_pkt.data)這個判斷為true為代碼塊3，false為代碼塊4.

• 如果seek修改出現(xiàn)在代碼塊2之前阳距，那么就一定會進(jìn)代碼塊2塔粒，因?yàn)閜acket_queue_get_or_buffering會一直讀取到flush_pkt，所以也就會一定進(jìn)代碼塊3筐摘，會執(zhí)行avcodec_flush_buffers清空解碼器的緩存卒茬。

• 如果seek在代碼塊2之后船老，那么就只會進(jìn)代碼塊4，但是再循環(huán)回去時圃酵，會進(jìn)代碼塊2柳畔、代碼塊3，然后avcodec_flush_buffers把這個就得packet清掉了郭赐。

• 綜合上面兩種情況荸镊，只有seek之后的packet才會得到解碼。

如果整個數(shù)據(jù)流是一條河流堪置，那flush_pkt就像一個這個河流的一個浮標(biāo)躬存，遇到這個浮標(biāo)，后面水流的顏色都變了舀锨。

4岭洲、播放處
視頻video_refresh里：

if (vp->serial != is->videoq.serial) {
       frame_queue_next(&is->pictq);
       goto retry;
   }

音頻audio_decode_frame里：

do {
       if (!(af = frame_queue_peek_readable(&is->sampq)))
           return -1;
       frame_queue_next(&is->sampq);
    } while (af->serial != is->audioq.serial);

都根據(jù)serial把舊數(shù)據(jù)略過了。

所以整體看下來坎匿，seek體系里最厲害的東西的東西就是使用了serial來標(biāo)記數(shù)據(jù)盾剩，從而可以很明確的知道哪些是舊數(shù)據(jù)，哪些是新數(shù)據(jù)替蔬。