專利名稱：一種基于brew的Http遞進(jìn)式視頻播放器的實(shí)現(xiàn)方法
技術(shù)領(lǐng)域：
本發(fā)明涉及電子設(shè)備領(lǐng)域，尤其涉及一種基于brew的Http遞進(jìn)式視頻播放器的實(shí)現(xiàn)方法。
背景技術(shù)：
手機(jī)在線視頻業(yè)務(wù)為3G典型增值應(yīng)用。傳統(tǒng)的基于RTSP協(xié)議的流媒體雖然已經(jīng)有多年的發(fā)展，并占據(jù)主流位置，但應(yīng)用于移動(dòng)流媒體業(yè)務(wù)時(shí)，表現(xiàn)出了較大的劣勢(shì)。主要問題體現(xiàn)在感官體驗(yàn)差，在復(fù)雜的無線環(huán)境中經(jīng)常出現(xiàn)停頓與馬賽克現(xiàn)象。持續(xù)的馬賽克很快會(huì)令用戶失去耐心，對(duì)流媒體業(yè)務(wù)的增長非常不利。所以一些移動(dòng)運(yùn)營商和手機(jī)制造商開始使用互聯(lián)網(wǎng)上普遍采用的HTTP漸進(jìn)下載協(xié)議來實(shí)現(xiàn)手機(jī)的流媒體播放功能。目前brew平臺(tái)下已有的Http漸進(jìn)式播放器，如高通QTV內(nèi)置的遞進(jìn)式播放的方式的支持，還有《在BREW平臺(tái)上同步播放音頻視頻的方法及系統(tǒng)》(專利申請(qǐng)?zhí)?CN200410009566.7)，都存在一些共有的缺陷，制約著漸進(jìn)式播放器的推廣。這些缺陷包括有(1)對(duì)于MOOV信息在文件末尾的文件，只能等到整個(gè)文件都下載完全后才能播放，而邊下載邊播放是Http遞進(jìn)式下載播放方式的最重要的特征，如果要整個(gè)文件下完才能播放， 就毫無意義了。OWeek操作只局限于已下載的數(shù)據(jù)，無法定位到任意位置，或者要等待 kek位置之前的所有數(shù)據(jù)都下載后才能播放，用戶有時(shí)候可能要等待幾乎下載整個(gè)文件的時(shí)間，才能播到的位置，這樣的用戶體驗(yàn)就很差了。(3)采用線性的緩沖區(qū)，即應(yīng)用和QTV共享一段預(yù)申請(qǐng)的內(nèi)存，播放文件的大小如果比這段預(yù)申請(qǐng)的內(nèi)存大，超出部分的數(shù)據(jù)無法處理。所以要么每次根據(jù)視頻文件的大小來申請(qǐng)相應(yīng)大小內(nèi)存去播放，但手機(jī)的內(nèi)存播放文件的大小如果比這段預(yù)申請(qǐng)的內(nèi)存大，超出部分的數(shù)據(jù)無法處理。所以要么每次根據(jù)視頻文件的大小來申請(qǐng)相應(yīng)大小內(nèi)存去播放，但手機(jī)的內(nèi)存大小通常情況下是很有限的，對(duì)大一點(diǎn)的文件就沒辦法處理了 ；要么每次播到超出共享內(nèi)存大小的緩沖數(shù)據(jù)時(shí)，要重建新的會(huì)話新的共享內(nèi)存來播放超出部分的數(shù)據(jù)，這樣的方法的缺點(diǎn)除了新舊會(huì)話切換帶來的停頓外，用戶還無法seek到不屬于當(dāng)前會(huì)話的緩沖數(shù)據(jù)的播放位置上，即使是已經(jīng)播放過的內(nèi)容。

