專利名稱：一種點對點移動流媒體的傳輸方法和播放器的制作方法
技術領域：
本發(fā)明涉及移動通信網(wǎng)絡，尤其涉及一種點對點移動流媒體
的傳輸方法和插-;改器，具體地說涉及一種基于UDP (User Datagram Protocol, 用戶數(shù)據(jù)包協(xié)議)的點對點移動流媒體的可靠傳輸實現(xiàn)方法。
背景技術：
在傳統(tǒng)的互聯(lián)網(wǎng)中，目前流行的P2P (Point to Point點對點) 應用形式涵蓋了視頻、語音、搜索、下載等多種應用，已成為互聯(lián)網(wǎng)最大核心 應用。在傳統(tǒng)互聯(lián)網(wǎng)技術與應用飛速發(fā)展的同時，移動互聯(lián)網(wǎng)也不甘落后，隨 著無線通信技術的日漸成熟，移動互聯(lián)網(wǎng)的規(guī)模也正在逐步發(fā)展壯大。隨著無 線帶寬的增加，P2P已經(jīng)自發(fā)的走向移動網(wǎng)內(nèi)。移動P2P技術的提出就是把傳 統(tǒng)互聯(lián)網(wǎng)P2P技術的思想應用到移動/無線網(wǎng)絡中來，這是移動互聯(lián)網(wǎng)發(fā)展的必 然需求。
在移動通信網(wǎng)絡中實現(xiàn)P2P多士某體內(nèi)容共享是一項創(chuàng)新型業(yè)務，目前在國 內(nèi)尚未發(fā)現(xiàn)完全一致的竟爭項目，產(chǎn)品或服務。但在國際上存在2家較為類似 或接近的服務，分別是愛爾蘭NewBay公司的Foneshare業(yè)務，美國的SplashData 公司的SplashBlog,但是這兩家公司的移動P2P業(yè)務都不支持流媒體業(yè)務。
目前對于WIFI (Wireless Fidelity無線寬帶)，最高帶寬為11 Mbps，在 信號較弱或有干擾的情況下，帶寬可調(diào)整為5. 5Mbps、 2Mbps或者1Mbps。帶寬 的自動調(diào)整，有效地保障了網(wǎng)絡的穩(wěn)定性和可靠性。但是，移動互聯(lián)網(wǎng)的傳輸 速率與固定互聯(lián)網(wǎng)相比，還是有著很大的差距，因為無線網(wǎng)絡的無線帶寬/鏈路 質(zhì)量變化比較大，因此固定互聯(lián)網(wǎng)中的P2P應用很難簡單地移植到移動互聯(lián)網(wǎng) 環(huán)境中
發(fā)明內(nèi)容
本發(fā)明的目的在于克服現(xiàn)有技術的不足之處，公開一種點對 點移動流i某體的傳輸方法和播放器，面向WiFi移動數(shù)據(jù)網(wǎng)絡環(huán)境，針對無線互 聯(lián)網(wǎng)帶寬/鏈路質(zhì)量變化比較大的特點，基于UDP實現(xiàn)的可靠的傳輸方法和播放器。本發(fā)明公開的一種點對點移動流媒體的傳輸方法，支持流媒體播放器在移
動通信網(wǎng)絡中的流媒體文件內(nèi)容共享及分發(fā)運營商組織的內(nèi)容，包括如下步驟 (1 )所述流媒體播放器根據(jù)播放所述流媒體信息的需要周期性地發(fā)出分片
請求；
(2)所述流媒體播放器記錄所述分片請求發(fā)出的時間并增加到請求列表
中；所述流媒體播放器接收分片請求的回復，同時將收到回復的分片請求從請 求列表中刪除；
(3 )所述流媒體播放器按照設定的定時器周期性地根據(jù)每一個分片請求發(fā) 出的時間判斷所述請求列表中是否有分片請求超時？否則回到步驟(l)，是則 從所述請求列表中刪除所述超時的分片請求并重新發(fā)出請求，回到步驟(2)。 本發(fā)明公開的這種點對點移動流媒體的傳輸方法，還包括如下從屬技術特
征
在所述步驟(l)中，還包括在計數(shù)器A中記錄發(fā)出的分片請求的數(shù)量；在 所述步驟(2)中，還包括在計數(shù)器B中記錄接收到的分片請求的回復的數(shù)量； 并且在步驟(1 )中還比較所述計時器A和計數(shù)器B所記錄的數(shù)量的大小并且根 據(jù)比較的結果調(diào)整所述發(fā)出分片請求的周期。
在所述步驟(l)中，所述調(diào)整所述發(fā)出分片請求的周期對于在單位時間內(nèi) 發(fā)出分片請求的數(shù)量設定上限。
在所述步驟(l)中，所述流媒體播放器首先掃描才艮據(jù)其lt據(jù)處理的速度設 置的窗口W，只有當所述窗口 W不滿時才發(fā)出分片請求。
在所述步驟(3)中，所述根據(jù)每一個分片請求發(fā)出的時間判斷所述請求列 表中是否有分片請求超時的方法包括根據(jù)所述每一個分片請求距離指示當前 播放到所述媒體文件的哪一塊的播放指針的差值賦予相應的超時閥值，距離所 述播放指針近的分片請求的超時閥值比距離播放指針遠的分片請求的超時閥值
在所述步驟(3)中，還根據(jù)所述流媒體播放器的播放碼率來確定每一個分 片請求的超時閥值。
5在所述步驟(3)中，所述流媒體播放器按照設定的定時器周期性地根據(jù)每 一個分片請求發(fā)出的時間判斷所述請求列表中是否有分片請求超時？否則回到 步驟(l)，是則從所述請求列表中刪除所述超時的分片請求，并重新發(fā)出請求，
回到步驟(2)。
本發(fā)明還公開了 一種點對點移動流媒體的播放器，在移動通信網(wǎng)絡中共享 及分發(fā)運營商組織的流媒體文件的內(nèi)容，包括分片請求發(fā)送模塊，用于周期性 地定時發(fā)出分片請求；還包括，請求列表維護模塊，用于記錄發(fā)出的分片請求 以及所述分片請求發(fā)出的時間；超時檢查模塊，用于周期性地定時檢查所述請 求列表中的分片請求是否超時，并且刪除所述請求列表中超時的分片請求同時 重新發(fā)出所述分片請求；分片請求接收模塊，用于接收發(fā)出的分片請求的回復 信息，同時刪除所述請求列表中的所述分片請求的相應記錄。
還包括，計數(shù)器A，用于記錄所述分片請求發(fā)送模塊發(fā)出的分片請求的數(shù)量； 計數(shù)器B，用于記錄所述分片請求接收模塊接收到的分片請求的回復的數(shù)量；所 述播放器比較所述計時器A和計數(shù)器B所記錄的數(shù)量的大小并且根據(jù)比較的結 果調(diào)整發(fā)出分片請求的周期。
還包括，播放指針，用于指示當前播放到所述媒體文件的哪一塊，所述播 放器根據(jù)每一個分片請求距離所述播放指針的差值賦予相應的超時閥值，使得 距離所述播放指針近的分片請求的超時閥值比距離播放指針遠的分片請求的超 時閥j直小。
本發(fā)明公開的一種點對點移動流媒體的傳輸方法和播放器，重點針對P2P 傳輸?shù)奶攸c，在采用UDP協(xié)議來傳輸數(shù)據(jù)的基礎上，結合當前播放進度，對于 每一個數(shù)據(jù)塊請求，通過與播放指針距離和播放碼率來相應的給定一個重傳超 時值，解決了丟包重傳的問題。通過上層應用進行請求發(fā)送的調(diào)整，避免了網(wǎng) 絡狀況不好時發(fā)包過多，導致網(wǎng)絡崩潰的情況，解決了網(wǎng)絡擁塞的問題。增加 了流量控制，從而使得終端能夠及時的處理所獲得的消息和數(shù)據(jù)，解決了終端 之間的交互問題。本發(fā)明重點面向WiFi移動數(shù)據(jù)網(wǎng)絡環(huán)境，針對無線互l關網(wǎng)的特點，綜合考慮了無線網(wǎng)絡的無線帶寬/鏈路質(zhì)量變化比較大和移動IP產(chǎn)生的
波動問題，提供了 一個WiFi網(wǎng)絡內(nèi)基于UDP的可靠傳輸實現(xiàn)方法。


