本備忘錄狀態(tài)
本文檔講述了一種Internet通信的標(biāo)準(zhǔn)Internet跟蹤協(xié)議,并對其改進(jìn)提出了討論和建
議。請參考最新版本的"InternetOfficial標(biāo)準(zhǔn)化進(jìn)程和狀態(tài)，此備忘錄的發(fā)布不受任何限制。
版權(quán)注重
版權(quán)歸因特網(wǎng)協(xié)會(huì)（1998）所有，保留一切權(quán)利。

摘要
本文檔描述了針對JPEG視頻流的RTP荷載格式。此種包格式針對編碼器參數(shù)基本不變化
的實(shí)時(shí)視頻流進(jìn)行了優(yōu)化。
本文檔是IETF下的視音頻傳輸工作組的產(chǎn)品。意見或建議請發(fā)到該工作組的郵件列表
conf@es.net或直接發(fā)給作者。
本備忘錄的大部分與RFC2035一致，對協(xié)議的改動(dòng)見附錄D。

目錄
1.簡介 3
2.術(shù)語 3
3.RTP上的JPEG 4
4.RTP/JPEG包格式 4
4．1JPEG頭 4
4.1.1類型特定：8比特 5
4.1.2分段偏移:24比特 5
3.1.3類型:8比特 5
3.1.4Q:8比特 5
3.1.5寬度:8比特 5
3.1.6高度:8比特 5
3.1.7復(fù)位標(biāo)記頭 6
3.1.8量化表頭 6
3.1.9JPEG荷載 7
4.討論 7
4.1類型域 7
4.2Q域 8
4.3分片和組裝 9
4.4復(fù)位標(biāo)記 9
5.安全性問題 9
原文作者地址 10
參考文獻(xiàn) 11
附錄A 12
附錄B 13
附錄C 18
附錄D 22
版權(quán)聲明 23

1.簡介
聯(lián)合圖像專家組（JPEG）標(biāo)準(zhǔn)[1,2,3]定義了一組針對連續(xù)色調(diào)靜止圖像的壓縮算法。這
個(gè)靜止圖像壓縮算法同樣也可以應(yīng)用于視頻壓縮，把每一幀都當(dāng)作一個(gè)獨(dú)立的靜態(tài)圖像來進(jìn)
行壓縮，然后再按次序進(jìn)行傳輸。這樣一種視頻編碼通常被稱作運(yùn)動(dòng)JPEG(Motion-JPEG)。
我們首先介紹JPEG的概況，然后描述RTP所支持的JPEG的子集，以及將JPEG幀通過
RTP包來傳輸?shù)臋C(jī)制。
JPEG標(biāo)準(zhǔn)定義了四種操作模式：順序DCT模式，漸進(jìn)DCT模式，無損模式，以及分級模
式。在不同的模式下，一幅圖像用一個(gè)或多個(gè)“節(jié)”來表示，每一節(jié)（在JPEG標(biāo)準(zhǔn)中稱為一
幀）又進(jìn)一步分成若干次掃描。在每一次掃描中，有一種到四種分量，這些分量代表著彩色
信號的分量（例如“紅綠藍(lán)”或一個(gè)亮度分量和兩個(gè)色差分量）。這些分量可以分開在不同
的掃描中編碼，也可以交織在一次單一的掃描中。
每一幀或每一次掃描前面都有一個(gè)頭，可選的壓縮參數(shù)定義，例如量化表和哈夫曼編碼
表。頭信息、可選參數(shù)以及一個(gè)定位符構(gòu)成了一個(gè)頭區(qū)段。每一個(gè)掃描都是一個(gè)經(jīng)過熵編碼
的比特流，位于兩個(gè)頭區(qū)段之間。定位符是字節(jié)對齊的，并且不能在熵編碼部分出現(xiàn)，這樣
對于掃描邊界的確定就無需解析整個(gè)碼流。
壓縮數(shù)據(jù)有三種表示格式：交換格式、緊縮格式和表格描述格式。交換格式包含在熵編
碼過程中用到的所有碼表的定義，緊縮模式中省略了一些碼表定義，假定他們在外部定義或
在前面的圖像中定義。
JPEG標(biāo)準(zhǔn)并不關(guān)心組成圖像的各個(gè)分量的含義或格式。諸如色彩空間和象素縱橫比這些
屬性在JPEG碼流的外部來定義。JPEG文件交換格式（JFIF）在應(yīng)用標(biāo)記段（APPO）提供這
些額外信息，它是一個(gè)事實(shí)上的標(biāo)準(zhǔn)。簡單說來，JFIF文件就是一個(gè)JPEG碼流加上一個(gè)APPO
段。對于視頻來說，另外還有一些參數(shù)在外部定義，比如幀率，逐行掃描還是隔行掃描等等。
盡管JPEG提供了一整套用于靈活壓縮的算法，但是目前能夠?qū)崿F(xiàn)整套標(biāo)準(zhǔn)的低成本硬件
還沒出現(xiàn)。事實(shí)上，絕大部分JPEG硬件編解碼器都只實(shí)現(xiàn)了其中的一個(gè)子集，也就是順序
DCT模式。典型的做法是，頭區(qū)段信息由軟件來解碼，而用硬件來處理一個(gè)在YUV色彩空間
中表示的經(jīng)過熵編碼的單一的掃描。
一次掃描中包含了一系列最小編碼單元（MCU），每個(gè)MCU定義了輸出圖像的一個(gè)小矩形
快的數(shù)據(jù)。
JPEG數(shù)據(jù)中的復(fù)位標(biāo)記表示解碼器應(yīng)當(dāng)在當(dāng)前點(diǎn)復(fù)位它的狀態(tài)。如JPEG中定義的那樣，
復(fù)位標(biāo)記是唯一的能夠嵌入在熵編碼碼流里的標(biāo)記，但他們只能夠在MCU的邊界處出現(xiàn)。一
個(gè)復(fù)位間隔是指兩個(gè)復(fù)位標(biāo)記之間的數(shù)據(jù)部分。每一幀的第一個(gè)復(fù)位間隔是一個(gè)例外，它們
前面沒有復(fù)位標(biāo)記。當(dāng)使用這些標(biāo)記時(shí)，每一幀都由固定數(shù)目的復(fù)位間隔組成。
2.術(shù)語
本文檔中出現(xiàn)的要害字“必須”，“必須不”，“要求的”，“應(yīng)該”，“不應(yīng)該”，“會(huì)”，“不
會(huì)”，“建議”，“或許”，“可選的”按照RFC2119[9]中的描述進(jìn)行解釋。
3.RTP上的JPEG
為了最大化硬件編解碼器的互操作性，我們假定使用順序DCT模式[1,附錄F]，并且限
制預(yù)定義的RTP/JPEG類型碼為單一掃描的隔行圖像。這甚至比基本JPEG更為嚴(yán)格，很多硬
件實(shí)現(xiàn)都不能正確解碼基本JPEG(例如，很多硬件不能解碼逐行掃描)。
實(shí)際上，在一個(gè)視頻碼流中，大部分表格描述的數(shù)據(jù)在一個(gè)視頻碼流中很少發(fā)生變化，
這樣在省略掉所有可以省掉的表格之后，RTP/JPEG數(shù)據(jù)就可以用緊縮格式來表示了。每一幀
一開始是一個(gè)熵編碼的掃描。同時(shí)存在于幀頭和掃描頭中的信息都在RTP/JPEG頭中表示，
RTP/JPEG頭位于RTP頭和JPEG荷載之間。
類似于哈夫曼碼表和色彩空間這樣的參數(shù)在整個(gè)視頻流的生命期中都保持不變，然而另
一些參數(shù)則是可以變化的，例如量化表和圖像大小（為了實(shí)現(xiàn)自適應(yīng)碼率傳輸，答應(yīng)用戶手
工調(diào)節(jié)量化等級或分辨率）。因此RTP/JPEG頭中分配了專門的數(shù)據(jù)域來表示這些信息。因?yàn)?br />量化表中只有一個(gè)小子集是經(jīng)常使用的，我們用一個(gè)短整數(shù)來表示整個(gè)量化表集。一些特定
范圍的值表示使用自定義的量化表，這種情況下量化表位于JPEG荷載之前。圖像的寬和高是
顯式編碼的。
因?yàn)橐粋€(gè)JPEG幀一般總比網(wǎng)絡(luò)的最大包長要大，它必須被切分成若干個(gè)包。一種方法是
在RTP下面的網(wǎng)絡(luò)層來進(jìn)行分片。但是，這種方法使得對于最終數(shù)據(jù)包流的碼流控制及有丟
包情況下的部分發(fā)送成為不可能，而且?guī)L有可能超過網(wǎng)絡(luò)層的最大組裝長度（具體信息參
考[10]）。為了克服這些問題，RTP/JPEG在RTP層定義了一個(gè)簡單的分片/組裝方案。

