JP2017192144A - 画像符号化方法および画像符号化装置 - Google Patents

Abstract

【課題】処理効率を向上することができる画像符号化方法を提供する。【解決手段】画像符号化方法は、処理対象のスライス以外の他のスライスに対する符号化処理の結果に依存してその符号化処理が行われる依存スライスがピクチャに含まれるか否かを示す依存スライス有効化フラグと、処理対象のスライスの開始位置を示すスライスアドレスと、処理対象のスライスが依存スライスであるか否かを示す依存性インジケーションとを含むビットストリームを送信するステップを含み、依存スライス有効化フラグは、複数のスライスに共通のパラメータセット内に配置され、スライスアドレスは、処理対象のスライスのスライスヘッダ内に配置され、依存性インジケーションは、スライスヘッダ内であって、スライスアドレスの前、かつ、パラメータセットを識別するシンタックスエレメントの後に配置されている。【選択図】図１３

Description

本発明は、画像を符号化する画像符号化方法、および、画像を復号する画像復号方法等に関する。

現在の標準的な映像符号化アルゴリズムの大半はハイブリッド映像符号化に基づく。ハイブリッド映像符号化方法では、所望の圧縮ゲインを達成するために、いくつかの異なる可逆圧縮方式と不可逆圧縮方式とが用いられる。ハイブリッド映像符号化は、ＩＳＯ／ＩＥＣ標準規格（ＭＰＥＧ‐１、ＭＰＥＧ‐２及びＭＰＥＧ‐４などのＭＰＥＧ−Ｘ標準規格）と同様に、ＩＴＵ‐Ｔ標準規格（Ｈ．２６１及びＨ．２６３などのＨ．２６ｘ標準規格）の基礎である。

最新の映像符号化標準規格は、Ｈ．２６４／ＭＰＥＧ‐４ Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）と称される。この規格は、ＪＶＴ（Ｊｏｉｎｔ ＣｏＶｅｄｅｏ Ｔｅａｍ）と、ＩＴＵ‐Ｔ及びＩＳＯ／ＩＥＣ ＭＰＥＧグループとの合同チームにより標準化された。

また、高解像度の映像符号化の効率改善を目的として、ＨＥＶＣ（Ｈｉｇｈ−Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）と称される映像符号化標準規格が、ＪＣＴ−ＶＣ（Ｊｏｉｎｔ Ｃｏｌｌａｂｏｒａｔｉｖｅ Ｔｅａｍ ｏｎ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）により検討されている。

Ｃ．Ｇｏｒｄｏｎ他、"Ｗａｖｅｆｒｏｎｔ Ｐａｒａｌｌｅｌ Ｐｒｏｃｅｓｓｉｎｇ ｆｏｒ ＨＥＶＣ Ｅｎｃｏｄｉｎｇ ａｎｄ Ｄｅｃｏｄｉｎｇ"、ＪＣＴＶＣ−Ｆ２７４−ｖ２，ｆｒｏｍ ｔｈｅ Ｍｅｅｔｉｎｇ ｉｎ Ｔｏｒｉｎｏ，Ｊｕｌｙ ２０１１、インターネット〈ＵＲＬ：ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ〉 Ａ．Ｆｕｌｄｓｅｔｈ他、"Ｔｉｌｅｓ"、ＪＣＴＶＣ−Ｆ３５５−ｖ１，ｆｒｏｍ ｔｈｅ Ｍｅｅｔｉｎｇ ｉｎ Ｔｏｒｉｎｏ，Ｊｕｌｙ ２０１１、インターネット〈ＵＲＬ：ｈｔｔｐ：／／ｐｈｅｎｉｘ．ｉｎｔ−ｅｖｒｙ．ｆｒ〉 ＪＣＴＶＣ−Ｊ１００３＿ｄ７，"Ｈｉｇｈ ｅｆｆｉｃｉｅｎｃｙ ｖｉｄｅｏ ｃｏｄｉｎｇ （ＨＥＶＣ） ｔｅｘｔ ｓｐｅｃｉｆｉｃａｔｉｏｎ ｄｒａｆｔ ８"、Ｊｕｌｙ ２０１２、第７３頁「ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇ」、インターネット〈ＵＲＬ：ｈｔｔｐ：／／ｐｈｅｎｉｘ．ＩＴ−ｓｕｄｐａｒｉｓ．ｅｕ／ｊｃｔ／〉

しかしながら、従来技術に係る画像符号化方法および画像復号（復号化）方法等では、処理効率が十分ではないという問題がある。

そこで、本発明は、処理効率を向上することができる画像符号化方法および画像復号方法等を提供する。

本発明の一態様に係る画像符号化方法は、ピクチャを複数のスライスに分割して符号化処理を実行する画像符号化方法であって、処理対象のスライス以外の他のスライスに対する前記符号化処理の結果に依存して前記符号化処理が行われる依存スライスが前記ピクチャに含まれるか否かを示す依存スライス有効化フラグと、前記処理対象のスライスの開始位置を示すスライスアドレスと、前記処理対象のスライスが前記依存スライスであるか否かを示す依存性インジケーションとを含むビットストリームを送信するステップを含み、前記依存スライス有効化フラグは、前記複数のスライスに共通のパラメータセット内に配置され、前記スライスアドレスは、前記処理対象のスライスのスライスヘッダ内に配置され、前記依存性インジケーションは、前記スライスヘッダ内であって、前記スライスアドレスの前、かつ、前記パラメータセットを識別するシンタックスエレメントの後に配置されている。

また、本発明の一態様に係る画像復号方法は、ピクチャを複数のスライスに分割して復号処理を実行する画像復号方法であって、処理対象のスライス以外の他のスライスに対する前記復号処理の結果に依存して前記復号処理が行われる依存スライスが前記ピクチャに含まれるか否かを示す依存スライス有効化フラグと、前記処理対象のスライスの開始位置を示すスライスアドレスと、前記処理対象のスライスが前記依存スライスであるか否かを示す依存性インジケーションとを、符号化されたビットストリームから抽出するステップを含み、前記依存スライス有効化フラグは、前記複数のスライスに共通のパラメータセット内に配置され、前記スライスアドレスは、前記処理対象のスライスのスライスヘッダ内に配置され、前記依存性インジケーションは、前記スライスヘッダ内であって、前記スライスアドレスの前、かつ、前記パラメータセットを識別するシンタックスエレメントの後に配置されている。

なお、これらの包括的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。

本発明の画像符号化方法及び画像復号方法は、符号化効率を向上することができる。

図１は、ＨＥＶＣに準拠したエンコーダの一例を示すブロック図である。 図２は、ＨＥＶＣに準拠したデコーダの一例を示すブロック図である。 図３は、波面並列処理（ＷＰＰ）における画像の構成の一例を示す図である。 図４は、波面並列処理における通常スライスと依存スライスとの関係の一例を示す図である。 図５は、パケットヘッダの一例を示す図である。 図６は、エントロピースライスまたは依存スライスのスライスヘッダの一例を示す図である。 図７は、通常スライスを用いる場合の依存性とその信号伝達を示す図である。 図８は、依存スライスおよびエントロピースライスを用いる場合の依存性とその信号伝達を示す概略図である。 図９Ａは、ＨＭ８．０における、レイヤ間の依存性、時間的依存性、およびスライス間の依存性のシンタックスの例を示す図である。 図９Ｂは、ＨＭ８．０における、レイヤ間の依存性を解析するために実行される解析ステップを説明するための図である。 図９Ｃは、ＨＭ８．０における、レイヤ間の依存性を解析するために実行される解析ステップを説明するための図である。 図１０は、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇの位置の一例を示す図である。 図１１は、図１０におけるｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇに関する解析条件を削除した場合のシンタックスの例を示す図である。 図１２は、ｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇの前にｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇを移動させた場合のシンタックスの例を示す図である。 図１３は、ｓｌｉｃｅ＿ａｄｄｒｅｓｓの前にｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇを移動させた場合のシンタックスの例を示す図である。 図１４は、ＮＡＬヘッダ内にｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇを移動させた場合のシンタックスの例を示す図である。 図１５は、ＮＡＬユニットタイプに新しいタイプを追加した場合の依存スライスのスライスヘッダのシンタックスの例を示す図である。 図１６は、特定のＮＡＬユニットタイプに対してｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇが１に設定されると仮定した場合のスライスヘッダおよびＮＡＬユニットヘッダのシンタックスの例を示す図である。 図１７は、コンテンツ配信サービスを実現するコンテンツ供給システムの全体構成図である。 図１８は、デジタル放送用システムの全体構成図である。 図１９は、テレビの構成例を示すブロック図である。 図２０は、光ディスクである記録メディアに情報の読み書きを行う情報再生／記録部の構成例を示すブロック図である。 図２１は、光ディスクである記録メディアの構造例を示す図である。 図２２Ａは、携帯電話の一例を示す図である。 図２２Ｂは、携帯電話の構成例を示すブロック図である。 図２３は、多重化データの構成を示す図である。 図２４は、各ストリームが多重化データにおいてどのように多重化されているかを模式的に示す図である。 図２５は、ＰＥＳパケット列に、ビデオストリームがどのように格納されるかを更に詳しく示した図である。 図２６は、多重化データにおけるＴＳパケットとソースパケットの構造を示す図である。 図２７は、ＰＭＴのデータ構成を示す図である。 図２８は、多重化データ情報の内部構成を示す図である。 図２９は、ストリーム属性情報の内部構成を示す図である。 図３０は、映像データを識別するステップを示す図である。 図３１は、各実施の形態の動画像符号化方法および動画像復号方法を実現する集積回路の構成例を示すブロック図である。 図３２は、駆動周波数を切り替える構成を示す図である。 図３３は、映像データを識別し、駆動周波数を切り替えるステップを示す図である。 図３４は、映像データの規格と駆動周波数を対応づけたルックアップテーブルの一例を示す図である。 図３５Ａは、信号処理部のモジュールを共有化する構成の一例を示す図である。 図３５Ｂは、信号処理部のモジュールを共有化する構成の他の一例を示す図である。

（本発明の基礎となった知見）
本発明者は、「背景技術」の欄において記載した、画像符号化方法及び画像復号方法に関し、以下の問題が生じることを見出した。

まず、ＨＥＶＣにおける画像符号化装置及び画像復号装置について説明する。

画像符号化装置へ入力される映像信号は、各々がフレーム（ピクチャ）と呼ばれる複数の画像を含む。各フレームは二次元行列状に配置された複数の画素を含む。ハイブリッド映像符号化に基づく上述の全ての標準規格では、個々の映像フレームは、各々が複数の画素を含む複数のブロックに分割される。このブロックのサイズは、例えば、画像の内容によって変更される。また、ブロックごとに異なる符号化方法を用いることができる。例えば、ＨＥＶＣにおいて、このブロックの最大サイズは６４×６４画素である。この最大サイズは、最大符号化単位（ＬＣＵ）と称される。ＬＣＵは、帰納的に、４つの符号化単位（ＣＵ）に分割することができる。

Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣにおいては、マクロブロック（通常１６×１６画素のブロック）単位で符号化が行われる。このマクロブロックはサブブロックに分割される場合もある。符号化方法に含まれる符号化ステップおよび／または復号方法に含まれる復号ステップは、サブブロック単位で実行される。

［１−１．ハイブリッド映像符号化］
以下、ハイブリッド符号化について、簡単に説明する。

典型的には、ハイブリッド映像符号化における符号化ステップには、空間的予測（空間予測）及び／または時間的予測（時間予測）が含まれる。つまり、空間的に隣接したブロックまたは時間的に隣接したブロックを用いて、即ち、符号化済み映像フレームを用いて、各符号化対象ブロックが予測される。次に、符号化対象ブロックと、予測結果との差分である残差ブロックが算出される。次に、残差ブロックは、空間（画素）ドメインから周波数ドメインへ変換される。この変換の目的は、入力ブロックの相関性を低下させることである。

次に、変換により得られた変換係数が量子化される。この量子化は不可逆圧縮である。また、得られた量子化係数は、エントロピー符号化によって可逆圧縮される。また、符号化映像信号を再構築するために必要な補助情報が符号化され、符号化映像信号とともに出力される。この情報は、例えば、空間的予測、時間的予測、または／及び量子化に関する情報である。

［１−２．画像符号化装置の構成］
図１は、Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣ及び／またはＨＥＶＣに準拠した画像符号化装置（エンコーダ１００）の一例を示す図である。

図１に示すように、エンコーダ１００は、減算器１０５と、変換部１１０と、量子化部１２０と、逆変換部１３０と、加算器１４０と、デブロッキングフィルタ１５０と、適応ループフィルタ１６０と、フレームメモリ１７０と、予測部１８０と、エントロピー符号化部１９０とを備えている。

予測部１８０は、時間的予測または空間的予測により、予測信号ｓ２を導出する。予測部１８０において用いられる予測のタイプは、フレーム毎またはブロック毎に異なっていてもよい。時間的予測は、インター予測と称され、空間的予測は、イントラ予測と称される。また、時間的予測による予測信号ｓ２を用いた符号化はインター符号化と称され、空間的予測による予測信号ｓ２を用いた符号化はイントラ符号化と称される。時間的予測を用いた予測信号の導出では、メモリに格納されている符号化済みの画像が用いられる。空間的予測を用いた予測信号の導出では、メモリに格納された符号化または復号済みの隣接ブロックの境界画素値が用いられる。イントラ予測における予測方向の数は、符号化単位（ＣＵ、Ｃｏｄｉｎｇ Ｕｎｉｔ）のサイズによって決まる。なお、予測の詳細については後述する。

減算器１０５は、入力画像の符号化対象ブロック（＝入力信号ｓ１）と対応する予測ブロック（＝予測信号ｓ２）との差分（＝予測誤差信号ｅ）を導出する。当該差分は、符号化対象ブロックの予測に用いられる。なお、予測誤差信号ｅは、予測残差信号とも呼ばれる。

変換部１１０は、予測誤差信号ｅを係数に変換する。一般的に、変換部１１０では、２次元離散コサイン変換（ＤＣＴ）またはその整数版等の直交変換が用いられる。直交変換により、入力信号ｓ１（符号化前の映像信号）の相関を効率的に削減することが可能になる。また、一般に高周波成分よりも低周波成分が画質にとってより重要なので、高周波成分よりも低周波成分により多くのビットが使用される。

量子化部１２０は、係数を量子化して量子化係数を導出する。

エントロピー符号化部１９０は、量子化係数に対してエントロピー符号化を行う。エントロピー符号化により、量子化係数は可逆的に圧縮される。さらに、エントロピー符号化を行うことにより、メモリに格納するデータのデータ量および送信されるデータ（ビットストリーム）のデータ量をさらに削減することができる。エントロピー符号化は、主に、可変長の符号語を用いた符号化処理を適用することによって達成される。この符号語の長さは、発生確率に基づいて選択される。

エントロピー符号化部１９０は、２次元配列の量子化係数を１次元配列に変換する。エントロピー符号化部１９０は、典型的には、いわゆるジグザグスキャンによって変換を行う。ジグザグスキャンにおいては、２次元配列の左上隅にあるＤＣ係数から右下隅にあるＡＣ係数まで、所定の順序で２次元配列が走査される。通常、２次元配列の量子化係数において、エネルギーは、左上部分に集中する。一般的に、より左上側に位置する係数ほど、低周波数成分の係数であり、より右下に位置する係数ほど、高周波数成分の係数である。このため、ジグザク走査を行うと、最後に１または複数のゼロが連続する１次元配列になる。これにより、実際のエントロピー符号化の一部として、またはその前処理として、ランレングス符号を用いる効率的な符号化が可能になる。

Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣ及びＨＥＶＣでは、複数種類のエントロピー符号化が用いられる。シンタックス要素の中には固定長で符号化されるものもあるが、ほとんどのシンタックス要素が可変長符号化される。特に、シンタックスのうち、予測誤差信号（予測残差信号）の符号化には、コンテキスト適応可変長符号（ＣＡＢＡＣ）が用いられる。他のシンタックス要素の符号化には、一般的に、コンテキスト適応可変長符号とは別の様々な整数符号が用いられるが、コンテキスト適応算術符号化を用いてもよい。

可変長符号により、符号化済みビットストリームを可逆的に圧縮することができる。しかしながら、符号語は可変長であるため、符号語を連続して復号しなければならない。つまり、エントロピー符号化をリスタート（初期化）することなく、または、最初に復号する符号語（開始点）の位置を個別に示すことなく、先行の符号語を符号化または復号する前に、符号語を符号化または復号することはできない。

所定の確率モデルに基づく算術符号化によりビット列が１つの符号語に符号化される。所定の確率モデルは、ＣＡＢＡＣの場合の映像シーケンスの内容に応じて決定される。よって、符号化対象のビットストリームの長さが長いほど、算術符号化及びＣＡＢＡＣはより効率的に行われる。つまり、ビット列に適用されるＣＡＢＡＣは、より大きなブロックにおいてより効率的であるといえる。各シーケンスの先頭でＣＡＢＡＣがリスタートされる。つまり、各映像シーケンスの先頭で確率モデルが既定値または所定値で初期化される。

エントロピー符号化部１９０は、符号化された量子化係数（符号化された映像信号）と符号化された補助情報とを含むビットストリームを、デコーダ側に送信する。

Ｈ．２６４／ＭＰＥＧ−４、Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣ、および、ＨＥＶＣは、ビデオ符号化層（ＶＣＬ）とネットワーク抽象化層（ＮＡＬ）の２つの機能層を有する。上述したように、ＶＣＬは、符号化機能を提供する。ＮＡＬは、チャネルを用いた送信あるいは記憶装置への格納等の用途に応じて、ＮＡＬユニットと称される標準単位で情報（情報要素）をカプセル化する。ＮＡＬによりカプセル化される情報要素には、例えば、（１）符号化された予測誤差信号（圧縮映像データ）、および、（２）予測タイプ、量子化パラメータおよび動きベクトル等の映像信号の復号に必要な補助情報（関連情報）が含まれる。補助情報には、映像シーケンス全体に関連するパラメータセットなどの追加データがカプセル化されたｎｏｎ−ＶＣＬユニット、および、復号効率の改善に用いることが可能な追加情報を提供する付加拡張情報（ＳＥＩ）が含まれる。

ｎｏｎ−ＶＣＬユニットには、例えば、パラメータセットが含まれる。パラメータセットとは、一定の映像シーケンスの符号化および復号に関する複数のパラメータのセットのことである。パラメータセットには、例えば、ピクチャシーケンス全体の符号化および復号に関連するパラメータを含むシーケンスパラメータセット（ＳＰＳ）がある。特に、シーケンスパラメータセットは、シンタックス要素を含むシンタックス構造を有する。シンタックス要素は、ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの内容により決定されるゼロ以上の符号化映像シーケンス全体に適用される。ｓｅｑ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄは、ｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄにより参照される（以下で説明する）ピクチャパラメータセットに含まれるシンタックス要素である。ｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄは、各スライスヘッダに含まれるシンタックス要素である。

ピクチャパラメータセット（ＰＰＳ）は、ピクチャシーケンス（映像シーケンス）のピクチャの符号化および復号に適用されるパラメータを定義したパラメータセットである。特に、ＰＰＳは、シンタックス要素を含むシンタックス構造を有する。シンタックス要素は、各スライスヘッダに含まれるシンタックス要素であるｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄにより決定されるゼロ以上の符号化ピクチャ全体に適用される。

よって、ＰＰＳよりもＳＰＳの追跡を続ける方が容易である。なぜなら、ＰＰＳが各ピクチャに対して変化するのに対して、ＳＰＳは、数分あるいは数時間にも及ぶ可能性のある映像シーケンス全体に対して一定であるからである。

エンコーダ１００には、再構築信号（いわゆる復号信号）ｓ３を導出するために、再構築部（いわゆる復号部）が組み入れられている。再構築部により、符号化済みの画像を再構築（復号）した再構築画像が生成され、フレームメモリ１７０に記憶される。

再構築部は、逆変換部１３０と、加算器１４０と、デブロッキングフィルタ１５０と、適応ループフィルタ１６０とを含む。

逆変換部１３０は、上述した符号化ステップに従い、逆量子化および逆変換を実行する。なお、逆変換部１３０により導出された予測誤差信号ｅ’は、量子化ノイズとも称される量子化誤差が原因で、予測誤差信号ｅとは異なる。

加算器１４０は、逆変換部１３０により再構築された予測誤差信号ｅ’を、予測信号ｓ２に加えることで、再構築信号ｓ’を導出する。

