視頻點播系統中猝髮式音視頻流傳輸及接收技術的製作方法

2023-10-05 13:50:14

專利名稱：視頻點播系統中猝髮式音視頻流傳輸及接收技術的製作方法
技術領域：
本發明屬於網絡多媒體數據傳送與播放領域。本發明涉及一種在網絡上有效傳送音頻/視頻流的技術，並特別涉及一種不改變已有播放體系的情況下實現視頻點播(以下簡稱VOD)播放的方法。
2技術背景VOD技術經歷多年的發展，原有的技術已經不很符合新的網絡環境。現在的網絡正向寬帶發展，第一代和第二代VOD系統一般採用用戶數據報協議(以下簡稱UDP)傳送，這種方法適應了以前的網絡環境。但在寬帶網絡下，UDP傳送數據不能很好的節省網絡帶寬；另處，UDP的遠程傳送數據需要有路由器和防火牆的配合。傳輸控制協議(以下簡稱TCP)的傳送在寬帶環境下可以很好的傳送數據流，但它同樣在遠程傳送數據時需要有路由器和防火牆的配合。事實上，多數路由器和防火牆都開放超文本傳輸協議(以下簡稱HTTP)數據包和埠，如果能採用HTTP協議有效的傳送數據流，則可以使VOD系統的功能更強勁，使其應用範圍更廣。
HTTP協議為傳送WEB服務而設計，如果要使其很好的傳送多媒體數據流，則必須對其進行改造。本發明可以解決這一問題。

發明內容本發明的具體內容如下●在播放器請求時才發送數據的方法；●採用特定的格式的PUT方法(HTTP協議的一種格式)請求音頻/視頻節目；●視頻伺服器回應播放器請求的方法；●播放器與視頻伺服器協同工作的方法；●不改變已有播放體系的情況下實現VOD播放的方法；

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