JP2019522413A - ディスプレイストリーム圧縮のためのサブストリーム多重化 - Google Patents

ディスプレイストリーム圧縮のためのサブストリーム多重化 Download PDF

Info

Publication number
JP2019522413A
JP2019522413A JP2018563630A JP2018563630A JP2019522413A JP 2019522413 A JP2019522413 A JP 2019522413A JP 2018563630 A JP2018563630 A JP 2018563630A JP 2018563630 A JP2018563630 A JP 2018563630A JP 2019522413 A JP2019522413 A JP 2019522413A
Authority
JP
Japan
Prior art keywords
substream
video data
block
substreams
coding mode
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.)
Granted
Application number
JP2018563630A
Other languages
English (en)
Other versions
JP2019522413A5 (ja
JP6921873B2 (ja
Inventor
ヴィジャヤラガヴァン・ティルマライ
ナタン・ハイム・ジェイコブソン
ラジャン・ラックスマン・ジョシ
Original Assignee
クアルコム，インコーポレイテッド
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 クアルコム，インコーポレイテッド filed Critical クアルコム，インコーポレイテッド
Publication of JP2019522413A publication Critical patent/JP2019522413A/ja
Publication of JP2019522413A5 publication Critical patent/JP2019522413A5/ja
Application granted granted Critical
Publication of JP6921873B2 publication Critical patent/JP6921873B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • 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/103—Selection of coding mode or of prediction mode
    • H04N19/11—Selection of coding mode or of prediction mode among a plurality of spatial predictive coding modes
    • 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/127—Prioritisation of hardware or computational resources
    • 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/146—Data rate or code amount at the encoder output
    • 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/146—Data rate or code amount at the encoder output
    • H04N19/147—Data rate or code amount at the encoder output according to rate distortion criteria
    • 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
    • H04N19/159—Prediction type, e.g. intra-frame, inter-frame or bidirectional frame prediction
    • 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/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/184—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 bits, e.g. of the compressed video stream
    • 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/188—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 a video data packet, e.g. a network abstraction layer [NAL] unit
    • 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/42—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation
    • H04N19/423—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by implementation details or hardware specially adapted for video compression or decompression, e.g. dedicated software implementation characterised by memory arrangements
    • 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/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/593—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving spatial prediction techniques
    • 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)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Abstract

ビデオデータのブロックを記憶するように構成されたメモリと、メモリと通信する1つまたは複数のプロセッサとを備えるビデオデータを符号化するように構成された装置。1つまたは複数のプロセッサは、1つまたは複数のコーディングモードの中から、ビデオデータのブロックを符号化するためのコーディングモードを決定することであって、コーディングモードは、最大シンタックス要素サイズに基づいて決定される、決定することと、ビデオデータの複数の符号化サブストリームを作成するために、決定されたコーディングモードに従って複数のサブストリームにおいてビデオデータのブロックを符号化することと、ビデオデータの複数の符号化サブストリームをそれぞれの平衡先入れ先出し(FIFO)バッファに記憶することと、複数の符号化サブストリームを、ビデオデコーダに送信するためにビットストリームにおいて多重化することとを行うように構成される。

Description

本出願は、2016年6月9日に出願された米国仮出願第62/347,964号、2016年7月7日に出願された米国仮出願第62/359,586号、および2016年11月1日に出願された米国仮出願第62/416,016号の利益を主張し、これらの各々の内容全体が参照により本明細書に組み込まれる。
本開示は、ビデオコーディングおよび圧縮の分野に関し、詳細には、ディスプレイストリーム圧縮などの、ディスプレイリンクを介した送信用のビデオ圧縮に関する。
デジタルコンテンツ能力は、デジタルテレビジョン、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップまたはデスクトップコンピュータ、タブレットコンピュータ、電子ブックリーダー、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲーミングデバイス、ビデオゲームコンソール、セルラー電話または衛星無線電話、いわゆる「スマートフォン」、ビデオ遠隔会議デバイス、ビデオストリーミングデバイスなどを含む、広範囲のデバイスに組み込まれ得る。ソース(たとえば、画像および/またはビデオデータを記憶するメモリ)からディスプレイにコンテンツを転送するために、ディスプレイリンクなどのリンクが使用され得る。たとえば、ディスプレイリンクがセットトップボックスをテレビジョンに、またはコンピュータをディスプレイに接続し得る。
ディスプレイリンクの帯域幅要件は、一般に、ディスプレイの解像度に比例し、したがって、高解像度ディスプレイは大帯域幅ディスプレイリンクから恩恵を受ける。いくつかのディスプレイリンクは、高解像度ディスプレイをサポートするための帯域幅を有しない。高解像度ディスプレイにデジタルビデオを提供するためにより小さい帯域幅のディスプレイリンクが使用され得るように、帯域幅要件を低減するためにビデオ圧縮が使用され得る。他のやり方では、ピクセルデータに対して画像圧縮を利用することを試みた。しかしながら、そのような方式は、時には視覚的ロスレスでなく、または従来のディスプレイデバイスにおいて実装するのが難しく、コストがかかる場合がある。
ビデオエレクトロニクス規格協会(VESA:Video Electronics Standards Association)が、ディスプレイリンクビデオ圧縮のための規格としてディスプレイストリーム圧縮(DSC)を開発した。DSCなどのディスプレイリンクビデオ圧縮技法は、特に、視覚的ロスレスである(すなわち、圧縮がアクティブであることがユーザにわからないようなレベルの品質をピクチャが有する)ピクチャ品質を提供すべきである。ディスプレイリンクビデオ圧縮技法はまた、従来のハードウェアを用いてリアルタイムで実装するのに容易かつ安価な方式を提供すべきである。
本開示のシステム、方法、およびデバイスは、いくつかの発明的態様をそれぞれ有し、それらの態様はどれも、本明細書で開示する望ましい属性を単独で担うものでない。
一般に、本開示は、ディスプレイストリーム圧縮を実行するように構成されたビデオエンコーダおよびビデオデコーダにおいてサブストリーム多重化を実行するための技法について説明する。本開示の技法は、ビデオエンコーダにおいてより小さいバッファを使用し、それによりエンコーダ実装のコストを下げ、場合によっては電力を節約することを可能にし得る。
本開示の一例では、ビデオデータを符号化するための方法が、1つまたは複数のコーディングモードの中から、ビデオデータのブロックを符号化するためのコーディングモードを決定するステップであって、コーディングモードは、最大シンタックス要素サイズに基づいて決定されるステップと、ビデオデータの複数の符号化サブストリームを作成するために、決定されたコーディングモードに従って複数のサブストリームにおいてビデオデータのブロックを符号化するステップと、ビデオデータの複数の符号化サブストリームをそれぞれの平衡先入れ先出し(FIFO)バッファに記憶するステップと、複数の符号化サブストリームを、ビデオデコーダに送信するためにビットストリームにおいて多重化するステップとを含む。
本開示の別の例では、ビデオデータを符号化するように構成された装置が、ビデオデータのブロックを記憶するように構成されたメモリと、メモリと通信する1つまたは複数のプロセッサとを備え、1つまたは複数のプロセッサは、1つまたは複数のコーディングモードの中から、ビデオデータのブロックを符号化するためのコーディングモードを決定することであって、コーディングモードは、最大シンタックス要素サイズに基づいて決定される、決定することと、ビデオデータの複数の符号化サブストリームを作成するために、決定されたコーディングモードに従って複数のサブストリームにおいてビデオデータのブロックを符号化することと、ビデオデータの複数の符号化サブストリームをそれぞれの平衡先入れ先出し(FIFO)バッファに記憶することと、複数の符号化サブストリームを、ビデオデコーダに送信するためにビットストリームにおいて多重化することとを行うように構成される。
本開示の別の例では、ビデオデータを符号化するように構成された装置が、1つまたは複数のコーディングモードの中から、ビデオデータのブロックを符号化するためのコーディングモードを決定するための手段であって、コーディングモードは、最大シンタックス要素サイズに基づいて決定される手段と、ビデオデータの複数の符号化サブストリームを作成するために、決定されたコーディングモードに従って複数のサブストリームにおいてビデオデータのブロックを符号化するための手段と、ビデオデータの複数の符号化サブストリームをそれぞれの平衡先入れ先出し(FIFO)バッファに記憶するための手段と、複数の符号化サブストリームを、ビデオデコーダに送信するためにビットストリームにおいて多重化するための手段とを含む。
別の例では、本開示は、実行されたとき、ビデオデータを符号化するように構成された1つまたは複数のプロセッサに、1つまたは複数のコーディングモードの中から、ビデオデータのブロックを符号化するためのコーディングモードを決定することであって、コーディングモードは、最大シンタックス要素サイズに基づいて決定される、決定することと、ビデオデータの複数の符号化サブストリームを作成するために、決定されたコーディングモードに従って複数のサブストリームにおいてビデオデータのブロックを符号化することと、ビデオデータの複数の符号化サブストリームをそれぞれの平衡先入れ先出し(FIFO)バッファに記憶することと、複数の符号化サブストリームを、ビデオデコーダに送信するためにビットストリームにおいて多重化することとを行わせる命令を記憶するコンピュータ可読記憶媒体について説明する。
新規のシステム、装置、および方法の様々な態様について、添付の図面を参照しながら以下でより十分に説明する。しかしながら、本開示は、多くの異なる形態で具現化されてよく、本開示全体にわたって提示される任意の特定の構造または機能に限定されるものと解釈されるべきでない。むしろ、これらの態様は、本開示が周到で完全になり、本開示の範囲を当業者に十分に伝えるように与えられる。本明細書の教示に基づいて、本開示の範囲は、本開示の任意の他の態様とは無関係に実装されるにせよ、本開示の任意の他の態様と組み合わせて実装されるにせよ、本明細書で開示する新規のシステム、装置、および方法のいかなる態様をもカバーするものであることを、当業者なら諒解されたい。たとえば、本明細書に記載した任意の数の態様を使用して、装置が実装されてよく、または方法が実践されてよい。加えて、本開示の範囲は、本明細書に記載した本開示の様々な態様に加えて、またはそうした態様以外に、他の構造、機能、または構造および機能を使用して実践されるような装置または方法をカバーするものとする。本明細書で開示する任意の態様が特許請求の範囲の1つまたは複数の要素によって具現化され得ることを理解されたい。
特定の態様について本明細書で説明するが、これらの態様の多くの変形および置換が、本開示の範囲内に入る。好ましい態様のいくつかの利益および利点について述べるが、本開示の範囲は特定の利益、使用、または目的に限定されるものではない。むしろ、本開示の態様は、異なるワイヤレス技術、システム構成、ネットワーク、および伝送プロトコルに広く適用可能であるものとし、そのうちのいくつかが例として図面および好ましい態様の以下の説明において示される。詳細な説明および図面は、限定的でなく、本開示の例示にすぎず、本開示の範囲は、添付の特許請求の範囲およびその同等物によって定義される。
添付の図面は例を示す。添付の図面において参照番号によって示される要素は、以下の説明において同様の参照番号によって示される要素に相当する。本開示では、序数語(たとえば、「第1の」、「第2の」、「第3の」など)で始まる名称を有する要素は、必ずしもそれらの要素が特定の順序を有することを暗示するとは限らない。むしろ、そのような序数語は、同じまたは類似のタイプの異なる要素を指すために使用されるにすぎない。
本開示の1つまたは複数の例の詳細が、添付図面および以下の説明に記載される。本開示の他の特徴、目的、および利点は、説明および図面から、また特許請求の範囲から明らかになるであろう。
本開示の技法を実行するように構成され得る例示的なビデオコーディングシステムを示すブロック図である。 本開示の技法を実行するように構成され得る別の例示的なビデオコーディングシステムを示すブロック図である。 本開示の技法を実行するように構成され得る例示的なビデオエンコーダを示すブロック図である。 本開示の技法を実行するように構成され得る例示的なビデオデコーダを示すブロック図である。 量子化パラメータを計算するための1つの例示的な技法を示すグラフである。 例示的なエントロピーコーディング技法を示す概念図である。 例示的なコードワードを示す概念図である。 本開示の一例による量子化残差ブロックグループを示す概念図である。 本開示の一例によるビデオエンコーダにおけるサブストリーム多重化を示すブロック図である。 本開示の一例によるビデオデコーダにおけるサブストリーム逆多重化を示すブロック図である。 サブストリーム多重化におけるmuxワード要求の一例を示す概念図である。 本開示の一例によるビデオデコーダにおけるサブストリーム逆多重化を示す概念図である。 本開示の一例によるビデオデコーダにおける例示的なサブストリーム逆多重化プロセスを示すフローチャートである。 本開示の一例によるビデオエンコーダにおけるサブストリーム多重化を示すブロック図である。 本開示の一例によるビデオエンコーダにおける例示的なサブストリーム多重化プロセスを示すフローチャートである。 本開示の一例によるビデオエンコーダにおける例示的なサブストリーム多重化プロセスを示すフローチャートである。 ブロック予測モードの場合の例示的なサブストリーム構成を示す概念図である。 変換モードの場合の例示的なサブストリーム構成を示す概念図である。 中間点予測モードの場合の例示的なサブストリーム構成を示す概念図である。 パターンモードの場合の例示的なサブストリーム構成を示す概念図である。 ブロック予測スキップモードの場合の例示的なサブストリーム構成を示す概念図である。 中間点予測フォールバックモードの場合の例示的なサブストリーム構成を示す概念図である。 差分パルス符号変調モードの場合の例示的なサブストリーム構成を示す概念図である。 レートバッファにおけるゼロパディングの例示的なプロセスを示すフローチャートである。 本開示の一例による符号化方法を示すフローチャートである。
ビデオ画像、TV画像、静止画像、またはビデオレコーダもしくはコンピュータによって生成された画像などのデジタル画像は、水平ラインおよび垂直ラインをなして配列されたピクセルまたはサンプルを含み得る。単一の画像中のピクセルの数は、通常、4k解像度で数十万から数百万である。各ピクセルは、ルミナンスおよびクロミナンス情報(たとえば、YCrCb)ならびに/または他のカラーフォーマット(たとえば、RGB)によって表され得る。圧縮を用いないと、画像エンコーダから画像デコーダに伝えられるべき莫大な量の情報が、リアルタイム画像送信を非実用的にさせることになる。送信されるべき情報の量を低減するために、JPEG、MPEG、およびH.263規格などの、いくつかの異なる圧縮方法が開発されている。
ビデオコーディング規格は、ITU-T H.261、ISO/IEC MPEG-1 Visual、ITU-T H.262またはISO/IEC MPEG-2 Visual、ITU-T H.263、ISO/IEC MPEG-4 Visual、ITU-T H.264(ISO/IEC MPEG-4 AVCとしても知られる)、およびITU-T H.265(HEVCとしても知られる)(そのような規格の拡張を含む)を含む。
加えて、ビデオコーディング規格、すなわちディスプレイストリーム圧縮(DSC)が、ビデオエレクトロニクス規格協会(VESA)によって開発されている。DSC規格は、ディスプレイリンクを介した送信用にビデオを圧縮することができるビデオ圧縮規格である。ディスプレイの解像度が増大するにつれて、ディスプレイを駆動するのに必要なビデオデータの帯域幅が相応して増大する。いくつかのディスプレイリンクは、そのような解像度にとって、ビデオデータのすべてをディスプレイに送信するための十分な帯域幅を有しないことがある。したがって、DSC規格は、ディスプレイリンクを介した相互動作可能な視覚的ロスレス圧縮のための圧縮規格を規定する。
DSC規格は、H.264およびHEVCなどの他のビデオコーディング規格とは異なる。DSCは、フレーム内圧縮を含むがフレーム間圧縮は含まず、そのことは、ビデオデータをコーディングする際に時間情報がDSC規格によって使用され得ないことを意味する。対照的に、他のビデオコーディング規格は、それらのビデオコーディング技法においてフレーム間圧縮を採用し得る。
概して、本開示は、たとえば、DSCなどのビデオ圧縮技法を改良する技法に関する。より詳細には、本開示は、デコーダが2つ以上のサブストリームを並列に復号できるようにすることによってスループット向上を促進するサブストリーム多重化のためのシステムおよび方法に関する。
いくつかの例がDSC規格のコンテキストにおいて本明細書で説明されるが、本明細書で開示するシステム、デバイス、および方法が、任意の適切なビデオコーディング規格に適用可能であり得ることが当業者には諒解されよう。たとえば、本明細書で開示する例示的な技法は、以下の規格、すなわち、国際電気通信連合(ITU)電気通信規格化部門(ITU-T)H.261、国際標準化機構/国際電気標準会議(ISO/IEC)Moving Picture Experts Group-1(MPEG 1)Visual、ITU-T H.262またはISO/IEC MPEG-2 Visual、ITU-T H.263、ISO/IEC MPEG 4 Visual、ITU-T H.264(ISO/IEC MPEG-4 AVCとしても知られる)、ITU-T H.265、高効率ビデオコーディング(HEVC)、およびそのような規格の任意の拡張のうちの、1つまたは複数に適用可能であり得る。本明細書で説明する技法は、詳細には、固定ビットレート(CBR)バッファモデルを組み込む規格に適用可能であり得る。また、本開示で説明する技法は、将来において開発される規格の一部になり得る。言い換えれば、本開示で説明する技法は、以前に開発されたビデオコーディング規格、現在開発中のビデオコーディング規格、および次のビデオコーディング規格に適用可能であり得る。
図1Aは、本開示で説明する態様による技法を利用し得る例示的なビデオコーディングシステム10を示すブロック図である。本明細書で使用し、説明する「ビデオコーダ」または「コーダ」という用語は、ビデオエンコーダとビデオデコーダの両方を総称的に指す。本開示では、「ビデオコーディング」または「コーディング」という用語は、ビデオ符号化およびビデオ復号を総称的に指す場合がある。ビデオエンコーダおよびビデオデコーダに加えて、本出願で説明する態様は、トランスコーダ(たとえば、ビットストリームを復号することができ、別のビットストリームを再符号化することができるデバイス)およびミドルボックス(たとえば、ビットストリームを修正、変換、かつ/または別の方法で操作することができるデバイス)などの、他の関連するデバイスに拡張され得る。
図1Aに示すように、ビデオコーディングシステム10は、宛先デバイス14によって後で復号されるべき符号化ビデオデータを生成するソースデバイス12を含む。図1Aの例では、ソースデバイス12および宛先デバイス14は、別個のデバイスを構成する。ただし、ソースデバイス12および宛先デバイス14が、図1Bの例に示すように同じデバイス上にあるか、またはその一部であってよいことに留意されたい。
ソースデバイス12および宛先デバイス14は、それぞれ、デスクトップコンピュータ、ノートブック(たとえば、ラップトップ)コンピュータ、タブレットコンピュータ、セットトップボックス、いわゆる「スマート」フォンなどの電話ハンドセット、いわゆる「スマート」パッド、テレビジョン、カメラ、ディスプレイデバイス、デジタルメディアプレーヤ、ビデオゲームコンソール、車載コンピュータ、ビデオストリーミングデバイス、アイウェアおよび/またはウェアラブルコンピュータなどのエンティティ(たとえば、人間、動物、および/または別の制御されたデバイス)によって(エンティティに)装着可能である(または、着脱可能に取付け可能な)デバイス、エンティティ内で消費され、取り込まれ、または配置され得るデバイスまたは装置などを含む、広範囲のデバイスのいずれかを備え得る。様々な実施形態では、ソースデバイス12および宛先デバイス14は、ワイヤレス通信用に装備されてよい。
宛先デバイス14は、リンク16を介して、復号されるべき符号化ビデオデータを受信し得る。リンク16は、ソースデバイス12から宛先デバイス14に符号化ビデオデータを移動することが可能な任意のタイプの媒体またはデバイスを備え得る。図1Aの例では、リンク16は、ソースデバイス12が符号化ビデオデータをリアルタイムで宛先デバイス14に送信することを可能にするための通信媒体を備え得る。符号化ビデオデータは、ワイヤレス通信プロトコルなどの通信規格に従って変調され、宛先デバイス14に送信され得る。通信媒体は、無線周波数(RF)スペクトルまたは1つもしくは複数の物理伝送線路などの、任意のワイヤレスまたは有線の通信媒体を備え得る。通信媒体は、ローカルエリアネットワーク、ワイドエリアネットワーク、またはインターネットなどのグローバルネットワークなどの、パケットベースネットワークの一部を形成し得る。通信媒体は、ルータ、スイッチ、基地局、またはソースデバイス12から宛先デバイス14への通信を容易にするために有用であり得る任意の他の機器を含み得る。
図1Aの例では、ソースデバイス12は、ビデオソース18(たとえば、カメラ)、ビデオエンコーダ20、および出力インターフェース22を含む。場合によっては、出力インターフェース22は、変調器/復調器(モデム)および/または送信機を含み得る。ソースデバイス12において、ビデオソース18は、ビデオキャプチャデバイス、たとえば、ビデオカメラ、以前キャプチャされたビデオを含むビデオアーカイブ、ビデオコンテンツプロバイダからビデオを受信するビデオフィードインターフェース、および/もしくはソースビデオとしてコンピュータグラフィックスデータを生成するためのコンピュータグラフィックスシステム、またはそのようなソースの組合せなどのソースを含む場合がある。一例として、ビデオソース18がビデオカメラである場合、ソースデバイス12および宛先デバイス14は、図1Bの例に示すように、いわゆる「カメラ電話」または「ビデオ電話」を形成し得る。しかしながら、本開示で説明する技法は、一般に、ビデオコーディングに適用可能であり得、ワイヤレスおよび/または有線の用途に適用され得る。
キャプチャされた、プリキャプチャされた、またはコンピュータ生成されたビデオは、以下でより詳細に説明する本開示の技法に従って、ビデオエンコーダ20によって符号化され得る。符号化ビデオデータは、ソースデバイス12の出力インターフェース22を介して、宛先デバイス14に送信され得る。符号化ビデオデータは、さらに(または、代替として)、復号および/または再生のために宛先デバイス14または他のデバイスによって後でアクセスできるように、記憶デバイス31上に記憶され得る。図1Aでは、記憶デバイス31は、ソースデバイス12とは別個のものとして示されている。他の例では、記憶デバイス31は、ソースデバイス12の一部であり得る。図1Aおよび図1Bに示すビデオエンコーダ20は、図2Aに示すビデオエンコーダ20または本明細書で説明する任意の他のビデオエンコーダを備え得る。
図1Aの例では、宛先デバイス14は、入力インターフェース28、ビデオデコーダ30、およびディスプレイデバイス32を含む。場合によっては、入力インターフェース28は、受信機および/またはモデムを含み得る。宛先デバイス14の入力インターフェース28は、リンク16を介して、かつ/または記憶デバイス31から、符号化ビデオデータを受信し得る。リンク16を介して通信された、または記憶デバイス31上に提供された符号化ビデオデータは、ビデオデータを復号する際にビデオデコーダ30などのビデオデコーダによって使用するための、ビデオエンコーダ20によって生成された様々なシンタックス要素を含み得る。そのようなシンタックス要素は、通信媒体上で送信されるか、記憶媒体上に記憶されるか、またはファイルサーバ上に記憶される符号化ビデオデータとともに含められてよい。図1Aおよび図1Bに示すビデオデコーダ30は、図2Bに示すビデオデコーダ30または本明細書で説明する任意の他のビデオデコーダを備え得る。
ディスプレイデバイス32は、宛先デバイス14と統合されてよく、または宛先デバイス14の外部にあってもよい。いくつかの例では、宛先デバイス14は、集積ディスプレイデバイスを含み得、また、外部ディスプレイデバイスとインターフェースするように構成され得る。他の例では、宛先デバイス14はディスプレイデバイスであり得る。一般に、ディスプレイデバイス32は、復号されたビデオデータをユーザに表示し、液晶ディスプレイ(LCD)、プラズマディスプレイ、有機発光ダイオード(OLED)ディスプレイ、または別のタイプのディスプレイデバイスなどの、様々なディスプレイデバイスのいずれかを備え得る。
関連する態様では、図1Bは、ソースデバイス12および宛先デバイス14がデバイス11上にあるかまたはその一部である、例示的なビデオコーディングシステム10'を示す。デバイス11は、「スマート」フォンなどのような電話ハンドセットであってよい。デバイス11は、ソースデバイス12および宛先デバイス14と動作可能に通信するプロセッサ/コントローラデバイス13(随意に存在する)を含み得る。図1Bのビデオコーディングシステム10'およびその構成要素は、その他の点では、図1Aのビデオコーディングシステム10およびその構成要素と同様である。
ビデオエンコーダ20およびビデオデコーダ30は、たとえば、DSCなどのビデオ圧縮規格に従って動作することができる。代替として、ビデオエンコーダ20およびビデオデコーダ30は、MPEG-4、Part 10、AVCと代替的に呼ばれるITU-T H.264規格、HEVC、またはそのような規格の拡張などの他のプロプライエタリ規格または業界規格に従って動作し得る。だが、本開示の技法は、特定のコーディング規格に限定されず、固定ビットレートバッファモデルを使用する任意のビデオ圧縮技法に適用されてよい。ビデオ圧縮規格の他の例には、MPEG-2およびITU-T H.263がある。
図1A〜図1Bの例には示されていないが、ビデオエンコーダ20およびビデオデコーダ30は各々、オーディオエンコーダおよびオーディオデコーダと統合され得、共通のデータストリームまたは別個のデータストリーム中のオーディオとビデオの両方の符号化を処理するために、適切なMUX-DEMUXユニット、または他のハードウェアおよびソフトウェアを含み得る。適用可能な場合、いくつかの例では、MUX-DEMUXユニットは、ITU H.223マルチプレクサプロトコル、またはユーザデータグラムプロトコル(UDP)などの他のプロトコルに準拠することができる。
ビデオエンコーダ20およびビデオデコーダ30は各々、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、個別論理、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組合せなどの、プログラマブルおよび/または固定関数処理回路を含む、様々な適切なエンコーダおよび/またはデコーダ回路のいずれかとして実装される場合がある。技法が部分的にソフトウェアで実装されるとき、デバイスは、適切な非一時的コンピュータ可読媒体の中にソフトウェア用の命令を記憶してよく、本開示の技法を実行するために1つまたは複数のプロセッサを使用してハードウェアにおいて命令を実行してよい。ビデオエンコーダ20およびビデオデコーダ30の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてよく、それらのいずれもが、複合エンコーダ/デコーダの一部としてそれぞれのデバイスの中に統合されてよい。
VESAによって最近確定された現世代の3:1 DSC v1.0ソリューションの例は、特に4Kなどの高解像度ディスプレイに対する、将来の市場要件(たとえば、モバイル市場要件)を促進するには概して不十分である。したがって、将来の需要に対処するために、VESAは、4:1以上の圧縮比をターゲットにする次世代DSCソリューションを開発するためにCfT(技術要請(call for technology))をリリースした。
本開示は、コンテンツコーデック(エンコーダデコーダ)およびテストモデル(アドバンストディスプレイストリーム圧縮(ADSC:advanced display stream compression)と称されることがある)について説明する。コンテンツコーダは、低コスト、固定レートの視覚的ロスレス圧縮を実現するDSCコーダと呼ばれることがある。図1Aおよび図1Bのビデオエンコーダ20およびビデオデコーダ30は、本開示のDSCコーダの例である。テストモデルは、コンテンツコーダがデータをコーディングするように構成される場合に準拠する圧縮プロトコル、アルゴリズム、規格などを指し得る。いくつかの例では、本明細書で説明する1つまたは複数の技法および/または利益は、ADSCテストモデルに関する。ビデオエンコーダ20およびビデオデコーダは、(ブロックサイズP×Qによる)ブロックベースの手法に基づいてビデオデータをコーディングするように構成され得、複数のコーディングモードを含み得る。たとえば、ブロックごとに利用可能なコーディングモードは、変換(たとえば、(離散コサイン変換(DCT)、アダマール)モード、ブロック予測(BP)モード、差分パルス符号変調(DPCM)モード、パターンモード、中間点予測(MPP:mid-point prediction)モード、BPスキップモード、および/または中間点予測フォールバック(MPPF:mid-point prediction fall back)モードを含み得る。異なるタイプのコンテンツまたは画像を効果的に圧縮するために、コーダの中でいくつかのコーディングモードが使用され得る。たとえば、テキスト画像はパターンモードによって効果的に圧縮され得、自然画像は変換モードによってより効果的にキャプチャされ得る。
いくつかの例では、ビデオエンコーダ20は、モードのレートとひずみの両方を検討することによってブロックごとにモードを選択することを目的とするレート制御機構に基づいて、複数のコーディングモードからブロックごとにコーディングモードを選択するように構成され得る。レート制御機構は、バッファモデルによってサポートされる。一例では、バッファが絶対にアンダーフロー(バッファの中のゼロ個よりも少ないビット)またはオーバーフロー(設定された最大サイズを超えてバッファサイズが増大している)の状態にないことがコーデック(たとえば、ビデオエンコーダ20およびビデオデコーダ30)の設計要件であり得る。
ブロックをコーディングするとき、所与のブロックにおける成分の値がすべてゼロである場合、その成分は、スキップモードを使用することによって効果的にコーディングされ得る。スキップモードコーディングでは、ビデオエンコーダ20は、現在ブロックがスキップモードを使用してコーディングされているか(たとえば、値がすべてゼロである場合)、それともスキップモードにないか(たとえば、ブロックにおける少なくとも1つの値が非ゼロである場合)を示すために、ビデオデコーダ30に1ビットフラグをシグナリングし得る。スキップモードでは、現在ブロックの色成分の値のすべてがゼロであるとき、ビデオエンコーダ20は、ビデオデコーダ30に1ビットフラグをシグナリングすることができ、ビデオエンコーダ20は、ブロックの色成分の値をコーディングするのを控え得る(すなわち、ブロックの色成分の値のコーディングがスキップされ得る)。ブロックよりも小さいサイズを有する色成分の値のグループに、または複数のブロックからなるグループに、スキップモードが適用されることもある。ブロックの色成分ごとに別個にスキップモードが適用されることもある。たとえば、現在ブロックの色成分の値のすべてがゼロであるときに、現在ブロックの色成分の値にスキップモードが適用され得る。いくつかの実装形態では、グループまたはブロックの色成分のすべてにスキップモードが適用され得る。
上記で全般的に説明したように、ビデオエンコーダ20は、ビデオデータを符号化するように構成される。ビデオデータは、1つまたは複数のピクチャを備え得る。ピクチャの各々は、ビデオの一部を形成する静止画像である。いくつかの事例では、ピクチャはビデオ「フレーム」と呼ばれ得る。ビデオエンコーダ20がビデオデータを符号化するとき、ビデオエンコーダ20はビットストリームを生成し得る。ビットストリームは、ビデオデータのコード化表現を形成するビットのシーケンスを含み得る。ビットストリームは、1つまたは複数のシンタックス要素を含む、コード化ピクチャおよび関連データを含み得る。コード化ピクチャは、ピクチャのコード化表現である。
ビットストリームを生成するために、ビデオエンコーダ20は、ビデオデータ中の各ピクチャに対して符号化動作を実行し得る。ビデオエンコーダ20がピクチャに対して符号化動作を実行するとき、ビデオエンコーダ20は、一連のコード化ピクチャおよび関連データを生成し得る。関連データは、量子化パラメータ(QP)などのコーディングパラメータのセットを含み得る。コード化ピクチャを生成するために、ビデオエンコーダ20は、ピクチャを、等しいサイズのビデオブロックに区分し得る。ビデオブロックは、サンプルの2次元アレイであり得る。サンプルは、ピクセルの色を示すデータであり得る。いくつかの例では、ピクセルの色は、1つのルーマ成分(たとえば、Y)および1つまたは複数のクロマ成分(たとえば、赤および青クロマ(CrおよびCb)、または橙および緑クロマ(CoおよびCg))によって表され得る。コーディングパラメータは、ビデオデータのブロックに対してコーディングモードを規定し得る。コーディングモードは、個別にビデオデータの各ブロックに対して、またはブロックのグループに対して指定され得る。コーディングモードは、所望のレートひずみ性能を達成するように決定され得る。
いくつかの例では、ビデオエンコーダ20は、ピクチャを複数のスライスに区分し得る。スライスの各々は、画像(たとえば、フレーム)の中に、画像またはフレームの中の領域の残りからの情報なしに独立して復号され得る空間的に別個の領域を含み得る。各画像またはビデオフレームは単一のスライス中で符号化されてよく、あるいは各画像またはビデオフレームはいくつかのスライス中で符号化されてもよい。DSCでは、各スライスを符号化するために割り振られるターゲットビットは、実質的に固定であり得る。ピクチャに対して符号化動作を実行することの一部として、ビデオエンコーダ20は、ピクチャの各スライスに対して符号化動作を実行し得る。ビデオエンコーダ20がスライスに対して符号化動作を実行するとき、ビデオエンコーダ20は、スライスに関連付けられた符号化データを生成することができる。スライスに関連付けられた符号化データは、「コード化スライス」と呼ばれ得る。
図2Aは、本開示で説明する態様による技法を実装し得るビデオエンコーダ20の一例を示すブロック図である。ビデオエンコーダ20は、本開示の技法のうちの一部または全部を実行するように構成され得る。いくつかの例では、本開示で説明する技法は、ビデオエンコーダ20の様々な構成要素の間で共有され得る。いくつかの例では、追加または代替として、プロセッサ(図示せず)が、本開示で説明する技法のうちの一部または全部を実行するように構成され得る。説明のために、本開示は、DSCコーディングのコンテキストにおいてビデオエンコーダ20について説明する。しかしながら、本開示の技法は、CBRバッファモデルを使用する他のビデオコーディング技法を含む、他のコーディング規格または方法に適用可能であり得る。
図2Aの例では、ビデオエンコーダ20は複数の構成要素を含む。ビデオエンコーダ20の構成要素は、色空間変換器105、バッファ110、平坦度検出器115、レートコントローラ120、予測器、量子化器、および再構成器構成要素125、ラインバッファ130、インデックス付き色履歴135、エントロピーエンコーダ140、サブストリームマルチプレクサ145、ならびにレートバッファ150を含む。他の例では、ビデオエンコーダ20は、より多数の、より少数の、または異なる構成要素を含んでよい。
色空間変換器105は、ビデオデータを受信し、ビデオデータの入力色空間を、コーディング実施において使用される色空間に変換するように構成され得る。たとえば、例示的な一実施形態では、入力ビデオデータの色空間は、赤、緑、および青(RGB)色空間にあり得る一方、ビデオエンコーダ20によって実行されるコーディングプロセスは、ルミナンスY、クロミナンス緑Cg、およびクロミナンス橙Co(YCoCg)色空間において実施される。色空間変換は、ビデオデータへのシフトおよび加算を含む、任意の技法を使用して実行され得る。他の色空間における入力ビデオデータが処理されてよく、他の色空間への変換も実行され得ることに留意されたい。
バッファ110、ラインバッファ130、および/またはレートバッファ150は、ランダムアクセスメモリ(RAM)、同期型ダイナミックランダムアクセスメモリ(SDRAM)、読取り専用メモリ(ROM)、不揮発性ランダムアクセスメモリ(NVRAM)、電気消去可能プログラマブル読取り専用メモリ(EEPROM)、FLASHメモリ、キャッシュメモリ、磁気または光データ記憶媒体などの、メモリまたはデータ記憶媒体を備え得る。
バッファ110は、色空間変換されたビデオデータを、ビデオエンコーダ20の他の構成要素による色空間変換されたビデオデータの使用の前に記憶するように構成され得る。別の例では、色空間変換されたデータはより多くのビットを必要とし得るので、ビデオデータがRGB色空間において記憶されてよく、色空間変換は必要に応じて実行されてよい。
レートバッファ150は、レートコントローラ120に関して以下でより詳細に説明する、ビデオエンコーダ20の中のレート制御機構の一部として使用され得る。各ブロックを符号化するのに費やされるビットは、特定のブロックの性質に基づいてかなり大幅に変わることがある。レートバッファ150は、圧縮ビデオにおけるレート変動を平滑化することができる。いくつかの例では、ビットが固定ビットレートでバッファから取り出されるCBRバッファモデルが採用される。CBRバッファモデルでは、ビデオエンコーダ20がビットストリームにあまりにも多くのビットを追加した場合、レートバッファ150はオーバーフローし得る。一方、ビデオエンコーダ20は、レートバッファ150のアンダーフローを防止するために、十分なビットを追加するように構成され得る。いくつかの例では、レートバッファフルネスがその最大サイズに近づいたとき、ビデオエンコーダは、オーバーフローを防止するためにQPを増大させるように構成され得る。レートバッファフルネスが空に近づいたとき、アンダーフローを防止するためにレートバッファにゼロのビットが詰め込まれる。レートバッファ150は、圧縮ビデオデータをビデオデコーダ(たとえば、ビデオデコーダ30)に出力するように構成され得る。
ビデオデコーダ側において、ビデオデコーダ30のレートバッファ155(以下でさらに詳細に説明する図2Bを参照)に固定ビットレートでビットが追加されてよく、ビデオデコーダ30は、ブロックごとに可変数のビットを除去してよい。適正な復号を確実にするために、ビデオデコーダ30のレートバッファ155は好ましくは、圧縮ビットストリームの復号中に「アンダーフロー」も「オーバーフロー」もしないように構成される。
いくつかの例では、バッファフルネス(BF)は、シンタックス要素BufferCurrentSizeの値に基づいて定義され得る。BufferCurrentSizeの値は、バッファ(たとえば、レートバッファ150)に現在あるビットの数を表す。可変値BufferMaxSizeは、レートバッファ150のサイズ、すなわち、任意の時点にレートバッファ150に記憶され得るビットの最大数を表す。BFは、次のように計算され得る。
BF=((BufferCurrentSize*100)/BufferMaxSize)
BFを計算するための上記の手法は例にすぎず、BFが、特定の実装形態またはコンテキストに応じて任意の数の異なる方法で計算され得ることに留意されたい。
平坦度検出器115は、ビデオデータの中の複雑(たとえば、不均一)エリアからビデオデータの中の平坦(たとえば、単純もしくは均一)エリアへの変化および/またはその逆の変化を検出するように構成され得る。「複雑」および「平坦」という用語は、概して、ビデオエンコーダ20がビデオデータのそれぞれの領域を符号化することの難しさを指すために本明細書で使用される。したがって、本明細書で使用する複雑という用語は、概して、ビデオエンコーダ20が符号化するのがより複雑である(たとえば、より多くのビットおよび/またはより多くの処理時間を必要とする)ものとしてビデオデータの領域を記述し、たとえば、テクスチャードビデオデータ、高い空間周波数を有するビデオデータ、および/または符号化するのが複雑である他の特徴を含み得る。本明細書で使用する平坦という用語は、概して、ビデオエンコーダ20が符号化するのがさほど複雑ではない(たとえば、より少ないビットおよび/またはより少ない処理時間を必要とする)ものとしてビデオデータの領域を記述し、たとえば、ビデオデータにおける平滑勾配、低い空間周波数を有するビデオデータ、および/または符号化するのが簡単である他の特徴を含み得る。複雑領域から平坦領域への遷移は、符号化ビデオデータにおける量子化アーティファクトを低減するためにビデオエンコーダ20によって使用され得る。詳細には、複雑領域から平坦領域への遷移が識別されると、レートコントローラ120ならびに予測器、量子化器、および再構成器構成要素125が、そのような量子化アーティファクトを低減することができる。同様に、平坦領域から複雑領域への遷移は、現在ブロックをコーディングするために必要な予想レートを下げるために、QPを増大させるためにビデオエンコーダ20によって使用され得る。
レートコントローラ120は、QPを含む、コーディングパラメータのセットを決定する。量子化は、信号において損失をもたらし、損失の量は、QPの値よって制御され得る。QPごとの量子化ステップサイズを記憶する代わりに、QPの関数としてスケーリングマトリックスが指定され得る。いくつかの例では、QPごとの量子化ステップサイズは、スケーリングマトリックスから導出され得る。量子化ステップのための導出される値は、必ずしも2のべき乗であるとは限らず、たとえば、導出される量子化ステップサイズは、2とは異なる数字のべき乗であってもよい。QPは、レートバッファ150がオーバーフローもアンダーフローもしないことを確実にするターゲットビットレートに対するピクチャ品質を最大限にするために、レートバッファ150のバッファフルネスおよびビデオデータの画像活動度(たとえば、複雑領域から平坦領域への遷移またはその逆の遷移)に基づいて、レートコントローラ120によって調節され得る。レートコントローラ120はまた、所望のレートひずみ性能を達成するために、ビデオデータのブロックごとに特定のコーディングオプション(たとえば、特定のコーディングモード)を決定するように構成され得る。レートコントローラ120は、ビットレート制約を満たすように、すなわち、実際のコーディングレート全体がターゲットビットレート内に収まるように、再構成画像のひずみを最小限に抑える。したがって、レートコントローラ120の1つの目的は、レートひずみ性能を最大にしながら、レートに対する瞬間的および平均的な制約を満たすために、QP、コーディングモードなどのコーディングパラメータのセットを決定することである。
予測器、量子化器、および再構成器構成要素125は、ビデオエンコーダ20の少なくとも3つの符号化動作を実行し得る。予測器、量子化器、および再構成器構成要素125は、いくつかの異なるコーディングモードで予測コーディングプロセス(たとえば、予測モード)を実行し得る。1つの例示的な予測モードは、メディアン適応予測の修正バージョンである。メディアン適応予測は、ロスレスJPEG規格(JPEG-LS)によって実施され得る。予測器、量子化器、および再構成器構成要素125によって実行され得るメディアン適応予測の修正バージョンは、3つの連続するサンプル値の並列予測を可能にし得る。別の例示的な予測モードは、ブロック予測である。ブロック予測では、サンプルは、上のラインの中の、または同じラインの中で左の、以前再構成されたピクセルから予測される。いくつかの例では、ビデオエンコーダ20およびビデオデコーダ30は両方とも、ブロック予測の使用を決定するために再構成ピクセルに対して同一の探索を実行し得、したがって、ビットがブロック予測モードで送られる必要はない。他の例では、ビデオデコーダ30が別個の探索を実行する必要がないように、ビデオエンコーダ20が探索を実行し得るとともにブロック予測ベクトルをビットストリームの中でシグナリングし得る。予測器、量子化器、および再構成器構成要素125はまた、成分範囲の中間点を使用してサンプルが予測される中間点予測モードを実行するように構成され得る。中間点予測モードは、ワーストケースサンプルにおいてさえ、圧縮ビデオにとって必要なビット数のバウンディングを可能にし得る。
いくつかの例示的な予測モードでは、予測器、量子化器、および再構成器構成要素125は、予測残差を生成し得る。予測残差は、ビデオデータの予測ブロックのサンプル値とコーディングされているビデオデータのブロックのサンプル値との間の差であり得る。以下で説明するように、予測残差は量子化されてよく、たとえば、エントロピー符号化技法を使用して、さらに圧縮されてよい。
予測器、量子化器、および再構成器構成要素125は、量子化を実行するようにさらに構成され得る。たとえば、予測器、量子化器、および再構成器構成要素125は、シフタを使用して実施され得る2のべき乗量子化器を介して量子化を実行し得る。2のべき乗量子化器の代わりに他の量子化技法が実施されてよいことに留意されたい。予測器、量子化器、および再構成器構成要素125によって実行される量子化は、レートコントローラ120によって決定されたQPに基づき得る。予測器、量子化器、および再構成器構成要素125はまた、逆量子化残差を予測値に加算すること、および結果がサンプル値の有効範囲の外にならないことを確実にすることを含む、再構成を実行する。
予測器、量子化器、および再構成器構成要素125によって実行される予測、量子化、および再構成のための上記の例示的な手法が例示にすぎないこと、ならびに他の手法が実施されてよいことに留意されたい。予測器、量子化器、および再構成器構成要素125が、予測、量子化、および/または再構成を実行するための下位構成要素を含み得ることにも留意されたい。予測、量子化、および/または再構成は、予測器、量子化器、および再構成器構成要素125の代わりに、いくつかの別個のエンコーダ構成要素によって実行されてよいことにさらに留意されたい。
予測器、量子化器、および再構成器構成要素125ならびにインデックス付き色履歴135が、バッファリングされたビデオデータを使用および/または記憶できるように、ラインバッファ130は、予測器、量子化器、および再構成器構成要素125からの出力を記憶するように構成される。インデックス付き色履歴135は、最近使用されたピクセル値を記憶するように構成されたメモリである。これらの最近使用されたピクセル値は、専用シンタックスを介して、ビデオエンコーダ20によって直接参照され得る。
エントロピーエンコーダ140は、予測器、量子化器、および再構成器構成要素125から受信された予測残差ならびに任意の他のデータ(たとえば、予測器、量子化器、および再構成器構成要素125によって識別されたシンタックス要素およびインデックス)を、インデックス付き色履歴135、および平坦度検出器115によって識別された平坦度遷移に基づいて符号化する。いくつかの例では、エントロピーエンコーダ140は、サブストリームエンコーダごとにクロックあたり3サンプルを符号化し得る。サブストリームマルチプレクサ145は、ヘッダレスパケット多重化方式に基づいてビットストリームを多重化し得る。このことにより、ビデオデコーダ30は、3つのエントロピーデコーダを並行して動作させることができ、クロックあたり3ピクセルの復号を容易にする。サブストリームマルチプレクサ145は、ビデオデコーダ30によってパケットが効率的に復号され得るようにパケット順序を最適化し得る。クロックあたり2のべき乗個のピクセル(たとえば、2ピクセル/クロックまたは4ピクセル/クロック)の復号を容易にし得る、エントロピーコーディングの異なる手法が実施され得ることに留意されたい。
図2Bは、本開示で説明する態様による技法を実装し得る例示的なビデオデコーダ30を示すブロック図である。ビデオデコーダ30は、本開示の技法のうちの一部または全部を実行するように構成され得る。いくつかの例では、本開示で説明する技法は、デコーダ30の様々な構成要素の間で共有され得る。いくつかの例では、追加または代替として、プロセッサ(図示せず)が、本開示で説明する技法のうちの一部または全部を実行するように構成され得る。
説明のために、本開示は、DSCコーディングのコンテキストにおいてビデオデコーダ30について説明する。ただし、本開示の技法は、他のコーディング規格または方法に適用可能であり得る。
図2Bの例では、ビデオデコーダ30は、複数の機能構成要素を含む。ビデオデコーダ30の機能構成要素は、レートバッファ155、サブストリームデマルチプレクサ160、エントロピーデコーダ165、レートコントローラ170、予測器、量子化器、および再構成器構成要素175、インデックス付き色履歴180、ラインバッファ185、ならびに色空間変換器190を含む。ビデオデコーダ30の図示の構成要素は、図2Aのビデオエンコーダ20に関して上記で説明した対応する構成要素に類似している。したがって、ビデオデコーダ30の構成要素の各々は、上記で説明したようなビデオエンコーダ20の対応する構成要素と同様だが逆の方式で動作し得る。
ラインバッファ185および/またはレートバッファ155は、RAM、SDRAM、ROM、NVRAM、EEPROM、FLASHメモリ、キャッシュメモリ、磁気または光データ記憶媒体などの、メモリまたはデータ記憶媒体を備え得る。レートバッファ155は、(たとえば、ビデオエンコーダ20から)圧縮ビデオを受信するように構成されてよく、ビデオデコーダ30においてレート制御機構の一部として使用される。各ブロックを復号するのに費やされるビットは、特定のブロックの性質に基づいてかなり大幅に変わることがある。レートバッファ155は、圧縮ビデオにおけるレート変動を平滑化することができる。いくつかの例では、ビットが固定ビットレートでレートバッファ155から取り出されるCBRバッファモデルが採用される。
以下でより詳細に説明するように、サブストリームデマルチプレクサ160は、ヘッダレスパケット多重化方式に基づいてビットストリームを逆多重化し得る。このことにより、ビデオデコーダ30は、(たとえば、エントロピーデコーダ165の一部として)3つのエントロピーデコーダを並行して動作させることができ、クロックあたり3ピクセルの復号を容易にする。エントロピーデコーダ165は、図2Aのエントロピーエンコーダ140の方式とは逆の方式で、サブストリームデマルチプレクサ160から受信された圧縮予測残差ならびに任意の他のデータ(たとえば、シンタックス要素およびインデックス)を復号する。
レートコントローラ170は、QPを含む、コーディングパラメータのセットを決定する。量子化は、信号において損失をもたらし、損失の量は、QPによって制御され得る。ある例では、レートコントローラ170は、圧縮ビデオビットストリームにおいてビデオエンコーダ20からQPを受信し得る。レートコントローラ170は、決定されたQPを予測器、量子化器、および再構成器構成要素175に供給し得る。
予測器、量子化器、および再構成器構成要素175は、ビデオデコーダ30の少なくとも3つの復号動作を実行し得る。予測器、量子化器、および再構成器構成要素175は、逆量子化を実行するようにさらに構成され得る。たとえば、予測器、量子化器、および再構成器構成要素175は、レートコントローラ170によって決定されたQPに従って逆量子化を実行し得る。
予測器、量子化器、および再構成器構成要素175はまた、いくつかの異なるコーディングモードで予測復号プロセス(たとえば、予測モード)を実行し得る。例示的なコーディングモードについて、図2Aの予測器、量子化器、および再構成器構成要素125を参照しながら上記で説明したが、他のコーディングモードが使用されてもよい。予測器、量子化器、および再構成器構成要素175は、圧縮ビデオビットストリームにおいて、ビデオデータの特定のブロックまたはビデオデータのブロックに使用されたコーディングモードを示すシンタックス要素を受信し得る。コーディングモードに基づいて、予測器、量子化器、および再構成器構成要素175は、現在復号されているブロックの予測ブロックを決定し得る。予測器、量子化器、および再構成器構成要素125はその場合に、復号されたブロックを生成するために逆量子化残差値を決定された予測ブロックに加算することを含む再構成も実行し得る。
予測器、量子化器、および再構成器構成要素175によって実行される予測、量子化、および再構成のための上記の例示的な手法が例示にすぎないこと、ならびに他の手法が実施されてよいことに留意されたい。予測器、量子化器、および再構成器構成要素175が、予測、逆量子化、および/または再構成を実行するための下位構成要素を含み得ることにも留意されたい。予測、逆量子化、および/または再構成は、予測器、量子化器、および再構成器構成要素175の代わりに、いくつかの別個のエンコーダ構成要素によって実行されてよいことにさらに留意されたい。
予測器、量子化器、および再構成器構成要素175ならびにインデックス付き色履歴180が、バッファリングされたビデオデータを使用および/または記憶できるように、ラインバッファ185は、予測器、量子化器、および再構成器構成要素175からの出力を記憶するように構成される。インデックス付き色履歴180は、最近使用されたピクセル値を記憶するように構成されたメモリである。これらの最近使用されたピクセル値は、専用シンタックスを介して、ビデオデコーダ30によって直接参照され得る。
色空間変換器190は、コーディング実施において使用された色空間を出力色空間に変換するように構成され得る。たとえば、例示的な一実施形態では、出力ビデオデータの色空間は、赤、緑、および青(RGB)色空間にあり得る一方、ビデオデコーダ30によって実行されるコーディングプロセスは、ルミナンスY、クロミナンス緑Cg、およびクロミナンス橙Co(YCoCg)色空間において実施される。色空間変換は、ビデオデータへのシフトおよび加算を含む、任意の技法を使用して実行され得る。他の色空間における出力ビデオデータが処理されてよく、他の色空間への変換も実行され得ることに留意されたい。
以下のセクションでは、DSCのための追加の技法についてより詳細に説明する。DSCに関する一例では、現在ブロック用のQP(currQPとして示す)は、以下の式に基づいて導出または計算され得る。
currQP=prevQP+QpAdj*(diffBits>0? 1: -1)
上式で、prevQPは、ビデオデータの前のブロックに関連するQPであり、diffBitsは、previousBlockBitsとtargetBitsとの間の差分を表し、QpAdjは、diffBitsの大きさに基づいて計算されるQPオフセット値(たとえば、QP調整値)であり、previousBlockBitsは、前のブロックをコーディングするために使用されるビット数を表し、targetBitsは、現在ブロックをコーディングする際のターゲットビット数を表す。previousBlockBitsがtargetBitsよりも大きいとき、diffBitsは正数であり、現在ブロックのQPは、オフセット値QpAdjをprevQP値に加算することによって導出され得る。言い換えれば、diffBitsが正数であるとき、QP値は、prevQP値から値が下がらない。previousBlockBitsがtargetBits以下であるとき、diffBitsは負数またはゼロであり、currQPはprevQP値から増えない。オフセット値QpAdjは、たとえば、diffBitsの大きさが増えるにつれてQpAdjが単調に増加するようにdiffBitsの関数として計算され得ることに留意されたい。
QP調整値QpAdjを計算するための、本明細書ではデフォルト技法と呼ぶ1つの技法について、図3を参照しながら次に説明する。図3は、ゼロで始まるdiffBitsの値が描かれる軸を含むグラフ300を示す。デフォルト技法では、diffBits>0のとき、diffBitsは、K個の閾値を使用してK+1個の範囲に分類され得る。これらの閾値は、閾値1、閾値2、閾値3、...、および閾値Kというラベルによって示され、範囲は、範囲1、範囲2、範囲3、...、および範囲K+1というラベルによって示される。図3のデフォルト技法では、diffBitsを、K個の閾値を使用してK+1個の範囲に分ける1つの手法が示されている。各範囲は、特定のQpAdj値に関連付けられてもよく、QpAdj値は、範囲インデックスが増えるにつれて増える。diffBits≦0のとき、diffBitsの絶対値は、J個の閾値を使用してJ+1個の範囲に分類されてもよく(図示せず)、J+1個の範囲の各々に割り当てられた特定のQpAdj値があってもよい。
他の態様では、currQP値は、バッファのアンダーフローおよび/またはオーバーフローを防ぐために、バッファのフルネス(バッファフルネス(BF)として表され得る)に基づいて調整されてもよい。詳細には、BFがある閾値(たとえば、P1)を超えるとき、currQPは固定オフセット値(たとえば、p1)だけインクリメントされ得る。たとえば、currQPは、次のように調整され得る:currQP+=p1。さらに、BFがある閾値(たとえば、Q1)を下回るとき、currQPはq1だけデクリメントされ、たとえば、currQP-=q1であり得る。いくつかの態様では、複数の閾値が用いられてもよく、各閾値に対して、currQPを調整するための対応するオフセット値があってもよい。
複雑領域から平坦領域への遷移が識別されるとき、または平坦領域が識別されるとき、currQPは、以下でさらに詳細に説明するように、低い値(たとえば、定義されたcurrQP値を下回る値)に設定されてもよい。
各ブロックを符号化するのに費やされるビットは、ブロックの性質に基づいてかなり大幅に変わることがある。したがって、出力ビットストリームにおけるレート変動を平滑化するために、バッファがレート制御機構の一部であり得る。
再び図2Aおよび図2Bを参照すると、エントロピーエンコーダ140およびエントロピーデコーダ165は、様々なタイプのエントロピーコーディング技法を適用し得る。一例では、デルタサイズユニット可変長コーディング(DSU-VLC:delta size unit-variable length coding)が使用され得る。DSU-VLCでは、(「グループ」として定義された)K長(K-length)サンプルベクトルの量子化残差値が、プレフィックス部分およびサフィックス部分を使用してコーディングされ得る。ここでのサンプルは、単一の色成分における値を指す。たとえば、RGB444の場合、各ピクセルは3つのサンプルを有する。プレフィックス部分は、サフィックス部分に後続する残差値のサイズ(サイズはBビットとして示される)を示すことができ、サフィックス部分は、ユニットにおけるすべてのサンプルの実際の残差値を示すことができる。グループにおけるK個の残差値が、たとえば、同じビット数を使用して2の補数でコーディングされ得る。
図4Aを参照すると、K=4個のサンプルによるベクトルのための例示的なDSU-VLC構造が示されている。一例として、4個のサンプルからなるグループ[1,-2,-1,0]をコーディングするためのサイズは、2の補数表現を使用してB=2ビットであり得る。DSU-VLCコードの一例が図4Bに示されており、001が、プレフィックスの単項コードを表し、[01,10,11,00]が、2ビットを使用して実際のコード化サンプル値をそれぞれ表す。単一のクロックにおいて通常行われるプレフィックスを復号することによって、4つのシンボルのすべてが復号され得る。
別の例では、たとえば、4サンプル/クロックのスループットを実現するために、(たとえば、ビデオエンコーダ20のエントロピーエンコーダ140および/またはビデオデコーダ30のエントロピーデコーダ165を介して)高スループットエントロピーコーディング技法が実施され得る。高スループットエントロピーコーディング技法は、(たとえば、ブロックサイズP×Qを有する)所与のブロック内のサンプルの量子化残差をN個のグループに区分し、次いでDSU-VLCを使用してグループサンプルをコーディングすることを伴い得る。N個のグループへのサンプルのブロックの区分は、均一または不均一であり得る。
均一グルーピングの場合、N個のグループはそれぞれ、等しい数のサンプルを有し、サンプルは、BPモード、DPCMモードなどで使用され得る。図5は、均一グルーピングの例示的な手法を示しており、量子化残差ブロック値の2×8ブロックが4つのグループに区分され、各グループが4つのサンプルを有する。不均一グルーピング(図示せず)の場合、各グループにおけるサンプルの数は異なってよく、サンプルは変換モードで使用され得る。
サブストリーム多重化(SSM)のための技法がDSCに関して提案されている。一般に、SSMは、共通の特性に基づくサブストリームへの符号化ビデオデータのビットストリームの切断(たとえば、各色成分が1つのサブストリームであり得る)を伴う。一例では、たとえば、固定長ワード(たとえば、muxワード)を使用して、複数のサブストリームを単一のストリームに多重化するために、ヘッダレスSSM技法が実施され得る。すなわち、ビデオエンコーダ20は、(たとえば、シンタックスmuxWordSizeによって示されるように)固定サイズのパケット(たとえば、muxワード)を送信するように構成され得る。デコーダが複数のサブストリームを並列に復号できるように、muxワードが導出され、単一のストリームに配置され得る。
本例では、ビデオデータの各色成分は、サブストリーム、たとえば、ルミナンス(Y)、クロミナンス橙(Co)、およびクロミナンス緑(Cg)と見なされてよく、その結果、合計3つのサブストリームが存在する。関係する態様では、muxワードサイズ(muxWordSize)は、成分ごとに使用されるビットの数(bpc)に依存してよく、たとえば、8bpcおよび10bpcの場合は48ビット、12bpcの場合は64ビットなどである。さらなる関係する態様では、muxワードサイズは、最大シンタックス要素サイズ(maxSeSize)以上に設定されることがあり、maxSeSizeは、1つのグループのための単一成分相当の圧縮データの最大可能サイズを指す。これは、ビデオデコーダ30が単一のグループを復号するために各サブストリームからの多くて1muxワードを要求するように構成され得ることを意味する。
図6Aは、エンコーダ(たとえば、ビデオエンコーダ20のサブストリームマルチプレクサ145)においてSSMの1つまたは複数の例示的な態様を実行するための構成要素を示す。図6Aおよび図6Bにおいて、線付きブロックがSSM機能を実行する構造を示し、白のブロックがFIFOバッファを示す。エンコーダ側では、SSMは、符号化データの複数のグループ(たとえば、各グループは3つのピクセルを含む)を記憶するサブストリームごとの平衡先入れ先出し(FIFO)手法を使用することを伴い得る。並列復号を容易にするためにmuxワードが導出されるとき、デマルチプレクサモデル206がビデオエンコーダ20において実施され得る。図6Bは、デコーダ(たとえば、ビデオデコーダ30のサブストリームデマルチプレクサ160)においてSSMの1つまたは複数の例示的な態様を実行するための構成要素を示す。デコーダ側では、デマルチプレクサモデルは、3つ以上のファネルシフタ(たとえば、サブストリームごとのファネルシフタ)および色成分を並列に復号するエントロピーデコーダ165A、165B、165C(サブストリームごとに1つ)を含み得る。エントロピーデコーダ165A、165B、165Cは、図2Bのエントロピーデコーダ165の一部であり得る。ファネルシフタとエントロピーデコーダとの組合せは、サブストリームプロセッサ(SSP)と呼ばれることがある。各グループ時間(またはブロック時間)に、各SSPは、1muxワードを要求すること、またはmuxワードをまったく要求しないことがある。DSCv1.xにおいて、サンプルのグループに対して動作が実行される。したがって、3つのサンプルからなるグループが符号化される時間は、グループ時間と呼ばれることがある。本開示の例では、サンプルのより大きいブロック(たとえば、サンプルの8×2ブロック)に対して符号化および復号が実行され得る。サンプルのブロックが符号化される時間は、ブロック時間と呼ばれることがある。ファネルシフタにおけるビットの数が厳密に言ってmaxSeSizeよりも小さいとき、muxワードがSSPによって要求され得る。図6Aおよび図6Bにおいて、影付きブロックは機能ブロックであり、影なしブロックはFIFOバッファである。
図6Aに戻ると、ビデオエンコーダ20は、処理されるビデオデータの色成分(たとえば、Y、Co、およびCg)ごとに、それぞれ、VLCおよびファネルシフタ200A、200B、および200C(まとめて「VLCおよびファネルシフタ200」)を含み得る。いくつかの例では、VLCおよびファネルシフタ200のVLC機能は、図2Aのエントロピーエンコーダ140によって実行され得る。VLCおよびファネルシフタ200は、ビデオデータのブロックの各色成分にVLC符号化(たとえば、DSU-VLC)を適用するように構成され得る。VLCおよびファネルシフタ200は、エンコーダ平衡FIFO202A、202B、および202C(まとめて、エンコーダ平衡FIFO202)にコード化ビデオデータを移動するためのファネルシフタを含み得る。一般に、シフタは、指定された数のビットでデータワードをシフトすることができるデジタル回路である。ファネルシフタは、出力ビットよりも多くの数の入力ビットを有するシフタである。すなわち、ファネルシフタに入力されるすべてのビットが各クロックサイクルにおいて出力されるわけではない。エンコーダ平衡FIFO202はmuxワードを、ビデオデコーダ30への後の送信のために記憶する。
muxワード要求がビデオデコーダ30のSSPから受信されたとき、マルチプレクサ204は、エンコーダ平衡FIFO202のうちの1つからの単一のmuxワードをレートバッファ150に配置し得る。たとえば、ビデオデコーダ30のSSPからY成分muxワードについての要求が行われた場合、マルチプレクサ204は、muxワードをYエンコーダ平衡FIFO202Aから移動し、ビットストリームにおいて送るためにレートバッファ150にmuxワードを配置し得る。所与のグループ時間において、複数の要求が、ビデオデコーダ30のSSPから受信され得る(サブストリームごとに多くて1つ)。そのようなシナリオでは、要求されたmuxワードは、特定の順序で(たとえば、Yが最高優先度を与えられ、その次にCoが来て、その次にCgが来る)レートバッファ150に配置され得る。マルチプレクサ204は、デマルチプレクサモデル206に基づいて、特定の順序でレートバッファ150にmuxワードを配置するように構成され得る。デマルチプレクサモデル206は、SSMプロセスがビデオデコーダ30によって実行される方法のモデルである。このようにして、ビデオエンコーダ20は、どの順序でビデオデコーダ30がmuxワードを要求するか(たとえば、特定のサブストリームからのmuxワードの順序)を判断することができ、マルチプレクサ204はその場合、デマルチプレクサモデル206によって与えられた、判断された順序に基づいて、muxワードをレートバッファ150に配置することができる。
エンコーダ平衡FIFO202A、202B、202Cの平衡FIFOサイズは、レートバッファ150におけるビットのオーバーフローまたはアンダーフローを防止するように導出または設定され得る。一般に、平衡FIFOサイズは、maxSeSizeと最小シンタックス要素サイズ(minSeSize)との間の差、ならびにmuxWordSizeに依存し得る。
一例では、スライスの最初に、エンコーダ平衡FIFO202は、データの(muxWordSize+maxSeSize-1)個のグループで満たされ得る。これは、ビデオデコーダ30にmuxワードがまったく送信されない初期遅延期間(たとえば、SSM遅延時間と呼ばれる)に対応し得る。オーバーフローを防止するために、エンコーダ平衡FIFO202の各々は、(muxWordSize+maxSeSize-1)*maxSeSizeビットを記憶するように構成され得る。アンダーフローを防止するために、(たとえば、デマルチプレクサモデル206によって示されるように)ビデオデコーダ30からの要求が行われたときはいつでもエンコーダ平衡FIFO202の各々が1muxワード相当のデータを含むようにFIFOサイズが計算され得る。
符号化の最初に、muxWordSize+maxSeSize-1個のグループに関して、エンコーダ平衡FIFO202は、muxワードを一切除去することなく、コード化ビットで満たされ得る。この初期遅延の後、マルチプレクサ204は、平衡FIFO202の各々から1muxワードを除去し、muxワードをレートバッファ150に送り得る。加えて、マルチプレクサ204は、これらのmuxワードを、デマルチプレクサモデル206のそれぞれのファネルシフタに配置し得る。グループ時間ごとに、デマルチプレクサモデル206において、ファネルシフタにおけるビットの数が、シンタックス要素のサイズだけ減らされ得る。
一般に、シンタックス要素サイズは、単一のグループにおける単一サブストリーム相当のデータを復号するために必要とされるビットの数を指し得る。一例では、シンタックス要素は、各成分が別個のストリームに属する場合に、単一のグループにおける単一成分相当のデータを指し得る。ビデオエンコーダ20におけるデマルチプレクサモデル206の1つの目的は、ビデオエンコーダ20がビデオデコーダ30にとって正しい順序でビットストリームにmuxワードを配置するように、ビデオデコーダ30における実際の復号を模倣することである。ファネルシフタフルネスは、そのときに1つのグループを復号するために必要とされるビットの数に応じて減らされ得る。ファネルシフタフルネスが最大シンタックス要素サイズ(maxSeSize)を下回る場合、ビデオデコーダ30(およびデマルチプレクサモデル206)は、ファネルシフタにmuxワードを追加することを求める要求を行い得る。同じmuxワードがレートバッファ150にも送られ得る。(各ファネルシフタフルネスを、対応するシンタックス要素サイズだけデクリメントし、ファネルシフタのフルネスがmaxSeSize未満であるときにmuxワードを要求する)このプロセスは、スライスにおける各グループが符号化を終了するまで進行し得る。いくつかの例では、スライスの終わりに、エンコーダ平衡FIFO202は、単一のmuxワードを形成するために十分なビットを含んでいないこと、または空であることがある。そのような場合、muxワードを導出するためにゼロパディング(すなわち、0値のビットでのパディング)が実行され得る。
図6Bに戻ると、レートバッファ155は、ビットストリームからのmuxワードを受信し、記憶し得る。デマルチプレクサ210は、レートバッファ155からのmuxワードを読み取り、muxワードが要求された順序でデコーダファネルシフタ212A、212B、または212C(まとめて、デコーダファネルシフタ212)のうちの1つに配置し得る。すなわち、デマルチプレクサ210は、受信されたmuxワードを、どのサブストリームがmuxワードを要求したかに基づいて、適切なデコーダファネルシフタ212に向けることができる。次いで、サブストリームごとのmuxワードは、エントロピーデコーダ165A、165B、または165Cのうちの1つ(たとえば、図2Bのエントロピーデコーダ165)によって復号され得る。
いくつかの例では、2の補数表現を使用する代わりに、符号絶対値表現が、サンプルの各グループまたはブロックをコーディングするために使用され得る。符号絶対値表現では、各グループまたはブロックにおけるシンボル値の絶対値がコーディングされ、非ゼロシンボルごとの符号ビットが後続する。プレフィックス部分は、グループにおけるシンボルの最大絶対値をシグナリングするために必要とされるビット、Bを示す。サフィックス部分は、各シンボルの絶対値を表す。最後に、非ゼロシンボルの符号ビットがシグナリングされる。
一例として、グループが4つのサンプルを含み、値が[1,-3,-1,0]であると仮定する。また、この例では、プレフィックスは、B=2(絶対値[1,-3,-1,0]から計算される)であり、サフィックスは01、11、01、00である。最後に、符号情報100がシグナリングされ、「1」が正数を示し、「0」が負数を示す。ゼロの符号はシグナリングされない。
2の補数表現と比較して、この表現の利点は、値がゼロであるシンボルの符号情報がシグナリングされないことである。したがって、この表現は、いくつかのモード、たとえば、ブロック予測および変換モードにおいてゼロ値がより確率が高いときに、優れたコーディング性能をもたらすことができる。
符号絶対値表現が使用されるとき、シンボルゼロの符号ビットがシグナリングされないと仮定すると、ビデオデコーダ30におけるパーサ論理にとって、ビットストリームからの符号情報を読み取るべきかどうかを知るためにシンボルを再構成または復号するのが望ましいことがある。すなわち、パーサ論理は、各シンボルがゼロであるか、それとも非ゼロであるかを判断し得る。シンボルが非ゼロである場合、符号情報がビットストリームからパースされ、そうでない場合(シンボルがゼロであるとき)、符号ビットはビットストリームから読み取られない。いくつかの例におけるパーサとデコーダ(たとえば、シンボルを復号するビデオデコーダ30における論理)との間のこの依存性のために、最大デコーダスループットが低減され得る。
スループットを増大させるために、いくつかの例ではハイブリッド方法が使用され、ハイブリッド方法では、最初の少数のグループまたはブロックが符号絶対値表現に基づいてコーディングされ、残りのグループまたはブロックが2の補数表現に基づいてコーディングされる。たとえば、最初の3つのグループまたはブロックが符号絶対値表現を使用してコーディングされ、最後のグループまたはブロックが2の補数表現を使用してコーディングされる。表現ごとの実際のエントロピーコーダは、DSU-VLCに基づいてよく、またはベクトルECであってよい。明快にするために、2の補数表現のためのベクトルECは、DSU-VLCに基づいてよく、その場合にシンボルが単一のコード値にマッピングされ、次いでVLCコードを使用してコード値がコーディングされる。符号絶対値表現では、各シンボルの絶対値が単一のコード値にマッピングされ、VLCコードを使用してコーディングされる。これに加えて、非ゼロシンボルごとに符号ビットがシグナリングされる。
いくつかの前の例示的なDSC実装形態では、平衡FIFOのサイズは、maxSeSizeとminSeSizeとの間の差に伴って増大する。これらのパラメータを仮定した場合の平衡FIFOサイズは、次のように計算される。スライスの最初にssmDelayブロック時間の遅延がある。この時間中に、ビットがSSM平衡FIFO(たとえば、エンコーダ平衡FIFO202)に配置されるが、何も除去されない。基本的に、これは、送信が始まる前にSSM平衡FIFOに十分なビットが存在することを確実にするバッファリング期間である。SSM平衡FIFOがアンダーフローしないことを確実にするために、送信が始まり得る前に平衡FIFOに以下の数のビット(requiredBits)が記憶される。「requiredBits」=(「maxSeSize」+「muxWordSize」-1)
ワーストケースでは、平衡FIFOは、ブロック時間あたり1minSeSizeシンタックス要素のレートでいっぱいになる。このワーストケース行動を仮定すると、SSM遅延(ブロック時間で測定される)は次のように計算される。「ssmDelay」=ceil(「requiredBits」/「minSeSize」)
ssmDelayを前提として、平衡FIFOがオーバーフローしないようにパラメータbalanceFifoSizeが決定される。これは、SSM遅延期間中のあらゆるブロックがmaxSeSizeビットを有する場合である。平衡FIFOサイズは次のように計算される。「balanceFifoSize」=「ssmDelay」*「maxSeSize」
たとえば、以下の構成を仮定する。
minSeSize=1
maxSeSize=142
muxWordSize=144
これから、balanceFifoSizeは次のように計算される。
「requiredBits」=(「maxSeSize」+「muxWordSize」-1)=(142+144-1)=285
「ssmDelay」=ceil(「requiredBits」/「minSeSize」)=ceil(285/1)=285
「balanceFifoSize」=「ssmDelay」*「maxSeSize」=285*142=40470(約40kbit)
別の例として、maxSeSize=185、minSeSize=1、およびmuxWordSize=192のとき、平衡FIFOの各々のサイズは、(185+192-1)*192=72192ビットであり得る。複数のサブストリームが本開示のDSC SSM技法に従って使用され得るので、本例に関連するハードウェアコストは法外に高くなり得る。
加えて、サブストリームの数およびいくつかのサブストリームへの単一のブロックの圧縮データの配列は、より大きいブロックサイズ(たとえば、8×2ブロックサイズ以上)の場合には最適化されないことがある。詳細には、前の例のうちのいくつかのサブストリーム多重化方式は、3つのサンプルからなるグループのみに好適であり得る。
本開示の1つまたは複数の例によれば、本開示は、より大きいブロックサイズを使用するビデオ圧縮技術(たとえば、ディスプレイストリーム圧縮)のための様々なSSM技法について説明する。ここで開示する技法は、ディスプレイストリーム圧縮に限定されず、むしろ、開示する技法は、スループットを増大させるために並列復号が望まれる任意のコーディング方式に適用され得る。以下で説明する技法が単独で使用されても一緒に使用されてもよいことを理解されたい。詳細には、本開示は、ゼロパディング、ゼロパディング検出、およびゼロパディング除去のための様々な技法について説明する。本開示の技法のすべてが、ゼロパディング技法とともに使用され得るが、サブストリームを構成するための技法、最大シンタックス要素サイズを決定するための技法、およびサブストリームパッキングのための技法を含む本開示の他の技法は、説明するゼロパディング技法なしで使用されてもよい。
ビデオエンコーダ20および/またはビデオデコーダ30のいくつかの例がDSC規格および/または次のADSC規格のコンテキストにおいて本明細書で説明されるが、本明細書で開示するシステムおよび方法が、任意の適切なビデオコーダまたはコーディング規格に適用可能であり得ることが当業者には諒解されよう。
図1A〜図1B、図2A〜図2B、および/または図6A〜図6Bに示すビデオエンコーダ20、ビデオデコーダ30、および/またはそれらの構成要素が、本明細書で説明するSSM技法の機能のうちの1つまたは複数を実行するように構成され得ることに留意されたい。たとえば、本明細書で説明するSSM技法は、ビデオエンコーダ(たとえば、図2Aにおけるビデオエンコーダ20)、ビデオデコーダ(たとえば、図2Bにおけるビデオデコーダ30)、またはたとえば、ビデオエンコーダ20のサブストリームマルチプレクサ145および/もしくはビデオデコーダ30のサブストリームデマルチプレクサ160など、それらの構成要素によって実行され得る。
ビデオエンコーダ20、ビデオデコーダ30、および/またはそれらの構成要素は、バッファを含む複数のプログラマブル計算ユニットによって共有される統合グローバルメモリを含むデバイス上に実装されてよく、バッファは、先入れ先出し(FIFO)バッファを含んでよい。デバイスは、少なくとも1つのプロセッサまたはプロセッサ回路(たとえば、中央処理装置(CPU))および/またはグラフィックス処理装置(GPU)を含み得る集積回路(IC)をさらに含んでよく、GPUは、1つまたは複数のプログラマブル計算ユニットを含んでよい。デバイスは、システムオンチップ(SoC)の一部であってよく、SoCは、少なくとも1つの縮小命令セットコンピューティング(RISC)命令セットを使用するCPUを含んでよい。SoCは、複数のCPUコアおよびGPUを含んでよい。
本開示の一例では、ビデオエンコーダ20は、4つのサブストリームにおいてビデオデータのブロック(たとえば、ビデオデータの8×2または他のサイズのブロック)を符号化するように構成されてよく、その場合に1つのサブストリーム(たとえば、サブストリーム0または「第1のサブストリーム」)が、ヘッダおよびコーディングモード関連情報をシグナリングするために使用され、他の3つのサブストリーム(たとえば、サブストリーム1、2、および3、または「第2の」、「第3の」、および「第4の」サブストリーム)が、3つの色成分(たとえば、YCoCg)を符号化するために使用される。ヘッダ情報は、コーディングモード情報、平坦度情報、またはビデオデコーダ30に通信されることが望まれる任意の他のオーバーヘッド情報を示すために使用されるビットを含み得る。コーディングモード関連情報は、特定のコーディングモードに固有である情報を指し得る。たとえば、BPモードに関するコーディングモード関連情報は、ブロック予測ベクトルを含む可能性がある。変換モードの場合、コーディングモード関連情報は、イントラ予測インデックス、変換区分インデックスなどを含み得る。
本開示のコンテキストでは、「シンタックス要素」という用語は、1つのブロックに関係する特定のサブストリームの符号化情報のすべてを指し得る。すなわち、本開示のコンテキストでは、シンタックス要素は、1つの個別の情報ではなく、特定のサブストリームに関するブロックの情報のすべてを指す。したがって、maxSeSizeは、特定のブロックに関する特定のサブストリームに対して許容可能なコード化情報の最大量を指す。同様に、minSeSizeは、特定のブロックに関する特定のサブストリームに対してコーディングされ得るコード化情報の最小量を指す。いくつかの例では、特定のサブストリームにとって、特定のコーディングモードでブロックをコーディングするために、定義されたmaxSeSizeよりも多くのデータが必要とされるとビデオエンコーダ20が判断した場合、ビデオエンコーダ20は、そのブロックに対する過剰なシンタックス要素サイズを生成するその特定のコーディングモードの使用を拒否する(たとえば、ビデオデータの特定のブロックに対してその特定のコーディングモードが使用可能ではないと判断する)ことができる。
一例では、(muxWordSize+maxSeSize-1)* maxSeSizeのエンコーダ平衡FIFO202の平衡FIFOサイズを使用する代わりに、以下で説明する本開示の技法は、より小さい平衡FIFOサイズを許容し得る。本開示では、平衡FIFO(たとえば、エンコーダ平衡FIFO202)のサイズは、balanceFIFOSizeによって示され、ビデオエンコーダ20は、コーデック(たとえば、ビデオエンコーダ20および/もしくはビデオデコーダ30)ならびに/またはそれらの構成要素のメモリ要件に基づいて、balanceFIFOSizeを構成または設定するように構成され得る。
別の例では、ビデオエンコーダ20が(muxWordSize+maxSeSize-1)*maxSeSizeよりも小さいbalanceFIFOSizeを使用するように構成されるとき、ビデオエンコーダ20は、floor(balanceFIFOSize/maxSeSize)ブロックとして初期(ブロック)遅延を計算するようにさらに構成されてよく、その場合に、floor(x)はxを、floor(x)<=xとなる最も近い整数に丸める。
この初期遅延時間中に、ビデオエンコーダ20は、ビデオデータのフレームのブロックを符号化し、それぞれのサブストリームごとの符号化ビットを、それぞれのエンコーダ平衡FIFO202に配置する。だが、この時間中に、ビデオエンコーダ20は、エンコーダ平衡FIFO202からmuxワードを除去しない。一例では、ビデオエンコーダ20は、初期遅延をfloor(balanceFIFOSize/maxSeSize)-1として計算するように構成され得る。一般に、初期遅延=floor(balanceFIFOSize/maxSeSize)であり、これは上限である。特定の実装形態に応じて、ビデオエンコーダ20は、上限以下の特定の初期遅延により構成され得る。
初期遅延期間が終了した後、ビデオエンコーダ20はmuxワードを、ビデオデコーダ30への送信のためにレートバッファ50に送信し始め、またこれらのmuxワードを、ファネルシフタデマルチプレクサモデル206に配置する。図7の例を参照すると、特定のエンコーダ平衡FIFO202がmuxワードを生成するために十分なビットを含んでいない場合、本開示の一例では、ビデオエンコーダ20は、少なくとも1muxワード相当のデータが利用可能となるように、特定のエンコーダ平衡FIFO202にゼロ(たとえば、ゼロのビット)を挿入するように構成され得る。図7は、エンコーダ側におけるゼロパディングを示す。一例では、エンコーダ平衡FIFO202がmuxWordSizeビットよりも少ないビットを含んでいるサブストリームの場合、ビデオエンコーダ20は、muxワードが送信され得るようにゼロパディングを実行するように構成され得る。デマルチプレクサモデル206のデコーダファネルシフタ状態は、デコーダファネルシフタのフルネスを示す。
パディングされるゼロのビットの数は、muxWordSize-balanceFIFOFullnessとして計算されてよく、balanceFIFOFullnessは、平衡FIFOにおけるビットの数(またはフルネス)を指す。FIFO中のゼロの挿入は、アンダーフローを防止する。別の例では、アンダーフローを防止するためにFIFOに1(すなわち、1のビット)が詰め込まれ得る。本開示の残りでは、アンダーフローを防止するためにパディングにゼロのビットが使用されると仮定される。とはいえ、本明細書で説明する技法は、パディングに1(1のビット)が使用されるときでも適用されてよい。
muxワードを生成するためにFIFOに配置されるゼロのビットはまた、(それらはビデオデコーダ30に送信されるので)ビットレートにカウントされる。平衡FIFOサイズは通常、頻繁なゼロパディングおよび過剰なメモリ要件を回避するように選択される。FIFOサイズがあまりにも小さい場合、ゼロパディングが頻繁に実行されなければならず、それはビットレートのかなりの部分を占め、それによって性能に直接影響が及ぶ可能性がある。一方、平衡FIFOサイズが大きくなるとゼロパディングの頻度が低下し得るが、これはメモリ要件を高める可能性がある。したがって、メモリ要件と性能との間の平衡したトレードオフを達成するようにFIFOサイズを注意深く選択するのが望ましい。
関係する態様では、エンコーダ平衡FIFO自体のサイズが縮小され得る一方で、レートバッファのサイズは変化がない。この意味で、エンコーダ平衡FIFO202のサイズおよびレートバッファ150のサイズは直交する。
ゼロパディングを使用する例では、正常な復号のために、ビデオデコーダ30は、受信された各muxワードがゼロパディングされているかどうかを最初に識別するように構成され得る。muxワードがゼロパディングされているとビデオデコーダ30が識別した場合、ビデオデコーダ30は、ゼロパディングされたビットの数を計算し、次いで、ゼロパディングされたビットはコード化ブロックデータの一部ではないので、ゼロパディングされたビットをフラッシュアウトする(たとえば、それらを除去する)ことができる。muxワードがゼロパディングされているかどうかを検出するために、またmuxワードがゼロパディングされている場合にゼロパディングビットの数を計算するために、ビデオデコーダ30は、サブストリームごとにエンコーダ平衡FIFOの平衡FIFOフルネス状態を判断するように構成され得る。すなわち、ビデオデコーダ30は、エンコーダ平衡FIFOの平衡FIFOフルネス状態を判断するためにビデオエンコーダ動作のモデルを実行するように構成され得る。これによりビデオデコーダ30は、エンコーダ動作を模倣することが可能になる。平衡FIFOフルネス状態は実際のFIFOではなく、平衡FIFOフルネス状態は、FIFOにおけるビットの数またはフルネスとして表されるエンコーダ平衡FIFOの状態を提示する値である。
上述のように、ビデオエンコーダ20による動作の一例では、balanceFIFOFullness<muxWordSizeのときにゼロパディングが発生する。したがって、ビデオデコーダ30において、muxワード要求が行われたときはいつでも、ビデオデコーダ30は、平衡FIFOフルネス状態をmuxWordSizeと比較し得る。balanceFIFOFullness<muxWordSizeの場合、ビデオデコーダ30は、現在のmuxワードがゼロパディングされていると判断し、ゼロパディングされたビットの数は、muxWordSizeと(平衡FIFOフルネス状態から推測される)平衡FIFOにおけるビットの数との間の差になる。
平衡FIFOフルネス状態に加えて、サブストリームごとに、ビデオデコーダ30は、追加のFIFOにmuxワード要求時間を記憶するように構成され得る。muxワード要求時間は、各サブストリームからのmuxワードが要求された時間を指す。一例では、これらの要求時間は、ブロックインデックスまたはブロックタイミングを使用して表され得る。サブストリームごとに、muxワード要求FIFOのサイズが、選択された初期遅延の値に縛られ得る。
本開示は、4つのサブストリームに適用される多重化技法の適用について説明するが、特定の数のサブストリームに限定されない。様々な異なるコーディングモードの場合の4つのサブストリームの各々に含まれるビデオデータの例について、以下でより詳細に説明する。ここで開示する技法は、任意の数のサブストリームに適用され得る。
ビデオデコーダ30は、デコーダファネルシフタ212がまだ有効なデータをまったく含んでいないので、たとえば、フルネスはゼロであり得るので、平衡FIFOフルネス状態をゼロに初期化し得る。加えて、muxワード要求時間FIFOも、それらの初期状態において空であり得る。
図8は、本開示のゼロパディングSSM技法を実行するように構成され得る例示的なビデオデコーダ30を示すブロック図である。図8では、線付きブロックがSSM機能を実行する構造を示し、白のブロックがFIFOバッファを示し、点付きブロックが固定ストレージを示す。図6Bに示す構造に加えて、図8の例におけるビデオデコーダ30はさらに、本開示の技法に従ってゼロパディングを検出しフラッシュするように構成された回路300により構成され得る。ビデオデコーダ30はまた、サブストリームごとの追加のFIFOおよび固定ストレージを含み得る。たとえば、ビデオデコーダ30は、それぞれのサブストリームごとの平衡FIFOフルネス状態メモリ302A、302B、302C、および302D(まとめて、平衡FIFOフルネス状態メモリ302)を含み得る。FIFOフルネス状態メモリ302は、レジスタを含む、任意のタイプのメモリまたはストレージであり得る。ビデオデコーダ30は、muxワード要求時間FIFO304A、304B、304C、および304D(まとめて、muxワード要求時間FIFO304)をさらに含み得る。ビデオデコーダ30のデコーダ動作は、SSPにロードされるサブストリーム(たとえば、図8ではss0、ss1、ss2、およびss3と標示されたサブストリーム0〜4)ごとの1muxワードを要求することによって開始し得る。各SSPは、ファネルシフタ212およびエントロピーデコーダ165を含み得る。各SSPは、各ブロック時間中に1シンタックス要素相当のデータ(たとえば、単一のブロックを復号するために必要とされる数のビット)を除去し得る。除去されたビットの数は、それぞれの平衡FIFOフルネス状態メモリ302をインクリメントするために使用され得る。
さらに、ビデオデコーダ30は、それぞれのサブストリームごとにmuxワード要求時間FIFO304にmuxワード要求時間を追加するようにさらに構成され得る。ブロック時間ごとに、ビデオデコーダ30は、1シンタックス要素相当のデータを除去することができ、それぞれのファネルシフタ212から除去されたビットの数は、それぞれの平衡FIFOフルネス状態メモリ302をインクリメントするために使用される。ファネルシフタフルネス値のいずれかがmaxSeSizeよりも小さくなった場合、muxワードがレートバッファ155から取られ、それぞれのSSPに配置されてよく、要求時間がそれぞれのmuxワード要求時間FIFO304に追加され得る。
現在ブロックインデックスが初期遅延に等しいとき、ビデオデコーダ30は、受信した第1のmuxワードがゼロパディングされているかどうかを(たとえば、ゼロパディング検出およびフラッシュ回路300を使用して)チェックする。この判断を行うために、ビデオデコーダ30は、平衡FIFOフルネス状態メモリ302の各々をチェックし、ビデオエンコーダ20における各エンコーダ平衡FIFO202のフルネスがmuxWordSizeよりも小さいかどうかを判断するように構成され得る。各エンコーダ平衡FIFO202のフルネスがmuxWordSizeよりも小さい場合、ビデオデコーダ30は、それぞれのサブストリームにおけるmuxワードがゼロパディングされていると判断することができ、ゼロパディングされたビットの数は、muxWordSizeと平衡FIFOフルネス状態の値との間の差になる。
ビデオデコーダ30(たとえば、ゼロパディング検出およびフラッシュ回路300を使用する)は、ゼロのビットをそれぞれのファネルシフタ212においてフラッシュするために、計算された数のパディングされたビットを使用する。さらに、それぞれの平衡FIFOフルネス状態メモリ302はゼロに設定される。平衡FIFOのフルネスがmuxWordSizeよりも小さくない場合、ビデオデコーダ30は、muxワードがゼロパディングされていないと判断する。この場合、ビデオデコーダ30は、それぞれの平衡FIFOフルネス状態メモリ302をmuxWordSizeだけデクリメントする。このプロセスが完了すると、ビデオエンコーダ20は、それぞれのmuxワード要求時間FIFO304における第1の要素を除去する。上述のように、サブストリームごとに、ビデオデコーダ30が最初に各サブストリームからの1muxワードを要求することに伴って、それぞれのmuxワード要求時間FIFO304における第1の要素はゼロとなる。この手順により、ビデオデコーダ30は、第1のmuxワードにおけるゼロパディングを正常に識別し、フラッシュすることができる。初期遅延に起因して、ビデオデコーダ30は、デコーダ現在ブロックインデックスが初期遅延に等しいときに、第1のmuxワードにおけるゼロパディングをチェックすることができる。
第1のmuxワードが処理された後、ビデオデコーダ30は、muxワードの各々に対するゼロパディングを検出するための同じ手順を実行し得る。各ブロック時間に、ビデオデコーダ30は、muxワード要求時間FIFO304の「フロント」におけるエントリをチェックする。図9は、デコーダSSMにおけるゼロパディングを検出し、パディングされたビットをフラッシュするための例示的なプロセスを示すフローチャートである。図9のプロセスは、ビデオデコーダ30によって実行され、サブストリームごとに繰り返され得る。ビデオデコーダ30は、次のmuxワード要求時間(reqTime)を最初に決定し得る(310)。ビデオデコーダ30は、デコーダの相対要求時間(modReqTime)を決定するために、SSMブロック遅延(blockDelay)にreqTimeを加算し得る(312)。ビデオエンコーダ20とビデオデコーダ30との間の遅延があるので、ビデオデコーダ30は、デコーダの相対要求時間を決定するために、要求時間にblockDelayを加算し得る。ビデオデコーダ30は次いで、現在ブロックインデックスがmodReqTimeに等しいかどうかを判断する(314)。noの場合、プロセスは終了する。yesの場合、ビデオデコーダ30は、上記のように、パディングされたビットがあればそれを識別しフラッシュするために、平衡FIFOフルネス状態がmuxWordSizeよりも小さいかどうかをチェックする(316)。
平衡FIFOフルネス状態がmuxWordSize未満である(すなわち、パディングが検出された)場合、ビデオデコーダ30は、ゼロパディングビットの数(numPadBits)を計算する(322)。ビデオデコーダ30は、muxWordSizeから平衡FIFOフルネス状態の値を減算することによって、numPadBitsを計算し得る。ビデオデコーダ30は次いで、計算された数のゼロパディングビットをそれぞれのファネルシフタから除去し得る(324)。ビデオデコーダ30は次いで、平衡FIFOフルネス状態の値をゼロに設定し得る(326)。ビデオデコーダ30はさらに、それぞれの要求時間をmuxワード要求時間FIFOから除去し得る(320)。そしてプロセスは終了し、パディングビットの除去とともにビデオデータのブロックのサブストリームが復号され得る。加えて、ビデオデコーダ30は、muxワード要求時間FIFOを更新し得る(328)。
平衡FIFOフルネス状態がmuxWordSize未満ではない(すなわち、パディングが検出されていない)場合、ビデオデコーダ30は、平衡FIFOフルネス状態メモリの値をmuxWordSizeだけデクリメントする(平衡FIFOフルネス状態-=muxWordSize)(318)。ビデオデコーダ30はさらに、それぞれの要求時間をmuxワード要求時間FIFOから除去し得る(320)。そしてプロセスは終了し、ビデオデータのブロックのサブストリームが復号され得る。加えて、ビデオデコーダ30は、muxワード要求時間FIFOを更新し得る(328)。
図10は、本開示のゼロパディングSSM技法を実行するように構成され得る例示的なビデオエンコーダ20を示すブロック図である。図10では、線付きブロックがSSM機能を実行する構造を示し、白のブロックがFIFOバッファを示し、点付きブロックが固定ストレージを示す。図6Aに示す構造に加えて、図8の例におけるビデオデコーダ30はさらに、異なるデマルチプレクサモデル207により構成され得る。詳細には、デマルチプレクサモデル207は、図8のビデオデコーダ30によって実行されるSSMデマルチプレクサプロセスのモデルを含む。たとえば、デマルチプレクサモデル207を使用して、ビデオエンコーダ20は、いつゼロパディングをサブストリームに挿入すべきかを判断し得る。加えて、ビデオデコーダ30は、それぞれのビットストリームの各々において、ビデオデコーダ30によって決定されるmuxワード要求時間および平衡FIFOフルネス状態を追跡し得る。図6Aの例と同様に、ビデオエンコーダ20はまた、それぞれのビットストリームごとにデコーダファネルシフタ状態を追跡し得る。図10の例では、ビデオエンコーダ20は、エンコーダSSM技法を実行するように構成されてよく、その場合に、図8および図9を参照しながら上記で説明したデマルチプレクサモデルが、muxワードを生成するために使用される。ビデオエンコーダ20におけるデマルチプレクサモデル207は、SSP(たとえば、デコーダファネルシフタ状態)に加えて、ビデオデコーダ30のモデル化された平衡FIFOフルネス状態とmuxワード要求時間FIFOの両方を使用して、muxワードを生成する。
遅延、たとえば初期SSM遅延に起因して、ビデオエンコーダ20とビデオデコーダ30との間でブロックタイミングが異なるので、ビデオエンコーダ20におけるデマルチプレクサモデル207は、遅延を考慮するように構成される。たとえば、ビデオエンコーダ20が(たとえば、このときにビデオデコーダ30がmuxワードを要求するとの判断に基づく)デマルチプレクサモデル207からのmuxワード要求を受信したとき、それぞれの要求時間は、エンコーダブロックタイミングに関して、またはデコーダブロックタイミングに関して表され、muxワード要求時間FIFOに記憶され得る。一例として、初期遅延の後、ビデオエンコーダ20は、各SSPに第1のmuxワードを配置し得る。したがって、エンコーダブロックタイミングに関するmuxワード要求時間は、初期遅延に等しくなる。ビデオデコーダ30は、ブロック時間ゼロにおいて第1のmuxワードを受信し、したがって、要求時間は、デコーダブロックタイミングに関してゼロである。したがって、図9の例に示すmuxワード要求時間および現在ブロックインデックスは、それらがデコーダブロックタイミングに関して表されることに伴って修正される。
一例では、ビデオエンコーダ20におけるデマルチプレクサモデル207は、エンコーダブロックタイミングに関してFIFOにmuxワード要求時間を記憶し得る。この例示的な技法が使用されるとき、図9の例におけるmodReqTimeは、reqTimeに等しく設定され得る。また、初期遅延を考慮して、図9における現在ブロックインデックスは修正されてよく、(エンコーダ現在ブロックインデックス)-(初期遅延)として計算されてよい。
明快にするために、図11の例に示すビデオエンコーダ側20において使用されるデマルチプレクサモデル207のゼロパディングを検出しフラッシュする例示的なフローチャート(エンコーダ側において使用されるデマルチプレクサモデルのゼロパディングの検出およびフラッシュ)。ここで、muxワード要求時間が、エンコーダブロックタイミングに関して記憶され、エンコーダ現在ブロックインデックスが、初期遅延を考慮してブロック遅延から減算される。図11が特定の例示的な実装形態を示すことに留意することが重要である。ビデオエンコーダ20において使用されるデマルチプレクサモデルを構築するために、初期遅延を考慮するように他の適用可能な技法が実装されてよい。
図11のプロセスは、ビデオデコーダ20のデマルチプレクサモデル207において実行されてよく、サブストリームごとに繰り返されてよい。ビデオエンコーダ20は、次のmuxワード要求時間(reqTime)を最初に決定し得る(410)。上述のように、modReqTimeがreqTimeに等しく設定され得る。ビデオエンコーダ20は、現在ブロックインデックスを決定するために、エンコーダ現在ブロックインデックスからブロック遅延を減算し得る(412)。ビデオデコーダ20は次いで、現在ブロックインデックスがmodReqTimeに等しいかどうかを判断する(414)。noの場合、プロセスは終了する。yesの場合、ビデオエンコーダ20は、パディングされたビットが必要とされるかどうかを識別するために、平衡FIFOフルネス状態がmuxWordSizeよりも小さいかどうかをチェックする(416)。
平衡FIFOフルネス状態がmuxWordSize未満である(すなわち、パディングが必要とされる)場合、ビデオデコーダ20は、ゼロパディングビットの数(numPadBits)を計算する(422)。ビデオエンコーダ20は、muxWordSizeから平衡FIFOフルネス状態の値を減算することによって、numPadBitsを計算し得る。ビデオデコーダ20は次いで、デマルチプレクサモデル207において、計算された数のゼロパディングビットをそれぞれのファネルシフタから除去し得る(424)。ビデオエンコーダ20は次いで、平衡FIFOフルネス状態の値をゼロに設定し得る(426)。ビデオエンコーダ20はさらに、それぞれの要求時間をmuxワード要求時間FIFOから除去し得る(420)。そしてプロセスは終了する。加えて、ビデオエンコーダ20は、muxワード要求時間FIFOを更新し得る(428)。
平衡FIFOフルネス状態がmuxWordSize未満ではない(すなわち、パディングが必要とされない)場合、ビデオエンコーダ20は、平衡FIFOフルネス状態メモリの値をmuxWordSizeだけデクリメントする(平衡FIFOフルネス状態-=muxWordSize)(418)。ビデオエンコーダ20はさらに、それぞれの要求時間をmuxワード要求時間FIFOから除去し得る(420)。そしてプロセスは終了する。加えて、ビデオエンコーダ20は、muxワード要求時間FIFOを更新し得る(428)。
図12は、SSM符号化動作の例示的なフローチャートを提供する。初期遅延期間中に、ビデオエンコーダ20は、符号化されているサブストリームの各々に関して、(たとえば、エンコーダブロックインデックスによって示される)様々なコード化ブロックのためのシンタックス要素を追加する(500)。ビデオエンコーダ20は、初期SSM遅延期間の後、符号化されているサブストリームの各々に関して、様々なコード化ブロックのためのシンタックス要素を追加し続ける(502)。デマルチプレクサモデル207がmuxワードを要求したとき(504)、ビデオエンコーダ20は、muxワードを生成し(508)、muxワードをレートバッファ150に、またデマルチプレクサモデル207のファネルシフタにも配置する。また、要求時間がmuxワード要求FIFOに追加される(506)。デマルチプレクサモデル207は次いで、シンタックス要素サイズに基づいてファネルシフタフルネスを調整する。最後に、デマルチプレクサモデル207は、上記のように、エンコーダ平衡FIFOフルネス状態およびファネルシフタフルネス状態を更新する(510)ために使用される、ゼロパディングされたビットを検出しフラッシュする。ビデオエンコーダ20はまた、各ブロックが符号化されるのに伴って、ブロックインデックスをインクリメントし得る(512)。デマルチプレクサモデル207がmuxワードについての要求を受信しなかったとき(504)、ビデオエンコーダ20は、上記のように、エンコーダ平衡FIFOフルネス状態およびファネルシフタフルネス状態を更新する(510)。ビデオエンコーダ20はまた、SSM遅延中に平衡FIFOにシンタックス要素を追加した後、エンコーダ平衡FIFOフルネス状態およびファネルシフタフルネス状態を更新する。
SSPのすべてがmuxワードを要求するとき、ビデオエンコーダ20は、ビットストリームにmuxワードを挿入するための特定の順序を選択し得る。たとえば、一実装形態では、muxワードは以下の順序で、最初にサブストリーム0から、次いでサブストリーム1から、その後にサブストリーム2、そして最後にサブストリーム3から生成される。デコーダ側においても同じ順序付けが使用され得る。エンコーダ側およびデコーダ側において同じ順序付けが使用される限り、代わりの順序付けが利用されてもよい。
本開示の1つまたは複数の態様によれば、SSMにおけるサブストリームは、以下の態様を考慮することによって様々なモードの場合に構成され得る。以下の技法は、図8〜図12を参照しながら説明したゼロパディングサブストリーム多重化技法を用いてまたは用いずに使用され得る。すなわち、以下の技法は、ゼロパディングが使用されない状況(たとえば、図6Aおよび図6B)またはゼロパディングが使用される状況(たとえば、図8〜図12)において使用され得る。
いくつかの例では、サブストリームがすべてパースされ並列に復号され得るように、符号化サブストリームの間に最小依存性があり得る。すなわち、1つのサブストリームにおけるデータが、そのサブストリームにおけるデータが別のサブストリームにおけるデータを復号するために必要とされないように生成される。何らかの依存性が存在する場合でも、ビデオエンコーダ20は、待機時間またはクリティカルパスが低減され得るように、サブストリームにおいて早期に(たとえば、サブストリーム0において早期に)依存情報をシグナリングするように構成され得る。たとえば、コーディングモード情報が復号されると、ビデオデコーダ30がそのような情報を使用して残りのサブストリームをパースし、その中の情報を復号することができるように、ビデオエンコーダ20は、サブストリーム0において最初にコーディングモード情報ビットをシグナリングするように構成され得る。本開示の別の例では、ゼロパディングが使用されるとき、予想される(たとえば、既定の)サブストリーム長さは、ゼロパディングの量が最小化され得るように、ほぼ平衡するか、または等しくなるべきである。
特定の一実装形態では、ディスプレイストリーム圧縮において使用されるいくつかのモードの場合、本明細書で説明するように、4つのサブストリームが利用され、構成され得る。本例では、ブロックサイズは8×2(幅:8ピクセル、高さ:2ピクセル)であると仮定される。
図13〜図19は、異なるコーディングモードの場合の例示的なサブストリームを示す。図13〜図19では、FLC凡例に従って影を付けたシンタックス要素は、固定長コーディングを使用してコーディングされる。VLC凡例に従って影を付けたシンタックス要素は、可変長コーディングを使用してコーディングされる。グループ凡例に従って影を付けたシンタックス要素は、以下でより詳細に定義するように、エントロピーコーディンググループである。
図13の例に示すように、BPモードの場合、サブストリーム0は、ヘッダ情報(たとえば、コーディングモードシグナリングおよび平坦度シグナリング)、区分情報(たとえば、区分テーブル)、ならびに/またはブロック予測ベクトル(BPV0、BPV1、...、BPVx)を含み得る。図13の例では、区分情報の長さは4ビットであり、これは、各2×2サブブロックが1×2サブブロックにさらに区分されるかどうかを示す。サブストリーム1、2、および3は、コーディングされているブロックのピクセルの3つの色成分(たとえば、それぞれY、Co、およびCg)からの符号化情報を含み得る。YCoCgのカラーフォーマットは一例にすぎない。サブストリーム1、2、および3は、所望の任意のカラーフォーマット(たとえば、RGB、YCrCb、YUVなど)の符号化情報を含み得る。加えて、サブストリーム2および3におけるクロマ成分に関して、サブストリームが任意の予測残差を含むかどうかを示す成分スキップフラグがシグナリングされ得る。
図14の例に示すように、変換モードの場合、サブストリーム0は、ヘッダ情報(たとえば、コーディングモードシグナリングおよび平坦度シグナリング)、イントラ予測インデックス、ならびに/または変換区分インデックスを含み得る。サブストリーム1、2、および3は、コーディングされているブロックのピクセルの3つの色成分(たとえば、それぞれY、Co、およびCg)からのコード化情報を含み得る。変換モードの場合、サブストリーム1、2、および3の各々は、ブロックにおける最後有意係数(たとえば、非ゼロ変換係数)の位置(Last Sig.Position)ならびに最後有意係数の符号値(Last Sig.Pos Sign)を示す符号化情報を含み得る。加えて、サブストリーム2および3におけるクロマ成分に関して、サブストリームが任意の有意変換係数を含むかどうかを示す成分スキップフラグがシグナリングされ得る。
図15の例に示すように、MPPモードの場合、サブストリーム0は、ヘッダ情報(たとえば、コーディングモードシグナリングおよび平坦度シグナリング)、MPPモードに使用される色空間(たとえば、色空間変換(CSC))、ならびに/または3つの色成分の各々からの4つのサンプルを含み得る。一例では、4つのサンプルは、ブロックの最初の4つのサンプルであり得る。サブストリーム1、2、および3は、3つの色成分からの8×2ブロックの残りの12個のサンプルからの符号化情報を含み得る。MPPモードに使用される色空間に応じて、3つの色成分は、たとえば、それぞれY、Co、およびCg(またはそれぞれR、G、およびB)であり得る。
図16の例に示すように、パターンモードの場合、サブストリーム0は、ヘッダ情報(たとえば、コーディングモードシグナリングおよび平坦度シグナリング)、以前の辞書における保持されたパターンに関連するビットなどを含み得る。これは、以前の辞書における何らかのパターンが保持されているかどうか(保持パターンイネーブル)をシグナリングするための1ビットを含み得る。何らかのパターンが保持されている場合、以前の辞書における個々のパターンについて1ビットずつ(保持パターンマッピング)がシグナリングされ得る。加えて、新しいパターンの数(新パターン数)もサブストリーム0においてシグナリングされる。新しいパターンは、サブストリーム0から開始して、1、2、および3(順番に)の4つのサブストリームの間で等しく分散される。一例として、図16では、最初の3つのサブストリーム0、1、および2において、それぞれ新パターン0、1、および2として示される3つの新しいパターンがシグナリングされる。
パターンインデックス(パターンidx)がサブストリーム1、2、および3の間で等しく分散される。1つのブロックに16個のパターンインデックスがあるので、図16の例に示すように、1つの方法として、サブストリーム1において6つのインデックス、サブストリーム2において5つのインデックス、そしてサブストリーム3において残りの5つのインデックスをシグナリングする。
BPスキップモードは、BPモードの特殊な場合であり、残差が符号化されない。図17は、BPスキップモードの場合の例示的なサブストリームを示す。サブストリーム0は、ヘッダ情報(たとえば、コーディングモードシグナリングおよび平坦度シグナリング)、区分情報(たとえば、区分テーブル)などを含み得る。ブロック予測ベクトル(BPV)は、サブストリーム0から開始して、1、2、および3(順番に)の4つのストリームの間で等しく分散される。一例として、BPベクトルが2×1のサブブロックごとにコーディングされるとき、図17の例に示すようにサブストリームに、8×2のブロックサイズのための8つのBPベクトルが置かれる。
MPPFモードは、MPPモードの特殊な場合であり、MPPFにおける残差が、固定サイズ量子化器を使用して符号化される。図18の例に示すように、MPPFの場合のサブストリームは、MPPモードの場合と同様の方法で構成され得る。
図19の例に示すように、DPCMモードの場合、サブストリーム0は、ヘッダ情報(たとえば、コーディングモードシグナリングおよび平坦度シグナリング)を含み得るのに対し、サブストリーム1、2、および3はそれぞれ、3つの色成分(たとえば、それぞれY、Co、およびCg)からの符号化情報を含み得る。サブストリーム1、2、および3の各々は、ブロックのそのサブストリームに関する予測残差があるかどうかを示す成分スキップフラグを含み得る。
レートバッファのアンダーフローを防止するために、本明細書で説明するディスプレイストリーム圧縮技法の1つまたは複数の態様によりレートバッファ150においてゼロパディングが実施され得る。これが発生するとき、ゼロパディングされたビットの数が、サブストリーム0から開始して、1、2、および3の順番ですべてのサブストリームに等しく分散される。レートバッファにおけるこのゼロパディングは、上記で説明したゼロパディングとは異なることに留意されたい。他の例では、ゼロパディングビットは、サブストリーム1〜3のみに追加され得る(たとえば、サブストリーム0はゼロパディングされない)。
明快にするために、また説明の目的で、ゼロパディングされたビットの数がnumPadBitsであり、サブストリームの数が4であると仮定する。numPadBitsビットを4つのサブストリームに等しく分散するための1つの方法は、一度に1ビットを追加することによって巡回的にサブストリームを通して繰り返すことである。そのような実装のための擬似コードを以下に提示する。
Int subStreamIdx = 0;
Int numSubStreams = 4;
for (Int i = 0; i < numPadBits; i++)
{
//subStreamIdxにおいて単一のゼロのビットを追加する
AddZeroBit(substreamIdx);
//subStreamIdxを更新する
subStreamIdx = (subStreamIdx + 1) % numSubStreams;
}
4つのサブストリームにおいてゼロパディングされたビットを追加する図が、図20に示されている。ゼロパディングされたビットは、レートバッファのアンダーフローを防止するために挿入される。図20の例では、CurSESizeは、特定のブロックをコーディングするために必要とされるビットの総数を示し、BufferFullnessは、レートバッファのフルネスを示す。レートバッファ150は、ブロック時間ごとに、avgBlockBitsによって与えられる一定数のビットを除去する。たとえば、8×2のブロックサイズおよび6bppのターゲットビットレートの場合、avgBlockBitsは96である。図20に示すように、BufferFullness+curSESizeがavgBlockBits未満であるとき、アンダーフローを防止するためにレートバッファ150においてゼロパディングが実行される。numPadBits個のゼロのビットを挿入することで、レートバッファ150がアンダーフローしないようになる。その場合にパディングビットが、上記のように各サブストリームに等しく分散される。
明快にするために、また説明の目的で、図20のゼロパディング技法は、4つのサブストリームを使用して示されているが、同じ技法が任意の数のサブストリームに適用されてよい。
レートバッファゼロパディングの別の例では、既定のパディングサイズが決定され得る(たとえば、16ビットのパディングワード)。ビデオエンコーダ20は、サブストリーム1、2、3の各々にこれらのパディングワードのうちの2つを配置するように構成され得る。ビットの数(この場合は16)は、6*n=avgBlockBitsとなるように選択される。6bppの圧縮の場合、avgBlockBits=96である。ビデオエンコーダ20は、ピクチャパラメータセット(PPS)パラメータの間でレートバッファパディングのサイズをシグナリングするように構成され得る。
上記で説明したように、muxワードサイズは、maxSeSize以上になるように選択される。したがって、maxSeSizeが増大する場合は、より大きいmuxWordSizeが必要となり、平衡FIFOサイズ(たとえば、エンコーダ平衡FIFO202にとって必要なメモリの量)が増大することになる。また、maxSeSizeは、ゼロパディングの頻度を高めることがあり、品質に影響が及び得る。したがって、本開示の一例では、ハードウェア要件に応じてmuxワードサイズおよび平衡FIFOサイズが制御され得るような構成可能パラメータとしてのmaxSeSize。すなわち、ビデオエンコーダ20は、所与の実装形態に関してmaxSeSizeを決定するように構成され得る。
ビデオエンコーダ20は、ブロックごとに最良のコーディングモードを選択する一方、ビデオエンコーダ20は、所与のサブストリームのためのシンタックス要素サイズが被選択maxSeSizeよりも大きくなるコーディングモードを拒否するように構成され得る。すなわち、ビデオエンコーダ20は、ブロックのためのmaxSeSizeよりも大きいシンタックス要素サイズを特定のコーディングモードが生成するかどうかの判断に基づいて、複数のコーディングモードのうちのどのコーディングモードが使用可能であるか、または使用可能ではないかを判断し得る。ビデオエンコーダ20は、サブストリームのいずれかのためのmaxSeSizeよりも大きいシンタックス要素サイズを生成するコーディングモードが、ブロックを符号化するために使用可能ではないと判断する。ビデオエンコーダ20は、サブストリームのすべてのためのmaxSeSize以下のシンタックス要素サイズを生成するコーディングモードが、ブロックを符号化するために使用可能であると判断する。これにより、ビデオデコーダ30が、単一のブロックを復号するために各サブストリームからの多くて1muxワードを要求するようになる。単一のブロックが情報の2つ以上のmuxワードを必要とするならば、ビデオデコーダ30は、単一のブロックを復号するために複数のmuxワードを要求する必要があることになる。
ビデオエンコーダ20は、モード選択アルゴリズムを使用して最良のコーディングモードを決定し得る。ビデオエンコーダ20は、いくつかの制約に従って、所与のブロックのためのレートひずみ(RD)コストを最小化するコーディングモードを決定する。例示的な制約は以下を含み得る。
1)現在のモードを選択することによってレートバッファがアンダーフローしない。
2)現在のモードを選択することによってレートバッファがオーバーフローしない。
3)現在のモードが選択された場合、少なくとも、スライスにおける各残存ブロックに利用可能なminBlockBitsがある。
一例では、ビデオエンコーダ20は、maxSeSizeにより事前構成され得る。事前構成されたmaxSeSizeは、オフラインで決定されてよく、特定のbppを仮定した場合の所望の性能レベルに基づき得る。実験結果によれば、一般に、6bppの場合にmaxSeSize=126がうまくいき、8bpp以上の場合にmaxSeSize=142がうまくいく。低いQPでは、BPモードと変換モードの両方は、あまりにも高くつくことがあり(たとえば、いくつかのブロックのためにmaxSeSizeよりも多くのビットを必要とすることがあり)、特定のブロックのためのシンタックス要素サイズ(seSize)がmaxSeSizeよりも大きい(たとえば、seSize>maxSeSize)ことに基づいて、ビデオエンコーダ20によって選択解除されるか、または使用可能ではないと判断されることがある。一般に、事前構成されたmaxSeSizeの値は、大きいシンタックス要素サイズをサポートすることと平衡FIFOサイズを最小化することとの間のトレードオフとして選択され得る。
他の例では、事前構成されたmaxSeSizeは、BPモードに関連する最大予想シンタックス要素サイズに基づいて決定され得る。だが、これは、BPモードが常に利用可能となることを保証しない。いくつかのブロックの場合、maxSeSizeよりも大きいシンタックス要素サイズをBPモードが必要とする可能性があり得る。他の例では、低いQP値の場合、変換モードは、maxSeSizeよりも大きいシンタックス要素サイズを有し得る。これが発生するとき、ビデオエンコーダ20は、最良モード選択中に現在ブロックに対して変換モードを拒否する(たとえば、変換モードが使用可能ではないと判断する)ことがある。他の例では、ビデオエンコーダ20は、MPPモードがすべてのブロックに利用可能となるように、maxSeSizeにより事前構成され得る。
いくつかのエッジケースでは、上記の提案されたサブストリームパッキングまたは多重化技法は、準最適であり得る。たとえば、ソースデータがグレースケール(たとえば、クロマ値なし)である場合、成分スキップ(ブロックごとにサブストリームあたり1ビット)を使用してサブストリーム成分CoおよびCgがコーディングされ得るので、これらの成分がアンダーフローするのを防止するために、頻繁なゼロパディングがCo(サブストリーム2)およびCg(サブストリーム3)に利用され得る。グレースケール画像は通常、非常に良好に圧縮されるので、これはエッジケースと見なされ、ドロップは軽微であり、たとえば、ピーク信号対雑音比(PSNR)などの客観的基準を使用して認識されるだけであり得る。すなわち、視覚的ロスは目立たないことがある。
そのようなエッジケースに対処するために、サブストリームパッキングの別の手法は、複数のサブストリームの間で成分ごとにデータを分散することを伴い得る。一例では、単一の成分のためのエントロピーコーディンググループ(ECグループ)が、利用可能なサブストリームの間で(たとえば、利用可能なサブストリームのすべてまたはサブセットの間で)分散され得る。ECグループは、エントロピーコーディングのために一緒にグルーピングされている1つまたは複数のサンプルからなる集合である。たとえば、BPモードの場合、ECグループは、一緒にグルーピングされていて、ビットストリームにおいてプレフィックスを共有することになる4つのサンプルを含む。変換モードの場合、ECグループごとのサンプルの数は、特定の周波数情報とともに係数の予想される大きさに起因して、可変的である。
たとえば、ルーマECグループ0がサブストリーム0に配置されること、ルーマECグループ1がサブストリーム1に配置されることなどがある。同様の方法で、クロマ成分も利用可能なサブストリームの間で分散され得る。別の例では、異なるサブストリームのシンタックス要素の長さの間の予想される不一致が最小化されるように、ECグループがサブストリームの間で分散され得る。
そのようなパッキング技法を実装することによって、3つの成分のサイズの間の不平衡が、さほど頻繁ではないゼロパディングにつながり得る。そのようなパッキング技法は、サブストリームの間の依存性の若干の増大に関連付けられることがあり、それは、たとえば、サブストリームデマルチプレクサにおける追加の論理により対処され得る。
一例では、ハイブリッドエントロピー方法が、代替サブストリームパッキング方法に加えて使用され得る。代替サブストリームパッキング方法が使用されるとき、スクランブリングのために各サブストリームにおけるすべてのグループが同じ成分からのものではないことがあることを想起されたい。ハイブリッドエントロピーコーディングが適用されるとき、一例では、各サブストリームにおける最後のグループは、2の補数表現を使用し得る一方、(同じサブストリームにおける)最初の3つのグループは、符号絶対値表現を使用し得る。ハイブリッドエントロピー方法はスループット要件を満たすことを可能にするので、そのような方法が望ましいことがある。したがって、ハイブリッドエントロピー方法は、ヘッダ情報を搬送するサブストリーム(たとえば、サブストリーム0)に適用されなくてよく、通常、ヘッダ情報はモード、平坦度シグナリングなどを含む。また、ハイブリッド方法は、固定長コードを使用するモード、たとえば、パターン、MPP、MPPFに適用されなくてよい。
別の例では、2の補数表現を使用するか、それとも符号絶対値表現を使用するかの決定(たとえば、ハイブリッドエントロピーコーディング方法)は、同じサブストリームにおける非ゼロシンボルを有するグループの数に基づく。一例では、2の補数表現は、同じサブストリームにおける最初の3つのグループの各々が少なくとも1つの非ゼロ係数を有する場合に、最後のグループのみに使用される。それ以外は、符号絶対値表現が使用される。2の補数表現は、コーディング効率を低下させるので、所望のスループットを達成するために必要なときのみ使用され得る。
図21は、本開示の一例による符号化方法を示すフローチャートである。図21の技法は、上記で説明した様々な例に整合する形で、ビデオエンコーダ20の1つまたは複数の構造構成要素によって実行され得る。
本開示の一例では、ビデオエンコーダ20は、1つまたは複数のコーディングモードの中から、ビデオデータのブロックを符号化するためのコーディングモードを決定するように構成されてよく、コーディングモードは、最大シンタックス要素サイズに基づいて決定される(600)。ビデオエンコーダ20は、ビデオデータの複数の符号化サブストリームを作成するために、決定されたコーディングモードに従って複数のサブストリームにおいてビデオデータのブロックを符号化するようにさらに構成され得る(602)。ビデオエンコーダ20は、ビデオデータの複数の符号化サブストリームをそれぞれの平衡先入れ先出し(FIFO)バッファに記憶し(604)、複数の符号化サブストリームを、ビデオデコーダに送信するためにビットストリームにおいて多重化する(606)ようにさらに構成され得る。本開示のさらなる一例では、ビデオエンコーダ20は、一定のビットレートでビデオデコーダに複数の符号化サブストリームをシグナリングするようにさらに構成され得る。
本開示の別の例では、ビデオエンコーダ20は、複数のコーディングモードのうちのコーディングモードの第1のセット内の各コーディングモードが、コーディングモードの第1のセット内の各コーディングモードが複数のサブストリームのうちの1つのための最大シンタックス要素サイズよりも大きいシンタックス要素サイズを生成するとの判断に基づいて、ビデオデータのブロックを符号化するために使用可能ではないと判断するようにさらに構成され得る。ビデオエンコーダ20は、複数のコーディングモードのうちのコーディングモードの第2のセット内の各コーディングモードが、コーディングモードの第2のセット内の各コーディングモードが複数のサブストリームのすべてのための最大シンタックス要素サイズ以下のシンタックス要素サイズを生成するとの判断に基づいて、ビデオデータのブロックを符号化するために使用可能であると判断するようにさらに構成され得る。ビデオエンコーダ20は、コーディングモードの第2のセットの中から、ビデオデータのブロックを符号化するためのコーディングモードを決定するようにさらに構成され得る。本開示の別の例では、ビデオエンコーダ20は、最大シンタックス要素サイズにより事前構成され得る。
本開示の別の例では、ビデオデータの複数の符号化サブストリームを作成するために、決定されたコーディングモードに従って複数のサブストリームにおいてビデオデータのブロックを符号化するために、ビデオエンコーダ20は、決定されたコーディングモードに基づいて複数のサブストリームのうちの第1のサブストリームにおいてヘッダ情報を符号化するようにさらに構成されてよく、ヘッダ情報は、決定されたコーディングモードまたはブロックの平坦度のうちの少なくとも1つを示す。ビデオエンコーダ20は、複数のサブストリームのうちの第2のサブストリームにおいてビデオデータのブロックのサンプルのルミナンス色成分を符号化し、複数のサブストリームのうちの第3のサブストリームにおいてビデオデータのブロックのサンプルの第1のクロミナンス成分を符号化し、複数のサブストリームのうちの第4のサブストリームにおいてビデオデータのブロックのサンプルの第2のクロミナンス成分を符号化するようにさらに構成され得る。
本開示の別の例では、ビデオエンコーダ20は、決定されたコーディングモードに基づいて第1のサブストリームにおいてコーディングモード情報を符号化するようにさらに構成されてよく、コーディングモード情報は、コーディングモードに関するテーブル、少なくとも1つのブロック予測ベクトル、または少なくとも1つのインデックスのうちの少なくとも1つを備える。
本開示の別の例では、ビデオエンコーダ20は、第1のサブストリーム、第2のサブストリーム、第3のサブストリーム、および第4のサブストリームの間で、ルミナンス色成分に関連するエントロピーコーディンググループを分散するようにさらに構成され得る。本開示の別の例では、ビデオエンコーダ20は、第1のサブストリーム、第2のサブストリーム、第3のサブストリーム、および第4のサブストリームの間で、第1のクロミナンス成分または第2のクロミナンス成分のうちの1つに関連するエントロピーコーディンググループを分散するようにさらに構成され得る。
本開示の別の例では、ビデオエンコーダ20は、ビデオデコーダのデマルチプレクサモデルに基づいて、それぞれの平衡FIFOバッファのアンダーフローを防止するために、それぞれの平衡FIFOバッファをパディングするようにさらに構成され得る。本開示の別の例では、ビデオエンコーダ20は、レートバッファのアンダーフローを防止するために、ビデオデータの複数の符号化サブストリームのうちの1つまたは複数をパディングするようにさらに構成され得る。
本開示の態様は、図2Aのビデオエンコーダ20などのエンコーダの観点から説明してきたことに留意されたい。ただし、たとえば図2Bのビデオデコーダ30によって、生成されたビットストリームを復号するために、上記で説明した動作と逆の動作が適用され得ることを当業者は諒解されよう。
本明細書で開示する情報および信号は、様々な異なる技術および技法のいずれかを使用して表され得る。たとえば、上記の説明全体にわたって言及されることがあるデータ、命令、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場もしくは磁性粒子、光場もしくは光学粒子、またはそれらの任意の組合せによって表されてよい。
本明細書で開示する実施形態に関して説明した様々な例示的な論理ブロック、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、またはその両方の組合せとして実装され得る。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、およびステップは、概して、それらの機能の観点から上記で説明された。そのような機能がハードウェアとして実装されるのか、それともソフトウェアとして実装されるのかは、特定の適用例および全体的なシステムに課される設計制約に依存する。当業者は説明した機能を特定の適用例ごとに様々な方法で実装し得るが、そのような実装決定は、本開示の範囲からの逸脱を引き起こすものと解釈されるべきでない。
本明細書で説明した技法は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。そのような技法は、汎用コンピュータ、ワイヤレス通信デバイスハンドセット、またはワイヤレス通信デバイスハンドセット、自動車用、アプライアンス、ウェアラブルおよび/もしくは他のデバイスにおける適用例を含む複数の用途を有する集積回路デバイスなどの、様々なデバイスのいずれかにおいて実装され得る。デバイスまたは構成要素として説明した任意の特徴は、集積論理デバイスの中で一緒に実装されてよく、または個別であるが相互運用可能な論理デバイスとして別々に実装されてもよい。ソフトウェアで実装される場合、技法は、実行されたとき、上記で説明した方法のうちの1つまたは複数を実行する命令を含むプログラムコードを備えるコンピュータ可読データ記憶媒体によって、少なくとも部分的に実現され得る。コンピュータ可読データ記憶媒体は、パッケージング材料を含むことがあるコンピュータプログラム製品の一部を形成し得る。コンピュータ可読媒体は、ランダムアクセスメモリ(RAM)、同期型ダイナミックランダムアクセスメモリ(SDRAM)、読取り専用メモリ(ROM)、不揮発性ランダムアクセスメモリ(NVRAM)、電気消去可能プログラマブル読取り専用メモリ(EEPROM)、FLASHメモリ、磁気または光データ記憶媒体などの、メモリまたはデータ記憶媒体を備え得る。技法は、追加または代替として、伝搬される信号または波などの、命令またはデータ構造の形態でプログラムコードを搬送または通信し、コンピュータによってアクセスされてよく、読み取られてよく、かつ/または実行されてよいコンピュータ可読通信媒体によって、少なくとも部分的に実現され得る。
プログラムコードはプロセッサによって実行されてよく、プロセッサは、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の同等の集積論理回路もしくは個別論理回路などの、1つまたは複数のプロセッサを含み得る。そのようなプロセッサは、本開示で説明した技法のうちのいずれかを実行するように構成され得る。汎用プロセッサはマイクロプロセッサであってよいが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または状態機械であってよい。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DSPとマイクロプロセッサとの組合せ、複数のマイクロプロセッサ、DSPコアと連携した1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装されてよい。したがって、本明細書で使用する「プロセッサ」という用語は、上記の構造、上記の構造の任意の組合せ、または本明細書で説明した技法の実装に好適な任意の他の構造もしくは装置のいずれかを指し得る。加えて、いくつかの態様では、本明細書で説明した機能は、符号化および復号のために構成された専用のソフトウェアもしくはハードウェア内で提供され得るか、または複合ビデオエンコーダ/デコーダ(コーデック)に組み込まれ得る。また、技法は、1つまたは複数の回路または論理要素で完全に実装されてもよい。
本開示の技法は、ワイヤレスハンドセット、IC、またはICのセット(たとえば、チップセット)を含む、多種多様なデバイスまたは装置において実装されてよい。様々な構成要素またはユニットは、開示する技法を実行するように構成されたデバイスの機能的態様を強調するために本開示で説明されるが、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上記で説明したように、様々なユニットは、コーデックハードウェアユニットの中で組み合わせられてよく、または適切なソフトウェアおよび/もしくはファームウェアとともに、上記で説明したような1つもしくは複数のプロセッサを含む、相互動作可能なハードウェアユニットの集合によって提供されてよい。
上記のことは様々な異なる実施形態に関して説明されたが、1つの実施形態からの特徴または要素が、本開示の教示から逸脱することなく他の実施形態と組み合わせられてよい。ただし、それぞれの実施形態の間での特徴の組合せは、必ずしもそれらに限定されるとは限らない。本開示の様々な実施形態が説明された。これらおよび他の実施形態は、以下の特許請求の範囲内に入る。
本明細書で使用する「コンテンツ」という用語の事例は、「ビデオ」または「画像」という用語を指すことがあり、その逆も同様である。これは、「コンテンツ」または「ビデオ」という用語が、形容詞として使用されるか、名詞として使用されるか、それとも他の品詞として使用されるかにかかわらずあてはまる。たとえば、「コンテンツコーダ」への言及は「ビデオコーダ」または「画像コーダ」への言及を含むことがあり、「ビデオコーダ」または「画像コーダ」への言及は「コンテンツコーダ」への言及を含むことがある。同様に、「コンテンツ」への言及も「ビデオ」または「画像」への言及を含み、「ビデオ」または「画像」への言及は「コンテンツ」への言及を含むことがある。
本明細書で使用する「コンテンツ」は、任意のタイプのコンテンツを指す。たとえば、「コンテンツ」は、ビデオコンテンツ、スクリーンコンテンツ、画像コンテンツ、任意のグラフィカルコンテンツ、または任意の表示可能コンテンツを指し得る。別の例として、「コンテンツ」は、ビデオコンテンツ、スクリーンコンテンツ、画像コンテンツ、任意のグラフィカルコンテンツ、または任意の表示可能コンテンツに対応するピクセルデータを指し得る。たとえば、画像は、複数のピクセルを含み、各ピクセルは、色空間に応じて1つまたは複数の成分を有する。したがって、「ピクセルデータ」への言及が任意のコンテンツのピクセルデータへの言及を含み得ることが理解される。
本明細書で使用する「ピクセルデータ」は、1つまたは複数のピクセルを指し得る。1つまたは複数のピクセルは、1つまたは複数の成分値を含み得る。たとえば、RGB色空間におけるピクセルは、3つの色成分、すなわち、赤色成分値、緑色成分値、および青色成分値を含み得る。いくつかの例では、「サンプル」は、「ピクセル」を指し得る。他の例では、「サンプル」は、ピクセルの成分を指し得る。たとえば、RGB色空間におけるピクセルは、3つのサンプル、すなわち、赤サンプル、緑サンプル、および青サンプルを含み得る。赤サンプルは赤色成分値であってよく、緑サンプルは緑色成分値であってよく、青サンプルはピクセルの青色成分値であってよい。したがって、サンプルに対する動作を実行することへの言及は、ピクセルの成分(たとえば、色成分)に対する動作を実行することを指し得ることが理解される。
本明細書で使用する「ビデオ」という用語は、順次提示され得る複数の画像を指し得る。本明細書で使用する「画像」という用語は、単一の画像(たとえば、ピクチャ)、1つまたは複数の画像、ビデオに対応する複数の画像のうちの1つまたは複数の画像、ビデオに対応しない複数の画像のうちの1つまたは複数の画像、ビデオに対応する複数の画像(たとえば、ビデオに対応する画像のすべてまたはビデオに対応する画像のすべて未満)、単一の画像の下位部分(たとえば、サブブロック)、単一の画像の複数の下位部分(たとえば、サブブロック)、複数の画像に対応する複数の下位部分(たとえば、サブブロック)、画像データ、グラフィカルデータなどを指し得る。いくつかの例では、「ピクチャ」という用語は、「画像」と互換的であり得る。
本明細書で説明する「符号化する」および「圧縮する」という用語は、互換的に使用され得る。同様に、「復号する」および「圧縮解除する」という用語は、互換的に使用され得る。
本明細書で使用する「リンク」または「ディスプレイリンク」という用語は、有線リンクまたはワイヤレスリンクを指し得る。いくつかの例では、「リンク」および「ディスプレイリンク」という用語は互換的であり得る。他の例では、「リンク」および「ディスプレイリンク」という用語は互換的ではないことがある。いくつかの例では、ディスプレイリンクは、コンテンツが(ディスプレイリンクプロトコルと呼ばれることもある)ディスプレイプロトコルに準拠しなければならないリンクを指し得る。ディスプレイプロトコルのいくつかの例には、HDMI(登録商標)プロトコル、DisplayPortプロトコル、MIPI DSIプロトコル、または別の通信プロトコルがある。
本開示によれば、「または」という用語は、文脈が別段規定しない限り、「および/または」として解釈され得る。加えて、「1つまたは複数の」または「少なくとも1つの」などの語句が、本明細書で開示するいくつかの特徴に対して使用されていて、他の特徴に対しては使用されていないことがあるが、そのような言葉が使用されなかった特徴は、文脈が別段規定しない限り、そのような示唆される意味を有するものと解釈され得る。
様々な例が説明された。これらおよび他の例は、以下の特許請求の範囲内に入る。
10 ビデオコーディングシステム
10' ビデオコーディングシステム
11 デバイス
12 ソースデバイス
13 プロセッサ/コントローラデバイス
14 宛先デバイス
16 リンク
18 ビデオソース
20 ビデオエンコーダ
22 出力インターフェース
28 入力インターフェース
30 ビデオデコーダ
31 記憶デバイス
32 ディスプレイデバイス
105 色空間変換器
110 バッファ
115 平坦度検出器
120 レートコントローラ
125 予測器、量子化器、および再構成器構成要素
130 ラインバッファ
135 インデックス付き色履歴
140 エントロピーエンコーダ
145 サブストリームマルチプレクサ
150 レートバッファ
155 レートバッファ
160 サブストリームデマルチプレクサ
165 エントロピーデコーダ
165A エントロピーデコーダ
165B エントロピーデコーダ
165C エントロピーデコーダ
170 レートコントローラ
175 予測器、量子化器、および再構成器構成要素
180 インデックス付き色履歴
185 ラインバッファ
190 色空間変換器
200 VLCおよびファネルシフタ
200A VLCおよびファネルシフタ
200B VLCおよびファネルシフタ
200C VLCおよびファネルシフタ
202 エンコーダ平衡FIFO、平衡FIFO
202A エンコーダ平衡FIFO、Yエンコーダ平衡FIFO
202B エンコーダ平衡FIFO
202C エンコーダ平衡FIFO
204 マルチプレクサ
206 デマルチプレクサモデル
207 デマルチプレクサモデル
210 デマルチプレクサ
212 デコーダファネルシフタ、ファネルシフタ
212A デコーダファネルシフタ
212B デコーダファネルシフタ
212C デコーダファネルシフタ
300 グラフ、回路、ゼロパディング検出およびフラッシュ回路
302 平衡FIFOフルネス状態メモリ
302A 平衡FIFOフルネス状態メモリ
302B 平衡FIFOフルネス状態メモリ
302C 平衡FIFOフルネス状態メモリ
302D 平衡FIFOフルネス状態メモリ
304 muxワード要求時間FIFO
304A muxワード要求時間FIFO
304B muxワード要求時間FIFO
304C muxワード要求時間FIFO
304D muxワード要求時間FIFO

