H.264多媒體數據實時傳送方法

2023-06-24 07:02:56

專利名稱：H.264多媒體數據實時傳送方法
技術領域：
本發明涉及多媒體數據傳送方法，特別涉及H.264多媒體數據實時傳送方法。
背景技術：
隨著計算機網際網路(Internet)和移動通信網絡的飛速發展，流媒體技術的應用越來越廣泛，從網上廣播、電影播放到遠程教學以及在線的新聞網站等都用到了流媒體技術。當前網上傳送視頻、音頻主要有下載(Download)和流式傳送(Streaming)兩種方式。流式傳送是連續傳送視/音頻信號，當流媒體在客戶機播放時其餘部分在後臺繼續下載。流式傳送有順序流式傳送(Progressive Streaming)和實時流式傳送(Realtime Streaming)兩種方式。實時流式傳送是實時傳送，特別適合現場事件，實時流式傳送必須匹配連接帶寬，這意味著圖像質量會因網絡速度降低而變差，以減少對傳送帶寬的需求。「實時」的概念是指在一個應用中數據的交付必須與數據的產生保持精確的時間關係。
尤其是隨著第三代移動通信系統(3rd Generation，簡稱「3G」)的出現和普遍基於網際協議(Internet Protocol，簡稱「IP」)的網絡迅速發展，視頻通信正逐步成為通信的主要業務之一。而雙方或多方視頻通信業務，如可視電話、視頻會議、移動終端多媒體服務等，更對多媒體數據流的傳送及服務質量提出苛刻的要求。不僅要求網絡傳送實時性更好，而且等效的也要求視頻數據壓縮編碼效率更高。
鑑於媒體通信的需求現狀，國際電信聯盟標準部(InternationalTelecommunication Union Telecommunication Standardization Sector，簡稱「ITU-T」)繼制定了H.261、H.263、H.263+等視頻壓縮標準後，於2003年正式發布了H.264標準。這是ITU-T和國際標準化組織(InternationalStandardization Organization，簡稱「ISO」)的運動圖像專家組(Moving PictureExperts Group，簡稱「MPEG」)一起聯合制定的適應新階段網絡媒體傳送及通信需求的高效壓縮編碼標準。它同時也是MPEG-4標準第10部分的主要內容。
制定H.264標準的目的在於更加有效地提高視頻編碼效率和它對網絡的適配性。事實上由於其優越性，H.264視頻壓縮編碼標準很快就已經逐漸成為當前多媒體通信中的主流標準。大量的採用H.264多媒體實時通信產品(如會議電視，可視電話，3G移動通信終端)和網絡流媒體產品先後問世。是否支持H.264已經成為這個市場領域中決定產品競爭力的關鍵因素。可以預測，隨著H.264的正式頒布和廣泛使用，基於IP網絡和3G、後3G無線網絡的多媒體通信必然進入一個飛躍發展的新階段。
如前所述多媒體通信不僅要求媒體壓縮編碼效率高，而且要求網絡傳送的實時性。目前多媒體流傳送基本上都是採用實時傳送協議(Real-timeTransport Protocol，簡稱「RTP」)及其控制協議(Real-time Transport ControlProtocol，簡稱「RTCP」)。RTP是針對Internet上多媒體數據流的一個傳送協議，由網際網路工程任務組(Internet Engineering Task Force，簡稱「IETF」)發布。RTP被定義為在一對一或一對多的傳送情況下工作，其目的是提供時間信息和實現流同步。RTP的典型應用建立在用戶數據包協議(UserDatagram Protocol，簡稱「UDP」)上，但也可以在傳送控制協議(TransportControl Protocol，簡稱「TCP」)或異步傳送模式(Asynchronous Transfer Mode，簡稱「ATM」)等其他協議之上工作。
RTP本身只保證實時數據的傳送，並不能為按順序傳送數據包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務。RTCP負責管理傳送質量在當前應用進程之間交換控制信息。在RTP會話期間，各參與者周期性地傳送RTCP包，包中含有已發送的數據包的數量、丟失的數據包的數量等統計資料，因此，伺服器可以利用這些信息動態地改變傳送速率，甚至改變有效載荷類型。RTP和RTCP配合使用，能以有效的反饋和最小的開銷使傳送效率最佳化，故特別適合傳送網上的實時數據。
而H.264多媒體數據在IP網絡上傳送，不例外的也是基於UDP和其上層的RTP協議。RTP本身在結構上對於不同的媒體數據類型都能夠適用，但是在多媒體通信中不同的高層協議或媒體壓縮編碼標準(如H.261，H.263，MPEG-1/-2/-4，MP3等)，IETF都會制定針對該協議的RTP淨荷(Payload)打包方法的規範文件，詳細規定RTP封裝打包的方法，對於該具體協議是經過優化的。同樣的，對於H.264也存在對應的IETF標準是RFC 3984RTPPayload Format for H.264 Video。該標準目前是H.264視頻碼流在IP網絡上傳送的主要標準，應用很廣泛。在視頻通信領域，各主流廠商的產品都是基於RFC 3984的，也是目前僅有的H.264/RTP傳送方式。
事實上，H.264和以往其它的視頻壓縮編碼協議不同的關鍵地方在於H.264定義了一個新的層面，稱為網絡抽象層(Network Abstract Layer，簡稱「NAL」)。H.264為了增加其視頻編碼層(Video Coding Layer，簡稱「VCL」)和下面具體的網絡傳送協議層的分離和無關性，帶來更大的應用靈活性，定義了NAL這個新的層面，該層在ITU-T早期的視頻壓縮編碼協議比如H.261，H.263/H.263+/H.263++中都是沒有的。然而，如何在NAL和RTP協議承載協同工作中針對H.264的優點設計效率更高、更好的方案，使得RTP對於H.264的承載性能更好，是一個很值得研究和有很大應用價值的問題。
RFC3984規範所提出的RTP承載H.264的NAL層數據的方法是目前僅有的技術方案，該方案在RTP協議(RFC 3550)的基礎上，將NAL層數據封裝在RTP淨荷中進行承載。NAL層位於VCL和RTP之間，規定要把視頻碼流按照定義的規則和結構，分割成一連串的NAL數據單元(NAL Units，簡稱「NALU」)。在RFC3984中定義了RTP淨荷對於NALU的封裝格式。下面依次簡單介紹RTP的幀格式和現有技術中NALU的封裝方法。
RTP設計的主要目的是實時多媒體會議和連續數據存儲、交互分布式仿真、控制和測量應用等。RTP通常被承載於UDP協議之上，以利用其多路復用和校驗的功能。如果底層提供多點分發，RTP支持多地址傳送。RTP提供的功能包括載荷類型鑑別，序列編號，時間戳，和發送監測。
RTP包的格式如下RTP頭信息基本選項佔用12位元組(最小情況)，而IP協議和UDP協議的頭信息分別佔用20位元組和8位元組，因此RTP包封裝在UDP包再封裝在IP包中，總的頭信息佔用字節數是12+8+20＝40位元組。RTP包的頭信息的詳細結構如圖1所示。
圖1中所示從前到後RTP頭信息依次為第1位元組(字節0)為一些關於頭信息結構本身的欄位，第2位元組(字節1)為定義淨荷類型，第3、4位元組(字節2、3)為包序號(Sequence Number)，第5-8位元組為時間戳(timestamp)，第9-12位元組為同步貢獻源標識符(Synchronous Source Identifier，簡稱「SSRCID」)，最後為貢獻源標識符(Contributing Source Identifiers，簡稱「CSRCIDs」)的列表，其數目不確定。注意到，在本文描述中第1個字節為標註的字節0，之後依此類推。
其中前12個字節出現在所有不同類型的RTP數據包中，而頭信息中的其它數據，比如貢獻源標識符標識只有當混合器插入時才有。因此CSRC一般用於存在媒體混合時候的情況，比如在多方會議中，音頻需要混合，視頻也可以用這種方法提供多畫面的功能。而同步源標識SSRC其實就是所承載媒體流的標識。
上述各個欄位的具體意義及全稱分別描述如下
V欄位為版本(Version)信息，佔2比特(bits)，目前採用的版本為2，因此置V＝2，而其他值如V＝1表示更早的RTP版本，V＝0表示最原始的RTP前身，即在早期Mbone網絡上使用的語音IP(VOIP)通信系統中採用，後來演化成了RTP，而V＝3則尚未定義，因此是本發明可以利用的；P欄位為填充標識(Padding)，佔1bit，P如果置位，則表示數據包末尾包含一個或多個填充字節(Padding)，填充不屬於有效載荷的一部分；X欄位為擴展標識比特(Extension)，佔1bit，X如果置位，則RTP頭的最後必須跟一個可變長的頭擴展(如果有CSRC列表，頭擴展要跟在其後)，主要是保留用於某些應用環境下頭信息欄位不夠用的情況，該頭信息擴展包含一個16比特的長度欄位來計數擴展中有多少個32比特長的字，頭擴展的前16比特是左開放的，以便區分標識符和參數，這16比特的格式由具體的層面規範定義，該頭擴展的格式定義在RFC3550第5.3.1節中有詳細描述，此處限於篇幅不再給出；CC欄位為貢獻源數目(CSRC Count)，佔4bits，指明頭信息最後面的CSRC標識符的個數，接收方根據CC欄位可以確定頭信息後面的CSRC IDs列表長度；M欄位為標識比特(Marker)，佔1bit，該標識比特的解釋在特定的層面(Profile)中定義，它允許標識出數據包流中的重要事件，一個層面可以定義附加的標識比特或規定沒有標識比特，這裡所謂層面就是指具體的應用環境設置，由通信雙方具體協定，不受協議的限定；PT欄位為載荷類型(Payload Type，簡稱「PT」)，共7bits，標識RTP載荷的格式並確定他在應用程式中的解釋；標誌比特和載荷類型共一個字節攜帶層面規定信息，這個字節可能會被具體層面重新定義以適應不同需求，在具體應用中可以定義所謂的profile，其實就是一組靜態(即通信雙方事先約定好的)對應關係，將PT比特不同的取值和不同的媒體格式對應起來。當然也可以通過RTP之外的信令來進行動態協商定義PT取值和媒體格式之間的關係。在一個RTP會話(Session)中，RTP源是可以變更PT的。
接著的欄位就是序號共16bits，每發送一個RTP數據包，該序號值加一，這樣接收者可以用它來檢測數據包丟失和恢復數據包順序，一次通信中的序號初始值可以隨機給定，不影響通信。
時間戳佔32bits，它反映了RTP數據包中第一個字節的採樣時間，這裡的採樣時間必須來源於一個單調線性增長的時鐘，接收方根據其調整媒體播放時間或者進行同步。
同步源SSRC ID佔32bits，其具體值可隨機選擇，但要確保同一個RTP會話中的唯一性，即能唯一標識一個媒體源，如果一個源改變了源傳送地址，必須選擇一個新的SSRC標誌符。
貢獻源CSRC列表，可以根據需要為0-15項，每項佔32bits，該列表的長度即CSRC ID的數目正好由CC欄位的4個bit標出。事實上，用於標識某個媒體源的CSRC標識符與其對應的貢獻源的SSRC標識符是一致的，只不過在不同的接收方的角色不同，而被置為SSRC或CSRC。在多方通信中，CSRC ID是由混合器插入。
在承載H.264視頻的情況下，RTP把H.264的NALU封裝打包成RTP包流。在RFC 3984文件中主要定義了NALU，並且基於此給出H.264層NAL數據在RTP中的封裝打包格式。這種NALU的RTP封裝格式如圖2所示。
圖2中給出一個NALU在RTP的淨荷中的封裝結構，前面第一個字節為NALU頭信息，之後為NALU的數據內容，多個NALU首尾相接的填充到RTP包的淨荷中，在最後還有可選的RTP填充，這是RTP包格式規定的內容，是為了使得RTP包的長度符合某種特定要求(比如達到固定長度)，可選的RTP填充數據一般都填零。
NALU頭信息即第1個字節，也稱為八比特組(Octet)，其共有三個欄位，意義和全稱分別描述如下F欄位定義為禁止比特(forbidden_zero_bit)，佔1bit，用於標識語法錯等情況，如果有語法衝突則置為1，當網絡識別此單元中存在比特錯誤時，可將其設為1，以便接收方丟掉該單元，主要用於適應不同種類的網絡環境(比如有線無線相結合的環境)；NRI欄位定義為NAL參考標識(nal_ref_idc)，佔2bits，用於指示NALU數據的重要程度，其值為00表示NALU的內容不用於重建幀間預測的參考圖像，而非00則表示當前NALU是屬於參考幀的條帶(slice)或序列參數集(Sequence Parameter Set，簡稱「SPS」)、圖像參數集(Picture ParameterSet，簡稱「PPS」)等重要數據，該值越大表示當前NAL越重要；Type欄位定義為NALU類型(Nal_unit_type)，共5bits，可以有32種NALU的類型，其值和具體類型的對應關係在表1中詳細給出。
表1NALU頭信息中Type欄位取值與類型對應關係表

