JP2015534312A - レンダリング時の制御 - Google Patents

Abstract

第２の装置（６）における第２のコンテンツ・ストリームのレンダリングのタイミングを制御する方法であって、上記第２のコンテンツ・ストリームがチャンクの形態に構成されており、各々の上記チャンクがデータ・パケットを含み、上記方法が、ａ）上記第２の装置（６）から上記第２のコンテンツ・ストリームのチャンクの要求を受信するステップと、ｂ）第１の装置（４）においてレンダリングされている第１のコンテンツ・ストリームの再生位置に基づいて上記要求されたチャンクの第２の位置を特定するステップと、ｃ）サーバ（１８）から上記要求されたチャンクのパケットを受信するステップと、ｄ）上記要求されたチャンクが上記第２の装置（６）に配信されるべき配信時点（ＴｏＤ）で、上記要求されたチャンクを上記第２の装置（６）に配信するステップであって、上記配信時点（ＴｏＤ）が上記第２の位置に関連づけられる、該ステップと、を備えた、方法。【選択図】図１

Description

本発明は、概して、種々のソース（供給源）から発生し、及び／又は、種々のトランスポート・プロトコルを用いて送信され、少なくとも１台のレンダリング装置において復元されるコンテンツ・ストリームの処理に関する。

更に詳しく述べると、本発明は、そのようなコンテンツ・ストリームの同期化に関し、特に、補助ディスプレイ上のコンテンツのレンダリングのタイミングの制御に関するもので、補助ディスプレイ上のコンテンツがメイン・ディスプレイ（主要ディスプレイ）上にレンダリングされる関連コンテンツに完全に同期化されるようにする。本発明は、特に、セカンド・スクリーン（第２のスクリーン）テレビジョン（ＴＶ）を有する状況であって、関連するコンテンツが、例えば、スマートフォンのようなパーソナル・デバイス上とテレビジョン（ＴＶ）セット（テレビジョン受像機）上とに同時にレンダリングされる状況に適用される。

したがって、本発明は、コンテンツのレンダリングのタイミングを制御するための方法と装置に関する。本発明は、また、本発明の方法を実施するコンピュータ・プログラムにも関する。

この節で説明されるアプローチ（手法）は、遂行可能ではあるが、必ずしも以前に考案された又は遂行されたアプローチではない。したがって、ここで特に示されていない限り、この節で説明されるアプローチは、本願における特許請求の範囲に対する先行技術ではなく、この節に含まれているからといって先行技術であると認められる訳ではない。

ブロードキャスト（放送）ネットワークとブロードバンドＩＰネットワークとの相補的な性質によって、各々のネットワークの長所を活用して個人化ＴＶサービスを提供するハイブリッド配信モデルへの扉が開かれている。このような配信モデルは、ＴＶ分野の多数の関係者によって既に利用されている。民生用機器の製造業者は、キャッチアップＴＶ（ｃａｔｃｈ-ｕｐ ＴＶ）、高度番組ガイド及びインターネット・ビデオへのブロードバンド・アクセスを組み込んだ「Ｃｏｎｎｅｃｔｅｄ ＴＶ」を提供している。

ＨｂｂＴＶ（Ｈｙｂｒｉｄ Ｂｒｏａｄｃａｓｔ Ｂｒｏａｄｂａｎｄ ＴＶ（ハイブリッド・ブロードキャスト・ブロードバンドＴＶ））及びＹｏｕＶｉｅｗのようなイニシアティブ（新規構想）がきっかけとなって、ブロードキャスタ（放送事業者）、コンテンツ・プロバイダ及びインターネット・サービス・プロバイダが、一緒になって、ハイブリッド・ブロードキャスト・ブロードバンド・サービスの提供の標準化方式を規定しようとしている。最初のＨｂｂＴＶサービスが遥か前の２００９年１２月に開始されたにもかかわらず、現在のハイブリッドＴＶサービスの発展は、メディア・コンテンツの配信についてのインターネットの可能性を未だ十分に活用しておらず、更なる革新について、かなりの可能性が残されている。

人気番組の大衆向けの配給についてのブロードキャスト（放送）配信と、ロングテール及びオン・デマンド・コンテンツについてのブロードバンド配信とを利用することによって、複合型配信モデルが、個人化付加価値ＴＶサービスを多数の加入者に提供することについて、十分に適合化されている。

タブレット又はスマートフォンのようなコンパニオン（携帯）端末は、ＴＶブロードキャストにリンクされた個人化コンテンツを消費する「ＴＶバディ（ｂｕｄｄｙ）（仲間）」として、十分に確立されつつある。

