JP2009506611A - マルチメディア・ストリームにおいてデバイスが非同期を実行するように又は同期遅延を含むように装置に信号通知するための方法 - Google Patents

Abstract

【課題】伝達電子デバイスが、伝達されているマルチメディア・ストリームにおけるどのストリームを同期するべきでないか、又は指定量の同期ジッタを含むべきかを明白に指示することを許容する改良されたシステム及び方法を提供する。
【解決手段】本発明は、受信デバイスがストリーム特徴を理解するのを援助する。本発明はまた、受信デバイスが、２つ又はそれ以上のストリームを同期するときに、同期ジッタを用いるべきかどうかに関して、充分な情報を得た上で決定できるようにする。単方向ビデオ共有又はビデオＰｏＣといった特定のアプリケーションでは、ストリームの送信デバイスは、より優れたメディア品質のために、受信デバイスが全く同期を実行しないか又は制限された同期を実行することを指示することができる。
【選択図】図１

Description

本発明は、一般に、ＩＰマルチメディア通信の領域に関する。さらに具体的には、本発明は、受信デバイスが、異なるマルチメディア・ストリーム間で、同期を実行しないように、又は、同期ジッタを含むように命令する、マルチメディア通信において用いられる信号通知（シグナリング）機構に関する。

ＩＰマルチメディア呼出しの設定中に、呼出しの送信デバイス（即ち提供者又は発信者）は、セッション情報を指定する。セッション情報は、メディア及び伝送関連情報を含む。このセッション情報は、Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＤＰ）といったプロトコル・メッセージで運ばれる。ＳＤＰは、Ｓｅｓｓｉｏｎ Ｉｎｉｔｉａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＳＩＰ）、Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ（ＲＴＳＰ）等の高レベル信号通知プロトコルで運ばれる。第三世代パートナーシップ・プロジェクト（３ＧＰＰ）は、ＩＰマルチメディア・サブシステム（ＩＭＳ）に対するマルチメディア・セッション設定のための信号通知プロトコルの選択としてＳＩＰを指定した。

ＳＤＰでは、送信デバイス及び受信デバイスは、メディア・ストリームに対して異なる方向を指定して、異なる種類の適用例を生じさせることができる。例えば、送信デバイスが一方向メディア・セッションを設定することを望む場合には（ビデオを送信し、受信デバイスはこのビデオのみを受け取ることを期待する、ということを意味する）、ＳＤＰにおいて、このメディア・ストリームをａ＝ｓｅｎｄｏｎｌｙとして指定する。受信デバイスは、このＳＤＰメッセージを受信し、このセッションに参加することを望む場合には、ストリームをａ＝ｒｅｃｖｏｎｌｙと指定することができる。テレビ電話では、送信デバイス及び受信デバイスは両方とも、メディア・ストリームの方向をａ＝ｓｅｎｄｒｅｃｖと指定する。

一般的には、ＩＰマルチメディア呼出しでは、受信デバイス側で、異なるメディアの種類を同期させる必要がある。例えば、オーディオ／ビデオＩＰ呼出しにおいては、良好なユーザ体験のために、受信デバイス側でリップシンクが実行される必要がある。同期の別の例は字幕を用いることを含み、オーディオ及び／又はビデオの送信者が英語で話している場合、及び音声と一緒に、音声のテキストが異なる言語で異なるＲｅａｌ Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ（ＲＴＰ）により送信される場合には、これら２つのストリームは受信デバイスで同期される必要がある。

（送信デバイス側からの）異なるメディア・ストリームは、異なるＲＴＰ／ユーザ・データ・プロトコル（ＵＤＰ）／インターネット・プロトコル（ＩＰ）ストリームで運ばれる。ＲＴＰタイムスタンプは受信デバイスのクライアントにより用いられて、メディア間の同期を実行する。

図１は、送信デバイスからマルチメディア・ストリームを受信する受信デバイスを示す。水平軸は経過時間を表わし、受信されるパケットを示す。図１に示すオーディオ及びビデオ・バッファは、送信デバイスからパケットを受信するときにＲＴＰパケットを保持する。バッファは（ネットワークから）ジッタ除去を実行し、各々のメディアに対して各々のパケットのプレイアウト時間を算出する。パケットが、所与の時間だけバッファに留まると、デコード化が実行される。この時間は一般に可変であり、この時間の一部はジッタと称される。プレイアウト時間に基づいてデコード化が完了すると、パケットは、表示のため又は再生のために与えられる。入ってくるＲＴＰパケットを保持するために、１つはジッタのため、もう１つはキューをデコードするための２つの異なるバッファがあるとすることができることに注目すべきである。明確かつ例示的な目的のために、図１では、１つのキューだけが示され、組み合わされたジッタ及びデコード化バッファが示されている。パケットがデコードされ、プレイアウト時間が経過すると、再生又は表示の準備が整う。しかしながら、受信デバイスがオーディオ／ビデオ同期を実行しようとしている場合には、最初に到達したパケットを遅延させることを試みる。

図１に示す例では、オーディオ・パケット１はＴＡ１で到達し、ビデオ・パケットはＴＡ１より後の時間であるＴＶ１で到達する。「到達する」という用語は、パケットが到達する時間、又は各々のパケットに対するプレイアウト時間を指すことに注目すべきである。図１の例では、同じ再生時間を有するオーディオ及びビデオ・パケットは、同じ基準クロック取得時間を（送信デバイスで）有し、これは送信デバイスで同時にサンプリングされたことを意味するため、同期される必要がある。基準クロック取得時間の算出は、ＲＴＰパケットにおけるＲＴＰタイムスタンプ、及びＲＴＣＰ送信者レポート（ＳＲ）パケットにおいて送信されるＮＴＰタイムスタンプを用いて実行される。オーディオ及びビデオ・パケットは、異なるネットワーク経路を取ることがあり、各々のパケットに対する処理遅延は異なることがあるため、異なる時間に受信デバイスに到達する可能性が大いに高い。従って、図１に示す例では、オーディオ・パケットは、同期ジッタ又は遅延であるＴＶ１−ＴＡ１の時間だけ遅延されなければならない。

