JPWO2015105003A1 - 復号装置および復号方法、並びに、符号化装置および符号化方法 - Google Patents
復号装置および復号方法、並びに、符号化装置および符号化方法 Download PDFInfo
- Publication number
- JPWO2015105003A1 JPWO2015105003A1 JP2015556767A JP2015556767A JPWO2015105003A1 JP WO2015105003 A1 JPWO2015105003 A1 JP WO2015105003A1 JP 2015556767 A JP2015556767 A JP 2015556767A JP 2015556767 A JP2015556767 A JP 2015556767A JP WO2015105003 A1 JPWO2015105003 A1 JP WO2015105003A1
- Authority
- JP
- Japan
- Prior art keywords
- unit
- encoding
- image
- tier
- decoding
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
- H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
- H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
- H04N19/115—Selection of the code volume for a coding unit prior to coding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
- H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
- H04N19/157—Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
- H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
Abstract
本開示は、最低限の圧縮率を調整することができるようにする復号装置および復号方法、並びに、符号化装置および符号化方法に関する。復号部は、画像を符号化する際の最低圧縮率がメインティアとハイティアのそれぞれに対して設定されたプロファイルを有するH.265/HEVC規格に従って符号化されたビットストリームを、再帰的に分割されたCU（Coding Unit）を単位として、復号する。本開示は、例えば、HEVC（High Efficiency Video Coding）方式の復号装置等に適用することができる。
Description
本開示は、復号装置および復号方法、並びに、符号化装置および符号化方法に関し、特に、最低限の圧縮率を調整することができるようにした復号装置および復号方法、並びに、符号化装置および符号化方法に関する。
近年、MPEG-4 Part10 （Advanced Video Coding、以下AVCと記す）より更なる符号化効率の向上を目的として、ITU-T（International Telecommunication Union Telecommunication Standardization Sector）と、ISO/IEC（International Organization for Standardization / International Electrotechnical Commission）の共同の標準化団体であるJCTVC（Joint Collaboration Team - Video Coding）により、HEVC（High Efficiency Video Coding）と呼ばれる符号化方式の標準化が進められている（例えば、非特許文献１参照）。
また、HEVCにおいて、4:2:2や4:4:4といった色差信号フォーマットの画像や、スクリーンコンテンツ用のプロファイル等、例えばハイエンド向けのフォーマットをサポートするようにレンジエクステンションの検討が行われている（例えば、非特許文献２参照）。
Benjamin Bross,Gary J.Sullivan,Ye-Kui Wang,"Editors’ proposed corrections to HEVC version 1",JCTVC-M0432_v3,2013.4.25
David Flynn,Joel Sole,Teruhiko Suzuki,"High Efficiency Video Coding(HEVC),Range Extension text specification:Draft 4",JCTVC-N1005_v1,2013.8.8
ところで、HEVC方式では、各プロファイルで規定された復号するために必要なツール（要素技術）の制約を規定するものとして、レベル（Level）とティア（Tier）が存在する。レベルは、符号化対象の画像のサイズ（解像度）の最大値を規定するものであり、ティアは、符号化対象の画像のビットレートの最大値を規定するものである。HEVC方式では、サイズが同一であるがビットレートが異なる画像が多数扱われるため、復号するために必要なツールがレベルとティアの２軸によって規定される。また、レベルごとに、最低限の圧縮率を表すMinCrが設定される。
しかしながら、最低限の圧縮率を調整して、その符号化ストリームに適応させることは考えられていなかった。
本開示は、このような状況に鑑みてなされたものであり、最低限の圧縮率を調整することができるようにするものである。
本開示の第１の側面の復号装置は、画像を符号化する際の最低圧縮率が複数のティアのそれぞれに対して設定されたプロファイルを有する符号化規格に従って符号化されたビットストリームを、再帰的に分割されたブロックを単位として、復号する復号部を備える復号装置である。
本開示の第１の側面の復号方法は、本開示の第１の側面の復号装置に対応する。
本開示の第１の側面においては、画像を符号化する際の最低圧縮率が複数のティアのそれぞれに対して設定されたプロファイルを有する符号化規格に従って符号化されたビットストリームが、再帰的に分割されたブロックを単位として、復号される。
本開示の第２の側面の符号化装置は、画像を符号化する際の最低圧縮率が複数のティアのそれぞれに対して設定されたプロファイルを有する符号化規格に従って、再帰的に分割されたブロックを単位として、画像を符号化する符号化部を備える符号化装置である。
本開示の第２の側面の符号化方法は、本開示の第２の側面の符号化装置に対応する。
本開示の第２の側面においては、画像を符号化する際の最低圧縮率が複数のティアのそれぞれに対して設定されたプロファイルを有する符号化規格に従って、再帰的に分割されたブロックを単位として、画像が符号化される。
なお、第１の側面の復号装置および第２の側面の符号化装置は、コンピュータにプログラムを実行させることにより実現することができる。
また、第１の側面の復号装置および第２の側面の符号化装置を実現するために、コンピュータに実行させるプログラムは、伝送媒体を介して伝送することにより、又は、記録媒体に記録して、提供することができる。
第１の側面の復号装置および第２の側面の符号化装置は、独立した装置であっても良いし、１つの装置を構成している内部ブロックであっても良い。
本開示の第１の側面によれば、符号化ストリームを復号することができる。また、本開示の第１の側面によれば、最低限の圧縮率が調整された符号化ストリームを復号することができる。
本開示の第２の側面によれば、画像を符号化することができる。また、本開示の第２の側面によれば、最低限の圧縮率を調整することができる。
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
＜本開示の概要＞
（ティアとレベルの説明）
図１は、HEVC方式においてレベルとティアにより規定される制約を説明する図であり、図２は、プロファイルがMainとMain10である場合にレベルとティアにより規定される固有の制約を説明する図である。
（ティアとレベルの説明）
図１は、HEVC方式においてレベルとティアにより規定される制約を説明する図であり、図２は、プロファイルがMainとMain10である場合にレベルとティアにより規定される固有の制約を説明する図である。
図１および図２に示すように、HEVC方式では、レベルごとに、符号化対象の画像の最大サイズ（Max luma picture size）が規定される。また、レベル４以上の各レベルでは、同一のレベル内でティアによって異なるビットレートの最大値を表す情報（Max CPB size,MaxBR）が規定される。ティアとしては、放送などのアプリケーション用の比較的低いビットレートを規定するメインティア（Main tier）と、映像制作や蓄積メディアへの記録などのアプリケーション用の比較的高いビットレートを規定するハイティア（High tier）がある。また、図２に示すように、レベルごとにMinCrが設定される。
しかしながら、ハイティアでは、ビットレートが高いため、符号化ストリームの圧縮率がMinCrより大きくなる場合がある。この場合、圧縮率がMinCrより低くなるように符号化をやり直す必要がある。HEVC規格で用いられているコンテキストを用いた算術符号化（CABAC）は、周辺の状態をコンテキストとして保存しながら行われる。従って、コーディングユニットレベルでリトライが必要になると、そのコンテキストの状態を全て保存しながらリトライする必要がある。よって、特にCABACの場合、リトライによる算術符号化に伴う演算負荷が大きく、システムに与える負荷が大きい。
また、HEVC方式におけるティアは、メインティアとハイティアの２つであり、よりビットレートの高い符号化ストリームを生成することができない。しかしながら、医療画像などに対してVisually loss less圧縮やloss less圧縮、ロー圧縮を行うアプリケーションを考えた場合、ハイティアより高いビットレートに対応するティアが必要とされる。
そこで、本開示では、最低限の圧縮率およびティアに対応するビットレートの最大値を調整することを識別する識別データを設定し、その識別データに基づいて、MinCrおよびビットレートの最大値を調整する。
＜第１実施の形態＞
（符号化装置の第１実施の形態の構成例）
図３は、本開示を適用した符号化装置の第１実施の形態の構成例を示すブロック図である。
（符号化装置の第１実施の形態の構成例）
図３は、本開示を適用した符号化装置の第１実施の形態の構成例を示すブロック図である。
図３の符号化装置１０は、設定部１１、符号化部１２、制御部１３、および伝送部１４により構成され、画像をHEVC方式に準ずる方式で符号化する。
具体的には、符号化装置１０の設定部１１は、SPS（Sequence Parameter Set）,PPS（Picture Parameter Set），VUI(Video Usability Information),SEI（Supplemental Enhancement Information）などのパラメータセットを設定する。SPSやVPSには、識別データ、レベルやティアを表す情報などを含むprofile_tier_levelが設定される。設定部１１は、設定されたパラメータセットを符号化部１２と制御部１３に供給する。
符号化部１２には、フレーム単位の画像が入力される。符号化部１２は、制御部１３の制御にしたがって、入力された画像をHEVC方式で符号化する。符号化部１２は、符号化の結果得られる符号化データと設定部１１から供給されるパラメータセットから符号化ストリームを生成し、伝送部１４に供給する。
制御部１３は、設定部１１から供給されるprofile_tier_levelに含まれる情報が表すレベルに対応するMinCrと識別データに基づいて、最低限の圧縮率を算出する。また、制御部１３は、profile_tier_levelに含まれる情報が表すティアに対応するビットレートの最大値と識別データに基づいて、ビットレートの最大値を算出する。制御部１３は、最低限の圧縮率とビットレートの最大値に基づいて、符号化部１２による符号化を制御する。
具体的には、制御部１３は、符号化データの圧縮率が最低限の圧縮率より高いかどうかを判定させ、符号化データの圧縮率が最低限の圧縮率以下である場合、最低限の圧縮率より高くなるように、符号化をやり直させる。
伝送部１４は、符号化部１２から供給される符号化ストリームを、後述する復号装置に伝送する。
（profile_tier_levelのシンタクスの例）
図４は、profile_tier_levelのシンタクスの例を示す図である。
図４は、profile_tier_levelのシンタクスの例を示す図である。
図４に示すように、profile_tier_levelには、ティアがメインティアであるか、ハイティアであるかを表すティアフラグ（general_tier_flag）が設定される。また、profile_tier_levelには、ビットレートが低いかどうかを表す低ビットレートフラグ（general_lower_bit_rate_constraint_flag）と識別データ（general_higher_bit_rate_indication_flag）が設定される。
低ビットレートフラグは、ビットレートが低いことを表す場合１であり、ビットレートが低くはないことを表す場合０である。また、識別データは、最低限の圧縮率およびティアに対応するビットレートの最大値を調整することを表す場合１であり、調整しないことを表す場合０である。
さらに、profile_tier_levelには、レベルを表すレベル情報（general_level_idc）が設定される。
（ビットレートの最大値および最低限の圧縮率の算出に用いられるパラメータの第１の例）
図５は、ビットレートの最大値および最低限の圧縮率の算出に用いられるパラメータの第１の例を示す図である。
図５は、ビットレートの最大値および最低限の圧縮率の算出に用いられるパラメータの第１の例を示す図である。
ビットレートの最大値は、パラメータCpbBrVclFactorまたはCpbBrNalFactorを用いて、以下の式（３）により算出される。
式（３）において、Maxbitrateは、ビットレートの最大値であり、MaxBRは、profile_tier_levelに含まれるレベル情報とティアフラグに対応する図２に示したビットレートの最大値を表す情報である。
また、最低限の圧縮率は、パラメータMinCrScaleFactorを用いて以下の式（４）により算出される。
式（４）において、MinCrは、最低限の圧縮率であり、MinCrBaseは、profile_tier_levelに含まれるレベル情報とティアフラグに対応する図２に示したMinCrである。
ビットレートの最大値の算出に用いられるパラメータCpbBrVclFactorまたはCpbBrNalFactor、および、最低限の圧縮率の算出に用いられるパラメータMinCrScaleFactorは、図５に示すようにプロファイルごとに設定される。
図５の例では、パラメータCpbBrVclFactorおよびCpbBrNalFactorは、パラメータHbrFactorおよびパラメータShFactorにより調整され、パラメータMinCrScaleFactorは、パラメータHbrFactorにより調整される。
パラメータHbrFactorは、profile_tier_levelに含まれる低ビットレートフラグ（general_lower_bit_rate_constraint_flag）と識別データ（general_higher_bit_rate_indication_flag）を用いて、以下の式（５）で定義される。
パラメータShFactorは、profile_tier_levelに含まれる低ビットレートフラグ（general_lower_bit_rate_constraint_flag）と識別データ（general_higher_bit_rate_indication_flag）を用いて、以下の式（６）で定義される。
（パラメータHbrFactorおよびShFactorの第１の例）
図６は、プロファイルがLong Gop profilesおよびAll Intra profilesである場合に図５のパラメータを調整するパラメータHbrFactorおよびShFactorの例を示す図である。
図６は、プロファイルがLong Gop profilesおよびAll Intra profilesである場合に図５のパラメータを調整するパラメータHbrFactorおよびShFactorの例を示す図である。
なお、スーパーハイティア（Super High Tier）とは、ビットレートの最大値がハイティアより高くされた仮想のティアである。
図６に示すように、プロファイルがLong Gop profilesであり、ティアがメインティアである場合、ティアフラグ（general_tier_flag）は０に設定される。また、低ビットレートフラグ（general_lower_bit_rate_constraint_flag）は１に設定され、識別データ（general_higher_bit_rate_indication_flag）は０に設定される。従って、パラメータHbrFactorは１となり、ShFactorは１となる。
その結果、ビットレートの最大値および最低限の圧縮率は、それぞれ、メインティアに対応するビットレートの最大値、MinCrが表す最低限の圧縮率となり、ビットレートの最大値および最低限の圧縮率は調整されない。
一方、プロファイルがLong Gop profilesであり、ティアがハイティアである場合、ティアフラグ（general_tier_flag）は１に設定される。また、低ビットレートフラグ（general_lower_bit_rate_constraint_flag）は１に設定され、識別データ（general_higher_bit_rate_indication_flag）は１に設定される。従って、パラメータHbrFactorは２となり、ShFactorは１となる。
その結果、ビットレートの最大値は、メインティアに対応するビットレートの最大値となり、調整されないが、最低限の圧縮率は、MinCrが表す最低限の圧縮率の1/2となる。
また、プロファイルがLong Gop profilesであり、ティアがスーパーハイティアである場合、ティアフラグ（general_tier_flag）は１に設定される。また、低ビットレートフラグ（general_lower_bit_rate_constraint_flag）は０に設定され、識別データ（general_higher_bit_rate_indication_flag）は１に設定される。従って、パラメータHbrFactorは４となり、ShFactorは４となる。
その結果、ビットレートの最大値は、メインティアに対応するビットレートの４倍となり、最低限の圧縮率は、MinCrが表す最低限の圧縮率の1/4となる。
プロファイルがAll Intra profilesであり、ティアがメインティアである場合、ティアフラグ（general_tier_flag）は０に設定される。また、低ビットレートフラグ（general_lower_bit_rate_constraint_flag）は０または１に設定され、識別データ（general_higher_bit_rate_indication_flag）は０に設定される。従って、パラメータHbrFactorは２または１となり、ShFactorは２または１となる。
その結果、ビットレートの最大値は、メインティアに対応するビットレートの２倍となり、最低限の圧縮率は、MinCrが表す最低限の圧縮率の1/2となるか、または、両方とも調整されない。
一方、プロファイルがAll Intra profilesであり、ティアがハイティアである場合、ティアフラグ（general_tier_flag）は１に設定される。また、低ビットレートフラグ（general_lower_bit_rate_constraint_flag）は０または１に設定され、識別データ（general_higher_bit_rate_indication_flag）は１に設定される。従って、パラメータHbrFactorは４または２となり、ShFactorは４または２となる。
その結果、ビットレートの最大値は、メインティアに対応するビットレートの４倍または２倍となり、最低限の圧縮率は、MinCrが表す最低限の圧縮率の1/4または1/2となる。
また、プロファイルがAll Intra profilesであり、ティアがスーパーハイティアである場合、ティアフラグ（general_tier_flag）は１に設定される。また、低ビットレートフラグ（general_lower_bit_rate_constraint_flag）は０に設定され、識別データ（general_higher_bit_rate_indication_flag）は１に設定される。従って、パラメータHbrFactorは４となり、ShFactorは４となる。
その結果、ビットレートの最大値は、メインティアに対応するビットレートの４倍となり、最低限の圧縮率は、MinCrが表す最低限の圧縮率の1/4となる。
（符号化部の構成例）
図７は、図３の符号化部１２の構成例を示すブロック図である。
図７は、図３の符号化部１２の構成例を示すブロック図である。
図７の符号化部１２は、A/D変換部３１、画面並べ替えバッファ３２、演算部３３、直交変換部３４、量子化部３５、可逆符号化部３６、蓄積バッファ３７、生成部３８、逆量子化部３９、逆直交変換部４０、および加算部４１を有する。また、符号化部１２は、デブロックフィルタ４２、適応オフセットフィルタ４３、適応ループフィルタ４４、フレームメモリ４５、スイッチ４６、イントラ予測部４７、動き予測・補償部４８、予測画像選択部４９、およびレート制御部５０を有する。
符号化部１２のA/D変換部３１は、符号化対象として入力されたフレーム単位の画像をA/D変換する。A/D変換部３１は、変換後のデジタル信号である画像を画面並べ替えバッファ３２に出力して記憶させる。
画面並べ替えバッファ３２は、記憶した表示の順番のフレーム単位の画像を、GOP構造に応じて、符号化のための順番に並べ替える。画面並べ替えバッファ３２は、並べ替え後の画像を、演算部３３、イントラ予測部４７、および動き予測・補償部４８に出力する。
演算部３３は、画面並べ替えバッファ３２から供給される画像から、予測画像選択部４９から供給される予測画像を減算することにより符号化を行う。演算部３３は、その結果得られる画像を、残差情報として直交変換部３４に出力する。なお、予測画像選択部４９から予測画像が供給されない場合、演算部３３は、画面並べ替えバッファ３２から読み出された画像をそのまま残差情報として直交変換部３４に出力する。
直交変換部３４は、演算部３３からの残差情報をＴＵ（transform unit）単位で直交変換する。直交変換部３４は、直交変換の結果得られる直交変換係数を量子化部３５に供給する。
量子化部３５は、直交変換部３４から供給される直交変換係数に対して量子化を行う。量子化部３５は、量子化された直交変換係数を可逆符号化部３６に供給する。
可逆符号化部３６は、最適イントラ予測モードを示すイントラ予測モード情報をイントラ予測部４７から取得する。また、可逆符号化部３６は、最適インター予測モードを示すインター予測モード情報、動きベクトル、参照画像を特定する情報などを動き予測・補償部４８から取得する。
また、可逆符号化部３６は、適応オフセットフィルタ４３からオフセットフィルタに関するオフセットフィルタ情報を取得し、適応ループフィルタ４４からフィルタ係数を取得する。
可逆符号化部３６は、量子化部３５から供給される量子化された直交変換係数に対して、可変長符号化（例えば、CAVLC（Context-Adaptive Variable Length Coding）など）、算術符号化（例えば、CABAC（Context-Adaptive Binary Arithmetic Coding）など）などの可逆符号化を行う。
また、可逆符号化部３６は、イントラ予測モード情報、または、インター予測モード情報、動きベクトル、および参照画像を特定する情報、オフセットフィルタ情報、並びにフィルタ係数を、符号化に関する符号化情報として可逆符号化する。可逆符号化部３６は、可逆符号化された符号化情報と直交変換係数を、符号化データとして蓄積バッファ３７に供給し、蓄積させる。なお、可逆符号化された符号化情報は、スライスヘッダ等のヘッダ部として符号化データに付加されるようにしてもよい。
蓄積バッファ３７は、可逆符号化部３６から供給される符号化データを、一時的に記憶する。また、蓄積バッファ３７は、記憶している符号化データを生成部３８に供給する。
生成部３８は、図３の設定部１１から供給されるパラメータセットと蓄積バッファ３７から供給される符号化データから符号化ストリームを生成し、図３の伝送部１４に供給する。
また、量子化部３５より出力された、量子化された直交変換係数は、逆量子化部３９にも入力される。逆量子化部３９は、量子化部３５により量子化された直交変換係数に対して、量子化部３５における量子化方法に対応する方法で逆量子化を行う。逆量子化部３９は、逆量子化の結果得られる直交変換係数を逆直交変換部４０に供給する。
逆直交変換部４０は、ＴＵ単位で、逆量子化部３９から供給される直交変換係数に対して、直交変換部３４における直交変換方法に対応する方法で逆直交変換を行う。逆直交変換部４０は、その結果得られる残差情報を加算部４１に供給する。
加算部４１は、逆直交変換部４０から供給される残差情報と、予測画像選択部４９から供給される予測画像を加算し、局部的に復号を行う。なお、予測画像選択部４９から予測画像が供給されない場合、加算部４１は、逆直交変換部４０から供給される残差情報を局部的に復号された画像とする。加算部４１は、局部的に復号された画像をデブロックフィルタ４２とフレームメモリ４５に供給する。
デブロックフィルタ４２は、加算部４１から供給される局部的に復号された画像に対して、ブロック歪を除去するデブロックフィルタ処理を行い、その結果得られる画像を適応オフセットフィルタ４３に供給する。
適応オフセットフィルタ４３は、デブロックフィルタ４２によるデブロックフィルタ処理後の画像に対して、主にリンギングを除去する適応オフセットフィルタ(SAO（Sample adaptive offset)）処理を行う。
具体的には、適応オフセットフィルタ４３は、最大の符号化単位であるLCU（Largest Coding Unit）ごとに適応オフセットフィルタ処理の種類を決定し、その適応オフセットフィルタ処理で用いられるオフセットを求める。適応オフセットフィルタ４３は、求められたオフセットを用いて、デブロックフィルタ処理後の画像に対して、決定された種類の適応オフセットフィルタ処理を行う。
適応オフセットフィルタ４３は、適応オフセットフィルタ処理後の画像を適応ループフィルタ４４に供給する。また、適応オフセットフィルタ４３は、行われた適応オフセットフィルタ処理の種類とオフセットを示す情報を、オフセットフィルタ情報として可逆符号化部３６に供給する。
適応ループフィルタ４４は、例えば、２次元のウィナーフィルタ（Wiener Filter）により構成される。適応ループフィルタ４４は、適応オフセットフィルタ４３から供給される適応オフセットフィルタ処理後の画像に対して、例えば、LCUごとに、適応ループフィルタ（ALF(Adaptive Loop Filter)）処理を行う。
具体的には、適応ループフィルタ４４は、LCUごとに、画面並べ替えバッファ３２から出力される画像である原画像と適応ループフィルタ処理後の画像の残差が最小となるように、適応ループフィルタ処理で用いられるフィルタ係数を算出する。そして、適応ループフィルタ４４は、適応オフセットフィルタ処理後の画像に対して、算出されたフィルタ係数を用いて、LCUごとに適応ループフィルタ処理を行う。
適応ループフィルタ４４は、適応ループフィルタ処理後の画像をフレームメモリ４５に供給する。また、適応ループフィルタ４４は、適応ループフィルタ処理に用いられたフィルタ係数を可逆符号化部３６に供給する。
なお、ここでは、適応ループフィルタ処理は、LCUごとに行われるものとするが、適応ループフィルタ処理の処理単位は、LCUに限定されない。但し、適応オフセットフィルタ４３と適応ループフィルタ４４の処理単位を合わせることにより、処理を効率的に行うことができる。
フレームメモリ４５は、適応ループフィルタ４４から供給される画像と、加算部４１から供給される画像を蓄積する。フレームメモリ４５に蓄積されたフィルタ処理が行われていない画像のうちのＰＵ（Prediction Unit）に隣接する画素は、周辺画素としてスイッチ４６を介してイントラ予測部４７に供給される。一方、フレームメモリ４５に蓄積されたフィルタ処理が行われた画像は、参照画像としてスイッチ４６を介して動き予測・補償部４８に出力される。
イントラ予測部４７は、ＰＵ単位で、フレームメモリ４５からスイッチ４６を介して読み出された周辺画素を用いて、候補となる全てのイントラ予測モードのイントラ予測処理を行う。
また、イントラ予測部４７は、画面並べ替えバッファ３２から読み出された画像と、イントラ予測処理の結果生成される予測画像とに基づいて、候補となる全てのイントラ予測モードに対してコスト関数値（詳細は後述する）を算出する。そして、イントラ予測部４７は、コスト関数値が最小となるイントラ予測モードを、最適イントラ予測モードに決定する。
イントラ予測部４７は、最適イントラ予測モードで生成された予測画像、および、対応するコスト関数値を、予測画像選択部４９に供給する。イントラ予測部４７は、予測画像選択部４９から最適イントラ予測モードで生成された予測画像の選択が通知された場合、イントラ予測モード情報を可逆符号化部３６に供給する。
なお、コスト関数値は、RD(Rate Distortion)コストともいい、例えば、H．264/AVC方式における参照ソフトウエアであるJM(Joint Model)で定められているような、High Complexity モードまたはLow Complexity モードの手法に基づいて算出される。なお、H．264/AVC方式における参照ソフトウエアは、http://iphome.hhi.de/suehring/tml/index.htmにおいて公開されている。
具体的には、コスト関数値の算出手法としてHigh Complexity モードが採用される場合、候補となる全ての予測モードに対して、仮に復号までが行われ、次の式（１）で表わされるコスト関数値が各予測モードに対して算出される。
Dは、原画像と復号画像の差分（歪）、Rは、直交変換の係数まで含んだ発生符号量、λは、量子化パラメータQPの関数として与えられるラグランジュ未定乗数である。
一方、コスト関数値の算出手法としてLow Complexity モードが採用される場合、候補となる全ての予測モードに対して、予測画像の生成、および、符号化情報の符号量の算出が行われ、次の式（２）で表わされるコスト関数Cost(Mode)が各予測モードに対して算出される。
Dは、原画像と予測画像の差分（歪）、Header_Bitは、符号化情報の符号量、QPtoQuantは、量子化パラメータQPの関数として与えられる関数である。
Low Complexity モードにおいては、全ての予測モードに対して、予測画像を生成するだけでよく、復号画像を生成する必要がないため、演算量が少なくて済む。
動き予測・補償部４８は、ＰＵ単位で候補となる全てのインター予測モードの動き予測・補償処理を行う。具体的には、動き予測・補償部４８は、２次元の線形内挿適応フィルタを有する。また、動き予測・補償部４８は、２次元の線形内挿適応フィルタを用いて、画面並べ替えバッファ３２から供給される画像と参照画像に対して内挿フィルタ処理を行うことにより、その画像と参照画像を高解像度化する。
動き予測・補償部４８は、高解像度化された画像と参照画像とに基づいて、候補となる全てのインター予測モードの動きベクトルを分数画素精度で検出する。そして、動き予測・補償部４８は、その動きベクトルに基づいて参照画像に補償処理を施し、予測画像を生成する。なお、インター予測モードとは、ＰＵのサイズ等を表すモードである。
また、動き予測・補償部４８は、画面並べ替えバッファ３２から供給される画像と予測画像とに基づいて、候補となる全てのインター予測モードに対してコスト関数値を算出し、コスト関数値が最小となるインター予測モードを最適インター予測モードに決定する。そして、動き予測・補償部４８は、最適インター予測モードのコスト関数値と、対応する予測画像を予測画像選択部４９に供給する。
また、動き予測・補償部４８は、予測画像選択部４９から最適インター予測モードで生成された予測画像の選択が通知された場合、インター予測モード情報、対応する動きベクトル、参照画像を特定する情報などを可逆符号化部３６に出力する。
予測画像選択部４９は、イントラ予測部４７および動き予測・補償部４８から供給されるコスト関数値に基づいて、最適イントラ予測モードと最適インター予測モードのうちの、対応するコスト関数値が小さい方を、最適予測モードに決定する。そして、予測画像選択部４９は、最適予測モードの予測画像を、演算部３３および加算部４１に供給する。また、予測画像選択部４９は、最適予測モードの予測画像の選択をイントラ予測部４７または動き予測・補償部４８に通知する。
レート制御部５０は、蓄積バッファ３７に蓄積された符号化データに基づいて、オーバーフローあるいはアンダーフローが発生しないように、量子化部３５の量子化動作のレートを制御する。
（符号化単位の説明）
図８は、HEVC方式における符号化単位であるCoding UNIT(CU)を説明する図である。
図８は、HEVC方式における符号化単位であるCoding UNIT(CU)を説明する図である。
HEVC方式では、4000画素×2000画素のUHD（Ultra High Definition）などのような大きな画枠の画像も対象としているため、符号化単位のサイズを16画素×16画素に固定することは最適ではない。従って、HEVC方式では、符号化単位としてCUが定義されている。このCUの詳細については、非特許文献１に記載されている。
CU（符号化ブロック）は、AVC方式におけるマクロブロックと同様の役割を果たす。具体的には、CUはPUに分割されたり、TUに分割されたりする。
但し、CUのサイズは、シーケンスごとに可変の２のべき乗画素で表される正方形である。具体的には、CUは、最大のサイズのCUであるLCUを、最小のサイズのCUであるSCU(Smallest Coding Unit)より小さくならないように、任意の回数だけ再帰的に水平方向および垂直方向に２分割することにより設定される。即ち、LCUを、SCUになるまで、上の階層のサイズが下の階層のサイズの1/4となるように階層化したときの任意の階層のサイズがCUのサイズである。
例えば、図８では、LCUのサイズが128であり、SCUのサイズが8である。従って、LCUの階層深度（Depth）は0乃至4となり、階層深度数は5となる。即ち、CUに対応する分割数は0乃至4のいずれかである。
なお、LCUとSCUのサイズを指定する情報は、SPSに含められる。また、CUに対応する分割数は、各階層においてさらに分割するかどうかを表すsplit_flagにより指定される。
ＴＵのサイズは、CUのsplit_flagと同様に、split_transform_flagを用いて指定することができる。インター予測時およびイントラ予測時のＴＵの最大分割数は、それぞれ、max_transform_hierarchy_depth_inter,max_transform_hierarchy_depth_intraとして、SPSにより指定される。
また、本明細書において、CTU（Coding Tree Unit）は、LCUのCTB（Coding Tree Block）と、そのLCUベース（レベル）で処理するときのパラメータを含む単位であるとする。また、CTUを構成するCUは、CB(Coding Block)と、そのCUベース（レベル）で処理するときのパラメータを含む単位であるとする。
（符号化装置の処理の説明）
図９は、図３の符号化装置１０のストリーム生成処理を説明するフローチャートである。
図９は、図３の符号化装置１０のストリーム生成処理を説明するフローチャートである。
図９のステップＳ１１において、符号化装置１０の設定部１１は、パラメータセットを設定する。設定部１１は、設定されたパラメータセットを符号化部１２と制御部１３に供給する。
ステップＳ１２において、制御部１３は、設定部１１から供給されるprofile_tier_levelに含まれる情報が表すレベルに対応するMinCrと識別データに基づいて、最低限の圧縮率を算出する。また、制御部１３は、profile_tier_levelに含まれる情報が表すティアに対応するビットレートの最大値と識別データに基づいて、ビットレートの最大値を算出する。制御部１３は、最低限の圧縮率とビットレートの最大値に基づいて、ステップＳ１３の符号化処理を制御する。
ステップＳ１３において、符号化部１２は、外部から入力されたフレーム単位の画像をHEVC方式で符号化する符号化処理を行う。この符号化処理の詳細は、後述する図１０および図１１を参照して説明する。
ステップＳ１４において、符号化部１２の生成部３８（図７）は、設定部１１から供給されるパラメータセットと蓄積している符号化データから符号化ストリームを生成し、伝送部１４に供給する。
ステップＳ１５において、伝送部１４は、設定部１１から供給される符号化ストリームを、後述する復号装置に伝送し、処理を終了する。
図１０および図１１は、図９のステップＳ１３の符号化処理の詳細を説明するフローチャートである。
図１０のステップＳ３１において、符号化部１２のA/D変換部３１は、符号化対象として入力されたフレーム単位の画像をA/D変換する。A/D変換部３１は、変換後のデジタル信号である画像を画面並べ替えバッファ３２に出力して記憶させる。
ステップＳ３２において、画面並べ替えバッファ３２は、記憶した表示の順番のフレームの画像を、GOP構造に応じて、符号化のための順番に並べ替える。画面並べ替えバッファ３２は、並べ替え後のフレーム単位の画像を、演算部３３、イントラ予測部４７、および動き予測・補償部４８に供給する。
ステップＳ３３において、イントラ予測部４７は、ＰＵ単位で候補となる全てのイントラ予測モードのイントラ予測処理を行う。また、イントラ予測部４７は、画面並べ替えバッファ３２から読み出された画像と、イントラ予測処理の結果生成される予測画像とに基づいて、候補となる全てのイントラ予測モードに対してコスト関数値を算出する。そして、イントラ予測部４７は、コスト関数値が最小となるイントラ予測モードを、最適イントラ予測モードに決定する。イントラ予測部４７は、最適イントラ予測モードで生成された予測画像、および、対応するコスト関数値を、予測画像選択部４９に供給する。
また、動き予測・補償部４８は、ＰＵ単位で候補となる全てのインター予測モードの動き予測・補償処理を行う。また、動き予測・補償部４８は、画面並べ替えバッファ３２から供給される画像と予測画像とに基づいて、候補となる全てのインター予測モードに対してコスト関数値を算出し、コスト関数値が最小となるインター予測モードを最適インター予測モードに決定する。そして、動き予測・補償部４８は、最適インター予測モードのコスト関数値と、対応する予測画像を予測画像選択部４９に供給する。
ステップＳ３４において、予測画像選択部４９は、イントラ予測部４７および動き予測・補償部４８から供給されるコスト関数値に基づいて、最適イントラ予測モードと最適インター予測モードのうちのコスト関数値が最小となる方を、最適予測モードに決定する。そして、予測画像選択部４９は、最適予測モードの予測画像を、演算部３３および加算部４１に供給する。
ステップＳ３５において、予測画像選択部４９は、最適予測モードが最適インター予測モードであるかどうかを判定する。ステップＳ３５で最適予測モードが最適インター予測モードであると判定された場合、予測画像選択部４９は、最適インター予測モードで生成された予測画像の選択を動き予測・補償部４８に通知する。
そして、ステップＳ３６において、動き予測・補償部４８は、インター予測モード情報、動きベクトル、および参照画像を特定する情報を可逆符号化部３６に供給し、処理をステップＳ３８に進める。
一方、ステップＳ３５で最適予測モードが最適インター予測モードではないと判定された場合、即ち最適予測モードが最適イントラ予測モードである場合、予測画像選択部４９は、最適イントラ予測モードで生成された予測画像の選択をイントラ予測部４７に通知する。そして、ステップＳ３７において、イントラ予測部４７は、イントラ予測モード情報を可逆符号化部３６に供給し、処理をステップＳ３８に進める。
ステップＳ３８において、演算部３３は、画面並べ替えバッファ３２から供給される画像から、予測画像選択部４９から供給される予測画像を減算することにより符号化を行う。演算部３３は、その結果得られる画像を、残差情報として直交変換部３４に出力する。
ステップＳ３９において、直交変換部３４は、演算部３３からの残差情報に対してＴＵ単位で直交変換を施し、その結果得られる直交変換係数を量子化部３５に供給する。
ステップＳ４０において、量子化部３５は、直交変換部３４から供給される直交変換係数を量子化し、量子化された直交変換係数を可逆符号化部３６と逆量子化部３９に供給する。
図１１のステップＳ４１において、逆量子化部３９は、量子化部３５から供給される量子化された係数を逆量子化し、その結果得られる直交変換係数を逆直交変換部４０に供給する。
ステップＳ４２において、逆直交変換部４０は、逆量子化部３９から供給される直交変換係数に対してＴＵ単位で逆直交変換を施し、その結果得られる残差情報を加算部４１に供給する。
ステップＳ４３において、加算部４１は、逆直交変換部４０から供給される残差情報と、予測画像選択部４９から供給される予測画像を加算し、局部的に復号を行う。加算部４１は、局部的に復号された画像をデブロックフィルタ４２とフレームメモリ４５に供給する。
ステップＳ４４において、デブロックフィルタ４２は、加算部４１から供給される局部的に復号された画像に対して、デブロックフィルタ処理を行う。デブロックフィルタ４２は、その結果得られる画像を適応オフセットフィルタ４３に供給する。
ステップＳ４５において、適応オフセットフィルタ４３は、デブロックフィルタ４２から供給される画像に対して、LCUごとに適応オフセットフィルタ処理を行う。適応オフセットフィルタ４３は、その結果得られる画像を適応ループフィルタ４４に供給する。また、適応オフセットフィルタ４３は、LCUごとに、オフセットフィルタ情報を可逆符号化部３６に供給する。
ステップＳ４６において、適応ループフィルタ４４は、適応オフセットフィルタ４３から供給される画像に対して、LCUごとに適応ループフィルタ処理を行う。適応ループフィルタ４４は、その結果得られる画像をフレームメモリ４５に供給する。また、適応ループフィルタ４４は、適応ループフィルタ処理で用いられたフィルタ係数を可逆符号化部３６に供給する。
ステップＳ４７において、フレームメモリ４５は、適応ループフィルタ４４から供給される画像と加算部４１から供給される画像を蓄積する。フレームメモリ４５に蓄積されたフィルタ処理が行われていない画像のうちのＰＵに隣接する画素は、周辺画素としてスイッチ４６を介してイントラ予測部４７に供給される。一方、フレームメモリ４５に蓄積されたフィルタ処理が行われた画像は、参照画像としてスイッチ４６を介して動き予測・補償部４８に出力される。
ステップＳ４８において、可逆符号化部３６は、イントラ予測モード情報、または、インター予測モード情報、動きベクトル、および参照画像を特定する情報、オフセットフィルタ情報、並びにフィルタ係数を、符号化情報として可逆符号化する。
ステップＳ４９において、可逆符号化部３６は、量子化部３５から供給される量子化された直交変換係数を可逆符号化する。そして、可逆符号化部３６は、ステップＳ４８の処理で可逆符号化された符号化情報と可逆符号化された直交変換係数から、符号化データを生成し、蓄積バッファ３７に供給する。
ステップＳ５０において、蓄積バッファ３７は、可逆符号化部３６から供給される符号化データを、一時的に蓄積する。
ステップＳ５１において、レート制御部５０は、蓄積バッファ３７に蓄積された符号化データに基づいて、オーバーフローあるいはアンダーフローが発生しないように、量子化部３５の量子化動作のレートを制御する。
ステップＳ５２において、蓄積バッファ３７は、記憶している符号化データを、生成部３８に出力する。そして、処理は、図９のステップＳ１３に戻り、ステップＳ１４に進む。そして、処理は、図９のステップＳ１３に戻り、ステップＳ１４に進む。
なお、図１０および図１１の符号化処理では、説明を簡単化するため、常に、イントラ予測処理と動き予測・補償処理が行われるようにしたが、実際には、ピクチャタイプ等によっていずれか一方のみが行われる場合もある。
以上のように、符号化装置１０は、識別データを設定するので、識別データに基づいて最低限の圧縮率およびビットレートの最大値を調整することができる。その結果、符号化処理のやり直しを抑制することができる。また、より高いビットレートの符号化ストリームを生成することができる。
（復号装置の第１実施の形態の構成例）
図１２は、図３の符号化装置１０から伝送される符号化ストリームを復号する、本開示を適用した復号装置の第１実施の形態の構成例を示すブロック図である。
図１２は、図３の符号化装置１０から伝送される符号化ストリームを復号する、本開示を適用した復号装置の第１実施の形態の構成例を示すブロック図である。
図１２の復号装置１１０は、受け取り部１１１、抽出部１１２、制御部１１３、および復号部１１４により構成される。
復号装置１１０の受け取り部１１１は、図３の符号化装置１０から伝送されてくる符号化ストリームを受け取り、抽出部１１２に供給する。
抽出部（パース部）１１２は、受け取り部１１１から供給される符号化ストリームから、パラメータセットと符号化データを抽出（パース）し、復号部１１４に供給する。また、抽出部１１２は、パラメータセットを制御部１１３に供給する。
制御部１１３は、抽出部１１２から供給されるprofile_tier_levelに含まれる情報が表すレベルに対応するMinCrと識別データに基づいて、図３の制御部１３と同様に最低限の圧縮率を算出する。また、制御部１１３は、profile_tier_levelに含まれる情報が表すティアに対応するビットレートの最大値と識別データに基づいて、制御部１３と同様にビットレートの最大値を算出する。制御部１１３は、最低限の圧縮率とビットレートの最大値に基づいて、復号部１１４による復号を制御する。
復号部１１４は、制御部１１３の制御にしたがって、抽出部１１２から供給される符号化データをHEVC方式でCU単位で復号する。このとき、復号部１１４は、必要に応じて、抽出部１１２から供給されるパラメータセットも参照する。復号部１１４は、復号の結果得られる画像を出力する。
（復号部の構成例）
図１３は、図１２の復号部１１４の構成例を示すブロック図である。
図１３は、図１２の復号部１１４の構成例を示すブロック図である。
図１３の復号部１１４は、蓄積バッファ１３１、可逆復号部１３２、逆量子化部１３３、逆直交変換部１３４、加算部１３５、デブロックフィルタ１３６、適応オフセットフィルタ１３７、適応ループフィルタ１３８、および画面並べ替えバッファ１３９を有する。また、復号部１１４は、D/A変換部１４０、フレームメモリ１４１、スイッチ１４２、イントラ予測部１４３、動き補償部１４４、およびスイッチ１４５を有する。
復号部１１４の蓄積バッファ１３１は、図１２の抽出部１１２から符号化データを受け取り、蓄積する。蓄積バッファ１３１は、蓄積されている符号化データを可逆復号部１３２に供給する。
可逆復号部１３２は、蓄積バッファ１３１からの符号化データに対して、図７の可逆符号化部３６の可逆符号化に対応する、可変長復号や、算術復号等の可逆復号を施すことで、量子化された直交変換係数と符号化情報を得る。可逆復号部１３２は、量子化された直交変換係数を逆量子化部１３３に供給する。また、可逆復号部１３２は、符号化情報としてのイントラ予測モード情報などをイントラ予測部１４３に供給する。可逆復号部１３２は、動きベクトル、インター予測モード情報、参照画像を特定する情報などを動き補償部１４４に供給する。
さらに、可逆復号部１３２は、符号化情報としてのイントラ予測モード情報またはインター予測モード情報をスイッチ１４５に供給する。可逆復号部１３２は、符号化情報としてのオフセットフィルタ情報を適応オフセットフィルタ１３７に供給する。可逆復号部１３２は、符号化情報としてのフィルタ係数を適応ループフィルタ１３８に供給する。
逆量子化部１３３、逆直交変換部１３４、加算部１３５、デブロックフィルタ１３６、適応オフセットフィルタ１３７、適応ループフィルタ１３８、フレームメモリ１４１、スイッチ１４２、イントラ予測部１４３、および動き補償部１４４は、図７の逆量子化部３９、逆直交変換部４０、加算部４１、デブロックフィルタ４２、適応オフセットフィルタ４３、適応ループフィルタ４４、フレームメモリ４５、スイッチ４６、イントラ予測部４７、および動き予測・補償部４８とそれぞれ同様の処理を行い、これにより、画像が復号される。
具体的には、逆量子化部１３３は、可逆復号部１３２からの量子化された直交変換係数を逆量子化し、その結果得られる直交変換係数を逆直交変換部１３４に供給する。
逆直交変換部１３４は、逆量子化部１３３からの直交変換係数に対してＴＵ単位で逆直交変換を行う。逆直交変換部１３４は、逆直交変換の結果得られる残差情報を加算部１３５に供給する。
加算部１３５は、逆直交変換部１３４から供給される残差情報と、スイッチ１４５から供給される予測画像を加算することにより、復号を行う。加算部１３５は、復号の結果得られる画像をデブロックフィルタ１３６とフレームメモリ１４１に供給する。
なお、スイッチ１４５から予測画像が供給されない場合、加算部１３５は、逆直交変換部１３４から供給される残差情報である画像を復号の結果得られる画像として、デブロックフィルタ１３６とフレームメモリ１４１に供給する。
デブロックフィルタ１３６は、加算部１３５から供給される画像に対してデブロックフィルタ処理を行い、その結果得られる画像を適応オフセットフィルタ１３７に供給する。
適応オフセットフィルタ１３７は、LCUごとに、可逆復号部１３２からのオフセットフィルタ情報が表すオフセットを用いて、デブロックフィルタ処理後の画像に対して、オフセットフィルタ情報が表す種類の適応オフセットフィルタ処理を行う。適応オフセットフィルタ１３７は、適応オフセットフィルタ処理後の画像を適応ループフィルタ１３８に供給する。
適応ループフィルタ１３８は、適応オフセットフィルタ１３７から供給される画像に対して、可逆復号部１３２から供給されるフィルタ係数を用いて、LCUごとに適応ループフィルタ処理を行う。適応ループフィルタ１３８は、その結果得られる画像をフレームメモリ１４１および画面並べ替えバッファ１３９に供給する。
画面並べ替えバッファ１３９は、適応ループフィルタ１３８から供給される画像をフレーム単位で記憶する。画面並べ替えバッファ１３９は、記憶した符号化のための順番のフレーム単位の画像を、元の表示の順番に並び替え、D/A変換部１４０に供給する。
D/A変換部１４０は、画面並べ替えバッファ１３９から供給されるフレーム単位の画像をD/A変換し、出力する。
フレームメモリ１４１は、適応ループフィルタ１３８から供給される画像と加算部１３５から供給される画像を蓄積する。フレームメモリ１４１に蓄積されたフィルタ処理が行われていない画像のうちのＰＵに隣接する画素は、周辺画素としてスイッチ１４２を介してイントラ予測部１４３に供給される。一方、フレームメモリ１４１に蓄積されたフィルタ処理が行われた画像は、参照画像として、スイッチ１４２を介して動き補償部１４４に供給される。
イントラ予測部１４３は、ＰＵ単位で、フレームメモリ１４１からスイッチ１４２を介して読み出された周辺画素を用いて、可逆復号部１３２から供給されるイントラ予測モード情報が示す最適イントラ予測モードのイントラ予測処理を行う。イントラ予測部１４３は、その結果生成される予測画像をスイッチ１４５に供給する。
動き補償部１４４は、フレームメモリ１４１からスイッチ１４２を介して、可逆復号部１３２から供給される参照画像を特定する情報により特定される参照画像を読み出す。動き補償部１４４は、２次元の線形内挿適応フィルタを有する。動き補償部１４４は、２次元の線形内挿適応フィルタを用いて、参照画像に対して内挿フィルタ処理を行うことにより、参照画像を高解像度化する。動き補償部１４４は、高解像度化された参照画像と可逆復号部１３２から供給される動きベクトルとを用いて、ＰＵ単位で、可逆復号部１３２から供給されるインター予測モード情報が示す最適インター予測モードの動き補償処理を行う。動き補償部１４４は、その結果生成される予測画像をスイッチ１４５に供給する。
スイッチ１４５は、可逆復号部１３２からイントラ予測モード情報が供給された場合、イントラ予測部１４３から供給される予測画像を加算部１３５に供給する。一方、可逆復号部１３２からインター予測モード情報が供給された場合、スイッチ１４５は、動き補償部１４４から供給される予測画像を加算部１３５に供給する。
（復号装置の処理の説明）
図１４は、図１２の復号装置１１０の画像生成処理を説明するフローチャートである。
図１４は、図１２の復号装置１１０の画像生成処理を説明するフローチャートである。
図１４のステップＳ１１１において、復号装置１１０の受け取り部１１１は、図３の符号化装置１０から伝送されてくる符号化ストリームを受け取り、抽出部１１２に供給する。
ステップＳ１１２において、抽出部１１２は、受け取り部１１１から供給される符号化ストリームから、符号化データとパラメータセットを抽出し、復号部１１４に供給する。
ステップＳ１１３において、制御部１１３は、抽出部１１２から供給されるprofile_tier_levelに含まれる情報が表すレベルに対応するMinCrと識別データに基づいて、最低限の圧縮率を算出する。また、制御部１１３は、profile_tier_levelに含まれる情報が表すティアに対応するビットレートの最大値と識別データに基づいて、ビットレートの最大値を算出する。制御部１１３は、最低限の圧縮率とビットレートの最大値に基づいて、ステップＳ１１４の復号処理を制御する。
ステップＳ１１４において、復号部１１４は、必要に応じて抽出部１１２から供給されるパラメータセットを用いて、抽出部１１２から供給される符号化データをHEVC方式に準ずる方式で復号する復号処理を行う。この復号処理の詳細は、後述する図１５を参照して説明する。そして、処理は終了する。
図１５は、図１４のステップＳ１１４の復号処理の詳細を説明するフローチャートである。
図１５のステップＳ１３１において、復号部１１４の蓄積バッファ１３１（図１３）は、図１２の抽出部１１２からフレーム単位の符号化データを受け取り、蓄積する。蓄積バッファ１３１は、蓄積されている符号化データを可逆復号部１３２に供給する。
ステップＳ１３２において、可逆復号部１３２は、蓄積バッファ１３１からの符号化データを可逆復号し、量子化された直交変換係数と符号化情報を得る。可逆復号部１３２は、量子化された直交変換係数を逆量子化部１３３に供給する。
また、可逆復号部１３２は、符号化情報としてのイントラ予測モード情報などをイントラ予測部１４３に供給する。可逆復号部１３２は、動きベクトル、インター予測モード情報、参照画像を特定する情報などを動き補償部１４４に供給する。
さらに、可逆復号部１３２は、符号化情報としてのイントラ予測モード情報またはインター予測モード情報をスイッチ１４５に供給する。可逆復号部１３２は、符号化情報としてのオフセットフィルタ情報を適応オフセットフィルタ１３７に供給し、フィルタ係数を適応ループフィルタ１３８に供給する。
ステップＳ１３３において、逆量子化部１３３は、可逆復号部１３２からの量子化された直交変換係数を逆量子化し、その結果得られる直交変換係数を逆直交変換部１３４に供給する。
ステップＳ１３４において、逆直交変換部１３４は、逆量子化部１３３からの直交変換係数に対して逆直交変換を施し、その結果得られる残差情報を加算部１３５に供給する。
ステップＳ１３５において、動き補償部１４４は、可逆復号部１３２からインター予測モード情報が供給されたかどうかを判定する。ステップＳ１３５でインター予測モード情報が供給されたと判定された場合、処理はステップＳ１３６に進む。
ステップＳ１３６において、動き補償部１４４は、ＰＵ単位で、可逆復号部１３２から供給される参照画像特定情報に基づいて参照画像を読み出し、動きベクトルと参照画像を用いて、インター予測モード情報が示す最適インター予測モードの動き補償処理を行う。動き補償部１４４は、その結果生成される予測画像を、スイッチ１４５を介して加算部１３５に供給し、処理をステップＳ１３８に進める。
一方、ステップＳ１３５でインター予測モード情報が供給されていないと判定された場合、即ちイントラ予測モード情報がイントラ予測部１４３に供給された場合、処理はステップＳ１３７に進む。
ステップＳ１３７において、イントラ予測部１４３は、ＰＵ単位で、フレームメモリ１４１からスイッチ１４２を介して読み出された周辺画素を用いて、イントラ予測モード情報が示すイントラ予測モードのイントラ予測処理を行う。イントラ予測部１４３は、イントラ予測処理の結果生成される予測画像を、スイッチ１４５を介して加算部１３５に供給し、処理をステップＳ１３８に進める。
ステップＳ１３８において、加算部１３５は、逆直交変換部１３４から供給される残差情報と、スイッチ１４５から供給される予測画像を加算することにより、局部的に復号を行う。加算部１３５は、復号の結果得られる画像をデブロックフィルタ１３６とフレームメモリ１４１に供給する。
ステップＳ１３９において、デブロックフィルタ１３６は、加算部１３５から供給される画像に対してデブロックフィルタ処理を行い、ブロック歪を除去する。デブロックフィルタ１３６は、その結果得られる画像を適応オフセットフィルタ１３７に供給する。
ステップＳ１４０において、適応オフセットフィルタ１３７は、可逆復号部１３２から供給されるオフセットフィルタ情報に基づいて、デブロックフィルタ１３６からの画像に対して、LCUごとに適応オフセットフィルタ処理を行う。適応オフセットフィルタ１３７は、適応オフセットフィルタ処理後の画像を、適応ループフィルタ１３８に供給する。
ステップＳ１４１において、適応ループフィルタ１３８は、適応オフセットフィルタ１３７から供給される画像に対して、可逆復号部１３２から供給されるフィルタ係数を用いて、LCUごとに適応ループフィルタ処理を行う。適応ループフィルタ１３８は、その結果得られる画像をフレームメモリ１４１および画面並べ替えバッファ１３９に供給する。
ステップＳ１４２において、フレームメモリ１４１は、加算部１３５から供給される画像と、適応ループフィルタ１３８から供給される画像を蓄積する。フレームメモリ１４１に蓄積されたフィルタ処理が行われていない画像のうちのＰＵに隣接する画素は、周辺画素としてスイッチ１４２を介してイントラ予測部１４３に供給される。一方、フレームメモリ１４１に蓄積されたフィルタ処理が行われた画像は、参照画像として、スイッチ１４２を介して動き補償部１４４に供給される。
ステップＳ１４３において、画面並べ替えバッファ１３９は、適応ループフィルタ１３８から供給される画像をフレーム単位で記憶し、記憶した符号化のための順番のフレーム単位の画像を、元の表示の順番に並び替え、D/A変換部１４０に供給する。
ステップＳ１４４において、D/A変換部１４０は、画面並べ替えバッファ１３９から供給されるフレーム単位の画像をD/A変換し、出力する。そして、処理は、図１４のステップＳ１１４に戻り、終了する。
以上のように、復号装置１１０は、識別データに基づいて最低限の圧縮率およびビットレートの最大値を調整する。従って、符号化装置１０により生成された、最低限の圧縮率およびビットレートの最大値といった制約を調整した符号化ストリームを復号することができる。
（ビットレートの最大値および最低限の圧縮率の算出に用いられるパラメータの第２の例）
図１６は、ビットレートの最大値および最低限の圧縮率の算出に用いられるパラメータの第２の例を示す図である。
図１６は、ビットレートの最大値および最低限の圧縮率の算出に用いられるパラメータの第２の例を示す図である。
図１６の例では、プロファイルがMain profileまたはMain 10 profileである場合のパラメータMinCrScaleFactorがパラメータShFactorにより調整される点、および、パラメータShFactorが上述した式（６）ではなく、以下の式（７）で定義される点が、図５の例と異なっている。
（パラメータHbrFactorおよびShFactorの第２の例）
図１７は、プロファイルがLong Gop profilesおよびAll Intra profilesである場合に図１６のパラメータを調整するパラメータHbrFactorおよびShFactorの例を示す図である。
図１７は、プロファイルがLong Gop profilesおよびAll Intra profilesである場合に図１６のパラメータを調整するパラメータHbrFactorおよびShFactorの例を示す図である。
なお、スーパーハイティア（Super High Tier）とは、ビットレートの最大値がハイティアより高くされた仮想のティアである。
図１７に示すように、プロファイルがLong Gop profilesであり、ティアがメインティアである場合、ティアフラグ（general_tier_flag）は０に設定される。また、低ビットレートフラグ（general_lower_bit_rate_constraint_flag）は１に設定され、識別データ（general_higher_bit_rate_indication_flag）は０に設定される。従って、パラメータHbrFactorは１となり、ShFactorは１となる。
その結果、ビットレートの最大値および最低限の圧縮率は、それぞれ、メインティアに対応するビットレートの最大値、MinCrが表す最低限の圧縮率となり、ビットレートの最大値および最低限の圧縮率は調整されない。
一方、プロファイルがLong Gop profilesであり、ティアがハイティアである場合、ティアフラグ（general_tier_flag）は１に設定される。また、低ビットレートフラグ（general_lower_bit_rate_constraint_flag）は１に設定され、識別データ（general_higher_bit_rate_indication_flag）は１に設定される。従って、パラメータHbrFactorは２となり、ShFactorは１となる。
その結果、ビットレートの最大値は、メインティアに対応するビットレートの最大値となり、調整されないが、プロファイルがMain profileまたはMain 10 profile以外である場合、最低限の圧縮率は、MinCrが表す最低限の圧縮率の1/2となる。プロファイルがMain profileまたはMain 10 profileである場合、最低限の圧縮率も調整されない。
また、プロファイルがLong Gop profilesであり、ティアがスーパーハイティアである場合、ティアフラグ（general_tier_flag）は１に設定される。また、低ビットレートフラグ（general_lower_bit_rate_constraint_flag）は０に設定され、識別データ（general_higher_bit_rate_indication_flag）は１に設定される。従って、パラメータHbrFactorは４となり、ShFactorは２となる。
その結果、ビットレートの最大値は、メインティアに対応するビットレートの２倍となる。また、プロファイルがMain profileまたはMain 10 profile以外である場合、最低限の圧縮率は、MinCrが表す最低限の圧縮率の1/4となり、プロファイルがMain profileまたはMain 10 profileである場合、最低限の圧縮率は、MinCrが表す最低限の圧縮率の1/2となる。
以上のように、プロファイルがMain profileまたはMain 10 profileである場合、ハイティア時には最低減の圧縮率は調整されず、スーパーハイティア時にのみ最低限の圧縮率が調整される。
プロファイルがAll Intra profilesである場合については、図６の場合と同様であるので、説明は省略する。
なお、上述した説明では、識別データが、最低限の圧縮率およびティアに対応するビットレートの最大値の両方を調整することを識別するものとしたが、いずれか一方を調整することを識別するものとすることもできる。この場合、識別データに基づいて、最低限の圧縮率およびティアに対応するビットレートの最大値のいずれか一方が調整される。
例えば、識別データが、最低限の圧縮率のみを調整することを識別するものである場合、パラメータCpbBrVclFactor,CpbBrNalFactor、およびMinCrScaleFactorは、図１８に示すようになる。
即ち、図１８に示すように、パラメータCpbBrVclFactor,CpbBrNalFactorは、パラメータHbrFactor´により調整され、パラメータMinCrScaleFactorは、パラメータHbrFactorにより調整される。
パラメータHbrFactor´は、profile_tier_levelに含まれる低ビットレートフラグ（general_lower_bit_rate_constraint_flag）を用いて、以下の式（８）で定義される。
また、プロファイルがLong Gop profilesおよびAll Intra profilesである場合のパラメータHbrFactorは、例えば、図１９に示すようになる。
図１９に示すように、プロファイルがLong Gop profilesであり、ティアがメインティアである場合、ティアフラグ（general_tier_flag）は０に設定される。また、低ビットレートフラグ（general_lower_bit_rate_constraint_flag）は１に設定され、識別データ（general_higher_bit_rate_indication_flag）は０に設定される。従って、パラメータHbrFactorは１となる。その結果、最低限の圧縮率は、MinCrが表す最低限の圧縮率となり、調整されない。
また、プロファイルがLong Gop profilesであり、ティアがハイティアである場合、ティアフラグ（general_tier_flag）は１に設定される。また、低ビットレートフラグ（general_lower_bit_rate_constraint_flag）は１に設定され、識別データ（general_higher_bit_rate_indication_flag）は１に設定される。従って、パラメータHbrFactorは２となる。その結果、最低限の圧縮率は、MinCrが表す最低限の圧縮率の1/2となる。
なお、図１８の例の場合、プロファイルがLong Gop profilesである場合には、ビットレートの最大値は、調整されない。
一方、プロファイルがAll Intra profilesであり、ティアがメインティアである場合、ティアフラグ（general_tier_flag）は０に設定される。また、低ビットレートフラグ（general_lower_bit_rate_constraint_flag）は０または１に設定され、識別データ（general_higher_bit_rate_indication_flag）は０に設定される。従って、パラメータHbrFactorは２または１となり、ShFactorは２または１となる。
その結果、ビットレートの最大値は、メインティアに対応するビットレートの２倍となり、最低限の圧縮率は、MinCrが表す最低限の圧縮率の1/2となるか、または、両方とも調整されない。
一方、プロファイルがAll Intra profilesであり、ティアがハイティアである場合、ティアフラグ（general_tier_flag）は１に設定される。また、低ビットレートフラグ（general_lower_bit_rate_constraint_flag）は０または１に設定され、識別データ（general_higher_bit_rate_indication_flag）は１に設定される。従って、パラメータHbrFactorは４または２となり、ShFactorは４または２となる。
その結果、ビットレートの最大値は、メインティアに対応するビットレートの４倍または２倍となり、最低限の圧縮率は、MinCrが表す最低限の圧縮率の1/4または1/2となる。
なお、パラメータHbrFactor´の代わりにパラメータHbrFactorが用いられるようにしてもよい。
また、上述した説明では、識別データに基づいて最低限の圧縮率を調整させたが、図２０に示すように、ティアごとにMinCrを設定することにより、最低限の圧縮率を調整するようにしてもよい。
＜第２実施の形態＞
We have added our arguments to section 1 and added our proposed system as a new "Option 2", adding working draft text to the annex.
We have pulled FormatCapabilityFactor into the maximum bit rate calculations by making CpbBr[Vcl|Nal]Factor a function of it. If that is too much change, CpbBr[Vcl|Nal]Factor is profile-specific anyway and we can just change that value
to accommodate 4:4:4 12-bit or 16-bit (The value is used only for determining maximum bit rate).
We have modified Option 1 with a few extra ShFactors, which should effect the desired quadrupling of the bit rate when in super-high tier. Note that Option 1 does not address the inability of the CPB to store a whole frame, but this is not an actual requirement, just a nice-to-have.
If we go with this option, we will need to tweak the values of CpbBr[Vcl|Nal]Factor for the higher profiles in order to take maximum bit depth into account as well as chroma format.
Variant 1 of Option 1 may have to be removed as it does not address the problem with maximum bit rate - only MinCR is modified.
Option 3 can work as long as it is accepted into O1005_v4 (i.e. alongside the HbrFactor stuff) If this case is used, then, as with Option 1, we will need to tweak CpbBr[Vcl|Nal]Factor for the higher profiles to get the maximum bit rates we want for higher bit depths.
As an aside, there seems to be a missing edit in subclause E.2.3 in the working draft. Specifically the definitions of the inferred default values for cpb_size_value_minus1 and cpb_size_du_value_minus1 still contain references to
CpbBrVclFactor and CpbBrNalFactor even though these have been fixed to 1000 and 1100 respectively when determining CPB sizes.
We have added our arguments to section 1 and added our proposed system as a new "Option 2", adding working draft text to the annex.
We have pulled FormatCapabilityFactor into the maximum bit rate calculations by making CpbBr[Vcl|Nal]Factor a function of it. If that is too much change, CpbBr[Vcl|Nal]Factor is profile-specific anyway and we can just change that value
to accommodate 4:4:4 12-bit or 16-bit (The value is used only for determining maximum bit rate).
We have modified Option 1 with a few extra ShFactors, which should effect the desired quadrupling of the bit rate when in super-high tier. Note that Option 1 does not address the inability of the CPB to store a whole frame, but this is not an actual requirement, just a nice-to-have.
If we go with this option, we will need to tweak the values of CpbBr[Vcl|Nal]Factor for the higher profiles in order to take maximum bit depth into account as well as chroma format.
Variant 1 of Option 1 may have to be removed as it does not address the problem with maximum bit rate - only MinCR is modified.
Option 3 can work as long as it is accepted into O1005_v4 (i.e. alongside the HbrFactor stuff) If this case is used, then, as with Option 1, we will need to tweak CpbBr[Vcl|Nal]Factor for the higher profiles to get the maximum bit rates we want for higher bit depths.
As an aside, there seems to be a missing edit in subclause E.2.3 in the working draft. Specifically the definitions of the inferred default values for cpb_size_value_minus1 and cpb_size_du_value_minus1 still contain references to
CpbBrVclFactor and CpbBrNalFactor even though these have been fixed to 1000 and 1100 respectively when determining CPB sizes.
Abstract
The constraint on MinCR is specified to limit the worst case of CABAC decoding process. In the current level/tier definition, the value of MinCR is the same for both Main Tier and High Tier. The current MinCR was defined mainly for Main Tier and larger value is used for higher level. For example, MinCR is equal to 8 for level 5.1 (4K@60p). However this value is too large for high end professional equipments. In addition, the implicit minimum sequence compression ratio defined by the maximum bit rate and maximum luma sample rate is asserted to be overly restrictive when using all-intra coding or higher bit depths and chroma formats, to the point where MinCr becomes superfluous. This contribution proposes to reduce the value of MinCR and introduce a new tier to allow increased bit rates for high end professional applications.
1 MinCR
The level and tier limits are specified in 図１（Table A-1） and 図２（Table A-2) .
Main tier is defined mainly for consumer applications. high tier is defined for high end consumer and professional applications. The bit rate of high tier is higher than that of main tier. However MinCR is the same for both main and high tier.
For large picture, e.g. 4K video, higher value of MinCR is used to reduce the worst case complexity of CABAC. For example, the value of MinCR is 8 for level 5.1 (4K@60p).
However MinCR＝8 is too high for high end applications. When 4K@60p video is encoded at 160Mbps, this MinCR > 8 is normally occurred for I picture and it is not a rare case.
In addition, MinCR＝8 is too high when the target quality is visually lossless. It is hard to achieve visually lossless coding due to this constraint.
As well as the per-frame minimum compression ratio defined by MinCR, there also exists an implied minimum compression ratio for the sequence as a whole defined by the maximum bit rate and maximum luma sample rate. In the example given above, if 4K@60p video is to be coded using level 5.1 (the lowest level at which such video can be coded), though the MinCr value is 8, the actual minimum compression ratio is defined as:
Maximum luma sample rate ＝ 534,773,760 samples/second (equal to 4096x2176@60p)Maximum bit rate (high tier) ＝ 160,000,000 bits/second (main profile CpbBrVclFactor)
Baseband bit rate ＝ 534,773,760 * 1.5 (4:2:0) * 8 (bits/sample) ＝ 6,417,285,120 bits/second
Minimum sequence compression ratio ＝ baseband bit rate / maximum bit rate ＝ 40:1
Though this degree of compression may be acceptable for inter-coded sequences (as the inter pictures can be compressed to a far greater degree than the intra pictures), for all-intra-coded sequences, the MinCR-defined minimum compression ratio becomes purely academic as the sequence must be compressed 40:1 using only intra coding.
Because of this, it will be necessary to modify the maximum bit rate when all-intra coding is in use if the value of MinCR is to be at all relevant. In addition, the above example uses only 4:2:0 8-bit coding. When higher bit depths and more detailed chroma formats are in use, the minimum compression ratio will be even larger. For example, when using 4:4:4 12-bit processing, the minimum compression ratio doubles to 80:1.
Furthermore, for certain profile and level combinations (e.g. HD@30p 4:4:4 12-bit coded using level 4 - MinCr ＝ 4 (MinCrBase) * 0.5 (MinCrScaleFactor) ＝ 2), the Coded Picture Buffer (CPB) (30,000,000 bits at level 4) will not be able to contain a whole coded picture if that picture has compression ratio equal to MinCR. Though there is no actual requirement that a decoder must hold a whole picture at once, it may introduce difficulties in implementation.
There is, however a requirement that the decoder be able to remove pictures from the CPB in real-time. The maximum coded picture size is given as (example: HD@30p 4:4:4 12-bit coded in level 4):
Baseband picture size ＝ 1920 * 1080 * 3 * 12 ＝ 74,649,600 bits
Maximum compressed picture size ＝ baseband size / MinCR ＝ 37,324,800 bits
If the CPB is filled at the maximum bit rate (45,000,000 bits/second for 4:4:4 12-bit at level 4 (high tier)), then the decoder will be receiving only 1.2 pictures/second and will not be able to decode the sequence in real-time. It would be possible to alleviate this problem by coding in a higher level, though even for HD@30p, level 6.1 or higher is required to provide a high enough maximum bit rate.
Therefore, this contribution proposes to reduce the value of MinCR and introduce a new tier for high-end professional applications.
2 Proposal
Version 4 of the current working draft text (JCTVC-O1005_v4) allows MinCR to be halved and maximum bit rate to be doubled via HbrFactor when all-intra coding is in use. Though this modification to MinCR is sufficient, a greater change to the maximum bit rate is needed for use in high-end professional applications.
Since the product development of HEVC had already been started and there are some deployments in market. Therefore the changes should be made not affecting such deployments. There could be the following options.
Option 1: Add another tier, e.g. “Super high tier”, and MinCR is reduced for such tier. A flag is introduced to indicate to reduce MinCR and to increase Max Bitrate and define profile specific level/tier constraints for RExt profiles. For those profiles, MinCR of high tier is interpreted to lower value.
Option 2: Add Super high tier and increase Max Bitrate for this tier. Reduce MinCR using the method specified in JCTVC-O1005_v4.
Option 3: If all current deployments are for main tier and if all people agree, it may be possible to change the values of MinCR and Max Bitrate of high tier. It means the changes are applied to Main and Main 10 profiles.
The text changes for each options are summarized in the Annex.
If nobody object, option 2 is desirable as it most easily integrates with the current working draft without requiring modification to version 1, but option 1 and option 3 could be fine too. It should be decided during the discussion in San Jose meeting.
3 Conclusions
In this contribution, three options to reduce MinCR and increase the maximum bit rate are proposed. One of those options should be adopted to support visually lossless coding in HEVC.
4 Annex
4.1 Option 1
Add flag to indicate higher bit rate (general_higher_bit_rate_indication_flag)(図３）
Change the level limits as follows
Maximum bit rate is derived as follows.
VCL HRD parameter: Max bit rate ＝ CpbBrVclFactor * MaxBR
NAL HRD parameter: Max bit rate ＝ CpbBrNalFactor * MaxBR
MinCR is derived as follows
MinCR ＝ Max(1, MinCrBase * MinCrScaleFactor)
where MaxBR and MinCrBase are defined in Table A-2.
CpbBrVclFactor, CpbBrNalFactor and MinCrScaleFactor are defined in Table A-3 as follows.
Variant 1: Reduce MinCR for high tier（図２１および図２２）
HbrFactor ＝ (2 − general_lower_bit_rate_constraint_flag) + 2 * general_higher_bit_rate_indication_flag
VCL HRD parameter: Max bit rate ＝ CpbBrVclFactor * MaxBR
NAL HRD parameter: Max bit rate ＝ CpbBrNalFactor * MaxBR
MinCR ＝ Max(1, MinCrBase * MinCrScaleFactor)
Variant 2: Add “Super high tier” and MinCR of Main and Main 10 are only changed for new tier（図２３および図２４）
HbrFactor ＝ (2 − general_lower_bit_rate_constraint_flag) + 2 * general_higher_bit_rate_indication_flag
ShFactor ＝ 1 + (!general_lower_bit_rate_constraint_flag) * general_higher_bit_rate_indication_flag
Variant 3: Add “Super high tier” and modify MinCR for high tier（図２５および図２６）
HbrFactor ＝ 2 − general_lower_bit_rate_constraint_flag + 2 * general_higher_bit_rate_indication_flag
ShFactor ＝ 1 + (!general_lower_bit_rate_constraint_flag) * 3 * general_higher_bit_rate_indication_flag
VCL HRD parameter: Max bit rate ＝ CpbBrVclFactor * MaxBR
NAL HRD parameter: Max bit rate ＝ CpbBrNalFactor * MaxBR
MinCR ＝ Max(1, MinCrBase * MinCrScaleFactor)
4.2 Option 2
Introduce super high tier. Use method as in JCTVC-O1005_v4 to modify MinCR.
4.2.1 Profile, tier and level syntax（図２７）
The value of general_super_high_tier_flag shall be 0 except when the value of general_tier_flag is 0. The value 1 of general_super_high_tier_flag when general_tier_flag is 1 is reserved for future use.
Change the level limits as follows
Maximum bit rate is derived as follows.
VCL HRD parameter: Max bit rate ＝ CpbBrVclFactor * MaxBR
NAL HRD parameter: Max bit rate ＝ CpbBrNalFactor * MaxBR
MinCR is derived as follows
MinCR ＝ Max(1, MinCrBase * MinCrScaleFactor)
HbrFactor is derived as follows
HbrFactor ＝ 2 − general_lower_bit_rate_constraint_flag
CpbBrVclFactor and CpbBrNalFactor are derived as follows.
CpbBrVclFactor ＝ ((FormatCapabilityFactor * HbrFactor) / 1.5) * 1000
CpbBrNalFactor ＝ ((FormatCapabilityFactor * HbrFactor) / 1.5) * 1100
where MaxBR and MinCrBase are defined in Table A-2, FormatCapabilityFactor and MinCrScaleFactor are defined in Table A-3.
Table A 1 - General tier and level limits（図２８）
Table A 2 - Tier and level limits for the Monochrome 12, Monochrome 16, Main, Main 10, Main 12,
Main 4:2:2 10, Main 4:2:2 12, Main 4:4:4, Main 4:4:4 10, and Main 4:4:4 12, Main Intra, Main 10 Intra, Main 12 Intra, Main 4:2:2 10 Intra, Main 4:2:2 12 Intra, Main 4:4:4 Intra, Main 4:4:4 10 Intra, and Main 4:4:4 12 Intra profiles（図２９）
Table A 3 - Specification of FormatCapabilityFactor and MinCrScaleFactor（図３０および図３１）
4.3 Option 3
Replace Table A-1 and A-2 with;
Table A 1 - General tier and level limits（図３２）
Table A 2 - Tier and level limits for the Main and Main 10 profiles（図３３）
The constraint on MinCR is specified to limit the worst case of CABAC decoding process. In the current level/tier definition, the value of MinCR is the same for both Main Tier and High Tier. The current MinCR was defined mainly for Main Tier and larger value is used for higher level. For example, MinCR is equal to 8 for level 5.1 (4K@60p). However this value is too large for high end professional equipments. In addition, the implicit minimum sequence compression ratio defined by the maximum bit rate and maximum luma sample rate is asserted to be overly restrictive when using all-intra coding or higher bit depths and chroma formats, to the point where MinCr becomes superfluous. This contribution proposes to reduce the value of MinCR and introduce a new tier to allow increased bit rates for high end professional applications.
1 MinCR
The level and tier limits are specified in 図１（Table A-1） and 図２（Table A-2) .
Main tier is defined mainly for consumer applications. high tier is defined for high end consumer and professional applications. The bit rate of high tier is higher than that of main tier. However MinCR is the same for both main and high tier.
For large picture, e.g. 4K video, higher value of MinCR is used to reduce the worst case complexity of CABAC. For example, the value of MinCR is 8 for level 5.1 (4K@60p).
However MinCR＝8 is too high for high end applications. When 4K@60p video is encoded at 160Mbps, this MinCR > 8 is normally occurred for I picture and it is not a rare case.
In addition, MinCR＝8 is too high when the target quality is visually lossless. It is hard to achieve visually lossless coding due to this constraint.
As well as the per-frame minimum compression ratio defined by MinCR, there also exists an implied minimum compression ratio for the sequence as a whole defined by the maximum bit rate and maximum luma sample rate. In the example given above, if 4K@60p video is to be coded using level 5.1 (the lowest level at which such video can be coded), though the MinCr value is 8, the actual minimum compression ratio is defined as:
Maximum luma sample rate ＝ 534,773,760 samples/second (equal to 4096x2176@60p)Maximum bit rate (high tier) ＝ 160,000,000 bits/second (main profile CpbBrVclFactor)
Baseband bit rate ＝ 534,773,760 * 1.5 (4:2:0) * 8 (bits/sample) ＝ 6,417,285,120 bits/second
Minimum sequence compression ratio ＝ baseband bit rate / maximum bit rate ＝ 40:1
Though this degree of compression may be acceptable for inter-coded sequences (as the inter pictures can be compressed to a far greater degree than the intra pictures), for all-intra-coded sequences, the MinCR-defined minimum compression ratio becomes purely academic as the sequence must be compressed 40:1 using only intra coding.
Because of this, it will be necessary to modify the maximum bit rate when all-intra coding is in use if the value of MinCR is to be at all relevant. In addition, the above example uses only 4:2:0 8-bit coding. When higher bit depths and more detailed chroma formats are in use, the minimum compression ratio will be even larger. For example, when using 4:4:4 12-bit processing, the minimum compression ratio doubles to 80:1.
Furthermore, for certain profile and level combinations (e.g. HD@30p 4:4:4 12-bit coded using level 4 - MinCr ＝ 4 (MinCrBase) * 0.5 (MinCrScaleFactor) ＝ 2), the Coded Picture Buffer (CPB) (30,000,000 bits at level 4) will not be able to contain a whole coded picture if that picture has compression ratio equal to MinCR. Though there is no actual requirement that a decoder must hold a whole picture at once, it may introduce difficulties in implementation.
There is, however a requirement that the decoder be able to remove pictures from the CPB in real-time. The maximum coded picture size is given as (example: HD@30p 4:4:4 12-bit coded in level 4):
Baseband picture size ＝ 1920 * 1080 * 3 * 12 ＝ 74,649,600 bits
Maximum compressed picture size ＝ baseband size / MinCR ＝ 37,324,800 bits
If the CPB is filled at the maximum bit rate (45,000,000 bits/second for 4:4:4 12-bit at level 4 (high tier)), then the decoder will be receiving only 1.2 pictures/second and will not be able to decode the sequence in real-time. It would be possible to alleviate this problem by coding in a higher level, though even for HD@30p, level 6.1 or higher is required to provide a high enough maximum bit rate.
Therefore, this contribution proposes to reduce the value of MinCR and introduce a new tier for high-end professional applications.
2 Proposal
Version 4 of the current working draft text (JCTVC-O1005_v4) allows MinCR to be halved and maximum bit rate to be doubled via HbrFactor when all-intra coding is in use. Though this modification to MinCR is sufficient, a greater change to the maximum bit rate is needed for use in high-end professional applications.
Since the product development of HEVC had already been started and there are some deployments in market. Therefore the changes should be made not affecting such deployments. There could be the following options.
Option 1: Add another tier, e.g. “Super high tier”, and MinCR is reduced for such tier. A flag is introduced to indicate to reduce MinCR and to increase Max Bitrate and define profile specific level/tier constraints for RExt profiles. For those profiles, MinCR of high tier is interpreted to lower value.
Option 2: Add Super high tier and increase Max Bitrate for this tier. Reduce MinCR using the method specified in JCTVC-O1005_v4.
Option 3: If all current deployments are for main tier and if all people agree, it may be possible to change the values of MinCR and Max Bitrate of high tier. It means the changes are applied to Main and Main 10 profiles.
The text changes for each options are summarized in the Annex.
If nobody object, option 2 is desirable as it most easily integrates with the current working draft without requiring modification to version 1, but option 1 and option 3 could be fine too. It should be decided during the discussion in San Jose meeting.
3 Conclusions
In this contribution, three options to reduce MinCR and increase the maximum bit rate are proposed. One of those options should be adopted to support visually lossless coding in HEVC.
4 Annex
4.1 Option 1
Add flag to indicate higher bit rate (general_higher_bit_rate_indication_flag)(図３）
Change the level limits as follows
Maximum bit rate is derived as follows.
VCL HRD parameter: Max bit rate ＝ CpbBrVclFactor * MaxBR
NAL HRD parameter: Max bit rate ＝ CpbBrNalFactor * MaxBR
MinCR is derived as follows
MinCR ＝ Max(1, MinCrBase * MinCrScaleFactor)
where MaxBR and MinCrBase are defined in Table A-2.
CpbBrVclFactor, CpbBrNalFactor and MinCrScaleFactor are defined in Table A-3 as follows.
Variant 1: Reduce MinCR for high tier（図２１および図２２）
HbrFactor ＝ (2 − general_lower_bit_rate_constraint_flag) + 2 * general_higher_bit_rate_indication_flag
VCL HRD parameter: Max bit rate ＝ CpbBrVclFactor * MaxBR
NAL HRD parameter: Max bit rate ＝ CpbBrNalFactor * MaxBR
MinCR ＝ Max(1, MinCrBase * MinCrScaleFactor)
Variant 2: Add “Super high tier” and MinCR of Main and Main 10 are only changed for new tier（図２３および図２４）
HbrFactor ＝ (2 − general_lower_bit_rate_constraint_flag) + 2 * general_higher_bit_rate_indication_flag
ShFactor ＝ 1 + (!general_lower_bit_rate_constraint_flag) * general_higher_bit_rate_indication_flag
Variant 3: Add “Super high tier” and modify MinCR for high tier（図２５および図２６）
HbrFactor ＝ 2 − general_lower_bit_rate_constraint_flag + 2 * general_higher_bit_rate_indication_flag
ShFactor ＝ 1 + (!general_lower_bit_rate_constraint_flag) * 3 * general_higher_bit_rate_indication_flag
VCL HRD parameter: Max bit rate ＝ CpbBrVclFactor * MaxBR
NAL HRD parameter: Max bit rate ＝ CpbBrNalFactor * MaxBR
MinCR ＝ Max(1, MinCrBase * MinCrScaleFactor)
4.2 Option 2
Introduce super high tier. Use method as in JCTVC-O1005_v4 to modify MinCR.
4.2.1 Profile, tier and level syntax（図２７）
The value of general_super_high_tier_flag shall be 0 except when the value of general_tier_flag is 0. The value 1 of general_super_high_tier_flag when general_tier_flag is 1 is reserved for future use.
Change the level limits as follows
Maximum bit rate is derived as follows.
VCL HRD parameter: Max bit rate ＝ CpbBrVclFactor * MaxBR
NAL HRD parameter: Max bit rate ＝ CpbBrNalFactor * MaxBR
MinCR is derived as follows
MinCR ＝ Max(1, MinCrBase * MinCrScaleFactor)
HbrFactor is derived as follows
HbrFactor ＝ 2 − general_lower_bit_rate_constraint_flag
CpbBrVclFactor and CpbBrNalFactor are derived as follows.
CpbBrVclFactor ＝ ((FormatCapabilityFactor * HbrFactor) / 1.5) * 1000
CpbBrNalFactor ＝ ((FormatCapabilityFactor * HbrFactor) / 1.5) * 1100
where MaxBR and MinCrBase are defined in Table A-2, FormatCapabilityFactor and MinCrScaleFactor are defined in Table A-3.
Table A 1 - General tier and level limits（図２８）
Table A 2 - Tier and level limits for the Monochrome 12, Monochrome 16, Main, Main 10, Main 12,
Main 4:2:2 10, Main 4:2:2 12, Main 4:4:4, Main 4:4:4 10, and Main 4:4:4 12, Main Intra, Main 10 Intra, Main 12 Intra, Main 4:2:2 10 Intra, Main 4:2:2 12 Intra, Main 4:4:4 Intra, Main 4:4:4 10 Intra, and Main 4:4:4 12 Intra profiles（図２９）
Table A 3 - Specification of FormatCapabilityFactor and MinCrScaleFactor（図３０および図３１）
4.3 Option 3
Replace Table A-1 and A-2 with;
Table A 1 - General tier and level limits（図３２）
Table A 2 - Tier and level limits for the Main and Main 10 profiles（図３３）
＜第３実施の形態＞
（本開示を適用したコンピュータの説明）
上述した一連の処理は、ハードウエアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウエアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。
（本開示を適用したコンピュータの説明）
上述した一連の処理は、ハードウエアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウエアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。
図３４は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。
コンピュータにおいて、CPU（Central Processing Unit）２０１，ROM（Read Only Memory）２０２，RAM（Random Access Memory）２０３は、バス２０４により相互に接続されている。
バス２０４には、さらに、入出力インタフェース２０５が接続されている。入出力インタフェース２０５には、入力部２０６、出力部２０７、記憶部２０８、通信部２０９、及びドライブ２１０が接続されている。
入力部２０６は、キーボード、マウス、マイクロホンなどよりなる。出力部２０７は、ディスプレイ、スピーカなどよりなる。記憶部２０８は、ハードディスクや不揮発性のメモリなどよりなる。通信部２０９は、ネットワークインタフェースなどよりなる。ドライブ２１０は、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリなどのリムーバブルメディア２１１を駆動する。
以上のように構成されるコンピュータでは、CPU２０１が、例えば、記憶部２０８に記憶されているプログラムを、入出力インタフェース２０５及びバス２０４を介して、RAM２０３にロードして実行することにより、上述した一連の処理が行われる。
コンピュータ（CPU２０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア２１１に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。
コンピュータでは、プログラムは、リムーバブルメディア２１１をドライブ２１０に装着することにより、入出力インタフェース２０５を介して、記憶部２０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部２０９で受信し、記憶部２０８にインストールすることができる。その他、プログラムは、ROM２０２や記憶部２０８に、あらかじめインストールしておくことができる。
なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
＜第４実施の形態＞
（テレビジョン装置の構成例）
図３５は、本技術を適用したテレビジョン装置の概略構成を例示している。テレビジョン装置９００は、アンテナ９０１、チューナ９０２、デマルチプレクサ９０３、デコーダ９０４、映像信号処理部９０５、表示部９０６、音声信号処理部９０７、スピーカ９０８、外部インタフェース部９０９を有している。さらに、テレビジョン装置９００は、制御部９１０、ユーザインタフェース部９１１等を有している。
（テレビジョン装置の構成例）
図３５は、本技術を適用したテレビジョン装置の概略構成を例示している。テレビジョン装置９００は、アンテナ９０１、チューナ９０２、デマルチプレクサ９０３、デコーダ９０４、映像信号処理部９０５、表示部９０６、音声信号処理部９０７、スピーカ９０８、外部インタフェース部９０９を有している。さらに、テレビジョン装置９００は、制御部９１０、ユーザインタフェース部９１１等を有している。
チューナ９０２は、アンテナ９０１で受信された放送波信号から所望のチャンネルを選局して復調を行い、得られた符号化ビットストリームをデマルチプレクサ９０３に出力する。
デマルチプレクサ９０３は、符号化ビットストリームから視聴対象である番組の映像や音声のパケットを抽出して、抽出したパケットのデータをデコーダ９０４に出力する。また、デマルチプレクサ９０３は、ＥＰＧ（Electronic Program Guide）等のデータのパケットを制御部９１０に供給する。なお、スクランブルが行われている場合、デマルチプレクサ等でスクランブルの解除を行う。
デコーダ９０４は、パケットの復号化処理を行い、復号処理化によって生成された映像データを映像信号処理部９０５、音声データを音声信号処理部９０７に出力する。
映像信号処理部９０５は、映像データに対して、ノイズ除去やユーザ設定に応じた映像処理等を行う。映像信号処理部９０５は、表示部９０６に表示させる番組の映像データや、ネットワークを介して供給されるアプリケーションに基づく処理による画像データなどを生成する。また、映像信号処理部９０５は、項目の選択などのメニュー画面等を表示するための映像データを生成し、それを番組の映像データに重畳する。映像信号処理部９０５は、このようにして生成した映像データに基づいて駆動信号を生成して表示部９０６を駆動する。
表示部９０６は、映像信号処理部９０５からの駆動信号に基づき表示デバイス（例えば液晶表示素子等）を駆動して、番組の映像などを表示させる。
音声信号処理部９０７は、音声データに対してノイズ除去などの所定の処理を施し、処理後の音声データのＤ／Ａ変換処理や増幅処理を行いスピーカ９０８に供給することで音声出力を行う。
外部インタフェース部９０９は、外部機器やネットワークと接続するためのインタフェースであり、映像データや音声データ等のデータ送受信を行う。
制御部９１０にはユーザインタフェース部９１１が接続されている。ユーザインタフェース部９１１は、操作スイッチやリモートコントロール信号受信部等で構成されており、ユーザ操作に応じた操作信号を制御部９１０に供給する。
制御部９１０は、ＣＰＵ(Central Processing Unit)やメモリ等を用いて構成されている。メモリは、ＣＰＵにより実行されるプログラムやＣＰＵが処理を行う上で必要な各種のデータ、ＥＰＧデータ、ネットワークを介して取得されたデータ等を記憶する。メモリに記憶されているプログラムは、テレビジョン装置９００の起動時などの所定タイミングでＣＰＵにより読み出されて実行される。ＣＰＵは、プログラムを実行することで、テレビジョン装置９００がユーザ操作に応じた動作となるように各部を制御する。
なお、テレビジョン装置９００では、チューナ９０２、デマルチプレクサ９０３、映像信号処理部９０５、音声信号処理部９０７、外部インタフェース部９０９等と制御部９１０を接続するためバス９１２が設けられている。
このように構成されたテレビジョン装置では、デコーダ９０４に本願の復号装置（復号方法）の機能が設けられる。このため、最低限の圧縮率やビットレートの最大値といった制約が調整された符号化ストリームを復号することができる。
＜第５実施の形態＞
（携帯電話機の構成例）
図３６は、本技術を適用した携帯電話機の概略構成を例示している。携帯電話機９２０は、通信部９２２、音声コーデック９２３、カメラ部９２６、画像処理部９２７、多重分離部９２８、記録再生部９２９、表示部９３０、制御部９３１を有している。これらは、バス９３３を介して互いに接続されている。
（携帯電話機の構成例）
図３６は、本技術を適用した携帯電話機の概略構成を例示している。携帯電話機９２０は、通信部９２２、音声コーデック９２３、カメラ部９２６、画像処理部９２７、多重分離部９２８、記録再生部９２９、表示部９３０、制御部９３１を有している。これらは、バス９３３を介して互いに接続されている。
また、通信部９２２にはアンテナ９２１が接続されており、音声コーデック９２３には、スピーカ９２４とマイクロホン９２５が接続されている。さらに制御部９３１には、操作部９３２が接続されている。
携帯電話機９２０は、音声通話モードやデータ通信モード等の各種モードで、音声信号の送受信、電子メールや画像データの送受信、画像撮影、またはデータ記録等の各種動作を行う。
音声通話モードにおいて、マイクロホン９２５で生成された音声信号は、音声コーデック９２３で音声データへの変換やデータ圧縮が行われて通信部９２２に供給される。通信部９２２は、音声データの変調処理や周波数変換処理等を行い、送信信号を生成する。また、通信部９２２は、送信信号をアンテナ９２１に供給して図示しない基地局へ送信する。また、通信部９２２は、アンテナ９２１で受信した受信信号の増幅や周波数変換処理および復調処理等を行い、得られた音声データを音声コーデック９２３に供給する。音声コーデック９２３は、音声データのデータ伸張やアナログ音声信号への変換を行いスピーカ９２４に出力する。
また、データ通信モードにおいて、メール送信を行う場合、制御部９３１は、操作部９３２の操作によって入力された文字データを受け付けて、入力された文字を表示部９３０に表示する。また、制御部９３１は、操作部９３２におけるユーザ指示等に基づいてメールデータを生成して通信部９２２に供給する。通信部９２２は、メールデータの変調処理や周波数変換処理等を行い、得られた送信信号をアンテナ９２１から送信する。また、通信部９２２は、アンテナ９２１で受信した受信信号の増幅や周波数変換処理および復調処理等を行い、メールデータを復元する。このメールデータを、表示部９３０に供給して、メール内容の表示を行う。
なお、携帯電話機９２０は、受信したメールデータを、記録再生部９２９で記憶媒体に記憶させることも可能である。記憶媒体は、書き換え可能な任意の記憶媒体である。例えば、記憶媒体は、ＲＡＭや内蔵型フラッシュメモリ等の半導体メモリ、ハードディスク、磁気ディスク、光磁気ディスク、光ディスク、USB（Universal Serial Bus）メモリ、またはメモリカード等のリムーバブルメディアである。
データ通信モードにおいて画像データを送信する場合、カメラ部９２６で生成された画像データを、画像処理部９２７に供給する。画像処理部９２７は、画像データの符号化処理を行い、符号化データを生成する。
多重分離部９２８は、画像処理部９２７で生成された符号化データと、音声コーデック９２３から供給された音声データを所定の方式で多重化して通信部９２２に供給する。通信部９２２は、多重化データの変調処理や周波数変換処理等を行い、得られた送信信号をアンテナ９２１から送信する。また、通信部９２２は、アンテナ９２１で受信した受信信号の増幅や周波数変換処理および復調処理等を行い、多重化データを復元する。この多重化データを多重分離部９２８に供給する。多重分離部９２８は、多重化データの分離を行い、符号化データを画像処理部９２７、音声データを音声コーデック９２３に供給する。画像処理部９２７は、符号化データの復号化処理を行い、画像データを生成する。この画像データを表示部９３０に供給して、受信した画像の表示を行う。音声コーデック９２３は、音声データをアナログ音声信号に変換してスピーカ９２４に供給して、受信した音声を出力する。
このように構成された携帯電話装置では、画像処理部９２７に本願の符号化装置および復号装置（符号化方法および復号方法）の機能が設けられる。このため、最低限の圧縮率やビットレートの最大値といった制約を調整することができる。また、最低限の圧縮率やビットレートの最大値といった制約が調整された符号化ストリームを復号することができる。
＜第６実施の形態＞
（記録再生装置の構成例）
図３７は、本技術を適用した記録再生装置の概略構成を例示している。記録再生装置９４０は、例えば受信した放送番組のオーディオデータとビデオデータを、記録媒体に記録して、その記録されたデータをユーザの指示に応じたタイミングでユーザに提供する。また、記録再生装置９４０は、例えば他の装置からオーディオデータやビデオデータを取得し、それらを記録媒体に記録させることもできる。さらに、記録再生装置９４０は、記録媒体に記録されているオーディオデータやビデオデータを復号して出力することで、モニタ装置等において画像表示や音声出力を行うことができるようにする。
（記録再生装置の構成例）
図３７は、本技術を適用した記録再生装置の概略構成を例示している。記録再生装置９４０は、例えば受信した放送番組のオーディオデータとビデオデータを、記録媒体に記録して、その記録されたデータをユーザの指示に応じたタイミングでユーザに提供する。また、記録再生装置９４０は、例えば他の装置からオーディオデータやビデオデータを取得し、それらを記録媒体に記録させることもできる。さらに、記録再生装置９４０は、記録媒体に記録されているオーディオデータやビデオデータを復号して出力することで、モニタ装置等において画像表示や音声出力を行うことができるようにする。
記録再生装置９４０は、チューナ９４１、外部インタフェース部９４２、エンコーダ９４３、ＨＤＤ（Hard Disk Drive）部９４４、ディスクドライブ９４５、セレクタ９４６、デコーダ９４７、ＯＳＤ（On-Screen Display）部９４８、制御部９４９、ユーザインタフェース部９５０を有している。
チューナ９４１は、図示しないアンテナで受信された放送信号から所望のチャンネルを選局する。チューナ９４１は、所望のチャンネルの受信信号を復調して得られた符号化ビットストリームをセレクタ９４６に出力する。
外部インタフェース部９４２は、ＩＥＥＥ１３９４インタフェース、ネットワークインタフェース部、ＵＳＢインタフェース、フラッシュメモリインタフェース等の少なくともいずれかで構成されている。外部インタフェース部９４２は、外部機器やネットワーク、メモリカード等と接続するためのインタフェースであり、記録する映像データや音声データ等のデータ受信を行う。
エンコーダ９４３は、外部インタフェース部９４２から供給された映像データや音声データが符号化されていないとき所定の方式で符号化を行い、符号化ビットストリームをセレクタ９４６に出力する。
ＨＤＤ部９４４は、映像や音声等のコンテンツデータ、各種プログラムやその他のデータ等を内蔵のハードディスクに記録し、また再生時等にそれらを当該ハードディスクから読み出す。
ディスクドライブ９４５は、装着されている光ディスクに対する信号の記録および再生を行う。光ディスク、例えばＤＶＤディスク（ＤＶＤ−Ｖｉｄｅｏ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、ＤＶＤ＋Ｒ、ＤＶＤ＋ＲＷ等）やＢｌｕ−ｒａｙ（登録商標）ディスク等である。
セレクタ９４６は、映像や音声の記録時には、チューナ９４１またはエンコーダ９４３からのいずれかの符号化ビットストリームを選択して、ＨＤＤ部９４４やディスクドライブ９４５のいずれかに供給する。また、セレクタ９４６は、映像や音声の再生時に、ＨＤＤ部９４４またはディスクドライブ９４５から出力された符号化ビットストリームをデコーダ９４７に供給する。
デコーダ９４７は、符号化ビットストリームの復号化処理を行う。デコーダ９４７は、復号処理化を行うことにより生成された映像データをＯＳＤ部９４８に供給する。また、デコーダ９４７は、復号処理化を行うことにより生成された音声データを出力する。
ＯＳＤ部９４８は、項目の選択などのメニュー画面等を表示するための映像データを生成し、それをデコーダ９４７から出力された映像データに重畳して出力する。
制御部９４９には、ユーザインタフェース部９５０が接続されている。ユーザインタフェース部９５０は、操作スイッチやリモートコントロール信号受信部等で構成されており、ユーザ操作に応じた操作信号を制御部９４９に供給する。
制御部９４９は、ＣＰＵやメモリ等を用いて構成されている。メモリは、ＣＰＵにより実行されるプログラムやＣＰＵが処理を行う上で必要な各種のデータを記憶する。メモリに記憶されているプログラムは、記録再生装置９４０の起動時などの所定タイミングでＣＰＵにより読み出されて実行される。ＣＰＵは、プログラムを実行することで、記録再生装置９４０がユーザ操作に応じた動作となるように各部を制御する。
このように構成された記録再生装置では、デコーダ９４７に本願の復号装置（復号方法）の機能が設けられる。このため、最低限の圧縮率やビットレートの最大値といった制約が調整された符号化ストリームを復号することができる。
＜第７実施の形態＞
（撮像装置の構成例）
図３８は、本技術を適用した撮像装置の概略構成を例示している。撮像装置９６０は、被写体を撮像し、被写体の画像を表示部に表示させたり、それを画像データとして、記録媒体に記録する。
（撮像装置の構成例）
図３８は、本技術を適用した撮像装置の概略構成を例示している。撮像装置９６０は、被写体を撮像し、被写体の画像を表示部に表示させたり、それを画像データとして、記録媒体に記録する。
撮像装置９６０は、光学ブロック９６１、撮像部９６２、カメラ信号処理部９６３、画像データ処理部９６４、表示部９６５、外部インタフェース部９６６、メモリ部９６７、メディアドライブ９６８、ＯＳＤ部９６９、制御部９７０を有している。また、制御部９７０には、ユーザインタフェース部９７１が接続されている。さらに、画像データ処理部９６４や外部インタフェース部９６６、メモリ部９６７、メディアドライブ９６８、ＯＳＤ部９６９、制御部９７０等は、バス９７２を介して接続されている。
光学ブロック９６１は、フォーカスレンズや絞り機構等を用いて構成されている。光学ブロック９６１は、被写体の光学像を撮像部９６２の撮像面に結像させる。撮像部９６２は、ＣＣＤまたはＣＭＯＳイメージセンサを用いて構成されており、光電変換によって光学像に応じた電気信号を生成してカメラ信号処理部９６３に供給する。
カメラ信号処理部９６３は、撮像部９６２から供給された電気信号に対してニー補正やガンマ補正、色補正等の種々のカメラ信号処理を行う。カメラ信号処理部９６３は、カメラ信号処理後の画像データを画像データ処理部９６４に供給する。
画像データ処理部９６４は、カメラ信号処理部９６３から供給された画像データの符号化処理を行う。画像データ処理部９６４は、符号化処理を行うことにより生成された符号化データを外部インタフェース部９６６やメディアドライブ９６８に供給する。また、画像データ処理部９６４は、外部インタフェース部９６６やメディアドライブ９６８から供給された符号化データの復号化処理を行う。画像データ処理部９６４は、復号化処理を行うことにより生成された画像データを表示部９６５に供給する。また、画像データ処理部９６４は、カメラ信号処理部９６３から供給された画像データを表示部９６５に供給する処理や、ＯＳＤ部９６９から取得した表示用データを、画像データに重畳させて表示部９６５に供給する。
ＯＳＤ部９６９は、記号、文字、または図形からなるメニュー画面やアイコンなどの表示用データを生成して画像データ処理部９６４に出力する。
外部インタフェース部９６６は、例えば、ＵＳＢ入出力端子などで構成され、画像の印刷を行う場合に、プリンタと接続される。また、外部インタフェース部９６６には、必要に応じてドライブが接続され、磁気ディスク、光ディスク等のリムーバブルメディアが適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて、インストールされる。さらに、外部インタフェース部９６６は、ＬＡＮやインターネット等の所定のネットワークに接続されるネットワークインタフェースを有する。制御部９７０は、例えば、ユーザインタフェース部９７１からの指示にしたがって、メディアドライブ９６８から符号化データを読み出し、それを外部インタフェース部９６６から、ネットワークを介して接続される他の装置に供給させることができる。また、制御部９７０は、ネットワークを介して他の装置から供給される符号化データや画像データを、外部インタフェース部９６６を介して取得し、それを画像データ処理部９６４に供給したりすることができる。
メディアドライブ９６８で駆動される記録メディアとしては、例えば、磁気ディスク、光磁気ディスク、光ディスク、または半導体メモリ等の、読み書き可能な任意のリムーバブルメディアが用いられる。また、記録メディアは、リムーバブルメディアとしての種類も任意であり、テープデバイスであってもよいし、ディスクであってもよいし、メモリカードであってもよい。もちろん、非接触IC（Integrated Circuit）カード等であってもよい。
また、メディアドライブ９６８と記録メディアを一体化し、例えば、内蔵型ハードディスクドライブやＳＳＤ（Solid State Drive）等のように、非可搬性の記憶媒体により構成されるようにしてもよい。
制御部９７０は、ＣＰＵを用いて構成されている。メモリ部９６７は、制御部９７０により実行されるプログラムや制御部９７０が処理を行う上で必要な各種のデータ等を記憶する。メモリ部９６７に記憶されているプログラムは、撮像装置９６０の起動時などの所定タイミングで制御部９７０により読み出されて実行される。制御部９７０は、プログラムを実行することで、撮像装置９６０がユーザ操作に応じた動作となるように各部を制御する。
このように構成された撮像装置では、画像データ処理部９６４に本願の符号化装置および復号装置（符号化方法および復号方法）の機能が設けられる。このため、最低限の圧縮率やビットレートの最大値といった制約を調整することができる。また、最低限の圧縮率やビットレートの最大値といった制約が調整された符号化ストリームを復号することができる。
＜第８実施の形態＞
（実施のその他の例）
以上において本技術を適用する装置やシステム等の例を説明したが、本技術は、これに限らず、このような装置またはシステムを構成する装置に搭載するあらゆる構成、例えば、システムLSI（Large Scale Integration）等としてのプロセッサ、複数のプロセッサ等を用いるモジュール、複数のモジュール等を用いるユニット、ユニットにさらにその他の機能を付加したセット等（すなわち、装置の一部の構成）として実施することもできる。
（実施のその他の例）
以上において本技術を適用する装置やシステム等の例を説明したが、本技術は、これに限らず、このような装置またはシステムを構成する装置に搭載するあらゆる構成、例えば、システムLSI（Large Scale Integration）等としてのプロセッサ、複数のプロセッサ等を用いるモジュール、複数のモジュール等を用いるユニット、ユニットにさらにその他の機能を付加したセット等（すなわち、装置の一部の構成）として実施することもできる。
（ビデオセットの構成例）
本技術をセットとして実施する場合の例について、図３９を参照して説明する。図３９は、本技術を適用したビデオセットの概略的な構成の一例を示している。
本技術をセットとして実施する場合の例について、図３９を参照して説明する。図３９は、本技術を適用したビデオセットの概略的な構成の一例を示している。
近年、電子機器の多機能化が進んでおり、その開発や製造において、その一部の構成を販売や提供等として実施する場合、１機能を有する構成として実施を行う場合だけでなく、関連する機能を有する複数の構成を組み合わせ、複数の機能を有する１セットとして実施を行う場合も多く見られるようになってきた。
図３９に示されるビデオセット１３００は、このような多機能化された構成であり、画像の符号化や復号（いずれか一方でもよいし、両方でも良い）に関する機能を有するデバイスに、その機能に関連するその他の機能を有するデバイスを組み合わせたものである。
図３９に示されるように、ビデオセット１３００は、ビデオモジュール１３１１、外部メモリ１３１２、パワーマネージメントモジュール１３１３、およびフロントエンドモジュール１３１４等のモジュール群と、コネクティビティ１３２１、カメラ１３２２、およびセンサ１３２３等の関連する機能を有するデバイスとを有する。
モジュールは、互いに関連するいくつかの部品的機能をまとめ、まとまりのある機能を持った部品としたものである。具体的な物理的構成は任意であるが、例えば、それぞれ機能を有する複数のプロセッサ、抵抗やコンデンサ等の電子回路素子、その他のデバイス等を配線基板等に配置して一体化したものが考えられる。また、モジュールに他のモジュールやプロセッサ等を組み合わせて新たなモジュールとすることも考えられる。
図３９の例の場合、ビデオモジュール１３１１は、画像処理に関する機能を有する構成を組み合わせたものであり、アプリケーションプロセッサ、ビデオプロセッサ、ブロードバンドモデム１３３３、およびRFモジュール１３３４を有する。
プロセッサは、所定の機能を有する構成をSoC（System On a Chip）により半導体チップに集積したものであり、例えばシステムLSI（Large Scale Integration）等と称されるものもある。この所定の機能を有する構成は、論理回路（ハードウエア構成）であってもよいし、CPU、ROM、RAM等と、それらを用いて実行されるプログラム（ソフトウエア構成）であってもよいし、その両方を組み合わせたものであってもよい。例えば、プロセッサが、論理回路とCPU、ROM、RAM等とを有し、機能の一部を論理回路（ハードウエア構成）により実現し、その他の機能をCPUにおいて実行されるプログラム（ソフトウエア構成）により実現するようにしてもよい。
図３９のアプリケーションプロセッサ１３３１は、画像処理に関するアプリケーションを実行するプロセッサである。このアプリケーションプロセッサ１３３１において実行されるアプリケーションは、所定の機能を実現するために、演算処理を行うだけでなく、例えばビデオプロセッサ１３３２等、ビデオモジュール１３１１内外の構成を必要に応じて制御することもできる。
ビデオプロセッサ１３３２は、画像の符号化・復号（その一方若しくは両方）に関する機能を有するプロセッサである。
ブロードバンドモデム１３３３は、インターネットや公衆電話回線網等の広帯域の回線を介して行われる有線若しくは無線（またはその両方）の広帯域通信に関する処理を行うプロセッサ（若しくはモジュール）である。例えば、ブロードバンドモデム１３３３は、送信するデータ（デジタル信号）をデジタル変調する等してアナログ信号に変換したり、受信したアナログ信号を復調してデータ（デジタル信号）に変換したりする。例えば、ブロードバンドモデム１３３３は、ビデオプロセッサ１３３２が処理する画像データや画像データが符号化されたストリーム、アプリケーションプログラム、設定データ等、任意の情報をデジタル変調・復調することができる。
RFモジュール１３３４は、アンテナを介して送受信されるRF（Radio Frequency）信号に対して、周波数変換、変復調、増幅、フィルタ処理等を行うモジュールである。例えば、RFモジュール１３３４は、ブロードバンドモデム１３３３により生成されたベースバンド信号に対して周波数変換等を行ってRF信号を生成する。また、例えば、RFモジュール１３３４は、フロントエンドモジュール１３１４を介して受信されたRF信号に対して周波数変換等を行ってベースバンド信号を生成する。
なお、図３９において点線１３４１に示されるように、アプリケーションプロセッサ１３３１とビデオプロセッサ１３３２を、一体化し、１つのプロセッサとして構成されるようにしてもよい。
外部メモリ１３１２は、ビデオモジュール１３１１の外部に設けられた、ビデオモジュール１３１１により利用される記憶デバイスを有するモジュールである。この外部メモリ１３１２の記憶デバイスは、どのような物理構成により実現するようにしてもよいが、一般的にフレーム単位の画像データのような大容量のデータの格納に利用されることが多いので、例えばDRAM（Dynamic Random Access Memory）のような比較的安価で大容量の半導体メモリにより実現するのが望ましい。
パワーマネージメントモジュール１３１３は、ビデオモジュール１３１１（ビデオモジュール１３１１内の各構成）への電力供給を管理し、制御する。
フロントエンドモジュール１３１４は、RFモジュール１３３４に対してフロントエンド機能（アンテナ側の送受信端の回路）を提供するモジュールである。図３９に示されるように、フロントエンドモジュール１３１４は、例えば、アンテナ部１３５１、フィルタ１３５２、および増幅部１３５３を有する。
アンテナ部１３５１は、無線信号を送受信するアンテナおよびその周辺の構成を有する。アンテナ部１３５１は、増幅部１３５３から供給される信号を無線信号として送信し、受信した無線信号を電気信号（RF信号）としてフィルタ１３５２に供給する。フィルタ１３５２は、アンテナ部１３５１を介して受信されたRF信号に対してフィルタ処理等を行い、処理後のRF信号をRFモジュール１３３４に供給する。増幅部１３５３は、RFモジュール１３３４から供給されるRF信号を増幅し、アンテナ部１３５１に供給する。
コネクティビティ１３２１は、外部との接続に関する機能を有するモジュールである。コネクティビティ１３２１の物理構成は、任意である。例えば、コネクティビティ１３２１は、ブロードバンドモデム１３３３が対応する通信規格以外の通信機能を有する構成や、外部入出力端子等を有する。
例えば、コネクティビティ１３２１が、Bluetooth（登録商標）、IEEE 802.11（例えばWi-Fi（Wireless Fidelity、登録商標））、NFC（Near Field Communication）、IrDA（InfraRed Data Association）等の無線通信規格に準拠する通信機能を有するモジュールや、その規格に準拠した信号を送受信するアンテナ等を有するようにしてもよい。また、例えば、コネクティビティ１３２１が、USB（Universal Serial Bus）、HDMI（登録商標）（High-Definition Multimedia Interface）等の有線通信規格に準拠する通信機能を有するモジュールや、その規格に準拠した端子を有するようにしてもよい。さらに、例えば、コネクティビティ１３２１が、アナログ入出力端子等のその他のデータ（信号）伝送機能等を有するようにしてもよい。
なお、コネクティビティ１３２１が、データ（信号）の伝送先のデバイスを含むようにしてもよい。例えば、コネクティビティ１３２１が、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリ等の記録媒体に対してデータの読み出しや書き込みを行うドライブ（リムーバブルメディアのドライブだけでなく、ハードディスク、SSD（Solid State Drive）、NAS（Network Attached Storage）等も含む）を有するようにしてもよい。また、コネクティビティ１３２１が、画像や音声の出力デバイス（モニタやスピーカ等）を有するようにしてもよい。
カメラ１３２２は、被写体を撮像し、被写体の画像データを得る機能を有するモジュールである。カメラ１３２２の撮像により得られた画像データは、例えば、ビデオプロセッサ１３３２に供給されて符号化される。
センサ１３２３は、例えば、音声センサ、超音波センサ、光センサ、照度センサ、赤外線センサ、イメージセンサ、回転センサ、角度センサ、角速度センサ、速度センサ、加速度センサ、傾斜センサ、磁気識別センサ、衝撃センサ、温度センサ等、任意のセンサ機能を有するモジュールである。センサ１３２３により検出されたデータは、例えば、アプリケーションプロセッサ１３３１に供給されてアプリケーション等により利用される。
以上においてモジュールとして説明した構成をプロセッサとして実現するようにしてもよいし、逆にプロセッサとして説明した構成をモジュールとして実現するようにしてもよい。
以上のような構成のビデオセット１３００において、後述するようにビデオプロセッサ１３３２に本技術を適用することができる。したがって、ビデオセット１３００は、本技術を適用したセットとして実施することができる。
（ビデオプロセッサの構成例）
図４０は、本技術を適用したビデオプロセッサ１３３２（図３９）の概略的な構成の一例を示している。
図４０は、本技術を適用したビデオプロセッサ１３３２（図３９）の概略的な構成の一例を示している。
図４０の例の場合、ビデオプロセッサ１３３２は、ビデオ信号およびオーディオ信号の入力を受けてこれらを所定の方式で符号化する機能と、符号化されたビデオデータおよびオーディオデータを復号し、ビデオ信号およびオーディオ信号を再生出力する機能とを有する。
図４０に示されるように、ビデオプロセッサ１３３２は、ビデオ入力処理部１４０１、第１画像拡大縮小部１４０２、第２画像拡大縮小部１４０３、ビデオ出力処理部１４０４、フレームメモリ１４０５、およびメモリ制御部１４０６を有する。また、ビデオプロセッサ１３３２は、エンコード・デコードエンジン１４０７、ビデオES（Elementary Stream）バッファ１４０８Ａおよび１４０８Ｂ、並びに、オーディオESバッファ１４０９Ａおよび１４０９Ｂを有する。さらに、ビデオプロセッサ１３３２は、オーディオエンコーダ１４１０、オーディオデコーダ１４１１、多重化部（MUX（Multiplexer））１４１２、逆多重化部（DMUX（Demultiplexer））１４１３、およびストリームバッファ１４１４を有する。
ビデオ入力処理部１４０１は、例えばコネクティビティ１３２１（図３９）等から入力されたビデオ信号を取得し、デジタル画像データに変換する。第１画像拡大縮小部１４０２は、画像データに対してフォーマット変換や画像の拡大縮小処理等を行う。第２画像拡大縮小部１４０３は、画像データに対して、ビデオ出力処理部１４０４を介して出力する先でのフォーマットに応じて画像の拡大縮小処理を行ったり、第１画像拡大縮小部１４０２と同様のフォーマット変換や画像の拡大縮小処理等を行ったりする。ビデオ出力処理部１４０４は、画像データに対して、フォーマット変換やアナログ信号への変換等を行って、再生されたビデオ信号として例えばコネクティビティ１３２１（図３９）等に出力する。
フレームメモリ１４０５は、ビデオ入力処理部１４０１、第１画像拡大縮小部１４０２、第２画像拡大縮小部１４０３、ビデオ出力処理部１４０４、およびエンコード・デコードエンジン１４０７によって共用される画像データ用のメモリである。フレームメモリ１４０５は、例えばDRAM等の半導体メモリとして実現される。
メモリ制御部１４０６は、エンコード・デコードエンジン１４０７からの同期信号を受けて、アクセス管理テーブル１４０６Ａに書き込まれたフレームメモリ１４０５へのアクセススケジュールに従ってフレームメモリ１４０５に対する書き込み・読み出しのアクセスを制御する。アクセス管理テーブル１４０６Ａは、エンコード・デコードエンジン１４０７、第１画像拡大縮小部１４０２、第２画像拡大縮小部１４０３等で実行される処理に応じて、メモリ制御部１４０６により更新される。
エンコード・デコードエンジン１４０７は、画像データのエンコード処理、並びに、画像データが符号化されたデータであるビデオストリームのデコード処理を行う。例えば、エンコード・デコードエンジン１４０７は、フレームメモリ１４０５から読み出した画像データを符号化し、ビデオストリームとしてビデオESバッファ１４０８Ａに順次書き込む。また、例えば、ビデオESバッファ１４０８Ｂからビデオストリームを順次読み出して復号し、画像データとしてフレームメモリ１４０５に順次書き込む。エンコード・デコードエンジン１４０７は、これらの符号化や復号において、フレームメモリ１４０５を作業領域として使用する。また、エンコード・デコードエンジン１４０７は、例えばマクロブロック毎の処理を開始するタイミングで、メモリ制御部１４０６に対して同期信号を出力する。
ビデオESバッファ１４０８Ａは、エンコード・デコードエンジン１４０７によって生成されたビデオストリームをバッファリングして、多重化部（MUX）１４１２に供給する。ビデオESバッファ１４０８Ｂは、逆多重化部（DMUX）１４１３から供給されたビデオストリームをバッファリングして、エンコード・デコードエンジン１４０７に供給する。
オーディオESバッファ１４０９Ａは、オーディオエンコーダ１４１０によって生成されたオーディオストリームをバッファリングして、多重化部（MUX）１４１２に供給する。オーディオESバッファ１４０９Ｂは、逆多重化部（DMUX）１４１３から供給されたオーディオストリームをバッファリングして、オーディオデコーダ１４１１に供給する。
オーディオエンコーダ１４１０は、例えばコネクティビティ１３２１（図３９）等から入力されたオーディオ信号を例えばデジタル変換し、例えばMPEGオーディオ方式やAC3（AudioCode number 3）方式等の所定の方式で符号化する。オーディオエンコーダ１４１０は、オーディオ信号が符号化されたデータであるオーディオストリームをオーディオESバッファ１４０９Ａに順次書き込む。オーディオデコーダ１４１１は、オーディオESバッファ１４０９Ｂから供給されたオーディオストリームを復号し、例えばアナログ信号への変換等を行って、再生されたオーディオ信号として例えばコネクティビティ１３２１（図３９）等に供給する。
多重化部（MUX）１４１２は、ビデオストリームとオーディオストリームとを多重化する。この多重化の方法（すなわち、多重化により生成されるビットストリームのフォーマット）は任意である。また、この多重化の際に、多重化部（MUX）１４１２は、所定のヘッダ情報等をビットストリームに付加することもできる。つまり、多重化部（MUX）１４１２は、多重化によりストリームのフォーマットを変換することができる。例えば、多重化部（MUX）１４１２は、ビデオストリームとオーディオストリームとを多重化することにより、転送用のフォーマットのビットストリームであるトランスポートストリームに変換する。また、例えば、多重化部（MUX）１４１２は、ビデオストリームとオーディオストリームとを多重化することにより、記録用のファイルフォーマットのデータ（ファイルデータ）に変換する。
逆多重化部（DMUX）１４１３は、多重化部（MUX）１４１２による多重化に対応する方法で、ビデオストリームとオーディオストリームとが多重化されたビットストリームを逆多重化する。つまり、逆多重化部（DMUX）１４１３は、ストリームバッファ１４１４から読み出されたビットストリームからビデオストリームとオーディオストリームとを抽出する（ビデオストリームとオーディオストリームとを分離する）。つまり、逆多重化部（DMUX）１４１３は、逆多重化によりストリームのフォーマットを変換（多重化部（MUX）１４１２による変換の逆変換）することができる。例えば、逆多重化部（DMUX）１４１３は、例えばコネクティビティ１３２１やブロードバンドモデム１３３３等（いずれも図３９）から供給されたトランスポートストリームを、ストリームバッファ１４１４を介して取得し、逆多重化することにより、ビデオストリームとオーディオストリームとに変換することができる。また、例えば、逆多重化部（DMUX）１４１３は、例えばコネクティビティ１３２１により（図３９）各種記録媒体から読み出されたファイルデータを、ストリームバッファ１４１４を介して取得し、逆多重化することにより、ビデオストリームとオーディオストリームとに変換することができる。
ストリームバッファ１４１４は、ビットストリームをバッファリングする。例えば、ストリームバッファ１４１４は、多重化部（MUX）１４１２から供給されたトランスポートストリームをバッファリングし、所定のタイミングにおいて、若しくは外部からの要求等に基づいて、例えばコネクティビティ１３２１やブロードバンドモデム１３３３（いずれも図３９）等に供給する。
また、例えば、ストリームバッファ１４１４は、多重化部（MUX）１４１２から供給されたファイルデータをバッファリングし、所定のタイミングにおいて、若しくは外部からの要求等に基づいて、例えばコネクティビティ１３２１（図３９）等に供給し、各種記録媒体に記録させる。
さらに、ストリームバッファ１４１４は、例えばコネクティビティ１３２１やブロードバンドモデム１３３３等（いずれも図３９）を介して取得したトランスポートストリームをバッファリングし、所定のタイミングにおいて、若しくは外部からの要求等に基づいて、逆多重化部（DMUX）１４１３に供給する。
また、ストリームバッファ１４１４は、例えばコネクティビティ１３２１（図３９）等において各種記録媒体から読み出されたファイルデータをバッファリングし、所定のタイミングにおいて、若しくは外部からの要求等に基づいて、逆多重化部（DMUX）１４１３に供給する。
次に、このような構成のビデオプロセッサ１３３２の動作の例について説明する。例えば、コネクティビティ１３２１（図３９）等からビデオプロセッサ１３３２に入力されたビデオ信号は、ビデオ入力処理部１４０１において４：２：２Ｙ／Ｃｂ／Ｃｒ方式等の所定の方式のデジタル画像データに変換され、フレームメモリ１４０５に順次書き込まれる。このデジタル画像データは、第１画像拡大縮小部１４０２または第２画像拡大縮小部１４０３に読み出されて、４：２：０Ｙ／Ｃｂ／Ｃｒ方式等の所定の方式へのフォーマット変換および拡大縮小処理が行われ、再びフレームメモリ１４０５に書き込まれる。この画像データは、エンコード・デコードエンジン１４０７によって符号化され、ビデオストリームとしてビデオESバッファ１４０８Ａに書き込まれる。
また、コネクティビティ１３２１（図３９）等からビデオプロセッサ１３３２に入力されたオーディオ信号は、オーディオエンコーダ１４１０によって符号化され、オーディオストリームとして、オーディオESバッファ１４０９Ａに書き込まれる。
ビデオESバッファ１４０８Ａのビデオストリームと、オーディオESバッファ１４０９Ａのオーディオストリームは、多重化部（MUX）１４１２に読み出されて多重化され、トランスポートストリーム若しくはファイルデータ等に変換される。多重化部（MUX）１４１２により生成されたトランスポートストリームは、ストリームバッファ１４１４にバッファされた後、例えばコネクティビティ１３２１やブロードバンドモデム１３３３（いずれも図３９）等を介して外部ネットワークに出力される。また、多重化部（MUX）１４１２により生成されたファイルデータは、ストリームバッファ１４１４にバッファされた後、例えばコネクティビティ１３２１（図３９）等に出力され、各種記録媒体に記録される。
また、例えばコネクティビティ１３２１やブロードバンドモデム１３３３（いずれも図３９）等を介して外部ネットワークからビデオプロセッサ１３３２に入力されたトランスポートストリームは、ストリームバッファ１４１４にバッファされた後、逆多重化部（DMUX）１４１３により逆多重化される。また、例えばコネクティビティ１３２１（図３９）等において各種記録媒体から読み出され、ビデオプロセッサ１３３２に入力されたファイルデータは、ストリームバッファ１４１４にバッファされた後、逆多重化部（DMUX）１４１３により逆多重化される。つまり、ビデオプロセッサ１３３２に入力されたトランスポートストリームまたはファイルデータは、逆多重化部（DMUX）１４１３によりビデオストリームとオーディオストリームとに分離される。
オーディオストリームは、オーディオESバッファ１４０９Ｂを介してオーディオデコーダ１４１１に供給され、復号されてオーディオ信号が再生される。また、ビデオストリームは、ビデオESバッファ１４０８Ｂに書き込まれた後、エンコード・デコードエンジン１４０７により順次読み出されて復号されてフレームメモリ１４０５に書き込まれる。復号された画像データは、第２画像拡大縮小部１４０３によって拡大縮小処理されて、フレームメモリ１４０５に書き込まれる。そして、復号された画像データは、ビデオ出力処理部１４０４に読み出されて、４：２：２Ｙ／Ｃｂ／Ｃｒ方式等の所定の方式にフォーマット変換され、さらにアナログ信号に変換されて、ビデオ信号が再生出力される。
このように構成されるビデオプロセッサ１３３２に本技術を適用する場合、エンコード・デコードエンジン１４０７に、上述した各実施形態に係る本技術を適用すればよい。つまり、例えば、エンコード・デコードエンジン１４０７が、第１および第２実施の形態に係る符号化装置や復号装置の機能を有するようにすればよい。このようにすることにより、ビデオプロセッサ１３３２は、図１乃至図２０を参照して上述した効果と同様の効果を得ることができる。
なお、エンコード・デコードエンジン１４０７において、本技術（すなわち、上述した各実施形態に係る画像符号化装置や画像復号装置の機能）は、論理回路等のハードウエアにより実現するようにしてもよいし、組み込みプログラム等のソフトウエアにより実現するようにしてもよいし、それらの両方により実現するようにしてもよい。
（ビデオプロセッサの他の構成例）
図４１は、本技術を適用したビデオプロセッサ１３３２（図３９）の概略的な構成の他の例を示している。図４１の例の場合、ビデオプロセッサ１３３２は、ビデオデータを所定の方式で符号化・復号する機能を有する。
図４１は、本技術を適用したビデオプロセッサ１３３２（図３９）の概略的な構成の他の例を示している。図４１の例の場合、ビデオプロセッサ１３３２は、ビデオデータを所定の方式で符号化・復号する機能を有する。
より具体的には、図４１に示されるように、ビデオプロセッサ１３３２は、制御部１５１１、ディスプレイインタフェース１５１２、ディスプレイエンジン１５１３、画像処理エンジン１５１４、および内部メモリ１５１５を有する。また、ビデオプロセッサ１３３２は、コーデックエンジン１５１６、メモリインタフェース１５１７、多重化・逆多重化部（MUX DMUX）１５１８、ネットワークインタフェース１５１９、およびビデオインタフェース１５２０を有する。
制御部１５１１は、ディスプレイインタフェース１５１２、ディスプレイエンジン１５１３、画像処理エンジン１５１４、およびコーデックエンジン１５１６等、ビデオプロセッサ１３３２内の各処理部の動作を制御する。
図４１に示されるように、制御部１５１１は、例えば、メインCPU１５３１、サブCPU１５３２、およびシステムコントローラ１５３３を有する。メインCPU１５３１は、ビデオプロセッサ１３３２内の各処理部の動作を制御するためのプログラム等を実行する。メインCPU１５３１は、そのプログラム等に従って制御信号を生成し、各処理部に供給する（つまり、各処理部の動作を制御する）。サブCPU１５３２は、メインCPU１５３１の補助的な役割を果たす。例えば、サブCPU１５３２は、メインCPU１５３１が実行するプログラム等の子プロセスやサブルーチン等を実行する。システムコントローラ１５３３は、メインCPU１５３１およびサブCPU１５３２が実行するプログラムを指定する等、メインCPU１５３１およびサブCPU１５３２の動作を制御する。
ディスプレイインタフェース１５１２は、制御部１５１１の制御の下、画像データを例えばコネクティビティ１３２１（図３９）等に出力する。例えば、ディスプレイインタフェース１５１２は、デジタルデータの画像データをアナログ信号に変換し、再生されたビデオ信号として、またはデジタルデータの画像データのまま、コネクティビティ１３２１（図３９）のモニタ装置等に出力する。
ディスプレイエンジン１５１３は、制御部１５１１の制御の下、画像データに対して、その画像を表示させるモニタ装置等のハードウエアスペックに合わせるように、フォーマット変換、サイズ変換、色域変換等の各種変換処理を行う。
画像処理エンジン１５１４は、制御部１５１１の制御の下、画像データに対して、例えば画質改善のためのフィルタ処理等、所定の画像処理を施す。
内部メモリ１５１５は、ディスプレイエンジン１５１３、画像処理エンジン１５１４、およびコーデックエンジン１５１６により共用される、ビデオプロセッサ１３３２の内部に設けられたメモリである。内部メモリ１５１５は、例えば、ディスプレイエンジン１５１３、画像処理エンジン１５１４、およびコーデックエンジン１５１６の間で行われるデータの授受に利用される。例えば、内部メモリ１５１５は、ディスプレイエンジン１５１３、画像処理エンジン１５１４、またはコーデックエンジン１５１６から供給されるデータを格納し、必要に応じて（例えば、要求に応じて）、そのデータを、ディスプレイエンジン１５１３、画像処理エンジン１５１４、またはコーデックエンジン１５１６に供給する。この内部メモリ１５１５は、どのような記憶デバイスにより実現するようにしてもよいが、一般的にブロック単位の画像データやパラメータ等といった小容量のデータの格納に利用することが多いので、例えばSRAM（Static Random Access Memory）のような比較的（例えば外部メモリ１３１２と比較して）小容量だが応答速度が高速な半導体メモリにより実現するのが望ましい。
コーデックエンジン１５１６は、画像データの符号化や復号に関する処理を行う。このコーデックエンジン１５１６が対応する符号化・復号の方式は任意であり、その数は１つであってもよいし、複数であってもよい。例えば、コーデックエンジン１５１６は、複数の符号化・復号方式のコーデック機能を備え、その中から選択されたもので画像データの符号化若しくは符号化データの復号を行うようにしてもよい。
図４１に示される例において、コーデックエンジン１５１６は、コーデックに関する処理の機能ブロックとして、例えば、MPEG-2 Video１５４１、AVC/H.264１５４２、HEVC/H.265１５４３、HEVC/H.265(Scalable)１５４４、HEVC/H.265(Multi-view)１５４５、およびMPEG-DASH１５５１を有する。
MPEG-2 Video１５４１は、画像データをMPEG-2方式で符号化したり復号したりする機能ブロックである。AVC/H.264１５４２は、画像データをAVC方式で符号化したり復号したりする機能ブロックである。HEVC/H.265１５４３は、画像データをHEVC方式で符号化したり復号したりする機能ブロックである。HEVC/H.265(Scalable)１５４４は、画像データをHEVC方式でスケーラブル符号化したりスケーラブル復号したりする機能ブロックである。HEVC/H.265(Multi-view)１５４５は、画像データをHEVC方式で多視点符号化したり多視点復号したりする機能ブロックである。
MPEG-DASH１５５１は、画像データをMPEG-DASH（MPEG-Dynamic Adaptive Streaming over HTTP）方式で送受信する機能ブロックである。MPEG-DASHは、HTTP（HyperText Transfer Protocol）を使ってビデオのストリーミングを行う技術であり、予め用意された解像度等が互いに異なる複数の符号化データの中から適切なものをセグメント単位で選択し伝送することを特徴の１つとする。MPEG-DASH１５５１は、規格に準拠するストリームの生成やそのストリームの伝送制御等を行い、画像データの符号化・復号については、上述したMPEG-2 Video１５４１乃至HEVC/H.265(Multi-view)１５４５を利用する。
メモリインタフェース１５１７は、外部メモリ１３１２用のインタフェースである。画像処理エンジン１５１４やコーデックエンジン１５１６から供給されるデータは、メモリインタフェース１５１７を介して外部メモリ１３１２に供給される。また、外部メモリ１３１２から読み出されたデータは、メモリインタフェース１５１７を介してビデオプロセッサ１３３２（画像処理エンジン１５１４若しくはコーデックエンジン１５１６）に供給される。
多重化・逆多重化部（MUX DMUX）１５１８は、符号化データのビットストリーム、画像データ、ビデオ信号等、画像に関する各種データの多重化や逆多重化を行う。この多重化・逆多重化の方法は任意である。例えば、多重化の際に、多重化・逆多重化部（MUX DMUX）１５１８は、複数のデータを１つにまとめるだけでなく、所定のヘッダ情報等をそのデータに付加することもできる。また、逆多重化の際に、多重化・逆多重化部（MUX DMUX）１５１８は、１つのデータを複数に分割するだけでなく、分割した各データに所定のヘッダ情報等を付加することもできる。つまり、多重化・逆多重化部（MUX DMUX）１５１８は、多重化・逆多重化によりデータのフォーマットを変換することができる。例えば、多重化・逆多重化部（MUX DMUX）１５１８は、ビットストリームを多重化することにより、転送用のフォーマットのビットストリームであるトランスポートストリームや、記録用のファイルフォーマットのデータ（ファイルデータ）に変換することができる。もちろん、逆多重化によりその逆変換も可能である。
ネットワークインタフェース１５１９は、例えばブロードバンドモデム１３３３やコネクティビティ１３２１（いずれも図３９）等向けのインタフェースである。ビデオインタフェース１５２０は、例えばコネクティビティ１３２１やカメラ１３２２（いずれも図３９）等向けのインタフェースである。
次に、このようなビデオプロセッサ１３３２の動作の例について説明する。例えば、コネクティビティ１３２１やブロードバンドモデム１３３３（いずれも図３９）等を介して外部ネットワークからトランスポートストリームを受信すると、そのトランスポートストリームは、ネットワークインタフェース１５１９を介して多重化・逆多重化部（MUX DMUX）１５１８に供給されて逆多重化され、コーデックエンジン１５１６により復号される。コーデックエンジン１５１６の復号により得られた画像データは、例えば、画像処理エンジン１５１４により所定の画像処理が施され、ディスプレイエンジン１５１３により所定の変換が行われ、ディスプレイインタフェース１５１２を介して例えばコネクティビティ１３２１（図３９）等に供給され、その画像がモニタに表示される。また、例えば、コーデックエンジン１５１６の復号により得られた画像データは、コーデックエンジン１５１６により再符号化され、多重化・逆多重化部（MUX DMUX）１５１８により多重化されてファイルデータに変換され、ビデオインタフェース１５２０を介して例えばコネクティビティ１３２１（図３９）等に出力され、各種記録媒体に記録される。
さらに、例えば、コネクティビティ１３２１（図３９）等により図示せぬ記録媒体から読み出された、画像データが符号化された符号化データのファイルデータは、ビデオインタフェース１５２０を介して多重化・逆多重化部（MUX DMUX）１５１８に供給されて逆多重化され、コーデックエンジン１５１６により復号される。コーデックエンジン１５１６の復号により得られた画像データは、画像処理エンジン１５１４により所定の画像処理が施され、ディスプレイエンジン１５１３により所定の変換が行われ、ディスプレイインタフェース１５１２を介して例えばコネクティビティ１３２１（図３９）等に供給され、その画像がモニタに表示される。また、例えば、コーデックエンジン１５１６の復号により得られた画像データは、コーデックエンジン１５１６により再符号化され、多重化・逆多重化部（MUX DMUX）１５１８により多重化されてトランスポートストリームに変換され、ネットワークインタフェース１５１９を介して例えばコネクティビティ１３２１やブロードバンドモデム１３３３（いずれも図３９）等に供給され図示せぬ他の装置に伝送される。
なお、ビデオプロセッサ１３３２内の各処理部の間での画像データやその他のデータの授受は、例えば、内部メモリ１５１５や外部メモリ１３１２を利用して行われる。また、パワーマネージメントモジュール１３１３は、例えば制御部１５１１への電力供給を制御する。
このように構成されるビデオプロセッサ１３３２に本技術を適用する場合、コーデックエンジン１５１６に、上述した各実施形態に係る本技術を適用すればよい。つまり、例えば、コーデックエンジン１５１６が、第１および第２実施の形態に係る符号化装置や復号装置を実現する機能ブロックを有するようにすればよい。コーデックエンジン１５１６が、このようにすることにより、ビデオプロセッサ１３３２は、図１乃至図２０を参照して上述した効果と同様の効果を得ることができる。
なお、コーデックエンジン１５１６において、本技術（すなわち、上述した各実施形態に係る画像符号化装置や画像復号装置の機能）は、論理回路等のハードウエアにより実現するようにしてもよいし、組み込みプログラム等のソフトウエアにより実現するようにしてもよいし、それらの両方により実現するようにしてもよい。
以上にビデオプロセッサ１３３２の構成を２例示したが、ビデオプロセッサ１３３２の構成は任意であり、上述した２例以外のものであってもよい。また、このビデオプロセッサ１３３２は、１つの半導体チップとして構成されるようにしてもよいが、複数の半導体チップとして構成されるようにしてもよい。例えば、複数の半導体を積層する３次元積層LSIとしてもよい。また、複数のLSIにより実現されるようにしてもよい。
（装置への適用例）
ビデオセット１３００は、画像データを処理する各種装置に組み込むことができる。例えば、ビデオセット１３００は、テレビジョン装置９００（図３５）、携帯電話機９２０（図３６）、記録再生装置９４０（図３７）、撮像装置９６０（図３８）等に組み込むことができる。ビデオセット１３００を組み込むことにより、その装置は、図１乃至図２０を参照して上述した効果と同様の効果を得ることができる。
ビデオセット１３００は、画像データを処理する各種装置に組み込むことができる。例えば、ビデオセット１３００は、テレビジョン装置９００（図３５）、携帯電話機９２０（図３６）、記録再生装置９４０（図３７）、撮像装置９６０（図３８）等に組み込むことができる。ビデオセット１３００を組み込むことにより、その装置は、図１乃至図２０を参照して上述した効果と同様の効果を得ることができる。
なお、上述したビデオセット１３００の各構成の一部であっても、ビデオプロセッサ１３３２を含むものであれば、本技術を適用した構成として実施することができる。例えば、ビデオプロセッサ１３３２のみを本技術を適用したビデオプロセッサとして実施することができる。また、例えば、上述したように点線１３４１により示されるプロセッサやビデオモジュール１３１１等を本技術を適用したプロセッサやモジュール等として実施することができる。さらに、例えば、ビデオモジュール１３１１、外部メモリ１３１２、パワーマネージメントモジュール１３１３、およびフロントエンドモジュール１３１４を組み合わせ、本技術を適用したビデオユニット１３６１として実施することもできる。いずれの構成の場合であっても、図１乃至図２０を参照して上述した効果と同様の効果を得ることができる。
つまり、ビデオプロセッサ１３３２を含むものであればどのような構成であっても、ビデオセット１３００の場合と同様に、画像データを処理する各種装置に組み込むことができる。例えば、ビデオプロセッサ１３３２、点線１３４１により示されるプロセッサ、ビデオモジュール１３１１、または、ビデオユニット１３６１を、テレビジョン装置９００（図３５）、携帯電話機９２０（図３６）、記録再生装置９４０（図３７）、撮像装置９６０（図３８）等に組み込むことができる。そして、本技術を適用したいずれかの構成を組み込むことにより、その装置は、ビデオセット１３００の場合と同様に、図１乃至図２０を参照して上述した効果と同様の効果を得ることができる。
なお、本明細書では、識別データなどの各種情報が、符号化データに多重化されて、符号化側から復号側へ伝送される例について説明した。しかしながら、これら情報を伝送する手法はかかる例に限定されない。例えば、これら情報は、符号化データに多重化されることなく、符号化データと関連付けられた別個のデータとして伝送され又は記録されてもよい。ここで、「関連付ける」という用語は、ビットストリームに含まれる画像（スライスやブロックなど、画像の一部であってもよい）と当該画像に対応する情報とを復号時にリンクさせ得るようにすることを意味する。即ち、情報は、符号化データとは別の伝送路上で伝送されてもよい。また、情報は、符号化データとは別の記録媒体（又は同一の記録媒体の別の記録エリア）に記録されてもよい。さらに、情報と符号化データとは、例えば、複数フレーム、１フレーム、又はフレーム内の一部分などの任意の単位で互いに関連付けられてよい。
本開示は、MPEG,H.26ｘ等のように、離散コサイン変換等の直交変換と動き補償によって圧縮されたビットストリームを、衛星放送、ケーブルＴＶ、インターネット、携帯電話などのネットワークメディアを介して受信する際、または光、磁気ディスク、フラッシュメモリのような記憶メディア上で処理する際に用いられる符号化装置や復号装置に適用することができる。
本開示の符号化方式は、HEVC方式以外の再帰的な階層構造を有する単位で符号化する方式であってもよい。
また、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
さらに、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。
また、本開示の実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。
例えば、本開示は、１つの機能をネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
また、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。
さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。
本開示は、以下のような構成もとることができる。
（１）
画像を符号化する際の最低圧縮率が複数のティアのそれぞれに対して設定されたプロファイルを有する符号化規格に従って符号化されたビットストリームを、再帰的に分割されたブロックを単位として、復号する復号部
を備える復号装置。
（２）
前記複数のティアのそれぞれに対して設定される前記最低圧縮率は、レベル毎に異なる
前記（１）に記載の復号装置。
（３）
前記複数のティアは、メインティアとハイティアである
前記（１）または（２）に記載の復号装置。
（４）
所定レベル以上のレベルの前記ハイティアの前記最低圧縮率と前記メインティアの前記最低圧縮率は異なる
前記（３）に記載の復号装置。
（５）
前記所定レベルは、レベル５である
前記（４）に記載の復号装置。
（６）
前記レベル５以上のレベルの前記ハイティアの前記最低圧縮率は４である
前記（５）に記載の復号装置。
（７）
前記符号化規格は、H.265/HEVC規格であり、
前記復号部は、H.265/HEVC規格に従って、前記符号化されたビットストリームを復号する
前記（１）乃至（６）のいずれかに記載の復号装置。
（８）
復号装置が、
画像を符号化する際の最低圧縮率が複数のティアのそれぞれに対して設定されたプロファイルを有する符号化規格に従って符号化されたビットストリームを、再帰的に分割されたブロックを単位として、復号する復号ステップ
を含む復号方法。
（９）
画像を符号化する際の最低圧縮率が複数のティアのそれぞれに対して設定されたプロファイルを有する符号化規格に従って、再帰的に分割されたブロックを単位として、画像を符号化する符号化部
を備える符号化装置。
（１０）
前記複数のティアのそれぞれに対して設定される前記最低圧縮率は、レベル毎に異なる
前記（９）に記載の符号化装置。
（１１）
前記複数のティアは、メインティアとハイティアである
前記（９）または（１０）に記載の符号化装置。
（１２）
所定レベル以上のレベルの前記ハイティアの前記最低圧縮率と前記メインティアの前記最低圧縮率は異なる
前記（１１）に記載の符号化装置。
（１３）
前記所定レベルは、レベル５である
前記（１２）に記載の符号化装置。
（１４）
前記レベル５以上のレベルの前記ハイティアの前記最低圧縮率は４である
前記（１３）に記載の符号化装置。
（１５）
前記符号化規格は、H.265/HEVC規格であり、
前記符号化部は、H.265/HEVC規格に従って、前記画像を符号化する
前記（９）乃至（１４）のいずれかに記載の符号化装置。
（１６）
符号化装置が、
画像を符号化する際の最低圧縮率が複数のティアのそれぞれに対して設定されたプロファイルを有する符号化規格に従って、再帰的に分割されたブロックを単位として、画像を符号化する符号化ステップ
を含む符号化方法。
画像を符号化する際の最低圧縮率が複数のティアのそれぞれに対して設定されたプロファイルを有する符号化規格に従って符号化されたビットストリームを、再帰的に分割されたブロックを単位として、復号する復号部
を備える復号装置。
（２）
前記複数のティアのそれぞれに対して設定される前記最低圧縮率は、レベル毎に異なる
前記（１）に記載の復号装置。
（３）
前記複数のティアは、メインティアとハイティアである
前記（１）または（２）に記載の復号装置。
（４）
所定レベル以上のレベルの前記ハイティアの前記最低圧縮率と前記メインティアの前記最低圧縮率は異なる
前記（３）に記載の復号装置。
（５）
前記所定レベルは、レベル５である
前記（４）に記載の復号装置。
（６）
前記レベル５以上のレベルの前記ハイティアの前記最低圧縮率は４である
前記（５）に記載の復号装置。
（７）
前記符号化規格は、H.265/HEVC規格であり、
前記復号部は、H.265/HEVC規格に従って、前記符号化されたビットストリームを復号する
前記（１）乃至（６）のいずれかに記載の復号装置。
（８）
復号装置が、
画像を符号化する際の最低圧縮率が複数のティアのそれぞれに対して設定されたプロファイルを有する符号化規格に従って符号化されたビットストリームを、再帰的に分割されたブロックを単位として、復号する復号ステップ
を含む復号方法。
（９）
画像を符号化する際の最低圧縮率が複数のティアのそれぞれに対して設定されたプロファイルを有する符号化規格に従って、再帰的に分割されたブロックを単位として、画像を符号化する符号化部
を備える符号化装置。
（１０）
前記複数のティアのそれぞれに対して設定される前記最低圧縮率は、レベル毎に異なる
前記（９）に記載の符号化装置。
（１１）
前記複数のティアは、メインティアとハイティアである
前記（９）または（１０）に記載の符号化装置。
（１２）
所定レベル以上のレベルの前記ハイティアの前記最低圧縮率と前記メインティアの前記最低圧縮率は異なる
前記（１１）に記載の符号化装置。
（１３）
前記所定レベルは、レベル５である
前記（１２）に記載の符号化装置。
（１４）
前記レベル５以上のレベルの前記ハイティアの前記最低圧縮率は４である
前記（１３）に記載の符号化装置。
（１５）
前記符号化規格は、H.265/HEVC規格であり、
前記符号化部は、H.265/HEVC規格に従って、前記画像を符号化する
前記（９）乃至（１４）のいずれかに記載の符号化装置。
（１６）
符号化装置が、
画像を符号化する際の最低圧縮率が複数のティアのそれぞれに対して設定されたプロファイルを有する符号化規格に従って、再帰的に分割されたブロックを単位として、画像を符号化する符号化ステップ
を含む符号化方法。
１０ 符号化装置， １１ 設定部， １２ 符号化部， １１０ 復号装置， １１２ 抽出部， １１４ 復号部
Claims (16)
- 画像を符号化する際の最低圧縮率が複数のティアのそれぞれに対して設定されたプロファイルを有する符号化規格に従って符号化されたビットストリームを、再帰的に分割されたブロックを単位として、復号する復号部
を備える復号装置。 - 前記複数のティアのそれぞれに対して設定される前記最低圧縮率は、レベル毎に異なる
請求項１に記載の復号装置。 - 前記複数のティアは、メインティアとハイティアである
請求項２に記載の復号装置。 - 所定レベル以上のレベルの前記ハイティアの前記最低圧縮率と前記メインティアの前記最低圧縮率は異なる
請求項３に記載の復号装置。 - 前記所定レベルは、レベル５である
請求項４に記載の復号装置。 - 前記レベル５以上のレベルの前記ハイティアの前記最低圧縮率は４である
請求項５に記載の復号装置。 - 前記符号化規格は、H.265/HEVC規格であり、
前記復号部は、H.265/HEVC規格に従って、前記符号化されたビットストリームを復号する
請求項６に記載の復号装置。 - 復号装置が、
画像を符号化する際の最低圧縮率が複数のティアのそれぞれに対して設定されたプロファイルを有する符号化規格に従って符号化されたビットストリームを、再帰的に分割されたブロックを単位として、復号する復号ステップ
を含む復号方法。 - 画像を符号化する際の最低圧縮率が複数のティアのそれぞれに対して設定されたプロファイルを有する符号化規格に従って、再帰的に分割されたブロックを単位として、画像を符号化する符号化部
を備える符号化装置。 - 前記複数のティアのそれぞれに対して設定される前記最低圧縮率は、レベル毎に異なる
請求項９に記載の符号化装置。 - 前記複数のティアは、メインティアとハイティアである
請求項１０に記載の符号化装置。 - 所定レベル以上のレベルの前記ハイティアの前記最低圧縮率と前記メインティアの前記最低圧縮率は異なる
請求項１１に記載の符号化装置。 - 前記所定レベルは、レベル５である
請求項１２に記載の符号化装置。 - 前記レベル５以上のレベルの前記ハイティアの前記最低圧縮率は４である
請求項１３に記載の符号化装置。 - 前記符号化規格は、H.265/HEVC規格であり、
前記符号化部は、H.265/HEVC規格に従って、前記画像を符号化する
請求項１４に記載の符号化装置。 - 符号化装置が、
画像を符号化する際の最低圧縮率が複数のティアのそれぞれに対して設定されたプロファイルを有する符号化規格に従って、再帰的に分割されたブロックを単位として、画像を符号化する符号化ステップ
を含む符号化方法。
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2014002047 | 2014-01-08 | ||
| JP2014002047 | 2014-01-08 | ||
| JP2014003739 | 2014-01-10 | ||
| JP2014003739 | 2014-01-10 | ||
| PCT/JP2014/084229 WO2015105003A1 (ja) | 2014-01-08 | 2014-12-25 | 復号装置および復号方法、並びに、符号化装置および符号化方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPWO2015105003A1 true JPWO2015105003A1 (ja) | 2017-03-23 |
Family
ID=53523840
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2015556767A Pending JPWO2015105003A1 (ja) | 2014-01-08 | 2014-12-25 | 復号装置および復号方法、並びに、符号化装置および符号化方法 |
Country Status (4)
| Country | Link |
|---|---|
| US (2) | US10523952B2 (ja) |
| JP (1) | JPWO2015105003A1 (ja) |
| CN (3) | CN110572650B (ja) |
| WO (1) | WO2015105003A1 (ja) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9860535B2 (en) * | 2015-05-20 | 2018-01-02 | Integrated Device Technology, Inc. | Method for time-dependent visual quality encoding for broadcast services |
| WO2017023829A1 (en) * | 2015-07-31 | 2017-02-09 | Stc.Unm | System and methods for joint and adaptive control of rate, quality, and computational complexity for video coding and video delivery |
| GB2593776A (en) * | 2020-04-03 | 2021-10-06 | Sony Group Corp | Video data encoding and decoding |
| AU2020203330B2 (en) | 2020-05-21 | 2022-12-01 | Canon Kabushiki Kaisha | Method, apparatus and system for encoding and decoding a block of video samples |
| WO2021246791A1 (ko) * | 2020-06-03 | 2021-12-09 | 엘지전자 주식회사 | 영상/비디오 코딩 시스템에서 상위 레벨 신택스를 처리하는 방법 및 장치 |
| KR20230023709A (ko) * | 2020-06-03 | 2023-02-17 | 엘지전자 주식회사 | 영상/비디오 코딩 시스템에서 일반 제한 정보를 처리하는 방법 및 장치 |
| US11523137B2 (en) | 2020-06-09 | 2022-12-06 | FG Innovation Company Limited | Device and method for decoding video data using general constraints information |
| WO2023048012A1 (ja) * | 2021-09-27 | 2023-03-30 | ソニーグループ株式会社 | 画像処理装置および方法 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007336573A (ja) * | 2004-08-17 | 2007-12-27 | Matsushita Electric Ind Co Ltd | 画像符号化装置、画像復号化装置 |
| WO2013065431A1 (ja) * | 2011-11-04 | 2013-05-10 | シャープ株式会社 | 画像復号装置、画像復号方法および画像符号化装置 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2006025388A1 (ja) * | 2004-08-31 | 2006-03-09 | Matsushita Electric Industrial Co., Ltd. | 動画像符号化方法及び装置 |
| US7826536B2 (en) * | 2005-12-29 | 2010-11-02 | Nokia Corporation | Tune in time reduction |
| JP2008193627A (ja) * | 2007-01-12 | 2008-08-21 | Mitsubishi Electric Corp | 画像符号化装置、画像復号装置、および画像符号化方法、画像復号方法 |
| KR20120088488A (ko) * | 2011-01-31 | 2012-08-08 | 한국전자통신연구원 | 시간적 움직임 벡터 저장 방법 및 그 장치 |
| JP2013110540A (ja) * | 2011-11-18 | 2013-06-06 | Sony Corp | 画像データ送信装置、画像データ送信方法、画像データ受信装置および画像データ受信方法 |
| WO2013181821A1 (en) * | 2012-06-07 | 2013-12-12 | Mediatek Singapore Pte. Ltd. | Improved intra transform skip mode |
| US9270994B2 (en) * | 2012-06-29 | 2016-02-23 | Cisco Technology, Inc. | Video encoder/decoder, method and computer program product that process tiles of video data |
-
2014
- 2014-12-25 CN CN201910911337.0A patent/CN110572650B/zh active Active
- 2014-12-25 CN CN202311280470.3A patent/CN117459724A/zh active Pending
- 2014-12-25 WO PCT/JP2014/084229 patent/WO2015105003A1/ja active Application Filing
- 2014-12-25 US US15/037,204 patent/US10523952B2/en active Active
- 2014-12-25 JP JP2015556767A patent/JPWO2015105003A1/ja active Pending
- 2014-12-25 CN CN201480072111.1A patent/CN105874801B/zh active Active
-
2019
- 2019-09-27 US US16/585,899 patent/US10893279B2/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007336573A (ja) * | 2004-08-17 | 2007-12-27 | Matsushita Electric Ind Co Ltd | 画像符号化装置、画像復号化装置 |
| WO2013065431A1 (ja) * | 2011-11-04 | 2013-05-10 | シャープ株式会社 | 画像復号装置、画像復号方法および画像符号化装置 |
Non-Patent Citations (4)
| Title |
|---|
| JIANLE CHEN, ET AL.: "High efficiency video coding (HEVC) scalable extension Draft 4", JCTVC-1008_V3[ONLINE], JPN6019001621, 7 December 2013 (2013-12-07), pages 49, ISSN: 0004074429 * |
| TERUHIKO SUZUKI: "On MinCR[online]", JCTVC-P0044, JPN6018027719, 4 January 2014 (2014-01-04), pages 1 - 3, ISSN: 0004074428 * |
| 大久保 榮, Ｈ．２６５／ＨＥＶＣ教科書, vol. 第1版, JPN6018027720, 21 October 2013 (2013-10-21), pages 97 - 99, ISSN: 0004074431 * |
| 大久保 榮, Ｈ．２６５／ＨＥＶＣ教科書, vol. 第1版, JPN6019001623, 21 October 2013 (2013-10-21), pages 298 - 299, ISSN: 0004074430 * |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2015105003A1 (ja) | 2015-07-16 |
| CN105874801B (zh) | 2019-11-08 |
| US20200029083A1 (en) | 2020-01-23 |
| US10893279B2 (en) | 2021-01-12 |
| CN105874801A (zh) | 2016-08-17 |
| CN110572650B (zh) | 2023-10-27 |
| CN110572650A (zh) | 2019-12-13 |
| CN117459724A (zh) | 2024-01-26 |
| US10523952B2 (en) | 2019-12-31 |
| US20160295217A1 (en) | 2016-10-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6219823B2 (ja) | 画像処理装置および方法、並びに記録媒体 | |
| US10893279B2 (en) | Decoding apparatus and decoding method, and coding apparatus and coding method | |
| US10448057B2 (en) | Image processing device and method | |
| JP6287035B2 (ja) | 復号装置および復号方法 | |
| WO2015053115A1 (ja) | 復号装置および復号方法、並びに、符号化装置および符号化方法 | |
| US20130329008A1 (en) | Encoding apparatus, encoding method, decoding apparatus, and decoding method | |
| US10148959B2 (en) | Image coding device and method, and image decoding device and method | |
| WO2015053116A1 (ja) | 復号装置および復号方法、並びに、符号化装置および符号化方法 | |
| WO2015098561A1 (ja) | 復号装置および復号方法、並びに、符号化装置および符号化方法 | |
| JP2015005899A (ja) | 復号装置および復号方法、並びに、符号化装置および符号化方法 | |
| WO2015056566A1 (ja) | 画像処理装置および方法 | |
| WO2015098559A1 (ja) | 復号装置および復号方法、並びに、符号化装置および符号化方法 | |
| WO2015053112A1 (ja) | 復号装置および復号方法、並びに、符号化装置および符号化方法 | |
| KR102338669B1 (ko) | 화상 처리 장치 및 방법, 및 기록 매체 | |
| JP6477930B2 (ja) | 符号化装置および符号化方法 | |
| WO2016199574A1 (ja) | 画像処理装置および画像処理方法 | |
| JP6402802B2 (ja) | 画像処理装置および方法、プログラム、並びに記録媒体 | |
| WO2015053111A1 (ja) | 復号装置および復号方法、並びに、符号化装置および符号化方法 | |
| JP2015050738A (ja) | 復号装置および復号方法、並びに、符号化装置および符号化方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20171030 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20180724 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20180827 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20190122 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20190711 |