JP5905957B2 - 空間的にセグメント化されたコンテンツの配信 - Google Patents

Description

本発明は、空間的にセグメント化されたコンテンツの配信に関し、更に特定すれば、空間的にセグメント化されたコンテンツを処理するための方法およびシステム、空間的にセグメント化されたコンテンツを配給するように構成されたコンテンツ配信ネットワーク、空間的にセグメント化されたコンテンツを処理するように構成されたクライアント、クライアントまたはコンテンツ配信ネットワークにおいて空間的にセグメント化されたコンテンツを制御するためのデータ構造、およびこのような方法を用いるコンピュータ・プログラム生産物に関するが、これらで全てではない。

従来技術

広角で非常に解像度が高いビデオ・コンテンツの取り込みおよび送信を可能にする新製品(new product equipment)が入手可能になり始めている。このようなメディア・ファイルの処理には、高い帯域幅（Gbpsp単位）が必要となり、このようなビデオ・ストリームにおける情報全体を利用するには、 通例、ビデオ・ウォールまたは投射画面のサイズとなる、大きなビデオ画面を使用しなければならない。

比較的小さなディスプレイ上でビデオを見るとき、ユーザはビデオ・フレーム全体や、その中に含まれる全ての情報を見ることができない。代わりに、ユーザは、彼または彼女の好みに基づいて、ユーザ機器のグラフィカル・ユーザ・インターフェースと対話処理することによって、特定のフレーム・エリア、視角、またはビデオ解像度を選択する。現在のネットワーク容量ではこれらのＨＤを超える解像度の広帯域幅要求に応じることができないという事実とは別に、どのようにしても画面上に表示できないコンテンツを配信することは、単に非効率的である。

Mavlankar et al.は、"An interactive region-of-interest video streaming system for online lecturing viewing"（オンライン講義視聴のためのインタラクティブ関心領域ビデオ・ストリーミング・システム）, proceeding of ICIP 2010, p.4437-4440という論文において、いわゆるタイル状ビデオ・システム(tiled video system)について記載しており、サーバ・ベースのインタラクティブ関心領域(region-of-interest)エンコーダを用いて、ビデオ・コンテンツ・ファイルの多数の解像度のレイヤを生成する。各レイヤは、多数の空間的セグメントまたはタイルに分割され、各タイルは、互いに独立してエンコードおよび配給（即ち、ストリーミング）することができる。

ビデオ・クライアントは、特定の空間領域、即ち、関心領域（ＲＯＩ）を要求することができ、サーバは続いてこのＲＯＩ要求を１つ以上のセグメントにマッピングして、選択したグループのタイル状ストリームをクライアントに送信することができる。クライアントは、このタイル状ストリームを組み合わせて１つのビデオにするように構成される。このようにして、表示されるコンテンツの解像度に関して妥協を必要とせずに、帯域幅に関して効率的に、表示コンテンツとのユーザ対話処理、例えば、ズーミングおよびパンニングを達成することができる。このような方式では、しかしながら、タイル状(tiled)ストリームの高速応答および処理が、サービス品質(quality of service)および最適なユーザ体験を配信するために必要となる。

このようなサービスを既存の大規模コンテンツ配信方式において実現するときに、問題が発生する虞がある。通例、コンテンツ・プロバイダは、コンテンツを直接消費者に配信しない。代わりに、コンテンツはコンテンツ・ディストリビュータに送られ、コンテンツ・ディストリビュータがコンテンツ配信ネットワーク（ＣＤＮ）を用いてコンテンツを消費者に配信する。ＣＤＮは、空間的にセグメント化されたコンテンツを扱うように構成されていない。更に、空間的にセグメント化されたコンテンツをクライアントに配信するための既知の解決策は（Mavlankarの論文に記載されているような解決策）、既存のＣＤＮと共に使用するには適していない。空間的にセグメント化されたコンテンツを異なる場所に格納することもあるＣＤＮにおいて、ＲＯＩ要求を解決する(resolve)ために既知のサーバ・ベースの解決策を実施しても、スケーラブルな解決策(scalable solution)が提供されず、過剰負荷や遅延の状況というような望ましくない影響が生じやすくなり、このようなサービスの現実を著しく阻害する虞がある。

更に、Mavlankarによって記載された、サーバ・ベースＲＯＩ／タイル・マッピング手法では、ブロードキャストまたはマルチキャストをアクセス技術（媒体）として用いて一部の空間的セグメント（セグメント・ストリーム）を受信し、他の一部の空間的セグメントは、例えば、ユニキャストをアクセス技術として用いて受信するというような状況では、クライアントは、２つの別個のアクセス方法／プロトコルによって、コンテンツにアクセスすることができない。Mavlankarのサーバ・ベースＲＯＩマッピング・メカニズムでは、異なるアクセス技術および／またはアクセス・プロトコルによってセグメント化コンテンツを受信するクライアント側能力の正確な知識が得られない。

更に、様々な空間的セグメント化ストリームに基づいてビデオ・ストリームを扱い表示するためには、多数の空間的セグメント・ストリームに基づいてシームレスなビデオ画像の表示を可能にし、表示されたコンテンツとのユーザの対話処理を可能にするためには、クライアントにおいて特定の機能を実装する必要がある。

したがって、先行技術には、クライアントに効率的に空間的セグメント化コンテンツを配信するという要望がある。具体的には、従来のＣＤＮインフラストラクチャに変更を加える必要なく、コンテンツの配信を可能にし、高解像度ビデオ・コンテンツと対話処理するユーザにスケーラブルで柔軟性のある解決策を提供することができる、空間的セグメント化コンテンツの配信方法およびシステムが求められている。

本発明の目的は、先行技術において知られている欠点の少なくとも１つを低減または解消すること、そして本発明の第１の態様において、空間的にセグメント化されたコンテンツを処理する方法を提供することである。この方法は、クライアントがソース・ストリームについて１つ以上の表現を含む空間的マニフェスト・データ構造を受信するステップであって、各空間的表現が、１つ以上の空間的セグメント・ストリームと１つ以上の配信ノードを位置特定するための位置情報とを識別し、このような１つ以上の配信ノードが、好ましくは、コンテンツ配信ネットワークに関連付けられ、前記１つ以上の空間的セグメント・ストリームを前記クライアントに送信するように構成される、ステップと、前記空間的表現の内少なくとも１つに関連付けられた１つ以上の空間的セグメント・ストリームを選択し、前記位置情報に基づいて、好ましくは前記コンテンツ配信ネットワークに関連付けられた、前記少なくとも１つの配信ノードに、前記少なくとも１つの選択された空間的セグメント・ストリームを前記クライアントへ配信することを要求するステップと、前記１つ以上の選択された空間的セグメント・ストリームを前記少なくとも１つの配信ノードから受信するステップとを含む。

空間的マニフェスト・データ構造（ファイル）は、ビデオ・データのズーミング、ティルティング、およびパンニングを含む、効率的なクライアント・ベースのビデオ操作動作(action)を可能にする。ネットワーク、特にＣＤＮにおける機能は、先行技術の解決策と比較すると、簡素なままに保つことができる。

一実施形態では、前記空間的マニフェスト・データ構造が、更に、前記空間的セグメント・ストリームにおける空間的セグメント・フレームを縫合して表示用ビデオ・フレームを得るための位置決め情報も含むこともできる。

他の実施形態では、前記空間的マニフェスト・データ構造が、前記ソース・ストリームの第１解像度バージョンに関連付けられた少なくとも１つの第１空間的表現と、前記ソース・ストリームの第２解像度バージョンに関連付けられた少なくとも１つの第２空間的表現とを含むこともできる。

一実施形態では、前記空間マニフェスト・データ構造が、第１数のセグメント・ストリームに関連付けられた第１空間的表現を含み、前記第２空間的表現が第２数のセグメント・ストリームを含むこともできる。

他の実施形態では、前記方法が、更に、前記１つ以上の選択された空間的セグメント・ストリームをバッファするステップと、前記１つ以上の空間的セグメント・ストリームに関連付けられた同期情報を受信するステップと、前記同期情報に基づいて、前記１つ以上の要求された空間的セグメント・ストリームを同期させるステップとを含むこともできる。

一実施形態では、前記方法が、位置情報に基づいて、前記空間的に整列した空間的セグメント・フレームを縫合して、再生のための連続ビデオ・フレームを得るステップを含むこともできる。

更に他の実施形態では、前記１つ以上の要求された空間的セグメント・ストリームが、適応ストリーミング・プロトコル、好ましくは、ＨＴＴＰ適応ストリーミング・プロトコルを用いて、前記クライアントに送信されるのでもよく、前記空間的セグメント・ストリームの少なくとも一部が時間セグメントに分割される。

更にまた他の実施形態では、前記１つ以上のセグメント・ストリームが、前記クライアントにＲＴＰストリーミング・プロトコルを用いて送信されるのでもよく、同期情報がＲＴＳＰシグナリング・メッセージにおいて前記クライアントに送信される。

更に他の実施形態では、前記空間的マニフェスト・データ構造が、１つ以上のアクセス技術またはプロトコル（例えば、ユニキャスト、マルチキャスト、ブロードキャスト）への参照を含み、前記参照が、好ましくは、１つ以上の、好ましくは空間的な、セグメント・ストリームに関連付けられる。

更に他の実施形態では、前記１つ以上のセグメント・ストリームが、前記アクセス技術および／またはアクセス・プロトコルの内１つ以上を用いて、前記クライアントに送信されるのでもよい。例えば、一部のセグメント・ストリームは、ブロードキャスト媒体（例えば、ブロードキャスト、マルチキャスト）をアクセス技術として用いて送信してもよく、一方他の一部のセグメント・ストリームは、ユニキャストをアクセス技術として用いて送信してもよい。

更に他の実施形態では、空間マニフェスト・データ構造（ファイル）が、マルチキャストまたはブロードキャストのような、ブロードキャスト媒体によって、好ましくはクライアントによって受信されるのでもよい。

更に他の実施形態では、空間的マニフェスト・データ構造（ファイル）が、多数の受信機（例えば、クライアント）に同時に、ブロードキャスト媒体（例えば、シミュルキャスト(simulcast)）によって送信されるのでもよい。

更に他の態様では、本発明は、メディア処理デバイスにおけるクライアントによってユーザに表示される、空間的にセグメント化されたコンテンツとのユーザ対話処理方法に関する。この方法は、ソース・ストリームについて１つ以上の空間的表現を含む空間マニフェスト・データ構造を受信するステップであって、各空間的表現が、１つ以上の空間的セグメント・ストリームと、コンテンツ配信ネットワークに関連付けられた１つ以上の配信ノードを位置特定するための位置情報とを識別し、コンテンツ配信ネットワークが前記１つ以上の空間的セグメント・ストリームを前記クライアントに送信するように構成される、ステップと、前記位置情報および前記空間的マニフェスト・データ構造に基づいて、第１空間的表現に関連付けられた１つ以上の空間的セグメント・ストリームを前記コンテンツ配信ネットワークから抽出して、前記１つ以上の空間的セグメント・ストリームを表示するステップと、関心領域に関連付けられたユーザ入力を受けるステップであって、前記関心領域が、前記表示された空間的セグメント化コンテンツから選択したエリアを定める、ステップと、前記空間的セグメント・データ構造における位置決め情報および前記関心領域に基づいて、１つ以上のメディア処理判断基準にしたがって、第２空間的表現を決定するステップであって、前記処理判断基準が、好ましくは、帯域幅、画面解像度、および／またはエンコーディング品質の内少なくとも１つを含む、ステップとを含む。

一実施形態では、前記方法が、更に、前記１つ以上の空間的表現について、前記選択した関心領域と重複する前記空間的セグメント・フレームを判定するステップを含むこともできる。