デブロッキングフィルタ１５０は、量子化に起因して再構築信号ｓ’に重畳された量子化ノイズを削減するデブロッキングフィルタ処理を実行する。ここで、上述した符号化ステップは、ブロック単位で行われるため、ノイズが重畳されることにより、ブロック境界が目立つ場合がある（ノイズのブロッキング特性）。重畳されたノイズは、ブロッキングノイズと呼ばれる。特に、量子化部１２０において強い量子化が行われた場合は、再構築画像（復号画像）のブロック境界がより顕著に目立つことになる。このようなブロッキングノイズは、人間の視覚認識において、画質が劣化しているように見える。このブロッキングノイズを削減するため、デブロッキングフィルタ１５０は、再構築信号ｓ’（再構築ブロック）に対してデブロッキングフィルタ処理を実行する。

例えば、Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣにおけるデブロッキングフィルタ処理では、領域ごとに、当該領域に適したフィルタ処理が選択される。例えば、ブロッキングノイズが大きい場合は、強い（狭帯域）ローパスフィルタが用いられ、ブロッキングノイズが小さい場合は、弱い（広帯域）ローパスフィルタが用いられる。このローパスフィルタの強度は、予測信号ｓ２および予測誤差信号ｅ’に応じて決定される。このデブロッキングフィルタ処理により、ブロックのエッジが平滑化される。これにより、復号画像信号の主観的画質が改善する。また、フィルタ処理済みの画像が次の画像の動き補償予測に用いられる。よって、このフィルタ処理により予測誤差も削減されるので、符号化効率を改善することができる。

適応ループフィルタ１６０は、デブロッキングフィルタ１５０においてデブロッキングフィルタ処理された後の再構築信号ｓ”に対し、サンプル適応オフセット（Ｓａｍｐｌｅ ａｄａｐｔｉｖｅ ｏｆｆｓｅｔ、ＳＡＯ）処理および／または適応ループフィルタ（Ａｄａｐｔｉｖｅ Ｌｏｏｐ Ｆｉｌｔｅｒ、ＡＬＦ）処理を適用することで、再構築信号（復号信号）ｓ３を導出する。

ここで、デブロッキングフィルタ１５０におけるデブロッキングフィルタ処理は、主観的品質の改善を目的とする。一方で、適応ループフィルタ１６０におけるＡＬＦ処理およびＳＡＯ処理は、画素単位の信頼性（客観的品質）の改善を目的とする。ＳＡＯ処理は、近接画素の画素値を用いて、各画素の画素値にオフセット値を追加する処理である。ＡＬＦ処理は、圧縮によって生じる画像の歪みを補償するために用いられる処理である。通常、ＡＬＦ処理で用いられるフィルタは、再構築信号ｓ’と入力信号ｓ１との平均二乗誤差（ＭＳＥ）が最小化されるように決定したフィルタ係数を有するウィーナフィルタである。ＡＬＦ処理のフィルタ係数は、例えば、フレーム単位で算出および送信される。ＡＬＦ処理は、フレーム全体（画像）に適用されてもよいし、局所領域（ブロック）に適用されてもよい。また、フィルタリングを行う領域を示す補助情報が、ブロック単位、フレーム単位、または四分木単位で送信されてもよい。

フレームメモリ（フレームバッファ）１７０は、符号化され再構築（復号）された再構築画像（再構築信号ｓ３）の一部を格納する。格納された再構築画像は、インター符号化されたブロックを復号するために用いられる。

予測部１８０では、エンコーダ側とデコーダ側の互換性を保つため、エンコーダ側およびデコーダ側の両方で利用可能な（同一の）信号を用いて予測信号ｓ２を導出する。エンコーダ側およびデコーダ側の両方で利用可能な信号は、エンコーダ側では、符号化され再構築（復号）された再構築信号ｓ３（適応ループフィルタ１６０によるフィルタ処理後の映像信号）であり、デコーダ側では、ビットストリームから復号された復号信号ｓ４（図２の適応ループフィルタ２６０によるフィルタ処理後の映像信号）である。

予測部１８０は、インター符号化により予測信号ｓ２を生成する場合、動き補償予測による予測を行う。予測部１８０の動き推定器（図示せず）は、以前に符号化され再構築された映像フレームに含まれるブロックから、符号化対象ブロックに最も適合する最適ブロックを見つける。この最適ブロックは予測信号となる。また、符号化対象ブロックと最適ブロック間の相対的なずれ（動き）は、３次元の動きベクトルの形で補助情報に含まれる動きデータとして信号により伝達される。当該信号は、符号化映像データとともに、送信される。３次元の動きベクトルは、空間の２次元の動きベクトルと、時間の１次元の動きベクトルとを含む。予測精度を最適化するため、１／２画素解像度あるいは１／４画素解像度等の空間的サブピクセル解像度で動きベクトルを求めてもよい。空間的サブピクセル解像度の動きベクトルは、実存する画素値がない、再構築フレーム内の空間的位置、つまりサブピクセルの位置を示してもよい。よって、動き補償予測を行うために、そのような画素値の空間的補間が必要である。これは、補間フィルタ（図１において予測部１８０に統合されている）により達成してもよい。

［１−３．画像復号装置の構成］
デコーダ（画像復号装置）の構成について、図２を基に説明する。

図２は、Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣまたはＨＥＶＣ映像符号化規格に準拠したデコーダ２００の一例を示すブロック図である。

図２に示すように、デコーダ２００は、エントロピー復号部２９０と、逆変換部２３０と、加算器２４０と、デブロッキングフィルタ２５０と、適応ループフィルタ２６０と、フレームメモリ２７０と、予測部２８０とを備えている。

デコーダ２００に入力されたビットストリーム（符号化された映像信号）は、まず、エントロピー復号部２９０に送られる。

エントロピー復号部２９０は、ビットストリームから符号化された量子化係数と、符号化された補助情報とを抽出し、符号化された量子化係数と符号化された補助情報とを復号する。補助情報は、上述したように、動きデータ（動きベクトル）および予測モード（予測タイプ）等の復号に必要な情報である。

エントロピー復号部２９０は、復号された量子化係数を、逆走査により、一次元配列から２次元配列に変換する。エントロピー復号部２９０は、２次元配列に変換した後の量子化係数を、逆変換部２３０に入力する。

逆変換部２３０は、２次元配列に変換された量子化係数に対し、逆量子化および逆変換を実行して、予測誤差信号ｅ’を導出する。予測誤差信号ｅ’は、量子化ノイズがなく、誤差が生じなかった場合にエンコーダに入力された信号から予測信号を減算して求めた差分に相当する。

予測部２８０は、時間的予測または空間的予測によって予測信号ｓ２を導出する。イントラ予測（空間的予測）の場合には、補助情報に含まれる予測タイプ等の情報を利用する。また、動き補償予測（インター予測、時間的予測）の場合には、補助情報に含まれる動きデータ等の情報を利用する。

加算器２４０は、逆変換部２３０から取得した予測誤差信号ｅ’と予測部２８０から取得した予測信号ｓ２とを加算して、再構築信号ｓ’を導出する。

デブロッキングフィルタ２５０は、再構築信号ｓ’に対し、デブロッキングフィルタ処理を適用する。適応ループフィルタ２６０は、デブロッキングフィルタ２５０によりデブロッキングフィルタ処理を適用された再構築信号ｓ”に対し、ＳＡＯ処理およびＡＬＦ処理を適用する。適応ループフィルタ２６０においてＳＡＯ処理およびＡＬＦ処理が適用された結果得られる復号信号Ｓ４は、フレームメモリ２７０に格納される。フレームメモリ２７０に格納された復号信号Ｓ４は、予測部２８０において、次の復号対象ブロックあるいは復号対象画像の予測に使用される。

［１−４．処理効率］
符号化処理および復号処理において処理効率を向上させる方法として、一般的に、処理の並列化が考えられる。

Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣと比較すると、ＨＥＶＣは、符号化処理および復号処理の高度な並列処理（並列化処理）を補助する機能を有する。Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣと同様に、ＨＥＶＣでは、フレームを複数のスライスに分割することができる。ここで、各スライスは、走査順で連続する複数のＬＣＵを含む。Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣにおいて、スライスはそれぞれ、個々に復号可能であり、スライスを跨いだ空間的予測は行われない。よって、スライス単位で、並列処理が可能である。

しかしながら、スライスはかなり大きなヘッダを有しており、また、スライス間で依存性がないため、圧縮の効率が低下する。また、ＣＡＢＡＣ符号化は、小さなデータブロックに行われる場合に効率性が損なわれる。

これに対して、より効率的な並列処理を可能にするため、波面並列処理（ＷＰＰ）が提案されている。ＷＰＰでは、上述した並列処理のようにスライス単位で完全に独立させるのではなく、一定の依存性を持たせている。

以下の説明では、ピクチャが行列状に配置された複数のＬＣＵで構成され、各ＬＣＵ行が１つのスライスを構成する場合を例に説明する（図３参照）。ＷＰＰでは、処理対象のＬＣＵ行３２を構成するＬＣＵのうち、１番目のＬＣＵ（先頭のＬＣＵ）のＣＡＢＡＣ状態をリセットするためのＣＡＢＡＣ確率モデルとして、前ＬＣＵ行３１の２番目のＬＣＵに対する処理が終了した直後におけるＣＡＢＡＣ確率モデルを利用する。これにより、ブロック間の依存性が維持される。また、複数のＬＣＵ行の復号処理の並列化が可能になる。但し、各ＬＣＵ行の処理の開始タイミングは、前ＬＣＵ行に対して、ＬＣＵ２つ分遅延する。スライスのヘッダには、ＬＣＵ行の復号を開始するための開始点の情報が含まれる。ＷＰＰの詳細については、非特許文献１に記載されている。

並列化改善のための別の手法としてタイルを用いる方法がある。フレーム（ピクチャ）は、複数のタイルに分割される。各タイルは、長方形であり、複数のＬＣＵを含む。タイル間の境界は、行列状にピクチャを分割するように設定される。また、複数のタイルは、ラスタスキャン順に処理される。

また、各タイルの境界において全ての依存性が失われる。ＣＡＢＡＣなどのエントロピー符号化も、各タイルの先頭でリセットされる。なお、デブロッキングフィルタ処理とサンプル適応オフセット処理のみが、タイル間の境界を跨いで適用される。よって、複数のタイルを並列に符号化または復号できる。なお、タイルの詳細については、非特許文献２及び非特許文献３に記載されている。

また、スライスの概念を、Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣにおけるスライスの本来の目的であった誤り耐性よりも、並列化に適した概念にするため、依存スライス及びエントロピースライスの概念が提案されている。

つまり、ＨＥＶＣでは、（１）通常スライス、（２）エントロピースライス、および、（３）依存スライスの３つのスライスが用いられる。

（１）通常スライスは、Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣにより既に知られているスライスのことである。通常スライス間では空間的予測はできない。つまり、スライス間の境界を跨いだ予測はできない。言い換えると、別のスライスを参照することなく、通常スライスは符号化される。このようなスライスの復号を別々に行えるように、ＣＡＢＡＣは各スライスの先頭でリスタートされる。

処理対象のスライスが通常スライスの場合、ＣＡＢＡＣのリスタートには、先行スライス終端での算術符号化処理または算術復号処理の終端処理（ターミネート処理）と、当該通常スライスの先頭において、コンテキストテーブル（確率テーブル）をデフォルト値に初期化する処理とが含まれる。

また、フレームの先頭には、通常スライスが用いられる。つまり、各フレームは通常スライスから開始しなければならない。通常スライスは、スライスデータの復号に必要なパラメータを含むヘッダを有する。

（２）エントロピースライスは、親スライスとエントロピースライスとの間で空間的予測が可能なスライスのことである。親スライス及びエントロピースライスの解析は、独立して行われる。

なお、親スライスは、例えば、エントロピースライスの直前の通常スライスである。親スライスは、エントロピースライスの画素値の再構築に必要とされる。また、エントロピースライスが独立解析できるよう、スライスの先頭でＣＡＢＡＣもリスタートされる。エントロピースライスのスライスヘッダには、通常スライスのスライスヘッダより短いスライスヘッダを用いることができる。エントロピースライスのスライスヘッダには、通常スライスのスライスヘッダに含まれる情報に関する符号化パラメータサブセットが含まれる。エントロピースライスのスライスヘッダにおける欠落要素は、親スライスのスライスヘッダからコピーされる。

処理対象のスライスがエントロピースライスの場合、ＣＡＢＡＣのリスタートには、通常スライスと同様に、先行スライス終端での終端処理（ターミネート処理）と、現行スライス先頭においてコンテキストテーブルをデフォルト値に初期化する処理とが含まれる。

（３）依存スライスは、エントロピースライスと類似しているが、ＣＡＢＡＣのリスタートの一部処理で異なっている。

処理対象のスライスが依存スライスかつＷＰＰが有効ではない場合、ＣＡＢＡＣのリスタートには、先行スライス終端での終端処理（ターミネート処理）と、現行スライスの先頭において、先行スライスの終端の状態値にコンテキストテーブルを初期化する処理とが含まれる。処理対象のスライスが依存スライスかつＷＰＰが有効である場合、ＣＡＢＡＣのリスタートには、先行スライス終端での終端処理（ターミネート処理）と、現行スライスの先頭において、先行スライスに属し左端から２つめのＬＣＵ処理後の状態値にコンテキストテーブルを初期化する処理とが含まれる。

上述したように、ＣＡＢＡＣのリスタートには、常に、ターミネート処理が含まれる。これに対し、ＣＡＢＡＣのリスタートにおいて、ＣＡＢＡＣの状態は、引き継がれる場合がある。

依存スライスは、親スライスなしに解析することはできない。このため、親スライスを取得していない場合、依存スライスを復号することができない。親スライスは通常、符号化順において依存スライスの先行スライスであり、完全なスライスヘッダを含むスライスである。このことは、エントロピースライスの親スライスでも同じである。

以上のように、依存スライス及びエントロピースライスは、スライスの符号化順における直前のスライスのスライスヘッダ（依存スライスのヘッダに含まれていない情報）を用いる。このルールは帰納的に適用される。対象依存スライスが依存する親スライスが参照可能であると認識される。参照には、スライス間の空間的予測及び共通ＣＡＢＡＣ状態などの利用が含まれる。依存スライスは、直前のスライスの終端で生成されるＣＡＢＡＣコンテキストテーブルを用いる。このように、依存スライスは、ＣＡＢＡＣのコンテキストテーブルをデフォルト値に初期化せず、作成済みのコンテキストテーブルを継続して利用する。また、エントロピースライスおよび依存スライスに関しては、非特許文献３に記載されている。

ＨＥＶＣは、いくつかのプロファイルを提示する。プロファイルは、特定のアプリケーションに適する画像符号化装置及び画像復号装置の設定を含む。例えば、「主要プロファイル」は、通常スライス及び依存スライスのみを含み、エントロピースライスを含まない。

上述したように、符号化スライスは、ＮＡＬユニットにカプセル化され、さらに、例えばリアルタイムプロトコル（ＲＴＰ）にカプセル化され、最終的にインターネットプロトコル（ＩＰ）パケットにカプセル化される。このプロトコルスタックまたは別のプロトコルスタックにより、インターネットまたは固有ネットワークなどのパケット指向型ネットワークにおいて、符号化映像の送信が可能になる。

典型的に、ネットワークは少なくとも１つ以上のルータを含み、ルータは超高速で動作する専用ハードウェアで構成される。ルータは、ＩＰパケットを受信してＩＰパケットのヘッダを解析し、適宜ＩＰパケットをそれぞれの宛先に転送する機能を有する。ルータは、多くのソースからの通信を処理する必要があるので、ロジックを制御するパケットはなるべくシンプルでなければならない。ルータは、少なくとも、ＩＰパケットを転送する経路を決定するため、ＩＰヘッダに含まれる宛先アドレスフィールドを確認する必要がある。サービス品質（ＱｏＳ）に対するサポートをさらに提供するため、スマート（メディア・アウェア）ルータは、ＩＰヘッダ、ＲＴＰヘッダ、及びＮＡＬＵヘッダなどのネットワーク・プロトコルヘッダにおける専用フィールドを追加的に確認する。

映像符号化に関する上記の記載から分かるように、依存スライス及びエントロピースライスなど、並列処理のために定義された異なるタイプのスライスは、データが欠落した場合の画質の低下に対する重要性が異なる。親スライスなしに、依存スライスを解析及び復号することはできない。なぜなら、依存スライスの先頭で、エントロピー符号化部またはエントロピー復号部をリスタートすることができないからである。よって、画像または映像を再構築するうえで、親スライスはより重要であるといえる。

ＨＥＶＣにおいて、依存スライス及びエントロピースライスは、依存性の補足的な側面として、スライス間の依存性（フレーム内の依存性）を取り入れている。この種の依存性は、ルータによって考慮されることはない。

つまり、上述した依存性、特に、インター符号化におけるスライス間の依存性は、ネットワークレベルでは考慮されない。しかしながら、サービス品質に対するより良いサポートを提供するためには、ネットワークレベルにおいて、上述した依存性を考慮することが望ましい。各スライスの依存性を考慮し、ネットワークレベルにおけるパケットの取り扱いの柔軟性を改善することが求められている。

（課題の詳細）
［１−５．ＷＰＰおよび依存スライス］
依存スライスは、ＷＰＰまたはタイルなどの並列処理ツールとともに用いることができる。また、依存スライスを用いることで、符号化損失を引き起こすことなく伝送遅延を削減することが可能なウェイブフロント（サブストリーム）を生成することができる。

また、依存スライスではＣＡＢＡＣがリスタートされないため、依存スライスをＣＡＢＡＣサブストリームの開始点として用いることができる。また、独立した解析の開始点を示すため、当該開始点を示す情報をビットストリームに含めて伝達してもよい。特に、２つ以上のＣＡＢＡＣサブストリームを通常スライスまたは依存スライスにカプセル化する場合、サブストリーム毎のバイト数を用いて明示的に開始点を信号伝達する。ここで、サブストリームは、開始点により別々に解析可能なストリームの一部分を示す。さらに、各依存スライスはＮＡＬユニットのヘッダを必要とするため、開始点の「マーカー」として依存スライスを用いることができる。つまり、そのようなマーカーに対する開始点を信号伝達できる。

信号により明示的に開始点を通知する方法と、依存スライスを介して開始点をマーキングする方法とは同時に用いることができる。

ここで、各ＮＡＬユニットの開始点（各ＮＡＬヘッダの先頭）が特定できる必要がある。なお、特定方法に関しては、任意の方法を用いることができる。例えば、以下の２つの方法を用いることができる。

一つ目の方法は、各ＮＡＬヘッダの先頭に、例えば、３バイトのスタートコードを挿入する方法である。二つ目の方法は、各ＮＡＬユニットを別々のパケットにパケット化する方法である。また、スライスの依存性のため、スライスヘッダのサイズを縮小してもよい。

これらの方法により、エントロピースライスに対して並列ＣＡＢＡＣ解析が可能になる。これは、エントロピースライスの先頭でＣＡＢＡＣが必ずリスタートされるからである。ＣＡＢＡＣの並列処理では、連続する画素構築処理の後の並列ＣＡＢＡＣ解析により障害を克服できる。具体的には、ＷＰＰ並列化ツールにより、各ＬＣＵ行の復号処理を１つのコア（ＩＰコア（ｉｎｔｅｌｌｅｃｔｕａｌ ｐｒｏｐｅｒｔｙ ｃｏｒｅ）、機能ブロック）により実現できる。なお、各コアへのＬＣＵ行の割り当ては異なってよい。例えば、１つのコアに２行が割り当てられてもよいし、２つのコアに１行が割り当てられてもよい。

図３は、ピクチャ３００の構成の一例を示す図である。図３において、ピクチャ３００は、複数のＬＣＵ行３１〜３ｍ（ｍはＬＣＵの行数）に分割されている。各ＬＣＵ行３ｉ（ｉ＝１〜ｍ）は、一行に配置された複数のＬＣＵ３ｉ１〜３ｉｎ（ｎはＬＣＵの列数）で構成されている。ＬＣＵ行３ｉは、「ウェイブフロントｉ」に対応している。ウェイブフロント同士は、並列処理が可能である。図３の「ＣＡＢＡＣ状態」の矢印は、ＣＡＢＡＣ状態を参照するＬＣＵとその参照先との関係を示している。

