本開示のいくつかの態様および実施形態が以下で提供される。当業者に明らかになるように、これらの態様および実施形態のうちのいくつかは独立に適用されてよく、それらのうちのいくつかは組み合わせて適用されてよい。以下の説明では、説明のために、本発明の実施形態の完全な理解をもたらすように具体的な詳細が説明される。しかしながら、様々な実施形態がこれらの具体的な詳細なしに実践され得ることは明らかであろう。図および説明は限定的であることを意図しない。
以下の説明は、例示的な実施形態のみを提供し、本開示の範囲、適用性、または構成を限定することを意図しない。むしろ、例示的な実施形態の以下の説明は、例示的な実施形態を実施することを可能にする説明を当業者に提供する。添付の特許請求の範囲に記載したような本発明の趣旨および範囲から逸脱することなく、様々な変更が要素の機能および構成に加えられ得ることを理解されたい。
本実施形態の十分な理解をもたらすために、以下の説明において具体的な詳細が与えられる。しかしながら、本実施形態がこれらの具体的な詳細なしに実践され得ることが、当業者によって理解されよう。たとえば、不必要な詳細で本実施形態を不明瞭にしないように、回路、システム、ネットワーク、プロセス、および他の構成要素がブロック図の形態で構成要素として示されることがある。他の事例では、本実施形態を不明瞭にすることを避けるために、よく知られている回路、プロセス、アルゴリズム、構造、および技法は、不必要な詳細なしに示されることがある。
また、個々の実施形態がフローチャート、フロー図、データフロー図、構造図、またはブロック図として示されるプロセスとして説明され得ることに留意されたい。フローチャートは逐次プロセスとして動作を説明することがあるが、動作の多くは並列または同時に実行され得る。加えて、動作の順序は並べ替えられてよい。プロセスは、その動作が完了するときに終了するが、図に含まれない追加のステップを有することがある。プロセスは、方法、関数、プロシージャ、サブルーチン、サブプログラムなどに相当し得る。プロセスが関数に相当するとき、その終了は、その関数が呼出し関数またはメイン関数に戻ることに相当し得る。
「コンピュータ可読媒体」という用語は、限定はしないが、ポータブルまたは非ポータブルの記憶デバイス、光記憶デバイス、ならびに命令および/またはデータを記憶、収容、または搬送することができる様々な他の媒体を含む。コンピュータ可読媒体は、データがそこに記憶され得るとともに、ワイヤレスにまたは有線接続を介して伝搬する搬送波および/または一時的な電子信号を含まない、非一時的媒体を含み得る。非一時的媒体の例は、限定はしないが、磁気ディスクもしくは磁気テープ、コンパクトディスク(CD)もしくはデジタル多用途ディスク(DVD)などの光記憶媒体、フラッシュメモリ、メモリ、またはメモリデバイスを含み得る。コンピュータ可読媒体は、プロシージャ、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、クラス、または命令、データ構造、もしくはプログラムステートメントの任意の組合せを表し得る、その上に記憶されたコードおよび/または機械実行可能命令を有し得る。コードセグメントは、情報、データ、引数、パラメータ、またはメモリ内容を渡すことおよび/または受けることによって、別のコードセグメントまたはハードウェア回路に結合され得る。情報、引数、パラメータ、データなどは、メモリ共有、メッセージパッシング、トークンパッシング、ネットワーク送信などを含む、任意の好適な手段を介して渡されてよく、転送されてよく、または送信されてよい。
さらに、実施形態は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、またはこれらの任意の組合せによって実装されてよい。ソフトウェア、ファームウェア、ミドルウェア、またはマイクロコードで実装されるとき、必要なタスクを実行するためのプログラムコードまたはコードセグメント(たとえば、コンピュータプログラム製品)は、コンピュータ可読媒体または機械可読媒体に記憶され得る。プロセッサは、必要なタスクを実行し得る。
ビデオコンテンツは、360度ビデオコンテンツ(仮想現実(VR:virtual reality)コンテンツとも呼ばれる)としてキャプチャおよびコーディングされ得る。以下でより詳細に説明するように、本明細書で説明する1つまたは複数のシステムおよび方法は、ビデオコンテンツの中の1つまたは複数の関心領域(ROI)のシグナリング情報を含むように360度ビデオコンテンツ用のメディアファイルを生成することを対象とする。本明細書で説明する1つまたは複数のシステムおよび方法はまた、ビデオコンテンツからROIをレンダリング用に抽出するために、メディアファイルの中に含まれるシグナリング情報を処理することを対象とする。ビデオコンテンツは、いくつかの時点におけるシーンをキャプチャする画像のセットをスティッチすることによって形成される球形ビデオであってよい。360度ビデオピクチャのROIは、シーンのいくつかの部分をキャプチャするピクチャの事前決定された領域であり得る。場合によっては、ROIは、シーンの動的に決定される部分(たとえば、ユーザによって現在見られているシーンの一部分)に対応することができる。メディアファイルは、ROIの第1のシグナリング情報および第2のシグナリング情報を含み得る。第1のシグナリング情報は、球形ビデオに対応する3次元球形空間における、ROIの第1のロケーションおよびROIの寸法情報を含み得る。第2のシグナリング情報は、球形空間を平面上に投影することによって形成される2次元空間におけるROIの第2のロケーションを含み得る。いくつかの例では、二重シグナリングが、ROIの第1のロケーションと第2のロケーションとの間のマッピングを提供することができる。マッピングは、球形ビデオデータの送信とレンダリングの両方を容易にすることができる。
360度ビデオは、キャプチャされるのかコンピュータ生成されるのかなどにかかわらず、仮想現実ビデオ、拡張現実データ、または任意の他のタイプの360度タイプビデオコンテンツを含むことができる。たとえば、360度ビデオは、没入するユーザの動きによって相関付けられる自然画像および/または合成画像(また、場合によっては音)のレンダリングによって作成される非物質界の中に仮想的に存在するための能力を提供することができ、ユーザがその世界と相互作用することを可能にする。360度ビデオは、一見すると現実的または物理的な方法でそれと相互作用され得る3次元環境を表すことができる。場合によっては、360度ビデオ環境を体験するユーザは、ヘッドマウントディスプレイ(HMD:head-mounted display)などの電子機器、および随意に、いくつかのツールまたは衣類(たとえば、センサが取り付けられた手袋)を使用して、仮想環境と相互作用する。実世界の中でユーザが動くにつれて、仮想環境の中でレンダリングされる画像も変化し、ユーザが仮想環境内で動いているという知覚をユーザに与える。場合によっては、仮想環境は、ユーザの動きと相互に関連する音を含み、音が特定の方向または音源から発生するという印象をユーザに与える。360度ビデオは、極めて高品質でキャプチャおよびレンダリングされ得、真に没入型の360度ビデオまたは仮想現実体験を潜在的にもたらす。360度ビデオ適用例は、特に、ゲーミング、トレーニング、教育、スポーツビデオ、オンラインショッピングを含む。
360度ビデオとは、360度環境における表示用にキャプチャされたビデオである。いくつかの適用例では、実世界からのビデオは、ゲーミングおよび仮想世界において見られることがあるようなコンピュータ生成グラフィックスではなく、仮想現実環境の提示において使用され得る。これらの適用例では、ユーザがユーザの現在のロケーションを体験できるのと同様に、ユーザは別のロケーションを体験することができる。たとえば、ユーザは、サンフランシスコに位置する360度ビデオシステムを使用しながらベルリンの徒歩旅行を体験することができる。
360度ビデオシステムは、ビデオキャプチャデバイスおよびビデオディスプレイデバイスを含むことができ、場合によっては、サーバ、データストレージ、およびデータ送信機器などの、他の中間デバイスも含むことができる。ビデオキャプチャデバイスは、カメラセットを含み得、カメラセットは、各々が異なる方向を向いており異なるビューをキャプチャする複数のカメラのセットを含むことができる。例示的な一例では、カメラセットのロケーションを中心とした完全な360度ビューをキャプチャするために6つのカメラが使用され得る。いくつかのビデオキャプチャデバイスは、もっと少数のカメラを使用してよい。たとえば、いくつかのビデオキャプチャデバイスは、主に横方向に複数のビューをキャプチャするか、または視野が広いレンズを使用する。例示的な一例では、360度の視野を一緒に提供する2つの画像をキャプチャするために、背中合わせに配置された2つの魚眼レンズを装備した1つまたは複数のカメラが使用され得る。ビデオは、一般に、フレームまたはピクチャを含み、ここで、フレームまたはピクチャは、電子的にコーディングされた、シーンの静止画像である。カメラは、通常はカメラのフレームレートと呼ばれる、秒当りいくつかの数のフレームをキャプチャする。
場合によっては、継ぎ目のない360度ビューを提供するために、カメラセットの中のカメラの各々によってキャプチャされたビデオフレーム(または、画像)に対して、画像スティッチングが実行され得る。360度ビデオ生成の場合における画像スティッチングは、ビデオフレームが重複するかまたは別の方法で連結することになるエリアの中の、互いに隣接するカメラ(または、レンズ)からのビデオフレームを合成またはマージすることを伴う。その結果は、ほぼ球形のフレームかつメルカトル投影と類似であることになり、マージされたデータは平面的に表され得る。たとえば、マージされたビデオフレームの中のピクセルは、立方体形状またはいくつかの他の3次元平面形状(たとえば、角錐、8面体、10面体など)の平面上にマッピングされ得る。ビデオキャプチャデバイスおよびビデオディスプレイデバイスは、ラスタ原理で動作することができ、-ビデオフレームがピクセルのグリッドとして扱われることを意味する-その場合、正方形平面、長方形平面、または他の好適な形状の平面が、球状の環境を表すために使用され得る。
平面状の表現にマッピングされた360度ビデオフレームは、記憶および/または送信のために符号化および/または圧縮され得る。符号化および/または圧縮は、ビデオコーデック(たとえば、H.265とも呼ばれる高効率ビデオコーディング(HEVC)規格、H.264と呼ばれるアドバンストビデオコーディング規格、または他の好適なコーデックに準拠するコード)を使用して達成され得、圧縮されたビデオビットストリーム(または、符号化ビデオビットストリーム)、またはビットストリームのグループをもたらす。ビデオコーデックを使用してビデオデータを符号化することが、以下でさらに詳細に説明される。
いくつかの実装形態では、符号化ビデオビットストリームは、メディアフォーマットまたはファイルフォーマットで記憶および/またはカプセル化され得る。記憶されたビットストリームは、たとえば、ネットワークを介して、表示のためにビデオを復号およびレンダリングできる受信機デバイスへ送信され得る。そのような受信機デバイスは、本明細書でビデオディスプレイデバイスと呼ばれることがある。たとえば、360度ビデオシステムは、符号化ビデオデータから(たとえば、国際標準化機構(ISO)ベースメディアファイルフォーマット、および/または導出されるファイルフォーマットを使用して)、カプセル化されたファイルを生成することができる。たとえば、ビデオコーデックは、ビデオデータを符号化することができ、カプセル化エンジンが、ビデオデータを1つまたは複数のISOフォーマットメディアファイルの中にカプセル化することによってメディアファイルを生成することができる。代替または追加として、記憶されたビットストリームは、記憶媒体から受信機デバイスに直接提供されてもよい。
受信機デバイスも、符号化ビデオビットストリームを復号および/または圧縮解除するために、コーデックを実装することができる。符号化ビデオビットストリームがメディアフォーマットまたはファイルフォーマットで記憶および/またはカプセル化される場合、受信機デバイスは、ビデオビットストリームをファイル(または、複数のファイル)の中に詰め込むために使用されたメディアフォーマットまたはファイルフォーマットをサポートすることができ、符号化ビデオデータを生成するためにビデオデータを(また、場合によってはオーディオデータも)抽出することができる。たとえば、受信機デバイスは、カプセル化されたビデオデータを有するメディアファイルを構文解析して符号化ビデオデータを生成することができ、受信機デバイスの中のコーデックは、符号化ビデオデータを復号することができる。
受信機デバイスは、次いで、復号されたビデオ信号をレンダリングデバイス(たとえば、ビデオディスプレイデバイス、プレーヤデバイス、または他の好適なレンダリングデバイス)へ送ることができる。レンダリングデバイスは、たとえば、ヘッドマウントディスプレイ、仮想現実テレビジョン、および他の180度または360度ディスプレイデバイスを含む。一般に、ヘッドマウントディスプレイは、着用者の頭部の動きおよび/または着用者の目の動きを追跡することができる。ヘッドマウントディスプレイは、追跡情報を使用して、着用者が見ている方向に対応する360度ビデオの一部をレンダリングすることができ、その結果、着用者は、その人が実世界を体験することになるのと同様に仮想環境を体験する。レンダリングデバイスは、ビデオがキャプチャされたのと同じフレームレートで、または異なるフレームレートでビデオをレンダリングし得る。
360度ビデオコンテンツのビデオピクチャは、時間インター予測(TIP:temporal inter prediction)を使用して単一レイヤビットストリームとして符号化され得、コード化ビットストリーム全体が、サーバにおいて記憶され得る。場合によっては、360度ビデオコンテンツのピクチャは、TIPおよびレイヤ間予測(ILP:inter-layer prediction)を使用してマルチレイヤビットストリームとして符号化され得る。必要な場合、ビットストリームは、受信機側へ送信され得、デコーダによって完全に復号され得、着用者によって見られているシーンの一部分(たとえば、着用者の頭部および/または目の動きに基づいて決定される)に対応する復号ピクチャの領域が、着用者にレンダリングされ得る。
図1は、符号化デバイス104および復号デバイス112を含むビデオコーディングシステム100の一例を示すブロック図である。符号化デバイス104はソースデバイスの一部であってよく、復号デバイス112は受信デバイスの一部であってよい。ソースデバイスおよび/または受信デバイスは、モバイルもしくは固定の電話ハンドセット(たとえば、スマートフォン、セルラー電話など)、デスクトップコンピュータ、ラップトップもしくはノートブックコンピュータ、タブレットコンピュータ、セットトップボックス、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲーミングコンソール、ビデオストリーミングデバイス、インターネットプロトコル(IP)カメラ、または任意の他の好適な電子デバイスなどの、電子デバイスを含み得る。いくつかの例では、ソースデバイスおよび受信デバイスは、ワイヤレス通信用の1つまたは複数のワイヤレストランシーバを含み得る。本明細書で説明するコーディング技法は、(たとえば、インターネットを介した)ストリーミングビデオ送信、テレビジョン放送もしくは送信、データ記憶媒体に記憶するためのデジタルビデオの符号化、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例を含む、様々なマルチメディア用途におけるビデオコーディングに適用可能である。いくつかの例では、システム100は、ビデオ会議、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、ゲーミング、および/またはビデオ電話などの適用例をサポートするために、一方向または双方向のビデオ送信をサポートすることができる。
符号化デバイス104(すなわち、エンコーダ)は、符号化ビデオビットストリームを生成するためのビデオコーディング規格またはビデオコーディングプロトコルを使用して、ビデオデータを符号化するために使用され得る。ビデオコーディング規格の例は、そのスケーラブルビデオコーディング(SVC)拡張およびマルチビュービデオコーディング(MVC)拡張を含む、ITU-T H.261、ISO/IEC MPEG-1 Visual、ITU-T H.262またはISO/IEC MPEG-2 Visual、ITU-T H.263、ISO/IEC MPEG-4 Visual、ITU-T H.264(ISO/IEC MPEG-4 AVCとも呼ばれる)、ならびに高効率ビデオコーディング(HEVC)すなわちITU-T H.265を含む。レンジ拡張およびスクリーンコンテンツコーディング拡張、3Dビデオコーディング(3D-HEVC)拡張およびマルチビュー拡張(MV-HEVC)、ならびにスケーラブル拡張(SHVC)を含む、マルチレイヤビデオコーディングを扱うHEVCの様々な拡張が存在する。HEVCおよびその拡張は、ビデオコーディング共同研究部会(JCT-VC)、ならびにITU-Tビデオコーディングエキスパートグループ(VCEG)およびISO/IECモーションピクチャエキスパートグループ(MPEG)の3Dビデオコーディング拡張開発共同研究部会(JCT-3V)によって開発されている。MPEGおよびITU-T VCEGはまた、次世代のビデオコーディング規格用の新たなコーディングツールを探究するために、共同探究ビデオチーム(JVET)を形成している。参照ソフトウェアは、JEM(共同探究モデル)と呼ばれる。
本明細書で説明する多くの実施形態が、JEMモデル、HEVC規格および/またはその拡張を使用する例を提供する。しかしながら、本明細書で説明する技法およびシステムはまた、AVC、MPEG、それらの拡張、あるいはすでに利用可能であるかまたはまだ利用可能もしくは開発済みでない他の好適なコーディング規格などの、他のコーディング規格に適用可能であり得る。したがって、本明細書で説明する技法およびシステムは特定のビデオコーディング規格を参照しながら説明されることがあるが、説明がその特定の規格だけに適用されるものと解釈されるべきでないことを、当業者なら諒解されよう。
図1を参照すると、ビデオソース102は、ビデオデータを符号化デバイス104に提供し得る。ビデオソース102は、ソースデバイスの一部であってよく、またはソースデバイス以外のデバイスの一部であってもよい。ビデオソース102は、ビデオキャプチャデバイス(たとえば、ビデオカメラ、カメラフォン、ビデオフォンなど)、記憶されたビデオを収容するビデオアーカイブ、ビデオデータを提供するビデオサーバもしくはコンテンツプロバイダ、ビデオサーバもしくはコンテンツプロバイダからビデオを受信するビデオフィードインターフェース、コンピュータグラフィックスビデオデータを生成するためのコンピュータグラフィックスシステム、そのようなソースの組合せ、または任意の他の好適なビデオソースを含み得る。
ビデオソース102からのビデオデータは、1つまたは複数の入力ピクチャまたは入力フレームを含み得る。ビデオのピクチャまたはフレームは、シーンの静止画像である。符号化デバイス104のエンコーダエンジン106(または、エンコーダ)は、ビデオデータを符号化して符号化ビデオビットストリームを生成する。いくつかの例では、符号化ビデオビットストリーム(または、「ビデオビットストリーム」もしくは「ビットストリーム」)は、一連の1つまたは複数のコード化ビデオシーケンスである。コード化ビデオシーケンス(CVS:coded video sequence)は、ベースレイヤの中でいくつかの特性を伴うランダムアクセスポイントピクチャを有するアクセスユニット(AU:access unit)から始めて、ベースレイヤの中でいくつかの特性を伴うランダムアクセスポイントピクチャを有する次のAUの直前までの、一連のAUを含む。たとえば、CVSを開始するランダムアクセスポイントピクチャのいくつかの特性は、1に等しいRASLフラグ(たとえば、NoRaslOutputFlag)を含み得る。そうでない場合、ランダムアクセスポイントピクチャ(0に等しいRASLフラグを有する)はCVSを開始しない。アクセスユニット(AU)は、1つまたは複数のコード化ピクチャ、および同じ出力時間を共有するコード化ピクチャに対応する制御情報を含む。ピクチャのコード化スライスは、ビットストリームレベルにおいて、ネットワークアブストラクションレイヤ(NAL:network abstraction layer)ユニットと呼ばれるデータ単位の中にカプセル化される。たとえば、HEVCビデオビットストリームは、NALユニットを含む1つまたは複数のCVSを含み得る。NALユニットの各々は、NALユニットヘッダを有する。一例では、ヘッダは、H.264/AVCに対して1バイト(マルチレイヤ拡張を除いて)、HEVCに対して2バイトである。NALユニットヘッダの中のシンタックス要素は、指定されたビットを取り、したがって、すべての種類のシステム、および特にトランスポートストリーム、リアルタイムトランスポート(RTP)プロトコル、ファイルフォーマットなどの、トランスポートレイヤにとって認識可能である。
ビデオコーディングレイヤ(VCL:video coding layer)NALユニットおよび非VCL NALユニットを含む、NALユニットの2つのクラスがHEVC規格に存在する。VCL NALユニットは、コード化ピクチャデータの1つのスライスまたはスライスセグメント(以下で説明する)を含み、非VCL NALユニットは、1つまたは複数のコード化ピクチャに関係する制御情報を含む。場合によっては、NALユニットはパケットと呼ばれることがある。HEVC AUは、コード化ピクチャデータを含むVCL NALユニット、および(もしあれば)コード化ピクチャデータに対応する非VCL NALユニットを含む。
NALユニットは、ビデオの中のピクチャのコード化表現などの、ビデオデータのコード化表現を形成するビットのシーケンス(たとえば、符号化ビデオビットストリーム、ビットストリームのCVSなど)を含み得る。エンコーダエンジン106は、各ピクチャを複数のスライスに区分することによって、ピクチャのコード化表現を生成する。スライスの中の情報が、同じピクチャ内の他のスライスからのデータに依存することなくコーディングされるように、スライスは他のスライスとは無関係である。スライスは、独立したスライスセグメント、および存在する場合、前のスライスセグメントに依存する1つまたは複数の従属したスライスセグメントを含む、1つまたは複数のスライスセグメントを含む。スライスは、次いで、ルーマサンプルおよびクロマサンプルのコーディングツリーブロック(CTB:coding tree block)に区分される。ルーマサンプルのCTB、およびクロマサンプルの1つまたは複数のCTBは、サンプル用のシンタックスとともにコーディングツリーユニット(CTU:coding tree unit)と呼ばれる。CTUは、HEVC符号化のための基本処理単位である。CTUは、様々なサイズの複数のコーディングユニット(CU:coding unit)に分割され得る。CUは、コーディングブロック(CB:coding block)と呼ばれるルーマサンプルアレイおよびクロマサンプルアレイを含む。
ルーマCBおよびクロマCBは、さらに予測ブロック(PB:prediction block)に分割され得る。PBは、(使用するために利用可能であるかまたは有効にされているとき)インター予測またはイントラブロックコピー予測のために同じ動きパラメータを使用するルーマ成分またはクロマ成分のサンプルのブロックである。ルーマPBおよび1つまたは複数のクロマPBは、関連するシンタックスとともに予測ユニット(PU:prediction unit)を形成する。インター予測の場合、動きパラメータのセット(たとえば、1つまたは複数の動きベクトル、参照インデックスなど)は、PUごとにビットストリームの中でシグナリングされ、ルーマPBおよび1つまたは複数のクロマPBのインター予測のために使用される。動きパラメータは、動き情報と呼ばれることもある。CBはまた、1つまたは複数の変換ブロック(TB:transform block)に区分され得る。TBは、予測残差信号をコーディングするために同じ2次元変換がそこで適用される、色成分のサンプルの正方形ブロックを表す。変換ユニット(TU:transform unit)は、ルーマサンプルおよびクロマサンプルのTB、ならびに対応するシンタックス要素を表す。
CUのサイズは、コーディングモードのサイズに対応し、形状が正方形であり得る。たとえば、CUのサイズは、8×8サンプル、16×16サンプル、32×32サンプル、64×64サンプル、または対応するCTUのサイズまでの任意の他の適切なサイズであってよい。本明細書で使用する「N×N」という句は、垂直寸法および水平寸法に関してビデオブロックのピクセル寸法(たとえば、8ピクセル×8ピクセル)を指すために使用される。ブロックの中のピクセルは、行および列をなして配置され得る。いくつかの実施形態では、ブロックは、水平方向において垂直方向と同じ数のピクセルを有しなくてもよい。CUに関連するシンタックスデータは、たとえば、1つまたは複数のPUへのCUの区分を記述し得る。区分モードは、CUがイントラ予測モード符号化されるのか、それともインター予測モード符号化されるのかの間で異なり得る。PUは、形状が非正方形であるように区分されてよい。CUに関連するシンタックスデータはまた、たとえば、CTUによる1つまたは複数のTUへのCUの区分を記述し得る。TUは、形状が正方形または非正方形であり得る。
HEVC規格によれば、変換は、変換ユニット(TU)を使用して実行され得る。TUは、異なるCUに対して異なってよい。TUは、所与のCU内のPUのサイズに基づいてサイズ決定され得る。TUは、同じサイズであってよく、またはPUよりも小さくてもよい。いくつかの例では、CUに対応する残差サンプルは、残差4分木(RQT:residual quad tree)と呼ばれる4分木構造を使用して、より小さいユニットに再分割され得る。RQTのリーフノードは、TUに対応し得る。TUに関連するピクセル差分値は、変換係数を生成するように変換され得る。変換係数は、次いで、エンコーダエンジン106によって量子化され得る。
ビデオデータのピクチャがCUに区分されると、エンコーダエンジン106は、予測モードを使用して各PUを予測する。予測ユニットまたは予測ブロックは、次いで、残差(以下で説明する)を得るために元のビデオデータから減算される。CUごとに、予測モードが、シンタックスデータを使用してビットストリームの内部でシグナリングされ得る。予測モードは、イントラ予測(または、イントラピクチャ予測)またはインター予測(または、インターピクチャ予測)を含み得る。イントラ予測は、ピクチャ内で空間的に隣接するサンプル間の相関を利用する。たとえば、イントラ予測を使用すると、たとえば、PUにとっての平均値を見つけるためのDC予測、平坦面をPUに適合させるための平面予測、隣接データから外挿するための方向予測、または任意の他の好適なタイプの予測を使用して、同じピクチャの中の隣接画像データから各PUが予測される。インター予測は、画像サンプルのブロックに対する動き補償予測を導出するために、ピクチャ間の時間的な相関を使用する。たとえば、インター予測を使用すると、(出力順序において現在ピクチャの前または後の)1つまたは複数の参照ピクチャの中の画像データからの動き補償予測を使用して、各PUが予測される。ピクチャエリアを、インターピクチャ予測を使用してコーディングすべきか、それともイントラピクチャ予測を使用してコーディングすべきかという決定は、たとえば、CUレベルにおいて行われ得る。
いくつかの例では、ピクチャの1つまたは複数のスライスは、スライスタイプが割り当てられる。スライスタイプは、Iスライス、Pスライス、およびBスライスを含む。Iスライス(独立に復号可能なイントラフレーム)は、イントラ予測のみによってコーディングされているピクチャのスライスであり、したがって、Iスライスがスライスの任意の予測ユニットまたは予測ブロックを予測するためにフレーム内のデータしか必要としないので、独立に復号可能である。Pスライス(単方向予測フレーム)は、イントラ予測を用いて、かつ単方向インター予測を用いてコーディングされ得るピクチャのスライスである。Pスライス内の各予測ユニットまたは予測ブロックは、イントラ予測またはインター予測のいずれかを用いてコーディングされる。インター予測が適用されるとき、予測ユニットまたは予測ブロックは、1つの参照ピクチャのみによって予測され、したがって、参照サンプルは、1つのフレームの1つの参照領域だけからのものである。Bスライス(双方向予測フレーム)は、イントラ予測を用いて、かつインター予測(たとえば、双予測または単予測のいずれか)を用いてコーディングされ得るピクチャのスライスである。Bスライスの予測ユニットまたは予測ブロックは、2つの参照ピクチャから双方向に予測され得、ここで、各ピクチャは、1つの参照領域に寄与し、2つの参照領域のサンプルセットが重み付けられて(たとえば、等しい重みを用いて、または異なる重みを用いて)、双方向予測ブロックの予測信号を生成する。上述のように、1つのピクチャのスライスは、独立にコーディングされる。場合によっては、ピクチャは、ただ1つのスライスとしてコーディングされ得る。
PUは、予測プロセスに関係するデータ(たとえば、動きパラメータまたは他の好適なデータ)を含み得る。たとえば、PUがイントラ予測を使用して符号化されるとき、PUは、PU用のイントラ予測モードを記述するデータを含み得る。別の例として、PUがインター予測を使用して符号化されるとき、PUは、PU用の動きベクトルを規定するデータを含み得る。PU用の動きベクトルを規定するデータは、たとえば、動きベクトルの水平成分(Δx)、動きベクトルの垂直成分(Δy)、動きベクトルに対する分解能(たとえば、整数精度、1/4ピクセル精度、または1/8ピクセル精度)、動きベクトルが指す参照ピクチャ、参照インデックス、動きベクトル用の参照ピクチャリスト(たとえば、リスト0、リスト1、またはリストC)、またはそれらの任意の組合せを記述し得る。
符号化デバイス104は、次いで、変換および量子化を実行し得る。たとえば、予測に続いて、エンコーダエンジン106は、PUに対応する残差値を計算し得る。残差値は、コーディングされているピクセルの現在ブロック(PU)と現在ブロックを予測するために使用される予測ブロック(たとえば、現在ブロックの予測されたバージョン)との間のピクセル差分値を備え得る。たとえば、予測ブロックを生成した(たとえば、インター予測またはイントラ予測を発した)後、エンコーダエンジン106は、予測ユニットによって生成された予測ブロックを現在ブロックから減算することによって、残差ブロックを生成することができる。残差ブロックは、現在ブロックのピクセル値と予測ブロックのピクセル値との間の差分を定量化するピクセル差分値のセットを含む。いくつかの例では、残差ブロックは、2次元のブロックフォーマット(たとえば、ピクセル値の2次元行列または2次元アレイ)で表され得る。そのような例では、残差ブロックは、ピクセル値の2次元表現である。
予測が実行された後に残ることがある任意の残差データは、ブロック変換を使用して変換され、ブロック変換は、離散コサイン変換、離散サイン変換、整数変換、ウェーブレット変換、他の好適な変換関数、またはそれらの任意の組合せに基づき得る。場合によっては、1つまたは複数のブロック変換(たとえば、サイズ32×32、16×16、8×8、4×4、または他の好適なサイズ)が、各CUにおける残差データに適用され得る。いくつかの実施形態では、エンコーダエンジン106によって実施される変換プロセスおよび量子化プロセスのためにTUが使用され得る。1つまたは複数のPUを有する所与のCUはまた、1つまたは複数のTUを含み得る。以下でさらに詳細に説明するように、残差値は、ブロック変換を使用して変換係数に変換され得、次いで、TUを使用して量子化および走査されて、エントロピーコーディングのためのシリアル化変換係数を生成し得る。
いくつかの実施形態では、CUのPUを使用するイントラ予測コーディングまたはインター予測コーディングに続いて、エンコーダエンジン106は、CUのTUに対する残差データを計算し得る。PUは、空間領域(すなわち、ピクセル領域)におけるピクセルデータを備え得る。TUは、ブロック変換を適用した後の、変換領域における係数を備え得る。前記のように、残差データは、符号化されていないピクチャのピクセルとPUに対応する予測値との間のピクセル差分値に相当し得る。エンコーダエンジン106は、CUに対する残差データを含むTUを形成し得、次いで、TUを変換してCUに対する変換係数を生成し得る。
エンコーダエンジン106は、変換係数の量子化を実行し得る。量子化は、変換係数を量子化することによってさらなる圧縮をもたらして、係数を表すために使用されるデータの量を低減する。たとえば、量子化は、係数の一部または全部に関連するビット深度を低減し得る。一例では、nビット値を有する係数は、量子化の間にmビット値に切り捨てられてよく、nはmよりも大きい。
量子化が実行されると、コード化ビデオビットストリームは、量子化変換係数、予測情報(たとえば、予測モード、動きベクトル、ブロックベクトルなど)、区分情報、および他のシンタックスデータなどの任意の他の好適なデータを含む。コード化ビデオビットストリームの様々な要素が、次いで、エンコーダエンジン106によってエントロピー符号化され得る。いくつかの例では、エンコーダエンジン106は、既定の走査順序を利用して量子化変換係数を走査して、エントロピー符号化され得るシリアル化ベクトルを生成し得る。いくつかの例では、エンコーダエンジン106は適応走査を実行し得る。量子化変換係数を走査してベクトル(たとえば、1次元ベクトル)を形成した後、エンコーダエンジン106は、ベクトルをエントロピー符号化し得る。たとえば、エンコーダエンジン106は、コンテキスト適応型可変長コーディング、コンテキスト適応型バイナリ算術コーディング、シンタックスベースコンテキスト適応型バイナリ算術コーディング、確率間隔区分エントロピーコーディング、または別の好適なエントロピー符号化技法を使用してよい。
前に説明したように、HEVCビットストリームは、VCL NALユニットおよび非VCL NALユニットを含む、NALユニットのグループを含む。VCL NALユニットは、コード化ビデオビットストリームを形成するコード化ピクチャデータを含む。たとえば、コード化ビデオビットストリームを形成するビットのシーケンスが、VCL NALユニットの中に存在する。非VCL NALユニットは、他の情報に加えて、符号化ビデオビットストリームに関係する高レベル情報を有するパラメータセットを含み得る。たとえば、パラメータセットは、ビデオパラメータセット(VPS:video parameter set)、シーケンスパラメータセット(SPS:sequence parameter set)、およびピクチャパラメータセット(PPS:picture parameter set)を含み得る。パラメータセットの目的の例は、ビットレート効率、エラーレジリエンシー、およびシステムレイヤインターフェースを提供することを含む。各スライスは、スライスを復号するために復号デバイス112が使用し得る情報にアクセスするために、単一のアクティブなPPS、SPS、およびVPSを参照する。識別子(ID)は、パラメータセットごとにコーディングされてよく、VPS ID、SPS ID、およびPPS IDを含む。SPSは、SPS IDおよびVPS IDを含む。PPSは、PPS IDおよびSPS IDを含む。各スライスヘッダは、PPS IDを含む。IDを使用すると、アクティブなパラメータセットが所与のスライスに対して識別され得る。
PPSは、所与のピクチャの中のすべてのスライスに適用される情報を含む。このことにより、ピクチャの中のすべてのスライスは、同じPPSを参照する。異なるピクチャの中のスライスも、同じPPSを参照し得る。SPSは、同じコード化ビデオシーケンス(CVS)またはビットストリームの中のすべてのピクチャに適用される情報を含む。前に説明したように、コード化ビデオシーケンスは、ベースレイヤの中で(上記で説明した)いくつかの特性を伴うランダムアクセスポイントピクチャ(たとえば、瞬時復号参照(IDR:instantaneous decode reference)ピクチャもしくはブロークンリンクアクセス(BLA:broken link access)ピクチャ、または他の適切なランダムアクセスポイントピクチャ)から始めて、ベースレイヤの中でいくつかの特性を伴うランダムアクセスポイントピクチャを有する次のアクセスユニット(AU)の直前(または、ビットストリームの末尾)までの、一連のAUである。SPSの中の情報は、コード化ビデオシーケンス内でピクチャからピクチャへと変化しないことがある。コード化ビデオシーケンスの中のピクチャは、同じSPSを使用し得る。VPSは、コード化ビデオシーケンス内またはビットストリーム内のすべてのレイヤに適用される情報を含む。VPSは、コード化ビデオシーケンス全体に適用されるシンタックス要素を有するシンタックス構造を含む。いくつかの実施形態では、VPS、SPS、またはPPSは、符号化ビットストリームとともにインバンド(in-band)で送信され得る。いくつかの実施形態では、VPS、SPS、またはPPSは、コード化ビデオデータを含むNALユニットとは別個の送信の中で、アウトオブバンド(out-of-band)で送信され得る。
ビデオビットストリームはまた、補足エンハンスメント情報(SEI)メッセージを含むことができる。たとえば、SEI NALユニットは、ビデオビットストリームの一部であり得る。場合によっては、SEIメッセージは、復号プロセスによって必要とされない情報を含むことができる。たとえば、SEIメッセージの中の情報は、デコーダがビットストリームのビデオピクチャを復号するのに必須でないことがあるが、デコーダは、ピクチャ(たとえば、復号出力)の表示または処理を改善するためにその情報を使用することができる。SEIメッセージの中の情報は、埋込みメタデータであってよい。例示的な一例では、SEIメッセージの中の情報は、コンテンツの視認性を改善するためにデコーダ側エンティティによって使用され得る。いくつかの事例では、いくつかのアプリケーション規格は、アプリケーション規格に準拠するすべてのデバイスに品質の改善がもたらされ得るように、ビットストリームの中にそのようなSEIメッセージの存在を要求することがある(たとえば、多くの他の例に加えて、SEIメッセージがビデオのすべてのフレームに対して搬送されるフレーム互換平面立体視3DTVビデオフォーマット用のフレームパッキングSEIメッセージの搬送、回復点SEIメッセージの処理、DVBにおけるパンスキャン矩形SEIメッセージの使用)。
符号化デバイス104の出力部110は、符号化ビデオビットストリームデータを構成するNALユニットを、通信リンク120を介して受信デバイスとしての復号デバイス112へ送り得る。復号デバイス112の入力部114は、NALユニットを受信し得る。通信リンク120は、ワイヤレスネットワーク、有線ネットワーク、または有線ネットワークとワイヤレスネットワークとの組合せによって提供される、チャネルを含み得る。ワイヤレスネットワークは、任意のワイヤレスインターフェースまたはワイヤレスインターフェースの組合せを含んでよく、任意の好適なワイヤレスネットワーク(たとえば、インターネットまたは他のワイドエリアネットワーク、パケットベースネットワーク、WiFi(商標)、無線周波数(RF)、UWB、WiFi-Direct、セルラー、ロングタームエボリューション(LTE)、WiMax(商標)など)を含んでよい。有線ネットワークは、任意の有線インターフェース(たとえば、ファイバー、イーサネット(登録商標)、電力線イーサネット(登録商標)、同軸ケーブルを介したイーサネット(登録商標)、デジタル信号ライン(DSL)など)を含んでよい。有線ネットワークおよび/またはワイヤレスネットワークは、基地局、ルータ、アクセスポイント、ブリッジ、ゲートウェイ、スイッチなどの様々な機器を使用して実装され得る。符号化ビデオビットストリームデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調されてよく、受信デバイスへ送信されてよい。
いくつかの例では、符号化デバイス104は、符号化ビデオビットストリームデータをストレージ108に記憶し得る。出力部110は、エンコーダエンジン106から、またはストレージ108から、符号化ビデオビットストリームデータを取り出し得る。ストレージ108は、分散されるかまたは局所的にアクセスされる様々なデータ記憶媒体のうちのいずれかを含み得る。たとえば、ストレージ108は、ハードドライブ、ストレージディスク、フラッシュメモリ、揮発性メモリもしくは不揮発性メモリ、または符号化ビデオデータを記憶するための任意の他の好適なデジタル記憶媒体を含み得る。
復号デバイス112の入力部114は、符号化ビデオビットストリームデータを受信し、デコーダエンジン116に、またはデコーダエンジン116によって後で使用できるようにストレージ118に、ビデオビットストリームデータを提供し得る。デコーダエンジン116は、エントロピー復号すること(たとえば、エントロピーデコーダを使用して)、および符号化ビデオデータを構成する1つまたは複数のコード化ビデオシーケンスの要素を抽出することによって、符号化ビデオビットストリームデータを復号し得る。デコーダエンジン116は、次いで、符号化ビデオビットストリームデータを再スケーリングし得、符号化ビデオビットストリームデータに対して逆変換を実行し得る。残差データが、次いで、デコーダエンジン116の予測ステージに渡される。デコーダエンジン116は、次いで、ピクセルのブロック(たとえば、PU)を予測する。いくつかの例では、逆変換の出力(残差データ)に予測が加算される。
復号デバイス112は、復号ビデオをビデオ宛先デバイス122に出力し得、ビデオ宛先デバイス122は、復号ビデオデータをコンテンツの消費者に表示するためのディスプレイまたは他の出力デバイスを含み得る。いくつかの態様では、ビデオ宛先デバイス122は、復号デバイス112を含む受信デバイスの一部であってよい。いくつかの態様では、ビデオ宛先デバイス122は、受信デバイス以外の別個のデバイスの一部であってよい。
いくつかの実施形態では、ビデオ符号化デバイス104および/またはビデオ復号デバイス112は、それぞれ、オーディオ符号化デバイスおよびオーディオ復号デバイスと統合されてよい。ビデオ符号化デバイス104および/またはビデオ復号デバイス112はまた、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、個別論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなどの、上記で説明したコーディング技法を実施するために必要な他のハードウェアまたはソフトウェアを含んでよい。ビデオ符号化デバイス104およびビデオ復号デバイス112は、複合エンコーダ/デコーダ(コーデック)の一部としてそれぞれのデバイスの中に統合されてよい。符号化デバイス104の具体的な詳細の一例が、図14を参照しながら以下で説明される。復号デバイス112の具体的な詳細の一例が、図15を参照しながら以下で説明される。
HEVC規格の拡張は、MV-HEVCと呼ばれるマルチビュービデオコーディング拡張、およびSHVCと呼ばれるスケーラブルビデオコーディング拡張を含む。MV-HEVC拡張およびSHVC拡張は階層化コーディングの概念を共有し、異なるレイヤが符号化ビデオビットストリームの中に含まれる。コード化ビデオシーケンスの中の各レイヤは、固有のレイヤ識別子(ID)によって扱われる。レイヤIDは、NALユニットが関連付けられたレイヤを識別するために、NALユニットのヘッダの中に存在し得る。MV-HEVCでは、異なるレイヤは、ビデオビットストリームの中で同じシーンの異なるビューを表現することができる。SHVCでは、異なる空間解像度(すなわち、ピクチャ解像度)または異なる再構成忠実度でビデオビットストリームを表現する様々なスケーラブルレイヤが提供される。スケーラブルレイヤは、(レイヤID=0である)ベースレイヤ、および(レイヤID=1、2、...nである)1つまたは複数のエンハンスメントレイヤを含み得る。ベースレイヤは、HEVCの最初のバージョンのプロファイルに準拠し得、ビットストリームの中の最低利用可能レイヤを表現する。エンハンスメントレイヤは、空間解像度、時間分解能もしくはフレームレート、および/または再構成忠実度(すなわち、品質)がベースレイヤと比較して増大している。エンハンスメントレイヤは、階層的に編成され、下位レイヤに依存することがある(または、依存しないこともある)。いくつかの例では、異なるレイヤは、単一規格コーデックを使用してコーディングされ得る(たとえば、HEVC、SHVC、または他のコーディング規格を使用してすべてのレイヤが符号化される)。いくつかの例では、異なるレイヤは、多規格コーデックを使用してコーディングされ得る。たとえば、ベースレイヤがAVCを使用してコーディングされてよく、1つまたは複数のエンハンスメントレイヤがHEVC規格に対するSHVC拡張および/またはMV-HEVC拡張を使用してコーディングされてよい。
一般に、レイヤは、VCL NALユニットのセット、および非VCL NALユニットの対応するセットを含む。NALユニットは、特定のレイヤID値が割り当てられる。レイヤが下位レイヤに依存することがあるという意味で、レイヤは階層的であり得る。レイヤセットとは、自蔵式であるビットストリーム内で表されるレイヤのセットを指し、自蔵式とは、レイヤセット内のレイヤが、復号プロセスにおけるレイヤセットの中の他のレイヤに依存することができるが、いかなる他のレイヤにも復号のために依存しないことを意味する。したがって、レイヤセットの中のレイヤは、ビデオコンテンツを表現できる独立したビットストリームを形成することができる。レイヤセットの中のレイヤのセットは、サブビットストリーム抽出プロセスの動作によって別のビットストリームから取得され得る。レイヤセットは、いくつかのパラメータに従って動作することをデコーダが望むときに復号されるべきレイヤのセットに相当し得る。
いくつかの実装形態では、360度ビデオをキャプチャするためのカメラセットは、全方向性カメラ、反射屈折カメラ(レンズおよび湾曲した鏡を使用するカメラ)、魚眼レンズを装備したカメラ、および/または他の好適なカメラを含むことができる。全方向性カメラの一例は、反対方向に焦点を合わせる2つの魚眼レンズを使用するリコーTheta-Sである。
反射屈折カメラや魚眼レンズを有するカメラなどの全方向性カメラは、通常、著しい量のひずみを有する画像をキャプチャする。図2Aおよび図2Bは、魚眼レンズを使用して広い視野をキャプチャする全方向性カメラによってキャプチャされたビデオフレームの例を示す。図2Aの例では、ビデオフレーム200は円形魚眼画像を含む。魚眼レンズは、280度以上のような極めて広い角度をキャプチャすることが可能である。したがって、背中合わせに配置された2つの魚眼レンズを装備したカメラは、360度の(または、それを超える)ビューを一緒に提供する2つの画像をキャプチャすることができる。角度が広くない魚眼レンズは、約45度〜約90度の程度の視野をキャプチャする。視野は、代替または追加として、ラジアンで表現されてもよい。
広い角度をキャプチャするために、魚眼レンズはシーンの画像をひずませる。図2Aに示すように、ビデオフレーム200の中でキャプチャされるシーンは形状が円形であり、この円形領域の中心から外側の縁部までゆがめられる。カメラセンサが長方形であるので、ビデオフレーム200は長方形であり、画像は、ここでは点描を使用して図示される、シーンの一部ではないエリアを含む。これらの領域の中のピクセルはシーンの一部でないので、これらのピクセルは使用できないものと見なされる。
図2Bの例は、フルフレーム魚眼画像を含むビデオフレーム202を含む。このタイプのビデオフレーム202では、角度が広い視野も円形領域の中にキャプチャされており、シーンが円形領域の中にゆがめられている。この例では、画像はスケーリング(たとえば、より大きく)されており、そのため、シーンは長方形フレームの縁部を占める。この例示的なビデオフレーム202は、使用できないエリアを含まず、レンズによってキャプチャされ得るシーンのいくつかの部分は、切り取られているか、またはキャプチャされていない。
上記で説明したように、360度ビデオをキャプチャするために他のタイプのカメラも使用され得る。たとえば、カメラセットは、複数のカメラのセット(たとえば、シーンの十分な数のビューをキャプチャするのに必要とされる、5個、6個、7個、または他の個数のカメラ)を含むことができる。各カメラは、異なる方向を向くことができ、シーンの異なるビューをキャプチャし得る。画像スティッチングが、次いで、カメラセットの中のカメラの各々によってキャプチャされたビデオフレーム(または、画像)に対して実行されて、継ぎ目のない360度ビューを提供し得る。
360度ビデオは、他のフォーマットに再マッピングされ得る。これらの他のフォーマットは、360度ビデオを記憶し、送信し、かつ/または見るために使用され得る。1つの例示的なフォーマットは正距円筒フォーマットである。図3は、2つの魚眼画像302A、302Bに基づく正距円筒ビデオフレーム300の一例を示す。この例示的な正距円筒ビデオフレーム300では、2つの魚眼画像302A、302Bからの使用できるピクセル(たとえば、円形領域の中のピクセル)は、正距円筒フォーマットの中へマッピングされている。この例では、各魚眼画像302A、302Bは180度以上の視野を含み、その結果、一緒に、2つの魚眼画像302A、302Bは、360度の視野を(場合によっては、いくらかの重複を伴って)包含する。
魚眼画像302A、302Bからのピクセルをマッピングすることは、魚眼画像302A、302Bの中でキャプチャされるシーンをゆがめさせず、ビデオフレーム300の縁部に向かってピクセルを伸張するという効果を有する。得られた正距円筒画像は、ビデオフレーム300の上部および下部において伸張されて見えることがある。よく知られている正距円筒投影は、直交する緯度線および経度線を用いて地球の地理が提示されるメルカトル投影である。
様々な実装形態では、魚眼画像302A、302Bは、立方体、円柱、角錐、角錐台、またはいくつかの他の幾何学的形状によって形成される面の上などの他のフォーマットにマッピングされ得る。これらの場合の各々では、魚眼画像302A、302Bの中に存在するひずみは補正され得、使用できないピクセルは除去され得る。平面状のデータはまた、記憶および/または送信のためにひとまとめにすることができ、360度ビデオを表示するために使用され得る。
場合によっては、たとえば、360度ビデオデータを記憶および/もしくは送信するために、またはビデオデータを別のフォーマットに変換するために、中間フォーマットが有用であり得る。たとえば、正距円筒表現は、図4Aおよび図4Bに示すように、ビデオデータを表示するために球形フォーマット(たとえば、球形形状)にマッピングされ得る。
図4Aおよび図4Bは、正距円筒ビデオフレーム400が360度ビデオプレゼンテーションにおいて使用される一例を示す。正距円筒ビデオフレーム400は、球形表現410を形成するように球形空間上にマッピングされ得、得られた球形表現は、ヘッドマウントディスプレイまたはいくつかの他の360度ビデオディスプレイデバイスを使用して、見ている人420に表示され得る。他の例では、正距円筒ビデオフレーム400は、立方体形状、円柱形状、角錐形状、またはいくつかの他の幾何学的形状にマッピングされ得、ここで、幾何学的形状は、ビデオを表示するために360度ビデオディスプレイデバイスによって使用され得る。
上述のように、正距円筒ビデオフレーム400は、完全な360度の視野をキャプチャすることができ、上側領域および下側領域の中のピクセルが伸張および/または圧縮されて見える。360度ビデオプレゼンテーションにおいて正距円筒ビデオフレーム400を使用するために、正距円筒ビデオフレーム400の中のピクセルは球形表現410にマッピングされ得る。このマッピングは、正距円筒ビデオフレーム400の上側領域および下側領域を、球形表現の上部および下部(たとえば、それぞれ「北極」および「南極」)に向かって拡大させるという効果を有することができる。上側領域および下側領域を拡大させることは、正距円筒ビデオフレーム400の中で目に見える、これらのエリアの中のひずみを補正することができる。
正距円筒ビデオフレーム400を球形表現410にマッピングすることは、球形表現の中央(たとえば、赤道)の近くでフレームの幅をおおい隠すという効果をさらに有することができる。正距円筒ビデオフレーム400の左および右の縁部は、「継ぎ目」が現れないように隣り合わせにマッピングされ得る。
正距円筒ビデオフレーム400が球形表現にマッピングされていると、球形表現が表示され得る。見ている人420は、ヘッドマウントディスプレイまたは別の360度ビデオディスプレイデバイスを使用して、球形表現内から球形表現を見ることができる。たいていの場合、見ている人420は、見ている人の観点からの「地上」が球形表現の最下点となるように位置する。場合によっては、ユーザの目が球の中心にあることが想定され得る。様々な実装形態では、球形表現は、(たとえば、見ている人が座っているか、立っているか、またはいくつかの他の位置にいる場合)見ている人の高さおよび/または位置を適合させるように拡大または収縮され得る。
上記で説明したように、本明細書で説明する1つまたは複数のシステムおよび方法は、ビデオコンテンツの中の1つまたは複数の関心領域(ROI)のシグナリング情報を含むように360度ビデオコンテンツ用のメディアファイルを生成することを対象とする。本明細書で説明する1つまたは複数のシステムおよび方法はまた、ビデオコンテンツからROIをレンダリング用に抽出するために、メディアファイルの中に含まれるシグナリング情報を処理することを対象とする。
上述のように、360度ビデオピクチャのROIは、シーンのいくつかの部分をキャプチャするピクチャの事前決定された領域であり得る。そのような場合、ROIは最も関心のある領域と呼ばれることもある。ROIに関係する情報の生成およびシグナリングは、ユーザが与える入力を使用して、サービスプロバイダまたはコンテンツプロバイダによるユーザ統計値に基づいて、または他の好適な技法を使用して、実行され得る。様々な例では、ピクチャに対して決定されるROIは、観衆の視界を導く360度ビデオコンテンツアイテムの特に選ばれた部分、統計的に決定された関心領域、またはシーンの他の事前決定された部分を含むことができる。たとえば、コンテンツの作成者(たとえば、ディレクター、プロデューサー、著者など)は、360度ビデオコンテンツアイテムの中の最も関心のある領域を規定することができる。そのような例では、360度ビデオの再生は、ユーザがその人の頭部を回転させていないか、または別のユーザインターフェース(UI)を通じてビューポートを変化させていないときでさえ、観衆が焦点を当てることをディレクターまたは他の当事者が望む、動的に変化するビューポートを表示することがある。そのようなビューポートは、シーンごとに全方向性ビデオが提供され得る。別の例では、360度ビデオコンテンツアイテムの様々なピクチャの中のROIは、いくつかの360度(または、VR)ビデオコンテンツがストリーミングサービスを通じて提供されたときに、どの領域がユーザによって最も多く要求されたのか、かつ/または見られたのかという、統計値を使用して決定され得る。そのような例では、360度ビデオピクチャの中のROIは、ピクチャのプレゼンテーション時間においてユーザにレンダリングされる可能性が統計的に最も高い領域のうちの1つを含むことができる。
ROIについての情報は、360度ビデオ性能を改善する様々な目的のために使用され得る。たとえば、ROI情報は、360度ビデオ適応ストリーミングにおいて、エッジサーバ、クライアント、および/または他のエンティティによってデータプリフェッチするために使用され得る。別の例では、ROI情報は、VRビデオがトランスコーディング(たとえば、異なるコーデックへの、異なる投影マッピングへの、または他のトランスコーディング動作)されるとき、トランスコーディング最適化のために使用され得る。他の例では、ROI情報は、エッジサーバもしくはキャッシュによるキャッシュ管理、360度ビデオストリーミングサーバによるコンテンツ管理、または他の目的のために使用され得る。場合によっては、ROIのシグナリングは、たとえば、ビデオビットストリームの中のSEIメッセージ、メディアファイルの中のファイルフォーマットサンプルグループ、動的適応ストリーミングオーバーHTTP(DASH:dynamic adaptive streaming over HTTP)メディアプレゼンテーション記述(MPD)要素もしくは属性(たとえば、サンプルグループを使用する)、および/または他のシグナリングメカニズムを使用することによって実行され得る。
360度ビデオの中のROIは、少なくとも2つの方法で規定され得る。たとえば、360度ビデオの中のROIは、2Dピクチャ上の2D直交座標系に基づいてROIを規定するためのものである。ROIを規定するための別の方法は、球座標系に基づいて(たとえば、360度ビデオの球面上の領域を規定することによって)規定され得る。
球座標系に基づいてROIを規定するために、いくつかの方法が使用され得る。たとえば、ROIは、4つの大円のいずれかの4つのセグメントによって囲まれているか、または2つの大円および2つの小円によって囲まれている、球面上の領域として規定され得、各セグメントは球面上の2つの点の間にある。本明細書では、円、大円、および小円は、次のように定義される(また、以下で説明する図5Aおよび図5Bに示される)。すなわち、平面と球との交差が円である(交差が点であるときを除く)。この円のすべての点は、球の表面に属する。オーソドローム(orthodrome)またはリーマン円(Riemannian circle)とも呼ばれる、球の大円は、球と球の中心点を通過する平面との交差である。球の中心および大円の中心は、必ず同じ場所に位置する。この条件を満たさない、球との平面のいかなる他の交差も、小円を形成し得る。
ヘッドマウントディスプレイ(HMD)または非HMDディスプレイ(たとえば、TV、モバイルデバイス、ウェアラブルデバイス、または他の好適な非HMDディスプレイ)において360度ビデオが再生されるとき、ビューポートがユーザにレンダリングされる。ビューポートは、球に接触している(球と点で交差する)平面上の長方形領域であり得、ここで、ビューポート平面はユーザの見ている方向に直交する。ビューポートは、直線的投影(たとえば、JVET-D1030で説明されるような)を適用することによって生成され得る。ビューポートに対応する球上の領域は、4つの大円の4つのセグメントによって囲まれている領域である。
VRビデオの中でのROIのシグナリングのための既存の設計に関して様々な問題が存在する。たとえば、シグナリングが球座標系(球上の領域のシグナリングによる)または2D直交座標系(ピクチャの領域のシグナリングによる)のいずれかにしか基づかないことから問題が起こり得る。球形ビデオデータをレンダリングおよび/または送信するために追加の処理が必要とされることがあり、そのことは、ビデオ処理システム(たとえば、ビデオキャッシュ、メディアゲートウェイ、レンダラなど)の性能に影響を及ぼすことがあり、ビデオコンテンツの送信および/またはレンダリングの際に、劣悪なユーザエクスペリエンスにつながることがある遅延を引き起こすことがある。たとえば、ユーザにとって関心のある特定の球領域(たとえば、シーンの中のオブジェクト)のレンダリングのために、その球領域がシグナリングされる場合、それは容易に識別され得るとともに球形ビデオシーン全体に位置し得るので、球座標系ベースのROIシグナリングはレンダリング観点から有益である。しかしながら、そのような球ベースのシグナリングが配信および復号の最適化のために使用されるとき(たとえば、DASHなどの適応ストリーミングにおいてデータプリフェッチする際に)、独立してコーディングされたピクチャ領域のどのセットが、シグナリングされたROIをカバーする最小セットであるのかを、ローカルキャッシュまたはメディアゲートウェイが見つけ出す必要がある。このことを行うことを可能にするために、キャッシュまたはメディアゲートウェイは、符号化の前に2Dビデオ信号への球ビデオ信号の変換の際に使用された、投影および領域ごとのマッピングを伴う幾何学的処理を実行する必要がある。このことは、キャッシュおよびメディアゲートウェイにとって重い処理負担であるはずである。一方、プレーヤまたはレンダラは、球上のどの領域が、独立してコーディングされた(ROIとしてシグナリングされる)ピクチャ領域によってカバーされるのかを見つけ出す必要があるときに、投影および領域ごとのマッピングの逆の幾何学的処理を適用する必要があることになるので、2D直交座標系ベースのROIシグナリングはレンダリングするために負担を課するが、(たとえば、DASHなどの適応ストリーミングにおいてデータプリフェッチする際に)配信および復号の最適化の観点からは有益である。
別の問題は、球座標系に基づくROIが球上の領域としてシグナリングされるとき、領域に対応するビューポートの寸法(たとえば、幅および高さ)を見つけ出すために、直線的投影が適用される必要があり得ることである。しかしながら、寸法が負担であるかどうかを決定するために直線的投影プロセスを適用する限り、この情報はセッション交渉またはコンテンツ選択の間に必要とされ得る。
場合によっては、2つの大円および2つの小円の4つのセグメントによって囲まれている球面上の領域がビューポートに対応しないとき、問題が起こり得る。たとえば、ビューポートは、2D正距円筒投影されたピクチャの中の非長方形領域(たとえば、図5Aに示すビューポート520全体)に対応し得るが、2つの大円および2つの小円の4つのセグメントによって囲まれている球面上の領域は、ビューポート領域のサブセットのみ(たとえば、ビューポート520の非長方形領域内の長方形領域のみ)に対応し得る。場合によっては、長方形領域が非長方形領域を含むことも可能である(非長方形領域は長方形領域のサブセットである)。しかしながら、長方形領域および非長方形領域は、常に互いに厳密に一致するとは限らない場合がある。
本明細書で説明するシステムおよび方法を使用して360度ビデオコンテンツのために生成されるメディアファイルは、ROIの第1のシグナリング情報および第2のシグナリング情報を含み得る。第1のシグナリング情報は、ROIの第1のロケーションを規定する球形情報、および球形ビデオに対応する3次元球形空間の中のROIの寸法情報を含み得る。第2のシグナリング情報は、球形空間を平面上に投影することによって形成される2次元空間の中のROIの第2のロケーションを規定する2D情報を含み得る。いくつかの例では、二重シグナリングが、ROIの第1のロケーションと第2のロケーションとの間のマッピングを提供することができ、そのことは、球形ビデオデータの送信とレンダリングの両方を容易にすることができる。たとえば、球形ビデオデータは、2次元ビデオフレームの形式でストリーミングアプリケーションによって送信され得る。上記で説明したように、2次元ビデオフレームは、2次元平面上への球形ビデオデータの投影(たとえば、正距円筒投影または他の好適な投影)を実行することによって形成され得る。たとえば、関心があるもの(たとえば、ディレクターズカット、統計的に決定された領域を、レンダリングするための命令、または他の好適な情報)と事前決定されたシーンの一部分に基づいてROIをレンダリングするために、ROIに対応する領域は、第1のロケーションに基づいて球形ビデオの中で識別され得る。その上、第1のロケーションと第2のロケーションとの間のマッピングを介して、ストリーミングアプリケーションは、2次元ビデオフレームのどの領域がROIのレンダリングのためにプリフェッチされるべきであるのかを決定することができる。さらに、2次元ビデオフレームの領域を取得した後、メディアプレーヤまたはレンダラは、たとえば、ROIの寸法情報に基づいて、ROIに対応する領域からのピクセルを識別することができ、抽出されたピクセルをレンダリングすることができる。
図4Aは、関心領域(ROI)430を示す図である。ROI430は、正距円筒ビデオフレーム400の中に含まれるピクセルのサブセットを備えることができる。上記で説明したように、ROI430は、たとえば、見ている人420の現在の視野(FOV:field of view)として提示されるべき事前決定された関心領域(ROI)に対応し得る。事前決定されたROIは、たとえば、見ている人420をシーンのビューの事前決定されたセットを通じて案内するためのディレクターズカット、フレームの統計的に決定された領域などに対応し得る。いくつかの例では、ROI430はまた、たとえば、見ている人420が、見るべきシーンの一部分を制御できるように、球形表現410に対する見ている人420の視界の方向に対応し得る。ROI430は、次いで、見ている人420によって使用されるビューイングデバイスによってレンダリングされるべきビューポートを形成するためにマッピングされ得る。普通の(非360度または非VRの)ビデオと比較して360度ビデオの異なる機能は、360度ビデオでは、通常、(現在の視野(FOV)またはビューイングデバイスのビューポートに対応する)ビデオピクチャによって表されるビデオ領域全体のサブセットしか表示されないが、通常のビデオアプリケーションでは、通常、ビデオ領域全体が表示されることである。FOVまたはビューポートは、ディスプレイデバイスによって現在提示されておりユーザまたは観察者によって見られているエリアである。
図4Bは、ROI430に対応するビューポート460の一例を示す図である。ビューポート460は、球形表現410を形成する球形空間に接触している平面上の領域であり得る。ビューポート460は、平面上へのROI430の直線的投影を実行することによって形成され得る。図4Bの例では、ビューポート平面は、1つの点において球形表現410の球形空間と交差することができ、ユーザ420の見ている方向に直交することができる。
図4Cは、球形表現410の球形空間内でのビューポート460のロケーションを表すことの一例を示す図である。図4Cの例では、ビューポート460のロケーションは、ピッチ角462およびヨー角464によって表され得る。両方の角度は、球形シーン上でのROIのロケーションに基づいて、ユーザの視界の方向から導出され得る。たとえば、球中心472に位置するユーザの視界の、ビューポート460のビューポート中心474に向かう方向は、ベクトル470によって表され得る。ベクトル470は、x-z平面上に投影476を、かつx-y平面上に投影478を形成し得る。ピッチ角462は、投影476とy軸に平行な軸480との間に形成され得る。ヨー角464は、投影478と軸480との間に形成され得る。
ピッチ角462とヨー角464の両方は、ビューポート460のロケーションを、ユーザの頭部および/または眼球の向きに関係付けることができる。たとえば、ピッチ角462は、たとえば、x-z平面に関するユーザの頭部の仰角、x-z平面に関するユーザの眼球の回転、またはx-z平面に関するユーザの任意の他の動きに相当し得る、ベクトル470の仰角を表すことができる。さらに、ヨー角464は、たとえば、x-y平面に関するユーザの頭部の回転角、x-y平面に関するユーザの眼球の回転、またはx-z平面に関するユーザの任意の他の動きに相当し得る、ベクトル470の回転角を表すことができる。ビューポート460のロケーションをピッチ角462およびヨー角464に基づいて表すことによって、ビューポート460によって表される関心領域(ROI)のロケーションは、ユーザの頭部および/または眼球の向きに基づいて効率的に決定され得、これにより、ROIに対応する球形ビデオコンテンツの部分の効率的なレンダリングが可能になる。
ビューポート460の中心474に加えて、ビューポート460の他の属性も、ヨー角464およびピッチ角462に基づいて表され得る。たとえば、図4Dを参照すると、中間点482、484、486、および488は、ビューポート460の縁部間の中間点であり得る。中間点484と488との間の距離は、たとえば、ビューポート460の高さを規定し得、中間点482と486との間の距離は、たとえば、ビューポート460の幅を規定し得る。ビューポート460の高さは、球中心472、中間点484、および中間点488の間に形成されるピッチデルタ角490によって表され得る。さらに、ビューポート460の、図4C〜図4Dとは異なる観点を示す図4Eを参照すると、ビューポート460の幅はまた、球中心472、中間点482、および中間点486の間に形成されるヨーデルタ角492によって表され得る。ビューポート460のロケーション、高さ、および幅は、ROI430の事前決定されたロケーション、事前決定された高さ、および事前決定された幅の、ビューポート460に対応する平面上の直線的投影の結果を表すことができる。
ピッチ角462およびヨー角464と一緒に、ピッチデルタ角490およびヨーデルタ角492は、球形空間の中で、かつユーザの頭部および/または眼球の向きに基づいて、ビューポート460(および、ROI)のロケーションおよび寸法を規定することができる。以下でより詳細に説明するように、ビューポート460のロケーション情報および寸法情報は、メディアファイルの中に含まれる第1のシグナリング情報の一部であり得る。メディアファイルは、たとえば、球形ビデオのレンダリング/送信のために生成された2次元ビデオフレームのセットのビットストリームをカプセル化する、ISOベースメディアファイルであってよい。メディアファイルはまた、ビットストリームをストリーミングするために使用される時限メタデータトラックを含み得る。メディアファイルはまた、ROIを含む2次元ビデオフレームのいくつかの領域に対する第2のシグナリング情報を含み得る。第1のシグナリング情報および第2のシグナリング情報は、ROIをシグナリングするために、メディアファイルの中で一緒にマッピングされ得る。マッピングに基づいて、ROIを含む2次元ビデオフレームの領域は、プリフェッチされ得るとともにレンダラに提供され得る。その上、レンダラは、ビューポート460の寸法情報に基づいて、ROIを表すビデオフレーム領域からピクセルを抽出することができ、ピクセルを表示用にレンダリングすることができる。その結果、追加の処理(たとえば、直線的投影または逆直線的投影を実行すること)が低減され得、そのことは、ビデオ処理システムの性能ならびにユーザエクスペリエンスを改善することができる。
図4A〜図4Eはビューポート460が長方形形状を有することを示すが、ビューポートは他の形状を有することができる。ビューポートの形状は、ビューポートに対応する領域(たとえば、ROI430)が、球形表現410において幾何学的にどのように規定されるのかに基づいて決定され得る。次に図5A〜図5Cを参照すると、図5A〜図5Cは、ROI430の様々な幾何学的定義を示す。図5Aでは、領域501は、円502、504、506、および508によって画定され得る。円502、504、506、および508の各々は、「大円」と呼ばれることがある。円502、504、506、および508の各々は、球形表現410の球形空間と球中心472を通過する平面との交差によって形成され得る。図5Bでは、領域509は、円502および504ならびに円516および518によって画定され得る。上記で説明したように、円502および504は大円と呼ばれることがある。対照的に、円516および518は「小円」と呼ばれ、小円は、球形表現410の球形空間と球中心472を通過しない平面との交差によって形成され得る。
ROI430の幾何学的定義(たとえば、4つの大円によって画定されるのか、それとも2つの大円および2つの小円によって画定されるのか)は、対応するビューポートの形状および寸法を決定することができる。次に図5Cを参照すると、図5Cは、ビューポート520と長方形領域530との間の比較を示す。図5Cに示すように、長方形領域530は、ビューポート520よりも小さく、ビューポート520よりも少数のピクセルしか含まない。もっと大きいビューポートは、HMDまたは他のディスプレイから見られ得るものに対応するものであり、たとえば、より多くのピクセルがユーザに表示され得るので、好ましい。いくつかの実装形態では、ビューポートの中でユーザに提供されるピクセルの数を最大にするために、ROIに対応する領域が大円のみによって形成される場合のみ、ROIがメディアファイルの中でシグナリングされる。そのような制約はまた、ビューポートのレンダリングにおける一様性および予測可能性を改善することができる。たとえば、図5Cを参照すると、レンダラは、長方形領域530の代わりにビューポート520の形状でビューポートをレンダリングすることができ、たとえば、ビューポート高(たとえば、ピッチデルタ角によって表される)を、長方形領域530の上の直線縁部と下の直線縁部との間の高さh'ではなく、ビューポート520の上の湾曲縁部と下の湾曲縁部との間の高さhを表すものとして解釈することができる。
図6Aは、2次元ビデオフレーム602a、602b〜602nのセットを示す。2次元ビデオフレーム602a、602b〜602nの各々は、球形表現410のビデオフレームに対応する。各2次元ビデオフレーム602a、602b〜602nは、たとえば、2次元平面上への球形表現410の対応するビデオフレームの直線的投影を実行することによって形成され得る。2次元ビデオフレーム602a、602b〜602nは、送信用のビデオビットストリームに符号化され得る。
2次元ビデオフレーム602a、602b〜602nの各々は、タイルのセットに分割され得る。ビデオフレーム602a、602b〜602nの中のタイルは動き制約付きタイルであり得、レイヤの中のすべてのピクチャは同じタイル構造を有することができる。そのような場合、タイルは、ビットストリームの所与のレイヤのすべてのフレームにわたって同じロケーションを有する。たとえば、動き制約付きタイルは、他のピクチャの中の同じロケーションにおける1つまたは複数のタイルのみを使用してコーディングされ得るピクチャ(または、フレーム)の中の、特定のロケーションにおけるタイル領域である。たとえば、特定のタイルロケーション内にある参照ピクチャの領域のみが、現在ピクチャの中のその特定のタイルロケーションにおいてタイルを符号化または復号するために使用され得る。ディスプレイデバイスの現在のビューポートを表示する必要があるピクチャのタイルのみが、表示用に提供され得る。図6Aに示すように、各タイルは、異なるビデオフレーム602a、602b〜602nにわたって、指定されたロケーションを有する。一例では、第1のタイルは602a、602b〜602nの中で(0,0)というロケーションを有し、第1のタイルはそのロケーションに基づいて識別され得る。場合によっては、タイルは、タイル番号0〜23、タイル番号1〜24、または他の好適な番号付けなどの、番号が付けられ得る。図6に示すように、タイルは互いに重複しない。2次元ビデオフレーム602a、602b〜602nの各々はまた、球形表現410の対応するフレームから投影された1つまたは複数のROI(または、ビューポート)を含み得る。たとえば、図6Bに示すように、ビューポート520は、ロケーション(1,1)、(1,2)、(2,1)、および(2,2)におけるタイルのグループの中に位置し得る。
上記で説明したように、メディアファイルは、ビデオフレーム602a、602b〜602nを符号化することによって形成されたビットストリームをカプセル化するように生成され得る。メディアファイルはまた、ビットストリームをストリーミングするために使用される(メディアビットストリームを搬送するトラックに加えて)時限メタデータトラックを含むように生成され得る。メディアファイルは、ROI/ビューポートの送信およびレンダリングを容易にするために、(ビューポートに対応する)ROIに対して上記で説明した第1のシグナリング情報および第2のシグナリング情報を含み得る。第1のシグナリング情報は、球形空間の中でのビューポートの(たとえば、ヨー角、ピッチ角、ヨーデルタ角、およびピッチデルタ角によって表される)ロケーションおよび寸法を含み得る。第2のシグナリング情報は、2次元ビデオフレームの中でのビューポートのロケーションを含み得る。2次元ビデオフレームの中でのビューポートのロケーションは、たとえば、ビューポートを含むタイルのロケーション(または、識別子)によって表され得る。図6Bの例の場合、第2のシグナリング情報は、ROIをシグナリングするために、タイルロケーション(1,1)、(1,2)、(2,1)、および(2,2)(または、これらのタイルに関連付けられた識別子/番号)を含み得る。
上記で説明したように、第1のシグナリング情報および第2のシグナリング情報は、ROIをシグナリングするためにメディアファイルの中で一緒にマッピングされ得る。マッピングは、ユーザへのビューポートの効率的な送信およびレンダリングを可能にする。たとえば、ビデオ処理システムは、球形ビデオ410の中の事前決定された関心領域をユーザにレンダリングするための命令を受信することができる。命令は、たとえば、特定の領域の中心のヨー角およびピッチ角を含むことができる。第1のシグナリング情報の中の入力ヨー角および入力ピッチ角に基づいて、ビデオ処理システムは、たとえば、ビューポート520を含む、ビデオフレーム602aの中のピクセルのタイルのセット(または、他の単位)を決定するために、メディアファイルの中での第1のシグナリング情報と第2のシグナリング情報との間のマッピングを参照することができる。その上、ピッチ角、ヨー角、ピッチデルタ角、ヨーデルタ角、およびビューポートの特定の形状のそれらの決定に基づいて(たとえば、球形ビデオ410の中の事前決定された領域が4つの大円に基づいて規定されるという制約に基づいて)、レンダラはまた、タイル内でのビューポート520のロケーションおよび境界を決定することができ、ビューポート520の境界内のピクセルをレンダリング用に抽出することができる。そのような処理は、最低限の幾何学的処理を用いて実行され得、システムの性能ならびにユーザエクスペリエンスを改善することができる。
次に図7を参照すると、図7は、ROIのシグナリング情報を含むISOベースメディアファイル700の一例を示す。ファイル700は、ISOBMFFに従ってフォーマットされ得る。ISOBMFFは、メディアの交換、管理、編集、および提示を容易にするフレキシブルかつ拡張可能なフォーマットで時限メディア情報を含むように設計されている。メディアの提示はプレゼンテーションを含むシステムにとって「局所的」であってよく、または提示はネットワークもしくは他のストリーム配信メカニズムを介してもよい。
ISOBMFF仕様によって定義されるような「プレゼンテーション」とは、しばしば、ビデオキャプチャデバイスによって連続的にキャプチャされていることによって関係するか、またはいくつかの他の理由のために関係する、一連のピクチャである。本明細書では、プレゼンテーションは、ムービーまたはビデオプレゼンテーションと呼ばれることもある。プレゼンテーションはオーディオを含んでよい。1つまたは複数のファイルの中に単一のプレゼンテーションが含まれてよく、1つのファイルが全体のプレゼンテーション用のメタデータを含む。メタデータは、タイミングおよびフレーミングデータ、デスクリプタ、ポインタ、パラメータ、ならびにプレゼンテーションを記述する他の情報などの、情報を含む。メタデータは、ビデオデータおよび/またはオーディオデータ自体を含まない。メタデータを含むファイル以外のファイルは、ISOBMFFに従ってフォーマットされる必要がなく、これらのファイルがメタデータによって参照され得るようにフォーマットされることしか必要としない。
ISOベースメディアファイルのファイル構造はオブジェクト指向であり、ファイルの中の個々のオブジェクトの構造はオブジェクトのタイプから直接推定され得る。ISOベースメディアファイルの中のオブジェクトは、ISOBMFF仕様によって「ボックス」と呼ばれる。ISOベースメディアファイルは、他のボックスを含むことができる一連のボックスとして構造化される。ボックスは、一般に、ボックスに対するサイズおよびタイプを提供するヘッダを含む。サイズは、ヘッダ、フィールド、およびそのボックス内に含まれるすべてのボックスを含む、ボックスのサイズ全体を表す。プレーヤデバイスによって認識されないタイプを有するボックスは、通常、無視およびスキップされる。
図7の例によって図示したように、ファイルのトップレベルにおいて、ISOベースメディアファイル700は、ファイルタイプボックス710、ムービーボックス720、および1つまたは複数のムービーフラグメントボックス730a、730b...730nを含むことができる。このレベルにおいて含まれ得るがこの例では表されない他のボックスは、特に、空き領域ボックス、メタデータボックス、およびメディアデータボックスを含む。
ISOベースメディアファイルは、ボックスタイプ「ftyp」によって識別されるファイルタイプボックス710を含むことができる。ファイルタイプボックス710は、ファイルを構文解析するのに最も適したISOBMFF仕様を識別する。この事例における「最も」とは、ISOベースメディアファイル700が、特定のISOBMFF仕様に従ってフォーマットされていることがあるが、仕様の他の版との互換性がありそうであることを意味する。この最も適した仕様は、メジャーブランドと呼ばれる。プレーヤデバイスは、デバイスがファイルのコンテンツを復号および表示できるかどうかを決定するために、メジャーブランドを使用することができる。ファイルタイプボックス710はまた、ISOBMFF仕様のバージョンを示すために使用され得るバージョン番号を含むことができる。ファイルタイプボックス710はまた、ファイルがそれと互換性のある他のブランドのリストを含む、互換性のあるブランドのリストを含むことができる。ISOベースメディアファイルは、2つ以上のメジャーブランドとの互換性があり得る。
ISOベースメディアファイルは、プレゼンテーション用のメタデータを含むムービーボックス720をさらに含むことができる。ムービーボックス720は、ボックスタイプ「moov」によって識別される。ISO/IEC14496-12は、プレゼンテーションが、1つのファイルの中に含まれるのかそれとも複数のファイルの中に含まれるのかにかかわらず、1つのムービーボックス720しか含むことができないことを定める。しばしば、ムービーボックス720は、ISOベースメディアファイルの冒頭の近くにある。ムービーボックス720は、ムービーヘッダボックス722を含み、1つまたは複数のトラックボックス724、ならびに他のボックスを含むことができる。
ボックスタイプ「mvhd」によって識別されるムービーヘッダボックス722は、メディア独立型であり全体としてプレゼンテーションに関連する情報を含むことができる。たとえば、ムービーヘッダボックス722は、特に、プレゼンテーションにとっての作成時間、修正時間、タイムスケール、および/または持続時間などの情報を含むことができる。ムービーヘッダボックス722はまた、プレゼンテーションにおける次のトラックを識別する識別子を含むことができる。たとえば、識別子は、図示の例ではムービーボックス720によって含められるトラックボックス724を指すことができる。
ボックスタイプ「trak」によって識別されるトラックボックス724は、プレゼンテーションに対するトラック用の情報を含むことができる。プレゼンテーションは、1つまたは複数のトラックを含むことができ、ここで、各トラックは、プレゼンテーションにおける他のトラックから独立している。各トラックは、トラックの中のコンテンツに特有の時間的および空間的な情報を含むことができ、各トラックは、メディアボックスに関連付けられ得る。トラックの中のデータはメディアデータであり得、その場合、トラックはメディアトラックであるか、またはデータはストリーミングプロトコル用のパケット化情報であり得、その場合、トラックはヒントトラックである。メディアデータは、たとえば、ビデオデータおよびオーディオデータを含む。図示の例では、例示的なトラックボックス724が、トラックヘッダボックス724aおよびメディアボックス724bを含む。トラックボックスは、トラック参照ボックス、トラックグループボックス、エディットボックス、ユーザデータボックス、メタボックスなどの、他のボックスを含むことができる。以下で詳細に説明するように、メディアボックス724bは、1つまたは複数のROIのシグナリング情報を含んでよい。
ボックスタイプ「tkhd」によって識別されるトラックヘッダボックス724aは、トラックボックス724の中に含まれるトラックの特性を指定することができる。たとえば、トラックヘッダボックス724aは、特に、トラックの作成時間、修正時間、持続時間、トラック識別子、レイヤ識別子、グループ識別子、ボリューム、幅、および/または高さを含むことができる。メディアトラックの場合、トラックヘッダボックス724aは、特に、トラックが有効にされているかどうか、トラックがプレゼンテーションの一部として再生されるべきであるかどうか、またはトラックがプレゼンテーションをプレビューするために使用され得るかどうかをさらに識別することができる。トラックのプレゼンテーションは、一般に、プレゼンテーションの冒頭にあるものと想定される。トラックボックス724は、明示的タイムラインマップを含むことができる、ここでは図示しないエディットリストボックスを含むことができる。タイムラインマップは、特に、トラックに対するオフセット時間を指定することができ、ここで、オフセットは、トラックに対して、プレゼンテーションの冒頭の後の開始時間を示す。
図示の例では、トラックボックス724はまた、ボックスタイプ「mdia」によって識別されるメディアボックス724bを含む。メディアボックス724bは、オブジェクト、およびトラックの中のメディアデータについての情報を含むことができる。たとえば、メディアボックス724bは、トラックのメディアタイプ、およびトラックの中のメディアがそれによって提示されるプロセスを識別できる、ハンドラ参照ボックスを含むことができる。別の例として、メディアボックス724bは、トラックの中のメディアの特性を指定できるメディア情報ボックスを含むことができる。メディア情報ボックスは、サンプルのテーブルをさらに含むことができ、ここで、各サンプルは、たとえば、サンプルに対するデータのロケーションを含む、メディアデータ(たとえば、ビデオデータまたはオーディオデータ)のチャンクを記述する。サンプルに対するデータは、以下でさらに説明するメディアデータボックスの中に記憶される。他のほとんどのボックスと同様に、メディアボックス724bはまた、メディアヘッダボックスを含むことができる。
図示の例では、例示的なISOベースメディアファイル700はまた、プレゼンテーションの複数のフラグメント730a、730b、...730nを含む。フラグメント730a、730b、...730nはISOBMFFボックスではないが、ムービーフラグメントボックス732、およびムービーフラグメントボックス732によって参照される1つまたは複数のメディアデータボックス738を含む、ボックスの組合せを記述する。ムービーフラグメントボックス732およびメディアデータボックス738はトップレベルボックスであるが、ムービーフラグメントボックス732とメディアデータボックス738との間の関係を示すようにここではグループ化されている。
ボックスタイプ「mfhd」によって識別されるムービーフラグメントヘッダボックス734は、シーケンス番号を含むことができる。プレーヤデバイスは、フラグメント730aがプレゼンテーション用のデータの次の断片を含むことを確認するために、シーケンス番号を使用することができる。場合によっては、ファイルのコンテンツ、またはプレゼンテーション用のファイルは、順序が狂ってプレーヤデバイスに提供され得る。たとえば、ネットワークパケットは、しばしば、パケットが初めに送信された順序以外の順序で到着することがある。これら場合、シーケンス番号は、フラグメントにとっての正しい順序を決定する際にプレーヤデバイスを支援することができる。
ムービーフラグメントボックス732はまた、ボックスタイプ「traf」によって識別される1つまたは複数のトラックフラグメントボックス736を含むことができる。ムービーフラグメントボックス732は、トラックフラグメントのセットをトラック当り0個以上含むことができる。トラックフラグメントは、0個以上のトラックランを含むことができ、その各々は、トラックに対するサンプルの連続するランを記述する。トラックフラグメントは、サンプルをトラックに追加することに加えて、空の時間をトラックに追加するために使用され得る。
ボックスタイプ「mdat」によって識別されるメディアデータボックス738は、メディアデータを含む。ビデオトラックの中で、メディアデータボックス738はビデオフレームを含むことになる。メディアデータボックスは、代替または追加として、オーディオデータを含むことができる。プレゼンテーションは、1つまたは複数の個々のファイルの中に含まれる0個以上のメディアデータボックスを含むことができる。メディアデータはメタデータによって記述される。図示の例では、メディアデータボックス738の中のメディアデータは、トラックフラグメントボックス736の中に含まれるメタデータによって記述され得る。他の例では、メディアデータボックスの中のメディアデータは、ムービーボックス720の中のメタデータによって記述され得る。メタデータは、メディアデータボックス738内のメディアデータヘッダおよび/または空き領域がスキップされ得るように、ファイル700内で絶対オフセットによって特定のメディアデータを参照することができる。
ISOベースメディアファイル700の中の他のフラグメント730b、730c、730nは、第1のフラグメント730aに対して図示したものと類似のボックスを含むことができ、かつ/または他のボックスを含むことができる。
図8は、ISOベースメディアファイルの中に含まれ得るメディアボックス840の一例を示す。上記で説明したように、メディアボックスは、トラックボックスの中に含まれ得、オブジェクト、およびトラックの中のメディアデータを記述する情報を含むことができる。図示の例では、メディアボックス840は、メディア情報ボックス842を含む。メディアボックス840はまた、ここでは図示しない他のボックスを含むことができる。
メディア情報ボックス842は、トラックの中のメディアについての特性情報を記述するオブジェクトを含むことができる。たとえば、メディア情報ボックス842は、トラックの中でのメディア情報のロケーションを記述するデータ情報ボックスを含むことができる。別の例として、メディア情報ボックス842は、トラックがビデオデータを含むとき、ビデオメディアヘッダを含むことができる。ビデオメディアヘッダは、ビデオメディアのコーディングから独立している一般的なプレゼンテーション情報を含むことができる。メディア情報ボックス842はまた、トラックがオーディオデータを含むとき、サウンドメディアヘッダを含むことができる。
メディア情報ボックス842はまた、図示の例で提供されるように、サンプルテーブルボックス844を含むことができる。ボックスタイプ「stbl」によって識別されるサンプルテーブルボックス844は、トラックの中でのメディアサンプルにとってのロケーション(たとえば、ファイルを伴うロケーション)、ならびにサンプルにとっての時間情報を提供することができる。サンプルテーブルボックス844によって提供される情報を使用して、プレーヤデバイスは、特に、正しい時間順序でサンプルの位置を特定することができ、サンプルのタイプを決定することができ、かつ/またはコンテナ内のサンプルのサイズ、コンテナ、およびオフセットを決定することができる。
サンプルテーブルボックス844は、ボックスタイプ「stsd」によって識別されるサンプル記述ボックス846を含むことができる。サンプル記述ボックス846は、たとえば、サンプルに対して使用されるコーディングタイプについての詳細情報、およびそのコーディングタイプにとって必要とされる任意の初期化情報を提供することができる。サンプル記述ボックスの中に記憶される情報は、サンプルを含むトラックのタイプに特有であり得る。たとえば、トラックがビデオトラックであるとき、あるフォーマットがサンプル記述のために使用されてよく、トラックがヒントトラックであるとき、異なるフォーマットが使用されてよい。さらなる例として、サンプル記述のためのフォーマットはまた、ヒントトラックのフォーマットに応じて変わることがある。
サンプル記述ボックス846は、サンプルエントリボックス848a...848nを含むことができる。サンプルエントリは抽象クラスであり、したがって、通常、サンプル記述ボックスは、例の中でも、ビデオデータに対するビジュアルサンプルエントリ、またはオーディオサンプルに対するオーディオサンプルエントリなどの、特定のサンプルエントリボックスを含む。ビデオデータに対する各ビジュアルサンプルエントリは、1つまたは複数のビデオフレームを含み得る。ビデオフレームは、たとえば、球形表現410から生成される2次元ビデオフレーム602a、602b〜602nであり得る。サンプルエントリボックスは、特定のサンプル用のパラメータを記憶することができる。たとえば、ビデオサンプルの場合、サンプルエントリボックスは、特に、ビデオサンプルに対する幅、高さ、水平解像度、垂直解像度、フレームカウント、および/または深度を含むことができる。別の例として、オーディオサンプルの場合、サンプルエントリは、特に、チャネルカウント、チャネルレイアウト、および/またはサンプリングレートを含むことができる。
サンプルエントリボックスに加えて、サンプル記述846は、サンプルグループ記述ボックス860(サンプルグループ記述ボックスタイプ「sgpd」によって識別される)、およびサンプル対グループ(sample to group)ボックス862(サンプル対グループボックスタイプ「sbgp」によって識別される)をさらに含み得る。サンプルグループ記述ボックス860とサンプル対グループボックス862の両方は、サンプルエントリのセットが1つまたは複数のROIを含むことをシグナリングするための、またサンプルエントリのセットの中で1つまたは複数のROIのロケーションおよび寸法をシグナリングするための、サンプルグループ化メカニズムの一部であり得る。図8の例では、サンプルグループ記述ボックス860は、サンプルグループタイプエントリ861を含み得る。サンプルグループタイプエントリ861は、タイプエントリがROI情報を含むことをシグナリングするために、グループタイプ「ROI」を含み得る。サンプルグループタイプエントリ861は、2次元ビデオフレームの中のROIのピクセル座標、ならびに球形空間の中でのROIのヨー角、ピッチ角、ヨーデルタ角、およびピッチデルタ角を示す、シンタックス要素をさらに含み得る。サンプル対グループボックス862は、サンプルグループタイプエントリ861の中のROI情報がサンプル記述846の中のいくつかのサンプルエントリに適用されるべきであることをさらに示す。この情報を用いると、ROIを含むビデオサンプルは、より効率的に識別され得、レンダリングのためにレンダラに提供され得る。
いくつかのビデオシステムは、メディアの局所的な再生をサポートすることに加えて、ネットワークを介してメディアデータをストリーミングすることをサポートする。たとえば、1つまたは複数のISOベースメディアファイルフォーマットファイル(たとえば、ISOBMFF)である。メディアファイルは、ムービープレゼンテーションを含むことができ、1つまたは複数のファイルをパケットとして形成および送信する際にストリーミングサーバを支援できる命令を含むヒントトラックを含むことができる。これらの命令は、たとえば、サーバが送るべきデータ(たとえば、ヘッダ情報)、またはメディアデータのセグメントへの参照を含むことができる。ファイルは、異なるストリーミングプロトコルに対して別個のヒントトラックを含むことができる。ヒントトラックはまた、ファイルを再フォーマットする必要なしにファイルに追加され得る。
次に図9を参照すると、図9は、ストリーミングのための例示的なシステム900を示す。システム900は、ネットワークプロトコルに基づくネットワーク906を介して互いに通信可能に結合されたサーバ902およびクライアントデバイス904を含む。たとえば、サーバ902は、従来のHTTPウェブサーバを含むことができ、クライアントデバイス904は、従来のHTTPクライアントを含み得る。クライアントデバイス904が1つまたは複数のネットワークリソースを要求するためにHTTP要求をサーバ902へ送信できるHTTP通信チャネルが、確立され得る。サーバ902は、要求されたネットワークリソースを含むHTTP応答をクライアントデバイス904へ送信し返すことができる。サーバ902によってホストされるネットワークリソースの一例はメディアコンテンツであり得、メディアコンテンツはメディアセグメントに分割され得る。メディアセグメントは、一連のビデオフレームを含むことができる。クライアントデバイス904は、ネットワーク906を介したサーバ902とのストリーミングセッションを確立するためのストリーミングアプリケーション908を含み得る。ストリーミングセッションの間、ストリーミングアプリケーション908は、1つまたは複数のメディアセグメントを求める要求を、ネットワーク906を介してサーバ902の要求プロセッサ910へ送信することができる。ストリーミングアプリケーション908は、要求された1つまたは複数のメディアセグメントを受信することができ、クライアントデバイス904上で受信されたメディアセグメントの一部または全部をレンダリングしてから、他のメディアセグメントを求める後続の要求を送信することができる。そのようなHTTPストリーミングを使用すると、ストリーミングアプリケーション908は、クライアントデバイス904においてメディアコンテンツをレンダリングする前にメディアコンテンツ全体が完全にダウンロードされるまで待つ必要がなく、そのことは、ネットワークリソースのより良好な利用を容易にするとともにユーザエクスペリエンスを改善することができる。
従来のHTTPウェブサーバを使用してメディアコンテンツの高品質ストリーミングを可能にするために、適応ビットレートストリーミングが使用され得る。適応ビットレートストリーミングを用いると、メディアセグメントごとに、代替セグメントファイル920および940のセットについての情報がクライアントデバイス904に提供され得る。ここで、メディアセグメントは、特定の再生タイムスタンプおよび持続時間に関連する、メディアビットストリームの一部分を参照し得る。代替セグメントファイル920および940の各セットは、メディアセグメントの特定の表現に対応(たとえば、特定の再生タイムスタンプおよび持続時間に関連)し得る。表現は、いくつかのメディアコンテンツを異なる品質を伴って(たとえば、異なるビットレート、フレームレートなどを用いて)符号化することの特定の結果を参照し得る。メディアセグメントファイルの各セットの間で、各メディアセグメントファイルは、たとえば、特定のビットレート、フレームレート、解像度、オーディオ言語などを含む、特性のセットに関連付けられ得る。局所的な情報(たとえば、ネットワーク906の帯域幅、クライアントデバイス904の復号/表示能力、ユーザ選好、または他の情報)に基づいて、ストリーミングアプリケーション908は、表現ごとに、特定のメディアセグメントファイルをセットから選択することができる。例示的な例として、クライアントデバイス904は、メディアセグメントファイル920からの、第1の解像度に関連するメディアセグメントファイルを求める要求を送信することができる。その後、ネットワーク906の帯域幅の変化に起因して、クライアントデバイス904は、第2の解像度に関連するメディアセグメントファイルを求める別の要求を送信してよい。
代替セグメントファイル920および940のセットについての情報は、サーバ902によって保持される記述ファイル960(または、マニフェストファイル)の一部であり得る。クライアントデバイス904は、サーバ902から記述ファイル960を取得することができ、メディアセグメントファイルを求める要求を、記述ファイル960に基づいて送信することができる。記述ファイル960は、たとえば、メディアコンテンツの表現ごとの代替メディアセグメントファイルのセットのリスト、および各代替メディアセグメントファイルに関連する特性(たとえば、ビットレート、フレームレート、解像度、オーディオ言語など)を含み得る。記述ファイル960はまた、代替メディアセグメントファイルの記憶ロケーションに関連するロケーション識別子(たとえば、ユニフォームリソースロケータ(URL)、ユニフォームリソースインジケータ(URI)など)を含むことができる。
適応ビットレートストリーミングのために様々なプロトコルが存在する。一例は、動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(HTTP)、すなわちDASH(ISO/IEC23009-1:2014において定義される)である。DASHはMPEG-DASHとも呼ばれる。DASHの下では、記述ファイル960はメディアプレゼンテーション記述(MPD)を含むことができる。図10は、MPD1001の一例を示す図である。場合によっては、MPD1001は、拡張可能マークアップ言語(XML)で表され得る。MPD1001は、適合セット1002を規定する要素のセットを含むことができる。適合セット1002は、代替表現1003および1004のセットを含むことができる。適合セット1002が表現1003および1004に加えて追加の表現を含むことができることを、当業者は諒解されよう。各代替表現1003および1004は、特定のビットレート、解像度、または他の品質に関連付けられ得、メディアセグメントのセットを含むことができる。たとえば、表現1003は、メディアセグメント1007および1009を、またヘッダ情報1005も含む。表現1004は、メディアセグメント1008および1010を、またヘッダ情報1006も含む。ヘッダ情報1005および1006は、たとえば、「Representation」要素(たとえば、識別子属性、帯域幅属性、幅属性、および高さ属性などを含む)を含み得る。メディアセグメント1007および1009の各々は、MPD1001の中でメディアセグメントファイルのURLに関連付けられてよく、そうしたURLは要素「SegmentURL」として示され得る。MPD1001の中の要素のセットの各々は、たとえば、適合セット1002、表現1003および/もしくは1004、または他の情報の特性を規定する属性のセットに関連付けられてよい。
以下は、MPDの一部の一例である。
<AdaptationSet mimeType="video/mp2t">
<Representation id="720p" bandwidth="3200000" width="1280" height="720">
...
<SegmentURL media="segment-1.DASH"/>
<SegmentURL media="segment-2.DASH"/>
...
上記に示した例示的なMPDでは、「Period」、「AdaptationSet」、「Representation」、「SegmentURL」などのテキストは要素であるが、「mimeType」、「id」、「bandwidth」、「width」および「height」、「media」などは属性である。この例では、適合セットは、特定の帯域幅およびフレームサイズに関連する1つの表現を含み、それらのURLによって表されるメディアセグメントのセットを含む。
MPDファイルは、ROIに対するシグナリング情報を含み得る。次に図11を参照すると、図11は、MPD1100の一例を示すXMLコード表現を示す。MPD1100は、少なくとも1つの適合セットのリスティングを含み得る。MPD1100において、適合セットは、異なるビットレート、解像度、または他の品質に関連する複数の代替表現を規定するための要素を含み得る。各表現はピクチャファイルに関連し得、MPD1100は、表現要素の各々に対してピクチャファイルの位置を特定するためのリンク(たとえば、ユニバーサルリソースロケータ(URL)、ユニバーサルリソースインジケータ(URI)、または任意の他の好適な情報)を含み得る。表現に関連するピクチャファイルがROIを含む場合には、表現要素は、ROIに関連する第1のシグナリング情報および第2のシグナリング情報をさらに含み得る。
図示のように、適合セットは、表現IDが1に等しい表現および表現IDが2に等しい表現を含む、複数の表現を含むように規定される。MPD1100は、表現IDが2の表現が、特性の中でも、3840ピクセルという幅、1920ピクセルという高さ、60というフレームレートを有することを示す。MPD1100は、表現用のビデオファイル「video1.mp4」に対するURLをさらに含む。EssentialProperty要素1102は、表現IDが2の表現に対して提供される。EssentialProperty要素1102は、投影タイプ、FOV方向、領域ごとのマッピング、および/または他の情報についての情報を記述することができる。たとえば、この情報は、EssentialPropertyを使用することによってMPD1100の中に含まれ得、その場合、情報タイプごとに異なるschemeIdUriが規定され得る。例示的な一例では、schemeIdUri「urn:mpeg:dash:360VideoProjection:2017」が投影タイプに関連し、かつ「CMP」が立方体マップ投影を意味する場合、次のように立方体マップ投影タイプについての情報をEssentialProperty要素の中に規定することができる。<EssentialProperty schemeIdUri=“urn:mpeg:dash:360VideoProjection:2017" value="CMP"/>
その上、SupplementalProperty要素1104は、ROIのシグナリング情報を含み得る。たとえば、schemeIdUri「urn:mpeg:dash:ROIpixelrep:2017」は、2次元フレームの中でのROIの中心ロケーションおよび寸法をシグナリングするための値のセットに関連付けられ得る。ロケーションおよび寸法はピクセル座標で表され得る。図11の例では、ROIの中心ロケーションは(1300,500)であり得、それは、中心ロケーションの左オフセットが1300ピクセルであり、中心ロケーションの上オフセットが500ピクセルであることを示す。その上、ROIは、100ピクセルという幅および200ピクセルという高さにわたる。図11の例ではロケーションおよび寸法がピクセル座標で表されるが、それらがタイルなどの他の形式で表され得ることが理解される。たとえば、ロケーションおよび寸法は、ROIを含むタイル、またはROIを含むタイルのグループに関連付けられたグループ識別子を列挙することによってシグナリングされ得る。
さらに、schemeIdUri「urn:mpeg:dash:ROIsphererep:2017」は、球形空間の中でのROIの中心ロケーションおよび寸法をシグナリングするための値のセットに関連付けられ得る。図11の例では、ROIのヨー角は20ラジアンであり得、ROIのピッチ角は30ラジアンであり得、ROIのピッチデルタ角は10ラジアンであり得、ROIのヨーデルタ角は10ラジアンであり得る。
MPD1100を用いると、システムは、ROIがビデオファイルの中に含まれるという表示に基づいて、ビデオファイル「video1.mp4」をフェッチすることができ、ファイルを復号することができる。システムはまた、復号されたファイルからシグナリング情報に従ってピクセルを抽出することができ、抽出されたピクセルをレンダリングのためにレンダラに提供することができる。
図12は、メディアファイルを生成するためのプロセス1200の一例を示すフローチャートである。プロセスは、符号化データをISOベースメディアファイル(たとえば、ISOBMFFファイル)の中にカプセル化する、たとえば、ストリーミングサーバ(たとえば、図9のサーバ902)、ホスティングサーバと受信機デバイスとの間の中間ネットワークデバイスなどによって実行され得る。
1202において、プロセス1200は、360度ビデオデータを取得することを含み、360度ビデオデータは、シーンの球形表現を含む。360度ビデオデータは、カメラセット(たとえば、全方向性カメラ)によって生成され得る。球形表現は、たとえば、特定の時点においてカメラセットによってキャプチャされた画像のセットをスティッチすることによって形成され得る。
1204において、プロセス1200は、シーンの球形表現における関心領域(ROI)を決定することを含む。決定は、たとえば、シーンの特定の部分をユーザに(たとえば、ディレクターズカットの一部として)出力するための命令、ユーザの視界の方向に基づくことができ、または他の好適な情報に基づくことができる。いくつかの例では、ROIは、球形表現と交差する少なくとも4つの平面によって画定され得、4つの平面の各々は、大円を形成するように球中心とも交差する。たとえば、再び図5Aを参照すると、ROIは、4つの大円502、504、506、および508によって画定され得る。
1206において、プロセス1200は、ROIに対応するビューポート領域の第1のシグナリング情報および第2のシグナリング情報を含むメディアファイルを生成することを含み、第1のシグナリング情報は、球形表現に関連する球形空間の中で測定されたビューポート領域の中心位置および寸法を含み、第2のシグナリング情報は、ビューポート領域を備えるピクチャの領域を示す。ピクチャは、ROIを含む球形表現を平面上への直線的投影を使用して投影することによって形成され得、ビデオフレームであり得る。ビューポートは、ディスプレイの中でレンダリングされるためのものである。いくつかの例では、第1のシグナリング情報および第2のシグナリング情報はまた、複数のROIに対応する複数のビューポート領域を規定し得、複数のビューポート領域のうちの1つが、ディスプレイの中でレンダリングするために選択され得る。
いくつかの例では、メディアファイルは、国際標準化機構(ISO)ベースメディアファイルフォーマット(ISOBMFF)に基づく。いくつかの例では、メディアファイルは、球形ビデオシーンに対応するビデオサンプルを含むサンプルグループを識別し得、第1のシグナリング情報および第2のシグナリング情報は、サンプルグループの1つまたは複数のシンタックス要素の中に含まれる。
いくつかの例では、メディアファイルは、メディアプレゼンテーション記述(MPD)フォーマットに基づくとともに1つまたは複数の適合セットのリストを含む。1つまたは複数の適合セットの各々は、1つまたは複数の表現を含み得る。第1のシグナリング情報、第2のシグナリング情報、およびピクチャへのリンクが、1つまたは複数の表現の中に含まれるROIに関連する1つまたは複数の要素の中に含まれる。いくつかの例では、1つまたは複数の表現は、タイルベース表現であり、第2のシグナリング情報は、1つまたは複数のタイルベース表現の中に含まれるROIを含むタイルに関連する識別子を含む。
いくつかの例では、第1のシグナリング情報は、シーンの球形表現の球中心に対するビューポート領域の中心の第1の角度および第2の角度を含むことができ、第1の角度は第1の平面上に形成され、第2の角度は第2の平面上に形成され、第1の平面は第2の平面に直交する。第1のシグナリング情報は、ビューポート領域の幅に関連する第3の角度、およびビューポート領域の高さに関連する第4の角度をさらに含み得る。第3の角度は、ビューポート領域の第1の縁部と第2の縁部との間に形成され得、第4の角度は、ビューポート領域の第3の縁部と第4の縁部との間に形成される。たとえば、図4C、図4D、および図4Eで説明したように、第1の角度はヨー角であり得、第2の角度はピッチ角であり得、第3の角度および第4の角度は、それぞれ、ヨーデルタ角およびピッチデルタ角であり得る。
いくつかの例では、第2のシグナリング情報は、ビューポート領域を含むピクチャの1つまたは複数のタイルを規定し得る。1つまたは複数のタイルは、ピクチャの中に含まれる複数のタイルの一部であってよい。いくつかの例では、第2のシグナリング情報は、ピクチャの中の1つまたは複数のタイルに関連する1つまたは複数の座標をさらに含み得る。いくつかの例では、1つまたは複数のタイルは、タイルグループを形成し、第2のシグナリング情報は、タイルグループに関連するグループ識別子を含み得る。それらのタイルは、たとえば、動き制約付きタイルであってよい。
いくつかの例では、第2のシグナリング情報は、ROIを平面上に投影することによって形成されるビューポート領域内の事前決定されたロケーションに関連するピクセル座標、ビューポート領域の幅、およびビューポート領域の高さを含み得る。
1208において、プロセス1200は、360度ビデオデータをレンダリングするために、または少なくともROIを含む360度ビデオデータの一部分の送信のために、メディアファイルを提供することをさらに含む。レンダリングは、たとえば、第2のシグナリング情報に基づいてピクチャからタイルのセットを取得することと、第1のシグナリング情報に基づいてタイルのセット内のビューポートのロケーションおよび境界を決定することと、決定されたロケーションおよび境界に基づいて、ビューポートに対応するピクセルを抽出して、ビューポートをレンダリングすることとを含み得る。境界はまた、ビューポートの事前決定された形状に基づいて決定され得る。ビューポートの形状は、たとえば、ROIが、球形表現と交差する少なくとも4つの平面によって画定されるという決定に基づいて事前決定され得、4つの平面の各々は、球形表現の球中心とも交差し、各々が大円を形成する。たとえば、上記で説明したように、ROIは、4つの大円502、504、506、および508によって画定され得、ビューポートは、図5Cのビューポート520と同じ形状のものであってよい。その上、360度ビデオデータの部分の送信は、たとえば、ROIを含むピクチャの中のタイルのセットを決定することと、タイルのセットに対応するビデオデータをROIのレンダリングのためにレンダラへ送信することとを含み得る。
図13は、メディアファイルを処理するためのプロセス1300の一例を示すフローチャートである。プロセスは、たとえば、ホスティングサーバと受信機デバイスとの間の中間ネットワークデバイス、受信機デバイスなどによって実行され得る。
1302において、プロセス1300は、360度ビデオデータに関連するメディアファイルを取得することを含む。360度ビデオデータは、カメラセット(たとえば、全方向性カメラ)によって生成され得る。球形表現は、たとえば、特定の時点においてカメラセットによってキャプチャされた画像のセットをスティッチすることによって形成され得る。メディアファイルは、球形表現における関心領域(ROI)に対応するビューポート領域の第1のシグナリング情報および第2のシグナリング情報を含み得る。
いくつかの例では、ROIは、球形表現と交差する少なくとも4つの平面によって画定され得、4つの平面の各々は、大円を形成するように球中心とも交差する。たとえば、再び図5Aを参照すると、ROIは、4つの大円502、504、506、および508によって画定され得る。
1304において、プロセス1300は、第1のシグナリング情報および第2のシグナリング情報に基づいて、ピクチャのデータからビューポートに対応するピクセルを抽出することを含む。
いくつかの例では、メディアファイルは、国際標準化機構(ISO)ベースメディアファイルフォーマット(ISOBMFF)に基づく。いくつかの例では、メディアファイルは、球形ビデオシーンに対応するビデオサンプルを含むサンプルグループを識別し得、第1のシグナリング情報および第2のシグナリング情報は、サンプルグループの1つまたは複数のシンタックス要素の中に含まれる。
いくつかの例では、メディアファイルは、メディアプレゼンテーション記述(MPD)フォーマットに基づくとともに1つまたは複数の適合セットのリストを含む。1つまたは複数の適合セットの各々は、1つまたは複数の表現を含み得る。第1のシグナリング情報、第2のシグナリング情報、およびピクチャへのリンクが、1つまたは複数の表現の中に含まれるROIに関連する1つまたは複数の要素の中に含まれる。いくつかの例では、1つまたは複数の表現は、タイルベース表現であり、第2のシグナリング情報は、1つまたは複数のタイルベース表現の中に含まれるROIを含むタイルに関連する識別子を含む。
いくつかの例では、第1のシグナリング情報は、シーンの球形表現の球中心に対するビューポート領域の中心の第1の角度および第2の角度を含むことができ、第1の角度は第1の平面上に形成され、第2の角度は第2の平面上に形成され、第1の平面は第2の平面に直交する。第1のシグナリング情報は、ビューポート領域の幅に関連する第3の角度、およびビューポート領域の高さに関連する第4の角度をさらに含み得る。第3の角度は、ビューポート領域の第1の縁部と第2の縁部との間に形成され得、第4の角度は、ビューポート領域の第3の縁部と第4の縁部との間に形成される。たとえば、図4C、図4D、および図4Eで説明したように、第1の角度はヨー角であり得、第2の角度はピッチ角であり得、第3の角度および第4の角度は、それぞれ、ヨーデルタ角およびピッチデルタ角であり得る。
いくつかの例では、第2のシグナリング情報は、ビューポート領域を含むピクチャの1つまたは複数のタイルを規定し得る。1つまたは複数のタイルは、ピクチャの中に含まれる複数のタイルの一部であってよい。いくつかの例では、第2のシグナリング情報は、ピクチャの中の1つまたは複数のタイルに関連する1つまたは複数の座標をさらに含み得る。いくつかの例では、1つまたは複数のタイルは、タイルグループを形成し、第2のシグナリング情報は、タイルグループに関連するグループ識別子を含み得る。それらのタイルは、たとえば、動き制約付きタイルであってよい。
いくつかの例では、第2のシグナリング情報は、ROIを平面上に投影することによって形成されるビューポート領域内の事前決定されたロケーションに関連するピクセル座標、ビューポート領域の幅、およびビューポート領域の高さを含み得る。
いくつかの例では、ピクセルの抽出は、ビューポート領域を含むピクチャの中のタイルのセットを識別することと、タイルのセットからピクセルを抽出することとを含み得る。ピクセルの抽出は、タイルのセットの中のビューポートのロケーションおよび境界を決定することをさらに含み得る。ロケーションは、ビューポート領域の中心位置を示すヨー角およびピッチ角に基づいて決定され得、境界は、それぞれ、ヨーデルタ角およびピッチデルタ角によって示される幅および高さに基づいて決定され得る。境界はまた、ビューポート領域の事前決定された形状に基づいて決定され得る。形状は、球形表現と交差する少なくとも4つの平面によって画定されているROIに基づいて決定され得、4つの平面の各々は、球形表現の球中心とも交差し、大円を形成する。たとえば、ビューポートの形状は、図5Cのビューポート520と同じであってよい。ピクセルの抽出は、ビューポート領域のロケーションおよび境界に基づき得る。
1306において、プロセス1300は、ディスプレイの中でビューポート領域をレンダリングするために、抽出されたピクセルを提供することをさらに含む。
いくつかの例では、プロセス1200および1300は、図1に示すシステム100などのコンピューティングデバイスまたは装置によって実行され得る。いくつかの例では、プロセス1200および1300は、ファイル生成デバイス、ファイル構文解析または処理デバイス、図1および図14に示す符号化デバイス104によって、別のビデオ送信側デバイスまたはビデオ送信デバイスによって、図1および図15に示す復号デバイス112によって、かつ/あるいはプレーヤデバイス、ディスプレイ、または任意の他のクライアント側デバイスなどの別のクライアント側デバイスによって実行され得る。一例では、プロセス1200は、ファイル生成デバイス、図1および図14に示す符号化デバイス104によって、かつ/あるいは別の送信側デバイスまたはビデオ送信デバイスによって実行され得る。別の例では、プロセス1300は、ファイル構文解析または処理デバイス、図1および図15に示す復号デバイス112によって、かつ/あるいはプレーヤデバイス、ディスプレイ、または任意の他のクライアント側デバイスなどの別のクライアント側デバイスによって実行され得る。場合によっては、コンピューティングデバイスまたは装置は、プロセス1200および1300のステップを実行するように構成されているデバイスのプロセッサ、マイクロプロセッサ、マイクロコンピュータ、または他の構成要素を含み得る。いくつかの例では、コンピューティングデバイスまたは装置は、ビデオフレームを含むビデオデータ(たとえば、ビデオシーケンス)をキャプチャするように構成されたカメラを含み得る。いくつかの例では、ビデオデータをキャプチャするカメラまたは他のキャプチャデバイスは、コンピューティングデバイスとは別個であり、その場合、コンピューティングデバイスは、キャプチャされたビデオデータを受信または取得する。コンピューティングデバイスは、ビデオデータを通信するように構成されたネットワークインターフェースをさらに含み得る。ネットワークインターフェースは、インターネットプロトコル(IP)ベースのデータまたは他のタイプのデータを通信するように構成され得る。いくつかの例では、コンピューティングデバイスまたは装置は、ビデオビットストリームのピクチャのサンプルなどの、出力ビデオコンテンツを表示するためのディスプレイを含み得る。
プロセス1200および1300は、論理フロー図として図示され、それらの動作は、ハードウェア、コンピュータ命令、またはそれらの組合せで実施され得る動作のシーケンスを表す。コンピュータ命令のコンテキストでは、動作は、1つまたは複数のプロセッサによって実行されたとき、記載する動作を実行し1つまたは複数のコンピュータ可読記憶媒体に記憶されたコンピュータ実行可能命令を表す。一般に、コンピュータ実行可能命令は、特定の機能を実行するかまたは特定のデータタイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。動作が説明される順序は、限定として解釈されることを意図せず、説明する任意の数の動作は、プロセスを実施するために任意の順序で、かつ/または並列に組み合わせられ得る。
追加として、プロセス1200および1300は、実行可能命令を用いて構成された1つまたは複数のコンピュータシステムの制御下で実行されてよく、ハードウェアまたはその組合せによって1つまたは複数のプロセッサ上で集合的に実行するコード(たとえば、実行可能命令、1つもしくは複数のコンピュータプログラム、または1つもしくは複数のアプリケーション)として実装されてよい。上述のように、コードは、たとえば、1つまたは複数のプロセッサによって実行可能な複数の命令を備えるコンピュータプログラムの形態で、コンピュータ可読記憶媒体または機械可読記憶媒体に記憶され得る。コンピュータ可読記憶媒体または機械可読記憶媒体は非一時的であってよい。
本明細書で説明するコーディング技法は、例示的なビデオ符号化および復号システム(たとえば、システム100)の中で実装され得る。いくつかの例では、システムは、後で宛先デバイスによって復号されるべき符号化ビデオデータを提供するソースデバイスを含む。詳細には、ソースデバイスは、コンピュータ可読媒体を介して宛先デバイスにビデオデータを提供する。ソースデバイスおよび宛先デバイスは、デスクトップコンピュータ、ノートブック(すなわち、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲーミングコンソール、ビデオストリーミングデバイスなどを含む、広範囲のデバイスのいずれかを備え得る。場合によっては、ソースデバイスおよび宛先デバイスは、ワイヤレス通信のために装備され得る。
宛先デバイスは、復号されるべき符号化ビデオデータを、コンピュータ可読媒体を介して受信し得る。コンピュータ可読媒体は、ソースデバイスから宛先デバイスへ符号化ビデオデータを移動することが可能な任意のタイプの媒体またはデバイスを備え得る。一例では、コンピュータ可読媒体は、ソースデバイスが符号化ビデオデータをリアルタイムで宛先デバイスに直接送信することを可能にするための通信媒体を備え得る。符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調されてよく、宛先デバイスへ送信されてよい。通信媒体は、無線周波数(RF)スペクトル、または1つもしくは複数の物理伝送線路などの、任意のワイヤレス通信媒体または有線通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなどの、パケットベースネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイスから宛先デバイスへの通信を容易にするために有用であり得る任意の他の機器を含み得る。
いくつかの例では、符号化データは、出力インターフェースから記憶デバイスに出力され得る。同様に、符号化データは、入力インターフェースによって記憶デバイスからアクセスされ得る。記憶デバイスは、ハードドライブ、Blu-ray(登録商標)ディスク、DVD、CD-ROM、フラッシュメモリ、揮発性メモリもしくは不揮発性メモリ、または符号化ビデオデータを記憶するための任意の他の好適なデジタル記憶媒体などの、分散されるかまたは局所的にアクセスされる様々なデータ記憶媒体のいずれかを含み得る。さらなる例では、記憶デバイスは、ソースデバイスによって生成された符号化ビデオを記憶し得るファイルサーバまたは別の中間記憶デバイスに相当し得る。宛先デバイスは、記憶デバイスからの記憶されたビデオデータにストリーミングまたはダウンロードを介してアクセスし得る。ファイルサーバは、符号化ビデオデータを記憶するとともにその符号化ビデオデータを宛先デバイスへ送信することが可能な、任意のタイプのサーバであってよい。例示的なファイルサーバは、ウェブサーバ(たとえば、ウェブサイト用の)、FTPサーバ、ネットワーク接続ストレージ(NAS)デバイス、またはローカルディスクドライブを含む。宛先デバイスは、インターネット接続を含む任意の標準的なデータ接続を通じて符号化ビデオデータにアクセスし得る。これは、ファイルサーバに記憶された符号化ビデオデータにアクセスするのに適したワイヤレスチャネル(たとえば、Wi-Fi接続)、有線接続(たとえば、DSL、ケーブルモデムなど)、またはその両方の組合せを含み得る。記憶デバイスからの符号化ビデオデータの送信は、ストリーミング送信、ダウンロード送信、またはそれらの組合せであり得る。
本開示の技法は、ワイヤレスの適用例または設定に必ずしも限定されるとは限らない。技法は、オーバージエアテレビジョン放送、ケーブルテレビジョン送信、衛星テレビジョン送信、動的適応ストリーミングオーバーHTTP(DASH:dynamic adaptive streaming over HTTP)などのインターネットストリーミングビデオ送信、データ記憶媒体上に符号化されているデジタルビデオ、データ記憶媒体に記憶されたデジタルビデオの復号、または他の適用例などの、様々なマルチメディア用途のいずれかをサポートするビデオコーディングに適用され得る。いくつかの例では、システムは、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、および/またはビデオ電話などの適用例をサポートするために、一方向または双方向のビデオ送信をサポートするように構成され得る。
一例では、ソースデバイスは、ビデオソース、ビデオエンコーダ、および出力インターフェースを含む。宛先デバイスは、入力インターフェース、ビデオデコーダ、およびディスプレイデバイスを含み得る。ソースデバイスのビデオエンコーダは、本明細書で開示する技法を適用するように構成され得る。他の例では、ソースデバイスおよび宛先デバイスは、他の構成要素または構成を含み得る。たとえば、ソースデバイスは、外部カメラなどの外部ビデオソースからビデオデータを受信してよい。同様に、宛先デバイスは、一体型ディスプレイデバイスを含むのではなく、外部のディスプレイデバイスとインターフェースしてよい。
上記の例示的なシステムは一例にすぎない。ビデオデータを並行して処理するための技法は、任意のデジタルビデオ符号化および/または復号デバイスによって実行され得る。概して、本開示の技法はビデオ符号化デバイスによって実行されるが、技法はまた、通常は「コーデック」と呼ばれるビデオエンコーダ/デコーダによって実行されてよい。その上、本開示の技法はまた、ビデオプリプロセッサによって実行されてよい。ソースデバイスおよび宛先デバイスは、ソースデバイスが宛先デバイスへの送信のためにコード化ビデオデータを生成する、そのようなコーディングデバイスの例にすぎない。いくつかの例では、ソースデバイスおよび宛先デバイスは、デバイスの各々がビデオ符号化および復号構成要素を含むように、実質的に対称的に動作し得る。したがって、例示的なシステムは、たとえば、ビデオストリーミング、ビデオ再生、ビデオブロードキャスティング、またはビデオ電話のために、ビデオデバイス間での一方向または双方向のビデオ送信をサポートし得る。
ビデオソースは、ビデオカメラなどのビデオキャプチャデバイス、以前にキャプチャされたビデオを含むビデオアーカイブ、および/またはビデオコンテンツプロバイダからビデオを受信するためのビデオフィードインターフェースを含み得る。さらなる代替形態として、ビデオソースは、ソースビデオとしてのコンピュータグラフィックスベースデータ、またはライブビデオ、アーカイブされたビデオ、およびコンピュータ生成されたビデオの組合せを生成し得る。場合によっては、ビデオソースがビデオカメラである場合、ソースデバイスおよび宛先デバイスは、いわゆるカメラフォンまたはビデオフォンを形成し得る。しかしながら、上述のように、本開示で説明する技法は、一般に、ビデオコーディングに適用可能であり得、ワイヤレスおよび/または有線の適用例に適用され得る。各事例において、キャプチャされたビデオ、プリキャプチャされたビデオ、またはコンピュータ生成されたビデオは、ビデオエンコーダによって符号化され得る。符号化されたビデオ情報は、次いで、出力インターフェースによってコンピュータ可読媒体上に出力され得る。
述べたように、コンピュータ可読媒体は、ワイヤレスブロードキャストもしくは有線ネットワーク送信などの一時的媒体、またはハードディスク、フラッシュドライブ、コンパクトディスク、デジタルビデオディスク、Blu-ray(登録商標)ディスクなどの記憶媒体(すなわち、非一時的記憶媒体)、あるいは他のコンピュータ可読媒体を含み得る。いくつかの例では、ネットワークサーバ(図示せず)が、たとえば、ネットワーク送信を介して、ソースデバイスから符号化ビデオデータを受信し得、宛先デバイスに符号化ビデオデータを提供し得る。同様に、ディスクスタンピング施設などの媒体生産施設のコンピューティングデバイスが、ソースデバイスから符号化ビデオデータを受信し得、符号化ビデオデータを収容するディスクを生産し得る。したがって、コンピュータ可読媒体は、様々な例において、様々な形態の1つまたは複数のコンピュータ可読媒体を含むものと理解され得る。
宛先デバイスの入力インターフェースは、コンピュータ可読媒体から情報を受信する。コンピュータ可読媒体の情報は、ブロックおよび他のコード化ユニット、たとえば、ピクチャグループ(GOP:group of pictures)の特性および/または処理を記述するシンタックス要素を含むとともにビデオエンコーダによって規定されるシンタックス情報を含み得、シンタックス情報はビデオデコーダによっても使用される。ディスプレイデバイスは、復号ビデオデータをユーザに表示し、陰極線管(CRT)、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなどの、様々なディスプレイデバイスのいずれかを備え得る。本発明の様々な実施形態が説明されている。
符号化デバイス104および復号デバイス112の具体的な詳細が、それぞれ、図14および図15に示される。図14は、本開示で説明する技法のうちの1つまたは複数を実施し得る例示的な符号化デバイス104を示すブロック図である。符号化デバイス104は、たとえば、本明細書で説明するシンタックス構造(たとえば、VPS、SPS、PPS、または他のシンタックス要素のシンタックス構造)を生成し得る。符号化デバイス104は、ビデオスライス内のビデオブロックのイントラ予測コーディングおよびインター予測コーディングを実行し得る。前に説明したように、イントラコーディングは、所与のビデオフレーム内またはピクチャ内の空間的冗長性を低減または除去するために、空間予測に少なくとも部分的に依拠する。インターコーディングは、ビデオシーケンスの隣接するかまたは周囲にあるフレーム内の時間的冗長性を低減または除去するために、時間予測に少なくとも部分的に依拠する。イントラモード(Iモード)とは、いくつかの空間ベース圧縮モードのうちのいずれかを指し得る。単方向予測(Pモード)または双予測(Bモード)などのインターモードとは、いくつかの時間ベース圧縮モードのうちのいずれかを指し得る。
符号化デバイス104は、区分ユニット35、予測処理ユニット41、フィルタユニット63、ピクチャメモリ64、加算器50、変換処理ユニット52、量子化ユニット54、およびエントロピー符号化ユニット56を含む。予測処理ユニット41は、動き推定ユニット42、動き補償ユニット44、およびイントラ予測処理ユニット46を含む。ビデオブロック再構成のために、符号化デバイス104はまた、逆量子化ユニット58、逆変換処理ユニット60、および加算器62を含む。フィルタユニット63は、デブロッキングフィルタ、適応ループフィルタ(ALF:adaptive loop filter)、およびサンプル適応オフセット(SAO:sample adaptive offset)フィルタなどの、1つまたは複数のループフィルタを表すことを意図する。フィルタユニット63はループ内フィルタであるものとして図14で示されるが、他の構成では、フィルタユニット63は、ループ後フィルタとして実装されてよい。後処理デバイス57は、符号化デバイス104によって生成された符号化ビデオデータに対して追加の処理を実行し得る。本開示の技法は、いくつかの事例では、符号化デバイス104によって実施され得る。しかしながら、他の事例では、本開示の技法のうちの1つまたは複数は、後処理デバイス57によって実施されてよい。
図14に示すように、符号化デバイス104はビデオデータを受信し、区分ユニット35はデータをビデオブロックに区分する。区分することはまた、スライス、スライスセグメント、タイル、または他のもっと大きい単位に区分すること、ならびに、たとえば、LCUおよびCUの4分木構造によるビデオブロック区分を含み得る。符号化デバイス104は、概して、符号化されるべきビデオスライス内のビデオブロックを符号化する構成要素を示す。スライスは、複数のビデオブロックに(また場合によっては、タイルと呼ばれるビデオブロックのセットに)分割され得る。予測処理ユニット41は、エラー結果(たとえば、コーディングレート、およびひずみのレベルなど)に基づいて、現在ビデオブロックに対して、複数のイントラ予測コーディングモードのうちの1つ、または複数のインター予測コーディングモードのうちの1つなどの、複数の可能なコーディングモードのうちの1つを選択し得る。予測処理ユニット41は、残差ブロックデータを生成するために加算器50に、また参照ピクチャとして使用するための符号化ブロックを再構成するために加算器62に、得られたイントラまたはインターコード化ブロックを提供し得る。
予測処理ユニット41内のイントラ予測処理ユニット46は、空間的な圧縮を行うために、コーディングされるべき現在ブロックと同じフレームまたはスライスの中の1つまたは複数の隣接ブロックに対する現在ビデオブロックのイントラ予測コーディングを実行し得る。予測処理ユニット41内の動き推定ユニット42および動き補償ユニット44は、時間的な圧縮を行うために、1つまたは複数の参照ピクチャの中の1つまたは複数の予測ブロックに対する現在ビデオブロックのインター予測コーディングを実行する。
動き推定ユニット42は、ビデオシーケンス用の所定のパターンに従ってビデオスライス用のインター予測モードを決定するように構成され得る。所定のパターンは、シーケンスの中のビデオスライスを、Pスライス、Bスライス、またはGPBスライスとして指定し得る。動き推定ユニット42および動き補償ユニット44は高度に集積され得るが、概念的な目的のために別個に図示される。動き推定ユニット42によって実行される動き推定は、ビデオブロックに対する動きを推定する動きベクトルを生成するプロセスである。動きベクトルは、たとえば、参照ピクチャ内の予測ブロックに対する、現在のビデオフレームまたはピクチャ内のビデオブロックの予測ユニット(PU)の変位を示し得る。
予測ブロックは、絶対差分和(SAD)、2乗差分和(SSD)、または他の差分メトリックによって決定され得るピクセル差分に関して、コーディングされるべきビデオブロックのPUと厳密に一致することが判明したブロックである。いくつかの例では、符号化デバイス104は、ピクチャメモリ64に記憶された参照ピクチャのサブ整数ピクセル位置に対する値を計算し得る。たとえば、符号化デバイス104は、参照ピクチャの1/4ピクセル位置、1/8ピクセル位置、または他の分数ピクセル位置の値を補間し得る。したがって、動き推定ユニット42は、フルピクセル位置および分数ピクセル位置に対する動き探索を実行し得、分数ピクセル精度を有する動きベクトルを出力し得る。
動き推定ユニット42は、PUの位置を参照ピクチャの予測ブロックの位置と比較することによって、インターコード化スライスの中のビデオブロックのPUに対する動きベクトルを計算する。参照ピクチャは、第1の参照ピクチャリスト(リスト0)または第2の参照ピクチャリスト(リスト1)から選択されてよく、その各々はピクチャメモリ64に記憶された1つまたは複数の参照ピクチャを識別する。動き推定ユニット42は、計算された動きベクトルをエントロピー符号化ユニット56および動き補償ユニット44へ送る。
動き補償ユニット44によって実行される動き補償は、場合によっては、サブピクセル精度への補間を実行する動き推定によって決定される動きベクトルに基づいて、予測ブロックをフェッチまたは生成することを伴い得る。現在ビデオブロックのPUに対する動きベクトルを受信すると、動き補償ユニット44は、参照ピクチャリストの中で動きベクトルが指す予測ブロックの位置を特定し得る。符号化デバイス104は、コーディングされている現在ビデオブロックのピクセル値から予測ブロックのピクセル値を減算することによって残差ビデオブロックを形成し、ピクセル差分値を形成する。ピクセル差分値は、ブロックに対する残差データを形成し、ルーマ差分成分とクロマ差分成分の両方を含み得る。加算器50は、この減算演算を実行する1つまたは複数の構成要素を表す。動き補償ユニット44はまた、ビデオスライスのビデオブロックを復号する際に復号デバイス112によって使用するために、ビデオブロックおよびビデオスライスに関連するシンタックス要素を生成し得る。
イントラ予測処理ユニット46は、上記で説明したように、動き推定ユニット42および動き補償ユニット44によって実行されるインター予測の代替として、現在ブロックをイントラ予測し得る。詳細には、イントラ予測処理ユニット46は、現在ブロックを符号化するために使用すべきイントラ予測モードを決定し得る。いくつかの例では、イントラ予測処理ユニット46は、たとえば、別個の符号化パスの間、様々なイントラ予測モードを使用して現在ブロックを符号化してよく、イントラ予測処理ユニット46は、テストされたモードの中から使用すべき適切なイントラ予測モードを選択し得る。たとえば、イントラ予測処理ユニット46は、テストされた様々なイントラ予測モードに対してレートひずみ分析を使用してレートひずみ値を計算し得、テストされたモードの中からレートひずみ特性が最良のイントラ予測モードを選択してよい。レートひずみ分析は、概して、符号化ブロックと、符号化ブロックを生成するために符号化された、符号化されていない元のブロックとの間のひずみ(すなわち、エラー)の量、ならびに符号化ブロックを生成するために使用されるビットレート(すなわち、ビット数)を決定する。イントラ予測処理ユニット46は、様々な符号化ブロックに対するひずみおよびレートから比を計算して、どのイントラ予測モードがブロックに対して最良のレートひずみ値を示すのかを決定し得る。
いずれの場合も、ブロック用のイントラ予測モードを選択した後、イントラ予測処理ユニット46は、ブロック用の選択されたイントラ予測モードを示す情報をエントロピー符号化ユニット56に提供し得る。エントロピー符号化ユニット56は、選択されたイントラ予測モードを示す情報を符号化し得る。符号化デバイス104は、様々なブロック用の符号化コンテキストの構成データ定義、ならびに最確のイントラ予測モード、イントラ予測モードインデックステーブル、およびコンテキストの各々に対して使用すべき修正されたイントラ予測モードインデックステーブルの表示を、送信されるビットストリームの中に含め得る。ビットストリーム構成データは、複数のイントラ予測モードインデックステーブルおよび複数の修正済みイントラ予測モードインデックステーブル(コードワードマッピングテーブルとも呼ばれる)を含み得る。
予測処理ユニット41がインター予測またはイントラ予測のいずれかを介して現在ビデオブロックに対する予測ブロックを生成した後、符号化デバイス104は、現在ビデオブロックから予測ブロックを減算することによって残差ビデオブロックを形成する。残差ブロックの中の残差ビデオデータは、1つまたは複数のTUの中に含められてよく、変換処理ユニット52に適用され得る。変換処理ユニット52は、離散コサイン変換(DCT)または概念的に類似の変換などの変換を使用して、残差ビデオデータを残差変換係数に変換する。変換処理ユニット52は、ピクセル領域から周波数領域などの変換領域に、残差ビデオデータを変換し得る。
変換処理ユニット52は、得られた変換係数を量子化ユニット54に送り得る。量子化ユニット54は、変換係数を量子化してビットレートをさらに低減する。量子化プロセスは、係数の一部または全部に関連するビット深度を低減し得る。量子化の程度は、量子化パラメータを調整することによって修正され得る。いくつかの例では、量子化ユニット54は、次いで、量子化変換係数を含む行列の走査を実行し得る。代替として、エントロピー符号化ユニット56が走査を実行してもよい。
量子化に続いて、エントロピー符号化ユニット56は、量子化変換係数をエントロピー符号化する。たとえば、エントロピー符号化ユニット56は、コンテキスト適応型可変長コーディング(CAVLC:context adaptive variable length coding)、コンテキスト適応型バイナリ算術コーディング(CABAC:context adaptive binary arithmetic coding)、シンタックスベースコンテキスト適応型バイナリ算術コーディング(SBAC:syntax-based context-adaptive binary arithmetic coding)、確率間隔区分エントロピー(PIPE:probability interval partitioning entropy)コーディング、または別のエントロピー符号化技法を実行し得る。エントロピー符号化ユニット56によるエントロピー符号化に続いて、符号化ビットストリームは、復号デバイス112へ送信されてよく、または復号デバイス112によって後で送信もしくは取出しができるようにアーカイブされてもよい。エントロピー符号化ユニット56はまた、コーディングされている現在ビデオスライス用の動きベクトルおよび他のシンタックス要素をエントロピー符号化し得る。
逆量子化ユニット58および逆変換処理ユニット60は、参照ピクチャの参照ブロックとして後で使用できるように、それぞれ、逆量子化および逆変換を適用してピクセル領域における残差ブロックを再構築する。動き補償ユニット44は、参照ピクチャリスト内の参照ピクチャのうちの1つの予測ブロックに残差ブロックを加算することによって、参照ブロックを計算し得る。動き補償ユニット44はまた、動き推定において使用するためのサブ整数ピクセル値を計算するために、1つまたは複数の補間フィルタを再構成残差ブロックに適用し得る。加算器62は、ピクチャメモリ64に記憶するための参照ブロックを生成するために、動き補償ユニット44によって生成された動き補償予測ブロックに再構成残差ブロックを加算する。参照ブロックは、後続のビデオフレームまたはピクチャの中のブロックをインター予測するための参照ブロックとして、動き推定ユニット42および動き補償ユニット44によって使用され得る。
このようにして、図14の符号化デバイス104は、LICパラメータを導出し、テンプレートのサイズを適応的に決定し、かつ/または重みを適応的に選択するように構成された、ビデオエンコーダの一例を表す。符号化デバイス104は、たとえば、上記で説明したように、LICパラメータを導出し得、テンプレートのサイズを適応的に決定し得、かつ/または重みセットを適応的に選択し得る。たとえば、符号化デバイス104は、図12および図13に関して上記で説明したプロセスを含む、本明細書で説明する技法のうちのいずれかを実行し得る。場合によっては、本開示の技法のいくつかはまた、後処理デバイス57によって実施されてよい。
図15は、例示的な復号デバイス112を示すブロック図である。復号デバイス112は、エントロピー復号ユニット80、予測処理ユニット81、逆量子化ユニット86、逆変換処理ユニット88、加算器90、フィルタユニット91、およびピクチャメモリ92を含む。予測処理ユニット81は、動き補償ユニット82およびイントラ予測処理ユニット84を含む。復号デバイス112は、いくつかの例では、図14からの符号化デバイス104に関して説明した符号化パスとは概して逆の復号パスを実行し得る。
復号プロセスの間、復号デバイス112は、符号化デバイス104によって送られた符号化ビデオスライスのビデオブロックおよび関連するシンタックス要素を表す符号化ビデオビットストリームを受信する。いくつかの実施形態では、復号デバイス112は、符号化デバイス104から符号化ビデオビットストリームを受信し得る。いくつかの実施形態では、復号デバイス112は、サーバ、メディアアウェアネットワーク要素(MANE:media-aware network element)、ビデオエディタ/スプライサ、または上記で説明した技法のうちの1つもしくは複数を実施するように構成されたそのような他のデバイスなどのネットワークエンティティ79から、符号化ビデオビットストリームを受信し得る。ネットワークエンティティ79は、符号化デバイス104を含んでも含まなくてもよい。本開示で説明する技法のうちのいくつかは、ネットワークエンティティ79が符号化ビデオビットストリームを復号デバイス112へ送信する前に、ネットワークエンティティ79によって実施され得る。いくつかのビデオ復号システムでは、ネットワークエンティティ79および復号デバイス112は、別個のデバイスの一部であってよく、他の事例では、ネットワークエンティティ79に関して説明する機能は、復号デバイス112を備える同じデバイスによって実行されてよい。
復号デバイス112のエントロピー復号ユニット80は、ビットストリームをエントロピー復号して、量子化係数、動きベクトル、および他のシンタックス要素を生成する。エントロピー復号ユニット80は、動きベクトルおよび他のシンタックス要素を予測処理ユニット81に転送する。復号デバイス112は、ビデオスライスレベルおよび/またはビデオブロックレベルにおいてシンタックス要素を受信し得る。エントロピー復号ユニット80は、VPS、SPS、およびPPSなどの1つまたは複数のパラメータセットの中の、固定長シンタックス要素と可変長シンタックス要素の両方を処理および構文解析し得る。
ビデオスライスがイントラコード化(I)スライスとしてコーディングされるとき、予測処理ユニット81のイントラ予測処理ユニット84は、シグナリングされたイントラ予測モード、および現在フレームまたは現在ピクチャの以前に復号されたブロックからのデータに基づいて、現在ビデオスライスのビデオブロックに対する予測データを生成し得る。ビデオフレームがインターコード化(すなわち、B、P、またはGPB)スライスとしてコーディングされるとき、予測処理ユニット81の動き補償ユニット82は、エントロピー復号ユニット80から受信された動きベクトルおよび他のシンタックス要素に基づいて、現在ビデオスライスのビデオブロックに対する予測ブロックを生成する。予測ブロックは、参照ピクチャリスト内の参照ピクチャのうちの1つから生成され得る。復号デバイス112は、ピクチャメモリ92に記憶された参照ピクチャに基づいて、デフォルトの構成技法を使用して、参照フレームリスト、すなわち、リスト0およびリスト1を構成し得る。
動き補償ユニット82は、動きベクトルおよび他のシンタックス要素を構文解析することによって、現在ビデオスライスのビデオブロックに対する予測情報を決定し、予測情報を使用して、復号されている現在ビデオブロックに対する予測ブロックを生成する。たとえば、動き補償ユニット82は、パラメータセットの中の1つまたは複数のシンタックス要素を使用して、ビデオスライスのビデオブロックをコーディングするために使用された予測モード(たとえば、イントラ予測またはインター予測)、インター予測スライスタイプ(たとえば、Bスライス、Pスライス、またはGPBスライス)、スライス用の1つまたは複数の参照ピクチャリストに対する構成情報、スライスのインター符号化ビデオブロックごとの動きベクトル、スライスのインターコード化ビデオブロックごとのインター予測ステータス、および現在ビデオスライスの中のビデオブロックを復号するための他の情報を決定し得る。
動き補償ユニット82はまた、補間フィルタに基づいて補間を実行し得る。動き補償ユニット82は、ビデオブロックの符号化の間に符号化デバイス104によって使用されたような補間フィルタを使用して、参照ブロックのサブ整数ピクセルに対する補間値を計算し得る。この場合、動き補償ユニット82は、符号化デバイス104によって使用された補間フィルタを、受信されたシンタックス要素から決定し得、予測ブロックを生成するためにその補間フィルタを使用し得る。
逆量子化ユニット86は、ビットストリームの中で提供されるとともにエントロピー復号ユニット80によって復号された量子化変換係数を逆量子化(inverse quantize)または逆量子化(de-quantize)する。逆量子化プロセスは、量子化の程度、および同様に、適用されるべき逆量子化の程度を決定するために、ビデオスライスの中のビデオブロックごとに符号化デバイス104によって計算された量子化パラメータを使用することを含み得る。逆変換処理ユニット88は、ピクセル領域における残差ブロックを生成するために、変換係数に逆変換(たとえば、逆DCTまたは他の好適な逆変換)、逆整数変換、または概念的に類似の逆変換プロセスを適用する。
動き補償ユニット82が動きベクトルおよび他のシンタックス要素に基づいて現在ビデオブロックに対する予測ブロックを生成した後、復号デバイス112は、逆変換処理ユニット88からの残差ブロックを、動き補償ユニット82によって生成された対応する予測ブロックと加算することによって、復号ビデオブロックを形成する。加算器90は、この加算演算を実行する1つまたは複数の構成要素を表す。所望される場合、(コーディングループ中またはコーディングループ後のいずれかの)ループフィルタも、ピクセル遷移を平滑化するために、または別の方法でビデオ品質を改善するために使用され得る。フィルタユニット91は、デブロッキングフィルタ、適応ループフィルタ(ALF)、およびサンプル適応オフセット(SAO)フィルタなどの、1つまたは複数のループフィルタを表すことを意図する。フィルタユニット91はループ内フィルタであるものとして図15に示されるが、他の構成では、フィルタユニット91は、ループ後フィルタとして実装されてよい。所与のフレームまたはピクチャの中の復号ビデオブロックは、次いで、ピクチャメモリ92に記憶され、ピクチャメモリ92は、後続の動き補償のために使用される参照ピクチャを記憶する。ピクチャメモリ92はまた、図1に示すビデオ宛先デバイス122などのディスプレイデバイス上で後で提示できるように、復号ビデオを記憶する。
このようにして、図15の復号デバイス112は、LICパラメータを導出し、テンプレートのサイズを適応的に決定し、かつ/または重みを適応的に選択するように構成された、ビデオデコーダの一例を表す。復号デバイス112は、たとえば、上記で説明したように、LICパラメータを導出し得、テンプレートのサイズを適応的に決定し得、かつ/または重みセットを適応的に選択し得る。たとえば、復号デバイス112は、図12および図13に関して上記で説明したプロセスを含む、本明細書で説明する技法のいずれかを実行し得る。
上記の説明では、本出願の態様は、それらの特定の実施形態を参照しながら説明されるが、本発明がそれらに限定されないことを当業者は認識されよう。したがって、本出願の例示的な実施形態が本明細書で詳細に説明されているが、本発明の概念が別の方法で様々に具現化または採用されてよく、従来技術による限定を除いて、添付の特許請求の範囲がそのような変形形態を含むものと解釈されることを意図することを理解されたい。上記で説明した発明の様々な特徴および態様は、個別または一緒に使用され得る。さらに、実施形態は、本明細書のより広い趣旨および範囲から逸脱することなく、本明細書で説明したものを越えた任意の数の環境および適用例において利用され得る。したがって、本明細書および図面は、限定ではなく例示であると見なされるべきである。例示のために、方法は特定の順序で説明された。代替実施形態では、説明された順序とは異なる順序で方法が実行され得ることを諒解されたい。
構成要素がいくつかの動作を実行する「ように構成される」ものとして説明される場合、そのような構成は、たとえば、動作を実行するように電子回路もしくはハードウェアを設計することによって、動作を実行するようにプログラマブル電子回路(たとえば、マイクロプロセッサ、または他の好適な電子回路)をプログラムすることによって、またはそれらの任意の組合せで達成され得る。
本明細書で開示する実施形態に関して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、ファームウェア、またはそれらの組合せとして実装され得る。ハードウェアとソフトウェアとのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップが、全般にそれらの機能に関して上で説明されている。そのような機能が、ハードウェアとして実装されるのか、それともソフトウェアとして実装されるのかは、特定の適用例および全体的なシステムに課される設計制約によって決まる。当業者は、説明した機能を具体的な適用例ごとに様々な方法で実装し得るが、そのような実装決定が本発明の範囲からの逸脱を引き起こすものと解釈されるべきではない。
本明細書で説明した技法はまた、電子ハードウェア、コンピュータソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。そのような技法は、汎用コンピュータ、ワイヤレス通信デバイスハンドセット、またはワイヤレス通信デバイスハンドセットおよび他のデバイスにおける適用例を含む複数の用途を有する集積回路デバイスなどの、様々なデバイスのいずれかにおいて実施され得る。モジュールまたは構成要素として説明した任意の特徴が、集積論理デバイスの中で一緒に、または個別であるが相互動作可能な論理デバイスとして別個に実装され得る。ソフトウェアで実装される場合、技法は、実行されたとき、上記で説明した方法のうちの1つまたは複数を実行する命令を含むプログラムコードを備える、コンピュータ可読データ記憶媒体によって少なくとも部分的に実現され得る。コンピュータ可読データ記憶媒体は、パッケージング材料を含み得るコンピュータプログラム製品の一部を形成し得る。コンピュータ可読媒体は、同期ダイナミックランダムアクセスメモリ(SDRAM)などのランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、不揮発性ランダムアクセスメモリ(NVRAM)、電気的消去可能プログラマブル読取り専用メモリ(EEPROM)、フラッシュメモリ、磁気または光データ記憶媒体などの、メモリまたはデータ記憶媒体を備え得る。技法は、追加または代替として、伝搬される信号または波などの、命令またはデータ構造の形態でプログラムコードを搬送または通信するとともに、コンピュータによってアクセスされ、読み取られ、かつ/または実行され得る、コンピュータ可読通信媒体によって少なくとも部分的に実現され得る。
プログラムコードは、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の等価な集積論理回路構成もしくは個別論理回路構成などの、1つまたは複数のプロセッサを含み得るプロセッサによって実行され得る。そのようなプロセッサは、本開示で説明した技法のうちのいずれかを実行するように構成され得る。汎用プロセッサはマイクロプロセッサであり得るが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであり得る。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携する1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装され得る。したがって、本明細書で使用する「プロセッサ」という用語は、上記の構造、上記の構造の任意の組合せ、または本明細書で説明した技法の実装に適した任意の他の構造もしくは装置のいずれかを指し得る。加えて、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のソフトウェアモジュールもしくはハードウェアモジュール内に設けられてよく、または複合ビデオエンコーダ/デコーダ(コーデック)に組み込まれてよい。