用于動態(tài)地適配接收比特率的方法和相關(guān)的接收器的制造方法
【專利摘要】一種接收經(jīng)由網(wǎng)絡(luò)上的一些部分傳送的視聽節(jié)目的方法，該方法利用在服務(wù)器和接收器之間的實時傳輸協(xié)議和實時控制協(xié)議，視聽節(jié)目在服務(wù)器上以與按不同分辨率編碼的節(jié)目對應(yīng)的多個版本而可用，并且根據(jù)接收器的請求來實現(xiàn)其以不同比特率的傳送。該方法包括通過接收器有規(guī)律地測量網(wǎng)絡(luò)的帶寬，以便根據(jù)網(wǎng)絡(luò)的狀態(tài)調(diào)節(jié)傳送比特率。
【專利說明】用于動態(tài)地適配接收比特率的方法和相關(guān)的接收器
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及視聽節(jié)目接收器的領(lǐng)域，并且更確切而言涉及根據(jù)在利用實時傳送協(xié)議和與用于流傳輸傳送的實時傳送協(xié)議關(guān)聯(lián)的實時服務(wù)器控制協(xié)議傳送節(jié)目期間在網(wǎng)絡(luò)上可用的帶寬來動態(tài)地適配節(jié)目。
【背景技術(shù)】
[0002]為播放而下載節(jié)目強(qiáng)制實行視聽節(jié)目在恢復(fù)前完全傳遞給接收器。為了避免相關(guān)的限制，諸如需要等待下載結(jié)束或者需要具有用于整個節(jié)目的足夠存儲空間，使用流傳輸(在觀看期間連續(xù)地傳送節(jié)目)是很普遍的。
[0003]已知的流傳輸協(xié)議包括RTP(RFC3550和根據(jù)所傳輸?shù)臄?shù)據(jù)的格式關(guān)聯(lián)的RFC)，其與服務(wù)器控制協(xié)議(RFC2326)和MPEG TS/UDP (運動圖像專家組傳輸流/用戶數(shù)據(jù)報協(xié)議)相關(guān)聯(lián)，而下載通常使用HTTP (超文本傳輸通訊協(xié)議)協(xié)議。
[0004]現(xiàn)代通信網(wǎng)絡(luò)提供實現(xiàn)流傳輸傳送視聽節(jié)目的帶寬容量。傳送可以經(jīng)由在服務(wù)器與客戶端之間的、例如因特網(wǎng)的網(wǎng)絡(luò)來實施。流傳輸是一種傳送方法，在該傳送方法中，所傳送的視聽節(jié)目被分解為在整個傳送和恢復(fù)中在網(wǎng)絡(luò)上相繼傳送的時間部分(待順序地呈現(xiàn)的相繼部分)。傳送和恢復(fù)是在添加由于使用接收器的緩存而造成的輕微延遲的條件下是同時的。
[0005]標(biāo)準(zhǔn)3GPP (3GPP、TSGS-SA，透明端到端分組交換流業(yè)務(wù)(PSS )、3GPP文件格式(3GP)、TS26.244、V6.3.0、2005-03)定義了一種用于組織數(shù)據(jù)和存儲包括相同節(jié)目的對應(yīng)于不同比特率的數(shù)個版本的格式。與節(jié)目服務(wù)器上的控制邏輯關(guān)聯(lián)的該格式實現(xiàn)適配于各種條件并且尤其適配于在與網(wǎng)絡(luò)使用相關(guān)的帶寬的各種變化。在服務(wù)器上實現(xiàn)的控制邏輯卻并未在3GPP標(biāo)準(zhǔn)中規(guī)定。
[0006]在3GPP格式中，數(shù)據(jù)被編碼為對于固定比特率符合傳送鏈接上的比特率限制:當(dāng)數(shù)據(jù)是圖像時，編碼在于將圖像的分辨率適配為實現(xiàn)其以更大或更小的帶寬在鏈接上傳輸。但是3GPP卻并未定義這樣的轉(zhuǎn)換手段，該轉(zhuǎn)換手段實現(xiàn)修改所傳送的圖像的分辨率，以便對于帶寬方面的變化調(diào)節(jié)數(shù)據(jù)的接收。一些方法對于解決該問題是已知的:它們?nèi)Q于從客戶端傳送到服務(wù)器的數(shù)據(jù)、諸如在RTCP (實時控制協(xié)議)協(xié)議中定義的RR (接收器報告)，以及這樣的數(shù)據(jù)，這些數(shù)據(jù)需要由服務(wù)器進(jìn)行的處理和判讀步驟，以便定義是否該以其它比特率實施傳送。
[0007]HTTP流傳輸技術(shù)近來通過蘋果對于其iPhone和通過微軟對于其Smoothstreaming而得到公眾關(guān)注。HTTP流傳輸技術(shù)僅使用在IPTV接收器中，對于該接收器而言功能依賴于RTP和RTSP協(xié)議。
[0008]如今在IPTV中使用的傳送方法也不允許在不使用特定服務(wù)器的情況下根據(jù)在網(wǎng)絡(luò)上可用的帶寬動態(tài)地適配比特率，當(dāng)至服務(wù)器的訪問條件變差，則在接收器上出現(xiàn)中斷服務(wù)的風(fēng)險。
[0009]實時傳遞協(xié)議RTP例如是用于封裝和實時傳送對編碼視聽節(jié)目進(jìn)行編碼的數(shù)據(jù)的協(xié)議。用于數(shù)據(jù)的編碼通常是MPEG-TS類型或者是等效格式。
[0010]RTSP是通信協(xié)議的一個示例，其實現(xiàn)控制遠(yuǎn)程媒體服務(wù)器。這種協(xié)議提供對于視頻播放器典型的功能性，諸如“播放”和“暫?！?，并且實現(xiàn)將視聽節(jié)目的一部分從該節(jié)目部分在該節(jié)目中的時間位置起播放(例如時間索引或者在文件中的對應(yīng)位置)。
[0011]例如，在利用諸如RTP和RTSP的協(xié)議流傳輸?shù)貍魉鸵暵牴?jié)目期間，網(wǎng)絡(luò)可用性方面的顯著修改對于節(jié)目的恢復(fù)具有非常顯著的影響。當(dāng)比特率并未在傳送的開始和結(jié)束之間動態(tài)調(diào)節(jié)時，出現(xiàn)中斷，其對于用戶而言是很大的不方便。
[0012]RTP傳輸協(xié)議依賴于UDP協(xié)議，并且HTTP協(xié)議依賴于所連接的TCP協(xié)議。
[0013]TCP已知為“所連接的”協(xié)議，其對應(yīng)于可靠性限制，其實現(xiàn)在沒有包錯誤的情況下將數(shù)據(jù)從服務(wù)器傳送到接收器。為了實現(xiàn)這一點，接收器與服務(wù)器通信，該服務(wù)器向其指示所接收的數(shù)據(jù)。除了與丟失和再傳送的數(shù)據(jù)有關(guān)之外，平均的比特率與確認(rèn)的路由關(guān)聯(lián)。路由時間越快，則最大比特率降低得越多。
[0014]UDP是并不響應(yīng)于相同可靠性限制的協(xié)議。其被稱作“不可靠的”和“無連接的”。其沒有確認(rèn)系統(tǒng)并且其平均比特率并不與服務(wù)器和接收器之間的距離關(guān)聯(lián)。為此在IPTV應(yīng)用中將m)P協(xié)議與RTP —起使用。
[0015]本發(fā)明的一個目的是將UDP的優(yōu)點組合，而同時能夠動態(tài)地將比特率適配于網(wǎng)絡(luò)條件。