4.RTP/JPEG包格式
RTP的時(shí)間戳是以90000Hz采樣的，同一幀的每一個(gè)包都必須有同樣的時(shí)間戳。一幀的
最后一個(gè)包的RTP標(biāo)志位必須為1。

4．1JPEG頭
每一個(gè)包的RTP頭之后都緊跟著一個(gè)JPEG頭。這個(gè)頭的前8個(gè)字節(jié)，稱作“主JPEG頭”，
定義如下：

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
類型特定分段偏移
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
類型Q寬高
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

同一個(gè)JPEG幀的的各個(gè)包的所有數(shù)據(jù)域，除了“分段偏移”之外，都必須保持一致。
這個(gè)頭之后可能會(huì)跟著一個(gè)復(fù)位頭和/或量化表頭，這取決于“類型”域和“量化”域的
值。

4.1.1類型特定：8比特
這個(gè)數(shù)據(jù)域的含義取決于“類型”域的值。假如沒有指定，這個(gè)域必須為0并且被接收
端忽略。
4.1.2分段偏移:24比特
分段偏移是當(dāng)前包在整個(gè)JPEG幀中的偏移位置，以字節(jié)為單位，以網(wǎng)絡(luò)字節(jié)次序編碼（最
重要位在前）。分段偏移加上當(dāng)前包中的荷載數(shù)據(jù)長度不能超出2^24字節(jié)。
3.1.3類型:8比特
類型域給出了可能出現(xiàn)在JPEG緊縮格式表格描述或JPEG未定義的JFIF風(fēng)格參數(shù)的信
息。類型0－63在本文檔或本文檔將來的修改中定義，類型64－127與類型0－63相同，除
了在主JPEG頭后緊跟一個(gè)復(fù)位標(biāo)記頭，并且在JPEG數(shù)據(jù)中存在復(fù)位標(biāo)記。類型128－255
可以通過一個(gè)會(huì)話建立協(xié)議來動(dòng)態(tài)定義（這不在本文檔的討論范圍之內(nèi)）。
3.1.4Q:8比特
Q域定義了當(dāng)前幀的量化表。Q值為0－127時(shí)量化表可以通過類型域決定的一個(gè)參數(shù)來
計(jì)算出來（具體計(jì)算方法見后）。Q值為128－255時(shí)會(huì)有一個(gè)量化表頭出現(xiàn)在當(dāng)前幀第一個(gè)
包的主JPEG頭之后。這個(gè)量化表頭用來明確定義量化表。
3.1.5寬度:8比特
寬度域編碼圖像的寬度，以8象素為單位（例如，寬度為40表示圖像寬度為320象素）。
最大寬度為2040象素。
3.1.6高度:8比特
高度域編碼圖像的高度，以8象素為單位（例如，高度為30表示圖像高度為240象素）。
當(dāng)編碼交織視頻時(shí)，這里表示的是一個(gè)視頻場的高度，因?yàn)槊總€(gè)場是單獨(dú)編碼的。最大高度
是2040象素。
3.1.7復(fù)位標(biāo)記頭
在類型64－127時(shí)，復(fù)位標(biāo)記必須緊跟在主JPEG頭之后。它提供了正確解碼一個(gè)包含復(fù)
位標(biāo)記的數(shù)據(jù)流所需要的額外信息。


0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
復(fù)位間隔FL復(fù)位計(jì)數(shù)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