図１に示す例では、アプリケーション（又は送信者）が、Ａ／Ｖ同期を実行する意図がなく、それにもかかわらず受信デバイスが（デフォルト動作であるために）同期の実行を試みた場合には、受信デバイスは、オーディオ・パケットを付加的な時間だけ保持するよう強いられる。この動作は、オーディオ・バッファをオーバーフローさせる可能性がある。さらに、キューの先頭にあるオーディオ・パケットは、同期を試みたときに遅延され、悪いユーザ体験又はメディア品質を招く。サービスの質（ＱｏＳ）が保証された場合には、オーディオ及びビデオ・パケットは、キューでさらに遅延された場合にドロップされなくてはならないこともある。従って、送信デバイスが受信デバイスに対して、同期又は遅延された同期が必要ないことを示す機構がないために、送信デバイスが、メディア・ストリームが同期されることを望まなくとも、パケット損失、遅延パケット、及び計算リソースの無駄といった問題が生じることがある。

Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ’ｓ Ｎｅｔｗｏｒｋ Ｗｏｒｋｉｎｇ Ｇｒｏｕｐからのリクエスト・フォー・コメント（ＲＦＣ）第３３８８号では、セッションにおけるどのメディア・ストリームが同期される必要があるかを、送信デバイスが明確に指定することができる機構が指定される。新しいＳＤＰ属性（例えば「群」、「中間」、及びリップシンク（ＬＳ））が定められ、送信デバイスが、セッションにおけるどのメディア・ストリームがリップシンクされる必要があるか指定する手助けをする。また、ＲＴＰ受信デバイスのデフォルト実施動作は、同じソースから受信するメディア・ストリームを同期することである。さらに、指定は、マルチメディア・ストリームを同期しなければならないかどうかを命令しないので、ＲＦＣ３３８８が必要になる。ＲＦＣ３３８８は、それが２つ又はそれ以上のストリームを送信している場合には、どのストリームが同期される必要があるかを送信デバイスに指定させることができる機構を指定するにすぎない。

マルチメディア・ストリームが同期されるべきでないことを要する適用例及び使用例がある。例えば、Ｒｅａｌ Ｔｉｍｅ Ｖｉｄｅｏ Ｓｈａｒｉｎｇ（ＲＴＶＳ）アプリケーションでは、ユーザは、単方向のビデオ共有セッションを開始する。単方向メディア・セッションは、ＳＤＰ内メディア・ストリームを、ａ＝ｓｅｎｄｏｎｌｙ又はａ＝ｒｅｃｖｎｌｙと明示することにより設定される。既に、双方向（又は単方向でもよい）のオーディオ・セッションが２つの当事者の間に設定されている。呼出しにおける当事者の一方は、他方の当事者とビデオを共有することを望む。オーディオ及びビデオは、ＩＰベアラ上で設定されるが、オーディオ又はビデオ・セッションは、回路交換ベアラ上で同様に設定することも可能である。共有ビデオは、ファイルからであってもよいし、又はライブ・カメラの視野からであってもよい。

単方向ビデオ共有におけるいくつかのシナリオでは、送信デバイスは、（ファイルから共有している）ビデオと音声を同期させることを望まない。同期しないというこの要求の１つの理由は、送信デバイスは、ビデオが、遅延されても、受信デバイスにおいて高品質で受信されることを好むためであるとすることができる。この状況では、送信デバイスは、受信デバイスがより高い遅延バッファを有することを好み、従って同期を実行することは望まないとすることができる。

単方向ビデオ共有の別の例は、ユーザが何らかの物体のビデオを撮り、それについて話している場合を含む。この状況においては、ユーザはユーザ自身の顔のビデオを撮るのではなく、別の物体を録画しているため、完璧な同期よりもより粗い同期の形態で充分である。さらに別の例は、グラフィックがリアルタイムのオーディオ及びビデオと合成される「増強現実」を含む。この場合、より粗い形態の同期で充分である。

クライアントのデフォルト動作がこれら２つのストリームを同期するものである場合には、受信デバイスのクライアントは、これらストリームを同期する特別なアルゴリズムを採用するであろう。受信デバイス側における同期アルゴリズムは、指定量の計算の複雑さを必要とし、クライアントは、送信デバイスがどのような同期も好まないときでも、いくらかのリソースを消耗するであろう。オーディオ及びビデオ・ストリームは、異なる遅延で受信デバイスに到達できる。受信デバイスがストリームを同期しようとする場合には、オーディオ及びビデオ・フレームをドロップする結果をもたらすことがあり、従って受信したメディアの品質を落とす。

あいにく、ＲＦＣ３３８８は、どのストリームが同期されるべきでないかを明確に識別できる機構を説明していない。例えば、送信デバイスが、セッションにおいて３つのストリームと、２つのオーディオ・ストリーム（Ａ１及びＡ２）と、１つのビデオ・ストリーム（Ｖ１）とを送信することを望み、送信デバイスがストリームＡ１とＶ１を同期（シップシンク）することを望む場合には、群、中間ＳＤＰ属性、及びＬＳ意味タグを用いて、それを指定できる。これは、Ａ１とＶ１が同期される必要があり、Ａ２は同期されるべきでないことを受信デバイスに示すことになる。しかし、２つ又はそれ以上のストリームがあり、どのストリームも同期される必要がない使用例の場合には、ＲＦＣ３３８８は不充分である。また、リップシンクの性能を示すために（及び非リップシンクを指定するのにＲＦＣ３３８８を用いることができるいくつかの場合）、ＲＦＣ３３８８は、命令されなくてはならない。最後に、ＲＦＣ３３８８は、デバイスが異なるメディア間で望ましい同期ジッタを示すことができる機構を提供しない。