具体的には、図３では、先ず、ＬＣＵ行３１に含まれるＬＣＵのうち、先頭のＬＣＵ３１１に対する処理（符号化または復号）が開始される。ＬＣＵに対する処理は、ＬＣＵ３１１〜３１ｎの順に実行される。ＬＣＵ行３１において最初の２つのＬＣＵ３１１，３１２が処理された後、ＬＣＵ行３２の処理が開始される。ＬＣＵ行３２の最初のＬＣＵ３２１の処理では、図３の「ＣＡＢＡＣ状態」の矢印に示されるように、１行目のＬＣＵ行３１におけるＬＣＵ３１２に対する処理が終了した直後のＣＡＢＡＣ状態が、ＣＡＢＡＣ状態の初期状態として用いられる。つまり、２つの並列処理の間では、ＬＣＵ２つ分の処理時間に相当する遅延が存在する。

図４は、ＷＰＰを用いた依存スライスの使用例を示す図である。ＬＣＵ行４１〜４３は、「ウェイブフロント１」、「ウェイブフロント２」、および、「ウェイブフロント３」に対応している。ＬＣＵ行４１〜４３は、それぞれ独立したコアで処理される。図４において、ＬＣＵ行４１は通常スライスであり、ＬＣＵ行４２〜４ｍは依存スライスである。

依存スライスは、遅延を改善できるＷＰＰを形成する。依存スライスには完全なスライスヘッダがない。また、開始点（または、上述したようなルールで知られる、依存スライスの開始点）が分かっていれば、他のスライスとは独立して依存スライスを復号できる。また、依存スライスは、符号化損失を生ずることなく、低遅延アプリケーションにも適したＷＰＰを形成できる。

サブストリーム（ＬＣＵ行）をスライスにカプセル化する通常のケースでは、確実に、エントロピー符号化及び復号を並列に行うためには明確な開始点をスライスヘッダに挿入する必要がある。そのため、スライスの最後のサブストリームが完全に符号化されてはじめて、スライスの伝送の準備ができる。また、スライス中の全てのサブストリームの符号化が完了してはじめてスライスヘッダは完成する。つまり、スライス全体の処理が終わるまで、ＲＴＰ／ＩＰ層のパケットフラグメンテーションを介してスライスの先頭の伝送を開始できない。

しかしながら、依存スライスが用いられる場合には、依存スライスを開始点マーカーとして利用できるため、開始点の明示的な信号による通知は必要ない。したがって、符号化損失なく通常スライスを多くの依存スライスに分割することができる。また、カプセル化されたサブストリームの符号化が完了するとすぐに（または、パケットフラグメンテーションの場合は、それよりも早く）、依存スライスを伝送することができる。

また、依存スライスは、空間的予測の依存性を弱めない。さらに、依存スライスは解析依存性も弱めない。なぜなら、対象依存スライスの解析には通常、先行スライスのＣＡＢＡＣ状態を必要とするからである。

依存スライスが許可されない場合、各ＬＣＵ行をスライスとすることができる。そのような構成は伝送遅延を改善するが、同時に、上述したように大きな符号化損失が生ずることになる。

フレーム（ピクチャ）全体を１つのスライスにカプセル化する場合を想定する。この場合、並列解析を可能にするため、スライスヘッダにサブストリーム（ＬＣＵ行）の開始点を信号により伝達する必要がある。これによりフレームレベルで伝送遅延が発生する。つまり、フレーム全体を符号化した後、ヘッダを修正する必要がある。ピクチャ全体を１つのスライスにカプセル化すること自体は、伝送遅延を悪化させない。例えば、符号化が完全に終わる前に、スライスの一部の伝送を開始してもよい。しかしながら、ＷＰＰを用いる場合、開始点を記すためにスライスヘッダを後で修正する必要がある。したがって、スライス全体の伝送を遅延させる必要がある。

このように、依存スライスの使用により、遅延を削減することができる。図４に示されるように、ピクチャ４００は、通常スライスであるＬＣＵ行４１、依存スライスであるＬＣＵ行４２〜４ｍに分割される。各ＬＣＵ行が１つの依存スライスである場合、符号化損失なく、１つのＬＣＵ行の伝送を遅延させることができる。これは、依存スライスが、空間依存を弱めず、かつＣＡＢＡＣエンジンをリスタートしないからである。

［１−６．パケットの構成］
上述したように、ネットワークルータは、サービス品質の提供を可能にするために、パケットのヘッダを分析しなければならない。サービス品質は、アプリケーションの種類、および／または、サービスの優先度、および／または、パケットロスに起因する歪みに対するパケットの関連性の優先度によって異なる。

図５は、ビットストリームのカプセル化（パケット化）の一例を示す図である。

ここで、一般的に、パケット化にはリアルタイムプロトコル（ＲＴＰ）が用いられる。ＲＴＰは、通常、リアルタイムのメディア送信に用いられる。また、パケット化で用いられる各プロトコルのヘッダの長さは、基本的に固定されている。各プロトコルのヘッダは、拡張フィールドを有する。この拡張フィールドにより、ヘッダの長さを４バイト拡張できる。例えば、ＩＰヘッダは、２０バイトまで拡張できる。またＩＰヘッダ、ユーザデータグラムプロトコル（ＵＤＰ）ヘッダ、および、ＲＴＰヘッダに含まれるシンタックスエレメントの長さは、固定されている。

図５は、ＩＰパケットに含まれるパケットヘッダ５００を示す。図５に示すパケットヘッダ５００には、ＩＰヘッダ５１０、ＵＤＰヘッダ５３０、ＲＴＰヘッダ５４０、ＲＴＰ Ｈ２６４ペイロードヘッダ５６０、および、ＮＡＬヘッダ５７０が含まれる。ＩＰヘッダ５１０は、４バイトの拡張フィールド５２０を有する２０バイト長のヘッダである。ＩＰパケットのペイロードは、ＵＤＰパケットである。ＵＤＰパケットは、８バイト長のＵＤＰヘッダ５３０と、ＵＤＰペイロードとを含む。ＵＤＰペイロードはＲＴＰパケットによって形成されている。ＲＴＰパケットは、先頭の１２バイト長のＲＴＰヘッダ５４０と、４バイトの拡張フィールド５５０とを有する。ＲＴＰパケットは、拡張フィールドにより、選択的に拡張できる。ＲＴＰパケットのペイロードは、０〜３バイト長の特別なＲＴＰ Ｈ２６４ペイロードヘッダ５６０とそれに続く２バイト長のＨＥＶＣのＮＡＬヘッダ５７０とを含む。符号化された映像パケットを含むＮＡＬＵのペイロードは（図５には図示せず）、パケットヘッダ５００の後に続く。

改良されたサービス品質を提供できるルータは、メディアアウェアネットワークエレメント（Ｍｅｄｉａ Ａｗａｒｅ Ｎｅｔｗｏｒｋ Ｅｌｅｍｅｎｔｓ、ＭＡＮＥ）と呼ばれる。メディアアウェアネットワークエレメントは、図５に示されるパケットヘッダ５００を構成するフィールドのうちのいくつかを解析する。ＭＡＮＥは、例えば、受信パケットコンテンツのロスおよび提示順序を検出するために、“ｔｅｍｐｏｒａｌ＿ｉｄ”と呼ばれ、ＮＡＬヘッダ５７０に含まれるシンタックスエレメント、または、ＲＴＰヘッダ５４０に含まれる復号順序番号を解析することができる。ルータ（ネットワーク要素）は、ネットワークのスループットをより高くするために、パケットをできる限り速く処理する。このようなルータの論理回路は、ネットワークエレメント処理の複雑性を低く抑えるために、パケットヘッダ内のフィールドに素早くシンプルにアクセスする必要がある。 ＮＡＬＵはパケットヘッダ５００内にカプセル化されている。ＮＡＬＵは、スライスヘッダが存在する場合、スライスデータを含んでいてもよい。

ＮＡＬＵはパケットヘッダ５００内にカプセル化されている。ＮＡＬＵは、スライスヘッダが存在する場合、スライスデータを含んでいてもよい。

図６は、スライスヘッダのシンタックス６００の一例を示す図である。ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇ６０１は、スライスが依存スライスであるか否かを示すシンタックスエレメントである。このシンタックスエレメントは、スライス間の依存性を識別するために用いることができる。しかしながら、スライスヘッダは、ＮＡＬＵのコンテンツである。ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇ６０１の前にシンタックスエレメントを解析するためには、かなり複雑な論理回路が必要とされる。これは、下記に示されるように、通常のルータでは効率的に考慮できないレベルである。

上述したように、ＮＡＬＵは、パラメータセットのように、複数のスライスに共通の情報を含む、あるいは、スライスヘッダに含まれる復号に必要な情報を有する符号化されたスライスを直接含む。図６には、エントロピースライスまたは依存スライスに用いられるスライスヘッダのシンタックスの一例が示されている。図６は、スライスヘッダ構造を示すテーブルである。シンタックスエレメント“ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａ
ｇ”が１に設定される場合は、復号順序において対象スライスに先行する最初の通常スライス（エントロピースライスでも依存スライスでもないスライス）までの全てのスライスが必要になる。これらのスライスが復号されていない場合、一般的に、対象依存スライスは復号できない。但し、特別な場合、例えば、信号伝達または導出された他の補助情報を利用することが可能な場合には、依存スライスを復号できる場合がある。シンタックスエレメントｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇ６０１は、スライスヘッダの中央の適切な位置に含まれている。さらに、スライスヘッダは、情報エレメントｎｕｍ＿ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔｓ６０２によって示される対象スライス内のＣＡＢＡＣサブストリームの数と、シンタックスエレメントｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔ［ｉ］６０３によって示されるサブストリームのバイト数とを含む。ここで、情報エレメントｎｕｍ＿ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔｓ６０２は、エントリーポイントの数に対応する。ｉは、整数であり、特定のエントリーポイント（エントリーポイントのオフセット）を示すインデックスである。ｅｎｔｒｙ＿ｐｏｉｎｔ＿ｏｆｆｓｅｔ［ｉ］６０３により示されるサブストリームのバイト数によって、ビットストリーム内でのナビゲーションが簡単になる。

［１−７．ピクチャの依存性］
上述したように、ＨＥＶＣによる符号化では、複数種類の依存性が用いられる。

図７は、依存スライスでもエントロピースライスでもない通常スライスのみが用いられる場合の依存性（依存度）とその信号伝達を示す図である。図７では、３つのピクチャ７１０、７２０、および７３０を示している。

ピクチャ７１０は、ＶＣＬ ＮＡＬ Ｕｎｉｔ１およびＶＣＬ ＮＡＬ Ｕｎｉｔ２の２つのＶＣＬ ＮＡＬＵに保持されるベースレイヤピクチャである。ＰＯＣは、ピクチャを描画する順序を示す。ＶＣＬ ＮＡＬＵには、それぞれ、ピクチャがベースレイヤに属するか、エンハンスメントレイヤに属するかを示すシンタックスエレメントと、シンタックスエレメントｔｅｍｐｏｒａｌ＿ｉｄが含まれる。あるピクチャがベースレイヤに属するか、エンハンスメントレイヤに属するかを示すシンタックスエレメントは、図５に示すパケットヘッダ５００のＮＡＬヘッダ５７０内に含まれた状態で送信される。また、シンタックスエレメントｔｅｍｐｏｒａｌ＿ｉｄについても、ＮＡＬヘッダ５７０内に含まれた状態で送信される。シンタックスエレメントｔｅｍｐｏｒａｌ＿ｉｄは、他のピクチャの依存性を示す。例えば、ｔｅｍｐｏｒａｌ＿ｉｄ＝０の符号化されたピクチャまたはスライスは、より高いｔｅｍｐｏｒａｌ＿ｉｄを有する他のピクチャまたはスライスとは独立して復号可能である。ＨＥＶＣにおいて、ｔｅｍｐｏｒａｌ＿ｉｄは、ＮＡＬヘッダに含めてｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１として信号送信される（図９Ａ参照）。なお、これらの例で用いられたｔｅｍｐｏｒａｌ＿ｉｄと、シンタックスエレメントｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１との間には、次の式１の関係が成り立つ。

ｔｅｍｐｏｒａｌ＿ｉｄ＝１のスライスは、ｔｅｍｐｏｒａｌ＿ｉｄの値がより低いスライスに依存する。つまり、この場合のｔｅｍｐｏｒａｌ＿ｉｄの値は０である。なお、ｔｅｍｐｏｒａｌ＿ｉｄは、ピクチャの予測構造を指す。一般的に、例えば、ｔｅｍｐｏｒａｌ＿ｉｄが特定の値を有するスライスは、ｔｅｍｐｏｒａｌ＿ｉｄの値がより低いスライスまたはｔｅｍｐｏｒａｌ＿ｉｄの値が同じスライスにのみ依存する。

したがって、図７におけるピクチャ７１０は、最初に復号することができる。

ピクチャ７２０は、ピクチャ７１０のベースレイヤに対するエンハンスメントレイヤである。よって、ピクチャ７２０をピクチャ７１０の復号後に復号する必要があるという依存性がある。ピクチャ７２０は、ＶＣＬ ＮＡＬ Ｕｎｉｔ３およびＶＣＬ ＮＡＬ Ｕｎｉｔ４の２つのＮＡＬＵを有する。ピクチャ７１０および７２０は共に、ＰＯＣの値が０である。これは、ピクチャ７１０、７２０が、一度に表示される同じ画像に属することを示す。当該画像は、ベースレイヤとエンハンスメントレイヤとを備えている。

ピクチャ７３０は、ＶＣＬ ＮＡＬ Ｕｎｉｔ５およびＶＣＬ ＮＡＬ Ｕｎｉｔ６の２つのＮＡＬＵを含むベースレイヤである。ピクチャ７３０のＰＯＣの値は１である。これは、ピクチャ（部分）７３０が、ピクチャ７２０および７１０の後に表示されるピクチャであることを意味する。さらに、ピクチャ７３０は、ｔｅｍｐｏｒａｌ＿ｉｄの値が１である。これは、ピクチャ７３０が、ｔｅｍｐｏｒａｌ＿ｉｄ＝０のピクチャに一時的に依存することを意味する。よって、ＮＡＬヘッダ内に含まれて信号送信された依存性に基づき、ピクチャ７３０はピクチャ７１０に依存する。

図８は、依存スライスとエントロピースライスとが用いられる場合の依存性（依存度）とその信号伝達を示す図である。図８では、３つのピクチャ８１０、８２０、および８３０を示している。図８は、スライスヘッダ内に含まれて信号送信された依存スライスおよびエントロピースライスの依存性が追加されている点で、上記図７とは異なる。

ここで、図７では、ピクチャ７１０および７２０の例を用いてレイヤ間の依存性を示している。さらに、ピクチャ７１０および７３０の例を用いて時間的依存性を示している。これらの依存性は共に、ＮＡＬヘッダ内に含まれて信号送信される。

これに対し、図８に示されるスライス間の依存性は、依存スライスおよびエントロピースライスに固有のものである。特に、ベースレイヤのフレーム８１０およびエンハンスメントレイヤのフレーム８２０は共に２つのスライスを有する。２つのスライスのうちの１つは親スライス（通常スライス）であり、もう１つは（依存スライス）である。フレーム８１０において、ＶＣＬ ＮＡＬ Ｕｎｉｔ１のスライスは、ＶＣＬ ＮＡＬ Ｕｎｉｔ２の親スライスである。フレーム８２０において、ＶＣＬ ＮＡＬ Ｕｎｉｔ３のスライスは、ＶＣＬ ＮＡＬ Ｕｎｉｔ４の親スライスである。上述したように、依存スライスの「親スライス」とは、当該依存スライスの依存先スライス、つまり、そのスライスヘッダ情報が当該依存スライスによって使用されるスライスを指す。これは、最初のスライスは、完全なヘッダを有する先行スライスであるというルールに従っている。完全なヘッダを有するスライスとは、例えば、他の依存スライスではなく、通常スライスである。

現在のＨＥＶＣ、特にＨＭ８．０において採用されているＮＡＬユニットヘッダおよびスライスヘッダに対応するシンタックスについて、図９Ａを用いて説明する。

図９Ａは、ＮＡＬユニットヘッダ９１０のシンタックスおよびスライスヘッダ９２０のシンタックスを示す図である。なお、レイヤ間の依存性は、シンタックスエレメントｎｕｈ＿ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿６ｂｉｔｓを用い、ＮＡＬユニットヘッダ内に含ませて信号送信されることが（最新の標準化において）計画されている。時間的依存性は、シンタックスエレメントｎｕｈ＿ｔｅｍｐｏｒａｌ＿ｉｄ＿ｐｌｕｓ１を用いて信号送信される。スライスヘッダ９２０は、スライス間の依存性のインジケータを示す信号を含む。スライス間の依存性のインジケータは、シンタックスエレメントｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇによって示される。つまり、スライス間の依存性（例えば、時間的依存性）は、スライスヘッダ内のどこかの位置に含まれて信号送信される。

このシンタックスエレメントを解析するためには、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇに先行する全てのシンタックスエレメントが、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇに先行するスライスヘッダのシンタックスエレメントの解析に必要なパラメータセットのシンタックスエレメントと同様に、解析されなければならない。

［１−８．ルータにおける処理］
上述したように、トラフィック形成の決定において、ＮＡＬヘッダ内に含まれて信号送信される依存性に加え、依存スライスおよびエントロピースライスによって導入される依存性を考慮することが望ましい。例えば、メディアアウェアモバイル基地局としてルータを用いることができる。下り回線の帯域は非常に限られており、ごく注意深く管理する必要がある。以下の例を想定する。パケットがアップストリームにおいて通常のルータによってランダムに削除される場合を想定する。この場合において、メディアアウェアネットワークエレメント（ＭＡＭＥ）は、パケット番号を確認することによって、パケットロスを確認することができる。パケットロスの確認後、削除されたパケットに依存する後続の全パケットを削除する。これは、メディアアウェアネットワークエレメントに望ましい特徴である。このようにすれば、パケットをよりインテリジェントに削除することができる。ルータは、ＮＡＬユニットの削除を決定すると、後続の依存スライスも削除する必要があると直ちに推定する。図９Ａにおいて導入された対象シンタックスにおいて、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇへのアクセスには、かなりの量の情報解析が必要とされる。これは、ルータにおけるパケットルーティングまたはトラフィック形成処理のいずれにも必須ではない。レイヤ間および時間間の関係を得るために必要な全ての情報は、映像パラメータセットの中にある。映像パラメータセットは、パラメータセット階層において最も高い階層のパラメータセットである。

よって、上述した情報は、ＮＡＬヘッダ５７０内に含まれて信号送信される。しかしながら、図９Ａに示すＮＡＬヘッダおよびスライスヘッダの場合、スライスの依存性を示す情報にアクセスするには、ＰＰＳおよびＳＰＳといった追加的パラメータセットの経過を追跡記録する必要がある。一方、これは、メディアアウェアゲートウェイまたはルータの能力を再利用することになる。図９Ａから分かるように、スライスヘッダ９２０は、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇまで解析されなければならず、解析されたパラメータはネットワーク動作には役に立たない。

ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇに先行するスライスアドレスを解析できるようにするためには、図９Ｂに示されるＳＰＳ９３０に含まれるシンタックスエレメントのうち、次のシンタックスエレメントが必要である。図９Ｂは、ＳＰＳに含まれるシンタックスの例を示す図である。
・ｐｉｃ＿ｗｉｄｔｈ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ（図９Ｂの符号９３１）
・ｐｉｃ＿ｈｅｉｇｈｔ＿ｉｎ＿ｌｕｍａ＿ｓａｍｐｌｅｓ（図９Ｂの符号９３２）
・ｌｏｇ２＿ｍｉｎ＿ｃｏｄｉｎｇ＿ｂｌｏｃｋ＿ｓｉｚｅ＿ｍｉｎｕｓ３（図９Ｂの符号９３３）
・ｌｏｇ２＿ｄｉｆｆ＿ｍａｘ＿ｍｉｎ＿ｃｏｄｉｎｇ＿ｂｌｏｃｋ＿ｓｉｚｅ（図９Ｂの符号９３４）

