図面 (/)

技術 画像復号方法、画像復号装置、およびコンピュータ読取可能な媒体

出願人 ヴェロスメディアインターナショナルリミテッド
発明者 セミエセンリクマティアスナロシュケトーマスウェディ
出願日 2019年7月10日 (1年5ヶ月経過) 出願番号 2019-128634
公開日 2019年11月28日 (1年1ヶ月経過) 公開番号 2019-205183
状態 特許登録済
技術分野 TV信号の圧縮,符号化方式
主要キーワード 通常スライス C状態 記号論 パラメータ構造 LF処理 固有ネットワーク 並列解析 最適ブロック
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2019年11月28日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

処理効率を向上することができる画像復号方法等を提供する。

解決手段

画像復号方法は、デコーダを用いて、符号化ビットストリームから、現行スライスとは異なるスライスに対する復号処理の結果に依存して復号処理が実行される依存スライスがピクチャに含まれるか否かを示し、これらスライスに共通のパラメータセット内に配置されている、依存スライス有効化フラグと、前記現行スライスの開始位置を示し、前記現行スライスのスライスヘッダ内に配置されている、スライスアドレスと、前記現行スライスが前記依存スライスであるか否かを示し、前記スライスヘッダ内の、前記スライスアドレスの前かつ前記パラメータセットを識別するシンタックスエレメントの後に配置されている、依存性インジケーションと、を抽出するステップを含む。

概要

背景

現在の標準的な映像符号化アルゴリズムの大半はハイブリッド映像符号化に基づく。ハイブリッド映像符号化方法では、所望の圧縮ゲインを達成するために、いくつかの異なる可逆圧縮方式不可逆圧縮方式とが用いられる。ハイブリッド映像符号化は、ISO/IEC標準規格MPEG‐1、MPEG‐2及びMPEG‐4などのMPEG−X標準規格)と同様に、ITU‐T標準規格(H.261及びH.263などのH.26x標準規格)の基礎である。

最新の映像符号化標準規格は、H.264/MPEG‐4 Advanced Video Coding(AVC)と称される。この規格は、JVT(Joint CoVedeo Team)と、ITU‐T及びISO/IECMPEGグループとの合同チームにより標準化された。

また、高解像度の映像符号化の効率改善を目的として、HEVC(High−Efficiency Video Coding)と称される映像符号化標準規格が、JCT−VC(Joint Collaborative Team on Video Coding)により検討されている。

概要

処理効率を向上することができる画像復号方法等を提供する。画像復号方法は、デコーダを用いて、符号化ビットストリームから、現行スライスとは異なるスライスに対する復号処理の結果に依存して復号処理が実行される依存スライスがピクチャに含まれるか否かを示し、これらスライスに共通のパラメータセット内に配置されている、依存スライス有効化フラグと、前記現行スライスの開始位置を示し、前記現行スライスのスライスヘッダ内に配置されている、スライスアドレスと、前記現行スライスが前記依存スライスであるか否かを示し、前記スライスヘッダ内の、前記スライスアドレスの前かつ前記パラメータセットを識別するシンタックスエレメントの後に配置されている、依存性インジケーションと、を抽出するステップを含む。

目的

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

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

(分野番号表示ON)※整理標準化データをもとに当社作成

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

ピクチャ復号する画像復号方法であって、符号化されたビットストリームから、前記ピクチャについて依存スライス使用可能であるかどうかを示す依存スライス有効化フラグを復号するステップであって、前記依存スライスは、前記依存スライスとは異なるスライスのヘッダに含まれる制御情報を少なくとも部分的に使用して復号処理が実行されるスライスである、復号するステップと、前記ピクチャがランダムアクセスピクチャであるか否かを示す値を決定し、前記ピクチャがランダムアクセスピクチャであるかどうかを決定した後に、符号化されたビットストリームから、i)前記ピクチャの現行スライスの開始位置を示すスライスアドレスと、ii)前記現行スライスが依存スライスかどうかを示す依存性インジケーションと、を復号するステップと、を備え、前記依存スライス有効化フラグは、前記ピクチャのすべてのスライスに共通のパラメータセット内に配置され、前記スライスアドレスは前記現行スライスのスライスヘッダに配置され、前記依存性インジケーションは、前記現行スライスの前記スライスヘッダ内の、前記スライスアドレスの前かつ前記パラメータセットを識別するシンタックスエレメントの後に配置されている、画像復号方法。

請求項2

前記依存スライスが前記ピクチャに対して有効であることを前記依存スライス有効化フラグが示す場合、前記ビットストリームから前記依存性インジケーションが抽出される、請求項1に記載の画像復号方法。

請求項3

前記依存スライス有効化フラグは、前記パラメータセットの先頭に配置される、請求項1に記載の画像復号方法。

請求項4

前記依存性インジケーションは、前記ピクチャの最初に処理されるスライスのスライスヘッダに含まれない、請求項1に記載の画像復号方法。

請求項5

ピクチャを復号する画像復号装置であって、少なくとも1つのプロセッサと、コンピュータプログラムコードを含む少なくとも1つのメモリであって、前記コンピュータプログラムコードと前記少なくとも1つのメモリは、前記少なくとも1つのプロセッサと協働すると、符号化されたビットストリームから、前記ピクチャについて依存スライスが使用可能であるかどうかを示す依存スライス有効化フラグを復号し、前記依存スライスは、前記依存スライスとは異なるスライスのヘッダに含まれる制御情報を少なくとも部分的に使用して復号処理が実行されるスライスであり、前記ピクチャがランダムアクセスピクチャであるか否かを示す値を決定し、前記ピクチャがランダムアクセスピクチャであるかどうかを決定した後に、符号化されたビットストリームから、i)前記ピクチャの現行スライスの開始位置を示すスライスアドレスと、ii)前記現行スライスが依存スライスかどうかを示す依存性インジケーションと、を復号する、ように構成され、前記依存スライス有効化フラグは、前記ピクチャのすべてのスライスに共通のパラメータセット内に配置され、前記スライスアドレスは前記現行スライスのスライスヘッダに配置され、前記依存性インジケーションは、前記現行スライスの前記スライスヘッダ内の、前記スライスアドレスの前かつ前記パラメータセットを識別するシンタックスエレメントの後に配置されている、画像復号装置。

請求項6

前記依存スライスが前記ピクチャに対して有効であることを前記依存スライス有効化フラグが示す場合、前記ビットストリームから前記依存性インジケーションが抽出される、請求項5に記載の画像復号装置。

請求項7

前記依存スライス有効化フラグは、前記パラメータセットの先頭に配置される、請求項5に記載の画像復号装置。

請求項8

前記依存性インジケーションは、前記ピクチャの最初に処理されるスライスのスライスヘッダに含まれない、請求項5に記載の画像復号装置。

請求項9