可見，NALU的頭信息的一個字節中給出的信息主要包含NALU的有效性、重要性等級，根據這些信息可以確定RTP所承載的數據重要性。
綜上所述，可以將現有技術的方案歸納如下首先在NAL層將H.264的視頻比特流按照一定的規則分割形成NALU流，這一步實際上屬於H.264實現的範疇，比如可以把一幀圖像作為一個NALU，也可以把一個Slice作為一個NALU，然後根據和應用相關的封裝打包策略把NALU流封裝打包形成RTP數據包流。RTP數據包中，在頭信息之後就是NALU數據區，如果一個RTP數據包封裝多個H.264的NALU，那麼這些NALU首尾相接排列，每個NALU佔據一段連續的比特，每個NALU的第一個字節是NALU頭信息字節，而在RTP數據包的最後，根據需要，可能存在一些可選性的填充數據比特。有一點需要注意，在傳送過程中，底層RTP協議並不處理NALU的具體信息。
在實際應用中，上述方案存在以下問題該方案中H.264的NALU頭信息沒有能夠體現在RTP包的頭信息中。而NALU頭信息字節中，其實含有很多重要的信息，比如NRI指示對應的NALU包含的數據是H.264非參考幀還是參考幀或者其它重要圖像數據比如參數集等。
因為RTP協議本身不提供任何服務質量(Quality of Service，簡稱「QoS」)機制，並且不提供關於承載數據重要性優先級等的信息，所以在IP和無線網絡上RTP本身沒有任何針對網絡丟包等錯誤的容錯能力，或稱為錯誤彈性(Error Resilience)。
如果能夠在RTP數據包的頭信息中，反映H.264 NALU的一些信息，則可以通過直接掃描RTP包頭信息獲得關於H.264 NALU屬性的信息。根據這些信息，網絡設備就有可能對於RTP數據包作有區別的處理，從而保證重要數據在傳送過程中的優先性。
另外，該方案在效率上還有改進的餘地，如果一個RTP數據包中封裝了多個H.264 NALU，一般這些NALU的類型都一樣，那麼這些NALU的頭信息字節其實是完全相同的，如果有N個NALU在一個RTP包中，那麼這N個NALU頭信息字節其實可以用一個字節替代，不損失任何信息，但是效率提高了，因為可以減少N-1個冗餘字節。
造成這種情況的主要原因在於，現有技術方案中將NALU的頭信息完全封裝在淨荷當中，使得RTP協議無法直接獲知有關淨荷的屬性、級別、重要程度等，從而無法實現基於此的QoS機制。其次，這樣的封裝格式還造成了NALU頭信息佔用淨荷資源，因為每個NALU的都附帶頭信息，導致在很多情況下，由於一個RTP中多個相同類型的NALU的頭信息都是一樣的，從而浪費了RTP傳送帶寬資源。