これらのパラメータは、図９Ｂの右のテーブルに示されており、ｓｌｉｃｅ＿ａｄｄｒｅｓｓのパラメータの取得に必要である。シンタックスエレメントｓｌｉｃｅ＿ａｄｒｅｓｓは、可変長符号化されている（図９Ａのｓｌｉｃｅ＿ａｄｄｒｅｓｓ、スライスヘッダ９２０の第２欄（右欄）、記述子“ｖ”の長さを参照）。可変長符号化されたｓｌｉｃｅ＿ａｄｄｒｅｓｓのパラメータの長さを知るために、ＳＰＳに含まれるこれらのシンタックスエレメントが必要である。しかし、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇを解析するためには、シンタックスエレメントｓｌｉｃｅ＿ａｄｄｒｅｓｓの実際の値は必要ない。解析処理を続けるためには、可変長のシンタックスエレメントの長さが分かれば良い。

したがって、図９Ｂに示すＳＰＳ９３０に含まれるシンタックスエレメントのうち、ポイント９３５のシンタックスエレメントまで解析される必要がある。４つのシンタックスエレメントを格納する必要がある。それらは後で、シンタックスエレメントｓｌｉｃｅ＿ａｄｄｒｅｓｓの長さを計算する公式に用いられる。

さらに、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇに先行するｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇにアクセスするために、図９Ｃに示されるＰＰＳに含まれるシンタックスエレメントのうち、ポイント９４５のシンタックスエレメントまで解析される必要がある。図９Ｃは、ＰＰＳに含まれるシンタックスの例を示す図である。なお、図９Ａ〜９Ｃを参照して解析方法を説明したスライスヘッダ、ＳＰＳおよびＰＰＳ内のシンタックスエレメントは、通常のルータの動作には必要ない。さらに、シンタックスエレメントのいくつかは可変長符号で符号化されているため、単純にスキップすることはできない。つまり、ビットストリーム内で所定量分のビットをジャンプしても、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇまでジャンプすることはできない。

要するに、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇ（依存性インジケーション）を読み出すためには、ＭＡＮＥは、スライスヘッダ（スライスヘッダ９２０参照）の複雑な解析をさらに進める必要がある。

具体的には、ｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇが解析されなければならない。ｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇは、スライスがピクチャ内の最初のスライスであるか否かを示すフラグである。

その後、ＮＡＬＵタイプに条件付けられたｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇが解析されなければならない。

さらに、可変長符号化されたｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄが復号されなければならない。ｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄは、複数のパラメータセットのうち、どのパラメータセットを用いるかを示すシンタックスエレメント（パラメータセットを識別するシンタックスエレメント）である。ｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄを解析することで、利用するパラメータセットを特定できる。

最後に、ｓｌｉｃｅ＿ａｄｄｒｅｓｓが必要である。ｓｌｉｃｅ＿ａｄｄｒｅｓｓは、スライスの開始位置を示すシンタックスエレメントである。このシンタックスエレメントは、追加的計算とＰＰＳおよびＳＰＳの解析とをさらに必要とする。

最後に、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇがビットストリーム内に存在するか否かを知るために、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（依存スライス有効化フラグ）の値がＰＰＳから取得されなければならない。ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ＝０は、依存スライスは有効でないため、対象スライスが通常スライスであることを意味する。ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値を取得するために、ＰＰＳは真ん中ぐらいまで解析される必要がある。

残念ながら、データ位置が予め定められているＲＴＰヘッダおよびＮＡＬヘッダのデータの場合とは異なり、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇの前に位置するシンタックスエレメントはスキップすることができず、解析される必要がある。これは、スライスヘッダ内のシンタックスエレメントが可変長符号化されているためである。このため、全てのＶＣＬ ＮＡＬユニットについてエレメントの存在および長さが計算される必要がある。加えて、後で必要になるため（ＰＰＳおよびＳＰＳ参照）、追加的セッションデータが格納される必要がある。さらに、シンタックスエレメントの存在が、他のパラメータ構造に含まれることが想定される他のシンタックスエレメントの存在またはその値に依存するシンタックスエレメントもある（そのシンタックスエレメントは条件付きで符号化される）。

現在の標準化において、ビットストリーム内にいくつの層が含まれるかを記述するビデオパラメータセット（ＶＰＳ）内のビデオシーケンス依存性構成、および様々なレイヤ間の依存性を示す依存性インジケータを信号送信するという提案がある。ＶＰＳは、最初のＳＰＳの前に、映像の先頭に含まれて信号送信される。複数のＳＰＳが１つのＶＰＳを参照することができる。これは、１つのＶＰＳが複数のビデオシーケンスに有効な情報を保持していることを意味する。ＶＰＳの主な目的は、以下のような情報を含む映像コンテンツを、ルータまたはデコーダに通知することである。いくつのビデオシーケンスが含まれ、それらがどのように相互に関係しているか。ＳＰＳは、ビデオシーケンス内でのみ有効であり、ＶＰＳは、複数のビデオシーケンスに関連する情報を保持する。

さらに、ＶＰＳに保持される情報の特徴は、特にルータにとって有益である。例えば、ＶＰＳは、設計がファイナライズされていないため、ストリーミングセッションの設定に必要な情報を保持してもよい。ルータはＶＰＳ内の情報を解析する。さらに、ルータは、他のパラメータセットを必要とせずに（ＮＡＬヘッダを見るだけで）、どのデータパケットをデコーダに送信し、どのパケットを削除するかを決定できる。

しかしながら、現在有効なＶＰＳを発見するために、次の順序で以下のステップを実行する必要がある。
スライスヘッダ内のＰＰＳ＿ｉｄを解析するステップ、
ＰＰＳ＿ｉｄによって決定された有効ＰＰＳ内のＳＰＳ＿ｉｄを解析するステップ、
ＳＰＳ＿ｉｄによって決定された有効ＳＰＳ内のＶＰＳ＿ｉｄを解析するステップ。

上述した問題を解決するために、本発明の一態様に係る画像符号化方法は、ピクチャを複数のスライスに分割して符号化処理を実行する画像符号化方法であって、処理対象のスライス以外の他のスライスに対する前記符号化処理の結果に依存して前記符号化処理が行われる依存スライスが前記ピクチャに含まれるか否かを示す依存スライス有効化フラグ（ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ）と、前記処理対象のスライスの開始位置を示すスライスアドレスと、前記処理対象のスライスが前記依存スライスであるか否かを示す依存性インジケーション（ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇ）とを含むビットストリームを送信するステップを含み、前記依存スライス有効化フラグは、前記複数のスライスに共通のパラメータセット内に配置され、前記スライスアドレスは、前記処理対象のスライスのスライスヘッダ内に配置され、前記依存性インジケーションは、前記スライスヘッダ内であって、前記スライスアドレスの前、かつ、前記パラメータセットを識別するシンタックスエレメント（ｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄ）の後に配置されている。

上記構成の画像符号化方法では、スライス間の依存性に関する依存性インジケーションが、ルータによる解析に適した位置に配置されている。これにより、依存性インジケーションを他のシンタックスエレメントとは独立させて、つまり無条件に、符号化することが可能になる。

例えば、前記依存性インジケーションは、前記依存スライス有効化フラグが前記依存スライスを含むことを示す場合に、前記ビットストリームに含まれてもよい。

例えば、前記依存スライス有効化フラグは、前記パラメータセットの先頭に配置されていてもよい。

例えば、前記複数のスライスのそれぞれは、複数のマクロブロックを含み、１つ前の処理対象のスライスに含まれる複数のマクロブロックのうち、２つのマクロブロックに対する前記符号化処理の実行後に、前記処理対象のスライスに対する前記符号化処理の実行が開始されていてもよい。

例えば、前記依存性インジケーションは、前記複数のスライスのうち、前記ピクチャの最初に処理されるスライスのスライスヘッダには含まれなくてもよい。

このような問題を解決するために、本発明の一態様に係る画像復号方法は、ピクチャを複数のスライスに分割して復号処理を実行する画像復号方法であって、処理対象のスライス以外の他のスライスに対する前記復号処理の結果に依存して前記復号処理が行われる依存スライスが前記ピクチャに含まれるか否かを示す依存スライス有効化フラグと、前記処理対象のスライスの開始位置を示すスライスアドレスと、前記処理対象のスライスが前記依存スライスであるか否かを示す依存性インジケーションとを、符号化されたビットストリームから抽出するステップを含み、前記依存スライス有効化フラグは、前記複数のスライスに共通のパラメータセット内に配置され、前記スライスアドレスは、前記処理対象のスライスのスライスヘッダ内に配置され、前記依存性インジケーションは、前記スライスヘッダ内であって、前記スライスアドレスの前、かつ、前記パラメータセットを識別するシンタックスエレメントの後に配置されている。

例えば、前記依存性インジケーションは、前記依存スライス有効化フラグが前記依存スライスを含むことを示す場合に、前記ビットストリームから抽出してもよい。

例えば、前記依存スライス有効化フラグは、前記パラメータセットの先頭に配置されていてもよい。

例えば、前記複数のスライスのそれぞれは、複数のマクロブロックを含み、１つ前の処理対象のスライスに含まれる複数のマクロブロックのうち、２つのマクロブロックに対する前記復号処理の実行後に、前記処理対象のスライスに対する前記復号処理の実行を開始してもよい。

例えば、前記依存性インジケーションは、前記複数のスライスのうち、前記ピクチャの最初に処理されるスライスのスライスヘッダには含まれなくてもよい。

このような問題を解決するために、本発明の一態様に係る画像符号化装置は、ピクチャを複数のスライスに分割して符号化処理を実行する画像符号化装置であって、処理対象のスライス以外の他のスライスに対する前記符号化処理の結果に依存して前記符号化処理が行われる依存スライスが前記ピクチャに含まれるか否かを示す依存スライス有効化フラグと、前記処理対象のスライスの開始位置を示すスライスアドレスと、前記処理対象のスライスが前記依存スライスであるか否かを示す依存性インジケーションとを含むビットストリームを送信する符号化部を含み、前記依存スライス有効化フラグは、前記複数のスライスに共通のパラメータセット内に配置され、前記スライスアドレスは、前記処理対象のスライスのスライスヘッダ内に配置され、前記依存性インジケーションは、前記スライスヘッダ内であって、前記スライスアドレスの前、かつ、前記パラメータセットを識別するシンタックスエレメントの後に配置されている。

このような問題を解決するために、本発明の一態様に係る画像復号装置は、ピクチャを複数のスライスに分割して復号処理を実行する画像復号装置であって、処理対象のスライス以外の他のスライスに対する前記復号処理の結果に依存して前記復号処理が行われる依存スライスが前記ピクチャに含まれるか否かを示す依存スライス有効化フラグと、前記処理対象のスライスの開始位置を示すスライスアドレスと、前記処理対象のスライスが前記依存スライスであるか否かを示す依存性インジケーションとを、符号化されたビットストリームから抽出する復号部を含み、前記依存スライス有効化フラグは、前記複数のスライスに共通のパラメータセット内に配置され、前記スライスアドレスは、前記処理対象のスライスのスライスヘッダ内に配置され、前記依存性インジケーションは、前記スライスヘッダ内であって、前記スライスアドレスの前、かつ、前記パラメータセットを識別するシンタックスエレメントの後に配置されている。

このような問題を解決するために、本発明の一態様に係る画像符号化復号装置は、上述した画像符号化装置と、上述した画像復号装置とを備える。

上記構成の画像符号化方法および画像復号方法等によると、スライス間の依存性インジケーションは、スライスに関連するビットストリームのシンタックス内に独立して配置される。依存性インジケーションは、他のエレメントを不必要に解析することなく、ストリームから解析できる位置に、他のエレメントとは分離して配置される。上記ＨＥＶＣの例では、スライス間の依存性を示すインジケータｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇが、ネットワーク動作に関係しないシンタックスエレメントの解析が不要になる位置で信号により伝達される。

具体的には、少なくとも部分的に可変長符号を用いて符号化された画像における映像シーケンスのビットストリームを解析し、映像シーケンスの符号化されたスライスを運ぶデータユニットを含む装置を提供する。この装置は、スライスの可変長復号または解析が他のスライスに依存するか否かを示すシンタックスエレメントである依存性インジケーションを、ビットストリームから抽出するパーサを備え、依存性インジケーションは、他のシンタックスエレメントを前もって抽出する必要なく、他のシンタックスエレメントから独立して、ビットストリームから抽出される。

そのような装置は、例えば、図２のエントロピーデコーダ２９０内に含まれてもよい。ビットストリームからの抽出の指示は、抽出と、その抽出に必要な場合は、エントロピー復号を含む。エントロピー符号化は、可変長符号化、例えばＣＡＢＡＣのような算術符号化である。これはＨＥＶＣにおいて画像データの符号化に適用されている。ここで、データユニットとは、例えばＮＡＬユニットまたはアクセスユニットのことである。「他のシンタックスエレメントを抽出する必要なく」とは、依存性インジケーションに先行する複数のエレメントのいずれもが、存在しかつ長さが分かっているエレメント、または、すでに解析済みの状態にあるエレメント、または、条件付きで全く符号化されないエレメントである状況を指す。

さらに、少なくとも部分的に可変長符号で符号化されたビデオシーケンスのビットストリームを生成し、ビデオ画像の符号化スライスを保持するデータユニットを含む装置を提供する。この装置は、スライスの可変長復号が他のスライスに依存するか否かを示すシンタックスエレメントである依存性インジケータを、前記ビットストリームに埋め込むビットストリームジェネレータを備え、前記依存性インジケータは、他のシンタックスエレメントを前もって埋め込む必要なく、前記他のシンタックスエレメントから独立して、前記ビットストリームに埋め込まれる。

そのような装置は、例えば、図１のエントロピー符号化部１９０内に含まれてもよい。

上記構成の画像符号化方法および画像復号方法等によれば、ビットストリームは符号化されたスライスデータおよびそのスライスに関するヘッダデータを含み、依存性インジケータは、ビットストリーム内のスライスヘッダの先頭に位置する。これは、スライスヘッダがスライスの依存性を示すシンタックスエレメントで始まることを意味する。

なお、依存性インジケーションは、スライスヘッダの先頭に位置する必要はない。しかしながら、スライスヘッダ内に、他の条件付きで符号化されたシンタックスエレメント、および／または、可変長符号化されたシンタックスエレメントが、依存性インジケータに先行するシンタックスエレメントに含まれていない場合には有益である。

例えば、上述の先行技術におけるｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇの現在位置を、スライスヘッダの先頭に位置するように変更してもよい。この変更により、解析される必要があるシンタックスエレメントの量が削減される。さらに、可変長復号や、追加の計算および／または後で使うための追加のパラメータの格納および／または他のパラメータセットの解析が必要な情報の解析といった、ルータの複雑な解析処理を避けることができる。さらに、追跡記録が必要なパラメータセットの数が削減される。

以下、実施の形態について、図面を参照しながら具体的に説明する。なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。

（実施の形態１）
図１０は、本実施の形態におけるビットストリームのシンタックスの例を示す図である。図１０に示すＮＡＬヘッダ１０１０は、図９Ａに示すＮＡＬヘッダ９１０と同じである。つまり、変更されていない。

しかしながら、スライスヘッダ１０２０のシンタックス構造は、図９Ａのスライスヘッダ９２０のシンタックス構造とは異なる。スライスヘッダ１０２０では、特に、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇが、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇに先行するシンタックスエレメントがないように、スライスヘッダ内で上方に移動されている。ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇは、条件付きで符号化され、あるいは、可変長符号により符号化され、あるいは、追加の計算を要する解析が行われる。

シンタックスエレメントｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇおよびｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇは共に、実質的に、空間的依存性を決定する。それらのシンタックスエレメントは、他のシンタックスエレメントの解析が不要になるように、ＮＡＬヘッダの直後に符号化される。ｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇはまた、スライス間依存性に関連する情報を保持するため、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇに先行してもよい。シンタックスエレメントｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇは、全てのフレームは通常スライスで始めなければならないというルールに起因して設定されたフラグである。つまり、ｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇフラグが設定される場合は、スライスが通常スライスであり、独立していることを意味する。従って、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇおよびｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇの両方で、スライス間の依存性のインジケータと見なすことができる。

言い換えると、依存性インジケータは、スライスがピクチャの最初のスライスであるか否かを示す第１スライスインジケーション、および、スライスの可変長復号が他のスライスに依存するか否かを示す依存スライスフラグを含むと定義できる。ピクチャの最初のスライスは、常に、可変長復号において他のスライスに依存しないスライスである。

有利なことに、ビットストリームには、当該ビットストリームが依存スライスを含んでいる可能性があるか否かを示す依存スライス有効化フラグが含まれている。依存スライス有効化フラグがビットストリームに依存スライスが含まれている可能性があることを示す場合にのみ、依存性インジケーションがビットストリームに含まれる。依存スライス有効化フラグは、ビットストリームにおいて、複数のスライスに共通するパラメータセット内、かつ、当該パラメータセットの先頭に位置する。パラメータセットは、例えば、単一のピクチャに用いられる複数のパラメータを保持するピクチャパラメータセットであってもよい。または、依存スライス有効化フラグは、画像（映像）シーケンス全体に用いられる複数のパラメータを保持するシーケンスパラメータセット内に位置してもよい。

しかしながら、本実施の形態では、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇ（依存性インジケーション）が、シンタックスエレメントｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ（依存スライス有効化フラグ）を必要条件とせずに符号化される。本実施の形態では、ピクチャパラメータセットｉｄが依存性インジケーションの後に配置されるので、スライスヘッダ内でピクチャパラメータセットｉｄが信号により伝達される場合に起こりうる解析エラーを避けるのに有利である。

この変更はまた、スライス間の依存性を決定するために解析される必要のあるシンタックスエレメントの量を削減することを目的とした、パラメータセットまたはヘッダにおける他の必要なシンタックスエレメントの位置の変更と見なされてもよいし、および／または、変更により補間されてもよい。

例えば、ＨＭ８．０の現在のシンタックスのスライスヘッダにおけるシンタックスエレメントｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇは、シンタックスエレメント“ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ”の値が、ビットストリーム内の依存スライスの使用が有効であることを示す場合にのみ、存在する。依存スライスを有効にすることによってシンタックスエレメント“ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ”もまた、図９Ｃに示すように、ＰＰＳに含まれる。したがって、ＰＰＳ内のシンタックスエレメント“ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ”が、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇの解析に必要な自身の解析を単純化するために、ＰＰＳのシンタックス内で上方（例えば、パラメータセットの先頭に）に移動される。これはまた、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇがｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄ（パラメータセットを識別するシンタックスエレメント）の後に符号化される場合にも役に立ち得る。なぜなら、そうすることによって、依存スライス有効化フラグが依存性インジケーションの存在を必要とする場合でも、解析エラーが回避されるからである。

ＰＰＳ内で“ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ”を上方に移動させる代わりに、階層の低いパラメータセットを追跡記録する必要がなくなるように、“ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇ”がＰＰＳからＳＰＳおよび／またはＶＰＳに移動されてもよい。

つまり、本実施の形態によると、必要なシンタックスエレメントの位置は、追跡記録される必要のあるパラメータセットの量を削減する目的で変更される。これは、解析の複雑さも削減する。この文脈において、「必要なパラメータ」は、スライスが相互依存スライスであるか否かを決定するために役立つパラメータを意味する。ＨＥＶＣに直接適用可能な第１の可能性は、依存スライスのスライスヘッダの先頭に、スライスヘッダと異なるパラメータセットに含まれる依存スライス有効化フラグを必要条件としない依存性インジケーションを付加することである。ＨＥＶＣに直接適用可能な第２の可能性は、依存スライス有効化フラグが含まれるパラメータセットを識別するシンタックスエレメントのインジケーションの後に、依存スライスヘッダにおける依存性インジケーションを提供することである。依存性インジケーションは、依存スライス有効化フラグを必要条件としてもよい。ＰＰＳ内で依存スライス有効化フラグを上方に移動させること、または依存スライス有効化フラグをＳＰＳ内に移動させることは、これらの可能性の何れにも有益である。特に、依存スライス有効化フラグが依存性インジケーションの解析に必要である第２の可能性に関して有益である。

図１０から分かるように、ＮＡＬユニットヘッダは、スライスヘッダの関連する部分と合わせて、１８ビットを有する（ＮＡＬＵヘッダ１４ビット、スライスヘッダ２ビット）。この例によると、メディアアウェアネットワークエレメントが対象スライスパケットに対して次のように動作してもよい。先行する通常スライス、エントロピースライス、または依存スライスが削除されると、ネットワークエレメントは対象スライスヘッダの初めの２ビット、つまりｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇおよび（依存スライスがビットストリームに許容される場合）ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇをチェックする。