圖1是本發(fā)明的WIFIP2P網(wǎng)絡結構示意圖。 圖2是基于UDP的信令傳輸會話流程圖。 圖3是基于UDP的數(shù)據(jù)傳輸會話流程圖。 圖4是本發(fā)明的丟包檢測方法流程圖。 圖5是本發(fā)明的流媒體播放器結構示意圖。
具體實施方式
下面結合附圖和具體實施方式
對本發(fā)明做進一步詳細說明。
本發(fā)明主要針對的是WiFi網(wǎng)絡中的無線終端(筆記本、PC)。在這些終端 上安裝P2P客戶端，以P2P的方式組織在一起，形成一張WiFi中的P2P網(wǎng)絡。 P2P客戶端以P2P的模式分享用戶提供的內(nèi)容及分發(fā)運營商自己組織的內(nèi)容。
如圖1所示是本發(fā)明的WIFI P2P網(wǎng)絡結構示意圖，在WiFi網(wǎng)絡中有多個 用戶節(jié)點，區(qū)域管理服務器也是作為一個用戶節(jié)點存在，區(qū)域管理服務器是作 為靜態(tài)PEER的補償服務器，同時也是區(qū)域中心。內(nèi)容源管理服務器和中心片 庫，以及EPG和版本升級服務器，服務于WiFi網(wǎng)絡。該處區(qū)域中心包括區(qū)域管 理服務器和靜態(tài)PEER(靜態(tài)節(jié)點)，區(qū)域管理服務器是用來管理所有用戶節(jié)點的， 而靜態(tài)節(jié)點就是補充服務器，是用來為用戶節(jié)點提供補償服務的。
如圖2所示是基于UDP的信令傳輸會話流程圖，不同的源Peer分別通過UDP 驅(qū)動線程向信令處理線程發(fā)出數(shù)據(jù)狀態(tài)請求，信令處理線程根據(jù)請求發(fā)回數(shù)據(jù) 狀態(tài)(Bitmap )。
圖2中，211是源Peer 1向UDP驅(qū)動線程發(fā)出數(shù)據(jù)狀態(tài)請求，212是UDP 驅(qū)動線程向信令處理線程發(fā)出數(shù)據(jù)狀態(tài)請求，213是信令處理線程向源Peer 1發(fā) 回數(shù)據(jù)狀態(tài)(Bitmap )。同樣的，圖2中的221是源Peer 2向UDP驅(qū)動線程發(fā) 出數(shù)據(jù)狀態(tài)請求，222是UDP驅(qū)動線程向信令處理線程發(fā)出數(shù)據(jù)狀態(tài)請求，223
7是信令處理線程向源Peer 2發(fā)回數(shù)據(jù)狀態(tài)(Bitmap ).
如圖3所示是基于UDP的數(shù)據(jù)傳輸會話流程圖，圖中的301是數(shù)據(jù)請求任 務模塊進行傳輸分配，302是數(shù)據(jù)請求任務模塊向源Peer發(fā)出塊請求，303是源 Peer向UDP驅(qū)動線程發(fā)出數(shù)據(jù)塊回復消息，304是UDP驅(qū)動線程向數(shù)據(jù)處理任 務模塊發(fā)出數(shù)據(jù)塊回復消息，305是數(shù)據(jù)處理任務模塊向緩沖區(qū)發(fā)送數(shù)據(jù)。
目前現(xiàn)有的互聯(lián)網(wǎng)上的P2P流媒體軟件在進行數(shù)據(jù)傳輸時都采用了 UDP協(xié) 議進行傳輸，UDP相對于TCP ( Transmission Control Protocol傳輸控制協(xié)議) 而言，傳輸速度快，比較適合流媒體傳輸，但是由于其沒有擁塞控制，丟包重 傳和流量控制機制，從而導致UDP協(xié)議難以適應網(wǎng)絡抖動性比較大的情況，而 在P2P流媒體傳輸里如果不處理丟包的情況，則會影響終端之間的相互共享。
如圖4所示是本發(fā)明的丟包檢測方法流程圖，圖中，步驟401首先是根據(jù) 播放器需要發(fā)出分片請求，然后步驟402將該請求加入到請求列表中，并記錄 該請求發(fā)出的時間；接收分片請求的回復，并刪除請求列表中的相應記錄；然 后步驟403判斷定時器時間是否到？否則回到步驟401。是則步驟404檢查請求 列表，并且步驟405判斷是否有請求超時，否則回到步驟401;是則步驟406將 該請求從請求列表中刪除，然后對超時的分片重新請求，回到步驟402繼續(xù)執(zhí) 行，直至請求結束。
本發(fā)明重點解決了 UDP傳輸中需要解決的幾個重要的問題，首先是丟包重 傳的問題，具體實施方案即如圖4所示，下面詳細描述如下
終端之間的交互主要包括信令和數(shù)據(jù)的交互(如圖2和圖3所示)，這兩類 消息都可能在傳輸過程中丟掉。由于P2P的數(shù)據(jù)傳輸采用的是拉模式，即所有 信令和數(shù)據(jù)的傳輸都是應請求方的請求而進行回復的，因此請求方可以知道哪 些信令和數(shù)據(jù)丟失了。終端維護一個請求列表，在終端發(fā)出一個分片請求后， 將該分片的請求加入到請求列表中，同時記錄該分片請求發(fā)出去的時間。終端 定時檢查請求列表，如發(fā)現(xiàn)某個分片超時，則將該分片從請求列表中刪除，同 時優(yōu)先重新發(fā)出該分片請求。如果請求的分片及時回復，則同樣需要將該分片請求從請求列表中刪除。
沒有及時回復的數(shù)據(jù)何時進行重請求，對系統(tǒng)性能的影響比較重要，如果 超時時間定的太長，導致終端需要的數(shù)據(jù)不能滿足播放進度的需要，如果太短， 則又會導致過多的數(shù)據(jù)重請求。本發(fā)明提出了 一種根據(jù)播放進度的緊迫程度來
確定該超時時間的方法，從而能夠有效的結合P2P流媒體播放的特點。
對于P2P流媒體的播放器，設置一播放指針，所謂播放指針，就是當前播 放器播放到媒體文件的哪一塊，則對于某個發(fā)出去的塊請求，根據(jù)其離當前播 放指針的差值賦予一超時值，如果該塊里播放指針比較近，則設置的超時值比 較短，而如果該塊里播放指針比較遠，則超時值設置得相對比較大一點，該超 時值可以根據(jù)塊的大小、該塊與播放指針相差的塊數(shù)以及播放的碼率來確定。
上段主要描述了如何設置已請求列表中的超時值，這里如果某個數(shù)據(jù)的超 時值到，則就重新請求，不再判斷距離播放指針的遠近。
或者，對于每次數(shù)據(jù)請求的生成，首先掃描已請求列表，檢查已請求列表 中的數(shù)據(jù)請求，如果某個數(shù)據(jù)的超時值已到，則再根據(jù)該塊里播放指針的距離， 如果該塊離播放指針的距離比較近，則重新發(fā)出該塊數(shù)據(jù)的請求，而如果該塊 離播放指針比較遠，則將該塊從請求列表中刪除，從而在下次數(shù)據(jù)請求生成時 該塊則有可能會被再次選擇到。
其次本發(fā)明解決的是擁塞控制問題，具體實施方案
由于移動網(wǎng)絡的波動性比較大，當網(wǎng)絡比較擁塞的時候，如果還是在不停 的發(fā)出數(shù)據(jù)請求，則會導致網(wǎng)絡的更加擁塞，甚至會導致網(wǎng)絡的崩潰。對于TCP 而言，其本身就有擁塞控制過程，而對于UDP傳輸而言，如果不考慮擁塞控制， 則難以應對網(wǎng)絡抖動性比較大的情況。針對這一問題，本發(fā)明結合P2P傳輸?shù)?特點，提出了 一種適合P2P流媒體的擁塞控制方案。
鑒于P2P客戶端的數(shù)據(jù)獲得都是事先通過發(fā)出數(shù)據(jù)請求才獲得的，而不是 對端主動發(fā)送的，因此可以通過客戶端的數(shù)據(jù)請求機制的動態(tài)調(diào)整來實現(xiàn)數(shù)據(jù) 傳輸?shù)淖赃m應調(diào)整。當網(wǎng)絡狀況比較好時，可以多發(fā)請求，而當網(wǎng)絡狀況比較
9差時，則減少數(shù)據(jù)請求的發(fā)生。這里比較重要的是客戶端如何判斷網(wǎng)絡狀況的
好壞，本發(fā)明結合P2P的特點，提出一種方案，即請求方記錄兩個變量 一個 是發(fā)送請求的數(shù)目，二是回復的數(shù)目，如果回復的數(shù)目遠小于發(fā)送請求的數(shù)目， 則認為網(wǎng)絡狀況不好，此時需要減少發(fā)送請求的數(shù)目，如果接近，則認為網(wǎng)絡 狀況比較好，可以考慮增加請求的數(shù)目，但是增加有一個上限，超過該上限就 不再考慮增加。
本發(fā)明還解決了流量控制問題，具體實施方案
由于客戶端處理速度的限制，當網(wǎng)絡狀況比較好時，大量數(shù)據(jù)的到來可能 會導致客戶端來不及處理，這時候客戶端就只能將到來的數(shù)據(jù)丟棄掉，雖然丟 棄掉的數(shù)據(jù)會重新請求，但這與本發(fā)明的擁塞控制過程相沖突，由于本發(fā)明的 擁塞控制過程在判斷網(wǎng)絡狀況好壞的一個標準就是發(fā)出去的數(shù)據(jù)請求回復了多 少，如果回復的少，則認為網(wǎng)絡狀況不好，而丟棄掉的數(shù)據(jù)則會認為是沒有回 復的數(shù)據(jù)。因此客戶端在進行數(shù)據(jù)請求時要引入窗口機制，該窗口會設置一個 上限值，而在該上限值內(nèi)，窗口是動態(tài)調(diào)整的，數(shù)據(jù)處理速度快，就增大窗口 的大小，但不能超過上限值，處理慢，就減少窗口大小。即該窗口的大小取決 于數(shù)據(jù)處理的速度，在發(fā)生數(shù)據(jù)請求時，首先需要掃描該窗口的大小，當窗口 滿時，則數(shù)據(jù)請求無法發(fā)出，只有在發(fā)送窗口不滿時才能夠進行數(shù)據(jù)請求。
目前互^:網(wǎng)上的解決方案通過抓包分析，發(fā)現(xiàn)這些P2P ^L件的UDP傳輸方 式采用一問一答的方式，即接收方對于每一個接收到的數(shù)據(jù)都需要進行一個回 復，這種方式會造成網(wǎng)絡間存在大量的回復消息，當網(wǎng)絡狀況變差出現(xiàn)丟包時， 如果回復消息丟失，則會造成數(shù)據(jù)傳輸?shù)男阅艽蟠蠼档?，不能根?jù)網(wǎng)絡狀況的 波動而做一些調(diào)整。本發(fā)明相對于現(xiàn)有方案的特點在于去除了每個UDP消息 的回復消息，減少了無效的流量，節(jié)約了網(wǎng)絡帶寬。由于本發(fā)明沒有回復消息， 因此圖中沒有對應的項。
如圖5所示是本發(fā)明的流媒體播放器結構示意圖，圖中所示是在移動通信 網(wǎng)絡中共享及分發(fā)運營商組織的流媒體文件的內(nèi)容的流媒體播放器，實現(xiàn)本發(fā)明的功能的部分，包括分片請求發(fā)送模塊，用于周期性地定時發(fā)出分片請求； 請求列表維護模塊，用于記錄發(fā)出的分片請求以及所述分片請求發(fā)出的時間； 超時檢查模塊，用于周期性地定時檢查所述請求列表中的分片請求是否超時， 并且刪除所述請求列表中超時的分片請求同時重新發(fā)出所述分片請求；分片請 求接收模塊，用于接收發(fā)出的分片請求的回復信息，同時刪除所述請求列表中 的所述分片請求的相應記錄。
本發(fā)明重點針對P2P傳輸?shù)奶攸c，在采用UDP協(xié)議來傳輸數(shù)據(jù)的基礎上， 通過上層應用來實現(xiàn)了 UDP的可靠傳輸，克服了現(xiàn)有P2P的UDP傳輸冗余消息 比較多并且無法針對網(wǎng)絡狀況的波動進行相應調(diào)整的缺點。
重傳超時值的確定，結合了當前播放進度，對于每一個數(shù)據(jù)塊請求，都相 應的給定一個超時值，該超時值通過與播放指針距離和播放碼率來共同確定。
對于網(wǎng)絡擁塞的情況，通過上層應用進行請求發(fā)送的調(diào)整來進行控制，從 而避免了網(wǎng)絡狀況不好時還是在極力發(fā)包，導致網(wǎng)絡崩潰。
對于終端之間的交互增加了流量控制，從而使得終端能夠及時的處理所獲 得的消息和數(shù)據(jù)。
本發(fā)明還可有其他多種實施例，在不背離本發(fā)明精神及其實質(zhì)的情況下， 熟悉本領域的技術人員可根據(jù)本發(fā)明作出各種相應的改變和變形，但這些相應 的改變和變形都應屬于本發(fā)明所附的權利要求的保護范圍。
權利要求
1.一種點對點移動流媒體的傳輸方法，支持流媒體播放器在移動通信網(wǎng)絡中的流媒體文件內(nèi)容共享及分發(fā)運營商組織的內(nèi)容，其特征在于，包括如下步驟(1)所述流媒體播放器根據(jù)播放所述流媒體信息的需要周期性地發(fā)出分片請求；(2)所述流媒體播放器記錄所述分片請求發(fā)出的時間并增加到請求列表中；所述流媒體播放器接收分片請求的回復，同時將收到回復的分片請求從請求列表中刪除；(3)所述流媒體播放器按照設定的定時器周期性地根據(jù)每一個分片請求發(fā)出的時間判斷所述請求列表中是否有分片請求超時？否則回到步驟(1)，是則從所述請求列表中刪除所述超時的分片請求并重新發(fā)出請求，回到步驟(2)。
2. 如權l(xiāng)所述的傳輸方法，其特征在于，在所述步驟(l)中，還包括在計 數(shù)器A中記錄發(fā)出的分片請求的數(shù)量；在所述步驟(2)中，還包括在計數(shù)器B 中記錄接收到的分片請求的回復的數(shù)量；并且在步驟(1)中還比較所述計時器 A和計數(shù)器B所記錄的數(shù)量的大小并且根據(jù)比較的結果調(diào)整所述發(fā)出分片請求的 周期。
3. 如權2所述的傳輸方法，其特征在于，在所述步驟(l)中，所述調(diào)整所 述發(fā)出分片請求的周期對于在單位時間內(nèi)發(fā)出分片請求的數(shù)量設定上限。
4. 如權3所述的傳輸方法，其特征在于，在所述步驟(l)中，所述流媒體 播放器首先掃描根據(jù)其數(shù)據(jù)處理的速度設置的窗口 W,只有當所述窗口 W不滿時 才發(fā)出分片請求。
5. 如權4所述的傳輸方法，其特征在于，在所述步驟(3)中，所述根據(jù)每 一個分片請求發(fā)出的時間判斷所述請求列表中是否有分片請求超時的方法包 括根據(jù)所述每一個分片請求距離指示當前播放到所述媒體文件的哪一塊的播放指針的差值賦予相應的超時閥值，距離所述播放指針近的分片請求的超時閥 值比距離播放指針遠的分片請求的超時閥值小。
6. 如權5所述的傳輸方法，其特征在于，在所述步驟(3)中，還根據(jù)所述 流+某體播放器的播放碼率來確定每一個分片請求的超時閥值。
7. 如權5所述的傳輸方法，其特征在于，在所述步驟(3)中，所述流媒體 播放器按照設定的定時器周期性地根據(jù)每一個分片請求發(fā)出的時間判斷所述請 求列表中是否有分片請求超時？否則回到步驟(l),是則從所述請求列表中刪 除所述超時的分片請求，并重新發(fā)出請求，回到步驟(2)。
8. —種點對點移動流媒體的播放器，在移動通信網(wǎng)絡中共享及分發(fā)運營商 組織的流媒體文件的內(nèi)容，包括分片請求發(fā)送模塊，用于周期性地定時發(fā)出分 片請求；其特征在于，還包括，請求列表維護模塊，用于記錄發(fā)出的分片請求 以及所述分片請求發(fā)出的時間；超時檢查模塊，用于周期性地定時檢查所述請 求列表中的分片請求是否超時，并且刪除所述請求列表中超時的分片請求同時 重新發(fā)出所述分片請求；分片請求接收模塊，用于接收發(fā)出的分片請求的回復 信息，同時刪除所述請求列表中的所述分片請求的相應記錄。
9. 如權8所述的播放器，其特征在于，還包括，計數(shù)器A,用于記錄所述分 片請求發(fā)送^f莫塊發(fā)出的分片請求的數(shù)量；計數(shù)器B，用于記錄所述分片請求接收 模塊接收到的分片請求的回復的數(shù)量；所述播放器比較所述計時器A和計數(shù)器B 所記錄的數(shù)量的大小并且根據(jù)比較的結果調(diào)整發(fā)出分片請求的周期。
10. 如權9所述的播放器，其特征在于，還包括，播放指針，用于指示當 前播放到所述媒體文件的哪一塊，所述播放器根據(jù)每一個分片請求距離所述播 放指針的差值賦予相應的超時閥值，使得距離所述播放指針近的分片請求的超 時閥值比距離播放指針遠的分片請求的超時閥值小。
全文摘要
本發(fā)明涉及一種點對點移動流媒體的傳輸方法和播放器，支持流媒體播放器在移動通信網(wǎng)絡中共享及分發(fā)運營商組織的內(nèi)容，包括根據(jù)播放所述流媒體信息的需要周期性地發(fā)出分片請求；記錄所述分片請求發(fā)出的時間并增加到請求列表中；接收分片請求的回復，同時將收到回復的分片請求從請求列表中刪除；按照設定的定時器周期性地根據(jù)每一個分片請求發(fā)出的時間判斷所述請求列表中是否有分片請求超時，否則回到步驟(1)，是則從所述請求列表中刪除所述超時的分片請求并重新發(fā)出請求，回到步驟(2)。本發(fā)明通過上層應用的改進實現(xiàn)了UDP的可靠傳輸，克服了現(xiàn)有P2P的UDP傳輸冗余消息比較多并且無法針對網(wǎng)絡狀況的波動進行相應調(diào)整的缺點。
文檔編號H04L12/18GK101562530SQ20091010736
公開日2009年10月21日 申請日期2009年5月15日 優(yōu)先權日2009年5月15日
發(fā)明者健 季, 偉 羅 申請人:中興通訊股份有限公司