一種基于TCP的實時視頻傳輸延時預測模型

摘 要:針對TCP重傳易導致延時抖動大、降低流媒體播放質量的問題，提出了使用TCP傳輸實時視頻時，播放質量不受TCP重傳影響的必要條件，即視頻幀發送延時、播放緩沖區延時與網絡往返時間需要滿足一定的關系式。建立了視頻幀發送延時的預測模型，該模型通過輸入視頻幀長度、丟包率、網絡往返時間、TCP擁塞窗口大小與TCP超時重傳時間，預測視頻幀的發送延時。NS2模擬結果表明，可以通過發送延時的預測值來判斷視頻幀是否適合采用TCP傳輸。

關鍵詞:傳輸控制協議; 實時視頻; 延時; 預測

中圖分類號:TP393文獻標志碼:A

文章編號:1001-3695(2010)06-2239-04

doi:10.3969/j.issn.1001-3695.2010.06.069

TCPbased realtime video transmission delay prediction model

XIONG Yonghua1， WU Min1， JIA Weijia2

(1.School of Information Science Engineering， Central South University， Changsha 410083， China; 2.Dept. of Computer Science， City University of Hong Kong， Hong Kong 999077， China)

Abstract:Aimed to larger endtoend delays and jitters and worse playing quality posed by the TCP retransmission for the multimedia streaming transmitting via Internet using TCP， this paper proposed the necessary conditions to overcome effect on video playing quality caused by TCP retransmission， such as the formula describing the relationship between video frame sendingdelays， play out buffer delays and round trip time (RTT). It presented a prediction model to predict the video frame sendingdelays with input parameters as video frame lengths， network loss ratio， RTT， TCP congestion window size， and TCP retransmission timeout (RTO). Experiments using NS2 simulator show that the prediction value of video frame sendingdelays can be used to determine whether it is feasible for a video frame to be transsmitted using TCP protocol.

Key words:TCP(transmission control protocol); realtime video; delay; prediction

TCP是當前Internet上使用最為廣泛的傳輸層協議，其最主要的特點是面向連接，采用加法增加乘法減少(AIMD)機制進行擁塞控制，采用滑動窗口協議進行流量控制，采用請求重傳機制進行差錯控制[1]，這些使得TCP對于網絡擁塞反應迅速、具有TCP友好性、容易被大多數防火墻所接受，但也導致了傳輸的吞吐率波動、端到端延時及抖動均大于同等條件下的UDP傳輸。

基于此，有研究人員認為TCP不適用于對于延時、抖動有嚴格要求的實時視頻傳輸[2]。但由于UDP自身的簡單、無連接和不可靠性，使得基于UDP的實時視頻傳輸還需要重新設計擁塞控制、流量控制與差錯控制機制，同時也需要考慮視頻流的TCP友好性與防火墻穿透能力等，這些都增加了傳輸機制設計與維護的難度，并減少了其通用性能，商用的Internet實時視頻傳輸系統，如Skype、Realplayer和QQ等，大都擯棄了設計維護較為復雜的UDP方式，而采用基于TCP的方式。

TCP的優點及其在Internet與商業領域的廣泛應用，也激勵著研究者對TCP實時視頻傳輸的研究與開發。文獻[3]提出了一個接收方驅動的TCP連接帶寬分配系統;文獻[4]提出了一種擴展的TCP以支持實時流媒體應用;文獻[5]設計了一種基于單個流多個TCP連接的實時多媒體傳輸系統;文獻[6]提出了一個隨機模型用于評估TCP實時與存儲視頻的傳輸性能;文獻[7]提出了播放緩沖區自適應算法，用于隨機丟包環境的無線網絡視頻流傳輸;文獻[8，9]通過設置視頻幀的優先級來控制幀率;文獻[10]設計了一個具備聯合緩沖區管理與擁塞控制機制的視頻傳輸系統;文獻[11]設計了一個基于多緩沖區調度算法的幀率自適應傳輸策略。

