関連出願の相互参照
[0001]本願は、2017年5月25日に出願された米国仮特許出願第62/511,189号の利益を主張し、その内容全体が、参照によってここに組み込まれる。
[0002]この開示は、符号化されたビデオデータの記憶およびトランスポートに関する。
[0003]デジタルビデオ能力は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲーミングデバイス、ビデオゲームコンソール、セルラまたは衛星無線電話、ビデオテレビ会議デバイス、および同様のものを含む、幅広い範囲のデバイスに組み込まれることができる。デジタルビデオデバイスは、デジタルビデオ情報をより効率的に送信および受信するために、MPEG-2、MPEG-4、ITU-T H.263またはITU-T H.264/MPEG-4、Part 10、アドバンスドビデオコーディング(AVC)、(高効率ビデオコーディング(HEVC)とも呼ばれる)ITU-T H.265、およびそのような規格の拡張によって定義される規格において記述されているもののような、ビデオ圧縮技法をインプリメントする。
[0004]ビデオ圧縮技法は、ビデオシーケンスに内在する冗長性を低減または取り除くために、空間的予測および/または時間的予測を実行する。ブロックベースのビデオコーディングの場合、ビデオフレームまたはスライスは、複数のマクロブロックへと区分化され得る。各マクロブロックはさらに区分化されることができる。イントラコーディングされた(I)フレームまたはスライス中のマクロブロックは、近隣のマクロブロックに対して空間的予測を使用して符号化される。インターコーディングされた(PまたはB)フレームまたはスライス中のマクロブロックは、同じフレームまたはスライス中の近隣のマクロブロックに対して空間的予測を、あるいは他の基準フレームに対して時間的予測を使用し得る。
[0005]ビデオデータが符号化された後に、ビデオデータは、送信または記憶のためにパケット化され得る。ビデオデータは、国際標準化機構(ISO)ベースメディアファイルフォーマット、およびAVCのようなその拡張のような、多様な規格のうちの任意のものに準拠するビデオファイルへとアセンブルされ得る。
[0006]一例では、方法は、魚眼ビデオデータを含むファイルを処理することと、ファイルは、魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造を含み、ここにおいて、複数のシンタックス要素は、魚眼ビデオデータがモノスコープ(monoscopic)であるかまたはステレオスコープ(stereoscopic)であるかを明示的に示す第1のシンタックス要素と、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを暗示的に示す1つまたは複数のシンタックス要素とを含み、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、第1のシンタックス要素に基づいて決定することと、モノスコープまたはステレオスコープとして、魚眼ビデオデータを決定に基づいてレンダリングすることとを含む。
[0007]別の例では、デバイスは、魚眼ビデオデータを含むファイルの少なくとも一部分を記憶するように構成されたメモリと、ファイルは、魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造を含み、ここにおいて、複数のシンタックス要素は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第1のシンタックス要素と、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを暗示的に示す1つまたは複数のシンタックス要素とを含み、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、第1のシンタックス要素に基づいて決定することと、モノスコープまたはステレオスコープとして、魚眼ビデオデータを決定に基づいてレンダリングすることとを行うように構成された1つまたは複数のプロセッサと含む。
[0008]別の例では、方法は、魚眼ビデオデータと、魚眼ビデオデータをキャプチャするために使用されるカメラの外部(extrinsic)パラメータとを取得することと、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、外部パラメータに基づいて決定することと、魚眼ビデオデータと、魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造とをファイル中に符号化することとを含み、ここにおいて、複数のシンタックス要素は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第1のシンタックス要素と、魚眼ビデオデータをキャプチャするために使用されるカメラの外部パラメータを明示的に示す1つまたは複数のシンタックス要素とを含む。
[0009]別の例では、デバイスは、魚眼ビデオデータを記憶するように構成されたメモリと、魚眼ビデオデータをキャプチャするために使用されるカメラの外部パラメータを取得することと、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、外部パラメータに基づいて決定することと、魚眼ビデオデータと、魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造とをファイル中に符号化することとを行うように構成された1つまたは複数のプロセッサとを含み、ここにおいて、複数のシンタックス要素は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第1のシンタックス要素と、魚眼ビデオデータをキャプチャするために使用されるカメラの外部パラメータを明示的に示す1つまたは複数のシンタックス要素とを含む。
[0010]1つまたは複数の例の詳細は、添付の図面および以下の説明に記載されている。他の特徴、目的、および利点が、説明、図面、および特許請求の範囲から明らかとなるであろう。
この開示に説明される1つまたは複数の実例的な技法にしたがった、全方位画像コンテンツをキャプチャするための実例的なデバイスを例示するブロック図である。
この開示に説明される1つまたは複数の実例的な技法にしたがった、全方位画像コンテンツをキャプチャするための実例的なデバイスを例示するブロック図である。
複数の魚眼画像を含むピクチャの例である。
この開示に説明される1つまたは複数の実例的な技法にしたがった、全方位画像の様々な外部パラメータおよび視野を例示する概念図である。
この開示に説明される1つまたは複数の実例的な技法にしたがった、全方位画像の様々な外部パラメータおよび視野を例示する概念図である。
この開示に説明される1つまたは複数の実例的な技法にしたがった、全方位画像の様々な外部パラメータおよび視野を例示する概念図である。
この開示に説明される1つまたは複数の実例的な技法にしたがった、全方位画像の様々な外部パラメータおよび視野を例示する概念図である。
この開示に説明される1つまたは複数の実例的な技法にしたがった、全方位画像の様々な外部パラメータおよび視野を例示する概念図である。
この開示に説明される1つまたは複数の実例的な技法にしたがった、全方位画像の様々な外部パラメータおよび視野を例示する概念図である。
ネットワークを通してメディアデータをストリーミングするための技法をインプリメントする実例的なシステムを例示するブロック図である。
実例的なマルチメディアコンテンツの要素を例示する概念図である。
実例的なビデオファイルの要素を例示するブロック図であり、それは、リプレゼンテーション(a representation)のセグメントに対応し得る。
この開示の1つまたは複数の技法にしたがった、魚眼ビデオデータを含むファイルを処理するための実例的な技法を例示するフローチャートである。
この開示の1つまたは複数の技法にしたがった、魚眼ビデオデータを含むファイルを生成するための実例的な技法を例示するフローチャートである。
詳細な説明
[0019]この開示に説明される実例的な技法は、全方位ビデオまたは画像データを表すファイルを処理することに関する。全方位メディアコンテンツがある特定のデバイス(例えば、ヘッドマウントディスプレイおよびヘッドフォン)で消費される(consumed)とき、メディアがキャプチャされた場所および時間(例えば、(1つまたは複数の)カメラがあったところ)にユーザがいたかのように、ユーザの視聴している向き(viewing orientation)に対応するメディアの一部のみがレンダリングされる。全方位メディアアプリケーションの最もポピュラーな形態のうちの1つは、360度ビデオとしても知られる全方位ビデオである。全方位ビデオは、最大で360度までのシーンをカバーする複数のカメラによって典型的にキャプチャされる。
[0020]一般に、全方位ビデオは、全方位画像のシーケンスから形成される。それ故に、この開示に説明される実例的な技法は、全方位画像コンテンツを生成することに関して説明される。その後、全方位ビデオコンテンツのために、これらの全方位画像は、順次に表示されることができる。いくつかの例では、ユーザは、(例えば、ユーザの360度周囲全体のスナップショットとして)全方位画像のみを撮ることを所望し得、およびこの開示に説明される技法は、そのような実例的なケースにも適用可能である。
[0021]全方位ビデオは、ステレオスコープ(stereoscopic)またはモノスコープ(monoscopic)であり得る。ビデオがステレオスコープであるときは、視聴者が奥行きを知覚し得るように、異なる画像が各目に示される。そのため、ステレオスコープビデオは、各方向を向いた2つのカメラを使用して典型的にキャプチャされる。ビデオがモノスコープであるときは、同じ画像が両目に示される。
[0022]ビデオデータは、1つまたは複数の魚眼レンズを使用してキャプチャされる魚眼ビデオデータである(あるいは、1つまたは複数の魚眼レンズを使用してキャプチャされたかのように見えるように生成された)と考えられ得る。魚眼レンズは、広パノラマまたは半球の画像(hemispherical image)を作成することを意図された強度の視覚的歪みを生じさせる超広角レンズであり得る。
[0023]本技法は、キャプチャされたビデオコンテンツ、仮想現実、および概してビデオおよび画像を表示することに適用可能であり得る。本技法は、モバイルデバイスにおいて使用され得るが、本技法は、モバイルアプリケーションに限定されると見なされるべきではない。一般に、本技法は、仮想現実アプリケーション、ビデオゲームアプリケーション、または360度球状ビデオ/画像環境が所望される他のアプリケーションのためのものであり得る。
[0024]いくつかの例では、全方位画像コンテンツは、2つの魚眼レンズを含むカメラデバイスでキャプチャされ得る。2つの魚眼レンズが画像コンテンツの球(sphere)の対向する両部分(opposite portions)をキャプチャするために、カメラデバイスの対向する両側(opposing sides)上に位置付けられる場合、画像コンテンツは、モノスコープであり、および360度ビデオの全球をカバーし得る。同様に、2つの魚眼レンズが画像コンテンツの球の同じ部分をキャプチャするために、カメラデバイスの同じ側上に位置付けられる場合、画像コンテンツは、ステレオスコープであり、および360度ビデオの球の半分をカバーし得る。カメラによって生成される画像は、円形画像である(例えば、1つの画像フレームが、2つの円形画像を含む)。
[0025]図1Aおよび1Bは、この開示に説明される1つまたは複数の実例的な技法にしたがった、全方位画像コンテンツをキャプチャするための実例的なデバイスを例示するブロック図である。図1Aに例示されているように、コンピューティングデバイス10Aは、球全体をカバーするモノスコープ画像コンテンツ(例えば、全360度ビデオコンテンツ)をキャプチャするために、コンピューティングデバイス10Aの両側上にロケートされた魚眼レンズ12Aと魚眼レンズ12Bとを含むビデオキャプチャデバイスである。図1Bに例示されているように、コンピューティングデバイス10Bは、球のほぼ半分をカバーするステレオスコープ画像コンテンツをキャプチャするために、コンピューティングデバイス10Bの同じ側上にロケートされた魚眼レンズ12Cと魚眼レンズ12Dとを含むビデオキャプチャデバイスである。
[0026]上記で説明されたように、カメラデバイスは、複数の魚眼レンズを含む。いくつかの実例的なカメラデバイスは、2つの魚眼レンズを含むが、実例的な技法は、2つの魚眼レンズに限定されない。1つの実例的なカメラデバイスは、16個のレンズ(例えば、3D VRコンテンツを撮影するための16台のカメラアレイ)を含み得る。別の実例的なカメラデバイスは、各々が195度の画角(angle of view)を有する8つのレンズを含み得る(例えば、各レンズが、360度の画像コンテンツのうちの195度をキャプチャする)。他の実例的なカメラデバイスは、3つまたは4つのレンズを含む。いくつかの例は、360度の画像コンテンツをキャプチャする360度レンズを含み得る。
[0027]この開示に説明される実例的な技法は概して、全方位画像/ビデオをキャプチャする2つの魚眼レンズに関して説明される。しかしながら、実例的な技法は、それに限定されない。実例的な技法は、複数のレンズ(例えば、2つ以上)をそれらレンズが魚眼レンズでない場合であっても含む、および複数の魚眼レンズを含む、実例的なカメラデバイスに適用可能であり得る。例えば、実例的な技法は、キャプチャされた画像を繋ぎ合わせる方法を説明し、および本技法は、複数のレンズ(例として、それらは魚眼レンズであり得る)からの複数のキャプチャされた画像が存在する例に適用可能であり得る。実例的な技法が2つの魚眼レンズに関して説明される一方で、実例的な技法は、それに限定されず、および全方位画像/ビデオをキャプチャするために使用される様々なカメラタイプに適用可能である。
[0028]この開示の技法は、ISOベースメディアファイルフォーマット(例えば、ISOBMFF、ISO/IEC 14496-12)、およびMPEG-4ファイルフォーマット(ISO/IEC 14496-15)、第3世代パートナーシッププロジェクト(3GPP(登録商標))ファイルフォーマット(3GPP TS 26.244)、およびビデオコーデックのAVCおよびHEVCファミリのためのファイルフォーマット(ISO/IEC 14496-15)、または他の同様のビデオファイルフォーマットを含む、ISOBMFFから派生した他のファイルフォーマットのうちの任意のものにしたがってカプセル化されたビデオデータに準拠するビデオファイルに適用され得る。
[0029]ISOBMFFは、AVCファイルフォーマットのような多くのコーデックカプセル化フォーマットの、ならびに、MPEG-4ファイルフォーマット、3GPPファイルフォーマット(3GP)、およびDVBファイルフォーマットのような多くのマルチメディアコンテナフォーマットの基礎として使用される。オーディオおよびビデオのような連続メディアに加えて、画像のような静的メディア、ならびにメタデータが、ISOBMFFに準拠するファイル中に記憶されることができる。ISOBMFFにしたがって構造化されたファイルは、ローカルメディアファイル再生、リモートファイルのプログレッシブダウンロード、HTTPを通した動的適応型ストリーミング(DASH)のためのセグメント、ストリーミングされることになるコンテンツのためのコンテナおよびそのパケット化命令、および受信されるリアルタイムメディアストリームの記録を含む、多くの目的のために使用され得る。
[0030]ボックスは、ISOBMFFにおけるエレメンタリシンタックス構造であり、4キャラクタコード化ボックスタイプ、ボックスのバイトカウント、およびペイロードを含む。ISOBMFFファイルは、ボックスのシーケンスから成り、およびボックスは、他のボックスを包含し得る。ムービーボックス(「moov」)は、ファイル中に存在する連続メディアストリームについてのメタデータを包含し、各々は、トラックとしてファイル中に表される。トラックについてのメタデータは、トラックボックス(「trak」)中にエンクローズされる(enclosed)が、その一方でトラックのメディアコンテンツは、メディアデータボックス(「mdat」)中にエンクローズされるか、または別個のファイル中に直接エンクローズされるかのいずれかである。トラックについてのメディアコンテンツは、オーディオまたはビデオアクセスユニットのようなサンプルのシーケンスから成る。
[0031]魚眼ビデオデータをレンダリングするとき、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかをビデオ復号器が決定することが望まれ得る。例えば、ビデオ復号器が魚眼ビデオデータのピクチャ中に含まれる円形画像を表示および/または繋ぎ合わせる方式は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかに直接依存する。
[0032]いくつかの例では、ビデオ復号器は、ファイルによって記述される魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを暗示的に示す、ファイル中に含まれた1つまたは複数のシンタックス要素に基づいて、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを決定し得る。例えば、ビデオ符号化器は、魚眼ビデオデータをキャプチャするために使用されるカメラの各々の外部パラメータ(例えば、ヨー角(yaw angle)、ピッチ角、ロール角、および1つまたは複数の空間的オフセットのような物理/ロケーション属性)を記述するシンタックス要素をファイル中に含め得、およびビデオ復号器は、ファイルによって記述されるビデオデータがモノスコープであるかまたはステレオスコープであるかを算出するために、外部パラメータを処理し得る。一例として、外部パラメータの処理が、カメラが同じ方向を向いており、且つ空間的オフセットを有しているというインジケーションをもたらす場合、ビデオ復号器は、ビデオデータがステレオスコープであると決定し得る。別の例として、外部パラメータの処理が、カメラが対向する方向(opposite directions)を向いていることを示す場合、ビデオ復号器は、ビデオデータがモノスコープであると決定し得る。しかしながら、いくつかの例では、そのような追加のリソース集約的な(resource intensive)算出を実行する必要なしに、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかをビデオ復号器が決定することが可能であることが望ましくあり得る。加えて、いくつかの例では、外部パラメータの処理は、モノスコープまたはステレオスコープとしてのビデオデータの正しい(例えば、意図された通りの)分類をもたらさないことがあり得る。一例として、外部パラメータの値は、符号化/送信/復号中に破損し得る。別の例として、外部パラメータは、符号化器において正確に提供されていないことがあり得る。
[0033]この開示の1つまたは複数の技法にしたがって、ビデオ符号化器は、ファイルによって記述される魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第1のシンタックス要素をファイル中に含め得る。ファイルは、魚眼ビデオデータの外部パラメータであるシンタックス要素に加えて、第1のシンタックス要素を含み得る。そのため、ファイルは、ファイルによって記述される魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかの明示的インジケーション(すなわち、第1のシンタックス要素)と暗示的インジケーション(すなわち、外部パラメータであるシンタックス要素)との両方を含み得る。このように、ビデオ復号器は、(例えば、外部パラメータに基づいて追加の算出を実行する必要なしに)ビデオデータがモノスコープであるかまたはステレオスコープであるかを正確に決定し得る。
[0034]ISOBMFFは、次のタイプのトラックを指定する:エレメンタリメディアストリームを包含するメディアトラック、メディア送信命令を含むか、または受信されたパケットストリームを表すかのいずれかであるヒントトラック、および時間同期されたメタデータを備える時間指定された(timed)メタデータトラック。
[0035]当初は記憶のために設計されたにも関わらず、ISOBMFFは、ストリーミングに、例えば、プログレッシブダウンロードまたはDASHに非常に有益であることが証明されている。ストリーミングの目的のために、ISOBMFFにおいて定義されたムービーフラグメントが使用されることができる。
[0036]各トラックについてのメタデータは、サンプル記述エントリのリストを含み、各々は、そのトラック中で使用されるコーディングまたはカプセル化フォーマット、およびそのフォーマットを処理するために必要とされる初期化データを提供する。各サンプルは、トラックのサンプル記述エントリのうちの1つに関連付けられる。
[0037]ISOBMFFは、様々なメカニズムを用いてサンプル固有メタデータを指定することを可能にする。サンプルテーブルボックス(「stbl」)内の特定のボックスは、共通のニーズに応えるために標準化されている。例えば、同期サンプルボックス(「stss」)は、トラックのランダムアクセスサンプルをリストするために使用される。サンプルグルーピングメカニズムは、ファイル中にサンプルグループ記述エントリとして指定された同じプロパティを共有するサンプルのグループへの4キャラクタグルーピングタイプにしたがったサンプルのマッピングを可能にする。いくつかのグルーピングタイプが、ISOBMFFにおいて指定されている。
[0038]仮想現実(VR)は、非物理的世界とインタラクトすることを可能にする没入したユーザの動きによって相関された自然および/または合成イメージおよびサウンドのレンダリングによって作成されたその世界の中に仮想的に存在するための能力である。ヘッドマウントディスプレイ(HMD)のようなレンダリングデバイスと、(360度ビデオと呼ばれることも多い)VRビデオ作成とにおいてなされた近年の進歩により、有意な品質のエクスペリエンスが提供されることができる。VRアプリケーションは、ゲーミング、トレーニング、教育、スポーツビデオ、オンラインショッピング、アダルトエントレインメント(entrainment)、等を含む。
[0039]典型的なVRシステムは、次のコンポーネントのうちの1つまたは複数を含み得、それらは、次のステップのうちの1つまたは複数を実行し得る:
1)異なる方向に向いており、且つ理想的には集合的にカメラセットの周囲の全てのビューポイントをカバーしている複数の個々のカメラから典型的に成るカメラセット。
2)天球ビデオ(spherical video)になるが、(世界地図のような)正距円筒図法(equi-rectangular)または立方体(cube)マップのような長方形フォーマットにマッピングされるイメージスティッチング。ここで、複数の個々のカメラによって撮られたビデオピクチャは、時間ドメイン中で同期され、および空間ドメイン中でステッチされる(stitched)。
3)マッピングされた長方形フォーマットのビデオは、ビデオコーデック、例えば、H.265/HEVCまたはH.264/AVC、を使用して符号化/圧縮される。
4)圧縮されたビデオビットストリーム(1つまたは複数)は、メディアフォーマットで記憶および/またはカプセル化され、および受信機にネットワークを通じて送信され得る(ことによると、ユーザによって見られているエリアのみをカバーするサブセットのみ)。
5)受信機は、ことによるとあるフォーマットでカプセル化されたビデオビットストリーム(1つ以上)またはその一部を受信し、およびレンダリングデバイスに復号されたビデオ信号またはその一部を送る。
6)レンダリングデバイスは、例えば、頭の動きおよび目の動きの瞬間さえもトラックすることができるHMDであり、および没入型のエクスペリエンスがユーザに配信されるようにビデオの対応する部分をレンダリングすることができる。
[0040]全方位メディアアプリケーションフォーマット(OMAF:Omnidirectional Media Application Format)は、全方位メディアアプリケーションを可能にするメディアアプリケーションフォーマットを定義するために、MPEGによって開発されており、360°ビデオおよび関連するオーディオを伴うVRアプリケーションに重点を置いている。OMAFは、天球または360°ビデオの2次元長方形ビデオへの変換のために使用されることができる投影(プロジェクション)およびリージョンワイズパッキング(region-wise packing)を指定し、それに続いてISOベースメディアファイルフォーマット(ISOBMFF)を使用して全方位メディアおよび関連するメタデータをどのように記憶するかと、HTTPを通した動的適応型ストリーミング(DASH)を使用して全方位メディアをどのようにカプセル化、シグナリング、およびストリーミングするかと、そして最後に、全方位メディア信号の圧縮および再生のためにどのビデオおよびオーディオコーデックならびにメディアコーディング構成が使用されることができるかとを指定する。
[0041]投影およびリージョンワイズパッキングは、投影される全方位ビデオのための天球(sphere)信号から2Dビデオピクチャを生成するために、コンテンツ生成側において使用される処理である。投影は通常、スティッチングとともに行われ、それは、各ビデオピクチャのための複数のカメラキャプチャされた画像(the multiple camera captured images)から天球信号を生成し得る。投影は、VRビデオにおける基本的な処理ステップであり得る。典型的な投影タイプは、正距円筒図法および立方体マップを含む。OMAF国際規格案(DIS)は、正距円筒図法の投影タイプのみをサポートする。リージョンワイズパッキングは、(コンテンツ生成側のビューポートからの)投影後のオプションのステップである。リージョンワイズパッキングは、符号化前のパッキングされたピクチャの任意の長方形(rectangular)領域の操作(サイズ変更、再位置付け、回転、およびミラーリング)を可能にする。
[0042]図2は、複数の魚眼画像を含むピクチャの例である。OMAF DISは、魚眼VR/360ビデオフォーマットをサポートし、ここにおいて、符号化前に2Dビデオを生成するために、投影およびオプションとしてリージョンワイズパッキングを適用する代わりに、各アクセスユニットについて、キャプチャするカメラからの円形画像が、2Dピクチャ中に直接埋め込まれる。例えば、図2に示されているように、第1の魚眼画像202および第2の魚眼画像204が、2Dピクチャ200中に埋め込まれている。
[0043]そのような魚眼ビデオはその後、符号化され得、およびビットストリームは、ISOBMFFファイル中にカプセル化され得、およびDASHリプレゼンテーションとしてさらにカプセル化され得る。加えて、魚眼ビデオの特性を示すパラメータを含む魚眼ビデオのプロパティが、シグナリングされ、およびクライアント側において360ビデオを正しくレンダリングするために使用され得る。魚眼VR/360ビデオアプローチの1つの利点は、それがモバイル端末による低コストユーザ生成VRコンテンツをサポートすることである。
[0044]OMAF DISでは、制限されたビデオサンプルエントリタイプ「resv」に対する魚眼全方位ビデオスキームの使用は、復号されたピクチャが魚眼ビデオピクチャであることを示す。魚眼全方位ビデオスキームの使用は、SchemeTypeBox内の「fodv」(魚眼全方位ビデオ)に等しいscheme_typeによって示される。魚眼ビデオのフォーマットは、SchemeInformationBox内に包含されたFisheyeOmnidirectionalVideoBoxで示され、それは、サンプルエントリ中に含まれているRestrictedSchemeInfoBox中に含まれている。OMAF DISの現在の草案(Information technology - Coded representation of immersive media (MPEG-I) - Part 2: Omnidirectional media format, ISO/IEC FDIS 14496-15:2014(E), ISO/IEC JTC 1/SC 29/WG 11, w16824, 2014-01-13、以下において「OMAF DISの現在の草案」と記載される)では、スキームタイプが「fodv」であるときに、1つおよび1つのみのFisheyeOmnidirectionalVideoBoxが、SchemeInformationBox中に存在すべきである。FisheyeOmnidirectionalVideoBoxがSchemeInformationBox中に存在するとき、StereoVideoBoxおよびRegionWisePackingBoxは、同じSchemeInformationBox中に存在するべきではない。OMAF DISの第6節(clause 6)中に規定されているようなFisheyeOmnidirectionalVideoBoxは、魚眼ビデオプロパティパラメータを包含するFisheyeOmnidirectionalVideoInfo( )シンタックス構造を包含する。
[0045]OMAF DISの現在の草案中のFisheyeOmnidirectionalVideoInfo( )シンタックス構造のシンタックスは、次の通りである。
aligned(8) class FisheyeOmnidirectionalVideoInfo( ) {
bit(24) reserved = 0;
unsigned int(8) num_circular_images;
for(i=0; i< num_circular_images; i++) {
unsigned int(32) image_center_x;
unsigned int(32) image_center_y;
unsigned int(32) full_radius;
unsigned int(32) picture_radius;
unsigned int(32) scene_radius;
unsigned int(32) image_rotation;
bit(30) reserved = 0;
unsigned int(2) image_flip;
unsigned int(32) image_scale_axis_angle;
unsigned int(32) image_scale_x;
unsigned int(32) image_scale_y;
unsigned int(32) field_of_view;
bit(16) reserved = 0;
unsigned int (16) num_angle_for_displaying_fov;
for(j=0; j< num_angle_for_displaying_fov; j++) {
unsigned int(32) displayed_fov;
unsigned int(32) overlapped_fov;
}
signed int(32) camera_center_yaw;
signed int(32) camera_center_pitch;
signed int(32) camera_center_roll;
unsigned int(32) camera_center_offset_x;
unsigned int(32) camera_center_offset_y;
unsigned int(32) camera_center_offset_z;
bit(16) reserved = 0;
unsigned int(16) num_polynomial_coefficeients;
for(j=0; j< num_polynomial_coefficients; j++) {
unsigned int(32) polynomial_coefficient_K;
}
bit(16) reserved = 0;
unsigned int (16) num_local_fov_region;
for(j=0; j<num_local_fov_region; j++) {
unsigned int(32) start_radius;
unsigned int(32) end_radius;
signed int(32) start_angle;
signed int(32) end_angle;
unsigned int(32) radius_delta;
signed int(32) angle_delta;
for(rad=start_radius; rad<= end_radius; rad+=radius_delta) {
for(ang=start_angle; ang<= ang_radius; ang+=angle_delta) {
unsigned int(32) local_fov_weight;
}
}
}
bit(16) reserved = 0;
unsigned int(16) num_polynomial_coefficients_lsc;
for(j=0; j< num_polynomial_coefficients_lsc; j++) {
unsigned int (32) polynomial_coefficient_K_lsc_R;
unsigned int (32) polynomial_coefficient_K_lsc_G;
unsigned int (32) polynomial_coefficient_K_lsc_B;
}
}
bit(24) reserved = 0;
unsigned int(8) num_deadzones;
for(i=0; i< num_deadzones; i++) {
unsigned int(16) deadzone_left_horizontal_offset;
unsigned int(16) deadzone_top_vertical_offset;
unsigned int(16) deadzone_width;
unsigned int(16) deadzone_height;
}
}
[0046]OMAF DISの現在の草案中のFisheyeOmnidirectionalVideoInfo( )シンタックス構造のセマンティクスは、次の通りである。
[0047]num_circular_imagesは、このボックスが適用される各サンプルのコーディングされたピクチャ中の円形画像(circular images)の数を指定する。典型的に、値は2に等しいが、他の非ゼロ値もまた可能である。
[0048]image_center_xは、このボックスが適用される各サンプルのコーディングされたピクチャ中の円形画像の中心の水平座標をルーマサンプルで指定する固定小数点16.16値である。
[0049]image_center_yは、このボックスが適用される各サンプルのコーディングされたピクチャ中の円形画像の中心の垂直座標をルーマサンプルで指定する固定小数点16.16値である。
[0050]full_radiusは、円形画像の中心から全周画像(the full round image)の端までの半径をルーマサンプルで指定する固定小数点16.16値である。
[0051]picture_radiusは、円形画像の中心から画像境界の最も近い端までの半径をルーマサンプルで指定する固定小数点16.16値である。円形魚眼画像は、カメラピクチャによってクロップされ得る(may be cropped)。したがって、この値は、円の半径を示し、ここにおいて、ピクセルが使用可能である。
[0052]scene_radiusは、円形画像の中心から画像中のエリアの最も近い端までの半径をルーマサンプルで指定する固定小数点16.16値であり、ここで、カメラ本体自体からの障害物が存在せず、およびエンクローズされたエリア内では、繋ぎ合わせる(ステッチする(stitching))のに大きすぎるレンズ歪みは存在しないことが保証される。
[0053]image_rotationは、円形画像の回転の量を度(degree)で指定する固定小数点16.16値である。画像は、画像+/-90度、または+/-180度、または任意の他の値だけ回転され得る。
[0054]image_flipは、画像が反転されているかどうか、およびどのように画像が反転されているか、そしてこのことから、逆反転動作が適用される必要があるかどうか、およびどのように逆反転動作が適用される必要があるかを指定する。値0は、画像が反転されていないことを示す。値1は、画像が垂直に反転されていることを示す。値2は、画像が水平に反転されていることを示す。値3は、画像が垂直および水平の両方に反転されていることを示す。
[0055]image_scale_axis_angle、image_scale_x、および image_scale_yは、画像が軸に沿ってスケーリングされているかどうか、およびどのように画像が軸に沿ってスケーリングされているかを指定する3つの固定小数点16.16値である。軸は、image_scale_axis_angleの値によって度(degree)で示されるような単一の角度によって定義される。0度の角度は、水平ベクトルが完全に水平であり、および垂直ベクトルが完全に垂直であることを意味する。image_scale_xおよびimage_scale_yの値は、軸に対してそれぞれ平行および直交である方向のスケーリング比を示す。
[0056]field_of_viewは、魚眼レンズの視野を度で指定する固定小数点16.16値である。半球魚眼レンズについての典型的な値は、180.0度である。
[0057]num_angle_for_displaying_fovは、角度の数を指定する。num_angle_for_displaying_fovの値にしたがって、displayed_fovおよびoverlapped_fovの複数の値は、等しい間隔で定義され、それは、12時において開始し、および時計回りに進む。
[0058]displayed_fovは、各魚眼カメラ画像の表示された視野および対応する画像エリアを指定する。overlapped_fovは、オーバラップされた領域を含む領域を指定し、それは通常、複数の円形画像間の視野の観点から、ブレンディングのために使用される。displayed_fovおよびoverlapped_fovの値は、field_of_viewの値以下である。
[0059]注記:field_of_viewの値は、各魚眼レンズの物性によって決定されるが、その一方でdisplayed_fovおよびoverlapped_fovは、複数の魚眼レンズの構成によって決定される。例えば、num_circular_imagesの値が2に等しく、および2つのレンズが対称的にロケートされているとき、displayed_fovおよびoverlapped_fovの値は、デフォルトでそれぞれ180および190として設定されることができる。しかしながら、値は、レンズの構成とコンテンツの特性とに依存して変更されることができる。例えば、displayed_fov値(左カメラ=170および右カメラ=190)およびoverlapped_fov値(左カメラ185および右カメラ=190)でのスティッチング品質がデフォルト値(180および190)での品質より良い場合、またはカメラの物理的構成が非対称である場合、等しくないdisplayed_fovおよびoverlapped_fov値が取られることができる。加えて、複数の(N>2)魚眼画像に関して言えば、単一のdisplayed_fov値は、各魚眼画像の正確なエリアを指定することができない。図6に示されているように、displayed_fov(602)は、方向にしたがって変動する。複数の(N>2)魚眼画像を操作するために、num_angle_for_displaying_fovが導入される。例えば、この値が12に等しい場合、魚眼画像は、各セクタ角度が30度である12個のセクタへと分割される。
[0060]camera_center_yawは、各サンプルのコーディングされたピクチャ中の円形画像の中心ピクセルが球面に投影される地点のヨー角を2-16度の単位で指定する。これは、グローバル座標軸に対するカメラ外部パラメータを指定する3つの角度のうちの第1のものである。camera_center_yawは、両端値を含む、-180*216~180*216-1の範囲中にあるべきである。
[0061]camera_center_pitchは、各サンプルのコーディングされたピクチャ中の円形画像の中心ピクセルが球面に投影される地点のピッチ角を2-16度の単位で指定する。camera_center_pitchは、両端値を含む、-90*216~90*216の範囲中にあるべきである。
[0062]camera_center_rollは、各サンプルのコーディングされたピクチャ中の円形画像の中心ピクセルが球面に投影される地点のロール角を2-16度の単位で指定する。camera_center_rollは、両端値を含む、-180*216~180*216-1の範囲中にあるべきである。
[0063]camera_center_offset_x、camera_center_offset_yおよびcamera_center_offset_zは、コーディングされたピクチャ中の円形画像中のピクセルが投影される単位球の原点からのXYZオフセット値を示す固定小数点8.24値である。camera_center_offset_x、camera_center_offset_yおよびcamera_center_offset_zは、両端値を含む、-1.0~1.0の範囲中にあるべきである。
[0064]num_polynomial_coefficientsは、存在する多項式係数の数を指定する整数である。多項式係数polynomial_coefficient_Kのリストは、魚眼空間から歪められていない(undistored)平面画像への変換を指定する多項式中の係数を表す固定小数点8.24値である。
[0065]num_local_fov_regionは、異なる視野を有するローカルフィッティング領域の数を指定する。
[0066]start_radius、end_radius、start_angle、およびend_angleは、ローカルに表示するための実際の視野を変更するために、ローカルフィッティング/ワーピング(local fitting/warping)のための領域を指定する。start_radiusおよびend_radiusは、最小および最大半径値を指定する固定小数点16.16値である。start_angleおよびend_angleは、12時において開始し、時計回りに増大する最小および最大角度値を2-16度の単位で指定する。start_angleおよびend_angleは、両端値を含む、-180*216~180*216-1の範囲中にあるべきである。
[0067]radius_deltaは、各半径についての異なる視野を表すためのデルタ半径値を指定する固定小数点16.16値である。
[0068]angle_deltaは、各角度についての異なる視野を表すためのデルタ角度値を2-16度の単位で指定する。
[0069]local_fov_weightは、start_radius、end_radius、start_angle、end_angle、角度インデックスiおよび半径インデックスjによって指定される位置の視野についての重み付け値を指定する8.24固定小数点フォーマットである。local_fov_weightの正の値は、視野の拡大を指定するが、その一方で負の値は、視野の縮小を指定する。
[0070]num_polynomial_coefficeients_lscは、レンズシェーディング曲線(the lens shading curve)の多項式近似の次数(the order)であるべきである。
[0071]polynomial_coefficient_K_lsc_R、polynomial_coefficient_K_lsc_G、およびpolynomial_coefficient_K_lsc_Bは、半径方向に沿って色を低減するシェーディングアーティファクト(the shading artifact)を補償するために、LSCパラメータを指定する8.24固定小数点フォーマットである。当初の色に乗算されるべき補償重み(w)は、多項式を使用して画像中心からの半径の曲線関数(curve function)として近似される。それは、
として定式化され、ここで、pは、polynomial_coefficient_K_lsc_R、polynomial_coefficient_K_lsc_Gまたはpolynomial_coefficient_K_lsc_Bに等しい係数値を示し、rは、full_radiusによる正規化後の半径値を示す。Nは、num_polynomial_coefficeients_lscの値に等しい。
[0072]num_deadzonesは、このボックスが適用される各サンプルのコーディングされたピクチャ中の死角(dead zones)の数を指定する整数である。
[0073]deadzone_left_horizontal_offset、deadzone_top_vertical_offset、deadzone_width、およびdeadzone_heightは、ピクセルが使用可能でない死角の長方形エリアの位置およびサイズを指定する整数値である。deadzone_left_horizontal_offsetおよびdeadzone_top_vertical_offsetは、コーディングされたピクチャ中の死角の左上隅の水平座標および垂直座標をそれぞれルーマサンプルで指定する。deadzone_widthおよびdeadzone_heightは、死角の幅および高さをそれぞれルーマサンプルで指定する。ビデオを表すためのビットを節約するために、死角内の全てのピクセルは、同じピクセル値、例えば、全て黒、に設定されるべきである。
[0074]図3~8は、上記のシンタックスおよびセマンティクスの様々な態様を例示する概念図である。図3は、image_center_xおよびimage_center_yシンタックスを中心302として、full_radiusシンタックスを全半径304として、picture_radiusをフレーム300のフレーム半径306として、scene_radiusをシーン半径308(例えば、カメラ本体510からの障害物がないエリア)として例示している。図4は、2つの魚眼画像についてのdisplayed_fov(すなわち、表示された視野(FOV:field of view))を例示している。FOV402は、170度の視野を表し、およびFOV404は、190度の視野を表す。図5は、複数の(例えば、N>2)魚眼画像についてのdisplayed_fov(すなわち、表示された視野(FOV))およびoverlapped_fovを例示している。FOV502は、第1の視野を表し、およびFOV504は、第2の視野を表す。図6は、camera_center_offset_x(ox)、camera_center_offset_y(oy)、およびcamera_center_offset_z(oz)シンタックスの例示である。図7は、ローカル視野に関するパラメータを例示する概念図である。図8は、ローカル視野の例を例示する概念図である。
[0075]OMAF DISの現在の草案中の魚眼ビデオのシグナリングは、1つまたは複数の不利な点を提示し得る。
[0076]OMAF DISの現在の草案中の魚眼ビデオのシグナリングの1つの実例的な不利な点として、各魚眼ビデオピクチャ中に2つの円形画像が存在するとき(例えば、FisheyeOmnidirectionalVideoInfo( )シンタックス構造中のnum_circular_imagesが2に等しい場合)、カメラ外部パラメータ(例えば、camera_center_yaw、camera_center_pitch、camera_center_roll、camera_center_offset_x、camera_center_offset_y、およびcamera_center_offset_z)の値に依存して、魚眼ビデオは、モノスコープまたはステレオスコープのいずれかであることができる。特に、2つの円形画像をキャプチャする2つのカメラが同じ側上にあるとき、魚眼ビデオは、球のほぼ半分(すなわち、水平に180度)をカバーするステレオスコープであり、および2つのカメラが互いに反対側(opposite sides)にあるとき、魚眼ビデオは、モノスコープであるが、ほぼ球全体(すなわち、水平に360度)をカバーする。例えば、カメラ外部パラメータ値の2つのセットが次の通りであるとき、魚眼ビデオは、モノスコープである:
第1のセット(1st set):
camera_center_yaw = 0 degrees (+/- 5 degrees)
camera center_pitch = 0 degrees (+/- 5 degrees)
camera center roll = 0 degrees (+/- 5 degrees)
camera_center_offset_x = 0 mm (+/- 3 mm)
camera_center_offset_y = 0 mm (+/- 3 mm)
camera_center_offset_z = 0 mm (+/- 3 mm)
第2のセット(2nd set):
camera_center_yaw = 180 degrees (+/- 5 degrees)
camera center_pitch = 0 degrees (+/- 5 degrees)
camera center roll = 0 degrees (+/- 5 degrees)
camera_center_offset_x = 0 mm (+/- 3 mm)
camera_center_offset_y = 0 mm (+/- 3 mm)
camera_center_offset_z = 0 mm (+/- 3 mm)
[0077]上記のパラメータ値は、図1Bのコンピューティングデバイス10Bのカメラ外部パラメータ値に対応し得る。別の例として、カメラ外部パラメータ値の2つのセットが次の通りであるとき、魚眼ビデオは、ステレオスコープである:
第1のセット(1st set):
camera_center_yaw = 0 degrees (+/- 5 degrees)
camera center_pitch = 0 degrees (+/- 5 degrees)
camera center roll = 0 degrees (+/- 5 degrees)
camera_center_offset_x = 0 mm (+/- 3 mm)
camera_center_offset_y = 0 mm (+/- 3 mm)
camera_center_offset_z = 0 mm (+/- 3 mm)
第2のセット(2nd set):
camera_center_yaw = 0 degrees (+/- 5 degrees)
camera center_pitch = 0 degrees (+/- 5 degrees)
camera center roll = 0 degrees (+/- 5 degrees)
camera_center_offset_x = 64 mm (+/- 3 mm)
camera_center_offset_y = 0 mm (+/- 3 mm)
camera_center_offset_z = 0 mm (+/- 3 mm)
[0078]上記のパラメータ値は、図1Aのコンピューティングデバイス10Aのカメラ外部パラメータ値に対応し得る。64mmのステレオオフセットX距離が2.5インチに同等であり、それは、人間の目の間の平均距離であることに留意されたい。
[0079]言い換えれば、魚眼ビデオがモノスコープであるかまたはステレオスコープであるかに関する情報は、隠されている(すなわち、暗示的にはコーディングされるが、明示的にはコーディングされない)。しかしながら、コンテンツ選択のような高レベルシステムの目的の場合、(例えば、コンテンツ選択関数を実行するエンティティが、対応するビデオデータがモノスコープであるかまたはステレオスコープであるかを決定するために、FisheyeOmnidirectionalVideoInfo( )シンタックス構造中の多くの情報を構文解析する必要がないように)この情報がファイルフォーマットレベルとDASHレベルとの両方で容易にアクセス可能であることが望まれ得る。
[0080]OMAF DISの現在の草案中の魚眼ビデオのシグナリングの別の実例的な不利な点として、各魚眼ビデオピクチャ中に2つの円形画像が存在し(例えば、FisheyeOmnidirectionalVideoInfo( )シンタックス構造中のnum_circular_imagesが2に等しい場合)、および魚眼ビデオがステレオスコープであるとき、クライアントデバイスは、2つの円形画像のうちのどちらが左目のビューであり、およびどちらが右目のビューであるかをカメラ外部パラメータから決定し得る。しかしながら、クライアントデバイスが、どちらの画像が左目のビューであり、およびどちらが右目のビューであるかをカメラ外部パラメータから決定しなければならないことは、望ましくないことがあり得る。
[0081]OMAF DISの現在の草案中の魚眼ビデオのシグナリングの別の実例的な不利な点として、各側上に2つずつ、魚眼ビデオをキャプチャするための4つの魚眼カメラが存在するとき、魚眼ビデオは、球全体をカバーするステレオスコープとなるであろう。このケースでは、各魚眼ビデオピクチャ中に4つの円形画像が存在する(例えば、FisheyeOmnidirectionalVideoInfo( )シンタックス構造中のnum_circular_imagesは、4に等しい)。そのようなケースでは(各魚眼ビデオピクチャ中に2つより多くの円形画像が存在するとき)、クライアントデバイスは、同じビューに属するある特定の2つの円形画像のペアリングをカメラ外部パラメータから決定し得る。しかしながら、クライアントデバイスが、同じビューに属するある特定の2つの円形画像のペアリングをカメラ外部パラメータから決定しなければならないことは、望ましくないことがあり得る。
[0082]OMAF DISの現在の草案中の魚眼ビデオのシグナリングの別の実例的な不利な点として、投影される全方位ビデオのために、カバレッジ情報(例えば、球上のどのエリアがビデオによってカバーされるか)は、CoverageInformationBoxを使用して明示的にシグナリングされるか、または、存在しないときは、全球となるようにクライアントデバイスによって推論されるかのいずれかである。クライアントデバイスは、カメラ外部パラメータからカバレッジを決定し得るが、ここでも、この情報が容易にアクセス可能となるように明示的にシグナリングすることが望まれ得る。
[0083]OMAF DISの現在の草案中の魚眼ビデオのシグナリングの別の実例的な不利な点として、リージョンワイズパッキングの使用は、投影される全方位ビデオに対しては許容されるが、魚眼ビデオに対しては許容されない。しかしながら、投影される全方位ビデオに適用可能であるリージョンワイズパッキングのいくつかの利益はまた、魚眼ビデオにも適用可能であり得る。
[0084]OMAF DISの現在の草案中の魚眼ビデオのシグナリングの別の実例的な不利な点として、サブピクチャトラック中での投影される全方位ビデオの搬送は、コンポジショントラックグルーピング(the composition track grouping)を使用することによって、OMAF DIS中に規定されている。しかしながら、サブピクチャトラック中での魚眼全方位ビデオの伝達は、サポートされていない。
[0085]この開示は、上記の問題に対するソリューションを提示する。これらの技法のうちのいくつかは、独立して適用され得、およびそれらのうちのいくつかは、組み合わせて適用され得る。
[0086]この開示の1つまたは複数の技法にしたがって、魚眼ビデオデータを含むファイルは、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかの明示的なインジケーションを含み得る。言い換えれば、魚眼ビデオがモノスコープであるかまたはステレオスコープであるかのインジケーションは、明示的にシグナリングされ得る。このように、クライアントデバイスは、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを他のパラメータから推論しなければならないことを避け得る。
[0087]一例として、FisheyeOmnidirectionalVideoInfo( )シンタックス構造中の最初の24ビットのうちの1つまたは複数は、モノスコープまたはステレオスコープのインジケーションをシグナリングするためのフィールド(例えば、1ビットフラグ)を形成するために使用され得る。第1の特定の値(例えば、0)に等しいフィールドは、魚眼ビデオがモノスコープであることを示し得、および第2の特定の値(例えば、1)に等しいフィールドは、魚眼ビデオがステレオスコープであることを示し得る。例えば、魚眼ビデオデータを含むファイルを生成するとき、コンテンツ準備デバイス(例えば、図9のコンテンツ準備デバイス20、および特定の例では、コンテンツ準備デバイス20のカプセル化ユニット30)は、ファイル内にボックス(例えば、FisheyeOmnidirectionalVideoBox)を符号化し得、ボックスは、魚眼ビデオデータについてのパラメータを包含するシンタックス構造(例えば、FisheyeOmnidirectionalVideoInfo( ))を含み、およびシンタックス構造は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかの明示的なインジケーションを含む。クライアントデバイス(例えば、図9のクライアントデバイス40、および特定の例では、クライアントデバイス40の取り出しユニット52)は、モノスコープまたはステレオスコープの明示的なインジケーションを取得するために、ファイルを同様に処理し得る。
[0088]別の例として、フィールド、例えば、1ビットフラグ、いくつかのリザーブされたビット、およびことによると何らかの他の情報を包含する新しいボックスは、モノスコープまたはステレオスコープのインジケーションをシグナリングするために、FisheyeOmnidirectionalVideoBoxに追加され得る。第1の特定の値(例えば、0)に等しいフィールドは、魚眼ビデオがモノスコープであることを示し得、および第2の特定の値(例えば、1)に等しいフィールドは、魚眼ビデオがステレオスコープであることを示し得る。例えば、魚眼ビデオデータを含むファイルを生成するとき、コンテンツ準備デバイス(例えば、図9のコンテンツ準備デバイス20)は、ファイル内に第1のボックス(例えば、FisheyeOmnidirectionalVideoBox)を符号化し得、第1のボックスは、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示すフィールドを含む第2のボックスを含む。クライアントデバイス(例えば、図9のクライアントデバイス40)は、モノスコープまたはステレオスコープの明示的なインジケーションを取得するために、ファイルを同様に処理し得る。
[0089]別の例として、フィールド(例えば、1ビットフラグ)は、このインジケーションをシグナリングするために、FisheyeOmnidirectionalVideoBoxに直接追加され得る。例えば、魚眼ビデオデータを含むファイルを生成するとき、コンテンツ準備デバイス(例えば、図9のコンテンツ準備デバイス20)は、ファイル内にボックス(例えば、FisheyeOmnidirectionalVideoBox)を符号化し得、ボックスは、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示すフィールドを含む。クライアントデバイス(例えば、図9のクライアントデバイス40)は、モノスコープまたはステレオスコープの明示的なインジケーションを取得するために、ファイルを同様に処理し得る。
[0090]この開示の1つまたは複数の技法にしたがって、複数の円形画像としての魚眼ビデオデータを含むファイルは、複数の円形画像のそれぞれの円形画像ごとに、それぞれのビュー識別情報(ビューID:view identification)の明示的なインジケーションを含み得る。言い換えれば、魚眼ビデオデータの各円形画像について、各円形画像のビューIDを示すフィールドが追加され得る。2つのビューID値0および1のみが存在するとき、0に等しいビューIDを有するビューは、左のビューであり得、および1に等しいビューIDを有するビューは、右のビューであり得る。例えば、複数の円形画像が2つの円形画像のみを含む場合、第1の予め定められたビデオ識別情報を有する、複数の円形画像のうちの1つの円形画像は、左のビューであり、第2の予め定められたビデオ識別情報を有する、複数の円形画像のうちの1つの円形画像は、右のビューである。このように、クライアントデバイスは、どちらの円形画像が左のビューであり、およびどちらが右のビューであるかを他のパラメータから推論しなければならないことを避け得る。
[0091]シグナリングされるビューIDはまた、同じビューに属する任意の2つの円形画像のペアリング関係を示すために使用されることができる(例えば、それらは両方とも、同じ値のシグナリングされるビューIDを有し得るため)。
[0092]円形画像についての全ての魚眼ビデオパラメータを構文解析する必要なしにビューIDが容易にアクセスされることを可能にするために、num_circular_imagesフィールドの後に、および既存のループの前に、ループが追加され得る。例えば、ファイルを処理することは、ビュー識別情報の明示的インジケーションを第1のループ中で構文解析することと、円形画像の他のパラメータを第1のループの後にある第2のループ中で構文解析することと、を含み得る。例えば、ビューIDおよび他のパラメータは、次の通りに構文解析され得る:
aligned(8) class FisheyeOmnidirectionalVideoInfo( ) {
bit(24) reserved = 0;
unsigned int(8) num_circular_images;
for(i=0; i< num_circular_images; i++) {
unsigned int(8) view_id;
bit(24) reserved = 0;
}
for(i=0; i< num_circular_images; i++) {
unsigned int(32) image_center_x;
unsigned int(32) image_center_y;
…
}
}
[0093]view_idは、円形画像が属するビューのビュー識別子を示す。全ての円形画像について2つの値のview_id 0および1のみが存在するとき、0に等しいview_idを有する円形画像は、左のビューに属し得、および1に等しいview_idを有する円形画像は、右のビューに属し得る。いくつかの例では、ビュー識別子を示すシンタックス要素(1つ以上)(すなわち、どちらの円形画像が左のビューであり、およびどちらが右のビューであるかを示すシンタックス要素)は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示すシンタックス要素と同じであり得る。
[0094]この開示の1つまたは複数の技法にしたがって、魚眼ビデオデータを含むファイルは、魚眼ビデオデータについてのパラメータを包含するシンタックス構造を含む第1のボックスを含み得、および魚眼ビデオデータについてのカバレッジ情報を示す第2のボックスをオプションとして含み得る。例えば、魚眼全方位ビデオについてのカバレッジ情報のシグナリングは、FisheyeOmnidirectionalVideoBoxに追加され得る。例えば、OMAF DIS中に定義されているようなCoverageInformationBoxは、FisheyeOmnidirectionalVideoBox中にオプションとして包含されることを許容され得、およびそれがFisheyeOmnidirectionalVideoBox中に存在しないときは、全球カバレッジが、魚眼ビデオについて推論され得る。CoverageInformationBoxがFisheyeOmnidirectionalVideoBox中に存在するとき、魚眼ビデオピクチャによって表される球面領域は、2つのヨー円(yaw circles)および2つのピッチ円(pitch circles)によって指定された領域であり得る。このように、クライアントデバイスは、他のパラメータからカバレッジ情報を推論しなければならないことを避け得る。
[0095]この開示の1つまたは複数の技法にしたがって、魚眼ビデオデータを含むファイルは、スキーム情報を含む第1のボックスを含み得、第1のボックスは、魚眼ビデオデータについてのパラメータを包含するシンタックス構造を含む第2のボックスを含み得、および第1のボックスは、魚眼ビデオデータのピクチャがリージョンワイズパッキングされているかどうかを示す第3のボックスをオプションとして含み得る。例えば、RegionWisePackingBoxは、魚眼全方位ビデオのためにSchemeInformationBox中にオプションとして含まれ得る(例えば、FisheyeOmnidirectionalVideoBoxがSchemeInformationBox中に存在するとき、RegionWisePackingBoxは、同じSchemeInformationBox中に存在することができる)。このケースでは、RegionWisePackingBoxの存在は、魚眼ビデオピクチャがリージョンワイズパッキングされており、およびレンダリングより前にアンパッキングを必要とすることを示す。このように、リージョンワイズパッキングの1つまたは複数の利益が、魚眼ビデオのために得られ得る。
[0096]この開示の1つまたは複数の技法にしたがって、サブピクチャコンポジション(sub-picture composition)が、魚眼全方位ビデオのためにグループ化に使用され得、およびサブピクチャコンポジショングルーピング(the sub-picture composition grouping)の適用に関する仕様が、魚眼全方位ビデオに追加され得る。その仕様は、サブピクチャコンポジショントラックグループにマッピングされるトラックのうちの任意のものが、サンプルエントリ中に含まれるSchemeTypeBox中に「fodv」に等しいscheme_type、「resv」に等しいサンプルエントリタイプを有するときに適用され得る。このケースでは、各コンポーズされたピクチャ(composed picture)は、任意のFisheyeOmnidirectionalVideoBoxによって示された魚眼フォーマットと、サブピクチャコンポジショントラックグループにマッピングされるトラックのサンプルエントリ中に含まれた任意のRegionWisePackingBoxによって示されたリージョンワイズパッキングフォーマットとを有するパッキングされたピクチャである。加えて、以下が適用され得る:
[0097]1)このグルーピングにマッピングされる各トラックは、「resv」に等しいサンプルエントリタイプを有するべきである。scheme_typeは、サンプルエントリ中に含まれるSchemeTypeBox中の「fodv」に等しくあるべきである。
[0098]2)同じサブピクチャコンポジショントラックグループにマッピングされるトラックのサンプルエントリ中に含まれるFisheyeOmnidirectionalVideoBoxの全てのインスタンスのコンテンツは、同一であるべきである。
[0099]3)同じサブピクチャコンポジショントラックグループにマッピングされるトラックのサンプルエントリ中に含まれるRegionWisePackingBoxの全てのインスタンスのコンテンツは、同一であるべきである。
[0100]HTTPストリーミングでは、頻繁に使用される動作は、HEAD、GET、および部分的GETを含む。HEAD動作は、所与のユニフォームリソースロケータ(URL)またはユニフォームリソース名(URN)に関連付けられたファイルのヘッダを、そのURLまたはURNに関連付けられたペイロードを取り出すことなしに、取り出す。GET動作は、所与のURLまたはURNに関連付けられたファイル全体を取り出す。部分的GET動作は、入力パラメータとしてバイト範囲を受信し、およびファイルの連続数のバイトを取り出し、ここで、バイトの数は、受信されるバイト範囲に対応する。このことから、ムービーフラグメントは、部分的GET動作が1つまたは複数の個々のムービーフラグメントを得ることができることから、HTTPストリーミングのために提供され得る。ムービーフラグメントでは、異なるトラックのいくつかのトラックフラグメントが存在することができる。HTTPストリーミングでは、メディアプレゼンテーション(a media presentation)は、クライアントにとってアクセス可能であるデータの構造化された集合であり得る。クライアントは、ユーザにストリーミングサービスを提示するために、メディアデータ情報を要求およびダウンロードし得る。
[0101]HTTPストリーミングを使用して3GPPデータをストリーミングする例では、マルチメディアコンテンツのビデオおよび/またはオーディオデータについての複数のリプレゼンテーションが存在し得る。以下に説明されるように、異なるリプレゼンテーションは、異なるコーディング特性(例えば、ビデオコーディング規格の異なるプロファイルまたはレベル)、異なるコーディング規格または(マルチビューおよび/またはスケーラブル拡張のような)コーディング規格の拡張、あるいは異なるビットレートに対応し得る。そのようなリプレゼンテーションのマニフェストは、メディアプレゼンテーション記述(MPD:Media Presentation Description)データ構造で定義され得る。メディアプレゼンテーションは、HTTPストリーミングクライアントデバイスにとってアクセス可能であるデータの構造化された集合に対応し得る。HTTPストリーミングクライアントデバイスは、クライアントデバイスのユーザにストリーミングサービスを提示するために、メディアデータ情報を要求およびダウンロードし得る。メディアプレゼンテーションは、MPDデータ構造で記述され得、それは、MPDの更新を含み得る。
[0102]メディアプレゼンテーションは、1つまたは複数の期間(Period)のシーケンスを包含し得る。各期間は、次の期間の開始まで、また最後の期間のケースではメディアプレゼンテーションの終了まで拡張し得る。各期間は、同じメディアコンテンツについての1つまたは複数のリプレゼンテーションを包含し得る。リプレゼンテーションは、オーディオ、ビデオ、時間指定されたテキスト、または他のそのようなデータのいくつかの代替の符号化されたバージョンのうちの1つであり得る。リプレゼンテーションは、符号化タイプによって、例えば、ビデオデータについてのビットレート、解像度、および/またはコーデックと、オーディオデータについてのビットレート、言語、および/またはコーデックとによって異なり得る。リプレゼンテーションという用語は、マルチメディアコンテンツの特定の期間に対応し、且つ特定の方法で符号化された、符号化されたオーディオまたはビデオデータのセクションを指すために使用され得る。
[0103]特定の期間のリプレゼンテーションは、リプレゼンテーションが属する適合セット(an adaptation set)を示すMPD中の属性によって示されるグループに割り当てられ得る。同じ適合セット中のリプレゼンテーションは概して、クライアントデバイスが、例えば、帯域幅適合を実行するためにこれらのリプレゼンテーション間を動的およびシームレスに切り替えることができるという点において、互いに対して代替であると考えられる。例えば、特定の期間についてのビデオデータの各リプレゼンテーションは、同じ適合セットに割り当てられ得、それにより、リプレゼンテーションのうちの任意のものが、対応する期間についてのマルチメディアコンテンツの、ビデオデータまたはオーディオデータのようなメディアデータを提示するための復号のために選択され得る。1つの期間内のメディアコンテンツは、存在する場合には、グループ0からの1つのリプレゼンテーションか、またはいくつかの例では、各非ゼログループからの多くとも1つのリプレゼンテーションの組み合わせ、のいずれかによって表され得る。ある期間の各リプレゼンテーションについてのタイミングデータは、その期間の開始時間に相対的に表され得る。
[0104]リプレゼンテーションは、1つまたは複数のセグメントを含み得る。各リプレゼンテーションは、初期化セグメントを含み得る、またはリプレゼンテーションの各セグメントは、自己初期化し得る。存在するとき、初期化セグメントは、リプレゼンテーションにアクセスするための初期化情報を包含し得る。一般に、初期化セグメントは、メディアデータを包含しない。セグメントは、ユニフォームリソースロケータ(URL)、ユニフォームリソース名(URN)、またはユニフォームリソース識別子(URI)のような識別子によって一意に参照され得る。MPDは、各セグメントについての識別子を提供し得る。いくつかの例では、MPDはまた、範囲属性の形態でバイト範囲を提供し得、それは、URL、URN、またはURIによってアクセス可能であるファイル内のセグメントについてのデータに対応し得る。
[0105]異なるリプレゼンテーションは、異なるタイプのメディアデータについての実質的に同時の取り出しのために選択され得る。例えば、クライアントデバイスは、それらからセグメントを取り出すためのオーディオリプレゼンテーション、ビデオリプレゼンテーション、および時間指定されたテキストリプレゼンテーションを選択し得る。いくつかの例では、クライアントデバイスは、帯域幅適合を実行するための特定の適合セットを選択し得る。すなわち、クライアントデバイスは、ビデオリプレゼンテーションを含む適合セット、オーディオリプレゼンテーションを含む適合セット、および/または時間指定されたテキストを含む適合セットを選択し得る。代替として、クライアントデバイスは、ある特定のタイプのメディア(例えば、ビデオ)についての適合セットを選択し、および他のタイプのメディア(例えば、オーディオおよび/または時間指定されたテキスト)についてのリプレゼンテーションを直接選択し得る。
[0106]図9は、ネットワークを通してメディアデータをストリーミングするための技法をインプリメントする実例的なシステム10を例示するブロック図である。この例では、システム10は、コンテンツ準備デバイス20、サーバデバイス60、およびクライアントデバイス40を含む。クライアントデバイス40およびサーバデバイス60は、ネットワーク74によって通信可能に結合され、それは、インターネットを備え得る。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60もまた、ネットワーク74または別のネットワークによって結合され得るか、あるいは直接通信可能に結合され得る。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60は、同じデバイスを備え得る。
[0107]図9の例におけるコンテンツ準備デバイス20は、オーディオソース22およびビデオソース24を備える。オーディオソース22は、例えば、オーディオ符号化器26によって符号化されることになるキャプチャされたオーディオデータを表す電気信号を生じさせるマイクロフォンを備え得る。代替として、オーディオソース22は、以前に記録されたオーディオデータを記憶する記憶媒体、コンピュータ化されたシンセサイザのようなオーディオデータ生成器、またはオーディオデータの任意の他のソースを備え得る。ビデオソース24は、ビデオ符号化器28によって符号化されることになるビデオデータを生じさせるビデオカメラ、以前に記録されたビデオデータで符号化された記憶媒体、コンピュータグラフィックスソースのようなビデオデータ生成ユニット、またはビデオデータの任意の他のソースを備え得る。コンテンツ準備デバイス20は、必ずしも全ての例においてサーバデバイス60に通信可能に結合されるわけではなく、サーバデバイス60によって読み取られる別個の媒体にマルチメディアコンテンツを記憶し得る。
[0108]生オーディオおよびビデオデータは、アナログまたはデジタルデータを備え得る。アナログデータは、オーディオ符号化器26および/またはビデオ符号化器28によって符号化される前にデジタル化され得る。オーディオソース22は、話す参加者から、その話す参加者が話している間にオーディオデータを取得し得、およびビデオソース24は、その話す参加者のビデオデータを同時に取得し得る。他の例では、オーディオソース22は、記憶されたオーディオデータを備えるコンピュータ可読記憶媒体を備え得、およびビデオソース24は、記憶されたビデオデータを備えるコンピュータ可読記憶媒体を備え得る。このように、この開示に説明される技法は、ライブの、ストリーミングの、リアルタイムのオーディオおよびビデオデータに、またはアーカイブされ、事前に記録されたオーディオおよびビデオデータに適用され得る。
[0109]ビデオフレームに対応するオーディオフレームは概して、ビデオフレーム内に包含される、ビデオソース24によってキャプチャされた(または生成された)ビデオデータと同時にオーディオソース22によってキャプチャされた(または生成された)オーディオデータを包含するオーディオフレームである。例えば、話す参加者が概して話すことによってオーディオデータを生じさせる間、オーディオソース22は、オーディオデータをキャプチャし、およびビデオソース24は、同時に、すなわち、オーディオソース22がオーディオデータをキャプチャしている間に、話す参加者のビデオデータをキャプチャする。故に、オーディオフレームは、1つまたは複数の特定のビデオフレームに時間的に対応し得る。それ故に、ビデオフレームに対応するオーディオフレームは概して、オーディオデータとビデオデータとが同時にキャプチャされた状況に対応し、およびそれについて、オーディオフレームとビデオフレームとは、同時にキャプチャされたオーディオデータとビデオデータとをそれぞれ備える。
[0110]いくつかの例では、オーディオ符号化器26は、符号化されたオーディオフレームについてのオーディオデータが記録された時間を表す各符号化されたオーディオフレーム中のタイムスタンプを符号化し得、および同様に、ビデオ符号化器28は、符号化されたビデオフレームについてのビデオデータが記録された時間を表す各符号化されたビデオフレーム中のタイムスタンプを符号化し得る。そのような例では、ビデオフレームに対応するオーディオフレームは、タイムスタンプを備えるオーディオフレームと、同じタイムスタンプを備えるビデオフレームとを備え得る。コンテンツ準備デバイス20は、オーディオ符号化器26および/またはビデオ符号化器28がそれからタイムスタンプを生成し得る、あるいは、オーディオソース22とビデオソース24とが、オーディオデータとビデオデータとをそれぞれタイムスタンプに関連付けるために使用し得る、内部クロックを含み得る。
[0111]いくつかの例では、オーディオソース22は、オーディオデータが記録された時間に対応するデータをオーディオ符号化器26に送り得、およびビデオソース24は、ビデオデータが記録された時間に対応するデータをビデオ符号化器28に送り得る。いくつかの例では、オーディオ符号化器26は、符号化されたオーディオデータの相対時間的順序(a relative temporal ordering)を示すために、しかしオーディオデータが記録された絶対時間を必ずしも示すことなしに、符号化されたオーディオデータ中のシーケンス識別子を符号化し得、および同様に、ビデオ符号化器28もまた、符号化されたビデオデータの相対時間的順序を示すために、シーケンス識別子を使用し得る。同様に、いくつかの例では、シーケンス識別子は、マッピングされ得るか、またはそうでない場合は、タイムスタンプと相関され得る。
[0112]オーディオ符号化器26は概して、符号化されたオーディオデータのストリームを生じさせ、その一方でビデオ符号化器28は、符号化されたビデオデータのストリームを生じさせる。(オーディオであれビデオであれ)データの各個々のストリームは、エレメンタリストリームと呼ばれ得る。エレメンタリストリームは、リプレゼンテーションの単一のデジタルにコーディングされた(ことによると圧縮された)コンポーネントである。例えば、リプレゼンテーションのコーディングされたビデオまたはオーディオ部分は、エレメンタリストリームであることができる。エレメンタリストリームは、ビデオファイル内にカプセル化される前に、パケット化されたエレメンタリストリーム(PES)へと変換され得る。同じリプレゼンテーション内で、ストリームIDは、ある1つのエレメンタリストリームに属するPESパケットを他のものと区別するために使用され得る。エレメンタリストリームのデータの基本単位は、パケット化されたエレメンタリストリーム(PES)パケットである。このことから、コーディングされたビデオデータは概して、エレメンタリビデオストリームに対応する。同様に、オーディオデータは、1つまたは複数のそれぞれのエレメンタリストリームに対応する。
[0113]ITU H.264/AVCおよび高効率ビデオコーディング(HEVC)規格のような多くのビデオコーディング規格は、誤りのないビットストリームのためのシンタックス、セマンティクス、および復号処理を定義し、それらのうちのいずれも、ある特定のプロファイルまたはレベルに準拠する。ビデオコーディング規格は典型的に、符号化器を指定しないが、符号化器は、生成されるビットストリームが復号器に対して規格準拠(standard-compliant)であることを保証するタスクを課される。ビデオコーディング規格のコンテキストでは、「プロファイル」は、アルゴリズム、機能(features,)、またはツールのサブセット、およびそれらに適用される制約に対応する。H.264規格によって定義されているように、例えば、「プロファイル」は、H.264規格によって指定されているビットストリームシンタックス全体のサブセットである。「レベル」は、例えば、復号器メモリおよび消費のような復号器リソース消費の制限に対応し、それらは、ピクチャの解像度、ビットレート、およびブロック処理レートに関連する。プロファイルは、profile_idc(プロファイルインジケータ)値でシグナリングされ得、その一方でレベルは、level_idc(レベルインジケータ)値でシグナリングされ得る。
[0114]H.264規格は、例えば、所与のプロファイルのシンタックスによって課せられる限度(the bounds)内で、復号されたピクチャの指定されたサイズのような、ビットストリーム中のシンタックス要素によって取られる値に依存して、符号化器と復号器との性能において大きな変動を要求することは依然として可能であることを認識している。H.264規格はさらに、多くのアプリケーションで、特定のプロファル内のシンタックスの全ての仮定的な使用に対処することが可能である復号器をインプリメントすることは実用的でも経済的でもないことを認識している。それ故に、H.264規格は、ビットストリーム中のシンタックス要素の値に対して課せられる制約の指定されたセットとして「レベル」を定義する。これらの制約は、値に対する単純な制限であり得る。代替として、これらの制約は、値の算術的組み合わせ(例えば、ピクチャ幅にピクチャの高さを乗算したものに、毎秒復号されるピクチャの数を乗算したもの)に対する制約の形態を取り得る。H.264規格はさらに、個々のインプリメンテーションが各サポートされるプロファイルについて異なるレベルをサポートし得ることを規定する。
[0115]プロファイルに準拠する復号器は通常、プロファイル中に定義された全ての機能をサポートする。例えば、コーディング機能として、Bピクチャコーディングは、H.264/AVCのベースラインプロファイル中でサポートされていないが、H.264/AVCの他のプロファイル中でサポートされている。あるレベルに準拠する復号器は、そのレベル中で定義された制限を超えるリソースを必要としないあらゆるビットストリームを復号することが可能であるべきである。プロファイルおよびレベルの定義は、解釈可能性(interpretability)に役に立ち得る。例えば、ビデオ送信中に、プロファイルおよびレベル定義のペアが、送信セッション全体についてネゴシエートおよび同意され得る。より具体的には、H.264/AVCでは、レベルは、処理される必要があるマクロブロックの数、復号ピクチャバッファ(DPB)サイズ、コーディングピクチャバッファ(CPB)サイズ、垂直動きベクトル範囲、2つの連続するMBあたりの動きベクトルの最大数、およびBブロックが8x8ピクセル未満のサブマクロブロック区分を有することができるかどうか、に対する制限を定義し得る。このように、復号器は、復号器がビットストリームを適正に復号することが可能であるかどうかを決定し得る。
[0116]図9の例では、コンテンツ準備デバイス20のカプセル化ユニット30は、ビデオ符号化器28からのコーディングされたビデオデータを備えるエレメンタリストリームと、オーディオ符号化器26からのコーディングされたオーディオデータを備えるエレメンタリストリームとを受信する。いくつかの例では、ビデオ符号化器28およびオーディオ符号化器26は各々、符号化されたデータからPESパケットを形成するためのパケタイザを含み得る。他の例では、ビデオ符号化器28およびオーディオ符号化器26は各々、符号化されたデータからPESパケットを形成するためのそれぞれのパケタイザとインターフェースし得る。さらに他の例では、カプセル化ユニット30は、符号化されたオーディオおよびビデオデータからPESパケットを形成するためのパケタイザを含み得る。
[0117]ビデオ符号化器28は、ピクセル解像度、フレームレート、様々なコーディング規格への準拠、様々なコーディング規格についての様々なプロファイルおよび/またはプロファイルのレベルへの準拠、(例えば、2次元または3次元再生のための)1つまたは複数のビューを有するリプレゼンテーション、あるいは他のそのような特性のような様々な特性を有する、および様々なビットレートにおける、マルチメディアコンテンツの異なるリプレゼンテーションを生じさせるために、多様な方法でマルチメディアコンテンツのビデオデータを符号化し得る。この開示に使用されているようなリプレゼンテーションは、オーディオデータ、ビデオデータ、(例えば、クローズドキャプションのための)テキストデータ、または他のそのようなデータのうちの1つを備え得る。リプレゼンテーションは、オーディオエレメンタリストリームまたはビデオエレメンタリストリームのようなエレメンタリストリームを含み得る。各PESパケットは、PESパケットが属するエレメンタリストリームを識別するstream_idを含み得る。カプセル化ユニット30は、エレメンタリストリームを様々なリプレゼンテーションのビデオファイル(例えば、セグメント)へとアセンブルすることを担う。
[0118]カプセル化ユニット30は、オーディオ符号化器26およびビデオ符号化器28からリプレゼンテーションのエレメンタリストリームについてのPESパケットを受信し、およびPESパケットから対応するネットワーク抽象化レイヤ(NAL)ユニットを形成する。コーディングされたビデオセグメントは、NALユニットへと編成され得、それは、ビデオ電話通信、記憶、ブロードキャスト、またはストリーミングのようなアプリケーションを扱う「ネットワークフレンドリーな」ビデオリプレゼンテーションを提供する。NALユニットは、ビデオコーディングレイヤ(VCL)NALユニットおよび非VCL NALユニットにカテゴリ化されることができる。VCLユニットは、コア圧縮エンジンを包含し得、ブロック、マクロブロック、および/またはスライスレベルのデータを含み得る。他のNALユニットは、非VCL NALユニットであり得る。いくつかの例では、プライマリのコーディングされたピクチャ(a primary coded picture)として通常提示される1つの時間インスタンス中のコーディングされたピクチャは、アクセスユニット中に包含され得、それは、1つまたは複数のNALユニットを含み得る。
[0119]非VCL NALユニットは、中でもとりわけ、パラメータセットNALユニットおよびSEI NALユニットを含み得る。パラメータセットは、(シーケンスパラメータセット(SPS)中に)シーケンスレベルヘッダ情報、および(ピクチャパラメータセット(PPS)中に)まれに変化するピクチャレベルヘッダ情報を包含し得る。パラメータセット(例えば、PPSおよびSPS)では、まれに変化する情報は、シーケンスまたはピクチャごとに繰り返される必要がなく、故に、コーディング効率が改善され得る。さらに、パラメータセットの使用は、重要なヘッダ情報の帯域外送信を可能にし得、誤り耐性のための冗長送信の必要性を避ける。帯域外送信の例では、パラメータセットNALユニットは、SEI NALユニットのような他のNALユニットとは異なるチャネル上で送信され得る。
[0120]補足エンハンスメント情報(SEI:Supplemental Enhancement Information)は、VCL NALユニットからのコーディングされたピクチャサンプルを復号するために必要ではない情報を包含し得るが、復号、表示、誤り耐性、および他の目的に関連したプロセスを支援し得る。SEIメッセージは、非VCL NALユニット中に包含され得る。SEIメッセージは、いくつかの規格仕様書(standard specifications)の規範的部分であり、およびこのことから、規格準拠の復号器インプリメンテーションのために常に必須なわけではない。SEIメッセージは、シーケンスレベルSEIメッセージまたはピクチャレベルSEIメッセージであり得る。何らかのシーケンスレベル情報が、SVCの例におけるスケーラビリティ情報SEIメッセージ、およびMVC中でのビュースケーラビリティ情報SEIメッセージのようなSEIメッセージ中に包含され得る。これらの実例的なSEIメッセージは、例えば、動作点の抽出および動作点の特性に関する情報を伝達し得る。加えて、カプセル化ユニット30は、リプレゼンテーションの特性を記述するメディアプレゼンテーション記述子(MPD:a media presentation descriptor)のようなマニフェストファイルを形成し得る。カプセル化ユニット30は、拡張可能マークアップ言語(XML)にしたがってMPDをフォーマットし得る。
[0121]カプセル化ユニット30は、出力インターフェース32に、マニフェストファイル(例えば、MPD)とともに、マルチメディアコンテンツの1つまたは複数のリプレゼンテーションについてのデータを提供し得る。出力インターフェース32は、ユニバーサルシリアルバス(USB)インターフェース、CDまたはDVDライタまたはバーナ、磁気またはフラッシュ記憶媒体に対するインターフェース、あるいは媒体データを記憶または送信するための他のインターフェースのような、記憶媒体に書き込むためのインターフェースまたはネットワークインターフェースを備え得る。カプセル化ユニット30は、出力インターフェース32にマルチメディアコンテンツのリプレゼンテーションの各々のデータを提供し得、それは、ネットワーク送信または記憶媒体を介してサーバデバイス60にデータを送り得る。図9の例では、サーバデバイス60は、それぞれのマニフェストファイル66と1つまたは複数のリプレゼンテーション68A~68N(リプレゼンテーション68)とを各々が含む様々なマルチメディアコンテンツ64を記憶する記憶媒体62を含む。いくつかの例では、出力インターフェース32はまた、ネットワーク74に直接データを送り得る。
[0122]いくつかの例では、リプレゼンテーション68は、適合セットに分けられ得る。すなわち、リプレゼンテーション68の様々なサブセットは、コーデック、プロファイルおよびレベル、解像度、ビューの数、セグメントのためのファイルフォーマット、復号され、且つ、例えば、スピーカによって提示されるべきオーディオデータおよび/またはリプレゼンテーションとともに表示されるべきテキストの言語または他の特性を識別し得るテキストタイプ情報、適合セット中のリプレゼンテーションについてのシーンの実世界カメラパースペクティブ(real-world camera perspective)またはカメラアングルを記述し得るカメラアングル情報、特定のオーディエンスに対するコンテンツ適性を記述するレーティング情報、または同様のもののような、特性のそれぞれの共通セットを含み得る。
[0123]マニフェストファイル66は、特定の適合セットに対応するリプレゼンテーション68のサブセット、ならびにその適合セットについての共通特性、を示すデータを含み得る。マニフェストファイル66はまた、適合セットの個々のリプレゼンテーションについての、ビットレートのような個々の特性を表すデータを含み得る。このように、適合セットは、簡略化されたネットワーク帯域幅適合を提供し得る。適合セット中のリプレゼンテーションは、マニフェストファイル66の適合セット要素の子要素を使用して示され得る。いくつかの例では、マニフェストファイル66は、ここに論述されたFisheyeOmnidirectionalVideoInfo( )のデータ、あるいは同様のデータ、のうちのいくつかまたは全てを含み得る。加えてまたは代替として、リプレゼンテーション68のセグメントは、ここに論述されたFisheyeOmnidirectionalVideoInfo( )のデータ、あるいは同様のデータ、のうちのいくつかまたは全てを含み得る。
[0124]サーバデバイス60は、要求処理ユニット70とネットワークインターフェース72とを含む。いくつかの例では、サーバデバイス60は、複数のネットワークインターフェースを含み得る。さらに、サーバデバイス60の機能のうちの任意のものまたは全ては、ルータ、ブリッジ、プロキシデバイス、スイッチ、または他のデバイスのような、コンテンツ配信ネットワークの他のデバイス上でインプリメントされ得る。いくつかの例では、コンテンツ配信ネットワークの中間デバイスは、マルチメディアコンテンツ64のデータをキャッシュし得、およびサーバデバイス60のものと実質的に一致するコンポーネントを含み得る。一般に、ネットワークインターフェース72は、ネットワーク74を介してデータを送受信するように構成される。
[0125]要求処理ユニット70は、記憶媒体62のデータを求めるネットワーク要求をクライアントデバイス40のようなクライアントデバイスから受信するように構成される。例えば、要求処理ユニット70は、RFC 2616, “Hypertext Transfer Protocol - HTTP/1.1,” by R. Fielding et al, Network Working Group, IETF, June 1999中に説明されているようなハイパーテキスト転送プロトコル(HTTP)バージョン1.1をインプリメントし得る。すなわち、要求処理ユニット70は、HTTP GETまたは部分的GET要求を受信し、およびそれら要求に応答してマルチメディアコンテンツ64のデータを提供するように構成され得る。それら要求は、例えば、セグメントのURLを使用して、リプレゼンテーション68のうちの1つのセグメントを指定し得る。いくつかの例では、それら要求はまた、セグメントの1つまたは複数のバイト範囲を指定し得、このことから、部分的GET要求を備える。要求処理ユニット70はさらに、リプレゼンテーション68のうちの1つのセグメントのヘッダデータを提供するために、HTTP HEAD要求をサービスするように構成され得る。いずれのケースでも、要求処理ユニット70は、クライアントデバイス40のような要求しているデバイスに要求されたデータを提供するために、それら要求を処理するように構成され得る。
[0126]加えてまたは代替として、要求処理ユニット70は、eMBMSのようなブロードキャストまたはマルチキャストプロトコルを介してメディアデータを配信するように構成され得る。コンテンツ準備デバイス20は、説明されたのと実質的に同じ方法でDASHセグメントおよび/またはサブセグメントを作成し得るが、サーバデバイス60は、eMBMSあるいは別のブロードキャストまたはマルチキャストネットワークトランスポートプロトコルを使用してこれらのセグメントまたはサブセグメントを配信し得る。例えば、要求処理ユニット70は、クライアントデバイス40からマルチキャストグループ参加要求(a multicast group join request)を受信するように構成され得る。すなわち、サーバデバイス60は、特定のメディアコンテンツ(例えば、ライブイベントのブロードキャスト)に関連付けられた、クライアントデバイス40を含むクライアントデバイスに、マルチキャストグループに関連付けられたインターネットプロトコル(IP)アドレスをアドバタイズし得る。クライアントデバイス40は次に、マルチキャストグループに加わるための要求をサブミットし得る。この要求は、ネットワーク74、例えば、ネットワーク74を構成するルータ、全体を通じて伝搬され得、それにより、それらルータは、クライアントデバイス40のような加入しているクライアントデバイスに、マルチキャストグループに関連付けられたIPアドレスに宛てられたトラフィックを向けさせられる(caused to direct)。
[0127]図9の例において例示されているように、マルチメディアコンテンツ64は、マニフェストファイル66を含み、それは、メディアプレゼンテーション記述(MPD)に対応し得る。マニフェストファイル66は、異なる代替のリプレゼンテーション68の記述を包含し得(例えば、異なる品質を有するビデオサービス)、および記述は、例えば、コーデック情報、プロファイル値、レベル値、ビットレート、およびリプレゼンテーション68の他の記述的特性を含み得る。クライアントデバイス40は、リプレゼンテーション68のセグメントにどのようにアクセスするかを決定するために、メディアプレゼンテーションのMPDを取り出し得る。
[0128]特に、取り出しユニット52は、ビデオ復号器48の復号能力とビデオ出力44のレンダリング能力とを決定するために、クライアントデバイス40の構成データ(図示せず)を取り出し得る。構成データはまた、クライアントデバイス40のユーザによって選択された言語選好、クライアントデバイス40のユーザによって設定された奥行き選好に対応する1つまたは複数のカメラパースペクティブ、および/またはクライアントデバイス40のユーザによって選択されたレーティング選好のうちの任意のものまたは全てを含み得る。取り出しユニット52は、例えば、HTTP GETおよび部分的GET要求をサブミットするように構成されたメディアクライアントまたはウェブブラウザを備え得る。取り出しユニット52は、クライアントデバイス40の1つまたは複数のプロセッサあるいは処理ユニット(図示せず)によって実行されるソフトウェア命令に対応し得る。いくつかの例では、取り出しユニット52に関して説明された機能のうちの全てまたは一部分は、ハードウェア、あるいはハードウェア、ソフトウェア、および/またはファームウェアの組み合わせにおいてインプリメントされ得、ここで、必須のハードウェアは、ソフトウェアまたはファームウェアのための命令を実行するために提供され得る。
[0129]取り出しユニット52は、クライアントデバイス40の復号およびレンダリング能力を、マニフェストファイル66の情報によって示されるリプレゼンテーション68の特性と比較し得る。例えば、取り出しユニット52は、(ビデオ出力44のような)クライアントデバイス40がステレオスコープデータをレンダリングすることが可能であるか、またはモノスコープデータのみをレンダリングすることが可能であるかを決定し得る。取り出しユニット52は初めに、リプレゼンテーション68の特性を決定するために、マニフェストファイル66の少なくとも一部分を取り出し得る。例えば、取り出しユニット52は、1つまたは複数の適合セットの特性を記述するマニフェストファイル66の一部分を要求し得る。取り出しユニット52は、クライアントデバイス40のコーディングおよびレンダリング能力によって満たされることができる特性を有するリプレゼンテーション68(例えば、適合セット)のサブセットを選択し得る。取り出しユニット52はその後、適合セット中のリプレゼンテーションについてのビットレートを決定し、ネットワーク帯域幅の現在利用可能な量を決定し、およびネットワーク帯域幅によって満たされることができるビットレートを有するリプレゼンテーションのうちの1つからセグメントを取り出し得る。この開示の技法にしたがって、取り出しユニット52は、対応する魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを示すデータを取り出し得る。例えば、取り出しユニット52は、リプレゼンテーション68のうちの1つのファイル(例えば、セグメント)の最初の部分を、そのファイルがモノスコープ魚眼ビデオデータを含むかまたはステレオスコープ魚眼ビデオデータを含むかを決定し、およびそのファイルのビデオデータを取り出すかどうかを決定するために、またはリプレゼンテーション68のうちの異なる1つの異なるファイルを、クライアントデバイス40がそのファイルの魚眼ビデオデータをレンダリングすることが可能であるか否かにしたがって、取り出し得る。
[0130]一般に、より高いビットレートリプレゼンテーションは、より高品質のビデオ再生をもたらし得、その一方でより低いビットレートリプレゼンテーションは、利用可能なネットワーク帯域幅が減少したときに十分な品質のビデオ再生を提供し得る。それ故に、利用可能なネットワーク帯域幅が比較的高いとき、取り出しユニット52は、比較的高いビットレートリプレゼンテーションからデータを取り出し得るのに対して、利用可能なネットワーク帯域幅が低いとき、取り出しユニット52は、比較的低いビットレートリプレゼンテーションからデータを取り出し得る。このように、クライアントデバイス40は、ネットワーク74の変化するネットワーク帯域幅の可用性に適合もしながら、ネットワーク74を通してマルチメディアデータをストリーミングし得る。
[0131]加えてまたは代替として、取り出しユニット52は、eMBMSまたはIPマルチキャストのようなブロードキャストまたはマルチキャストネットワークプロトコルにしたがってデータを受信するように構成され得る。そのような例では、取り出しユニット52は、特定のメディアコンテンツに関連付けられたマルチキャストネットワークグループに加わるための要求をサブミットし得る。マルチキャストグループに加わった後に、取り出しユニット52は、サーバデバイス60またはコンテンツ準備デバイス20に発行されるさらなる要求なしに、マルチキャストグループのデータを受信し得る。取り出しユニット52は、例えば、再生を停止するために、または異なるマルチキャストグループにチャネルを変更するために、マルチキャストグループのデータがもはや必要とされないときに、マルチキャストグループを去るための要求をサブミットし得る。
[0132]ネットワークインターフェース54は、選択されたリプレゼンテーションのセグメントのデータを受信し、およびそれを取り出しユニット52に提供し得、それは次に、デカプセル化(decapsulation)ユニット50にそれらセグメントを提供し得る。デカプセル化ユニット50は、構成要素(constituent)PESストリームへとビデオファイルの要素をデカプセル化し、符号化されたデータを取り出すためにPESストリームをデパケット化(depacketize)し、および、例えば、ストリームのPESパケットヘッダによって示されているように、その符号化されたデータがオーディオストリームの一部であるかまたはビデオストリームの一部であるかに依存して、オーディオ復号器46またはビデオ復号器48のいずれかにその符号化されたデータを送り得る。オーディオ復号器46は、符号化されたオーディオデータを復号し、およびオーディオ出力42に復号されたオーディオデータを送り、その一方でビデオ復号器48は、符号化されたビデオデータを復号し、およびビデオ出力44に復号されたビデオデータを送り、それは、ストリームの複数のビューを含み得る。
[0133]ビデオ符号化器28、ビデオ復号器48、オーディオ符号化器26、オーディオ復号器46、カプセル化ユニット30、取り出しユニット52、およびデカプセル化ユニット50は各々、適宜、1つまたは複数のマイクロプロセッサ、デジタルシグナルプロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリートロジック回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組み合わせのような、多様な適した処理回路のうちの任意のものとしてインプリメントされ得る。ビデオ符号化器28およびビデオ復号器48の各々は、1つまたは複数の符号化器または復号器中に含まれ得、それらのうちのいずれも、組み合わされたビデオ符号化器/復号器(CODEC)の一部として統合され得る。同様に、オーディオ符号化器26およびオーディオ復号器46の各々は、1つまたは複数の符号化器または復号器中に含まれ得、それらのうちのいずれも、組み合わされたCODECの一部として統合され得る。ビデオ符号化器28、ビデオ復号器48、オーディオ符号化器26、オーディオ復号器46、カプセル化ユニット30、取り出しユニット52、および/またはデカプセル化ユニット50を含む装置は、集積回路、マイクロプロセッサ、および/またはセルラ電話のようなワイヤレス通信デバイスを備え得る。
[0134]クライアントデバイス40、サーバデバイス60、および/またはコンテンツ準備デバイス20は、この開示の技法にしたがって動作するように構成され得る。例を目的として、この開示は、クライアントデバイス40およびサーバデバイス60に関するこれらの技法を説明している。しかしながら、コンテンツ準備デバイス20が、サーバデバイス60の代わりに(またはそれに加えて)、これらの技法を実行するように構成され得ることが理解されるべきである。
[0135]カプセル化ユニット30は、NALユニットが属するプログラムを識別するヘッダ、ならびにペイロード、例えば、オーディオデータ、ビデオデータ、あるいはNALユニットが対応するトランスポートまたはプログラムストリームを記述するデータ、を備えるNALユニットを形成し得る。例えば、H.264/AVCでは、NALユニットは、1バイトのヘッダと変動するサイズのペイロードとを含む。そのペイロード中にビデオデータを含むNALユニットは、様々な粒度(granularity)レベルのビデオデータを備え得る。例えば、NALユニットは、ビデオデータのブロック、複数のブロック、ビデオデータのスライス、またはビデオデータのピクチャ全体を備え得る。カプセル化ユニット30は、エレメンタリストリームのPESパケットの形状で、ビデオ符号化器28から符号化されたビデオデータを受信し得る。カプセル化ユニット30は、各エレメンタリストリームを対応するプログラムと関連付け得る。
[0136]カプセル化ユニット30はまた、複数のNALユニットからアクセスユニットをアセンブルし得る。一般に、アクセスユニットは、ビデオデータのフレーム、ならびにそのフレームに対応するオーディオデータが利用可能であるときにはそのようなオーディオデータ、を表すための1つまたは複数のNALユニットを備え得る。アクセスユニットは概して、1つの出力時間インスタンスについての全てのNALユニット、例えば、1つの時間インスタンスについての全てのオーディオおよびビデオデータ、を含む。例えば、各ビューが20フレーム/秒(fps)のフレームレートを有する場合、各時間インスタンスは、0.05秒の時間間隔に対応し得る。この時間間隔中に、同じアクセスユニット(同じ時間インスタンス)の全てのビューについての特定のフレームは、同時にレンダリングされ得る。一例では、アクセスユニットは、1つの時間インスタンス中にコーディングされたピクチャを備え得、それは、プライマリのコーディングされたピクチャとして提示され得る。
[0137]それ故に、アクセスユニットは、共通の時間的インスタンスの全てのオーディオおよびビデオフレーム、例えば、時間Xに対応する全てのビュー、を備え得る。この開示はまた、特定のビューの符号化されたピクチャを「ビューコンポーネント」と呼ぶ。すなわち、ビューコンポーネントは、特定の時間における特定のビューについての符号化されたピクチャ(またはフレーム)を備え得る。それ故に、アクセスユニットは、共通の時間的インスタンスの全てのビューコンポーネントを備えるものとして定義され得る。アクセスユニットの復号順序は、出力または表示順序とは必ずしも同じである必要はない。
[0138]メディアプレゼンテーションは、メディアプレゼンテーション記述(MPD)を含み得、それは、異なる代替のリプレゼンテーションの記述を包含し得(例えば、異なる品質を有するビデオサービス)、および記述は、例えば、コーデック情報、プロファイル値、およびレベル値を含み得る。MPDは、マニフェストファイル66のようなマニフェストファイルの一例である。クライアントデバイス40は、様々なプレゼンテーションのムービーフラグメントにどのようにアクセスするかを決定するために、メディアプレゼンテーションのMPDを取り出し得る。ムービーフラグメントは、ビデオファイルのムービーフラグメントボックス(moofボックス)中にロケートされ得る。
[0139](例えば、MPDを備え得る)マニフェストファイル66は、リプレゼンテーション68のセグメントの可用性をアドバタイズし得る。すなわち、MPDは、リプレゼンテーション68のうちの1つの第1のセグメントが利用可能になるウォールクロック時間(the wall-clock time)を示す情報、ならびにリプレゼンテーション68内のセグメントの持続時間を示す情報を含み得る。このように、クライアントデバイス40の取り出しユニット52は、特定のセグメントに先行するセグメントの持続時間ならびに開始時間に基づいて、各セグメントがいつ利用可能になるかを決定し得る。
[0140]カプセル化ユニット30が受信されたデータに基づいてNALユニットおよび/またはアクセスユニットをビデオファイルへとアセンブルした後に、カプセル化ユニット30は、出力のために出力インターフェース32にそのビデオファイルを渡す。いくつかの例では、カプセル化ユニット30は、クライアントデバイス40に直接ビデオファイルを送るというよりはむしろ、出力インターフェース32を介してリモートサーバにビデオファイルを送り得るか、またはビデオファイルをローカルに記憶し得る。出力インターフェース32は、例えば、送信機、トランシーバ、例えば、光学ドライブ、磁気媒体ドライブ(例えば、フロッピー(登録商標)ドライブ)、ユニバーサルシリアルバス(USB)ポート、ネットワークインターフェース、または他の出力インターフェースのような、コンピュータ可読媒体にデータを書き込むためのデバイスを備え得る。出力インターフェース32は、例えば、送信信号、磁気媒体、光学媒体、メモリ、フラッシュドライブ、または他のコンピュータ可読媒体のようなコンピュータ可読媒体にビデオファイルを出力する。
[0141]ネットワークインターフェース54は、ネットワーク74を介してNALユニットまたはアクセスユニットを受信し、および取り出しユニット52を介してデカプセル化ユニット50にNALユニットまたはアクセスユニットを提供し得る。デカプセル化ユニット50は、構成要素PESストリームへとビデオファイルの要素をデカプセル化し、符号化されたデータを取り出すためにPESストリームをデパケット化し、および、例えば、ストリームのPESパケットヘッダによって示されているように、その符号化されたデータがオーディオストリームの一部であるかまたはビデオストリームの一部であるかに依存して、オーディオ復号器46またはビデオ復号器48のいずれかにその符号化されたデータを送り得る。オーディオ復号器46は、符号化されたオーディオデータを復号し、およびオーディオ出力42に復号されたオーディオデータを送り、その一方でビデオ復号器48は、符号化されたビデオデータを復号し、およびビデオ出力44に復号されたビデオデータを送り、それは、ストリームの複数のビューを含み得る。
[0142]このように、クライアントデバイス40は、メディアデータを取り出すためのデバイスの例を表し、そのデバイスは、上述されたような、および/または以下の特許請求の範囲に記載されたような、魚眼ビデオデータファイルを取り出すためのデバイスを含む。例えば、クライアントデバイス40は、魚眼ビデオデータファイルを取り出し得、および/または魚眼ビデオがモノスコープであるかまたはステレオスコープであるかの決定に基づいて魚眼ビデオをレンダリングし得、およびこの決定は、魚眼ビデオがモノスコープであるかまたはステレオスコープであるかを明示的に指定するシンタックス要素に基づき得る。
[0143]同様に、コンテンツ準備デバイス20は、上述されたような、および/または以下の特許請求の範囲に記載されたような、魚眼ビデオデータファイルを生成するためのデバイスを表す。例えば、コンテンツ準備デバイス20は、魚眼ビデオがモノスコープであるかまたはステレオスコープであるかを明示的に指定するシンタックス要素を、魚眼ビデオデータ中に含め得る。
[0144]図10は、実例的なマルチメディアコンテンツ120の要素を例示する概念図である。マルチメディアコンテンツ120は、マルチメディアコンテンツ64(図9)、または記憶媒体62中に記憶された別のマルチメディアコンテンツに対応し得る。図10の例では、マルチメディアコンテンツ120は、メディアプレゼンテーション記述(MPD)122と複数のリプレゼンテーション124A~124N(リプレゼンテーション124)とを含む。リプレゼンテーション124Aは、オプションのヘッダデータ126とセグメント128A~128N(セグメント128)とを含み、その一方でリプレゼンテーション124Nは、オプションのヘッダデータ130とセグメント132A~132N(セグメント132)とを含む。Nの文字は、便宜上、リプレゼンテーション124の各々中の最後のムービーフラグメントを指定するために使用されている。いくつかの例では、リプレゼンテーション124間に異なる数のムービーフラグメントが存在し得る。
[0145]MPD122は、リプレゼンテーション124とは別個のデータ構造を備え得る。MPD122は、図9のマニフェストファイル66に対応し得る。一般に、MPD122は、コーディングおよびレンダリング特性、適合セット、MPD122が対応するプロファイル、テキストタイプ情報、カメラアングル情報、レーティング情報、トリックモード情報(例えば、時間的サブシーケンスを含むリプレゼンテーションを示す情報)、および/または(例えば、再生中におけるメディアコンテンツへのターゲット広告の挿入のための)リモート期間を取り出すための情報のような、リプレゼンテーション124の特性を概して記述するデータを含み得る。
[0146]ヘッダデータ126は、存在するとき、セグメント128の特性、例えば、ランダムアクセスポイント(RAP、ストリームアクセスポイント(SAP)とも呼ばれる)の時間的ロケーション、セグメント128のうちのどれがランダムアクセスポイントを含むか、セグメント128内のランダムアクセスポイントに対するバイトオフセット、セグメント128のユニフォームリソースロケータ(URL)、またはセグメント128の他の態様を記述し得る。ヘッダデータ130は、存在するとき、セグメント132についての同様の特性を記述し得る。加えてまたは代替として、そのような特性は、MPD122内に完全に含まれ得る。
[0147]セグメント128、132は、1つまたは複数のコーディングされたビデオサンプルを含み、それらの各々は、ビデオデータのフレームまたはスライスを含み得る。セグメント128のコーディングされたビデオサンプルの各々は、同様の特性、例えば、高さ、幅、および帯域幅要件を有し得る。そのような特定は、MPD122のデータによって記述され得るが、そのようなデータは、図10の例には例示されていない。MPD122は、この開示に説明されるシグナリングされる情報のうちの任意のものまたは全ての追加とともに、3GPP仕様書によって説明されるような特性を含み得る。
[0148]セグメント128、132の各々は、一意のユニフォームリソースロケータ(URL)に関連付けられ得る。このことから、セグメント128、132の各々は、DASHのようなストリーミングネットワークプロトコルを使用して、独立して取り出し可能であり得る。このように、クライアントデバイス40のような宛先デバイスは、セグメント128または132を取り出すために、HTTP GET要求を使用し得る。いくつかの例では、クライアントデバイス40は、セグメント128または132の特定のバイト範囲を取り出すために、HTTP部分的GET要求を使用し得る。
[0149]図11は、実例的なビデオファイル150の要素を例示するブロック図であり、それは、図10のセグメント114、124のうちの1つのような、リプレゼンテーションのセグメントに対応し得る。セグメント128、132の各々は、図11の例において例示されているデータの配列に実質的に一致するデータを含み得る。ビデオファイル150は、セグメントをカプセル化すると言われ得る。上述されたように、ISOベースメディアファイルフォーマットおよびその拡張にしたがったビデオファイルは、「ボックス」と呼ばれる一連のオブジェクト中にデータを記憶する。図11の例では、ビデオファイル150は、ファイルタイプ(FTYP)ボックス152、ムービー(MOOV)ボックス154、セグメントインデックス(sidx)ボックス162、ムービーフラグメント(MOOF)ボックス164、およびムービーフラグメントランダムアクセス(MFRA)ボックス166を含む。図11は、ビデオファイルの例を表しているが、他のメディアファイルが、ISOベースメディアファイルフォーマットおよびその拡張にしたがった、ビデオファイル150のデータと同様に構造化された他のタイプのメディアデータ(例えば、オーディオデータ、時間指定されたテキストデータ、または同様のもの)を含み得ることが理解されるべきである。
[0150]ファイルタイプ(FTYP)ボックス152は概して、ビデオファイル150についてのファイルタイプを記述する。ファイルタイプボックス152は、ビデオファイル150についての最良の使用を記述する仕様を識別するデータを含み得る。ファイルタイプボックス152は代替として、MOOVボックス154、ムービーフラグメントボックス164、および/またはMFRAボックス166の前に配置され得る。
[0151]いくつかの例では、ビデオファイル150のようなセグメントは、FTYPボックス152の前にMPD更新ボックス(図示せず)を含み得る。MPD更新ボックスは、MPDを更新するための情報とともに、ビデオファイル150を含むリプレゼンテーションに対応するMPDが更新されるべきであることを示す情報を含み得る。例えば、MPD更新ボックスは、MPDを更新するために使用されるべきリソースについてのURIまたはURLを提供し得る。別の例として、MPD更新ボックスは、MPDを更新するためのデータを含み得る。いくつかの例では、MPD更新ボックスは、ビデオファイル150のセグメントタイプ(STYP)ボックス(図示せず)の直後に後続し得、ここで、STYPボックスは、ビデオファイル150についてのセグメントタイプを定義し得る。
[0152]MOOVボックス154は、図11の例では、ムービーヘッダ(MVHD)ボックス156、トラック(TRAK)ボックス158、および1つまたは複数のムービー拡張(MVEX)ボックス160を含む。一般に、MVHDボックス156は、ビデオファイル150の一般の特性を記述し得る。例えば、MVHDボックス156は、いつビデオファイル150が当初に作成されたか、いつビデオファイル150が最後に修正されたか、ビデオファイル150についての時間スケール、ビデオファイル150についての再生の持続時間、またはビデオファイル150を概して記述する他のデータ、を記述するデータを含み得る。
[0153]TRAKボックス158は、ビデオファイル150のトラックについてのデータを含み得る。TRAKボックス158は、TRAKボックス158に対応するトラックの特性を記述するトラックヘッダ(TKHD)ボックスを含み得る。いくつかの例では、TRAKボックス158は、コーディングされたビデオピクチャを含み得、その一方で他の例では、トラックのコーディングされたビデオピクチャは、ムービーフラグメント164中に含まれ得、それは、TRAKボックス158および/またはsidxボックス162のデータによって参照され得る。
[0154]いくつかの例では、ビデオファイル150は、1つより多くのトラックを含み得る。それ故に、MOOVボックス154は、ビデオファイル150中のトラックの数に等しいいくつかのTRAKボックスを含み得る。TRAKボックス158は、ビデオファイル150の対応するトラックの特性を記述し得る。例えば、TRAKボックス158は、対応するトラックについての時間的および/または空間的情報を記述し得る。MOOVボックス154のTRAKボックス158と同様なTRAKボックスは、カプセル化ユニット30(図9)がビデオファイル150のようなビデオファイル中にパラメータセットトラックを含めるときに、パラメータセットトラックの特性を記述し得る。カプセル化ユニット30は、パラメータセットトラックを記述するTRAKボックス内で、パラメータセットトラック中のシーケンスレベルSEIメッセージの存在をシグナリングし得る。
[0155]MVEXボックス160は、例えば、ある場合には、MOOVボックス154内に含まれるビデオデータに加えて、ビデオファイル150がムービーフラグメント164を含むことをシグナリングするために、対応するムービーフラグメント164の特性を記述し得る。ビデオデータをストリーミングすることのコンテキストでは、コーディングされたビデオピクチャは、MOOVボックス154中というよりはむしろムービーフラグメント164中に含まれ得る。それ故に、全てのコーディングされたビデオサンプルは、MOOVボックス154中というよりはむしろ、ムービーフラグメント164中に含まれ得る。
[0156]MOOVボックス154は、ビデオファイル150中のムービーフラグメント164の数に等しいいくつかのMVEXボックス160を含み得る。MVEXボックス160の各々は、ムービーフラグメント164のうちの対応するものの特性を記述し得る。例えば、各MVEXボックスは、ムービーフラグメント164のうちの対応するものについての時間的持続時間(a temporal duration)を記述するムービー拡張ヘッダボックス(MEHD)ボックスを含み得る。
[0157]さらに、この開示の技法にしたがって、ビデオファイル150は、SchemeInformationBox中にFisheyeOmnidirectionalVideoBoxを含み得、それは、MOOVボックス154中に含まれ得る。いくつかの例では、FisheyeOmnidirectionalVieoBoxは、ビデオファイル150の異なるトラックがモノスコープまたはステレオスコープ魚眼ビデオデータを含み得る場合に、TRAKボックス158中に含まれ得る。いくつかの例では、FisheyeOmnidirectionalVieoBoxは、FOVボックス157中に含まれ得る。
[0158]上述されたように、カプセル化ユニット30は、実際のコーディングされたビデオデータを含まないビデオサンプル中にシーケンスデータセットを記憶し得る。ビデオサンプルは概して、アクセスニットに対応し得、それは、特定の時間インスタンスにおけるコーディングされたピクチャのリプレゼンテーションである。AVCのコンテキストでは、コーディングされたピクチャは、アクセスユニットの全てのピクセルを構築するための情報を包含する1つまたは複数のVCL NALユニットと、SEIメッセージのような他の関連する非VCL NALユニットとを含み得る。それ故に、カプセル化ユニット30は、ムービーフラグメント164のうちの1つ中にシーケンスデータセットを含め得、それは、シーケンスレベルSEIメッセージを含み得る。カプセル化ユニット30はさらに、ムービーフラグメント164のうちの1つに対応するMVEXボックス160のうちの1つ内で、ムービーフラグメント164のうちの1つ中に存在するものとして、シーケンスレベルSEIメッセージおよび/またはシーケンスデータセットの存在をシグナリングし得る。
[0159]SIDXボックス162は、ビデオファイル150のオプションの要素である。すなわち、3GPPファイルフォーマット、または他のそのようなファイルフォーマットに準拠するビデオファイルは、必ずしもSIDXボックス162を含むわけではない。3GPPファイルフォーマットの例にしたがって、SIDXボックスは、セグメント(例えば、ビデオファイル150内に包含されるセグメント)のサブセグメントを識別するために使用され得る。3GPPファイルフォーマットは、サブセグメントを、「対応するメディアデータボックス(1つ以上)を有する1つまたは複数の連続するムービーフラグメントボックスの内蔵された(self-contained)セットであって、ムービーフラグメントボックスによって参照されるデータを包含するメディアデータボックスは、そのムービーフラグメントボックスに後続し、および同じトラックについての情報を包含する次のムービーフラグメントボックスに先行しなければならない」と定義している。3GPPファイルフォーマットはまた、SIDXボックスが、「ボックスによってドキュメントされる(サブ)セグメントのサブセグメントへの参照のシーケンスを包含する。参照されるサブセグメントは、提示時間において連続している。同様に、セグメントインデックスボックスによって参照されるバイトは常に、セグメント内で連続している。参照されるサイズは、参照されるマテリアル中のバイトの数のカウントを示す(gives)」ことを示す。
[0160]SIDXボックス162は概して、ビデオファイル150中に含まれるセグメントの1つまたは複数のサブセグメントを表す情報を提供する。例えば、そのような情報は、サブセグメントが始まるおよび/または終了する再生時間、サブセグメントについてのバイトオフセット、サブセグメントがストリームアクセスポイント(SAP)を含む(例えば、それから開始する)かどうか、SAPについてのタイプ(例えば、SAPが瞬時復号器リフレッシュ(IDR:instantaneous decoder refresh)ピクチャ、クリーンランダムアクセス(CRA)ピクチャ、ブロークンリンクアクセス(BLA)ピクチャ、または同様のものであるか)、サブセグメント中の(再生時間および/またはバイトオフセットの観点からの)SAPの位置、および同様のもの、を含み得る。
[0161]ムービーフラグメント164は、1つまたは複数のコーディングされたビデオピクチャを含み得る。いくつかの例では、ムービーフラグメント164は、1つまたは複数のピクチャのグループ(GOP:group of pictures)を含み得、それらの各々は、いくつかのコーディングされたビデオピクチャ、例えば、フレームまたはピクチャを含み得る。加えて、上述されたように、ムービーフラグメント164は、いくつかの例ではシーケンスデータセットを含み得る。ムービーフラグメント164の各々は、ムービーフラグメントヘッダボックス(MFHD、図11には図示せず)を含み得る。MFHDボックスは、ムービーフラグメントについてのシーケンス番号のような、対応するムービーフラグメントの特性を記述し得る。ムービーフラグメント164は、ビデオファイル150中にシーケンス番号の順序で含まれ得る。
[0162]MFRAボックス166は、ビデオファイル150のムービーフラグメント164内のランダムアクセスポイントを記述し得る。これは、ビデオファイル150によってカプセル化されたセグメント内の特定の時間的ロケーション(すなわち、再生時間)に対してシークを実行するといったような、トリックモードを実行することを支援し得る。MFRAボックス166は概してオプションであり、およびいくつかの例では、ビデオファイル中に含まれる必要はない。同様に、クライアントデバイス40のようなクライアントデバイスは、ビデオファイル150のビデオデータを正しく復号および表示するために、必ずしもMFRAボックス166を参照する必要はない。MFRAボックス166は、ビデオファイル150のトラックの数に等しいか、またはいくつかの例では、ビデオファイル150のメディアトラック(例えば、非ヒントトラック)の数に等しい、いくつかのトラックフラグメントランダムアクセス(TFRA)ボックス(図示せず)を含み得る。
[0163]いくつかの例では、ムービーフラグメント164は、IDRピクチャのような1つまたは複数のストリームアクセスポイント(SAP)を含み得る。同様に、MFRAボックス166は、SAPのビデオファイル150内のロケーションのインジケーションを提供し得る。それ故に、ビデオファイル150の時間的サブシーケンスは、ビデオファイル150のSAPから形成され得る。時間的サブシーケンスはまた、SAPに従属する(depend from)Bフレームおよび/またはPフレームのような他のピクチャを含み得る。時間的サブシーケンスのフレームおよび/またはスライスは、サブシーケンスの他のフレーム/スライスに依存する時間的サブシーケンスのフレーム/スライスが適正に復号されることができるように、セグメント内に配列され得る。例えば、データの階層的配列では、他のデータについての予測のために使用されるデータもまた、時間的サブシーケンス中に含まれ得る。
[0164]図12は、この開示の1つまたは複数の技法にしたがった、魚眼ビデオデータを含むファイルを処理するための実例的な技法を例示するフローチャートである。図12の技法は、図9のクライアントデバイス40によって実行されるものとして説明されるが、クライアントデバイス40以外の構成を有するデバイスが、図12の技法を実行し得る。
[0165]クライアントデバイス40は、魚眼ビデオデータと、魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造とを含むファイルを受信し得る(1202)。上述されたように、複数のシンタックス要素は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第1のシンタックス要素と、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを暗示的に示す1つまたは複数のシンタックス要素とを含み得る。魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを暗示的に示す1つまたは複数のシンタックス要素は、魚眼ビデオデータをキャプチャするために使用されるカメラの外部(extrinsic)パラメータを明示的に示すシンタックス要素であり得る。いくつかの例では、1つまたは複数のシンタックス要素は、OMAF DISの現在の草案中のFisheyeOmnidirectionalVideoInfo( )シンタックス構造中に含まれるシンタックス要素であり得るか、またはそれと同様であり得る。いくつかの例では、第1のシンタックス要素は、シンタックス構造の最初のビット(initial bits)のセット(例えば、FisheyeOmnidirectionalVideoInfo( )シンタックス構造の最初の(initial)24ビット)中に含まれ得る。
[0166]クライアントデバイス40は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、第1のシンタックス要素に基づいて決定し得る(1204)。第1のシンタックス要素の値は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示し得る。一例として、第1のシンタックス要素が第1の値を有する場合、クライアントデバイス40は、魚眼ビデオデータがモノスコープである(すなわち、魚眼ビデオデータのピクチャ中に含まれる円形画像が、揃えられた(aligned)光軸を有し、且つ対向方向(opposite directions)を向いている)と決定し得る。別の例として、第1のシンタックス要素が第2の値を有する場合、クライアントデバイス40は、魚眼ビデオデータがステレオスコープである(すなわち、魚眼ビデオデータのピクチャ中に含まれる円形画像が、平行な光軸を有し、且つ同じ方向を向いている)と決定し得る。
[0167]上述されたように、魚眼ビデオデータをキャプチャするために使用されるカメラの外部パラメータを明示的に示すシンタックス要素に基づいて、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかをクライアントデバイス40が決定することは可能であり得るが、そのような算出は、クライアントデバイス40上での計算負荷を増大させ得る。このように、実行される算出(およびこのことから、使用される計算リソース)を低減するために、クライアントデバイス40は、第1のシンタックス要素に基づいて、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを決定し得る。
[0168]クライアントデバイス40は、その決定に基づいて、魚眼ビデオデータをレンダリングし得る。例えば、魚眼ビデオデータがモノスコープであると決定することに応答して、クライアントデバイス40は、モノスコープとして魚眼データをレンダリングし得る(1206)。例えば、クライアントデバイス40は、ビューポート(すなわち、ユーザが現在「見ている」球の一部分)を決定することと、ビューポートに対応する魚眼ビデオデータの円形画像の一部分を識別することと、視聴者の目の各々に円形画像の同じ部分を表示することとを行い得る。同様に、魚眼ビデオデータがステレオスコープであると決定することに応答して、クライアントデバイス40は、ステレオスコープとして魚眼データをレンダリングし得る(1208)。例えば、クライアントデバイス40は、ビューポート(すなわち、ユーザが現在「見ている」球の一部分)を決定することと、ビューポートに対応する魚眼ビデオデータの円形画像の各々のそれぞれの部分を識別することと、視聴者の目に円形画像のそれぞれの部分を表示することとを行い得る。
[0169]図13は、この開示の1つまたは複数の技法にしたがった、魚眼ビデオデータを含むファイルを生成するための実例的な技法を例示するフローチャートである。図13の技法は、図9のコンテンツ準備デバイス20によって実行されるものとして説明されるが、コンテンツ準備デバイス20以外の構成を有するデバイスが、図13の技法を実行し得る。
[0170]コンテンツ準備デバイス20は、魚眼ビデオデータと、魚眼ビデオデータをキャプチャするために使用されるカメラの外部パラメータとを取得し得る(1302)。例えば、コンテンツ準備デバイス20は、HEVCのようなビデオコーデックを使用して符号化されている魚眼ビデオデータのピクチャを取得し得る。魚眼ビデオデータのピクチャの各々は、魚眼レンズを有する異なるカメラによってキャプチャされた画像に各々対応する複数の円形画像を含み得る(例えば、ピクチャは、図1Aの魚眼レンズ12Aを介してキャプチャされた第1の円形画像と、図1Aの魚眼レンズ12Bを介してキャプチャされた第2の円形画像とを含み得る)。外部パラメータは、カメラの様々な属性を指定し得る。例えば、外部パラメータは、魚眼ビデオデータをキャプチャするために使用されるカメラの各々のヨー角、ピッチ角、ロール角、および1つまたは複数の空間的オフセットを指定し得る。
[0171]コンテンツ準備デバイス20は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、外部パラメータに基づいて決定し得る(1304)。一例として、カメラ外部パラメータ値の2つのセットが次の通りであるとき、コンテンツ準備デバイス20は、魚眼ビデオがステレオスコープであると決定し得る:
第1のセット(1st set):
camera_center_yaw = 0 degrees (+/- 5 degrees)
camera center_pitch = 0 degrees (+/- 5 degrees)
camera center roll = 0 degrees (+/- 5 degrees)
camera_center_offset_x = 0 mm (+/- 3 mm)
camera_center_offset_y = 0 mm (+/- 3 mm)
camera_center_offset_z = 0 mm (+/- 3 mm)
第2のセット(2nd set):
camera_center_yaw = 0 degrees (+/- 5 degrees)
camera center_pitch = 0 degrees (+/- 5 degrees)
camera center roll = 0 degrees (+/- 5 degrees)
camera_center_offset_x = 64 mm (+/- 3 mm)
camera_center_offset_y = 0 mm (+/- 3 mm)
camera_center_offset_z = 0 mm (+/- 3 mm)
[0172]別の例として、カメラ外部パラメータ値の2つのセットが次の通りであるとき、コンテンツ準備デバイス20は、魚眼ビデオがモノスコープであると決定し得る:
第1のセット(1st set):
camera_center_yaw = 0 degrees (+/- 5 degrees)
camera center_pitch = 0 degrees (+/- 5 degrees)
camera center roll = 0 degrees (+/- 5 degrees)
camera_center_offset_x = 0 mm (+/- 3 mm)
camera_center_offset_y = 0 mm (+/- 3 mm)
camera_center_offset_z = 0 mm (+/- 3 mm)
第2のセット(2nd set):
camera_center_yaw = 180 degrees (+/- 5 degrees)
camera center_pitch = 0 degrees (+/- 5 degrees)
camera center roll = 0 degrees (+/- 5 degrees)
camera_center_offset_x = 0 mm (+/- 3 mm)
camera_center_offset_y = 0 mm (+/- 3 mm)
camera_center_offset_z = 0 mm (+/- 3 mm)
[0173]コンテンツ準備デバイス20は、魚眼ビデオデータと、魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造とをファイル中で符号化し得る(1306)。複数のシンタックス要素は、次を含む:魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第1のシンタックス要素、および魚眼ビデオデータをキャプチャするために使用されるカメラの外部パラメータを明示的に示す1つまたは複数のシンタックス要素。
[0174]1つまたは複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせにおいてインプリメントされ得る。ソフトウェアにおいてインプリメントされる場合、それら機能は、1つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶され得るか、またはコンピュータ可読媒体を通して送信され得、およびハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、例えば、通信プロトコルにしたがって、コンピュータプログラムのある場所から別の場所への転送を容易にする任意の媒体を含む通信媒体、またはコンピュータ可読記憶媒体を含み得、それは、データ記憶媒体のような有形媒体に対応する。このように、コンピュータ可読媒体は概して、(1)非一時的である有形コンピュータ可読記憶媒体、あるいは(2)信号または搬送波のような通信媒体に対応し得る。データ記憶媒体は、この開示に説明された技法のインプリメンテーションのための命令、コード、および/またはデータ構造を取り出すために、1つまたは複数のコンピュータあるいは1つまたは複数のプロセッサによってアクセスされることができる任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。
[0175]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM(登録商標)、CD-ROMまたは他の光ディスク記憶装置、磁気ディスク記憶装置、または他の磁気記憶デバイス、フラッシュメモリ、あるいはデータ構造もしくは命令の形態で所望されるプログラムコードを記憶するために使用されることができ、且つコンピュータによってアクセスされることができる任意の他の媒体を備えることができる。また、任意の接続は、厳密にはコンピュータ可読媒体と称される。例えば、命令が、ウェブサイト、サーバ、あるいは同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波のようなワイヤレス技術を使用する他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波のようなワイヤレス技術は、媒体の定義中に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象にすることが理解されるべきである。ディスク(disk)およびディスク(disc)は、ここに使用される場合、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)、およびBlu-ray(登録商標)ディスク(disc)を含み、ここで、ディスク(disk)は通常、磁気的にデータを再生し、その一方でディスク(disc)は、レーザーを用いて光学的にデータを再生する。上記の組み合わせもまた、コンピュータ可読媒体の範囲内に含まれるべきである。
[0176]命令は、1つまたは複数のデジタルシグナルプロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルロジックアレイ(FPGA)、あるいは他の同等な集積またはディスクリートロジック回路のような1つまたは複数のプロセッサによって実行され得る。それ故に、「プロセッサ」という用語は、ここに使用される場合、前述の構造のうちの任意のものまたはここに説明された技法のインプリメンテーションに適した任意の他の構造を指し得る。加えて、いくつかの態様では、ここに説明された機能は、符号化および復号のために構成された専用ハードウェアおよび/またはソフトウェアモジュール内で提供され得るか、あるいは組み合わされたコーデック中に組み込まれ得る。また、それら技法は、1つまたは複数の回路またはロジック要素において十分にインプリメントされることができる。
[0177]この開示の技法は、ワイヤレスハンドセット、集積回路(IC)またはICのセット(例えば、チップセット)を含む、幅広い多様なデバイスまたは装置においてインプリメントされ得る。様々なコンポーネント、モジュール、またはユニットは、開示された技法を実行するように構成されたデバイスの機能的な態様を強調するためにこの開示に説明されているが、必ずしも異なるハードウェアユニットによる実現を必要とするわけではない。むしろ、上述されたように、様々なユニットは、コーデックハードウェアユニット中で組み合わされ得るか、あるいは、適したソフトウェアおよび/またはファームウェアと併せて、上述されたような1つまたは複数のプロセッサを含む、相互運用ハードウェアユニットの集合によって提供され得る。
[0178]様々な例が説明されてきた。これらおよび他の例は、次の特許請求の範囲内にある。
以下に本願の出願当初の特許請求の範囲に記載された発明を付記する。
[C1] ビデオデータを含むファイルを処理する方法であって、前記方法は、
魚眼ビデオデータを含むファイルを処理することと、前記ファイルは、前記魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造を含み、ここにおいて、前記複数のシンタックス要素は、前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第1のシンタックス要素と、前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを暗示的に示す1つまたは複数のシンタックス要素とを含む、
前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、前記第1のシンタックス要素に基づいて決定することと、
モノスコープまたはステレオスコープとしてレンダリングするために、前記魚眼ビデオデータを前記決定に基づいて出力することと、
を備える、方法。
[C2] 前記第1のシンタックス要素は、前記シンタックス構造の最初のビットのセット中に含まれる、C1に記載の方法。
[C3] 前記最初のビットのセットは、長さが24ビットである、C2に記載の方法。
[C4] 前記ファイルは、前記シンタックス構造を含むボックスを含む、C1に記載の方法。
[C5] 前記ボックスは、スキーム情報を含む第2のボックス中に含まれている第1のボックスであり、前記方法は、
前記魚眼ビデオデータのピクチャがリージョンワイズパッキングされているかどうかを示す第3のボックスを前記第1のボックスが含むかどうかを決定すること、
をさらに備える、C4に記載の方法。
[C6] 前記第1のボックスが前記第3のボックスを含むと決定することに応答して、前記魚眼ビデオデータの前記ピクチャをレンダリングするより前に前記魚眼ビデオデータの前記ピクチャをアンパッキングすること、または、
前記第1のボックスが前記第3のボックスを含まないと決定することに応答して、前記魚眼ビデオデータの前記ピクチャをアンパッキングすることなしに前記魚眼ビデオデータの前記ピクチャをレンダリングすること、
をさらに備える、C5に記載の方法。
[C7] 前記第1のボックスは、SchemeInformationBoxであり、前記第2のボックスは、FisheyeOmnidirectionalVideoBoxであり、および前記第3のボックスは、RegionWisePackingBoxである、C5に記載の方法。
[C8] 前記シンタックス構造は、前記魚眼ビデオデータの各ピクチャ中に含まれる円形画像の数を指定する第2のシンタックス要素をさらに含む、C1に記載の方法。
[C9] 前記シンタックス構造は、それぞれの円形画像ごとに、前記それぞれの円形画像のビュー識別子を示すそれぞれの第3のシンタックス要素を備える、C8に記載の方法。
[C10] 前記シンタックス構造は、前記ファイルによってカプセル化されるビデオコーディングレイヤ(VCL)データの外部にある、C1に記載の方法。
[C11] 前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを決定することは、
前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、前記第1のシンタックス要素に基づいて、および前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを暗示的に示す前記シンタックス要素にかかわらず決定すること、
を備える、C1に記載の方法。
[C12] ビデオデータを含むファイルを生成するための方法であって、前記方法は、
魚眼ビデオデータと、前記魚眼ビデオデータをキャプチャするために使用されるカメラの外部パラメータとを取得することと、
前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、前記外部パラメータに基づいて決定することと、
前記魚眼ビデオデータと、前記魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造とを、ファイル中で符号化することと、ここにおいて、前記複数のシンタックス要素は、前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第1のシンタックス要素と、前記魚眼ビデオデータをキャプチャするために使用される前記カメラの前記外部パラメータを明示的に示す1つまたは複数のシンタックス要素とを含む、
を備える、方法。
[C13] 前記第1のシンタックス要素を符号化することは、前記シンタックス構造の最初のビットのセット中の前記第1のシンタックス要素を符号化することを備える、C12に記載の方法。
[C14] 前記最初のビットのセットは、長さが24ビットである、C13に記載の方法。
[C15] 前記ファイルは、前記シンタックス構造を含むボックスを含む、C12に記載の方法。
[C16] 前記ボックスは、スキーム情報を含む第2のボックス中に含まれている第1のボックスであり、前記方法は、
前記魚眼ビデオデータのピクチャがリージョンワイズパッキングされているかどうかを示す第3のボックスを、前記第1のボックス中に符号化すること、
をさらに備える、C15に記載の方法。
[C17] 前記第1のボックスは、SchemeInformationBoxであり、前記第2のボックスは、FisheyeOmnidirectionalVideoBoxであり、および前記第3のボックスは、RegionWisePackingBoxである、C16に記載の方法。
[C18] 前記シンタックス構造は、前記魚眼ビデオデータの各ピクチャ中に含まれる円形画像の数を指定する第2のシンタックス要素をさらに含む、C12に記載の方法。
[C19] 前記シンタックス構造は、それぞれの円形画像ごとに、前記それぞれの円形画像のビュー識別子を示すそれぞれの第3のシンタックス要素を備える、C18に記載の方法。
[C20] 前記魚眼ビデオデータは、ビデオコーディングレイヤ(VCL)中に符号化され、および前記シンタックス構造は、前記VCLの外部にある、C12に記載の方法。
[C21] ビデオデータを処理するためのデバイスであって、前記デバイスは、
魚眼ビデオデータを含むファイルの少なくとも一部分を記憶するように構成されたメモリと、前記ファイルは、前記魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造を含み、ここにおいて、前記複数のシンタックス要素は、前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第1のシンタックス要素と、前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを暗示的に示す1つまたは複数のシンタックス要素とを含む、
1つまたは複数のプロセッサと、
を備え、前記1つまたは複数のプロセッサは、
前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、前記第1のシンタックス要素に基づいて決定することと、
モノスコープまたはステレオスコープとしてレンダリングするために、前記魚眼ビデオデータを前記決定に基づいて出力することと、
を行うように構成された、デバイス。
[C22] 前記第1のシンタックス要素は、前記シンタックス構造の最初のビットのセット中に含まれる、C21に記載のデバイス。
[C23] 前記最初のビットのセットは、長さが24ビットである、C22に記載のデバイス。
[C24] 前記ファイルは、前記シンタックス構造を含むボックスを含む、C21に記載のデバイス。
[C25] 前記ボックスは、スキーム情報を含む第2のボックス中に含まれている第1のボックスであり、前記1つまたは複数のプロセッサは、
前記魚眼ビデオデータのピクチャがリージョンワイズパッキングされているかどうかを示す第3のボックスを前記第1のボックスが含むかどうかを決定すること、
を行うようにさらに構成される、C24に記載のデバイス。
[C26] 前記第1のボックスが前記第3のボックスを含むと決定することに応答して、前記1つまたは複数のプロセッサは、前記魚眼ビデオデータの前記ピクチャをレンダリングするより前に前記魚眼ビデオデータの前記ピクチャをアンパッキングするようにさらに構成される、または、
前記第1のボックスが前記第3のボックスを含まないと決定することに応答して、前記1つまたは複数のプロセッサは、前記魚眼ビデオデータの前記ピクチャをアンパッキングすることなしに前記魚眼ビデオデータの前記ピクチャをレンダリングするようにさらに構成される、
C25に記載のデバイス。
[C27] 前記第1のボックスは、SchemeInformationBoxであり、前記第2のボックスは、FisheyeOmnidirectionalVideoBoxであり、および前記第3のボックスは、RegionWisePackingBoxである、C25に記載のデバイス。
[C28] 前記シンタックス構造は、前記魚眼ビデオデータの各ピクチャ中に含まれる円形画像の数を指定する第2のシンタックス要素をさらに含む、C21に記載のデバイス。
[C29] 前記シンタックス構造は、前記ファイルによってカプセル化されるビデオコーディングレイヤ(VCL)データの外部にある、C21に記載のデバイス。
[C30] 前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを決定するために、前記1つまたは複数のプロセッサは、
前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、前記第1のシンタックス要素に基づいて、および前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを暗示的に示す前記シンタックス要素にかかわらず決定すること
を行うように構成される、C21に記載のデバイス。
[C31] ビデオデータを含むファイルを生成するためのデバイスであって、前記デバイスは、 魚眼ビデオデータを記憶するように構成されたメモリと、
1つまたは複数のプロセッサと、を備え、前記1つまたは複数のプロセッサは、
前記魚眼ビデオデータをキャプチャするために使用されるカメラの外部パラメータを取得することと、
前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、前記外部パラメータに基づいて決定することと、
前記魚眼ビデオデータと、前記魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造とをファイル中で符号化することと、ここにおいて、前記複数のシンタックス要素は、前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第1のシンタックス要素と、前記魚眼ビデオデータをキャプチャするために使用される前記カメラの前記外部パラメータを明示的に示す1つまたは複数のシンタックス要素とを含む、
を行うように構成された、デバイス。
[C32] 前記第1のシンタックス要素を符号化するために、前記1つまたは複数のプロセッサは、前記シンタックス構造の最初のビットのセット中の前記第1のシンタックス要素を符号化するように構成される、C31に記載のデバイス。
[C33] 前記最初のビットのセットは、長さが24ビットである、C32に記載のデバイス。
[C34] 前記ファイルは、前記シンタックス構造を含むボックスを含む、C31に記載のデバイス。
[C35] 前記ボックスは、スキーム情報を含む第2のボックス中に含まれている第1のボックスであり、前記1つまたは複数のプロセッサは、
前記魚眼ビデオデータのピクチャがリージョンワイズパッキングされているかどうかを示す第3のボックスを、前記第1のボックス中に符号化すること、
を行うようにさらに構成される、C34に記載のデバイス。
[C36] 前記第1のボックスは、SchemeInformationBoxであり、前記第2のボックスは、FisheyeOmnidirectionalVideoBoxであり、および前記第3のボックスは、RegionWisePackingBoxである、C35に記載のデバイス。
[C37] 前記シンタックス構造は、前記魚眼ビデオデータの各ピクチャ中に含まれる円形画像の数を指定する第2のシンタックス要素をさらに含む、C31に記載のデバイス。
[C38] 前記魚眼ビデオデータは、ビデオコーディングレイヤ(VCL)中で符号化され、および前記シンタックス構造は、前記VCLの外部にある、C31に記載のデバイス。