專利名稱：預設速率匹配信號通知的方法和裝置的制作方法
技術領域：
本發(fā)明總的涉及一種多媒體流，更具體地，涉及一種在多媒體流服務中在服務器和客戶端之間的速率匹配。
背景技術：
在多媒體流服務中，包括三個部分流服務器、流客戶端和傳輸信道或者底層網(wǎng)絡。通常從吞吐量方面和可靠性(即，假設沒有吞吐量比特率保證)方面來說，傳輸信道是服務的瓶頸，但是在客戶端和/或服務器上也會發(fā)生吞吐量受限。
在實時流系統(tǒng)中，由于信道、客戶端和服務器的動態(tài)變化吞吐量的特點，為了保持對用戶的實時重放機制，流傳送需要是自適應的。服務器需要讓傳輸率適應于系統(tǒng)變化的吞吐量。在Haskell et al.(美國專利No.5565924，“用于可變信道的編碼/解碼緩沖器控制”)中可以發(fā)現(xiàn)這樣的速率匹配系統(tǒng)的例子。
流客戶端在讓輸入數(shù)據(jù)通過并到達用于播放的媒體解碼器之前，為其提供用于存儲的接收器緩沖。接收緩沖器用于補償源編碼率(也稱為采樣率)和傳輸率(預解碼器緩沖)之間的差。它還用于補償在信道上的信息包傳送延遲變化(抖動緩沖)。通常，假設在一個單一的接收器緩沖器中組合有這兩種功能。但是，它們也可以通過在接收器中兩個單獨的緩沖器來完成，雖然這樣的執(zhí)行從延遲的觀點看不是最優(yōu)的。接收器緩沖還可以消除自適應偏差(即，如果系統(tǒng)吞吐量沒有和服務器輸出完全匹配)。
如果接收器緩沖器變空(即緩沖器下溢)，這意味著解碼器要解碼的數(shù)據(jù)溢出，客戶端需要暫停播放并在重新開始之前再次緩沖輸入數(shù)據(jù)。另一方面，如果輸入數(shù)據(jù)速率比播放速率快，那么接收器緩沖器空間會被用完(即緩沖器溢出)，這會導致為了給新的輸入數(shù)據(jù)信息包提供空間而從緩沖器中拋棄信息包。當拋下信息包時，視頻質(zhì)量將下降。為了確保平穩(wěn)和完美的播放，客戶端的接收器緩沖器應當保持在一定的充滿范圍內(nèi)。為了保證接收器緩沖器不會下溢或溢出，必須充分控制在服務器中傳輸和采樣以及在客戶端接收和播放的比特率。
在下面的描述中，將參考定義下列曲線的比特率發(fā)展曲線圖來描述比特率控制(在水平軸上是以秒為單位的時間；在垂直軸上，是以字節(jié)或比特為單位的數(shù)據(jù)累計量)—播放曲線，P(t)，表示解碼器在給定的時間內(nèi)從接收器緩沖器處理的數(shù)據(jù)累計量；—采樣曲線，S(t)，表示如果媒體編碼器實時運行時的數(shù)據(jù)產(chǎn)生進度(這是播放曲線的對應物，實際上是其時間變換的版本)；—傳輸曲線，T(t)，表示在給定時間內(nèi)由服務器送出的數(shù)據(jù)累計量；和—接收曲線，R(t)，表示在給定時間內(nèi)接收并送入客戶端緩沖器中的數(shù)據(jù)累計量。
任意兩個曲線之間的差定義這兩個曲線之間的延遲和“緩沖器大小”。比特率控制將會受到在兩個曲線間差上的某些限制(例如，最大緩沖器大小，或最大延遲)的制約。圖1表示一種典型比特率發(fā)展曲線圖。
在確定用于服務器和客戶端比特率控制中配合的最佳配置時，將考慮以下內(nèi)容A.采樣曲線一將把控制(即傳輸比特率的選擇)完全留給服務器去處理，因為1)只有服務器知道每個比特流的準確特性，例如切換位置、幀優(yōu)先權(quán)、下一幀的尺寸，并且2)可能沒有和網(wǎng)絡比特率匹配的比特流速率，服務器能夠執(zhí)行一些“技巧”(例如細化、來回切換)。
B.傳輸曲線一也會把控制(即傳輸速率)留給服務器去處理(即使用RTCP(實時控制協(xié)議)報告或其它來自客戶端的帶寬信息)，因為1)通常，只有服務器可以檢測在線數(shù)據(jù)量，和2)如果采樣曲線控制具有受限的靈活性，可能需要使傳輸速率適應采樣曲線。
通過使其采樣曲線S(t)適應其傳輸曲線T(t)，服務器應當保持一定的實時制約。通過適當?shù)木彌_，使采樣曲線適應傳輸曲線，保證接收器能夠以正確的同步播放媒體。在每一時刻t，采樣曲線S(t)應當不會以太大的字節(jié)量從傳輸曲線T(t)偏離。
如果服務器在由實時制約定義的限制內(nèi)操作，客戶端負責提供任何必要的緩沖，以在限制內(nèi)跟隨服務器。在這種情況，客戶端必須為下面部分進行補償1)為|S(t)-T(t)|的預解碼緩沖，和2)為傳輸延遲變化{T(t)-R(t)}的抖動緩沖。
此外，客戶端必須允許在播放曲線和采樣曲線之間的任何失配(例如，由于客戶端平臺操作系統(tǒng)問題造成的時鐘漂移或重放減速)。
在多媒體流系統(tǒng)中，發(fā)送器或服務器需要在每個時刻決定如何去給其將要發(fā)送的后面的信息包編碼(以什么樣的速率)并決定什么時間進行發(fā)送它。在正常操作中，發(fā)送器能夠通過只使用RTCP報告的接收器保持實時播放。3GPP(第3代合作方案)信息包切換流服務(PSS)定義標準視頻緩沖要求，其用于為在VBR(可變比特率)視頻壓縮和傳輸(參見3GPP TS 26.234 V5.1.0，“Transparent End-to-End Packet Switched Streaming Service(PSS)；Protocols andCodeces(Release 5)”，2002年六月，在下文中稱為TS 26.234)中固有的編碼和特定服務器延遲變化進行補償。當流服務器和客戶端都遵守該緩沖要求時，可以保證客戶端能夠在沒有客戶端緩沖器擾亂(即在客戶端不會存在緩沖器下溢或溢出)的情況下播放由服務器傳輸?shù)牧鳎诤愣ㄑ舆t和可靠的傳輸信道上提供從服務器傳輸?shù)牧?。但是，在一些例如移交、中繼或時鐘漂移的情況下這是不太可能的。結(jié)果，發(fā)送器和接收器可能會執(zhí)行相互抵觸的操作，并在用戶使用中發(fā)生嚴重惡化。
在現(xiàn)有技術中，通過RTSP(實時流協(xié)議)標題字段速度(音頻和/或視頻子采樣)和尺寸(比特率的倍增或遞減)的使用，接收器改變其緩沖器等級。在IETF RFC2326中定義了這些標題。接收器也可以利用如在“End-to-End bit rateadaptation for PSS”，3GPP SA4 doc S4-030024所述的通過客戶端的比特率切換命令。