Claims (40)

  1. ビデオデータを符号化するための方法であって、
    1つまたは複数のコーディングモードの中から、ビデオデータのブロックを符号化するためのコーディングモードを決定するステップであって、前記コーディングモードは、最大シンタックス要素サイズに基づいて決定される、ステップと、
    ビデオデータの複数の符号化サブストリームを作成するために、前記決定されたコーディングモードに従って複数のサブストリームにおいてビデオデータの前記ブロックを符号化するステップと、
    ビデオデータの前記複数の符号化サブストリームをそれぞれの平衡先入れ先出し(FIFO)バッファに記憶するステップと、
    前記複数の符号化サブストリームを、ビデオデコーダに送信するためにビットストリームにおいて多重化するステップと
    を含む方法。
  2. 前記複数のコーディングモードのうちのコーディングモードの第1のセット内の各コーディングモードが、コーディングモードの前記第1のセット内の各コーディングモードが前記複数のサブストリームのうちの1つのための前記最大シンタックス要素サイズよりも大きいシンタックス要素サイズを生成するとの判断に基づいて、ビデオデータの前記ブロックを符号化するために使用可能ではないと判断するステップと、
    前記複数のコーディングモードのうちのコーディングモードの第2のセット内の各コーディングモードが、コーディングモードの前記第2のセット内の各コーディングモードが前記複数のサブストリームのすべてのための前記最大シンタックス要素サイズ以下のシンタックス要素サイズを生成するとの判断に基づいて、ビデオデータの前記ブロックを符号化するために使用可能であると判断するステップと、
    コーディングモードの前記第2のセットの中から、ビデオデータの前記ブロックを符号化するための前記コーディングモードを決定するステップと
    をさらに含む、請求項1に記載の方法。
  3. 前記最大シンタックス要素サイズを事前構成するステップ
    をさらに含む、請求項1に記載の方法。
  4. 一定のビットレートで前記ビデオデコーダに前記複数の符号化サブストリームをシグナリングするステップ
    をさらに含む、請求項1に記載の方法。
  5. ビデオデータの複数の符号化サブストリームを作成するために、前記決定されたコーディングモードに従って複数のサブストリームにおいてビデオデータの前記ブロックを符号化するステップは、
    前記決定されたコーディングモードに基づいて前記複数のサブストリームのうちの第1のサブストリームにおいてヘッダ情報を符号化するステップであって、前記ヘッダ情報は、前記決定されたコーディングモードまたは前記ブロックの平坦度のうちの少なくとも1つを示す、ステップと、
    前記複数のサブストリームのうちの第2のサブストリームにおいてビデオデータの前記ブロックのサンプルのルミナンス色成分を符号化するステップと、
    前記複数のサブストリームのうちの第3のサブストリームにおいてビデオデータの前記ブロックの前記サンプルの第1のクロミナンス成分を符号化するステップと、
    前記複数のサブストリームのうちの第4のサブストリームにおいてビデオデータの前記ブロックの前記サンプルの第2のクロミナンス成分を符号化するステップと
    を含む、請求項1に記載の方法。
  6. BPモードに関して、前記決定されたコーディングモードに基づいて前記第1のサブストリームにおいてコーディングモード情報を符号化するステップであって、前記コーディングモード情報は、前記コーディングモードに関するテーブル、少なくとも1つのブロック予測ベクトル、または少なくとも1つのインデックスのうちの少なくとも1つを備える、ステップ
    をさらに含む、請求項5に記載の方法。
  7. 前記第1のサブストリーム、前記第2のサブストリーム、前記第3のサブストリーム、および前記第4のサブストリームの間で、前記ルミナンス色成分に関連するエントロピーコーディンググループを分散するステップ
    をさらに含む、請求項5に記載の方法。
  8. 前記第1のサブストリーム、前記第2のサブストリーム、前記第3のサブストリーム、および前記第4のサブストリームの間で、前記第1のクロミナンス成分または前記第2のクロミナンス成分のうちの1つに関連するエントロピーコーディンググループを分散するステップ
    をさらに含む、請求項5に記載の方法。
  9. 前記ビデオデコーダのデマルチプレクサモデルに基づいて、それぞれの平衡FIFOバッファのアンダーフローを防止するために、前記それぞれの平衡FIFOバッファをパディングするステップ
    をさらに含む、請求項1に記載の方法。
  10. レートバッファのアンダーフローを防止するために、ビデオデータの前記複数の符号化サブストリームのうちの1つまたは複数をパディングするステップ
    をさらに含む、請求項1に記載の方法。
  11. ビデオデータを符号化するように構成された装置であって、
    ビデオデータのブロックを記憶するように構成されたメモリと、
    前記メモリと通信する1つまたは複数のプロセッサと
    を備え、前記1つまたは複数のプロセッサは、
    1つまたは複数のコーディングモードの中から、ビデオデータの前記ブロックを符号化するためのコーディングモードを決定することであって、前記コーディングモードは、最大シンタックス要素サイズに基づいて決定される、決定することと、
    ビデオデータの複数の符号化サブストリームを作成するために、前記決定されたコーディングモードに従って複数のサブストリームにおいてビデオデータの前記ブロックを符号化することと、
    ビデオデータの前記複数の符号化サブストリームをそれぞれの平衡先入れ先出し(FIFO)バッファに記憶することと、
    前記複数の符号化サブストリームを、ビデオデコーダに送信するためにビットストリームにおいて多重化することと
    を行うように構成される、装置。
  12. 前記1つまたは複数のプロセッサは、
    前記複数のコーディングモードのうちのコーディングモードの第1のセット内の各コーディングモードが、コーディングモードの前記第1のセット内の各コーディングモードが前記複数のサブストリームのうちの1つのための前記最大シンタックス要素サイズよりも大きいシンタックス要素サイズを生成するとの判断に基づいて、ビデオデータの前記ブロックを符号化するために使用可能ではないと判断することと、
    前記複数のコーディングモードのうちのコーディングモードの第2のセット内の各コーディングモードが、コーディングモードの前記第2のセット内の各コーディングモードが前記複数のサブストリームのすべてのための前記最大シンタックス要素サイズ以下のシンタックス要素サイズを生成するとの判断に基づいて、ビデオデータの前記ブロックを符号化するために使用可能であると判断することと、
    コーディングモードの前記第2のセットの中から、ビデオデータの前記ブロックを符号化するための前記コーディングモードを決定することと
    を行うようにさらに構成される、請求項11に記載の装置。
  13. 前記1つまたは複数のプロセッサは、前記最大シンタックス要素サイズにより事前構成される、請求項11に記載の装置。
  14. 前記1つまたは複数のプロセッサは、
    一定のビットレートで前記ビデオデコーダに前記複数の符号化サブストリームをシグナリングする
    ようにさらに構成される、請求項11に記載の装置。
  15. ビデオデータの複数の符号化サブストリームを作成するために、前記決定されたコーディングモードに従って複数のサブストリームにおいてビデオデータの前記ブロックを符号化するために、前記1つまたは複数のプロセッサは、
    前記決定されたコーディングモードに基づいて前記複数のサブストリームのうちの第1のサブストリームにおいてヘッダ情報を符号化することであって、前記ヘッダ情報は、前記決定されたコーディングモードまたは前記ブロックの平坦度のうちの少なくとも1つを示す、符号化することと、
    前記複数のサブストリームのうちの第2のサブストリームにおいてビデオデータの前記ブロックのサンプルのルミナンス色成分を符号化することと、
    前記複数のサブストリームのうちの第3のサブストリームにおいてビデオデータの前記ブロックの前記サンプルの第1のクロミナンス成分を符号化することと、
    前記複数のサブストリームのうちの第4のサブストリームにおいてビデオデータの前記ブロックの前記サンプルの第2のクロミナンス成分を符号化することと
    を行うようにさらに構成される、請求項11に記載の装置。
  16. 前記1つまたは複数のプロセッサは、
    BPモードに関して、前記決定されたコーディングモードに基づいて前記第1のサブストリームにおいてコーディングモード情報を符号化することであって、前記コーディングモード情報は、前記コーディングモードに関するテーブル、少なくとも1つのブロック予測ベクトル、または少なくとも1つのインデックスのうちの少なくとも1つを備える、符号化すること
    を行うようにさらに構成される、請求項15に記載の装置。
  17. 前記1つまたは複数のプロセッサは、
    前記第1のサブストリーム、前記第2のサブストリーム、前記第3のサブストリーム、および前記第4のサブストリームの間で、前記ルミナンス色成分に関連するエントロピーコーディンググループを分散する
    ようにさらに構成される、請求項15に記載の装置。
  18. 前記1つまたは複数のプロセッサは、
    前記第1のサブストリーム、前記第2のサブストリーム、前記第3のサブストリーム、および前記第4のサブストリームの間で、前記第1のクロミナンス成分または前記第2のクロミナンス成分のうちの1つに関連するエントロピーコーディンググループを分散する
    ようにさらに構成される、請求項15に記載の装置。
  19. 前記1つまたは複数のプロセッサは、
    前記ビデオデコーダのデマルチプレクサモデルに基づいて、それぞれの平衡FIFOバッファのアンダーフローを防止するために、前記それぞれの平衡FIFOバッファをパディングする
    ようにさらに構成される、請求項11に記載の装置。
  20. 前記1つまたは複数のプロセッサは、
    レートバッファのアンダーフローを防止するために、ビデオデータの前記複数の符号化サブストリームのうちの1つまたは複数をパディングする
    ようにさらに構成される、請求項11に記載の装置。
  21. ビデオデータを符号化するように構成された装置であって、
    1つまたは複数のコーディングモードの中から、ビデオデータのブロックを符号化するためのコーディングモードを決定するための手段であって、前記コーディングモードは、最大シンタックス要素サイズに基づいて決定される、手段と、
    ビデオデータの複数の符号化サブストリームを作成するために、前記決定されたコーディングモードに従って複数のサブストリームにおいてビデオデータの前記ブロックを符号化するための手段と、
    ビデオデータの前記複数の符号化サブストリームをそれぞれの平衡先入れ先出し(FIFO)バッファに記憶するための手段と、
    前記複数の符号化サブストリームを、ビデオデコーダに送信するためにビットストリームにおいて多重化するための手段と
    を含む装置。
  22. 前記複数のコーディングモードのうちのコーディングモードの第1のセット内の各コーディングモードが、コーディングモードの前記第1のセット内の各コーディングモードが前記複数のサブストリームのうちの1つのための前記最大シンタックス要素サイズよりも大きいシンタックス要素サイズを生成するとの判断に基づいて、ビデオデータの前記ブロックを符号化するために使用可能ではないと判断するための手段と、
    前記複数のコーディングモードのうちのコーディングモードの第2のセット内の各コーディングモードが、コーディングモードの前記第2のセット内の各コーディングモードが前記複数のサブストリームのすべてのための前記最大シンタックス要素サイズ以下のシンタックス要素サイズを生成するとの判断に基づいて、ビデオデータの前記ブロックを符号化するために使用可能であると判断するための手段と、
    コーディングモードの前記第2のセットの中から、ビデオデータの前記ブロックを符号化するための前記コーディングモードを決定するための手段と
    をさらに含む、請求項21に記載の装置。
  23. 前記最大シンタックス要素サイズにより事前構成される、請求項21に記載の装置。
  24. 一定のビットレートで前記ビデオデコーダに前記複数の符号化サブストリームをシグナリングするための手段
    をさらに含む、請求項21に記載の装置。
  25. ビデオデータの複数の符号化サブストリームを作成するために、前記決定されたコーディングモードに従って複数のサブストリームにおいてビデオデータの前記ブロックを符号化するための前記手段は、
    前記決定されたコーディングモードに基づいて前記複数のサブストリームのうちの第1のサブストリームにおいてヘッダ情報を符号化するための手段であって、前記ヘッダ情報は、前記決定されたコーディングモードまたは前記ブロックの平坦度のうちの少なくとも1つを示す、手段と、
    前記複数のサブストリームのうちの第2のサブストリームにおいてビデオデータの前記ブロックのサンプルのルミナンス色成分を符号化するための手段と、
    前記複数のサブストリームのうちの第3のサブストリームにおいてビデオデータの前記ブロックの前記サンプルの第1のクロミナンス成分を符号化するための手段と、
    前記複数のサブストリームのうちの第4のサブストリームにおいてビデオデータの前記ブロックの前記サンプルの第2のクロミナンス成分を符号化するための手段と
    を含む、請求項21に記載の装置。
  26. BPモードに関して、前記決定されたコーディングモードに基づいて前記第1のサブストリームにおいてコーディングモード情報を符号化するための手段であって、前記コーディングモード情報は、前記コーディングモードに関するテーブル、少なくとも1つのブロック予測ベクトル、または少なくとも1つのインデックスのうちの少なくとも1つを備える、手段
    をさらに含む、請求項25に記載の装置。
  27. 前記第1のサブストリーム、前記第2のサブストリーム、前記第3のサブストリーム、および前記第4のサブストリームの間で、前記ルミナンス色成分に関連するエントロピーコーディンググループを分散するための手段
    をさらに含む、請求項25に記載の装置。
  28. 前記第1のサブストリーム、前記第2のサブストリーム、前記第3のサブストリーム、および前記第4のサブストリームの間で、前記第1のクロミナンス成分または前記第2のクロミナンス成分のうちの1つに関連するエントロピーコーディンググループを分散するための手段
    をさらに含む、請求項25に記載の装置。
  29. 前記ビデオデコーダのデマルチプレクサモデルに基づいて、それぞれの平衡FIFOバッファのアンダーフローを防止するために、前記それぞれの平衡FIFOバッファをパディングするための手段
    をさらに含む、請求項21に記載の装置。
  30. レートバッファのアンダーフローを防止するために、ビデオデータの前記複数の符号化サブストリームのうちの1つまたは複数をパディングするための手段
    をさらに含む、請求項21に記載の装置。
  31. 実行されたとき、ビデオデータを符号化するように構成された1つまたは複数のプロセッサに、
    1つまたは複数のコーディングモードの中から、ビデオデータの前記ブロックを符号化するためのコーディングモードを決定することであって、前記コーディングモードは、最大シンタックス要素サイズに基づいて決定される、決定することと、
    ビデオデータの複数の符号化サブストリームを作成するために、前記決定されたコーディングモードに従って複数のサブストリームにおいてビデオデータの前記ブロックを符号化することと、
    ビデオデータの前記複数の符号化サブストリームをそれぞれの平衡先入れ先出し(FIFO)バッファに記憶することと、
    前記複数の符号化サブストリームを、ビデオデコーダに送信するためにビットストリームにおいて多重化することと
    を行わせる命令を記憶するコンピュータ可読記憶媒体。
  32. 前記命令は、前記1つまたは複数のプロセッサに、
    前記複数のコーディングモードのうちのコーディングモードの第1のセット内の各コーディングモードが、コーディングモードの前記第1のセット内の各コーディングモードが前記複数のサブストリームのうちの1つのための前記最大シンタックス要素サイズよりも大きいシンタックス要素サイズを生成するとの判断に基づいて、ビデオデータの前記ブロックを符号化するために使用可能ではないと判断することと、
    前記複数のコーディングモードのうちのコーディングモードの第2のセット内の各コーディングモードが、コーディングモードの前記第2のセット内の各コーディングモードが前記複数のサブストリームのすべてのための前記最大シンタックス要素サイズ以下のシンタックス要素サイズを生成するとの判断に基づいて、ビデオデータの前記ブロックを符号化するために使用可能であると判断することと、
    コーディングモードの前記第2のセットの中から、ビデオデータの前記ブロックを符号化するための前記コーディングモードを決定することと
    をさらに行わせる、請求項31に記載のコンピュータ可読記憶媒体。
  33. 前記1つまたは複数のプロセッサは、前記最大シンタックス要素サイズにより事前構成される、請求項31に記載のコンピュータ可読記憶媒体。
  34. 前記命令は、前記1つまたは複数のプロセッサに、
    一定のビットレートで前記ビデオデコーダに前記複数の符号化サブストリームをシグナリングすること
    をさらに行わせる、請求項31に記載のコンピュータ可読記憶媒体。
  35. ビデオデータの複数の符号化サブストリームを作成するために、前記決定されたコーディングモードに従って複数のサブストリームにおいてビデオデータの前記ブロックを符号化するために、前記命令は、前記1つまたは複数のプロセッサに、
    前記決定されたコーディングモードに基づいて前記複数のサブストリームのうちの第1のサブストリームにおいてヘッダ情報を符号化することであって、前記ヘッダ情報は、前記決定されたコーディングモードまたは前記ブロックの平坦度のうちの少なくとも1つを示す、符号化することと、
    前記複数のサブストリームのうちの第2のサブストリームにおいてビデオデータの前記ブロックのサンプルのルミナンス色成分を符号化することと、
    前記複数のサブストリームのうちの第3のサブストリームにおいてビデオデータの前記ブロックの前記サンプルの第1のクロミナンス成分を符号化することと、
    前記複数のサブストリームのうちの第4のサブストリームにおいてビデオデータの前記ブロックの前記サンプルの第2のクロミナンス成分を符号化することと
    をさらに行わせる、請求項31に記載のコンピュータ可読記憶媒体。
  36. 前記命令は、前記1つまたは複数のプロセッサに、
    BPモードに関して、前記決定されたコーディングモードに基づいて前記第1のサブストリームにおいてコーディングモード情報を符号化することであって、前記コーディングモード情報は、前記コーディングモードに関するテーブル、少なくとも1つのブロック予測ベクトル、または少なくとも1つのインデックスのうちの少なくとも1つを備える、符号化すること
    をさらに行わせる、請求項35に記載のコンピュータ可読記憶媒体。
  37. 前記命令は、前記1つまたは複数のプロセッサに、
    前記第1のサブストリーム、前記第2のサブストリーム、前記第3のサブストリーム、および前記第4のサブストリームの間で、前記ルミナンス色成分に関連するエントロピーコーディンググループを分散すること
    をさらに行わせる、請求項35に記載のコンピュータ可読記憶媒体。
  38. 前記命令は、前記1つまたは複数のプロセッサに、
    前記第1のサブストリーム、前記第2のサブストリーム、前記第3のサブストリーム、および前記第4のサブストリームの間で、前記第1のクロミナンス成分または前記第2のクロミナンス成分のうちの1つに関連するエントロピーコーディンググループを分散すること
    をさらに行わせる、請求項35に記載のコンピュータ可読記憶媒体。
  39. 前記命令は、前記1つまたは複数のプロセッサに、
    前記ビデオデコーダのデマルチプレクサモデルに基づいて、それぞれの平衡FIFOバッファのアンダーフローを防止するために、前記それぞれの平衡FIFOバッファをパディングすること
    をさらに行わせる、請求項31に記載のコンピュータ可読記憶媒体。
  40. 前記命令は、前記1つまたは複数のプロセッサに、
    レートバッファのアンダーフローを防止するために、ビデオデータの前記複数の符号化サブストリームのうちの1つまたは複数をパディングすること
    をさらに行わせる、請求項31に記載のコンピュータ可読記憶媒体。