更に他の態様では、本発明は、少なくとも１つのソース・ノードから発する空間的にセグメント化されたコンテンツを、第１コンテンツ配信ネットワークに収集する方法に関することができ、前記少なくとも１つのソース・ノードが、好ましくは、第２コンテンツ配信ネットワークに関連付けられる。この方法は、ソース・ストリームについて１つ以上の空間的表現を含む空間的マニフェスト・データ構造を受信するステップであって、各空間的表現が、１つ以上の空間的セグメント・ストリームと、コンテンツ配信ネットワークに関連付けられた１つ以上の配信ノードを位置特定するための位置情報とを識別し、コンテンツ配信ネットワークが前記１つ以上の空間的セグメント・ストリームを前記クライアントに送信するように構成され、前記少なくとも１つのソース・ノードが、前記１つ以上の空間的セグメント・ストリームを前記第１コンテンツ配信ネットワークに送信するように構成される、ステップと、前記少なくとも１つの空間的セグメント・ストリームを、前記第１コンテンツ配信ネットワークにおける１つ以上の配信ノードに配給するステップと、前記１つ以上の配信ノードに関連付けられた位置情報を前記空間的マニフェスト情報に追加することによって、前記空間的マニフェスト情報を更新するステップとを含む。

他の態様では、本発明は、空間的にセグメント化されたコンテンツを配給するように構成されたコンテンツ配給ネットワークに関することができる。このネットワークは、制御機能と、収集ノードと、１つ以上の配信ノードとを含み、前記制御機能が、ソース・ストリームについて１つ以上の空間的表現を含む空間的マニフェスト・データ構造を受信するように構成され、各空間的表現が、１つ以上の空間的セグメント・ストリームと、前記１つ以上の空間的セグメント・ストリームを前記クライアントに送信するように構成されたコンテンツ配信ネットワークに関連付けられた１つ以上の配信ノードを位置特定するための位置情報とを識別し、前記制御機能が、前記位置情報に基づいて、前記１つ以上の空間的セグメント・ストリームを前記１つ以上のソース・ノードに要求するように構成され、前記収集ノードが、前記１つ以上の空間的セグメント・ストリームを前記１つ以上のソース・ノードから受信するように構成され、前記１つ以上の配信ノードが、前記１つ以上の収集された空間的セグメント・ストリームを受信するように構成される。

更に他の態様では、本発明は、ソース・ストリームについて１つ以上の空間的表現を含む空間的マニフェスト・データ構造を受信するように構成された制御機能に関することができ、各空間的表現が、１つ以上の空間的セグメント・ストリームと、コンテンツ配信ネットワークに関連付けられた１つ以上の配信ノードを位置特定するための位置情報とを識別し、コンテンツ配信ネットワークが前記１つ以上の空間的セグメント・ストリームを前記クライアントに送信するように構成され、更に、前記位置情報に基づいて、前記１つ以上の空間的セグメント・ストリームを前記１つ以上のソース・ノードに要求するように構成される。

更に、本発明は、空間的にセグメント化されたコンテンツを処理するためのクライアントに関することができ、ソース・ストリームについて１つ以上の空間的表現を含む空間的マニフェスト・データ構造を受信するように構成され、各空間的表現が、１つ以上の空間的セグメント・ストリームと、コンテンツ配信ネットワークに関連付けられた１つ以上の配信ノードを位置特定するための位置情報とを識別し、コンテンツ配信ネットワークが前記１つ以上の空間的セグメント・ストリームを前記クライアントに送信するように構成され、１つ以上の空間的セグメント・ストリームを選択し、前記位置情報に基づいて、前記コンテンツ配信ネットワークにおける少なくとも１つの配信ノードに、前記１つ以上の選択された空間的セグメント・ストリームを前記クライアントに送信するように要求し、前記１つ以上の選択された空間的セグメント・ストリームを前記少なくとも１つの配信ノードから受信するように構成される。

一実施形態では、前記クライアントが、更に、前記１つ以上の選択された空間的セグメント・ストリームをバッファし、前記１つ以上の空間的セグメント・ストリームに関連付けられた同期情報を受信し、前記同期情報に基づいて、前記１つ以上の要求された空間的セグメント・ストリームを同期させるように構成される。

他の実施形態では、前記クライアントが、更に、前記空間的マニフェスト・データ構造における位置決め情報に基づいて、空間的セグメント・フレームを縫合するように構成される。

更に、本発明は、再生デバイスのクライアント、好ましくは、前述のようなクライアントにおいて用いるための空間的マニフェスト・データ構造に関することができ、前記データ構造が、コンテンツ配信ネットワークから発する空間的にセグメント化されたコンテンツの抽出および表示を制御し、前記データ構造が、ソース・ストリームについて１つ以上の空間的表現を含み、各空間的表現が、１つ以上の空間的セグメント・ストリームと、前記コンテンツ配信ネットワークにおける１つ以上の配信ノードを位置特定するための位置情報と、任意に、前記セグメント・ストリームにおける空間的セグメント・フレームを縫合して、表示用ビデオ・フレームを得るための位置情報とを含む。

また、本発明は、コンテンツ配信ネットワーク、好ましくは、前述のようなコンテンツ配信ネットワークによる使用のための空間的マニフェスト・データ構造に関することができ、前記空間的マニフェスト・データ構造が、空間的にセグメント化されたコンテンツの収集を制御し、前記データ構造が、ソース・ストリームについて１つ以上の空間的表現を含み、各空間的表現が、１つ以上の空間的セグメント・ストリームと、前記１つ以上のソース・ノードを位置特定するための位置情報と、任意に、前記セグメント・ストリームにおける空間的セグメント・フレームを縫合して、表示用のビデオ・フレームを得るための位置決め情報とを含む。

また、本発明は、ソフトウェア・コード部分を含むコンピュータ・プログラム生産物に関し、前記ソフトウェア・コード部分をコンピュータのメモリにおいて実行すると、前述のような方法ステップを実行するように構成される。

添付図面を参照して、本発明について更に例示する。添付図面は、本発明による実施形態を模式的に示す。尚、本発明はこれらの具体的な実施形態には決して限定されないことは言うまでもない。

図１は、本発明の一実施形態によるセグメント化コンテンツ配信システムを示す。 図２Ａは、本発明の種々の実施形態による、空間的にセグメント化されたコンテンツの生成および処理を示す。 図２Ｂは、本発明の種々の実施形態による、空間的にセグメント化されたコンテンツの生成および処理を示す。 図２Ｃは、本発明の種々の実施形態による、空間的にセグメント化されたコンテンツの生成および処理を示す。 図２Ｄは、本発明の種々の実施形態による、空間的にセグメント化されたコンテンツの生成および処理を示す。 図２Ｅは、本発明の種々の実施形態による、空間的にセグメント化されたコンテンツの生成および処理を示す。 図３は、本発明の一実施形態によるＳＭＦデータ構造を示す。 図４は、本発明の一実施形態によるＳＭＦの一部の一例を示す。 図５Ａは、本発明の一実施形態にしたがって、空間的にセグメント化されたコンテンツを処理および表示するように構成されたコンテンツ処理デバイスとユーザが対話処理するプロセスを示す。 図５Ｂは、本発明の一実施形態にしたがって、空間的にセグメント化されたコンテンツを処理および表示するように構成されたコンテンツ処理デバイスとユーザが対話処理するプロセスを示す。 図５Ｃは、本発明の一実施形態にしたがって、空間的にセグメント化されたコンテンツを処理および表示するように構成されたコンテンツ処理デバイスとユーザが対話処理するプロセスを示す。 図６Ａは、本発明の種々の実施形態にしたがって、空間的にセグメント化されたコンテンツをクライアントに配信するプロセスの流れ図を示す。 図６Ｂは、本発明の種々の実施形態にしたがって、空間的にセグメント化されたコンテンツをクライアントに配信するプロセスの流れ図を示す。 図７Ａは、本発明の種々の実施形態によるＳＭＦの一部を示す。 図７Ｂは、本発明の種々の実施形態によるＳＭＦの一部を示す。 図７Ｃは、本発明の種々の実施形態によるＳＭＦの一部を示す。 図８Ａおよび図８Ｂは、画像フレームにおける空間的セグメント・フレームの位置を定めるための異なる座標系の使用を示す。 図９は、本発明の一実施形態によるメディア・エンジンの模式図を示す。 図１０Ａは、異なるストリーミング・プロトコルに基づいて同期および縫合(stitch)した空間的セグメント・フレームを示す。 図１０Ｂは、異なるストリーミング・プロトコルに基づいて同期および縫合した空間的セグメント・フレームを示す。 図１１は、本発明の一実施形態にしたがって、空間的にセグメント化されたコンテンツを同期させるための同期情報を決定するプロセスを示す。 図１２は、２つの異なる配信ノードにコンテンツを要求するクライアントの例を示す。 図１３は、本発明の一実施形態にしたがって、空間的にセグメント化されたコンテンツとのユーザ対話処理を改良するプロセスを示す。

図１は、本発明の一実施形態にしたがって、空間的にセグメント化されたコンテンツをクライアントに配信するコンテンツ配信システム１００を示す。このコンテンツ配信システムは、コンテンツ配信ネットワーク（ＣＤＮ）１０２、コンテンツ提供システム（ＣＰＳ）１２４、および多数のクライアント１０４１−Ｎを含むことができる。ＣＰＳは、コンテンツ、例えば、ビデオ・タイトルをカスタマに提供するように構成することができ、カスタマは、端末上にホストされるクライアントを用いて、このコンテンツを購入し受信することができる。

端末は、一般に、コンテンツ処理デバイス、例えば、電子タブレット、スマートフォン、ノートブック、メディア・プレーヤ等というような、（移動体）コンテンツ再生(play-out)デバイスに関する。実施形態の中には、端末が、コンテンツを処理し、コンテンツ再生デバイスによる今後の消費のために一時的に格納するように構成されたセット・トップ・ボックスまたはコンテンツ記憶デバイスとしてもよい場合もある。

コンテンツの配信は、配信ネットワーク（ＣＤＮ）によって実現される。配信ネットワーク（ＣＤＮ）は、配信ノード１０８１−Ｍ、および少なくとも１つの収集ノード１０８０を含む。ＣＤＮ制御機能（ＣＤＮＣＦ）１１１は、コンテンツを外部コンテンツ・ソース、例えば、コンテンツ・プロバイダ１１０または他のＣＤＮ（図示せず）から受信するように構成される。ＣＤＮＣＦは、更に、収集ノードを制御して、ネットワーク全体を通じて、端末へのコンテンツ配信に十分な帯域幅が保証されるように、コンテンツの１つ以上のコピーを配信ノードに配給することができる。一実施形態では、ＣＤＮは、ＥＴＳＩ ＴＳ １８２０１９に記載されているようなＣＤＮに関係することができる。

カスタマは、要求１１８をウェブ・ポータル（ＷＰ）１１２に送ることによって、コンテンツ、例えば、ビデオ・タイトルを、コンテンツ・プロバイダから購入することができる。この要求に応答して、クライアントは、タイトル参照の少なくとも一部をＷＰから受信し、位置情報、例えば、選択されたコンテンツを配信することができるＣＤＮのＣＤＮＣＦのＵＲＬを受信することができる。ＣＤＮＣＦは、ＣＤＮにおいて、選択されたコンテンツをクライアントに配信することができる少なくとも１つの配信ノードに関連付けられたクライアント位置情報を送ることができる。通例、ＣＤＮＣＦは、クライアントに選択されたコンテンツを配信するのに最も適している配信ノードをＣＤＮにおいて選択する。配信ノードを選択する判断基準は、クライアントの位置、および配信ノードの処理負荷を含むことができる。

クライアントは、ＨＴＴＰおよび／またはＤＮＳシステムを含む、種々の既知の技法を用いて、ＣＤＮにおける配信ノードと連絡を取ることができる。更に、コンテンツをクライアントに配信するには、種々のストリーミング・プロトコルを用いることができる。このようなプロトコルには、ＨＴＴＰおよびＲＴＰ型のストリーミング・プロトコルを含むことができる。好ましい実施形態では、ＨＴＴＰ適応ストリーミング（ＨＡＳ）、ＤＶＢ適応ストリーミング、ＤＴＧ適応ストリーミング、ＭＰＥＧ ＤＡＳＨ、ＡＴＩＳ適応ストリーミング、ＩＥＴＦ ＨＴＴＰライブ・ストリーミング、および関連プロトコルというような適応ストリーミング・プロトコルを用いることができる。

