用于發(fā)送相應地接收媒體流的方法
【專利摘要】本發(fā)明提議一種用于接收媒體流的方法，由此將媒體流分段在多個連續(xù)片段中。開始時，接收清單文件，由此清單文件包括以URI模板方式的媒體片段的指示和引用所述媒體流的第一片段的開始索引。從清單文件內(nèi)的接收信息組裝不同URI，由此組裝的URI引用所述多個片段的片段，并且由此組裝是基于所述指示和索引，由此索引基于開始索引進行計算，并且對于每個連續(xù)片段增加預確定的值。借助于這些組裝的URI，接收所述片段，由此接收是基于允許識別相同片段的分組的標識符，由此所述片段散布在多個分組上，并且特定片段的每個分組包括所述特定標識符，由此索引映射到標識符。重新組裝獲取的媒體片段分組以形成所述媒體流。本發(fā)明還提議了一種用于以上述方式提供所述媒體流的方法及允許執(zhí)行相應方法的相應設(shè)備。
【專利說明】用于發(fā)送相應地接收媒體流的方法
[0001]
【技術(shù)領(lǐng)域】
[0002]本發(fā)明涉及用于接收媒體流的方法。
【背景技術(shù)】
[0003]迄今為止，通過移動網(wǎng)絡(luò)的標準化直播視頻分組服務依賴RTP (實時傳輸協(xié)議)傳輸媒體流(也稱為內(nèi)容)。其后，3GPP/ETSI ,MPEG和開放IPTV論壇組織已定義了動態(tài)和適應性HTTP流傳送(DASH)系統(tǒng)。DASH定義成通過HTTP協(xié)議傳輸內(nèi)容。然而，它定義也能夠通過象例如FLUTE的其它文件傳送協(xié)議傳輸?shù)奈募袷健ASH由此描述通過HTTP的動態(tài)適應性流傳送，而FLUTE涉及通過單向傳輸?shù)奈募斔汀LUTE上的DASH (DASH over FLUTE)基本上描述“文件流傳送”服務，由此客戶端從單獨獲取的文件的序列重新組裝流。
[0004]圖1中示出在“HTTP流傳送”與提議的DASH直播流傳送(“文件流傳送”)原理之間的差別。
[0005]在可以MPEG2-傳輸流分組(MPEG2-TS)形式提供的“HTTP流傳送”內(nèi)容的情況下，可通過例如TCP管道的單個管道發(fā)送。在例如通過使用HTTP請求/HTTP響應循環(huán)打開HTTP/TCP管道后，客戶端接收MPEG-TS分組而不發(fā)送任何另外的HTTP請求。
[0006]在“適應性HTTP流傳送”的情況下，提供內(nèi)容的服務器將流細分成多個連續(xù)媒體片段，每個片段包含某個持續(xù)時間的媒體數(shù)據(jù)(一般大約I秒或10秒)。客戶端單獨獲取這些媒體片段，即，在某個時間點發(fā)送對每個媒體片段的HTTP請求，并且在客戶端側(cè)上聯(lián)結(jié)獲取的媒體片段，從而形成連續(xù)的流。
[0007]DASH標準由兩個主要部分組成。
[0008]第一部分提供用于媒體呈現(xiàn)描述(MPD)，MPD將由客戶端用于得出接入內(nèi)容的適當鏈路。
[0009]第二部分識別內(nèi)容的格式，內(nèi)容在媒體片段方面指ISO文件格式(3GP或MP4)和MPEG2-TS格式的擴展。
[0010]用于媒體片段檢索的默認協(xié)議是基于HTTP的，但其它協(xié)議也可使用。允許此類檢索的協(xié)議將能夠獨特地識別媒體片段，例如，通過使用URL或諸如此類。
[0011]MPD的用途是向客戶端提供與可用內(nèi)容版本的特性(例如，視頻分辨率、比特率)的信息、位置和定時，使得客戶端能夠獲取和播放特定內(nèi)容的媒體片段。
[0012]MPD語法以XML方式定義。一般情況下，在流傳送會話開始時使用HTTP獲取MPD文件，但為了靈活性，也可在預確定的時間間隔流逝后更新/重新獲取MPD。
[0013]如圖2以示意圖方式所示的Mro包括三個主要組成，即，時期、表示和片段。雖然在下述內(nèi)容中以分層方式描述，但要理解的是，可選擇允許有關(guān)組成的明確歸屬的任何適當格式。
[0014]如圖2所示，時期元素是MPD的最外部分。時期一般表示將按順序向用戶呈現(xiàn)的更大塊的媒體。
[0015]在某個時期內(nèi)，可出現(xiàn)內(nèi)容的多個不同編碼。每個備選稱為表示。這些備選表示可提供用于不同比特率和/或不同幀速率和/或視頻分辨率及諸如此類。
[0016]最后，每個表示例如通過使用HTTP URL描述一系列的片段。這些URL在表示(并且可能因此類似于播放列表)中明確描述，或者URL通過模板構(gòu)造描述，這允許客戶端得到用于表不的每個片段的有效URL。
[0017]如所述的，Mro格式是靈活的，并且能夠支持諸如MPEG-2 TS的其它媒體容器格式。Mro甚至也允許內(nèi)容播放列表和/或廣告插入功能性，這是因為不同內(nèi)容的時期可鏈接在表示或時期內(nèi)。
[0018]電信系統(tǒng)中廣泛使用的3GP文件格式及因此還有3G2和MP4文件格式是基于ISO基本媒體文件格式(ISO-FF)。在下述內(nèi)容中，我們將只引用3GP，但由此假設(shè)也包含3G2和MP4。圖3中以示意圖方式顯示3GP媒體流的一部分。
[0019]用于HTTP流傳送的3GP片段可以是初始化片段或媒體片段。
[0020]初始化片段包括配置數(shù)據(jù)(其可格式化為文件格式的“ftyp”和“moov”盒)。
[0021]媒體片段類似于一個片段類型盒(“styp”)和媒體指針和樣本的一個或更多個電影片段(“moof”和“mdat”盒)的級聯(lián)。
[0022]將初始化片段與相同表示的一個或更多個媒體片段級聯(lián)將產(chǎn)生有效的3GP文件。
[0023]3GP文件格式被擴展用于特定的HTTP流傳送要求?，F(xiàn)在它也提供“sidx”、“tfad”和“ tfdt ”盒，而“ styp ”盒非常類似于“ ftyp ”盒。
[0024]片段索引盒(“sidx”)提供與時期開始有關(guān)的相對定時信息以用于在搜尋后的時間恢復。片段索引盒(“Sidx”)也可提供隨機接入點的列表。此類信息也可作為樣本標志輸送。
[0025]另一方面，軌道片段調(diào)整盒(“tfad”)提供在軌道之間的相對定時信息用于媒體同
止/J/ O
[0026]軌道片段基本媒體解碼時間(“tfdt”)盒在軌道片段中提供第一樣本的解碼時間用于媒體同步。
[0027]這些盒(即，“s i dx ”、“ tfdt ” 和 “ s i dx ”)是可選的。
[0028]眾所周知，舊式播放器經(jīng)常丟棄“ftyp”盒。
[0029]提議的適應性HTTP流傳送的特征是媒體片段將對所有用戶是相同的。通過為客戶端提供在備選表示的片段之間交換的可能性，獲得適應性方式。
[0030]由于可為多個用戶容易地緩存媒體片段，因此，此屬性使3GP-DASH HTTP緩存和內(nèi)容輸送網(wǎng)絡(luò)(CDN)友好。由其URL識別的媒體片段然后能夠以與任何其它Web內(nèi)容相同的方式由中間HTTP代理/緩存提供。
[0031]3GPP中HTTP流傳送的另一特征是可再使用為諸如3GPP PSS流傳送的其它流傳送解決方案定義的編解碼器，由此消除提供另外編解碼器的需要。
[0032]此外，在其它領(lǐng)域，如在IPTV (因特網(wǎng)協(xié)議電視)中，可能采用類似的概念，如例如采納了類似規(guī)范作為在2010年9月公布的其第2版的一部分的開放IPTV論壇(OIPF)。MPD語法和語義被再使用，只示出較小的適應。
[0033]此外，指定了允許在MPEG2傳輸流(MPEG2-TS)格式中支持媒體片段的擴展。OIPF提供的MPEG2-TS擴展與由只示出較小的適應的3GP媒體片段提供的擴展對齊。MPD可使用例如MME類型“視頻/mpeg”或“視頻/mp2t”指示媒體片段的格式為MPEG2-TS。
[0034]OIPF MPEG-2 TS格式可被理解為完全TS格式的子集。因此，通過聯(lián)結(jié)客戶端獲取的媒體片段，可能形成符合MPEG2-TS的流。
[0035]節(jié)目特定信息(PSI)表可包括在初始化片段中和/或在一個或更多個媒體片段中。
[0036]每個媒體片段將以隨機接入點開始。所有媒體表示將是時間對齊的，從而允許簡化的交換及比特率適應。MPEG2-TS random_access_indicator字段可用于表明在一個或更多個媒體片段內(nèi)的隨機接入點，由此允許客戶端側(cè)上簡化的特技播放和/或搜尋操作。
[0037]DASH規(guī)范現(xiàn)在可用于具有3GP和MPEG2-TS文件格式的服務器和客戶端實現(xiàn)器。
[0038]至今，即使上述設(shè)置提供了幾個益處，但還有主要問題要解決。
[0039]也描述為MBMS下載的MBMS文件輸送未設(shè)計用于直播視頻分布。直播視頻分布及其它直播服務依賴諸如RTP的實時協(xié)議。
[0040]能夠設(shè)想對“FLUTE上的DASH”設(shè)計的改變。然而，此類設(shè)計要求通過新文件輸送表(FDT)實例通告每個媒體片段。FDT實例由此將包括用于相應媒體片段的文件名和相應FEC配置(例如，符號大小和內(nèi)容長度)。包含在FTD實例中的文件名與是整數(shù)的傳輸對象ID相關(guān)聯(lián)。此傳輸對象標識符要包括在屬于相應媒體片段的每個分組中。另外，每個分組包括經(jīng)常稱為FEC有效負載ID的序號，序號用于識別片段內(nèi)分組的順序。
[0041]為示出此問題，我們將在下述內(nèi)容中參照涉及MBMS上的DASH的過程的圖4和5。
[0042]其中，MPD包括URL模板，模板將通過將字符(此處為$Index$)的良好定義的順序替換為是索引的整數(shù)(此處為“10”到“12”)的字符來描述有效的URL構(gòu)造。索引的范圍也在MPD中給出。默認開始索引可以為“I”。
[0043]媒體客戶端可使用模板http://www.example.com/FIFA_2min-$Index$.3gs 和索引來構(gòu)建用于媒體片段的有效URI。如果索引為10，則用于媒體片段的有效URI能夠是http://www.example.com/FIFA_2min_10.3gs。
[0044]FLUTE協(xié)議的性質(zhì)由此要允許為例如http://www.example.com/FIFA_2min-10.3gs的每個文件URI指派例如10的傳輸對象ID (TOI)(參見圖4)。注意，URI引用的文件仍可分成幾個分組，例如，UDP分組，并且TOI由媒體客戶端用于收集屬于相同文件的FLUTE分組。由于具有相同TOI的所有分組保持為相同文件的一部分，因此，這可以完成。
[0045]圖5是通過FLUTE的DASH片段流的傳送。其中，例如FIFA_seg003.3gs的每個媒體片段在簡化顯示的FLUTE FDT實例內(nèi)通知，并且指派有單個傳輸對象ID，即，在所示示例中，TOI 21指派到名為FIFA-seg003.3gs的文件(簡化的內(nèi)容位置)，而TOI 22指派到文件URI FIFA-seg004.3gs。此外，每個FLUTE FDT實例指示諸如FEC符號大小、FEC編碼和其它FEC信息、文件大小的FEC參數(shù)及內(nèi)容類型和確切的內(nèi)容位置，如圖4所示。在FDT實例后，可接收和重新組裝所述文件“FIFA-seg003.3gs”的相應“UDP/Flute”分組。在分組的序列之間，通過重復“FDT Inst #x”分組，可如圖5所示重復FDT實例。
[0046]缺點是如果對應于所述實例的FDT實例未收到，或者如果FDT實例損壞，則FLUTE接收器將丟棄整個片段，這是因為在沒有適當FEC配置以及丟失在FDT實例內(nèi)提供的內(nèi)容位置相應地內(nèi)容的正確類型(MME類型)和/或文件大小的情況下，F(xiàn)LUTE接收器不能將媒體片段解碼。此類丟棄將導致服務質(zhì)量被感覺為差，由此減小了允許再使用已知編解碼器和輸送機制并且由此最小化市場化的時間及總體軟件開發(fā)和維護成本的常見方案的總體益處。

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