JP2018563630A 2016-06-09 2017-06-09 ディスプレイストリーム圧縮のためのサブストリーム多重化 Active JP6921873B2 (ja)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
US201662347964P 2016-06-09 2016-06-09
US62/347,964 2016-06-09
US201662359586P 2016-07-07 2016-07-07
US62/359,586 2016-07-07
US201662416016P 2016-11-01 2016-11-01
US62/416,016 2016-11-01
US15/617,844 2017-06-08
US15/617,844 US10855989B2 (en) 2016-06-09 2017-06-08 Substream multiplexing for display stream compression
PCT/US2017/036772 WO2017214515A1 (en) 2016-06-09 2017-06-09 Substream multiplexing for display stream compression

Publications (3)

Publication Number Publication Date
JP2019522413A true JP2019522413A (ja) 2019-08-08
JP2019522413A5 JP2019522413A5 (ja) 2021-02-25
JP6921873B2 JP6921873B2 (ja) 2021-08-18

Family

ID=60573318

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018563630A Active JP6921873B2 (ja) 2016-06-09 2017-06-09 ディスプレイストリーム圧縮のためのサブストリーム多重化

Country Status (9)

Country Link
US (1) US10855989B2 (ja)
EP (1) EP3469795B1 (ja)
JP (1) JP6921873B2 (ja)
KR (1) KR102342660B1 (ja)
CN (1) CN109196866B (ja)
BR (1) BR112018074811A2 (ja)
CA (1) CA3022147C (ja)
TW (1) TWI732884B (ja)
WO (1) WO2017214515A1 (ja)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10283091B2 (en) * 2014-10-13 2019-05-07 Microsoft Technology Licensing, Llc Buffer optimization
US10225561B2 (en) * 2015-10-08 2019-03-05 Mediatek Inc. Method and apparatus for syntax signaling in image and video compression
JP2017183910A (ja) * 2016-03-29 2017-10-05 富士通株式会社 画像符号化装置及び画像符号化方法
US10750175B2 (en) * 2017-05-04 2020-08-18 Sony Corporation Quantization partitioning for enhanced image compression
US10743032B2 (en) 2017-05-24 2020-08-11 Qualcomm Incorporated Substream multiplexing for display stream compression
FR3068556A1 (fr) * 2017-06-29 2019-01-04 B<>Com Procede de decodage d'une image, procede de codage, dispositifs, equipement terminal et programmes d'ordinateurs associes
US10904532B2 (en) * 2019-05-20 2021-01-26 Samsung Display Co., Ltd. Differential prefix coding for high throughput entropy coder in display compression
TWI741919B (zh) * 2020-01-15 2021-10-01 瑞鼎科技股份有限公司 串流解壓縮電路
CN112926456B (zh) * 2021-02-26 2022-11-15 格学教育科技(唐山)有限公司 一种基于状态机的识别文字逻辑重组方法
WO2023122244A1 (en) * 2021-12-23 2023-06-29 Op Solutions, Llc Intelligent multi-stream video coding for video surveillance
CN115083530B (zh) * 2022-08-22 2022-11-04 广州明领基因科技有限公司 基因测序数据压缩方法、装置、终端设备和存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140098857A1 (en) * 2012-10-03 2014-04-10 Broadcom Corporation Bounded Rate Near-Lossless And Lossless Image Compression
US20150296209A1 (en) * 2014-04-15 2015-10-15 Qualcomm Incorporated System and method for flatness detection for display stream compression (dsc)
US20150304675A1 (en) * 2014-04-21 2015-10-22 Qualcomm Incorporated System and method for coding in block prediction mode for display stream compression (dsc)

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5784494A (en) * 1995-04-18 1998-07-21 Advanced Micro Devices, Inc. Method and apparatus for prestoring dequantization information for DCT VLC decoding
US20050114639A1 (en) * 2001-05-11 2005-05-26 Zimmer Vincent J. Hardened extensible firmware framework to support system management mode operations using 64-bit extended memory mode processors
US20030208537A1 (en) * 2002-05-01 2003-11-06 Lane James K. Real-time data collection and distribution among office productivity software applications
AU2002319283A1 (en) * 2002-07-03 2004-01-23 Telefonaktiebolaget Lm Ericsson (Publ) Load balancing system using mobile agents
US7475257B2 (en) * 2003-09-25 2009-01-06 International Business Machines Corporation System and method for selecting and using a signal processor in a multiprocessor system to operate as a security for encryption/decryption of data
US20050125582A1 (en) * 2003-12-08 2005-06-09 Tu Steven J. Methods and apparatus to dispatch interrupts in multi-processor systems
US20070208956A1 (en) * 2004-11-19 2007-09-06 Motorola, Inc. Energy efficient inter-processor management method and system
US8126046B2 (en) * 2006-06-30 2012-02-28 Intel Corporation Flexible macroblock ordering and arbitrary slice ordering apparatus, system, and method
EP2140350B1 (en) * 2007-03-23 2017-04-05 Qualcomm Incorporated Distributed processing method and computer program product
US20090316788A1 (en) * 2008-06-23 2009-12-24 Thomson Licensing Video coding method with non-compressed mode and device implementing the method
US8074087B2 (en) * 2008-06-24 2011-12-06 Microsoft Corporation Configuring processors and loads for power management
US9749661B2 (en) * 2012-01-18 2017-08-29 Qualcomm Incorporated Sub-streams for wavefront parallel processing in video coding
EP2904796B1 (en) * 2012-10-03 2020-09-02 Avago Technologies International Sales Pte. Limited Bounded rate compression with rate control for slices
US9978156B2 (en) * 2012-10-03 2018-05-22 Avago Technologies General Ip (Singapore) Pte. Ltd. High-throughput image and video compression
US9866853B2 (en) * 2014-04-15 2018-01-09 Qualcomm Incorporated System and method for lagrangian parameter calculation for display stream compression (DSC)
US9848193B2 (en) * 2014-04-15 2017-12-19 Qualcomm Incorporated System and method for selecting quantization parameter (QP) in display stream compression (DSC)

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140098857A1 (en) * 2012-10-03 2014-04-10 Broadcom Corporation Bounded Rate Near-Lossless And Lossless Image Compression
US20150296209A1 (en) * 2014-04-15 2015-10-15 Qualcomm Incorporated System and method for flatness detection for display stream compression (dsc)
US20150304675A1 (en) * 2014-04-21 2015-10-22 Qualcomm Incorporated System and method for coding in block prediction mode for display stream compression (dsc)

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
VESA DISPLAY STREAM COMPRESSION (DSC) STANDARD, vol. Version 1.1, JPN6020010345, August 2014 (2014-08-01), pages 1 - 4, ISSN: 0004531719 *

