変更されたストリーム同期
少なくとも第１のおよび第２のストリームの発信元間同期の方法およびシステムが記載される。第２のストリームは、入力ストリームとして第１のストリームを用いるメディアストリーム変更ユニットの出力ストリームである。方法は以下のステップを含む。第１の同期ポイントに到達する第１のストリームにおけるパケットの第１の到達時刻情報と、第２の同期ポイントに到達する第２のストリームにおけるパケットの第２の到達時刻情報と、を提供するステップ。前記入力ストリームおよび前記出力ストリームの間の同期関係に関する同期相関情報を提供するステップ。および、前記第１のおよび前記第２の到達時刻情報および前記同期相関情報に基づいて、遅延情報を計算するステップ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、関連するストリームの送信先間同期の方法およびシステムに関する。本発明はさらに、そのようなシステムにおいて使用する同期ユニット、同期点、到達時刻情報調整モジュールおよびデータ構造、およびそのような方法を使用するコンピュータプログラム製品に関する。
【背景技術】
【０００２】
ボイスオーバーＩＰ（ＶｏＩＰ）およびインターネットプロトコルテレビジョン（ＩＰＴＶ）などの新しいマルチメディア技術が、あらゆる範囲で新しいマルチメディアサービスを生み出す。これらのサービスの１つのタイプは、ユーザのグループが、同じテレビチャンネルを別々に見て、テキスト、音声、および／またはビデオを用いて互いに通信することを可能にする。これらのサービスの他のタイプは、対話型テレビジョン経験を提供する。例えば、テレビジョンのクイズ放送で、放送された問題に視聴者が家庭で答えを入力し、番組に参加することなどである。そのようなサービスは、端末の出力信号がグループ内のすべてのユーザに同時に送信されることを必要とする。言い換えれば、グループにおけるディスプレイまたはプレイアウト装置、例えばテレビジョン、ＰＤＡ、モバイル装置、ＰＣまたはそれらの組み合わせの、異なる送信先に対応する出力は、同期すべきであるということである。
【０００３】
ＩＰＴＶシステムにおいては、ＴＶチャンネル信号は典型的には、ヘッドエンド、エッジルータなどのネットワークノードおよびそのようなサービスの加入者の端末へのアクセスノードを介したオペレータの高帯域幅ＩＰネットワーク上を１つ以上のパケット化されたストリームとして送信される。そのようなストリームの送信の間、パケットは、送信の遅延、ネットワークルートの相違、およびコード化ならびにコード解除の遅延の相違などの、ネットワークにおける未知の遅延を被る。結果として、第１の端末（第１の送信先）で受信された音声および映像ストリームのパケットと、別の第２の端末（第２の送信先）で受信されたそれらとの間の時間的な関係が乱されるであろう。
【０００４】
ＩＰＴＶコンテンツを端末にストリーミングするためには、通常はリアルタイムトランスポートプロトコル（ＲＴＰ）が用いられる。ＲＴＰはシーケンスの番号付けおよびタイムスタンプ作成を提供する。ＲＴＰを用いることで、同じ最終端末で終端する関連ストリームの間（ストリーム間同期）の、または、異なる最終端末で終端する関連ストリームの間（グループ同期または送信先間同期）の、１つのストリーム内の時間的な関係（ストリーム内同期）が回復する。Ｆ．Ｂｏｒｏｎａｔらによる論文「マルチメディアグループおよびストリーム間同期技術：比較研究（Ｍｕｌｔｉｍｅｄｉａ ｇｒｏｕｐ ａｎｄ ｉｎｔｅｒ−ｓｔｒｅａｍ ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｔｅｃｈｎｉｑｕｅｓ：Ａ ｃｏｍｐａｒａｔｉｖｅ ｓｔｕｄｙ）」（Ｅｌｓｅｖｉｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍｓ ３４（２００９）１０８〜１３１ページ）は、知られている送信先間同期技術の総合的な概観を提供し、それは３つの主要なカテゴリに分けることができる。
【０００５】
「同期マエストロスキーム（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｍａｅｓｔｒｏ Ｓｃｈｅｍｅ）」（ＳＭＳ）においては、中央の同期マスターがグループ内のすべての端末からタイミング情報を集め、制御パケットを端末に配信することによって出力タイミングを調整する。「マスター−スレーブ受信器スキーム（Ｍａｓｔｅｒ−Ｓｌａｖｅ Ｒｅｃｅｉｖｅｒ Ｓｃｈｅｍｅ）」（ＭＳＲＳ）においては、受信器（端末）はマスター受信器とスレーブ受信器に分類される。マスター受信器はその出力タイミングをスレーブ受信器にマルチキャストし、スレーブ受信器はそれに従ってスレーブ受信器のパケットの出力タイミングを調整する。「配信制御スキーム（Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｎｔｒｏｌ Ｓｃｈｅｍｅ」（ＤＣＳ）においては、各端末（受信器）はグループ内のすべての他の端末にすべてのタイミング情報をマルチキャストし、端末は正確な出力タイミングを計算するように構成される。これらのスキームは、メディアストリームの発信元または受信器端末のいずれかで同期が発生するという点で共通する。
【０００６】
同時に係属する欧州特許出願には、発信元と受信器の間のストリームの通路に沿ったどこかでネットワークノードが同期化される、さらなる送信先間同期スキームが記載される。この方法は特に、オペレータネットワークにストリーム送信先を接続するアクセス回線における相違に由来するストリーム伝播時間の小さな相違を許容する、大規模な配置およびサービスに適している。
【０００７】
参考の送信先間同期技術の大部分は、端末におけるメディアストリーム受信におけるタイミング情報（例えば、ＲＴＰタイムスタンプ、特定のある時刻において受信されたＲＴＰメディアストリームのＲＴＰシーケンスナンバ、トランスポートストリームにおける１つ以上の等価パラメータ）を利用する。異なる受信器のタイミング情報を比較することによって、適切なストリーム調整が計算されることができる。調整の例は、受信器側においてバッファを用いることによる、受信されたストリームのプレイアウト時刻の遅延であってもよい。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
これらの知られている同期スキームに関連する１つの問題は、これらのスキームが、発信元と受信器の間のストリームがコンテンツ準備および／またはコンテンツ再生成の目的によって変更される状況を処理するようには設計されていないことである。
【０００９】
ストリームの変更は、多くの状況において必要でありうる、および／または有利でありうる。例えば、効率的な配信のためにメディアストリームを準備するために、メディアストリームはストリーム受信器またはアクセス線の、解像度の変更（例えば、ＨＤからＳＤへの変更またはより低いビットレートへの変更）などの特定の要請に適応してもよい。そのような状況において、トランスレータまたはトランスコーダと呼ばれるストリーム変更ユニットがストリームの通路に配置されてもよい。変更されたトランスコーダ出力ストリームは、オリジナルの（変更されていない）入力ストリームと比較して異なるタイムスタンプ、シーケンスナンバ、または他のタイミング情報を有してもよい。
【００１０】
メディアストリームは特定の顧客の要求のためにカスタマイズされてもよい。画面外のボイス、サブタイトル、ピクチャインピクチャをメインコンテンツストリームに加える必要があってもよい。これは典型的には、ミクサと呼ばれるストリーム変更ユニットによって行われる。さらに、ネットワークドメインがクロスする場合は、ストリームは、再生器（ｒｅ−ｇｅｎｅｒａｔｏｒ）ユニットを用いて再生されてもよい。すべてのこれらのコンテンツ準備および再生スキームは、ストリームにおけるタイミング情報を変化させ、それによって知られている送信先間同期スキームを、信頼できないものに、または使用不可能なものにさえする。したがって、従来技術においては、変更されたストリームと変更されていないストリームの間の、または２つの異なって変更されたストリームの間の、送信先間同期を可能にする方法およびシステムが必要となる。
【課題を解決するための手段】
【００１１】
従来技術において知られている同期スキームの欠点の少なくとも１つを低減するか取り除くこと、および、入力ストリームとして第１のストリームを使用するメディアストリーム変更ユニットの出力ストリームが第２のストリームであるかもしれない、少なくとも前記第１のおよび前記第２のストリームの送信先間同期の方法を提供することが本発明の目的である。方法は以下のステップを含んでもよい。第１の同期ポイントに到達する第１のストリームにおけるパケットの第１の到達時刻情報と、第２の同期ポイントに到達する第２のストリームにおけるパケットの第２の到達時刻情報と、を提供すること。前記入力ストリームおよび前記出力ストリームの間の同期関係に関する同期相関情報を提供すること。および、前記第１のおよび前記第２の到達時刻情報および前記同期相関情報に基づいて、遅延情報を計算すること。さらなる実施形態において、方法はさらに、少なくとも前記第１のまたは前記第２の同期ポイントに前記遅延情報を提供し、前記第１のおよび前記第２の同期ポイントによってそれぞれ出力される前記第１のおよび前記第２のストリームが実質的に同期するように、少なくとも前記第１のおよび前記第２の同期ポイントがストリームの出力を遅延させることを可能にする、ステップを含んでもよい。
【００１２】
同期相関情報を提供することによって、異なる機種環境の視聴者の集合、異なる端末を用いる視聴者の集合、および／または異なるサービス要求を有する視聴者の集合に向けられた関連するストリームが、なおも同期することができる。本発明はしたがって、異なる機種環境のネットワークにおける視聴者のグループが、同期された方式でメディアストリームを見ることを可能にする。
【００１３】
この文脈において、到達時刻とは通常、同期ポイントがメディアストリームのある部分を受信する時刻である。本発明の文脈において、当業者には、パケットが完全に到達する時間がここで用いられる必要がないことが理解される。到達時刻情報として用いられる現実の時刻はわずかに変化し、それは同期ポイントが到達時刻を決定するために用いる正確なポイントに依存する。この時刻は、例えばジッタバッファにパケットを配置する前の、到達時を直接用いてもよい。しかしながら、メディアパケットを取り扱う過程における遅れたポイント内にあってもよく、例えばコード解除過程の直前またはトランスレーション過程の直前などにあってもよい。メディアコンテンツのそのある特定の部分の現実の提示の前に、同期ポイントは、メディアパケットを処理するために必要な時間を知っていてもよく、到達時刻情報として現実の提示時間を使用してもよい。
【００１４】
一実施形態では、前記第１のおよび第２のストリームは少なくとも第１のおよび第２の同期ポイントによって出力され、前記同期ポイントは前記同期ポイントを同期させるために少なくとも１つの同期ユニットに接続される。
【００１５】
他の実施形態では、遅延情報を計算する前記ステップは、第１の到達時刻情報と第２の到達時刻情報の間の共通のタイムラインを達成するように、第１のおよび／または第２の到達時刻情報を調整する調整ステップを有してもよい。前記調整ステップは、同期相関情報の少なくとも一部に基づいてもよい。
【００１６】
一実施形態では、前記調整ステップは到達時刻情報調整モジュールによって実行され、前記モジュールは同期ユニットの一部であり、前記同期ユニットは同期相関情報を提供される。
【００１７】
他の実施形態では、前記調整ステップは同期ポイントにおいて実行されてもよく、前記同期ポイントは到達時刻情報調整モジュールを有してもよい。そのような到達時刻情報調整モジュールは同期相関情報の少なくとも一部を提供されてもよく、同期ユニットは調整された第２の到達時刻情報を提供される。
【００１８】
さらに他の実施形態では、調整ステップはネットワーク要素において実施されてもよく、前記ネットワーク要素は到達時刻情報を受信するように構成されてもよい。ネットワーク要素は到達時刻情報調整モジュールをさらに有してもよく、到達時刻情報調整モジュールは、同期相関情報の少なくとも一部を提供され、同期ユニットは調整された第２の到達時刻情報を提供される。
【００１９】
一実施形態では、前記同期ポイントは端末またはネットワークノードであってもよく、好ましくはアクセスノードであってもよい。さらなる変形例では、ストリーム変更ユニットはトランスレータまたはミクサであってもよく、同期ユニットは同期ポイントまたはサーバ内に含まれてもよい。
【００２０】
さらなる形態では、本発明は同期ユニットに関連してもよく、好ましくは、少なくとも、第１のメディアストリームを受信する第１の同期ポイントおよび第２のメディアストリームを受信する第２の同期ポイントの出力を同期させる同期サーバに関連してもよい。前記第２のストリームは、入力ストリームとして第１のストリームを用いるメディアストリーム変更ユニットの出力ストリームであってもよい。同期ユニットは、第１の同期ポイントに到達するストリームにおけるパケットの第１の到達時刻情報および、第２の同期ポイントに到達する第２のストリームにおけるパケットの第２の到達時刻情報を受信する手段、前記入力ストリームと前記出力ストリームの間の同期関係に関する同期相関情報を提供する手段、および、前記第１のおよび前記第２の到達時刻情報および前記同期相関情報に基づいて遅延情報を計算する手段を有してもよい。
【００２１】
他の実施形態では、同期ユニットは、受信されたストリームが実質的に同期するように、前記第１のおよび前記第２の同期ポイントにおける１つ以上の可変遅延ユニットが受信されたストリームの出力時間を遅延させることを可能にする遅延情報を、前記第１のおよび前記第２の同期ポイントに提供する手段を有してもよい。
【００２２】
さらなる形態では、本発明は少なくとも第１のおよび第２の同期ポイントの出力の送信先間同期システムに関してもよい。システムは、メディアストリームを配信するコンテンツ配信サーバ、入力メディアストリームを変更して、変更された出力メディアストリームにするように構成され、前記入力ストリームと前記出力ストリームの間の同期関係に関する同期相関情報を提供するように構成されたストリーム変更ユニット、および、上記の少なくとも１つの同期ユニットを含んでもよい。
【００２３】
さらなる形態では、本発明は上記システムにおいて使用する同期ポイントおよびメディアストリーム変更ユニットに関してもよい。さらに別の形態では、本発明は上記システムにおいて使用するデータ構造、好ましくはＲＴＣＰ拡張報告データ構造に関してもよい。前記データ構造は、メディア同期ポイントに到達するストリームにおけるパケット、またはメディアストリーム変更ユニットに到達するストリームにおけるパケット、または前記変更ユニットによって送信されるストリームにおけるパケットに関連づけられた同期ステータス情報を信号化する前記システムによって使用される。また、前記データ構造は、前記データ構造の発信元を識別する識別子、少なくとも１つのタイムスタンプ、好ましくはＲＴＰおよび／またはＮＴＰタイムスタンプ、および／またはメディアストリーム相関識別子を少なくとも含み、前記データ構造は、前記同期ユニットが、前記システムにおけるメディア同期ポイントに関連するメディアストリームを同期させることを可能にする。
【００２４】
本発明はまた、コンピュータのメモリにおいて実行されるとき、上記の方法ステップにおいて記載されたような方法ステップを実行するように構成されたソフトウェアコード部分を含む、コンピュータプログラム製品にも関してよい。
【００２５】
本発明はさらに、本発明による実施形態を概略的に示す添付の図面を参照して記載される。本発明はこれらの特定の実施形態にいかなる意味でも制約されるものではないことが理解されるであろう。
【図面の簡単な説明】
【００２６】
【図１】複数のストリーム変更ユニットを含み、関連するストリームを異なる位置に配信することが可能な、異なる機種環境のネットワークトポロジの例示的な実施形態を示す図である。
【図２】本発明の一実施形態によるシステムを示す図である。
【図３】本発明によるシステムに関連するフロー図である。
【図４】本発明の他の実施形態によるシステムを示す図である。
【図５】本発明の一実施形態による送信先間同期スキームの実施例を示す図である。
【図６】本発明の一実施形態による例示的なＲＴＣＰ拡張報告（ＲＴＣＰ ｅＸｔｅｎｄｅｄ Ｒｅｐｏｒｔ）を示す図である。
【図７】本発明の他の実施形態によるメディアストリームを同期させるＲＴＣＰメッセージの使用を示す図である。
【発明を実施するための形態】
【００２７】
図１は、ネットワーク全体のユーザ装置にコンテンツを配信するためのマルチメディア配信システム１００の例示的な実施形態を示す。ネットワークは異なる機種環境のトポロジを有し、複数のストリーム変更モジュールを含み、関連するストリームを異なる位置に配信することが可能である。この実施形態では、パケットを含むメディアストリームは複数のユーザ装置に配信され、メディアストリームは異なるユーザ装置に応じて異なる構成をとる。
【００２８】
本出願の文脈におけるパケットは、タイミング情報、例えばタイムスタンプに関連づけられたメディアストリームの１つ（すなわち１単位）である。そのようなパケットの一例は１つ以上のタイムスタンプを有するＲＴＰパケットである。他の例は、１つ以上の表示タイムスタンプを含むトランスポートストリーム（ＴＳ）パケットなどのＭＰＥＧタイプパケットである。
【００２９】
タイミング情報を含む任意のメディアパケットフォーマットが同期目的のために用いられてもよいことを、当業者は理解する。タイミング情報はトランスポートコンテナ（トランスポートプロトコル）の部分であってもよく、それは標準的なものか専有のものかのいずれかの、コンテンツの搬送のために用いられる。代わりに、または加えて、それは実在のコンテンツの部分であってもよく、例えばコンテンツをコード化するためのコード化スキームにおいて用いられるタイミング情報であってもよい。
【００３０】
図１におけるマルチメディア配信システムはメディアストリーム生成器１０１を含む。それは例えば、１つ以上のネットワーク、例えばＩＰネットワークを介して、メディアストリームを異なるユーザ機器（ＵＥ）１０６−１０９に配信することが可能なサーバを含む。ＵＥまたは端末はプレイアウト装置またはそれに接続された装置（例えばセットトップボックス）に関連してもよい。そのような装置には、例えば携帯電話、テレビジョンセット、ＩＰ電話、ゲーム操作盤、スマート計量装置などが挙げられてもよいが、該計量は、同期化されたストリームに応じた他の自動化された動作、例えば同期化された信号に応じた複数の計量装置の自動化された計量などであってもよい。
【００３１】
マルチメディア配信システムは様々なネットワーク要素を有してよく、該要素はメディアストリームにおけるタイミング情報が変更されるように、該メディアストリーム上である動作を実行する。そのようなネットワークエレメントは、以降では概してストリーム変更ユニットと呼ばれる。図１の実施形態では、システムは様々なストリーム変更ユニット、例えば第１のトランスコーダ１０２、第２のトランスコーダ１０３、およびミクサ１０４などを含む。サーバ１０５は代替のおよび／または追加の基本ストリーム１０５をミクサに配信してもよい。このサーバ１０５は、例えば代替の音声（異なる言語、監督のコメントまたはサラウンド音響）、代替のサブタイトル、または代替の映像（例えば、話し言葉を書き言葉に翻訳するサイナー（ｓｉｇｎｅｒ））を配信してもよい。
【００３２】
メディアサーバ１０１によって配信されるオリジナルのメディアストリーム１１０は、ＩＰ上のＵＤＰ上のＲＴＰを用いてネットワーク中に搬送されるＭＰＥＧ４コード化を伴うビデオオンデマンド（ＶｏＤ）ストリームであってもよい。このオリジナルのメディアストリーム１１０は、ＭＰＥＧ２コード化のみをサポートするＵＥ２ １０７の利益のためにＭＰＥＧ２コード化されたストリーム内に、オリジナルのＭＰＥＧ４コード化されたストリームをトランスコードする第１のトランスコーダ１０２によって、変更（すなわち、トランスコード）される。トランスコードされたメディアストリーム１１２は、ＩＰ上のＵＤＰ上のＲＴＰを用いてＵＥ２にさらに搬送される。
【００３３】
第２のトランスコーダ１０３はオリジナルのメディアストリーム１１０をトランスコードして、現実のコード化スキームが変化しないオリジナルのメディアストリームによって用いられるコンテナフォーマットとは異なるコンテナフォーマットを有する、変更されたメディアストリームにしてもよい。第２のトランスコーダ１０３は、ＵＤＰ上で直接搬送されるＭＰＥＧトランスポートストリームを用いるＵＥ３ １０８にネットワーク中でＭＰＥＧ４にコード化されるメディアストリームを、例えば配信してもよい。さらに、ミクサ１０４は１つ以上の追加の基本ストリームをオリジナルのメディアストリームに追加してもよく、オリジナルのメディアストリーム内の１つ以上の基本メディアストリームを１つ以上の代替の基本ストリームに置き換えてもよい。これらの追加の、または代替の基本ストリームはＩＰ上のＵＤＰ上のＲＴＰを用いてサーバ１０５によって配信される。したがって、ミクサ１０４は、ミックスされたメディアストリーム１１４を、ＩＰ上のＵＤＰ上のＲＴＰ上のＭＰＥＧを用いて、ＵＥ４に配信する。
【００３４】
図１に記載のマルチメディア配信システムにおいて、オリジナルのメディアストリーム１１０は、タイミング情報を含むトランスポートプロトコルを使用してもよい。一実施形態では、ＲＴＰプロトコルはトランスポート機構として用いられてもよい。ＲＴＰは、メディアストリームを同期化するタイミング情報として用いられてもよいＲＴＰタイムスタンプを用いる。
【００３５】
第１のトランスコーダ１０２はオリジナルのストリーム１１０をコード解除して、メディアを再コード化（例えばＭＰＥＧ４からＭＰＥＧ２に）してもよい。したがって、それは、ＵＥ２ １０７への送信の開始を示すランダムＲＴＰタイムスタンプを用いて変更されたメディアストリームを送信するであろう。したがって、同じトランスポートプロトコル（ＩＰ上のＵＤＰ上のＲＴＰ）が用いられていても、出ていくメディアストリームのタイムスタンプは入ってくるメディアストリームのタイムスタンプとは異なる。
【００３６】
第２のトランスコーダ１０３はオリジナルのストリーム１１０をコード解除せず、異なるトランスポートコンテナを用いるＵＥ３ １０８にメディアストリーム１１３を送信する。例えば、ＵＤＰ上のＭＰＥＧトランスポートストリーム（ＴＳ）はコンテンツをＵＥ３に送信するように用いられる。これらのＭＰＥＧ ＴＳパケットは、パケットが表示のために示されるべき瞬間を表示するための、いわゆるプレゼンテーションタイムスタンプ（ＰＴＳ）の形態でタイミング情報を含んでもよい。たとえ、入ってくるメディアストリームと出ていくメディアストリームの間の現実のコード化が変化しないままであったとしても、これらのＰＴＳはオリジナルのメディアストリーム１１０のＲＴＰタイムスタンプとは異なる。
【００３７】
ミクサ１０４は、メディアストリーム１１１における１つ以上の基本ストリームをオリジナルのメディアストリーム１１０とミックスすることができる。その後、ミクサ１０４はミックスされたメディアストリーム１１４をネットワークを介してＵＥ４ １０９に送信してもよい。ミクサが新しいメディアストリームを生成するとき、ミクサはこのストリームをＵＥ４に送信する開始時刻として、無作為に生成された新しいＲＴＰタイムスタンプを使用し、入力ストリーム１１０に用いられるコード化およびトランスポートスキームが、ミックスされた出力ストリーム１１４に用いられるコード化およびトランスポートスキームと同じである。
【００３８】
さらにいかなる測定もない場合は、ＵＥにおけるプレイアウトの同期は不可能である。というのは、ネットワークにおけるコンテンツ変更ユニットはストリームにおけるタイミング情報を変化させ、発信元とＵＥのタイムスタンプを互いに一致させなくするためである。この理由は、メディアサーバ１０１、トランスコーダ１０２および１０３、およびミクサ１０４がそれぞれ開始時刻として無作為なタイムスタンプを選ぶためである。この同じ問題がミクサに存在する。ミクサは、オリジナルのメディアサーバ１０１と、他の発信元、すなわち追加のおよび代替の基本ストリーム１０５を有するメディアサーバの両方から、メディアストリームを受信する。上記の説明のとおり、これらのメディアストリームにおけるタイムスタンプは相関づけされない。
【００３９】
図２は、メディアストリームを同期させるための、第１の同期ポイント２０５および第２の同期ポイント２０８を有するマルチメディア配信システム２００の概略図を示す。同期ポイントとは、同期情報（例えば到達時刻情報）が決定されるストリームの通路における（論理的または物理的な）ポイントである。同期ポイントはネットワークに接続されるかネットワーク内に組み込まれた任意の物理的装置に含まれてもよい。同期ポイントは、例えばネットワークノード、例えばアクセスノード（例えばデジタル加入者線アクセスマルチプレクサ（ＤＳＬＡＭ）、ケーブルモデム終端システム（ＣＭＴＳ））、光アクセスノードまたはエッジルータまたはヘッドエンドなどに関連してもよい。代替として、同期ポイントがテレビジョン、パーソナルコンピュータ、ラップトップ、ネットブック、パーソナルデジタルアシスタント、またはメディアストリームを取り扱うことが可能な任意の他の装置に接続されたセットトップボックスとして形成されてもよい。
【００４０】
マルチメディア配信システムは、メディアストリーム発信源２０１、例えばビデオオンデマンドストリームまたはライブマルチキャストテレビジョン放送を配信する、例えばメディアサーバを含んでもよい。このメディア発信源２０１はオリジナルの第１のメディアストリーム２１２をネットワーク２１１を介して同期ポイントに送信してもよい。第１の同期ポイント２０５は、いかなる変更もないオリジナルのメディアストリーム２１２を受信してもよい。しかしながら、第２の同期ポイント２０８は、同じコンテンツであるが例えば異なるフォーマットであるコンテンツを有するストリームを受信してもよい。したがって、第２の同期ポイント２０８は、メディアストリーム変更ユニット２０２によって生成された、変更された第２のメディアストリーム２１３を受信する。メディアストリーム変更ユニット２０２は、オリジナルのメディアストリーム２１２を受信し、変更されたメディアストリーム２１３を生成する。
【００４１】
第１のおよび第２のストリーム同期ポイント２０５、２０８は、それぞれ第１のおよび第２のメディアストリーム２１２、２１３の間の送信先間同期（またはグループ同期）を提供するように構成されてもよい。この目的のために、メディアストリーム同期ポイントはメディア同期ユニット２０４、例えばメディア同期アプリケーションサーバ（ＭＳＡＳ）に接続される。第１のおよび第２のストリーム同期ポイント２０５、２０８は第１のおよび第２の同期クライアント２０７、２１０と、例えば変化可能な遅延バッファ２０６、２０９を含む第１のおよび第２の変化可能な遅延ユニットとを、それぞれ含んでよい。第１のおよび第２の同期クライアント２０７、２１０は、以下により詳細に説明されるように、ＭＳＡＳ２０４と同期情報を交換するように構成される。
【００４２】
メディアストリーム変更ユニット２０２は、メディアストリーム変更ユニットと関連づけられた第３の同期クライアントＳＣ’２０３をさらに含んでもよい。同期クライアント２０７、２１０、２０３は、例えば信号化経路２１４を用いてＭＳＡＳ２０４とメッセージを交換する。これらの信号化メッセージは、メディア配信において用いられる同じネットワーク２１１上で搬送されてもよい。代替として、メッセージは同様に他のネットワーク上で搬送されてもよい。以下の説明において、信号化経路２１４は同期参照ポイントとみなされる。
【００４３】
この例において、オリジナルのメディアストリーム２１２は、例えば、ＵＤＰプロトコルを用いてＩＰネットワーク上でＲＴＰにおいて搬送されるビデオストリームに関連することができる。その場合には、オリジナルのメディアストリーム２１２におけるＲＴＰパケットはメディアストリーム発信元２０１によって生成されるＲＴＰタイムスタンプおよびＲＴＰプロトコルにおいて定義された同期発信元（ＳＳＲＣ）識別子を含むことができる。
【００４４】
変更されたストリーム２１３は、オリジナルのメディアストリーム２１２と同じコンテンツであるがメディアストリーム変更ユニット２０２によって変更されているコンテンツを有してもよい。変更は、図１を参照にした上記のような変更動作であってもよく、例えば、オリジナルのストリームが高帯域幅高解像度（ＨＤ）ストリームであってもよく、変更されたストリームが低帯域幅標準解像度（ＳＤ）であってもよい。他の変更は、例えば、ネットワーク内の１つ以上のストリーム同期ポイントによってサポートされるデジタル権利管理（ＤＲＭ）システムに関連する暗号化スキームの適用であってもよい。この変更は再発信（ｒｅ−ｏｒｉｇｉｎａｔｉｏｎ）に関してもよい。再発信は、メディアストリームがネットワークの境界を超えた場合、例えば、ＩＰＴＶプロバイダが１つ以上のプライベートＩＰＴＶネットワークと同様にインターネット上で有効なメディアストリームを提供することを欲した場合に提供される。他の変更は、ミックスに基づく変更を含んでもよい。それは例えば、ビデオストリームにおいて手話を実行する人を含めること、あるいは、異なるメディアコンテナにおいてストリームを再送信すること、例えば、ＲＴＰを用いるかわりにＭＰＥＧトランスポートストリーム（ＴＳ）を用いることである。
【００４５】
変更されたメディアストリーム２１３におけるＲＴＰパケットは、オリジナルのメディアストリーム２１２におけるそれらと比較して異なるＳＳＲＣ識別子と異なるＲＴＰタイムスタンプを有してもよい。ＩＥＴＦ ＲＴＣ ３５５０によれば、ＳＳＲＣ識別子とＲＴＰタイムスタンプはＲＴＰパケットにおいて３２ビットヘッダフィールドである。各メディアストリームにおいて、ＲＴＰタイムスタンプの開始時間は無作為に選択されるべきである。さらに、ＳＳＲＣは無作為に選ばれた値であり、それはグローバルに一意的であることを意味している。知られている送信先間同期スキームにおいて、同期は各ストリーム同期ポイントへの信号化タイムスタンプ情報によって達成されることができる。しかしながら、第１のおよび第２のストリーム２１２、２１３におけるＲＴＰタイムスタンプは異なるため、第１のおよび第２の同期ポイントにおけるメディアストリームの直接の同期は可能ではない。
【００４６】
マルチメディア配信システムにおいて、第１のおよび第２のストリーム同期ポイント２０５、２０８は、いわゆる同期ステータス情報をＭＳＡＳ２０４に送信することができる。この同期ステータス情報は、メディアストリームに関連する識別情報（例えばＳＳＲＣ識別子）、およびタイミング情報（例えば、パケットのプレイアウト時刻に関連づけられたＲＴＰタイムスタンプおよびＮＴＰタイムスタンプ）を有してもよい。
【００４７】
ＲＴＰタイムスタンプはＲＴＰデータパケットにおける第１のオクテットのサンプリング例を示す。タイムスタンプの初期値は無作為な値である。ＲＴＰタイムスタンプはサンプリング期間をカウントするので、第２のＲＴＰパケットが第１のＲＴＰパケットの後に１６０のサンプルをスタートさせた場合、第２のＲＴＰタイムスタンプは第１のＲＴＰタイムスタンプよりも１６０大きい。
【００４８】
ＮＴＰタイムスタンプは絶対的な「壁掛け時計（ｗａｌｌ ｃｌｏｃｋ）」時刻である。ＮＴＰは、ＩＥＴＦ ＲＦＣ １３０５において定義されたような、１９００年１月１日から始まる６４ビットカウンタである。ＮＴＰによって用いられる６４ビットタイムスタンプは、３２ビットの整数秒部分と３２ビットの小数点以下部分からなる。ＮＴＰタイムスタンプは、ＲＴＰタイムスタンプによって識別される第１のオクテットが、特定のポイント、すなわち同期ポイントを通過する絶対的な時間を表す。
【００４９】
この特定のポイントは、ＳＣを含むユーザ機器（ＵＥ）のプレイアウトポイントであってもよく、ＮＴＰタイムスタンプは、特定のオクテットがユーザに示された時刻を表す。代替として、それは、ＳＣが特定のオクテットを最初に受信する入来ポイントであってもよい。同様の方法で、ＳＣ’を同期化するために、この特定のポイントは出力ポイントまたは入力ポイントであってもよい。
【００５０】
第１のストリーム同期ポイントは、以下の第１の同期ステータス情報メッセージをＭＳＡＳに送信することができる。
ＳＳＲＣ識別子＝１２３４５６７８
ＲＴＰタイムスタンプ＝１５５６６８８４２３
ＮＴＰタイムスタンプ＝１３：４２：２１．０００
同様に、第２のメディアストリーム同期ポイントが、以下の第２の同期ステータス情報メッセージをＭＳＡＳに送信することができる。
ＳＳＲＣ識別子＝９０ＡＢＣＤＥＦ
ＲＴＰタイムスタンプ＝１６８４６５４８４５
ＮＴＰタイムスタンプ＝１３：４２：２１．０００
【００５１】
この例では、第１のおよび第２のストリーム同期ポイントからの情報は、同じＮＴＰプレイアウト時刻、１３：４２：２１．０００に関連する。この例では、両方のメディアストリーム同期ポイントがＮＴＰ同期している、すなわち、ネットワークタイムプロトコルまたは何らかの他の手段を使用してそれらの時計は同期していると、考えられる。
【００５２】
上で説明したように、変更されたメディアストリームが同じコンテンツを搬送するが、メディアストリーム変更ユニット２０２が変更された出力ストリーム２１３においてタイミング情報を変更するので、同期は可能ではないことがある。同期を可能にするために、メディアストリーム変更ユニット２０２に関連する同期クライアントＳＣ’は、メディアストリーム変更ユニットによって受信された、入ってくるメディアストリーム２１２と、メディアストリーム送信ユニットによって第２のメディアストリーム同期ポイントに送信される、出て行くメディアストリーム２１３と、の間の同期関係に基づく同期相関情報メッセージを送信してもよい。したがって、同期関係は第１のパケットにおける第１のタイミング情報と、第２のパケットにおける第２のタイミング情報に関しており、第１のおよび第２のパケットは同一のコンテンツまたはその一部を有し、前記第２のパケットはメディアストリーム変更ユニットによって変更されたストリームの一部であり、前記第１のパケットは前記変更を受ける前のメディアストリームの一部である。
【００５３】
第１の実施形態では、メディアストリーム変更ユニットは以下の情報をＭＳＡＳに送信してもよい。
入ってくる：
ＳＳＲＣ識別子＝１２３４５６７８
ＲＴＰタイムスタンプ＝１５５６６８８４２３
出ていく：
ＳＳＲＣ識別子＝９０ＡＢＣＤＥＦ
ＲＴＰタイムスタンプ＝１６８４６５７８４５
この情報は、入ってくるＳＳＲＣ識別子／ＲＴＰタイムスタンプの組と、出ていくＳＳＲＣ識別子／ＲＴＰタイムスタンプの組と、の両方を含む。したがって、同期相関情報メッセージは、ＭＳＡＳに信号化されたＳＳＲＣおよび／またはＲＴＰタイムスタンプを使用して、ストリーム変更ユニットの入力において受信された１つ以上のストリームと、ストリーム変更ユニットの出力において送信された１つ以上のストリームと、の相関を可能にすることができる。
【００５４】
一実施形態では、同期相関情報は１つのメッセージでＭＳＡＳに送信されてもよい。他の実施形態では、同期相関情報は２つの別々のメッセージで送信されてもよい。別々のメッセージの使用は、入ってくるストリームまたは出ていくストリームのいずれかの同期パラメータが時間を通してあまり大きく変化しない場合には、これらのストリームに関連した同期情報の信号化が頻繁には必要ないため、有利である。同期情報の信号化に関するさらなる詳細は、図５〜図７を参照して以下に説明される。
【００５５】
ＭＳＡＳ２０４は、メディアストリーム同期ポイントおよび、メディアストリーム変更ユニットからの同期関係を含む同期相関情報メッセージの両方から、第１のおよび第２の同期ステータス情報メッセージを受信する。その後、ＭＳＡＳ２０４はこの情報を用いて、第１のおよび第２のメディアストリーム同期ポイントにおけるタイミング情報を計算する。
【００５６】
この計算は２つの計算ステップを含むことができる。第１のステップは、すべての同期ステータス情報を１つの時間軸（時間基準）に調整する計算に関する。第２のステップにおいては、現実の遅延情報が計算される。以下の例では、両方のＲＴＰタイムスタンプがミリ秒スケールを示すと考える。そうでなければ、計算はこのことを反映するように調整されるべきである。第１のステップにおいては、すべての同期ステータス情報は１つの共通の時間軸、例えば、オリジナルのメディアストリーム２１２のＲＴＰタイムスタンプに関連する時間軸に適合される。このステップはステータス情報変換ステップと呼ばれる。
【００５７】
１３：４２：２１．０００において、第１のメディアストリーム同期ポイント２０５はタイムスタンプ１５５６６８８４２３にある。この例では、第２のメディアストリーム同期ポイント２０８によって提供されたタイムスタンプはオリジナルのメディアストリーム２１２に関連する時間軸に調整される。他の変形例では、変更されたストリームに関連する時間軸に基づいて同期ステータス情報を調整すること、または両方のストリームの時間軸を新しい（第３の）時間軸に調整することが可能であってもよい。第３の時間軸の例は、各メディアストリームがタイムスタンプ０で開始して、各ストリームから無作為に選ばれた第１のタイムスタンプが０への調整を必要とするような状況に関連してもよい。
【００５８】
第２のメディア同期ポイント２０８から受信された同期ステータス情報を調整するために、以下の情報が用いられる。
−値１６８４６５４８４５を有する調整されたストリームの同期ステータス情報におけるＲＴＰタイムスタンプ
−変更されたストリームに関連するＲＴＰタイムスタンプ値１６８４６５７８４５が、オリジナルのストリームに関連するＲＴＰタイムスタンプ値１５５６６８８４２３に相関する。
タイムスタンプを調整するための計算は簡単な線形変換に関するものでよい。調整されたタイムスタンプ＝ｃｏｎｖ＿ｔｉｍｅｓｔａｍｐ＿ｏｒｇ＿ｓｔｒｅａｍ＋ｃｏｎｖ＿ｔｉｍｅｓｔａｍｐ＿ｍｏｄ＿ｓｔｒｅａｍ−ｔｉｍｅｓｔａｍｐ＿ｍｏｄ＿ｓｔｒｅａｍ＿ｃｕｒｒｅｎｔ。したがって、１３：４２：２１．０００に、第２のメディアストリーム同期ポイント２０８は、調整されたタイムスタンプ１５５６６８８４２３＋１６８４６５４８４５−１６８４６５７８４５＝１５５６６８５４２３に関連するかもしれない。そのように、第２のメディアストリーム同期ポイント２０８から受信された同期ステータス情報は、第１のメディアストリーム同期ポイント２０５から受信された同期ステータス情報に関連する時間軸に調整されてもよい。
【００５９】
その後、遅延情報の計算が知られているスキームに従って実行されてもよい。例えば、遅延情報はメディアストリームを再生する際にいちばん遅れているクライアントに基づいて決定される。上記の例において両方のタイムスタンプが同じ時刻１３：４２：２１．０００に報告されているため、計算は双方のメディアストリーム同期ポイントの同期ステータス情報の単純な減算を含んでもよい。１５５６６８５４２３−１５５６６８８４２３＝−３０００。この結果は、第２のメディアストリーム同期ポイント２０８におけるメディアストリームが、第１のメディアストリーム同期ポイント２０５におけるメディアストリームから３秒遅れていることを示す。この時間差はメディアストリーム変更ユニット２０２において実行されたトランスコードプロセスに起因するかもしれない。報告された時刻（すなわちＮＴＰ時刻）がＭＳＡＳによって受信された異なる同期ステータス情報メッセージにおいて異なる場合は、この時刻の相違は、遅延を決定するための計算において考慮されるべきである。
【００６０】
上記から、変更されたストリームは３秒遅れている（タイムスタンプの右から４桁目に示されているように）ということになる。別の実施形態では、調整されたメディアストリームの時間軸が用いられてもよい。１６８４６５７８４５ｍｓ−１６８４６５４８４５ｍｓ＝３０００ｍｓ。したがって、両方のメディアストリーム同期ポイントのメディアストリームを同期させるためには、ＭＳＡＳは第１の同期ポイント２０５に同期設定指示を送信して、プレイアウトを３秒遅らせてもよい。
【００６１】
図３は、図２を参照した上記の例におけるメッセージフロー図３００における情報の交換を図示する。第１のステップ３０２において、第１の同期ポイントはメディアストリーム発信元からオリジナルのメディアストリームを受信し、第２の同期ポイントはメディアストリーム変更ユニットの出力から変更されたメディアストリームを受信し、メディアストリーム変更ユニットは入力信号としてメディアストリーム発信元からのオリジナルのメディアストリームを用いる。
【００６２】
第２のおよび第３のステップ３０４、３０６において、第１のおよび第２の同期ポイントはそれぞれ第１のおよび第２の同期ステータス情報メッセージをメディア同期アプリケーションサーバ（ＭＳＡＳ）に送信する。その後、第４のステップ３０８において、メディアストリーム同期ユニットは、入ってくるメディアストリームと出ていくメディアストリームの間の同期関係に基づく相関情報メッセージをＭＳＡＳに送信する。したがって、ＭＳＡＳは第５のステップ３１０において、同期設定指示を計算して、送信先、すなわち第１のおよび第２の同期ポイントにこれらの指示を送信してもよい。
【００６３】
図２および図３を参照して記載された非限定的な例は、１つのメディアストリーム変更ユニットおよび２つの同期ポイントを用いる送信先間同期スキームを示す。さらなる変形例では、そのようなスキームは２つ以上のストリーム変更ユニットと共に、および／または２つ以上のメディア同期ポイントと共に用いられてもよい。ネットワーク上の信号化メッセージ（例えば同期ステータス情報メッセージ、異なるタイムスタンプを相関化する情報を含むメッセージ、同期設定指示）を搬送するために異なるプロトコルが用いられてもよい。これらのメッセージは例えばＨＴＴＰ上でＳＯＡＰを用いるＸＭＬフォーマット（Ｗ３Ｃ推奨）、ＳＩＰメッセージ（ＩＥＴＦ ＲＦＣ ３２６１）またはＲＴＣＰメッセージでＭＩＭＥメッセージボディにおけるＸＭＬフォーマットまたはプレーンテキストにおいて搬送されてもよい。
【００６４】
図２および図３を参照して記載された例において、変更可能な遅延ユニットおよび同期ユニットはクライアントサーバタイプモデルにおいて実施され、そこでは、遅延ポイントにおける変更可能な遅延ユニットの機能は同期クライアント（ＳＣ）の一部として実施されてもよく、同期ユニットは同期サーバ（ＳＹＮＣＨＳまたはメディア同期アプリケーションサーバ（ＭＳＡＳ））として実施されてもよい。同期クライアントは、同期ステータス情報が適切なプロトコルを用いて同期サーバ（同期ユニット）に送信可能となり、同期設定指示が同期サーバから受信可能となるプロトコルソケットを有してもよい。
【００６５】
同期ステータス情報はストリーム受信に基づいたタイミング情報（すなわち、第１の同期ポイントに到達するストリームにおけるパケットの到達時間）を含んでもよく、現在の遅延設定を含んでもよい。したがって、同期ステータス情報は、ストリームにおけるパケットが同期ポイントによって受信される時間においてポイントを考慮する情報を含んでもよい。同期設定指示は、例えば実際に計算された遅延を用いて変更可能な遅延バッファを設定することについての指示を含んでもよい。
【００６６】
同期設定指示および遅延指示という用語は、本発明の目的のために同じ意味で用いられており、あるメディアストリームの実際の遅延時刻を含んでもよい。好ましくは、これらの遅延指示は所定の継続時間だけメディアストリームを遅延させることに関する正の時間値を含んでもよい。代替として、遅延指示はメディアストリームのプレイアウトまたは出力を速めることに関する負の時間値を含んでもよい。ある同期ポイントが大きなバッファを有し、知られている測定を用いてバッファリング時刻を減少させることによって遅延を短縮することを可能にする場合が、これにあてはまるかもしれない。
【００６７】
図４は、ＥＴＳＩ ＴＳ １８２ ０２７ ｖｅｒｓｉｏｎ ２．０．０で特定されるＩＭＳに基づいたＩＰＴＶシステム４００として実施される本発明による例示的なコンテンツ配信システムを示す。ＩＰＴＶシステム４００はＩＰＴＶメディア機能（ＭＦ）４０１からなり、メディア制御機能（ＭＣＦ）４０２およびメディア配信機能（ＭＤＦ）４０３を含む。さらに、ＩＰＴＶシステム４００は搬送機能（ＴＦ）４０４、ユーザ機器（ＵＥ）４０５、ＩＰＴＶサービス制御機能（ＳＣＦ）４０６、個別のアプリケーションサーバ（ＡＳ）４０７およびコアＩＭＳネットワーク（Ｃｏｒｅ）４０８を含む。同期クライアント（ＳＣ）４０９はＵＥ４０５の部分であってもよく、搬送機能４０４の部分であってもよい。同期方法の部分として、ユーザ機器がストリームをバッファ可能であるならば、ＳＣはユーザ機器において実施されてもよい。ＳＣは、例えばユーザ機器がバッファ機能をサポートしていない場合に搬送ネットワークにおいて実装されてもよい。ＳＣは少なくとも１つの変更可能な遅延バッファに関連しており、したがってＳＣがＵＥ内で実装される場合、ＳＣは１つ以上の関連する変更可能な遅延バッファ４１０を有してもよい。同様に、ＳＣが搬送機能の一部として実施される場合は、搬送機能を含む要素は１つ以上の変更可能な遅延バッファ４１０を有してもよい。ＭＳＡＳ４１１の機能は、搬送機能またはメディア機能の部分として、標準ＩＰＴＶサービス制御機能４０６に含まれてもよく、代替として、スタンドアローンなアプリケーションサーバ４０７上で実施されてもよい。メディアストリーム変更ユニット（ＭＳＭＵ）４１３はＩＰＴＶメディア機能４０１の一部であってもよい。ＭＤＦ４０３は実際のトランスコードを実行することができ、ＭＣＦ４０２は同期クライアント（ＳＣ’）４１２を含むことができる。
【００６８】
図５は、本発明の一実施形態による送信先間同期スキーム５００の実施形態を示し、ＲＴＣＰ ＲＴＰ制御プロトコル（ＲＴＣＰ）が、メディア配信システムにおける要素間で同期情報を搬送するために用いられる。システムは２つの同期クライアントＳＣａ、ＳＣｂ ５０２、５０４を含む。同期クライアントは第１のおよび第２のメディアストリーム５１２、５１４に関連づけられた信号同期ステータス情報をＭＳＡＳ５０８に信号化するように設定されている。２つの同期クライアントは２つの異なるＲＴＰメディアストリームを受信する２つのユーザ機器（ＵＥ）（図示せず）内にあり、該２つのメディアストリームは異なるサンプリングレートであってもよい。ＳＣａによって受信された第１のメディアストリーム５１２は、メディアストリーム発信元（すなわちメディアサーバ）に関連したオリジナルのメディアストリームであってもよく、ＳＣｂによって受信された第２のメディアストリーム５１４は、変更されたメディアストリームであってもよい。第１のメディアストリームを第２のメディアストリームに変更する、メディアストリーム変更ユニット（トランスコーダ）５０２は、該第１のおよび第２のメディアストリームの間の同期関係をＭＳＡＳに報告する特別な同期クライアントＳＣ’５１０を含む。
【００６９】
システムはＵＥ、メディアストリーム変更ユニットおよびメディアストリーム発信元の間のメディアセッションをセットアップするためにＳＩＰを使用してもよい。ＳＩＰ信号化によって搬送されたセッション記述プロトコル（ＳＤＰ）が、各セッションにおけるメディア構成要素を記述およびネゴシエートするために用いられてもよい。セットアップの最中、ＵＥ（およびメディアストリーム変更ユニット）は、特定のＵＥが属する同期グループを識別するＳｙｎｃＧｒｏｕｐＩｄと関連づけられてもよい。
【００７０】
同期グループは、１つ以上の指定されたメディアストリームに関して同期されることが必要なＵＥのグループである。そのようなグループの例は、同期方法において互いに同じコンテンツオンデマンド（映画）を観ることを要求する、２つの異なる位置にある２つの異なるユーザに属する２つのＵＥであってもよい。
【００７１】
同期セッションを設定する詳細な説明のために、「Ｄｙｎａｍｉｃ ＲＴＣＰ ｒｅｌｙ」という名称の、同時に係属する欧州特許出願が参照され、それは本出願への参照によって本明細書に組み込まれる。
【００７２】
さらに、ＵＥおよびメディアストリーム変更ユニット、特にその中に位置する同期クライアントは、ＲＴＰ制御プロトコル（ＲＴＣＰ）を用いて、同期情報をＭＳＡＳに関連づけられたＩＰアドレスおよびポート番号に送信し、ＵＥに関連づけられたＲＴＣＰ受信器ポート上でＭＳＡＳからのＲＴＣＰ報告を受信してもよい。一実施形態では、同期クライアントは、ＲＴＣＰ拡張報告（ＲＴＣＰ ＸＲ）を用いたＲＴＣＰ受信器報告（ＲＴＣＰ ＲＲ）において同期ステータス情報を含み、１つ以上のＲＴＣＰメッセージ内のその情報をＭＳＡＳに送信することができる。
【００７３】
特に、同期クライアントは、同期ステータス情報を含む、特別にフォーマットされたＲＴＣＰ拡張報告（ＲＴＣＰ ＸＲ）５１６、５１８を生成してもよい。この情報はＮＴＰタイムスタンプと組み合わせられたＲＴＰタイムスタンプの形式であってもよい。ＲＴＣＰ ＸＲは発信元のＳＳＲＣ、パケットで受信されたＮＴＰタイムスタンプ、パケットで受信されたＲＴＰタイムスタンプ（ＲＴＰ受信タイムスタンプ）をさらに有してもよく、随意には、ＳｙｎｃＧｒｏｕｐＩｄパラメータを有してもよい。さらに、ＲＴＣＰ ＸＲは、ＸＲにパケットで示されたＮＴＰタイムスタンプ（ＮＹＰ表示タイムスタンプ）を有してもよい。
【００７４】
ＳｙｎｃＧｒｏｕｐＩｄパラメータはセッション記述プロトコル（ＳＤＰ）セッションレベル属性、例えば、ａ＝ＲＴＣＰ−ｘｒ：ｓｙｎｃ−ｇｒｏｕｐ＝＜ｖａｌｕｅ＞として、または、例えばＩＥＴＦ ＲＦＣ ３５５０によるＳＤＥＳ ＰＲＩＶアイテムの形式で実施されてもよい。さらなる実施形態では、ＩＥＴＦ ＲＦＣ ３６１１から知られるＲＴＣＰ−ｘｒ属性フィールドが用いられてもよい。
【００７５】
メディアストリーム変更ユニットＳＣ’に関連づけられた同期クライアントは、ＭＳＡＳに同期相関情報を報告する。ＵＥに関連づけられた同期クライアントとは対照的に、ＳＣ’はトランスコーダの入力で１つ以上のメディアストリームに関連づけられたＲＴＣＰ ＸＲと、トランスコーダの出力で１つ以上のメディアストリームに関連づけられたＲＴＣＰ ＸＲを送信する。一般的に、同期相関情報５２０は２つのＲＴＣＰ ＸＲによって形成され、それは入力ストリームに関連づけられた第１のＲＴＣＰ ＸＲ５２２および出力ストリーム（すなわち変更された入力ストリーム）に関連づけられた第２のＲＴＣＰ ＸＲ５２４である。したがって、同期相関情報は、一方は入力ストリームに関連づけられもう一方は出力ストリームに関連づけられた２組のタイムスタンプ（ＲＴＰ１，ＮＴＰ１）および（ＲＴＰ２，ＮＴＰ２）を有してもよい。
【００７６】
ＭＳＡＳはさらに、同期設定指示を含むＲＴＣＰ ＸＲを同期クライアントＳＣａ、ＳＣｂに送信してもよい。これらのＲＴＣＰ ＸＲは発信元のＳＳＲＣ、パケットで受信された参照ＮＴＰタイムスタンプ、パケットで受信された参照ＲＴＰタイムスタンプ受領タイムスタンプを含んでもよい。ＲＴＣＰ ＸＲはまた、パケットで示された参照ＮＴＰタイムスタンプをさらに有してもよい。これらのＲＴＣＰ ＸＲは共にＲＴＣＰ送信者報告（ＳＲ）に追加されてもよく、ＵＥによって別々に受信されてもよい。
【００７７】
同期設定はＮＴＰタイムスタンプと組み合わせられたＲＴＰタイムスタンプの形式であってもよく、ここでＮＴＰタイムスタンプは、例えばＳｙｎｃＧｒｏｕｐＩｄによって識別されたとして同期グループによって分割されたクロックを示し、ＲＴＰタイムスタンプは期待される提示時刻を示す。
【００７８】
一実施形態において、同期クライアントはＭＳＡＳと同一場所に配置されてもよい。この場合には、同期ステータス情報と同期設定指示の交換は、それらが存在するＭＳＡＳの１つ以上の機能エンティティの内部で行われる。
【００７９】
別の実施形態において、同期は１つ以上のブロードキャストストリームの同期に関してもよい。この場合には、ＭＳＡＳは、ＲＦＣ ３５５０においてより詳細に記載されたようにフィードバックターゲットとして機能することができる。ＲＴＣＰ受信器報告を転送する前に、ＭＳＡＳは同期ステータス情報を含むＲＴＣＰ拡張報告を読み込んで削除してもよい。したがって、ＭＳＡＳはＲＴＣＰ拡張報告を用いて同期設定指示を同期クライアントに送信してもよい。
【００８０】
コンテンツオンデマンドまたは他の単一キャストのストリームの同期の場合、ＭＳＡＳは１つ以上のＵＥに関連づけられたＲＴＣＰ受信器報告を適切なメディア機能ＭＦに転送してもよい。ＲＴＣＰ受信者報告を転送する前に、ＭＳＡＳはＲＴＣＰ ＸＲを読み込んで解析し、同期ステータス情報を含むそれらのＲＴＣＰ拡張報告を削除してもよい。したがって、ＭＳＡＳは、ＲＴＣＰ送信者報告を適切な同期クライアントに転送して、ＲＴＣＰ拡張報告を使用してＳＣに同期設定指示を追加してもよい。ＭＳＡＳは別のＲＴＣＰ ＸＲを用いて同期クライアントに同期設定指示を送信してもよい。
【００８１】
図６は、本発明の一実施形態によるＲＴＰメディアストリーム上の同期情報を報告する例示的なＲＴＣＰ拡張報告を示す。同期ＲＴＣＰ ＸＲにおける以下のフィールドが、本発明による同期スキームにおいて使用されてもよい。
−特定のＲＴＣＰパケットの送信者を識別するパケット送信者のＳＳＲＣ。
−ブロックフォーマットを識別する８ビットのブロックタイプ（ＢＴ）フィールド。
−この特定の拡張報告のためのパケット送信者の役割を識別する、４ビットの同期パケット送信者タイプ（ＳＰＳＴ）フィールド。
−パケット提示ＮＴＰタイムスタンプが値を有する場合には１に設定される、パケット提示ＮＴＰタイムスタンプフラグ（Ｐ）。このフラグが０に設定された場合は、パケット提示ＮＴＰタイムスタンプは検査されていないものとする。
−メディアペイロードのフォーマットを識別する、７ビットのペイロードタイプ（ＰＴ）フィールド。メディアペイロードは、ＲＴＰタイムスタンプカウンタにタイムベースを提供するＲＴＰタイムスタンプクロック速度に関連づけられてもよい。
−同期されたメディアストリームを相関させる際に用いるメディアストリーム相関識別子（３２ビット）。ＲＴＣＰパケット送信者がＳＣまたはＭＳＡＳ（ＳＰＳＴ＝１またはＳＰＳＴ＝２）である場合、メディアストリーム相関識別子はＳｙｎｃＧｒｏｕｐＩｄ上にマッピングされる。ＲＴＣＰパケット送信者がＳＣ’（ＳＰＳＴ＝３またはＳＰＳＴ＝４）である場合、入ってくるまたは出ていく関連のメディアストリームは同一のメディアストリーム相関識別子を有してもよい。
−メディア発信元のＳＳＲＣ（３２ビット）は、ＸＲが関連するＲＴＰパケットのＲＴＰヘッダにおいて搬送されるＳＳＲＣ識別子の値に設定されてもよい。
−パケット受信ＮＴＰタイムスタンプ（６４ビット）は、ＸＲが関連するＲＴＰパケットの最初のオクテットの到達時刻を表してもよい。
−パケット受信ＲＴＰタイムスタンプ（３２ビット）は、ＸＲが関連するＲＴＰパケットのＲＴＰヘッダにおいて搬送されるＲＴＰタイムスタンプの値に関連づけられる。
−パケット提示ＮＴＰタイムスタンプ（３２ビット）は、関連づけられたＲＴＰパケットの最初のオクテットを含むデータがユーザに提示された場合のＮＴＰタイムを反映する。これはＮＴＰの秒部分の最も重要でない１６ビットと、ＮＴＰの秒の小数点以下部分の最も重要な１６ビットを含む。このフィールドが空の場合は、このフィールドは０に設定されてもよく、パケット提示ＮＴＰタイムスタンプフラグ（Ｐ）は０に設定されてもよい。
表１は、同期パケット送信者タイプ（ＳＰＳＴ）フィールドに関連づけられ
た値を示す。
【００８２】
【表１】
【００８３】
図６を参照して記載されたように、特別にフォーマットされたＲＴＣＰ拡張報告を用いると、ネットワークまたは１つ以上のＵＥのクライアントとＭＳＡＳの間の同期情報は効率的に信号化されることができる。例えば図５に記載されたシステムにおいて、ＵＥに関連づけられた同期クライアントＳＣａ、ＳＣｂ ５０４、５０６およびメディアストリーム変更ユニットに関連づけられた同期クライアントＳＣ’５１０は、ＲＴＣＰ ＸＲを用いてＭＳＡＳに同期情報（すなわち、同期ステータス情報または同期相関情報）を報告することができる。表２はこの情報の例を提供する。
【００８４】
【表２】
メディアストリームはその同期発信元（ＳＳＲＣ識別子）によって識別されることができる。すなわち、ＳＳＲＣａ＝ＳＳＲＣ１であり、ＳＳＲＣｂ＝ＳＳＲＣ２である。このようにして、ＭＳＡＳは、ＳＣａが第１のメディアストリームを受信してＳＣｂが第２のメディアストリームを受信することを導き出すことができる。さらに、各メディアストリームは、Ｈｚ（すなわち、秒あたりのクロック刻み数）で表すことができる特定のクロック速度に関連してもよい。すなわち、ＣＲａ＝ＣＲ１であり、ＣＲｂ＝ＣＲ２である。典型的なクロック速度は、音声に関しては毎秒８０００〜９６０００サンプルの範囲にあり、映像に関しては毎秒９０．０００サンプルである。
【００８５】
一実施形態では、クロック速度はＭＳＡＳに信号化されてもよい。別の実施形態では、速度は一定であってもよい。さらに別の実施形態では、クロック速度の代わりにペイロードタイプがＭＳＡＳに信号化されてもよい。ペイロードタイプは、例えばＩＥＴＦ ＲＦＣ ３５５１に記載されたスキームを用いて、クロック速度をマッピングしてもよい。ＭＳＡＳに報告された情報は、ＲＴＰタイムスタンプとＮＴＰタイムスタンプの両方をさらに含んでもよい。
【００８６】
ＳＣ’は、各メディアストリームにつき１つの、２組のタイムスタンプ（ＲＴＰ１、ＮＴＰ１）および（ＲＴＰ２、ＮＴＰ２）をＭＳＡＳに報告する。ＮＴＰ１はＲＴＰ１によって識別されたオクテットがＳＣ’において特定のポイントを通過した時間を表し、ＮＴＰ２はＲＴＰ２によって識別されたオクテットがＳＣ’において特定のポイントを通過した時間を表す。トランスコードおよびクロック速度が変化するため、これらは一般的に異なるオクテットである。識別されたオクテットによって表されるコンテンツ内のポイントが特定のポイントをいつ通過したのかを決定するために、ＳＣ’は計算を行ってＮＴＰ１およびＮＴＰ２を決定しなければならない。
【００８７】
ＭＳＡＳは、プレイアウトＳＣａ−プレイアウトＳＣｂ＝（ＮＴＰａ−（ＲＴＰａ／ＣＲａ）−（ＮＴＰｂ−（ＲＴＰｂ／ＣＲｂ）−（ＮＴＰ１−（ＲＴＰ１／ＣＲ１）＋（ＮＲＰ２−（ＲＴＰ２／ＣＲ２）というアルゴリズムを使用することで、ミリ秒単位でのＳＣａのプレイアウトとＳＣｂのプレイアウトの差を決定してもよい。それらのプレイアウトを十分に同期させるために、その結果を用いて、ＳＣａまたはＳＣｂに特定の量だけそのプレイアウトを遅延させることを指示してもよい。
【００８８】
表３の例にあるパラメータを用いると、−５．４９３秒の遅延（プレイアウトＳＣａ−プレイアウトＳＣｂ）という結果になり、このことは、ＳＣｂがＳＣａよりも５．４９３秒遅くプレイアウトしたことを示す。したがって、実質的に同期させるために、この計算に基づいて、ＭＳＡＳはＳＣａにその出力を５．４９３秒遅らせるよう指示してもよい。
【００８９】
【表３】
図７は、本発明の他の実施形態による、メディアストリームを同期させるためのＲＴＣＰ ＸＲメッセージの使用を示す。この例では、ある単一のコード化装置７０２が複数のメディアストリーム変更ユニットを含んでもよい。コード化装置は複数の入ってくるメディアストリーム７０８、７１０および出ていくメディアストリーム７１２−７１６に関連づけられてもよく、出ていくメディアストリーム７１２−７１６は、単一の同期クライアントＳＣ’７０４によって同期化されてもよい。
【００９０】
入ってくる各メディアストリームＡ１、Ｂ４に関して、および出ていく各メディアストリームＡ２、Ａ３、Ｂ５、．．．に関して、同期クライアントＳＣ’はＲＴＣＰ ＸＲ７１８−７２４をＭＳＡＳ７０６に送信してもよい。したがって、この実施形態では、同期相関情報は２つのＲＴＣＰ ＸＲにおいてＭＳＡＳに送信される。それらは、入ってくるメディアストリーム７０８、７１０に関連づけられた第１のＲＴＣＰ ＸＲ ７２４、７２６および、出ていくメディアストリーム７１２−７１６に関連づけられた第２のＲＴＣＰ ＸＲ ７１８−７２２である。
【００９１】
そのような信号化スキームは、ＲＴＣＰ ＸＲが異なる時刻に、および異なる速度でＭＳＡＳに独立して送信されるという利点を有する。あるメディアストリームがより安定した時間参照を有する場合は、その同期相関情報はより不定期に更新されてもよくなり、したがって処理時間および帯域が節約される。さらに、入ってくるあるメディアストリームが複数の異なる出ていくメディアストリームにトランスコードする場合、入ってくるメディアストリームに関した同期相関情報の部分が測定され、１度だけ送信されるべきであり、それによって時間および帯域が節約される。
【００９２】
しかしながら、同期相関情報の異なる部分（ＲＴＣＰ ＸＲ）を独立して送信することは、同期相関情報のどの部分が関連する部分であるかをＭＳＡＳが知っていないため、問題となることがある。この場合には、ＭＳＡＳが、同期相関情報のどの部分がひとまとまりになっているかを決定することが不可能である。
【００９３】
この理由により、ＭＳＡＳがトランスコード装置の入力および出力における異なるメディアストリームを相関させることと、正しい同期相関情報をＭＳＡＳによって受信された異なるＲＴＣＰ ＸＲから導き出すことと、を可能にするために、同期クライアントＳＣ’はメディアストリーム相関識別子（ＭＳＣＩ）を生成する。例えば、図７において、ＭＳＡＳはＭＳＣＩＡを用いて、メディアストリーム７１０に関連づけられたＲＴＣＰ ＸＲ７２６を、（変更された）メディアストリーム７１２に関連づけられた第１のＲＴＣＰ ＸＲ７１８および（変更された）メディアストリーム７１４に関連づけられた第２のＲＴＣＰ ＸＲ７２０と相関させることができる。このようにして、複数の変更されたメディアストリームの効率的な同期が達成されてもよい。互いに関連する異なるストリームの間の同期は、同時に同じブロードキャストを視聴することを望みながら異なる性能の異なるプレイアウト装置を用いる異なるユーザにとって有利でありうるだけでなく、互いに関連する異なるストリームを搬送する２つ以上ネットワークを切り換える単独のユーザにとっても有益でありうることに留意すべきである。この切り換えは、例えば、ユーザがカバレッジの悪いモバイルネットワークを用いる場合に発生しうる。ユーザがネットワークへの接続から離れた場合、ユーザは別のネットワーク、例えば、カバレッジが改良された別のモバイルネットワークに切り換えることを望むかもしれない。そのようなネットワーク切り換えの例に、ＤＶＢ−Ｈ（デジタルビデオブロードキャスト−ハンドヘルド）ネットワークとＵＴＭＳネットワークの間の切り換えがありうる。モバイルネットワークと固定ネットワークの間の切り換えもまた行われるかもしれない。例えば、モバイルネットワーク経由でビデオストリームを見ているユーザが、帰宅して固定ネットワークに接続された自分の大スクリーンテレビジョンで視聴を続けることを望む場合である。互いに関連する異なるストリームの間の遅延を打ち消すことは、シームレスなネットワーク移行および向上したユーザエクスペリエンスを提供する。
【００９４】
任意のある実施形態に関連して記載されたいかなる特徴も、単独で用いられてもよく、または記載された他の特徴と組み合わされて用いられてもよく、任意の他の実施形態の１つ以上の特徴と組み合わされて用いられてもよく、任意の他の実施形態の組み合わせと組み合わされて用いられてもよい。さらに、上記されなかった同等の例および変形例もまた、本発明の範囲から逸脱せずに用いられることができ、それらは添付の特許請求の範囲において定義される。
【００９５】
例えば、本発明による同期方法は、例えばネットワーク全体またはその一部上で作動する、または、ネットワークを介して流れるすべてのストリーム上で作動する、またはあるストリーム上のみで作動する連続プロセスとして実施されることができる。さらに、連続動作はすべての同期ポイントに作用してもよく、特定の同期ポイントのみに作用してもよい。方法は、この連続方式において動作するようにシステムを構成することによって実施されてもよい。
【００９６】
代替として、方法は、例えばクライアントサーバ型のモデルを用いるセッション型の同期プロセスとして実施されてもよい。同期セッションは、例えばネットワーク内のあるトリガを介して開始または終了してもよい。同期セッションを開始または終了するトリガは、例えば同期ポイントによって提供されてもよく、ネットワークまたはシステム内の他の要素によって提供されてもよい。
【００９７】
一実施形態では、同期サーバおよび同期クライアントは同期セッションを開始および終了するように構成されてもよい。同期セッションは、同期クライアントが招待メッセージを同期サーバに送信したときに開始されてもよく、逆も同様である。同期セッションの最中に、同期サーバおよび同期クライアントは同期ステータス情報および同期設定指示を交換してもよい。同期セッションは、同期クライアントが同期サーバに終了メッセージを送信したときに終了してもよく、逆も同様である。同期サーバおよび同期クライアントは、招待を受け入れるために、または同期セッションの終了を確認するために、返答メッセージを送信してもよい。
【技術分野】
【０００１】
本発明は、関連するストリームの送信先間同期の方法およびシステムに関する。本発明はさらに、そのようなシステムにおいて使用する同期ユニット、同期点、到達時刻情報調整モジュールおよびデータ構造、およびそのような方法を使用するコンピュータプログラム製品に関する。
【背景技術】
【０００２】
ボイスオーバーＩＰ（ＶｏＩＰ）およびインターネットプロトコルテレビジョン（ＩＰＴＶ）などの新しいマルチメディア技術が、あらゆる範囲で新しいマルチメディアサービスを生み出す。これらのサービスの１つのタイプは、ユーザのグループが、同じテレビチャンネルを別々に見て、テキスト、音声、および／またはビデオを用いて互いに通信することを可能にする。これらのサービスの他のタイプは、対話型テレビジョン経験を提供する。例えば、テレビジョンのクイズ放送で、放送された問題に視聴者が家庭で答えを入力し、番組に参加することなどである。そのようなサービスは、端末の出力信号がグループ内のすべてのユーザに同時に送信されることを必要とする。言い換えれば、グループにおけるディスプレイまたはプレイアウト装置、例えばテレビジョン、ＰＤＡ、モバイル装置、ＰＣまたはそれらの組み合わせの、異なる送信先に対応する出力は、同期すべきであるということである。
【０００３】
ＩＰＴＶシステムにおいては、ＴＶチャンネル信号は典型的には、ヘッドエンド、エッジルータなどのネットワークノードおよびそのようなサービスの加入者の端末へのアクセスノードを介したオペレータの高帯域幅ＩＰネットワーク上を１つ以上のパケット化されたストリームとして送信される。そのようなストリームの送信の間、パケットは、送信の遅延、ネットワークルートの相違、およびコード化ならびにコード解除の遅延の相違などの、ネットワークにおける未知の遅延を被る。結果として、第１の端末（第１の送信先）で受信された音声および映像ストリームのパケットと、別の第２の端末（第２の送信先）で受信されたそれらとの間の時間的な関係が乱されるであろう。
【０００４】
ＩＰＴＶコンテンツを端末にストリーミングするためには、通常はリアルタイムトランスポートプロトコル（ＲＴＰ）が用いられる。ＲＴＰはシーケンスの番号付けおよびタイムスタンプ作成を提供する。ＲＴＰを用いることで、同じ最終端末で終端する関連ストリームの間（ストリーム間同期）の、または、異なる最終端末で終端する関連ストリームの間（グループ同期または送信先間同期）の、１つのストリーム内の時間的な関係（ストリーム内同期）が回復する。Ｆ．Ｂｏｒｏｎａｔらによる論文「マルチメディアグループおよびストリーム間同期技術：比較研究（Ｍｕｌｔｉｍｅｄｉａ ｇｒｏｕｐ ａｎｄ ｉｎｔｅｒ−ｓｔｒｅａｍ ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ ｔｅｃｈｎｉｑｕｅｓ：Ａ ｃｏｍｐａｒａｔｉｖｅ ｓｔｕｄｙ）」（Ｅｌｓｅｖｉｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍｓ ３４（２００９）１０８〜１３１ページ）は、知られている送信先間同期技術の総合的な概観を提供し、それは３つの主要なカテゴリに分けることができる。
【０００５】
「同期マエストロスキーム（Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ Ｍａｅｓｔｒｏ Ｓｃｈｅｍｅ）」（ＳＭＳ）においては、中央の同期マスターがグループ内のすべての端末からタイミング情報を集め、制御パケットを端末に配信することによって出力タイミングを調整する。「マスター−スレーブ受信器スキーム（Ｍａｓｔｅｒ−Ｓｌａｖｅ Ｒｅｃｅｉｖｅｒ Ｓｃｈｅｍｅ）」（ＭＳＲＳ）においては、受信器（端末）はマスター受信器とスレーブ受信器に分類される。マスター受信器はその出力タイミングをスレーブ受信器にマルチキャストし、スレーブ受信器はそれに従ってスレーブ受信器のパケットの出力タイミングを調整する。「配信制御スキーム（Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｎｔｒｏｌ Ｓｃｈｅｍｅ」（ＤＣＳ）においては、各端末（受信器）はグループ内のすべての他の端末にすべてのタイミング情報をマルチキャストし、端末は正確な出力タイミングを計算するように構成される。これらのスキームは、メディアストリームの発信元または受信器端末のいずれかで同期が発生するという点で共通する。
【０００６】
同時に係属する欧州特許出願には、発信元と受信器の間のストリームの通路に沿ったどこかでネットワークノードが同期化される、さらなる送信先間同期スキームが記載される。この方法は特に、オペレータネットワークにストリーム送信先を接続するアクセス回線における相違に由来するストリーム伝播時間の小さな相違を許容する、大規模な配置およびサービスに適している。
【０００７】
参考の送信先間同期技術の大部分は、端末におけるメディアストリーム受信におけるタイミング情報（例えば、ＲＴＰタイムスタンプ、特定のある時刻において受信されたＲＴＰメディアストリームのＲＴＰシーケンスナンバ、トランスポートストリームにおける１つ以上の等価パラメータ）を利用する。異なる受信器のタイミング情報を比較することによって、適切なストリーム調整が計算されることができる。調整の例は、受信器側においてバッファを用いることによる、受信されたストリームのプレイアウト時刻の遅延であってもよい。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
これらの知られている同期スキームに関連する１つの問題は、これらのスキームが、発信元と受信器の間のストリームがコンテンツ準備および／またはコンテンツ再生成の目的によって変更される状況を処理するようには設計されていないことである。
【０００９】
ストリームの変更は、多くの状況において必要でありうる、および／または有利でありうる。例えば、効率的な配信のためにメディアストリームを準備するために、メディアストリームはストリーム受信器またはアクセス線の、解像度の変更（例えば、ＨＤからＳＤへの変更またはより低いビットレートへの変更）などの特定の要請に適応してもよい。そのような状況において、トランスレータまたはトランスコーダと呼ばれるストリーム変更ユニットがストリームの通路に配置されてもよい。変更されたトランスコーダ出力ストリームは、オリジナルの（変更されていない）入力ストリームと比較して異なるタイムスタンプ、シーケンスナンバ、または他のタイミング情報を有してもよい。
【００１０】
メディアストリームは特定の顧客の要求のためにカスタマイズされてもよい。画面外のボイス、サブタイトル、ピクチャインピクチャをメインコンテンツストリームに加える必要があってもよい。これは典型的には、ミクサと呼ばれるストリーム変更ユニットによって行われる。さらに、ネットワークドメインがクロスする場合は、ストリームは、再生器（ｒｅ−ｇｅｎｅｒａｔｏｒ）ユニットを用いて再生されてもよい。すべてのこれらのコンテンツ準備および再生スキームは、ストリームにおけるタイミング情報を変化させ、それによって知られている送信先間同期スキームを、信頼できないものに、または使用不可能なものにさえする。したがって、従来技術においては、変更されたストリームと変更されていないストリームの間の、または２つの異なって変更されたストリームの間の、送信先間同期を可能にする方法およびシステムが必要となる。
【課題を解決するための手段】
【００１１】
従来技術において知られている同期スキームの欠点の少なくとも１つを低減するか取り除くこと、および、入力ストリームとして第１のストリームを使用するメディアストリーム変更ユニットの出力ストリームが第２のストリームであるかもしれない、少なくとも前記第１のおよび前記第２のストリームの送信先間同期の方法を提供することが本発明の目的である。方法は以下のステップを含んでもよい。第１の同期ポイントに到達する第１のストリームにおけるパケットの第１の到達時刻情報と、第２の同期ポイントに到達する第２のストリームにおけるパケットの第２の到達時刻情報と、を提供すること。前記入力ストリームおよび前記出力ストリームの間の同期関係に関する同期相関情報を提供すること。および、前記第１のおよび前記第２の到達時刻情報および前記同期相関情報に基づいて、遅延情報を計算すること。さらなる実施形態において、方法はさらに、少なくとも前記第１のまたは前記第２の同期ポイントに前記遅延情報を提供し、前記第１のおよび前記第２の同期ポイントによってそれぞれ出力される前記第１のおよび前記第２のストリームが実質的に同期するように、少なくとも前記第１のおよび前記第２の同期ポイントがストリームの出力を遅延させることを可能にする、ステップを含んでもよい。
【００１２】
同期相関情報を提供することによって、異なる機種環境の視聴者の集合、異なる端末を用いる視聴者の集合、および／または異なるサービス要求を有する視聴者の集合に向けられた関連するストリームが、なおも同期することができる。本発明はしたがって、異なる機種環境のネットワークにおける視聴者のグループが、同期された方式でメディアストリームを見ることを可能にする。
【００１３】
この文脈において、到達時刻とは通常、同期ポイントがメディアストリームのある部分を受信する時刻である。本発明の文脈において、当業者には、パケットが完全に到達する時間がここで用いられる必要がないことが理解される。到達時刻情報として用いられる現実の時刻はわずかに変化し、それは同期ポイントが到達時刻を決定するために用いる正確なポイントに依存する。この時刻は、例えばジッタバッファにパケットを配置する前の、到達時を直接用いてもよい。しかしながら、メディアパケットを取り扱う過程における遅れたポイント内にあってもよく、例えばコード解除過程の直前またはトランスレーション過程の直前などにあってもよい。メディアコンテンツのそのある特定の部分の現実の提示の前に、同期ポイントは、メディアパケットを処理するために必要な時間を知っていてもよく、到達時刻情報として現実の提示時間を使用してもよい。
【００１４】
一実施形態では、前記第１のおよび第２のストリームは少なくとも第１のおよび第２の同期ポイントによって出力され、前記同期ポイントは前記同期ポイントを同期させるために少なくとも１つの同期ユニットに接続される。
【００１５】
他の実施形態では、遅延情報を計算する前記ステップは、第１の到達時刻情報と第２の到達時刻情報の間の共通のタイムラインを達成するように、第１のおよび／または第２の到達時刻情報を調整する調整ステップを有してもよい。前記調整ステップは、同期相関情報の少なくとも一部に基づいてもよい。
【００１６】
一実施形態では、前記調整ステップは到達時刻情報調整モジュールによって実行され、前記モジュールは同期ユニットの一部であり、前記同期ユニットは同期相関情報を提供される。
【００１７】
他の実施形態では、前記調整ステップは同期ポイントにおいて実行されてもよく、前記同期ポイントは到達時刻情報調整モジュールを有してもよい。そのような到達時刻情報調整モジュールは同期相関情報の少なくとも一部を提供されてもよく、同期ユニットは調整された第２の到達時刻情報を提供される。
【００１８】
さらに他の実施形態では、調整ステップはネットワーク要素において実施されてもよく、前記ネットワーク要素は到達時刻情報を受信するように構成されてもよい。ネットワーク要素は到達時刻情報調整モジュールをさらに有してもよく、到達時刻情報調整モジュールは、同期相関情報の少なくとも一部を提供され、同期ユニットは調整された第２の到達時刻情報を提供される。
【００１９】
一実施形態では、前記同期ポイントは端末またはネットワークノードであってもよく、好ましくはアクセスノードであってもよい。さらなる変形例では、ストリーム変更ユニットはトランスレータまたはミクサであってもよく、同期ユニットは同期ポイントまたはサーバ内に含まれてもよい。
【００２０】
さらなる形態では、本発明は同期ユニットに関連してもよく、好ましくは、少なくとも、第１のメディアストリームを受信する第１の同期ポイントおよび第２のメディアストリームを受信する第２の同期ポイントの出力を同期させる同期サーバに関連してもよい。前記第２のストリームは、入力ストリームとして第１のストリームを用いるメディアストリーム変更ユニットの出力ストリームであってもよい。同期ユニットは、第１の同期ポイントに到達するストリームにおけるパケットの第１の到達時刻情報および、第２の同期ポイントに到達する第２のストリームにおけるパケットの第２の到達時刻情報を受信する手段、前記入力ストリームと前記出力ストリームの間の同期関係に関する同期相関情報を提供する手段、および、前記第１のおよび前記第２の到達時刻情報および前記同期相関情報に基づいて遅延情報を計算する手段を有してもよい。
【００２１】
他の実施形態では、同期ユニットは、受信されたストリームが実質的に同期するように、前記第１のおよび前記第２の同期ポイントにおける１つ以上の可変遅延ユニットが受信されたストリームの出力時間を遅延させることを可能にする遅延情報を、前記第１のおよび前記第２の同期ポイントに提供する手段を有してもよい。
【００２２】
さらなる形態では、本発明は少なくとも第１のおよび第２の同期ポイントの出力の送信先間同期システムに関してもよい。システムは、メディアストリームを配信するコンテンツ配信サーバ、入力メディアストリームを変更して、変更された出力メディアストリームにするように構成され、前記入力ストリームと前記出力ストリームの間の同期関係に関する同期相関情報を提供するように構成されたストリーム変更ユニット、および、上記の少なくとも１つの同期ユニットを含んでもよい。
【００２３】
さらなる形態では、本発明は上記システムにおいて使用する同期ポイントおよびメディアストリーム変更ユニットに関してもよい。さらに別の形態では、本発明は上記システムにおいて使用するデータ構造、好ましくはＲＴＣＰ拡張報告データ構造に関してもよい。前記データ構造は、メディア同期ポイントに到達するストリームにおけるパケット、またはメディアストリーム変更ユニットに到達するストリームにおけるパケット、または前記変更ユニットによって送信されるストリームにおけるパケットに関連づけられた同期ステータス情報を信号化する前記システムによって使用される。また、前記データ構造は、前記データ構造の発信元を識別する識別子、少なくとも１つのタイムスタンプ、好ましくはＲＴＰおよび／またはＮＴＰタイムスタンプ、および／またはメディアストリーム相関識別子を少なくとも含み、前記データ構造は、前記同期ユニットが、前記システムにおけるメディア同期ポイントに関連するメディアストリームを同期させることを可能にする。
【００２４】
本発明はまた、コンピュータのメモリにおいて実行されるとき、上記の方法ステップにおいて記載されたような方法ステップを実行するように構成されたソフトウェアコード部分を含む、コンピュータプログラム製品にも関してよい。
【００２５】
本発明はさらに、本発明による実施形態を概略的に示す添付の図面を参照して記載される。本発明はこれらの特定の実施形態にいかなる意味でも制約されるものではないことが理解されるであろう。
【図面の簡単な説明】
【００２６】
【図１】複数のストリーム変更ユニットを含み、関連するストリームを異なる位置に配信することが可能な、異なる機種環境のネットワークトポロジの例示的な実施形態を示す図である。
【図２】本発明の一実施形態によるシステムを示す図である。
【図３】本発明によるシステムに関連するフロー図である。
【図４】本発明の他の実施形態によるシステムを示す図である。
【図５】本発明の一実施形態による送信先間同期スキームの実施例を示す図である。
【図６】本発明の一実施形態による例示的なＲＴＣＰ拡張報告（ＲＴＣＰ ｅＸｔｅｎｄｅｄ Ｒｅｐｏｒｔ）を示す図である。
【図７】本発明の他の実施形態によるメディアストリームを同期させるＲＴＣＰメッセージの使用を示す図である。
【発明を実施するための形態】
【００２７】
図１は、ネットワーク全体のユーザ装置にコンテンツを配信するためのマルチメディア配信システム１００の例示的な実施形態を示す。ネットワークは異なる機種環境のトポロジを有し、複数のストリーム変更モジュールを含み、関連するストリームを異なる位置に配信することが可能である。この実施形態では、パケットを含むメディアストリームは複数のユーザ装置に配信され、メディアストリームは異なるユーザ装置に応じて異なる構成をとる。
【００２８】
本出願の文脈におけるパケットは、タイミング情報、例えばタイムスタンプに関連づけられたメディアストリームの１つ（すなわち１単位）である。そのようなパケットの一例は１つ以上のタイムスタンプを有するＲＴＰパケットである。他の例は、１つ以上の表示タイムスタンプを含むトランスポートストリーム（ＴＳ）パケットなどのＭＰＥＧタイプパケットである。
【００２９】
タイミング情報を含む任意のメディアパケットフォーマットが同期目的のために用いられてもよいことを、当業者は理解する。タイミング情報はトランスポートコンテナ（トランスポートプロトコル）の部分であってもよく、それは標準的なものか専有のものかのいずれかの、コンテンツの搬送のために用いられる。代わりに、または加えて、それは実在のコンテンツの部分であってもよく、例えばコンテンツをコード化するためのコード化スキームにおいて用いられるタイミング情報であってもよい。
【００３０】
図１におけるマルチメディア配信システムはメディアストリーム生成器１０１を含む。それは例えば、１つ以上のネットワーク、例えばＩＰネットワークを介して、メディアストリームを異なるユーザ機器（ＵＥ）１０６−１０９に配信することが可能なサーバを含む。ＵＥまたは端末はプレイアウト装置またはそれに接続された装置（例えばセットトップボックス）に関連してもよい。そのような装置には、例えば携帯電話、テレビジョンセット、ＩＰ電話、ゲーム操作盤、スマート計量装置などが挙げられてもよいが、該計量は、同期化されたストリームに応じた他の自動化された動作、例えば同期化された信号に応じた複数の計量装置の自動化された計量などであってもよい。
【００３１】
マルチメディア配信システムは様々なネットワーク要素を有してよく、該要素はメディアストリームにおけるタイミング情報が変更されるように、該メディアストリーム上である動作を実行する。そのようなネットワークエレメントは、以降では概してストリーム変更ユニットと呼ばれる。図１の実施形態では、システムは様々なストリーム変更ユニット、例えば第１のトランスコーダ１０２、第２のトランスコーダ１０３、およびミクサ１０４などを含む。サーバ１０５は代替のおよび／または追加の基本ストリーム１０５をミクサに配信してもよい。このサーバ１０５は、例えば代替の音声（異なる言語、監督のコメントまたはサラウンド音響）、代替のサブタイトル、または代替の映像（例えば、話し言葉を書き言葉に翻訳するサイナー（ｓｉｇｎｅｒ））を配信してもよい。
【００３２】
メディアサーバ１０１によって配信されるオリジナルのメディアストリーム１１０は、ＩＰ上のＵＤＰ上のＲＴＰを用いてネットワーク中に搬送されるＭＰＥＧ４コード化を伴うビデオオンデマンド（ＶｏＤ）ストリームであってもよい。このオリジナルのメディアストリーム１１０は、ＭＰＥＧ２コード化のみをサポートするＵＥ２ １０７の利益のためにＭＰＥＧ２コード化されたストリーム内に、オリジナルのＭＰＥＧ４コード化されたストリームをトランスコードする第１のトランスコーダ１０２によって、変更（すなわち、トランスコード）される。トランスコードされたメディアストリーム１１２は、ＩＰ上のＵＤＰ上のＲＴＰを用いてＵＥ２にさらに搬送される。
【００３３】
第２のトランスコーダ１０３はオリジナルのメディアストリーム１１０をトランスコードして、現実のコード化スキームが変化しないオリジナルのメディアストリームによって用いられるコンテナフォーマットとは異なるコンテナフォーマットを有する、変更されたメディアストリームにしてもよい。第２のトランスコーダ１０３は、ＵＤＰ上で直接搬送されるＭＰＥＧトランスポートストリームを用いるＵＥ３ １０８にネットワーク中でＭＰＥＧ４にコード化されるメディアストリームを、例えば配信してもよい。さらに、ミクサ１０４は１つ以上の追加の基本ストリームをオリジナルのメディアストリームに追加してもよく、オリジナルのメディアストリーム内の１つ以上の基本メディアストリームを１つ以上の代替の基本ストリームに置き換えてもよい。これらの追加の、または代替の基本ストリームはＩＰ上のＵＤＰ上のＲＴＰを用いてサーバ１０５によって配信される。したがって、ミクサ１０４は、ミックスされたメディアストリーム１１４を、ＩＰ上のＵＤＰ上のＲＴＰ上のＭＰＥＧを用いて、ＵＥ４に配信する。
【００３４】
図１に記載のマルチメディア配信システムにおいて、オリジナルのメディアストリーム１１０は、タイミング情報を含むトランスポートプロトコルを使用してもよい。一実施形態では、ＲＴＰプロトコルはトランスポート機構として用いられてもよい。ＲＴＰは、メディアストリームを同期化するタイミング情報として用いられてもよいＲＴＰタイムスタンプを用いる。
【００３５】
第１のトランスコーダ１０２はオリジナルのストリーム１１０をコード解除して、メディアを再コード化（例えばＭＰＥＧ４からＭＰＥＧ２に）してもよい。したがって、それは、ＵＥ２ １０７への送信の開始を示すランダムＲＴＰタイムスタンプを用いて変更されたメディアストリームを送信するであろう。したがって、同じトランスポートプロトコル（ＩＰ上のＵＤＰ上のＲＴＰ）が用いられていても、出ていくメディアストリームのタイムスタンプは入ってくるメディアストリームのタイムスタンプとは異なる。
【００３６】
第２のトランスコーダ１０３はオリジナルのストリーム１１０をコード解除せず、異なるトランスポートコンテナを用いるＵＥ３ １０８にメディアストリーム１１３を送信する。例えば、ＵＤＰ上のＭＰＥＧトランスポートストリーム（ＴＳ）はコンテンツをＵＥ３に送信するように用いられる。これらのＭＰＥＧ ＴＳパケットは、パケットが表示のために示されるべき瞬間を表示するための、いわゆるプレゼンテーションタイムスタンプ（ＰＴＳ）の形態でタイミング情報を含んでもよい。たとえ、入ってくるメディアストリームと出ていくメディアストリームの間の現実のコード化が変化しないままであったとしても、これらのＰＴＳはオリジナルのメディアストリーム１１０のＲＴＰタイムスタンプとは異なる。
【００３７】
ミクサ１０４は、メディアストリーム１１１における１つ以上の基本ストリームをオリジナルのメディアストリーム１１０とミックスすることができる。その後、ミクサ１０４はミックスされたメディアストリーム１１４をネットワークを介してＵＥ４ １０９に送信してもよい。ミクサが新しいメディアストリームを生成するとき、ミクサはこのストリームをＵＥ４に送信する開始時刻として、無作為に生成された新しいＲＴＰタイムスタンプを使用し、入力ストリーム１１０に用いられるコード化およびトランスポートスキームが、ミックスされた出力ストリーム１１４に用いられるコード化およびトランスポートスキームと同じである。
【００３８】
さらにいかなる測定もない場合は、ＵＥにおけるプレイアウトの同期は不可能である。というのは、ネットワークにおけるコンテンツ変更ユニットはストリームにおけるタイミング情報を変化させ、発信元とＵＥのタイムスタンプを互いに一致させなくするためである。この理由は、メディアサーバ１０１、トランスコーダ１０２および１０３、およびミクサ１０４がそれぞれ開始時刻として無作為なタイムスタンプを選ぶためである。この同じ問題がミクサに存在する。ミクサは、オリジナルのメディアサーバ１０１と、他の発信元、すなわち追加のおよび代替の基本ストリーム１０５を有するメディアサーバの両方から、メディアストリームを受信する。上記の説明のとおり、これらのメディアストリームにおけるタイムスタンプは相関づけされない。
【００３９】
図２は、メディアストリームを同期させるための、第１の同期ポイント２０５および第２の同期ポイント２０８を有するマルチメディア配信システム２００の概略図を示す。同期ポイントとは、同期情報（例えば到達時刻情報）が決定されるストリームの通路における（論理的または物理的な）ポイントである。同期ポイントはネットワークに接続されるかネットワーク内に組み込まれた任意の物理的装置に含まれてもよい。同期ポイントは、例えばネットワークノード、例えばアクセスノード（例えばデジタル加入者線アクセスマルチプレクサ（ＤＳＬＡＭ）、ケーブルモデム終端システム（ＣＭＴＳ））、光アクセスノードまたはエッジルータまたはヘッドエンドなどに関連してもよい。代替として、同期ポイントがテレビジョン、パーソナルコンピュータ、ラップトップ、ネットブック、パーソナルデジタルアシスタント、またはメディアストリームを取り扱うことが可能な任意の他の装置に接続されたセットトップボックスとして形成されてもよい。
【００４０】
マルチメディア配信システムは、メディアストリーム発信源２０１、例えばビデオオンデマンドストリームまたはライブマルチキャストテレビジョン放送を配信する、例えばメディアサーバを含んでもよい。このメディア発信源２０１はオリジナルの第１のメディアストリーム２１２をネットワーク２１１を介して同期ポイントに送信してもよい。第１の同期ポイント２０５は、いかなる変更もないオリジナルのメディアストリーム２１２を受信してもよい。しかしながら、第２の同期ポイント２０８は、同じコンテンツであるが例えば異なるフォーマットであるコンテンツを有するストリームを受信してもよい。したがって、第２の同期ポイント２０８は、メディアストリーム変更ユニット２０２によって生成された、変更された第２のメディアストリーム２１３を受信する。メディアストリーム変更ユニット２０２は、オリジナルのメディアストリーム２１２を受信し、変更されたメディアストリーム２１３を生成する。
【００４１】
第１のおよび第２のストリーム同期ポイント２０５、２０８は、それぞれ第１のおよび第２のメディアストリーム２１２、２１３の間の送信先間同期（またはグループ同期）を提供するように構成されてもよい。この目的のために、メディアストリーム同期ポイントはメディア同期ユニット２０４、例えばメディア同期アプリケーションサーバ（ＭＳＡＳ）に接続される。第１のおよび第２のストリーム同期ポイント２０５、２０８は第１のおよび第２の同期クライアント２０７、２１０と、例えば変化可能な遅延バッファ２０６、２０９を含む第１のおよび第２の変化可能な遅延ユニットとを、それぞれ含んでよい。第１のおよび第２の同期クライアント２０７、２１０は、以下により詳細に説明されるように、ＭＳＡＳ２０４と同期情報を交換するように構成される。
【００４２】
メディアストリーム変更ユニット２０２は、メディアストリーム変更ユニットと関連づけられた第３の同期クライアントＳＣ’２０３をさらに含んでもよい。同期クライアント２０７、２１０、２０３は、例えば信号化経路２１４を用いてＭＳＡＳ２０４とメッセージを交換する。これらの信号化メッセージは、メディア配信において用いられる同じネットワーク２１１上で搬送されてもよい。代替として、メッセージは同様に他のネットワーク上で搬送されてもよい。以下の説明において、信号化経路２１４は同期参照ポイントとみなされる。
【００４３】
この例において、オリジナルのメディアストリーム２１２は、例えば、ＵＤＰプロトコルを用いてＩＰネットワーク上でＲＴＰにおいて搬送されるビデオストリームに関連することができる。その場合には、オリジナルのメディアストリーム２１２におけるＲＴＰパケットはメディアストリーム発信元２０１によって生成されるＲＴＰタイムスタンプおよびＲＴＰプロトコルにおいて定義された同期発信元（ＳＳＲＣ）識別子を含むことができる。
【００４４】
変更されたストリーム２１３は、オリジナルのメディアストリーム２１２と同じコンテンツであるがメディアストリーム変更ユニット２０２によって変更されているコンテンツを有してもよい。変更は、図１を参照にした上記のような変更動作であってもよく、例えば、オリジナルのストリームが高帯域幅高解像度（ＨＤ）ストリームであってもよく、変更されたストリームが低帯域幅標準解像度（ＳＤ）であってもよい。他の変更は、例えば、ネットワーク内の１つ以上のストリーム同期ポイントによってサポートされるデジタル権利管理（ＤＲＭ）システムに関連する暗号化スキームの適用であってもよい。この変更は再発信（ｒｅ−ｏｒｉｇｉｎａｔｉｏｎ）に関してもよい。再発信は、メディアストリームがネットワークの境界を超えた場合、例えば、ＩＰＴＶプロバイダが１つ以上のプライベートＩＰＴＶネットワークと同様にインターネット上で有効なメディアストリームを提供することを欲した場合に提供される。他の変更は、ミックスに基づく変更を含んでもよい。それは例えば、ビデオストリームにおいて手話を実行する人を含めること、あるいは、異なるメディアコンテナにおいてストリームを再送信すること、例えば、ＲＴＰを用いるかわりにＭＰＥＧトランスポートストリーム（ＴＳ）を用いることである。
【００４５】
変更されたメディアストリーム２１３におけるＲＴＰパケットは、オリジナルのメディアストリーム２１２におけるそれらと比較して異なるＳＳＲＣ識別子と異なるＲＴＰタイムスタンプを有してもよい。ＩＥＴＦ ＲＴＣ ３５５０によれば、ＳＳＲＣ識別子とＲＴＰタイムスタンプはＲＴＰパケットにおいて３２ビットヘッダフィールドである。各メディアストリームにおいて、ＲＴＰタイムスタンプの開始時間は無作為に選択されるべきである。さらに、ＳＳＲＣは無作為に選ばれた値であり、それはグローバルに一意的であることを意味している。知られている送信先間同期スキームにおいて、同期は各ストリーム同期ポイントへの信号化タイムスタンプ情報によって達成されることができる。しかしながら、第１のおよび第２のストリーム２１２、２１３におけるＲＴＰタイムスタンプは異なるため、第１のおよび第２の同期ポイントにおけるメディアストリームの直接の同期は可能ではない。
【００４６】
マルチメディア配信システムにおいて、第１のおよび第２のストリーム同期ポイント２０５、２０８は、いわゆる同期ステータス情報をＭＳＡＳ２０４に送信することができる。この同期ステータス情報は、メディアストリームに関連する識別情報（例えばＳＳＲＣ識別子）、およびタイミング情報（例えば、パケットのプレイアウト時刻に関連づけられたＲＴＰタイムスタンプおよびＮＴＰタイムスタンプ）を有してもよい。
【００４７】
ＲＴＰタイムスタンプはＲＴＰデータパケットにおける第１のオクテットのサンプリング例を示す。タイムスタンプの初期値は無作為な値である。ＲＴＰタイムスタンプはサンプリング期間をカウントするので、第２のＲＴＰパケットが第１のＲＴＰパケットの後に１６０のサンプルをスタートさせた場合、第２のＲＴＰタイムスタンプは第１のＲＴＰタイムスタンプよりも１６０大きい。
【００４８】
ＮＴＰタイムスタンプは絶対的な「壁掛け時計（ｗａｌｌ ｃｌｏｃｋ）」時刻である。ＮＴＰは、ＩＥＴＦ ＲＦＣ １３０５において定義されたような、１９００年１月１日から始まる６４ビットカウンタである。ＮＴＰによって用いられる６４ビットタイムスタンプは、３２ビットの整数秒部分と３２ビットの小数点以下部分からなる。ＮＴＰタイムスタンプは、ＲＴＰタイムスタンプによって識別される第１のオクテットが、特定のポイント、すなわち同期ポイントを通過する絶対的な時間を表す。
【００４９】
この特定のポイントは、ＳＣを含むユーザ機器（ＵＥ）のプレイアウトポイントであってもよく、ＮＴＰタイムスタンプは、特定のオクテットがユーザに示された時刻を表す。代替として、それは、ＳＣが特定のオクテットを最初に受信する入来ポイントであってもよい。同様の方法で、ＳＣ’を同期化するために、この特定のポイントは出力ポイントまたは入力ポイントであってもよい。
【００５０】
第１のストリーム同期ポイントは、以下の第１の同期ステータス情報メッセージをＭＳＡＳに送信することができる。
ＳＳＲＣ識別子＝１２３４５６７８
ＲＴＰタイムスタンプ＝１５５６６８８４２３
ＮＴＰタイムスタンプ＝１３：４２：２１．０００
同様に、第２のメディアストリーム同期ポイントが、以下の第２の同期ステータス情報メッセージをＭＳＡＳに送信することができる。
ＳＳＲＣ識別子＝９０ＡＢＣＤＥＦ
ＲＴＰタイムスタンプ＝１６８４６５４８４５
ＮＴＰタイムスタンプ＝１３：４２：２１．０００
【００５１】
この例では、第１のおよび第２のストリーム同期ポイントからの情報は、同じＮＴＰプレイアウト時刻、１３：４２：２１．０００に関連する。この例では、両方のメディアストリーム同期ポイントがＮＴＰ同期している、すなわち、ネットワークタイムプロトコルまたは何らかの他の手段を使用してそれらの時計は同期していると、考えられる。
【００５２】
上で説明したように、変更されたメディアストリームが同じコンテンツを搬送するが、メディアストリーム変更ユニット２０２が変更された出力ストリーム２１３においてタイミング情報を変更するので、同期は可能ではないことがある。同期を可能にするために、メディアストリーム変更ユニット２０２に関連する同期クライアントＳＣ’は、メディアストリーム変更ユニットによって受信された、入ってくるメディアストリーム２１２と、メディアストリーム送信ユニットによって第２のメディアストリーム同期ポイントに送信される、出て行くメディアストリーム２１３と、の間の同期関係に基づく同期相関情報メッセージを送信してもよい。したがって、同期関係は第１のパケットにおける第１のタイミング情報と、第２のパケットにおける第２のタイミング情報に関しており、第１のおよび第２のパケットは同一のコンテンツまたはその一部を有し、前記第２のパケットはメディアストリーム変更ユニットによって変更されたストリームの一部であり、前記第１のパケットは前記変更を受ける前のメディアストリームの一部である。
【００５３】
第１の実施形態では、メディアストリーム変更ユニットは以下の情報をＭＳＡＳに送信してもよい。
入ってくる：
ＳＳＲＣ識別子＝１２３４５６７８
ＲＴＰタイムスタンプ＝１５５６６８８４２３
出ていく：
ＳＳＲＣ識別子＝９０ＡＢＣＤＥＦ
ＲＴＰタイムスタンプ＝１６８４６５７８４５
この情報は、入ってくるＳＳＲＣ識別子／ＲＴＰタイムスタンプの組と、出ていくＳＳＲＣ識別子／ＲＴＰタイムスタンプの組と、の両方を含む。したがって、同期相関情報メッセージは、ＭＳＡＳに信号化されたＳＳＲＣおよび／またはＲＴＰタイムスタンプを使用して、ストリーム変更ユニットの入力において受信された１つ以上のストリームと、ストリーム変更ユニットの出力において送信された１つ以上のストリームと、の相関を可能にすることができる。
【００５４】
一実施形態では、同期相関情報は１つのメッセージでＭＳＡＳに送信されてもよい。他の実施形態では、同期相関情報は２つの別々のメッセージで送信されてもよい。別々のメッセージの使用は、入ってくるストリームまたは出ていくストリームのいずれかの同期パラメータが時間を通してあまり大きく変化しない場合には、これらのストリームに関連した同期情報の信号化が頻繁には必要ないため、有利である。同期情報の信号化に関するさらなる詳細は、図５〜図７を参照して以下に説明される。
【００５５】
ＭＳＡＳ２０４は、メディアストリーム同期ポイントおよび、メディアストリーム変更ユニットからの同期関係を含む同期相関情報メッセージの両方から、第１のおよび第２の同期ステータス情報メッセージを受信する。その後、ＭＳＡＳ２０４はこの情報を用いて、第１のおよび第２のメディアストリーム同期ポイントにおけるタイミング情報を計算する。
【００５６】
この計算は２つの計算ステップを含むことができる。第１のステップは、すべての同期ステータス情報を１つの時間軸（時間基準）に調整する計算に関する。第２のステップにおいては、現実の遅延情報が計算される。以下の例では、両方のＲＴＰタイムスタンプがミリ秒スケールを示すと考える。そうでなければ、計算はこのことを反映するように調整されるべきである。第１のステップにおいては、すべての同期ステータス情報は１つの共通の時間軸、例えば、オリジナルのメディアストリーム２１２のＲＴＰタイムスタンプに関連する時間軸に適合される。このステップはステータス情報変換ステップと呼ばれる。
【００５７】
１３：４２：２１．０００において、第１のメディアストリーム同期ポイント２０５はタイムスタンプ１５５６６８８４２３にある。この例では、第２のメディアストリーム同期ポイント２０８によって提供されたタイムスタンプはオリジナルのメディアストリーム２１２に関連する時間軸に調整される。他の変形例では、変更されたストリームに関連する時間軸に基づいて同期ステータス情報を調整すること、または両方のストリームの時間軸を新しい（第３の）時間軸に調整することが可能であってもよい。第３の時間軸の例は、各メディアストリームがタイムスタンプ０で開始して、各ストリームから無作為に選ばれた第１のタイムスタンプが０への調整を必要とするような状況に関連してもよい。
【００５８】
第２のメディア同期ポイント２０８から受信された同期ステータス情報を調整するために、以下の情報が用いられる。
−値１６８４６５４８４５を有する調整されたストリームの同期ステータス情報におけるＲＴＰタイムスタンプ
−変更されたストリームに関連するＲＴＰタイムスタンプ値１６８４６５７８４５が、オリジナルのストリームに関連するＲＴＰタイムスタンプ値１５５６６８８４２３に相関する。
タイムスタンプを調整するための計算は簡単な線形変換に関するものでよい。調整されたタイムスタンプ＝ｃｏｎｖ＿ｔｉｍｅｓｔａｍｐ＿ｏｒｇ＿ｓｔｒｅａｍ＋ｃｏｎｖ＿ｔｉｍｅｓｔａｍｐ＿ｍｏｄ＿ｓｔｒｅａｍ−ｔｉｍｅｓｔａｍｐ＿ｍｏｄ＿ｓｔｒｅａｍ＿ｃｕｒｒｅｎｔ。したがって、１３：４２：２１．０００に、第２のメディアストリーム同期ポイント２０８は、調整されたタイムスタンプ１５５６６８８４２３＋１６８４６５４８４５−１６８４６５７８４５＝１５５６６８５４２３に関連するかもしれない。そのように、第２のメディアストリーム同期ポイント２０８から受信された同期ステータス情報は、第１のメディアストリーム同期ポイント２０５から受信された同期ステータス情報に関連する時間軸に調整されてもよい。
【００５９】
その後、遅延情報の計算が知られているスキームに従って実行されてもよい。例えば、遅延情報はメディアストリームを再生する際にいちばん遅れているクライアントに基づいて決定される。上記の例において両方のタイムスタンプが同じ時刻１３：４２：２１．０００に報告されているため、計算は双方のメディアストリーム同期ポイントの同期ステータス情報の単純な減算を含んでもよい。１５５６６８５４２３−１５５６６８８４２３＝−３０００。この結果は、第２のメディアストリーム同期ポイント２０８におけるメディアストリームが、第１のメディアストリーム同期ポイント２０５におけるメディアストリームから３秒遅れていることを示す。この時間差はメディアストリーム変更ユニット２０２において実行されたトランスコードプロセスに起因するかもしれない。報告された時刻（すなわちＮＴＰ時刻）がＭＳＡＳによって受信された異なる同期ステータス情報メッセージにおいて異なる場合は、この時刻の相違は、遅延を決定するための計算において考慮されるべきである。
【００６０】
上記から、変更されたストリームは３秒遅れている（タイムスタンプの右から４桁目に示されているように）ということになる。別の実施形態では、調整されたメディアストリームの時間軸が用いられてもよい。１６８４６５７８４５ｍｓ−１６８４６５４８４５ｍｓ＝３０００ｍｓ。したがって、両方のメディアストリーム同期ポイントのメディアストリームを同期させるためには、ＭＳＡＳは第１の同期ポイント２０５に同期設定指示を送信して、プレイアウトを３秒遅らせてもよい。
【００６１】
図３は、図２を参照した上記の例におけるメッセージフロー図３００における情報の交換を図示する。第１のステップ３０２において、第１の同期ポイントはメディアストリーム発信元からオリジナルのメディアストリームを受信し、第２の同期ポイントはメディアストリーム変更ユニットの出力から変更されたメディアストリームを受信し、メディアストリーム変更ユニットは入力信号としてメディアストリーム発信元からのオリジナルのメディアストリームを用いる。
【００６２】
第２のおよび第３のステップ３０４、３０６において、第１のおよび第２の同期ポイントはそれぞれ第１のおよび第２の同期ステータス情報メッセージをメディア同期アプリケーションサーバ（ＭＳＡＳ）に送信する。その後、第４のステップ３０８において、メディアストリーム同期ユニットは、入ってくるメディアストリームと出ていくメディアストリームの間の同期関係に基づく相関情報メッセージをＭＳＡＳに送信する。したがって、ＭＳＡＳは第５のステップ３１０において、同期設定指示を計算して、送信先、すなわち第１のおよび第２の同期ポイントにこれらの指示を送信してもよい。
【００６３】
図２および図３を参照して記載された非限定的な例は、１つのメディアストリーム変更ユニットおよび２つの同期ポイントを用いる送信先間同期スキームを示す。さらなる変形例では、そのようなスキームは２つ以上のストリーム変更ユニットと共に、および／または２つ以上のメディア同期ポイントと共に用いられてもよい。ネットワーク上の信号化メッセージ（例えば同期ステータス情報メッセージ、異なるタイムスタンプを相関化する情報を含むメッセージ、同期設定指示）を搬送するために異なるプロトコルが用いられてもよい。これらのメッセージは例えばＨＴＴＰ上でＳＯＡＰを用いるＸＭＬフォーマット（Ｗ３Ｃ推奨）、ＳＩＰメッセージ（ＩＥＴＦ ＲＦＣ ３２６１）またはＲＴＣＰメッセージでＭＩＭＥメッセージボディにおけるＸＭＬフォーマットまたはプレーンテキストにおいて搬送されてもよい。
【００６４】
図２および図３を参照して記載された例において、変更可能な遅延ユニットおよび同期ユニットはクライアントサーバタイプモデルにおいて実施され、そこでは、遅延ポイントにおける変更可能な遅延ユニットの機能は同期クライアント（ＳＣ）の一部として実施されてもよく、同期ユニットは同期サーバ（ＳＹＮＣＨＳまたはメディア同期アプリケーションサーバ（ＭＳＡＳ））として実施されてもよい。同期クライアントは、同期ステータス情報が適切なプロトコルを用いて同期サーバ（同期ユニット）に送信可能となり、同期設定指示が同期サーバから受信可能となるプロトコルソケットを有してもよい。
【００６５】
同期ステータス情報はストリーム受信に基づいたタイミング情報（すなわち、第１の同期ポイントに到達するストリームにおけるパケットの到達時間）を含んでもよく、現在の遅延設定を含んでもよい。したがって、同期ステータス情報は、ストリームにおけるパケットが同期ポイントによって受信される時間においてポイントを考慮する情報を含んでもよい。同期設定指示は、例えば実際に計算された遅延を用いて変更可能な遅延バッファを設定することについての指示を含んでもよい。
【００６６】
同期設定指示および遅延指示という用語は、本発明の目的のために同じ意味で用いられており、あるメディアストリームの実際の遅延時刻を含んでもよい。好ましくは、これらの遅延指示は所定の継続時間だけメディアストリームを遅延させることに関する正の時間値を含んでもよい。代替として、遅延指示はメディアストリームのプレイアウトまたは出力を速めることに関する負の時間値を含んでもよい。ある同期ポイントが大きなバッファを有し、知られている測定を用いてバッファリング時刻を減少させることによって遅延を短縮することを可能にする場合が、これにあてはまるかもしれない。
【００６７】
図４は、ＥＴＳＩ ＴＳ １８２ ０２７ ｖｅｒｓｉｏｎ ２．０．０で特定されるＩＭＳに基づいたＩＰＴＶシステム４００として実施される本発明による例示的なコンテンツ配信システムを示す。ＩＰＴＶシステム４００はＩＰＴＶメディア機能（ＭＦ）４０１からなり、メディア制御機能（ＭＣＦ）４０２およびメディア配信機能（ＭＤＦ）４０３を含む。さらに、ＩＰＴＶシステム４００は搬送機能（ＴＦ）４０４、ユーザ機器（ＵＥ）４０５、ＩＰＴＶサービス制御機能（ＳＣＦ）４０６、個別のアプリケーションサーバ（ＡＳ）４０７およびコアＩＭＳネットワーク（Ｃｏｒｅ）４０８を含む。同期クライアント（ＳＣ）４０９はＵＥ４０５の部分であってもよく、搬送機能４０４の部分であってもよい。同期方法の部分として、ユーザ機器がストリームをバッファ可能であるならば、ＳＣはユーザ機器において実施されてもよい。ＳＣは、例えばユーザ機器がバッファ機能をサポートしていない場合に搬送ネットワークにおいて実装されてもよい。ＳＣは少なくとも１つの変更可能な遅延バッファに関連しており、したがってＳＣがＵＥ内で実装される場合、ＳＣは１つ以上の関連する変更可能な遅延バッファ４１０を有してもよい。同様に、ＳＣが搬送機能の一部として実施される場合は、搬送機能を含む要素は１つ以上の変更可能な遅延バッファ４１０を有してもよい。ＭＳＡＳ４１１の機能は、搬送機能またはメディア機能の部分として、標準ＩＰＴＶサービス制御機能４０６に含まれてもよく、代替として、スタンドアローンなアプリケーションサーバ４０７上で実施されてもよい。メディアストリーム変更ユニット（ＭＳＭＵ）４１３はＩＰＴＶメディア機能４０１の一部であってもよい。ＭＤＦ４０３は実際のトランスコードを実行することができ、ＭＣＦ４０２は同期クライアント（ＳＣ’）４１２を含むことができる。
【００６８】
図５は、本発明の一実施形態による送信先間同期スキーム５００の実施形態を示し、ＲＴＣＰ ＲＴＰ制御プロトコル（ＲＴＣＰ）が、メディア配信システムにおける要素間で同期情報を搬送するために用いられる。システムは２つの同期クライアントＳＣａ、ＳＣｂ ５０２、５０４を含む。同期クライアントは第１のおよび第２のメディアストリーム５１２、５１４に関連づけられた信号同期ステータス情報をＭＳＡＳ５０８に信号化するように設定されている。２つの同期クライアントは２つの異なるＲＴＰメディアストリームを受信する２つのユーザ機器（ＵＥ）（図示せず）内にあり、該２つのメディアストリームは異なるサンプリングレートであってもよい。ＳＣａによって受信された第１のメディアストリーム５１２は、メディアストリーム発信元（すなわちメディアサーバ）に関連したオリジナルのメディアストリームであってもよく、ＳＣｂによって受信された第２のメディアストリーム５１４は、変更されたメディアストリームであってもよい。第１のメディアストリームを第２のメディアストリームに変更する、メディアストリーム変更ユニット（トランスコーダ）５０２は、該第１のおよび第２のメディアストリームの間の同期関係をＭＳＡＳに報告する特別な同期クライアントＳＣ’５１０を含む。
【００６９】
システムはＵＥ、メディアストリーム変更ユニットおよびメディアストリーム発信元の間のメディアセッションをセットアップするためにＳＩＰを使用してもよい。ＳＩＰ信号化によって搬送されたセッション記述プロトコル（ＳＤＰ）が、各セッションにおけるメディア構成要素を記述およびネゴシエートするために用いられてもよい。セットアップの最中、ＵＥ（およびメディアストリーム変更ユニット）は、特定のＵＥが属する同期グループを識別するＳｙｎｃＧｒｏｕｐＩｄと関連づけられてもよい。
【００７０】
同期グループは、１つ以上の指定されたメディアストリームに関して同期されることが必要なＵＥのグループである。そのようなグループの例は、同期方法において互いに同じコンテンツオンデマンド（映画）を観ることを要求する、２つの異なる位置にある２つの異なるユーザに属する２つのＵＥであってもよい。
【００７１】
同期セッションを設定する詳細な説明のために、「Ｄｙｎａｍｉｃ ＲＴＣＰ ｒｅｌｙ」という名称の、同時に係属する欧州特許出願が参照され、それは本出願への参照によって本明細書に組み込まれる。
【００７２】
さらに、ＵＥおよびメディアストリーム変更ユニット、特にその中に位置する同期クライアントは、ＲＴＰ制御プロトコル（ＲＴＣＰ）を用いて、同期情報をＭＳＡＳに関連づけられたＩＰアドレスおよびポート番号に送信し、ＵＥに関連づけられたＲＴＣＰ受信器ポート上でＭＳＡＳからのＲＴＣＰ報告を受信してもよい。一実施形態では、同期クライアントは、ＲＴＣＰ拡張報告（ＲＴＣＰ ＸＲ）を用いたＲＴＣＰ受信器報告（ＲＴＣＰ ＲＲ）において同期ステータス情報を含み、１つ以上のＲＴＣＰメッセージ内のその情報をＭＳＡＳに送信することができる。
【００７３】
特に、同期クライアントは、同期ステータス情報を含む、特別にフォーマットされたＲＴＣＰ拡張報告（ＲＴＣＰ ＸＲ）５１６、５１８を生成してもよい。この情報はＮＴＰタイムスタンプと組み合わせられたＲＴＰタイムスタンプの形式であってもよい。ＲＴＣＰ ＸＲは発信元のＳＳＲＣ、パケットで受信されたＮＴＰタイムスタンプ、パケットで受信されたＲＴＰタイムスタンプ（ＲＴＰ受信タイムスタンプ）をさらに有してもよく、随意には、ＳｙｎｃＧｒｏｕｐＩｄパラメータを有してもよい。さらに、ＲＴＣＰ ＸＲは、ＸＲにパケットで示されたＮＴＰタイムスタンプ（ＮＹＰ表示タイムスタンプ）を有してもよい。
【００７４】
ＳｙｎｃＧｒｏｕｐＩｄパラメータはセッション記述プロトコル（ＳＤＰ）セッションレベル属性、例えば、ａ＝ＲＴＣＰ−ｘｒ：ｓｙｎｃ−ｇｒｏｕｐ＝＜ｖａｌｕｅ＞として、または、例えばＩＥＴＦ ＲＦＣ ３５５０によるＳＤＥＳ ＰＲＩＶアイテムの形式で実施されてもよい。さらなる実施形態では、ＩＥＴＦ ＲＦＣ ３６１１から知られるＲＴＣＰ−ｘｒ属性フィールドが用いられてもよい。
【００７５】
メディアストリーム変更ユニットＳＣ’に関連づけられた同期クライアントは、ＭＳＡＳに同期相関情報を報告する。ＵＥに関連づけられた同期クライアントとは対照的に、ＳＣ’はトランスコーダの入力で１つ以上のメディアストリームに関連づけられたＲＴＣＰ ＸＲと、トランスコーダの出力で１つ以上のメディアストリームに関連づけられたＲＴＣＰ ＸＲを送信する。一般的に、同期相関情報５２０は２つのＲＴＣＰ ＸＲによって形成され、それは入力ストリームに関連づけられた第１のＲＴＣＰ ＸＲ５２２および出力ストリーム（すなわち変更された入力ストリーム）に関連づけられた第２のＲＴＣＰ ＸＲ５２４である。したがって、同期相関情報は、一方は入力ストリームに関連づけられもう一方は出力ストリームに関連づけられた２組のタイムスタンプ（ＲＴＰ１，ＮＴＰ１）および（ＲＴＰ２，ＮＴＰ２）を有してもよい。
【００７６】
ＭＳＡＳはさらに、同期設定指示を含むＲＴＣＰ ＸＲを同期クライアントＳＣａ、ＳＣｂに送信してもよい。これらのＲＴＣＰ ＸＲは発信元のＳＳＲＣ、パケットで受信された参照ＮＴＰタイムスタンプ、パケットで受信された参照ＲＴＰタイムスタンプ受領タイムスタンプを含んでもよい。ＲＴＣＰ ＸＲはまた、パケットで示された参照ＮＴＰタイムスタンプをさらに有してもよい。これらのＲＴＣＰ ＸＲは共にＲＴＣＰ送信者報告（ＳＲ）に追加されてもよく、ＵＥによって別々に受信されてもよい。
【００７７】
同期設定はＮＴＰタイムスタンプと組み合わせられたＲＴＰタイムスタンプの形式であってもよく、ここでＮＴＰタイムスタンプは、例えばＳｙｎｃＧｒｏｕｐＩｄによって識別されたとして同期グループによって分割されたクロックを示し、ＲＴＰタイムスタンプは期待される提示時刻を示す。
【００７８】
一実施形態において、同期クライアントはＭＳＡＳと同一場所に配置されてもよい。この場合には、同期ステータス情報と同期設定指示の交換は、それらが存在するＭＳＡＳの１つ以上の機能エンティティの内部で行われる。
【００７９】
別の実施形態において、同期は１つ以上のブロードキャストストリームの同期に関してもよい。この場合には、ＭＳＡＳは、ＲＦＣ ３５５０においてより詳細に記載されたようにフィードバックターゲットとして機能することができる。ＲＴＣＰ受信器報告を転送する前に、ＭＳＡＳは同期ステータス情報を含むＲＴＣＰ拡張報告を読み込んで削除してもよい。したがって、ＭＳＡＳはＲＴＣＰ拡張報告を用いて同期設定指示を同期クライアントに送信してもよい。
【００８０】
コンテンツオンデマンドまたは他の単一キャストのストリームの同期の場合、ＭＳＡＳは１つ以上のＵＥに関連づけられたＲＴＣＰ受信器報告を適切なメディア機能ＭＦに転送してもよい。ＲＴＣＰ受信者報告を転送する前に、ＭＳＡＳはＲＴＣＰ ＸＲを読み込んで解析し、同期ステータス情報を含むそれらのＲＴＣＰ拡張報告を削除してもよい。したがって、ＭＳＡＳは、ＲＴＣＰ送信者報告を適切な同期クライアントに転送して、ＲＴＣＰ拡張報告を使用してＳＣに同期設定指示を追加してもよい。ＭＳＡＳは別のＲＴＣＰ ＸＲを用いて同期クライアントに同期設定指示を送信してもよい。
【００８１】
図６は、本発明の一実施形態によるＲＴＰメディアストリーム上の同期情報を報告する例示的なＲＴＣＰ拡張報告を示す。同期ＲＴＣＰ ＸＲにおける以下のフィールドが、本発明による同期スキームにおいて使用されてもよい。
−特定のＲＴＣＰパケットの送信者を識別するパケット送信者のＳＳＲＣ。
−ブロックフォーマットを識別する８ビットのブロックタイプ（ＢＴ）フィールド。
−この特定の拡張報告のためのパケット送信者の役割を識別する、４ビットの同期パケット送信者タイプ（ＳＰＳＴ）フィールド。
−パケット提示ＮＴＰタイムスタンプが値を有する場合には１に設定される、パケット提示ＮＴＰタイムスタンプフラグ（Ｐ）。このフラグが０に設定された場合は、パケット提示ＮＴＰタイムスタンプは検査されていないものとする。
−メディアペイロードのフォーマットを識別する、７ビットのペイロードタイプ（ＰＴ）フィールド。メディアペイロードは、ＲＴＰタイムスタンプカウンタにタイムベースを提供するＲＴＰタイムスタンプクロック速度に関連づけられてもよい。
−同期されたメディアストリームを相関させる際に用いるメディアストリーム相関識別子（３２ビット）。ＲＴＣＰパケット送信者がＳＣまたはＭＳＡＳ（ＳＰＳＴ＝１またはＳＰＳＴ＝２）である場合、メディアストリーム相関識別子はＳｙｎｃＧｒｏｕｐＩｄ上にマッピングされる。ＲＴＣＰパケット送信者がＳＣ’（ＳＰＳＴ＝３またはＳＰＳＴ＝４）である場合、入ってくるまたは出ていく関連のメディアストリームは同一のメディアストリーム相関識別子を有してもよい。
−メディア発信元のＳＳＲＣ（３２ビット）は、ＸＲが関連するＲＴＰパケットのＲＴＰヘッダにおいて搬送されるＳＳＲＣ識別子の値に設定されてもよい。
−パケット受信ＮＴＰタイムスタンプ（６４ビット）は、ＸＲが関連するＲＴＰパケットの最初のオクテットの到達時刻を表してもよい。
−パケット受信ＲＴＰタイムスタンプ（３２ビット）は、ＸＲが関連するＲＴＰパケットのＲＴＰヘッダにおいて搬送されるＲＴＰタイムスタンプの値に関連づけられる。
−パケット提示ＮＴＰタイムスタンプ（３２ビット）は、関連づけられたＲＴＰパケットの最初のオクテットを含むデータがユーザに提示された場合のＮＴＰタイムを反映する。これはＮＴＰの秒部分の最も重要でない１６ビットと、ＮＴＰの秒の小数点以下部分の最も重要な１６ビットを含む。このフィールドが空の場合は、このフィールドは０に設定されてもよく、パケット提示ＮＴＰタイムスタンプフラグ（Ｐ）は０に設定されてもよい。
表１は、同期パケット送信者タイプ（ＳＰＳＴ）フィールドに関連づけられ
た値を示す。
【００８２】
【表１】
【００８３】
図６を参照して記載されたように、特別にフォーマットされたＲＴＣＰ拡張報告を用いると、ネットワークまたは１つ以上のＵＥのクライアントとＭＳＡＳの間の同期情報は効率的に信号化されることができる。例えば図５に記載されたシステムにおいて、ＵＥに関連づけられた同期クライアントＳＣａ、ＳＣｂ ５０４、５０６およびメディアストリーム変更ユニットに関連づけられた同期クライアントＳＣ’５１０は、ＲＴＣＰ ＸＲを用いてＭＳＡＳに同期情報（すなわち、同期ステータス情報または同期相関情報）を報告することができる。表２はこの情報の例を提供する。
【００８４】
【表２】
メディアストリームはその同期発信元（ＳＳＲＣ識別子）によって識別されることができる。すなわち、ＳＳＲＣａ＝ＳＳＲＣ１であり、ＳＳＲＣｂ＝ＳＳＲＣ２である。このようにして、ＭＳＡＳは、ＳＣａが第１のメディアストリームを受信してＳＣｂが第２のメディアストリームを受信することを導き出すことができる。さらに、各メディアストリームは、Ｈｚ（すなわち、秒あたりのクロック刻み数）で表すことができる特定のクロック速度に関連してもよい。すなわち、ＣＲａ＝ＣＲ１であり、ＣＲｂ＝ＣＲ２である。典型的なクロック速度は、音声に関しては毎秒８０００〜９６０００サンプルの範囲にあり、映像に関しては毎秒９０．０００サンプルである。
【００８５】
一実施形態では、クロック速度はＭＳＡＳに信号化されてもよい。別の実施形態では、速度は一定であってもよい。さらに別の実施形態では、クロック速度の代わりにペイロードタイプがＭＳＡＳに信号化されてもよい。ペイロードタイプは、例えばＩＥＴＦ ＲＦＣ ３５５１に記載されたスキームを用いて、クロック速度をマッピングしてもよい。ＭＳＡＳに報告された情報は、ＲＴＰタイムスタンプとＮＴＰタイムスタンプの両方をさらに含んでもよい。
【００８６】
ＳＣ’は、各メディアストリームにつき１つの、２組のタイムスタンプ（ＲＴＰ１、ＮＴＰ１）および（ＲＴＰ２、ＮＴＰ２）をＭＳＡＳに報告する。ＮＴＰ１はＲＴＰ１によって識別されたオクテットがＳＣ’において特定のポイントを通過した時間を表し、ＮＴＰ２はＲＴＰ２によって識別されたオクテットがＳＣ’において特定のポイントを通過した時間を表す。トランスコードおよびクロック速度が変化するため、これらは一般的に異なるオクテットである。識別されたオクテットによって表されるコンテンツ内のポイントが特定のポイントをいつ通過したのかを決定するために、ＳＣ’は計算を行ってＮＴＰ１およびＮＴＰ２を決定しなければならない。
【００８７】
ＭＳＡＳは、プレイアウトＳＣａ−プレイアウトＳＣｂ＝（ＮＴＰａ−（ＲＴＰａ／ＣＲａ）−（ＮＴＰｂ−（ＲＴＰｂ／ＣＲｂ）−（ＮＴＰ１−（ＲＴＰ１／ＣＲ１）＋（ＮＲＰ２−（ＲＴＰ２／ＣＲ２）というアルゴリズムを使用することで、ミリ秒単位でのＳＣａのプレイアウトとＳＣｂのプレイアウトの差を決定してもよい。それらのプレイアウトを十分に同期させるために、その結果を用いて、ＳＣａまたはＳＣｂに特定の量だけそのプレイアウトを遅延させることを指示してもよい。
【００８８】
表３の例にあるパラメータを用いると、−５．４９３秒の遅延（プレイアウトＳＣａ−プレイアウトＳＣｂ）という結果になり、このことは、ＳＣｂがＳＣａよりも５．４９３秒遅くプレイアウトしたことを示す。したがって、実質的に同期させるために、この計算に基づいて、ＭＳＡＳはＳＣａにその出力を５．４９３秒遅らせるよう指示してもよい。
【００８９】
【表３】
図７は、本発明の他の実施形態による、メディアストリームを同期させるためのＲＴＣＰ ＸＲメッセージの使用を示す。この例では、ある単一のコード化装置７０２が複数のメディアストリーム変更ユニットを含んでもよい。コード化装置は複数の入ってくるメディアストリーム７０８、７１０および出ていくメディアストリーム７１２−７１６に関連づけられてもよく、出ていくメディアストリーム７１２−７１６は、単一の同期クライアントＳＣ’７０４によって同期化されてもよい。
【００９０】
入ってくる各メディアストリームＡ１、Ｂ４に関して、および出ていく各メディアストリームＡ２、Ａ３、Ｂ５、．．．に関して、同期クライアントＳＣ’はＲＴＣＰ ＸＲ７１８−７２４をＭＳＡＳ７０６に送信してもよい。したがって、この実施形態では、同期相関情報は２つのＲＴＣＰ ＸＲにおいてＭＳＡＳに送信される。それらは、入ってくるメディアストリーム７０８、７１０に関連づけられた第１のＲＴＣＰ ＸＲ ７２４、７２６および、出ていくメディアストリーム７１２−７１６に関連づけられた第２のＲＴＣＰ ＸＲ ７１８−７２２である。
【００９１】
そのような信号化スキームは、ＲＴＣＰ ＸＲが異なる時刻に、および異なる速度でＭＳＡＳに独立して送信されるという利点を有する。あるメディアストリームがより安定した時間参照を有する場合は、その同期相関情報はより不定期に更新されてもよくなり、したがって処理時間および帯域が節約される。さらに、入ってくるあるメディアストリームが複数の異なる出ていくメディアストリームにトランスコードする場合、入ってくるメディアストリームに関した同期相関情報の部分が測定され、１度だけ送信されるべきであり、それによって時間および帯域が節約される。
【００９２】
しかしながら、同期相関情報の異なる部分（ＲＴＣＰ ＸＲ）を独立して送信することは、同期相関情報のどの部分が関連する部分であるかをＭＳＡＳが知っていないため、問題となることがある。この場合には、ＭＳＡＳが、同期相関情報のどの部分がひとまとまりになっているかを決定することが不可能である。
【００９３】
この理由により、ＭＳＡＳがトランスコード装置の入力および出力における異なるメディアストリームを相関させることと、正しい同期相関情報をＭＳＡＳによって受信された異なるＲＴＣＰ ＸＲから導き出すことと、を可能にするために、同期クライアントＳＣ’はメディアストリーム相関識別子（ＭＳＣＩ）を生成する。例えば、図７において、ＭＳＡＳはＭＳＣＩＡを用いて、メディアストリーム７１０に関連づけられたＲＴＣＰ ＸＲ７２６を、（変更された）メディアストリーム７１２に関連づけられた第１のＲＴＣＰ ＸＲ７１８および（変更された）メディアストリーム７１４に関連づけられた第２のＲＴＣＰ ＸＲ７２０と相関させることができる。このようにして、複数の変更されたメディアストリームの効率的な同期が達成されてもよい。互いに関連する異なるストリームの間の同期は、同時に同じブロードキャストを視聴することを望みながら異なる性能の異なるプレイアウト装置を用いる異なるユーザにとって有利でありうるだけでなく、互いに関連する異なるストリームを搬送する２つ以上ネットワークを切り換える単独のユーザにとっても有益でありうることに留意すべきである。この切り換えは、例えば、ユーザがカバレッジの悪いモバイルネットワークを用いる場合に発生しうる。ユーザがネットワークへの接続から離れた場合、ユーザは別のネットワーク、例えば、カバレッジが改良された別のモバイルネットワークに切り換えることを望むかもしれない。そのようなネットワーク切り換えの例に、ＤＶＢ−Ｈ（デジタルビデオブロードキャスト−ハンドヘルド）ネットワークとＵＴＭＳネットワークの間の切り換えがありうる。モバイルネットワークと固定ネットワークの間の切り換えもまた行われるかもしれない。例えば、モバイルネットワーク経由でビデオストリームを見ているユーザが、帰宅して固定ネットワークに接続された自分の大スクリーンテレビジョンで視聴を続けることを望む場合である。互いに関連する異なるストリームの間の遅延を打ち消すことは、シームレスなネットワーク移行および向上したユーザエクスペリエンスを提供する。
【００９４】
任意のある実施形態に関連して記載されたいかなる特徴も、単独で用いられてもよく、または記載された他の特徴と組み合わされて用いられてもよく、任意の他の実施形態の１つ以上の特徴と組み合わされて用いられてもよく、任意の他の実施形態の組み合わせと組み合わされて用いられてもよい。さらに、上記されなかった同等の例および変形例もまた、本発明の範囲から逸脱せずに用いられることができ、それらは添付の特許請求の範囲において定義される。
【００９５】
例えば、本発明による同期方法は、例えばネットワーク全体またはその一部上で作動する、または、ネットワークを介して流れるすべてのストリーム上で作動する、またはあるストリーム上のみで作動する連続プロセスとして実施されることができる。さらに、連続動作はすべての同期ポイントに作用してもよく、特定の同期ポイントのみに作用してもよい。方法は、この連続方式において動作するようにシステムを構成することによって実施されてもよい。
【００９６】
代替として、方法は、例えばクライアントサーバ型のモデルを用いるセッション型の同期プロセスとして実施されてもよい。同期セッションは、例えばネットワーク内のあるトリガを介して開始または終了してもよい。同期セッションを開始または終了するトリガは、例えば同期ポイントによって提供されてもよく、ネットワークまたはシステム内の他の要素によって提供されてもよい。
【００９７】
一実施形態では、同期サーバおよび同期クライアントは同期セッションを開始および終了するように構成されてもよい。同期セッションは、同期クライアントが招待メッセージを同期サーバに送信したときに開始されてもよく、逆も同様である。同期セッションの最中に、同期サーバおよび同期クライアントは同期ステータス情報および同期設定指示を交換してもよい。同期セッションは、同期クライアントが同期サーバに終了メッセージを送信したときに終了してもよく、逆も同様である。同期サーバおよび同期クライアントは、招待を受け入れるために、または同期セッションの終了を確認するために、返答メッセージを送信してもよい。
【特許請求の範囲】
【請求項１】
少なくとも１つの第１のストリーム、および少なくとも１つの第２のストリームの送信先間同期の方法であって、前記第２のストリームは、メディアストリーム変更ユニットの出力ストリームと関連づけられ、前記第１のストリームを入力ストリームとして使用し、
−第１の同期ポイントに到達した第１のストリーム内のパケットの第１の到達時刻情報および、第２の同期ポイントに到達した第２のストリーム内のパケットの第２の到達時刻情報を提供するステップと、
−前記入力ストリームと前記出力ストリームの間の同期関係に関する同期相関情報を提供するステップと、
−前記第１のおよび前記第２の到達時刻情報および前記同期相関情報に基づいて、遅延情報を計算するステップと、を含む方法。
【請求項２】
−少なくとも前記第１のまたは前記第２の同期ポイントに前記遅延情報を提供し、前記第１のおよび前記第２の同期ポイントによってそれぞれ出力される前記第１のおよび前記第２のストリームが実質的に同期するように、少なくとも前記第１のおよび前記第２の同期ポイントがストリームの出力を遅延させることを可能にするステップをさらに含む、
請求項１に記載の方法。
【請求項３】
前記第１のおよび前記第２のストリームが少なくとも前記第１のおよび前記第２の同期ポイントによって出力され、前記同期ポイントは前記同期ポイントを同期させるために少なくとも１つの同期ユニットに接続される、請求項１または２に記載の方法。
【請求項４】
遅延情報を計算する前記ステップは、第１の到達時刻情報と第２の到達時刻情報の間の共通のタイムラインを達成するように、第１のおよび／または第２の到達時刻情報を調整する調整ステップをさらに有し、前記調整ステップは、同期相関情報の少なくとも一部に基づく、請求項１から３のいずれか一項に記載の方法。
【請求項５】
前記調整ステップは到達時刻情報調整モジュールによって実行され、前記モジュールは同期ユニットの一部であり、前記同期ユニットは同期相関情報の少なくとも一部を提供される、請求項４に記載の方法。
【請求項６】
前記調整ステップは同期ポイントにおいて実行され、前記同期ポイントは到達時刻情報調整モジュールを有し、前記到達時刻情報調整モジュールは同期相関情報の少なくとも一部を提供され、同期ユニットは調整された第２の到達時刻情報を提供される、請求項４に記載の方法。
【請求項７】
前記調整ステップはネットワーク要素において実行され、前記ネットワーク要素は到達時刻情報を受信するように構成され、前記ネットワーク要素は到達時刻情報調整モジュールをさらに有し、前記到達時刻情報調整モジュールは、同期相関情報の少なくとも一部を提供され、同期ユニットは調整された第２の到達時刻情報を提供される、請求項４に記載の方法。
【請求項８】
前記同期ポイントは端末、ネットワークノード、またはアクセスノードである、請求項１から７のいずれか一項に記載の方法。
【請求項９】
前記ストリーム変更ユニットは、少なくとも第１のメディアストリームを受信および処理するためのメディアストリーム処理装置であり、前記処理は前記第１のメディアストリームにおけるタイミング情報を変更し、好ましくは前記メディアストリーム処理装置はトランスレータまたはミクサである、請求項１から８のいずれか一項に記載の方法。
【請求項１０】
前記同期ユニットは同期ポイントまたはネットワークノードに含まれ、好ましくは同期サーバに含まれる、請求項１から９のいずれか一項に記載の方法。
【請求項１１】
前記到達時刻情報、前記同期相関情報および／または前記遅延情報は１つ以上のＲＴＣＰメッセージにおいて信号化され、好ましくは１つ以上のＲＴＣＰ拡張報告において信号化される、請求項１から１０のいずれか一項に記載の方法。
【請求項１２】
前記ＲＴＣＰメッセージの少なくとも１つが、パケットの発信元を識別する識別子、ＲＴＰタイムスタンプ、ＮＴＰタイムスタンプ、クロック速度値および／またはメディアストリーム相関識別子を少なくとも備える、請求項１１に記載の方法。
【請求項１３】
少なくとも、第１のメディアストリームを受信する第１の同期ポイントおよび第２のメディアストリームを受信する第２の同期ポイントの出力を同期させる同期ユニット、好ましくは同期サーバであって、前記第２のストリームは、入力ストリームとして第１のストリームを用いるメディアストリーム変更ユニットの出力ストリームであり、前記同期ユニットは、
第１の同期ポイントに関連づけられたストリームにおけるパケットに関連づけられた第１の時刻情報と、第２の同期ポイントに到達する第２のストリームにおけるパケットの第２の到達時刻情報と、を受信する第１の入力と、
前記入力ストリームと前記出力ストリームの間の同期関係に関する同期相関情報を受信する第２の入力と、
前記第１のおよび前記第２の到達時刻情報および前記同期相関情報に基づいて遅延情報を計算するプロセッサと、を含む、同期ユニット。
【請求項１４】
受信されたストリームが実質的に同期するように、前記第１のおよび前記第２の同期ポイントにおける１つ以上の可変遅延ユニットが受信されたストリームの出力時間を遅延させることを可能にする遅延情報を前記第１のおよび前記第２の同期ポイントに送信する出力をさらに有する、
請求項１３に記載の同期ユニット。
【請求項１５】
前記到達時刻情報、前記同期相関情報および／または前記遅延情報が１つ以上のＲＴＣＰメッセージにおいて信号化され、好ましくは１つ以上のＲＴＣＰ拡張報告において信号化される、請求項１３または１４に記載の同期ユニット。
【請求項１６】
少なくとも第１のおよび第２の同期ポイントの出力の送信先間同期システムであって、
メディアストリームを配信するコンテンツ配信サーバと、
入力メディアストリームを変更して、変更された出力メディアストリームにするように構成され、前記入力ストリームと前記出力ストリームの間の同期関係に関する同期相関情報を提供するように構成されたストリーム変更ユニットと、
請求項１１または１２に記載の少なくとも１つの同期ユニットと、を含む、システム。
【請求項１７】
前記同期ユニットが、
ストリーム変更ユニットから同期相関情報を受信する第１の入力と、
ストリームにおけるパケットの到達時刻情報を同期ユニットに送信する出力と、
少なくとも１つの可変遅延ユニットと、
前記少なくとも１つの可変遅延ユニットが、ストリームの出力を同期ポイントが遅延させることを可能にするように、遅延情報を受信する第２の入力と、を含む、請求項１６に記載のシステムにおいて使用する同期ポイント。
【請求項１８】
メディアストリーム変更ユニットが、前記メディアストリーム変更ユニットによって入力ストリームとして用いられる第１のメディアストリームと、前記第１のメディアストリームを入力ストリームとして用いる前記メディアストリーム変更ユニットの出力ストリームである第２のメディアストリームと、の間の同期関係に関連づけられた同期相関情報を提供する手段を含むことを特徴とする、請求項１６に記載のシステムにおいて使用するメディアストリーム変更ユニット。
【請求項１９】
ネットワーク要素が到達時刻情報変更モジュールを含み、前記モジュールが、前記同期相関情報に基づいて、同期ポイントによって受信された変更されたモジュールにおけるパケットの到達時刻情報を調整するように構成されることを特徴とする、請求項１６に記載のシステムにおいて使用するネットワーク要素。
【請求項２０】
データ構造が、メディア同期ポイントに到達するストリームにおけるパケット、またはメディアストリーム変更ユニットに到達するストリームにおけるパケット、または前記メディアストリーム変更ユニットによって送信されたストリームにおけるパケットに関連づけられた同期ステータス情報を信号化する前記システムによって使用され、前記データ構造が、前記データ構造の発信元を識別する識別子、少なくとも１つのタイムスタンプ、好ましくはＲＴＰおよび／またはＮＴＰタイムスタンプ、および／またはメディアストリーム相関識別子を少なくとも含む、請求項１６に記載のシステムにおいて使用する、好ましくはＲＴＣＰ拡張報告データ構造である、データ構造。
【請求項２１】
コンピュータのメモリにおいて実行されるとき、請求項１から１２のいずれか一項に記載の方法ステップを実行するように構成されたソフトウェアコード部分を含む、コンピュータプログラム製品。
【請求項１】
少なくとも１つの第１のストリーム、および少なくとも１つの第２のストリームの送信先間同期の方法であって、前記第２のストリームは、メディアストリーム変更ユニットの出力ストリームと関連づけられ、前記第１のストリームを入力ストリームとして使用し、
−第１の同期ポイントに到達した第１のストリーム内のパケットの第１の到達時刻情報および、第２の同期ポイントに到達した第２のストリーム内のパケットの第２の到達時刻情報を提供するステップと、
−前記入力ストリームと前記出力ストリームの間の同期関係に関する同期相関情報を提供するステップと、
−前記第１のおよび前記第２の到達時刻情報および前記同期相関情報に基づいて、遅延情報を計算するステップと、を含む方法。
【請求項２】
−少なくとも前記第１のまたは前記第２の同期ポイントに前記遅延情報を提供し、前記第１のおよび前記第２の同期ポイントによってそれぞれ出力される前記第１のおよび前記第２のストリームが実質的に同期するように、少なくとも前記第１のおよび前記第２の同期ポイントがストリームの出力を遅延させることを可能にするステップをさらに含む、
請求項１に記載の方法。
【請求項３】
前記第１のおよび前記第２のストリームが少なくとも前記第１のおよび前記第２の同期ポイントによって出力され、前記同期ポイントは前記同期ポイントを同期させるために少なくとも１つの同期ユニットに接続される、請求項１または２に記載の方法。
【請求項４】
遅延情報を計算する前記ステップは、第１の到達時刻情報と第２の到達時刻情報の間の共通のタイムラインを達成するように、第１のおよび／または第２の到達時刻情報を調整する調整ステップをさらに有し、前記調整ステップは、同期相関情報の少なくとも一部に基づく、請求項１から３のいずれか一項に記載の方法。
【請求項５】
前記調整ステップは到達時刻情報調整モジュールによって実行され、前記モジュールは同期ユニットの一部であり、前記同期ユニットは同期相関情報の少なくとも一部を提供される、請求項４に記載の方法。
【請求項６】
前記調整ステップは同期ポイントにおいて実行され、前記同期ポイントは到達時刻情報調整モジュールを有し、前記到達時刻情報調整モジュールは同期相関情報の少なくとも一部を提供され、同期ユニットは調整された第２の到達時刻情報を提供される、請求項４に記載の方法。
【請求項７】
前記調整ステップはネットワーク要素において実行され、前記ネットワーク要素は到達時刻情報を受信するように構成され、前記ネットワーク要素は到達時刻情報調整モジュールをさらに有し、前記到達時刻情報調整モジュールは、同期相関情報の少なくとも一部を提供され、同期ユニットは調整された第２の到達時刻情報を提供される、請求項４に記載の方法。
【請求項８】
前記同期ポイントは端末、ネットワークノード、またはアクセスノードである、請求項１から７のいずれか一項に記載の方法。
【請求項９】
前記ストリーム変更ユニットは、少なくとも第１のメディアストリームを受信および処理するためのメディアストリーム処理装置であり、前記処理は前記第１のメディアストリームにおけるタイミング情報を変更し、好ましくは前記メディアストリーム処理装置はトランスレータまたはミクサである、請求項１から８のいずれか一項に記載の方法。
【請求項１０】
前記同期ユニットは同期ポイントまたはネットワークノードに含まれ、好ましくは同期サーバに含まれる、請求項１から９のいずれか一項に記載の方法。
【請求項１１】
前記到達時刻情報、前記同期相関情報および／または前記遅延情報は１つ以上のＲＴＣＰメッセージにおいて信号化され、好ましくは１つ以上のＲＴＣＰ拡張報告において信号化される、請求項１から１０のいずれか一項に記載の方法。
【請求項１２】
前記ＲＴＣＰメッセージの少なくとも１つが、パケットの発信元を識別する識別子、ＲＴＰタイムスタンプ、ＮＴＰタイムスタンプ、クロック速度値および／またはメディアストリーム相関識別子を少なくとも備える、請求項１１に記載の方法。
【請求項１３】
少なくとも、第１のメディアストリームを受信する第１の同期ポイントおよび第２のメディアストリームを受信する第２の同期ポイントの出力を同期させる同期ユニット、好ましくは同期サーバであって、前記第２のストリームは、入力ストリームとして第１のストリームを用いるメディアストリーム変更ユニットの出力ストリームであり、前記同期ユニットは、
第１の同期ポイントに関連づけられたストリームにおけるパケットに関連づけられた第１の時刻情報と、第２の同期ポイントに到達する第２のストリームにおけるパケットの第２の到達時刻情報と、を受信する第１の入力と、
前記入力ストリームと前記出力ストリームの間の同期関係に関する同期相関情報を受信する第２の入力と、
前記第１のおよび前記第２の到達時刻情報および前記同期相関情報に基づいて遅延情報を計算するプロセッサと、を含む、同期ユニット。
【請求項１４】
受信されたストリームが実質的に同期するように、前記第１のおよび前記第２の同期ポイントにおける１つ以上の可変遅延ユニットが受信されたストリームの出力時間を遅延させることを可能にする遅延情報を前記第１のおよび前記第２の同期ポイントに送信する出力をさらに有する、
請求項１３に記載の同期ユニット。
【請求項１５】
前記到達時刻情報、前記同期相関情報および／または前記遅延情報が１つ以上のＲＴＣＰメッセージにおいて信号化され、好ましくは１つ以上のＲＴＣＰ拡張報告において信号化される、請求項１３または１４に記載の同期ユニット。
【請求項１６】
少なくとも第１のおよび第２の同期ポイントの出力の送信先間同期システムであって、
メディアストリームを配信するコンテンツ配信サーバと、
入力メディアストリームを変更して、変更された出力メディアストリームにするように構成され、前記入力ストリームと前記出力ストリームの間の同期関係に関する同期相関情報を提供するように構成されたストリーム変更ユニットと、
請求項１１または１２に記載の少なくとも１つの同期ユニットと、を含む、システム。
【請求項１７】
前記同期ユニットが、
ストリーム変更ユニットから同期相関情報を受信する第１の入力と、
ストリームにおけるパケットの到達時刻情報を同期ユニットに送信する出力と、
少なくとも１つの可変遅延ユニットと、
前記少なくとも１つの可変遅延ユニットが、ストリームの出力を同期ポイントが遅延させることを可能にするように、遅延情報を受信する第２の入力と、を含む、請求項１６に記載のシステムにおいて使用する同期ポイント。
【請求項１８】
メディアストリーム変更ユニットが、前記メディアストリーム変更ユニットによって入力ストリームとして用いられる第１のメディアストリームと、前記第１のメディアストリームを入力ストリームとして用いる前記メディアストリーム変更ユニットの出力ストリームである第２のメディアストリームと、の間の同期関係に関連づけられた同期相関情報を提供する手段を含むことを特徴とする、請求項１６に記載のシステムにおいて使用するメディアストリーム変更ユニット。
【請求項１９】
ネットワーク要素が到達時刻情報変更モジュールを含み、前記モジュールが、前記同期相関情報に基づいて、同期ポイントによって受信された変更されたモジュールにおけるパケットの到達時刻情報を調整するように構成されることを特徴とする、請求項１６に記載のシステムにおいて使用するネットワーク要素。
【請求項２０】
データ構造が、メディア同期ポイントに到達するストリームにおけるパケット、またはメディアストリーム変更ユニットに到達するストリームにおけるパケット、または前記メディアストリーム変更ユニットによって送信されたストリームにおけるパケットに関連づけられた同期ステータス情報を信号化する前記システムによって使用され、前記データ構造が、前記データ構造の発信元を識別する識別子、少なくとも１つのタイムスタンプ、好ましくはＲＴＰおよび／またはＮＴＰタイムスタンプ、および／またはメディアストリーム相関識別子を少なくとも含む、請求項１６に記載のシステムにおいて使用する、好ましくはＲＴＣＰ拡張報告データ構造である、データ構造。
【請求項２１】
コンピュータのメモリにおいて実行されるとき、請求項１から１２のいずれか一項に記載の方法ステップを実行するように構成されたソフトウェアコード部分を含む、コンピュータプログラム製品。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公表番号】特表２０１２−５２０６４８（Ｐ２０１２−５２０６４８Ａ）
【公表日】平成２４年９月６日（２０１２．９．６）
【国際特許分類】
【出願番号】特願２０１２−５００２２３（Ｐ２０１２−５００２２３）
【出願日】平成２２年３月１６日（２０１０．３．１６）
【国際出願番号】ＰＣＴ／ＥＰ２０１０／０５３４０７
【国際公開番号】ＷＯ２０１０／１０６０７５
【国際公開日】平成２２年９月２３日（２０１０．９．２３）
【出願人】（５０００９８０５７）コニンクリジケ ケーピーエヌ エヌブィー (9)
【出願人】（５９５１１５８０２）
【氏名又は名称原語表記】Ｎｅｄｅｒｌａｎｄｓｅ Ｏｒｇａｎｉｓａｔｉｅ ｖｏｏｒ ｔｏｅｇｅｐａｓｔ−ｎａｔｕｕｒｗｅｔｅｎｓｃｈａｐｐｅｌｉｊｋ ｏｎｄｅｒｚｏｅｋ ＴＮＯ
【Ｆターム（参考）】
【公表日】平成２４年９月６日（２０１２．９．６）
【国際特許分類】
【出願日】平成２２年３月１６日（２０１０．３．１６）
【国際出願番号】ＰＣＴ／ＥＰ２０１０／０５３４０７
【国際公開番号】ＷＯ２０１０／１０６０７５
【国際公開日】平成２２年９月２３日（２０１０．９．２３）
【出願人】（５０００９８０５７）コニンクリジケ ケーピーエヌ エヌブィー (9)
【出願人】（５９５１１５８０２）
【氏名又は名称原語表記】Ｎｅｄｅｒｌａｎｄｓｅ Ｏｒｇａｎｉｓａｔｉｅ ｖｏｏｒ ｔｏｅｇｅｐａｓｔ−ｎａｔｕｕｒｗｅｔｅｎｓｃｈａｐｐｅｌｉｊｋ ｏｎｄｅｒｚｏｅｋ ＴＮＯ
【Ｆターム（参考）】
[ Back to top ]