專利名稱：組播頻道快速啟動系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種流^^某體技術(shù)，具體說，涉及一種組播頻道快速啟動的系 纟充和方法。
背景技術(shù)：
在一個現(xiàn)有流4某體頻道系統(tǒng)中，頭端、流服務(wù)器和播放器是最基本的組成部分，通常采用TCP/IP協(xié)議轉(zhuǎn)輸碼流和信令，播放器和流服務(wù)器之間采 用RTSP協(xié)議交換信令，在UDP或TCP協(xié)議之上承載RTP或TS等格式的 載荷，傳輸々某體數(shù)據(jù)。 一般來說，UDP較TCP更為常用。組播是UDP的一種，由于歷史和現(xiàn)有不少網(wǎng)絡(luò)都不能很好地支持組播， 當(dāng)網(wǎng)絡(luò)不能支持組播協(xié)議時，只能由流服務(wù)器接收頭端發(fā)出的碼流，然后通 過TCP協(xié)議或點(diǎn)對點(diǎn)的UDP協(xié)議，分發(fā)給各個播放器，我們把碼流分發(fā)給 其中一個播放器的過程稱為單播。在一個IPTV頻道系統(tǒng)中，單播是流服務(wù) 器最為基本的功能之一。組播是TCP/IP協(xié)議中，從一個單點(diǎn)向多點(diǎn)發(fā)送相同的數(shù)據(jù)協(xié)議，發(fā)送 者只需要向組播IP地址發(fā)送一份組播UDP包，然后由網(wǎng)絡(luò)上的路由器把數(shù) 據(jù)分發(fā)復(fù)制到感興趣的接收者，不管接收者的數(shù)量，發(fā)送者的工作負(fù)荷是常 數(shù)，同時，組播協(xié)議的設(shè)計，可以把網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)量減到最小。這一特 性，使得組播非常適合于頻道數(shù)據(jù)的傳輸。如果網(wǎng)絡(luò)支持組播協(xié)議，播放器則可以通過加入組播組，直接接收頭端 發(fā)出的組播碼流，從而大大減輕流服務(wù)器的工作負(fù)荷和降低網(wǎng)絡(luò)流量。由于 通過組播傳輸碼流，中間無須流服務(wù)器參與，這樣減少了一個故障點(diǎn)，也提 高了系統(tǒng)的可靠性。如圖1所示，組播頻道子系統(tǒng)是流媒體頻道系統(tǒng)的一個子系統(tǒng)， 一般來 說，邏輯上沒有流服務(wù)器的參與，僅僅由一個頭端和數(shù)量不等的播放器組成， 由于頭端沒有信令交互能力，頭端只能按照媒體編碼方法的要求，按照固有 的方式發(fā)送碼流。例如按照一定的時間間隔，定期發(fā)送視頻媒體的I幀數(shù)據(jù) 等。頭端發(fā)送媒體碼流時，數(shù)據(jù)發(fā)送的方向是單向的，由頭端發(fā)送到播放器?？蛻舳耸怯捎脩舨倏v的，可能在任意一個時刻點(diǎn)，加入組播接收碼流， 因此接收到的碼流的起始點(diǎn)是隨機(jī)的。而相當(dāng)多的編碼方法，尤其是視頻編碼方法，必須接收到一幀完整的關(guān) 鍵幀(例如，視頻編碼的I幀)，其解碼結(jié)杲才是完整正確的。收到關(guān)鍵幀 之前接收的碼流不能完全正確解碼，要么是只能丟棄，要么強(qiáng)行解碼，但解 碼后的數(shù)據(jù)是有誤的，對于視頻來說，會有馬賽克或停頓等異常現(xiàn)象出現(xiàn)， 同樣影響用戶體驗(yàn)。從開始接收數(shù)據(jù)，到接收到關(guān)鍵幀的碼流，需要一段時間，這段時刻稱 為關(guān)鍵幀等待時間。關(guān)鍵幀等待時間取決時關(guān)鍵幀的發(fā)送頻率，平均值為關(guān)鍵幀的發(fā)送間隔的1/2。同時，為了防止傳輸?shù)亩秳樱蛻舳艘话愣荚O(shè)置了緩沖區(qū)，需要首先把 接收到的碼流保存到緩沖區(qū)中，當(dāng)緩沖區(qū)填充到一定大小時，才把媒體數(shù)據(jù) 從緩沖區(qū)取出解碼播放。這段緩沖區(qū)的填充，也需要一段時間，這段時間稱 為緩沖填充時間。同時，從播放器加入組播組，到收到組播包，也需要一段時間，這段時 間稱為加入組播時間，加入組播時間取決網(wǎng)絡(luò)結(jié)構(gòu)。在某些網(wǎng)絡(luò)結(jié)構(gòu)或環(huán)境 下，這個時間可能非常長。在一個碼率大于iMbps的IPTV頻道系統(tǒng)中，關(guān)鍵幀的發(fā)送間隔往往設(shè) 為2秒左右，同時緩沖填充時間也為2秒左右。也就是說，從用戶開始點(diǎn)播 一個頻，到正常觀看節(jié)目，不計加入組播時間，平均需要3秒左右的等待時 間。而人在觀看電視時，切換頻道時能容忍的等待時間往往在1秒以內(nèi)，因 此有必要采用某些技術(shù)方案，提高播放啟動速度，提高用戶體驗(yàn)。絕大部分播放器，都設(shè)置了最大等待時間，如果在規(guī)定的時間內(nèi)，收到 不到組播包，則認(rèn)為播放失敗，中止播放。如果出現(xiàn)某些特殊情況，加入組 播時間大于最大等待時間，還可能造成播放失敗。在申請?zhí)枮镃N200410069507的專利申請中，提及了一些提高組播頻道 切換速度的技術(shù)方案。該方法的核心是當(dāng)用戶終端離開當(dāng)前所在的組播頻道 時，根據(jù)所述用戶終端接入的位置信息判斷該組播頻道下的該位置信息是否 還存在其他接入的用戶終端，并根據(jù)判斷結(jié)果對相應(yīng)組播頻道的組播復(fù)制表 進(jìn)行維護(hù)。其目的是解決播放器從一個組播頻道，切換到另一個頻道時，切 換時間長的問題，它工作的層次在網(wǎng)絡(luò)設(shè)備，并沒有解決前面所述的問題。發(fā)明內(nèi)容本發(fā)明所解決的技術(shù)問題是提供一種組播頻道快速啟動系統(tǒng)，提高了 播;改啟動速度，實(shí)現(xiàn)了快速啟動組播頻道的播放。才支術(shù)方案如下組播頻道快速啟動系統(tǒng)包括頭端和至少一個播放器，其中，頭端，產(chǎn)生或者中轉(zhuǎn)頻道的媒體數(shù)據(jù)并發(fā)送；播放器，設(shè)置有緩沖區(qū)，用于播放所述媒體數(shù)據(jù)；流服務(wù)器，設(shè)置有歷史緩沖區(qū)，所述歷史緩存區(qū)保存有歷史碼流；接收 所述頭端發(fā)出的碼流，保存在所述歷史緩沖區(qū)，當(dāng)所述流服務(wù)器收到所述播 放器的組播請求后，所述流服務(wù)器將歷史緩沖區(qū)的歷史碼流，以單播方式填 充到所述播放器的緩沖區(qū)，當(dāng)所述播放器加入組播組后，所述流服務(wù)器停止 發(fā)送單播碼流；所述播放器加入組播組后接收組播碼流，并將所述組播碼流和單播碼流 進(jìn)行拼接。優(yōu)選的，所述流服務(wù)器以TCP方式發(fā)送碼流。優(yōu)選的，當(dāng)所述歷史緩沖區(qū)耗盡時，所述流服務(wù)器向播放器發(fā)送快發(fā)結(jié) 束通知。優(yōu)選的，所述播放器把單播通道和組播通道接收到的RTP填充到緩沖 區(qū)，填充前過濾已經(jīng)收到的重復(fù)的RTP包。
優(yōu)選的，當(dāng)所述播放器加入組播組后，接收組播碼流。優(yōu)選的，所述流服務(wù)器從歷史緩沖區(qū)的歷史碼流的關(guān)鍵幀開始，以單播 方式將歷史碼流填充到所述播放器的緩沖區(qū)。技術(shù)效果如下本發(fā)明解決了關(guān)鍵幀等待時間、緩沖區(qū)時間和加入組播時間三者的累積 導(dǎo)致的播放啟動速度慢的問題，有效地提高了播放的啟動速度，實(shí)現(xiàn)了快速 啟動組播頻道的播放，提高了用戶的體驗(yàn)。同時，本發(fā)明也可以有效地防止 意外出現(xiàn)的，如由于加入組播時間過長，造成的播放失敗的錯誤。在快發(fā)單播階段，采用的是TCP協(xié)議，可以防止網(wǎng)絡(luò)流量過大，通信 鏈路擁塞造成的丟包；快發(fā)結(jié)束后，邊收邊發(fā)，繼續(xù)以正常速度發(fā)送單播碼 流，直到播放器收到組播包，防止兩段碼流出現(xiàn)空檔拼接不上；快發(fā)結(jié)束后， 才讓播放器加入組播，防止在快發(fā)階段，組播碼流的加入，進(jìn)一步加激通信 鏈路擁塞。收到流服務(wù)器發(fā)出的快發(fā)結(jié)束標(biāo)記播放器就加入組播分組，盡量縮短流 服務(wù)器單播的時間，即盡量減輕流服務(wù)器的工作負(fù)荷；收到組播包后，盡快 通知流服務(wù)器停止繼續(xù)單播，把單播和組播兩份碼流在通信鏈路上重疊傳輸 的時間減到最小。流服務(wù)器可以從歷史碼流中，選擇從關(guān)鍵幀開始發(fā)送，播 放器接收到碼流，就可以解碼播放，關(guān)鍵幀等待時間被縮減到0。播放器在通知流服務(wù)器停止單播時，附帶媒體包的標(biāo)記性信息，流服務(wù) 器可以判斷到該媒體包之間，是否所有的媒體包已經(jīng)發(fā)送，如果沒有，則繼 續(xù)發(fā)送，直至通知中指定的媒體包為止，保證單播和組播碼流可以無縫地拼 接在一起。不管播放器加入組播時間的長短，都不影響播放器正常播放組播 頻道，加入組播時間對播放啟動速度的影響被縮減為0。本發(fā)明還可以解決偶然出現(xiàn)的，播放器加入組播時間很長，超過播放器 的最大等待時間而導(dǎo)致的播放失敗異常。