上記の理由のために、送信デバイスが、送信デバイスにより伝達されるマルチメディア・ストリームを同期しないように、マルチメディアの呼出において受信デバイスに指示できる機構は現在存在せず、マルチメディア・ストリームに対して同期遅延（同期化遅延）又はジッタを指定する機構もない。

本発明は、伝達又は送信デバイスが、送信されているマルチメディア・ストリームにおけるどのストリームが同期されるべきでないか、又は指定量の同期ジッタを含むべきかを、明白に指示できる機構を提供する。この機構は、受信デバイスがストリームの特徴を理解するのを助け、同期を実行すべきか否か、並びに、同期ジッタ値を指定することについて、受信デバイスが充分な情報を得た上で決定できるようにする。単方向ビデオ共有又はビデオＰｏＣといった特定のアプリケーションでは、ストリームの送信デバイスは、より優れたメディア品質のために、受信デバイスが全く同期を実行しないことを指示できる。

本発明の１つの実施形態は、多数の新しいＳＤＰ属性の導入を含む。送信デバイスは、セッションの設定段階の間、ＳＤＰにおけるこれら属性を明示し、属性は、いずれのより高度な信号通知プロトコル（例えばＳＩＰ、ＲＴＳＰ等）によっても運ばれることができる。しかしながら、これら属性は、ＳＤＰプロトコルの使用に限定されるものではなく、ＩＳＯ ＯＳＩプロトコル・スタック（例えばＸＭＬ、ＨＴＴＰ、ＵＰｎＰ、ＣＣ／ＰＰ等）の層１−７のいずれかにおいて、何らかの他の通信プロトコルを用いて、定められ、運ばれることができる。

本発明は、セッションの設定段階の間、送信デバイスのメディア・ストリーム間の非同期に対するプリファレンスを示す能力を与えることにより、通常のＲＦＣ３３８８フレームワークと比較して実質的な利益を提供する。送信デバイスが伝達しているメディアを同期することを望まない使用例及び適用例がある。このプリファレンスを受信デバイスに信号通知できるときには、受信デバイスは、それに応じてリソースを設定することができ、他のタスク又はより高いメディア品質のために使用できる計算リソースを無駄にしないで済む。結果として、本発明は、受信デバイスがメディア・ストリームの同期を実行しようとした場合に発生することがある受信デバイスのパケット損失を少なくすることができる。

上記に加えて、本発明は、セッションの設定段階の間、送信デバイスのメディア・ストリーム間の同期ジッタに対するプリファレンスを示す能力を与えることにより、ＲＦＣ３３８８を改良する。さらに、送信デバイスが、伝達されているメディアがより粗いジッタで同期されるべきであると望む使用例及び適用例もあるため、このプリファレンスを受信デバイスに信号通知する能力は、受信デバイスがそれに応じてリソースを設定することを可能にする。これはまた、計算リソースを節約する機会も提供する。いくつかの場合には、これは、改良されたレベルのメディア品質も生むことができる。事実、強制メディア同期シナリオでは、受信デバイスがメディア・ストリームの同期を実行しようとする場合に、受信デバイスにおけるデータ廃棄又は他の理由のために発生することがある、いくらかのパケット損失が存在する。これはメディア・データが異なる遅延で受信デバイスに到達することがあるという事実のためであり、いくつかのコンテンツは、完全に同期された再生に有用であるには到達が遅すぎるという結果をもたらす可能性がある。同期ジッタを制御することによって、この課題は緩和できる又は取り除くことができる。

本発明のこれら及び他の目的、利点、及び特徴は、その動作の構成及び様式と併せて、いくつかの図面にわたり同様の要素が同様の番号を有する添付の図面と共に検討されるときに、以下の詳細な説明から明白になるであろう。

本発明は、伝達又は送信デバイスが、送信されているマルチメディア・ストリームにおけるどのストリームが同期されるべきでないか、又は指定量の同期ジッタを含むべきかを、明白に指示できる機構を提供する。この機構は、受信デバイスがストリームの特徴を理解するのを助け、同期を実行すべきか否か、並びに、同期ジッタ値を指定することについて、受信デバイスが充分な情報を得た上で決定できるようにする。

本発明の実施を理解するために、図１は、セッション設定期間中に、送信デバイスは、受信デバイスに、どのような同期も実行することを望まないこと、又は指定値（例えば５００ミリ秒）を用いて、より粗い同期遅延又はジッタで同期を実行することを通知するという理解に基づいて用いることができる。このシナリオでは、受信デバイスは、各々のメディア・ストリームの各々のパケットに対してデコードを完了し、プレイアウト・タイムが経過したときに、表示のためにそれぞれのパケットを提供できる。受信デバイスは、指定値より長くパケットを遅延させなくてよい。これは、ジッタ・バッファのオーバーフロー問題を防止する働きをし、パケットは同期目的のために遅延されることはなく、メディア品質が改良される。このシナリオでは、受信は、どのような相関関係もなく、両方のメディア・キューを別個に管理しなくてはならない。

送信デバイスが、受信デバイスは指定遅延値により何らかの同期を実行すると予測する場合には、受信デバイスは、デコード後、オーディオ及びビデオ・パケットのためのプレイアウト・タイムの差（ＴＶ１−ＴＡ１）を求める。この値が同期ジッタのためのセッションの設定で定められた値よりも小さい場合には、受信デバイスは、オーディオ及びビデオ・パケットをプレイアウト・タイムが示すよりも長い期間保持する必要はない。値（ＴＶ１−ＴＡ１）が同期ジッタよりも大きい場合には、受信デバイスは短い時間だけパケットを保持する必要がある。例えば、セッション設定中に、同期ジッタが５００ミリ秒と指定され、ＴＶ１−ＴＡ１が３５０ミリ秒である場合には、受信デバイスは何も指定する必要はない。しかしながら、ＴＶ１−ＴＡ１が６００ミリ秒である場合には、オーディオ・パケットは、キューにおいて、追加の１００ミリ秒だけ遅延されなくてはならない。

