(57)【要約】  マルチプレクサは、非連続ビュー順序インデックスを備えるビューを備えるＭＰＥＧ−２（Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）システム標準ビットストリームを生成する。一例において、装置は、シーンの複数のビューをエンコーディングするビデオエンコーダと、対応するＭＰＥＧ−２（Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）システム標準ビットストリームが第１のビュー順序インデックスに関連付けられたシーンの複数のビューのうちの第１のビューと第２のビュー順序インデックスに関連付けられたシーンの複数のビューのうちの第２のビューとを備えることをシグナリングするためのデータ構造を構築するマルチプレクサと、第１のビュー順序インデックスと第２のビュー順序インデックスとは非連続であり、データ構造を出力する出力インターフェースと、を備える。【選択図】図２
2013502089.tif 000002
【特許請求の範囲】
【請求項１】
マルチビュービデオデータを生成する方法であって、
ソースデバイスで、対応するＭＰＥＧ−２（Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）システム標準ビットストリームが第１のビュー順序インデックスに関連付けられたシーンの第１のビューと第２のビュー順序インデックスに関連付けられた前記シーンの第２のビューとを備えることをシグナリングするために、データ構造を構築することと、前記第１のビュー順序インデックスと前記第２のビュー順序インデックスとは非連続であり、
前記データ構造を出力することと、
を備える方法。
【請求項２】
前記データ構造はプログラムマップテーブルを備え、前記ビットストリームはＭＰＥＧ−２転送ストリームを備える、請求項１記載の方法。
【請求項３】
前記データ構造はプログラムストリームマップを備え、前記ビットストリームはＭＰＥＧ−２プログラムストリームを備える、請求項１記載の方法。
【請求項４】
前記データ構造を構築することは、前記ビットストリームに含まれる各ビューに対する個別のビュー順序インデックス値を備えるマルチビュービデオコーディング（ＭＶＣ）拡張記述子を構築することを備え、
前記個別のビュー順序インデックス値は前記第１のビュー順序インデックスと前記第２のビュー順序インデックスに関する値を備え、前記ビュー順序インデックス値は昇順に配置されている、
請求項１記載の方法。
【請求項５】
前記ビュー順序インデックス値は第１のビュー順序インデックス値と第２のビュー順序インデックス値とを備え、
前記第２のビュー順序インデックス値は前記ＭＶＣ拡張記述子の前記第１のビュー順序インデックス値の直後に生じ、前記第２のビュー順序インデックス値と前記第１のビュー順序インデックス値との間の差異は１より大きい、
請求項４記載の方法。
【請求項６】
前記データ構造を構築することは、ビュー拡張フラグフィールドに関する値を備える階層記述子を構築すること、を備え、前記ビュー拡張フラグフィールドについての値は、関連付けられたプログラム要素が、前記階層記述子の階層埋め込みレイヤインデックスフィールドの値によって参照される前記プログラム要素から生じる前記ビットストリームのビューの数を拡張することを示す、
請求項１記載の方法。
【請求項７】
前記階層記述子を構築することは、前記ビュー拡張フラグフィールドの前記値をゼロの値に設定すること、を備える請求項６記載の方法。
【請求項８】
前記ビットストリームはＭＶＣのアドバンスドビデオコーディング（ＡＶＣ）ベースビューを含むか否かを決定することをさらに備え、
前記階層記述子を構築することは、前記階層記述子の階層タイプフィールドの値を、２０に等しいタイプ値を備える全てのプレフィックスネットワーク抽象レイヤ（ＮＡＬ）ユニットを備えるプレフィックスＭＶＣサブビットストリームを前記ビットストリームが含むことを示す値に設定すること、を備える、
請求項６記載の方法。
【請求項９】
前記階層タイプフィールドの前記値を設定することは、前記階層タイプフィールドの前記値を１４の値に設定すること、を備える請求項８記載の方法。
【請求項１０】
前記第１のビューのビュー構成要素と前記第２のビューのビュー構成要素とを備えるアクセスユニットを構築することと、前記ビュー構成要素に関する前記第１のビュー順序インデックスと前記第２のビュー順序インデックスとが前記アクセスユニット内で非連続に生じるように、前記第１のビューの前記ビュー構成要素は、前記アクセスユニットにおいて、前記第２のビューの前記ビュー構成要素の直前に生じ、
前記アクセスユニットを出力することと、
をさらに備える請求項１記載の方法。
【請求項１１】
マルチビュービデオデータを生成するための装置であって、
シーンの複数のビューをエンコーディングするビデオエンコーダと、
対応するＭＰＥＧ−２（Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）システム標準ビットストリームが第１のビュー順序インデックスに関連付けられた前記シーンの複数のビューのうちの第１のビューと第２のビュー順序インデックスに関連付けられた前記シーンの複数のビューのうちの第２のビューとを備えることをシグナリングするために、データ構造を構築するマルチプレクサと、前記第１のビュー順序インデックスと前記第２のビュー順序インデックスとは非連続であり、
前記データ構造を出力する出力インターフェースと、
を備える装置。
【請求項１２】
前記データ構造はプログラムマップテーブルを備え、前記ビットストリームはＭＰＥＧ−２転送ストリームを備える、請求項１１記載の装置。
【請求項１３】
前記データ構造はプログラムストリームマップを備え、前記ビットストリームはＭＰＥＧ−２プログラムストリームを備える、請求項１１記載の装置。
【請求項１４】
前記データ構造を構築するために、前記マルチプレクサは、前記ビットストリームに含まれる各ビューに対する個別のビュー順序インデックス値を備えるマルチビュービデオコーディング（ＭＶＣ）拡張記述子を構築し、前記ビュー順序インデックス値は昇順に配置されている、請求項１１記載の装置。
【請求項１５】
前記ビュー順序インデックス値は前記第１のビュー順序インデックスに関する第１のビュー順序インデックス値と前記第２のビュー順序インデックスに関する第２のビュー順序インデックス値を備え、
前記第２のビュー順序インデックス値が前記ＭＶＣ拡張記述子の前記第１のビュー順序インデックス値の直後に生じ、前記第２のビュー順序インデックス値と前記第１のビュー順序インデックス値との間の差異は１より大きい、
請求項１４に記載の装置。
【請求項１６】
前記データ構造を構築するために、前記マルチプレクサは、ビュー拡張フラグフィールドに関する値を備える階層記述子をさらに構築し、
前記ビュー拡張フラグフィールドについての値は、関連付けられたプログラム要素が、前記階層記述子の階層埋め込みレイヤインデックスフィールドの値によって参照される前記プログラム要素から生じる前記ビットストリームのビューの数を拡張することを示す、
請求項１１記載の装置。
【請求項１７】
前記階層記述子を構築するために、前記マルチプレクサは、前記ビュー拡張フラグフィールドの前記値をゼロの値に設定する、請求項１６記載の装置。
【請求項１８】
前記マルチプレクサは、前記ビットストリームがＭＶＣのアドバンスドビデオコーディング（ＡＶＣ）ベースビューを含むか否かを決定し、
前記ビットストリームがＭＶＣの前記ＡＶＣベースビューを含む場合、前記マルチプレクサは、前記階層記述子の階層タイプフィールドの値を、２０に等しいタイプ値を備える全てのプレフィックスネットワーク抽象レイヤ（ＮＡＬ）ユニットを備えるプレフィックＭＶＣサブビットストリームを前記ビットストリームが含むことを示す値に設定する、
請求項１６記載の装置。
【請求項１９】
前記階層タイプフィールドの前記値を設定するために、前記マルチプレクサは前記階層タイプフィールドの前記値を１４の値に設定する、請求項１８記載の装置。
【請求項２０】
前記マルチプレクサは前記第１のビューのビュー構成要素と前記第２のビューのビュー構成要素を備えるアクセスユニットを構築し、
前記ビュー構成要素に関する前記第１のビュー順序インデックスと前記第２のビュー順序インデックスとが前記アクセスユニット内で非連続に生じるように、前記第１のビューの前記ビュー構成要素は、前記アクセスユニットにおいて、前記第２のビューの前記ビュー構成要素の直前に生じ、
前記出力インターフェースは前記アクセスユニットを出力する、
請求項１１記載の装置。
【請求項２１】
前記装置は、
集積回路と、
マイクロプロセッサと、
前記ビデオエンコーダを含むワイヤレス通信デバイスと、
のうちの少なくとも１つを備える請求項１１記載の装置。
【請求項２２】
マルチビュービデオデータを生成するための装置であって、
ソースデバイスで、対応するＭＰＥＧ−２（Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）システム標準ビットストリームが第１のビュー順序インデックスに関連付けられたシーンの第１のビューと第２のビュー順序インデックスに関連付けられた前記シーンの第２のビューとを備えることをシグナリングするために、データ構造を構築する手段と、前記第１のビュー順序インデックスと前記第２のビュー順序インデックスとは非連続であり、
前記データ構造を出力する手段と、
を備える装置。
【請求項２３】
前記データ構造はプログラムマップテーブルを備え、前記ビットストリームはＭＰＥＧ−２転送ストリームを備える、請求項２２記載の装置。
【請求項２４】
前記データ構造はプログラムストリームマップを備え、前記ビットストリームはＭＰＥＧ−２プログラムストリームを備える、請求項２２記載の装置。
【請求項２５】
前記データ構造を構築する手段は、前記ビットストリームに含まれる各ビューに対する個別のビュー順序インデックス値を備えるマルチビューコーディング（ＭＶＣ）拡張記述子を構築する手段を備え、
前記個別のビュー順序インデックス値は前記第１のビュー順序インデックスと前記第２のビュー順序インデックスとに関する値を備え、前記ビュー順序インデックス値は昇順に配置されている、
請求項２２記載の装置。
【請求項２６】
前記ビュー順序インデックス値は第１のビュー順序インデックス値と第２のビュー順序インデックス値とを備え、
前記第２のビュー順序インデックス値は前記ＭＶＣ拡張記述子の前記第１のビュー順序インデックス値の直後に生じ、前記第２のビュー順序インデックス値と前記第１のビュー順序インデックス値との間の差異は１より大きい、
請求項２５記載の装置。
【請求項２７】
前記データ構造を構築する手段は、ビュー拡張フラグフィールドに関する値を備える階層記述子を構築する手段をさらに備え、前記ビュー拡張フラグフィールドについての値は、関連付けられたプログラム要素が、前記階層記述子の階層埋め込みレイヤインデックスフィールドの値によって参照される前記プログラム要素から生じる前記ビットストリームのビューの数を拡張することを示す、
請求項２２記載の装置。
【請求項２８】
前記階層記述子を構築する手段は、前記ビュー拡張フラグフィールドの前記値をゼロの値に設定する手段、を備える請求項２７記載の装置。
【請求項２９】
前記ビットストリームはＭＶＣのアドバンスドビデオコーディング（ＡＶＣ）ベースビューを含むか否かを決定する手段をさらに備え、
前記階層記述子を構築する手段は、前記階層記述子の階層タイプフィールドの値を、２０に等しいタイプの値を備える全てのプレフィックスネットワーク抽象レイヤ（ＮＡＬ）ユニットを備えるプレフィックスＭＶＣサブビットストリームを前記ビットストリームが含むことを示す値に設定する手段を備える、請求項２７記載の装置。
【請求項３０】
前記階層タイプフィールドの前記値を設定する手段は、前記階層タイプフィールドの前記値を１４の値に設定する手段、を備える請求項２９記載の装置。
【請求項３１】
前記第１のビューのビュー構成要素と前記第２のビューのビュー構成要素を備えるアクセスユニットを構築することと、前記ビュー構成要素に関する前記第１のビュー順序インデックスと前記第２のビュー順序インデックスとが前記アクセスユニット内で非連続に生じるように、前記第１のビューの前記ビュー構成要素は、前記アクセスユニットにおいて、前記第２のビューの前記ビュー構成要素の直前に生じ、
前記アクセスユニットを出力することと、
をさらに備える請求項２２記載の装置。
【請求項３２】
コンピュータ可読記憶媒体であって、ビデオデータソースデバイスのプロセッサに、
対応するＭＰＥＧ−２（Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）システム標準ビットストリームが第１のビュー順序インデックスに関連付けられたシーンの第１のビューと第２のビュー順序インデックスに関連付けられた前記シーンの第２のビューとを備えることをシグナリングするために、データ構造を構築させる命令と、前記第１のビュー順序インデックスと前記第２のビュー順序インデックスとは非連続であり、
前記データ構造を出力させる命令と、
がエンコーディングされたコンピュータ可読記憶媒体。
【請求項３３】
前記データ構造はプログラムマップテーブルを備え、前記ビットストリームはＭＰＥＧ−２転送ストリームを備える、請求項３２記載のコンピュータ可読記憶媒体。
【請求項３４】
前記データ構造はプログラムストリームマップを備え、前記ビットストリームはＭＰＥＧ−２プログラムストリームを備える、請求項３２記載のコンピュータ可読記憶媒体。
【請求項３５】
前記データ構造を構築させる命令は、前記ビットストリームに含まれる各ビューに対する個別のビュー順序インデックス値を備えるマルチビューコーディング（ＭＶＣ）拡張記述子を構築させる命令を備え、
前記個別のビュー順序インデックス値は前記第１のビュー順序インデックスと前記第２のビュー順序インデックスに関する値を備え、
前記ビュー順序インデックス値は昇順に配置されている、
請求項３２記載のコンピュータ可読記憶媒体。
【請求項３６】
前記ビュー順序インデックス値は第１のビュー順序インデックス値と第２のビュー順序インデックス値を備え、
前記第２のビュー順序インデックス値は前記ＭＶＣ拡張記述子の前記第１のビュー順序インデックス値の直後に生じ、
前記第２のビュー順序インデックス値と前記第１のビュー順序インデックス値との間の差異は１より大きい、
請求項３５記載のコンピュータ可読記憶媒体。
【請求項３７】
前記データ構造を構築させる命令は、ビュー拡張フラグフィールドに関する値を備える階層記述子を構築させる命令をさらに備え、
前記ビュー拡張フラグフィールドについての値は、関連付けられたプログラム要素が、階層記述子の階層埋め込みレイヤインデックスフィールドの値によって参照される前記プログラム要素から生じる前記ビットストリームのビューの数を拡張することを示す、
請求項３２記載のコンピュータ可読記憶媒体。
【請求項３８】
前記階層記述子を構築させる命令は、前記ビュー拡張フラグフィールドの前記値をゼロの値に設定させる命令を備える、請求項３７記載のコンピュータ可読記憶媒体。
【請求項３９】
前記ビットストリームがＭＶＣのアドバンスドビデオコーディング（ＡＶＣ）ベースビューを含むか否かを決定させる命令をさらに備え、
前記階層記述子を構築することは、前記階層記述子の階層タイプフィールドの値を、２０に等しいタイプの値を備える全てのプレフィックスネットワーク抽象レイヤ（ＮＡＬ）ユニットを備えるプレフィックスＭＶＣサブビットストリームを前記ビットストリームが含むことを示す値に設定することを備える、
請求項３７記載のコンピュータ可読記憶媒体。
【請求項４０】
前記階層タイプフィールドの前記値を設定させる命令は、前記階層タイプフィールドの前記値を１４の値に設定させる命令を備える、請求項３９記載のコンピュータ可読記憶媒体。
【請求項４１】
前記第１のビューのビュー構成要素と前記第２のビューのビュー構成要素を備えるアクセスユニットを構築させる命令と、前記ビュー構成要素に関する前記第１のビュー順序インデックスと前記第２のビュー順序インデックスとが前記アクセスユニット内で非連続に生じるように、前記第１のビューの前記ビュー構成要素は、前記アクセスユニットにおいて、前記第２のビューの前記ビュー構成要素の直前に生じ、
前記アクセスユニットを出力させる命令と、
をさらに備える請求項３２記載のコンピュータ可読記憶媒体。
【発明の詳細な説明】
【関連出願】
【０００１】
関連出願
本出願は、２００９年６月２９日に出願された米国仮特許出願第６１／２２１，４４９号と、２００９年６月１２日に出願された米国仮特許出願第６１／１８６，６１３号との利益を主張し、それら両方の全内容は、それぞれ全体として参照により本明細書に明示的に組み入れられる。
【０００２】
関連出願への相互参照
本特許出願は、本出願と同時に出願され、本出願の譲受人に譲渡され、ここでの参照をもって本明細書に明示的に組み入れられる、代理人整理番号第０９２６５２号を有する下記の同時係属中のＹｉｎｇ  Ｃｈｅｎによる米国特許出願「ＡＳＳＥＭＢＬＩＮＧ  ＭＵＬＴＩＶＩＥＷ  ＶＩＤＥＯ  ＣＯＤＩＮＧ  ＳＵＢ−ＢＩＳＴＲＥＡＭＳ  ＩＮ  ＭＰＥＧ−２  ＳＹＳＴＥＭＳ」に関連する。
【技術分野】
【０００３】
本開示は、エンコードされたビデオデータの転送に関する。
【背景技術】
【０００４】
デジタルビデオ機能は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップ又はデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレイヤー、ビデオゲームデバイス、ビデオゲームコンソール、携帯電話又は衛星無線電話、テレビ会議デバイス、及び同等物を含む多種多様のデバイスに組み込まれ得る。デジタルビデオデバイスは、デジタルビデオ情報をより効率的に送受信するように、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ  Ｈ．２６３又はＩＴＵ−Ｔ  Ｈ．２６４／ＭＰＥＧ−４、Ｐａｒｔ１０、Ａｄｖａｎｃｅｄ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ（ＡＶＣ）によって規定される標準、及びそれら標準の拡張により説明されるようなビデオ圧縮技術を実装する。
【０００５】
ビデオ圧縮技術は、ビデオシーケンスに内在する冗長性を低減又は削除するために空間的予測及び／又は時間的予測を実行する。ブロックベースビデオコーディングについては、ビデオフレーム又はスライスがマクロブロックに分割され得る。各マクロブロックは、さらに分割され得る。イントラコード化された（Ｉ）フレーム又はスライスのマクロブロックは、隣接するマクロブロックに関する空間的予測を用いてエンコーディングされる。インターコーディングされた（Ｐ又はＢ）フレーム又はスライスのマクロブロックは、同じフレーム若しくはスライス内の隣接するマクロブロックに関する空間的予測又は他の参照フレームに関する時間的予測を用い得る。
【０００６】
ビデオデータがエンコーディングされた後、このビデオデータは、送信又は記憶のためにマルチプレクサによってパケット化され得る。ＭＰＥＧ−２は、多くのビデオエンコーディング標準に関する転送レベルを規定する「システム」部分を含む。ＭＰＥＧ−２転送レベルシステムは、ＭＰＥＧ−２ビデオエンコーダ又は種々のビデオエンコーディング標準に準拠するその他のビデオエンコーダによって使用され得る。例えば、ＭＰＥＧ−４は、ＭＰＥＧ−２のものとは異なるエンコーディング方法とデコーディング方法とを指定するが、ＭＰＥＧ−４標準の技術を実装するビデオエンコーダはそれでもなおＭＰＥＧ−２転送レベル方法を利用し得る。一般に、「ＭＰＥＧ−２システム」への言及は、ＭＰＥＧ−２によって規定されるビデオデータの転送レベルを指している。ＭＰＥＧ−２によって規定される転送レベルは、本開示で「ＭＰＥＧ−２転送ストリーム」又は単に「転送ストリーム」とも呼ばれる。同様に、ＭＰＥＧ−２システムの転送レベルは、プログラムストリームをさらに含む。一般に、転送ストリーム及びプログラムストリームは、同様のデータを配信するための異なる複数のフォーマットを含み、転送ストリームがオーディオデータとビデオデータの両方を含む１つ又は複数の「プログラム」を備えるのに対し、プログラムストリームはオーディオデータとビデオデータの両方を含む１つのプログラムを備える。
【０００７】
ＭＰＥＧ−２システム仕様は、デジタル送信又は記憶に適切な単一なデータストリームを形成するために、圧縮されているマルチメディア（ビデオ及びオーディオ）データストリームがどのようにして他のデータと共に多重化され得るかを説明している。ＭＰＥＧ−２システムの最新の仕様は、２００６年５月の「Ｉｎｆｏｒｍａｔｉｏｎ  Ｔｅｃｈｎｏｌｏｇｙ−Ｇｅｎｅｒｉｃ  Ｃｏｄｉｎｇ  ｏｆ  Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅｓ  ａｎｄ  Ａｓｓｏｃｉａｔｅｄ  Ａｕｄｉｏ：Ｓｙｓｔｅｍｓ，Ｒｅｃｏｍｍｅｎｄａｔｉｏｎ  Ｈ．２２２．０；Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｏｒｇａｎｉｓａｔｉｏｎ  ｆｏｒ  Ｓｔａｎｄａｒｉｓａｔｉｏｎ，ＩＳＯ／ＩＥＣ  ＪＴＣ１／ＳＣ２９／ＷＧ１１；Ｃｏｄｉｎｇ  ｏｆ  Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅｓ  ａｎｄ  Ａｓｓｏｃｉａｔｅｄ  Ａｕｄｉｏ」に規定されている。ＭＰＥＧは、ＭＰＥＧ−２システムにおけるＭＶＣの転送標準が最近設計されており、この仕様の最新バージョンは、「Ｓｔｕｄｙ  ｏｆ  ＩＳＯ／ＩＥＣ  １３８１８−１：２００７／ＦＰＤＡＭ４  Ｔｒａｎｓｐｏｒｔ  ｏｆ  ＭＶＣ」ＭＰＥＧ文書Ｎ１０５７２号、ＭＰＥＧ  ｏｆ  ＩＳＯ／ＩＥＣ  ＪＴＣ１／ＳＣ２９／ＷＧ１１、米国ハワイ州マウイ、２００９年４月である。
【発明の概要】
【０００８】
一般に、本開示は、ＭＰＥＧ−２（Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）システムのマルチビュービデオコーディングを改善するための技術を説明する。本開示の技術は、一般に、ＭＰＥＧ−２転送レベル、例えば、ＭＰＥＧ−２転送ストリーム及びＭＰＥＧ−２プログラムストリーム、の機能をマルチビュービデオコーディング（ＭＶＣ）に関して拡張する。例えば、本開示の機能は、ＭＶＣビデオストリームの非連続ビューの送信が転送レベルで送信されることを可能にする。本開示の技術は、転送ストリーム（又はプログラム）のサブビットストリームが各々、非連続ビューを含むことをさらに可能にする。この技術はまた、受信デバイスが、各々が非連続ビューを有する複数のサブビットストリームを備える転送レベルストリームを受信すると、サブビットストリームのビューを再配置し、転送ストリームが適切に、即ち、ビュー順序インデックスに関して昇順に順序付けられることを可能にし、それによりデコーダがビューの各々のフレームを適切にデコーディングし得る。
【０００９】
一例において、方法は、対応するＭＰＥＧ−２（Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）システム標準ビットストリームが第１のビュー順序インデックスに関連付けられたシーンの第１のビューと第２のビュー順序インデックスに関連付けられたシーンの第２のビューとを備えることをシグナリングするために、ソースデバイスで、データ構造を構築することを含み、第１のビュー順序インデックスと第２のビュー順序インデックスが非連続である。この方法はまた、例えば、データ構造を宛先デバイスに送信すること又はデータ構造をコンピュータ可読媒体に記憶すること等の、データ構造を出力することを含む。
【００１０】
別の例において、装置は、シーンの複数のビューをエンコーディングするビデオエンコーダと、対応するＭＰＥＧ−２（Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）システム標準ビットストリームが第１のビュー順序インデックスに関連付けられたシーンの複数のビューのうちの第１のビューと第２のビュー順序インデックスに関連付けられたシーンの複数のビューのうちの第２のビューとを備えることをシグナリングするためのデータ構造を構築するマルチプレクサと、を含み、第１のビュー順序インデックスと第２のビュー順序インデックスとが非連続であり、該装置はさらに、データ構造を出力する出力インターフェースを含む。
【００１１】
別の例において、装置は、対応するＭＰＥＧ−２（Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）システム標準ビットストリームが第１のビュー順序インデックスに関連付けられたシーンの第１のビューと第２のビュー順序インデックスに関連付けられたシーンの第２のビューとを備えることをシグナリングするために、ソースデバイスで、データ構造を構築する手段を含み、第１のビュー順序インデックスと第２のビュー順序インデックスが非連続であり、該装置はさらに、データ構造を出力するための手段を含む。
【００１２】
別の例において、コンピュータ可読記憶媒体は、プロセッサに、対応するＭＰＥＧ−２（Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）システム標準ビットストリームが第１のビュー順序インデックスに関連付けられたシーンの第１のビューと第２のビュー順序インデックスに関連付けられたシーンの第２のビューとを備えることをシグナリングするためのデータ構造を構築させる命令と、ここで第１のビュー順序インデックスと第２のビュー順序インデックスが非連続であり、このデータ構造を出力させる命令とがエンコーディングされる。
【００１３】
さらに別の例において、方法は、クライアントデバイスで、プライマリ・サブビットストリームとこのプライマリ・サブビットストリームの埋め込まれたサブビットストリームとを備える受信したビットストリームからマルチビュービデオコーディング（ＭＶＣ）標準に準拠するビットストリームを生成することを含み、ＭＶＣ標準に準拠するビットストリームを生成することは、プライマリ・サブビットストリームのビュー構成要素が埋め込まれたサブビットストリームのビュー構成要素のビュー順序インデックスより大きいビュー順序インデックスを有するか否かを決定することと、プライマリ・サブビットストリームのビュー構成要素のビュー順序インデックスが、埋め込まれたサブビットストリームのビュー構成要素のビュー順序インデックスより大きい場合には、埋め込まれたサブビットストリームのビュー構成要素を生成されたビットストリームに付加することと、プライマリ・サブビットストリームのビュー構成要素のビュー順序インデックスが、埋め込まれたサブビットストリームのビュー構成要素のビュー順序インデックスより大きくない場合には、プライマリ・サブビットストリームのビュー構成要素を生成されたビットストリームに付加することと、を含む。この方法は、生成されたビットストリームをビデオデコーダに出力することをさらに含む。
【００１４】
別の例において、装置は、プライマリ・サブビットストリームとこのプライマリ・サブビットストリームの埋め込まれたサブビットストリームとを備えるビットストリームを受信する受信機と、受信したビットストリームからマルチビュービデオコーディング（ＭＶＣ）標準に準拠するビットストリームを生成するデマルチプレクサと、を含み、ＭＶＣ標準に準拠するビットストリームを生成するために、このデマルチプレクサはプライマリ・サブビットストリームのビュー構成要素が、埋め込まれたサブビットストリームのビュー構成要素のビュー順序インデックスより大きいビュー順序インデックスを有するか否かを決定し、プライマリ・サブビットストリームのビュー構成要素のビュー順序インデックスが埋め込まれたサブビットストリームのビュー構成要素のビュー順序インデックスより大きい場合に、埋め込まれたサブビットストリームのビュー構成要素を生成されたビットストリームに付加し、プライマリ・サブビットストリームのビュー構成要素のビュー順序インデックスが埋め込まれたサブビットストリームのビュー構成要素のビュー順序インデックスより大きくない場合に、プライマリ・サブビットストリームのビュー構成要素を生成されたビットストリームに付加する。該装置はさらに、このデマルチプレクサによって生成されたビットストリームをデコーディングするビデオデコーダを含む。
【００１５】
別の例において、装置は、プライマリ・サブビットストリームとこのプライマリ・サブビットストリームの埋め込まれたサブビットストリームとを備える受信したビットストリームからマルチビュービデオコーディング（ＭＶＣ）標準に準拠するビットストリームを生成する手段と、
プライマリ・サブビットストリームのビュー構成要素が、埋め込まれたサブビットストリームのビュー構成要素のビュー順序インデックスより大きいビュー順序インデックスを有するか否かを決定する手段と、プライマリ・サブビットストリームのビュー構成要素のビュー順序インデックスが、埋め込まれたサブビットストリームのビュー構成要素のビュー順序インデックスより大きい場合に、埋め込まれたサブビットストリームのビュー構成要素を生成されたビットストリームに付加する手段と、プライマリ・サブビットストリームのビュー構成要素のビュー順序インデックスが、埋め込まれたサブビットストリームのビュー構成要素のビュー順序インデックスより大きくない場合に、プライマリ・サブビットストリームのビュー構成要素を生成されたビットストリームに付加する手段と、生成されたビットストリームをビデオデコーダに出力する手段と、を含む。
【００１６】
別の例において、コンピュータ可読記憶媒体は、プログラマブルプロセッサに、クライアントデバイスで、プライマリ・サブビットストリームとこのプライマリ・サブビットストリームの埋め込まれたサブビットストリームとを備える受信したビットストリームからマルチビュービデオコーディング（ＭＶＣ）標準に準拠するビットストリームを生成させる命令がエンコーディングされ、該命令は、プライマリ・サブビットストリームのビュー構成要素が埋め込まれたサブビットストリームのビュー構成要素のビュー順序インデックスより大きいビュー順序インデックスを有するか否かを決定し、プライマリ・サブビットストリームのビュー構成要素のビュー順序インデックスが、埋め込まれたサブビットストリームのビュー構成要素のビュー順序インデックスより大きい場合に、埋め込まれたサブビットストリームのビュー構成要素を生成されたビットストリームに付加し、プライマリ・サブビットストリームのビュー構成要素のビュー順序インデックスが、埋め込まれたサブビットストリームのビュー構成要素のビュー順序インデックスより大きくない場合に、プライマリ・サブビットストリームのビュー構成要素を生成されたビットストリームに付加し、生成されたビットストリームをビデオデコーダに出力する命令を含む。
【００１７】
１つ又は複数の実施例の詳細は、添付の図面及び以下の説明に記載されている。その他の機能、目的及び利点は、説明及び図面から、且つ特許請求の範囲から明白になるであろう。
【図面の簡単な説明】
【００１８】
【図１】オーディオ／ビデオ（Ａ／Ｖ）ソースデバイスがオーディオデータとビデオデータとをＡ／Ｖ宛先デバイスに転送する例示的なシステムを図示するブロック図。
【図２】マルチプレクサの構成要素の例示的な配置を図示するブロック図。
【図３】プログラム特有情報テーブルの例示的なセットを図示するブロック図。
【図４】マルチビュービデオコーディング（ＭＶＣ）拡張記述子に含まれるデータのセットの例を図示するブロック図。
【図５】階層記述子に含まれるデータのセットの例を図示するブロック図。
【図６】例示的なＭＶＣ予測パターンを図示する概念図。
【図７】非連続ビュー順序インデックスを備えるビューのサブセットを有するＭＰＥＧ−２システムストリームをサーバからクライアントに送るための例示的な方法を図示するフローチャート。
【図８】ビュー構成要素が昇順のビュー順序インデックスを有するようにビットストリームを生成するために、２つ以上のサブビットストリームのビュー構成要素を組み立てる方法の例を図示するフローチャート。
【発明を実施するための形態】
【００１９】
本開示の技術は、一般に、ＭＰＥＧ−２（Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）システム、即ち、転送レベルの詳細に関してＭＰＥＧ−２に準拠するシステムにおけるマルチビュービデオコーディング（ＭＶＣ）を向上させることを対象とする。例えば、ＭＰＥＧ−４は、ビデオエンコーディングに関する標準を提供するが、ＭＰＥＧ−４標準に準拠するビデオエンコーダは、ＭＰＥＧ−２転送レベルシステムを利用することが一般に予測される。従って、本開示の技術は、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ  Ｈ．２６３、ＩＴＵ−Ｔ  Ｈ．２６４／ＭＰＥＧ−４、又はＭＰＥＧ−２転送ストリーム及び／若しくはＭＰＥＧ−２プログラムストリームを利用するあらゆる他のビデオエンコーディング標準に準拠するビデオエンコーダに適用可能である。
【００２０】
特に、本開示の技術は、ＭＰＥＧ−２転送ストリームとプログラムストリームとに関する転送レベルでシンタックス要素を修正するために用いられ得る。例えば、本開示の技術は、転送ストリーム内で送信されるマルチビュービデオデータの各ビューを具体的に識別するために転送ストリーム内で送信される記述子を含む。サーバデバイスは、例えば、各々がマルチビュービデオコーディングビデオデータの特定のビューの各サブセットを備える種々のサービスを提供し、サービスのビューのサブセットは、クライアントデバイスによって実行されるアプリケーション、クライアントデバイスによって実行されるデコーダの容量、クライアントデバイスによって示される嗜好、又はその他の選択基準に基づいて選択され得る。
【００２１】
本開示の技術によれば、サーバデバイスは、非連続ビュー順序インデックスを有するビューのサブセットを提供する。一例において、サーバデバイスは、転送ストリームに含まれるビューの各々を、プログラムマップテーブル（ＰＭＴ）又はプログラムストリームマップ（ＰＳＭ）に含まれ得るＭＶＣ拡張記述子で、具体的にシグナリングする。
【００２２】
いくつかの例において、サーバデバイスが複数のサブビットストリームを単一の転送ストリーム又はプログラムストリームで送信する。ビットストリームのビューが非連続であることを可能にすることによって、本開示の技術は、各サブビットストリームのビューに対応するビュー順序インデックスが非連続であることをさらに可能にする。これらの技術は、各サブビットストリームの非連続ビュー順序インデックスを可能にするが、既存のビットストリーム標準、例えば、ＭＰＥＧ−２システム標準に準拠するために、ビュー順序インデックスはそれでもなおサブビットストリーム内で昇順であることが必要とされる。しかしながら、第１のサブビットストリームと第２のサブビットストリームとのビューが各々、非連続であり得るため、ビューは、ビュー順序インデックスに関して順序外れにクライアントデバイスに到着し得る。本開示の技術はまた、第１のサブビットストリームと第２のサブビットストリームのビューを効率的に再順序付けしてビューのビュー順序インデックスが昇順になるように、クライアントデバイスがそのような転送ストリームを処理することを可能にする。帯域適応、デコーダ効率に有用である可能性があり、且つその他のそのような利点を提供するビューのスケーラビリティに、非連続ビュー順序インデックスを有するビュー組み合わせが用いられ得る。例えば、クライアントデバイスに全てのビューを送信し、クライアントデバイスが連続的ビュー順序インデックスを有する各ビューをデコーディングすることを必要とする従来技術とは対照的に、本開示の技術は、クライアントデバイスによって具体的に要求されたビューだけを送信することを、これによって非連続ビュー順序インデックスを有するビューを生じる場合でさえも可能にする。このようにして、クライアントデバイスは、ビュー順序インデックスを介在して全てのビューを受信するのではなく、特定のサービスに必要であるビューだけを受信することが可能である。
【００２３】
種々の部分で本開示が「転送ストリーム」又は「プログラムストリーム」に個別に言及する可能性があるが、本開示の技術は、ＭＰＥＧ−２転送ストリームとＭＰＥＧ−２プログラムストリームの一方又は両方に一般に適用可能であることを理解されたい。一般に、本開示は、本開示の技術を実行するための例示的な記述子を説明する。記述子は、ストリームの機能性を拡張するために用いられる。本開示の記述子は、本開示の技術を実装するために転送ストリームとプログラムストリームとの両方によって用いられ得る。
【００２４】
さらに、本開示は、以下の用語を使用しており、これらの用語を以下に示す意味と共に最新のＭＰＥＧ−２システム標準の改訂に含むことを提案する：
・ＡＶＣビデオサブビットストリーム：ＭＶＣビットストリームのベースビュー
・ＭＶＣのＡＶＣビデオサブビットストリーム：プレフィックスＮＡＬユニットを破棄するＭＶＣビットストリームのベースビュー
・ＭＶＣベースビューサブビットストリーム：ＭＶＣのＡＶＣビデオサブストリーム又はＡＶＣビデオサブビットストリームのいずれか
・ＭＶＣビュー構成要素サブセット：１つのビュー構成要素のＮＡＬユニット
・ＭＶＣｖｉｅｗ＿ｉｄサブセット：１つのビューのＮＡＬユニット
・ＭＶＣビデオサブビットストリーム：非ベースビューのＮＡＬユニット
図１は、オーディオ／ビデオ（Ａ／Ｖ）ソースデバイス２０がオーディオデータとビデオデータとをＡ／Ｖ宛先デバイス４０に転送する例示的なシステム１０を図示するブロック図である。図１のシステム１０は、テレビ会議システム、サーバ／クライアントシステム、ブロードキャスター／受信機システム、又はビデオデータがＡ／Ｖソースデバイス２０等のソースデバイスからＡ／Ｖ宛先デバイス４０等の宛先デバイスに送られる任意のその他のシステムに対応し得る。実施例によっては、Ａ／Ｖソースデバイス２０とＡ／Ｖ宛先デバイス４０とが双方向の情報交換を実行し得る。即ち、Ａ／Ｖソースデバイス２０とＡ／Ｖ宛先デバイス４０は、オーディオデータとビデオデータのエンコーディングとデコーディング（さらに送信と受信）の両方が可能であり得る。実施例によっては、オーディオエンコーダ２６が、ボコーダとも呼ばれる音声エンコーダを備え得る。
【００２５】
図１の実施例のＡ／Ｖソースデバイス２０は、オーディオソース２２とビデオソース２４とを備えている。オーディオソース２２は、例えば、オーディオエンコーダ２６によってエンコーディングされるキャプチャされたオーディオデータを表す電気信号を生成するマイクロフォンを備え得る。代替的に、オーディオソース２２は、以前に記録されたオーディオデータを記憶する記憶媒体、コンピュータ化されているシンセサイザ等のオーディオデータジェネレータ、又は任意のその他のオーディオデータのソースを備え得る。ビデオソース２４は、ビデオエンコーダ２８によってエンコーディングされるビデオデータを生成するビデオカメラ、以前に記録されたビデオデータでエンコーディングされた記憶媒体、ビデオデータ生成ユニット、又は任意のその他のビデオデータのソースを備え得る。生のオーディオデータとビデオデータとは、アナログデータ又はデジタルデータを備え得る。アナログデータは、オーディオエンコーダ２６及び／又はビデオエンコーダ２８によってエンコーディングされる前にデジタル化され得る。オーディオソース２２は、発話参加者が話している際に発話参加者からオーディオデータを取得し、ビデオソース２４は、発話参加者のビデオデータを同時に取得する。別の実施例では、オーディオソース２２が、記憶されているオーディオデータを備えるコンピュータ可読記憶媒体を備え、ビデオソース２４が、記憶されているビデオデータを備えるコンピュータ可読記憶媒体を備える。このようにして、本開示で開示された技術が、ライブ、ストリーミング、リアルタイムのオーディオデータとビデオデータとに、又は保存された、予め記録されたオーディオデータとビデオデータとに適用される。
【００２６】
ビデオフレームに対応するオーディオフレームは、一般に、ビデオフレーム内に含まれるビデオソース２４によってキャプチャされビデオデータと同時にオーディオソース２２によってキャプチャされたオーディオデータを含んでいる。例えば、発話参加者が一般に発話によってオーディオデータを生成する際に、オーディオソース２２がオーディオデータをキャプチャし、同時に、即ち、オーディオソース２２がオーディオデータをキャプチャする際にビデオソース２４が発話参加者のビデオデータをキャプチャする。それゆえに、オーディオフレームは、１つ又は複数の特定のビデオフレームと時間的に対応し得る。従って、ビデオフレームと対応するオーディオフレームは、オーディオデータとビデオデータとが同時にキャプチャされ、オーディオフレームとビデオフレームとがそのために、同時にキャプチャされたオーディオデータとビデオデータとを各々備えている状況に一般に対応する。
【００２７】
実施例によっては、オーディオエンコーダ２６が、エンコーディングされたオーディオフレームの各々のタイムスタンプをエンコーディングする。ここで、タイムスタンプは、エンコーディングされたオーディオフレームについてのオーディオデータが記録された時間を示す。同時に、ビデオエンコーダ２８が、エンコーディングされたビデオフレームの各々のタイムスタンプをエンコーディングしてもよく、このタイムスタンプは、エンコーディングされたビデオフレームについてのビデオデータが記録された時間を示す。そのような実施例で、ビデオフレームに対応するオーディオフレームは、タイムスタンプを備えるオーディオフレームと、同一のタイムスタンプを備えるビデオフレームとを備え得る。Ａ／Ｖソースデバイス２０は、オーディオエンコーダ２６及び／又はビデオエンコーダ２８がタイムスタンプをそれから生成し得る、又はオーディオソース２２とビデオソース２４とがオーディオデータとビデオデータとを各々、タイムスタンプと関連付けるために用いる、内部クロックを含み得る。実施例によっては、オーディオソース２２が、オーディオデータが記録された時間に対応してデータをオーディオエンコーダ２６に送ってよいし、ビデオソース２４が、ビデオデータが記録された時間に対応してデータをビデオエンコーダ２８に送ってよい。実施例によっては、オーディオデータが記録された絶対的時間を必ずしも示すことなしに、エンコーディングされたオーディオデータの相対的時間的順序付けを示すために、オーディオエンコーダ２６が、エンコーディングされたオーディオデータのシーケンス識別子をエンコーディングし、同様に、ビデオエンコーダ２８が、エンコーディングされたビデオデータの相対的時間的順序付けを示すためにシーケンス識別子を用いてもよい。同様に、実施例によっては、シーケンス識別子がマッピングされるか、そうでなければタイムスタンプと関連付けられてよい。
【００２８】
本開示の技術は、一般に、エンコーディングされたマルチメディア（例えば、オーディオ及びビデオ）データの転送と、転送されたマルチメディアデータの受信とその後の解釈とデコーディングとを対象としている。本開示の技術は、具体的に、マルチビュービデオコーディング（ＭＶＣ）データ、即ち、複数のビューを備えるビデオデータの転送に適用可能である。図１の実施例に示すように、ビデオソース２４は、シーンの複数のビューをビデオエンコーダ２８に提供する。ＭＶＣは、立体(stereoscopic）又は自動立体（autostereoscopic）の３次元ディスプレイ等の３次元ディスプレイによって用いられる３次元ビデオデータを生成するのに有用である。
【００２９】
Ａ／Ｖソースデバイス２０は、Ａ／Ｖ宛先デバイス４０に「サービス」を提供する。サービスは、一般に、ＭＶＣデータの利用可能なビューのサブセットに対応する。例えば、ＭＶＣデータは、０から７に順序付けられた８つのビューが利用可能である。１つのサービスが２つのビューを有する立体ビデオに対応し、一方、別のサービスが４つのビューに対応し、さらに別のサービスが全ての８つのビューに対応する。一般に、サービスは、利用可能なビューの任意の組み合わせ（即ち、任意のサブセット）に対応する。サービスは、利用可能なビューの組み合わせと同様にオーディオデータにも対応する。
【００３０】
Ａ／Ｖソースデバイス２０は、本開示の技術に従って、非連続ビュー順序インデックスを含むビューのサブセットに対応するサービスを提供することが可能である。一般に、ビューはビュー識別子で示され、「ｖｉｅｗ＿ｉｄ」とも呼ばれる。ビュー識別子は、一般に、ビューを識別するのに用いられるシンタックス要素を備える。ＭＶＣエンコーダは、ビューがエンコーディングされる際にビューのｖｉｅｗ＿ｉｄを提供する。ｖｉｅｗ＿ｉｄは、ビュー間予測のためにＭＶＣデコーダによって、又は別の目的、例えば、レンダリングのために他のユニットによって使用される。
【００３１】
ビュー間予測は、フレームのＭＶＣビデオデータを異なるビューのエンコーディングされたフレームとして共通の時間位置における１つ又は複数のフレームに関連してエンコーディングするための技術である。以下でより詳述される図６は、ビュー間予測に関する例示的なコーディングスキームを提供している。一般に、ＭＶＣビデオデータのエンコーディングされたフレームは、空間的、時間的、および／又は共通の時間位置での他のビューのフレームに関連して、予測的にエンコーディングされる。従って、それから他のビューが予測される参照ビューは、一般に、参照ビューが参照として機能するビューがデコーディングされる前にデコーディングされ、それによりこれらのデコーディングされたビューは関連ビューがデコーディングされる際に参照として用いられ得る。デコーディング順序は、必ずしもｖｉｅｗ＿ｉｄの順序と対応しない。それゆえに、ビューのデコーディング順序は、ビュー順序インデックスを用いて表現される。ビュー順序インデックスは、アクセスユニットの対応するビュー構成要素のデコーディング順序を示すインデックスである。
【００３２】
データ（オーディオ又はビデオによらず）の各個別のストリームは、基本（elementary）ストリームと呼ばれる。基本ストリームは、プログラムのデジタル的にコーディングされた（ことによると圧縮されている）単一の構成要素である。例えば、プログラムのオーディオ部分又はコーディングされたビデオは、基本ストリームである。基本ストリームは、プログラムストリーム又は転送ストリームに多重化される前にパケット化された基本ストリーム（ＰＥＳ）に変換され得る。同一プログラム内で、１つの基本ストリームに属するＰＥＳパケットを他のものから区別するためにストリームＩＤが用いられる。基本ストリームのデータの基本ユニットは、パケット化された基本ストリーム（ＰＥＳ）パケットである。従って、ＭＶＣビデオデータの各ビューは、各基本ストリームに対応する。同様に、オーディオデータは、各基本ストリームに対応する。図１の実施例では、マルチプレクサ３０は、ビデオデータを備える基本ストリームをビデオエンコーダ２８から、且つオーディオデータを備える基本ストリームをオーディオエンコーダ２６から受信する。実施例によっては、ビデオエンコーダ２８とオーディオエンコーダ２６は、エンコーディングされたデータからＰＥＳパケットを形成するためにパケッタイザを各々含んでよい。別の実施例では、ビデオエンコーダ２８とオーディオエンコーダ２６はそれぞれ、エンコーディングされたデータからＰＥＳパケットを形成するためにそれぞれのパケッタイザとインターフェースをとってよい。さらに別の実施例では、マルチプレクサ３０は、エンコーディングされたオーディオデータとビデオデータからＰＥＳパケットを形成するためにパケッタイザを含んでよい。
【００３３】
本開示で用いられる「プログラム」は、オーディオデータとビデオデータとの組み合わせ、例えば、Ａ／Ｖソースデバイス２０のサービスによって配信される利用可能なビューのサブセットとオーディオ基本ストリームとを備える。各ＰＥＳパケットは、ＰＥＳパケットが所属する基本ストリームを識別するｓｔｒｅａｍ＿ｉｄを含む。マルチプレクサ３０は、基本ストリームを構成プログラムストリーム又は転送ストリームに統合する役割を果たす。プログラムストリームと転送ストリームとは、種々のアプリケーションをターゲットにする２つの代替的なマルチプレックス（multiplex）である。
【００３４】
一般に、プログラムストリームが１つのプログラムについてのデータから構成されるのに対し、転送ストリームは１つ又は複数のプログラムについてのデータを備える。マルチプレクサ３０は、提供されるサービス、ストリームが渡される媒体、送られるプログラムの数、又はその他の考察に基づいて、プログラムストリームと転送ストリームの一方又は両方をエンコーディングする。例えば、ビデオデータが記憶媒体内でエンコーディングされる際に、マルチプレクサ３０がプログラムストリームを形成する傾向が強い可能性があり、同様に、ビデオデータがネットワーク、ブロードキャストにおいてストリーミングされるか又はテレビ電話の一部として送られる際に、マルチプレクサ３０が転送ストリームを用いる傾向が強い可能性がある。
【００３５】
マルチプレクサ３０は、デジタル記憶サービスからの単一プログラムの記憶と表示のためにプログラムストリームを用いる方に偏っている。プログラムストリームはエラーにかなり影響を受けやすいため、プログラムストリームは、エラーのない環境又は直面するエラーに影響を受ける度合いが小さい環境で用いることが意図される。プログラムストリームは、それに所属する基本ストリームを単に備え、通常、可変長パケットと共にパケットを含む。プログラムストリーム内で、寄与する基本ストリームから生じたＰＥＳパケットが「パック（pack）」に編成される。パックは、パックヘッダと、任意選択のシステムヘッダと、任意の寄与する基本ストリームから取得された任意の数のＰＥＳパケットとを任意の順序で備える。システムヘッダは、プログラムストリームの最大データレート、寄与するビデオ及びオーディオ基本ストリームの数、さらなるタイミング情報、又はその他の情報等のプログラムストリームの特性の概要を含む。デコーダは、デコーダがプログラムストリームをデコーディングすることが可能であるか否かを決定するために、システムヘッダに含まれる情報を用い得る。
【００３６】
マルチプレクサ３０は、潜在的にエラーが生じやすいチャネルにおける複数のプログラムの同時配信に対して転送ストリームを使用し得る。転送ストリームは、ブロードキャスティング等のマルチプログラムアプリケーションに関して考案されたマルチプレックスであり、そのために単一の転送ストリームが多数の独立したプログラムに対応可能である。転送ストリームは一連の転送パケットを備え、転送パケットの各々は１８８バイト長である。短い固定長パケットの使用は、転送ストリームがプログラムストリームよりエラーの影響を受けにくいことを意味する。さらに、各１８８バイト長転送パケットは、このパケットをリードソロモン（Ｒｅｅｄ−Ｓｏｌｏｍｏｎ）エンコーディング等の標準エラー防止プロセスを介して処理することによって、付加的なエラー防止が与えられる。転送ストリームの改善されたエラー耐性は、それが、例えば、ブロードキャスト環境で見つかるエラーの生じやすいチャネルより生存する可能性が高いことを意味する。
【００３７】
転送ストリームは、その増強されたエラー耐性と多数の同時プログラムを搬送する能力とにより、２つのマルチプレックスのうちの明らかに良い方であると見受けられる。しかしながら、転送ストリームは、プログラムストリームより洗練されたマルチプレックスであり、それゆえに生成及び逆多重化することがより困難である。転送パケットの最初のバイトは０ｘ４７（１６進数４７、２進数「０１０００１１１」、１０進数７１）の値を有する同期バイトである。単一の転送ストリームは、多数の異なるプログラムを搬送することが可能であり、各々のプログラムが多数のパケット化された基本ストリームを備える。マルチプレクサ３０は、１つの基本ストリームのデータを含む転送パケットを、他の基本ストリームのデータを搬送する転送パケットから区別するために、１３ビットのパケット識別子（ＰＩＤ）フィールドを用いる。各基本ストリームが固有のＰＩＤ値を与えられていることを確認することは、マルチプレクサの役割である。転送パケットの最後のバイトは、連続性カウントフィールドである。マルチプレクサ３０は、同一の基本ストリームに所属する連続転送パケットの間で連続性カウントフィールドの値を増加させる。これによって、デコーダ又はＡ／Ｖ宛先デバイス４０等の宛先デバイスのその他のユニットが、転送パケットの損失又はゲインを検出することが可能になり、望ましくは、そうでなければそのようなイベントから生じている可能性があるエラーをキャンセルすることができる。
【００３８】
マルチプレクサ３０は、オーディオエンコーダ２６とビデオエンコーダ２８とからプログラムの基本ストリームに関するＰＥＳパケットを受信し、このＰＥＳパケットから対応するネットワーク抽象レイヤ（ＮＡＬ：network abstraction layer）ユニットを形成する。Ｈ．２６４／ＡＶＣ（Ａｄｖａｎｃｅｄ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ）の例では、コーディングされたビデオセグメントがＮＡＬユニットに編成され、これがテレビ電話、記憶、ブロードキャスト、又はストリーミング等の「ネットワークに優しい」ビデオ表現対処アプリケーションを提供する。ＮＡＬユニットは、Ｖｉｄｅｏ  Ｃｏｄｉｎｇ  Ｌａｙｅｒ（ＶＣＬ）ＮＡＬユニットと非ＶＣＬ−ＮＡＬユニットとに分類され得る。ＶＣＬユニットは、コア圧縮エンジンを含み、ブロック、マクロブロック、及び／又はスライスレベルを備え得る。その他のＮＡＬユニットは、非ＶＣＬ−ＮＡＬユニットである。
【００３９】
マルチプレクサ３０は、ＮＡＬが所属するプログラムを識別するヘッダと、例えば、オーディオデータ、ビデオデータ、又はＮＡＬユニットが対応する転送ストリーム若しくはプログラムストリームを説明するデータ等のペイロードとを備えるＮＡＬユニットを形成し得る。例えば、Ｈ．２６４／ＡＶＣで、ＮＡＬユニットは、１バイトのヘッダと可変サイズのペイロードとを含む。一実施例では、ＮＡＬユニットヘッダは、ｐｒｉｏｒｉｔｙ＿ｉｄ要素と、ｔｅｍｐｏｒａｌ＿ｉｄ要素と、ａｎｃｈｏｒ＿ｐｉｃ＿ｆｌａｇ要素と、ｖｉｅｗ＿ｉｄ要素と、ｎｏｎ＿ｉｄｒ＿ｆｌａｇ要素と、ｉｎｔｅｒ＿ｖｉｅｗ＿ｆｌａｇ要素とを備える。従来のＭＶＣで、Ｈ．２６４で規定されるＮＡＬユニットは、４バイトＭＶＣ  ＮＡＬユニットヘッダとＮＡＬユニットペイロードとを含む、プレフィックスＮＡＬユニットとＭＶＣコーディングされたスライスＮＡＬユニットを除いて保留される。
【００４０】
ＮＡＬヘッダのｐｒｉｏｒｉｔｙ＿ｉｄ要素は、単純な一経路ビットストリーム適応プロセスに用いられ得る。ｔｅｍｐｏｒａｌ＿ｉｄ要素は、対応するＮＡＬユニットの時間的レベルを特定するのに用いられ得て、異なる時間レベルは異なるフレームレートに対応する。ａｎｃｈｏｒ＿ｐｉｃ＿ｆｌａｇ要素は、ピクチャがアンカーピクチャ又は非アンカーピクチャであるかどうかを示し得る。
【００４１】
出力順序（即ち、表示順序）でアンカーピクチャとその後に続く全てのピクチャとが、前のピクチャをデコーディング順序（即ち、ビットストリーム順序）でデコーディングすることなしに正しくデコーディングでき、従って、ランダムアクセスポイントとして用いられる。アンカーピクチャと非アンカーピクチャとが異なる依存性を有し、それらは共にシーケンスパラメータセットでシグナリングされる。その他のフラグは本章の後節で説明及び使用される。そのようなアンカーピクチャは、オープンＧＯＰ（Ｇｒｏｕｐ  Ｏｆ  Ｐｉｃｔｕｒｅｓ）アクセスポイントとも呼ばれ、一方、ｎｏｎ＿ｉｄｒ＿ｆｌａｇ要素がゼロに等しい場合にはクローズＧＯＰアクセスポイントも同様にサポートされる。ｎｏｎ＿ｉｄｒ＿ｆｌａｇ要素は、ピクチャが瞬時デコーダ更新（ＩＤＲ）又はビューＩＤＲ（Ｖ−ＩＤＲ）ピクチャであるかどうかを示す。一般に、ＩＤＲピクチャと、出力順序又はビットストリーム順序でその後に続く全てのピクチャとが、前のピクチャをデコーディング順序又は表示順序のいずれか一方でデコーディングすることなしに適切にデコーディングされ得る。
【００４２】
ｖｉｅｗ＿ｉｄ要素は、ビューを識別するのに用いられ得るシンタックス情報を備え、それは、例えば、ビュー間予測のためにＭＶＣデコーダの内部で、及び、例えば、レンダリングのためにデコーダの外部でデータ双方向性のために用いられ得る。ｉｎｔｅｒ＿ｖｉｅｗ＿ｆｌａｇ要素は、対応するＮＡＬユニットが他のビューによってビュー間予測に用いられているかを特定し得る。ＡＶＣに準拠し得る、ベースビューに関する４バイトＮＡＬユニットヘッダ情報を搬送するために、プレフィックスＮＡＬユニットがＭＶＣに規定されている。ＭＶＣにおいて、ベースビューアクセスユニットは、ビューの最新の時間インスタンスのＶＣＬ  ＮＡＬユニットと、ＮＡＬユニットヘッドだけを含むそのプレフィックスＮＡＬユニットとを含む。Ｈ．２６４／ＡＶＣデコーダは、プレフィックスＮＡＬユニットを無視し得る。
【００４３】
ビデオデータをそのペイロードに含むＮＡＬユニットは、種々の粒度レベルのビデオデータを備え得る。例えば、ＮＡＬユニットは、ビデオデータのブロック、マクロブロック、複数のマクロブロック、ビデオデータのスライス、又はビデオデータの全フレームを備え得る。マルチプレクサ３０は、ビデオエンコーダ２８から基本ストリームのＰＥＳパケットの形態でエンコーディングされたビデオデータを受信し得る。マルチプレクサ３０は、例えば、データベースで、又はプログラムマップテーブル（ＰＭＴ）若しくはプログラムストリームマップ（ＰＳＭ）等のその他のデータ構造体で、ｓｔｒｅａｍ＿ｉｄを対応するプログラムにマッピングすることによって各基本ストリームを対応するプログラムに関連付けし得る。
【００４４】
さらに、マルチプレクサ３０は、複数のＮＡＬユニットからアクセスユニットを組み立てる。一般に、アクセスユニットは、ビデオデータのフレームを表現するための、また、そのフレームに対応するオーディオデータが利用可能である際にはそうしたオーディオデータのフレームも表現するための１つ又は複数のＮＡＬユニットを備える。Ｈ．２６４／ＡＶＣに対応する実施例で、アクセスユニットは、一時間インスタンス内にコーディングされたピクチャを備え得て、それはプライマリ・コーディングされたピクチャと示され得る。従って、アクセスユニットは、例えば、時間Ｘに対応する全てのビュー等の、共通な時間インスタンスの全てのオーディオ及びビデオのフレームを備え得る。本開示は、さらに、特定のビューのエンコーディングされたピクチャを「ビュー構成要素」と呼ぶ。即ち、ビュー構成要素は、特定の時間での特定のビューに関するエンコーディングされたピクチャ（又はフレーム）を備える。従って、アクセスユニットは、共通な時間インスタンスの全てのビュー構成要素を備えているものとして規定される。
【００４５】
マルチプレクサ３０は、さらに、プログラムに関するデータをＮＡＬユニットに埋め込み得る。例えば、マルチプレクサ３０は、プログラムマップテーブル（ＰＭＴ）又はプログラムストリームマップ（ＰＳＭ）を備えるＮＡＬユニットを生成し得る。一般に、ＰＭＴが転送ストリームを表現するのに用いられ、一方、ＰＳＭはプログラムストリームを表現するのに用いられる。下記の図２の実施例に関連してより詳述されるように、マルチプレクサ３０は、オーディオエンコーダ２６とビデオエンコーダ２８とから受信した基本ストリームをプログラムと関連付け、従って、各転送ストリーム及び／又はプログラムストリームと関連付ける、データ記憶ユニットを備えるか、又は相互作用をし得る。
【００４６】
ＭＰＥＧ−２システム標準は、「記述子」を通じてシステムの拡張を可能にする。ＰＭＴとＰＳＭの両方が、１つ又は複数の記述子が挿入され得る記述子ループを含む。一般に、記述子は、プログラム及び／又はプログラム要素の定義を拡張するのに用いられる構造を備える。本開示は、本開示の技術を実行するための２つの記述子：ＭＶＣ拡張記述子と階層記述子とを説明する。一般に、本開示のＭＶＣ拡張記述子は、プログラムストリーム又は転送ストリームに埋め込まれているビューのビュー順序インデックスを具体的に識別することによって従来のＭＶＣ拡張記述子を向上させ、一方、本開示の階層記述子は、関連付けられたプログラム要素が、階層記述子の要素によって参照される該プログラム要素から生じたビットストリームのビューの数を増加させるか否かを示すフラグを含む。
【００４７】
ＩＴＵ−Ｔ  Ｈ．２６１、Ｈ．２６３、ＭＰＥＧ−１、ＭＰＥＧ−２、及びＨ．２６４／ＭＰＥＧ−４  Ｐａｒｔ１０等のビデオ圧縮標準は、時間的冗長性を低減するために動き補償時間予測を活用する。エンコーダは、動きベクトルに従って最新のコーディングされているピクチャを予測するために、いくつかの以前にエンコーディングされたピクチャ（本明細書ではフレームとも呼ぶ）から動き補償予測を用いる。典型的なビデオコーディングでは３種類のプライマリ・ピクチャタイプが存在する。それらは、イントラコーディングされたピクチャ（「Ｉ−ピクチャ」又は「Ｉ−フレーム」）と、予測ピクチャ（「Ｐ−ピクチャ」又は「Ｐ−フレーム」）と、双方向予測ピクチャ（「Ｂ−ピクチャ」又は「Ｂ−フレーム」）である。Ｐ−ピクチャは、時間順序で最新のピクチャの前の参照ピクチャだけを用いる。Ｂ−ピクチャでは、１つ又は２つの参照ピクチャからＢ−ピクチャの各ブロックが予測され得る。これらの参照ピクチャは、時間順序で現ピクチャの前又は後に位置する。
【００４８】
Ｈ．２６４コーディング標準に従って、実施例のように、Ｂ−ピクチャが以前にコーディングされた参照ピクチャの２つのリスト、リスト０とリスト１とを用いる。これらの２つのリストは、それぞれ、時間順序で過去及び／又は未来のコーディングされたピクチャを含む。Ｂ−ピクチャのブロックは、いくつかの方法：リスト０参照ピクチャからの動き補償予測、リスト１参照ピクチャからの動き補償予測、又はリスト０とリスト１の参照ピクチャの両方の組み合わせからの動き補償予測、のうちの１つで予測され得る。リスト０とリスト１の参照ピクチャの両方の組み合わせを得るために、２つの動き補償参照領域が、各々、リスト０とリスト１の参照ピクチャから取得される。それらの組み合わせが最新のブロックを予測するために用いられる。
【００４９】
ＩＴＵ−Ｔ  Ｈ．２６４標準は、ルマ構成要素に関する１６かける１６、８かける８、又は４かける４、及び彩度構成要素に関する８×８等の種々のブロックサイズでのイントラ予測と、ルマ構成要素に関する１６×１６、１６×８、８×１６、８×８、８×４、４×８、及び４×４、及び彩度構成要素に関する対応するスケーリングされたサイズ等の種々のブロックサイズでのインター予測とをサポートしている。本開示では、「×」と「かける」は、例えば、１６×１６ピクセル又は１６かける１６ピクセル等、垂直及び水平寸法に関するブロックのピクセル寸法を示すために交換可能に用いられ得る。一般に、１６×１６ブロックは、垂直方向に１６ピクセル（ｙ＝１６）と、水平方向に１６ピクセル（ｘ＝１６）とを有する。同様に、Ｎが負でない整数値を示す場合、Ｎ×Ｎブロックは、一般に、垂直方向にＮピクセルと、水平方向にＮピクセルとを有する。ブロックのピクセルは、行と列に配置され得る。
【００５０】
１６かける１６より小さいブロックサイズは、１６かける１６マクロブロックのパーティションと呼ばれ得る。ビデオブロックは、ピクセル領域内のピクセルデータのブロック、又は、例えば、離散コサイン変換（ＤＣＴ）、整数変換、ウェーブレット変換、若しくはコーディングされたビデオブロックと予測ビデオブロックとの間のピクセル差異を示す残余のビデオブロックデータへの概念的に類似の変換等の変換アプリケーションの変換領域内の変換係数のブロックを備え得る。場合によっては、ビデオブロックは、変換領域内の量子化された変換係数のブロックを備えてよい。
【００５１】
より小さなビデオブロックは、より良質な解像度を提供でき、高レベルの細部表現を含むビデオフレームの位置に用いられる。一般に、マクロブロックと、場合によってはサブブロックと呼ばれる種々のパーティションとがビデオブロックとみなされる。さらに、スライスは、マクロブロック及び／又はサブブロック等の複数のビデオブロックであるとみなされる。各スライスは、ビデオフレームと独立してデコーディング可能なユニットであり得る。代替的に、フレーム自体がデコーディング可能なユニットであるか、又はフレームの別の部分がデコーディング可能なユニットとして規定されてよい。用語「コーディングされたユニット」又は「コーディングユニット」は、全フレーム、フレームのスライス、シーケンスとも呼ばれるピクチャの群（ＧＯＰ）、又は適用可能なコーディング技術に従って規定された他の独立してデコーディング可能なユニット等の、ビデオフレームの任意の独立してデコーディング可能なユニットを示す。
【００５２】
用語マクロブロックは、１６×１６ピクセルを備える２次元ピクセル配列に従って、ピクチャ及び／又はビデオデータをエンコーディングするためのデータ構造を示す。各ピクセルは、クロミナンス構成要素とルミナンス構成要素とを備える。従って、マクロブロックは、各々が８×８ピクセルの２次元配列を備える４つのルミナンスブロックと、各々が１６×１６ピクセルの２次元配列を備える２つのクロミナンスブロックと、コーディングされたブロックパターン（ＣＢＰ）、エンコーディングモード（例えば、イントラ−（Ｉ）、又はインター−（Ｐ又はＢ）エンコーディングモード）、イントラエンコーディングされたブロックのパーティションに関するパーティションサイズ（例えば、１６×１６、１６×８、８×１６、８×８、８×４、４×８、又は４×４）、若しくはインターエンコーディングされたマクロブロックに関する１つ又は複数の動きベクトル等のシンタックス情報を備えるヘッダを規定する。
【００５３】
ビデオエンコーダ２８、ビデオデコーダ４８、オーディオエンコーダ２６、オーディオデコーダ４６、マルチプレクサ３０、及びデマルチプレクサ３８は、各々、１つ又は複数のマイクロプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、個別論理回路、ソフトウェア、ハードウェア、ファームウェア又はそれらの任意の組み合わせ等の任意の適切なエンコーダ又はデコーダ回路として適宜実装され得る。ビデオエンコーダ２８とビデオデコーダ４８の各々は、１つ又は複数のエンコーダ又はデコーダに含まれてよく、それらのいずれもが、結合されたビデオエンコーダ／デコーダ（ＣＯＤＥＣ）の一部として統合されてよい。同様に、オーディオエンコーダ２６とオーディオデコーダ４６の各々が１つ又は複数のエンコーダ又はデコーダに含まれてよく、それらのいずれもが、結合されたオーディオエンコーダ／デコーダ（ＣＯＤＥＣ）の一部として統合されてよい。ビデオエンコーダ２８、ビデオデコーダ４８、オーディオエンコーダオーディオエンコーダ２６、オーディオデコーダ４６、マルチプレクサ３０、及び／又はデマルチプレクサ３８を含む装置が、集積回路、マイクロプロセッサ、及び／又は携帯電話等のワイヤレス通信デバイスを備える。
【００５４】
本開示の技術は、いくつかの動作点に関するシグナリング特性のサポートを使用不可にする、ＭＶＣサブビットストリームに関する従来の技術より優れた所定の利点を提供し得る。従来の技術とは異なり、本開示のＭＶＣ拡張記述子のシンタックス要素及び意味が非連続ビュー順序インデックス値を使用可能にして、従って、ＭＶＣに準拠し、且つ非連続であるビュー順序インデックス値を備えるビットストリーム又はサブビットストリームをサポートすることを可能にする。本開示は、ビュー拡張をシグナリングするための階層記述子をさらに提案し、それはＭＶＣサブビットストリームが成功するデコーディングに関して他のビューに依存していることをデコーダが決定することを可能にさせる。
【００５５】
特性のシグナリングの良質なサポートを提供するために、提案されたＭＶＣ拡張記述子内でシグナリングされるようなビュー順序インデックス値が任意選択的に非連続であってよい。さらに、ビュー順序インデックス値又はｖｉｅｗ＿ｉｄ値はＭＶＣ拡張記述子内でシグナリングされてよい。
【００５６】
代替的に、ビュー順序インデックスリマッピング機構は、ＭＶＣサブビットストリームが多重化される前に、アクティブな従来のシーケンスパラメータセット（ＳＰＳ）ＭＶＣ拡張に規定されるビュー順序を修正することによって、その準拠ＭＶＣサブビットストリームのビューのビュー順序インデックス値を、連続的ビュー順序インデックス値にマッピングするのに用いられる。そのような機構では、ビュー順序インデックスよりもむしろ従来のＭＶＣ拡張記述子がビューＩＤをシグナリングするのに用いられ、従って、異なるビューＩＤを有するようにエンコーダがビューをエンコーディングするために再構成され、一方、再構成されたエンコーディング順序に従ってデコーダが従来のＭＶＣ拡張記述子を異なって解釈するように再構成される。例えば、各々がビュー順序インデックス０、１、及び２を有するｖｉｅｗ＿ｉｄ０、１、及び２を備えた３つのビューがあるとする。さらに、サービスがビュー０とビュー２だけを必要とすると仮定する。エンコーダは、ビューをビューＩＤ０、２、１に対応する順序でエンコーディングし得て、それにより、従来のＳＰＳ  ＭＶＣ拡張記述子がｖｉｅｗ＿ｉｄ値を０、２、１の順序でシグナリングするように用いられる。このようにして、ビュー２が１のビュー順序インデックスを有し、それによりビュー０とビュー２の組み合わせが連続的ビュー順序インデックスを有する。
【００５７】
さらに、ＭＶＣのＡＶＣビデオサブビットストリームが存在する場合にプレフィックスＮＡＬユニットの重複を回避するために、本開示は、プレフィックスＭＶＣサブビットストリームが規定されるべきであると提案し、実施例によっては、少なくとも１つのＭＶＣサブビットストリームが存在する場合にそのようなプレフィックスＭＶＣサブビットストリームが含まれる。さらに、本開示は、ベースビューに所属するＭＶＣ特有ＳＥＩメッセージ、即ち、ＡＶＣ仕様のＡｎｎｅｘ  Ｈに規定されているＳＥＩメッセージ、又はＭＶＣビットストリームの全てのビューに適用するＭＶＣ  ＳＥＩメッセージが、記憶サイズ又は帯域幅最適化の観点から効率的な記憶及び転送を可能にするように、この「プレフィックスＭＶＣサブビットストリーム」内で関連付けられ得ることを提案する。本開示はまた、同じ考えが、情報技術の改正３−移動ピクチャ及び関連するオーディオ情報の包括的コーディング：システム（本開示では、「ＭＰＥＧ−２システム」又は「ＭＰＥＧ−２システム標準」と呼ぶ）とも呼ばれるＭＰＥＧ−２システムにおけるスケーラブルビデオの転送に適用され得ることを提案する。
【００５８】
マルチプレクサ３０が受信データからＮＡＬユニット及び／又はアクセスユニットを組み立てた後、マルチプレクサ３０は、このユニットを出力のために出力インターフェース３２に渡す。出力インターフェース３２は、例えば、送信機、トランシーバ、例えば、光学ドライブ、磁気媒体ドライブ（例えば、フロッピー（登録商標）ドライブ）、ユニバーサルシリアルバス（ＵＳＢ）ポート、ネットワークインターフェース、若しくはその他の出力インターフェース等のコンピュータ可読媒体にデータを書き込むためのデバイスを備え得る。出力インターフェース３２は、例えば、送信信号、磁気媒体、光学媒体、メモリ、フラッシュドライブ、又はその他のコンピュータ可読媒体等のコンピュータ可読媒体３４にＮＡＬユニット又はアクセスユニットを出力する。
【００５９】
最終的に、入力インターフェース３６は、コンピュータ可読媒体３４からデータを回収する。入力インターフェース３６は、例えば、光学ドライブ、磁気媒体ドライブ、ＵＳＢポート、受信機、トランシーバ、又はその他のコンピュータ可読媒体インターフェースを備え得る。入力インターフェース３６は、デマルチプレクサ３８にＮＡＬユニット又はアクセスユニットを提供し得る。デマルチプレクサ３８は、転送ストリーム又はプログラムストリームを構成ＰＥＳストリームに逆多重化し、エンコーディングされたデータを回収するためにＰＥＳストリームを逆パケット化し、そして、例えば、ストリームのＰＥＳパケットヘッダに示されるように、エンコーディングされたデータがオーディオストリーム又はビデオストリームの一部であるか否かに基づいて、エンコーディングされたデータをオーディオデコーダ４６又はビデオデコーダ４８のいずれかに送信する。オーディオデコーダ４６は、エンコーディングされたオーディオデータをデコーディングし、このデコーディングされたオーディオデータをオーディオ出力４２に送信し、一方、ビデオデコーダ４８は、エンコーディングされたビデオデータをデコーディングし、ストリームの複数のビューを含み得るデコーディングされたビデオデータをビデオ出力４４に送信する。ビデオ出力４４は、例えば、シーンの各ビューを同時に表示する立体又はオートステレオスコピックのディスプレイ等の、シーンの複数のビューを用いるディスプレイを備え得る。
【００６０】
さらに、例えば、埋め込まれたサブビットストリームの少なくとも１つの、埋め込まれたサブビットストリームが埋め込まれるプライマリ・サブビットストリームのビューのビュー順序インデックスより小さいビュー順序インデックスを備えるビューを、埋め込まれたサブビットストリームの少なくとも１つのビューが有する場合等、ストリームのビュー順序インデックスが厳密に昇順であるように、デマルチプレクサ３８は、１つ又は複数のサブビットストリームのビューを再順序付けする。このようにして、Ａ／Ｖ宛先デバイス４０は、受信したビットストリームからＭＶＣ標準準拠ビットストリームを生成するデマルチプレクサを備える装置に対応する。
【００６１】
図２は、マルチプレクサ３０（図１）の構成要素の例示的な配置を図示するブロック図である。図２の実施例では、マルチプレクサ３０は、ストリーム管理ユニット６０と、ビデオ入力インターフェース８０と、オーディオ入力インターフェース８２と、多重化ストリーム出力インターフェース８４と、プログラム特有情報テーブル８８とを含む。ストリーム管理ユニット６０は、ＮＡＬユニットコンストラクタ６２と、ＰＭＴコンストラクタ６４と、ストリーム識別子（ストリームＩＤ）ルックアップユニット６６と、プログラム識別子（ＰＩＤ）割り当てユニット６８とを含む。
【００６２】
図２の実施例において、ビデオ入力インターフェース８０とオーディオ入力インターフェース８２は、エンコーディングされたビデオデータとエンコーディングされたオーディオデータからＰＥＳユニットを形成するための各パケッタイザを含む。別の実施例では、ビデオパケッタイザ及び／又はオーディオパケッタイザがマルチプレクサ３０の外部に存在してよい。図２の実施例に関して、ビデオ入力インターフェース８０は、ビデオエンコーダ２８から受信したエンコーディングされたビデオデータからＰＥＳパケットを形成し得て、オーディオ入力インターフェース８２は、オーディオエンコーダ２６から受信したエンコーディングされたオーディオデータからＰＥＳパケットを形成し得る。
【００６３】
ストリーム管理ユニット６０は、ビデオ入力インターフェース８０とオーディオ入力インターフェース８２からＰＥＳパケットを受信する。各ＰＥＳパケットは、ＰＥＳパケットが所属する基本ストリームを識別するストリームＩＤを含む。ストリームＩＤルックアップユニット６６は、プログラム特有情報テーブル８８に問合せをすることによってＰＥＳパケットが対応するプログラムを決定し得る。即ち、ストリームＩＤルックアップユニット６６は、受信したＰＥＳパケットがどのプログラムに対応するのかを決定する。各プログラムは、複数の基本ストリームを含むが、一般に、１つの基本ストリームは１つだけのプログラムに対応する。しかしながら、実施例によっては、１つの基本ストリームが複数のプログラムに含まれていてもよい。種々のサービスは、それぞれ利用可能なオーディオストリーム及びビデオストリームの種々のサブセットを含むので、各ＰＥＳパケットは、マルチプレクサ３０からの複数のストリーム出力に含まれる。従って、ストリームＩＤルックアップユニット６６は、ＰＥＳパケットが１つ又は複数の出力ストリーム（例えば、１つ又は複数の転送ストリーム又はプログラムストリーム）に含まれるのかどうかと、特に出力ストリームのいずれにＰＥＳパケットを含むのかと、を決定し得る。
【００６４】
一実施例では、各基本ストリームが１つのプログラムに対応する。マルチプレクサ３０は、各基本ストリームが特定のプログラムに、従って、プログラムＩＤ（ＰＩＤ）に確実に関連付けられるようにする役割を果たす。マルチプレクサ３０によって認識されていないストリームＩＤを含むＰＥＳパケットが受信される（例えば、ストリームＩＤがプログラム特有情報テーブル８８に記憶されていない）場合、新規のストリームＩＤを未使用のＰＩＤに関連付けるために、ＰＩＤ割り当てユニット６８が１つ又は複数の新規エントリをプログラム特有情報テーブル８８に生成する。
【００６５】
ＰＥＳパケットが対応するプログラムを決定した後、ＮＡＬユニットコンストラクタ６２は、例えば、ＰＥＳパケットのストリームＩＤが対応するプログラムのＰＩＤを含むＮＡＬユニットヘッダでＰＥＳパケットをカプセル化することによって、ＰＥＳパケットを含むＮＡＬユニットを形成する。実施例によっては、ＮＡＬユニットコンストラクタ６２又はストリーム管理ユニット６０の別のサブユニットは、複数のＮＡＬユニットを備えるアクセスユニットを形成し得る。
【００６６】
ＰＭＴコンストラクタ６４は、プログラム特有情報テーブル８８からの情報を用いてマルチプレクサ３０の対応する出力ストリームに関するプログラムマップテーブル（ＰＭＴ）を生成する。別の実施例では、ストリーム管理ユニット６０は、マルチプレクサ３０によるプログラムストリーム出力に関するプログラムストリームマップを生成するためのＰＳＭコンストラクタを備え得る。実施例によっては、マルチプレクサ３０は、ＰＭＴコンストラクタ６４とＰＳＭコンストラクタの両方と、転送ストリームとプログラムストリームの一方又は両方の出力とを備え得る。図２の実施例では、ＰＭＴコンストラクタ６４は、本開示によって規定される記述子、例えば、ＭＶＣ拡張記述子及び階層記述子と、任意のその他の必要な記述子と、ＰＭＴに関するＰＭＴデータと、を含むＰＭＴを構築する。ＰＭＴコンストラクタ６４は、周期的に、例えば、所定の時間周期の後又は所定の量のデータが送信された後に、転送ストリームに関する一連のＰＭＴを送る。ＰＭＴコンストラクタ６４は、ＰＭＴを備えるＮＡＬユニットを形成するために、例えば、対応するＰＩＤを含む対応するＮＡＬユニットヘッダでＰＭＴをカプセル化することによって、生成されたＰＭＴをＮＡＬユニットコンストラクタ６２に渡す。
【００６７】
多重化ストリーム出力インターフェース８４は、ストリーム管理ユニット６０から１つ又は複数のＮＡＬユニット及び／又はアクセスユニット、例えば、ＰＥＳパケット（例えば、オーディオデータ又はビデオデータ）を備えるＮＡＬユニット及び／又はＰＭＴを備えるＮＡＬユニットを受信する。実施例によっては、多重化ストリーム出力インターフェース８４は、ＮＡＬユニットがストリーム管理ユニット６０から受信された後の共通の時間位置に対応する１つ又は複数のＮＡＬユニットからアクセスユニットを形成する。多重化ストリーム出力インターフェース８４は、出力としてＮＡＬユニット又はアクセスユニットを、対応する転送ストリーム又はプログラムストリームで送信する。
【００６８】
図３は、プログラム特有情報テーブル８８の例示的なセットを図示するブロック図である。転送パケットが所属する基本ストリームは、転送パケットのＰＩＤ値に基づいて決定される。デコーダが受信したデータを適切にデコーディングするために、デコーダは、どの基本ストリームが各プログラムに所属するかを決定可能である必要がある。プログラム特有情報テーブル８８に含まれるようなプログラム特有情報は、プログラムと構成基本ストリームとの間の関係を明示的に特定しる。図３の実施例では、プログラム特有情報テーブル８８は、ネットワーク情報テーブル１００と、条件付きアクセステーブル１０２と、プログラムアクセステーブル１０４と、プログラムマップテーブル１０６とを含む。図３の実施例の場合、出力ストリームはＭＰＥＧ−２転送ストリームを含むことが仮定されている。代替的な実施例では、プログラムマップテーブル１０６がプログラムストリームマップと置換され得る場合に出力ストリームがプログラムストリームを備える。
【００６９】
ＭＰＥＧ−２システム仕様は、転送ストリームで搬送される全プログラムが、それと関連付けられている、プログラムマップテーブル１０６等のプログラムマップテーブルを有することを規定する。プログラムマップテーブル１０６は、プログラムとそのプログラムが含む基本ストリームとについての詳細を含み得る。一例として、プログラム番号３で特定されるプログラムは、ＰＩＤ３３を備えるビデオ基本ストリームと、ＰＩＤ５７を備える英語オーディオストリームと、ＰＩＤ６０を備える中国語オーディオストリームとを含む。ＰＭＴが２つ以上のプログラムを含むことが許されている。
【００７０】
ＭＰＥＧ−２システム仕様によって規定されている基本プログラムマップテーブルは、多数の記述子のうちのいくつか、例えば、ＭＰＥＧ−２システム仕様内に規定される記述子１０８で装飾される。記述子１０８は、ＭＰＥＧ−２システム仕様の特定の記述子の一部又は全てを含んでよい。一般に、記述子１０８等の記述子は、プログラム又はその構成基本ストリームについてのさらなる情報を搬送する。記述子は、ビデオエンコーディングパラメータ、オーディオエンコーディングパラメータ、言語識別子、パンアンドスキャン情報、条件付きアクセス詳細、著作権情報、又はその他の同様の情報を含んでよい。ブロードキャスター又はその他のユーザは、付加的な自分用の記述子を規定してよい。
【００７１】
この開示は、転送ストリーム又はプログラムストリーム等の出力ストリーム内で非連続ビュー順序インデックスが搬送されることを可能にするために２つの記述子を用いる。図２に示されるように、本開示のこれら２つの記述子は、ＭＶＣ拡張記述子１１０と階層記述子１１２を含む。ビデオ関連構成基本ストリームには、階層的にコーディングされたビデオ、オーディオ、及びプライベートのストリームの構成要素を含むプログラム要素を識別するための情報を提供する階層記述子が同様に存在する。
【００７２】
マルチプレクサ３０の出力がプログラムストリームを備える実施例では、プログラム特有情報テーブル８８がプログラムストリームマップ（ＰＳＭ）を含んでよい。ＰＳＭは、対応するプログラムストリームの基本ストリームの記述子と、基本ストリームの互いの関係とを提供し得る。実施例によっては、プログラムストリームマップがさらに転送ストリームに対応し得る。対応する転送ストリームで搬送される場合、ＰＳＭ構造は修正されるべきではない。マルチプレクサ３０は、ＰＥＳパケットのｓｔｒｅａｍ＿ｉｄ値を０ｘＢＣ、即ち、２進数値１０１１１１００、又は１０進数値１８８に対応する１６進数値ＢＣに設定することによって、ＰＳＭがＰＥＳパケット内に存在することを示し得る。
【００７３】
マルチプレクサ３０は、転送ストリーム内で利用可能な全てのプログラムの完全なリストをプログラム関連付けテーブル１０４に保持する。さらに、マルチプレクサ３０は、プログラム関連付けテーブルをＮＡＬユニットに埋め込み得る。マルチプレクサ３０は、ＮＡＬユニットに０のＰＩＤ値を割り当てることによって、ＮＡＬユニットがプログラム関連付けテーブルを含むことを示す。マルチプレクサ３０は、対応するプログラムマップテーブルを含む転送パケットのＰＩＤ値と共に、プログラム関連付けテーブル１０４に各プログラムをリストアップする。上述と同じ実施例を用いると、プログラム番号３の基本ストリームを規定する例示的なプログラムマップテーブルは、１００１のＰＩＤを有し、別のＰＭＴは１００２の別のＰＩＤを有する。情報のこのセットは、プログラム関連付けテーブル１０４に含まれる。
【００７４】
ネットワーク情報テーブル（ＮＩＴ）と条件付きアクセステーブル（ＣＡＴ）：ＰＡＴで規定されるプログラム番号ゼロは、特別な意味を有する。具体的には、プログラム番号ゼロは、ネットワーク情報テーブルへの手段を示すために用いられる。このテーブルは任意選択であり、存在する場合、チャネル周波数、衛星トランスポンダー詳細、変調特性、サービス発信元、サービス名及び利用可能な代替的ネットワークの詳細等の、転送ストリームを搬送する物理的ネットワークの情報を提供することが意図される。
【００７５】
転送ストリーム内のいずれかの基本ストリームが暗号化される場合、条件付き関連付けテーブルが存在する必要がある。このテーブルは、用いる暗号化システム（複数可）の詳細を提供し、且つ条件付きアクセス管理と権利情報を含む転送パケットのＰＩＤ値を提供する。この情報のフォーマットはＭＰＥＧ−２内には規定されていない。
【００７６】
図４は、ＭＶＣ拡張記述子１１０に含まれ得るデータの例示的なセットを図示するブロック図である。図４の実施例では、ＭＶＣ拡張記述子１１０は、記述子タグフィールド１２０と、記述子長さフィールド１２２と、平均ビットレートフィールド１２４と、最大ビットレートフィールド１２６と、予約済フィールド１２８と、時間識別子（ＩＤ）開始フィールド１３０と、時間ＩＤ終了フィールド１３２と、追加拡張情報（ＳＥＩ）なしＮＡＬユニット存在フィールド１３４と、１つ又は複数のビュー順序インデックスフィールド１３６と、１つ又は複数の予約済トレーリング（trailing）ビットフィールド１３８とを含む。さらに、ＭＶＣ拡張記述子１１０は、ＭＶＣサブビットストリームに対応する動作点を規定する。以下のＭＶＣ拡張記述子１１０のフィールドのビット深さは、ＭＶＣ拡張記述子に関する一実施例に対応する。別の実施例は、対応するビットストリーム若しくはサブビットストリームに含まれる各ビューの各ビュー順序インデックスを個別にシグナリングするための別のビット深さ、値、又は範囲を含む。
【００７７】
記述子タグフィールド１２０は、ＭＰＥＧ−２システム標準に規定されるように、記述子を具体的に識別するために全ての記述子に含まれる８ビット記述子タグフィールドに対応する。ＭＰＥＧ−２システム標準は、所定の記述子タグを規定し、「予約済」として、例えば、３６〜６３の値等、別の記述子タグ値をマークする。本開示の技術は、ＭＶＣ拡張記述子１１０の記述子タグフィールド１２０の値を、ＭＰＥＧ−２システム仕様に規定されるように予約済記述子タグのうちの１つに対応する「４９」に設定することを提案する。
【００７８】
記述子長さフィールド１２２は、ＭＰＥＧ−２システム標準に示されるように、全ての記述子に同様に含まれる８ビット記述子長さフィールドに対応する。マルチプレクサ３０は、記述子長さフィールド１２２の直後のＭＶＣ拡張記述子１１０のバイト数と等しい記述子長さフィールド１２２の値を設定する。ＭＶＣ拡張記述子１１０は、例えば、ＭＶＣ拡張記述子１１０の特定のインスタンスに含まれるビュー順序インデックス１３６の数に基づいて可変な長さを備え得るので、マルチプレクサ３０がＭＶＣ拡張記述子１１０のインスタンスのサイズを計算し、それに応じて記述子のインスタンスの記述子長さフィールド１２２の値を設定する。
【００７９】
平均ビットレートフィールド１２４は、再組み立てされたＡＶＣビデオストリームの秒毎のキロビットでの平均ビットレートを示す１６ビットフィールドを備える。即ち、平均ビットレートフィールド１２４は、ビデオストリームが転送ストリーム又はプログラムストリームの構成部分から対応するＭＶＣ拡張記述子１１０へと組み立てられる際のビデオストリームの平均ビットレートを表現する。実施例によっては、ＭＶＣ拡張記述子１１０によって平均ビットレートが示されていないことを示すために、マルチプレクサ３０が平均ビットレートフィールド１２４の値をゼロに設定し得る。
【００８０】
最大ビットレートフィールド１２６は、再組み立てされたＡＶＣビデオストリームの秒毎のキロビットでの最大ビットレートを示す１６ビットフィールドを備える。即ち、最大ビットレートフィールド１２６は、ビデオストリームが転送ストリーム又はプログラムストリームの構成部分から対応するＭＶＣ拡張記述子１１０へと組み立てられる際のビデオストリームの最大ビットレートを表現する。実施例によっては、ＭＶＣ拡張記述子１１０によって最大ビットレートが示されていないことを示すために、マルチプレクサ３０が最大ビットレートフィールド１２６の値をゼロに設定する。
【００８１】
時間ＩＤ開始フィールド１３０は、関連付けられたＭＶＣビデオサブビットストリームに含まれる全てのＮＡＬユニットのＮＡＬユニットヘッダシンタックス要素のｔｅｍｏｐｒａｌ＿ｉｄの最小値を示す３ビットフィールドを備える。即ち、時間ＩＤ値は、各ＮＡＬユニットに関するヘッダに含まれる。一般に、時間ＩＤ値は特定のフレームレートに対応し、この場合は比較的により大きい時間ＩＤ値がより高いフレームレートに対応する。例えば、時間ＩＤに対する「０」の値が１５フレーム毎秒（ｆｐｓ）のフレームレートに対応し、時間ＩＤに対する「１」の値が３０ｆｐｓのフレームレートに対応してもよい。このようにして、０の時間ＩＤを有する全てのピクチャを、この実施例では、セットに集めることが、１５ｆｐｓのフレームレートを有するビデオセグメントを形成するために用いられてよいのに対し、０の時間ＩＤを有する全てのピクチャと１の時間ＩＤを有する全てのピクチャとを別のセットに集めることが、３０ｆｐｓのフレームレートを有する異なるビデオセグメントを形成するために用いられてよい。マルチプレクサ３０は、ＭＶＣビデオサブビットストリームの全てのＮＡＬユニットの最小の時間ＩＤを決定し、この決定された最小の時間ＩＤ値と等しい時間ＩＤ開始フィールド１３０の値を設定する。
【００８２】
時間ＩＤ終了フィールド１３２は、関連付けられたＭＶＣビデオサブビットストリームに含まれる全てのＮＡＬユニットのＮＡＬユニットヘッダシンタックス要素の時間ＩＤの最大値を示す３ビットフィールドを備える。従って、マルチプレクサ３０は、ＭＶＣビデオサブビットストリームの全てのＮＡＬユニットの最大の時間ＩＤを決定し、この決定された最大の時間ＩＤ値と等しい時間ＩＤ開始フィールド１３０の値を設定する。
【００８３】
ＳＥＩなしＮＡＬユニット存在フィールド１３４は、「１」に設定された場合に関連付けられたビデオサブビットストリームに追加拡張情報（supplemental enhancement information）ＮＡＬユニットが存在しないことを示す１ビットフラグを備える。マルチプレクサ３０は、１つ又は複数の追加拡張情報ＮＡＬユニットがビットストリーム内に配置されたか否かを決定し、ビットストリームにＳＥＩ  ＮＡＬユニットが存在しない場合にＳＥＩなしＮＡＬユニット存在フィールド１３４の値を「１」の値に設定するが、ビットストリームに少なくとも１つのＳＥＩ  ＮＡＬユニットが存在する場合にはＳＥＩなしＮＡＬユニット存在フィールド１３４の値を「０」の値に設定する。
【００８４】
一態様では、本開示の技術が、以下の表１に示されるようなループを用いて示される１つ又は複数のビュー順序インデックスフィールド１３６を含むような、従来のＭＶＣ拡張記述子の修正を説明する。ビュー順序インデックスフィールド１３６の各々１つは、関連付けられたＭＶＣビデオサブビットストリームに含まれるＮＡＬユニットの１つに対応するビュー順序インデックスの値を示す１０ビットフィールドを備える。マルチプレクサ３０は、ＭＶＣビデオサブビットストリームに含まれるビューのビュー順序インデックスに従ってビュー順序インデックスフィールド１３６の値を設定し得る。さらに、ビュー順序インデックスフィールド１３６の値は、昇順でシグナリングされ得る。このようにして、ＭＶＣ拡張記述子１１０がＭＶＣビデオサブビットストリームに含まれるビューの非連続ビュー順序インデックスを表現し得る。
【００８５】
図４の実施例では、ＭＶＣ拡張記述子１１０は、予約済トレーリングビットフィールド１３８をさらに含む。本開示は、これらの値が必ずしもどのようにして用いられるかを規定することなしに将来の目的のためにこれらのビットを予約することを説明する。種々の実施例で、予約済トレーリングビットは、ＭＶＣ拡張記述子１１０のビットの１つの単一の連続的な予約済のセグメントとして、又は複数の別個のビットのループとして示され得る。
【００８６】
以下の表１は、本開示のＭＶＣ拡張記述子１１０のシンタックス要素を説明する。表１はまた、各シンタックス要素に関して、シンタックス要素を表現するのに用いられるビットの数と、シンタックス要素のタイプを表現するニーモニックとを説明する。ビットの数は、ＭＶＣ拡張記述子１１０がコーディングされたビットストリームに送信される際に対応するシンタックス要素に割り当てられるビットの数に対応する。ニーモニックは、コーディングされたビットストリームで用いられる種々のデータのタイプを表現するためにＭＰＥＧ−２システム標準で用いられている。本開示で用いられるニーモニックは、ＭＰＥＧ−２システム標準が先頭に最上位ビットを有する符号なし整数として規定する「ｕｉｍｓｂｆ」と、ＭＰＥＧ−２システム標準が左ビット先頭の、ここで「左」はビットストリングがＭＰＥＧ−２システム標準で書き込まれる順序である、ビットストリングとして規定する「ｂｓｌｂｆ」とを含む。表１の実施例のシンタックス要素の各々は、ＭＶＣ拡張記述子１１０に関して上述されたシンタックス要素の各々１つに対応する。特に、本開示は、プログラムストリーム又は転送ストリームの各ビューに対するビュー順序インデックスを具体的にシグナリングするための「ｆｏｒ」ループを表１で提供する。このようにして、表１のＭＶＣ拡張記述子の「ｆｏｒ」ループは、対応するＭＰＥＧ−２システム標準ビットストリームが第１のビュー順序インデックスに関連付けられたシーンの第１のビューと、第２のビュー順序インデックスに関連付けられたシーンの第２のビューとを備え、第１のビュー順序インデックスと第２のビュー順序インデックスが非連続であることをシグナリングするために用いられ得る。
【表１】
2013502089.tif 000003
【００８７】
別の実施例では、予約済トレーリングビットが代わりに個別にシグナリングされ得る。以下の表２は、予約済トレーリングビットの各々が個別にシグナリングされる例示的なＭＶＣ拡張記述子を示している。
【表２】
2013502089.tif 000004
【００８８】
図５は、階層記述子１１２に含まれ得るデータの例示的なセットを図示するブロック図である。図５の実施例では、階層記述子１１２は、記述子タグフィールド１５０と、記述子長さフィールド１５２と、ビュー拡張フラグフィールド１５４と、時間スケーラビリティフラグフィールド１５６と、空間スケーラビリティフラグフィールド１５８と、品質スケーラビリティフラグフィールド１６０と、階層タイプフィールド１６２と、予約済フィールド１６４と、階層レイヤインデックスフィールド１６６と、ＴＲＥＦ存在フラグフィールド１６８と、予約済フィールド１７０と、階層埋め込みレイヤインデックスフィールド１７２と、予約済フィールド１７４と、階層チャネルフィールド１７６と、を含む。シグナリング、ビュースケーラビリティ及び／又はビュー依存性関係を改善するために、本開示の技術は、関連付けられたプログラム要素が、ｈｉｅｒａｒｃｈｙ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘによって参照されるプログラム要素から生じるビットストリームのビューの数を増大させるか否かを示す、階層記述子の１つのフラグがシグナリングされることを実現し得る。
【００８９】
上述したように、ＭＰＥＧ−２システム仕様は、各記述子が記述子タグフィールドと記述子長さフィールドとを含むことを規定する。従って、階層記述子１１２は、記述子タグフィールド１５０と記述子長さフィールド１５２とを含む。ＭＰＥＧ−２システム仕様に従って、マルチプレクサ３０が記述子タグフィールド１５０の値を階層記述子１１２に関する「４」の値に設定する。
【００９０】
階層記述子１１２の各インスタンスが同じ量のデータを含む必要があるので、階層記述子１１２の長さは事前に決定され得る。以下の表３に関連する一実施例では、マルチプレクサ３０が、記述子長さフィールド１５２の値を、記述子長さフィールド１５２の末尾の後の階層記述子１１２のインスタンスのビットの数を示す３２の値に設定する。
【００９１】
本開示の技術は、従来の階層記述子にビュー拡張フラグフィールド１５４を付加することを提案する。本開示の技術に従って、ビュー拡張フラグフィールド１５４は、「０」に設定された場合に、関連付けられたプログラム要素が階層埋め込みレイヤインデックスによって参照されるプログラム要素から生じるビットストリームのビューの数を拡張することを示す、１ビットフラグを備え得る。本開示の技術は、ビュー拡張フラグフィールド１５４に対して「１」の値を予約することをさらに提案する。
【００９２】
階層タイプフィールド１６２は、関連付けられた階層のレイヤとその階層埋め込みレイヤとの間の階層関係を表現する。一実施例では、マルチプレクサ３０が、例えば、以下の表４によって説明されるような階層関係に基づいて階層タイプフィールド１６２の値を設定する。一実施例では、スケーラビリティが２つ以上の次元に適用される場合、マルチプレクサ３０が階層タイプフィールド１６２の値を「８」（表４に示されるように「結合されたスケーラビリティ」）の値に設定し得て、マルチプレクサ３０は、各ストリームのＰＥＳパケットとＰＥＳパケットヘッダから回収されたデータに従って時間スケーラビリティフラグフィールド１５６、空間スケーラビリティフラグフィールド１５８、及び品質スケーラビリティフラグフィールド１６０の値を設定する。一般に、マルチプレクサ３０は、種々のビュー及び／又はオーディオデータストリームに対応する異なるストリームの間の依存性を決定し得る。マルチプレクサ３０は、拡張レイヤを備える依存性ストリームが空間レイヤ、信号対雑音（ＳＮＲ）拡張レイヤ、品質向上レイヤ、又はその他のタイプの拡張レイヤであるかどうかをさらに決定し得る。
【００９３】
別の実施例として、ＭＶＣビデオサブビットストリームに関して、マルチプレクサ３０が、階層タイプフィールド１６２を「９」（表４に示されるように「ＭＶＣ」）の値に設定し、スケーラビリティフラグフィールド１５６、空間スケーラビリティフラグフィールド１５８、及び品質スケーラビリティフラグフィールド１６０のそれぞれの値を「１」に設定し得る。さらに別の実施例として、ＭＶＣベースビューサブビットストリームに関して、マルチプレクサ３０が、階層タイプフィールド１６２の値を「１５」の値に設定し得て、スケーラビリティフラグフィールド１５６、空間スケーラビリティフラグフィールド１５８、及び品質スケーラビリティフラグフィールド１６０の値を「１」に設定し得る。さらに別の実施例として、プレフィックスＭＶＣサブビットストリームに関して、マルチプレクサ３０が、階層タイプフィールド１６２を「１４」の値に設定し得て、スケーラビリティフラグフィールド１５６、空間的スケーラビリティフラグフィールド１５８、及び品質スケーラビリティフラグフィールド１６０を「１」に設定し得る。
【００９４】
階層レイヤインデックスフィールド１６６は、コーディングされたレイヤの階層のテーブルの関連付けられたプログラム要素の固有インデックスを規定する６ビットフィールドを備え得る。インデックスは、単一のプログラム規定内では固有であり得る。ＩＴＵ−Ｔ  Ｒｅｃ．Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０のＡｎｎｅｘ  Ｇに規定される１つ又は複数のプロファイルに準拠するビデオストリームのＡＶＣのビデオサブビットストリームの場合、これは、プログラム要素インデックスであり、このプログラム要素インデックスは、同じアクセスユニットのビデオサブビットストリームの関連付けられたＳＶＣ依存性表現がｈｉｅｒａｒｃｈｙ＿ｌａｙｅｒ＿ｉｎｄｅｘの昇順で再組み立てされる場合にビットストリーム順序が正しくなるようなやり方で割り当てられる。ＩＴＵ−Ｔ  Ｒｅｃ．Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０のＡｎｎｅｘ  Ｈに規定される１つ又は複数のプロファイルに準拠するＡＶＣビデオストリームのＭＶＣビデオサブビットストリームの場合、これは、これらの値のいずれもがプレフィックスＭＶＣサブビットストリームに関する階層記述子に規定されるｈｉｅｒａｒｃｈｙ＿ｌａｙｅｒ＿ｉｎｄｅｘの値より大きくなるやり方で割り当てられるプログラム要素インデックスである。
【００９５】
階層埋め込みレイヤインデックスフィールド１７２は、階層記述子１１２の対応するインスタンスに関連付けられた基本ストリームをデコーディングする前にアクセスされる必要のあるプログラム要素の階層テーブルインデックスを規定する６ビットフィールドを備え得る。本開示は、階層タイプフィールド１６２が１５（即ち、ベースレイヤに対応する値）の値を有する場合についての階層埋め込みレイヤインデックスフィールド１７２に関する値を未定義のままにする。
【００９６】
階層チャネルフィールド１７６は、送信チャネルの順序付けされたセットの関連付けられたプログラム要素に対する意図されたチャネル番号を示す６ビットフィールドを備え得る。最もロバストな送信チャネルは、全体の送信階層規定に対して階層チャネルフィールド１７６の最低値によって規定される。所与の階層チャネルが同時に複数のプログラム要素に割り当てられることに注意されたい。
【００９７】
予約済フィールド１６４、１７０及び１７４は、将来の標準開発による将来の使用のために予約されている。本開示の技術は、予約済フィールド１６４、１７０及び１７４の値に意味的意味を割り当てることを現時点では提案しない。
【００９８】
タイムスタンプ参照（ＴＲＥＦ）存在フラグフィールド１６８は、対応するＰＥＳパケットヘッダにＴＲＥＦフィールドが存在するか否かを示す１ビットフィールドである。ＰＥＳパケットのＴＲＥＦフィールドは、３つの別個のフィールドにコーディングされた３３ビットの数である。ＴＲＥＦフィールドは、ＤＴＳによって、又はＤＴＳが存在しない場合には対応する基本ストリームｎの同じｊ番目のアクセスユニットのＰＥＳヘッダのＰＴＳによって示されるようなシステムターゲットデコーダにおける、デコーディング時間値を示す。
【００９９】
以下の表３は、本開示の階層記述子１１２のシンタックス要素を説明する。さらに、表３は、各シンタックス要素について、シンタックス要素を表現するのに用いられるビットの数と、シンタックス要素に関するタイプを説明するニーモニックとを提供する。ビットの数は、階層記述子１１２がコーディングされたビットストリームに送信された際の対応するシンタックス要素に割り当てられているビットの数に対応する。ニーモニックは、コーディングされたビットストリームで用いられる種々のデータのタイプを説明するためにＭＰＥＧ−２システム標準で用いられる。本開示で用いられるニーモニックは、ＭＰＥＧ−２システム標準が先頭に最上位ビットを有する符号なし整数として定義する「ｕｉｍｓｂｆ」と、ＭＰＥＧ−２システム標準が左ビットが先頭のビットストリングとして定義する「ｂｓｌｂｆ」とを含み、ここで「左」はビットストリングがＭＰＥＧ−２システム標準で書き込まれる順序である。表３の実施例のシンタックス要素の各々は、階層記述子１１２に関して上述されたシンタックス要素の各々１つに対応する。
【表３】
2013502089.tif 000005
【０１００】
以下の表４は、階層記述子１１２の階層タイプフィールド１６２に関する種々の潜在的な値と各値に関する意味とを説明する。本開示は、階層タイプフィールド１６２に対し、対応するビットストリームの説明として「プレフィックスＭＶＣサブビットストリーム」の説明を備える「１４」の潜在的な値を付加することを提案する。本開示の技術は、プレフィックスＭＶＣサブビットストリームが、２０と等しいｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ（即ち、ＮＡＬユニットのタイプの値）を備える全てのプレフィックスＮＡＬユニットと、ＭＶＣのＡＶＣビデオサブビットストリームで再組み立てされた後に、ＩＴＵ−Ｔ  Ｒｅｃ．Ｈ．２６４｜ＩＳＯ／ＩＥＣ１４４９６−１０のＡｎｎｅｘ  Ｈに規定される１つ又は複数のプロファイルに準拠する、関連付けられた非ＶＣＬ  ＮＡＬユニットと、を備えることを規定する。本開示の技術は、ＭＶＣのＡＶＣビデオサブビットストリームが存在する場合、プレフィックスＭＶＣサブビットストリームが同様に存在するべきであることをさらに提案する。
【表４】
2013502089.tif 000006
【０１０１】
いくつかの例において、階層記述子１１２が、増分サブビットストリームと埋め込まれたサブビットストリームによってシグナリングされたＭＶＣサブビットストリームをシグナリングするのに用いられる。埋め込まれたサブビットストリームは、ｈｉｅｒａｒｃｈｙ＿ｅｍｂｅｄｄｅｄ＿ｌａｙｅｒ＿ｉｎｄｅｘに対応する直接依存性サブビットストリームと、この直接依存性サブビットストリームの全ての埋め込まれたサブビットストリームとを含む。本開示では、明示的に含まれるビューは拡張ビューと呼ばれ、一方、埋め込まれたビューは依存性ビューと呼ばれる。
【０１０２】
図６は、例示的なＭＶＣ予測パターンを図示する概念図である。図６の実施例では、（「Ｓ０」から「Ｓ７」のビューＩＤを有する）８つのビューが示され、各ビューに対する１２個の時間的位置（「Ｔ０」から「Ｔ１１」）が示されている。即ち、図６の各行がビューに対応し、一方、各列が時間的位置を示す。
【０１０３】
ＭＶＣは、Ｈ．２６４／ＡＶＣデコーダによってデコーディングされるいわゆるベースビューと、ＭＶＣによって同様にサポートされ得るステレオビューペアとを有するが、ＭＶＣの利点は、３つ以上のビューを３Ｄビデオ入力として用いて、複数のビューによって表現されるこの３Ｄビデオをデコーディングする例をサポートすることが可能な点である。ＭＶＣデコーダを有するクライアントのレンダラは、複数のビューを備える３Ｄビデオコンテンツを期待し得る。
【０１０４】
図６のフレームは、文字を含む陰影付きブロックを用いて図６の各行及び各列の表示によって示されており、対応するフレームがイントラコーディングされている（即ち、Ｉ−フレーム）か、又は１つの方向でインターコーディングされている（即ち、Ｐ−フレームとして）か、又は複数の方向である（即ち、Ｂ−フレームとして）かが指定されている。一般に、予測は矢印で示され、ポイント先のフレームはポイント元のオブジェクトを予測参照に用いる。例えば、時間位置Ｔ０でのビューＳ２のＰ−フレームは、時間位置Ｔ０でのビューＳ０のＩ−フレームから予測される。
【０１０５】
単一のビュービデオエンコーディングと同様に、マルチビュービデオコーディングビデオシーケンスのフレームは、種々の時間位置でのフレームに対して予測的にエンコーディングされる。例えば、時間位置Ｔ１でのビューＳ０のｂ−フレームは、時間位置Ｔ０でのビューＳ０のＩ−フレームからポイントされた矢印を有し、当該ｂ−フレームが当該Ｉ−フレームから予測されることを示す。しかしながら、さらに、マルチビュービデオエンコーディングにおいては、フレームがインタービュー予測され得る。即ち、ビュー構成要素が別のビューのビュー構成要素を参照として用い得る。例えば、ＭＶＣでは、別のビューのビュー構成要素がインター予測参照であるかのようにインタービュー予測が実現されている。潜在的なインタービュー参照は、シーケンスパラメータセット（ＳＰＣ）ＭＶＣ拡張でシグナリングされ、インター予測参照又はインタービュー予測参照の柔軟な順序付けを可能にする参照ピクチャリスト構築プロセスによって修正され得る。以下の表５は、ＭＶＣ拡張シーケンスパラメータセットに関する例示的な定義を提供する。
【表５】
2013502089.tif 000007
【０１０６】
図６は、インタービュー予測の種々の実施例を提供する。図６の実施例で、ビューＳ１のフレームは、ビューＳ１の異なる時間位置でのフレームから予測され、同様に、同じ時間位置でのビューＳ０及びＳ２のフレームのフレームからインタービュー予測されることが示されている。例えば、時間位置Ｔ１でのビューＳ１のｂ−フレームが時間位置Ｔ０及びＴ２でのビューＳ１のＢ−フレームの各々から予測され、同様に、時間位置Ｔ１でのビューＳ０及びＳ２のｂ−フレームから予測される。
【０１０７】
図６の実施例では、大文字「Ｂ」と小文字「ｂ」は、異なるエンコーディング方法ではなく、フレーム間の異なる階層的関係を示すことを意図している。一般に、大文字「Ｂ」のフレームは、小文字「ｂ」のフレームより予測階層が相対的に高い。さらに、図６は、陰影の異なるレベルを用いて予測階層の変動を図示し、陰影の量の多い（即ち、相対的により暗い）フレームの予測階層は、陰影の少ない（即ち、相対的により明るい）フレームの予測階層よりも高い。例えば、図６の全てのＩ−フレームは完全に陰影付けされているのに対し、Ｐ−フレームは若干より明るい陰影付けであり、Ｂ−フレーム（及び小文字のｂ−フレーム）は互いに対して陰影付けの種々のレベルを有するがＰ−フレームとＩ−フレームの陰影付けより常に明るい。
【０１０８】
一般に、階層の相対的に低いフレームをデコーディングする際に階層の相対的に高いフレームが参照フレームとして用いられ得るように、予測階層で相対的により高いフレームが階層の相対的により低いフレームがデコーディングされる前にデコーディングされる必要があるという点で、予測階層はビュー順序インデックスに関係する。ビュー順序インデックスは、アクセスユニットにおいてビュー構成要素のデコーディング順序を示すインデックスである。Ｈ．２６４／ＡＶＣ（ＭＶＣ改訂）のＡｎｎｅｘ  Ｈに規定されるように、ビュー順序インデックスは、ＳＰＳ  ＭＶＣ拡張に示唆されている。ＳＰＳでは、各インデックスｉに対し、対応するｖｉｅｗ＿ｉｄがシグナリングされる。ビュー構成要素のデコーディングは、ビュー順序インデックスの昇順に従う必要がある。全てのビューが存在する場合、ビュー順序インデックスは０からｎｕｍ＿ｖｉｅｗｓ＿ｍｉｎｕｓ＿１の連続順序になっている。
【０１０９】
このようにして、参照フレームとして用いられるフレームは、参照フレームを参照してエンコーディングされるフレームがデコーディングされる前にデコーディングされ得る。ビュー順序インデックスは、アクセスユニットのビュー構成要素のデコーディング順序を示すインデックスである。各ビュー順序インデックスｉに対し、対応するｖｉｅｗ＿ｉｄがシグナリングされる。ビュー構成要素のデコーディングは、ビュー順序インデックスの昇順に従う。全てのビューが存在する場合、ビュー順序インデックスのセットは、０からビューの総数から１を引いた数までの連続的に順序付けされたセットを備える。
【０１１０】
階層の等しいレベルの所定のフレームの場合、デコーディング順序が互いに対してどうなっていてもよい場合がある。例えば、時間位置Ｔ０でのビューＳ０のＩ−フレームが、時間位置Ｔ０でのビューＳ２のＰ−フレームに関する参照フレームとして用いられ、時間位置Ｔ０でのビューＳ２のＰ−フレームが時間位置Ｔ０でのビューＳ４のＰ−フレームに関する参照フレームとして用いられる。従って、時間位置Ｔ０でのビューＳ０のＩ−フレームは時間位置Ｔ０でのビューＳ２のＰ−フレームの前にデコーディングされる必要があり、時間位置Ｔ０でのビューＳ２のＰ−フレームは時間位置Ｔ０でのビューＳ４のＰ−フレームの前にデコーディングされる必要がある。しかしながら、ビューＳ１とＳ３は予測に関して互いに依存せず、その代わりに予測階層のより高いビューからだけ予測されるので、ビューＳ１とＳ３の間ではデコーディング順序がどうなっていてもよい。さらに、ビューＳ１がビューＳ０とＳ２の後にデコーディングされる限りは、ビューＳ１がビューＳ４の前にデコーディングされてよい。
【０１１１】
このようにして、階層順序付けがビューＳ０からＳ７を説明するのに用いられ得る。表記ＳＡ＞ＳＢは、ビューＳＡがビューＳＢの前にデコーディングされる必要があることを意味すると仮定する。この表記を用いて、図６の実施例で、Ｓ０＞Ｓ２＞Ｓ４＞Ｓ６＞Ｓ７である。さらに、図６の実施例に関して、Ｓ０＞Ｓ１、Ｓ２＞Ｓ１、Ｓ２＞Ｓ３、Ｓ４＞Ｓ３、Ｓ４＞Ｓ５、且つＳ６＞Ｓ５である。この要件に違反しない、ビューに対する任意のデコーディング順序が可能である。従って、所定の制限だけで、多数の異なるデコーディング順序が可能である。２つの例示的なデコーディング順序が以下に示されているが、多くの他のデコーディング順序が可能であることを理解されたい。以下の表６に示されている一実施例では、ビューは可能な限り早くデコーディングされる。
【表６】
2013502089.tif 000008
【０１１２】
表６の例は、ビューＳ１はビューＳ０とＳ２がデコーディングされた直後にデコーディングされ、ビューＳ３はビューＳ２とＳ４がデコーディングされた直後にデコーディングされ、ビューＳ５はビューＳ４とＳ６がデコーディングされた直後にデコーディングされることを認める。
【０１１３】
以下の表７は、別のビューに関する参照として用いられるあらゆるビューが、別のビューに関する参照として用いられていないビューの前にデコーディングされるようにデコーディング順序がなっている、別の例示的なデコーディング順序を提供する。
【表７】
2013502089.tif 000009
【０１１４】
表７の例は、ビューＳ１、Ｓ３、Ｓ５及びＳ７のフレームが任意の他のビューのフレームに対する参照フレームとして機能せず、それゆえに、ビューＳ１、Ｓ３、Ｓ５及びＳ７は、参照フレームとして用いられるビュー、即ち、図６の実施例のビューＳ０、Ｓ２、Ｓ４、及びＳ６のフレームの後にデコーディングされることを認める。ビューＳ１、Ｓ３、Ｓ５及びＳ７は、互いに関して任意の順序でデコーディングされ得る。従って、表７の実施例では、ビューＳ１、Ｓ３及びＳ５の各々の前にビューＳ７がデコーディングされる。
【０１１５】
明確にするために、各ビューのフレームの時間位置と同様に、各ビューのフレームの間に階層関係が存在し得る。図６の実施例に関し、時間位置Ｔ０でのフレームは、時間位置Ｔ０での他のビューのフレームからイントラ予測又はインタービュー予測のいずれかがされる。同様に、時間位置Ｔ８でのフレームは、時間位置Ｔ８での他のビューのフレームからイントラ予測又はインタービュー予測のいずれかがされる。従って、時間的階層に関し、時間位置Ｔ０及びＴ８は時間的階層の最上部である。
【０１１６】
図６の実施例で、時間位置Ｔ４のフレームは時間位置Ｔ０及びＴ８のフレームを参照してＢ−エンコーディングされるので、時間位置Ｔ４でのフレームは時間的階層において時間位置Ｔ０及びＴ８のフレームより低い。時間位置Ｔ２及びＴ６でのフレームは時間的階層において時間位置Ｔ４でのフレームよりより低い。最終的に、時間位置Ｔ１、Ｔ３、Ｔ５及びＴ７でのフレームは時間位置Ｔ２及びＴ６のフレームより時間的階層においてより低い。
【０１１７】
ＭＶＣで、全ビットストリームのサブセットが、それでもなおＭＶＣに準拠するサブビットストリームを形成するように抽出され得る。例えば、サーバによって提供されるサービス、１つ又は複数のクライアントのデコーダの容量、サポート、及び機能、および／又は１つ又は複数のクライアントの嗜好に基づいて特定のアプリケーションが要求し得る多くの可能なサブビットストリームが存在する。例えば、クライアントが３つのビューだけを要求してよく、２つのシナリオが存在する可能性がある。一実施例では、一方のクライアントがスムースビューイング体験を要求し、ｖｉｅｗ＿ｉｄ値Ｓ０、Ｓ１、及びＳ２を備えるビューを好む可能性があり、一方、他方の別のクライアントはビュースケーラビリティを要求し、ｖｉｅｗ＿ｉｄ値Ｓ０、Ｓ２、及びＳ４を備えるビューを好む可能性がある。元々ｖｉｅｗ＿ｉｄが表６の実施例に関して順序付けされている場合、これらの２つの例でのビュー順序インデックス値は各々｛０，１，２｝と｛０，１，４｝である。これらのサブビットストリームの両方が、独立したＭＶＣビットストリームとしてデコーディングされ得て、同時にサポートされ得ることに注意されたい。
【０１１８】
図７は、非連続ビュー順序インデックスを備えるビューのサブセットを有するＭＰＥＧ−２システムストリームをサーバからクライアントに送るための例示的な方法を図示するフローチャートである。図７の方法は、例示目的として、Ａ／Ｖソースデバイス２０とＡ／Ｖ宛先デバイス４０に関連して説明されるが、別の実施例で図７の方法が実行され得ることを理解されたい。図７の実施例では、「サーバ」に起因する動作がＡ／Ｖソースデバイス２０によって実行され得るのに対し、「クライアント」によって実行される動作がＡ／Ｖ宛先デバイス４０によって実行され得る。
【０１１９】
図７の実施例では、Ａ／Ｖソースデバイス２０によって提供されるサービスに基づいて、Ａ／Ｖソースデバイス２０がＡ／Ｖ宛先デバイス４０に送るために利用可能なビューのサブセットを最初に決定する（２００）。上述されたように、一般に、１つのサービスが複数のビューの選択を備える。図６の実施例に関連して、サービスがビューＳ０、Ｓ２、及びＳ４を備え得る。これらのビューのビュー順序インデックスが表６によって規定されたビュー順序インデックスであると仮定すると、実施例のように、ビューＳ０、Ｓ２及びＳ４に対するビュー順序インデックスがビュー順序インデックス０、１、及び３を備え得る。図７の方法の残りの議論は、これらのビューＩＤとビュー順序インデックスを説明目的での例として用いる。
【０１２０】
次に、Ａ／Ｖソースデバイス２０は、サービスの提供の一部として送られると決定されたビューに基づいてプログラムマップテーブル（ＰＭＴ）を準備する（２０２）。具体的には、Ａ／Ｖソースデバイス２０によって提供されるサービスに対応する１つ又は複数のプログラムに対して、プログラム特有情報テーブル８８から回収される情報に基づいてマルチプレクサ３０のＰＭＴコントラクタ６４がＰＭＴを準備する。本開示の技術によれば、ＰＭＴの準備は、ＭＶＣ拡張記述子１１０と階層記述子１１２の生成を含む。
【０１２１】
ＭＶＣ拡張記述子１１０を生成するために、マルチプレクサ３０のＰＭＴコントラクタ６４は、記述子タグフィールド１２０を「４９」と等しく設定する。ＰＭＴコントラクタ６４は、プログラム特有情報テーブル８８により記憶されているようなプログラムのプログラム特有データに従って、平均ビットレートフィールド１２４と、最大ビットレートフィールド１２６と、時間ＩＤ開始フィールド１３０と、時間ＩＤ終了フィールド１３２と、ＳＥＩなしＮＡＬユニット存在フィールド１３４との値を設定する。さらに、ＰＭＴコントラクタ６４は、選択されたビューのビュー順序インデックスに従って、ビュー順序インデックスフィールド１３６の値を設定する。上述された実施例では、ＰＭＴコンストラクタ６４は、ビュー順序インデックス０、１、及び３を表す３つのビュー順序インデックスフィールド値を含む。このようにして、この実施例は、プログラムのビューの各ビュー順序インデックスを個別に示すＭＶＣ拡張記述子を提供する。さらに、ビュー順序インデックス「２」がスキップされるため、この実施例は、ビュー順序インデックスが非連続である例である。
【０１２２】
階層記述子１１２を生成するために、ＰＭＴコンストラクタ６４は、プログラム特有情報テーブル８８に従って階層記述子１１２のフィールドの値を設定する。本開示の技術によれば、ＰＭＴコンストラクタ６４は、さらに、関連付けられたプログラム要素が階層埋め込みレイヤインデックスフィールド１７２の値によって参照されるプログラム要素から生じるビットストリームのビューの数を拡張することを示すために、ビュー拡張フラグフィールド１５４の値を「０」の値に設定する。
【０１２３】
ＰＭＴを生成した後、Ａ／Ｖソースデバイス２０が、例えば、ＮＡＬユニットの形態で、ＰＭＴをＡ／Ｖ宛先デバイス４０に送信し得る（２０４）。実施例によっては、Ａ／Ｖソースデバイス２０が周期的に、例えば、所定の時間間隔の後又は特定の量のデータが送られた後に、ＰＭＴをＡ／Ｖ宛先デバイス４０に再送信してよい。Ａ／Ｖ宛先デバイス４０は、ＰＭＴからのプログラム情報をクライアント側記憶媒体に記録し、これはマルチプレクサ３０のプログラム特有情報テーブル８８を本質的にミラーリングし得る（２０８）。例えば、デマルチプレクサ３８は、マルチプレクサ３０のプログラム特有情報テーブル８８と同様のプログラム特有情報テーブルのセットを備える。送信されたＰＭＴ等のプログラム特有情報の受信に応じて、デマルチプレクサ３８は、デマルチプレクサ３８のプログラム特有情報テーブルを更新する。
【０１２４】
マルチプレクサ３０は、次に、Ａ／Ｖソースデバイス２０によって提供されるサービスと関連付けられた１つ又は複数のプログラムのＰＥＳパケットを受信する（２１０）。マルチプレクサ３０は、ＰＥＳパケットのストリームＩＤで検索することによって、ＰＥＳパケットがＡ／Ｖ宛先デバイス４０への転送ストリームに含まれるべきであるかを決定する。ＰＥＳパケットのストリームＩＤが転送ストリームに含まれるべきビューと合致する場合、マルチプレクサ３０は、例えば、ＰＥＳパケットをプログラムに対応するプログラムＩＤ（ＰＩＤ）でカプセル化することによって、ＰＥＳパケットからＮＡＬユニットを形成する（２１２）。マルチプレクサ３０は、さらに、複数のそのようなＮＡＬユニットからアクセスユニットを形成し（２１４）、このアクセスユニットをＡ／Ｖ宛先デバイス４０に送る（２１６）。
【０１２５】
Ａ／Ｖ宛先デバイス４０は、次に、Ａ／Ｖソースデバイス２０からアクセスユニットを受信し（２１８）、例えば、アクセスユニットのＰＩＤを参照することによって、アクセスユニットをプログラムに関連付ける（２２０）。Ａ／Ｖ宛先デバイス４０のデマルチプレクサ３８は、アクセスユニットを構成ＮＡＬユニットに、従って、デマルチプレクサ３８がオーディオデコーダ４６及び／又はビデオデコーダ４８に最終的に渡し得るＰＥＳパケットに、逆多重化する。ビデオデコーダ４８は、ビューの各々をデコーディングし、デコーディングされたビューを、複数のビューを要求する立体又はオートステレオスコピックのビデオディスプレイ又はその他のディスプレイデバイスを備え得るビデオ出力４４に送る。同様に、オーディオディサイダ４６は、デコーディングされたオーディオデータを形成するためにオーディオフレームをデコーディングし、このオーディオデータを、例えば、スピーカ等のオーディオ出力４２に送る。このやり方で、Ａ／Ｖ宛先デバイス４０が受信したデータをデコーディング及び表示する（２２２）。
【０１２６】
図８は、ビュー構成要素が昇順のビュー順序インデックスを有するように、２つ以上のサブビットストリームのビュー構成要素を組み立ててビットストリームを生成する例示的な方法を図示するフローチャートである。本方法は、各サブビットストリーム及びビュー構成要素のビューＩＤを参照することなしにサブビットストリームを順序付ける。図６の実施例に関連して、転送ストリーム（又はプログラムストリーム）の第１のサブビットストリームがビューＳ０、Ｓ２、及びＳ４のビュー構成要素を含み、（第１のサブビットストリームの埋め込まれたサブビットストリームに対応する）転送ストリームの第２のサブビットストリームがビューＳ１及びＳ３のビュー構成要素を含むと仮定する。さらに、本開示は、埋め込まれたサブビットストリームを「依存性サブビットストリーム」と呼ぶ。同様に、本開示は、依存性サブビットストリームが埋め込まれるサブビットストリームをプライマリ・サブビットストリームと呼ぶ。従って、図８の第１のサブビットストリームはプライマリ・サブビットストリームと呼ばれ、第２のサブビットストリームは埋め込まれたサブビットストリーム又は依存性サブビットストリームと呼ばれる。
【０１２７】
本実施例に関するビュー順序インデックスが表６の実施例に関して規定されたものと同様であると仮定すると、第１のサブビットストリームのビュー構成要素のビュー順序インデックスは、（各々、）０、１、及び３であり、第２のサブビットストリームに関するビュー順序インデックスは、２及び４である。従って、本実施例の第１のビットストリームのビュー構成要素が第２のサブビットストリームのビュー構成要素の前に完全にデコーディングされる場合、デコーディング順序は、ビュー順序インデックスに関して、０、１、３、２、４に対応する。ビュー順序インデックスは、デコーディング順序を表現するべきであるので、そのようなデコーディング順序はＭＶＣ仕様の違反を構成し得る。従って、図８の方法は、ビュー構成要素のデコーディング順序がＭＶＣ仕様に準拠するように、ビュー順序インデックスに関して、ビュー構成要素を再順序付けするために用いられる。
【０１２８】
図８の方法は、サブビットストリームを組み立てる際に、現在のサブビットストリーム及びその埋め込まれたサブビットストリームの全てで搬送されるような、ビュー順序インデックスの昇順に従う必要がある、各アクセスユニットのビュー構成要素を含む例示的な方法に一般に対応する。本開示の技術は、ＮＡＬユニットのＮＡＬユニットヘッダのｖｉｅｗ＿ｉｄシンタックス要素をチェックすることなく、しかも、それをビュー順序インデックスにマッピングすることなく、適合ＭＶＣサブビットストリームの組み立てを可能にする。図８の方法は、ＭＶＣ標準に準拠する順序でのサブビットストリームのｖｉｅｗ＿ＩＤに対応するインデックスを備える「階層レイヤインデックスリスト」（ＨＬＩ）と呼ばれるリストを生成するのに用いられる。
【０１２９】
最初に、Ａ／Ｖ宛先デバイス４０等のクライアントデバイスが、２つのサブビットストリームのビュー構成要素を有するアクセスユニットを受信する（２５０）。例示目的で、第２のサブビットストリームが、第１のサブビットストリームの埋め込まれたサブビットストリーム又は依存性サブビットストリームを備えると仮定する。図８の例示的な方法は、２つのサブビットストリームに関連して説明される。しかしながら、図８の技術は、３つ以上のサブビットストリームを有する実施例にも適用可能である。さらに、図８の方法は、例示及び説明の目的でＡ／Ｖ宛先デバイス４０のデマルチプレクサ３８に関連して描写される。しかしながら、図８の方法は、ＭＶＣ標準に準拠するように２つ以上のサブビットストリームのビューを再編成するための、任意のデバイス、モジュール、ユニット、又はファームウェア、ハードウェア、及び／若しくはソフトウェア構成要素の組み合わせによって実行され得ることを理解されたい。
【０１３０】
各サブビットストリームのビュー構成要素が、ＭＶＣ標準に従って順序付けされると仮定する。それゆえに、デマルチプレクサ３８が、サブビットストリームのいずれのビュー構成要素が最小のビュー順序インデックスを有するか決定する（２５２）。次に、デマルチプレクサ３８は、（１つ又は複数のＮＡＬユニットを備え得る）ビュー構成要素のインデックスを次の利用可能な位置でＨＬＩリストに追加する（２５４）。実施例によっては、ビュー構成要素は、マルチメディアデータを備える１つ又は複数のＮＡＬユニットと、ビュー構成要素を別の一連のビュー構成要素から区別するために用いられ得るデリミターＮＡＬユニットとを備え得る。次に、デマルチプレクサ３８は、何らかのビュー構成要素が第１のサブビットストリームに対して残っているか否かを決定し得る（２５６）。
【０１３１】
ビュー構成要素が第１のサブビットストリームに対して残っている場合（２５６の「はい」分岐）、デマルチプレクサ３８は、ビュー構成要素が第２のサブビットストリームに対して同様に残っているか否かを決定し得る（２５８）。第１のサブビットストリームと第２のサブビットストリームの両方が少なくとも１つのビュー構成要素を含む場合（２５８の「はい」分岐）、デマルチプレクサ３８はステップ２５２に戻り、ビュー構成要素の最小のビュー順序インデックスを決定してＨＬＩリストに最小のビュー構成要素のビューインデックスを付加する。しかしながら、ビュー構成要素が第２のサブビットストリームにはなく、第１のサブビットストリームに対してのみ残っている場合（２５８の「いいえ」分岐）、デマルチプレクサ３８は、第１のサブビットストリームの残っているビュー構成要素をＨＬＩリストに付加する（２６０）。
【０１３２】
一方、第１のサブビットストリームに対してビュー構成要素が１つも残っていない場合（２５６の「いいえ」分岐）、デマルチプレクサ３８は、ビュー構成要素が第２のサブビットストリームに対して残っているか否かを決定する（２６２）。第２のサブビットストリームが残っているビュー構成要素を有する場合、デマルチプレクサ３８は、第２のサブビットストリームの残っているビュー構成要素をＨＬＩリストに付加する（２６４）。
【０１３３】
ＨＬＩリストが、対応するビュー順序インデックスの順序でビューＩＤを備えた後（例えば、ステップ２６０、２６４の完了後又は２６２の分岐「いいえ」）、デマルチプレクサ３８は、ＨＬＩリストに従って決定された順序でサブビットストリームを備える新しいビットストリームを形成する。即ち、新しいビットストリームのアクセスユニットについて、アクセスユニットが複数のビュー構成要素を備える場合、ビュー構成要素の各々のビュー順序インデックスが全ての先行のビュー順序インデックスよりも大きく、且つ全ての後続のビュー順序インデックスよりも小さくなるように、ビュー構成要素が新しいビットストリーム内に順序付けされる。次に、このビットストリームは、ビュー構成要素のデコーディングのために、例えば、ビデオデコーダ４８に、そして最終的にビュー構成要素のディスプレイに転送される。
【０１３４】
以下の例示的なアルゴリズムは、ＭＶＣ標準に準拠するようにサブビットストリームを順序付けするための例示的なプロセスを提供する。この実施例では、現在のＭＶＣサブビットストリーム又は埋め込まれたサブビットストリームのいずれかに対応するｈｉｅｒａｒｃｈｙ＿ｌａｙｅｒ＿ｉｎｄｅｘ値のリスト（ＨＬＩＬｉｓｔ）が存在する。上述したように、ビュー構成要素は複数のＮＡＬユニットを備える。同様に、実施例によっては、ビュー構成要素は、各ビュー構成要素を別のビュー構成要素から区別するためにデリミターＮＡＬユニットを備えるか、又はデリミターＮＡＬユニットが後に続いてよい。
【０１３５】
新しいビットストリームを組み立てるプロセスは以下のように規定される：
１）依存性サブビットストリームを、埋め込まれたサブビットストリームを有さないサブビットストリームとして設定する。
【０１３６】
２）ｈｉｅｒａｒｃｈｙ＿ｌａｙｅｒ＿ｉｎｄｅｘの昇順で。以下が繰り返して適用される：
１．ＭＶＣに準拠し、ＨＬＩに等しいｈｉｅｒａｒｃｈｙ＿ｌａｙｅｒ＿ｉｎｄｅｘで階層記述子に記載されるサブビットストリームを組み立てる：
２．このプロセスは、以下を入力として有する：
ｉ．明示的に存在する拡張サブビットストリーム；
ｉｉ．依存性サブビットストリーム。それがＭＶＣに準拠していて、従って、各アクセスユニットにビュー順序インデックスの昇順で配置されているビュー構成要素を有することに留意されたい；
ｉｉｉ．拡張サブビットストリームのビュー順序インデックスのリスト；
ｉｖ．依存性サブビットストリームのビュー順序インデックスのリスト；
３．このプロセスは、以下を出力として有する：
ｉ．全ての組み立てられたビュー構成要素を有し、従って、ＭＶＣに準拠し、階層記述子に規定されたＨＬＩに対応する完全な動作点を形成する新しいサブビットストリーム；
ｉｉ．新しいサブビットストリームのビュー順序インデックスのリスト；
４．ステップ３で生成された新しいサブビットストリームを依存性サブビットストリームとして設定する；
５．ＨＬＩがＨＬＩＬｉｓｔのリスト内の最後の１つである場合、依存性サブビットストリームを最後の組み立てられたＭＶＣサブビットストリームとして設定し、組み立てるプロセス全体を終了する。
【０１３７】
以下のアルゴリズムは、上記の例示的なアルゴリズムのステップ２で要求されたように、依存性サブビットストリームと拡張サブビットストリームに基づいてサブビットストリームを組み立てる例示的なプロセスを説明する。
【０１３８】
１．組み立てるプロセスの入力は２つのリストと２つのサブビットストリームであり、それらの各々は、ビュー順序インデックスの昇順に既に順序付けられている。２つのリストの各々は、ビュー順序インデックスを昇順に含み、２つのリストはＶＯＩｄｘＬｉｓｔＥとＶＯＩｄｘＬｉｓｔＤである。２つのサブビットストリームは、依存性サブビットストリームと拡張サブビットストリームである。新しいリストは、最初は空であるＶＯＩｄｘＬｉｓｔＮｅｗである。
【０１３９】
２．各アクセスユニットに対し、以下を適用する：
ｉ．ＶＯＩｄｘＥをＶＯＩｄｘＬｉｓｔＥの最初の値として、且つＶＯＩｄｘＤをＶＯＩｄｘＬｉｓｔＤの最初の値として設定する；
ｉｉ．ＶＯＩｄｘＥがＶＯＩｄｘＤより小さい場合、拡張サブビットストリームから１つのビュー構成要素を組み立てて、ＶＯＩｄｘＥをＶＯＩｄｘＬｉｓｔＥの次の値に設定し、ＶＯＩｄｘＣｕｒｒがＶＯＩｄｘＥに設定される；そうでない場合は、依存性サブビットストリームから１つのビュー構成要素を組み立てて、ＶＯＩｄｘＤをＶＯＩｄｘＬｉｓｔＤの次の値に設定し、ＶＯＩｄｘＣｕｒｒがＶＯＩｄｘＤに設定される。ＶＯＩｄｘＣｕｒｒをＶＯＩｄｘＬｉｓｔＮｅｗに追加する。
【０１４０】
・１つのビュー構成要素をサブビットストリームから組み立てる際に、デリミターＮＡＬユニットと遭遇するまでＮＡＬユニットが追加される。
【０１４１】
ｉｉｉ．ＶＯＩｄｘＥがＶＯＩｄｘＬｉｓｔＥの最後でなく、且つＶＯＩｄｘＤがＶＯＩｄｘＬｉｓｔＤの最後でない場合、全プロセスを終了する；そうでない場合は、ステップｉｖ．に進む。
【０１４２】
ｉｖ．そうでない場合、ＶＯＩｄｘＥがＶＯＩｄｘＬｉｓｔＥの最後である場合、依存性サブビットストリーム内の全ての残りのビュー構成要素を組み立て、ＶＯＩｄｘＬｉｓｔＤ内の全ての残りの値をＶＯＩｄｘＬｉｓｔＮｅｗに追加し、ＶＯＩｄｘＤをＶＯＩｄｘＬｉｓｔＤの最後に設定する。
【０１４３】
ｖ．そうでない場合、ＶＯＩｄｘＤがＶＯＩｄｘＬｉｓｔＤの最後である場合、拡張サブビットストリーム内の全ての残りのビュー構成要素を組み立てて、ＶＯＩｄｘＬｉｓｔＥ内の全ての残りの値をＶＯＩｄｘＬｉｓｔＮｅｗに追加し、ＶＯＩｄｘＥをＶＯＩｄｘＬｉｓｔＥの最後に設定する。
【０１４４】
ｖｉ．そうでない場合は、ステップｉｉ．に進む。
【０１４５】
１つ又は複数の実施例で、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、又はそれらの任意の組み合わせに実装され得る。ソフトウェアに実装される場合、機能がコンピュータ可読媒体上の１つ又は複数の命令又はコードとして記憶又は送信がされ得る。コンピュータ可読媒体は、コンピュータデータ記憶媒体又はコンピュータプログラムを１つの場所から別の場所へと転送する手助けをする任意の媒体を含む通信媒体を含んでよい。データ記憶媒体は、本開示で説明される技術を実装するための命令、コード及び／又はデータ構造を読み出す１つ若しくは複数のコンピュータ又は１つ若しくは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であってよい。限定ではなく例示目的として、そのようなコンピュータ可読媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ又はその他の光学ディスク記憶装置、磁気ディスク記憶装置、若しくはその他の磁気記憶デバイス、フラッシュメモリ、又は所望するプログラムコードを命令若しくはデータ構造の形態で搬送若しくは記憶するために利用可能であり、コンピュータによってアクセス可能である任意のその他の媒体を含んでよい。さらに、任意の接続が適切にコンピュータ可読媒体と呼ばれる。例えば、ソフトウェアがウェブサイト、サーバ、又は同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、若しくは赤外線、ラジオ、及びマイクロ波等のワイヤレス技術を用いるその他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ、又は赤外線、ラジオ、及びマイクロ波等のワイヤレス技術は媒体の定義に含まれる。本明細書で用いられるディスク（ｄｉｓｋ）及びディスク（ｄｉｓｃ）は、コンパクトディスク（ＣＤ）、レーザーディスク（登録商標）、光学ディスク、デジタル多用途ディスク（ＤＶＤ）、フロッピーディスク及びブルーレイディスクを含み、ディスク（ｄｉｓｋ）が通常、データを磁気的に再生するのに対し、ディスク（ｄｉｓｃ）はデータをレーザーで光学的に再生する。上記を組み合わせたものも、コンピュータ可読媒体の範囲に包含されるべきである。
【０１４６】
コードは、１つ又は複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）、又はその他の同等の一体型若しくは別個の論理回路等の１つ又は複数のプロセッサで実行されてよい。従って、本明細書で用いられる用語「プロセッサ」は、あらゆる前述の構造又は本明細書で説明された技術の実装に適した任意のその他の構造を示し得る。さらに、態様によっては、本明細書で説明された機能性が、エンコーディング及びデコーディングのために構成された専用のハードウェア及び／又はソフトウェアモジュール内で実現されてよいし、又は結合されたコーデックに組み込まれてよい。さらに、本技術が１つ又は複数の回路又は論理素子で完全に実装されてよい。
【０１４７】
本開示の技術は、ワイヤレスハンドセット、集積回路（ＩＣ）又はＩＣのセット（例えば、チップセット）を含む多種多様のデバイス又は装置に実装されてよい。種々の構成要素、モジュール、又はユニットが、開示された技術を実行するために構成されているデバイスの機能性の態様を強調するために本開示で説明されているが、必ずしも種々のハードウェアによる実現を要求しない。むしろ、上述されたように、種々のユニットがコーデックハードウェアユニットに結合されるか、適切なソフトウェア及び／又はファームウェアと共に、上述されたような１つ又は複数のプロセッサを含む相互作用的ハードウェアユニットの集合によって実現されてよい。
【０１４８】
種々の実施例が説明された。これら及びその他の実施例は添付の特許請求の範囲の範疇に包含される。
【図１】
2013502089.tif 000010
【図２】
2013502089.tif 000011
【図３】
2013502089.tif 000012
【図４】
2013502089.tif 000013
【図５】
2013502089.tif 000014
【図６】
2013502089.tif 000015
【図７】
2013502089.tif 000016
【図８】
2013502089.tif 000017
【国際調査報告】
2013502089.tif 000018
2013502089.tif 000019