本備忘錄的狀態(tài)

這份備忘錄定義了一個(gè)應(yīng)用于Internet業(yè)界的實(shí)驗(yàn)性的協(xié)議。本備忘錄沒有規(guī)定一個(gè)任
何種類的Internet標(biāo)準(zhǔn)。它需要得到進(jìn)一步的討論和建議。本備忘錄的分發(fā)是沒有限制的。

版權(quán)通告

Copyright(C)TheInternetSociety(1998).AllRightsReserved.

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

MPEG-2國際標(biāo)準(zhǔn)由三個(gè)層次組成：音頻，視頻和系統(tǒng)[2]。音頻和視頻層定義了相應(yīng)的
“基本流(elementarystreams)”的語法和語義。系統(tǒng)層支持多重壓縮流的同步和交叉，緩
沖區(qū)的初始化和治理，以及時(shí)間的鑒定。RFC2250[3]描述了為傳輸單獨(dú)的音頻和視頻基本流，
即傳輸流，而采用的打包技術(shù)，該流在系統(tǒng)層定義，使用RTP。
捆綁打包方案是必須的，因?yàn)閷?duì)于某些重要的應(yīng)用，它比其他的方案有幾個(gè)優(yōu)勢(shì)。這些
應(yīng)用包括了視頻點(diǎn)播(VOD)，在那里音頻和視頻總是一起使用。與音頻和視頻和獨(dú)立打包相比，
其優(yōu)勢(shì)在于：

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

2．提供音頻和視頻的顯式的同步(implicitsynchronization)。當(dāng)音頻和視頻數(shù)據(jù)以
交叉格式存儲(chǔ)在服務(wù)器時(shí)，這是一個(gè)明顯的便利。

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

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

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

并且，與傳輸層流的打包相比，其優(yōu)勢(shì)在于：

1．總開銷的減少。它不包含系統(tǒng)層的信息，對(duì)于RTP這是多余的。（essentiallythey
addresssimilarissues）

2．更輕易進(jìn)行錯(cuò)誤恢復(fù)。因?yàn)榻Y(jié)構(gòu)化的打包與應(yīng)用層分幀(applicationlayerframing
(ALF))規(guī)則相一致，丟失掩蔽(lossconcealment)和錯(cuò)誤恢復(fù)(errorrecovery)更加簡(jiǎn)單而
有效。
2.捆綁的MPEG視頻和音頻的封裝
視頻封裝遵循與在[3]中描述的適用于MPEG基流(MPEGelementarystreams)的封裝相似
的規(guī)則。非凡地：

1．MPEGVideo_Sequence_Header出現(xiàn)的時(shí)候，將總是在一個(gè)RTP有效載荷的開始處。

2．一個(gè)MPEGGOP_header出現(xiàn)的時(shí)候，將總是在一個(gè)RTP有效載荷的開始處，或跟
隨在一個(gè)Video_Sequence_Header的后面。

3．一個(gè)MPEGPicture_header出現(xiàn)的時(shí)候，將總是在一個(gè)RTP有效載荷的開始處，或
跟隨在一個(gè)GOP_header的后面。

除此之外，還需要：

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

應(yīng)用程序有責(zé)任調(diào)整放置到每一個(gè)RTP包中的片斷的大小和數(shù)量，這樣不致于產(chǎn)生底層
的分段(lowerlevelfragmentation)。當(dāng)傳輸器(transmitrer)的打包器(packetizer)的復(fù)雜度有某種
程度的增加時(shí)，這種途徑可以簡(jiǎn)化接收器(receiver)。考慮到一個(gè)片斷可能小到與微塊
(macroblock)相同，可以防止大多數(shù)情況下的分段。假如一個(gè)包的大小超出了路徑最大傳輸單
元(pathmaximumtransmissionunit(path-MTU))[4]，盡管該有效載荷的類型依靠于適合分段的
較低的協(xié)議層，但這可能引發(fā)綜合服務(wù)的包分級(jí)(packetclassification)方面的問題(例如RSVP
方面)。

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

