專利名稱：視頻點播系統(tǒng)中猝發(fā)式音視頻流傳輸及接收技術(shù)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明屬于網(wǎng)絡(luò)多媒體數(shù)據(jù)傳送與播放領(lǐng)域。本發(fā)明涉及一種在網(wǎng)絡(luò)上有效傳送音頻/視頻流的技術(shù)，并特別涉及一種不改變已有播放體系的情況下實現(xiàn)視頻點播(以下簡稱VOD)播放的方法。
2技術(shù)背景VOD技術(shù)經(jīng)歷多年的發(fā)展，原有的技術(shù)已經(jīng)不很符合新的網(wǎng)絡(luò)環(huán)境。現(xiàn)在的網(wǎng)絡(luò)正向?qū)拵Оl(fā)展，第一代和第二代VOD系統(tǒng)一般采用用戶數(shù)據(jù)報協(xié)議(以下簡稱UDP)傳送，這種方法適應(yīng)了以前的網(wǎng)絡(luò)環(huán)境。但在寬帶網(wǎng)絡(luò)下，UDP傳送數(shù)據(jù)不能很好的節(jié)省網(wǎng)絡(luò)帶寬；另處，UDP的遠(yuǎn)程傳送數(shù)據(jù)需要有路由器和防火墻的配合。傳輸控制協(xié)議(以下簡稱TCP)的傳送在寬帶環(huán)境下可以很好的傳送數(shù)據(jù)流，但它同樣在遠(yuǎn)程傳送數(shù)據(jù)時需要有路由器和防火墻的配合。事實上，多數(shù)路由器和防火墻都開放超文本傳輸協(xié)議(以下簡稱HTTP)數(shù)據(jù)包和端口，如果能采用HTTP協(xié)議有效的傳送數(shù)據(jù)流，則可以使VOD系統(tǒng)的功能更強(qiáng)勁，使其應(yīng)用范圍更廣。
HTTP協(xié)議為傳送WEB服務(wù)而設(shè)計，如果要使其很好的傳送多媒體數(shù)據(jù)流，則必須對其進(jìn)行改造。本發(fā)明可以解決這一問題。

發(fā)明內(nèi)容本發(fā)明的具體內(nèi)容如下●在播放器請求時才發(fā)送數(shù)據(jù)的方法；●采用特定的格式的PUT方法(HTTP協(xié)議的一種格式)請求音頻/視頻節(jié)目；●視頻服務(wù)器回應(yīng)播放器請求的方法；●播放器與視頻服務(wù)器協(xié)同工作的方法；●不改變已有播放體系的情況下實現(xiàn)VOD播放的方法；

