h264 ES流文件通过计算first_mb_in_slice区分帧边界
本人因为近期在读取h264文件的时候,遇到怎样读取完整一帧数据的问题。通过使用elecard stream analyzer工具,以及结合《新一代视频压缩编码标准--H264/AVC》(第二版)书。并在网上查找总结例如以下:
首先NAL句法,片头句法以及nal_unit_type语义必须知道:
以上两图截自《新一代视频压缩编码标准--H264/AVC》(第二版)
简单的区分帧的方法就是读取文件的时候与0x00 0x00 0x00 0x01比較。假设相等觉得是一个片。再读取一个字节就相应表6.1的forbidden_zero_bit(1bit)。nal_ref_idc(2bit),nal_unit_type(5bit)。nal_unit_type值依据表6.20能够确定该帧类型,对于7,8是没有first_mb_in_slice,能够一直读到下一个0x00 0x00 0x00 0x01这之间的数据都是參数集数据。
对于1,5都是有first_mb_in_slice而且每一帧第一片的first_mb_in_slice都是0,这对于分成多片的一帧数据的获取是非常实用的。
以下是指数哥伦布码的解析:来自http://blog.csdn.net/simongyley/article/details/8517817
解析k阶指数哥伦布码时。首先从比特流的当前位置開始寻找第一个非零比特,并将找到的零比特个数记为leadingZeroBits,然后依据leadingZeroBits计算CodeNum。用伪代码描写叙述例如以下:
first_mb_in_slice是须要对h264通过ExpGolomb编码过的一串2进制数进行ExpGolomb解码得到。通过在网上多方查找并结合h264的文件分析,最终找到了计算方法,如今跟大家分享一下。有不正确的地方欢迎指正。
I帧情况:
例如以下图所看到的:
88 80 = 1000 1000 1000 0000 如果阶数为0,那么leadingZeroBits=0, CodeNum(first_mb_in_slice) = 1-1+0=0
06 62 = 0000 0110 0110 0010 如果阶数为0。那么LeadingZeroBits=5, CodeNum(first_mb_in_slice)=2EXP(5)-2EXP(0)+10011(2进制)=32-1+19=50
p帧情况:
例如以下图所看到的:
9A 00 = 1001 1010 0000 0000 如果阶数为0,那么leadingZeroBits=0, CodeNum(first_mb_in_slice) = 1-1+0=0
03 29 = 0000 0011 0010 1001 如果阶数为0,那么LeadingZeroBits=6, CodeNum(first_mb_in_slice)=2EXP(6)-2EXP(0)+100101(2进制)=64-1+37=100
事实上对于0阶而言,最简单的方法就是推断该字节第一个bit是否为1,假设是1。CodeNum(first_mb_in_slice),肯定为0,就是一帧的第一片。
原理讲解完成,希望对大家有所帮助。详细计算first_mb_in_slice的代码网上应该比較多,也能够參考ffmpeg的。
最新文章
- 【密码】Oracle用户密码系列
- if...else..的错误用法
- ODAC访问oracle时,提示:由于以前的函数求值超时,函数求值被禁用,必须继续执行才能正常返回
- 10670 Work Reduction (贪心 + 被题意坑了- -)y
- java基础(二十二)线程
- Linux下alias命令
- Spark Streaming实时写入数据到HBase
- java初级开发程序员(第六单元)
- Beta冲刺 第一天
- SpringCloud的服务注册中心(四)- 高可用服务注册中心的搭建
- [Zabbix3.0 ]添加Nginx监控
- 微信小程序用户信息解密失败导致的内存泄漏问题。
- MySQL--运维内参中的binlog_summary脚本
- HTML常用标签及属性
- CCPC-Wannafly Winter Camp Day4 Div1 - 咆咆咆哮 - [三分+贪心]
- VS相关设置
- Linux中Postfix基于SSL收发邮件(九)
- url重写(urlrewrite)的一些系统变量
- Java的Stream流
- 关于Mantis变更日志(Changelog)和路线图(Roadmap)的说明