[0047]一個目的是消除至少一些上述缺點并且提供用于發(fā)送相應地接收媒體流的改進方法以及因此改進的裝置。
[0048]因此，本發(fā)明提議一種用于接收媒體流的方法，由此將媒體流分段在多個連續(xù)片段中。開始時，接收清單文件，由此清單文件包括以URI模板方式的媒體片段的指示和引用所述媒體流的第一片段的開始索引。從清單文件內(nèi)的接收信息組裝不同URI，由此組裝的URI引用所述多個片段的片段，并且由此組裝是基于所述指示和索引，由此索引基于開始索引進行計算，并且對于每個連續(xù)片段增加預確定的值。借助于這些組裝的URI，接收所述片段，由此接收是基于允許識別相同片段的分組的標識符，由此所述片段散布在多個分組上，并且特定片段的每個分組包括所述特定標識符，由此索引映射到標識符。重新組裝獲取的媒體片段分組以形成所述媒體流。
[0049]本發(fā)明也提議了一種用于以上述方式提供所述媒體流的方法及允許執(zhí)行相應方法的相應設(shè)備。
【專利附圖】

【附圖說明】
[0050]在下述內(nèi)容中，將參照附圖進一步詳細描述本發(fā)明，其中 圖1以示意圖方式示出傳統(tǒng)媒體流和分段的媒體流的比較；
圖2以示意圖方式示出媒體呈現(xiàn)描述的一般布置；
圖3以示意圖方式示出片段的基于3gp格式的http流傳送的典型布置；
圖4以示意圖方式示出允許識別媒體流的單獨URI的現(xiàn)有技術(shù)的設(shè)計原理；
圖5以示意圖方式示出通過FLUTE的DASH片段的傳送；
圖6以示意圖方式示出在允許利用本發(fā)明的益處的系統(tǒng)內(nèi)根據(jù)本發(fā)明的裝置的布置； 圖7示出顯示根據(jù)本發(fā)明的實施例的客戶端的方面的流程圖，以及 圖8示出顯示根據(jù)本發(fā)明的實施例的服務器的方面的流程圖。
【具體實施方式】
[0051]在詳細描述本發(fā)明的實施例之前，要理解本發(fā)明不限于所述裝置的特定組件部分或所述方法的步驟，這是因為此類裝置和方法可有所不同。也要理解，本文使用的術(shù)語只是為了描述特定實施例，而無意于限制。必須注意的是，除非上下文另外明確指明，否則，如說明書和隨附權(quán)利要求中使用的，單數(shù)形式“一”和“該”也包括單數(shù)和/或復數(shù)指示物。
[0052]
【發(fā)明者】注意到，文件序列的多個連續(xù)文件提供幾乎相同大小和/或持續(xù)時間。因此，此類似大小和/或提供類似持續(xù)時間的大多數(shù)FEC參數(shù)也將是類似的。這可同樣對于流的一些或甚至所有文件是正確的。此外，
【發(fā)明者】注意到，MPD文件及FDT實例各自至少部分包括類似信息，而其它信息只在FDT內(nèi)提供，如文件大小和FEC參數(shù)及文件大小。[0053]本發(fā)明提議直接傳送例如ISO-FF或MPEG2-TS或諸如此類的媒體片段，例如，經(jīng)由如IETF定義的ALC (異步分層編碼)協(xié)議，由此消除對IETF FLUTE協(xié)議的需要。為允許此類傳輸，類似的信息被布置使得它變得相同，而傳統(tǒng)上在FLUTE FDT實例中傳輸?shù)撵o態(tài)信息移向MPD?？勺冃畔⑼ㄟ^不同方式傳輸，例如，它可編碼到報頭中，例如，作為擴展。
[0054]本發(fā)明因此允許增加的魯棒性。
[0055]MPD能夠描述采用具有單獨索引的URI模板形式的媒體片段URI的序列。MPD包括開始索引，并且可選擇地也包括結(jié)束索引。此類結(jié)束索引可事先已知，例如，在直播會話的已知結(jié)束時間的情況下?？蛻舳丝赏ㄟ^組合URI模板和索引而形成媒體片段URI。
[0056]不例模板可以是“http: //server/path/seg$Index$.3gs”,其中，序列 “$Index$”要由索引替換，例如，索引的整數(shù)值。作為示例，如果$Index$的值為9，則產(chǎn)生的URI將是“http://server/path/seg9.3gs”。
[0057]FLUTE協(xié)議通過常規(guī)文件輸送功能擴展ALC (異步分層編碼)。具體而言，F(xiàn)LUTE提供了將象文件名和MIME類型的文件屬性關(guān)聯(lián)到ALC/LCT TOI元素(傳輸對象ID)的功能性。因此，每個UDP分組包括其所屬的傳輸對象(即，文件)的TOI值。
[0058]FLUTE也可提供允許客戶端移除TOI到文件關(guān)聯(lián)的超時機制。
[0059]除其它之外，F(xiàn)DT條目還可包括 ?Τ0Ι (條目)
?用于關(guān)聯(lián)的截止時間 ?文件名(內(nèi)容位置)
?MIME類型(內(nèi)容類型)
?內(nèi)容長度 ?FEC符號大小 ?FEC編碼ID ?源塊長度 ?其它FEC OTI參數(shù)
例如，如具“MBMS上的DASH”能力的客戶端的通過本發(fā)明使能的具有能力的裝置可通過使用諸如ALC TOI值的允許識別相同片段的分組的標識符作為用于媒體片段URI創(chuàng)建的索引來創(chuàng)建媒體片段URI。標識符可直接用作$Index$，或者可在預確定的方案內(nèi)使用，如在預確定的計算方案內(nèi)。即，$index$與ALC TOI方案對齊，其中，索引一般以I開始。為此，索引直接映射到MPD片段索引和ALC TOI。MPD也可包括內(nèi)容類型(MME類型)(因為這一般是用于流的片段的靜態(tài)數(shù)據(jù))，相應地它的分組。向如通過本發(fā)明使能的客戶端提供的MPD將包括專用“廣播”表示(或適應集)，客戶端可在通過MBMS接收媒體片段時使用它。
[0060]此類廣播表示將包括FEC編碼ID (并且可選擇地也包括FEC實例ID)，從而允許描述使用的FEC方案。注意，甚至NO-CODE FEC也是包括編碼ID O的有效FEC方案。MPD中的廣播表示也可包括FEC符號大小，并且還可基于需要而包括其它FEC方案特定信息。FEC方案特定信息可涉及每編碼符號的子塊數(shù)量和/或子符號數(shù)量。
[0061] 如果媒體輸送要求跨不同表示的時間對齊，則媒體片段將提供用于相同持續(xù)時間的媒體播放時間。因此，媒體片段可由于視頻的性質(zhì)而在大小方面有所不同，一般示出可變比特率。[0062]在此情況下，將為例如ALC傳輸塊的每個文件提供對象長度或編碼符號的數(shù)量。為此，可在諸如LCT報頭擴展的報頭內(nèi)提供信息，從而允許攜帶必需的信息，例如作為ALC報頭的一部分。此類報頭可與每個分組一起提供。
[0063]如果媒體輸送允許恒定大小的媒體片段，則每個媒體片段的播放時間將一般是不同的，即，如果媒體片段具有恒定大小(以字節(jié)為單位)，則每個片段提供的媒體播放時間一般有所不同。
[0064]在此情況下，文件大小或源符號的數(shù)量可在MPD中提供。
[0065]為使能與現(xiàn)有FLUTE接收器的后向兼容性，可設(shè)想作為提供此類增強服務的服務器的廣播-多播-服務中心(BM-SC)還可創(chuàng)建有效FDT實例并且標記為TOI O。由于媒體流的第一媒體片段從TOI=I開始，因此，預期無負相互作用。
[0066]為使能在媒體會話內(nèi)的MPD更新，例如，象圖5所示的，其中，在傳送UDP/Flute分組流的同時包括了第二 FDT INST#X，可設(shè)想更新的MPD將例如通過在FLUTE/ALC報頭中使用不同傳輸會話標識符TSI而單獨輸送，例如，在例如另一 FLUTE/ALC信道的單獨信道中輸送，和/或例如通過使用不同UDP端口而作為不同(FLUTE)會話輸送。顯而易見的是，即使使用術(shù)語“更新”，MPD更新也可只是以前發(fā)送的MPD的副本。
[0067]下面示出使能“MBMS上的優(yōu)化DASH”的示例MPD。此MPD允許組合模板URI構(gòu)造和與FLUTE FDT實例有關(guān)的信息。此構(gòu)造消除了在單獨消息中發(fā)送這些FLUTE FDT實例的需要，并且由此本發(fā)明提供了允許更可靠傳輸?shù)挠欣桨浮?br> [0068]因此，根據(jù)本發(fā)明的MPD也包括允許直接ALC傳輸對象識別和文件URI關(guān)聯(lián)的模板。對于后向兼容性，模板可 被布置使得它也允許經(jīng)典FLUTE傳輸對象識別和文件URI關(guān)聯(lián)。
[0069]在下述內(nèi)容中，給出了示出根據(jù)本發(fā)明的特征的示例MPD。下面的示例示出具有時間對齊媒體片段的MPD實現(xiàn)示例。
[0070]〈MPD xmlns="urn:3GPP:ns:PSS:AdaptiveHTTPStreamingMPD:2009〃 availabilityStartTime="2010-10-llT13:50:44Z" availabilityEndTime="2010-10_llT16:50:44Z" timeShiftBufferDepth="PTlM0.00S" type="Live" minBufferTime="PT10.00S">
〈Per1d segmentAlignmentFlag=〃true〃>
〈Representat1n bandwidth=〃128000〃 mimeType=〃video/3gpp〃 >
〈Segmentlnfo durat1n="PT10S" baseURL="mt500">