プロセッサによって実行されるときに、符号化されたビットストリームから、ピクチャについて依存スライスが使用可能であるかどうかを示す依存スライス有効化フラグを復号するステップであって、前記依存スライスは、前記依存スライスとは異なるスライスのヘッダに含まれる制御情報を少なくとも部分的に使用して復号処理が実行されるスライスである、復号するステップと、前記ピクチャがランダムアクセスピクチャであるか否かを示す値を決定し、前記ピクチャがランダムアクセスピクチャであるかどうかを決定した後に、符号化されたビットストリームから、i)前記ピクチャの現行スライスの開始位置を示すスライスアドレスと、ii)前記現行スライスが依存スライスかどうかを示す依存性インジケーションと、を復号するステップと、を実施する命令を格納する一時的でないコンピュータ読取可能な媒体であって、前記依存スライス有効化フラグは、前記ピクチャのすべてのスライスに共通のパラメータセット内に配置され、前記スライスアドレスは前記現行スライスのスライスヘッダに配置され、前記依存性インジケーションは、前記現行スライスの前記スライスヘッダ内の、前記スライスアドレスの前かつ前記パラメータセットを識別するシンタックスエレメントの後に配置されている、一時的でないコンピュータ読取可能な媒体。

請求項10

前記依存スライスが前記ピクチャに対して有効であることを前記依存スライス有効化フラグが示す場合、前記ビットストリームから前記依存性インジケーションが抽出される、請求項9に記載の一時的でないコンピュータ読取可能な媒体。

請求項11

前記依存スライス有効化フラグは、前記パラメータセットの先頭に配置される、請求項9に記載の一時的でないコンピュータ読取可能な媒体。

請求項12

前記依存性インジケーションは、前記ピクチャの最初に処理されるスライスのスライスヘッダに含まれない、請求項9に記載の一時的でないコンピュータ読取可能な媒体。

技術分野

0001

本発明は、画像を復号する画像復号方法等に関する。

背景技術

0002

現在の標準的な映像符号化アルゴリズムの大半はハイブリッド映像符号化に基づく。ハイブリッド映像符号化方法では、所望の圧縮ゲインを達成するために、いくつかの異なる可逆圧縮方式不可逆圧縮方式とが用いられる。ハイブリッド映像符号化は、ISO/IEC標準規格MPEG‐1、MPEG‐2及びMPEG‐4などのMPEG−X標準規格)と同様に、ITU‐T標準規格(H.261及びH.263などのH.26x標準規格)の基礎である。

0003

最新の映像符号化標準規格は、H.264/MPEG‐4 Advanced Video Coding(AVC)と称される。この規格は、JVT(Joint CoVedeo Team)と、ITU‐T及びISO/IECMPEGグループとの合同チームにより標準化された。

0004

また、高解像度の映像符号化の効率改善を目的として、HEVC(High−Efficiency Video Coding)と称される映像符号化標準規格が、JCT−VC(Joint Collaborative Team on Video Coding)により検討されている。

先行技術

0005

C.Gordon他、“Wavefront Parallel Processing forHEVC Encoding and Decoding”、JCTVC−F274−v2,from the Meeting in Torino,July 2011、インターネット〈URL:http://phenix.int−evry.fr〉
A.Fuldseth他、“Tiles”、JCTVC−F355−v1,from the Meeting in Torino,July 2011、インターネット〈URL:http://phenix.int−evry.fr〉
JCTVC−J1003_d7,“High efficiency video coding (HEVC) text specification draft 8”、July 2012、第73頁「dependent_slice_flag」、インターネット〈URL:http://phenix.IT−sudparis.eu/jct/〉

発明が解決しようとする課題

0006

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

0007

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

課題を解決するための手段

0008

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

0009

また、本発明の一態様に係る画像復号装置は、
少なくとも1つのプロセッサと、コンピュータプログラムコードを含む少なくとも1つのメモリと、を有する画像復号装置であって、
前記メモリおよび前記コンピュータプログラムコードは、前記プロセッサと協働して、符号化ビットストリームから、
現行スライスとは異なるスライスに対する復号処理の結果に依存して復号処理が実行される依存スライスがピクチャに含まれるか否かを示し、これらスライスに共通のパラメータセット内に配置されている、依存スライス有効化フラグと、
前記現行スライスの開始位置を示し、前記現行スライスのスライスヘッダ内に配置されている、スライスアドレスと、
前記現行スライスが前記依存スライスであるか否かを示し、前記スライスヘッダ内の、前記スライスアドレスの前かつ前記パラメータセットを識別するシンタックスエレメントの後に配置されている、依存性インジケーションと、
を前記画像復号装置に抽出させる、
ように構成されている。

0010

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

発明の効果

0011

本発明によれば、処理効率を向上することができる。

図面の簡単な説明

0012

図1は、HEVCに準拠したエンコーダの一例を示すブロック図である。
図2は、HEVCに準拠したデコーダの一例を示すブロック図である。
図3は、波面並列処理(WPP)における画像の構成の一例を示す図である。
図4は、波面並列処理における通常スライスと依存スライスとの関係の一例を示す図である。
図5は、パケットヘッダの一例を示す図である。
図6は、エントロピースライスまたは依存スライスのスライスヘッダの一例を示す図である。
図7は、通常スライスを用いる場合の依存性とその信号伝達を示す図である。
図8は、依存スライスおよびエントロピースライスを用いる場合の依存性とその信号伝達を示す概略図である。
図9Aは、HM8.0における、レイヤ間の依存性、時間的依存性、およびスライス間の依存性のシンタックスの例を示す図である。
図9Bは、HM8.0における、レイヤ間の依存性を解析するために実行される解析ステップを説明するための図である。
図9Cは、HM8.0における、レイヤ間の依存性を解析するために実行される解析ステップを説明するための図である。
図10は、dependent_slice_flagの位置の一例を示す図である。
図11は、図10におけるdependent_slice_enabled_flagに関する解析条件を削除した場合のシンタックスの例を示す図である。
図12は、first_slice_in_pic_flagの前にdependent_slice_flagを移動させた場合のシンタックスの例を示す図である。
図13は、slice_addressの前にdependent_slice_flagを移動させた場合のシンタックスの例を示す図である。
図14は、NALヘッダ内にdependent_slice_flagを移動させた場合のシンタックスの例を示す図である。
図15は、NALユニットタイプに新しいタイプを追加した場合の依存スライスのスライスヘッダのシンタックスの例を示す図である。
図16は、特定のNALユニットタイプに対してdependent_slice_flagが1に設定されると仮定した場合のスライスヘッダおよびNALユニットヘッダのシンタックスの例を示す図である。
図17は、コンテンツ配信サービスを実現するコンテンツ供給システムの全体構成図である。
図18は、デジタル放送用システムの全体構成図である。
図19は、テレビの構成例を示すブロック図である。
図20は、光ディスクである記録メディアに情報の読み書きを行う情報再生/記録部の構成例を示すブロック図である。
図21は、光ディスクである記録メディアの構造例を示す図である。
図22Aは、携帯電話の一例を示す図である。
図22Bは、携帯電話の構成例を示すブロック図である。
図23は、多重化データの構成を示す図である。
図24は、各ストリームが多重化データにおいてどのように多重化されているかを模式的に示す図である。
図25は、PESパケット列に、ビデオストリームがどのように格納されるかを更に詳しく示した図である。
図26は、多重化データにおけるTSパケットソースパケットの構造を示す図である。
図27は、PMTデータ構成を示す図である。
図28は、多重化データ情報の内部構成を示す図である。
図29は、ストリーム属性情報の内部構成を示す図である。
図30は、映像データを識別するステップを示す図である。
図31は、各実施の形態の動画像符号化方法および動画像復号方法を実現する集積回路の構成例を示すブロック図である。
図32は、駆動周波数切り替える構成を示す図である。
図33は、映像データを識別し、駆動周波数を切り替えるステップを示す図である。
図34は、映像データの規格と駆動周波数を対応づけたルックアップテーブルの一例を示す図である。
図35Aは、信号処理部のモジュール共有化する構成の一例を示す図である。
図35Bは、信号処理部のモジュールを共有化する構成の他の一例を示す図である。

