JP5450810B2 - Ｍｐｅｇ−２システムにおけるマルチビュービデオ符号化サブビットストリームのアセンブル - Google Patents

Description

関連出願
本出願は、参照により全体が明示的に本明細書に組み込まれる、２００９年６月２９日に出願された米国仮出願第６１／２２１，４４９号および２００９年６月１２日に出願された米国仮出願第６１／１８６，６１３号の利益を主張するものである。

関連出願の相互参照
本出願は、本出願と同時に出願され、本出願の譲受人に譲渡され、参照により本明細書に明示的に組み込まれる、Ｙｉｎｇ Ｃｈｅｎによる同時係属米国特許出願「ＭＵＬＴＩＶＩＥＷ ＶＩＤＥＯ ＣＯＤＩＮＧ ＯＶＥＲ ＭＰＥＧ−２ ＳＹＳＴＥＭＳ」（整理番号０９２５１４）に関係する。

本開示は、エンコードされたビデオデータのトランスポートに関する。

デジタルビデオ機能は、デジタルテレビジョン、デジタルダイレクト放送システム、ワイヤレス放送システム、携帯情報端末（ＰＤＡ）、ラップトップもしくはデスクトップコンピュータ、デジタルカメラ、デジタル録音デバイス、デジタルメディアプレーヤー、ビデオゲームデバイス、家庭用ゲーム機、セルラー方式または衛星無線電話、ビデオ遠隔会議デバイス、および同様のものを含む、各種のデバイスに組み込まれ得る。デジタルビデオデバイスでは、デジタルビデオ情報をより効率的に送信し、受信するためにＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ Ｈ．２６３またはＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４、Ｐａｒｔ １０、Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）、およびそのような規格の拡張によって定義される規格に記述されているようなビデオ圧縮技術を実装する。

ビデオ圧縮技術は、ビデオシーケンスに固有の冗長性を減らすか、または取り除くために空間予測および／または時間予測を実行する。ブロックベースのビデオ符号化では、ビデオフレームまたはスライスがいくつかのマクロブロックに分割され得る。それぞれのマクロブロックは、さらに分割され得る。イントラ符号化（intra-coded）（Ｉ）フレームまたはスライス内のマクロブロックは、隣接するマクロブロックに関して空間予測を使用してエンコードされる。インター符号化（inter-coded）（ＰまたはＢ）フレームまたはスライス内のマクロブロックでは、同じフレームもしくはスライス内の隣接するマクロブロックに関する空間予測または他の基準フレームに関する時間予測を使用することができる。

ビデオデータがエンコードされた後、そのビデオデータは、送信のために、または格納のためにマルチプレクサによってパケット化され得る。ＭＰＥＧ−２は、多くのビデオエンコード処理規格に対しトランスポートレベルを定義する「システム」セクションを備えている。ＭＰＥＧ−２トランスポートレベルのシステムは、ＭＰＥＧ−２ビデオエンコーダ、または異なるビデオエンコード処理規格に準拠する他のビデオエンコーダによって使用され得る。例えば、ＭＰＥＧ−４では、ＭＰＥＧ−２のとは異なるエンコード処理およびデコード処理の方法を規定しているが、ＭＰＥＧ−４規格の技術を実装するビデオエンコーダでは、ＭＰＥＧ−２トランスポートレベルの方法をそのまま使用することができる。一般に、「ＭＰＥＧ−２システム」を参照した場合、これは、ＭＰＥＧ−２によって規定されたビデオデータのトランスポートレベルを指す。ＭＰＥＧ−２によって規定されているトランスポートレベルは、本開示では、「ＭＰＥＧ−２トランスポートストリーム」または単に「トランスポートストリーム」とも称される。同様に、ＭＰＥＧ−２システムのトランスポートレベルは、プログラムストリームも含む。トランスポートストリームおよびプログラムストリームは、一般に、類似のデータを送るための異なるフォーマットを含み、トランスポートストリームはオーディオデータとビデオデータの両方を含む１つまたは複数の「プログラム」を備え、プログラムストリームはオーディオデータとビデオデータの両方を含む１つのプログラムを備える。

ＭＰＥＧ−２システム仕様では、デジタル送信または格納に適した単一のデータストリームを形成するため圧縮されたマルチメディア（ビデオおよびオーディオ）データストリームが他のデータと一緒にどのように多重化できるかを説明している。ＭＰＥＧ−２システムの最新仕様は、「Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ−Ｇｅｎｅｒｉｃ Ｃｏｄｉｎｇ ｏｆ Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅｓ ａｎｄ Ａｓｓｏｃｉａｔｅｄ Ａｕｄｉｏ： Ｓｙｓｔｅｍｓ， Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ Ｈ．２２２．０； Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｏｒｇａｎｉｓａｔｉｏｎ ｆｏｒ Ｓｔａｎｄａｒｄｉｓａｔｉｏｎ， ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１； Ｃｏｄｉｎｇ ｏｆ Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅｓ ａｎｄ Ａｓｓｏｃｉａｔｅｄ Ａｕｄｉｏ」（２００６年５月）において規定されている。ＭＰＥＧでは、最近、ＭＰＥＧ−２システム上のＭＶＣのトランスポート規格を設計しており、この仕様書の最新バージョンは、「Ｓｔｕｄｙ ｏｆ ＩＳＯ／ＩＥＣ １３８１８−１：２００７／ＦＰＤＡＭ４ Ｔｒａｎｓｐｏｒｔ ｏｆ ＭＶＣ」（ＭＰＥＧ ｄｏｃ． Ｎ１０５７２、ＭＰＥＧ ｏｆ ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１、Ｍａｕｉ、Ｈａｗａｉｉ、ＵＳＡ、２００９年４月）である。

一般に、本開示では、ＭＰＥＧ−２（Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）システムにおけるマルチビュービデオ符号化を改善するための技術を説明する。本開示の技術は、一般的に、ＭＰＥＧ−２トランスポートレベルの機能、例えば、ＭＰＥＧ−２トランスポートストリームとＭＰＥＧ−２プログラムストリームとをマルチビュービデオ符号化（ＭＶＣ）に関して拡張するものである。例えば、本開示の技術は、ＭＶＣビデオストリームの不連続ビューの送信がトランスポートレベルで行われることを可能にする。本開示の技術は、トランスポートストリーム（またはプログラム）のサブビットストリームがそれぞれ不連続ビューを含むことをさらに可能にする。これらの技術は、受信デバイスが、それぞれ不連続ビューを有する複数のサブビットストリームを備えるトランスポートレベルストリームを受信した後にトランスポートストリームが適切な順序で、つまり、ビュー順序インデックスに関して昇順で並ぶようにサブビットストリーム内のビューを再配置し、デコーダが複数あるビューのそれぞれのビューのフレームを適切にデコードすることができるようにすることも可能にする。

一例では、方法は、対応するＭＰＥＧ−２（Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）システム規格のビットストリームが第１のビュー順序インデックスに関連付けられているシーンの第１のビューと第２のビュー順序インデックスに関連付けられているシーンの第２のビューとを備え、第１のビュー順序インデックスおよび第２のビュー順序インデックスが不連続であることを信号により伝達するためのデータ構造体をソースデバイスにより構成することを含む。この方法は、データ構造体を出力すること、例えば、データ構造体をデスティネーションデバイスに送信するか、またはデータ構造体をコンピュータ可読媒体に格納することも含む。

別の例では、装置は、シーンの複数のビューをエンコードするビデオエンコーダと、対応するＭＰＥＧ−２（Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）システム規格のビットストリームが第１のビュー順序インデックスに関連付けられているシーンの複数のビューのうちの第１のビューと第２のビュー順序インデックスに関連付けられているシーンの複数のビューのうちの第２のビューとを備え、第１のビュー順序インデックスおよび第２のビュー順序インデックスが不連続であることを信号により伝達するためのデータ構造体を構成するマルチプレクサと、データ構造体を出力する出力インターフェースとを含む。

別の例では、装置は、対応するＭＰＥＧ−２（Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）システム規格のビットストリームが第１のビュー順序インデックスに関連付けられているシーンの第１のビューと第２のビュー順序インデックスに関連付けられているシーンの第２のビューとを備え、第１のビュー順序インデックスおよび第２のビュー順序インデックスが不連続であることを信号により伝達するためのデータ構造体をソースデバイスにより構成するための手段と、データ構造体を出力するための手段とを含む。

別の例では、コンピュータ可読記憶媒体は、対応するＭＰＥＧ−２（Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）システム規格のビットストリームが第１のビュー順序インデックスに関連付けられているシーンの第１のビューと第２のビュー順序インデックスに関連付けられているシーンの第２のビューとを備え、第１のビュー順序インデックスおよび第２のビュー順序インデックスが不連続であることを信号により伝達するためのデータ構造体を構成し、データ構造体を出力することをプロセッサに行わせる命令でエンコードされる。

さらに別の例では、方法は、クライアントデバイスにより、プライマリサブビットストリームとプライマリサブビットストリームの埋め込みサブビットストリームとを備える受信されたビットストリームからマルチビュービデオ符号化（ＭＶＣ）規格準拠のビットストリームを生成することを含み、ＭＶＣ規格準拠のピットストリームを生成することが、プライマリサブビットストリームのビューコンポーネントが埋め込みサブビットストリームのビューコンポーネントのビュー順序インデックスより大きいビュー順序インデックスを有するかどうかを判定することと、プライマリサブビットストリームのビューコンポーネントのビュー順序インデックスが埋め込みサブビットストリームのビューコンポーネントのビュー順序インデックスより大きい場合に、埋め込みサブビットストリームのビューコンポーネントを生成されたビットストリームに追加することと、プライマリサブビットストリームのビューコンポーネントのビュー順序インデックスが埋め込みサブビットストリームのビューコンポーネントのビュー順序インデックスより大きくない場合に、プライマリサブビットストリームのビューコンポーネントを生成されたビットストリームに追加することとを含む。この方法は、生成されたビットストリームをビデオデコーダに出力することをさらに含む。

別の例では、装置は、プライマリサブビットストリームとプライマリサブビットストリームの埋め込みサブビットストリームとを備えるビットストリームを受信する入力インターフェースと、受信されたビットストリームからマルチビュービデオ符号化（ＭＶＣ）規格準拠のビットストリームを生成するデマルチプレクサであって、ＭＶＣ規格準拠のビットストリームを生成するために、プライマリサブビットストリームのビューコンポーネントが埋め込みサブビットストリームのビューコンポーネントのビュー順序インデックスより大きいビュー順序インデックスを有するかどうかを判定し、プライマリサブビットストリームのビューコンポーネントのビュー順序インデックスが埋め込みサブビットストリームのビューコンポーネントのビュー順序インデックスより大きい場合に、埋め込みサブビットストリームのビューコンポーネントを生成されたビットストリームに追加し、プライマリサブビットストリームのビューコンポーネントのビュー順序インデックスが埋め込みサブビットストリームのビューコンポーネントのビュー順序インデックスより大きくない場合に、プライマリサブビットストリームのビューコンポーネントを生成されたビットストリームに追加するデマルチプレクサと、デマルチプレクサによって生成されたビットストリームをデコードするビデオデコーダとを含む。

別の例では、装置は、プライマリサブビットストリームとプライマリサブビットストリームの埋め込みサブビットストリームとを備える受信されたビットストリームからマルチビュービデオ符号化（ＭＶＣ）規格準拠のビットストリームを生成するための手段と、プライマリサブビットストリームのビューコンポーネントが埋め込みサブビットストリームのビューコンポーネントのビュー順序インデックスより大きいビュー順序インデックスを有するかどうかを判定するための手段と、プライマリサブビットストリームのビューコンポーネントのビュー順序インデックスが埋め込みサブビットストリームのビューコンポーネントのビュー順序インデックスより大きい場合に、埋め込みサブビットストリームのビューコンポーネントを生成されたビットストリームに追加するための手段と、プライマリサブビットストリームのビューコンポーネントのビュー順序インデックスが埋め込みサブビットストリームのビューコンポーネントのビュー順序インデックスより大きくない場合に、プライマリサブビットストリームのビューコンポーネントを生成されたビットストリームに追加するための手段と、生成されたビットストリームをビデオデコーダに出力するための手段とを含む。

別の例では、コンピュータ可読記憶媒体は、クライアントデバイスのプログラム可能なプロセッサに、プライマリサブビットストリームとプライマリサブビットストリームの埋め込みサブビットストリームとを備える受信されたビットストリームからマルチビュービデオ符号化（ＭＶＣ）規格準拠のビットストリームを生成することを行わせる命令であって、プライマリサブビットストリームのビューコンポーネントが埋め込みサブビットストリームのビューコンポーネントのビュー順序インデックスより大きいビュー順序インデックスを有するかどうかを判定するための命令と、プライマリサブビットストリームのビューコンポーネントのビュー順序インデックスが埋め込みサブビットストリームのビューコンポーネントのビュー順序インデックスより大きい場合に、埋め込みサブビットストリームのビューコンポーネントを生成されたビットストリームに追加する命令と、プライマリサブビットストリームのビューコンポーネントのビュー順序インデックスが埋め込みサブビットストリームのビューコンポーネントのビュー順序インデックスより大きくない場合に、プライマリサブビットストリームのビューコンポーネントを生成されたビットストリームに追加する命令とを備える命令と、生成されたビットストリームをビデオデコーダに出力することを行わせる命令とでエンコードされる。

１つまたは複数の例の詳細は、添付図面および以下の説明で述べられる。他の特徴、目的、および利点は、説明と図面、さらには請求項から明らかになるであろう。

図１は、オーディオ／ビデオ（Ａ／Ｖ）ソースデバイスがオーディオおよびビデオデータをＡ／Ｖデスティネーションデバイスにトランスポートする例示的なシステムを示すブロック図である。 図２は、マルチプレクサのコンポーネントの例示的な配置構成を示すブロック図である。 図３は、例示的な一組のプログラム特定情報テーブルを示すブロック図である。 図４は、マルチビュービデオ符号化（ＭＶＣ）拡張記述子に含まれ得る例示的な一組のデータを示すブロック図である。 図５は、階層記述子に含まれ得る例示的な一組のデータを示すブロック図である。 図６は、例示的なＭＶＣ予測パターンを示す概念図である。 図７は、不連続ビュー順序インデックスを持つビューの部分集合を有するＭＰＥＧ−２システムストリームをサーバーからクライアントに送るための例示的な方法を示す流れ図である。 図８は、２つまたはそれ以上のサブビットストリームのビューコンポーネントをアセンブルしてビューコンポーネントが大きくなるビュー順序インデックスを有するようにビットストリームを生成するための例示的な方法を示す流れ図である。

本開示の技術は、一般的に、ＭＰＥＧ−２（Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）システム、つまり、トランスポートレベルの詳細に関してＭＰＥＧ−２に準拠するシステムにおけるマルチビュービデオ符号化（ＭＶＣ）を強化することを対象とする。ＭＰＥＧ−４は、例えば、ビデオエンコード処理の規格を定めるものであるが、一般的には、ＭＰＥＧ−４規格に準拠しているビデオエンコーダは、ＭＰＥＧ−２トランスポートレベルシステムを使用すると想定している。したがって、本開示の技術は、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ Ｈ．２６３、ＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４、またはＭＰＥＧ−２トランスポートストリームおよび／またはプログラムストリームを使用する他のビデオエンコード処理規格に準拠するビデオエンコーダに適用可能である。

特に、本開示の技術は、ＭＰＥＧ−２トランスポートストリームとプログラムストリームとに対するトランスポートレベルで構文エレメントを修正するために使用することができる。例えば、本開示の技術は、トランスポートストリームで送られるマルチビュービデオデータのそれぞれのビューを特に識別するためにトランスポートストリームで送信される記述子を含む。サーバーデバイスは、例えば、それぞれがマルチビュービデオ符号化ビデオデータの特定のビューの各部分集合を含み、サービスのビューの部分集合がクライアントデバイスによって実行されるアプリケーション、クライアントデバイスによって実行されるデコーダの容量、クライアントデバイスが示すプリファレンス、または他の選択基準に基づき選択され得る、さまざまなサービスを提供することができる。

本開示の技術によれば、サーバーデバイスは、不連続ビュー順序インデックスを有するビューの部分集合を与えることができる。一例では、サーバーデバイスは、特に、プログラムマップテーブル（ＰＭＴ）またはプログラムストリームマップ（ＰＳＭ）に含まれ得るＭＶＣ拡張記述子におけるトランスポートストリームに含まれるビューのそれぞれに信号を送る。

いくつかの例では、サーバーデバイスは、単一のトランスポートストリームまたはプログラムストリームで複数のサブビットストリームを送ることができる。ビットストリームのビューが不連続であることを可能にすることによって、本開示の技術は、それぞれのサブビットストリームのビューに対応するビュー順序インデックスが不連続となることも可能にする。これらの技術は、それぞれのサブビットストリーム内の不連続ビュー順序インデックスを可能にするけれども、ビュー順序インデックスは、いぜんとして、既存のビットストリーム規格、例えば、ＭＰＥＧ−２システム規格に準拠するために、サブビットストリームにおいて増加するものである必要がある。しかし、第１のサブビットストリームおよび第２のサブビットストリームのビューは、それぞれ不連続である場合があるため、これらのビューはビュー順序インデックスに関して順序通りでなくクライアントデバイスに到達し得る。本開示の技術は、クライアントデバイスがそのようなトランスポートストリームを処理して第１のサブビットストリームと第２のサブビットストリームのビューをビューのビュー順序インデックスが大きくなるように効率よく順序変更することも可能にする。不連続のビュー順序インデックスを有するビュー組み合わせが、帯域幅適応、デコーダ効率に有用と思われる、ビュースケーラビリティに使用され、他のそのような利点をももたらし得る。例えば、連続するビュー順序インデックスを有する、すべてのビューをクライアントデバイスに送ることとクライアントデバイスがそれぞれのビューをデコードすることとを要求する従来の技術とは反対に、本開示の技術は、この結果ビューが不連続ビュー順序インデックスを有することになっても、クライアントデバイスによって特に要求されるビューのみを送ることを可能にする。この方法では、クライアントデバイスは、間にあるビュー順序インデックスを持つすべてのビューではなく、特定のサービスに必要なビューのみを受信することができる。

さまざまな節において、本開示は、「トランスポートストリーム」または「プログラムストリーム」を個別に参照し得るが、本開示の技術は、一般的に、ＭＰＥＧ−２トランスポートストリームとプログラムストリームのいずれかまたは両方に適用可能であることは理解されるであろう。一般に、本開示は、本開示の技術を実行するための例示的な記述子を説明している。ストリームの機能を拡張するために、記述子が使用される。本開示の記述子は、本開示の技術を実装するためにトランスポートストリームとプログラムストリームの両方によって使用され得る。

