x264編碼延時研究

研究了一下x264編碼延時.
方法是加log在x264.c
static int encode( x264_param_t *param, cli_opt_t *opt )
{
    ...
        i_frame_size = encode_frame( h, opt->hout, &pic, &last_dts );
        if( i_frame_size == 0)   // delay frames
            fprintf( stderr, "output zero %d\n", i_frame );
    ...
}

統計了一下，發現x264編碼延時幀數符合下面的公式。
    h->frames.i_delay =
                                 param->i_sync_lookahead +                        // 前向考慮幀數
                                max ( param->i_bframe,                               // B幀數量
                                          param->rc.i_lookahead)  +                 // 碼率控制前向考慮幀數
                                param->i_threads - 1.                                  // 並行編碼幀數

延遲有兩種：
1.編碼前延時(當前幀沒有編碼，需要buffer更多幀後才能開始編碼)。
   這種延時出口在 encoder.c,  x264_encoder_encode函數
   ...
        if( h->frames.i_input <= h->frames.i_delay + 1 - h->i_thread_frames )
        {
            /* Nothing yet to encode, waiting for filling of buffers */
            pic_out->i_type = X264_TYPE_AUTO;
            return 0;
        }
    ...
   i_sync_lookahead, i_bframe, rc.i_lookahead 都會在此影響延時。

2. 編碼後延時（當前幀已經編碼，但後續幀還沒編碼，只好先退出）。
   這種延時出口在 encoder.c,  x264_encoder_frame_end函數
    if( !h->out.i_nal )
    {
        pic_out->i_type = X264_TYPE_AUTO;
        return 0;
    }
    這部分延時是因爲x264並行幀編碼引起的。
    x264並行幀編碼每一次都是把一個幀組（i_threads個並行處理幀）處理完後，再處理下一個幀組。

根據公式看到減少幀延時的方法，也就是（zerolatency 設置）
            param->rc.i_lookahead = 0;
            param->i_sync_lookahead = 0;
            param->i_bframe = 0;
            param->b_sliced_threads = 1;   
            param->b_vfr_input = 0;
            param->rc.b_mb_tree = 0;

這個設置h->frames.i_delay = 0。但其中param->b_sliced_threads = 1  的設置值得懷疑。
當b_sliced_threads = 1時，x264放棄幀並行編碼，這必然會影響編碼速度。
一個折中的辦法是設置b_sliced_threads = 0，其他按照zerolatency 設置。
這樣h->frames.i_delay = param->i_threads - 1。
x264根據CPU自動計算i_threads，一般爲6/8. 這樣的幀羣延遲大概是1/3-1/2秒。
看具體系統的需要能否滿足。

這樣看x264並行幀編碼寫的還不是很自適應。
如果能夠讓i_threads在編碼起始階段隨着輸入幀數的增加而增加，那樣就可以徹底解決編碼羣延時的問題了。
個人想法，未經驗證，歡迎指正。