復(fù)位間隔域給出了兩個(gè)復(fù)位標(biāo)記之間MCU的數(shù)目。它和JFIF頭中DRI標(biāo)記段的16比特
值是一致的。這個(gè)值不能為零。
假如一幀中的復(fù)位間隔不能保證在包邊界處對齊，F(xiàn)比特和L比特必須設(shè)為1，復(fù)位計(jì)數(shù)
必須設(shè)為0x3fff。這樣接收端就必須在解碼之前首先重新組裝整個(gè)幀。
為了支持部分幀解碼，必須把一幀分成若干塊，每一塊包含整數(shù)個(gè)復(fù)位間隔。復(fù)位計(jì)數(shù)
域給出第一個(gè)復(fù)位間隔在當(dāng)前塊中的位置，從而接收端可以知道這些數(shù)據(jù)對應(yīng)于當(dāng)前幀的哪
個(gè)部分。復(fù)位間隔長度的選取應(yīng)能夠使一個(gè)塊完全放進(jìn)一個(gè)包中。在這種情況下，F(xiàn)比特和L
比特都必須設(shè)為1。然而，假如一個(gè)塊要放在多個(gè)包里，只有第一個(gè)包的F比特設(shè)為1，也只
有最后一個(gè)包的L比特設(shè)為1。
3.1.8量化表頭
Q值為128－255時(shí)，量化表頭必須出現(xiàn)在主JPEG頭之后（假如存在復(fù)位標(biāo)記頭，則位
于復(fù)位標(biāo)記頭之后）。它提供了一種在帶內(nèi)描述與Q值對應(yīng)的量化表的方法。

0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MBZ精度長度
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
量化表數(shù)據(jù)
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

長度域給出了后面量化表數(shù)據(jù)的長度，以字節(jié)為單位。長度域?yàn)榱惚硎井?dāng)前幀沒有量化表
數(shù)據(jù)。具體信息參考4.2。假如長度域的值比剩余的字節(jié)數(shù)大，整個(gè)包必須丟棄。
包含量化表數(shù)據(jù)時(shí)，表的個(gè)數(shù)取決于JPEG類型域的值。例如。類型0使用兩個(gè)表（一個(gè)
用于亮度分量，另一個(gè)用于色差分量）。每個(gè)表是一個(gè)64個(gè)值得數(shù)組，按zig-zag次序，與
JFIF的DQT標(biāo)記段一致。
對于每一個(gè)量化表，精度域的一個(gè)比特指示了表中系數(shù)的大小。假如這個(gè)比特為0，系數(shù)
為8比特，表長度為64個(gè)字節(jié)。假如該比特為1，系數(shù)就是16比特的，表長度為128字節(jié)。
對于16比特的表系數(shù)，字節(jié)次序是網(wǎng)絡(luò)次序。精度域的最右邊的比特對應(yīng)于第一個(gè)表，后面
的表依次對應(yīng)于左邊的下一個(gè)比特。超出表個(gè)數(shù)的那些比特必須被忽略。
對于Q值為128－254的情況，Q值與量化表之間的映射必須是靜態(tài)的，也就是說，保證
接收端只需要讀一次與某個(gè)Q值對應(yīng)的量化表，就可以正確解碼出所有用該Q值編碼的幀。
解碼器不能依靠于任何以前的量化表，而需要在每幀都重新載入這些量化表。Q＝255并且長
度為0的包是不答應(yīng)的。

3.1.9JPEG荷載
緊跟RTP/JPEG頭的數(shù)據(jù)是包含一次掃描的熵編碼的圖像數(shù)據(jù)。這次掃描不包含掃描頭，
掃描頭的信息可以從RTP/JPEG頭中推出。掃描的結(jié)束可能是隱含的（整幅圖象都已經(jīng)完全解
碼），也可能是顯式的，即跟著一個(gè)EOI標(biāo)記。一次掃描可能會(huì)用一些未定義字節(jié)填充到任
意長度（一些現(xiàn)存的硬件編解碼器會(huì)在一幀圖象的底部生成一些額外的行，解碼器需要對它
們進(jìn)行哈夫曼解碼來去除這些額外的行。
類型碼決定著復(fù)位標(biāo)記是否存在。假如某種類型支持復(fù)位標(biāo)記，數(shù)據(jù)包的復(fù)位頭中必須
包含一個(gè)非零的復(fù)位間隔值，并且復(fù)位標(biāo)記必須是字節(jié)對齊的，以一個(gè)0xFF起始。另外的
0xFF字節(jié)可以出現(xiàn)在復(fù)位間隔之中。在打包過程中，用這樣的方法來進(jìn)行對齊，例如字對齊，
從而實(shí)現(xiàn)比較高效的拷貝。除此之外，復(fù)位標(biāo)記不能出現(xiàn)在碼流中的任何其它地方。不支持
復(fù)位標(biāo)記的類型的碼流在任何地方都不能包含復(fù)位標(biāo)記。在數(shù)據(jù)包中，假如熵編碼產(chǎn)生了一
個(gè)0xFF字節(jié)，則必須在它后面填充一個(gè)0x00字節(jié)。[見文獻(xiàn)1的B.1.1.5]

4.討論
4.1類型域
類型域定義了緊縮的表格描述和JPEG中未定義的額外的JFIF風(fēng)格參數(shù)，因?yàn)檫@些信息
在待傳輸?shù)腏PEG數(shù)據(jù)中不存在。
類型域定義了三種取值范圍。0－63的含義是固定的，在本文檔或本文檔的將來版本中
定義。64－127與0－63的區(qū)別僅在于包含復(fù)位標(biāo)記，并且在主JPEG頭后緊跟著一個(gè)復(fù)位頭，
其余都完全一致。128－255是可以由一個(gè)會(huì)話建立協(xié)議來動(dòng)態(tài)定義的（這不再本文的討論范
圍之內(nèi)）。
對于第一類取值范圍，類型0和類型1目前已經(jīng)定義了，對應(yīng)第二類范圍中的類型64和
類型65。類型0，1指的是基本DCT順序模式、8比特采樣、正方形象素、YUV三種顏色分量
以及標(biāo)準(zhǔn)哈夫曼碼表[在文獻(xiàn)1的附錄K.3中定義]，一次隔行掃描并帶一個(gè)掃描分量選擇子，
來指示是分量1，2還是3。Y，U和V分量分別對應(yīng)于分量1，2，3。分量1使用0號哈夫曼
碼表和0號量化表，分量2和3使用1號哈夫曼碼表和1號量化表。
類型碼2－5定為保留，并禁止使用。基于本文檔以前版本（RFC2035）的應(yīng)用應(yīng)當(dāng)更新
對于類型64和類型65的解釋，指示出有復(fù)位標(biāo)記的存在。
這兩種RTP/JPEG類型當(dāng)前的具體定義如下：