本開示では、以下の用語も使用し、またこれらの用語を示されているような用語の意味と併せて現行のＭＰＥＧ−２システム規格の改訂に含めることを提案する：
・ ＡＶＣビデオサブビットストリーム：ＭＶＣビットストリームのベースビュー。
・ ＭＶＣのＡＶＣビデオサブビットストリーム：プレフィックスＮＡＬユニットを無視したＭＶＣビットストリームのベースビュー。
・ ＭＶＣベースビューサブビットストリーム：ＡＶＣビデオサブストリームまたはＭＶＣのＡＶＣビデオサブビットストリームのいずれか。
・ ＭＶＣビューコンポーネント部分集合：１つのビューコンポーネントのＮＡＬユニット。
・ ＭＶＣ ｖｉｅｗ＿ｉｄ部分集合：１つのビューのＮＡＬユニット。
・ ＭＶＣビデオサブビットストリーム：非ベースビューのＮＡＬユニット。

図１は、オーディオ／ビデオ（Ａ／Ｖ）ソースデバイス２０がオーディオおよびビデオデータをＡ／Ｖデスティネーションデバイス４０にトランスポートする例示的なシステム１０を示すブロック図である。図１のシステム１０は、テレビ遠隔会議システム、サーバー／クライアントシステム、放送装置／受信機システム、またはビデオデータがＡ／Ｖソースデバイス２０などのソースデバイスからＡ／Ｖデスティネーションデバイス４０などのデスティネーションデバイスに送られる他のシステムに対応し得る。いくつかの例では、Ａ／Ｖソースデバイス２０およびＡ／Ｖデスティネーションデバイス４０は、双方向情報交換を実行することができる。つまり、Ａ／Ｖデバイス２０およびＡ／Ｖデスティネーションデバイス４０は、オーディオおよびビデオデータのエンコードとデコード（さらに送信と受信）の両方を行うことができるものとしてよい。いくつかの例では、オーディオエンコーダ２６は、ボコーダとも称される、音声エンコーダを備えることができる。

図１の例における、Ａ／Ｖソースデバイス２０は、オーディオソース２２とビデオソース２４とを備える。オーディオソース２２は、例えば、オーディオエンコーダ２６によってエンコードされるべき取り込まれたオーディオデータを表す電気信号を発生するマイクロホンを備えることができる。あるいは、オーディオソース２２は、すでに記録されているオーディオデータを格納している記憶媒体、コンピュータ制御シンセサイザなどのオーディオデータ生成装置、またはオーディオデータの他のソースを備えることができる。ビデオソース２４は、ビデオエンコーダ２８によってエンコードされるべきビデオデータを生成するビデオカメラ、すでに記録されているビデオデータでエンコードされた記憶媒体、ビデオデータ生成ユニット、またはビデオデータの他のソースを備えることができる。生のオーディオおよびビデオデータは、アナログまたはデジタルデータを備えることができる。アナログデータは、オーディオエンコーダ２６および／またはビデオエンコーダ２８によってエンコードされる前に２値化され得る。オーディオソース２２は、話者が話している最中に話者からオーディオデータを取得することができ、ビデオソース２４は、話者のビデオデータを同時に取得することができる。他の例では、オーディオソース２２は、格納されているオーディオデータを備えるコンピュータ可読記憶媒体を備えることができ、ビデオソース２４は、格納されているビデオデータを備えるコンピュータ可読記憶媒体を備えることができる。この方法で、本開示において説明されている技術が、ライブの、ストリーミング再生による、リアルタイムのオーディオおよびビデオデータに、またはアーカイブされている、記録済みのオーディオおよびビデオデータに適用され得る。

ビデオフレームに対応するオーディオフレームは、一般的に、ビデオフレーム内に収められているビデオソース２４によって取り込まれたビデオデータと同時にオーディオソース２２によって取り込まれたオーディオデータを収めてあるオーディオフレームである。例えば、話者は、一般的に、発話することによってオーディオデータを生成するが、オーディオソース２２はオーディオデータを取り込み、ビデオソース２４はそれと同時に、つまり、オーディオソース２２がオーディオデータを取り込んでいる最中に、話者のビデオデータを取り込む。したがって、オーディオフレームは、１つまたは複数の特定のビデオフレームに時間的に対応するものとしてよい。そのため、ビデオフレームに対応するオーディオフレームは、一般的に、オーディオデータおよびビデオデータが同時に取り込まれ、オーディオフレームおよびビデオフレームがそれぞれオーディオデータと同時に取り込まれたビデオデータとを備える状況に対応する。

いくつかの例では、オーディオエンコーダ２６は、エンコードされたオーディオフレームに対するオーディオデータが記録された時点を表すそれぞれのエンコードされたオーディオフレーム内のタイムスタンプをエンコードすることができ、同様に、ビデオエンコーダ２８は、エンコードされたビデオフレームに対するビデオデータが記録された時点を表すそれぞれのエンコードされたビデオフレーム内のタイムスタンプをエンコードすることができる。そのような例では、ビデオフレームに対応するオーディオフレームは、タイムスタンプを備えるオーディオフレームと、同じタイムスタンプを備えるビデオフレームとを備えることができる。Ａ／Ｖソースデバイス２０は、オーディオエンコーダ２６および／またはビデオエンコーダ２８がそこからタイムスタンプを生成することができるか、あるいはオーディオソース２２およびビデオソース２４がオーディオデータとビデオデータとをそれぞれタイムスタンプに関連付けるために使用することができる、内部クロックを含むことができる。いくつかの例では、オーディオソース２２は、オーディオデータが記録された時点に対応するデータをオーディオエンコーダ２６に送ることができ、ビデオソース２４は、ビデオデータが記録された時点に対応するデータをビデオエンコーダ２８に送ることができる。いくつかの例では、オーディオエンコーダ２６は、オーディオデータが記録された絶対時間を必ずしも示すことなくエンコードされたオーディオデータの相対的時間順序を示すようにエンコードされたオーディオデータ内にシーケンス識別子をエンコードすることができ、同様に、ビデオエンコーダ２８も、エンコードされたビデオデータの相対的時間順序を示すようにシーケンス識別子を使用することができる。同様に、いくつかの例では、シーケンス識別子がマッピングされるか、またはタイムスタンプと何らかの形で相関させることができる。

本開示の技術は、一般的に、エンコードされたマルチメディア（例えば、オーディオとビデオ）データのトランスポートを対象とし、またトランスポートされたマルチメディアデータの受信とその後の解釈とデコードとを対象とする。本開示の技術は、マルチビュービデオ符号化（ＭＶＣ）データ、つまり、複数のビューを備えるビデオデータのトランスポートに特に適用可能である。図１の例に示されているように、ビデオソース２４は、１つのシーンの複数のビューをビデオエンコーダ２８に供給することができる。ＭＶＣは、立体視または裸眼立体視三次元ディスプレイなどの三次元ディスプレイによって使用されるべき三次元ビデオデータを生成する場合にも有用であり得る。

Ａ／Ｖソースデバイス２０は、「サービス」をＡ／Ｖデスティネーションデバイス４０に提供することができる。サービスは、一般的に、ＭＶＣデータの利用可能なビューの部分集合に対応する。例えば、ＭＶＣデータは、０から７まで順序付けられた８つのビューに利用可能であるものとすることができる。一方のサービスは、２つのビューを有する立体ビデオに対応するが、別のサービスは、４つのビューに対応することができ、さらに別のサービスは、８つすべてのビューに対応することができる。一般に、サービスは、利用可能なビューの任意の組み合わせ（つまり、部分集合）に対応する。サービスは、利用可能なビューとオーディオデータとの組み合わせにも対応し得る。

Ａ／Ｖソースデバイス２０は、本開示の技術によれば、不連続ビュー順序インデックスを含むビューの部分集合に対応するサービスを提供することができる。一般に、ビューは、「ｖｉｅｗ＿ｉｄ」とも称される、ビュー識別子によって表される。ビュー識別子は、一般的に、ビューを識別するために使用され得る構文エレメントを備える。ＭＶＣエンコーダは、ビューがエンコードされるときにビューのｖｉｅｗ＿ｉｄを与える。ｖｉｅｗ＿ｉｄは、ビュー間予測のためにＭＶＣデコーダによって使用されるか、または他の目的のために、例えば、レンダリングするために、他のユニットによって使用され得る。

ビュー間予測は、共通の時間位置の１つまたは複数のフレームを異なるビューのエンコードされたフレームとして参照しつつフレームのＭＶＣビデオデータをエンコードするための技術である。図６は、以下でさらに詳しく説明されるが、ビュー間予測の例示的な符号体系を示している。一般に、ＭＶＣビデオデータのエンコードされたフレームは、空間的に、時間的に、および／または共通の時間位置における他のビューのフレームを参照しつつ予測的にエンコードされ得る。したがって、他のビューを予測する際に元になる基準ビューは、一般的に、基準ビューが基準として働くビューの前にデコードされ、そのため、それらのデコードされたビューは基準ビューをデコードするときに基準として使用され得る。デコード順序は、必ずしも、ｖｉｅｗ＿ｉｄｓの順序に対応しない。したがって、ビューのデコード順序は、ビュー順序インデックスを使用して記述される。ビュー順序インデックスは、アクセスユニット内の対応するビューコンポーネントのデコード順序を示すインデックスである。

（オーディオもしくはビデオの）データのそれぞれの個別ストリームは、エレメンタリストリームと称される。エレメンタリストリームは、プログラムの単一の２値符号化された（場合によっては圧縮された）コンポーネントである。例えば、プログラムの符号化されたビデオまたはオーディオ部分は、エレメンタリストリームとすることができる。エレメンタリストリームは、プログラムストリームまたはトランスポートストリームに多重化される前にパケット化エレメンタリストリーム（ＰＥＳ）に変換されることができる。同じプログラム内で、ストリームＩＤは、一方のエレメンタリストリームに属すＰＥＳパケットを他方のものから区別するために使用される。エレメンタリストリームのデータの基本ユニットは、パケット化エレメンタリストリーム（ＰＥＳ）パケットである。そのため、ＭＶＣビデオデータのそれぞれのビューは、各エレメンタリストリームに対応する。同様に、オーディオデータは各エレメンタリストリームに対応する。図１の例では、マルチプレクサ３０は、ビデオエンコーダ２８からのビデオデータを備えるエレメンタリストリームとオーディオエンコーダ２６からのオーディオデータを備えるエレメンタリストリームとを受信する。いくつかの例では、ビデオエンコーダ２８およびオーディオエンコーダ２６は、それぞれ、エンコードされたデータからＰＥＳパケットを形成するためにパケタイザーを含むことができる。他の例では、ビデオエンコーダ２８およびオーディオエンコーダ２６は、それぞれ、エンコードされたデータからＰＥＳパケットを形成するために各パケタイザーとインターフェースすることができる。さらに他の例では、マルチプレクサ３０は、エンコードされたオーディオおよびビデオデータからＰＥＳパケットを形成するためにパケタイザーを含むことができる。

本開示で使用されているような「プログラム」は、オーディオデータとビデオデータ、例えば、オーディオエレメンタリストリームとＡ／Ｖソースデバイス２０のサービスによって送られる利用可能なビューの部分集合の組み合わせを備えることができる。それぞれのＰＥＳパケットは、ＰＥＳパケットが属すエレメンタリストリームを識別するｓｔｒｅａｍ＿ｉｄを含む。マルチプレクサ３０は、エレメンタリストリームを構成要素であるプログラムストリームまたはトランスポートストリームにアセンブルする役割を有する。プログラムストリームおよびトランスポートストリームは、異なるアプリケーションをターゲットとする２つの代替的マルチプレクサである。

一般に、プログラムストリームは、１つのプログラムに対するデータからなり、その一方でトランスポートストリームは、１つまたは複数のプログラムに対するデータを備えることができる。マルチプレクサ３０は、提供されるサービス、ストリームが受け渡される媒体、送られる多数のプログラム、または他の考慮事項に基づき、プログラムストリームまたはトランスポートストリームのいずれかまたは両方をエンコードすることができる。例えば、ビデオデータが記憶媒体内にエンコードされる場合、マルチプレクサ３０は、１つのプログラムストリームを形成する可能性がより高いが、ビデオデータがネットワーク上でストリーミングされるか、または放送されるか、またはテレビ電話の一部として送られる場合、マルチプレクサ３０は、トランスポートストリームを使用する可能性がより高いものとすることができる。

マルチプレクサ３０は、デジタルストレージサービスからの単一のプログラムの格納および表示のためにプログラムストリームを使用することに有利である。プログラムストリームは、プログラムストリームがむしろエラーの影響を受けやすいため、エラーのない環境またはエラーの発生に左右されにくい環境で使用することが意図されている。プログラムストリームは、それに属するエレメンタリストリームを単に備えるだけであり、通常は可変長パケットのパケットを含む。プログラムストリームでは、寄与するエレメンタリストリームに由来するＰＥＳパケットは「パック」に編成される。パックは、パックヘッダ、オプションのシステムヘッダ、および寄与するエレメンタリストリームのどれかから取り出された任意の数のＰＥＳパケットを、任意の順序で備える。システムヘッダは、最大データ転送速度、寄与するビデオおよびオーディオエレメンタリストリームの数、さらなるタイミング情報、または他の情報などのプログラムストリームの特性の要約を含む。デコーダは、システムヘッダに収められている情報を使用して、デコーダがプログラムストリームをデコードすることができるかどうかを判定することができる。

マルチプレクサ３０は、トランスポートストリームを使用して、潜在的にエラーを起こしがちなチャネル上で複数のプログラムの同時配送を行うことができる。トランスポートストリームは、放送など多重プログラムアプリケーション用に考案された多重送信であり、単一のトランスポートストリームで多くの独立したプログラムを受け入れることができる。トランスポートストリームは、一連のトランスポートパケットを備え、これらのトランスポートパケットのそれぞれは１８８バイト長である。短い固定長パケットを使用するということは、トランスポートストリームがプログラムストリームに比べてエラーの影響を受けにくいことを意味する。さらに、それぞれの１８８バイト長のトランスポートパケットは、リードソロモンエンコード処理などの、標準のエラー保護プロセスを通じてパケットを処理することによってエラー保護能力を高めることができる。トランスポートストリームのエラー耐性が向上しているということは、例えば放送環境において見られるエラーを起こしがちなチャネルを生き延びることができる確率が高いことを意味する。

トランスポートストリームは、エラー耐性の向上と多数の同時プログラムを伝送する能力を持つ２つの多重送信のうちのよい方であることは明らかである。しかし、トランスポートストリームは、プログラムストリームに比べてより高度な多重送信であり、その結果、作成も逆多重化も難しい。トランスポートパケットの１番目のバイトは、値０ｘ４７（１６進数４７、２進数「０１０００１１１」、１０進数７１）を有する同期バイトである。単一のトランスポートストリームは、異なる多数のプログラムを伝送することができ、それぞれのプログラムは多数のパケット化エレメンタリストリームを備える。マルチプレクサ３０は、１３ビットのパケット識別子（ＰＩＤ）フィールドを使用して、エレメンタリストリームのデータを収めたトランスポートパケットを他のエレメンタリストリームのデータを伝送するトランスポートパケットから区別することができる。それぞれのエレメンタリストリームが固有のＰＩＤ値を確実に与えられるようにすることは、マルチプレクサの役割である。トランスポートパケットの最後のバイトは、連続カウントフィールドである。マルチプレクサ３０は、同じエレメンタリストリームに属す連続するトランスポートパケット間で連続カウントフィールドの値をインクリメントする。これは、デコーダ、またはＡ／Ｖデスティネーションデバイス４０などのデスティネーションデバイスの他のユニットが、トランスポートパケットの損失または取得を検出し、そのようなイベントから結果として他の何らかの形で発生するおそれのあるエラーをあわよくば隠すことを可能にする。

マルチプレクサ３０は、オーディオエンコーダ２６とビデオエンコーダ２８とからプログラムのエレメンタリストリームに対するＰＥＳパケットを受信し、ＰＥＳパケットから対応するネットワーク抽象化層（ＮＡＬ）ユニットを形成する。Ｈ．２６４／ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）の例では、符号化されたビデオセグメントが複数のＮＡＬユニットに編成され、テレビ電話、ストレージ、放送、またはストリーミングなどのアプリケーションを扱う「ネットワークフレンドリー」なビデオ表現を構成する。ＮＡＬユニットは、ビデオ符号化層（ＶＣＬ）ＮＡＬユニットと非ＶＣＬ ＮＡＬユニットとに分類され得る。ＶＣＬユニットは、コア圧縮エンジンを含んでおり、ブロック、マクロブロック、および／またはスライスレベルを備えることができる。他のＮＡＬユニットは、非ＶＣＬ ＮＡＬユニットである。

マルチプレクサ３０は、ＮＡＬが属すプログラムを識別するヘッダ、さらにはペイロード、例えば、オーディオデータ、ビデオデータ、またはＮＡＬユニットが対応するトランスポートもしくはプログラムストリームを記述するデータを備えるＮＡＬユニットを形成し得る。例えば、Ｈ．２６４／ＡＶＣでは、ＮＡＬユニットは１バイトのヘッダと可変サイズのペイロードとを含む。一例では、ＮＡＬユニットヘッダは、ｐｒｉｏｒｉｔｙ＿ｉｄエレメントとｔｅｍｐｏｒａｌ＿ｉｄエレメントとａｎｃｈｏｒ＿ｐｉｃ＿ｆｌａｇエレメントとｖｉｅｗ＿ｉｄエレメントとｎｏｎ＿ｉｄｒ＿ｆｌａｇエレメントとｉｎｔｅｒ＿ｖｉｅｗ＿ｆｌａｇエレメントとを備える。従来のＭＶＣでは、Ｈ．２６４によって定義されているＮＡＬユニットは、４バイトのＭＶＣ ＮＡＬユニットヘッダとＮＡＬユニットペイロードとを含む、プレフィックスＮＡＬユニットとＭＶＣ符号化スライスＮＡＬユニットとを除いて、保持される。

ＮＡＬヘッダのｐｒｉｏｒｉｔｙ＿ｉｄエレメントが、単純な１パスビットストリーム適応プロセスに使用され得る。ｔｅｍｐｏｒａｌ＿ｉｄエレメントは、対応するＮＡＬユニットの時間的レベルを指定するために使用することができ、異なる時間的レベルは異なるフレームレートに対応する。ａｎｃｈｏｒ＿ｐｉｃ＿ｆｌａｇエレメントは、ピクチャーがアンカーピクチャーであるか、または非アンカーピクチャーであるかを示すことができる。

アンカーピクチャーおよび出力順序（つまり、表示順序）でそれに続くすべてのピクチャーは、デコード順序（つまり、ビットストリーム順序）で前のピクチャーのデコードなしで正しくデコードされ、したがってランダムアクセスポイントとして使用され得る。アンカーピクチャーおよび非アンカーピクチャーは、異なる依存関係を有することができ、その両方がシーケンスパラメータセットにおいて信号により伝達される。この章の以下の節において、他のフラグも説明し、使用する。そのようなアンカーピクチャーは、オープンＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅｓ）アクセスポイントとも称され得るが、クローズＧＯＰアクセスポイントも、ｎｏｎ＿ｉｄｒ＿ｆｌａｇエレメントがゼロに等しいときにサポートされる。ｎｏｎ＿ｉｄｒ＿ｆｌａｇエレメントは、ピクチャーが瞬時デコーダリフレッシュ（ＩＤＲ）ピクチャーであるか、またはビューＩＤＲ（Ｖ−ＩＤＲ）ピクチャーであるかを示す。一般に、ＩＤＲピクチャー、および出力順序またはストリーム順序でそれに続くすべてのピクチャーは、デコード順序または表示順序のいずれかで前のピクチャーをデコードせずに正しくデコードされ得る。