本発明の第１の実施形態では、マルチメディア・ストリームの送信デバイスが、マルチメディア・ストリームが同期されるべきでないと指示することを許容する２つの機構が指定される。本実施形態は、マルチメディア・ストリームの送信デバイスが、受信デバイスは同期を実行すべきでないと指定するのを補助する、新しいＳＤＰパラメータの導入を含む。

第１の機構では、“ＮＯ＿ＳＹＮＣ”と呼ばれる新しいＳＤＰ属性が導入される。“ＮＯ＿ＳＹＮＣ”は、ストリームは、セッションにおける他のいずれのマルチメディア・ストリームとも同期されるべきでないことを示す。ＮＯ＿ＳＹＮＣ属性は、ａ＝ＮＯ＿ＳＹＮＣと明示される。

ＮＯ＿ＳＹＮＣ属性は、メディア・レベル（即ちＳＤＰにおけるｍラインの後）で定められることができ、又はセッション・レベルで定められることができる。メディア・レベルで定められるとき、ＮＯ＿ＳＹＮＣ属性は、メディア・ストリームが、セッションにおけるいずれの他のストリームとも同期されるべきでないことを意味する。ＮＯ＿ＳＹＮＣ属性を用いた例は、以下のとおりである。
ｖ＝０
０＝ＮＲＣ ２８９０８４４１２ ２８９０８４１２３５ ＩＮ ＩＰ４ １２３．１２４．１２５．１
ｓ＝Ｄｅｍｏ
ｃ＝ＩＮ ＩＰ４ １２３．１２４．１２５．１
ｍ＝ｖｉｄｅｏ ６００１ ＲＴＰ／ＡＶＰ ９８
ａ＝ｒｔｐｍａｐ：９８ ＭＰ４Ｖ−ＥＳ／９００００
ａ＝ＮＯ＿ＳＹＮＣ
ｍ＝ｖｉｄｅｏ ５００１ ＲＴＰ／ＡＶＰ ９９
ａ＝ｒｔｐｍａｐ ９９ Ｈ２．６３／９００００
ｍ＝ａｕｄｉｏ ６００１ ＲＴＰ／ＡＶＰ ９８
ａ＝ｒｔｐｍａｐ：９８ ＡＭＲ

上の例では、第１のビデオ・ストリームは、受信デバイスで同期されるべきでない。受信デバイスのクライアントは、このＳＤＰを受信したとき、（ＭＰＥＧ４コーデックを備える）ビデオ・ストリームはいずれの他のストリームとも同期されるべきでないことがわかる。受信デバイスは、残存（オーディオ及びビデオ）ストリームを同期すること又は同期しないことを選択できる。

ＮＯ＿ＳＹＮＣ属性は、セッションの開始で明示され、セッションにおける全ストリームが同期されるべきでないことを示唆する。これは以下のように示される。
ｖ＝０
ｏ＝ＮＲＣ ２８９０８４４１２ ２８９０８４１２３５ ＩＮ ＩＰ４ １２３．１２４．１２５．１
ｓ＝Ｄｅｍｏ
ｃ＝ＩＮ ＩＰ４ １２３．１２４．１２５．１
ａ＝ＮＯ＿ＳＹＮＣ
ｍ＝ｖｉｄｅｏ ６００１ ＲＴＰ／ＡＶＰ ９８
ａ＝ｒｔｐｍａｐ：９８ ＭＰ４Ｖ−ＥＳ／９００００
ｍ＝ａｕｄｉｏ ６００１ ＲＴＰ／ＡＶＰ ９８
ａ＝ｒｔｐｍａｐ：９８ ＡＭＲ

上の例では、送信デバイスは、セッションにおけるストリームの全てが同期されるべきでないことを、受信デバイスに示す。

別の実施例では、ＲＦＣ ３３８８への拡張を定めることができる。この拡張は、どのストリームが同期されるべきでないかを指定するのに用いることができる。以下は、同期がＳＤＰにおいてどのように指示されるかを示す通常のＲＦＣ３３８８システムからの例である。
ｖ＝０
０＝Ｌａｕｒａ ２８９０８３１２４ ２８９０８３１２４ ＩＮ ＩＰ４ ｏｎｅ．ｅｘａｍｐｌｅ．ｃｏｍ
ｔ＝０ ０
ｃ＝ＩＮ ＩＰ４ ２２４．２．１７．１２／１２７
ａ＝ｇｒｏｕｐ：ＬＳ １ ２
ｍ＝ａｕｄｉｏ ３００００ ＲＴＰ／ＡＶＰ ０
ａ＝ｍｉｄ：１
ｍ＝ｖｉｄｅｏ ３０００２ ＲＴＰ／ＡＶＰ ３１
ａ＝ｍｉｄ：２
ｍ＝ａｕｄｉｏ ３０００４ ＲＴＰ／ＡＶＰ ０
ｉ＝Ｔｈｉｓ ｍｅｄｉａ ｓｔｒｅａｍ ｃｏｎｔａｉｎｓ ｔｈｅ Ｓｐａｎｉｓｈ ｔｒａｎｓｌａｔｉｏｎ（このメディア・ストリームはスペイン語翻訳を含む）
ａ＝ｍｉｄ：３

