x264 如何提升 1‰ 的转码性能

在8K视频编解码特别是解码部分，我做了一些优化工作，转码速度提升了50%以上。专家们评价曰：“主要围绕算法并行度的优化，属于算法性能优化的常规手段，在创新性和技术难度方面的体现较为一般”。评价过于犀利，不服不行，可能专家们认为编解码提升并行度是多开几个线程的事。

好吧，那我换用另一种手段，叫“Don’t taking off your pants to fart”，来做一个提升1‰的优化。读过唐诗的都知道，千是虚数，优化效果基本上被淹没在测试噪声中…

作者：quink
来源：Fun With FFmpeg
原文：https://mp.weixin.qq.com/s/NrpPH5y0A1Odn-9yp1VP8w

0、前置信息

H.264常用的bitstream格式有三种：annexb、avcc以及RTP协议中的特有格式。简单来说，annexb格式是start code加nal_unit，avcc是nal_unit的长度加nal_unit，RTP H.264负载格式既没有start code也没有长度信息。

不同的容器格式使用不同的bitstream格式，比如MP4/MKV/FLV使用avcc格式，TS使用annexb格式，直接H.264裸流也是使用annexb格式。当然，国内有些团队比较随性，在FLV里使用annexb格式，再让大家兼容它。

除了bitstream格式外，还有一个in-band/out-of-band参数集的问题，就是在哪里存放SPS/PPS。像MP4/MKV，“一般”是要求在文件特定位置存SPS/PPS，其他位置只有音视频帧数据。而像TS格式，SPS/PPS是随着IDR帧重复出现的。FFmpeg libavformat定义了一个flag，叫

#define AVFMT_GLOBALHEADER  0x0040 /**< Format wants global header. *

libavcodec定义了一个flag，叫

#define AV_CODEC_FLAG_GLOBAL_HEADER   (1 << 22)

global header约等于out-of-band SPS/PPS。

关于bitstream格式和in-band/out-of-band参数集问题就介绍到这里。相关资料比较多，详细信息可以阅读具体的标准文档。

1、问题描述

我们的优化手段是“Don’t taking off your pants to fart”，所以对应的问题是一个“taking off your pants to fart”问题：

x264编码器能够输出annexb和avcc两种bitstream格式
FFmpeg的种种限制，导致x264只能输出annexb格式
当编码后封装为MP4/MKV格式，或者生成FLV走RTMP推流时，libavformat再做一次格式转换，把annexb转成avcc格式。注意这里是处理所有视频帧，处理的时候要拷贝一次packet数据，既浪费CPU，又浪费内存

当前的处理流程：

[x264]—annexb—>[avformat/avc]—avcc—>[avformat/movenc]—>mp4

优化的处理流程：

[x264]—avcc—>[avformat/movenc]—>mp4

看起来很简单，但工程落地，困难往往藏在细节中，把牛顿三定律背的滚瓜烂熟，未必造的出二踢脚，更别说火箭了。

一个小小的优化，我前后改了六次，遇到一些有趣的、容易被忽视的小细节，下面展开描述。

2、如何让x264输出avcc格式bitstream

x264参数配置有两种方式：直接给成员变量赋值，以及x264_param_parse接口。

x264设置bitstream格式的成员变量：

int b_annexb;     /* if set, place start codes (4 bytes) before NAL units,
                   * otherwise place size (4 bytes) before NAL units. */

通过x264_param_parse配置方式：

x264_param_parse(param, "annexb", "0");

FFmpeg配置x264输出avcc格式：

ffmpeg -i foo.mp4 \
  -c:a copy \
  -c:v libx264 \
  -x264-params "annexb=0" \
  -y bar.mp4

转码运行过程看着没问题，但如果你试着播放输出的视频文件，会发现视频无法解码，没有画面。问题出在哪里？

3、FFmpeg bitstream格式限制

FFmpeg框架层既支持annexb格式也支持avcc格式，但是有以下限制：

extradata的bitstream格式和AVPacket中的bitstream格式应当是同一种格式，不可以混用两种格式。很多地方，FFmpeg会根据extradata的格式来判断AVPacket的格式，前提假设是两者为同一种格式
对于avcc格式，FFmpeg要求extradata是完整的AVCDecoderConfigurationRecord

当x264配置输出avcc格式时，x264_encoder_headers输出的还是一个个的NALU，是sps_nal_length+sps_nal、pps_nal_length+pps_nal、sei_nal_length+sei_nal，不是完整的AVCDecoderConfigurationRecord。

int x264_encoder_headers( x264_t *, x264_nal_t **pp_nal, int *pi_nal );

