專利名稱：支持vcr功能的多播流合并方法
技術領域：
本發(fā)明涉及視頻服務系統(tǒng)，特別涉及一種以多播形式發(fā)送數(shù)據(jù)，并可支持用戶VCR操作的個性化視頻服務系統(tǒng)。
背景技術：
使用多播技術的視頻服務系統(tǒng)可以廣泛應用于網(wǎng)絡教學、視頻會議、網(wǎng)絡課堂、視頻點播等服務。與單播方式的視頻服務相比，使用多播技術的視頻服務系統(tǒng)更節(jié)省服務器的帶寬，使其具有更高的性能。與傳統(tǒng)的視頻直播服務相比，多播流合并方法可以使視頻服務更具有個性化，能隨時滿足客戶不同的需求?，F(xiàn)有的支持VCR功能的多播流合并方法在功能上有不足之處。
VCR軟件可以把ASF、RM、WMA、RA等流文件下載到本地再播放，再也不用因為網(wǎng)絡速度慢而影響觀看了，當然最大的好處是可以保存那些本來不能保存的“流”節(jié)目了。它同時支持現(xiàn)場下載和點播下載。提高了多種流媒體文件的下載能力。現(xiàn)在已經(jīng)能夠支持下載Real Helix的流文件。并且在下載的帶寬上已經(jīng)支持到了10Mbps LAN的新速率。對于采用T1速率之上的ADSL、Cable Modem、光纜、LAN等設備的用戶的下載道路可是更加的寬闊了?？梢园袮SF、RM、WMA、RA等等流文件下載到本地再播放，再也不用因為網(wǎng)絡速度慢而影響觀看了。當然最大的好處是可以保存那些本來不能保存的“流”節(jié)目了。它同時支持現(xiàn)場下載和點播下載。多播流合并方法應該支持VCR功能。

發(fā)明內(nèi)容
本發(fā)明的主要目的是針對現(xiàn)有技術在個性化服務與服務器可擴展性之間不能兼顧的情況，提出一種支持VCR功能的多播流合并方法，使在滿足個性化視頻服務的同時，不過多的損耗服務器性能。
為實現(xiàn)本發(fā)明所述目的，本發(fā)明提供一種客戶端和服務器端的協(xié)作機制(1)在客戶端通過主動緩存機制，一方面預取和緩存數(shù)據(jù)，另一方面通過特殊的控制及請求機制為服務器端的流合并創(chuàng)造條件；(2)在服務器端，使用特殊的流合并機制，既滿足用戶觀看以及VCR操作的需要，又盡可能地提高流的共享度，增強服務器的服務性能。
下面將結(jié)合附圖進行詳細說明。