有效載荷類型(PayloadType):一個(gè)獨(dú)特的有效載荷類型數(shù)字，它有可能是動(dòng)態(tài)的，并
應(yīng)指派給BMPEG。

M位(MBit):為包含圖象結(jié)尾的包而設(shè)置。

時(shí)間戳(timestamp)：32位90khz時(shí)間戳表示MPEG圖象的采樣時(shí)間。假如B圖出現(xiàn)，
那么它可能不是單調(diào)增加的。對(duì)于包含同一圖象的包，它都是相同的。對(duì)于僅包含一個(gè)序列、
擴(kuò)展和/或GOP頭的包，該時(shí)間戳是后續(xù)圖象的時(shí)間戳。
2.2.BMPEG頭的細(xì)節(jié):
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PNMBZAudioLengthAudioOffset
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MBZ

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

N:頭數(shù)據(jù)改變(1bit)。假如視頻序列、擴(kuò)展、GOP和頭數(shù)據(jù)的任何部分不同于先前傳
送的頭，該位將被設(shè)置。當(dāng)所有的頭數(shù)據(jù)被重發(fā)時(shí)，該位被重置(參閱附錄1)。

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

AudioLength音頻長(zhǎng)度:
(10bits)以字節(jié)(byte)表示該包中音頻數(shù)據(jù)的長(zhǎng)度。音頻數(shù)據(jù)的開始可以通過從
接收包的總長(zhǎng)度中減去“AudioLength”得到。

AudioOffset音頻偏移量:
(16bits)以音頻采樣數(shù)表示音頻幀開始處與該包RTP時(shí)間戳之間的偏移量(對(duì)于
多同道源(multi-channelsources)，為達(dá)到此目的，覆蓋所有通道的一組采樣被
計(jì)為一個(gè)采樣)。

音頻偏移量在它的兩種補(bǔ)余形式中是一個(gè)有符號(hào)整數(shù)。在44.1khz音頻采樣時(shí)，它答應(yīng)
一個(gè)~+/-750msec的偏移。對(duì)于視頻幀速率非常低的情況(例如，每秒1幀)，這個(gè)偏移量
可能是不夠用的，那么這種有效載荷格式可能是不能用的。

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

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

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

回顧本有效載荷格式的安全性，沒有發(fā)現(xiàn)超出RTP規(guī)范需要額外考慮的問題。

附錄1.錯(cuò)誤恢復(fù)(ErrorRecovery)
包丟失可以從RTP固定頭中的序列號(hào)(sequencenumber)和時(shí)間戳(timestamp)域的組合
檢測(cè)到。丟失的范圍可以決定于包中的時(shí)間戳、片斷號(hào)(slicenumber)和第一個(gè)片斷的水平
位置(horizontallocation)。片斷號(hào)和水平位置可以決定于片斷頭和第一個(gè)微塊
(macroblock)的增量，它們都位于固定的位位置(bitpositions)。

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

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

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

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

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



參考
[1]Schulzrinne,H.,Casner,S.,Frederick,R.,andV.Jacobson,
"RTP:ATransportRFC1889,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.
作者的地址
M.RehaCivanlar
AT&TLabs-Research
100SchultzDrive
RedBank,NJ07701
USA

EMail:civanlar@research.att.com


GlennL.Cash
AT&TLabs-Research
100SchultzDrive
RedBank,NJ07701
USA

EMail:glenn@research.att.com


BarryG.Haskell
AT&TLabs-Research
100SchultzDrive
RedBank,NJ07701
USA

EMail:bgh@research.att.com

完整的版權(quán)聲明
Copyright(C)TheInternetSociety(1998).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnished
toothers,andderivativeworksthatcommentonorotherwiseeXPlain
itorassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraph
areincludedonallsUChcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurpoSEOf
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnot
berevokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERINGTASKFORCE
DISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDINGBUTNOTLIMITEDTOANY
WARRANTYTHATTHEUSEOFTHEINFORMATIONHEREINWILLNOTINFRINGEANYRIGHTSOR
ANYIMPLIEDWARRANTIESOFMERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.