|
Nal頭
|
EBSP
|
Nal頭
|
EBSP
|
Nal頭
|
EBSP
|
每個NAL單元是一個一定語法元素的可變長字節字符串，包括包含一個字節的頭信息（用來表示數據類型），以及若干整數字節的負荷數據。
（1）NALU類型位可以表示NALU的32種不同類型特徵，類型1～12是H.264定義的，類型24～31是用於H.264以外的，RTP負荷規範使用這其中的一些值來定義包聚合和分裂，其他值爲H.264保留。
（2）重要性指示位
用於在重構過程中標記一個NAL單元的重要性，值越大，越重要。值爲0表示這個NAL單元沒有用於預測，因此可被解碼器拋棄而不會有錯誤擴散；值高於0表示此NAL單元要用於無漂移重構，且值越高，對此NAL單元丟失的影響越大。
（3）禁止位
編碼中默認值爲0，當網絡識別此單元中存在比特錯誤時，可將其設爲 1，以便接收方丟掉該單元，主要用於適應不同種類的網絡環境（比如有線無線相結合的環境）。例如對於從無線到有線的網關，一邊是無線的非IP環境，一邊是有線網絡的無比特錯誤的環境。假設一個NAL單元到達無線那邊時，校驗和檢測失敗，網關可以選擇從NAL流中去掉這個NAL單元，也可以把已知被破壞的 NAL單元前傳給接收端。在這種情況下，智能的解碼器將嘗試重構這個NAL單元（已知它可能包含比特錯誤）。而非智能的解碼器將簡單地拋棄這個NAL單 元。NAL單元結構規定了用於面向分組或用於流的傳輸子系統的通用格式。在H.320和MPEG-2系統中，NAL單元的流應該在NAL單元邊界內，每個 NAL單元前加一個3字節的起始前綴碼。在分組傳輸系統中，NAL單元由系統的傳輸規程確定幀界，因此不需要上述的起始前綴碼。一組NAL單元被稱爲一個 接入單元，定界後加上定時信息（SEI），形成基本編碼圖像。該基本編碼圖像（PCP）由一組已編碼的NAL單元組成，其後是冗餘編碼圖像（RCP），它 是PCP同一視頻圖像的冗餘表示，用於解碼中PCP丟失情況下恢復信息。如果該編碼視頻圖像是編碼視頻序列的最後一幅圖像，應出現序列NAL單元的 end，表示該序列結束。一個圖像序列只有一個序列參數組，並被獨立解碼。如果該編碼圖像是整個NAL單元流的最後一幅圖像，則應出現流的end。
處理過程：
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 /* equal to 0x03 */
} 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 /* equal to 0x00 */
if( more_data_in_byte_stream( ) ) {
start_code_prefix_one_3bytes /* equal to 0x000001 */ 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單元以前發送，並且重複傳送，大大提高糾錯能力。序列和圖像參數集可以在“帶內”，也可以用更爲可靠的其他“帶外”通道傳送。
存儲單元：
一組指定格式的NAL單元稱爲存儲單元，每個存儲單元對應一個圖像。每個存儲單元包含一組VCL NAL單元，組成一個主編碼圖像，VCL NAL單元由表示視頻圖像採樣的像條所組成。存儲單元前面可以加一個前綴，分界存儲單元，附加增強信息（SEI）（如圖像定時信息）也可以放在主編碼圖像的前面。主編碼圖像後附加的VCL NAL單元，包含同一圖像的冗餘表示，稱爲冗餘編碼圖像，當主編碼圖像數據丟失或損壞時，可用冗餘編碼圖像解碼。
編碼視頻序列
一個編碼視頻序列由一串連續的存儲單元組成，使用同一序列參數集。每個視頻序列可獨立解碼。編碼序列的開始是即時刷新存儲單元（IDR）。IDR是一個I幀圖像，表示後面的圖像不用參考以前的圖像。一個NAL單元流可包含一個或更多的編碼視頻序列。
RTP協議：
實時傳輸協議（Real-time Transport Protocol，RTP）是在Internet上處理多媒體數據流的一種網絡協議，利用它能夠在一對一（單播）或者一對多（multicast，多播）的網絡環境中實現傳流媒體數據的實時傳輸。RTP通常使用UDP來進行多媒體數據的傳輸，但如果需要的話可以使用TCP或者ATM等其它協議，整個RTP協議由兩個密切相關的部分組成：RTP數據協議和RTP控制協議。實時流協議（Real Time Streaming Protocol， RTSP）最早由Real Networks和Netscape公司共同提出，它位於RTP和RTCP之上，其目的是希望通過IP網絡有效地傳輸多媒體數據。
RTP數據協議
RTP數據協議負責對流媒體數據進行封包並實現媒體流的實時傳輸，每一個RTP數據報都由頭部（Header）和負載（Payload）兩個部分組成，其中頭部前12個字節的含義是固定的，而負載則可以是音頻或者視頻數據。RTP數據報的頭部格式如圖1所示：
其中比較重要的幾個域及其意義如下：
CSRC記數（CC） 表示CSRC標識的數目。CSRC標識緊跟在RTP固定頭部之後，用來表示RTP數據報的來源，RTP協議允許在同一個會話中存在多個數據源，它們可以通過RTP混合器合併爲一個數據源。例如，可以產生一個CSRC列表來表示一個電話會議，該會議通過一個RTP混合器將所有講話者的語音數據組合爲一個RTP數據源。
負載類型（PT） 標明RTP負載的格式，包括所採用的編碼算法、採樣頻率、承載通道等。例如，類型2表明該RTP數據包中承載的是用ITU G.721算法編碼的語音數據，採樣頻率爲8000Hz，並且採用單聲道。
序列號 用來爲接收方提供探測數據丟失的方法，但如何處理丟失的數據則是應用程序自己的事情，RTP協議本身並不負責數據的重傳。
時間戳 記錄了負載中第一個字節的採樣時間，接收方能夠時間戳能夠確定數據的到達是否受到了延遲抖動的影響，但具體如何來補償延遲抖動則是應用程序自己的事情。從RTP數據報的格式不難看出，它包含了傳輸媒體的類型、格式、序列號、時間戳以及是否有附加數據等信息，這些都爲實時的流媒體傳輸提供了相應的基礎。RTP協議的目的是提供實時數據（如交互式的音頻和視頻）的端到端傳輸服務，因此在RTP中沒有連接的概念，它可以建立在底層的面向連接或面向非連接的傳輸協議之上；RTP也不依賴於特別的網絡地址格式，而僅僅只需要底層傳輸協議支持組幀（Framing）和分段（Segmentation）就足夠了；另外RTP本身還不提供任何可靠性機制，這些都要由傳輸協議或者應用程序自己來保證。在典型的應用場合下，RTP一般是在傳輸協議之上作爲應用程序的一部分加以實現的，如圖2所示：
RTCP控制協議
RTCP控制協議需要與RTP數據協議一起配合使用，當應用程序啓動一個RTP會話時將同時佔用兩個端口，分別供RTP和RTCP使用。RTP本身並不能爲按序傳輸數據包提供可靠的保證，也不提供流量控制和擁塞控制，這些都由RTCP來負責完成。通常RTCP會採用與RTP相同的分發機制，向會話中的所有成員週期性地發送控制信息，應用程序通過接收這些數據，從中獲取會話參與者的相關資料，以及網絡狀況、分組丟失概率等反饋信息，從而能夠對服務質量進行控制或者對網絡狀況進行診斷。
RTCP協議的功能是通過不同的RTCP數據報來實現的，主要有如下幾種類型：
SR 發送端報告，所謂發送端是指發出RTP數據報的應用程序或者終端，發送端同時也可以是接收端。
RR 接收端報告，所謂接收端是指僅接收但不發送RTP數據報的應用程序或者終端。
SDES 源描述，主要功能是作爲會話成員有關標識信息的載體，如用戶名、郵件地址、電話號碼等，此外還具有向會話成員傳達會話控制信息的功能。
BYE 通知離開，主要功能是指示某一個或者幾個源不再有效，即通知會話中的其他成員自己將退出會話。
APP 由應用程序自己定義，解決了RTCP的擴展性問題，並且爲協議的實現者提供了很大的靈活性。
RTCP數據報攜帶有服務質量監控的必要信息，能夠對服務質量進行動態的調整，並能夠對網絡擁塞進行有效的控制。由於RTCP數據報採用的是多播方式，因此會話中的所有成員都可以通過RTCP數據報返回的控制信息，來了解其他參與者的當前情況。
在一個典型的應用場合下，發送媒體流的應用程序將週期性地產生髮送端報告SR，該RTCP數據報含有不同媒體流間的同步信息，以及已經發送的數據報和字節的計數，接收端根據這些信息可以估計出實際的數據傳輸速率。另一方面，接收端會向所有已知的發送端發送接收端報告RR，該RTCP數據報含有已接收數據報的最大序列號、丟失的數據報數目、延時抖動和時間戳等重要信息，發送端應用根據這些信息可以估計出往返時延，並且可以根據數據報丟失概率和時延抖動情況動態調整發送速率，以改善網絡擁塞狀況，或者根據網絡狀況平滑地調整應用程序的服務質量。
RTSP實時流協議
作爲一個應用層協議，RTSP提供了一個可供擴展的框架，它的意義在於使得實時流媒體數據的受控和點播變得可能。總的說來，RTSP是一個流媒體表示協議，主要用來控制具有實時特性的數據發送，但它本身並不傳輸數據，而是必須依賴於下層傳輸協議所提供的某些服務。RTSP可以對流媒體提供諸如播放、暫停、快進等操作，它負責定義具體的控制消息、操作方法、狀態碼等，此外還描述了與RTP間的交互操作。
RTSP在制定時較多地參考了HTTP/1.1協議，甚至許多描述與HTTP/1.1完全相同。RTSP之所以特意使用與HTTP/1.1類似的語法和操作，在很大程度上是爲了兼容現有的Web基礎結構，正因如此，HTTP/1.1的擴展機制大都可以直接引入到RTSP中。
由RTSP控制的媒體流集合可以用表示描述（Presentation Description）來定義，所謂表示是指流媒體服務器提供給客戶機的一個或者多個媒體流的集合，而表示描述則包含了一個表示中各個媒體流的相關信息，如數據編碼/解碼算法、網絡地址、媒體流的內容等。
雖然RTSP服務器同樣也使用標識符來區別每一流連接會話（Session），但RTSP連接並沒有被綁定到傳輸層連接（如TCP等），也就是說在整個RTSP連接期間，RTSP用戶可打開或者關閉多個對RTSP服務器的可靠傳輸連接以發出RTSP 請求。此外，RTSP連接也可以基於面向無連接的傳輸協議（如UDP等）。
RTSP協議目前支持以下操作：
檢索媒體 允許用戶通過HTTP或者其它方法向媒體服務器提交一個表示描述。如表示是組播的，則表示描述就包含用於該媒體流的組播地址和端口號；如果表示是單播的， 爲了安全在表示描述中應該只提供目的地址。
邀請加入 媒體服務器可以被邀請參加正在進行的會議，或者在表示中回放媒體，或者在表示中錄製全部媒體或其子集，非常適合於分佈式教學。
添加媒體 通知用戶新加入的可利用媒體流，這對現場講座來講顯得尤其有用。與HTTP/1.1類似，RTSP請求也可以交由代理、通道或者緩存來進行處理