(57)【特許請求の範囲】
【請求項１】
ビデオビットストリームを復号するための復号方法であって、
（ａ）前記ビデオビットストリームを受信するステップと、
（ｂ）前記ビデオビットストリームの複数のピクチャを復号するステップと、
（ｃ）現ピクチャのピクチャ順序カウント値を有する復号されたピクチャバッファ内の
長期参照ピクチャを識別するステップと、を含み、
前記複数のピクチャの各々は、ピクチャ順序カウントの最上位ビット値および前記ピク
チャ順序カウントの最下位ビット値に基づくピクチャ順序カウント値に関連付けられ、か
つ最大ピクチャ順序カウント最下位ビット値に関連付けられ、
前記最大ピクチャ順序カウント最下位ビット値から１減算された値及び前記現ピクチャ
のピクチャ順序カウント値がＡＮＤされた値は、前記現ピクチャの長期参照ピクチャのピ
クチャ順序カウント値に等しいことを特徴とする復号方法。
【請求項２】
複数のピクチャからなるビデオビットストリームを生成する生成方法であって、
（ａ）前記複数のピクチャを符号化するステップと、
（ｂ）現ピクチャのピクチャ順序カウント値を有する符号化されたピクチャバッファ内の長期参照ピクチャをシグナリングするステップと、を含み、
前記複数のピクチャの各々は、ピクチャ順序カウントの最上位ビット値および前記ピクチャ順序カウントの最下位ビット値に基づくピクチャ順序カウント値に関連付けられ、か
つ最大ピクチャ順序カウント最下位ビット値に関連付けられ、
前記最大ピクチャ順序カウント最下位ビット値から１減算された値及び前記現ピクチャのピクチャ順序カウント値がＡＮＤされた値は、前記現ピクチャの前記長期参照ピクチャのピクチャ順序カウント値に等しいことを特徴とする生成方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ビデオ符号化および復号に関する。
【背景技術】
【０００２】
電子デバイスは、消費者の要求を満たすため、ならびに可搬性および利便性を改善するために、より小型かつ強力になってきている。消費者は電子デバイスに依存するようになっており、機能性の向上を期待している。電子デバイスのいくつかの例は、デスクトップコンピュータ、ラップトップコンピュータ、携帯電話、スマートフォン、メディアプレーヤ、集積回路などを含む。
【０００３】
いくつかの電子デバイスは、デジタルメディアを処理および／または表示するために用いられる。たとえばポータブル電子デバイスは、今や消費者が存在するほとんどあらゆる場所でデジタルメディアが生成および／または消費されることを可能にする。さらに、いくつかの電子デバイスは、消費者の使用および娯楽のためのデジタルメディアコンテンツのダウンロードまたはストリーミングを提供してもよい。
【０００４】
デジタルビデオは、典型的に一連の画像またはフレームとして表され、その画像またはフレームの各々は画素の配列を含む。各画素は、たとえば強度および／または色情報などの情報を含む。多くの場合、各画素は３色のセットとして表される。いくつかのビデオ符号化方式は、複雑性の増加という犠牲を払って、より高い符号化効率を提供する。ビデオ符号化方式に対する画像品質の向上の要求および画像解像度の増加の要求も、符号化の複雑性を高める。
【０００５】
デジタルメディアの人気が高まることによって、いくつかの問題が提示されている。たとえば、記憶、送信および再生のために高品質のデジタルメディアを効率的に表すことは、いくつかの課題を提示する。デジタルメディアをより効率的に表す技術は有益である。
【０００６】
本発明の前述およびその他の目的、特徴および利点は、添付の図面とともに以下の本発明の詳細な説明を考慮することによって、より容易に理解されるだろう。
【発明の概要】
【課題を解決するための手段】
【０００７】
本発明の一実施形態は、ビデオビットストリームを復号するための方法を開示し、この方法は（ａ）前記ビデオビットストリームを受信するステップと、（ｂ）前記ビデオビットストリームの複数のピクチャを復号するステップとを含み、前記複数のピクチャの各々は、ピクチャ順序カウントの最上位ビット値および前記ピクチャ順序カウントの最下位ビット値に基づくピクチャ順序カウント値に関連付けられ、かつ最大ピクチャ順序カウント最下位ビット値に関連付けられ、この方法はさらに（ｃ）前記最大ピクチャ順序カウント最下位ビット値とビット毎にＡＮＤされた、現ピクチャのピクチャ順序カウントと同じ前記ピクチャ順序カウント値を有する、デコーダピクチャバッファ内のピクチャを位置付けるステップを含む。
【図面の簡単な説明】
【０００８】
【図１Ａ】ＨＥＶＣエンコーダを含む電子デバイスの一構成を示すブロック図である。
【図１Ｂ】エンハンスメントレイヤを有するＨＥＶＣエンコーダを含む電子デバイスの一構成を示すブロック図である。
【図２Ａ】ＨＥＶＣデコーダを含む電子デバイスの一構成を示すブロック図である。
【図２Ｂ】エンハンスメントレイヤを有するＨＥＶＣデコーダを含む電子デバイスの一構成を示すブロック図である。
【図３Ａ】エンコーダおよびデコーダの一実施例を示すブロック図である。
【図３Ｂ】エンハンスメントレイヤを有するエンコーダおよびデコーダの一実施例を示すブロック図である。
【図４】電子デバイスにおいて使用されるさまざまなコンポーネントを示す図である。
【図５】例示的なスライス構造を示す図である。
【図６】１スライスおよび９タイルを有するフレームを示す図である。
【図７】３スライスおよび３タイルを有するフレームを示す図である。
【図８】ＰＯＣ、復号順およびＲＰＳを示す図である。
【図９】例示的なスライスヘッダを示す図である。
【図１０】例示的なスライスヘッダを示す図である。
【図１１】例示的なスライスヘッダを示す図である。
【図１２】例示的なスライスヘッダを示す図である。
【図１３】例示的なビデオパラメータセットを示す図である。
【図１４Ａ】第２のエンハンスメントレイヤ（ｅｎｈａｎｃｅｍｅｎｔ  ｌａｙｅｒ）（ＥＬ２）がベースレイヤ（ｂａｓｅ  ｌａｙｅｒ：ＢＬ）および第１のエンハンスメントレイヤ（ＥＬ１）よりも低いピクチャレートを有するときの、符号化ピクチャに対するレイヤのネットワーク抽象化レイヤ（ｎｅｔｗｏｒｋ  ａｂｓｔｒａｃｔｉｏｎ  ｌａｙｅｒ：ＮＡＬ）ユニットおよびアクセスユニット（ａｃｃｅｓｓ  ｕｎｉｔｓ：ＡＵ）に対する構造およびタイミングを示すブロック図である。
【図１４Ｂ】ベースレイヤ（ＢＬ）が第１のエンハンスメントレイヤ（ＥＬ１）および第２のエンハンスメントレイヤ（ＥＬ２）よりも低いピクチャレートを有するときの、符号化ピクチャに対するレイヤのネットワーク抽象化レイヤ（ＮＡＬ）ユニットおよびアクセスユニット（ＡＵ）に対する構造およびタイミングを示すブロック図である。
【図１５】ＩＤＲ／ＢＬＡピクチャに対する制約を示す図である。
【図１６】同時放送ＩＤＲ／ＢＬＡピクチャを示す図である。
【図１７】ベースレイヤおよび／またはエンハンスメントレイヤ（単数または複数）を伴うアクセスユニットを示す図である。
【図１８】複数の符号化ピクチャに対するＴｅｍｐｏｒａｌＩｄ、ｐｒｅｖＴｉｄ０Ｐｉｃ、およびＰｉｃＯｒｄｅｒＣｎｔＶａｌを示す図である。
【発明を実施するための形態】
【０００９】
国際電気通信連合電気通信標準化部門（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｕｎｉｏｎ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ  Ｓｅｃｔｏｒ：ＩＴＵ−Ｔ）研究グループ１６（Ｓｔｕｄｙ  Ｇｒｏｕｐ  １６：ＳＧ１６）作業班３（Ｗｏｒｋｉｎｇ  Ｐａｒｔｙ  ３：ＷＰ３）と、国際標準化機構／国際電気標準会議（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｏｒｇａｎｉｚａｔｉｏｎ  ｆｏｒ  Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ／Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｅｌｅｃｔｒｏｔｅｃｈｎｉｃａｌ  Ｃｏｍｍｉｓｓｉｏｎ：ＩＳＯ／ＩＥＣ）合同専門委員会１／小委員会２９／作業グループ１１（Ｊｏｉｎｔ  Ｔｅｃｈｎｉｃａｌ  Ｃｏｍｍｉｔｔｅｅ  １／Ｓｕｂｃｏｍｍｉｔｔｅｅ  ２９／Ｗｏｒｋｉｎｇ  Ｇｒｏｕｐ  １１：ＪＴＣ１／ＳＣ２９／ＷＧ１１）とのビデオ符号化に関する共同作業チーム（Ｊｏｉｎｔ  Ｃｏｌｌａｂｏｒａｔｉｖｅ  Ｔｅａｍ  ｏｎ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ：ＪＣＴ−ＶＣ）は、高効率ビデオ符号化規格（Ｈｉｇｈ  Ｅｆｆｉｃｉｅｎｃｙ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ  ｓｔａｎｄａｒｄ：ＨＥＶＣ）と呼ばれるビデオ符号化規格に関する標準化の取り組みを開始した。ＨＥＶＣは、ブロックに基づく符号化を使用する。
【００１０】
図１Ａは、ビデオが符号化される電子デバイス１０２の一構成を示すブロック図である。なお、電子デバイス１０２内に含まれるものとして示されるエレメントの１つまたはそれ以上は、ハードウェア、ソフトウェア、または両方の組み合わせにおいて実現されてもよい。たとえば、電子デバイス１０２は、ハードウェア、ソフトウェア、または両方の組み合わせにおいて実現されるエンコーダ１０８を含む。たとえば、エンコーダ１０８は回路、集積回路、特定用途向け集積回路（ａｐｐｌｉｃａｔｉｏｎ−ｓｐｅｃｉｆｉｃ  ｉｎｔｅｇｒａｔｅｄ  ｃｉｒｃｕｉｔ：ＡＳＩＣ）、実行可能な命令を有するメモリと電子通信を行うプロセッサ、ファームウェア、フィールドプログラマブルゲート配列（ｆｉｅｌｄ−ｐｒｏｇｒａｍｍａｂｌｅ  ｇａｔｅ  ａｒｒａｙ：ＦＰＧＡ）など、またはその組み合わせとして実現されてもよい。いくつかの構成において、エンコーダ１０８は高効率ビデオ符号化（ＨＥＶＣ）コーダであってもよい。
【００１１】
電子デバイス１０２はサプライヤ１０４を含んでもよい。サプライヤ１０４は、ピクチャまたは画像データ（例、ビデオ）をソース１０６としてエンコーダ１０８に提供してもよい。サプライヤ１０４の例は、画像センサ、メモリ、通信インタフェース、ネットワークインタフェース、無線受信機、ポートなどを含む。
【００１２】
ソース１０６は、イントラフレーム予測モジュールおよび再構築バッファ１１０に提供されてもよい。加えてソース１０６は、動き推定および動き補償モジュール１３６と、減算モジュール１１６とに提供されてもよい。
【００１３】
イントラフレーム予測モジュールおよび再構築バッファ１１０は、ソース１０６および再構築データ１５０に基づいて、イントラモード情報１２８およびイントラ信号１１２を生成してもよい。動き推定および動き補償モジュール１３６は、ソース１０６および参照ピクチャバッファ１６６の信号１６８に基づいて、インターモード情報１３８およびインター信号１１４を生成してもよい。参照ピクチャバッファ１６６の信号１６８は、参照ピクチャバッファ１６６に保存される１つまたはそれ以上の参照ピクチャからのデータを含んでもよい。
【００１４】
エンコーダ１０８は、モードに従ってイントラ信号１１２とインター信号１１４との間で選択を行ってもよい。イントラ信号１１２は、イントラ符号化モードにおいてピクチャ内の空間的特徴を利用するために用いられてもよい。インター信号１１４は、インター符号化モードにおいてピクチャ間の時間的特徴を利用するために用いられてもよい。イントラ符号化モードで、イントラ信号１１２が減算モジュール１１６に提供されてもよく、かつイントラモード情報１２８がエントロピー符号化モジュール１３０に提供されてもよい。インター符号化モードで、インター信号１１４が減算モジュール１１６に提供されてもよく、かつインターモード情報１３８がエントロピー符号化モジュール１３０に提供されてもよい。  予測残差１１８を生成するために、減算モジュール１１６において（モードによって）イントラ信号１１２またはインター信号１１４のいずれかがソース１０６から減算される。予測残差１１８は変換モジュール１２０に提供される。変換モジュール１２０は予測残差１１８を圧縮して変換信号１２２を生成してもよく、変換信号１２２は量子化モジュール１２４に提供される。量子化モジュール１２４は変換信号１２２を量子化して、変換および量子化係数（ｔｒａｎｓｆｏｒｍｅｄ  ａｎｄ  ｑｕａｎｔｉｚｅｄ  ｃｏｅｆｆｉｃｉｅｎｔｓ：ＴＱＣ）１２６を生成する。
【００１５】
ＴＱＣ１２６は、エントロピー符号化モジュール１３０および逆量子化モジュール１４０に提供される。逆量子化モジュール１４０は、ＴＱＣ１２６に対して逆量子化を行って逆量子化信号１４２を生成し、逆量子化信号１４２は逆変換モジュール１４４に提供される。逆変換モジュール１４４は、逆量子化信号１４２を展開して展開信号１４６を生成し、展開信号１４６は再構築モジュール１４８に提供される。
【００１６】
再構築モジュール１４８は、展開信号１４６に基づいて再構築データ１５０を生成してもよい。たとえば、再構築モジュール１４８は（修正された）ピクチャを再構築してもよい。再構築データ１５０は、デブロッキングフィルタ１５２と、イントラ予測モジュールおよび再構築バッファ１１０とに提供されてもよい。デブロッキングフィルタ１５２は、再構築データ１５０に基づいてフィルタ信号１５４を生成してもよい。
【００１７】
フィルタ信号１５４は、サンプル適応オフセット（ｓａｍｐｌｅ  ａｄａｐｔｉｖｅ  ｏｆｆｓｅｔ：ＳＡＯ）モジュール１５６に提供されてもよい。ＳＡＯモジュール１５６は、エントロピー符号化モジュール１３０に提供されるＳＡＯ情報１５８と、適応ループフィルタ（ａｄａｐｔｉｖｅ  ｌｏｏｐ  ｆｉｌｔｅｒ：ＡＬＦ）１６２に提供されるＳＡＯ信号１６０とを生成してもよい。ＡＬＦ１６２はＡＬＦ信号１６４を生成し、ＡＬＦ信号１６４は参照ピクチャバッファ１６６に提供される。ＡＬＦ信号１６４は、参照ピクチャとして用いられる１つまたはそれ以上のピクチャからのデータを含んでもよい。場合によっては、ＡＬＦ１６２が省略されてもよい。
【００１８】
エントロピー符号化モジュール１３０は、ＴＱＣ１２６を符号化してビットストリーム１３４を生成してもよい。上述のとおり、ＴＱＣ１２６はエントロピー符号化の前に１Ｄ配列に変換されてもよい。加えて、エントロピー符号化モジュール１３０は、ＣＡＶＬＣまたはＣＡＢＡＣを用いてＴＱＣ１２６を符号化してもよい。特に、エントロピー符号化モジュール１３０は、イントラモード情報１２８、インターモード情報１３８およびＳＡＯ情報１５８のうちの１つまたはそれ以上に基づいて、ＴＱＣ１２６を符号化してもよい。ビットストリーム１３４は、符号化ピクチャデータを含んでもよい。
【００１９】
たとえばＨＥＶＣなどのビデオ圧縮に伴われる量子化は、ある範囲の値を単一の量子値に圧縮することによって達成される不可逆圧縮技術である。量子化パラメータ（ｑｕａｎｔｉｚａｔｉｏｎ  ｐａｒａｍｅｔｅｒ：ＱＰ）は、再構築されたビデオの品質および圧縮比の両方に基づいて量子化を行うために用いられる、予め定義されたスケーリングパラメータである。所与のブロックの特徴をブロックサイズおよびブロックの色情報に基づいて表すために、ＨＥＶＣにおいてブロックタイプが定められる。ＱＰ、解像度情報およびブロックタイプは、エントロピー符号化の前に定められてもよい。たとえば、電子デバイス１０２（例、エンコーダ１０８）がＱＰ、解像度情報およびブロックタイプを定めてもよく、これらの情報がエントロピー符号化モジュール１３０に提供されてもよい。
【００２０】
エントロピー符号化モジュール１３０は、ＴＱＣ１２６のブロックに基づいてブロックサイズを定めてもよい。たとえば、ブロックサイズはＴＱＣのブロックの１つのディメンジョンに沿ったＴＱＣ１２６の数であってもよい。言換えると、ＴＱＣのブロック内のＴＱＣ１２６の数は、ブロックサイズの２乗に等しくてもよい。加えて、ブロックは正方形でなくてもよく、ここでＴＱＣ１２６の数はブロックの高さ掛ける幅である。たとえば、ブロックサイズは、ＴＱＣのブロック内のＴＱＣ１２６の数の平方根として定めてもよい。解像度は、画素幅掛ける画素高さとして定義されてもよい。解像度情報は、ピクチャの幅、ピクチャの高さ、またはその両方に対する画素数を含んでもよい。ブロックサイズは、ＴＱＣの２Ｄブロックの１つのディメンジョンに沿ったＴＱＣの数として定義されてもよい。
【００２１】
いくつかの構成において、ビットストリーム１３４は別の電子デバイスに送信されてもよい。たとえば、ビットストリーム１３４は通信インタフェース、ネットワークインタフェース、無線送信機、ポートなどに提供されてもよい。たとえば、ビットストリーム１３４はローカルエリアネットワーク（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ：ＬＡＮ）、インターネット、携帯電話基地局などを介して別の電子デバイスに送信されてもよい。付加的または代替的に、ビットストリーム１３４は電子デバイス１０２のメモリに保存されてもよい。
【００２２】
図２Ｂは、高効率ビデオ符号化（ＨＥＶＣ）デコーダであってもよいデコーダ２７２を含む電子デバイス２７０の一構成を示すブロック図である。デコーダ２７２およびデコーダ２７２内に含まれるものとして示されるエレメントの１つまたはそれ以上は、ハードウェア、ソフトウェア、または両方の組み合わせにおいて実現されてもよい。デコーダ２７２は、復号のためのビットストリーム２３４（例、ビットストリーム２３４に含まれる１つまたはそれ以上の符号化ピクチャ）を受信してもよい。いくつかの構成において、受信されるビットストリーム２３４は、たとえば受信スライスヘッダ、受信ピクチャパラメータセット（ｐｉｃｔｕｒｅ  ｐａｒａｍｅｔｅｒ  ｓｅｔ：ＰＰＳ）、受信バッファ記述情報、分類インジケータなどの受信オーバーヘッド情報を含んでもよい。
【００２３】
ビットストリーム２３４からの受信シンボル（例、符号化ＴＱＣ）は、エントロピー復号モジュール２７４によってエントロピー復号されてもよい。このエントロピー復号によって、動き情報信号２９８と、復号された変換および量子化係数（ＴＱＣ）２７８とが生成されてもよい。
【００２４】
動き情報信号２９８は、動き補償モジュール２９４において、フレームメモリ２９０からの復号ピクチャ２９２の一部と組み合わされてもよく、動き補償モジュール２９４はインターフレーム予測信号２９６を生成してもよい。復号された変換および量子化係数（ＴＱＣ）２７８は、逆量子化および逆変換モジュール２８０によって逆量子化および逆変換されることによって、復号残差信号２８２を生成してもよい。加算モジュール２０７によって復号残差信号２８２を予測信号２０５に加えて、結合信号２８４を生成してもよい。予測信号２０５は、動き補償モジュール２９４によって生成されるインターフレーム予測信号２９６か、またはイントラフレーム予測モジュール２０１によって生成されるイントラフレーム予測信号２０３のいずれかから選択される信号であってもよい。いくつかの構成において、この信号選択はビットストリーム２３４に基づいて（例、制御されて）いてもよい。
【００２５】
イントラフレーム予測信号２０３は、（たとえば現フレーム内の）結合信号２８４からの、以前に復号された情報から予測されてもよい。結合信号２８４はさらに、デブロッキングフィルタ２８６によってフィルタ処理されてもよい。結果として得られるフィルタ信号２８８は、サンプル適応オフセット（ＳＡＯ）モジュール２３１に提供されてもよい。フィルタ信号２８８と、エントロピー復号モジュール２７４からの情報２３９とに基づいて、ＳＡＯモジュール２３１はＳＡＯ信号２３５を生成してもよく、ＳＡＯ信号２３５は適応ループフィルタ（ａｄａｐｔｉｖｅ  ｌｏｏｐ  ｆｉｌｔｅｒ：ＡＬＦ）２３３に提供される。ＡＬＦ２３３はＡＬＦ信号２３７を生成し、ＡＬＦ信号２３７はフレームメモリ２９０に提供される。ＡＬＦ信号２３７は、参照ピクチャとして用いられる１つまたはそれ以上のピクチャからのデータを含んでもよい。ＡＬＦ信号２３７はフレームメモリ２９０に書込まれてもよい。結果として得られるＡＬＦ信号２３７は、復号ピクチャを含んでもよい。場合によっては、ＡＬＦ２３３が省略されてもよい。
【００２６】
フレームメモリ２９０は、復号ピクチャバッファ（ｄｅｃｏｄｅｄ  ｐｉｃｔｕｒｅ  ｂｕｆｆｅｒ：ＤＰＢ）を含んでもよい。フレームメモリ２９０はさらに、復号ピクチャに対応するオーバーヘッド情報を含んでもよい。たとえば、フレームメモリ２９０は、スライスヘッダ、ピクチャパラメータセット（ＰＰＳ）情報、サイクルパラメータ、バッファ記述情報などを含んでもよい。これらの情報の１つまたはそれ以上が、コーダ（例、エンコーダ１０８）からシグナリングされてもよい。
【００２７】
フレームメモリ２９０は、１つまたはそれ以上の復号ピクチャ２９２を動き補償モジュール２９４に提供してもよい。さらに、フレームメモリ２９０は１つまたはそれ以上の復号ピクチャ２９２を提供してもよく、その復号ピクチャ２９２はデコーダ２７２から出力されてもよい。１つまたはそれ以上の復号ピクチャ２９２は、たとえばディスプレイに提示されたり、メモリに保存されたり、別のデバイスに送信されたりしてもよい。
【００２８】
図１Ｂは、電子デバイス７０２上のビデオエンコーダ７８２の一構成を示すブロック図である。図１Ｂのビデオエンコーダ７８２は、図１Ａのビデオエンコーダ１０８の一構成であってもよい。ビデオエンコーダ７８２は、エンハンスメントレイヤエンコーダ７０６と、ベースレイヤエンコーダ７０９と、解像度アップスケーリングブロック７７０と、出力インタフェース７８０とを含んでもよい。本明細書に記載されるとおり、たとえば図１Ｂのビデオエンコーダは、スケーラブルビデオ符号化およびマルチビュービデオ符号化に対して好適である。
【００２９】
エンハンスメントレイヤエンコーダ７０６は、入力ピクチャ７０４を受信するビデオ入力７８１を含んでもよい。ビデオ入力７８１の出力は、予測選択７５０の出力を受信する加算器／減算器７８３に提供されてもよい。加算器／減算器７８３の出力は、変換および量子化ブロック７５２に提供されてもよい。変換および量子化ブロック７５２の出力は、エントロピー符号化７４８ブロックならびにスケーリングおよび逆変換ブロック７７２に提供されてもよい。エントロピー符号化７４８が行われた後、エントロピー符号化ブロック７４８の出力は、出力インタフェース７８０に提供されてもよい。出力インタフェース７８０は、符号化ベースレイヤビデオビットストリーム７０７と、符号化エンハンスメントレイヤビデオビットストリーム７１０との両方を出力してもよい。
【００３０】
スケーリングおよび逆変換ブロック７７２の出力は、加算器７７９に提供されてもよい。加算器７７９はさらに、予測選択７５０の出力を受信してもよい。加算器７７９の出力は、デブロッキングブロック７５１に提供されてもよい。デブロッキングブロック７５１の出力は、参照バッファ７９４に提供されてもよい。参照バッファ７９４の出力は、動き補償ブロック７５４に提供されてもよい。動き補償ブロック７５４の出力は、予測選択７５０に提供されてもよい。参照バッファ７９４の出力は、イントラ予測因子７５６にも提供されてもよい。イントラ予測因子７５６の出力は、予測選択７５０に提供されてもよい。予測選択７５０はさらに、解像度アップスケーリングブロック７７０の出力を受信してもよい。
【００３１】
ベースレイヤエンコーダ７０９は、ダウンサンプリングされた入力ピクチャ、または別の画像と組み合わせるために好適なその他の画像内容、または代替ビュー入力ピクチャもしくは同じ入力ピクチャ７０３（すなわち、エンハンスメントレイヤエンコーダ７０６が受信する入力ピクチャ７０４と同じ入力ピクチャ）を受信するビデオ入力７６２を含んでもよい。ビデオ入力７６２の出力は、符号化予測ループ７６４に提供されてもよい。エントロピー符号化７６６は、符号化予測ループ７６４の出力に提供されてもよい。符号化予測ループ７６４の出力は、参照バッファ７６８にも提供されてもよい。参照バッファ７６８は、符号化予測ループ７６４にフィードバックを提供してもよい。参照バッファ７６８の出力は、解像度アップスケーリングブロック７７０にも提供されてもよい。エントロピー符号化７６６が行われたとき、その出力が出力インタフェース７８０に提供されてもよい。
【００３２】
図２Ｂは、電子デバイス８０２上のビデオデコーダ８１２の一構成を示すブロック図である。図２Ｂのビデオデコーダ８１２は、図２Ａのビデオデコーダ２７２の一構成であってもよい。ビデオデコーダ８１２は、エンハンスメントレイヤデコーダ８１５と、ベースレイヤデコーダ８１３とを含んでもよい。加えてビデオデコーダ８１２は、インタフェース８８９と、解像度アップスケーリング８７０とを含んでもよい。本明細書に記載されるとおり、たとえば図２Ｂのビデオデコーダは、スケーラブルビデオ符号化およびマルチビュービデオ符号化に対して好適である。
【００３３】
インタフェース８８９は、符号化ビデオストリーム８８５を受信してもよい。符号化ビデオストリーム８８５は、ベースレイヤ符号化ビデオストリームと、エンハンスメントレイヤ符号化ビデオストリームとからなっていてもよい。これら２つのストリームは別々に送られても、一緒に送られてもよい。インタフェース８８９は、符号化ビデオストリーム８８５の一部またはすべてを、ベースレイヤデコーダ８１３内のエントロピー復号ブロック８８６に提供してもよい。エントロピー復号ブロック８８６の出力は、復号予測ループ８８７に提供されてもよい。復号予測ループ８８７の出力は、参照バッファ８８８に提供されてもよい。参照バッファは、復号予測ループ８８７にフィードバックを提供してもよい。加えて参照バッファ８８８は、復号ベースレイヤビデオストリーム８８４を出力してもよい。
【００３４】
加えてインタフェース８８９は、符号化ビデオストリーム８８５の一部またはすべてを、エンハンスメントレイヤデコーダ８１５内のエントロピー復号ブロック８９０に提供してもよい。エントロピー復号ブロック８９０の出力は、逆量子化ブロック８９１に提供されてもよい。逆量子化ブロック８９１の出力は、加算器８９２に提供されてもよい。加算器８９２は、逆量子化ブロック８９１の出力と、予測選択ブロック８９５の出力とを加算してもよい。加算器８９２の出力は、デブロッキングブロック８９３に提供されてもよい。デブロッキングブロック８９３の出力は、参照バッファ８９４に提供されてもよい。参照バッファ８９４は、復号エンハンスメントレイヤビデオストリーム８８２を出力してもよい。参照バッファ８９４の出力は、イントラ予測因子８９７にも提供されてもよい。エンハンスメントレイヤデコーダ８１５は、動き補償８９６を含んでもよい。動き補償８９６は、解像度アップスケーリング８７０の後に行われてもよい。予測選択ブロック８９５は、イントラ予測因子８９７の出力と、動き補償８９６の出力とを受信してもよい。
【００３５】
図３Ａは、エンコーダ３０８およびデコーダ３７２の一実施例を示すブロック図である。この実施例においては、電子デバイスＡ３０２および電子デバイスＢ３７０が示される。しかし、いくつかの構成においては、電子デバイスＡ３０２および電子デバイスＢ３７０に関して記載された特徴および機能が単一の電子デバイス内に組み合わされてもよいことが留意されるべきである。
【００３６】
電子デバイスＡ３０２はエンコーダ３０８を含む。エンコーダ３０８は、ハードウェア、ソフトウェア、または両方の組み合わせにおいて実現されてもよい。一構成において、エンコーダ３０８は高効率ビデオ符号化（ＨＥＶＣ）コーダであってもよい。他のコーダが同様に用いられてもよい。電子デバイスＡ３０２はソース３０６を得てもよい。いくつかの構成において、ソース３０６は、画像センサを用いて電子デバイスＡ３０２に捕捉されても、メモリから検索されても、別の電子デバイスから受信されてもよい。
【００３７】
エンコーダ３０８はソース３０６を符号化してビットストリーム３３４を生成してもよい。たとえば、エンコーダ３０８はソース３０６内の一連のピクチャ（例、ビデオ）を符号化してもよい。エンコーダ３０８は、図１Ａに関連して上述したエンコーダ１０８と類似のものであってもよい。
【００３８】
ビットストリーム３３４は、ソース３０６に基づく符号化ピクチャデータを含んでもよい。いくつかの構成において、ビットストリーム３３４はさらに、たとえばスライスヘッダ情報、ＰＰＳ情報などのオーバーヘッドデータを含んでもよい。ソース３０６内の付加的なピクチャが符号化されるために、ビットストリーム３３４は１つまたはそれ以上の符号化ピクチャを含んでもよい。
【００３９】
ビットストリーム３３４はデコーダ３７２に提供されてもよい。一実施例において、ビットストリーム３３４は、有線または無線リンクを用いて電子デバイスＢ３７０に送信されてもよい。場合によっては、この送信が、たとえばインターネットまたはローカルエリアネットワーク（ＬＡＮ）などのネットワークを通じて行われてもよい。図３Ａに示されるとおり、デコーダ３７２は、電子デバイスＡ３０２のエンコーダ３０８とは別に電子デバイスＢ３７０上に実現されてもよい。しかし、いくつかの構成においては、エンコーダ３０８とデコーダ３７２とが同じ電子デバイス上に実現されてもよいことに留意すべきである。エンコーダ３０８とデコーダ３７２とが同じ電子デバイス上に実現される実施においては、たとえばビットストリーム３３４はバスを通じてデコーダ３７２に提供されてもよいし、デコーダ３７２による検索のためにメモリに保存されてもよい。デコーダ３７２は、復号ピクチャ３９２出力を提供してもよい。
【００４０】
デコーダ３７２は、ハードウェア、ソフトウェア、または両方の組み合わせにおいて実現されてもよい。一構成において、デコーダ３７２は高効率ビデオ符号化（ＨＥＶＣ）デコーダであってもよい。他のデコーダが同様に用いられてもよい。デコーダ３７２は、図２Ａに関連して上述したデコーダ２７２と類似のものであってもよい。
【００４１】
図３Ｂは、エンコーダ（ｅｃｏｄｅｒ）９０８およびデコーダ９７２の別の実施例を示すブロック図である。この実施例においては、電子デバイスＡ９０２および電子デバイスＢ９７０が示される。しかし、いくつかの構成においては、電子デバイスＡ９０２および電子デバイスＢ９７０に関して記載された特徴および機能が単一の電子デバイス内に組み合わされてもよいことが留意されるべきである。
【００４２】
電子デバイスＡ９０２はエンコーダ９０８を含む。エンコーダ９０８は、ベースレイヤエンコーダ９１０と、エンハンスメントレイヤエンコーダ９２０とを含んでもよい。ビデオエンコーダ９０８は、スケーラブルビデオ符号化およびマルチビュービデオ符号化に対して好適である。エンコーダ９０８は、ハードウェア、ソフトウェア、または両方の組み合わせにおいて実現されてもよい。一構成において、エンコーダ９０８は、スケーラブルおよび／またはマルチビューを含む高効率ビデオ符号化（ＨＥＶＣ）コーダであってもよい。他のコーダが同様に用いられてもよい。電子デバイスＡ９０２はソース９０６を得てもよい。いくつかの構成において、ソース９０６は、画像センサを用いて電子デバイスＡ９０２に捕捉されても、メモリから検索されても、別の電子デバイスから受信されてもよい。
【００４３】
エンコーダ９０８はソース９０６を符号化して、ベースレイヤビットストリーム９３４およびエンハンスメントレイヤビットストリーム９３６を生成してもよい。たとえば、エンコーダ９０８はソース９０６内の一連のピクチャ（例、ビデオ）を符号化してもよい。特に、品質スケーラビリティとしても公知であるＳＮＲスケーラビリティに対するスケーラブルビデオ符号化に対しては、ベースレイヤおよびエンハンスメントレイヤエンコーダに同じソース９０６が提供されてもよい。特に、空間スケーラビリティに対するスケーラブルビデオ符号化に対しては、ベースレイヤエンコーダにはダウンサンプリングされたソースが用いられてもよい。特に、マルチビュー符号化に対しては、ベースレイヤエンコーダおよびエンハンスメントレイヤエンコーダに異なるビューソースが用いられてもよい。エンコーダ９０８は、図１Ｂに関連して上述したエンコーダ７８２と類似のものであってもよい。
【００４４】
ビットストリーム９３４、９３６は、ソース９０６に基づく符号化ピクチャデータを含んでもよい。いくつかの構成において、ビットストリーム９３４、９３６はさらに、たとえばスライスヘッダ情報、ＰＰＳ情報などのオーバーヘッドデータを含んでもよい。ソース９０６内の付加的なピクチャが符号化されるために、ビットストリーム９３４、９３６は１つまたはそれ以上の符号化ピクチャを含んでもよい。
【００４５】
ビットストリーム９３４、９３６は、デコーダ９７２に提供されてもよい。デコーダ９７２は、ベースレイヤデコーダ９８０と、エンハンスメントレイヤデコーダ９９０とを含んでもよい。ビデオデコーダ９７２は、スケーラブルビデオ復号およびマルチビュービデオ復号に対して好適である。一実施例において、ビットストリーム９３４、９３６は、有線または無線リンクを用いて電子デバイスＢ９７０に送信されてもよい。場合によっては、この送信が、たとえばインターネットまたはローカルエリアネットワーク（ＬＡＮ）などのネットワークを通じて行われてもよい。図３Ｂに示されるとおり、デコーダ９７２は、電子デバイスＡ９０２のエンコーダ９０８とは別に電子デバイスＢ９７０上に実現されてもよい。しかし、いくつかの構成においては、エンコーダ９０８とデコーダ９７２とが同じ電子デバイス上に実現されてもよいことに留意すべきである。エンコーダ９０８とデコーダ９７２とが同じ電子デバイス上に実現される実施においては、たとえばビットストリーム９３４、９３６は、バスを通じてデコーダ９７２に提供されてもよいし、デコーダ９７２による検索のためにメモリに保存されてもよい。デコーダ９７２は、出力として復号ベースレイヤ９９２および復号エンハンスメントレイヤピクチャ（単数または複数）９９４を提供してもよい。
【００４６】
デコーダ９７２は、ハードウェア、ソフトウェア、または両方の組み合わせにおいて実現されてもよい。一構成において、デコーダ９７２は、スケーラブルおよび／またはマルチビューを含む高効率ビデオ符号化（ＨＥＶＣ）デコーダであってもよい。他のデコーダが同様に用いられてもよい。デコーダ９７２は、図２Ｂに関連して上述したデコーダ８１２と類似のものであってもよい。
【００４７】
図４は、電子デバイス４０９において使用されるさまざまなコンポーネントを示す。電子デバイス４０９は、電子デバイスの１つまたはそれ以上として実現されてもよい。たとえば、電子デバイス４０９は、図１Ａおよび図１Ｂに関連して上述した電子デバイス１０２、図２Ａおよび図２Ｂに関連して上述した電子デバイス２７０、またはその両方として実現されてもよい。
【００４８】
電子デバイス４０９は、電子デバイス４０９の動作を制御するプロセッサ４１７を含む。プロセッサ４１７は、ＣＰＵと呼ばれることもある。リードオンリメモリ（ｒｅａｄ−ｏｎｌｙ  ｍｅｍｏｒｙ：ＲＯＭ）、ランダムアクセスメモリ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ：ＲＡＭ）の両方、または情報を保存する任意のタイプのデバイスを含むメモリ４１１は、プロセッサ４１７に命令４１３ａ（例、実行可能な命令）およびデータ４１５ａを提供する。メモリ４１１の一部は、不揮発性ランダムアクセスメモリ（ｎｏｎ−ｖｏｌａｔｉｌｅ  ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｍｅｍｏｒｙ：ＮＶＲＡＭ）をさらに含んでもよい。メモリ４１１は、プロセッサ４１７と電子通信していてもよい。
【００４９】
加えて、プロセッサ４１７内にも命令４１３ｂおよびデータ４１５ｂが存在してもよい。プロセッサ４１７にロードされた命令４１３ｂおよび／またはデータ４１５ｂはさらに、プロセッサ４１７による実行または処理のためにロードされた、メモリ４１１からの命令４１３ａおよび／またはデータ４１５ａを含んでもよい。本明細書において開示される１つまたはそれ以上の技術を実現するために、プロセッサ４１７によって命令４１３ｂが実行されてもよい。
【００５０】
電子デバイス４０９は、他の電子デバイスと通信するための１つまたはそれ以上の通信インタフェース４１９を含んでもよい。通信インタフェース４１９は、有線通信技術、無線通信技術、またはその両方に基づいていてもよい。通信インタフェース４１９の例は、シリアルポート、パラレルポート、ユニバーサルシリアルバス（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ：ＵＳＢ）、イーサネット（登録商標）アダプタ、ＩＥＥＥ１３９４バスインタフェース、小型コンピュータシステムインタフェース（ｓｍａｌｌ  ｃｏｍｐｕｔｅｒ  ｓｙｓｔｅｍ  ｉｎｔｅｒｆａｃｅ：ＳＣＳＩ）バスインタフェース、赤外線（ｉｎｆｒａｒｅｄ：ＩＲ）通信ポート、Ｂｌｕｅｔｏｏｔｈ（登録商標）無線通信アダプタ、および第３世代パートナーシッププロジェクト（３ｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ：３ＧＰＰ）仕様に従う無線トランシーバなどを含む。
【００５１】
電子デバイス４０９は、１つまたはそれ以上の出力デバイス４２３および１つまたはそれ以上の入力デバイス４２１を含んでもよい。出力デバイス４２３の例は、スピーカ、プリンタなどを含む。電子デバイス４０９に含まれる１つのタイプの出力デバイスは、ディスプレイデバイス４２５である。本明細書において開示される構成とともに使用されるディスプレイデバイス４２５は、たとえば陰極線管（ｃａｔｈｏｄｅ  ｒａｙ  ｔｕｂｅ：ＣＲＴ）、液晶ディスプレイ（ｌｉｑｕｉｄ  ｃｒｙｓｔａｌ  ｄｉｓｐｌａｙ：ＬＣＤ）、発光ダイオード（ｌｉｇｈｔ−ｅｍｉｔｔｉｎｇ  ｄｉｏｄｅ：ＬＥＤ）、気体プラズマ、またはエレクトロルミネセンスなど、任意の好適な画像投影技術を用いてもよい。メモリ４１１に保存されたデータを、ディスプレイ４２５において示されるテキスト、グラフィックス、および／または動画に（適宜）変換するために、ディスプレイコントローラ４２７が提供されてもよい。入力デバイス４２１の例は、キーボード、マウス、マイクロホン、リモートコントロールデバイス、ボタン、ジョイスティック、トラックボール、タッチパッド、タッチスクリーン、ライトペンなどを含む。
【００５２】
電子デバイス４０９のさまざまなコンポーネントは、バスシステム４２９によってともに結合されており、バスシステム４２９は、データバスに加えて電力バス、制御信号バスおよびステータス信号バスを含んでもよい。しかし、明瞭にするために、図４においてはさまざまなバスがバスシステム４２９として示される。図４に示される電子デバイス４０９は、特定のコンポーネントのリストではなく、機能ブロック図である。
【００５３】
「コンピュータ読取り可能媒体」という用語は、コンピュータまたはプロセッサによるアクセスが可能なあらゆる利用可能な媒体を示す。本明細書において用いられる「コンピュータ読取り可能媒体」という用語は、非一時的かつ有形なコンピュータおよび／またはプロセッサ読取り可能媒体を示してもよい。限定ではなく例として、コンピュータ読取り可能媒体またはプロセッサ読取り可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭもしくはその他の光ディスク記憶装置、磁気ディスク記憶装置もしくはその他の磁気記憶装置、または、命令もしくはデータ構造の形の所望のプログラムコードを保有もしくは保存するために使用でき、かつコンピュータもしくはプロセッサによるアクセスが可能なあらゆるその他の媒体を含んでもよい。本明細書において用いられるディスク（Ｄｉｓｋ）およびディスク（ｄｉｓｃ）は、コンパクトディスク（ｃｏｍｐａｃｔ  ｄｉｓｃ：ＣＤ）、レーザディスク、光ディスク、デジタル多用途ディスク（ｄｉｇｉｔａｌ  ｖｅｒｓａｔｉｌｅ  ｄｉｓｃ：ＤＶＤ）、フロッピーディスク、およびＢｌｕ−ｒａｙ（登録商標）ディスクを含み、ここでディスク（ｄｉｓｋｓ）は通常データを磁気的に再生するのに対し、ディスク（ｄｉｓｃｓ）はデータをレーザによって光学的に再生する。デコーダおよび／またはエンコーダに対するコードが、コンピュータ読取り可能媒体に保存されてもよい。
【００５４】
複数の符号化ツリーブロック（例、本明細書においては一般的にブロックと呼ぶ）を含む入力ピクチャは、１つまたはいくつかのスライスに分割されてもよい。エンコーダおよびデコーダにおいて用いられる参照ピクチャが同じであり、かつデブロッキングフィルタ処理がスライス境界を越えた情報を使用しないとき、あるスライスが表すピクチャの区域内のサンプルの値は、他のスライスからのデータを使用することなく適切に復号されてもよい。したがって、あるスライスに対するエントロピー復号およびブロック再構築は、他のスライスに依存しない。特に、エントロピー符号化状態は、各スライスの最初にリセットされてもよい。エントロピー復号および再構築の両方に対する近傍の利用可能性を定めるとき、他のスライスのデータは利用不可能とマーク付けされてもよい。スライスは、並行してエントロピー復号および再構築されてもよい。スライスの境界を越えたイントラ予測および動きベクトル予測は許可されないことが好ましい。これに対し、デブロッキングフィルタ処理は、スライス境界を越えた情報を使用してもよい。
【００５５】
図５は、水平方向に１１ブロック、鉛直方向に９ブロックを含む例示的ビデオピクチャ５００を示す（９つの例示的ブロックが５０１〜５０９とラベル付けされる）。図５は、３つの例示的スライスを示す。すなわち、「ＳＬＩＣＥ＃０」と表示される第１のスライス５２０、「ＳＬＩＣＥ＃１」と表示される第２のスライス５３０、および「ＳＬＩＣＥ＃２」と表示される第３のスライス５４０である。デコーダは、３つのスライス５２０、５３０、５４０を並行して復号および再構築してもよい。各々のスライスは、連続的な態様で走査線の順序で送信されてもよい。各スライスに対する復号／再構築プロセスの開始時に、コンテキストモデルは初期化またはリセットされ、他のスライスのブロックは、エントロピー復号およびブロック再構築の両方に対して利用不可能とマーク付けされる。コンテキストモデルは一般的に、エントロピーエンコーダおよび／またはデコーダの状態を表す。よって、たとえば「ＳＬＩＣＥ＃１」内の５０３とラベル付けされたブロックなどのブロックに対して、「ＳＬＩＣＥ＃０」内のブロック（たとえば５０１および５０２とラベル付けされたブロック）は、コンテキストモデル選択にも再構築にも使用されない。一方で、たとえば「ＳＬＩＣＥ＃１」内の５０５とラベル付けされたブロックなどのブロックに対して、「ＳＬＩＣＥ＃１」内の他のブロック（たとえば５０３および５０４とラベル付けされたブロック）は、コンテキストモデル選択または再構築のために使用されてもよい。したがって、エントロピー復号およびブロック再構築は、スライス内で連続的に進行する。スライスがフレキシブルブロック順序付け（ｆｌｅｘｉｂｌｅ  ｂｌｏｃｋ  ｏｒｄｅｒｉｎｇ：ＦＭＯ）を用いるものと定められない限り、スライス内のブロックはラスタスキャン順に処理される。
【００５６】
図６を参照すると、タイル技術は、画像を（正方形を含む）矩形領域のセットに分割する。各タイル内のブロック（いくつかのシステムにおいては、代替的に最大符号化ユニットまたは符号化ツリーブロックと呼ばれる）は、ラスタスキャン順に符号化および復号される。タイルの配列も、同様にラスタスキャン順に符号化および復号される。したがって、任意の好適な数の列境界（例、０またはそれ以上）が存在してもよく、かつ任意の好適な数の行境界（例、０またはそれ以上）が存在してもよい。よって、フレームはたとえば図６に示される１つのスライスなどの、１つまたはそれ以上のスライスを定めてもよい。いくつかの実施形態において、異なるタイルに位置するブロックは、イントラ予測、動き補償、エントロピー符号化コンテキスト選択、または近傍ブロック情報に依拠するその他のプロセスに利用できない。
【００５７】
図７を参照すると、画像を３つの矩形の列のセットに分割するタイル技術が示される。各タイル内のブロック（いくつかのシステムにおいては、代替的に最大符号化ユニットまたは符号化ツリーブロックと呼ばれる）は、ラスタスキャン順に符号化および復号される。タイルも同様に、ラスタスキャン順に符号化および復号される。タイルのスキャン順において１つまたはそれ以上のスライスが定められてもよい。各々のスライスは独立に復号可能である。たとえば、スライス１はブロック１〜９を含むものと定められてもよく、スライス２はブロック１０〜２８を含むものと定められてもよく、スライス３は３つのタイルにまたがるブロック２９〜１２６を含むものと定められてもよい。タイルの使用によって、フレームのより局部的領域でデータを処理することによって、符号化効率が高まる。
【００５８】
場合によっては、ビデオ符号化は任意にタイルを含まないことがあり、任意にビデオのフレームに対するウェーブフロント符号化／復号パターンの使用を含むことが理解されるべきである。この態様で、ビデオの１つまたはそれ以上のライン（たとえば、マクロブロック（または代替的に符号化ツリーブロック）の１つまたはそれ以上の行の複数のグループなどであって、ウェーブフロントサブストリームを表すその各々のグループが、並行する態様で符号化／復号されてもよい。一般的に、ビデオの分割は、任意の好適な態様で構築されてもよい。
【００５９】
ビデオ符号化規格はしばしば、限られた周波数帯域幅および／または限られた記憶容量を伴うチャネルを通じた送信のために、ビデオデータを圧縮する。これらのビデオ符号化規格は、より効果的にフレームを符号化および復号するために、たとえばイントラ予測、空間ドメインから周波数ドメインへの変換、量子化、エントロピー符号化、動き推定、および動き補償など、複数の符号化段階を含んでもよい。符号化および復号段階の多くは、計算が過度に複雑である。
【００６０】
ビデオのビットストリームは、一般的にネットワーク抽象化レイヤ（ＮＡＬ）ユニットと呼ばれる論理データパケットに入れられるシンタックス構造を含んでもよい。各ＮＡＬユニットは、関連するデータペイロードの目的を識別するための、たとえば２バイトＮＡＬユニットヘッダ（例、１６ビット）などのＮＡＬユニットヘッダを含む。たとえば、各符号化スライス（および／またはピクチャ）は、１つまたはそれ以上のスライス（および／またはピクチャ）ＮＡＬユニットにおいて符号化されてもよい。たとえば補足エンハンスメント情報、時間サブレイヤアクセス（ｔｅｍｐｏｒａｌ  ｓｕｂ−ｌａｙｅｒ  ａｃｃｅｓｓ：ＴＳＡ）ピクチャの符号化スライス、段階的時間サブレイヤアクセス（ｓｔｅｐ−ｗｉｓｅ  ｔｅｍｐｏｒａｌ  ｓｕｂ−ｌａｙｅｒ  ａｃｃｅｓｓ：ＳＴＳＡ）ピクチャの符号化スライス、符号化スライス非ＴＳＡ、非ＳＴＳＡトレイリングピクチャ、ブロークンリンクアクセスピクチャの符号化スライス、瞬時復号リフレッシュピクチャの符号化スライス、クリーンランダムアクセスピクチャの符号化スライス、ランダムアクセス復号可能リーディングピクチャの符号化スライス、ランダムアクセススキップリーディングピクチャの符号化スライス、ビデオパラメータセット、シーケンスパラメータセット、ピクチャパラメータセット、アクセスユニットデリミタ、シーケンスの最後、ビットストリームの最後、フィラーデータ、および／またはシーケンスエンハンスメント情報メッセージなど、他のカテゴリのデータに対して、他のＮＡＬユニットが含まれてもよい。下の表１は、ＮＡＬユニットコードおよびＮＡＬユニットタイプクラスの一例を示すものである。所望に応じて、他のＮＡＬユニットタイプが含まれてもよい。加えて、表１に示されるＮＡＬユニットに対するＮＡＬユニットタイプ値の入れ替えおよび再割り当てが行われることが理解されるべきである。さらに、付加的なＮＡＬユニットタイプが追加されてもよい。さらに、いくつかのＮＡＬユニットタイプが除去されてもよい。
【００６１】
【表１】
0006393317.tif 000002
ＮＡＬは、ピクチャの内容を表すビデオ符号化レイヤ（ｖｉｄｅｏ  ｃｏｄｉｎｇ  ｌａｙｅｒ：ＶＣＬ）データを、さまざまなトランスポートレイヤ上にマップする能力を提供する。ＮＡＬユニットは、それぞれ符号化ピクチャまたはその他の関連データを含むかどうかによって、ＶＣＬおよび非ＶＣＬ  ＮＡＬユニットに分類されてもよい。Ｂ．ブロス（Ｂｒｏｓ）、Ｗ−Ｊ．ハン（Ｈａｎ）、Ｊ−Ｒ．オーム（Ｏｈｍ）、Ｇ．Ｊ．サリバン（Ｓｕｌｌｉｖａｎ）、およびＴ−．ウィーガンド（Ｗｉｅｇａｎｄ）、「高効率ビデオ符号化（ＨＥＶＣ）テキスト仕様ドラフト８（Ｈｉｇｈ  ｅｆｆｉｃｉｅｎｃｙ  ｖｉｄｅｏ  ｃｏｄｉｎｇ（ＨＥＶＣ）ｔｅｘｔ  ｓｐｅｃｉｆｉｃａｔｉｏｎ  ｄｒａｆｔ  ８）」、ＪＣＴＶＣ−Ｊ１０００３、ストックホルム（Ｓｔｏｃｋｈｏｌｍ）、２０１２年７月は、本明細書においてその全体が引用により援用される。Ｂ．ブロス、Ｗ−Ｊ．ハン、Ｊ−Ｒ．オーム、Ｇ．Ｊ．サリバン、ワン（Ｗａｎｇ）、およびＴ−．ウィーガンド、「高効率ビデオ符号化（ＨＥＶＣ）テキスト仕様ドラフト１０（ＤＦＩＳおよび最終コメント招請に対するもの）（Ｈｉｇｈ  ｅｆｆｉｃｉｅｎｃｙ  ｖｉｄｅｏ  ｃｏｄｉｎｇ（ＨＥＶＣ）ｔｅｘｔ  ｓｐｅｃｉｆｉｃａｔｉｏｎ  ｄｒａｆｔ  １０（ｆｏｒ  ＤＦＩＳ  ＆  Ｌａｓｔ  Ｃａｌｌ））」、ＪＣＴＶＣ−Ｊ１０００３＿ｖ３４、ジュネーブ（Ｇｅｎｅｖａ）、２０１３年１月は、本明細書においてその全体が引用により援用される。Ｂ．ブロス、Ｗ−Ｊ．ハン、Ｊ−Ｒ．オーム、Ｇ．Ｊ．サリバン、ワン、およびＴ−．ウィーガンド、「高効率ビデオ符号化（ＨＥＶＣ）テキスト仕様ドラフト１０（Ｈｉｇｈ  ｅｆｆｉｃｉｅｎｃｙ  ｖｉｄｅｏ  ｃｏｄｉｎｇ（ＨＥＶＣ）ｔｅｘｔ  ｓｐｅｃｉｆｉｃａｔｉｏｎ  ｄｒａｆｔ  １０）」、ＪＣＴＶＣ−Ｌ１００３、ジュネーブ、２０１３年１月は、本明細書においてその全体が引用により援用される。
【００６２】
ランダムアクセスおよびビットストリームスプライシングを可能にするために、ＩＤＲアクセスユニットはイントラピクチャ、すなわちＮＡＬユニットストリームにおけるあらゆる前のピクチャを復号することなく復号される符号化ピクチャを含む。加えて、ＩＤＲアクセスユニットの存在は、ビットストリーム中の後続ピクチャが、ＩＤＲアクセスユニットに復号のために含まれるイントラピクチャより前のピクチャに対する参照を必要としないことを示す。
【００６３】
ＩＤＲアクセスユニットは、Ｉスライスのみを含むＩＤＲピクチャを参照してもよく、ＩＤＲピクチャはビットストリームにおいて復号順で第１のピクチャであってもよいし、ビットストリームにおいて後で出現してもよい。各ＩＤＲピクチャは、復号順で符号化ビデオシーケンス（ｃｏｄｅｄ  ｖｉｄｅｏ  ｓｅｑｕｅｎｃｅ：ＣＶＳ）の第１のピクチャである。ＩＤＲピクチャに対する各ＶＣＬ  ＮＡＬユニットのｎａｌ＿ｕｎｉｔ＿ｔｙｐｅがＩＤＲ＿Ｗ＿ＲＡＤＬに等しいとき、そのＩＤＲピクチャは関連ＲＡＤＬピクチャを有してもよい。ＩＤＲピクチャに対する各ＶＣＬ  ＮＡＬユニットのｎａｌ＿ｕｎｉｔ＿ｔｙｐｅがＩＤＲ＿Ｎ＿ＬＰに等しいとき、そのＩＤＲピクチャは関連リーディングピクチャを何ら有さない。ＩＤＲピクチャは関連ＲＡＳＬピクチャを有さない。
【００６４】
ＢＬＡアクセスユニットは、Ｉスライスのみを含むＢＬＡピクチャを参照してもよく、ＢＬＡピクチャはビットストリームにおいて復号順で第１のピクチャであってもよいし、ビットストリームにおいて後で出現してもよい。各ＢＬＡピクチャは新たなＣＶＳを開始してもよく、復号プロセスに対してＩＤＲピクチャと同じ効果を有する。しかし、ＢＬＡピクチャは空でないＲＰＳを指定するシンタックスエレメントを含む。ＢＬＡピクチャに対する各ＶＣＬ  ＮＡＬユニットのｎａｌ＿ｕｎｉｔ＿ｔｙｐｅがＢＬＡ＿Ｗ＿ＬＰに等しいとき、そのＢＬＡピクチャは関連ＲＡＳＬピクチャを有してもよく、その関連ＲＡＳＬピクチャはデコーダから出力されず、かつビットストリームに存在しないピクチャに対する参照を含むかもしれないために復号可能でないことがある。ＢＬＡピクチャに対する各ＶＣＬ  ＮＡＬユニットのｎａｌ＿ｕｎｉｔ＿ｔｙｐｅがＢＬＡ＿Ｗ＿ＬＰに等しいとき、そのＢＬＡピクチャはさらに関連ＲＡＤＬピクチャを有してもよく、その関連ＲＡＤＬピクチャは復号されるよう指定されている。ＢＬＡピクチャに対する各ＶＣＬ  ＮＡＬユニットのｎａｌ＿ｕｎｉｔ＿ｔｙｐｅがＢＬＡ＿Ｗ＿ＲＡＤＬに等しいとき、そのＢＬＡピクチャは関連ＲＡＳＬピクチャを有さないが、関連ＲＡＤＬピクチャを有してもよい。ＢＬＡピクチャに対する各ＶＣＬ  ＮＡＬユニットのｎａｌ＿ｕｎｉｔ＿ｔｙｐｅがＢＬＡ＿Ｎ＿ＬＰに等しいとき、そのＢＬＡピクチャは関連リーディングピクチャを何ら有さない。
【００６５】
クリーンランダムアクセス（ｃｌｅａｎ  ｒａｎｄｏｍ  ａｃｃｅｓｓ：ＣＲＡ）ピクチャシンタックスは、ランダムアクセスポイント（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｐｏｉｎｔ：ＲＡＰ）の位置、すなわちデコーダがビットストリームのより早い位置に出現していた任意のピクチャを復号する必要なくピクチャの復号の開始を成功させることができるビットストリーム内の位置における、イントラピクチャの使用を指定する。ランダムアクセスの支援によって、効果的なチャネル切換え、シーク動作、および動的ストリーミングサービスが可能になる。復号順でＣＲＡピクチャに後続し、かつ表示順（出力順）でＣＲＡピクチャに先行するいくつかのピクチャは、ＣＲＡピクチャにおける復号開始のときにデコーダにおいて利用不可能なピクチャに対するインターピクチャ予測参照を含んでいてもよい。これらの復号不可能なピクチャは、ＣＲＡポイントにおいて復号プロセスを開始するデコーダによって廃棄される。こうした復号不可能なピクチャは、ランダムアクセススキップリーディング（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｓｋｉｐｐｅｄ  ｌｅａｄｉｎｇ：ＲＡＳＬ）ピクチャとして識別される。異なる元の符号化ビットストリームからのスプライスポイントの位置は、ブロークンリンクアクセス（ｂｒｏｋｅｎ  ｌｉｎｋ  ａｃｃｅｓｓ：ＢＬＡ）ピクチャによって示されてもよい。ビットストリームスプライシング動作は、一方のビットストリームにおけるＣＲＡピクチャのＮＡＬユニットタイプを、ＢＬＡピクチャを示す値に変更し、他方のビットストリームにおけるＲＡＰピクチャの位置に新たなビットストリームを連結することによって行われてもよい。ＲＡＰピクチャはＩＤＲ、ＣＲＡまたはＢＬＡピクチャであってもよく、ビットストリームにおいてＣＲＡおよびＢＬＡピクチャの両方の後にＲＡＳＬピクチャが続いてもよく（ＢＬＡピクチャに対して用いられるＮＡＬユニットタイプの特定の値に依存する）、他方のビットストリームにおけるＲＡＰピクチャの位置に新たなビットストリームを連結する。ＢＬＡピクチャに関連する任意のＲＡＳＬピクチャは、スプライシング動作のためにビットストリームに実際には存在しないピクチャに対する参照を含むため、デコーダによって廃棄される。復号順でＲＡＰピクチャに後続でき、かつ出力順でＲＡＰピクチャに先行できる他のタイプのピクチャは、ランダムアクセス復号可能リーディングピクチャ（ｒａｎｄｏｍ  ａｃｃｅｓｓ  ｄｅｃｏｄａｂｌｅ  ｌｅａｄｉｎｇ  ｐｉｃｔｕｒｅ：ＲＡＤＬ）であり、このピクチャは復号順でＲＡＰピクチャに先行する任意のピクチャに対する参照を含有できない。ＲＡＳＬおよびＲＡＤＬピクチャは、集合的にリーディングピクチャ（ｌｅａｄｉｎｇ  ｐｉｃｔｕｒｅｓ：ＬＰ）と呼ばれる。復号順および出力順の両方でＲＡＰピクチャに後続するピクチャはトレイリングピクチャとして公知であり、このピクチャはインターピクチャ予測のためのＬＰに対する参照を含有できない。
【００６６】
複数参照ピクチャ管理に対して、ビットストリーム内の残りのピクチャを復号するために、復号ピクチャバッファ（ＤＰＢ）（図１Ａの参照ピクチャバッファ１６６および図２Ａのフレームメモリ２９０を参照）には以前復号されたピクチャの特定のセットが存在する必要がある。これらのピクチャを識別するために、各スライスヘッダにおいてピクチャ順序カウント（ｐｉｃｔｕｒｅ  ｏｒｄｅｒ  ｃｏｕｎｔ：ＰＯＣ）識別子が送信される。ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂシンタックスエレメントは、現ピクチャに対するピクチャ順序カウントをＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂで割った余りを示す。ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂシンタックスエレメントの長さは、ｌｏｇ２＿ｍａｘ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ＿ｍｉｎｕｓ４＋４ビットである。ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂの値は、両端値を含めて０からＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ−１までの範囲内である。ｌｏｇ２＿ｍａｘ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ＿ｍｉｎｕｓ４は、次のとおりにピクチャ順序カウントに対する復号プロセスにおいて用いられる変数ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂの値を示す。
【００６７】
ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ＝２（ｌｏｇ２＿ｍａｘ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ＿ｍｉｎｕｓ４＋４）（０−１）
ｌｏｇ２＿ｍａｘ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ＿ｍｉｎｕｓ４の値は、両端値を含めて０から１２の範囲内である。
【００６８】
参照ピクチャセット（Ｒｅｆｅｒｅｎｃｅ  ｐｉｃｔｕｒｅ  ｓｅｔ：ＲＰＳ）とは、あるピクチャに関連する参照ピクチャのセットであり、復号順で関連ピクチャの前にある、関連ピクチャまたは復号順で関連ピクチャに後続する任意のピクチャのインター予測に用いられるすべての参照ピクチャからなる。図８は、時間予測構造に対する例示的なＰＯＣ値、復号順、およびＲＰＳを示す。この実施例において示されるＲＰＳ値は、ＲＰＳに対する実際のＰＯＣ値を示す。他の場合には、ＰＯＣ値の代わりに、現ピクチャのＰＯＣに関するピクチャのＰＯＣ値の差と、参照されるピクチャが現ピクチャおよび参照によって使用されるか否かをシグナリングするインジケータとがＲＰＳに保存されてもよい。
【００６９】
ＩＤＲピクチャは、復号のためにいかなる以前のピクチャも必要としないため、ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂシンタックスエレメントに対するピクチャ順序カウントは０であると推測されてもよく、よってビットストリームのビットレートが低減する。デコーダ順でピクチャにおける第１のスライスは、ｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇが１に等しく設定されることによってシグナリングされる。その結果、１に等しい値を有するシンタックスエレメントｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇは、２つまたはそれ以上のＩＤＲピクチャが連続して送られる場合に、ＩＤＲピクチャの開始を識別する境界の役割をする。しかし、場合によっては、ビデオレイヤにおいて連続するＩＤＲピクチャに属するスライスを区別することができない。第１のこうした場合とは、デコーダにパケットがばらばらの順序で到着するときである。第２のこうした場合とは、ＩＤＲピクチャの第１のスライスを含むパケットが失われたときである。加えて、符号化ビデオシーケンスのすべてのピクチャがＩＤＲピクチャとしてイントラ符号化によってシグナリングされるとき（例、すべてイントラのプロファイルを用いるとき）、すべてのピクチャのｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ値が０となる。よって、デコーダが特定のＩＤＲピクチャと別のＩＤＲピクチャとを識別できるようにするために、システムは各々に対して異なるｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ値をシグナリングする必要がある。加えて、ＩＤＲピクチャと類似であり、かつＩスライスのみを有するＢＬＡピクチャは、ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂエレメントに対して非ゼロ値をシグナリングできる。
【００７０】
図９を参照すると、ビットストリームの復号におけるデコーダの頑強性を増すために、ＩＤＲピクチャに対してｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂシンタックスエレメントをシグナリングする必要がある。図９に示されるスライスヘッダの実施形態において、ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂは、現ピクチャに対するピクチャ順序カウントをＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂで割った余りを示す。ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂシンタックスエレメントの長さは、ｌｏｇ２＿ｍａｘ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ＿ｍｉｎｕｓ４＋４ビットである。ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂの値は、両端値を含めて０からＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ−１までの範囲内である。
【００７１】
代替的な技術は、ＢＬＡピクチャに対してｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂシンタックスエレメントをシグナリングしないことを含み、よってＩＤＲシグナリングと整合させるためにその値を０であると推測する。その結果、ＩｄｒＰｉｃＦｌａｇ導出は、好ましくはＢＬＡをも含むように変更される。加えて、ＩｄｒＰｉｃＦｌａｇは好ましくはＩｄｒＢｌａＰｉｃＦｌａｇと再命名される。加えて、好ましくはＰｉｃＯｒｄｅｒＣｎｔＶａｌの算出がＢＬＡピクチャに対して修正される。代替的には、ＩｄｒＰｉｃＦｌａｇを維持しながら、新たなフラグＩｄｒＢｌａＰｉｃＦｌａｇが含まれてもよい。
【００７２】
一般的に、もしそのピクチャがＩＤＲピクチャであれば、ＩｄｒＰｉｃＦｌａｇは真または１である。そうでなければ、ＩｄｒＰｉｃＦｌａｇは偽または０である。１つの場合に、変数ＩｄｒＰｉｃＦｌａｇは、ＩｄｒＰｉｃＦｌａｇ＝（ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ＝＝ＩＤＲ＿Ｗ＿ＲＡＤＬ｜｜ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ＝＝ＩＤＲ＿Ｎ＿ＬＰ）と示され、ここでｎａｌ＿ｕｎｉｔ＿ｔｙｐｅはＮＡＬユニットタイプを示す。
【００７３】
一般的に、もしそのピクチャがＩＤＲピクチャまたはＢＬＡピクチャであれば、ＩｄｒＢｌａＰｉｃＦｌａｇは真または１である。そうでなければ、ＩｄｒＢｌａＰｉｃＦｌａｇは偽または０である。１つの場合に、変数ＩｄｒＢｌａＰｉｃＦｌａｇは、ＩｄｒＢｌａＰｉｃＦｌａｇ＝（ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ＝＝ＩＤＲ＿Ｗ＿ＲＡＤＬ｜｜ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ＝＝ＩＤＲ＿Ｎ＿ＬＰ｜｜ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ＝＝ＢＬＡ＿Ｗ＿ＬＰ｜｜ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ＝＝ＢＬＡ＿Ｗ＿ＬＰ｜｜ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ＝＝ＢＬＡ＿Ｎ＿ＬＰ）と示され、ここでｎａｌ＿ｕｎｉｔ＿ｔｙｐｅはＮＡＬユニットタイプを示す。
【００７４】
この代替的な技術が用いられる理由は、ＢＬＡピクチャがＩスライスのみを含み、かつビットストリームにおいて復号順で第１のピクチャであるから、またはＢＬＡピクチャがビットストリームにおいて後で出現するからである。前述したとおり、各ＢＬＡピクチャは新たな符号化ビデオシーケンスを開始し、復号プロセスに対してＩＤＲピクチャと同じ効果を有する。その結果として、ＢＬＡおよびＩＤＲピクチャに対してｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ値をシグナリングする一貫したやり方を有することによって、それらのピクチャがデコーダによって類似の態様で処理されることが可能になる。
【００７５】
図１０を参照すると、ビットストリームの復号ならびにＩＤＲおよびＢＬＡピクチャの処理におけるデコーダの一貫性を増すために、ＩＤＲピクチャまたはＢＬＡピクチャ以外のピクチャ（例、！ＩｄｒＢＬＡＰｉｃＦｌａｇ）のスライスヘッダにおいてｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂシンタックスエレメントがシグナリングされてもよい。
【００７６】
図１１を参照すると、ビットストリームの復号ならびにＩＤＲおよびＢＬＡピクチャの処理におけるデコーダの一貫性を増すために、ＩＤＲピクチャまたはＢＬＡピクチャ以外のピクチャ（例、！ＩｄｒＢＬＡＰｉｃＦｌａｇ）のスライスヘッダにおいてｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂシンタックスエレメントがシグナリングされてもよい。スライスヘッダの残りの部分は、ＩＤＲピクチャ以外のピクチャ（例、！ＩｄｒＰｉｃＦｌａｇ）に対してシグナリングされてもよい。よって、スライスヘッダの残りの部分は、ＢＬＡピクチャに対してシグナリングされてもよい。
【００７７】
図１２を参照すると、ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂシンタックスエレメントは、スライスヘッダの最初にあってもよい。ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂフィールドがスライスヘッダの最初にあることによって、スライスの他のシンタックスエレメントを構文解析する前に、そのスライスがどのピクチャに属するかを理解するために、スライスヘッダにおいてそのフィールドを最初にチェックすることがより容易に可能になる。このことは、ピクチャがばらばらの順序で到着するか、および／または失われる可能性のある環境において有用である。
【００７８】
スケーラブルビデオ符号化とは、１つまたはそれ以上のサブセットビットストリームをさらに含むビデオビットストリームを符号化する技術である。サブセットビデオビットストリームは、サブセットビットストリームに必要とされる帯域幅を低減させるために、より大きなビデオからパケットを落とすことによって導出されてもよい。サブセットビットストリームは、より低い空間解像度（より小さいスクリーン）、より低い時間解像度（より低いフレームレート）、またはより低品質のビデオ信号を表してもよい。たとえば、ビデオビットストリームは５つのサブセットビットストリームを含んでもよく、各々のサブセットビットストリームはベースビットストリームに付加的な内容を与える。ハンヌクセラ（Ｈａｎｎｕｋｓｅｌａ）ら、「高効率ビデオ符号化（ＨＥＶＣ）のスケーラブル拡張のためのテストモデル（Ｔｅｓｔ  Ｍｏｄｅｌ  ｆｏｒ  Ｓｃａｌａｂｌｅ  Ｅｘｔｅｎｓｉｏｎｓ  ｏｆ  Ｈｉｇｈ  Ｅｆｆｉｃｉｅｎｃｙ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ（ＨＥＶＣ））」ＪＣＴＶＣ−Ｌ０４５３、上海（Ｓｈａｎｇｈａｉ）、２０１２年１０月は、本明細書においてその全体が引用により援用される。チェン（Ｃｈｅｎ）ら、「ＳＨＶＣドラフトテキスト１（ＳＨＶＣ  Ｄｒａｆｔ  Ｔｅｘｔ  １）」、ＪＣＴＶＣ−Ｌ１００８、ジュネーブ、２０１３年３月は、本明細書においてその全体が引用により援用される。付加的な説明は、Ｊ．チェン、Ｊ．ボイス（Ｂｏｙｃｅ）、Ｙ．イェ（Ｙｅ）、Ｍ．Ｍ．ハンヌクセラ、「ＳＨＶＣドラフトテキスト２（ＳＨＶＣ  Ｄｒａｆｔ  Ｔｅｘｔ  ２）」、ＪＣＴＶＣ−Ｍ１００８、仁川（Ｉｎｃｈｅｏｎ）、２０１３年５月；Ｇ．テック（Ｔｅｃｈ）、Ｋ．ウェグナー（Ｗｅｇｎｅｒ）、Ｙ．チェン、Ｍ．ハンヌクセラ、Ｊ．ボイス、「ＭＶ−ＨＥＶＣドラフトテキスト４（ＭＶ−ＨＥＶＣ  Ｄｒａｆｔ  Ｔｅｘｔ  ４）（ＩＳＯ／ＩＥＣ  ２３００８−２：２０１ｘ／ＰＤＡＭ２）」、ＪＣＴＶＣ−Ｄ１００４、仁川、２０１３年５月；Ｊ．チェン、Ｊ．ボイス、Ｙ．イェ、Ｍ  ハンヌクセラ、ＳＨＶＣドラフト３（ＳＨＶＣ  Ｄｒａｆｔ  ３）、ＪＣＴＶＣ−Ｎ１００８、ウィーン（Ｖｉｅｎｎａ）、２０１３年８月；およびＹ．チェン、Ｙ．−Ｋ．ワン、Ａ．Ｋ．ラマスブロマニアン（Ｒａｍａｓｕｂｒｏｍａｎｉａｎ）、ＭＶ−ＨＥＶＣ／ＳＨＶＣ  ＨＬＳ：クロスレイヤＰＯＣアライメント（Ｃｒｏｓｓ−ｌａｙｅｒ  ＰＯＣ  Ａｌｉｇｎｍｅｎｔ）、ＪＣＴＶＣ−Ｎ０２４４、ウィーン、２０１３年７月に記載されており、その文献の各々は本明細書においてその全体が引用により援用される。
【００７９】
マルチビュービデオ符号化とは、代替ビューを表す１つまたはそれ以上の他のビットストリームをも含むビデオビットストリームを符号化する技術である。たとえば、多重ビューは立体ビデオのための一対のビューであってもよい。たとえば、多重ビューは異なる視点からの同じシーンの多重ビューを表してもよい。一般的に、多重ビューは大量のインタービュー統計的依存性を含む。なぜなら、それらの画像は異なる視点からの同じシーンの画像だからである。したがって、時間およびインタービュー予測を組み合わせることによって、効率的なマルチビュー符号化を達成できる。たとえば、時間的に関係するフレームだけでなく、近傍の視点のフレームからも効率的にフレームが予測されてもよい。ハンヌクセラら、「スケーラブルおよびマルチビュー拡張のための共通仕様テキスト（Ｃｏｍｍｏｎ  ｓｐｅｃｉｆｉｃａｔｉｏｎ  ｔｅｘｔ  ｆｏｒ  ｓｃａｌａｂｌｅ  ａｎｄ  ｍｕｌｔｉ−ｖｉｅｗ  ｅｘｔｅｎｓｉｏｎｓ）」、ＪＣＴＶＣ−Ｌ０４５２、ジュネーブ、２０１３年１月は、本明細書においてその全体が引用により援用される。テックら、「ＭＶ−ＨＥＶＣドラフトテキスト３（ＭＶ−ＨＥＶＣ  Ｄｒａｆｔ  Ｔｅｘｔ  ３）（ＩＳＯ／ＩＥＣ  ２３００８−２：２０１ｘ／ＰＤＡＭ２）」、ＪＣＴ３Ｖ−Ｃ１００４＿ｄ３、ジュネーブ、２０１３年１月は、本明細書においてその全体が引用により援用される。Ｇ．テック、Ｋ．ウェグナー、Ｙ．チェン、Ｍ．ハンヌクセラ、Ｊ．ボイス、「ＭＶ−ＨＥＶＣドラフトテキスト５（ＭＶ−ＨＥＶＣ  Ｄｒａｆｔ  Ｔｅｘｔ  ５）（ＩＳＯ／ＩＥＣ  ２０３００８−２：２０１ｘ／ＰＤＡＭ２）」、ＪＣＴＶＣ−Ｅ１００４、ウィーン、２０１３年８月は、本明細書においてその全体が引用により援用される。
【００８０】
図１３を参照すると、ビデオパラメータセットは、ビデオシーケンスに関係する内容を記述するシンタックスである。ビデオパラメータセットシンタックスは、多くのシンタックスエレメントによって示され、そのシンタックスエレメントのいくつかを以下に説明する。
【００８１】
ｖｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｏｆｆｓｅｔは、ＮＡＬユニットの最初から始まる、ＶＰＳ  ＮＡＬユニット内の固定長符号化情報の次のセットのバイトオフセットを示す。非ベースレイヤまたはビューに対するＶＰＳ情報は、ＶＰＳ  ＮＡＬユニットのバイトアライメントされた位置から始まっていてもよく、セッションネゴシエーションおよび／または能力交換に対する固定長符号化情報を有する。ｖｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｏｆｆｓｅｔによって示されるバイトオフセットは、次いでエントロピー復号の必要なくＶＰＳ  ＮＡＬユニット内の情報を位置付けてその情報にアクセスすることを助ける。
【００８２】
ｖｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇが０に等しいことは、ＶＰＳ  ＲＢＳＰシンタックス構造にｖｐｓ＿ｅｘｔｅｎｓｉｏｎ（）シンタックス構造が存在しないことを示す。ｖｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇが１に等しいことは、ＶＰＳ  ＲＢＳＰシンタックス構造にｖｐｓ＿ｅｘｔｅｎｓｉｏｎ（）シンタックス構造が存在することを示す。ｖｐｓ＿ｍａｘ＿ｌａｙｅｒｓ＿ｍｉｎｕｓ１が０より大きいとき、ｖｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｆｌａｇは１に等しい。
【００８３】
ｖｐｓ＿ｅｘｔｅｎｓｉｏｎ２＿ｆｌａｇが０に等しいことは、ＶＰＳ  ＲＢＳＰシンタックス構造にｖｐｓ＿ｅｘｔｅｎｓｉｏｎ＿ｄａｔａ＿ｆｌａｇシンタックスエレメントが存在しないことを示す。デコーダは、ＶＰＳ  ＮＡＬユニット内のｖｐｓ＿ｅｘｔｅｎｓｉｏｎ２＿ｆｌａｇに対する値１に続くデータを無視してもよい。
【００８４】
ＪＣＴＶＣ−Ｍ１００８およびＪＣＴ３ＶＤ−１００４には、以下の制約が含まれる。符号化ピクチャに対するｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ値ｎａｌＵｎｉｔＴｙｐｅＡがＩＤＲ＿Ｗ＿ＤＬＰ、ＩＤＲ＿Ｎ＿ＬＰ、ＢＬＡ＿Ｗ＿ＬＰ、ＢＬＡ＿Ｗ＿ＤＬＰ、またはＢＬＡ＿Ｎ＿ＬＰに等しいとき、同じアクセスユニットのすべての符号化ピクチャのすべてのＶＣＬ  ＮＡＬユニットに対して、ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ値がｎａｌＵｎｉｔＴｙｐｅＡに等しくなる。
【００８５】
アクセスユニット（ＡＵ）は、ネットワーク抽象化レイヤ（ＮＡＬ）ユニットのセットを示し、それらのネットワーク抽象化レイヤ（ＮＡＬ）ユニットは、指定された分類規則に従って互いに関連付けられており、かつ復号順に連続しており、かつ同じ出力時間に関連するすべての符号化ピクチャのビデオ符号化レイヤ（ＶＣＬ）ＮＡＬユニットと、ＶＣＬ  ＮＡＬユニットに関連する非ＶＣＬ  ＮＡＬユニットとを含む。ベースレイヤとは、すべてのＶＣＬ  ＮＡＬユニットのｎｕｈ＿ｌａｙｅｒ＿ｉｄが０に等しいレイヤのことである。符号化ピクチャとはピクチャの符号化表現であって、特定の値のｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するＶＣＬ  ＮＡＬユニットを含み、かつそのピクチャのすべての符号化ツリーユニットを含む。場合によっては、符号化ピクチャがレイヤコンポーネントと呼ばれることもある。
【００８６】
図１４Ａは、第２のエンハンスメントレイヤ（ＥＬ２）９４２ｂがベースレイヤ（ＢＬ）９４４および第１のエンハンスメントレイヤ（ＥＬ１）９４２ａよりも低いピクチャレートを有するときの、符号化ピクチャに対するレイヤのネットワーク抽象化レイヤ（ＮＡＬ）ユニットおよびアクセスユニット（ＡＵ）に対する構造およびタイミングを示すブロック図である。ＥＬ１符号化ピクチャのＮＡＬユニット９５３ａは、第１のエンハンスメントレイヤ（ＥＬ１）９４２ａに沿って示される。ＥＬ２符号化ピクチャのＮＡＬユニット９５３ｂは、第２のエンハンスメントレイヤ（ＥＬ２）９４２ｂに沿って示される。ベースレイヤ符号化ピクチャのＮＡＬユニット９５３ｃは、ベースレイヤ（ＢＬ）９４４に沿って示される。
【００８７】
時間ｔ１において、ＥＬ１符号化ピクチャのＮＡＬユニット９５３ａ、ＥＬ２符号化ピクチャのＮＡＬユニット９５３ｂ、およびベースレイヤ符号化ピクチャのＮＡＬユニット９５３ｃは、アクセスユニット（ＡＵ）９５５ａの一部である。時間ｔ２において、ＥＬ１符号化ピクチャのＮＡＬユニット９５３ａ、およびベースレイヤ符号化ピクチャのＮＡＬユニット９５３ｃは、アクセスユニット（ＡＵ）９５５ｂの一部である。時間ｔ３において、ＥＬ１符号化ピクチャのＮＡＬユニット９５３ａ、ＥＬ２符号化ピクチャのＮＡＬユニット９５３ｂ、およびベースレイヤ符号化ピクチャのＮＡＬユニット９５３ｃは、アクセスユニット（ＡＵ）９５５ｃの一部である。時間ｔ４において、ＥＬ１符号化ピクチャのＮＡＬユニット９５３ａ、およびベースレイヤ符号化ピクチャのＮＡＬユニット９５３ｃは、アクセスユニット（ＡＵ）９５５ｄの一部である。
【００８８】
図１４Ｂは、ベースレイヤ（ＢＬ）１０４４が第１のエンハンスメントレイヤ（ＥＬ１）１０４２ａおよび第２のエンハンスメントレイヤ（ＥＬ２）１０４２ｂよりも低いピクチャレートを有するときの、符号化ピクチャに対するレイヤのネットワーク抽象化レイヤ（ＮＡＬ）ユニットおよびアクセスユニット（ＡＵ）に対する構造およびタイミングを示すブロック図である。ＥＬ１符号化ピクチャのＮＡＬユニット１０５３ａは、第１のエンハンスメントレイヤ（ＥＬ１）１０４２ａに沿って示される。ＥＬ２符号化ピクチャのＮＡＬユニット１０５３ｂは、第２のエンハンスメントレイヤ（ＥＬ２）１０４２ｂに沿って示される。ベースレイヤ符号化ピクチャのＮＡＬユニット１０５３ｃは、ベースレイヤ（ＢＬ）１０４４に沿って示される。
【００８９】
時間ｔ１において、ＥＬ１符号化ピクチャのＮＡＬユニット１０５３ａ、ＥＬ２符号化ピクチャのＮＡＬユニット１０５３ｂ、およびベースレイヤ符号化ピクチャのＮＡＬユニット１０５３ｃは、アクセスユニット（ＡＵ）１０５５ａの一部である。時間ｔ２において、ＥＬ１符号化ピクチャのＮＡＬユニット１０５３ａ、およびＥＬ２符号化ピクチャのＮＡＬユニット１０５３ｂは、アクセスユニット（ＡＵ）１０５５ｂの一部である。時間ｔ３において、ＥＬ１符号化ピクチャのＮＡＬユニット１０５３ａ、ＥＬ２符号化ピクチャのＮＡＬユニット１０５３ｂ、およびベースレイヤ符号化ピクチャのＮＡＬユニット１０５３ｃは、アクセスユニット（ＡＵ）１０５５ｃの一部である。時間ｔ４において、ＥＬ１符号化ピクチャのＮＡＬユニット１０５３ａ、およびＥＬ１符号化ピクチャのＮＡＬユニット１０５３ｂは、アクセスユニット（ＡＵ）１０５５ｄの一部である。
【００９０】
図１５を参照すると、ＮＡＬユニットタイプに対するこの制約が図示される。異なるタイプのＩＤＲピクチャ（例、ＩＤＲ＿Ｗ＿ＲＡＤＬ、ＩＤＲ＿Ｎ＿ＬＰ）およびＢＬＡピクチャ（ＢＬＡ＿Ｗ＿ＬＰ、ＢＬＡ＿Ｗ＿ＲＡＤＬまたはＢＬＡ＿Ｎ＿ＬＰ）に対して、ベースレイヤ（例、ベースレイヤ０）に関してエンハンスメントレイヤ（例、エンハンスメントレイヤ１、２、３、４）の各々に対して制約が実施される。したがって、もしベースレイヤのピクチャがＩＤＲまたはＢＬＡピクチャのいずれかであれば、同じＰｉｃＯｒｄｅｒＣｎｔＶａｌに対するエンハンスメントレイヤの各々も同様に、対応するＩＤＲまたはＢＬＡピクチャである。
【００９１】
ベースレイヤおよびエンハンスメントレイヤ（単数または複数）の使用は、同じビデオストリーム内で一対（またはそれ以上）のビデオストリームを同時放送するために用いられてもよい。この態様で、たとえばベースレイヤ０およびエンハンスメントレイヤ１が第１のビデオストリームであってもよく、エンハンスメントレイヤ２、エンハンスメントレイヤ３、およびエンハンスメントレイヤ４が第２のビデオストリームであってもよい。たとえば、２つのビデオストリームは同じビデオ内容を有するが、異なるベースレイヤおよびエンハンスメントレイヤに対して異なるビットレートを用いてもよい。加えて、それらのビデオストリームは、異なるベースレイヤに対して異なる符号化アルゴリズム（例、ＨＥＶＣ／ＡＶＣ）を用いてもよい。この態様で、エンハンスメントレイヤ２はエンハンスメントレイヤ１にもベースレイヤ０にも依存しない。加えて、エンハンスメントレイヤ３およびエンハンスメントレイヤ４は、エンハンスメントレイヤ１にもベースレイヤ０にも依存しない。エンハンスメントレイヤ３はエンハンスメントレイヤ２に依存してもよく、エンハンスメントレイヤ４はエンハンスメントレイヤ３およびエンハンスメントレイヤ２の両方に依存してもよい。好ましくは、エンハンスメントレイヤはより小さい番号を有するエンハンスメントレイヤにのみ依存してもよく、より大きい番号を有するエンハンスメントレイヤには依存しない方がよい。
【００９２】
各レイヤに対して、そのレイヤが他のどのレイヤに直接依存するかを示すために、直接依存性フラグを用いて、この特定のエンハンスメントレイヤ依存性がシグナリングされる。たとえばｄｉｒｅｃｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｆｌａｇ［１］［ｊ］＝｛１｝は、エンハンスメントレイヤ１がベースレイヤ０に依存することを示す。たとえばｄｉｒｅｃｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｆｌａｇ［２］［ｊ］＝｛０，０｝は、エンハンスメントレイヤ２が別のレイヤに依存しないことを示す。たとえばｄｉｒｅｃｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｆｌａｇ［３］［ｊ］＝｛０，０，１｝は、エンハンスメントレイヤ３がベースレイヤ０に依存せず、かつエンハンスメントレイヤ１に依存せず、かつエンハンスメントレイヤ２に依存することを示す。たとえばｄｉｒｅｃｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｆｌａｇ［４］［ｊ］＝｛０，０，１，１｝は、エンハンスメントレイヤ４がベースレイヤ０に依存せず、かつエンハンスメントレイヤ１に依存せず、かつエンハンスメントレイヤ２に依存でき、かつエンハンスメントレイヤ３に依存できることを示す。同時放送構成の可能性によって、同時放送構成が用いられるときにＩＤＲおよびＢＬＡ周波数が異なることを可能にするために、ｄｉｒｅｃｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｆｌａｇ［ｉ］［ｊ］に対する制約が再定義されてもよい。言換えると、ＩＤＲおよびＢＬＡの制約は同時放送ストリームの各々に対して制限されてもよいが、同時放送ストリームの各々に対して互いに独立していてもよい。
【００９３】
図１６を参照すると、２つのビデオストリームの同時放送が示され、第１のビデオストリームはベースレイヤ０およびエンハンスメントレイヤ１を含み、第２のビデオストリームはエンハンスメントレイヤ２、エンハンスメントレイヤ３、およびエンハンスメントレイヤ４を含む。図示されるとおり、第１のビデオストリームは、ＰｉｃＯｒｄｅｒＣｎｔＶａｌＢの値を有するＰｉｃＯｒｄｅｒＣｎｔＶａｌに対するＩＤＲ／ＢＬＡピクチャの対応する対６００、６１０を含むのに対し、第２のビデオストリームは、ＰｉｃＯｒｄｅｒＣｎｔＶａｌＢの同じ値を有するＰｉｃＯｒｄｅｒＣｎｔＶａｌに対するＩＤＲ／ＢＬＡピクチャの対応するセット６２０、６３０、６４０を含まない。図示されるとおり、第２のビデオストリームはＩＤＲ／ＢＬＡピクチャの対応するセット６５０、６６０、６７０を含むのに対し、第１のビデオストリームはＩＤＲ／ＢＬＡピクチャの対応する対６８０、６９０を含まない。
【００９４】
図１６を参照すると、この柔軟性は特に、たとえばＶＰＳ拡張におけるレイヤに対してシグナリングされるｄｉｒｅｃｔ＿ｄｅｐｅｎｄｅｎｃｙ＿ｆｌａｇ［ｉ］［ｊ］値を考慮することなどによって達成されてもよい。各レイヤに対して、すなわちそのレイヤが独立であるか（例、０）、または別のレイヤに依存するか（例、１）に対して変数ＩｎｄｅｐＬａｙｅｒ［ｉ］が定められてもよい。このＩｎｄｅｐＬａｙｅｒ［ｉ］は次のとおりに導出されてもよい。
【数１】
0006393317.tif 000003
したがって、図１６に示される実施例に対して、ベースレイヤ０およびエンハンスメントレイヤ２はどちらも独立レイヤである。代替的に、付加的なシンタックスＩｎｄｅｐＬａｙｅｒ［ｉ］を用いずに、ＮｕｍＤｉｒｅｃｔＲｅｆＬａｙｅｒｓ［ｉ］から独立レイヤが推測されてもよい。たとえば、ＮｕｍＤｉｒｅｃｔＲｅｆＬａｙｅｒｓ［ｉ］が０に等しいとき、ＩｎｄｅｐＬａｙｅｒ［ｉ］は１に等しくなる。さらに、ＮｕｍＤｉｒｅｃｔＲｅｆＬａｙｅｒｓ［ｉ］が０に等しくないとき、ＩｎｄｅｐＬａｙｅｒ［ｉ］は０に等しくなる。
【００９５】
シンタックスにおいて、レイヤの識別子を示すｎｕｈ＿ｌａｙｅｒ＿ｉｄは、「特定のＰｉｃＯｒｄｅｒＣｎｔＶａｌ値を有し、かつ特定のＣＶＳ内にある符号化ピクチャに対するｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ値ｎａｌＵｎｉｔＴｙｐｅＡがＩＤＲ＿Ｗ＿ＲＡＤＬ、ＩＤＲ＿Ｎ＿ＬＰ、ＢＬＡ＿Ｗ＿ＬＰ、ＢＬＡ＿Ｗ＿ＲＡＤＬ、またはＢＬＡ＿Ｎ＿ＬＰに等しいとき、ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅ値は、同じ特定のＰｉｃＯｒｄｅｒＣｎｔＶａｌ値を有し、かつ同じ特定のＣＶＳ内にあるすべての符号化ピクチャのすべてのＶＣＬ  ＮＡＬユニットに対してｎａｌＵｎｉｔＴｙｐｅＡに等しくなる」から、前述の同時放送実施形態を可能にするために修正されたセマンティクスに修正される必要がある。ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅに対するセマンティクスは、所望に応じて任意の態様で修正されてもよい。
【００９６】
図１７を参照すると、ビデオストリームは、ベースレイヤおよび１つまたはそれ以上のエンハンスメントレイヤ（ＥＬ１／ＥＬ２／ＥＬ３）を含んでもよい。各時間（Ｔ１／Ｔ２／Ｔ３／Ｔ４／．．．）に対して別個のアクセスユニットが存在し、そのアクセスユニット内にベースレイヤおよび／またはエンハンスメントレイヤ（単数または複数）に対する符号化ピクチャが存在する。たとえば時間＝Ｔ１において、対応するアクセスユニットはベースレイヤ、第１のエンハンスメントレイヤ、第２のエンハンスメントレイヤ、および第３のエンハンスメントレイヤに対する符号化ピクチャを含む。たとえば時間＝Ｔ３において、対応するアクセスユニットは、ベースレイヤおよび第２のエンハンスメントレイヤに対する符号化ピクチャを含むが、第１のエンハンスメントレイヤに対する符号化ピクチャも、第３のエンハンスメントレイヤに対する符号化ピクチャも含まない。たとえば時間Ｔ＝５において、対応するアクセスユニットは、第１のエンハンスメントレイヤ、第２のエンハンスメントレイヤ、第３のエンハンスメントレイヤに対する符号化ピクチャを含むが、ベースレイヤに対する符号化ピクチャを含まない。符号化ピクチャは、たとえばＩＤＲピクチャ、ＢＬＡピクチャ、ＣＲＡピクチャ、非ＩＤＲピクチャ、非ＢＬＡピクチャ、非ＣＲＡピクチャ、トレイリングピクチャ、および／またはリーディングピクチャなどであってもよい。Ｊ．チェン、Ｊ．ボイス、Ｙ．イェ、Ｍ  ハンヌクセラ、ＳＨＶＣドラフト３（ＳＨＶＣ  Ｄｒａｆｔ  ３）、ＪＣＴＶＣ−Ｎ１００８、ウィーン、２０１３年８月は、セクションＦ．８．１．１内に適合要件を含んでおり、ビットストリーム適合の要件は、ＰｉｃＯｒｄｅｒＣｎｔＶａｌがアクセスユニット内で変化しないことである。言換えると、同じアクセスユニット内の各符号化ピクチャは、同じＰｉｃＯｒｄｅｒＣｎｔＶａｌを有する。さらに、ベースレイヤ（ｎｕｈ＿ｌａｙｅｒ＿ｉｄ＝０）に含まれるＩＤＲピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌは、０に設定されるか、または０であると推測される。しかし、非ベースレイヤ（ｎｕｈ＿ｌａｙｅｒ＿ｉｄ＞０）に対する非ＩＤＲピクチャおよびＩＤＲピクチャは、スライスセグメントヘッダにおけるｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂシンタックスエレメントとしてシグナリングされたＰＯＣ  ＬＳＢ値を有してもよく、次いでこの値を用いてＰｉｃＯｒｄｅｒＣｎｔＶａｌの値が導出される。ＰｉｃＯｒｄｅｒＣｎｔＶａｌは最上位ビット（ｍｏｓｔ  ｓｉｇｎｉｆｉｃａｎｔ  ｂｉｔ：ＭＳＢ）および最下位ビット（ｌｅａｓｔ  ｓｉｇｎｉｆｉｃａｎｔ  ｂｉｔ：ＬＳＢ）から導出され、ここでＬＳＢがビットストリームにおいてシグナリングされる。たとえばエンハンスメントレイヤの符号化ピクチャなどに対して、ＬＳＢは０としてシグナリングされるが、ＰｉｃＯｒｄｅｒＣｎｔＶａｌは０でないかもしれない。なぜなら、ＭＳＢはビットストリーム内で直接シグナリングされるのではなく、ビットストリームから定められるからである。したがって、ベースレイヤのＩＤＲのＰｉｃＯｒｄｅｒＣｎｔＶａｌが０であるものとしてシグナリングまたは推測されるときを含み、ＰｉｃＯｒｄｅ��ＣｎｔＶａｌは同じであるがＭＳＢはシンタックス内でシグナリングされないことを保証する方法でシグナルされる、同じアクセスユニット内のすべての符号化ピクチャをもつことが望ましい。
【００９７】
Ｇ．テック、Ｋ．ウェグナー、Ｙ．チェン、Ｍ．ハンヌクセラ、Ｊ．ボイス、「ＭＶ−ＨＥＶＣドラフトテキスト５（ＭＶ−ＨＥＶＣ  Ｄｒａｆｔ  Ｔｅｘｔ  ５）（ＩＳＯ／ＩＥＣ  ２０３００８−２：２０１ｘ／ＰＤＡＭ２）」、ＪＣＴＶＣ−Ｅ１００４、ウィーン、２０１３年８月；Ｊ．チェン、Ｊ．ボイス、Ｙ．イェ、Ｍ  ハンヌクセラ、ＳＨＶＣドラフト３（ＳＨＶＣ  Ｄｒａｆｔ  ３）、ＪＣＴＶＣ−Ｎ１００８、ウィーン、２０１３年８月；およびＹ．チェン、Ｙ．−Ｋ．ワン、Ａ．Ｋ．ラマスブロマニアン、ＭＶ−ＨＥＶＣ／ＳＨＶＣ  ＨＬＳ：クロスレイヤＰＯＣアライメント（Ｃｒｏｓｓ−ｌａｙｅｒ  ＰＯＣ  Ａｌｉｇｎｍｅｎｔ）、ＪＣＴＶＣ−Ｎ０２４４、ウィーン、２０１３年７月は、以下のシンタックスおよびセマンティクスを定義する。
【表２】
0006393317.tif 000004
表２
ｐｏｃ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しいことは、現ピクチャに対する導出ピクチャ順序カウントが０に等しいことを示す。ｐｏｃ＿ｒｅｓｅｔ＿ｆｌａｇが０に等しいことは、現ピクチャに対する導出ピクチャ順序カウントが０に等しいことも、等しくないこともあることを示す。ビットストリーム適合の要件は、ｃｒｏｓｓ＿ｌａｙｅｒ＿ｉｒａｐ＿ａｌｉｇｎｅｄ＿ｆｌａｇが１に等しいときに、ｐｏｃ＿ｒｅｓｅｔ＿ｆｌａｇの値が０に等しくなることである。存在しないとき、ｐｏｃ＿ｒｅｓｅｔ＿ｆｌａｇの値は０に等しいと推測される。
【００９８】
ｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｈｅａｄｅｒにおいてシグナリングされるｐｏｃ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しいとき、その値は、異なるレイヤの符号化ピクチャのピクチャ順序カウントが適合していない可能性があることを示す。次いで、その不適合を改善するために２つの規則が適用される。第１の規則は、復号ピクチャバッファ内にあり、かつ現ピクチャと同じレイヤに属する各ピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌをＰｉｃＯｒｄｅｒＣｎｔＶａｌだけデクリメントすることである。第２の規則は、ＰｉｃＯｒｄｅｒＣｎｔＶａｌを０に等しく設定することである。この態様で、もし現ＰｉｃＯｒｄｅｒＣｎｔＶａｌが０に設定されれば（例、対応するベースレイヤは０のＰｉｃＯｒｄｅｒＣｎｔＶａｌを有するＩＤＲ画像であり、エンハンスメントレイヤの対応する符号化ピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌを０に設定することが望ましい）、復号ピクチャバッファのその他のピクチャにそのデクリメントされた量が適用されることにより、それらのピクチャが互いの相対的アライメントを維持する。
【００９９】
しかし、アクセスユニット内のすべての符号化ピクチャに対するＰｉｃＯｒｄｅｒＣｎｔＶａｌが同じになることを確実にするために、上の２つの規則では不十分である。このため、現ピクチャに対するｐｏｃ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しいときに、０に等しいＴｅｍｐｏｒａｌＩｄと、現ピクチャのｎｕｈ＿ｌａｙｅｒ＿ｉｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄとを有し、かつＲＡＳＬピクチャでも、ＲＡＤＬピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるｐｒｅｖＴｉｄ０ＰｉｃのＰｉｃＯｒｄｅｒＣｎｔＶａｌの変更が必要とされる。
【０１００】
上記の第１の規則により、現ピクチャのスライスセグメントヘッダにおいてｐｏｃ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しくなるようにシグナリングされるときに、現ピクチャと同じレイヤに属するＤＰＢ内の各ピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌのみが現ピクチャに対して算出されたＰｉｃＯｒｄｅｒＣｎｔＶａｌだけデクリメントされる。しかし、後続ピクチャのＰＯＣを算出するとき、およびビットストリーム適合に対してｐｒｅｖＴｉｄ０ＰｉｃのＰｉｃＯｒｄｅｒＣｎｔｌＶａｌが使用されるため、ｐｏｃ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しくなるようにシグナリングされるときに、このＰｉｃＯｒｄｅｒＣｎｔＶａｌも現ピクチャに対して算出されたＰｉｃＯｒｄｅｒＣｎｔＶａｌだけその値をデクリメントすることによって修正する必要がある。これが必要な理由は、場合によってはＤＰＢがｐｒｅｖＴｉｄ０Ｐｉｃ、すなわち０に等しいＴｅｍｐｏｒａｌＩｄと、現ピクチャのｎｕｈ＿ｌａｙｅｒ＿ｉｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄとを有し、かつＲＡＳＬピクチャでも、ＲＡＤＬピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャを含まないことがあるからである。たとえば、ＴｅｍｐｏｒａｌＩｄが０に等しいピクチャがＩＤＲまたはＣＲＡピクチャとして符号化され、かつ低い頻度でしか符号化されないとき、ＤＰＢ内にｐｒｅｖＴｉｄ０Ｐｉｃがないことがある。この場合、ｐｒｅｖＴｉｄ０ＰｉｃはＤＰＢ内にないかもしれないが、ｐｒｅｖＴｉｄ０ＰｉｃのＰｉｃＯｒｄｅｒＣｎｔｌＶａｌのＬＳＢおよびＭＳＢ値は復号プロセスの間追跡されている。この場合、ＭＶ−ＨＥＶＣテキストドラフトＪＣＴ３Ｖ−Ｅ１００４およびＳＨＶＣテキストドラフトＪＣＴＶＣ−Ｎ１００８における現在の動作によって、ｐｒｅｖＴｉｏｄ０ＰｉｃのＰｉｃＯｒｄｅｒＣｎｔｌＶａｌの値が、現ピクチャにおいてリセットされたＰＯＣに対して補償されなくなる。
【０１０１】
ｐｒｅｖＴｉｄ０ＰｉｃのＰｉｃＯｒｄｅｒＣｎｔＶａｌの変更を説明したが、意図されるのは、現ピクチャに対してｐｏｃ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しくなるようにシグナリングされるときに、以下のタイプのピクチャに対して、ＰｉｃＯｒｄｅｒＣｎｔＶａｌ値を現ピクチャに対して算出されたＰｉｃＯｒｄｅｒＣｎｔＶａｌだけデクリメントすることによってＰｉｃＯｒｄｅｒＣｎｔＶａｌ値を同様に補償することが行われるべきだということである。
【０１０２】
ＤＰＢに存在しないかもしれないが、他の後続ピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌを正確に算出するために必要とされるＰｉｃＯｒｄｅｒＣｎｔＶａｌを有する、任意のピクチャ、
デクリメントすることによって補償される前に、現ピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌと同じ相対的オフセットを有する値を有することが必要とされるＰｉｃＯｒｄｅｒＣｎｔＶａｌを有する、任意のピクチャ。
【０１０３】
こうしてこの技術は、現ピクチャのスライスセグメントヘッダにおいてｐｏｃ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しくなるようにシグナリングされるときに、上述のとおりのピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌを、現ピクチャに対して算出されたＰｉｃＯｒｄｅｒＣｎｔＶａｌだけデクリメントすることによって、そのＰｉｃＯｒｄｅｒＣｎｔｌＶａｌを補償する。
【０１０４】
加えて、ｐｒｅｖＴｉｄ０ＰｉｃのＰｉｃＯｒｄｅｒＣｎｔＶａｌに関する動作を補正するために、ＰｉｃＯｒｄｅｒＣｎｔｌＶａｌ導出に対する変更が含まれてもよい。
【０１０５】
図１８を参照すると、レイヤの符号化ピクチャのセットのＴｅｍｐｏｒａｌＩｄが例示的に示される。たとえば、符号化ピクチャＡはＴｅｍｐｏｒａｌＩｄ＝０を有してもよく、かつ符号化ピクチャＡは符号化ピクチャＢ、Ｃ、Ｄ、Ｅ、およびＦに対するｐｒｅｖＴｉｄ０Ｐｉｃである。同様に、ｐｒｅｖＴｉｄ０Ｐｉｃピクチャの役割をするＡのＰｉｃＯｒｄｅｒＣｎｔＶａｌは、符号化ピクチャＢ、Ｃ、Ｄ、Ｅ、およびＦのＰｉｃＯｒｄｅｒＣｎｔＶａｌの算出のために用いられてもよい。たとえば、こうした符号化ピクチャを復号するときに、符号化ピクチャＢ、Ｃ、Ｄ、Ｅ、および／またはＦに対するＰｉｃＯｒｄｅｒＣｎｔＶａｌを算出するときに、符号化ピクチャＡはＤＰＢ内にないことがある。ピクチャＡはＤＰＢ内に存在しないかもしれないが、ピクチャＢ、Ｃ、Ｄ、Ｅ、およびＦのＰｉｃＯｒｄｅｒＣｎｔＶａｌの正確な算出を可能にするように、ピクチャＡのＰｉｃＯｒｄｅｒＣｎｔＶａｌはデコーダによって追跡されている。したがって、ＡすなわちｐｒｅｖＴｉｄ０ＰｉｃピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌを適切な態様でデクリメントすることが望ましい。
【０１０６】
このデクリメントに加えて、ｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂの代わりに導出されたＰｉｃＯｒｄｅｒＣｎｔＶａｌ  ＆（ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ−１）を使用するように、参照ピクチャセットに対する復号プロセスを変更してもよい。ｐｏｃ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しい場合、導出ＰｉｃＯｒｄｅｒＣｎｔＶａｌはリセットされるため、リセットされた可能性のあるＰＯＣの正しいＬＳＢ値を使用するために、この変更が必要である。
【０１０７】
さらに、現ピクチャが１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを有するＩＲＡＰピクチャでないときに、復号ピクチャバッファにおけるこうした変更を説明するために、変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂおよびｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＭｓｂが以下のとおりに導出される。第１に、ｐｒｅｖＴｉｄ０Ｐｉｃは、０に等しいＴｅｍｐｏｒａｌＩｄと、現ピクチャのｎｕｈ＿ｌａｙｅｒ＿ｉｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄとを有し、かつＲＡＳＬピクチャでも、ＲＡＤＬピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるものとし、かつｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔはｐｒｅｖＴｉｄ０ＰｉｃのＰｉｃＯｒｄｅｒＣｎｔＶａｌに等しいものとする。第２に、変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂをｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔ  ＆（ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ−１）に等しく設定する。第３に、変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＭｓｂをｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔ−ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂに等しく設定する。したがって、ＰｉｃＯｒｄｅｒＣｎｔＶａｌが０に設定されるとき、新たなＰｉｃＯｒｄｅｒＣｎｔＶａｌ値からＬＳＢ値を導出することが望ましい。
【０１０８】
ピクチャ順序カウントを含む復号プロセスは、現ピクチャのピクチャ順序カウントＰｉｃＯｒｄｅｒＣｎｔＶａｌである出力を提供する。ピクチャ順序カウントは、ピクチャの識別、マージモードにおける動きパラメータの導出および動きベクトル予測、ならびにデコーダ適合性チェックのために使用される。各符号化ピクチャは、ＰｉｃＯｒｄｅｒＣｎｔＶａｌと示されるピクチャ順序カウント変数に関連付けられる。
【０１０９】
現ピクチャが１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを有するＩＲＡＰピクチャでないとき、変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂおよびｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＭｓｂは次のとおりに導出される。
【０１１０】
（１）ｐｒｅｖＴｉｄ０Ｐｉｃは、０に等しいＴｅｍｐｏｒａｌＩｄと、現ピクチャのｎｕｈ＿ｌａｙｅｒ＿ｉｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄとを有し、かつＲＡＳＬピクチャでも、ＲＡＤＬピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるものとし、かつｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔはｐｒｅｖＴｉｄ０ＰｉｃのＰｉｃＯｒｄｅｒＣｎｔＶａｌに等しいものとする。
【０１１１】
（２）変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂを、ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔ  ＆（ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ−１）に等しく設定する。
【０１１２】
（３）変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＭｓｂを、ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔ−ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂに等しく設定する。
【０１１３】
現ピクチャの変数ＰｉｃＯｒｄｅｒＣｎｔＭｓｂは、次のとおりに導出される。
【０１１４】
（１）もし現ピクチャが１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを有するＩＲＡＰピクチャであれば、ＰｉｃＯｒｄｅｒＣｎｔＭｓｂを０に等しく設定する。
【０１１５】
（２）そうでないときは、ＰｉｃＯｒｄｅｒＣｎｔＭｓｂを次のとおりに導出する。
【数２】
0006393317.tif 000005
ＰｉｃＯｒｄｅｒＣｎｔＶａｌは、次のとおりに導出される。ＰｉｃＯｒｄｅｒＣｎｔＶａｌ＝ＰｉｃＯｒｄｅｒＣｎｔＭｓｂ＋ｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ。なお、すべてのＩＤＲピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌは０に等しくなる。なぜなら、ＩＤＲピクチャに対するｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂは０であると推測され、ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂおよびｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＭｓｂはどちらも０に等しく設定されるからである。
【０１１６】
ｐｏｃ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しいとき、以下のステップがリストされる順序で適用される。
【０１１７】
（１）ＤＰＢ内にあり、かつ現ピクチャと同じレイヤに属する各ピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌを、ＰｉｃＯｒｄｅｒＣｎｔＶａｌだけデクリメントする。
【０１１８】
（２）０に等しいＴｅｍｐｏｒａｌＩｄと、現ピクチャのｎｕｈ＿ｌａｙｅｒ＿ｉｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄとを有し、かつＲＡＳＬピクチャでも、ＲＡＤＬピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるｐｒｅｖＴｉｄ０ＰｉｃのＰｉｃＯｒｄｅｒＣｎｔＶａｌを、ＰｉｃＯｒｄｅｒＣｎｔＶａｌだけデクリメントする。
【０１１９】
（３）現ピクチャのＲＰＳ内の短期参照ピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌを、ＰｉｃＯｒｄｅｒＣｎｔＶａｌだけデクリメントする。
【０１２０】
（４）ＰｉｃＯｒｄｅｒＣｎｔＶａｌを０に等しく設定する。
【０１２１】
ＰｉｃＯｒｄｅｒＣｎｔＶａｌの値は、両端値を含めて−２３１から２３１−１までの範囲内となる。１つのＣＶＳにおいて、同じレイヤ内の任意の２つの符号化ピクチャに対するＰｉｃＯｒｄｅｒＣｎｔＶａｌ値は、同じにならない。
【０１２２】
関数ＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＸ）は、ＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＸ）＝ピクチャｐｉｃＸのＰｉｃＯｒｄｅｒＣｎｔＶａｌと指定される。
【０１２３】
関数ＤｉｆｆＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＡ，ｐｉｃＢ）は、ＤｉｆｆＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＡ，ｐｉｃＢ）＝ＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＡ）−ＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＢ）と指定される。
【０１２４】
ビットストリームは、復号プロセスに用いられるＤｉｆｆＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＡ，ｐｉｃＢ）の値が両端値を含めて−２１５から２１５−１までの範囲にないような値をもたらすデータは含まない。なお、Ｘが現ピクチャであるとし、ＹおよびＺが同じシーケンス内の２つの他のピクチャであるとするとき、ＤｉｆｆＰｉｃＯｒｄｅｒＣｎｔ（Ｘ，Ｙ）およびＤｉｆｆＰｉｃＯｒｄｅｒＣｎｔ（Ｘ，Ｚ）の両方が正であるか、または両方が負であるときは、ＹおよびＺがＸからみて同じ出力順方向にあるものと考えられる。
【０１２５】
状況によっては、復号ピクチャバッファに典型的に含まれる１つまたはそれ以上のピクチャが、たとえばピクチャの送信におけるエラーなどの結果として、復号ピクチャバッファの一部になっていないことがある。上に示したとおり、復号エラーを減らし、かつさまざまなピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌ間の正しい相対的関係を維持するために、こうした状況に適応するために、選択されたｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔをＰｉｃＯｒｄｅｒＣｎｔＶａｌだけデクリメントすることが望ましい。
【０１２６】
参照ピクチャセットに対する復号プロセスも同様に修正されてもよく、このプロセスは、スライスヘッダの復号の後、任意の符号化ユニットの復号より前、かつスライスに対する参照ピクチャリスト構築のための復号プロセスより前に、ピクチャ当り1回呼び出される。このプロセスの結果として、復号ピクチャバッファ内の１つまたはそれ以上の参照ピクチャが「参照に使用せず」または「長期参照に使用」とマーク付けされてもよい。このマーク付けは同じ値のｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するピクチャのみをマーク付けするものであり、現ピクチャと異なるｎｕｈ＿ｌａｙｅｒ＿ｉｄを有する任意のピクチャはマーク付けしない。ＲＰＳは、現在および将来の符号化ピクチャの復号プロセスにおいて用いられる参照ピクチャの絶対記述である。ＲＰＳに含まれるすべての参照ピクチャが明示的にリストされるという意味において、ＲＰＳシグナリングは明示的である。
【０１２７】
ＤＰＢ内の復号ピクチャは「参照に使用せず」、「短期参照に使用」、または「長期参照に使用」とマーク付けされるが、復号プロセスの動作中のあらゆる所与の瞬間に、これら３つのうちの１つしかマーク付けされない。これらのマーク付けのうちの１つをあるピクチャに割り当てることによって、適用可能なときにこれらのマーク付けのうちの別のものが暗示的に除去される。ピクチャが「参照に使用」とマーク付けされていることが示されるとき、このことはピクチャが「短期参照に使用」または「長期参照に使用」とマーク付けされている（ただし両方ではない）ことを集合的に示す。
【０１２８】
変数ｃｕｒｒＰｉｃＬａｙｅｒＩｄは、現ピクチャのｎｕｈ＿ｌａｙｅｒ＿ｉｄとなるように設定される。
【０１２９】
現ピクチャが、１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを有するＩＲＡＰピクチャであるとき、（もしあれば）現在ＤＰＢ内に存在するｃｕｒｒＰｉｃＬａｙｅｒＩｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するすべての参照ピクチャが「参照に使用せず」とマーク付けされる。
【０１３０】
短期参照ピクチャは、それらのピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌ値によって識別される。長期参照ピクチャは、それらのピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌ値またはそれらのピクチャのｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ値のいずれかによって識別される。
【０１３１】
ＲＰＳを導出するために、ピクチャ順序カウント値の５つのリストが構築される。これら５つのリストは、それぞれＮｕｍＰｏｃＳｔＣｕｒｒＢｅｆｏｒｅ、ＮｕｍＰｏｃＳｔＣｕｒｒＡｆｔｅｒ、ＮｕｍＰｏｃＳｔＦｏｌｌ、ＮｕｍＰｏｃＬｔＣｕｒｒ、およびＮｕｍＰｏｃＬｔＦｏｌｌのエレメント数を有するＰｏｃＳｔＣｕｒｒＢｅｆｏｒｅ、ＰｏｃＳｔＣｕｒｒＡｆｔｅｒ、ＰｏｃＳｔＦｏｌｌ、ＰｏｃＬｔＣｕｒｒ、およびＰｏｃＬｔＦｏｌｌである。これら５つのリストおよび５つの変数は、次のとおりに導出される。
【０１３２】
もし現ピクチャがＩＤＲピクチャであれば、ＰｏｃＳｔＣｕｒｒＢｅｆｏｒｅ、ＰｏｃＳｔＣｕｒｒＡｆｔｅｒ、ＰｏｃＳｔＦｏｌｌ、ＰｏｃＬｔＣｕｒｒ、およびＰｏｃＬｔＦｏｌｌはすべて空になるように設定され、かつＮｕｍＰｏｃＳｔＣｕｒｒＢｅｆｏｒｅ、ＮｕｍＰｏｃＳｔＣｕｒｒＡｆｔｅｒ、ＮｕｍＰｏｃＳｔＦｏｌｌ、ＮｕｍＰｏｃＬｔＣｕｒｒ、およびＮｕｍＰｏｃＬｔＦｏｌｌはすべて０に等しく設定される。
【０１３３】
そうでないときは、以下が適用される。
【数３】
0006393317.tif 000006
0006393317.tif 000007
ここで、ＰｉｃＯｒｄｅｒＣｎｔＶａｌは現ピクチャのピクチャ順序カウントである。ＣｕｒｒＲｐｓＩｄｘの値が、両端値を含めて０からｎｕｍ＿ｓｈｏｒｔ＿ｔｅｒｍ＿ｒｅｆ＿ｐｉｃ＿ｓｅｔｓ−１までの範囲内にあることは、アクティブＳＰＳからの候補短期ＲＰＳが用いられていることを示し、ここでＣｕｒｒＲｐｓＩｄｘは、アクティブＳＰＳにおいてシグナリングされる候補短期ＲＰＳのリストに入る候補短期ＲＰＳのインデックスである。ＣｕｒｒＲｐｓＩｄｘがｎｕｍ＿ｓｈｏｒｔ＿ｔｅｒｍ＿ｒｅｆ＿ｐｉｃ＿ｓｅｔｓに等しいことは、現ピクチャの短期ＲＰＳがスライスヘッダにおいて直接シグナリングされることを示す。
【０１３４】
両端値を含めて０からＮｕｍＰｏｃＬｔＣｕｒｒ−１までの範囲内の各ｉに対して、ＣｕｒｒＤｅｌｔａＰｏｃＭｓｂＰｒｅｓｅｎｔＦｌａｇ［ｉ］が１に等しいとき、次の条件が適用されることがビットストリーム適合の要件である。
【０１３５】
ＰｏｃＬｔＣｕｒｒ［ｉ］がＰｏｃＳｔＣｕｒｒＢｅｆｏｒｅ［ｊ］に等しくなるような、両端値を含めて０からＮｕｍＰｏｃＳｔＣｕｒｒＢｅｆｏｒｅ−１までの範囲内のｊは存在しない。
【０１３６】
ＰｏｃＬｔＣｕｒｒ［ｉ］がＰｏｃＳｔＣｕｒｒＡｆｔｅｒ［ｊ］に等しくなるような、両端値を含めて０からＮｕｍＰｏｃＳｔＣｕｒｒＡｆｔｅｒ−１までの範囲内のｊは存在しない。
【０１３７】
ＰｏｃＬｔＣｕｒｒ［ｉ］がＰｏｃＳｔＦｏｌｌ［ｊ］に等しくなるような、両端値を含めて０からＮｕｍＰｏｃＳｔＦｏｌｌ−１までの範囲内のｊは存在しない。
【０１３８】
ｊがｉに等しくないとき、ＰｏｃＬｔＣｕｒｒ［ｉ］がＰｏｃＬｔＣｕｒｒ［ｊ］に等しくなるような、両端値を含めて０からＮｕｍＰｏｃＬｔＣｕｒｒ−１までの範囲内のｊは存在しない。
【０１３９】
両端値を含めて０からＮｕｍＰｏｃＬｔＦｏｌｌ−１までの範囲内の各ｉに対して、ＦｏｌｌＤｅｌｔａＰｏｃＭｓｂＰｒｅｓｅｎｔＦｌａｇ［ｉ］が１に等しいとき、次の条件が適用されることがビットストリーム適合の要件である。
【０１４０】
ＰｏｃＬｔＦｏｌｌ［ｉ］がＰｏｃＳｔＣｕｒｒＢｅｆｏｒｅ［ｊ］に等しくなるような、両端値を含めて０からＮｕｍＰｏｃＳｔＣｕｒｒＢｅｆｏｒｅ−１までの範囲内のｊは存在しない。
【０１４１】
ＰｏｃＬｔＦｏｌｌ［ｉ］がＰｏｃＳｔＣｕｒｒＡｆｔｅｒ［ｊ］に等しくなるような、両端値を含めて０からＮｕｍＰｏｃＳｔＣｕｒｒＡｆｔｅｒ−１までの範囲内のｊは存在しない。
【０１４２】
ＰｏｃＬｔＦｏｌｌ［ｉ］がＰｏｃＳｔＦｏｌｌ［ｊ］に等しくなるような、両端値を含めて０からＮｕｍＰｏｃＳｔＦｏｌｌ−１までの範囲内のｊは存在しない。
【０１４３】
ｊがｉに等しくないとき、ＰｏｃＬｔＦｏｌｌ［ｉ］がＰｏｃＬｔＦｏｌｌ［ｊ］に等しくなるような、両端値を含めて０からＮｕｍＰｏｃＬｔＦｏｌｌ−１までの範囲内のｊは存在しない。
【０１４４】
ＰｏｃＬｔＦｏｌｌ［ｉ］がＰｏｃＬｔＣｕｒｒ［ｊ］に等しくなるような、両端値を含めて０からＮｕｍＰｏｃＬｔＣｕｒｒ−１までの範囲内のｊは存在しない。
【０１４５】
両端値を含めて０からＮｕｍＰｏｃＬｔＣｕｒｒ−１までの範囲内の各ｉに対して、ＣｕｒｒＤｅｌｔａＰｏｃＭｓｂＰｒｅｓｅｎｔＦｌａｇ［ｉ］が０に等しいとき、次の条件が適用されることがビットストリーム適合の要件である。
【０１４６】
ＰｏｃＬｔＣｕｒｒ［ｉ］が（ＰｏｃＳｔＣｕｒｒＢｅｆｏｒｅ［ｊ］＆（ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ−１））に等しくなるような、両端値を含めて０からＮｕｍＰｏｃＳｔＣｕｒｒＢｅｆｏｒｅ−１までの範囲内のｊは存在しない。
【０１４７】
ＰｏｃＬｔＣｕｒｒ［ｉ］が（ＰｏｃＳｔＣｕｒｒＡｆｔｅｒ［ｊ］＆（ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ−１））に等しくなるような、両端値を含めて０からＮｕｍＰｏｃＳｔＣｕｒｒＡｆｔｅｒ−１までの範囲内のｊは存在しない。
【０１４８】
ＰｏｃＬｔＣｕｒｒ［ｉ］が（ＰｏｃＳｔＦｏｌｌ［ｊ］＆（ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ−１））に等しくなるような、両端値を含めて０からＮｕｍＰｏｃＳｔＦｏｌｌ−１までの範囲内のｊは存在しない。
【０１４９】
ｊがｉに等しくないとき、ＰｏｃＬｔＣｕｒｒ［ｉ］が（ＰｏｃＬｔＣｕｒｒ［ｊ］＆（ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ−１））に等しくなるような、両端値を含めて０からＮｕｍＰｏｃＬｔＣｕｒｒ−１までの範囲内のｊは存在しない。
【０１５０】
両端値を含めて０からＮｕｍＰｏｃＬｔＦｏｌｌ−１までの範囲内の各ｉに対して、ＦｏｌｌＤｅｌｔａＰｏｃＭｓｂＰｒｅｓｅｎｔＦｌａｇ［ｉ］が０に等しいとき、次の条件が適用されることがビットストリーム適合の要件である。
【０１５１】
ＰｏｃＬｔＦｏｌｌ［ｉ］が（ＰｏｃＳｔＣｕｒｒＢｅｆｏｒｅ［ｊ］＆（ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ−１））に等しくなるような、両端値を含めて０からＮｕｍＰｏｃＳｔＣｕｒｒＢｅｆｏｒｅ−１までの範囲内のｊは存在しない。
【０１５２】
ＰｏｃＬｔＦｏｌｌ［ｉ］が（ＰｏｃＳｔＣｕｒｒＡｆｔｅｒ［ｊ］＆（ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ−１））に等しくなるような、両端値を含めて０からＮｕｍＰｏｃＳｔＣｕｒｒＡｆｔｅｒ−１までの範囲内のｊは存在しない。
【０１５３】
ＰｏｃＬｔＦｏｌｌ［ｉ］が（ＰｏｃＳｔＦｏｌｌ［ｊ］＆（ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ−１））に等しくなるような、両端値を含めて０からＮｕｍＰｏｃＳｔＦｏｌｌ−１までの範囲内のｊは存在しない。
【０１５４】
ｊがｉに等しくないとき、ＰｏｃＬｔＦｏｌｌ［ｉ］が（ＰｏｃＬｔＦｏｌｌ［ｊ］＆（ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ−１））に等しくなるような、両端値を含めて０からＮｕｍＰｏｃＬｔＦｏｌｌ−１までの範囲内のｊは存在しない。
【０１５５】
ＰｏｃＬｔＦｏｌｌ［ｉ］が（ＰｏｃＬｔＣｕｒｒ［ｊ］＆（ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ−１））に等しくなるような、両端値を含めて０からＮｕｍＰｏｃＬｔＣｕｒｒ−１までの範囲内のｊは存在しない。
【０１５６】
変数ＮｕｍＰｉｃＴｏｔａｌＣｕｒｒが導出される。ＮｕｍＰｉｃＴｏｔａｌＣｕｒｒの値に対して以下が適用されることが、ビットストリーム適合の要件である。
【０１５７】
ｎｕｈ＿ｌａｙｅｒ＿ｉｄが０に等しく、かつ現ピクチャがＢＬＡピクチャまたはＣＲＡピクチャであるとき、ＮｕｍＰｉｃＴｏｔａｌＣｕｒｒの値は０に等しくなる。
【０１５８】
そうでなければ、現ピクチャがＰまたはＢスライスを含むとき、ＮｕｍＰｉｃＴｏｔａｌＣｕｒｒの値は０に等しくならない。
【０１５９】
現ピクチャのＲＰＳは、５つのＲＰＳリストからなる。すなわち、ＲｅｆＰｉｃＳｅｔＳｔＣｕｒｒＢｅｆｏｒｅ、ＲｅｆＰｉｃＳｅｔＳｔＣｕｒｒＡｆｔｅｒ、ＲｅｆＰｉｃＳｅｔＳｔＦｏｌｌ、ＲｅｆＰｉｃＳｅｔＬｔＣｕｒｒ、およびＲｅｆＰｉｃＳｅｔＬｔＦｏｌｌである。ＲｅｆＰｉｃＳｅｔＳｔＣｕｒｒＢｅｆｏｒｅ、ＲｅｆＰｉｃＳｅｔＳｔＣｕｒｒＡｆｔｅｒ、およびＲｅｆＰｉｃＳｅｔＳｔＦｏｌｌは、集合的に短期ＲＰＳと呼ばれる。ＲｅｆＰｉｃＳｅｔＬｔＣｕｒｒおよびＲｅｆＰｉｃＳｅｔＬｔＦｏｌｌは、集合的に長期ＲＰＳと呼ばれる。ＲｅｆＰｉｃＳｅｔＳｔＣｕｒｒＢｅｆｏｒｅ、ＲｅｆＰｉｃＳｅｔＳｔＣｕｒｒＡｆｔｅｒ、およびＲｅｆＰｉｃＳｅｔＬｔＣｕｒｒは、現ピクチャと、復号順で現ピクチャに続く１つまたはそれ以上のピクチャとのインター予測に用いられるすべての参照ピクチャを含む。ＲｅｆＰｉｃＳｅｔＳｔＦｏｌｌおよびＲｅｆＰｉｃＳｅｔＬｔＦｏｌｌは、現ピクチャのインター予測には用いられないが、復号順で現ピクチャに続く１つまたはそれ以上のピクチャに対するインター予測に用いられるすべての参照ピクチャからなる。
【０１６０】
ＲＰＳおよびピクチャのマーク付けに対する導出プロセスは、以下の順序ステップに従って行われる。
【０１６１】
以下が適用される。
【数４】
0006393317.tif 000008
（２）ＲｅｆＰｉｃＳｅｔＬｔＣｕｒｒおよびＲｅｆＰｉｃＳｅｔＬｔＦｏｌｌに含まれ、かつｎｕｈ＿ｌａｙｅｒ＿ｉｄがｃｕｒｒＰｉｃＬａｙｅｒＩｄに等しいすべての参照ピクチャは、「長期参照に使用」とマーク付けされる。
【０１６２】
（３）以下が適用される。
【数５】
0006393317.tif 000009
（４）ＲｅｆＰｉｃＳｅｔＬｔＣｕｒｒ、ＲｅｆＰｉｃＳｅｔＬｔＦｏｌｌ、ＲｅｆＰｉｃＳｅｔＳｔＣｕｒｒＢｅｆｏｒｅ、ＲｅｆＰｉｃＳｅｔＳｔＣｕｒｒＡｆｔｅｒ、またはＲｅｆＰｉｃＳｅｔＳｔＦｏｌｌに含まれず、かつｎｕｈ＿ｌａｙｅｒ＿ｉｄがｃｕｒｒＰｉｃＬａｙｅｒＩｄに等しいＤＰＢ内のすべての参照ピクチャは、「参照に使用せず」とマーク付けされる。
【０１６３】
ＲＰＳリストには、対応するピクチャがＤＰＢに存在しないために「参照ピクチャなし」に等しい１つまたはそれ以上のエントリが存在してもよい。ＲｅｆＰｉｃＳｅｔＳｔＦｏｌｌまたはＲｅｆＰｉｃＳｅｔＬｔＦｏｌｌ内の「参照ピクチャなし」に等しいエントリは、無視されるべきである。ＲｅｆＰｉｃＳｅｔＳｔＣｕｒｒＢｅｆｏｒｅ、ＲｅｆＰｉｃＳｅｔＳｔＣｕｒｒＡｆｔｅｒ、またはＲｅｆＰｉｃＳｅｔＬｔＣｕｒｒ内の「参照ピクチャなし」に等しい各エントリに対しては、意図的でないピクチャの損失が推測されるべきである。あるピクチャが、５つのＲＰＳリストの２つ以上に含まれることはできない。本明細書に記載される特徴またはエレメントのいずれかが所望に応じて省略されたり、別様に異なる態様で組み換えられたりすることが理解されるべきである。
【０１６４】
次に、もういくつかの変形実施形態を説明する。１つの例示的実施形態においては、ＰｉｃＯｒｄｅｒＣｎｔＶａｌのリセットをシグナリングするためにｐｏｃ＿ｒｅｓｅｔ＿ｆｌａｇをシグナリングする代わりに、表（３）に示されるとおりに２つの別個のフラグｐｏｃ＿ｍｓｂ＿ｒｅｓｅｔ＿ｆｌａｇおよびｐｏｃ＿ｌｓｂ＿ｒｅｓｅｔ＿ｆｌａｇがシグナリングされてもよい。
【表３】
0006393317.tif 000010
表（３）
ｐｏｃ＿ｍｓｂ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しいことは、現ピクチャに対する導出ピクチャ順序カウントのＭＳＢ値が０に等しいことを示してもよい。ｐｏｃ＿ｍｓｂ＿ｒｅｓｅｔ＿ｆｌａｇが０に等しいことは、現ピクチャに対する導出ピクチャ順序カウントのＭＳＢ値が０に等しいことも、等しくないこともあることを示してもよい。
【０１６５】
存在しないとき、ｐｏｃ＿ｍｓｂ＿ｒｅｓｅｔ＿ｆｌａｇの値は０に等しいと推測されてもよい。
【０１６６】
ｐｏｃ＿ｌｓｂ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しいことは、現ピクチャに対する導出ピクチャ順序カウントが０に等しいことを示してもよい。ｐｏｃ＿ｌｓｂ＿ｒｅｓｅｔ＿ｆｌａｇが０に等しいことは、現ピクチャに対する導出ピクチャ順序カウントが０に等しいことも、等しくないこともあることを示してもよい。
【０１６７】
存在しないとき、ｐｏｃ＿ｌｓｂ＿ｒｅｓｅｔ＿ｆｌａｇの値は０に等しいと推測されてもよい。
【０１６８】
ｐｏｃ＿ｍｓｂ＿ｒｅｓｅｔ＿ｆｌａｇの値が０に等しいとき、ｐｏｃ＿ｌｓｂ＿ｒｅｓｅｔ＿ｆｌａｇの値は０に等しいことが要求されてもよい。
【０１６９】
次いで、ＰｉｃＯｒｄｅｒＣｎｔＶａｌに対する復号プロセスが次のとおりに修正されてもよい。
【０１７０】
現ピクチャが１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを有するＩＲＡＰピクチャではないとき、変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂおよびｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＭｓｂは、以下のとおりに導出される。第１に、ｐｒｅｖＴｉｄ０Ｐｉｃは、０に等しいＴｅｍｐｏｒａｌＩｄと、現ピクチャのｎｕｈ＿ｌａｙｅｒ＿ｉｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄとを有し、かつＲＡＳＬピクチャでも、ＲＡＤＬピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるものとし、かつｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔはｐｒｅｖＴｉｄ０ＰｉｃのＰｉｃＯｒｄｅｒＣｎｔＶａｌに等しいものとする。第２に、変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂをｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔ  ＆（ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ−１）に等しく設定する。第３に、変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＭｓｂをｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔ−ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂに等しく設定する。したがって、ＰｉｃＯｒｄｅｒＣｎｔＶａｌが０に設定されるとき、新たなＰｉｃＯｒｄｅｒＣｎｔＶａｌ値からＬＳＢ値を導出することが望ましい。
【０１７１】
ピクチャ順序カウントを含む復号プロセスは、現ピクチャのピクチャ順序カウントＰｉｃＯｒｄｅｒＣｎｔＶａｌである出力を提供する。ピクチャ順序カウントは、ピクチャの識別、マージモードにおける動きパラメータの導出および動きベクトル予測、ならびにデコーダ適合性チェックのために使用される。各符号化ピクチャは、ＰｉｃＯｒｄｅｒＣｎｔＶａｌと示されるピクチャ順序カウント変数に関連付けられる。
【０１７２】
現ピクチャが１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを有するＩＲＡＰピクチャではないとき、変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂおよびｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＭｓｂは、以下のとおりに導出される。
【０１７３】
（１）ｐｒｅｖＴｉｄ０Ｐｉｃは、０に等しいＴｅｍｐｏｒａｌＩｄと、現ピクチャのｎｕｈ＿ｌａｙｅｒ＿ｉｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄとを有し、かつＲＡＳＬピクチャでも、ＲＡＤＬピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるものとし、かつｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔはｐｒｅｖＴｉｄ０ＰｉｃのＰｉｃＯｒｄｅｒＣｎｔＶａｌに等しいものとする。
【０１７４】
（２）変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂを、ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔ  ＆（ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ−１）に等しく設定する。
【０１７５】
（３）変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＭｓｂを、ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔ−ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂに等しく設定する。
【０１７６】
現ピクチャの変数ＰｉｃＯｒｄｅｒＣｎｔＭｓｂは、次のとおりに導出される。
【０１７７】
（１）もし現ピクチャが１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを有するＩＲＡＰピクチャであれば、ＰｉｃＯｒｄｅｒＣｎｔＭｓｂを０に等しく設定する。
【０１７８】
（２）そうでないときは、ＰｉｃＯｒｄｅｒＣｎｔＭｓｂを次のとおりに導出する。
【数６】
0006393317.tif 000011
ＰｉｃＯｒｄｅｒＣｎｔＶａｌは、次のとおりに導出される。ＰｉｃＯｒｄｅｒＣｎｔＶａｌ＝（ｐｏｃ＿ｍｓｂ＿ｒｅｓｅｔ＿ｆｌａｇ？０：ＰｉｃＯｒｄｅｒＣｎｔＭｓｂ）＋（ｐｏｃ＿ｌｓｂ＿ｒｅｓｅｔ＿ｆｌａｇ？０：ｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ）。
【０１７９】
なお、０に等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄを有するすべてのＩＤＲピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌは０に等しくなる。なぜなら、ＩＤＲピクチャに対するｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂは０であると推測され、ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂおよびｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＭｓｂはどちらも０に等しく設定されるからである。
【０１８０】
ｐｏｃ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しいときは、以下のステップが適用される。
【０１８１】
（１）ｐｏｃ＿ｍｓｂ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しいとき、ＤＰＢ内にあり、かつ現ピクチャと同じレイヤに属する各ピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌを、ＰｉｃＯｒｄｅｒＣｎｔＭｓｂだけデクリメントする。
【０１８２】
（２）ｐｏｃ＿ｍｓｂ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しいとき、０に等しいＴｅｍｐｏｒａｌＩｄと、現ピクチャのｎｕｈ＿ｌａｙｅｒ＿ｉｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄとを有し、かつＲＡＳＬピクチャでも、ＲＡＤＬピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるｐｒｅｖＴｉｄ０ＰｉｃのＰｉｃＯｒｄｅｒＣｎｔＶａｌを、ＰｉｃＯｒｄｅｒＣｎｔＭｓｂだけデクリメントする。
【０１８３】
（３）ｐｏｃ＿ｍｓｂ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しいとき、現ピクチャのＲＰＳ内の短期参照ピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌを、ＰｉｃＯｒｄｅｒＣｎｔＭｓｂだけデクリメントする。
【０１８４】
（４）ｐｏｃ＿ｌｓｂ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しいとき、ＤＰＢ内にあり、かつ現ピクチャと同じレイヤに属する各ピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌを、ｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂだけデクリメントする。
【０１８５】
（５）ｐｏｃ＿ｌｓｂ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しいとき、０に等しいＴｅｍｐｏｒａｌＩｄと、現ピクチャのｎｕｈ＿ｌａｙｅｒ＿ｉｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄとを有し、かつＲＡＳＬピクチャでも、ＲＡＤＬピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるｐｒｅｖＴｉｄ０ＰｉｃのＰｉｃＯｒｄｅｒＣｎｔＶａｌを、ｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂだけデクリメントする。
【０１８６】
（６）ｐｏｃ＿ｌｓｂ＿ｒｅｓｅｔ＿ｆｌａｇが等しいとき、現ピクチャのＲＰＳ内の短期参照ピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌを、ｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂだけデクリメントする。
【０１８７】
ＰｉｃＯｒｄｅｒＣｎｔＶａｌの値は、両端値を含めて−２３１から２３１−１までの範囲内となる。１つのＣＶＳにおいて、同じレイヤ内の任意の２つの符号化ピクチャに対するＰｉｃＯｒｄｅｒＣｎｔＶａｌ値は、同じにならない。
【０１８８】
関数ＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＸ）は、ＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＸ）＝ピクチャｐｉｃＸのＰｉｃＯｒｄｅｒＣｎｔＶａｌと指定される。
【０１８９】
関数ＤｉｆｆＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＡ，ｐｉｃＢ）は、ＤｉｆｆＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＡ，ｐｉｃＢ）＝ＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＡ）−ＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＢ）と指定される。
【０１９０】
ビットストリームは、復号プロセスに用いられるＤｉｆｆＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＡ，ｐｉｃＢ）の値が両端値を含めて−２１５から２１５−１までの範囲にないような値をもたらすデータは含まない。なお、Ｘが現ピクチャであるとし、ＹおよびＺが同じシーケンス内の２つの他のピクチャであるとするとき、ＤｉｆｆＰｉｃＯｒｄｅｒＣｎｔ（Ｘ，Ｙ）およびＤｉｆｆＰｉｃＯｒｄｅｒＣｎｔ（Ｘ，Ｚ）の両方が正であるか、または両方が負であるときは、ＹおよびＺがＸからみて同じ出力順方向にあるものと考えられる。
【０１９１】
次に、別の変形実施形態を説明する。１つの例示的実施形態においては、クロスレイヤＰＯＣアライメントを達成するために、３２ビットＰＯＣデクリメント値がシグナリングされてもよい。たとえば、表（４）に示されるとおり、この３２ビットＰＯＣデクリメント値は、ベースレイヤＩＤＲピクチャのスライスヘッダ拡張においてシグナリングされてもよい。
【表４】
0006393317.tif 000012
表（４）
「ｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｈｅａｄｅｒ＿ｅｘｔｅｎｓｉｏｎ＿ｌｅｎｇｔｈ」は、ｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｈｅａｄｅｒ＿ｅｘｔｅｎｓｉｏｎ＿ｌｅｎｇｔｈ自身をシグナリングするために用いられるビットを含まない、スライスセグメントヘッダ拡張データの長さをバイト数で示してもよい。ｎｕｈ＿ｌａｙｅｒ＿ｉｄおよびｃｒｏｓｓ＿ｌａｙｅｒ＿ｉｒａｐ＿ａｌｉｇｎｅｄ＿ｆｌａｇの両方が０に等しいとき、ＩＤＲ＿Ｗ＿ＲＡＤＬおよびＩＤＲ＿Ｎ＿ＬＰ  ＮＡＬユニットに対するｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｈｅａｄｅｒ＿ｅｘｔｅｎｓｉｏｎ＿ｌｅｎｇｔｈは４以上になることが、ビットストリーム適合の要件である。ｓｌｉｃｅ＿ｓｅｇｍｅｎｔ＿ｈｅａｄｅｒ＿ｅｘｔｅｎｓｉｏｎ＿ｌｅｎｇｔｈの値は、両端値を含めて０から２５６までの範囲内となる。
【０１９２】
「ｐｏｃ＿ｄｅｃｒｅｍｅｎｔ」は、現ピクチャに対して用いられるべきピクチャ順序カウントデクリメントを示してもよい。存在しないとき、ｐｏｃ＿ｄｅｃｒｅｍｅｎｔの値は０に等しいと推測される。
【０１９３】
次いで、ＰｉｃＯｒｄｅｒＣｎｔＶａｌに対する復号プロセスが次のとおりに修正されてもよい。
【０１９４】
現ピクチャが１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを有するＩＲＡＰピクチャではないとき、変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂおよびｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＭｓｂは、以下のとおりに導出される。第１に、ｐｒｅｖＴｉｄ０Ｐｉｃは、０に等しいＴｅｍｐｏｒａｌＩｄと、現ピクチャのｎｕｈ＿ｌａｙｅｒ＿ｉｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄとを有し、かつＲＡＳＬピクチャでも、ＲＡＤＬピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるものとし、かつｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔはｐｒｅｖＴｉｄ０ＰｉｃのＰｉｃＯｒｄｅｒＣｎｔＶａｌに等しいものとする。第２に、変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂをｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔ  ＆（ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ−１）に等しく設定する。第３に、変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＭｓｂをｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔ−ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂに等しく設定する。したがって、ＰｉｃＯｒｄｅｒＣｎｔＶａｌが０に設定されるとき、新たなＰｉｃＯｒｄｅｒＣｎｔＶａｌ値からＬＳＢ値を導出することが望ましい。
【０１９５】
ピクチャ順序カウントを含む復号プロセスは、現ピクチャのピクチャ順序カウントＰｉｃＯｒｄｅｒＣｎｔＶａｌである出力を提供する。ピクチャ順序カウントは、ピクチャの識別、マージモードにおける動きパラメータの導出および動きベクトル予測、ならびにデコーダ適合性チェックのために使用される。各符号化ピクチャは、ＰｉｃＯｒｄｅｒＣｎｔＶａｌと示されるピクチャ順序カウント変数に関連付けられる。
【０１９６】
現ピクチャが１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを有するＩＲＡＰピクチャではないとき、変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂおよびｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＭｓｂは、以下のとおりに導出される。
【０１９７】
（１）ｐｒｅｖＴｉｄ０Ｐｉｃは、０に等しいＴｅｍｐｏｒａｌＩｄと、現ピクチャのｎｕｈ＿ｌａｙｅｒ＿ｉｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄとを有し、かつＲＡＳＬピクチャでも、ＲＡＤＬピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるものとし、かつｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔはｐｒｅｖＴｉｄ０ＰｉｃのＰｉｃＯｒｄｅｒＣｎｔＶａｌに等しいものとする。
【０１９８】
（２）変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂを、ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔ  ＆（ＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ−１）に等しく設定する。
【０１９９】
（３）変数ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＭｓｂを、ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔ−ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂに等しく設定する。
【０２００】
現ピクチャの変数ＰｉｃＯｒｄｅｒＣｎｔＭｓｂは、次のとおりに導出される。
【０２０１】
（１）もし現ピクチャが１に等しいＮｏＲａｓｌＯｕｔｐｕｔＦｌａｇを有するＩＲＡＰピクチャであれば、ＰｉｃＯｒｄｅｒＣｎｔＭｓｂを０に等しく設定する。
【０２０２】
（２）そうでないときは、ＰｉｃＯｒｄｅｒＣｎｔＭｓｂを次のとおりに導出する。
【数７】
0006393317.tif 000013
ＰｉｃＯｒｄｅｒＣｎｔＶａｌは、次のとおりに導出される。ＰｉｃＯｒｄｅｒＣｎｔＶａｌ＝ＰｉｃＯｒｄｅｒＣｎｔＭｓｂ＋ｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂ。
【０２０３】
なお、すべてのＩＤＲピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌは０に等しくなる。なぜなら、ＩＤＲピクチャに対するｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂは０であると推測され、ｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＬｓｂおよびｐｒｅｖＰｉｃＯｒｄｅｒＣｎｔＭｓｂはどちらも０に等しく設定されるからである。
【０２０４】
ｐｏｃ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しいとき、以下のステップが適用される。
【０２０５】
（１）ＤＰＢ内にある各ピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌを、ｐｏｃ＿ｄｅｃｒｅｍｅｎｔだけデクリメントする。
【０２０６】
（２）０に等しいＴｅｍｐｏｒａｌＩｄと、現ピクチャのｎｕｈ＿ｌａｙｅｒ＿ｉｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄとを有し、かつＲＡＳＬピクチャでも、ＲＡＤＬピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるｐｒｅｖＴｉｄ０ＰｉｃのＰｉｃＯｒｄｅｒＣｎｔＶａｌを、ｐｏｃ＿ｄｅｃｒｅｍｅｎｔだけデクリメントする。
【０２０７】
ＰｉｃＯｒｄｅｒＣｎｔＶａｌの値は、両端値を含めて−２３１から２３１−１までの範囲内となる。１つのＣＶＳにおいて、同じレイヤ内の任意の２つの符号化ピクチャに対するＰｉｃＯｒｄｅｒＣｎｔＶａｌ値は、同じにならない。
【０２０８】
関数ＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＸ）は、ＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＸ）＝ピクチャｐｉｃＸのＰｉｃＯｒｄｅｒＣｎｔＶａｌと指定される。
【０２０９】
関数ＤｉｆｆＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＡ，ｐｉｃＢ）は、ＤｉｆｆＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＡ，ｐｉｃＢ）＝ＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＡ）−ＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＢ）と指定される。
【０２１０】
ビットストリームは、復号プロセスに用いられるＤｉｆｆＰｉｃＯｒｄｅｒＣｎｔ（ｐｉｃＡ，ｐｉｃＢ）の値が両端値を含めて−２１５から２１５−１までの範囲にないような値をもたらすデータは含まない。なお、Ｘが現ピクチャであるとし、ＹおよびＺが同じシーケンス内の２つの他のピクチャであるとするとき、ＤｉｆｆＰｉｃＯｒｄｅｒＣｎｔ（Ｘ，Ｙ）およびＤｉｆｆＰｉｃＯｒｄｅｒＣｎｔ（Ｘ，Ｚ）の両方が正であるか、または両方が負であるときは、ＹおよびＺがＸからみて同じ出力順方向にあるものと考えられる。
【０２１１】
上述のすべての実施形態において、現ピクチャに対するビットストリーム適合性をチェックするときには、０に等しいＴｅｍｐｏｒａｌＩｄと、現ピクチャのｎｕｈ＿ｌａｙｅｒ＿ｉｄに等しいｎｕｈ＿ｌａｙｅｒ＿ｉｄとを有し、かつＲＡＳＬピクチャでも、ＲＡＤＬピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャであるｐｒｅｖＴｉｄ０Ｐｉｃの、（デクリメントによって）修正されたＰｉｃＯｒｄｅｒＣｎｔＶａｌ値が用いられる。
【０２１２】
さらに別の代替的実施形態においては、標準仕様に対するビットストリームの適合を確認するために、以下のプロセスが行われてもよい。
【０２１３】
この明細書に従う符号化データのビットストリームは、この従属節に示されるすべての要件を満たす。
【０２１４】
ビットストリームは、この付加文書以外のこの明細書において示されるシンタックス、セマンティクス、および制約に従って構築される。
【０２１５】
ビットストリーム内の第１の符号化ピクチャはＩＲＡＰピクチャ、すなわちＩＤＲピクチャ、ＣＲＡピクチャまたはＢＬＡピクチャである。
【０２１６】
従属節Ｃ．１に示されるとおり、ビットストリームの適合性が、ＨＲＤによってテストされる。
【０２１７】
現ピクチャの各々に対して、変数ｍａｘＰｉｃＯｒｄｅｒＣｎｔおよびｍｉｎＰｉｃＯｒｄｅｒＣｎｔを、以下のピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌ値のそれぞれ最大値および最小値に等しく設定する。
【０２１８】
現ピクチャ。
【０２１９】
０に等しいＴｅｍｐｏｒａｌＩｄを有し、かつＲＡＳＬピクチャでも、ＲＡＤＬピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャ。このピクチャのＰｉｃＯｒｄｅｒＣｎｔｌＶａｌは、次のとおりに導出される。
【０２２０】
（１）現ピクチャに対するｐｏｃ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しいとき、０に等しいＴｅｍｐｏｒａｌＩｄを有し、かつＲＡＳＬピクチャでも、ＲＡＤＬピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌを、現ピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌだけデクリメントする。
【０２２１】
（２）現ピクチャに対するｐｏｃ＿ｍｓｂ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しいとき、０に等しいＴｅｍｐｏｒａｌＩｄを有し、かつＲＡＳＬピクチャでも、ＲＡＤＬピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌを、現ピクチャのＰｉｃＯｒｄｅｒＣｎｔＭｓｂだけデクリメントする。
【０２２２】
（３）現ピクチャに対するｐｏｃ＿ｌｓｂ＿ｒｅｓｅｔ＿ｆｌａｇが１に等しいとき、０に等しいＴｅｍｐｏｒａｌＩｄを有し、かつＲＡＳＬピクチャでも、ＲＡＤＬピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌを、現ピクチャのｓｌｉｃｅ＿ｐｉｃ＿ｏｒｄｅｒ＿ｃｎｔ＿ｌｓｂだけデクリメントする。
【０２２３】
（４）ｐｏｃ＿ｄｅｃｒｅｍｅｎｔ値が０より大きいとき、０に等しいＴｅｍｐｏｒａｌＩｄを有し、かつＲＡＳＬピクチャでも、ＲＡＤＬピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌを、ｐｏｃ＿ｄｅｃｒｅｍｅｎｔ＿ｖａｌｕｅだけデクリメントする。
【０２２４】
（５）ＪＣＴＶＣ−Ｌ１００３文書に記載されるとおりにピクチャ順序カウントの復号プロセスに基づいてｄｅｃｒＶａｌｕｅ値を算出した後に、現ピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌをｄｅｃｒＶａｌｕｅ値だけデクリメントしたとき、次いで、０に等しいＴｅｍｐｏｒａｌＩｄを有し、かつＲＡＳＬピクチャでも、ＲＡＤＬピクチャでも、サブレイヤ非参照ピクチャでもない、復号順で前のピクチャのＰｉｃＯｒｄｅｒＣｎｔＶａｌを、ｄｅｃｒＶａｌｕｅ値だけデクリメントする。
【０２２５】
現ピクチャのＲＰＳ内の短期参照ピクチャ。
【０２２６】
ｃｕｒｒＰｉｃが現ピクチャであるとき、１に等しいＰｉｃＯｕｔｐｕｔＦｌａｇと、ＡｕＣｐｂＲｅｍｏｖａｌＴｉｍｅ［ｃｕｒｒＰｉｃ］より小さいＡｕＣｐｂＲｅｍｏｖａｌＴｉｍｅ［ｎ］と、ＡｕＣｐｂＲｅｍｏｖａｌＴｉｍｅ［ｃｕｒｒＰｉｃ］以上のＤｐｂＯｕｔｐｕｔＴｉｍｅ［ｎ］とを有するすべてのピクチャｎ。
【０２２７】
現ピクチャの各々に対して、ｍａｘＰｉｃＯｒｄｅｒＣｎｔ−ｍｉｎＰｉｃＯｒｄｅｒＣｎｔの値がＭａｘＰｉｃＯｒｄｅｒＣｎｔＬｓｂ／２より小さくなることが、ビットストリーム適合の要件である。
【０２２８】
前述の明細書において使用されている用語および表現は、限定ではなく説明のための用語として用いられるものであり、こうした用語および表現の使用において、図示および記載される特徴の均等物またはその特徴の一部を除外することは意図されておらず、本発明の範囲は以下の請求項によってのみ定義および限定されることが認識される。
【図１Ａ】
0006393317.tif 000014
【図１Ｂ】
0006393317.tif 000015
【図２Ａ】
0006393317.tif 000016
【図２Ｂ】
0006393317.tif 000017
【図３Ａ】
0006393317.tif 000018
【図３Ｂ】
0006393317.tif 000019
【図４】
0006393317.tif 000020
【図５】
0006393317.tif 000021
【図６】
0006393317.tif 000022
【図７】
0006393317.tif 000023
【図８】
0006393317.tif 000024
【図９】
0006393317.tif 000025
【図１０】
0006393317.tif 000026
【図１１】
0006393317.tif 000027
【図１２】
0006393317.tif 000028
【図１３】
0006393317.tif 000029
【図１４Ａ】
0006393317.tif 000030
【図１４Ｂ】
0006393317.tif 000031
【図１５】
0006393317.tif 000032
【図１６】
0006393317.tif 000033
【図１７】
0006393317.tif 000034
【図１８】
0006393317.tif 000035