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的開始位元組形成連續的起始碼競爭檢測;對一幀影象的最後一個巨集塊,先新增結尾停止位元