用于發(fā)送相應(yīng)地接收媒體流的方法
【專利摘要】本發(fā)明提議一種用于接收媒體流的方法,由此將媒體流分段在多個(gè)連續(xù)片段中。開始時(shí),接收清單文件,由此清單文件包括以URI模板方式的媒體片段的指示和引用所述媒體流的第一片段的開始索引。從清單文件內(nèi)的接收信息組裝不同URI,由此組裝的URI引用所述多個(gè)片段的片段,并且由此組裝是基于所述指示和索引,由此索引基于開始索引進(jìn)行計(jì)算,并且對(duì)于每個(gè)連續(xù)片段增加預(yù)確定的值。借助于這些組裝的URI,接收所述片段,由此接收是基于允許識(shí)別相同片段的分組的標(biāo)識(shí)符,由此所述片段散布在多個(gè)分組上,并且特定片段的每個(gè)分組包括所述特定標(biāo)識(shí)符,由此索引映射到標(biāo)識(shí)符。重新組裝獲取的媒體片段分組以形成所述媒體流。本發(fā)明還提議了一種用于以上述方式提供所述媒體流的方法及允許執(zhí)行相應(yīng)方法的相應(yīng)設(shè)備。
【專利說明】用于發(fā)送相應(yīng)地接收媒體流的方法
[0001]
【技術(shù)領(lǐng)域】
[0002]本發(fā)明涉及用于接收媒體流的方法。
【背景技術(shù)】
[0003]迄今為止,通過移動(dòng)網(wǎng)絡(luò)的標(biāo)準(zhǔn)化直播視頻分組服務(wù)依賴RTP (實(shí)時(shí)傳輸協(xié)議)傳輸媒體流(也稱為內(nèi)容)。其后,3GPP/ETSI ,MPEG和開放IPTV論壇組織已定義了動(dòng)態(tài)和適應(yīng)性HTTP流傳送(DASH)系統(tǒng)。DASH定義成通過HTTP協(xié)議傳輸內(nèi)容。然而,它定義也能夠通過象例如FLUTE的其它文件傳送協(xié)議傳輸?shù)奈募袷健ASH由此描述通過HTTP的動(dòng)態(tài)適應(yīng)性流傳送,而FLUTE涉及通過單向傳輸?shù)奈募斔?。FLUTE上的DASH (DASH over FLUTE)基本上描述“文件流傳送”服務(wù),由此客戶端從單獨(dú)獲取的文件的序列重新組裝流。
[0004]圖1中示出在“HTTP流傳送”與提議的DASH直播流傳送(“文件流傳送”)原理之間的差別。
[0005]在可以MPEG2-傳輸流分組(MPEG2-TS)形式提供的“HTTP流傳送”內(nèi)容的情況下,可通過例如TCP管道的單個(gè)管道發(fā)送。在例如通過使用HTTP請求/HTTP響應(yīng)循環(huán)打開HTTP/TCP管道后,客戶端接收MPEG-TS分組而不發(fā)送任何另外的HTTP請求。
[0006]在“適應(yīng)性HTTP流傳送”的情況下,提供內(nèi)容的服務(wù)器將流細(xì)分成多個(gè)連續(xù)媒體片段,每個(gè)片段包含某個(gè)持續(xù)時(shí)間的媒體數(shù)據(jù)(一般大約I秒或10秒)??蛻舳藛为?dú)獲取這些媒體片段,即,在某個(gè)時(shí)間點(diǎn)發(fā)送對(duì)每個(gè)媒體片段的HTTP請求,并且在客戶端側(cè)上聯(lián)結(jié)獲取的媒體片段,從而形成連續(xù)的流。
[0007]DASH標(biāo)準(zhǔn)由兩個(gè)主要部分組成。
[0008]第一部分提供用于媒體呈現(xiàn)描述(MPD),MPD將由客戶端用于得出接入內(nèi)容的適當(dāng)鏈路。
[0009]第二部分識(shí)別內(nèi)容的格式,內(nèi)容在媒體片段方面指ISO文件格式(3GP或MP4)和MPEG2-TS格式的擴(kuò)展。
[0010]用于媒體片段檢索的默認(rèn)協(xié)議是基于HTTP的,但其它協(xié)議也可使用。允許此類檢索的協(xié)議將能夠獨(dú)特地識(shí)別媒體片段,例如,通過使用URL或諸如此類。
[0011]MPD的用途是向客戶端提供與可用內(nèi)容版本的特性(例如,視頻分辨率、比特率)的信息、位置和定時(shí),使得客戶端能夠獲取和播放特定內(nèi)容的媒體片段。
[0012]MPD語法以XML方式定義。一般情況下,在流傳送會(huì)話開始時(shí)使用HTTP獲取MPD文件,但為了靈活性,也可在預(yù)確定的時(shí)間間隔流逝后更新/重新獲取MPD。
[0013]如圖2以示意圖方式所示的Mro包括三個(gè)主要組成,即,時(shí)期、表示和片段。雖然在下述內(nèi)容中以分層方式描述,但要理解的是,可選擇允許有關(guān)組成的明確歸屬的任何適當(dāng)格式。
[0014]如圖2所示,時(shí)期元素是MPD的最外部分。時(shí)期一般表示將按順序向用戶呈現(xiàn)的更大塊的媒體。
[0015]在某個(gè)時(shí)期內(nèi),可出現(xiàn)內(nèi)容的多個(gè)不同編碼。每個(gè)備選稱為表示。這些備選表示可提供用于不同比特率和/或不同幀速率和/或視頻分辨率及諸如此類。
[0016]最后,每個(gè)表示例如通過使用HTTP URL描述一系列的片段。這些URL在表示(并且可能因此類似于播放列表)中明確描述,或者URL通過模板構(gòu)造描述,這允許客戶端得到用于表不的每個(gè)片段的有效URL。
[0017]如所述的,Mro格式是靈活的,并且能夠支持諸如MPEG-2 TS的其它媒體容器格式。Mro甚至也允許內(nèi)容播放列表和/或廣告插入功能性,這是因?yàn)椴煌瑑?nèi)容的時(shí)期可鏈接在表示或時(shí)期內(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]媒體片段類似于一個(gè)片段類型盒(“styp”)和媒體指針和樣本的一個(gè)或更多個(gè)電影片段(“moof”和“mdat”盒)的級(jí)聯(lián)。
[0022]將初始化片段與相同表示的一個(gè)或更多個(gè)媒體片段級(jí)聯(lián)將產(chǎn)生有效的3GP文件。
[0023]3GP文件格式被擴(kuò)展用于特定的HTTP流傳送要求?,F(xiàn)在它也提供“sidx”、“tfad”和“ tfdt ”盒,而“ styp ”盒非常類似于“ ftyp ”盒。
[0024]片段索引盒(“sidx”)提供與時(shí)期開始有關(guān)的相對(duì)定時(shí)信息以用于在搜尋后的時(shí)間恢復(fù)。片段索引盒(“Sidx”)也可提供隨機(jī)接入點(diǎn)的列表。此類信息也可作為樣本標(biāo)志輸送。
[0025]另一方面,軌道片段調(diào)整盒(“tfad”)提供在軌道之間的相對(duì)定時(shí)信息用于媒體同
止/J/ O
[0026]軌道片段基本媒體解碼時(shí)間(“tfdt”)盒在軌道片段中提供第一樣本的解碼時(shí)間用于媒體同步。
[0027]這些盒(即,“s i dx ”、“ tfdt ” 和 “ s i dx ”)是可選的。
[0028]眾所周知,舊式播放器經(jīng)常丟棄“ftyp”盒。
[0029]提議的適應(yīng)性HTTP流傳送的特征是媒體片段將對(duì)所有用戶是相同的。通過為客戶端提供在備選表示的片段之間交換的可能性,獲得適應(yīng)性方式。
[0030]由于可為多個(gè)用戶容易地緩存媒體片段,因此,此屬性使3GP-DASH HTTP緩存和內(nèi)容輸送網(wǎng)絡(luò)(CDN)友好。由其URL識(shí)別的媒體片段然后能夠以與任何其它Web內(nèi)容相同的方式由中間HTTP代理/緩存提供。
[0031]3GPP中HTTP流傳送的另一特征是可再使用為諸如3GPP PSS流傳送的其它流傳送解決方案定義的編解碼器,由此消除提供另外編解碼器的需要。
[0032]此外,在其它領(lǐng)域,如在IPTV (因特網(wǎng)協(xié)議電視)中,可能采用類似的概念,如例如采納了類似規(guī)范作為在2010年9月公布的其第2版的一部分的開放IPTV論壇(OIPF)。MPD語法和語義被再使用,只示出較小的適應(yīng)。
[0033]此外,指定了允許在MPEG2傳輸流(MPEG2-TS)格式中支持媒體片段的擴(kuò)展。OIPF提供的MPEG2-TS擴(kuò)展與由只示出較小的適應(yīng)的3GP媒體片段提供的擴(kuò)展對(duì)齊。MPD可使用例如MME類型“視頻/mpeg”或“視頻/mp2t”指示媒體片段的格式為MPEG2-TS。
[0034]OIPF MPEG-2 TS格式可被理解為完全TS格式的子集。因此,通過聯(lián)結(jié)客戶端獲取的媒體片段,可能形成符合MPEG2-TS的流。
[0035]節(jié)目特定信息(PSI)表可包括在初始化片段中和/或在一個(gè)或更多個(gè)媒體片段中。
[0036]每個(gè)媒體片段將以隨機(jī)接入點(diǎn)開始。所有媒體表示將是時(shí)間對(duì)齊的,從而允許簡化的交換及比特率適應(yīng)。MPEG2-TS random_access_indicator字段可用于表明在一個(gè)或更多個(gè)媒體片段內(nèi)的隨機(jī)接入點(diǎn),由此允許客戶端側(cè)上簡化的特技播放和/或搜尋操作。
[0037]DASH規(guī)范現(xiàn)在可用于具有3GP和MPEG2-TS文件格式的服務(wù)器和客戶端實(shí)現(xiàn)器。
[0038]至今,即使上述設(shè)置提供了幾個(gè)益處,但還有主要問題要解決。
[0039]也描述為MBMS下載的MBMS文件輸送未設(shè)計(jì)用于直播視頻分布。直播視頻分布及其它直播服務(wù)依賴諸如RTP的實(shí)時(shí)協(xié)議。
[0040]能夠設(shè)想對(duì)“FLUTE上的DASH”設(shè)計(jì)的改變。然而,此類設(shè)計(jì)要求通過新文件輸送表(FDT)實(shí)例通告每個(gè)媒體片段。FDT實(shí)例由此將包括用于相應(yīng)媒體片段的文件名和相應(yīng)FEC配置(例如,符號(hào)大小和內(nèi)容長度)。包含在FTD實(shí)例中的文件名與是整數(shù)的傳輸對(duì)象ID相關(guān)聯(lián)。此傳輸對(duì)象標(biāo)識(shí)符要包括在屬于相應(yīng)媒體片段的每個(gè)分組中。另外,每個(gè)分組包括經(jīng)常稱為FEC有效負(fù)載ID的序號(hào),序號(hào)用于識(shí)別片段內(nèi)分組的順序。
[0041]為示出此問題,我們將在下述內(nèi)容中參照涉及MBMS上的DASH的過程的圖4和5。
[0042]其中,MPD包括URL模板,模板將通過將字符(此處為$Index$)的良好定義的順序替換為是索引的整數(shù)(此處為“10”到“12”)的字符來描述有效的URL構(gòu)造。索引的范圍也在MPD中給出。默認(rèn)開始索引可以為“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的每個(gè)文件URI指派例如10的傳輸對(duì)象ID (TOI)(參見圖4)。注意,URI引用的文件仍可分成幾個(gè)分組,例如,UDP分組,并且TOI由媒體客戶端用于收集屬于相同文件的FLUTE分組。由于具有相同TOI的所有分組保持為相同文件的一部分,因此,這可以完成。
[0045]圖5是通過FLUTE的DASH片段流的傳送。其中,例如FIFA_seg003.3gs的每個(gè)媒體片段在簡化顯示的FLUTE FDT實(shí)例內(nèi)通知,并且指派有單個(gè)傳輸對(duì)象ID,即,在所示示例中,TOI 21指派到名為FIFA-seg003.3gs的文件(簡化的內(nèi)容位置),而TOI 22指派到文件URI FIFA-seg004.3gs。此外,每個(gè)FLUTE FDT實(shí)例指示諸如FEC符號(hào)大小、FEC編碼和其它FEC信息、文件大小的FEC參數(shù)及內(nèi)容類型和確切的內(nèi)容位置,如圖4所示。在FDT實(shí)例后,可接收和重新組裝所述文件“FIFA-seg003.3gs”的相應(yīng)“UDP/Flute”分組。在分組的序列之間,通過重復(fù)“FDT Inst #x”分組,可如圖5所示重復(fù)FDT實(shí)例。
[0046]缺點(diǎn)是如果對(duì)應(yīng)于所述實(shí)例的FDT實(shí)例未收到,或者如果FDT實(shí)例損壞,則FLUTE接收器將丟棄整個(gè)片段,這是因?yàn)樵跊]有適當(dāng)FEC配置以及丟失在FDT實(shí)例內(nèi)提供的內(nèi)容位置相應(yīng)地內(nèi)容的正確類型(MME類型)和/或文件大小的情況下,F(xiàn)LUTE接收器不能將媒體片段解碼。此類丟棄將導(dǎo)致服務(wù)質(zhì)量被感覺為差,由此減小了允許再使用已知編解碼器和輸送機(jī)制并且由此最小化市場化的時(shí)間及總體軟件開發(fā)和維護(hù)成本的常見方案的總體益處。
【發(fā)明內(nèi)容】
[0047]一個(gè)目的是消除至少一些上述缺點(diǎn)并且提供用于發(fā)送相應(yīng)地接收媒體流的改進(jìn)方法以及因此改進(jìn)的裝置。
[0048]因此,本發(fā)明提議一種用于接收媒體流的方法,由此將媒體流分段在多個(gè)連續(xù)片段中。開始時(shí),接收清單文件,由此清單文件包括以URI模板方式的媒體片段的指示和引用所述媒體流的第一片段的開始索引。從清單文件內(nèi)的接收信息組裝不同URI,由此組裝的URI引用所述多個(gè)片段的片段,并且由此組裝是基于所述指示和索引,由此索引基于開始索引進(jìn)行計(jì)算,并且對(duì)于每個(gè)連續(xù)片段增加預(yù)確定的值。借助于這些組裝的URI,接收所述片段,由此接收是基于允許識(shí)別相同片段的分組的標(biāo)識(shí)符,由此所述片段散布在多個(gè)分組上,并且特定片段的每個(gè)分組包括所述特定標(biāo)識(shí)符,由此索引映射到標(biāo)識(shí)符。重新組裝獲取的媒體片段分組以形成所述媒體流。
[0049]本發(fā)明也提議了一種用于以上述方式提供所述媒體流的方法及允許執(zhí)行相應(yīng)方法的相應(yīng)設(shè)備。
【專利附圖】
【附圖說明】
[0050]在下述內(nèi)容中,將參照附圖進(jìn)一步詳細(xì)描述本發(fā)明,其中 圖1以示意圖方式示出傳統(tǒng)媒體流和分段的媒體流的比較;
圖2以示意圖方式示出媒體呈現(xiàn)描述的一般布置;
圖3以示意圖方式示出片段的基于3gp格式的http流傳送的典型布置;
圖4以示意圖方式示出允許識(shí)別媒體流的單獨(dú)URI的現(xiàn)有技術(shù)的設(shè)計(jì)原理;
圖5以示意圖方式示出通過FLUTE的DASH片段的傳送;
圖6以示意圖方式示出在允許利用本發(fā)明的益處的系統(tǒng)內(nèi)根據(jù)本發(fā)明的裝置的布置; 圖7示出顯示根據(jù)本發(fā)明的實(shí)施例的客戶端的方面的流程圖,以及 圖8示出顯示根據(jù)本發(fā)明的實(shí)施例的服務(wù)器的方面的流程圖。
【具體實(shí)施方式】
[0051]在詳細(xì)描述本發(fā)明的實(shí)施例之前,要理解本發(fā)明不限于所述裝置的特定組件部分或所述方法的步驟,這是因?yàn)榇祟愌b置和方法可有所不同。也要理解,本文使用的術(shù)語只是為了描述特定實(shí)施例,而無意于限制。必須注意的是,除非上下文另外明確指明,否則,如說明書和隨附權(quán)利要求中使用的,單數(shù)形式“一”和“該”也包括單數(shù)和/或復(fù)數(shù)指示物。
[0052]
【發(fā)明者】注意到,文件序列的多個(gè)連續(xù)文件提供幾乎相同大小和/或持續(xù)時(shí)間。因此,此類似大小和/或提供類似持續(xù)時(shí)間的大多數(shù)FEC參數(shù)也將是類似的。這可同樣對(duì)于流的一些或甚至所有文件是正確的。此外,
【發(fā)明者】注意到,MPD文件及FDT實(shí)例各自至少部分包括類似信息,而其它信息只在FDT內(nèi)提供,如文件大小和FEC參數(shù)及文件大小。[0053]本發(fā)明提議直接傳送例如ISO-FF或MPEG2-TS或諸如此類的媒體片段,例如,經(jīng)由如IETF定義的ALC (異步分層編碼)協(xié)議,由此消除對(duì)IETF FLUTE協(xié)議的需要。為允許此類傳輸,類似的信息被布置使得它變得相同,而傳統(tǒng)上在FLUTE FDT實(shí)例中傳輸?shù)撵o態(tài)信息移向MPD??勺冃畔⑼ㄟ^不同方式傳輸,例如,它可編碼到報(bào)頭中,例如,作為擴(kuò)展。
[0054]本發(fā)明因此允許增加的魯棒性。
[0055]MPD能夠描述采用具有單獨(dú)索引的URI模板形式的媒體片段URI的序列。MPD包括開始索引,并且可選擇地也包括結(jié)束索引。此類結(jié)束索引可事先已知,例如,在直播會(huì)話的已知結(jié)束時(shí)間的情況下??蛻舳丝赏ㄟ^組合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ī)文件輸送功能擴(kuò)展ALC (異步分層編碼)。具體而言,F(xiàn)LUTE提供了將象文件名和MIME類型的文件屬性關(guān)聯(lián)到ALC/LCT TOI元素(傳輸對(duì)象ID)的功能性。因此,每個(gè)UDP分組包括其所屬的傳輸對(duì)象(即,文件)的TOI值。
[0058]FLUTE也可提供允許客戶端移除TOI到文件關(guān)聯(lián)的超時(shí)機(jī)制。
[0059]除其它之外,F(xiàn)DT條目還可包括 ?Τ0Ι (條目)
?用于關(guān)聯(lián)的截止時(shí)間 ?文件名(內(nèi)容位置)
?MIME類型(內(nèi)容類型)
?內(nèi)容長度 ?FEC符號(hào)大小 ?FEC編碼ID ?源塊長度 ?其它FEC OTI參數(shù)
例如,如具“MBMS上的DASH”能力的客戶端的通過本發(fā)明使能的具有能力的裝置可通過使用諸如ALC TOI值的允許識(shí)別相同片段的分組的標(biāo)識(shí)符作為用于媒體片段URI創(chuàng)建的索引來創(chuàng)建媒體片段URI。標(biāo)識(shí)符可直接用作$Index$,或者可在預(yù)確定的方案內(nèi)使用,如在預(yù)確定的計(jì)算方案內(nèi)。即,$index$與ALC TOI方案對(duì)齊,其中,索引一般以I開始。為此,索引直接映射到MPD片段索引和ALC TOI。MPD也可包括內(nèi)容類型(MME類型)(因?yàn)檫@一般是用于流的片段的靜態(tài)數(shù)據(jù)),相應(yīng)地它的分組。向如通過本發(fā)明使能的客戶端提供的MPD將包括專用“廣播”表示(或適應(yīng)集),客戶端可在通過MBMS接收媒體片段時(shí)使用它。
[0060]此類廣播表示將包括FEC編碼ID (并且可選擇地也包括FEC實(shí)例ID),從而允許描述使用的FEC方案。注意,甚至NO-CODE FEC也是包括編碼ID O的有效FEC方案。MPD中的廣播表示也可包括FEC符號(hào)大小,并且還可基于需要而包括其它FEC方案特定信息。FEC方案特定信息可涉及每編碼符號(hào)的子塊數(shù)量和/或子符號(hào)數(shù)量。
[0061] 如果媒體輸送要求跨不同表示的時(shí)間對(duì)齊,則媒體片段將提供用于相同持續(xù)時(shí)間的媒體播放時(shí)間。因此,媒體片段可由于視頻的性質(zhì)而在大小方面有所不同,一般示出可變比特率。[0062]在此情況下,將為例如ALC傳輸塊的每個(gè)文件提供對(duì)象長度或編碼符號(hào)的數(shù)量。為此,可在諸如LCT報(bào)頭擴(kuò)展的報(bào)頭內(nèi)提供信息,從而允許攜帶必需的信息,例如作為ALC報(bào)頭的一部分。此類報(bào)頭可與每個(gè)分組一起提供。
[0063]如果媒體輸送允許恒定大小的媒體片段,則每個(gè)媒體片段的播放時(shí)間將一般是不同的,即,如果媒體片段具有恒定大小(以字節(jié)為單位),則每個(gè)片段提供的媒體播放時(shí)間一般有所不同。
[0064]在此情況下,文件大小或源符號(hào)的數(shù)量可在MPD中提供。
[0065]為使能與現(xiàn)有FLUTE接收器的后向兼容性,可設(shè)想作為提供此類增強(qiáng)服務(wù)的服務(wù)器的廣播-多播-服務(wù)中心(BM-SC)還可創(chuàng)建有效FDT實(shí)例并且標(biāo)記為TOI O。由于媒體流的第一媒體片段從TOI=I開始,因此,預(yù)期無負(fù)相互作用。
[0066]為使能在媒體會(huì)話內(nèi)的MPD更新,例如,象圖5所示的,其中,在傳送UDP/Flute分組流的同時(shí)包括了第二 FDT INST#X,可設(shè)想更新的MPD將例如通過在FLUTE/ALC報(bào)頭中使用不同傳輸會(huì)話標(biāo)識(shí)符TSI而單獨(dú)輸送,例如,在例如另一 FLUTE/ALC信道的單獨(dú)信道中輸送,和/或例如通過使用不同UDP端口而作為不同(FLUTE)會(huì)話輸送。顯而易見的是,即使使用術(shù)語“更新”,MPD更新也可只是以前發(fā)送的MPD的副本。
[0067]下面示出使能“MBMS上的優(yōu)化DASH”的示例MPD。此MPD允許組合模板URI構(gòu)造和與FLUTE FDT實(shí)例有關(guān)的信息。此構(gòu)造消除了在單獨(dú)消息中發(fā)送這些FLUTE FDT實(shí)例的需要,并且由此本發(fā)明提供了允許更可靠傳輸?shù)挠欣桨浮?br>
[0068]因此,根據(jù)本發(fā)明的MPD也包括允許直接ALC傳輸對(duì)象識(shí)別和文件URI關(guān)聯(lián)的模板。對(duì)于后向兼容性,模板可 被布置使得它也允許經(jīng)典FLUTE傳輸對(duì)象識(shí)別和文件URI關(guān)聯(lián)。
[0069]在下述內(nèi)容中,給出了示出根據(jù)本發(fā)明的特征的示例MPD。下面的示例示出具有時(shí)間對(duì)齊媒體片段的MPD實(shí)現(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包括三個(gè)表示。此處,前兩個(gè)表示〈Representat1nbandwidth="128000〃 mimeType="video/3gpp"> 和〈Representat1n bandwidth="512000〃mimeType=〃video/3gpp〃>描述使用HTTP的媒體片段的單播接收,由此第一表示和第二表示在所需帶寬方面相互不同,并且因此也提供用于不同基準(zhǔn)URL。
[0072]第三表不〈Representat1nbandwidth="512000〃 mimeType="video/3gpp"mbms==〃true〃>包括名為“mbms”的屬性,該屬性將指示媒體片段的mbms接收,即,媒體片段的多播或廣播接收。
[0073]在所述第三表不內(nèi),有詳細(xì)描述用于廣播/多播輸送的參數(shù)的部分〈MbmsRec印t1n〉。它包括名為承載的元素,其sdp屬性涉及詳細(xì)描述輸送會(huì)話描述的SDP文件。SDP文件可描述FLUTE會(huì)話(后向兼容性),或者可描述在MBMS上的直接會(huì)話,如在MBMS上的ALC會(huì)話。
[0074]備選地或另外地,也可將來自SDP文件的這些參數(shù)直接包括到MPD中。具體而言,可提供TMGI (臨時(shí)移動(dòng)群組標(biāo)識(shí)符,即,MBMS承載id)、IP多播地址、UDP目的地端口和TSI信息。
[0075]元素fee包含那些FEC參數(shù),這些參數(shù)可適用于所有媒體片段,即,它們是靜態(tài)的。這些FEC參數(shù)具體而言是fec-1d,識(shí)別將使用哪個(gè)FEC代碼、符號(hào)大小(symLen)和方案特定信息,例如,源塊和子塊的數(shù)量。這些FEC參數(shù)要用于所有媒體片段。
[0076]文件大小或源符號(hào)的數(shù)量可在諸如LCT擴(kuò)展報(bào)頭的報(bào)頭內(nèi)提供到客戶端。
[0077]如果提供了文件大小,則客戶端將源符號(hào)的數(shù)量計(jì)算為最高限度(ceil)(文件大小/符號(hào)大小)。在FEC解碼期間可將最后的符號(hào)填充為完整符號(hào)。
[0078]取決于要求的魯棒程度,此報(bào)頭可在開始時(shí)提供一次,或者它可在輸送內(nèi)提供若干次。
[0079]在下述內(nèi)容中,給出了示出根據(jù)本發(fā)明的特征的另一示例MPD:媒體輸送也提供使用大小對(duì)齊的媒體片段的可能性。然后,所有媒體片段(大約)具有相同大小。攜帶的時(shí)間量一般隨片段的不同而不同,這是因?yàn)槎嗝襟w內(nèi)容可能進(jìn)行了可變比特率編碼。
[0080]這些大小對(duì)齊的片段也可表示為字節(jié)對(duì)齊的片段。片段持續(xù)時(shí)間可在媒體片段內(nèi)顯式或隱式攜帶。
[0081]例如,在ISO-FF的情況下,一些表(稱為盒)攜帶用于每個(gè)片段的解碼定時(shí)信息。在MPEG TS的情況下,DTS和PTS (解碼和呈現(xiàn)時(shí)間戳)攜帶定時(shí)信息。
[0082]因此,由于此片段持續(xù)時(shí)間可從以任何方式提供的此信息得出,因此,無需如前面相對(duì)于時(shí)間對(duì)齊片段在報(bào)頭內(nèi)提供信息。
[0083]下面的示例示出具有大小對(duì)齊的媒體片段的另一 MPD實(shí)現(xiàn)示例。
【權(quán)利要求】
1.一種用于接收媒體流的方法,由此將媒體流分段在多個(gè)連續(xù)片段中, 接收清單文件,由此所述清單文件 包括以URI模板方式的媒體片段的指示, 包括引用所述媒體流的第一片段的開始索引, 從所述收到的清單文件組裝不同URI, 由此組裝的URI引用所述多個(gè)片段的片段, 由此組裝是基于所述指示和索引, 由此所述索引是基于所述開始索引進(jìn)行計(jì)算,并且對(duì)于每個(gè)連續(xù)片段增加預(yù)確定的值, 借助于所述組裝的URI接收所述片段,由此接收是基于允許識(shí)別相同片段的分組的標(biāo)識(shí)符,由此所述片段散布在多個(gè)分組上,并且特定片段的每個(gè)分組包括所述標(biāo)識(shí)符,由此所述索引映射到所述標(biāo)識(shí)符, 重新組裝所述片段以形成所述媒體流。
2.一種用于提供媒體流的方法,由此將媒體流分段在多個(gè)連續(xù)片段中, 提供清單文件,由此所述清單文件 包括以URI模板方式的媒體片段的指示, 包括引用所述媒體流的第一片段的開始索引, 由此所述清單文件允許從所述收到的清單文件組裝不同URI, 由此組裝的URI引用所述多個(gè)片段的片段, 由此組裝是基于所述指示和索引, 由此所述索引是基于所述開始索引進(jìn)行計(jì)算,并且對(duì)于每個(gè)連續(xù)片段增加預(yù)確定的值, 借助于所述組裝的URI提供所述片段,由此提供是基于允許識(shí)別相同片段的分組的標(biāo)識(shí)符,由此所述片段散布在多個(gè)分組上,并且特定片段的每個(gè)分組包括所述標(biāo)識(shí)符,由此所述索引映射到所述標(biāo)識(shí)符,由此允許重新組裝所述片段以形成所述媒體流。
3.如權(quán)利要求1或2所述的方法,由此所述索引是傳輸對(duì)象標(biāo)識(shí)符。
4.如權(quán)利要求1或2或3所述的方法,由此所述清單文件包括結(jié)束索引。
5.如前面權(quán)利要求任一項(xiàng)所述的方法,由此所述流以單播或廣播或多播方式提供。
6.如前面權(quán)利要求任一項(xiàng)所述的方法,由此所述片段具有實(shí)質(zhì)相同的大小和/或?qū)嵸|(zhì)相同的持續(xù)時(shí)間。
7.如前面權(quán)利要求任一項(xiàng)所述的方法,由此提供更新的清單文件用于接收。
8.如前面權(quán)利要求任一項(xiàng)所述的方法,由此所述清單文件包括提供不同比特率和/或不同分辨率和/或不同幀速率的媒體片段的多個(gè)指示。
9.一種允許執(zhí)行如權(quán)利要求1到8任一項(xiàng)所述方法的設(shè)備。
【文檔編號(hào)】H04L29/06GK104040993SQ201280067351
【公開日】2014年9月10日 申請日期:2012年1月17日 優(yōu)先權(quán)日:2012年1月17日
【發(fā)明者】T.洛馬, F.加賓 申請人:瑞典愛立信有限公司