ｖｉｅｗ＿ｉｄエレメントは、ＭＶＣデコーダ内ではデータの相互のやり取りに、例えば、ビュー間予測に、またデコーダの外部で、例えば、レンダリングに使用され得る、ビューを識別するために使用することができる構文情報を備える。ｉｎｔｅｒ＿ｖｉｅｗ＿ｆｌａｇエレメントは、対応するＮＡＬユニットがビュー間予測のために他のビューによって使用されるかどうかを指定することができる。ＡＶＣに準拠しているものとしてよい、ベースビューの４バイトのＮＡＬユニットヘッダ情報を伝達するために、プレフィックスＮＡＬユニットがＭＶＣ内で定義される。ＭＶＣに関連して、ベースビューアクセスユニットは、ビューの現在時刻インスタンスのＶＣＬ ＮＡＬユニットと、さらにはＮＡＬユニットヘッドのみを収めたそのプレフィックスＮＡＬユニットとを含む。Ｈ．２６４／ＡＶＣデコーダは、プレフィックスＮＡＬユニットを無視してもよい。

ペイロード内にビデオデータを含むＮＡＬユニットは、さまざまなグラニュラリティ（granularity）レベルのビデオデータを含み得る。例えば、ＮＡＬユニットは、ビデオデータのブロック、１つのマクロブロック、複数のマクロブロック、ビデオデータのスライス、またはビデオデータのフレーム全体を備えることができる。マルチプレクサ３０は、エレメンタリストリームのＰＥＳパケットの形態でビデオエンコーダ２８からエンコードされたビデオデータを受信することができる。マルチプレクサ３０は、ｓｔｒｅａｍ＿ｉｄｓを、データベースもしくは例えばプログラムマップテーブル（ＰＭＴ）またはプログラムストリームマップ（ＰＳＭ）などの他のデータ構造体内の対応するプログラムにマッピングすることによって、それぞれのエレメンタリストリームを対応するプログラムに関連付けることができる。

マルチプレクサ３０は、複数のＮＡＬユニットからアクセスユニットをアセンブルすることもできる。一般に、アクセスユニットは、ビデオデータ、さらにはオーディオデータのフレームを表すための１つまたは複数のＮＡＬユニットを備えることができ、オーディオデータはそのようなオーディオデータが利用可能である場合にフレームに対応する。Ｈ．２６４／ＡＶＣに対応する例では、アクセスユニットは、１つの時間インスタンスにおいて符号化されたピクチャーを備えることができ、これは一次符号化ピクチャーとして示され得る。したがって、アクセスユニットは、共通の時間インスタンス、例えば、時間Ｘに対応するすべてのビューのすべてのオーディオおよびビデオフレームを備えることができる。本開示では、特定のビューのエンコードされたピクチャーを「ビューコンポーネント」とも称する。つまり、ビューコンポーネントは、特定の時間の特定のビューに対するエンコードされたピクチャー（またはフレーム）を備える。したがって、アクセスユニットは、共通の時間インスタンスのすべてのビューコンポーネントを備えるものとして定義され得る。

マルチプレクサ３０は、ＮＡＬユニット内にプログラムに関するデータを埋め込むこともできる。例えば、マルチプレクサ３０は、プログラムマップテーブル（ＰＭＴ）またはプログラムストリームマップ（ＰＳＭ）を備えるＮＡＬユニットを作成することができる。一般に、ＰＭＴは、トランスポートストリームを記述するために使用され、ＰＳＭは、プログラムストリームを記述するために使用される。以下の図２の例に関してさらに詳しく説明されているように、マルチプレクサ３０は、オーディオエンコーダ２６とビデオエンコーダ２８とから受信されたエレメンタリストリームをプログラムに、したがって各トランスポートストリームおよび／またはプログラムストリームに関連付けるデータストレージユニットを備えるか、またはそのようなデータストレージユニットと相互にやり取りすることができる。

ＭＰＥＧ−２システム規格では、「記述子」を使ってシステムの拡張を行うことができる。ＰＭＴおよびＰＳＭの両方が、１つまたは複数の記述子が挿入され得る記述子ループを含む。一般に、記述子は、プログラムおよび／またはプログラムエレメントの定義を拡張するために使用され得る構造体を備える。本開示では、本開示の技術を実行するために、ＭＶＣ拡張記述子と階層記述子の２つの記述子を説明している。一般に、本開示のＭＶＣ拡張記述子は、プログラムストリームまたはトランスポートストリームに埋め込まれているビューのビュー順序インデックスを特に識別することによって従来のＭＶＣ拡張記述子を機能強化するが、本開示の階層記述子は、関連付けられているプログラムエレメントが階層記述子のエレメントによって参照されているプログラムエレメントから結果として得られるビットストリームのビューの数を増やすかどうかを示すフラグを含む。

ＩＴＵ−Ｔ Ｈ．２６１、Ｈ．２６３、ＭＰＥＧ−１、ＭＰＥＧ−２、およびＨ．２６４／ＭＰＥＧ−４ ｐａｒｔ １０などのビデオ圧縮規格では、動き補償時間予測を使用して時間冗長性を低減する。エンコーダは、いくつかのすでにエンコードされたピクチャー（本明細書ではフレームとも称される）からの動き補償予測を使用して動きベクトルに応じて現在の符号化されているピクチャーを予測する。典型的なビデオ符号化には３つの主要なピクチャータイプがある。これらは、イントラ符号化ピクチャー（「Ｉピクチャー」または「Ｉフレーム」）、予測ピクチャー（「Ｐピクチャー」または「Ｐフレーム」）、および双方向予測ピクチャー（「Ｂピクチャー」または「Ｂフレーム」）である。Ｐピクチャーでは、時間順序で現在のピクチャーより前にある基準ピクチャーのみを使用する。Ｂピクチャーでは、Ｂピクチャーのそれぞれのブロックが１つまたは２つの基準ピクチャーから予測され得る。これらの基準ピクチャーは、時間順序で現在のピクチャーより前または後に配置される可能性もある。

一例として、Ｈ．２６４符号化規格によれば、Ｂピクチャーは、すでに符号化されている基準ピクチャーの２つのリスト、リスト０とリスト１とを使用する。これら２つのリストは、それぞれ、時間順序で過去および／または未来の符号化されたピクチャーを含むことができる。Ｂピクチャー内のブロックは、リスト０基準ピクチャーからの動き補償予測、リスト１基準ピクチャーからの動き補償予測、リスト０とリスト１の両方の基準ピクチャーの組み合わせからの動き補償予測の複数の方法のうちの１つで予測され得る。リスト０とリスト１の両方の基準ピクチャーの組み合わせを取得するために、２つの動き補償基準領域が、それぞれ、リスト０の基準ピクチャーとリスト１の基準ピクチャーとから得られる。これらの組み合わせは、現在のブロックを予測するために使用される。

ＩＴＵ−Ｔ Ｈ．２６４規格は、輝度成分に対する１６×１６、８×８、または４×４および彩度成分に対する８×８などのさまざまなブロックサイズのイントラ予測、さらには輝度成分に対する１６×１６と１６×８と８×１６と８×８と８×４と４×８と４×４および彩度成分に対する対応するスケーリングされたサイズなどのさまざまなブロックサイズのインター予測をサポートする。本開示では、「×」と「かける」、例えば「１６×１６ピクセル」または「１６かける１６ピクセル」は、入れ換えて使用することができ、垂直と水平の寸法に関するブロックのピクセル寸法を指す。一般に、１６×１６ブロックは、垂直方向に１６個のピクセル（ｙ＝１６）、水平方向に１６個のピクセル（ｘ＝１６）を有する。同様に、Ｎ×Ｎブロックは、一般的に、垂直方向にＮ個のピクセル、水平方向にＮ個のピクセルを有し、Ｎは非負整数値を表す。ブロック内のピクセルは、行と列とに配置され得る。

１６×１６未満のブロックサイズは、１６×１６マクロブロックのパーティションと称することができる。ビデオブロックは、例えば、離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、または概念上類似の変換などの変換を符号化ビデオブロックと予測ビデオブロックとのピクセル差を表す残留ビデオブロックデータに適用した後の、ピクセルドメイン内のピクセルデータのブロック、または変換ドメイン内の変換係数のブロックを備えることができる。いくつかの場合において、ビデオブロックは、変換ドメイン内の量子化変換係数のブロックを備えることができる。

より小さなビデオブロックは、より高い分解能をもたらし、高い詳細レベルを含むビデオフレームの配置に使用され得る。一般に、マクロブロックおよびときにはサブブロックとも称されるさまざまなパーティションがビデオブロックとみなされ得る。それに加えて、スライスも、マクロブロックおよび／またはサブブロックなどの複数のビデオブロックであるとみなされることができる。それぞれのスライスは、ビデオフレームの独立してデコード可能なユニットであることができる。あるいは、フレームそれ自体がデコード可能なユニットであるか、またはフレームの他の部分が、デコード可能なユニットとして定義され得る。「符号化されたユニット」または「符号化ユニット」は、フレーム全体、フレームのスライス、シーケンスとも称されるピクチャーのグループ（ＧＯＰ）、または適用可能な符号化技術に従って定義された別の独立してデコード可能なユニットなどのビデオフレームの独立してデコード可能なユニットを指すものとすることができる。

「マクロブロック」という用語は、１６×１６ピクセルを備える二次元ピクセル配列に従ってピクチャーおよび／またはビデオデータをエンコードするためのデータ構造体を指す。それぞれのピクセルは、彩度成分と輝度成分とを備える。したがって、マクロブロックは、それぞれが８×８ピクセルの二次元配列を備える４つの輝度ブロックと、それぞれが１６×１６ピクセルの二次元配列を備える２つの彩度ブロックと、符号化ブロックパターン（ＣＢＰ）、エンコードモード（例えば、イントラ（Ｉ）、またはインター（ＰまたはＢ）エンコードモード）、イントラエンコードブロック（例えば、１６×１６、１６×８、８×１６、８×８、８×４、４×８、または４×４）のパーティションに対するパーティションサイズ、またはインター符号化マクロブロックに対する１つまたは複数の動きベクトルなどの構文情報を備えるヘッダとを定義することができる。

ビデオエンコーダ２８、ビデオデコーダ４８、オーディオエンコーダ２６、オーディオデコーダ４６、マルチプレクサ４０、およびデマルチプレクサ３８は、それぞれ、適宜１つまたは複数のマイクロプロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリート部品による論理回路、ソフトウェア、ハードウェア、ファームウェア、またはこれらの任意の組み合わせなどの、さまざまな好適なエンコーダまたはデコーダ回路のうちのどれかとして実装され得る。ビデオエンコーダ２８およびビデオデコーダ４８のそれぞれは、１つまたは複数のエンコーダまたはデコーダに含まれるものとすることもでき、これらのいずれかが組み合わされたビデオエンコーダ／デコーダ（ＣＯＤＥＣ）の一部として集積化され得る。同様に、オーディオエンコーダ２６およびオーディオデコーダ４６のそれぞれは、１つまたは複数のエンコーダまたはデコーダに含まれるものとすることもでき、これらのいずれかが組み合わされたオーディオエンコーダ／デコーダ（ＣＯＤＥＣ）の一部として集積化され得る。ビデオエンコーダ２８、ビデオデコーダ４８、オーディオエンコーダオーディオエンコーダ２６、オーディオデコーダ４６、マルチプレクサ３０、および／またはデマルチプレクサ３８を含む装置は、集積回路、マイクロプロセッサ、および／または携帯電話などのワイヤレス通信デバイスを備えることができる。

本開示の技術は、いくつかの動作ポイントに対する信号特性のサポートを無効にする、ＭＶＣサブビットストリームに対する従来の技術に勝るいくつかの利点をもたらし得る。従来の技術とは異なり、本開示のＭＶＣ拡張記述子の構文エレメントおよびセマンティクスは、不連続ビュー順序インデックス値の使用を可能にし、そのため、ＭＶＣに適合し、また不連続であるビュー順序インデックス値を持つビットストリームもしくはサブビットストリームをサポートすることが可能になる。本開示は、デコードを成功させるためにＭＶＣサブビットストリームが他のビューに依存しているとデコーダが判定することを可能にする、信号によりビューエンハンスメント（view enhancement）を伝達するための階層記述子も提案する。

信号特性のサポートを改善するために、提案されているＭＶＣ拡張記述子で信号により知らされるようなビュー順序インデックス値は、適宜、不連続であることができる。さらに、ビュー順序インデックス値またはｖｉｅｗ＿ｉｄ値は、ＭＶＣ拡張記述子で信号により知らせることができる。

代替として、アクティブな従来のシーケンスパラメータセット（ＳＰＳ）ＭＶＣ拡張において定義されているビュー順序を修正することによって、適合しているＭＶＣビットストリームのビューのビュー順序インデックス値を連続するビュー順序インデックス値に、このＭＶＣサブビットストリームが多重化される前にマッピングする、ビュー順序インデックス再マッピングメカニズムが使用され得る。このようなメカニズムにおいて、従来のＭＶＣ拡張記述子は、ビュー順序インデックスではなくビューＩＤを信号により伝達するために使用され、したがって、エンコーダは、異なるビューＩＤを有するものとしてビューをエンコードするように再構成され、デコーダは、再構成されたエンコード順序に従って、従来のＭＶＣ拡張記述子を異なる形で解釈するように再構成され得る。例えば、それぞれビュー順序インデックス０と１と２とを有するｖｉｅｗ＿ｉｄ ０と１と２とを持つ３つのビューがあると仮定する。サービスは、ビュー０とビュー２のみを必要とするとさらに仮定する。エンコーダは、ビューＩＤ ０、２、１に対応する順序でビューをエンコードすることができ、従来のＳＰＳ ＭＶＣ拡張記述子は、０、２、１の順序でｖｉｅｗ＿ｉｄ値を信号により伝達するために使用され得る。この方法により、ビュー２は、１のビュー順序インデックスを有し、したがってビュー０とビュー２の組み合わせは連続するビュー順序インデックスを有する。

それに加えて、ＭＶＣのＡＶＣビデオサブビットストリームが存在するときにプレフィックスＮＡＬユニットの複製を回避するために、本開示では、プレフィックスＭＶＣサブビットストリームが定義されなければならないことといくつかの例ではそのようなプレフィックスＭＶＣサブビットストリームが、少なくとも１つのＭＶＣサブビットストリームがあるときに含まれることも提案する。さらに、本開示では、ベースビューに属す、ＭＶＣ特有のＳＥＩメッセージ、つまり、ＡＶＣ仕様書の付録Ｈにおいて定義されているＳＥＩメッセージ、またはＭＶＣビットストリームのすべてのビューに適用されるＭＶＣ ＳＥＩメッセージは、この「プレフィックスＭＶＣサブビットストリーム」内で関連付けられ、これが格納サイズまたは帯域幅の最適化に関して効率的な格納およびトランスポートを可能にすることを提案している。本開示は、同じ考え方が、「Ａｍｅｎｄｍｅｎｔ ３ ｏｆ Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｇｅｎｅｒｉｃ ｃｏｄｉｎｇ ｏｆ ｍｏｖｉｎｇ ｐｉｃｔｕｒｅｓ ａｎｄ ａｓｓｏｃｉａｔｅｄ ａｕｄｉｏ ｉｎｆｏｒｍａｔｉｏｎ： Ｓｙｓｔｅｍｓ」（本開示では「ＭＰＥＧ−２システム」または「ＭＰＥＧ−２システム規格」として参照されている）とも称される、ＭＰＥＧ−２システム上のスケーラブルなビデオのトランスポートにも適用できることも提案している。

マルチプレクサ３０が、受信されたデータからＮＡＬユニットおよび／またはアクセスユニットをアセンブルした後、マルチプレクサ３０は出力するためユニットを出力インターフェース３２に受け渡す。出力インターフェース３２は、例えば、送信機、トランシーバ、データを例えば光学式ドライブ、磁気媒体ドライブ（例えば、フロッピー（登録商標）ドライブ）などのコンピュータ可読媒体に書き込むためのデバイス、ユニバーサルシリアルバス（ＵＳＢ）ポート、ネットワークインターフェース、または他の出力インターフェースを備えることができる。出力インターフェース３２は、ＮＡＬユニットまたはアクセスユニットを、例えば送信信号、磁気媒体、光媒体、メモリ、フラッシュドライブ、または他のコンピュータ可読媒体などのコンピュータ可読媒体３４に出力する。

最終的に、入力インターフェース３６が、コンピュータ可読媒体３４からデータを取り出す。入力インターフェース３６は、例えば、光学式ドライブ、磁気媒体ドライブ、ＵＳＢポート、受信機、トランシーバ、または他のコンピュータ可読媒体インターフェースを備えることができる。入力インターフェース３６は、ＮＡＬユニットまたはアクセスユニットをデマルチプレクサ３８に送ることができる。デマルチプレクサ３８は、トランスポートストリームまたはプログラムストリームを構成要素のＰＥＳストリームに逆多重化し、ＰＥＳストリームを逆パケット化してエンコードされたデータを取り出し、エンコードされたデータがオーディオもしくはビデオストリームであるかどうかに応じて、例えばストリームのＰＥＳパケットヘッダによる指示に従って、エンコードされたデータをオーディオデコーダ４６もしくはビデオデコーダ４８のいずれかに送ることができる。オーディオデコーダ４６は、エンコードされたオーディオデータをデコードして、デコードされたオーディオデータをオーディオ出力４２に送り、ビデオデコーダ４８は、エンコードされたビデオデータをデコードして、１つのストリームの複数のビューを含んでいる可能性のある、デコードされたビデオデータをビデオ出力４４に送る。ビデオ出力４４は、１つのシーンの複数のビューを使用するディスプレイ、例えば、シーンのそれぞれのビューを同時に提示する立体視または裸眼立体視ディスプレイを備えることができる。

それに加えて、デマルチプレクサ３８は、例えば埋め込みサブビットストリームの少なくとも１つのビューが埋め込みサブビットストリームが埋め込まれているプライマリサブビットストリームのビューのビュー順序インデックスより小さいビュー順序インデックスを持つビューを有するときにストリームのビュー順序インデックスが厳密に昇順になっているように１つまたは複数のサブビットストリームのビューの順序を変更することができる。この方法では、Ａ／Ｖデスティネーションデバイス４０は、受信されたビットストリームからＭＶＣ規格準拠のビットストリームを生成するデマルチプレクサを備える装置に対応することができる。

図２は、マルチプレクサ３０（図１）のコンポーネントの例示的な配置構成を示すブロック図である。図２の例では、マルチプレクサ３０は、ストリーム管理ユニット６０とビデオ入力インターフェース８０とオーディオ入力インターフェース８２と多重化ストリーム出力インターフェース８４とプログラム特定情報テーブル８８とを備える。ストリーム管理ユニット６０は、ＮＡＬユニットコンストラクタ６２とＰＭＴコンストラクタ６４とストリーム識別子（ストリームＩＤ）ルックアップユニット６６とプログラム識別子（ＰＩＤ）割り当てユニット６８とを備える。