上記の例では、ｍｉｄ １及びｍｉｄ ２を備えるストリームが同期される。これは、群属性においてＬＳ意味タグと共に示される。しかしながら、新しい実施においては、新しい意味タグは、非同期の意味を有する群属性「ＮＬＳ」と共に用いられる。以下の例は、ストリームはセッションにおけるいずれの他のストリームとも同期されるべきではないという指示をどのように与えることができるかを示す。
ｖ＝０
０＝Ｌａｕｒａ ２８９０８３１２４ ２８９０８３１２４ ＩＮ ＩＰ４ ｏｎｅ．ｅｘａｍｐｌｅ．ｃｏｍ
ｔ＝０ ０
ｃ＝ＩＮ ＩＰ４ ２２４．２．１７．１２／１２７
ａ＝ｇｒｏｕｐ：ＮＬＳ １
ｍ＝ａｕｄｉｏ ３００００ ＲＴＰ／ＡＶＰ ０
ａ＝ｍｉｄ：１
ｍ＝ｖｉｄｅｏ ３０００２ ＲＴＰ／ＡＶＰ ３１
ａ＝ｍｉｄ：２
ｍ＝ａｕｄｉｏ ３０００４ ＲＴＰ／ＡＶＰ ０
ｉ＝Ｔｈｉｓ ｍｅｄｉａ ｓｔｒｅａｍ ｃｏｎｔａｉｎｓ Ｓｐａｎｉｓｈ ｔｒａｎｓｌａｔｉｏｎ（このメディア・ストリームはスペイン語翻訳を含む）
ａ＝ｍｉｄ：３

上の例では、ＭＩＤ １を備えるストリームは、セッションにおけるいずれの他のストリームとも同期されない。ＲＦＣ ３３８８は、従って、この新しい意味タグにより拡張され、メディア・ストリームには同期は必要でないことを送信デバイスが指示するのを補助する。

意味タグＬＳ及びＮＬＳは、どのストリームが同期されるべきか、及びどのストリームが同期されるべきでないかを記述するのに、同じセッション記述に用いることができる。例えば、以下に示すＳＤＰ例では、ストリーム１はセッションにおけるいずれの他のストリームとも同期されるべきでなく、ストリーム２及びストリーム３は同期されるべきである。このように、送信デバイスは、どのストリームが同期されるべきで、どのストリームが同期されるべきでないかを明白に記述する。
ｖ＝０
ｏ＝Ｌａｕｒａ ２８９０８３１２４ ２８９０８３１２４ ＩＮ ＩＰ４ ｏｎｅ．ｅｘａｍｐｌｅ．ｃｏｍ
ｔ＝０ ０
ｃ＝ＩＮ ＩＰ４ ２２４．２．１７．１２／１２７
ａ＝ｇｒｏｕｐ：ＮＬＳ １
ａ＝ｇｒｏｕｐ：ＬＳ ２ ３
ｍ＝ａｕｄｉｏ ３００００ ＲＴＰ／ＡＶＰ ０
ａ＝ｍｉｄ：１
ｍ＝ｖｉｄｅｏ ３０００２ ＲＴＰ／ＡＶＰ ３１
ａ＝ｍｉｄ：２
ｍ＝ａｕｄｉｏ ３０００４ ＲＴＰ／ＡＶＰ ０
ｉ＝Ｔｈｉｓ ｍｅｄｉａ ｓｔｒｅａｍ ｃｏｎｔａｉｎｓ ｔｈｅ Ｓｐａｎｉｓｈ ｔｒａｎｓｌａｔｉｏｎ（このメディア・ストリームは、スペイン語翻訳を含む）
ａ＝ｍｉｄ：３

本発明の第２の実施形態では、マルチメディア・ストリームの送信デバイスが、受信デバイスが同期することを望むマルチメディア・ストリーム間の同期遅延又はジッタ値を指示することを許容する機構が導入される。本実施形態では、新しいＳＤＰパラメータは、ジッタ値を指定するのに用いられる。これらＳＤＰ属性により、送信デバイスはまた、所与のマルチメディア・セッションのどのストリームが、同じセッションにおけるいずれの他のストリームとも同期されるべきでないことを指定することもできる。

本実施形態の１つの特定の実施では、“ｓｙｎｃ＿ｊｉｔｔｅｒ”と呼ばれる新しいＳＤＰ属性が定められる。この属性は、マルチメディア・ストリーム間の同期遅延を指示する。ｓｙｎｃ＿ｊｉｔｔｅｒ ＳＤＰ属性は、時間単位（例えばミリ秒）又はいずれかの他の好適な単位で指定される。ｓｙｎｃ＿ｊｉｔｔｅｒの値０は、非同期が実行されるべきであることを意味する。属性は、ＳＤＰにおいては、
ａ＝ｓｙｎｃ＿ｊｉｔｔｅｒ：ｖａｌｕｅ ／／ｖａｌｕｅ ｉｓ ｆｏｒ ｅｘａｍｐｌｅ ｉｎ ｍｉｌｌｉｓｅｃｏｎｄｓ．（値は例えばミリ秒である。）
として明示される。

ｓｙｎｃ＿ｊｉｔｔｅｒ ＳＤＰ属性は、（ＲＦＣ３３８８に定められるように）群及びｍｉｄ属性及びＬＳ意味タグと併せて用いることができる。この属性と共に用いられるとき、ｓｙｎｃ＿ｊｉｔｔｅｒは、ＬＳ意味タグに指定されたように同期される必要があるストリーム間で、受け入れられる同期ジッタを指定する。以下は、ＳＤＰにおいて同期が通常どのように示されているかを記述するＲＦＣ ３３８８からの例である。
ｖ＝０
ｏ＝Ｌａｕｒａ ２８９０８３１２４ ２８９０８３１２４ ＩＮ ＩＰ４ ｏｎｅ．ｅｘａｍｐｌｅ．ｃｏｍ
ｔ＝０ ０
ｃ＝ＩＮ ＩＰ４ ２２４．２．１７．１２／１２７
ａ＝ｇｒｏｕｐ：ＬＳ １ ２
ｍ＝ａｕｄｉｏ ３００００ ＲＴＰ／ＡＶＰ ０
ａ＝ｍｉｄ：１
ｍ＝ｖｉｄｅｏ ３０００２ ＲＴＰ／ＡＶＰ ３１
ａ＝ｍｉｄ：２
ｍ＝ａｕｄｉｏ ３０００４ ＲＴＰ／ＡＶＰ ０
ｉ＝Ｔｈｉｓ ｍｅｄｉａ ｓｔｒｅａｍ ｃｏｎｔａｉｎｓ ｔｈｅ Ｓｐａｎｉｓｈ ｔｒａｎｓｌａｔｉｏｎ（このメディア・ストリームは、スペイン語翻訳を含む）
ａ＝ｍｉｄ：３