FFmpeg当前构造extradata，是直接把x264_encoder_headers输出的数据拼接到一起。annexb格式没问题，avcc格式直接拼一起得到的extradata不是完整的AVCDecoderConfigurationRecord，不符合FFmpeg的格式要求。输出mp4时，FFmpeg误认为extradata是完整的AVCDecoderConfigurationRecord，导致生成的mp4文件格式错误，视频无法解码。

4、解决方案

我考虑了几种解决方案：

1、让FFmpeg extradata支持x264 headers的格式

2、在libavcodec里加一个统一的模块，把x264 header格式转成AVCDecoderConfigurationRecord

3、在FFmpeg x264 wrapper里做处理，把header转成AVCDecoderConfigurationRecord格式extradata

方案1，新增一种extradata格式，影响面太广，容易制造混乱。

方案2，其实我是考虑了其他的编码器，比如videotoolbox，也面临同样问题。但是否能复用，复用到什么程度还不确定。

方案3，在x264 wrapper里做处理最简单，时机成熟了，可以再抽取出来复用到其他编码器。

跟 Andreas Rheinhardt 讨论之后，选择了方案3。

5、方案落地

由SPS/PPS生成AVCDecoderConfigurationRecord，好像很简单，毕竟libavformat/avc.c里已经实现了一遍。简单粗暴的做法，那就直接抄了。但FFmpeg里做事的风格不是这样的。

如果你打开libavformat/avc.c看看，你会发现处理过程还是挺复杂的，原因有两点：

由SPS/PPS生成AVCDecoderConfigurationRecord涉及SPS的parse过程
libavformat不能依赖libavcodec的内部API，因为两者以动态库编译时，libavcodec内部的API对libavformat来说是不可见的

因为libavcodec和libavformat的隔离，导致libavformat/avc.c实现的啰嗦。在libavcodec/libx264.c里，我们可以利用libavcodec的基础设施，不需要也不应该像libavformat/avc.c一样啰嗦。

一开始我用ff_h264_decode_seq_parameter_set来解析SPS，好像没什么问题。但是Andreas Rheinhardt指出来一个非常隐蔽的漏洞：ff_h264_decode_seq_parameter_set处理的是移除了emulation prevention byte的码流，x264_encoder_headers输出的NAL可能带着emulation prevention byte，所以有可能出现解析错误。

emulation prevention byte的作用是防止出现假的start code。比如，如果NAL内的数据出现了0x000001，则在里面插入一个emulation prevention byte 0x03，变成0x00000301，这样就不会误当成start code了。解码的时候，需要把0x03剔除掉

James Almer提出了一个疑问，可能很多人也存在同样的误区：

emulation prevention byte是防止出现假的start code，avcc格式没有start code，所以avcc格式没有emulation prevention byte。

这是错误的，avcc格式也要使用emulation prevention byte。

考虑剔除emulation prevention byte再加上ff_h264_decode_seq_parameter_set的操作开销很大，而AVCDecoderConfigurationRecord里稍微复杂的解析只有chroma format和bit depth的解析，所以最后选择用libavcodec提供的golomb utils，手动从SPS里解出三个字段。

除了emulation prevention byte，还有个小问题被我忽略了。x264_encoder_headers除了输出SPS/PPS，还输出一个SEI，SEI里是x264版权信息和编码参数配置。这个信息是没法保留在AVCDecoderConfigurationRecord里的，需要单独拷贝出来，跟着后面的IDR帧一起输出。

到此为止，我们修复了libx264输出的extradata格式问题，以下命令生成正常的mp4文件

ffmpeg -i foo.mp4 \
  -c:a copy \
  -c:v libx264 \
  -x264-params "annexb=0" \
  -y bar.mp4

整个流程变成了 [x264]—avcc—>[avformat/movenc]—>mp4。

CPU占用能节省多少呢？和编码相比，微乎其微。内存占用的节省倒是能测出来，感兴趣的同学可以自己测测看。

6、遗留问题

最后遗留的一个问题是：为什么还需要手动设置-x264-params “annexb=0″，而不是自动的在需要的时候输出avcc格式呢？

从muxer到encoder，有一个AV_CODEC_FLAG_GLOBAL_HEADER flag。FFmpeg libx264.c里，当AV_CODEC_FLAG_GLOBAL_HEADER 开启时，输出out-of-band参数集。虽然常见的global header的mp4、mkv、flv都是要avcc格式，但global header和avcc没有强绑定关系，不能看到global header就开启avcc。

当前缺少让muxer通知encoder输出什么bitstream格式的机制，感兴趣的同学可以考虑实现这个功能。FFmpeg API用户可以根据媒体文件格式手动配置-x264-params “annexb=0″，基本也够用了。