図２の例では、ビデオ入力インターフェース８０およびオーディオ入力インターフェース８２は、エンコードされたビデオデータとエンコードされたオーディオデータとからＰＥＳユニットを形成するために各パケタイザーを備える。他の例では、ビデオおよび／またはオーディオパケタイザーは、マルチプレクサ３０の外部に存在しているものとしてよい。図２の例に関して、ビデオ入力インターフェース８０は、ビデオエンコーダ２８から受信されたエンコードされたビデオデータからＰＥＳパケットを形成することができ、オーディオ入力インターフェース８２は、オーディオエンコーダ２６から受信されたエンコードされたオーディオデータからＰＥＳパケットを形成することができる。

ストリーム管理ユニット６０は、ビデオ入力インターフェース８０とオーディオ入力インターフェース８２とからＰＥＳパケットを受信する。それぞれのＰＥＳパケットは、ＰＥＳパケットが属すエレメンタリストリームを識別するストリームＩＤを含む。ストリームＩＤルックアップユニット６６は、プログラム特定情報テーブル８８にクエリを実行することによってＰＥＳパケットが対応するプログラムを判定することができる。すなわち、ストリームＩＤルックアップユニット６６は、受信されたＰＥＳパケットがどのプログラムに対応するかを判定することができるということである。それぞれのプログラムは、複数のエレメンタリストリームを備えることができるが、一般に、１つのエレメンタリストリームはただ１つのプログラムに対応する。しかし、いくつかの例では、エレメンタリストリームは、複数のプログラムに含まれ得る。さまざまなサービスがそれぞれ利用可能なオーディオおよびビデオストリームのさまざまな部分集合を含むことができるので、それぞれのＰＥＳパケットはマルチプレクサ３０から出力された複数のストリームに含まれ得る。したがって、ストリームＩＤルックアップユニット６６は、ＰＥＳパケットが１つまたは複数の出力ストリーム（例えば、１つまたは複数のトランスポートまたはプログラムストリーム）に含まれていなければならないかどうか、特にＰＥＳパケットを出力ストリームのうちのどれに含めるかを決定することができる。

一例では、それぞれのエレメンタリストリームは１つのプログラムに対応する。マルチプレクサ３０は、それぞれのエレメンタリストリームが特定のプログラムに、したがってプログラムＩＤ（ＰＩＤ）に関連付けられていることを確認する役割を持つ。マルチプレクサ３０によって認識されないストリームＩＤ（例えば、プログラム特定情報テーブル８８に格納されていないストリームＩＤ）を含むＰＥＳパケットが受信された場合、ＰＩＤ割り当てユニット６８は、新規ストリームＩＤを未使用のＰＩＤに関連付けるためにプログラム特定情報テーブル８８内に１つまたは複数の新規エントリを作成する。

ＰＥＳパケットが対応するプログラムを決定した後、ＮＡＬユニットコンストラクタ６２は、例えば、ＰＥＳパケットのストリームＩＤが対応するプログラムのＰＩＤを含む、ＮＡＬユニットヘッダでＰＥＳパケットをカプセル化することによって、ＰＥＳパケットを備えるＮＡＬユニットを形成する。いくつかの例では、ＮＡＬユニットコンストラクタ６２、またはストリーム管理ユニット６０の別のサブユニットが、複数のＮＡＬユニットを備えるアクセスユニットを形成することができる。

ＰＭＴコンストラクタ６４は、プログラム特定情報テーブル８８からの情報を使用してマルチプレクサ３０の対応する出力ストリームに対するプログラムマップテーブル（ＰＭＴ）を作成する。別の例では、ストリーム管理ユニット６０は、マルチプレクサ３０によって出力されたプログラムストリームに対するプログラムストリームマップを作成するためのＰＳＭコンストラクタを備えることができる。いくつかの例では、マルチプレクサ３０は、ＰＭＴコンストラクタ６４とＰＳＭコンストラクタの両方を備え、トランスポートストリームとプログラムストリームのいずれかまたは両方を出力することができる。図２の例では、ＰＭＴコンストラクタ６４は、本開示によって規定されている記述子、例えば、ＭＶＣエンハンスメント記述子（enhancement descriptor）と階層記述子、さらにはＰＭＴに対する他の必要な記述子とＰＭＴデータを含む、ＰＭＴを構成することができる。ＰＭＴコンストラクタ６４は、定期的に、例えば、一定期間後または一定量のデータが送信された後、トランスポートストリームに対する後続のＰＭＴを送ることができる。ＰＭＴコンストラクタ６４は、例えば、対応するＰＩＤを含む、対応するＮＡＬユニットヘッダでＰＭＴをカプセル化することによって、ＰＭＴを備えるＮＡＬユニットを形成するために作成されたＰＭＴをＮＡＬユニットコンストラクタ６２に受け渡すことができる。

多重化ストリーム出力インターフェース８４は、ストリーム管理ユニット６０から１つまたは複数のＮＡＬユニットおよび／またはアクセスユニット、例えば、ＰＥＳパケット（例えば、オーディオもしくはビデオデータ）を備えるＮＡＬユニットおよび／またはＰＭＴを備えるＮＡＬユニットを受信することができる。いくつかの例では、多重化ストリーム出力インターフェース８４は、ストリーム管理ユニット６０からＮＡＬユニットが受信された後、共通の時間位置に対応する１つまたは複数のＮＡＬユニットからアクセスユニットを形成することができる。多重化ストリーム出力インターフェース８４は、対応するトランスポートストリームまたはプログラムストリームで出力としてＮＡＬユニットまたはアクセスユニットを送信する。

図３は、例示的な一組のプログラム特定情報テーブル８８を示すブロック図である。トランスポートパケットが属すエレメンタリストリームは、トランスポートパケットのＰＩＤ値に基づいて決定され得る。デコーダが受信されたデータを適切にデコードするために、デコーダはどのエレメンタリストリームがそれぞれのプログラムに対応するのかを決定することができる必要がある。プログラム特定情報テーブル８８に含まれるようなプログラム特定情報は、プログラムとコンポーネントエレメンタリストリームとの間の関係を明示的に指定することができる。図３の例では、プログラム特定情報テーブル８８は、ネットワーク情報テーブル１００と条件付きアクセステーブル１０２とプログラムアクセステーブル１０４とプログラムマップテーブル１０６とを含む。図３の例については、出力ストリームがＭＰＥＧ−２トランスポートストリームを備えることが仮定される。代替的な例において、出力ストリームはプログラムストリームを備えることができ、その場合、プログラムマップテーブル１０６はプログラムストリームマップで置き換えられ得る。

ＭＰＥＧ−２システム仕様書では、トランスポートストリームで伝送されるすべてのプログラムは、それに関連付けられている、プログラムマップテーブル１０６などのプログラムマップケーブルを有することを指定している。プログラムマップテーブル１０６は、プログラムとプログラムが含むエレメンタリストリームに関する詳細を含むことができる。一例として、プログラム番号３で識別されるプログラムは、ＰＩＤ ３３を持つビデオエレメンタリストリームとＰＩＤ ５７を持つ英語オーディオストリームとＰＩＤ ６０を持つ中国語オーディオストリームとを含むことができる。ＰＭＴが複数のプログラムを含むことは許容される。

ＭＰＥＧ−２システム仕様書によって指定されている基本プログラムマップテーブルは、ＭＰＥＧ−２システム仕様の範囲内で指定されている、多くの記述子のうちのいくつかの記述子、例えば、記述子１０８で修飾することができる。記述子１０８は、ＭＰＥＧ−２システム仕様の指定された記述子のどれか、または全部を含むことができる。一般に、記述子１０８などの記述子は、プログラムまたはそのコンポーネントエレメンタリストリームに関するさらなる情報を伝達するものである。これらの記述子は、ビデオエンコードパラメータ、オーディオエンコードパラメータ、言語識別、パンアンドスキャン情報、条件付きアクセス詳細、著作権情報、または他のそのような情報を含み得る。放送局または他のユーザーが、追加のプライベート記述子を定義することができる。

一実施形態によれば、不連続のビュー順序インデックスがトランスポートストリームまたはプログラムストリームなどの出力ストリームで伝送できるようにするため、２つの記述子が使用され得る。図２に示されているように、本開示の２つの記述子は、ＭＶＣ拡張記述子１１０と階層記述子１１２とを含む。ビデオ関係コンポーネントエレメンタリストリームには、階層符号化されたビデオ、オーディオ、およびプライベートストリームのコンポーネントを含むプログラムエレメントを識別するための情報を提供する、階層記述子もある。

マルチプレクサ３０の出力がプログラムストリームを備える例では、プログラム特定情報テーブル８８がプログラムストリームマップ（ＰＳＭ）を格納することができる。ＰＳＭは、対応するプログラムストリーム内のエレメンタリストリームとエレメンタリストリーム同士の間の関係の記述を提供することができる。いくつかの例では、プログラムストリームマップは、トランスポートストリームにも対応することができる。対応するトランスポートストリームで伝送される場合、ＰＳＭ構造体は修正してはならない。マルチプレクサ３０は、ＰＳＭがＰＥＳパケット内に存在することを、ＰＥＳパケットのｓｔｒｅａｍ＿ｉｄ値を、２進数値１０１１１１００、または１０進数値１８８に対応する、０ｘＢＣ、つまり、１６進数値ＢＣに設定することによって指示することができる。

マルチプレクサ３０は、プログラム関連付けテーブル１０４内にトランスポートストリームにおいて利用可能なすべてのプログラムの完全なリストを保持する。マルチプレクサ３０は、ＮＡＬユニット内にプログラム関連付けテーブルを埋め込むこともできる。マルチプレクサ３０は、ＮＡＬユニットがプログラム関連付けテーブルを含むことを、ＮＡＬユニットを０のＰＩＤ値に割り当てることによって指示することができる。マルチプレクサ３０は、プログラム関連付けテーブル１０４内に、対応するプログラムマップテーブルを格納するトランスポートパケットのＰＩＤ値とともに、それぞれのプログラムをリストすることができる。上述の同じ例を使用すると、プログラム番号３のエレメンタリストリームを指定する例示的なプログラムマップテーブルは１００１のＰＩＤを有し、別のＰＭＴは１００２の別のＰＩＤを有する。この情報の集合は、プログラム関連付けテーブル１０４内に収めることができる。

ネットワーク情報テーブル（ＮＩＴ）および条件付きアクセステーブル（ＣＡＴ）：ＰＡＴで指定された、プログラム番号０は特別な意味を持つ。特に、プログラム番号０は、ネットワーク情報テーブルへの道筋を示すために使用される。テーブルはオプションであり、存在する場合、チャネル周波数、衛星トランスポンダの詳細、変調特性、サービスオリジネーター（service originator）、サービス名、および利用可能な代替的ネットワークの詳細などのトランスポートストリームを伝送する物理的ネットワークに関する情報を提供することが意図されている。

トランスポートストリーム内のエレメンタリストリームがスクランブルされる場合、条件付きアクセステーブルが存在していなければならない。このテーブルは、使用中のスクランブリングシステム（複数可）の詳細を示し、また条件付きアクセス管理および権利情報を格納しているトランスポートパケットのＰＩＤ値を示す。この情報のフォーマットは、ＭＰＥＧ−２の範囲内では指定されていない。

図４は、ＭＶＣ拡張記述子１１０に含まれ得る例示的な一組のデータを示すブロック図である。図４の例では、ＭＶＣ拡張記述子１１０は、記述子タグフィールド１２０と記述子長フィールド１２２と平均ビットレートフィールド１２４と最大ビットレートフィールド１２６と予約済みフィールド１２８と時間識別子（ＩＤ）開始フィールド１３０と時間ＩＤ終了フィールド１３２と付加拡張情報（ＳＥＩ）ＮＡＬユニット非存在フィード１３４と１つまたは複数のビュー順序インデックスフィールド１３６と１つまたは複数の予約トレーリングビットフィールド１３８とを備える。ＭＶＣ拡張記述子１１０は、ＭＶＣサブビットストリームに対応する、動作ポイントも指定する。以下のＭＶＣ拡張記述子１１０のフィールドのビット深度は、ＭＶＣ拡張記述子の１つの例に対応している。他の例は、他のビット深度、値、または範囲を含み、対応するビットストリームまたはサブビットストリームに含まれるそれぞれのビューのそれぞれのビュー順序インデックスを信号により個別に伝達することができる。

記述子タグフィールド１２０は、記述子を特に識別するためにＭＰＥＧ−２システム規格によって規定されているようなすべての記述子に含まれる８ビット記述子タグフィールドに対応する。ＭＰＥＧ−２システム規格では、いくつかの記述子タグを定義し、記述子タグ値、例えば、値３６から６３に「予約済み」のマークを付ける。本開示の技術では、ＭＰＥＧ−２システム仕様書において指定されているような予約済み記述子タグのうちの１つに対応するＭＶＣ拡張記述子１１０から「４９」に対する記述子タグフィールド１２０の値を設定することを提案している。

記述子長フィールド１２２は、ＭＰＥＧ−２システム規格によって規定されているようなすべての記述子にも含まれる８ビット記述子長フィールドに対応する。マルチプレクサ３０は、記述子長フィールド１２２の値を記述子長フィールド１２２の直後のＭＶＣ拡張記述子１１０のバイトの個数に等しくなるように設定することができる。ＭＶＣ拡張記述子１１０は、例えば、ＭＶＣ拡張記述子１１０の特定のインスタンスに含まれるビュー順序インデックス１３６の数に基づき可変長を備えることができるため、マルチプレクサ３０は、ＭＶＣ拡張記述子１１０のインスタンスのサイズを計算し、しかるべく記述子のインスタンスの記述子長フィールド１２２の値を指定する。

平均ビットレートフィールド１２４は、再アセンブルされたＡＶＣビデオストリームの、毎秒キロビットを単位とする、平均ビットレートを示す１６ビットフィールドを備える。つまり、平均ビットレートフィールド１２４は、ＭＶＣ拡張記述子１１０が対応するトランスポートストリームまたはプログラムストリームの構成要素である部分からビデオストリームがアセンブルされたときのビデオストリームの平均ビットレートを記述する。いくつかの例では、マルチプレクサ３０は、平均ビットレートフィールド１２４の値をゼロに設定し、平均ビットレートがＭＶＣ拡張記述子１１０によって指示されていないことを示す。

最大ビットレートフィールド１２６は、再アセンブルされたＡＶＣビデオストリームの、毎秒キロビットを単位とする、最大ビットレートを示す１６ビットフィールドを備える。つまり、最大ビットレートフィールド１２６は、ＭＶＣ拡張記述子１１０が対応するトランスポートストリームまたはプログラムストリームの構成要素である部分からビデオストリームがアセンブルされたときのビデオストリームの最大ビットレートを記述する。いくつかの例では、マルチプレクサ３０は、最大ビットレートフィールド１２６の値をゼロに設定し、最大ビットレートがＭＶＣ拡張記述子１１０によって指示されていないことを示す。

時間ＩＤ開始フィールド１３０は、関連付けられているＭＶＣビデオサブビットストリーム内に含まれるすべてのＮＡＬユニットのＮＡＬユニットヘッダ構文エレメントのｔｅｍｐｏｒａｌ＿ｉｄの最小値を示す３ビットフィールドを備える。つまり、時間ＩＤ値は、それぞれのＮＡＬユニットに対するヘッダ内に含まれる。一般に、時間ＩＤ値は特定のフレームレートに対応し、比較的大きな時間ＩＤ値はより高いフレームレートに対応している。例えば、時間ＩＤに対する「０」の値は、毎秒１５フレーム（ｆｐｓ）のフレームレートに対応し、時間ＩＤに対する「１」の値は、３０ｆｐｓのフレームレートに対応し得る。この方法で、１５ｆｐｓのフレームレートを有するビデオセグメントを形成するために、この例では０の時間ＩＤを有するすべてのピクチャーを集めて１つの集合にすることが使用されるが、３０ｆｐｓのフレームレートを有する異なるビデオセグメントを形成するために、０の時間ＩＤを有するすべてのピクチャーと１の時間ＩＤを有するすべてのピクチャーを集めて異なる１つの集合にすることが使用され得る。マルチプレクサ３０は、ＭＶＣビデオサブビットストリームのＮＡＬユニットのすべての最小の時間ＩＤを決定し、時間ＩＤ開始フィールド１３０の値をこの決定された最小の時間ＩＤ値に等しくなるように設定する。

時間ＩＤ終了フィールド１３２は、関連付けられているＭＶＣビデオサブビットストリーム内に含まれるすべてのＮＡＬユニットのＮＡＬユニットヘッダ構文エレメントの時間ＩＤの最大値を示す３ビットフィールドを備える。したがって、マルチプレクサ３０は、ＭＶＣビデオサブビットストリームのＮＡＬユニットのすべての最大の時間ＩＤを決定し、時間ＩＤ開始フィールド１３０の値をこの決定された最大の時間ＩＤ値に等しくなるように設定する。

ＳＥＩ ＮＡＬユニット非存在フィールド１３４は、「１」に設定されているときに、付加拡張情報ＮＡＬユニットが関連付けられているビデオサブビットストリーム内に存在していないことを示す１ビットフラグを備えている。マルチプレクサ３０は、１つまたは複数の付加拡張情報ＮＡＬユニットがストリームの中に配置されているかどうかを判定し、ＳＥＩ ＮＡＬユニットがビットストリーム内にないときにＳＥＩ ＮＡＬユニット非存在フィールド１３４の値を値「１」に設定することができるが、少なくとも１つのＳＥＩ ＮＡＬユニットがビットストリーム内に存在しているときにはＳＥＩ ＮＡＬユニット非存在フィールド１３４の値を「０」の値に設定することができる。

一態様では、本開示の技術では、以下の表１に示されているようなループを使用して表される、１つまたは複数のビュー順序インデックスフィールド１３６を含むように従来のＭＶＣ拡張記述子を修正することを説明している。ビュー順序インデックスフィールド１３６のそれぞれ１つのフィールドは、関連付けられているＭＶＣビデオサブビットストリーム内に含まれるＮＡＬユニットのうちの対応する１つのＮＡＬユニットのビュー順序インデックスの値を示す１０ビットフィールドを備える。マルチプレクサ３０は、ＭＶＣビデオサブビットストリームに含まれるビューのビュー順序インデックスに応じてビュー順序インデックスフィールド１３６の値を設定することができる。さらに、ビュー順序インデックスフィールド１３６の値は、昇順で信号により伝達され得る。この方法で、ＭＶＣ拡張記述子１１０は、ＭＶＣビデオサブビットストリームに含まれるビューの不連続のビュー順序インデックスを記述することができる。

図４の例では、ＭＶＣ拡張記述子１１０は、予約済みトレーリングビットフィールド１３８も備える。本開示では、これらの値が必ず使用されるべき方法を指定することなく将来の目的のためにこれらのビットを予約することを説明している。さまざまな例において、予約済みトレーリングビットは、ＭＶＣ拡張記述子１１０のビットの単一の連続する予約済みセグメントとして、または複数の個別ビットにわたるループとして表され得る。