２０１１ ＩＥＥＥ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｃｏｎｓｕｍｅｒ Ｅｌｅｃｔｒｏｎｉｃｓ（家庭用電子機器に関する２０１１年ＩＥＥＥ国際会議）におけるＣ.Ｈｏｗｓｏｎ氏その他の論文である「Ｓｅｃｏｎｄ Ｓｃｒｅｅｎ ＴＶ Ｓｙｎｃｈｒｏｎｉｚａｔｉｏｎ（セカンド・スクリーンＴＶ同期化）」において、放送番組にリンクされた代替の（代わりに選択できる）オーディオ（音声）又はビデオ（映像）のコンテンツをブロードバンドを介して搬送することによって、個人化を可能にし、放送ネットワークの帯域幅の負担を軽減するセカンド・スクリーンの使用ケースが予見されている。

このようなサービスの一例によれば、ユーザは、ＴＶ受像機に表示された放送ビデオに伴う自分好みのオーディオ・サウンドトラックをハンドヘルド（携帯）機器上で選択できる。主音声及び映像コンポーネントが放送ネットワークを介して配信される一方で、いくつかの他言語がインターネットを介してオン・デマンドで利用できる。

別のこのようなサービスによれば、ユーザは、ＴＶセット上に放送コンテンツを表示させつつ、スポーツ又は音楽イベントの代替のビューを配信するブロードバンドを選択し、これを自分のタブレット上にレンダリングさせることが可能となる。

このようなセカンド・スクリーン・サービスのユーザ体験が満足なものであるようにするには、ブロードバンド・ネットワーク及びブロードキャスト（放送）ネットワークを介して別々に配信されるメディアコンポーネントを正確に同期化してレンダリングする必要がある。

既存のハイブリッドＴＶサービスは、インタラクティブなアプリケーションについてのトリガ・メカニズムを採用しているが、例えば、インターネットを介して配信された代替サウンドトラックを放映されるビデオコンポーネントに自動的に且つ正確に同期化できる技術を組み入れていない。

先に引用した論文では、セカンド・スクリーン個人化ＴＶサービスの開発について、ブロードバンド・ネットワーク及びブロードキャスト（放送）ネットワークを介して個別に配信されるコンテンツコンポーネントのレンダリングをユーザ装置において同期化できるシステムが提案されている。この論文に開示された課題解決手段は、放送ネットワーク、および、場合によっては、ブロードバンド・ネットワークを介して配信されるメディアコンポーネントの各々のグループに関連付けられた補助コンポーネントタイムラインの付加に基づいている。このタイムライン・コンポーネントは、各々のイベントに関連する同期化情報を伝達し、メディアコンポーネントの表示を整列することに使用される。

２つのレンダラ（レンダリング装置）を、比較的高い又は比較的低い正確さで、同期化できる他の技術、例えば、オーディオ・ウォーターマーキング（音声透かし処理）及びオーディオ・フィンガープリンティング（音声指紋処理）も存在する。

しかしながら、これらの既存の技術では、セカンド・スクリーン装置が、メイン・スクリーン装置と共用するタイム・リファレンスを管理するように構成されたプレーヤを備えている必要がある。

本発明は、このような状況を改善するソリューションを提案する。

したがって、本発明は、第２の装置における第２のコンテンツ・ストリームのレンダリングのタイミングを制御する方法であって、上記第２のコンテンツ・ストリームがチャンクの形態に構成されており、各々の上記チャンクが上記第２のコンテンツ・ストリームの個別にアクセス可能なパートに対応しており、各々の上記チャンクがデータ・パケットを含み、上記方法が、制御装置によって実行されるステップ、すなわち、
ａ）上記第２の装置から上記第２のコンテンツ・ストリームのチャンクの要求を受信するステップと、
ｂ）第１の装置においてレンダリングされている第１のコンテンツ・ストリームの再生位置に基づいて上記第２のコンテンツ・ストリーム内の上記要求されたチャンクの第２の位置を特定するステップと、
ｃ）サーバから上記要求されたチャンクのパケットを受信するステップと、
ｄ）上記第２の装置による上記第２のコンテンツ・ストリームのレンダリングが、上記第１の装置による上記第１のコンテンツ・ストリームのレンダリングに同期化されるように上記要求されたチャンクが上記第２の装置に配信されるべき配信時点で、上記要求されたチャンクを上記第２の装置に配信するステップであって、上記配信時点が上記第２の位置に関連づけられる、上記ステップと、
を備えた、方法を提供する。

