專利名稱:一種視頻數(shù)據(jù)傳送方法及系統(tǒng)的制作方法
技術領域:
本發(fā)明涉及網(wǎng)絡通信及多媒體技術領域,具體涉及一種視頻數(shù)據(jù)傳送方法及系統(tǒng)。
背景技術:
近年來,寬帶的普及和網(wǎng)絡多媒體技術的發(fā)展,通過網(wǎng)絡來傳送視頻數(shù)據(jù)成為互
聯(lián)網(wǎng)上廣受歡迎的服務之一,視頻用戶數(shù)量龐大而且快速增長,網(wǎng)絡視頻的市場容量也在
快速增長。目前,互聯(lián)網(wǎng)視頻、手機電視、網(wǎng)絡電視(IPTV, Internet Protocol Television)
等視頻新媒體業(yè)務蓬勃發(fā)展,內(nèi)容分發(fā)系統(tǒng)用于將視頻數(shù)據(jù)從運營商傳送至終端用戶,是
視頻新媒體業(yè)務流程中最關鍵的環(huán)節(jié)之一。流媒體技術是當今業(yè)界最廣泛采用的內(nèi)容分發(fā)
技術,它允許用戶邊下載邊播放,無需等待視頻全部下載完成。視頻流媒體分發(fā)的效率和質(zhì)
量很大程度上決定了運營商的運營成本,并決定了終端用戶的觀賞體驗。 采用流媒體的方式實現(xiàn)網(wǎng)絡視頻分發(fā),客戶端播放軟件向流媒體服務器發(fā)送關于
視頻文件的請求報文,流媒體服務器則以特定的傳輸協(xié)議反饋發(fā)送視頻文件的數(shù)據(jù)內(nèi)容。
流媒體傳輸協(xié)議目前較為廣泛采用有HTTP超文件傳輸協(xié)議(HTTP, HyperText Transfer
Protocol),實時流協(xié)議(RTSP, Real TimeStreaming Protocol)等標準協(xié)以及Adobe公司
的私有協(xié)議實時消息傳送協(xié)議(RTMP, Real-time Messaging Protocol)。各種流媒體協(xié)議
因為其實現(xiàn)機制不同,所支持的功能也不相同。例如,Adobe公司的RTMP協(xié)議支持自適應帶
寬的視頻分發(fā)功能,即能夠根據(jù)網(wǎng)絡的帶寬環(huán)境,發(fā)送最適合數(shù)據(jù)量的視頻數(shù)據(jù)。在內(nèi)部實
現(xiàn)中,Adobe公司的流媒體服務器Flash Media Server實際上需要預先存儲不同碼率的視
頻文件副本。比如,為了能夠適應300Kbps,400Kbps和450Kbps的網(wǎng)絡帶寬條件,預先需將
同一個視頻文件轉(zhuǎn)碼為三份副本,即300Kbps、400Kbps和450Kbps碼率的視頻各一份。在
分發(fā)過程中,檢測帶寬參數(shù)并選擇對應碼率的視頻文件副本。 另外,一種業(yè)界常用的HTTP協(xié)議,由于其協(xié)議本身簡單,支持的功能僅僅為簡單 的文件傳送。在實際利用中,視頻業(yè)務運營者往往將一個視頻文件分割成多個視頻片段文 件,并且每個視頻片段文件存儲多個碼率的副本,來達到減少流量和適應帶寬的目的。
雖然上述的幾種協(xié)議以及利用這些協(xié)議的具體做法在實際中解決了減少流量和 自適應帶寬的目的,但是同時也帶來了一些弊端,如效率低下,需要準備多個視頻片段文件 和多份視頻(片段)文件的副本;管理不便,需要對多個視頻片段文件及其副本進行同步管 理;不適應現(xiàn)在的內(nèi)容分發(fā)網(wǎng)絡(CDN, Content Delivery Network)架構(gòu)。
發(fā)明內(nèi)容
有鑒于此,本發(fā)明所要解決的技術問題是提供一種視頻數(shù)據(jù)傳送方法及系統(tǒng),可 自適應網(wǎng)絡帶寬進行視頻數(shù)據(jù)發(fā)送,最大限度保證視頻的流暢播放;而且在分發(fā)過程中,每 次傳送視頻文件中的部分內(nèi)容,避免了將一個視頻文件分割成多個視頻片斷文件,簡化了 文件管理。
本發(fā)明實施例提供的一種視頻數(shù)據(jù)傳送方法,包括 接收來自客戶端的要求發(fā)送第一視頻片段的請求,該請求攜帶有所述第一視頻片 段標識信息及當前可用網(wǎng)絡帶寬參數(shù); 根據(jù)所述可用網(wǎng)絡帶寬調(diào)整所述第一視頻片段的視頻數(shù)據(jù)量,并將調(diào)整后的第一 視頻片段發(fā)送給所述客戶端; 接收來自客戶端的要求發(fā)送第二視頻片段的請求,該請求攜帶有所述第二視頻片 段標識信息及檢測到的網(wǎng)絡帶寬參數(shù); 調(diào)整所述第二視頻片段的視頻數(shù)據(jù)內(nèi)容,使其與所檢測得到的網(wǎng)絡帶寬參數(shù)相匹 配; 發(fā)送調(diào)整后的第二視頻片段給所述客戶端。 本發(fā)明實施例還提供一種視頻數(shù)據(jù)傳送系統(tǒng),包括視頻服務器和客戶端; 所述客戶端,用于發(fā)送請求分發(fā)視頻片段的消息給所述視頻服務器,并提供所請
求的視頻片段標識信息和網(wǎng)絡帶寬信息給視頻服務器; 所述視頻服務器,根據(jù)所述網(wǎng)絡帶寬信息調(diào)整所述視頻片段的視頻數(shù)據(jù)量,使其
與所檢測得到的網(wǎng)絡帶寬參數(shù)相匹配;并發(fā)送調(diào)整后的視頻片段給所述客戶端。 本發(fā)明實施例還提供一種視頻服務器,包括 接收單元,用于接收來自客戶端的要求發(fā)送視頻片段的請求,該請求攜帶有所述 視頻片段標識信息及當前可用網(wǎng)絡帶寬參數(shù); 調(diào)整單元,根據(jù)所述可用網(wǎng)絡帶寬調(diào)整所述視頻片段的視頻數(shù)據(jù)量,使其與所述 網(wǎng)絡帶寬相匹配; 發(fā)送單元,用于將調(diào)整后的視頻片段發(fā)送給所述客戶端。
更適宜地,該視頻服務器還包括 判斷單元,用于判斷所述視頻片段的視頻數(shù)據(jù)量是否大于所述網(wǎng)絡帶寬乘以所述 視頻片斷正常播放所需的時間得到的數(shù)據(jù)量; 若所述判斷單元判定所述視頻片段的視頻數(shù)據(jù)量大于所述網(wǎng)絡帶寬乘以所述視 頻片斷正常播放所需的時間得到的數(shù)據(jù)量,則指示調(diào)整單元刪減所述視頻片段中的視頻數(shù) 據(jù)量,以適應網(wǎng)絡帶寬。 與現(xiàn)有技術中的視頻數(shù)據(jù)分發(fā)技術方案相比,本發(fā)明提供的視頻數(shù)據(jù)傳送技術方 案,在不同網(wǎng)絡帶寬條件下,能夠根據(jù)用戶的不同帶寬自動選擇傳送最合適的數(shù)據(jù)量的內(nèi) 容,保證視頻的流暢、高質(zhì)量播放;傳統(tǒng)的流媒體系統(tǒng)為了提供自適應碼率分發(fā)功能,通過 存儲多份視頻副本的來實現(xiàn)。應用本發(fā)明所公開的方法和系統(tǒng),只需存儲單份的視頻文件, 節(jié)省了存儲空間和成本。本發(fā)明提供的視頻數(shù)據(jù)分發(fā)方法和系統(tǒng),在視頻數(shù)據(jù)發(fā)送過程中, 不是一次性傳輸整份視頻內(nèi)容,而是根據(jù)客戶端請求每次傳輸視頻內(nèi)容的一個片斷,并基 于當前可用網(wǎng)絡帶寬進行傳送,充分利用了網(wǎng)絡帶寬資源?,F(xiàn)有技術的視頻數(shù)據(jù)分發(fā)流程 中,從流媒體服務器到終端用戶客戶端的各個中間環(huán)節(jié)中使用了很多緩存技術,例如CDN 緩存,視頻文件是數(shù)據(jù)密集型,而視頻數(shù)據(jù)量大,不利于緩存系統(tǒng)處理。本發(fā)明提供的視頻 數(shù)據(jù)分發(fā)方法和系統(tǒng),以視頻片斷為單位進行傳送,視頻片斷的數(shù)據(jù)量比整個視頻文件小 很多,更有利于緩存系統(tǒng)處理,提高緩存效率?,F(xiàn)有技術中的視頻分發(fā)方法和系統(tǒng)采取了將 單個視頻文件顯式地分割成多個視頻片斷文件的做法,每次分發(fā)單個視頻片斷文件,這給視頻文件的管理增加了很大麻煩。根據(jù)本發(fā)明可最大限度保證視頻的流暢播放;本發(fā)明提 供的技術方案中存儲和管理的對象仍然是完整的視頻文件,而且在分發(fā)過程中,每次傳送 視頻文件中的部分內(nèi)容,避免了將一個視頻文件分割成多個視頻片斷文件,因而簡化了存
儲管理。 說明書附圖
圖1是本發(fā)明實施例提供的視頻分發(fā)方法流程圖;
圖2a是本發(fā)明實施例提供的視頻數(shù)據(jù)幀結(jié)構(gòu)示意圖;
圖2b是本發(fā)明實施例提供的調(diào)整后的視頻片段示意圖;
圖3是本發(fā)明實施例提供的視頻分發(fā)系統(tǒng)架構(gòu)示意圖;
圖4是本發(fā)明實施例提供的視頻服務器構(gòu)成示意圖。
具體實施例方式
為了解決如背景技術中所述的現(xiàn)有技術中存在的問題或弊端,本發(fā)明提供了一種
能夠自適應網(wǎng)絡帶寬的逐段發(fā)送視頻文件內(nèi)容的方法。通常所說的視頻文件,實際上包括
文件標志信息數(shù)據(jù),音頻編解碼信息數(shù)據(jù)、視頻編解碼信息數(shù)據(jù),音頻內(nèi)容數(shù)據(jù)和視頻內(nèi)容
數(shù)據(jù)。本發(fā)明提供的視頻文件發(fā)送方法,其基本原理是,在從服務器向客戶端的發(fā)送過程
中,每次只發(fā)送整個視頻文件的一部分(稱為視頻片段),并且,根據(jù)網(wǎng)絡帶寬參數(shù)動態(tài)調(diào)
整待發(fā)送的視頻片段中的視頻數(shù)據(jù),比如在不影響視頻信號正常播放的前提下,拋棄其中
不重要的數(shù)據(jù),使從服務器向客戶端發(fā)送的整體數(shù)據(jù)量滿足網(wǎng)絡帶寬條件。通常采用丟幀
(Dro卯ing Frame)這種簡單、有效的碼率適配方法,即通過丟棄視頻序列中一定數(shù)量的編
碼幀來降低視頻的數(shù)據(jù)量,自適應網(wǎng)絡帶寬的變化??蓙G棄的幀為對用戶的主觀感知質(zhì)量
影響較小的編碼幀,從而最大限度地保證視頻重建質(zhì)量。 參照圖l,本發(fā)明提供的一種視頻數(shù)據(jù)傳送方法,包括如下步驟 S101,客戶端向服務器請求關于某待發(fā)送視頻文件的元信息,該元信息包含所述
待發(fā)送視頻文件的視頻片段數(shù)量及各視頻片段標識信息; S102,服務器將該視頻文件的元信息反饋給客戶端; 預先將待發(fā)送視頻文件劃分為若干視頻片段,每個視頻片段包含若干視頻文件編 碼時設置的畫面組(Group of Pictures)單元,并為每個視頻片段設置標識,該標識可采用 該視頻片段序號或該視頻片段在視頻文件中的起始位置信息。根據(jù)具體情況,各視頻片段 包含的畫面組單元數(shù)量可相同也可不同。 另外,客戶端也可通過其他途徑獲得視頻文件的元信息。因此S101及S102為可
選步驟。 S103,客戶端發(fā)送要求分發(fā)第一視頻片段的請求,該請求攜帶有第一視頻片段標 識信息及當前可用網(wǎng)絡帶寬參數(shù); 客戶端根據(jù)視頻文件的元信息和當前可用網(wǎng)絡帶寬參數(shù)構(gòu)造對該視頻中某一片 段內(nèi)容的請求報文,并發(fā)送給服務器。 S104,服務器根據(jù)接收到的請求報文中的網(wǎng)絡帶寬參數(shù)調(diào)整第一視頻片段的視頻 數(shù)據(jù)量,并將調(diào)整后的第一視頻片段發(fā)送給所述客戶端; 在不影響視頻信號正常播放的前提下,拋棄其中不重要的數(shù)據(jù),使從服務器向客
6戶端發(fā)送的整體數(shù)據(jù)量滿足網(wǎng)絡帶寬條件。
通常,視頻片段內(nèi)容包括
該視頻文件的文件頭標志數(shù)據(jù); 該視頻文件中視頻部分解碼時必需的解碼參數(shù)數(shù)據(jù);
該視頻文件中音頻部分解碼時必需的解碼參數(shù)數(shù)據(jù); 該視頻文件中從請求的視頻片段的起始位置到終止位置之間的音頻內(nèi)容數(shù)據(jù);
該視頻文件中從請求的視頻片段的起始位置到終止位置之間的視頻數(shù)據(jù),且數(shù)據(jù) 量大小與客戶端請求的帶寬參數(shù)相匹配。 具體地,如圖2a所示, 一視頻文件包含有三視頻片段,每個片段有若干視頻數(shù)據(jù) 幀,如I幀、B幀和P幀以及相應的音頻數(shù)據(jù)。 在視頻編碼中,I幀編碼的基本流程為進行幀內(nèi)預測,決定所采用的幀內(nèi)預測模 式;像素值減去預測值,得到殘差;對殘差進行變換和量化;變長編碼和算術編碼;重構(gòu)圖 像并濾波,得到的圖像作為其它幀的參考幀。 P幀只參考前面的幀,B幀可參考前面或后面的幀,P幀和B幀編碼的基本流程為
首先,進行運動估計,計算采用幀間編碼模式的率失真函數(shù)(節(jié))值,進行幀內(nèi)預 測,選取率失真函數(shù)值最小的幀內(nèi)模式與幀間模式比較,確定采用哪種編碼模式,計算實際 值和預測值的差值,對殘差進行變換和量化,熵編碼,如果是幀間編碼模式,編碼運動矢量。
由此可知,I幀是關鍵幀,屬于幀內(nèi)壓縮,P幀是向前搜索,B幀是雙向搜索,二者均 基于I幀來壓縮數(shù)據(jù)。I幀作為參考幀,采用幀內(nèi)預測,P幀以前面的I幀或P幀作為參考 幀,B幀以前面的I幀或P幀和后面的P幀作為參考幀。 若視頻片段的視頻數(shù)據(jù)量大于所述網(wǎng)絡帶寬乘以所述視頻片斷正常播放所需的 時間得到的數(shù)據(jù)量,則服務器刪減所述視頻片段中的視頻數(shù)據(jù)量,以適應網(wǎng)絡帶寬。因此, 將視頻數(shù)據(jù)B幀刪除,得到新的第一視頻片段并發(fā)送給客戶端。
S105,客戶端檢測當前的視頻傳輸網(wǎng)絡帶寬;
網(wǎng)絡帶寬的檢測計算方法具體為 客戶端在接收第一視頻片段期間的某個時間段單位時間內(nèi)接收到的數(shù)據(jù)量。將已 經(jīng)接收到的當前視頻片段的數(shù)據(jù)量除以接收這些數(shù)據(jù)所用時間,即得到當前的視頻傳輸網(wǎng) 絡帶寬。 S106,客戶端發(fā)送要求分發(fā)第二視頻片段的請求給服務器,該請求攜帶有所述第 二視頻片段標識信息及檢測計算得到的網(wǎng)絡帶寬參數(shù); 在下述情況下客戶端發(fā)送要求分發(fā)第二視頻片段的請求給服務器
客戶端接收完第一視頻片段內(nèi)容;或 客戶端已接收完第一視頻片段內(nèi)容,并且離第一視頻片段的播放完畢時間小于預 定的閾值;或 客戶端停止播放(比如,因意外或用戶主動更換其他節(jié)目)第一視頻片段,并請求 另一視頻片段。 S107,服務器根據(jù)所檢測得到的網(wǎng)絡帶寬參數(shù)調(diào)整第二視頻片段的視頻數(shù)據(jù)內(nèi) 容,使其與所檢測得到的網(wǎng)絡帶寬參數(shù)相匹配; 與步驟S104類似,基于所檢測得到的網(wǎng)絡帶寬對第二視頻片段的視頻數(shù)據(jù)內(nèi)容進行調(diào)整,使其與網(wǎng)絡帶寬參數(shù)匹配。 所述調(diào)整后的視頻片段的視頻數(shù)據(jù)量按照下述步驟確定 根據(jù)所述網(wǎng)絡帶寬參數(shù)和視頻片段的正常播放所需的時間長度計算相乘得到所 述視頻片段的數(shù)據(jù)量值; 若第二視頻片段的視頻數(shù)據(jù)量大于所述網(wǎng)絡帶寬乘以所述視頻片斷正常播放所 需的時間得到的數(shù)據(jù)量,則服務器刪減所述視頻片段中的視頻數(shù)據(jù)量,以適應網(wǎng)絡帶寬。因 此,將視頻數(shù)據(jù)B幀(即V5幀)刪除,得到如圖2b所示的視頻片段作為新的第二視頻片段。
S108,發(fā)送調(diào)整后的第二視頻片段給所述客戶端。
將刪除視頻數(shù)據(jù)幀V5后的第二視頻片段給所述客戶端。 如圖3所示,本發(fā)明實施例提供的一種視頻數(shù)據(jù)傳送系統(tǒng)200,包括視頻服務器 210和至少一個客戶端220。 客戶端220,用于發(fā)送請求分發(fā)視頻片段的消息給所述視頻服務器,并提供所請求 的視頻片段標識信息和網(wǎng)絡帶寬信息給視頻服務器; 視頻服務器210,根據(jù)所述網(wǎng)絡帶寬信息調(diào)整視頻片段的視頻數(shù)據(jù)量,使其與所檢
測得到的網(wǎng)絡帶寬參數(shù)相匹配;并發(fā)送調(diào)整后的視頻片段給客戶端220。 其中,網(wǎng)絡帶寬信息為當前可用的網(wǎng)絡帶寬,或在所述視頻片段傳輸期間檢測得
到的網(wǎng)絡帶寬參數(shù)。 當視頻片段的視頻數(shù)據(jù)量大于所述網(wǎng)絡帶寬乘以正常播放所需的時間得到的數(shù)
據(jù)量,則視頻服務器刪減該視頻片段中的視頻數(shù)據(jù)量,以適應網(wǎng)絡帶寬。 在下述情況之一,客戶端將要求發(fā)送另一視頻片段的請求發(fā)送給視頻服務器 客戶端接收完當前視頻片段內(nèi)容;或 客戶端已接收完當前視頻片段數(shù)據(jù),并且離當前視頻片段的播放完畢時間小于預 定的閾值;或 客戶端停止播放當前視頻片段,并請求另一視頻片段。 本發(fā)明實施例提供的視頻數(shù)據(jù)傳送系統(tǒng)中,服務器與客戶端之間的交互過程如前 述方法流程,在此不再贅述。 參照圖4,本發(fā)明實施例還提供一種視頻服務器300,包括 接收單元310,用于接收來自客戶端的要求發(fā)送視頻片段的請求,該請求攜帶有所 述視頻片段標識信息及當前可用網(wǎng)絡帶寬參數(shù); 調(diào)整單元320,根據(jù)所述可用網(wǎng)絡帶寬調(diào)整所述視頻片段的視頻數(shù)據(jù)量,使其與所 述網(wǎng)絡帶寬相匹配; 發(fā)送單元330,用于將調(diào)整后的視頻片段發(fā)送給所述客戶端。
該視頻服務器300,還包括 判斷單元340,用于判斷待發(fā)送視頻片段的視頻數(shù)據(jù)量是否大于所述網(wǎng)絡帶寬乘 以該視頻片段正常播放所需的時間得到的數(shù)據(jù)量; 若判斷單元340判定待發(fā)送視頻片段的視頻數(shù)據(jù)量大于所述網(wǎng)絡帶寬乘以該視 頻片段正常播放所需的時間得到的數(shù)據(jù)量,則指示調(diào)整單元320刪減該待發(fā)送視頻片段中 的視頻數(shù)據(jù)量,以適應網(wǎng)絡帶寬。 與現(xiàn)有技術中的視頻數(shù)據(jù)分發(fā)技術方案相比,本發(fā)明提供的視頻數(shù)據(jù)傳送技術方
8案,在不同網(wǎng)絡帶寬條件下,能夠根據(jù)用戶的不同帶寬自動選擇傳送最合適的數(shù)據(jù)量的內(nèi) 容,保證視頻的流暢、高質(zhì)量播放;傳統(tǒng)的流媒體系統(tǒng)為了提供自適應碼率分發(fā)功能,通過 存儲多份視頻副本的來實現(xiàn)。應用本發(fā)明所公開的方法和系統(tǒng),只需存儲單份的視頻內(nèi)容, 節(jié)省了存儲空間和成本。本發(fā)明提供的視頻數(shù)據(jù)分發(fā)方法和系統(tǒng),在視頻數(shù)據(jù)發(fā)送過程中, 不是一次性傳輸整份視頻內(nèi)容,而是根據(jù)客戶端請求每次傳輸視頻內(nèi)容的一個片斷,并基 于當前可用網(wǎng)絡帶寬進行傳送,充分利用了網(wǎng)絡帶寬資源?,F(xiàn)有技術的視頻數(shù)據(jù)分發(fā)流程 中,從流媒體服務器到終端用戶客戶端的各個中間環(huán)節(jié)中使用了很多緩存技術,例如內(nèi)容 分發(fā)網(wǎng)絡CDN緩存,視頻文件是數(shù)據(jù)密集型,而視頻數(shù)據(jù)量大,不利于緩存系統(tǒng)處理。本發(fā) 明提供的視頻數(shù)據(jù)分發(fā)方法和系統(tǒng),以視頻片斷為單位進行傳送,視頻片斷的數(shù)據(jù)量比整 個視頻文件小很多,更有利于緩存系統(tǒng)處理,提高緩存效率?,F(xiàn)有技術中的視頻分發(fā)方法和 系統(tǒng)采取了將單個視頻文件顯式地分割成多個視頻片斷文件的做法,每次分發(fā)單個視頻片 斷文件,這給視頻文件的管理增加了很大麻煩。根據(jù)本發(fā)明可最大限度保證視頻的流暢播 放;本發(fā)明提供的技術方案中存儲和管理的對象仍然是完整的視頻文件,而且在分發(fā)過程 中,每次傳送視頻文件中的部分內(nèi)容,避免了將一個視頻文件分割成多個視頻片斷文件,因 而簡化了存儲管理。 根據(jù)所述公開的實施例,可以使得本領域技術人員能夠?qū)崿F(xiàn)或者使用本發(fā)明。對 于本領域技術人員來說,這些實施例的各種修改是顯而易見的,并且這里定義的總體原理 也可以在不脫離本發(fā)明的范圍和主旨的基礎上應用于其他實施例。以上所述的實施例僅為 本發(fā)明的較佳實施例而已,并不用以限制本發(fā)明,凡在本發(fā)明的精神和原則之內(nèi),所作的任 何修改、等同替換、改進等,均應包含在本發(fā)明的保護范圍之內(nèi)。
權(quán)利要求
一種視頻數(shù)據(jù)傳送方法,其特征在于,包括接收來自客戶端的要求發(fā)送第一視頻片段的請求,該請求攜帶有所述第一視頻片段標識信息及當前可用網(wǎng)絡帶寬參數(shù);根據(jù)所述可用網(wǎng)絡帶寬調(diào)整所述第一視頻片段的視頻數(shù)據(jù)量,并將調(diào)整后的第一視頻片段發(fā)送給所述客戶端;接收來自客戶端的要求發(fā)送第二視頻片段的請求,該請求攜帶有所述第二視頻片段標識信息及檢測到的網(wǎng)絡帶寬參數(shù);調(diào)整所述第二視頻片段的視頻數(shù)據(jù)內(nèi)容,使其與所檢測得到的網(wǎng)絡帶寬參數(shù)相匹配;發(fā)送調(diào)整后的第二視頻片段給所述客戶端。
2. 如權(quán)利要求1所述的視頻數(shù)據(jù)傳送方法,其特征在于, 所述調(diào)整視頻片段的視頻數(shù)據(jù)內(nèi)容具體為當所述視頻片段的數(shù)據(jù)量大于所述網(wǎng)絡帶寬乘以所述視頻片斷正常播放所需的時間 得到的數(shù)據(jù)量,刪減所述視頻片段中的視頻數(shù)據(jù)量,以適應網(wǎng)絡帶寬。
3. 如權(quán)利要求1所述的視頻數(shù)據(jù)傳送方法,其特征在于, 所檢測到的網(wǎng)絡帶寬參數(shù)是在所述第一視頻片段傳輸期間檢測獲取的。
4. 如權(quán)利要求1所述的視頻數(shù)據(jù)傳送方法,其特征在于,所述客戶端要求發(fā)送第二視 頻片段的請求是在下述情況之一發(fā)送的客戶端播放完第一視頻片段內(nèi)容;或客戶端已接收完第一視頻片段內(nèi)容,并且離第一視頻片段的播放完畢時間小于預定的 閾值;或客戶端停止播放第一視頻片段,并請求另一視頻片段。
5. 如權(quán)利要求1所述的視頻數(shù)據(jù)傳送方法,其特征在于,接收來自客戶端要求發(fā)送第 一視頻片段的請求之前,還包括預先將待發(fā)送視頻文件劃分為若干視頻片段;將所述待發(fā)送視頻文件的元信息發(fā)送給客戶端,該元信息包含所述待發(fā)送視頻文件包 含的視頻片段數(shù)量及各視頻片段標識信息。
6. 如權(quán)利要求1所述的視頻數(shù)據(jù)傳送方法,其特征在于, 所述調(diào)整后的視頻片段的視頻數(shù)據(jù)量按照下述步驟確定根據(jù)所述網(wǎng)絡帶寬參數(shù)和視頻片段的正常播放所需時間相乘計得到所述視頻片段的 數(shù)據(jù)量值。
7. 如權(quán)利要求1至6中任一項所述的視頻數(shù)據(jù)傳送方法,其特征在于, 所述視頻片段包括N個編碼時設置的畫面組單元,N為自然數(shù)。
8. —種視頻數(shù)據(jù)傳送系統(tǒng),包括視頻服務器和客戶端,其特征在于, 所述客戶端,用于發(fā)送請求分發(fā)視頻片段的消息給所述視頻服務器,并提供所請求的視頻片段標識信息和網(wǎng)絡帶寬信息給視頻服務器;所述視頻服務器,根據(jù)所述網(wǎng)絡帶寬信息調(diào)整所述視頻片段的視頻數(shù)據(jù)量,使其與所 檢測得到的網(wǎng)絡帶寬參數(shù)相匹配;并發(fā)送調(diào)整后的視頻片段給所述客戶端。
9. 如權(quán)利要求8所述的視頻數(shù)據(jù)傳送系統(tǒng),其特征在于,所述網(wǎng)絡帶寬信息為當前可用的網(wǎng)絡帶寬,或在所述視頻片段傳輸期間檢測得到的網(wǎng)絡帶寬參數(shù)。
10. 如權(quán)利要求8所述的視頻數(shù)據(jù)傳送系統(tǒng),其特征在于,所述視頻片段的視頻數(shù)據(jù)量大于所述網(wǎng)絡帶寬乘以所述視頻片斷正常播放所需的時 間得到的數(shù)據(jù)量,則所述視頻服務器刪減所述視頻片段中的視頻數(shù)據(jù)量,以適應網(wǎng)絡帶寬。
11. 如權(quán)利要求8所述的視頻數(shù)據(jù)傳送系統(tǒng),其特征在于,在下述情況之一所述客戶端將要求發(fā)送另一視頻片段的請求發(fā)送給所述視頻服務器客戶端接收完當前視頻片段內(nèi)容;或客戶端已接收完當前視頻片段內(nèi)容,并且離當前視頻片段的播放完畢時間小于預定的 閾值;或客戶端停止播放當前視頻片段,并請求另一視頻片段。
12. —種視頻服務器,其特征在于,包括接收單元,用于接收來自客戶端的要求發(fā)送視頻片段的請求,該請求攜帶有所述視頻 片段標識信息及當前可用網(wǎng)絡帶寬參數(shù);調(diào)整單元,根據(jù)所述可用網(wǎng)絡帶寬調(diào)整所述視頻片段的視頻數(shù)據(jù)量,使其與所述網(wǎng)絡 帶寬相匹配;發(fā)送單元,用于將調(diào)整后的視頻片段發(fā)送給所述客戶端。
13. 如權(quán)利要求12所述的視頻服務器,其特征在于,還包括判斷單元,用于判斷所述視頻片段的視頻數(shù)據(jù)量是否大于所述網(wǎng)絡帶寬乘以所述視頻 片斷正常播放所需的時間得到的數(shù)據(jù)量;若所述判斷單元判定所述視頻片段的視頻數(shù)據(jù)量大于所述網(wǎng)絡帶寬乘以所述視頻片 斷正常播放所需的時間得到的數(shù)據(jù)量,則指示調(diào)整單元刪減所述視頻片段中的視頻數(shù)據(jù) 量,以適應網(wǎng)絡帶寬。
全文摘要
本發(fā)明公開了一種視頻數(shù)據(jù)傳送方法,包括接收客戶端的要求發(fā)送視頻片段的請求,該請求攜帶網(wǎng)絡帶寬參數(shù);根據(jù)網(wǎng)絡帶寬調(diào)整視頻片段的視頻數(shù)據(jù)量,使其與所檢測得到的網(wǎng)絡帶寬參數(shù)相匹配;并將調(diào)整后的視頻片段發(fā)送給客戶端。本發(fā)明還提供了一種視頻數(shù)據(jù)傳送系統(tǒng),包括客戶端,發(fā)送分發(fā)視頻片段的請求并提供網(wǎng)絡帶寬信息給視頻服務器;視頻服務器,根據(jù)網(wǎng)絡帶寬信息調(diào)整視頻片段的視頻數(shù)據(jù)量,使其與網(wǎng)絡帶寬參數(shù)相匹配,并發(fā)送調(diào)整后的視頻片段給客戶端。根據(jù)本發(fā)明可自適應網(wǎng)絡帶寬進行視頻數(shù)據(jù)發(fā)送,最大限度保證視頻的流暢播放;而且在分發(fā)過程中,每次傳送視頻文件中的部分內(nèi)容,簡化了文件管理。
文檔編號H04N7/24GK101795264SQ20091024440
公開日2010年8月4日 申請日期2009年12月30日 優(yōu)先權(quán)日2009年12月30日
發(fā)明者章動, 鄭清芳, 鮑東山 申請人:北京新岸線網(wǎng)絡技術有限公司