X264编码测试验证

之前在做一个rtsp直播需求，其中一个方案是要用的x264来对摄像头数据进行实时编码推流，摄像头帧率是25fps,为了验证方案的可行性，先对x264的编码速度进行一个测试研究，再确认是否要采用此方案。

我移植的x264是x264-snapshot-20180829-2245

作为实时流的编码有几个参数一定要注意

        x264_param_default(pParm);
.....................................
         pParam->b_repeat_headers = 1;  // 重复SPS/PPS 放到关键帧前面 保证播放不会解析错误
        pParam->rc.b_mb_tree=0;//不为0,将导致编码延时帧

bitrate设置为2M,第一次测试下来编码一分钟的yuv数据花了十多分钟,

然后一直吧bitrate降低到　200k编码还是需要花上超过一分钟，也就是编码速度大大大的低过摄像头数据产生速度，

后来上网搜索了对比了一遍各种参数发现有一个参数对编码速度是很有贡献的

设置如下，其中两个参数的解释参考h264.h文件解释

x264_param_default_default_preset(pParm,“ultrafast”,"zerolatency");

　　

/* x264_param_default_preset:
 *      The same as x264_param_default, but also use the passed preset and tune
 *      to modify the default settings.
 *      (either can be NULL, which implies no preset or no tune, respectively)
 *
 *      Currently available presets are, ordered from fastest to slowest: */
static const char * const x264_preset_names[] = { "ultrafast", "superfast", "veryfast", "faster", "fast", "medium", "slow", "s
lower", "veryslow", "placebo", 0 };

/*      The presets can also be indexed numerically, as in:
 *      x264_param_default_preset( &param, "3", ... )
 *      with ultrafast mapping to "0" and placebo mapping to "9".  This mapping may
 *      of course change if new presets are added in between, but will always be
 *      ordered from fastest to slowest.
 *
 *      Warning: the speed of these presets scales dramatically.  Ultrafast is a full
 *      100 times faster than placebo!
 *
 *      Currently available tunings are: */
static const char * const x264_tune_names[] = { "film", "animation", "grain", "stillimage", "psnr", "ssim", "fastdecode", "zer
olatency", 0 };

/*      Multiple tunings can be used if separated by a delimiter in ",./-+",
 *      however multiple psy tunings cannot be used.
 *      film, animation, grain, stillimage, psnr, and ssim are psy tunings.
 *
 *      returns 0 on success, negative on failure (e.g. invalid preset/tune name). */
int     x264_param_default_preset( x264_param_t *, const char *preset, const char *tune );

　　第二个参数可选参数如下，其中ultrafast的速度比placebo块100倍

 "ultrafast", "superfast", "veryfast", "faster", "fast", "medium", "slow", "s
lower", "veryslow", "placebo", 

于是修改之后在验证编码速度一分钟的yuv数据花费了大概65s的时间，但是还是没法满足我的需求，估计只能编码12fps的数据。
这样看来x264软编码的实时效率对于我目前的需求实现确实没什么价值，只能放弃此方案。

转载于:https://www.cnblogs.com/tid-think/p/10537515.html