類型分量水平采樣因子.垂直采樣因子量化表序號
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1(Y)210
0,642(U)111
3(V)111
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1(Y)220
1,652(U)111
3(V)111
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

采樣因子說明類型0的視頻的色度分量水平方向上二倍降采樣（一般稱為4：2：2），
而類型1的視頻的色度分量在水平和垂直兩個(gè)方向上都二倍降采樣（一般稱為4：2：0）。
類型0和類型1既可以用于傳輸漸進(jìn)掃描的圖象數(shù)據(jù)，也可以用于傳輸隔行掃描的圖象
數(shù)據(jù)。這兩種不同的數(shù)據(jù)格式在主JPEG頭中加以區(qū)分。具體定義如下：
0：圖象是漸進(jìn)掃描的。在計(jì)算機(jī)顯示器上，它可以按照制定的大小來顯示。
1：當(dāng)前圖像是隔行掃描視頻信號的奇數(shù)場。主JPEG頭中給出的高度是整個(gè)圖象高度的
一半。當(dāng)前場應(yīng)當(dāng)與后面緊跟的偶數(shù)場一起重新恢復(fù)出整幀圖象。偶數(shù)場的行恰好處
于奇數(shù)場對應(yīng)行的上方。
2：當(dāng)前圖象是隔行掃描視頻信號的偶數(shù)場。
3：當(dāng)前圖象是隔行掃描視頻信號的一場，但它將按整幀圖象的大小來單獨(dú)顯示。在計(jì)算
機(jī)顯示器上，每一行都顯示兩遍，圖象高度加倍。
附錄B中給出了將RTP/JPEG頭中的信息變換到JPEG幀頭和掃描頭的C源碼。

4.2Q域
對于JPEG類型0和類型1（以及相應(yīng)的類型64和65），Q值1－99的定義如下。其它
128以下的值保留。
類型0和類型1都需要有兩個(gè)量化表。這些量化表的計(jì)算方法如下：對于1<=Q<=99，
用JPEG組織的公式[5]來計(jì)算一個(gè)標(biāo)量量化因子S：
S=5000/Q假如1<=Q<=50
=200-2*Q假如51<=Q<=99
然后把這個(gè)S值代入[1]中的表K.1和K.2（每個(gè)值都擴(kuò)展到8比特）,就分別得到了量
化表0和量化表1。計(jì)算量化表的C源碼在附錄A中給出。
當(dāng)Q值在128－255之間時(shí)，就需要使用動(dòng)態(tài)定義的量化表。這些量化表既可以在帶內(nèi)定
義，也可以在帶外通過一個(gè)會(huì)話建立協(xié)議來定義。但在每一幀的第一個(gè)包中必須有一個(gè)量化
表頭。當(dāng)量化表在帶外定義時(shí)，可以通過將包頭中的長度域設(shè)為0來省略掉量化表。
當(dāng)在帶內(nèi)傳輸量化表時(shí)，并不需要在每一幀都重復(fù)傳送一遍。類似于帶外的情況，不包
含量化表的幀可以在包頭中將長度域設(shè)置為0。盡管這樣做減小了傳輸量化表帶來的
OVERHEAD，但是也帶來了一些負(fù)面效應(yīng)。一個(gè)新的接收者在收到完整量化表之前接收到的所
有幀都不能夠正確解碼。

4.3分片和組裝
由于JPEG的每一幀都相當(dāng)大，必須經(jīng)過切分才便于傳輸。在將一幀切分成若干個(gè)包的過
程中，應(yīng)當(dāng)避免在低層進(jìn)行分片。假如要求支持部分幀解碼，被切分出的每一個(gè)包就應(yīng)當(dāng)包
含整數(shù)個(gè)復(fù)位間隔（如下）。組成同一幀的數(shù)據(jù)包的時(shí)間戳必須保持一致，并且最后一個(gè)包
的RTP標(biāo)記位必須為1。每個(gè)包的分段偏移域的值是這個(gè)包中數(shù)據(jù)在原來整個(gè)幀中的偏移位
置，以字節(jié)為單位。這些包必須按照次序進(jìn)行傳輸，并且它們所包含的圖象數(shù)據(jù)不能重疊。
整個(gè)一幀圖象以一個(gè)分段偏移為0的包為起始，并以一個(gè)RTP標(biāo)記位為1的包為結(jié)束。可
以通過RTP的順序號或者分段偏移結(jié)合每個(gè)包的長度來檢測丟包。數(shù)據(jù)的重組可以不使用分
段偏移的數(shù)據(jù)（只使用RTP標(biāo)記位和RTP順序號），但是在出現(xiàn)包的亂序的情況下，就不可
能通過簡單的拷貝操作來實(shí)現(xiàn)圖象數(shù)據(jù)的重組。而且，假如前一幀的最后一個(gè)包丟失的話，
即使當(dāng)前幀完好無損，接收段也不能夠正常恢復(fù)出當(dāng)前幀。
4.4復(fù)位標(biāo)記
復(fù)位標(biāo)記插入在JPEG碼流中，告訴接收端哈夫曼解碼器和直流猜測器應(yīng)當(dāng)在當(dāng)前位置復(fù)
位，并且答應(yīng)從當(dāng)前點(diǎn)開始進(jìn)行部分解碼。然而，為了充分實(shí)現(xiàn)部分解碼，解碼器必須知道
一個(gè)復(fù)位間隔中包含的是哪些MCU。為此，原來的JPEG標(biāo)準(zhǔn)中在復(fù)位標(biāo)記中提供了一個(gè)短的
次序號域。但是對于典型的網(wǎng)絡(luò)MTU長度來說，這個(gè)數(shù)域不夠長，不能很好的處理丟包問題。
因此，在RTP/JPEG的復(fù)位頭中包含了額外的信息來處理這個(gè)問題。
復(fù)位間隔的大小應(yīng)當(dāng)使得整數(shù)個(gè)復(fù)位間隔能夠恰好放在一個(gè)數(shù)據(jù)包里。這樣就可以保證
這些包可以相互獨(dú)立地進(jìn)行解碼。假如一個(gè)復(fù)位間隔的結(jié)束處超出了一個(gè)包的長度，可以使
用復(fù)位標(biāo)記頭中的F比特和L比特來對它進(jìn)行切分。但是這樣生成的包的集合必須全部接收
到，接收端才可以正確解碼出那個(gè)復(fù)位間隔中的數(shù)據(jù)。
一旦解碼器接收到一個(gè)F和L都為1的包，或者是一連串的包，第一個(gè)F為1，最后一
個(gè)L為1，它就可以開始解碼了。起始MCU在整幅圖象中的位置可以通過將復(fù)位計(jì)數(shù)的值與
復(fù)位間隔的值相乘來確定。這樣的一個(gè)包（或一連串包）可以包含任意數(shù)量的連續(xù)的復(fù)位間
隔。
為了兼容生成碼流中就包含復(fù)位標(biāo)記但無法按這些復(fù)位標(biāo)記來分片的編碼器，將復(fù)位計(jì)
數(shù)域設(shè)為0x3FFF并且F和L均為1。這樣一種模式意味著解碼器必須對整幅圖象首先進(jìn)行重
組，然后才能解碼。