本文針對Internet上的TCP實時視頻雙向傳輸過程，分析推導了采用TCP傳輸實時視頻的可行性與必要條件，設計了一種實時視頻幀的發送延時預測模型，通過發送延時的預測值來判斷視頻幀是否適合采用TCP傳輸。

1 TCP實時視頻傳輸的局限性

實時流媒體傳輸在接收方通常需要設置播放緩沖區用于消除IP包的延時抖動，即接收方在IP包到達以后不是立即播放，而是將其放入播放緩沖區中等待一個時間段Dplayout以后再進行播放，從而通過增加流媒體整體的端到端延時，擴大了單個包的延時抖動范圍。文獻[4]推導了TCP播放緩沖區延時Dplayout與媒體包延時的關系為

Dplayout≥32RTT+3period+delta(1)

其中:Dplayout為播放緩沖區延時;RTT(roundtrip time)為TCP的網絡往返時間;period為兩個報文段的發送間隔時間，等于流媒體的采樣間隔;delta為補償時間，如緩沖區的存取耗時等。在報文段丟失后，TCP通過收到三次重復ACK(acknowledgement)的快重傳機制對丟失的報文段進行重傳，如果Dplayout滿足式(1)，則表明報文段的重傳所造成的延時能被播放緩沖區所消除，即重傳的媒體報文段能夠在接收端按時播放，此時因TCP重傳所造成的延時對于接收端而言是透明的，因而說明了TCP實時流媒體傳輸在滿足式(1)的條件下是可行的。

文獻[4]只考慮了一個視頻幀只通過一個TCP報文段(segment)進行傳輸的理想情況，而實際傳輸過程中一個經過編碼壓縮后的實時視頻幀往往大于TCP最大報文段(maximum segment size， MSS)，因此TCP需要將視頻幀分為多個報文段進行發送，而當報文段數目大于TCP當前發送窗口大小時，視頻幀需要經過多個RTT周期才能完成發送，如圖1所示。

設一個視頻幀可以被分為n個TCP報文段(從S1到Sn)，在第i(1≤i≤n)個RTT開始時TCP發送窗口大小為Wi個報文段，則在第i個RTT內，發送端最多可以發送Wi個報文段，當Wi

∑ki=1Wi≥n(2)

定義Dsend為視頻幀的第一個報文段從TCP發送緩沖區進入網絡，到其最后一個報文段進入網絡的時間間隔(最后一個報文段可能是最末尾的一個報文段，也有可能是因丟包而重傳的報文段)。當最后一個發送窗口無丟包時，Dsend=(k-1)#8226;RTT;而當其有丟包時，由于需要一個額外的RTT時間來重傳丟失的報文，Dsend=k#8226;RTT。

根據文獻[4]和式(1)的思想:如果TCP的播放緩沖區能夠消除因為TCP重傳而造成的延時抖動，則這時采用TCP傳輸實時流媒體才是可行的。而由圖1可知，當視頻幀的大小超過一個TCP最大報文段時，該視頻幀需要多個RTT周期才能完成發送，此時的Dsend包括了在這些RTT周期中TCP重傳所造成的延時抖動，因此根據式(1)的思想，此時的TCP播放緩沖區需滿足

Dplayout≥Dsend+12RTT(3)

才能消除因為TCP重傳所帶來的延時抖動，由式(3)可得

Dsend≤Dplayout-12RTT(4)

當Dplayout為常量時，一個視頻幀的發送延時需滿足式(4)，否則該視頻幀將錯過其播放時間，造成嚴重的延時抖動，降低視頻播放質量，即TCP實時視頻的傳輸在滿足式(4)時是可行的。

2 視頻幀發送延時的特性

定義Dframe(i)為第i個視頻幀從采樣生成，到接收端開始播放之間的端到端延時;Dwait(i)為第i個視頻幀進入TCP發送緩沖區，到該視頻幀的第一個報文段開始被發送的時間間隔;Dnetwork(i)為第i個視頻幀從發送端網絡層到接收端網絡層的傳播延時。為便于研究，可認為Dnetwork(i)=0.5RTT，則根據文獻[11]，有