ＣＤＮは、いわゆる空間的にセグメント化されたコンテンツを収集し、この空間的にセグメント化されたコンテンツをクライアントに配給するように構成される。空間的にセグメント化されたコンテンツは、ソース・ストリーム、例えば、ＭＰＥＧ−型ストリームの各画像フレームを、多数の空間的セグメント・フレームに分割することによって生成することができる。画像フレームの１つの特定エリアに関連付けられた空間的セグメント・フレームの時間シーケンスは、別個の空間的セグメント・ストリームにおいて編成することができる。空間的セグメント・ストリームにおける空間的セグメント・フレームは、既知のトランスポート・コンテナ・フォーマット(transport container format)にしたがってフォーマットし、メモリに空間的セグメント・ファイルとして格納することができる。

空間的にセグメント化されたコンテンツの収集を扱い、空間的にセグメント化されたコンテンツをクライアントに配信するために、ＣＤＮＣＦは特殊なデータ構造を使用する。以後、このデータ構造を空間的マニフェスト・ファイル（ＳＭＦ）と呼ぶ。ＳＭＦは、ｚｚｚ.ＳＭＦファイル拡張を用いて格納および識別することができる。ＣＤＮに基づいて空間的にセグメント化されたコンテンツをクライアントに配信する際におけるＳＭＦの使用については、以下で更に詳しく説明する。

図２Ａから図２Ｅは、本発明の種々の実施形態による、空間的にセグメント化されたコンテンツの生成および処理を示す。

図２Ａは、空間的にセグメント化されたコンテンツを生成するプロセス例を模式的に示す。コンテンツ・プロバイダは、ＣＤＮを通じてこのようなコンテンツをクライアントに配信するために、このプロセスを用いることができる。このプロセスは、画像処理機能が、高解像度のソース・ストリーム２２０の１つ以上の低解像度バージョンを生成することから開始することができる。その後、低解像度のビデオ・ストリームにおける各画像フレーム２２２を、別個の空間的セグメント・フレーム２２４１−１６に分割する。各空間的セグメント・フレームは、その画像フレームにおける特定のエリアと関連付けられている。元のソース・ストリームの画像フレームを組み立てるために必要とされる全ての空間的セグメント・フレームを、以後、空間的セグメント・グループと呼ぶ。

一実施形態では、空間的セグメント・フレームは、セグメント・フレーム・ヘッダを含むことができる。セグメント・フレーム・ヘッダは、空間的セグメント情報、例えば、それが属する画像フレームにおける特定の位置に関する情報、シーケンス情報（例えば、タイム・スタンプ）、および解像度情報を含む。

続いて、ソース・ストリームの画像フレームの１つの特定エリアに関連付けられた空間的セグメント・フレームのシーケンスを、特定のフォーマット、例えば、ＡＶＩまたはＭＰＥＧにエンコードし、空間的セグメント・ストリーム２２６１−１６フォーマットに並べる。各空間的セグメント・ストリームは、空間的セグメント・ファイル、例えば、ｘｘｘｘ.ｍ２ｔｓまたはｘｘｘ.ａｖｉとして格納することができる。セグメント化の間に、画像処理機能は、空間的セグメント・ストリーム間における空間的関係を確立するための情報、および空間的セグメント・ストリームをどこから抽出することができるかについて示す位置情報を生成することができる。

尚、画像フレームのセグメント・グループへの空間分割は、図２Ａに模式的示されたものに限定されないことを申し添えておく。画像フレームは、等しい寸法の空間的セグメント・フレームのマトリクスを定めるセグメント・グループに空間的に分割することができる。あるいは、他の実施形態では、セグメント・グループにおける空間的セグメント・フレームが異なるセグメント・フレーム寸法を有してもよい。例えば、元の画像フレームの中心に関連付けられた小さなセグメント・フレームと、画像フレームのエッジにおけるそれよりも大きなサイズの空間的セグメント・フレームとを有してもよい。

図２Ａに示す空間的セグメント化プロセスは、ソース・ストリームの異なる解像度バージョン毎に繰り返すことができる。このように、１つのソース・ストリームに基づいて、多数の空間的表現を生成することができ、各空間的表現には、ソース・ファイルの所定の空間的にセグメント化されたフォーマットを関連付けることができる。

各空間的表現における空間的セグメント・ストリーム間において空間的関係および／または時間的関係を確立する情報、ならびに空間的セグメント・ストリームを抽出するための位置情報、例えば、ＵＲＬは、階層的に並べ、空間的マニフェスト・ファイル（ＳＭＦ)として格納することができる。ＳＭＦの構造については、図３を参照して詳しく論ずることにする。

図２Ｂは、本発明の一実施形態によるＣＤＮ２００の少なくとも一部を更に詳細に示す。ＣＤＮは、１つ以上の配信ノード２０２１−２を含むことができ、各々、コントローラ２０４１−２および配信ストレージ２０６１−２を含む。収集ノード２０８は、空間的にセグメント化されたコンテンツをコンテンツ処理エンティティ２１０、例えば、コンテンツ・プロバイダまたは他のＣＤＮから、ＣＤＮＣＦの制御の下で受信するように構成される。

空間的にセグメント化されたコンテンツを収集するために、ＣＤＮＣＦ２１２はＳＭＦをコンテンツ処理エンティティから受信することができる。ＳＭＦは、位置情報、例えば、ＵＲＬを含んでおり、ここに、コンテンツ処理エンティティに関連付けられた空間的セグメント化コンテンツが格納される。ＳＭＦにおける位置情報に基づいて、ＣＤＮＣＦは、次に、空間的セグメント・ストリームの収集ノードへの移送を開始することができる。収集ノードは、収集したコンテンツを収集キャッシュ２１４に一時的に格納またはバッファすることができる。

ＣＤＦＣＦは、更に、所定の配給機能にしたがって、空間的コンテンツ・セグメント・ストリームのコピーを１つ以上の配信ノードに配給するコンテンツ展開機能２１６も含むことができる。この機能は、処理負荷、データ・トラフィックおよび／またはＣＤＮにおける配信ノードに関連付けられた地理的近接度情報に基づいて、空間的にセグメント化されたコンテンツのコピーをＣＤＮの１つ以上の配信ノードを通じて配給することを可能にするアルゴリズムを使用することができる。

したがって、コンテンツ要求をクライアントから受けたとき、ＣＤＮＣＦは、例えば、このクライアントに近くにあり大きな処理負荷がかかっていない１つ以上の配信ノードを選択することができる。ＣＤＮの効率を高めるために、１つのＳＭＦに関連付けられた異なる空間的セグメント・ストリームを異なる配信ノードに配給することができる。例えば、画像フレームの中央に位置し、要求される頻度が高い空間的セグメント・ストリームを多数の配信ノードに格納することができ、画像フレームのエッジに位置し要求される頻度が低い空間的セグメント・ストリームは、１つの配信ノードに格納すればよい。

一旦ＣＤＮＣＦが、収集した空間的セグメント化コンテンツを配信ノードに配給したなら、ＣＤＮＣＦはＳＭＦにおける位置情報を変更し、空間的セグメント・ストリームが配給された配信ノードへの参照（ＵＲＬ）を、変更されたＳＭＦが含むようにすることができる。このように変更したＳＭＦを、ＣＤＮＣＦによってＳＭＦストレージ２１８に格納する。

図２Ｃおよび図２Ｄは、本発明の一実施形態にしたがって空間的にセグメント化されたコンテンツを収集するプロセスに関連付けられたフロー・チャートおよびシーケンス図をそれぞれ示す。図２Ｃに示すように、本プロセスは、ＣＤＮＣＦがソース、例えば、コンテンツ・プロバイダ、ＣＤＮ、または他のコンテンツ処理エンティティから発する(originate)コンテンツ収集の要求を受けることから開始することができる（ステップ２３０）。この要求は、位置情報、例えば、ＵＲＬと、コンテンツ識別子とを含むことができる。応答して、ＣＤＮＣＦはファイルを受信する（２３２）。このファイルは、ＳＭＦ（ｚｚｚ.ＳＭＦ）または従来のセグメント化されていないコンテンツ・ファイルのいずれかに関係することができる。

ＣＤＮＣＦがＳＭＦを受信した場合、この受信したＳＭＦに基づいて、空間的にセグメント化されたコンテンツの収集を実行することができる（ステップ２３４）。収集プロセスの実行は、空間的セグメント・ストリームに関連付けられた位置情報、例えば、ＵＲＬを抽出するためにＳＭＦをパースすること（ステップ２３６）、およびそれぞれの空間的セグメント・ストリームを抽出するように収集ノードに命令し、収集したストリームを一時的に収集キャッシュに格納すること（ステップ２３８）を含むことができる。

処理負荷、データ・トラフィック、および／またはＣＤＮにおける配信ノードに関連付けられた地理的近接度情報に基づいて、ＣＤＮ展開機能は、次に、空間的セグメント・ファイルを、１つ以上の所定のコンテンツ配信ノードにわたって配給し（ステップ２４０）、続いて、空間的に異なるセグメント・ファイルが格納される異なる配信ノードの新規の位置に関連付けられた位置情報を追加することによってＳＭＦを更新する（ステップ２４２）ことができる。任意に、ＵＲＬをソースに送ることもできる（ステップ２５４）。

ＣＤＮＣＦは、更新された（変更された）ＳＭＦを、配信ノードの少なくとも１つによって格納し（ステップ２４４）、今後の使用のために、更新されたＳＭＦを抽出することができる位置を格納するために、ＣＤＮＣＦに関連付けられたＳＭＦテーブルに新規エントリを生成する（ステップ２４６および２４８）ことができる。任意に、ＳＭＦを位置特定するためのＵＲＬをソースに送ることもできる（ステップ２５４）。

ソースのソース収集要求が従来のセグメント化されていないコンテンツと関連付けられている場合、このコンテンツを一時的に収集ストレージに格納することができ、その後ＣＤＮ展開機能がこのコンテンツを１つ以上の配信ノードに配給する（ステップ２５０）。格納されているファイルに関連付けられたＵＲＬを生成し、後に抽出ためにＣＤＮＣＦによって格納する（ステップ２５２）ことができる。任意に、コンテンツを位置特定するためのＵＲＬもソースに送ることができる（ステップ２５４）。

図２Ｄのシーケンス図は、空間的にセグメント化されたコンテンツを収集するプロセスの一実施形態を更に詳しく示す。この例では、ＣＤＮＣＦおよびソースは、コンテンツ収集を制御するためにＨＴＴＰに基づくプロトコルを用いることができる。本プロセスは、ソースがコンテンツ収集要求をＣＤＮＣＦに送ることから開始することができ、この要求は、Movie-4.ＳＭＦという名称のＳＭＦを指し示すＵＲＬを含む（ステップ２６０）。ＣＤＮＣＦは、このＳＭＦを抽出し（ステップ２６２および２６４）、空間的セグメント・ファイル位置を抽出するために（例えば、１つ以上のＵＲＬの形態で）ＳＭＦをパースすることができる（ステップ２６８）。

これらのＵＲＬを用いて、ＣＤＮＣＦは、ＣＤＮ収集ノードに、ＳＦＭ、例えば、ソース記憶キャッシュにおいて識別される空間的セグメント・ストリームを読み出すように命令する（ステップ２７０）。この空間的セグメント・ストリームを受信した後（ステップ２７２から２７８）、収集ノードは、コンテンツを抽出するのに成功したことをＣＤＮＣＦに通知する（ステップ２８０）ことができる。次いで、ＣＤＮＣＦは、収集したストリームのコピーを、ＣＤＮにおける配信ノードに配給することができる。例えば、処理負荷、データ・トラフィック、および／または地理的近接度情報に基づいて、ＣＤＮ展開機能は、４つの空間的にセグメント化されたコンテンツ、Movie-4-1.seg、Movie-4-2.seg、Movie-4-3.seg、およびMovie-4-4.segのコピーを配給ノードND2に配給し、空間的セグメント・ストリームMovie-4-1.segおよびMovie-4-3.segをＤＮ１に配給することを決定することができる（ステップ２８１）。

