JP6193365B2 - パラメータセットにおけるスケーラビリティ情報のシグナリング - Google Patents

パラメータセットにおけるスケーラビリティ情報のシグナリング Download PDF

Info

Publication number
JP6193365B2
JP6193365B2 JP2015514270A JP2015514270A JP6193365B2 JP 6193365 B2 JP6193365 B2 JP 6193365B2 JP 2015514270 A JP2015514270 A JP 2015514270A JP 2015514270 A JP2015514270 A JP 2015514270A JP 6193365 B2 JP6193365 B2 JP 6193365B2
Authority
JP
Japan
Prior art keywords
layer
scalability
picture
bits
information
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.)
Active
Application number
JP2015514270A
Other languages
English (en)
Other versions
JP2015536052A (ja
Inventor
サーチン ジー. デシュパンダ
サーチン ジー. デシュパンダ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of JP2015536052A publication Critical patent/JP2015536052A/ja
Application granted granted Critical
Publication of JP6193365B2 publication Critical patent/JP6193365B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods 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/187Methods 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 a scalable video layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods 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/103Selection of coding mode or of prediction mode
    • H04N19/105Selection of the reference unit for prediction within a chosen coding or prediction mode, e.g. adaptive choice of position and number of pixels used for prediction
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134Methods 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/136Incoming video signal characteristics or properties
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/189Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the adaptation method, adaptation tool or adaptation type used for the adaptive coding
    • H04N19/196Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the adaptation method, adaptation tool or adaptation type used for the adaptive coding being specially adapted for the computation of encoding parameters, e.g. by averaging previously computed encoding parameters
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/30Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using hierarchical techniques, e.g. scalability
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/46Embedding additional information in the video signal during the compression process
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70Methods 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)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Description