実施例

0013

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

0014

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

0015

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

0016

H.264/MPEG−4 AVCにおいては、マクロブロック(通常16×16画素のブロック)単位で符号化が行われる。このマクロブロックはサブブロックに分割される場合もある。符号化方法に含まれる符号化ステップおよび/または復号方法に含まれる復号ステップは、サブブロック単位で実行される。

0017

[1−1.ハイブリッド映像符号化]
以下、ハイブリッド符号化について、簡単に説明する。

0018

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

0019

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

0020

[1−2.画像符号化装置の構成]
図1は、H.264/MPEG−4 AVC及び/またはHEVCに準拠した画像符号化装置(エンコーダ100)の一例を示す図である。

0021

図1に示すように、エンコーダ100は、減算器105と、変換部110と、量子化部120と、逆変換部130と、加算器140と、デブロッキングフィルタ150と、適応ループフィルタ160と、フレームメモリ170と、予測部180と、エントロピー符号化部190とを備えている。

0022

予測部180は、時間的予測または空間的予測により、予測信号s2を導出する。予測部180において用いられる予測のタイプは、フレーム毎またはブロック毎に異なっていてもよい。時間的予測は、インター予測と称され、空間的予測は、イントラ予測と称される。また、時間的予測による予測信号s2を用いた符号化はインター符号化と称され、空間的予測による予測信号s2を用いた符号化はイントラ符号化と称される。時間的予測を用いた予測信号の導出では、メモリに格納されている符号化済みの画像が用いられる。空間的予測を用いた予測信号の導出では、メモリに格納された符号化または復号済み隣接ブロック境界画素値が用いられる。イントラ予測における予測方向の数は、符号化単位(CU、Coding Unit)のサイズによって決まる。なお、予測の詳細については後述する。

0023

減算器105は、入力画像の符号化対象ブロック(=入力信号s1)と対応する予測ブロック(=予測信号s2)との差分(=予測誤差信号e)を導出する。当該差分は、符号化対象ブロックの予測に用いられる。なお、予測誤差信号eは、予測残差信号とも呼ばれる。

0024

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

0025

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

0026

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

0027

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

0028

H.264/MPEG−4 AVC及びHEVCでは、複数種類のエントロピー符号化が用いられる。シンタックス要素の中には固定長で符号化されるものもあるが、ほとんどのシンタックス要素が可変長符号化される。特に、シンタックスのうち、予測誤差信号(予測残差信号)の符号化には、コンテキスト適応可変長符号(CABAC)が用いられる。他のシンタックス要素の符号化には、一般的に、コンテキスト適応可変長符号とは別の様々な整数符号が用いられるが、コンテキスト適応算術符号化を用いてもよい。

0029

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

0030

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

0031

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

0032

H.264/MPEG−4、H.264/MPEG−4 AVC、および、HEVCは、ビデオ符号化層(VCL)とネットワーク抽象化層(NAL)の2つの機能層を有する。上述したように、VCLは、符号化機能を提供する。NALは、チャネルを用いた送信あるいは記憶装置への格納等の用途に応じて、NALユニットと称される標準単位で情報(情報要素)をカプセル化する。NALによりカプセル化される情報要素には、例えば、(1)符号化された予測誤差信号(圧縮映像データ)、および、(2)予測タイプ量子化パラメータおよび動きベクトル等の映像信号の復号に必要な補助情報(関連情報)が含まれる。補助情報には、映像シーケンス全体に関連するパラメータセットなどの追加データがカプセル化されたnon−VCLユニット、および、復号効率の改善に用いることが可能な追加情報を提供する付加拡張情報(SEI)が含まれる。

0033

non−VCLユニットには、例えば、パラメータセットが含まれる。パラメータセットとは、一定の映像シーケンスの符号化および復号に関する複数のパラメータのセットのことである。パラメータセットには、例えば、ピクチャシーケンス全体の符号化および復号に関連するパラメータを含むシーケンスパラメータセットSPS)がある。特に、シーケンスパラメータセットは、シンタックス要素を含むシンタックス構造を有する。シンタックス要素は、seq_parameter_set_idの内容により決定されるゼロ以上の符号化映像シーケンス全体に適用される。seq_parameter_set_idは、pic_parameter_set_idにより参照される(以下で説明する)ピクチャパラメータセットに含まれるシンタックス要素である。pic_parameter_set_idは、各スライスヘッダに含まれるシンタックス要素である。

0034

ピクチャパラメータセット(PPS)は、ピクチャシーケンス(映像シーケンス)のピクチャの符号化および復号に適用されるパラメータを定義したパラメータセットである。特に、PPSは、シンタックス要素を含むシンタックス構造を有する。シンタックス要素は、各スライスヘッダに含まれるシンタックス要素であるpic_parameter_set_idにより決定されるゼロ以上の符号化ピクチャ全体に適用される。

0035

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

0036

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

0037

再構築部は、逆変換部130と、加算器140と、デブロッキングフィルタ150と、適応ループフィルタ160とを含む。

0038

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

0039

加算器140は、逆変換部130により再構築された予測誤差信号e’を、予測信号s2に加えることで、再構築信号s’を導出する。

0040

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

0041