配信ノードへの配給の後、ＣＤＮＣＦは、これらの空間的セグメント・ストリームを抽出することができる配信ノードの位置（この場合、ＤＮ１およびＤ２のＵＲＬ)をＳＭＦに挿入することによって、ＳＭＦを更新することができる（ステップ２８２）。更新したＳＭＦは、空間的セグメント・ストリームと共に格納することができる（ステップ２８４および２８８）。ＳＭＦの位置は、ＣＤＮＣＦに関連付けられたＳＭＦテーブルに格納することができる（ステップ２８６）。任意に、ＣＤＮＣＦは、更新したＳＭＦに関連付けられた位置情報を含む応答をソースに送り、ＣＤＮによるコンテンツ収集成功を示すこともできる（ステップ２９０）。

図２Ｅは、図２Ｃおよび図２Ｄを参照して説明したような、空間的にセグメント化されたコンテンツの収集前後におけるＳＭＦの一部の例を示す。ソースから受信されたＳＭＦ２９２は、コンテンツ識別子、セグメント化に関する情報、例えば、セグメント化のタイプ、セグメントの数、および異なる空間的セグメント・ファイルからの空間的セグメント間の空間的関係を含むことができる。例えば、図２ＥにおけるＳＭＦ例の内容は、空間的セグメント・コンテンツがソース・ファイルMovie_4に基づいて生成されたことを示す。更に、このＳＭＦは、４つの別個の空間的セグメント・ストリームMovie-4-1.seg、Movie-4-2.seg、Movie-4-3.seg、およびMovie-4-4.segが、ソース・ドメインにおけるある位置、cache.source.com/res/に格納されていることも示す。

空間的セグメント・ファイルの収集後、ＣＤＮＣＦは、更新された空間的セグメント位置を含む更新ＳＭＦ２９４をＵＲＬの形態で生成することができる。このＵＲＬは、空間的セグメント・ストリームMovie-4-1.segおよびMovie-4-3.segを含む第１配信ノードcache-1.cdn_A/res/、ならびに４つ空間的セグメント・ストリーム全てMovie-4-1.seg、Movie-4-2.seg、Movie-4-3.seg、およびMovie-4-4.segを含む第２配信ノードcache_2cdn_A/res/を指し示す。

したがって、以上のことから、ＳＭＦは、空間的にセグメント化されたコンテンツのＣＤＮへの収集を制御しながら行うことを可能にするということになる。収集の後、ＳＭＦは、空間的セグメント・ストリームを抽出することができるＣＤＮにおける位置を特定する。以下で更に詳しく説明するが、ＳＭＦは、更に、クライアントが空間的にセグメント化されたコンテンツを抽出し、これと対話処理することも可能にすることができる。具体的には、ＳＭＦは、クライアントが制御する表示コンテンツとのユーザ対話処理（例えば、ズーミング、パンニング、およびティルティング(tilting)動作）を可能にする。

図３は、本発明の一実施形態によるＳＭＦデータ構造３００を模式的に示す。ＳＭＦは、様々な階層データ・レベル３０２、３０８、３１８、３２８を含むことができ、第１レベル３０２はソース・ストリーム（例えば、source1.m2ts)のいわゆる空間的表現３０６１−３を定める空間的組成情報に関係することができる。通例、ソース・ストリームは、高解像度であり、多くの場合、広角ビデオ・ストリームであると考えられる。

次のデータ・レベル３０８は、空間的表現を定める空間的表現情報に関係することができる。具体的には、空間的表現情報は、ソース・ストリームの特定のバージョン、例えば、解像度バージョンに関連付けられた１組の空間的セグメント・ストリーム間における空間的関係を定めることができる。

空間的表現情報は、空間マップ３１１に配列された１組の空間的セグメント・ストリーム・インスタンス３１２１−４を含むことができる。一実施形態では、このマップは、空間的セグメント・ストリーム・インスタンスのマトリクス（行および列に構成される）を定めることができ、ソース・ストリームによって搬送されるコンテンツの少なくとも一部を構成する画像の構築(construction)を可能にする。

空間的セグメント・ストリーム・インスタンスは、位置参照システム内におけるセグメントの位置を定めるセグメント位置３１３１−４と関連付けることができる。例えば、図３は、空間的セグメント・ストリーム・インスタンスのマトリクスを示し、セグメント位置（１，１）および（１，２）に関連付けられた空間的セグメント・ストリーム・インスタンスが、ソース・ストリームにおけるビデオ画像の左上エリアおよび右上エリアに関連付けられたコンテンツを指すことができる。これら２つのセグメント・ストリーム・インスタンスに基づいて、ソース・ファイルのビデオ画像の上半分に関連付けられたコンテンツを含むビデオ画像を再生することができる。

更に、空間的表現情報は、ソース・ストリームの解像度バージョンを示すソース解像度３１０も含むことができる。これは、空間マップにおいて示される空間的セグメント・ストリームを生成するために用いられる。例えば、図３では、空間マップにおいて示される空間的セグメント・ストリームは、ソース・ストリームの４０９６×２１６０の解像度バージョンに基づいて生成することができる。

更に、空間的表現情報は、空間マップにおいてしめされた空間的セグメント・ストリームの解像度を定めるセグメント解像度３１４（図３の例では、２０４８×１０８０の解像度）、および空間マップにおける空間的セグメント・ストリームをクライアントに送信するときのビット・レートを定めるセグメント・ビット−ストリーム・レート３１６を含むことができる。

次のデータ・レベル３１８は、空間的セグメント情報、即ち、空間マップにおける空間的セグメント・ストリーム・インスタンスに関連付けられた情報に関係することができる。空間的セグメント情報は、空間的セグメント・ストリーム３２４における空間的セグメント・フレームに関連付けられた位置座標を含むことができる。この位置座標は、絶対座標系または相対座標系に基づくことができる。空間マップにおいて示された空間的セグメント・ストリームにおける空間的セグメント・フレームの位置座標は、隣接する空間的セグメント・フレームの境界を空間的に整合して、表示のためのシームレス・ビデオ画像にするために、クライアントによって用いることができる。このプロセスは、多くの場合「縫合」(stitching)と呼ばれる。

更に、空間的セグメント情報は、配信ノードを位置特定するために、１つ以上の空間的セグメント・ストリーム・ロケータ３２６、３２８（例えば、１つ以上のＵＲＬ）も含むことができる。配信ノードは、特定の空間的セグメント・ストリームをクライアントに送信するように構成される。また、空間的セグメント情報は、ストリームのクライアントへの送信を制御するために用いられるのはどのプロトコルか（例えば、ＲＴＳＰまたはＨＴＴＰ）を示すプロトコル情報と、クライアントにおける同期モジュールが、クライアントによって受信された異なるセグメント・ストリームを同期するための同期情報３３０、３３２とを含むこともできる。

以上で述べた縫合および同期プロセスについて、図９から図１１を参照しながら、以下で更に詳しく説明する。

更に、ＳＭＦは、１つの空間的表現における空間的セグメント・ストリームを、別の空間的表現における空間的セグメント・ストリームに関係付ける表現間情報３３４も含むことができる。この関係間情報は、クライアントが異なる表現に跨がって効率的にブラウズすることを可能にする。

図４は、本発明の一実施形態にしたがって、（擬似）ＸＭＬを用いる（高解像度）ソース・ファイルの、１組の空間的にセグメント化されたビデオ表現を定めるＳＭＦの一部の一例を示す。このＳＭＦは、ソース・ファイルｓｏｕｒｓｅｌ.ｍ２ｔｓに基づいて、異なる空間的表現（この場合３通り）を定める。

図４のＳＭＦにおける第１の空間的表現は、１つの１０２４×５４０画素解像度のセグメント化されていないビデオ・ストリーム(segment_mode==OFF)を定める。クライアントは、この第１空間的表現において定められているＵＲＬ、rtsp://video.content.com/full_stream/aviを用いて、ストリームを抽出することができる。

このＳＭＦにおける第２空間的表現は、４０９６×２１６０解像度のソース・ストリームと関連付けられている。このストリームは、２×２マトリクス（NumberOfColumns、NumberOfRows）に空間的にセグメント化される。このマトリクスは、４つの空間的セグメント・ストリーム・インスタンスを含んでおり、各々が、２０４８×１０８０セグメント解像度の別個の空間的セグメント・ストリームに関連付けられており、各々が、ＵＲＬによってアクセス可能である。例えば、セグメント位置（１，１）と関連付けられた第１セグメント・ストリームは、ＵＲＬ、rtsp://video.content.com/stream1_1.aviを用いて、ＲＴＳＰサーバに要求することができる。

ＳＭＦは、空間的セグメント・ストリームに関連付けられた同期情報を定めることができる。例えば、図４におけるＳＭＦは、ＲＴＳＰサーバに対して所定のＲＴＰオフセット値を定める。このＲＴＳＰサーバは、空間的セグメント・ストリームstream1_1.aviをクライアントに送信するように構成される。ＲＴＳＰサーバは、空間的セグメント・ストリームをクライアントにストリーミングするためにＲＴＰプロトコルを用いる。通常、ＲＴＰストリームにおける連続ＲＴＰパケットには、ＲＴＳＰサーバによって、ランダムなオフセット値を開始値として用いるタイム・スタンプが付けられている。クライアントにおいて異なる空間的セグメント・ストリームを同期させるためには、この初期オフセット値についての知識が必要となる。

したがって、異なるＲＴＳＰサーバから発する異なるＲＴＰストリームをクライアントが同期させることを可能にするために、クライアントは、要求の中において、所定のＲＴＰオフセット値を、異なるＲＴＳＰサーバに送り、要求の中にある所定のＲＴＰオフセットをＲＴＰタイム・スタンプの開始値として使用するように、各サーバに命令することができる。このように、クライアントは、異なるＲＴＳＰサーバから発し、異なるタイム・スタンプが付けられたＲＴＰストリーム間における時間的関係を判断することができる。

ＳＭＰにおけるもう１つの、第３空間的表現は、ソース・ストリームの７６８０×４３２０解像度バージョンに関係することができる。このソース・ストリームは、１６個の空間的セグメント・ストリーム・インスタンスを含むマトリクスにセグメント化され、各々が１９２０×１０８０解像度空間的セグメント・ストリームと関連付けられ、各々が所定のＵＲＬを介してアクセス可能である。

好ましくは、空間的セグメント・ストリームの解像度およびアスペクト比は、マクロ・ブロックおよびスライス・サイズというような、共通のビデオ・エンコーディングおよびデコーディング・パラメータと一貫性がある。加えて、空間的セグメント・ストリームの解像度は、十分なビデオ・コーディング利得を保持できるように、十分に大きくなければならない。

図５Ａから図５Ｃは、本発明の一実施形態にしたがって、ユーザがコンテンツ処理デバイスと対話処理するプロセスを示す。このコンテンツ処理デバイスは、空間的にセグメント化されたコンテンツを処理および表示するように構成される。

図５Ａは、１つ以上の配信ノード５０４１、５０４２から空間的セグメント・ストリームを直接抽出するように構成されるクライアント５０２を含むコンテンツ処理デバイス５０１を示す。各配信ノードは、コントローラ５２２１、５２２２と、空間的セグメント・ストリームを格納する配信ストレージ５２４１、５２４２を含むことができる。

コンテンツ処理デバイスのディスプレイは、コンテンツを表示することおよびユーザ入力５２０を受け取ることの双方を可能にするインタラクティブ・グラフィカル・ユーザ・インターフェース（ＧＵＩ）５０９として構成することができる。このようなユーザ入力は、表示されるコンテンツとのユーザの対話処理に関係することができ、ユーザの対話処理は、ビデオ・データのズーミング、ティルティング、およびパンニングというようなコンテンツ操作動作を含む。このようなＧＵＩは、当技術分野では周知のタッチ・スクリーン機能を有するディスプレイを含む。

クライアントは、ＳＭＦ５０３をＣＤＮから受信し、ＳＭＦにおける情報およびＧＵＩを介して受け取ったユーザ入力とに基づいて、メディア・エンジン５０７およびアクセス・エンジン５０８を制御するように構成される制御エンジン５０５を含むことができる。このようなユーザ入力は、表示されるコンテンツとのユーザの対話処理、例えば、ズーミング動作、に関係することができる。このようなユーザ対話処理は、制御エンジンを起動し、ＳＭＦにおける位置情報（ＵＲＬ）を用いて、空間的にセグメント化されたコンテンツを抽出するようにアクセス・エンジン（例えば、ＨＴＴＰまたはＲＴＳＰクライアント）に命令することができる。