以下の表１では、本開示のＭＶＣ拡張記述子１１０の構文エレメントを説明している。表１は、構文エレメント毎に、構文エレメントを表すために使用されるビットの数と構文エレメントに対する型を示すニーモニックも説明している。このビットの数は、ＭＶＣ拡張記述子１１０が符号化ビットストリームで送信されるときに対応する構文エレメントに割り当てられるビットの数に対応している。ニーモニックは、符号化ビットストリーム内で使用される異なるデータ型を記述するためにＭＰＥＧ−２システム規格において使用される。本開示で使用されるニーモニックとしては、ＭＰＥＧ−２システム規格において最上位ビットを先頭にした符号なし整数として定義される「ｕｉｍｓｂｆ」およびＭＰＥＧ−２システム規格において左ビットを先頭にしたビット列として定義される「ｂｓｌｂｆ」があるが、ただし、「左」はＭＰＥＧ−２システム規格においてビット列が書かれる順序で左である。表１の例における構文エレメントのそれぞれは、ＭＶＣ拡張記述子１１０に関して説明されている構文エレメントのうちの各１つの構文エレメントに対応する。特に、本開示では、プログラムストリームまたはトランスポートストリームのそれぞれのビューに対するビュー順序インデックスを特に信号により伝達するため表１の「ｆｏｒ」ループを用意している。この方法で、表１のＭＶＣ拡張記述子内の「ｆｏｒ」ループは、対応するＭＰＥＧ−２システム規格のビットストリームが第１のビュー順序インデックスに関連付けられているシーンの第１のビューと第２のビュー順序インデックスに関連付けられているシーンの第２のビューとを備え、第１のビュー順序インデックスおよび第２のビュー順序インデックスが不連続であることを信号により伝達するために使用され得る。

別の例では、予約済みトレーリングビットが、代わりに、個別に信号により伝達され得る。以下の表２は、予約済みトレーリングビットのそれぞれを個別に信号により伝達する例示的なＭＶＣ拡張記述子を示している。

図５は、階層記述子１１２に含まれ得る例示的な一組のデータを示すブロック図である。図５の例では、階層記述子１１２は、記述子タグフィールド１５０と、記述子長フィールド１５２と、ビューエンハンスメントフラグフィールド１５４と、時間スケーラビリティフラグフィールド１５６と、空間スケーラビリティフラグフィールド１５８と、品質スケーラビリティフラグフィールド１６０と、階層タイプフィールド１６２と、予約済みフィールド１６４と、階層層インデックスフィールド１６６と、ＴＲＥＦ存在フラグフィールド１６８と、予約済みフィールド１７０と、階層埋め込み層インデックスフィールド１７２と、予約済みフィールド１７４と、階層チャネルフィールド１７６とを含む。信号伝達、ビュースケーラビリティおよび／またはビュー依存関係を改善するために、本開示の技術は、関連付けられているプログラムエレメントがｈｉｅｒａｒｃｈｙ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘによって参照されているプログラムエレメントの結果として得られるビットストリームのビューの数を増やすかどうかを示す１つのフラグが、階層記述子において信号により伝達されることを提供することができる。

上記のように、ＭＰＥＧ−２システム仕様書では、それぞれの記述子が記述子タグフィールドと記述子長フィールドとを含むことを指定している。したがって、階層記述子１１２は、記述子タグフィールド１５０と記述子長フィールド１５２とを含む。ＭＰＥＧ−２システム仕様によれば、マルチプレクサ３０は、階層記述子１１２について記述子タグフィールド１５０の値を「４」の値に設定することができる。

階層記述子１１２のそれぞれのインスタンスは同じ量のデータを含んでいなければならないため、階層記述子１１２の長さはアプリオリに決定され得る。一例では、以下の表３に関して、マルチプレクサ３０は、記述子長フィールド１５２の値を、記述子長フィールド１５２の末尾の後の階層記述子１１２のインスタンス内のビットの数を示す３２という値に設定することができる。

本開示の技術では、ビューエンハンスメントフラグフィールド１５４を従来の階層記述子に追加することを提案している。本開示の技術によれば、ビューエンハンスメントフラグフィールド１５４は、「０」に設定された場合に関連付けられているプログラムエレメントが階層埋め込み層インデックスによって参照されているプログラムエレメントから結果として得られるビットストリームのビューの数を増やすことを示す１ビットフラグを備えることができる。本開示の技術では、ビューエンハンスメントフラグフィールド１５４に対して「１」の値を予約することも提案する。

階層タイプフィールド１６２は、関連付けられている階層層とその階層埋め込み層との間の階層関係を記述する。一例では、マルチプレクサ３０は、例えば以下の表４で説明されているような階層関係に基づき階層タイプフィールド１６２の値を設定する。一例として、スケーラビリティが複数の次元において適用される場合、マルチプレクサ３０は、階層タイプフィールド１６２を「８」の値（表４に示されているような「組み合わせスケーラビリティ」）に設定することができ、マルチプレクサ３０は、各ストリームのＰＥＳパケットおよびＰＥＳパケットヘッダから取り出されたデータに応じて時間スケーラビリティフラグフィールド１５６と空間スケーラビリティフラグフィールド１５８と品質スケーラビリティフラグフィールド１６０の値を設定する。一般に、マルチプレクサ３０は、さまざまなビューおよび／またはオーディオデータストリームに応じて異なるストリーム間の依存関係を判定することができる。マルチプレクサ３０は、エンハンスメント層を備える依存ストリームが空間層であるか、信号対雑音比（ＳＮＲ）エンハンスメント層であるか、品質エンハンスメント層であるか、または別のタイプのエンハンスメント層であるかを判定することもできる。

別の例として、ＭＶＣビデオサブビットストリームについては、マルチプレクサ３０は、階層タイプフィールド１６２を「９」の値（表４に示されているような「ＭＶＣ」）に設定することができ、またスケーラビリティフラグフィールド１５６と空間スケーラビリティフラグフィールド１５８と品質スケーラビリティフラグフィールド１６０のそれぞれの値を「１」に設定することができる。さらに別の例として、ＭＶＣベースビューサブビットストリームについては、マルチプレクサ３０は、階層タイプフィールド１６２の値を「１５」の値に設定することができ、またスケーラビリティフラグフィールド１５６と空間スケーラビリティフラグフィールド１５８と品質スケーラビリティフラグフィールド１６０の値を「１」に設定することができる。さらに別の例として、プレフィックスＭＶＣサブビットストリームについては、マルチプレクサ３０は、階層タイプフィールド１６２を「１４」の値に設定することができ、またスケーラビリティフラグフィールド１５６と空間スケーラビリティフラグフィールド１５８と品質スケーラビリティフラグフィールド１６０を「１」に設定することができる。

階層層インデックスフィールド１６６は、符号化層階層のテーブル内の関連付けられているプログラムエレメントの一意的なインデックスを定義する６ビットフィールドを備えることができる。インデックスは、単一のプログラム定義の範囲内では一意であることができる。ＩＴＵ−Ｔ Ｒｅｃ． Ｈ．２６４｜ＩＳＯ／ＩＥＣ １４４９６−１０の付録Ｇで定義されている１つまたは複数のプロファイルに適合するＡＶＣビデオストリームのビデオサブビットストリームについては、これは、同じアクセスユニットのビデオサブビットストリームの関連付けられているＳＶＣ依存関係表現がｈｉｅｒａｒｃｈｙ＿ｌａｙｅｒ＿ｉｎｄｅｘの昇順で再アセンブルされる場合にビットストリーム順序が正しいものとなるように割り当てられている、プログラムエレメントインデックスである。ＩＴＵ−Ｔ Ｒｅｃ． Ｈ．２６４｜ＩＳＯ／ＩＥＣ １４４９６−１０の付録Ｈで定義されている１つまたは複数のプロファイルに適合するＡＶＣビデオストリームのＭＶＣビデオサブビットストリームについては、これは、これらの値のどれかがプレフィックスＭＶＣサブビットストリームに対する階層記述子において指定されているｈｉｅｒａｒｃｈｙ＿ｌａｙｅｒ＿ｉｎｄｅｘ値より大きいものとなるように割り当てられている、プログラムエレメントインデックスである。

階層埋め込み層インデックスフィールド１７２は、階層記述子１１２の対応するインスタンスに関連付けられているエレメンタリストリームのデコード前にアクセスされる必要のあるプログラムエレメントの階層テーブルインデックスを定義する６ビットフィールドを備えることができる。本開示では、階層埋め込み層インデックスフィールド１７２に対する値を、階層タイプフィールド１６２が１５の値（つまり、ベース層に対応する値）を有する場合に対して未定義のままにしておく。

階層チャネルフィールド１７６は、順序付けられた一組の送信チャネルにおける関連付けられているプログラムエレメントに対する意図されたチャネル数を示す６ビットフィールドを備えることができる。最もロバストな送信チャネルは、全体的な送信階層定義に関して、階層チャネルフィールド１７６の最低値によって定義される。与えられた階層チャネルは同時に複数のプログラムエレメントに割り当てられる可能性のあることに留意されたい。

予約済みフィールド１６４、１７０、および１７４は、将来の規格策定により将来使用するために予約されている。本開示の技術は、この時点では、セマンティクス上の意味を予約済みフィールド１６４、１７０、および１７４の値に割り当てることを提案していない。

タイムスタンプ参照（ＴＲＥＦ）存在フラグフィールド１６８は、ＴＲＥＦフィールドが対応するＰＥＳパケットヘッダ内に存在しているかどうかを示す１ビットフィールドである。ＰＥＳパケット内のＴＲＥＦフィールドは、３つの個別フィールドに符号化された３３ビット数である。ＴＲＥＦフィールドは、対応するエレメンタリストリームｎ内の同じｊ番目のアクセスユニットのＰＥＳヘッダのＰＴＳによる、ＤＴＳによって示されるようなシステムターゲットデコーダ内の、またはＤＴＳが存在しない場合の、デコード時間値を示す。

以下の表３では、本開示の階層記述子１１２の構文エレメントを説明している。表３には、構文エレメント毎に、構文エレメントを表すために使用されるビットの数と構文エレメントに対する型を示すニーモニックも掲載している。このビットの数は、階層記述子１１２が符号化ビットストリームで送信されるときに対応する構文エレメントに割り当てられるビットの数に対応している。ニーモニックは、符号化ビットストリーム内で使用される異なるデータ型を記述するためにＭＰＥＧ−２システム規格において使用される。本開示で使用されるニーモニックとしては、ＭＰＥＧ−２システム規格において最上位ビットを先頭にした符号なし整数として定義される「ｕｉｍｓｂｆ」およびＭＰＥＧ−２システム規格において左ビットを先頭にしたビット列として定義される「ｂｓｌｂｆ」があるが、ただし、「左」はＭＰＥＧ−２システム規格においてビット列が書かれる順序で左である。表３の例における構文エレメントのそれぞれは、階層記述子１１２に関して説明されている構文エレメントのうちの各１つの構文エレメントに対応する。

以下の表４は、階層記述子１１２の階層タイプフィールド１６２に対するさまざまな潜在的な値、さらにはそれぞれの値に対する意味も説明している。本開示では、対応するビットストリームの記述として「プレフィックスＭＶＣサブビットストリーム」の説明を備える、階層タイプフィールド１６２に対して「１４」の潜在的な値を追加することを提案する。本開示の技術では、ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ（つまり、ＮＡＬユニットの型値）が２０に等しいすべてのプレフィックスＮＡＬユニットとＭＶＣのＡＶＣビデオサブビットストリームで再アセンブルされた後に、ＩＴＵ−Ｔ Ｒｅｃ． Ｈ．２６４｜ＩＳＯ／ＩＥＣ １４４９６−１０の付録Ｈにおいて定義されている１つまたは複数のプロファイルに適合する関連付けられている非ＶＣＬ ＮＡＬユニットとを備えるようにプレフィックスＭＶＣサブビットストリームを定義する。本開示の技術では、ＭＶＣのＡＶＣビデオサブビットストリームが存在しているときに、プレフィックスＭＶＣサブビットストリームも存在するものとすることも提案する。

いくつかの例では、階層記述子１１２は、インクリメンタルサブビットストリーム（incremental sub-bitstream）と埋め込みサブビットストリームとによって信号により伝達されるＭＶＣサブビットストリームを信号により伝達するために使用され得る。埋め込みサブビットストリームは、ｈｉｅｒａｒｃｈｙ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘに対応する直接的従属サブビットストリームとこの直接的従属サブビットストリームのすべての埋め込みサブビットストリームとを含む。本開示では、明示的に含まれるビューは、エンハンスビューと称され、埋め込まれているビューは、従属ビューと称される。

図６は、例示的なＭＶＣ予測パターンを示す概念図である。図６の例では、８つのビュー（「Ｓ０」から「Ｓ７」までのビューＩＤを有する）が示され、１２個の時間位置（「Ｔ０」から「Ｔ１１」まで）がそれぞれのビューについて示されている。つまり、図６内のそれぞれの行は１つのビューに対応し、それぞれの列は時間位置を示す。

ＭＶＣは、Ｈ．２６４／ＡＶＣによってデコード可能ないわゆるベースビューを有し、立体視ビューペアは、ＭＶＣによってもサポートされ得るが、ＭＶＣの利点は、２つより多いビューを３Ｄビデオ入力として使用し、複数のビューによって表現されるこの３Ｄビデオをデコードする例をサポートすることが可能であるという点である。ＭＶＣデコーダを有するクライアントのレンダラーは、複数のビューを含む３Ｄビデオコンテンツを予期し得る。

図６のフレームは、文字を含む陰影付きブロックを使用して図６内のそれぞれの行およびそれぞれの列の指示のところに示されており、対応するフレームがイントラ符号化されているか（つまり、Ｉフレーム）、または一方向に（つまり、Ｐフレームとして）もしくは複数の方向に（つまり、Ｂフレームとして）インター符号化されているかを指定する。一般に、予測は矢印で示され、指示先のフレームは予測参照に指示元のオブジェクトを使用する。例えば、時間位置Ｔ０のビューＳ２のＰフレームは、時間位置Ｔ０のビューＳ０のＩフレームから予測される。

単一ビュービデオエンコードと同様に、マルチビュービデオ符号化ビデオシーケンスのフレームは、異なる時間位置にあるフレームに関して予測的にエンコードされ得る。例えば、時間位置Ｔ１のビューＳ０のｂフレームは、時間位置Ｔ０のビューＳ０のＩフレームからそれを指す矢印を有し、ｂフレームがＩフレームから予測されることを示す。しかし、それに加えて、マルチビュービデオエンコードに関連して、フレームはビュー間予測され得る。つまり、ビューコンポーネントは、参照のため他のビュー内のビューコンポーネントを使用することができる。例えば、ＭＶＣでは、ビュー間予測は、別のビュー内のビューコンポーネントがインター予測参照であるかのように実現される。潜在的なビュー間参照は、シーケンスパラメータセット（ＳＰＳ）ＭＶＣ拡張で信号により伝達され、インター予測またはビュー間予測参照の柔軟な順序付けを可能にする、参照ピクチャーリスト構成プロセスによって修正され得る。以下の表５は、ＭＶＣ拡張シーケンスパラメータセットに対する例示的な定義をまとめたものである。

図６は、ビュー間予測のさまざまな例を掲載している。図６の例における、ビューＳ１のフレームは、ビューＳ１の異なる時間位置におけるフレームから予測されるだけでなく、同じ時間位置におけるビューＳ０とＳ２の複数のフレームのうちのいくつかのフレームからビュー間予測されるものとして示されている。例えば、時間位置Ｔ１におけるビューＳ１のｂフレームは、時間位置Ｔ０とＴ２におけるビューＳ１のＢフレームのそれぞれ、さらには時間位置Ｔ１におけるビューＳ０とＳ２のｂフレームから予測される。

図６の例では、大文字「Ｂ」および小文字「ｂ」は、フレーム間の異なる階層関係を示すことが意図されており、異なるエンコード方法を示すことは意図されていない。一般に、大文字「Ｂ」フレームは、小文字「ｂ」フレームに比べて予測階層内で比較的高いレベルにある。図６は、異なるレベルの陰影を使用して予測階層の変動も示しており、陰影が大きい（つまり、比較的暗い）フレームほど、陰影の小さい（つまり、比較的明るい）フレームに比べて予測階層内で高いレベルにある。例えば、図６のすべてのＩフレームは１００％の濃さの陰影で示されているが、Ｐフレームは幾分明るい陰影を有し、Ｂフレーム（および小文字のｂフレーム）は、互いに関してさまざまなレベルの陰影を有するが、ＰフレームとＩフレームの陰影に比べて常に明るい。

一般に、予測階層は、予測階層内で比較的高いフレームが階層内で比較的低いフレームをデコードする前にデコードされなければならないという点で、ビュー順序インデックスに関係しており、階層内で比較的高いフレームが階層内で比較的低いフレームのデコード中に基準フレームとして使用され得る。ビュー順序インデックスは、アクセスユニット内の対応するビューコンポーネントのデコード順序を示すインデックスである。ビュー順序インデックスは、Ｈ．２６４／ＡＶＣ（ＭＶＣ改訂）の付録Ｈで指定されているように、ＳＰＳ ＭＶＣ拡張に暗示されている。ＳＰＳでは、それぞれのインデックスｉについて、対応するｖｉｅｗ＿ｉｄが信号により伝達される。ビューコンポーネントのデコードは、ビュー順序インデックスの昇順に従うものとする。すべてのビューが提示された場合、ビュー順序インデックスは、０からｎｕｍ＿ｖｉｅｗｓ＿ｍｉｎｕｓ＿１までの連続する順序で並ぶ。

この方法で、基準フレームとして使用されるフレームは、基準フレームを参照しつつエンコードされたフレームをデコードする前にデコードされ得る。ビュー順序インデックスは、アクセスユニット内のビューコンポーネントのデコード順序を示すインデックスである。それぞれのビュー順序インデックスｉについて、対応するｖｉｅｗ＿ｉｄが信号により伝達される。ビューコンポーネントのデコードは、ビュー順序インデックスの昇順に従う。すべてのビューが提示された場合、ビュー順序インデックスの集合は、ゼロからビューの全数−１まで連続的に順序付けられた集合を備える。

階層の等しいレベルにおけるいくつかのフレームについて、デコード順序は、互いに関して問題にならないものとすることができる。例えば、時間位置Ｔ０におけるビューＳ０のＩフレームは、時間位置Ｔ０におけるビューＳ２のＰフレームに対する基準フレームとして使用され、次いで、このＰフレームは、時間位置Ｔ０におけるビューＳ４のＰフレームに対する基準フレームとして使用される。したがって、時間位置Ｔ０におけるビューＳ０のＩフレームは、時間位置Ｔ０におけるビューＳ２のＰフレームの前にデコードされなければならず、このＰフレームは、時間位置Ｔ０におけるビューＳ４のＰフレーム前にデコードされなければならない。しかし、ビューＳ１とＳ３との間では、ビューＳ１およびＳ３が予測のために互いに依存し合わず、その代わりに予測階層内で高いビューからのみ予測されるので、デコード順序は問題にならない。さらに、ビューＳ１は、ビューＳ１がビューＳ０とＳ２との後にデコードされる限り、ビューＳ４の前にデコードされることができる。