ＮＡＬユニットタイプがＶＣＬ ＮＡＬユニットタイプであり、チェックされた１８ビットの最後の２ビットが“０１”であれば、そのＮＡＬユニットは削除される。特に、スライスヘッダの先頭のビットが“１”であれば、それは、（ルールによれば）ピクチャの先頭の依存スライスでないスライスである。スライスヘッダの先頭のビットが“０”であり、次のビットも“０”であれば、そのスライスは独立している。したがって、スライスヘッダの先頭の２ビットが”０１”である場合にのみ、そのスライスは依存している。さらに、当該スライスは、親スライスが既に削除されているときは、復号できないため、削除されなければならない。よって、ｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇおよびｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇは、スライスヘッダシンタックスに属していても、ＮＡＬヘッダの拡張であると見なすことができる。

本実施の形態では、さらに、ネットワークパケットを受信し、分析し、目的地に転送するネットワークルータを提供する。このルータは、パケット目的地アドレスと符号化ビデオデータを有するビットストリーム部分とを含むネットワークパケットを受信する受信部と、他のパケットからの前記符号化ビデオデータの依存性を判定するために、上述したまたは後述の実施の形態に記載した符号化ビデオシーケンスのビットストリームを解析する前記装置を含むパーサと、前記受信されたパケットの目的地アドレスと、判定された依存性とを分析し、前記ネットワークパケットの扱い方を判断するパケットアナライザとを備える。

（実施の形態２）
本実施の形態２によれば、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇがＰＰＳから削除されている。なお、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、削除するのではなく、ＳＰＳに移動させてもよい。

図１１は、ｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇおよびｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇにアクセスする前に、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇを解析する必要がない例を示す図である。

この例では、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、依存性インジケーションの存在を必要条件としないため、用いられない。この例は、対象ＰＰＳセットの識別が分からないことに起因する解析上の問題を引き起こすことなく、スライスヘッダの先頭に依存性インジケーションを配置する可能性を提供する。

（実施の形態２の効果等）
実施の形態１では、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇを解析するためには、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇを解析しなければならない。ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、ＰＰＳ内に含まれて信号により伝達される。これは上述の通り、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇがＰＰＳの初めから遠い位置にあり、かつ先行するシンタックスエレメントが条件付きで符号化される場合に、解析のオーバーヘッドをもたらす可能性がある。

さらに、ＰＰＳにおいてシンタックスエレメントｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄが解析される前にシンタックスエレメントｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇを信号により伝達すると、次のような解析エラーが発生し得る。ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇの存在は、ＰＰＳ内に含まれて信号により伝達されるｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇに依存する。しかしながら、現在有効なＰＰＳのｉｄは、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇの後に信号により伝達される。したがって、先行するエレメントにアクセスする前にｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇを解析することはできない。

本実施の形態では、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇを必要条件とする解析を取り除くため、有益である。以下の制限を適用すると、さらに有益である。つまり、ＰＰＳ内のｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇがゼロであれば、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇはゼロになる。

しかしながら、これら有利な実施形態は、本発明の範囲を限定するものではない。

（実施の形態１および２の変形例１）
ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇを取り除く代わりに、または、それに追加的に、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇをＰＰＳからＳＰＳおよび／またはＶＰＳの何れかに移動させてもよい。

さらに、単にｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇを移動させる代わりに、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇをＳＰＳに複写させてもよい。この場合、ＳＰＳおよびＰＰＳ内のインジケータは、強制的に同じ値としてもよい。もしくは、ＰＰＳはＳＰＳ内のインジケータの上書きを許可されてもよい。

例えば、ｓｐｓ＿ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇが１であれば、ｐｐｓ＿ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇは０または１の可能性がある。ｓｐｓ＿ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇはＳＰＳ内に含まれて信号により伝達されたピクチャのシーケンスに用いられる依存スライスの有効化を示すインジケーションであり、ｐｐｓ＿ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、ＰＰＳ内に含まれて信号により伝達されたピクチャに用いられる依存スライスの有効化を示すインジケーションである。しかしながら、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇの値がＰＰＳ内で変化できるなら、これは、ＰＰＳの解析が依然として必要であることを意味し、ＰＰＳの追跡記録および解析の頻度が低くなるという効果が防げられる。

これらの変形例は、ＶＰＳおよびＳＰＳが依存構造を保持するという効果を奏する。ＶＰＳおよびＳＰＳが依存構造を保持することにより、ネットワークエレメントがビットストリームを形成できる、つまりどうしても復号できない依存パケットを削除することができる、または独立スライスではない依存スライスを削除すると決定することができる。したがって、ＶＰＳ内のｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇは、ルータがスライスヘッダを追加的に確認するか、またはしないかのトリガとなる。

これらの変形例は、図１０および１１の例において適用された場合、解析における複雑さをさらに低減するものではない。しかしながら、これは依存性構造を保持するためのさらに有益なシンタックス構造を提供する。要するに、この例によれば、依存スライスがビットストリームに対して有効か否かを示すインジケータが、映像パラメータセット内に含まれて信号により伝達される。ここで、映像パラメータセットは、複数のピクチャにおける複数のスライスに適用するパラメータセットである。

ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇがＶＰＳおよび／またはＳＰＳにおいて信号により伝達される場合、２つの効果がある。フラグが単に移動または複写されている場合は、ＰＰＳは解析される必要がなく、その結果、解析のオーバーヘッドが削減される。もう一つの利点は、ルータに映像シーケンスの予測構造を知らせることができる点である。この効果は常にある。通常、ルータは、何を受信するかを知るために、ＶＰＳ／ＳＰＳの内容を確認してもよい。

ＶＰＳは、階層において最上位のパラメータである。ＳＰＳおよびＰＰＳはそれぞれ１つの映像シーケンスおよび１つのピクチャに対応するのに対して、ＶＰＳは複数の映像シーケンスに関する情報を含むことができる。ＶＰＳに含まれる情報は、ビットレートあるいは映像シーケンスのｔｅｍｐｏｒａｌ＿ｌａｙｅｒｉｎｇ構造等である。また、レイヤ間の依存性（異なる映像シーケンス間の依存性）に関する情報を含む。よって、ＶＰＳを、複数の映像シーケンスの入れ物としてみなすことができ、ＶＰＳにより、各シーケンスの概要が分かる。

ＨＥＶＣの最新版において、フレームにおけるスライス間の依存性は、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇおよびｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇの両方によって規定されている。最新の仕様書によれば、ネットワークエンティティは、非常に複雑な解析を適用することなくスライス間の依存性を利用することはできない。単純な解決法は、パケット番号の欠落によってパケットのロスが発見された場合、値が１のｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇが見つかるまで全てのパケットを削除することである。なぜなら、ピクチャの先頭のスライスは、常に通常スライスだからである。

しかしながら、この解決法は、符号化効率の低下につながる。したがって、上述の通り、スライス間依存性の信号による伝達を有効にする効率的な解析が採用されてもよい。これは、ＮＡＬヘッダの直後のスライスヘッダ内において、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇおよびｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇを信号により伝達することによって達成される。

その代わりまたはそれに加えて、スライス間依存性に関連するシンタックスエレメントは、無条件に、つまり、スライスヘッダまたはＰＰＳ内にある他のシンタックスエレメントとは独立して符号化される。

（実施の形態１および２の変形例２）
図１２は、上記の変形例１に代わる他の変形例２を示す図である。具体的には、ＮＡＬユニットヘッダ１２１０は、図１０に示すＮＡＬユニットヘッダ（図９Ａに示すＮＡＬユニットヘッダ９１０）と同じである。しかしながら、スライスヘッダ１２２０は、図１０に示すスライスヘッダ１０２０とは、シンタックスエレメントｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇおよびｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇの順番が逆になっている。特に、スライスヘッダ１２２０は、最初のシンタックスエレメントとしてｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇを含み、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇの存在を必要条件として、２番目のシンタックスエレメントとしてシンタックスエレメントｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇを含む。

この例から分かるように、スライスがピクチャにおける先頭のスライスであるか否かを示す第１スライスインジケーションが、シンタックスに含まれる。ピクチャにおける先頭のスライスは、常に、可変長復号において他のスライスに依存しないスライスである。さらに、依存スライスフラグは、ビットストリームにおいて、第１スライスインジケーションの前に含まれる。第１スライスインジケーションは、依存スライスフラグが依存スライスであることを示さない場合にのみビットストリームに含まれる。この配置は、条件付けと同じ効果をもたらす。つまり、依存性フラグは、第１スライスインジケーションを必要条件とする。図１２から分かるとおり、両方のエレメントが依存性インジケーションとして理解されてもよく、スライスヘッダの先頭に含まれる。

（実施の形態３）
本実施の形態３では、実施の形態１および実施の形態２と比較して、不必要なシンタックスエレメントの解析を減らすために、シンタックスエレメントの配置方法が変更されている。

上記実施の形態では、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇの存在を必要条件としてｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇが含まれる場合について説明したが、ｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇおよびｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇは、共に、互いの存在を必要条件とせずにビットストリームに含まれてもよい。例えば、上記の変形例のうちの１つおいて、シンタックスエレメントｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇから独立させるために、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇの符号化方法を変更する。

図１３は、本実施の形態のスライスヘッダの一例を示す図である。図１３に示す例では、依存スライス有効化フラグに関する依存性インジケーションの条件付けを依然として含む場合を示している。

具体的には、本実施の形態のスライスヘッダでは、図６に示す従来のスライスヘッダと比較して、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇが、ｓｌｉｃｅ＿ａｄｄｒｅｓｓの前に配置されている。さらに、本実施の形態のスライスヘッダでは、図１０〜図１２に示す例と比較して、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇが、ｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの後に配置されている。

本実施の形態では、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇがｓｌｉｃｅ＿ａｄｄｒｅｓｓの前に配置されているので、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇを解析するのに、少なくともＳＰＳを解析する必要がない。上述したように、ｓｌｉｃｅ＿ａｄｄｒｅｓｓは、スライスの開始を示すシンタックスエレメントである。さらに、ｓｌｉｃｅ＿ａｄｄｒｅｓｓは、ＳＰＳ内に含まれて信号により伝達されたシンタックスエレメント（ｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄ）の助けによってのみ解析できる。

その代わりに、またはそれに加えて、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇはＰＰＳ内で上方に移動されるか、ＳＰＳおよび／またはＶＰＳに移動される。有効化フラグがＶＰＳおよび／またはＳＰＳ内にある場合は、解析ならびにＰＰＳおよびＳＰＳの追跡記録が必要としなくてもよい。

（実施の形態３の変形例、効果等）
（１）少なくとも部分的に可変長符号で符号化されたビデオシーケンスであって、ビデオ画像の符号化スライスを保持するデータユニットを含むビデオシーケンスのビットストリームを解析する装置において、図１３に示すスライスヘッダを持つビットストリームを解析するように構成してもよい。この場合、当該装置を、ビットストリームから以下のシンタックスエレメントを抽出するパーサを備えるように構成する。
−スライスの可変長復号が他のスライスに依存するか否かを示す、スライスヘッダ内のシンタックスエレメントである依存性インジケーション、
−複数のスライスに用いられるパラメータセット内に含まれ、依存スライスがビットストリーム内に含まれるか否かを示す依存スライス有効化フラグ、および、
−ビットストリーム内のスライスが開始する位置を示すスライスアドレス。

（２）また、本実施の形態では、依存性インジケーションは、スライスアドレスの前、かつ、前記パラメータセットを識別するシンタックスエレメントの後に、スライスヘッダ内に含まれて信号により伝達される。

したがって、本実施の形態では、依存スライスをビットストリームに含むことができることを依存スライス有効化フラグが示す場合のみ、解析エラーを起こすことなく、依存性インジケーションがビットストリームに含まれるように構成することができる。

（３）さらに、本実施の形態では、依存スライス有効化フラグは、ビットストリーム内の、同一のピクチャフレームを形成する複数のスライスに共通のパラメータセット（ＰＰＳ）内、かつ、前記パラメータセットの先頭に配置しているが、これに限るものではない。

その代わりに、（またはそれに加えて）、依存スライス有効化フラグは、ビットストリーム内の、同一のピクチャシーケンスを形成する複数のスライスに共通のパラメータセット（ＳＰＳ）内に位置してもよい。さらにその代わりに、（またはそれに加えて）、依存スライス有効化フラグは、ビットストリーム内の、複数のピクチャフレームシーケンスを形成する複数のスライスに共通のパラメータセット（ＶＰＳ）内に位置してもよい。

（４）また、本実施の形態において、ＶＰＳ＿ｉｄおよびＳＰＳ＿ｉｄを、ＳＥＩメッセージ内に含めて明示的に信号により伝達するように構成してもよい。ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇがＳＰＳ内に含まれて信号により伝達される場合、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇは依然としてｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄに後続しなければならない。

そうしなければ、ＳＰＳ＿ｉｄがＰＰＳ内に含まれて信号により伝達されることから、解析において依存性が導入される。ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇを保持する対象ＳＰＳまたはＶＰＳの識別を信号により伝達することによって、その後のピクチャパラメータセットの解析が不要であるため、依存性インジケーションをｐｉｃ＿ｐａｒａｍｅｔｅｒ＿ｓｅｔ＿ｉｄの前に含めてもよい。さらに、ＶＰＳ＿ｉｄまたはＳＰＳ＿ｉｄを保持するＳＥＩメッセージは、それらのＩＤもＰＰＳを解析することによって決定されるので、復号処理に不要である。よって、ＳＥＩメッセージは、ネットワークエレメントに使用された後に、復号処理に影響することなく削除できる。

（実施の形態４）
本実施の形態４では、スライス間依存性の情報が、ＳＥＩメッセージのような他のＮＡＬユニットに（スライスヘッダおよび／またはパラメータセット内に含まれて信号により伝達された情報の補足に）複写される。

例えば、全てのアクセスユニット内の、または各依存スライスの前のスライス間依存性の情報を伝達するＳＥＩメッセージを定義してもよい。「アクセスユニット」という用語は、ＮＡＬユニットのセットからなるデータユニットを指す。アクセスユニットは、複数の符号化ピクチャスライス、つまり複数のＶＣＬ ＮＡＬＵを含む。特に、アクセスユニットはランダムアクセスに用いられるポイントを定義してもよく、単一のピクチャの複数のＮＡＬＵを含んでもよい。しかしながら、アクセスユニットは必ずしもランダムアクセスポイントでなくてもよい。

最新のＨＥＶＣ仕様書において、アクセスユニットは復号順に連続したＮＡＬユニットのセットとして定義され、きっちり１つの符号化ピクチャを含む。符号化ピクチャの符号化スライスＮＡＬユニットに加えて、アクセスユニットは、符号化ピクチャのスライスを含まない他のＮＡＬユニットも含んでもよい。アクセスユニットの復号は、常に、復号ピクチャをもたらす。しかしながら、ＨＥＶＣの将来の拡張において（マルチビュー符号化（ＭＶＣ）またはスケーラブル映像符号化（ＳＶＣ）のように）、アクセスユニットの定義は緩和／修正されてもよい。最新の仕様書によれば、アクセスユニットは、アクセスユニットデリミター、ＳＥＩメッセージ、およびＶＣＬ ＮＡＬＵによって形成されている。

よって、本実施の形態によれば、依存性インジケーションは、ビットストリームにおいて、依存性インジケーションが関連するスライスのヘッダの外に位置する。さらに、依存性インジケーションが、ビットストリームにおいて、依存スライスの前またはアクセスユニット毎にビットストリーム内に含まれるＳＥＩメッセージ内に位置すれば、有益かも知れない。

（実施の形態５）
本実施の形態５によれば、スライス間依存性情報は、フラグとして、または暗示的に、関連するＮＡＬユニットタイプとしてＮＡＬヘッダ内に含まれて信号により伝達される。

規則として、ＮＡＬヘッダにおけるシンタックスエレメントの解析は、他のシンタックスエレメントの何れにも依存しない。全てのＮＡＬユニットヘッダは、独立して解析できる。ＮＡＬヘッダは、通常、依存性情報を信号により伝達させる場所である。従って、本実施の形態によれば、スライス間依存性も、ＮＡＬヘッダに含まれて信号送信される。

言い換えると、解析装置は、ルータまたはデコーダに採用されてもよい。解析装置は、さらに、ネットワーク適応レイヤ、ＮＡＬヘッダを符号化映像データのスライスおよび当該スライスのヘッダに追加するためのネットワーク適応レイヤユニットをさらに含む。有利な点は、依存性インジケーションは、ビットストリームにおいて、ＮＡＬヘッダ内に位置し、他のシンタックスエレメントとは独立して符号化される点である。

最新のＨＥＶＣ仕様書におけるＮＡＬヘッダは、そのために用いることができる予備のビットを想定しているため、依存性インジケータは、ＮＡＬヘッダ内に位置してもよい。依存性インジケーションの信号による伝達は、単一のビットで十分と思われる。

または、依存性インジケーションは、ＮＡＬユニットタイプによって示され、予め定義されたＮＡＬユニットタイプは依存性情報を保持するために保存される。

（実施の形態６）
上記５つの実施の形態は、ネットワークエレメントにおける依存性の情報を効率的に解析できるようにするために、任意に組み合わせてもよい。それらの使用が重複しても、当該実施の形態は組み合わせ可能である。したがって、依存性インジケーションがスライスヘッダの先頭に含まれて信号により伝達されている場合でも、依存性インジケーションの複写は適用可能である。

図１４は、図９Ａに示すＮＡＬユニットヘッダ９１０を修正したＮＡＬユニットヘッダ１４１０の例を示す図である。ＮＡＬユニットヘッダ１４１０は、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇを含む。

さらに、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇをＮＡＬヘッダに移動させ、後方互換性のためＮＡＬヘッダのサイズを固定し続けるために、ＮＡＬユニットヘッダのシンタックスエレメントｎｕｈ＿ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿６ｂｉｔｓからｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇに必要な１ビットが取得される。よって、シンタックスエレメントｎｕｈ＿ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿６ｂｉｔｓは、現在５ビットのみを有する。シンタックスエレメントｎｕｈ＿ｒｅｓｅｒｖｅｄ＿ｚｅｒｏ＿６ｂｉｔｓは、ビットの減少が何ら問題を起こさず、さらなる修正を要しないように、後で用いるための予備のビットを有する。

一般的に、対象ＶＣＬ ＮＡＬユニットは、同一のｔｅｍｐｏｒａｌ＿ｌａｙｅｒ＿ｉｄを有する先行するＶＣＬ ＮＡＬユニットに依存する。ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇがＮＡＬヘッダ内に含まれて信号により伝達されている場合は、ピクチャスライスまたはパラメータセットといった全てのデータユニットが同じＮＡＬヘッダを有するため、ＶＣＬおよび非ＶＣＬ ＮＡＬユニットの両方に１ビットが浪費される。よって、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇも、パラメータセットまたはＳＥＩメッセージに用いられるように信号により伝達されると思われるが、それは不必要である。さらに、依存スライスがシーケンスパラメータセット内で無効になっても、ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇは、常に信号による伝達が必要である。これは不必要なオーバーヘッドにつながる。

上記全ての実施形態において、依存性インジケーションは１ビットのフラグでもよい。

（実施の形態７）
本実施の形態７によれば、依存性インジケーションはＮＡＬユニットタイプによって示され、予め定義されたＮＡＬユニットタイプは、依存性情報を保持するために保存される。

よって、新たな（別個の）ＶＣＬ ＮＡＬタイプが、既存のＶＣＬ ＮＡＬユニットのように、類似の記号論で定義される。例えば、ＮＡＬ＿ｕｎｉｔ＿ｔｙｐｅの値が１５に（または他の予め定義されたタイプ、または他の特定タイプのＮＡＬＵのために保存されていないＮＡＬＵに）等しければ、対象ＶＣＬ ＮＡＬユニットは同一のｔｅｍｐｏｒａｌ＿ｌａｙｅｒ＿ｉｄを有する先行ＶＣＬ ＮＡＬユニットに依存する。その依存性は、上述の通り、先行スライスのスライスヘッダに対する対象スライスの依存性、つまり解析における依存性に関連する。

これらの場合において、追加的ＮＡＬユニットタイプにＮＡＬヘッダ内のビットを含めると有益であると考えられる。これは、対象スライスが依存スライスであるか否かを示すために用いることができる。