図５Ｂは、ユーザがＧＵＩを介してクライアントと対話処理するプロセスを模式的に更に詳しく示す。具体的には、図５Ａは、図５Ｂに模式的に示すように、ユーザがディスプレイ５１４の特定のエリア５１２（関心領域即ちＲＯＩ）を選択するプロセスを模式的に示す。選択されたＲＯＩのサイズおよび座標に基づいて、制御エンジンは、ＳＭＦからしかるべき空間的表現を選択することができる。しかるべき空間的表現を選択するプロセスについて、図５Ｃを参照して更に詳細に説明する。

図５Ｂの例では、制御エンジンが、１６個の空間的セグメント・ストリーム・インスタンスのマトリクスを構成するＳＭＦから空間的表現を既に選択しているのでもよい。各空間的セグメント・ストリーム・インスタンスは、ディスプレイにおける特定エリアと関連付けられたコンテンツに関係する（ディスプレイ５１４において点線で模式的に示すように）。次いで、制御エンジンは、ＲＯＩと、選択された空間的表現の空間的セグメント・ストリーム・インスタンスに関連付けられた空間エリアとの間の重複を判定することができる。

このように、図５Ｂの例では、制御エンジンは、４つの空間的セグメント・ストリーム・インスタンス（陰影を付けた空間的セグメント・ストリーム・インスタンスＳ２，１、Ｓ３，１、Ｓ２，２、Ｓ３，２）がＲＯＩと重複することを判定することができる。このように、制御エンジンによって、４つの空間的セグメント・ストリーム５１５１−４が識別され、ＲＯＩ５１２におけるコンテンツをユーザに表示する新規のビデオ・ストリーム５１６の再生が可能となる。識別された空間的セグメント・ストリーム・インスタンスがＲＯＩを構成する場合、以後空間的セグメント・サブグループと呼ぶ。

図５Ａを参照すると、空間的セグメント・サブグループを決定した後、制御エンジン５０５は、識別された空間的セグメント・ストリームを配信するように構成された配信ノードへのアクセスを要求するように、アクセス・エンジンに命令することができる（この場合、２つの配信ノードが識別された）。次いで、アクセス・エンジンは、空間的セグメント・ストリームをクライアントに送信することを求める要求５１１１−２を配信ノード５０４１および５０４２のコントローラに送ることができる（この場合、各配信ノードが２つの空間的セグメント・ストリーム５１３１−２および５１５１−２をクライアントに配信する）。アクセス・エンジン５０８は、送信された空間的セグメント・ストリームをメディア・エンジン５０７に転送することができる。メディア・エンジン５０７は、空間的セグメント・サブグループの空間的セグメント・ストリームを、バッファ、同期、およびデコードし、デコードした空間的セグメント・フレームを縫合して、ＲＯＩを構成するビデオ画像にする処理機能を含むことができる。

図５Ｃは、本発明の一実施形態による、ＳＭＦに基づいて空間的にセグメント化したコンテンツのユーザ対話処理および再生(play-out)の流れ図を示す。具体的には、図５Ｃは、ユーザがＲＯＩを選択することによってズーミング動作を開始する場合の流れ図を示す。

本プロセスは、クライアント、具体的には、クライアントにおける制御エンジンがＳＭＦを受信し、空間的表現の内１つをデフォルトとして選択する、例えば、ソース・ストリームの低帯域幅非セグメント化バージョンを選択することから開始することができる（ステップ５３０）。更に、制御エンジンは、ＲＯＩをデフォルト値に、通例、最大表示サイズに対応する値に設定することができる（ステップ５３２）。制御エンジンがＲＯＩ要求を受けた場合、一時的ファイル上に空間的表現の全てまたは少なくとも一部を抽出し、この空間的表現に「未チェック」としてマークすることができる（ステップ５３４）。次いで、制御エンジンはプロセスを開始することができ、リストから未チェックの空間的表現を取り出し（ステップ５３６）、チェック済みとしてマークすることができる（ステップ５３８）。ＳＭＦに基づいて、制御エンジンは、次に、選択された空間的表現に一致する空間的セグメント・サブグループ、即ち、ＲＯＩを構成する関連空間的セグメント・ストリーム・インスタンスが存在するか否か判断することができる。

空間的表現情報および関連空間的セグメント情報を用いて、制御エンジンは、更に、識別された空間的セグメント・サブグループが再生要件、例えば、帯域幅、コデック・サポート等を満たすか否か検証することができる（ステップ５４２）。再生要件が満たされる場合、次の「未チェック」空間的表現を処理する。再生要件が満たされない場合、制御エンジンは、その空間的表現をリストから削除することができる（ステップ５４６）。その後、リスト上にある全ての空間的表現が処理されるまで、次の未チェック空間的表現を処理する（ステップ５４４）。

次いで、リスト上にある全ての空間的表現をチェックし終えた後、クライアントはこのリストが空であることをチェックすることができる（ステップ５４７）。リストが空である場合、クライアントは、以前のＲＯＩおよび空間的表現が利用可能であり選択できるか否か判断することができる（ステップ５４８）。そうであれば、以前のＲＯＩを再生のために選択することができる（ステップ５４９）。以前のＲＯＩが利用可能でない場合、エラー・メッセージを生成することができる（ステップ５５０）。あるいは、チェック済み空間的表現のリストが空でない場合、コンテンツ・エージェントが、このリストから、再生判断基準、例えば、画面解像度、品質、エンコーディング、帯域幅等を最も良く満たす空間的表現を選択することができ、続いてこの選択した空間的表現に変更する（ステップ５５２）。

次いで、制御エンジンは、新規に選択した空間的表現を用いて、空間的にセグメント化されたコンテンツの再生プロセスを実行することができる（ステップ５４４）。この場合、制御エンジンは、空間的セグメント・サブグループを決定し（ステップ５５６）、更にこの空間的セグメント・サブグループにおいて空間的セグメント・ストリームを抽出することができる位置の情報を判定することができる（ステップ５５８）。空間的セグメント・ストリームを抽出した後（ステップ５６０）、これらを再生のために処理する（ステップ５６２）。即ち、ＲＯＩを構成するビデオ画像のストリームを形成するために、バッファリングし、同期させ、縫合する。

空間的にセグメント化されたコンテンツの再生中に、制御エンジンは、更に他のＲＯＩ要求を検出することができる。例えば、ユーザがＧＵＩを通じて他のＲＯＩを選択する。このような信号が検出された場合（ステップ５６４）、適した空間的表現のリストを構築しチェックする前述のプロセスを再度開始することができる。

つまり、ＳＭＦにおける空間的表現は、ＳＭＦにおける１つ以上の空間的表現に定められている異なる空間的セグメント・ストリームをクライアントに選択させることによって、ユーザが異なるＲＯＩを選択し、ビデオ画像を拡大する(zoom in)ことを可能にする。ＳＭＦは、クライアントが直接ＣＤＮ内にある配信ノードから、空間的にセグメント化されたコンテンツを要求することを可能にする。このような直接抽出によって、コンテンツへの高速アクセスが得られる。これは、サービスの品質および最適なユーザ体験を配信するために必要となる。

したがって、単純に画像の選択画素エリアを拡大し倍率を上げて忠実性を失う結果になるのではなく、クライアントは、単にＳＭＦを用いて効率的に所望の空間的表現に切り替えることができる。例えば、４８０×３２０画素解像度の空間的セグメント・ストリームを用いて、左上１／４を表示するように、ソース・ストリームの、例えば、９６０×６４０解像度バージョンに関連付けられた空間的表現を選択する。このように、選択された空間的表現では、従来のディジタル・ズーミングの状況と比較して、倍率を上げた既存の詳細に基づいて、拡大したときの更なる詳細を実際に表示全体に当てはめてユーザに見せることができる。ＳＭＦにおいて異なる空間的表現があることにより、ユーザは忠実性を失うことなく、そして過剰な量の帯域幅を必要とせずに、特定のＲＯＩまでズームすることが可能になる。

図６Ａは、本発明の一実施形態にしたがって、空間的にセグメント化されたコンテンツをクライアントに配信するプロセスの流れ図を示す。この特定的な実施形態では、ＳＭＦは、空間的セグメント・ストリームと同じ配信ノードＤＮに格納される。

本プロセスは、クライアントが特定のメディア・ファイルashd31.asfを選択し（ステップ６０２）、選択されたメディア・ファイルへの参照を含むHTTP GETをコンテンツ・プロバイダ・システム（ＣＰＳ）（この場合、YouTube（商標）に送る（ステップ６０４）ことから開始することができる。ＣＰＳは、応答して、要求されたメディア・ファイルに関連付けられたＳＭＦを得るために、ＣＤＮのＣＤＮＣＦへのリディレクト(redirect)を生成することができる（ステップ６０６および６０８）。応答して、ＣＤＮＣＦは、要求されたＳＭＦが格納されているコンテンツ配信ノードへのリディレクトを生成することができる（ステップ６０９および６１０）。次いで、配信ノードは、要求されたＳＭＦをクライアントに送ることができる。

次に、図５Ｃを参照して先に説明したように、クライアントはユーザからＲＯＩ要求を受けることができ（ステップ６１２）、応答して、クライアントは、所望の空間的表現を選択し、空間的セグメント・サブグループ、即ち、選択されたＲＯＩを構成する空間的セグメント・ストリーム・インスタンスを決定するプロセスを開始することができる（ステップ６１４）。

クライアントは、ストリーミング・セッション、例えば、ＲＴＳＰストリーミング・セッションを、格納されているＳＭＦを含む配信ノードによって、設定することができる（ステップ６１６および６１８）。要求された空間的セグメント・ストリームを受信すると（ステップ６２０および６２２）、クライアントは、選択されたＲＯＩを構成するビデオ画像の構築のために、空間的セグメント・ストリームを処理することができる（ステップ６２４）。

図６Ｂは、本発明の更に別の実施形態にしたがって、クライアントが制御することによる、空間的セグメント化コンテンツの配信の流れ図を示す。この場合、空間的セグメント・ストリームは、異なる配信ノードＤ１およびＤ２に格納されている。その場合、本プロセスは、図６Ａと同様に開始することができる。本プロセスは、クライアントが特定のメディア・ファイルashd31.asfを選択し（ステップ６３０）、選択されたメディア・ファイルへの参照を含むHTTP GETをコンテンツ・プロバイダ・システム（ＣＰＳ）（この場合、YouTube（商標）に送る（ステップ６３２）ことから開始することができる。応答して、ＣＰＳは、要求されたメディア・ファイルに関連付けられたＳＭＦを得るために、ＣＤＮのＣＤＮＣＦへのリディレクトを生成することができる（ステップ６３４および６３６）。その後、ＣＤＮＣＦは、ＣＤＮＣＦに関連付けられたＳＭＦストレージからＳＭＦを抽出することができる。このＳＭＦは、図２Ｅを参照して説明したフォーマットと同様のフォーマットを有することができる。具体的には、空間的セグメント・ストリームの少なくとも一部について、ＳＭＦは２つ以上の配信ノードを定めることができる。

したがって、この場合、ＣＤＮＣＦは、空間的セグメント・ストリーム毎に、空間的セグメント・ストリームをクライアントに送信するのに最も適した配信ノードはどれか判断しなければならない。例えば、クライアントの位置に基づいて、ある配信ノードが他の配信ノードよりも好ましい場合がある。更に、輻輳の問題、または重い処理負荷のために、ある配信ノードを回避したほうがよい場合もある。このように、格納されているＳＭＦに基づいて、ＣＤＮＣＦは、空間的セグメント・ストリーム毎に最も適した配信ノードをクライアントのために選択することによって、「個人」ＳＭＦを生成する（ステップ６３８）。この個人ＳＭＦをクライアントに送る（ステップ６４０）。

クライアントは、ユーザからＲＯＩ要求を受けることができる（ステップ６４２）。次いで、個人ＳＭＦに基づいて、クライアントは、所望の空間的表現を選択するため、空間的セグメント・サブグループを決定するため、そして空間的セグメント・サブグループにおいて空間ストリームをクライアントに送信する配信モードの位置を判定するためのプロセスを開始することができる。

