組織：中國互動出版網（http://www.china-pub.com/）
RFC文檔中文翻譯計劃（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
譯者：劉學武 （Arlen  arlen@pub.sd.cninfo.net ）
譯文發布時間：2001-5-8
版權：本中文翻譯文檔版權歸中國互動出版網所有。可以用于非商業用途自由轉載，但必須
保留本文檔的翻譯及版權信息。


Network Working Group                                            M. Civanlar
Request for Comments: 2343                                            G. Cash
Category: Experimental                                              B. Haskell
                                                        AT&T Labs-Research
May 1998



應用于捆綁的MPEG的RTP有效載荷的格式
(RFC 2343  RTP Payload Format for Bundled MPEG)

本備忘錄的狀態

    這份備忘錄定義了一個應用于Internet業界的實驗性的協議。本備忘錄沒有規定一個任
何種類的Internet標準。它需要得到進一步的討論和建議。本備忘錄的分發是沒有限制的。

版權通告

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

目 錄
摘要	2
1. 介紹	2
2. 捆綁的MPEG 視頻和音頻的封裝	3
2.1. RTP 應用于BMPEG封裝的固的頭部	3
2.2. BMPEG 頭的細節:	4
3. 安全性考慮	4
附錄 1. 錯誤恢復 (ERROR RECOVERY)	5
附錄 2. 再同步（RESYNCHRONIZATION）	5
參考	6
作者的地址	6
完整的版權聲明	7
摘要
    這份文檔描述了一種適合于捆綁的、MPEG-2編碼的、可以應用RTP協議的視頻和音頻數
據的有效載荷類型，這是第二版。對于這種有效載荷類型，當它用于視頻點播應用系統時，
捆綁具有明顯的優勢。當這種優勢足夠重要，以至于可以犧牲已分離的音頻視頻流的模塊化
時，就可能使用這種有效載荷。
1. 介紹
    這份文檔描述了一種適用于MPEG-2編碼的、使用實時傳輸協議(RTP)第二版[1]的音頻和
視頻流的捆綁式打包方案。

    MPEG-2 國際標準由三個層次組成：音頻，視頻和系統[2]。音頻和視頻層定義了相應的
“基本流(elementary streams)”的語法和語義。系統層支持多重壓縮流的同步和交叉，緩
沖區的初始化和管理，以及時間的鑒定。RFC 2250[3]描述了為傳輸單獨的音頻和視頻基本流，
即傳輸流，而采用的打包技術，該流在系統層定義，使用RTP。
    捆綁打包方案是必須的，因為對于某些重要的應用，它比其他的方案有幾個優勢。這些
應用包括了視頻點播(VOD)，在那里音頻和視頻總是一起使用。與音頻和視頻和獨立打包相比，
其優勢在于：

     1. 每一個“節目”(例如捆綁的音頻/視頻)使用唯一的端口。這種方法增加了可服務的
流數，例如來自一個VOD服務器。而且，它消除了在客戶端兩個端口應用于分離的音頻和視
頻流時的性能碰撞。

     2．提供音頻和視頻的顯式的同步(implicit synchronization)。當音頻和視頻數據以
交叉格式存儲在服務器時，這是一個明顯的便利。

     3．減少了頭部的總開銷(overhead)。既然使用大包會增加丟失和延遲的影響，那么僅
有音頻包需要較小的總開銷增加。A/V捆綁格式可以提供總共大約1％的減少。考慮到MPEG-2
編碼的素材使用高位率，例如在4Mbps時，節省的位數就是40Kbps，這可以提供可察覺的音
頻或視頻質量的改善。

     4．可以全面地減小接收器的緩沖區大小。音頻和視頻流在傳輸時可能經歷不同的延遲。
接收器的緩沖區必須設計得適合這些延遲中的最大值。例如，讓我們假設使用兩個緩沖區，
每一個的大小都是B，對于每個流單獨傳送時的概率P都是足夠用的。同樣大小的緩沖區能
足夠接收兩個流時的概率是P乘以能足夠接收第一個流并能足夠接收給出的第二個流的B的
條件概率。這個條件概率，一般地，比用一個較大的緩沖區達到相同的概率等級要小。

     5．可以有助于控制被一個A/V節目使用的總體帶寬。

    并且，與傳輸層流的打包相比，其優勢在于：

     1．總開銷的減少。它不包含系統層的信息，對于RTP這是多余的。（essentially they 
address similar issues）

     2．更容易進行錯誤恢復。因為結構化的打包與應用層分幀(application layer framing 
(ALF))規則相一致，丟失掩蔽(loss concealment)和錯誤恢復(error recovery)更加簡單而
有效。
2. 捆綁的MPEG 視頻和音頻的封裝
    視頻封裝遵循與在[3]中描述的適用于MPEG基流(MPEG elementary streams)的封裝相似