この方法で、Ｓ０からＳ７までのビューを記述するために、階層順序付けが使用され得る。記法ＳＡ＞ＳＢは、ビューＳＡがビューＳＢの前にデコードされなければならないことを意味するものとする。この表記を使用すると、図６の例では、Ｓ０＞Ｓ２＞Ｓ４＞Ｓ６＞Ｓ７となる。また、図６の例に関して、Ｓ０＞Ｓ１、Ｓ２＞Ｓ１、Ｓ２＞Ｓ３、Ｓ４＞Ｓ３、Ｓ４＞Ｓ５、およびＳ６＞Ｓ５である。これらの要件に反しないビューに対するデコード順序であればどのような順序も可能である。したがって、多くの異なるデコード順序が可能であるが、ただし、いくつかの制限はある。２つの例示的なデコード順序が以下に示されているけれども、多くの他のデコード順序も可能であることは理解されるであろう。以下の表６に示されている一例では、ビューはできる限り早くデコードされる。

表６の例から、ビューＳ１はビューＳ０およびＳ２がデコードされた直後にデコードされ、ビューＳ３はビューＳ２およびＳ４がデコードされた直後にデコードされ、ビューＳ５はビューＳ４およびＳ６がデコードされた直後にデコードされ得ることがわかる。

表７は、デコード順序が別ビューの基準として使用されるビューが他のビューの基準として使用されていないビューの前にデコードされるような順序である、別の例示的なデコード順序を示している。

表７の例からは、ビューＳ１、Ｓ３、Ｓ５、およびＳ７のフレームが他のビューのフレームに対する基準フレームとして働かない、したがって、ビューＳ１、Ｓ３、Ｓ５、およびＳ７は、基準フレームとして使用されるビュー、つまり、図６の例におけるビューＳ０、Ｓ２、Ｓ４、およびＳ６のフレームの後にデコードされることがわかる。互いに関して、ビューＳ１、Ｓ３、Ｓ５、およびＳ７は、任意の順序でデコードされ得る。したがって、表７の例では、ビューＳ７は、ビューＳ１、Ｓ３、およびＳ５のそれぞれの前にデコードされる。

わかりやすくするため、それぞれのビューのフレーム間の階層関係だけでなくそれぞれのビューのフレームの時間位置もあり得る。図６の例に関して、時間位置Ｔ０におけるフレームは、時間位置Ｔ０における他のビューのフレームからイントラ予測またはビュー間予測のいずれかがなされる。同様に、時間位置Ｔ８におけるフレームは、時間位置Ｔ８における他のビューのフレームからイントラ予測またはビュー間予測のいずれかがなされる。したがって、時間的階層に関して、時間位置Ｔ０およびＴ８は、時間階層の最上位にある。

図６の例における時間位置Ｔ４のフレームは、時間位置Ｔ０およびＴ８のフレームより時間階層内で低いが、それは、時間位置Ｔ４のフレームが時間位置Ｔ０およびＴ８のフレームに関してＢエンコードされているからである。時間位置Ｔ２およびＴ６のフレームは、時間位置Ｔ４のフレームより時間階層において低い。最後に、時間位置Ｔ１、Ｔ３、Ｔ５、およびＴ７のフレームは、時間位置Ｔ２およびＴ６のフレームより時間階層において低い。

ＭＶＣでは、ビットストリーム全体の部分集合は、いぜんとしてＭＶＣに適合しているサブビットストリームを形成するように抽出され得る。例えばサーバーによって提供されるサービス、１つまたは複数のクライアントのデコーダの容量とサポートと能力、および／または１つまたは複数のクライアントのユーザープリファレンスに基づき、特定の用途が必要とすると思われるサブビットストリームが多数ある可能性がある。例えば、クライアントは、３つのビューのみを必要とする可能性があり、２つのシナリオがあり得る。一例では、一方のクライアントは、スムーズな視聴体験を要求し、ｖｉｅｗ＿ｉｄ値Ｓ０、Ｓ１、およびＳ２を有するビューを好む可能性があるが、他方のクライアントは、ビュースケーラビリティを要求し、ｖｉｅｗ＿ｉｄ値Ｓ０、Ｓ２、およびＳ４を有するビューを好む可能性がある。元々ｖｉｅｗ＿ｉｄが表６の例に関して順序付けられている場合、ビュー順序インデックス値は、これら２つの例において、それぞれ、｛０，１，２｝および｛０，１，４｝である。これらのサブビットストリームの両方が、独立したＭＶＣビットストリームとしてデコードされ、同時にサポートされ得ることに留意されたい。

図７は、不連続ビュー順序インデックスを持つビューの部分集合を有するＭＰＥＧ−２システムストリームをサーバーからクライアントに送るための例示的な方法を示す流れ図である。図７の方法は、Ａ／Ｖソースデバイス２０とＡ／Ｖデスティネーションデバイス４０とに関して、例を示すことを目的として説明されているが、他の例も図７の方法を実行できることは理解されるであろう。図７の例では、「サーバー」に帰されるアクションは、Ａ／Ｖソースデバイス２０によって実行され得るが、「クライアント」によって実行されるアクションは、Ａ／Ｖデスティネーションデバイス４０によって実行され得る。

図７の例では、Ａ／Ｖソースデバイス２０は、最初に、Ａ／Ｖソースデバイス２０によって提供されるサービスに基づきＡ／Ｖデスティネーションデバイス４０に送るべき利用可能なビューの部分集合を決定する（２００）。上述のように、サービスは、一般的に、ビューの選択を備える。図６の例に関して、サービスは、ビューＳ０、Ｓ２、およびＳ４を備えることができる。これらのビューのビュー順序インデックスが表６に規定されているビュー順序インデックスであると仮定すると、例えば、ビューＳ０、Ｓ２、およびＳ４に対するビュー順序インデックスは、ビュー順序インデックス０、１、および３を備えることができる。図７の方法の残りの説明では、これらのビューＩＤおよびビュー順序インデックスを説明目的のための例として使用する。

次いで、Ａ／Ｖソースデバイス２０は、サービスの提供の一部として送られるように決定されたビューに基づきプログラムマップテーブル（ＰＭＴ）を用意することができる（２０２）。特に、マルチプレクサ３０のＰＭＴコンストラクタ６４は、Ａ／Ｖソースデバイス２０によって提供されるサービスに対応する１つまたは複数のプログラムに対するプログラム特定情報テーブル８８から取り出された情報に基づきＰＭＴを用意することができる。本開示の技術によれば、ＰＭＴの用意は、ＭＶＣ拡張記述子１１０と階層記述子１１２との生成を含む。

ＭＶＣ拡張記述子１１０を生成するために、マルチプレクサ３０のＰＭＴコンストラクタ６４が記述子タグフィールド１２０を「４９」に等しくなるように設定する。ＰＭＴコンストラクタ６４は、平均ビットレートフィールド１２４と最大ビットレートフィールド１２６と時間ＩＤ開始フィールド１３０と時間ＩＤ終了フィールド１３２とＳＥＩ ＮＡＬユニット非存在フィールド１０３４との値を、プログラム特定情報テーブル８８によって格納されているようなプログラムのプログラム特定データに従って設定する。ＰＭＴコンストラクタ６４は、選択されたビューのビュー順序インデックスに応じてビュー順序インデックスフィールド１３６の値も設定する。上で説明されている例では、ＰＭＴコンストラクタ６４は、ビュー順序インデックス０と１と３とを表す３つのビュー順序インデックスフィールド値を含む。この方法では、この例は、プログラムのビューのそれぞれのビュー順序インデックスを個別に示すＭＶＣ拡張記述子を与えるものである。さらに、ビュー順序インデックス「２」がスキップされるため、この例は、ビュー順序インデックスが不連続である例である。

階層記述子１１２を生成するために、ＰＭＴコンストラクタ６４は、プログラム特定情報テーブル８８に応じて階層記述子１１２のフィールドの値を設定する。本開示の技術によれば、ＰＭＴコンストラクタ６４は、ビューエンハンスメントフラグフィールド１５４の値を、関連付けられているプログラムエレメントが階層埋め込み層インデックスフィールド１７２の値によって参照されているプログラムエレメントから結果として得られるビットストリームのビューの数を増やすことを示す「０」の値に設定することもできる。

ＰＭＴを生成した後、Ａ／Ｖソースデバイス２０は、ＰＭＴをＡ／Ｖデスティネーションデバイス４０に、例えば、ＮＡＬユニットの形態で、送信することができる（２０４）。いくつかの例では、Ａ／Ｖソースデバイス２０は、ＰＭＴをＡ／Ｖデスティネーションデバイス４０に、例えば、所定の時間間隔が経過した後、または特定のデータ量が送られた後に、定期的に再送することができる。Ａ／Ｖデスティネーションデバイス４０は、ＰＭＴからのプログラム情報を、マルチプレクサ３０のプログラム特定情報テーブル８８を本質的ミラーリングすることができる、クライアントサイドの記憶媒体内に記録することができる（２０８）。例えば、デマルチプレクサ３８は、マルチプレクサ３０のプログラム特定情報テーブル８８に類似の一組のプログラム特定情報テーブルを備えることができる。送信されたＰＭＴなどの、プログラム特定情報を受信した後、デマルチプレクサ３８がデマルチプレクサ３８のプログラム特定情報テーブルを更新することができる。

次いで、マルチプレクサ３０は、Ａ／Ｖソースデバイス２０によって提供されるサービスに関連付けられている１つまたは複数のプログラムのＰＥＳパケットを受信することができる（２１０）。マルチプレクサ３０は、ＰＥＳパケットのストリームＩＤについてルックアップを実行することによってＡ／Ｖデスティネーションデバイス４０へのトランスポートストリーム内にＰＥＳパケットが含まれるべきであると判定することができる。ＰＥＳパケットのストリームＩＤがトランスポートストリームに含まれるべきビューと一致した場合、マルチプレクサ３０は、例えば、プログラムに対応するプログラムＩＤ（ＰＩＤ）でＰＥＳパケットをカプセル化することによって、ＰＥＳパケットからＮＡＬユニットを形成することができる（２１２）。マルチプレクサ３０は、複数のそのようなＮＡＬユニットからアクセスユニットを形成し（２１４）、アクセスユニットをＡ／Ｖデスティネーションデバイス４０に送ることもできる（２１６）。

次いで、Ａ／Ｖデスティネーションデバイス４０は、例えば、アクセスユニットのＰＩＤを参照することによって、Ａ／Ｖソースデバイス２０からアクセスユニットを受信し（２１８）、アクセスユニットをプログラムに関連付けることができる（２２０）。Ａ／Ｖデスティネーションデバイス４０のデマルチプレクサ３８は、アクセスユニットを構成要素となるいくつかのＮＡＬユニットに、したがって、ＰＥＳパケットに逆多重化し、これをデマルチプレクサ３８が最終的にオーディオデコーダ４６および／またはビデオデコーダ４８に受け渡すことができる。ビデオデコーダ４８は、ビューのそれぞれをデコードし、デコードされたビューを、立体視または裸眼立体視ビデオディスプレイまたは複数のビューを要求する他の表示デバイスを備えることができるビデオ出力４４に送ることができる。同様に、オーディオデコーダ４６はオーディオフレームをデコードしてデコードされたオーディオデータを形成し、そのオーディオデータをオーディオ出力４２、例えば、スピーカーに送ることができる。この方法で、Ａ／Ｖデスティネーションデバイス４０は、受信されたデータをデコードし、表示することができる（２２２）。

図８は、２つまたはそれ以上のサブビットストリームのビューコンポーネントをアセンブルしてビューコンポーネントが大きくなるビュー順序インデックスを有するようにビットストリームを生成するための例示的な方法を示す流れ図である。この方法では、各サブビットストリームとビューコンポーネントのビューＩＤを参照することなくサブビットストリームに順序付けすることができる。図６の例に関して、トランスポートストリーム（またはプログラムストリーム）の第１のビットストリームは、ビューＳ０、Ｓ２、およびＳ４のビューコンポーネントを含み、トランスポートストリームの第２のサブビットストリーム（第１のサブビットストリームの埋め込みサブビットストリームに対応する）は、ビューＳ１およびＳ３のビューコンポーネントを含むと仮定する。本開示では、埋め込みサブビットストリームを「従属サブビットストリーム」と称することもできる。同様に、本開示では、従属サブビットストリームが埋め込まれているサブビットストリームをプライマリサブビットストリームと称することもできる。したがって、図８の第１のサブビットストリームは、プライマリサブビットストリームと称されるが、第２のサブビットストリームは、埋め込みまたは従属サブビットストリームと称され得る。

この例に対するビュー順序インデックスは、表６の例に関して定義されている通りであると仮定すると、第１のサブビットストリーム内のビューコンポーネントのビュー順序インデックスは、（それぞれ）０、１、３であり、第２のサブビットストリームに対するビュー順序インデックスは、２と４である。したがって、この例における第１のビットストリームのビューコンポーネントが、第２のサブビットストリームのビューコンポーネントの前に安全にデコードされたとすれば、ビュー順序インデックスに関するデコード順序は、０、１、３、２、４に対応するであろう。ビュー順序インデックスは、デコード順序を記述すべきであるため、そのようなデコード順序はＭＶＣ仕様の違反となる。したがって、図８の方法は、ビューコンポーネントのデコード順序がＭＶＣ仕様に準拠するように、ビュー順序インデックスに関して、ビューコンポーネントの順序を変更するために使用される。

図８の方法は、一般的に、サブビットストリームをアセンブルするときに、それぞれのアクセスユニット内のビューコンポーネントを含む例示的な方法に対応しており、すべての現在のサブビットストリームと埋め込みサブビットストリームとで伝送されるようなビュー順序インデックスの昇順に従わなければならない。本開示の技術は、ＮＡＬユニットのＮＡＬユニットヘッダ内のｖｉｅｗ＿ｉｄ構文エレメントをチェックしてそれをビュー順序インデックスにマッピングするという作業をすることなく、適合しているＭＶＣサブビットストリームのアセンブルを可能にすることができる。図８の方法は、ＭＶＣ規格に準拠している順序でサブビットストリームのｖｅｗ＿ＩＤに対応するインデックスを備える「階層層インデックスリスト」（ＨＬＩ）と称される、リストを生成するために使用され得る。

最初に、Ａ／Ｖデスティネーションデバイス４０などのクライアントデバイスが、２つのサブビットストリームのビューコンポーネントを有するアクセスユニットを受信する（２５０）。例示することを目的として、第２のサブビットストリームは、第１のサブビットストリームの埋め込みまたは従属サブビットストリームを備えると仮定される。図８の例示的な方法は、２つのサブビットストリームに関して説明されている。しかし、図８の技術は、２つより多いサブビットストリームを有する例にも適用可能である。さらに、図８の方法は、Ａ／Ｖデスティネーションデバイス４０のデマルチプレクサ３８に関して例示し説明することを目的として記述されている。しかし、図８の方法は、ＭＶＣ規格に準拠するように２つまたはそれ以上のサブビットストリームのビューを再編成するために、任意のデバイス、モジュール、ユニット、またはファームウェア、ハードウェア、および／またはソフトウェアの組み合わせによって実行され得ることは理解されるであろう。

それぞれのサブビットストリームのビューコンポーネントは、ＭＶＣ規格に従って順序付けられると仮定される。したがって、デマルチプレクサ３８は、サブビットストリームのどのビューコンポーネントが最小のビュー順序インデックスを有するかを判定する（２５２）。次いで、デマルチプレクサ３８は、ビューコンポーネント（１つまたは複数のＮＡＬユニットを備えることができる）のインデックスをＨＬＩリスト内の次に利用可能な位置に追加することができる（２５４）。いくつかの例では、ビューコンポーネントは、マルチメディアデータを備える１つまたは複数のＮＡＬユニットとともに、別の後続のビューコンポーネントからビューコンポーネントを区別するために使用することができる区切りＮＡＬユニットをも備えることができる。次いで、デマルチプレクサ３８は、第１のサブビットストリームに対してビューコンポーネントが残っているかどうかを判定することができる（２５６）。

第１のサブビットストリームに対してビューコンポーネントが残っている場合（２５６の「ＹＥＳ」ブランチ）、デマルチプレクサ３８が、第２のサブビットストリームに対してもビューコンポーネントが残っているかどうかを判定することができる（２５８）。第１のサブビットストリームと第２のサブビットストリームの両方が少なくとも１つのビューコンポーネントを含む場合（２５８の「ＹＥＳ」ブランチ）、デマルチプレクサ３８は、ステップ２５２に戻り、ビューコンポーネントの最小のビュー順序インデックスを決定し、最小のビューコンポーネントのビューインデックスをＨＬＩリストに追加する。しかし、第１のサブビットストリームに対してのみビューコンポーネントが残っており、第２のサブビットストリームに対しては残っていない場合（２５８の「ＮＯ」ブランチ）、デマルチプレクサ３８は、第１のサブビットストリームの残っているビューコンポーネントをＨＬＩリストに追加することができる（２６０）。

その一方で、第１のサブビットストリームに対してビューコンポーネントが残っていない場合（２５６の「ＮＯ」ブランチ）、デマルチプレクサ３８は、第２のサブビットストリームに対してビューコンポーネントが残っているかどうかを判定することができる（２６２）。第２のサブビットストリームが残っているビューコンポーネントを有している場合、デマルチプレクサ３８は、第２のサブビットストリームの残っているビューコンポーネントをＨＬＩリストに追加することができる（２６４）。

ＨＬＩリストが対応するビュー順序インデックスの順序でビューＩＤを備えた後（例えば、２６２のステップ２６０、２６４、または「ＮＯ」ブランチの完了後）、デマルチプレクサ３８は、ＨＬＩリストに従って決定された順序でサブビットストリームを備える、新しいビットストリームを形成することができる。つまり、新しいビットストリームのアクセスユニットに対して、アクセスユニットが複数のビューコンポーネントを備えている場合、ビューコンポーネントは、ビューコンポーネントのそれぞれのビュー順序インデックスがすべての先行するビュー順序インデックスより大きく、すべての後続のビュー順序インデックスより小さいインデックスとなるように新しいビットストリーム内で順序付けられる。次いで、このビットストリームは、ビューコンポーネントのデコードのために、例えばビデオデコーダ４８に、そして最終的に、ビューコンポーネントのディスプレイに回送され得る。

以下の例示的なアルゴリズムは、ＭＶＣ規格に準拠するようにサブビットストリームを順序付けるための例示的なプロセスを構成する。いくつかの例では、現在のＭＶＣサブビットストリームまたは埋め込みサブビットストリームのいずれかに対応するｈｉｅｒａｒｃｈｙ＿ｌａｙｅｒ＿ｉｎｄｅｘ（ＨＬＩＬｉｓｔ）値のリストがある。上述のように、ビューコンポーネントは、複数のＮＡＬユニットを備えることができる。同様に、いくつかの例では、ビューコンポーネントは、それぞれのビューコンポーネントを別のビューから区別するために、区切りＮＡＬユニットを備えるか、または区切りＮＡＬユニットがその後に続くものとすることができる。