5.安全性問題
本文檔中所定義的RTP包格式的安全性問題可以遵循[6]和[7]中的建議。這意味著媒體
數(shù)據(jù)流的安全性是通過加密來實(shí)現(xiàn)的。因?yàn)閷τ诿襟w數(shù)據(jù)的壓縮是端到端的，加密操作可以
在壓縮操作之后執(zhí)行，這樣在兩種操作之間就不存在任何沖突。
對于解碼端計(jì)算量不均衡的壓縮編碼計(jì)數(shù)，存在一種潛在的拒絕服務(wù)的攻擊威脅。攻擊
者可以在數(shù)據(jù)流中插入一些惡意的數(shù)據(jù)包，對于這些包的解碼會(huì)導(dǎo)致解碼器運(yùn)算量過載。幸
運(yùn)的是，我們的壓縮編碼算法并沒有明顯的計(jì)算量不均衡現(xiàn)象。
另一種潛在的拒絕服務(wù)威脅存在于我們提出的分片重組機(jī)制。接收端應(yīng)當(dāng)限制重組數(shù)據(jù)
的總長，以避免資源耗盡。
對于任何基于ip的協(xié)議，接收端在某些情況下可能會(huì)因?yàn)榻邮盏竭^多的數(shù)據(jù)包而發(fā)生過
載。網(wǎng)絡(luò)層的鑒定機(jī)制可以將來自不明來源或惡意來源的數(shù)據(jù)包丟棄，但是這樣做所帶來的
成本也是相當(dāng)高的。在組播的環(huán)境里，刪除某些源的數(shù)據(jù)包可以通過IGMP[8]的未來版本和
組播路由協(xié)議來實(shí)現(xiàn)，從而答應(yīng)用戶來選擇哪些數(shù)據(jù)源是答應(yīng)的，哪些是不答應(yīng)的。
對于這種荷載格式的安全性考慮并不超出RTP規(guī)范中的內(nèi)容。

原文作者地址
LanceM.Berc
SystemsResearchCenter
DigitalEquipmentCorporation
130LyttonAve
PaloAltoCA94301

Phone:+16508532100
Email:berc@pa.dec.com

WilliamC.Fenner
XeroXPARC
3333CoyoteHillRoad
PaloAlto,CA94304

Phone:+16508124816
Email:fenner@parc.xerox.com

RonFrederick
XeroxPARC
3333CoyoteHillRoad
PaloAlto,CA94304

Phone:+16508124459
Email:frederick@parc.xerox.com

StevenMcCanne
UniversityofCaliforniaatBerkeley
ElectricalEngineeringandComputerScience
633SodaHall
Berkeley,CA94720

Phone:+15106420865
Email:mccanne@cs.berkeley.edu

PaulStewart
XeroxPARC
3333CoyoteHillRoad
PaloAlto,CA94304

Phone:+16508124821
Email:stewart@parc.xerox.com

參考文獻(xiàn)

[1]ISODIS10918-1.DigitalCompressionandCodingofContinuous-
toneStillImages(JPEG),CCITTRecommendationT.81.

[2]WilliamB.Pennebaker,JoanL.Mitchell,JPEG:StillImageData
CompressionStandard,VanNostrandReinhold,1993.

[3]GregoryK.Wallace,TheJPEGSillPictureCompressionStandard,
CommunicationsoftheACM,April1991,Vol34,No.1,pp.31-44.

[4]TheJPEGFileInterchangeFormat.MaintainedbyC-Cube
Microsystems,Inc.,andavailablein
FTP://ftp.uu.net/graphics/jpeg/jfif.ps.gz.

[5]TomLaneet.Al.,TheIndependentJPEGGroupsoftwareJPEG
codec.Sourcecodeavailablein
ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6a.tar.gz.

[6]Schulzrinne,H.,Casner,S.,Frederick,R.andV.Jacobson,
"RTP:ATransportProtocolforReal-Timeapplications",RFC
1889,January1996.

[7]Schulzrinne,H.,"RTPProfileforAudioandVideoConferences
withMinimalControl",RFC1890,January1996.

[8]Fenner,W.,"InternetGroupManagementProtocolVersion2",RFC
2236,November1997.

[9]Bradner,S.,"KeyWordsforuseinRFCstoIndicateRequirement
Levels",BCP14,RFC2119,March1997.

[10]KentC.,andJ.Mogul,"FragmentationConsideredHarmful",
ProceedingsoftheACMSIGCOMM'87WorkshoponFrontiersin
ComputerCommunicationsTechnology,August1987.

附錄A
下面的代碼用來通過一個(gè)Q因子值生成一個(gè)量化表：

/*
? TableK.1fromJPEGspec.
*/
staticconstintjpeg_luma_quantizer[64]={
16,11,10,16,24,40,51,61,
12,12,14,19,26,58,60,55,
14,13,16,24,40,57,69,56,
14,17,22,29,51,87,80,62,
18,22,37,56,68,109,103,77,
24,35,55,64,81,104,113,92,
49,64,78,87,103,121,120,101,
72,92,95,98,112,100,103,99
};

/*
? TableK.2fromJPEGspec.
*/
staticconstintjpeg_chroma_quantizer[64]={
17,18,24,47,99,99,99,99,
18,21,26,66,99,99,99,99,
24,26,56,99,99,99,99,99,
47,66,99,99,99,99,99,99,
99,99,99,99,99,99,99,99,
99,99,99,99,99,99,99,99,
99,99,99,99,99,99,99,99,
99,99,99,99,99,99,99,99
};

