webrtc中的h264解析

H264的码流解析，网上有很多开源文件；

一般的解析有： 获取NALU，sps，pps，NALU type，slice type，获取Qp等；

可以通过C++的位运算实现获取计算，但是一般可以定义结构体直接获取；

这里要说的是webrtc中的H264解析相关：

在webrtc中，关于H264的相关源码文件在：webrtc58\src\webrtc\common_video\h264中；

都包含了很好的函数：

h264_bitstream_parser.h；

h264_common.h；

pps_parser.h；

sps_parser.h；

profile_level_id.h；

比较全，具体可自行查看，比较简单；

普及一些简单知识：

《h.264 SODB RBSP EBSP的区别》

from：http://blog.csdn.net/threewells_14/article/details/1508657

SODB　数据比特串－－＞最原始的编码数据

RBSP　原始字节序列载荷－－＞在SODB的后面填加了结尾比特（RBSP trailing bits　一个bit“1”）若干比特“0”,以便字节对齐。

EBSP　扩展字节序列载荷-->在RBSP基础上填加了仿校验字节（0X03）它的原因是：　在NALU加到Annexb上时，需要填加每组NALU之前的开始码StartCodePrefix,如果该NALU对应的slice为一帧的开始则用4位字节表示，ox00000001,否则用3位字节表示ox000001.为了使NALU主体中不包括与开始码相冲突的，在编码时，每遇到两个字节连续为0，就插入一个字节的0x03。解码时将0x03去掉。也称为脱壳操作。

 

网上查询的区别：

在对整帧图像的数据比特串(SODB)添加原始字节序列载荷(RBSP)结尾比特(RBSP trailing bits,添加一比特的“1”和若干比特“0”,以便字节对齐)后,再检查RBSP 中是否存在连续的三字节“00000000 00000000 000000xx”;若存在这种连续的三字节码,在第三字节前插入一字节的“0×03”,以免与起始码竞争,形成EBSP码流,这需要将近两倍的整帧图像码流大小。为了减小存储器需求,在每个宏块编码结束后即检查该宏块SODB中的起始码竞争问题,并保留SODB最后两字节的零字节个数,以便与下一宏块的SODB的开始字节形成连续的起始码竞争检测;对一帧图像的最后一个宏块,先添加结尾停止比特,再检测起始码竞争。