したがって、本発明において、第２の装置におけるレンダリングのタイミングは、第２のコンテンツ・ストリームのデータを上記第２の装置に適切な時点で配信することによって、制御される。この方法は、第２の装置のプレーヤ・アプリケーションの如何なる特定の特徴も必要としない。

その結果、本発明の方法は、ビデオ・プレーヤを実装するあらゆる装置においてセカンド・スクリーン・サービスを実施することを可能にする。

また、本方法は、ブロードバンド・ネットワークを介して複数の端末に配信される種々のビデオ・ストリームのレンダリングのタイミングを制御することに使用してもよい。

望ましくは、上記配信するステップは、適応ストリーミング・プロトコルを使用する。

更に詳しくは、このプロトコルは、例えば、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）適応ストリーミング・プロトコルである。

この場合、上記第２のコンテンツ・ストリームの各々のチャンクは、別々のＵＲＩによって、個別にアクセス可能である。

利点として、本方法は、上記制御装置によって実行されるステップ、すなわち、
ｅ）上記要求されたチャンクの最後のパケットを除く上記要求されたチャンクの上記パケットを上記第２の装置（６）に送信するステップと、
ｆ）上記要求されたチャンクの上記最後のパケットをバッファリングするステップと、
を更に備え、ｄ）の上記配信するステップは、上記配信時点で、上記要求されたチャンクの上記最後のパケットを上記第２の装置に配信することを含む。

適応ストリーミングの場合、第２の装置が上記要求されたチャンクの最後のパケットを受信した時点によって上記チャンクのレンダリングの開始が決まるので、この最後のパケットの第２の装置への配信の時点が上記装置による上記チャンクのレンダリングのタイミングを強制的に決める。

利点として、本方法は、上記第２の装置による上記要求されたチャンクの処理に必要な時間を特定する更なるステップを備える。

この処理時間は、したがって、上記要求されたチャンクの最後のパケットの受信と上記チャンクのレンダリングの開始との間の時間である。この処理時間は、プレーヤの各々のタイプに固有である。

望ましくは、本方法は、
ｄ）のステップにおいて、上記要求されたチャンクを上記配信時点で配信できない場合、更なるステップ、すなわち、
ｇ）上記要求されたチャンクを破棄するステップと、
ｈ）上記第２のコンテンツ・ストリーム内の上記要求されたチャンクの次のチャンクについて、ｂ）からｄ）のステップを繰り返すステップと、
を備える。

本発明の特定の一実施形態において、上記第１のコンテンツ・ストリームと上記第２のコンテンツ・ストリームが同一のコンテンツを搬送する。

これは、ブロードバンド・ネットワークの場合、複数の端末が同一コンテンツを同時にレンダリングすることを保証する必要がある時、特に魅力的である。

本発明は、第２の装置による第２のコンテンツ・ストリームのレンダリングが、第１の装置による第１のコンテンツ・ストリームのレンダリングに同期化されるように上記第２の装置における上記第２のコンテンツ・ストリームのレンダリングのタイミングを制御する制御装置であって、本発明の方法のステップを実行するように構成された制御装置も提供する。

第１の実施形態に従えば、上記制御装置は、ホーム・ゲートウェイ又はセットトップ・ボックスである。

第２の実施形態に従えば、上記制御装置は、プロキシ・サーバである。

例えば、このプロキシ・サーバは、ブロードバンド・ネットワークを介して複数の端末に配信されるビデオ・ストリームのレンダリングのタイミングを制御することによって、例えば、同一場所にいる全てのユーザが、同時に、あるイベントを知ることを保証する。その場合、レンダリングのタイミングは、全ての端末を最も遅いものに同期化するように、選択してもよい。また、ライブ・イベントのビデオレンダリングをこのイベントのテキスト解説又は音声コメントに同期化することを決めることも可能である。端末が移動している場合、レンダリングは、それらの端末が特定の位置に到着した時に、開始できる。

本発明に従う方法は、プログラム可能装置においてソフトウェアの形態で実施してもよい。また、この方法は、単独でハードウェアの形態又はソフトウェアの形態、あるいは、それらの組み合わせの形態で実施してもよい。

本発明は、ソフトウェアの形態で実施できるので、プログラム可能装置用のコンピュータ読み取り可能コードとして、任意の適切な搬送媒体上に、具現化できる。搬送媒体は、例えば、フロッピー（登録商標）ディスク、ＣＤ―ＲＯＭ、ハード・ディスク・ドライブ、磁気テープ装置、又は、固体メモリ装置のような記憶媒体などで構成されていてもよい。