發(fā)明內(nèi)容
為了克服Brew上現(xiàn)有的Http漸進(jìn)下載播放器的不足，本發(fā)明提供了一種新的 http遞進(jìn)式下載播放器的實(shí)現(xiàn)方法，對(duì)網(wǎng)絡(luò)媒體文件的多個(gè)不連續(xù)的緩沖數(shù)據(jù)段的進(jìn)行存儲(chǔ)管理，不需要使用線性的共享內(nèi)存來處理緩沖數(shù)據(jù)；對(duì)網(wǎng)絡(luò)視頻文件的下載采用http range來指定每次的下載范圍，并根據(jù)播放的要求動(dòng)態(tài)調(diào)整下載位置，可以快速響應(yīng)用戶對(duì)任意位置的播放請(qǐng)求；在開始播放緩沖數(shù)據(jù)前，對(duì)文件尾數(shù)據(jù)進(jìn)行預(yù)先下載，這種機(jī)制結(jié)合前面的緩沖區(qū)管理策略和下載位置動(dòng)態(tài)調(diào)整技術(shù)，避免了 MOOV信息在文件末尾的視頻文件要整個(gè)文件下載完畢才能播放的限制。本發(fā)明的發(fā)明目的是通過如下技術(shù)方案實(shí)現(xiàn)的
一種基于brew的Http遞進(jìn)式視頻播放器的實(shí)現(xiàn)方法，所述的使用PULL方式來處理緩沖數(shù)據(jù)，通過IMedia接口向底層QTV注冊(cè)獲取數(shù)據(jù)大小和獲取數(shù)據(jù)的兩個(gè)回調(diào)函數(shù)， 讓QTV使用這兩個(gè)回調(diào)函數(shù)取得數(shù)據(jù)。QTV決定什么時(shí)候去取數(shù)據(jù)和取多少，但不關(guān)心緩沖數(shù)據(jù)怎么存儲(chǔ)的，這樣就可以把網(wǎng)絡(luò)媒體文件下載到臨時(shí)文件中，而不需要申請(qǐng)一段巨大的內(nèi)存區(qū)去播放一個(gè)大文件。所有的臨時(shí)文件用一個(gè)隊(duì)列管理著，當(dāng)需要引入一個(gè)新的臨時(shí)文件時(shí)，需要在隊(duì)列中插入一個(gè)新的節(jié)點(diǎn)。相應(yīng)的，對(duì)網(wǎng)絡(luò)媒體文件的下載也并不總是從頭到尾的連續(xù)下載數(shù)據(jù)的，而是使用Http Range技術(shù)，根據(jù)需要請(qǐng)求文件任意部分的數(shù)據(jù)。 這樣就可以支持對(duì)多個(gè)不連續(xù)的緩沖數(shù)據(jù)段的下載和存儲(chǔ)管理。所述的在從文件起始位置開始順序下載了由預(yù)置值ml指定大小的數(shù)據(jù)后(通常還會(huì)預(yù)下載了文件尾部的少量數(shù)據(jù))，開始播放數(shù)據(jù)。在播放過程中，監(jiān)控QTV獲取播放數(shù)據(jù)的位置的更新情況，當(dāng)發(fā)現(xiàn)從播放數(shù)據(jù)位置開始的剩余緩沖數(shù)據(jù)量小于預(yù)置值m2時(shí)，播放進(jìn)入緩沖暫停狀態(tài)，等待下載數(shù)據(jù)的更新使得剩余緩沖數(shù)據(jù)量上升到另一個(gè)預(yù)定值m3 后，恢復(fù)播放。所述的當(dāng)發(fā)現(xiàn)QTV請(qǐng)求的數(shù)據(jù)已經(jīng)位于未下載區(qū)域時(shí)，播放進(jìn)入緩沖暫停狀態(tài)； 接著計(jì)算這個(gè)數(shù)據(jù)位置距離在它之前的最近的一個(gè)緩沖數(shù)據(jù)段的最短距離，如果這個(gè)距離小于某個(gè)默認(rèn)值m4時(shí)，只需把下載位置定位到該數(shù)據(jù)段末尾下載；否則，會(huì)在新的位置創(chuàng)建新的臨時(shí)文件插入臨時(shí)文件隊(duì)列中，并對(duì)它進(jìn)行下載；等待下載數(shù)據(jù)緩沖到至剩余緩沖數(shù)據(jù)量大于預(yù)定值m3后，在當(dāng)前播放位置或者用戶kek操作指向的位置上恢復(fù)播放。所述的用多個(gè)臨時(shí)文件分別存儲(chǔ)網(wǎng)絡(luò)視頻文件的多個(gè)不同的數(shù)據(jù)段，以隊(duì)列形式管理所有臨時(shí)文件。所述的當(dāng)播放請(qǐng)求的數(shù)據(jù)未下載時(shí)，根據(jù)請(qǐng)求的數(shù)據(jù)與在它之前第一個(gè)已下載數(shù)據(jù)段的距離，決定是從該數(shù)據(jù)段末尾繼續(xù)下載還是在新的位置上新建一個(gè)臨時(shí)文件來下載。本發(fā)明有以下有益效果1、因?yàn)樾碌木彌_數(shù)據(jù)的管理方案不需要與QTV共享內(nèi)存，克服了因手機(jī)內(nèi)存有限而不能播放大文件的限制；預(yù)下載文件尾和支持對(duì)網(wǎng)絡(luò)媒體文件任意位置的下載和緩沖的機(jī)制，克服了對(duì)MOOV信息在文件末尾的視頻文件只能等到整個(gè)文件下載完才能播放的限制。這兩種限制的解決極大提高了 Http漸進(jìn)下載播放器的適用范圍。2、對(duì)用戶的％4請(qǐng)求，可以靈活的根據(jù)當(dāng)前已下載的緩沖數(shù)據(jù)的情況，重新定位下載位置，在新的位置緩沖數(shù)據(jù)，所以不但可以支持對(duì)任意位置的kek操作，而且當(dāng)kek 請(qǐng)求的位置遠(yuǎn)離已下載數(shù)據(jù)時(shí)，通過下載位置的調(diào)整縮短數(shù)據(jù)緩沖的時(shí)間，用戶體驗(yàn)有很大的改善。


