專利名稱：低等待時間的可高速緩存的媒體流式傳輸?shù)闹谱鞣椒?br> 低等待時間的可高速緩存的媒體流式傳輸
背景技術(shù)：
流媒體是在被(使用服務(wù)器的)流式傳輸提供者遞送時持續(xù)地由(使用客戶端的)最終用戶接收并且通常被呈現(xiàn)給最終用戶的多媒體?，F(xiàn)有媒體流式傳輸架構(gòu)的一個問題是服務(wù)器與客戶端之間的緊密耦合?？蛻舳伺c服務(wù)器之間的有狀態(tài)的連接造成了附加的服務(wù)器開銷，因為服務(wù)器跟蹤每個客戶端的當(dāng)前狀態(tài)。這還限制了服務(wù)器的伸縮性。另外， 客戶端不能快速地對諸如下列改變中的條件作出反應(yīng)增加的分組丟失；減少的帶寬；用戶請求不同的內(nèi)容或者修改現(xiàn)有內(nèi)容(例如加速或倒帶)等等，而不是首先與服務(wù)器通信并且等待服務(wù)器進(jìn)行適應(yīng)和響應(yīng)。常常在客戶端報告較低的可用帶寬時，服務(wù)器不夠快速地適應(yīng)，從而在超過可用帶寬的分組不被接收并且新的較低比特率分組未及時地從服務(wù)器發(fā)送時導(dǎo)致客戶端上的用戶注意到媒體的中斷。為了避免這些問題，客戶端常常緩沖數(shù)據(jù)， 但是緩沖引入了等待時間，等待時間對于實況事件而言可能是不可接受的。另外，因特網(wǎng)包含許多類型的可下載的媒體內(nèi)容項目，包括音頻、視頻、文檔等等。 這些內(nèi)容項目常常非常大，比如幾百兆字節(jié)的視頻。用戶常常通過web瀏覽器使用HTTP在因特網(wǎng)上檢索文檔。因特網(wǎng)已經(jīng)建立了路由器和代理的大的基礎(chǔ)結(jié)構(gòu)，這些路由器和代理有效地對數(shù)據(jù)進(jìn)行高速緩存以用于HTTP。服務(wù)器可以以較少的延遲并且通過使用與從原始來源重新請求內(nèi)容相比更少的資源來向客戶端提供經(jīng)高速緩存的數(shù)據(jù)。例如，紐約的用戶可以下載從日本的主機所服務(wù)的內(nèi)容項目，并且通過加利福尼亞的路由器接收該內(nèi)容項目。如果新澤西的用戶請求相同的文件，則加利福尼亞的路由器可能能夠提供該內(nèi)容項目， 而不必再次從日本的主機請求該數(shù)據(jù)。這減少了通過可能緊張的路由的網(wǎng)絡(luò)通信量，并且允許新澤西的用戶以較少的延遲接收該內(nèi)容項目。遺憾的是，實況媒體常常不能使用現(xiàn)有協(xié)議來被高速緩存，并且每個客戶端都從相同的服務(wù)器或服務(wù)器組請求媒體。另外，當(dāng)流媒體可以被高速緩存時，這常常是由專用高速緩存硬件完成的、而不是由現(xiàn)有和易于獲得的基于HTTP的因特網(wǎng)高速緩存基礎(chǔ)結(jié)構(gòu)完成的。高速緩存的缺乏限制了并行觀眾的數(shù)目、以及服務(wù)器能夠處理的請求的數(shù)目，并且限制了對實況事件的出席。世界上越來越多使用因特網(wǎng)來消費最新的實況信息，比如通過因特網(wǎng)觀看諸如2008奧林匹克運動會開幕式之類的實況事件的創(chuàng)紀(jì)錄的用戶數(shù)目。當(dāng)前技術(shù)的局限性正在減緩將因特網(wǎng)用作用于消費這種類型的媒體內(nèi)容的介質(zhì)。當(dāng)期望基于因特網(wǎng)的流媒體與通過傳統(tǒng)廣播(例如衛(wèi)星)或其他系統(tǒng)發(fā)送的實況廣播密切地同步時，原始信號與信號在客戶端處重現(xiàn)的時間之間的等待時間也可能是一個問題。流媒體經(jīng)過編碼器、一個或多個服務(wù)器，以及最終轉(zhuǎn)到客戶端。沿著該路徑，可能發(fā)生引入等待時間的大量延遲。例如，編碼器可以包括其在對每個分組進(jìn)行編碼以前用信號信息來填充的緩沖區(qū)；服務(wù)器協(xié)議可以要求將關(guān)于即將到來的分組的信息放置在當(dāng)前分組中，使得服務(wù)器將分組保持得超過這些分組將被發(fā)送的最早時間；客戶端可以在回放數(shù)據(jù)以前緩沖數(shù)據(jù)(例如由于解碼器設(shè)定)；等等。這些延遲中的每個都促使了實況事件的時間與客戶端能夠查看實況事件的時間之間的等待時間。

發(fā)明內(nèi)容
在此描述了一種低等待時間的流式傳輸系統(tǒng)，該系統(tǒng)以與以前系統(tǒng)相比減少的等待時間來提供客戶端與服務(wù)器之間的無狀態(tài)協(xié)議。該服務(wù)器將遞增信息嵌入在媒體片段 (例如塊)中，所述遞增信息消除了典型控制信道的使用。另外，該服務(wù)器提供對媒體片段請求的統(tǒng)一媒體片段響應(yīng)(即請求相同片段的客戶端獲得相同的響應(yīng))，由此允許現(xiàn)有因特網(wǎng)高速緩存基礎(chǔ)結(jié)構(gòu)對流媒體數(shù)據(jù)進(jìn)行高速緩存。每個片段都具有相區(qū)別的統(tǒng)一資源定位符(URL)，所述統(tǒng)一資源定位符允許該片段被標(biāo)識出并且被因特網(wǎng)高速緩存服務(wù)器和客戶端的瀏覽器高速緩存二者高速緩存。該系統(tǒng)使用各種技術(shù)來降低等待時間，比如發(fā)送包含比完整圖像組(GOP)更少內(nèi)容的片段；在不依賴于隨后的片段的情況下對媒體進(jìn)行編碼；以及通過允許客戶端僅僅利用關(guān)于以前幀的信息來請求隨后幀。因此，低等待時間流式傳輸系統(tǒng)提供更加可伸縮的流媒體服務(wù)器而不必跟蹤客戶端狀態(tài)，并且客戶端將以較低等待時間從客戶端本地的高速緩存服務(wù)器接收媒體的可能性增加。提供本發(fā)明內(nèi)容以便以簡化形式介紹將在以下具體實施方式
中進(jìn)一步描述的一些概念。本概述并不旨在標(biāo)識出所要求保護的主題的關(guān)鍵或必要特征，也不旨在用于限定所要求保護的主題的范圍。