圖l是現(xiàn)有技術(shù)中組播頻道系統(tǒng)結(jié)構(gòu)圖;
圖2是本發(fā)明所采用的組播頻道系統(tǒng)結(jié)構(gòu)圖； 圖3是本發(fā)明方法的基本流程圖。
具體實(shí)施方式
下面結(jié)合附圖，對本發(fā)明的優(yōu)選實(shí)施例作詳細(xì)描述。如圖2所示， 一個組播頻道系統(tǒng)由頭端、流服務(wù)器和數(shù)量不等的播放器 組成。頭端和流服務(wù)器在邏輯是兩個實(shí)體，既可以是兩個不同的物理上實(shí)體， 也可以同一個物理的實(shí)現(xiàn)。流服務(wù)器實(shí)時不停地從頭端接收碼流，并保存到 自己的歷史緩沖區(qū)中。頭端負(fù)責(zé)產(chǎn)生或中轉(zhuǎn)頻道的媒體數(shù)據(jù)，發(fā)送到不同客戶的設(shè)備，與播放 器之間沒有信令交互。播放器設(shè)置有緩沖區(qū)，由最終用戶操縱的，接收并播放媒體數(shù)據(jù)的設(shè)備。 對于IPTV,則更多稱為機(jī)頂盒(STB)。流服務(wù)器是通過信令交互，為不同用戶或播放器提供個性化的流^!某體服 務(wù)的實(shí)體。本發(fā)明中，流服務(wù)器設(shè)置有歷史緩沖區(qū)，通過信令交互，為不同 用戶或播放器提供個性化的流媒體服務(wù)。歷史緩存區(qū)保存有歷史碼流，當(dāng)流 服務(wù)器收到播放器的組播請求后，流服務(wù)器從歷史緩沖區(qū)的歷史碼流的關(guān)鍵 幀開始，以單播方式將歷史碼流填充到播放器的緩沖區(qū)。當(dāng)播放器加入組播 組后，流服務(wù)器停止發(fā)送單播碼流。處理過程如下第一步用戶操作操縱播放器選擇播放某個組播頻道。 第二步播放器向流服務(wù)器發(fā)送播放組播頻道的請求。第三步流服務(wù)器進(jìn)行歷史碼流快發(fā)。流服務(wù)器從緩沖區(qū)中的歷史碼流中，選取一部分或全部碼流，以快發(fā)方 式，向點(diǎn)播該頻道的播放器發(fā)送單播碼流，快發(fā)的碼流是從歷史某一時刻點(diǎn) 開始，到最近接收到的連續(xù)碼流。流4某體系統(tǒng)中，每一小段時間內(nèi)，頭端或流服務(wù)器發(fā)送的碼流，都應(yīng)該
滿足這段時間內(nèi)，播放器播放媒體的需求。如果一'卜段時間內(nèi)，發(fā)送速率與 需要不相匹配， 一般稱為速率攔動。如杲一段較長時間內(nèi)，發(fā)送速率連續(xù)超 出4番方文的需要，則稱之為快發(fā)。在這一步中，流服務(wù)器可以選擇性采用其它方法進(jìn)一步優(yōu)化效果，包括采用TCP方式發(fā)送碼流，而不是流媒體應(yīng)用中常用的UDP傳輸協(xié)議。 采用盡力而為的方式，以期采用所能達(dá)到的最快的速率發(fā)送歷史碼流，以通 信鏈路允許的最大速率，在最短的時間內(nèi)，完成播放器緩沖區(qū)的填充工作， 把緩沖區(qū)填充時間壓縮到最短。檢索歷史碼流，從關(guān)鍵幀開始處開始發(fā)送。第四步流服務(wù)器向播放器發(fā)送快發(fā)結(jié)束通知。因?yàn)榭彀l(fā)的發(fā)送速率大于頭端的正常發(fā)送速率，也即是流服務(wù)器從頭端 接收到碼流，填充歷史碼流緩沖區(qū)的速率，歷史緩沖區(qū)最終會被耗盡。當(dāng)歷史緩沖區(qū)耗盡時，流服務(wù)器向播放器發(fā)送快發(fā)結(jié)束通知。在這一步，可能有多種不同的簡單變換方法，包括在歷史緩沖區(qū)耗盡前一小段時間或后一段較長時間內(nèi)發(fā)送快發(fā)結(jié)束通 知；或者，流服務(wù)器在此之前的信令交互中，通知播放器自己將要快發(fā)的數(shù) 量，由播放器根據(jù)接收的數(shù)據(jù)量，自行計算出快發(fā)結(jié)束的點(diǎn)；或者，播放器 根據(jù)接收的速率計算快發(fā)結(jié)束的點(diǎn)。第五步播放器在快發(fā)結(jié)束點(diǎn)前后加入組播組；第六步流服務(wù)器以正常速率發(fā)送單播碼流快發(fā)結(jié)束后，流服務(wù)器一邊從頭端接收碼流， 一邊發(fā)送給播放器。如果以下的步驟執(zhí)行很快，這一步有可能被跳過。第七步當(dāng)播放器收到組播包之后，通知流服務(wù)器停止發(fā)送單播碼流。在這一步中，播放器可以更進(jìn)一步，在通知中，附帶從組播接收媒體包 的標(biāo)記信息，例如，該標(biāo)記信息可以是RTP包號或時間戳等。第八步流服務(wù)器收到停止通知后，停止發(fā)送單播碼流。如果通知中附帶了媒體包的標(biāo)記性信息，流服務(wù)器還可以更進(jìn)一步，釆 用判斷比較RTP包序號或時間戳大小等辦法，判斷到該媒體包之間，是否
所有的媒體包已經(jīng)發(fā)送，如果沒有，則繼續(xù)發(fā)送，直至通知中指定的媒體包 為止。流服務(wù)器需要收到播放器已經(jīng)接收到組播碼流，才能停止單播的發(fā)送， 因此，不管播放器加入組播時間的長短，都不影響播放器正常播放組播頻道，加入組播時間對播放啟動速度的影響^a縮減為0。第九步播放器把從流服務(wù)器和組播接收到碼流進(jìn)行拼接，拼接成一份 單一的碼流進(jìn)行播放。如圖3所示，在一個IPTV系統(tǒng)，通過本發(fā)明方法，能夠提高播放器點(diǎn) 播頻道時的啟動速度。這個IPTV系統(tǒng)包括三個基本實(shí)體頭端、流服務(wù)器和播放器(又稱機(jī) 頂盒)。頭端和流服務(wù)器通過千兆以太網(wǎng)連接入網(wǎng)絡(luò)，機(jī)頂盒通過4Mbps ADSL接入網(wǎng)絡(luò)，整個網(wǎng)絡(luò)采用的是TCP/IP協(xié)議。媒體是音視頻數(shù)據(jù)，其中音頻采用AAC方式編碼，AAC編碼無須關(guān)鍵 幀，解碼器一收到媒體包即可解碼；視頻采用MPEG4編碼，采用MPEG4 的解碼器要收到一個完整的I幀，才能完整完成后續(xù)的媒體數(shù)據(jù)解碼工作， 關(guān)鍵幀為I幀。碼流的傳輸協(xié)議是RTP，機(jī)頂盒與流服務(wù)器之間信息交互協(xié) 議是是RTSP。頭端輸出的正常速率碼率是1.5Mbps，平均每隔2秒發(fā)送一個I幀。機(jī) 頂盒在緩沖區(qū)填充2秒^/某體數(shù)據(jù)后，開始解碼播放。機(jī)頂盒從加入組播，到 收到第l個組播包，平均時間是0.5秒。在現(xiàn)在方法下，機(jī)頂盒點(diǎn)播一個組播頻道，理論上平均必須3.5秒時間 才能啟動播放，最小必須2.5秒才能啟動播放。而采用本發(fā)明方法，理論上 只需要1.5 x 2 + 4 = 0.75秒的緩沖區(qū)填充時間，即可完成緩沖區(qū)填充工作， 啟動播放。在本實(shí)施例中，實(shí)測結(jié)果絕大部分點(diǎn)播的啟動時間都小于1.0秒。機(jī)頂盒在一次點(diǎn)播組播頻道的流程如下1、 機(jī)頂盒向流服務(wù)器發(fā)送RTSPDESCRIBE請求；2、 流服務(wù)器響應(yīng)RTSP 200成功響應(yīng)；3 、機(jī)頂盒發(fā)送視頻軌道的RTSP SETUP請求；4 、流月l務(wù)器響應(yīng)RTSP 200成功響應(yīng)；5 、機(jī)頂盒發(fā)送音頻軌道的RTSP SETUP請求；6、 流服務(wù)器響應(yīng)RTSP 200成功響應(yīng)；7、 機(jī)頂盒發(fā)送音頻軌道的RTSP PLAY請求；8、 流服務(wù)器響應(yīng)RTSP 200成功響應(yīng)；9、 流服務(wù)器通過TCP通道，發(fā)送快發(fā)單播流碼；10、 歷史碼流耗盡后，流服務(wù)器通過RTSP SET—PARAMETER Speed Up: End信令，通知機(jī)頂盒快發(fā)結(jié)束；11、 機(jī)頂盒收到RTSP SET—PARAMETER Speed Up: End信令后，響 應(yīng)RTSP 200成功響應(yīng)，并加入組播組；12、 流服務(wù)器邊收邊發(fā)，繼續(xù)通過TCP通道，以正常速率，向機(jī)頂盒 發(fā)送單播碼流；13 、機(jī)頂盒收到組播包后，發(fā)送RTSP PAUSE請求，并在請求中，附 帶了收到第1個組播包對應(yīng)的TrackID和RTP包的RTP序號；14、 流服務(wù)器根據(jù)Track ID和RTP包序號，判斷和該包之間，是否有 其它RTP包尚未收到和發(fā)送，是則立刻中止發(fā)送，否則繼續(xù)發(fā)送到該包為 止；15、 流服務(wù)器中止發(fā)包后，響應(yīng)RTSP 200成功響應(yīng)；16、 機(jī)頂盒繼續(xù)接收組播包；17、 機(jī)頂盒把從單播通道和組播通道接收到的RTP填充到緩沖區(qū)，填 充前過濾已經(jīng)收到的重復(fù)的RTP包；18、 當(dāng)緩沖區(qū)填充到足夠大小后，從緩沖區(qū)取出RTP包送往解碼器解 碼播放。
權(quán)利要求
1. 一種組播頻道快速啟動系統(tǒng)，包括頭端和至少一個播放器，其中，頭端，產(chǎn)生或者中轉(zhuǎn)頻道的媒體數(shù)據(jù)并發(fā)送；播放器，設(shè)置有緩沖區(qū)，用于播放所述媒體數(shù)據(jù)；其特征在于，還包括流服務(wù)器，設(shè)置有歷史緩沖區(qū)，所述歷史緩存區(qū)保存有歷史碼流；接收所述頭端發(fā)出的碼流，保存在所述歷史緩沖區(qū)，當(dāng)所述流服務(wù)器收到所述播放器的組播請求后，所述流服務(wù)器將歷史緩沖區(qū)的歷史碼流，以單播方式填充到所述播放器的緩沖區(qū)，當(dāng)所述播放器加入組播組后，所述流服務(wù)器停止發(fā)送單播碼流；所述播放器加入組播組后接收組播碼流，并將所述組播碼流和單播碼流進(jìn)行拼接。
2、 根據(jù)權(quán)利要求1所述的組播頻道快速啟動系統(tǒng)，其特征在于，所述 流服務(wù)器以TCP方式發(fā)送碼流。
3、 根據(jù)權(quán)利要求1所述的組播頻道快速啟動系統(tǒng)，其特征在于，當(dāng)所 述歷史緩沖區(qū)耗盡之后，所述流服務(wù)器向播放器發(fā)送快發(fā)結(jié)束通知。
4、 根據(jù)權(quán)利要求1所述的組播頻道快速啟動系統(tǒng)，其特征在于，所述 播放器把單播通道和組播通道接收到的RTP填充到緩沖區(qū)，填充前過濾已 經(jīng)收到的重復(fù)的RTP包。
5、 根據(jù)權(quán)利要求1所述的組播頻道快速啟動系統(tǒng)，其特征在于，當(dāng)所 述播放器加入組播組后，接收組播碼流。
6、 根據(jù)權(quán)利要求1所述的組播頻道快速啟動系統(tǒng)，其特征在于，所述 流服務(wù)器從歷史緩沖區(qū)的歷史碼流的關(guān)鍵幀開始，以單播方式將歷史碼流填 充到所迷播放器的緩沖區(qū)。
全文摘要
本發(fā)明公開了一種組播頻道快速啟動系統(tǒng)，包括流服務(wù)器、頭端和至少一個播放器，其中，頭端產(chǎn)生或者中轉(zhuǎn)頻道的媒體數(shù)據(jù)并發(fā)送；播放器設(shè)置有緩沖區(qū)，用于播放所述媒體數(shù)據(jù)；流服務(wù)器，設(shè)置有歷史緩沖區(qū)，所述歷史緩存區(qū)保存有歷史碼流；接收所述頭端發(fā)出的碼流，保存在所述歷史緩沖區(qū)，當(dāng)所述流服務(wù)器收到所述播放器的組播請求后，所述流服務(wù)器將歷史緩沖區(qū)的歷史碼流，以單播方式填充到所述播放器的緩沖區(qū)，當(dāng)所述播放器加入組播組后，所述流服務(wù)器停止發(fā)送單播碼流；所述播放器加入組播組后接收組播碼流，并將所述組播碼流和單播碼流進(jìn)行拼接。本發(fā)明有效地提高了播放啟動速度，實(shí)現(xiàn)了快速啟動組播頻道的播放，提高了用戶的體驗(yàn)。
文檔編號H04L12/56GK101212406SQ20061017032
公開日2008年7月2日 申請日期2006年12月28日 優(yōu)先權(quán)日2006年12月28日
發(fā)明者陳重奮 申請人:中興通訊股份有限公司