本発明は、したがって、コンピュータが本発明の方法を実施できるようにするコンピュータ実行可能命令を備えたコンピュータ読み取り可能プログラムを提供する。図３には、そのようなコンピュータ・プログラムについての概括的なアルゴリズムの一例が示されている。

本発明は、以下に記す添付図面において、本発明を限定するものとしてではなく、例として示されており、これらの図面において同じ参照番号は同じ構成要素を指している。
本発明に従う方法を実施するシステムの一実施形態の概略的な図である。 本発明の一実施形態に従う制御装置の概略的な図である。 本発明の一実施形態に従う方法のステップを示すフローチャートである。 本発明の一実施形態に従う配信時の演算を例示するタイム・ラインである。

図１を参照すると、そこには、本発明の推奨実施形態に従う同期化システム２の概略図が示されている。

同期化システム２は、ユーザ宅内に位置する、メイン装置４と称される第１の装置と、補助装置６と称される第２の装置とを備えている。メイン装置４は、例えば、ユーザにとってのメイン・ディスプレイを構成するＴＶ受像機であり、一方、補助装置６は、例えば、スマートフォン、ＰＣラップトップ、又は、タブレットである。これは、ビデオ・プレーヤを備えており、ユーザによってセカンド・スクリーン（第２のスクリーン）装置として使用される。

メイン装置４上に表示されるコンテンツは、オリジナルの（本来の）コンテンツ・サーバから（図示せず）放送ネットワークを介して受信される。このような放送コンテンツ、例えばＤＶＢ―Ｔ又はＤＶＢ―Ｃマルチメディア・ストリームを受信するために、メイン装置４はアンテナ８につながれている。また、メイン装置４は、インターネット１４に接続されたホーム・ゲートウェイ１２にもホーム・ネットワーク１０を介して接続されている。

メイン装置４に表示されるコンテンツは、リモート又はローカルのオーディオ及び／又はビデオのサーバ、ビデオ・ファイル、ＤＶＤ、ブルーレイ・ディスクなどからのストリーミングのように任意のローカル又はリモートのソース（供給源）によっても提供され得る。このために、メイン装置４は、ローカルのコンテンツ供給源１６、例えばＤＶＤ及び／又はブルーレイのリーダにも接続されている。

メイン装置４は、オーディオ／ビデオ・データと、上記メイン装置４にレンダリングされるＴＶ番組内の現在の再生位置の特定を可能にする関連メタデータと、を受信する。

補助装置６もホーム・ネットワーク１０に接続されている。したがって、これは、オリジナル・コンテンツ・サーバのコンテンツに関連するコンテンツを収容している補完コンテンツ・サーバ１８に、ホーム・ゲートウェイ１２及びインターネット１４を介して、接続されている。

補完コンテンツ・サーバ１８は、ビデオ・データ・パケットから成るチャンク（まとまり）に編成された補助コンテンツ・ストリームを、ホーム・ゲートウェイ１２を介して、補助装置６に供給できる。

補完サービスへのアクセスは、例えば、放送ネットワークから受信される放送ストリームに組み込まれた情報により、ホーム・ゲートウェイ１２によって補助装置６に供給される。

別の一実施形態では、補助装置６について、補完コンテンツ・サーバ１８によって提供される補助コンテンツはウェブサイトからアクセス可能であり、このウェブサイトは、メイン装置４に受信される放送コンテンツに緊密に結び付けられているので、ユーザによって容易に識別される。このウェブサイトは、放送提供事業者のウェブサイトか、あるいは、オリジナル・コンテンツ・サーバから提供されるメイン・コンテンツを作成したスタジオのウェブサイトであってもよい。このウェブサイトは、例えば、使用コーデック、符号化ビットレート、ビデオ解像度、マーカ、キャプション、および、補助コンテンツ・ストリームのチャンクのＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒｓ）などを列挙することによって利用可能ストリームを記述したマニフェスト・ファイルのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を提供する。このマニフェスト・ファイルは、ＤＡＳＨ (Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ)においてＭｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ（ＭＰＤ）と呼ばれる。例えば、アドビ、アップル、マイクロソフトなどから提供されるプロプラエタリ（所有権主張可能）適応ストリーミング・ソリューションにおいては、別のマニフェスト・ファイルが使用される。

ユーザ宅のこれらの装置により、ユーザは、メイン装置４によってレンダリングされる、オリジナル・コンテンツ・サーバを供給源とする第１のマルチメディア・ストリームを受信でき、且つ、補助装置６によってレンダリングされる、補完サーバ１８を供給源とする第２のマルチメディア・ストリームを受信できる。

