本發(fā)明總體上涉及超文本傳輸協議(HTTP)流傳輸,且更具體地涉及用于更新HTTP內容描述的方法和設備。
背景技術:超文本傳輸協議(HTTP)流傳輸客戶端使用HTTPGET(獲得)請求來下載一個或多個媒體呈現。如在可擴展標記語言(XML)文檔(例如,3GPPSA4規(guī)范)中描述的呈現也可被稱為媒體呈現(MPD)。根據MPD,客戶端可以了解媒體內容的編碼格式(如比特率、編解碼器、分辨率、語言)。然后,客戶端基于屏幕分辨率、信道帶寬、信道接收條件、用戶的語言偏好等等中的一個或多個來選擇格式。在使用HTTP流傳輸的情況下,一次下載媒體的一部分。這對于實況內容而言是必須的,使得內容的播出不會落后于實況編碼太多。它還使客戶端能夠根據信道條件等等自適應地切換到不同的內容編碼。根據3GPPHTTP自適應流傳輸,段(segment)是在MPD中被描述了其位置(URL,并且有可能是字節(jié)范圍)的媒體的可下載部分。換言之,經由MPD向客戶端通知如何訪問段。根據3GPP,HTTP流傳輸客戶端假定使用3GPP文件格式和電影片段,其中,段包含一個或多個電影片段。3GPP文件格式以ISO/IEC14496-12ISO基本媒體文件格式為基礎。文件包括一系列稱為盒(box)的對象。盒可以包含媒體或元數據。每個盒具有關聯的盒類型(boxtype)(通常是4個字符的名稱(總共32個字節(jié)))和關聯的大小(通常是32位的無符號整數)。電影片段可以包括“moof”/“mdat”盒對?!癿oof”盒包含電影片段的元數據,而“mdat”盒包含電影片段的媒體數據。使用分段的文件使得客戶端能夠一次下載媒體的一部分,同時通過在“moof”盒中包括元數據,而不是在“moov”盒中的前部包括元數據, 來最小化啟動延遲。“moov”盒仍包含對用于編碼的編解碼器的描述,但不包含與媒體采樣有關的任何具體信息,例如定時、偏移量等。
技術實現要素:附圖說明為了更完整地理解本公開,現在結合附圖和具體實施方式來參考下述附圖描述,其中,相似的附圖標記表示類似的部分。圖1是被配置為根據本公開的客戶端來工作的無線手持設備的圖;圖2是被配置為根據本公開來工作的系統的圖;圖3是示出了被配置為根據本公開來工作的系統的消息的圖;圖4是根據本公開的用于接收經由HTTP來流傳輸的呈現的方法的流程圖;圖5是根據本公開的用于發(fā)送經由HTTP來流傳輸的呈現的方法的流程圖;以及圖6是根據本公開的媒體呈現描述的圖。具體實施方式應該意識到:為了說明的簡單和清楚,在認為合適的地方,附圖標記在附圖中可以重復,以指示對應的或類似的元素。另外,闡述了眾多的具體細節(jié),以提供對本文描述的實施例的徹底理解。然而,本領域技術人員應該了解:可以在沒有這些具體細節(jié)的情況下,實施本文描述的實施例。在其他實例中,沒有詳細描述公知的方法、過程、以及部件,以避免模糊本文所描述的實施例。此外,不應該認為本說明書限制了本文描述的實施例的范圍。對于HTTP流傳輸,經由MPD向客戶端通知媒體段的地址。MPD可以將播放列表結構或模板結構用于媒體段的地址。在利用播放列表結構的情況下,MPD將每個媒體段的統一資源定位符(URL)包含在MPD中。在利用模板結構的情況下,MPD將包含對客戶端應該如何構造URL以訪問未來將創(chuàng)建的段的描述。當將MPD的播放列表結構與實況流傳輸一起使用時,用新編碼的段的地址來更新MPD,一次更新一個或幾個。然而,客戶端控制其何時發(fā)出HTTPGET或部分GET。因此,如果客戶端已經獲取了進入實況呈現30分鐘的MPD,并且用戶想從頭觀看該呈現,則客戶端具有針對接下來的30分鐘的全部段位置??蛻舳嗽诩s30分鐘(在該時間點數據將播放完)時間內不需要下載新MPD。MPD的模板結構的特征是:客戶端不需要以規(guī)律間隔來獲取MPD。在這種情況下,通過MPD向客戶端通知如何構造URL以訪問未來將創(chuàng)建的段。對于這兩種使用情形(當模板或播放列表被使用,并且客戶端較晚收看且想從頭觀看呈現時),客戶端不需要按與段持續(xù)時間在同一量級的間隔來獲取MPD。對于這兩種使用情形,在客戶端需要由MPD所提供的新的段地址之前,其可以在例如30分鐘或更長時間的量級上。如果客戶端不需要按任何規(guī)律間隔來獲取MPD,則當HTTP流傳輸服務從一個服務器遷移到另一個服務器時,存在服務中斷的風險。HTTP流傳輸服務可能會發(fā)生中斷,除非在MPD中提供了timeShiftBufferDepth(時移緩沖深度)(在MPD中給出了其地址的媒體段的持續(xù)時間,即客戶端在任何給定時間可以訪問的內容的總持續(xù)時間)并且timeShiftBufferDepth較短,即,在分鐘或更短時間的量級上。在這種情況下,當新段被添加到MPD時,其地址可以對應于新的服務器位置,并且與舊服務器對應的段將最終落在與timeShiftBufferDepth對應的時間窗口之外。timeShiftBufferDepth是MPD中的可選參數,并且較長的時移緩沖深度有助于向客戶端給出所存儲內容的較大的時間范圍供查看和搜索。MPD還包括要求向用戶通知它們將要發(fā)生改變的特定參數。一個示例是minimumUpdatePeriod(最小更新周期),這是MPD中的可選參數。minimumUpdatePeriod向客戶端通知不會以比minimumUpdatePeriod更短的間隔來更新MPD。例如,考慮下述情形:minimumUpdatePeriod是10分鐘,并且服務器在0、10分鐘、20分鐘等時間處更新MPD。此外,客戶端在5分鐘、15分鐘和25分鐘時間處獲取MPD。如果在20分鐘處的MPD更新時,服務器將 minimumUpdatePeriod改為1分鐘,則當客戶端在25分鐘處獲取了最新的MPD時,其錯過了4個更新。盡管事實上當客戶端在15分鐘處獲取MPD時,minimumUpdatePeriod的值曾是10分鐘。服務器的更新將不會比隔10分鐘更頻繁。然而,當客戶端在10分鐘后收看時,其發(fā)現已經錯過了對MPD的4個更新。在實況流傳輸期間,基于呈現所需的段的數量,MPD可以變得很大??梢栽诜掌魃戏胖脝为毜妮^小的檢查文件,其指示是否已經發(fā)生服務遷移以及MPD中的任何參數是否已經改變。如果服務遷移已經發(fā)生,則客戶端可以下載整個MPD。在服務遷移很少發(fā)生并且下載整個MPD對于客戶端而言將是負擔沉重的情況下,該檢查文件有助于以“maximumMPDFetchInterval”(最大MPD獲取間隔)的定期間隔來檢查。MPD中提供的信息引導3GPP自適應HTTP流傳輸客戶端。當客戶端獲得更新的MPD或者客戶端驗證了從上次獲取開始MPD還沒有更新時,客戶端成功獲取MPD。MPD包括若干參數,所述參數包括:newMPDLocation(新MPD位置)、maximumMPDFetchInterval、minimumUpdatePeriodMPD(最小更新周期MPD)、以及timeShiftBufferDepth。newMPDLocation:由客戶端檢測在MPD中是否存在該參數,指示MPD的位置的改變。在先前位置和新位置都維持MPD至少等于maximumMPDFetchIInterval的持續(xù)時間。在接收具有newMPDLocation屬性的MPD之后,客戶端必須從newMPDLocation所指示的新MPD位置獲取下一個MPD。maximumMPDFetchInterval:該參數指定由客戶端進行的MPD獲取之間的最大允許時間量。換言之,maximumMPDFetchInterval是與客戶端設備接收MPD的頻率相關聯的最大獲取間隔。當maximumMPDFetchInterval存在時,客戶端在超過與該間隔相關聯的持續(xù)時間之前獲取MPD。這允許在中斷流傳輸服務的風險較小的情況下實現服務遷移和對特定MPD參數的更新。minimumUpdatePeriodMPD:該參數提供在服務器上更新MPD的 最小周期。換言之,minimumUpdatePeriodMPD與參數和段引用的更新頻率相關聯。如果minimumUpdatePeriodMPD不存在,則最小更新周期被假定為無窮大。如果minimumUpdatePeriodMPD的值減小,則在減小的值首次出現時,在MPD更新之后的至少等于maximumMPDFetchInterval的較大持續(xù)時間上,MPD更新間隔繼續(xù)遵循先前的較長值。timeShiftBufferDepth:該參數指示可用于實況呈現的時移緩沖區(qū)的持續(xù)時間。換言之,它是客戶端在任何給定時間處可以訪問的內容的總持續(xù)時間。當timeShiftBufferDepth不存在時,其值是未知的。如果針對按需服務存在該timeShiftBufferDepth,則客戶端應該忽略該屬性。如果timeShiftBufferDepth值減少,則在減小的值首次出現時,在MPD更新之后的至少等于maximumMPDFetchInterval的持續(xù)時間上,應當保持先前的較長值的時間窗口內的所有段。另外,可以使用保護間隔。保護間隔是添加到maximumMPDFetchInterval的持續(xù)時間,在此期間服務器繼續(xù)維持MPD的先前位置和任何內容段,從而避免在網絡時延拖延了客戶端獲取MPD的情況下中斷HTTP流傳輸。要求客戶端至少按maximumMPDFetchInterval的頻率來獲取新MPD將允許服務以與maximumMPDFetchInterval一樣快地從一個服務器遷移到另一個服務器。MPD可被更新,使得段位置對應于新的服務器位置。內容將在這兩個位置都存在等于maximumMPDFetchInterval的持續(xù)時間。在maximumMPDFetchInterval之后,內容創(chuàng)建者可以確信所有客戶端都已經獲取最新的MPD,并且能夠開始從原始服務器中移除那些段。備選地,可能需要服務器在兩個位置處都將那些段保持較長的持續(xù)時間,該持續(xù)時間例如等于maximumMPDFetchInterval加上保護間隔。這將允許客戶端具有一些額外的時間,因為它需要下載完整的MPD。這也允許下述情況:客戶端在持續(xù)時間maximumMPDFetchInterval已經經過之前請求MPD,而服務器直到已經過持續(xù)時間maximumMPDFetchInterval之后才接收到該請求。一個例子是在存在高網絡時延的情況下。此外,該客戶端不 一定如minimumUpdatePeriod(其可以短于maximumMPDFetchInterval)那么頻繁地獲取MPD,由此節(jié)省帶寬。存在客戶端可以初始找到MPD的多種方式,其中之一包括對瀏覽器鏈接的點擊事件。一旦客戶端有權訪問MPD,可以使用稱為newMPDLocation(即呈現描述位置)的參數來改變MPD的位置。這在服務從一個位置遷移到另一個位置時可能是需要的。例如,MPD和段本身可以位于同一服務器上。如果內容創(chuàng)建者希望將MPD的位置從一個服務器改變到另一服務器,則其可以用參數newMPDLocation(新MPD位置)來指示新MPD位置的URL。當客戶端看到MPD中指示的newMPDLocation時,則客戶端可以從newMPDLocation中指示的URL獲取所有未來的MPD。只要服務器在兩個位置都維持MPD至少等于maximumMPDFetchInterval的持續(xù)時間,則其可以確信所有客戶端現在從新位置獲取MPD。此外,與maximumMPDFetchInterval相關聯的持續(xù)時間可以進一步與保護間隔相關聯,例如,通過將兩個間隔加起來,以防止在因網絡時延減慢了通信的情況下出現服務中斷。參數maximumMPDFetchInterval自身可被更新。如果maximumMPDFetchInterval的原始值是“x”而新值是“y”,則如果在從“y”在MPD中首次出現的時間到時間“y+x”的時間間隔期間更新了任何參數或執(zhí)行了服務遷移,則服務器應該在舊服務器上保持舊的參數值或段達等于x或y中較大者的時間長度。此外,該參數maximumMPDFetchInterval可以與另一參數相關聯。一個實施例中,可以令maximumMPDFetchInterval是這樣的數:其與minimumUpdatePeriod相乘以確定客戶端獲取MPD的頻率。在一個示例中,maximumMPDFetchInterval可以是1.2,而minimumUpdatePeriod可以是10分鐘;在該情況下,客戶端將每12分鐘獲取一次MPD。在上文的描述中,客戶端拉取MPD。作為補充或替代,在諸如服務器維護客戶端狀態(tài)的情況下MPD可被推送給客戶端。在一個示例中,在一些情況下OMADM管理對象可被用于服務遷移和更新參數,而不是要求客戶端按不長于maximumMPDFetchInterval的間隔執(zhí)行對MPD的連續(xù)獲取。這可能對應于下述情況:無線運營商向客戶端設備 提供無線通信服務,并且向客戶端設備提供HTTP流傳輸服務。運營商網絡上的具有OMADM客戶端且還配置為消費HTTP流傳輸服務的所有客戶端可以使得經由管理對象從運營商的DM服務器向它們發(fā)送新參數。例如,可以使用OMADM管理對象將newMPDLocation和minimumUpdatePeriod的新值發(fā)送給客戶端,并且由客戶端接收它們。還可以發(fā)送對客戶端應該立即從特定位置獲取新MPD的指示。本公開的實施例可以使用與maximumMPDFetchInterval類似的minimumUpdatePeriod。在這種情況下,客戶端將在超過與minimumlUpdatePeriod相關聯的持續(xù)時間之前獲取MPD。在這種情況下,要求客戶至少按隔minimumUpdatePeriod的頻率獲取新MPD將允許服務與minimumUpdatePeriod一樣快地從一個服務器遷移到另一個服務器。圖1是根據本公開的一種無線手持設備的圖,該無線手持設備被配置為作為客戶端來工作。無線手持設備100包括數字鍵區(qū)101、顯示器102和一個或多個處理器(未示出)。設備100的一個或多個處理器被配置為充當HTTP流傳輸客戶端,以及執(zhí)行本公開的方法。設備100可被配置為根據包括3GPP在內的各種蜂窩電話通信標準來工作。圖2是被配置為根據本公開來工作的系統的圖。系統201包括經由網絡204可通信連接的客戶端202和服務器203??蛻舳?02可以是根據本公開的、可用于接收呈現的任何設備。其示例包括根據各種3GPP標準工作的移動電話(例如,無線手持設備100)和膝上型計算機。服務器203可以是根據本公開的、可用于發(fā)送呈現描述的任何設備。盡管服務器203被描繪成單一服務器,但是服務器203可以包括多個服務器、計算機、處理器、存儲器和數據倉庫。服務器203可以存儲MPD,并且還可以存儲具有一個或多個段的形式的呈現。備選地,所述一個或多個段可被存儲于不同的服務器、存儲器和數據庫上或者存儲在它們之間(未示出)。網絡204可以是提供在客戶端202和服務器203之間的通信的任何類型或風格的網絡。其示例包括互聯網和用于移動電話的公共無線 運營商網絡。圖3是描繪系統的消息的圖,所述系統被配置為根據本公開工作。在301,客戶端202向服務器203發(fā)送針對呈現描述(例如MPD)的內容請求,例如HTTPGET請求302。在303,服務器203從客戶端202接收針對MPD的HTTPGET請求302。在304,客戶端202從服務器203接收第一呈現描述(MPD305)。在306,服務器203向客戶端304發(fā)送第一呈現描述(MPD305)。第一呈現描述(MPD305)包括獲取間隔,所述獲取間隔確定客戶端202必須何時獲取或以其他方式接收新MPD。第一呈現描述(MPD305)還可以包括新呈現描述位置,所述新呈現描述位置確定客戶端202必須從何處獲取或以其他方式接收新MPD。MPD305還包括對與呈現關聯的一個或多個段的至少一個引用。每個段與統一資源定位符(URL)相關聯。在307,客戶端202向服務器203發(fā)送針對一個或多個段的一個或多個HTTPGET請求308。如上所述,服務器203可以包括多個服務器,使得不同的服務器可以存儲MPD和一個或多個段。在309,服務器203從客戶端202接收針對一個或多個段的一個或多個HTTPGET請求308。在310,客戶端202從服務器203接收所請求的段311。在312,服務器203向客戶端202發(fā)送段311。在客戶端202接收到第二呈現描述(例如MPD317)之前,該客戶端可以接收到一個或多個段。在313,可選地,客戶端202可以向服務器203發(fā)送針對第二呈現描述(即,更新的MPD)的HTTPGET請求314。在315,可選地,服務器203從客戶端202接收針對第二呈現描述的HTTPGET請求314。在客戶端202處經過了獲取間隔(例如maximumMPDFetchInterval)的持續(xù)時間之前,由客戶端202發(fā)送針對更新的MPD的HTTPGET請求314。在316,客戶端202從服務器203接收第二呈現描述(MPD317)。在318,服務器203向客戶端202發(fā)送第二呈現描述(MPD317)。在客戶端202沒有請求第二呈現描述(MPD317)的情況下,例如當使 用OMADM對象的情況下,在獲取間隔持續(xù)時間過去之前,服務器203發(fā)送該第二呈現描述(MPD317)。在319,客戶端202向服務器203發(fā)送針對一個或多個段的一個或多個HTTPGet請求320。在321,服務器203接收針對一個或多個段的一個或多個HTTPGET請求320。HTTPGET請求320與第二呈現描述(MPD317)一致。因此,與HTTPGET請求308相比,HTTPGET請求320可被發(fā)送給不同的服務器。此外,一個或多個HTTPGET請求308可以是僅請求段的一部分的局部HTTPGET請求。在322,客戶端202從服務器203接收段323。在324,服務器203向客戶端202發(fā)送段323。如上文討論的,發(fā)送第二呈現描述(MPD317)的服務器可以與發(fā)送段的服務器不相同。此外,這說明了在客戶端設備消費所述段中的一個或多個段之前接收到第二呈現描述(MPD317)的情形。圖4是根據本公開的用于接收經由HTTP來流傳輸的呈現的方法的流程圖。在401,HTTP流傳輸客戶端發(fā)送針對內容的請求。如上文討論的,其示例包括媒體呈現描述。在402,客戶端接收基于內容請求的MPD。媒體呈現描述包括獲取間隔,該獲取間隔指示在其結束之前客戶端應該獲取或以其他方式接收更新的MPD的持續(xù)時間。在403,可選地,客戶端可以請求更新的MPD。該請求應該由客戶端在與獲取間隔關聯的持續(xù)時間過去之前做出。在404,客戶端接收第二MPD。第二MPD是在402中接收的MPD的更新版本,但可以與在402中接收的MPD相同。圖5是根據本公開的、用于發(fā)送經由HTTP來流傳輸的呈現的方法的流程圖。在501,服務器接收針對內容的請求。如上文討論的,其示例包括媒體呈現描述。在502,服務器發(fā)送基于在501中接收的內容請求的MPD。發(fā)送的MPD包括在其結束之前應該獲取的或以其他方式向客戶端發(fā)送更新的MPD的持續(xù)時間。在503,可選地,服務器可以接收針對更新的MPD的請求。服務 器可能沒有接收到來自客戶端的請求,如在該服務器是維護客戶端狀態(tài)的OMADM服務器的情況下那樣。在504,服務器向客戶端發(fā)送第二MPD。第二MPD是在502中發(fā)送的MPD的更新版本,但有可能與在502中發(fā)送的MPD相同。發(fā)送第二MPD可以是響應于在客戶端處與獲取間隔相關聯的持續(xù)時間過去之前由客戶端發(fā)送的請求。備選地,發(fā)送第二MPD可以是在服務器處與獲取間隔相關聯的持續(xù)時間過去之前,例如在服務器維護客戶端狀態(tài)并且可以使用OMADM對象來發(fā)送第二MPD的情況下。圖6是根據本公開的媒體呈現描述的圖。MPD601包括一個或多個參數602和一個或多個段描述603。參數602包括獲取間隔。獲取間隔可以是maximumFetchInterval或minimumUpdatePeriod。另外,參數602可以同時包括maximumFetchInterval和minimumUpdatePeriod。段描述603可以具有下述形式:播放列表、模板、或兩者兼而有之。此外,段描述603可以具有提供呈現的一個或多個段的多個服務器。