| 实际应用环境：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一次，就直接在原数据上修改，所以把录制本地放在后面。 |