その後、クライアントは、空間的セグメント・ストリームをクライアントに送信するために、ストリーミング・セッション、例えば、ＲＴＳＰストリーミング・セッションを、異なる識別された配信ノード、この場合、それぞれ第1および第２配信ノードＤ１およびＤ２によって設定することができる（ステップ６４６から６５２）。要求した空間的セグメント・ストリームを受信すると（ステップ６５０および６５２）、クライアントは、選択されたＲＯＩを構成するビデオ画像の構築のために、空間的セグメント・ストリームを処理することができる（ステップ６５４）。したがって、図６Ｂのプロセスでは、クライアントは、特定のクライアントおよびＣＤＮ状況、例えば、クライアント−配信ノード間の距離、配信ノードの処理負荷等にしたがって最適化されているＳＭＦを受信する。

図６Ａおよび図６Ｂでは、ＨＴＴＰに基づいてＳＭＦの抽出について説明したが、ＳＩＰ／ＳＤＰ、ＳＩＰ／ＸＭＬ、ＨＴＴＰ／ＸＭＬ、またはＳＯＡＰというような種々の他のプロトコルを用いることもできる。更に、空間的セグメント・ストリームの要求は、例えば、ＲＴＳＰ／ＳＤＰ、ＳＩＰ／ＳＤＰ、ＳＩＰ／ＸＭＬ、ＨＴＴＰ、ＩＧＭＰに基づくことができる。セグメントの配信は、ＤＶＢ−Ｔ、ＤＶＢ−Ｈ、ＲＴＰ、ＨＴＴＰ（ＨＡＳ）、またはＩＰ−マルチキャストによるＵＤＰ／ＲＴＰに基づくことができる。

ソース・コンテンツ・ストリームの多数の空間的表現を定めるＳＭＦは、ＣＤＮにおけるコンテンツの収集のため、および／またはＣＤＮからクライアントへのコンテンツ配信のための効率的なツールを提供することができる。これは、クライアントが、ＲＯＩに関連付けられた空間的セグメント・ストリームを効率的に決定すること、およびＣＤＮにおける配信ノードのためにこれらの空間的セグメント・ストリームを直接抽出することを可能にする。更に、これは、ユーザが、ＣＤＮにおいてそしてクライアントをＣＤＮと接続するアクセス・ラインにおいて過剰な量の帯域幅を消費することなくコンテンツと対話処理する（例えば、ズーミングおよびパンニング）効率的な方法を可能にする。尚、ＳＭＦは、空間的にセグメント化されたコンテンツを制御する様々な有利な方法にも対処できることは明らかである。

図７Ａから図７Ｃは、本発明の種々の実施形態によるＳＭＦの少なくとも一部を示す。図７Ａは、本発明の一実施形態によるＳＭＦの一部を示す。具体的には、図７ＡにおけるＳＭＦは、表示しようとする画像フレームにおける空間的セグメント・フレームの空間位置を定める。このように、例えば、特定の空間的セグメント・ストリームにおける空間的セグメント・フレームの左下角を、絶対表示位置１０００，５００に関係付けることができる。

このような座標系の使用によって、隣接する空間的セグメント・ストリームにおけるセグメント・フレームが重複することが可能になり、これによってパンニングおよびズーミング方法の改良が可能になる。例えば、重複によって、隣接する空間的セグメント・ストリームに切り替えるときに、一掃円滑なパンニング動作を行うことができる。

図７Ｂは、表現間情報(inter-representation information)を含む、本発明の一実施形態によるＳＭＦの一部を示す。空間的にセグメント化されたコンテンツが多数の空間的表現を含み、その各々が多数の空間的セグメントを定める場合、そのコンテンツ内部においてズーミングするとき、特定のＲＯＩに関連付けられた空間的セグメント・ストリームおよび他の空間的表現における解像度バージョンに対する所望の１つ以上の参照を発見するためには、計算的な負担が大きくなる虞がある。

これらの状況では、異なる空間的表現間の相関についての情報も含むようにＳＭＦを構成し、各空間的表現が、空間的にセグメント化されたビデオ・コンテンツの特定の解像度バージョンと関連付けられることが有用である場合もある。例えば、第１空間的表現の表示位置１０００，５００における空間的セグメント・ストリームを、第２空間的表現の表示位置５００、２５０における空間的セグメント・ストリーム、および第３空間的表現の表示位置２５０，１２５における空間的セグメント・ストリームに関係付ける。

表現間情報の使用は、特に、図７Ａを参照して説明したような絶対画素座標系と組み合わせるときに有用であることができる。例えば、表現間情報(inter-representation)は、ズーム動作の間におけるＲＯＩのしかるべき空間的表現との照合を簡略化することができる。

図７Ｃは、本発明の一実施形態によるＳＭＦの一部を示し、正規化された画素座標がビデオ画像フレームの中心として選択され、選択された解像度バージョンとは独立して、空間的表現に関連付けられた画像フレーム内における絶対位置を定める。このような正規化座標系は、０から１までの範囲を取ることができ、（０．５，０．５）を原点として用いる。このような正規化座標系の使用により、ズーミング動作中においてＳＭＦ内での異なる空間的表現間の切り替えを一層簡単にすることができる。

図８Ａおよび図８Ｂは、更に、画像フレームにおける空間的セグメント・フレームの位置を定めるための異なる座標系の使用を示す。図８Ａは、様々な異なる座標系、即ち、行および列８０２に基づく測位システム、絶対座標系８０４、および画像フレームにおけるセグメント・フレームを位置付けるための正規化座標系８０６を示す。図８Ｂは、空間的セグメント・ストリーム・インスタンスのマトリクスを含む１つの空間的表現を示し、これによって、隣接する空間的セグメント・フレームが重複する（例えば、５０％の重複）。

異なる配信ノードから発し個々に送信された空間的セグメント・ストリームに基づいてコンテンツを処理し表示するために、特定の機能をクライアントにおいて実装する必要がある。具体的には、個々の空間的セグメント・フレームを縫合して、表示のための１つの画像フレームが得られるように、異なる送信ノード（ＣＤＮの配信ノードのような送信ノード）から発する空間的セグメント・ストリームのフレーム・レベルの同期が必要とされ、この画像フレームはＲＯＩを構成する。

同期が必要となるのは、クライアントと配信ノードとの間におけるデータ交換には、ネットワークにおいて種々の発生源の未知の遅延、例えば、送信遅延、ネットワーク経路の相違、ならびにコード化およびデコーディングの違いによる遅延が生ずるからである。その結果、要求は、異なる配信ノードに異なる時刻に到達し、生成しようとするビデオに関連付けられた空間的セグメント・ストリームの送信開始時刻が異なるという事態に至る。

Mavlankar et al.は、タイル状ビデオ・ストリームを同時に同期させて表示するために、メディア・プレーヤの多数のインスタンスを用いる。このような解決策は、しかしながら、スマートフォン、タブレット等というような、低電力のメディア処理デバイスの多くには適していない。これらのデバイスは、一般に、同時に１つのデコーダ・インスタンスが実行することしか許さない。更に、Mavlankarは、異なる配信ノードから発する多数のセグメント・ストリームを同期させるという問題には取り組んでいない。具体的には、Mavlankarは、新規の空間的セグメント・ストリームの要求と空間的セグメント・ストリームの受信との間に遅延があり、この遅延はＣＤＮにおける異なる配信ノード間で変更する可能性があるという問題に取り組んでいない。

バッファリングおよび同期の問題は、空間的セグメント・ストリームを１つのトランスポート・コンテナにカプセル化することによって、回避するまたは少なくとも大幅に低減することができる。しかしながら、１つのコンテナにおいて空間的セグメント・ストリームを移送すると、空間的にセグメント化されたコンテンツのストリーミングの柔軟性が著しく低下する。何故なら、個々の空間的セグメント・ストリームを直接異なる配信ノードからクライアントにストリーミングすることができないからである。したがって、空間的にセグメント化されたコンテンツについて提案した方法の利点を維持するためには、クライアントにおける空間的セグメント・ストリームのストリーミング同期が必要となる。

図９は、本発明の種々の実施形態にしたがって、空間的セグメント・フレームを同期させ、デコードし、空間的に整列するように構成されたメディア・エンジン９０２の模式図を示す。このメディア・エンジンは、図５Ａを参照して説明したクライアントに含めることができる。

メディア・エンジン９０２は、バッファ９０３を含むことができる。バッファ９０３は、多数のパケット化空間的セグメント・ストリーム９０６１−４をバッファするために多数の適応バッファ・インスタンスを含む。同期情報を用いれば、同期エンジン９１０が、空間的セグメント・ストリームにおいてパケットを同期させるために、バッファを制御することができる。

同期情報は、空間的セグメント・ストリームにおけるパケットのヘッダにおいてタイミング情報を含むことができる。このようなタイミング情報は、ストリームにおける画像フレームの相対的位置を示すタイム・スタンプ、例えば、ＲＴＰタイム・スタンプを含むことができる。また、タイミング情報は、ＲＴＳＰサーバとクライアントとの間で交換されるＲＴＰタイム・スタンプ情報にも関係することができる。更に他の実施形態では、タイミング情報がタイム・セグメント、例えば、ＨＴＴＰ ＤＡＳＨマニフェスト・ファイルにおいて指定されるＤＡＳＨタイム・セグメント、およびこのようなＤＡＳＨタイム・セグメントに収容される、タイム・スタンプ付きフレーム（例えば、ＭＰＥＧ）または連番付きフレーム（例えば、ＡＶＩ）にも関係することができる。

図４を参照して既に説明したように、同期情報９１１、例えば、ＲＴＰオフセット値をＳＭＦ９１３に含め、制御エンジン９１５によって同期モジュールに送ることもできる。他の実施形態では、同期情報９１７は、帯域内(in-band)チャネルまたは帯域外(out-of-band)チャネルにおいて同期エンジンに送ることもできる。

タイミング情報は、バッファ・モジュールにおける１つ以上の適応バッファ・インスタンスを制御するために用いることができる。例えば、バッファの出力が時間整列された（即ち、時間同期された）パケットを生成できるように、異なる空間的セグメント・ストリームのタイミング情報に基づいて、適応バッファ・インスタンスの時間遅延を判定することができる。

バッファの出力における同期されたパケットをマルチプレクサ（図示せず）によって多重化し、時間同期パケット９１２のストリームにすることができる。このストリームは、いわゆるピクチャ・グループ（ＧＯＰ：groups of pictures)に論理的に配列されたフレームを含むので、デコーダ９１６はこれらのパケットを順次デコードデコードして、デコードされた空間的セグメント・フレーム９２０のストリームを得ることができる。更に他の実施形態では、メディア・エンジンは、バッファから発するデータをデコードするために２つ以上のデコーダ９２０を含むこともできる。

一実施形態では、デコードされたセグメント・フレームは、空間的セグメント・サブグループ９２１１−４のシーケンスに並べることができる。縫合エンジンは、各空間的セグメント・サブグループに関連付けられた空間的セグメント・フレームを縫合して、ＲＯＩを構成するビデオ画像フレームを得ることができる。縫合エンジンは、例えば、ＳＭＦにおける位置座標を用いて、空間的セグメント・サブグループにおける空間的セグメント・フレームを空間的に整列し、ユーザに表示するためのシームレスなビデオ画像フレーム９２２を得ることができる。

画像縫合のプロセスは、空間的セグメント・サブグループの空間的セグメント・フレームを空間的に整列することによって、空間的セグメント・フレームに基づいてビデオ画像を生成する技法を含む(encompass)。更に他の実施形態では、画像位置合わせ、較正、配合(blending)というような画像処理技法を用いて、縫合プロセスを改良することができる。画像位置合わせは、２つの隣接する空間的セグメント・フレーム間における画像の特徴の照合を伴うことができる。重複する画素間の絶対差の総和を最小にする画像整列を探索するために、直接整列方法を用いることもできる。画像構成は、画像間における光学差および／または歪みを最小に抑えることを伴うことができ、配合は露出差を補償するために画像間で色を調節することを伴うことができる。