例えば、H.264/MPEG−4 AVCにおけるデブロッキングフィルタ処理では、領域ごとに、当該領域に適したフィルタ処理が選択される。例えば、ブロッキングノイズが大きい場合は、強い(狭帯域ローパスフィルタが用いられ、ブロッキングノイズが小さい場合は、弱い(広帯域)ローパスフィルタが用いられる。このローパスフィルタの強度は、予測信号s2および予測誤差信号e’に応じて決定される。このデブロッキングフィルタ処理により、ブロックのエッジ平滑化される。これにより、復号画像信号主観的画質が改善する。また、フィルタ処理済みの画像が次の画像の動き補償予測に用いられる。よって、このフィルタ処理により予測誤差も削減されるので、符号化効率を改善することができる。

0042

適応ループフィルタ160は、デブロッキングフィルタ150においてデブロッキングフィルタ処理された後の再構築信号s”に対し、サンプ適応オフセット(Sample adaptive offset、SAO)処理および/または適応ループフィルタ(Adaptive Loop Filter、ALF)処理を適用することで、再構築信号(復号信号)s3を導出する。

0043

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

0044

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

0045

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

0046

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

0047

[1−3.画像復号装置の構成]
デコーダ(画像復号装置)の構成について、図2を基に説明する。

0048

図2は、H.264/MPEG−4 AVCまたはHEVC映像符号化規格に準拠したデコーダ200の一例を示すブロック図である。

0049

図2に示すように、デコーダ200は、エントロピー復号部290と、逆変換部230と、加算器240と、デブロッキングフィルタ250と、適応ループフィルタ260と、フレームメモリ270と、予測部280とを備えている。

0050

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

0051

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

0052

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

0053

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

0054

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

0055

加算器240は、逆変換部230から取得した予測誤差信号e’と予測部280から取得した予測信号s2とを加算して、再構築信号s’を導出する。

0056

デブロッキングフィルタ250は、再構築信号s’に対し、デブロッキングフィルタ処理を適用する。適応ループフィルタ260は、デブロッキングフィルタ250によりデブロッキングフィルタ処理を適用された再構築信号s”に対し、SAO処理およびALF処理を適用する。適応ループフィルタ260においてSAO処理およびALF処理が適用された結果得られる復号信号S4は、フレームメモリ270に格納される。フレームメモリ270に格納された復号信号S4は、予測部280において、次の復号対象ブロックあるいは復号対象画像の予測に使用される。

0057

[1−4.処理効率]
符号化処理および復号処理において処理効率を向上させる方法として、一般的に、処理の並列化が考えられる。

0058

H.264/MPEG−4 AVCと比較すると、HEVCは、符号化処理および復号処理の高度な並列処理(並列化処理)を補助する機能を有する。H.264/MPEG−4 AVCと同様に、HEVCでは、フレームを複数のスライスに分割することができる。ここで、各スライスは、走査順で連続する複数のLCUを含む。H.264/MPEG−4 AVCにおいて、スライスはそれぞれ、個々に復号可能であり、スライスを跨いだ空間的予測は行われない。よって、スライス単位で、並列処理が可能である。

0059

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

0060

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

0061

以下の説明では、ピクチャが行列状に配置された複数の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に記載されている。

0062

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

0063

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

0064

また、スライスの概念を、H.264/MPEG−4 AVCにおけるスライスの本来の目的であった誤り耐性よりも、並列化に適した概念にするため、依存スライス及びエントロピースライスの概念が提案されている。

0065

つまり、HEVCでは、(1)通常スライス、(2)エントロピースライス、および、(3)依存スライスの3つのスライスが用いられる。

0066

(1)通常スライスは、H.264/MPEG−4 AVCにより既に知られているスライスのことである。通常スライス間では空間的予測はできない。つまり、スライス間の境界を跨いだ予測はできない。言い換えると、別のスライスを参照することなく、通常スライスは符号化される。このようなスライスの復号を別々に行えるように、CABACは各スライスの先頭でリスタートされる。

0067

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

0068

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

0069

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

0070

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

0071

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

0072

(3)依存スライスは、エントロピースライスと類似しているが、CABACのリスタートの一部処理で異なっている。

0073

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

0074

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

0075

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

0076

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

0077

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

0078

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

0079

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

0080

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

0081

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

0082

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

0083

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

0084

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

0085

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

0086

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

0087

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

0088

これらの方法により、エントロピースライスに対して並列CABAC解析が可能になる。これは、エントロピースライスの先頭でCABACが必ずリスタートされるからである。CABACの並列処理では、連続する画素構築処理の後の並列CABAC解析により障害を克服できる。具体的には、WPP並列化ツールにより、各LCU行の復号処理を1つのコアIPコア(intellectual property core)、機能ブロック)により実現できる。なお、各コアへのLCU行の割り当ては異なってよい。例えば、1つのコアに2行が割り当てられてもよいし、2つのコアに1行が割り当てられてもよい。

0089

図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とその参照先との関係を示している。

0090

具体的には、図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つ分の処理時間に相当する遅延が存在する。

0091

図4は、WPPを用いた依存スライスの使用例を示す図である。LCU行41〜43は、「ウェイブフロント1」、「ウェイブフロント2」、および、「ウェイブフロント3」に対応している。LCU行41〜43は、それぞれ独立したコアで処理される。図4において、LCU行41は通常スライスであり、LCU行42〜4mは依存スライスである。

0092

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

0093

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

0094

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

0095

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

0096

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

0097

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

0098

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

0099

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

0100

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

0101

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

0102

図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の後に続く。

0103

改良されたサービス品質を提供できるルータは、メディアアウェアネットワークエレメント(Media Aware Network Elements、MANE)と呼ばれる。メディアアウェアネットワークエレメントは、図5に示されるパケットヘッダ500を構成するフィールドのうちのいくつかを解析する。MANEは、例えば、受信パケットコンテンツのロスおよび提示順序を検出するために、“temporal_id”と呼ばれ、NALヘッダ570に含まれるシンタックスエレメント、または、RTPヘッダ540に含まれる復号順序番号を解析することができる。ルータ(ネットワーク要素)は、ネットワークのスループットをより高くするために、パケットをできる限り速く処理する。このようなルータの論理回路は、ネットワークエレメント処理の複雑性を低く抑えるために、パケットヘッダ内のフィールドに素早くシンプルにアクセスする必要がある。 NALUはパケットヘッダ500内にカプセル化されている。NALUは、スライスヘッダが存在する場合、スライスデータを含んでいてもよい。

0104

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

0105

図6は、スライスヘッダのシンタックス600の一例を示す図である。dependent_slice_flag601は、スライスが依存スライスであるか否かを示すシンタックスエレメントである。このシンタックスエレメントは、スライス間の依存性を識別するために用いることができる。しかしながら、スライスヘッダは、NALUのコンテンツである。dependent_slice_flag601の前にシンタックスエレメントを解析するためには、かなり複雑な論理回路が必要とされる。これは、下記に示されるように、通常のルータでは効率的に考慮できないレベルである。

0106

