1. 引言
隨着信息產業的發展,人們對信息資源的要求已經逐漸由文字和圖片過渡到音頻和視頻,並越來越強調獲取資源的實時性和互動性。但人們又面臨着另外一種不可避免的尷尬,就是在網絡上看到生動清晰的媒體演示的同時,不得不爲等待傳輸文件而花費大量時間。爲了解決這個矛盾,一種新的媒體技術應運而生,這就是流媒體技術。流媒體由於具有啓動時延小、節省客戶端存儲空間等優勢,逐漸成爲人們的首選,流媒體網絡應用也在全球範圍內得到不斷的發展。其中實時流傳輸協議
RTP 詳細說明了在互聯網上傳遞音頻和視頻的標準數據包格式,它與傳輸控制協議 RTCP 配合使用,成爲流媒體技術最普遍採用的協議之一。
H.264/AVC 是ITU-T 視頻編碼專家組(VCEG)和ISO/IEC 動態圖像專家組(MPEG )聯合組成的聯合視頻組(JVT)共同努力制訂的新一代視頻編碼標準,它最大的優勢是具有很高的數據壓縮比率,在同等圖像質量的條件下,H.264 的壓縮比是MPEG-2 的2 倍以上,是 MPEG-4的1.5~2 倍。同時,採用視頻編碼層(VCL)和網絡提取層(NAL
)的分層設計,非常適用於流媒體技術進行實時傳輸。本文就是基於 RTP 協議,對 H.264 視頻進行流式打包傳輸,實現了一個基本的流媒體服務器功能,同時利用開源播放器VLC 作爲接收端,構成一個完整的H.264 視頻傳輸系統。
(1)標示位(M ):1 位,該標示位的含義一般由具體的媒體應用框架(profile )定義, 目的在於標記處RTP 流中的重要事件。
(2)載荷類型(PT):7 位,用來指出RTP負載的具體格式。在RFC3551中,對常用的音視頻格式的RTP 傳輸載荷類型做了默認的取值規定,例如,類型2 表明該RTP數據包中承載的是用ITU G.721 算法編碼的語音數據,採用頻率爲 8000HZ,並且採用單聲道。
(3)序號:16 位,每發送一個 RTP 數據包,序號加 1。接受者可以用它來檢測分組丟失和恢復分組順序。
(4)時間戳:32 位,時間戳表示了 RTP 數據分組中第一個字節的採樣時間,反映出各RTP 包相對於時間戳初始值的偏差。對於RTP 發送端而言,採樣時間必須來源於一個線性單調遞增的時鐘。
從 RTP 數據包的格式不難看出,它包含了傳輸媒體的類型、格式、序列號、時間戳以及是否有附加數據等信息。這些都爲實時的流媒體傳輸提供了相應的基礎。而傳輸控制協議RTCP爲 RTP傳輸提供了擁塞控制和流控制,它的具體包結構和各字段的含義可參考RFC3550,此處不再贅述。
H.264 的基本流由一系列NALU (Network Abstraction Layer Unit )組成,不同的NALU數據量各不相同。H.264 草案指出[2],當數據流是儲存在介質上時,在每個NALU 前添加起始碼:0x000001,用來指示一個 NALU的起始和終止位置。在這樣的機制下,*在碼流中檢測起始碼,作爲一個NALU得起始標識,當檢測到下一個起始碼時,當前NALU結束。每個NALU單元由一個字節的 NALU頭(NALU Header)和若干個字節的載荷數據(RBSP)組成。其中NALU 頭的格式如圖2 所示:
F:forbidden_zero_bit.1 位,如果有語法衝突,則爲 1。當網絡識別此單元存在比特錯誤時,可將其設爲 1,以便接收方丟掉該單元。
NRI:nal_ref_idc.2 位,用來指示該NALU 的重要性等級。值越大,表示當前NALU越重要。具體大於0 時取何值,沒有具體規定。
需要特別指出的是,NRI 值爲 7 和 8 的NALU 分別爲序列參數集(sps)和圖像參數集(pps)。參數集是一組很少改變的,爲大量VCL NALU 提供解碼信息的數據。其中序列參數集作用於一系列連續的編碼圖像,而圖像參數集作用於編碼視頻序列中一個或多個獨立的圖像。如果*沒能正確接收到這兩個參數集,那麼其他NALU 也是無法解碼的。因此它們一般在發送其它 NALU 之前發送,並且使用不同的信道或者更加可靠的傳輸協議(如TCP)進行傳輸,也可以重複傳輸。
前面分別討論了RTP 協議及H.264基本流的結構,那麼如何使用RTP協議來傳輸H.264視頻了?一個有效的辦法就是從H.264視頻中剝離出每個NALU,在每個NALU前添加相應的RTP包頭,然後將包含RTP 包頭和NALU 的數據包發送出去。下面就從RTP包頭和NALU兩方面分別闡述。
完整的 RTP 固定包頭的格式在前面圖 1 中已經指出,根據RFC3984[3],這裏詳細給出各個位的具體設置。
V:版本號,2 位。根據RFC3984,目前使用的RTP 版本號應設爲0x10。
P:填充位,1 位。當前不使用特殊的加密算法,因此該位設爲 0。
X:擴展位,1 位。當前固定頭後面不跟隨頭擴展,因此該位也爲 0。
CC:CSRC 計數,4 位。表示跟在 RTP 固定包頭後面CSRC 的數目,對於本文所要實現的基本的流媒體服務器來說,沒有用到混合器,該位也設爲 0x0。
M:標示位,1 位。如果當前 NALU爲一個接入單元最後的那個NALU,那麼將M位置 1;或者當前RTP 數據包爲一個NALU 的最後的那個分片時(NALU 的分片在後面講述),M位置 1。其餘情況下M 位保持爲 0。
PT:載荷類型,7 位。對於H.264 視頻格式,當前並沒有規定一個默認的PT 值。因此選用大於 95 的值可以。此處設爲0x60(十進制96)。
SQ:序號,16 位。序號的起始值爲隨機值,此處設爲 0,每發送一個RTP 數據包,序號值加 1。
TS:時間戳,32 位。同序號一樣,時間戳的起始值也爲隨機值,此處設爲0。根據RFC3984, 與時間戳相應的時鐘頻率必須爲90000HZ。
SSRC:同步源標示,32 位。SSRC應該被隨機生成,以使在同一個RTP會話期中沒有任何兩個同步源具有相同的SSRC 識別符。此處僅有一個同步源,因此將其設爲0x12345678。
對於每一個NALU,根據其包含的數據量的不同,其大小也有差異。在IP網絡中,當要傳輸的IP 報文大小超過最大傳輸單元MTU(Maximum Transmission Unit )時就會產生IP分片情況。在以太網環境中可傳輸的最大 IP 報文(MTU)的大小爲 1500 字節。如果發送的IP數據包大於MTU,數據包就會被拆開來傳送,這樣就會產生很多數據包碎片,增加丟包率,降低網絡速度。對於視頻傳輸而言,若RTP 包大於MTU 而由底層協議任意拆包,可能會導致接收端播放器的延時播放甚至無法正常播放。因此對於大於MTU 的NALU 單元,必須進行拆包處理。
(2)Aggregation Packet:在一個RTP 包中封裝多個NALU,對於較小的NALU 可以採用這種打包方案,從而提高傳輸效率。
(3)Fragmentation Unit:一個NALU 封裝在多個RTP包中,在本文中,對於大於1400字節的NALU 便採用這種方案進行拆包處理。
佰銳科技採用先進去馬賽克技術,保障在視頻通訊過程中不出現花屏、馬賽克等現象。免費測試下載地址:
http://www2.bairuitech.com/downloads/bairuisoft/AnyChatCoreSDK_V3.0.rar