專利名稱：恢復(fù)流傳輸為塊的內(nèi)容的方法
技術(shù)領(lǐng)域：
本發(fā)明一般涉及自適應(yīng)視頻流傳輸，尤其涉及ー種用于恢復(fù)自適應(yīng)視頻流傳輸內(nèi)容的方法。
背景技術(shù)：
這部分g在向讀者介紹本技術(shù)領(lǐng)域的各個方面，這些方面可能與下面將要描述和/或要求權(quán)利的本發(fā)明的各個方面有夫。這個討論被認(rèn)為有助于向讀者提供背景信息以幫 助更好地理解本發(fā)明的各個方面。因此，應(yīng)該從這個角度理解這些陳述，而不應(yīng)該將它們理解為是對現(xiàn)有技術(shù)的承認(rèn)。媒體傳送流傳輸解決方案主要基于諸如定義在IETF RFC 2326、微軟公司的微軟媒體服務(wù)器(MMS)私有協(xié)議或Adobe系統(tǒng)公司的實時消息傳送協(xié)議(RTMP)私有協(xié)議中實時流傳輸(RTSP)的協(xié)議。最近出現(xiàn)了基于HTTP協(xié)議的新的流傳輸技術(shù)。自適應(yīng)流傳輸技術(shù)通過不間斷且合適地提升或降低視頻質(zhì)量以適應(yīng)帶寬限制提供了一種補償與可用帶寬有關(guān)的異常的網(wǎng)絡(luò)行為的方法。更確切地說，視頻流被編碼成幾個編碼比特流，每個都與ー個比特率限制對應(yīng),諸如例如300kbps、600kbps、1200kbps、2000kbps或3000kbps。然后，這些流中的每個都被劃分為代表例如2秒持續(xù)時間的若干塊，全部以其中每個塊都以參考幀開始的方式很好地對齊；任何給定的塊的幀都不參考另ー個塊的幀。換句話說，視頻流被切割成被稱作“塊”并被編碼成理想傳送格式的短分段(segment)。塊通常為2至4秒長。在視頻編解碼器級別，這通常意味著每個塊都沿著視頻畫面組(GOP)的邊界切割并且與之前或之后的塊和GOP無關(guān)。這允許每個塊可以獨立于其它塊在稍后被解碼?？蛻舳搜b置請求HTTP服務(wù)器發(fā)送保持在與估計的帶寬有關(guān)的特定比特率上的塊，其中可以通過例如測量HTTP請求/應(yīng)答所用的往返時間測量可用帶寬。然后，基于客戶端請求一塊接ー塊地傳送視頻流。這在如圖I中圖示，圖I從較低到較高比特率地展示了塊比特率的4個等級。所有與固定的持續(xù)時間對應(yīng)的視頻塊或多或少是大的。大的塊要求更寬的帶寬并提供更好的視頻質(zhì)量。塊的選擇取決干與曲線對應(yīng)的估計的可用帶寬。當(dāng)然，取決于實施方式、環(huán)境、網(wǎng)絡(luò)技術(shù)和客戶端應(yīng)用，策略可能或多或少是保守的。當(dāng)策略是保守的時候，客戶端僅在某一時間后請求更高比特率的塊，從而保證平滑的提升過渡。較不保守的策略在客戶端ー檢測到更多的可用帶寬后就請求更高比特率的塊。以及，通常地，客戶端在其一檢測到暗示急速的降低過渡的帶寬減少就請求更低比特率的塊。這種流傳輸技術(shù)的實例是Move Networks的“ Move Adaptive Stream”、蘋果公司的“HTTP實時流傳輸”和微軟公司的“ IIS (因特網(wǎng)信息服務(wù))平滑流傳輸”。在這些流傳輸解決方案中使用HTTP協(xié)議的好處在于它能夠無縫地跨越NAT和防火墻。這些HTTP流傳輸技木通過不間斷且合適地提升或降低視頻質(zhì)量以適應(yīng)帶寬限制提供了一種補償與可用帶寬有關(guān)的異常的網(wǎng)絡(luò)行為的方法。更具體地說，Move Networks的專利WO 2005/109224A2描述了ー種在處在客戶端側(cè)的代理控制器模塊(Agent Controller Module)中并且能夠適應(yīng)波動的網(wǎng)絡(luò)帶寬的機(jī)制，這是由于下列事實將要被流傳輸?shù)拿襟w在之前已經(jīng)被組織成多個細(xì)流(streamlet)，這種細(xì)流也被稱作塊，它們中的每ー個都被從低到高比特率編碼。根據(jù)可用網(wǎng)絡(luò)帶寬和ー些其它額外的信息，包括在代理控制器模塊中的監(jiān)視工具使用HTTP協(xié)議以請求服務(wù)器發(fā)送最合適在TCP/IP連接上流傳輸?shù)膲K?；诨緣K，質(zhì)量根據(jù)代理控制器模塊上移(up-shift)或者下移(down-shift)。Alex Zambelli 的 IIS Smooth Streaming Technical Overview (微軟公司，2009年3月)描述了 TCP/IP連接上基于HTTP協(xié)議的IIS平滑流傳輸技術(shù)。將要由服務(wù)器流傳輸?shù)拿襟w之前被切分成代表例如I到10秒持續(xù)時間的塊。然后，根據(jù)H. 264/MPEG-4AVC標(biāo)準(zhǔn)以不同的比特率對這些塊編碼并將其存儲在MP4文件格式容器中。根據(jù)網(wǎng)絡(luò)帶寬波動選擇比特率并請求無縫地將對應(yīng)的塊流傳輸?shù)椒?wù)器的機(jī)制通過應(yīng)用代碼，Silverlight應(yīng)用，完全被實施在客戶端側(cè)。HTTP實時流傳輸支持響應(yīng)變化的連接速度在不同數(shù)據(jù)率的流之間動態(tài)切換。蘋果公司在2009 年 10 向 IETF 提交了ー份標(biāo)題為“HTTP Live Streaming draft- pantos-http-live-streaming-02”的有關(guān)HTTP流傳輸方法規(guī)范的因特網(wǎng)草案。HTTP流傳輸架構(gòu)基于3個支柱服務(wù)器、通過Web服務(wù)器或Web高速緩存系統(tǒng)的分布和客戶端。將要被流傳輸?shù)拿襟w是使用H. 264編碼的視頻和使用AAC編碼的音頻。在服務(wù)器端，它被封裝在MPEG-TS容器內(nèi)并使用名稱為Apple stream segmenter (蘋果流分段器)的特定工具將其分段成相等持續(xù)時間的塊。這個工具生成若干被保存為*. ts文件和索引文件*;m3u8的塊，以組成塊播放列表。然后，由于URL指針，客戶端先取回索引文件。索引文件反過來規(guī)定可用媒體文件、解密密鑰和任何可用替代性流的位置。對于選擇的流，客戶端按順序下載每ー個可用媒體文件。使用這種自適應(yīng)流傳輸技木，視頻質(zhì)量是不規(guī)律的。客戶端ー個塊接一個塊獲得的流由于它是不同比特率的塊的混合因此并不具有一致的質(zhì)量。該視頻可以被存儲在稍后會被其重放的接收器上。通常地，使用這種流傳輸應(yīng)用，由于塊可以被記錄在本地存儲設(shè)施上，因此不存在在網(wǎng)絡(luò)上重新發(fā)送流的需要。然而，記錄的塊序列與在流傳輸會話期間得到體驗的網(wǎng)絡(luò)條件對應(yīng)，從而導(dǎo)致不一致的視頻質(zhì)量。這個問題的ー個解決方案可能是從服務(wù)器重新獲取與低質(zhì)量的塊對應(yīng)的塊。這可以作為在記錄的流被重放之前的分組下載來完成。然而，這種做法可能比較耗吋。另ー種解決方案是在重放被記錄的流的過程中即時地替換低質(zhì)量的塊。然而，也無法保證客戶在他們需要時能獲得更好質(zhì)量的塊。并且，這兩種解決方案都強制要求客戶端與服務(wù)器連接。

