用于提供彩信服務(wù)的方法
【專利摘要】本發(fā)明涉及一種用于從服務(wù)器或中繼器向多媒體網(wǎng)絡(luò)中的用戶代理提供彩信服務(wù)的方法(100)，所述方法(100)包括：通過所述服務(wù)器或中繼器確定(101)視頻內(nèi)容的視頻內(nèi)容特征；確定(103)所述用戶代理的顯示和/或解碼能力；將所述視頻內(nèi)容的選項(xiàng)發(fā)信號通知(105)給所述用戶代理；以及根據(jù)所述顯示和/或解碼能力并且根據(jù)通過所述用戶代理從所述視頻內(nèi)容的發(fā)信號通知的選項(xiàng)中選擇的選項(xiàng)(223)提供(107)所述視頻內(nèi)容。
【專利說明】用于提供彩信服務(wù)的方法

【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及一種用于從服務(wù)器或中繼器向多媒體網(wǎng)絡(luò)中的用戶代理提供彩信服務(wù)的方法，尤其涉及一種用于根據(jù)3GPP (第三移動通信標(biāo)準(zhǔn)化伙伴項(xiàng)目)彩信服務(wù)規(guī)范從麗S服務(wù)器/中繼器B向麗S用戶代理B提供彩信服務(wù)(MMS)的方法。