ユーザが互いに関連するコンテンツを装置４と６の両方で同時に受信したいと思うことがあり得る。例えば、ユーザが、スポーツ又は音楽イベントの代替映像を、メイン装置４に表示されるメイン・コンテンツに関連して、受信して補助装置６にレンダリングしたいと思うことがあり得る。

ここでは、補助装置６によってレンダリングされるオーディオ／ビデオ補完コンテンツは、補完コンテンツ・サーバ１８からホーム・ゲートウェイ１２に適応ＨＴＴＰストリーミングで配信される。

本発明の同期化システム２、更に詳しくは、ホーム・ゲートウェイ１２は、両コンテンツを同時に装置４と６にレンダリングするために、両コンテンツの完全な同期化を可能にする。

実際、ホーム・ゲートウェイ１２は、ホーム・ネットワーク１０に接続された全ての装置にアクセスでき、且つ、全ての入来及び／又は送出インターネット・トラフィックをルーティングできるので、特権的な立場にある。

望ましくは、ホーム・ゲートウェイ１２は、透過的なプロキシ・モードに構成されている。このような構成において、ホーム・ゲートウェイ１２は、宅内の装置４と６についての特定の構成なしに、インターネット通信をインターセプトできる。ホーム・ゲートウェイ１２は、ウェブ・サービス由来のデータ又はウェブ・サービス向けのデータを分析又は調整できる。

図２に表されているように、ホーム・ゲートウェイ１２は、メイン装置４においてレンダリングされているメイン・コンテンツ・ストリームのメイン・タイミング位置、すなわち、再生位置を識別する識別モジュール２２を備えている。

したがって、識別モジュール２２は、メイン装置４から情報を取得できる。識別モジュール２２は、メイン装置４においてレンダリングされているＴＶ番組内で受信されるメイン・タイミング位置の他に、放送ストリーム内において配信される全てのメタデータを取得できる。識別モジュール２２は、これらのメタデータのうち、メイン装置４において現在消費されているＴＶ番組に関連付けられたセカンド・ビュー（第２の画像）を提供するウェブ・サービスへのアクセスを可能にするＵＲＬを識別できる。

また、ホーム・ゲートウェイ１２には、補助装置のレンダリングをメイン装置のレンダリングに同期化するために、補完コンテンツ・サーバ１８から送信される補助コンテンツ・ストリームの次のチャンクを補助装置６に配信すべき配信時を、上記メイン・タイミング位置を用いて、特定する特定モジュール２４も備えられている。

更に、ホーム・ゲートウェイ１２には、ビデオ・コンテンツを格納するバッファ２６と、適応ＨＴＴＰストリーミングを用いて補助装置６にビデオ・コンテンツを配信する配信モジュール２８とが備えられている。

図３は、一推奨実施形態に従う本発明の方法のステップを例示するフローチャートである。

ユーザがセカンド・ビュー（第２の画像）サービスを選択すると、ステップ３２において、ＨＴＴＰ Ｇｅｔ要求が、マニフェスト・ファイルを得るために、ホーム・ゲートウェイ１２を介して補完コンテンツ・サーバ１８に送られる。

ホーム・ゲートウェイ１２には、イン・バンド（帯域内）で、例えば、文献国際公開第２０１２／０４９３０５号に規定されているようなタイムライン・コンポーネント、あるいは、電子透かしデータを用いて、あるいは、アウト・オブ・バンド（帯域外）で、例えばＥＰＧ（電子番組ガイド）を用いて配信されるＴＶ番組のメタデータが提供されており、直接的に、すなわち、マニフェストＵＲＬがこのメタデータ内に示されており、あるいは、間接的に、すなわち、メタデータが、マニフェストＵＲＬを取得するための情報を提供しているため、このマニフェスト・ファイルへのＵＲＬはホーム・ゲートウェイ１２に既知である。

ステップ３４において、サーバ１８は要求の受領通知を行う。ステップ３６において、サーバ１８は、マニフェスト・ファイルを返送する。

ホーム・ゲートウェイ１２は、マニフェスト・ファイルが補完サーバ１８によって返送されると、ステップ３８において、それをインターセプトして転送する。ホーム・ゲートウェイ１２は、この記述マニフェスト・ファイルに含まれている情報によって、自分自身で補助コンテンツのビデオ・チャンクを要求できる。

ステップ４０において、補助装置６は、マニフェスト・ファイルの受領通知を行う。

補助装置プレーヤは、マニフェスト・ファイル、すなわち、ＤＡＳＨ用語法におけるＭＰＤを解釈すると、ステップ４２において、ＨＴＴＰ Ｇｅｔ要求を補完サーバ１８に送る。補助装置プレーヤは、補助コンテンツ・ストリームを放送ＴＶ番組に同期化するための指標を持たないので、サーバ１８に対して補助ストリームの１番目のチャンクを要求する。