依存性情報がＮＡＬヘッダ内に含まれての信号による伝達に加えて、スライスヘッダ内に含まれての信号による伝達が可能な場合、ＮＡＬヘッダ内に含まれての信号による伝達はオプションにより選択されることになる。具体的には、ＮＡＬヘッダ内のＮＡＬ＿ｕｎｉｔ＿ｔｙｐｅフィールドが、対象スライスが依存スライスであることを信号により伝達するように構成されていれば、他の「タイプ」の情報を信号により伝達することはできない。例えば、対象スライスが「シーケンスにおける先頭のピクチャ」（１０または１１に等しいＮＡＬ＿ｕｎｉｔ＿ｔｙｐｅ）であるという情報を伝達するほうがより有益な場合がある。（スライスヘッダ内に複写されていることにより）ＮＡＬヘッダにおけるスライス間依存性情報オプションにより選択可能であれば、より価値のある情報を信号により伝達することが選択されてもよい。

さらに、（解析に用いられる）「依存スライスＲＡＰピクチャ」または「依存スライス非ＲＡＰピクチャ」といった２つ以上のＶＣＬ ＮＡＬユニットタイプを追加することは有益であると考えられる。“ＲＡＰ”という用語は、ランダムアクセスピクチャを示す。ランダムアクセスピクチャは、他のピクチャとは（予測に関して）独立して符号化されたピクチャなので、符号化および復号の開始点として用いてもよい。これにより、ランダムアクセスポイントとして適する。

依存スライスヘッダにおいて、シンタックスエレメントＲａｐＰｉｃＦｌａｇが解析処理に用いられる。具体的には、シンタックスエレメントＲａｐＰｉｃＦｌａｇは、対象ピクチャがランダムアクセスピクチャであるか否かを示すインジケーションである。

ＲＡＰＰｉｃＦｌａｇの値は、以下の式２のようにＮＡＬユニットタイプに依存する。

つまり、図１５に示す例では、ランダムアクセスピクチャは、ＮＡＬＵタイプが７から１２のＮＡＬＵによって保持される。本実施の形態では、正確な解析を可能にし、ランダムアクセスピクチャに対するスライス依存性の可能性を提供するために、２つの異なるＮＡＬユニットタイプが、スライスヘッダの正確な解析を保証する目的で定義されている。

全般的なルールとして、新たなＶＣＬ ＮＡＬユニットタイプが定義されたとしても、スライスヘッダの解析は、依然として何ら問題なく可能であると考えられる。複数のＮＡＬタイプの何れかが上記のように定義されるか、あるいは、解析に問題が生じない方法で依存スライスヘッダが変更される。

新しいＶＣＬ ＮＡＬユニットタイプが依存スライスであることを示す場合、スライスヘッダのシンタックス構造は、下記のように変更される。

上述した例のＮＡＬユニットタイプ“ＤＳ＿ＮＵＴ”は、処理対象ＶＣＬｎａｌユニットが依存スライスであることを示すために用いられる。非特許文献３に記載されている最新のスライスヘッダのシンタックス構造と比較すると、本実施の形態では、下記の２つの変更が導き出される。

（１）ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇが、依存スライスに含まれていない。言い換えると、ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇは、処理対象スライスが依存スライスではない場合に存在する。（処理対象スライスが依存スライスではない場合に、ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇはスライスヘッダに存在する。）

（２）ｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇが、ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅの値に応じて含まれる。ｎａｌ＿ｕｎｉｔ＿ｔｙｐｅの値が、処理対象スライスが依存スライスであることを示す場合、シンタックスの要素ｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇは明示的に含まれず、０になると推測される。これは、同じ品質でビットレートを維持する。

上述した例によれば、処理対象スライスが依存スライスである場合、ｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇは含まれない。ＲａｐＰｉｃＦｌａｇの値は、処理対象スライスが依存スライスである場合、評価の為に必要とされない。このため、依存スライスのスライスヘッダは、問題無く評価できる。さらに依存スライスのスライスヘッダは、先行するｎａｌユニットヘッダのＮＡＬユニットヘッダを参照することなく、解析することができる。先行するｎａｌユニットヘッダが復号時に存在しない場合は、問題が生じる。

次に、ｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇは、ＮＡＬ＿ｕｎｉｔ＿ｔｙｐｅの値に基づいて含められる。この変更は、図１２に示される例と同じである。図１２では、ｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇは、処理対象スライスが依存スライス（ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇにより示される）ではない場合にのみ、スライスヘッダに含められる。同様に、処理対象スライスが依存スライスではないことを意味する“ＤＳ＿ＮＵＴ”とｎａｌ＿ｕｎｉｔ＿ｔｙｐｅとが等しくない場合にのみ、上述した例のｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇが含められる。

上述した２つの変更は、同時に行う必要は無い。また、スライスヘッダにおいて、一方の変更のみを行ってもよい。各変更の利点は、スライスが依存スライスであるか否かのチェックコストに関連する。しかし、２つの変更が同時に実行された場合、２つのシンタックスエレメントｆｉｒｓｔ＿ｓｌｉｃｅ＿ｉｎ＿ｐｉｃ＿ｆｌａｇおよびｎｏ＿ｏｕｔｐｕｔ＿ｏｆ＿ｐｒｉｏｒ＿ｐｉｃｓ＿ｆｌａｇが連続してコーディング（符号化）されている場合は、２つの変更の利点は、個々に変更した場合の個々の利点と同じになる。従って、２つの変更と、２つのシンタックスエレメントの連続したコーディングとを組み合わせたアプリケーションでは、個々の変更を個別に行うアプリケーションよりも利点がある。

実施の形態の説明の全てにおいて、依存スライスの指標が条件付きで符号化されていない場合は、ビットストリームからｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇを削除することが可能である。言い換えると、新しいＮＡＬユニットタイプを処理対象スライスが依存スライスであることを示すために用いるなら、ビットストリームからｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｅｎａｂｌｅｄ＿ｆｌａｇを削除することができる。

図１５は、図９Ａに示すＮＡＬユニットヘッダ９１０と同一のＮＡＬユニットヘッダ１５１０と、図９Ａに示すスライスヘッダ９２０を変更したスライスヘッダ１５２０の例を示す図である。スライスヘッダ１５２０は、ＮＡＬＵのタイプに従ってｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇ値の終端を含む。特に、１５および１６の値を有するＮＡＬ＿ｕｎｉｔ＿ｔｙｐｅシンタックスエレメントは、依存スライスを定義する。ＮＡＬ＿ｕｎｉｔ＿ｔｙｐｅが１５に等しい場合は、スライスのタイプはランダムアクセスピクチャの依存スライスである。一方、ＮＡＬ＿ｕｎｉｔ＿ｔｙｐｅが１６に等しければ、当該スライスは非ランダムアクセスピクチャの依存スライスである。従って、以下の式３の関係が成り立つ。

なお、値１５および１６は、単に一例として選択された。当業者には明らかなとおり、他には用いられない予め定義された任意の番号を採用してもよい。具体的には、ＮＡＬＵの第１タイプはランダムアクセスピクチャの依存スライスの内容を識別するために定義され、ＮＡＬＵの第２タイプは非ランダムアクセスピクチャの依存スライスの内容を識別するために定義される。

さらに、依存スライスはＲＡＰのみに用いられるか、または非ＲＡＰのみに用いられるという制限が適用されてもよい。その場合、新たなＮＡＬＵタイプは１つだけ必要である。

（実施の形態８）
図１６は、代替的な解決法を示す図である。ＮＡＬユニットヘッダ１６１０は、ＮＡＬユニットヘッダ９１０と同じである。スライスヘッダ１６２０では、ＮＡＬ＿ｕｎｉｔ＿ｔｙｐｅが、上述したような依存スライスを定義する値１５および１６を有すると仮定している。

しかしながら、ＮＡＬ＿ｕｎｉｔ＿ｔｙｐｅは依存スライスフラグの解析において用いられない。これにより、エンコーダによるＮＡＬ＿ｕｎｉｔ＿ｔｙｐｅの使用は、オプション化することができる。したがって、本実施の形態の効果は、エンコーダが新たなＮＡＬＵタイプの採用を決定したときにのみ達成される。

そして、ルータはＮＡＬＵタイプを検証するだけでよい。しかしながら、エンコーダが上述した新たなＮＡＬＵタイプを使用しなければ、ルータは技術水準の通りに依存スライスを取り扱うと考えられる。

要するに、依存性インジケーションは、ＮＡＬユニットタイプによって示されてもよい。また、予め定義されたＮＡＬユニットタイプは、スライスヘッダが先行スライスのスライスヘッダに依存する符号化されたスライスを保持するために保存されてもよい。有利な点は、依存性を示す別個のＮＡＬユニットタイプが、ランダムアクセスピクチャおよび非ランダムアクセスピクチャに対して提供される点である。

要するに、上述した実施の形態は、符号化映像シーケンスを保持するビットストリームのシンタックスに関する。特に、上述した実施の形態は、スライスヘッダが先行スライスのスライスヘッダに依存する依存スライスおよびエントロピースライスに関連するシンタックスに関する。メディアアウェアネットワーク要素が、その複雑性および解析による遅延を実質的に増加させずにこの種の依存性を考慮できるようにするために、依存性のインジケーションがパケットの先頭、つまり、解析対象のヘッダまたはパラメータの近傍に含まれて信号により伝達される。これは、例えば、スライスヘッダの先頭に（図１０〜図１２）、できれば、パラメータセットを識別するシンタックスの後、かつ、スライスアドレスの前に依存性インジケーションを含めることによって（図１０、図１１）、または、別個のメッセージを用い、ＮＡＬＵヘッダに依存性インジケーションを提供することによって（図１４）、または、依存スライスを保持するＮＡＬＵに用いられる特別なＮＡＬＵタイプを用いて（図１５、図１６）達成される。

（上記実施の形態１〜８の変形例、効果等）
本発明は、以上の実施例に限定されることなく、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。

なお、上記各実施の形態において、各構成要素は、専用のハードウェア（処理回路）で構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。

なお、上記実施の形態１〜８では、ｗａｖｅｆｒｏｎｔを前提として説明したが、これに限るものではない。

但し、ｗａｖｅｆｒｏｎｔの場合、全てのサブストリームを同時に開始することはできない。上述したように、先頭のサブストリーム以外の各サブストリームについては、処理（符号化または復号）の開始が、先行するサブストリームよりもＬＣＵ２つ分遅れることになる。このため、ｗａｖｅｆｒｏｎｔでは、より処理の短縮が求められている。本実施の形態では、依存性インジケーション（ｄｅｐｅｎｄｅｎｔ＿ｓｌｉｃｅ＿ｆｌａｇ）を、ＰＰＳを識別するシンタックスの後、スライスアドレスの前に配置することで、解析するシンタックスエレメントの数を減らすことができ、処理を短縮することが可能になる。

また、上記実施の形態１〜８では、依存性インジケーションをスライスヘッダ内のより上方に（特に、先頭に）配置することで、例えば、ピクチャの処理のより早い段階で、各スライスが依存スライスであるか否かを確認することが可能になる。

つまり、ピクチャに対する処理（符号化処理または復号処理）の開始時に、複数のスライスのそれぞれについて、依存スライスであるか否かを確認するステップを実行すれば、ピクチャに対する処理の開始時に、並列処理の開始点を抽出することが可能になる。つまり、ピクチャに複数の通常スライスが含まれる場合に、ピクチャに対する処理の開始時（あるいは、処理の早い段階で）並列処理の開始点を抽出できる。

ここで、従来のように、依存性インジケーションがスライスアドレスの後に配置されている場合は、当該スライスアドレスの解析が終わるまで、スライスが依存スライスか通常スライスであるかを確認できない。この場合、ピクチャの途中にある通常スライスの処理の開始は、ピクチャの先頭にある通常スライスの処理の開始より相当遅れることになる。

これに対し、上述した実施の形態１〜８では、ピクチャの処理のより早い段階で、各スライスが依存スライスであるか否かを確認することが可能になるため、ピクチャの途中にある通常スライスの処理の開始を、より早めることが可能になる。言い換えると、ピクチャの途中にある通常スライスの処理を、ピクチャの先頭にある通常スライスとほぼ同時に開始することが可能になる。

（実施の形態９）
上記各実施の形態で示した動画像符号化方法（画像符号化方法）または動画像復号化方法（画像復号方法）の構成を実現するためのプログラムを記憶メディアに記録することにより、上記各実施の形態で示した処理を独立したコンピュータシステムにおいて簡単に実施することが可能となる。記憶メディアは、磁気ディスク、光ディスク、光磁気ディスク、ＩＣカード、半導体メモリ等、プログラムを記録できるものであればよい。

さらにここで、上記各実施の形態で示した動画像符号化方法（画像符号化方法）や動画像復号化方法（画像復号方法）の応用例とそれを用いたシステムを説明する。当該システムは、画像符号化方法を用いた画像符号化装置、及び画像復号方法を用いた画像復号装置からなる画像符号化復号装置を有することを特徴とする。システムにおける他の構成について、場合に応じて適切に変更することができる。

図１７は、コンテンツ配信サービスを実現するコンテンツ供給システムex１００の全体構成を示す図である。通信サービスの提供エリアを所望の大きさに分割し、各セル内にそれぞれ固定無線局である基地局ex１０６、ex１０７、ex１０８、ex１０９、ex１１０が設置されている。

このコンテンツ供給システムex１００は、インターネットex１０１にインターネットサービスプロバイダex１０２および電話網ex１０４、および基地局ex１０６からex１１０を介して、コンピュータex１１１、ＰＤＡ（Personal Digital Assistant）ex１１２、カメラex１１３、携帯電話ex１１４、ゲーム機ex１１５などの各機器が接続される。

しかし、コンテンツ供給システムex１００は図１７のような構成に限定されず、いずれかの要素を組合せて接続するようにしてもよい。また、固定無線局である基地局ex１０６からex１１０を介さずに、各機器が電話網ex１０４に直接接続されてもよい。また、各機器が近距離無線等を介して直接相互に接続されていてもよい。

カメラex１１３はデジタルビデオカメラ等の動画撮影が可能な機器であり、カメラex１１６はデジタルカメラ等の静止画撮影、動画撮影が可能な機器である。また、携帯電話ex１１４は、ＧＳＭ（登録商標）（Global System for Mobile Communications）方式、ＣＤＭＡ（Code Division Multiple Access）方式、Ｗ−ＣＤＭＡ（Wideband-Code Division Multiple Access）方式、若しくはＬＴＥ（Long Term Evolution）方式、ＨＳＰＡ(High Speed Packet Access)の携帯電話機、またはＰＨＳ（Personal Handyphone System）等であり、いずれでも構わない。

コンテンツ供給システムex１００では、カメラex１１３等が基地局ex１０９、電話網ex１０４を通じてストリーミングサーバex１０３に接続されることで、ライブ配信等が可能になる。ライブ配信では、ユーザがカメラex１１３を用いて撮影するコンテンツ（例えば、音楽ライブの映像等）に対して上記各実施の形態で説明したように符号化処理を行い（即ち、本発明の一態様に係る画像符号化装置として機能する）、ストリーミングサーバex１０３に送信する。一方、ストリーミングサーバex１０３は要求のあったクライアントに対して送信されたコンテンツデータをストリーム配信する。クライアントとしては、上記符号化処理されたデータを復号化することが可能な、コンピュータex１１１、ＰＤＡex１１２、カメラex１１３、携帯電話ex１１４、ゲーム機ex１１５等がある。配信されたデータを受信した各機器では、受信したデータを復号化処理して再生する（即ち、本発明の一態様に係る画像復号装置として機能する）。

なお、撮影したデータの符号化処理はカメラex１１３で行っても、データの送信処理をするストリーミングサーバex１０３で行ってもよいし、互いに分担して行ってもよい。同様に配信されたデータの復号化処理はクライアントで行っても、ストリーミングサーバex１０３で行ってもよいし、互いに分担して行ってもよい。また、カメラex１１３に限らず、カメラex１１６で撮影した静止画像および／または動画像データを、コンピュータex１１１を介してストリーミングサーバex１０３に送信してもよい。この場合の符号化処理はカメラex１１６、コンピュータex１１１、ストリーミングサーバex１０３のいずれで行ってもよいし、互いに分担して行ってもよい。

また、これら符号化・復号化処理は、一般的にコンピュータex１１１や各機器が有するＬＳＩex５００において処理する。ＬＳＩex５００は、ワンチップであっても複数チップからなる構成であってもよい。なお、動画像符号化・復号化用のソフトウェアをコンピュータex１１１等で読み取り可能な何らかの記録メディア（ＣＤ−ＲＯＭ、フレキシブルディスク、ハードディスクなど）に組み込み、そのソフトウェアを用いて符号化・復号化処理を行ってもよい。さらに、携帯電話ex１１４がカメラ付きである場合には、そのカメラで取得した動画データを送信してもよい。このときの動画データは携帯電話ex１１４が有するＬＳＩex５００で符号化処理されたデータである。

また、ストリーミングサーバex１０３は複数のサーバや複数のコンピュータであって、データを分散して処理したり記録したり配信するものであってもよい。

以上のようにして、コンテンツ供給システムex１００では、符号化されたデータをクライアントが受信して再生することができる。このようにコンテンツ供給システムex１００では、ユーザが送信した情報をリアルタイムでクライアントが受信して復号化し、再生することができ、特別な権利や設備を有さないユーザでも個人放送を実現できる。

なお、コンテンツ供給システムex１００の例に限らず、図１８に示すように、デジタル放送用システムex２００にも、上記各実施の形態の少なくとも動画像符号化装置（画像符号化装置）または動画像復号化装置（画像復号装置）のいずれかを組み込むことができる。具体的には、放送局ex２０１では映像データに音楽データなどが多重化された多重化データが電波を介して通信または衛星ex２０２に伝送される。この映像データは上記各実施の形態で説明した動画像符号化方法により符号化されたデータである（即ち、本発明の一態様に係る画像符号化装置によって符号化されたデータである）。これを受けた放送衛星ex２０２は、放送用の電波を発信し、この電波を衛星放送の受信が可能な家庭のアンテナex２０４が受信する。受信した多重化データを、テレビ（受信機）ex３００またはセットトップボックス（ＳＴＢ）ex２１７等の装置が復号化して再生する（即ち、本発明の一態様に係る画像復号装置として機能する）。

また、ＤＶＤ、ＢＤ等の記録メディアex２１５に記録した多重化データを読み取り復号化する、または記録メディアex２１５に映像信号を符号化し、さらに場合によっては音楽信号と多重化して書き込むリーダ／レコーダex２１８にも上記各実施の形態で示した動画像復号化装置または動画像符号化装置を実装することが可能である。この場合、再生された映像信号はモニタex２１９に表示され、多重化データが記録された記録メディアex２１５により他の装置やシステムにおいて映像信号を再生することができる。また、ケーブルテレビ用のケーブルex２０３または衛星／地上波放送のアンテナex２０４に接続されたセットトップボックスex２１７内に動画像復号化装置を実装し、これをテレビのモニタex２１９で表示してもよい。このときセットトップボックスではなく、テレビ内に動画像復号化装置を組み込んでもよい。

図１９は、上記各実施の形態で説明した動画像復号化方法および動画像符号化方法を用いたテレビ（受信機）ex３００を示す図である。テレビex３００は、上記放送を受信するアンテナex２０４またはケーブルex２０３等を介して映像データに音声データが多重化された多重化データを取得、または出力するチューナex３０１と、受信した多重化データを復調する、または外部に送信する多重化データに変調する変調／復調部ex３０２と、復調した多重化データを映像データと、音声データとに分離する、または信号処理部ex３０６で符号化された映像データ、音声データを多重化する多重／分離部ex３０３を備える。

また、テレビex３００は、音声データ、映像データそれぞれを復号化する、またはそれぞれの情報を符号化する音声信号処理部ex３０４、映像信号処理部ex３０５（本発明の一態様に係る画像符号化装置または画像復号装置として機能する）を有する信号処理部ex３０６と、復号化した音声信号を出力するスピーカex３０７、復号化した映像信号を表示するディスプレイ等の表示部ex３０８を有する出力部ex３０９とを有する。さらに、テレビex３００は、ユーザ操作の入力を受け付ける操作入力部ex３１２等を有するインタフェース部ex３１７を有する。さらに、テレビex３００は、各部を統括的に制御する制御部ex３１０、各部に電力を供給する電源回路部ex３１１を有する。インタフェース部ex３１７は、操作入力部ex３１２以外に、リーダ／レコーダex２１８等の外部機器と接続されるブリッジex３１３、ＳＤカード等の記録メディアex２１６を装着可能とするためのスロット部ex３１４、ハードディスク等の外部記録メディアと接続するためのドライバex３１５、電話網と接続するモデムex３１６等を有していてもよい。なお記録メディアex２１６は、格納する不揮発性／揮発性の半導体メモリ素子により電気的に情報の記録を可能としたものである。テレビex３００の各部は同期バスを介して互いに接続されている。