【背景技術(shù)】
[0002]深度感知是以三維形式(3D)感知世界以及物體的距離的視覺能力。立體3D視頻指代用于通過向觀看者的左眼和右眼單獨(dú)地呈現(xiàn)場景的兩個偏離圖像而形成場景深度的錯覺的技術(shù)。立體3D視頻通過經(jīng)由兩個單獨(dú)的攝像機(jī)捕獲場景來傳送場景的3D感知，這使得場景的物體投射到左側(cè)圖像和右側(cè)圖像中的不同位置。
[0003]通過經(jīng)由兩個以上單獨(dú)的攝像機(jī)捕獲場景，形成了多視圖3D視頻。根據(jù)選定的所捕獲圖像對，可以呈現(xiàn)場景的不同視角(視圖)。多視圖3D視頻允許觀看者交互地控制觀看點(diǎn)。多視圖3D視頻可以被視作表示來自不同視角的同一場景的多個立體3D視頻的多路復(fù)用。
[0004]從右側(cè)視圖到左側(cè)視圖的像素(物體)的位移被稱作視差。視差的值限定感知深度。作為一個實(shí)例，當(dāng)視差等于O且隨后在圖像平面(即，屏幕)上感知相關(guān)像素(物體)時，通過負(fù)視差感知相關(guān)像素(物體)以呈現(xiàn)給屏幕前方的觀看者并且通過正視差感知相關(guān)像素(物體)以呈現(xiàn)給屏幕后方的觀看者。
[0005]幀兼容封裝格式在于對構(gòu)成立體3D視頻的兩個視圖進(jìn)行亞采樣并且將它們封裝在一起，以便產(chǎn)生與2D幀基礎(chǔ)設(shè)施兼容的視頻信號。
[0006]在典型的操作模式中，與相同時間相關(guān)的兩個立體幀被封裝到具有相同2D兼容視圖分辨率的空間布置中。所述空間封裝布置通常使用并排格式或頂部-底部格式，其中下采樣過程應(yīng)用于每個視圖:以此方式，每個視圖呈現(xiàn)相對于對應(yīng)的2D視圖支持的空間分辨率減半的空間分辨率。
[0007]為了避免由幀兼容封裝格式引入的清晰度的缺乏，有可能以全分辨率傳輸兩個視圖。最常見的格式是幀封裝，其中左側(cè)視圖和右側(cè)視圖是按時序交錯的。以此方式，兩個視圖具有與對應(yīng)的幀兼容封裝格式相比加倍的分辨率。
[0008]在幀兼容立體視頻中，將立體對空間封裝到單個幀中在編碼器側(cè)執(zhí)行，并且因此獲得的幀作為單個視圖進(jìn)行編碼。由解碼器產(chǎn)生的輸出幀含有立體對的構(gòu)成幀。編碼器側(cè)指示使用過的幀封裝格式，方法是按照H.264/AVC標(biāo)準(zhǔn)中規(guī)定的來規(guī)定輔助增強(qiáng)信息(SEI)消息中的幀封裝布置，并且在3D視頻H.264/AVC經(jīng)編碼位流內(nèi)傳送所述幀封裝布置。因此，關(guān)于幀封裝格式的SEI消息在3D視頻位流的解碼過程期間進(jìn)行提取和解析。解碼器側(cè)對幀進(jìn)行常規(guī)解碼，解封來自解碼器的輸出幀的兩個構(gòu)成幀，執(zhí)行上采樣以便恢復(fù)編碼器側(cè)的下采樣過程并且使構(gòu)成幀再現(xiàn)在3D顯示器上。
[0009]在暫態(tài)交錯中，視頻在原始視頻的雙倍幀率下編碼。每一對隨后的圖片構(gòu)成立體對(左側(cè)視圖和右側(cè)視圖)。編碼器側(cè)按照H.264/AVC標(biāo)準(zhǔn)中規(guī)定的使用輔助增強(qiáng)信息(SEI)來指示使用過的時間交錯格式并且在3D視頻H.264/AVC經(jīng)編碼位流內(nèi)傳送所述交錯格式。因此，關(guān)于幀封裝格式的SEI消息在3D視頻位流的解碼過程期間進(jìn)行提取和解析。時間交錯立體視頻的再現(xiàn)通常是在高幀率下執(zhí)行的，其中主動式(快門式)眼鏡用于遮蓋每只眼睛處的不正確的視圖。這需要眼鏡與屏幕之間的精確同步。
[0010]多視圖視頻編碼(MVC)是作為H.264/AVC標(biāo)準(zhǔn)的擴(kuò)展(附件)規(guī)范化的。在MVC中，來自不同攝像機(jī)的視圖被編碼成單個位流，所述位流與單視圖H.264/AVC向后兼容。視圖中的一者被編碼為“基礎(chǔ)視圖”。單視圖H.264/AVC解碼器可以解碼并且輸出不同配置文件下(例如，受限基線或漸進(jìn)式高配置文件)的MVC位流的基礎(chǔ)視圖。MVC引入視圖之間的視圖間預(yù)測。MVC能夠以向后兼容方式壓縮立體視頻而不會損害視圖分辨率。如果服務(wù)器察覺到用戶設(shè)備(UE)能力，那么它可以省略將非基礎(chǔ)視圖的視圖分量發(fā)送到并不支持3D或并不具有足夠位率來輸送兩個視圖的裝置中。
[0011]MIME是最初開發(fā)用于包含除電子郵件的純文本主體之外的電子郵件消息中的內(nèi)容的標(biāo)準(zhǔn)。MIME可以用于將單獨(dú)的文件捆綁在一起。根據(jù)RFC 2557 “集合文檔的MIME封裝”被稱為“集合文檔的MME封裝”的MME的擴(kuò)展允許向客戶端指示出消息的所有部分都涉及彼此并且可以指代彼此。在圖6中說明了如在RFC 2557中規(guī)定的MME封裝消息600的一個實(shí)例。
[0012]<Content-Type>向接收客戶端指示出消息的單獨(dú)部分是相關(guān)的并且可以指代彼此。對所有多部分消息常見的〈boundary〉向客戶端指示出將分離消息的每個部分的字符串。在每個邊界之間的是消息601、602、603本身。每個消息601、602、603還含有描述消息類型的〈Content-Type〉。第一消息601僅示出了來自HTML的摘錄。第二消息602和第三消息603省略了圖像的實(shí)際主體并且僅示出了與它們在多部分/相關(guān)消息中的聚集相關(guān)的信息。
[0013]HTML 消息可以通過其規(guī)定的 <Content_ID> (cid)或〈Content-Locat1n〉指代包含的圖像。這些是獨(dú)特地識別消息的部分的兩種方法，因此消息的其他部分可以指代它們。
[0014]了解到HTML是多部分/相關(guān)消息的一部分的讀取實(shí)例HTML的客戶端在查找網(wǎng)絡(luò)之前首先在URL的消息部分內(nèi)查找。
[0015]根據(jù)“用戶代理配置文件版本2.0”的UAProf，Open Mobile Alliance?是處理終端能力和偏好信息(CPI)的表示和端到端流動的開放移動聯(lián)盟(OMA)規(guī)范。UAProf使用通過萬維網(wǎng)聯(lián)盟的(W3C’s)復(fù)合能力/偏好配置文件(CC/PP)定義的框架來表示能力和偏好信息(CPI)并且是使用資源描述框架(RDF)模式和詞匯定義的。規(guī)范還提供了應(yīng)該如何使用無線會話協(xié)議(WSP)和超文本傳送協(xié)議(HTTP)將信息傳輸?shù)椒?wù)器的細(xì)節(jié)。UAProf在描述符的以下類別中進(jìn)行劃分:硬件平臺、軟件平臺、瀏覽器用戶代理、網(wǎng)絡(luò)特征和無線應(yīng)用協(xié)議(WAP)特征。終端的UAProf說明可以提供URL，其中可以在網(wǎng)絡(luò)上檢索CPI或者可以明確地提供它們。此第一選項(xiàng)被稱作靜態(tài)UAProf并且允許傳輸CPI所需的帶寬顯著減小。被稱作動態(tài)UAP1f的第二選項(xiàng)允許發(fā)送動態(tài)能力(例如，改變網(wǎng)絡(luò)條件)。
[0016]服務(wù)器負(fù)責(zé)解析UAProf信息。此特征使動態(tài)UAProf在終端和服務(wù)器二者上的實(shí)施相當(dāng)復(fù)雜。舉例來說，在終端側(cè)上，靜態(tài)UAProf實(shí)施方案僅需要終端傳輸表示其能力的恒定字符串，或者更常見的是，服務(wù)器可以從中檢索它們的URL。此類字符串在終端中可以是硬接線的。相比之下，動態(tài)UAProf將需要終端監(jiān)控其能力的變化(例如，提供新的MME類型支持的安裝的新軟件)，并且生成、追蹤來自參考配置文件的差值并且將所述差值發(fā)送給服務(wù)器。這解釋了為何大部分制造商目前已經(jīng)決定僅支持靜態(tài)UAP1f的原因。
[0017]RDF的使用允許針對基于CC/PP方案的擴(kuò)展性機(jī)制，其提出新類型裝置的演進(jìn)和應(yīng)用。3GPP PSS基礎(chǔ)詞匯是UAProf的擴(kuò)展并且被定義為RDF模式。3GPP中的裝置功能配置文件是遵循CC/PP構(gòu)架的結(jié)構(gòu)和CC/PP應(yīng)用UAP1f的RDF文檔。屬性用于規(guī)定裝置能力和偏好。一組屬性名稱、容許值和語義構(gòu)成CC/PP詞匯，所述詞匯是由RDF模式定義的。對于PSS，再使用UAProf詞匯并且定義了額外的PSS專用詞匯。屬性的語法定義在詞匯模式中，而且在一定程度上定義了語義。PSS裝置能力配置文件是模式(UAProf和/或PSS專用模式)的一個實(shí)例。
[0018]根據(jù)“http://www.w3.0rg/TR/2005/REC-SMIL2_20050107/”的同步多媒體集成語言(SMIL)定義了目標(biāo)在于描述交互多媒體演示的基于XML的語言。使用SMIL，可以描述多媒體演示的暫態(tài)行為，超鏈接與媒體對象的關(guān)聯(lián)以及屏幕上的演示的布局。
[0019]SMIL被定義為一組標(biāo)記模塊，其界定了用于SMIL功能的某些區(qū)域的語義和XML語法。SMIL定義了 10個模塊:動畫模塊、內(nèi)容控制模塊、布局模塊、鏈接模塊、媒體對象模塊、間位信息模塊、結(jié)構(gòu)模塊、定時和同步模塊、時間操縱模塊以及過渡效果模塊。
[0020]第三代移動通信標(biāo)準(zhǔn)化伙伴項(xiàng)目(3GPP)在3GPP TS 26.246中定義了 3GPP SMIL語言配置文件透明的端到端的包交換流媒體服務(wù)(PSS) ;3GPP SMIL語言配置文件”，也稱為“3GPP PSS SMIL語言配置文件”或僅僅稱為“3GPP SMIL”。3GPP SMIL語言配置文件是根據(jù) “http: //www.w3.0rg/TR/2005/REC-SMIL2-20050107/” 基于 SMIL 2.0 基礎(chǔ)配置文件的。
[0021]主要從訂閱者以及服務(wù)供應(yīng)商的視角來看，3GPP彩信服務(wù)(MMS)詳細(xì)說明確保提供非實(shí)時彩信服務(wù)的一組要求。3GPP MMS允許針對不同類型的媒體的非實(shí)時傳輸，包含例如以下功能:每單個消息的多個媒體元素、消息元素的個體處理、每個消息元素的不同輸送方法、協(xié)商不同的終端和網(wǎng)絡(luò)彩信(MM)能力、通知和確認(rèn)麗相關(guān)事件以及個性化麗S配置。
[0022]因此3GPP麗S允許整合了不同種類的媒體(例如，結(jié)合額外移動要求的文本、語音、圖像或視頻)的組成、儲存、接入和輸送的統(tǒng)一應(yīng)用。3GPP麗S使用根據(jù)3GPP TS26.246的3GPP SMIL語言配置文件:用于媒體同步和場景說明的“透明的端到端的包交換流媒體服務(wù)(PSS) ；3GPP SMIL語言配置文件”。圖7示出了針對麗S消息的同步多媒體集成語言(SMIL) 700的示意圖。
[0023]SMIL消息主體703封閉在<smilX/smil>標(biāo)記中并且文檔含有眉頭701部分和主體703部分。眉頭部分701含有應(yīng)用于整個消息的信息。間位字段，例如“標(biāo)題”和“作者”不是必選的。眉頭部分701內(nèi)的布局部分<layout>〈/layout>詳細(xì)說明消息中的所有幻燈片的總體布局。在圖7中描繪的實(shí)例中，幻燈片將被顯示為160像素寬和120像素高。圖7的實(shí)例中的布局進(jìn)一步分成兩個較小區(qū)域:“圖像”(或“視頻”)和“文本”。主體部分703描述消息中的實(shí)際幻燈片。這些幻燈片通過〈par〉標(biāo)記表示。此標(biāo)記內(nèi)的所有元素將會同時顯示。用于每個幻燈片的〈dur>屬性是幻燈片展示中幻燈片的持續(xù)時間。在圖7的實(shí)例中，每個幻燈片含有三個元素:用于在圖像(或視頻)區(qū)域中顯示的一個元素，用于在文本區(qū)域中顯示的一個元素，以及將在觀看幻燈片時播放的音頻元素。
[0024]根據(jù)3GPP TS 23.140的MMS網(wǎng)絡(luò)架構(gòu)800 彩信服務(wù)(MMS);功能說明；2級”在圖8中示出，其由向用戶提供完整的MMS所需的所有元素組成。
[0025]如果麗S用戶代理A 811和麗S用戶代理B 831屬于相同網(wǎng)絡(luò)，那么呈現(xiàn)在圖8中的系統(tǒng)A 801和系統(tǒng)B 803組分可以是相同的實(shí)體。麗S中繼器/服務(wù)器815位于3GPPMMS架構(gòu)800的核心處。除其他之外，MMS中繼器/服務(wù)器815可以根據(jù)3GPP TS 23.140:“彩信服務(wù)(MMS);功能說明；2級”提供以下功能:接收和發(fā)送彩信(MM)用戶代理811的MM通知；消息的臨時存儲817 ;終端能力的協(xié)商；應(yīng)用數(shù)據(jù)的傳送；基于用戶配置文件信息將麗S個性化；基于用戶配置文件或?yàn)V波信息的麗刪除；媒體類型轉(zhuǎn)化；以及媒體格式轉(zhuǎn)化。
[0026]麗S用戶代理(UA) 811駐存在用戶設(shè)備(UE)上或連接到UE的外部裝置上。應(yīng)用層功能向用戶提供觀看、構(gòu)成和處理MM的能力(例如，提交、接收、刪除MM)。
[0027]麗S增值服務(wù)(VAS)應(yīng)用823為麗S用戶提供增值服務(wù)?？梢源嬖诎邴怱架構(gòu)800中或連接到麗S架構(gòu)800上的若干麗S VAS應(yīng)用823。
[0028]MMS用戶數(shù)據(jù)庫819元素可以由一個或多個實(shí)體組成，所述實(shí)體含有用戶相關(guān)信息，例如，訂購和配置(例如，UAProf)。
[0029]在圖8中描繪的麗S用戶代理A 811發(fā)送彩信900，如圖9中所說明，方法是將消息900提交到其歸屬M(fèi)MS服務(wù)器/中繼器A 815。多個媒體元素應(yīng)被組合到復(fù)合的單個MM中，方法是使用如在IETF RFC 2046 多用途網(wǎng)絡(luò)郵件擴(kuò)展(MME)部分二:媒體類型”中定義的MME多部分格式。單個MM元素的媒體類型應(yīng)通過其適當(dāng)?shù)腗ME類型識別，而媒體格式應(yīng)通過其適當(dāng)?shù)腗ME亞型指示。消息必須具有接收方的地址和MME內(nèi)容類型?？梢栽O(shè)置用于消息的若干其他參數(shù)，包含所希望的消息到期時間和消息優(yōu)先級。在接收消息900之后，接收方歸屬M(fèi)MS服務(wù)器/中繼器B 835將消息標(biāo)識分配給消息900。MMS服務(wù)器/中繼器B 835還可以儲存消息900的復(fù)本，隨后朝向接收方，即MMS用戶代理B 831路由消息900。圖9是用于從麗S用戶代理A 811向麗S服務(wù)器/中繼器A 815傳輸麗S的多部分MIME的一個實(shí)例。消息900包括視頻內(nèi)容901、音頻內(nèi)容903和文本內(nèi)容905。
[0030]圖10示出了麗S服務(wù)器/中繼器B 1001與麗S用戶代理B 1003之間的消息順序圖，麗S服務(wù)器/中繼器B 1001對應(yīng)于在圖8中描繪的麗S服務(wù)器/中繼器B 835，麗S用戶代理B 1003對應(yīng)于根據(jù)技術(shù)規(guī)范3GPP TS 23.140的在圖8中描繪的麗S用戶代理B 831。在接收消息(例如，在圖9中描繪的消息900)之后，接收方麗S服務(wù)器/中繼器B1001驗(yàn)證接收方(MMS用戶代理B 1003)的配置文件(UAProf)并且向接收方麗S用戶代理B 1003生成通知，S卩Μ-Notificat1n, ind 1011。它還存儲消息至少直至以下事件中的一者發(fā)生:達(dá)到了相關(guān)聯(lián)的到期時間；輸送了消息；接收方麗S用戶代理B 1003請求消息被轉(zhuǎn)發(fā)；所述消息被拒絕。當(dāng)接收方麗S用戶代理B 1003接收通知1011時，它使用通知1011中的消息參考(統(tǒng)一資源識別符，uri)以立即或在稍后的時間人工地或自動地拒絕或檢索消息，如同由操作者配置和用戶配置文件所確定的。MMS使用具有發(fā)信號通知的uri的HTTP GET請求消息1012進(jìn)行檢索。
[0031]在用于輸送消息1012的請求內(nèi)，接收方MMS用戶代理B 1003可以指示其能力，例如，支持的媒體類型以及指示其UAP1f的媒體格式的列表，用于接收方MMS服務(wù)器/中繼器B 1001。當(dāng)接收到輸送請求1012時，接收方麗S服務(wù)器/中繼器B 1001使用關(guān)于接收方麗S用戶代理B 1003的能力的信息以準(zhǔn)備用于輸送到接收方MMS用戶代理B 1003的消息。此準(zhǔn)備可以涉及不支持的媒體類型和媒體格式的刪除或適配。MMS服務(wù)器/中繼器B1001也可以基于由儲存在網(wǎng)絡(luò)中的接收方裝置(MMS用戶代理B 1003)的UAProf信息指示的能力來執(zhí)行內(nèi)容適配。
[0032]在0MA-TS-MMS-C0NF-V1_3-20110913-A，“MMS — 致性文檔”、Open MobileAlliance?中，需要進(jìn)行解決以便確保由不同制造商生產(chǎn)的終端之間的MMS功能性的互操作性的問題得到識別。根據(jù)文檔，MMS用戶代理1003應(yīng)根據(jù)用于麗S用戶代理能力協(xié)商的“用戶代理配置文件版本2.0”，0pen MobileAlliance?支持UAProf。類似地，MMS服務(wù)器/中繼器1001應(yīng)支持用于MMS用戶代理能力協(xié)商的UAProf。
[0033]互操作性是用戶體驗(yàn)和服務(wù)的成功所必需的。當(dāng)發(fā)送消息時，用戶期望消息到達(dá)其目的地并且適當(dāng)?shù)爻尸F(xiàn)。否則的話，用戶會停止使用服務(wù)，因?yàn)樗麄儾⒉恍湃卧摲?wù)。操作者要求互操作性，因?yàn)槿绻鸐M無法以合理地可接受的方式輸送并且呈現(xiàn)給接收方的話，那么他們就不應(yīng)該對MM收費(fèi)。
[0034]目前，麗S服務(wù)器/中繼器B 1001僅基于麗S接收方的UAProf信息執(zhí)行內(nèi)容適配，而無需根據(jù)圖10中描繪的消息順序咨詢裝置/用戶。在此情況下，其中裝置并不支持3D而是連接到外部3D顯示器上的且因此能夠正確地顯示3D視頻的情境不能夠接收MMS的3D視頻內(nèi)容。這種情況是由于外部裝置未包含在裝置的UAProf信息中且麗S服務(wù)器/中繼器B 1001總是執(zhí)行內(nèi)容適配并且將MMS 3D內(nèi)容轉(zhuǎn)化為2D內(nèi)容的原因。類似地，相反的情況，例如，其中想要限制使用的帶寬且因此僅下載MMS的2D版本的3D可用裝置也是不可能的。
[0035]如上文所述，3D視頻可以各種編碼格式進(jìn)行編碼。幀兼容H.264/AVC和時間交錯H.264/AVC使用傳統(tǒng)的AVC文件格式，其中關(guān)于立體布置的信息攜帶在經(jīng)編碼3D視頻位流內(nèi)部的SEI消息中。因此，MMS服務(wù)器/中繼器B在經(jīng)編碼位流上執(zhí)行額外處理，即，解碼位流以提取關(guān)于麗S的3D視頻內(nèi)容的信息，以便執(zhí)行適當(dāng)?shù)膬?nèi)容適配。另一方面，多視圖視頻編碼H.264/MVC使用AVC文件格式的擴(kuò)展和元數(shù)據(jù)中的單獨(dú)的信令，即，在經(jīng)編碼3D視頻位流外部。因此，MMS服務(wù)器/中繼器B并不需要執(zhí)行額外的解碼來提取信息并且按與H.264/AVC經(jīng)編碼3D視頻內(nèi)容的情況相同的方式，所以額外的復(fù)雜性減小。
[0036]在幀兼容或時間交錯幀封裝格式中使用3GPP MMS規(guī)范的當(dāng)前版本輸送3D視頻確保UE將能夠正確地解碼位流，前提是所述UE具有對應(yīng)的解碼能力。然而，規(guī)范并不能確保UE正確地再現(xiàn)3D視頻。舉例來說，未察覺指示出位流表示幀兼容3D或時間交錯3D的SEI消息的UE簡單地將視頻幀再現(xiàn)為具有兩個并排(頂部底部)視圖的一個2D幀或表示3D視頻的兩個單獨(dú)的視圖的連續(xù)的2D幀。因此這引起了降級的用戶體驗(yàn)。目前，如上所述的UAProf或3GPP中的裝置能力配置文件都無法提供關(guān)于裝置的3D再現(xiàn)能力的信息，即，關(guān)于裝置支持的幀封裝格式的信息。因此，MMS服務(wù)器/中繼器B并不具有全部信息來執(zhí)行適當(dāng)?shù)膬?nèi)容適配以及確保裝置互操作性。


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

