應用於捆綁的MPEG的RTP有效載荷的格式

這份文檔描述了一種適合於捆綁的、MPEG-2編碼的、可以應用RTP協議的視頻和音頻數
據的有效載荷類型，這是第二版。對於這種有效載荷類型，當它用於ApsaraVideo for VOD應用系統時，
捆綁具有明顯的優勢。當這種優勢足夠重要，以至於可以犧牲已分離的音頻視頻流的模組化
時，就可能使用這種有效載荷。
1.介紹
這份文檔描述了一種適用於MPEG-2編碼的、使用即時傳輸協議(RTP)第二版[1]的音頻和
視頻流的捆綁式打包方案。

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

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

2．提供音頻和視頻的顯式的同步(implicitsynchronization)。當音頻和視頻資料以
交叉格式儲存在伺服器時，這是一個明顯的便利。

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

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

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

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

1．總開銷的減少。它不包含系統層的資訊，對於RTP這是多餘的。（essentiallythey
addresssimilarissues）

2．更容易進行錯誤恢複。因為結構化的打包與應用程式層分幀(applicationlayerframing
(ALF))規則相一致，丟失掩蔽(lossconcealment)和錯誤恢複(errorrecovery)更加簡單而
有效。
2.捆綁的MPEG視頻和音訊封裝
視頻封裝遵循與在[3]中描述的適用於MPEG基流(MPEGelementarystreams)的封裝相似
的規則。特別地：

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

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

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

除此之外，還需要：

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

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

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

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

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

時間戳記(timestamp)：32位90khz時間戳記表示MPEG圖象的採樣時間。如果B圖出現，
那麼它可能不是單調增加的。對於包含同一圖象的包，它都是相同的。對於僅包含一個序列、
擴充和/或GOP頭的包，該時間戳記是後續圖象的時間戳記。
2.2.BMPEG頭的細節:
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PNMBZAudioLengthAudioOffset
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MBZ

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

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

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

AudioLength音頻長度:
(10bits)以位元組(byte)表示該包中音頻資料的長度。音頻資料的開始可以通過從
接收包的總長度中減去“AudioLength”得到。

AudioOffset音頻位移量:
(16bits)以音頻採樣數表示音訊框架開始處與該包RTP時間戳記之間的位移量(對於
多同道源(multi-channelsources)，為達到此目的，覆蓋所有通道的一組採樣被
計為一個採樣)。

音頻位移量在它的兩種補餘形式中是一個有符號整數。在44.1khz音頻採樣時，它允許
一個~+/-750msec的位移。對於視訊框架速率非常低的情況(例如，每秒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.錯誤恢複(ErrorRecovery)
包丟失可以從RTP固定頭中的序號(sequencenumber)和時間戳記(timestamp)域的組合
檢測到。丟失的範圍可以決定於包中的時間戳記、片斷號(slicenumber)和第一個片斷的水平
位置(horizontallocation)。片斷號和水平位置可以決定於片斷頭和第一個微塊
(macroblock)的增量，它們都位於固定的位位置(bitpositions)。

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

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

如果多於一個圖象的資料被丟失並且頭不可用，那麼可以採用再同步
(Resynchronization)到一個新的視頻序列頭部，除非N為0並且對於相同類型的每一個插入
圖象(interveningpicture)至少接受到一個包，且這些圖象中的每一個的N位都是0。

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

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

參考
[1]Schulzrinne,H.,Casner,S.,Frederick,R.,andV.Jacobson,
"RTP:ATransportProtocolforReal-TimeApplications",
RFC1889,January1996.

[2]ISO/IECInternationalStandard13818;"Genericcodingof
movingpicturesandassociatedaudioinformation",
November1994.

[3]Hoffman,D.,Fernando,G.,Goyal,V.,andM.Civanlar,"RTP
PayloadFormatforMPEG1/MPEG2Video",RFC2250,
January1998.

[4]Mogul,J.,andS.Deering,"PathMTUDiscovery",RFC1191,
November1990.