まず、テレビex３００がアンテナex２０４等により外部から取得した多重化データを復号化し、再生する構成について説明する。テレビex３００は、リモートコントローラex２２０等からのユーザ操作を受け、ＣＰＵ等を有する制御部ex３１０の制御に基づいて、変調／復調部ex３０２で復調した多重化データを多重／分離部ex３０３で分離する。さらにテレビex３００は、分離した音声データを音声信号処理部ex３０４で復号化し、分離した映像データを映像信号処理部ex３０５で上記各実施の形態で説明した復号化方法を用いて復号化する。復号化した音声信号、映像信号は、それぞれ出力部ex３０９から外部に向けて出力される。出力する際には、音声信号と映像信号が同期して再生するよう、バッファex３１８、ex３１９等に一旦これらの信号を蓄積するとよい。また、テレビex３００は、放送等からではなく、磁気／光ディスク、ＳＤカード等の記録メディアex２１５、ex２１６から多重化データを読み出してもよい。次に、テレビex３００が音声信号や映像信号を符号化し、外部に送信または記録メディア等に書き込む構成について説明する。テレビex３００は、リモートコントローラex２２０等からのユーザ操作を受け、制御部ex３１０の制御に基づいて、音声信号処理部ex３０４で音声信号を符号化し、映像信号処理部ex３０５で映像信号を上記各実施の形態で説明した符号化方法を用いて符号化する。符号化した音声信号、映像信号は多重／分離部ex３０３で多重化され外部に出力される。多重化する際には、音声信号と映像信号が同期するように、バッファex３２０、ex３２１等に一旦これらの信号を蓄積するとよい。なお、バッファex３１８、ex３１９、ex３２０、ex３２１は図示しているように複数備えていてもよいし、１つ以上のバッファを共有する構成であってもよい。さらに、図示している以外に、例えば変調／復調部ex３０２や多重／分離部ex３０３の間等でもシステムのオーバフロー、アンダーフローを避ける緩衝材としてバッファにデータを蓄積することとしてもよい。

また、テレビex３００は、放送等や記録メディア等から音声データ、映像データを取得する以外に、マイクやカメラのＡＶ入力を受け付ける構成を備え、それらから取得したデータに対して符号化処理を行ってもよい。なお、ここではテレビex３００は上記の符号化処理、多重化、および外部出力ができる構成として説明したが、これらの処理を行うことはできず、上記受信、復号化処理、外部出力のみが可能な構成であってもよい。

また、リーダ／レコーダex２１８で記録メディアから多重化データを読み出す、または書き込む場合には、上記復号化処理または符号化処理はテレビex３００、リーダ／レコーダex２１８のいずれで行ってもよいし、テレビex３００とリーダ／レコーダex２１８が互いに分担して行ってもよい。

一例として、光ディスクからデータの読み込みまたは書き込みをする場合の情報再生／記録部ex４００の構成を図２０に示す。情報再生／記録部ex４００は、以下に説明する要素ex４０１、ex４０２、ex４０３、ex４０４、ex４０５、ex４０６、ex４０７を備える。光ヘッドex４０１は、光ディスクである記録メディアex２１５の記録面にレーザスポットを照射して情報を書き込み、記録メディアex２１５の記録面からの反射光を検出して情報を読み込む。変調記録部ex４０２は、光ヘッドex４０１に内蔵された半導体レーザを電気的に駆動し記録データに応じてレーザ光の変調を行う。再生復調部ex４０３は、光ヘッドex４０１に内蔵されたフォトディテクタにより記録面からの反射光を電気的に検出した再生信号を増幅し、記録メディアex２１５に記録された信号成分を分離して復調し、必要な情報を再生する。バッファex４０４は、記録メディアex２１５に記録するための情報および記録メディアex２１５から再生した情報を一時的に保持する。ディスクモータex４０５は記録メディアex２１５を回転させる。サーボ制御部ex４０６は、ディスクモータex４０５の回転駆動を制御しながら光ヘッドex４０１を所定の情報トラックに移動させ、レーザスポットの追従処理を行う。システム制御部ex４０７は、情報再生／記録部ex４００全体の制御を行う。上記の読み出しや書き込みの処理はシステム制御部ex４０７が、バッファex４０４に保持された各種情報を利用し、また必要に応じて新たな情報の生成・追加を行うと共に、変調記録部ex４０２、再生復調部ex４０３、サーボ制御部ex４０６を協調動作させながら、光ヘッドex４０１を通して、情報の記録再生を行うことにより実現される。システム制御部ex４０７は例えばマイクロプロセッサで構成され、読み出し書き込みのプログラムを実行することでそれらの処理を実行する。

以上では、光ヘッドex４０１はレーザスポットを照射するとして説明したが、近接場光を用いてより高密度な記録を行う構成であってもよい。

図２１に光ディスクである記録メディアex２１５の模式図を示す。記録メディアex２１５の記録面には案内溝（グルーブ）がスパイラル状に形成され、情報トラックex２３０には、予めグルーブの形状の変化によってディスク上の絶対位置を示す番地情報が記録されている。この番地情報はデータを記録する単位である記録ブロックex２３１の位置を特定するための情報を含み、記録や再生を行う装置において情報トラックex２３０を再生し番地情報を読み取ることで記録ブロックを特定することができる。また、記録メディアex２１５は、データ記録領域ex２３３、内周領域ex２３２、外周領域ex２３４を含んでいる。ユーザデータを記録するために用いる領域がデータ記録領域ex２３３であり、データ記録領域ex２３３より内周または外周に配置されている内周領域ex２３２と外周領域ex２３４は、ユーザデータの記録以外の特定用途に用いられる。情報再生／記録部ex４００は、このような記録メディアex２１５のデータ記録領域ex２３３に対して、符号化された音声データ、映像データまたはそれらのデータを多重化した多重化データの読み書きを行う。

以上では、１層のＤＶＤ、ＢＤ等の光ディスクを例に挙げ説明したが、これらに限ったものではなく、多層構造であって表面以外にも記録可能な光ディスクであってもよい。また、ディスクの同じ場所にさまざまな異なる波長の色の光を用いて情報を記録したり、さまざまな角度から異なる情報の層を記録したりなど、多次元的な記録／再生を行う構造の光ディスクであってもよい。

また、デジタル放送用システムex２００において、アンテナex２０５を有する車ex２１０で衛星ex２０２等からデータを受信し、車ex２１０が有するカーナビゲーションex２１１等の表示装置に動画を再生することも可能である。なお、カーナビゲーションex２１１の構成は例えば図１９に示す構成のうち、ＧＰＳ受信部を加えた構成が考えられ、同様なことがコンピュータex１１１や携帯電話ex１１４等でも考えられる。

図２２Ａは、上記実施の形態で説明した動画像復号化方法および動画像符号化方法を用いた携帯電話ex１１４を示す図である。携帯電話ex１１４は、基地局ex１１０との間で電波を送受信するためのアンテナex３５０、映像、静止画を撮ることが可能なカメラ部ex３６５、カメラ部ex３６５で撮像した映像、アンテナex３５０で受信した映像等が復号化されたデータを表示する液晶ディスプレイ等の表示部ex３５８を備える。携帯電話ex１１４は、さらに、操作キー部ex３６６を有する本体部、音声を出力するためのスピーカ等である音声出力部ex３５７、音声を入力するためのマイク等である音声入力部ex３５６、撮影した映像、静止画、録音した音声、または受信した映像、静止画、メール等の符号化されたデータもしくは復号化されたデータを保存するメモリ部ex３６７、又は同様にデータを保存する記録メディアとのインタフェース部であるスロット部ex３６４を備える。

さらに、携帯電話ex１１４の構成例について、図２２Ｂを用いて説明する。携帯電話ex１１４は、表示部ex３５８及び操作キー部ex３６６を備えた本体部の各部を統括的に制御する主制御部ex３６０に対して、電源回路部ex３６１、操作入力制御部ex３６２、映像信号処理部ex３５５、カメラインタフェース部ex３６３、ＬＣＤ（Liquid Crystal Display）制御部ex３５９、変調／復調部ex３５２、多重／分離部ex３５３、音声信号処理部ex３５４、スロット部ex３６４、メモリ部ex３６７がバスex３７０を介して互いに接続されている。

電源回路部ex３６１は、ユーザの操作により終話及び電源キーがオン状態にされると、バッテリパックから各部に対して電力を供給することにより携帯電話ex１１４を動作可能な状態に起動する。

携帯電話ex１１４は、ＣＰＵ、ＲＯＭ、ＲＡＭ等を有する主制御部ex３６０の制御に基づいて、音声通話モード時に音声入力部ex３５６で収音した音声信号を音声信号処理部ex３５４でデジタル音声信号に変換し、これを変調／復調部ex３５２でスペクトラム拡散処理し、送信／受信部ex３５１でデジタルアナログ変換処理および周波数変換処理を施した後にアンテナex３５０を介して送信する。また携帯電話ex１１４は、音声通話モード時にアンテナex３５０を介して受信した受信データを増幅して周波数変換処理およびアナログデジタル変換処理を施し、変調／復調部ex３５２でスペクトラム逆拡散処理し、音声信号処理部ex３５４でアナログ音声信号に変換した後、これを音声出力部ex３５７から出力する。

さらにデータ通信モード時に電子メールを送信する場合、本体部の操作キー部ex３６６等の操作によって入力された電子メールのテキストデータは操作入力制御部ex３６２を介して主制御部ex３６０に送出される。主制御部ex３６０は、テキストデータを変調／復調部ex３５２でスペクトラム拡散処理をし、送信／受信部ex３５１でデジタルアナログ変換処理および周波数変換処理を施した後にアンテナex３５０を介して基地局ex１１０へ送信する。電子メールを受信する場合は、受信したデータに対してこのほぼ逆の処理が行われ、表示部ex３５８に出力される。

データ通信モード時に映像、静止画、または映像と音声を送信する場合、映像信号処理部ex３５５は、カメラ部ex３６５から供給された映像信号を上記各実施の形態で示した動画像符号化方法によって圧縮符号化し（即ち、本発明の一態様に係る画像符号化装置として機能する）、符号化された映像データを多重／分離部ex３５３に送出する。また、音声信号処理部ex３５４は、映像、静止画等をカメラ部ex３６５で撮像中に音声入力部ex３５６で収音した音声信号を符号化し、符号化された音声データを多重／分離部ex３５３に送出する。

多重／分離部ex３５３は、映像信号処理部ex３５５から供給された符号化された映像データと音声信号処理部ex３５４から供給された符号化された音声データを所定の方式で多重化し、その結果得られる多重化データを変調／復調部（変調／復調回路部）ex３５２でスペクトラム拡散処理をし、送信／受信部ex３５１でデジタルアナログ変換処理及び周波数変換処理を施した後にアンテナex３５０を介して送信する。

データ通信モード時にホームページ等にリンクされた動画像ファイルのデータを受信する場合、または映像およびもしくは音声が添付された電子メールを受信する場合、アンテナex３５０を介して受信された多重化データを復号化するために、多重／分離部ex３５３は、多重化データを分離することにより映像データのビットストリームと音声データのビットストリームとに分け、同期バスex３７０を介して符号化された映像データを映像信号処理部ex３５５に供給するとともに、符号化された音声データを音声信号処理部ex３５４に供給する。映像信号処理部ex３５５は、上記各実施の形態で示した動画像符号化方法に対応した動画像復号化方法によって復号化することにより映像信号を復号し（即ち、本発明の一態様に係る画像復号装置として機能する）、ＬＣＤ制御部ex３５９を介して表示部ex３５８から、例えばホームページにリンクされた動画像ファイルに含まれる映像、静止画が表示される。また音声信号処理部ex３５４は、音声信号を復号し、音声出力部ex３５７から音声が出力される。

また、上記携帯電話ex１１４等の端末は、テレビex３００と同様に、符号化器・復号化器を両方持つ送受信型端末の他に、符号化器のみの送信端末、復号化器のみの受信端末という３通りの実装形式が考えられる。さらに、デジタル放送用システムex２００において、映像データに音楽データなどが多重化された多重化データを受信、送信するとして説明したが、音声データ以外に映像に関連する文字データなどが多重化されたデータであってもよいし、多重化データではなく映像データ自体であってもよい。

このように、上記各実施の形態で示した動画像符号化方法あるいは動画像復号化方法を上述したいずれの機器・システムに用いることは可能であり、そうすることで、上記各実施の形態で説明した効果を得ることができる。

また、本発明はかかる上記実施の形態に限定されるものではなく、本発明の範囲を逸脱することなく種々の変形または修正が可能である。

（実施の形態１０）
上記各実施の形態で示した動画像符号化方法または装置と、ＭＰＥＧ−２、ＭＰＥＧ４−ＡＶＣ、ＶＣ−１など異なる規格に準拠した動画像符号化方法または装置とを、必要に応じて適宜切替えることにより、映像データを生成することも可能である。

ここで、それぞれ異なる規格に準拠する複数の映像データを生成した場合、復号する際に、それぞれの規格に対応した復号方法を選択する必要がある。しかしながら、復号する映像データが、どの規格に準拠するものであるか識別できないため、適切な復号方法を選択することができないという課題を生じる。

この課題を解決するために、映像データに音声データなどを多重化した多重化データは、映像データがどの規格に準拠するものであるかを示す識別情報を含む構成とする。上記各実施の形態で示す動画像符号化方法または装置によって生成された映像データを含む多重化データの具体的な構成を以下説明する。多重化データは、ＭＰＥＧ−２トランスポートストリーム形式のデジタルストリームである。

図２３は、多重化データの構成を示す図である。図２３に示すように多重化データは、ビデオストリーム、オーディオストリーム、プレゼンテーショングラフィックスストリーム（ＰＧ）、インタラクティブグラフィックスストリームのうち、１つ以上を多重化することで得られる。ビデオストリームは映画の主映像および副映像を、オーディオストリーム（ＩＧ）は映画の主音声部分とその主音声とミキシングする副音声を、プレゼンテーショングラフィックスストリームは、映画の字幕をそれぞれ示している。ここで主映像とは画面に表示される通常の映像を示し、副映像とは主映像の中に小さな画面で表示する映像のことである。また、インタラクティブグラフィックスストリームは、画面上にＧＵＩ部品を配置することにより作成される対話画面を示している。ビデオストリームは、上記各実施の形態で示した動画像符号化方法または装置、従来のＭＰＥＧ−２、ＭＰＥＧ４−ＡＶＣ、ＶＣ−１などの規格に準拠した動画像符号化方法または装置によって符号化されている。オーディオストリームは、ドルビーＡＣ−３、Ｄｏｌｂｙ Ｄｉｇｉｔａｌ Ｐｌｕｓ、ＭＬＰ、ＤＴＳ、ＤＴＳ−ＨＤ、または、リニアＰＣＭのなどの方式で符号化されている。

多重化データに含まれる各ストリームはＰＩＤによって識別される。例えば、映画の映像に利用するビデオストリームには０ｘ１０１１が、オーディオストリームには０ｘ１１００から０ｘ１１１Ｆまでが、プレゼンテーショングラフィックスには０ｘ１２００から０ｘ１２１Ｆまでが、インタラクティブグラフィックスストリームには０ｘ１４００から０ｘ１４１Ｆまでが、映画の副映像に利用するビデオストリームには０ｘ１Ｂ００から０ｘ１Ｂ１Ｆまで、主音声とミキシングする副音声に利用するオーディオストリームには０ｘ１Ａ００から０ｘ１Ａ１Ｆが、それぞれ割り当てられている。

図２４は、多重化データがどのように多重化されるかを模式的に示す図である。まず、複数のビデオフレームからなるビデオストリームex２３５、複数のオーディオフレームからなるオーディオストリームex２３８を、それぞれＰＥＳパケット列ex２３６およびex２３９に変換し、ＴＳパケットex２３７およびex２４０に変換する。同じくプレゼンテーショングラフィックスストリームex２４１およびインタラクティブグラフィックスex２４４のデータをそれぞれＰＥＳパケット列ex２４２およびex２４５に変換し、さらにＴＳパケットex２４３およびex２４６に変換する。多重化データex２４７はこれらのＴＳパケットを１本のストリームに多重化することで構成される。

図２５は、ＰＥＳパケット列に、ビデオストリームがどのように格納されるかをさらに詳しく示している。図２５における第１段目はビデオストリームのビデオフレーム列を示す。第２段目は、ＰＥＳパケット列を示す。図２５の矢印ｙｙ１，ｙｙ２，ｙｙ３，ｙｙ４に示すように、ビデオストリームにおける複数のＶｉｄｅｏ Ｐｒｅｓｅｎｔａｔｉｏｎ ＵｎｉｔであるＩピクチャ、Ｂピクチャ、Ｐピクチャは、ピクチャ毎に分割され、ＰＥＳパケットのペイロードに格納される。各ＰＥＳパケットはＰＥＳヘッダを持ち、ＰＥＳヘッダには、ピクチャの表示時刻であるＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ−Ｓｔａｍｐ）やピクチャの復号時刻であるＤＴＳ（Ｄｅｃｏｄｉｎｇ Ｔｉｍｅ−Ｓｔａｍｐ）が格納される。

図２６は、多重化データに最終的に書き込まれるＴＳパケットの形式を示している。ＴＳパケットは、ストリームを識別するＰＩＤなどの情報を持つ４ＢｙｔｅのＴＳヘッダとデータを格納する１８４ＢｙｔｅのＴＳペイロードから構成される１８８Ｂｙｔｅ固定長のパケットであり、上記ＰＥＳパケットは分割されＴＳペイロードに格納される。ＢＤ−ＲＯＭの場合、ＴＳパケットには、４ＢｙｔｅのＴＰ＿Ｅｘｔｒａ＿Ｈｅａｄｅｒが付与され、１９２Ｂｙｔｅのソースパケットを構成し、多重化データに書き込まれる。ＴＰ＿Ｅｘｔｒａ＿ＨｅａｄｅｒにはＡＴＳ（Ａｒｒｉｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐ）などの情報が記載される。ＡＴＳは当該ＴＳパケットのデコーダのＰＩＤフィルタへの転送開始時刻を示す。多重化データには図２６下段に示すようにソースパケットが並ぶこととなり、多重化データの先頭からインクリメントする番号はＳＰＮ（ソースパケットナンバー）と呼ばれる。

また、多重化データに含まれるＴＳパケットには、映像・音声・字幕などの各ストリーム以外にもＰＡＴ（Ｐｒｏｇｒａｍ Ａｓｓｏｃｉａｔｉｏｎ Ｔａｂｌｅ）、ＰＭＴ（Ｐｒｏｇｒａｍ Ｍａｐ Ｔａｂｌｅ）、ＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）などがある。ＰＡＴは多重化データ中に利用されるＰＭＴのＰＩＤが何であるかを示し、ＰＡＴ自身のＰＩＤは０で登録される。ＰＭＴは、多重化データ中に含まれる映像・音声・字幕などの各ストリームのＰＩＤと各ＰＩＤに対応するストリームの属性情報を持ち、また多重化データに関する各種ディスクリプタを持つ。ディスクリプタには多重化データのコピーを許可・不許可を指示するコピーコントロール情報などがある。ＰＣＲは、ＡＴＳの時間軸であるＡＴＣ（Ａｒｒｉｖａｌ Ｔｉｍｅ Ｃｌｏｃｋ）とＰＴＳ・ＤＴＳの時間軸であるＳＴＣ（Ｓｙｓｔｅｍ Ｔｉｍｅ Ｃｌｏｃｋ）の同期を取るために、そのＰＣＲパケットがデコーダに転送されるＡＴＳに対応するＳＴＣ時間の情報を持つ。

図２７はＰＭＴのデータ構造を詳しく説明する図である。ＰＭＴの先頭には、そのＰＭＴに含まれるデータの長さなどを記したＰＭＴヘッダが配置される。その後ろには、多重化データに関するディスクリプタが複数配置される。上記コピーコントロール情報などが、ディスクリプタとして記載される。ディスクリプタの後には、多重化データに含まれる各ストリームに関するストリーム情報が複数配置される。ストリーム情報は、ストリームの圧縮コーデックなどを識別するためストリームタイプ、ストリームのＰＩＤ、ストリームの属性情報（フレームレート、アスペクト比など）が記載されたストリームディスクリプタから構成される。ストリームディスクリプタは多重化データに存在するストリームの数だけ存在する。