上の例では、ｍｉｄ １とｍｉｄ ２を備えるストリームが同期される。これは群属性におけるＬＳ意味タグにより指示される。しかしながら、この例では、ｍｉｄ １及び２を備えるストリーム間で望ましい同期を指示する方法はない。（単方向ビデオ共有又はリアルタイム会話のテレビ電話といった）様々なアプリケーションによって、同期値は異なる。

以下の例は、上の例をｓｙｎｃ＿ｊｉｔｔｅｒ属性で拡張する。上のＳＤＰ記述が単方向ビデオ共有アプリケーションに用いられる場合、及びより粗い形態の同期が特定の状況に充分である場合には、送信デバイスは、ｍｉｄ １及びｍｉｄ ２を備えるストリーム間の同期ジッタに、例えば、５００ミリ秒の値を用いることができる。そのような状況では、ＳＤＰは以下のようになる。
ｖ＝０
ｏ＝Ｌａｕｒａ ２８９０８３１２４ ２８９０８３１２４ ＩＮ ＩＰ４ ｏｎｅ．ｅｘａｍｐｌｅ．ｃｏｍ
ｔ＝０ ０
ｃ＝ＩＮ ＩＰ４ ２２４．２．１７．１２／１２７
ａ＝ｇｒｏｕｐ：ＬＳ １ ２
ａ＝ｓｙｎｃ＿ｊｉｔｔｅｒ：５００
ｍ＝ａｕｄｉｏ ３００００ ＲＴＰ／ＡＶＰ ０
ａ＝ｍｉｄ：１
ｍ＝ｖｉｄｅｏ ３０００２ ＲＴＰ／ＡＶＰ ３１
ａ＝ｍｉｄ：２
ｍ＝ａｕｄｉｏ ３０００４ ＲＴＰ／ＡＶＰ ０
ｉ＝Ｔｈｉｓ ｍｅｄｉａ ｓｔｒｅａｍ ｃｏｎｔａｉｎｓ ｔｈｅ Ｓｐａｎｉｓｈ ｔｒａｎｓｌａｔｉｏｎ（このメディア・ストリームは、スペイン語翻訳を含む）
ａ＝ｍｉｄ：３

ｓｙｎｃ＿ｊｉｔｔｅｒ属性は、０の値と併せて用いることができる。０の値は、本質的には、送信デバイスが、特定のメディア・ストリームが所与のセッションにおけるいずれの他のストリームとも同期されることを望まないことを指定する。前述のように、デフォルト実施は、同期を実行することであり、送信デバイスのＳＤＰ実施がＲＦＣ ３３８８を支援しない場合には、送信デバイスは、０の値を備えるｓｙｎｃ＿ｊｉｔｔｅｒ属性を用いて、セッションにおける所与のストリームを、いずれの他のストリームとも同期することを望まないことを示す。送信デバイスが、ｓｙｎｃ＿ｊｉｔｔｅｒ値を０と指定するＳＤＰ例は、以下のとおりである。
ｖ＝０
ｏ＝ＮＲＣ ２８９０８４４１２ ２８９０８４１２３５ ＩＮ ＩＰ４ １２３．１２４．１２５．１
ｓ＝Ｄｅｍｏ
ｃ＝ＩＮ ＩＰ４ １２３．１２４．１２５．１
ｍ＝ｖｉｄｅｏ ６００１ ＲＴＰ／ＡＶＰ ９８
ａ＝ｒｔｐｍａｐ：９８ ＭＰ４Ｖ−ＥＳ／９００００
ａ＝ｓｙｎｃ＿ｊｉｔｔｅｒ：０
ｍ＝ｖｉｄｅｏ ５００１ ＲＴＰ／ＡＶＰ ９９
ａ＝ｒｔｐｍａｐ ９９ Ｈ２．６３／９００００
ｍ＝ａｕｄｉｏ ６００１ ＲＴＰ／ＡＶＰ ９８
ａ＝ｒｔｐｍａｐ：９８ ＡＭＲ

上記の例では、送信デバイスは、（ＭＰＥＧ−４を備える）第１のビデオ・ストリームが、セッションにおけるいずれの他のストリームとも同期されることを望まない。受信デバイスは、セッションに与えられる残存する２つのストリームを同期させるかどうか選択することができる。

０は異なる意味を持つため、ｓｙｎｃ＿ｊｉｔｔｅｒに対する０以外の適切な値は、同期が必要ではないことを示すように選択されなければならない可能性があることに注目すべきである。

図４は、送信デバイスが、非同期、又は同期ジッタの特定値の導入のいずれかを指定することができる、本発明の実施形態の実施を表す一般的なフローチャートである。図４のステップ３００では、送信デバイスはＳＤＰ情報を伝達する。ＳＤＰ情報は、伝達されているマルチメディア・ストリームの同期に関する、上述の種類の命令を含む。ステップ３１０では、受信デバイスはＳＤＰ情報を受信する。ステップ３２０では、受信デバイスはＳＤＰ情報を読み込んで、マルチメディア・ストリームのいずれか又は全てを同期しない命令があるかどうか、特定量の同期ジッタを含むかどうか、又は完全な同期が発生するかどうかを判断する。非同期命令がある場合には、この命令はステップ３３０で従われる。同期ジッタ値がある場合には、ステップ３４０で、ジッタの指定量がストリームに導入される。同期又は同期ジッタの量の欠如に関する命令がない場合、又は完全な同期のための特定の命令がある場合には、ステップ３５０で完全な同期が発生する。