發(fā)明內(nèi)容
本發(fā)明如下劃分在發(fā)送器和接收器之間的速率匹配職責服務器負責—使傳輸速率適應于接收速率(即擁擠控制)。
—使采樣率適應于傳輸速率(即管理變換和將其保持在速率匹配操作范圍內(nèi))。
接收器負責—補償信息包傳輸延遲變化(即網(wǎng)絡抖動)。
—設置服務器速率匹配操作范圍的參數(shù)(即變換范圍)。
通過說明所允許的服務器發(fā)送的信息包的最小和最大變換，用于服務器速率匹配的操作范圍確定了“服務器的動態(tài)調(diào)度”的限制。在服務器和接收器之間轉(zhuǎn)換服務器速率匹配操作范圍的參數(shù)，以使得在例如移交、中繼和時鐘漂移的情況下下溢、溢出和質(zhì)量惡化的發(fā)生率最小化。
因此，本發(fā)明的第一個方面提供一種多媒體流網(wǎng)絡中在客戶端自適應控制接收器緩沖器等級的方法，該流網(wǎng)絡包括用于向客戶端提供數(shù)據(jù)流的服務器，其中接收器緩沖器用于補償在服務器的數(shù)據(jù)傳輸量和客戶端的數(shù)據(jù)使用量之間的差，以允許客戶端具有滿意的數(shù)據(jù)流量以非中斷方式播放，所述方法包括在客戶端定義至少一個參數(shù)，用于確定速率匹配操作范圍，得以在服務器和客戶端之間執(zhí)行速率匹配；根據(jù)所述的至少一個參數(shù)使在服務器中的數(shù)據(jù)量適應于接收率；和根據(jù)上述調(diào)節(jié)在客戶端調(diào)整傳輸延遲變化。
根據(jù)本發(fā)明，該至少一個參數(shù)包括最小變換量，其表示服務器中一個信息包的采樣時間和傳輸時間之間的差，以允許在服務器中根據(jù)該最小變換量執(zhí)行所述調(diào)節(jié)。
根據(jù)本發(fā)明，該至少一個參數(shù)包括目標變換量，其表示大于服務器中一個信息包的采樣時間和傳輸時間之間的差的變換量，以允許在服務器中根據(jù)該目標變換量執(zhí)行所述調(diào)節(jié)。
根據(jù)本發(fā)明，該至少一個參數(shù)包括指定在已經(jīng)發(fā)送的字節(jié)數(shù)和已經(jīng)采樣的字節(jié)數(shù)之間的最大差的數(shù)目，以允許服務器執(zhí)行所述調(diào)節(jié)。
根據(jù)本發(fā)明，通過調(diào)節(jié)傳輸速率或采樣速率或?qū)烧哌M行調(diào)節(jié)以執(zhí)行所述在服務器中的調(diào)節(jié)。
根據(jù)本發(fā)明，該至少一個參數(shù)包括用于防止在客戶端的播放中斷的時鐘變換量。
根據(jù)本發(fā)明，該方法還包括根據(jù)至少一個參數(shù)使在服務器中的采樣速率適應于傳輸速率的步驟。
根據(jù)本發(fā)明，把最小變換量、目標變換量、指定數(shù)目和時鐘中的兩個或更多個一同發(fā)送到服務器。
本發(fā)明的第二個方面提供一種多媒體流系統(tǒng)。該系統(tǒng)包括至少一個客戶端，和用于向客戶端提供數(shù)據(jù)流的服務器，客戶端具有接收器緩沖器，用于補償在服務器的數(shù)據(jù)傳輸量和客戶端的數(shù)據(jù)使用量之間的差，使得允許客戶端具有滿意的數(shù)據(jù)流量進行非中斷方式的播放，其中客戶端包括用于定義至少一個確定速率匹配操作范圍的參數(shù)的機構(gòu)，以允許服務器根據(jù)所述至少一個參數(shù)使數(shù)據(jù)量適應于接收率；和用于根據(jù)所述調(diào)節(jié)調(diào)整信息包傳輸延遲變化的機構(gòu)。
根據(jù)本發(fā)明，所述至少一個參數(shù)包括最小變換量，其表示服務器中一個信息包的采樣時間和傳輸時間之間的差，以允許服務器根據(jù)該最小變換量執(zhí)行所述調(diào)節(jié)；目標變換量，其表示大于服務器中一個信息包的采樣時間和傳輸時間之間的差的變換量，以允許在服務器中根據(jù)該目標變換量執(zhí)行所述調(diào)節(jié)；指定在已經(jīng)發(fā)送的字節(jié)數(shù)和已經(jīng)采樣的字節(jié)數(shù)之間的最大差的數(shù)目，和用于防止在客戶端的播放中斷的時鐘變換量。
根據(jù)本發(fā)明，服務器包括調(diào)節(jié)機構(gòu)，用于根據(jù)所述的至少一個參數(shù)使采樣速率適應于傳輸速率。
本發(fā)明的第三方面提供一種在多媒體流網(wǎng)絡中在客戶端使用的軟件產(chǎn)品，用于自適應地控制在客戶端中接收器緩沖器的等級，該多媒體流網(wǎng)絡包括能夠向客戶端提供數(shù)據(jù)流的服務器，其中該接收器緩沖器用于補償在服務器的數(shù)據(jù)傳輸量和客戶端的數(shù)據(jù)使用量之間的差，使得允許客戶端具有滿意的數(shù)據(jù)流量進行非中斷方式的播放，所述軟件產(chǎn)品包括用于定義至少一個在服務器中確定速率匹配操作范圍的參數(shù)的代碼，以在服務器和客戶端之間執(zhí)行速率匹配；和用于根據(jù)所述調(diào)節(jié)調(diào)整信息包傳輸延遲變化的代碼。
根據(jù)本發(fā)明，所述至少一個參數(shù)包括最小變換量，其表示服務器中一個信息包的采樣時間和傳輸時間之間的差；目標變換量，其表示大于服務器中一個信息包的采樣時間和傳輸時間之間的差的變換量；指定在已經(jīng)發(fā)送的字節(jié)數(shù)和已經(jīng)采樣的字節(jié)數(shù)之間的最大差的數(shù)目，和用于防止在客戶端的播放中斷的時鐘變換量。
本發(fā)明的第四方面提供一種在多媒體流網(wǎng)絡中的終端，該多媒體流網(wǎng)絡具有至少一個向終端提供數(shù)據(jù)流的服務器，該終端具有接收器緩沖器，用于補償在服務器的數(shù)據(jù)傳輸量和終端的數(shù)據(jù)使用量之間的差，使得允許終端具有滿意的數(shù)據(jù)流量以進行非中斷方式的播放。該終端包括用于定義至少一個確定在服務器中速率匹配操作范圍的參數(shù)的機構(gòu)，以允許服務器根據(jù)所述至少一個參數(shù)使數(shù)據(jù)傳輸量適應于接收率；和用于根據(jù)所述調(diào)節(jié)調(diào)整信息包傳輸延遲變化的機構(gòu)。
根據(jù)本發(fā)明，該定義機構(gòu)包括具有至少用于定義所述至少一個參數(shù)的代碼的軟件程序，和包括具有至少一個用于調(diào)整信息包傳輸延遲變化的代碼的軟件程序。
本發(fā)明的第五方面提供一種在多媒體流網(wǎng)絡中的網(wǎng)絡部件，該多媒體流網(wǎng)絡具有至少一個從網(wǎng)絡部件接收數(shù)據(jù)流的終端，該終端具有接收器緩沖器，用于補償在服務器的數(shù)據(jù)傳輸量和終端的數(shù)據(jù)使用量之間的差，使得允許終端具有滿意的數(shù)據(jù)流量進行非中斷方式的播放。該網(wǎng)絡部件包括接收來自終端的請求的裝置，該請求表示在網(wǎng)絡部件中確定速率匹配操作范圍的至少一個參數(shù)；和根據(jù)所述至少一個參數(shù)用于使數(shù)據(jù)傳輸量適應于終端的接收速率的機構(gòu)，使得終端根據(jù)所述調(diào)節(jié)調(diào)整信息包傳輸延遲變化。
根據(jù)本發(fā)明，該調(diào)節(jié)機構(gòu)包括軟件程序，其具有至少用于調(diào)節(jié)數(shù)據(jù)傳輸量的代碼。
根據(jù)本發(fā)明，該軟件程序包括用于調(diào)節(jié)傳輸速率或采樣速率或它們兩者的代碼。
根據(jù)閱讀結(jié)合圖1-3的描述，本發(fā)明就將變得清楚。