[0037]本發(fā)明的目標(biāo)是改進(jìn)網(wǎng)絡(luò)輸送3D視頻中(尤其是根據(jù)3GPP麗S規(guī)范的網(wǎng)絡(luò)中)的用戶設(shè)備的互操作性。
[0038]此目標(biāo)是通過獨(dú)立權(quán)利要求的特征實(shí)現(xiàn)的。根據(jù)從屬權(quán)利要求、說明書和附圖，其他實(shí)施形式是顯而易見的。
[0039]本發(fā)明是基于如下發(fā)現(xiàn)的:通過使用用于輸送3GPP彩信服務(wù)的新方法，尤其是MMS服務(wù)器/中繼器B與MMS用戶代理B之間的新信令，互操作性得到了改進(jìn)。此新方法是基于在執(zhí)行內(nèi)容適配之前通過MMS服務(wù)器/中繼器B向MMS用戶代理B提供MMS 3D內(nèi)容的多個替代的選擇或選項(xiàng)，例如，2D、3D，這兩者等來確定的。由于此新方法，內(nèi)容適配不會受限于UAProf信息，而且還會考慮到終端用戶偏好。此外，通過應(yīng)用關(guān)于包含在MMS中的3D視頻內(nèi)容的后解碼器要求的新信令信息，互操作性得到了改進(jìn)。信令信息是在元數(shù)據(jù)中發(fā)送的，也就是說，在3D視頻經(jīng)編碼位流外部。由于額外信息，可以在MMS服務(wù)器/中繼器B或接收方MMS用戶代理B上引入用于解決3D MMS互操作性問題的多個彩信(MM)適配機(jī)構(gòu)，由此改進(jìn)用戶設(shè)備與網(wǎng)絡(luò)的互操作性。另外，UAP1f的新詞匯，S卩，PSS詞匯的擴(kuò)展允許MMS服務(wù)器/中繼器B為3D可用裝置的適當(dāng)?shù)暮蠼獯a器能力正確地執(zhí)行內(nèi)容適配。
[0040]通過應(yīng)用如將在下文中呈現(xiàn)的用于輸送3GPP彩信服務(wù)的此類方法，互操作性得到了顯著改進(jìn)。
[0041]為了詳細(xì)描述本發(fā)明，將使用以下術(shù)語、縮寫和符號:
[0042]3D:三維，
[0043]MM:彩信，
[0044]MMS:彩信服務(wù)，
[0045]AVC:高級視頻編碼，
[0046]SE1:輔助增強(qiáng)信息，
[0047]MVC:多視圖視頻編碼，
[0048]UE:用戶設(shè)備，
[0049]MIME:根據(jù)RFC2046的多用途網(wǎng)絡(luò)郵件擴(kuò)展，
[0050]HTML:超文本標(biāo)記語言，
[0051 ] UAProf:用戶代理配置文件，
[0052]OMA:開放移動聯(lián)盟，
[0053]CP1:能力和偏好信息，
[0054]W3C:萬維網(wǎng)聯(lián)盟，
[0055]CC/PP:復(fù)合能力/偏好配置文件，
[0056]RDF:資源描述框架，
[0057]WSP:無線會話協(xié)議，
[0058]HTTP:超文本傳送協(xié)議，
[0059]WAP:無線應(yīng)用協(xié)議，
[0060]URL:統(tǒng)一資源定位符，
[0061]PSS:包交換流媒體服務(wù)，
[0062]SMIL:同步多媒體集成語言，
[0063]UA:用戶代理，
[0064]VAS:增值服務(wù)，
[0065]UR1:統(tǒng)一資源識別符。
[0066]出于支持彩信的目的，應(yīng)將術(shù)語“多媒體網(wǎng)絡(luò)或網(wǎng)絡(luò)”視為包含移動運(yùn)營商的網(wǎng)絡(luò)和可以存在于移動運(yùn)營商的網(wǎng)絡(luò)外部的任何功能，例如，固定的互聯(lián)網(wǎng)和多媒體技術(shù)等，以及該功能提供的對于彩信的支持。
[0067]根據(jù)第一方面，本發(fā)明涉及一種用于從服務(wù)器或中繼器向多媒體網(wǎng)絡(luò)中的用戶代理提供彩信服務(wù)(MMS)的方法，所述方法包括:通過服務(wù)器或中繼器確定視頻內(nèi)容的視頻內(nèi)容特征；確定用戶代理的顯示和/或解碼能力；發(fā)信號通知用戶代理視頻內(nèi)容的選項(xiàng)；以及根據(jù)顯示和/或解碼能力并且根據(jù)經(jīng)由用戶代理選定的選項(xiàng)從視頻內(nèi)容的發(fā)信號通知的選項(xiàng)提供視頻內(nèi)容。
[0068]通過使用輸送彩信服務(wù)的新方法，尤其是服務(wù)器或中繼器之間的新的信令，用戶代理互操作性得到了改進(jìn)。
[0069]在根據(jù)第一方面的方法的第一可能實(shí)施形式中，多媒體網(wǎng)絡(luò)是根據(jù)3GPP彩信服務(wù)規(guī)范的網(wǎng)絡(luò)，例如，根據(jù)3GPP TS 22.140:“技術(shù)規(guī)范組服務(wù)和系統(tǒng)方面；彩信服務(wù)(MMS) ;1級(版本10)”；3GPP TS 22.140 技術(shù)規(guī)范組組核心網(wǎng)絡(luò)和終端；彩信服務(wù)(MMS);功能說明；2級(版本6) ”或稍后譯本和/或版本。
[0070]根據(jù)第一實(shí)施形式的新方法增強(qiáng)了根據(jù)3GPP MMS標(biāo)準(zhǔn)化的網(wǎng)絡(luò)中的互操作性。
[0071]在照此根據(jù)第一方面或根據(jù)第一方面的第一實(shí)施形式的方法的第二可能的實(shí)施形式中，服務(wù)器或中繼器是根據(jù)3GPP彩信服務(wù)規(guī)范的麗S服務(wù)器/中繼器B，例如，根據(jù)3GPP TS 22.140 技術(shù)規(guī)范組核心網(wǎng)絡(luò)和終端；彩信服務(wù)(MMS);功能說明；2級(版本6) ”或稍后譯本和/或版本；其中用戶代理是根據(jù)3GPP彩信服務(wù)規(guī)范的MMS用戶代理B，例如，3GPP TS 22.140 技術(shù)規(guī)范組核心網(wǎng)絡(luò)和終端；彩信服務(wù)(MMS);功能說明；2級(版本6) ”或稍后譯本和/或版本；并且其中視頻內(nèi)容是根據(jù)3GPP彩信服務(wù)規(guī)范的MMS視頻內(nèi)容。
[0072]所述新方法可以根據(jù)3GPP彩信服務(wù)規(guī)范應(yīng)用于麗S服務(wù)器/中繼器B和麗S用戶代理B。在消息協(xié)議中僅需要較小的提高，而這對舊版終端是透明的。
[0073]在照此根據(jù)第一方面或根據(jù)第一方面的任何前述實(shí)施形式的方法的第三可能的實(shí)施形式中，到用戶代理的視頻內(nèi)容的信令選項(xiàng)包括將視頻內(nèi)容的所有可能的選項(xiàng)發(fā)信號通知給用戶代理。
[0074]因此用戶可以在發(fā)信號通知給用戶代理的可用的選項(xiàng)之間進(jìn)行選擇。
[0075]在照此根據(jù)第一方面或根據(jù)第一方面的任何前述實(shí)施形式的方法的第四可能的實(shí)施形式中，視頻內(nèi)容的選項(xiàng)包括以下項(xiàng)中的一者:2D、3D，這二者等等。
[0076]服務(wù)器或中繼器可以執(zhí)行3D視頻文件的適配以將它編碼為用于舊版裝置的2D內(nèi)容，或轉(zhuǎn)碼為用于支持根據(jù)第四實(shí)施形式的方法的裝置支持的3D格式。
[0077]在照此根據(jù)第一方面或根據(jù)第一方面的任何前述實(shí)施形式的方法的第五可能的實(shí)施形式中，視頻內(nèi)容特征是基于外部元數(shù)據(jù)確定的。
[0078]當(dāng)視頻內(nèi)容特征基于外部元數(shù)據(jù)確定時，不需要解碼來獲取視頻內(nèi)容特征。
[0079]在根據(jù)第一方面的第五實(shí)施形式的方法的第六可能的實(shí)施形式中，外部元數(shù)據(jù)包括指示3D視頻位流的3D幀封裝格式的呈現(xiàn)類型消息字段。
[0080]3D視頻位流的3D幀封裝格式可以通過使用可供使用的信令協(xié)議傳送，僅需要不顯著的變化。因此，實(shí)施是具有計(jì)算效率的。
[0081]在根據(jù)第一方面的第六實(shí)施形式的方法的第七可能的實(shí)施形式中，3D視頻位流的3D幀封裝格式包括以下格式中的一者:并排、頂部-底部、時間交錯。
[0082]通過弓丨入這些格式，服務(wù)器不需要解碼視頻內(nèi)容來獲得視頻內(nèi)容特征。
[0083]在照此根據(jù)第一方面或根據(jù)第一方面的任何前述實(shí)施形式的方法的第八可能的實(shí)施形式中，確定顯示和/或解碼能力包括基于用戶代理的分析信息，尤其是基于根據(jù)開放移動聯(lián)盟規(guī)范的UAProf信息確定顯示和/或解碼能力。
[0084]UAProf的新詞匯，即，PSS詞匯的擴(kuò)展允許麗S服務(wù)器/中繼器B正確地對3D可用裝置的適當(dāng)?shù)暮蠼獯a器能力執(zhí)行內(nèi)容適配。
[0085]在照此根據(jù)第一方面或根據(jù)第一方面的任何前述實(shí)施形式的方法的第九可能的實(shí)施形式中，到用戶代理的視頻內(nèi)容的信令選項(xiàng)是從服務(wù)器或中繼器中提供的，尤其是通過使用根據(jù)開放移動聯(lián)盟規(guī)范的M-N0TIFICAT10N.1ND消息，例如根據(jù)“彩信服務(wù)封裝協(xié)議”。
[0086]增強(qiáng)型消息M-N0TIFICAT10N.1ND可以根據(jù)3GPP彩信服務(wù)規(guī)范應(yīng)用于MMS服務(wù)器/中繼器B和MMS用戶代理B。對于舊版終端，新信令選項(xiàng)是透明的，由此不會影響它們的操作模式。
[0087]在照此根據(jù)第一方面或根據(jù)第一方面的任何前述實(shí)施形式的方法的第十可能的實(shí)施形式中，所述方法包括:告知用戶關(guān)于發(fā)信號通知給用戶代理的視頻內(nèi)容的選項(xiàng)。
[0088]因此用戶可以給出關(guān)于所希望選項(xiàng)的反饋。這改進(jìn)了體驗(yàn)質(zhì)量。
[0089]在根據(jù)第一方面的第十實(shí)施形式的方法的第^^一可能的實(shí)施形式中，所述方法包括:從用戶代理向服務(wù)器或中繼器指示來自視頻內(nèi)容的選項(xiàng)的選定選項(xiàng)，尤其通過使用根據(jù)HTTP標(biāo)準(zhǔn)的GET REQUEST消息的標(biāo)題字段，例如，根據(jù)IETF RFC 2616 超文本傳送協(xié)議一HTTP/1.1”或稍后版本。
[0090]新方法進(jìn)一步與HTTP標(biāo)準(zhǔn)化兼容。
[0091]在根據(jù)第一方面的第^^一實(shí)施形式的方法的第十二可能的實(shí)施形式中，所述方法包括:將用戶代理重新定向到支持選定選項(xiàng)的終端，尤其通過使用根據(jù)HTTP標(biāo)準(zhǔn)的REDIRECT消息，例如，根據(jù)IETF RFC 2616 超文本傳送協(xié)議一HTTP/1.1”或稍后版本。
[0092]重新定向僅僅是針對根據(jù)第十二實(shí)施形式的裝置執(zhí)行的；重新定向?qū)τ谂f版裝置是透明的。因此，根據(jù)第十二實(shí)施形式的裝置的互操作性得到了改進(jìn)并且舊版裝置的操作未受到影響。
[0093]在根據(jù)第一方面的任何實(shí)施形式的或照此根據(jù)第一方面的方法的第十三可能的實(shí)施形式中，其中所述方法進(jìn)一步包括在提供視頻內(nèi)容之前:通過或經(jīng)由用戶代理向用戶顯示發(fā)信號通知的選項(xiàng)，并且通過用戶代理由用戶從發(fā)信號通知的選項(xiàng)中選擇一個選項(xiàng)。
[0094]在根據(jù)第一方面的任何實(shí)施形式的或照此根據(jù)第一方面的方法的第十四可能的實(shí)施形式中，其中所述視頻內(nèi)容是3D視頻。
[0095]根據(jù)第二方面，本發(fā)明涉及一種用戶代理裝置，尤其是根據(jù)3GPP彩信服務(wù)規(guī)范的MMS用戶代理B裝置，包括處理電路，其配置用于確定用戶代理裝置的顯示和/或解碼能力；接收由服務(wù)器或中繼器發(fā)信號通知的視頻內(nèi)容的選項(xiàng)，尤其通過根據(jù)3GPP彩信服務(wù)規(guī)范的MMS服務(wù)器/中繼器B裝置；并且根據(jù)顯示和/或解碼能力以及根據(jù)根據(jù)用戶偏好的視頻內(nèi)容的選項(xiàng)來提供視頻內(nèi)容。
[0096]應(yīng)用用于輸送3GPP彩信服務(wù)的新方法，尤其是在麗S服務(wù)器/中繼器B與麗S用戶代理B之間的新信令的用戶代理裝置可以改進(jìn)它們在MMS網(wǎng)絡(luò)中的互操作性。MMS 3D內(nèi)容的多個替代的選擇或選項(xiàng)，例如，2D、3D、這兩者等在執(zhí)行內(nèi)容適配之前被提供到麗S用戶代理B。內(nèi)容適配未受UAProf信息的限制，而且還考慮到終端用戶偏好。此外，通過應(yīng)用關(guān)于包含在MMS中的3D視頻內(nèi)容的后解碼器要求的新信令信息，互操作性得到了改進(jìn)。
[0097]根據(jù)第三方面，本發(fā)明涉及一種服務(wù)器或中繼器裝置，尤其是根據(jù)3GPP彩信服務(wù)規(guī)范的MMS服務(wù)器/中繼器B裝置，包括處理電路，其配置用于確定視頻內(nèi)容特征；向用戶代理裝置，尤其是向根據(jù)3GPP彩信服務(wù)規(guī)范的MMS用戶代理B裝置發(fā)信號通知視頻內(nèi)容的選項(xiàng)；以及根據(jù)用戶的偏好根據(jù)用戶代理裝置的顯示和/或解碼能力并且根據(jù)視頻內(nèi)容的選項(xiàng)提供視頻內(nèi)容。
[0098]服務(wù)器或中繼器裝置可以類似地改進(jìn)它們在MMS網(wǎng)絡(luò)中的互操作性，如同上述用戶代理裝置。
[0099]本文中所描述的方法可以實(shí)施為數(shù)字信號處理器(DSP)、微控制器或任何其他輔助處理器中的軟件或?qū)嵤閷Ｓ眉呻娐?ASIC)內(nèi)的硬件電路。
[0100]本發(fā)明可以在數(shù)字電子電路中實(shí)施，或在計(jì)算機(jī)硬件、固件、軟件或其組合中實(shí)施。