図２及び図３は、本発明を実施することができる１つの代表的な電子デバイス１２を示す。図２及び図３の電子デバイスは携帯電話を含み、送信デバイス又は受信デバイスとして用いることができる。しかしながら、本発明は、電子デバイスの１つの特定の種類に制限することが目的でないことを理解すべきである。例えば、電子デバイス１２は、携帯情報端末（ＰＤＡ）、ＰＤＡと携帯電話の組み合わせ、統合メッセージング・デバイス（ＩＭＤ）、デスクトップ・コンピュータ、ノートブック・コンピュータ、又は多様な他のデバイスを含むことができる。

図２及び図３の電子デバイス１２は、ハウジング３０、液晶ディスプレイ形態のディスプレイ３２、キーパッド３４、マイクロフォン３６、イヤホン３８、バッテリ４０、赤外線ポート４２、アンテナ４４、本発明の１つの実施形態によるＵＩＣＣ形態のスマートカード４６、カード・リーダ４８、無線インターフェース回路５２、コーデック回路５４、コントローラ５６、及びメモリ５８を含む。個別の回路及び要素は全て、例えば携帯電話のノキアの範囲において当業者によく知られる種類のものである。

本発明は、ネットワーク環境でコンピュータにより実行されるプログラム・コードといったコンピュータ実行可能な命令を含むプログラム製品によって、１つの実施形態で実施することができる方法ステップの一般的な文脈で説明される。

一般に、プログラム・モジュールは、特定のタスクを実行する、又は特定の抽象データ・タイプを実施するルーチン、プログラム、オブジェクト、コンポーネント、データ構造体等を含む。コンピュータ実行可能命令、関連データ構造体、及びプログラム・モジュールは、本明細書に開示される方法の実行ステップのためのプログラム・コードの例を表す。そのような実行可能命令又は関連データ構造体の特定の順序は、そのようなステップに説明される機能を実施するための対応する動作の例を表す。

本発明のソフトウェア及びウェブ実施は、ルールをベースとした論理、及び、様々なデータベース検索ステップ、相関ステップ、比較ステップ、及び決定ステップを遂行する他の論理を備えた標準的なプログラミング技術によって達成することができる。また、本明細書及び特許請求の範囲で用いられる「コンポーネント」及び「モジュール」という用語は、ソフトウェア・コードの１つ又はそれ以上のライン、及び／又はハードウェア実施、及び／又は手入力を受信するための機器を用いた実施を包含することを目的とすることに注目すべきである。

本発明の実施形態の上記の説明は、例示及び説明の目的で提示された。本発明は、網羅的なものであること又は開示される厳密な形態に限定することを目的とするものではなく、修正及び変形態様は、上述の教示を考慮して可能であり、又は、本発明の実践により得ることができる。実施形態は、本発明の原理及びその実用的な適用例を説明して、当業者が本発明を種々の実施形態において、及び想定される特定の用途に適した種々の修正をもって使用できるように選択され、説明された。

送信デバイスが同期を必要としなくても、受信デバイスによって同期が実行される、送信デバイスから受信デバイスへの複数のオーディオ及びビデオ・パケットの伝達を示す図である。 本発明の実施に用いることができる電子デバイスの斜視図である。 図１の電子デバイスの回路の概略図である。 本発明の１つの実施形態の標準的な実施を表すフローチャートである。

Claims (35)

1. 複数のマルチメディア・ストリームに同期情報を与えるための方法であって、
   複数のマルチメディア・ストリームを受信デバイスに伝達し、
   前記複数のマルチメディア・ストリームの少なくとも１つと該複数のマルチメディア・ストリームの少なくとも他の１つとの間に、非同期、又は指定量の同期遅延を可能にする、前記受信デバイスに対する特定の命令を含む、前記複数のマルチメディア・ストリームに関する情報を伝達する、
   ことを含むことを特徴とする方法。
2. 前記命令は、前記受信デバイスに伝達されるセッション情報における属性として含まれることを特徴とする請求項１に記載の方法。
3. 前記命令は、前記マルチメディア・ストリームのうちの少なくとも２つの間に、受け入れることができる同期遅延値を含むことを特徴とする請求項１に記載の方法。
4. 前記命令は“ｓｙｎｃ＿ｊｉｔｔｅｒ”属性を含むことを特徴とする請求項１に記載の方法。
5. 前記“ｓｙｎｃ＿ｊｉｔｔｅｒ”属性は、非同期を指示する値を伴うことを特徴とする請求項４に記載の方法。
6. 前記“ｓｙｎｃ＿ｊｉｔｔｅｒ”属性は、受け入れることができる同期遅延値を伴うことを特徴とする請求項４に記載の方法。
7. 前記“ｓｙｎｃ＿ｊｉｔｔｅｒ”属性はＳＤＰ属性であることを特徴とする請求項４に記載の方法。
8. 前記命令は“ＮＯ＿ＳＹＮＣ”属性を含むことを特徴とする請求項１に記載の方法。
9. 前記命令は“ＮＬＳ”意味タグを含むことを特徴とする請求項１に記載の方法。
10. 前記伝達される情報は、前記受信デバイスに、前記複数のマルチメディア・ストリームのいずれも互いに同期しないように命令することを特徴とする請求項１に記載の方法。
11. 前記伝達される情報は、前記受信デバイスに、前記複数のマルチメディア・ストリームの１つを該複数のマルチメディア・ストリームの他のいずれとも同期しないように命令することを含むことを特徴とする請求項１に記載の方法。
12. 複数のマルチメディア・ストリームに同期情報を与えるコンピュータ・プログラム製品であって、
    複数のマルチメディア・ストリームを受信デバイスに伝達するためのコンピュータ・コードと、
    前記複数のマルチメディア・ストリームの少なくとも１つと該複数のマルチメディア・ストリームの少なくとも他の１つとの間に、非同期、又は指定量の同期遅延を可能にする、前記受信デバイスに対する特定の命令を含む、前記複数のマルチメディア・ストリームに関する情報を伝達するためのコンピュータ・コードと、
    を含むことを特徴とするコンピュータ・プログラム製品。
