メディアストリームコンポーネントの同期
ブロードキャストメディアストリームの複数のコンポーネントを同期させる方法であって、ブロードキャストメディアストリームの複数のコンポーネントに関するデータサンプルのストリームをバッファし、複数の情報パケットをバッファするステップ（１８）であって、複数のコンポーネントの各々に関するデータサンプルのストリームが、相対タイミング情報を含み、各情報パケットが、前記コンポーネント内の相対タイミング情報と絶対時間との間の関係を示すタイミング情報を含む、ステップと、複数のコンポーネントの各々に関するタイミング情報を抽出するために、バッファされた情報パケットに対してルックアヘッドアクションを実施するステップ（１６）と、前記複数のコンポーネントを同期させるために、前記抽出されたタイミング情報及び相対タイミング情報を使用するステップ（１６）と、を含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オーディオ及びビデオのようなメディアストリームのコンポーネントの同期に関し、具体的には、デジタルビデオブロードキャスティング−ハンドヘルド（ＤＶＢ―Ｈ）システムにおけるコンポーネントの同期に関する。
【背景技術】
【０００２】
デジタルビデオブロードキャスティング−ハンドヘルド（ＤＶＢ―Ｈ）は、テレビジョン放送及び他のビデオ及びオーディオストリームを、持ち運び可能な（モバイル）又はハンドヘルドの装置に提供するための標準である。
【０００３】
ＤＶＢ―Ｈにおいて、時間スライスが使用されており、これは、それぞれ異なるサービス（すなわち異なるＴＶチャンネル）が、個々の時間「スライス」又はバーストで送信されることを意味する。図１は、例示のＤＶＢ―Ｈ送信構造を示す。この例では、ＤＶＢ―Ｈトランスポートストリーム２は、２Ｍｂｐｓで送信され、５００ｋｂｐｓの平均ビットレートを各々がもつ４つの異なるサービスを含む。時間スライシングの結果として、各サービスは、４分の１の時間に２Ｍｂｐｓの最大ビットレートで送信される。従って、単一のサービスを使用する受信装置は、時間の７５％の最中、ＤＶＢ―Ｈ受信機を不活性にすることができる。このように、時間スライシングは、受信装置の電力消費を低減するために、ＤＶＢ―Ｈにおいて使用されている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
図１に示すように、ＤＶＢ―Ｈストリームにおいて、オーディオ及びビデオ情報は、リアルタイムトランスポートプロトコル（ＲＴＰ）を使用して、それぞれ225.0.0.1:4000及び225.0.0.1:5000と示される別々のストリームを介して（及び特にユーザデータグラムプロトコル（ＵＤＰ）ソケットで）送られる。このプロトコルは、マルチメディアセッションのそれぞれ異なるメディアコンポーネント（例えばビデオ及びオーディオ）が、それぞれ異なるチャネル／ルート（例えばテレビ会議のマイクロホン及びカメラのような異なるソースからおそらく到来する）を介してトランスポートされることができるように、設計される。ＲＴＰを使用する場合、ブロードキャストオーディオ及びビデオストリームが数秒も同期がずれることが起こりうる。
【０００５】
従って、オーディオ及びビデオストリームは、リップシンク問題を回避するために、受信装置において時間的に同期されなければならない。ビデオストリーム及びオーディオストリームの間のわずかなずれでさえ、ユーザによって知覚されることができる。
【０００６】
ＤＶＢ―Ｈブロードキャストに関する２つの別個の同期問題がある。第１の同期問題は、ユーザが受信されるサービスを選択し又は変更する（すなわち、ユーザが、受信装置を起動させ又は図１の「サービス１」から「サービス２」へ切り替える）際に生じる。この場合、受信装置は、新しいサービスに変更して、新しいビデオ及びオーディオストリームを同期させなければならない。この同期には数秒かかることがあり、これは、新しいサービスが提供される前に、ユーザにとって遅延があることを意味する。ビデオ及びオーディオストリームに加えて、同期される必要がある他のコンポーネント（例えばグラフィクス又は字幕）もありうる。
【０００７】
第２の問題は、ビデオストリーム及びオーディオストリームの間の同期が、ある時間にわたってドリフトする可能性がありえ、修正される必要がありうることである。
【０００８】
ＲＴＰにおいて、これらの同期問題は、オーディオ及びビデオストリームに加えて送られるパケットＲＴＰ制御プロトコル（ＲＴＣＰ）センダレポートパケットを使用することにより緩和される。図１に示すように、各ビデオ及びオーディオストリームは、ＲＴＣＰセンダリポートパケットを含むそれぞれのストリームと対にされ、ストリーム225.0.0.1:4001は、ビデオストリーム225.0.0.1:4000に関するＲＴＣＰセンダリポートパケット４を運び、ストリーム225.0.0.1:5001は、オーディオストリーム225.0.0.1:5000に関するＲＴＣＰセンダリポートパケット６を運ぶ。
【０００９】
しかしながら、この図から、ビデオ及びオーディオストリームが最初に受信されると、ストリームが同期されることができるようになる（図１において「同期ポイント」と示される）前に、ＲＴＣＰセンダリポートパケットが、オーディオ及びビデオストリームの各々について受信されるまで待つ必要があることが理解されうる。
【００１０】
ＲＴＣＰ仕様に従うＲＴＣＰセンダリポートパケットの一般的な構造が、図２に示されている。パケットは、使用されるプロトコルのバージョン（Ｖ）、パディングインジケータビット（Ｐ）、パケット内の受信リポートブロックの数（ＲＣ）、パケットタイプ（ＰＴ―すなわちセンダリポートＳＲ）、３２ビットワード内のパケットの長さ、及びセンダリポートパケットのソースのための同期ソース識別子（ＳＳＲＣ）を指定するヘッダセクションを含む。パケットは、更に、６４ビットネットワークタイムプロトコル（ＮＴＰ）タイムスタンプ（本明細書において絶対時間と呼ばれる）、ビデオ又はオーディオストリーム内のＲＴＰデータパケットの最初のオクテットのサンプリング時間を反映するＲＴＰタイムスタンプ、センダリポートの送信までにセンダによって送信されるＲＴＰデータパケットの総数を示すセンダパケットカウント、及びセンダリポートの送信までにセンダによって送信されるペイロードオクテットの総数を示すセンダオクテットカウント、を指定するセンダ情報セクションを含む。
【００１１】
あらゆるＲＴＰデータパケットは、ＲＴＰデータパケット内の最初のオクテットのサンプリング時点から経過した時間を示すＲＴＰタイムスタンプを運ぶ。ＲＴＰタイムスタンプは、通常、特定のメディアストリーム（すなわちビデオ又はオーディオ）に特有であり、タイムスタンプのインクリメントを計数するための個々の始点及び周波数を使用する。従って、異なるオーディオ及びビデオストリームは、ＲＴＰタイムスタンプについて同じ時間ベース（すなわちクロック周波数及び開始オフセット）を使用しないので、それらは直接比較できない。
【００１２】
こうして、あらゆるオーディオ及びビデオＲＴＰストリームは、上述したようにＲＴＣＰパケットを含む個々のストリームと対にされる。図２に示すように、これらのＲＴＣＰセンダリポートパケットは、異なる時間ベースであるが、同じ時間を表現するＮＴＰタイムスタンプ及びＲＴＰタイムスタンプを含む。ＮＴＰタイムスタンプは、それぞれ異なるメディアコンポーネント（例えばオーディオ及びビデオ）の全てについて同一であるので、ストリームのすべてを同期させることは単純明快である。特に、プレゼンテーションタイムスタンプ（ＰＴＳ）が、タイミング情報を使用して各コンポーネントについて計算される。ＰＴＳは、当該データサンプルがバッファから取り出され、復号化され、ユーザに提示される時間を示す。
【００１３】
ＤＶＢ−Ｈアプリケーションにおいて、ＲＴＣＰパケットは５秒ごとに送信されることが推奨される。しかしながら、サービスの変更が行われる場合、これは、次のＲＴＣＰパケットが受け取られる前に最大５秒かかることを意味し、オーディオ及びビデオストリームのＲＴＰタイムスタンプは、タイミング情報を使用して互いに関連付けられることができる。これは、オーディオ及びビデオストリームが、サービスの選択は変更後の最初の最大５秒間は同期があわないことがあることを意味する。
【００１４】
更に、ブロードキャストの間、新しいＲＴＣＰセンダリポートパケットが受け取られ、同期を修正する必要があると判断される場合、調整又は修正は、提示されたオーディオ又はビデオのわずかなジャンプ又はアーチファクトとしてユーザによって知覚されうる。
【００１５】
従って、上述した不利益を克服する、ＤＶＢ−Ｈ仕様に従うブロードキャストに使用される方法及び装置のニーズがある。特に、新しいサービスが選択される際の改善された同期時間を有し、メディアストリームのコンポーネント間の同期の修正が実現される際により滑らかな遷移を提供する方法及び装置のニーズがある。
【課題を解決するための手段】
【００１６】
本発明は、独立請求項によって規定される。従属請求項は、有利な実施形態を規定する。
【００１７】
本発明の第１の見地によれば、ブロードキャストメディアストリームの複数のコンポーネントを同期させる方法であって、ブロードキャストメディアストリームの複数のコンポーネントに関するデータサンプルのストリームをバッファし、複数の情報パケットをバッファするステップであって、複数のコンポーネントの各々に関するデータサンプルのストリームが、相対タイミング情報を含み、各々の情報パケットが、コンポーネント内の相対タイミング情報及び絶対時間の間の関係を示すタイミング情報を含む、ステップと、複数のコンポーネントの各々に関するタイミング情報を抽出するために、バッファされた情報パケットに対してルックアヘッドアクションを実施するステップと、複数のコンポーネントを同期させるために、抽出されたタイミング情報及び相対タイミング情報を使用するステップと、を含む。
【００１８】
一実施例において、各々の情報パケットは、複数のコンポーネントの個々のものに関連付けられ、タイミング情報は、それらの個々のコンポーネント内の相対タイミング情報及び絶対時間の間の関係を示す。
【００１９】
好適には、方法は、複数のコンポーネント内の同期されたデータサンプルをストリーミングするステップを更に含む。
【００２０】
一実施例において、方法は、情報パケットをメモリに記憶するステップと、他の情報パケットが受け取られるまで、複数のコンポーネント内のデータサンプルを同期させるために、メモリに記憶された情報パケット内のタイミング情報を使用するステップと、を更に含む。
【００２１】
この実施形態において、ブロードキャストメディアストリームは、複数の選択可能なサービスを含み、方法は更に、各々の選択可能なサービスのコンポーネントに関する情報パケットを受け取るステップと、メモリに情報パケットを記憶するステップと、を含む。
【００２２】
好適には、複数のコンポーネントに関するデータサンプルのストリームは、ブロードキャストメディアストリームの第１の選択可能なサービスを含み、第２のサービスが選択されるとき、第２のサービスに関する個々の情報パケットが受け取られる前に、第２の選択可能なサービスについて記憶されている情報パケットが、使用される。
【００２３】
好適には、データサンプルは、バーストで受け取られ、情報パケットは、各バーストと共に受け取られる。
【００２４】
好適には、抽出されたタイミング情報及び相対タイミング情報を使用するステップは、同時にストリーミングされるべき複数のコンポーネント内のデータサンプルを決定することを含む。
【００２５】
好適には、方法は更に、複数のコンポーネント間のドリフトを識別するために、同時にストリーミングされるべき決定されたデータサンプルを、同時にストリーミングされるべき以前に決定されたデータサンプルの組と比較するステップと、データサンプルがバッファからストリーミングされるとき、識別されたドリフトを修正するために、特定のコンポーネントからのデータサンプルを付加し又は省くステップと、を更に含む。
【００２６】
この実施形態において、ドリフトを決定するために使用された情報パケットと共に受け取られた１又は複数のデータサンプルが、ストリーミングされる前に、ドリフトが、データサンプルを加え又は省くことによって修正される。
【００２７】
好適には、データサンプルは、既存のデータサンプルを複製することによって加えられる。
【００２８】
好適には、方法は更に、比較のステップの結果をメモリに記憶するステップを含む。
【００２９】
好適には、方法は更に、メモリに記憶された結果から平均的な修正を計算するステップと、特定のコンポーネントについて必要な修正を予測するために、計算された平均的な修正を使用するステップと、を含む。
【００３０】
好適な実施形態において、ブロードキャストメディアストリームは、デジタルビデオブロードキャスティング−ハンドヘルド仕様に従ってブロードキャストされる。
【００３１】
これらの実施形態において、相対タイミング情報は、リアルタイム伝送プロトコル（ＲＴＰ）タイムスタンプを含み、情報パケットは、ＲＴＰ制御プロトコル（ＲＴＣＰ）センダリポートパケットであり、絶対時間は、ネットワークタイムプロトコル（ＮＴＰ）に従って決定される。
【００３２】
好適には、ブロードキャストメディアストリームのコンポーネントは、ビデオ、オーディオ、グラフィクス、字幕及び対話コンテントから選択されるものを含む。
【００３３】
本発明の第２の見地によれば、ユーザにブロードキャストメディアストリームを提示する装置であって、ブロードキャストメディアストリームの複数のコンポーネントに関するデータサンプルのストリーム及び複数の情報パケットを記憶するためのバッファであって、各々のコンポーネントは、ストリーム内のデータサンプルに関する相対タイミング情報を含み、各々の情報パケットは、コンポーネント内の相対タイミング情報と絶対時間との間の関係を示すタイミング情報を含む、バッファと、各コンポーネントに関するバッファされた情報パケットからタイミング情報を抽出するために、ルックアヘッドアクションを実施し、複数のコンポーネントを同期させるために、抽出されたタイミング情報及び相対タイミング情報を使用するように適応されるプロセッサと、を含む。
【００３４】
好適には、装置は更に、抽出されたタイミング情報を記憶するためのメモリを含む。
【００３５】
本発明の第３の見地は、プロセッサによって実行されるとき、上述した方法を実施するように適応されるコンピュータ可読コードを含むコンピュータプログラム製品を提供する。
【００３６】
本発明のこれらの及び他の見地は、以下に記述される実施例から明らかになり、それらを参照して説明される。
【図面の簡単な説明】
【００３７】
【図１】ＤＶＢ−Ｈシステムのブロードキャストの構造を示す図。
【図２】例示のＲＴＣＰセンダリポートパケットの構造を示す図。
【図３】本発明の一実施形態によるモバイル装置のブロック図。
【図４】任意の時点におけるＤＶＢ−Ｈシステムのバッファの内容を示す図。
【図５】本発明の一実施形態による方法を示すフローチャート。
【発明を実施するための形態】
【００３８】
本発明は、図面を参照して単なる例示によって記述される。
【００３９】
本発明は、オーディオ及びビデオコンポーネントを含むブロードキャストメディアストリームに関して記述される。但し、本発明は、以下に限定されないが、字幕、グラフィクス及び対話的コンテントを含むそれぞれ異なる又は付加のコンポーネントを含むメディアストリームに適用可能であることが分かるであろう。
【００４０】
更に、本発明は、以下、ＤＶＢ−Ｈシステムに関して記述されるが、本発明は、エア又はワイヤードインタフェースを通じてサービスを送出するために時間スライシングを使用する他のシステム（非モバイル又は非ポータブル装置用のシステムを含む）にも適用可能であることが分かるであろう。
【００４１】
図３を参照して、本発明の一実施形態によるモバイル装置が示されている。例えばモバイル電話、パーソナルディジタルアシスタント又はポータブルテレビジョン装置のような、ブロードキャストメディアストリームを受信することができる任意の装置でありうるモバイル装置１０は、エアインターフェースを通じてブロードキャストメディアストリームを受け取るためのアンテナ１２及び受信機回路１４を含む。受信機回路１４は、モバイル装置１０の動作を制御するプロセッサ１６に接続される。モバイル装置１０は更に、プロセッサ１６に接続されるバッファ１８を含み、バッファは、到来入力メディアストリームのコンポーネントに関するデータサンプルのパケットを記憶するために使用される。
【００４２】
モバイル装置１０のユーザからコマンドを受け取るユーザインターフェース２０は、スピーカ２２及びディスプレイ２４と共に、プロセッサ１６にも接続される。プロセッサ１６が、バッファ１８からメディアコンポーネントを取り出し復号化するとき、スピーカ２２及びディスプレイ２４は、ユーザにメディアストリームを提示するために使用される。
【００４３】
ある実施形態において、モバイル装置１０は、プロセッサ１６に接続されるメモリ２６を更に有することができる。
【００４４】
従って、複数のコンポーネントを含む到来メディアストリームは、アンテナ１２及び受信機回路１４を使用して、モバイル装置１０によって受け取られ、プロセッサ１６によってバッファ１８に記憶される。モバイル装置１０のユーザにメディアを最初に提示するために（すなわち、装置１０が、最初にスイッチをオンにされるとき、装置１０が、初めてブロードキャストメディアストリームを受け取り始めるとき、又はユーザが視聴するためにブロードキャストメディア装置の新しいサービスを選択するとき）、プロセッサ１６は、オーディオ及びビデオパケットの各々について、どのオーディオパケットが特定のビデオパケットと共にバッファ１８からストリーミングされるべきかを示すために使用されるＮＴＰタイムスタンプを決定し、バッファ１８からのパケットを、モバイル装置１０の適当な出力部（すなわちスピーカ２２又はディスプレイ２４）にストリーミングする。プレゼンテーションの実時間（すなわち、パケットがバッファ１８からストリーミングされる時間）は、プロセッサ１６によってプレゼンテーションタイムスタンプ（ＰＴＳ）から決定されることができ、又は単にビデオストリームのフレームレート（すなわち、毎秒特定のフレーム数のビデオデータをストリーミングする）を考慮に入れてプロセッサ１６によって決定されることができる。
【００４５】
モバイル装置がモバイル電話である場合、受信機回路１４は、トランシーバ回路と置き換えられることができ、又は別個の送信機回路が、通信ネットワークとのアップリンク通信のために設けられる。
【００４６】
更に、ある実施形態において、受信機回路１４は、プロセッサ１６を通過することなく、受信されたメディアストリームをバッファ１８へ直接に供給することができることが分かるであろう。
【００４７】
図４は、任意の時点におけるＤＶＢ−Ｈシステムのバッファ１８の内容を示す。この図において、バッファ１８へストリーミングされるデータサンプルは、左側から到来し、バッファ１８から（ストリーミングポイントから）スピーカ２２又はディスプレイ２４へストリーミングされるデータサンプルは、右へ行く。メディアストリームは、この例では、２つのコンポーネント、すなわちビデオ及びオーディオ、を含むので、バッファ１８は、２つのセクションに効果的に分割されており、（図４の上半分に示される）第１の部分は、ビデオデータサンプルを記憶し、（図４の下半分に示される）第２の部分は、オーディオデータサンプルを記憶する。
【００４８】
各時間スライス又はバーストの間に受け取られる各コンポーネントに関するデータサンプルが、バッファ１８に示されている。上述したように、データサンプルは、メディアストリームのコンポーネントのソースによって生成され、サンプルは、タイムスタンプを付される。しかしながら、各コンポーネントは、タイムスタンプに関するそれぞれ異なるベースを使用し、従って、異なるコンポーネントのタイムスタンプは、直接比較できない。
【００４９】
従って、各コンポーネントは、データチャネルと同時にブロードキャストされる個々のチャネルを伴い、チャネルは、コンポーネント内の相対タイムスタンプ及び絶対時間の間の関係を示すタイミング情報を含む情報パケット４、６を含む。これらの情報パケット４、６は、図４に示されるようにバッファに記憶される。
【００５０】
ＤＶＢ−Ｈシステムにおいて、データサンプルは、リアルタイム伝送プロトコル（ＲＴＰ）を使用してブロードキャストされ、それゆえ、ＲＴＰタイムスタンプを含む。更に、情報パケットは、ＲＴＣＰセンダリポートであり、タイミング情報は、ＲＴＰタイムスタンプと絶対時間（すなわちＮＴＰ時間）との間の関係を示す。
【００５１】
通常、情報パケット４、６は、それらがそれらの個々のオーディオ及びビデオストリームと共にバッファ１８からストリーミングされるとき、プロセッサ１６又は他のメディアプレーヤによって読み取られる（すなわち、それらは、ストリーミングポイントが個々の情報パケットに達すると読み取られる）。
【００５２】
しかしながら、本発明によれば、プロセッサ１６は、バッファ１８にすでに記憶されている任意の「将来の」情報パケットについて、ルックアヘッドアクションを実施することが可能であり、これは、バッファ１８内の現在ストリーミングポイント（すなわちデータサンプルが現在ストリーミングされている当該ストリーミングポイント）より先行するようにみえることを意味する。言い換えると、プロセッサ１６は、バッファ１８内にある情報パケットがデータサンプルと共にバッファ１８からストリーミング出力されるのを待つのではなく、それらの情報パケットを調べる。代替例として、ルックアヘッドアクションは、情報パケットが受信機回路１４によって受け取られるとき（すなわち、それらがバッファ１８に記憶される前に）、プロセッサ１６に情報パケットを調べさせることができる。
【００５３】
データサンプルは、プロセッサ１６内のコンポーネント復号器がそれらを使用することができるようになるよりもずっと速く特定の時間スライスに受け取られるので、プロセッサ１６によるこの「ルックアヘッド」アクションは、ブロードキャストメディアストリームの時間スライシング構造により、可能である。
【００５４】
図５は、本発明の１つの見地によるモバイル装置の動作を示すフローチャートである。
【００５５】
ステップ１０１において、ブロードキャストメディアストリームの複数のコンポーネントに関するデータサンプルが、受け取られ、バッファ１８に記憶される。コンポーネントの各々は、ストリーム内のデータサンプルに関する相対タイムスタンプを含む。
【００５６】
ステップ１０３において、各コンポーネントについて個々の情報パケットが、受け取られ、バッファ１８に記憶される。各情報パケットは、それらの個々のコンポーネント内の相対タイムスタンプと絶対時間との間の関係を示すタイミング情報を含む。
【００５７】
ステップ１０５において、プロセッサ１６は、バッファ１８に対するルックアヘッドアクションを実施し、受け取られた情報パケットから、タイミング情報を抽出する。代替例として、情報パケットが受信機回路１４によって受け取られるとき、プロセッサ１６は、タイミング情報を読み取ることもできる。その結果、情報パケットと同時に受け取られたデータサンプルが、バッファ１８からストリーミングされるよりも前に、タイミング情報が、情報パケットから抽出される。情報パケットが、間欠的に受け取られるとき、プロセッサ１６は、ルックアヘッドアクションを周期的に繰り返すことができる。
【００５８】
ステップ１０７において、プロセッサ１６は、コンポーネント内のデータサンプルの相対タイムスタンプを絶対時間と関連づけるために、識別されたタイミング情報を使用する。異なるデータストリームからのサンプルは、ここで、共通の時間ベースを有するので、プロセッサ１６は、１つのコンポーネント内のどのサンプルが別のコンポーネント内のどのサンプルと共にストリーミングされるべきかを決定することによって、コンポーネントを同期させることができる。
【００５９】
最後に、ステップ１０９において、コンポーネント内の同期されたデータサンプルが、バッファ１８からストリーミングされる。
【００６０】
データストリーミングシステムの性質により（すなわち、データが、（バースト送信の場合）周期的に受け取られ、ユーザに連続的にストリーミングされる）、この方法におけるステップの各々は、メディアストリームのそれぞれ異なる部分についてであるが、モバイル装置１０によってほぼ同時に実施されていることが分かるであろう。例えば、ステップ１０１及び１０３は、特定のバーストについてほぼ同時に行われ（それゆえ、フローチャートに横に並んで示されている）、プロセッサ１６は、ブロードキャストメディアストリーム内のより早いものからのデータサンプルを、ユーザにストリーミングする。
【００６１】
従って、装置１０が、最初にオンにされるとき、装置１０が、最初にブロードキャストメディアストリームを受け取り始めるとき、又はユーザが、ブロードキャストメディアストリームの新しいサービスを選択するとき、上述の方法は、複数のコンポーネントが、通常の方法より非常に速く同期されることを可能にする。実際、情報パケット（ＲＴＣＰセンダリポート）が第１のバーストにおいて利用可能である場合、同期は、サービス変更が行われるとほとんどすぐに実現されることができる。
【００６２】
更に、上述の方法を使用することによって、複数のコンポーネントが従来の方法より早く同期し直される必要があるかどうか（すなわち、コンポーネント間のタイミングがドリフトしているかどうか）を判定することが可能である。更に、以下に一層詳しく記述されるように、必要とされる同期修正の早期の検出は、修正が、従来の方法のように特定の時点に実現されるのではなく、短い時間期間（すなわち複数のフレーム）にわたって実現されることを可能にする。このようにして、ユーザ知覚できるアーチファクトが低減される。
【００６３】
これらの２つの実現例の更なる詳細が、以下に与えられる。
【００６４】
新しいサービスのコンポーネントの同期
従って、装置１０が最初にオンにされるとき、装置１０が最初にブロードキャストメディアストリームを受け取り始めるとき、又はユーザが、ブロードキャストメディアの新しいサービスを選択するとき、装置１０は、第１の選択されたバーストを受け取り、バッファ１８にデータサンプル及びＲＴＣＰセンダリポートパケットを記憶する。
【００６５】
プロセッサ１６は、バッファ１８から、受け取ったメディアコンポーネントを消費（すなわちストリーミング）し始めることができるが、すべての必要なメディアコンポーネントの利用可能なＲＴＣＰパケットがあるかどうかバッファ１８の残りの部分を調べるために、ルックアヘッドアクションを同時に実施することができる。
【００６６】
このようなＲＴＣＰパケットが、それぞれ異なるメディアコンポーネントの少なくとも２つに関して見つけられる場合、データサンプルストリーム内の個別のコンポーネントＲＴＰタイムスタンプは、ＲＴＰタイムスタンプをＮＴＰ時間にリンクするＲＴＣＰセンダリポートパケット内のタイミング情報を使用して、１つの絶対時間ベースに変換されることができる。特に、ＲＴＣＰセンダリポートパケットは、ＲＴＰデータパケット内の最初のオクテットのサンプリング時点に関するＲＴＰタイムスタンプ及び対応するＮＴＰタイムスタンプを含むので、（この第１のサンプリング時点から正確に計られた）ＲＴＰデータパケット内のＲＴＰタイムスタンプは、ＮＴＰ時間に関連付けられることができる。
【００６７】
タイミング情報は、各々のＲＴＣＰパケットの間で変わらないので、より早い及びより遅いＲＴＣＰセンダリポートパケットからのタイミング情報が、ＲＴＰデータストリームのデータサンプルに有効である。
【００６８】
従って、ＲＴＣＰセンダリポートパケットは、時間的により遅くに受け取られるが、複数のコンポーネント間の同期は、パケットが受け取られるとすぐに確立されることができる。
【００６９】
特に、以下の計算は、本発明が複数のコンポーネントの同期を達成する際に従来の方法を超えて提供する改善を示す。以下、新しいサービスが、当該サービスのバーストとバーストの間に選択されるものとする（すなわち、当該サービスのバーストは、サービス切り替えが行われるときには送信されない）。
【００７０】
ＲＴＣＰセンダリポートパケットが、（今日の標準において勧告されるように）メディアストリーム内の各コンポーネントについて５秒毎に送信され、ストリームが、２秒の時間スライシングサイクルを有するものとすると、同期を達成するために必要とされる最大時間は７秒であり、これは、正しい時間スライスを待つ２秒と、ＲＴＣＰセンダレポートパケットを待つ５秒と、を含む。平均して、同期を達成するために３．５秒かかり、これは、正しい時間スライスを待つ１秒と、ＲＴＣＰパケットを待つ２．５秒と、を含む。
【００７１】
しかしながら、本発明による方法を使用する場合、同期を達成するための最大時間は６秒であり、これは、正しい時間スライスを待つ２秒と、（現在時間スライスがＲＴＣＰパケットを含まない場合）次の時間スライスを待つ２秒と、次の時間スライスがなおＲＴＣＰパケットを含まない場合の更なる２秒と、ＲＴＣＰパケットはそれが受け取られるとほぼすぐに読み取られることができるという理由で０秒と、を含む。同期を達成する平均時間は２．６秒であり、これは、時間スライスを待つ１秒と、ＲＴＣＰパケットがこの時間スライス内にある（ゆえに０秒の更なる待ち時間を必要とする）４０％の可能性と、ＲＴＣＰパケットが次の時間スライス内にある４０％の可能性（ゆえに更なる２秒の待ち時間を必要とする）と、ＲＴＣＰパケットが最後の時間スライス内にある２０％の可能性（ゆえに更なる４秒の待ち時間を必要とする）と、を含む。
【００７２】
本発明の好適な実施形態において、同期時間は、データサンプルの各バーストと共にＲＴＣＰタイムスタンプを送信することによって、一層改善されることができる。従って、別のバーストを待つ結果としての遅延が回避される。
【００７３】
特に、ＲＴＣＰパケットが、時間スライス毎（従って２秒毎）に送信される場合、従来の方法を使用してコンポーネントを同期させるための最大時間は４秒であり、これは、時間スライスを待つ２秒と、ＲＴＣＰパケットを待つ２秒と、を含む。コンポーネントを同期させるためにかかる平均時間は２秒であり、これは、時間スライスを待つ１秒と、ＲＴＣＰパケットを待つ１秒と、を含む。
【００７４】
しかしながら、あらゆる時間スライスにＲＴＣＰパケットに関して上述の方法を使用することは、２秒の最大の同期時間を生じさせ、これは、時間スライスを待つ２秒を含む。平均持続時間は１秒であり、これは、時間スライスを待つ１秒である。
【００７５】
複数のコンポーネントを同期させるためにかかる時間の更なる改善は、メモリ２６の履歴テーブルに、各サービスについて受け取られたタイミング情報を記憶することによって得られることができる。ＲＴＣＰセンダリポートパケット内の相対値は、ある時間にわたって変化すべきでないので、記憶されたパケットは、ユーザがそのサービスに切り替えをする際に使用されることができる。
【００７６】
この履歴テーブルは、いくつかのやり方でデータを入れられることができる。最初に、装置１０が活性化されると、装置１０は、ブロードキャストのすべてのサービスに関する時間スライスを受け取る必要がある。プロセッサ１６は、すべてのＲＴＣＰパケットについてこれらの時間スライスを探すことができ、メモリ２６にこれらを記憶することができる。
【００７７】
第２に、装置１０は、メモリ２６の各サービスのタイミング情報をリフレッシュするために、周期的な更新を実施することができる。
【００７８】
第３に、通常のサービス受信の間、装置１０は、現在消費されているサービスのＲＴＣＰパケットをキャッシュすることができる。しばらくしてから、ユーザがこのサービスに戻ってくる場合、ＲＴＣＰ情報は、メモリ２６内ですでに利用可能である。このようにして、装置１０が、新しいサービスに最初にスイッチされるときにのみ、同期の遅れがある。
【００７９】
従って、新しく選択されたサービスの最初の時間スライスにＲＴＣＰセンダリポートがない場合、キャッシュされたタイミング情報が、複数のコンポーネントを同期させるために使用されることができる。
【００８０】
これらのケースのいずれにおいても、可能性は低いが、相対タイミングが変化している可能性がある場合、プロセッサ１６が、メディアストリーム内のコンポーネント間の大きなタイミング差（例えば数秒又はより長い秒のオーダーの差）があるのを検出することはかなり容易であり、プロセッサ１６は、このテストに失敗する任意のキャッシュされた情報を無視することができる。
【００８１】
キャッシュされた情報が今もなお有効であうかどうか判定するための更なるチェックが、キャッシュされた情報について行われることができる。更に、メモリ２６にＲＴＣＰパケットをキャッシュすることに加えて、ＲＴＣＰパケットが受け取られるポイントに対応する絶対時間及びＲＴＣＰパケットの近くで受け取られるＲＴＰパケットのプレゼンテーションタイムスタンプをキャッシュすることも可能である。従って、ＲＴＰパケットのプレゼンテーションタイムスタンプが、キャッシュされた情報を用いて計算される場合、結果として得られるプレゼンテーションタイムスタンプは、キャッシュの時間とキャッシュの時点のプレゼンテーションタイムスタンプとの間の絶対時間差に近いものであるべきである。そうでない場合、キャッシュに保持される情報は、おそらく無効であり、プロセッサ１６は、新しいＲＴＣＰパケットを待つべきである。
【００８２】
既存のサービスのコンポーネント間の同期の修正
上述したように、サービス内の複数のコンポーネント間の同期が、ある時間にわたってドリフトする場合、本発明による方法は、この同期ドリフトが従来の方法よりも早く判定されることを可能にする。
【００８３】
同期ドリフトのこの早期の検出の結果として、同期修正は、従来の方法のように特定の時点に行われるのではなく、短い時間期間（すなわち多くのフレーム）にわたって行われることができる。
【００８４】
特に、同期修正は、（ビデオコンポーネントが他のコンポーネントに時間的に先行している場合）ビデオフレームを落とす（ドロップする）ことによって、及び／又は（オーディオコンポーネントが他のコンポーネントに時間的に先行している場合）オーディオサンプルを落とすことによって、実現されることができる。
【００８５】
モバイル装置１０は、各ストリームと共に送られた第１のＲＴＣＰセンダリポートパケットを使用してＲＴＰ送信のそれぞれ異なるメディアコンポーネントを同期させたのち、各々のコンポーネントストリームについて他のＲＴＣＰ情報パケットを受け取ることを続ける。本発明によれば、モバイル装置１０は、バッファ１８内のＲＴＣＰパケットに対してルックアヘッド動作を実施する。言い換えると、モバイル装置１０は、対応するデータサンプルと共にバッファからストリーミングされるＲＴＣＰパケットを待つのではなく、それが装置１０に利用可能になるとすぐに、ＲＴＣＰパケット内のタイミング情報を抽出する。
【００８６】
このようなＲＴＣＰパケットが見つけられるとすぐに、プロセッサ１６は、相対タイムスタンプを絶対時間と関連づけ、通常通り、それぞれ異なるメディアコンポーネントのプレゼンテーションタイムスタンプを計算する。これから、プロセッサ１６は、１つのコンポーネントからのどのサンプルが、他のコンポーネントからの特定のサンプルと共にストリーミングされるべきかを判定し、これを、現在ストリーミングされているデータサンプル対と比較する。これらのサンプル対が、現在ストリーミングされているものと異なる場合、ドリフトが生じており、従って、プロセッサ１６は、１又は複数の特定のコンポーネントがどれくらい調整される必要があるか、及びこのドリフトが修正されるべきであるポイント、を判定する。ドリフトが通常修正される時間は、ＲＴＣＰパケットがバッファ１８から読み取られる時間である。
【００８７】
プロセッサ１６は、ＲＴＣＰパケットがバッファ１８から読み取られる前に、コンポーネントを同期させるために、各々のコンポーネントが（又はどのコンポーネントが）どれくらい調整される必要があるかを判定するために、決定された調整量及び通常の修正時間を使用する。
【００８８】
プロセッサ１６は、（ビデオストリームがオーディオストリームに先行している又は遅れている場合）ビデオフレームを付加し又は省くことによって、又は（オーディオストリームがビデオストリームに先行している又は遅れている場合）オーディオサンプルを付加し又は省くことによって、オーディオ及びビデオストリームの間の同期ドリフトを修正することができる。フレーム又はサンプルは、既存のフレーム又はサンプルを繰り返すことによって、付加されることができる。
【００８９】
好適には、プロセッサ１６は、バッファ１８からＲＴＣＰパケットを読み取る前に、ある時間期間にわたってフレーム又はサンプルの付加又は省略を配置することによって、同期ドリフトを修正し、よって、再同期の際に、いかなるユーザ知覚可能なアーチファクトもあるべきでない。
【００９０】
再同期が行われるたびに、再同期に関する情報が、メモリ２６の履歴テーブルに記憶されることができる。プロセッサ１６は、フレーム又はオーディオタイミングの行われた全体の平均的な調整を計算するために、このテーブル内の情報を使用することができる。この情報によって、プロセッサ１６は、受け取られるＲＴＣＰパケットに先立って、再同期を予測することができ、当該ＲＴＣＰパケットがバッファ１８から読み取られるよりかなり前に、再同期が実現されることを確実にする。このようにして、再同期は、より大きいタイムスケールにわたって実現されることができ、これは、フレーム又はオーディオサンプルの付加又は省略がより離れて拡散されることができるので、遷移がなお一層滑らかに行われることができることを意味する。
【００９１】
ＲＴＣＰパケットがバッファ１８から読み取られるとき、その中のタイミング情報が、コンポーネントの同期が正しく調整されたことを確認するために使用されることができる。
【００９２】
更に、本発明のこの実施例は、送信のソースにおいて特別なＲＴＣＰパケットを導入することによって、非時間スライシング送信に適用されることができる。このパケットは、同期情報及びこの情報がいつ作用されるべきかを示すタイムスタンプを含むことができる。わずかな再同期が期待される場合、このパケットは、送信のソースによって、時間的に先立って生成され、送られることができる。このようにして、この特別なＲＴＣＰパケットが受け取られる場合、装置は、ある時間期間にわたって同期を円滑に調整することができる。
【００９３】
従って、新しいサービスが選択される場合に改善された同期時間を有するとともに、メディアストリームのコンポーネント間の同期の修正が実現される場合に一層滑らかな遷移を供給する方法及び装置が提供される。
【００９４】
本発明は、図面及び前述の記述に詳しく図示され記述されているが、このような図示及び記述は、制限的なものではなく、説明的又は例示的なものであると考えられることができる。本発明は、開示された実施形態に制限されない。
【００９５】
開示された実施形態に対する変更は、図面、開示及び添付の請求項の検討から、請求項に記載された本発明を実施する際に当業者によって理解されることができ、実現されることができる。本発明は、いくつかの個別の構成要素を含むハードウェアによって、及び／又は適切にプログラムされたプロセッサによって、実現されることができる。請求項において、「含む、有する」という語は、他の構成要素又はステップを除外せず、不定冠詞「a」又は「an」は、複数性を除外しない。単一のプロセッサ又は他のユニットが、請求項に列挙されるいくつかのアイテムの機能を果たすことができる。特定の手段が相互に異なる従属請求項に列挙されているという単なる事実は、これらの手段の組み合わせが有利に使用されることができないことを示さない。請求項におけるいかなる参照符号も、範囲を制限するものとして解釈されるべきでない。コンピュータプログラムは、例えば他のハードウェアと共に又はその一部として供給される光学記憶媒体又はソリッドステート媒体のような適切な媒体に記憶され／分散されることができるが、例えばインターネット又は他のワイヤード又はワイヤレス通信システムを介するように、他の形態で分散されることもできる。
【技術分野】
【０００１】
本発明は、オーディオ及びビデオのようなメディアストリームのコンポーネントの同期に関し、具体的には、デジタルビデオブロードキャスティング−ハンドヘルド（ＤＶＢ―Ｈ）システムにおけるコンポーネントの同期に関する。
【背景技術】
【０００２】
デジタルビデオブロードキャスティング−ハンドヘルド（ＤＶＢ―Ｈ）は、テレビジョン放送及び他のビデオ及びオーディオストリームを、持ち運び可能な（モバイル）又はハンドヘルドの装置に提供するための標準である。
【０００３】
ＤＶＢ―Ｈにおいて、時間スライスが使用されており、これは、それぞれ異なるサービス（すなわち異なるＴＶチャンネル）が、個々の時間「スライス」又はバーストで送信されることを意味する。図１は、例示のＤＶＢ―Ｈ送信構造を示す。この例では、ＤＶＢ―Ｈトランスポートストリーム２は、２Ｍｂｐｓで送信され、５００ｋｂｐｓの平均ビットレートを各々がもつ４つの異なるサービスを含む。時間スライシングの結果として、各サービスは、４分の１の時間に２Ｍｂｐｓの最大ビットレートで送信される。従って、単一のサービスを使用する受信装置は、時間の７５％の最中、ＤＶＢ―Ｈ受信機を不活性にすることができる。このように、時間スライシングは、受信装置の電力消費を低減するために、ＤＶＢ―Ｈにおいて使用されている。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
図１に示すように、ＤＶＢ―Ｈストリームにおいて、オーディオ及びビデオ情報は、リアルタイムトランスポートプロトコル（ＲＴＰ）を使用して、それぞれ225.0.0.1:4000及び225.0.0.1:5000と示される別々のストリームを介して（及び特にユーザデータグラムプロトコル（ＵＤＰ）ソケットで）送られる。このプロトコルは、マルチメディアセッションのそれぞれ異なるメディアコンポーネント（例えばビデオ及びオーディオ）が、それぞれ異なるチャネル／ルート（例えばテレビ会議のマイクロホン及びカメラのような異なるソースからおそらく到来する）を介してトランスポートされることができるように、設計される。ＲＴＰを使用する場合、ブロードキャストオーディオ及びビデオストリームが数秒も同期がずれることが起こりうる。
【０００５】
従って、オーディオ及びビデオストリームは、リップシンク問題を回避するために、受信装置において時間的に同期されなければならない。ビデオストリーム及びオーディオストリームの間のわずかなずれでさえ、ユーザによって知覚されることができる。
【０００６】
ＤＶＢ―Ｈブロードキャストに関する２つの別個の同期問題がある。第１の同期問題は、ユーザが受信されるサービスを選択し又は変更する（すなわち、ユーザが、受信装置を起動させ又は図１の「サービス１」から「サービス２」へ切り替える）際に生じる。この場合、受信装置は、新しいサービスに変更して、新しいビデオ及びオーディオストリームを同期させなければならない。この同期には数秒かかることがあり、これは、新しいサービスが提供される前に、ユーザにとって遅延があることを意味する。ビデオ及びオーディオストリームに加えて、同期される必要がある他のコンポーネント（例えばグラフィクス又は字幕）もありうる。
【０００７】
第２の問題は、ビデオストリーム及びオーディオストリームの間の同期が、ある時間にわたってドリフトする可能性がありえ、修正される必要がありうることである。
【０００８】
ＲＴＰにおいて、これらの同期問題は、オーディオ及びビデオストリームに加えて送られるパケットＲＴＰ制御プロトコル（ＲＴＣＰ）センダレポートパケットを使用することにより緩和される。図１に示すように、各ビデオ及びオーディオストリームは、ＲＴＣＰセンダリポートパケットを含むそれぞれのストリームと対にされ、ストリーム225.0.0.1:4001は、ビデオストリーム225.0.0.1:4000に関するＲＴＣＰセンダリポートパケット４を運び、ストリーム225.0.0.1:5001は、オーディオストリーム225.0.0.1:5000に関するＲＴＣＰセンダリポートパケット６を運ぶ。
【０００９】
しかしながら、この図から、ビデオ及びオーディオストリームが最初に受信されると、ストリームが同期されることができるようになる（図１において「同期ポイント」と示される）前に、ＲＴＣＰセンダリポートパケットが、オーディオ及びビデオストリームの各々について受信されるまで待つ必要があることが理解されうる。
【００１０】
ＲＴＣＰ仕様に従うＲＴＣＰセンダリポートパケットの一般的な構造が、図２に示されている。パケットは、使用されるプロトコルのバージョン（Ｖ）、パディングインジケータビット（Ｐ）、パケット内の受信リポートブロックの数（ＲＣ）、パケットタイプ（ＰＴ―すなわちセンダリポートＳＲ）、３２ビットワード内のパケットの長さ、及びセンダリポートパケットのソースのための同期ソース識別子（ＳＳＲＣ）を指定するヘッダセクションを含む。パケットは、更に、６４ビットネットワークタイムプロトコル（ＮＴＰ）タイムスタンプ（本明細書において絶対時間と呼ばれる）、ビデオ又はオーディオストリーム内のＲＴＰデータパケットの最初のオクテットのサンプリング時間を反映するＲＴＰタイムスタンプ、センダリポートの送信までにセンダによって送信されるＲＴＰデータパケットの総数を示すセンダパケットカウント、及びセンダリポートの送信までにセンダによって送信されるペイロードオクテットの総数を示すセンダオクテットカウント、を指定するセンダ情報セクションを含む。
【００１１】
あらゆるＲＴＰデータパケットは、ＲＴＰデータパケット内の最初のオクテットのサンプリング時点から経過した時間を示すＲＴＰタイムスタンプを運ぶ。ＲＴＰタイムスタンプは、通常、特定のメディアストリーム（すなわちビデオ又はオーディオ）に特有であり、タイムスタンプのインクリメントを計数するための個々の始点及び周波数を使用する。従って、異なるオーディオ及びビデオストリームは、ＲＴＰタイムスタンプについて同じ時間ベース（すなわちクロック周波数及び開始オフセット）を使用しないので、それらは直接比較できない。
【００１２】
こうして、あらゆるオーディオ及びビデオＲＴＰストリームは、上述したようにＲＴＣＰパケットを含む個々のストリームと対にされる。図２に示すように、これらのＲＴＣＰセンダリポートパケットは、異なる時間ベースであるが、同じ時間を表現するＮＴＰタイムスタンプ及びＲＴＰタイムスタンプを含む。ＮＴＰタイムスタンプは、それぞれ異なるメディアコンポーネント（例えばオーディオ及びビデオ）の全てについて同一であるので、ストリームのすべてを同期させることは単純明快である。特に、プレゼンテーションタイムスタンプ（ＰＴＳ）が、タイミング情報を使用して各コンポーネントについて計算される。ＰＴＳは、当該データサンプルがバッファから取り出され、復号化され、ユーザに提示される時間を示す。
【００１３】
ＤＶＢ−Ｈアプリケーションにおいて、ＲＴＣＰパケットは５秒ごとに送信されることが推奨される。しかしながら、サービスの変更が行われる場合、これは、次のＲＴＣＰパケットが受け取られる前に最大５秒かかることを意味し、オーディオ及びビデオストリームのＲＴＰタイムスタンプは、タイミング情報を使用して互いに関連付けられることができる。これは、オーディオ及びビデオストリームが、サービスの選択は変更後の最初の最大５秒間は同期があわないことがあることを意味する。
【００１４】
更に、ブロードキャストの間、新しいＲＴＣＰセンダリポートパケットが受け取られ、同期を修正する必要があると判断される場合、調整又は修正は、提示されたオーディオ又はビデオのわずかなジャンプ又はアーチファクトとしてユーザによって知覚されうる。
【００１５】
従って、上述した不利益を克服する、ＤＶＢ−Ｈ仕様に従うブロードキャストに使用される方法及び装置のニーズがある。特に、新しいサービスが選択される際の改善された同期時間を有し、メディアストリームのコンポーネント間の同期の修正が実現される際により滑らかな遷移を提供する方法及び装置のニーズがある。
【課題を解決するための手段】
【００１６】
本発明は、独立請求項によって規定される。従属請求項は、有利な実施形態を規定する。
【００１７】
本発明の第１の見地によれば、ブロードキャストメディアストリームの複数のコンポーネントを同期させる方法であって、ブロードキャストメディアストリームの複数のコンポーネントに関するデータサンプルのストリームをバッファし、複数の情報パケットをバッファするステップであって、複数のコンポーネントの各々に関するデータサンプルのストリームが、相対タイミング情報を含み、各々の情報パケットが、コンポーネント内の相対タイミング情報及び絶対時間の間の関係を示すタイミング情報を含む、ステップと、複数のコンポーネントの各々に関するタイミング情報を抽出するために、バッファされた情報パケットに対してルックアヘッドアクションを実施するステップと、複数のコンポーネントを同期させるために、抽出されたタイミング情報及び相対タイミング情報を使用するステップと、を含む。
【００１８】
一実施例において、各々の情報パケットは、複数のコンポーネントの個々のものに関連付けられ、タイミング情報は、それらの個々のコンポーネント内の相対タイミング情報及び絶対時間の間の関係を示す。
【００１９】
好適には、方法は、複数のコンポーネント内の同期されたデータサンプルをストリーミングするステップを更に含む。
【００２０】
一実施例において、方法は、情報パケットをメモリに記憶するステップと、他の情報パケットが受け取られるまで、複数のコンポーネント内のデータサンプルを同期させるために、メモリに記憶された情報パケット内のタイミング情報を使用するステップと、を更に含む。
【００２１】
この実施形態において、ブロードキャストメディアストリームは、複数の選択可能なサービスを含み、方法は更に、各々の選択可能なサービスのコンポーネントに関する情報パケットを受け取るステップと、メモリに情報パケットを記憶するステップと、を含む。
【００２２】
好適には、複数のコンポーネントに関するデータサンプルのストリームは、ブロードキャストメディアストリームの第１の選択可能なサービスを含み、第２のサービスが選択されるとき、第２のサービスに関する個々の情報パケットが受け取られる前に、第２の選択可能なサービスについて記憶されている情報パケットが、使用される。
【００２３】
好適には、データサンプルは、バーストで受け取られ、情報パケットは、各バーストと共に受け取られる。
【００２４】
好適には、抽出されたタイミング情報及び相対タイミング情報を使用するステップは、同時にストリーミングされるべき複数のコンポーネント内のデータサンプルを決定することを含む。
【００２５】
好適には、方法は更に、複数のコンポーネント間のドリフトを識別するために、同時にストリーミングされるべき決定されたデータサンプルを、同時にストリーミングされるべき以前に決定されたデータサンプルの組と比較するステップと、データサンプルがバッファからストリーミングされるとき、識別されたドリフトを修正するために、特定のコンポーネントからのデータサンプルを付加し又は省くステップと、を更に含む。
【００２６】
この実施形態において、ドリフトを決定するために使用された情報パケットと共に受け取られた１又は複数のデータサンプルが、ストリーミングされる前に、ドリフトが、データサンプルを加え又は省くことによって修正される。
【００２７】
好適には、データサンプルは、既存のデータサンプルを複製することによって加えられる。
【００２８】
好適には、方法は更に、比較のステップの結果をメモリに記憶するステップを含む。
【００２９】
好適には、方法は更に、メモリに記憶された結果から平均的な修正を計算するステップと、特定のコンポーネントについて必要な修正を予測するために、計算された平均的な修正を使用するステップと、を含む。
【００３０】
好適な実施形態において、ブロードキャストメディアストリームは、デジタルビデオブロードキャスティング−ハンドヘルド仕様に従ってブロードキャストされる。
【００３１】
これらの実施形態において、相対タイミング情報は、リアルタイム伝送プロトコル（ＲＴＰ）タイムスタンプを含み、情報パケットは、ＲＴＰ制御プロトコル（ＲＴＣＰ）センダリポートパケットであり、絶対時間は、ネットワークタイムプロトコル（ＮＴＰ）に従って決定される。
【００３２】
好適には、ブロードキャストメディアストリームのコンポーネントは、ビデオ、オーディオ、グラフィクス、字幕及び対話コンテントから選択されるものを含む。
【００３３】
本発明の第２の見地によれば、ユーザにブロードキャストメディアストリームを提示する装置であって、ブロードキャストメディアストリームの複数のコンポーネントに関するデータサンプルのストリーム及び複数の情報パケットを記憶するためのバッファであって、各々のコンポーネントは、ストリーム内のデータサンプルに関する相対タイミング情報を含み、各々の情報パケットは、コンポーネント内の相対タイミング情報と絶対時間との間の関係を示すタイミング情報を含む、バッファと、各コンポーネントに関するバッファされた情報パケットからタイミング情報を抽出するために、ルックアヘッドアクションを実施し、複数のコンポーネントを同期させるために、抽出されたタイミング情報及び相対タイミング情報を使用するように適応されるプロセッサと、を含む。
【００３４】
好適には、装置は更に、抽出されたタイミング情報を記憶するためのメモリを含む。
【００３５】
本発明の第３の見地は、プロセッサによって実行されるとき、上述した方法を実施するように適応されるコンピュータ可読コードを含むコンピュータプログラム製品を提供する。
【００３６】
本発明のこれらの及び他の見地は、以下に記述される実施例から明らかになり、それらを参照して説明される。
【図面の簡単な説明】
【００３７】
【図１】ＤＶＢ−Ｈシステムのブロードキャストの構造を示す図。
【図２】例示のＲＴＣＰセンダリポートパケットの構造を示す図。
【図３】本発明の一実施形態によるモバイル装置のブロック図。
【図４】任意の時点におけるＤＶＢ−Ｈシステムのバッファの内容を示す図。
【図５】本発明の一実施形態による方法を示すフローチャート。
【発明を実施するための形態】
【００３８】
本発明は、図面を参照して単なる例示によって記述される。
【００３９】
本発明は、オーディオ及びビデオコンポーネントを含むブロードキャストメディアストリームに関して記述される。但し、本発明は、以下に限定されないが、字幕、グラフィクス及び対話的コンテントを含むそれぞれ異なる又は付加のコンポーネントを含むメディアストリームに適用可能であることが分かるであろう。
【００４０】
更に、本発明は、以下、ＤＶＢ−Ｈシステムに関して記述されるが、本発明は、エア又はワイヤードインタフェースを通じてサービスを送出するために時間スライシングを使用する他のシステム（非モバイル又は非ポータブル装置用のシステムを含む）にも適用可能であることが分かるであろう。
【００４１】
図３を参照して、本発明の一実施形態によるモバイル装置が示されている。例えばモバイル電話、パーソナルディジタルアシスタント又はポータブルテレビジョン装置のような、ブロードキャストメディアストリームを受信することができる任意の装置でありうるモバイル装置１０は、エアインターフェースを通じてブロードキャストメディアストリームを受け取るためのアンテナ１２及び受信機回路１４を含む。受信機回路１４は、モバイル装置１０の動作を制御するプロセッサ１６に接続される。モバイル装置１０は更に、プロセッサ１６に接続されるバッファ１８を含み、バッファは、到来入力メディアストリームのコンポーネントに関するデータサンプルのパケットを記憶するために使用される。
【００４２】
モバイル装置１０のユーザからコマンドを受け取るユーザインターフェース２０は、スピーカ２２及びディスプレイ２４と共に、プロセッサ１６にも接続される。プロセッサ１６が、バッファ１８からメディアコンポーネントを取り出し復号化するとき、スピーカ２２及びディスプレイ２４は、ユーザにメディアストリームを提示するために使用される。
【００４３】
ある実施形態において、モバイル装置１０は、プロセッサ１６に接続されるメモリ２６を更に有することができる。
【００４４】
従って、複数のコンポーネントを含む到来メディアストリームは、アンテナ１２及び受信機回路１４を使用して、モバイル装置１０によって受け取られ、プロセッサ１６によってバッファ１８に記憶される。モバイル装置１０のユーザにメディアを最初に提示するために（すなわち、装置１０が、最初にスイッチをオンにされるとき、装置１０が、初めてブロードキャストメディアストリームを受け取り始めるとき、又はユーザが視聴するためにブロードキャストメディア装置の新しいサービスを選択するとき）、プロセッサ１６は、オーディオ及びビデオパケットの各々について、どのオーディオパケットが特定のビデオパケットと共にバッファ１８からストリーミングされるべきかを示すために使用されるＮＴＰタイムスタンプを決定し、バッファ１８からのパケットを、モバイル装置１０の適当な出力部（すなわちスピーカ２２又はディスプレイ２４）にストリーミングする。プレゼンテーションの実時間（すなわち、パケットがバッファ１８からストリーミングされる時間）は、プロセッサ１６によってプレゼンテーションタイムスタンプ（ＰＴＳ）から決定されることができ、又は単にビデオストリームのフレームレート（すなわち、毎秒特定のフレーム数のビデオデータをストリーミングする）を考慮に入れてプロセッサ１６によって決定されることができる。
【００４５】
モバイル装置がモバイル電話である場合、受信機回路１４は、トランシーバ回路と置き換えられることができ、又は別個の送信機回路が、通信ネットワークとのアップリンク通信のために設けられる。
【００４６】
更に、ある実施形態において、受信機回路１４は、プロセッサ１６を通過することなく、受信されたメディアストリームをバッファ１８へ直接に供給することができることが分かるであろう。
【００４７】
図４は、任意の時点におけるＤＶＢ−Ｈシステムのバッファ１８の内容を示す。この図において、バッファ１８へストリーミングされるデータサンプルは、左側から到来し、バッファ１８から（ストリーミングポイントから）スピーカ２２又はディスプレイ２４へストリーミングされるデータサンプルは、右へ行く。メディアストリームは、この例では、２つのコンポーネント、すなわちビデオ及びオーディオ、を含むので、バッファ１８は、２つのセクションに効果的に分割されており、（図４の上半分に示される）第１の部分は、ビデオデータサンプルを記憶し、（図４の下半分に示される）第２の部分は、オーディオデータサンプルを記憶する。
【００４８】
各時間スライス又はバーストの間に受け取られる各コンポーネントに関するデータサンプルが、バッファ１８に示されている。上述したように、データサンプルは、メディアストリームのコンポーネントのソースによって生成され、サンプルは、タイムスタンプを付される。しかしながら、各コンポーネントは、タイムスタンプに関するそれぞれ異なるベースを使用し、従って、異なるコンポーネントのタイムスタンプは、直接比較できない。
【００４９】
従って、各コンポーネントは、データチャネルと同時にブロードキャストされる個々のチャネルを伴い、チャネルは、コンポーネント内の相対タイムスタンプ及び絶対時間の間の関係を示すタイミング情報を含む情報パケット４、６を含む。これらの情報パケット４、６は、図４に示されるようにバッファに記憶される。
【００５０】
ＤＶＢ−Ｈシステムにおいて、データサンプルは、リアルタイム伝送プロトコル（ＲＴＰ）を使用してブロードキャストされ、それゆえ、ＲＴＰタイムスタンプを含む。更に、情報パケットは、ＲＴＣＰセンダリポートであり、タイミング情報は、ＲＴＰタイムスタンプと絶対時間（すなわちＮＴＰ時間）との間の関係を示す。
【００５１】
通常、情報パケット４、６は、それらがそれらの個々のオーディオ及びビデオストリームと共にバッファ１８からストリーミングされるとき、プロセッサ１６又は他のメディアプレーヤによって読み取られる（すなわち、それらは、ストリーミングポイントが個々の情報パケットに達すると読み取られる）。
【００５２】
しかしながら、本発明によれば、プロセッサ１６は、バッファ１８にすでに記憶されている任意の「将来の」情報パケットについて、ルックアヘッドアクションを実施することが可能であり、これは、バッファ１８内の現在ストリーミングポイント（すなわちデータサンプルが現在ストリーミングされている当該ストリーミングポイント）より先行するようにみえることを意味する。言い換えると、プロセッサ１６は、バッファ１８内にある情報パケットがデータサンプルと共にバッファ１８からストリーミング出力されるのを待つのではなく、それらの情報パケットを調べる。代替例として、ルックアヘッドアクションは、情報パケットが受信機回路１４によって受け取られるとき（すなわち、それらがバッファ１８に記憶される前に）、プロセッサ１６に情報パケットを調べさせることができる。
【００５３】
データサンプルは、プロセッサ１６内のコンポーネント復号器がそれらを使用することができるようになるよりもずっと速く特定の時間スライスに受け取られるので、プロセッサ１６によるこの「ルックアヘッド」アクションは、ブロードキャストメディアストリームの時間スライシング構造により、可能である。
【００５４】
図５は、本発明の１つの見地によるモバイル装置の動作を示すフローチャートである。
【００５５】
ステップ１０１において、ブロードキャストメディアストリームの複数のコンポーネントに関するデータサンプルが、受け取られ、バッファ１８に記憶される。コンポーネントの各々は、ストリーム内のデータサンプルに関する相対タイムスタンプを含む。
【００５６】
ステップ１０３において、各コンポーネントについて個々の情報パケットが、受け取られ、バッファ１８に記憶される。各情報パケットは、それらの個々のコンポーネント内の相対タイムスタンプと絶対時間との間の関係を示すタイミング情報を含む。
【００５７】
ステップ１０５において、プロセッサ１６は、バッファ１８に対するルックアヘッドアクションを実施し、受け取られた情報パケットから、タイミング情報を抽出する。代替例として、情報パケットが受信機回路１４によって受け取られるとき、プロセッサ１６は、タイミング情報を読み取ることもできる。その結果、情報パケットと同時に受け取られたデータサンプルが、バッファ１８からストリーミングされるよりも前に、タイミング情報が、情報パケットから抽出される。情報パケットが、間欠的に受け取られるとき、プロセッサ１６は、ルックアヘッドアクションを周期的に繰り返すことができる。
【００５８】
ステップ１０７において、プロセッサ１６は、コンポーネント内のデータサンプルの相対タイムスタンプを絶対時間と関連づけるために、識別されたタイミング情報を使用する。異なるデータストリームからのサンプルは、ここで、共通の時間ベースを有するので、プロセッサ１６は、１つのコンポーネント内のどのサンプルが別のコンポーネント内のどのサンプルと共にストリーミングされるべきかを決定することによって、コンポーネントを同期させることができる。
【００５９】
最後に、ステップ１０９において、コンポーネント内の同期されたデータサンプルが、バッファ１８からストリーミングされる。
【００６０】
データストリーミングシステムの性質により（すなわち、データが、（バースト送信の場合）周期的に受け取られ、ユーザに連続的にストリーミングされる）、この方法におけるステップの各々は、メディアストリームのそれぞれ異なる部分についてであるが、モバイル装置１０によってほぼ同時に実施されていることが分かるであろう。例えば、ステップ１０１及び１０３は、特定のバーストについてほぼ同時に行われ（それゆえ、フローチャートに横に並んで示されている）、プロセッサ１６は、ブロードキャストメディアストリーム内のより早いものからのデータサンプルを、ユーザにストリーミングする。
【００６１】
従って、装置１０が、最初にオンにされるとき、装置１０が、最初にブロードキャストメディアストリームを受け取り始めるとき、又はユーザが、ブロードキャストメディアストリームの新しいサービスを選択するとき、上述の方法は、複数のコンポーネントが、通常の方法より非常に速く同期されることを可能にする。実際、情報パケット（ＲＴＣＰセンダリポート）が第１のバーストにおいて利用可能である場合、同期は、サービス変更が行われるとほとんどすぐに実現されることができる。
【００６２】
更に、上述の方法を使用することによって、複数のコンポーネントが従来の方法より早く同期し直される必要があるかどうか（すなわち、コンポーネント間のタイミングがドリフトしているかどうか）を判定することが可能である。更に、以下に一層詳しく記述されるように、必要とされる同期修正の早期の検出は、修正が、従来の方法のように特定の時点に実現されるのではなく、短い時間期間（すなわち複数のフレーム）にわたって実現されることを可能にする。このようにして、ユーザ知覚できるアーチファクトが低減される。
【００６３】
これらの２つの実現例の更なる詳細が、以下に与えられる。
【００６４】
新しいサービスのコンポーネントの同期
従って、装置１０が最初にオンにされるとき、装置１０が最初にブロードキャストメディアストリームを受け取り始めるとき、又はユーザが、ブロードキャストメディアの新しいサービスを選択するとき、装置１０は、第１の選択されたバーストを受け取り、バッファ１８にデータサンプル及びＲＴＣＰセンダリポートパケットを記憶する。
【００６５】
プロセッサ１６は、バッファ１８から、受け取ったメディアコンポーネントを消費（すなわちストリーミング）し始めることができるが、すべての必要なメディアコンポーネントの利用可能なＲＴＣＰパケットがあるかどうかバッファ１８の残りの部分を調べるために、ルックアヘッドアクションを同時に実施することができる。
【００６６】
このようなＲＴＣＰパケットが、それぞれ異なるメディアコンポーネントの少なくとも２つに関して見つけられる場合、データサンプルストリーム内の個別のコンポーネントＲＴＰタイムスタンプは、ＲＴＰタイムスタンプをＮＴＰ時間にリンクするＲＴＣＰセンダリポートパケット内のタイミング情報を使用して、１つの絶対時間ベースに変換されることができる。特に、ＲＴＣＰセンダリポートパケットは、ＲＴＰデータパケット内の最初のオクテットのサンプリング時点に関するＲＴＰタイムスタンプ及び対応するＮＴＰタイムスタンプを含むので、（この第１のサンプリング時点から正確に計られた）ＲＴＰデータパケット内のＲＴＰタイムスタンプは、ＮＴＰ時間に関連付けられることができる。
【００６７】
タイミング情報は、各々のＲＴＣＰパケットの間で変わらないので、より早い及びより遅いＲＴＣＰセンダリポートパケットからのタイミング情報が、ＲＴＰデータストリームのデータサンプルに有効である。
【００６８】
従って、ＲＴＣＰセンダリポートパケットは、時間的により遅くに受け取られるが、複数のコンポーネント間の同期は、パケットが受け取られるとすぐに確立されることができる。
【００６９】
特に、以下の計算は、本発明が複数のコンポーネントの同期を達成する際に従来の方法を超えて提供する改善を示す。以下、新しいサービスが、当該サービスのバーストとバーストの間に選択されるものとする（すなわち、当該サービスのバーストは、サービス切り替えが行われるときには送信されない）。
【００７０】
ＲＴＣＰセンダリポートパケットが、（今日の標準において勧告されるように）メディアストリーム内の各コンポーネントについて５秒毎に送信され、ストリームが、２秒の時間スライシングサイクルを有するものとすると、同期を達成するために必要とされる最大時間は７秒であり、これは、正しい時間スライスを待つ２秒と、ＲＴＣＰセンダレポートパケットを待つ５秒と、を含む。平均して、同期を達成するために３．５秒かかり、これは、正しい時間スライスを待つ１秒と、ＲＴＣＰパケットを待つ２．５秒と、を含む。
【００７１】
しかしながら、本発明による方法を使用する場合、同期を達成するための最大時間は６秒であり、これは、正しい時間スライスを待つ２秒と、（現在時間スライスがＲＴＣＰパケットを含まない場合）次の時間スライスを待つ２秒と、次の時間スライスがなおＲＴＣＰパケットを含まない場合の更なる２秒と、ＲＴＣＰパケットはそれが受け取られるとほぼすぐに読み取られることができるという理由で０秒と、を含む。同期を達成する平均時間は２．６秒であり、これは、時間スライスを待つ１秒と、ＲＴＣＰパケットがこの時間スライス内にある（ゆえに０秒の更なる待ち時間を必要とする）４０％の可能性と、ＲＴＣＰパケットが次の時間スライス内にある４０％の可能性（ゆえに更なる２秒の待ち時間を必要とする）と、ＲＴＣＰパケットが最後の時間スライス内にある２０％の可能性（ゆえに更なる４秒の待ち時間を必要とする）と、を含む。
【００７２】
本発明の好適な実施形態において、同期時間は、データサンプルの各バーストと共にＲＴＣＰタイムスタンプを送信することによって、一層改善されることができる。従って、別のバーストを待つ結果としての遅延が回避される。
【００７３】
特に、ＲＴＣＰパケットが、時間スライス毎（従って２秒毎）に送信される場合、従来の方法を使用してコンポーネントを同期させるための最大時間は４秒であり、これは、時間スライスを待つ２秒と、ＲＴＣＰパケットを待つ２秒と、を含む。コンポーネントを同期させるためにかかる平均時間は２秒であり、これは、時間スライスを待つ１秒と、ＲＴＣＰパケットを待つ１秒と、を含む。
【００７４】
しかしながら、あらゆる時間スライスにＲＴＣＰパケットに関して上述の方法を使用することは、２秒の最大の同期時間を生じさせ、これは、時間スライスを待つ２秒を含む。平均持続時間は１秒であり、これは、時間スライスを待つ１秒である。
【００７５】
複数のコンポーネントを同期させるためにかかる時間の更なる改善は、メモリ２６の履歴テーブルに、各サービスについて受け取られたタイミング情報を記憶することによって得られることができる。ＲＴＣＰセンダリポートパケット内の相対値は、ある時間にわたって変化すべきでないので、記憶されたパケットは、ユーザがそのサービスに切り替えをする際に使用されることができる。
【００７６】
この履歴テーブルは、いくつかのやり方でデータを入れられることができる。最初に、装置１０が活性化されると、装置１０は、ブロードキャストのすべてのサービスに関する時間スライスを受け取る必要がある。プロセッサ１６は、すべてのＲＴＣＰパケットについてこれらの時間スライスを探すことができ、メモリ２６にこれらを記憶することができる。
【００７７】
第２に、装置１０は、メモリ２６の各サービスのタイミング情報をリフレッシュするために、周期的な更新を実施することができる。
【００７８】
第３に、通常のサービス受信の間、装置１０は、現在消費されているサービスのＲＴＣＰパケットをキャッシュすることができる。しばらくしてから、ユーザがこのサービスに戻ってくる場合、ＲＴＣＰ情報は、メモリ２６内ですでに利用可能である。このようにして、装置１０が、新しいサービスに最初にスイッチされるときにのみ、同期の遅れがある。
【００７９】
従って、新しく選択されたサービスの最初の時間スライスにＲＴＣＰセンダリポートがない場合、キャッシュされたタイミング情報が、複数のコンポーネントを同期させるために使用されることができる。
【００８０】
これらのケースのいずれにおいても、可能性は低いが、相対タイミングが変化している可能性がある場合、プロセッサ１６が、メディアストリーム内のコンポーネント間の大きなタイミング差（例えば数秒又はより長い秒のオーダーの差）があるのを検出することはかなり容易であり、プロセッサ１６は、このテストに失敗する任意のキャッシュされた情報を無視することができる。
【００８１】
キャッシュされた情報が今もなお有効であうかどうか判定するための更なるチェックが、キャッシュされた情報について行われることができる。更に、メモリ２６にＲＴＣＰパケットをキャッシュすることに加えて、ＲＴＣＰパケットが受け取られるポイントに対応する絶対時間及びＲＴＣＰパケットの近くで受け取られるＲＴＰパケットのプレゼンテーションタイムスタンプをキャッシュすることも可能である。従って、ＲＴＰパケットのプレゼンテーションタイムスタンプが、キャッシュされた情報を用いて計算される場合、結果として得られるプレゼンテーションタイムスタンプは、キャッシュの時間とキャッシュの時点のプレゼンテーションタイムスタンプとの間の絶対時間差に近いものであるべきである。そうでない場合、キャッシュに保持される情報は、おそらく無効であり、プロセッサ１６は、新しいＲＴＣＰパケットを待つべきである。
【００８２】
既存のサービスのコンポーネント間の同期の修正
上述したように、サービス内の複数のコンポーネント間の同期が、ある時間にわたってドリフトする場合、本発明による方法は、この同期ドリフトが従来の方法よりも早く判定されることを可能にする。
【００８３】
同期ドリフトのこの早期の検出の結果として、同期修正は、従来の方法のように特定の時点に行われるのではなく、短い時間期間（すなわち多くのフレーム）にわたって行われることができる。
【００８４】
特に、同期修正は、（ビデオコンポーネントが他のコンポーネントに時間的に先行している場合）ビデオフレームを落とす（ドロップする）ことによって、及び／又は（オーディオコンポーネントが他のコンポーネントに時間的に先行している場合）オーディオサンプルを落とすことによって、実現されることができる。
【００８５】
モバイル装置１０は、各ストリームと共に送られた第１のＲＴＣＰセンダリポートパケットを使用してＲＴＰ送信のそれぞれ異なるメディアコンポーネントを同期させたのち、各々のコンポーネントストリームについて他のＲＴＣＰ情報パケットを受け取ることを続ける。本発明によれば、モバイル装置１０は、バッファ１８内のＲＴＣＰパケットに対してルックアヘッド動作を実施する。言い換えると、モバイル装置１０は、対応するデータサンプルと共にバッファからストリーミングされるＲＴＣＰパケットを待つのではなく、それが装置１０に利用可能になるとすぐに、ＲＴＣＰパケット内のタイミング情報を抽出する。
【００８６】
このようなＲＴＣＰパケットが見つけられるとすぐに、プロセッサ１６は、相対タイムスタンプを絶対時間と関連づけ、通常通り、それぞれ異なるメディアコンポーネントのプレゼンテーションタイムスタンプを計算する。これから、プロセッサ１６は、１つのコンポーネントからのどのサンプルが、他のコンポーネントからの特定のサンプルと共にストリーミングされるべきかを判定し、これを、現在ストリーミングされているデータサンプル対と比較する。これらのサンプル対が、現在ストリーミングされているものと異なる場合、ドリフトが生じており、従って、プロセッサ１６は、１又は複数の特定のコンポーネントがどれくらい調整される必要があるか、及びこのドリフトが修正されるべきであるポイント、を判定する。ドリフトが通常修正される時間は、ＲＴＣＰパケットがバッファ１８から読み取られる時間である。
【００８７】
プロセッサ１６は、ＲＴＣＰパケットがバッファ１８から読み取られる前に、コンポーネントを同期させるために、各々のコンポーネントが（又はどのコンポーネントが）どれくらい調整される必要があるかを判定するために、決定された調整量及び通常の修正時間を使用する。
【００８８】
プロセッサ１６は、（ビデオストリームがオーディオストリームに先行している又は遅れている場合）ビデオフレームを付加し又は省くことによって、又は（オーディオストリームがビデオストリームに先行している又は遅れている場合）オーディオサンプルを付加し又は省くことによって、オーディオ及びビデオストリームの間の同期ドリフトを修正することができる。フレーム又はサンプルは、既存のフレーム又はサンプルを繰り返すことによって、付加されることができる。
【００８９】
好適には、プロセッサ１６は、バッファ１８からＲＴＣＰパケットを読み取る前に、ある時間期間にわたってフレーム又はサンプルの付加又は省略を配置することによって、同期ドリフトを修正し、よって、再同期の際に、いかなるユーザ知覚可能なアーチファクトもあるべきでない。
【００９０】
再同期が行われるたびに、再同期に関する情報が、メモリ２６の履歴テーブルに記憶されることができる。プロセッサ１６は、フレーム又はオーディオタイミングの行われた全体の平均的な調整を計算するために、このテーブル内の情報を使用することができる。この情報によって、プロセッサ１６は、受け取られるＲＴＣＰパケットに先立って、再同期を予測することができ、当該ＲＴＣＰパケットがバッファ１８から読み取られるよりかなり前に、再同期が実現されることを確実にする。このようにして、再同期は、より大きいタイムスケールにわたって実現されることができ、これは、フレーム又はオーディオサンプルの付加又は省略がより離れて拡散されることができるので、遷移がなお一層滑らかに行われることができることを意味する。
【００９１】
ＲＴＣＰパケットがバッファ１８から読み取られるとき、その中のタイミング情報が、コンポーネントの同期が正しく調整されたことを確認するために使用されることができる。
【００９２】
更に、本発明のこの実施例は、送信のソースにおいて特別なＲＴＣＰパケットを導入することによって、非時間スライシング送信に適用されることができる。このパケットは、同期情報及びこの情報がいつ作用されるべきかを示すタイムスタンプを含むことができる。わずかな再同期が期待される場合、このパケットは、送信のソースによって、時間的に先立って生成され、送られることができる。このようにして、この特別なＲＴＣＰパケットが受け取られる場合、装置は、ある時間期間にわたって同期を円滑に調整することができる。
【００９３】
従って、新しいサービスが選択される場合に改善された同期時間を有するとともに、メディアストリームのコンポーネント間の同期の修正が実現される場合に一層滑らかな遷移を供給する方法及び装置が提供される。
【００９４】
本発明は、図面及び前述の記述に詳しく図示され記述されているが、このような図示及び記述は、制限的なものではなく、説明的又は例示的なものであると考えられることができる。本発明は、開示された実施形態に制限されない。
【００９５】
開示された実施形態に対する変更は、図面、開示及び添付の請求項の検討から、請求項に記載された本発明を実施する際に当業者によって理解されることができ、実現されることができる。本発明は、いくつかの個別の構成要素を含むハードウェアによって、及び／又は適切にプログラムされたプロセッサによって、実現されることができる。請求項において、「含む、有する」という語は、他の構成要素又はステップを除外せず、不定冠詞「a」又は「an」は、複数性を除外しない。単一のプロセッサ又は他のユニットが、請求項に列挙されるいくつかのアイテムの機能を果たすことができる。特定の手段が相互に異なる従属請求項に列挙されているという単なる事実は、これらの手段の組み合わせが有利に使用されることができないことを示さない。請求項におけるいかなる参照符号も、範囲を制限するものとして解釈されるべきでない。コンピュータプログラムは、例えば他のハードウェアと共に又はその一部として供給される光学記憶媒体又はソリッドステート媒体のような適切な媒体に記憶され／分散されることができるが、例えばインターネット又は他のワイヤード又はワイヤレス通信システムを介するように、他の形態で分散されることもできる。
【特許請求の範囲】
【請求項１】
ブロードキャストメディアストリームの複数のコンポーネントを同期させる方法であって、
ブロードキャストメディアストリームの複数のコンポーネントに関するデータサンプルのストリームをバッファし、複数の情報パケットをバッファするステップであって、前記複数のコンポーネントの各々に関する前記データサンプルのストリームは、相対タイミング情報を含み、各情報パケットは、前記コンポーネント内の前記相対タイミング情報と絶対時間との間の関係を示すタイミング情報を含む、ステップと、
前記複数のコンポーネントの各々に関するタイミング情報を抽出するために、前記バッファされた情報パケットについてルックアヘッドアクションを実施するステップと、
前記複数のコンポーネントを同期させるために、前記抽出されたタイミング情報及び前記相対タイミング情報を使用するステップと、
を含む方法。
【請求項２】
各情報パケットが、前記複数のコンポーネントの個々のものに関連付けられ、前記タイミング情報が、それらの個々のコンポーネント内の前記相対タイミング情報と絶対時間との間の関係を示す、請求項１に記載の方法。
【請求項３】
前記複数のコンポーネント内の前記同期されたデータサンプルをストリーミングするステップを更に含む、請求項１又は２に記載の方法。
【請求項４】
メモリに前記情報パケットを記憶するステップと、
更なる情報パケットが受け取られるまで、前記複数のコンポーネント内の前記データサンプルを同期させるために、前記メモリに記憶された前記情報パケット内の前記タイミング情報を使用するステップと、
を含む、請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記ブロードキャストメディアストリームは、複数の選択可能なサービスを含み、前記方法が、
各選択可能なサービスのコンポーネントに関する情報パケットを受け取るステップと、
前記メモリに前記情報パケットを記憶するステップと、
を更に含む、請求項４に記載の方法。
【請求項６】
前記複数のコンポーネントに関する前記データサンプルのストリームが、前記ブロードキャストメディアストリームの第１の選択可能なサービスを含み、
第２の選択可能なサービスが選択される場合、前記第２の選択可能なサービスに関する個々の情報パケットが受け取られる前に、前記第２の選択可能なサービスに関して記憶された情報パケットが使用される、請求項５に記載の方法。
【請求項７】
前記データサンプルは、バーストで受け取られ、情報パケットは、各バーストと共に受け取られる、請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記抽出されたタイミング情報及び前記相対タイミング情報を使用する前記ステップは、同時にストリーミングされるべき前記複数のコンポーネント内の前記データサンプルを決定することを含む、請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記複数のコンポーネント間のドリフトを識別するために、同時にストリーミングされるべきと決定された前記データサンプルを、同時にストリーミングされるべきと以前に決定されたデータサンプルの組と比較するステップと、
前記データサンプルが前記バッファからストリーミングされるとき、前記識別されたドリフトを修正するために特定の前記コンポーネントからのデータサンプルを付加し又は省くステップと、
を含む、請求項８に記載の方法。
【請求項１０】
前記ドリフトを識別するために使用された前記情報パケットと共に受け取られた１又は複数のデータサンプルが、ストリーミングされる前に、前記ドリフトが、データサンプルを付加し又は省くことによって修正される、請求項９に記載の方法。
【請求項１１】
前記データサンプルの付加は、データサンプルの複製を含む、請求項９又は１０に記載の方法。
【請求項１２】
前記比較するステップの結果を、メモリに記憶するステップを更に含む、請求項９、１０又は１１に記載の方法。
【請求項１３】
前記メモリに記憶された結果から平均的な修正を計算するステップと、
特定のコンポーネントに必要な修正を予測するために、前記計算された平均的な修正を使用するステップと、
を更に含む、請求項１２に記載の方法。
【請求項１４】
ユーザにブロードキャストメディアストリームを提供する装置であって、
ブロードキャストメディアストリームの複数のコンポーネントに関するデータサンプルのストリーム及び複数の情報パケットを記憶するバッファであって、各コンポーネントは、前記ストリーム内に前記データサンプルに関する相対タイミング情報を含み、各情報パケットは、前記コンポーネント内の前記相対タイミング情報と絶対時間との間の関係を示すタイミング情報を含む、バッファと、
各コンポーネントに関する前記バッファされた情報パケットから前記タイミング情報を抽出するルックアヘッドアクションを実施し、前記複数のコンポーネントを同期させるために、前記抽出されたタイミング情報及び前記相対タイミング情報を使用するプロセッサと、
を有する装置。
【請求項１５】
前記抽出されたタイミング情報を記憶するためのメモリを更に有する、請求項１４に記載の装置。
【請求項１】
ブロードキャストメディアストリームの複数のコンポーネントを同期させる方法であって、
ブロードキャストメディアストリームの複数のコンポーネントに関するデータサンプルのストリームをバッファし、複数の情報パケットをバッファするステップであって、前記複数のコンポーネントの各々に関する前記データサンプルのストリームは、相対タイミング情報を含み、各情報パケットは、前記コンポーネント内の前記相対タイミング情報と絶対時間との間の関係を示すタイミング情報を含む、ステップと、
前記複数のコンポーネントの各々に関するタイミング情報を抽出するために、前記バッファされた情報パケットについてルックアヘッドアクションを実施するステップと、
前記複数のコンポーネントを同期させるために、前記抽出されたタイミング情報及び前記相対タイミング情報を使用するステップと、
を含む方法。
【請求項２】
各情報パケットが、前記複数のコンポーネントの個々のものに関連付けられ、前記タイミング情報が、それらの個々のコンポーネント内の前記相対タイミング情報と絶対時間との間の関係を示す、請求項１に記載の方法。
【請求項３】
前記複数のコンポーネント内の前記同期されたデータサンプルをストリーミングするステップを更に含む、請求項１又は２に記載の方法。
【請求項４】
メモリに前記情報パケットを記憶するステップと、
更なる情報パケットが受け取られるまで、前記複数のコンポーネント内の前記データサンプルを同期させるために、前記メモリに記憶された前記情報パケット内の前記タイミング情報を使用するステップと、
を含む、請求項１乃至３のいずれか１項に記載の方法。
【請求項５】
前記ブロードキャストメディアストリームは、複数の選択可能なサービスを含み、前記方法が、
各選択可能なサービスのコンポーネントに関する情報パケットを受け取るステップと、
前記メモリに前記情報パケットを記憶するステップと、
を更に含む、請求項４に記載の方法。
【請求項６】
前記複数のコンポーネントに関する前記データサンプルのストリームが、前記ブロードキャストメディアストリームの第１の選択可能なサービスを含み、
第２の選択可能なサービスが選択される場合、前記第２の選択可能なサービスに関する個々の情報パケットが受け取られる前に、前記第２の選択可能なサービスに関して記憶された情報パケットが使用される、請求項５に記載の方法。
【請求項７】
前記データサンプルは、バーストで受け取られ、情報パケットは、各バーストと共に受け取られる、請求項１乃至６のいずれか１項に記載の方法。
【請求項８】
前記抽出されたタイミング情報及び前記相対タイミング情報を使用する前記ステップは、同時にストリーミングされるべき前記複数のコンポーネント内の前記データサンプルを決定することを含む、請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記複数のコンポーネント間のドリフトを識別するために、同時にストリーミングされるべきと決定された前記データサンプルを、同時にストリーミングされるべきと以前に決定されたデータサンプルの組と比較するステップと、
前記データサンプルが前記バッファからストリーミングされるとき、前記識別されたドリフトを修正するために特定の前記コンポーネントからのデータサンプルを付加し又は省くステップと、
を含む、請求項８に記載の方法。
【請求項１０】
前記ドリフトを識別するために使用された前記情報パケットと共に受け取られた１又は複数のデータサンプルが、ストリーミングされる前に、前記ドリフトが、データサンプルを付加し又は省くことによって修正される、請求項９に記載の方法。
【請求項１１】
前記データサンプルの付加は、データサンプルの複製を含む、請求項９又は１０に記載の方法。
【請求項１２】
前記比較するステップの結果を、メモリに記憶するステップを更に含む、請求項９、１０又は１１に記載の方法。
【請求項１３】
前記メモリに記憶された結果から平均的な修正を計算するステップと、
特定のコンポーネントに必要な修正を予測するために、前記計算された平均的な修正を使用するステップと、
を更に含む、請求項１２に記載の方法。
【請求項１４】
ユーザにブロードキャストメディアストリームを提供する装置であって、
ブロードキャストメディアストリームの複数のコンポーネントに関するデータサンプルのストリーム及び複数の情報パケットを記憶するバッファであって、各コンポーネントは、前記ストリーム内に前記データサンプルに関する相対タイミング情報を含み、各情報パケットは、前記コンポーネント内の前記相対タイミング情報と絶対時間との間の関係を示すタイミング情報を含む、バッファと、
各コンポーネントに関する前記バッファされた情報パケットから前記タイミング情報を抽出するルックアヘッドアクションを実施し、前記複数のコンポーネントを同期させるために、前記抽出されたタイミング情報及び前記相対タイミング情報を使用するプロセッサと、
を有する装置。
【請求項１５】
前記抽出されたタイミング情報を記憶するためのメモリを更に有する、請求項１４に記載の装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公表番号】特表２０１１−５２５３２２（Ｐ２０１１−５２５３２２Ａ）
【公表日】平成２３年９月１５日（２０１１．９．１５）
【国際特許分類】
【出願番号】特願２０１１−５１３０８７（Ｐ２０１１−５１３０８７）
【出願日】平成２１年６月４日（２００９．６．４）
【国際出願番号】ＰＣＴ／ＩＢ２００９／０５２３５７
【国際公開番号】ＷＯ２００９／１５０５７８
【国際公開日】平成２１年１２月１７日（２００９．１２．１７）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【Ｆターム（参考）】
【公表日】平成２３年９月１５日（２０１１．９．１５）
【国際特許分類】
【出願日】平成２１年６月４日（２００９．６．４）
【国際出願番号】ＰＣＴ／ＩＢ２００９／０５２３５７
【国際公開番号】ＷＯ２００９／１５０５７８
【国際公開日】平成２１年１２月１７日（２００９．１２．１７）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【Ｆターム（参考）】
[ Back to top ]