記録媒体などに記録する場合には、上記多重化データは、多重化データ情報ファイルと共に記録される。

多重化データ情報ファイルは、図２８に示すように多重化データの管理情報であり、多重化データと１対１に対応し、多重化データ情報、ストリーム属性情報とエントリマップから構成される。

多重化データ情報は図２８に示すようにシステムレート、再生開始時刻、再生終了時刻から構成されている。システムレートは多重化データの、後述するシステムターゲットデコーダのＰＩＤフィルタへの最大転送レートを示す。多重化データ中に含まれるＡＴＳの間隔はシステムレート以下になるように設定されている。再生開始時刻は多重化データの先頭のビデオフレームのＰＴＳであり、再生終了時刻は多重化データの終端のビデオフレームのＰＴＳに１フレーム分の再生間隔を足したものが設定される。

ストリーム属性情報は図２９に示すように、多重化データに含まれる各ストリームについての属性情報が、ＰＩＤ毎に登録される。属性情報はビデオストリーム、オーディオストリーム、プレゼンテーショングラフィックスストリーム、インタラクティブグラフィックスストリーム毎に異なる情報を持つ。ビデオストリーム属性情報は、そのビデオストリームがどのような圧縮コーデックで圧縮されたか、ビデオストリームを構成する個々のピクチャデータの解像度がどれだけであるか、アスペクト比はどれだけであるか、フレームレートはどれだけであるかなどの情報を持つ。オーディオストリーム属性情報は、そのオーディオストリームがどのような圧縮コーデックで圧縮されたか、そのオーディオストリームに含まれるチャンネル数は何であるか、何の言語に対応するか、サンプリング周波数がどれだけであるかなどの情報を持つ。これらの情報は、プレーヤが再生する前のデコーダの初期化などに利用される。

本実施の形態においては、上記多重化データのうち、ＰＭＴに含まれるストリームタイプを利用する。また、記録媒体に多重化データが記録されている場合には、多重化データ情報に含まれる、ビデオストリーム属性情報を利用する。具体的には、上記各実施の形態で示した動画像符号化方法または装置において、ＰＭＴに含まれるストリームタイプ、または、ビデオストリーム属性情報に対し、上記各実施の形態で示した動画像符号化方法または装置によって生成された映像データであることを示す固有の情報を設定するステップまたは手段を設ける。この構成により、上記各実施の形態で示した動画像符号化方法または装置によって生成した映像データと、他の規格に準拠する映像データとを識別することが可能になる。

また、本実施の形態における動画像復号化方法のステップを図３０に示す。ステップexＳ１００において、多重化データからＰＭＴに含まれるストリームタイプ、または、多重化データ情報に含まれるビデオストリーム属性情報を取得する。次に、ステップexＳ１０１において、ストリームタイプ、または、ビデオストリーム属性情報が上記各実施の形態で示した動画像符号化方法または装置によって生成された多重化データであることを示しているか否かを判断する。そして、ストリームタイプ、または、ビデオストリーム属性情報が上記各実施の形態で示した動画像符号化方法または装置によって生成されたものであると判断された場合には、ステップexＳ１０２において、上記各実施の形態で示した動画像復号方法により復号を行う。また、ストリームタイプ、または、ビデオストリーム属性情報が、従来のＭＰＥＧ−２、ＭＰＥＧ４−ＡＶＣ、ＶＣ−１などの規格に準拠するものであることを示している場合には、ステップexＳ１０３において、従来の規格に準拠した動画像復号方法により復号を行う。

このように、ストリームタイプ、または、ビデオストリーム属性情報に新たな固有値を設定することにより、復号する際に、上記各実施の形態で示した動画像復号化方法または装置で復号可能であるかを判断することができる。従って、異なる規格に準拠する多重化データが入力された場合であっても、適切な復号化方法または装置を選択することができるため、エラーを生じることなく復号することが可能となる。また、本実施の形態で示した動画像符号化方法または装置、または、動画像復号方法または装置を、上述したいずれの機器・システムに用いることも可能である。

（実施の形態１１）
上記各実施の形態で示した動画像符号化方法および装置、動画像復号化方法および装置は、典型的には集積回路であるＬＳＩで実現される。一例として、図３１に１チップ化されたＬＳＩex５００の構成を示す。ＬＳＩex５００は、以下に説明する要素ex５０１、ex５０２、ex５０３、ex５０４、ex５０５、ex５０６、ex５０７、ex５０８、ex５０９を備え、各要素はバスex５１０を介して接続している。電源回路部ex５０５は電源がオン状態の場合に各部に対して電力を供給することで動作可能な状態に起動する。

例えば符号化処理を行う場合には、ＬＳＩex５００は、ＣＰＵex５０２、メモリコントローラex５０３、ストリームコントローラex５０４、駆動周波数制御部ex５１２等を有する制御部ex５０１の制御に基づいて、ＡＶ Ｉ／Ｏex５０９によりマイクex１１７やカメラex１１３等からＡＶ信号を入力する。入力されたＡＶ信号は、一旦ＳＤＲＡＭ等の外部のメモリex５１１に蓄積される。制御部ex５０１の制御に基づいて、蓄積したデータは処理量や処理速度に応じて適宜複数回に分けるなどされ信号処理部ex５０７に送られ、信号処理部ex５０７において音声信号の符号化および／または映像信号の符号化が行われる。ここで映像信号の符号化処理は上記各実施の形態で説明した符号化処理である。信号処理部ex５０７ではさらに、場合により符号化された音声データと符号化された映像データを多重化するなどの処理を行い、ストリームＩ／Ｏex５０６から外部に出力する。この出力された多重化データは、基地局ex１０７に向けて送信されたり、または記録メディアex２１５に書き込まれたりする。なお、多重化する際には同期するよう、一旦バッファex５０８にデータを蓄積するとよい。

なお、上記では、メモリex５１１がＬＳＩex５００の外部の構成として説明したが、ＬＳＩex５００の内部に含まれる構成であってもよい。バッファex５０８も１つに限ったものではなく、複数のバッファを備えていてもよい。また、ＬＳＩex５００は１チップ化されてもよいし、複数チップ化されてもよい。

また、上記では、制御部ex５０１が、ＣＰＵex５０２、メモリコントローラex５０３、ストリームコントローラex５０４、駆動周波数制御部ex５１２等を有するとしているが、制御部ex５０１の構成は、この構成に限らない。例えば、信号処理部ex５０７がさらにＣＰＵを備える構成であってもよい。信号処理部ex５０７の内部にもＣＰＵを設けることにより、処理速度をより向上させることが可能になる。また、他の例として、ＣＰＵex５０２が信号処理部ex５０７、または信号処理部ex５０７の一部である例えば音声信号処理部を備える構成であってもよい。このような場合には、制御部ex５０１は、信号処理部ex５０７、またはその一部を有するＣＰＵex５０２を備える構成となる。

なお、ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。

また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。このようなプログラマブル・ロジック・デバイスは、典型的には、ソフトウェア又はファームウェアを構成するプログラムを、ロードする又はメモリ等から読み込むことで、上記各実施の形態で示した動画像符号化方法、又は動画像復号化方法を実行することができる。

さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適応等が可能性としてありえる。

（実施の形態１２）
上記各実施の形態で示した動画像符号化方法または装置によって生成された映像データを復号する場合、従来のＭＰＥＧ−２、ＭＰＥＧ４−ＡＶＣ、ＶＣ−１などの規格に準拠する映像データを復号する場合に比べ、処理量が増加することが考えられる。そのため、ＬＳＩex５００において、従来の規格に準拠する映像データを復号する際のＣＰＵex５０２の駆動周波数よりも高い駆動周波数に設定する必要がある。しかし、駆動周波数を高くすると、消費電力が高くなるという課題が生じる。

この課題を解決するために、テレビex３００、ＬＳＩex５００などの動画像復号化装置は、映像データがどの規格に準拠するものであるかを識別し、規格に応じて駆動周波数を切替える構成とする。図３２は、本実施の形態における構成ex８００を示している。駆動周波数切替え部ex８０３は、映像データが、上記各実施の形態で示した動画像符号化方法または装置によって生成されたものである場合には、駆動周波数を高く設定する。そして、上記各実施の形態で示した動画像復号化方法を実行する復号処理部ex８０１に対し、映像データを復号するよう指示する。一方、映像データが、従来の規格に準拠する映像データである場合には、映像データが、上記各実施の形態で示した動画像符号化方法または装置によって生成されたものである場合に比べ、駆動周波数を低く設定する。そして、従来の規格に準拠する復号処理部ex８０２に対し、映像データを復号するよう指示する。

より具体的には、駆動周波数切替え部ex８０３は、図３１のＣＰＵex５０２と駆動周波数制御部ex５１２から構成される。また、上記各実施の形態で示した動画像復号化方法を実行する復号処理部ex８０１、および、従来の規格に準拠する復号処理部ex８０２は、図３１の信号処理部ex５０７に該当する。ＣＰＵex５０２は、映像データがどの規格に準拠するものであるかを識別する。そして、ＣＰＵex５０２からの信号に基づいて、駆動周波数制御部ex５１２は、駆動周波数を設定する。また、ＣＰＵex５０２からの信号に基づいて、信号処理部ex５０７は、映像データの復号を行う。ここで、映像データの識別には、例えば、実施の形態１０で記載した識別情報を利用することが考えられる。識別情報に関しては、実施の形態１０で記載したものに限られず、映像データがどの規格に準拠するか識別できる情報であればよい。例えば、映像データがテレビに利用されるものであるか、ディスクに利用されるものであるかなどを識別する外部信号に基づいて、映像データがどの規格に準拠するものであるか識別可能である場合には、このような外部信号に基づいて識別してもよい。また、ＣＰＵex５０２における駆動周波数の選択は、例えば、図３４のような映像データの規格と、駆動周波数とを対応付けたルックアップテーブルに基づいて行うことが考えられる。ルックアップテーブルを、バッファex５０８や、ＬＳＩの内部メモリに格納しておき、ＣＰＵex５０２がこのルックアップテーブルを参照することにより、駆動周波数を選択することが可能である。

図３３は、本実施の形態の方法を実施するステップを示している。まず、ステップexＳ２００では、信号処理部ex５０７において、多重化データから識別情報を取得する。次に、ステップexＳ２０１では、ＣＰＵex５０２において、識別情報に基づいて映像データが上記各実施の形態で示した符号化方法または装置によって生成されたものであるか否かを識別する。映像データが上記各実施の形態で示した符号化方法または装置によって生成されたものである場合には、ステップexＳ２０２において、駆動周波数を高く設定する信号を、ＣＰＵex５０２が駆動周波数制御部ex５１２に送る。そして、駆動周波数制御部ex５１２において、高い駆動周波数に設定される。一方、従来のＭＰＥＧ−２、ＭＰＥＧ４−ＡＶＣ、ＶＣ−１などの規格に準拠する映像データであることを示している場合には、ステップexＳ２０３において、駆動周波数を低く設定する信号を、ＣＰＵex５０２が駆動周波数制御部ex５１２に送る。そして、駆動周波数制御部ex５１２において、映像データが上記各実施の形態で示した符号化方法または装置によって生成されたものである場合に比べ、低い駆動周波数に設定される。

さらに、駆動周波数の切替えに連動して、ＬＳＩex５００またはＬＳＩex５００を含む装置に与える電圧を変更することにより、省電力効果をより高めることが可能である。例えば、駆動周波数を低く設定する場合には、これに伴い、駆動周波数を高く設定している場合に比べ、ＬＳＩex５００またはＬＳＩex５００を含む装置に与える電圧を低く設定することが考えられる。

また、駆動周波数の設定方法は、復号する際の処理量が大きい場合に、駆動周波数を高く設定し、復号する際の処理量が小さい場合に、駆動周波数を低く設定すればよく、上述した設定方法に限らない。例えば、ＭＰＥＧ４−ＡＶＣ規格に準拠する映像データを復号する処理量の方が、上記各実施の形態で示した動画像符号化方法または装置により生成された映像データを復号する処理量よりも大きい場合には、駆動周波数の設定を上述した場合の逆にすることが考えられる。

さらに、駆動周波数の設定方法は、駆動周波数を低くする構成に限らない。例えば、識別情報が、上記各実施の形態で示した動画像符号化方法または装置によって生成された映像データであることを示している場合には、ＬＳＩex５００またはＬＳＩex５００を含む装置に与える電圧を高く設定し、従来のＭＰＥＧ−２、ＭＰＥＧ４−ＡＶＣ、ＶＣ−１などの規格に準拠する映像データであることを示している場合には、ＬＳＩex５００またはＬＳＩex５００を含む装置に与える電圧を低く設定することも考えられる。また、他の例としては、識別情報が、上記各実施の形態で示した動画像符号化方法または装置によって生成された映像データであることを示している場合には、ＣＰＵex５０２の駆動を停止させることなく、従来のＭＰＥＧ−２、ＭＰＥＧ４−ＡＶＣ、ＶＣ−１などの規格に準拠する映像データであることを示している場合には、処理に余裕があるため、ＣＰＵex５０２の駆動を一時停止させることも考えられる。識別情報が、上記各実施の形態で示した動画像符号化方法または装置によって生成された映像データであることを示している場合であっても、処理に余裕があれば、ＣＰＵex５０２の駆動を一時停止させることも考えられる。この場合は、従来のＭＰＥＧ−２、ＭＰＥＧ４−ＡＶＣ、ＶＣ−１などの規格に準拠する映像データであることを示している場合に比べて、停止時間を短く設定することが考えられる。

このように、映像データが準拠する規格に応じて、駆動周波数を切替えることにより、省電力化を図ることが可能になる。また、電池を用いてＬＳＩex５００またはＬＳＩex５００を含む装置を駆動している場合には、省電力化に伴い、電池の寿命を長くすることが可能である。

（実施の形態１３）
テレビや、携帯電話など、上述した機器・システムには、異なる規格に準拠する複数の映像データが入力される場合がある。このように、異なる規格に準拠する複数の映像データが入力された場合にも復号できるようにするために、ＬＳＩex５００の信号処理部ex５０７が複数の規格に対応している必要がある。しかし、それぞれの規格に対応する信号処理部ex５０７を個別に用いると、ＬＳＩex５００の回路規模が大きくなり、また、コストが増加するという課題が生じる。

この課題を解決するために、上記各実施の形態で示した動画像復号方法を実行するための復号処理部と、従来のＭＰＥＧ−２、ＭＰＥＧ４−ＡＶＣ、ＶＣ−１などの規格に準拠する復号処理部とを一部共有化する構成とする。この構成例を図３５Ａのex９００に示す。例えば、上記各実施の形態で示した動画像復号方法と、ＭＰＥＧ４−ＡＶＣ規格に準拠する動画像復号方法とは、エントロピー符号化、逆量子化、デブロッキングフィルタ、動き補償などの処理において処理内容が一部共通する。共通する処理内容については、ＭＰＥＧ４−ＡＶＣ規格に対応する復号処理部ex９０２を共有し、ＭＰＥＧ４−ＡＶＣ規格に対応しない、本発明の一態様に特有の他の処理内容については、専用の復号処理部ex９０１を用いるという構成が考えられる。復号処理部の共有化に関しては、共通する処理内容については、上記各実施の形態で示した動画像復号化方法を実行するための復号処理部を共有し、ＭＰＥＧ４−ＡＶＣ規格に特有の処理内容については、専用の復号処理部を用いる構成であってもよい。

また、処理を一部共有化する他の例を図３５Ｂのex１０００に示す。この例では、本発明の一態様に特有の処理内容に対応した専用の復号処理部ex１００１と、他の従来規格に特有の処理内容に対応した専用の復号処理部ex１００２と、本発明の一態様に係る動画像復号方法と他の従来規格の動画像復号方法とに共通する処理内容に対応した共用の復号処理部ex１００３とを用いる構成としている。ここで、専用の復号処理部ex１００１、ex１００２は、必ずしも本発明の一態様、または、他の従来規格に特有の処理内容に特化したものではなく、他の汎用処理を実行できるものであってもよい。また、本実施の形態の構成を、ＬＳＩex５００で実装することも可能である。

このように、本発明の一態様に係る動画像復号方法と、従来の規格の動画像復号方法とで共通する処理内容について、復号処理部を共有することにより、ＬＳＩの回路規模を小さくし、かつ、コストを低減することが可能である。

本発明に係る画像符号化方法および画像復号方法は、あらゆるマルチメディアデータに適用することができる。本発明に係る画像符号化方法および画像復号方法は、例えば、携帯電話、ＤＶＤ装置、およびパーソナルコンピュータ等を用いた蓄積、伝送、通信等における画像符号化方法および画像復号方法として有用である。

１００ エンコーダ
１０５ 減算器
１１０ 変換部
１２０ 量子化部
１３０、２３０ 逆変換部
１４０、２４０ 加算器
１５０、２５０ デブロッキングフィルタ
１６０、２６０ 適応ループフィルタ
１７０、２７０ フレームメモリ
１８０、２８０ 予測部
１９０ エントロピー符号化部
２００ デコーダ
２９０ エントロピー復号部
３００、４００、７１０ ピクチャ
３１、３２、３ｉ、４１、４２ ＬＣＵ行
３１１、３１２、３ｉ１、３２１ ＬＣＵ
５００ パケットヘッダ
５１０ ＩＰヘッダ
５２０、５５０ 拡張フィールド
５３０ ＵＤＰヘッダ
５４０ ＲＴＰヘッダ
５６０ ペイロードヘッダ
５７０ ＮＡＬヘッダ
ｓ１ 入力信号
ｓ２ 予測信号
ｅ、ｅ’ 予測誤差信号
ｓ’、ｓ”、ｓ３ 再構築信号

Claims (6)

1. ピクチャを複数のスライスに分割して符号化処理を実行する画像符号化方法であって、
   処理対象のスライス以外の他のスライスに対する前記符号化処理の結果に依存して前記符号化処理が行われる依存スライスが前記ピクチャに含まれるか否かを示す依存スライス有効化フラグと、前記処理対象のスライスの開始位置を示すスライスアドレスと、前記処理対象のスライスが前記依存スライスであるか否かを示す依存性インジケーションとを含むビットストリームを送信するステップを含み、
   前記依存スライス有効化フラグは、前記複数のスライスに共通のパラメータセット内に配置され、
   前記スライスアドレスは、前記処理対象のスライスのスライスヘッダ内に配置され、
   前記依存性インジケーションは、前記スライスヘッダ内であって、前記スライスアドレスの前、かつ、前記パラメータセットを識別するシンタックスエレメントの後に配置されている
   画像符号化方法。
2. 前記依存性インジケーションは、前記依存スライス有効化フラグが前記依存スライスを含むことを示す場合に、前記ビットストリームに含まれる
   請求項１に記載の画像符号化方法。
3. 前記依存スライス有効化フラグは、前記パラメータセットの先頭に配置されている
   請求項１または２に記載の画像符号化方法。
4. 前記複数のスライスのそれぞれは、複数のマクロブロックを含み、
   １つ前の処理対象のスライスに含まれる複数のマクロブロックのうち、２つのマクロブロックに対する前記符号化処理の実行後に、前記処理対象のスライスに対する前記符号化処理の実行が開始される
   請求項１〜３の何れか１項に記載の画像符号化方法。
5. 前記依存性インジケーションは、前記複数のスライスのうち、前記ピクチャの最初に処理されるスライスのスライスヘッダには含まれない
   請求項１〜４の何れか１項に記載の画像符号化方法。
6. ピクチャを複数のスライスに分割して符号化処理を実行する画像符号化装置であって、
   処理対象のスライス以外の他のスライスに対する前記符号化処理の結果に依存して前記符号化処理が行われる依存スライスが前記ピクチャに含まれるか否かを示す依存スライス有効化フラグと、前記処理対象のスライスの開始位置を示すスライスアドレスと、前記処理対象のスライスが前記依存スライスであるか否かを示す依存性インジケーションとを含むビットストリームを送信する符号化部を含み、
   前記依存スライス有効化フラグは、前記複数のスライスに共通のパラメータセット内に配置され、
   前記スライスアドレスは、前記処理対象のスライスのスライスヘッダ内に配置され、
   前記依存性インジケーションは、前記スライスヘッダ内であって、前記スライスアドレスの前、かつ、前記パラメータセットを識別するシンタックスエレメントの後に配置されている
   画像符号化装置。

Images