專利名稱:向設(shè)備發(fā)送信令以不執(zhí)行同步或在多媒體流上包括同步延遲的方法
技術(shù)領(lǐng)域:
本發(fā)明一般涉及IP多媒體通信領(lǐng)域。更特別地,本發(fā)明涉及用 于多媒體通信的信令機(jī)制以指令接收設(shè)備不執(zhí)行同步或包括不同多 媒體流之間的同步抖動(dòng)。
背景技術(shù):
在IP多媒體呼叫建立期間,呼叫的發(fā)送設(shè)備(即提供端或發(fā)啟 端)指定會(huì)話信息。會(huì)話信息包括媒體和與傳輸相關(guān)的信息。會(huì)話
信息承載于例如會(huì)話描述協(xié)議(SDP)的協(xié)議消息中。SDP承載于例 如會(huì)話發(fā)起協(xié)議(SIP)和實(shí)時(shí)流協(xié)議(RTSP)等的高級(jí)信令協(xié)議中。 第三代合作伙伴項(xiàng)目(3GPP)將SIP指定為IP多媒體子系統(tǒng)(IMS) 的多媒體會(huì)話建立的信令協(xié)議的選擇。
在SDP中,發(fā)送設(shè)備和接收設(shè)備可以為多媒體流指定不同的方 向,從而得到不同類型的應(yīng)用。例如,如果發(fā)送設(shè)備希望建立單向 媒體會(huì)話(即其希望發(fā)送視頻并且希望接收設(shè)備只接收該視頻), 則其在SDP中指定該々某體流為a-sendonly。當(dāng)接收設(shè)備接收該SDP 消息時(shí)并且如果其希望參與到該會(huì)話中,則接收設(shè)備可以指定該流 為a=recvonly。對(duì)于視頻電話呼叫,發(fā)送設(shè)備和接收設(shè)備都指定力某 體流的方向?yàn)閍=sendrecv。
通常,在IP多媒體呼叫中,在接收設(shè)備側(cè)存在同步不同媒體類 型的需求。例如,在音頻/視頻IP呼叫中,為了好的用戶體驗(yàn)需要 在接收設(shè)備側(cè)執(zhí)行唇音同步。同步的另一個(gè)示例涉及字幕的使用; 如果音頻和/或視頻的發(fā)送端正在說英語(yǔ)并且如果在講話的同時(shí),在 不同的實(shí)時(shí)傳輸協(xié)議(RTP)流中在用不同的語(yǔ)言發(fā)送講話的文字, 則需要在接收設(shè)備側(cè)同步這兩個(gè)流。不同的媒體流(來自發(fā)送設(shè)備側(cè))承載于不同的RTP/用戶數(shù)據(jù) 協(xié)議(UDP ) /互聯(lián)網(wǎng)協(xié)議(IP )流中。RTP時(shí)間戳被接收設(shè)備客戶端 用來執(zhí)行媒體間同步。
圖1描述了從發(fā)送設(shè)備接收多媒體流的接收設(shè)備。橫軸表示逝去 的時(shí)間并且示出接收的分組。圖1中示出的音頻和視頻緩沖器在從 發(fā)送設(shè)備接收分組時(shí)保存RTP分組。緩沖器執(zhí)行抖動(dòng)消除(來自網(wǎng) 絡(luò)的)并且為每個(gè)々某體的每個(gè)分組計(jì)算播出時(shí)間(playout time)。 一旦分組在緩沖器中保留了一段給定的時(shí)間,則執(zhí)行解碼。該時(shí)間 段通常是變化的并且該時(shí)間段的 一 部分稱為抖動(dòng)。 一 旦基于播出時(shí) 間完成了解碼,則將分組用于顯示或用于播放。應(yīng)當(dāng)理解,可以有 兩個(gè)不同的緩沖器用于保存進(jìn)入的RTP分組-一個(gè)用于抖動(dòng), 一個(gè) 用于解碼排隊(duì)。為了清晰和示例性的目的,在圖l中僅示出了一個(gè) 排隊(duì),其中示出了結(jié)合的抖動(dòng)和解碼緩沖器。解碼后, 一旦經(jīng)過了 播出時(shí)間,分組就可以用于播放或顯示。然而,如果接收設(shè)備試圖 執(zhí)行音頻/視頻同步,則其將試圖延遲首先到達(dá)的分組。
在圖1所示的示例中,音頻分組1在TA1處到達(dá),并且一見頻分組 在時(shí)間上較晚于TA1的TV1處到達(dá)。應(yīng)當(dāng)理解,術(shù)語(yǔ)"到達(dá)"可以 代表分組到達(dá)的時(shí)間或每個(gè)分組的播出時(shí)間。在圖l的示例中,需 要同步具有相同的播放時(shí)間的音頻和視頻分組,因?yàn)樗鼈兙哂邢嗤?的基準(zhǔn)時(shí)鐘捕獲時(shí)間(在發(fā)送設(shè)備處),即在發(fā)送設(shè)備處它們是在 相同的時(shí)間得以采樣。使用在RTP分組中的RTP時(shí)間戳和在RTCP發(fā) 送端報(bào)告(SR)分組中發(fā)送的NTP時(shí)間戳,執(zhí)行基準(zhǔn)時(shí)鐘捕獲時(shí)間 的計(jì)算。音頻和視頻分組很有可能在不同的時(shí)間到達(dá)接收設(shè)備處, 因?yàn)樗鼈兛赡芙?jīng)過不同的網(wǎng)絡(luò)路徑,并且每個(gè)分組的處理延遲(編 碼,分組化,解分組化,解碼)可以不同。因此在圖l所示的示例 中,必須將音頻分組延遲TV1-TA1的時(shí)間段,其為同步抖動(dòng)或延遲。
在圖l所示的示例中,如果應(yīng)用(或發(fā)送端)不試圖執(zhí)行A/V 同步,但接收設(shè)備仍然試圖執(zhí)行同步(因?yàn)槠錇槟J(rèn)的行為),則 接收設(shè)備將被迫將音頻分組保存額外的時(shí)間。該動(dòng)作有可能使音頻 緩沖器溢出。此外,當(dāng)試圖同步時(shí),在排隊(duì)的開頭的音頻分組被延遲,這可以導(dǎo)致差的用戶體驗(yàn)或媒體質(zhì)量。如果要保障服務(wù)質(zhì)量
(QoS),則在音頻和視頻分組在排隊(duì)中有較大的延遲的情況下,將
不得不被丟棄。因此,雖然發(fā)送設(shè)備可能不希望媒體流被同步,但 由于缺乏發(fā)送設(shè)備可以向接收設(shè)備指示不需要同步或延遲的同步的 機(jī)制,可能會(huì)發(fā)生例如分組丟失、延遲的分組和浪費(fèi)計(jì)算資源的問題。
在互聯(lián)網(wǎng)工程任務(wù)組的網(wǎng)絡(luò)工作組的請(qǐng)求說明(RFC) No. 3388 中,指定了發(fā)送設(shè)備可以明確地指定需要同步會(huì)話中的哪些媒體流 的機(jī)制。定義了新的SDP屬性(例如"group" 、"mid"和唇音同 步(LS)),這可以幫助發(fā)送設(shè)備指定需要對(duì)會(huì)話中的哪些媒體流 進(jìn)行唇音同步。另外,RTP接收設(shè)備的默認(rèn)實(shí)現(xiàn)行為是同步從相同的 源接收的媒體流。此外,規(guī)范未規(guī)定如果必須同步多媒體流,則要 求RFC 3388。 RFC 3388只指定了可以使發(fā)送設(shè)備在其發(fā)送兩個(gè)或多 個(gè)流的情況下指定需要同步哪些流的機(jī)制。
存在要求多媒體流不應(yīng)當(dāng)被同步的應(yīng)用和使用情況。例如,在實(shí) 時(shí)視頻共享(RTVS)應(yīng)用中,用戶開始單向視頻共享會(huì)話。通過在 SDP中將媒體流聲明為a=sendonly或a=recvonly,建立單向媒體會(huì) 話。在兩方之間已經(jīng)存在雙向(或可以是單向)音頻會(huì)話建立。呼 叫中的一方希望與另一方共享視頻。盡管有可能音頻或視頻會(huì)話也 可以建立在電路交換載體上,但在IP載體上建立音頻和視頻。共享 的視頻可以是來自文檔或來自現(xiàn)場(chǎng)的攝像鏡頭。
在單向視頻共享的某些情況下,發(fā)送設(shè)備不希望同步視頻(共享 自文檔的)和講話。不期望進(jìn)行同步的一個(gè)原因可能是發(fā)送設(shè)備希 望在接收設(shè)備處接收到高質(zhì)量的視頻,雖然有延遲。在此情況下, 發(fā)送設(shè)備希望接收設(shè)備具有較大的延遲緩沖器并且因此不希望執(zhí)行 同步。
單向視頻共享的另一個(gè)示例涉及用戶正在拍攝某個(gè)物體的視頻 并且在談?wù)撛撐矬w。在此情況下,粗劣形式的同步就足夠了,不必 進(jìn)行完美的同步,因?yàn)榇巳瞬皇窃谂臄z其自己的臉部的視頻而是拍 攝不同的物體。又一個(gè)示例涉及"擴(kuò)大的真實(shí)感",其中將圖形與實(shí)時(shí)音頻和視頻混合。在此情況下,粗劣形式的同步將可以滿足要 求。
如果客戶端的默認(rèn)行為是同步這兩個(gè)流,則接收設(shè)備客戶端將采 用特別的算法以同步這些流。在接收設(shè)備側(cè)的同步算法將要求指定 量的計(jì)算復(fù)雜性,并且甚至在當(dāng)發(fā)送設(shè)備不希望任何同步時(shí),客戶 端也將浪費(fèi)某些資源。音頻和視頻流到達(dá)接收設(shè)備時(shí)可以具有不同 的延遲。如果接收設(shè)備試圖同步這些流,則將導(dǎo)致音頻和視頻幀的 丟棄,因此降低了接收的媒體的質(zhì)量。
遺憾的是,RFC 3388未討論可以明確地確定哪些流不應(yīng)當(dāng)被同 步的機(jī)制。例如,如果發(fā)送設(shè)備希望在會(huì)話中發(fā)送三個(gè)流,兩個(gè)音 頻流(Al和A2)和一個(gè)視頻流(VI),并且發(fā)送設(shè)備希望同步(唇 音同步)流Al和VI,則其可以使用group、 mid-SDP屬性和LS語(yǔ)義 標(biāo)簽加以指定。這將為接收設(shè)備指示Al和VI需要進(jìn)行同步而A2不 需要進(jìn)行同步。但對(duì)于有兩個(gè)或多個(gè)流并且不需要流同步的使用情 況,RFC 3388存在不足。另外,為指示唇音同步的性能(并且在某 些情況下RFC 3388可以用于指定無唇音同步),RFC 3388必須被強(qiáng) 制執(zhí)行。最后,RFC 3388不提供用來使設(shè)備可以指示在不同的媒體 之中的期望的同步抖動(dòng)的機(jī)制。
出于上述原因,目前沒有使發(fā)送設(shè)備可以為多媒體呼叫中的接收 設(shè)備指示不同步由發(fā)送設(shè)備傳輸?shù)亩嗝襟w流的機(jī)制,也不存在為多 媒體流指定同步延遲或抖動(dòng)的機(jī)制。
發(fā)明內(nèi)容
本發(fā)明提供 一 種機(jī)制,其中傳輸或發(fā)送設(shè)備可以明確地指示被發(fā) 送的多媒體流中的哪些流不應(yīng)當(dāng)被同步或應(yīng)當(dāng)包括指定的同步抖動(dòng) 量。該機(jī)制幫助接收設(shè)備理解流特性,并且允許接收設(shè)備做出關(guān)于 是否應(yīng)當(dāng)執(zhí)行同步以及是否指定同步抖動(dòng)值的被告知的決定。對(duì)于 例如單向視頻共享或視頻PoC的某些應(yīng)用,流的發(fā)送設(shè)備可以指示 接收設(shè)備為了更好的媒體質(zhì)量不執(zhí)行任何同步。
本發(fā)明的一個(gè)實(shí)施例涉及若干新SDP屬性的引入。發(fā)送設(shè)備將在會(huì)話建立階段期間在SDP中聲明這些屬性,并且這些屬性可以承載 于任何高級(jí)信令協(xié)議(例如SIP、 RTSP等)中。然而,這些屬性不 限于SDP協(xié)議的使用,并且這些屬性可以使用在ISO 0SI協(xié)議棧的 階層1-7的任何一層上的任何其他的通信協(xié)議(例如XML、 HTTP、 UPnP、 CC/PP等)進(jìn)行定義和承載。
本發(fā)明通過在會(huì)話建立階段期間提供指示發(fā)送設(shè)備不在媒體流 中間進(jìn)行同步的選擇的能力,為常規(guī)的RFC 3388框架提供了實(shí)質(zhì)性 的益處。存在發(fā)送設(shè)備不希望其發(fā)送的媒體被同步的使用情況和應(yīng) 用。當(dāng)該選擇可以以信令發(fā)送給接收設(shè)備時(shí),接收設(shè)備可以相應(yīng)地 建立資源并且不必浪費(fèi)可用于其他任務(wù)或用于更好的媒體質(zhì)量的計(jì) 算資源。作為結(jié)果,本發(fā)明導(dǎo)致了在接收設(shè)備處的較少的分組丟失, 否則如果接收設(shè)備試圖執(zhí)行媒體流同步,將發(fā)生分組丟失。
除上述之外,本發(fā)明通過在會(huì)話建立階段期間提供指示發(fā)送設(shè)備 在媒體流之間的同步抖動(dòng)的選擇的能力改進(jìn)了 RFC 3388。由于也存 在發(fā)送設(shè)備希望發(fā)送的媒體進(jìn)行具有粗劣抖動(dòng)的同步的使用情況和 應(yīng)用,將該選擇用信令發(fā)送到接收設(shè)備的能力允許接收設(shè)備相應(yīng)地 建立資源。這也提供了節(jié)省計(jì)算資源的機(jī)會(huì)。在某些情況下,這還 可以產(chǎn)生媒體質(zhì)量等級(jí)的改善。事實(shí)上,在強(qiáng)制媒體同步的情況下, 由于在接收設(shè)備處的數(shù)據(jù)丟棄或其他原因,可能有某些分組丟失, 如果接收設(shè)備試圖執(zhí)行媒體流同步,就可能發(fā)生分組丟失。這是由 于這樣的事實(shí),即媒體數(shù)據(jù)到達(dá)接收設(shè)備時(shí)有不同的延遲,這將導(dǎo) 致某些內(nèi)容過遲地到達(dá),而不可用于完全同步的播放。通過控制同 步抖動(dòng),可以減輕或消除此問題。
本發(fā)明的這些和其它目標(biāo)、優(yōu)點(diǎn)和特征以及其組織和操作方式將 從下面結(jié)合附圖的詳細(xì)描述中變得顯而易見,其中貫穿以下附圖相 同的元件將具有相同的標(biāo)號(hào)。
圖1是示出了多個(gè)音頻和視頻分組從發(fā)送設(shè)備到接收設(shè)備的傳 輸?shù)谋硎?,其中雖然發(fā)送設(shè)備不要求同步,但接收設(shè)備執(zhí)行同步;圖2為用于本發(fā)明的實(shí)現(xiàn)方式的電子設(shè)備的透視圖3是圖1的電子設(shè)備的電路的示意性表示;以及
圖4是示出了本發(fā)明的一個(gè)實(shí)施例的一般實(shí)現(xiàn)方式的流程圖。
具體實(shí)施例方式
本發(fā)明提供一種機(jī)制,其中傳輸或發(fā)送設(shè)備可以明確地指示被發(fā) 送的多媒體流中的哪些流不應(yīng)當(dāng)被同步或應(yīng)當(dāng)包括指定量的同步抖 動(dòng)。該機(jī)制幫助接收設(shè)備理解流特性,并且允許接收設(shè)備做出是否 應(yīng)當(dāng)執(zhí)行同步以及是否指定同步抖動(dòng)值的被告知的決定。
為理解本發(fā)明的實(shí)現(xiàn)方式,圖1可用于基于發(fā)送設(shè)備在會(huì)話建立 階段期間通知接收設(shè)備其希望接收設(shè)備不執(zhí)行任何同步或使用具體 值(例如500毫秒)執(zhí)行具有粗劣同步延遲或抖動(dòng)的同步。在此情 況下,當(dāng)已經(jīng)完成解碼并且每個(gè)媒體流的每個(gè)分組已經(jīng)到了播出時(shí) 間,接收設(shè)備可以提供相應(yīng)的分組以便呈現(xiàn)。接收設(shè)備對(duì)分組進(jìn)行 的延遲不需長(zhǎng)于指定的值。這可以用于防止抖動(dòng)緩沖器溢出的問題, 不為同步的目的而延遲分組,并且改善了媒體質(zhì)量。在此情況下, 接收必須獨(dú)立地管理兩個(gè)沒有任何相互關(guān)系的媒體排隊(duì)。
在發(fā)送設(shè)備希望接收設(shè)備執(zhí)行具有指定的延遲值的某些同步的 情況下,接收設(shè)備在解碼之后確定音頻和視頻分組的播出時(shí)間之間 的差(TV1-TA1 )。如果該值小于在會(huì)話建立中為同步抖動(dòng)定義的值, 則接收設(shè)備不需要將音頻和視頻分組保存比播出時(shí)間指示的時(shí)段較 長(zhǎng)的時(shí)段。如果值(TV1-TA1)大于同步抖動(dòng),則接收設(shè)備需要將分 組保存一短的時(shí)間段。例如,如果在會(huì)話建立期間指定的同步抖動(dòng) 為5 00毫秒并且TV1-TA1為350毫秒,則接收設(shè)備不需要進(jìn)行任何 指定。然而,如果TV1-TA1為600毫秒,則音頻分組必須在排隊(duì)中 延遲額外的100毫秒。
在本發(fā)明的第一實(shí)施例中,指定了兩個(gè)機(jī)制,以允許多媒體流的 發(fā)送設(shè)備指示多媒體流不應(yīng)當(dāng)被同步。該實(shí)施例涉及新SDP參數(shù)的 引入,該新SDP參數(shù)幫助多媒體流的發(fā)送設(shè)備指定接收設(shè)備不應(yīng)當(dāng) 執(zhí)行同步。在第一機(jī)制中,引入了稱為"NO — SYNC"的新SDP屬性。"NO —SYNC" 指示該流不應(yīng)當(dāng)與會(huì)話中的任何其他多媒體流進(jìn)行同步。將該 N0-SYNC屬性聲明為a=N0 —SYNC。
該NO-SYNC屬性可以在J;某體級(jí)(即在SDP中的m行之后)或可以 在會(huì)話級(jí)上得以定義。當(dāng)在媒體級(jí)上定義之后,NO-SYNC屬性意味著 該媒體流不應(yīng)當(dāng)與會(huì)話中的任何其他流進(jìn)行同步。使用NO-SYNC屬 性的示例如下
v=0
o=NRC 289084412 2890841235 IN IP4 123.124.125.1 s=D6mo
c=IN IP4 123. 124. 125. 1 m=video 6001 RTP/AVP 98 a=rtpmap:98 MP4V-ES/90000 a=N0—SYNC
m=video 5001 RTP/AVP 99 a=rtpmap 99 H2.63/90000 m-audio 6001 RTP/AVP 98 a=rtpmap: 98 AMR
在以上示例中,在接收設(shè)備處第一視頻流不應(yīng)當(dāng)被同步。當(dāng)接收 設(shè)備客戶端接收該SDP時(shí),其知道不應(yīng)當(dāng)將任何其他流與該視頻流 (具有MPEG4編解碼器)進(jìn)行同步。接收設(shè)備可以選擇同步或不同 步其余的(音頻和視頻)流。
NO — SYNC屬性可以在會(huì)話的開始處得以聲明,這暗示了會(huì)話中的
所有的流都不應(yīng)當(dāng)進(jìn)行同步。其描述如下 v=0
o=NRC 289084412 2890841235 IN IP4 123.124.125.1 s=Demo
c=IN IP4 123.124.125.1
a=N0_SYNC
m=video 6001 RTP/AVP 98a=rtpmap:98 MP4V-ES/90000 m=audio 6001 RTP/AVP 98 a=rtpmap: 98 AMR
在以上示例中,發(fā)送設(shè)備指示接收設(shè)備該會(huì)話中的所有的流都不 應(yīng)當(dāng)進(jìn)行同步。
在另一個(gè)實(shí)現(xiàn)方式的示例中,可以定義RFC 3388的擴(kuò)展。該擴(kuò) 展可用于指定哪些流應(yīng)當(dāng)被同步。以下為常規(guī)RFC 3388系統(tǒng)的示例, 其展示了在SDP中如何指示同步
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com t=0 0
c=IN IP4 224. 2.17.12/127 a=group:LS 1 2 m=audio 30000 RTP/AVP 0 a=mid: 1
m=video 30002 RTP/AVP 31 a=mid: 2
m=audio 30004 RTP/AVP 0
i=This media stream contains the Spanish translation a=mid: 3
在以上的示例中,具有mid 1和mid 2的流:故同步。這是用group 屬性中的LS語(yǔ)義標(biāo)簽來指示的。然而,利用新的實(shí)現(xiàn)方式,使用具 有g(shù)roup屬性"NLS"的新的語(yǔ)義標(biāo)簽,其具有不同步的語(yǔ)義。以下 的示例示出了如何提供關(guān)于流不應(yīng)當(dāng)與在會(huì)話中的任何其他的流進(jìn) 行同步的指示
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com 1=0 0
c=IN IP4 224.2.17.12/127 a=group: NLS 1
13m=audio 30000 RTP/AVP 0 a=mid:1
m=video 30002 RTP/AVP 31 a=mid: 2
m=audio 30004 RTP/AVP 0
i=This media stream contains the Spanish translation a=mid: 3
在以上的示例中,具有mid 1的流不與會(huì)話中的任何其他流進(jìn)行 同步。因此,RFC 3388可以利用該新的語(yǔ)義標(biāo)簽進(jìn)行擴(kuò)展,這將幫 助發(fā)送設(shè)備指示媒體流不要求同步。
語(yǔ)義標(biāo)簽LS和NLS可用于相同的會(huì)話描述中以描述哪些流需要 同步而哪些流不需要同步。例如,在以下描述的SDP示例中,流l 不應(yīng)當(dāng)與會(huì)話中的任何其他流進(jìn)行同步,而流2和流3應(yīng)當(dāng)?shù)靡酝?步。以此方式,發(fā)送設(shè)備可以明確地描述哪些流應(yīng)該進(jìn)行同步而哪 些流不需要同步。
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com t=0 0
c=IN IP4 224.2.17.12/127 a=group:NLS 1 a=group:LS 2 3 m=audio 30000 RTP/AVP 0 a=mid: 1
m=video 30002 RTP/AVP 31 a=mid: 2
m=audio 30004 RTP/AVP 0
i=This media stream contains the Spanish translation a=mid: 3
在本發(fā)明的第二實(shí)施例中,引入了允許多媒體流的發(fā)送設(shè)備指示 在其希望接收設(shè)備進(jìn)行同步的多媒體流之間的同步延遲和抖動(dòng)值的機(jī)制。在此實(shí)施例中,新SDP參數(shù)用于指定抖動(dòng)值,利用這些SDP
屬性,發(fā)送設(shè)備還可以指定在給定的多媒體會(huì)話中的哪些流不應(yīng)當(dāng) 與在相同的會(huì)話中的任何其他流進(jìn)行同步。
在該實(shí)施例的一個(gè)具體的實(shí)現(xiàn)方式中,定義稱為"sync —jitter" 的新SDP屬性。該屬性指示多媒體流之間的同步延遲。sync-jitter SDP屬性以時(shí)間單位(例如毫秒)或任何其他合適的單位來指定。 sync-jitter的0的值意味著不應(yīng)當(dāng)執(zhí)行同步。在SDP中將屬性聲明 為
a=sync — j i t ter: value //值例如為毫秒。
sync—jitter SDP屬性可與group和mid屬性以及LS語(yǔ)義標(biāo)簽 (如在RFC 3388中定義的)結(jié)合使用。當(dāng)與該屬性一起使用時(shí), sync_jitter指定在如LS語(yǔ)義標(biāo)簽所指定的需要同步的流之間的可 接受的同步抖動(dòng)。以下為RFC 3388的示例,其描述了在SDP中如何 常^L地指示同步 v=0
o=Laura 289083124 289083124 IN IP4 one.example.com t=0 0
c=IN IP4 224. 2.17. 12/127 a-group:LS 1 2 m-audio 30000 RTP/AVP 0 a=mid: 1
m=video 30002 RTP/AVP 31 a=mid: 2
m=audio 30004 RTP/AVP 0
i=This media stream contains the Spanish translation a=mid: 3
在以上的示例中,具有mid 1和mid 2的流要進(jìn)行同步。這是用 在group屬性中的LS語(yǔ)義標(biāo)簽來指示的。然而,在此示例中,無法 指示在具有mid l和mid 2的流之間的期望的同步抖動(dòng)。取決于不 同的應(yīng)用(例如單向^L頻共享或?qū)崟r(shí)對(duì)話;f見頻電話),同步值將不同。
以下示例利用sync-jitter屬性擴(kuò)展上述示例。如果上述SDP 描述是用于單向視頻共享應(yīng)用,并且如果粗劣形式的同步將滿足特 定情況的要求,則發(fā)送設(shè)備可以例如針對(duì)具有mid l和mid 2的流 之間的同步抖動(dòng)使用500毫秒的值。在此情況下,SDP將如下
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com 1=0 0
c=IN IP4 224. 2.17. 12/127 a=group:LS 1 2 a=sync—jitter: 500 m=audio 30000 RTP/AVP 0 a=mid: 1
m=video 30002 RTP/AVP 31 a=mid: 2
m=audio 30004 RTP/AVP 0
i=This media stream contains the Spanish translation a=mid: 3
sync_jitter屬性可以使用O值。0值特別指定了發(fā)送設(shè)備不希 望特定的媒體流與在給定的會(huì)話中的任何其他流進(jìn)行同步。如前所 述,默認(rèn)的實(shí)現(xiàn)方式是執(zhí)行同步,并且如果發(fā)送設(shè)備SDP實(shí)現(xiàn)方式 不支持RFC 3388,則發(fā)送設(shè)備可以使用值為0的sync —jitter屬性以 指示其不希望會(huì)話中的給定的流與任何其他流進(jìn)行同步。發(fā)送設(shè)備 指定sync-jitter值為0的SDP示例如下
v=0
o=NRC 289084412 2890841235 IN IP4 123.124.125.1 s=Demo
c=IN IP4 123.124.125.1 m=video 6001 RTP/AVP 98 a=rtpmap: 98MP4V-ES/90000 a=sync — j i t ter: 0 m=video 5001 RTP/AVP 99 a=rtpmap 99 H2. 63/90000 m=audio 6001 RTP/AVP 98 a=rtpmap: 98 AMR
在以上的示例中,發(fā)送設(shè)備不希望第一視頻流(具有MPEG-4) 與會(huì)話中的任何其他流進(jìn)行同步。接收設(shè)備可以選擇是否同步在會(huì) 話中給定的其余的兩個(gè)流。
應(yīng)當(dāng)理解,有可能需要為sync_jitter選擇非0的適當(dāng)?shù)闹?,?指示不要求同步,因?yàn)镺將具有不同的語(yǔ)義。
圖4為示出本發(fā)明實(shí)施例的實(shí)現(xiàn)方式的一般流程圖,其中發(fā)送設(shè) 備指明不進(jìn)行同步或引入同步抖動(dòng)的某個(gè)值。在圖4的步驟300中, 發(fā)送設(shè)備傳輸SDP信息。SDP信息包括關(guān)于被傳輸?shù)亩嗝襟w流的同步 的以上討論的類型的引入。在步驟310中,接收設(shè)備接收SDP信息。 在步驟320中,接收設(shè)備讀取SDP信息以確定是否存在不同步任何 或所有多媒體流的指令,是否包括某個(gè)數(shù)量的同步抖動(dòng),或是否應(yīng) 當(dāng)進(jìn)行完全的同步。如果存在不進(jìn)行同步的指令,則在步驟330中 遵循該指令。如果存在同步抖動(dòng)值,則在步驟340處將指明的抖動(dòng) 量引入到流中。如果不存在關(guān)于缺乏同步或同步抖動(dòng)數(shù)量的指令, 或如果存在完全同步的具體指令,則在步驟350進(jìn)行完全同步。
圖2和圖3示出了一個(gè)在其中可以實(shí)現(xiàn)本發(fā)明的代表性電子設(shè)備 12。圖2和圖3中的電子設(shè)備包括移動(dòng)電話并且可以用作發(fā)送設(shè)備 或接收設(shè)備。然而,還應(yīng)該理解,本發(fā)明不限于電子設(shè)備的一種特 定類型。例如電子設(shè)備12可以包括個(gè)人數(shù)字助理(PDA) 、 PDA和移 動(dòng)電話的結(jié)合、集成的消息發(fā)送設(shè)備(IMD)、臺(tái)式計(jì)算機(jī)、筆記本
計(jì)算機(jī)或各種其他設(shè)備。
圖2和圖3中的電子設(shè)備12包括外殼30、液晶顯示器形式的顯 示器32、小鍵盤34、麥克風(fēng)36、耳機(jī)38、電池40、紅外端口42、 天線44、以根據(jù)本發(fā)明一個(gè)實(shí)施例的UICC形式的智能卡46、讀卡器48、無線接口電路52、編解碼器電路54、控制器56和存儲(chǔ)器58。 各個(gè)電路和元件全都是現(xiàn)有技術(shù)已知的類型,例如諾基亞移動(dòng)電話 的范圍。
用方法步驟的一般上下文描述了本發(fā)明,在一個(gè)實(shí)施例中其可以 由程序產(chǎn)品實(shí)現(xiàn),其中程序產(chǎn)品包括計(jì)算機(jī)可執(zhí)行指令,例如可以 由在聯(lián)網(wǎng)環(huán)境中的計(jì)算機(jī)執(zhí)行的程序代碼。
通常,程序模塊包括例程、程序、對(duì)象、組件、數(shù)據(jù)結(jié)構(gòu)等,其 可以執(zhí)行特定的任務(wù)或?qū)崿F(xiàn)特定的抽象數(shù)據(jù)類型。計(jì)算機(jī)可執(zhí)行指 令、相關(guān)數(shù)據(jù)結(jié)構(gòu)和程序模塊代表用于執(zhí)行在此公開的方法步驟的 程序代碼的示例。這樣的可執(zhí)行指令的特定序列或相關(guān)數(shù)據(jù)結(jié)構(gòu)代 表用于實(shí)現(xiàn)在這樣的步驟中描述的功能的相應(yīng)動(dòng)作的示例。
本發(fā)明的軟件和web實(shí)現(xiàn)方式可以用標(biāo)準(zhǔn)的編程才支術(shù)來完成,該
驟、相關(guān)步驟、比較步驟和判決步驟。還應(yīng)當(dāng)理解,在此和在權(quán)利 要求書中使用的詞匯"組件"和"模塊"旨在包括使用一行或多行 軟件代碼的實(shí)現(xiàn)、和/或硬件實(shí)現(xiàn)、和/或用于接收手動(dòng)輸入的設(shè)備。
為了說明和描述的目的,給出了上述的對(duì)本發(fā)明的實(shí)施例的描 述。不旨在窮舉或?qū)⒈景l(fā)明限制于公開的精確的形式,根據(jù)上述啟 示的修改和變形是可能的或可以從本發(fā)明的實(shí)踐中獲得。為了解釋 本發(fā)明的原理選擇和描述了這些實(shí)施例,其實(shí)際的應(yīng)用可使得本領(lǐng) 域技術(shù)人員以各種實(shí)施例和各種修改利用本發(fā)明作為所遇到的特定 用途的適當(dāng)解決方案。
權(quán)利要求
1.一種提供用于多個(gè)多媒體流的同步信息的方法,包括將多個(gè)多媒體流傳輸?shù)浇邮赵O(shè)備;以及傳輸關(guān)于該多個(gè)多媒體流的信息,該信息包括用于該接收設(shè)備的具體指令,以允許不進(jìn)行同步或允許在多個(gè)多媒體流的至少一個(gè)和多個(gè)多媒體流的至少一個(gè)其他流之間的指定的同步延遲量。
2. 根據(jù)權(quán)利要求1所述的方法,其中該指令作為在傳輸?shù)皆摻?收設(shè)備的會(huì)話信息中的屬性得以包括。
3. 根據(jù)權(quán)利要求1所述的方法,其中該指令包括在該多媒體流 的至少兩個(gè)流之間的可接受的同步延遲值。
4. 根據(jù)權(quán)利要求1所述的方法,其中該指令包括"sync-jitter" 屬性。
5. 根據(jù)權(quán)利要求4所述的方法,其中該"sync —jitter"屬性伴 隨著指示不進(jìn)行同步的值。
6. 根據(jù)權(quán)利要求4所述的方法,其中該"sync —jitter"屬性伴 隨著可接受的同步延遲值。
7. 根據(jù)權(quán)利要求4所述的方法,其中該"sync-jitter"屬性為 SDP屬性。
8. 根據(jù)權(quán)利要求1所述的方法,其中該指令包括"NO — SYNC"屬性。
9. 根據(jù)權(quán)利要求1所述的方法,其中該指令包括"NLS"語(yǔ)義標(biāo)簽。
10. 根據(jù)權(quán)利要求1所述的方法,其中該傳輸?shù)男畔⒅噶钤摻邮?設(shè)備不進(jìn)行多個(gè)多媒體流彼此之間的任何同步。
11. 根據(jù)權(quán)利要求1所述的方法,其中該傳輸?shù)男畔⒅噶钤摻邮?設(shè)備不進(jìn)行多個(gè)多媒體流之一 與多個(gè)多媒體流的任何其他流的同步。
12. —種提供用于多個(gè)多媒體流的同步信息的計(jì)算機(jī)程序產(chǎn)品,包括計(jì)算機(jī)代碼,用于將多個(gè)多媒體流傳輸?shù)浇邮赵O(shè)備;以及計(jì)算機(jī)代碼,用于傳輸關(guān)于該多個(gè)多媒體流的信息,該信息包括 用于該接收設(shè)備的具體指令,以允許不進(jìn)行同步或允許在多個(gè)多媒 體流的至少 一 個(gè)和多個(gè)多媒體流的至少 一 個(gè)其他流之間的指定的同 步延遲量。
13. 根據(jù)權(quán)利要求12所述的計(jì)算機(jī)程序產(chǎn)品,其中該指令作為 在傳輸?shù)皆摻邮赵O(shè)備的會(huì)話信息中的屬性得以包括。
14. 根據(jù)權(quán)利要求12所述的計(jì)算機(jī)程序產(chǎn)品,其中該指令包括 在該多媒體流的至少兩個(gè)流之間的可接受的同步延遲值。
15. 根據(jù)權(quán)利要求12所述的計(jì)算機(jī)程序產(chǎn)品,其中該指令包括 "sync —jitter"屬性。
16. 根據(jù)權(quán)利要求15所述的計(jì)算機(jī)程序產(chǎn)品,其中該 "sync-jitter"屬性伴隨著可接受的同步延遲值。
17. 根據(jù)權(quán)利要求15所述的計(jì)算機(jī)程序產(chǎn)品,其中該 "sync-jitter"屬性為SDP屬性。
18. 根據(jù)權(quán)利要求12所述的計(jì)算機(jī)程序產(chǎn)品,其中該傳輸?shù)男?息指令該接收設(shè)備不進(jìn)行多個(gè)多媒體流之一 與多個(gè)多媒體流的任何其他流的同步。
19. 根據(jù)權(quán)利要求12所述的計(jì)算機(jī)程序產(chǎn)品,其中該傳輸?shù)男?息指令該接收設(shè)備不進(jìn)行多個(gè)多媒體流彼此之間的任何同步。
20. —種電子設(shè)備,包括 處理器;以及存儲(chǔ)器單元,操作地連接到該處理器并且包括計(jì)算機(jī)代碼,用于將多個(gè)多媒體流傳輸?shù)浇邮赵O(shè)備;以及 計(jì)算機(jī)代碼,用于傳輸關(guān)于該多個(gè)多媒體流的信息,該信 息包括用于該接收設(shè)備的具體指令,以允許不進(jìn)行同步或允許在多 個(gè)多媒體流的至少一個(gè)和多個(gè)多媒體流的至少一個(gè)其他流之間的指 定的同步延遲量。
21,根據(jù)權(quán)利要求20所述的電子設(shè)備,其中該指令作為在傳輸 到該接收設(shè)備的會(huì)話信息中的屬性得以包括。
22.根據(jù)權(quán)利要求20所述的電子設(shè)備,其中該指令包括在該多 媒體流的至少兩個(gè)流之間的可接受的同步延遲值。
23.根據(jù)權(quán)利要求20所述的電子設(shè)備,其中該指令包括 "sync —jitter,,屬性。
24. 根據(jù)權(quán)利要求23所述的電子設(shè)備,其中該"sync —jitter" 屬性伴隨著可接受的同步延遲值。
25. 根據(jù)權(quán)利要求23所述的電子設(shè)備,其中該"sync-jitter" 屬性為SDP屬性。
26. 根據(jù)權(quán)利要求20所述的電子設(shè)備,其中該傳輸?shù)男畔⒅噶?該接收設(shè)備不進(jìn)行多個(gè)多媒體流彼此之間的任何同步。
27. 根據(jù)權(quán)利要求20所述的電子設(shè)備,其中該傳輸?shù)男畔⒅噶?該接收設(shè)備不進(jìn)行多個(gè)多媒體流之一與多個(gè)多媒體流的任何其他流 的同步。
28. 根據(jù)權(quán)利要求20所述的電子設(shè)備,其中該電子設(shè)備包括從 如下組中選^r的設(shè)備,該組包括移動(dòng)電話、個(gè)人數(shù)字助理、膝上 型計(jì)算機(jī)、臺(tái)式計(jì)算機(jī)、集成的消息發(fā)送設(shè)備以及其組合。
29. —種處理多媒體內(nèi)容的方法,包括 從發(fā)送設(shè)備接收多個(gè)多媒體流;從該發(fā)送設(shè)備接收關(guān)于該多個(gè)多媒體流的信息;以及 如果接收的信息包括允許不進(jìn)行同步或允許在多個(gè)多媒體流的 至少 一 個(gè)和多個(gè)多媒體流的至少 一 個(gè)其他流之間的指定的同步延遲量的具體指令,則根據(jù)該接收的具體指令展示該多個(gè)多媒體流。
30. 根據(jù)權(quán)利要求29所述的方法,其中該指令包括在該多媒體 流的至少兩個(gè)流之間的可接受的同步延遲值。
31. 根據(jù)權(quán)利要求29所述的方法,其中該指令包括 "sync —jitter"屬性。
32. 根據(jù)權(quán)利要求31所述的方法,其中該"sync —jitter"屬性伴隨著可接受的同步延遲值。
33. 根據(jù)權(quán)利要求29所述的方法,其中根據(jù)該接收的信息,不 進(jìn)行多個(gè)多媒體流彼此之間的任何同步。
34. 才艮據(jù)權(quán)利要求29所述的方法,其中^4居該接收的信息,不 進(jìn)行多個(gè)多媒體流之一與多個(gè)多媒體流的任何其他流的同步。
35. —種電子設(shè)備,包括 處理器;以及存儲(chǔ)器單元,操作地連接到該處理器并且包括用于將多個(gè)多媒體流傳輸?shù)浇邮赵O(shè)備的裝置;以及 用于傳輸關(guān)于該多個(gè)多媒體流的信息的裝置,該信息包括 用于該接收設(shè)備的具體指令,以允許不進(jìn)行同步或允許在多個(gè)多媒 體流的至少 一 個(gè)和多個(gè)多媒體流的至少 一 個(gè)其他流之間的指定的同 步延遲量。
全文摘要
一種改進(jìn)的系統(tǒng)和方法,允許傳輸電子設(shè)備明確地指示被傳輸?shù)亩嗝襟w流中的哪些流不應(yīng)當(dāng)被同步或應(yīng)當(dāng)包括指定的同步抖動(dòng)量。本發(fā)明幫助接收設(shè)備理解流的特性。本發(fā)明還允許接收設(shè)備做出關(guān)于當(dāng)同步兩個(gè)或多個(gè)流時(shí)是否應(yīng)當(dāng)使用同步抖動(dòng)值的被告知的決定。對(duì)于例如單向視頻共享或視頻PoC的某些應(yīng)用,流的發(fā)送設(shè)備可以指示接收設(shè)備為了更好的媒體質(zhì)量不執(zhí)行任何同步或執(zhí)行有限的同步。
文檔編號(hào)H04J3/06GK101288257SQ200680038380
公開日2008年10月15日 申請(qǐng)日期2006年8月25日 優(yōu)先權(quán)日2005年8月26日
發(fā)明者D·萊昂, I·D·D·屈爾西奧, U·錢德拉 申請(qǐng)人:諾基亞公司