(本発明の基礎となった知見)
本発明者は、「背景技術」の欄において記載した、画像符号化方法及び画像復号方法に関し、以下の問題が生じることを見出した。
まず、HEVCにおける画像符号化装置及び画像復号装置について説明する。
画像符号化装置へ入力される映像信号は、各々がフレーム(ピクチャ)と呼ばれる複数の画像を含む。各フレームは二次元行列状に配置された複数の画素を含む。ハイブリッド映像符号化に基づく上述の全ての標準規格では、個々の映像フレームは、各々が複数の画素を含む複数のブロックに分割される。このブロックのサイズは、例えば、画像の内容によって変更される。また、ブロックごとに異なる符号化方法を用いることができる。例えば、HEVCにおいて、このブロックの最大サイズは64×64画素である。この最大サイズは、最大符号化単位(LCU)と称される。LCUは、帰納的に、4つの符号化単位(CU)に分割することができる。
H.264/MPEG−4 AVCにおいては、マクロブロック(通常16×16画素のブロック)単位で符号化が行われる。このマクロブロックはサブブロックに分割される場合もある。符号化方法に含まれる符号化ステップおよび/または復号方法に含まれる復号ステップは、サブブロック単位で実行される。
[1−1.ハイブリッド映像符号化]
以下、ハイブリッド符号化について、簡単に説明する。
典型的には、ハイブリッド映像符号化における符号化ステップには、空間的予測(空間予測)及び/または時間的予測(時間予測)が含まれる。つまり、空間的に隣接したブロックまたは時間的に隣接したブロックを用いて、即ち、符号化済み映像フレームを用いて、各符号化対象ブロックが予測される。次に、符号化対象ブロックと、予測結果との差分である残差ブロックが算出される。次に、残差ブロックは、空間(画素)ドメインから周波数ドメインへ変換される。この変換の目的は、入力ブロックの相関性を低下させることである。
次に、変換により得られた変換係数が量子化される。この量子化は不可逆圧縮である。また、得られた量子化係数は、エントロピー符号化によって可逆圧縮される。また、符号化映像信号を再構築するために必要な補助情報が符号化され、符号化映像信号とともに出力される。この情報は、例えば、空間的予測、時間的予測、または/及び量子化に関する情報である。
[1−2.画像符号化装置の構成]
図1は、H.264/MPEG−4 AVC及び/またはHEVCに準拠した画像符号化装置(エンコーダ100)の一例を示す図である。
図1に示すように、エンコーダ100は、減算器105と、変換部110と、量子化部120と、逆変換部130と、加算器140と、デブロッキングフィルタ150と、適応ループフィルタ160と、フレームメモリ170と、予測部180と、エントロピー符号化部190とを備えている。
予測部180は、時間的予測または空間的予測により、予測信号s2を導出する。予測部180において用いられる予測のタイプは、フレーム毎またはブロック毎に異なっていてもよい。時間的予測は、インター予測と称され、空間的予測は、イントラ予測と称される。また、時間的予測による予測信号s2を用いた符号化はインター符号化と称され、空間的予測による予測信号s2を用いた符号化はイントラ符号化と称される。時間的予測を用いた予測信号の導出では、メモリに格納されている符号化済みの画像が用いられる。空間的予測を用いた予測信号の導出では、メモリに格納された符号化または復号済みの隣接ブロックの境界画素値が用いられる。イントラ予測における予測方向の数は、符号化単位(CU、Coding Unit)のサイズによって決まる。なお、予測の詳細については後述する。
減算器105は、入力画像の符号化対象ブロック(=入力信号s1)と対応する予測ブロック(=予測信号s2)との差分(=予測誤差信号e)を導出する。当該差分は、符号化対象ブロックの予測に用いられる。なお、予測誤差信号eは、予測残差信号とも呼ばれる。
変換部110は、予測誤差信号eを係数に変換する。一般的に、変換部110では、2次元離散コサイン変換(DCT)またはその整数版等の直交変換が用いられる。直交変換により、入力信号s1(符号化前の映像信号)の相関を効率的に削減することが可能になる。また、一般に高周波成分よりも低周波成分が画質にとってより重要なので、高周波成分よりも低周波成分により多くのビットが使用される。
量子化部120は、係数を量子化して量子化係数を導出する。
エントロピー符号化部190は、量子化係数に対してエントロピー符号化を行う。エントロピー符号化により、量子化係数は可逆的に圧縮される。さらに、エントロピー符号化を行うことにより、メモリに格納するデータのデータ量および送信されるデータ(ビットストリーム)のデータ量をさらに削減することができる。エントロピー符号化は、主に、可変長の符号語を用いた符号化処理を適用することによって達成される。この符号語の長さは、発生確率に基づいて選択される。
エントロピー符号化部190は、2次元配列の量子化係数を1次元配列に変換する。エントロピー符号化部190は、典型的には、いわゆるジグザグスキャンによって変換を行う。ジグザグスキャンにおいては、2次元配列の左上隅にあるDC係数から右下隅にあるAC係数まで、所定の順序で2次元配列が走査される。通常、2次元配列の量子化係数において、エネルギーは、左上部分に集中する。一般的に、より左上側に位置する係数ほど、低周波数成分の係数であり、より右下に位置する係数ほど、高周波数成分の係数である。このため、ジグザク走査を行うと、最後に1または複数のゼロが連続する1次元配列になる。これにより、実際のエントロピー符号化の一部として、またはその前処理として、ランレングス符号を用いる効率的な符号化が可能になる。
H.264/MPEG−4 AVC及びHEVCでは、複数種類のエントロピー符号化が用いられる。シンタックス要素の中には固定長で符号化されるものもあるが、ほとんどのシンタックス要素が可変長符号化される。特に、シンタックスのうち、予測誤差信号(予測残差信号)の符号化には、コンテキスト適応可変長符号(CABAC)が用いられる。他のシンタックス要素の符号化には、一般的に、コンテキスト適応可変長符号とは別の様々な整数符号が用いられるが、コンテキスト適応算術符号化を用いてもよい。
可変長符号により、符号化済みビットストリームを可逆的に圧縮することができる。しかしながら、符号語は可変長であるため、符号語を連続して復号しなければならない。つまり、エントロピー符号化をリスタート(初期化)することなく、または、最初に復号する符号語(開始点)の位置を個別に示すことなく、先行の符号語を符号化または復号する前に、符号語を符号化または復号することはできない。
所定の確率モデルに基づく算術符号化によりビット列が1つの符号語に符号化される。所定の確率モデルは、CABACの場合の映像シーケンスの内容に応じて決定される。よって、符号化対象のビットストリームの長さが長いほど、算術符号化及びCABACはより効率的に行われる。つまり、ビット列に適用されるCABACは、より大きなブロックにおいてより効率的であるといえる。各シーケンスの先頭でCABACがリスタートされる。つまり、各映像シーケンスの先頭で確率モデルが既定値または所定値で初期化される。
エントロピー符号化部190は、符号化された量子化係数(符号化された映像信号)と符号化された補助情報とを含むビットストリームを、デコーダ側に送信する。
H.264/MPEG−4、H.264/MPEG−4 AVC、および、HEVCは、ビデオ符号化層(VCL)とネットワーク抽象化層(NAL)の2つの機能層を有する。上述したように、VCLは、符号化機能を提供する。NALは、チャネルを用いた送信あるいは記憶装置への格納等の用途に応じて、NALユニットと称される標準単位で情報(情報要素)をカプセル化する。NALによりカプセル化される情報要素には、例えば、(1)符号化された予測誤差信号(圧縮映像データ)、および、(2)予測タイプ、量子化パラメータおよび動きベクトル等の映像信号の復号に必要な補助情報(関連情報)が含まれる。補助情報には、映像シーケンス全体に関連するパラメータセットなどの追加データがカプセル化されたnon−VCLユニット、および、復号効率の改善に用いることが可能な追加情報を提供する付加拡張情報(SEI)が含まれる。
non−VCLユニットには、例えば、パラメータセットが含まれる。パラメータセットとは、一定の映像シーケンスの符号化および復号に関する複数のパラメータのセットのことである。パラメータセットには、例えば、ピクチャシーケンス全体の符号化および復号に関連するパラメータを含むシーケンスパラメータセット(SPS)がある。特に、シーケンスパラメータセットは、シンタックス要素を含むシンタックス構造を有する。シンタックス要素は、seq_parameter_set_idの内容により決定されるゼロ以上の符号化映像シーケンス全体に適用される。seq_parameter_set_idは、pic_parameter_set_idにより参照される(以下で説明する)ピクチャパラメータセットに含まれるシンタックス要素である。pic_parameter_set_idは、各スライスヘッダに含まれるシンタックス要素である。
ピクチャパラメータセット(PPS)は、ピクチャシーケンス(映像シーケンス)のピクチャの符号化および復号に適用されるパラメータを定義したパラメータセットである。特に、PPSは、シンタックス要素を含むシンタックス構造を有する。シンタックス要素は、各スライスヘッダに含まれるシンタックス要素であるpic_parameter_set_idにより決定されるゼロ以上の符号化ピクチャ全体に適用される。
よって、PPSよりもSPSの追跡を続ける方が容易である。なぜなら、PPSが各ピクチャに対して変化するのに対して、SPSは、数分あるいは数時間にも及ぶ可能性のある映像シーケンス全体に対して一定であるからである。
エンコーダ100には、再構築信号(いわゆる復号信号)s3を導出するために、再構築部(いわゆる復号部)が組み入れられている。再構築部により、符号化済みの画像を再構築(復号)した再構築画像が生成され、フレームメモリ170に記憶される。
再構築部は、逆変換部130と、加算器140と、デブロッキングフィルタ150と、適応ループフィルタ160とを含む。
逆変換部130は、上述した符号化ステップに従い、逆量子化および逆変換を実行する。なお、逆変換部130により導出された予測誤差信号e’は、量子化ノイズとも称される量子化誤差が原因で、予測誤差信号eとは異なる。
加算器140は、逆変換部130により再構築された予測誤差信号e’を、予測信号s2に加えることで、再構築信号s’を導出する。
デブロッキングフィルタ150は、量子化に起因して再構築信号s’に重畳された量子化ノイズを削減するデブロッキングフィルタ処理を実行する。ここで、上述した符号化ステップは、ブロック単位で行われるため、ノイズが重畳されることにより、ブロック境界が目立つ場合がある(ノイズのブロッキング特性)。重畳されたノイズは、ブロッキングノイズと呼ばれる。特に、量子化部120において強い量子化が行われた場合は、再構築画像(復号画像)のブロック境界がより顕著に目立つことになる。このようなブロッキングノイズは、人間の視覚認識において、画質が劣化しているように見える。このブロッキングノイズを削減するため、デブロッキングフィルタ150は、再構築信号s’(再構築ブロック)に対してデブロッキングフィルタ処理を実行する。
例えば、H.264/MPEG−4 AVCにおけるデブロッキングフィルタ処理では、領域ごとに、当該領域に適したフィルタ処理が選択される。例えば、ブロッキングノイズが大きい場合は、強い(狭帯域)ローパスフィルタが用いられ、ブロッキングノイズが小さい場合は、弱い(広帯域)ローパスフィルタが用いられる。このローパスフィルタの強度は、予測信号s2および予測誤差信号e’に応じて決定される。このデブロッキングフィルタ処理により、ブロックのエッジが平滑化される。これにより、復号画像信号の主観的画質が改善する。また、フィルタ処理済みの画像が次の画像の動き補償予測に用いられる。よって、このフィルタ処理により予測誤差も削減されるので、符号化効率を改善することができる。
適応ループフィルタ160は、デブロッキングフィルタ150においてデブロッキングフィルタ処理された後の再構築信号s”に対し、サンプル適応オフセット(Sample adaptive offset、SAO)処理および/または適応ループフィルタ(Adaptive Loop Filter、ALF)処理を適用することで、再構築信号(復号信号)s3を導出する。
ここで、デブロッキングフィルタ150におけるデブロッキングフィルタ処理は、主観的品質の改善を目的とする。一方で、適応ループフィルタ160におけるALF処理およびSAO処理は、画素単位の信頼性(客観的品質)の改善を目的とする。SAO処理は、近接画素の画素値を用いて、各画素の画素値にオフセット値を追加する処理である。ALF処理は、圧縮によって生じる画像の歪みを補償するために用いられる処理である。通常、ALF処理で用いられるフィルタは、再構築信号s’と入力信号s1との平均二乗誤差(MSE)が最小化されるように決定したフィルタ係数を有するウィーナフィルタである。ALF処理のフィルタ係数は、例えば、フレーム単位で算出および送信される。ALF処理は、フレーム全体(画像)に適用されてもよいし、局所領域(ブロック)に適用されてもよい。また、フィルタリングを行う領域を示す補助情報が、ブロック単位、フレーム単位、または四分木単位で送信されてもよい。
フレームメモリ(フレームバッファ)170は、符号化され再構築(復号)された再構築画像(再構築信号s3)の一部を格納する。格納された再構築画像は、インター符号化されたブロックを復号するために用いられる。
予測部180では、エンコーダ側とデコーダ側の互換性を保つため、エンコーダ側およびデコーダ側の両方で利用可能な(同一の)信号を用いて予測信号s2を導出する。エンコーダ側およびデコーダ側の両方で利用可能な信号は、エンコーダ側では、符号化され再構築(復号)された再構築信号s3(適応ループフィルタ160によるフィルタ処理後の映像信号)であり、デコーダ側では、ビットストリームから復号された復号信号s4(図2の適応ループフィルタ260によるフィルタ処理後の映像信号)である。
予測部180は、インター符号化により予測信号s2を生成する場合、動き補償予測による予測を行う。予測部180の動き推定器(図示せず)は、以前に符号化され再構築された映像フレームに含まれるブロックから、符号化対象ブロックに最も適合する最適ブロックを見つける。この最適ブロックは予測信号となる。また、符号化対象ブロックと最適ブロック間の相対的なずれ(動き)は、3次元の動きベクトルの形で補助情報に含まれる動きデータとして信号により伝達される。当該信号は、符号化映像データとともに、送信される。3次元の動きベクトルは、空間の2次元の動きベクトルと、時間の1次元の動きベクトルとを含む。予測精度を最適化するため、1/2画素解像度あるいは1/4画素解像度等の空間的サブピクセル解像度で動きベクトルを求めてもよい。空間的サブピクセル解像度の動きベクトルは、実存する画素値がない、再構築フレーム内の空間的位置、つまりサブピクセルの位置を示してもよい。よって、動き補償予測を行うために、そのような画素値の空間的補間が必要である。これは、補間フィルタ(図1において予測部180に統合されている)により達成してもよい。
[1−3.画像復号装置の構成]
デコーダ(画像復号装置)の構成について、図2を基に説明する。
図2は、H.264/MPEG−4 AVCまたはHEVC映像符号化規格に準拠したデコーダ200の一例を示すブロック図である。
図2に示すように、デコーダ200は、エントロピー復号部290と、逆変換部230と、加算器240と、デブロッキングフィルタ250と、適応ループフィルタ260と、フレームメモリ270と、予測部280とを備えている。
デコーダ200に入力されたビットストリーム(符号化された映像信号)は、まず、エントロピー復号部290に送られる。
エントロピー復号部290は、ビットストリームから符号化された量子化係数と、符号化された補助情報とを抽出し、符号化された量子化係数と符号化された補助情報とを復号する。補助情報は、上述したように、動きデータ(動きベクトル)および予測モード(予測タイプ)等の復号に必要な情報である。
エントロピー復号部290は、復号された量子化係数を、逆走査により、一次元配列から2次元配列に変換する。エントロピー復号部290は、2次元配列に変換した後の量子化係数を、逆変換部230に入力する。
逆変換部230は、2次元配列に変換された量子化係数に対し、逆量子化および逆変換を実行して、予測誤差信号e’を導出する。予測誤差信号e’は、量子化ノイズがなく、誤差が生じなかった場合にエンコーダに入力された信号から予測信号を減算して求めた差分に相当する。
予測部280は、時間的予測または空間的予測によって予測信号s2を導出する。イントラ予測(空間的予測)の場合には、補助情報に含まれる予測タイプ等の情報を利用する。また、動き補償予測(インター予測、時間的予測)の場合には、補助情報に含まれる動きデータ等の情報を利用する。
加算器240は、逆変換部230から取得した予測誤差信号e’と予測部280から取得した予測信号s2とを加算して、再構築信号s’を導出する。
デブロッキングフィルタ250は、再構築信号s’に対し、デブロッキングフィルタ処理を適用する。適応ループフィルタ260は、デブロッキングフィルタ250によりデブロッキングフィルタ処理を適用された再構築信号s”に対し、SAO処理およびALF処理を適用する。適応ループフィルタ260においてSAO処理およびALF処理が適用された結果得られる復号信号S4は、フレームメモリ270に格納される。フレームメモリ270に格納された復号信号S4は、予測部280において、次の復号対象ブロックあるいは復号対象画像の予測に使用される。
[1−4.処理効率]
符号化処理および復号処理において処理効率を向上させる方法として、一般的に、処理の並列化が考えられる。
H.264/MPEG−4 AVCと比較すると、HEVCは、符号化処理および復号処理の高度な並列処理(並列化処理)を補助する機能を有する。H.264/MPEG−4 AVCと同様に、HEVCでは、フレームを複数のスライスに分割することができる。ここで、各スライスは、走査順で連続する複数のLCUを含む。H.264/MPEG−4 AVCにおいて、スライスはそれぞれ、個々に復号可能であり、スライスを跨いだ空間的予測は行われない。よって、スライス単位で、並列処理が可能である。
しかしながら、スライスはかなり大きなヘッダを有しており、また、スライス間で依存性がないため、圧縮の効率が低下する。また、CABAC符号化は、小さなデータブロックに行われる場合に効率性が損なわれる。
これに対して、より効率的な並列処理を可能にするため、波面並列処理(WPP)が提案されている。WPPでは、上述した並列処理のようにスライス単位で完全に独立させるのではなく、一定の依存性を持たせている。
以下の説明では、ピクチャが行列状に配置された複数のLCUで構成され、各LCU行が1つのスライスを構成する場合を例に説明する(図3参照)。WPPでは、処理対象のLCU行32を構成するLCUのうち、1番目のLCU(先頭のLCU)のCABAC状態をリセットするためのCABAC確率モデルとして、前LCU行31の2番目のLCUに対する処理が終了した直後におけるCABAC確率モデルを利用する。これにより、ブロック間の依存性が維持される。また、複数のLCU行の復号処理の並列化が可能になる。但し、各LCU行の処理の開始タイミングは、前LCU行に対して、LCU2つ分遅延する。スライスのヘッダには、LCU行の復号を開始するための開始点の情報が含まれる。WPPの詳細については、非特許文献1に記載されている。
並列化改善のための別の手法としてタイルを用いる方法がある。フレーム(ピクチャ)は、複数のタイルに分割される。各タイルは、長方形であり、複数のLCUを含む。タイル間の境界は、行列状にピクチャを分割するように設定される。また、複数のタイルは、ラスタスキャン順に処理される。
また、各タイルの境界において全ての依存性が失われる。CABACなどのエントロピー符号化も、各タイルの先頭でリセットされる。なお、デブロッキングフィルタ処理とサンプル適応オフセット処理のみが、タイル間の境界を跨いで適用される。よって、複数のタイルを並列に符号化または復号できる。なお、タイルの詳細については、非特許文献2及び非特許文献3に記載されている。
また、スライスの概念を、H.264/MPEG−4 AVCにおけるスライスの本来の目的であった誤り耐性よりも、並列化に適した概念にするため、依存スライス及びエントロピースライスの概念が提案されている。
つまり、HEVCでは、(1)通常スライス、(2)エントロピースライス、および、(3)依存スライスの3つのスライスが用いられる。
(1)通常スライスは、H.264/MPEG−4 AVCにより既に知られているスライスのことである。通常スライス間では空間的予測はできない。つまり、スライス間の境界を跨いだ予測はできない。言い換えると、別のスライスを参照することなく、通常スライスは符号化される。このようなスライスの復号を別々に行えるように、CABACは各スライスの先頭でリスタートされる。
処理対象のスライスが通常スライスの場合、CABACのリスタートには、先行スライス終端での算術符号化処理または算術復号処理の終端処理(ターミネート処理)と、当該通常スライスの先頭において、コンテキストテーブル(確率テーブル)をデフォルト値に初期化する処理とが含まれる。
また、フレームの先頭には、通常スライスが用いられる。つまり、各フレームは通常スライスから開始しなければならない。通常スライスは、スライスデータの復号に必要なパラメータを含むヘッダを有する。
(2)エントロピースライスは、親スライスとエントロピースライスとの間で空間的予測が可能なスライスのことである。親スライス及びエントロピースライスの解析は、独立して行われる。
なお、親スライスは、例えば、エントロピースライスの直前の通常スライスである。親スライスは、エントロピースライスの画素値の再構築に必要とされる。また、エントロピースライスが独立解析できるよう、スライスの先頭でCABACもリスタートされる。エントロピースライスのスライスヘッダには、通常スライスのスライスヘッダより短いスライスヘッダを用いることができる。エントロピースライスのスライスヘッダには、通常スライスのスライスヘッダに含まれる情報に関する符号化パラメータサブセットが含まれる。エントロピースライスのスライスヘッダにおける欠落要素は、親スライスのスライスヘッダからコピーされる。
処理対象のスライスがエントロピースライスの場合、CABACのリスタートには、通常スライスと同様に、先行スライス終端での終端処理(ターミネート処理)と、現行スライス先頭においてコンテキストテーブルをデフォルト値に初期化する処理とが含まれる。
(3)依存スライスは、エントロピースライスと類似しているが、CABACのリスタートの一部処理で異なっている。
処理対象のスライスが依存スライスかつWPPが有効ではない場合、CABACのリスタートには、先行スライス終端での終端処理(ターミネート処理)と、現行スライスの先頭において、先行スライスの終端の状態値にコンテキストテーブルを初期化する処理とが含まれる。処理対象のスライスが依存スライスかつWPPが有効である場合、CABACのリスタートには、先行スライス終端での終端処理(ターミネート処理)と、現行スライスの先頭において、先行スライスに属し左端から2つめのLCU処理後の状態値にコンテキストテーブルを初期化する処理とが含まれる。
上述したように、CABACのリスタートには、常に、ターミネート処理が含まれる。これに対し、CABACのリスタートにおいて、CABACの状態は、引き継がれる場合がある。
依存スライスは、親スライスなしに解析することはできない。このため、親スライスを取得していない場合、依存スライスを復号することができない。親スライスは通常、符号化順において依存スライスの先行スライスであり、完全なスライスヘッダを含むスライスである。このことは、エントロピースライスの親スライスでも同じである。
以上のように、依存スライス及びエントロピースライスは、スライスの符号化順における直前のスライスのスライスヘッダ(依存スライスのヘッダに含まれていない情報)を用いる。このルールは帰納的に適用される。対象依存スライスが依存する親スライスが参照可能であると認識される。参照には、スライス間の空間的予測及び共通CABAC状態などの利用が含まれる。依存スライスは、直前のスライスの終端で生成されるCABACコンテキストテーブルを用いる。このように、依存スライスは、CABACのコンテキストテーブルをデフォルト値に初期化せず、作成済みのコンテキストテーブルを継続して利用する。また、エントロピースライスおよび依存スライスに関しては、非特許文献3に記載されている。
HEVCは、いくつかのプロファイルを提示する。プロファイルは、特定のアプリケーションに適する画像符号化装置及び画像復号装置の設定を含む。例えば、「主要プロファイル」は、通常スライス及び依存スライスのみを含み、エントロピースライスを含まない。
上述したように、符号化スライスは、NALユニットにカプセル化され、さらに、例えばリアルタイムプロトコル(RTP)にカプセル化され、最終的にインターネットプロトコル(IP)パケットにカプセル化される。このプロトコルスタックまたは別のプロトコルスタックにより、インターネットまたは固有ネットワークなどのパケット指向型ネットワークにおいて、符号化映像の送信が可能になる。
典型的に、ネットワークは少なくとも1つ以上のルータを含み、ルータは超高速で動作する専用ハードウェアで構成される。ルータは、IPパケットを受信してIPパケットのヘッダを解析し、適宜IPパケットをそれぞれの宛先に転送する機能を有する。ルータは、多くのソースからの通信を処理する必要があるので、ロジックを制御するパケットはなるべくシンプルでなければならない。ルータは、少なくとも、IPパケットを転送する経路を決定するため、IPヘッダに含まれる宛先アドレスフィールドを確認する必要がある。サービス品質(QoS)に対するサポートをさらに提供するため、スマート(メディア・アウェア)ルータは、IPヘッダ、RTPヘッダ、及びNALUヘッダなどのネットワーク・プロトコルヘッダにおける専用フィールドを追加的に確認する。
映像符号化に関する上記の記載から分かるように、依存スライス及びエントロピースライスなど、並列処理のために定義された異なるタイプのスライスは、データが欠落した場合の画質の低下に対する重要性が異なる。親スライスなしに、依存スライスを解析及び復号することはできない。なぜなら、依存スライスの先頭で、エントロピー符号化部またはエントロピー復号部をリスタートすることができないからである。よって、画像または映像を再構築するうえで、親スライスはより重要であるといえる。
HEVCにおいて、依存スライス及びエントロピースライスは、依存性の補足的な側面として、スライス間の依存性(フレーム内の依存性)を取り入れている。この種の依存性は、ルータによって考慮されることはない。
つまり、上述した依存性、特に、インター符号化におけるスライス間の依存性は、ネットワークレベルでは考慮されない。しかしながら、サービス品質に対するより良いサポートを提供するためには、ネットワークレベルにおいて、上述した依存性を考慮することが望ましい。各スライスの依存性を考慮し、ネットワークレベルにおけるパケットの取り扱いの柔軟性を改善することが求められている。
(課題の詳細)
[1−5.WPPおよび依存スライス]
依存スライスは、WPPまたはタイルなどの並列処理ツールとともに用いることができる。また、依存スライスを用いることで、符号化損失を引き起こすことなく伝送遅延を削減することが可能なウェイブフロント(サブストリーム)を生成することができる。
また、依存スライスではCABACがリスタートされないため、依存スライスをCABACサブストリームの開始点として用いることができる。また、独立した解析の開始点を示すため、当該開始点を示す情報をビットストリームに含めて伝達してもよい。特に、2つ以上のCABACサブストリームを通常スライスまたは依存スライスにカプセル化する場合、サブストリーム毎のバイト数を用いて明示的に開始点を信号伝達する。ここで、サブストリームは、開始点により別々に解析可能なストリームの一部分を示す。さらに、各依存スライスはNALユニットのヘッダを必要とするため、開始点の「マーカー」として依存スライスを用いることができる。つまり、そのようなマーカーに対する開始点を信号伝達できる。
信号により明示的に開始点を通知する方法と、依存スライスを介して開始点をマーキングする方法とは同時に用いることができる。
ここで、各NALユニットの開始点(各NALヘッダの先頭)が特定できる必要がある。なお、特定方法に関しては、任意の方法を用いることができる。例えば、以下の2つの方法を用いることができる。
一つ目の方法は、各NALヘッダの先頭に、例えば、3バイトのスタートコードを挿入する方法である。二つ目の方法は、各NALユニットを別々のパケットにパケット化する方法である。また、スライスの依存性のため、スライスヘッダのサイズを縮小してもよい。
これらの方法により、エントロピースライスに対して並列CABAC解析が可能になる。これは、エントロピースライスの先頭でCABACが必ずリスタートされるからである。CABACの並列処理では、連続する画素構築処理の後の並列CABAC解析により障害を克服できる。具体的には、WPP並列化ツールにより、各LCU行の復号処理を1つのコア(IPコア(intellectual property core)、機能ブロック)により実現できる。なお、各コアへのLCU行の割り当ては異なってよい。例えば、1つのコアに2行が割り当てられてもよいし、2つのコアに1行が割り当てられてもよい。
図3は、ピクチャ300の構成の一例を示す図である。図3において、ピクチャ300は、複数のLCU行31〜3m(mはLCUの行数)に分割されている。各LCU行3i(i=1〜m)は、一行に配置された複数のLCU3i1〜3in(nはLCUの列数)で構成されている。LCU行3iは、「ウェイブフロントi」に対応している。ウェイブフロント同士は、並列処理が可能である。図3の「CABAC状態」の矢印は、CABAC状態を参照するLCUとその参照先との関係を示している。
具体的には、図3では、先ず、LCU行31に含まれるLCUのうち、先頭のLCU311に対する処理(符号化または復号)が開始される。LCUに対する処理は、LCU311〜31nの順に実行される。LCU行31において最初の2つのLCU311,312が処理された後、LCU行32の処理が開始される。LCU行32の最初のLCU321の処理では、図3の「CABAC状態」の矢印に示されるように、1行目のLCU行31におけるLCU312に対する処理が終了した直後のCABAC状態が、CABAC状態の初期状態として用いられる。つまり、2つの並列処理の間では、LCU2つ分の処理時間に相当する遅延が存在する。
図4は、WPPを用いた依存スライスの使用例を示す図である。LCU行41〜43は、「ウェイブフロント1」、「ウェイブフロント2」、および、「ウェイブフロント3」に対応している。LCU行41〜43は、それぞれ独立したコアで処理される。図4において、LCU行41は通常スライスであり、LCU行42〜4mは依存スライスである。
依存スライスは、遅延を改善できるWPPを形成する。依存スライスには完全なスライスヘッダがない。また、開始点(または、上述したようなルールで知られる、依存スライスの開始点)が分かっていれば、他のスライスとは独立して依存スライスを復号できる。また、依存スライスは、符号化損失を生ずることなく、低遅延アプリケーションにも適したWPPを形成できる。
サブストリーム(LCU行)をスライスにカプセル化する通常のケースでは、確実に、エントロピー符号化及び復号を並列に行うためには明確な開始点をスライスヘッダに挿入する必要がある。そのため、スライスの最後のサブストリームが完全に符号化されてはじめて、スライスの伝送の準備ができる。また、スライス中の全てのサブストリームの符号化が完了してはじめてスライスヘッダは完成する。つまり、スライス全体の処理が終わるまで、RTP/IP層のパケットフラグメンテーションを介してスライスの先頭の伝送を開始できない。
しかしながら、依存スライスが用いられる場合には、依存スライスを開始点マーカーとして利用できるため、開始点の明示的な信号による通知は必要ない。したがって、符号化損失なく通常スライスを多くの依存スライスに分割することができる。また、カプセル化されたサブストリームの符号化が完了するとすぐに(または、パケットフラグメンテーションの場合は、それよりも早く)、依存スライスを伝送することができる。
また、依存スライスは、空間的予測の依存性を弱めない。さらに、依存スライスは解析依存性も弱めない。なぜなら、対象依存スライスの解析には通常、先行スライスのCABAC状態を必要とするからである。
依存スライスが許可されない場合、各LCU行をスライスとすることができる。そのような構成は伝送遅延を改善するが、同時に、上述したように大きな符号化損失が生ずることになる。
フレーム(ピクチャ)全体を1つのスライスにカプセル化する場合を想定する。この場合、並列解析を可能にするため、スライスヘッダにサブストリーム(LCU行)の開始点を信号により伝達する必要がある。これによりフレームレベルで伝送遅延が発生する。つまり、フレーム全体を符号化した後、ヘッダを修正する必要がある。ピクチャ全体を1つのスライスにカプセル化すること自体は、伝送遅延を悪化させない。例えば、符号化が完全に終わる前に、スライスの一部の伝送を開始してもよい。しかしながら、WPPを用いる場合、開始点を記すためにスライスヘッダを後で修正する必要がある。したがって、スライス全体の伝送を遅延させる必要がある。
このように、依存スライスの使用により、遅延を削減することができる。図4に示されるように、ピクチャ400は、通常スライスであるLCU行41、依存スライスであるLCU行42〜4mに分割される。各LCU行が1つの依存スライスである場合、符号化損失なく、1つのLCU行の伝送を遅延させることができる。これは、依存スライスが、空間依存を弱めず、かつCABACエンジンをリスタートしないからである。
[1−6.パケットの構成]
上述したように、ネットワークルータは、サービス品質の提供を可能にするために、パケットのヘッダを分析しなければならない。サービス品質は、アプリケーションの種類、および/または、サービスの優先度、および/または、パケットロスに起因する歪みに対するパケットの関連性の優先度によって異なる。
図5は、ビットストリームのカプセル化(パケット化)の一例を示す図である。
ここで、一般的に、パケット化にはリアルタイムプロトコル(RTP)が用いられる。RTPは、通常、リアルタイムのメディア送信に用いられる。また、パケット化で用いられる各プロトコルのヘッダの長さは、基本的に固定されている。各プロトコルのヘッダは、拡張フィールドを有する。この拡張フィールドにより、ヘッダの長さを4バイト拡張できる。例えば、IPヘッダは、20バイトまで拡張できる。またIPヘッダ、ユーザデータグラムプロトコル(UDP)ヘッダ、および、RTPヘッダに含まれるシンタックスエレメントの長さは、固定されている。
図5は、IPパケットに含まれるパケットヘッダ500を示す。図5に示すパケットヘッダ500には、IPヘッダ510、UDPヘッダ530、RTPヘッダ540、RTP H264ペイロードヘッダ560、および、NALヘッダ570が含まれる。IPヘッダ510は、4バイトの拡張フィールド520を有する20バイト長のヘッダである。IPパケットのペイロードは、UDPパケットである。UDPパケットは、8バイト長のUDPヘッダ530と、UDPペイロードとを含む。UDPペイロードはRTPパケットによって形成されている。RTPパケットは、先頭の12バイト長のRTPヘッダ540と、4バイトの拡張フィールド550とを有する。RTPパケットは、拡張フィールドにより、選択的に拡張できる。RTPパケットのペイロードは、0〜3バイト長の特別なRTP H264ペイロードヘッダ560とそれに続く2バイト長のHEVCのNALヘッダ570とを含む。符号化された映像パケットを含むNALUのペイロードは(図5には図示せず)、パケットヘッダ500の後に続く。
改良されたサービス品質を提供できるルータは、メディアアウェアネットワークエレメント(Media Aware Network Elements、MANE)と呼ばれる。メディアアウェアネットワークエレメントは、図5に示されるパケットヘッダ500を構成するフィールドのうちのいくつかを解析する。MANEは、例えば、受信パケットコンテンツのロスおよび提示順序を検出するために、“temporal_id”と呼ばれ、NALヘッダ570に含まれるシンタックスエレメント、または、RTPヘッダ540に含まれる復号順序番号を解析することができる。ルータ(ネットワーク要素)は、ネットワークのスループットをより高くするために、パケットをできる限り速く処理する。このようなルータの論理回路は、ネットワークエレメント処理の複雑性を低く抑えるために、パケットヘッダ内のフィールドに素早くシンプルにアクセスする必要がある。 NALUはパケットヘッダ500内にカプセル化されている。NALUは、スライスヘッダが存在する場合、スライスデータを含んでいてもよい。
NALUはパケットヘッダ500内にカプセル化されている。NALUは、スライスヘッダが存在する場合、スライスデータを含んでいてもよい。
図6は、スライスヘッダのシンタックス600の一例を示す図である。dependent_slice_flag601は、スライスが依存スライスであるか否かを示すシンタックスエレメントである。このシンタックスエレメントは、スライス間の依存性を識別するために用いることができる。しかしながら、スライスヘッダは、NALUのコンテンツである。dependent_slice_flag601の前にシンタックスエレメントを解析するためには、かなり複雑な論理回路が必要とされる。これは、下記に示されるように、通常のルータでは効率的に考慮できないレベルである。
上述したように、NALUは、パラメータセットのように、複数のスライスに共通の情報を含む、あるいは、スライスヘッダに含まれる復号に必要な情報を有する符号化されたスライスを直接含む。図6には、エントロピースライスまたは依存スライスに用いられるスライスヘッダのシンタックスの一例が示されている。図6は、スライスヘッダ構造を示すテーブルである。シンタックスエレメント“dependent_slice_flag”が1に設定される場合は、復号順序において対象スライスに先行する最初の通常スライス(エントロピースライスでも依存スライスでもないスライス)までの全てのスライスが必要になる。これらのスライスが復号されていない場合、一般的に、対象依存スライスは復号できない。但し、特別な場合、例えば、信号伝達または導出された他の補助情報を利用することが可能な場合には、依存スライスを復号できる場合がある。シンタックスエレメントdependent_slice_flag601は、スライスヘッダの中央の適切な位置に含まれている。さらに、スライスヘッダは、情報エレメントnum_entry_point_offsets602によって示される対象スライス内のCABACサブストリームの数と、シンタックスエレメントentry_point_offset[i]603によって示されるサブストリームのバイト数とを含む。ここで、情報エレメントnum_entry_point_offsets602は、エントリーポイントの数に対応する。iは、整数であり、特定のエントリーポイント(エントリーポイントのオフセット)を示すインデックスである。entry_point_offset[i]603により示されるサブストリームのバイト数によって、ビットストリーム内でのナビゲーションが簡単になる。
[1−7.ピクチャの依存性]
上述したように、HEVCによる符号化では、複数種類の依存性が用いられる。
図7は、依存スライスでもエントロピースライスでもない通常スライスのみが用いられる場合の依存性(依存度)とその信号伝達を示す図である。図7では、3つのピクチャ710、720、および730を示している。
ピクチャ710は、VCL NAL Unit1およびVCL NAL Unit2の2つのVCL NALUに保持されるベースレイヤピクチャである。POCは、ピクチャを描画する順序を示す。VCL NALUには、それぞれ、ピクチャがベースレイヤに属するか、エンハンスメントレイヤに属するかを示すシンタックスエレメントと、シンタックスエレメントtemporal_idが含まれる。あるピクチャがベースレイヤに属するか、エンハンスメントレイヤに属するかを示すシンタックスエレメントは、図5に示すパケットヘッダ500のNALヘッダ570内に含まれた状態で送信される。また、シンタックスエレメントtemporal_idについても、NALヘッダ570内に含まれた状態で送信される。シンタックスエレメントtemporal_idは、他のピクチャの依存性を示す。例えば、temporal_id=0の符号化されたピクチャまたはスライスは、より高いtemporal_idを有する他のピクチャまたはスライスとは独立して復号可能である。HEVCにおいて、temporal_idは、NALヘッダに含めてnuh_temporal_id_plus1として信号送信される(図9A参照)。なお、これらの例で用いられたtemporal_idと、シンタックスエレメントnuh_temporal_id_plus1との間には、次の式1の関係が成り立つ。
temporal_id=1のスライスは、temporal_idの値がより低いスライスに依存する。つまり、この場合のtemporal_idの値は0である。なお、temporal_idは、ピクチャの予測構造を指す。一般的に、例えば、temporal_idが特定の値を有するスライスは、temporal_idの値がより低いスライスまたはtemporal_idの値が同じスライスにのみ依存する。
したがって、図7におけるピクチャ710は、最初に復号することができる。
ピクチャ720は、ピクチャ710のベースレイヤに対するエンハンスメントレイヤである。よって、ピクチャ720をピクチャ710の復号後に復号する必要があるという依存性がある。ピクチャ720は、VCL NAL Unit3およびVCL NAL Unit4の2つのNALUを有する。ピクチャ710および720は共に、POCの値が0である。これは、ピクチャ710、720が、一度に表示される同じ画像に属することを示す。当該画像は、ベースレイヤとエンハンスメントレイヤとを備えている。
ピクチャ730は、VCL NAL Unit5およびVCL NAL Unit6の2つのNALUを含むベースレイヤである。ピクチャ730のPOCの値は1である。これは、ピクチャ(部分)730が、ピクチャ720および710の後に表示されるピクチャであることを意味する。さらに、ピクチャ730は、temporal_idの値が1である。これは、ピクチャ730が、temporal_id=0のピクチャに一時的に依存することを意味する。よって、NALヘッダ内に含まれて信号送信された依存性に基づき、ピクチャ730はピクチャ710に依存する。
図8は、依存スライスとエントロピースライスとが用いられる場合の依存性(依存度)とその信号伝達を示す図である。図8では、3つのピクチャ810、820、および830を示している。図8は、スライスヘッダ内に含まれて信号送信された依存スライスおよびエントロピースライスの依存性が追加されている点で、上記図7とは異なる。
ここで、図7では、ピクチャ710および720の例を用いてレイヤ間の依存性を示している。さらに、ピクチャ710および730の例を用いて時間的依存性を示している。これらの依存性は共に、NALヘッダ内に含まれて信号送信される。
これに対し、図8に示されるスライス間の依存性は、依存スライスおよびエントロピースライスに固有のものである。特に、ベースレイヤのフレーム810およびエンハンスメントレイヤのフレーム820は共に2つのスライスを有する。2つのスライスのうちの1つは親スライス(通常スライス)であり、もう1つは(依存スライス)である。フレーム810において、VCL NAL Unit1のスライスは、VCL NAL Unit2の親スライスである。フレーム820において、VCL NAL Unit3のスライスは、VCL NAL Unit4の親スライスである。上述したように、依存スライスの「親スライス」とは、当該依存スライスの依存先スライス、つまり、そのスライスヘッダ情報が当該依存スライスによって使用されるスライスを指す。これは、最初のスライスは、完全なヘッダを有する先行スライスであるというルールに従っている。完全なヘッダを有するスライスとは、例えば、他の依存スライスではなく、通常スライスである。
現在のHEVC、特にHM8.0において採用されているNALユニットヘッダおよびスライスヘッダに対応するシンタックスについて、図9Aを用いて説明する。
図9Aは、NALユニットヘッダ910のシンタックスおよびスライスヘッダ920のシンタックスを示す図である。なお、レイヤ間の依存性は、シンタックスエレメントnuh_reserved_zero_6bitsを用い、NALユニットヘッダ内に含ませて信号送信されることが(最新の標準化において)計画されている。時間的依存性は、シンタックスエレメントnuh_temporal_id_plus1を用いて信号送信される。スライスヘッダ920は、スライス間の依存性のインジケータを示す信号を含む。スライス間の依存性のインジケータは、シンタックスエレメントdependent_slice_flagによって示される。つまり、スライス間の依存性(例えば、時間的依存性)は、スライスヘッダ内のどこかの位置に含まれて信号送信される。
このシンタックスエレメントを解析するためには、dependent_slice_flagに先行する全てのシンタックスエレメントが、dependent_slice_flagに先行するスライスヘッダのシンタックスエレメントの解析に必要なパラメータセットのシンタックスエレメントと同様に、解析されなければならない。
[1−8.ルータにおける処理]
上述したように、トラフィック形成の決定において、NALヘッダ内に含まれて信号送信される依存性に加え、依存スライスおよびエントロピースライスによって導入される依存性を考慮することが望ましい。例えば、メディアアウェアモバイル基地局としてルータを用いることができる。下り回線の帯域は非常に限られており、ごく注意深く管理する必要がある。以下の例を想定する。パケットがアップストリームにおいて通常のルータによってランダムに削除される場合を想定する。この場合において、メディアアウェアネットワークエレメント(MAME)は、パケット番号を確認することによって、パケットロスを確認することができる。パケットロスの確認後、削除されたパケットに依存する後続の全パケットを削除する。これは、メディアアウェアネットワークエレメントに望ましい特徴である。このようにすれば、パケットをよりインテリジェントに削除することができる。ルータは、NALユニットの削除を決定すると、後続の依存スライスも削除する必要があると直ちに推定する。図9Aにおいて導入された対象シンタックスにおいて、dependent_slice_flagへのアクセスには、かなりの量の情報解析が必要とされる。これは、ルータにおけるパケットルーティングまたはトラフィック形成処理のいずれにも必須ではない。レイヤ間および時間間の関係を得るために必要な全ての情報は、映像パラメータセットの中にある。映像パラメータセットは、パラメータセット階層において最も高い階層のパラメータセットである。
よって、上述した情報は、NALヘッダ570内に含まれて信号送信される。しかしながら、図9Aに示すNALヘッダおよびスライスヘッダの場合、スライスの依存性を示す情報にアクセスするには、PPSおよびSPSといった追加的パラメータセットの経過を追跡記録する必要がある。一方、これは、メディアアウェアゲートウェイまたはルータの能力を再利用することになる。図9Aから分かるように、スライスヘッダ920は、dependent_slice_flagまで解析されなければならず、解析されたパラメータはネットワーク動作には役に立たない。
dependent_slice_flagに先行するスライスアドレスを解析できるようにするためには、図9Bに示されるSPS930に含まれるシンタックスエレメントのうち、次のシンタックスエレメントが必要である。図9Bは、SPSに含まれるシンタックスの例を示す図である。
・pic_width_in_luma_samples(図9Bの符号931)
・pic_height_in_luma_samples(図9Bの符号932)
・log2_min_coding_block_size_minus3(図9Bの符号933)
・log2_diff_max_min_coding_block_size(図9Bの符号934)
これらのパラメータは、図9Bの右のテーブルに示されており、slice_addressのパラメータの取得に必要である。シンタックスエレメントslice_adressは、可変長符号化されている(図9Aのslice_address、スライスヘッダ920の第2欄(右欄)、記述子“v”の長さを参照)。可変長符号化されたslice_addressのパラメータの長さを知るために、SPSに含まれるこれらのシンタックスエレメントが必要である。しかし、dependent_slice_flagを解析するためには、シンタックスエレメントslice_addressの実際の値は必要ない。解析処理を続けるためには、可変長のシンタックスエレメントの長さが分かれば良い。
したがって、図9Bに示すSPS930に含まれるシンタックスエレメントのうち、ポイント935のシンタックスエレメントまで解析される必要がある。4つのシンタックスエレメントを格納する必要がある。それらは後で、シンタックスエレメントslice_addressの長さを計算する公式に用いられる。
さらに、dependent_slice_flagに先行するdependent_slice_enabled_flagにアクセスするために、図9Cに示されるPPSに含まれるシンタックスエレメントのうち、ポイント945のシンタックスエレメントまで解析される必要がある。図9Cは、PPSに含まれるシンタックスの例を示す図である。なお、図9A〜9Cを参照して解析方法を説明したスライスヘッダ、SPSおよびPPS内のシンタックスエレメントは、通常のルータの動作には必要ない。さらに、シンタックスエレメントのいくつかは可変長符号で符号化されているため、単純にスキップすることはできない。つまり、ビットストリーム内で所定量分のビットをジャンプしても、dependent_slice_enabled_flagまでジャンプすることはできない。
要するに、dependent_slice_flag(依存性インジケーション)を読み出すためには、MANEは、スライスヘッダ(スライスヘッダ920参照)の複雑な解析をさらに進める必要がある。
具体的には、first_slice_in_pic_flagが解析されなければならない。first_slice_in_pic_flagは、スライスがピクチャ内の最初のスライスであるか否かを示すフラグである。
その後、NALUタイプに条件付けられたno_output_of_prior_pics_flagが解析されなければならない。
さらに、可変長符号化されたpic_parameter_set_idが復号されなければならない。pic_parameter_set_idは、複数のパラメータセットのうち、どのパラメータセットを用いるかを示すシンタックスエレメント(パラメータセットを識別するシンタックスエレメント)である。pic_parameter_set_idを解析することで、利用するパラメータセットを特定できる。
最後に、slice_addressが必要である。slice_addressは、スライスの開始位置を示すシンタックスエレメントである。このシンタックスエレメントは、追加的計算とPPSおよびSPSの解析とをさらに必要とする。
最後に、dependent_slice_flagがビットストリーム内に存在するか否かを知るために、dependent_slice_enabled_flag(依存スライス有効化フラグ)の値がPPSから取得されなければならない。dependent_slice_enabled_flag=0は、依存スライスは有効でないため、対象スライスが通常スライスであることを意味する。dependent_slice_enabled_flagの値を取得するために、PPSは真ん中ぐらいまで解析される必要がある。
残念ながら、データ位置が予め定められているRTPヘッダおよびNALヘッダのデータの場合とは異なり、dependent_slice_flagの前に位置するシンタックスエレメントはスキップすることができず、解析される必要がある。これは、スライスヘッダ内のシンタックスエレメントが可変長符号化されているためである。このため、全てのVCL NALユニットについてエレメントの存在および長さが計算される必要がある。加えて、後で必要になるため(PPSおよびSPS参照)、追加的セッションデータが格納される必要がある。さらに、シンタックスエレメントの存在が、他のパラメータ構造に含まれることが想定される他のシンタックスエレメントの存在またはその値に依存するシンタックスエレメントもある(そのシンタックスエレメントは条件付きで符号化される)。
現在の標準化において、ビットストリーム内にいくつの層が含まれるかを記述するビデオパラメータセット(VPS)内のビデオシーケンス依存性構成、および様々なレイヤ間の依存性を示す依存性インジケータを信号送信するという提案がある。VPSは、最初のSPSの前に、映像の先頭に含まれて信号送信される。複数のSPSが1つのVPSを参照することができる。これは、1つのVPSが複数のビデオシーケンスに有効な情報を保持していることを意味する。VPSの主な目的は、以下のような情報を含む映像コンテンツを、ルータまたはデコーダに通知することである。いくつのビデオシーケンスが含まれ、それらがどのように相互に関係しているか。SPSは、ビデオシーケンス内でのみ有効であり、VPSは、複数のビデオシーケンスに関連する情報を保持する。
さらに、VPSに保持される情報の特徴は、特にルータにとって有益である。例えば、VPSは、設計がファイナライズされていないため、ストリーミングセッションの設定に必要な情報を保持してもよい。ルータはVPS内の情報を解析する。さらに、ルータは、他のパラメータセットを必要とせずに(NALヘッダを見るだけで)、どのデータパケットをデコーダに送信し、どのパケットを削除するかを決定できる。
しかしながら、現在有効なVPSを発見するために、次の順序で以下のステップを実行する必要がある。
スライスヘッダ内のPPS_idを解析するステップ、
PPS_idによって決定された有効PPS内のSPS_idを解析するステップ、
SPS_idによって決定された有効SPS内のVPS_idを解析するステップ。
上述した問題を解決するために、本発明の一態様に係る画像符号化方法は、ピクチャを複数のスライスに分割して符号化処理を実行する画像符号化方法であって、処理対象のスライス以外の他のスライスに対する前記符号化処理の結果に依存して前記符号化処理が行われる依存スライスが前記ピクチャに含まれるか否かを示す依存スライス有効化フラグ(dependent_slice_enabled_flag)と、前記処理対象のスライスの開始位置を示すスライスアドレスと、前記処理対象のスライスが前記依存スライスであるか否かを示す依存性インジケーション(dependent_slice_flag)とを含むビットストリームを送信するステップを含み、前記依存スライス有効化フラグは、前記複数のスライスに共通のパラメータセット内に配置され、前記スライスアドレスは、前記処理対象のスライスのスライスヘッダ内に配置され、前記依存性インジケーションは、前記スライスヘッダ内であって、前記スライスアドレスの前、かつ、前記パラメータセットを識別するシンタックスエレメント(pic_parameter_set_id)の後に配置されている。
上記構成の画像符号化方法では、スライス間の依存性に関する依存性インジケーションが、ルータによる解析に適した位置に配置されている。これにより、依存性インジケーションを他のシンタックスエレメントとは独立させて、つまり無条件に、符号化することが可能になる。
例えば、前記依存性インジケーションは、前記依存スライス有効化フラグが前記依存スライスを含むことを示す場合に、前記ビットストリームに含まれてもよい。
例えば、前記依存スライス有効化フラグは、前記パラメータセットの先頭に配置されていてもよい。
例えば、前記複数のスライスのそれぞれは、複数のマクロブロックを含み、1つ前の処理対象のスライスに含まれる複数のマクロブロックのうち、2つのマクロブロックに対する前記符号化処理の実行後に、前記処理対象のスライスに対する前記符号化処理の実行が開始されていてもよい。
例えば、前記依存性インジケーションは、前記複数のスライスのうち、前記ピクチャの最初に処理されるスライスのスライスヘッダには含まれなくてもよい。
このような問題を解決するために、本発明の一態様に係る画像復号方法は、ピクチャを複数のスライスに分割して復号処理を実行する画像復号方法であって、処理対象のスライス以外の他のスライスに対する前記復号処理の結果に依存して前記復号処理が行われる依存スライスが前記ピクチャに含まれるか否かを示す依存スライス有効化フラグと、前記処理対象のスライスの開始位置を示すスライスアドレスと、前記処理対象のスライスが前記依存スライスであるか否かを示す依存性インジケーションとを、符号化されたビットストリームから抽出するステップを含み、前記依存スライス有効化フラグは、前記複数のスライスに共通のパラメータセット内に配置され、前記スライスアドレスは、前記処理対象のスライスのスライスヘッダ内に配置され、前記依存性インジケーションは、前記スライスヘッダ内であって、前記スライスアドレスの前、かつ、前記パラメータセットを識別するシンタックスエレメントの後に配置されている。
例えば、前記依存性インジケーションは、前記依存スライス有効化フラグが前記依存スライスを含むことを示す場合に、前記ビットストリームから抽出してもよい。
例えば、前記依存スライス有効化フラグは、前記パラメータセットの先頭に配置されていてもよい。
例えば、前記複数のスライスのそれぞれは、複数のマクロブロックを含み、1つ前の処理対象のスライスに含まれる複数のマクロブロックのうち、2つのマクロブロックに対する前記復号処理の実行後に、前記処理対象のスライスに対する前記復号処理の実行を開始してもよい。
例えば、前記依存性インジケーションは、前記複数のスライスのうち、前記ピクチャの最初に処理されるスライスのスライスヘッダには含まれなくてもよい。
このような問題を解決するために、本発明の一態様に係る画像符号化装置は、ピクチャを複数のスライスに分割して符号化処理を実行する画像符号化装置であって、処理対象のスライス以外の他のスライスに対する前記符号化処理の結果に依存して前記符号化処理が行われる依存スライスが前記ピクチャに含まれるか否かを示す依存スライス有効化フラグと、前記処理対象のスライスの開始位置を示すスライスアドレスと、前記処理対象のスライスが前記依存スライスであるか否かを示す依存性インジケーションとを含むビットストリームを送信する符号化部を含み、前記依存スライス有効化フラグは、前記複数のスライスに共通のパラメータセット内に配置され、前記スライスアドレスは、前記処理対象のスライスのスライスヘッダ内に配置され、前記依存性インジケーションは、前記スライスヘッダ内であって、前記スライスアドレスの前、かつ、前記パラメータセットを識別するシンタックスエレメントの後に配置されている。
このような問題を解決するために、本発明の一態様に係る画像復号装置は、ピクチャを複数のスライスに分割して復号処理を実行する画像復号装置であって、処理対象のスライス以外の他のスライスに対する前記復号処理の結果に依存して前記復号処理が行われる依存スライスが前記ピクチャに含まれるか否かを示す依存スライス有効化フラグと、前記処理対象のスライスの開始位置を示すスライスアドレスと、前記処理対象のスライスが前記依存スライスであるか否かを示す依存性インジケーションとを、符号化されたビットストリームから抽出する復号部を含み、前記依存スライス有効化フラグは、前記複数のスライスに共通のパラメータセット内に配置され、前記スライスアドレスは、前記処理対象のスライスのスライスヘッダ内に配置され、前記依存性インジケーションは、前記スライスヘッダ内であって、前記スライスアドレスの前、かつ、前記パラメータセットを識別するシンタックスエレメントの後に配置されている。
このような問題を解決するために、本発明の一態様に係る画像符号化復号装置は、上述した画像符号化装置と、上述した画像復号装置とを備える。
上記構成の画像符号化方法および画像復号方法等によると、スライス間の依存性インジケーションは、スライスに関連するビットストリームのシンタックス内に独立して配置される。依存性インジケーションは、他のエレメントを不必要に解析することなく、ストリームから解析できる位置に、他のエレメントとは分離して配置される。上記HEVCの例では、スライス間の依存性を示すインジケータdependent_slice_flagが、ネットワーク動作に関係しないシンタックスエレメントの解析が不要になる位置で信号により伝達される。
具体的には、少なくとも部分的に可変長符号を用いて符号化された画像における映像シーケンスのビットストリームを解析し、映像シーケンスの符号化されたスライスを運ぶデータユニットを含む装置を提供する。この装置は、スライスの可変長復号または解析が他のスライスに依存するか否かを示すシンタックスエレメントである依存性インジケーションを、ビットストリームから抽出するパーサを備え、依存性インジケーションは、他のシンタックスエレメントを前もって抽出する必要なく、他のシンタックスエレメントから独立して、ビットストリームから抽出される。
そのような装置は、例えば、図2のエントロピーデコーダ290内に含まれてもよい。ビットストリームからの抽出の指示は、抽出と、その抽出に必要な場合は、エントロピー復号を含む。エントロピー符号化は、可変長符号化、例えばCABACのような算術符号化である。これはHEVCにおいて画像データの符号化に適用されている。ここで、データユニットとは、例えばNALユニットまたはアクセスユニットのことである。「他のシンタックスエレメントを抽出する必要なく」とは、依存性インジケーションに先行する複数のエレメントのいずれもが、存在しかつ長さが分かっているエレメント、または、すでに解析済みの状態にあるエレメント、または、条件付きで全く符号化されないエレメントである状況を指す。
さらに、少なくとも部分的に可変長符号で符号化されたビデオシーケンスのビットストリームを生成し、ビデオ画像の符号化スライスを保持するデータユニットを含む装置を提供する。この装置は、スライスの可変長復号が他のスライスに依存するか否かを示すシンタックスエレメントである依存性インジケータを、前記ビットストリームに埋め込むビットストリームジェネレータを備え、前記依存性インジケータは、他のシンタックスエレメントを前もって埋め込む必要なく、前記他のシンタックスエレメントから独立して、前記ビットストリームに埋め込まれる。
そのような装置は、例えば、図1のエントロピー符号化部190内に含まれてもよい。
上記構成の画像符号化方法および画像復号方法等によれば、ビットストリームは符号化されたスライスデータおよびそのスライスに関するヘッダデータを含み、依存性インジケータは、ビットストリーム内のスライスヘッダの先頭に位置する。これは、スライスヘッダがスライスの依存性を示すシンタックスエレメントで始まることを意味する。
なお、依存性インジケーションは、スライスヘッダの先頭に位置する必要はない。しかしながら、スライスヘッダ内に、他の条件付きで符号化されたシンタックスエレメント、および/または、可変長符号化されたシンタックスエレメントが、依存性インジケータに先行するシンタックスエレメントに含まれていない場合には有益である。
例えば、上述の先行技術におけるdependent_slice_flagの現在位置を、スライスヘッダの先頭に位置するように変更してもよい。この変更により、解析される必要があるシンタックスエレメントの量が削減される。さらに、可変長復号や、追加の計算および/または後で使うための追加のパラメータの格納および/または他のパラメータセットの解析が必要な情報の解析といった、ルータの複雑な解析処理を避けることができる。さらに、追跡記録が必要なパラメータセットの数が削減される。
以下、実施の形態について、図面を参照しながら具体的に説明する。なお、以下で説明する実施の形態は、いずれも包括的または具体的な例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。
(実施の形態1)
図10は、本実施の形態におけるビットストリームのシンタックスの例を示す図である。図10に示すNALヘッダ1010は、図9Aに示すNALヘッダ910と同じである。つまり、変更されていない。
しかしながら、スライスヘッダ1020のシンタックス構造は、図9Aのスライスヘッダ920のシンタックス構造とは異なる。スライスヘッダ1020では、特に、dependent_slice_flagが、dependent_slice_flagに先行するシンタックスエレメントがないように、スライスヘッダ内で上方に移動されている。dependent_slice_flagは、条件付きで符号化され、あるいは、可変長符号により符号化され、あるいは、追加の計算を要する解析が行われる。
シンタックスエレメントfirst_slice_in_pic_flagおよびdependent_slice_flagは共に、実質的に、空間的依存性を決定する。それらのシンタックスエレメントは、他のシンタックスエレメントの解析が不要になるように、NALヘッダの直後に符号化される。first_slice_in_pic_flagはまた、スライス間依存性に関連する情報を保持するため、dependent_slice_flagに先行してもよい。シンタックスエレメントfirst_slice_in_pic_flagは、全てのフレームは通常スライスで始めなければならないというルールに起因して設定されたフラグである。つまり、first_slice_in_pic_flagフラグが設定される場合は、スライスが通常スライスであり、独立していることを意味する。従って、dependent_slice_flagおよびfirst_slice_in_pic_flagの両方で、スライス間の依存性のインジケータと見なすことができる。
言い換えると、依存性インジケータは、スライスがピクチャの最初のスライスであるか否かを示す第1スライスインジケーション、および、スライスの可変長復号が他のスライスに依存するか否かを示す依存スライスフラグを含むと定義できる。ピクチャの最初のスライスは、常に、可変長復号において他のスライスに依存しないスライスである。
有利なことに、ビットストリームには、当該ビットストリームが依存スライスを含んでいる可能性があるか否かを示す依存スライス有効化フラグが含まれている。依存スライス有効化フラグがビットストリームに依存スライスが含まれている可能性があることを示す場合にのみ、依存性インジケーションがビットストリームに含まれる。依存スライス有効化フラグは、ビットストリームにおいて、複数のスライスに共通するパラメータセット内、かつ、当該パラメータセットの先頭に位置する。パラメータセットは、例えば、単一のピクチャに用いられる複数のパラメータを保持するピクチャパラメータセットであってもよい。または、依存スライス有効化フラグは、画像(映像)シーケンス全体に用いられる複数のパラメータを保持するシーケンスパラメータセット内に位置してもよい。
しかしながら、本実施の形態では、dependent_slice_flag(依存性インジケーション)が、シンタックスエレメントdependent_slice_enabled_flag(依存スライス有効化フラグ)を必要条件とせずに符号化される。本実施の形態では、ピクチャパラメータセットidが依存性インジケーションの後に配置されるので、スライスヘッダ内でピクチャパラメータセットidが信号により伝達される場合に起こりうる解析エラーを避けるのに有利である。
この変更はまた、スライス間の依存性を決定するために解析される必要のあるシンタックスエレメントの量を削減することを目的とした、パラメータセットまたはヘッダにおける他の必要なシンタックスエレメントの位置の変更と見なされてもよいし、および/または、変更により補間されてもよい。
例えば、HM8.0の現在のシンタックスのスライスヘッダにおけるシンタックスエレメントdependent_slice_flagは、シンタックスエレメント“dependent_slice_enabled_flag”の値が、ビットストリーム内の依存スライスの使用が有効であることを示す場合にのみ、存在する。依存スライスを有効にすることによってシンタックスエレメント“dependent_slice_enabled_flag”もまた、図9Cに示すように、PPSに含まれる。したがって、PPS内のシンタックスエレメント“dependent_slice_enabled_flag”が、dependent_slice_flagの解析に必要な自身の解析を単純化するために、PPSのシンタックス内で上方(例えば、パラメータセットの先頭に)に移動される。これはまた、dependent_slice_flagがpic_parameter_set_id(パラメータセットを識別するシンタックスエレメント)の後に符号化される場合にも役に立ち得る。なぜなら、そうすることによって、依存スライス有効化フラグが依存性インジケーションの存在を必要とする場合でも、解析エラーが回避されるからである。
PPS内で“dependent_slice_enabled_flag”を上方に移動させる代わりに、階層の低いパラメータセットを追跡記録する必要がなくなるように、“dependent_slice_enabled_flag”がPPSからSPSおよび/またはVPSに移動されてもよい。
つまり、本実施の形態によると、必要なシンタックスエレメントの位置は、追跡記録される必要のあるパラメータセットの量を削減する目的で変更される。これは、解析の複雑さも削減する。この文脈において、「必要なパラメータ」は、スライスが相互依存スライスであるか否かを決定するために役立つパラメータを意味する。HEVCに直接適用可能な第1の可能性は、依存スライスのスライスヘッダの先頭に、スライスヘッダと異なるパラメータセットに含まれる依存スライス有効化フラグを必要条件としない依存性インジケーションを付加することである。HEVCに直接適用可能な第2の可能性は、依存スライス有効化フラグが含まれるパラメータセットを識別するシンタックスエレメントのインジケーションの後に、依存スライスヘッダにおける依存性インジケーションを提供することである。依存性インジケーションは、依存スライス有効化フラグを必要条件としてもよい。PPS内で依存スライス有効化フラグを上方に移動させること、または依存スライス有効化フラグをSPS内に移動させることは、これらの可能性の何れにも有益である。特に、依存スライス有効化フラグが依存性インジケーションの解析に必要である第2の可能性に関して有益である。
図10から分かるように、NALユニットヘッダは、スライスヘッダの関連する部分と合わせて、18ビットを有する(NALUヘッダ14ビット、スライスヘッダ2ビット)。この例によると、メディアアウェアネットワークエレメントが対象スライスパケットに対して次のように動作してもよい。先行する通常スライス、エントロピースライス、または依存スライスが削除されると、ネットワークエレメントは対象スライスヘッダの初めの2ビット、つまりfirst_slice_in_pic_flagおよび(依存スライスがビットストリームに許容される場合)dependent_slice_flagをチェックする。
NALユニットタイプがVCL NALユニットタイプであり、チェックされた18ビットの最後の2ビットが“01”であれば、そのNALユニットは削除される。特に、スライスヘッダの先頭のビットが“1”であれば、それは、(ルールによれば)ピクチャの先頭の依存スライスでないスライスである。スライスヘッダの先頭のビットが“0”であり、次のビットも“0”であれば、そのスライスは独立している。したがって、スライスヘッダの先頭の2ビットが”01”である場合にのみ、そのスライスは依存している。さらに、当該スライスは、親スライスが既に削除されているときは、復号できないため、削除されなければならない。よって、first_slice_in_pic_flagおよびdependent_slice_flagは、スライスヘッダシンタックスに属していても、NALヘッダの拡張であると見なすことができる。
本実施の形態では、さらに、ネットワークパケットを受信し、分析し、目的地に転送するネットワークルータを提供する。このルータは、パケット目的地アドレスと符号化ビデオデータを有するビットストリーム部分とを含むネットワークパケットを受信する受信部と、他のパケットからの前記符号化ビデオデータの依存性を判定するために、上述したまたは後述の実施の形態に記載した符号化ビデオシーケンスのビットストリームを解析する前記装置を含むパーサと、前記受信されたパケットの目的地アドレスと、判定された依存性とを分析し、前記ネットワークパケットの扱い方を判断するパケットアナライザとを備える。
(実施の形態2)
本実施の形態2によれば、dependent_slice_enabled_flagがPPSから削除されている。なお、dependent_slice_enabled_flagは、削除するのではなく、SPSに移動させてもよい。
図11は、first_slice_in_pic_flagおよびdependent_slice_flagにアクセスする前に、dependent_slice_enabled_flagを解析する必要がない例を示す図である。
この例では、dependent_slice_enabled_flagは、依存性インジケーションの存在を必要条件としないため、用いられない。この例は、対象PPSセットの識別が分からないことに起因する解析上の問題を引き起こすことなく、スライスヘッダの先頭に依存性インジケーションを配置する可能性を提供する。
(実施の形態2の効果等)
実施の形態1では、dependent_slice_flagを解析するためには、dependent_slice_enabled_flagを解析しなければならない。dependent_slice_enabled_flagは、PPS内に含まれて信号により伝達される。これは上述の通り、dependent_slice_enabled_flagがPPSの初めから遠い位置にあり、かつ先行するシンタックスエレメントが条件付きで符号化される場合に、解析のオーバーヘッドをもたらす可能性がある。
さらに、PPSにおいてシンタックスエレメントpic_parameter_set_idが解析される前にシンタックスエレメントdependent_slice_flagを信号により伝達すると、次のような解析エラーが発生し得る。dependent_slice_flagの存在は、PPS内に含まれて信号により伝達されるdependent_slice_enabled_flagに依存する。しかしながら、現在有効なPPSのidは、dependent_slice_flagの後に信号により伝達される。したがって、先行するエレメントにアクセスする前にdependent_slice_flagを解析することはできない。
本実施の形態では、dependent_slice_enabled_flagを必要条件とする解析を取り除くため、有益である。以下の制限を適用すると、さらに有益である。つまり、PPS内のdependent_slice_enabled_flagがゼロであれば、dependent_slice_flagはゼロになる。
しかしながら、これら有利な実施形態は、本発明の範囲を限定するものではない。
(実施の形態1および2の変形例1)
dependent_slice_enabled_flagを取り除く代わりに、または、それに追加的に、dependent_slice_enabled_flagをPPSからSPSおよび/またはVPSの何れかに移動させてもよい。
さらに、単にdependent_slice_enabled_flagを移動させる代わりに、dependent_slice_enabled_flagをSPSに複写させてもよい。この場合、SPSおよびPPS内のインジケータは、強制的に同じ値としてもよい。もしくは、PPSはSPS内のインジケータの上書きを許可されてもよい。
例えば、sps_dependent_slice_enabled_flagが1であれば、pps_dependent_slice_enabled_flagは0または1の可能性がある。sps_dependent_slice_enabled_flagはSPS内に含まれて信号により伝達されたピクチャのシーケンスに用いられる依存スライスの有効化を示すインジケーションであり、pps_dependent_slice_enabled_flagは、PPS内に含まれて信号により伝達されたピクチャに用いられる依存スライスの有効化を示すインジケーションである。しかしながら、dependent_slice_enabled_flagの値がPPS内で変化できるなら、これは、PPSの解析が依然として必要であることを意味し、PPSの追跡記録および解析の頻度が低くなるという効果が防げられる。
これらの変形例は、VPSおよびSPSが依存構造を保持するという効果を奏する。VPSおよびSPSが依存構造を保持することにより、ネットワークエレメントがビットストリームを形成できる、つまりどうしても復号できない依存パケットを削除することができる、または独立スライスではない依存スライスを削除すると決定することができる。したがって、VPS内のdependent_slice_enabled_flagは、ルータがスライスヘッダを追加的に確認するか、またはしないかのトリガとなる。
これらの変形例は、図10および11の例において適用された場合、解析における複雑さをさらに低減するものではない。しかしながら、これは依存性構造を保持するためのさらに有益なシンタックス構造を提供する。要するに、この例によれば、依存スライスがビットストリームに対して有効か否かを示すインジケータが、映像パラメータセット内に含まれて信号により伝達される。ここで、映像パラメータセットは、複数のピクチャにおける複数のスライスに適用するパラメータセットである。
dependent_slice_enabled_flagがVPSおよび/またはSPSにおいて信号により伝達される場合、2つの効果がある。フラグが単に移動または複写されている場合は、PPSは解析される必要がなく、その結果、解析のオーバーヘッドが削減される。もう一つの利点は、ルータに映像シーケンスの予測構造を知らせることができる点である。この効果は常にある。通常、ルータは、何を受信するかを知るために、VPS/SPSの内容を確認してもよい。
VPSは、階層において最上位のパラメータである。SPSおよびPPSはそれぞれ1つの映像シーケンスおよび1つのピクチャに対応するのに対して、VPSは複数の映像シーケンスに関する情報を含むことができる。VPSに含まれる情報は、ビットレートあるいは映像シーケンスのtemporal_layering構造等である。また、レイヤ間の依存性(異なる映像シーケンス間の依存性)に関する情報を含む。よって、VPSを、複数の映像シーケンスの入れ物としてみなすことができ、VPSにより、各シーケンスの概要が分かる。
HEVCの最新版において、フレームにおけるスライス間の依存性は、dependent_slice_flagおよびfirst_slice_in_pic_flagの両方によって規定されている。最新の仕様書によれば、ネットワークエンティティは、非常に複雑な解析を適用することなくスライス間の依存性を利用することはできない。単純な解決法は、パケット番号の欠落によってパケットのロスが発見された場合、値が1のfirst_slice_in_pic_flagが見つかるまで全てのパケットを削除することである。なぜなら、ピクチャの先頭のスライスは、常に通常スライスだからである。
しかしながら、この解決法は、符号化効率の低下につながる。したがって、上述の通り、スライス間依存性の信号による伝達を有効にする効率的な解析が採用されてもよい。これは、NALヘッダの直後のスライスヘッダ内において、dependent_slice_flagおよびfirst_slice_in_pic_flagを信号により伝達することによって達成される。
その代わりまたはそれに加えて、スライス間依存性に関連するシンタックスエレメントは、無条件に、つまり、スライスヘッダまたはPPS内にある他のシンタックスエレメントとは独立して符号化される。
(実施の形態1および2の変形例2)
図12は、上記の変形例1に代わる他の変形例2を示す図である。具体的には、NALユニットヘッダ1210は、図10に示すNALユニットヘッダ(図9Aに示すNALユニットヘッダ910)と同じである。しかしながら、スライスヘッダ1220は、図10に示すスライスヘッダ1020とは、シンタックスエレメントdependent_slice_flagおよびfirst_slice_in_pic_flagの順番が逆になっている。特に、スライスヘッダ1220は、最初のシンタックスエレメントとしてdependent_slice_flagを含み、dependent_slice_flagの存在を必要条件として、2番目のシンタックスエレメントとしてシンタックスエレメントfirst_slice_in_pic_flagを含む。
この例から分かるように、スライスがピクチャにおける先頭のスライスであるか否かを示す第1スライスインジケーションが、シンタックスに含まれる。ピクチャにおける先頭のスライスは、常に、可変長復号において他のスライスに依存しないスライスである。さらに、依存スライスフラグは、ビットストリームにおいて、第1スライスインジケーションの前に含まれる。第1スライスインジケーションは、依存スライスフラグが依存スライスであることを示さない場合にのみビットストリームに含まれる。この配置は、条件付けと同じ効果をもたらす。つまり、依存性フラグは、第1スライスインジケーションを必要条件とする。図12から分かるとおり、両方のエレメントが依存性インジケーションとして理解されてもよく、スライスヘッダの先頭に含まれる。
(実施の形態3)
本実施の形態3では、実施の形態1および実施の形態2と比較して、不必要なシンタックスエレメントの解析を減らすために、シンタックスエレメントの配置方法が変更されている。
上記実施の形態では、dependent_slice_flagの存在を必要条件としてfirst_slice_in_pic_flagが含まれる場合について説明したが、first_slice_in_pic_flagおよびdependent_slice_flagは、共に、互いの存在を必要条件とせずにビットストリームに含まれてもよい。例えば、上記の変形例のうちの1つおいて、シンタックスエレメントdependent_slice_enabled_flagから独立させるために、dependent_slice_flagの符号化方法を変更する。
図13は、本実施の形態のスライスヘッダの一例を示す図である。図13に示す例では、依存スライス有効化フラグに関する依存性インジケーションの条件付けを依然として含む場合を示している。
具体的には、本実施の形態のスライスヘッダでは、図6に示す従来のスライスヘッダと比較して、dependent_slice_flagが、slice_addressの前に配置されている。さらに、本実施の形態のスライスヘッダでは、図10〜図12に示す例と比較して、dependent_slice_flagが、pic_parameter_set_idの後に配置されている。
本実施の形態では、dependent_slice_flagがslice_addressの前に配置されているので、dependent_slice_flagを解析するのに、少なくともSPSを解析する必要がない。上述したように、slice_addressは、スライスの開始を示すシンタックスエレメントである。さらに、slice_addressは、SPS内に含まれて信号により伝達されたシンタックスエレメント(pic_parameter_set_id)の助けによってのみ解析できる。
その代わりに、またはそれに加えて、dependent_slice_enabled_flagはPPS内で上方に移動されるか、SPSおよび/またはVPSに移動される。有効化フラグがVPSおよび/またはSPS内にある場合は、解析ならびにPPSおよびSPSの追跡記録が必要としなくてもよい。
(実施の形態3の変形例、効果等)
(1)少なくとも部分的に可変長符号で符号化されたビデオシーケンスであって、ビデオ画像の符号化スライスを保持するデータユニットを含むビデオシーケンスのビットストリームを解析する装置において、図13に示すスライスヘッダを持つビットストリームを解析するように構成してもよい。この場合、当該装置を、ビットストリームから以下のシンタックスエレメントを抽出するパーサを備えるように構成する。
−スライスの可変長復号が他のスライスに依存するか否かを示す、スライスヘッダ内のシンタックスエレメントである依存性インジケーション、
−複数のスライスに用いられるパラメータセット内に含まれ、依存スライスがビットストリーム内に含まれるか否かを示す依存スライス有効化フラグ、および、
−ビットストリーム内のスライスが開始する位置を示すスライスアドレス。
(2)また、本実施の形態では、依存性インジケーションは、スライスアドレスの前、かつ、前記パラメータセットを識別するシンタックスエレメントの後に、スライスヘッダ内に含まれて信号により伝達される。
したがって、本実施の形態では、依存スライスをビットストリームに含むことができることを依存スライス有効化フラグが示す場合のみ、解析エラーを起こすことなく、依存性インジケーションがビットストリームに含まれるように構成することができる。
(3)さらに、本実施の形態では、依存スライス有効化フラグは、ビットストリーム内の、同一のピクチャフレームを形成する複数のスライスに共通のパラメータセット(PPS)内、かつ、前記パラメータセットの先頭に配置しているが、これに限るものではない。
その代わりに、(またはそれに加えて)、依存スライス有効化フラグは、ビットストリーム内の、同一のピクチャシーケンスを形成する複数のスライスに共通のパラメータセット(SPS)内に位置してもよい。さらにその代わりに、(またはそれに加えて)、依存スライス有効化フラグは、ビットストリーム内の、複数のピクチャフレームシーケンスを形成する複数のスライスに共通のパラメータセット(VPS)内に位置してもよい。
(4)また、本実施の形態において、VPS_idおよびSPS_idを、SEIメッセージ内に含めて明示的に信号により伝達するように構成してもよい。dependent_slice_enabled_flagがSPS内に含まれて信号により伝達される場合、dependent_slice_flagは依然としてpic_parameter_set_idに後続しなければならない。
そうしなければ、SPS_idがPPS内に含まれて信号により伝達されることから、解析において依存性が導入される。dependent_slice_enabled_flagを保持する対象SPSまたはVPSの識別を信号により伝達することによって、その後のピクチャパラメータセットの解析が不要であるため、依存性インジケーションをpic_parameter_set_idの前に含めてもよい。さらに、VPS_idまたはSPS_idを保持するSEIメッセージは、それらのIDもPPSを解析することによって決定されるので、復号処理に不要である。よって、SEIメッセージは、ネットワークエレメントに使用された後に、復号処理に影響することなく削除できる。
(実施の形態4)
本実施の形態4では、スライス間依存性の情報が、SEIメッセージのような他のNALユニットに(スライスヘッダおよび/またはパラメータセット内に含まれて信号により伝達された情報の補足に)複写される。
例えば、全てのアクセスユニット内の、または各依存スライスの前のスライス間依存性の情報を伝達するSEIメッセージを定義してもよい。「アクセスユニット」という用語は、NALユニットのセットからなるデータユニットを指す。アクセスユニットは、複数の符号化ピクチャスライス、つまり複数のVCL NALUを含む。特に、アクセスユニットはランダムアクセスに用いられるポイントを定義してもよく、単一のピクチャの複数のNALUを含んでもよい。しかしながら、アクセスユニットは必ずしもランダムアクセスポイントでなくてもよい。
最新のHEVC仕様書において、アクセスユニットは復号順に連続したNALユニットのセットとして定義され、きっちり1つの符号化ピクチャを含む。符号化ピクチャの符号化スライスNALユニットに加えて、アクセスユニットは、符号化ピクチャのスライスを含まない他のNALユニットも含んでもよい。アクセスユニットの復号は、常に、復号ピクチャをもたらす。しかしながら、HEVCの将来の拡張において(マルチビュー符号化(MVC)またはスケーラブル映像符号化(SVC)のように)、アクセスユニットの定義は緩和/修正されてもよい。最新の仕様書によれば、アクセスユニットは、アクセスユニットデリミター、SEIメッセージ、およびVCL NALUによって形成されている。
よって、本実施の形態によれば、依存性インジケーションは、ビットストリームにおいて、依存性インジケーションが関連するスライスのヘッダの外に位置する。さらに、依存性インジケーションが、ビットストリームにおいて、依存スライスの前またはアクセスユニット毎にビットストリーム内に含まれるSEIメッセージ内に位置すれば、有益かも知れない。
(実施の形態5)
本実施の形態5によれば、スライス間依存性情報は、フラグとして、または暗示的に、関連するNALユニットタイプとしてNALヘッダ内に含まれて信号により伝達される。
規則として、NALヘッダにおけるシンタックスエレメントの解析は、他のシンタックスエレメントの何れにも依存しない。全てのNALユニットヘッダは、独立して解析できる。NALヘッダは、通常、依存性情報を信号により伝達させる場所である。従って、本実施の形態によれば、スライス間依存性も、NALヘッダに含まれて信号送信される。
言い換えると、解析装置は、ルータまたはデコーダに採用されてもよい。解析装置は、さらに、ネットワーク適応レイヤ、NALヘッダを符号化映像データのスライスおよび当該スライスのヘッダに追加するためのネットワーク適応レイヤユニットをさらに含む。有利な点は、依存性インジケーションは、ビットストリームにおいて、NALヘッダ内に位置し、他のシンタックスエレメントとは独立して符号化される点である。
最新のHEVC仕様書におけるNALヘッダは、そのために用いることができる予備のビットを想定しているため、依存性インジケータは、NALヘッダ内に位置してもよい。依存性インジケーションの信号による伝達は、単一のビットで十分と思われる。
または、依存性インジケーションは、NALユニットタイプによって示され、予め定義されたNALユニットタイプは依存性情報を保持するために保存される。
(実施の形態6)
上記5つの実施の形態は、ネットワークエレメントにおける依存性の情報を効率的に解析できるようにするために、任意に組み合わせてもよい。それらの使用が重複しても、当該実施の形態は組み合わせ可能である。したがって、依存性インジケーションがスライスヘッダの先頭に含まれて信号により伝達されている場合でも、依存性インジケーションの複写は適用可能である。
図14は、図9Aに示すNALユニットヘッダ910を修正したNALユニットヘッダ1410の例を示す図である。NALユニットヘッダ1410は、dependent_slice_flagを含む。
さらに、dependent_slice_flagをNALヘッダに移動させ、後方互換性のためNALヘッダのサイズを固定し続けるために、NALユニットヘッダのシンタックスエレメントnuh_reserved_zero_6bitsからdependent_slice_flagに必要な1ビットが取得される。よって、シンタックスエレメントnuh_reserved_zero_6bitsは、現在5ビットのみを有する。シンタックスエレメントnuh_reserved_zero_6bitsは、ビットの減少が何ら問題を起こさず、さらなる修正を要しないように、後で用いるための予備のビットを有する。
一般的に、対象VCL NALユニットは、同一のtemporal_layer_idを有する先行するVCL NALユニットに依存する。dependent_slice_flagがNALヘッダ内に含まれて信号により伝達されている場合は、ピクチャスライスまたはパラメータセットといった全てのデータユニットが同じNALヘッダを有するため、VCLおよび非VCL NALユニットの両方に1ビットが浪費される。よって、dependent_slice_flagも、パラメータセットまたはSEIメッセージに用いられるように信号により伝達されると思われるが、それは不必要である。さらに、依存スライスがシーケンスパラメータセット内で無効になっても、dependent_slice_flagは、常に信号による伝達が必要である。これは不必要なオーバーヘッドにつながる。
上記全ての実施形態において、依存性インジケーションは1ビットのフラグでもよい。
(実施の形態7)
本実施の形態7によれば、依存性インジケーションはNALユニットタイプによって示され、予め定義されたNALユニットタイプは、依存性情報を保持するために保存される。
よって、新たな(別個の)VCL NALタイプが、既存のVCL NALユニットのように、類似の記号論で定義される。例えば、NAL_unit_typeの値が15に(または他の予め定義されたタイプ、または他の特定タイプのNALUのために保存されていないNALUに)等しければ、対象VCL NALユニットは同一のtemporal_layer_idを有する先行VCL NALユニットに依存する。その依存性は、上述の通り、先行スライスのスライスヘッダに対する対象スライスの依存性、つまり解析における依存性に関連する。
これらの場合において、追加的NALユニットタイプにNALヘッダ内のビットを含めると有益であると考えられる。これは、対象スライスが依存スライスであるか否かを示すために用いることができる。
依存性情報がNALヘッダ内に含まれての信号による伝達に加えて、スライスヘッダ内に含まれての信号による伝達が可能な場合、NALヘッダ内に含まれての信号による伝達はオプションにより選択されることになる。具体的には、NALヘッダ内のNAL_unit_typeフィールドが、対象スライスが依存スライスであることを信号により伝達するように構成されていれば、他の「タイプ」の情報を信号により伝達することはできない。例えば、対象スライスが「シーケンスにおける先頭のピクチャ」(10または11に等しいNAL_unit_type)であるという情報を伝達するほうがより有益な場合がある。(スライスヘッダ内に複写されていることにより)NALヘッダにおけるスライス間依存性情報オプションにより選択可能であれば、より価値のある情報を信号により伝達することが選択されてもよい。
さらに、(解析に用いられる)「依存スライスRAPピクチャ」または「依存スライス非RAPピクチャ」といった2つ以上のVCL NALユニットタイプを追加することは有益であると考えられる。“RAP”という用語は、ランダムアクセスピクチャを示す。ランダムアクセスピクチャは、他のピクチャとは(予測に関して)独立して符号化されたピクチャなので、符号化および復号の開始点として用いてもよい。これにより、ランダムアクセスポイントとして適する。
依存スライスヘッダにおいて、シンタックスエレメントRapPicFlagが解析処理に用いられる。具体的には、シンタックスエレメントRapPicFlagは、対象ピクチャがランダムアクセスピクチャであるか否かを示すインジケーションである。
RAPPicFlagの値は、以下の式2のようにNALユニットタイプに依存する。
つまり、図15に示す例では、ランダムアクセスピクチャは、NALUタイプが7から12のNALUによって保持される。本実施の形態では、正確な解析を可能にし、ランダムアクセスピクチャに対するスライス依存性の可能性を提供するために、2つの異なるNALユニットタイプが、スライスヘッダの正確な解析を保証する目的で定義されている。
全般的なルールとして、新たなVCL NALユニットタイプが定義されたとしても、スライスヘッダの解析は、依然として何ら問題なく可能であると考えられる。複数のNALタイプの何れかが上記のように定義されるか、あるいは、解析に問題が生じない方法で依存スライスヘッダが変更される。
新しいVCL NALユニットタイプが依存スライスであることを示す場合、スライスヘッダのシンタックス構造は、下記のように変更される。
上述した例のNALユニットタイプ“DS_NUT”は、処理対象VCLnalユニットが依存スライスであることを示すために用いられる。非特許文献3に記載されている最新のスライスヘッダのシンタックス構造と比較すると、本実施の形態では、下記の2つの変更が導き出される。
(1)no_output_of_prior_pics_flagが、依存スライスに含まれていない。言い換えると、no_output_of_prior_pics_flagは、処理対象スライスが依存スライスではない場合に存在する。(処理対象スライスが依存スライスではない場合に、no_output_of_prior_pics_flagはスライスヘッダに存在する。)
(2)first_slice_in_pic_flagが、nal_unit_typeの値に応じて含まれる。nal_unit_typeの値が、処理対象スライスが依存スライスであることを示す場合、シンタックスの要素first_slice_in_pic_flagは明示的に含まれず、0になると推測される。これは、同じ品質でビットレートを維持する。
上述した例によれば、処理対象スライスが依存スライスである場合、no_output_of_prior_pics_flagは含まれない。RapPicFlagの値は、処理対象スライスが依存スライスである場合、評価の為に必要とされない。このため、依存スライスのスライスヘッダは、問題無く評価できる。さらに依存スライスのスライスヘッダは、先行するnalユニットヘッダのNALユニットヘッダを参照することなく、解析することができる。先行するnalユニットヘッダが復号時に存在しない場合は、問題が生じる。
次に、first_slice_in_pic_flagは、NAL_unit_typeの値に基づいて含められる。この変更は、図12に示される例と同じである。図12では、first_slice_in_pic_flagは、処理対象スライスが依存スライス(dependent_slice_flagにより示される)ではない場合にのみ、スライスヘッダに含められる。同様に、処理対象スライスが依存スライスではないことを意味する“DS_NUT”とnal_unit_typeとが等しくない場合にのみ、上述した例のfirst_slice_in_pic_flagが含められる。
上述した2つの変更は、同時に行う必要は無い。また、スライスヘッダにおいて、一方の変更のみを行ってもよい。各変更の利点は、スライスが依存スライスであるか否かのチェックコストに関連する。しかし、2つの変更が同時に実行された場合、2つのシンタックスエレメントfirst_slice_in_pic_flagおよびno_output_of_prior_pics_flagが連続してコーディング(符号化)されている場合は、2つの変更の利点は、個々に変更した場合の個々の利点と同じになる。従って、2つの変更と、2つのシンタックスエレメントの連続したコーディングとを組み合わせたアプリケーションでは、個々の変更を個別に行うアプリケーションよりも利点がある。
実施の形態の説明の全てにおいて、依存スライスの指標が条件付きで符号化されていない場合は、ビットストリームからdependent_slice_enabled_flagを削除することが可能である。言い換えると、新しいNALユニットタイプを処理対象スライスが依存スライスであることを示すために用いるなら、ビットストリームからdependent_slice_enabled_flagを削除することができる。
図15は、図9Aに示すNALユニットヘッダ910と同一のNALユニットヘッダ1510と、図9Aに示すスライスヘッダ920を変更したスライスヘッダ1520の例を示す図である。スライスヘッダ1520は、NALUのタイプに従ってdependent_slice_flag値の終端を含む。特に、15および16の値を有するNAL_unit_typeシンタックスエレメントは、依存スライスを定義する。NAL_unit_typeが15に等しい場合は、スライスのタイプはランダムアクセスピクチャの依存スライスである。一方、NAL_unit_typeが16に等しければ、当該スライスは非ランダムアクセスピクチャの依存スライスである。従って、以下の式3の関係が成り立つ。
なお、値15および16は、単に一例として選択された。当業者には明らかなとおり、他には用いられない予め定義された任意の番号を採用してもよい。具体的には、NALUの第1タイプはランダムアクセスピクチャの依存スライスの内容を識別するために定義され、NALUの第2タイプは非ランダムアクセスピクチャの依存スライスの内容を識別するために定義される。
さらに、依存スライスはRAPのみに用いられるか、または非RAPのみに用いられるという制限が適用されてもよい。その場合、新たなNALUタイプは1つだけ必要である。
(実施の形態8)
図16は、代替的な解決法を示す図である。NALユニットヘッダ1610は、NALユニットヘッダ910と同じである。スライスヘッダ1620では、NAL_unit_typeが、上述したような依存スライスを定義する値15および16を有すると仮定している。
しかしながら、NAL_unit_typeは依存スライスフラグの解析において用いられない。これにより、エンコーダによるNAL_unit_typeの使用は、オプション化することができる。したがって、本実施の形態の効果は、エンコーダが新たなNALUタイプの採用を決定したときにのみ達成される。
そして、ルータはNALUタイプを検証するだけでよい。しかしながら、エンコーダが上述した新たなNALUタイプを使用しなければ、ルータは技術水準の通りに依存スライスを取り扱うと考えられる。
要するに、依存性インジケーションは、NALユニットタイプによって示されてもよい。また、予め定義されたNALユニットタイプは、スライスヘッダが先行スライスのスライスヘッダに依存する符号化されたスライスを保持するために保存されてもよい。有利な点は、依存性を示す別個のNALユニットタイプが、ランダムアクセスピクチャおよび非ランダムアクセスピクチャに対して提供される点である。
要するに、上述した実施の形態は、符号化映像シーケンスを保持するビットストリームのシンタックスに関する。特に、上述した実施の形態は、スライスヘッダが先行スライスのスライスヘッダに依存する依存スライスおよびエントロピースライスに関連するシンタックスに関する。メディアアウェアネットワーク要素が、その複雑性および解析による遅延を実質的に増加させずにこの種の依存性を考慮できるようにするために、依存性のインジケーションがパケットの先頭、つまり、解析対象のヘッダまたはパラメータの近傍に含まれて信号により伝達される。これは、例えば、スライスヘッダの先頭に(図10〜図12)、できれば、パラメータセットを識別するシンタックスの後、かつ、スライスアドレスの前に依存性インジケーションを含めることによって(図10、図11)、または、別個のメッセージを用い、NALUヘッダに依存性インジケーションを提供することによって(図14)、または、依存スライスを保持するNALUに用いられる特別なNALUタイプを用いて(図15、図16)達成される。
(上記実施の形態1〜8の変形例、効果等)
本発明は、以上の実施例に限定されることなく、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。
なお、上記各実施の形態において、各構成要素は、専用のハードウェア(処理回路)で構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、CPUまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。
なお、上記実施の形態1〜8では、wavefrontを前提として説明したが、これに限るものではない。
但し、wavefrontの場合、全てのサブストリームを同時に開始することはできない。上述したように、先頭のサブストリーム以外の各サブストリームについては、処理(符号化または復号)の開始が、先行するサブストリームよりもLCU2つ分遅れることになる。このため、wavefrontでは、より処理の短縮が求められている。本実施の形態では、依存性インジケーション(dependent_slice_flag)を、PPSを識別するシンタックスの後、スライスアドレスの前に配置することで、解析するシンタックスエレメントの数を減らすことができ、処理を短縮することが可能になる。
また、上記実施の形態1〜8では、依存性インジケーションをスライスヘッダ内のより上方に(特に、先頭に)配置することで、例えば、ピクチャの処理のより早い段階で、各スライスが依存スライスであるか否かを確認することが可能になる。
つまり、ピクチャに対する処理(符号化処理または復号処理)の開始時に、複数のスライスのそれぞれについて、依存スライスであるか否かを確認するステップを実行すれば、ピクチャに対する処理の開始時に、並列処理の開始点を抽出することが可能になる。つまり、ピクチャに複数の通常スライスが含まれる場合に、ピクチャに対する処理の開始時(あるいは、処理の早い段階で)並列処理の開始点を抽出できる。
ここで、従来のように、依存性インジケーションがスライスアドレスの後に配置されている場合は、当該スライスアドレスの解析が終わるまで、スライスが依存スライスか通常スライスであるかを確認できない。この場合、ピクチャの途中にある通常スライスの処理の開始は、ピクチャの先頭にある通常スライスの処理の開始より相当遅れることになる。
これに対し、上述した実施の形態1〜8では、ピクチャの処理のより早い段階で、各スライスが依存スライスであるか否かを確認することが可能になるため、ピクチャの途中にある通常スライスの処理の開始を、より早めることが可能になる。言い換えると、ピクチャの途中にある通常スライスの処理を、ピクチャの先頭にある通常スライスとほぼ同時に開始することが可能になる。
(実施の形態9)
上記各実施の形態で示した動画像符号化方法(画像符号化方法)または動画像復号化方法(画像復号方法)の構成を実現するためのプログラムを記憶メディアに記録することにより、上記各実施の形態で示した処理を独立したコンピュータシステムにおいて簡単に実施することが可能となる。記憶メディアは、磁気ディスク、光ディスク、光磁気ディスク、ICカード、半導体メモリ等、プログラムを記録できるものであればよい。
さらにここで、上記各実施の形態で示した動画像符号化方法(画像符号化方法)や動画像復号化方法(画像復号方法)の応用例とそれを用いたシステムを説明する。当該システムは、画像符号化方法を用いた画像符号化装置、及び画像復号方法を用いた画像復号装置からなる画像符号化復号装置を有することを特徴とする。システムにおける他の構成について、場合に応じて適切に変更することができる。
図17は、コンテンツ配信サービスを実現するコンテンツ供給システムex100の全体構成を示す図である。通信サービスの提供エリアを所望の大きさに分割し、各セル内にそれぞれ固定無線局である基地局ex106、ex107、ex108、ex109、ex110が設置されている。
このコンテンツ供給システムex100は、インターネットex101にインターネットサービスプロバイダex102および電話網ex104、および基地局ex106からex110を介して、コンピュータex111、PDA(Personal Digital Assistant)ex112、カメラex113、携帯電話ex114、ゲーム機ex115などの各機器が接続される。
しかし、コンテンツ供給システムex100は図17のような構成に限定されず、いずれかの要素を組合せて接続するようにしてもよい。また、固定無線局である基地局ex106からex110を介さずに、各機器が電話網ex104に直接接続されてもよい。また、各機器が近距離無線等を介して直接相互に接続されていてもよい。
カメラex113はデジタルビデオカメラ等の動画撮影が可能な機器であり、カメラex116はデジタルカメラ等の静止画撮影、動画撮影が可能な機器である。また、携帯電話ex114は、GSM(登録商標)(Global System for Mobile Communications)方式、CDMA(Code Division Multiple Access)方式、W−CDMA(Wideband-Code Division Multiple Access)方式、若しくはLTE(Long Term Evolution)方式、HSPA(High Speed Packet Access)の携帯電話機、またはPHS(Personal Handyphone System)等であり、いずれでも構わない。
コンテンツ供給システムex100では、カメラex113等が基地局ex109、電話網ex104を通じてストリーミングサーバex103に接続されることで、ライブ配信等が可能になる。ライブ配信では、ユーザがカメラex113を用いて撮影するコンテンツ(例えば、音楽ライブの映像等)に対して上記各実施の形態で説明したように符号化処理を行い(即ち、本発明の一態様に係る画像符号化装置として機能する)、ストリーミングサーバex103に送信する。一方、ストリーミングサーバex103は要求のあったクライアントに対して送信されたコンテンツデータをストリーム配信する。クライアントとしては、上記符号化処理されたデータを復号化することが可能な、コンピュータex111、PDAex112、カメラex113、携帯電話ex114、ゲーム機ex115等がある。配信されたデータを受信した各機器では、受信したデータを復号化処理して再生する(即ち、本発明の一態様に係る画像復号装置として機能する)。
なお、撮影したデータの符号化処理はカメラex113で行っても、データの送信処理をするストリーミングサーバex103で行ってもよいし、互いに分担して行ってもよい。同様に配信されたデータの復号化処理はクライアントで行っても、ストリーミングサーバex103で行ってもよいし、互いに分担して行ってもよい。また、カメラex113に限らず、カメラex116で撮影した静止画像および/または動画像データを、コンピュータex111を介してストリーミングサーバex103に送信してもよい。この場合の符号化処理はカメラex116、コンピュータex111、ストリーミングサーバex103のいずれで行ってもよいし、互いに分担して行ってもよい。
また、これら符号化・復号化処理は、一般的にコンピュータex111や各機器が有するLSIex500において処理する。LSIex500は、ワンチップであっても複数チップからなる構成であってもよい。なお、動画像符号化・復号化用のソフトウェアをコンピュータex111等で読み取り可能な何らかの記録メディア(CD−ROM、フレキシブルディスク、ハードディスクなど)に組み込み、そのソフトウェアを用いて符号化・復号化処理を行ってもよい。さらに、携帯電話ex114がカメラ付きである場合には、そのカメラで取得した動画データを送信してもよい。このときの動画データは携帯電話ex114が有するLSIex500で符号化処理されたデータである。
また、ストリーミングサーバex103は複数のサーバや複数のコンピュータであって、データを分散して処理したり記録したり配信するものであってもよい。
以上のようにして、コンテンツ供給システムex100では、符号化されたデータをクライアントが受信して再生することができる。このようにコンテンツ供給システムex100では、ユーザが送信した情報をリアルタイムでクライアントが受信して復号化し、再生することができ、特別な権利や設備を有さないユーザでも個人放送を実現できる。
なお、コンテンツ供給システムex100の例に限らず、図18に示すように、デジタル放送用システムex200にも、上記各実施の形態の少なくとも動画像符号化装置(画像符号化装置)または動画像復号化装置(画像復号装置)のいずれかを組み込むことができる。具体的には、放送局ex201では映像データに音楽データなどが多重化された多重化データが電波を介して通信または衛星ex202に伝送される。この映像データは上記各実施の形態で説明した動画像符号化方法により符号化されたデータである(即ち、本発明の一態様に係る画像符号化装置によって符号化されたデータである)。これを受けた放送衛星ex202は、放送用の電波を発信し、この電波を衛星放送の受信が可能な家庭のアンテナex204が受信する。受信した多重化データを、テレビ(受信機)ex300またはセットトップボックス(STB)ex217等の装置が復号化して再生する(即ち、本発明の一態様に係る画像復号装置として機能する)。
また、DVD、BD等の記録メディアex215に記録した多重化データを読み取り復号化する、または記録メディアex215に映像信号を符号化し、さらに場合によっては音楽信号と多重化して書き込むリーダ/レコーダex218にも上記各実施の形態で示した動画像復号化装置または動画像符号化装置を実装することが可能である。この場合、再生された映像信号はモニタex219に表示され、多重化データが記録された記録メディアex215により他の装置やシステムにおいて映像信号を再生することができる。また、ケーブルテレビ用のケーブルex203または衛星/地上波放送のアンテナex204に接続されたセットトップボックスex217内に動画像復号化装置を実装し、これをテレビのモニタex219で表示してもよい。このときセットトップボックスではなく、テレビ内に動画像復号化装置を組み込んでもよい。
図19は、上記各実施の形態で説明した動画像復号化方法および動画像符号化方法を用いたテレビ(受信機)ex300を示す図である。テレビex300は、上記放送を受信するアンテナex204またはケーブルex203等を介して映像データに音声データが多重化された多重化データを取得、または出力するチューナex301と、受信した多重化データを復調する、または外部に送信する多重化データに変調する変調/復調部ex302と、復調した多重化データを映像データと、音声データとに分離する、または信号処理部ex306で符号化された映像データ、音声データを多重化する多重/分離部ex303を備える。
また、テレビex300は、音声データ、映像データそれぞれを復号化する、またはそれぞれの情報を符号化する音声信号処理部ex304、映像信号処理部ex305(本発明の一態様に係る画像符号化装置または画像復号装置として機能する)を有する信号処理部ex306と、復号化した音声信号を出力するスピーカex307、復号化した映像信号を表示するディスプレイ等の表示部ex308を有する出力部ex309とを有する。さらに、テレビex300は、ユーザ操作の入力を受け付ける操作入力部ex312等を有するインタフェース部ex317を有する。さらに、テレビex300は、各部を統括的に制御する制御部ex310、各部に電力を供給する電源回路部ex311を有する。インタフェース部ex317は、操作入力部ex312以外に、リーダ/レコーダex218等の外部機器と接続されるブリッジex313、SDカード等の記録メディアex216を装着可能とするためのスロット部ex314、ハードディスク等の外部記録メディアと接続するためのドライバex315、電話網と接続するモデムex316等を有していてもよい。なお記録メディアex216は、格納する不揮発性/揮発性の半導体メモリ素子により電気的に情報の記録を可能としたものである。テレビex300の各部は同期バスを介して互いに接続されている。
まず、テレビex300がアンテナex204等により外部から取得した多重化データを復号化し、再生する構成について説明する。テレビex300は、リモートコントローラex220等からのユーザ操作を受け、CPU等を有する制御部ex310の制御に基づいて、変調/復調部ex302で復調した多重化データを多重/分離部ex303で分離する。さらにテレビex300は、分離した音声データを音声信号処理部ex304で復号化し、分離した映像データを映像信号処理部ex305で上記各実施の形態で説明した復号化方法を用いて復号化する。復号化した音声信号、映像信号は、それぞれ出力部ex309から外部に向けて出力される。出力する際には、音声信号と映像信号が同期して再生するよう、バッファex318、ex319等に一旦これらの信号を蓄積するとよい。また、テレビex300は、放送等からではなく、磁気/光ディスク、SDカード等の記録メディアex215、ex216から多重化データを読み出してもよい。次に、テレビex300が音声信号や映像信号を符号化し、外部に送信または記録メディア等に書き込む構成について説明する。テレビex300は、リモートコントローラex220等からのユーザ操作を受け、制御部ex310の制御に基づいて、音声信号処理部ex304で音声信号を符号化し、映像信号処理部ex305で映像信号を上記各実施の形態で説明した符号化方法を用いて符号化する。符号化した音声信号、映像信号は多重/分離部ex303で多重化され外部に出力される。多重化する際には、音声信号と映像信号が同期するように、バッファex320、ex321等に一旦これらの信号を蓄積するとよい。なお、バッファex318、ex319、ex320、ex321は図示しているように複数備えていてもよいし、1つ以上のバッファを共有する構成であってもよい。さらに、図示している以外に、例えば変調/復調部ex302や多重/分離部ex303の間等でもシステムのオーバフロー、アンダーフローを避ける緩衝材としてバッファにデータを蓄積することとしてもよい。
また、テレビex300は、放送等や記録メディア等から音声データ、映像データを取得する以外に、マイクやカメラのAV入力を受け付ける構成を備え、それらから取得したデータに対して符号化処理を行ってもよい。なお、ここではテレビex300は上記の符号化処理、多重化、および外部出力ができる構成として説明したが、これらの処理を行うことはできず、上記受信、復号化処理、外部出力のみが可能な構成であってもよい。
また、リーダ/レコーダex218で記録メディアから多重化データを読み出す、または書き込む場合には、上記復号化処理または符号化処理はテレビex300、リーダ/レコーダex218のいずれで行ってもよいし、テレビex300とリーダ/レコーダex218が互いに分担して行ってもよい。
一例として、光ディスクからデータの読み込みまたは書き込みをする場合の情報再生/記録部ex400の構成を図20に示す。情報再生/記録部ex400は、以下に説明する要素ex401、ex402、ex403、ex404、ex405、ex406、ex407を備える。光ヘッドex401は、光ディスクである記録メディアex215の記録面にレーザスポットを照射して情報を書き込み、記録メディアex215の記録面からの反射光を検出して情報を読み込む。変調記録部ex402は、光ヘッドex401に内蔵された半導体レーザを電気的に駆動し記録データに応じてレーザ光の変調を行う。再生復調部ex403は、光ヘッドex401に内蔵されたフォトディテクタにより記録面からの反射光を電気的に検出した再生信号を増幅し、記録メディアex215に記録された信号成分を分離して復調し、必要な情報を再生する。バッファex404は、記録メディアex215に記録するための情報および記録メディアex215から再生した情報を一時的に保持する。ディスクモータex405は記録メディアex215を回転させる。サーボ制御部ex406は、ディスクモータex405の回転駆動を制御しながら光ヘッドex401を所定の情報トラックに移動させ、レーザスポットの追従処理を行う。システム制御部ex407は、情報再生/記録部ex400全体の制御を行う。上記の読み出しや書き込みの処理はシステム制御部ex407が、バッファex404に保持された各種情報を利用し、また必要に応じて新たな情報の生成・追加を行うと共に、変調記録部ex402、再生復調部ex403、サーボ制御部ex406を協調動作させながら、光ヘッドex401を通して、情報の記録再生を行うことにより実現される。システム制御部ex407は例えばマイクロプロセッサで構成され、読み出し書き込みのプログラムを実行することでそれらの処理を実行する。
以上では、光ヘッドex401はレーザスポットを照射するとして説明したが、近接場光を用いてより高密度な記録を行う構成であってもよい。
図21に光ディスクである記録メディアex215の模式図を示す。記録メディアex215の記録面には案内溝(グルーブ)がスパイラル状に形成され、情報トラックex230には、予めグルーブの形状の変化によってディスク上の絶対位置を示す番地情報が記録されている。この番地情報はデータを記録する単位である記録ブロックex231の位置を特定するための情報を含み、記録や再生を行う装置において情報トラックex230を再生し番地情報を読み取ることで記録ブロックを特定することができる。また、記録メディアex215は、データ記録領域ex233、内周領域ex232、外周領域ex234を含んでいる。ユーザデータを記録するために用いる領域がデータ記録領域ex233であり、データ記録領域ex233より内周または外周に配置されている内周領域ex232と外周領域ex234は、ユーザデータの記録以外の特定用途に用いられる。情報再生/記録部ex400は、このような記録メディアex215のデータ記録領域ex233に対して、符号化された音声データ、映像データまたはそれらのデータを多重化した多重化データの読み書きを行う。
以上では、1層のDVD、BD等の光ディスクを例に挙げ説明したが、これらに限ったものではなく、多層構造であって表面以外にも記録可能な光ディスクであってもよい。また、ディスクの同じ場所にさまざまな異なる波長の色の光を用いて情報を記録したり、さまざまな角度から異なる情報の層を記録したりなど、多次元的な記録/再生を行う構造の光ディスクであってもよい。
また、デジタル放送用システムex200において、アンテナex205を有する車ex210で衛星ex202等からデータを受信し、車ex210が有するカーナビゲーションex211等の表示装置に動画を再生することも可能である。なお、カーナビゲーションex211の構成は例えば図19に示す構成のうち、GPS受信部を加えた構成が考えられ、同様なことがコンピュータex111や携帯電話ex114等でも考えられる。
図22Aは、上記実施の形態で説明した動画像復号化方法および動画像符号化方法を用いた携帯電話ex114を示す図である。携帯電話ex114は、基地局ex110との間で電波を送受信するためのアンテナex350、映像、静止画を撮ることが可能なカメラ部ex365、カメラ部ex365で撮像した映像、アンテナex350で受信した映像等が復号化されたデータを表示する液晶ディスプレイ等の表示部ex358を備える。携帯電話ex114は、さらに、操作キー部ex366を有する本体部、音声を出力するためのスピーカ等である音声出力部ex357、音声を入力するためのマイク等である音声入力部ex356、撮影した映像、静止画、録音した音声、または受信した映像、静止画、メール等の符号化されたデータもしくは復号化されたデータを保存するメモリ部ex367、又は同様にデータを保存する記録メディアとのインタフェース部であるスロット部ex364を備える。
さらに、携帯電話ex114の構成例について、図22Bを用いて説明する。携帯電話ex114は、表示部ex358及び操作キー部ex366を備えた本体部の各部を統括的に制御する主制御部ex360に対して、電源回路部ex361、操作入力制御部ex362、映像信号処理部ex355、カメラインタフェース部ex363、LCD(Liquid Crystal Display)制御部ex359、変調/復調部ex352、多重/分離部ex353、音声信号処理部ex354、スロット部ex364、メモリ部ex367がバスex370を介して互いに接続されている。
電源回路部ex361は、ユーザの操作により終話及び電源キーがオン状態にされると、バッテリパックから各部に対して電力を供給することにより携帯電話ex114を動作可能な状態に起動する。
携帯電話ex114は、CPU、ROM、RAM等を有する主制御部ex360の制御に基づいて、音声通話モード時に音声入力部ex356で収音した音声信号を音声信号処理部ex354でデジタル音声信号に変換し、これを変調/復調部ex352でスペクトラム拡散処理し、送信/受信部ex351でデジタルアナログ変換処理および周波数変換処理を施した後にアンテナex350を介して送信する。また携帯電話ex114は、音声通話モード時にアンテナex350を介して受信した受信データを増幅して周波数変換処理およびアナログデジタル変換処理を施し、変調/復調部ex352でスペクトラム逆拡散処理し、音声信号処理部ex354でアナログ音声信号に変換した後、これを音声出力部ex357から出力する。
さらにデータ通信モード時に電子メールを送信する場合、本体部の操作キー部ex366等の操作によって入力された電子メールのテキストデータは操作入力制御部ex362を介して主制御部ex360に送出される。主制御部ex360は、テキストデータを変調/復調部ex352でスペクトラム拡散処理をし、送信/受信部ex351でデジタルアナログ変換処理および周波数変換処理を施した後にアンテナex350を介して基地局ex110へ送信する。電子メールを受信する場合は、受信したデータに対してこのほぼ逆の処理が行われ、表示部ex358に出力される。
データ通信モード時に映像、静止画、または映像と音声を送信する場合、映像信号処理部ex355は、カメラ部ex365から供給された映像信号を上記各実施の形態で示した動画像符号化方法によって圧縮符号化し(即ち、本発明の一態様に係る画像符号化装置として機能する)、符号化された映像データを多重/分離部ex353に送出する。また、音声信号処理部ex354は、映像、静止画等をカメラ部ex365で撮像中に音声入力部ex356で収音した音声信号を符号化し、符号化された音声データを多重/分離部ex353に送出する。
多重/分離部ex353は、映像信号処理部ex355から供給された符号化された映像データと音声信号処理部ex354から供給された符号化された音声データを所定の方式で多重化し、その結果得られる多重化データを変調/復調部(変調/復調回路部)ex352でスペクトラム拡散処理をし、送信/受信部ex351でデジタルアナログ変換処理及び周波数変換処理を施した後にアンテナex350を介して送信する。
データ通信モード時にホームページ等にリンクされた動画像ファイルのデータを受信する場合、または映像およびもしくは音声が添付された電子メールを受信する場合、アンテナex350を介して受信された多重化データを復号化するために、多重/分離部ex353は、多重化データを分離することにより映像データのビットストリームと音声データのビットストリームとに分け、同期バスex370を介して符号化された映像データを映像信号処理部ex355に供給するとともに、符号化された音声データを音声信号処理部ex354に供給する。映像信号処理部ex355は、上記各実施の形態で示した動画像符号化方法に対応した動画像復号化方法によって復号化することにより映像信号を復号し(即ち、本発明の一態様に係る画像復号装置として機能する)、LCD制御部ex359を介して表示部ex358から、例えばホームページにリンクされた動画像ファイルに含まれる映像、静止画が表示される。また音声信号処理部ex354は、音声信号を復号し、音声出力部ex357から音声が出力される。
また、上記携帯電話ex114等の端末は、テレビex300と同様に、符号化器・復号化器を両方持つ送受信型端末の他に、符号化器のみの送信端末、復号化器のみの受信端末という3通りの実装形式が考えられる。さらに、デジタル放送用システムex200において、映像データに音楽データなどが多重化された多重化データを受信、送信するとして説明したが、音声データ以外に映像に関連する文字データなどが多重化されたデータであってもよいし、多重化データではなく映像データ自体であってもよい。
このように、上記各実施の形態で示した動画像符号化方法あるいは動画像復号化方法を上述したいずれの機器・システムに用いることは可能であり、そうすることで、上記各実施の形態で説明した効果を得ることができる。
また、本発明はかかる上記実施の形態に限定されるものではなく、本発明の範囲を逸脱することなく種々の変形または修正が可能である。
(実施の形態10)
上記各実施の形態で示した動画像符号化方法または装置と、MPEG−2、MPEG4−AVC、VC−1など異なる規格に準拠した動画像符号化方法または装置とを、必要に応じて適宜切替えることにより、映像データを生成することも可能である。
ここで、それぞれ異なる規格に準拠する複数の映像データを生成した場合、復号する際に、それぞれの規格に対応した復号方法を選択する必要がある。しかしながら、復号する映像データが、どの規格に準拠するものであるか識別できないため、適切な復号方法を選択することができないという課題を生じる。
この課題を解決するために、映像データに音声データなどを多重化した多重化データは、映像データがどの規格に準拠するものであるかを示す識別情報を含む構成とする。上記各実施の形態で示す動画像符号化方法または装置によって生成された映像データを含む多重化データの具体的な構成を以下説明する。多重化データは、MPEG−2トランスポートストリーム形式のデジタルストリームである。
図23は、多重化データの構成を示す図である。図23に示すように多重化データは、ビデオストリーム、オーディオストリーム、プレゼンテーショングラフィックスストリーム(PG)、インタラクティブグラフィックスストリームのうち、1つ以上を多重化することで得られる。ビデオストリームは映画の主映像および副映像を、オーディオストリーム(IG)は映画の主音声部分とその主音声とミキシングする副音声を、プレゼンテーショングラフィックスストリームは、映画の字幕をそれぞれ示している。ここで主映像とは画面に表示される通常の映像を示し、副映像とは主映像の中に小さな画面で表示する映像のことである。また、インタラクティブグラフィックスストリームは、画面上にGUI部品を配置することにより作成される対話画面を示している。ビデオストリームは、上記各実施の形態で示した動画像符号化方法または装置、従来のMPEG−2、MPEG4−AVC、VC−1などの規格に準拠した動画像符号化方法または装置によって符号化されている。オーディオストリームは、ドルビーAC−3、Dolby Digital Plus、MLP、DTS、DTS−HD、または、リニアPCMのなどの方式で符号化されている。
多重化データに含まれる各ストリームはPIDによって識別される。例えば、映画の映像に利用するビデオストリームには0x1011が、オーディオストリームには0x1100から0x111Fまでが、プレゼンテーショングラフィックスには0x1200から0x121Fまでが、インタラクティブグラフィックスストリームには0x1400から0x141Fまでが、映画の副映像に利用するビデオストリームには0x1B00から0x1B1Fまで、主音声とミキシングする副音声に利用するオーディオストリームには0x1A00から0x1A1Fが、それぞれ割り当てられている。
図24は、多重化データがどのように多重化されるかを模式的に示す図である。まず、複数のビデオフレームからなるビデオストリームex235、複数のオーディオフレームからなるオーディオストリームex238を、それぞれPESパケット列ex236およびex239に変換し、TSパケットex237およびex240に変換する。同じくプレゼンテーショングラフィックスストリームex241およびインタラクティブグラフィックスex244のデータをそれぞれPESパケット列ex242およびex245に変換し、さらにTSパケットex243およびex246に変換する。多重化データex247はこれらのTSパケットを1本のストリームに多重化することで構成される。
図25は、PESパケット列に、ビデオストリームがどのように格納されるかをさらに詳しく示している。図25における第1段目はビデオストリームのビデオフレーム列を示す。第2段目は、PESパケット列を示す。図25の矢印yy1,yy2,yy3,yy4に示すように、ビデオストリームにおける複数のVideo Presentation UnitであるIピクチャ、Bピクチャ、Pピクチャは、ピクチャ毎に分割され、PESパケットのペイロードに格納される。各PESパケットはPESヘッダを持ち、PESヘッダには、ピクチャの表示時刻であるPTS(Presentation Time−Stamp)やピクチャの復号時刻であるDTS(Decoding Time−Stamp)が格納される。
図26は、多重化データに最終的に書き込まれるTSパケットの形式を示している。TSパケットは、ストリームを識別するPIDなどの情報を持つ4ByteのTSヘッダとデータを格納する184ByteのTSペイロードから構成される188Byte固定長のパケットであり、上記PESパケットは分割されTSペイロードに格納される。BD−ROMの場合、TSパケットには、4ByteのTP_Extra_Headerが付与され、192Byteのソースパケットを構成し、多重化データに書き込まれる。TP_Extra_HeaderにはATS(Arrival_Time_Stamp)などの情報が記載される。ATSは当該TSパケットのデコーダのPIDフィルタへの転送開始時刻を示す。多重化データには図26下段に示すようにソースパケットが並ぶこととなり、多重化データの先頭からインクリメントする番号はSPN(ソースパケットナンバー)と呼ばれる。
また、多重化データに含まれるTSパケットには、映像・音声・字幕などの各ストリーム以外にもPAT(Program Association Table)、PMT(Program Map Table)、PCR(Program Clock Reference)などがある。PATは多重化データ中に利用されるPMTのPIDが何であるかを示し、PAT自身のPIDは0で登録される。PMTは、多重化データ中に含まれる映像・音声・字幕などの各ストリームのPIDと各PIDに対応するストリームの属性情報を持ち、また多重化データに関する各種ディスクリプタを持つ。ディスクリプタには多重化データのコピーを許可・不許可を指示するコピーコントロール情報などがある。PCRは、ATSの時間軸であるATC(Arrival Time Clock)とPTS・DTSの時間軸であるSTC(System Time Clock)の同期を取るために、そのPCRパケットがデコーダに転送されるATSに対応するSTC時間の情報を持つ。
図27はPMTのデータ構造を詳しく説明する図である。PMTの先頭には、そのPMTに含まれるデータの長さなどを記したPMTヘッダが配置される。その後ろには、多重化データに関するディスクリプタが複数配置される。上記コピーコントロール情報などが、ディスクリプタとして記載される。ディスクリプタの後には、多重化データに含まれる各ストリームに関するストリーム情報が複数配置される。ストリーム情報は、ストリームの圧縮コーデックなどを識別するためストリームタイプ、ストリームのPID、ストリームの属性情報(フレームレート、アスペクト比など)が記載されたストリームディスクリプタから構成される。ストリームディスクリプタは多重化データに存在するストリームの数だけ存在する。
記録媒体などに記録する場合には、上記多重化データは、多重化データ情報ファイルと共に記録される。
多重化データ情報ファイルは、図28に示すように多重化データの管理情報であり、多重化データと1対1に対応し、多重化データ情報、ストリーム属性情報とエントリマップから構成される。
多重化データ情報は図28に示すようにシステムレート、再生開始時刻、再生終了時刻から構成されている。システムレートは多重化データの、後述するシステムターゲットデコーダのPIDフィルタへの最大転送レートを示す。多重化データ中に含まれるATSの間隔はシステムレート以下になるように設定されている。再生開始時刻は多重化データの先頭のビデオフレームのPTSであり、再生終了時刻は多重化データの終端のビデオフレームのPTSに1フレーム分の再生間隔を足したものが設定される。
ストリーム属性情報は図29に示すように、多重化データに含まれる各ストリームについての属性情報が、PID毎に登録される。属性情報はビデオストリーム、オーディオストリーム、プレゼンテーショングラフィックスストリーム、インタラクティブグラフィックスストリーム毎に異なる情報を持つ。ビデオストリーム属性情報は、そのビデオストリームがどのような圧縮コーデックで圧縮されたか、ビデオストリームを構成する個々のピクチャデータの解像度がどれだけであるか、アスペクト比はどれだけであるか、フレームレートはどれだけであるかなどの情報を持つ。オーディオストリーム属性情報は、そのオーディオストリームがどのような圧縮コーデックで圧縮されたか、そのオーディオストリームに含まれるチャンネル数は何であるか、何の言語に対応するか、サンプリング周波数がどれだけであるかなどの情報を持つ。これらの情報は、プレーヤが再生する前のデコーダの初期化などに利用される。
本実施の形態においては、上記多重化データのうち、PMTに含まれるストリームタイプを利用する。また、記録媒体に多重化データが記録されている場合には、多重化データ情報に含まれる、ビデオストリーム属性情報を利用する。具体的には、上記各実施の形態で示した動画像符号化方法または装置において、PMTに含まれるストリームタイプ、または、ビデオストリーム属性情報に対し、上記各実施の形態で示した動画像符号化方法または装置によって生成された映像データであることを示す固有の情報を設定するステップまたは手段を設ける。この構成により、上記各実施の形態で示した動画像符号化方法または装置によって生成した映像データと、他の規格に準拠する映像データとを識別することが可能になる。
また、本実施の形態における動画像復号化方法のステップを図30に示す。ステップexS100において、多重化データからPMTに含まれるストリームタイプ、または、多重化データ情報に含まれるビデオストリーム属性情報を取得する。次に、ステップexS101において、ストリームタイプ、または、ビデオストリーム属性情報が上記各実施の形態で示した動画像符号化方法または装置によって生成された多重化データであることを示しているか否かを判断する。そして、ストリームタイプ、または、ビデオストリーム属性情報が上記各実施の形態で示した動画像符号化方法または装置によって生成されたものであると判断された場合には、ステップexS102において、上記各実施の形態で示した動画像復号方法により復号を行う。また、ストリームタイプ、または、ビデオストリーム属性情報が、従来のMPEG−2、MPEG4−AVC、VC−1などの規格に準拠するものであることを示している場合には、ステップexS103において、従来の規格に準拠した動画像復号方法により復号を行う。
このように、ストリームタイプ、または、ビデオストリーム属性情報に新たな固有値を設定することにより、復号する際に、上記各実施の形態で示した動画像復号化方法または装置で復号可能であるかを判断することができる。従って、異なる規格に準拠する多重化データが入力された場合であっても、適切な復号化方法または装置を選択することができるため、エラーを生じることなく復号することが可能となる。また、本実施の形態で示した動画像符号化方法または装置、または、動画像復号方法または装置を、上述したいずれの機器・システムに用いることも可能である。
(実施の形態11)
上記各実施の形態で示した動画像符号化方法および装置、動画像復号化方法および装置は、典型的には集積回路であるLSIで実現される。一例として、図31に1チップ化されたLSIex500の構成を示す。LSIex500は、以下に説明する要素ex501、ex502、ex503、ex504、ex505、ex506、ex507、ex508、ex509を備え、各要素はバスex510を介して接続している。電源回路部ex505は電源がオン状態の場合に各部に対して電力を供給することで動作可能な状態に起動する。
例えば符号化処理を行う場合には、LSIex500は、CPUex502、メモリコントローラex503、ストリームコントローラex504、駆動周波数制御部ex512等を有する制御部ex501の制御に基づいて、AV I/Oex509によりマイクex117やカメラex113等からAV信号を入力する。入力されたAV信号は、一旦SDRAM等の外部のメモリex511に蓄積される。制御部ex501の制御に基づいて、蓄積したデータは処理量や処理速度に応じて適宜複数回に分けるなどされ信号処理部ex507に送られ、信号処理部ex507において音声信号の符号化および/または映像信号の符号化が行われる。ここで映像信号の符号化処理は上記各実施の形態で説明した符号化処理である。信号処理部ex507ではさらに、場合により符号化された音声データと符号化された映像データを多重化するなどの処理を行い、ストリームI/Oex506から外部に出力する。この出力された多重化データは、基地局ex107に向けて送信されたり、または記録メディアex215に書き込まれたりする。なお、多重化する際には同期するよう、一旦バッファex508にデータを蓄積するとよい。
なお、上記では、メモリex511がLSIex500の外部の構成として説明したが、LSIex500の内部に含まれる構成であってもよい。バッファex508も1つに限ったものではなく、複数のバッファを備えていてもよい。また、LSIex500は1チップ化されてもよいし、複数チップ化されてもよい。
また、上記では、制御部ex501が、CPUex502、メモリコントローラex503、ストリームコントローラex504、駆動周波数制御部ex512等を有するとしているが、制御部ex501の構成は、この構成に限らない。例えば、信号処理部ex507がさらにCPUを備える構成であってもよい。信号処理部ex507の内部にもCPUを設けることにより、処理速度をより向上させることが可能になる。また、他の例として、CPUex502が信号処理部ex507、または信号処理部ex507の一部である例えば音声信号処理部を備える構成であってもよい。このような場合には、制御部ex501は、信号処理部ex507、またはその一部を有するCPUex502を備える構成となる。
なお、ここでは、LSIとしたが、集積度の違いにより、IC、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。
また、集積回路化の手法はLSIに限るものではなく、専用回路または汎用プロセッサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。このようなプログラマブル・ロジック・デバイスは、典型的には、ソフトウェア又はファームウェアを構成するプログラムを、ロードする又はメモリ等から読み込むことで、上記各実施の形態で示した動画像符号化方法、又は動画像復号化方法を実行することができる。
さらには、半導体技術の進歩または派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適応等が可能性としてありえる。
(実施の形態12)
上記各実施の形態で示した動画像符号化方法または装置によって生成された映像データを復号する場合、従来のMPEG−2、MPEG4−AVC、VC−1などの規格に準拠する映像データを復号する場合に比べ、処理量が増加することが考えられる。そのため、LSIex500において、従来の規格に準拠する映像データを復号する際のCPUex502の駆動周波数よりも高い駆動周波数に設定する必要がある。しかし、駆動周波数を高くすると、消費電力が高くなるという課題が生じる。
この課題を解決するために、テレビex300、LSIex500などの動画像復号化装置は、映像データがどの規格に準拠するものであるかを識別し、規格に応じて駆動周波数を切替える構成とする。図32は、本実施の形態における構成ex800を示している。駆動周波数切替え部ex803は、映像データが、上記各実施の形態で示した動画像符号化方法または装置によって生成されたものである場合には、駆動周波数を高く設定する。そして、上記各実施の形態で示した動画像復号化方法を実行する復号処理部ex801に対し、映像データを復号するよう指示する。一方、映像データが、従来の規格に準拠する映像データである場合には、映像データが、上記各実施の形態で示した動画像符号化方法または装置によって生成されたものである場合に比べ、駆動周波数を低く設定する。そして、従来の規格に準拠する復号処理部ex802に対し、映像データを復号するよう指示する。
より具体的には、駆動周波数切替え部ex803は、図31のCPUex502と駆動周波数制御部ex512から構成される。また、上記各実施の形態で示した動画像復号化方法を実行する復号処理部ex801、および、従来の規格に準拠する復号処理部ex802は、図31の信号処理部ex507に該当する。CPUex502は、映像データがどの規格に準拠するものであるかを識別する。そして、CPUex502からの信号に基づいて、駆動周波数制御部ex512は、駆動周波数を設定する。また、CPUex502からの信号に基づいて、信号処理部ex507は、映像データの復号を行う。ここで、映像データの識別には、例えば、実施の形態10で記載した識別情報を利用することが考えられる。識別情報に関しては、実施の形態10で記載したものに限られず、映像データがどの規格に準拠するか識別できる情報であればよい。例えば、映像データがテレビに利用されるものであるか、ディスクに利用されるものであるかなどを識別する外部信号に基づいて、映像データがどの規格に準拠するものであるか識別可能である場合には、このような外部信号に基づいて識別してもよい。また、CPUex502における駆動周波数の選択は、例えば、図34のような映像データの規格と、駆動周波数とを対応付けたルックアップテーブルに基づいて行うことが考えられる。ルックアップテーブルを、バッファex508や、LSIの内部メモリに格納しておき、CPUex502がこのルックアップテーブルを参照することにより、駆動周波数を選択することが可能である。
図33は、本実施の形態の方法を実施するステップを示している。まず、ステップexS200では、信号処理部ex507において、多重化データから識別情報を取得する。次に、ステップexS201では、CPUex502において、識別情報に基づいて映像データが上記各実施の形態で示した符号化方法または装置によって生成されたものであるか否かを識別する。映像データが上記各実施の形態で示した符号化方法または装置によって生成されたものである場合には、ステップexS202において、駆動周波数を高く設定する信号を、CPUex502が駆動周波数制御部ex512に送る。そして、駆動周波数制御部ex512において、高い駆動周波数に設定される。一方、従来のMPEG−2、MPEG4−AVC、VC−1などの規格に準拠する映像データであることを示している場合には、ステップexS203において、駆動周波数を低く設定する信号を、CPUex502が駆動周波数制御部ex512に送る。そして、駆動周波数制御部ex512において、映像データが上記各実施の形態で示した符号化方法または装置によって生成されたものである場合に比べ、低い駆動周波数に設定される。
さらに、駆動周波数の切替えに連動して、LSIex500またはLSIex500を含む装置に与える電圧を変更することにより、省電力効果をより高めることが可能である。例えば、駆動周波数を低く設定する場合には、これに伴い、駆動周波数を高く設定している場合に比べ、LSIex500またはLSIex500を含む装置に与える電圧を低く設定することが考えられる。
また、駆動周波数の設定方法は、復号する際の処理量が大きい場合に、駆動周波数を高く設定し、復号する際の処理量が小さい場合に、駆動周波数を低く設定すればよく、上述した設定方法に限らない。例えば、MPEG4−AVC規格に準拠する映像データを復号する処理量の方が、上記各実施の形態で示した動画像符号化方法または装置により生成された映像データを復号する処理量よりも大きい場合には、駆動周波数の設定を上述した場合の逆にすることが考えられる。
さらに、駆動周波数の設定方法は、駆動周波数を低くする構成に限らない。例えば、識別情報が、上記各実施の形態で示した動画像符号化方法または装置によって生成された映像データであることを示している場合には、LSIex500またはLSIex500を含む装置に与える電圧を高く設定し、従来のMPEG−2、MPEG4−AVC、VC−1などの規格に準拠する映像データであることを示している場合には、LSIex500またはLSIex500を含む装置に与える電圧を低く設定することも考えられる。また、他の例としては、識別情報が、上記各実施の形態で示した動画像符号化方法または装置によって生成された映像データであることを示している場合には、CPUex502の駆動を停止させることなく、従来のMPEG−2、MPEG4−AVC、VC−1などの規格に準拠する映像データであることを示している場合には、処理に余裕があるため、CPUex502の駆動を一時停止させることも考えられる。識別情報が、上記各実施の形態で示した動画像符号化方法または装置によって生成された映像データであることを示している場合であっても、処理に余裕があれば、CPUex502の駆動を一時停止させることも考えられる。この場合は、従来のMPEG−2、MPEG4−AVC、VC−1などの規格に準拠する映像データであることを示している場合に比べて、停止時間を短く設定することが考えられる。
このように、映像データが準拠する規格に応じて、駆動周波数を切替えることにより、省電力化を図ることが可能になる。また、電池を用いてLSIex500またはLSIex500を含む装置を駆動している場合には、省電力化に伴い、電池の寿命を長くすることが可能である。
(実施の形態13)
テレビや、携帯電話など、上述した機器・システムには、異なる規格に準拠する複数の映像データが入力される場合がある。このように、異なる規格に準拠する複数の映像データが入力された場合にも復号できるようにするために、LSIex500の信号処理部ex507が複数の規格に対応している必要がある。しかし、それぞれの規格に対応する信号処理部ex507を個別に用いると、LSIex500の回路規模が大きくなり、また、コストが増加するという課題が生じる。
この課題を解決するために、上記各実施の形態で示した動画像復号方法を実行するための復号処理部と、従来のMPEG−2、MPEG4−AVC、VC−1などの規格に準拠する復号処理部とを一部共有化する構成とする。この構成例を図35Aのex900に示す。例えば、上記各実施の形態で示した動画像復号方法と、MPEG4−AVC規格に準拠する動画像復号方法とは、エントロピー符号化、逆量子化、デブロッキングフィルタ、動き補償などの処理において処理内容が一部共通する。共通する処理内容については、MPEG4−AVC規格に対応する復号処理部ex902を共有し、MPEG4−AVC規格に対応しない、本発明の一態様に特有の他の処理内容については、専用の復号処理部ex901を用いるという構成が考えられる。復号処理部の共有化に関しては、共通する処理内容については、上記各実施の形態で示した動画像復号化方法を実行するための復号処理部を共有し、MPEG4−AVC規格に特有の処理内容については、専用の復号処理部を用いる構成であってもよい。
また、処理を一部共有化する他の例を図35Bのex1000に示す。この例では、本発明の一態様に特有の処理内容に対応した専用の復号処理部ex1001と、他の従来規格に特有の処理内容に対応した専用の復号処理部ex1002と、本発明の一態様に係る動画像復号方法と他の従来規格の動画像復号方法とに共通する処理内容に対応した共用の復号処理部ex1003とを用いる構成としている。ここで、専用の復号処理部ex1001、ex1002は、必ずしも本発明の一態様、または、他の従来規格に特有の処理内容に特化したものではなく、他の汎用処理を実行できるものであってもよい。また、本実施の形態の構成を、LSIex500で実装することも可能である。
このように、本発明の一態様に係る動画像復号方法と、従来の規格の動画像復号方法とで共通する処理内容について、復号処理部を共有することにより、LSIの回路規模を小さくし、かつ、コストを低減することが可能である。