h264使用rtp傳輸時，以sps和pps開頭，如下圖：
h264幀由nalu頭和nalu載荷構成，以sps為例如下圖：
5 idr影象中的片
6 補充增強資訊單元（sei）
7 sps
8 pps
9 序列結束
10 序列結束
上圖中sps的nalu頭中的type值為7，表示sps(sequence parameter set)，sps還包含一些影象編碼的一些重要配置資訊，比如profile_id，level_id，影象的寬高資訊等，具體如下圖：
如果一幀資料過大，將被分為多個片，即有多個slice組成，如下圖：
h.264編碼時，在每個nal前新增起始碼 0x000001，解碼器在碼流中檢測到起始碼，當前nal結束。為了防止nal內部出現0x000001的資料，h.264又提出'防止競爭 emulation prevention"機制，在編碼完乙個nal時，如果檢測出有連續兩個0x00位元組，就在後面插入乙個0x03。當解碼器在nal內部檢測到0x000003的資料，就把0x03拋棄，恢復原始資料。
0x000000 -----------> 0x00000300
0x000001 -----------> 0x00000301
0x000002 -----------> 0x00000302
0x000003 -----------> 0x00000303
總的來說，h264的碼流的打包方式有兩種,一種為annex-b byte stream format 的格式，這個是絕大部分編碼器的預設輸出格式，就是每個幀的開頭的3~4個位元組是h264的start_code,0x00000001或者0x000001；另一種是原始的nal打包格式，就是開始的若干位元組（1，2，4位元組）是nal的長度，而不是start_code,此時必須借助某個全域性的資料來獲得編 碼器的profile,level,pps,sps等資訊才可以解碼。
RTP封裝H264詳解
nalu buff nal資料buff len nal資料長度 cnt 包數 max fu size 每包長度，一般1400 nalu type nal型別 cnt len max fu size 0 len max fu size len max fu size 1 nalu type buff ...
linphone中h264的 RTP打包 二
html view plain copy 今天發現乙個奇怪的問題，用上位機的linphone客戶端撥打下位機的sip客戶端能夠正常工作，但是反過來就出問題了。抓包發現linphone傳送了大量的ip fragmentation 資料報，google才知道，當發現的資料大於mtu時就發產生ip分片的資...
對H264進行RTP封包原理
1.引言 2.rtp 協議關鍵引數的設定 其中比較關鍵的引數設定解釋如下 1 標示位 m 1 位，該標示位的含義一般由具體的 應用框架 profile 定義，目的在於標記處rtp 流中的重要事件。3 序號 16 位，每傳送乙個 rtp 資料報，序號加 1。接受者可以用它來檢測分組丟失和恢復分組順序。...