總的來說H264的碼流的打包方式有兩種,一種為annex-b byte stream format的格式，這個是絕大部分編碼器的默認輸出格式，就是每個幀的開頭的3~4個字節是H264的start_code,0x00000001或者0x000001。
另一種是原始的NAL打包格式，就是開始的若干字節（1，2，4字節）是NAL的長度，而不是start_code,此時必須借助某個全局的數據來獲得編碼器的profile,level,PPS,SPS等信息才可以解碼。
時空互換(178316135) 10:17:08
rtp傳輸的是annexb的h264碼流
轉自http://blog.sina.com.cn/s/blog_442ae05d0100je8y.html
字節流格式（Annex B）和RTP格式流淺析
AnnexB格式：NALU數據+開始前綴（00000001或000001，此處注意為甚么是4bit或3bit，后面有描述）；針對H.320電話會議
RTP 格式：NALU數據+20個字節的類似的並不符合RTP協議的RTP頭。針對IP網絡的RTP打包方式
H.264協議只規定了字節流格式，沒有規定 RTP 格式。可能也是因為這個原因，JM 的 RTP 格式沒有被用到任何場合場合中，成為了擺設。下圖中的 RTP 格式是h.264樂園的firstime從 JM86 中分析出來的。實際包交換網絡中必須按照 RFC3984 將 NALU 數據封裝為 RTP 包，而不能使用 JM 的 RTP 格式。
下面引自“QUESTIONMARK”的博客
下面說明3字節起始碼和4字節起始碼。
以下和leading_zero_8bits、trailing_zero_8bits已無關系，忘掉。
if( next_bits( 24 ) != 0x000001 )
zero_byte f(8)
start_code_prefix_one_3bytes f(24)
根據B.1節，可以看到所謂的4字節起始碼是(zero_byte + 3字節起始碼)。那么看zero_byte的說明，就可以明白zero_byte什么時候出現，也就能明白什么時候出現4字節起始碼：
1. SPS、PPS nalu是4字節起始碼；
2. Access Unit的首個nalu是4字節起始碼（參見7.4.1.2.3）。
這里舉個例子說明，用JM可以生成這樣一段碼流（不要使用JM8.6，它在這部分與標准不符），這個碼流可以見本樓附件：
SPS （4字節頭）
PPS （4字節頭）
SEI （4字節頭）
I0(slice0) （4字節頭）
I0(slice1) （3字節頭）
P1(slice0) （4字節頭）
P1(slice1) （3字節頭）
P2(slice0) （4字節頭）
P2(slice1) （3字節頭）
I0(slice0)是序列第一幀（I幀）的第一個slice，是當前Access Unit的首個nalu，所以是4字節頭。而I0(slice1)表示第一幀的第二個slice，所以是3字節頭。P1(slice0) 、P1(slice1)同理。
總結：
1 附錄 B字節流在一個byte_stream_nal_unit的前后可能出現若干個0x00，僅用作填充之用。這個不常見。
2 4字節頭只出現在SPS、PPS和7.4.1.2.3規定的Access Unit的首個nalu。其余情況都是3字節頭
一共有兩種起始碼：3字節的0x000001和4字節的0x00000001
3字節的0x000001只有一種場合下使用，就是一個完整的幀被編為多個slice的時候，包含這些slice的nalu使用3字節起始碼。其余場合都是4字節的。
IDR幀屬於I幀，但是I幀不一定是IDR幀。解碼器收到IDR幀時，將驅動器參數塊（DPB）清空。而I幀不會。(我自己理解為即把參考幀列表刷新從新更新，就是不再參考idr前面的幀)由此可見，在編碼器端，每發一個IDR，就相應地發一個nal。當然在現在的編碼中，為了取得更高的圖像質量，在一個視頻文件中有好多個IDR幀，這些IDR幀把視頻文件分成了片，但是每片中第一個幀是IDR，而且僅此一個
例如：存在這樣一段視頻:
| 碼流 |
IDR |
B |
B |
P |
B |
B |
P |
…… |
| 幀號 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
…… |
對IDR幀的處理(與I幀的處理相同)：(1) 進行幀內預測，決定所采用的幀內預測模式。(2) 像素值減去預測值，得到殘差。(3) 對殘差進行變換和量化。(4) 變長編碼和算術編碼。(5) 重構圖像並濾波，得到的圖像作為其它幀的參考幀。
這里要提一下，當編碼器處理完IDR幀遇到B幀時，編碼期先把其放入緩存器中存放起來。直接對P進行編碼。即編碼器中編碼的實際順序是IDR P B B P B B…..即1423756……
有用的來了
IDR-instantaneous decoding refresh (IDR)picture;
A coded picture in which all slices are I or SI slices that causes the decoding process to mark all reference pictures as "unused for reference" immediately after decoding the IDR picture. After the decoding of an IDR picture all following coded pictures in decoding order can be decoded without inter prediction from any picture decoded prior to the IDR picture. The first picture of each coded video sequence is an IDR picture.
“也就是說,IDR的出現其實是相當於向解碼器發出了一個清理reference buffer的信號吧，上面說前於這一幀的所有已編碼幀不能為inter做參考幀了。”
還有：“因為264采用了多幀預測，就有可能在display order下I幀后的P會參考I幀前的幀，這樣在random access時如果只找I幀，隨后的幀的參考幀可能unavailable，IDR就是這樣一種特殊的I幀，把它定義為確保后面的P一定不參考其前面的幀，可以放心地random access。 ”
多參考幀情況下。
舉個例子：有如下幀序列：IPPPPIPPPP……（我們程序沒有B幀，所以幀序列簡單些，但道理是一樣的）。按照3個參考幀編碼。
因為“按照3個參考幀編碼”，所以參考幀隊列長度為3。
遇到綠色的I時，並不清空參考幀隊列，把這個I幀加入參考幀隊列（當然I編碼時不用參考幀。）。再檢測到紅色的P幀時，用到的就是PPI三幀做參考了。
不怕自己羅嗦（好記性不如爛筆頭），再強調一個：一個參考幀，就是參考當前幀的前面的那幀（因為沒涉及到B幀，所以“前面的那幀”既是播放順序的，也是編碼順序的）。多個參考幀是一個道理。（我以前一直誤解為從前面的幾幀中找到最合適的一個參考幀）
最后，“但是收到IDR幀時，解碼器另外需要做的工作就是：把所有的PPS和SPS參數進行更新。由此可見，在編碼器端，每發一個IDR，就相應地發一個 PPS&SPS_nal_unit”應該是對的吧。先這樣認為：）
0
頂
H.264起始碼
在網絡傳輸h264數據時，一個UDP包就是一個NALU,解碼器可以很方便的檢測出NAL分界和解碼。但是如果編碼數據存儲為一個文件，原來的解碼器將無法從數據流中分別出每個NAL的起始位置和終止位置，為此h.264用起始碼來解決這一問題。
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
附上h.264解碼nalu中檢測起始碼的算法流程
for(;;)
{
if next 24 bits are 0x000001
{
startCodeFound = true
break;
}
else
{
flush 8 bits
}
}// for(;;)
if(true == startCodeFound)
{
//startcode found
// Flush the start code found
flush 24 bits
//Now navigate up to next start code and put the in between stuff
// in the nal structure.
for(;;)
{
get next 24 bits & check if it equals to 0x000001
if(false == (next 24 bits == 000001))
{
// search for pattern 0x000000
check if next 24 bits are 0x000000
if(false == result)
{
// copy the byte into the buffer
copy one byte to the Nal unit
}
else
{
break;
}
}
else
{
break;
}
}//for(;;)
}
2. MPEG4起始碼
MPEG4的特色是VOP，沒有NALU的概念，仍使用startcode對每幀進行分界。MPEG4的起始碼是0x000001. 另外MPEG4中很多起始碼也很有用，比如video_object_sequence_start_code 0x000001B0 表示一個視頻對象序列的開始,VO_start_code 0x000001B6 表示一個VOP的開始. 0x000001B6之后的兩位，是00表示 I frame， 01 表示 P frame， 10 表示 B frame.
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的開始字節形成連續的起始碼競爭檢測;對一幀圖像的最后一個宏塊,先添加結尾停止比特,再檢測起始碼競爭。
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/threewells_14/archive/2007/02/12/1508657.aspx
typedef struct
{
int byte_pos; //!< current position in bitstream;
int bits_to_go; //!< current bitcounter
byte byte_buf; //!< current buffer for last written byte
int stored_byte_pos; //!< storage for position in bitstream;
int stored_bits_to_go; //!< storage for bitcounter
byte stored_byte_buf; //!< storage for buffer of last written byte
byte byte_buf_skip; //!< current buffer for last written byte
int byte_pos_skip; //!< storage for position in bitstream;
int bits_to_go_skip; //!< storage for bitcounter
byte *streamBuffer; //!< actual buffer for written bytes
int write_flag; //!< Bitstream contains data and needs to be written
} Bitstream; 定義比特流結構
static byte *NAL_Payload_buffer;
void SODBtoRBSP(Bitstream *currStream)
{
currStream->byte_buf <<= 1; //左移1bit
currStream->byte_buf |= 1; //在尾部填一個“1”占1bit
currStream->bits_to_go--;
currStream->byte_buf <<= currStream->bits_to_go;
currStream->streamBuffer[currStream->byte_pos++] = currStream->byte_buf;
currStream->bits_to_go = 8;
currStream->byte_buf = 0;
}
int RBSPtoEBSP(byte *streamBuffer, int begin_bytepos, int end_bytepos, int min_num_bytes)
{
int i, j, count;
for(i = begin_bytepos; i < end_bytepos; i++)
NAL_Payload_buffer[i] = streamBuffer[i];
count = 0;
j = begin_bytepos;
for(i = begin_bytepos; i < end_bytepos; i++)
{
if(count == ZEROBYTES_SHORTSTARTCODE && !(NAL_Payload_buffer[i] & 0xFC))
{
streamBuffer[j] = 0x03;
j++;
count = 0;
}
streamBuffer[j] = NAL_Payload_buffer[i];
if(NAL_Payload_buffer[i] == 0x00)
count++;
else
count = 0;
j++;
}
while (j < begin_bytepos+min_num_bytes) {
streamBuffer[j] = 0x00; // cabac stuffing word
streamBuffer[j+1] = 0x00;
streamBuffer[j+2] = 0x03;
j += 3;
stat->bit_use_stuffingBits[img->type]+=16;
}
return j;
}
在2010-6-9 15:33:33我又看到了別人博客上的一句話 更加深了我的理解 ，這里貼出來。感謝QuestionMark
標准 7.4.1.1 如是說：
This process can allow any SODB to be represented in a NAL unit while ensuring that
– ……
– no sequence of 8 zero-valued bits followed by a start code prefix, regardless of byte-alignment, is emulated within the NAL unit.
這段的意思是 在nal_unit層面，即nalu header+RBSP的結構中，不可能出現0x00 00 01這樣的片段。這是通過SODB->RBSP->EBSP的過程中添加防沖突字節實現的。這里多說一句
標准附錄 B 如是說：
any bytes equal to 0x00 that follow a NAL unit syntax structure and precede the four-byte sequence 0x00000001 (which is to be interpreted as a zero_byte followed by a start_code_prefix_one_3bytes) will be considered to be trailing_zero_8bits syntax elements that are part of the preceding byte stream NAL unit.
這一段則在說明byte_stream_nal_unit層面。結合B.1，可以明白這段話的意思是 一個nalu之后，下一個起始碼0x00000001之前，可能會有若干0x00，就是所謂的 trailing_zero_8bits。 此外B.1中還說明了在碼流的最開始，還有可能有若干0x00，就是所謂的leading_zero_8bits。這些 leading_zero_8bits和trailing_zero_8bits可能與傳輸打包有關，但在實際中，我沒有見過包含這種“多余”的0x00 的碼流。
//
Standards Track [Page 2] RFC 3984 RTP Payload Format for H.264 Video February 2005 1.
按照RFC3984協議實現H264視頻流媒體
nalu單元 包起始 0x 00 00 00 01
H．264 NAL格式及分析器
http://hi.baidu.com/zsw_davy/b ... c409cc7cd92ace.html
http://hi.baidu.com/zsw_davy/blo ... 081312c8fc7acc.html
----------------------------------比特流信息----------------------------------------------
①NALU(Network Abstract Layer Unit)：兩標准中的比特流都是以NAL為單位，每個NAL單元包含一個RBSP，NALU的頭信息定義了RBSP所屬類型。類型一般包括序列參數集 （SPS）、圖像參數集（PPS）、增強信息（SEI）、條帶（Slice）等，其中，SPS和PPS屬於參數集，兩標准采用參數集機制是為了將一些主要 的序列、圖像參數（解碼圖像尺寸、片組數、參考幀數、量化和濾波參數標記等）與其他參數分離，通過解碼器先解碼出來。此外，為了增強圖像的清晰 度，AVS-M添加了圖像頭（Picture head）信息。讀取NALU流程中，每個NALU前有一個起始碼0x000001，為防止 內部0x000001序列競爭，H.264編碼器在最后一字節前插入一個新的字節——0x03，所以解碼器檢測到該序列時，需將0x03刪掉，而AVS- M只需識別出起始碼0x000001。
②讀取宏塊類型（mb type）和宏塊編碼模板（cbp）：編解碼圖像以宏塊划分，一個宏塊由一個16*16亮度塊和相應的一個8*8cb和一個8*8cr色度塊組成。
(a) 兩標准的幀內、幀間預測時宏塊的划分是有區別的。H.264中，I_slice亮度塊有Intra_4*4和Intra_16*16兩種模式，色度塊只有 8*8模式；P_slice宏塊分為16*16、16*8、8*16、8*8、8*4、4*8、4*4共7種模式。而AVS-M中，I_slice亮度塊 有I_4*4和I_Direct兩模式，P_slice時宏塊的划分和H.264中的划分一致。
(b) 兩標准的宏塊cbp值計算也不相同。H.264中，Intra_16*16宏塊的亮度（色度）cbp直接通過讀mb type得到；非Intra_16*16宏塊的亮度cbp=coded_block_pattern，色度 cbp=coded_block_pattern/16 。其中，亮度cbp最低4位有效，每位決定對應宏塊的殘差系數能不能為0；色度cbp為0時，對應殘差系數為0，cbp為1時，DC殘差系數不為0，AC 系數為0，cbp為2時，DC、AC殘差系數都不為0。AVS-M中，當宏塊類型不是P_skip時，直接從碼流中得到cbp的索引值，並以此索引值查表 得到codenum值，再以codenum查表分別得到幀內／幀間cbp。此cbp為6位，每位代表宏塊按8*8划分時能不能包含非零系數，當變換系數不 為0時，需進一步讀cbp_4*4中每位值來判斷一個8*8塊中4個4*4塊的系數能不能為0。
---------------------------------------------------------------------------------------------
總的來說H264的碼流的打包方式有兩種,一種為annex-b byte stream format的格式，這個是絕大部分編碼器的默認輸出格式，就是每個幀的開頭的3~4個字節是H264的start_code,0x00000001或者0x000001。
另一種是原始的NAL打包格式，就是開始的若干字節（1，2，4字節）是NAL的長度，而不是start_code,此時必須借助某個全局的數據來獲得編碼器的profile,level,PPS,SPS等信息才可以解碼。
----------------------------------------------------------------------------
AVC vs. H.264
AVC and H.264 are synonymous. The standard is known by the full names "ISO/IEC 14496-10" and "ITU-T Recommendation H.264". In addition, a number of alternate names are used (or have been) in reference to this standard. These include:
MPEG-4 part 10
MPEG-4 AVC
AVC
MPEG-4 (in the broadcasting world MPEG4 part 2 is ignored)
H.264
JVT (Joint Video Team, nowadays rarely used referring to actual spec)
H.26L (early drafts went by this name)
All of the above (and those I've missed) include the Annex B byte-stream format. Unlike earlier MPEG1/2/4 and H.26x codecs, the H.264 specification proper does not define a full bit-stream syntax. It describes a number of NAL (Network Abstraction Layer) units, a sequence of which can be decoded into video frames. These NAL units have no boundary markers, and rely on some unspecified format to provide framing.
Annex B of of the document specifies one such format, which wraps NAL units in a format resembling a traditional MPEG video elementary stream, thus making it suitable for use with containers like MPEG PS/TS unable to provide the required framing. Other formats, such as ISO base media based formats, are able to properly separate the NAL units and do not need the Annex B wrapping.
The H.264 spec suffers from a deficiency. It defines several header-type NAL units (SPS and PPS) without specifying how to pack them into the single codec data field available in most containers. Fortunately, most containers seem to have adopted the packing used by the ISO format known as MP4.
1. H.264起始碼
在網絡傳輸h264數據時，一個UDP包就是一個NALU,解碼器可以很方便的檢測出NAL分界和解碼。但是如果編碼數據存儲為一個文件，原來的解碼器將無法從數據流中分別出每個NAL的起始位置和終止位置，為此h.264用起始碼來解決這一問題。
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
附上h.264解碼nalu中檢測起始碼的算法流程
for(;;)
{
if next 24 bits are 0x000001
{
startCodeFound = true
break;
}
else
{
flush 8 bits
}
}// for(;;)
if(true == startCodeFound)
{
//startcode found
// Flush the start code found
flush 24 bits
//Now navigate up to next start code and put the in between stuff
// in the nal structure.
for(;;)
{
get next 24 bits & check if it equals to 0x000001
if(false == (next 24 bits == 000001))
{
// search for pattern 0x000000
check if next 24 bits are 0x000000
if(false == result)
{
// copy the byte into the buffer
copy one byte to the Nal unit
}
else
{
break;
}
}
else
{
break;
}
}//for(;;)
}
2. MPEG4起始碼
MPEG4的特色是VOP，沒有NALU的概念，仍使用startcode對每幀進行分界。MPEG4的起始碼是0x000001. 另外MPEG4中很多起始碼也很有用，比如video_object_sequence_start_code 0x000001B0 表示一個視頻對象序列的開始,VO_start_code 0x000001B6 表示一個VOP的開始. 0x000001B6之后的兩位，是00表示 I frame， 01 表示 P frame， 10 表示 B frame.
1．引言
H.264的主要目標：
1．高的視頻壓縮比
2．良好的網絡親和性
解決方案：
VCL video coding layer 視頻編碼層
NAL network abstraction layer 網絡提取層
VCL：核心算法引擎，塊，宏塊及片的語法級別的定義
NAL：片級以上的語法級別（如序列參數集和圖像參數集），同時支持以下功能：獨立片解碼，起始碼唯一保證，SEI以及流格式編碼數據傳送
VCL設計目標：盡可能地獨立於網絡的情況下進行高效的編解碼
NAL設計目標：根據不同的網絡把數據打包成相應的格式，將VCL產生的比特字符串適配到各種各樣的網絡和多元環境中。
NALU頭結構：NALU類型(5bit)、重要性指示位(2bit)、禁止位(1bit)。
NALU類型：1～12由H.264使用，24～31由H.264以外的應用使用。
重要性指示：標志該NAL單元用於重建時的重要性，值越大，越重要。
禁止位：網絡發現NAL單元有比特錯誤時可設置該比特為1，以便接收方丟掉該單元。
2．NAL語法語義
NAL層句法：
在編碼器輸出的碼流中，數據的基本單元是句法元素。
句法表征句法元素的組織結構。
語義闡述句法元素的具體含義。
分組都有頭部，解碼器可以很方便的檢測出NAL的分界，依次取出NAL進行解碼。
但為了節省碼流，H.264沒有另外在NAL的頭部設立表示起始位置的句法元素。
如果編碼數據是存儲在介質上的，由於NAL是依次緊密相連的，解碼器就無法在數據流中分辨出每個NAL的起始位置和終止位置。
解決方案：在每個NAL前添加起始碼：0X000001
在某些類型的介質上，為了尋址的方便，要求數據流在長度上對齊，或某個常數的整數倍。所以在起始碼前添加若干字節的0來填充。
檢測NAL的開始：
0X000001和0X000000
我們必須考慮當NAL內部出現了0X000001和0X000000
解決方案：
H.264提出了“防止競爭”機制：
0X000000——0X00000300
0X000001——0X00000301
0X000002——0X00000302
0X000003——0X00000303
為此，我們可以知道：
在NAL單元中，下面的三字節序列不應在任何字節對齊的位置出現
0X000000
0X000001
0X000002
Forbidden_zero_bit =0;
Nal_ref_idc：表示NAL的優先級。0～3，取值越大，表示當前NAL越重要，需要優先受到保護。如果當前NAL是屬於參考幀的片，或是序列參數集，或是圖像參數集這些重要的單位時，本句法元素必需大於0。
Nal_unit_type：當前NAL 單元的類型
3．H.264的NAL層處理
結構示意圖：
NAL以NALU（NAL unit）為單元來支持編碼數據在基於分組交換技術網絡中傳輸。
它定義了符合傳輸層或存儲介質要求的數據格式，同時給出頭信息，從而提供了視頻編碼和外部世界的接口。
NALU：定義了可用於基於分組和基於比特流系統的基本格式
RTP封裝：只針對基於NAL單元的本地NAL接口。
三種不同的數據形式：
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去掉。 也稱為脫殼操作
處理過程：
1． 將VCL層輸出的SODB封裝成nal_unit， Nal_unit是一個通用封裝格式，可以適用於有序字節流方式和IP包交換方式。
2． 針對不同的傳送網絡（電路交換|包交換），將nal_unit 封裝成針對不同網絡的封裝格 式。
第一步的具體過程：
VCL層輸出的比特流SODB（String Of Data Bits），到nal_unit之間，經過了以下三步處理：
1.SODB字節對齊處理后封裝成RBSP（Raw Byte Sequence Payload）。
2. 為防止RBSP的字節流與有序字節流傳送方式下的SCP（start_code_prefix_one_3bytes，0x000001）出現字節競爭情 形，循環檢測RBSP前三個字節，在出現字節競爭時在第三字節前加入emulation_prevention_three_byte （0x03），具體方法：
nal_unit( NumBytesInNALunit ) {
forbidden_zero_bit
nal_ref_idc
nal_unit_type
NumBytesInRBSP = 0
for( i = 1; i < NumBytesInNALunit; i++ ) {
if( i + 2 < NumBytesInNALunit && next_bits( 24 ) = = 0x000003 ) {
rbsp_byte[ NumBytesInRBSP++ ]
rbsp_byte[ NumBytesInRBSP++ ]
i += 2
emulation_prevention_three_byte
} else
rbsp_byte[ NumBytesInRBSP++ ]
}
}
3. 防字節競爭處理后的RBSP再加一個字節的header(forbidden_zero_bit+ nal_ref_idc+ nal_unit_type)，封裝成nal_unit.
第二步的具體過程：
case1：有序字節流的封裝
byte_stream_nal_unit( NumBytesInNALunit ) {
while( next_bits( 24 ) != 0x000001 )
zero_byte
if( more_data_in_byte_stream( ) ) {
start_code_prefix_one_3bytes nal_unit( NumBytesInNALunit )
}
}
類 似H.320和MPEG-2/H.222.0等傳輸系統，傳輸NAL作為有序連續字節或比特流，同時要依靠數據本身識別NAL單元邊界。在這樣的應用系統 中，H.264/AVC規范定義了字節流格式，每個NAL單元前面增加3個字節的前綴，即同步字節。在比特流應用中，每個圖像需要增加一個附加字節作為邊 界定位。還有一種可選特性，在字節流中增加附加數據，用做擴充發送數據量，能實現快速邊界定位，恢復同步
Case2：IP網絡的RTP打包封裝
分組打包的規則
(1)額外開銷要少，使MTU尺寸在100～64k字節范圍都可以；
(2)不用對分組內的數據解碼就可以判別該分組的重要性；
(3)載荷規范應當保證不用解碼就可識別由於其他的比特丟失而造成的分組不可解碼；
(4)支持將NALU分割成多個RTP分組；
(5)支持將多個NALU匯集在一個RTP分組中。
RTP的頭標可以是NALU的頭標，並可以實現以上的打包規則。
一 個RTP分組里放入一個NALU，將NALU(包括同時作為載荷頭標的NALU頭)放入RTP的載荷中，設置RTP頭標值。為了避免IP層對大分組的再一 次分割，片分組的大小一般都要小於MTU尺寸。由於包傳送的路徑不同，解碼端要重新對片分組排序，RTP包含的次序信息可以用來解決這一問題。
NALU分割
對 於預先已經編碼的內容，NALU可能大於MTU尺寸的限制。雖然IP層的分割可以使數據塊小於64千字節，但無法在應用層實現保護，從而降低了非等重保護 方案的效果。由於UDP數據包小於64千字節，而且一個片的長度對某些應用場合來說太小，所以應用層打包是RTP打包方案的一部分。
新的討論方案(IETF)應當符合以下特征：
(1)NALU的分塊以按RTP次序號升序傳輸；
(2)能夠標記第一個和最后一個NALU分塊；
(3)可以檢測丟失的分塊。
NALU合並
一些NALU如SEI、參數集等非常小，將它們合並在一起有利於減少頭標開銷。已有兩種集合分組：
(1)單一時間集合分組(STAP)，按時間戳進行組合；
(2)多時間集合分組(MTAP)，不同時間戳也可以組合。
NAL規范視頻數據的格式，主要是提供頭部信息，以適合各種媒體的傳輸和存儲。NAL支持各種網絡，包括：
1．任何使用RTP/IP協議的實時有線和無線Internet 服務
2．作為MP4文件存儲和多媒體信息文件服務
3．MPEG-2系統
4．其它網
NAL規定一種通用的格式，既適合面向包傳輸，也適合流傳送。實際上，包傳輸和流傳輸的方式是相同的，不同之處是傳輸前面增加了一個起始碼前綴
在類似Internet/RTP面向包傳送協議系統中，包結構中包含包邊界識別字節，在這種情況下，不需要同步字節。
NAL單元分為VCL和非VCL兩種
VCL NAL單元包含視頻圖像采樣信息，
非VCL包含各種有關的附加信息，例如參數集（頭部信息，應用到大量的VCL NAL單元）、提高性能的附加信息、定時信息等
參數集：
參數集是很少變化的信息，用於大量VCL NAL單元的解碼，分為兩種類型：
1．序列參數集，作用於一串連續的視頻圖像，即視頻序列。
兩個IDR圖像之間為序列參數集。IDR和I幀的區別見下面。
2． 圖像參數集，作用於視頻序列中的一個或多個個別的圖像
序列和圖像參數集機制，減少了重復參數的傳送，每個VCL NAL單元包含一個標識，指
向有關的圖像參數集，每個圖像參數集包含一個標識，指向有關的序列參數集的內容
因此，只用少數的指針信息，引用大量的參數，大大減少每個VCL NAL單元重復傳送的信息。
序列和圖像參數集可以在發送VCL NAL單元以前發送，並且重復傳送，大大提高糾錯能力。序列和圖像參數集可以在“帶內”，也可以用更為可靠的其他“帶外”通道傳送。