x264编码延时研究

研究了一下x264编码延时.

方法是加log在x264.c

static int encode( x264_param_t *param, cli_opt_t *opt )

{

...

i_frame_size = encode_frame( h, opt->hout, &pic, &last_dts );

if( i_frame_size == 0)   // delay frames

fprintf( stderr, "output zero %d\n", i_frame );

...

}

统计了一下,发现x264编码延时帧数符合下面的公式。

h->frames.i_delay =

param->i_sync_lookahead +                        // 前向考虑帧数

max ( param->i_bframe,                               // B帧数量

param->rc.i_lookahead)  +                 // 码率控制前向考虑帧数

param->i_threads - 1.                                  // 并行编码帧数

延迟有两种:

1.编码前延时(当前帧没有编码,需要buffer更多帧后才能开始编码)。

这种延时出口在 encoder.c,  x264_encoder_encode函数

...

if( h->frames.i_input <= h->frames.i_delay + 1 - h->i_thread_frames )

{

/* Nothing yet to encode, waiting for filling of buffers */

pic_out->i_type = X264_TYPE_AUTO;

return 0;

}

...

i_sync_lookahead, i_bframe, rc.i_lookahead 都会在此影响延时。

2. 编码后延时(当前帧已经编码,但后续帧还没编码,只好先退出)。

这种延时出口在 encoder.c,  x264_encoder_frame_end函数

if( !h->out.i_nal )

{

pic_out->i_type = X264_TYPE_AUTO;

return 0;

}

这部分延时是因为x264并行帧编码引起的。

x264并行帧编码每一次都是把一个帧组(i_threads个并行处理帧)处理完后,再处理下一个帧组。

根据公式看到减少帧延时的方法,也就是(zerolatency 设置)

param->rc.i_lookahead = 0;

param->i_sync_lookahead = 0;

param->i_bframe = 0;

param->b_sliced_threads = 1;

param->b_vfr_input = 0;

param->rc.b_mb_tree = 0;

这个设置h->frames.i_delay = 0。但其中param->b_sliced_threads = 1  的设置值得怀疑。

当b_sliced_threads = 1时,x264放弃帧并行编码,这必然会影响编码速度。

一个折中的办法是设置b_sliced_threads = 0,其他按照zerolatency 设置。

这样h->frames.i_delay = param->i_threads - 1。

x264根据CPU自动计算i_threads,一般为6/8. 这样的帧群延迟大概是1/3-1/2秒。

看具体系统的需要能否满足。

这样看x264并行帧编码写的还不是很自适应。

如果能够让i_threads在编码起始阶段随着输入帧数的增加而增加,那样就可以彻底解决编码群延时的问题了。

个人想法,未经验证,欢迎指正。

时间: 2024-10-10 16:30:35

x264编码延时研究的相关文章

WebRTC VideoEngine超详细教程(三)——集成X264编码和ffmpeg解码

总述 在前一篇文章中,讲解了如何将OPENH264编解码器集成到WebRTC中,但是OPENH264只能编码baseline的H264视频,而且就编码质量而言,还是X264最好,本文就来讲解一下如何将X264编码器集成到WebRTC中,为了实现解码,同时要用到ffmpeg.总体流程和之前一样,分为重新封装编解码器和注册调用两大步骤,注册调用这一步没有任何不同,主要是重新封装这一步骤有较大区别. 重新封装X264编码功能 首先当然还是要下载X264源码编译出相应的库以供调用.在windows下使用

视频x264编码浅析

声明 x264_param_t 结构体变量: x264_param_t params; x264_param_default_preset(&params, "ultrafast", "zerolatency");//优化编码延迟? 变量参数编码前赋值: params.i_csp = (csp == 17) ? X264_CSP_NV12 : csp;//编码比特流的CSP,仅支持i420,色彩空间设置 #ifdef SQUARE_AND_ROTATE pa

python的编码问题研究------使用scrapy体验

python转码译码 *:first-child { margin-top: 0 !important; } body>*:last-child { margin-bottom: 0 !important; } /* BLOCKS =============================================================================*/ p, blockquote, ul, ol, dl, table, pre { margin: 15px 0

X264编码流程详解(转)

http://blog.csdn.net/xingyu19871124/article/details/7671634 对H.264编码标准一直停留在理解原理的基础上,对于一个实际投入使用的编码器是如何构建起来一直感觉很神秘,于是决定在理解理论的基础上潜心于编码器实现框架.关于开源的H264编码器有很多,JMVC,T264.X264,这里选择X264,因为网上关于X264源码分析资源很多.X264编码器是一个开源的经过优化的高性能H.264编码器,目前最新的源码在本人的I5处理器的PC机上,编码

X264编码实现

H264 H264的官方测试源码,由德国hhi研究所负责开发.特点:实现了264所有的特性,由于是官方的测试源码,所以学术研究的算法都是在JM基础上实现并和JM进行比较.但其程序结构冗长,只考虑引入各种新特性以提高编码性能,忽视了编码复杂度,其编码复杂度极高,不宜实用.X264 网上自由组织联合开发的兼容264标准码流的编码器,创始人是一个法国人.X264在网上的口碑极佳.特点:注重实用.和JM相比,在不明显降低编码性能的前提下,努力降低编码的计算复杂度,故X264摈弃了264中一些对编码性能贡

WebGIS中GeoHash编码的研究和扩展

1.背景 1.1普通地理编码流程 将采集的POI入库后,数据库里保存有该POI的位置描述.X.Y等信息.当需要进行逆编码查询时,前端传入坐标的X.Y值,后台构建查询范围查询,并且对查询出来的值进行距离排序. 1.2普通地理编码的几点劣势 a.前端查询url中的X.Y值为真实值,可能会暴露相关真实信息. b.前端查询的url因为X.Y值的长度而变得比较长. c.后台中,需要同时对X列.Y列做查询判断. d.因为传入的X.Y值总在变化,数据库中的查询很难进行缓存优化. e.数据库中保存的是真实X.Y

x264 编码数配置

记录项目中用到一组x264快速编码参数配置,具体如下: param->i_frame_reference = 1; param->i_scenecut_threshold = 0; param->b_deblocking_filter = 0; param->b_cabac = 0; param->i_bframe = 0; param->analyse.intra = 0; param->analyse.inter = 0; param->analyse.

用X264编码以后的H264数据

输入的数据准备好了,编码后的数据都在x264_nal_t的数组.我这里设置的参数是Baseline Profile,所以编码后没有B帧,将编码后的数据保存分析后发现,第一次编码的时候会有4个NAl,分别是SPS.PPS.SEI.I帧,也即分别是00 00 00 01 67. 00 00 00 01 68. 00 00  01 06.00 00 01 65开头的四个数据段,这里注意的是SEI和I帧的开头貌似X264中就是00 00 01的起始头了,应该是和源码中这样写的关系,不过没有什么大碍,就是

ffmpeg,X264编码结果I帧QP比P帧还大

enc_ctx->profile =FF_PROFILE_H264_MAIN ; enc_ctx->time_base.den = 24; enc_ctx->time_base.num = 1; enc_ctx->gop_size = 8; /* emit one intra frame every twelve frames at most */ enc_ctx->pix_fmt = AV_PIX_FMT_YUV420P; enc_ctx->max_b_frames