/*
? CallMakeTableswiththeQfactorandtwou_char[64]returnarrays
*/
void
MakeTables(intq,u_char*lqt,u_char*cqt)
{
intI;
intfactor=q;

if(q<1)factor=1;
if(q>99)factor=99;
if(q<50)
q=5000/factor;
else
q=200–factor*2;

for(I=0;I<64;I++){
intlq=(jpeg_luma_quantizer[I]*q+50)/100;
intcq=(jpeg_chroma_quantizer[I]*q+50)/100;

/*Limitthequantizersto1<=q<=255*/
if(lq<1)lq=1;
elseif(lq>255)lq=255;
lqt[I]=lq;

if(cq<1)cq=1;
elseif(cq>255)cq=255;
cqt[I]=cq;
}
}

附錄B
下面這段代碼用來生成對應(yīng)于那些RTP/JPEG中不存在的表描述數(shù)據(jù)的JPEG標(biāo)記段。

U_charlum_dc_codelens[]={
0,1,5,1,1,1,1,1,1,0,0,0,0,0,0,0,
};

u_charlum_dc_symbols[]={
0,1,2,3,4,5,6,7,8,9,10,11,
};

u_charlum_ac_codelens[]={
0,2,1,3,3,2,4,3,5,5,4,4,0,0,1,0x7d,
};

u_charlum_ac_symbols[]={
0x01,0x02,0x03,0x00,0x04,0x11,0x05,0x12,
0x21,0x31,0x41,0x06,0x13,0x51,0x61,0x07,
0x22,0x71,0x14,0x32,0x81,0x91,0xa1,0x08,
0x23,0x42,0xb1,0xc1,0x15,0x52,0xd1,0xf0,
0x24,0x33,0x62,0x72,0x82,0x09,0x0a,0x16,
0x17,0x18,0x19,0x1a,0x25,0x26,0x27,0x28,
0x29,0x2a,0x34,0x35,0x36,0x37,0x38,0x39,
0x3a,0x43,0x44,0x45,0x46,0x47,0x48,0x49,
0x4a,0x53,0x54,0x55,0x56,0x57,0x58,0x59,
0x5a,0x63,0x64,0x65,0x66,0x67,0x68,0x69,
0x6a,0x73,0x74,0x75,0x76,0x77,0x78,0x79,
0x7a,0x83,0x84,0x85,0x86,0x87,0x88,0x89,
0x8a,0x92,0x93,0x94,0x95,0x96,0x97,0x98,
0x99,0x9a,0xa2,0xa3,0xa4,0xa5,0xa6,0xa7,
0xa8,0xa9,0xaa,0xb2,0xb3,0xb4,0xb5,0xb6,
0xb7,0xb8,0xb9,0xba,0xc2,0xc3,0xc4,0xc5,
0xc6,0xc7,0xc8,0xc9,0xca,0xd2,0xd3,0xd4,
0xd5,0xd6,0xd7,0xd8,0xd9,0xda,0xe1,0xe2,
0xe3,0xe4,0xe5,0xe6,0xe7,0xe8,0xe9,0xea,
0xf1,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,
0xf9,0xfa,
};

u_charchm_dc_codelens[]={
0,3,1,1,1,1,1,1,1,1,1,0,0,0,0,0,
};

u_charchm_dc_symbols[]={
0,1,2,3,4,5,6,7,8,9,10,11,

};

u_charchm_ac_codelens[]={
0,2,1,2,4,4,3,4,7,5,4,4,0,1,2,0x77,
};

u_charchm_ac_symbols[]={
0x00,0x01,0x02,0x03,0x11,0x04,0x05,0x21,
0x31,0x06,0x12,0x41,0x51,0x07,0x61,0x71,
0x13,0x22,0x32,0x81,0x08,0x14,0x42,0x91,
0xa1,0xb1,0xc1,0x09,0x23,0x33,0x52,0xf0,
0x15,0x62,0x72,0xd1,0x0a,0x16,0x24,0x34,
0xe1,0x25,0xf1,0x17,0x18,0x19,0x1a,0x26,
0x27,0x28,0x29,0x2a,0x35,0x36,0x37,0x38,
0x39,0x3a,0x43,0x44,0x45,0x46,0x47,0x48,
0x49,0x4a,0x53,0x54,0x55,0x56,0x57,0x58,
0x59,0x5a,0x63,0x64,0x65,0x66,0x67,0x68,
0x69,0x6a,0x73,0x74,0x75,0x76,0x77,0x78,
0x79,0x7a,0x82,0x83,0x84,0x85,0x86,0x87,
0x88,0x89,0x8a,0x92,0x93,0x94,0x95,0x96,
0x97,0x98,0x99,0x9a,0xa2,0xa3,0xa4,0xa5,
0xa6,0xa7,0xa8,0xa9,0xaa,0xb2,0xb3,0xb4,
0xb5,0xb6,0xb7,0xb8,0xb9,0xba,0xc2,0xc3,
0xc4,0xc5,0xc6,0xc7,0xc8,0xc9,0xca,0xd2,
0xd3,0xd4,0xd5,0xd6,0xd7,0xd8,0xd9,0xda,
0xe2,0xe3,0xe4,0xe5,0xe6,0xe7,0xe8,0xe9,
0xea,0xf2,0xf3,0xf4,0xf5,0xf6,0xf7,0xf8,
0xf9,0xfa,
};

u_char*
MakeQuantHeader(u_char*p,u_char*qt,inttableNo)
{
*p++=0xff;
*p++=0xdb;/*DQT*/
*p++=0;/*lengthmsb*/
*p++=67;/*lengthlsb*/
*p++=tableNo;
memcpy(p,qt,64);
return(p+64);
}

u_char*
MakeHuffmanHeader(u_char*p,u_char*codelens,intncodes,
u_char*symbols,intnsymbols,inttableNo,
inttableClass)
{
*p++=0xff;

*p++=0xc4;/*DHT*/
*p++=0;/*lengthmsb*/
*p++=3+ncodes+nsymbols;/*lengthlsb*/
*p++=(tableClass<<4)tableNo;
memcpy(p,codelens,ncodes);
p+=ncodes;
memcpy(p,symbols,nsymbols);
p+=nsymbols;
return(p);
}