【發(fā)明內(nèi)容】

[0016]本發(fā)明的目的是克服現(xiàn)有技術(shù)的缺點中的至少一個，并且更確切而言，是實現(xiàn)動態(tài)地控制在使用一些實施傳遞/控制協(xié)議(例如RTP和RTSP協(xié)議)對于標(biāo)準(zhǔn)IPTV架構(gòu)傳送視聽節(jié)目期間所使用的帶寬。
[0017]使用根據(jù)本發(fā)明適配過的實時服務(wù)器控制協(xié)議的使用使得接收器能夠從服務(wù)器請求按相繼的部分傳送視聽節(jié)目。接收器周期性地對于每個所傳送的部分測量網(wǎng)絡(luò)的傳送條件并且從而調(diào)節(jié)傳送比特率。傳送比特率的調(diào)節(jié)由接收器實施，方式是對于節(jié)目的相繼地從服務(wù)器被請求的每個部分都從在服務(wù)器上可用并且以不同比特率編碼的數(shù)個版本中選擇節(jié)目版本。由接收器進(jìn)行的版本選擇根據(jù)在前一部分的傳送期間測量的傳送比特率來做出。以該方式，比特率的調(diào)節(jié)并不需要節(jié)目服務(wù)器的修改。
[0018]本發(fā)明涉及一種方法，用于接收存儲在服務(wù)器上的、用于在連接至接收器的顯示設(shè)備上進(jìn)行播放的視聽節(jié)目，該視聽節(jié)目在服務(wù)器上以至少兩個版本可用，每個版本都包括對節(jié)目的部分進(jìn)行編碼的數(shù)據(jù)塊的時間系列(并且因此包括一系列的待順序地呈現(xiàn)的數(shù)據(jù)塊)，這些版本均包括相同數(shù)目的塊，這些塊均以在不參考前面的圖像的情況下編碼的圖像開始。根據(jù)本發(fā)明，該方法在接收器的水平上包括如下步驟:根據(jù)實時傳輸協(xié)議接收視聽節(jié)目的第一部分，該第一部分包括來自由服務(wù)器以第一比特率傳送的第一版本的至少一個數(shù)據(jù)塊；在接收視聽節(jié)目的由所述服務(wù)器以第一比特率傳送的第一部分之后確定帶寬；根據(jù)實時服務(wù)器控制協(xié)議將請求傳送給服務(wù)器，該請求包括根據(jù)在服務(wù)器與接收器之間的帶寬的所確定的值識別與傳送速度參數(shù)的節(jié)目版本之一中的視聽節(jié)目的第二部分的信息，該識別信息包括該第二部分的開始和結(jié)束的時間標(biāo)記。
[0019]根據(jù)本發(fā)明的一個實施例，由接收器接收、確定帶寬和傳送請求的步驟在接收視聽節(jié)目期間迭代地重復(fù)。
[0020]根據(jù)本發(fā)明的一個實施例，視聽節(jié)目的版本包括在存儲在服務(wù)器上的單個文件中。
[0021]根據(jù)本發(fā)明的一個實施例，視聽節(jié)目在服務(wù)器上與描述性文件關(guān)聯(lián)，該描述性文件包括與視聽節(jié)目的版本在該相同文件中的定位有關(guān)的信息。
[0022]根據(jù)本發(fā)明的一個實施例，在服務(wù)器與接收器之間的可用帶寬的確定包括分析視聽節(jié)目的以第一比特率接收的部分的至少一個特性。
[0023]根據(jù)本發(fā)明的一個實施例，部分的至少一個特性是所傳送的比特的數(shù)目。
[0024]根據(jù)本發(fā)明的一個實施例，傳送請求的步驟使用RSTP協(xié)議的命令“播放”。
[0025]本發(fā)明還涉及一種用于由服務(wù)器傳播的視聽節(jié)目的接收設(shè)備，該節(jié)目在服務(wù)器上以至少兩個版本可用，這些版本中的每個都對應(yīng)于視聽節(jié)目的圖像分辨率并且包括一系列部分，這些版本均包括相同數(shù)目的部分并且這些部分均以幀內(nèi)圖像(intra image)開始。根據(jù)本發(fā)明，該設(shè)備包括:用于根據(jù)實時傳輸協(xié)議對由所述服務(wù)器以第一比特率傳送的第一版本中的視聽節(jié)目的第一部分進(jìn)行接收的裝置；用于在接收由所述服務(wù)器以第一比特率傳送的所述視聽節(jié)目的第一部分之后確定帶寬的裝置；以及用于根據(jù)實時控制協(xié)議將請求傳送給服務(wù)器的裝置，該請求包括根據(jù)所確定的在服務(wù)器與接收器之間的帶寬值和傳送速度參數(shù)的在節(jié)目版本之一中的視聽節(jié)目的第二部分的識別信息，該識別信息包括第二部分的開始和結(jié)束的時間標(biāo)記。
[0026]因此，傳送比特率被調(diào)節(jié)為適配于在網(wǎng)絡(luò)上可用的帶寬并且調(diào)節(jié)為在恢復(fù)視聽節(jié)目期間避免中斷，即使這意味著以較低質(zhì)量水平來恢復(fù)節(jié)目。
[0027]顯然，本發(fā)明并不限于使用RTP和RTSP協(xié)議并且涉及任意實時傳遞協(xié)議和對應(yīng)的服務(wù)器控制協(xié)議，該服務(wù)器控制協(xié)議具有與分別對于RTP和RTSP相比相似的特征，并且尤其提供例如播放命令的控制命令，其帶有允許對于待播放(呈現(xiàn))的視聽節(jié)目的部分選擇版本、開始時間和長度(或停止時間)的參數(shù)。
【專利附圖】