的規則。特別地：

     1．MPEG Video_Sequence_Header 出現的時候，將總是在一個RTP有效載荷的開始處。

     2．一個MPEG GOP_header出現的時候，將總是在一個RTP有效載荷的開始處，或跟
隨在一個Video_Sequence_Header的后面。

     3．一個MPEG Picture_header出現的時候，將總是在一個RTP有效載荷的開始處，或
跟隨在一個GOP_header的后面。

   除此之外，還需要：

     4．每一個包還必須包含一個整數數目的視頻片斷(Video slices)。

    應用程序有責任調整放置到每一個RTP包中的片斷的大小和數量，這樣不致于產生底層
的分段(lower level fragmentation)。當傳輸器(transmitrer)的打包器(packetizer)的復雜度有某種
程度的增加時，這種途徑可以簡化接收器(receiver)。考慮到一個片斷可能小到與微塊
(macroblock)相同，可以防止大多數情況下的分段。如果一個包的大小超出了路徑最大傳輸單
元(path maximum transmission unit (path-MTU))[4]，盡管該有效載荷的類型依賴于適合分段的
較低的協議層，但這可能引發綜合服務的包分級(packet classification)方面的問題(例如RSVP
方面)。

    視頻數據后面跟隨了足夠數量的完整的音頻幀，能夠覆蓋包中的視頻段的時間區間。例
如，如果第一個包包含了三個1/900秒的視頻片斷，并使用了44.1khz采樣率的Layer I音頻
編碼，那么只需要有時長384/44100秒的音頻包含在這個包里面。既然該音頻幀的長度(8.71 
msec.)比包含在該包中的視頻段的長度(3.33 msec.)長，那么在接下來的幾個包中就可以不包
含任何的音頻數幀，直到在一個包中的視頻段的歷時擴展到了先前傳輸的音頻幀之外。在本
建議中，另一種選擇是在“無音頻”的包中重發最近的音頻幀來達到包丟失的恢復(resilence)。
此外，應用程序有責任根據最小MTU的尺寸調整捆綁包的大小來避免分段。
2.1. RTP 應用于BMPEG封裝的固的頭部
   下列的RTP頭部域要被使用：

     有效載荷類型(Payload Type):一個獨特的有效載荷類型數字，它有可能是動態的，并
應指派給BMPEG。

     M位(M Bit): 為包含圖象結尾的包而設置。

     時間戳(timestamp)：32位90 khz 時間戳表示MPEG 圖象的采樣時間。如果B圖出現，
那么它可能不是單調增加的。對于包含同一圖象的包，它都是相同的。對于僅包含一個序列、
擴展和/或GOP頭的包，該時間戳是后續圖象的時間戳。
2.2. BMPEG 頭的細節:
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | P |N|MBZ|    Audio Length   | |         Audio Offset          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 MBZ

    P: 圖象類型Picture type (2 bits). I (0), P (1), B (2).

    N: 頭數據改變(1 bit)。如果視頻序列、擴展、GOP和頭數據的任何部分不同于先前傳 
       送的頭，該位將被設置。當所有的頭數據被重發時，該位被重置(參閱 附錄1)。

    MBZ: 必須為0。保留作為將來使用。

    Audio Length音頻長度:  
        (10 bits)以字節(byte)表示該包中音頻數據的長度。音頻數據的開始可以通過從 
        接收包的總長度中減去“Audio Length”得到。 

    Audio Offset 音頻偏移量:  
        (16 bits) 以音頻采樣數表示音頻幀開始處與該包RTP時間戳之間的偏移量(對于 
        多同道源(multi-channel sources)，為達到此目的，覆蓋所有通道的一組采樣被 
        計為一個采樣)。

音頻偏移量在它的兩種補余形式中是一個有符號整數。在44.1khz音頻采樣時，它允許
一個~ +/- 750 msec的偏移。對于視頻幀速率非常低的情況(例如，每秒1幀)，這個偏移量
可能是不夠用的，那么這種有效載荷格式可能是不能用的。

如果B幀出現，音頻幀沒有和視頻一起被重排序(re-ordered)。而是，它們以它們的傳
輸順序與視頻幀一起被打包(例如，與一個對應于P圖的視頻段一起打包的音頻段可能屬于一
個將被后來傳送并應該與這個音頻段同時被呈現的B圖)。盡管視頻段被重排序，對應于一個
特定音頻段的音頻偏移仍然是相對于包含該音頻段的包中的RTP時間戳。

既然一個專用的圖象計數器，象[3]的“時間參考”域，沒有包含在這個有效載荷格式中，
丟失的GOP頭可能沒有被檢測到。這點的唯一影響可能是對于一些編輯過的視頻素材，緊跟
在丟失的GOP頭后面的B圖被錯誤地解碼。
3. 安全性考慮
   使用在本文檔中定義的有效載荷格式的RTP包服從于在RTP規范[1]中討論的安全性考慮。