上述したように、NALUは、パラメータセットのように、複数のスライスに共通の情報を含む、あるいは、スライスヘッダに含まれる復号に必要な情報を有する符号化されたスライスを直接含む。図6には、エントロピースライスまたは依存スライスに用いられるスライスヘッダのシンタックスの一例が示されている。図6は、スライスヘッダ構造を示すテーブルである。シンタックスエレメント“dependent_slice_fla
g”が1に設定される場合は、復号順序において対象スライスに先行する最初の通常スライス(エントロピースライスでも依存スライスでもないスライス)までの全てのスライスが必要になる。これらのスライスが復号されていない場合、一般的に、対象依存スライスは復号できない。但し、特別な場合、例えば、信号伝達または導出された他の補助情報を利用することが可能な場合には、依存スライスを復号できる場合がある。シンタックスエレメントdependent_slice_flag601は、スライスヘッダの中央の適切な位置に含まれている。さらに、スライスヘッダは、情報エレメントnum_entry_point_offsets602によって示される対象スライス内のCABACサブストリームの数と、シンタックスエレメントentry_point_offset[i]603によって示されるサブストリームのバイト数とを含む。ここで、情報エレメントnum_entry_point_offsets602は、エントリーポイントの数に対応する。iは、整数であり、特定のエントリーポイント(エントリーポイントのオフセット)を示すインデックスである。entry_point_offset[i]603により示されるサブストリームのバイト数によって、ビットストリーム内でのナビゲーションが簡単になる。

0107

[1−7.ピクチャの依存性]
上述したように、HEVCによる符号化では、複数種類の依存性が用いられる。

0108

図7は、依存スライスでもエントロピースライスでもない通常スライスのみが用いられる場合の依存性(依存度)とその信号伝達を示す図である。図7では、3つのピクチャ710、720、および730を示している。

0109

ピクチャ710は、VCLNALUnit1および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の関係が成り立つ。

0110

0111

temporal_id=1のスライスは、temporal_idの値がより低いスライスに依存する。つまり、この場合のtemporal_idの値は0である。なお、temporal_idは、ピクチャの予測構造を指す。一般的に、例えば、temporal_idが特定の値を有するスライスは、temporal_idの値がより低いスライスまたはtemporal_idの値が同じスライスにのみ依存する。

0112

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

0113

ピクチャ720は、ピクチャ710のベースレイヤに対するエンハンスメントレイヤである。よって、ピクチャ720をピクチャ710の復号後に復号する必要があるという依存性がある。ピクチャ720は、VCLNALUnit3およびVCL NAL Unit4の2つのNALUを有する。ピクチャ710および720は共に、POCの値が0である。これは、ピクチャ710、720が、一度に表示される同じ画像に属することを示す。当該画像は、ベースレイヤとエンハンスメントレイヤとを備えている。

0114

ピクチャ730は、VCLNALUnit5およびVCL NAL Unit6の2つのNALUを含むベースレイヤである。ピクチャ730のPOCの値は1である。これは、ピクチャ(部分)730が、ピクチャ720および710の後に表示されるピクチャであることを意味する。さらに、ピクチャ730は、temporal_idの値が1である。これは、ピクチャ730が、temporal_id=0のピクチャに一時的に依存することを意味する。よって、NALヘッダ内に含まれて信号送信された依存性に基づき、ピクチャ730はピクチャ710に依存する。

0115

図8は、依存スライスとエントロピースライスとが用いられる場合の依存性(依存度)とその信号伝達を示す図である。図8では、3つのピクチャ810、820、および830を示している。図8は、スライスヘッダ内に含まれて信号送信された依存スライスおよびエントロピースライスの依存性が追加されている点で、上記図7とは異なる。

0116

ここで、図7では、ピクチャ710および720の例を用いてレイヤ間の依存性を示している。さらに、ピクチャ710および730の例を用いて時間的依存性を示している。これらの依存性は共に、NALヘッダ内に含まれて信号送信される。

0117

これに対し、図8に示されるスライス間の依存性は、依存スライスおよびエントロピースライスに固有のものである。特に、ベースレイヤのフレーム810およびエンハンスメントレイヤのフレーム820は共に2つのスライスを有する。2つのスライスのうちの1つは親スライス(通常スライス)であり、もう1つは(依存スライス)である。フレーム810において、VCLNALUnit1のスライスは、VCL NAL Unit2の親スライスである。フレーム820において、VCL NAL Unit3のスライスは、VCL NAL Unit4の親スライスである。上述したように、依存スライスの「親スライス」とは、当該依存スライスの依存先スライス、つまり、そのスライスヘッダ情報が当該依存スライスによって使用されるスライスを指す。これは、最初のスライスは、完全なヘッダを有する先行スライスであるというルールに従っている。完全なヘッダを有するスライスとは、例えば、他の依存スライスではなく、通常スライスである。

0118

現在のHEVC、特にHM8.0において採用されているNALユニットヘッダおよびスライスヘッダに対応するシンタックスについて、図9Aを用いて説明する。

0119

図9Aは、NALユニットヘッダ910のシンタックスおよびスライスヘッダ920のシンタックスを示す図である。なお、レイヤ間の依存性は、シンタックスエレメントnuh_reserved_zero_6bitsを用い、NALユニットヘッダ内に含ませて信号送信されることが(最新の標準化において)計画されている。時間的依存性は、シンタックスエレメントnuh_temporal_id_plus1を用いて信号送信される。スライスヘッダ920は、スライス間の依存性のインジケータを示す信号を含む。スライス間の依存性のインジケータは、シンタックスエレメントdependent_slice_flagによって示される。つまり、スライス間の依存性(例えば、時間的依存性)は、スライスヘッダ内のどこかの位置に含まれて信号送信される。

0120

このシンタックスエレメントを解析するためには、dependent_slice_flagに先行する全てのシンタックスエレメントが、dependent_slice_flagに先行するスライスヘッダのシンタックスエレメントの解析に必要なパラメータセットのシンタックスエレメントと同様に、解析されなければならない。

0121

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

0122

よって、上述した情報は、NALヘッダ570内に含まれて信号送信される。しかしながら、図9Aに示すNALヘッダおよびスライスヘッダの場合、スライスの依存性を示す情報にアクセスするには、PPSおよびSPSといった追加的パラメータセットの経過を追跡記録する必要がある。一方、これは、メディアアウェアゲートウェイまたはルータの能力を再利用することになる。図9Aから分かるように、スライスヘッダ920は、dependent_slice_flagまで解析されなければならず、解析されたパラメータはネットワーク動作には役に立たない。

0123

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)

0124

これらのパラメータは、図9Bの右のテーブルに示されており、slice_addressのパラメータの取得に必要である。シンタックスエレメントslice_adressは、可変長符号化されている(図9Aのslice_address、スライスヘッダ920の第2欄(右欄)、記述子“v”の長さを参照)。可変長符号化されたslice_addressのパラメータの長さを知るために、SPSに含まれるこれらのシンタックスエレメントが必要である。しかし、dependent_slice_flagを解析するためには、シンタックスエレメントslice_addressの実際の値は必要ない。解析処理を続けるためには、可変長のシンタックスエレメントの長さが分かれば良い。