【專利附圖】

【附圖說明】
[0101]將參考以下附圖描述本發(fā)明的其他實(shí)施例，其中:
[0102]圖1示出了根據(jù)一個實(shí)施形式的用于提供彩信服務(wù)的方法的示意圖；
[0103]圖2示出了根據(jù)一個實(shí)施形式的服務(wù)器或中繼器裝置與用戶代理裝置之間的消息協(xié)議200的不意圖；
[0104]圖3示出了根據(jù)一個實(shí)施形式的指示3D視頻位流的3D幀封裝格式的呈現(xiàn)類型消息字段的示意圖；
[0105]圖4示出了根據(jù)一個實(shí)施形式的包括呈現(xiàn)類型信息的麗S信令信息的示意圖；
[0106]圖5示出了根據(jù)一個實(shí)施形式的用戶代理的分析信息的示意圖；
[0107]圖6示出了常規(guī)的MME(多部分互聯(lián)網(wǎng)郵件擴(kuò)展)封裝消息的示意圖；
[0108]圖7示出了常規(guī)的SMIL(同步多媒體集成語言)消息的示意圖；
[0109]圖8示出了根據(jù)技術(shù)規(guī)范3GPP TS 23.140的常規(guī)的麗S架構(gòu)的框圖；
[0110]圖9示出了根據(jù)3GPP規(guī)范的常規(guī)彩信的框圖；
[0111]圖10示出了根據(jù)技術(shù)規(guī)范3GPP TS 23.140的麗S服務(wù)器/中繼器B與麗S用戶代理B之間的消息順序圖。

