專利名稱::一種實現(xiàn)網(wǎng)絡電視頻道快速切換的方法及系統(tǒng)的制作方法
技術領域:
:本發(fā)明涉及網(wǎng)絡電視(IPTV)業(yè)務
技術領域:
,特別是一種實現(xiàn)網(wǎng)絡電視頻道快速切換的方法及系統(tǒng)。
背景技術:
:隨著因特網(wǎng)技術的發(fā)展,近年來迅速發(fā)展起來了IP網(wǎng)絡上的IPTV業(yè)務,該業(yè)務把傳統(tǒng)的電視業(yè)務引入到IP網(wǎng)絡中。在本發(fā)明中涉及會話發(fā)起協(xié)議(SIP)、IP多媒體子系統(tǒng)(IMS)、下一代網(wǎng)絡(NGN)、流媒體技術、IP組播、視頻中的幀和場景等技術,下面首先對這些技術作個簡單的介紹。SIP是由因特網(wǎng)工程任務組(IETF)制訂的多媒體通信系統(tǒng)框架協(xié)議之一,是用于建立、改變或結(jié)束多媒體會話的應用層協(xié)議,與實時傳輸協(xié)議(RTP)/實時傳輸控制協(xié)議(RTCP)、會話描述協(xié)議(SDP)、實時流協(xié)議(RTSP)、域名服務(DNS)等協(xié)議配合,共同完成IMS中的會話建立及媒體協(xié)商;一旦建立會話,媒體流將使用RTP協(xié)議在承載層中直接傳送,在一次會話中可以靈活的交互多種媒體。由于SIP基于公開的互聯(lián)網(wǎng)標準,在語音、數(shù)據(jù)業(yè)務結(jié)合和互通方面具有天然優(yōu)勢,能跨越媒體和設備實現(xiàn)呼叫控制,支持豐富的媒體格式,可動態(tài)增/刪^^某體流,容易實現(xiàn)更加豐富的業(yè)務特性,同時,SIP支持智能向業(yè)務和終端側(cè)的發(fā)展,從而減輕網(wǎng)絡負擔,其本身支持包括動態(tài)注冊機制、位置管理機制、重定向機制等應用層移動性功能以及呈現(xiàn)(Presence)/剪枝(Fork)/訂閱特性,便于擴展新業(yè)務,而且協(xié)議的內(nèi)容簡單,具有公認的擴展?jié)摿?,因此獲得了包括在IMS及NGN中越來越多的應用。另外,在通訊和信息技術(IT)高度發(fā)展的今天,隨著跨鏈路層傳輸介質(zhì)的IP技術的出現(xiàn),因特網(wǎng)應用的迅速普及,人們也不再滿足于單一的語音通信方式,而需要全新的多媒體通信方式,移動通訊網(wǎng)絡和固定通訊網(wǎng)絡的IP化、因特網(wǎng)和電信網(wǎng)絡的融合已無可爭議地成為業(yè)界公認的發(fā)展方向。為滿足越來越突出的IP多媒體應用的普遍需求,第三代合作伙伴計劃(3GPP)在分組承栽網(wǎng)基礎上引入的全IP業(yè)務網(wǎng)絡架構(gòu)的IMS,目標是按照個性化用戶數(shù)據(jù)、屏蔽用戶接入方式、控制業(yè)務能力的開放程度,從而提供多媒體的通信體驗。IMS是3GPPR5階段增加的WCDMA網(wǎng)絡中疊加在已有分組域之上的一個子系統(tǒng),采用分組域為其上層控制信令和媒體傳輸?shù)某休d通道,引入SIP協(xié)議作為業(yè)務控制協(xié)議,利用SIP簡單、易擴展、媒體組合方便的特點,通過將業(yè)務控制與承栽控制分離,提供豐富的多媒體業(yè)務;IMS中主要的功能實體包括控制用戶注冊、會話控制等功能的呼叫會話控制實體(CSCF)、提供各種業(yè)務邏輯控制功能的應用服務器(AS)、集中管理用戶簽約數(shù)據(jù)的歸屬用戶服務器(HSS)以及用于實現(xiàn)與電路交換網(wǎng)互通的媒體網(wǎng)關控制功能實體(MGCF)/IP多媒體-媒體網(wǎng)關(IM-MGW),用戶通過當前所在地的代理CSCF(P-CSCF)接入IMS,會話和業(yè)務觸發(fā)控制及與AS的業(yè)務控制交互則由其注冊地的歸屬域服務CSCF(S-CSCF)完成。眾所周知,NGN是基于分組技術的融合型網(wǎng)絡,以分組交換為主,采用承載與控制分離的架構(gòu),它繼承了原有公用電話交換網(wǎng)絡(PSTN)的所有業(yè)務,也同時夠繼承了移動網(wǎng)絡的業(yè)務能力。因此,NGN綜合了固定電話網(wǎng)、移動電話網(wǎng)和IP網(wǎng)絡的優(yōu)勢,使得模擬用戶、數(shù)字用戶、移動用戶、非對稱數(shù)字用戶線路(ADSL)用戶、綜合業(yè)務數(shù)字網(wǎng)(ISDN)用戶、IP窄帶網(wǎng)絡用戶、IP寬帶網(wǎng)絡用戶、甚至是通過衛(wèi)星接入的用戶都能作為NGN中的一員相互通信。如圖1所示的是電信和互聯(lián)網(wǎng)融合業(yè)務以及高級網(wǎng)絡協(xié)議(TISPAN)NGN整體架構(gòu)。流媒體業(yè)務是近幾年迅速發(fā)展的一種新業(yè)務。流媒體業(yè)務利用流式傳輸技術,在包交換網(wǎng)絡上傳輸多媒體文件,包括視頻、音頻等文件內(nèi)容。這些內(nèi)容在訪問時無需完全下載就可以立即播放。流媒體實現(xiàn)的關鍵技術就是流式傳輸技術,而流式傳輸技術是把連續(xù)的視頻和音頻信息經(jīng)過處理后放上網(wǎng)站服務器,讓用戶一邊下栽一邊觀看、收聽,而不需要等整個文件下載到本地后才可以觀看的網(wǎng)絡傳輸技術。IP組播是以D類IP地址發(fā)送業(yè)務的技術,發(fā)送者利用IP組播可以同時向多個接收者發(fā)送相同業(yè)務內(nèi)容,因為相同內(nèi)容只需要向指定組播地址發(fā)送一份即可,因而可以有效降低業(yè)務發(fā)送方和傳輸網(wǎng)絡的負栽。為了獲取組播內(nèi)容,作為內(nèi)容接收方的用戶通過使用因特網(wǎng)組管理協(xié)議(IGMP)等協(xié)議加入業(yè)務組播組,來要求鄰接的路由器發(fā)送業(yè)務內(nèi)容給自己,而路由器之間則通過組播路由協(xié)議如協(xié)議無關組播-稀疏模式(PIM-SM)等與其它路由器交互以建立組播轉(zhuǎn)發(fā)路徑,這樣組播業(yè)務內(nèi)容就可以從組播源沿組播轉(zhuǎn)發(fā)路徑傳遞給內(nèi)容接收方。使用組播技術傳送業(yè)務流,無論接收方有多少,業(yè)務發(fā)送方只需要發(fā)送一個數(shù)據(jù)流。組播數(shù)據(jù)在從業(yè)務發(fā)送點到接收方的傳送路徑上的傳送點之間只產(chǎn)生單一的數(shù)據(jù)流。由此可見,使用組播技術可以減輕發(fā)送者即業(yè)務提供方的負荷,并且可以有效利用網(wǎng)絡資源。圖2所示為視頻序列中幀和場景的關系。場景是在視頻內(nèi)容拍攝和制作的時候已經(jīng)產(chǎn)生的。如圖2所示,一個場景可以包含多個幀。圖3所示為場景、幀和視頻碼流中數(shù)據(jù)包之間的對應關系。對于一個場景,一般來說,其中存在幀內(nèi)編碼幀(I幀)、預測編碼幀(P幀)和雙向預測編碼幀(B幀)。所謂I幀是相對于P幀和B幀而言的。I幀的編碼完全由其本身決定,而不需要依賴其它幀,而P幀要依賴其前面的參考幀才能解碼,B幀則要依賴其前后的參考幀才能解碼。因此,I幀的解碼最為簡單。只要是基于離散余弦變換(DCT)以及熵編碼思想的壓縮編碼標準中,比如國際電信聯(lián)盟(ITU)H.26x系列和運動圖像專家組(MPEG)系列,I幀的解碼都只需要進行反熵編碼、去量化和反DCT變換就可以了,不需要運動補償。因此I幀解碼的計算量最少。其他類型的幀,比如P幀,如果需要從視頻碼流中解碼該P幀,則需要解碼其前面若干個P幀,一直到前面離它最近的一個I幀。但是對于I幀,則只需要解碼該I幀本身即可。兩者相比較,解碼的復雜度相差巨大。另外,也有可能在一個場景內(nèi)存在多個I幀,,例如鏡頭比較長時。一般來說,媒體內(nèi)容在節(jié)目制作編碼過程中,場景之間的變化很大,一個場景至少產(chǎn)生一個I幀。在編碼器中,雖然標準一般沒有強制規(guī)定何時加入I幀,但是一般來說,在場景發(fā)生變化時,都會加入I幀,場景的第一幀往往就是I幀。當然上述說法,對于H.264這類新的標準可能不完全適用,因為在H.264中,可能沒有完整的I幀,而只是一個幀的某個部分進行幀內(nèi)編碼,例如一個條帶(Slice)可以獨立地進行幀內(nèi)編碼。對于可能不存在完整I幀的情況,可以通過定義一些修正的選取準則比如選取存在幀內(nèi)編碼條帶或者宏塊(MB)最多的幀。對于一般的編碼協(xié)議,都有標識機制來標識I幀或者幀內(nèi)編碼的條帶等。比如在ITU的H.264標準中,是通過瞬時解碼刷新(IDR)標志來標識的。因此從視頻流/視頻文件中正確提取I幀或者幀內(nèi)編碼的條帶/宏塊等是技術可行的。為了表述方便,我們下面都統(tǒng)一稱為I幀,其包含對于H.264等的特殊定義和處理。由于使用IP技術提供類似傳統(tǒng)電視類的業(yè)務,IPTV技術為用戶提供了相當?shù)撵`活性,并極大地改善了用戶的體驗。但也正是因為使用了IP技術,相應地帶來了一系列的問題需要解決,比如IPTV頻道快速切換就是開展IPTV業(yè)務需要迫切解決的一個問題,否則若基于IP技術的頻道切換速度太慢,如切換時間大于2秒或1秒,則用戶體驗變差,無法有效吸引用戶,也就是說,在這種情況下,IPTV無法達到實際應用的要求。在傳統(tǒng)電視技術中,所有頻道內(nèi)容一般是按頻分的方式同時發(fā)送到用戶側(cè)的,如目前常用的有線電視(CableTV);這時候終端如果需要切換頻道,只需要調(diào)諧到相應頻道的播放頻率/頻帶上就可以了;而對于IPTV而言,考慮帶寬的限制,一般頻道內(nèi)容是按需發(fā)送到終端的,即一次性發(fā)送一個或者幾個頻道內(nèi)容給用戶,而不是同時發(fā)送所有頻道的內(nèi)容給用戶;這時候要進行頻道切換一般涉及到終端和網(wǎng)絡的信令交互過程,正是因為機制有所不同,因而會在各個環(huán)節(jié)引入頻道切換延遲從而影響終端用戶的最終體驗;目前有多種方案可以解決切換延遲的問題。現(xiàn)有技術一對于IPTV實時電視(LiveTV)業(yè)務而言,目前基于xDSL的一種^^術方案如圖4所示。參照圖4,該技術方案使用IP組播技術向終端傳送媒體流,用戶使用IGMP/組播偵聽者發(fā)現(xiàn)協(xié)議(MLD)從接入節(jié)點請求加入頻道的組播地址來接收該頻道節(jié)目,在傳輸/核心網(wǎng)使用組播路由技術建立組播轉(zhuǎn)發(fā)路徑,媒體服務器發(fā)出的組播數(shù)據(jù)包經(jīng)傳輸/核心網(wǎng)到達接入網(wǎng)并最終發(fā)送給用戶終端。為了對用戶進行有效控制,在DSL接入節(jié)點上,如數(shù)字用戶環(huán)路接入復用器(DSLAM)或者寬帶遠程接入服務器(BRAS)進行用戶頻道權(quán)限的控制;這里用戶的頻道切換請求最終體現(xiàn)為終端使用IGMP/MLD協(xié)議加入或者離開播放頻道的組播組,一般通過檢查配置到DSLAM或者BRAS上的權(quán)限列表來判斷是否允許用戶的此次頻道切換操作。使用此方案進行業(yè)務提供時,頻道切換延遲一般由如下因素引起l)DSLAM、BRAS等接入點處理IGMP/MLD的延遲;2)媒體流從媒體服務器傳送到接入節(jié)點的延遲;3)終端解碼媒體流以及顯示的延遲等。另外,此方案中,為了降低頻道切換延遲,目前一般會考慮提前把多個頻道的內(nèi)容發(fā)送到接入網(wǎng)邊緣,在用戶請求頻道內(nèi)容時直接從接入節(jié)點發(fā)送內(nèi)容給用戶終端,從而節(jié)省媒體流從媒體服務器傳送到接入節(jié)點的延遲時間;當沒有用戶收看內(nèi)容時,接入節(jié)點對收到的內(nèi)容作丟棄處理?,F(xiàn)有技術一的方案從媒體傳輸延遲方面著手,可以一定程度上降低頻道切換延遲,但對其它導致切換延遲的問題沒有考慮,如用戶發(fā)送IGMP/MLD信令以及接入網(wǎng)處理此信令的延遲等。現(xiàn)有技術二現(xiàn)有技術二主要利用分層視頻編碼(layeredvideocoding)技術。分層視頻編碼是一種把視頻數(shù)據(jù)流進行分層壓縮編碼的方法,主要思想是輸出多個編碼層,最主要的部分是基本層(baselayer),基本層之上有多個增強層(enhancementlayer),基本層和增強層可以分開發(fā)送,走不同的網(wǎng)絡路徑。在接收端,基本層可以獨立解碼重構(gòu)出基本層視頻,但是增強層必須依賴于基本層和/或者其下面的增強層,才能解碼重構(gòu)出各自對應的視頻。在^t秦收端,解碼重構(gòu)出來的基本層和各個增強層視頻碼流按照由具體分層編碼方法規(guī)定的規(guī)則進行疊加,從而得到總的視頻碼流?,F(xiàn)有技術二的方案使用上述技術對視頻流編碼,并且對基本層編碼^:用小分辨率編碼,則其數(shù)據(jù)碼率相對較小,其在網(wǎng)絡中的傳輸延遲也較小。終端對該基本層編碼的解碼速度相對較快,因此從網(wǎng)絡傳輸時間和編解碼方面該技術對切換延遲都有一定程度的改善。但是,現(xiàn)有技術二具有如下缺點1)由于采用基本層和增強層編碼,其編碼復雜性和設備實現(xiàn)復雜性將較高,解碼增強層則增加了延遲時間;2)現(xiàn)有技術二與現(xiàn)有技術一配合雖然可以降低傳輸/核心網(wǎng)的傳輸延遲,但對于接入網(wǎng)處理IGMP所引起的延遲部分依然沒有太多改善?,F(xiàn)有技術三由于NGN網(wǎng)絡的成熟,目前還有考慮遵循NGN網(wǎng)絡的業(yè)務控制與承栽層分離思路開展IPTV業(yè)務的方法,此類方案需要通過業(yè)務信令進行IPTV頻道的請求,在頻道切換時終端也需要使用信令與業(yè)務實體或者媒體服務器交互;在收到用戶請求后,業(yè)務實體或者媒體服務器對用戶進行驗證、狀態(tài)記錄、計費等;另外,在業(yè)務實體或者媒體服務器給用戶的響應中可以返回頻道的組播地址、業(yè)務保護信息等;收到這些信息后,終端可以根據(jù)所給出的組播地址發(fā)出IGMP/MLD等用于向網(wǎng)絡請求頻道媒體流,其中返回的業(yè)務保護信息可以用于終端順利解碼內(nèi)容。根據(jù)此種思路基于IMS網(wǎng)絡進行IPTV業(yè)務建立的方案可以參考本申請人的申請?zhí)枮?006100034107.3另一篇專利。在現(xiàn)有技術三中,由于引入了信令交互,因此引入了信令交互所導致的延遲,雖然可以采用與現(xiàn)有技術一和現(xiàn)有技術二類似的技術對頻道切換延遲加以解決,但對于信令交互所導致的延遲,現(xiàn)有技術一和現(xiàn)有技術二則無能為力。綜上所述,對于現(xiàn)有技術一中以傳統(tǒng)IP組播技術配合接入側(cè)權(quán)限控制的技術而言,該技術未考慮接入網(wǎng)部分處理組播加入請求的時間優(yōu)化。而現(xiàn)有技術二中基于分層編碼技術的基層媒體流配合接入側(cè)權(quán)限控制的方案,一方面設備及終端的實現(xiàn)將比較復雜,另外,該類技術同樣沒有充分考慮接入網(wǎng)部分處理組播加入請求的時間優(yōu)化。另外,對于現(xiàn)有技術三中使用獨立業(yè)務層信令進行業(yè)務協(xié)商的技術,其相應地引入了信令層面的延遲,也需要進一步考慮優(yōu)化,以降低頻道切換的時間延遲。
發(fā)明內(nèi)容有鑒于此,本發(fā)明提出了一種實現(xiàn)網(wǎng)絡電視頻道快速切換的方法,用以降低在頻道切換時的時間延遲。本發(fā)明的另一個目的在于,提出一種實現(xiàn)網(wǎng)絡電視頻道快速切換的系統(tǒng)。根據(jù)上述目的,本發(fā)明提供了一種實現(xiàn)網(wǎng)絡電視頻道快速切換的方法,該方法包括以下步驟A.媒體服務器向終端發(fā)送目標頻道的頻道切換媒體流以及目標頻道的媒體流;B.終端在目標頻道的媒體流能夠播放之前,播放目標頻道的頻道切換媒體流。步驟A之前進一步包括終端獲取目標頻道信息以及頻道切換媒體流信息,在媒體服務器與終端之間建立用于傳輸正常媒體流的第一媒體通道和用于傳輸所述頻道切換媒體流的第二媒體通道。所述終端獲取目標頻道信息以及頻道切換媒體流信息的步驟為終端通過帶外機制獲取所述信息。在上述技術方案中,所述頻道切換媒體流信息包括頻道切換媒體流封裝方式、頻道切換媒體流發(fā)送方式以及頻道切換服務支持信息。頻道切換媒體流封裝方式為TS封裝,頻道切換媒體流發(fā)送方式為IP單播,頻道切換服務支持信息為頻道切換媒體流單播地址和端口;或者,頻道切換媒體流封裝方式為TS封裝,頻道切換媒體流發(fā)送方式為IP組播,頻道切換服務支持信息為頻道切換媒體流組播地址和端口。所述終端獲取目標頻道信息以及頻道切換媒體流信息的步驟包括終端通過中間處理模塊向應用處理模塊發(fā)送首次頻道請求,應用處理模塊向々某體服務器請求目標頻道信息和頻道切換媒體流信息;媒體服務器向應用處理模塊返回目標頻道信息和頻道切換媒體流信息,應用處理模塊將其發(fā)送給終端。該方法預先在應用處理模塊上配置所述目標頻道信息和頻道切換^!某體流信息;所述終端獲取目標頻道信息以及頻道切換媒體流信息的步驟包^^舌終端通過中間處理模塊向應用處理模塊發(fā)送首次頻道請求,應用處理模塊向終端返回所配置的目標頻道信息和頻道切換媒體流信息。在上述技術方案中,所述頻道切換媒體流信息包括頻道切換媒體流封裝方式、頻道切換媒體流發(fā)送方式以及頻道切換服務支持信息。頻道切換媒體流封裝方式為傳輸流TS封裝,頻道切換媒體流發(fā)送方式為IP單播,頻道切換服務支持信息為頻道切換媒體流單播地址和端口;或者,頻道切換媒體流封裝方式為TS封裝,頻道切換媒體流發(fā)送方式為IP組播,頻道切換服務支持信息為頻道切換媒體流組播地址和端口;或者,頻道切換媒體流封裝方式為因特網(wǎng)流媒體聯(lián)盟ISMA封裝,頻道切換媒體流發(fā)送方式為IP單播,頻道切換服務支持信息為頻道切換媒體流單播地址和端口。可選地,媒體服務器在未收到終端請求的情況下或者在收到終端請求之后,以組播方式發(fā)送所述頻道切換媒體流。步驟A中媒體服務器進一步向終端發(fā)送復合為一個媒體流的多個頻道的頻道切換媒體流。步驟A之前進一步包括生成頻道切換媒體流的步驟。所述生成頻道切換媒體流的步驟包括提取對應頻道媒體流中部分或全部的幀內(nèi)編碼幀,組成頻道切換媒體流;或者,提取對應頻道媒體流中部分或全部的幀內(nèi)編碼幀,對所提取的幀內(nèi)編碼幀進行尺寸壓縮后,組成頻道切換媒體流;或者,將對應頻道分層編碼的基本層媒體流作為頻道切換媒體流;或者,對采用分層編碼的頻道媒體流,提取對應頻道基本層媒體流中部分或全部的幀內(nèi)編碼幀,并作為頻道切換媒體流;或者,對采用分層編碼的頻道媒體流,提取對應頻道基本層媒體流中部分或全部的幀內(nèi)編碼幀,對所提取的幀內(nèi)編碼幀進行尺寸壓縮后,并作為頻道切換媒體流。所述生成頻道切換媒體流的步驟是指根據(jù)對應頻道的媒體流實時生成頻道切換媒體流;或者,針對對應頻道的流媒體文件預先生成用于頻道切換媒體流的流媒體文件。本發(fā)明還提供了一種實現(xiàn)網(wǎng)絡電視頻道快速切換的系統(tǒng),該系統(tǒng)包括終端,用于發(fā)起頻道切換請求,以及在目標頻道的媒體流能夠播放之前播放目標頻道的頻道切換媒體流;媒體服務器,用于向終端發(fā)送所述頻道切換媒體流以及目標頻道的^某體流。所述終端進一步用于根據(jù)帶外方式獲取目標頻道信息以及頻道切換媒體流信息,并在媒體服務器與終端之間建立用于傳輸正常媒體流的第一媒體通道和用于傳輸所述頻道切換媒體流的第二媒體通道。該系統(tǒng)進一步包括中間處理模塊和應用處理模塊,其中,中間處理模塊用于在終端與應用處理模塊以及在應用處理模塊與媒體服務器之間轉(zhuǎn)發(fā)消息;應用處理模塊用于根據(jù)終端的首次頻道請求向媒體服務器請求目標頻道信息和頻道切換媒體流信息,以及將媒體服務器返回的目標頻道信息和頻道切換媒體流信息發(fā)送給終端;所述終端進一步根據(jù)目標頻道信息以及頻道切換媒體流信息,在媒體服務器與終端之間建立用于傳輸正常媒體流的第一媒體通道和用于傳輸所述頻道切換媒體流的第二媒體通道。所述終端和中間處理模塊之間的接口采用SIP、HTTP或RTSP;和/或,所述應用處理模塊和中間處理模塊之間的接口采用SIP、HTTP或RTSP;和/或,所述中間處理模塊和媒體服務器之間的接口采用SIP、Diameter或H.248。所述中間處理模塊包括P-CSCF、I-CSCF、S-CSCF;所述應用處理才莫塊為應用服務器AS;所述媒體服務器為媒體資源功能實體MRF;所述MRF包括媒體資源控制功能實體MRCF和媒體資源處理功能實體MRFP,其中MRCF用于接收AS的請求并控制MRFP進行媒體資源的分配,MRFP則受MRFC的控制向終端提供媒體資源。所述媒體服務器進一步用于根據(jù)對應頻道的媒體流生成頻道切換媒體流。所述媒體服務器包括提供目標頻道媒體流的第一媒體服務器,以及提供頻道切換媒體流的第二媒體服務器。本專利給出的方案,通過在媒體服務器提供獨立的頻道切換媒體流,該頻道切換媒體流可以在終端請求正常頻道媒體流的同時發(fā)送到終端,該頻道切換媒體流可以包含一個頻道的頻道切換媒體流或者多個頻道的頻道切換媒體流,這樣當終端需要切換頻道時,無須進行額外的信令請求,接入網(wǎng)組播加入請求等動作,可以直接從已收到的頻道切換媒體流中解碼目標頻道的頻道切換媒體流預先播放,實現(xiàn)頻道的快速切換,本發(fā)明避免了接入節(jié)點進行信令處理,媒體流從媒體服務器到接入節(jié)點的延遲,以及終端和網(wǎng)絡之間可能的應用信令交互的延遲,大大縮短了頻道切換的時間。圖1為TISPANNGN的網(wǎng)絡架構(gòu)示意圖;圖2為視頻序列中幀和場景的關系示意圖;圖3為場景、幀和視頻碼流中數(shù)據(jù)包之間的對應關系示意圖;圖4為現(xiàn)有技術一中基于xDSL的IPTV方案的示意圖;圖5為本發(fā)明實施例中快速頻道切換的示意圖6為本發(fā)明一種實施方式的通信網(wǎng)絡邏輯結(jié)構(gòu)示意圖;圖7為本發(fā)明實施例中方法的流程示意圖;圖8為本發(fā)明另一種實施方式的通信網(wǎng)絡邏輯結(jié)構(gòu)示意圖;圖9為本發(fā)明實施例中采用IMS核心(IMScore)作為中間處理模塊時的網(wǎng)絡結(jié)構(gòu)示意圖;圖IO為本發(fā)明實施例中另一種方法的流程示意圖。具體實施方式為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚,以下舉實施例對本發(fā)明進一步詳細說明。終端在進行頻道切換時需要經(jīng)過網(wǎng)絡驗證,該過程使用的信令延遲會造成目標頻道媒體流的延遲到達;另外高分辨率圖像在網(wǎng)絡中的傳輸需要一定的時間,也會造成切換延遲。因此,本發(fā)明考慮在進行頻道切換時通過優(yōu)先發(fā)送對應于頻道當前內(nèi)容的頻道切換媒體流,例如低分率/或準動態(tài)的視頻流,由終端在收到頻道內(nèi)容前使用低分辨率或準動態(tài)視頻填補這一延遲時間,使得用戶最終可以看到連續(xù)的切換過程,縮短頻道切換的時間,獲得較佳體驗。這一過程如圖5所示,參照圖5,媒體服務器同時向終端提供當前節(jié)目正常的媒體流以及支持快速頻道切換的頻道切換媒體流,該頻道切換媒體流可以只包含目標頻道的頻道切換媒體流,也可以包括多個頻道的頻道切換媒體流的復合媒體流,例如所有頻道的復合媒體流。本發(fā)明的基本思想是在用戶進行初始頻道請求時即建立一個與傳輸正常媒體流的第一媒體傳輸通道相獨立的第二媒體傳輸通道,該傳輸通道在用也可以在用戶收看某頻道的同時傳輸所有頻道的低分辨率或準動態(tài)媒體流給用戶;當用戶進行頻道切換時,終端可以根據(jù)該頻道低分辨率或準動態(tài)媒體流快速解碼目標頻道的視頻內(nèi)容顯示在終端上;雖然此視頻信息是低分辨率或者準動態(tài)的,但考慮人的視覺殘留效果,使用其填補切換時的"空白,,或者"灰屏"時間是完全可以接受的;與此同時,終端可以在后臺繼續(xù)進行頻道切換請求和高分辨率視頻的接收和解碼,當高分辨率視頻準備好后,則用其替代低分辨率的視頻或者準動態(tài)圖像??傮w來看,如果采用切換頻道時再從媒體服務器發(fā)送低分辨率或準動態(tài)視頻給用戶,則相對于傳輸高分辨率媒體流而言可以部分的節(jié)省傳輸時間;如果采用提前發(fā)送所有頻道的低分辨率或準動態(tài)視頻給用戶,則不僅可以節(jié)省高分辨率媒體流的傳輸時間,而且可以節(jié)省用于頻道請求的信令所引起的延遲,其效果將是比較顯著的。本發(fā)明實施例中所采用一種實施方式的通信網(wǎng)絡邏輯結(jié)構(gòu)如圖6所示。參照圖6,該系統(tǒng)包括終端、媒體服務器、中間處理模塊和應用處理模塊。其中,終端除了現(xiàn)有技術中正常的功能以外,例如發(fā)起頻道請求、播放正常的頻道的媒體流等等,還能夠在接收來自媒體服務器的頻道切換媒體流,并在正常的目標媒體流能夠播放之前播放所述頻道切換媒體流。在終端和媒體服務器之間,除了用于傳輸正常媒體流的第一媒體通道外,還具有用于傳輸所述頻道切換媒體流的第二媒體通道,所述第二媒體通道通常在終端發(fā)起初次頻道請求時建立。媒體服務器可以接受應用處理模塊的請求或者控制為終端傳送指定的媒體文件或者媒體流,包括正常的媒體流和頻道切換媒體流,所述頻道切換媒體流的產(chǎn)生將在下面描述。終端和媒體服務器是IP網(wǎng)絡,與現(xiàn)有的技術相同,可以將該IP網(wǎng)絡劃分為接入網(wǎng)和傳輸/核心網(wǎng)等,這里不再贅述。中間處理模塊為接入核心網(wǎng)的用戶提供呼叫控制、路由接續(xù)等功能,它可以將呼叫路由到被叫用戶終端,也可以將呼叫路由到應用處理模塊,相當于在終端與應用處理模塊以及在應用處理模塊與媒體服務器之間轉(zhuǎn)發(fā)消息。終端和中間處理模塊之間有接口El,中間處理模塊和媒體服務器之間有接口E3。接口El可以采用SIP、超文本傳輸協(xié)議(HTTP)、RTSP等。接口E3可以采用SIP、Diameter、H.248等。應用處理模塊用于處理用戶請求,在這里主要是進行IPTV業(yè)務的業(yè)務邏輯處理。中間處理模塊和應用處理模塊之間有接口E2,接口E2可以采用SIP、HTTP、RTSP等。采用圖6所示的系統(tǒng)結(jié)構(gòu),用戶終端通過發(fā)送頻道請求信令請求應用處理模塊返回頻道描述信息,或者使用應用層信令請求進行頻道切換,應用處理模塊對切換請求的響應仍然是切換目標頻道的描述信息,這種處理方式在本申請人的申請?zhí)枮?006100034107.3的中國專利申請中有所描述。在獲得這些信息后,終端可以與媒體服務器建立媒體通道用于媒體流傳送。下面描述媒體服務器生成頻道切換媒體流的方法。這里以低分辨率和/或準動態(tài)視頻為例。主要是希望其傳輸時間小,占用額外帶寬小,可以考慮如下技術用于在媒體服務器上生成頻道切換媒體流1.由于視頻中的i幀是可以獨立解碼的,因此我們可以從一個頻道的媒體流中僅提取其中的i幀并形成一個準動態(tài)媒體流。2.由于一般媒體流中的I幀:B幀:P幀的比率大概為8:2:3,因此一般僅提取I幀這樣操作的結(jié)果可能并不理想;為了進一步降低頻道切換媒體流占用的帶寬,進一步可以對每一個I幀進行尺寸壓縮處理,如將其分辨率降低到原來的1/4或者1/16,這樣整個媒體流占用的帶寬將顯著降低,提高了傳輸速度,降低了延遲時間。3.為了更進一步降低媒體流的大小,還可以在新形成的媒體流中采用n中取m的處理方法,即在連續(xù)的n個I幀中只取m(l<=m<=n)幀放入新的媒體流中;為了取得更好的連續(xù)性效果,在實際操作時也可以根據(jù)圖像的動態(tài)變化速度來調(diào)整提取的比例,如對于快速運動圖像可能需要提高其提取比例。4.另外,現(xiàn)有技術二中的分層編碼技術也可以用于提供此類媒體流,即對其基本層編碼使用上述3種處理方法的一種或者多種然后生成對應頻道的頻道切換媒體流;若基本層編碼本身媒體流就比較小,也可以直接作為對應頻道的頻道切換媒體流使用。需要指出的是,降低媒體流大小或者其占用的帶寬是為了服務亍快逸切換的需求,因此不能無限制的降低視頻分辨率或者降低提取I幀的比例,其取值應根據(jù)用戶的體驗感受試驗后確定。另外,上面所述的視頻指媒體流或者視頻文件,如果是媒體流,則頻道切換媒體流需要實時生成;如果是在頻道播出前即進行頻道切換媒體流生成,則處理對象是視頻文件,處理的結(jié)果也是視頻文件。接著描述頻道切換媒體流封裝和傳輸方式。在媒體服務器按上述方式對頻道的媒體流進行處理后,整個媒體流就可以應用在具體的頻道切換支持中了。媒體服務器可以分為提供正常媒體流的第一媒體服務器和提供頻道切換媒體流的第二媒體服務器,提供頻道切換支持的第二媒體服務器可以獨立存在,也可以和提供正常收看媒體流的第一媒體服務器合設。這里對提供頻道切換支持的媒體服務器和終端之間的媒體封裝和傳輸方式作以說明1)切換目標頻道媒體內(nèi)容的組織方式。媒體服務器可以將按照上述方法生成的媒體流,按如下方式封裝1.以傳輸流(TS)方式封裝。所述TS具體格式在ISO/IEC13818-1:2000(ITU-TRecommendationH.222.0)作了定義。按照TS的定義,在其中可以一次封裝單個頻道內(nèi)容,也可以一次性封裝多個頻道內(nèi)容,因此按上述方式對多個頻道生成的媒體流可以完全封裝到一個媒體流中。對于TS格式,在IP網(wǎng)絡上傳輸可以遵循RFC2250("RTPPayloadFormatforMPEG1/MPEG2Video")規(guī)范或者由DVB組織定義的"DigitalVideoBroadcasting(DVB);TransportofMPEG-2BasedDVBServicesoverIPBasedNetworks"規(guī)范。2.以因特網(wǎng)流媒體聯(lián)盟(InternetStreamingMediaAlliance,ISMA)規(guī)范所定義的方式進行頻道切換流媒體的封裝和傳輸,所述ISMA規(guī)范包括ISMA實現(xiàn)規(guī)范vl.0和v2.0。ISMA使用RTP協(xié)議傳送數(shù)據(jù),一般一次性只發(fā)送一個頻道的內(nèi)容。為了在支持頻道切換的第二媒體服務器和終端之間傳送頻道切換+某體流,可以考慮以IP單播和IP組播兩種方式進行發(fā)送。<table>tableseeoriginaldocumentpage20</column></row><table>表1結(jié)合上面給出封裝方式和發(fā)送方式,可以得出如表1所示的四種發(fā)送頻道切換媒體流的機制,即(1)TS封裝+IP單播發(fā)送;(2)TS封裝+IP組播發(fā)送;(3)ISMA封裝+IP單播發(fā)送;(4)ISMA封裝+IP組播發(fā)送。其中,第4種方式的實用意義不大,因此這里不作詳細說明。下面分別說明前三種方式(1)以IP單播方式從媒體服務器向終端發(fā)送,并且采用TS封裝。在業(yè)務交互過程中應用處理模塊向終端指定第二媒體服務器地址并協(xié)商傳輸通道;該通道在用戶正常收看節(jié)目時不用于傳輸內(nèi)容;當用戶切換頻道時,通過業(yè)務控制信令通知應用處理模塊,如以IMScore為中間處理才莫塊為例則所述業(yè)務控制信令可以是SIP再請求(reinvite)/信息(info)/通知(notify)等,應用處理模塊再控制/通知/請求第二媒體服務器通過單播通道向終端發(fā)送切換目標頻道的媒體流。應當指出,這里僅描述了如何發(fā)送頻道切換媒體流,實際上應用服務器在此同時應向發(fā)送正常媒體流的第一媒體服務器請求發(fā)送用戶所請求的媒體流。終端收到頻道切換媒體流后經(jīng)過解碼將低分辨率圖像顯示給用戶,以用于切換過渡,終端在這里可能需要進一步對低分辨率圖像進行放大以適應終端顯示屏的尺寸。進一步,也可以在單播流中發(fā)送所有頻道的頻道切換媒體流給用戶,則不需要在切換時再通過額外業(yè)務層信令進行頻道切換媒體流的請求,這才羊可以節(jié)省信令交互造成的延遲。為了避免某些用戶通過接收該頻道切換媒體流而免費收看節(jié)目,這里可以通過編碼機制造成該流中的信息只能還原成靜態(tài)信息或者準動態(tài)信息,使接收者在連續(xù)收看時無法達到體驗需求;從前面對于媒體服務器生成此頻道切換媒體流的機制來看,這個媒體流本身可以滿足此要求。(2)以組播方式從第二媒體服務器向用戶發(fā)送,并采用TS封裝。和方式(1)類似,這里可以在TS流中攜帶所有的頻道切換媒體流發(fā)送給用戶。這種方式下的處理相對簡單。在業(yè)務過程中攜帶第二媒體服務器發(fā)送頻道切換信息的組播地址給用戶,用戶以IGMP/MLD請求接收該組播流。對該IGMP/MLD請求,網(wǎng)絡側(cè)可以不加驗證的發(fā)送組播數(shù)據(jù)給用戶。否則,如果考慮驗證過程,則會增加驗證延遲的時間。當然,可以考慮按方式(l)中防止用戶免費收看節(jié)目的方法對內(nèi)容加以處理。(3)以單播方式從第二媒體服務器向用戶發(fā)送,并采用ISMA封裝。這種方式和方式(1)中TS封裝單個目標頻道信息大體相似,只是封裝方式不同而已,其處理機制相同。需要注意的是,這里給出的是對TS和ISMA封裝方式的說明,事實上經(jīng)媒體服務器處理后的媒體流/媒體文件也可以用其它可能的媒體封裝格式進行封裝和傳送,因此本發(fā)明的適用范圍并不局限于此。下面描述上述實施方式的具體流程,該流程如圖7所示。參照圖7,該流程包括以下步驟為了向終端提供頻道快速切換支持,終端首先需要獲得媒體服務器地址信息。步驟SOOl,終端向應用處理模塊發(fā)送頻道請求,該請求經(jīng)中間處理模塊路由到應用處理模塊處理;這個請求可以是終端的首次頻道請求,也可以是一個頻道切換請求,其中攜帶相應的指示,以表示是首次頻道請求或者是頻道切換_清求。步驟S002,應用處理模塊查詢終端的應用狀態(tài)信息,若終端已經(jīng)在收看節(jié)目,則終端應該已經(jīng)獲取了頻道切換媒體流的地址信息,即該請求為頻道切換請求,否則為首次頻道請求信息。如果終端的所述頻道請求為首次頻道請求,應用處理模塊在向媒體力l務器的媒體資源請求中除了包括對用戶希望收看的頻道信息進行請求外,還需要同時請求媒體服務器所支持的頻道切換媒體流信息。在所述請求是頻道切換請求的情況下,如果頻道切換媒體流需要經(jīng)過應用處理模塊給媒體服務器指示后才能發(fā)送,則應用處理模塊在向媒體服務器的請求中增加頻道切換媒體流發(fā)送指示;當然,這個請求中也包含對原始頻道媒體流的請求信息;步驟S003,媒體服務器根據(jù)應用處理模塊的請求進行媒體資源的分配,在響應中返回用戶所請求的目標頻道信息,如頻道組播地址,頻道端口等。如果應用處理模塊在上一步驟中同時請求了頻道切換媒體流信息,則媒體服務器在響應中返回相應信息。如前面所述,媒體服務器可能支持以單播TS方式、單播ISMA方式或者組播TS方式等進行頻道切換媒體流的發(fā)送,因此其攜帶的信息可能包括<頻道切換媒體流封裝方式,頻道切換媒體流發(fā)送方式,頻道切換服務支持信息>等,其中頻道切換媒體流封裝方式可以是"TSoRTP"、"ISMA,,等,頻道切換媒體流發(fā)送方式可以是"IP組播,,或者"IP單播"等。而頻道切換服務支持信息根據(jù)頻道切換媒體流發(fā)送方式的不同而不同,如對于"IP組播"而言,則可以包括<頻道切換媒體流組播地址,頻道切換媒體流組播端口>等;對于"IP單播,,而言,則可以包括<頻道切換媒體流單播地址,頻道切換媒體流單播端口>等。另外,若上述請求中包含發(fā)送頻道切換媒體流的指示,則媒體服務器應當優(yōu)先發(fā)送所指示的媒體流給終端。步驟S004,應用處理模塊將媒體服務器給出的目標頻道的媒體描迷信息通過頻道請求響應消息返回給終端;如果上一步返回信息中包括頻道切換媒體流信息,則這些信息也一起返回給終端。若媒體服務器所發(fā)送的正常媒體流和頻道切換媒體流都是以組播方式發(fā)送的,則上述的步驟S002和步驟S003可能只需要在第一個用戶請求業(yè)務時需要執(zhí)行,后續(xù)用戶請求時因為正常媒體流和頻道切換媒體流都已經(jīng)開始發(fā)送,因而不需要進一步請求;這里只需要應用處理模塊將所述<頻道切換媒體流封裝方式,頻道切換媒體流發(fā)送方式,頻道切換服務支持信息>以及目標頻道的媒體描述信息等發(fā)送給終端即可。步驟S005,若是初次進行頻道請求,則終端根據(jù)應用處理模塊返回的目標頻道信息準備在第一媒體通道接收目標頻道的媒體流。事實上,如果目標頻道的媒體流是通過IP組播方式發(fā)送的,則上迷準備接收的過程可能包含終端使用IGMP/MLD從接入節(jié)點請求媒體流,接入節(jié)點向其轉(zhuǎn)發(fā)組播媒體流的過程。步驟S006,若是終端首次進行頻道請求,則這里需要根據(jù)應用處理模塊返回的頻道切換媒體流信息準備在第二媒體通道接收頻道切換媒體流,其處理根據(jù)所返回的信息有所不同對于以單播方式發(fā)送而言,則終端可能需要根據(jù)指定的<頻道切換^某體流單播地址,頻道切換媒體流單播端口>等與媒體服務器建立相應的連接;或者根據(jù)所述信息準備在特定端口上接收頻道切換媒體流;對于以IP組播方式發(fā)送而言,則終端需要根據(jù)指定的<頻道切換媒體流組播地址,頻道切換媒體流組播端口>等信息向網(wǎng)絡側(cè)以IGMP/MLD協(xié)議請求組播流,并在指定端口上準備接收相應的頻道切換媒體流信息。若終端并非首次請求頻道,則頻道切換傳輸通道應該已經(jīng)存在,則其處理過程稍有不同1)對于以單播方式、TS只封裝單個頻道切換媒體流的情況,則在處理上述的用戶切換頻道請求時應用處理模塊應該請求頻道切換媒體服務器優(yōu)先發(fā)送指定目標頻道的切換媒體流給用戶,用戶可以通過單播通道優(yōu)先》11到該切換媒體流并用于切換"補償"。2)對于以單播方式、TS封裝所有頻道切換媒體流的情況,當用戶切換頻道時,切換目標頻道的切換媒體流應該提前發(fā)送,因此這個媒體流應該已經(jīng)被終端所接收;此時終端只需要從所接收的媒體流中快速檢索到相應的媒體流并用于切換"補償"即可。3)對于以組播方式、TS封裝所有切換媒體流的情況,其情況和上述情況2)處理相同。4)對于以單播方式、ISMA封裝方式而言,其處理同1)。另外,在上述流程中,在步驟S004,應用處理模塊也可以不向媒體提供設備請求所述的<頻道切換媒體流封裝方式,頻道切換媒體流發(fā)送方式,頻道切換服務支持信息>以及目標頻道的媒體描述信息等;這些信息可以提前配置到應用處理模塊,應用處理模塊在接收到用戶請求時只需要向終端直接返回這些信息即可,后續(xù)處理同上。另外,在上述方式下,在終端請求頻道信息時,應用處理模塊也可以一次性將所有正常頻道描述信息和頻道切換媒體流信息<頻道切換媒體流封裝方式,頻道切換媒體流發(fā)送方式,頻道切換服務支持信息>等一起發(fā)送給終端,后續(xù)終端不需要再進行此類信息的請求,而只需要使用根據(jù)這些信息使用IGMP/MLD等進行頻道切換請求,在發(fā)送此請求時,終端可以使用頻道切換媒體流進行快速頻道切換"彌補"處理。當然,這里假定頻道切換^f某體流是以組播方式發(fā)送給終端的,且無論用戶請求與否,該視頻流信息可以一直發(fā)送給終端。需要指出,進行IPTV組播業(yè)務建立和頻道切換可以使用多種方式的組合,這里只是給出幾種可能的情形,具體采用何種方式并不影響此專利思想的運用。圖8所示的是本發(fā)明的另一種實施方式的網(wǎng)絡結(jié)構(gòu)示意圖。參見圖8,該系統(tǒng)只包括終端和媒體服務器。在如圖8所示的方式中,不使用業(yè)務層信令進行目標頻道描述信息以及頻道切換媒體流信息的獲取和頻道切換請求。這里在終端和媒體服務器之間是IP網(wǎng)絡,終端可以通過帶外機制獲取媒體服務器的頻道地址信息等,所述帶外方式可能包括廣播、報紙、網(wǎng)站、郵件、電子節(jié)目單等,此類方法屬于現(xiàn)有技術,這里不再贅述。在獲得這些信息后,終端可以與媒體服務器建立第一媒體通道和第二媒體通道用于:fr某體流傳送。在上述傳送頻道描述信息的時候,也可以同時傳送頻道切換媒體流地址信息,則終端可以根據(jù)這些信息采用上面流程圖中步驟S005和步驟S006步驟進行相應處理,該過程如圖IO所示,其中步驟S005'和S006'與圖7中的步驟S005和S006相同,這里不再贅述。需要指出的是,這里假定終端使用IGMP/MLD進行頻道請求。由于沒有所謂應用處理模塊,這里主要考慮在頻道切換媒體流中發(fā)送所有頻道切換媒體流的方案,因此圖8所示的方式只有在前面所述的以單播或者組播報文、TS封裝所有頻道切換媒體流方式可以適用。進一步,針對圖6所示的邏輯結(jié)構(gòu)圖,在TISPANNGN架構(gòu)下,中間處理模塊可以是圖1所示的IMScore或者其它媒體支持組件,媒體服務器可以是傳統(tǒng)的媒體服務器,也可以是NGN中的多媒體資源功能實體(MultimediaResourceFunction,MRF),負責提供媒體資源,如媒體流。在該結(jié)構(gòu)中,同樣可以采用圖7所示流程進行處理。圖9所示為采用IMScore作為中間處理模塊時的網(wǎng)絡結(jié)構(gòu)。在圖9中,對于IMScore進行了簡略表示,其具體規(guī)范在3GPP已有定義。這里終端用于和應用服務器(AS)進行業(yè)務協(xié)商,請求應用服務器提供服務。代理CSCF(P-CSCF)用于轉(zhuǎn)發(fā)終端和服務CSCF(S-CSCF)之間的請求和響應消息。查詢CSCF(I-CSCF)用于查詢終端的信息。S-CSCF用于根據(jù)觸發(fā)規(guī)則,把業(yè)務請求消息觸發(fā)到AS,對消息進行路由。歸屬用戶服務器(HSS)用于向I-CSCF和/或S-CSCF提供必要的用戶信息。AS用于向用戶提供業(yè)務,與終端進行必要的業(yè)務協(xié)商,以及根據(jù)協(xié)商的結(jié)果向媒體資源控制功能實體(MRFC)提出媒體資源請求。MRFC接收AS的媒體資源請求并控制4某體資源處理功能實體(MRFP)進行媒體資源的分配。MRFP受MRFC的控制向終端提供媒體資源,如提供視頻/音頻節(jié)目流。通常情況下,MRFC和MRFP也合稱為MRF,相當于前面所述的々某體服務器。另外需要指出,除了中間處理模塊實例化為IMScore之外,這里MRF作為媒體服務器,而應用處理模塊則由AS承擔。以上所述僅為本發(fā)明的較佳實施例而已,并不用以限制本發(fā)明,凡在本發(fā)明的精神和原則之內(nèi),所作的任何修改、等同替換、改進等,均應包舍在本發(fā)明的保護范圍之內(nèi)。權(quán)利要求1、一種實現(xiàn)網(wǎng)絡電視頻道快速切換的方法,其特征在于,該方法包括以下步驟A.媒體服務器向終端發(fā)送目標頻道的頻道切換媒體流以及目標頻道的媒體流;B.終端在目標頻道的媒體流能夠播放之前,播放目標頻道的頻道切換媒體流。2、根據(jù)權(quán)利要求1所述的方法,其特征在于,步驟A之前進一步包括終端獲取目標頻道信息以及頻道切換媒體流信息,在媒體服務器與終端之間建立用于傳輸正常媒體流的第一媒體通道和用于傳輸所述頻道切換媒體流的第二媒體通道。3、根據(jù)權(quán)利要求2所述的方法,其特征在于,所述終端獲取目標頻道信息以及頻道切換媒體流信息的步驟為終端通過帶外機制獲取所述信息。4、根據(jù)權(quán)利要求3所述的方法,其特征在于,所述頻道切換媒體流信息包括頻道切換媒體流封裝方式、頻道切換媒體流發(fā)送方式以及頻道切換服務支持信息。5、根據(jù)權(quán)利要求4所述的方法,其特征在于,頻道切換媒體流封裝方式為傳輸流TS封裝,頻道切換媒體流發(fā)送方式為IP單播,頻道切換服務支持信息為頻道切換媒體流單播地址和端口;或者,頻道切換媒體流封裝方式為TS封裝,頻道切換媒體流發(fā)送方式為IP組播,頻道切換服務支持信息為頻道切換媒體流組播地址和端口。6、根據(jù)權(quán)利要求2所述的方法,其特征在于,所述終端獲取目標頻道信息以及頻道切換媒體流信息的步驟包括終端通過中間處理模塊向應用處理模塊發(fā)送首次頻道請求,應用處理模塊向媒體服務器請求目標頻道信息和頻道切換媒體流信息;媒體服務器向應用處理模塊返回目標頻道信息和頻道切換媒體流信息,應用處理模塊將其發(fā)送給終端。7、根據(jù)權(quán)利要求2所述的方法,其特征在于,該方法預先在應用處理模塊上配置所述目標頻道信息和頻道切換媒體流信息;所述終端獲取目標頻道信息以及頻道切換媒體流信息的步驟包括終端通過中間處理模塊向應用處理模塊發(fā)送首次頻道請求,應用處理模塊向終端返回所配置的目標頻道信息和頻道切換媒體流信息。8、根據(jù)權(quán)利要求6或7所述的方法,其特征在于,所述頻道切換々某體流信息包括頻道切換媒體流封裝方式、頻道切換媒體流發(fā)送方式以及頻道切換服務支持信息。9、根據(jù)權(quán)利要求8所述的方法,其特征在于,頻道切換媒體流封裝方式為傳輸流TS封裝,頻道切換媒體流發(fā)送方式為IP單播,頻道切換服務支持信息為頻道切換媒體流單播地址和端口;或者,頻道切換媒體流封裝方式為TS封裝,頻道切換媒體流發(fā)送方式為IP組播,頻道切換服務支持信息為頻道切換媒體流組播地址和端口;或者,頻道切換媒體流封裝方式為因特網(wǎng)流媒體聯(lián)盟ISMA封裝,頻道切換媒體流發(fā)送方式為IP單播,頻道切換服務支持信息為頻道切換媒體流單播地址和端口。10、根據(jù)權(quán)利要求1所述的方法,其特征在于,媒體服務器在未收到終端請求的情況下或者在收到終端請求之后,以組播方式發(fā)送所述頻道切換媒體流。11、根據(jù)權(quán)利要求1所述的方法,其特征在于,步驟A中媒體服務器進一步向終端發(fā)送復合為一個媒體流的多個頻道的頻道切換媒體流。12、根據(jù)權(quán)利要求1所述的方法,其特征在于,步驟A之前進一步包括生成頻道切換媒體流的步驟。13、根據(jù)權(quán)利要求12所述的方法,其特征在于,所述生成頻道切換媒體流的步驟包括提取對應頻道媒體流中部分或全部的幀內(nèi)編碼幀,組成頻道切換媒體流;或者,提取對應頻道媒體流中部分或全部的幀內(nèi)編碼幀,對所提取的幀內(nèi)編碼幀進行尺寸壓縮后,組成頻道切換媒體流;或者,將對應頻道分層編碼的基本層媒體流作為頻道切換媒體流;或者,對采用分層編碼的頻道媒體流,提取對應頻道基本層媒體流中部分或全部的幀內(nèi)編碼幀,并作為頻道切換媒體流;或者,對采用分層編碼的頻道媒體流,提取對應頻道基本層媒體流中部分或全部的幀內(nèi)編碼幀,對所提取的幀內(nèi)編碼幀進行尺寸壓縮后,并作為頻道切換媒體流。14、根據(jù)權(quán)利要求12或13所述的方法,其特征在于,所述生成頻道切換媒體流的步驟是指根據(jù)對應頻道的媒體流實時生成頻道切換媒體流;或者,針對對應頻道的流媒體文件預先生成用于頻道切換媒體流的流媒體文件。15、一種實現(xiàn)網(wǎng)絡電視頻道快速切換的系統(tǒng),其特征在于,該系統(tǒng)包括終端,用于發(fā)起頻道切換請求,以及在目標頻道的媒體流能夠播放之前播放目標頻道的頻道切換媒體流;媒體服務器,用于向終端發(fā)送所述頻道切換媒體流以及目標頻道的媒體流。16、根據(jù)權(quán)利要求15所述的系統(tǒng),其特征在于,所述終端進一步用于根據(jù)帶外方式獲取目標頻道信息以及頻道切換媒體流信息,并在媒體服務器與終端之間建立用于傳輸正常媒體流的第一媒體通道和用于傳輸所述頻道切換媒體流的第二媒體通道。17、根據(jù)權(quán)利要求15所述的系統(tǒng),其特征在于,該系統(tǒng)進一步包括中間處理模塊和應用處理模塊,其中,中間處理模塊用于在終端與應用處理模塊以及在應用處理模塊與媒體服務器之間轉(zhuǎn)發(fā)消息;應用處理模塊用于根據(jù)終端的首次頻道請求向媒體服務器請求目標頻道信息和頻道切換媒體流信息,以及將媒體服務器返回的目標頻道信息和頻道切換媒體流信息發(fā)送給終端;所述終端進一步根據(jù)目標頻道信息以及頻道切換媒體流信息,在媒體服務器與終端之間建立用于傳輸正常媒體流的第一媒體通道和用于傳輸所述頻道切換媒體流的第二媒體通道。18、根據(jù)杈利要求17所述的系統(tǒng),其特征在于,所述終端和中間處理模塊之間的接口采用會話發(fā)起協(xié)議SIP、超文本傳輸協(xié)議HTTP或?qū)崟r流協(xié)議RTSP;和/或,所述應用處理模塊和中間處理模塊之間的接口采用SIP、HTTP或RTSP;和/或,所述中間處理模塊和媒體服務器之間的接口采用SIP、Diameter或H.248。19、根據(jù)權(quán)利要求17所述的系統(tǒng),其特征在于,所述中間處理模塊包括代理呼叫會話控制實體P-CSCF、查詢呼叫會話控制實體I-CSCF、服務呼叫會話控制實體S-CSCF;所述應用處理模塊為應用服務器AS;所述媒體服務器為媒體資源功能實體MRF;所述MRF包括媒體資源控制功能實體MRCF和媒體資源處理功能實體MRFP,其中MRCF用于接收AS的請求并控制MRFP進行媒體資源的分配,MRFP則受MRFC的控制向終端提供媒體資源。20、根據(jù)權(quán)利要求15所述的系統(tǒng),其特征在于,所述媒體服務器進一步用于根據(jù)對應頻道的媒體流生成頻道切換媒體流。21、根據(jù)權(quán)利要求15所述的系統(tǒng),其特征在于,所述媒體服務器包括提供目標頻道媒體流的第一媒體服務器,以及提供頻道切換媒體流的第二媒體服務器。全文摘要本發(fā)明公開了一種實現(xiàn)網(wǎng)絡電視頻道快速切換的方法,該方法包括以下步驟A.媒體服務器向終端發(fā)送目標頻道的頻道切換媒體流以及目標頻道的媒體流;B.終端在目標頻道的媒體流能夠播放之前,播放目標頻道的頻道切換媒體流。本發(fā)明還提供了一種實現(xiàn)網(wǎng)絡電視頻道快速切換的系統(tǒng)。在本發(fā)明的方案中,當終端需要切換頻道時,無須進行額外的信令請求,接入網(wǎng)組播加入請求等動作,可以直接從已收到的頻道切換媒體流中解碼目標頻道的頻道切換媒體流預先播放,實現(xiàn)頻道的快速切換,本發(fā)明避免了接入節(jié)點進行信令處理,媒體流從媒體服務器到接入節(jié)點的延遲,以及終端和網(wǎng)絡之間可能的應用信令交互的延遲,大大縮短了頻道切換的時間。文檔編號H04N7/24GK101155298SQ200610139479公開日2008年4月2日申請日期2006年9月25日優(yōu)先權(quán)日2006年9月25日發(fā)明者軍嚴,吳向陽申請人:華為技術有限公司