ステップ４４において、このＨＴＴＰ要求は、ホーム・ゲートウェイ１２によってインターセプトされる。ホーム・ゲートウェイ１２は、インターセプトしたマニフェスト・ファイルを通じて、メイン装置４によってレンダリングされるＴＶ番組の現在位置を受けとり、ビデオ・チャンクのサイズを知り、メイン装置のレンダリングに同期して再生されるべき次のチャンクに対するオフセットを計算する。ホーム・ゲートウェイ１２は、補完コンテンツ・サーバ１８向けの新たなＨＴＴＰ Ｇｅｔ要求を生成する。例えば、レンダリングされるべき次のチャンクがインデックス１００に在ると仮定する。

補完コンテンツは、補完サーバ１８において、各々のチャンク位置が十分に識別される単一ファイルに、あるいは、各々が各々のチャンクに対応する一連のファイルに、記憶されている場合がある。前者の場合、クライアントがあるチャンクを要求する際、クライアントはＨＴＴＰ Ｇｅｔ要求内にそのバイト範囲を示すことになる。後者の場合、クライアントは、単に所望のチャンクを含んでいるファイルを要求すればよい。

ステップ４６において、補完コンテンツ・サーバ１８は、チャンク要求の受領通知を行う。次に、ステップ４８において、補完コンテンツ・サーバ１８は、上記チャンク要求に対して、上記前者の場合ではＨＴＴＰ部分的コンテンツ応答によって、上記後者の場合ではＯＫ応答によって、応答する。

この種の応答は、補完サーバ１８がリソースに対するＧＥＴ要求を実行したことを示す。この応答には、供給されるバイト数を示すＣｏｎｔｅｎｔ―Ｒａｎｇｅ又はＣｏｎｔｅｎｔ―ｌｅｎｇｔｈヘッダ・フィールドが含まれている。例えば、チャンク番号１００は、１２４８３２バイトのサイズを有することがある。

ここで、チャンクは、図３においてａｋａセグメントと呼ばれ、パート１、パート２、・・・パートｎという名前が付けられた数個のＴＣＰパケットの形態で配信される。

要求されたビデオ・チャンクは、それが補助装置６に完全に配信された時のみ、表示され得る。換言すれば、これは、補助装置６におけるビデオのレンダリングが、この装置がこのビデオの次のチャンクの最後のバイトを受信した時点によって決まる、ことを意味している。本発明がセカンド・ビューをメイン装置４に同期化することを可能にするのは、補助装置６に対するこの最後のバイトの配信を制御することによって、実現される。

更に詳しくは、ホーム・ゲートウェイ１２は、各々のパケット・ヘッダを分析することによって、補完コンテンツ・サーバ１８によって配信されたバイト数を計算する。

最後のデータ・パケット（図３ではパートｎ）が、受信時点ＴｏＲでホーム・ゲートウェイ１２に到着すると、ステップ５０において、上記最後のデータ・パケットは、ホーム・ゲートウェイ１２によって決定される配信時点ＴｏＤまで、ホーム・ゲートウェイ１２によってバッファリングされる。このバッファリングの持続期間を待ち時間ＷＴと呼ぶ。

ステップ５２において、ホーム・ゲートウェイ１２による補助装置６へのビデオ・チャンクの最後のパートの配信が適切な時点で行われ、補助装置プレーヤが、メイン装置４と同期してレンダリングを開始する。

図４において、Ｔ_０は、ビデオ・チャンクのレンダリングが、メイン装置４に現在表示されているコンテンツに完全に同期化させるために開始されるべき時点である。チャンクの最後のパケットは、このチャンクがレンダリングされるべき時から、ホーム・ネットワークでは通常無視できるホーム・ゲートウェイ１２と補助装置６との間の伝送に因る遅延と、補助装置６による処理の期間ＰＴとを差し引いた時点で、ホーム・ゲートウェイ１２によって補助装置６に送られる。