u_char*
MakeDRIHeader(u_char*p,u_shortdri){
*p++=0xff;
*p++=0xdd;/*DRI*/
*p++=0x0;/*lengthmsb*/
*p++=4;/*lengthlsb*/
*p++=dri>>8;/*drimsb*/
*p++=dri&0xff;/*drilsb*/
return(p);
}

/*
? Arguments:
? type,width,height:assuppliedinRTP/JPEGheader
? lqt,cqt:quantizationtablesaseitherderivedfrom
? theQfieldusingMakeTables()orasspecified
? insection4.2.
? dri:restartintervalinMCUs,or0ifnorestarts.
*
? p:pointertoreturnarea
*
? Returnvalue:
? Thelengthofthegeneratedheaders.
*
? Generateaframeandscanheadersthatcanbeprependedtothe
? RTP/JPEGdatapayloadtoprodUCeaJPEGcompressedimagein
? interchangeformat(exceptforpossibletrailinggarbageand
? absenceofanEOImarkertoterminatethescan).
*/
intMakeHeaders(u_char*p,inttype,intw,inth,u_char*lqt,
u_char*cqt,u_shortdri)
{
u_char*start=p;

/*convertfromblockstopixels*/
w<<=3;
h<<=3;

*p++=0xff;
*p++=0xd8;/*SOI*/

p=MakeQuantHeader(p,lqt,0);
p=MakeQuantHeader(p,cqt,1);

if(dri!=0)
p=MakeDRIHeader(p,dri);

*p++=0xff;
*p++=0xc0;/*SOF*/
*p++=0;/*lengthmsb*/
*p++=17;/*lengthlsb*/
*p++=8;/*8-bitprecision*/
*p++=h>>8;/*heightmsb*/
*p++=h;/*heightlsb*/
*p++=w>>8;/*widthmsb*/
*p++=w;/*wudthlsb*/
*p++=3;/*numberofcomponents*/
*p++=0;/*comp0*/
if(type==0)
*p++=0x21;/*hsamp=2,vsamp=1*/
else
*p++=0x22;/*hsamp=2,vsamp=2*/
*p++=0;/*quanttable0*/
*p++=1;/*comp1*/
*p++=0x11;/*hsamp=1,vsamp=1*/
*p++=1;/*quanttable1*/
*p++=2;/*comp2*/
*p++=0x11;/*hsamp=1,vsamp=1*/
*p++=1;/*quanttable1*/
p=MakeHuffmanHeader(p,lum_dc_codelens,
sizeof(lum_dc_codelens),
lum_dc_symbols,
sizeof(lum_dc_symbols),0,0);
p=MakeHuffmanHeader(p,lum_ac_codelens,
sizeof(lum_ac_codelens),
lum_ac_symbols,
sizeof(lum_ac_symbols),0,1);
p=MakeHuffmanHeader(p,chm_dc_codelens,
sizeof(chm_dc_codelens),
chm_dc_symbols,
sizeof(chm_dc_symbols),1,0);
p=MakeHuffmanHeader(p,chm_ac_codelens,
sizeof(chm_ac_codelens),
chm_ac_symbols,
sizeof(chm_ac_symbols),1,1);

*p++=0xff;
*p++=0xda;/*SOS*/
*p++=0;/*lengthmsb*/
*p++=12;/*lengthlsb*/
*p++=3;/*3components*/
*p++=0;/*comp0*/
*p++=0;/*Successtable0*/
*p++=1;/*comp1*/
*p++=0x11;/*Successtable1*/
*p++=2;/*comp2*/
*p++=0x11;/*Successtable1*/
*p++=0;/*firstDCTcoeff*/
*p++=63;/*lastDCTcoeff*/
*p++=0;/*Successiveapprox.*/

return(p–start);
};

附錄C
下面這段代碼用來闡明RTP/JPEG數(shù)據(jù)包分片和頭的生成過程。

Forclarityandbrevity,thestructuredefinitionsareonlyvalidfor
32-bitbig-endian(mostsignificantoctetfirst)architectures.Bit
fieldsareassumedtobepackedtightlyinbig-endianbitorder,with
noadditionalpadding.Modificationswouldberequiredtoconstructa
portableimplementation.

/*
? RTPdataheaderfromRFC1889
*/
typedefstruct{
unsignedintversion:2;/*protocolversion*/
unsignedintp:1;/*paddingflag*/
unsignedintx:1;/*headerextensionflag*/
unsignedintcc:4;/*CSRCcount*/
unsignedintm:1;/*markerbit*/
unsignedintpt:7;/*payloadtype*/
u_int16seq;/*sequencenumber*/
u_int32ts;/*timestamp*/
u_int32ssrc;/*synchronizationsource*/
u_int32csrc[1];/*optionalCSRClist*/
}rtp_hdr_t;

#defineRTP_HDR_SZ12

/*ThefollowingdefinitionisfromRFC1890*/
#defineRTP_PT_JPEG26

structjpeghdr{
unsignedinttspec:8;/*type-specificfield*/
unsignedintoff:24;/*fragmentbyteoffset*/
u_int8type;/*idofjpegdecoderparams*/
u_int8q;/*quantizationfactor(ortableid)*/
u_int8width;/*framewidthin8pixelblocks*/
u_int8height;/*frameheightin8pixelblocks*/
};

structjpeghdr_rst{
u_int16dri;
unsignedintf:1;
unsignedintl:1;
unsignedintcount:14;
};

structjpeghdr_qtable{
u_int8mbz;
u_int8precision;
u_int16length;
};

#defineRTP_JPEG_RESTART0x40

/*ProcedureSendFrame:
*
? Arguments:
? start_seq:Thesequencenumberforthefirstpacketofthecurrent
? frame.
? ts:RTPtimestampforthecurrentframe
? ssrc:RTPSSRCvalue
? jpeg_data:HuffmanencodedJPEGscandata
? len:LengthoftheJPEGscandata
? type:ThevaluetheRTP/JPEGtypefieldshouldbesetto
? typespec:ThevaluetheRTP/JPEGtype-specificfieldshouldbeset
? to
? width:ThewidthinpixelsoftheJPEGimage
? height:TheheightinpixelsoftheJPEGimage
? dri:ThenumberofMCUsbetweenrestartmarkers(or0ifthere
? arenorestartmarkersinthedata
? q:TheQfactorofthedata,tobespecifiedusingtheIndependent
? JPEGgroup'salgorithmif1<=q<=99,specifiedexplicitly
? withlqtandcqtifq>=128,orundefinedotherwise.
? lqt:Thequantizationtablefortheluminancechannelifq>=128
? cqt:Thequantizationtableforthechrominancechannelsif
? q>=128
*
? Returnvalue:
? thesequencenumbertobesentforthefirstpacketofthenext
? frame.
*
? Thefollowingareassumedtobedefined:
*
*PACKET_SIZE-Thesizeoftheoutgoingpacket
? send_packet(u_int8*data,intlen)-Sendsthepackettothenetwork
*/