本発明は、ビデオの符号化および復号に関する。
電子デバイスは、消費者のニーズを満たして携帯性および利便性を高めるために、小型化・強化されてきた。消費者は、電子デバイスに依存するようになり、機能性の増大を期待するようになっている。電子デバイスのいくつかの例としては、デスクトップコンピュータ、ラップトップコンピュータ、携帯電話、スマートフォン、メディアプレーヤ、集積回路などが挙げられる。
一部の電子デバイスは、デジタルメディアの処理および/または表示に使用される。例えば、携帯用電子デバイスは、現在では、消費者が存在しうるほぼすべての場所で、デジタルメディアの生成および/または消費を可能にする。さらに、一部の電子デバイスは、消費者により使用および享受されるデジタルメディアコンテンツのダウンロードまたはストリーミングを提供することができる。
デジタルビデオは、典型的には、一連の画像またはフレームとして表現され、そのそれぞれが画素の配列を含む。各画素は、輝度および/または色情報などの情報を含む。多くの場合、各画素は3色のセットとして表現される。一部のビデオ符号化方式は、複雑さの増大と引き換えに、符号化効率の向上をもたらす。ビデオ符号化方式に対する画像品質要件の増大および画像解像度要件の増大も、符号化の複雑さを増大させる。
デジタルメディアの人気が増すことで、いくつかの問題が生じた。例えば、高品質のデジタルメディアを記憶、伝送、および再生のために効率的に表現することは、いくつかの課題を提起する。デジタルメディアをより効率的に表現する方式は、有益である。
本発明によれば、ビデオビットストリームを復号する方法が提供され、本方法は、
相互に隣接し、符号化ツリーブロック、少なくとも1つのスライス、および少なくとも1つのタイルをグループで構成する符号化単位のグループを含む前記ビデオの複数のフレームを受信するステップを含み、符号化ツリーブロックのグループが、前記少なくとも1つのスライス内に含まれ、符号化ツリーブロックのグループが、前記少なくとも1つのタイル内に含まれ、前記少なくとも1つのスライスおよび前記少なくとも1つのタイルそれぞれは、すべてが相互に整列されてはおらず、前記少なくとも1つのタイルそれぞれは、タイルが、イントラ予測情報、動き情報を含め、他の前記少なくとも1つのタイルとは独立して復号されることを特徴とし、前記少なくとも1つのタイルそれぞれは、タイルが前記フレームの或る領域であり、前記復号のための符号化単位を有することを特徴とし、前記フレームの前記少なくとも1つのタイルは、前記フレームのラスタ走査順に集合的に配列される。
以下の本発明の詳細な説明を添付の図面とともに考慮することで、本発明の前述の目的ならびにその他の目的、特徴、および利点がより容易に理解される。
HEVC(High Efficiency Video Coding:高効率ビデオ符号化)エンコーダを含む電子デバイスの一構成を示すブロック図である。 HEVCデコーダを含む電子デバイスの一構成を示すブロック図である。 エンコーダおよびデコーダの一例を示すブロック図である。 電子デバイスにおいて利用されうる様々なコンポーネントを示す。 例示のスライス構造を示す。 別の例示のスライス構造を示す。 1つのスライスおよび9つのタイルを有するフレームを示す。 3つのスライスおよび3つのタイルを有するフレームを示す。 様々なNALユニットヘッダシンタックスを示す。 様々なNALユニットヘッダシンタックスを示す。 様々なNALユニットヘッダシンタックスを示す。 一般的なNALユニットシンタックスを示す。 既存のビデオパラメータセットを示す。 既存のスケーラビリティタイプを示す。 例示のビデオパラメータセットを示す。 例示のスケーラビリティマップシンタックスを示す。 例示のビデオパラメータセットを示す。 既存のビデオパラメータセットを示す。 既存の次元タイプ、次元idシンタックスを示す。 例示のビデオパラメータセットを示す。 例示のスケーラビリティマップシンタックスを示す。 例示のビデオパラメータセットを示す。 例示のビデオパラメータセットを示す。 例示のビデオパラメータセットを示す。 例示のスケーラビリティマスクシンタックスを示す。 例示のビデオパラメータセット拡張シンタックスを示す。 例示のビデオパラメータセット拡張シンタックスを示す。 例示のビデオパラメータセット拡張シンタックスを示す。 例示のビデオパラメータセット拡張シンタックスを示す。 例示のビデオパラメータセット拡張シンタックスを示す。 例示のビデオパラメータセット拡張シンタックスを示す。
国際電気通信連合標準化部門(ITU−T:International Telecommunication Union Telecommunication Standardization Sector)第16研究委員会(SG16:Study Group 16)第3作業部会(WP3:Working Party 3)、および国際標準化機構/国際電気標準会議(ISO/IEC:International Organization for Standardization/International Electrotechnical Commission)第1合同専門委員会/第29小委員会/第11作業部会(JTC1/SC29/WG11:Joint Technical Committee 1/Subcommittee 29/Working Group 11)のビデオ符号化に関する協同作業チーム(JCT−VC:Joint Collaborative Team on Video Coding)は、高効率ビデオ符号化標準(HEVC)と呼ばれるビデオ符号化標準のための標準化作業を開始した。HEVCは、ブロックベースの符号化を使用する。
HEVCでは、変換および量子化された係数(TQC:Transformed and Quantized Coefficient)を損失なしに圧縮するために、エントロピー符号化方式であるコンテキスト適応型2値算術符号化CABAC(Context−Adaptive Binary Arithmetic Coding)))が使用される。TQCは、変換サイズに応じて、様々なブロックサイズからとすればよい(例えば4×4、8×8、16×16、32×32)。
2次元(2D)TQCは、エントロピー符号化の前に1次元(1D)配列に変換されうる。一例では、4×4ブロックの2D配列TQCは、表(1)に示されているように配列されうる。
Figure 0006193365
2D TQCを1D配列に変換するとき、ブロックは、斜めジグザグ式に走査されうる。引き続きこの例を用いる。表(1)に示された2D配列TQCは、第1行第1列、第1行第2列、第2行第1列、第3行第1列、第2行第2列、第1行第3列、第1行第4列、第2行第3列、第3行第2列、第4行第1列などと走査することにより、1D配列TQC[4,0,3,−3,2,1,0,−1,0,…]に変換することができる。
例えば、HEVCにおける符号化手順は以下のように進行しうる。1D配列のTQCが、走査位置(scanning position)に従って順序付けられる。最後の有意係数の走査位置および最後の係数レベルが判断される。最後の有意係数が符号化される。なお、係数は、典型的には走査と逆の順序で符号化される。ラン−レベル符号化が実行される。ラン−レベル符号化は、数値自体を符号化するのではなく、同一の数値および/またはビットのランについての情報を符号化する。この符号化は、最後の係数の符号化後、直ちに開始される。続いて、レベル符号化が実行される。有意係数という用語は、ゼロより大きい係数レベル値を有する係数をいう。係数レベル値とは、変換および量子化された係数(TQC)値の大きさ(すなわち絶対値)の一意の指示をいう。
(1D配列TQC[4,0,3,−3,2,1,0,−1,0,…]を用いる)上記の例の続きとして、この手順を表(2)に示すことができる。
Figure 0006193365
表(2)では、例として、走査位置7にある係数レベル−1が、最後の非ゼロ係数であってもよい。よって、最終位置は走査位置7であり、最終係数レベルは−1である。ラン−レベル符号化が、走査位置6、5、および4にある係数0、1、および2に対して実行される(係数は、走査と逆の順序で符号化される)。続いて、係数レベル−3、3、0、および4に対してレベル符号化が実行される。
図1は、ビデオの符号化が行われうる電子デバイス102の一構成を示すブロック図である。なお、電子デバイス102内に含まれるものとして示される構成要素のうちの1つ以上は、ハードウェア、ソフトウェア、または両方の組み合わせに実装されうる。例えば、電子デバイス102はエンコーダ108を含むが、エンコーダ108は、ハードウェア、ソフトウェア、または両方の組み合わせに実装されうる。例えば、エンコーダ108は、回路、集積回路、特定用途向け集積回路(ASIC:application−specific integrated circuit)、実行可能命令を有するメモリと電子通信するプロセッサ、ファームウェア、フィールドプログラマブルゲートアレイ(FPGA:field−programmable gate array)などとして、またはその組み合わせとして実装されうる。一部の構成では、エンコーダ108は、高効率ビデオ符号化(HEVC)コーダであってもよい。
電子デバイス102は、供給器104を含んでもよい。供給器104は、ピクチャまたは画像データ(例えばビデオ)を、情報源106としてエンコーダ108に供給することができる。供給器104の例としては、イメージセンサ、メモリ、通信インターフェース、ネットワークインターフェース、無線受信機、ポートなどが挙げられる。
情報源106は、フレーム内予測モジュールおよび再構築バッファ110に供給されてもよい。情報源106はさらに、動き推定・動き補償モジュール136に供給されて、減算モジュール116に供給されてもよい。
フレーム内予測モジュールおよび再構築バッファ110は、情報源106および再構築データ150に基づいて、イントラモード情報128およびイントラ信号112を発生させることができる。動き推定・動き補償モジュール136は、情報源106および参照ピクチャバッファ166信号168に基づいて、インターモード情報138およびインター信号114を発生させることができる。参照ピクチャバッファ166信号168は、参照ピクチャバッファ166に記憶された1つ以上の参照ピクチャからのデータを含むことができる。
エンコーダ108は、モードに従って、イントラ信号112とインター信号114とから選択を行うことができる。イントラ信号112は、イントラ符号化モードにおいて、ピクチャ内の空間的特徴を利用するために使用することができる。インター信号114は、インター符号化モードにおいて、ピクチャ間の時間的特徴を利用するために使用することができる。イントラ符号化モードの間は、イントラ信号112が減算モジュール116に供給されるとよく、イントラモード情報128がエントロピー符号化モジュール130に供給されるとよい。インター符号化モードの間は、インター信号114が減算モジュール116に供給されるとよく、インターモード情報138がエントロピー符号化モジュール130に供給されるとよい。
予測残差118を生成するために、(モードに応じて)イントラ信号112またはインター信号114のいずれかが、減算モジュール116にて情報源106から減算される。予測残差118は、変換モジュール120に供給される。変換モジュール120は、予測残差118を圧縮して変換信号122を生成することができ、変換信号122は、量子化モジュール124に供給される。量子化モジュール124は、変換信号122を量子化して、変換および量子化された係数(TQC)126を生成する。
TQC126は、エントロピー符号化モジュール130および逆量子化モジュール140に供給される。逆量子化モジュール140は、TQC126に対して逆量子化を実行して逆量子化信号142を生成し、逆量子化信号142は、逆変換モジュール144に供給される。逆変換モジュール144は、逆量子化信号142を伸張して伸張信号146を生成し、伸張信号146は、再構築モジュール148に供給される。
再構築モジュール148は、伸張信号146に基づいて再構築データ150を生成することができる。例えば、再構築モジュール148は、(変更された)ピクチャを再構築することができる。再構築データ150は、デブロッキングフィルタ152と、イントラ予測モジュールおよび再構築バッファ110とに供給されてもよい。デブロッキングフィルタ152は、再構築データ150に基づいて、フィルタされた信号154を生成することができる。
フィルタされた信号154は、サンプル適応オフセット(SAO:sample adaptive offset)モジュール156に供給されてもよい。SAOモジュール156は、エントロピー符号化モジュール130に供給されるSAO情報158、および適応ループフィルタ(ALF:adaptive loop filter)162に供給されるSAO信号160を生成することができる。ALF162は、ALF信号164を生成し、ALF信号164は、参照ピクチャバッファ166に供給される。ALF信号164は、参照ピクチャとして使用できる1つ以上のピクチャからのデータを含んでもよい。場合によっては、ALF162は省かれてもよい。
エントロピー符号化モジュール130は、TQC126を符号化してビットストリーム134を生成することができる。上記のように、TQC126は、エントロピー符号化の前に1D配列に変換されてもよい。さらに、エントロピー符号化モジュール130は、CAVLCまたはCABACを使用してTQC126を符号化することができる。具体的には、エントロピー符号化モジュール130は、イントラモード情報128、インターモード情報138、およびSAO情報158のうちの1つ以上に基づいてTQC126を符号化することができる。ビットストリーム134は、符号化されたピクチャデータを含むことができる。
HEVCなどのビデオ圧縮に関わる量子化は、或る範囲の値を単一の量子値に圧縮することにより達成される、損失の多い圧縮方式である。量子化パラメータ(QP:quantization parameter)は、再構築されたビデオの品質および圧縮率の両方に基づいて量子化を実行するために使用される、事前定義されたスケーリング・パラメータである。ブロックタイプは、特定のブロックの特徴をブロックサイズおよびその色情報に基づいて表現するよう、HEVCにおいて定義されている。エントロピー符号化の前に、QP、解像度情報、およびブロックタイプが判断されてもよい。例えば、電子デバイス102(例えばエンコーダ108)が、QP、解像度情報、およびブロックタイプを判断してもよく、これらがエントロピー符号化モジュール130に供給されてもよい。
エントロピー符号化モジュール130は、TQC126のブロックに基づいてブロックサイズを求めてもよい。例えば、ブロックサイズは、TQCのブロックの1次元方向のTQC126の数であってもよい。すなわち、TQCのブロック内のTQC126の数は、ブロックサイズの2乗と等しくてもよい。さらに、ブロックは非正方形であってもよく、この場合、TQC126の数は、ブロックの高さかける幅である。例として、ブロックサイズは、TQCのブロック内のTQC126の数の平方根として求められてもよい。解像度は、画素幅かける画素高さと定義されうる。解像度情報は、ピクチャの幅、ピクチャの高さ、または両方の画素数を含んでもよい。ブロックサイズは、TQCの2Dブロックの1次元方向のTQCの数と定義されてもよい。
一部の構成では、ビットストリーム134は別の電子デバイスへ送信されてもよい。例えば、ビットストリーム134は、通信インターフェース、ネットワークインターフェース、無線送信機、ポートなどに供給されてもよい。例として、ビットストリーム134は、ローカルエリアネットワーク(LAN:Local Area Network)、インターネット、携帯電話基地局などを介して別の電子デバイスへ送信されてもよい。さらに、または代わりに、ビットストリーム134は、電子デバイス102上のメモリに記憶されてもよい。
図2は、高効率ビデオ符号化(HEVC)デコーダとされてもよいデコーダ272を含む電子デバイス270の一構成を示すブロック図である。デコーダ272およびデコーダ272に含まれるものとして示されている構成要素のうちの1つ以上は、ハードウェア、ソフトウェア、または両方の組み合わせに実装されうる。デコーダ272は、復号されるビットストリーム234(例えばビットストリーム234に含まれる1つ以上の符号化ピクチャ)を受信するとよい。一部の構成では、受信されたビットストリーム234は、受信されたスライスヘッダ、受信されたピクチャパラメータセット(PPS:picture parameter set)、受信されたバッファ記述情報、分類指示などの、受信されたオーバーヘッド情報を含んでもよい。
ビットストリーム234からの受信されたシンボル(例えば符号化されたTQC)は、エントロピー復号モジュール274によってエントロピー復号されうる。これにより、動き情報信号298ならびに復号済みの変換および量子化された係数(TQC)278を生成することができる。
動き情報信号298は、動き補償モジュール294にてフレームメモリ290からの復号ピクチャ292の一部と組み合わされてもよく、これによりフレーム間予測信号296を生成することができる。復号済みの変換および量子化された係数(TQC)278は、逆量子化・逆変換モジュール280によって逆量子化および逆変換されてもよく、それによって復号残差信号282が生成される。復号残差信号282は、加算モジュール207によって予測信号205に加算されて、結合信号284が生成されうる。予測信号205は、動き補償モジュール294によって生成されたフレーム間予測信号296、またはフレーム内予測モジュール201によって生成されたフレーム内予測信号203のいずれかから選択された信号とされうる。一部の構成では、この信号選択は、ビットストリーム234に基づいて(例えばそれにより制御されて)もよい。
フレーム内予測信号203は、(例えば現フレームにおいて)以前に復号された結合信号284からの情報から予測されうる。結合信号284はさらに、デブロッキングフィルタ286によってフィルタされてもよい。結果として生じるフィルタされた信号288は、サンプル適応オフセット(SAO)モジュール231に供給されてもよい。SAOモジュール231は、フィルタされた信号288と、エントロピー復号モジュール274からの情報239とに基づいてSAO信号235を生成することができ、SAO信号235は、適応ループフィルタ(ALF)233に供給される。ALF233は、ALF信号237を生成し、ALF信号237は、フレームメモリ290に供給される。ALF信号237は、参照ピクチャとして使用できる1つ以上のピクチャからのデータを含んでもよい。ALF信号237は、フレームメモリ290に書き込まれてもよい。結果として生じるALF信号237は、復号ピクチャを含んでもよい。場合によっては、ALF233は省かれてもよい。
フレームメモリ290は、復号ピクチャバッファ(DPB:decoded picture buffer)を含んでもよい。フレームメモリ290はさらに、復号ピクチャに対応するオーバーヘッド情報を含んでもよい。例えば、フレームメモリ290は、スライスヘッダ、ピクチャパラメータセット(PPS)情報、サイクルパラメータ、バッファ記述情報などを含んでもよい。これらの情報のうちの1つ以上は、コーダ(例えばエンコーダ108)からシグナリングされてもよい。
フレームメモリ290は、1つ以上の復号ピクチャ292を動き補償モジュール294に供給してもよい。さらに、フレームメモリ290は、デコーダ272から出力することができる1つ以上の復号ピクチャ292を供給してもよい。この1つ以上の復号ピクチャ292は、例えば、ディスプレイ上で提示されても、メモリに記憶されても、または別のデバイスへ送信されてもよい。
図3は、エコーダ308およびデコーダ372の一例を示すブロック図である。この例では、電子デバイスA302および電子デバイスB370が示されている。なお、一部の構成では、電子デバイスA302および電子デバイスB370に関して記載される特徴および機能性が、単一の電子デバイスに組み合わされてもよいことに留意されたい。
電子デバイスA302は、エンコーダ308を含む。エンコーダ308は、ハードウェア、ソフトウェア、または両方の組み合わせに実装されうる。一構成では、エンコーダ308は、高効率ビデオ符号化(HEVC)コーダであってもよい。他のコーダも同様に使用されうる。電子デバイスA302は、情報源306を取得することができる。一部の構成では、情報源306は、イメージセンサを使用して電子デバイスA302上で捕捉されても、メモリから読み出されても、または別の電子デバイスから受信されてもよい。
エンコーダ308は、情報源306を符号化してビットストリーム334を生成することができる。例えば、エンコーダ308は、情報源306中の一連のピクチャ(例えばビデオ)を符号化してもよい。エンコーダ308は、図1に関して上述したエンコーダ108と類似していてもよい。
ビットストリーム334は、情報源306に基づく符号化されたピクチャデータを含んでもよい。一部の構成では、ビットストリーム334はさらに、スライスヘッダ情報、PPS情報などのオーバーヘッドデータを含んでもよい。情報源306中のさらなるピクチャが符号化されるのに伴い、ビットストリーム334は、1つ以上の符号化ピクチャを含むことができる。
ビットストリーム334は、デコーダ372に供給されてもよい。一例では、ビットストリーム334は、有線リンクまたは無線リンクを使用して電子デバイスB370へ送信されうる。場合によっては、この送信は、インターネットまたはローカルエリアネットワーク(LAN)などのネットワーク上で行われてもよい。図3に示されているように、デコーダ372は、電子デバイスA302上のエンコーダ308とは別個に、電子デバイスB370上に実装されてもよい。なお、一部の構成ではエンコーダ308およびデコーダ372が同じ電子デバイス上に実装されうるということに留意されたい。例として、エンコーダ308およびデコーダ372が同じ電子デバイス上に実装される実装においては、ビットストリーム334は、バスを介してデコーダ372に供給されても、またはデコーダ372による読み出しのためにメモリに記憶されてもよい。
デコーダ372は、ハードウェア、ソフトウェア、または両方の組み合わせに実装されうる。一構成では、デコーダ372は、高効率ビデオ符号化(HEVC)デコーダであってもよい。他のデコーダも同様に使用されうる。デコーダ372は、図2に関して上述したデコーダ272と類似していてもよい。
図4は、電子デバイス409において利用されうる様々なコンポーネントを示す。電子デバイス409は、各電子デバイスのうちの1つ以上として実装されうる。例えば、電子デバイス409は、図1に関して上述した電子デバイス102として、または図2に関して上述した電子デバイス270として、または両方として実装されうる。
電子デバイス409は、電子デバイス409の動作を制御するプロセッサ417を含む。プロセッサ417は、CPUと呼ばれることもある。メモリ411は、読み取り専用メモリ(ROM:read−only memory)、ランダムアクセスメモリ(RAM:random access memory)の両方、または情報を記憶できる任意のタイプのデバイスを含むことができ、命令413a(例えば実行可能命令)およびデータ415aをプロセッサ417に供給する。メモリ411の一部はさらに、不揮発性ランダムアクセスメモリ(NVRAM:non−volatile random access memory)を含んでもよい。メモリ411は、プロセッサ417と電子通信することができる。
プロセッサ417にも命令413bおよびデータ415bが存在してもよい。プロセッサ417にロードされた命令413bおよび/またはデータ415bはさらに、プロセッサ417による実行または処理のためにロードされた、メモリ411からの命令413aおよび/またはデータ415aを含んでもよい。命令413bは、本願明細書に開示される1つ以上の技術を実装するためにプロセッサ417によって実行されてもよい。
電子デバイス409は、他の電子デバイスと通信するために、1つ以上の通信インターフェース419を含んでもよい。通信インターフェース419は、有線通信技術、無線通信技術、または両方に基づきうる。通信インターフェース419の例としては、シリアルポート、パラレルポート、ユニバーサルシリアルバス(USB:Universal Serial Bus)、イーサネットアダプタ、IEEE1394バスインターフェース、小型コンピュータシステムインターフェース(SCSI:small computer system interface)バスインターフェース、赤外線(IR:infrared)通信ポート、Bluetooth無線通信アダプタ、第3世代パートナーシッププロジェクト(3GPP:3rd Generation Partnership Project)規格に従った無線送受信機などが挙げられる。
電子デバイス409は、1つ以上の出力デバイス423および1つ以上の入力デバイス421を含んでもよい。出力デバイス423の例としては、スピーカ、プリンタなどが挙げられる。電子デバイス409に含まれうる出力デバイスの1つのタイプは、ディスプレイデバイス425である。本願明細書に開示される構成とともに使用されるディスプレイデバイス425は、陰極線管(CRT:cathode ray tube)、液晶ディスプレイ(LCD:liquid crystal display)、発光ダイオード(LED:light−emitting diode)、ガスプラズマ、エレクトロルミネセンス、または同様のものなど、任意の適切な画像投影技術を利用しうる。メモリ411に記憶されたデータを、ディスプレイ425上に示されるテキスト、グラフィックス、および/または動画に(適宜)変換するために、ディスプレイコントローラ427が提供されてもよい。入力デバイス421の例としては、キーボード、マウス、マイクロホン、リモートコントロールデバイス、ボタン、ジョイスティック、トラックボール、タッチパッド、タッチスクリーン、ライトペンなどが挙げられる。
電子デバイス409の様々なコンポーネントは、バスシステム429によって結合される。バスシステム429は、データバスに加えて、電力バス、制御信号バス、およびステータス信号バスを含みうる。なお、明瞭にするために、この種々のバスが、図4ではバスシステム429として示されている。図4に示されている電子デバイス409は、特定のコンポーネントのリストではなく、機能ブロック図である。
「コンピュータ可読媒体」という用語は、コンピュータまたはプロセッサによりアクセスされうる利用可能な任意の媒体を指す。本願明細書で使用される「コンピュータ可読媒体」という用語は、非一時的かつ有形のコンピュータ可読媒体および/またはプロセッサ可読媒体を意味しうる。限定ではなく例として、コンピュータ可読媒体またはプロセッサ可読媒体は、RAM、ROM、EEPROM、CD−ROM、もしくはその他の光ディスクストレージ、磁気ディスクストレージ、もしくは他の磁気ストレージデバイス、またはそのほか、コンピュータまたはプロセッサによってアクセスできる命令もしくはデータ構造の形態の所望のプログラムコードを搬送または記憶するために使用できる任意の媒体を含みうる。本願明細書で使用されるディスク(disk)およびディスク(disc)には、コンパクトディスク(CD:compact disc)、レーザディスク(laser disc)、光ディスク(optical disc)、デジタルバーサタイルディスク(DVD:digital versatile disc)、フロッピーディスク(floppy disk)およびBlu−ray(登録商標)ディスク(disc)が含まれ、ディスク(disk)は、通常、磁気的にデータを再生し、ディスク(disc)は、レーザを用いて光学的にデータを再生する。デコーダおよび/またはエンコーダのためのコードは、コンピュータ可読媒体上に記憶されてもよい。
複数の符号化ツリーブロック(例えば本願明細書で概してブロックと呼ばれる)を含む入力ピクチャが、1つまたはいくつかのスライスへと分割されてもよい。エンコーダおよびデコーダにて使用される参照ピクチャが同一であり、デブロッキングフィルタリングがスライス境界を越える情報を使用しないという条件の下で、スライスが表現するピクチャの区域中のサンプルの値を、他のスライスからのデータを使用せずに適切に復号することができる。したがって、或るスライスに対するエントロピー復号およびブロック再構築は、他のスライスに依存しない。具体的には、エントロピー符号化の状態は、各スライスの開始時にリセットされうる。他のスライス中のデータは、エントロピー復号および再構築両方のための近傍利用可能性を定義する際に、利用不可能としてマークされうる。各スライスは、並列にエントロピー復号され、再構築されうる。好適には、イントラ予測および動きベクトル予測は、スライスの境界を越えることができない。これに対し、デブロッキングフィルタリングは、スライス境界を越える情報を使用することもできる。
図5は、水平方向に11のブロックおよび垂直方向に9つのブロックを含む例示のビデオピクチャ500を示す(9つの例示のブロックが501〜509と標示されている)。図5は、3つの例示のスライス、すなわち、「スライス#0」と示された第1スライス520、「スライス#1」と示された第2スライス530、および「スライス#2」と示された第3スライス540を示す。デコーダは、3つのスライス520、530、540を並列に復号し、再構築することができる。各スライスは、逐次方式で走査線の順に送信されうる。各スライスに対する復号/再構築処理の開始時に、コンテキストモデルが初期化またはリセットされ、他のスライス中のブロックは、エントロピー復号およびブロック再構築の両方に対し利用不可能としてマークされる。コンテキストモデルは、一般に、エントロピーエンコーダおよび/またはエントロピーデコーダの状態を表現する。したがって、例えば503と標示されたブロックなどの「スライス#1」中のブロックに対して、「スライス#0」中のブロック(例えば501および502と標示されたブロック)をコンテキストモデル選択または再構築のために使用することはできない。一方、例えば505と標示されたブロックなどの「スライス#1」中のブロックに対して、「スライス#1」中の他のブロック(例えば503および504と標示されたブロック)をコンテキストモデル選択または再構築のために使用することはできる。したがって、エントロピー復号およびブロック再構築は、スライス内で順次進行する。スライスがフレキシブルブロック順序付け(FMO:flexible block ordering)を用いて定義されている場合を除いて、スライス内のブロックは、ラスタ走査の順に処理される。
図6は、「スライスグループ#0」と示された第1スライスグループ550、「スライスグループ#1」と示された第2スライスグループ560、および「スライスグループ#2」と示された第3スライスグループ570の3つのスライスグループへの、例示のブロック割り当てを示す。これらのスライスグループ550、560、570は、それぞれピクチャ580中の2つの前景領域および1つの背景領域に関連しうる。
図5に示されたスライスの配列は、ラスタ走査またはラスタ走査順としても知られる画像走査順に、一対のブロック間に各スライスを定義することに限定されうる。この走査順のスライスの配列は、計算効率は良いが、高効率並列符号化および復号には適さない傾向がある。さらに、スライスをこのように走査順に定義すると、符号化の効率化に非常に適した共通特徴を有する可能性が高い、画像の中のより小さな局所領域がグループ化されない傾向もある。図6に示されたスライスの配列は、その配列においては極めて柔軟であるが、高効率並列符号化または復号には適さない傾向がある。さらに、この極めて柔軟なスライスの定義は、デコーダでの実装が計算的に複雑である。
図7を参照する。或るタイル方式によって、画像が矩形(正方形を含む)領域のセットに分割されている。各タイル内のブロック(あるいは、一部のシステムでは最大符号化単位または符号化ツリーブロックと呼ばれる)は、ラスタ走査順に符号化および復号される。タイルの配列も、同様にラスタ走査順に符号化および復号される。よって、任意の適切な数の列の境界が存在してよく(例えば0以上)、任意の適切な数の行の境界が存在してよい(例えば0以上)。よって、フレームは、図7に示された1つのスライスなど、1つ以上のスライスを定義することができる。いくつかの実施形態では、異なるタイルに位置するブロックは、隣接するブロックの情報に依存するイントラ予測、動き補償、エントロピー符号化コンテキスト選択、またはその他の処理に利用できない。
図8を参照する。このタイル方式によって、画像が3つの矩形列のセットへと分割されているのが示されている。各タイル内のブロック(あるいは、一部のシステムでは最大符号化単位または符号化ツリーブロックと呼ばれる)は、ラスタ走査順に符号化および復号される。タイルも、同様にラスタ走査順に符号化および復号される。1つ以上のスライスを、タイルの走査順に定義することができる。各スライスは、独立して復号可能である。例えば、スライス1は、ブロック1〜9を含むように定義されてもよく、スライス2は、ブロック10〜28を含むように定義されてもよく、スライス3は、3つのタイルにまたがるブロック29〜126を含むように定義されてもよい。タイルを使用すると、より局所的なフレームの領域のデータを処理することにより符号化の効率化が促進される。
当然のことながら、場合によっては、ビデオ符号化は、任意選択でタイルを含まなくてもよいし、さらに任意選択でビデオのフレームに対する波面符号化/復号パターンの使用を含んでもよい。このようにして、ビデオの1つ以上のライン(1行以上のマクロブロック(あるいは符号化ツリーブロック)の複数のグループなどであって、該グループそれぞれが波面サブストリームを表す、が並列方式で符号化/復号されてもよい。概して、ビデオの分割は、任意の適切な方式で構成されればよい。
ビデオ符号化標準は、多くの場合、限定された周波数帯域幅および/または限定された記憶容量を有するチャネル上で送信するためにビデオデータを圧縮する。これらビデオ符号化標準は、フレームをより効果的に符号化および復号するために、イントラ予測、空間領域から周波数領域への変換、量子化、エントロピー符号化、動き推定、および動き補償などの複数の符号化段階を含むことができる。符号化および復号段階の多くは、計算が過度に複雑である。
様々なスケーラブルビデオ符号化方式が開発されてきた。スケーラブルビデオ符号化では、プライマリビットストリーム(一般的に基本レイヤビットストリームと呼ばれる)がデコーダによって受信される。さらに、デコーダは、1つ以上のセカンダリビットストリーム(単数または複数)(一般的に拡張レイヤ(単数または複数)と呼ばれる)を受信しうる。各拡張レイヤの機能は、基本レイヤビットストリームの品質改善、基本レイヤビットストリームのフレームレート向上、および/または基本レイヤビットストリームの画素解像度改善とすることもできる。品質スケーラビリティは、信号対雑音比(SNR:Signal−to−Noise Ratio)スケーラビリティとも呼ばれる。フレームレートスケーラビリティは、時間スケーラビリティとも呼ばれる。解像度スケーラビリティは、空間スケーラビリティとも呼ばれる。
拡張レイヤ(単数または複数)は、基本レイヤビットストリームの他の特徴を変更しうる。例えば、拡張レイヤは、基本レイヤと異なるアスペクト比および/または視野角に関連しうる。拡張レイヤの別の側面は、基本レイヤおよび拡張レイヤが、別々のビデオ符号化標準に対応してもよいということである。例えば、基本レイヤは、MPEG−2(動画専門家集団2:Motion Pictures Experts Group2)であってもよく、拡張レイヤは、HEVC−Ext(高効率ビデオ符号化拡張)であってもよい。
Figure 0006193365
拡張レイヤ(単数または複数)は、(基本レイヤに加えて)相互に依存関係にあってもよい。一例では、拡張レイヤ2は、拡張レイヤ1の少なくとも一部の構文解析および/または再構築が成功している場合(かつ基本レイヤの少なくとも一部の構文解析および/または再構築が成功している場合)に限り使用可能である。
符号化されたビデオのビットストリームは、一般にネットワーク抽象化レイヤ(NAL:Network Abstraction Layer)ユニットと呼ばれる論理データパケットに入れられるシンタックス構造を含みうる。各NALユニットは、関連するデータペイロードの目的を特定する、2バイトNALユニットヘッダ(例えば16ビット)などのNALユニットヘッダを含む。例えば、各符号化スライス(および/またはピクチャ)は、1つ以上のスライス(および/またはピクチャ)NALユニットに符号化されうる。他のNALユニットが、他のカテゴリのデータ、例えば、付加拡張情報、時間サブレイヤアクセス(TSA:temporal sub−layer access)ピクチャの符号化スライス、段階的時間サブレイヤアクセス(STSA:step−wise temporal sub−layer access)ピクチャの符号化スライス、非TSA、非STSA後続(trailing)ピクチャの符号化スライス、ブロークンリンクアクセスピクチャの符号化スライス、瞬時復号更新ピクチャの符号化スライス、クリーンランダムアクセスピクチャの符号化スライス、復号可能なリーディングピクチャの符号化スライス、破棄標識付き(tagged for discard)ピクチャの符号化スライス、ビデオパラメータセット、シーケンスパラメータセット、ピクチャパラメータセット、アクセスユニットデリミタ、エンドオブシーケンス、エンドオブビットストリーム、フィラーデータ、および/またはシーケンス拡張情報メッセージなどのために含まれてもよい。必要に応じて、他のNALユニットタイプが含まれてもよい。
ランダムアクセスポイントピクチャ(RAP:random access point)ピクチャは、Iスライスのみを含み、ブロークンリンクアクセス(BLA:broken link access)ピクチャ、クリーンランダムアクセス(CRA:clean random access)ピクチャ、または瞬時復号更新(IDR:instantaneous decoding refresh)ピクチャとすることができる。ビットストリーム中の第1ピクチャは、RAPピクチャである。
ブロークンリンクアクセスピクチャ(BLA)ピクチャは、RAPピクチャの一種である。BLAピクチャは、Iスライスのみを含み、復号順でビットストリーム中の第1ピクチャとすることも、またはビットストリーム中の後の方で出現することもできる。各BLAピクチャは、新たな符号化ビデオシーケンスを開始し、IDRピクチャと同じ効果を復号処理に対して有する。なお、BLAピクチャは、代わりにこれがCRAピクチャであったとしたら空でない参照ピクチャセットを指定することになるシンタックス要素を含む。ビットストリーム中、BLAピクチャが検出されると、これらのシンタックス要素は無視され、代わりに参照ピクチャセットは、空のセットとして初期化される。
クリーンランダムアクセス(CRA)ピクチャは、RAPピクチャの一種である。CRAピクチャは、Iスライスのみを含み、復号順でビットストリーム中の第1ピクチャとすることも、またはビットストリーム中の後の方で出現することもできる。CRAピクチャは、関連する復号可能なリーディングピクチャ(DLP:decodable leading picture)および破棄標識付き(TFD:Tagged for discard)ピクチャを有することもある。
瞬時復号更新(IDR)ピクチャは、RAPピクチャの一種である。IDRピクチャは、Iスライスのみを含み、復号順でビットストリーム中の第1ピクチャとすることも、またはビットストリーム中の後の方で出現することもできる。各IDRピクチャは、復号順で符号化ビデオシーケンスの第1ピクチャである。
復号可能なリーディングピクチャ(DLP)は、リーディングピクチャである。DLPピクチャは、関連する同一RAPピクチャの後続ピクチャの復号処理のための参照ピクチャとしては使用されない。
破棄標識付き(TFD)ピクチャは、関連するBLAまたはCRAピクチャのリーディングピクチャである。関連するRAPピクチャがBLAピクチャであるか、またはビットストリーム中の第1符号化ピクチャである場合、そのTFDピクチャはビットストリーム中に存在しない参照ピクチャに対する参照を含むかもしれないため、このTFDピクチャは出力されず、正しく復号可能でないこともある。
リーディングピクチャは、出力順で、関連するRAPピクチャに先行するピクチャである。
後続ピクチャは、出力順で、関連するRAPピクチャに後続するピクチャである。
NALユニットは、ピクチャのコンテンツを表現するビデオ符号化レイヤ(VCL:video coding layer)データを様々なトランスポートレイヤにマッピングする能力を提供する。NALユニットは、符号化ピクチャを含むか、または他の関連データを含むかに応じて、それぞれVCL NALユニットおよび非VCL NALユニットに分類されうる。B.ブロズ(Bros)、W−J.ハン(Han)、J−R.オーム(Ohm)、G.J.サリバン(Sullivan)、およびT−.ウィーガント(Wiegand)著、「高効率ビデオ符号化(HEVC)テキスト規格第8案(High efficiency video coding(HEVC)text specification draft 8)」、JCTVC−J10003、ストックホルム(Stockholm)、2012年7月、イエ−クイ・ワン(Ye−Kui Wang)著、「拡張のための上位シンタックス計画に関する分科会(BoG on high−level syntax for extension planning)」、JCTVC−J00574、2012年7月、およびイエ−クイ・ワン(Ye−Kui Wang)著、「拡張のための上位シンタックス計画に関する分科会(BoG on high−level syntax for extension planning)」、JCTVC−J00574r1、2012年7月は、その内容全体を参照により本願明細書に引用したものとする。
図9Aを参照する。NALユニットヘッダシンタックスは、2バイトのデータ、すなわち16ビットを含むことができる。第1ビットは、「forbidden_zero_bit」であり、このビットは常にNALユニットの先頭でゼロにセットされる。次の6ビットは、「nal_unit_type」であり、このビットは、NALユニットに含まれるローバイトシーケンスペイロード(「RBSP:raw byte sequence payload」)データ構造のタイプを指定する。次の6ビットは、「nuh_reserved_zero_6bits」である。nuh_reserved_zero_6bitsは、標準の基本規格では0と等しくすることができる。必要に応じて、他の値のnuh_reserved_zero_6bitsが指定されうる。デコーダは、標準の基本規格に基づいてストリームを処理する場合、0と等しくないnuh_reserved_zero_6bitsの値を有するすべてのNALユニットを無視(すなわちビットストリームから除去して破棄)してよい。スケーラブルその他の拡張では、スケーラブルビデオ符号化および/またはシンタックス拡張をシグナリングするために、nuh_reserved_zero_6bitsが他の値を指定してもよい。場合によっては、シンタックス要素nuh_reserved_zero_6bitsが、reserved_zero_6bitsと呼ばれることもある。場合によっては、シンタックス要素nuh_reserved_zero_6bitsが、図9Bおよび図9Cに示されているように、layer_id_plus1またはlayer_idと呼ばれることもある。この場合、要素layer_idは、layer_id_plus1マイナス1となる。この場合、この要素は、スケーラブル符号化ビデオのレイヤに関する情報をシグナリングするために使用されてもよい。次のシンタックス要素は、「nuh_temporal_id_plus1」である。nuh_temporal_id_plus1マイナス1は、NALユニットの時間識別子を指定できる。可変の時間識別子TemporalIdは、TemporalId=nuh_temporal_id_plus1−1として指定されてもよい。
図10を参照する。一般的なNALユニットシンタックス構造が示されている。図9のNALユニットヘッダ2バイトシンタックスは、図10のnal_unit_header()に対する参照に含まれている。NALユニットシンタックスの残りの部分は、主としてRBSPに関係する。
「nuh_reserved_zero_6bits」を使用する1つの既存方式は、別々のビットフィールドへと、すなわち、スケーラブル符号化ビデオの異なるレイヤの識別情報をそれぞれ参照する、依存ID、品質ID、ビューID、および深度フラグのうちの1つ以上へと、nuh_reserved_zero_6bitsの6ビットを分割することにより、スケーラブルビデオ符号化情報をシグナリングすることである。したがって、この6ビットは、この特定のNALユニットが、スケーラブル符号化方式のどのレイヤに属するかを示す。続いて、図11に示されているビデオパラメータセット(「VPS:video parameter set」)拡張シンタックス(「scalability_type」)などのデータペイロードにおいて、レイヤについての情報が定義される。図11のVPS拡張シンタックスは、符号化ビデオシーケンスにおいて使用されているスケーラビリティタイプおよびNALユニットヘッダにおいてlayer_id_plus1(またはlayer_id)を用いてシグナリングされる次元を指定する、スケーラビリティタイプ(シンタックス要素scalability_type)のための4ビットを含む。スケーラビリティタイプが0と等しい場合、符号化ビデオシーケンスは、基本規格に準拠し、よって、すべてのNALユニットのlayer_id_plus1は、0と等しく、拡張レイヤまたはビューに属するNALユニットは存在しない。スケーラビリティタイプのより大きな値は、図12に示されるように解釈される。
layer_id_dim_len[i]は、第iスケーラビリティ次元IDのビット長を指定する。0〜7の範囲のすべてのi値に関する値layer_id_dim_len[i]の合計は、6以下である。vps_extension_byte_alignment_reserved_zero_bitは、ゼロである。vps_layer_id[i]は、後続のレイヤ依存情報が適用される第iレイヤのlayer_idの値を指定する。num_direct_ref_layers[i]は、第iレイヤが直接依存するレイヤの数を指定する。ref_layer_id[i][j]は、第iレイヤが直接依存する第jレイヤを識別する。
このようにして、既存方式は、スケーラビリティ識別子をNALユニットおよびビデオパラメータセットにおいてシグナリングして、ビットを図12に列挙されたスケーラビリティタイプに割り当てる。さらに、図12は、各スケーラビリティタイプについていくつの次元がサポートされるかを定義する。例えば、スケーラビリティタイプ1は、2つの次元(すなわち空間および品質)を有する。この次元それぞれに関して、layer_id_dim_len[i]は、これら2つの次元それぞれに割り当てられたビットの数を定義し、layer_id_dim_len[i]のすべての値の総計は、6以下であり、6とは、NALユニットヘッダのnuh_reserved_zero_6bits内のビットの数である。したがって、組み合わせると、この方式により、どのタイプのスケーラビリティが使用されているか、およびNALユニットの6ビットがどのようにスケーラビリティに割り当てられるかが特定される。
そのような、図12に示されている種々のスケーラビリティ次元の固定された組み合わせは、多くの用途に適するが、望ましい組み合わせで含まれていないものがある。図13を参照する。変更されたビデオパラメータセット拡張シンタックスは、nuh_reserved_zero_6bits要素内の各ビットについてスケーラビリティタイプを指定する。vps_extension_byte_alignment_reserved_zero_bitは、0にセットされる。max_num_layers_minus1_bitsは、図9のNALユニットヘッダの最初の2バイト内のlayer_id_plus1またはnuh_reserved_zero_6bitsと呼ばれるシンタックス要素に使用されるビットの総数を示す。scalability_map[i]は、layer_id_plus1シンタックス要素内の各ビットのスケーラビリティタイプを指定する。場合によっては、layer_id_plus1シンタックス要素は、代わりにnuh_reserved_zero_6bitsまたはrserved_zero_6bitsシンタックス要素と呼ばれることもある。シンタックス要素layer_id_plus1のビット全部に対するスケーラビリティマップは、その符号化ビデオシーケンスにおいて使用されるスケーラビリティを指定する。各スケーラビリティタイプの識別子の実際の値は、NALユニットヘッダ内のlayer_id_plus1(nuh_reserved_zero_6bits)フィールド内の対応する当該ビットを用いてシグナリングされる。scalability_map[i]がすべてのiの値について0と等しい場合、符号化ビデオシーケンスは、基本規格に準拠し、よって、NALユニットのlayer_id_plus1値は、0と等しく、拡張レイヤまたはビューに属するNALユニットは存在しない。vps_layer_id[i]は、後続のレイヤ依存情報が適用される第iレイヤのlayer_idの値を指定する。num_direct_ref_layers[i]は、第iレイヤが直接依存するレイヤの数を指定する。ref_layer_id[i][j]は、第iレイヤが直接依存する第jレイヤを識別する。
scalability_map[i]のより大きな値は、図14に示されているように解釈される。scalability map [i]は、(0)なし、(1)空間、(2)品質、(3)深度、(4)マルチビュー、(5)未指定、(6)予約、および(7)予約のスケーラビリティ次元を含む。
したがって、NALユニットヘッダ内の各ビットは、スケーラビリティ次元が何であるか、ビデオパラメータセット内の3ビットに基づいて解釈される(例えば、なし、空間、品質、深度、マルチビュー、未指定、予約)。例として、layer_id_plus1内のすべてのビットが空間スケーラビリティに対応することをシグナリングするために、VPS内のscalability_map値が、NALユニットヘッダの6ビットに対して001 001 001 001 001 001として符号化されてもよい。さらに例として、layer_id_plus1内の3ビットが空間スケーラビリティに対応し、3ビットが品質スケーラビリティに対応することをシグナリングするために、VPS内のscalability_map値が、NALユニットヘッダの6ビットに対して001 001 001 010 010 010として符号化されてもよい。
図15を参照する。別の実施形態は、num_scalability_dimensions_minus1を使用して、NALユニットヘッダの6ビットにおけるスケーラビリティ次元の数をシグナリングするビデオパラメータセットを含む。num_scalability_dimensions_minus1プラス1は、layer_id_plus1、nuh_reserved_zero_6bits、および/またはreserved_zero_6bitsシンタックス要素を用いてシグナリングされるスケーラビリティ次元の数を示す。scalability_map[i]は、図13に関して上述したのと同じセマンティクスを有する。num_bits_for_scalability_map[i]は、第iスケーラビリティ次元のビット長を指定する。num_bits_for_scalability_map[i]、i=0,…num_scalability_dimensions_minus1、のすべての合計は、6と等しい(あるいは、layer_id_plus1、vps_reserved_zero_6bits、max_num_layers_minus1、reserved_zero_6bits、nuh_reserved_zero_6bitsシンタックス要素に使用されるビットの数と等しい)。
図13および図15に関して、必要に応じて他の変形が使用されてもよい。例えば、一実施形態では、scalability_map[i]は、u(4)(またはn>3もしくはn<3であるu(n))を用いてシグナリングされてもよい。この場合、scalability_map[i]のより大きな値は、ビデオ方式の特定のプロファイルに適合するビットストリーム用に予約されたものとして指定されうる。例えば、スケーラビリティマップ値6…15は、u(4)を用いてscalability_map[i]をシグナリングする場合、「予約」と指定されてもよい。別の実施形態では、例えば、scalability_map[i]は、ue(v)またはその他何らかの符号化スキームを用いてシグナリングされてもよい。別の実施形態では、例えば、scalability_map[i]値が単調非減少(または非増加)順に配列されるように、制約が指定されてもよい。これにより、NALユニットヘッダ内のlayer_id_plus1フィールド内の個々のスケーラビリティ次元フィールドが連続的となる。
「layer_id_plus1」または「nuh_reserved_zero_6bits」シンタックス要素を使用してスケーラブルビデオ符号化をシグナリングするもう1つの既存方式は、ビデオパラメータセット内で全体的なルックアップテーブルをシグナリングすることにより、NALユニットヘッダ内のlayer_id_plus1をレイヤ識別情報にマッピングすることである。図16を参照する。この既存方式は、ルックアップテーブルの第iレイヤの次元タイプおよび次元識別情報の数を指定するビデオパラメータセットを含む。具体的には、vps_extension_byte_alignment_reserved_zero_bitは、ゼロである。num_dimensions_minus1[i]プラス1は、第iレイヤの次元タイプ(dimension_type[i][j])および次元識別子(dimension_id[i][j])の数を指定する。図17に規定されているように、dimension_type[i][j]は、第iレイヤの第jスケーラビリティ次元タイプを指定し、第iレイヤは、iと等しいlayer_idまたはlayer_id_plus1を有する。図17に示されているように、識別される次元には、(0)ビューオーダidx、(1)深度フラグ、(2)依存ID、(3)品質ID、(4)〜(15)予約が含まれる。dimension_id[i][j]は、第iレイヤの第jスケーラビリティ次元タイプの識別子を指定し、存在しない場合は0と推定される。num_direct_ref_layers[i]は、第iレイヤが直接依存するレイヤの数を指定する。ref_layer_id[i][j]は、第iレイヤが直接依存する第jレイヤを識別する。残念ながら、図16に示した提案される実施形態は、実用的でないほど大きなルックアップテーブルをもたらす。
図18を参照する。変更されたビデオパラメータセット拡張には、スケーラビリティ次元と組み合わせて使用されるスケーラビリティマスクが含まれる。scalability_mask[i]は、0および1のビットのパターンをシグナリングし、各ビットは、図19のスケーラビリティマップシンタックスにより示される1つのスケーラビリティ次元に対応する。特定のスケーラビリティ次元に対する1の値は、当該レイヤ(第iレイヤ)において当該スケーラビリティ次元が存在することを示す。特定のスケーラビリティ次元に対する0の値は、当該レイヤ(第iレイヤ)において当該スケーラビリティ次元が存在しないことを示す。例えば、00100000のビットのセットは、品質スケーラビリティを指す。存在する特定のスケーラビリティ次元の実際の識別子の値は、シグナリングされるscalability_id[j]値により示される。num_scalability_types[i]の値は、1の値を有するscalability_mask内のビットの数の合計と等しい。したがって、以下の通りとなる。
Figure 0006193365
scalability_id[j]は、scalability_mask値によってシグナリングされるスケーラビリティタイプ値の、第jスケーラビリティ次元の識別子の値を示す。
図18の1つの変形である図20を参照する。この変形には、ループ外でシグナリングされるスケーラビリティマスクが含まれる。これは、各レイヤ識別情報に対し1つの共通マスクをもたらす。図21を参照する。この変形では、対応する例示のビデオパラメータセットは、スケラ−ビリティマスクが含まれていない状態で、スケーラブル識別情報を含むことができる。この場合、シンタックス要素scalability_id[j]は、図18のシンタックス要素scalability_id[j]と同じ解釈である。
図22を参照する。図18の1つの変形には、ループ外でシグナリングされるスケーラビリティマスク(scalability_mask)が含まれる。これは、各レイヤ識別情報に対し1つの共通マスクをもたらす。scalability_maskは、0および1のビットのパターンをシグナリングし、各ビットは、図23のスケーラビリティマップシンタックスにより示される1つのスケーラビリティ次元に対応する。特定のスケーラビリティ次元に対する1の値は、当該レイヤ(第iレイヤ)において当該スケーラビリティ次元が存在することを示す。特定のスケーラビリティ次元に対する0の値は、当該レイヤ(第iレイヤ)において当該スケーラビリティ次元が存在しないことを示す。例えば、00100000のビットのセットは、品質スケーラビリティを指す。存在する特定のスケーラビリティ次元の実際の識別子の値は、シグナリングされるscalability_id[j]値により示される。num_scalability_types[i]の値は、1の値を有するscalability_mask内のビットの数の合計と等しい。したがって、以下の通りとなる。
Figure 0006193365
この場合、scalability_id[j]変数は、代わりにdimension_id[i][j]変数と呼ばれてもよい。dimension_id[i][j]は、第iレイヤの第jスケーラビリティ次元のスケーラビリティ識別子を指定する。その結果、変数ScalabilityId[i][j]が、以下のように得られる。
Figure 0006193365
ScalabilityId[i][k]は、対応するスケーラビリティタイプの次元IDを次のようにシグナリングする。
Figure 0006193365
ScalabilityId[i][0]は、第iレイヤの空間スケーラビリティ次元の依存IDであり、ScalabilityId[i][1]は、第iレイヤの品質スケーラビリティ次元の品質IDであり、ScalabilityId[i][2]は、第iレイヤの深度スケーラビリティ次元の深度フラグ/深度IDであり、ScalabilityId[i][3]は、第iレイヤのマルチビュースケーラビリティ次元のビューIDである。
さらに、図22において、1と等しいavc_base_codec_flagは、基本レイヤがRec.ITU−T H.264|ISO/IEC14496−10に準拠することを指定し、1と等しいavc_base_codec_flagは、HEVCに準拠することを指定する。vps_nuh_layer_id_presnet_flagは、NALユニットヘッダ内のlayer_idの値をシグナリングするlayer_id_in_nuh[i]変数がシグナリングされるかどうかを示す。
別の実施形態では、シンタックス要素scalability_mask[i]、scalability_mask、scalability_id[j]のうちの1つ以上が、u(8)以外のビット数を使用してシグナリングされてもよい。例えば、これらシンタックス要素は、u(16)(またはn>8もしくはn<8であるu(n))を用いてシグナリングできるであろう。別の実施形態では、これらシンタックス要素のうちの1つ以上を、ue(v)を用いてシグナリングできるであろう。別の実施形態では、scalability_maskは、NALユニットヘッダ内で、layer_id_plus1、vps_reserved_zero_6bits、max_num_layers_minus1、reserved_zero_6bits、および/またはnuh_reserved_zero_6bitsシンタックス要素においてシグナリングされうる。いくつかの実施形態では、システムは、このシグナリングを、VPS NALユニットのみ、または非VPS NALユニットのみ、またはすべてのNALユニットに対して行ってもよい。さらに別の実施形態では、scalability_maskは、ビットストリーム中の任意の位置で、ピクチャ毎にシグナリングされてもよい。例えば、scalability_maskは、スライスヘッダ、ピクチャパラメータセット、ビデオパラメータセット、またはその他任意のパラメータセット、またはそのほか、ビットストリームの任意の標準的な部分においてシグナリングされうる。
なお、図13、図15、図18、図20、図21、図22、図23、および対応する記載は、6ビットに言及するが、これは、図9のNALユニットヘッダ内のシンタックス要素nuh_reserved_zero_6bitsまたはlayer_id_plus1が6ビットを有するからである。しかしながら、当該シンタックス要素が6ビット以外のビット数を使用したとしても、上記の記載はすべて、適宜変更することができる。例えば、当該シンタックス要素(nuh_reserved_zero_6bitsまたはlayer_id_plus1)が代わりに9ビットを使用したとすると、その結果、図13において、max_num_layer_minus1ビットの値は9になり、scalability_map[i]は、6ビットではなく9ビットそれぞれに関してシグナリングされることになる。
図24を参照する。図22の1つの変形は、レイヤ依存情報をシグナリングするためのシンタックスを提供する。新たなシンタックス要素layer_dependency_information_patternが定義される。
layer_dependency_information_patternは、vps_max_layers_minus1と等しい長さの0および1のビットのパターンをシグナリングする。第iビットの0の値は、layer_id(i+1)を有するレイヤが独立したレイヤであることを示す。第iビットの1の値は、layer_id(i+1)を有するレイヤが他のレイヤの1つ以上に依存する依存レイヤであることを示す。
NumDepLayersの値は、layer_dependency_information_patternの中で1の値を有するビットの数の合計と等しい。したがって、以下の通りとなる。
Figure 0006193365
図25を参照する。図22の1つの変形は、レイヤ依存情報をシグナリングするためのシンタックスを提供する。新たなシンタックス要素layer_dependency_flag[i]が定義される。layer_dependency_flag[i]は、レイヤが他のレイヤに依存するかどうかをシグナリングする。このフラグの0の値は、layer_id iを有するレイヤが独立したレイヤであることを示す。第iビットの1の値は、layer_id iを有するレイヤが依存レイヤであることを示す。
図26を参照する。図22の1つの変形は、レイヤ依存情報をシグナリングするためのシンタックスを提供する。新たなシンタックス要素layer_dependency_map[i]が定義される。layer_dependency_map[i]は、vps_max_layers_minus1と等しい長さの0および1のビットのパターンをシグナリングする。layer_dependency_map[i]の第kビットの0の値は、レイヤiが、layer_id(k+1)を有するレイヤに依存しないことを示す。layer_dependency_map[i]の第kビットの1の値は、レイヤiが、layer_id(k+1)を有するレイヤに依存することを示す。
図27を参照する。図22の1つの変形は、レイヤ依存情報をシグナリングするためのシンタックスを提供する。新たなシンタックス要素layer_dependency_information_patternが定義される。layer_dependency_information_patternは、vps_max_layers_minus1と等しい長さの0および1のビットのパターンをシグナリングする。第iビットの0の値は、layer_id(i+1)を有するレイヤが独立したレイヤであることを示す。第iビットの1の値は、layer_id(i+1)を有するレイヤが他のレイヤの1つ以上に依存する依存レイヤであることを示す。NumDepLayersの値は、layer_dependency_information_patternの中で1の値を有するビットの数の合計と等しい。したがって、以下の通りとなる。
Figure 0006193365
layer_dependency_map[i]は、NumDepLayersと等しい長さの0および1のビットのパターンをシグナリングする。layer_dependency_map[i]の第kビットの0の値は、レイヤiが、layer_id(k+1)を有するレイヤに依存しないことを示す。layer_dependency_map[i]の第kビットの1の値は、レイヤiが、layer_id(k+1)を有するレイヤに依存することを示す。
図28を参照する。図22の1つの変形は、レイヤ依存情報をシグナリングするためのシンタックスを提供する。図28は、図22のシンタックスに基づく派生シンタックスである。新たなシンタックス要素layer_dependency_information_patternが定義される。
layer_dependency_information_patternは、vps_max_layers_minus1と等しい長さの0および1のビットのパターンをシグナリングする。第iビットの0の値は、layer_id(i+1)を有するレイヤが独立したレイヤであることを示す。第iビットの1の値は、layer_id(i+1)を有するレイヤが他のレイヤの1つ以上に依存する依存レイヤであることを示す。
NumDepLayersの値は、layer_dependency_information_patternの中で1の値を有するビットの数の合計と等しい。したがって、以下の通りとなる。
Figure 0006193365
シンタックス要素num_direct_ref_layers[i]およびref_layer_id[i][j]は、layer_dependency_information_pattern(i)が1の値を有するときのみシグナリングされる。layer_depdndency_information_pattern(i)は、シンタックス要素layer_dependency_patternの第iビットである。
図29を参照する。図22の1つの変形は、レイヤ依存情報をシグナリングするためのシンタックスを提供する。図29は、図22のシンタックスに基づく派生シンタックスである。新たなシンタックス要素layer_dependency_information_patternが定義される。
layer_dependency_information_patternは、vps_max_layers_minus1と等しい長さの0および1のビットのパターンをシグナリングする。第iビットの0の値は、layer_id(i+1)を有するレイヤが独立したレイヤであることを示す。第iビットの1の値は、layer_id(i+1)を有するレイヤが他のレイヤの1つ以上に依存する依存レイヤであることを示す。
NumDepLayersの値は、layer_dependency_information_patternの中で1の値を有するビットの数の合計と等しい。したがって、以下の通りとなる。
Figure 0006193365
layer_dependency_map[i]は、vps_max_layers_minus1と等しい長さの0および1のビットのパターンをシグナリングする。layer_dependency_map[i]の第kビットの0の値は、レイヤiが、layer_id(k+1)を有するレイヤに依存しないことを示す。layer_dependency_map[i]の第kビットの1の値は、レイヤiが、layer_id(k+1)を有するレイヤに依存することを示す。シンタックス要素layer_dependency_map[i]は、layer_dependency_information_pattern(i)が1の値を有するときのみシグナリングされる。layer_depdndency_information_pattern(i)は、シンタックス要素layer_dependency_patternの第iビットである。
別の実施形態では、layer_dependency_information_patternシンタックス要素は、1ビットフラグ値のセットとしてシグナリングされてもよい。この場合、以下のように合計vps_max_layers_minus1の1ビット値がシグナリングされることになる。
Figure 0006193365
別の実施形態では、layer_dependency_map[i]シンタックス要素は、1ビットフラグ値のセットとしてシグナリングされてもよい。この場合、以下のように合計vps_max_layers_minus1の1ビット値がシグナリングされることになる。
Figure 0006193365
別の実施形態では、シンタックス要素layer_dependency_information_pattern、layer_dependency_mapの1つ以上が、u(v)ではなく、既知の固定数のビットを使用してシグナリングされうる。例えば、これらのシンタックス要素を、u(64)を使用してシグナリングできるであろう。
別の実施形態では、シンタックス要素layer_dependency_information_pattern、layer_dependency_mapの1つ以上が、ue(v)またはその他何らかの符号化スキームを用いてシグナリングされてもよい。
別の実施形態では、記載されたシンタックスおよびセマンティクスと比較して、plus1またはplus2の加算、またはminus1またはminus2の減算によって、様々なシンタックス要素の名前およびセマンティクスが変更されてもよい。
さらに別の実施形態では、layer_dependency_information_pattern、layer_dependency_map、layer_dependency_flag[i]などの様々なシンタックス要素が、ビットストリーム中の任意の位置で、ピクチャ毎にシグナリングされてもよい。例えば、これらシンタックス要素は、スライスヘッダ、pps/sps/vps/apsもしくはその他任意のパラメータセット、またはビットストリームの他の標準的な部分においてシグナリングされうる。
前述の明細書中で用いた用語および語句は、明細書において説明の用語として使用されており、限定するものではなく、かかる用語および語句を使用するにあたり、示され記載された特徴またはその一部の等価物を排除する意図はなく、当然のことながら、本発明の範囲は、添付の特許請求の範囲によってのみ定義および限定される。

Claims (1)

  1. ビデオパラメータセットにおいてスケーラビリティ情報をシグナリングする方法、
    (a)前記ビデオパラメータセットを受信するステップ、
    (b)前記ビデオパラメータセットに含まれたスケーラビリティマスク信号を識別するステップであって、前記スケーラビリティマスク信号は、0および1のビットのパターンで構成され、前記ビットのそれぞれは1つのスケーラビリティ次元に対応し、前記ビットの値が0または1であることは前記ビットに対応する前記スケーラビリティ次元が存在しないことまたは存在することを示し、前記スケーラビリティマスク信号における1の値を有するビットの数の合計はシグナリングされるスケーラビリティタイプの個数を示す、前記ステップ、
    (c)前記スケーラビリティマスク信号に基づいて前記スケーラビリティタイプをシグナリングするステップ。
JP2015514270A 2012-09-30 2013-09-25 パラメータセットにおけるスケーラビリティ情報のシグナリング Active JP6193365B2 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201261708029P 2012-09-30 2012-09-30
US61/708,029 2012-09-30
US201261727572P 2012-11-16 2012-11-16
US61/727,572 2012-11-16
US201361749150P 2013-01-04 2013-01-04
US61/749,150 2013-01-04
PCT/JP2013/005671 WO2014050090A1 (en) 2012-09-30 2013-09-25 Signaling scalability information in a parameter set

Publications (2)

Publication Number Publication Date
JP2015536052A JP2015536052A (ja) 2015-12-17
JP6193365B2 true JP6193365B2 (ja) 2017-09-06

Family

ID=50387527

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015514270A Active JP6193365B2 (ja) 2012-09-30 2013-09-25 パラメータセットにおけるスケーラビリティ情報のシグナリング

Country Status (6)

Country Link
US (1) US20150256838A1 (ja)
EP (1) EP2901702B1 (ja)
JP (1) JP6193365B2 (ja)
CN (1) CN104685885B (ja)
HK (1) HK1212526A1 (ja)
WO (1) WO2014050090A1 (ja)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10805605B2 (en) * 2012-12-21 2020-10-13 Telefonaktiebolaget Lm Ericsson (Publ) Multi-layer video stream encoding and decoding
US9591321B2 (en) 2013-04-07 2017-03-07 Dolby International Ab Signaling change in output layer sets
SG10201913551WA (en) 2013-04-07 2020-03-30 Dolby Int Ab Signaling change in output layer sets
MX352631B (es) 2013-04-08 2017-12-01 Arris Entpr Llc Señalización para adición o remoción de capas en codificación de video.
GB2513303B (en) * 2013-04-16 2017-06-07 Canon Kk Method and device for partitioning an image
US10212437B2 (en) * 2013-07-18 2019-02-19 Qualcomm Incorporated Device and method for scalable coding of video information
EP3056004A2 (en) * 2013-10-11 2016-08-17 VID SCALE, Inc. High level syntax for hevc extensions
US9706228B2 (en) * 2013-10-15 2017-07-11 Qualcomm Incorporated Support for large numbers of views in multi-layer coding
US10034002B2 (en) 2014-05-21 2018-07-24 Arris Enterprises Llc Signaling and selection for the enhancement of layers in scalable video
CA3083172C (en) 2014-05-21 2022-01-25 Arris Enterprises Llc Individual buffer management in transport of scalable video
JP6721631B2 (ja) 2017-07-07 2020-07-15 ノキア テクノロジーズ オーユー ビデオの符号化・復号の方法、装置、およびコンピュータプログラムプロダクト
FR3072850B1 (fr) * 2017-10-19 2021-06-04 Tdf Procedes de codage et de decodage d'un flux de donnees representatif d'une video omnidirectionnelle

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5833682B2 (ja) * 2011-03-10 2015-12-16 ヴィディオ・インコーポレーテッド スケーラブルなビデオ符号化のための依存性パラメータセット
WO2013002709A1 (en) * 2011-06-30 2013-01-03 Telefonaktiebolaget L M Ericsson (Publ) Indicating bit stream subsets
RU2610670C1 (ru) * 2012-12-21 2017-02-14 Телефонактиеболагет Л М Эрикссон (Пабл) Кодирование и декодирование многоуровневого видеопотока
EP2982123A4 (en) * 2013-04-05 2016-09-07 Sharp Kk DECODING INTERMEDIATE REFERENCE IMAGE SETS AND CONSTRUCTING REFERENCE PICTURES
US10212437B2 (en) * 2013-07-18 2019-02-19 Qualcomm Incorporated Device and method for scalable coding of video information

Also Published As

Publication number Publication date
WO2014050090A1 (en) 2014-04-03
EP2901702A1 (en) 2015-08-05
HK1212526A1 (en) 2016-06-10
EP2901702A4 (en) 2016-03-30
CN104685885A (zh) 2015-06-03
JP2015536052A (ja) 2015-12-17
CN104685885B (zh) 2018-09-07
US20150256838A1 (en) 2015-09-10
EP2901702B1 (en) 2018-04-11

Similar Documents

Publication Publication Date Title
JP6193365B2 (ja) パラメータセットにおけるスケーラビリティ情報のシグナリング
US10827189B2 (en) Explicit signaling of scalability dimension identifier information in a parameter set
US9807421B2 (en) NAL unit type restrictions
US9325997B2 (en) Signaling scalability information in a parameter set
US11689733B2 (en) Signaling scalability information in a parameter set
US10397606B2 (en) System for signaling IFR and BLA pictures
JP2016519855A (ja) ランダムアクセスポイント・ピクチャ
US9426468B2 (en) Signaling layer dependency information in a parameter set
EP2923488B1 (en) Signaling scalability information in a parameter set

Legal Events

Date Code Title Description
A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20160107

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160203

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20161206

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170303

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170314

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170614

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170711

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170809

R150 Certificate of patent or registration of utility model

Ref document number: 6193365

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250