圖1給出的是播放器發(fā)送請求包頭和接收數(shù)據(jù)流的過程；圖2給出的是服務(wù)器響應(yīng)播放器請求的過程；圖3給出的是不改變已有播放體系的情況下實現(xiàn)VOD播放的過程。
具體實施方式
猝發(fā)式音視頻流傳輸及接收技術(shù)的核心思想是播放器在要需要數(shù)據(jù)時才請求服務(wù)器發(fā)送，播放器每次請求發(fā)送盡量少(但不影響播放)的數(shù)據(jù)塊，服務(wù)器保證在最短的時間內(nèi)把相應(yīng)的數(shù)據(jù)塊傳送給播放器。
播放器采用HTTP協(xié)議的PUT方法向服務(wù)器請求節(jié)目流。播放器在第一次點播指定的節(jié)目和重定位節(jié)目流的位置時，請求的信息包頭稍有區(qū)別。
第一次點播指定的節(jié)目時的請求信息列表●點播的節(jié)目流路徑(可能是虛擬路徑)●點播的節(jié)目起點位置●點播的節(jié)目終點位置●第一次點播的標(biāo)志(標(biāo)志是第一次點播)●點播者的帳號●點播者的密碼重定位指定的節(jié)目時的請求信息列表●點播的節(jié)目流路徑(真實路徑)●點播的節(jié)目起點位置●點播的節(jié)目終點位置●第一次點播的標(biāo)志(標(biāo)志不是第一次點播)●點播者的帳號●點播者的密碼由于本發(fā)明的服務(wù)器采用的是猝發(fā)式傳送，為了減少服務(wù)器的運算開銷，當(dāng)重定位節(jié)目流時，播放器傳送到服務(wù)器的節(jié)目路徑是真實路徑，并且標(biāo)志節(jié)目為非第一次點播，這樣，服務(wù)器接收到請求后，將不對請求的節(jié)目流的名字進(jìn)行重新解析，也不再對用戶進(jìn)行認(rèn)證。除此之外，對兩者的請求，服務(wù)器的處理是相同的。
播放器發(fā)送給服務(wù)器的HTTP請求格式如下CHAR szRequestStreamHttpHeader[]＝{″USERAGENTHEROVODPLAY\r\n″∥播放器驗證標(biāo)志″VODUSERIP％u\r\n″ ∥用戶的當(dāng)?shù)豂P地址″PROIRITY％u\r\n″ ∥用于重定位時發(fā)送優(yōu)先級″FILMID％u\r\n″∥影片ID″STARTPOS％u\r\n″ ∥起動位置(請求的開始位置字節(jié)數(shù))″STOPPOS％u\r\n″ ∥結(jié)束位置(請求的結(jié)束位置字節(jié)數(shù))″USERNAME％s\r\n″ ∥用戶名稱″PASSWORD％s\r\n″ ∥口令″FIRSTPLAY％s\r\n″ ∥是否起動″FILMPATH％s\r\n″ ∥文件路徑″USERLANG％s\r\n″ ∥客戶端字符集″USERSN％u\r\n″∥用戶的時間序號″STARTTIME％s\r\n″； ∥流起動時間，從服務(wù)器上獲取“\r\n”}；服務(wù)器傳送給播放器的包頭信息列表●點播的節(jié)目流真實路徑●點播的節(jié)目起點位置●點播的節(jié)目的長度(字節(jié))
●傳送給服務(wù)器的數(shù)據(jù)流的長度●傳送的開始時間●節(jié)目的類型●服務(wù)器的響應(yīng)碼●服務(wù)器的響應(yīng)字符串等圖1給出了播放器請求(或重位)節(jié)目流和接收節(jié)目流的過程。該過程包括以下步驟●播放器把請求組織成szRequestStreamHttpHeader格式的HTTP頭；●播放器把該HTTP頭發(fā)送到相應(yīng)的服務(wù)器(圖1中的(1))；如果發(fā)送失敗，則此次的播放請求終止(圖1中的(4))；如果發(fā)送成功，則播放器等待服務(wù)器的回應(yīng)定長的數(shù)據(jù)包頭(圖1中的(2))；●如果服務(wù)器沒有取到數(shù)據(jù)包頭，則此次的播放請求終止(圖1中的(4))；如果取到數(shù)據(jù)包頭信息，則分析服務(wù)器的返回信息。返回信息中包括服務(wù)器是否接受播放器的請求以及請求數(shù)據(jù)流的名字及大小等信息；●如果服務(wù)器接受播放器的請求，則會傳送回相應(yīng)的節(jié)目流的信息，并且緊接著會傳送數(shù)據(jù)流；●播放器接收一塊數(shù)據(jù)，然后播放；在播放過程中，播放器不再接收數(shù)據(jù)，服務(wù)器也不對其傳送數(shù)據(jù)；當(dāng)該塊數(shù)據(jù)傳送完后，播放器再請求一塊數(shù)據(jù)進(jìn)行播放(圖1中的(3))；●直到接收完所有數(shù)據(jù)或者用戶中斷播放過程，此次播放過程結(jié)束(圖1中的(4))。
圖2給出了服務(wù)器在接收到播放器的請求后的處理過程。該過程包括以下步驟●服務(wù)器有一個偵聽線程接收到播放器的連接信息(圖2中的(5))；●當(dāng)接收到一個播放器的請求后，啟動一個線程為播放器服務(wù)(圖2中的(6))；●服務(wù)器接收線程接收播放器的請求頭信息；如果接收信息出錯，則拒絕服務(wù)；如果接收正確，則進(jìn)一步分析播放器的請求；●如果播放器是第一次請求指定的節(jié)目流，則對節(jié)目名進(jìn)行處理；當(dāng)播放器第一次請求時，其請求的節(jié)目路徑可能是虛擬路徑，因此要進(jìn)行路徑轉(zhuǎn)換(圖2中的(7))；●如果轉(zhuǎn)換節(jié)目路徑正確，則準(zhǔn)備并發(fā)送回應(yīng)播放器的信息包頭(圖2中的(8))；如果發(fā)送不正確，則服務(wù)線程退出，服務(wù)器為播放器的服務(wù)終止；●如果信息包頭發(fā)送正確，并且服務(wù)器認(rèn)可播放器的請求，則向播放器發(fā)送數(shù)據(jù)流(圖2中的(9))；●服務(wù)器發(fā)送數(shù)據(jù)時，采用阻塞式發(fā)送方式；如果播放器不接收，則服務(wù)器就不能發(fā)送數(shù)據(jù)；●服務(wù)器每次發(fā)送一塊數(shù)據(jù)，并且保證在最短的時間內(nèi)把這塊數(shù)據(jù)傳送給播放器；●服務(wù)器把數(shù)據(jù)發(fā)送完畢，或者在發(fā)送的過程中數(shù)據(jù)發(fā)送不出去，則服務(wù)器的服務(wù)線程退出，不再為播放器服務(wù)。
前面闡述了播放器及服務(wù)器的協(xié)同工作完成音視頻流的傳輸及接收技術(shù)。本發(fā)明的數(shù)據(jù)傳送的關(guān)鍵是需要時才傳送數(shù)據(jù)，如果要傳送數(shù)據(jù)，則用最短的時間內(nèi)傳送完成。由于播放器在播放已取得的數(shù)據(jù)時，服務(wù)器不會向其傳送數(shù)據(jù)。而此時服務(wù)器可以為其它播放器服務(wù)。這樣每個播放請求在播放過程中不是一直占用網(wǎng)絡(luò)帶寬，而是間歇式的，猝發(fā)式的占用，從而可以充分利用網(wǎng)絡(luò)帶寬。
實驗證明，在100MBPS(MBPS指每秒1M比特)的網(wǎng)絡(luò)上，采用本發(fā)明的技術(shù)，可以傳送80個1.5MBPS的MPEG1的節(jié)目流，并且保證播放流暢；也就是說，采用本發(fā)明的技術(shù)，在100MBPS的網(wǎng)絡(luò)上可以穩(wěn)定的傳送120MBPS的音視頻數(shù)據(jù)流，并保證它們能夠流暢的播放。
能做到這一點的原因不是增加物理的網(wǎng)絡(luò)帶寬，而是本發(fā)明的猝發(fā)式傳送技術(shù)適合于網(wǎng)絡(luò)多媒體數(shù)據(jù)流的傳送。這種技術(shù)充分利用音視頻流邊播放邊取數(shù)據(jù)的特點以節(jié)省網(wǎng)絡(luò)帶寬。
在前面的闡述中，還有一點需要更進(jìn)一步的說明和解決，同時這也是本發(fā)明的一個部分。這就是，現(xiàn)有的播放器多數(shù)是讀取本地的文件進(jìn)行播放，如果要支持播放網(wǎng)絡(luò)上的文件流，則需要對播放器進(jìn)行改造。MICROSOFT的MEDIAPLAYER及REALNETWORD的REALPLAYER可以播放網(wǎng)絡(luò)上流文件。但是它們不能播放任意的非流式的文件如AVI、WAV、MIDI等。但是，如果這些文件是本地文件，則它們可以很好的被大多數(shù)據(jù)播放器播放。本發(fā)明的如下技術(shù)可以使得播放器像播放本地文件一樣播放網(wǎng)絡(luò)文件，而且不需更改播放器的原有的播放體系。
該技術(shù)的中心思想是盡量不改變原有的播放器的體系；通過掛鉤系統(tǒng)的文件操作的API函數(shù)，掛接上的新API函數(shù)可以讀取網(wǎng)絡(luò)文件；當(dāng)播放器調(diào)用文件操作API函數(shù)打開已掛接的網(wǎng)絡(luò)文件時，新的文件操作API函數(shù)將去打開網(wǎng)絡(luò)文件，對播放器來說，就象打開本地文件一樣進(jìn)行操作。
不改變已有播放體系的情況下實現(xiàn)VOD播放的步驟如下●裝入已有的播放體系的播放器，并裝入掛鉤文件操作API函數(shù)的模塊，同時掛接相應(yīng)的API函數(shù)(圖3中的(10))；●調(diào)用裝入的播放器播放文件(圖3中的(11))；如果播放的是VOD文件，則掛接對該文件的操作(圖3中的(12))；●播放器像播放本地文件一樣操作要播放的文件，如打開音視頻流文件，從文件中讀取數(shù)據(jù)，重新定位文件等(圖3中的(13))；●如果打開的是本地文件，則被掛接的新的文件操作的API函數(shù)會調(diào)用系統(tǒng)的相應(yīng)的函數(shù)來操作文件(圖3中的(14))；如果是VOD文件，則這些新的被掛接API函數(shù)會自動到VOD服務(wù)器上讀取對應(yīng)的VOD文件(圖3中的(15))；這樣對于播放器來說，它根本不知道現(xiàn)在播放的是VOD文件還是本地文件；●播放器利用新掛接的API函數(shù)的操作要播放的節(jié)目流(圖3中的(16))，直到播放結(jié)束；●如果播放完成，則解除對該文件的掛鉤(如果前面已經(jīng)掛接)，進(jìn)而該播放過程結(jié)束(圖2中的(17))。
權(quán)利要求
1.視頻點播(以下簡稱VOD)系統(tǒng)猝發(fā)式音視頻流傳輸及接收技術(shù)通過一定的方法，在不改變已有的播放體系的情況下實現(xiàn)VOD播放，并且在播放音視頻流時可以有效的節(jié)省網(wǎng)絡(luò)帶寬；該方法包括以下步驟裝入已有的播放體系的播放器，并裝入掛鉤文件操作應(yīng)用程序編程接口(以下簡稱API)函數(shù)的模塊，同時掛接相應(yīng)的API函數(shù)；掛接要播放的VOD文件，并調(diào)用裝入的播放器播放該文件；播放器把請求信息組織成超文本傳送協(xié)議(以下簡稱HTTP)請求包頭，并發(fā)送到相應(yīng)的服務(wù)器；然后等待服務(wù)器的回應(yīng)的定長的數(shù)據(jù)包頭；播放器分析服務(wù)器傳回的信息，如是服務(wù)器按受播放器的請求，則播放器準(zhǔn)備接收數(shù)據(jù)和播放；播放器接收一塊數(shù)據(jù)，然后播放；在播放過程中，播放器不再接收數(shù)據(jù)，服務(wù)器也不對其傳送數(shù)據(jù)；當(dāng)該塊數(shù)據(jù)傳送完后，播放器再請求一塊數(shù)據(jù)進(jìn)行播放；直到接收完所有數(shù)據(jù)或者用戶中斷播放過程，此次播放過程結(jié)束；如果播放完成，則解除對該文件的掛鉤(如果前面已經(jīng)掛接)，進(jìn)而該播放過程結(jié)束。
2.權(quán)利要求1的方法還包括步驟服務(wù)器發(fā)送數(shù)據(jù)時，采用阻塞式發(fā)送方式；如果播放器不接收，則服務(wù)器就不能發(fā)送數(shù)據(jù)；服務(wù)器每次發(fā)送一塊數(shù)據(jù)，并且保證在最短的時間內(nèi)把這塊數(shù)據(jù)傳送給播放器；
3.權(quán)利要求1的方法還包括盡量不改變原有的播放器的體系；通過掛鉤系統(tǒng)的文件操作的API函數(shù)，掛接上的新API函數(shù)可以讀取網(wǎng)絡(luò)文件；當(dāng)播放器調(diào)用文件操作API函數(shù)打開已掛接的網(wǎng)絡(luò)文件時，新的文件操作API函數(shù)將去打開網(wǎng)絡(luò)文件，對播放器來說，就象打開本地文件一樣進(jìn)行操作。
全文摘要
多媒體數(shù)據(jù)流的數(shù)據(jù)量大，傳送占用的網(wǎng)絡(luò)帶寬很大?，F(xiàn)有的網(wǎng)絡(luò)帶寬十分寶貴，充分利用現(xiàn)有的網(wǎng)絡(luò)帶寬勢在必行。本發(fā)明的猝發(fā)式音視頻流傳輸及接收技術(shù)可以有效的利用網(wǎng)絡(luò)帶寬，并且不影響音視頻的播放質(zhì)量。本發(fā)明的關(guān)鍵思想是播放器需要數(shù)據(jù)時，服務(wù)器才傳送；如果要傳送數(shù)據(jù)，則用最短的時間內(nèi)傳送完成；由于播放器在播放已取得的數(shù)據(jù)時，服務(wù)器不會向其傳送數(shù)據(jù)。而此時服務(wù)器可以為其它播放器服務(wù)；這樣每個播放請求在播放過程中不是一直占用網(wǎng)絡(luò)帶寬，而是間歇式的，猝發(fā)式的占用，從而可以充分利用網(wǎng)絡(luò)帶。通過掛鉤系統(tǒng)的文件操作的應(yīng)用程序編程接口(API)函數(shù)，可以在不改變已有的播放器體系的情況下，可以很容易使原有的播放器可以播放視頻點播(VOD)服務(wù)器上的文件。
文檔編號H04N7/16GK1471317SQ0212532
公開日2004年1月28日 申請日期2002年7月25日 優(yōu)先權(quán)日2002年7月25日
發(fā)明者梁肇新 申請人:梁肇新