圖1是支持VCR功能的多播視頻服務系統(tǒng)的結(jié)構2是此視頻服務系統(tǒng)的工作流程3是本發(fā)明的客戶端緩存控制邏輯圖4是客戶端緩存簡單示意5是本發(fā)明的服務器端調(diào)度邏輯圖6是服務器調(diào)度策略輔助說明圖具體實施方式
如圖1所示，視頻服務系統(tǒng)由客戶端和服務器端兩部分組成，這兩部分通過網(wǎng)絡進行視頻數(shù)據(jù)和控制信息的轉(zhuǎn)的?？蛻舳司彺尕撠熛虿シ牌魈峁?shù)據(jù)并觀察其行為，適時地向服務器發(fā)送請求。客戶端接收器負責從網(wǎng)絡接收數(shù)據(jù)放入緩存。服務器端調(diào)度器接收到請求后進行流調(diào)度，并將數(shù)據(jù)以多播流形式發(fā)送給客戶端。
本發(fā)明的總流程如圖2所示。當一個新客戶加入系統(tǒng)時，播放器向緩存請求數(shù)據(jù)(步驟11)，緩存控制檢查緩存內(nèi)的數(shù)據(jù)(步驟12)，如果有相應數(shù)據(jù)，則直接將數(shù)據(jù)返回給播放器進行播放(步驟13)；如果沒有，則向服務器發(fā)送請求(步驟14)，等待直到服務器返回多播流地址后(步驟15)，接收器開始接收相應地址的流數(shù)據(jù)(步驟16)。在客戶的播放過程中，播放器會不斷向緩存請求數(shù)據(jù)，且當客戶發(fā)生VCR操作時也會向緩存請求數(shù)據(jù)，直至影片播放結(jié)束。緩存控制是比較復雜的一個過程，其中涉及本發(fā)明特有的方法，將在后面詳細描述。
相應地，服務器端從步驟20開始啟動服務，等待直到客戶請求到達(步驟21)，進行多播流的調(diào)度與合并(步驟22)，將結(jié)果返回給客戶端(步驟23)，并向客戶發(fā)送數(shù)據(jù)(步驟24)，調(diào)度的算法也將在后面詳細描述。一個調(diào)度過程完成以后，將回到步驟21等待新的客戶請求到達，如此往復，直到服務器停止服務。
在圖3中詳細描述了客戶端的緩存控制流程。當播放器請求數(shù)據(jù)時，先判斷緩存中有無被請求的數(shù)據(jù)(步驟121)，如果沒有則向服務器發(fā)送立即請求(步驟124)，如果有則將數(shù)據(jù)返回給播放器(步驟122)，同時檢查接收器接收數(shù)據(jù)的狀況(步驟123)。如果接收器不在接收數(shù)據(jù)，或者正在接收的數(shù)據(jù)不是客戶在一段時間以后需要但緩存中缺失的數(shù)據(jù)，則向服務器發(fā)送延遲請求(步驟125)，即此請求要求服務器在限定的延遲內(nèi)發(fā)送被請求數(shù)據(jù)。如圖4所示，從Dstart到Dend表示觀看整部影片所需要的數(shù)據(jù)，陰影部分表示緩存中已有數(shù)據(jù)，Dnow表示播放器當前正在播放的數(shù)據(jù)，Drup表示緩存中缺失數(shù)據(jù)的起始位置，播放器消耗數(shù)據(jù)的速率為v，則緩存發(fā)送的延遲請求的允許延遲時間可以通過公式(1)求得，即服務器必須在播放器到達Drup之前向客戶發(fā)送Drup之后的數(shù)據(jù)。
Tdelay=Drup-Dnowv---(1)]]>接收器接收到數(shù)據(jù)后，先判斷此數(shù)據(jù)是否是播放器正在請求的數(shù)據(jù)(步驟127)，若是，則回到步驟122將數(shù)據(jù)放入緩存并返回給播放器；如果不是，則繼續(xù)判斷緩存中是否還有可用空間(步驟128)。如果有剩余空間，則將數(shù)據(jù)放入緩存；如果沒有，則停止接收該流的數(shù)據(jù)。
圖5顯示了服務器的調(diào)度流程。當服務器接收到客戶請求后，先判斷請求類型(步驟221)。如果是立即請求，則判斷服務器有無多余帶寬(步驟222)，如果沒有則調(diào)度失敗，向客戶返回失敗信息。如果服務器還有剩余帶寬可供使用，則以請求地址為起始開辟一個新的多播流P，并且進行多播流的合并(步驟223)。在進行流合并時，假設Dnow為流正在發(fā)送的數(shù)據(jù)位置，Dend表示流的結(jié)束位置，則在現(xiàn)存流中尋找一個滿足以下條件的多播流A作為流P的目標流DA_now-DP_now＜DA_end-DA_now(2)調(diào)度成功，將補丁流P及其目標流A的地址發(fā)送給客戶。具體如圖6(a)所示，可用坐標軸對上述調(diào)度策略加以解釋說明。橫坐標表示時間，縱坐標表示發(fā)送的數(shù)據(jù)在影片中的位置。坐標軸中的每一條斜線就是服務器發(fā)送的一個數(shù)據(jù)流。假設在時間t1，服務器接收到一個立即請求，要求發(fā)送數(shù)據(jù)Dreq。服務器立即調(diào)度一個新流P，并在現(xiàn)有所有同一影片的多播流中查找一個符合條件(2)的流作為合并的目標流。流a不能滿足條件，因為Da_now-DP_now＞Da_end-Da_now，會導致流P為追上流a而發(fā)送完Da_now時，流a已經(jīng)結(jié)束發(fā)送，不能再進行合并。流b符合條件(2)，因此可以作為流P的目標流進行合并，流P發(fā)送至Db_now結(jié)束。
如果客戶的請求是延遲請求，則判斷系統(tǒng)中有無符合條件的現(xiàn)存流(步驟225)。假設客戶請求數(shù)據(jù)Dreq，允許的延遲為Tdelay，假設存在符合以下條件的流ADreq＞DA_now＞Dreq-Tdelay*v且Dreq＜DA_end(3)則調(diào)度成功，將流A的地址返回給客戶。如果沒有符合此條件的流，則暫緩調(diào)度，等待客戶再次發(fā)送請求。同樣可用圖6(b)來說明對延遲請求的調(diào)度策略。假設在時間t2，服務器接收到一個請求數(shù)據(jù)Dreq、允許延遲為Tdelay的延遲請求。服務器在現(xiàn)有多播流中，查找一條滿足條件(3)的流。因為對于流a，Dreq＜Da_now，顯然不能滿足從t2～t2+Tdelay時間段內(nèi)發(fā)送Dreq；而對于流b，Db_now＜Dreq-Tdelay*v，從而不能在Tdelay時間段內(nèi)發(fā)送Dreq；流c滿足條件Dreq＞Dc_now＞Dreq-Tdelay*v，但Dreq＞Dc_end，即流c在發(fā)送到數(shù)據(jù)Dreq之前就已經(jīng)結(jié)束；流d滿足條件(3)，可以在t2～t2+Tdelay時間段內(nèi)發(fā)送客戶請求的數(shù)據(jù)，及時滿足客戶的需求。
縱上所述，客戶緩存控制邏輯以及服務器調(diào)度邏輯是本發(fā)明的核心。
權利要求
1.支持VCR功能的多播流合并方法，由服務器端向客戶端提供多播視頻服務，客戶端通過主動緩存預取和緩存數(shù)據(jù)，通過控制及請求機制為服務器端的流合并創(chuàng)造條件；在服務器端，使用流合并機制，其特征是當一個新客戶加入系統(tǒng)時，播放器向緩存請求數(shù)據(jù)，緩存控制檢查緩存內(nèi)的數(shù)據(jù)，如果有相應數(shù)據(jù)，則直接將數(shù)據(jù)返回給播放器進行播放；如果沒有，則向服務器發(fā)送請求，等待直到服務器返回多播流地址后，接收器開始接收相應地址的流數(shù)據(jù)；在客戶的播放過程中，播放器會不斷向緩存請求數(shù)據(jù)，且當客戶發(fā)生VCR操作時也會向緩存請求數(shù)據(jù)，直至文件播放結(jié)束；相應地，服務器端從開始啟動服務，等待直到客戶請求到達，進行多播流的調(diào)度與合并，將結(jié)果返回給客戶端，并向客戶發(fā)送數(shù)據(jù)，一個調(diào)度過程完成以后，將回到等待新的客戶請求到達，如此往復，直到服務器停止服務。
2.由權利要求1所述的支持VCR功能的多播流合并方法，其特征是緩存控制方法當客戶播放器請求數(shù)據(jù)時，如果有則將數(shù)據(jù)返回給播放器，同時檢查接收器接收數(shù)據(jù)的狀況；如果接收器不在接收數(shù)據(jù)，或者正在接收的數(shù)據(jù)不是客戶在一段時間以后需要但緩存中缺失的數(shù)據(jù)，則向服務器發(fā)送延遲請求，即此請求要求服務器在限定的延遲內(nèi)發(fā)送被請求數(shù)據(jù)；假設Dnow表示播放器當前正在播放的數(shù)據(jù)，Drup表示緩存中缺失的數(shù)據(jù)，v表示播放器消耗數(shù)據(jù)的速率，則延遲的時間可通過以下公式求得Tdelay=Drup-Dnowv]]>接收器接收到數(shù)據(jù)后，先判斷此數(shù)據(jù)是否是播放器正在請求的數(shù)據(jù)，若是，則將數(shù)據(jù)放入緩存并返回給播放器；如果不是，則繼續(xù)判斷緩存中是否還有可用空間；如果有剩余空間，則將數(shù)據(jù)放入緩存；如果沒有，則停止接收該流的數(shù)據(jù)。
3.由權利要求1或2所述的支持VCR功能的多播流合并方法，其特征是調(diào)度服務器的調(diào)度方法當服務器接收到客戶請求后，先判斷請求類型，如果是立即請求，則判斷服務器有無多余帶寬，如果沒有則調(diào)度失敗，向客戶返回失敗信息；如果服務器還有剩余帶寬可供使用，則以請求地址為起始開辟一個新的多播流P，并且進行多播流的合并；在進行流合并時，假設Dnow為流正在發(fā)送的數(shù)據(jù)位置，Dend表示流的結(jié)束位置，則在現(xiàn)存流中尋找一個滿足以下條件的多播流A作為流P的目標流DA_now-DP_now＜DA_end-DA_now(2)調(diào)度成功，將補丁流P及其目標流A的地址發(fā)送給客戶。
4.由權利要求3所述的支持VCR功能的多播流合并方法，其特征是在時間t1，服務器接收到一個立即請求，要求發(fā)送數(shù)據(jù)Dreq，服務器立即調(diào)度一個新流P，并在現(xiàn)有所有同一影片的多播流中查找一個符合條件(2)的流作為合并的目標流；滿足式(2)的流作為流P的目標流進行合并，流P發(fā)送至Db_now結(jié)束。
5.由權利要求1或2的支持VCR功能的多播流合并方法，其特征是如果客戶的請求是延遲請求時，則判斷系統(tǒng)中有無符合條件的現(xiàn)存流(步驟225)；假設客戶請求數(shù)據(jù)Dreq，允許的延遲為Tdelay，假設存在符合以下條件的流ADreq＞DA_now＞Dreq-Tdelay*v且Dreq＜DA_end(3)則調(diào)度成功，將流A的地址返回給客戶；如果沒有符合此條件的流，則暫緩調(diào)度，等待客戶再次發(fā)送請求。
6.由權利要求3所述的支持VCR功能的多播流合并方法，其特征是在時間t2，服務器接收到一個請求數(shù)據(jù)Dreq、允許延遲為Tdelay的延遲請求；服務器在現(xiàn)有多播流中，查找一條滿足條件(3)的流，在t2～t2+Tdelay時間段內(nèi)發(fā)送客戶請求的數(shù)據(jù)，及時滿足客戶的需求。
全文摘要
支持VCR功能的多播流合并方法，由服務器端向客戶端提供多播視頻服務，客戶端通過主動緩存預取和緩存數(shù)據(jù)，通過控制及請求機制為服務器端的流合并創(chuàng)造條件；在服務器端，使用流合并機制，當一個新客戶加入系統(tǒng)時，播放器向緩存請求數(shù)據(jù)，緩存控制檢查緩存內(nèi)的數(shù)據(jù)，如果有相應數(shù)據(jù)，則直接將數(shù)據(jù)返回給播放器進行播放；如果沒有，則向服務器發(fā)送請求，等待直到服務器返回多播流地址后，接收器開始接收相應地址的流數(shù)據(jù)；發(fā)明提供一種客戶端和服務器端的協(xié)作機制在客戶端通過主動緩存機制，一方面預取和緩存數(shù)據(jù)，另一方面通過特殊的控制及請求機制為服務器端的流合并創(chuàng)造條件。
文檔編號H04N7/00GK1610400SQ20041006574
公開日2005年4月27日 申請日期2004年11月16日 優(yōu)先權日2004年11月16日
發(fā)明者單煒, 陸桑璐, 陳力軍, 陳道蓄, 謝立 申請人:南京大學