【具體實(shí)施方式】
[0112]圖1示出了根據(jù)一個實(shí)施形式的用于提供彩信服務(wù)的方法100的示意圖。
[0113]方法100從服務(wù)器或中繼器向多媒體網(wǎng)絡(luò)中的用戶代理提供彩信服務(wù)。方法100包括通過服務(wù)器或中繼器確定101視頻內(nèi)容特征。方法100包括確定103用戶代理的顯示和/或解碼能力。方法100包括將視頻內(nèi)容的選項(xiàng)發(fā)信號通知105給用戶代理。方法100包括根據(jù)用戶的偏好根據(jù)顯示和/或解碼能力并且根據(jù)視頻內(nèi)容的選項(xiàng)提供107視頻內(nèi)容。
[0114]服務(wù)器或中繼器可以對應(yīng)于如參考圖8描述的MMS服務(wù)器/中繼器B835。用戶代理可以對應(yīng)于如參考圖8描述的MMS用戶代理B 831。向用戶代理發(fā)信號通知105視頻內(nèi)容的選項(xiàng)可以通過使用如參考圖2說明的M-Notificat1n-1nd消息211來執(zhí)行，其中如圖2中所說明的M-Notif icat1n-1nd消息211通過包括選項(xiàng)的額外的選項(xiàng)字段擴(kuò)展。服務(wù)器或中繼器可以對應(yīng)于在圖2中描繪的MMS服務(wù)器/中繼器B 201，并且用戶代理可以對應(yīng)于在圖2中描繪的麗S用戶代理B 203，其中麗S服務(wù)器/中繼器B 201和麗S用戶代理B203用于提供并且接收此額外的選項(xiàng)字段。用戶可以根據(jù)用戶代理的顯示和/或解碼能力在視頻內(nèi)容的發(fā)信號通知的可用選項(xiàng)之間進(jìn)行選擇。根據(jù)用戶的偏好，視頻內(nèi)容將被輸送。
[0115]圖2示出了根據(jù)一個實(shí)施形式的服務(wù)器或中繼器裝置201與用戶代理裝置203之間的消息協(xié)議200的示意圖。基礎(chǔ)消息協(xié)議對應(yīng)于如參考圖10描述的消息協(xié)議。也就是說，無需額外選項(xiàng)字段的Μ-Notificat1n, ind消息211對應(yīng)于圖10中描繪的Μ-Notificat1n, ind消息1011，無需額外選項(xiàng)字段的HTTP Get.req消息212對應(yīng)于圖10中描繪的HTTP Get.req消息1012，無需選定的URI字段的M-retrieve.conf消息215對應(yīng)于在圖10中描繪的M-retrieve.conf消息1015，并且無需選定的URI字段且無需額外的選項(xiàng)字段的M-NotifyResp.1nd消息216對應(yīng)于在圖10中描繪的M-NotifyResp.1nd消息1016。
[0116]如圖2中所描繪的用于輸送3GPP彩信服務(wù)的新方法200引入額外的步驟，其中有可能選擇麗S內(nèi)容編碼的不同選項(xiàng)221的信息在Μ-Notificat1n, ind消息211中通過麗S服務(wù)器/中繼器B 201提供給MMS用戶代理B 203。用于M-Notif icat1n.1nd PDU 211的新選項(xiàng)標(biāo)題字段如下文中所定義。所述過程在圖2中呈現(xiàn)。首先，MMS服務(wù)器/中繼器B 201向麗S用戶代理B 203發(fā)布具有3D視頻的URI的通知211。此外，提供M-Notif icat1n.1nd PDU 211中的新“選項(xiàng)”字段221。通過該字段通知支持的終端:該終端可以決定并且指示它是否需要3D或2D內(nèi)容或這兩種版本或不同的支持3D的解碼/顯示格式?！斑x項(xiàng)”字段221是被舊版MMS用戶代理忽略的并且內(nèi)容是使用以標(biāo)準(zhǔn)方式提供的URI通過舊版終端提取的。
[0117]支持新標(biāo)題字段的麗S用戶代理向麗S服務(wù)器/中繼器B 201發(fā)布指示用戶所選擇的(意味著根據(jù)用戶的偏好)編碼方法的具有新“選項(xiàng)”標(biāo)題字段221的GET請求212。通過MMS用戶代理B 203發(fā)布的GET請求212中的“選項(xiàng)”字段可以根據(jù)RFC 2616 (http://www.1etf.0rg/rfc/rfc2616.txt)被規(guī)定為新的請求標(biāo)題字段。在支持的終端包含GET請求212中的新“選項(xiàng)”標(biāo)題字段的情況下，隨后MMS服務(wù)器/中繼器B 201相應(yīng)地作用并且與具有指示新的selected_uri的重新定向消息213的MMS用戶代理B 203相對應(yīng)。此后，MMS用戶代理B發(fā)布具有新selected_uri的Get.req消息214。在MMS用戶代理B 203經(jīng)重新定向到selected_uri之后，它開始以標(biāo)準(zhǔn)方式但是通過使用selected_uri和選擇的選項(xiàng)字段223提取麗S內(nèi)容。
[0118]圖3示出了根據(jù)一個實(shí)施形式的指示3D視頻位流的3D幀封裝格式的呈現(xiàn)類型消息字段300的示意圖。
[0119]在MMS規(guī)范中，幀封裝格式是在輔助增強(qiáng)信息(SEI)消息中指示的。因此，麗S服務(wù)器/中繼器必須執(zhí)行額外處理以獲取接收到的內(nèi)容是3D內(nèi)容的信息。額外處理需要解碼步驟。在圖3中描繪的實(shí)施形式中，提供關(guān)于MME多部分格式的3D視頻的后解碼器信令信息。指示3D視頻位流的3D幀封裝格式的呈現(xiàn)類型消息字段包括不同的可能呈現(xiàn)類型，艮P，類型“并排” 301、“頂部-底部” 302、“時間交錯” 303等的信令信息。
[0120]圖4示出了根據(jù)一個實(shí)施形式的包括呈現(xiàn)類型信息的麗S信令信息400的示意圖。
[0121]麗S包括如圖4中說明的新定義的“呈現(xiàn)類型”信息。識別新信令信息的麗S服務(wù)器/中繼器能夠識別3D內(nèi)容和其編碼形式而無需解碼位流。MMS信令信息400可以對應(yīng)于如圖9中所描繪的麗S信令信息，但是在圖9中描繪的視頻內(nèi)容901通過額外的呈現(xiàn)類型信息401增強(qiáng)，所述額外的呈現(xiàn)類型信息在此處是類型“并排”的。當(dāng)然，此額外的呈現(xiàn)類型信息401可以是在圖3中所說明的呈現(xiàn)類型消息字段300中定義的任何其他類型，例如，頂部-底部、時間交錯等。
[0122]圖5示出了根據(jù)一個實(shí)施形式的用戶代理的分析信息500的示意圖。引入了指示裝置的再現(xiàn)能力的UAP1f中的新詞匯。圖5示出了此類新詞匯的示例性定義。
[0123]新詞匯提供了名稱為“3DRenderingSupport”的新屬性。其法定值是“并排”、“頂部-底部”和“時間交錯”。
[0124]基于在UAProf中指示的或在接收方麗S用戶代理B和麗S服務(wù)器/中繼器B的能力協(xié)商期間獲取的后解碼器信令和接收方能力，MMS服務(wù)器/中繼器B執(zhí)行3D視頻文件的適配以將它編碼為用于舊版裝置的2D內(nèi)容，或轉(zhuǎn)碼到提供UAP1f中的新詞匯的支持3D格式的裝置中。
[0125]服務(wù)器/中繼器B和麗S服務(wù)器/中繼器B可以對應(yīng)于在圖8中描繪的裝置835、831或當(dāng)被增強(qiáng)以提供UAProf中的新詞匯時對應(yīng)于在圖10中描繪的裝置1001和1003。
[0126]根據(jù)上文，提供關(guān)于錄音媒體的各種方法、系統(tǒng)、計(jì)算機(jī)程序以及類似者對于所屬領(lǐng)域的技術(shù)人員而言是顯而易見的。
[0127]本發(fā)明還支持包含計(jì)算機(jī)可執(zhí)行代碼或者計(jì)算機(jī)可執(zhí)行指令的計(jì)算機(jī)程序產(chǎn)品，當(dāng)執(zhí)行時所述計(jì)算機(jī)可執(zhí)行代碼或所述計(jì)算機(jī)可執(zhí)行指令引起至少一個計(jì)算機(jī)執(zhí)行本文中所描述的執(zhí)行和計(jì)算步驟。
[0128]本發(fā)明還支持用于執(zhí)行本文中所描述的執(zhí)行和計(jì)算步驟的系統(tǒng)。
[0129]根據(jù)上述教示，許多替代方式、修改和變型對于所屬領(lǐng)域的技術(shù)人員而言將是顯而易見的。當(dāng)然，所屬領(lǐng)域的技術(shù)人員容易認(rèn)識到，除了本文中所描述的那些應(yīng)用之外，存在許多本發(fā)明的應(yīng)用。盡管已參考一個或多個特定實(shí)施例描述本發(fā)明，但是所屬領(lǐng)域的技術(shù)人員將認(rèn)識到，在不脫離本發(fā)明的精神和范圍的情況下可以對本發(fā)明作出許多改變。因此，應(yīng)理解，在所附權(quán)利要求書及其等效物的范圍內(nèi)，可以以不同于如本文中所具體描述的方式實(shí)踐本發(fā)明。
[0130]本發(fā)明的實(shí)施例可以尤其在UMTS(通用移動電信系統(tǒng))和LTE(長期演進(jìn))網(wǎng)絡(luò)中實(shí)施。
【權(quán)利要求】
1.一種用于從服務(wù)器或中繼器(201)向多媒體網(wǎng)絡(luò)中的用戶代理(203)提供彩信服務(wù)(MMS)的方法(100、200)，所述方法(100,200)包括: 通過所述服務(wù)器或中繼器(201)確定(101)視頻內(nèi)容的視頻內(nèi)容特征； 將所述視頻內(nèi)容的選項(xiàng)(221)發(fā)信號通知(105)給所述用戶代理(203);以及 根據(jù)所述顯示和/或解碼能力并且根據(jù)通過所述用戶代理從所述視頻內(nèi)容的發(fā)信號通知的選項(xiàng)(221)中選擇的選項(xiàng)(223)提供(107)所述視頻內(nèi)容。
2.根據(jù)權(quán)利要求1所述的方法(100、200)，其中所述多媒體網(wǎng)絡(luò)是根據(jù)3GPP彩信服務(wù)規(guī)范的網(wǎng)絡(luò)(803)。
3.根據(jù)權(quán)利要求1或權(quán)利要求2所述的方法(100、200)，其中所述服務(wù)器或中繼器(201)是根據(jù)3GPP彩信服務(wù)規(guī)范的麗S服務(wù)器/中繼器B ;其中所述用戶代理(203)是根據(jù)所述3GPP彩信服務(wù)規(guī)范的MMS用戶代理B ;并且其中所述視頻內(nèi)容是根據(jù)所述3GPP彩信服務(wù)規(guī)范的麗S視頻內(nèi)容。
4.根據(jù)前述權(quán)利要求中的任一項(xiàng)所述的方法(100、200)，其中將視頻內(nèi)容的選項(xiàng)(221)發(fā)信號通知給所述用戶代理(203)包括將所述視頻內(nèi)容的所有可能的選項(xiàng)發(fā)信號通知給所述用戶代理(203)。
5.根據(jù)前述權(quán)利要求中的任一項(xiàng)所述的方法(100、200)，其中所述視頻內(nèi)容的所述發(fā)信號通知的選項(xiàng)(221)包括以下項(xiàng)中的一者:2D、3D、2D和3D、或其他。
6.根據(jù)前述權(quán)利要求中的任一項(xiàng)所述的方法(100、200)，其中所述視頻內(nèi)容特征是基于外部元數(shù)據(jù)確定的。
7.根據(jù)權(quán)利要求6所述的方法(100、200)，其中所述視頻內(nèi)容是3D視頻并且所述外部元數(shù)據(jù)包括指示所述3D視頻位流的3D幀封裝格式的呈現(xiàn)類型消息字段(300)。
8.根據(jù)權(quán)利要求7所述的方法(100、200)，其中所述3D視頻位流的所述3D幀封裝格式包括以下格式中的一者:并排(301)、頂部-底部(302)、時間交錯(303)。
9.根據(jù)前述權(quán)利要求中的任一項(xiàng)所述的方法(100、200)，其中所述方法進(jìn)一步包括: 確定(103)所述用戶代理(203)的顯示和/或解碼能力；并且其中所述確定(103)顯示和/或解碼能力包括基于所述用戶代理(203)的分析信息，尤其基于根據(jù)開放移動聯(lián)盟規(guī)范的UAProf信息確定所述顯示和/或解碼能力。
10.根據(jù)前述權(quán)利要求中的任一項(xiàng)所述的方法(100、200)，其中發(fā)信號通知給所述用戶代理(203)的所述視頻內(nèi)容的選項(xiàng)是由所述服務(wù)器或中繼器(201)提供，尤其是通過使用根據(jù)開放移動聯(lián)盟規(guī)范的M-N0TIFICAT10N.1ND消息(211)提供的。
11.根據(jù)前述權(quán)利要求中的任一項(xiàng)所述的方法(100、200)，其包括:告知所述用戶發(fā)信號通知給所述用戶代理(203)的所述視頻內(nèi)容的所述選項(xiàng)(221)。
12.根據(jù)權(quán)利要求11所述的方法(100、200)，其包括:由所述用戶代理(203)向所述所述服務(wù)器或中繼器(201)指示從所述視頻內(nèi)容的發(fā)信號通知的選項(xiàng)(221)中選擇的選項(xiàng)(223)，尤其通過使用根據(jù)HTTP標(biāo)準(zhǔn)化的GET REQUEST消息(212)的標(biāo)題字段來指示。
13.根據(jù)權(quán)利要求12所述的方法(100、200)，其包括:將所述用戶代理(203)重新定向到支持所述選擇的選項(xiàng)(223)的終端，尤其通過使用根據(jù)HTTP標(biāo)準(zhǔn)的REDIRECT消息(213)來重定向。
14.一種用戶代理裝置(203)，尤其是根據(jù)3GPP彩信服務(wù)規(guī)范的MMS用戶代理B裝置，其包括處理電路(203a)，所述處理電路配置用于 確定(103)所述用戶代理裝置(203)的顯示和/或解碼能力； 接收通過服務(wù)器或中繼器(201)，尤其通過根據(jù)3GPP彩信服務(wù)規(guī)范的MMS服務(wù)器/中繼器B裝置發(fā)信號通知的視頻內(nèi)容的選項(xiàng)(221);并且 根據(jù)所述顯示和/或解碼能力并且根據(jù)根據(jù)用戶的偏好的所述視頻內(nèi)容的所述選項(xiàng)(221)提供(107)所述視頻內(nèi)容。
15.一種服務(wù)器或中繼器裝置(201)，尤其是根據(jù)3GPP彩信服務(wù)規(guī)范的麗S服務(wù)器/中繼器B裝置，其包括處理電路(201a)，所述處理電路配置用于 將所述視頻內(nèi)容的選項(xiàng)(221)發(fā)信號通知(105)給用戶代理裝置(203)，尤其是根據(jù)3GPP彩信服務(wù)規(guī)范的MMS用戶代理B裝置；并且 根據(jù)所述用戶代理裝置(203)的顯示和/或解碼能力并且根據(jù)通過所述用戶代理裝置(203)從所述視頻內(nèi)容的發(fā)信號通知的選項(xiàng)(221)中選擇的選項(xiàng)提供(107)所述視頻內(nèi)容。
【文檔編號】H04L29/06GK104509139SQ201280074975
【公開日】2015年4月8日 申請日期:2012年8月6日 優(yōu)先權(quán)日:2012年8月6日
【發(fā)明者】愛默德·鮑阿齊齊, 基奧萬尼·科達(dá)拉, 盧卡斯·康德拉德 申請人:華為技術(shù)有限公司