圖1是本發(fā)明緩沖數(shù)據(jù)組織結(jié)構(gòu)示意圖；圖2是本發(fā)明kek請(qǐng)求后的分段數(shù)據(jù)示意圖；圖3是本發(fā)明系統(tǒng)實(shí)現(xiàn)的步驟示意圖。
具體實(shí)施方式
下面結(jié)合附圖對(duì)本發(fā)明做進(jìn)一步說明如附圖1中，每一個(gè)Chunk結(jié)構(gòu)對(duì)應(yīng)一個(gè)臨時(shí)文件，代表著一個(gè)連續(xù)數(shù)據(jù)段，它記錄著臨時(shí)文件路徑，臨時(shí)文件起始位置的數(shù)據(jù)對(duì)應(yīng)網(wǎng)絡(luò)文件中的位置，臨時(shí)文件大小； Chunk隊(duì)列把所有的臨時(shí)文件組織在一起，代表了緩沖區(qū)的所有數(shù)據(jù)。Chunk之上還有 Group結(jié)構(gòu)，一個(gè)Group由一個(gè)或者多個(gè)Chunk組成。Group描述的也是一個(gè)連續(xù)數(shù)據(jù)段， 但是Group所代表的數(shù)據(jù)段可以跨越多個(gè)臨時(shí)文件，即多個(gè)Chunk ；當(dāng)相鄰的兩個(gè)Chunk的兩段數(shù)據(jù)因?yàn)橄螺d數(shù)據(jù)的不斷更新，而最后連成一片時(shí)，這兩個(gè)Chunk所在的Group就可以合并成一個(gè)新的Group，包含的Chunk為原來兩個(gè)Group所包含的Chunk的合集。Group隊(duì)列中Group的個(gè)數(shù)代表著緩沖區(qū)里有多少個(gè)不連續(xù)的數(shù)據(jù)段。當(dāng)文件全部下載完畢時(shí)，整個(gè)緩沖就區(qū)只有一個(gè)連續(xù)的數(shù)據(jù)段，此時(shí)Group隊(duì)列中的Group數(shù)也就只有一個(gè)了。如附圖2所示，1是指向已下載區(qū)域；2是指向未下載區(qū)域；3是播放位置；4是下載位置，由于用戶的^ek請(qǐng)求指向未下載的數(shù)據(jù)，所以下載位置進(jìn)行了調(diào)整，在seek所在數(shù)據(jù)之前不遠(yuǎn)處開始下載，從而形成了 1所指向的三段不連續(xù)的數(shù)據(jù)段。此時(shí)Group隊(duì)列中會(huì)有三個(gè)Group存在。如附圖3所示，描述了 http遞進(jìn)式下載播放的實(shí)現(xiàn)。得到視頻資源的地址后，首先下載文件起始位置開始的一段數(shù)據(jù)，這段數(shù)據(jù)量大小是預(yù)先配置的，但是不能太小，以避免開始播放后，會(huì)因?yàn)榫彌_數(shù)據(jù)量不足而很快要進(jìn)入暫停等待緩沖數(shù)據(jù)的情形，影響用戶體驗(yàn)。完成文件頭的下載后，已經(jīng)可以獲得視頻文件的大小，接著就對(duì)預(yù)定大小的文件尾部進(jìn)行下載。文件尾數(shù)據(jù)下載完畢后，把下載點(diǎn)調(diào)整到文件起始位置未下載的地方繼續(xù)下載剩余數(shù)據(jù)，同時(shí)開始播放緩沖數(shù)據(jù)。播放中，會(huì)監(jiān)控QTV請(qǐng)求數(shù)據(jù)位置更新情況，當(dāng)發(fā)現(xiàn)剩余緩沖數(shù)據(jù)量不足時(shí)，暫停播放，等待下載數(shù)據(jù)更新使得剩余緩沖數(shù)據(jù)量達(dá)到恢復(fù)播放的要求后，恢復(fù)播放。播放停止有兩種情況，一種是正常停止，如用戶請(qǐng)求終止播放或者播放完畢，另一種是播放失敗。當(dāng)發(fā)現(xiàn)播放失敗時(shí)，要進(jìn)一步分析是不是因?yàn)镼TV請(qǐng)求的數(shù)據(jù)未下載導(dǎo)致， 如果是，則要通過計(jì)算結(jié)果采用合理的方式去下載尚未下載的數(shù)據(jù)(即決定是否調(diào)整下載位置)，然后在剩余緩沖數(shù)據(jù)量滿足條件時(shí)恢復(fù)播放?；謴?fù)播放時(shí)，需要設(shè)置恢復(fù)播放的時(shí)間點(diǎn)，如果播放失敗是因?yàn)橛脩舻膋ek請(qǐng)求導(dǎo)致的，則設(shè)置播放時(shí)間點(diǎn)為％4所請(qǐng)求的時(shí)間，否則設(shè)置為播放失敗時(shí)的已播放時(shí)間。
權(quán)利要求
1.一種基于brew的Http遞進(jìn)式視頻播放器的實(shí)現(xiàn)方法，其特征在于所述的該方法是使用PULL方式來處理緩沖數(shù)據(jù)，通過IMedia接口向底層QTV注冊(cè)獲取數(shù)據(jù)大小和獲取數(shù)據(jù)的兩個(gè)回調(diào)函數(shù)，讓QTV使用這兩個(gè)回調(diào)函數(shù)取得數(shù)據(jù)，所有的臨時(shí)文件用一個(gè)隊(duì)列管理著，當(dāng)需要引入一個(gè)新的臨時(shí)文件時(shí)，需要在隊(duì)列中插入一個(gè)新的節(jié)點(diǎn)，根據(jù)需要請(qǐng)求文件任意部分的數(shù)據(jù)，這樣就可以支持對(duì)多個(gè)不連續(xù)的緩沖數(shù)據(jù)段的下載和存儲(chǔ)管理。
2.根據(jù)權(quán)利要求1所述的一種基于brew的Http遞進(jìn)式視頻播放器的實(shí)現(xiàn)方，其特征在于所述的從文件起始位置開始順序下載了由預(yù)置值ml指定大小的數(shù)據(jù)后，開始播放數(shù)據(jù)，在播放過程中，監(jiān)控QTV獲取播放數(shù)據(jù)的位置的更新情況，當(dāng)發(fā)現(xiàn)從播放數(shù)據(jù)位置開始的剩余緩沖數(shù)據(jù)量小于預(yù)置值m2時(shí)，播放進(jìn)入緩沖暫停狀態(tài)，等待下載數(shù)據(jù)的更新使得剩余緩沖數(shù)據(jù)量上升到另一個(gè)預(yù)定值m3后恢復(fù)播放。
3.根據(jù)權(quán)利要求1所述的一種基于brew的Http遞進(jìn)式視頻播放器的實(shí)現(xiàn)方，其特征在于所述的當(dāng)發(fā)現(xiàn)QTV請(qǐng)求的數(shù)據(jù)已經(jīng)位于未下載區(qū)域時(shí)，播放進(jìn)入緩沖暫停狀態(tài)；接著計(jì)算這個(gè)數(shù)據(jù)位置距離在它之前的最近的一個(gè)緩沖數(shù)據(jù)段的最短距離，如果這個(gè)距離小于某個(gè)默認(rèn)值m4時(shí)，只需把下載位置定位到該數(shù)據(jù)段末尾下載；否則，會(huì)在新的位置創(chuàng)建新的臨時(shí)文件插入臨時(shí)文件隊(duì)列中，并對(duì)它進(jìn)行下載；等待下載數(shù)據(jù)緩沖到至剩余緩沖數(shù)據(jù)量大于預(yù)定值m3后，在當(dāng)前播放位置或者用戶kek操作指向的位置上恢復(fù)播放。
4.根據(jù)權(quán)利要求1所述的一種基于brew的Http遞進(jìn)式視頻播放器的實(shí)現(xiàn)方，其特征在于所述的用多個(gè)臨時(shí)文件分別存儲(chǔ)網(wǎng)絡(luò)視頻文件的多個(gè)不同的數(shù)據(jù)段，以隊(duì)列形式管理所有臨時(shí)文件。
5.根據(jù)權(quán)利要求1所述的一種基于brew的Http遞進(jìn)式視頻播放器的實(shí)現(xiàn)方，其特征在于所述的當(dāng)播放請(qǐng)求的數(shù)據(jù)未下載時(shí)，根據(jù)請(qǐng)求的數(shù)據(jù)與在它之前第一個(gè)已下載數(shù)據(jù)段的距離，決定是從該數(shù)據(jù)段末尾繼續(xù)下載還是在新的位置上新建一個(gè)臨時(shí)文件來下載。
全文摘要
本發(fā)明公開了一種基于brew的Http遞進(jìn)式視頻播放器的實(shí)現(xiàn)方法，所述的使用PULL方式來處理緩沖數(shù)據(jù)，通過IMedia接口向底層QTV注冊(cè)獲取數(shù)據(jù)大小和獲取數(shù)據(jù)的兩個(gè)回調(diào)函數(shù)，讓QTV使用這兩個(gè)回調(diào)函數(shù)取得數(shù)據(jù)。QTV決定什么時(shí)候去取數(shù)據(jù)和取多少，但不關(guān)心緩沖數(shù)據(jù)怎么存儲(chǔ)的，這樣就可以把網(wǎng)絡(luò)媒體文件下載到臨時(shí)文件中，而不需要申請(qǐng)一段巨大的內(nèi)存區(qū)去播放一個(gè)大文件。所有的臨時(shí)文件用一個(gè)隊(duì)列管理著，當(dāng)需要引入一個(gè)新的臨時(shí)文件時(shí)，需要在隊(duì)列中插入一個(gè)新的節(jié)點(diǎn)。相應(yīng)的，對(duì)網(wǎng)絡(luò)媒體文件的下載也并不總是從頭到尾的連續(xù)下載數(shù)據(jù)的，而是使用HttpRange技術(shù)，根據(jù)需要請(qǐng)求文件任意部分的數(shù)據(jù)。這樣就可以支持對(duì)多個(gè)不連續(xù)的緩沖數(shù)據(jù)段的下載和存儲(chǔ)管理。
文檔編號(hào)H04L29/08GK102420840SQ20101029403
公開日2012年4月18日 申請(qǐng)日期2010年9月27日 優(yōu)先權(quán)日2010年9月27日
發(fā)明者鄭富強(qiáng) 申請(qǐng)人:西安龍飛軟件有限公司