發(fā)明內(nèi)容
本發(fā)明試圖通過提供適時地增強塊質(zhì)量的方法補救至少ー些現(xiàn)有技術(shù)中與質(zhì)量較低的塊有關(guān)的問題。為了達(dá)到這個目的，本發(fā)明涉及用于在客戶端裝置接收被分割成與內(nèi)容持續(xù)時間對應(yīng)的塊的內(nèi)容的自適應(yīng)流傳輸方法，這些塊在服務(wù)器被編碼成至少第一和第二格式，第一格式與比第二格式更好的內(nèi)容呈現(xiàn)質(zhì)量等級對應(yīng)，塊在塊接收時段期間被接收。根據(jù)本發(fā)明，該方法包括下列步驟測量客戶端和服務(wù)器之間可用于下ー個塊接收時段的帶寬、請求服務(wù)器發(fā)送以某種格式編碼的塊以使得該塊可以在下一個塊接收時段期間被接收以及如果某些帶寬可用于下ー個塊接收時段，那么請求服務(wù)器發(fā)送一部分以第ニ格式編碼的塊，以第一格式編碼的該塊已被接收。根據(jù)實施例，該方法包括接收塊并將該塊傳送給呈現(xiàn)裝置的步驟。根據(jù)實施例，該方法包括將塊存儲在存儲器中的步驟。根據(jù)本發(fā)明的實施例，該方法包括在連續(xù)的塊接收時段使用可用帶寬以請求以第ニ格式編碼的該塊所有部分的步驟。根據(jù)本發(fā)明的實施例，該方法包括一接收到以第二格式編碼的塊的所有部分就在存儲器中用以第二格式編碼的塊替換(swap)以第一格式編碼的塊的步驟。本發(fā)明還涉及ー種用于在客戶端裝置接收被分割成與內(nèi)容持續(xù)時間對應(yīng)的塊的內(nèi)容的自適應(yīng)流傳輸方法，在服務(wù)器，根據(jù)視頻可伸縮視頻編碼(SVC)技術(shù)，將這塊編碼成一個基礎(chǔ)層和至少ー個增強層，并且塊在塊接收時段期間被接收。為了達(dá)到這個目的，該方·法包括下列步驟測量客戶端和服務(wù)器之間可用于下ー個塊接收時段的帶寬、請求服務(wù)器發(fā)送使用至少ー個SVC層編碼的塊以使得該塊可以在下一個塊接收時段期間被接收，以及如果ー些帶寬可用于下ー塊接收時段，那么請求服務(wù)器發(fā)送之前在沒有至少ー個增強層的情況下已經(jīng)被接收的塊的所述至少ー個增強層。根據(jù)本發(fā)明的實施例，該方法包括接收塊并將該塊傳送給呈現(xiàn)裝置的步驟。根據(jù)本發(fā)明的實施例，該方法包括將塊存儲在存儲器中的步驟。根據(jù)本發(fā)明另一目的是ー種包括用于在計算機(jī)上執(zhí)行時執(zhí)行根據(jù)本發(fā)明的方法步驟的程序代碼指令的計算機(jī)程序產(chǎn)品?！坝嬎銠C(jī)程序產(chǎn)品”是指計算機(jī)程序支持，其可能不僅僅在于包含程序的存儲空間，諸如計算機(jī)存儲器，而且在于信號，諸如電信號或光信號。下面將陳述在范圍方面與公開的實施例相當(dāng)?shù)哪承┓矫?。?yīng)該理解的是，展示這些方面只是為了為讀者提供本發(fā)明可能會采用的某些形式的簡略概要，而不是為了限制本發(fā)明的范圍。當(dāng)然，本發(fā)明可能包括可能未在下面陳述的多個方面。