<Initialisat1nSegmentURL sourceURL=〃fifal28seg—1.3gp〃/>
〈UrlTemplate sourceURL=〃$Index$.3gs〃/>
</SegmentInfo>
〈/Representat1n〉
〈Representat1n bandwidth=〃512000〃 mimeType=〃video/3gpp〃>
〈Segmentlnfo durat1n="PT10S" baseURL="mt1000">

<Initialisat1nSegmentURL sourceURL=〃fifa512seg—1.3gp〃/>
〈UrlTemplate sourceURL=〃$Index$.3gs〃/>
</SegmentInfo>
〈/Representat1n〉〈Representat1n bandwidth=〃512000〃 mimeType=〃video/3gpp〃 mbms==〃true〃>
<MbmsRecept1n>

〈bearer sdp=，，http://example, com/link/del.sdp，，/>

〈fee fecld=” I” symLen=” 135” schemelnfo=” AAEBBA==” >
</MbmsRecept1n>
〈Segmentlnfo durat1n="PT10S" baseURL="mtlOOO">

<Initialisat1nSegmentURL sourceURL=〃fifa512seg_1.3gp〃/>
〈UrlTemplate sourceURL=//$Index$.3gs7>
</SegmentInfo>
〈/Representat1n〉
〈/Per1d〉
</MPD>
MPD示出信息的分層布置。第一信息是在字段availabilityStartTime=〃2010-10_llT13:50:44Z〃中給出的開始索引信息。此外，可選的結(jié)束索引可在另一字段avaiIabiIityEndTime=〃2010-10-l 1T16:50:44Z〃中提供。涉及所有表示的其它參數(shù)也可給出，例如，涉及媒體的緩沖器和/或類型的 信息。
[0071]示范MPD包括三個表示。此處，前兩個表示〈Representat1nbandwidth="128000〃 mimeType="video/3gpp"> 和〈Representat1n bandwidth="512000〃mimeType=〃video/3gpp〃>描述使用HTTP的媒體片段的單播接收，由此第一表示和第二表示在所需帶寬方面相互不同，并且因此也提供用于不同基準URL。
[0072]第三表不〈Representat1nbandwidth="512000〃 mimeType="video/3gpp"mbms==〃true〃>包括名為“mbms”的屬性，該屬性將指示媒體片段的mbms接收，即，媒體片段的多播或廣播接收。
[0073]在所述第三表不內(nèi)，有詳細描述用于廣播/多播輸送的參數(shù)的部分〈MbmsRec印t1n〉。它包括名為承載的元素，其sdp屬性涉及詳細描述輸送會話描述的SDP文件。SDP文件可描述FLUTE會話(后向兼容性)，或者可描述在MBMS上的直接會話，如在MBMS上的ALC會話。
[0074]備選地或另外地，也可將來自SDP文件的這些參數(shù)直接包括到MPD中。具體而言，可提供TMGI (臨時移動群組標識符，即，MBMS承載id)、IP多播地址、UDP目的地端口和TSI信息。
[0075]元素fee包含那些FEC參數(shù)，這些參數(shù)可適用于所有媒體片段，即，它們是靜態(tài)的。這些FEC參數(shù)具體而言是fec-1d，識別將使用哪個FEC代碼、符號大小(symLen)和方案特定信息，例如，源塊和子塊的數(shù)量。這些FEC參數(shù)要用于所有媒體片段。
[0076]文件大小或源符號的數(shù)量可在諸如LCT擴展報頭的報頭內(nèi)提供到客戶端。
[0077]如果提供了文件大小，則客戶端將源符號的數(shù)量計算為最高限度(ceil)(文件大小/符號大小)。在FEC解碼期間可將最后的符號填充為完整符號。
[0078]取決于要求的魯棒程度，此報頭可在開始時提供一次，或者它可在輸送內(nèi)提供若干次。
[0079]在下述內(nèi)容中，給出了示出根據(jù)本發(fā)明的特征的另一示例MPD:媒體輸送也提供使用大小對齊的媒體片段的可能性。然后，所有媒體片段(大約)具有相同大小。攜帶的時間量一般隨片段的不同而不同，這是因為多媒體內(nèi)容可能進行了可變比特率編碼。
[0080]這些大小對齊的片段也可表示為字節(jié)對齊的片段。片段持續(xù)時間可在媒體片段內(nèi)顯式或隱式攜帶。
[0081]例如，在ISO-FF的情況下，一些表(稱為盒)攜帶用于每個片段的解碼定時信息。在MPEG TS的情況下，DTS和PTS (解碼和呈現(xiàn)時間戳)攜帶定時信息。
[0082]因此，由于此片段持續(xù)時間可從以任何方式提供的此信息得出，因此，無需如前面相對于時間對齊片段在報頭內(nèi)提供信息。
[0083]下面的示例示出具有大小對齊的媒體片段的另一 MPD實現(xiàn)示例。
【權(quán)利要求】
1.一種用于接收媒體流的方法，由此將媒體流分段在多個連續(xù)片段中， 接收清單文件，由此所述清單文件 包括以URI模板方式的媒體片段的指示， 包括引用所述媒體流的第一片段的開始索引， 從所述收到的清單文件組裝不同URI， 由此組裝的URI引用所述多個片段的片段， 由此組裝是基于所述指示和索引， 由此所述索引是基于所述開始索引進行計算，并且對于每個連續(xù)片段增加預確定的值， 借助于所述組裝的URI接收所述片段，由此接收是基于允許識別相同片段的分組的標識符，由此所述片段散布在多個分組上，并且特定片段的每個分組包括所述標識符，由此所述索引映射到所述標識符， 重新組裝所述片段以形成所述媒體流。
2.一種用于提供媒體流的方法，由此將媒體流分段在多個連續(xù)片段中， 提供清單文件，由此所述清單文件 包括以URI模板方式的媒體片段的指示， 包括引用所述媒體流的第一片段的開始索引， 由此所述清單文件允許從所述收到的清單文件組裝不同URI， 由此組裝的URI引用所述多個片段的片段， 由此組裝是基于所述指示和索引， 由此所述索引是基于所述開始索引進行計算，并且對于每個連續(xù)片段增加預確定的值， 借助于所述組裝的URI提供所述片段，由此提供是基于允許識別相同片段的分組的標識符，由此所述片段散布在多個分組上，并且特定片段的每個分組包括所述標識符，由此所述索引映射到所述標識符，由此允許重新組裝所述片段以形成所述媒體流。
3.如權(quán)利要求1或2所述的方法，由此所述索引是傳輸對象標識符。
4.如權(quán)利要求1或2或3所述的方法，由此所述清單文件包括結(jié)束索引。
5.如前面權(quán)利要求任一項所述的方法，由此所述流以單播或廣播或多播方式提供。
6.如前面權(quán)利要求任一項所述的方法，由此所述片段具有實質(zhì)相同的大小和/或?qū)嵸|(zhì)相同的持續(xù)時間。
7.如前面權(quán)利要求任一項所述的方法，由此提供更新的清單文件用于接收。
8.如前面權(quán)利要求任一項所述的方法，由此所述清單文件包括提供不同比特率和/或不同分辨率和/或不同幀速率的媒體片段的多個指示。
9.一種允許執(zhí)行如權(quán)利要求1到8任一項所述方法的設(shè)備。
【文檔編號】H04L29/06GK104040993SQ201280067351
【公開日】2014年9月10日 申請日期:2012年1月17日 優(yōu)先權(quán)日:2012年1月17日
【發(fā)明者】T.洛馬, F.加賓 申請人:瑞典愛立信有限公司