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


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