新しいビットストリームをアセンブルするためのプロセスは、以下のように定義することができる：
１）従属サブビットストリームを埋め込みサブビットストリームを有していないサブビットストリームとして設定する。
２）ｈｉｅｒａｒｃｈｙ＿ｌａｙｅｒ＿ｉｎｄｅｘの昇順で、以下が反復的に適用される：
１．ＭＶＣに適合している、ｈｉｅｒａｒｃｈｙ＿ｌａｙｅｒ＿ｉｎｄｅｘがＨＬＩに等しい階層記述子で説明されている、サブビットストリームをアセンブルする：
２．このプロセスは、以下を入力として有する：
ｉ．明示的に存在するエンハンスメントサブビットストリーム；
ｉｉ．従属サブビットストリーム。これはＭＶＣに適合しており、それぞれのアクセスユニット内のビュー順序インデックスの昇順で配置されるビューコンポーネントを有することに留意されたい；
ｉｉｉ．エンハンスメントサブビットストリーム内のビュー順序インデックスのリスト；
ｉｖ．従属サブビットストリーム内のビュー順序インデックスのリスト；
３．このプロセスは、以下を出力として有する。
ｉ．すべてのビューコンポーネントがアセンブルされ、したがってＭＶＣに適合しており、階層記述子で定義されているＨＬＩに対応する完全な動作ポイントを形成する新しいサブビットストリーム；
ｉｉ．新しいサブビットストリーム内のビュー順序インデックスのリスト；
４．ステップ３で生成された新しいサブビットストリームを従属サブビットストリームとして設定する；
５．ＨＬＩがＨＬＩＬｉｓｔのリスト内の最後の１つである場合、その従属サブビットストリームを最終アセンブル済みＭＶＣサブビットストリームとして設定し、アセンブルプロセス全体を終了する。

以下のアルゴリズムは、上記の例示的なアルゴリズムのステップ２で要求されているような、従属サブビットストリームとエンハンスメントサブビットストリームとに基づきサブビットストリームをアセンブルする例示的なプロセスを説明している：
１．アセンブルプロセスの入力は、２つのリストと２つのサブビットストリームであり、それぞれビュー順序インデックスの昇順ですでに順序付けられている。２つのリストのそれぞれは、昇順でビュー順序インデックスを格納しており、２つのリストはＶＯＩｄｘＬｉｓｔＥおよびＶＯＩｄｘＬｉｓｔＤである。２つのサブビットストリームは、従属サブビットストリームとエンハンスサブビットストリームである。新しいリストは、最初は空であるＶＯＩｄｘＬｉｓｔＮｅｗである。
２．アクセスユニット毎に、以下を適用する：
ｉ．ＶＯＩｄｘＥをＶＯＩｄｘＬｉｓｔＥの第１の値として、ＶＯＩｄｘＤをＶＯＩｄｘＬｉｓｔＤの第１の値として設定する；
ｉｉ．ＶＯＩｄｘＥがＶＯＩｄｘＤより小さい場合、エンハンスサブビットストリームから１つのビューコンポーネントをアセンブルし、ＶＯＩｄｘＥをＶＯＩｄｘＬｉｓｔＥ内の次の値に設定し、ＶＯＩｄｘＣｕｒｒはＶＯＩｄｘＥに設定され；そうでない場合、従属サブビットストリームから１つのビューコンポーネントをアセンブルし、ＶＯＩｄｘＤをＶＯＩｄｘＬｉｓｔＤ内の次の値に設定し、ＶＯＩｄｘＣｕｒｒはＶＯＩｄｘＤに設定される。ＶＯＩｄｘＣｕｒｒをＶＯＩｄｘＬｉｓｔＮｅｗに加える。
・サブビットストリームから１つのビューコンポーネントをアセンブルするときに、区切りＮＡＬユニットに遭遇するまでＮＡＬユニットが追加される。
ｉｉｉ．ＶＯＩｄｘＥがＶＯＩｄｘＬｉｓｔＥの末尾になく、ＶＯＩｄｘＤがＶＯＩｄｘＬｉｓｔＤの末尾にない場合、プロセス全体を終了し、そうでない場合、ステップｉｖに進む。
ｉｖ．さもなければＶＯＩｄｘＥがＶＯＩｄｘＬｉｓｔＥの末尾にある場合、従属サブビットストリーム内の残りのすべてのビューコンポーネントをアセンブリし、ＶＯＩｄｘＬｉｓｔＤ内に残っている値すべてをＶＯＩｄｘＬｉｓｔＮｅｗに加え、ＶＯＩｄｘＤをＶＯＩｄｘＬｉｓｔＤの末尾に設定する。
ｖ．さもなければＶＯＩｄｘＤがＶＯＩｄｘＬｉｓｔＤの末尾にある場合、エンハンスサブビットストリーム内の残りのすべてのビューコンポーネントをアセンブルし、ＶＯＩｄｘＬｉｓｔＥ内に残っている値すべてをＶＯＩｄｘＬｉｓｔＮｅｗに加え、ＶＯＩｄｘＥをＶＯＩｄｘＬｉｓｔＥの末尾に設定する。
ｖｉ．さもなければステップｉｉに進む。

１つまたは複数の例において、説明されている関数は、ハードウェア、ソフトウェア、ファームウェア、またはこれらの組み合わせで実装することができる。ソフトウェアで実装された場合、これらの関数は、コンピュータ可読媒体上に１つまたは複数の命令もしくはコードとして格納され得る。コンピュータ可読媒体は、一方の場所から他方の場所へのコンピュータプログラムの転送を容易にする媒体を含むコンピュータデータ記憶媒体または通信媒体を含むことができる。データ記憶媒体は、本開示において説明されている技術の実装のための命令、コード、および／またはデータ構造体を取り出すために、１つもしくは複数のコンピュータまたは１つもしくは複数のプロセッサによってアクセスされ得る利用可能な任意の媒体とすることができる。例えば、限定はしないが、このようなコンピュータ可読媒体としては、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、または他の光ディスク記憶装置、磁気ディスク記憶装置、または他の磁気記憶デバイス、フラッシュメモリ、または命令もしくはデータ構造体の形態で所望のプログラムコードを搬送または格納するために使用することができ、またコンピュータによってアクセスできる他の媒体が挙げられる。本明細書で使用されているような、「Ｄｉｓｋ」と「Ｄｉｓｃ」は、コンパクトディスク（ＣＤ）、レーザーディスク（登録商標）、光ディスク、デジタル多用途ディスク（ＤＶＤ）、フロッピーディスク、およびブルーレイディスクを含み、「Ｄｉｓｋ」は通常磁気的にデータを再現し、「Ｄｉｓｃ」はレーザーを使って光学的にデータを再現する。上記の組み合わせも、コンピュータ可読媒体の範囲に収まらなければならない。

コードは、１つまたは複数のデジタルシグナルプロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルロジックアレイ（ＦＰＧＡ）、または他の同等の集積回路もしくはディスクリート部品による論理回路などの１つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用されているような「プロセッサ」という用語は、前記の構造物または本明細書で説明されている技術の実装に適している他の構造物のいずれかを指すことができる。それに加えて、いくつかの態様では、本明細書で説明されている機能は、エンコードとデコードの処理を行うように構成された専用ハードウェアおよび/またはソフトウェアモジュール内に提供されるか、または組み合わされたコーデックに組み込まれ得る。また、これらの技術は、１つもしくは複数の回路または論理素子で完全に実装することも可能である。

本開示の技術は、ワイヤレスハンドセット、集積回路（ＩＣ）、または一組のＩＣ（例えば、チップセット）を含む、さまざまなデバイスもしくは装置で実装することができる。さまざまなコンポーネント、モジュール、またはユニットは、開示されている技術を実行するように構成されたデバイスの機能面の態様を強調するように本開示において説明されているが、異なるハードウェアユニットによる実現を必ずしも必要としない。むしろ、上で説明されているように、さまざまなユニットが、コーデックハードウェアユニット内に組み合わされるか、または好適なソフトウェアおよび／またはファームウェアと併せて、上述のような１つまたは複数のプロセッサを含む、相互運用性を有するハードウェアユニットの集合体によって構成され得る。

さまざまな例が説明されている。これらおよび他の例は、以下の請求項の範囲内に収まる。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
（１） ビデオビットストリームを生成する方法であって、
クライアントデバイスにより、プライマリサブビットストリームと前記プライマリサブビットストリームの埋め込みサブビットストリームとを備える受信されたビットストリームからマルチビュービデオ符号化（ＭＶＣ）規格準拠のビットストリームを生成することであって、
前記プライマリサブビットストリームのビューコンポーネントが前記埋め込みサブビットストリームのビューコンポーネントのビュー順序インデックスより大きいビュー順序インデックスを有するかどうかを判定することと、
前記プライマリサブビットストリームの前記ビューコンポーネントの前記ビュー順序インデックスが前記埋め込みサブビットストリームの前記ビューコンポーネントの前記ビュー順序インデックスより大きい場合に、前記埋め込みサブビットストリームの前記ビューコンポーネントを前記生成されたビットストリームに追加することと、及び
前記プライマリサブビットストリームの前記ビューコンポーネントの前記ビュー順序インデックスが前記埋め込みサブビットストリームの前記ビューコンポーネントの前記ビュー順序インデックスより大きくない場合に、前記プライマリサブビットストリームの前記ビューコンポーネントを前記生成されたビットストリームに追加することと、
を備える、ＭＶＣ規格準拠のビットストリームを生成することと、及び
前記生成されたビットストリームをビデオデコーダに出力することと、
を備えるビデオビットストリームを生成する方法。
（２） 前記プライマリサブビットストリームに、残っているビューコンポーネントがないことを判定することと、及び
前記埋め込みサブビットストリームの残りのすべてのビューコンポーネントを前記生成されたサブビットストリームに追加することと、
をさらに備える、（１）に記載の方法。
（３） 前記埋め込みサブビットストリームに、残っているビューコンポーネントがないことを判定することと、及び
前記プライマリサブビットストリームの残りのすべてのビューコンポーネントを前記生成されたサブビットストリームに追加することと、
をさらに備える、（１）に記載の方法。
（４） 前記埋め込みサブビットストリームの前記ビューコンポーネントを前記生成されたビットストリームに追加することは、
区切りネットワーク抽象化層（ＮＡＬ）ユニットが前記埋め込みサブビットストリーム内に到達するまで前記埋め込みサブビットストリームからＮＡＬユニットを取り出すことと、及び
前記取り出されたＮＡＬユニットのそれぞれを、前記区切りＮＡＬユニットを除いて、前記生成されたビットストリームに追加することと、
を備える、（１）に記載の方法。
（５） 前記プライマリサブビットストリームの前記ビューコンポーネントを前記生成されたビットストリームに追加することは、
区切りネットワーク抽象化層（ＮＡＬ）ユニットが前記プライマリサブビットストリーム内に到達するまで前記プライマリサブビットストリームからＮＡＬユニットを取り出すことと、及び
前記取り出されたＮＡＬユニットのそれぞれを、前記区切りＮＡＬユニットを除いて、前記生成されたビットストリームに追加することと、
を備える、（１）に記載の方法。
（６） 前記ビューコンポーネントの前記ビュー順序インデックスに応じて前記受信されたビットストリームの前記ビューコンポーネントの順序付けられた表現を備える階層層インデックスリストを生成すること、
をさらに備え、
前記生成されたビットストリームを前記ビデオデコーダに出力することは、前記階層層インデックスを前記ビデオデコーダに出力することを備える、（１）に記載の方法。
（７） 前記ＭＶＣ規格準拠のビットストリームを生成することは、前記プライマリサブビットストリームに含まれているビューのビュー識別子と前記埋め込みサブビットストリームに含まれているビューのビュー識別子とを比較せずに前記ＭＶＣ規格準拠のビットストリームを生成することを備える、（１）に記載の方法。
（８） ビデオビットストリームを生成するための装置であって、
プライマリサブビットストリームと前記プライマリサブビットストリームの埋め込みサブビットストリームとを備えるビットストリームを受信する入力インターフェースと、
前記受信されたビットストリームからマルチビュービデオ符号化（ＭＶＣ）規格準拠のビットストリームを生成するデマルチプレクサであって、前記ＭＶＣ規格準拠のビットストリームを生成するために、前記プライマリサブビットストリームのビューコンポーネントが前記埋め込みサブビットストリームのビューコンポーネントのビュー順序インデックスより大きいビュー順序インデックスを有するかどうかを判定し、前記プライマリサブビットストリームのビューコンポーネントの前記ビュー順序インデックスが前記埋め込みサブビットストリームの前記ビューコンポーネントの前記ビュー順序インデックスより大きい場合に、前記埋め込みサブビットストリームの前記ビューコンポーネントを前記生成されたビットストリームに追加し、前記プライマリサブビットストリームの前記ビューコンポーネントの前記ビュー順序インデックスが前記埋め込みサブビットストリームの前記ビューコンポーネントの前記ビュー順序インデックスより大きくない場合に、前記プライマリサブビットストリームの前記ビューコンポーネントを前記生成されたビットストリームに追加する、デマルチプレクサと、及び
前記デマルチプレクサによって生成された前記ビットストリームをデコードするビデオデコーダと、
を備える、ビデオビットストリームを生成するための装置。
（９） 前記デマルチプレクサは、前記プライマリサブビットストリームに残っているビューコンポーネントはないと判定した後、前記埋め込みサブビットストリームの残りのすべてのビューコンポーネントを前記生成されたサブビットストリームに追加する、（８）に記載の装置。
（１０） 前記デマルチプレクサは、前記埋め込みサブビットストリームに残っているビューコンポーネントはないと判定した後、前記プライマリサブビットストリームの残りのすべてのビューコンポーネントを前記生成されたサブビットストリームに追加する、（８）に記載の装置。
（１１） 前記埋め込みサブビットストリームの前記ビューコンポーネントを前記生成されたビットストリームに追加するために、前記デマルチプレクサは、区切りネットワーク抽象化層（ＮＡＬ）ユニットが前記埋め込みサブビットストリーム内に到達するまで前記埋め込みサブビットストリームからＮＡＬユニットを取り出し、次いで、前記取り出されたＮＡＬユニットのそれぞれを、前記区切りＮＡＬユニットを除いて、前記生成されたビットストリームに追加する、（８）に記載の装置。
（１２） 前記プライマリサブビットストリームの前記ビューコンポーネントを前記生成されたビットストリームに追加するために、前記デマルチプレクサは、区切りネットワーク抽象化層（ＮＡＬ）ユニットが前記プライマリサブビットストリーム内に到達するまで前記プライマリサブビットストリームからＮＡＬユニットを取り出し、前記取り出されたＮＡＬユニットのそれぞれを、前記区切りＮＡＬユニットを除いて、前記生成されたビットストリームに追加する、（８）に記載の装置。
（１３） 前記デマルチプレクサは、前記ビューコンポーネントの前記ビュー順序インデックスに応じて前記受信されたビットストリームの前記ビューコンポーネントの順序付けられた表現を備える階層層インデックスリストをさらに生成し、前記階層層インデックスを前記ビデオデコーダに前記生成されたビットストリームの一部として出力する、（８）に記載の装置。
（１４） 前記デマルチプレクサは、前記プライマリサブビットストリームに含まれているビューのビュー識別子と前記埋め込みサブビットストリームに含まれているビューのビュー識別子とを比較せずに前記ＭＶＣ規格準拠のビットストリームを生成する、（８）に記載の装置。
（１５） 前記装置は、
集積回路と、
マイクロプロセッサと、及び
前記ビデオエンコーダを備えるワイヤレス通信デバイスと、
のうちの少なくとも１つを備える、（８）に記載の装置。
（１６） ビデオビットストリームを生成するための装置であって、
プライマリサブビットストリームと前記プライマリサブビットストリームの埋め込みサブビットストリームとを備える受信されたビットストリームからマルチビュービデオ符号化（ＭＶＣ）規格準拠のビットストリームを生成するための手段であって、
前記プライマリサブビットストリームのビューコンポーネントが前記埋め込みサブビットストリームのビューコンポーネントのビュー順序インデックスより大きいビュー順序インデックスを有するかどうかを判定するための手段と、
前記プライマリサブビットストリームの前記ビューコンポーネントの前記ビュー順序インデックスが前記埋め込みサブビットストリームの前記ビューコンポーネントの前記ビュー順序インデックスより大きい場合に、前記埋め込みサブビットストリームの前記ビューコンポーネントを前記生成されたビットストリームに追加するための手段と、及び
前記プライマリサブビットストリームの前記ビューコンポーネントの前記ビュー順序インデックスが前記埋め込みサブビットストリームの前記ビューコンポーネントの前記ビュー順序インデックスより大きくない場合に、前記プライマリサブビットストリームの前記ビューコンポーネントを前記生成されたビットストリームに追加するための手段と、
を備える、ＭＶＣ規格準拠のビットストリームを生成するための手段と、及び
前記生成されたビットストリームをビデオデコーダに出力するための手段と、
を備える、ビデオビットストリームを生成するための装置。
（１７） 前記プライマリサブビットストリームに、残っているビューコンポーネントがないことを判定するための手段と、及び
前記埋め込みサブビットストリームの残りのすべてのビューコンポーネントを前記生成されたサブビットストリームに追加するための手段と、
をさらに備える、（１６）に記載の装置。
（１８） 前記埋め込みサブビットストリームに、残っているビューコンポーネントがないことを判定するための手段と、及び
前記プライマリサブビットストリームの残りのすべてのビューコンポーネントを前記生成されたサブビットストリームに追加するための手段と、
をさらに備える、（１６）に記載の装置。
（１９） 前記埋め込みサブビットストリームの前記ビューコンポーネントを前記生成されたビットストリームに追加するための前記手段は、
区切りネットワーク抽象化層（ＮＡＬ）ユニットが前記埋め込みサブビットストリーム内に到達するまで前記埋め込みサブビットストリームからＮＡＬユニットを取り出すための手段と、及び
前記取り出されたＮＡＬユニットのそれぞれを、前記区切りＮＡＬユニットを除いて、前記生成されたビットストリームに追加するための手段と、
を備える、（１６）に記載の装置。
（２０） 前記プライマリサブビットストリームの前記ビューコンポーネントを前記生成されたビットストリームに追加するための前記手段は、
区切りネットワーク抽象化層（ＮＡＬ）ユニットが前記プライマリサブビットストリーム内に到達するまで前記プライマリサブビットストリームからＮＡＬユニットを取り出すための手段と、及び
前記取り出されたＮＡＬユニットのそれぞれを、前記区切りＮＡＬユニットを除いて、前記生成されたビットストリームに追加するための手段と、
を備える、（１６）に記載の装置。
（２１） 前記ビューコンポーネントの前記ビュー順序インデックスに応じて前記受信されたビットストリームの前記ビューコンポーネントの順序付けられた表現を備える階層層インデックスリストを生成するための手段、
をさらに備え、
前記生成されたビットストリームを前記ビデオデコーダに出力するための前記手段は、前記階層層インデックスを前記ビデオデコーダに出力するための手段を備える、（１６）に記載の装置。
（２２） 前記ＭＶＣ規格準拠のビットストリームを生成するための前記手段は、前記プライマリサブビットストリームに含まれているビューのビュー識別子と前記埋め込みサブビットストリームに含まれているビューのビュー識別子とを比較せずに前記ＭＶＣ規格準拠のビットストリームを生成するための手段を備える、（１６）に記載の装置。
（２３） コンピュータ可読記憶媒体であって、クライアントデバイスのプロセッサに、
プライマリサブビットストリームと前記プライマリサブビットストリームの埋め込みサブビットストリームとを備える受信されたビットストリームからマルチビュービデオ符号化（ＭＶＣ）規格準拠のビットストリームを生成することを行わせる命令であって、
前記プライマリサブビットストリームのビューコンポーネントが前記埋め込みサブビットストリームのビューコンポーネントのビュー順序インデックスより大きいビュー順序インデックスを有するかどうかを判定する命令と、
前記プライマリサブビットストリームの前記ビューコンポーネントの前記ビュー順序インデックスが前記埋め込みサブビットストリームの前記ビューコンポーネントの前記ビュー順序インデックスより大きい場合に、前記埋め込みサブビットストリームの前記ビューコンポーネントを前記生成されたビットストリームに追加する命令と、及び
前記プライマリサブビットストリームの前記ビューコンポーネントの前記ビュー順序インデックスが前記埋め込みサブビットストリームの前記ビューコンポーネントの前記ビュー順序インデックスより大きくない場合に、前記プライマリサブビットストリームの前記ビューコンポーネントを前記生成されたビットストリームに追加する命令と、
を備える、前記ＭＶＣ規格順序のビットストリームを生成する命令と、及び
前記生成されたビットストリームを前記クライアントデバイスからビデオデコーダに出力することを行わせる命令と、
でエンコードされた、コンピュータ可読記憶媒体。
（２４） 前記プライマリサブビットストリームに、残っているビューコンポーネントがないことを判定する命令と、及び
前記埋め込みサブビットストリームの残りのすべてのビューコンポーネントを前記生成されたサブビットストリームに追加する命令と、
をさらに備える、（２３）に記載のコンピュータ可読記憶媒体。
（２５） 前記埋め込みサブビットストリームに、残っているビューコンポーネントがないことを判定する命令と、及び
前記プライマリサブビットストリームの残りのすべてのビューコンポーネントを前記生成されたサブビットストリームに追加する命令と、
をさらに備える、（２３）に記載のコンピュータ可読記憶媒体。
（２６） 前記埋め込みサブビットストリームの前記ビューコンポーネントを前記生成されたビットストリームに追加する前記命令は、
区切りネットワーク抽象化層（ＮＡＬ）ユニットが前記埋め込みサブビットストリーム内に到達するまで前記埋め込みサブビットストリームからＮＡＬユニットを取り出す命令と、及び
前記取り出されたＮＡＬユニットのそれぞれを、前記区切りＮＡＬユニットを除いて、前記生成されたビットストリームに追加する命令と、
を備える、（２３）に記載のコンピュータ可読記憶媒体。
（２７） 前記プライマリサブビットストリームの前記ビューコンポーネントを前記生成されたビットストリームに追加する前記命令は、
区切りネットワーク抽象化層（ＮＡＬ）ユニットが前記プライマリサブビットストリーム内に到達するまで前記プライマリサブビットストリームからＮＡＬユニットを取り出す命令と、及び
前記取り出されたＮＡＬユニットのそれぞれを、前記区切りＮＡＬユニットを除いて、前記生成されたビットストリームに追加する命令と、
を備える、（２３）に記載のコンピュータ可読記憶媒体。
（２８） 前記ビューコンポーネントの前記ビュー順序インデックスに応じて前記受信されたビットストリームの前記ビューコンポーネントの順序付けられた表現を備える階層層インデックスリストを生成する命令、
をさらに備え、
前記生成されたビットストリームを前記ビデオデコーダに出力する前記命令は、前記階層層インデックスを前記ビデオデコーダに出力する命令を備える、（２３）に記載のコンピュータ可読記憶媒体。
（２９） 前記ＭＶＣ規格準拠のビットストリームを生成する前記命令は、前記プライマリサブビットストリームに含まれているビューのビュー識別子と前記埋め込みサブビットストリームに含まれているビューのビュー識別子とを比較せずに前記ＭＶＣ規格準拠のビットストリームを生成する命令を備える、（２３）に記載のコンピュータ可読記憶媒体。

