專利名稱：用于http流傳輸?shù)拿襟w呈現(xiàn)描述增量文件的制作方法
用于HTTP流傳輸?shù)拿襟w呈現(xiàn)描述增量文件背景技術(shù)
第三代合作伙伴項(xiàng)目(3GPP)已開發(fā)出了被稱為HTTP流傳輸?shù)奶卣鳎苿?dòng)電話、個(gè)人數(shù)字助理、手持或膝上型計(jì)算機(jī)、臺(tái)式計(jì)算機(jī)、機(jī)頂盒、網(wǎng)絡(luò)裝置、以及類似設(shè)備可以借此經(jīng)由超文本傳輸協(xié)議(HTTP)來接收流傳輸媒體內(nèi)容?？梢越邮誋TTP流傳輸數(shù)據(jù)的任何設(shè)備在本文中將被稱為客戶端?？山?jīng)由HTTP向這種客戶端設(shè)備提供的內(nèi)容可以包括流傳輸視頻、流傳輸音頻、以及其他多媒體內(nèi)容。在一些情況下，準(zhǔn)備內(nèi)容，然后將其存儲(chǔ)在標(biāo)準(zhǔn) web服務(wù)器上以用于稍后經(jīng)由HTTP進(jìn)行的流傳輸。在其他情況下，可以使用實(shí)況或接近實(shí)況的流傳輸，借此在創(chuàng)建內(nèi)容時(shí)或接近創(chuàng)建內(nèi)容時(shí)上將內(nèi)容放置在web服務(wù)器上。在任一情況下，客戶端可以使用標(biāo)準(zhǔn)的web瀏覽技術(shù)在任何所需時(shí)間接收被流傳輸?shù)膬?nèi)容。


為了更完整地理解本公開，現(xiàn)在將結(jié)合附圖和具體實(shí)施方式
來參考以下