補助装置６によるこの処理時間ＰＴは、上記装置内のビデオ・プレーヤのタイプに固有のものである。レンダリングのタイミングを正確に制御するために、ホーム・ゲートウェイ１２は、ビデオ・レンダラとして使用されるブラウザ・プラグインを自動的に識別する。各々の商用ソリューションは、それぞれ独自のプレーヤを有する。ＳｉｌｖｅｒｌｉｇｈｔとＱｕｉｃｋＴｉｍｅが、それぞれマイクロソフトとアップルに適応するストリーミング・ソリューションについてのそのようなプレーヤの２つの例である。この種々のソリューションは、たとえＤＡＳＨ規格に準拠していても、マニフェスト・ファイルのそれぞれ独自のフォーマットを使用しており、当該マニフェスト・ファイルは、メディア・フォーマット、すなわち、例えば、ビデオ・コーデック、利用可能ビットレート及びオーディオ／ビデオ・ファイルＵＲＬなどを記述する。補助装置６がステップ３２において要求したマニフェスト・ファイルの分析によって、ホーム・ゲートウェイ１２は、どの適応技術が使用されているか、その結果、どのプレーヤが使用されているかを、ストリーミングの開始前に特定できる。

詳細な例として、補助装置６内のプレーヤは、ＨＴＭＬ５（ＨｙｐｅｒＴｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ５）ビデオ・プレーヤである。ＨＴＭＬ言語のこのバージョンは、プラグインの実行を必要としないことによってビデオ処理能力を改善することを目指し、且つ、ＨＴＭＬの以前のバージョンでは可能でなかったビデオとウェブ・ページ上のその他の要素との間のインタラクションを創出することへの扉を開くものである。ＨＴＭＬ５の使用は、ビデオ・チャンクを取り出すために補助装置がステップ３２において送信するＨＴＴＰ Ｇｅｔ内に提供される情報を通じても、識別できる。

多くの使用事例において、端末内で使用されるプラグインのタイプを考慮せずに処理時間を見積もればそれで十分であり得る。

もしチャンクの伝送時に問題が生じて、その結果、チャンクの最後のパートが、完全な同期化を保証する適切な時点で配信できない場合には、ホーム・ゲートウェイ１２は、自発的に、現在のチャンクを破棄して、その次のチャンクを補完コンテンツ・サーバ１８に要求する。

チャンクを完全に受信した後に、補助装置プレーヤは、ステップ５４において、ＨＴＴＰ Ｇｅｔ要求を補完サーバ１８に送信する。補助装置プレーヤは、チャンクのインデックスについての指標を持たないので、補助ストリームの２番目のチャンクをサーバ１８に要求する。

ステップ５６において、このＨＴＴＰ要求はホーム・ゲートウェイ１２によってインターセプトされ、上記ホーム・ゲートウェイ１２は、補完コンテンツ・サーバ１８に対する、インデックス１０１を有するチャンクについての新たなＨＴＴＰ Ｇｅｔ要求を生成する。

以上、現時点で本発明の推奨実施形態であると考えられるものを例示して説明したが、当業者であれば、本発明の真の権利範囲から逸脱することなく、様々なその他の変更を行い、等価物と置き換えられることを理解できるであろう。更に、ここに説明した中核を成す創意に富んだ構想から逸脱することなく、多くの変更を行うことによって、特定の状況を本発明の開示事項に適応化できる。また、本発明の一実施形態は、上述の特徴の全ては含んでいないかもしれない。したがって、本発明は、ここに開示した特定の実施形態には限定されず、巻末の特許請求の範囲の請求項の権利範囲内にある全ての実施形態を含むことを意図するものである。

例えば「〜を備えている」、「〜を含む」、「〜を組み込む」、「〜から成る」、「〜である」、及び、「〜を有する」といった表現は、本明細書の記載とそれに対応付けられた特許請求の範囲の請求項の記載とを解釈する際には、非排他的に解釈されるべきである。単数形に言及しているものは、複数形に言及しているものとしても解釈すべきであり、その逆も同様である。

当業者であれば、本発明の権利範囲から逸脱することなく、本明細書に開示された種々のパラメータを改変でき、また、本明細書に開示された、及び／又は、特許請求の範囲の請求項に記載された種々の実施形態を組み合わせられることを容易に理解できるであろう。

例えば、上述の説明では、本発明に従う同期化は、ホーム・ゲートウェイによって実行された。しかしながら、本発明の方法は、利点として、セットトップ・ボックスによって実施できる。

更に、上述の説明は、ユーザのホーム・アプリケーションについての本発明の使用に関するものであったが、本発明は、利点として、公共施設、例えば、空港、駅、病院などにおけるセカンド・スクリーン・アプリケーションについて使用してもよい。

また、本発明は、プロキシ・サーバによって、ブロードバンド・ネットワークを介して配信される相異なるビデオ・ストリームのレンダリングのタイミングを制御することにも適用できる。そのような制御は、例えば、同一場所にいる全てのユーザが、同時に、あるイベントを知ることを保証するのに必要であり得る。