0125

したがって、図9Bに示すSPS930に含まれるシンタックスエレメントのうち、ポイント935のシンタックスエレメントまで解析される必要がある。4つのシンタックスエレメントを格納する必要がある。それらは後で、シンタックスエレメントslice_addressの長さを計算する公式に用いられる。

0126

さらに、dependent_slice_flagに先行するdependent_slice_enabled_flagにアクセスするために、図9Cに示されるPPSに含まれるシンタックスエレメントのうち、ポイント945のシンタックスエレメントまで解析される必要がある。図9Cは、PPSに含まれるシンタックスの例を示す図である。なお、図9A〜9Cを参照して解析方法を説明したスライスヘッダ、SPSおよびPPS内のシンタックスエレメントは、通常のルータの動作には必要ない。さらに、シンタックスエレメントのいくつかは可変長符号で符号化されているため、単純にスキップすることはできない。つまり、ビットストリーム内で所定量分のビットをジャンプしても、dependent_slice_enabled_flagまでジャンプすることはできない。

0127

要するに、dependent_slice_flag(依存性インジケーション)を読み出すためには、MANEは、スライスヘッダ(スライスヘッダ920参照)の複雑な解析をさらに進める必要がある。

0128

具体的には、first_slice_in_pic_flagが解析されなければならない。first_slice_in_pic_flagは、スライスがピクチャ内の最初のスライスであるか否かを示すフラグである。

0129

その後、NALUタイプに条件付けられたno_output_of_prior_pics_flagが解析されなければならない。

0130

さらに、可変長符号化されたpic_parameter_set_idが復号されなければならない。pic_parameter_set_idは、複数のパラメータセットのうち、どのパラメータセットを用いるかを示すシンタックスエレメント(パラメータセットを識別するシンタックスエレメント)である。pic_parameter_set_idを解析することで、利用するパラメータセットを特定できる。

0131

最後に、slice_addressが必要である。slice_addressは、スライスの開始位置を示すシンタックスエレメントである。このシンタックスエレメントは、追加的計算とPPSおよびSPSの解析とをさらに必要とする。

0132

最後に、dependent_slice_flagがビットストリーム内に存在するか否かを知るために、dependent_slice_enabled_flag(依存スライス有効化フラグ)の値がPPSから取得されなければならない。dependent_slice_enabled_flag=0は、依存スライスは有効でないため、対象スライスが通常スライスであることを意味する。dependent_slice_enabled_flagの値を取得するために、PPSは真ん中ぐらいまで解析される必要がある。

0133

残念ながら、データ位置が予め定められているRTPヘッダおよびNALヘッダのデータの場合とは異なり、dependent_slice_flagの前に位置するシンタックスエレメントはスキップすることができず、解析される必要がある。これは、スライスヘッダ内のシンタックスエレメントが可変長符号化されているためである。このため、全てのVCLNALユニットについてエレメントの存在および長さが計算される必要がある。加えて、後で必要になるため(PPSおよびSPS参照)、追加的セッションデータが格納される必要がある。さらに、シンタックスエレメントの存在が、他のパラメータ構造に含まれることが想定される他のシンタックスエレメントの存在またはその値に依存するシンタックスエレメントもある(そのシンタックスエレメントは条件付きで符号化される)。

0134

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

0135

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

0136

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

0137

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

0138

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

0139

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

0140

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

0141

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

0142

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

0143

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

0144

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

0145

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

0146

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

0147

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

0148

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

0149

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

0150

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

0151

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

0152

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

0153

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

0154

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

0155

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

0156

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

0157

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

0158

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

0159

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

0160

(実施の形態1)
図10は、本実施の形態におけるビットストリームのシンタックスの例を示す図である。図10に示すNALヘッダ1010は、図9Aに示すNALヘッダ910と同じである。つまり、変更されていない。

0161

しかしながら、スライスヘッダ1020のシンタックス構造は、図9Aのスライスヘッダ920のシンタックス構造とは異なる。スライスヘッダ1020では、特に、dependent_slice_flagが、dependent_slice_flagに先行するシンタックスエレメントがないように、スライスヘッダ内で上方に移動されている。dependent_slice_flagは、条件付きで符号化され、あるいは、可変長符号により符号化され、あるいは、追加の計算を要する解析が行われる。

0162

シンタックスエレメント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の両方で、スライス間の依存性のインジケータと見なすことができる。

0163

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

0164

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

0165

しかしながら、本実施の形態では、dependent_slice_flag(依存性インジケーション)が、シンタックスエレメントdependent_slice_enabled_flag(依存スライス有効化フラグ)を必要条件とせずに符号化される。本実施の形態では、ピクチャパラメータセットidが依存性インジケーションの後に配置されるので、スライスヘッダ内でピクチャパラメータセットidが信号により伝達される場合に起こりうる解析エラーを避けるのに有利である。

0166

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

0167

例えば、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(パラメータセットを識別するシンタックスエレメント)の後に符号化される場合にも役に立ち得る。なぜなら、そうすることによって、依存スライス有効化フラグが依存性インジケーションの存在を必要とする場合でも、解析エラーが回避されるからである。

0168

PPS内で“dependent_slice_enabled_flag”を上方に移動させる代わりに、階層の低いパラメータセットを追跡記録する必要がなくなるように、“dependent_slice_enabled_flag”がPPSからSPSおよび/またはVPSに移動されてもよい。

0169

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

0170

図10から分かるように、NALユニットヘッダは、スライスヘッダの関連する部分と合わせて、18ビットを有する(NALUヘッダ14ビット、スライスヘッダ2ビット)。この例によると、メディアアウェアネットワークエレメントが対象スライスパケットに対して次のように動作してもよい。先行する通常スライス、エントロピースライス、または依存スライスが削除されると、ネットワークエレメントは対象スライスヘッダの初めの2ビット、つまりfirst_slice_in_pic_flagおよび(依存スライスがビットストリームに許容される場合)dependent_slice_flagをチェックする。

0171

NALユニットタイプがVCL NALユニットタイプであり、チェックされた18ビットの最後の2ビットが“01”であれば、そのNALユニットは削除される。特に、スライスヘッダの先頭のビットが“1”であれば、それは、(ルールによれば)ピクチャの先頭の依存スライスでないスライスである。スライスヘッダの先頭のビットが“0”であり、次のビットも“0”であれば、そのスライスは独立している。したがって、スライスヘッダの先頭の2ビットが”01”である場合にのみ、そのスライスは依存している。さらに、当該スライスは、親スライスが既に削除されているときは、復号できないため、削除されなければならない。よって、first_slice_in_pic_flagおよびdependent_slice_flagは、スライスヘッダシンタックスに属していても、NALヘッダの拡張であると見なすことができる。

0172

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

0173

(実施の形態2)
本実施の形態2によれば、dependent_slice_enabled_flagがPPSから削除されている。なお、dependent_slice_enabled_flagは、削除するのではなく、SPSに移動させてもよい。