發明內容
有鑑於此，本發明的主要目的在於提供一種H.264多媒體數據實時傳送方法，使得RTP協議能夠高效承載H.264多媒體視頻數據，在兼容現有採用RTP協議的設備及傳送方式的前提下增加服務質量保證機制。
為實現上述目的，本發明提供了一種H.264多媒體數據實時傳送方法，所述H.264多媒體數據在網絡抽象層被分為網絡抽象層單元流，所述網絡抽象層單元包含頭信息，所述網絡抽象層單元頭信息依次包含禁止比特欄位，用於指示所述網絡抽象層單元是否出錯；網絡抽象層參考標識欄位，用於指示所述網絡抽象層單元的重要性；類型欄位，用於指示所述網絡抽象層單元的類型，包含以下步驟A發送方按改進實時傳送協議封裝格式將頭信息相同的至少一個網絡抽象層單元封裝在同一個改進實時傳送協議包中，並在該改進實時傳送協議包頭信息中設改進實時傳送協議標識以區別實時傳送協議包；B接收方根據該改進實時傳送協議標識判斷該包為改進實時傳送協議包，並根據改進實時傳送協議封裝格式處理該改進實時傳送協議包，獲取所承載的網絡抽象層單元；其中，在所述改進實時傳送協議封裝格式中，將其所承載的網絡抽象層單元所具有的相同頭信息綜合體現在該改進實時傳送協議包的頭信息中，並將所承載的網絡抽象層單元去掉其頭信息再填充入該改進實時傳送協議包的淨荷中。
其中，在所述改進實時傳送協議封裝格式中，所述網絡抽象層單元頭信息中的網絡抽象層參考標識欄位和類型欄位填充在所述改進實時傳送協議包頭信息的淨荷類型欄位中，該淨荷類型欄位位於所述改進實時傳送協議包頭信息的第2個字節的後7比特。
此外在所述方法中，在所述步驟A、B中，所述改進實時傳送協議標識為所述改進實時傳送協議包頭信息的版本信息欄位取值為二進位值11，該版本信息欄位位於所述改進實時傳送協議包頭信息的第1個字節的前2比特。
此外在所述方法中，在所述改進實時傳送協議封裝格式中，所述網絡抽象層單元頭信息中的禁止比特欄位填充在所述改進實時傳送協議包頭信息的標記欄位中，該標記欄位位於所述改進實時傳送協議包頭信息的第2個字節的前1比特；且在所述步驟B中，接收方根據所述改進實時傳送協議包的標記欄位判斷其所承載的網絡抽象層單元是否出錯；其中，所述接收方包含通信終端和網絡中間設備。
此外在所述方法中，在所述步驟A、B中，所述改進實時傳送協議標識為所述改進實時傳送協議包頭信息的標記欄位取值為二進位值1，該標記欄位位於所述改進實時傳送協議包頭信息的第2個字節的前1比特。
此外在所述方法中，在所述改進實時傳送協議封裝格式中，忽略所述網絡抽象層單元頭信息中的禁止比特欄位；在所述步驟A中，對於所述禁止比特欄位指示的出錯網絡抽象層單元，採用實時傳送協議包封裝；在所述步驟B中，判斷該實時傳送協議包後按實時傳送協議封裝格式處理該實時傳送協議包。
此外在所述方法中，所述步驟A包含以下子步驟發送方首先判斷至少一個所述網絡抽象層單元的頭信息中的禁止比特欄位是否有效，據此將其分為正常網絡抽象層單元和出錯網絡抽象層單元；然後按所述改進實時傳送協議封裝格式將所述正常網絡抽象層單元封裝成所述改進實時傳送協議包，並設所述改進實時傳送協議標識；按所述實時傳送協議封裝格式將所述出錯網絡抽象層單元封裝成所述實時傳送協議包；所述步驟B包含以下子步驟接收方首先根據接收到的包的頭信息中是否含有所述改進實時傳送協議標識，將其分為所述改進實時傳送協議包和所述實時傳送協議包；然後根據所述改進實時傳送協議封裝格式處理所述改進實時傳送協議包，根據所述實時傳送協議包封裝格式處理所述實時傳送協議包。
此外在所述方法中，在所述改進實時傳送協議封裝格式中，當所述網絡抽象層單元的所有類型少於16種時，僅用所述類型欄位的低4比特表徵，而所述類型欄位的最高比特作為擴展保留比特。
此外在所述方法中，多媒體傳送設備根據所述改進實時傳送協議頭信息獲知其所承載的網絡抽象層單元的相關信息，並據此實施所述H.264多媒體數據實時傳送的服務質量策略。
通過比較可以發現，本發明的技術方案與現有技術的主要區別在於，給出一種改進的RTP協議(MRTP)用於承載NALU數據，通過將同一個RTP包中的所有NALU的頭信息字節結合到其頭信息中，採用了一種結合方式使得既不影響現有RTP協議及設備的運作，而且能夠將NALU淨荷的屬性直接體現在MRTP頭信息中，一方面使得MRTP對NALU的封裝承載效率大大提高，另一方面使得通過MRTP對淨荷NALU屬性的體現提供了QoS機制實現的基礎；另外通過對現有RTP頭信息中相關欄位比如M、F欄位的改進，給出區別現有RTP和MRTP的標識方法，這使得現有網絡媒體設備同時支持RTP和MRTP進行工作成為可能，提高了MRTP的兼容性；並且給出相應的對於存在語法錯誤(syntactical errors)或者誤碼的NALU的傳統RTP單獨傳送方法，和MRTP與RTP數據包交替處理的方案。
這種技術方案上的區別，帶來了較為明顯的有益效果，即通過本發明改進的MRTP協議的頭信息攜帶H.264的NALU頭信息，從而在不用對於NALU進行解碼的情況下，通過對於MRTP頭信息的快速掃描即可以確定MRTP數據包承載NALU的重要性，從而採取相應的措施，實現QoS策略等，進一步提高服務質量；同時，通過剝離掉MRTP數據包中同類H.264 NALU的頭信息字節，達到降低冗餘、提高傳送效率的目的，對於IP網絡多媒體視頻通信提高視頻傳送質量和用戶體驗有很好效果；另外，對於MRTP和RTP的區別實現了與現有技術的兼容，給出交替處理MRTP和RTP數據包的解決方式，以及錯誤NALU的單獨傳送方案，這些都提高了MRTP這種新方法的健壯性。