Dframe(i)=Dwait(i)+Dsend(i)+C(5)

其中:C為常量。設P為視頻幀的采樣間隔時間，令

A(i-1)=Dwait(i-1)+Dsend(i-1)-P(6)

則當A(i-1)>0時，第i-1個視頻幀尚未全部從TCP發送緩沖區進入網絡，而后續的第i個視頻幀已經生成并進入了TCP發送緩沖區，因此有Dwait(i)=A(i-1);反之，若A(i-1)≤0，則第i個視頻幀生成時，第i-1個視頻幀已經完成發送，此時有Dwait(i)=0。因此有

Dwait(i)=0A(i-1)≤0

A(i-1)A(i-1)>0(7)

令Dwait(1)=0，將式(6)代入式(7)并迭代，得到

Dairt(i)≥max0，∑i-1j=1Dsend(j)-(i-1)#8226;P

(8)

將式(8)代入式(5)有

Dframe(i)≥max0，∑i-1j=1Dsend(j)-(i-1)#8226;P+Dsend(i)+C(9)

可見，使用TCP傳輸實時視頻時，視頻幀的發送延時不僅決定了該視頻幀自身能否在接收端按時播放，而且也將影響其后序視頻幀的端到端延時。

發送延時Dsend的大小取決于RTT以及TCP擁塞窗口的大小及變化規律，這些是由RTT、丟包率與TCP的擁塞控制、流量控制與差錯控制機制共同決定的。因此，在不修改TCP的前提下無法對發送延時進行控制，但是可以利用影響發送延時的相關參數對發送延時進行預測。當預測的視頻幀發送延時滿足式(4)時，可認為該幀能正常播放，反之該幀將具有不合要求的端到端延時，并且還將加大其后續幀的端到端延時，不適合采用TCP傳輸。由此可見，視頻幀發送延時的預測值能作為制定TCP視頻傳輸機制的參考因素。

3 視頻幀發送延時預測模型

3.1 假設條件

本文使用TCP Reno及其SACK補充版本，這是當前所有Windows操作系統默認的以及Internet上使用最為廣泛的TCP版本，并作如下假設:

a)TCP發送緩沖區的大小能夠容納多個連續的視頻幀，TCP的接收緩沖區能夠及時將所收到的數據提交給應用層，而不會造成視頻幀在TCP接收緩沖區溢出。TCP發送與接收緩沖區大小主要由端主機的性能決定，因此該假設條件易滿足。

b)不同RTT內的丟包事件相互獨立，而同一個RTT內，若發送窗口有報文丟失，則該窗口中自該報文以后的報文也全部丟失。由于TCP SACK機制有能力一次重傳同一窗口中所有丟失的報文，該假設不會影響報文的傳輸與重傳時間。

c)根據TCP，其發送窗口大小等于擁塞窗口(congestion window)和發送方廣告窗口(advertise window)的最小值，因此假設接收方廣告窗口足夠大(廣告窗口大小由主機性能決定)，則發送方窗口大小等于擁塞窗口大小。

d)假設TCP連接已經建立，并且關閉了Nagel算法，且不會產生糊涂窗口綜合癥。由于是雙向的視頻流，采用捎帶(piggyback)ACK方式，不適用延時ACK。

根據上述假設，本文忽略了TCP的三次握手階段和延時ACK補償階段，認為一個TCP報文段可處于慢開始、重傳和擁塞避免三種階段。定義三種階段的發送延時分別為Dslow、Dre和Dcon，而報文段處于三種階段的概率分別為Pslow、Pre和Pcon，則有期望的視頻幀發送延時為

E[Dsend]=PslowDslow+PreDre+PconDcon=

E[Dslow]+E[Dre]+E[Dcon](10)

3.2 慢開始階段的發送延時