圖1是示出在一個實施例中的低等待時間流式傳輸系統(tǒng)的各組件的框圖。圖2是示出了一個實施例中的使用Microsoft Windows和Microsoft因特網(wǎng)信息服務(wù)器(IIS)的低等待時間流式傳輸系統(tǒng)的操作環(huán)境的框圖。圖3是示出一個實施例中的低等待時間流式傳輸系統(tǒng)從服務(wù)器處的編碼器接收媒體數(shù)據(jù)的處理的流程圖。圖4是示出一個實施例中的低等待時間流式傳輸系統(tǒng)處理用于服務(wù)器處的流媒體的客戶端連接的處理的流程圖。圖5是示出了一個實施例中的從編碼器到原始服務(wù)器的媒體片段流的數(shù)據(jù)流圖。圖6是示出一個實施例中低等待時間流式傳輸系統(tǒng)在客戶端上回放媒體的的處理的流程圖。圖7是示出一個實施例中的低等待時間流式傳輸系統(tǒng)處理單個媒體塊的處理的流程圖。
具體實施例方式在此描述了一種低等待時間流式傳輸系統(tǒng)，該系統(tǒng)以與以前系統(tǒng)相比減少的等待時間來提供客戶端與服務(wù)器之間的無狀態(tài)協(xié)議。該服務(wù)器將遞增信息嵌入在媒體片段(例如塊)中，所述遞增信息消除了典型控制信道的使用。另外，該服務(wù)器提供對媒體片段請求的統(tǒng)一媒體片段響應(yīng)(即請求相同片段的客戶端獲得相同的響應(yīng))，由此允許現(xiàn)有因特網(wǎng)高速緩存基礎(chǔ)結(jié)構(gòu)對流媒體數(shù)據(jù)進(jìn)行高速緩存。每個片段都具有相區(qū)別的統(tǒng)一資源定位符 (URL)，所述統(tǒng)一資源定位符允許該片段被標(biāo)識出并且被因特網(wǎng)高速緩存服務(wù)器和客戶端的瀏覽器高速緩存二者高速緩存。高速緩存減少了服務(wù)器的負(fù)載，并且允許更多的客戶端同時查看相同的內(nèi)容。低等待時間流式傳輸系統(tǒng)從一個或多個編碼器接收片段形式的媒體數(shù)據(jù)，創(chuàng)建每個片段的索引，并且存儲所述片段。隨著事件進(jìn)展，服務(wù)器提供客戶端所請求的片段，直到事件結(jié)束。每個片段都包含元數(shù)據(jù)信息，所述元數(shù)據(jù)信息除了片段的供客戶端回放的媒體內(nèi)容以外還描述服務(wù)器上可用的編碼以及片段的編碼。該服務(wù)器可以提供多種編碼的片段，使得客戶端例如可以基于網(wǎng)絡(luò)條件快速地切換到不同比特率或回放速度的片段。服務(wù)器還可以在每個片段內(nèi)提供如下的信息該信息允許客戶端確定該客戶端是請求數(shù)據(jù)過快還是過慢，使得該客戶端可以使其請求速率適應(yīng)于與服務(wù)器接收編碼器數(shù)據(jù)一致的節(jié)奏。因此，低等待時間流式傳輸系統(tǒng)提供更加可伸縮的流媒體服務(wù)器而不必跟蹤客戶端狀態(tài)，并且客戶端將以較低等待時間從客戶端本地的高速緩存服務(wù)器接收媒體的可能性增加。在一些實施例中，低等待時間流式傳輸系統(tǒng)在服務(wù)器與客戶端之間使用特定的數(shù)據(jù)傳輸格式?？蛻舳讼虬襟w的一部分的服務(wù)器請求媒體片段。例如，對于10分鐘的文件而言，客戶端可以請求2秒或更小的片段。注意，不同于服務(wù)器將數(shù)據(jù)推送給客戶端的典型流式傳輸，在這種情況下，客戶端從服務(wù)器拉取媒體片段。在實況流的情況下，服務(wù)器可以在進(jìn)行中創(chuàng)建媒體，并且產(chǎn)生片段來響應(yīng)客戶端請求。因此，根據(jù)服務(wù)器多快地創(chuàng)建片段以及客戶端多快地請求片段，客戶端可以僅僅落后于服務(wù)器若干片段。每個片段都包含元數(shù)據(jù)和媒體內(nèi)容。元數(shù)據(jù)可以描述諸如下列關(guān)于媒體內(nèi)容的有用信息媒體內(nèi)容被編碼的比特率；媒體內(nèi)容被放入到較大的媒體元素中的何處(例如該片段表示10分鐘的視頻剪輯中的偏移量1 10)；用于對媒體內(nèi)容進(jìn)行編碼的編解碼器； 等等。客戶端使用該信息將片段放置到較大的媒體元素的故事板中并且合適地對媒體內(nèi)容進(jìn)行解碼和回放。網(wǎng)絡(luò)分組丟失是不可避免的。它發(fā)生在公共因特網(wǎng)、DSL、電纜、無限局域網(wǎng) (WLAN)、3G無線以及許多其他種類的網(wǎng)絡(luò)上。因特網(wǎng)上的所估計的分組丟失率是5%，而某些無線網(wǎng)絡(luò)可具有超過10%的分組丟失率。諸如傳輸控制協(xié)議(TCP)等可靠的網(wǎng)絡(luò)傳輸協(xié)議將在傳輸介質(zhì)丟棄分組時重發(fā)該分組，由此保證分組傳遞。諸如不可靠數(shù)據(jù)報協(xié)議(UDP) 等不可靠協(xié)議不保證分組送達(dá)并且不重發(fā)丟棄的分組。重發(fā)分組花費時間且消耗額外的帶寬。由于視頻通信的實時特性，視頻信號通常使用不可靠協(xié)議來發(fā)送并因此將遭受網(wǎng)絡(luò)分組丟失。對于實時視頻通信，發(fā)送端點有時以每秒20到30幀或更多的速率跨網(wǎng)絡(luò)將視頻幀發(fā)送到接收端點。幀基于網(wǎng)絡(luò)所允許的最大傳輸單元(MTU)(例如，對于以太網(wǎng)是1500 字節(jié))來被分成各分組。視頻幀可以小得足以放入一個分組中，或者可以大得足以填充許多分組。對于某些視頻壓縮器/解壓縮器(編解碼器)，如果丟棄幀中的任何分組，則接收端點可能由于缺少數(shù)據(jù)而丟棄整個幀。另外，編解碼器通常使用依賴性結(jié)構(gòu)來減少發(fā)送端點通過網(wǎng)絡(luò)來傳送的視頻數(shù)據(jù)量。例如，被稱為內(nèi)(I)幀的幀基于其內(nèi)容來被完全編碼。后續(xù)幀基于與先前幀的增量(差信號)來壓縮。這些幀通常被稱為預(yù)測(P)幀。某些編解碼器引入甚至更復(fù)雜的依賴性結(jié)構(gòu)。例如，編解碼器可以偶爾發(fā)送被稱為超預(yù)測(SP)幀的指定P幀，其中與常規(guī)P幀不同， 所述SP幀不依賴于直接在前的P幀或I幀而是依賴于更舊的SP幀或I幀。這樣的SP幀的內(nèi)容通常與參考幀相關(guān)度較小并且由此攜帶更多的視頻數(shù)據(jù)。另一種類型的幀是包含與先前和后續(xù)幀兩者的增量的中間或雙向(B)幀。這些類型的幀間依賴性減少了發(fā)送端點通過網(wǎng)絡(luò)來傳送的數(shù)據(jù)量，但這些依賴性也擴大了網(wǎng)絡(luò)分組丟失的影響。例如，如果丟棄I幀， 則接收端點將缺少針對依賴該I幀的所有后續(xù)P幀的數(shù)據(jù)，并且用戶將看見視頻偽像直到下一 I幀到達(dá)。圖像組(GOP)結(jié)構(gòu)指定了內(nèi)和間幀被安排的順序。GOP是經(jīng)編碼的視頻流內(nèi)的一組連續(xù)的圖像。每個經(jīng)編碼的視頻流都包括連續(xù)的G0P。從包含在GOP中的圖像中生成可視幀。GOP以I幀開始。然后跟隨有若干P幀，其在每種情況下都具有某個幀距離。在剩余的空隙中是B幀。I幀包含了完整圖像，并且不參考任何附加的信息來重建圖像。因此， GOP結(jié)構(gòu)內(nèi)的任何錯誤都被下一 I幀糾正。GOP內(nèi)的B幀僅僅在H. 264中傳播錯誤，在H. 264 中，其他圖像可以參考B幀以便提高壓縮效率。視頻流具有越多的I幀，則該視頻是越可編輯的。然而，具有更多I幀將增加流大小。為了節(jié)省帶寬和盤空間，為因特網(wǎng)廣播準(zhǔn)備的視頻常常每GOP僅具有一個I幀。GOP結(jié)構(gòu)常常由兩個數(shù)字來指代，例如M = 3，N = 12。第一個數(shù)字說明兩個錨幀(I或P)之間的距離。第二個數(shù)字說明兩個完整圖像(I幀)之間的距離。這是GOP長度。對于示例M = 3N = 12而言，GOP結(jié)構(gòu)是IBBPBBPBBPBB。替代于 M參數(shù)，可以使用兩個相繼錨幀之間的B幀的最大計數(shù)。在一個實施例中，低等待時間流式傳輸系統(tǒng)創(chuàng)建比整個GOP包含更少內(nèi)容的片段。例如，該系統(tǒng)可以創(chuàng)建長度為一個或多個幀、但是少于完整GOP的片段。在一些情況下， 完整GOP可以表示兩秒視頻，并且等待以片段發(fā)送完整GOP可能引入兩秒或更多秒的等待時間。通過創(chuàng)建比完整GOP具有更少內(nèi)容的片段，該系統(tǒng)可以管理片段的大小以將等待時間降低到更加可接受的水平。例如，以每個都包含3幀的片段發(fā)送的每秒30幀(fps)視頻將僅僅包括可歸因于片段布局的十分之一秒的等待時間。在一些實施例中，低等待時間流式傳輸系統(tǒng)在沒有B幀的情況下對GOP進(jìn)行編碼。 由于B幀包括前向依賴性，因此B幀在流中的存在將致使客戶端上的解碼器在對B幀解碼以前等待該B幀之后的幀。例如，客戶端可以等待B幀所參考的隨后的P幀，使得其可以首先對P幀、然后對B幀進(jìn)行解碼。該延遲引入了回放等待時間。通過從經(jīng)編碼的流中消除 B幀，該系統(tǒng)去除了解碼器處的等待時間。B幀常常被用來降低用于傳送給定流質(zhì)量的帶寬。然而，在帶寬充足或者稍低的質(zhì)量是可接受的情況下，不帶B幀的編碼可以因其他可接受的折衷而減小等待時間。在一些實施例中，低等待時間流式傳輸系統(tǒng)包括下一片段請求，所述下一片段請求可以被客戶端發(fā)送給服務(wù)器以請求跟隨在所標(biāo)識出的片段之后的片段。服務(wù)器常常在發(fā)送當(dāng)前片段以前等待從編碼器接收一個或多個隨后的片段。這允許服務(wù)器將關(guān)于隨后片段的信息(比如隨后片段的相對或絕對開始時間)嵌入在當(dāng)前片段的元數(shù)據(jù)中。這允許客戶端使用所嵌入的信息直接請求隨后的片段。然而，致使服務(wù)器以這種方式保持分組將引入不必要的等待時間。通過允許客戶端請求跟隨在該客戶端已經(jīng)接收的片段之后的片段，低等待時間系統(tǒng)允許服務(wù)器避免保持片段，并且減小等待時間。該系統(tǒng)允許客戶端請求如下的特定服務(wù)器URL 所述特定服務(wù)器URL以可以經(jīng)由標(biāo)準(zhǔn)因特網(wǎng)代理使用典型HTTP或其他協(xié)議高速緩存來高速緩存的方式標(biāo)識出下一片段請求。圖1是示出在一個實施例中的低等待時間流式傳輸系統(tǒng)的各組件的框圖。低等待時間流式傳輸系統(tǒng)100包括由諸如因特網(wǎng)之類的網(wǎng)絡(luò)145連接的至少一個服務(wù)器105和至少一個客戶端150。服務(wù)器105包括注冊事件組件110、編碼器接口組件115、索引片段組件120、片段數(shù)據(jù)存儲125、客戶端接口組件130、構(gòu)建客戶端清單組件135、時鐘同步組件140。 這些組件中的每一個都在此處進(jìn)一步詳細(xì)討論。注冊事件組件110接收關(guān)于實況或其他媒體事件的信息，其中針對所述媒體事件，系統(tǒng)100將接收經(jīng)編碼的媒體數(shù)據(jù)。該信息可以包括將向服務(wù)器提供經(jīng)編碼媒體數(shù)據(jù)的每個編碼器的網(wǎng)絡(luò)地址信息或其他標(biāo)識符。該信息還包括編碼器將把經(jīng)編碼媒體數(shù)據(jù)提供給的、并且客戶端可以訪問所述媒體數(shù)據(jù)之處的URL。編碼器接口組件115提供系統(tǒng)100與提供經(jīng)編碼媒體數(shù)據(jù)的一個或多個編碼器之間的接口。所述編碼器可以使用常用網(wǎng)絡(luò)協(xié)議將數(shù)據(jù)推送給系統(tǒng)100。例如，編碼器可以使用HTTP POST請求來向系統(tǒng)100提供經(jīng)編碼的媒體數(shù)據(jù)。編碼器每個都可以使用相區(qū)別的 URL，所述URL指定作為經(jīng)編碼媒體數(shù)據(jù)的源的編碼器，其中服務(wù)器可以將所述URL與注冊事件組件110在媒體事件被注冊時接收的信息相匹配。編碼器接口組件115可以指定所接收的經(jīng)編碼媒體數(shù)據(jù)的特定格式，比如MP4或其他媒體容器(例如MKV)。MP4容器格式允許多種類型的數(shù)據(jù)被關(guān)聯(lián)在單個文件中。組成 MP4容器的各種數(shù)據(jù)被稱為盒(box)，并且每個盒通常都具有標(biāo)識出該盒中所存儲數(shù)據(jù)的類型的標(biāo)簽。編碼器可以在盒中放置元數(shù)據(jù)信息、比如用于對經(jīng)編碼媒體數(shù)據(jù)進(jìn)行編碼的編碼類型、以及經(jīng)編碼媒體數(shù)據(jù)本身。系統(tǒng)100可以將編碼器配置為降低由該系統(tǒng)產(chǎn)生的總等待時間。例如，系統(tǒng)100 可以將編碼器配置為不將B幀包括在流中，使得解碼器可以更快速地對幀進(jìn)行解碼而不必等待B幀將參考的隨后幀。另外，系統(tǒng)100可以指示編碼器產(chǎn)生包括比整個GOP更少的片段，使得編碼器可以更快速地將片段推送給服務(wù)器105。索引片段組件120創(chuàng)建和維護從各個編碼器接收的片段的索引表。由于系統(tǒng)100 在事件期間以正在進(jìn)行的基礎(chǔ)從可能許多編碼器接收媒體片段，因此系統(tǒng)100使用索引表來跟蹤什么媒體片段已經(jīng)被接收到、以及是從哪些編碼器(或者以何種格式)接收到的。每個編碼器都可以使用共同的方法來標(biāo)識出媒體片段(例如使用同步時鐘的時間戳)，使得索引片段組件120可以將來自不同編碼器的表示實況事件中的相同時間段的片段相關(guān)。通過這種方式，系統(tǒng)100可以檢測到何時缺少媒體片段并且可以向客戶端提供關(guān)于可用媒體片段的清單信息。片段數(shù)據(jù)存儲125存儲所接收的媒體片段和片段的所創(chuàng)建的索引表，以響應(yīng)于所接收的客戶端請求提供給客戶端。片段數(shù)據(jù)存儲可以包括數(shù)據(jù)庫、盤驅(qū)動器或其他形式的數(shù)據(jù)存儲(例如存儲區(qū)域網(wǎng)(SAN)或基于云的存儲服務(wù))。客戶端接口組件130接收針對媒體片段的客戶端請求，并且向客戶端提供清單數(shù)據(jù)和媒體片段。當(dāng)客戶端最初連接到系統(tǒng)100時，客戶端可以發(fā)送針對客戶端清單的請求。 客戶端接口組件130調(diào)用構(gòu)建客戶端清單組件135以基于索引表創(chuàng)建清單，所述清單包括關(guān)于從系統(tǒng)100可用的編碼、以及直到當(dāng)前時間由系統(tǒng)100所存儲的片段的信息?？蛻舳丝梢允褂迷撔畔硪撮_始請求正在進(jìn)行的實況片段、要么在時間上跳回到呈現(xiàn)的較早部分。例如如果客戶端加入已經(jīng)在進(jìn)行的實況事件并且想要趕上該事件的以前部分，則該客戶端可以使用該技術(shù)。構(gòu)建客戶端清單組件135構(gòu)建清單以滿足客戶端請求，所述清單包括關(guān)于從系統(tǒng) 100可用的編碼中的每個、以及直到當(dāng)前時間由系統(tǒng)100存儲的片段的信息。構(gòu)建客戶端清單組件135還提供與每個媒體片段包括在一起的如下清單該清單向客戶端提供關(guān)于當(dāng)前媒體片段以及可能隨后的片段的信息。通過將最初接收的清單與同每個媒體片段一起提供的隨后清單相組合，客戶端可以構(gòu)建最新清單，該最新清單包括關(guān)于從啟動直到當(dāng)前時間的媒體事件的完整信息。當(dāng)媒體事件完成時，客戶端具有媒體事件的完整故事板，該故事板可被該客戶端用于媒體事件的點播查看。在一些實施例中，客戶端接口組件130響應(yīng)針對可用片段的客戶端請求，而不必等待將包括當(dāng)前片段信息的隨后片段。客戶端可以通過參考當(dāng)前片段來請求隨后片段。例如，如果客戶端上次在時間1000請求了片段并且想要隨后的片段，則該客戶端可以發(fā)送請求以取得跟隨在時間1000的片段之后的片段。通過這種方式，服務(wù)器可以發(fā)送片段而不引入由于在發(fā)送片段以前等待隨后片段引起的附加等待時間。時鐘同步組件140同步系統(tǒng)100、客戶端和編碼器的時鐘。盡管絕對時間與系統(tǒng) 100是不相關(guān)的，但是能夠在多個編碼器的范圍內(nèi)標(biāo)識出特定片段以及向客戶端提供請求片段的速率(例如節(jié)奏)是與系統(tǒng)100相關(guān)的。例如，如果客戶端150過快地請求數(shù)據(jù)，則服務(wù)器105將還不具有該數(shù)據(jù)，并且將以錯誤響應(yīng)作出響應(yīng)(例如HTTP 404未找到錯誤響應(yīng))，從而造成許多不必要地消耗帶寬的虛假請求。另一方面，如果客戶端150過慢地請求數(shù)據(jù)，則客戶端150不能及時地具有數(shù)據(jù)以供回放，從而造成向用戶回放的媒體中的可察覺的中斷。另外，編碼器產(chǎn)生以可動態(tài)變化的編碼的媒體片段，并且可能不能提供有意義的方式來將以不同編碼表示相同時間段的兩個片段相關(guān)、以及將片段放入到媒體事件的總時間線中的何處。時鐘同步組件140通過允許服務(wù)器105、編碼器和客戶端在特定時間具有相似時鐘值來提供該信息。編碼器還可以用編碼器創(chuàng)建該片段的時間來標(biāo)記每個媒體片段。 通過這種方式，如果客戶端150請求特定的片段，則無論客戶端150選擇何種編碼，該客戶端150都將取得表示相同時間段的片段?？蛻舳?50包括塊請求組件155、塊解析組件160、清單組裝組件165、媒體回放組件170、QoS監(jiān)控組件175、以及時鐘同步組件180。這些組件中的每一個都在此處進(jìn)一步詳細(xì)討論。塊請求組件155作出客戶端對來自服務(wù)器的各個媒體塊的請求。如圖2所示，客戶端的請求可以首先經(jīng)過邊緣服務(wù)器(例如因特網(wǎng)高速緩存)，然后經(jīng)過原始服務(wù)器，并且然后經(jīng)過攝取服務(wù)器。在每個階段，如果所請求的數(shù)據(jù)被找到，則請求不進(jìn)行到下一等級。例如，如果邊緣服務(wù)器具有所請求的數(shù)據(jù)，則客戶端從邊緣服務(wù)器接收該數(shù)據(jù)，并且原始服務(wù)器不接收該請求。每個塊都具有個別化地標(biāo)識出該塊的統(tǒng)一資源定位符(URL)。因特網(wǎng)高速緩存服務(wù)器擅長于高速緩存對特定URL請求(例如HTTP GET)的服務(wù)器響應(yīng)。因此，當(dāng)?shù)谝豢蛻舳私油ǖ椒?wù)器105以獲取塊時，邊緣服務(wù)器高速緩存該塊，并且請求該同一塊的后續(xù)客戶端可以從邊緣服務(wù)器接收該塊(基于高速緩存的壽命和服務(wù)器存活時間(TTL) 設(shè)定)。塊請求組件巧5接收塊并且將其傳遞給塊解析組件160以用于解釋。塊請求組件 1550可以通過參考之前的塊來請求塊(例如給我塊N之后的塊)。塊解析組件160解釋由塊請求組件155接收的媒體塊的格式，并且將塊分成其組分部分。通常，塊包括含有元數(shù)據(jù)的報頭部分、以及含有媒體內(nèi)容的數(shù)據(jù)部分。塊解析組件將元數(shù)據(jù)提供給清單組裝組件165，并且將媒體內(nèi)容提供給媒體回放組件170。媒體內(nèi)容可以包括混合媒體類型，比如與呈現(xiàn)相關(guān)的視頻和音頻數(shù)據(jù)。
清單組裝組件165構(gòu)建描述所接收的媒體內(nèi)容所屬的媒體元素的清單。由客戶端整體下載(例如未流式傳輸)的大媒體文件常常包括清單，該清單描述整個文件、用于對文件的各個部分進(jìn)行編碼的編解碼器和比特率、關(guān)于文件內(nèi)的有意義的部分的標(biāo)記等等。在尤其是流式傳輸實況內(nèi)容期間，服務(wù)器105不能提供完整的清單，因為事件還在進(jìn)行。因此，服務(wù)器105通過媒體塊中的元數(shù)據(jù)提供其所能提供的清單那樣多的清單。服務(wù)器105 還可以提供諸如預(yù)定義URL之類的應(yīng)用編程接口(API)以供客戶端請求直到媒體流中的當(dāng)前點的清單。這在客戶端150在實況的被流式傳輸?shù)氖录呀?jīng)進(jìn)展以后加入該事件時可能是有用的。清單允許客戶端150請求媒體元素的之前被流式傳輸?shù)牟糠?例如通過倒帶)， 并且客戶端150通過被流式傳輸?shù)拿襟w塊的元數(shù)據(jù)繼續(xù)接收清單的新的部分。清單組裝組件165構(gòu)建與對完整媒體文件可用的清單類似的清單。因此，隨著事件進(jìn)行，如果用戶想要在媒體中向后跳轉(zhuǎn)(例如倒帶或跳轉(zhuǎn)到特定的位置)，然后再次向前跳轉(zhuǎn)，則用戶可以這樣做并且客戶端150使用經(jīng)組裝的清單來找出合適的一個塊或多個塊以向用戶回放。當(dāng)用戶暫停時，系統(tǒng)100可以繼續(xù)接收媒體塊(或者基于相區(qū)別的請求URL 僅僅接收塊的元數(shù)據(jù)部分)，使得清單組裝組件165可以繼續(xù)構(gòu)建清單并且在用戶結(jié)束暫停以后為任何用戶請求做好準(zhǔn)備(例如跳轉(zhuǎn)到當(dāng)前的實況位置或者從暫停位置播放)?？蛻舳藗?cè)經(jīng)組裝的清單允許客戶端150在媒體事件一結(jié)束就將該事件作為點播內(nèi)容進(jìn)行回放，以及在媒體事件進(jìn)行時在媒體事件的范圍內(nèi)跳轉(zhuǎn)。媒體回放組件170使用客戶端硬件來回放所接收的媒體內(nèi)容。媒體回放組件170 可以調(diào)用一個或多個編解碼器來解釋在其內(nèi)部的媒體內(nèi)容被傳輸?shù)娜萜鞑⑶覍⒚襟w內(nèi)容從經(jīng)壓縮的格式解壓縮或以其他方式解碼成原始格式(例如YV12、RGBA或者PCM音頻采樣)。媒體回放組件170然后可以將原始格式媒體內(nèi)容提供給操作系統(tǒng)API (例如Microsoft DirectX)以供在諸如顯示器和揚聲器之類的本地計算機系統(tǒng)聲音和視頻硬件上回放。服務(wù)器105可以通過所使用的編碼來影響客戶端150上的等待時間。例如，包括B幀的編碼可以致使客戶端在播放所接收的數(shù)據(jù)以前更長時間地緩沖該數(shù)據(jù)。通過不帶B幀地對視頻數(shù)據(jù)進(jìn)行編碼，服務(wù)器可以致使客戶端以較低等待時間來回放視頻。QoS監(jiān)控組件175分析從服務(wù)器105接收分組的成功，并且基于一組當(dāng)前網(wǎng)絡(luò)和其他條件調(diào)整客戶端的請求。例如，如果客戶端150按照慣例延遲地接收媒體塊，則QoS監(jiān)控組件175可以確定客戶端150與服務(wù)器105之間的帶寬對于當(dāng)前的比特率而言不夠，并且客戶端150可以開始請求較低比特率的媒體塊。QoS監(jiān)控可以包括其他試探法的測量、比如呈遞幀速、窗口大小、緩沖區(qū)大小、重新緩沖的頻率等等，并且然后采取合適的動作。每種比特率的媒體塊都可以具有相區(qū)別的URL，使得各種比特率的塊都由不同URL處的因特網(wǎng)高速緩存基礎(chǔ)結(jié)構(gòu)來高速緩存。注意，服務(wù)器105不跟蹤客戶端150狀態(tài)并且不知道任何特定客戶端當(dāng)前正在以何種比特率播放。服務(wù)器105可以簡單地提供各種比特率的相同的媒體元素以滿足在一定范圍的條件下的潛在客戶請求。另外，客戶端150所接收的初始清單和/或元數(shù)據(jù)可以包括關(guān)于從服務(wù)器105可用的比特率和其他編碼性質(zhì)的信息，使得客戶端150可以選擇將提供良好體驗的編碼。當(dāng)切換比特率時，客戶端150可以簡單地開始請求新的比特率并且在客戶端150 接收到塊時回放新的比特率塊。與之前的系統(tǒng)不同，客戶端150不必向服務(wù)器105發(fā)送控制信息并等待服務(wù)器105調(diào)整流?？蛻舳说恼埱笊踔量梢杂捎诳蛻舳?50與服務(wù)器105之間的滿足該請求的高速緩存而不到達(dá)服務(wù)器105。因此，客戶端150比常規(guī)媒體流式傳輸系統(tǒng)中的客戶端快得多地作出反應(yīng)，并且服務(wù)器105上具有在各種當(dāng)前條件下所連接的不同客戶端的負(fù)擔(dān)顯著減小。另外，由于當(dāng)前條件往往是局部化的，因此可能的是，處于特定地理區(qū)域中或者特定因特網(wǎng)服務(wù)提供商(ISP)上的許多客戶端將體驗類似的條件并且將請求類似的媒體編碼(例如比特率)。由于高速緩存往往也是局部化的，因此可能的是特定情況下的客戶端將感到它們附近的高速緩存“新鮮地”具有他們各自請求的數(shù)據(jù)，使得由每個客戶端體驗到的等待時間將是少的。時鐘同步組件180將客戶端時鐘與服務(wù)器時鐘同步。盡管絕對時間與客戶端和服務(wù)器在大體上是不相關(guān)的，但是能夠標(biāo)識出特定的塊以及知道請求塊的速率(例如節(jié)奏) 是與客戶端相關(guān)的。時鐘同步還給予客戶端跨許多編碼的共同參考。例如，服務(wù)器可以同時以多種比特率并且使用多種編解碼器對數(shù)據(jù)進(jìn)行編碼。每個編碼器都可以以不同方式引用經(jīng)編碼的數(shù)據(jù)，但是時間戳可以以跨所有編碼器被設(shè)置為通用。通過這種方式，如果客戶端請求特定的塊，則無論客戶端選擇何種編碼，該客戶端都將獲得表示相同時間段的媒體。在其上實現(xiàn)低等待時間流式傳輸系統(tǒng)的計算設(shè)備可包括中央處理單元、存儲器、 輸入設(shè)備(例如，鍵盤和定點設(shè)備)、輸出設(shè)備(例如，顯示設(shè)備)，以及存儲設(shè)備(例如，磁盤驅(qū)動器或其他非易失性存儲介質(zhì))。存儲器和存儲設(shè)備是可以用實現(xiàn)或啟用該系統(tǒng)的計算機可執(zhí)行指令(例如，軟件)來編碼的計算機可讀存儲介質(zhì)。此外，數(shù)據(jù)結(jié)構(gòu)和消息結(jié)構(gòu)可被存儲或經(jīng)由諸如通信鏈路上的信號等數(shù)據(jù)傳送介質(zhì)發(fā)送?？梢允褂酶鞣N通信鏈路，諸如因特網(wǎng)、局域網(wǎng)、廣域網(wǎng)、點對點撥號連接、蜂窩電話網(wǎng)絡(luò)等。該系統(tǒng)的實施例可以在各種操作環(huán)境中實現(xiàn)，這些操作環(huán)境包括個人計算機、服務(wù)器計算機、手持式或膝上型設(shè)備、多處理器系統(tǒng)、基于微處理器的系統(tǒng)、可編程消費電子產(chǎn)品、數(shù)碼照相機、網(wǎng)絡(luò)PC、小型計算機、大型計算機、包括任何上述系統(tǒng)或設(shè)備中任一種的分布式計算環(huán)境等。計算機系統(tǒng)可以是蜂窩電話、個人數(shù)字助理、智能電話、個人計算機、可編程消費電子設(shè)備、數(shù)碼相機等。該系統(tǒng)可以在由一個或多個計算機或其他設(shè)備執(zhí)行的諸如程序模塊等計算機可執(zhí)行指令的通用上下文中描述。一般而言，程序模塊包括執(zhí)行特定任務(wù)或?qū)崿F(xiàn)特定抽象數(shù)據(jù)類型的例程、程序、對象、組件、數(shù)據(jù)結(jié)構(gòu)等等。通常，程序模塊的功能可在各個實施例中按需進(jìn)行組合或分布。如上面所討論的那樣，構(gòu)建客戶端清單組件創(chuàng)建客戶端清單。以下是典型客戶端清單的示例。
< xml version=" 1.0" encoding="utf-8" ><!—Created with Expression Encoder version 2.1.1205.0~> <SmoothStreamingMedia MajorVersion="l" MinorVersion="0"
Duration= "6537916781"LookAheadFragmentCount=" 3"
IsLive="TRUE">
<StreamIndex Type="video" Subtype=nWVC 1" Chunks="327"
Url= “QualityLevels({bitrate})/Fragments(video= {start time})"> <QualityLevel Bitrate=" 1450000" FourCC="WVCl" Width="848"
Height="480" CodecPrivateData="..." /> <QualityLevel Bitrate=" 1050000" FourCC=nWVC 1" Width="592"
Height="336" CodecPrivateData="..." /> <c n="0" t=" 12345678" d="20000000" /> <c n=T t="32345678" d="20000000" /> <c n="2" t="52345678" d="20000000" /> <c n="3" t="72345678" d="20000000" /> </StreamIndex>
</SmoothStreamingMedia>客戶端清單列出了解碼信息以及服務(wù)器迄今為止已經(jīng)歸檔的所有片段的信息。總媒體片段數(shù)目和時長是僅僅針對服務(wù)器到客戶端作出該請求為止已經(jīng)歸檔的媒體片段的 (這允許客戶端快速地構(gòu)建查找欄)。對于每個媒體片段，“t”是指絕對時間戳?？蛻舳耸褂迷撝祦順?gòu)成片段URL(例如“FragmentsGideo = {start time}))。超前片段計數(shù)指示 “跟蹤片段參考盒”(Track Fragment Reference Box)將要參考的隨后片段的有針對性的數(shù)目，這在此予以進(jìn)一步描述?！盀閷崨r”(Is Live)指示實況廣播是否仍在進(jìn)行。圖2是示出了一個實施例中的使用Microsoft Windows和Microsoft因特網(wǎng)信息服務(wù)器(IIS)的低等待時間流式傳輸系統(tǒng)的操作環(huán)境的框圖。該環(huán)境通常包括源客戶端 210、內(nèi)容遞送網(wǎng)絡(luò)M0、以及外部網(wǎng)絡(luò)270。源客戶端是媒體或?qū)崨r事件的源。源客戶端包括媒體源220和一個或多個編碼器230。媒體源220可以包括相機，這些相機每個都提供多個相機角度；麥克風(fēng)捕獲音頻；幻燈片呈現(xiàn)；文本(比如來自隱藏字幕服務(wù))；圖像；以及其他類型的媒體。編碼器230并行地以一種或多種編碼格式對來自媒體源220的數(shù)據(jù)進(jìn)行編碼。例如，編碼器230可以產(chǎn)生多種比特率的經(jīng)編碼的媒體。低等待時間流式傳輸系統(tǒng)在里面進(jìn)行操作的內(nèi)容遞送網(wǎng)絡(luò)240包括一個或多個攝取服務(wù)器250和一個或多個原始服務(wù)器沈0。攝取服務(wù)器250從編碼器230接收每種編碼格式的經(jīng)編碼的媒體，并且創(chuàng)建描述經(jīng)編碼的媒體的清單。攝取服務(wù)器250可以創(chuàng)建和存儲在此描述的媒體片段，或可以在片段被請求時在進(jìn)行中創(chuàng)建片段。攝取服務(wù)器250可以比如通過HTTP POST從編碼器230、或者經(jīng)由拉取通過請求數(shù)據(jù)從編碼器230接收推送的數(shù)據(jù)。編碼器230和攝取服務(wù)器250可以以多種冗余配置來連接。例如，每個編碼器都可以將經(jīng)編碼的媒體數(shù)據(jù)發(fā)送給每個攝取服務(wù)器250或者僅僅發(fā)送給一個攝取服務(wù)器直到發(fā)生故障。原始服務(wù)器260是響應(yīng)對媒體片段的客戶端請求的服務(wù)器。原始服務(wù)器260也可以以多種冗余配置來配置。在一些實施例中，攝取服務(wù)器250包括專用于攝取編碼器媒體流的一個或多個服務(wù)器。管理員或內(nèi)容作者可以創(chuàng)建發(fā)布點，所述發(fā)布點定義攝取服務(wù)器250的客戶端可以找到特定媒體元素(例如實況事件)之處的URL。例如，使用IIS，管理員可以發(fā)布 URL"http//ingserver/pubpoint. isml”。發(fā)布點被編碼器230用于向攝取服務(wù)器250提供新媒體數(shù)據(jù)，并且被原始服務(wù)器260用于向攝取服務(wù)器250請求媒體數(shù)據(jù)。每個編碼器都可以使用相區(qū)別的URL來連接到攝取服務(wù)器250，使得攝取服務(wù)器250可以檢測相同數(shù)據(jù)的不同編碼。例如，基于上一示例中的URL，編碼器可以使用URL "http://ingserver/ pubpoint. isml/Streams (streaml)，，發(fā)送HTTP POST以將媒體數(shù)據(jù)提供給攝取服務(wù)器。攝取服務(wù)器250存儲所接收的數(shù)據(jù)以供攝取服務(wù)器250的客戶端(例如原始服務(wù)器沈0)在以后進(jìn)行檢索。POST可以包含各種類型的媒體格式，比如MP4容器。MP4容器包含稱為盒的各種類型的信息，所述盒通常被標(biāo)記有四字母的編碼，比如用于描述所使用的編碼類型的“ftyp”、以及用于包含視聽數(shù)據(jù)的“moov”。無論使用MP4還是其他容器格式，編碼器都可以向流添加附加的盒或信息，比如包含描述媒體元素的清單的“清單盒”。當(dāng)攝取服務(wù)器250接收針對數(shù)據(jù)的請求時，攝取服務(wù)器250提供較早存儲的數(shù)據(jù)。攝取服務(wù)器250可以支持若干類型的請求，包括針對標(biāo)識出可用編碼器流的編碼器流清單的請求、以及針對來自特定流的數(shù)據(jù)(包括流數(shù)據(jù)的各部分)的請求。請求的類型可以由請求的URL來標(biāo)識。例如，當(dāng)攝取服務(wù)器250接收URL“http://ingserver/pubpoint. isml/StreamManifest"時，攝取服務(wù)器250返回包含每個可用編碼器的標(biāo)識符的編碼器清單。當(dāng)攝取服務(wù)器 250 接收 URL "http //ingserver/pubpoint. isml/Streams (streaml) ” 時，攝取服務(wù)器250作為響應(yīng)而發(fā)送針對與標(biāo)識符“Encoderl”相關(guān)聯(lián)的編碼器的相應(yīng)媒體流。該響應(yīng)可以包括MP4數(shù)據(jù)，比如上述所高速緩存的“ftyp”、“清單盒”和“moov”盒，跟隨在其后的是FIFO緩沖區(qū)中的媒體片段。攝取服務(wù)器250還可以接收“httpV/ingserver/ pubpoint. isml/Streams (streaml) /StartTime (12345678) ” 形式的部分?jǐn)?shù)據(jù)請求(例如在故障轉(zhuǎn)移期間)，該請求致使攝取服務(wù)器250跳過發(fā)送“ftyp”、“清單盒”和“moov”盒并且嘗試從與指定時間戳最接近的媒體片段開始。原始服務(wù)器260從媒體客戶端接收針對媒體流的請求，并且從一個或多個攝取服務(wù)器250檢索所請求的媒體流。像攝取服務(wù)器250那樣，管理員或內(nèi)容作者注冊原始服務(wù)器上的發(fā)布點，并且然后將攝取服務(wù)器250和/或編碼器URL與該發(fā)布點相關(guān)聯(lián)。原始服務(wù)器260可以首先向攝取服務(wù)器250請求(例如使用HTTP GET請求)描述可用流的清單。 然后，原始服務(wù)器將針對每個編碼器流的單獨請求提交給攝取服務(wù)器，并且攝取服務(wù)器用從編碼器接收的所請求媒體流作出響應(yīng)。原始服務(wù)器260可以單獨地接收關(guān)于媒體流和表示該媒體流所提供的大媒體元素的一部分的媒體片段的清單信息。原始服務(wù)器260基于時間戳或由每個編碼器提供的允許原始服務(wù)器260將來自每個編碼器的數(shù)據(jù)相關(guān)的其他標(biāo)識符來構(gòu)建從每個流接收的每個片段的索引。原始服務(wù)器260可以從所接收的數(shù)據(jù)中構(gòu)建其自己的MP4容器或其他存儲格式，以此來響應(yīng)媒體客戶端請求。通過從實況事件中構(gòu)建已知格式的文件，原始服務(wù)器能夠在該事件以后快速地提供媒體文件的統(tǒng)一下載。當(dāng)原始服務(wù)器260接收到媒體客戶端請求時，原始服務(wù)器260通過將該服務(wù)器已經(jīng)構(gòu)建的索引附加到從編碼器清單接收的靜態(tài)流信息來生成客戶端清單。如果存在多個流，則原始服務(wù)器260將流清單合并到全面的客戶端清單中。這允許客戶端選擇該客戶端請求哪種編碼類型，而不必從原始服務(wù)器260獲得進(jìn)一步的信息。該服務(wù)器使用標(biāo)準(zhǔn)響應(yīng)類型將該清單提供給該客戶端，所述標(biāo)準(zhǔn)響應(yīng)類型可以由諸如HTTP響應(yīng)之類的現(xiàn)有因特網(wǎng)基礎(chǔ)結(jié)構(gòu)來高速緩存。由于清單數(shù)據(jù)可能隨時間改變，因此服務(wù)器可以對清單響應(yīng)設(shè)定短的高速緩存超時值(例如存活時間(TTL))。外部網(wǎng)絡(luò)270包括邊緣服務(wù)器280和其他因特網(wǎng)(或者其他網(wǎng)絡(luò))基礎(chǔ)結(jié)構(gòu)和客戶端四0。當(dāng)客戶端作出針對媒體片段的請求時，該客戶端向原始服務(wù)器260提出該請求。 由于網(wǎng)絡(luò)高速緩存的設(shè)計，如果邊緣服務(wù)器280之一包含該數(shù)據(jù)，則該邊緣服務(wù)器可以響應(yīng)于客戶端而不必傳遞該請求。然而，如果數(shù)據(jù)在邊緣服務(wù)器處不可用，則邊緣服務(wù)器將該請求轉(zhuǎn)發(fā)給原始服務(wù)器260之一。同樣，如果原始服務(wù)器260之一接收到對不可用數(shù)據(jù)的請求，則該原始服務(wù)器可以向攝取服務(wù)器250之一請求該數(shù)據(jù)。圖3是示出一個實施例中的低等待時間流式傳輸系統(tǒng)從服務(wù)器處的編碼器接收媒體數(shù)據(jù)的處理的流程圖。在框310中開始，該系統(tǒng)向一個或多個編碼器發(fā)送配置參數(shù)。例如，配置參數(shù)可以指示編碼器在不使用B幀的情況下對視頻進(jìn)行編碼或者定義多少幀被放置在由編碼器所發(fā)送的每個片段中。在框320中繼續(xù)，該系統(tǒng)對傳入流進(jìn)行解析以獲得描述該系統(tǒng)可以預(yù)期的所有編碼器流的流清單、以及描述對出現(xiàn)媒體數(shù)據(jù)的流可用的媒體數(shù)據(jù)的服務(wù)器清單。該系統(tǒng)可以使用拉取或推送模型來操作。例如，該系統(tǒng)可以向編碼器發(fā)送請求該編碼器的配置信息的HTTP GET請求，或者該系統(tǒng)可以簡單地作為該流的一部分從該編碼器接收該信息。在“推送”(例如編碼器POST)情況下，兩個清單都被嵌入在該流的開頭處、定制盒 (custom box)中，因此沒有請求要作出，并且該系統(tǒng)可以解析出所述清單。在“拉取”情況下(例如服務(wù)器GET)，流清單是不適用的(發(fā)布點定義包含等價的信息)，并且該系統(tǒng)嵌入該信息作為定制盒。該流清單被用于指定服務(wù)器在向下游服務(wù)器和客戶端呈現(xiàn)任何數(shù)據(jù)以前從編碼器獲取的一組流。在沒有流清單的情況下存在競爭條件，其中服務(wù)器已經(jīng)獲取了一些、但不是全部編碼器流，并且下游服務(wù)器或客戶端取得不完整的圖像。該系統(tǒng)如下意義上是“自管理的”服務(wù)器管理員不指定預(yù)期什么流，因為每個傳入編碼器流都包含提供該信息的流清單。在框330中繼續(xù)，該系統(tǒng)從每個編碼器接收編碼器清單。該系統(tǒng)將編碼器的清單合并到一起，并且存儲經(jīng)合并的清單以供有興趣了解系統(tǒng)可提供的媒體編碼的客戶端在以后進(jìn)行檢索。在一些實施例中，該服務(wù)器可以請求編碼器根據(jù)諸如編碼視頻數(shù)據(jù)之類的特定參數(shù)來產(chǎn)生數(shù)據(jù)，而不使用B幀或在每個片段中包括某個數(shù)目的幀。在框340中繼續(xù)，該系統(tǒng)從編碼器接收媒體片段。該媒體片段可以包括時間戳、對該媒體片段進(jìn)行編碼的編碼器的標(biāo)識符、以及關(guān)于該媒體片段的其他信息。通常不使用編碼器標(biāo)識符，因為該系統(tǒng)知道片段是通過什么流進(jìn)來的，并且具有關(guān)于除了該流標(biāo)識符以外哪個編碼器生成了該流的標(biāo)識信息。在框350中繼續(xù)，該系統(tǒng)對所接收的媒體片段進(jìn)行索引化，并且將索引信息添加到該系統(tǒng)所維護的索引表中，所述索引表對來自該系統(tǒng)的可用媒體片段進(jìn)行歸類。該系統(tǒng)可以使用與媒體片段相關(guān)聯(lián)的時間戳來把由不同編碼器并行產(chǎn)生的媒體片段相關(guān)。在框360中繼續(xù)，該系統(tǒng)通過將片段和索引信息存儲在數(shù)據(jù)存儲中來對所述片段進(jìn)行歸檔，其中在以后可以從所述數(shù)據(jù)存儲中檢索所述片段和索引信息以滿足客戶端請求。在框370中繼續(xù)，該系統(tǒng)通過將關(guān)于所接收的片段的信息添加到該清單來構(gòu)建服務(wù)器清單，所述服務(wù)器清單包括關(guān)于以所述媒體片段為組成部分的媒體事件的信息。該服務(wù)器在客戶端連接時將該清單提供給該客戶端以向該客戶端提供關(guān)于那時存在的從該系統(tǒng)可用的媒體片段的信息。當(dāng)該事件完成時，服務(wù)器清單包含媒體事件的完整描述，該描述可以被提供給客戶端以用于媒體事件的點播查看。在判定框380中繼續(xù)，如果系統(tǒng)從編碼器預(yù)期更多的片段(例如實況事件仍在進(jìn)行)，則該系統(tǒng)循環(huán)到框340以接收下一編碼器片段， 否則該系統(tǒng)完成。圖4是示出一個實施例中的低等待時間流式傳輸系統(tǒng)處理用于服務(wù)器處的流媒體的客戶端連接的處理的流程圖。在框410中開始，該系統(tǒng)從客戶端接收清單請求。對于實況事件，許多客戶端都可以同時連接，但是不是所有客戶端都將在該事件開始時連接。例如，如果媒體片段包含兩秒的數(shù)據(jù)，并且客戶端在該事件開始一分鐘后進(jìn)行連接，則將已經(jīng)有30個片段從該系統(tǒng)可用。該客戶端請求初始清單以確定該事件的從該系統(tǒng)可用的編碼 (其由向該系統(tǒng)提供數(shù)據(jù)的編碼器來確定)、以及關(guān)于那時存在的片段的信息。注意，服務(wù)器與客戶端之間的連接是無狀態(tài)的。服務(wù)器通常不將任何資源專用于特定客戶端。更確切地說，服務(wù)器監(jiān)聽任何傳入請求，每個請求都請求特定片段或其他信息，并且該服務(wù)器響應(yīng)該請求并且繼續(xù)移動到下一請求，而不專門跟蹤任何客戶端對服務(wù)器的請求的狀態(tài)或歷史。在框420中繼續(xù)，該系統(tǒng)基于所接收的片段以及在該系統(tǒng)最初請求編碼器清單時所接收的編碼器信息來構(gòu)建清單以滿足客戶端的請求?？蛻舳饲鍐伟o態(tài)部分，所述靜態(tài)部分是描述可用編碼的每個編碼器清單的聯(lián)合；以及動態(tài)部分，所述動態(tài)部分描述服務(wù)器迄今為止從編碼器接收的媒體片段。在框430中繼續(xù)，該系統(tǒng)響應(yīng)客戶端請求向客戶端提供所構(gòu)建的客戶端清單。在一些實施例中，該請求是標(biāo)準(zhǔn)HTTP GET請求，并且該響應(yīng)是HTTP響應(yīng)(例如2000K)。該系統(tǒng)可以對響應(yīng)提供高速緩存壽命，使得在合理時間量內(nèi)的隨后客戶端請求可以由因特網(wǎng)高速緩存基礎(chǔ)結(jié)構(gòu)進(jìn)行服務(wù)。然后，由于清單的動態(tài)部分快速地變陳舊，因此高速緩存壽命短得足以避免給客戶端留下過多陳舊的清單信息的高速緩存?；谠撉鍐?，該客戶端可以開始請求以客戶端選擇的任何編碼的片段。例如，該客戶端可以最初選擇低比特率編碼并且針對隨后的片段選擇更高的比特率編碼，直到網(wǎng)絡(luò)帶寬限制該客戶端以一定比特率接收該片段的能力。在框440中繼續(xù)，該系統(tǒng)從客戶端接收片段請求。該客戶端可以通過使用特定的 URL來標(biāo)識出該片段。該URL可以標(biāo)識出片段的時間以及編碼。例如，URL可以是“http:// server/event. isml/Quality Levels (1500000) /Fragments (video = 20000000) ” 的形式， 其中質(zhì)量等級(Quality Levels)參數(shù)是以每秒比特為度量的比特率，視頻(video)是所請求的軌道的名稱，并且跟隨在“video =”之后的值是以100納秒為單位的時間位置(單元的比例取決于呈現(xiàn)被編碼的方式)。在一些實施例中，客戶端可以通過參考上一片段來請求片段,例如替代于上一 URL中的“片段(Fragments) ”使用諸如“Next Fragments (video =20000000)”之類的URL。在框450中繼續(xù)，該系統(tǒng)通過從片段數(shù)據(jù)存儲和描述所請求片段的本地索引表中檢索清單信息來構(gòu)建遞增清單。該系統(tǒng)還可以在此處所述的遞增清單中包括一個或多個隨后片段的清單信息。在框460中繼續(xù)，該系統(tǒng)發(fā)送對客戶端片段請求的響應(yīng)，該響應(yīng)包括所請求的媒體片段和所構(gòu)建的遞增清單。基于最初清單和每個遞增清單，該客戶端可以構(gòu)建本地清單， 所述本地清單涵蓋了關(guān)于整個媒體事件的信息。該清單允許客戶端快速地在媒體事件內(nèi)四處跳轉(zhuǎn)、以及回放媒體事件的任何位置。在框470中繼續(xù)，該系統(tǒng)等待下一片段請求。在決策框480中繼續(xù)，如果接收到新的片段請求，則該系統(tǒng)循環(huán)到框440以處理該片段請求，否則該系統(tǒng)循環(huán)到框470以繼續(xù)等待。在框480之后，這些步驟結(jié)束。注意在此處所述的步驟中，平滑的流式傳輸不知道每個客戶端的狀態(tài)，并且不跟蹤客戶端的狀態(tài)。事實上，對于特定客戶端而言可能的是，該客戶端播放整個媒體事件而不曾與該系統(tǒng)交談。這之所以可能是因為，該客戶端可以從分布在整個網(wǎng)絡(luò)內(nèi)的高速緩存服務(wù)器接收每個所請求的清單以及媒體片段?？蛻舳嘶诟饕蛩貋碚埱笏鼈兿胍臄?shù)據(jù)諸如基于客戶端觀測的網(wǎng)絡(luò)條件來請求所期望的比特率；或者基于與客戶端顯示的控件的用戶交互來請求所期望的位置(例如快進(jìn)、查找、倒帶等等)。這允許服務(wù)器將資源集中于其他任務(wù)并且動態(tài)地增加縮放能力。對于上座率好的實況事件而言，這意味著多得多的觀眾可以觀看該事件。圖5是示出了一個實施例中的從編碼器到原始服務(wù)器再到客戶端的媒體片段流的數(shù)據(jù)流圖。編碼器505要么直接地、要么如在此所述那樣通過攝取服務(wù)器來將媒體數(shù)據(jù) 520連續(xù)地提供給原始服務(wù)器510。例如基于實況事件，該媒體數(shù)據(jù)可以包括MP4流的片段。 原始服務(wù)器510比如將每個媒體片段歸檔525到本地數(shù)據(jù)存儲。原始服務(wù)器510從客戶端 515接收清單請求530。原始服務(wù)器510基于最近的媒體片段信息來生成535客戶端清單。 原始服務(wù)器510將客戶端清單響應(yīng)540提供給客戶端515。然后，客戶端515發(fā)送一個或多個媒體片段請求討5，并且原始服務(wù)器510用所請求的媒體片段、以及可能還有關(guān)于隨后的媒體片段的信息來作出響應(yīng)550。只要媒體事件在進(jìn)行并且編碼器505提供新的媒體數(shù)據(jù)，則該圖左部的數(shù)據(jù)流就繼續(xù)。只要客戶端515在請求媒體片段，則該圖右部的數(shù)據(jù)流就繼續(xù)，其中該請求可能發(fā)生在媒體事件期間以及在客戶端請求媒體事件的點播觀看時發(fā)生在該事件以后。圖6是示出一個實施例中低等待時間流式傳輸系統(tǒng)在客戶端上回放媒體的的處理的流程圖。始于框610，該系統(tǒng)選擇以此從服務(wù)器請求經(jīng)編碼的媒體的初始編碼。例如， 系統(tǒng)可以最初選擇最低可用的比特率。該系統(tǒng)可能之前已經(jīng)向服務(wù)器發(fā)送了請求以發(fā)現(xiàn)可用的比特率以及其他可用編碼。在框620繼續(xù)，系統(tǒng)請求和播放特定的媒體塊，這將參考圖 7予以進(jìn)一步描述。在框630中繼續(xù)，該系統(tǒng)基于所請求的塊確定服務(wù)質(zhì)量度量。例如，塊可能包括針對服務(wù)器當(dāng)前存儲的塊那樣多的附加塊的元數(shù)據(jù)，這些塊可以被客戶端用于確定客戶端相對于服務(wù)器多快地產(chǎn)生塊而言多快地請求塊。該過程在本文中更詳細(xì)地描述。在決策框640中繼續(xù)，如果系統(tǒng)確定當(dāng)前QoS度量過低并且到服務(wù)器的客戶端連接不能處理當(dāng)前編碼，則系統(tǒng)在框650繼續(xù)，否則系統(tǒng)循環(huán)到框620以處理下一塊。在框650中繼續(xù)，系統(tǒng)選擇媒體的不同編碼，其中系統(tǒng)通過從不同URL請求數(shù)據(jù)來為來自服務(wù)器的隨后的塊選擇不同的編碼。例如，系統(tǒng)可以選擇消耗當(dāng)前編碼的一半帶寬的編碼。同樣，系統(tǒng)可以確定=QoS度量指示客戶端可以處理更高比特率編碼，并且客戶端可以為隨后的塊請求更高的比特率。通過這種方式，客戶端基于當(dāng)前條件向上和向下調(diào)節(jié)比特率。盡管圖6將QoS確定示為發(fā)生在每個塊之后，但是本領(lǐng)域的普通技術(shù)人員將認(rèn)識到，其他QoS實施方式是普遍的，比如等待固定數(shù)目的分組或塊(例如每10個分組)以作出QoS確定。在框650之后，系統(tǒng)在有塊可用的情況下循環(huán)到620以處理下一塊，或者在沒有另外的媒體可用的情況下結(jié)束(未示出)。圖7是示出一個實施例中的低等待時間流式傳輸系統(tǒng)處理單個媒體塊的處理的流程圖。在框710中開始，該系統(tǒng)基于所選的初始比特率通過網(wǎng)絡(luò)將對塊的請求從客戶端發(fā)送給服務(wù)器。例如，系統(tǒng)可以基于所選編碼來選擇請求數(shù)據(jù)的特定URL (例如http:// server/a. isml/quality/bitrate)。在框720中繼續(xù)，系統(tǒng)在客戶端處接收所請求的塊。系統(tǒng)可以從服務(wù)器或者從網(wǎng)絡(luò)上的處于服務(wù)器與客戶端之間的高速緩存接收塊。由于每個塊都是由其自己的穩(wěn)定URL來標(biāo)識的，因此塊可以由共同的因特網(wǎng)高速緩存基礎(chǔ)結(jié)構(gòu)來高速緩存。在框730中繼續(xù)，系統(tǒng)將塊解析成元數(shù)據(jù)部分和媒體數(shù)據(jù)部分。例如，每個塊都可以包含描述塊的編碼的元數(shù)據(jù)以及適于使用編解碼器和合適硬件進(jìn)行回放的媒體數(shù)據(jù)。在框740中繼續(xù)，系統(tǒng)將塊元數(shù)據(jù)添加到正在進(jìn)行的媒體清單中，該清單描述關(guān)于每個媒體數(shù)據(jù)塊所屬的較大的媒體元素的信息。例如，系統(tǒng)可以在存儲器中存儲包含來自每個媒體文件塊的元數(shù)據(jù)的清單。在框750中繼續(xù)，系統(tǒng)使用由塊元數(shù)據(jù)和客戶端的硬件所標(biāo)識出的編解碼器來播放媒體數(shù)據(jù)。媒體數(shù)據(jù)可以包括視頻、音頻、以及系統(tǒng)在包括顯示器、揚聲器等等在內(nèi)的硬件上回放的其他類型的數(shù)據(jù)?？商娲鼗蚋郊拥兀摂?shù)據(jù)可以包括與回放不同的方式被消費的非視聽數(shù)據(jù)(例如文本)，在這種情況下，該系統(tǒng)基于數(shù)據(jù)的類型作用于數(shù)據(jù)。在框750之后，這些步驟結(jié)束。在一些實施例中，低等待時間流式傳輸系統(tǒng)提供具有更多I幀的流以改善啟動時間。由于客戶端可在實況流事件期間的任何時刻加入并且由于片段可能包括比完整GOP 少的內(nèi)容，因此客戶端可以在該片段不包含I幀時的時間請求其第一個片段。這可能從觀看用戶的角度而言導(dǎo)致察覺到的等待時間，因為客戶端在接收到I幀以前一直不能回放視頻。為了減小或消除該等待時間，該系統(tǒng)可以提供如下的流該流是用較高百分比的I幀被編碼的或者甚至完全由I幀構(gòu)成。通過這種方式，客戶端可以最初請求來自該流的片段，使得保證該客戶端能夠快速地啟動媒體事件的回放。然后，一旦回放處于進(jìn)行中，則該客戶端就可以平滑地過渡到由于使用P幀而消耗更少帶寬的常規(guī)流。在一些實施例中，低等待時間流式傳輸系統(tǒng)使用高I幀流以用于快速錯誤恢復(fù)。 例如，當(dāng)在客戶端上發(fā)生解碼錯誤時，該客戶端可以快速地切換到高I幀流以獲取I幀并使解碼器復(fù)位。在需要時的特定時刻請求I幀這一能力允許客戶端快速地恢復(fù)而無需與服務(wù)器進(jìn)行任何握手。另外，由于某個地理區(qū)域中的多個客戶端可能經(jīng)歷類似的分組丟失或其他網(wǎng)絡(luò)問題，因此變得更為可能的是，處于這些客戶端附近的高速緩存將包含類似的恢復(fù)數(shù)據(jù)，使得對高I幀流的請求與服務(wù)器請求的結(jié)果相比更可能來自本地高速緩存。在一些實施例中，低等待時間流式傳輸系統(tǒng)為實況媒體流提供類似于數(shù)字錄像機 (DVR)的功能。換言之，用戶可以暫停實況流，在實況流內(nèi)查找等等，而不必給服務(wù)器增添工作或狀態(tài)跟蹤。在實況流中，存在諸如缺少畫面、暫停以中斷、在后期加入事件、打算從開始觀看等等的若干情景，這些情景由該系統(tǒng)來實現(xiàn)，從而允許用戶以各種順序以及在各個時
17間播放媒體片段。基于在此所述的經(jīng)組裝的清單，系統(tǒng)向用戶提供對他們?nèi)绾斡^看實況流的控制。如今，這些控制在電視的情況下通過DVR可用。低等待時間流式傳輸系統(tǒng)包括客戶端控件來在非實況模式下通過嘗試清單中的各個位置以及請求適當(dāng)?shù)拿襟w片段來響應(yīng)用戶動作以及管理實況流的回放。另外，客戶端可以在回放期間在實況與非實況觀看之間切換。在一些實施例中，低等待時間流式傳輸系統(tǒng)通過向客戶端提供web瀏覽器插件來操作。例如，該系統(tǒng)可以向客戶端提供Microsoft Silverlight應(yīng)用。Microsoft Silverlight接收網(wǎng)頁中對包含在稱為XAP文件的容器中的應(yīng)用的引用。Microsoft Silverlight提取XAP文件并且調(diào)用該應(yīng)用。Microsoft Silverlight給應(yīng)用提供沙箱中 (sandboxed)的安全環(huán)境以在其中運行，使得用戶的計算機系統(tǒng)被保護免受惡意或錯誤應(yīng)用代碼損害。Microsoft Silverlight提供如下的應(yīng)用編程接口(API)所述API可以由應(yīng)用以保護用戶的計算機和硬件免受可能有害的應(yīng)用動作損害的方式來調(diào)用來回放媒體。因此，Microsoft Silverlight和其他瀏覽器插件可以提供低等待時間流式傳輸系統(tǒng)預(yù)期運行在其內(nèi)的客戶端環(huán)境的所有功能。在一些實施例中，低等待時間流式傳輸系統(tǒng)提供用于試探法的插件模型以確定在特定時間使用媒體的何種編碼。例如，系統(tǒng)可以允許管理員在用于基于特定的條件(例如減小的帶寬或增加的分組丟失)來確定請求媒體塊的速率的若干策略中選擇。另外，內(nèi)容提供商可以包括其自己的試探法以用于確定要使用的編碼，并且可以在應(yīng)用包(例如 Microsoft Silverlight XAP)文件中提供試探法作為應(yīng)用模塊或應(yīng)用依賴性模塊，該應(yīng)用包由客戶端在播放期間從內(nèi)容提供商下載。在一些實施例中，低等待時間流式傳輸系統(tǒng)存儲在此所述的經(jīng)組裝的清單以供之后使用，比如在實況事件的次日回放。在實況事件期間，客戶端可能已經(jīng)基于網(wǎng)絡(luò)條件請求了各種編碼的塊。客戶端瀏覽器也可以在瀏覽器的高速緩存中包含這些塊。如果用戶請求之后回放媒體，則嘗試從本地高速緩存回放媒體是最高效的，這通常意味著客戶端請求原來播放的恰好相同的塊。通過存儲具有來自實際上已接收的每個塊的元數(shù)據(jù)的清單，客戶端可以使用之前已請求過的相同編碼連續(xù)地回放媒體。這可以使得用戶能夠在到原始服務(wù)器的連通性不可用的情況下在諸如飛機之類的情景中觀看媒體。在一些實施例中，低等待時間流式傳輸系統(tǒng)提供用于同步相關(guān)媒體流的邏輯。例如，實況視聽事件可以包括一個或多個視頻流(例如相機角度)以及一個或多個音頻流 (例如語言)。當(dāng)客戶端單獨地下載音頻和視頻媒體片段時，該客戶端通過將與每個媒體片段相關(guān)聯(lián)的時間信息對齊來同步地播放所述音頻和視頻媒體內(nèi)容，這將在此參考時鐘同步予以進(jìn)一步描述。該系統(tǒng)還可以同步其他類型的數(shù)據(jù)，比如幻燈片呈現(xiàn)中的幻燈片、圖像、 文本等等。在一些實施例中，低等待時間流式傳輸系統(tǒng)向客戶端提供以不同速率播放的流。 例如，該服務(wù)器可以包括h、5x、0.切或其他回放速度?？蛻舳丝梢郧袚Q到不同速率的流以向用戶提供媒體在快進(jìn)(例如2x)或倒帶(例如0.5x)的表現(xiàn)。為了進(jìn)行切換，客戶端簡單地請求例如處于不同URL處的不同媒體片段?？蛻舳丝梢酝ㄟ^繼續(xù)播放所接收的特定媒體片段來平滑地在以當(dāng)前速率播放媒體片段與以不同速率播放媒體片段之間切換。這向最終用戶提供無縫的體驗，其中在用戶的請求與媒體回放的改變之間幾乎沒有等待時間。這也節(jié)省了網(wǎng)絡(luò)帶寬，因為客戶端沒有為了快1倍播放媒體而2次下載數(shù)據(jù)，而是下載該媒體的大小降低的編碼，其中該編碼是以加速的速率編碼的。在一些實施例中，低等待時間流式傳輸系統(tǒng)在元數(shù)據(jù)中提供精彩場面 (Highlight)標(biāo)記。精彩場面可以包括媒體的任何感興趣的片段，比如運動事件期間運動員進(jìn)球得分的時刻?？蛻舳丝梢栽谑录呀?jīng)結(jié)束以后通過播放媒體的與精彩場面標(biāo)記相關(guān)聯(lián)的那些媒體片段來播放精彩場面卷。如果客戶端未曾接收實況事件，則客戶端可以請求媒體的清單并且然后僅僅請求與精彩場面相對應(yīng)的那些媒體片段。如果用戶想要觀看精彩場面之前或之后的更多媒體(例如由用戶快進(jìn)或倒帶來指示)，則客戶端可以請求附加的媒體片段來播放所請求的媒體部分。因此，該系統(tǒng)可以在清單中為客戶端提供精彩場面信息。在一些實施例中，低等待時間流式傳輸系統(tǒng)支持內(nèi)聯(lián)廣告。對于實況事件而言，可能在事件開始時不知道何時將出現(xiàn)廣告中斷。事件協(xié)調(diào)員可以在制片期間在該播廣告的時間按下按鈕，從而導(dǎo)致系統(tǒng)在媒體流元數(shù)據(jù)中插入廣告標(biāo)記。當(dāng)客戶端接收到廣告標(biāo)記時， 客戶端可以請求和接收與之前標(biāo)識出的廣告相關(guān)聯(lián)的媒體片段。例如，該系統(tǒng)可以在初始清單中提供潛在廣告的列表。廣告可以配備在與其他媒體類似的媒體片段內(nèi)，并且可以不存儲在提供實況事件的相同服務(wù)器處。在遇到廣告標(biāo)記時，客戶端暫停主流的回放，檢索和顯示廣告，并且然后恢復(fù)主流的回放。在一些實施例中，低等待時間流式傳輸系統(tǒng)基于訂閱或其他支付模型來確定哪些編碼可用。例如，內(nèi)容提供商可以針對實時事件的高清(HD)版本收取比該事件的標(biāo)清(SD) 版本更多的費用。在這種情況下，該系統(tǒng)可以基于是否已經(jīng)滿足支付模型的條件(例如用戶的賬戶為當(dāng)前的)來啟用或停用到特定比特率的切換。該信息可以包括在提供給該客戶端的清單中。內(nèi)容提供商可以免費提供一些編碼，比如低比特率或僅限精彩場面的媒體，而對其他編碼收費。在一些實施例中，低等待時間流式傳輸系統(tǒng)提供該系統(tǒng)的各個組件的故障轉(zhuǎn)移。 例如，該系統(tǒng)可以包括冗余編碼器、攝取服務(wù)器、原始服務(wù)器等等。在編碼器故障轉(zhuǎn)移期間， 該服務(wù)器可以將“MartTime(Imrm)(起始時間(rmrm)) ”附加到編碼器URL，其中“rmrm”是服務(wù)器成功接收到的上一片段的絕對時間戳。故障轉(zhuǎn)移URL的示例將是“http://encoder port/^tartTime (12345678)”。當(dāng)使用MP4盒時，備份編碼器不需要在其啟動該流時重發(fā) “代7 ”、“清單盒”和“!1100￥”盒。如果編碼器故障轉(zhuǎn)移導(dǎo)致缺少片段，則該服務(wù)器將在這些片段被客戶端請求的情況下返回“404-File Not Rnmd(文件未找到)”。低等待時間流式傳輸系統(tǒng)可以請求和接收多種編碼的媒體內(nèi)容。在一些實施例中，低等待時間流式傳輸系統(tǒng)使用定制MP4盒。運動圖像專家組(MPEG)版本4標(biāo)準(zhǔn)提供可以包含定制數(shù)據(jù)的格式內(nèi)的盒。MP4擴展是通常與該版本的內(nèi)容相關(guān)聯(lián)的文件格式。該系統(tǒng)可以充分利用盒來包括定制元數(shù)據(jù)和媒體內(nèi)容塊。其他媒體格式在容器內(nèi)提供類似的內(nèi)容定制，并且可以供該系統(tǒng)使用。在一些實施例中，低等待時間流式傳輸系統(tǒng)符合用于分布式超媒體系統(tǒng)的軟件架構(gòu)的代表性狀態(tài)轉(zhuǎn)移(REST)風(fēng)格的方針。REST中的一個觀點是應(yīng)用可以通過僅僅知道資源的標(biāo)識符(例如URI)以及所請求的動作來與資源交互，而不必知道是否存在高速緩存、 代理、網(wǎng)關(guān)、防火墻、隧道、或者處于應(yīng)用與服務(wù)器之間的實際上保持該信息的任何其他東西。遵循REST方針將允許系統(tǒng)受益于現(xiàn)有因特網(wǎng)基礎(chǔ)結(jié)構(gòu)和諸如高速緩存之類的預(yù)先存在的資源節(jié)省技術(shù)。一些由系統(tǒng)在一些實施例中實現(xiàn)的與REST有關(guān)的示例性原理包括每個URI都標(biāo)識出恰好一個響應(yīng)，每個URI都指向無狀態(tài)和可高速緩存的服務(wù)器資源，并且每個URI都是直觀的并且使用名詞(動詞是HTTP動詞)。具體而言，該系統(tǒng)可以避免作出使用查詢串的請求并且可以將基本上唯一的密鑰用于通過URL所請求的起始時間。
從前面的描述中可以看出，能夠理解，此處描述的低等待時間流式傳輸系統(tǒng)的特定實施例只是為了說明的目的，但是在不偏離本發(fā)明的精神和范圍的情況下，可以進(jìn)行各種修改。例如，盡管已經(jīng)在示例中使用了視聽數(shù)據(jù)，但是可以將其他類型的數(shù)據(jù)用于該系統(tǒng)，包括文本(例如流式傳輸股票報價)、幻燈片(例如呈現(xiàn))等等。因此，本發(fā)明只受所附權(quán)利要求限制。
權(quán)利要求
1.一種計算機實現(xiàn)的用于從一個或多個編碼器接收經(jīng)編碼的媒體片段的方法，該方法包括將包括參數(shù)的編碼器配置信息發(fā)送310給一個或多個編碼器以減少等待時間； 向每個經(jīng)注冊的編碼器請求320清單，所述清單描述從該編碼器可用的媒體數(shù)據(jù)； 從每個編碼器接收330編碼器清單； 從編碼器接收340媒體片段；將所接收的媒體片段索引化350并且將索引信息添加到索引表，所述索引表對可用媒體片段進(jìn)行歸類；通過將所述片段和索引信息存儲在數(shù)據(jù)存儲中來對所接收的媒體片段進(jìn)行歸檔360， 其中在以后能夠從所述數(shù)據(jù)存儲中檢索所述片段和索引信息以滿足客戶端請求；以及通過將關(guān)于所接收的片段的信息添加到所述清單來構(gòu)建370服務(wù)器清單，所述服務(wù)器清單包括關(guān)于以所述媒體片段為組成部分的媒體事件的信息； 其中，前面的步驟由至少一個處理器來執(zhí)行。
2.如權(quán)利要求1所述的方法，其特征在于，所述編碼器配置信息包括如下參數(shù)所述參數(shù)請求編碼器在沒有雙向編碼幀(B幀)的情況下對視頻進(jìn)行編碼。
3.如權(quán)利要求1所述的方法，其特征在于，所述編碼器配置信息包括如下參數(shù)所述參數(shù)請求編碼器創(chuàng)建少于完整圖像組(GOP)的片段。
4.如權(quán)利要求1所述的方法，其特征在于，所述編碼器配置信息包括如下參數(shù)所述參數(shù)請求編碼器創(chuàng)建具有預(yù)定數(shù)目的幀的片段。
5.如權(quán)利要求1所述的方法，其特征在于，所述編碼器配置信息包括如下參數(shù)所述參數(shù)請求編碼器創(chuàng)建快速起始流，所述快速起始流比至少一個其他的流包括更多的內(nèi)幀(I 幀)。
6.如權(quán)利要求1所述的方法，其特征在于，將所接收的媒體片段索引化包括標(biāo)識出在先片段的時間，使得能夠響應(yīng)于來自客戶端的參考所述在先片段的下一片段請求來提供所接收的媒體片段。
7.如權(quán)利要求1所述的方法，其特征在于，所接收的媒體片段包括時間戳，所述時間戳把由不同編碼器并行產(chǎn)生的媒體片段和對所述媒體片段進(jìn)行編碼的編碼器的標(biāo)識符相關(guān)。
8.如權(quán)利要求1所述的方法，其特征在于，還包括針對每個所接收的編碼器清單，將所述編碼器的清單合并到一起，并且存儲經(jīng)合并的清單以供客戶端在以后進(jìn)行檢索以標(biāo)識出所述系統(tǒng)能夠提供的媒體編碼。
9.一種用于遞送低等待時間可高速緩存流媒體呈現(xiàn)的計算機系統(tǒng)，該系統(tǒng)包括 處理器和存儲器，該處理器和存儲器被配置為執(zhí)行軟件指令；注冊事件組件110，所述注冊事件組件110被配置為接收關(guān)于實況媒體事件的信息，其中針對所述實況媒體事件，所述系統(tǒng)將接收經(jīng)編碼的媒體數(shù)據(jù)；編碼器接口組件115，所述編碼器接口組件115被配置為提供所述系統(tǒng)與作為媒體片段來提供經(jīng)編碼的媒體數(shù)據(jù)的一個或多個編碼器之間的接口；索引片段組件120，所述索引片段組件120被配置為創(chuàng)建和維護從編碼器接收的媒體片段的索引表；片段數(shù)據(jù)存儲125，所述片段數(shù)據(jù)存儲125被配置為存儲所接收的媒體片段和片段的所創(chuàng)建的索引表，以基于所接收的客戶端請求提供給客戶端；客戶端接口組件130，所述客戶端接口組件130被配置為接收針對媒體片段的客戶端請求、以及向客戶端提供清單數(shù)據(jù)和媒體片段；構(gòu)建客戶端清單組件135，所述構(gòu)建客戶端清單組件135被配置為構(gòu)建清單以滿足客戶端請求，所述清單包括關(guān)于從所述系統(tǒng)可用的編碼中的每個、以及直到該請求的時間為止由所述系統(tǒng)存儲的片段的信息；時鐘同步組件140，所述時鐘同步組件140被配置為同步所述系統(tǒng)、客戶端和編碼器的時鐘。
10.如權(quán)利要求9所述的系統(tǒng)，其特征在于，所述編碼器接口組件還被配置為向編碼器發(fā)送指定參數(shù)的編碼器配置信息以用于減少等待時間。
11.如權(quán)利要求9所述的系統(tǒng)，其特征在于，所述編碼器接口組件還被配置為向編碼器發(fā)送指定不具有雙向編碼幀(B幀)的編碼的配置信息。
12.如權(quán)利要求9所述的系統(tǒng)，其特征在于，所述編碼器接口組件還被配置為向編碼器發(fā)送指定如下編碼的配置信息所述編碼在由所述編碼器創(chuàng)建的每個片段中具有比完整圖像組(GOP)更少的內(nèi)容。
13.如權(quán)利要求9所述的系統(tǒng)，其特征在于，所述編碼器接口組件還被配置為向編碼器發(fā)送指定在由所述編碼器創(chuàng)建的每個片段中要包括的幀數(shù)的配置信息。
14.如權(quán)利要求9所述的系統(tǒng)，其特征在于，所述客戶端接口組件還被配置為接收針對媒體片段的客戶端請求，其中所述請求通過參考在先片段來標(biāo)識出片段。
15.如權(quán)利要求9所述的系統(tǒng)，其特征在于，所述客戶端接口組件還被配置為接收針對媒體片段的客戶端請求，其中所述請求通過指定與以前的片段相關(guān)聯(lián)的時間來標(biāo)識出片段。
全文摘要
一種低等待時間流式傳輸系統(tǒng)以減小的等待時間來提供客戶端與服務(wù)器之間的無狀態(tài)協(xié)議。該服務(wù)器將遞增信息嵌入在媒體片段中，所述遞增信息消除了典型控制信道的使用。另外，該服務(wù)器提供對媒體片段請求的統(tǒng)一媒體片段響應(yīng)，由此允許現(xiàn)有因特網(wǎng)高速緩存基礎(chǔ)結(jié)構(gòu)對流媒體數(shù)據(jù)進(jìn)行高速緩存。每個片段都具有相區(qū)別的統(tǒng)一資源定位符(URL)，所述統(tǒng)一資源定位符允許該片段被標(biāo)識出并且被因特網(wǎng)高速緩存服務(wù)器和客戶端的瀏覽器高速緩存二者高速緩存。該系統(tǒng)使用各種技術(shù)來降低等待時間，比如發(fā)送包含比完整圖像組(GOP)更少內(nèi)容的片段；在不依賴于隨后的片段的情況下對媒體進(jìn)行編碼；以及通過允許客戶端僅僅利用關(guān)于以前幀的信息來請求隨后幀。
文檔編號H04L12/56GK102577272SQ201080045546
公開日2012年7月11日 申請日期2010年10月6日 優(yōu)先權(quán)日2009年10月6日
發(fā)明者A·洛伊, J·A·博恰洛夫, J·E·弗里蘭德, K·P·杜格拉居, L·劉, N·林 申請人:微軟公司