Claims (29)

1. ビデオビットストリームを生成する方法であって、
   クライアントデバイスにより、第１のサブビットストリームと第２のサブビットストリームとを備えるトランスポートストリームまたはプログラムストリームを備える受信されたＭＰＥＧ−２システム準拠のビットストリームからマルチビュービデオ符号化（ＭＶＣ）規格準拠のビットストリームを生成することであって、
   前記第１のサブビットストリームと前記第２のサブビットストリームに含まれる個々のビューのビュー順序インデックスを受信することと、及び
   前記受信したビュー順序インデックスに従って、前記第１及び第２のサブビットストリーム両方の前記ビューのすべてのビューコンポーネントのすべてをソートすることによって、前記第１及び第２のサブビットストリームを、昇順のビュー順序インデックスを備えるビューコンポーネントを持つような、単一のＭＶＣ規格準拠のビットストリームにアセンブルすることと、
   を備える、ＭＶＣ規格準拠のビットストリームを生成することと、及び
   前記生成されたＭＶＣ規格準拠のビットストリームをビデオデコーダに出力することと、
   を備えるビデオビットストリームを生成する方法。
2. 前記第１のサブビットストリームに、残っているビューコンポーネントがないことを判定することと、及び
   前記第２のサブビットストリームの残りのすべてのビューコンポーネントを前記生成されたＭＶＣ規格準拠のビットストリームに追加することと、
   をさらに備える、請求項１に記載の方法。
3. 前記第２のサブビットストリームに、残っているビューコンポーネントがないことを判定することと、及び
   前記第１のサブビットストリームの残りのすべてのビューコンポーネントを前記生成されたＭＶＣ規格準拠のビットストリームに追加することと、
   をさらに備える、請求項１に記載の方法。
4. 前記第２のサブビットストリームの前記ビューコンポーネントをアセンブルすることは、
   区切りネットワーク抽象化層（ＮＡＬ）ユニットが前記第２のサブビットストリーム内に到達するまで前記第２のサブビットストリームからＮＡＬユニットを取り出すことと、及び
   前記取り出されたＮＡＬユニットのそれぞれを、前記区切りＮＡＬユニットを除いて、前記生成されたＭＶＣ規格準拠のビットストリームに追加することと、
   を備える、請求項１に記載の方法。
5. 前記第１のサブビットストリームの前記ビューコンポーネントをアセンブルすることは、
   区切りネットワーク抽象化層（ＮＡＬ）ユニットが前記第１のサブビットストリーム内に到達するまで前記第１のサブビットストリームからＮＡＬユニットを取り出すことと、及び
   前記取り出されたＮＡＬユニットのそれぞれを、前記区切りＮＡＬユニットを除いて、前記生成されたＭＶＣ規格準拠のビットストリームに追加することと、
   を備える、請求項１に記載の方法。
6. 前記ビューコンポーネントの前記ビュー順序インデックスに応じて前記受信されたＭＰＥＧ−２システム準拠のビットストリームの前記ビューコンポーネントの順序付けられた表現を備える階層層インデックスリストを生成すること、
   をさらに備え、
   前記生成されたＭＶＣ規格準拠のビットストリームを前記ビデオデコーダに出力することは、前記階層層インデックスを前記ビデオデコーダに出力することを備える、請求項１に記載の方法。
7. 前記ＭＶＣ規格準拠のビットストリームを生成することは、前記第１のサブビットストリームに含まれているビューのビュー識別子と前記第２のサブビットストリームに含まれているビューのビュー識別子とを比較せずに前記ＭＶＣ規格準拠のビットストリームを生成することを備える、請求項１に記載の方法。
8. ビデオビットストリームを生成するための装置であって、
   第１のサブビットストリームと第２のサブビットストリームとを備えるトランスポートストリームまたはプログラムストリームを備えるＭＰＥＧ−２システム準拠のビットストリームを受信する入力インターフェースと、
   前記受信されたＭＰＥＧ−２システム準拠のビットストリームからマルチビュービデオ符号化（ＭＶＣ）規格準拠のビットストリームを生成するデマルチプレクサであって、前記ＭＶＣ規格準拠のビットストリームを生成するために、前記第１のサブビットストリームと前記第２のサブビットストリームに含まれる個々のビューのビュー順序インデックスを受信し、前記受信したビュー順序インデックスに従って、前記第１及び第２のサブビットストリーム両方の前記ビューのすべてのビューコンポーネントのすべてをソートすることによって、前記第１及び第２のサブビットストリームを、昇順のビュー順序インデックスを備えるビューコンポーネントを持つような、単一のＭＶＣ規格準拠のビットストリームにアセンブルする、デマルチプレクサと、及び
   前記デマルチプレクサによって生成された前記ＭＶＣ規格準拠のビットストリームをデコードするビデオデコーダと、
   を備える、ビデオビットストリームを生成するための装置。
9. 前記デマルチプレクサは、前記第１のサブビットストリームに残っているビューコンポーネントはないと判定した後、前記第２のサブビットストリームの残りのすべてのビューコンポーネントを前記生成されたＭＶＣ規格準拠のビットストリームに追加する、請求項８に記載の装置。
10. 前記デマルチプレクサは、前記第２のサブビットストリームに残っているビューコンポーネントはないと判定した後、前記第１のサブビットストリームの残りのすべてのビューコンポーネントを前記生成されたＭＶＣ規格準拠のビットストリームに追加する、請求項８に記載の装置。
11. 前記第２のサブビットストリームの前記ビューコンポーネントをアセンブルするために、前記デマルチプレクサは、区切りネットワーク抽象化層（ＮＡＬ）ユニットが前記第２のサブビットストリーム内に到達するまで前記第２のサブビットストリームからＮＡＬユニットを取り出し、次いで、前記取り出されたＮＡＬユニットのそれぞれを、前記区切りＮＡＬユニットを除いて、前記生成されたＭＶＣ規格準拠のビットストリームに追加する、請求項８に記載の装置。
12. 前記第１のサブビットストリームの前記ビューコンポーネントをアセンブルするために、前記デマルチプレクサは、区切りネットワーク抽象化層（ＮＡＬ）ユニットが前記第１のサブビットストリーム内に到達するまで前記プライマリサブビットストリームからＮＡＬユニットを取り出し、前記取り出されたＮＡＬユニットのそれぞれを、前記区切りＮＡＬユニットを除いて、前記生成されたＭＶＣ規格準拠のビットストリームに追加する、請求項８に記載の装置。
13. 前記デマルチプレクサは、前記ビューコンポーネントの前記ビュー順序インデックスに応じて前記受信されたＭＰＥＧ−２システム準拠のビットストリームの前記ビューコンポーネントの順序付けられた表現を備える階層層インデックスリストをさらに生成し、前記階層層インデックスを前記ビデオデコーダに前記生成されたＭＶＣ規格準拠のビットストリームの一部として出力する、請求項８に記載の装置。
14. 前記デマルチプレクサは、前記第１のサブビットストリームに含まれているビューのビュー識別子と前記第２のサブビットストリームに含まれているビューのビュー識別子とを比較せずに前記ＭＶＣ規格準拠のビットストリームを生成する、請求項８に記載の装置。
15. 前記装置は、
    集積回路と、
    マイクロプロセッサと、及び
    前記ビデオエンコーダを備えるワイヤレス通信デバイスと、
    のうちの少なくとも１つを備える、請求項８に記載の装置。
16. ビデオビットストリームを生成するための装置であって、
    第１のサブビットストリームと第２のサブビットストリームとを備えるトランスポートストリームまたはプログラムストリームを備える受信されたＭＰＥＧ−２システム準拠のビットストリームからマルチビュービデオ符号化（ＭＶＣ）規格準拠のビットストリームを生成するための手段であって、
    前記第１のサブビットストリームと前記第２のサブビットストリームに含まれる個々のビューのビュー順序インデックスを受信するための手段と、及び
    前記受信したビュー順序インデックスに従って、前記第１及び第２のサブビットストリーム両方の前記ビューのすべてのビューコンポーネントのすべてをソートすることによって、前記第１及び第２のサブビットストリームを、昇順のビュー順序インデックスを備えるビューコンポーネントを持つような、単一のＭＶＣ規格準拠のビットストリームにアセンブルするための手段と、
    を備える、ＭＶＣ規格準拠のビットストリームを生成するための手段と、及び
    前記生成されたＭＶＣ規格準拠のビットストリームをビデオデコーダに出力するための手段と、
    を備える、ビデオビットストリームを生成するための装置。
17. 前記第１のサブビットストリームに、残っているビューコンポーネントがないことを判定するための手段と、及び
    前記第２のサブビットストリームの残りのすべてのビューコンポーネントを前記生成されたＭＶＣ規格準拠のビットストリームに追加するための手段と、
    をさらに備える、請求項１６に記載の装置。
18. 前記第２のサブビットストリームに、残っているビューコンポーネントがないことを判定するための手段と、及び
    前記第１のサブビットストリームの残りのすべてのビューコンポーネントを前記生成されたＭＶＣ規格準拠のビットストリームに追加するための手段と、
    をさらに備える、請求項１６に記載の装置。
19. 前記第２のサブビットストリームの前記ビューコンポーネントをアセンブルするための前記手段は、
    区切りネットワーク抽象化層（ＮＡＬ）ユニットが前記第２のサブビットストリーム内に到達するまで前記第２のサブビットストリームからＮＡＬユニットを取り出すための手段と、及び
    前記取り出されたＮＡＬユニットのそれぞれを、前記区切りＮＡＬユニットを除いて、前記生成されたＭＶＣ規格準拠のビットストリームに追加するための手段と、
    を備える、請求項１６に記載の装置。
20. 前記第１のサブビットストリームの前記ビューコンポーネントをアセンブルするための前記手段は、
    区切りネットワーク抽象化層（ＮＡＬ）ユニットが前記第１のサブビットストリーム内に到達するまで前記第１のサブビットストリームからＮＡＬユニットを取り出すための手段と、及び
    前記取り出されたＮＡＬユニットのそれぞれを、前記区切りＮＡＬユニットを除いて、前記生成されたＭＶＣ規格準拠のビットストリームに追加するための手段と、
    を備える、請求項１６に記載の装置。
21. 前記ビューコンポーネントの前記ビュー順序インデックスに応じて前記受信されたＭＰＥＧ−２システム準拠のビットストリームの前記ビューコンポーネントの順序付けられた表現を備える階層層インデックスリストを生成するための手段、
    をさらに備え、
    前記生成されたＭＶＣ規格準拠のビットストリームを前記ビデオデコーダに出力するための前記手段は、前記階層層インデックスを前記ビデオデコーダに出力するための手段を備える、請求項１６に記載の装置。
22. 前記ＭＶＣ規格準拠のビットストリームを生成するための前記手段は、前記第１のサブビットストリームに含まれているビューのビュー識別子と前記第２のサブビットストリームに含まれているビューのビュー識別子とを比較せずに前記ＭＶＣ規格準拠のビットストリームを生成するための手段を備える、請求項１６に記載の装置。
23. コンピュータ可読記憶媒体であって、クライアントデバイスのプロセッサに、
    第１のサブビットストリームと第２のサブビットストリームとを備えるトランスポートストリームまたはプログラムストリームを備える受信されたＭＰＥＧ−２システム準拠のビットストリームからマルチビュービデオ符号化（ＭＶＣ）規格準拠のビットストリームを生成することを行わせる命令であって、
    前記第１のサブビットストリームと前記第２のサブビットストリームに含まれる個々のビューのビュー順序インデックスを受信する命令と、及び
    前記受信したビュー順序インデックスに従って、前記第１及び第２のサブビットストリーム両方の前記ビューのすべてのビューコンポーネントのすべてをソートすることによって、前記第１及び第２のサブビットストリームを、昇順のビュー順序インデックスを備えるビューコンポーネントを持つような、単一のＭＶＣ規格準拠のビットストリームにアセンブルする命令と、
    を備える、前記ＭＶＣ規格順序のビットストリームを生成する命令と、及び
    前記生成されたＭＶＣ規格準拠のビットストリームを前記クライアントデバイスからビデオデコーダに出力することを行わせる命令と、
    でエンコードされた、コンピュータ可読記憶媒体。
24. 前記第１のサブビットストリームに、残っているビューコンポーネントがないことを判定する命令と、及び
    前記第２のサブビットストリームの残りのすべてのビューコンポーネントを前記生成されたＭＶＣ規格準拠のビットストリームに追加する命令と、
    をさらに備える、請求項２３に記載のコンピュータ可読記憶媒体。
25. 前記第２のサブビットストリームに、残っているビューコンポーネントがないことを判定する命令と、及び
    前記第１のサブビットストリームの残りのすべてのビューコンポーネントを前記生成されたＭＶＣ規格準拠のビットストリームに追加する命令と、
    をさらに備える、請求項２３に記載のコンピュータ可読記憶媒体。
26. 前記第２のサブビットストリームの前記ビューコンポーネントをアセンブルする前記命令は、
    区切りネットワーク抽象化層（ＮＡＬ）ユニットが前記第２のサブビットストリーム内に到達するまで前記第２のサブビットストリームからＮＡＬユニットを取り出す命令と、及び
    前記取り出されたＮＡＬユニットのそれぞれを、前記区切りＮＡＬユニットを除いて、前記生成されたＭＶＣ規格準拠のビットストリームに追加する命令と、
    を備える、請求項２３に記載のコンピュータ可読記憶媒体。
27. 前記第１のサブビットストリームの前記ビューコンポーネントをアセンブルする前記命令は、
    区切りネットワーク抽象化層（ＮＡＬ）ユニットが前記第１のサブビットストリーム内に到達するまで前記第１のサブビットストリームからＮＡＬユニットを取り出す命令と、及び
    前記取り出されたＮＡＬユニットのそれぞれを、前記区切りＮＡＬユニットを除いて、前記生成されたＭＶＣ規格準拠のビットストリームに追加する命令と、
    を備える、請求項２３に記載のコンピュータ可読記憶媒体。
28. 前記ビューコンポーネントの前記ビュー順序インデックスに応じて前記受信されたＭＰＥＧ−２システム準拠のビットストリームの前記ビューコンポーネントの順序付けられた表現を備える階層層インデックスリストを生成する命令、
    をさらに備え、
    前記生成されたＭＶＣ規格準拠のビットストリームを前記ビデオデコーダに出力する前記命令は、前記階層層インデックスを前記ビデオデコーダに出力する命令を備える、請求項２３に記載のコンピュータ可読記憶媒体。
29. 前記ＭＶＣ規格準拠のビットストリームを生成する前記命令は、前記第１のサブビットストリームに含まれているビューのビュー識別子と前記第２のサブビットストリームに含まれているビューのビュー識別子とを比較せずに前記ＭＶＣ規格準拠のビットストリームを生成する命令を備える、請求項２３に記載のコンピュータ可読記憶媒体。

Images