x264 b_annexb格式和多slice

實際應用環境：iOS，Android x264_param_t中有下面兩個參數值得注意下 int i_threads;        /* encode multiple frames in parallel */ int b_annexb;        /* if set, place start codes (4 bytes) before NAL units, i_threads 默認0，自動設置爲 x264_cpu_num_processors() * (h->param.b_sliced_threads?2:3)/2; 實測 i_threads = 2， 則 x264_encoder_encode 出來的 pi_nal 一般也是2 可見編碼出來每幀的NAL個數跟 i_threads 是相關的。 b_annexb 默認1，可參考 http://aviadr1.blogspot.com.au/2 ... -explained-for.html 個人需求： x264編碼出來的流需交給 librtmp 推流，而且交給ffmpeg錄製本地mp4視頻。 librtmp推流怎麼封裝，請參考小乙哥的 BLE https://github.com/wenjiegit/Bul ... /BleX264Encoder.cpp BLE 是設置b_annexb 爲0，這樣封裝成flv直接用 咱們再來看看另外一篇博文 http://www.codeman.net/2014/01/439.html，這裏 send_rtmp_video 是有封裝是有問題，這裏buf 是 startcode 形式，若是隻是一個 NAL 那沒有問題，可是若是是多個NAL，這裏就出問題了。A，buf 裏面就一個 NAL ，send_rtmp_video 前面先去掉 startcode，而後巧妙的在 body[5~8] 設置成4個字節的NAL數據長度。由於startcode 有3個字節或者4字節狀況，要是直接在buf修改，4個本身好處理，3個字節就麻煩了B，buf 裏面有多個NAL，那 send_rtmp_video 的封裝就有問題了，並無把buf 正確的轉換成 AVCC 格式。可是目前國內不少CDN也兼容了這個錯誤。可見，要是annexb格式，並且是多NAL，那這個封裝就十分麻煩了，須要把buf 正確的轉換成 AVCC格式。因此，就像BLE的作法，把b_annexb設置爲0，i_thread 無所謂，無論是一個NAL仍是多個，封裝時都很方便，直接memcpy就能夠。我這邊須要交給ffmpeg保存視頻，實測 av_write_frame 只支持 annexb 格式，avformat_alloc_output_context2 傳入的路徑也是 .mp4，這裏你們要是找到 av_write_frame 支持 AVCC格式輸入的分享一下。要知足這兩個需求，想代碼比較省事，建議設置b_annexb = 0。由於AVCC 轉成 annexb 格式比較簡單，反之很麻煩。x264出來的數據先交給librtmp，再交給ffmpeg封裝，由於給av_write_frame前，須要 AVCC 轉成 annexb，爲了不少memcpy一次，就直接在原數據上修改，因此把錄製本地放在後面。