參考附圖，通過非限制性的以下實施例和執(zhí)行實例，將會更好地理解和例示本發(fā)明。在附圖中圖I是沿時間的傳送塊的圖示；圖2是根據(jù)實施例的系統(tǒng)的框圖；圖3是根據(jù)實施例的客戶端裝置的框圖；圖4示例了根據(jù)第一實施例的塊傳送；和圖5示例了根據(jù)第二實施例的塊傳送。在圖3中，表示的方塊都是單純的功能實體，其并不一定要與物理上分開的實體對應(yīng)。即，它們可以被開發(fā)成硬件或軟件的形式，或者被實施為ー個或若干集成電路。
具體實施例方式應(yīng)該了解的是，為了清楚地理解本發(fā)明，本發(fā)明的圖和描述都已經(jīng)被簡化以示例相關(guān)元素，而為了清楚，除去了典型的數(shù)字多媒體內(nèi)容傳送方法和系統(tǒng)中的許多其它的元素。然而，由于這些元素在本領(lǐng)域中是熟知的，因此在本說明書中并未提供這些元素的詳細(xì)討論。本說明書中的公開內(nèi)容關(guān)注本領(lǐng)域技術(shù)人員已知的所有這樣的變化和修改。下面將描述兩個實施例。在第一實施例中，內(nèi)容被編碼成具有若干比特率，而在第ニ實施例中，使用可伸縮視頻編碼對內(nèi)容編碼。圖2表示了根據(jù)實施例的系統(tǒng)。它包括通過因特網(wǎng)連接的客戶端I和服務(wù)器3。視頻文件分割器5生成壓縮的視頻和音頻為塊?？蛻舳艘才c播放器4連接。在服務(wù)器側(cè)，根據(jù)客戶端請求，使用HTTP協(xié)議在TCP/IP連接上流傳輸塊?？蛻舳烁鶕?jù)下面描述的方法并基于網(wǎng)絡(luò)帶寬估計和顯著的多余帶寬請求塊。圖3示出了根據(jù)實施例的客戶端。客戶端包括網(wǎng)絡(luò)的第一接ロ 14和通信部件13，該通信部件13包括與位于網(wǎng)絡(luò)上的服務(wù)器通信的協(xié)議棧。尤其地，網(wǎng)絡(luò)是因特網(wǎng)，通信部件是本領(lǐng)域熟知的TCP/IP棧。當(dāng)然，它也可以是任何其它類型的使得客戶端能夠與服務(wù)器通信的網(wǎng)絡(luò)和/或通信部件。客戶端還包括連接至適用于解碼并呈現(xiàn)內(nèi)容的視頻播放器的第二接ロ 16。當(dāng)然，第二接ロ可能能夠連接ー個以上的播放器。第二接ロ可以是網(wǎng)絡(luò)的接ロ，使得能夠連接一 個或多個播放器。客戶端還包括用于處理存儲在客戶端中的應(yīng)用的處理器11。它包括用于在接收自服務(wù)器的塊被傳輸?shù)絊VC播放器之前緩沖這些塊的緩沖器12?？蛻舳诉€包括存儲器17，接收自服務(wù)器的塊被傳送至該存儲器17。它優(yōu)選是非易失性存儲器。客戶端還包括用于存儲在客戶端上運行的應(yīng)用的非易失性存儲器(未顯示)。塊選擇器15是適用于進(jìn)行如下文所述的塊選擇的應(yīng)用。客戶端可以被實施為網(wǎng)關(guān)裝置。替代性地，客戶端包括嵌入式SVC播放器。因此，它也可以是諸如機(jī)頂盒這樣的裝置。替代性地，可以將存儲器替代性地放置在與客戶端裝置連接的存儲裝置中。只有當(dāng)存儲裝置與客戶端連接時，才會觸發(fā)執(zhí)行如下文所述的方法。這可以ー檢測到連接的存儲裝置就被自動觸發(fā)。這還可以在末端用戶請求時被觸發(fā)?？蛻舳擞糜诮邮諌K的方法總結(jié)如下-塊選擇器根據(jù)下文描述的方法選擇塊，-通信部件向服務(wù)器發(fā)送請求以接收選擇的塊，-通信部件接收塊，-對塊進(jìn)行緩沖，-將塊發(fā)送至視頻播放器。根據(jù)實施例，塊也被發(fā)送至存儲器17。為了增強這些存儲的塊的質(zhì)量，客戶端使用剰余可用帶寬以請求更高質(zhì)量的塊，正如下文所示。然后，這些更高質(zhì)量的塊被存儲在存儲器17中。圖4示出了根據(jù)第一實施例的方法。塊持續(xù)時間與附帯在塊上的視頻持續(xù)時間對應(yīng)?？蛻舳嗽诿總€塊持續(xù)時間段請求與某ー比特率對應(yīng)的塊?？蛻舳私邮諌Kchi至chl4。在下文中，塊持續(xù)時間被設(shè)定為2秒。在保守的方法中，客戶端僅在一定時間后就請求更聞比特率的塊，從而保證平滑的提升過渡。當(dāng)客戶端估計到可用于下ー個塊的帶寬時，遵循保守方法，請求與留出足夠的帶寬以在同一時間段請求提升塊的部分的比特率對應(yīng)的塊。圖4以從較低到較高比特率的順序，如與圖I所示，展示了塊比特率的4個等級。為了簡化，與同一比特率對應(yīng)的塊具有相同的大小，即給定比特率的所有塊都被表示為具有相同的面積。如圖4所示，客戶端已經(jīng)請求了與給予同時下載更多信息的機(jī)會的比特率相關(guān)的塊序號3。客戶端使用可用帶寬請求塊I的第一中間比特率版本的片段(fragment)，而該塊I在開始時已經(jīng)被接收為低比特率的塊，如具有設(shè)置為一的索引的方框。當(dāng)請求塊4時會發(fā)生相同的情形。此時，客戶端獲得塊I的第一中間比特率版本的最后ー個片段。并且，塊6、7、8和9也會逐漸地被它們各自的第一完全中間比特率的版本替換。當(dāng)然，ー個塊只有在相應(yīng)的提升的塊已經(jīng)被完全接收時才會被替換。替代性地，可以使用其它方法用于提升本地緩存在客戶端主機(jī)中的視頻的整體質(zhì)量。圖4所示的實例與提供平均質(zhì)量增強的方法對應(yīng)，其中，首先優(yōu)先權(quán)給予提升最低比特率塊。另外ー種方法可能首先優(yōu)先考慮提升特定的塊，例如包含高運動序列的塊，其中在對質(zhì)量或者用戶體驗沒有太大影響的情況下，低運動序列以低比特率傳遞，而高運動序列要求更高的比特率用于一致的質(zhì)量。在第一實施例的系統(tǒng)中，視頻文件分割器準(zhǔn)備根據(jù)H. 264/MPEG-4AVC標(biāo)準(zhǔn)以不同格式編碼并存儲在MP4文件格式容器中的塊；每種格式都與300、600、1000或2000kbps中 的任何比特率對應(yīng)。視頻文件分割器多路復(fù)用塊以每個支持比特率地生成MPEG傳輸流塊序列。所有這些塊都被存儲在HTTP服務(wù)器中。包含支持比特率的列表、塊的數(shù)目和每個塊的大小的清単文件被發(fā)送至客戶端。然后，客戶端可以開始請求塊傳送。客戶端每隔2秒發(fā)送ー個請求，這與視頻塊的持續(xù)時間對應(yīng)。實際上，客戶端估計帶寬并請求與估計的帶寬減去保守規(guī)定(conservativeprovision)對應(yīng)的塊。因此，接收自HTTP服務(wù)器的應(yīng)答在某一時間后到達(dá)，該時間直接與塊比特率相關(guān)。一旦接收到應(yīng)答，客戶端就計算在請求下一個塊之前的剰余時間Timeleft。然后獲取它可以請求的與它想要提升的前面的塊相關(guān)的字節(jié)數(shù)目BytesMaxNum。Time left=2s_ 塊往返時間BytesMaxNum=估計帶寬(字節(jié) / 秒)*Time left (秒)然后，客戶端發(fā)送其它HTTP請求以從將要被提升的塊下載某一字節(jié)范圍。HTTP請求格式支持文件某一字節(jié)范圍的需求。然而，這要求序列化所有的HTTP請求/應(yīng)答事務(wù)(transaction)。如果HTTP事物比估計的長,那么在有危險饑餓播放器的情況下,這可能延遲下ー個塊請求。替代性地，客戶端建立第二 TCP連接。與提升塊的過程相關(guān)的HTTP請求通過第二TCP連接發(fā)送?？蛻舳税凑张c上文所述相同的過程工作?？蛻舳斯烙嫀挷⑼ㄟ^主TCP連接請求與估計的帶寬減去保守規(guī)定對應(yīng)的塊。根據(jù)給出的估計，客戶端計算它可以請求的與它想要提升的前面的塊相關(guān)的字節(jié)數(shù)目BytesMaxNum=(估計帶寬-塊比特率)*2秒客戶端可以通過第二 TCP連接并行鏈接在主連接上，可能若干請求要求與將要被提升的塊的片段對應(yīng)的字節(jié)?？蛻舳丝梢耘c主連接無關(guān)地關(guān)閉第二 TCP連接。如果體驗帶寬減少并且想優(yōu)先考慮主連接以維持平滑的回放體驗，那么這可能會發(fā)生。在本發(fā)明的第二實施例中，根據(jù)在H. 264/MPEG-4AVC Annex G中標(biāo)準(zhǔn)化的可伸縮視頻編碼(SVC)壓縮技術(shù)對塊進(jìn)行編碼。SVC定義了三個粒度參數(shù)時間可伸縮性、空間可伸縮性和信噪比(SNR)可伸縮性。根據(jù)諸如目標(biāo)多樣性或帶寬開銷這樣的準(zhǔn)則，對流進(jìn)行的編碼并不一定要求編碼成所有存在的可伸縮類型。這決定了每種可伸縮性類型的層的數(shù)目。對HTTP流傳輸，SVC內(nèi)容被存儲在文件中。SVC文件被格式化為MPEG-2傳輸流或MP4文件。尤其，這些格式允許管理用于呈現(xiàn)的定時信息。在不需要額外數(shù)據(jù)的情況下，通常生成MPEG-2傳輸流以廣播TV頻道。使用SVC 視頻廣播 TV 頻道被規(guī)定在標(biāo)準(zhǔn)“Information Technology-Generic Coding ofMoving Pictures and Audio:bystem:Transport of scalable video over ITU-Γ Rec.H. 222. 0| IS0/IEC 13818-1;Amendment 3;03/2009”中。它定義了常規(guī)電視頻道 C (ー個基本流(ES) AVC, ー個ES音頻)的節(jié)目映射表(PMT)，每個增強層“I”都有對應(yīng)的ES。MP4 文件格式存儲器被規(guī)定在有關(guān)“ Information Technology-Coding ofAudio,Pictures Multimedia and Hypermedia Information-Part 14:MP4 fileformat” 的 IS0/IEC FDIS 14496-14:2003 (E)中。它適用于在有關(guān)“InformationTechnology-Coding of audio-visual objects-Part 15:Advanced Video Coding (AVC)file format, AMENDMENT 2:File format support for Scalable Video Coding，，的 ISO/IEC 14496-15:2004/FDAM 2:2008 (E)中規(guī)定的SVC內(nèi)容。示例圖示的SVC文件格式描述可 以在論文“File Format for Scalable Video Coding:P. Amon;T. Rathgen;D. Singer; IEEETransaction on circuits&System for video Technology, vol. 17，2007 年九月”中找到。在第二實施例中，SVC編碼視頻被分割成塊。塊不僅僅包含ー個SVC樣本，而且是單個相鄰流的分段，即連續(xù)畫面的集合。因此，塊具有在下文中被稱為“塊偏移”的開始時間和在下文中被稱為“塊持續(xù)時間”的持續(xù)時間。并且，塊排列在畫面組(GOP)或整數(shù)的GOP上。通常地，塊大小的范圍是從I秒到10秒持續(xù)時間。這意味著每個塊都以關(guān)鍵幀開始。塊的內(nèi)容還與ー種可伸縮性的僅僅ー層對應(yīng)。所有的塊文件都具有相同的格式。每個塊都具有統(tǒng)ー資源標(biāo)識符(URI)。無論存儲格式(MPEG2-TS或MP4文件)是什么，SVC內(nèi)容都可以被分割成每塊的文件或者被存儲為如它在服務(wù)器上。在第一種情形中，客戶端請求URI，而在第二中，它請求時間碼或持續(xù)時間或字節(jié)偏移(從文件的開始處偏移)和字節(jié)范圍?？捎脡K在由流傳輸服務(wù)器生成并提供的播放列表中列出。這個播放列表可以指向其它播放列表，諸如每格式類型的播放列表。播放列表描述塊內(nèi)容，諸如編解碼器或所需帶寬，以及請求它們的方式。播放列表的格式可以是描述在“HTTP Live Streaming draft-pantos-http-live_streaming-02”中的格式，利用編解碼器信息擴(kuò)展以描述各種SVC層。第二實施例的系統(tǒng)與第一實施例的系統(tǒng)相似，但是在這里其內(nèi)容被編碼成SVC層而不是被編碼成不同質(zhì)量等級。尤其地，視頻文件分割器使用4個互補層(complementarylayer)對塊進(jìn)行準(zhǔn)備；1個基礎(chǔ)層和3個增強層。在第一實施例中，更高質(zhì)量的塊被發(fā)送到存儲器。在第二實施例中，所有的塊都被發(fā)送到存儲器。圖5示出了根據(jù)第二實施例的方法?？蛻舳私邮諒腸hi到chl4的塊，由未使用索引標(biāo)識出來的基礎(chǔ)層和增強層表示?；謴?fù)的塊用索引表示。這里，客戶端已經(jīng)請求與給予同時下載更多信息的機(jī)會的比特率相關(guān)的塊3?？蛻舳艘呀?jīng)使用可用帶寬請求開始時已經(jīng)被接收為基礎(chǔ)層塊的塊I的第一增強層片。當(dāng)請求塊4時相同發(fā)生；請求塊I和塊2的第ニ增強層。使用塊5，客戶端請求塊I的第三增強層。利用塊6發(fā)生相同，其中塊2的第三增強層被請求。在塊6的時間，客戶端獲得完整的使用增強層I和2提升過的序列，某些塊被使用增強層3進(jìn)ー步改善。時間進(jìn)一歩，塊3、5、6、7、8也都被提升。為了簡單，基礎(chǔ)層和增強層塊被表示成具有各自相同的大小。第二實施例展示了 SVC層的特定排列，其中增強層I依賴于基礎(chǔ)層，增強層2依賴于增強層I等等?？商娲缘兀梢允褂昧硗猢`種其中所有的增強層都依賴于基礎(chǔ)層的SVC方案。這當(dāng)然不那么靈活但生成更少的開銷。在說明書、權(quán)利要求和附圖中公開的參考可以被獨立地或以任何合適的組合提供。特征在合適的地方可以被實施為硬件、軟件或兩者的組合。本文中引用的“ー個實施例”或“實施例”是指結(jié)合該實施例描述的特定特征、結(jié)構(gòu)或特性可以被包括在本發(fā)明的至少ー種實施形式中。說明書中各個地方出現(xiàn)的詞語“在一個實施例中”并不一定都是指同一個實施例，分開或可替代性的實施例不必須相互排除其它實施例。權(quán)利要求中出現(xiàn)的參考標(biāo)號是圖示方式，并且應(yīng)該對權(quán)利要求的范圍不具有限制 性影響。
權(quán)利要求
1.一種用于在客戶端裝置接收被分割成與內(nèi)容持續(xù)時間對應(yīng)的塊的內(nèi)容的自適應(yīng)流傳輸?shù)姆椒ǎ鰤K在服務(wù)器被編碼成至少第一和第二格式，所述第二格式與比所述第一格式更好的內(nèi)容呈現(xiàn)質(zhì)量等級對應(yīng)，塊在塊接收時段期間被接收，在所述客戶端裝置，所述方法包括下列步驟 -測量所述客戶端和所述服務(wù)器之間可用于下一個塊接收時段的帶寬， -請求所述服務(wù)器發(fā)送以所述至少第一或第二格式中的任何一種編碼的塊以使得所述塊可以在所述下一個塊接收時段期間被接收，以及 -如果以所述第一格式編碼的所述塊已經(jīng)被接收并且如果一些帶寬可用于所述下一個塊接收時段，那么請求所述服務(wù)器發(fā)送以第二格式編碼的塊的一部分。
2.如權(quán)利要求I所述的方法，包括下列步驟 -接收所述塊； -將所述塊發(fā)送給呈現(xiàn)裝置。
3.如權(quán)利要求I或2所述的方法，包括將所述塊存儲在存儲器中的步驟。
4.如前述權(quán)利要求中任何一項所述的方法，包括在連續(xù)塊接收時段使用所述可用帶寬以請求以所述第二格式編碼的所述塊所有部分的步驟。
5.如權(quán)利要求4所述的方法，包括一接收到以第二格式編碼的塊的所有部分就在所述存儲器中用以第二格式編碼的所述塊替換以第一格式編碼的所述塊的步驟。
6.一種用于在客戶端裝置接收被分割成與內(nèi)容持續(xù)時間對應(yīng)的塊的內(nèi)容的自適應(yīng)流傳輸方法，所述塊在服務(wù)器根據(jù)可伸縮視頻編碼SVC技術(shù)被編碼成一個基礎(chǔ)層和至少一個增強層，塊在塊接收時段期間被接收， 在所述客戶端裝置，所述方法包括下列步驟 -測量所述客戶端和所述服務(wù)器之間可用于所述下一個塊接收時段的帶寬， -請求所述服務(wù)器發(fā)送用至少一個SVC層編碼的塊以使得所述塊可以在所述下一個塊接收時段期間被接收，以及 -如果一些帶寬可用于所述下一個塊接收時段，那么請求所述服務(wù)器發(fā)送之前在沒有至少一個增強層的情況下已經(jīng)被接收的塊的所述至少一個增強層。
7.如權(quán)利要求6所述的方法，包括下列步驟 -接收所述塊，以及 -將所述塊發(fā)送給呈現(xiàn)裝置。
8.如權(quán)利要求6或7所述的方法，包括將所述塊存儲在存儲器中的步驟。
9.如前述權(quán)利要求中任一項所述的方法，所述塊通過HTTP請求被請求。
10.一種計算機(jī)程序產(chǎn)品，其特征在于，它包括用于在計算機(jī)上執(zhí)行所述程序時執(zhí)行根據(jù)權(quán)利要求I至9的方法步驟的程序代碼指令。
全文摘要
本發(fā)明涉及一種用于在客戶端裝置接收被分割成與內(nèi)容持續(xù)時間對應(yīng)的塊的內(nèi)容的自適應(yīng)流傳輸方法，這些塊在服務(wù)器被編碼成至少第一和第二格式，第一格式與比第二格式更好的內(nèi)容呈現(xiàn)質(zhì)量等級對應(yīng)，塊在塊接收時段期間被接收。根據(jù)本發(fā)明，方法包括下列步驟測量客戶端和服務(wù)器之間可用于下一個塊接收時段的帶寬、請求服務(wù)器發(fā)送以某種格式編碼的塊以使得該塊可以在下一個塊接收時段期間被接收以及如果一些帶寬可用于下一個塊接收時段，那么請求服務(wù)器發(fā)送一部分以第二格式編碼的塊，以第一格式編碼的該塊已被接收。
文檔編號H04L29/06GK102823223SQ201180016915
公開日2012年12月12日 申請日期2011年3月31日 優(yōu)先權(quán)日2010年4月1日
發(fā)明者G.比喬特, S.高奇 申請人:湯姆森特許公司