13. 前記命令は、前記受信デバイスに伝達されるセッション情報における属性として含まれることを特徴とする請求項１２に記載のコンピュータ・プログラム製品。
14. 前記命令は、前記マルチメディア・ストリームのうちの少なくとも２つの間に、受け入れることができる同期遅延値を含むことを特徴とする請求項１２に記載のコンピュータ・プログラム製品。
15. 前記命令は“ｓｙｎｃ＿ｊｉｔｔｅｒ”属性を含むことを特徴とする請求項１２に記載のコンピュータ・プログラム製品。
16. 前記“ｓｙｎｃ＿ｊｉｔｔｅｒ”属性は、受け入れることができる同期遅延値を伴うことを特徴とする請求項１５に記載のコンピュータ・プログラム製品。
17. 前記“ｓｙｎｃ＿ｊｉｔｔｅｒ”属性はＳＤＰ属性であることを特徴とする請求項１５に記載のコンピュータ・プログラム製品。
18. 前記伝達される情報は、前記受信デバイスに、前記複数のマルチメディア・ストリームの１つを該複数のマルチメディア・ストリームの他のいずれとも同期しないように命令することを含むことを特徴とする請求項１２に記載のコンピュータ・プログラム製品。
19. 前記伝達される情報は、前記受信デバイスに、前記複数のマルチメディア・ストリームのいずれも互いに同期しないように命令することを特徴とする請求項１２に記載のコンピュータ・プログラム製品。
20. プロセッサと、
    複数のマルチメディア・ストリームを受信デバイスに伝達するためのコンピュータ・コードと、
    前記複数のマルチメディア・ストリームの少なくとも１つと該複数のマルチメディア・ストリームの少なくとも他の１つとの間に、非同期、又は指定量の同期遅延を可能にする、前記受信デバイスに対する特定の命令を含む、前記複数のマルチメディア・ストリームに関する情報を伝達するためのコンピュータ・コードと
    を含む、前記プロセッサに動作的に連結するメモリ・ユニットと、
    を含むことを特徴とする電子デバイス。
21. 前記命令は、前記受信デバイスに伝達されるセッション情報における属性として含まれることを特徴とする請求項２０に記載の電子デバイス。
22. 前記命令は、前記マルチメディア・ストリームのうちの少なくとも２つの間に、受け入れることができる同期遅延値を含むことを特徴とする請求項２０に記載の電子デバイス。
23. 前記命令は“ｓｙｎｃ＿ｊｉｔｔｅｒ”属性を含むことを特徴とする請求項２０に記載の電子デバイス。
24. 前記“ｓｙｎｃ＿ｊｉｔｔｅｒ”属性は、受け入れることができる同期遅延値を伴うことを特徴とする請求項２３に記載の電子デバイス。
25. 前記“ｓｙｎｃ＿ｊｉｔｔｅｒ”属性はＳＤＰ属性であることを特徴とする請求項２３に記載の電子デバイス。
26. 前記伝達される情報は、前記受信デバイスに、前記複数のマルチメディア・ストリームのいずれも互いに同期しないように命令することを特徴とする請求項２０に記載の電子デバイス。
27. 前記伝達される情報は、前記受信デバイスに、前記複数のマルチメディア・ストリームの１つを該複数のマルチメディア・ストリームの他のいずれとも同期しないように命令することを含むことを特徴とする請求項２０に記載の電子デバイス。
28. 前記電子デバイスは、携帯電話、携帯情報端末、ラップトップ・コンピュータ、デスクトップ・コンピュータ、統合メッセージング・デバイス、及びそれらの組合せから成る群から選択されるデバイスを含むことを特徴とする請求項２０に記載の電子デバイス。
29. マルチメディア・コンテンツを処理するための方法であって、
    送信デバイスから複数のマルチメディア・ストリームを受信し、
    前記送信デバイスから、前記複数のマルチメディア・ストリームに関する情報を受信し、
    前記受信した情報が、前記複数のマルチメディア・ストリームの少なくとも１つと該複数のマルチメディア・ストリームの他の少なくとも１つとの間に、非同期又は指定量の同期遅延を可能にする特定の命令を含む場合には、前記特定の命令により該複数のマルチメディア・ストリームを表示する、
    ことを含むことを特徴とする方法。
30. 前記命令は、前記マルチメディア・ストリームのうちの少なくとも２つの間に、受け入れることができる同期遅延値を含むことを特徴とする請求項２９に記載の方法。
31. 前記命令は“ｓｙｎｃ＿ｊｉｔｔｅｒ”属性を含むことを特徴とする請求項２９に記載の方法。
32. 前記“ｓｙｎｃ＿ｊｉｔｔｅｒ”属性は、受け入れることができる同期遅延値を伴うことを特徴とする請求項３１に記載の方法。
33. 前記受信された情報により、前記複数のマルチメディア・ストリームのいずれも互いに同期されないことを特徴とする請求項２９に記載の方法。
34. 前記受信された情報により、前記複数のマルチメディア・ストリームの１つは、該複数のマルチメディア・ストリームの他のいずれのものとも同期されないことを特徴とする請求項２９に記載の方法。
35. プロセッサと、
    複数のマルチメディア・ストリームを受信デバイスに伝達するための手段と、
    前記複数のマルチメディア・ストリームの少なくとも１つと該複数のマルチメディア・ストリームの少なくとも他の１つとの間に、非同期又は指定量の同期遅延を可能にする、前記受信デバイスに対する特定の命令を含む、前記複数のマルチメディア・ストリームに関する情報を伝達するための手段と
    を含む、前記プロセッサに動作的に連結するメモリ・ユニットと、
    を含むことを特徴とする電子デバイス。

Images