u_int16SendFrame(u_int16start_seq,u_int32ts,u_int32ssrc,
u_int8*jpeg_data,intlen,u_int8type,
u_int8typespec,intwidth,intheight,intdri,
u_int8q,u_int8*lqt,u_int8*cqt){
rtp_hdr_trtphdr;
structjpeghdrjpghdr;
structjpeghdr_rstrsthdr;

structjpeghdr_qtableqtblhdr;
u_int8packet_buf[PACKET_SIZE];
u_int8*ptr;
intbytes_left=len;
intseq=start_seq;
intpkt_len,data_len;

/*InitializeRTPheader
*/
rtphdr.version=2;
rtphdr.p=0;
rtphdr.x=0;
rtphdr.cc=0;
rtphdr.m=0;
rtphdr.pt=RTP_PT_JPEG;
rtphdr.seq=start_seq;
rtphdr.ts=ts;
rtphdr.ssrc=ssrc;

/*InitializeJPEGheader
*/
jpghdr.tspec=typespec;
jpghdr.off=0;
jpghdr.type=type((dri!=0)?RTP_JPEG_RESTART:0);
jpghdr.q=q;
jpghdr.width=width/8;
jpghdr.height=height/8;

/*InitializeDRIheader
*/
if(dri!=0){
rsthdr.dri=dri;
rsthdr.f=1;/*ThiscodedoesnotalignRis*/
rsthdr.l=1;
rsthdr.count=0x3fff;
}

/*Initializequantizationtableheader
*/
if(q>=128){
qtblhdr.mbz=0;
qtblhdr.precision=0;/*Thiscodeuses8bittablesonly*/
qtblhdr.length=128;/*264-bytetables*/
}

while(bytes_left>0){
ptr=packet_buf+RTP_HDR_SZ;
memcpy(ptr,&jpghdr,sizeof(jpghdr));

ptr+=sizeof(jpghdr);

if(dri!=0){
memcpy(ptr,&rsthdr,sizeof(rsthdr));
ptr+=sizeof(rsthdr);
}

if(q>=128&&jpghdr.off==0){
memcpy(ptr,&qtblhdr,sizeof(qtblhdr));
ptr+=sizeof(qtblhdr);
memcpy(ptr,lqt,64);
ptr+=64;
memcpy(ptr,cqt,64);
ptr+=64;
}

data_len=PACKET_SIZE–(ptr–packet_buf);
if(data_len>=bytes_left){
data_len=bytes_left;
rtphdr.m=1;
}

memcpy(packet_buf,&rtphdr,RTP_HDR_SZ);
memcpy(ptr,jpeg_data+jpghdr.off,data_len);

send_packet(packet_buf,(ptr–packet_buf)+data_len);

jpghdr.off+=data_len;
bytes_left-=data_len;
rtphdr.seq++;
}
returnrtphdr.seq;
}

附錄D
這一部分給出了本文檔相對于RFC2035的改動(dòng)。這些改動(dòng)著眼于盡可能保持新版本對于
舊版本的兼容性。事實(shí)上，很多已經(jīng)廢棄的約定仍然能夠在新版中正常地解碼。盡管如此，
我們?nèi)匀粡?qiáng)烈反對在新版中使用一些舊地約定。
o類型0和類型1現(xiàn)在可以編碼隔行掃描的視頻圖象，用類型特定域中的兩個(gè)比特給
出指示即可。參見4.1節(jié)。
oJPEG工作組曾經(jīng)就如何更靈活地描述JPEG量化表發(fā)生過爭論。本備忘錄答應(yīng)通過使
用一個(gè)可選地量化表頭來顯式地描述表系數(shù)。這些內(nèi)容在節(jié)3.1.8和4.2中討論。


o在RFC2035中，在類型域中描述復(fù)位標(biāo)記的信息，這樣就很難再加入新的類型。并
且，類型特定域用于記錄復(fù)位計(jì)數(shù)，這樣其它的一些類型特定信息就無法編碼。在
本備忘錄中，復(fù)位標(biāo)記的指示移到了類型域中的一個(gè)特定比特位，并且加入了可選
頭來編碼一些必要的額外信息，而把類型特定域留出來用于它本來的用途。對于部
分幀解碼的處理提高了碼流的健壯性，能夠?qū)挂欢ǔ潭鹊膩G包。具體信息參見
3.1.7和4.4。

版權(quán)聲明
版權(quán)歸Internet協(xié)會(huì)所有（1998）。保留所有權(quán)利。
本文及其譯本可以提供給其他任何人，可以預(yù)備繼續(xù)進(jìn)行注釋，可以繼續(xù)拷貝、出版、發(fā)
布，無論是全部還是部分，沒有任何形式的限制，不過要在所有這樣的拷貝和后續(xù)工作中提
供上述聲明和本段文字。無論如何，本文檔本身不可以做任何的修改，比如刪除版權(quán)聲明或
是關(guān)于因特耐特協(xié)會(huì)、其他的因特耐特組織的參考資料等。除了是為了開發(fā)Internet標(biāo)準(zhǔn)的
需要，或是需要把它翻譯成除英語外的其他語言的時(shí)候，在這種情況下，在Internet標(biāo)準(zhǔn)程
序中的版權(quán)定義必須被附加其中。
上面提到的有限授權(quán)答應(yīng)永遠(yuǎn)不會(huì)被Internet協(xié)會(huì)或它的繼續(xù)者或它的下屬機(jī)構(gòu)廢除。
本文檔和包含在其中的信息以"Asis"提供給讀者，Internet社區(qū)和Internet工程任務(wù)
組不做任何擔(dān)保、解釋和暗示，包括該信息使用不破壞任何權(quán)利或者任何可商用性擔(dān)保或特
定目的。