図１０Ａおよび図１０Ｂは、異なるストリーミング・プロトコルに基づいて、同期および縫合された空間的セグメント・フレームを示す。具体的には、図１０Ａは、同期および縫合されて１つの画像フレームとなった空間的セグメント・フレーム（この場合、４つ）を示す。これらの空間的セグメント・フレームは、適応ストリーミング・プロトコル、例えば、MPEG DASH ISO-IEC_23001-6v12において定義されているＨＴＴＰ適応ストリーム（ＨＡＳ）プロトコルを用いて、クライアントに移送される。

各ＨＡＳ−型空間的セグメント・ストリームを、Ｎ個の等しいサイズの時間セグメント（以後、空間−時間セグメントまたはＳＴセグメントと呼ぶ）に分割することができる。各ＳＴセグメントは、空間的セグメント・ストリームにおいて、特定の期間、例えば２〜４秒が関連付けられる。空間的セグメント・ストリームにおけるＳＴセグメントの位置は、単調増加（または減少）セグメント番号によって決定される。

更に、各ＳＴセグメントは所定数の一連の空間的セグメント・フレームも含んでおり、ＳＴセグメントにおける空間的セグメント・フレームの位置は、単調増加タイム・スタンプまたはフレーム番号（用いられるトランスポート・コンテナによって異なる）によって決定することができる。例えば、番号が付けられた各ＳＴセグメントは、所定数の単調に番号またはタイム・スタンプが付けられた空間的セグメント・フレームを含むことができる。したがって、ＨＡＳ−型空間的セグメント・ストリーム（またはＳＴセグメント・ストリーム）における各空間的セグメント・フレームの（時間的）位置は、そのＳＴセグメントにおけるセグメント番号およびフレーム番号によって一意に決定される。

ＳＴセグメントにおける空間的セグメント・ストリームを等しい長さに分割する際、個々の空間的セグメント・ストリームの各々についてのピクチャ・グループ（ＧＯＰ）の長さおよび構造、ビデオ・フレーム・レート、および全体的なビット・レートというようなビデオ・エンコーディング・パラメータを用いることによって、容易に行うことができる。

ＨＡＳ−型空間的セグメント・ストリームの時間フォーマット、例えば、各ＴＳセグメントに関連付けられた時間期間、ＴＳセグメントにおけるフレーム数等は、ＨＡＳマニフェスト・ファイル（図３参照。ＨＴＴＰ空間的セグメント・ストリームがＨＡＳマニフェスト・ファイルにしたがって定められる）において記述することができる。したがって、ＨＡＳ−型空間的セグメント化コンテンツでは、ＳＭＦがコンテンツの空間フォーマットを定めることができ、このコンテンツの時間フォーマットを定めるために、他のマニフェスト・ファイル、即ち、ＨＡＳマニフェスト・ファイルを参照することができる。

ＳＴセグメント化コンテンツ空間的セグメント・フレームの同期および縫合は、図１０Ａに示すようなセグメント番号およびフレーム番号に基づいて実現することができる。例えば、メディア・エンジンにおけるバッファが４つの別個のＳＴセグメント・ストリーム１００２１−４を受信した場合、同期エンジンは、セグメント番号（図１０Ａにおける時間セグメント番号Ｎ）およびフレーム番号（図１０Ａにおけるセグメント・フレーム番号＃Ｍ）にしたがって、ＳＴセグメント・ストリームを処理することができる。例えば、同期エンジンは、マトリクス位置（１，１）、（１，２）、（２，１）および（２，２）に関連付けられたＳＴセグメント・ストリーム毎に、特定のセグメント番号に関連付けられた空間的セグメント・フレームを決定することができ、フレーム番号が同期エンジンによって選択され、バッファの出力に送られる。

バッファの出力において、エンコードされた空間的セグメント・フレームをデコードすることができ、図９を参照して説明したのと同様の方法で、デコードされた空間的セグメントを縫合して、表示用のビデオ画像を得ることができる。

図１０Ｂは、同期および縫合されて１つの画像フレームとなった空間的セグメント・フレーム（この例では、４つ）を示す。これらの空間的セグメント・フレームは、ＲＴＰ／ＲＴＳＰストリーミング・プロトコルを用いて、クライアントに移送される。この場合、バッファは、タイム・スタンプが付けられたＲＴＰパケットを含む４つのＲＴＰストリームを受信することができる。ＲＴＰタイム・スタンプの値は、ランダムなＲＴＰオフセット値から開始して、単調に増加することができる。したがって、異なるＲＴＰ−型空間的セグメント・ストリームにおける空間的セグメント・フレーム間の関係を判断するために、ＲＴＰオフセット値の知識が必要になる。

以下で更に詳しく説明するが、ＲＴＳＰサーバに特定の空間的セグメント・ストリームを要求するとき、このＲＴＳＰサーバはＲＴＰタイム・スタンプ情報をクライアントに通知することができる。このＲＴＰタイム・スタンプ情報に基づいて、ランダムなＲＴＰオフセット値を決定することができる。あるいは、特定の空間的セグメント・ストリームを要求するときに、この要求が特定の所定ＲＴＰオフセット値を含んでもよく、ＲＴＳＰサーバは、クライアントにストリーミングするために、このＲＴＰオフセット値を使用する。このような所定のＲＴＰオフセット値は、ＳＭＦにおいて定めることができる（例えば、図３参照）。

したがって、同期エンジンは、バッファされた空間的セグメント・ストリームに関連付けられたＲＴＰオフセット値を受信することができる。これらのＲＴＰオフセット値は、ＳＭＦ１００６において決定することができる。これらのＲＴＰオフセット値を用いて、同期エンジンは、次に、空間的セグメント・ストリームの各々におけるＲＴＰパケット間の関係を判断することができる。例えば、図１０Ｂにおいて、同期エンジンは、４つの異なる空間的セグメント・ストリーム１００４１−４に関連付けられた４つのＲＴＰオフセット値を受信することができる。これらのオフセット値を用いて、同期エンジンは、次に、バッファされている空間的セグメント・ストリームの各々におけるパケットを決定することができる。例えば、空間的セグメント・ストリーム（１，１）におけるＲＴＰタイム・スタンプ８０００（およびＲＴＰオフセット４０００）を有するＲＴＰパケットは、ＲＴＰタイム・スタンプ６０００およびＲＴＰオフセット２０００を有する空間的セグメント・ストリーム（１，２）におけるＲＴＰパケット、ＲＴＰタイム・スタンプ１１０００およびＲＴＰオフセット７０００を有する空間的セグメント・ストリーム（２，１）におけるＲＴＰパケット、およびＲＴＰタイム・スタンプ５０００およびＲＴＰオフセット値１０００を有する空間的セグメント・ストリーム（２，２）におけるＲＴＰパケットに属する。

同期エンジンは、これらのパケットをバッファの出力に送ることができる。その後、図９を参照して説明したのと同様な方法で、これらのパケットは、空間的セグメント・フレームにデコードされ、縫合されて表示用のビデオ画像が得られる。

以上で説明した同期プロセスによって、空間画像フレームのフレーム・レベルでの同期が可能になる。これは、２つ以上の空間的セグメント・ストリームに基づいてシームレスなビデオ画像を構築するために必要になる。

精度が劣るＮＴＰクロック情報を拠り所とする、いわゆるＲＴＣＰ送出側報告(RTCP Sender Reports)のような他の周知の同期方式は、空間的セグメント・ストリームの同期には適していない。

図１１は、本発明の一実施形態にしたがって、空間的にセグメント化されたコンテンツを同期させるための同期情報を決定するプロセス１１００を示す。具体的には、図１１は、異なる空間的セグメント・ストリームに関連付けられたＲＴＰオフセット値を決定するプロセスを示す。このプロセスは、クライアントがＲＴＳＰ ＰＬＡＹ要求を第１配信ノードに送って、ＲＴＳＰサーバに、第１空間的セグメント・ストリームstream1_1RTSPを、起動しているクライアント(client starting)にストリーミングし始めることを要求することから開始することができる。ＲＴＳＰ ＰＬＡＹ要求における範囲パラメータは、ストリームにおけるｔ＝１０秒の位置においてストリーミングを開始するようにＲＴＳＰサーバに命令する（ステップ１１０２）。応答して、ＤＮ１はＲＴＳＰ２００ＯＫ応答をクライアントに送り、要求を実行することを確認する。更に、この応答におけるRTP-infoフィールドは、ストリームの第１パケットがＲＴＰタイム・スタンプ５０００を有することを示す（ステップ１１０４）。次いで、毎秒１００フレームのストリーミング・クロック・レートに基づいて、クライアントは、予期されるＲＴＰタイム・スタンプを１０００と計算することができる（即ち、１００×１０秒）。次いで、受信したＲＴＰタイム・スタンプを、予期されるＲＴＰタイム・スタンプから減算することによって、ＲＴＰオフセット値を４０００に決定することができる（ステップ１１０６）。

同様に、ｔ＝２０秒において、クライアントは、次に、他の空間的セグメント・ストリームstream1_2を第２配信ノードＤＮ２に要求することができる（ステップ１１０８）。応答して、ＤＮ２はＲＴＳＰ２００ＯＫメッセージをクライアントに送り、第１ＲＴＰパケットがＲＴＰタイム・スタンプ７０００を有することを示す（ステップ１１１０）。この情報を用いて、クライアントは、次に、第２空間的セグメント・ストリームに対するＲＴＰタイムスタンプ・オフセットが５０００であると決定する（ステップ１１１２）。したがって、クライアントと配信ノードとの間のＲＴＳＰシグナリングにおけるＲＴＰタイミング情報に基づいて、クライアントは、各空間的セグメント・ストリームに関連付けられたＲＴＰオフセット値を効率的に決定することができる。

以上のことから、ＳＭＦはクライアントが直接ＣＤＮにおける異なる配信ノードにアクセスすることを可能にするので、高速なコンテンツ配信が達成されることになる。高速コンテンツ配信は、表示される空間的セグメント化コンテンツとの正しい対話処理、例えば、ズーミングおよびパンニングを可能にするために必要である。しかしながら、要求とコンテンツ受信との間における多少の遅延は不可避である。これらの遅延は、ＣＤＮにおける異なる配信ノード間で異なる場合もあり得る。図１２は、２つの異なる配信ノードＤＮ１およびＤＮ２にコンテンツを要求したクライアントの例を示す。

ｔ＝０において、クライアントはＲＴＳＰ ＰＬＡＹ要求をＤＮ１に送ることができる（ステップ１２０２）。この要求に応答して、ＤＮ１はＲＴＰパケットをクライアントに送り始めることができる（ステップ１２０４）。何らかの遅延のために、ｔ＝０に関連付けられたＲＴＰパケットは、ｔ＝１においてクライアントによって受信される。同様に、ｔ＝１において送信されるＲＴＰパケットは、ｔ＝２においてクライアントによって受信され、ｔ＝２において送信されるＲＴＰパケットはｔ＝３においてクライアントによって受信されることになる。その時点で、クライアントは第１ＲＴＰパケットｔ＝０の再生を開始することを判断するかもしれないが（ステップ１２０６）、他の２つのＲＴＰパケットｔ＝１および２は未だバッファされているところである。

次に、ＲＴＰパケットｔ＝１の再生を見ている間に、ユーザは、ｔ＝４において、パンニング動作を要求することを決定するとする。この要求に応答して、クライアントは、ｔ＝４から開始する所定の空間的セグメント・ストリームのストリーミングを、第２配信ノードＤＮ２に要求することができる（即ち、範囲パラメータがｔ＝４に設定される）（ステップ１２０８）。しかしながら、ＤＮ２の応答時間は遅いので、ＲＴＰパケットｔ＝４をｔ＝６においてクライアントに送る（ステップ１２１０）。この遅延のために、クライアントは、ｔ＝７においてでないと、ＤＮ２から発する空間的セグメント・ストリームを表示することができない（ステップ１２１２）。これは、ユーザがパンニング要求を出した３秒後である。したがって、この遅延の影響をできるだけ低減する方式が望まれる。

図１３は、本発明の一実施形態にしたがって、空間的にセグメント化されたコンテンツとのユーザ対話処理を改良するプロセスを示す。具体的には、図１３は、図１２を参照して説明したのと同様の、クライアントおよび２つの配信ノードを示す（即ち、１秒で応答する第１配信ノードＤＮ１、および２秒の応答遅延があり、ＤＮ１よりも遅い第２配信ノードＤＮ２）。

