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一次，就直接在原数据上修改，因此把录制本地放在后面。