在8K视频编解码特别是解码部分,我做了一些优化工作,转码速度提升了50%以上。专家们评价曰:“主要围绕算法并行度的优化,属于算法性能优化的常规手段,在创新性和技术难度方面的体现较为一般”。评价过于犀利,不服不行,可能专家们认为编解码提升并行度是多开几个线程的事。
好吧,那我换用另一种手段,叫“Don't taking off your pants to fart”,来做一个提升1‰的优化。读过唐诗的都知道,千是虚数,优化效果基本上被淹没在测试噪声中…
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",基本也够用了。
粉丝福利, 免费领取C++音视频学习资料包+学习路线大纲、技术视频/代码,内容包括(音视频开发,面试题,FFmpeg ,webRTC ,rtmp ,hls ,rtsp ,ffplay ,编解码,推拉流,srs)↓↓↓↓↓↓见下面↓↓文章底部点击免费领取↓↓