圖1是RTP數據包的頭信息結構示意圖；圖2是現有技術在RTP包淨荷中對NALU數據的封裝格式示意圖；圖3是根據本發明的實施方式的MRTP數據包的頭信息結構示意圖。
具體實施例方式
為使本發明的目的、技術方案和優點更加清楚，下面將結合附圖對本發明作進一步地詳細描述。
本發明旨在提供一種方案能夠在RTP的頭信息中體現H.264 NALU的頭信息。其基本原理是利用目前RTP頭信息中的某個或者某些字節或者比特來體現NALU的頭信息，而這些字節或者比特在RTP中定義的目的就是為和所承載的具體媒體協議結合留下發展空間的。改進後的RTP協議還不會影響與支持原RTP協議的設備之間的互通性，即在通信中有些終端採用按照本發明改進的RTP協議，另外的終端採用未改進的RTP協議，這些終端之間完全能夠正常通信。這一點是靠在MRTP頭信息中設置標誌比特，用以區分傳統的RTP數據包，同時終端也可以針對不同的情況，採取不同的處理措施，實現MRTP與RTP交替傳送處理的方案。這裡面也包括了對語法錯誤NALU的處理方案，用傳統RTP傳送語法錯誤NALU即可解決其F標誌比特被用於區別MRTP所帶來的問題。
MRTP對現有RTP的改進主要涉及到RTP數據包頭信息中的淨荷類型PT欄位和版本信息V欄位的重新定義。該方案的兩個潛在價值是為H.264數據的傳送提供一定的QoS機制；提高RTP封裝H.264 NALU的效率。
本文採用改進的RTP(Modified RTP，簡稱「MRTP」)格式封裝NALU數據，下面給出具體實施方式
的描述，但是有一點需要說明的是，下面給出的所有有關MRTP的描述中將只提到其與現有RTP所不同的地方。MRTP與RTP最基本的不同點在於，在MRTP封裝過程中，將具有相同頭信息的NALU包的頭信息綜合入MRTP的頭信息中。
前面已經提到過NALU頭信息結構，這裡再次強調以下，NALU信息依次包含佔1比特的F欄位，用於指示所述NALU是否出錯；佔2比特的NRI欄位，用於指示所述NALU的重要性；佔5比特的Type欄位，用於指示所述NALU的類型。
本發明的第一實施方式中收發雙方的執行步驟如下所述。
發送方按MRTP封裝格式將頭信息相同的多個NALU封裝在同一個MRTP包中，並在該MRTP包頭信息中設MRTP標識以區別RTP包。這裡有一點值得注意本發明要求的一個合理前提條件是，在同一個MRTP數據包中只存放同一種類型的H.264NALU，即具有相同的頭信息。
根據實際工程經驗，在一般情況下，因為H.264比特流總是存在相鄰的部分其對應的NALU類型相同這個屬性，這個假設總是可以滿足的。即使在某些情況下無法滿足，也可以有幾種對策可以處理這樣的情況第一種可以將相同類型的NALU累積，直到滿足一定的數目後在封裝到MRTP中，另一種如果相同類型的NALU的數目達不到一定的數目的話，採用RTP填充的方法，雖然浪費一點帶寬，但這微不足道，還有一種方法是如果類型不同的NALU非常多，則可以採用RTP封裝，反正在接收方能夠根據MRTP標識來識別，進行對應的處理。
接收方根據該MRTP標識判斷該包為MRTP包，並根據MRTP封裝格式處理該MRTP包，獲取所承載的NALU。這裡接收方根據MRTP標識可以識別MRTP包，主要是區別於RTP包，這樣可是使得採用MRTP協議的終端不影響現有的RTP協議正常通信，具備向下兼容性。
上面提到的在所述MRTP封裝格式中，將其所承載的NALU所具有的相同頭信息綜合在該MRTP包的頭信息中，並將所承載的NALU去掉其頭信息再填充入該MRTP包的淨荷中。這一點也就是MRTP於RTP的主要區別，前面提過很多，這樣帶來方便功能擴展和節約帶寬的好處。
那麼如何將NALU頭綜合到MRTP頭中的，又如何在MRTP頭標識該包是MRTP包呢？下面將具體給出兩套方案以解決這個幾個問題。
本發明第二實施方式在第一實施方式的基礎上，在MRTP封裝格式中，NALU頭信息中的NRI欄位和Type欄位填充在MRTP包頭信息的PT欄位中，前面已經敘述，該PT欄位位於MRTP包頭信息的第2個字節的後7比特。在圖3中示出了這樣一個MRTP頭的格式，其中與RTP不同的地方已經用粗體部分表示，另外圖中有些地方在後面還會解釋。
該實施方式的另外兩個要點是第一，將MRTP包頭中的V欄位作為MRTP標識，如果是MRTP包則將其V欄位取值為3(二進位值11)，前面已提到，該V欄位位於MRTP包頭信息的第1個字節的前2比特，即版本信息欄位；第二，NALU頭信息中的F欄位填充在MRTP包頭信息的M欄位中，該M欄位位於MRTP包頭信息的第2個字節的前1比特，在接收方則根據MRTP包的M欄位判斷其所承載的NALU是否出錯，也就實現了F欄位的禁止比特功能。
可見在本發明的第二實施方式中，令MRTP的當前版本V取值3，相當於是新版本的RTP，現行的RTP版本V取值為2。通過版本的區別，可以告訴RTP數據包的接收方，該RTP協議是改進版本MRTP，從而在後面的處理，就要按照針對改進RTP協議的處理流程進行。後面我們還將描述一種替代方案，可以不修改V也能達到表示MRTP和RTP之間的差別的目的。
在該實施方式中，將NALU頭信息字節(8個比特)替換原RTP頭信息中的標識M欄位1個比特和PT欄位7個比特共8個比特。具體的替換順序比如可以是這樣F比特替換M比特；NRI2個比特替換PT7個比特中的最高2個比特；Type5個比特替換PT7個比特中的最低5個比特；實際上，這樣的替換方案是有其合理性的。PT7個比特本來就是可以自由使用的，前面已經提到。M欄位的用途在RTP(RFC 3550)中規定如下某種具體的層面(Profile)可以規定不使用M比特，而是把它併入PT，這樣PT最多可以有8個比特，區別256種不同的類型。因此，用F比特替換M比特完全是符合RTP規定的，不會引起MRTP和傳統RTP之間互通的問題。
容易看出本發明MRTP的封裝格式具有明顯的三個優點第一，額外開銷少，尤其是一個RTP中有多個NALU時，明顯節省傳送比特數；第二，不用對RTP數據包中的H.264 NALU數據解碼就可以判別這些NALU的相對重要性；第三，不用對RTP數據包中的H.264 NALU數據解碼就可識別由於其它的比特丟失而是否會造成該RTP包能否正確解碼。
為了進一步詳細描述本發明第二實施方式的技術細節，下面給出一個MRTP封裝和去封裝的過程描述。在進行上述處理後，在同一個MRTP數據包中的多個H.264 NALU類型完全相同，即它們的頭信息字節都相同，那麼在他們封裝到MRTP數據包中的時候，可以剝離掉原來的頭信息字節，這樣如果有N個NALU，可以減少N個字節。去封裝時，就是把NALU從MRTP數據包中提取出來還原為原來的形式，即將這N個NALU從他們所在的MRTP數據包中提取出來，然後把MRTP頭信息中的PT的7個比特拷貝到一個字節H(8比特)中的最低7個比特中去，而H的最高比特作為F比特，設置為0。然後把生成的H字節附加到每個提取出來的NALU的最前面，這樣就還原了每個NALU。當然如果說MRTP包頭中的F欄位為1的話，說明該MRTP包中的NALU出錯，因此直接丟棄即可，節省了處理時間。
本發明的第三實施方式在第一實施方式的基礎上給出第二種解決方案，該方案與第二實施方式有一點是相同的，即也是將NALU頭中的NRI和Type欄位填充到MRTP頭的PT欄位的7個比特中。不同的地方有兩點不再採用V欄位標識MRTP，還是取值為V＝2，但是採用M欄位標識MRTP，這樣帶來的一個問題就是F欄位沒有地方填充了，該實施方式中將F是否置位的兩類NALU分別對待，對於F置位的出錯NALU還是採用原先的RTP傳送，而對於正常的則採用MRTP傳送，但忽略該F比特。具體細節如下所述。
第三實施方式中，將M欄位取值為1來標識MRTP包，該M欄位位於所述MRTP包頭信息的第2個字節的前1比特。而對於F比特，在H.264協議中規定如果有語法衝突或者錯誤，則為1。當網絡識別此單元中存在比特錯誤時，可將其設為1，以便接收方丟掉該單元。主要用於適應不同種類的網絡環境，比如有線無線相結合的環境。具體的使用原則是一般情況下通信的發送方和接收方在對於視頻進行H.264編碼和解碼的時候，不對於該比特進行「寫」操作，解碼端對於該比特進行「讀」操作。如果發現F＝1，則接收方在解碼過程中將丟棄該NALU。根據目前的業界普遍應用情況來看，對於F比特進行「寫」操作，主要是在兩種不同網絡之間的網關上進行，比如進行編碼轉換的情況(MPEG-4到H.264，H.263到H.264等)。
因此，本發明的第三實施方式將F比特忽略，不用於原來H.264定義的目的。從而使得原先用於填充F比特的M欄位可以保留，用於未來的擴展攜帶更多信息，這裡就是用於標識MRTP包。這樣做的好處是，不需要對於版本信息V＝2進行修改，MRTP還是用原來版本V取值2。這也是節約了目前僅有的RTP版本信息資源。
然而不可避免的是，在實際應用中可能出現需要使用F比特的小概率情況，比如NALU語法錯的時候，本發明第三實施方式對於這種情況做如下處理在MRTP封裝格式中，忽略所述NALU頭信息中的F欄位；但在發送方，對於F欄位有效的出錯NALU，仍舊採用RTP包封裝，僅對正常的NALU採用MRTP包裝；在接收方則判斷該包為MRTP還是RTP包後按相應封裝格式處理該包。也就是說，當F比特在某些特殊情況下，要用於原來H.264定義的目的，即要用於表示可能存在的H.264 NALU語法錯誤的情況，如果一個中間設備比如網關在對於視頻按照H.264協議進行視頻編碼的時候，發現某個NALU存在語法錯誤，那麼就要對於該NALU單獨進行封裝處理。
歸納上述MRTP和RTP交替處理的方法流程如下發送方首先判斷至少一個NALU的頭信息中的F欄位是否有效，據此將其分為正常NALU和出錯NALU；然後按MRTP封裝格式將正常NALU封裝成MRTP包，並設MRTP標識；按RTP封裝格式將出錯NALU封裝成RTP包；接收方首先判斷接收到的包的頭信息是否設MRTP標識，將其分為MRTP包和RTP包；然後根據MRTP封裝格式處理MRTP包，根據RTP包封裝格式處理RTP包。
可見，在本發明的第三實施方式中，網關對於正常的NALU，按照前面描述的方法，對於類型相同的H.264 NALU按照一定的規則(由具體應用決定，主要規定每個MRTP數據包中封裝多少個同類的NALU)進行MRTP封裝，一旦發現某個NALU存在語法錯誤，那麼就要對於該NALU採用常規RTP封裝。這個時候常規的RTP數據包中也許就只含有一個H.264 NALU。
以上方法的假設是在連續的H.264 NALU流中，偶爾出現單獨的語法錯誤NALU，這個時候把錯誤的NALU單獨拿出來用RTP封裝。在接收方，如果收到MRTP數據包，就按MRTP的規則進行H.264 NALU的去封裝處理；如果收到RTP的數據包，就按RTP的規則進行H.264 NALU的去封裝處理。
在更加極端的情況下，中間設備出現H.264編碼錯誤，出現連續多個有語法錯誤的H.264 NALU，比如M個連續的語法錯誤NALU出現，那麼可以把這M個NALU仍然採取傳統RTP來封裝。另外，即使NALU流中出錯NALU陸續不絕，那麼可以將這些出錯NALU累積，直到達到滿足一個RTP包的長度後再用RTP打包，這樣可以節約帶寬，同時不影響接收方，因為接收方可以根據序號得知哪些NALU丟失。
不難看出，這種方案雖然採用了用傳統RTP來傳送，但完全不會影響MRTP帶來的好處。因為正常的NALU都能夠用MRTP封裝，其好處都可以享受，比如基於頭信息可能採用的QoS機制等。而對於出錯的NALU，在接收方的處理一般都是丟棄，因此它們享受不到MRTP帶來的好處是合理的。
最後還需要說明的一點是，注意到前文提到的表1中給出的NALU的類型及其對應Type欄位的取值，可以發現現有的類型不足16種，也就是說Type的5個比特完全可以縮減為4個，這不影響現有的H.264傳送，因此在本發明的第四實施方式種，在MRTP封裝格式中，當NALU的所有類型少於16種時，僅用Type欄位的低4比特表徵，而Type的最高比特作為擴展保留比特，稱作C欄位，如圖3中所示。將該C比特留待以後使用，繼續進行功能擴展。將比特C進行保留後，表1中給出的NALU類型要做相應修改共16個值，取值0-12與表1相同，取值13-15為保留。
當然雖然目前H.264的NALU類型只有13種，但是H.264後續會發展，可能會產生更多的NALU類型，如果未來NALU類型增加到16種以上，那麼還是需要用PT 7個比特中的最低4個比特加上C比特作為類型指示。
行文最後，需要提及的是本發明的MRTP帶來的最大好處也就是，多媒體傳送設備可以根據MRTP頭信息直接獲知其所承載的NALU的相關信息，並據此實施H.264多媒體數據實時傳送的QoS策略。這一點在現有的RTP是無法實現的，因為對於RTP層來說，NALU層信息是不關心的，也就無法獲知淨荷中的每個NALU的頭信息，從而無法實現QoS策略。
雖然通過參照本發明的某些優選實施方式，已經對本發明進行了圖示和描述，但本領域的普通技術人員應該明白，可以在形式上和細節上對其作各種改變，而不偏離本發明的精神和範圍。
權利要求
1.一種H.264多媒體數據實時傳送方法，所述H.264多媒體數據在網絡抽象層被分為網絡抽象層單元流，所述網絡抽象層單元包含頭信息，其特徵在於，包含以下步驟A發送方按改進實時傳送協議封裝格式將頭信息相同的至少一個網絡抽象層單元封裝在同一個改進實時傳送協議包中，並在該改進實時傳送協議包頭信息中設改進實時傳送協議標識以區別實時傳送協議包；B接收方根據該改進實時傳送協議標識判斷該包為改進實時傳送協議包，並根據改進實時傳送協議封裝格式處理該改進實時傳送協議包，獲取所承載的網絡抽象層單元；其中，在所述改進實時傳送協議封裝格式中，將其所承載的網絡抽象層單元所具有的相同頭信息綜合體現在該改進實時傳送協議包的頭信息中，並將所承載的網絡抽象層單元去掉其頭信息再填充入該改進實時傳送協議包的淨荷中。
2.根據權利要求1所述的H.264多媒體數據實時傳送方法，其特徵在於，所述網絡抽象層單元頭信息依次包含禁止比特欄位，用於指示所述網絡抽象層單元是否出錯；網絡抽象層參考標識欄位，用於指示所述網絡抽象層單元的重要性；類型欄位，用於指示所述網絡抽象層單元的類型；
3.根據權利要求2所述的H.264多媒體數據實時傳送方法，其特徵在於，在所述改進實時傳送協議封裝格式中，所述網絡抽象層單元頭信息中的網絡抽象層參考標識欄位和類型欄位填充在所述改進實時傳送協議包頭信息的淨荷類型欄位中，該淨荷類型欄位位於所述改進實時傳送協議包頭信息的第2個字節的後7比特。
4.根據權利要求3所述的H.264多媒體數據實時傳送方法，其特徵在於，在所述步驟A、B中，所述改進實時傳送協議標識為所述改進實時傳送協議包頭信息的版本信息欄位，該版本信息欄位位於所述改進實時傳送協議包頭信息的第1個字節的前2比特。
5.根據權利要求4所述的H.264多媒體數據實時傳送方法，其特徵在於，在所述改進實時傳送協議封裝格式中，所述網絡抽象層單元頭信息中的禁止比特欄位填充在所述改進實時傳送協議包頭信息的標記欄位中，該標記欄位位於所述改進實時傳送協議包頭信息的第2個字節的前1比特；且在所述步驟B中，接收方根據所述改進實時傳送協議包的標記欄位判斷其所承載的網絡抽象層單元是否出錯。其中，所述接收方包含通信終端和網絡中間設備。
6.根據權利要求3所述的H.264多媒體數據實時傳送方法，其特徵在於，在所述步驟A、B中，所述改進實時傳送協議標識為所述改進實時傳送協議包頭信息的標記欄位，該標記欄位位於所述改進實時傳送協議包頭信息的第2個字節的前1比特。
7.根據權利要求6所述的H.264多媒體數據實時傳送方法，其特徵在於，所述步驟A包含以下子步驟發送方首先判斷至少一個所述網絡抽象層單元的頭信息中的禁止比特欄位是否有效，據此將其分為正常網絡抽象層單元和出錯網絡抽象層單元；然後按所述改進實時傳送協議封裝格式將所述正常網絡抽象層單元封裝成所述改進實時傳送協議包，並設所述改進實時傳送協議標識，在所述改進實時傳送協議封裝格式中，忽略所述網絡抽象層單元頭信息中的禁止比特欄位；按所述實時傳送協議封裝格式將所述出錯網絡抽象層單元封裝成所述實時傳送協議包；所述步驟B包含以下子步驟接收方首先根據接收到的包的頭信息中是否含有所述改進實時傳送協議標識，將其分為所述改進實時傳送協議包和所述實時傳送協議包；然後根據所述改進實時傳送協議封裝格式處理所述改進實時傳送協議包，根據所述實時傳送協議包封裝格式處理所述實時傳送協議包。
8.根據權利要求3-7中任意一項所述的H.264多媒體數據實時傳送方法，其特徵在於，在所述改進實時傳送協議封裝格式中，當所述網絡抽象層單元的所有類型少於16種時，僅用所述類型欄位的低4比特表徵，而所述類型欄位的最高比特作為擴展保留比特。
9.根據權利要求3-8中任意一項所述的H.264多媒體數據實時傳送方法，其特徵在於，多媒體傳送設備根據所述改進實時傳送協議頭信息獲知其所承載的網絡抽象層單元的相關信息，並據此實施所述H.264多媒體數據實時傳送的服務質量策略。
全文摘要
本發明涉及多媒體視頻數據傳送方法，公開了一種H.264多媒體視頻數據實時傳送方法，使得RTP協議能夠高效承載H.264多媒體視頻數據，在兼容現有採用RTP協議的設備及傳送方式的前提下增加服務質量保證機制。本發明中，給出一種改進的RTP協議用於承載H.264數據，通過將同一個RTP包中的所有H.264 NALU的頭信息字節結合到RTP包自身的頭信息中，使得既不影響現有RTP協議及設備的運作，而且能夠將H.264 NALU淨荷的屬性直接體現在MRTP頭信息中；另外通過對現有RTP頭信息中相關欄位比如M、F欄位的改進，給出區別現有RTP和MRTP的標識方法，這使得現有網絡媒體設備同時支持RTP和MRTP進行工作成為可能，提高了MRTP的兼容性和應用的靈活性。
文檔編號H04N7/24GK1863314SQ20051011394
公開日2006年11月15日 申請日期2005年10月17日 優先權日2005年10月17日
發明者宋彬, 羅忠 申請人:華為技術有限公司