這意味著媒體流的機密性可以通過加密達到。因為這個有效載荷格式使用的數據壓縮適用于
端對端(end-to-end)，加密可以在壓縮之后執行，這樣兩種操作之間不會發生沖突。

    這個有效載荷類型沒有在接受端包處理的計算復雜度方面顯示出任何重大的非一致性
(non-uniformity)，不會引發潛在的拒絕服務(denial-of-service)的危脅

回顧本有效載荷格式的安全性，沒有發現超出RTP規范需要額外考慮的問題。

附錄 1. 錯誤恢復 (Error Recovery)
    包丟失可以從RTP固定頭中的序列號(sequence number)和時間戳(timestamp)域的組合
檢測到。丟失的范圍可以決定于包中的時間戳、片斷號(slice number)和第一個片斷的水平
位置(horizontal location)。片斷號和水平位置可以決定于片斷頭和第一個微塊
(macroblock)的增量，它們都位于固定的位位置(bit positions)。

    如果組成丟失數據的片斷全部來自同一個圖象，那么跟隨在丟失部分后面的新數據可以
簡單地送到視頻解碼器，它通常重復前一圖象中缺少的象素。下一個音頻幀必須在由包含在
該接收包中的時間戳和音頻偏移量決定的適當的時刻播放。適當的音頻幀(例如，表現背景噪
音)可能需要回饋到音頻解碼器中丟失音頻幀的位置，以保持口形同步(lip-synch)，和/或掩
蓋丟失造成的影響。

    如果在丟失之后的新數據來自下一個圖象(例如，并沒有丟失整個圖象)且N位沒有被設
置，則先前接受到的對于特定圖象類型(由P位決定)的頭可以送到視頻解碼器，后面跟隨新
的數據。如果N位被設置，那么除非通過其它某個通道而使頭對于接收器來說可用，否則可
以采用數據刪除，直到一個新圖象的起始碼。

    如果多于一個圖象的數據被丟失并且頭不可用，那么可以采用再同步
(Resynchronization)到一個新的視頻序列頭部，除非N為0并且對于相同類型的每一個插入
圖象(intervening picture)至少接受到一個包，且這些圖象中的每一個的N位都是0。

   在所有嚴重的包丟失的情況下，如果正確的頭對于丟失的圖象來說是可用的，它們可以送
到視頻解碼器，且可以不考慮N位的值或丟失圖象的數目而使用接受到的數據。

附錄 2. 再同步（Resynchronization）
   如[3]所描述的，頻繁的視頻序列頭的使用使任意次數地參加到節目中成為可能。它也縮
短了在嚴重丟失之后的再同步時間。



參考
   [1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, 
       "RTP: A Transport Protocol for Real-Time Applications",  
       RFC 1889, January 1996.

   [2] ISO/IEC International Standard 13818; "Generic coding of  
       moving pictures and associated audio information",  
       November 1994.

   [3] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, "RTP 
       Payload Format for MPEG1/MPEG2 Video", RFC 2250,  
       January 1998.

   [4] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, 
       November 1990.
作者的地址
   M. Reha Civanlar
   AT&T Labs-Research
   100 Schultz Drive
   Red Bank, NJ 07701
   USA

   EMail: civanlar@research.att.com


   Glenn L. Cash
   AT&T Labs-Research
   100 Schultz Drive
   Red Bank, NJ 07701
   USA

   EMail: glenn@research.att.com


   Barry G. Haskell
   AT&T Labs-Research
   100 Schultz Drive
   Red Bank, NJ 07701
   USA

   EMail: bgh@research.att.com

完整的版權聲明
   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished 
to others, and derivative works that comment on or otherwise explain 
it or assist in its implementation may be prepared, copied, published   
and distributed, in whole or in part, without restriction of any   
kind, provided that the above copyright notice and this paragraph 
are included on all such copies and derivative works.  However, this   
document itself may not be modified in any way, such as by removing   
the copyright notice or references to the Internet Society or other   
Internet organizations, except as needed for the purpose of   
developing Internet standards in which case the procedures for   
copyrights defined in the Internet Standards process must be   
followed, or as required to translate it into languages other than   
English.

   The limited permissions granted above are perpetual and will not 
be revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE 
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING   BUT NOT LIMITED TO ANY 
WARRANTY THAT THE USE OF THE INFORMATION   HEREIN WILL NOT INFRINGE ANY RIGHTS OR 
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
RFC 2343  RTP Payload Format for Bundled MPEG           應用于捆綁的MPEG的RTP有效載荷的格式