プロキシ装置は、自己が担当する端末の要求を分析することによって、自己が現在管理しているストリームを識別できる。今、第１の端末が、ウェブ・サーバからＨＴＴＰ適応ストリーミング・モードで配信される第１のストリームを消費していると考えてみよう。第２の端末が同一イベントの第２のストリームを要求すると、プロキシ・サーバは、第１の端末に現在配信されているチャンクのタイミング位置を検査する。プロキシ・サーバは、第１の端末内で使用されているプレーヤ・タイプを知ることによって、この第１の端末で現在レンダリングされているコンテンツの時間位置を特定できる。したがって、本発明の方法を適用して第２の端末にオーディオ／ビデオ・コンテンツを配信することによって、両端末に表示されるコンテンツが同期化されることが保証される。同じ同期化メカニズムが３台以上の端末にも適用できることは明らかである。

Claims (10)

1. 第２の装置（６）における第２のコンテンツ・ストリームのレンダリングのタイミングを制御する方法であって、前記第２のコンテンツ・ストリームがチャンクの形態に構成されており、各々の前記チャンクが前記第２のコンテンツ・ストリームの個別にアクセス可能なパートに対応しており、各々の前記チャンクがデータ・パケットを含み、前記方法が、制御装置（１２）によって実行されるステップであって、
   ａ）前記第２の装置（６）から前記第２のコンテンツ・ストリームのチャンクの要求を受信するステップ（４２）と、
   ｂ）第１の装置（４）においてレンダリングされている第１のコンテンツ・ストリームの再生位置に基づいて前記第２のコンテンツ・ストリーム内の前記要求されたチャンクの第２の位置を特定するステップ（４４）と、
   ｃ）サーバ（１８）から前記要求されたチャンクのパケットを受信するステップ（４８）と、
   ｄ）前記第２の装置（６）による前記第２のコンテンツ・ストリームのレンダリングが、前記第１の装置（４）による前記第１のコンテンツ・ストリームのレンダリングに同期化されるように前記要求されたチャンクが前記第２の装置（６）に配信されるべき配信時点（ＴｏＤ）で、前記要求されたチャンクを前記第２の装置（６）に配信するステップであって、前記配信時点（ＴｏＤ）が前記第２の位置に関連づけられる、該ステップと、
   を備えた、前記方法。
2. 前記配信するステップが適応ストリーミング・プロトコルを使用する、請求項１に記載の方法。
3. 前記制御装置（１２）によって実行されるステップであって、
   ｅ）前記要求されたチャンクの最後のパケットを除く前記要求されたチャンクの前記パケットを前記第２の装置（６）に送信するステップ（４８）と、
   ｆ）前記要求されたチャンクの前記最後のパケットをバッファリングするステップ（５０）と、
   を更に備え、ｄ）の前記配信するステップが、前記配信時点（ＴｏＤ）で、前記要求されたチャンクの前記最後のパケットを前記第２の装置（６）に配信すること（５２）を含む、請求項１又は２に記載の方法。
4. 前記第２の装置（６）による前記要求されたチャンクの処理に必要な時間（ＰＴ）を特定する更なるステップを備えた、請求項１から３のうちの１つの請求項に記載の方法。
5. ｄ）のステップにおいて、前記要求されたチャンクを前記配信時点（ＴｏＤ）で配信できない場合、
   ｇ）前記要求されたチャンクを破棄するステップと、
   ｈ）前記第２のコンテンツ・ストリーム内の前記要求されたチャンクの次のチャンクについて、ｂ）からｄ）のステップを繰り返すステップと、
   を更に備えた、請求項１から４のうちの１つの請求項に記載の方法。
6. 前記第１のコンテンツ・ストリームと前記第２のコンテンツ・ストリームが同一のコンテンツを搬送する、請求項１から５のうちの１つの請求項に記載の方法。
7. 第２の装置（６）による第２のコンテンツ・ストリームのレンダリングが、第１の装置（４）による第１のコンテンツ・ストリームのレンダリングに同期化されるように前記第２の装置（６）における前記第２のコンテンツ・ストリームのレンダリングのタイミングを制御する制御装置（１２）であって、請求項１から６のうちの１つの請求項のステップを実行するように構成された制御装置。
8. 前記制御装置（１２）は、ホーム・ゲートウェイ又はセットトップ・ボックスである、請求項７に記載の制御装置。
9. 前記制御装置（１２）は、プロキシ・サーバである、請求項７に記載の制御装置。
10. コンピュータが請求項１から６のうちの１つの請求項に記載の方法を実施できるようにするコンピュータ実行可能命令を備えたコンピュータ読み取り可能プログラム。

Images