開始位置ｔ＝０から第１空間的セグメント・ストリームをストリーミングし始めることをＤＮ１に要求した後（ステップ１３０２）、クライアントは、ｔ＝３においてＲＴＰパケットの再生を開始するとする（即ち、２つのＲＴＰパケットをバッファした後）（ステップ１３０４）。次いで、ＲＴＰパケットｔ＝１の再生を見ている間に、ユーザがｔ＝４においてパンニング動作を要求することを決めたとする。この要求に応答して、クライアントは２つのＲＴＳＰ ＰＬＡＹ要求を第２配信ノードＤＮ２に送ることができる。第１ＲＴＳＰ ＰＬＡＹ要求は、位置ｔ＝４から開始する第２空間的セグメント・ストリームをストリーミングし始めることを第２配信ノードに要求し（ＲＴＳＰ ＰＬＡＹ要求の中にある範囲パラメータを用いる）（ステップ１３０６）、第２ＲＴＳＰ ＰＬＡＹ要求は、位置ｔ＝１から位置ｔ＝４までの第２空間的セグメント・ストリームを、リアル・タイムよりも速いストリーミング・レートでストリーミングし始めることを、ＤＮＳ２に要求する（ＲＴＳＰ ＰＬＡＹ要求の中にある範囲パラメータおよびSPEEDパラメータを用いる）（ステップ１３０８）。

応答して、（ｔ＝６において）第２配信ノードは、ＲＴＰパケットｔ＝１，２，３および４を、クライアントに、レートを高くして送り始めることができるので（ステップ１３１０）、ｔ＝６において、クライアントは、第２配信ノードからのＲＴＰパケットｔ＝３の再生を開始することができる（ステップ１３１２）。同じ時点において、第１ＲＴＳＰ ＰＬＡＹ要求は、通常のレートでＲＴＰパケットの送信を開始することができるので、一旦クライアントの再生がｔ＝４に達したなら、レートを高めたＲＴＰパケットの配信を終了することができる。このように、ユーザは、２秒の遅延があるパンニング動作に気付き、こうしてネットワーク遅延によるユーザの対話処理における影響を低減する。

一時的にレートを高めてＲＴＰパケットを配信することは、ビデオ−オン・デマンドの状況でも用いることができる。リアル・タイムよりも速いストリーミングは許されないライフ・ストリーミングの状況では、他の解決策を用いることができる。この場合、ＩＥＦＴ文書"Unicast-based rapid acquisition of multicast RTP sessions"(http://tools.ietf.org/html.draft-ietf-avt-rapid-acquisition-for-rtp-17)において記載されているようなＩＰ−マルチキャストに基づく高速チャネル変更を用いることができる。

尚、いずれの実施形態に関して説明したいずれの特徴であっても、単独で、または説明した他の特徴と組み合わせて使用することもでき、また他のいずれの実施形態の１つ以上の特徴と組み合わせて使用することもでき、あるいは他のいずれの実施形態のいずれの組み合わせとでも使用することができることは言うまでもない。

本発明の他の実施形態は、コンピュータ・システムと共に用いるためのプログラム生産物として実現することもできる。プログラム生産物のプログラム（１つまたは複数）は、実施形態の機能を定め（本明細書において説明した方法を含む）、種々のコンピュータ読み取り可能記憶媒体上に収容することができる。例示的なコンピュータ読み取り可能記憶媒体には、（ｉ）情報が永続的に格納される書き込み不可の記憶媒体（例えば、ＣＤ−ＲＯＭドライブによって読み取り可能なＣＤ−ＲＯＭディスクのようなコンピュータ内部にある読み取り専用メモリ・デバイス、フラッシュ・メモリ、ＲＯＭチップ、またはあらゆるタイプのソリッド・ステート不揮発性半導体メモリ）、および（ｉｉ）変更可能な情報が格納される書き込み可能な記憶媒体（例えば、ディスケット・ドライブ内にあるフロッピ・ディスク、またはハード・ディスク・ドライブ、あるいはあらゆるタイプのソリッド・ステート・ランダム・アクセス半導体メモリ）が含まれるが、これらに限定されるのではない。本発明は、前述の実施形態には限定されず、添付する請求項の範囲内で変更することができる。

Claims (16)

1. 空間的にセグメント化されたコンテンツを処理する方法であって、
   クライアントがソース・ストリームについて１つ以上の表現を含む空間的マニフェスト・データ構造を受信するステップであって、各空間的表現が、１つ以上の空間的セグメント・ストリームとコンテンツ配信ネットワークに関連付けられた１つ以上の配信ノードを位置特定するための位置情報とを識別し、前記コンテンツ配信ネットワークが前記１つ以上の空間的セグメント・ストリームを前記クライアントに送信するように構成され、前記空間的マニフェスト・データ構造が更に前記空間的セグメント・ストリームにおける空間的セグメント・フレームを縫合して表示用のビデオ・フレームを得るための位置決め情報を含む、ステップと、
   前記空間的表現の内少なくとも１つに関連付けられた１つ以上の空間的セグメント・ストリームを選択し、前記位置情報に基づいて、前記コンテンツ配信ネットワークに関連付けられた少なくとも１つの配信ノードに、前記少なくとも１つの選択された空間的セグメント・ストリームを前記クライアントへ配信することを要求するステップと、
   前記１つ以上の選択された空間的セグメント・ストリームを前記少なくとも１つの配信ノードから受信するステップと
   を含み、
   前記１つ以上の要求された空間的セグメント・ストリームが、ＨＴＴＰ適応ストリーミング・プロトコルを用いて前記クライアントに送信され、前記空間的セグメント・ストリームの少なくとも一部が時間セグメントに分割される、方法。
2. 請求項１記載の方法において、前記位置決め情報が、空間的セグメント・ストリームにおける空間的セグメント・フレームに関連付けられた位置座標である、方法。
3. 請求項１または２記載の方法において、前記空間的マニフェスト・データ構造が、前記ソース・ストリームの第１解像度バージョンに関連付けられた少なくとも１つの第１空間的表現と、前記ソース・ストリームの第２解像度バージョンに関連付けられた少なくとも１つの第２空間的表現とを含む、方法。
4. 請求項３記載の方法において、前記空間的マニフェスト・データ構造が、第１数の空間的セグメント・ストリームに関連付けられた第１空間的表現を含み、前記第２空間的表現が第２数の空間的セグメント・ストリームを含む、方法。
5. 請求項１から４のいずれか１項記載の方法であって、更に、
   前記１つ以上の選択された空間的セグメント・ストリームをバッファするステップと、
   前記１つ以上の空間的セグメント・ストリームに関連付けられた同期情報を受信するステップと、
   前記同期情報に基づいて、前記１つ以上の要求された空間的セグメント・ストリームを同期させるステップと、
   を含む、方法。
6. 請求項１から５のいずれか１項記載の方法であって、
   前記位置決め情報に基づいて、前記空間的に整列した空間的セグメント・フレームを縫合して、再生のための連続ビデオ・フレームを得るステップを含む、方法。
7. 請求項１から６のいずれか１項記載の方法において、前記１つ以上の空間的セグメント・ストリームが、ＲＴＰストリーミング・プロトコルを用いて前記クライアントに送信され、同期情報がＲＴＳＰシグナリング・メッセージにおいて前記クライアントに送信される、方法。
8. 請求項１から７のいずれか１項記載の方法において、隣接する空間的セグメント・フレームが重複する、方法。
9. 請求項８記載の方法において、前記重複が５０％である、方法。
10. メディア処理デバイスにおけるクライアントによってユーザに表示される、空間的にセグメント化されたコンテンツとのユーザ対話処理方法であって、
    ソース・ストリームについて１つ以上の空間的表現を含む空間的マニフェスト・データ構造を受信するステップであって、各空間的表現が、１つ以上の空間的セグメント・ストリームと、コンテンツ配信ネットワークに関連付けられた１つ以上の配信ノードを位置特定するための位置情報とを識別し、前記コンテンツ配信ネットワークが前記１つ以上の空間的セグメント・ストリームを前記クライアントに送信するように構成される、ステップと、
    前記空間的マニフェスト・データ構造における前記位置情報に基づいて、第１空間的表現に関連付けられた１つ以上の空間的セグメント・ストリームを前記コンテンツ配信ネットワークから抽出して、前記１つ以上の空間的セグメント・ストリームを表示するステップと、
    関心領域に関連付けられたユーザ入力を受けるステップであって、前記関心領域が、前記表示された空間的セグメント化コンテンツから選択したエリアを定める、ステップと、
    前記空間的マニフェスト・データ構造における位置決め情報および前記関心領域に基づいて、１つ以上のメディア処理判断基準にしたがって、第２空間的表現を決定するステップであって、前記処理判断基準が、帯域幅、画面解像度、および／またはエンコーディング品質の内少なくとも１つを含む、ステップと、
    を含み、
    前記１つ以上の要求された空間的セグメント・ストリームが、ＨＴＴＰ適応ストリーミング・プロトコルを用いて前記クライアントに送信され、前記空間的セグメント・ストリームの少なくとも一部が時間セグメントに分割される、方法。
11. 請求項１０記載の方法において、前記方法が、更に、
    前記１つ以上の空間的表現について、前記選択した関心領域と重複する空間的セグメント・フレームを判定するステップを含む、方法。
12. 空間的にセグメント化されたコンテンツを処理するためのクライアントであって、
    ソース・ストリームについて１つ以上の空間的表現を含む空間的マニフェスト・データ構造を受信するように構成され、各空間的表現が、１つ以上の空間的セグメント・ストリームと、コンテンツ配信ネットワークに関連付けられた１つ以上の配信ノードを位置特定するための位置情報とを識別し、前記コンテンツ配信ネットワークが前記１つ以上の空間的セグメント・ストリームを前記クライアントに送信するように構成され、前記空間的マニフェスト・データ構造が更に前記空間的セグメント・ストリームにおける空間的セグメント・フレームを縫合して表示用のビデオ・フレームを得るための位置決め情報を含み、
    １つ以上の空間的セグメント・ストリームを選択し、前記位置情報に基づいて、前記コンテンツ配信ネットワークにおける少なくとも１つの配信ノードに、前記１つ以上の選択された空間的セグメント・ストリームを前記クライアントに送信するように要求し、
    前記１つ以上の選択された空間的セグメント・ストリームを前記少なくとも１つの配信ノードから受信する、
    ように構成され、
    前記１つ以上の要求された空間的セグメント・ストリームが、ＨＴＴＰ適応ストリーミング・プロトコルを用いて前記クライアントに送信され、前記空間的セグメント・ストリームの少なくとも一部が時間セグメントに分割される、クライアント。
13. 請求項１２記載のクライアントであって、更に、前記１つ以上の選択された空間的セグメント・ストリームをバッファし、前記１つ以上の空間的セグメント・ストリームに関連付けられた同期情報を受信し、前記同期情報に基づいて、前記１つ以上の要求された空間的セグメント・ストリームを同期させるように構成される、クライアント。
14. 請求項１２または１３記載のクライアントであって、更に、前記空間的マニフェスト・データ構造における位置決め情報に基づいて、空間的セグメント・フレームを縫合するように構成される、クライアント。
15. 請求項１２から１４のいずれか１項記載のクライアントにおいて用いるための空間的マニフェスト・データ構造であって、前記データ構造が、コンテンツ配信ネットワークから発する空間的にセグメント化されたコンテンツの抽出および表示を制御し、前記データ構造が、ソース・ストリームについて１つ以上の空間的表現を含み、各空間的表現が、１つ以上の空間的セグメント・ストリームと、前記コンテンツ配信ネットワークにおける少なくとも１つ以上の配信ノードを位置特定するための位置情報と、前記空間的セグメント・ストリームにおける空間的セグメント・フレームを縫合して、表示用ビデオ・フレームを得るための位置決め情報とを含む、空間的マニフェスト・データ構造。
16. ソフトウェア・コード部分を含むコンピュータ・プログラムであって、前記ソフトウェア・コード部分をコンピュータのメモリにおいて実行すると、請求項１から１１までのいずれか１項記載の方法を実行するように構成される、コンピュータ・プログラム。

Images