【附圖說明】
[0028]閱讀下面參考附圖進(jìn)行的描述，將更好地理解本發(fā)明，并且其它特定特征和優(yōu)點也將出現(xiàn)，附圖中:
[0029]-圖1示出了一種根據(jù)本發(fā)明的一個實施例的、用于借助接收器/解碼器接收視聽節(jié)目的系統(tǒng)。
[0030]-圖2示出了一種用于編碼的方法，其實現(xiàn)創(chuàng)建包括相同節(jié)目的數(shù)個版本的文件。
[0031]圖3示出了服務(wù)器的一個根據(jù)本發(fā)明的一個實施例的文件，其包括編碼的相同的視聽節(jié)目的待以不同比特率傳播的數(shù)個版本。
[0032]-圖4以圖表示出了在接收器與服務(wù)器之間的一系列初始化消息，用于根據(jù)RTP傳送協(xié)議傳送流。
[0033]圖5示出了根據(jù)本發(fā)明的一個實施例的在接收器與服務(wù)器之間的一系列初始化消息，用于傳送流。
[0034]-圖6是示出了在接收器上執(zhí)行的方法的圖，該方法包括有規(guī)律地評估網(wǎng)絡(luò)帶寬和傳送包括適配于網(wǎng)絡(luò)狀態(tài)的比特率參數(shù)和傳送速度參數(shù)的請求。[0035]-圖7是根據(jù)本發(fā)明的接收器的功能圖。
[0036]-圖8是示出了圖7中所描述的接收器的控制單元的功能圖。
【具體實施方式】
[0037]以普遍但不限制的方式，本發(fā)明涉及一種用于接收流傳輸?shù)囊暵牴?jié)目的方法，其實現(xiàn)根據(jù)通過有規(guī)律地測量帶寬而確定的網(wǎng)絡(luò)擁塞來動態(tài)地適配用于傳送節(jié)目的比特率。
[0038]圖1示出了一種用于由接收器2經(jīng)由網(wǎng)絡(luò)3接收視聽節(jié)目的系統(tǒng)。在接收期間，接收器處理視聽節(jié)目并且將信號傳送給顯示設(shè)備4用于其顯示。節(jié)目被編碼并且在節(jié)目服務(wù)器I上可用。節(jié)目以數(shù)字文件形式存儲。準(zhǔn)許在恢復(fù)期間以可變比特率傳送節(jié)目的傳送技術(shù)需要特殊的編碼，以便使得在與傳送編碼節(jié)目的數(shù)據(jù)期間的不同的比特率相對應(yīng)的不同版本的視聽節(jié)目在服務(wù)器上可用。相同的視聽節(jié)目的不同版本存儲在節(jié)目服務(wù)器I上。不同版本可以存儲在不同文件中或者聚集到單個文件上，并且通過其在文件中的相應(yīng)位置來被識別。與每個節(jié)目相關(guān)聯(lián)的描述文件包含與不同版本、其各自的比特率和其位置相關(guān)的信息。在從服務(wù)器到接收器的節(jié)目傳送的初始化階段期間，信息傳送給接收器。
[0039]圖2示出了視聽節(jié)目的編碼以便以根據(jù)網(wǎng)絡(luò)上的傳送條件進(jìn)行的比特率調(diào)節(jié)來傳送。視聽節(jié)目被編碼成數(shù)個版本。這些版本中的每個都對應(yīng)于一種圖像分辨率并且因此對應(yīng)于一種傳送比特率。在每個版本中，節(jié)目都由一系列塊或圖像組構(gòu)成。所有塊都對應(yīng)于節(jié)目的基本恢復(fù)(或播放)持續(xù)時間，例如2秒。這些基本塊常被稱作組塊(chunk)，例如在HTTP自適應(yīng)流傳輸(HTTP Adaptive streaming)技術(shù)的情況下。每個塊的第一圖像是幀內(nèi)圖像。幀內(nèi)圖像定義為在不參考前面的圖像的情況下被編碼。幀內(nèi)圖像在塊開始時的位置在每個版本中是相同的。因此，如果接收器請求服務(wù)器按在所觀看的內(nèi)容方面的節(jié)目的連續(xù)性，但是以其它版本并因此而以其它傳送比特率來遞送下一塊，則集成在接收器中的解碼器可以在并無參考前面圖像的問題的情況下實施該塊的解碼。圖2描述了以分別對應(yīng)于接收中(并且因此在傳送中)500千比特/秒、I兆比特/秒、1.5兆比特/秒和2兆比特/秒的比特率的版本來編碼節(jié)目。
[0040]圖3示出了文件30，其包含相同的視聽節(jié)目的如根據(jù)圖2中所示的編碼方法的數(shù)個版本31、32、33、34。不同的版本帶有不同索引地放置在相同的文件中。因此，在節(jié)目傳送中從一個版本到另一個的轉(zhuǎn)換對應(yīng)于索引與播放指針的相加。視聽節(jié)目的一個版本對應(yīng)于加至指針的可能的索引值中的每個。指針標(biāo)記出節(jié)目的待恢復(fù)部分的時間位置。
[0041]圖4示出了利用RTP傳送標(biāo)準(zhǔn)根據(jù)本發(fā)明的一個實施例建立在接收器與傳播服務(wù)器之間的通信。在使用RTP協(xié)議的傳播的初始化期間，接收器向服務(wù)器提交題目為RTSP描述、包括url的第一消息，以便從服務(wù)器獲得與將在連接至接收器的顯示設(shè)備上觀看的節(jié)目有關(guān)的信息。術(shù)語url (統(tǒng)一資源定位器)在此描述指向待觀看的節(jié)目的網(wǎng)絡(luò)地址。該地址例如具有語法“multimedia, exemple.com”。服務(wù)器在題目為RTSP描述響應(yīng)的響應(yīng)消息中向接收器提交信息。消息RTSP描述響應(yīng)向接收器指示節(jié)目版本以獨立的文件還是連接成單個文件存儲在服務(wù)器上。題目為RTSP設(shè)置的第二請求然后經(jīng)由接收器提交給服務(wù)器，以便準(zhǔn)備節(jié)目的流傳輸時段。如果節(jié)目的不同版本存儲在服務(wù)器上獨立的文件中，則接收器將借助服務(wù)器初始化與所存在的可用版本一樣多的傳送會話。如果不同版本連接在服務(wù)器上的相同文件中，則接收器發(fā)起單個的傳送會話。在節(jié)目的不同版本連接在相同的文件中的情況下，接收器將索引加至播放指針，以從節(jié)目的一個版本移動至另一個，并且因此調(diào)節(jié)所播放的節(jié)目部分的傳送比特率。對于會話的由接收器提出的每個初始化請求，服務(wù)器通過題目為RTSP設(shè)置響應(yīng)的消息來響應(yīng)。由接收器發(fā)送的題目為RTSP播放的第三消息起動由服務(wù)器進(jìn)行的節(jié)目傳送。消息RTSP播放還被稱作請求并且包括待為其恢復(fù)而傳輸?shù)墓?jié)目的部分的時間標(biāo)記參數(shù)。播放消息還包括速度參數(shù)，其向服務(wù)器指示傳輸對應(yīng)于待傳輸?shù)墓?jié)目部分的數(shù)據(jù)的速度。
[0042]根據(jù)本發(fā)明的一個實施例，根據(jù)用于視頻的H.264編解碼器和用于音頻的AAC編解碼器來對視聽節(jié)目內(nèi)容進(jìn)行編碼，以幀內(nèi)圖像開始的基本數(shù)據(jù)塊的大小對應(yīng)于在恢復(fù)時的2秒持續(xù)時間，數(shù)據(jù)的封裝根據(jù)MPEG傳輸流格式來進(jìn)行，并且與不同版本相關(guān)聯(lián)的比特率是50千比特/秒、1.5兆比特/秒和2兆比特/秒。在服務(wù)器上與視聽節(jié)目內(nèi)容文件關(guān)聯(lián)并且包含與節(jié)目的不同版本和不同的相關(guān)比特率有關(guān)的信息的描述文件是具有例如如下形式的SDP格式文件:
[0043]v=0
[0044]O=-1lIN IP4192.168.1.33
[0045]S=多媒體流的示例
[0046]b=RR:0
[0047]a=X-keyframe-period=2
[0048]a=control: *
[0049]a=range:npt=0_300
[0050]m=videoORTP/AVP33
[0051]b=TIAS:500000
[0052]a=control:tracklD=0
[0053]m=videoORTP/AVP33
[0054]b=TIAS:1000000
[0055]a=control:tracklD=l
[0056]m=videoORTP/AVP33
[0057]b=TIAS:1500000
[0058]a=control:tracklD=2
[0059]m=videoORTP/AVP33
[0060]b=TIAS:2000000
[0061]a=control:tracklD=3
[0062]在該SDP文件示例中，4個流(MPEG傳輸流)被標(biāo)出，并且通過使用與以兆比特/秒表示的比特率對應(yīng)的參數(shù)b=TIAS而與其各自比特率關(guān)聯(lián)。
[0063]圖5示出了根據(jù)本發(fā)明的一個實施例并且當(dāng)待觀看的節(jié)目的不同版本存儲在服務(wù)器上的不同文件中時建立在接收器與傳播服務(wù)器之間的通信。接收器初始化對待從不同流恢復(fù)的視聽節(jié)目部分的接收。在復(fù)原期間，并且對于相繼被請求的每個節(jié)目部分，接收器在服務(wù)器上指示適配于網(wǎng)絡(luò)上的帶寬條件的版本，并且接收對應(yīng)的流的數(shù)據(jù)。每個流都對應(yīng)于來自相同版本的數(shù)據(jù)傳送。根據(jù)一個實施例，在傳送之前，接收器提交與所存在的可用的版本一樣多的初始化消息。[0064]一旦對于每個版本都已完成初始化階段(設(shè)置)，則接收器可以通過發(fā)送播放請求從一個版本轉(zhuǎn)換為另一個該請求規(guī)定與所需塊，以及與傳送速度對應(yīng)的版本和時間間隔(通過使用時間標(biāo)記)。根據(jù)其它實施例，在傳送期間，接收器可以在到一個版本的第一訪問之前提交設(shè)置初始化請求。
[0065]圖6是示出了根據(jù)本發(fā)明的一個實施例的、由接收器所用的方法的框圖。步驟SI是初始步驟，在該步驟上，接收器并未初始化接收流傳輸?shù)墓?jié)目。在該步驟，接收器對于來自控制接收器的用戶的命令處于等待。在步驟S2，接收器將流傳輸傳播會話初始化。其發(fā)送第一 RTSP描述消息，該消息規(guī)定為復(fù)原而待從服務(wù)器接收的視聽節(jié)目的目標(biāo)url地址。該url地址例如可以是rtsp://exemple.com/movie/。該目標(biāo)地址用作對于控制傳播的參考。服務(wù)器提交RTSP描述響應(yīng)類型的消息，其向接收器指示與視聽節(jié)目的編碼為以不同比特率傳播的不同版本對應(yīng)的傳送流特性。該信息包括版本數(shù)目、其各自的標(biāo)識、編碼比特率和數(shù)據(jù)塊的大小。下面的信息交換、即從接收器傳送的RTSP設(shè)置和從服務(wù)器傳送的RTSP設(shè)置響應(yīng)準(zhǔn)備流傳輸傳播會話。接收器存儲在初始化階段S2中接收的信息，并且能夠提交用于傳播和接收視聽節(jié)目的部分(包括一個或數(shù)個數(shù)據(jù)塊)的相繼的RTSP播放請求。在步驟S3，傳送RTSP播放請求，該請求包含特定于待接收(并且因此待由服務(wù)器傳播)的節(jié)目的部分的傳播的參數(shù)。
[0066]RTSP播放請求的結(jié)構(gòu)根據(jù)本發(fā)明的一個實施例為:
[0067]PLAY rtsp://multimedia, exemple.com/stream/tracklD=lRTSP/l.0
[0068]Cseq:833
[0069]Range:npt=0_2
[0070]Speed:1
[0071]其中，PLAY指示該請求是這樣的消息，該消息請求傳播數(shù)據(jù)塊以用于其復(fù)原。
[0072]Cseq指示在初始化步驟S2上由服務(wù)器指示的序號,Range指示與從傳播開始起O到2秒的時間位置對應(yīng)的節(jié)目部分，并且Speed指示傳播速度。
[0073]為了避免在復(fù)原視聽節(jié)目期間中斷，接收器預(yù)先提交用于下一節(jié)目部分的RTSP播放請求，以便維持接收緩存中足夠的數(shù)據(jù)量。優(yōu)選地，接收緩存包含所接收節(jié)目的2秒，并且在解碼前可用。有利地，并且為了吸收在網(wǎng)絡(luò)上可用帶寬方面的波動，接收緩存可以包含多項數(shù)據(jù)，其對應(yīng)于所傳送的視聽節(jié)目的復(fù)原的數(shù)秒。
[0074]根據(jù)本發(fā)明的一個實施例并且為了簡化的目的，來自不同版本的數(shù)據(jù)塊的傳播在單個RTSP會話中完成。因此有利的是將節(jié)目的所編碼的多個版本連接到服務(wù)器上的單個文件中。
[0075]如果所考慮的是以比特率B0=500Kbps、Bl=IMbps, B2=l.5Mbps 和 B3=2Mbps 編碼的、持續(xù)時間為d的視聽節(jié)目，則從時間位置t到以比特率Bi編碼的節(jié)目的第i個版本的通道、對應(yīng)的RTSP播放請求的Range參數(shù)將以如下方式定義:
[0076]Range=i X d+t
[0077]在步驟S4，接收器接收對在服務(wù)器上為目標(biāo)的節(jié)目的部分進(jìn)行編碼的數(shù)據(jù)塊。接收器將該數(shù)據(jù)塊存儲在接收緩存中，在該接收緩存中，該數(shù)據(jù)塊將被接收器的音頻/視頻解碼模塊讀取。
[0078]步驟S5定義之前在S4中接收的部分是否是節(jié)目的最后，如果是，則傳播結(jié)束。[0079]在步驟S6中并且在其中在S4中接收的數(shù)據(jù)部分不是視聽節(jié)目的在時間位置方面的最后的情況下，則接收器實施對網(wǎng)絡(luò)上的可用帶寬的估計。
[0080]根據(jù)本發(fā)明的一個實施例帶寬的估計包括用于定義從服務(wù)器起可能的傳播比特率的步驟，以及用于測量預(yù)定義周期上的比特率的步驟。有利地，帶寬的估計可以包括加權(quán)步驟。根據(jù)本發(fā)明的一個實施例，加權(quán)步驟包括平滑或積分的步驟，其實現(xiàn)獲得平均值，以克服帶寬方面圍繞該值的迅速變化。接收器包括緩沖存儲器(接收緩存)，其能夠吸收網(wǎng)絡(luò)帶寬方面的迅速變化。
[0081]根據(jù)本發(fā)明，帶寬的估計可以對于每個基本數(shù)據(jù)塊重復(fù)或者對于包括預(yù)定義數(shù)目的基本數(shù)據(jù)塊的節(jié)目的部分來重復(fù)。
[0082]根據(jù)本發(fā)明的一個實施例，接收器使用由服務(wù)器響應(yīng)于RTSP播放請求傳送的信息來實施帶寬估計。
[0083]由服務(wù)器傳送的對于RTSP播放請求響應(yīng)具有如下形式:
[0084]RTSP/1.02000K
[0085]Cseq: 834
[0086]Range:npt=0_2
[0087]RTP-1nfo:url=rtsp://multimedia, exemple.com/stream/trackID=l;
[0088]seq=45102;rtptime=l2345678
[0089]其中rtptime是時間標(biāo)記，其指示由間隔npt指示的節(jié)目的部分的開始。
[0090]例如，如果時鐘節(jié)目(clock programme)被認(rèn)為是具有值9000的以MPEG-2TS格式編碼的、在傳送會話的初始化步驟中通信給接收器的的流，則接收器可以計算與該數(shù)據(jù)塊的接收時間對應(yīng)的時間間隔rangeduration:
[0091]rangeduration=rtptime end-rtptime start
[0092]其中rtptime start是在服務(wù)器響應(yīng)的信息域RTP-1nfo中指示的參數(shù)rtptime的值，
[0093]并且rtptime end=域 RTP-1nfo 的 rtptime+90000
[0094]其中90000是在傳播會話的階段初始化期間指示的時鐘RTP。
[0095]在數(shù)據(jù)塊的接收周期中的瞬時比特率然后通過如下方式計算:將在時間間隔中接收的數(shù)據(jù)的字節(jié)數(shù)(構(gòu)成根據(jù)RTP協(xié)議傳播的數(shù)據(jù)包的字節(jié))相加，將字節(jié)數(shù)乘以8以便獲得比特數(shù)(二進(jìn)制元素)，以及將乘積的結(jié)果除以接收持續(xù)時間。
[0096]S卩，瞬時比特率的如下表示:
[0097]Bi=字節(jié) X 8/rangeduration
[0098]根據(jù)本發(fā)明的一個實施例，因此計算出的瞬時比特率的值用于平滑算法中以定義更精確的比特率值。
[0099]算法使用迭代過程，以便確定在考慮在之前的迭代中計算出的瞬時比特率值的情況下可以獲得的比特率:
[0100]i是索引，其指的是有用比特率和其在傳送所接收的數(shù)據(jù)期間的方差的計算的第i次迭代。
[0101]因此，對于下一迭代進(jìn)行未來比特率的估計的計算:
[0102]avgi+1= (1- a ) X avgj+ α X Bi[0103]其中，Bi是所測量的比特率，
[0104]avgi是對于當(dāng)前迭代所計算的平均值，
[0105]α是歸因于瞬時比特率的測量值的加權(quán)因子。
[0106]優(yōu)選地，α的值等于1/16。
[0107]除了加權(quán)的平均值之外，由本發(fā)明使用的算法估計比特率的方差。方差以與比特率相同方式來平滑:
[0108]Δ J=IB1- avgj
[0109]Vari+1= (1- β ) X Vari+ ^XAi
[0110]其中，Ai是所測量的比特率與計算的當(dāng)前迭代的平均比特率之間差，
[0111]Vari是對于當(dāng)前迭代所計算的方差，
[0112]β是用于當(dāng)前估計的方差值的加權(quán)因子。
[0113]優(yōu)選地，β的值等于1/8。
[0114]對于算法的每次迭代，可以如下計算對于視聽節(jié)目的傳播獲得的比特率估計:
[0115]Bjmax=Bvg1- 4 X Vari
[0116]因此，如果方差大，這意味著接收器使用小于平均可用帶寬。此外，當(dāng)帶寬是穩(wěn)定的并且方差是低的，則接收器使用在服務(wù)器和其本身之間的所有可用帶寬。
[0117]有利地，在其中接收器使用所有可用帶寬的情況下，其向服務(wù)器提交RTSP播放請求，旨在將所接收節(jié)目的數(shù)個基本部分分組在一起，這是為了避免以非常頻繁的請求使服務(wù)器過載。接收器例如可以以相同的請求向服務(wù)器請求兩個或四個基本數(shù)據(jù)塊。
[0118]根據(jù)本發(fā)明的一個實施例，當(dāng)方差過大時，例如如果其值大于比特率值的一半，則如下計算比特率和方差的估計:
[0119]BVgw=(BVg^Bi)/2
[0120]以及
[0121]vari+1=avgi+1/10
[0122]根據(jù)本發(fā)明的一個變型，接收器確定的是網(wǎng)絡(luò)允許以大于當(dāng)前比特率的比特率進(jìn)行傳播，方式是指向視聽節(jié)目的相同版本并且修改在RTSP控制協(xié)議中定義的速度參數(shù)。如果當(dāng)前比特率例如是1.5兆比特/秒，接收器通過將規(guī)定“速度”參數(shù)為值速度=1.34的請求發(fā)送給服務(wù)器來評估網(wǎng)絡(luò)的以2兆比特/秒傳送的能力。
[0123]為了接收與經(jīng)由url “multimedia, exemple.com/stream”定位的視聽節(jié)目的第二和第四秒之間的時間間隔相對應(yīng)的數(shù)據(jù)塊而傳送的RTSP請求具有2兆比特/秒的比特率，而當(dāng)前的傳播比特率是1.5兆比特/秒，則該請求例如具有如下形式:
[0124]PLAY rtsp://multimedia, exemple.com/stream/trackID=lRTSP/l.0
[0125]Cseq:833
[0126]Range:npt=2_4
[0127]Speed: 1.34
[0128]在步驟S7，在考慮可用帶寬和帶寬變化的計算結(jié)果的情況下，接收器定義待提交給服務(wù)器的請求的參數(shù)。根據(jù)本發(fā)明的一個實施例，接收器根據(jù)帶寬和方差的計算值的組合來修改RTSP請求的速度參數(shù)。例如，根據(jù)本發(fā)明的一個變型并且在網(wǎng)絡(luò)的擁塞不僅導(dǎo)致傳送速度降低還導(dǎo)致數(shù)據(jù)丟失的情況下，接收器實施新請求，以便以較低比特率和增大的傳送速度來接收在對應(yīng)的版本中丟失的數(shù)據(jù)。較低比特率和增大的傳送速度的使用實現(xiàn)一方面降低在服務(wù)器與接收器之間傳送的數(shù)據(jù)量，但是還快速補(bǔ)償由之前由服務(wù)器傳送的數(shù)據(jù)丟失引起的時間損失。根據(jù)本發(fā)明的一個實施例，接收器使用傳輸數(shù)據(jù)的RTP包的首部的序號，以便檢測在節(jié)目的部分的傳送期間的數(shù)據(jù)丟失。數(shù)據(jù)丟失和再傳送數(shù)據(jù)的契約具有的結(jié)果是在復(fù)原節(jié)目期間降低接收緩存的填充率和增大與緩沖器中的數(shù)據(jù)丟失有關(guān)的偽影的風(fēng)險。有利地，接收器然后提交RTSP播放請求，其指示在實施之前描述的算法之前的較低比特率和大于I的速度參數(shù)。
[0129]圖7示出了根據(jù)本發(fā)明的一個實施例的接收設(shè)備2，其適配于接收和顯示視聽節(jié)目。雙向網(wǎng)絡(luò)接口 201實現(xiàn)對待恢復(fù)的視聽節(jié)目進(jìn)行編碼的數(shù)據(jù)進(jìn)行接收。接口 201還實現(xiàn)向傳播服務(wù)器傳送和從其接收控制消息。信號分離器202將與節(jié)目的接收有關(guān)的數(shù)據(jù)從接收通量以及控制消息中濾出，并且將其存儲在接收緩沖器203中。對視聽節(jié)目進(jìn)行編碼的數(shù)據(jù)由音頻/視頻解碼器204讀取，其將這些數(shù)據(jù)解碼并且將對應(yīng)的信號傳送給輸出接口 205。連接至輸出接口 205的顯示設(shè)備(未示出的)實現(xiàn)為用戶顯示節(jié)目。元件201、202、203、204和205的集合由控制單元200控制，該控制單元根據(jù)本發(fā)明的一個實施例包含微控制器和相關(guān)的存儲器，其實現(xiàn)運行軟件例程以及處理數(shù)據(jù)?？刂茊卧?00此外還分析從服務(wù)器接收的控制消息，并且生成傳送給服務(wù)器的控制消息。
[0130]圖8示出了根據(jù)本發(fā)明的一個實施例的控制單元200。該控制單元包括對于軟件應(yīng)用的執(zhí)行負(fù)責(zé)的微控制器210。應(yīng)用的可執(zhí)行代碼在接收器2起動時存儲在非易失性存儲器211中，并且可以當(dāng)接收器2可操作時被復(fù)制到工作存儲器212中。工作存儲器212包括用于存儲特定于執(zhí)行軟件應(yīng)用的數(shù)據(jù)和存儲所接收的數(shù)據(jù)的隨機(jī)存取存儲器?？刂茊卧?00還包括用于估計帶寬的模塊213。帶寬估計模塊213利用從接收緩沖器讀取的數(shù)據(jù)計算在服務(wù)器和接收器2之間的鏈接上的可用帶寬。RTSP控制模塊214根據(jù)所計算并且在估計模塊213中可用的帶寬值來制作RTSP請求。RTSP控制模塊讀取接收緩沖器中構(gòu)成對于RTSP播放請求的響應(yīng)的數(shù)據(jù)，并且將時間標(biāo)記rtptime通信給估計模塊213。在控制單元200的不同模塊之間交換的數(shù)據(jù)經(jīng)由內(nèi)部總線216來傳送。與接收器的其它功能模塊交換的數(shù)據(jù)集合經(jīng)由接口模塊215來實施。
[0131]在此借助基于RTP和RTSP協(xié)議的實施例描述了本發(fā)明，但是本發(fā)明顯然并不限于使用RTP和RTSP協(xié)議。本發(fā)明還涉及任意實時傳遞協(xié)議和對應(yīng)的服務(wù)器控制協(xié)議，其具有分別與RTP和RTSP相比類似的特征并且尤其提供例如播放命令的控制命令，其帶有允許對于視聽節(jié)目的待播放(呈現(xiàn))的部分定義(選擇)版本、開始時間和長度(或者停止時間)。
【權(quán)利要求】
1.一種用于接收存儲在服務(wù)器上的、用于在連接至接收器的顯示設(shè)備上進(jìn)行播放的視聽節(jié)目的方法，所述視聽節(jié)目在所述服務(wù)器上以至少兩個版本可用，所述版本中的每個都包括一系列數(shù)據(jù)塊，這些數(shù)據(jù)塊分別表示所述視聽節(jié)目的待相繼呈現(xiàn)的部分，所述版本中的每個都包括相同數(shù)目的塊，所述塊中的每個都以在不參考前面圖像的情況下編碼過的圖像開始，其特征在于，所述方法在接收器水平上包括如下步驟: -根據(jù)傳輸協(xié)議，接收所述視聽節(jié)目的第一部分，該第一部分包括來自由所述服務(wù)器以第一比特率傳送的第一版本的至少一個數(shù)據(jù)塊，所述第一部分是所述服務(wù)器上的文件的子集，所述文件包括多個部分，所述部分中的每個的位置都在所述文件中通過索引來指示， -在接收視聽節(jié)目的由所述服務(wù)器以所述第一比特率傳送的所述第一部分之后確定帶寬， -根據(jù)控制協(xié)議，將請求傳送給所述服務(wù)器，所述控制協(xié)議適配于通過使用命令控制內(nèi)容的實時傳送，并且適配于在文件中識別數(shù)個數(shù)據(jù)部分中的待傳送的數(shù)據(jù)部分，所述識別經(jīng)由索引來實現(xiàn)，所述請求包括: -根據(jù)在所述服務(wù)器和所述接收器之間的帶寬的所確定的值來識別在所述節(jié)目的所述版本之一中的所述視聽節(jié)目的第二部分的信息， 所述識別信息包括所述第二部分的開始和結(jié)束的時間標(biāo)記。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述請求還包括傳送速度參數(shù)。
3.根據(jù)權(quán)利要求1或2所述的用于接收視聽節(jié)目的方法，其特征在于，接收步驟使用RTP傳送協(xié)議。
4.根據(jù)權(quán)利要求1到3中任一項所述的用于接收視聽節(jié)目的方法，其特征在于，傳送請求的步驟使用RSTP控制協(xié)議。
5.根據(jù)權(quán)利要求1到4中任一項所述的方法，其特征在于，所述視聽節(jié)目的所述版本包括在存儲在所述服務(wù)器上的相同文件中。
6.根據(jù)上述權(quán)利要求中任一項所述的方法，其特征在于，將所述視聽節(jié)目在所述服務(wù)器上與描述性文件關(guān)聯(lián)，該描述性文件包括與所述視聽節(jié)目的所述版本在所述相同文件中的定位有關(guān)的信息。
7.根據(jù)上述權(quán)利要求中任一項所述的方法，其特征在于，對于在所述服務(wù)器與所述接收器之間的可用帶寬的確定包括分析所述視聽節(jié)目的以所述第一比特率接收的所述部分的至少一個特性。
8.根據(jù)權(quán)利要求7所述的方法，其特征在于，所述部分的至少一個特性是所傳送的比特數(shù)。
9.根據(jù)上述權(quán)利要求中任一項所述的方法，其特征在于，傳送請求的步驟使用RSTP協(xié)議的播放命令。
10.根據(jù)上述權(quán)利要求中任一項所述的方法，其特征在于，確定在所述服務(wù)器與所述接收器之間的帶寬的步驟使用服務(wù)器對于RSTP協(xié)議的播放命令的響應(yīng)。
11.一種用于接收由服務(wù)器傳播的視聽節(jié)目的設(shè)備，所述節(jié)目在所述服務(wù)器上以至少兩個版本可用，所述版本中的每個都對應(yīng)于所述視聽節(jié)目的圖像分辨率并且包括一系列部分，所述版本中的每個都以幀內(nèi)圖像開始，其特征在于，所述設(shè)備包括: -用于接收的裝置，來根據(jù)傳輸協(xié)議接收由所述服務(wù)器以第一比特率傳播的第一版本中的所述視聽節(jié)目的第一部分， -用于確定帶寬的裝置，該確定在接收由所述服務(wù)器以所述第一比特率傳播的所述視聽節(jié)目的所第一部分之后進(jìn)行， -用于將請求傳送給所述服務(wù)器的裝置，該傳送根據(jù)控制協(xié)議進(jìn)行，所述控制協(xié)議適配于通過使用命令來控制內(nèi)容的實時傳送，并且適配于在文件中識別數(shù)個數(shù)據(jù)部分中的待傳送的數(shù)據(jù)部分，所述識別經(jīng)由索引來實現(xiàn)，所述請求包括: -根據(jù)在所述服務(wù)器與所述接收器之間的帶寬的所確定的值來識別在所述節(jié)目的所述版本之一中的所述視聽節(jié)目的第二部分的信息， -所述識別信息包括所述第二部分的開始和結(jié)束的時間標(biāo)記。
12.根據(jù)權(quán)利要求11 所述的設(shè)備，其特征在于，所述請求還包括傳送速度參數(shù)。
【文檔編號】H04L29/06GK103548318SQ201280023415
【公開日】2014年1月29日 申請日期:2012年5月4日 優(yōu)先權(quán)日:2011年5月18日
【發(fā)明者】S.古阿基, Y.勒加萊斯, P.吉爾伯頓 申請人:湯姆遜許可公司