次に、いくつかの実施形態を、添付の図面を参照して以降でより完全に説明するが、本発明のすべてではなく一部の実施形態が示される。実際、本発明の様々な実施形態は、多くの異なる形態として具体化することができ、本明細書で説明される実施形態に限定されると解釈されてはならない。むしろ、これらの実施形態は、本開示が適用可能な法的な要件を満たすべく与えられる。全体を通じて、類似の参照符号は、類似の要素を指す。本明細書で使用される際、用語「データ」、「コンテンツ」、「情報」、および類似の用語は、本発明の実施形態にしたがって、送信、受信、および/または記憶することができるデータを指すために互換的に用いられる場合がある。したがって、あらゆるそのような用語の使用は、本発明の実施形態の思想および範囲を限定するように取られるべきではない。
追加的に、本明細書で使用される際、用語「回路」は、(a)ハードウェアだけの回路実装形態(例えば、アナログ回路および/またはデジタル回路としての実装形態)、(b)回路と、本明細書で説明される1つまたは複数の機能を装置に実施させるように一緒に作動する1つまたは複数のコンピュータ可読メモリに記憶された、ソフトウェアおよび/またはファームウェア命令を含むコンピュータプログラム製品との組み合わせ、ならびに(c)例えばソフトウェアまたはファームウェアが物理的に存在しなくても、動作のためのソフトウェアまたはファームウェアを要求する、マイクロプロセッサまたはマイクロプロセッサの一部などの回路を指す。「回路」のこの定義は、あらゆる特許請求を含む本明細書における本用語のすべての使用に当てはまる。さらなる例として、本明細書で使用される際、用語「回路」は、1つまたは複数のプロセッサおよび/またはその一部、ならびに付随するソフトウェアおよび/またはファームウェアを含む実装形態も含む。別の例として、本明細書で使用される際、用語「回路」には、例えば、携帯電話向けのベースバンド集積回路もしくはアプリケーションプロセッサ集積回路、またはサーバ、セルラネットワークデバイス、他のネットワークデバイス、および/もしくは他のコンピューティングデバイス内の類似の集積回路も含まれる。
本明細書で定義されるように、非一時的な物理記憶媒体を指す(例えば、揮発性または非揮発性のメモリデバイス)「コンピュータ可読記憶媒体」は、電磁気的な信号を指す「コンピュータ可読送信媒体」とは区別することができる。
用語「タイル」と「サブピクチャ」は、互換的に用いられる場合がある。
方法、装置、およびコンピュータプログラム製品は、例示的な実施形態にしたがって提供され、映像エンコーディングにおけるレイトバインディングのためのメカニズムを与える。方法、装置、およびコンピュータプログラム製品は、高効率映像符号化規格(High Efficiency Video Coding standard)(HEVCまたはH.265/HEVC)、高度映像符号化規格(Advanced Video Coding standard)(AVCまたはH.264/AVC)、次世代バーサタイル映像符号化規格(Versatile Video Coding standard)(VVCまたはH.266/VVC)を含む様々な映像形式と併せて、ならびに/または国際標準化機構(ISO)ベースのメディアファイル形式(ISOBMFFと省略される場合があるISO/IEC14496-12)、動画専門家グループ(MPEG)-4ファイル形式(MP4形式としても知られるISO/IEC14496-14)、NAL(ネットワーク抽象化レイヤ)ユニット構造化映像(ISO/IEC14496-15)向けのファイル形式、および第3世代パートナーシッププロジェクト(3GPPファイル形式)(3GP形式としても知られる3GPP技術仕様書26.244)を含む様々な映像およびマルチメディアファイル形式とともに利用することができる。ISOBMFFは、上で言及したすべてのファイル形式の派生のためのベースである。例示的な実施形態を、HEVC、ISOBMFF、およびDASHと併せて説明するが、本開示はHEVC、ISOBMFF、およびDASHに限定されるのではなく、むしろ説明は、本開示の例示的な実施形態が部分的または完全に実現され得る1つの可能な基礎のために与えられる。
本開示のいくつかの態様は、国際標準化機構(ISO)ベースのメディアファイル形式(ISOBMFFと省略される場合があるISO/IEC14496-12)、動画専門家グループ(MPEG)-4ファイル形式(MP4形式としても知られるISO/IEC14496-14)、NAL(ネットワーク抽象化レイヤ)ユニット構造化映像(ISO/IEC14496-15)向けのファイル形式、および第3世代パートナーシッププロジェクト(3GPPファイル形式)(3GP形式としても知られる3GPP技術仕様書26.244)などのコンテナファイル形式に関する。例示的な実施形態が、MPEGまたはその派生物と併せて説明されることがあるが、本開示は、MPEGに限定されるのではなく、むしろ説明は、本開示の例示的な実施形態が部分的または完全に実現され得る1つの可能な基礎のために与えられる。
映像ビットストリームのファイル形式に関わらず、例示的な実施形態の装置は、例えば、映像エンコーダ、映像デコーダ、コンピュータワークステーション、サーバなどを含む、多様なコンピューティングデバイスのいずれかによって、またはモバイル端末、例えばスマートフォン、タブレットコンピュータ、ビデオゲームプレーヤなどの様々なモバイルコンピューティングデバイスのいずれかによって、実現することができる。
装置を具体化するコンピューティングデバイスに関わらず、例示的な実施形態の装置10は、処理回路12、メモリ14、通信インターフェース16、および図1に示されるように任意にユーザインターフェース18を含むか、これらに関連付けられるか、またはこれらと通信する。
処理回路12は、装置10のコンポーネント間で情報を受け渡しするためのバスを介して、メモリデバイス14と通信することができる。メモリデバイスは、非一時的であってもよく、例えば1つまたは複数の揮発性および/または非揮発性のメモリを含む場合がある。換言すると、例えば、メモリデバイスは、マシン(例えば、処理回路のようなコンピューティングデバイス)から取り出すことができるデータ(例えば、ビット)を記憶するように構成されたゲートを含む電子的な記憶デバイス(例えば、コンピュータ可読記憶媒体)であってもよい。メモリデバイスは、装置が本開示の例示的な実施形態にしたがって様々な機能を実行できるようにする、情報、データ、コンテンツ、アプリケーション、命令などを記憶するように構成することができる。例えば、メモリデバイスは、処理回路によって処理するための入力データをバッファリングするように構成することが可能である。追加的に、または代替的に、メモリデバイスは、処理回路による実行用の命令を記憶するように構成される場合がある。
装置10は、いくつかの実施形態では、上述したような様々なコンピューティングデバイスとして具体化することができる。しかしながら、いくつかの実施形態では、装置はチップまたはチップセットとして具体化される場合がある。換言すると、装置は、構造的な組立体(例えば、ベース基板(baseboard))上に材料、コンポーネント、および/または配線を含む1つまたは複数の物理的なパッケージ(例えば、チップ)を含むことができる。構造的な組立体は、そこに含まれるコンポーネント回路に、物理的な強度、大きさの保全、および/または電気的な相互作用の制限を与えることができる。したがって、場合によっては、装置は、単一のチップ上で、または単一の「システムオンチップ」として、本開示の実施形態を実装するように構成される場合がある。そのため、場合によっては、チップまたはチップセットは、本明細書で説明される機能性を提供するための、1つまたは複数の動作を実施するための手段を構成することができる。
処理回路12は、複数の様々な方法で具体化することができる。例えば、処理回路は、コプロセッサ、マイクロプロセッサ、コントローラ、デジタル信号プロセッサ(DSP)、付随的なDSPを伴うもしくは伴わない処理要素などの、様々なハードウェア処理手段、または例えばASIC(特定用途向け集積回路)、FPGA(フィールドプログラマブルゲートアレイ)、マイクロコントローラユニット(MCU)、ハードウェアアクセラレータ、特殊目的コンピュータチップなどの集積回路を含む様々な他の回路のうちの、1つまたは複数として具体化することができる。そのため、いくつかの実施形態では、処理回路は、独立的に実行するように構成された1つまたは複数の処理用コアを含むことができる。マルチコア処理回路は、単一の物理的なパッケージ内でマルチプロセッシングを可能にすることができる。追加的に、または代替的に、処理回路は、命令の独立的な実行、パイプライン処理、および/またはマルチスレッド処理を可能にするようバスを介してタンデム型に構成された1つまたは複数のプロセッサを含むことができる。
例示的な実施形態では、処理回路12は、メモリデバイス14に記憶された、または処理回路からアクセス可能な命令を実行するように構成することができる。追加的に、または代替的に、処理回路は、ハードコーディングされた機能性を実行するように構成することができる。そのため、ハードウェアまたはソフトウェア的な方法によって、またはその組み合わせによって構成されるかどうかに関わらず、処理回路は、しかるべく構成されている間、本開示の実施形態にしたがって動作を実施することが可能な(例えば、回路内で物理的に具体化される)エンティティを表現することができる。したがって、例えば処理回路がASIC、FPGAなどとして具体化される場合、処理回路は、本明細書で説明される動作を行なうように具体的に構成されたハードウェアであり得る。代替的に、別の例として、処理回路が命令の実行体として具体化される場合、命令は、命令が実行されると本明細書で説明されるアルゴリズムおよび/または動作を実施するようプロセッサを具体的に構成することができる。しかしながら、場合によっては、処理回路は、本明細書で説明されるアルゴリズムおよび/または動作を実施するための命令による処理回路のさらなる構成によって本発明の実施形態を採用するように構成された特殊なデバイス(例えば、画像または映像処理システム)のプロセッサである可能性がある。処理回路は、とりわけ、クロック、算術論理ユニット(ALU)および処理回路の演算をサポートするように構成された論理ゲートを含むことができる。
通信インターフェース16は、映像ビットストリームを含むデータを受信および/または送信するように構成された、ハードウェアまたはハードウェアとソフトウェアとの組み合わせのいずれかに具体化される、デバイスまたは回路などのあらゆる手段であってもよい。この点において、通信インターフェースは、例えば、アンテナ(または複数のアンテナ)、ならびに無線通信ネットワークとの通信を可能にするためのサポート用ハードウェアおよび/またはソフトウェアを含むことができる。追加的に、または代替的に、通信インターフェースは、アンテナを介して信号を送信させるために、またはアンテナを介して受信された信号の受け取りを扱うために、アンテナと対話するための回路を含むことができる。いくつかの環境では、通信インターフェースは、代替的に、またはその上、有線通信をサポートすることができる。そのために、例えば通信インターフェースは、ケーブル、デジタル加入者線(DSL)、ユニバーサルシリアルバス(USB)または他のメカニズムを介した通信をサポートするために、通信モデムおよび/または他のハードウェア/ソフトウェアを含むことができる。
装置10が映像ビットストリームをエンコードするように構成される事例などの、いくつかの実施形態では、装置10は、今度はエンコードされた映像ビットストリームを出力することなどによって、出力をユーザに与えるために、またいくつかの実施形態では、ユーザ入力のインジケーションを受信するために、次に処理回路12と通信することができるユーザインターフェース18を含んでもよい。そのために、ユーザインターフェースは、ディスプレイを含む場合があり、いくつかの実施形態では、キーボード、マウス、ジョイスティック、タッチスクリーン、タッチエリア、ソフトキー、マイクロフォン、スピーカ、または他の入力/出力メカニズムを含むこともできる。代替的に、または追加的に、処理回路は、ディスプレイ、およびいくつかの実施形態では、スピーカ、リンガ、マイクロフォンなどの、1つまたは複数のユーザインターフェース要素のうちの少なくともいくつかの機能を制御するように構成されたユーザインターフェース回路を含むことができる。処理回路および/または処理回路を含むユーザインターフェース回路は、処理回路からアクセス可能なメモリ(例えば、メモリデバイス14など)に記憶されたコンピュータプログラム命令を通じて(例えば、ソフトウェアおよび/またはファームウェア)1つまたは複数のユーザインターフェース要素のうちの1つまたは複数の機能を制御するように構成することができる。
特定の例示的な実施形態を説明する際、シンタックス構造のシノニムとして、またはシンタックス構造の一例として、用語ファイルが時々使用される。他のコンテキストでは、用語ファイルは、記憶装置内でスタンドアロンのユニットを形成するリソースであるコンピュータファイルを意味するために用いられる場合がある。
様々なシンタックスを説明する場合、また特定の例示的な実施形態では、シンタックス構造は、以下で説明されるように指定することができる。中括弧で囲まれるステートメントのグループは、複合ステートメントであり、機能的に単一のステートメントとして扱われる。「while」構造は、条件が真であるかどうかのテストを指定しており、真であるならば、条件が真でなくなるまで、ステートメント(または複合ステートメント)の評価を反復して指定する。「do...while」構造は、ステートメントの評価を一度だけ指定し、次に条件が真であるかどうかをテストし、真であるならば、条件が真でなくなるまでステートメントの反復評価を指定する。「if...else」構造は、条件が真であるかどうかのテストを指定し、条件が真であるならば、主なステートメントの評価を指定し、それ以外は代替的なステートメントの評価を指定する。構造の「else」部分および関連付けられる代替的なステートメントは、代替的なステートメント評価が必要ではない場合、省略される。「for」構造は、最初のステートメントの評価を指定して、次に条件をテストして、条件が真であるならば、主なステートメントの反復評価を指定し、次に条件が真でなくなるまで後続のステートメントの評価をする。
H.264/AVCでは、マクロブロックはルマ(luma)サンプルの16×16ブロック、および対応するクロマ(chroma)サンプルのブロックである。例えば、4:2:0のサンプリングパターンでは、マクロブロックはクロマコンポーネント1つ当たり、8×8ブロックのクロマサンプルを1つ含んでいる。H.264/AVCでは、ピクチャは1つまたは複数のスライスグループにパーティショニングされ、スライスグループは、1つまたは複数のスライスを含む。H.264/AVCでは、スライスは、特定のスライスグループ内でラスタスキャンとして連続的に並べられた、整数の数のマクロブロックを含むことができる。
映像エンコーディングおよび/または復号化の動作を説明する際、以下の用語が用いられる場合がある。符号化ブロックは、符号化ツリーブロックの符号化ブロックへの分割がパーティショニングとなるように、何らかのNの値に対するN×Nのサンプルのブロックとして定義することができる。符号化ツリーブロック(CTB)は、コンポーネントの符号化ツリーブロックへの分割がパーティショニングとなるように、何らかのNの値に対するN×Nのサンプルのブロックとして定義することができる。符号化ツリーユニット(CTU)は、ルマサンプルの符号化ツリーブロック、3つのサンプルアレイを有するピクチャのクロマサンプルの2つの対応する符号化ツリーブロック、またはモノクロームピクチャもしくは3つの別個の色プレーンとサンプルを符号化するために使用されたシンタックス構造とを用いて符号化されたピクチャのサンプルの符号化ツリーブロックとして定義することができる。符号化ユニット(CU)は、ルマサンプルの符号化ブロック、3つのサンプルアレイを有するピクチャのクロマサンプルの2つの対応する符号化ブロック、またはモノクロームピクチャもしくは3つの別個の色プレーンとサンプルを符号化するために使用されたシンタックス構造とを用いて符号化されたピクチャのサンプルの符号化ブロックとして定義することができる。
高効率映像符号化(HEVC)コーデックなどの、一部の映像コーデックでは、映像ピクチャは、ピクチャのエリアをカバーする符号化ユニット(CU)に分割される。CUは、CU内のサンプルに対する予測プロセスを定義する1つまたは複数の予測ユニット(PU)、およびCU内のサンプルに対して予測誤差符号化プロセスを定義する1つまたは複数の変換ユニット(TU)から構成される。典型的には、CUは、可能CUサイズの所定のセットからサイズを選択可能な正方形のサンプルのブロックから構成される。可能な最大のサイズのCUは、LCU(最大符号化ユニット)または符号化ツリーユニット(CTU)と呼ぶことができ、映像ピクチャはオーバラップしないLCUに分割される。LCUは、例えばLCUおよび得られるCUを再帰的に分けることにより、より小さなCUの組み合わせにさらに分けることができる。得られる各CUは、典型的には少なくとも1つのPUおよびそれに関連付けられる少なくとも1つのTUを有する。各PUおよびTUは、予測の粒度および予測誤差符号化プロセスをそれぞれ向上させるために、より小さなPUおよびTUにさらに分けることができる。各PUは、どの種類の予測がPU内のピクセルに適用されるかを定義する、関連付けられた予測情報(例えば、インター予測されたPUについての動きベクトル情報、およびイントラ予測されたPUについてのイントラ予測方向性情報)を有する。
画像は、独立的に符号化可能および復号化可能な画像セグメントに分けることができ(例えば、スライス、またはタイル、またはタイルグループ)、これらは独立的に符号化されたピクチャ領域と称される場合もある。そのような画像セグメントは、並列処理を可能とすることができ、本説明における「スライス」は、デフォルトの符号化順または復号順で処理された特定数の基本符号化ユニットから構成された画像セグメントを称することがあり、一方で「タイル」は、矩形の画像領域として定義されてある画像セグメントを称する場合がある。タイルグループは、1つまたは複数のタイルのグループとして定義することができる。画像セグメントは、H.264/AVCおよびHEVCにおけるVCL NALユニットなどの、ビットストリーム内の別個のユニットとして符号化することができる。符号化された画像セグメントは、ヘッダおよびペイロードを含むことができ、ヘッダにはペイロードを復号化するために必要なパラメータ値が含まれる。
各TUは、前記TU内のサンプルについて予測誤差復号化プロセスを記述する情報に関連付けられる可能性がある(例えば、離散コサイン変換係数情報を含んでいる)。典型的には、各CUに予測誤差符号化が適用されるかどうかは、CUレベルでシグナリングされる。CUに関連付けられる予測誤差残差がない場合、前記CUについてTUは存在しないと考えることが可能である。画像のCUへの分割、およびCUのPUとTUへの分割は、典型的にはビットストリーム内でシグナリングされ、デコーダがこれらのユニットの意図された構造を再現できるようにしている。
HEVC規格では、ピクチャは、矩形で整数個のCTUを含むタイルにパーティショニングすることができる。HEVC規格では、タイルへのパーティショニングは、(CTUにおける)タイル列幅のリストと(CTUにおける)タイル行高さのリストによって特徴付けることができるグリッドを形成する。タイルは、ビットストリーム内で連続的に、タイルグリッドのラスタスキャン順に並んでいる。タイルは、整数個のスライスを含むことができる。
HEVCでは、スライスは、整数個のCTUを含むことができる。CTUは、タイル内で、またはタイルが使用されていない場合はピクチャ内で、CTUのラスタスキャン順でスキャンされる。スライスは、整数個のタイルを含むことができ、スライスはタイル内に含まれることが可能である。CTU内では、CUは特定の定義されたスキャン順を有する。
HEVCでは、スライスは、1つの独立的なスライスセグメントおよび同一のアクセス単位内の次の独立的なスライスセグメント(もしあれば)に先行するすべての後続の依存的なスライスセグメント(もしあれば)に含まれる整数個の符号化ツリーユニットとして定義される。HEVCでは、スライスセグメントは、タイルスキャンにおいて連続的に並べられ、単一のネットワーク抽象レイヤ(NAL)ユニットに含まれる、整数個の符号化ツリーユニットとなるように定義される。各ピクチャのスライスセグメントへの分割が、パーティショニングである。HEVCでは、独立的なスライスセグメントは、スライスセグメントヘッダのシンタックスエレメントの値が先行するスライスセグメント用の値から推測されないスライスセグメントとなるように定義され、依存的なスライスセグメントは、スライスセグメントヘッダの何らかのシンタックスエレメントの値が復号化順で先行する独立的なスライスセグメント用の値から推論されるスライスセグメントとなるように定義される。HEVCでは、スライスヘッダは、現在のスライスセグメントであるか、現在の依存的なスライスセグメントに先行する独立的なスライスセグメントである、独立的なスライスセグメントのスライスセグメントヘッダとなるように定義され、スライスセグメントヘッダは、スライスセグメントで表現される第1のまたはすべての符号化ツリーユニットに関連するデータ要素を含む符号化されたスライスセグメントの一部となるように定義される。CUは、タイル内で、またはタイルが使用されていない場合はピクチャ内で、LCUのラスタスキャン順にスキャンされる。LCU内では、CUは特定のスキャン順を有する。
H.266/VVCのドラフト版では、ピクチャはタイルグリッドに沿ってタイルにパーティショニングされる(HEVCに類似している)。2タイプのタイルグループ、すなわちラスタスキャン順タイルグループおよび矩形タイルグループが指定され、エンコーダはビットストリーム、例えばPPSにおいて、どのタイプのタイルグループが使用されているかを示すことができる。ラスタスキャン順タイルグループでは、タイルはビットストリーム内で、ピクチャ内のタイルラスタスキャン順で並んでおり、CTUはビットストリーム内で、タイル内のラスタスキャン順で並んでいる。矩形タイルグループでは、ピクチャは矩形タイルグループにパーティショニングされており、タイルはビットストリーム内で、各タイルグループ内のラスタスキャン順で並んでおり、CTUはビットストリーム内で、タイル内のラスタスキャン順で並んでいる。タイルグループのタイプに関わらず、タイルグループは、1つまたは複数のタイル全体をビットストリーム順で含み、VCL NALユニットは1つのタイルグループを含む。スライスは、H.266/VVCのドラフト版には含まれてこなかった。本パラグラフで説明したことは、規格が最終化されるまで、H.266/VVCの新しいドラフト版においてさらに発展する可能性があることに留意されたい。
H.264/高度映像符号化(AVC)またはHEVCエンコーダの出力用、およびH.264/AVCまたはHEVCデコーダの入力用の基本ユニットは、それぞれ、NALユニットである。パケット指向ネットワーク上でのトランスポートまたは構造化ファイルへの記憶向けに、NALユニットは、パケットまたは類似の構造物にカプセル化される場合がある。ISOベースのメディアファイル形式では、アクセス単位のNALユニットは、サンプルを形成し、そのサイズはファイル形式メタデータ内で提供される。
バイトストリーム形式は、フレーミング構造を与えない送信または記憶環境向けに、H.264/AVCおよびHEVCで指定されてきた。バイトストリーム形式は、各NALユニットの前方に開始コードを付加することによってNALユニットを互いに別個にする。NALユニット境界の偽検出を回避するために、エンコーダは、バイト指向の開始コードエミュレーション防止アルゴリズムを実行し、このアルゴリズムは、それ以外では開始コードが生じるであろうNALユニットペイロードに、エミュレーション防止バイトを追加する。パケット指向とストリーム指向のシステム同士で単純なゲートウェイ操作を可能にするために、バイトストリーム形式が使用されているかどうかに関わらず、開始コードエミュレーション防止は、いつも実施され得る。NALユニットは、したがうデータのタイプのインジケーションを含むシンタックス構造、および必要であればエミュレーション防止バイトで分断されたローバイトシーケンスペイロード(RBSP)の形式でそのデータを含むバイトとして定義することができる。RBSPは、NALユニットにカプセル化された整数個のバイトを含むシンタックス構造として定義することができる。
HEVCおよびVVCに関連する例示的な実施形態を説明する際、各シンタックスエレメントの解析プロセスを指定するために、以下の説明が使用される場合がある。
u(n):nビットを使用する符号なし整数。nがシンタックステーブルで「v」である場合、他のシンタックスエレメントの値に応じたやり方でビット数は変動する。この記述子用のペアリングプロセスは、最初に最上位ビットが書き込まれる符号なし整数のバイナリ表現として解釈されるビットストリームの次のnビットによって指定される。
ue(v):左ビットが最初の符号なし整数の指数ゴロム符号化シンタックスエレメント。
HEVCにおける例示的なスライスセグメントレイヤローバイトシーケンスペイロード(RBSP)は、以下のように与えられる:
slice_segment_header()は、次のシンタックスの形態を取ることができる:
first_slice_segment_in_pic_flagおよびslice_segment_addressは、ピクチャ内のスライスセグメントの位置に依存するが、他のシンタックスエレメントの値は、同一の符号化されたピクチャのすべての独立的なスライスセグメントにおいて何回もは変わらない。
ビットストリームは、何らかの符号化形式または規格においてNALユニットストリームまたはバイトストリームの形態であり得るビットのシーケンスとして定義することができ、符号化されたピクチャの表現および1つまたは複数の符号化された映像シーケンスを形成する関連付けられたデータを形成する。最初のビットストリームには、同一のファイル内または通信プロトコルの同一の接続内など、同一の論理チャネル内の第2のビットストリームが続く可能性がある。(映像符号化のコンテキストでは)基本的なストリームは、1つまたは複数のビットストリームのシーケンスとして定義することができる。一部の符号化形式または規格では、第1のビットストリームの最後は、ビットストリーム終端(EOB)NALユニットと称され得る特定のNALユニットによって示される場合があり、これはビットストリームの最後のNALユニットである。
ビットストリームに沿って(例えば、ビットストリームに伴うことを示す)という言い回し、またはビットストリームの符号化されたユニットに沿って(例えば、符号化されたタイルに伴うことを示す)という言い回しは、「アウトオブバンド」データが関連付けられるが、ビットストリーム内または符号化されたユニット内にはそれぞれ含まれないやり方で、送信、シグナリング、または記憶を指すために、特許請求の範囲および説明される実施形態で使用される場合がある。ビットストリームに沿った復号化という言い回し、またはビットストリームの符号化されたユニットに沿った復号化という言い回しなどは、ビットストリームまたは符号化されたユニットにそれぞれ関連付けられる参照されたアウトオブバンドデータ(アウトオブバンドの送信、シグナリング、または記憶から取得することができる)を復号化することを指す場合がある。例えば、ビットストリームに沿ってという言い回しは、ビットストリームが、ISO Base Media File Formatに準拠しているファイルなどのコンテナファイルに含まれる場合に使用される場合があり、特定ファイルのメタデータは、ビットストリームを含むトラック用のサンプルエントリ内のボックス、ビットストリームを含むトラック用のサンプルグループ、またはビットストリームを含むトラックに関連付けられた時間決めされたメタデータトラックなど、メタデータをビットストリームに関連付けるやり方で、そのファイルに記憶される。
イントラランダムアクセスポイント(IRAP)ピクチャとも称され得るランダムアクセスポイント(RAP)ピクチャまたはランダムアクセスピクチャは、イントラ符号化された画像セグメントのみを含むことができる。さらには、RAPピクチャは、復号化順のRAPピクチャに先行するあらゆるピクチャの復号化プロセスを実施することなく正しく復号化することができるように、出力順のサブシーケンスピクチャを制約する場合がある。
動き制約タイルセット(MCTS)は、インター予測プロセスがエンコーディングにおいて制約されるタイルセットである。以下の制限が適用される場合がある:動き制約タイルセットの外部のサンプル値、および動き制約タイルセットの外部の1つまたは複数のサンプル値を使用して導出したフラクショナルなサンプル位置におけるサンプル値は、動き制約タイルセット内のいかなるサンプルのインター予測にも使用されない。追加的に、MCTSのエンコーディングは、MCTSの外部のブロックから導出された変数およびいかなる復号化結果も、MCTS内のいかなる復号化プロセスに使用されないやり方で制約される。例えば、MCTSのエンコーディングは、動きベクトル候補がMCTSの外部のブロックから導出されないやり方で、制約される。これは、HEVCの時間動きベクトル予測をオフにすることによって、あるいはTMVP候補またはマージ内のTMVP候補もしくはMCTSの右下の最後の1つを除くMCTSの右のタイル境界のすぐ左に配置されたPUについてのAMVP候補リストにしたがうあらゆる動きベクトル予測候補を、エンコーダが使用することを不許可にすることによって、強制することができる。一般に、MCTSは、MCTSの外部にある動きベクトルなどの、いかなるサンプル値および符号化されたデータとも無関係なタイルセットとなるように定義することができる。MCTSシーケンスは、1つまたは複数の符号化された映像シーケンスなどにおける個々のMCTSのシーケンスとして定義することができる。場合によっては、MCTSは矩形面積を形成するよう要求される場合がある。コンテキストに応じて、MCTSはピクチャ内のタイルセット、またはピクチャのシーケンス内の個々のタイルセットを指す可能性があることを理解されたい。一般的には必要とされないが、個々のタイルセットはピクチャのシーケンス内にコロケートされてもよい。動き制約タイルセットは、他のタイルセットなしに復号化することができるため、独立的に符号化されたタイルセットとして考えることができる。
インター予測で使用されるサンプル場所は、飽和している場合がある。結果として、それ以外でピクチャの外部となる場所は、ピクチャの対応する境界サンプルをポイントするために飽和する。したがって、タイル境界がやはりピクチャ境界である場合、動きベクトルは事実上その境界を横切ることができるか、または、サンプル場所が境界に対して飽和しているため動きベクトルはその境界外部の場所を参照する可能性があるフラクショナルなサンプル補間を事実上生じさせることができる。HEVCの時間動き制約タイルセット補助強化情報(SEI)メッセージを使用して、ビットストリーム内の動き制約タイルセットの存在を示すことができる。
360度映像または仮想現実(VR)映像は、一般的に典型的な表示構成では、単一の時間ポイントにおいて映像の一部のみが表示されるような広い視野(FOV)を与える映像コンテンツを称する。例えば、VR映像は、例えば約100度の視野を表示することが可能な頭部装着型ディスプレイ(HMD)で視聴することができる。表示されるVR映像コンテンツの空間的なサブセットは、HMDの向きに基づいて選択することができる。別の例では、典型的なフラットパネル視聴環境が想定され、この場合例えば最大40度の視野を表示することができる。そのようなディスプレイでワイドFOVコンテンツ(例えば、魚眼)を表示する場合、ピクチャ全体ではなく空間サブセットが表示されることがある。VR映像取得、エンコーディング、および再生の例示的なプロセスを、図2Aに図示する。
現実世界の音声-視覚シーン(A)が、20で図示されるように、音声センサおよびカメラのセット、または複数のレンズとセンサを備えるカメラデバイスによってキャプチャされる。取得により、デジタル画像/映像(Bi)および音声(Ba)信号のセットが得られる。カメラ/レンズは、カメラセットまたはカメラデバイスの中心周りのすべての方向をカバーすることができる。音声は、様々なマイクロフォン構成を使用してキャプチャされ、チャネルベース信号、静的または動的(例えば、3Dシーンを通って動く)なオブジェクト信号、およびシーンベース信号(例えば、高次アンビソニクス)を含む、様々な異なるコンテンツ形式として記憶することができる。チャネルベースの信号は、典型的にはCoding Independent Code Point(CICP)で定義される拡声器レイアウトのうちの1つに準拠している。全指向性メディア用途では、レンダリングされた没入型音声プログラムの拡声器レイアウト信号は、ヘッドフォンを介した提示用にバイノーラル化することができる。同じ瞬間の画像(Bi)を、パックされたピクチャ(D)に対して、スティッチング、投影、およびマッピングすることができる。
モノスコピックな360度映像では、22に図示されるように、ある瞬間の入力画像が、1つのビューを表現する投影ピクチャを生成するようスティッチングされる。モノスコピックなコンテンツ向けの画像のスティッチング、投影、および領域単位パッキングプロセスのブレイクダウンを図2Bに図示する。入力画像(Bi)は、例えば単位球面であり得る三次元投影構造に対して、スティッチングされ、投影される。投影構造は、平面またはその一部などの、1つまたは複数の表面を含むと考えることができる。投影構造は、キャプチャされたVR画像/映像コンテンツが投影され、各投影ピクチャを形成することができる、1つまたは複数の表面から成る三次元構造として定義することができる。投影構造上の画像データは、二次元投影ピクチャ(C)にさらに配置構成される。投影という用語は、入力画像のセットを投影フレームに投影するプロセスとして定義することができる。例えば正距円筒図法投影(ERP)形式およびキューブマップ投影(CMP)形式を含む、予め定義された投影ピクチャの表現形式のセットがあってもよい。投影ピクチャは球面全体をカバーすると考えることができる。
領域単位パッキングが、投影ピクチャをパックされたピクチャにマッピングするために適用されてもよい。領域単位パッキングが適用されない場合、パックされたピクチャは投影ピクチャと同一であり、投影ピクチャが、画像/映像エンコーディングへの入力として与えられる。領域単位パッキングが適用される場合、投影ピクチャの領域は、パックされたピクチャにおける各領域の場所、形状、およびサイズを示すことによってパックされたピクチャ(D)にマッピングされ、パックされたピクチャ(D)が、画像/映像エンコーディングへの入力として与えられる。領域単位パッキングは、投影ピクチャをパックされたピクチャにマッピングするプロセスを指す。パックされたピクチャは、投影ピクチャの領域単位パッキングから得られるピクチャを指す。
インター予測で使用されるサンプル場所は、飽和している場合がある。結果として、それ以外でピクチャの外部となる場所は、ピクチャの対応する境界サンプルをポイントするために飽和する。したがって、いくつかの事例では、タイル境界がやはりピクチャ境界である場合、動きベクトルは事実上その境界を横切ることができるか、または、サンプル場所が境界に対して飽和しているため動きベクトルはその境界外部の場所を参照する可能性があるフラクショナルなサンプル補間を事実上生じさせることができる。他の事例では、具体的に符号化されたタイルを、ピクチャ境界に隣接する位置にあるビットストリームから、タイルがピクチャ境界に隣接していない位置にある別のビットストリームに抽出することができる場合、エンコーダは、動きベクトルを任意のMCTS境界同様にピクチャ境界に制約することができる。HEVCの時間動き制約タイルセット補助強化情報(SEI)メッセージを使用して、ビットストリーム内の動き制約タイルセットの存在を示すことができる。
ISOBMFFの一部の概念、構造、および仕様を、それに基づいて実施形態を実施することができるコンテナファイル形式の例として、以下で説明する。本発明の態様は、ISOBMFFに限定されるのではなく、説明は、本発明が部分的または完全に実現され得る1つの可能な基礎のために与えられる。
ISOベースのメディアファイル形式における基本的なビルディングブロックを、ボックスと呼ぶ。各ボックスは、ヘッダおよびペイロードを有する。ボックスヘッダは、ボックスのタイプ、およびボックスのサイズをバイトとして示す。ボックスは、他のボックスを包み込むことができ、ISOBMFFは特定のタイプのボックス内で、どのボックスタイプが許容されるか指定する。さらには、いくつかのボックスの存在は、各ファイルで必須である場合がある一方で、他のボックスの存在は任意選択であってもよい。追加的に、一部のボックスタイプでは、2つ以上のボックスが1つのファイルに存在することが許可可能であってもよい。したがって、ISOベースのメディアファイル形式は、ボックスの階層構造を指定すると考えることができる。
ISOBMFFによると、ファイルは、ボックスにカプセル化されたメディアデータおよびメタデータを含む。それぞれのボックスは、4つの文字コード(4CC)によって識別され、ボックスのタイプおよびサイズについて知らせるヘッダから始まる。
ISOベースのメディアファイル形式に準拠するファイルでは、メディアデータはメディアデータ「mdat」ボックス(別名、MediaDataBox)内で与えられ、動画「moov」ボックス(別名、MovieBox)を使用してメタデータを包み込むことができる。場合によっては、動作可能となるファイルには、「mdat」および「moov」の両方のボックスが存在することが要求される場合がある。動画「moov」ボックスは、1つまたは複数のトラックを含むことができ、それぞれのトラックは、1つの対応するTrackBox(「trak」)に存在することができる。トラックは、メディア圧縮形式(およびISOベースのメディアファイル形式への、そのカプセル化)にしたがってフォーマットされたサンプルを参照するメディアトラックを含む多くのタイプのうちの1つであってもよい。トラックは、論理チャネルとして考えることができる。
動画フラグメントは、例えばストリーミング配信もしくはメディアコンテンツのプログレッシブダウンロード用に、または例えば記録アプリケーションがクラッシュした場合、メモリ空間が不足した場合、もしくは何らかの他のインシデントが生じた場合に、データの損失を回避するためにコンテンツをISOBMFFファイルに記録する際に、使用することができる。動画フラグメントがない場合、ファイル形式がすべてのメタデータ、例えば動画ボックスがファイルの1つの隣接するエリアに書き込まれることを必要とする可能性があるため、データ損失が生じる可能性がある。さらには、ファイルを記録する際、利用可能な記憶サイズの動画ボックスをバッファリングするために十分なメモリ空間(例えば、ランダムアクセスメモリRAM)がない可能性があり、動画が閉じられた時に動画ボックスのコンテンツを再計算することが遅くなりすぎる場合がある。その上、動画フラグメントは、通常のISOBMFFファイルパーサを使用して、ファイルの同時的な記録および再生を可能にすることができる。さらには、プログレッシブダウンロードでは、必要とされる初期バッファリングが、より短い持続時間である可能性があり、例えば動画フラグメントが使用され、かつ初期動画ボックスが同一のメディアコンテンツを有するが動画フラグメントなしに構築されたファイルに比べて小さい場合の、ファイルの同時的な受信および再生である。
動画フラグメント特徴により、そうでなければ動画ボックスに存在し得るメタデータを、複数のピースに分けられるようになる可能性がある。それぞれのピースは、トラックの特定の期間に対応することができる。換言すると、動画フラグメント特徴により、ファイルメタデータおよびメディアデータをインターリーブできるようにすることが可能である。結果的に、動画ボックスのサイズを限定することができ、上述の事例が実現される。
いくつかの例では、動画フラグメント用のメディアサンプルは、moovボックスと同じファイルにある場合、mdatボックス内に存在する可能性がある。しかしながら、動画フラグメントのメタデータには、moofボックスが用意される場合がある。moofボックスは、以前はmoovボックス内にあった再生時間の特定の持続時間の情報を含む場合がある。moovボックスは、それ自体の有効な動画をさらに表現することができるが、それに加えて、動画フラグメントが同一のファイル内で続くことを示すmvexボックス(別名、MovieExtendsBox)を含むことができる。動画フラグメントは、moovボックスに関連付けられた提示を時間的に延ばすことができる。
動画フラグメント内には、トラックごとにゼロから複数までのどこかを含むトラックフラグメントのセットがある可能性がある。次いで、トラックフラグメントは、トラックラン(別名、トラックフラグメントラン)のゼロから複数までのどこかを含み得、そのドキュメントのそれぞれは、そのトラックのためのサンプルの隣接するランである。これらの構造内では、多くのフィールドが任意選択であり、また、デフォルト化することが可能である。moofボックスに含まれ得るメタデータは、moovボックスに含まれる可能性があり場合によっては、様々に符号化され得るメタデータのサブセットに限定される場合がある。moofボックスに含むことが可能なボックスに関する詳細は、ISOベースのメディアファイル形式仕様書に見ることができる。内蔵型動画フラグメントは、ファイル順に連続的なmoofボックスおよびmdatボックスで構成されるよう定義することができ、mdatボックスは動画フラグメントのサンプルを含み(このために、moofボックスはメタデータを提供する)、いかなる他の動画フラグメント(つまり、いかなる他のmoofボックス)のサンプルも含まない。
トラック参照メカニズムを使用してトラックを互いに関連付けることができる。TrackReferenceBoxは、ボックスを含み、そのそれぞれは含んでいるトラックから他のトラックのセットへの参照を提供する。これらの参照は、含まれるボックスのボックスタイプ(つまり、ボックスの4つの文字コード)を通じてラベル付けされる。
TrackBoxに含まれるTrackGroupBoxにより、それぞれのグループが特定の特性を共有するか、またはグループ内のトラックが特定の関係性を有する、トラックのグループのインジケーションが可能となる。ボックスは、ゼロ以上のボックスを含み、特定の特性または関係性が、含まれるボックスのボックスタイプによって示される。含まれるボックスは、トラックが同一のトラックグループに属すると結論付けるために使用することができる識別子を含む。同一のタイプの含まれるボックスをTrackGroupBox内に含み、これらの含まれるボックス内に同一の識別子の値を有するトラックは、同一のトラックグループに属する。
BoxFileIndexBoxは、ISO/IEC23001-14の一部として指定される。BoxFileIndexBoxは、関連付けられるファイルまたはセグメントのボックス階層構造の概要を与える。これは、BoxIndexBoxボックスのセットを含み、そのそれぞれは、1つの上位レベルボックスを記述しており、例えばボックスタイプおよびボックスサイズ(バイトで)を与える。
uniform resource identifier(URI)は、リソースの名前を識別するために使用される文字の文字列として定義することができる。そのような識別情報により、ネットワーク上で特定のプロトコルを使用して、リソースの表現との対話が可能となる。URIは、URI用の具体的なシンタックスおよび関連付けられるプロトコルを指定するスキームを通じて定義される。uniform resource locator(URL)およびuniform resource name(URN)は、URIの形態である。URLは、ウェブリソースを識別して、リソースの表現に作用する、またはリソースの表現を取得する手段を指定するURIとして定義することができ、その主なアクセスメカニズムおよびネットワーク場所の両方を指定する。URNは、特定の名前空間において名前によってリソースを識別するURIとして定義することができる。URNは、リソースの場所、またはどのようにリソースにアクセスするかを示唆することなく、リソースを識別するために使用することができる。
近年、映像ストリーミング用途などにおいて、インターネット上でのリアルタイムのマルチメディアコンテンツの配信にHypertext Transfer Protocol(HTTP)が広く使用されている。User Datagram Protocol(UDP)上でReal-time Transport Protocol(RTP)を使用するのとは異なり、HTTPは構成するのが容易で、典型的にはファイアウォールおよびネットワークアドレス変換器(NAT)を通過するようグラントされており、そのためマルチメディアストリーミング用途にとって魅力的となっている。
Microsoft(登録商標)のSmooth Streaming、Apple(登録商標)のAdaptive HTTP Live StreamingおよびAdobe(登録商標)のDynamic Streamingなどの、HTTP上でのアダプティブストリーミング向けの、いくつかの市販のソリューションが始まっており、同様に標準化プロジェクトが進行中である。最初に、アダプティブHTTPストリーミング(AHS)が、第3世代パートナーシッププロジェクト(3GPP)パケット交換方式ストリーミング(PSS)サービスのリリース9で、標準化された(3GPP TS26.234 Release9:「Transparent end-to-end packet-switched streaming service(PSS);protocols and codecs」)。MPEGは、3GPP AHSリリース9を、MPEG DASH規格(ISO/IEC23009-1:「Dynamic adaptive streaming over HTTP(DASH)-Part1:Media presentation description and segment formats」International Standard,2nd Edition,,2014)の出発点として採用した。3GPPは、MPEGと通信してアダプティブHTTPストリーミングに対して作業を継続し、3GP-DASHを公開した(Dynamic Adaptive Streaming over HTTP;3GPP TS26.247:「Transparent end-to-end packet-switched streaming Service(PSS);Progressive download and dynamic adaptive Streaming over HTTP(3GP-DASH)」。MPEG DASHと3GP-DASHとは、技術上は互いに近いものであるため、DASHと総称される場合がある。DASHの一部の概念、形式、および動作を、実施形態を実装することができる映像ストリーミングシステムの例として、以下で説明する。本発明の態様は、DASHに限定されるのではなく、説明は、本発明が部分的または完全に実現され得る1つの可能な基礎のために与えられる。
DASHでは、マルチメディアコンテンツは、HTTPサーバに記憶することができ、HTTPを使用して配信することができる。コンテンツは、2つの部分としてサーバに記憶することができる:利用可能なコンテンツのマニフェスト、その様々な代替物、そのURLアドレス、および他の特性を記述する、Media Presentation Description(MPD);ならびに実際のマルチメディアビットストリームを、ひと塊の形態で、単一ファイル、または複数ファイルとして含む、セグメント。MDPは、クライアントがHTTP上で動的なアダプティブストリーミングを確立するために必要な情報を提供する。MPDは、GET Segmentリクエストを作成するための、各SegmentのHTTP-uniform resource locator(URL)などの、メディア提示を説明する情報を含む。コンテンツを再生するために、DASHクライアントは、例えばHTTP、電子メール、サムドライブ、ブロードキャスト、または他のトランスポート方法を用いることによって、MPDを取得する場合がある。MPDを解析することによって、DASHクライアントは、プログラムタイミング、メディアコンテンツの可用性、メディアタイプ、解像度、最小および最大帯域幅、ならびにマルチメディアコンポーネントの様々なエンコード済代替物、アクセス性特徴、および必要なデジタル著作権管理(DRM)の存在、ネットワーク上でのメディアコンポーネント場所、ならびに他のコンテンツ特性を認識するようになることが可能である。この情報を用いて、DASHクライアントは適当なエンコード済代替物を選択して、例えばHTTP GETリクエストを使用してセグメントをフェッチすることによってコンテンツのストリーミングを開始することができる。ネットワークのスループット変動を考慮した適当なバッファリングの後、クライアントは後続のセグメントをフェッチし続け、ネットワーク帯域幅変動を監視することもできる。クライアントは、十分なバッファを維持するために、様々な代替物のセグメントをフェッチする(低い、または高いビットレートで)ことによって、利用可能な帯域幅にどのように適合するかを決定することができる。
DASHでは、階層構造的なデータモデルを使用して、メディア提示を次のように構造化する。メディア提示は、1つまたは複数のPeriodのシーケンスから成り、各Periodは1つまたは複数のGroupを含み、各Groupは1つまたは複数のAdaptation Setを含み、各Adaptation Setは1つまたは複数のRepresentationを含み、各Representationは1つまたは複数のSegmentから成る。Representationは、メディアコンテンツまたはそのサブセットの代替的な選択の1つであり、典型的にはエンコーディング選択によって、例えばビットレート、解像度、言語、コーデックなどによって違いがある。Segmentは、特定の持続時間のメディアデータ、および含まれるメディアコンテンツを復号化して提示するためのメタデータを含む。Segmentは、URIによって識別され、典型的にはHTTP GETリクエストによってリクエストされる場合がある。Segmentは、HTTP-URLに関連付けられたデータの単位として定義することができ、MPDによって指定されるバイト範囲に関連付けられてもよい。
DASH MPDは、拡張可能マークアップ言語(XML)に準拠しており、そのためXMLで定義される通りの要素および属性を通じて指定される。
DASHでは、すべての記述子要素は、同じ方法で構造化されており、つまり、スキームを識別するためにURIを与える@schemeIdUri属性、ならびに任意属性@valueおよび任意属性@idを含む。要素のセマンティクスは、採用されるスキームに固有である。スキームを識別するURIは、URNまたはURLであり得る。
DASHでは、独立的な表現は、あらゆる他の表現とは無関係に処理することが可能な表現として定義することができる。独立的な表現は、独立的なビットストリームまたは独立的なビットストリームのレイヤを含むものと理解することができる。依存的な表現は、提示および/または含まれるメディアコンテンツコンポーネントの復号化のために、その相補的な表現からのSegmentが必要となる表現として定義することができる。依存的な表現は、例えばスケーラブルなビットストリームの予測されたレイヤを含むものと理解することができる。相補的な表現は、少なくとも1つの依存的な表現を補完する表現として定義することができる。相補的な表現は、独立的な表現であってもよく、依存的な表現であってもよい。依存的なRepresentationは、@dependencyId属性を含むRepresentation要素によって記述することができる。依存的なRepresentationは、復号化および/または提示のために相補的なRepresentationのセットに依存すること以外は、通常のRepresentationとして考えることができる。@dependencyIdは、すべての相補的なRepresentation、つまりこの依存的なRepresentationに含まれるメディアコンテンツコンポーネントを提示および/または復号化するために必要なRepresentationの@id属性の値を含む。
ISOBMFFのトラック参照は、1対1の様式で@associationIdに与えられるRepresentation@id値のリストにマッピングされるDASH MPDの@associationType属性中の4つの文字コードのリスト内に反映され得る。これらの属性は、メディアRepresentationをメタデータRepresentationにリンクするために使用することができる。
DASHサービスは、オンデマンドのサービスまたはライブサービスとして提供される場合がある。オンデマンドのサービスでは、MPDは静的であり、Media PresentationのすべてのSegmentは、コンテンツプロバイダがMPDを公開する時、既に利用可能である。しかし、ライブサービスでは、MPDによって採用されるSegment URL構築方法に応じて、MPDは静的であってもよく、動的であってもよく、コンテンツが生成されてコンテンツプロバイダによってDASHクライアントに公開されるにつれ、Segmentは継続的に作成される。Segment URL構築方法は、テンプレートベースのSegment URL構築方法またはSegmentリスト生成方法のいずれであってもよい。テンプレートベースのSegment URL構築方法では、DASHクライアントは、Segmentをリクエストする前にMPDを更新することなくSegment URLを構築することができる。Segmentリスト生成方法では、DASHクライアントはSegment URLを得るために更新されたMPDを定期的にダウンロードしなければならない。したがって、ライブサービスでは、テンプレートベースのSegment URL構築方法が、Segmentリスト生成方法より優れている。
Initialization Segmentは、Media Segmentにカプセル化されたメディアストリームを提示するために必要なメタデータを含むSegmentとして定義することができる。ISOBMFFベースのセグメント形式では、Initialization Segmentは、あらゆるサンプル用のメタデータを含まない可能性があるMovie Box(「moov」)を含む場合があり、つまりサンプル用のあらゆるメタデータが「moof」ボックスで提供される。
Media Segmentは、通常速度で一定の持続時間の再生用のメディアデータを含み、そのような持続時間はMedia Segment持続時間またはSegment持続時間と称される。コンテンツ製作者またはサービスプロバイダは、所望のサービスの特性にしたがって、Segment持続時間を選択することができる。例えば、比較的短いSegment持続時間は、短いエンドツーエンドのレイテンシを達成するためにライブサービスで使用される場合がある。その理由としては、SegmentはDASH向けのメディアデータを生成する離散的な単位であるため、Segment持続時間は、典型的にはDASHクライアントに知覚されるエンドツーエンドのレイテンシの下限だからである。コンテンツ生成は、典型的にはメディアデータのSegment全体がサーバに利用可能な様式で行なわれる。さらには、多くのクライアント実装形態は、SegmentをGETリクエストのための単位として使用する。したがって、ライブサービス向けの典型的な構成では、Segmentは、Media Segmentの持続時間全体が利用可能であり、エンコードされてSegmentにカプセル化されている時だけ、DASHクライアントによってリクエストされる可能性がある。オンデマンドのサービス向けでは、Segment持続時間を選択する様々な戦略が使用される場合がある。
Segmentは、例えば、複数の部分としてセグメントのダウンロードを可能にするために、Subsegmentにさらにパーティショニングすることができる。Subsegmentは、完全なアクセス単位を含むことが必要とされる場合がある。Subsegmentは、Segment Indexボックス(別名、SegmentIndexBox、すなわち「sidx」ボックス)によってインデックス付けすることができ、Segment Indexボックスは、Subsegmentごとに提示時間範囲およびバイト範囲をマッピングするための情報を含んでいる。Segment Indexボックスは、その持続時間およびバイトオフセットをシグナリングすることによって、セグメント内のサブセグメントおよびストリームアクセスポイントを記述することもできる。DASHクライアントは、Segment Indexボックスから取得した情報を使用して、バイト範囲HTTPリクエストを使用して特定のSubsegment用のHTTP GETリクエストを作成することができる。比較的長いSegment持続時間が使用される場合、Subsegmentを使用して、ビットレートのアダプテーションに妥当かつ柔軟なHTTPレスポンスのサイズを保つことができる。セグメントのインデックス付け情報は、そのセグメントの初めに単一のボックスに入れるか、またはセグメント中の多数のインデックス付けボックス間に拡散することができる。階層構造的、デイジーチェーン、およびハイブリッド型など、拡散の様々な方法が可能である。この技法は、セグメントの初めに大きなボックスが追加されることを回避することができるため、初期ダウンロード遅延の可能性を防ぐことができる。
SegmentIndexBoxは、次のシンタックスを有することができる:
aligned(8) class SegmentIndexBox extends FullBox(’sidx’,version,0){
unsigned int(32) reference_ID;
unsigned int(32) timescale;
if (version==0){
unsigned int(32) earliest_presentation_time;
unsigned int(32) first_offset;
}
else{
unsigned int(64) earliest_presentation_time;
unsigned int(64) first_offset;
}
unsigned int(16) reserved=0;
unsigned int(16) reference_count;
for(i=1;i<=reference_count;i++)
{
bit(1) reference_type;
unsigned int(31) referenced_size;
unsigned int(32) subsegment_duration;
bit(1) starts_with_SAP;
unsigned int(3) SAP_type;
unsigned int(28) SAP_delta_time;
}
}
SegmentIndexBoxの一部のシンタックスエレメントのセマンティクスは、次のように指定することができる。
reference_type:1にセットされる場合は、参照がSegmentIndexBoxに向いていることを示す;それ以外では、参照はメディアコンテンツを向いている(例えば、ISOBMFFに基づくファイルの場合、MovieFragmentBoxへの参照である);別個のインデックスセグメントが使用される場合、参照タイプ1のエントリは、インデックスセグメント内にあり、参照タイプ0のエントリはメディアファイル内にある。
referenced_size:参照される項目の第1のバイトから、次の参照される項目の第1のバイト、または最終エントリの場合では参照されるものの最後までのバイト距離。
用語Segment Indexは、MPDとは別個の、Media Segment内における時間範囲対バイト範囲マッピングのコンパクトなインデックスとして定義することができる。Segment Indexは、1つまたは複数のSegmentIndexBoxを含むことができる。
表記(Sub)segmentは、SegmentまたはSubsegmentのいずれかを指す。Segment Indexボックスが存在しない場合、表記(Sub)segmentは、Segmentを指す。Segment Indexボックスが存在する場合、表記(Sub)segmentは、例えばクライアントがSegmentベースまたはSubsegmentベースのどちらでリクエストを発行するかどうかに応じて、SegmentまたはSubsegmentを指し得る。
MPEG-DASHは、ISOベースのメディアファイル形式およびMPEG-2 Transport Stream両方のセグメント-コンテナ形式を定義する。他の仕様書は、他のコンテナ形式に基づいてセグメント形式を指定することができる。例えば、Matroskaコンテナファイル形式に基づいたセグメント形式が提案されている。
Sub-Representationは、通常のRepresentationに埋め込まれており、SubRepresentation要素によって記述される。SubRepresentation要素は、Representation要素に含まれる。SubRepresentation要素は、Representationに埋め込まれた1つまたは複数のメディアコンテンツコンポーネントの性質を記述する。例えば、SubRepresentation要素は埋め込まれた音声コンポーネント(例えば、コーデック、サンプリングレートなど)、埋め込まれたサブタイトル(例えば、コーデックなど)の厳密な性質を記述し、または一部の埋め込まれた低品質映像レイヤ(それ以外では、例えば一部の低フレームレートなど)を記述する場合がある。Sub-RepresentationとRepresentationとは、一部の共通属性および要素を共有する。
SubRepresentation要素に@level属性が存在する場合、以下が適用される:
Sub-Representationは、Sub-Representationが含まれるRepresentationの低品質バージョンへアクセスするための機能を与える。この場合、Sub-Representationは、例えば多重化されたRepresentation中の音声トラックを抽出することを可能にするか、または低フレームレートが与えられている場合、効率的な高速転送もしくは巻き戻し動作を可能にすることができる。
HTTPの部分的なGETリクエストを通じて容易にデータへアクセスすることができるように、Initialization Segmentおよび/またはMedia Segmentおよび/またはIndex Segmentは、十分な情報を与える。そのような情報を与えることに対する詳細は、使用中のメディア形式によって定義される。
ISOBMFFセグメントが、Sub-Representationを含むRepresentationに使用される場合、以下が適用される:
Initialization Segmentは、Level Assignmentボックスを含む。
Subsegment Indexボックス(「ssix」)は、Subsegmentごとに存在する。
属性@levelは、記述されるSub-RepresentationがSubsegment Index内で関連付けられるレベルを指定する。Representation、Sub-Representation中、およびLevel Assignment(「leva」)ボックス中の情報は、メディアデータのレベルに対する割り当ての情報を含む。
メディアデータは、各レベルが低レベルと比較して高度化をもたらすような、順序を有するべきである。
@level属性がない場合、SubRepresentation要素は、Representationに埋め込まれたメディアストリームのさらに詳細な説明を与えるために使用されるだけである。
ISOBMFFは、ファイルのサブセットを指定する、いわゆるレベルメカニズムを含む。レベルは、m<=nの時、レベルにnにマッピングされたサンプルがレベルmの任意のサンプルに依存し得るような、依存性階層構造にしたがい、p>nの時、レベルpのいかなるサンプルにも依存しない。例えば、レベルは、時間サブレイヤ(例えば、HEVCのTemporalId)にしたがって指定することができる。レベルは、Movie Extend(「mvex」)ボックスに含まれるLevel Assignment(「leva」)ボックス(別名、LevelAssignmentBox)で報知することができる。レベルは、最初の動画では指定することができない。Level Assignmentボックスが存在する場合、これは最初の動画に続くすべての動画フラグメントに当てはまる。Level Assignmentボックスのコンテキストでは、1つまたは複数のMovie Fragmentボックスおよび関連付けられるMedia Dataボックスで構成されるようにフラクションが定義され、可能性としては最後のMedia Data Boxの最初の部分だけを含む。フラクション内では、レベルごとのデータが隣接して現れる。フラクション内のレベルのデータは、レベル値の昇順に現れる。フラクション内のすべてのデータはレベルに割り振られる。Level Assignmentボックスは、スケーラビリティレイヤまたは時間サブレイヤなどの特徴からレベルへのマッピングを提供する。特徴は、トラック、トラック内のサブトラック、またはトラックのサンプルグルーピングを通じて指定することができる。例えば、Temporal Levelサンプルグルーピングを使用して、HEVC内の時間サブレイヤと等価である、ピクチャの時間レベルへのマッピングを示すことができる。すなわち、特定のTemporalId値のHEVCピクチャは、Temporal Levelサンプルグルーピングを使用して、特定の時間レベルにマッピングすることができる(同じことをすべてのTemporalId値に繰り返すことができる)。この時、Level Assignmentボックスは、レベルに対する示されたマッピングにおけるTemporal Levelサンプルグルーピングを参照することができる。
Subsegment Indexボックス(「ssix」、別名、SubsegmentIndexBox)は、レベル(Level Assignmentボックスによって指定される通り)から、インデックス付けされたサブセグメントのバイト範囲へのマッピングを与える。換言すると、このボックスは、サブセグメント中のデータを、レベルに応じて、部分的なサブセグメントにどのように並べるかについての、コンパクトなインデックスを与える。これによって、クライアントは、サブセグメント中のデータの範囲をダウンロードすることによって、部分的なサブセグメントのデータに容易にアクセスできるようになる。Subsegment Indexボックスが存在する場合、サブセグメント中のそれぞれのバイトが、レベルに割り振られる。範囲がレベル割り振り中のどの情報にも関連付けられていない場合、レベル割り振りに含まれていない、あらゆるレベルを使用することができる。葉サブセグメントだけをインデックス付けする、つまりサブセグメントのみをインデックス付けしてセグメントにはインデックス付けしない、各Segment Indexボックスごとに存在する、0または1のSubsegment Indexボックスがある。もしあれば、Subsegment Indexボックスが、関連付けられるSegment Indexボックスの後の、次のボックスである。Subsegment Indexボックスは、Segment Indexボックスの直前で示されるサブセグメントを詳細に記録する。各レベルは、厳密に1つの\部分的なサブセグメントに割り振ることができる、つまり1レベルのバイト範囲は隣接している。部分的なサブセグメントのレベルは、サブセグメント内で昇順の数字によって割り振られている。つまり、部分的なサブセグメントのサンプルは、同一のサブセグメント中の先行する部分的なサブセグメントのあらゆるサンプルに依存する可能性があるが、その逆はない。例えば、各部分的なサブセグメントは、同一の時間サブレイヤを有するサンプルを含んでおり、部分的なサブセグメントは、サブセグメント内で昇順の時間サブレイヤ順に現れる。部分的なサブセグメントがこの方法でアクセスされる場合、最終的なMedia Dataボックスは不完全である可能性がある。つまり、Media Data Boxの長さインジケーションが存在することを示すよりも少ないデータがアクセスされる。Media Dataボックスの長さは、調節を必要とする場合があり、またはパッディングを使用してもよい。Level Assignment Boxにおけるpadding_flagは、この欠落データがゼロで置換することが可能かどうかを示している。ゼロで置換することができない場合、アクセスされないレベルに割り振られたサンプル用のサンプルデータが存在しない場合、対応が取られるべきである。
DASHは、変動するネットワーク帯域幅に一致するよう、Adaptation Set内の様々なRepresentationにMedia Segmentを動的にリクエストすることによって、レートアダプテーションをサポートする。DASHクライアントがRepresentationを上下に切り替える場合、Representation内の符号化依存性が考慮されなければならない。Representation切り替えは、H.264/AVCなどの映像符号化技法で典型的に使用されるランダムアクセスポイント(RAP)で生じる場合がある。DASHでは、Stream Access Point(SAP)と称される、より一般的な概念が導入され、Representationをアクセスするため、およびRepresentation間の切り替えのために、コーデック独立的なソリューションを提供する。DASHでは、SAPが、その位置から前方に開始するRepresentationデータ(もしあれば、Initialisation Segment中のデータを初期化することが先行する)に含まれる情報だけを使用してメディアストリームの再生を開始することができるRepresentation中の位置として指定される。したがって、Representation切り替えは、SAPで実施することが可能である。
DASHでは、同一のAdaptation Set内でのRepresentation間の自動選択は、幅および高さ(@widthおよび@height);フレームレート(@frameRate);ビットレート(@bandwidth);Representation間の示される品質順(@qualityRanking)に基づいて実施されてきた。@qualityRankingのセマンティクスは、以下のように指定される:同一のAdaptation Set内の他のRepresentationに対して、Representationの品質ランキングを指定する。値が低いほど、コンテンツの品質が高いことを表現する。@qualityRankingが存在しない場合、ランキングが定義されない。
いくつかのタイプのSAPが指定されており、以下を含む。SAP Type1は、一部の符号化スキームで「Closed GOPランダムアクセスポイント」(この場合、復号化順のすべてのピクチャは、正しく復号化することが可能であり、ギャップのない正しく復号化されたピクチャの連続的な時間シーケンスとなる)として既知のタイプに相当し、加えて、復号化順で第1のピクチャは、提示順の第1のピクチャでもある。SAP Type2は、一部の符号化スキームで「Closed GOPランダムアクセスポイント」(この場合、復号化順のすべてのピクチャは、正しく復号化することが可能であり、ギャップのない正しく復号化されたピクチャの連続的な時間シーケンスとなる)として既知のタイプに相当し、この時、復号化順で第1のピクチャは、提示順の第1のピクチャにならない可能性がある。SAP Type3は、一部の符号化スキームで「Open GOPランダムアクセスポイント」として既知のタイプに相当し、この場合、正しく復号化することができず、SAPに関連付けられるイントラ符号化されたピクチャよりも短い提示時間を有するいくつかのピクチャが復号化順で存在する可能性がある。
MPEG-2などの一部の映像符号化規格では、各イントラピクチャは符号化されたシーケンス内のランダムアクセスポイントであった。H.264/AVCおよびH.265/HEVCなどの一部の映像符号化規格でのインター予測向けの複数の参照ピクチャの、柔軟な使用の機能の結果、イントラピクチャがランダムアクセスには十分ではない可能性がある。したがって、ピクチャは、そのランダムアクセスポイント機能性に関して、そのような機能性を符号化タイプから推論するのではなく、マーク付けすることができる。例えば、H.264/AVC規格で指定されるようなIDRピクチャは、ランダムアクセスポイントとして使用することができる。クローズドなピクチャのグループ(GOP)は、すべてのピクチャが正しく復号化することができるようなピクチャのグループである。例えば、H.264/AVCでは、クローズドGOPは、IDRアクセス単位から開始することができる。
オープンなピクチャのグループ(GOP)は、出力順で最初のイントラピクチャに先行するピクチャは正しく復号化可能ではない場合があるが、出力順で最初のイントラピクチャに続くピクチャは正しく復号化可能であるような、ピクチャのグループである。そのような最初のイントラピクチャは、ビットストリーム内で示される可能性がある、および/またはビットストリームからのインジケーションから、例えばHEVCにおけるCRA NALユニットタイプを使用して結論付けることができる。オープンGOPを出力順で開始する最初のイントラピクチャに先行し、復号化順で最初のイントラピクチャに続くピクチャは、リーディングピクチャと称される場合がある。2つのタイプのリーディングピクチャがある:復号化可能、および非復号化可能。HEVCのRADLピクチャなどの復号化可能なリーディングピクチャは、オープンGOPを開始する最初のイントラピクチャから復号化が開始された時に、正しく復号化することができるようなピクチャである。換言すると、復号化可能なリーディングピクチャは、最初のイントラピクチャまたは復号化順で後続のピクチャだけを、インター予測における参照として使用する。HEVCのRASLピクチャなどの非復号化可能なリーディングピクチャは、オープンGOPを開始する最初のイントラピクチャから復号化が開始された時に、正しく復号化することができないようなピクチャである。
DASH Preselectionは、単一のデコーダインスタンスによって併せて消費されると期待されるMPDのメディアコンポーネントのサブセットを定義しており、消費することには復号化およびレンダリングが含まれる場合がある。Preselection用のメインのメディアコンポーネントを含むAdaptation Setは、メインAdaptation Setと称される。加えて、それぞれのPreselectionは、1つまたは複数の部分的なAdaptation Setを含むことができる。部分的なAdaptation Setは、メインAdaptation Setと組み合わせて処理する必要がある場合がある。メインAdaptation Setおよび部分的なAdaptation Setは、次の2つの手段のうちの1つによって示すことができる:事前選択記述子、またはPreselection要素。
360度映像では、ある瞬間の入力画像が、それぞれの目に1つずつ、2つのビューを表現する投影ピクチャを生成するようスティッチングされる。両方のビューは、同一のパックされたピクチャにマッピングし、従来的な2D映像エンコーダによってエンコードすることができる。図2Cは、360度映像向けの、エンコードプロセスを図示している。代替的に、投影ピクチャのそれぞれのビューを、それ自身のパックされたピクチャにマッピングしてもよく、その場合、画像のスティッチング、投影、および領域単位パッキングは、図2Bに図示したプロセスと類似したやり方で実施することができる。左のビューまたは右のビューのいずれかのパックされたピクチャのシーケンスは、独立的に符号化することができる、またはマルチビューの映像エンコーダを使用する場合、他のビューに基づいて予測することができる。
画像のスティッチング、投影、および領域単位パッキングのプロセスは、同一コンテンツの異なるバージョン、例えば投影構造の異なる向きを作成するために、同一のソース画像に対して複数回行なわれてもよい。同様に、領域単位パッキングプロセスは、エンコードされるパックされたピクチャの2つ以上のシーケンスを作成するために、同じ投影ピクチャから複数回実施されてもよい。
360度パノラマコンテンツ(例えば、画像および映像)は、撮像デバイスのキャプチャ位置周りで、完全な360度視野を水平にカバーする。垂直な視野は変動する場合があり、例えば180度である可能性がある。水平に360度視野、垂直に180度視野をカバーするパノラマ画像は、正距円筒図法投影(ERP)を使用して二次元画像平面にマッピングされている球体によって表現することができる。この場合、変換や縮尺が適用されなければ、水平座標は経度と等価であると考えることができ、垂直座標は緯度と等価であると考えることができる。モノスコピックな正距円筒図法パノラマピクチャを形成するプロセスを、図3に図示する。カメラアレイまたは複数のレンズおよびセンサを有するカメラデバイスの魚眼画像などの入力画像のセットは、球面画像上にスティッチングすることができる。球面画像は、さらに(上面および底面のない)円筒上に投影することができる。円筒は、二次元投影フレームを形成するために、広げることができる。これらの操作の1つまたは複数は、マージすることができる。例えば、入力画像は、球面への中間的な投影を伴わずに、直接円筒上に投影してもよい。正距円筒図法パノラマ用の投影構造は、単一表面を含む円筒であると考えることができる。
360度のコンテンツは、多面体(例えば、平坦な多角面、直線辺および鋭角または頂点を含む三次元立体物体、例えば立方体または錐体)、円筒形(正距円筒図法投影で上述したように、球面画像を円筒上に投影することによる)、円筒形(初めに球体に投影することなく直接的に)、円錐などの、様々なタイプの立体幾何学構造体にマッピングし、次いで二次元画像平面に展開することができる。
いくつかの実施形態では、360度水平視野であるが、垂直視野が180度未満のパノラマコンテンツは、球面の極エリアが二次元画像平面にマッピングされていない正距円筒図法投影の特殊なケースと考えることができる。いくつかの実施形態では、パノラマ画像は、360度未満の水平視野と最大180度の垂直視野を有することができるが、それ以外では正距円筒図法投影形式の特性を有している。
領域単位パッキング情報は、ビットストリーム内で、またはビットストリームに沿ってメタデータとしてエンコードされる場合がある。例えば、パッキング情報は、先ほど説明したように、所定のまたは示されたソース形式からパックされたフレーム形式への領域単位マッピング、例えば投影ピクチャからパックされたピクチャへの領域単位マッピングを含むことができる。
領域単位パッキング情報は、矩形の領域単位パッキングメタデータとしてエンコードすることができる。領域ごとに、矩形の領域単位パッキングメタデータは、投影ピクチャ内の矩形、パックされたピクチャ内の個々の矩形、および90度、180度、もしくは270度の任意の回転の変換、ならびに/または水平および/もしくは垂直なミラーリングを定義する。矩形は、例えば左上角と右下角の場所によって示すことができる。マッピングは、再サンプリングを含む場合がある。個々の矩形のサイズは、投影ピクチャとパックされたピクチャとでは異なる可能性があるため、メカニズムは領域単位の再サンプリングを推論する。
例として、領域単位パッキングは、以下の使用シナリオではシグナリングを与える:
1)球面全体のさらなる均一性を達成するために、ビューポート独立的な投影用の追加的な圧縮が、異なる領域のサンプリングを稠密化することによって達成される。例えば、ERPの上部および下部がオーバサンプリングされ、これらを水平にダウンサンプリングするために領域単位パッキングを適用することができる。
2)キューブマップ投影などの平面ベースの投影形式の面を、アダプティブなやり方で構成する。
3)ビューポート独立的な投影形式を使用するビューポート依存ビットストリームを生成する。例えば、ERPの領域またはCMPの面は、様々なサンプリング密度を有する可能性があり、基礎となる投影構造は様々な向きを有することができる。
4)エキストラクタトラックが異なる解像度のビットストリームからタイルを収集する場合など、エキストラクタトラックによって表現されるパックされたピクチャの領域を示す。
MPEG全指向性メディア形式(ISO/IEC23090-2)は、仮想現実(VR)システム規格である。OMAFはメディア形式を定義している(ISOBMFFから導出したファイル形式およびDASHおよびMPEG Media Transport向けのストリーミング形式の両方を含む)。OMAF version1は、360°映像、画像、および音声ならびに関連付けられた時間が決められたテキストをサポートし、自由度が3(3DoF)のコンテンツ消費を容易にしており、全指向性コンテンツによってカバーされるあらゆる方位角と仰角および傾斜角でビューポートが選択可能であることを意味しているが、コンテンツはビュー位置のいかなる並進方向の変化にも適合されない。以下でさらに説明されるビューポート依存ストリーミングシナリオは、3DoF用にも設計されているが、潜在的には自由度の異なる数に適合することが可能である。
全指向性メディア形式(OMAF)により、画像のスティッチング、投影、および領域単位パッキングの省略が可能となり、画像/映像データを、キャプチャされた形式でエンコードする。この場合、画像Dは画像Biと同一であると考えられ、時間瞬間当たり限られた数の魚眼画像がエンコードされる。
音声信号では、キャプチャされた信号が本質的に没入的で全指向性であり得るため、スティッチングプロセスが必要ない場合がある。スティッチングされた画像(D)は、符号化画像(Ei)または符号化映像ビットストリーム(Ev)としてエンコードされる。キャプチャされた音声(Ba)は、音声ビットストリーム(Ea)としてエンコードされる。符号化された画像、映像、および/または音声は、特定のメディアコンテナファイル形式、一例としてISOBMFFにしたがって、次にファイル再生用のメディアファイル(F)、またはストリーミング向けの初期化セグメントおよびメディアセグメントのシーケンス(Fs)に構成される。ファイルエンカプセレータは、復号化されたパックされたピクチャのレンダリングを支援する投影および領域単位パッキング情報など、メタデータをファイルまたはセグメントにカプセル化することもできる。ファイル中のメタデータは、以下を含む場合がある:
- 投影ピクチャの投影形式
- 魚眼映像パラメータ
- パックされたピクチャによってカバーされる球面の面積
- グローバル座標軸に対する投影ピクチャに対応する投影構造の向き
- 領域単位パッキング情報
- 領域単位品質ランキング(任意)。
セグメントFsは、配信メカニズムを使用して再生デバイスに配信することができる。ファイルエンカプセレータ出力(F)を含むファイルは、ファイルデカプセレータ入力(F’)を含むファイルと同一であってもよい。ファイルデカプセレータは、ファイル(F’)または受信したセグメント(F’s)を処理し、符号化されたビットストリーム(E’a、E’v、および/またはE’i)を抽出してメタデータを解析する。次いで、音声、映像、および/または画像は、復号化信号へと復号化される(B’aは音声用、D’は画像/映像用)。復号化されたパックされたピクチャ(D’)は、現在の視聴方向またはビューポートおよび投影、球体カバレッジ、投影構造向き、ならびにファイルから解析された領域単位パッキングメタデータに基づいて、頭部装着型ディスプレイまたは任意の他のディスプレイデバイスの画面に投影される。同様に、復号化された音声(B’a)が、例えばヘッドフォンを通じて、現在の視聴方向に応じてレンダリングされる。現在の視聴方向は、頭部追跡および可能であればさらなる視線追跡機能性によって決定される。復号化された映像および音声信号の適当な部分をレンダリングするためにレンダラによって使用される他、現在の視聴方向は復号化最適化のために映像および音声デコーダによって使用される場合もある。
人間の目は、360度の空間全体を見ることはできず、最大水平方向FOVおよび最大垂直方向FoV(それぞれ、HHFoV、HVFoV)に限定される。また、HMDデバイスには、水平方向および垂直方向(それぞれ、DHFoV、DVFoV)に360度の空間全体のサブセットを見ることだけを可能にするという技術的な限度がある。あらゆる時間的ポイントにおいて、HMDのアプリケーションによってレンダリングされた映像は、360度映像の一部をレンダリングする。この部分を、ビューポートと定義する。ビューポートは、レンダリングディスプレイを介して表示される全指向性映像中に表現される360ワールド上でのウインドウである。ビューポートは、水平および垂直FoV(それぞれ、VHFoV、VVFoV)によって特徴付けられる。以下では、VHFoVおよびVVFoVは、単にHFoVおよびVFoVと略する。
OMAFなどの様々なメディア形式において、図4に図示される座標系が利用される。図4に図示されるように、座標系は単位球面および3つの座標軸、つまりX軸(後方から前方)、Y軸(横方向、側方から側方)、Z軸(垂直、上向き)から成り、3つの軸は球体の中心で交わり、そこから直交方向に延びる。球体上でのポイント場所は、球面座標の方位角(φ)および仰角(θ)の対によって特定される。方位角の値範囲は、-180.0度以上180.0度未満である。仰角の値範囲は、-90.0度以上90.0度以下である。
図5は、コンテンツオーサリングで使用されることがある球面ピクチャからパックされたピクチャへのコンバージョン、およびOMAFプレーヤなど様々なメディアプレーヤで使用される可能性がある、レンダリングされるパックされたピクチャから球面ピクチャへの対応するコンバージョンを図示している。この節での例は、投影された全指向性映像トラックに見られるパックされたピクチャについて説明する。類似の説明が、画像項目について導出することが可能である。コンテンツオーサリングには、次の順序付けられた操作が含まれる場合がある:
操作A:50で示されるように、入力として与えられたソース画像は、球面ピクチャを生成するよう、グローバル座標軸ごとに単位球面上でスティッチングされる。
操作B:次に、52に示されるように、単位球面をグローバル座標軸周りに回転させる。ローカル座標軸からグローバル座標軸へコンバートさせるための回転量は、RotationBoxシンタックス構造で示される回転角によって指定することができる。単位球面のローカル座標軸は、回転させられた座標系の軸である。RotationBoxがないということは、ローカル座標軸がグローバル座標軸と同一であることを示している可能性がある。
操作C:54で示されるように、次いで回転した単位球面上の球面ピクチャは、例えば正距円筒図法投影を用いて、二次元投影ピクチャにコンバートされる。ステレオスコピックなコンテンツの空間パッキングが適用される場合、2つのビュー用の2つの球面ピクチャが、2つの構成ピクチャにコンバートされ、その後、フレームパッキングが適用され、2つの構成ピクチャを1つの投影ピクチャにパックする。
操作D:矩形の領域単位パッキングを適用して、投影ピクチャからパックされたピクチャを取得することが可能である。パッキングの一例を、54および56に図示する。54での破線矩形は、投影ピクチャ上の投影領域を示し、56での個々のエリアは対応するパックされた領域を示す。この例では、投影領域1および3は水平方向にダウンサンプリングされるが、投影領域2ではその元来の解像度が保たれる。
CoverageInformationBoxシンタックス構造は、球体のどの部分がパックされたピクチャによってカバーされるかを示すために使用することが可能である。
56におけるようなパックされたピクチャのサンプル場所を、50で図示されるレンダリングで使用される単位球面にマッピングするために、OMAFプレーヤは、以下の順序付けられた操作を実施することができる:
- 56のピクチャなどのパックされたピクチャは、映像トラックまたは画像項目からのピクチャを復号化した結果として取得される。
- 必要であれば、パックされたピクチャのクロマサンプルアレイが、パックされたピクチャのルマサンプルアレイの解像度までアップサンプリングされ、色空間コンバージョンも実施してもよい。
- 領域単位パッキングが示される場合、パックされたピクチャのサンプル場所が、54におけるような個々の投影ピクチャのサンプル場所にコンバートされる。それ以外では、投影ピクチャはパックされたピクチャと同一である。
- 投影ピクチャの空間フレームパッキングが示される場合、投影ピクチャのサンプル場所が、投影ピクチャの個々の構成ピクチャのサンプル場所にコンバートされる。それ以外では、投影ピクチャの構成ピクチャは投影ピクチャと同一である。
- 投影ピクチャの構成ピクチャのサンプル場所は、使用されている全指向性投影形式向けに指定されるようなローカル座標軸に対する球面座標にコンバートされる。得られるサンプル場所は、52で図示される球面ピクチャに対応する。
- 回転が示される場合、ローカル座標軸に対する球面座標は、グローバル座標軸に対する球面座標にコンバートされる。それ以外では、グローバル座標軸はローカル座標軸と同一である。
VR映像のストリーミングビットレートを減らすために、主なビューポート(例えば、現在の視聴方向)をカバーする360度映像コンテンツのサブセットが最良の品質/解像度で送信され、360度映像の残りが低品質/解像度で送信されるビューポート依存配信が、導入されてもよい。ビューポート固有のエンコーディング/パッキングでは、360度画像コンテンツは、主なビューポートに対する強調を伴って(例えば、より大きな空間エリア)同一のフレームにパックされる。コンテンツのいくつかのバージョンが、様々な主なビューポートの向きおよび/またはFOV用に作成される。ビューポート固有のエンコーディング/パッキングは、非対称投影(別名、ビューポート依存投影)によって達成することができ、ビューポートエリアは、最高サンプリング密度でエンコードされ、360°シーンの残りはサンプリング密度がビューポートから非ビューポートエリアに向かって徐々に減少する方法で投影される。再投影された非ビューポートエリアは、ビューポートエリアと同じ画像平面にパックされる。領域単位の混合型品質手法では、ビューポートエリアは最高ピクチャ品質でエンコードされるが、他のエリアは低品質でエンコードされる。領域単位の混合型解像度手法では、ビューポート独立的投影が適用され、投影された2Dピクチャは、ビューポートが最高2D解像度から始まり、他のエリアが2D低解像度から始まるやり方で、そのエンコーディングの前に領域単位で再サンプリングされる。
タイルベースのビューポート依存ストリーミング手法では、投影ピクチャは、動き制約タイルセット(MCTS)として符号化されるタイルにパーティショニングされる。タイルベースのビューポートアダプティブストリーミングスキームは、以下のようにカテゴライズすることができる:
1.領域単位混合型品質(RWMQ)360°映像:コンテンツのいくつかのバージョンが、MCTSを用いて同じタイルグリッド上でエンコードされ、それぞれのバージョンは異なるビットレートおよびピクチャ品質を有する。プレーヤはMCTSベースで、どのバージョンが受信されるか選択し、それによりビューポートをカバーするMCTSの品質は、受信される他のMCTSの品質よりも高くなる。
2.ビューポート+360°映像:完全な低解像度全指向性ピクチャおよびビューポートをカバーする高解像度のタイル用のMCTSが受信される。
3.領域単位混合型解像度(RWMR)360°映像:タイルは複数の解像度でエンコードされる。プレーヤは、ビューポートをカバーする高解像度のタイルと、残りのエリア用の低解像度のタイルとの組み合わせを選択する。
これらすべての手法は、クライアント駆動ビットストリーム再書き込み(別名、レイトバインディング)または、エキストラクタ駆動サブピクチャトラックマージングなどのオーサ駆動画像セグメント(例えば、MCTS)マージング(別名、アーリーバインディング)が使用中かどうかに関わらず適用することができる。レイトバインディングでは、プレーヤは、受信されるMCTSシーケンスを選択し、必要に応じて(例えば、パラメータセットおよびスライスセグメントヘッダは、再書き込みする必要がある場合がある)受信したMCTSを単一のビットストリームに組み合わせるために受信した映像データの一部を選択的に再書き込みし、単一のビットストリームを復号化する。アーリーバインディングとは、必要に応じて受信した映像データの一部を再書き込みするため、MCTSを復号化される単一のビットストリームにマージングするため、場合によっては、受信するMCTSシーケンスの選択のための、オーサ駆動情報の使用を指す。アーリーバインディングとレイトバインディングとの間の手法が存在してもよい:例えば、プレーヤにオーサガイダンスなしに受信するMCTSシーケンスを選択させ、その一方でオーサ駆動手法がMCTSマージングおよびヘッダ再書き込みに使用されることが可能であってもよい。アーリーバインディング手法は、エキストラクタ駆動手法およびタイルトラック手法を含み、引き続きこれらを説明する。これらすべての手法において、タイル(またはそのガードバンド)同士は事前処理またはエンコーディングにおいて選択された分、オーバラップしてもよい。
タイルトラック手法では、1つまたは複数の動き制約タイルセットシーケンスが、ビットストリームから抽出され、それぞれ抽出された動き制約タイルセットシーケンスは、タイルトラック(例えば、HEVCタイルトラック)としてファイルに記憶される。タイルベーストラック(例えば、HEVCタイルベーストラック)が生成され、ファイルに記憶することができる。タイルベーストラックは、タイルトラックから動き制約タイルセットを非明示的に収集することにより、ビットストリームを表現する。タイルトラックは、次のようにビューポート依存ストリーミングに使用することができる:受信機側では、ストリーミングされるタイルトラックは、視聴方向に基づいて選択され得る。クライアントは、全指向性コンテンツ全体をカバーするタイルトラックを受信することができる。残りの360度映像をカバーする品質または解像度と比較して、より良好な品質またはより高解像度のタイルトラックを、現在のビューポート用に受信することができる。タイルベーストラックは、タイルトラックへのトラック参照を含む場合がある、および/またはタイルトラックはタイルベーストラックへのトラック参照を含む場合がある。例えば、HEVCでは、タイルベーストラックからタイルトラックを参照するために「sabt」トラック参照が使用され使用され、タイルの並び順は「sabt」トラック参照によって含まれるタイルトラックの順によって示される。さらには、HEVCでは、タイルトラックは、タイルベーストラックへの「tbas」トラック参照を有するである。
エキストラクタを必要とするファイルリーダによってエキストラクタが処理される場合、エキストラクタは、含まれるコンストラクタをその出現順に解決する際に得られるバイトによって、論理的に置換される。いくつかの実施形態では、ネストされた抽出は許可されていない場合があり、例えば、サンプルコンストラクタによって参照されるバイトはエキストラクタを含まない場合がある。また、エキストラクタは、直接または間接的に別のエキストラクタを参照しない場合がある。エキストラクタは、現在のトラックから、またはトラック参照のタイプ「scal」によってエキストラクタが存在するトラックにリンクされた別のトラックからデータを抽出するための1つまたは複数のコンストラクタを含むことができる。
一例では、解決されたエキストラクタのバイトは、以下のうちの1つである:
a)1つのNALユニット全体;Aggregatorが参照されると、含まれるバイトおよび参照されるバイトの両方がコピーされることに留意されたい
b)2つ以上のNALユニット全体
両方の場合で、解決されたエキストラクタのバイトは、有効長フィールドおよびNALユニットヘッダで始まる。
サンプルコンストラクタのバイトは、示された「scal」トラック参照を通じて参照されるトラック内の単一の識別されたサンプルからのみコピーされる。アラインメントは、復号化時間に基づいており、例えば時間-サンプルのテーブルだけを使用し、サンプル番号のカウントされたオフセットが続く。エキストラクタは、メディアレベルの概念であり、そのためあらゆる編集リストを考慮する前に宛先トラックに適用される。しばしば、2つのトラック内の編集リストが同一となる。次のシンタックスが使用される場合がある:
class aligned(8) Extractor(){
NALUnitHeader();
do{
unsigned int(8) constructor_type;
if(constructor_type==0)
SampleConstructor();
else if(constructor_type==2)
InlineConstructor();
}while(!EndOfNALUnit())
}
NALUnitHeader()は、HEVC NALユニットの最初の2バイトである。特定のnal_unit_type値は、エキストラクタを示しており、例えばnal_unit_typeイコール49である。constructor_typeは使用されているコンストラクタを指定する。EndOfNALUnit()は、このエキストラクタ内でさらにデータが続く場合に0(偽)を返し、そうでない場合に1(真)を返す関数である。サンプルコンストラクタ(SampleConstructor)は、次のシンタックスを有することができる:
class aligned(8) SampleConstructor(){
unsigned int(8) track_ref_index;
signed int(8) sample_offset;
unsigned int((lengthSizeMinusOne+1)*8)
data_offset;
unsigned int((lengthSizeMinusOne+1)*8)
data_length;
}
track_ref_indexは、データが抽出されるソーストラックを特定する。track_ref_indexは、トラック参照のタイプ「scal」のインデックスである。最初のトラック参照は、インデックス値1を有する。値0は、予約済である。データが抽出されるそのトラックにおけるサンプルは、メディア復号化タイムラインにおいて時間的に揃っているか、最も近く先行しており、例えば時間-サンプルのテーブルだけを使用して、エキストラクタを含むサンプルでsample_offsetで指定されるオフセット分、調節される。sample_offsetは、情報のソースとして使用され得るリンクされたトラック内のサンプルの相対的なインデックスを与える。サンプル0(ゼロ)は、同じ復号化時間、またはエキストラクタを含むサンプルの復号化時間と比較して最も近く先行する復号化時間を持つサンプルである。サンプル1は、次のサンプルであり、サンプル-1(マイナス1)は、その直前のサンプルであり、以下同様である。data_offsetは、コピーする参照サンプル内の第1のバイトのオフセットである。抽出がそのサンプル中で、データの第1のバイトで始まる場合、オフセットは値0を取る。data_lengthは、コピーするバイト数である。
インラインコンストラクタのシンタックスは、次のように指定することができる:
class aligned(8) InlineConstructor(){
unsigned int(8) length;
unsigned int(8) inline_data[length];
}
lengthは、このフィールドに続くInlineConstructorに属するバイト数である。inline_dataは、インラインコンストラクタを解決すると返されるデータバイトである。
エキストラクタ駆動手法では、1つまたは複数の動き制約タイルセットシーケンスは、ビットストリームから抽出され、それぞれ抽出された動き制約タイルセットシーケンスは、それ自身の準拠ビットストリーム(例えば、HEVCビットストリーム)となるように修正され、サブピクチャトラック(例えば、HEVCでは無変換サンプルエントリタイプ「hvc1」)としてファイルに記憶される。1つまたは複数のエキストラクタトラック(例えば、HEVCエキストラクタトラック)が生成され、ファイルに記憶することができる。エキストラクタトラックは、サブピクチャトラックから動き制約タイルセットを明示的に抽出することによって(例えば、HEVCエキストラクタによって)、ビットストリームを表現する。受信機側では、ストリーミングされるサブピクチャトラックは、視聴方向に基づいて選択され得る。クライアントは、全指向性コンテンツ全体をカバーするサブピクチャトラックを受信することができる。残りの360度映像をカバーする品質または解像度と比較して、より良好な品質またはより高解像度のサブピクチャトラックを、現在のビューポート用に受信することができる。
タイルトラック手法およびエキストラクタ駆動手法を詳細に説明したが、具体的にHEVCのコンテキストでは、これらは他のコーデックおよびタイルトラックまたはエキストラクタと同様の概念に適用されることを理解する必要がある。その上、タイルトラックとエキストラクタ駆動手法の組み合わせまたは混合型が可能である。例えば、そのような混合型は、タイルトラック手法に基づくことができるが、タイルベーストラックは、クライアント向けの再書き込み操作のガイダンスを含むことが可能であり、例えばタイルベーストラックは、再書き込みされたスライスまたはタイルグループヘッダを含むことが可能である。
MCTSベースのコンテンツエンコーディングの代替として、タイルベースのビューポート依存ストリーミング用のコンテンツオーサリングを、以下で説明するようなサブピクチャベースのコンテンツオーサリングで実現することができる。(エンコーディングに先立つ)事前処理には、圧縮されていないピクチャをサブピクチャにパーティショニングすることが含まれる。同じ圧縮されていないサブピクチャシーケンスのいくつかのサブピクチャビットストリームが、例えば同じ解像度であるが異なる品質およびビットレートで、エンコードされる。エンコーディングは、符号化されたサブピクチャビットストリームの、全指向性映像を表現する準拠ビットストリームへのマージングが可能になるやり方に制約することができる。例えば、復号化されるピクチャ境界の外部のサンプルへの依存は、ピクチャ外部のサンプル場所がインター予測プロセスで参照されないようなやり方で動きベクトルを選択することによって、エンコーディングの際に回避することができる。それぞれのサブピクチャビットストリームは、サブピクチャトラックとしてカプセル化することができ、様々なサブピクチャ場所のサブピクチャトラックをマージングする1つまたは複数のエキストラクタトラックを、追加的に形成することができる。タイルトラックベースの手法が対象となる場合、それぞれのサブピクチャビットストリームは、MCTSシーケンスとなるように修正され、タイルトラックとしてファイルに記憶され、1つまたは複数のタイルベーストラックがタイルトラック用に作成される。
タイルベースのビューポート依存ストリーミング手法は、例えばプレーヤを実行中のデバイスおよびオペレーティングシステムの機能に応じて、単一のデコーダインスタンスまたはMCTSシーケンスごとに(または、場合によっては、これらの間に何らか、例えば、同じ解像度のMCTSごとに1デコーダインスタンス)1つのデコーダインスタンスを実行することによって実現することができる。単一のデコーダインスタンスの使用は、レイトバインディングまたはアーリーバインディングによって可能とすることができる。複数のデコーダインスタンスを容易にするために、エキストラクタ駆動手法は、修正を伴わずに符号化形式または規格に準拠するサブピクチャトラックを使用することができる。他の手法は、クライアント側で画像セグメントヘッダ、パラメータセット、および/または類似の情報を再書き込みして準拠ビットストリームを構築すること、または他の符号化映像データの存在なしにMCTSシーケンスを復号化できるデコーダ実装形態を有することのいずれかを必要とする可能性がある。
タイルトラック手法とエキストラクタ駆動手法のそれぞれにおいて、タイルトラックまたはサブピクチャトラックをカプセル化して参照するための、少なくとも2つの手法があり得る:
タイルベーストラックまたはエキストラクタトラックからの参照トラック識別子。
タイルベーストラックまたはエキストラクタトラックからの参照タイルグループ識別子であり、タイルグループ識別子によって識別されるタイルグループは、コロケートされたタイルトラックまたは抽出の代替であるサブピクチャトラックを含む。
RWMQ方法では、各ピクチャサイズと各タイルグリッド当たり1つのエキストラクタトラックで十分である。360°+ビューポート映像およびRWMR映像では、1つのエキストラクタトラックが、それぞれ別個の視聴方向に必要とされる場合がある。
識別されたメディアデータボックスは、MediaDataBoxが有しているのと同一のセマンティクスを有する場合があるが、含まれるメディアデータへのデータ参照をセットアップする際に使用される識別子を追加的に含んでいる。識別子は、例えば識別されるメディアデータボックスによって含まれる第1の要素であってもよい。識別されたメディアデータボックスのシンタックスは、以下のように説明することができ、imda_identifierはボックスの識別子である。64ビット符号なし整数型タイプのimda_identifierがシンタックスで使用されるが、他のフィールド長および他の基本データタイプ(例えば、文字列型)が同じように可能であることに留意されたい。例示的な識別されたメタデータボックスを、以下に与える:
aligned(8) class IdentifiedMediaDataBox extends Box(’imda’){
unsigned int(64) imda_identifier;
bit(8) data[];//ボックスの最後まで
}
本明細書においてDataEntryImdaBoxと称されるボックスは、識別されたメディアデータボックスでデータを参照するために使用することができる。DataEntryImdaBoxは、このDataEntryImdaBoxに対応するdata_reference_indexを通じてアクセスされたメディアデータを含むIdentifiedMediaDataBoxを識別する。DataEntryImdaBoxは、参照されたIdentifiedMediaDataBoxのimda_identifierの値を含む。メディアデータオフセットは、参照されたIdentifiedMediaDataBoxのペイロードの第1のバイトに関連している。換言すると、メディアデータオフセット0は、参照されたIdentifiedMediaDataBoxのペイロードの第1のバイトをポイントしている。サンプルエントリは、DataReferenceBoxのどのデータ参照がサンプルエントリを参照しているサンプルを含むために使用中かを識別するdata_reference_indexを含む。IdentifiedMediaDataBoxがサンプルを含むことに使用されている場合、data_reference_indexはDataEntryImdaBoxをポイントしている値にセットされる。DataEntryImdaBoxのシンタックスは、以下のように指定することができ、imda_ref_identifierはimda_identifier値を提供し、ひいては特定のIdentifiedMediaDataBoxを識別する:
aligned(8) class DataEntryImdaBox(bit(24) flags)
extends FullBox(’imdt’,version=0,flags){
unsigned int(64) imda_ref_identifier;
}
ある例では、(Sub)segmentまたは動画フラグメントの識別されたメディアデータボックス用の識別子値が決定され、その識別子値は、(Sub)segmentまたは動画フラグメントのメディアデータ用のデータ参照基準として提供される。ある例では、識別されたメディアデータボックス用の識別子のためのテンプレートスキームが、サンプルデータ、例えばDataReferenceBox用のデータ参照として使用されるように定義される。テンプレートスキームに基づくことは可能であるが、動画フラグメントシーケンス番号(MovieFragmentHeaderBoxのsequence_numberフィールドなど)またはトラックフラグメント復号化時間(TrackFragmentBaseMediaDecodeTimeBoxのbaseMediaDecodeTimeフィールドなど)に限定されない。上述した識別子に加えて、または上述した識別子の代わりに、動画フラグメントまたはトラックフラグメント向けに用意されるあらゆる識別子が、テンプレートスキームに適当であり得ることを理解する必要がある。ある例では、次のシンタックスが、識別子を導出するためのテンプレートを使用して識別されたメディアデータボックスを参照するために使用される場合がある:
aligned(8) class DataEntryTfdtBasedImdaBox (bit(24) flags)
extends FullBox(’imdt’,version=0,flags){
}
DataEntryTfdtBasedImdaBoxは、このDataEntryTfdtBasedImdaBoxに対応するdata_reference_indexを通じてアクセスされたメディアデータを含むIdentifiedMediaDataBoxを識別する。メディアデータオフセット0は、TrackFragmentBaseMediaDecodeTimeBoxのbaseMediaDecodeTimeに等しいimda_identifierを有するIdentifiedMediaDataBoxのペイロードの第1のバイトをポイントする。一実施形態では、baseMediaDecodeTimeの64ビット値を搬送するために、64ビットのimda_identifier値が使用される。32ビットのbaseMediaDecodeTime値が使用中である場合、64ビットのimda_identifierの最上位ビットを0にセットすることができる。内蔵型の動画フラグメントでは、IdentifiedMediaDataBoxのimda_identifierがTrackFragmentBaseMediaDecodeTimeBoxのbaseMediaDecodeTimeと等しいことが要求され、この時参照されるデータ参照エントリは、タイプDataEntryTfdtBasedImdaBoxのものである。
別の例では、次のシンタックスが、識別子を導出するためのテンプレートを使用して識別されたメディアデータボックスを参照するために使用される場合がある:
aligned(8) class DataEntrySeqNumImdaBox (bit(24) flags)
extends FullBox(’snim’,version=0,flags){
}
DataEntrySeqNumImdaBoxは、このDataEntrySeqNumImdaBoxに対応するdata_reference_indexを通じてアクセスされたメディアデータを含むIdentifiedMediaDataBoxを識別する。サンプルエントリに含まれるdata_reference_indexがDataEntrySeqNumImdaBoxを参照する時、サンプルエントリを参照している各サンプルは、動画フラグメントに含まれ、メディアデータオフセット0は、サンプルを含む動画フラグメントのMovieFragmentHeaderBoxのsequence_numberに等しいimda_identifierを有するIdentifiedMediaDataBoxのペイロードの第1のバイトをポイントする。
MovieFragmentBoxのサイズは、動画フラグメントのトラックのベースデータオフセットを決定する時点では分かっている必要はなく、結果的にMovieFragmentBoxの子ボックス(例えば、TrackFragmentHeaderBoxおよびTrackRunBox)は、動画フラグメント用のすべての符号化されたメディアデータが利用可能となる前に「プログレッシブに」オーサリングされ得る。その上、コンテンツエンカプセレータは、セグメントヘッダのサイズを正確に推定する必要がなく、セグメント持続時間の一部動的なばらつきの柔軟性を有する。
いくつかの実施形態では、メディアセグメントヘッダおよびセグメントペイロードは、セグメントヘッダと対応するセグメントペイロード用に別個のUniform Resource Locator(URL)を示すストリーミングマニフェストをコンパイルすることによって、別個に利用可能にすることができる。DASH Media Presentation Description(MPD)などの、ストリーミングマニフェストは、URLテンプレートを提供することができる、またはMPDで与えられるベースURLを付加するURLテンプレートスキームが適用可能であると示される場合がある。いくつかの実施形態では、ストリーミングマニフェストは、セグメントペイロード中のデータが密にパックされ、復号化順になっていることをさらに示す場合がある。セグメントペイロードとは、例えばMediaDataBoxを指すことができる。密にパックされるとは、セグメントペイロードのすべてのバイトが映像ビットストリームに属していること、例えばセグメントペイロードが映像ビットストリームのバイトの隣接範囲で構成されていることを指す。そのようなインジケーションは、例えばDASH MPDにおける補足的な性質として与えることができる。セグメントペイロード中の映像ビットストリームは、カプセル化された映像ビットストリームであることができる。例えば、セグメントペイロードは、ISOBMFFファイルの映像トラックのサンプルの隣接するセットで構成することができる。
Index Segmentは、主にMedia Segmentのインデックス付け情報を含むSegmentとして定義することができる。MPDは、Index Segmentを取得するために使用可能なURLを示す情報を提供することができる。情報の例は以下の通りである:
- SegmentBase要素内のRepresentationIndex要素は、Representation Index Segmentに可能なバイト範囲を含むURLを指定する。
- SegmentList要素は、複数のSegmentURL要素を含み、複数のSegmentURL要素は(@media属性中に)Media Segment用のURL、@media属性のURLによって特定されたリソース内のバイト範囲、(@index属性中に)Index Segment用のURL、および/または@index属性のURLによって特定されたリソース内のバイト範囲を含むことができる。@media属性中のURLは、もし存在する場合、@mediaRange属性と組み合わせて、Media Segment用のHTTP-URLを指定する。@index属性中のURLは、もし存在する場合、@indexRange属性と組み合わせて、Index Segment用のHTTP-URLを指定する。
- SegmentTemplate要素の@index属性は、Index Segment Listを作成するためのテンプレートを指定する。セグメントテンプレートは、Segment(そのURLによって特定される)のリストを導出することができる文字列型の文字列を含む。セグメントテンプレートは、Segmentのリストを作成するためにSegmentに割り振られた動的な値で置換された特定の識別子を含むことができる。
各Segmentは、明示的に宣言されたIndex Segmentに与えられる場合がある割り振られたSegment Index情報を有することができる。明示的なIndex Segment情報の存在は、例えば次のうちのいずれかによって示すことができる:
- Segment IndexをRepresentation全体に提供している、1つのRepresentationIndex要素の存在によって、または
- SegmentList.SegmentURL要素中の2つの属性@indexおよび@indexRangeのうちの少なくとも1つの存在によって、または
- SegmentTemplate@index属性の存在によって。
@indexRange属性は、Media Segment内のインデックスのためのバイト範囲を提供するために使用することもでき、これはMedia Segment形式によって可能となる。この場合、@index属性は存在せず、指定される範囲はMedia Segment用に指定された任意のバイト範囲内に完全に入る。Index Segmentの可用性は、それらが対応するMedia Segmentへの可用性と同一であることができる。
レイトバインディングで効率的にビューポート依存ストリーミングを実現するために、すべての利用可能なトラックのすべての動画フラグメントヘッダを、(Sub)segment当たり1つのリクエストでフェッチすることが可能であることが好ましい場合がある。クライアントにおける動画フラグメントヘッダの可用性は、ピクチャ粒度で符号化されたピクチャデータのバイト範囲のHTTP GETリクエストを容易にするため、品質切り替えのレイテンシを低減する可能性がある。しかしながら、現在、DASHシグナリングまたはDASH概念に対応するソリューションがない。
まず、DASH MPDには、(Sub)segmentヘッダ用のURLを個々のメディアデータと別個に報知するためのメカニズムがない。(Sub)segmentヘッダは、動画フラグメントヘッダ、すなわちMovieFragmentBoxを含み、個々のメディアデータはMediaDataBoxおよび/またはそこで包み込まれるメディアデータを含むことができる。次に、MPEG文書N18235で提示されるレイトバインディング手法は、(MetaBoxのDataInformationBoxのDataReferenceBoxに含まれる)MovieFragmentBox内にメディアデータのURLを含み、これには次の欠点がある:
- コンテンツが新しいサーバまたはコンテンツ配信ネットワーク(CDN)に移動する場合、MovieFragmentBoxを変更する必要があるため、異なるサーバおよびCDN上でのコンテンツ配信が困難である。
- 1つのURLしか使用できないため、マルチサーバ/マルチCDN配信を扱うことができない。(逆に、DASH MPDは、同一のコンテンツに対して複数のベースURLを挙げることができる。)
- トラック用のデータ参照が、TrackBoxのMediaBoxのMediaInformationBoxのDataInformationBoxのDataReferenceBox内で搬送されるため、ISOBMFFに非対応である。TrackFragmentHeaderBoxおよびTrackExtendsBoxのsample_description_indexフィールドは、TrackBox内に含まれるDataReferenceBoxで与えられるデータ参照のインデックス付けされたリストを参照する。
DASH規格の現在のバージョンによると、DASH RepresentationのMedia Segmentに含まれる(Sub)segmentヘッダメタデータ(例えば、MovieFragmentBox)は、同一のDASH Representationに含まれるメディアデータに対応する。しかしながら、レイトバインディングの場合、メタデータはすべての利用可能なトラックを記述しているがメディアデータのサブセットだけが受信されるため、メタデータは受信されたメディアデータのスーパーセットに対応するべきである。すべての利用可能なトラックおよびトラックのサブセット用の(Sub)segmentメディアデータ用の(Sub)segmentメタデータのフェッチを扱うメカニズムが提案されていない。したがって、レイトバインディング用のより良好なメカニズムが必要である。
いくつかの実施形態では、エンコーダは、ファイルまたはInitializationおよびタイルトラックを伴うメディアセグメントを取得することができる。エンコーダは、各タイルトラックをある表現に、そしてコロケートされたタイルトラックの表現の各セットをアダプテーションセットにエンコードすることができる。エンコーダは、タイルトラック用のSegmentメタデータを含むIndex Segmentを生成することができる。ベーストラック用に、エンコーダはファイルまたは初期化およびタイルベーストラックを含むMedia Segmentを取得することもできる。エンコーダは、タイルベーストラックをあるRepresentationにエンコードすること、およびその表現をそれ自身のアダプテーションセットにエンコードすることができる。RepresentationおよびAdaptationセットがエンコードされた後、エンコーダはメディア提示記述およびセグメントオーサリングに進むことができる。
いくつかの実施形態では、エンコーダは、Index SegmentのURLを示す情報をMPDにエンコードすることができる。いくつかの実施形態では、エンコーダは、個々のRepresentationsに固有のMedia SegmentのURLを示す情報をMPDにエンコードすることができる。Index Segmentは、タイルベーストラックの情報を含むこともできる。タイルベーストラックのRepresentationに固有のMedia SegmentのURLを示す情報も、MPDにエンコードすることができる。コロケートされたタイルトラックの例えば異なるビットレートのいくつかのバージョンは、コロケートされたタイルトラックの各セットが、(例えば「alte」タイプの)トラックグループを形成するように、ファイルまたはInitialization Segmentでトラックグループを示す情報をエンコーディングすること、およびタイルベーストラックのトラック参照からトラックグループを参照することによって、扱うことができる。トラックグループを参照することは、トラックグループから1つのトラックが、タイルベーストラックに基づいてビットストリームを再構築するために選択されることを意味する。
図6は、例えば図1の装置10によって具体化されるエンコーダによって実施されるメディア提示記述およびセグメントオーサリングのプロセスを図示している。ブロック60に図示されるように、図1の装置10などの装置は、表現のセットについてのセグメントメタデータ用の第1のロケータを示す第1の情報項目をメディア記述にエンコーディングするための処理回路12などの手段を含む。いくつかの実施形態では、第1の情報項目は、ISOBMFFベースのMedia Segment用のIndex Segmentを識別する情報を含む。Index Segmentは、トラックの集合の1つまたは複数のセグメント、例えば特定のメディアコンテンツのすべてのタイルトラック中のセグメント、潜在的には個々のタイルベーストラックも記述する。いくつかの実施形態では、メディア記述はDASH MPDに準拠する。
ブロック62に図示されるように、図1の装置10などの装置は、表現のセットの1つまたは複数の表現について、セグメントメディアデータ用の表現固有のロケータを示す1つまたは複数の表現固有の情報項目を、メディア記述にエンコードするための処理回路12などの手段を含む。いくつかの実施形態では、MPD中の、Preselectionのメインアダプテーションセットとなる、タイルベーストラックを含むアダプテーションセットを示す情報もエンコードされる。いくつかの実施形態では、MPD中の、事前選択に含められるタイルトラックを含むアダプテーションセットおよび表現を示す情報もエンコードされる。いくつかの実施形態では、事前選択のアダプテーションセット(例えば、事前選択のメインアダプテーションセット)用のインデックスセグメントが同一の事前選択のアダプテーションSetの表現内で搬送されるトラックを記述することを示す情報も、MPD中でエンコードされる。追加的なインジケーションがMPDに含められて、インデックスセグメントがメインアダプテーションセットの表現だけではなく事前選択全体をカバーすることを示す場合もある。いくつかの実施形態では、表現固有の情報項目は、ISOBMFFベースのMedia Segment用のMedia Segmentを識別する情報を含む。いくつかの実施形態では、ISOBMFFベースのMedia Segmentは、ISOBMFFメタデータを伴わないメディアデータを含む。いくつかの実施形態では、ISOBMFFベースのMedia Segmentは、ISOBMFFのIdentifiedMediaDataBoxを含む。
ブロック64に図示されるように、図1の装置10などの装置は、表現のセットとともにメディア記述を記憶するための処理回路12およびメモリ14などの手段を含む。
いくつかの実施形態では、セグメントメタデータは、動画フラグメントヘッダ、例えばMovieFragmentBoxを含み、次のうちのゼロ以上を含むことができる:SegmentTypeBox、SegmentIndexBox、SubsegmentIndexBox、および/またはProducerReferenceTimeBox。
図7Aおよび図7Bは、例としてDASHライブサービス利用と併せて利用することができる例示的なIndex SegmentおよびMedia Segmentを図示している。例として、異なるアダプテーションセットとして2つのサブピクチャを有し、それぞれのアダプテーションセットが次のように特徴付けられる2つの表現を有する提示を考える:
- DASH期間
〇 Adaptation_set_1
・ Representation_1(タイルトラックTrack_1を搬送する)
・ Representation_2(タイルトラックTrack_2を搬送する)
〇 Adaptation_set_2
・ Representation_3(タイルトラックTrack_3を搬送する)
・ Representation_4(タイルトラックTrack_4を搬送する)
〇 Adaptation_set_3
・ Representation_5(タイルベーストラックTrack_5を搬送する)
例示的な提示のIndex Segmentを図7Aに図示する。例示的な提示のMedia Segmentを図7Bに図示する。それぞれ図示される「imda」ボックスは、MPDから導出することができるURLを有する別個のMedia Segment内でカプセル化される。動画フラグメントシーケンス番号は、一意であることができ、IdentifiedMediaDataBox内で識別子として使用することができる。Initialization Segmentでは、DataEntrySeqNumImdaBoxがデータ参照エントリ間に含まれる。TrackFragmentHeaderBoxおよび/またはTrackExtendsBoxは、DataEntrySeqNumImdaBoxのデータ参照エントリを参照するサンプル記述エントリを使用する。トラック識別子値も、やはり一意である。
ある実施形態では、SegmentIndexBoxのreference_typeのセマンティクスは、次のように指定される:1に等しいreference_typeは、参照がSegmentIndexBoxまたはMovieFragmentBox(reference_typeを含むSegmentIndexBoxと同じSegmentに含まれる)に向けたものであることを示す。0に等しいreference_typeは、参照がMedia Segment(MovieFragmentBoxを含まなくてもよい)内の参照されるSubsegmentの第1のボックス(IdentifiedMediaDataBoxまたはMediaDataBoxなど)の開始に向けたものであることを示す。代替的に、0に等しいreference_typeが、Subsegmentの第1のメディアデータボックスがSubsegmentの第1のボックスであるかどうかに関わらず、参照がMedia Segment内の参照されるSubsegmentの第1のメディアデータボックス(IdentifiedMediaDataBoxまたはMediaDataBoxなど)の開始に向けたものであることを示すように指定してもよい。上述のreference_typeのセマンティクスは、ファイルライタおよび/またはファイルリーダおよび/または別のエンティティによって、条件的に使用することができ、その条件は、以下のうちの1つまたは複数であることができるが、それに限定されない:
- reference_typeを含むSegmentIndexBoxは、Index Segmentに含まれる。
- SegmentIndexBoxのボックスヘッダフラグの所定のフラグは、1に等しい。
- SegmentIndexBoxのボックスヘッダの所定のバージョン(またはバージョン値の範囲)。
- 所定のブランドは、FileTypeBox中および/またはTrackTypeBox中に含まれる。
ある実施形態では、上述の条件が満たされない場合、ファイルライタおよび/またはファイルリーダおよび/または別のエンティティは、ISOBMFFで現在指定されるように、また本文書のどこかで説明されるように、reference_typeのセマンティクスを使用する。
ある実施形態では、ファイルライタまたは別のエンティティは、SegmentIndexBoxおよびMovieFragmentBoxでIndex Segmentを作成し、Index SegmentのMovieFragmentBoxをポイントするSegmentIndexBoxに1に等しいreference_typeを含む。
ある実施形態では、ファイルリーダまたは別のエンティティは、Index Segmentを全体的にまたは部分的に解析する。前記Index Segmentの解析の一部として、ファイルリーダまたは別のエンティティは、Index Segmentに含まれるSegmentIndexBoxからの1に等しいreference_typeを解析し、1に等しいreference_typeはIndex Segment中のMovieFragmentBoxをポイントする。ある実施形態では、ファイルリーダまたは別のエンティティは、1に等しいreference_typeのどのインスタンスがSegmentIndexBoxをポイントしているか、およびどのインスタンスがMovieFragmentBoxをポイントしているかを、結論付ける、または推定する。この結論には、すべてのSegmentIndexBoxがIndex Segment中のすべてのMovieFragmentBoxに先行するという情報(例えば、規格における要件、または解析されたインジケーション)に基づいて達することができる。したがって、最後のSegmentIndexBoxまたはIndex Segment内の第1のMovieFragmentBoxへの参照を結論付けることまたは推定することによって、後続の参照がすべてMovieFragmentBoxに向けたものであることを知ることができる。例えば、ファイルリーダまたは別のエンティティは、第1のMovieFragmentBoxが見つかるまで、Index Segment内でそれらの出現順に参照を解析することができる。結果的に、ファイルリーダまたは別のエンティティは、リクエストされるおよび/または処理されるMovieFragmentsBoxのサブセットを選択することができる。したがって、Index Segmentの選択されたMovieFragmentBoxだけを、フェッチすることができ、そのためより少ないビットレートがIndex Segmentのフェッチに使用され得る。
Media Segmentが2つ以上のIdentifiedMediaDataBox、例えばSub-Segment当たりに1つのIdentifiedMediaDataBoxを含む場合、DASHクライアントはIdentifiedMediaDataBoxのサブセット(例えば、特定のSub-Segmentだけ)または1つの特定のIdentifiedMediaDataBoxの一部(例えば、ランダムアクセスピクチャから開始する特定の符号化されたピクチャだけ)のバイト範囲リクエストを発行する場合がある。この点で、例示的な実施形態は、個別のIndentifiedMediaDataBoxのバイト範囲を示す(コンテンツオーサリングにおいて)および/または解決する(クライアントにおいて)ように構成され、以下を含む:
1.reference_typeが0に等しいreferenced_sizeを有するSegmentIndexBoxは、Subsegmentごとの「imda」ボックスのサイズを示す。図8は、選択肢1をグラフィカルに図示している。図8に図示される例は、DASHオンデマンドプロファイル利用と併せて利用することができる。
a.いくつかの実施形態ではSegmentは、reference_typeが0に等しいループエントリの直前にreference_typeが1に等しいループエントリが先行する可能性があり、ループエントリが「moof」ボックスをポイントする(またはSubsegment用のメタデータを開始することができる「sidx」以外の何らかの他のボックス)ことができるという制約にしたがうようにオーサリングされる。いくつかの実施形態では、解析することは、「sidx」ボックスのどの参照が「moof」ボックスをポイントしているかを結論付けるために制約を利用する。
2.Media Segmentのバイト範囲インデックスのインジケーションは別個に、例として、以下のシンタックス構造のいずれかを使用することによって:
a.個々の(時間で揃えた)Media Segmentの構造を示すためのIndex Segment形式に含まれるBoxFileIndexBox(fidx)。
・様々なRepresentationのMedia Segmentが、様々なファイル/リソースに含まれてもよく、または含まれなくてもよく(例えば、それらをフェッチするために異なるURLが使用される場合がある)、BoxFileIndexBoxと正しいMedia Segmentとの関連付けは明確でなければならない。これは、例として、以下の手法のうちのいずれか1つによって行なうことができる:
i.「fidx」ボックス用の新しいコンテナボックスが定義され、関連付けられるMedia Segment内で搬送されるトラックIDを搬送する:
aligned(8) class MediaSegmentContentsBox
extends FullBox(’mstc’,version,flags){
TrackIdBox track_id_list;//任意
//存在する場合、このfidxボックスが適用されるトラックを定義する。
//存在しない場合、このボックスがすべてのトラックに適用される。
BoxFileIndexBox table_of_boxes;//関連するMedia Segmentのボックスインデックス
}
aligned(8) class TrackIdBox extends FullBox(’trid’,version,flags)
{
unsigned int(32) num_tracks;
for (i=0;i<num_tracks;i++)
track_id[i];//トラック用のトラックID
}
}
ii.ボックス順は、関連付けを指定することができる。例えば、BoxFileIndexBoxは直後の「sidx」または「moof」ボックスに関連付けることができ、関連付けられた「sidx」または「moof」ボックスによって記述されるトラックを搬送するファイルを記述することができる。
Media Segmentが単一の「imda」ボックスを搬送することを示すために、BoxFileIndexBoxの不在を指定することができる。
b.「moof」ボックスの子ボックスとして、または「moof」ボックスの隣に含まれる(新しい)バイト範囲ボックス。バイト範囲ボックスは、すべての「imda」ボックスのバイト範囲および/またはサイズを含むことができる。
c.「moof」ボックスの子ボックスとして、または「moof」ボックスの隣に含まれるBoxIndexBox;Media Segmentの個々のSubsegmentのボックスインデックスを示すために、そのセマンティクスを定義する。
d.SegmentIndexBoxで別個に示されるMovieFragmentBoxとメディアデータボックス(例えば、IdentifiedMediaDataBox)とのオフセットおよび/またはバイト範囲および/またはバイトカウント。
上記カテゴリdに入る実施形態では、SegmentIndexBoxに以下が指定される:SegmentIndexBoxのボックスフラグにおいて所定のフラグが指定され、1に等しいとき、メディアデータのオフセットまたはバイト範囲またはバイトカウントが、SegmentIndexBox中で0に等しいreference_typeを有するエントリごとにSegmentIndexBoxに存在することを示す。SegmentIndexBoxのボックスフラグにおいて別の所定のフラグまたは同じフラグが指定され、1に等しいとき、メディアデータのバイトカウントのオフセットまたはバイト範囲が、SegmentIndexBoxは、SegmentIndexBoxを含んでいるリソースとは異なるリソース(例えば、SegmentIndexBoxまたはMovieFragmentBoxを持たないMedia Segment)に関連することを示す。例えば、次のシンタックスが使用される場合がある:
aligned(8) class SegmentIndexBox extends FullBox(’sidx’,version,flags){
unsigned int(32) reference_ID;
unsigned int(32) timescale;
if(version==0){
unsigned int(32) earliest_presentation_time;
unsigned int(32) first_offset;
}
else{
unsigned int(64) earliest_presentation_time;
unsigned int(64) first_offset;
}
unsigned int(16) reserved=0;
unsigned int(16) reference_count;
for(i=1;i<=reference_count;i++)
{
bit(1) reference_type;
unsigned int(31) referenced_size;
unsigned int(32) subsegment_duration;
bit(1) starts_with_SAP;
unsigned int(3) SAP_type;
unsigned int(28) SAP_delta_time;
}
if(flags & 1)
for(i=1;i<=reference_count;i++)
if(reference_type==0)//同じi値のreference_type
unsigned int(32) media_data_offset;
}
media_data_offsetは、サブセグメントの参照されるMediaDataBoxまたはIdentifiedMediaDataBoxの開始までのオフセットを指定する。(flags & 8)がゼロに等しい場合、オフセットはサブセグメントの開始、すなわちSegmentIndexBoxの第1のループ中で0に等しい個々のreference_typeによって示されるMovieFragmentBoxに関連している。それ以外では、オフセットは参照されるMediaDataBoxまたはIdentifiedMediaDataBoxを含むMedia Segmentの開始までに関連する。オフセットは、バイト単位で示すことができる。実施形態は、上ではオフセットを参照して説明したが、シンタックス内のオフセットに加え、バイトカウントまたは最終オフセットを含めることによって、バイト範囲に同様に適用することができることが理解される必要がある。同様に、実施形態はオフセットの代わりにバイトカウントにも適用することができ、結果的にファイルリーダまたは別のエンティティは、オフセットを先行オフセット(同じループ内の)の合計として導出することができる。
選択肢1が利用される場合、デコーダを含むクライアントデバイスは、(「sidx」ボックスを含む)Index Segmentの初期部分をフェッチするように構成することができる。Index SegmentはSubsegmentベースでインターリーブされるため、(「sidx」ボックスから見つけた)バイト範囲を使用してSubsegmentによってリクエストされたSubsegmentであり得る。クライアントデバイスは、選択されたMedia Segmentの選択されたSubsegmentをフェッチするようにさらに構成することができ、そのために個々の「imda」ボックスのバイト範囲が、個々の「sidx」ボックスに含まれるreference_type0の参照から取得される。
Media SegmentのURLは、MPDにおいてIndex SegmentのURLとは別個に示されるため、これらは論理的に異なるファイルまたはリソースに存在することが理解されるべきである。したがって、Index Segment内で搬送されるセグメントヘッダは、論理的にメディアデータとは異なるファイル内に存在する。結果的に、SegmentIndexBox中の参照タイプ1のエントリはIndex Segment内にあり、参照タイプ0のエントリはMedia Segment内にあり、バイトオフセットはMedia Segmentそれ自身に関連してSegmentIndexBox内で示されている。DASH MPDは、HTTP URLでバイト範囲を使用することを許可しているため、Index SegmentおよびMediaSegmentは、物理的に同一のファイルに存在することができ、単にMPDで示される異なるバイト範囲を有する。しかしながら、この場合でも、Index SegmentおよびMedia Segmentは、論理的に異なるファイルまたはリソース内にあり、SegmentIndexBoxで与えられるオフセットの解釈は、同じままである。
トラック当たりに1つまたは複数のSegmentIndexBoxが存在するような実施形態を上述してきた。すべてのタイルトラックおよびタイルベーストラックは、典型的にはSAP場所など同じ性質を共有するため、そのようなトラック固有のSegmentIndexBoxは、不要な場合がある。トラック固有のSegmentIndexBoxを回避することによって、バイトカウントの節約を実現することができる。その上、トラック固有のSegmentIndexBoxは、異なるトラックのSegmentIndexBoxを並べるためおよび/またはインターリーブするために、例えば規格における制約を必要とする場合がある。ある実施形態によると、トラックは、同じ1つまたは複数のSegmentIndexBoxを以下の構成で共有する:
- Sub-Representationが使用され、それぞれのSub-Representationは異なるトラックに対応している。
- SubsegmentIndexBoxがセグメントヘッダに存在する(メディアデータをインデックス付けする対応するSegmentIndexBoxの隣に)。
- Initialization Segment内にLevelAssignmentBoxが存在し、トラックベースでレベルの割り振り、つまりレベルに対して示された特徴から示されたトラックへのマッピングを示す。
結果的に、タイルベーストラックおよびタイルベーストラックによって参照されるすべてのタイルトラックに対し、単一のRepresentationが存在することができる。タイルベーストラックが(例えば、「alte」タイプの)トラックグループへのトラック参照を含む場合、コロケートされたタイルトラックの異なるバージョン(例えば、ビットレートおよび/または品質に違いがある)が、単一のRepresentationに存在してもよい。
ある実施形態では、それぞれのSubsegment当たりに単一のMovieFragmentBoxがあり、MovieFragmentBoxはRepresentationのトラックごとにTrackFragmentBoxを含む。他の実施形態で説明されるように、クライアントは、MovieFragmentBoxに対応するIdentifiedMediaDataBoxのバイト範囲を解決することができるか、(URLによって特定される)リソース全体がIdentifiedMediaDataBoxに対応していると結論付けることができる。クライアントは、どのトラックが受信されるかを、例えば現在のビューポートに基づいて決定し、対応するSub-Representation、レベル、およびトラックを結論付ける。選択されたトラックのTrackFragmentBoxにおけるバイトオフセットは、MovieFragmentBoxに対応するIdentifiedMediaDataBoxの開始に関連する。したがって、TrackFragmentBox中のバイトオフセットは、URLおよびIdentifiedMediaDataBox用のバイト範囲の潜在的な開始バイトオフセットと関連して使用して、選択されたトラックのメディアデータをフェッチするためにどのバイト範囲がリクエストされるかを決定することができる。
いくつかの実施形態では、IdentifiedMediaDataBoxを使用する代わりに、新しい新しいタイプのデータ参照:「外部的に与えられたURL」を定義して使用することができる。このURLがファイルリーダに与えられないとファイルを処理することができない。与えられるURLはトラックフラグメントベースで変わる場合がある。ISOBMFFベースのMedia Segmentは、MediaDataBox、IdentifiedMediaDataBoxまたはボックスにカプセル化されていないメディアデータだけを含むようなものである可能性がある。Media Segmentタイプ、プロファイル、またはそのようなものは、どのタイプのMedia Segmentが使用中かを示すことができる。Media Segment URLは、MPDから特定され、ファイルリーダに与えることができる。ファイルリーダは、ファイルリーダに与えられたURLによって特定されたリソースの開始に関連して、SegmentIndexBoxおよび/またはMovieFragmentBoxから取得したバイトオフセットを適用することができる。SegmentIndexBox中の参照タイプ0のエントリは、メディアファイル、例えばファイルリーダに与えられたURLによって特定されたリソース内に入るように指定することができる。
いくつかの実施形態では、Index Segmentは、Index SegmentのSegmentTypeBox(「styp」)に含まれる具体的な4つの文字コードによって識別される。いくつかの実施形態では、他の実施形態によるMedia Segmentは、Media SegmentのSegmentTypeBox(「styp」)に含まれる具体的な4つの文字コードによって識別される。受信機、ファイルリーダなどは、SegmentTypeBoxについて受信した具体的な4つの文字コードに基づいて他の実施形態で説明されるようにSegmentを処理する必要があることを識別することができる。
いくつかの実施形態では、Index Segment形式は、次のように指定されるが、Index Segment形式についての他の類似の実施形態が、他の実施形態で説明される特徴を有して同様に作成され得ることが理解される必要がある。各Index Segmentは「styp」ボックスで始まる必要があり、具体的なブランド、例えば「sibm」は「styp」ボックス中に存在する必要があり得る。この形式のIndex Segmentは、以下のように構成される:すべてのSegmentIndexBoxが、すべてのMovieFragmentBoxに先行する。Index Segmentがいくつかのトラックを記述する場合、すべてのトラックのSubsegmentがアライメントされ、アライメントされた同一のSubsegmentのすべてのMovieFragmentBoxはIndex Segment内で隣接している。つまり、あらゆる他のSubsegmentのいかなるMovieFragmentBoxによってもインターリーブされない。各トラックのMovieFragmentBoxは時間の昇順となる。MovieFragmentBoxはDataEntrySeqNumImdaBoxを参照するサンプルエントリを使用する。Index Segmentは、単一のMedia SegmentまたはすべてのMedia Segmentのいずれかに関連付けられる。Index SegmentはSubsegmentIndexBoxを含むことができる。PreselectionのメインAdaptation SetのRepresentation用のIndex Segmentは、PreselectionのすべてのRepresentation用のSegment Indexを与える。
ある実施形態では、ファイルライタまたは別のエンティティは、1つまたは複数の同一のトラックがIndex Segmentの各Subsegmentの第1のMovieFragmentBoxに一貫して記述されるやり方でIndex Segmentを書き込む。したがって、Subsegmentを記述するためにSegmentIndexBox(「sidx」)が使用される場合、Subsegmentの第1のMovieFragmentBoxに適用される(「sidx」ボックス中の)referenced_sizeは、SubsegmentのすべてのMovieFragmentBoxの集合サイズを示す。ある実施形態では、ファイルライタまたは別のエンティティは、ファイル内で(例えば、SegmentIndexBox中の1に等しい所定のボックスフラグで)またはファイルとともに(例えば、MPDにおいて)、1つまたは複数の同一のトラックがIndex Segmentの各Subsegmentの第1のMovieFragmentBoxに一貫して記述されることを示す。
ある実施形態では、ファイルリーダまたは別のエンティティが、1つまたは複数の同一のトラックがIndex Segmentの各Subsegmentの第1のMovieFragmentBoxに一貫して記述されることを結論付ける。ある実施形態では、前記結論付けることは、ファイルから(例えば、SegmentIndexBox中の1に等しい所定のボックスフラグから)またはファイルとともに(例えば、MPDから)、1つまたは複数の同一のトラックがIndex Segmentの各Subsegmentの第1のMovieFragmentBoxに一貫して記述されるというインジケーションを読取ることに基づいている。ある実施形態では、例えば規格において1つまたは複数の同一のトラックがIndex Segmentの各Subsegmentの第1のMovieFragmentBoxに一貫して記述されることが予め定義され、そのため前記結論付けることが、ファイル、またはRepresentationなどがそのような事前定義がなされた規格(または類似のもの)に準拠していると結論付けることに基づいている。ある実施形態では、その1つまたは複数の同一のトラックがIndex Segmentの各Subsegmentの第1のMovieFragmentBoxに一貫して記述されていると結論付けられた後、ファイルリーダまたは別のエンティティは、referenced_sizeバイトから導出したバイト範囲で単一のHTTP GETリクエストを発行して、SubsegmentのすべてのMovieFragmentBoxをフェッチする。したがって、SubsegmentのすべてのMovieFragmentBoxをフェッチするために、複数のバイト範囲を、ファイルリーダまたは別のエンティティによって結論付ける、またはリクエストする必要はない。
いくつかの実施形態では、Index Segment形式は、次のように指定されるが、Index Segment形式についての他の類似の実施形態が、他の実施形態で説明される特徴を有して同様に作成され得ることが理解される必要がある。各Media Segmentは「styp」ボックスで始まる必要があり、具体的なブランド、例えば「imds」は「styp」ボックス中に存在する必要があり得る。この形式のMedia Segmentは、1つまたは複数のIdentifiedMediaDataBoxにメディアデータを含む(また他のボックスにメディアデータを含むことは許可されていない場合がある)。
図9Aおよび図9Bは、例えば図1の装置10によって具体化される再生デバイスによって実施されるクライアントデバイス動作のプロセスを図示している。図9Aのブロック902に図示されるように、図1の装置10などの装置は、セグメントまたはサブセグメントメタデータからセグメントまたはサブセグメントメディアデータまでのバイトオフセットが、セグメントまたはサブセグメントメディアデータを含むボックスに関連していることを示す情報を受信するために、処理回路12および通信インターフェース16などの手段を含む。ある実施形態では、前記情報は、識別されたメディアデータボックスへのデータ参照を含む。ある実施形態では、前記情報は、識別されたメディアデータボックスに指定されたデータ参照を含むDataReferenceBoxを含むInitialization Segmentを含む。データ参照は、例えばDataEntryImdaBox、DataEntryTfdtBasedImdaBox、DataEntrySeqNumImdaBoxなどであってもよい。
図9Aのブロック904に図示されるように、装置は、トラックの集合用のセグメントまたはサブセグメントメタデータを受信するための処理回路12および通信インターフェース16などの手段を含む。ある実施形態では、トラックの集合用のセグメントまたはサブセグメントメタデータは、Index Segmentを含む。
図9Aのブロック906に図示されるように、図1の装置10などの装置は、セグメントまたはサブセグメントメディアデータを解析することなどによって、セグメントまたはサブセグメントメディアデータ用のロケータを決定するための、処理回路12などの手段を含む。ある実施形態では、セグメントまたはサブセグメントメディアデータ用のロケータは、Media Segment用のHTTP URLであり、これはDASH MPDから決定される。
図9Aのブロック908に図示されるように、装置は、セグメントまたはサブセグメントメディアデータをリクエストするためのロケータに加え、バイト範囲が必要かどうかを判断するための処理回路12などの手段を含む。ある実施形態では、Index Segmentは複数のサブセグメントの情報およびそれらのバイト範囲を含む。したがって、Index Segmentから結論付けられたバイト範囲が、サブセグメントメディアデータをリクエストするためのロケータ(例えば、HTTP URL)に加えて必要とされる。
図9Bのブロック910に図示されるように、装置は、例えばバイト範囲ボックスを解析することによって、バイト範囲が必要とされる状況において、トラックの集合それぞれのために個々のセグメントまたはサブセグメントメディアデータの1つまたは複数のバイト範囲を、セグメントまたはサブセグメントメタデータから決定するための、処理回路12などの手段を含む。
図9Bのブロック912に図示されるように、装置は、トラックの集合からトラックのサブセットを選択するための処理回路12などの手段を含む。
図9Bのブロック914に図示されるように、装置は、個々のロケータを用いたリクエストを通じて選択されたトラックのサブセット用のセグメントまたはサブセグメントメディアデータを受信するための処理回路12および通信インターフェース16などの手段を含む。
図9Bのブロック916に図示されるように、装置は、トラックのサブセットのセグメントまたはサブセグメントメタデータを解析して、セグメントまたはサブセグメントメディアデータを復号化することに適した非カプセル化されたメディアデータを取得するための処理回路12などの手段を含む。
クライアントは、時間的に揃えられたIndexおよびMedia Segmentに対して図9Aおよび図9Bの動作、Index Segmentをフェッチして、Media Segmentがリクエストおよび受信される表現またはトラックを選択する動作を繰り返し実施することができる。クライアントデバイスは、またIndex Segmentと受信したMedia Segmentとをつなぎ合わせて、つなぎ合わせたセグメントをファイル解析および後続の復号化(914および916など)のために渡すこともできる。そのようなつなぎ合わせは、MovieFragmentBoxから導出したバイトオフセットがIdentifiedMediaDataBoxの開始に関連しているおかげで可能であり、したがってどのボックスがつなぎ合わせたセグメント内に存在するか、およびまたはどのつなぎ合わせ順が使用されるかよって影響されない。
図10Aおよび図10Bは、クライアントデバイスの動作で使用されるIndexおよびMedia Segmentのグラフィカルな図である。IndexおよびMedia Segmentは、例としてDASHライブサービス利用と併せて使用することができる。図10Aは、リクエストすること、フェッチすること、および選択動作を図示しており、図10Bは再構築されたつなぎ合わされたファイルを図示している。
個々の「imda」ボックスが存在しない「moof」ボックスは、除去される場合がある。つなぎ合わせたファイル内の「moof」ボックスおよび「imda」の順は、つなぎ合わせたファイル内で「imda」ボックスが関連する「moof」ボックスの後に来る限り、コンテンツ作成者の選択に基づいて配置することができる。
レイトバインディングを伴う360度3DoF映像のビューポート依存のストリーミングに関連して実施形態を説明した。実施形態は、360度映像またはビューポート依存のストリーミングに限定されないことが理解される必要がある。ある実施形態では、表現は6DoF映像、オーバレイ、ビューポイント、または点群データに関するメディア/メタデータを含むことができる。別の実施形態では、タイリングを伴う、2D/3D投影を伴うまたは伴わないあらゆる2D映像メディアを、上で定義したような表現およびアダプテーションセットを利用することによってストリーミングすることができる。アダプティブビットレートロジックを有するプレーヤは、ダウンロードするセグメントがどれかを決定するためにセグメントを利用する。
図11は、例えば図1の装置10によって具体化されるエンコーダによって実施されるメディア提示記述およびセグメントオーサリングのプロセスを図示している。ブロック110に図示されるように、図1の装置10などの装置は、ファイル、または初期化セグメントおよび1つもしくは複数のタイルトラックを有する1つもしくは複数のメディアセグメントを受信するために、処理回路12および通信インターフェース16などの手段を含む。
ブロック112に図示されるように、装置は、表現内の1つまたは複数のタイルトラックをエンコードするための処理回路12などの手段を含む。
ブロック114に図示されるように、装置は、セグメントメタデータとセグメントメディアデータとを分離して、1つまたは複数のメディアセグメントのそれぞれのメディアセグメントの部分を分離するための処理回路12などの手段を含む。
ブロック116に図示されるように、装置は、セグメントメタデータを、1つまたは複数のメディアセグメントのそれぞれのメディアセグメント内でサブセグメントインターリーブ順に並べるための処理回路12などの手段を含む。
装置は、1つまたは複数のメディアセグメントのそれぞれの中でメディアデータのSubsegmentおよびトラック単位のバイト範囲を示すための処理回路12などの手段をさらに含むことができる。図12は、DASHオンデマンドサービス利用と併せて利用することができる例示的なメディアセグメントを図示している。図示される例では、「imda」ボックスがトラックベースでインターリーブされている。これは、トラックのいくつかの連続的なSubsegmentが、1つのリクエストでリクエストされる場合に、好ましい場合がある。別の選択肢は、「imda」ボックスをSubsegmentベースでインターリーブすることである。バイト範囲のリクエストでリクエストされる「imda」ボックスに対応するバイト範囲を決定するために、特定のIndex Segmentベースの実施形態と類似の選択肢が存在する。選択肢には、少なくとも以下が含まれる:
1.Media Segmentの初めにBoxFileIndexBoxを含む。BoxFileIndexBoxは、Media Segmentのトップレベルのボックスを記述する(例えば、そのサイズを与える)。
2.「moof」ボックスの子ボックスとして、または「moof」ボックスの隣に(新しい)バイト範囲ボックス(「byra」)を含む。
3.「sidx」ボックスによって参照される(すなわち、reference_type0で参照される)「moof」ボックスに関連付けられる「imda」ボックスのバイト範囲でSegmentIndexBoxを広げる。
4.新しいボックス「First Data Box Offset」(fdbo)も定義される:第1の「imda」ボックスのバイトオフセットを示すために、fdboは、第1のsidxボックスの前に置かれる。これにより、セグメントヘッダ(sidxおよびmoofボックスを含む)およびimdaボックスのプログレッシブダウンロードが可能になる。加えて、「imda」ボックスのサイズまたはバイト範囲が、上述の任意の方法で示される。FirstDataBoxOffsetBoxの例示的なデータ構造は、以下の通りであってもよい:
aligned(8) class FirstDataBoxOffsetBox
extends FullBox(’fdbo’,version,flags){
unsigned int(32) first_data_box_offset;//第1の「imda」ボックスのバイトオフセット
}
図13は、DASHオンデマンドサービス利用と併せて利用することができる例示的なバイト範囲ボックスを図示している。「imda」ボックスのサブセットだけが受信されるため、(Sub)セグメントを受信した後、そして(Sub)セグメントを解析する前に、「imda」ボックスに関連するバイト範囲についての情報を、再書き込みまたは除去することができる。例えば、BoxFileIndexBoxは、正しいバイト範囲で受信したボックスだけを記述するために更新することができる。
「imda」ボックス(つまりIdentifiedMediaDataBox)を参照して実施形態を説明した。実施形態は、他のタイプのメディアデータボックス、またはボックス構造で搬送されないメディアデータで実現することができることが理解されるべきである。メディアセグメントに元々含まれるバイトオフセットは、すべてのメディアデータが受信されることを想定している場合があるが、実際にはメディアデータは部分的にしか受信されないため、そのような実現形態の欠点は、セグメントヘッダからメディアデータまでのバイトオフセットを補正するために、何らかのサイド情報が必要とされ得ることである。
タイルトラックおよびタイルベーストラックを参照して実施形態を説明した。実施形態は、タイルトラックとタイルベーストラックの代わりにそれぞれサブピクチャトラックおよびエキストラクタトラックなど、他の類似の概念により同じように実現可能であることが理解される必要がある。
タイルまたはMCTSを参照して実施形態を説明した。実施形態は他の類似の概念により、同じように実現可能であることが理解される必要がある。例えば、ドラフトH.266規格(別名、バーサタイル映像符号化)では、サブピクチャは、整数個の完全なスライスから成る矩形領域であり、サブピクチャの境界はピクチャ境界のように扱うことができる。すなわち(復号化)符号化プロセスでは、サブピクチャ境界の外部のサンプル場所へのあらゆる参照は、(復号化)符号化プロセスにおいてサブピクチャ境界の最も近いサンプル場所を使用するためには飽和する可能性がある。
特定のシンタックスに関連して、実施形態を説明した。実施形態は、同一または類似の機能性を有する他のシンタックスに同じように適用されることが理解される必要がある。
特定のシンタックスに関連して、実施形態を説明した。実施形態は、そのようなシンタックスを書き込むエンティティに適用されることが理解される必要がある。例えば、ファイル形式シンタックスに関連して実施形態が説明される場合、実施形態は、ファイル形式シンタックスにしたがってファイルまたはセグメントを作成するファイルライタにも適用される。同様に、実施形態はそのようなシンタックスを読取るエンティティにも適用される。例えば、ファイル形式シンタックスに関連して実施形態が説明される場合、実施形態は、ファイル形式シンタックスにしたがってファイルまたはセグメントを解析または処理するファイルリーダにも適用される。
上述の本発明の例示的な実施形態は、関与するプロセスの理解を支援するために、別個のエンコーダおよびデコーダの装置の点でコーデックを説明した。しかしながら、装置、構造、および動作は、単一のエンコーダ-デコーダ装置/構造/動作として実装できることが理解されよう。さらには、コーダおよびデコーダは一部またはすべての共通要素を共有することが可能である。
上述の例は、装置内のコーデックによって実施される特定の実施形態を説明しているが、他の実施形態があらゆる映像コーデックの一部として実装できることが理解されよう。したがって、例えば、特定の実施形態を、固定または有線の通信経路上で映像符号化を実装することができる映像コーデックに実装することができる。
上述のように、図6、図9A、図9B、および図11は、特定の例示的な実施形態による、装置10、方法、およびコンピュータプログラム製品のフローチャートを含む。フローチャートの各ブロックおよびフローチャート内のブロックの組み合わせは、ハードウェア、ファームウェア、プロセッサ、回路、および/または1つもしくは複数のコンピュータプログラム命令を含むソフトウェアの実行に関連付けられた他のデバイスなどの様々な手段によって実装できることを理解されたい。例えば、上述の手順のうちの1つまたは複数は、コンピュータプログラム命令によって具体化することができる。この点で、上述の手順を具体化するコンピュータプログラム命令は、本発明の実施形態を採用する装置のメモリ14によって記憶され、装置の処理回路12によって実行することができる。諒解されるように、そのようなあらゆるコンピュータプログラム命令は、得られるコンピュータまたは他のプログラム可能装置がフローチャートのブロックで指定される機能を実装すべく、コンピュータまたは他のプログラム可能装置(例えば、ハードウェア)にロードして、マシンを作り出すことができる。このようなコンピュータプログラム命令は、コンピュータ可読メモリに記憶された命令により、その実行がフローチャートのブロックで指定される機能を実装する製造物品を作り出すべく、コンピュータ可読メモリに記憶され、コンピュータ、または他のプログラム可能装置に特定の方式で機能するように指示するものであってもよい。コンピュータプログラム命令は、コンピュータまたは他のプログラム可能装置で実行される命令がフローチャートのブロックで指定される機能を実装するための動作を提供するように、コンピュータ実装のプロセスを作り出すべく、コンピュータまたは他のプログラム可能装置にロードされ、コンピュータまたは他のプログラム可能装置上で一連の動作を実行させるものであってもよい。
したがって、コンピュータプログラム製品は、コンピュータ可読プログラムコード部分などのコンピュータプログラム命令が少なくとも1つの非一時的なコンピュータ可読記憶媒体に記憶され、コンピュータ可読プログラムコード部分などのコンピュータプログラム命令が実行されると、図6、図9A、図9B、および図11のフローチャートと併せてなど上述の機能を実施するように構成される場合に定義される。他の実施形態では、コンピュータ可読プログラムコード部分などのコンピュータプログラム命令は、非一時的なコンピュータ可読記憶媒体によって記憶または具体化される必要はないが、代わりに一時的な媒体によって具体化され、コンピュータ可読プログラムコード部分などのコンピュータプログラム命令が実行されると、上述の機能を実施するようにさらに構成することができる。
したがって、フローチャートのブロックは、指定された機能を実施するための手段の組み合わせ、および指定された機能を実施するための指定された機能を実施するための動作の組み合わせをサポートする。フローチャートの1つまたは複数のブロック、およびフローチャート中のブロックの組み合わせは、指定された機能を実行する特殊目的ハードウェアベースのコンピュータシステム、または特殊目的ハードウェアとコンピュータ命令との適切な組み合わせによって実装可能であることも理解されたい。
いくつかの実施形態では、上述の動作のうちの特定の1つが修正されるか、さらに拡張される場合がある。さらには、いくつかの実施形態では、図2~図4において破線で輪郭が描かれるブロックによって表現されるように、追加的で任意選択の動作が含まれる場合もある。上述の動作に対する修正、追加、または拡張は、あらゆる順序およびあらゆる組み合わせで実施することができる。
本明細書で説明される本発明の多くの修正形態および他の実施形態は、これらの発明に関する当業者であれば想到し、前述の説明および関連図面で提示された教示の便益を有するであろう。したがって、本発明は開示される特定の実施形態に限定されず、修正形態および他の実施形態は、添付の特許請求の範囲に含まれるよう意図されることを理解されたい。その上、前述の説明および関連図面は、要素および/または機能の特定の例示的な組み合わせのコンテキストで例示的な実施形態を説明するが、要素および/または機能の様々な組み合わせが、代替的な実施形態によって添付の特許請求の範囲から逸脱することなく提供され得ることを諒解されたい。この点で、例えば、上で明示的に説明した以外の要素および/または機能の様々な組み合わせが、添付の特許請求の範囲の一部で説明され得るように、やはり企図される。本明細書では具体的な用語が採用されるが、これらは単に一般的で説明的な意味で使用され、限定を目的とはしていない。