Also Published As

Publication number Publication date
US10855989B2 (en) 2020-12-01
CA3022147C (en) 2023-11-07
TW201806391A (zh) 2018-02-16
BR112018074811A2 (pt) 2019-03-19
CN109196866A (zh) 2019-01-11
EP3469795B1 (en) 2021-04-21
CN109196866B (zh) 2022-11-25
KR20190016502A (ko) 2019-02-18
JP6921873B2 (ja) 2021-08-18
KR102342660B1 (ko) 2021-12-22
TWI732884B (zh) 2021-07-11
US20170359583A1 (en) 2017-12-14
WO2017214515A1 (en) 2017-12-14
EP3469795A1 (en) 2019-04-17
CA3022147A1 (en) 2017-12-14

Similar Documents

Publication Publication Date Title
KR102342660B1 (ko) 디스플레이 스트림 압축을 위한 서브스트림 멀티플렉싱
CN110603812B (zh) 显示器流压缩的子流多路复用的设备、方法和存储介质
US9866853B2 (en) System and method for lagrangian parameter calculation for display stream compression (DSC)
US10631005B2 (en) System and method for coding in block prediction mode for display stream compression (DSC)
JP2018531556A (ja) 非４：４：４クロマサブサンプリングのディスプレイストリーム圧縮（ｄｓｃ）のためのエントロピーコーディング技法
JP2018531556A6 (ja) 非４：４：４クロマサブサンプリングのディスプレイストリーム圧縮（ｄｓｃ）のためのエントロピーコーディング技法
KR102185027B1 (ko) 디스플레이 스트림 압축을 위한 벡터 기반 엔트로피 코딩을 위한 장치 및 방법
JP2019514290A (ja) ディスプレイストリーム圧縮用の知覚的量子化パラメータ（ｑｐ）重み付けのための装置および方法
KR20160145181A (ko) 디스플레이 스트림 압축 (dsc) 을 위해 패턴 모드에서 코딩하기 위한 시스템 및 방법
US10123045B2 (en) Modification to block size for transform mode in display stream compression

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181211

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200518

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200518

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210108

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20210108

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20210414

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20210415

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210426

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210609

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: 20210628

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20210728

R150 Certificate of patent or registration of utility model

Ref document number: 6921873

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150