0174

図11は、first_slice_in_pic_flagおよびdependent_slice_flagにアクセスする前に、dependent_slice_enabled_flagを解析する必要がない例を示す図である。

0175

この例では、dependent_slice_enabled_flagは、依存性インジケーションの存在を必要条件としないため、用いられない。この例は、対象PPSセットの識別が分からないことに起因する解析上の問題を引き起こすことなく、スライスヘッダの先頭に依存性インジケーションを配置する可能性を提供する。

0176

(実施の形態2の効果等)
実施の形態1では、dependent_slice_flagを解析するためには、dependent_slice_enabled_flagを解析しなければならない。dependent_slice_enabled_flagは、PPS内に含まれて信号により伝達される。これは上述の通り、dependent_slice_enabled_flagがPPSの初めから遠い位置にあり、かつ先行するシンタックスエレメントが条件付きで符号化される場合に、解析のオーバーヘッドをもたらす可能性がある。

0177

さらに、PPSにおいてシンタックスエレメントpic_parameter_set_idが解析される前にシンタックスエレメントdependent_slice_flagを信号により伝達すると、次のような解析エラーが発生し得る。dependent_slice_flagの存在は、PPS内に含まれて信号により伝達されるdependent_slice_enabled_flagに依存する。しかしながら、現在有効なPPSのidは、dependent_slice_flagの後に信号により伝達される。したがって、先行するエレメントにアクセスする前にdependent_slice_flagを解析することはできない。

0178

本実施の形態では、dependent_slice_enabled_flagを必要条件とする解析を取り除くため、有益である。以下の制限を適用すると、さらに有益である。つまり、PPS内のdependent_slice_enabled_flagがゼロであれば、dependent_slice_flagはゼロになる。

0179

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

0180

(実施の形態1および2の変形例1)
dependent_slice_enabled_flagを取り除く代わりに、または、それに追加的に、dependent_slice_enabled_flagをPPSからSPSおよび/またはVPSの何れかに移動させてもよい。

0181

さらに、単にdependent_slice_enabled_flagを移動させる代わりに、dependent_slice_enabled_flagをSPSに複写させてもよい。この場合、SPSおよびPPS内のインジケータは、強制的に同じ値としてもよい。もしくは、PPSはSPS内のインジケータの上書きを許可されてもよい。

0182

例えば、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の追跡記録および解析の頻度が低くなるという効果が防げられる。

0183

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

0184

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

0185

dependent_slice_enabled_flagがVPSおよび/またはSPSにおいて信号により伝達される場合、2つの効果がある。フラグが単に移動または複写されている場合は、PPSは解析される必要がなく、その結果、解析のオーバーヘッドが削減される。もう一つの利点は、ルータに映像シーケンスの予測構造を知らせることができる点である。この効果は常にある。通常、ルータは、何を受信するかを知るために、VPS/SPSの内容を確認してもよい。

0186

VPSは、階層において最上位のパラメータである。SPSおよびPPSはそれぞれ1つの映像シーケンスおよび1つのピクチャに対応するのに対して、VPSは複数の映像シーケンスに関する情報を含むことができる。VPSに含まれる情報は、ビットレートあるいは映像シーケンスのtemporal_layering構造等である。また、レイヤ間の依存性(異なる映像シーケンス間の依存性)に関する情報を含む。よって、VPSを、複数の映像シーケンスの入れ物としてみなすことができ、VPSにより、各シーケンスの概要が分かる。

0187

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

0188

しかしながら、この解決法は、符号化効率の低下につながる。したがって、上述の通り、スライス間依存性の信号による伝達を有効にする効率的な解析が採用されてもよい。これは、NALヘッダの直後のスライスヘッダ内において、dependent_slice_flagおよびfirst_slice_in_pic_flagを信号により伝達することによって達成される。

0189

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

0190