，其中，相似的附圖標(biāo)記表示相似的部分。
圖1是用于自適應(yīng)HT TP流傳輸?shù)南到y(tǒng)架構(gòu)。
圖2是根據(jù)本公開的實(shí)施例的媒體呈現(xiàn)描述文檔的示例。
圖3是根據(jù)本公開的實(shí)施例的自適應(yīng)HTTP流傳輸?shù)南到y(tǒng)架構(gòu)。
圖4a和4b示出了根據(jù)本公開的實(shí)施例的增量模式(schema)。
圖5是示出了根據(jù)本公開的實(shí)施例用于獲得媒體呈現(xiàn)描述信息的方法的流程圖。
圖6示出了適用于實(shí)現(xiàn)本公開的若干實(shí)施例的處理器和相關(guān)組件。
具體實(shí)施方式
首先應(yīng)當(dāng)理解盡管下面提供了本公開的一個(gè)或多個(gè)實(shí)施例的說明性實(shí)現(xiàn)方式， 可以使用任意數(shù)目的技術(shù)(不管是當(dāng)前已知的還是現(xiàn)有的)來實(shí)現(xiàn)所公開的系統(tǒng)和/或方法。本公開不應(yīng)以任何方式受限于包括本文所說明和描述的示例設(shè)計(jì)和實(shí)現(xiàn)方法在內(nèi)的說明性實(shí)現(xiàn)、附圖、以及下面說明的技術(shù)，而是可以在所附權(quán)利要求的范圍內(nèi)及其完全等價(jià)物的范圍內(nèi)進(jìn)行修改。
圖1示出了用于自適應(yīng)HTTP流傳輸?shù)牡湫拖到y(tǒng)架構(gòu)。在內(nèi)容準(zhǔn)備階段110中，針對(duì)HTTP流傳輸來準(zhǔn)備媒體呈現(xiàn)。然后在HTTP流傳輸服務(wù)器120上和/或可能在HTTP高速緩存130上存儲(chǔ)該內(nèi)容。HTTP流傳輸客戶端140可以使用HTTP GET請(qǐng)求或類似的消息， 以從服務(wù)器120或高速緩存130下載媒體呈現(xiàn)。
可以在可擴(kuò)展標(biāo)記語言(XML)文檔中描述媒體呈現(xiàn)，在3GPP規(guī)范中將該可擴(kuò)展標(biāo)記語言文檔稱為媒體呈現(xiàn)描述(MPD)。MH)包含向客戶端通知對(duì)媒體內(nèi)容進(jìn)行編碼所使用的格式的元數(shù)據(jù)，比如比特率、編解碼、屏幕解析度、以及語言。可以將這種參數(shù)的每個(gè)不同組合稱為內(nèi)容的表示，且多個(gè)不同的表示可以描述相同的內(nèi)容。這允許客戶端可能基于其屏幕解析度、當(dāng)前信道帶寬、當(dāng)前信道接收條件、用戶的語言偏好、以及其他參數(shù)來選擇特定的表示。
在不使用實(shí)況流傳輸?shù)那闆r下，可以向客戶端提供描述整個(gè)呈現(xiàn)的MPD，且客戶端可以貫穿該呈現(xiàn)使用MPD中的元數(shù)據(jù)。然而在實(shí)況流傳輸情況下，在開始流傳輸之前，不可能提供關(guān)于整個(gè)媒體流的元數(shù)據(jù)，因?yàn)樵獢?shù)據(jù)可能尚未已知。此外，在會(huì)話過程期間，與流傳輸會(huì)話相關(guān)的參數(shù)可以改變。例如，客戶端可以移動(dòng)到具有糟糕接收的區(qū)域中，且數(shù)據(jù)速率可慢下來。在這種情況下，客戶端可能需要切換到具有較低比特率的表示。在另一示例中，客戶端設(shè)備可以選擇將流傳輸內(nèi)容的顯示從縱向模式切換到橫向模式，在該情況下，可能要求不同的表示。
由于這些原因，不可能向客戶端提供描述整個(gè)表示的MPD。在這種情況下，可以將媒體呈現(xiàn)拆分為段，且MPD的一部分可以描述每個(gè)段。即，在使用HTTP流傳輸?shù)那闆r下，可以一次一段地下載媒體，使得實(shí)況內(nèi)容的播放并不落后實(shí)況編碼太多，且使得客戶端可以如上所述根據(jù)信道條件或其他因素自適應(yīng)地切換到不同的內(nèi)容編碼。
使用MPD中的“Url”XML元素中的信息可以對(duì)段進(jìn)行尋址。“Url”元素包含段的 URL,且可以受到“range”屬性的約束，該“range”屬性可以用于HTTP GET請(qǐng)求的Ranges 報(bào)頭?？梢砸砸?guī)律間隔來添加新的內(nèi)容段，比如每10秒，且可以在添加每個(gè)新的內(nèi)容段時(shí)向MPD添加對(duì)應(yīng)的新信息。因此，MPD的大小可以隨著內(nèi)容的流傳輸?shù)倪M(jìn)展而增長。
在圖2中示出了示例MPD，且其可以被稱為“exampleMPD. xml”。示例MPD的多個(gè)部分210各自描述了媒體呈現(xiàn)的段。為了節(jié)約圖中的空間，僅示出了兩·個(gè)這樣的部分210， 但是在實(shí)際MPD中，可以存在大量的這種部分。在本示例中，可以假定對(duì)于總共30分鐘的內(nèi)容，存在3個(gè)持續(xù)時(shí)間10分鐘的周期。每個(gè)周期包含3個(gè)不同的編碼或表示，且每個(gè)表示包含持續(xù)時(shí)間10秒的段。因此，對(duì)于周期中的每個(gè)表示，存在60個(gè)段，且總共存在540 個(gè)不同的段。exampleMPD. xml的文件大小是52千字節(jié)。對(duì)于實(shí)況媒體呈現(xiàn),每次添加新的段時(shí)(針對(duì)本示例是每10秒鐘)更新服務(wù)器上的MPD。
在本示例中，假定在周期中僅提供3個(gè)不同的內(nèi)容編碼或表示。在其它情況下，服務(wù)器可以包含更大數(shù)目的不同解析度、多個(gè)不同比特率、多種語言等。因此取代示例的3個(gè)不同編碼，數(shù)目大得多的表示可以是可用的。此外，在示例Mro中，僅描述了 30分鐘的內(nèi)容。 另一 MPD可以描述例如在長度方面是3個(gè)小時(shí)或更長的體育賽事。
在第二示例中，可以假定在MPD中描述了 15個(gè)表示以及2. 5小時(shí)的內(nèi)容。與3個(gè)表不和30分鐘內(nèi)容的第一不例相比,在服務(wù)器上存儲(chǔ)的MPD的大小乘以25 (即，5倍的表不乘以5倍持續(xù)時(shí)間的內(nèi)容)。因此，在第二示例中，將需要在服務(wù)器上存儲(chǔ)約1. 3兆字節(jié)數(shù)據(jù)(52千字節(jié)乘以25)的MPD，并每10秒提供和/或獲得該MPD。向成百的客戶端如此頻繁地提供和/或獲得這種大文件可以消耗大量的帶寬。
針對(duì)該大帶寬消耗的一種可能的解決方案可以使用壓縮應(yīng)用來壓縮MPD。然而，在實(shí)況流傳輸?shù)那闆r下，客戶端通常每10秒左右下載MPD，以發(fā)現(xiàn)最新編碼段的位置，且MPD 隨著添加到流傳輸內(nèi)容上的每個(gè)新段而增長。針對(duì)MPD的壓縮不能充分地解決增長的MPD 的問題。此外，針對(duì)每個(gè)段壓縮和解壓縮MPD的資源成本可以是巨大的。
當(dāng)更新MPD時(shí)，MH)中的大多數(shù)信息保持不變。例如，每次在周期內(nèi)添加新段時(shí)，僅向每個(gè)表示添加“UrI”元素。例如，在圖2的MPD中，存在最多540個(gè)不同的“UrI”元素， 且每10秒僅添加3個(gè)。MPD中的其他信息通常保持不變。
在實(shí)施例中，客戶端僅下載從上次MPD信息下載開始已實(shí)際改變的信息。這在圖3中示出，其中，服務(wù)器120包括描述了從服務(wù)器120可獲取的媒體呈現(xiàn)的MPD310?？蛻舳?140也包括MPD320，且客戶端MPD320應(yīng)當(dāng)與服務(wù)器的MPD310同步，使得客戶端140具有關(guān)于媒體呈現(xiàn)的最新信息。創(chuàng)建包括從上一次MPD更新開始已改變的信息在內(nèi)的增量文件 330 (可能由內(nèi)容提供方來創(chuàng)建)。無論何時(shí)向呈現(xiàn)添加新段，每次添加新段時(shí)，客戶端140 可以下載增量文件330，而不是下載整個(gè)MPD。S卩，一旦客戶端140已下載了整個(gè)MPD310，無論何時(shí)更新增量文件330時(shí)，客戶端140可以僅下載增量文件330。
在實(shí)施例中，服務(wù)器120是符合HTTP1.1或更高的標(biāo)準(zhǔn)web服務(wù)器。即，服務(wù)器 120不具有諸如XML配置訪問協(xié)議(XCAP)功能或會(huì)話發(fā)起協(xié)議(SIP)功能之類的能力。
XML路徑語言(XPath)是由萬維網(wǎng)聯(lián)合會(huì)(W3C)定義的用于定義XML文檔的各部分的語言。RFC5261描述了針對(duì)使用XPath選擇符的XML文檔的“補(bǔ)丁”或改變的元素模式類型。在RFC5261中定義的“補(bǔ)丁”是〈add〉(添加)、〈replace> (替換)、以及〈remove〉(移除)。這些“補(bǔ)丁”可以用于描述對(duì)元素或?qū)傩缘母淖?。這些元素模式類型可以在描述 XML “增量文件”(描述針對(duì)XML文檔的改變的XML文件)的XML模式中使用。在實(shí)施例中，因此有可能向客戶端描述僅在針對(duì)MH)的最新更新中改變的內(nèi)容。剛剛調(diào)入(tune in) 的客戶端可以依然下載完整的MPD。然而，其他客戶端可以僅下載增量文件，以發(fā)現(xiàn)在最新更新之后已改變了什么。MH)本身可以包含對(duì)MH)可能被更新的頻率進(jìn)行指示的“最小更新”(minimum update)持續(xù)時(shí)間。因此如果每10秒更新MPD,則客戶端將在其首次調(diào)入時(shí)下載完整的MPD，且之后可以僅下載增量文件。有可能創(chuàng)建若干類型的增量文件。在其他實(shí)施例中，可以使用除了 XPath之外的語言來識(shí)別MPD中的點(diǎn)。
以下是XPath表達(dá)式的示例，其指示具有239K帶寬的周期3的表示中的URL元素所附加到的元素
/Period[3]/*[Obandwidth =， 239000’ ]/SegmentInfo]
因此在針對(duì)該ΜΗ)添加了最后段的“Url”元素之后，可以使用例如RFC5261的補(bǔ)丁操作來對(duì)此進(jìn)行描述，例如使用以下語法
〈add sel = " //Period[3] /Representation [ibandwidth = 1 239000 1 ] SegmentInfo" XUrl
sourceURL = " p3repl. 3gp" range = " 17642842-17943394" /></add>
在本示例中，“增量”文件由3個(gè)部分構(gòu)成。由“add”元素來指示針對(duì)MPD的改變由添加的東西來構(gòu)成這一事實(shí)?！皊el”屬性指示要在何處添加元素。換言之，“ sel”屬性的值是對(duì)要在MPD中的何處添加元素進(jìn)行指示的XPath表達(dá)式。在該情況下，將其添加為 SegmentInfo的最后子節(jié)點(diǎn)。添加的元素是〈add〉元素內(nèi)的文本。因此，作為示例，可以用以下3個(gè)增量表達(dá)式來描述對(duì)MPD進(jìn)行的改變
AppendElement//Period[3]/Representation[@bandwidth='239000']/Segirientlntb/Url[last()]<Url sourceURL="p3rep 1.3gp" range=" I 7642842-179433947〉A(chǔ)ppendElement//Period[3]/Representation[@bandwidth='478000']/Segirientlntb/Url[last()]<Url sourcelIRL="p3rep2.3gp" range="35284728-35885833"/>AppendElement//Period[3]/Representation[@bandwidth='892000']/Seginentlnfo/Url[last()]<Url sourceURL="p3rep3.3gp" range="658443 I 7-66966044"/>
備選地，作為另一示例，可以用以下XML語言來描述對(duì)MPD進(jìn)行的改變
<add sel=”//Period[3]/*[@bandwidth='239000']Segmentlnfo”><Url sourceURL="p3rep 1.3gp" range=" 17642842-17943394n/></'add>
〈add sel=7/l)eriod[3]/*[@bandwidth='478000']Segmentlnfo”><Url sourceURL="p3rep2.3gp" range="35284728-35885833"/></add><add sel=7/l)eriod[3]/*[@bandwidth='892000']Segmentlnfo"><Url sourceURL.="p3rep3.3gp" range=M658443 17-669660447></add>
在該情況下,“ sel ”屬性包含XPath表達(dá)式，且〈add〉元素內(nèi)的文本包含添加到MPD 的元素。
上述第二示例具有362字節(jié)的總大小。因此取代圖2的示例中每個(gè)客戶端必須下載或接收每10秒52千字節(jié)級(jí)別的東西，現(xiàn)在每個(gè)客戶端僅必須下載或接收362字節(jié)。這小于該大小的百分之一，且因此在帶寬方面有效率得多。這也可以通過讓客戶端不必須每 10秒進(jìn)行壓縮和解壓縮來節(jié)約計(jì)算資源。
通過與客戶端確定 MPD的位置相同的方式，客戶端可以獲得增量文件的位置。備選地，可以在MPD中引用增量文件位置。可以存在一個(gè)增量文件或多個(gè)順序編號(hào)的增量文件。
在實(shí)施例中，Mro可以包括指示MPD支持使用增量文件的指示符。即，為了利用增量文件，客戶端可能需要知道增量文件可用?？梢酝ㄟ^MPD中的指示符讓客戶端意識(shí)到該事實(shí)。例如，MPD中的元素可以指示正在使用增量文件來描述針對(duì)MPD的更新。元素的屬性可以指示存儲(chǔ)了多少個(gè)增量文件、增量文件的名稱、更新增量文件的頻率、和/或其他信息。如下所述，在其他實(shí)施例中，指示符可以通過某種其他形式指示更新可用。
客戶端具有了解其已錯(cuò)過了增量更新的各種手段。MH)可以包含對(duì)MPD可能被更新的頻率進(jìn)行指示的“最小更新”持續(xù)時(shí)間。如果在MPD中描述了最小更新持續(xù)時(shí)間，則客戶端知道將不會(huì)比該持續(xù)時(shí)間更頻繁地更新MPD，且客戶端不需要以比該持續(xù)時(shí)間更大的頻率來搜索增量文件。因此，如果每10秒更新MPD，客戶端在其首次調(diào)入時(shí)將下載完整的MPD,并在之后將每10秒僅下載增量文件。如果客戶端繼續(xù)每10秒下載增量文件，客戶端可以確保其并未錯(cuò)過增量文件。
備選地，在更新MPD的同時(shí)，可以在服務(wù)器上讓增量文件對(duì)于客戶端可用。如果客戶端以minimumUpdatePeriod(最小更新周期)的頻率來進(jìn)行更新,則其知道其將不會(huì)錯(cuò)過增量文件更新。此外，可以存儲(chǔ)之前版本的增量文件，使得客戶端不需要以最小更新頻率來請(qǐng)求增量文件。例如，增量文件可以具有文件名delta, xml?？梢栽赿elta-1, xml中存儲(chǔ) delta, xml的之前版本,且可以在名為delta-2. xml的文件中存儲(chǔ)deltal. xml的之前版本。 delta, xml (且從而delta-l. xml和delta-2. xml)包含序列號(hào)，使得客戶端可以知道其是否錯(cuò)過了版本。因此，如果客戶端要以兩倍的minimumUpdatePeriod來下載增量文件,其可以確保不會(huì)存在針對(duì)MPD的多于2個(gè)不同更新，但是其不能肯定地知道是否存在O、1、或2個(gè)更新。增量文件中的序列號(hào)可以提供該指示。
備選地，在另一實(shí)施例中，可以向增量文件給予順序編號(hào)的文件名，且客戶端可以確認(rèn)其尚未錯(cuò)過序列中的號(hào)碼。例如，為了讓客戶端利用增量文件的概念而無需每10秒 (或最小更新持續(xù)時(shí)間碰巧是的任何時(shí)間)調(diào)入，可以創(chuàng)建多個(gè)增量文件。例如，如果最小更新碰巧是10秒，則“delta_10”可以是對(duì)在最新版本的MPD中相對(duì)于前一版本的MPD改變了什么進(jìn)行指定的增量文件，“delta_20”可以是對(duì)在最新的兩個(gè)版本的MPD中改變了什么進(jìn)行指定的增量文件，且依此類推。如果客戶端想要每10秒更新的增量文件，則客戶端可以下載delta_10文件，如果客戶端想要每20秒更新的增量文件，則客戶端可以下載 delta_20文件，且依此類推。此外，如果例如客戶端意識(shí)到其錯(cuò)過了 delta_10文件，則客戶端可以下載delta_20文件，且依然保持與服務(wù)器上的MH)的同步。可以使用標(biāo)準(zhǔn)的命名慣例，或可以在MPD中放置文件的名稱。
在另一備選實(shí)施例中，可以向增量文件給予不同版本號(hào)、版本名稱、或序列號(hào)，這些不同版本號(hào)、版本名稱或序列號(hào)指示該增量文件表示多個(gè)更新中的哪個(gè)更新。在該情況下，將不一定需要以周期方式來創(chuàng)建增量文件。例如，可以向增量文件給予以下名稱針對(duì)原始MPD的第一修訂的“revisionl”,針對(duì)包括從“revisionl”開始的所有更新在內(nèi)的修訂的“revision2”,針對(duì)包括從“revision2”開始的所有更新在內(nèi)的修訂的“revision3”,且依此類推。將不一定以以下間隔來產(chǎn)生修訂與MH)所描述的內(nèi)容被更新的間隔相對(duì)應(yīng)的間隔。即，如果每10秒添加新的內(nèi)容段，則可以按某個(gè)其他周期間隔來創(chuàng)建增量文件，或可以在沒有·任何規(guī)律性周期的情況下創(chuàng)建增量文件。如果客戶端希望更新其MPD，客戶端可以僅下載修訂號(hào)比其下載的最新增量文件的修訂號(hào)更大的所有增量文件。客戶端將不需要以任何規(guī)律的頻率來下載增量文件。
在實(shí)施例中，如果客戶端由于任何原因而未能獲得增量文件，客戶端可以再次下載整個(gè)MPD。之后，客戶端可以恢復(fù)僅下載增量文件。
盡管AddElement和DeleteElement命令可以描述最常用的增量(如向 Mro添加或從Mro刪除段描述)，很多其他的命令也是可能的。例如，AddSibling, AddChilcU AddParent> DeleteSibling、DeleteChilcU DeleteParent、AddAttribute、 RepIaceAttribute> RemoveAttribute 等等。
作為使用增量文件的備選，可以在MPD的頂部或底部附近放置〈delta〉標(biāo)簽，使得客戶端可以使用部分GET或類似消息，以僅下載MPD的一部分。即，可以在開始(opening)和結(jié)束(closing)〈delta〉標(biāo)簽之間放置從MPD的上一次更新開始在MTO中已改變的信息。 然后客戶端可以僅檢索在增量(delta)標(biāo)簽內(nèi)的信息，并可以忽略MPD的其余部分。
HTTP自適應(yīng)流傳輸當(dāng)前受到客戶端控制，且如上所述，服務(wù)器是標(biāo)準(zhǔn)web服務(wù)器。 然而，在將來，服務(wù)器可以包括附加功能。因此，在實(shí)施例中，客戶端可以首先下載MPD，然后可以由服務(wù)器向客戶端推送具有增量文件形式或某種其他形式的更新，而不是客戶端向服務(wù)器檢查更新。
在服務(wù)器具有附加功能的另一實(shí)施例中，取代客戶端使用“增量”方案和XPath的組合來訪問MPD，可以使用XCAP向客戶端提供MPD。在該情況下，將不需要準(zhǔn)備增量文件。 取而代之地，可以向MPD中的每個(gè)元數(shù)據(jù)段給予可預(yù)測的或已知的標(biāo)識(shí)符或序列號(hào)?？蛻舳丝梢灾苯釉L問支持XCAP的服務(wù)器上的MPD文件，并使用XCAP GET來指向MPD中在客戶端下載的最新元素之后的元素。然后客戶端可以取回在該點(diǎn)開始的指定數(shù)目的元素。在 RFC4825中描述用于訪問XML文檔的XCAP機(jī)制。備選地，服務(wù)器可以使用基于XCAP的消息向客戶端推送MPD更新。
在服務(wù)器具有附加功能的另一備選中，可以使用預(yù)訂/通知模型向客戶端通知針對(duì)MPD的改變。即，客戶端可以預(yù)訂被通知針對(duì)MPD的改變，且服務(wù)器可以在改變發(fā)生時(shí)向客戶端通知任何改變?？梢允褂肧IP SUBSCRIBE/SIP :N0TIFY或使用XDCP (XML文檔命令協(xié)議)來實(shí)現(xiàn)預(yù)訂/通知模型，其是針對(duì)基于HTTP的SIP的備選機(jī)制。在OMA XDM (XML文檔管理)2.1使能器規(guī)范中描述了這些機(jī)制。為了支持這些機(jī)制，要求針對(duì)MPD的應(yīng)用使用， 以在XDM服務(wù)器中容留MPD文件。且如該應(yīng)用使用中所規(guī)定的，需要在能夠訪問并預(yù)訂MPD 文件的UE (用戶設(shè)備)上實(shí)現(xiàn)XDM客戶端。
在服務(wù)器具有附加功能的任何這些備選中，可以在MPD中包括指示符，以指示服務(wù)器支持使用針對(duì)MPD的更新。即，類似于上述指示支持增量文件的指示符，指示符可以指示服務(wù)器具有向客戶端推送Mro更新的能力、使用XCAP向客戶端提供Mro更新的能力、使用預(yù)訂/通知模型向客戶端通知MPD更新的能力、或用于向客戶端提供MPD更新的其他能力。然后客戶端可以具有下面的恰當(dāng)功能解釋指示符并采取恰當(dāng)動(dòng)作來接收MPD的更新， 而不接收整個(gè)MPD。
圖4a和4b示出了可以用于上述增量文件的增量模式的示例。
圖5示出了用于獲得媒體呈現(xiàn)描述信息的方法500的實(shí)施例。在步驟510處，客戶端獲得與服務(wù)器上的第一 MH)中的改變相關(guān)的信息。在步驟520，客戶·端使用該與改變相關(guān)的信息來更新客戶端上的第二 MPD。
總之，可以向MPD添加元素，以指示對(duì)增量文件的支持。向MPD添加的元素的名稱可以是“delta”。元素“delta”可以包含名為“numberOfStoredDeltas”的屬性,其取正整數(shù)值。增量文件的名稱可以是“delta, xml”，且其之前版本可以是“delta-1, xml”。“delta-1. xml”的之前版本可以是“delta-2. xml”等等。因此,如果屬性“numberOfStoredDeltas”的值是“3”,則客戶端知道在服務(wù)器上存在文件delta. xml> delta-1, xml和delta-2. xml。
此外，圖4中的模式可以用于增量文件。任何〈add〉、〈replace〉、或〈remove〉 中的“sel”屬性的值可以是有效的XPath表達(dá)式。模式包含指示要使用的XPath的版本的屬性“xpathVersion”。缺省值是“1. O”。如果使用另一版本的XPath,其可以經(jīng)由 “xpathVersion”屬性來指示。如果客戶端在下載增量文件時(shí)發(fā)現(xiàn)“sel”屬性中的XPath表達(dá)式中的錯(cuò)誤，則其可以下載整個(gè)MPD。
客戶端、服務(wù)器、以及上述其他組件可以包括能夠執(zhí)行與上述動(dòng)作相關(guān)的指令的處理組件。圖6示出了包括適合實(shí)現(xiàn)本文所公開的一個(gè)或多個(gè)實(shí)施例的處理組件1310在內(nèi)的系統(tǒng)1300的示例。除了處理器1310之外(其可以被稱為中央處理單元或CPU)，系統(tǒng) 1300可以包括網(wǎng)絡(luò)連接設(shè)備1320、隨機(jī)存取存儲(chǔ)器(RAM) 1330、只讀存儲(chǔ)器(ROM) 1340、輔助存儲(chǔ)器1350、以及輸入/輸出(I/O)設(shè)備1360。這些組件可以經(jīng)由總線1370彼此通信。 在一些情況下，這些組件中的一些可以不存在，或可以彼此按各種組合相結(jié)合，或與未示出的其它組件相結(jié)合。這些組件可以位于單一物理實(shí)體中，或位于多于一個(gè)物理實(shí)體中。在本文中被描述為由處理器1310所采取的任何動(dòng)作可以由處理器1310單獨(dú)采取，或由處理器1310與附圖中示出或未示出的一個(gè)或多個(gè)組件(如數(shù)字信號(hào)處理器(DSP) 1380)相結(jié)合來采取。盡管將DSP1380示出為單獨(dú)的組件，可以將DSP1380并入處理器1310中。
處理器1310執(zhí)行可以從網(wǎng)絡(luò)連接設(shè)備1320、RAM1330、R0M1340、或輔助存儲(chǔ)器 1350(其可以包括各種基于盤的系統(tǒng)，如硬盤、軟盤、或光盤)訪問的指令、代碼、計(jì)算機(jī)程序、或腳本。盡管僅示出一個(gè)CPU1310，多個(gè)處理器可以存在。從而，盡管可以將指令討論為由處理器執(zhí)行，指令可以由一個(gè)或多個(gè)處理器同時(shí)、順序或以其他方式來執(zhí)行?？梢詫⑻幚砥?310實(shí)現(xiàn)為一個(gè)或多個(gè)CPU芯片。
網(wǎng)絡(luò)連接設(shè)備1320可以采用以下形式調(diào)制解調(diào)器、調(diào)制解調(diào)器組、以太網(wǎng)設(shè)備、 通用串行總線(USB)接口設(shè)備、串行接口、令牌網(wǎng)設(shè)備、光纖分布式數(shù)據(jù)接口(FDDI)設(shè)備、 無線局域網(wǎng)(WLAN)設(shè)備、無線收發(fā)信機(jī)設(shè)備，如碼分多址接入(CDMA)設(shè)備、全球移動(dòng)通信系統(tǒng)(GSM)無線收發(fā)信機(jī)設(shè)備、全球微波接入可互操作性(WiMAX)設(shè)備、和/或其他用于連接到網(wǎng)絡(luò)的眾所周知的設(shè)備。這些網(wǎng)絡(luò)連接設(shè)備1320可以使得處理器1310能夠與互聯(lián)網(wǎng)或一個(gè)或多個(gè)電信網(wǎng)絡(luò)或處理器1310可以從其接收信息或處理器1310可以向其輸出信息的其他網(wǎng)絡(luò)通信。網(wǎng)絡(luò)連接設(shè)備1320還可以包括能夠無線發(fā)送和/或接收數(shù)據(jù)的一個(gè)或多個(gè)收發(fā)信機(jī)組件1325。
RAM1330可以用于存儲(chǔ)易失性數(shù)據(jù)以及可能用于存儲(chǔ)由處理器1310執(zhí)行的指令。 ROMl340是非易失性存儲(chǔ)器設(shè)備，其通常具有比輔助存儲(chǔ)器1350·的存儲(chǔ)器容量更小的存儲(chǔ)器容量。R0M1340可以用于存儲(chǔ)指令以及可能存儲(chǔ)在指令執(zhí)行期間讀取的數(shù)據(jù)。針對(duì) RAM1330和R0M1340的存取通常快于對(duì)輔助存儲(chǔ)器1350的存取。輔助存儲(chǔ)器1350通常由一個(gè)或多個(gè)盤驅(qū)動(dòng)器或帶驅(qū)動(dòng)器構(gòu)成，且可以用于數(shù)據(jù)的非易失性存儲(chǔ)，或作為在RAM1330 未大到足以容納所有工作數(shù)據(jù)的情況下的溢出數(shù)據(jù)存儲(chǔ)設(shè)備。輔助存儲(chǔ)器1350可以用于存儲(chǔ)程序，當(dāng)在選擇執(zhí)行這種程序時(shí)該程序被加載到RAM1330中。
I/O設(shè)備1360可以包括液晶顯示器(IXD)、觸摸屏顯示器、鍵盤、鍵區(qū)、開關(guān)、撥號(hào)盤、鼠標(biāo)、軌跡球、語音識(shí)別器、讀卡器、紙帶讀取器、打印機(jī)、視頻監(jiān)視器、或其他眾所周知的輸入/輸出設(shè)備。此外，可以將收發(fā)信機(jī)1325視為I/O設(shè)備1360的組件，而不是網(wǎng)絡(luò)連接設(shè)備1320的組件，或者也是網(wǎng)絡(luò)連接設(shè)備1320的組件。
在實(shí)施例中，提供一種用于獲得媒體呈現(xiàn)描述信息的方法。所述方法包括客戶端獲得與服務(wù)器上的第一 MPD中的改變相關(guān)的信息。所述方法還包括所述客戶端使用所述與改變相關(guān)的信息來更新所述客戶端上的第二 MPD。
在另一實(shí)施例中，提供一種客戶端。所述客戶端包括處理器，所述處理器被配置為使得所述客戶端獲得與服務(wù)器上的第一 MPD中的改變相關(guān)的信息，以及被配置為使得所述客戶端使用所述與改變相關(guān)的信息來更新所述客戶端上的第二 MPD。
為了所有的目的通過引用將以下內(nèi)容并入本文中3GPP技術(shù)規(guī)范(TS) 26. 234、 3GPP TS26. 244、IS0/IEC14496-12、互聯(lián)網(wǎng)工程任務(wù)組(IETF)評(píng)論請(qǐng)求(RFC)5874、以及 IETF RFC5261。
盡管在本公開中已提供了若干實(shí)施例，應(yīng)當(dāng)理解可以在不脫離本公開的范圍的情況下，用很多其它特定形式來體現(xiàn)所公開的系統(tǒng)和方法。應(yīng)當(dāng)將當(dāng)前示例視為說明性，而非限制性的，且本發(fā)明不應(yīng)受限于本文給出的細(xì)節(jié)。例如，在另一系統(tǒng)中可以組合或集成各種單元或組件，或可以省略或不實(shí)現(xiàn)特定特征。
此外，在不脫離本公開的范圍的情況下，在各種實(shí)施例中描述和說明為離散或分離的技術(shù)、系統(tǒng)、子系統(tǒng)和方法可以與其他系統(tǒng)、模塊、技術(shù)或方法組合或集成。被示出或討論為耦合或直接耦合或彼此通信的其他項(xiàng)可以間接耦合或通過某個(gè)接口、設(shè)備或中間組件通信，不管是以電子、機(jī)械還是其他方 式。改變、替換和更改的其他示例可由本領(lǐng)域技術(shù)人員來確定，且可以在不脫離本文所公開的精神和范圍的情況下作出。
權(quán)利要求
1.一種用于獲得媒體呈現(xiàn)描述信息的方法，包括客戶端獲得與服務(wù)器上的第一媒體呈現(xiàn)描述MPD中的改變相關(guān)的信息；以及所述客戶端使用所述與改變相關(guān)的信息來更新所述客戶端上的第二 MPD。
2.根據(jù)權(quán)利要求1所述的方法，其中，所述服務(wù)器是符合超文本傳輸協(xié)議HTTP標(biāo)準(zhǔn)1.1及以上的標(biāo)準(zhǔn)web服務(wù)器。
3.根據(jù)權(quán)利要求1所述的方法，其中，所述與改變相關(guān)的信息存儲(chǔ)在增量文件中，所述增量文件包括以下至少一項(xiàng)所述與改變相關(guān)的信息；對(duì)針對(duì)所述與改變相關(guān)的信息所采取的動(dòng)作進(jìn)行指定的命令；以及描述在所述第二 MPD中要應(yīng)用所述命令的位置的表達(dá)式。
4.根據(jù)權(quán)利要求3所述的方法，其中，所述表達(dá)式是XPath表達(dá)式。
5.根據(jù)權(quán)利要求3所述的方法，其中，所述客戶端在發(fā)起與所述第一MPD相關(guān)聯(lián)的會(huì)話之后獲得整個(gè)所述第一 MPD，以及在獲得整個(gè)所述第一 MPD之后以周期性間隔獲得所述增量文件。
6.根據(jù)權(quán)利要求3所述的方法，其中，多個(gè)增量文件可用于所述客戶端，所述多個(gè)增量文件中的每一個(gè)包含不同量的與改變相關(guān)的信息，以及所述客戶端選擇所述多個(gè)增量文件中的一個(gè)或更多個(gè)。
7.根據(jù)權(quán)利要求6所述的方法，其中，使用序列號(hào)或版本號(hào)來確定要選擇所述多個(gè)增量文件中的哪些。
8.根據(jù)權(quán)利要求3所述的方法，其中，當(dāng)所述客戶端未能獲得所述增量文件或者識(shí)別出所述增量文件中的錯(cuò)誤時(shí)，所述客戶端獲得整個(gè)所述第一 MPD并在之后獲得所述增量文件。
9.根據(jù)權(quán)利要求1所述的方法，其中，將所述與改變相關(guān)的信息存儲(chǔ)在所述第一Mro中的可擴(kuò)展標(biāo)記語言XML標(biāo)簽中，以及當(dāng)所述客戶端希望更新所述第二 MPD時(shí)，所述客戶端僅檢索所述標(biāo)簽中的元素。
10.根據(jù)權(quán)利要求1所述的方法，其中，將符合XML配置訪問協(xié)議XCAP的標(biāo)識(shí)符與所述與改變相關(guān)的信息相關(guān)聯(lián)，以及使用基于XCAP的消息將所述與改變相關(guān)的信息訪問到所述客戶端。
11.根據(jù)權(quán)利要求1所述的方法，其中，當(dāng)由所述服務(wù)器向所述客戶端推送所述與改變相關(guān)的信息時(shí)，所述客戶端接收所述與改變相關(guān)的信息。
12.根據(jù)權(quán)利要求1所述的方法，其中，所述客戶端預(yù)訂接收所述與改變相關(guān)的信息， 以及當(dāng)所述與改變相關(guān)的信息變得可用時(shí)，通知所述客戶端。
13.根據(jù)權(quán)利要求1所述的方法，其中，所述第一Mro包括指示符，所述指示符指示所述第一 Mro支持在不向所述客戶端提供整個(gè)所述第一 Mro的情況下向所述客戶端提供所述第一 MPD的更新。
14.根據(jù)權(quán)利要求13所述的方法，其中，所述指示符指示以下至少一項(xiàng)使用增量文件來提供所述與改變相關(guān)的信息；使用XCAP消息來訪問所述與改變相關(guān)的信息；使用來自所述服務(wù)器的推送來提供所述與改變相關(guān)的信息；以及使用預(yù)訂/通知模型來訪問所述與改變相關(guān)的信息。
15.—種客戶端,包括處理器，被配置為使得所述客戶端獲得與服務(wù)器上的第一媒體呈現(xiàn)描述MPD中的改變相關(guān)的信息，以及被配置為使得所述客戶端使用所述與改變相關(guān)的信息來更新所述客戶端上的第二 MPD。
16.根據(jù)權(quán)利要求15所述的客戶端，其中，所述服務(wù)器是符合超文本傳輸協(xié)議HTTP標(biāo)準(zhǔn)1.1及以上的標(biāo)準(zhǔn)web服務(wù)器。
17.根據(jù)權(quán)利要求15所述的客戶端，其中，所述與改變相關(guān)的信息存儲(chǔ)在增量文件中， 所述增量文件包括以下至少一項(xiàng)所述與改變相關(guān)的信息；對(duì)針對(duì)所述與改變相關(guān)的信息所采取的動(dòng)作進(jìn)行指定的命令；以及描述在所述第二 MPD中要應(yīng)用所述命令的位置的表達(dá)式。
18.根據(jù)權(quán)利要求17所述的客戶端，其中，所述表達(dá)式是XPath表達(dá)式。
19.根據(jù)權(quán)利要求17所述的客戶端，其中，所述客戶端在發(fā)起與所述第一MH)相關(guān)聯(lián)的會(huì)話之后獲得整個(gè)所述第一 MPD，以及在獲得整個(gè)所述第一 MPD之后以周期性間隔獲得所述增量文件。
20.根據(jù)權(quán)利要求17所述的客戶端，其中，多個(gè)增量文件可用于所述客戶端，所述多個(gè)增量文件中的每一個(gè)包含不同量的與改變相關(guān) 的信息，以及所述客戶端選擇所述多個(gè)增量文件中的一個(gè)。
21.根據(jù)權(quán)利要求20所述的客戶端，其中，使用序列號(hào)或版本號(hào)來確定要選擇所述多個(gè)增量文件中的哪些。
22.根據(jù)權(quán)利要求17所述的客戶端，其中，當(dāng)所述客戶端未能獲得所述增量文件或者識(shí)別出所述增量文件中的錯(cuò)誤時(shí)，所述客戶端獲得整個(gè)所述第一 MPD并在之后獲得所述增量文件。
23.根據(jù)權(quán)利要求15所述的客戶端，其中，將所述與改變相關(guān)的信息存儲(chǔ)在所述第一 MPD中的可擴(kuò)展標(biāo)記語言XML標(biāo)簽中，以及當(dāng)所述客戶端希望更新所述第二 MPD時(shí)，所述客戶端僅檢索所述標(biāo)簽中的元素。
24.根據(jù)權(quán)利要求15所述的客戶端，其中，將符合XML配置訪問協(xié)議XCAP的標(biāo)識(shí)符與所述與改變相關(guān)的信息相關(guān)聯(lián)，以及使用基于XCAP的消息將所述與改變相關(guān)的信息訪問到所述客戶端。
25.根據(jù)權(quán)利要求15所述的客戶端，其中，當(dāng)由所述服務(wù)器向所述客戶端推送所述與改變相關(guān)的信息時(shí)，所述客戶端接收所述與改變相關(guān)的信息。
26.根據(jù)權(quán)利要求15所述的客戶端，其中，所述客戶端預(yù)訂接收所述與改變相關(guān)的信息，以及當(dāng)所述與改變相關(guān)的信息變得可用時(shí)，通知所述客戶端。
27.根據(jù)權(quán)利要求15所述的客戶端，其中，所述第一MH)包括指示符，所述指示符指示 所述第一 Mro支持在不向所述客戶端提供整個(gè)所述第一 Mro的情況下向所述客戶端提供所述第一 MPD的更新。
28.根據(jù)權(quán)利要求27所述的客戶端，其中，所述指示符指示以下至少一項(xiàng)使用增量文件來提供所述與改變相關(guān)的信息；使用XCAP消息來訪問所述與改變相關(guān)的信息；使用來自所述服務(wù)器的推送來提供所述與改變相關(guān)的信息；以及 使用預(yù)訂/通知模型來訪問所述與改變相關(guān)的信息。
全文摘要
本發(fā)明提供了一種用于獲得媒體呈現(xiàn)描述信息的方法。所述方法包括客戶端獲得與服務(wù)器上的第一媒體呈現(xiàn)描述(MPD)中的改變相關(guān)的信息。所述方法還包括所述客戶端使用所述與改變相關(guān)的信息來更新所述客戶端上的第二MPD。
文檔編號(hào)H04L29/08GK103069770SQ201180039108
公開日2013年4月24日 申請(qǐng)日期2011年6月10日 優(yōu)先權(quán)日2010年6月14日
發(fā)明者戴維·斯圖爾特·弗貝克, 蘇雷什·奇圖里 申請(qǐng)人:捷訊研究有限公司