圖1是定義與采樣和傳輸曲線有關參數(shù)的圖表。
圖2是表示對于某些變換參數(shù)，移交及其在接收器緩沖器等級上的影響的圖表。
圖3是表示具有能夠執(zhí)行根據(jù)本發(fā)明的速率匹配方法的服務器設備和客戶端設備的多媒體流系統(tǒng)的結(jié)構(gòu)圖。
具體實施例方式
為了說明什么是供服務器發(fā)送的任一信息包使用的最小和最大變換，本發(fā)明使用以下的速率匹配模式定義“變換”。
A.共同速率匹配模式將在RTP(實時傳輸協(xié)議)信息包中媒體的采樣時間(即時標)和該信息包的傳輸時間(即當由服務器發(fā)送時)之間的時間差α定義為“變換”。參考采樣(S)和傳輸(T)曲線，α變換可以表示為T(t)＝S(t+α)。
當信息包采樣時間晚于信息包傳輸時間時，該變換為正值。當信息包采樣時間早于信息包傳輸時間時，該變換為負值。
隨著建立了“變換”的定義，如下定義了最小和最大變換參數(shù)。
B.服務器速率匹配操作范圍參數(shù)如下定義服務器速率匹配操作范圍參數(shù)。
1)最小變換一該參數(shù)定義了發(fā)送器可以使用的最小變換。它給出在傳輸時間t處能夠被發(fā)送的最早的允許采樣時間。如果該參數(shù)是α_min，發(fā)送器必須在時間t處發(fā)送一個采樣時間不能早于t+α_min的信息包。
具有和它們的采樣時間相比較關于多晚可以發(fā)送該信息包的最大限制，就可以在接收器保持實時重放。接收器可以估計其需要允許等待信息包的最大時間量以防止延遲重放(即沒有接收器緩沖器下溢)。
需要標明最初接收器緩沖延遲(即預卷)的大小以考慮最小變換和此外為信息包傳輸延遲變化進行補償。作為例子，讓我們假設最小變換為-2000ms。這意味著當發(fā)送器發(fā)出一個信息包時，和該信息包的采樣時間早于其傳輸時間最多2秒，而不是更多。為了避免接收器緩沖器下溢，接收器需要為最大期望信息包傳輸延遲變化加2秒進行最初緩沖。該(負)值越小，在接收器需要的初始緩沖就越高。
當接收器探測到時鐘漂移(即接收器播放曲線從保持在發(fā)送器的采樣曲線的偏離)時，可以修改最小變換參數(shù)以迫使服務器跟隨帶有信息包傳輸時間的播放曲線。例如，如果接收器較快，它將以比采樣這些數(shù)據(jù)更快的速率播放它們。這最終將導致緩沖器下溢。通過要求發(fā)送器增加其最小變換，可以避免下溢。
如果接收器比發(fā)送器慢，將減小最小變換。如果接收器比發(fā)送器快，應當增加最小變換。
最小變換的初始值典型地為負，但是接收器也可以將其變成正的。例如，在當最小變換增加的較快接收器(即較快的播放時鐘)的情況下，它可能最終變成正的。例如，如果初始值是-2秒，發(fā)送器可以稍后要求該變換為-1.9秒，然后是-1.7秒，等等。
2)目標變換-該參數(shù)定義客戶端希望發(fā)送器實現(xiàn)的變換。如果該參數(shù)是α_target，發(fā)送器應當在時間t發(fā)送采樣時間為t+α_target的信息包。
目標變換必須總是比上面定義的最小變換高。通過定義，如果根據(jù)目標變換發(fā)送器發(fā)出一個信息包，它也明顯地遵守最小變換。
當傳輸速率在仍然滿足實時限期(即最小變換)的同時需要急劇減小的時候(例如在移交的過程中)，目標變換用于減少對減小采樣速率的需要。換句話說，在傳輸速率足夠好的時候，目標變換是用于使發(fā)送器比恰好必需滿足實時更早地發(fā)送信息包。
為了更好地解釋該第二參數(shù)的使用，讓我們假設發(fā)送器操作接近最小變換。讓我們現(xiàn)在假設傳輸速率明顯下降(這可能是因為例如移交或RTP中繼，其會減少原始流的可用比特率)。為了保證最小變換(并從而實時)，發(fā)送器也要急劇減小其采樣速率。因為發(fā)送器可能例如為了獲得采樣速率的下降而強制跳幀，而這會引起質(zhì)量的下降。
在服務器操作接近目標變換的情況下，當傳輸速率下降時，采樣速率的下降不需要像傳輸速率的下降那樣劇烈。發(fā)送器不使采樣速率下降而使傳輸速率下降，將使實際變換減小到目標變換以下，但是最小變換可以仍然保持而沒有必須如所述的傳輸速率的下降那樣急劇地減小采樣速率。
在強制減小其變換之后，當傳輸速率再次增加時，服務器應當重建其目標變換。為了獲得由接收器信號通知的目標變換，發(fā)送器可以根據(jù)當前傳輸速率制約使用傳輸速率增加和采樣速率的減小(或者傳輸速率減小和采樣速率的增加)的組合。
具有像這樣的目標變換消除了當處理傳輸速率急劇減小時接收器“命令”服務器首先減小然后又再次使變換增加回去的需要。發(fā)送器本身決定從已經(jīng)由接收器提前信號通知的目標變換減小該變換，然后再使該變換朝目標變換增加回去。
因此，該方案可以稱為預設。在傳輸速率下降的情況下不需要發(fā)生(變換)信號通知。
3)在前發(fā)送的字節(jié)的最大數(shù)-該參數(shù)定義已經(jīng)在時間t發(fā)送的字節(jié)數(shù)和到采樣時間t已經(jīng)采樣的字節(jié)數(shù)之間的最大差(即在傳輸曲線和采樣曲線之間的差T(t)-S(t))。該參數(shù)限制在接收器上的必需緩沖器大小以保持作為正變換的結(jié)果所接收的信息包，并且接收器必須因此等待這些信息包的播放時間。該參數(shù)的目標是防止緩沖器溢出。
在具有傳輸曲線T(t)和采樣曲線S(t)例子的圖1中說明了這些參數(shù)。
C.符合速率匹配操作范圍參數(shù)要求的服務器服務器必須嚴格符合“最小變換”和“在前發(fā)送字節(jié)的最大數(shù)”參數(shù)。由此，服務器將努力在按其能力和允許的可用媒體編碼盡量接近“目標變換”的正常傳輸條件下操作。
由于可能的媒體編碼速率隨時間變化，對于所有發(fā)出的信息包，服務器無法準確跟隨“目標變換”。在傳輸條件下服務器的判斷允許從“目標變換”的偏離，在上述判斷中將認為嚴格遵守“目標變換”將導致不必要的質(zhì)量下降(參見下面的使用情況例子)。這還要看在這樣的偏離后，多快能恢復“目標變換”的服務器的判斷/能力。
在“目標變換”和“在前發(fā)送字節(jié)的最大數(shù)”參數(shù)發(fā)生沖突(即保持該目標變換將導致超出該在前發(fā)送字節(jié)的最大數(shù))時，后者優(yōu)先。
D.在服務器和客戶端之間職責分離的說明保持無干擾播放的關鍵是對接收器緩沖器等級的有效管理。這可以通過擁有在客戶端處的播放曲線和接收曲線上的至少隱含或預計控制來實現(xiàn)?？蛻舳送ㄟ^定義了解和控制解碼/播放時間線。通過允許對要由發(fā)送器引入的變換的控制，給客戶端提供至少對接收器曲線的預計控制和其與采樣曲線的關系，由此給出對接收器緩沖器等級的控制。
因此，客戶端考慮其絕對緩存限制來選擇和請求變換參數(shù).。在共同速率匹配模式中，接收器只請求變換參數(shù)，并且在響應于該請求時，其用于發(fā)送器如何調(diào)節(jié)其編碼速率和/或傳輸速率?？梢哉{(diào)節(jié)傳輸曲線或采樣曲線或者它們二者的組合。
但是，在服務器控制下留下了采樣速率控制(即用于傳輸?shù)谋忍亓鬟x擇)，因為—只有服務器知道每個比特流的準確特性，例如切換位置、幀優(yōu)先權(quán)、下一幀的尺寸。
—可能沒有和網(wǎng)絡比特率匹配的比特流速率，因此為了使比特流速率符合網(wǎng)絡比特速率，服務器能夠執(zhí)行一些“技巧”(例如細化、來回切換)。
傳輸速率控制(即傳輸中的速率)也留給了服務器控制(即，使用RTCP RR報告)，因為—一般情況下只有服務器可以檢測在線數(shù)據(jù)量。
—如果采樣率控制具有受限的柔性，可能需要使傳輸速率適應于采樣速率。
在試圖通過以下方式執(zhí)行調(diào)節(jié)時對發(fā)送器進行限制—傳輸曲線的更改傳輸曲線受到接收曲線的制約，由此發(fā)送器不能增加它。只有在其事先沒有使用其總的可用帶寬時它才可以增加。例如，服務器可以使用TFRC(傳輸控制協(xié)議友好速率控制)機制(或通過接收器信號通知接收明確的帶寬信息)來計算其允許的傳輸速率，并且不會將其速率增加超過TFRC速率(或?qū)嶋H信號通知的帶寬)容限。
采樣曲線的更改取決于發(fā)送器的速率匹配能力。例如，如果發(fā)送器執(zhí)行比特流切換并且正在其最低(或最高)比特流上進行傳輸，它就不能進一步減小(或減小)采樣速率了。
E.使用情況根據(jù)本發(fā)明，在服務器和接收器之間轉(zhuǎn)換服務器速率匹配操作范圍的參數(shù)，以使在例如移交、中繼和時鐘漂移的情況中下溢、溢出和質(zhì)量下降的發(fā)生率最小。
在RTP信息包傳輸?shù)那闆r下，接收器可以選擇其想要執(zhí)行的信息包中繼的數(shù)量和其對于中繼所允許的延遲。
在移交的情況下，接收器可以從無線網(wǎng)絡類型中得到例如其希望的移交長度和由此所請求的目標變換。接收器更了解無線連接，并且還可以探測系統(tǒng)間移交和相應地調(diào)節(jié)時鐘變換參數(shù)的需要。
接收器可以通過更新時鐘變換參數(shù)來補償發(fā)送器的時鐘漂移。
RTP中繼在做出中繼請求之前，接收器通常需要估計在其播放時間之前中繼的信息包是否會做出請求。如果該信息包沒有做出請求，中繼會浪費可用帶寬。
發(fā)送器了解信息包的采樣時間，為了符合在接收器上的實時制約，要用至少變換α_min來安排采樣時間。
在這一點上，中繼信息包和在第一次發(fā)送的信息包沒有差別。由于在接收器上最小變換表示下溢閾值，如果發(fā)送器的時標小于t+α_min，其中t是當前時間，則發(fā)送器不會中繼信息包。
通過允許發(fā)送器不中繼信息包，即在接收器上不在它們的解碼時間之前進行中繼并且它們的中繼會浪費可用帶寬，變換參數(shù)信號通知由此可以使信息包傳輸更有效。接收器在對丟失的信息包是否可以在其播放之前被接收到的估計中不必過份保守。如同服務器不會中繼該信息包一樣，錯誤的估計不會有影響(除了無用的請求以外)。
接收器還能夠協(xié)調(diào)中繼的數(shù)量，就好像通過目標變換來進行。當網(wǎng)絡條件好的時候，目標變換的值越高，越多的信息包就被提前發(fā)出(和接收器緩沖等級就越高)。這樣當網(wǎng)絡條件變壞時就又給出更多用于中繼的時間。
這里再一次預設時鐘變換。接收器不需要使變換請求和RTCP請求同步。
移交時鐘變換信號通知可以作為工具來防止在接收器上由于移交引起的播放惡化。
讓我們假設接收器連接網(wǎng)絡并且其了解該網(wǎng)絡期望的移交長度是TH。讓我們假設接收器將其目標變換設置為比最小變換至少高TH，即，α_target＞α_min+TH。
在移交前，發(fā)送器通過早發(fā)送信息包來滿足目標變換。當發(fā)送器檢測到移交的時候，它將停止傳輸(并由此避免因為網(wǎng)絡緩沖器溢出造成信息包丟失)。在移交過程中，盡管沒有發(fā)送新的數(shù)據(jù)，時鐘仍然前進。由此，移交使變換減少了時間TH的量(假設移交正好持續(xù)TH)。因為在移交之前發(fā)送器運行在目標變換，所以移交后的變換將是α_target-TH。
該值仍然比最小變換α_min大。這意味著將仍然滿足實時并且在接收器沒有下溢。在移交過程中，接收器能夠根據(jù)目標變換播放由發(fā)送器發(fā)出的信息包而沒有明顯的質(zhì)量惡化。
在移交之后，當發(fā)送器的傳輸速率再次增加時發(fā)送器將重建目標變換。不需要新的信號通知。
只有當接收器為了進一步增加其能夠允許的移交長度而增加目標變換的時候，接收器才信號通知一個新的變換參數(shù)。具體地可能是這樣一種情況，即在向具有不同期望移交長度的不同類型網(wǎng)絡移交的情況下。
當然需要發(fā)送器能夠檢測移交。通常發(fā)送器將通過對于幾個RTCP間隔不接收RTCP信息包來檢測移交。為了使發(fā)送器能夠盡可能快地檢測移交，如果AVPF可用，接收器應當發(fā)送早期反饋信息包。AVPF是用于基于反饋的RTCP的擴展協(xié)議子集(extended profile)。
如果接收器在RTSP上發(fā)送參數(shù)，其可以在移交之后發(fā)送新的請求(具有相同的參數(shù)或更新值)。如果快速RTCP反饋不能用，這會幫助發(fā)送器更快地檢測移交的結(jié)束。
在圖2中說明了移交及其在緩沖器等級上的影響。在此例中，在移交過程中，緩沖器等級減小但是沒有下溢。在移交之后，發(fā)送器將自己恢復初始目標α_target。但是，因為在移交過程中緩沖器幾乎清空，一旦移交結(jié)束，接收器能夠選擇信號通知一個較大的目標值。這可能是因為第一次移交比接收器最初期望的更大，并且希望確定它在將來可以支持更大的移交。在圖中示出了新目標的信號通知及其在曲線上的影響。
時鐘漂移因為在發(fā)送器和接收器之間的時鐘漂移或其它任何原因(例如慢速客戶端平臺操作系統(tǒng))，發(fā)送器相對于接收器會看起來太慢或太快。可以通過發(fā)送新的變換參數(shù)來校正該漂移。
例如，在慢速接收器的情況下，接收器可以周期性要求一個最小變換值的減小。
F.信息格式和傳輸可以按“3GPP-變換-參數(shù)”定義新的RTSP標題。該標題可以用在客戶端請求中信號通知由客戶端請求的變換參數(shù)。
如果該請求用于對話級RTSP URL(統(tǒng)一資源定位器)，那么該變換應用于該對話中的全部媒體。如果該請求應用于媒體級RTSP URL，該變換應當只用于該媒體。發(fā)送器在其響應中也使用“3GPP-變換-參數(shù)”。這些參數(shù)可以是由客戶端請求的參數(shù)。但是，發(fā)送器可以送回盡可能接近所請求參數(shù)(因為受發(fā)送器能力的限制)的參數(shù)。
可以用任何RTSP方法發(fā)送新的標題。
下面表示了用于這樣的RTP標題的ABNF3gppshifiparameters＝“3GPP-Shift-Parameters”“”shift-parameter*(“；”shift-parameter)CRLFshift-parameter＝alpha-min/alpha-target/max-sizealpha-min＝“alpha_min”“＝”“+”/“-”1*DIGIT；msalpha-target＝“alpha_target”“＝”“+”/“-”1*DIGIT；msmax-size＝“max_size”“＝”1*DIGIT；bytes第一次客戶端發(fā)送所有的參數(shù)。在隨后的請求中，客戶端可以只發(fā)送其請求改變的參數(shù)。
如果改變是可以接受的，如果已經(jīng)按照接收器的請求設置了全部參數(shù)，那么服務器不需要發(fā)送標題。
如果在前一請求完成之前由服務器接收到一個新的請求，那么服務器應當遵照最新的請求。
發(fā)送器也可以在對話開始時向接收器信號通知發(fā)送器所想要使用的參數(shù)。當選擇要請求參數(shù)的哪個值時接收器會考慮這些參數(shù)。
盡管信號通知參數(shù)的優(yōu)選方法是用RTSP，但是也可以使用例如RTCP這樣的不可靠的傳輸協(xié)議。
圖3是表示根據(jù)本發(fā)明在流網(wǎng)絡中的多媒體流系統(tǒng)1的結(jié)構(gòu)圖，其中提供用于為網(wǎng)絡部件或流服務器10確定速率匹配操作范圍的信號通知參數(shù)的裝置，例如在終端或流客戶端60到流服務器10之間協(xié)商。
流服務器10包括應用級的信號通知引擎20、速率控制器30和服務器緩沖器40。流客戶端60包括應用級的信號通知引擎70，對應于并且和在流服務器10中的應用級的信號通知引擎20通信。其還包括在圖3所示本發(fā)明實施例中的客戶端緩沖器80，客戶端緩沖器80包括集成為一個單元的抖動緩沖器82和預解碼緩沖器84。在本發(fā)明的另一個實施例中，流客戶端60可以包括單獨實現(xiàn)的抖動緩沖器和預解碼緩沖器。流客戶端還包括媒體解碼器90、后解碼緩沖器100、緩沖器控制器110和顯示/播放設備120。
圖3所述系統(tǒng)還顯示包括位于流服務器10和流客戶端60之間的“信道緩沖器”50，其表示在從流服務器向客戶端傳輸數(shù)據(jù)信息包的過程中發(fā)生的變化傳輸延遲。
在流客戶端60，從傳輸信道接收并在客戶端緩沖器80中緩沖媒體數(shù)據(jù)。由緩沖器控制器110設置預解碼緩沖器84和抖動緩沖器82的參數(shù)。選擇這些參數(shù)作為服務器推薦的預解碼緩沖參數(shù)和如客戶端估計所需的額外緩沖的集合。客戶端估計在可用傳輸信道上允許所期望的信息包傳輸延遲變化(即抖動)所需要的。客戶端的最大緩沖能力制約這樣的集合。媒體解碼器90從客戶端緩沖器中提取媒體數(shù)據(jù)并以適合于在請求中媒體類型的方式對該媒體數(shù)據(jù)進行解碼。將了解到，一般媒體數(shù)據(jù)包括一些不同的媒體類型。例如，如果從服務器傳輸來的媒體數(shù)據(jù)由視頻序列表示，它很可能包括除了視頻數(shù)據(jù)之外的至少一種音頻分量。因此將理解，如圖3所示的媒體解碼器90實際上可以包括多于一種的解碼器，例如根據(jù)特定視頻編碼標準執(zhí)行的視頻解碼器和相關的音頻解碼器。當通過媒體解碼器90將媒體數(shù)據(jù)解碼時，將其輸出到后解碼緩沖器100，解碼的媒體數(shù)據(jù)暫時存儲在其中直到其所安排的播放時間，在這一時刻在緩沖器控制器110的控制下將數(shù)據(jù)從后解碼緩沖器送到顯示/播放裝置120。
根據(jù)本發(fā)明，緩沖器控制器110適于向應用級的信號通知引擎70提供最小變換、目標變換和先前發(fā)送的字節(jié)最大數(shù)的指示。這些參數(shù)由軟件程序116例如根據(jù)客戶端緩沖限制、解碼/播放時限等確定。應用級的信號通知引擎接著又適于向流服務器10傳輸指示那些操作范圍速率匹配參數(shù)的信號300。例如，使用實時流協(xié)議(RSTP)將這些參數(shù)從客戶端傳輸?shù)椒掌?。例如，可以把RSPT標題定義為“3GPP-變換-參數(shù)”。
在服務器一側(cè)，操作服務器的速率控制器30以使傳輸速率適應于接收速率，并在管理變換和將其保持在速率匹配范圍內(nèi)的同時使采樣速率適應于傳輸速率。服務器還具有傳輸時鐘32，為要傳輸?shù)娇蛻舳说男畔谱鲿r間標記。使用軟件程序36的服務器通過根據(jù)由客戶端建議的參數(shù)調(diào)節(jié)被傳輸?shù)臄?shù)據(jù)速率來工作，考慮客戶端建議的變換參數(shù)，改變在傳輸信道上的比特率，由此設法避免由于預解碼緩沖器下溢造成的在客戶端播放中的暫?；蛴捎诰彌_器溢出造成的在客戶端的信息包丟失。
在把數(shù)據(jù)信息包通過傳輸信道從流服務器傳輸?shù)搅骺蛻舳?0之前，服務器緩沖器40暫時存儲數(shù)據(jù)信息包。在實時采樣數(shù)據(jù)信息包的“活的(live)”流腳本(scenario)中，服務器緩沖器確實是物理緩沖器，其中在采樣時間放入數(shù)據(jù)信息包而在傳輸時間提取該數(shù)據(jù)信息包。在不對數(shù)據(jù)信息包進行實時采樣而是將其存儲在預編碼文件中并在傳輸時間從該文件讀出的“預編碼”流腳本中，服務器緩沖器是虛擬緩沖器，其表示在數(shù)據(jù)信息包的采樣時間(根據(jù)傳輸預編碼文件的第一數(shù)據(jù)信息包時在流服務器上開始的采樣時鐘)和傳輸時間之間的差。
服務器還可以使用應用級的信號通知引擎20以在對話開始時向接收器發(fā)送表示服務器想要使用的參數(shù)的信號300?？紤]由信號300指示的參數(shù)，接收器選擇服務器速率匹配操作范圍的參數(shù)。根據(jù)服務器的能力，服務器可以使用信號300來響應客戶端的請求，返回服務器可以用于速率匹配的參數(shù)。
本發(fā)明的優(yōu)點現(xiàn)有技術的方法(RTSP標題和比特率切換)具有很多的限制。其中的限制之一就是SPEED標題只能在RTSP PLAY請求中發(fā)送。
—PLAY并不意味著為緩沖器控制而操縱，而是從客戶端向服務器傳輸用戶請求。
—在服務器得到請求的時刻不能指望帶有范圍請求的新PLAY的響應與實際播放位置同步(即可能跳過或重發(fā)送數(shù)據(jù))。
—當傳輸速率需要適于可用比特率時，作為由客戶端通過RTSP SPEED請求的對傳輸速率的變更可能常常是根本不可能的。
—它在比特率域操作，不能直接通過接收器映射到時間域(即接收器用于播放給定量的數(shù)據(jù)的時間量)。這是因為采樣曲線一般不是直線。
—可能沒有和NW比特率匹配的比特流。
—由于在給定比特流中的比特率變化或者在比特流平均速率和傳輸速率之間的累計差量，客戶端不了解接收器緩沖器等級減少/增加多少。
—因為沒有服務器和客戶端作業(yè)的間隔，所以在發(fā)送器和接收器上產(chǎn)生采樣曲線成形判定之間的沖突。這與由此清楚劃分發(fā)送器和接收器職責的時鐘變換信號通知形成對比。接收器只更改在曲線上的約束而發(fā)送器為了滿足該約束進行曲線的實際成形。
本發(fā)明具有以下優(yōu)點—制定配置而以一種預設方式工作。這種概念是為了對于客戶端請求操作范圍而不是嚴格的操作點允許服務器以更少的限制和更靈活的方式來操作速率控制。
—請求的服務器速率匹配操作范圍現(xiàn)在是清楚明白定義的，簡化了兼容的服務器執(zhí)行。
—通過減小客戶端到服務器信號通知所需的頻率和速度(即和RTP同步)來減少方案的信號通知開銷。
—可以通過使用RTSP信號通知來解決客戶端到服務器速率匹配操作范圍請求信息的傳輸可靠性和正確流水線技術。這符合(即不再抵觸于)松懈的信號通知的速度和頻率要求。
總的來說，本發(fā)明提供一種用于適應性地控制在多媒體流網(wǎng)絡中在終端或客戶端中接收器緩沖器等級的方法和系統(tǒng)。該多媒體流網(wǎng)絡具有向客戶端提供數(shù)據(jù)流的網(wǎng)絡部件或服務器。服務器負責使傳輸速率適應于接收速率或擁擠控制和使采樣速率適應于傳輸速率。這樣，服務器管理變換并將其保持在速率匹配操作范圍之內(nèi)。客戶端負責補償信息包傳輸延遲變化，這也被稱為網(wǎng)絡抖動?？蛻舳诉€負責設置服務器速率匹配操作范圍的參數(shù)?？蛻舳诉x擇并向服務器發(fā)送變換參數(shù)，而當響應于這些參數(shù)時，服務器用于調(diào)節(jié)其編碼速率或傳輸速率。
盡管已經(jīng)根據(jù)一個或多個實施例對本發(fā)明進行了介紹，但是本領域技術人員可以理解，在不背離本發(fā)明精神的情況下，本發(fā)明可以由形式和細節(jié)上的前述和各種其它變化、省略和偏差來完成。
權(quán)利要求
1.一種用于適應性地控制在多媒體流網(wǎng)絡中客戶端中的接收器緩沖器等級的方法，該流網(wǎng)絡包括用于向客戶端提供數(shù)據(jù)流的服務器，其中接收器緩沖器用于補償服務器的數(shù)據(jù)傳輸量和客戶端的數(shù)據(jù)使用量之間的差，以使得允許客戶端具有足夠的數(shù)據(jù)流量用于以不間斷方式播放，所述方法其特征在于在客戶端定義至少一個參數(shù)，用于確定速率匹配操作范圍，得以在服務器和客戶端之間執(zhí)行速率匹配；根據(jù)所述的至少一個參數(shù)使在服務器中的數(shù)據(jù)量適應于接收率；和根據(jù)上述調(diào)節(jié)在客戶端調(diào)整信息包傳輸延遲變化。
2.權(quán)利要求1的一種方法，其特征在于所述至少一個參數(shù)包括最小變換量，其表示服務器中一個信息包的采樣時間和傳輸時間之間的差，以允許服務器根據(jù)該最小變換量執(zhí)行所述調(diào)節(jié)。
3.權(quán)利要求1或2的一種方法，其特征在于所述至少一個參數(shù)包括目標變換量，其表示大于服務器中一個信息包的采樣時間和傳輸時間之間的差的變換量，以允許服務器根據(jù)該目標變換量執(zhí)行所述調(diào)節(jié)。
4.權(quán)利要求1-3中任一種的方法，其特征在于所述至少一個參數(shù)包括指定在已經(jīng)發(fā)送的字節(jié)數(shù)和已經(jīng)采樣的字節(jié)數(shù)之間的最大差的數(shù)目，以允許服務器根據(jù)該數(shù)目執(zhí)行所述調(diào)節(jié)。
5.權(quán)利要求1-4中任一種的方法，其特征還在于根據(jù)所述的至少一個參數(shù)使在服務器中的采樣速率適應于傳輸速率。
6.權(quán)利要求1-5中任一種的方法，其特征在于所述的至少一種參數(shù)包括用于防止在客戶端播放中斷的時鐘變換量。
7.權(quán)利要求1-6中任一種的方法，其特征在于所述調(diào)節(jié)包括傳輸速率的調(diào)節(jié)。
8.權(quán)利要求1-7中任一種的方法，其特征在于所述調(diào)節(jié)包括采樣速率的調(diào)節(jié)。
9.權(quán)利要求1-6中任一種的方法，其特征在于所述調(diào)節(jié)包括對傳輸速率和采樣速率的調(diào)節(jié)。
10.權(quán)利要求1的一種方法，其特征在于所述至少一種參數(shù)包括表示服務器中一個信息包的采樣時間和傳輸時間之間的差的最小變換量；表示大于服務器中一個信息包的采樣時間和傳輸時間之間的差的變換量的目標變換量；指定在已經(jīng)發(fā)送的字節(jié)數(shù)和已經(jīng)采樣的字節(jié)數(shù)之間的最大差的數(shù)目；和時鐘變換量，其中把最小變換量、目標變換量、指定數(shù)目和時鐘中的兩個或更多個一起發(fā)送到服務器。
11.一種多媒體流系統(tǒng)，特征在于至少一個客戶端；和用于向客戶端提供數(shù)據(jù)流的服務器，客戶端具有接收器緩沖器，用于補償在服務器的數(shù)據(jù)傳輸量和客戶端的數(shù)據(jù)使用量之間的差，使得允許客戶端具有足夠的數(shù)據(jù)流量以進行非中斷方式的播放，其中客戶端包括用于定義至少一個確定速率匹配操作范圍的參數(shù)的機構(gòu)，以允許服務器根據(jù)所述至少一個參數(shù)使數(shù)據(jù)量適應于接收率；和用于根據(jù)所述調(diào)節(jié)調(diào)整信息包傳輸延遲變化的機構(gòu)。
12.權(quán)利要求11的多媒體流系統(tǒng)，特征在于所述至少一個參數(shù)包括最小變換量，其表示服務器中一個信息包的采樣時間和傳輸時間之間的差，以允許在服務器中執(zhí)行所述調(diào)節(jié)。
13.權(quán)利要求11或12的多媒體流系統(tǒng)，特征在于所述至少一個參數(shù)包括目標變換量，其表示大于服務器中一個信息包的采樣時間和傳輸時間之間的差的變換量，以允許服務器執(zhí)行所述調(diào)節(jié)。
14.權(quán)利要求11-13中的任一項的多媒體流系統(tǒng)，特征在于所述至少一個參數(shù)包括指定在已經(jīng)發(fā)送的字節(jié)數(shù)和已經(jīng)采樣的字節(jié)數(shù)之間的最大差的數(shù)目，以允許服務器執(zhí)行所述調(diào)節(jié)。
15.權(quán)利要求11-14中的任一項的多媒體流系統(tǒng)，特征在于服務器包括用于根據(jù)所述的至少一個參數(shù)使采樣速率適應于傳輸速率的調(diào)節(jié)機構(gòu)。
16.權(quán)利要求11-15中的任一項的多媒體流系統(tǒng)，特征在于所述至少一個參數(shù)包括用于防止在客戶端播放中斷的時鐘變換量。
17.權(quán)利要求11-16中的任一項的多媒體流系統(tǒng)，特征在于服務器包括用于調(diào)節(jié)傳輸速率的調(diào)節(jié)機構(gòu)。
18.權(quán)利要求11-17中的任一項的多媒體流系統(tǒng)，特征在于服務器包括用于調(diào)節(jié)采樣速率的調(diào)節(jié)機構(gòu)。
19.權(quán)利要求11-16中的任一項的多媒體流系統(tǒng)，特征在于服務器包括用于調(diào)節(jié)傳輸速率和采樣速率的調(diào)節(jié)機構(gòu)。
20.權(quán)利要求11-19中的任一項的多媒體流系統(tǒng)，特征在于服務器包括具有至少一個用于執(zhí)行所述調(diào)節(jié)的代碼的軟件程序。
21.一種在多媒體流網(wǎng)絡中在客戶端使用的軟件產(chǎn)品，用于自適應控制在客戶端中的接收器緩沖器的等級，該多媒體流網(wǎng)絡包括能夠向客戶端提供數(shù)據(jù)流的服務器，其中該接收器緩沖器用于補償在服務器的數(shù)據(jù)傳輸量和客戶端的數(shù)據(jù)使用量之間的差，使得允許客戶端具有足夠的數(shù)據(jù)流量以進行非中斷方式的播放，所述軟件產(chǎn)品包括用于定義至少一個在服務器中確定速率匹配操作范圍的參數(shù)的代碼，以在服務器和客戶端之間執(zhí)行速率匹配；和用于根據(jù)所述調(diào)節(jié)來調(diào)整信息包傳輸延遲變化的代碼。
22.權(quán)利要求21的軟件產(chǎn)品，其特征在于所述至少一個參數(shù)包括最小變換量，其表示服務器中一個信息包的采樣時間和傳輸時間之間的差，以允許在服務器中執(zhí)行所述調(diào)節(jié)。
23.權(quán)利要求21或22的軟件產(chǎn)品，其特征在于所述至少一個參數(shù)包括目標變換量，其表示大于服務器中一個信息包的采樣時間和傳輸時間之間的差的變換量，以允許服務器執(zhí)行所述調(diào)節(jié)。
24.權(quán)利要求21-23中任一個的軟件產(chǎn)品，其特征在于所述至少一個參數(shù)包括指定在已經(jīng)發(fā)送的字節(jié)數(shù)和已經(jīng)采樣的字節(jié)數(shù)之間的最大差的數(shù)目，以允許服務器執(zhí)行所述調(diào)節(jié)。
25.權(quán)利要求21-24中任一個的軟件產(chǎn)品，其特征在于所述至少一個參數(shù)包括用于防止客戶端的播放中斷的時鐘變換量。
26.一種在多媒體流網(wǎng)絡中的終端，該多媒體流網(wǎng)絡具有至少向終端提供數(shù)據(jù)流的服務器，該終端具有接收器緩沖器，用于補償在服務器的數(shù)據(jù)傳輸量和終端的數(shù)據(jù)使用量之間的差，使得允許該終端具有足夠的數(shù)據(jù)流量以進行非中斷方式的播放，該終端包括用于定義至少一個確定速率匹配操作范圍的參數(shù)的機構(gòu)，以允許服務器根據(jù)所述至少一個參數(shù)使數(shù)據(jù)傳輸量適應于接收率；和用于根據(jù)所述調(diào)節(jié)來調(diào)整信息包傳輸延遲變化的機構(gòu)。
27.權(quán)利要求26的終端，其特征在于所述定義機構(gòu)包括至少具有用于定義至少一個參數(shù)的代碼的軟件程序。
28.權(quán)利要求26或27的終端，其特征在于所述調(diào)節(jié)機構(gòu)包括至少具有用于調(diào)整信息包傳輸延遲變化的代碼的軟件程序。
29.權(quán)利要求26-28中任一項的終端，其特征在于所述至少一個參數(shù)包括最小變換量，其表示服務器中一個信息包的采樣時間和傳輸時間之間的差，以允許服務器根據(jù)該最小變換量執(zhí)行所述調(diào)節(jié)。
30.權(quán)利要求26-29中任一項的終端，其特征在于所述至少一個參數(shù)包括目標變換量，其表示大于服務器中一個信息包的采樣時間和傳輸時間之間的差的變換量，以允許服務器根據(jù)該目標變換量執(zhí)行所述調(diào)節(jié)。
31.權(quán)利要求26-30中任一項的終端，其特征在于所述至少一個參數(shù)包括指定在已經(jīng)發(fā)送的字節(jié)數(shù)和已經(jīng)采樣的字節(jié)數(shù)之間的最大差的數(shù)目，以允許服務器根據(jù)該數(shù)目執(zhí)行所述調(diào)節(jié)。
32.一種在多媒體流網(wǎng)絡中的網(wǎng)絡部件，該多媒體流網(wǎng)絡具有至少一個從網(wǎng)絡部件接收數(shù)據(jù)流的終端，該終端具有接收器緩沖器，用于補償在網(wǎng)絡部件的數(shù)據(jù)傳輸量和客戶端的數(shù)據(jù)使用量之間的差，使得允許終端具有足夠的數(shù)據(jù)流量以進行非中斷方式的播放，所述網(wǎng)絡部件特征在于從終端接收請求的裝置，該請求表示在網(wǎng)絡部件中確定速率匹配操作范圍的至少一個參數(shù)；和根據(jù)所述至少一個參數(shù)用于使數(shù)據(jù)傳輸量適應于終端的接收量的機構(gòu)，使得終端根據(jù)所述調(diào)節(jié)來調(diào)整信息包傳輸延遲變化。
33.權(quán)利要求32的網(wǎng)絡部件，其特征在于所述調(diào)節(jié)機構(gòu)包括至少具有用于調(diào)節(jié)數(shù)據(jù)傳輸量的代碼的軟件程序。
34.權(quán)利要求33的網(wǎng)絡部件，其特征在于所述軟件程序包括用于調(diào)節(jié)傳輸速率的代碼。
35.權(quán)利要求33或34的網(wǎng)絡部件，其特征在于所述軟件程序包括用于調(diào)節(jié)采樣速率的代碼。
36.權(quán)利要求33-35中任一項的網(wǎng)絡部件，其特征在于所述軟件程序包括用于調(diào)節(jié)傳輸速率和采樣速率的代碼。
全文摘要
一種用于適應性地控制在多媒體流網(wǎng)絡中在客戶端中接收器緩沖器等級的方法和系統(tǒng)。該多媒體流網(wǎng)絡具有向客戶端提供數(shù)據(jù)流的服務器。服務器負責使傳輸速率適應于接收速率或擁擠控制和使采樣速率適應于傳輸速率。這樣，服務器管理變換并將其保持在速率匹配操作范圍之內(nèi)?？蛻舳素撠熝a償信息包傳輸延遲變化，這也被稱為網(wǎng)絡抖動?？蛻舳诉€負責設置服務器速率匹配操作范圍的參數(shù)?？蛻舳诉x擇并向服務器發(fā)送變換參數(shù)，而當響應于這些參數(shù)時，使服務器調(diào)節(jié)其編碼速率或傳輸速率。
文檔編號G06F15/16GK1799044SQ200480010866
公開日2006年7月5日 申請日期2004年4月23日 優(yōu)先權(quán)日2003年4月24日
發(fā)明者D·萊昂, V·瓦薩, I·D·D·庫爾喬 申請人:諾基亞有限公司