(実施の形態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を含む。

0191

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

0192

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

0193

上記実施の形態では、dependent_slice_flagの存在を必要条件としてfirst_slice_in_pic_flagが含まれる場合について説明したが、first_slice_in_pic_flagおよびdependent_slice_flagは、共に、互いの存在を必要条件とせずにビットストリームに含まれてもよい。例えば、上記の変形例のうちの1つおいて、シンタックスエレメントdependent_slice_enabled_flagから独立させるために、dependent_slice_flagの符号化方法を変更する。

0194

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

0195

具体的には、本実施の形態のスライスヘッダでは、図6に示す従来のスライスヘッダと比較して、dependent_slice_flagが、slice_addressの前に配置されている。さらに、本実施の形態のスライスヘッダでは、図10図12に示す例と比較して、dependent_slice_flagが、pic_parameter_set_idの後に配置されている。

0196

本実施の形態では、dependent_slice_flagがslice_addressの前に配置されているので、dependent_slice_flagを解析するのに、少なくともSPSを解析する必要がない。上述したように、slice_addressは、スライスの開始を示すシンタックスエレメントである。さらに、slice_addressは、SPS内に含まれて信号により伝達されたシンタックスエレメント(pic_parameter_set_id)の助けによってのみ解析できる。

0197

その代わりに、またはそれに加えて、dependent_slice_enabled_flagはPPS内で上方に移動されるか、SPSおよび/またはVPSに移動される。有効化フラグがVPSおよび/またはSPS内にある場合は、解析ならびにPPSおよびSPSの追跡記録が必要としなくてもよい。

0198

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

0199

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

0200

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

0201

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

0202

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

0203

(4)また、本実施の形態において、VPS_idおよびSPS_idを、SEIメッセージ内に含めて明示的に信号により伝達するように構成してもよい。dependent_slice_enabled_flagがSPS内に含まれて信号により伝達される場合、dependent_slice_flagは依然としてpic_parameter_set_idに後続しなければならない。

0204

そうしなければ、SPS_idがPPS内に含まれて信号により伝達されることから、解析において依存性が導入される。dependent_slice_enabled_flagを保持する対象SPSまたはVPSの識別を信号により伝達することによって、その後のピクチャパラメータセットの解析が不要であるため、依存性インジケーションをpic_parameter_set_idの前に含めてもよい。さらに、VPS_idまたはSPS_idを保持するSEIメッセージは、それらのIDもPPSを解析することによって決定されるので、復号処理に不要である。よって、SEIメッセージは、ネットワークエレメントに使用された後に、復号処理に影響することなく削除できる。

0205

(実施の形態4)
本実施の形態4では、スライス間依存性の情報が、SEIメッセージのような他のNALユニットに(スライスヘッダおよび/またはパラメータセット内に含まれて信号により伝達された情報の補足に)複写される。

0206

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

0207

最新のHEVC仕様書において、アクセスユニットは復号順に連続したNALユニットのセットとして定義され、きっちり1つの符号化ピクチャを含む。符号化ピクチャの符号化スライスNALユニットに加えて、アクセスユニットは、符号化ピクチャのスライスを含まない他のNALユニットも含んでもよい。アクセスユニットの復号は、常に、復号ピクチャをもたらす。しかしながら、HEVCの将来の拡張において(マルチビュー符号化(MVC)またはスケーラブル映像符号化(SVC)のように)、アクセスユニットの定義は緩和/修正されてもよい。最新の仕様書によれば、アクセスユニットは、アクセスユニットデリミター、SEIメッセージ、およびVCLNALUによって形成されている。

0208

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

0209

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

0210

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

0211

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

0212

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

0213

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

0214

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

0215

図14は、図9Aに示すNALユニットヘッダ910を修正したNALユニットヘッダ1410の例を示す図である。NALユニットヘッダ1410は、dependent_slice_flagを含む。

0216

さらに、dependent_slice_flagをNALヘッダに移動させ、後方互換性のためNALヘッダのサイズを固定し続けるために、NALユニットヘッダのシンタックスエレメントnuh_reserved_zero_6bitsからdependent_slice_flagに必要な1ビットが取得される。よって、シンタックスエレメントnuh_reserved_zero_6bitsは、現在5ビットのみを有する。シンタックスエレメントnuh_reserved_zero_6bitsは、ビットの減少が何ら問題を起こさず、さらなる修正を要しないように、後で用いるための予備のビットを有する。

0217

一般的に、対象VCLNALユニットは、同一のtemporal_layer_idを有する先行するVCL NALユニットに依存する。dependent_slice_flagがNALヘッダ内に含まれて信号により伝達されている場合は、ピクチャスライスまたはパラメータセットといった全てのデータユニットが同じNALヘッダを有するため、VCLおよび非VCL NALユニットの両方に1ビットが浪費される。よって、dependent_slice_flagも、パラメータセットまたはSEIメッセージに用いられるように信号により伝達されると思われるが、それは不必要である。さらに、依存スライスがシーケンスパラメータセット内で無効になっても、dependent_slice_flagは、常に信号による伝達が必要である。これは不必要なオーバーヘッドにつながる。

0218

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

0219

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

0220

よって、新たな(別個の)VCLNALタイプが、既存のVCLNALユニットのように、類似の記号論で定義される。例えば、NAL_unit_typeの値が15に(または他の予め定義されたタイプ、または他の特定タイプのNALUのために保存されていないNALUに)等しければ、対象VCL NALユニットは同一のtemporal_layer_idを有する先行VCL NALユニットに依存する。その依存性は、上述の通り、先行スライスのスライスヘッダに対する対象スライスの依存性、つまり解析における依存性に関連する。

0221

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

0222

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

0223

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

0224

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

0225

RAPPicFlagの値は、以下の式2のようにNALユニットタイプに依存する。

0226

0227

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

0228

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

0229

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

0230

上述した例のNALユニットタイプ“DS_NUT”は、処理対象VCLnalユニットが依存スライスであることを示すために用いられる。非特許文献3に記載されている最新のスライスヘッダのシンタックス構造と比較すると、本実施の形態では、下記の2つの変更が導き出される。

0231

(1)no_output_of_prior_pics_flagが、依存スライスに含まれていない。言い換えると、no_output_of_prior_pics_flagは、処理対象スライスが依存スライスではない場合に存在する。(処理対象スライスが依存スライスではない場合に、no_output_of_prior_pics_flagはスライスヘッダに存在する。)

0232

(2)first_slice_in_pic_flagが、nal_unit_typeの値に応じて含まれる。nal_unit_typeの値が、処理対象スライスが依存スライスであることを示す場合、シンタックスの要素first_slice_in_pic_flagは明示的に含まれず、0になると推測される。これは、同じ品質でビットレートを維持する。

0233

上述した例によれば、処理対象スライスが依存スライスである場合、no_output_of_prior_pics_flagは含まれない。RapPicFlagの値は、処理対象スライスが依存スライスである場合、評価の為に必要とされない。このため、依存スライスのスライスヘッダは、問題無く評価できる。さらに依存スライスのスライスヘッダは、先行するnalユニットヘッダのNALユニットヘッダを参照することなく、解析することができる。先行するnalユニットヘッダが復号時に存在しない場合は、問題が生じる。

0234

次に、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が含められる。

0235

上述した2つの変更は、同時に行う必要は無い。また、スライスヘッダにおいて、一方の変更のみを行ってもよい。各変更の利点は、スライスが依存スライスであるか否かのチェックコストに関連する。しかし、2つの変更が同時に実行された場合、2つのシンタックスエレメントfirst_slice_in_pic_flagおよびno_output_of_prior_pics_flagが連続してコーディング(符号化)されている場合は、2つの変更の利点は、個々に変更した場合の個々の利点と同じになる。従って、2つの変更と、2つのシンタックスエレメントの連続したコーディングとを組み合わせたアプリケーションでは、個々の変更を個別に行うアプリケーションよりも利点がある。

0236

実施の形態の説明の全てにおいて、依存スライスの指標が条件付きで符号化されていない場合は、ビットストリームからdependent_slice_enabled_flagを削除することが可能である。言い換えると、新しいNALユニットタイプを処理対象スライスが依存スライスであることを示すために用いるなら、ビットストリームからdependent_slice_enabled_flagを削除することができる。

0237

図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の関係が成り立つ。

0238

0239

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

0240

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

0241

(実施の形態8)
図16は、代替的な解決法を示す図である。NALユニットヘッダ1610は、NALユニットヘッダ910と同じである。スライスヘッダ1620では、NAL_unit_typeが、上述したような依存スライスを定義する値15および16を有すると仮定している。

0242

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

0243

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

0244

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

0245

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

0246

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

0247

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

0248

なお、上記実施の形態1〜8では、wavefrontを前提として説明したが、これに限るものではない。

0249

但し、wavefrontの場合、全てのサブストリームを同時に開始することはできない。上述したように、先頭のサブストリーム以外の各サブストリームについては、処理(符号化または復号)の開始が、先行するサブストリームよりもLCU2つ分遅れることになる。このため、wavefrontでは、より処理の短縮が求められている。本実施の形態では、依存性インジケーション(dependent_slice_flag)を、PPSを識別するシンタックスの後、スライスアドレスの前に配置することで、解析するシンタックスエレメントの数を減らすことができ、処理を短縮することが可能になる。

0250

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

0251

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

0252

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

0253

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

0254

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

0255

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

0256

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

0257

このコンテンツ供給システムex100は、インターネットex101にインターネットサービスプロバイダex102および電話網ex104、および基地局ex106からex110を介して、コンピュータex111、PDA(Personal Digital Assistant)ex112、カメラex113、携帯電話ex114、ゲーム機ex115などの各機器が接続される。

0258

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

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

該当するデータがありません

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

(分野番号表示ON)※整理標準化データをもとに当社作成

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

該当するデータがありません

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