x264编码demo定制修改介绍

  x264编码器,提供了两个demo来验证编码功能:一个是大而全的x264.c,另外一个是简洁版的example.c。

  其中,前者demo,可以配置很多编码参数,但太冗长繁杂,对初学者不太友好。

   后者demo,大多参数都已hard code,用户仅需调整width、height、color_space信息即可,阅读起来比较easy。

  但是存在一个问题,默认输入/输出文件是stdin/stdout,这怎么能行?因此修改了一版来方便大家使用。已上传至这儿

  修改部分需要做几点说明:

1. sps/pps头补加方式:param.b_repeat_headers

  原生方式,在每个关键帧前编码器都会自动增加该头信息(因为设置值为1)。而实际上,一般编码参数配置了后(不需送yuv帧),

就可以出该csd(Codec Specific Data,对于h264为sps/pps)数据了,不需每个关键帧前都加该头信息,因此我将该值修改为了0。

2. 基于1的修改,需要增加特定接口获得csd数据。

  该特定接口函数为x264_encoder_headers(h,&nal,&i_nal),打开编码器后,直接调用该接口就可以获得csd数据。

针对该接口,需要补充说明一点,函数返回后i_nal值代表多少个nalu单元,这里的值是3,即SPS+PPS+SEI共三种类型。

3. profile级别设定:x264_param_apply_profile

  原生profile为“high”,其实我比较排斥B帧,因此修改为了baseline,因为规范中只有该profile不带B帧。

4. 固定关键帧间隔 or 根据场景自动生成

  原生方式为根据场景变换来生成一个关键帧,因此什么时候来KeyFrame是不确定的。其实,这种方式有其很强的合理性。

  什么场景使用x264编码器?一般是视频剪辑,而不是像具体手持设备实时编码场景(场景画面变化是物理连续、渐进的),

  因此,常常会出现场景切换,这个时候最合理的方案是切换后的第一帧,编码为关键帧,当然前提条件是需要一定算法去检测到场景变化了!

  而我的需求是:需要出固定关键帧间隔!怎么做呢?编码参数进行如下配置:

1 param.i_keyint_max = 25;
2 
3 param.i_keyint_min = 25;

  然而,这样做起作用了吗?

  答案可能不是那么干脆利索,不能简单用“是”或“否”来回答,只能用“几乎是”,呵呵。。。

  详细说来,如果图像帧序列画风比较平稳,没有大变天,那么就会按照25的关键帧间隔编码;

  而如果遇到画风大变,就会智能地编出关键帧,然后以该帧为起点再按25的关键帧间隔出帧,直到下一次画风大变。

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


一年前写了一个demo,用于生成几种标准的波形,如正弦波、方波、三角波。之前写的只有这几个功能:波形/通道/时长/频率的控制选择,这几天抽了些时间又加了增益控制功能。为了避免东西丢失或意外删除,特上传
wav文件格式作为一种常用的多媒体音频文件格式,其由MS在1991年8月在Windows 3.1上推出,文件扩展名为WAV,是WaveFom的简写。通常存储未压缩的pcm数据,也可存储压缩的pcm数据
mpeg2ts文件格式中有pcr和pts的概念,其代码含义如下: PCR(Program Clock Reference)——指示系统时钟本身的瞬时值的时间标签称为节目参考时钟标签(PCR)。 PTS
我的月经贴博客该更新了!!!已经有许多博文需要补了! 去年开始的jpeg解码项目,中间停止更新了大半年时间,上个月想起这事还没完工,就又做了更多兼容性和性能上的改进,目前终于接近尾声了。有需要参考的可
花了两天时间做了个h264裸流nal类型和frame类型检测的工具,已上传至github,有需要的自行下载(其中包含构建出来的可执行文件exe)。 1.NAL类型检测 nal类型检测非常容易,对照下表
随着工作业务的开展,对视频编解码的理解更加深入了一些,记录一些心得体会,以便后面回味。 某天突然有个好的想法略过心头,可以形象的向别人介绍视频编码和解码。 1.编解码像一场考试,编码就像做主观题,解码
承接昨天写的《JPEG软解码实现介绍》,今天介绍其使用方法和一些细节说明。 1.仓库下已经包含了几个jpeg文件,以方便直接校验。 2.使用命令分为两种模式。 一种是直接解码为yuv文件,另外一种是解
x264编码器,提供了两个demo来验证编码功能:一个是大而全的x264.c,另外一个是简洁版的example.c。 其中,前者demo,可以配置很多编码参数,但太冗长繁杂,对初学者不太友好。 后者d
本博文为概览性介绍。后面有空了再分几篇博文分别介绍所用到的技术细节。 1.编解码目标 编码和解码是个逆过程。jpeg编码的目的在于图形去冗余,进行数据压缩,解码的目的在于还原图像,使能够进行预览。 2
今天使用公司开发手机,调研一下当下很火的抖音客户端,其使用的视频编码类型。 在调研前,有个初步判断: 1.从抖音服务器推送到客户端的视频流要么是avc码流,要么是hevc码流(具体要视平台解码硬件支持
最近对抖音有点上瘾,经常看到这样的视频列表: 由于抖音平台的限制,用户最多只能上传60s的视频,因此分段为3个视频。而在视频列表的缩略图模式下,三个视频的封面恰好组合成一张图像。这种方式比较符合审美标
自己在学习h264的路上,欢迎讨论交流。 前段时间研究JM出品的h264编码器,代码实在看不下去,因此换了个角度来研究诸多算法——逆向方式(解码),本系列文章记录一些遇到的东西和思考。 1. JM介绍
h264裸码流,根据nalu_header可以知道类型,例如该帧是I帧,P帧/B帧。 例如,常见的0x65代表I帧,0x41代表非关键帧,即P帧或B帧,但是只根据nalu_header是无法区分P帧和