設視頻幀的長度為S個TCP MSS，Sslow為慢開始階段結束以前已成功發送的報文段數目(即在Dslow內發送的報文段數目，不包括丟失的報文段)。設網絡丟包率為p(p≥0)，當p=0時，可以期望在Dslow內發送完所有的S個報文段，即E[Sslow]=S;當p>0時，假設包丟失與包發送事件相互獨立，則有離散隨機變量Sslow的概率分布為P{Sslow=k|k∈(0，S)}=(1-p)k#8226;p因此有

E[Sslow]=∑S-1k=0[(1-p)k#8226;p#8226;k]+(1-p)s#8226;S，p>0(11)

在慢開始階段，接收方每收到一個ACK就將擁塞窗口大小增加一個報文段，設第i個RTT周期TCP擁塞窗口大小為Wi，則有Wi=2#8226;Wi-1。若在第i個RTT內能發送完Sslow，則有Sslow=W1+2W1+…+2i-1W1=(2i-1)#8226;W1，從而i=log2(Sslow/W1+1)，其中W1為第一個RTT，即視頻幀開始被傳輸時的TCP擁塞窗口的大小，因此有

E[Dslow]=E[i#8226;RTT]=RTT#8226;log2(E[Sslow]/W1+1)(12)

其中:E[Sslow]取值如式(11)。設此時擁塞窗口大小為Wslow，則有Wslow=2i-1W1=(Sslow+W1)/2，從而得到

E[Wslow]=(E[Sslow]+W1)/2(13)

3.3 重傳階段的發送延時

傳輸完S個報文段以后沒有出現丟包現象的概率為(1-p)S，因此在傳輸S個報文期間至少出現一個丟包現象，即TCP進入重傳階段的概率為1-(1-p)S。

TCP通過兩種方式判斷是否進入重傳階段:收到三個以上的重復ACK(Dup ACK)或者出現重傳計時器超時(retransmission timeout， RTO)。文獻[13]推導了TCP因為RTO而進入擁塞避免階段的概率Q(p，W)為

min1，1+(1-p)3#8226;(1-(1-p)W-3)

(1-(1-p)W)/(1-(1-p)3)(14)

其中:p為丟包率，W為擁塞避免階段開始時TCP擁塞窗口的大小。因此，TCP因為收到三次重復ACK而進入擁塞避免的概率為1-Q(p，W)。

定義ZTO為從RTO恢復所需時間，ZTD為從重復ACK機制恢復所需時間，根據文獻[13]有:

E[ZTO]=G(p)#8226;T0/(1-p)(15)

其中:T0為首次出現RTO時重傳計時器所設置的時間間隔，G(p)為

G(p)=1+p+2p2+4p3+8p4+16p5+32p6(16)

E[ZTD]的取值取決于同一發送窗口內丟包的數目及TCP的版本，本文針對TCP Reno及SACK選項，可以在一個RTT內重傳一個窗口內所有丟失的報文，因此有E[ZTD]=RTT，從而

E[Dre]=(1-(1-p)S)#8226;(E[ZTO]#8226;Q(p，E[WSlow])+

RTT#8226;(1-Q(p，E[Wslow])))

(17)

其中:p為網絡丟包率，S為視頻幀的長度，E[ZTO]可由式(15)求得，E[Wslow]可由式(13)求得，p和E[Wslow]作為式(14)的輸入參數。

在重傳階段，若是因RTO重傳，則并未發送新的報文段，即SRTO=0;若是因三次重復ACK重傳，則有窗口大小一半的新數據段被發送，即STD=0.5Wslow，因此重傳階段期望發送的報文段長度

E[Sre]=(1-Q(p，E[Wslow]))#8226;0.5E[Wslow](18)

3.4 擁塞避免階段的發送延時

在對丟失報文重傳以后，TCP進入擁塞避免階段，所發送的剩余報文段長度為

E[Scon]=S-E[Sslow]-E[Sre](19)

根據文獻[13]所建立的擁塞避免階段TCP擁塞窗口大小的模型，在開始發送剩余報文段時，TCP擁塞窗口的期望值

E[Wcon]=23+8(1-p)3P+1(20)

利用文獻[13]提出的TCP擁塞避免階段的平均吞吐率模型，得到擁塞避免階段吞吐率B為

1-pp+E[Wcon]2+Q(p，E[Wcon])

RTT#8226;12E[Wcon]+1+T0#8226;Q(p，E[Wcon])#8226;G(p)1-p(21)

因此，有擁塞避免階段的期望發送延時

E[Dcon]=E[Scon]/B(22)

將式(12)(17)(22)代入式(10)得到E[Dsend]的值為p、S、W1、RTT和T0的函數，記為E[Dsend]=f(p，S，W1，RTT，T0)。

4 模擬實驗與性能分析

4.1 模擬環境描述

在NS2下對發送延時性能與預測模型進行驗證與分析，所采用的NS2模擬環境拓撲結構如圖2所示。

TCP發送端與接收端分別與路由器R1和R2連接，設置路由器R1隊列長度為50，鏈路最小RTT為60 ms，MSS=1 000 Byte。發送端輸入一個自定義的視頻流量(video traffic)，該流量的生成來自于一個基于H.263標準的視頻追蹤(video trace)文件。Video trace文件由一段H.263編碼的視頻生成，主要記錄了視頻幀的大小及其發送時間，如表1所示。

表1 實時視頻追蹤文件格式

參數

幀編號

12…100

發送時間/s0.20.4…20

幀大小/Byte12 5396 604…8 073

所使用的視頻文件長度為20 s，采用基于H.263可變比特率編碼標準壓縮成100個大小不同的視頻幀，幀間間隔為200 ms。

4.2 模擬結果及性能分析

發送延時預測的目的在于利用預測值來判斷實時視頻幀是否適合采用TCP傳輸，據此制定相應的TCP傳輸策略。根據E[Dsend]=f(p，S，W1，RTT，T0)，預測模型輸出量為視頻幀發送延時的期望值，輸入量為丟包率p，視頻幀長度S，發送時刻TCP擁塞窗口大小W1、網絡往返時間RTT和超時計時器T0。設RTT=100 ms，取T0=4RTT，采用同一段視頻文件，并取Dplayout=400 ms，當路由器R1為尾部丟包策略(drop tail)時，設置p=0和p=1.8%，當R1為隨機早期丟包策略(random early detection， RED)時，設置p=2.1%，得到模型輸入參數與預測結果分別如圖3和4所示。

在圖3中，當p=0時，擁塞窗口W1在第二幀以后開始超過幀大小S，并且持續增加;當p=1.8%時，由于路由器是采用drop tail策略，數據包的丟失具有爆發性(burst)，丟包現象集中出現在第7~27幀間，且在第7幀時出現了RTO，使得窗口大小直接跌到最小值，第31幀之后擁塞窗口開始線性增長，并在第40幀以后超過幀大小;當p=2.1%時，路由器基于RED策略，丟失的數據包較為分散，且均采用快重傳、快恢復機制，沒有出現RTO，從而使得擁塞窗口呈現鋸齒狀波動。

圖4(a)是p=0，drop tail策略的情形。此時Dframe的值最大為726 ms，平均值為652 ms，所有視頻幀都滿足Internet實時視頻的傳輸要求，這說明了式(4)必要條件的合理性。根據式(4)，通過實際值Dsend判斷所有的視頻幀都適合采用TCP傳輸，而通過預測值E[Dsend]也判斷所有的視頻幀都適合TCP傳輸，因此，預測判斷的漏判率為0，準確程度為100%。

圖4(b)是p=1.8%，RED策略的情形。Dsend的變化規律與Dframe基本一致，通過Dsend判斷為不適合的幀，其Dframe也較大，符合式(4)的必要條件。預測值對實際值波峰的跟隨性較好，通過實際值可以判斷在100個視頻幀中不符合必要條件的視頻幀有5個，編號集為actual(40，42，73，75，91);通過預測值判斷不符合條件的視頻幀有7個，編號集為prediction(13，40，42，73，91，96，97)，其中4個幀(40，42，73，91)包含在actual中。因此采用預測判斷時漏掉了1個不合要求的幀，而將3個符合要求的幀判斷為不合要求，即預測判斷的漏判率為1%，準確程度為96%。

圖4(c)是p=2.1%，drop tail策略的情形。Actual集有19幀，prediction集有26幀，其中18幀在actual 中，因此預測判斷漏判率為1%，準確程度為92%。

5 結束語

本文基于TCP Reno和TCP SACK版本，通過分析TCP實時視頻傳輸的可行性與局限性，提出了如果視頻播放質量不受網絡丟包及TCP重傳影響，則視頻幀發送延時所必須滿足的約束條件。為了能在視頻幀被發送以前就判斷它的發送延時是否滿足該約束條件，即判斷該視頻幀是否適合采用TCP傳輸，建立了一個視頻幀發送延時預測模型，通過判斷發送延時的預測值是否滿足約束條件，來決定視頻幀能否采用TCP傳輸。使用NS2模擬平臺，在不同路由器丟包策略和丟包率環境下的實驗表明，使用模型預測值進行判斷，漏判率為0%~1%，準確程度為92%~100%，因此，可以通過發送延時的預測值來判斷視頻幀是否適合采用TCP傳輸。

筆者下一步將研究如何利用發送延時預測模型來制定新的TCP實時視頻傳輸策略，如利用發送延時的預測值進行選擇丟幀、幀率調整、播放緩沖區自適應調整等。

參考文獻:

[1]熊永華， 吳敏， 賈維嘉. 實時流媒體傳輸技術研究綜述[J]. 計算機應用研究， 2009，26(10): 3615-3620.

[2]FLOYD S， HANDLEY M， PADHYE J， et al. Equation based congestion control for unicast applications[C]//Proc of ACM SIGCOMMk. 2000: 43-56.

[3]MEHRA P， De VLEESCHOUWER C， ZAKHOR A. Receiverdriven bandwidth sharing for TCP and its application to video streaming[J]. IEEE Trans on Multimedia，2005，7(4): 740-752.

[4]LIANG S， CHERITON D. TCPRTM: using TCP for realtime multimedia applications[C]//Proc of International Conference on Network Protocols(ICNP). 2002: 1-20.

[5]NGUYEN T， CHEUNG S. Multimedia streaming using multiple TCP connections[C]//Proc of the 24th IEEE International Conference on Performance， Computing， and Communications. 2005: 215-223.

[6]BOHACEK S. A stochastic model of TCP and fair video transmission[C]//Proc of INFOCOM.2003: 1134-1144.

[7]ANTONIOS A. Improving the performance of TCP wireless video streaming with a novel playback adaptation algorithm[C]//Proc of IEEE International Conference on Multimedia and Expo. 2006: 1169-1172.

[8]SEELAM N， SETHI P， FENG W C. A hysteresis based approach for quality， frame rate， and buffer management for video streaming using TCP[C]//Proc of the Management of Multimedia Networks and Services Conference.2001: 1-15.

[9]KRASIC C， WALPOLE J. Priorityprogress streaming for qualityadaptive multimedia[C]//Proc of ACM Multimedia Doctoral Symposium.2001: 463-464.

[10]BAJIC I V， TICKOO O， BALAN A， et al. Integrated endtoend buffer management and congestion control for scalable video communications[C]//Proc of International Conference on Image Processing.2003: 14-17.

[11]XIONG Yonghua， WU Min， JIA Weijia. Efficient frame schedule scheme for realtime video transmission across the Internet using TCP[J]. Journal of Networks， 2009， 4(3): 216-223.

[12]FLOYD S， MAHDAVI J， MATHIS M， et al. IETF RFC 2883，An extension to the selective acknowledgement (SACK) option for TCP[S]. 2000.

[13]PADHYE J， FIROIU V， TOWSLEY D， et al. Modeling TCP Reno performance: a simple model and its empirical validation[J]. IEEE/ACM Trans on Networking， 2000， 8(2): 133-145.