JP7375125B2 - ルーマおよびクロマ成分についてibc専用バッファおよびデフォルト値リフレッシュを使用するエンコーダ、デコーダおよび対応する方法 - Google Patents

ルーマおよびクロマ成分についてibc専用バッファおよびデフォルト値リフレッシュを使用するエンコーダ、デコーダおよび対応する方法 Download PDF

Info

Publication number
JP7375125B2
JP7375125B2 JP2022112148A JP2022112148A JP7375125B2 JP 7375125 B2 JP7375125 B2 JP 7375125B2 JP 2022112148 A JP2022112148 A JP 2022112148A JP 2022112148 A JP2022112148 A JP 2022112148A JP 7375125 B2 JP7375125 B2 JP 7375125B2
Authority
JP
Japan
Prior art keywords
block
ibc
ctu
current
video
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2022112148A
Other languages
English (en)
Other versions
JP2022140481A (ja
Inventor
ガオ,ハン
エセンリク,セミフ
ワン,ビアオ
メヘル コトラ,アナンド
チェン,ジェンレェ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of JP2022140481A publication Critical patent/JP2022140481A/ja
Application granted granted Critical
Publication of JP7375125B2 publication Critical patent/JP7375125B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/157Assigned coding mode, i.e. the coding mode being predefined or preselected to be further used for selection of another element or parameter
    • H04N19/159Prediction type, e.g. intra-frame, inter-frame or bidirectional frame prediction
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/593Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving spatial prediction techniques
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17Methods 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/176Methods 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103Selection of coding mode or of prediction mode
    • H04N19/105Selection of the reference unit for prediction within a chosen coding or prediction mode, e.g. adaptive choice of position and number of pixels used for prediction
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/103Selection of coding mode or of prediction mode
    • H04N19/11Selection of coding mode or of prediction mode among a plurality of spatial predictive coding modes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/12Selection from among a plurality of transforms or standards, e.g. selection between discrete cosine transform [DCT] and sub-band transform or selection between H.263 and H.264
    • H04N19/122Selection of transform size, e.g. 8x8 or 2x4x8 DCT; Selection of sub-band transforms of varying structure or type
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/132Sampling, masking or truncation of coding units, e.g. adaptive resampling, frame skipping, frame interpolation or high-frequency transform coefficient masking
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/136Incoming video signal characteristics or properties
    • H04N19/137Motion inside a coding unit, e.g. average field, frame or block difference
    • H04N19/139Analysis of motion vectors, e.g. their magnitude, direction, variance or reliability
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/186Methods 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 colour or a chrominance component
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42Methods 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/423Methods 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/42Methods 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/43Hardware specially adapted for motion estimation or compensation
    • H04N19/433Hardware specially adapted for motion estimation or compensation characterised by techniques for memory access
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/44Decoders specially adapted therefor, e.g. video decoders which are asymmetric with respect to the encoder
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/503Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal prediction
    • H04N19/51Motion estimation or motion compensation
    • H04N19/513Processing of motion vectors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/90Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
    • H04N19/91Entropy coding, e.g. variable length coding [VLC] or arithmetic coding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/90Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using coding techniques not provided for in groups H04N19/10-H04N19/85, e.g. fractals
    • H04N19/96Tree coding, e.g. quad-tree coding

Description

関連出願への相互参照
本願は、2019年5月16日に米国特許商標庁に出願された米国仮出願第62/849,119号および2019年6月13日に欧州特許庁に出願された国際特許出願第PCT/EP2019/065540号からの優先権を主張するものであり、これらの開示は、ここにその全体において参照により組み込まれる。
技術分野
本願の実施形態は、概して、ピクチャー処理の分野に関し、より詳細には、IBC専用バッファを使用するエンコーダ、デコーダ、および対応する方法に関する。
ビデオ符号化(coding)(ビデオ・エンコードおよびデコード)は、広範囲のデジタル・ビデオ・アプリケーション、たとえば、放送デジタルTV、インターネットおよびモバイルネットワーク上でのビデオ伝送、ビデオチャット、ビデオ会議のようなリアルタイムの会話アプリケーション、DVDおよびブルーレイディスク、ビデオコンテンツ取得および編集システム、ならびにセキュリティ・アプリケーションのカムコーダーにおいて使用される。
比較的短いビデオを描写するために必要とされるビデオ・データの量でさえ相当な量になることがあり、結果として、限られた帯域幅容量を有する通信ネットワークを通じてデータがストリーミングされるか、または他の仕方で通信される場合に困難を生じることがありうる。そこで、ビデオ・データは、一般に、現代の遠隔通信ネットワークを通じて通信される前に圧縮される。メモリ資源が限られていることがありうるため、ビデオのサイズも、ビデオが記憶装置に記憶されるときに問題となる可能性がある。ビデオ圧縮装置は、しばしば、伝送または記憶の前にビデオ・データを符号化するために源においてソフトウェアおよび/またはハードウェアを使用し、それによりデジタルビデオ画像を表わすのに必要とされるデータ量を減少させる。次いで、圧縮されたデータは、宛先において、ビデオ・データをデコードするビデオ圧縮解除装置によって受領される。ネットワーク資源が限られており、より高いビデオ品質の要求が絶えず増大しているため、画質の犠牲がほとんどないしは全くなしに圧縮比を改善する改良された圧縮および圧縮解除技術が望ましい。
本願の実施形態は、独立請求項に従ってエンコードおよびデコードするための装置および方法を提供する。
前記および他の目的は、独立請求項の主題事項によって達成される。さらなる実装形態は、従属請求項、明細書および図面から明らかである。
本開示の第1の実施形態は、デコードされるべき現在の符号化ツリー単位(coding tree unit、CTU)がCTU行の最初のCTUである場合、ブロック内コピー(intra block copy、IBC)参照のための専用バッファを初期化するステップと、現在のCTU内の現在のブロックがIBCモードを使用して予測されるかどうかを決定するステップと、現在のブロックがIBCモードを使用して予測される場合、現在のブロックについてのIBCブロック・ベクトルを取得するステップと、前記専用バッファからの参照サンプルおよび現在のブロックについての前記IBCブロック・ベクトルに基づいて、現在のブロックについての予測されたサンプル値を取得するステップとを含む、デコード装置によって実装される符号化方法を提供する。
専用バッファからの参照サンプルは、デフォルト値に初期化されてもよい。デフォルト値は-1であってもよい。
本実施形態による方法は、すべてのブロック・ベクトル検証ビットストリーム準拠性制約条件を除去する。これは、符号化されたビットストリームの堅牢性を増す。また、専用のIBCバッファが初期化される。したがって、未定義のサンプルが避けられる。結果として、IBCブロック・ベクトル検証(validation)のためのビットストリーム準拠性は要求されない。さらに、最後のCTU行からのサンプルはIBC参照において使用されない。この場合、IBC予測のために追加のラインメモリは必要とされない。
第1の実施形態のある側面によれば、第1の実施形態による方法のいずれかを実行するための処理回路を備えるデコーダが提供される。デコーダは、さらに、IBC参照サンプルを記憶するための専用バッファを含んでいてもよい。
第1実施形態のさらなる側面によれば、命令を有するコンピュータ・プログラム製品であって前記命令は、前記プログラムがコンピュータによって実行されると、前記コンピュータに第1実施形態による方法のいずれかを実行させるものである、コンピュータ・プログラム製品が提供される。
第1の実施形態のさらなる側面によれば、一つまたは複数のプロセッサと、前記一つまたは複数のプロセッサに結合され、前記一つまたは複数のプロセッサによる実行のための命令を記憶する非一時的なコンピュータ読み取り可能な記憶媒体とを有するデコーダが提供され、前記命令は、前記一つまたは複数のプロセッサによって実行されると、第1の実施形態による方法のいずれかを実行するように前記デコーダを構成する。
本開示の第2の実施形態は、エンコードされるべき現在の符号化ツリー単位(CTU)がCTU行の最初のCTUである場合に、ブロック内コピー(IBC)参照のための専用バッファを初期化し、専用バッファからの参照サンプルに基づいて、現在のCTU内の現在のブロックについての予測されたサンプル値を取得し、現在のブロックについての予測されたサンプル値に基づいて、現在のブロックについてのIBCブロック・ベクトルをエンコードすることを含む、エンコード装置によって実装される符号化方法を提供する。
専用バッファからの参照サンプルは、デフォルト値に初期化されてもよい。デフォルト値は-1であってもよい。
本実施形態による方法は、すべてのブロック・ベクトル検証ビットストリーム準拠性制約条件を除去する。これは、符号化されたビットストリームの堅牢性を増す。また、専用のIBCバッファは初期化される。したがって、未定義のサンプルが避けられる。結果として、IBCブロック・ベクトル検証のためのビットストリーム準拠性は要求されない。さらに、最後のCTU行からのサンプルはIBC参照において使用されない。この場合、IBC予測のために追加のラインメモリは必要とされない。
第2の実施形態のある側面によれば、第2の実施形態による方法のいずれかを実行するための処理回路を備えるエンコーダが提供される。エンコーダは、さらに、IBC参照サンプルを記憶するための専用バッファを含んでいてもよい。
第2実施形態のさらなる側面によれば、命令を有するコンピュータ・プログラム製品であって前記命令は、前記プログラムがコンピュータによって実行されると、前記コンピュータに第2実施形態による方法のいずれかを実行させるものである、コンピュータ・プログラム製品が提供される。
第2の実施形態のさらなる側面によれば、一つまたは複数のプロセッサと、前記一つまたは複数のプロセッサに結合され、前記一つまたは複数のプロセッサによる実行のための命令を記憶する非一時的なコンピュータ読み取り可能な記憶媒体とを有するエンコーダが提供され、前記命令は、前記一つまたは複数のプロセッサによって実行されると、第2の実施形態による方法のいずれかを実行するように前記エンコーダを構成する。
本開示の第3の実施形態は、デコード装置によって実装される符号化方法を提供し、この方法は、符号化ツリー単位(CTU)のある領域についてのブロック内コピー(IBC)参照のための専用バッファを、デコードされるべき現在の符号化ブロックが前記CTUの前記領域内の最初の符号化ブロックである場合に、初期化し、現在のCTU内の現在のブロックがIBCモードを使用して予測されるかどうかを決定し、現在のブロックがIBCモードを使用して予測される場合、現在のブロックについてのIBCブロック・ベクトルを取得し、専用バッファからの参照サンプルおよび現在のブロックについてのIBCブロック・ベクトルに基づいて現在のブロックについての予測されたサンプル値を取得することを含む。
専用バッファからの参照サンプルは、デフォルト値に初期化されてもよい。デフォルト値は-1であってもよい。
CTUの領域は、固定サイズの、重ならない領域であってもよい。この領域は、仮想パイプライン処理単位(virtual pipeline processing unit)VPDUであってもよい。この領域のサイズは64×64であってもよい。
IBCブロック・ベクトル検証のためのビットストリーム準拠性は要求されない。最後のCTU行からのサンプルは、IBC参照には使用されない。この場合、IBC予測のために追加のラインメモリは使用されない。さらに、IBC参照メモリ・サイズは、現在のVVC設計におけるものと同じである、すなわち、本実施形態を実装するために追加のメモリは要求されない。現在のVPDU参照については、専用のIBCバッファにアクセスする必要はない。
第3の実施形態のある側面によれば、第3の実施形態による方法のいずれかを実行するための処理回路を備えるデコーダが提供される。デコーダは、さらに、IBC参照サンプルを記憶するための専用バッファを含んでいてもよい。
第3実施形態のさらなる側面によれば、命令を有するコンピュータ・プログラム製品であって前記命令は、前記プログラムがコンピュータによって実行されると、前記コンピュータに第3実施形態による方法のいずれかを実行させるものである、コンピュータ・プログラム製品が提供される。
第3の実施形態のさらなる側面によれば、一つまたは複数のプロセッサと、前記一つまたは複数のプロセッサに結合され、前記一つまたは複数のプロセッサによる実行のための命令を記憶する非一時的なコンピュータ読み取り可能な記憶媒体とを有するデコーダが提供され、前記命令は、前記一つまたは複数のプロセッサによって実行されると、第3の実施形態による方法のいずれかを実行するように前記デコーダを構成する。
本開示の第4の実施形態は、デコード装置によって実装される符号化方法であって、デコードされるべき現在の符号化ツリー単位(CTU)がピクチャーの最初のCTUである場合に、ブロック内コピー(IBC)参照のための専用バッファを初期化するステップと、現在のCTU内の現在のブロックがIBCモードを使用して予測されるかどうかを決定するステップと、現在のブロックがIBCモードを使用して予測される場合に、現在のブロックについてのIBCブロック・ベクトルを取得するステップと、専用バッファからの参照サンプルおよび現在のブロックについてのIBCブロック・ベクトルに基づいて、現在のブロックについての予測されたサンプル値を取得するステップとを含む、方法を提供する。
専用バッファからの参照サンプルは、デフォルト値に初期化されてもよい。デフォルト値は-1であってもよい。
本実施形態による方法は、すべてのブロック・ベクトル検証ビットストリーム準拠性制約条件を除去する。これは、符号化されたビットストリームの堅牢性を増す。また、専用のIBCバッファは初期化される。したがって、未定義のサンプルが避けられる。
第4の実施形態のある側面によれば、第4の実施形態による方法のいずれかを実行するための処理回路を備えるデコーダが提供される。デコーダは、さらに、IBC参照サンプルを記憶するための専用バッファを含んでいてもよい。
第4実施形態のさらなる側面によれば、命令を有するコンピュータ・プログラム製品であって前記命令は、前記プログラムがコンピュータによって実行されると、前記コンピュータに第4実施形態の方法のいずれかを実行させるものである、コンピュータ・プログラム製品が提供される。
第4の実施形態のさらなる側面によれば、一つまたは複数のプロセッサと、前記一つまたは複数のプロセッサに結合され、前記一つまたは複数のプロセッサによる実行のための命令を記憶する非一時的なコンピュータ読み取り可能な記憶媒体とを有するデコーダが提供され、前記命令は、前記一つまたは複数のプロセッサによって実行されると、第4の実施形態による方法のいずれかを実行するように前記デコーダを構成する。
本開示の第5の実施形態は、デコード装置によって実装される符号化方法であって、現在のブロックが現在の符号化ツリー単位(CTU)内の最初の符号化ブロックである場合、ブロック内コピー(IBC)参照のための専用バッファを初期化するステップであって、前記CTUはCTU行の最初のCTUである、ステップと、現在のCTU内の現在のブロックがIBCモードを用いて予測されるかどうかを決定するステップと、現在のブロックがIBCモードを用いて予測される場合に、現在のブロックについてのIBCブロック・ベクトルを取得するステップと、専用バッファからの参照サンプルおよび現在のブロックについてのIBCブロック・ベクトルに基づいて、現在のブロックについての予測されたサンプル値を取得するステップとを含む、方法を提供する。
専用バッファからの参照サンプルは、デフォルト値に初期化されてもよい。デフォルト値は-1であってもよい。結果として、IBCブロック・ベクトル検証のためのビットストリーム準拠性は要求されない。さらに、最後のCTU行からのサンプルはIBC参照において使用されない。この場合、IBC予測のために追加のラインメモリは必要とされない。
第5の実施形態のある側面によれば、第5の実施形態による方法のいずれかを実行するための処理回路を備えるデコーダが提供される。デコーダは、さらに、IBC参照サンプルを記憶するための専用バッファを含んでいてもよい。
第5実施形態のさらなる側面によれば、命令を有するコンピュータ・プログラム製品であって前記命令は、前記プログラムがコンピュータによって実行されると、前記コンピュータに第5実施形態による方法のいずれかを実行させるものである、コンピュータ・プログラム製品が提供される。
第5の実施形態のさらなる側面によれば、一つまたは複数のプロセッサと、前記一つまたは複数のプロセッサに結合され、前記一つまたは複数のプロセッサによる実行のための命令を記憶する非一時的なコンピュータ読み取り可能な記憶媒体とを有するデコーダが提供され、前記命令は、前記一つまたは複数のプロセッサによって実行されると、第5の実施形態による方法のいずれかを実行するように前記デコーダを構成する。
本開示の第6の実施形態は、デコード装置によって実装される符号化方法であって、ブロック内コピー(IBC)参照のための専用バッファを提供するステップと;デコードされるべき現在のブロックがIBCモードを使用して予測されるかどうかを決定するステップと;現在のブロックがIBCモードを用いて予測される場合、現在のブロックについてのIBCブロック・ベクトルを取得するステップと;専用バッファからの参照サンプルおよび現在のブロックについてのIBCブロック・ベクトルに基づいて、現在のブロックについての予測されたサンプル値を取得するステップとを含み、現在のブロックが現在のフレーム内の最初の符号化ツリー単位(CTU)の最初の符号化ブロックである場合、専用バッファがデフォルト値に初期化される、方法を提供する。
本実施形態による方法は、すべてのブロック・ベクトル検証ビットストリーム準拠性制約条件を除去する。これは、符号化されたビットストリームの堅牢性を増す。また、専用のIBCバッファは初期化される。したがって、未定義のサンプルが避けられる。
この方法は、現在のブロックが現在のフレーム内のCTU行の最初の符号化ブロックである場合に、専用バッファをデフォルト値に初期化することをさらに含んでいてもよい。
結果として、IBCブロック・ベクトル検証のためのビットストリーム準拠性は要求されない。さらに、最後のCTU行からのサンプルはIBC参照において使用されない。この場合、IBC予測のために追加のラインメモリは必要とされない。
この方法は、CTUのある領域についての専用バッファを、現在のブロックがCTUのその領域内の最初の符号化ブロックである場合に、デフォルト値に初期化するステップをさらに含んでいてもよい。CTUの前記領域は、固定サイズの、重ならない領域であってもよい。前記領域は、特に、仮想パイプライン処理単位(VPDU)であってもよい。
IBCブロック・ベクトル検証のためのビットストリーム準拠性は要求されない。最後のCTU行からのサンプルは、IBC参照において使用されない。この場合、IBC予測のために追加のラインメモリは使用されない。さらに、IBC参照メモリ・サイズは、現在のVVC設計におけるものと同じである、すなわち、本実施形態を実装するために追加のメモリは要求されない。現在のVPDU参照については、専用のIBCバッファにアクセスする必要はない。
デフォルト値は-1であってもよい。
デフォルト値は、フレームのシーケンスについて内部ビット深さに基づいて得られてもよく、ここで、現在のブロックは該シーケンスのブロックである。
現在のブロックのクロマ成分がIBCモードを用いて予測され、現在のブロックの共位置のルーマ成分がIBCモードを用いずに予測される場合、現在のブロックのクロマ成分についてのIBCブロック・ベクトルはデフォルトのブロック・ベクトルに設定されてもよい。
現在のブロックは、少なくとも2つのサブブロックを含んでいてもよく、サブブロックのクロマ成分がIBCモードを使用して予測され、該サブブロックの共位置のルーマ成分がIBCモードを用いずに予測される場合、そのサブブロックのクロマ成分についてのIBCブロック・ベクトルはデフォルトのブロック・ベクトルに設定されてもよい。
デフォルトのブロック・ベクトルは(0,0)であってもよい。デフォルト・ベクトルは、現在のブロックについての共位置の中央ルーマ・サンプルがIBCモードを使用して予測される場合、現在のブロックについての共位置の中央ルーマ・サンプルのIBCブロック・ベクトルであってもよい。
結果として、分離されたツリーの場合、クロマ成分について追加のビットストリーム準拠性検査を避けることができる。
専用バッファは、((x+BVx)%W,(y+BVy)%H)に基づいて参照されてもよく、ここで、x<0については、
Figure 0007375125000001
であり、ここで、WおよびHは、専用バッファのサイズを表わし、xおよびyは、現在のブロックの予測されたサンプルを表わし、そして(BVx,BVy)は、現在のブロックのIBCブロック・ベクトルを表わす。
第6の実施形態のある側面によれば、第6の実施形態による方法のいずれかを実行するための処理回路を備えるデコーダが提供される。デコーダは、さらに、IBC参照サンプルを記憶するための専用バッファを含んでいてもよい。
第6実施形態のさらなる側面によれば、命令を有するコンピュータ・プログラム製品であって前記命令は、前記プログラムがコンピュータによって実行されると、前記コンピュータに第6実施形態の方法のいずれかを実行させるものである、コンピュータ・プログラム製品が提供される。
第6の実施形態のさらなる側面によれば、一つまたは複数のプロセッサと、前記一つまたは複数のプロセッサに結合され、前記一つまたは複数のプロセッサによる実行のための命令を記憶する非一時的なコンピュータ読み取り可能な記憶媒体とを有するデコーダが提供され、前記命令は、前記一つまたは複数のプロセッサによって実行されると、第6の実施形態による方法のいずれかを実行するように前記デコーダを構成する。
第6の実施形態のさらなる側面によれば、ブロック内コピー(IBC)参照のための専用バッファと;デコードされるべき現在のブロックがIBCモードを使用して予測されるかどうかを決定するように構成された決定モジュールと;現在のブロックがIBCモードを用いて予測される場合、現在のブロックについてのIBCブロック・ベクトルを取得するように構成された第1の取得モジュールと;専用バッファからの参照サンプルおよび現在のブロックについてのIBCブロック・ベクトルに基づいて、現在のブロックについての予測されたサンプル値を取得するように構成された第2の取得モジュールと;現在のブロックが現在のフレーム内の最初の符号化ツリー単位(CTU)の最初の符号化ブロックである場合、専用バッファをデフォルト値に初期化するように構成された初期化モジュールとを有するデコーダが提供される。
本開示の第7の実施形態は、エンコード装置によって実装される符号化方法であって、ブロック内コピー(IBC)参照のための専用バッファを提供するステップと;専用バッファからの参照サンプルに基づいて、エンコードされるべき現在のブロックについての予測されたサンプル値を取得するステップと;現在のブロックについての予測されたサンプル値に基づいて、現在のブロックについてのIBCブロック・ベクトルを取得するステップとを含み、現在のブロックが現在のフレーム内の最初の符号化ツリー単位(CTU)の最初の符号化ブロックである場合、専用バッファがデフォルト値に初期化される、方法を提供する。
本実施形態による方法は、すべてのブロック・ベクトル検証ビットストリーム準拠性制約条件を除去する。これは、符号化されたビットストリームの堅牢性を増す。また、専用のIBCバッファは初期化される。したがって、未定義のサンプルが避けられる。
本方法は、現在のブロックが現在のフレーム内のCTU行の最初の符号化ブロックである場合に、専用バッファをデフォルト値に初期化することをさらに含んでいてもよい。
結果として、IBCブロック・ベクトル検証のためのビットストリーム準拠性は要求されない。さらに、最後のCTU行からのサンプルはIBC参照において使用されない。この場合、IBC予測のために追加のラインメモリは必要とされない。
本方法は、CTUのある領域についての前記専用バッファを、現在のブロックが前記CTUの前記領域内の最初の符号化ブロックである場合に、デフォルト値に初期化することをさらに含んでいてもよい。前記CTUの前記領域は、固定サイズの、重ならない領域であってもよい。前記領域は、特に、仮想パイプライン処理単位(VPDU)であってもよい。
IBCブロック・ベクトル検証のためのビットストリーム準拠性は要求されない。最後のCTU行からのサンプルはIBC参照において使用されない。この場合、IBC予測のために追加のラインメモリは使用されない。さらに、IBC参照メモリ・サイズは、現在のVVC設計におけるものと同じである、すなわち、本実施形態を実装するために追加のメモリは要求されない。現在のVPDU参照については、専用のIBCバッファにアクセスする必要はない。
デフォルト値は-1であってもよい。
デフォルト値は、フレームのシーケンスについての内部ビット深さに基づいて得ることができ、ここで、現在のブロックは前記シーケンスのブロックである。
現在のブロックのクロマ成分がIBCモードを用いて予測され、現在のブロックの共位置のルーマ成分がIBCモードを用いないで予測される場合、現在のブロックのクロマ成分についてのIBCブロック・ベクトルはデフォルトのブロック・ベクトルに設定されてもよい。
現在のブロックは、少なくとも2つのサブブロックを含んでいてもよく、サブブロックのクロマ成分がIBCモードを使用して予測され、サブブロックの共位置のルーマ成分がIBCモードを用いないで予測される場合、サブブロックのクロマ成分についてのIBCブロック・ベクトルがデフォルトのブロック・ベクトルに設定されてもよい。
デフォルトのブロック・ベクトルは(0,0)であってもよい。デフォルト・ベクトルは、現在のブロックについての共位置の中央ルーマ・サンプルがIBCモードを使用して予測される場合、現在のブロックについての共位置の中央ルーマ・サンプルのIBCブロック・ベクトルであってもよい。
結果として、分離されたツリーの場合、クロマ成分のための追加のビットストリーム準拠性検査を避けることができる。
専用バッファは、((x+BVx)%W,(y+BVy)%H)に基づいて参照されてもよく、ここで、x<0について、
Figure 0007375125000002
であり、ここで、WおよびHは、専用バッファのサイズを表わし、xおよびyは、現在のブロックの予測されたサンプルを表わし、(BVx,BVy)は、現在のブロックのIBCブロック・ベクトルを表わす。
第7の実施形態のある側面によれば、第7の実施形態による方法のいずれかを実行するための処理回路を備えるエンコーダが提供される。エンコーダは、さらに、IBC参照サンプルを記憶するための専用バッファを含んでいてもよい。
第7実施形態のさらなる側面によれば、命令を有するコンピュータ・プログラム製品であって前記命令は、前記プログラムがコンピュータによって実行されると、前記コンピュータに第7実施形態による方法のいずれかを実行させるものである、コンピュータ・プログラム製品が提供される。
第7の実施形態のさらなる側面によれば、一つまたは複数のプロセッサと、前記一つまたは複数のプロセッサに結合され、前記一つまたは複数のプロセッサによる実行のための命令を記憶する非一時的なコンピュータ読み取り可能な記憶媒体とを有するエンコーダが提供され、前記命令は、前記一つまたは複数のプロセッサによって実行されると、第7の実施形態による方法のいずれかを実行するように前記エンコーダを構成する。
第7の実施形態のさらなる側面によれば、ブロック内コピー(IBC)参照のための専用バッファと;専用バッファからの参照サンプルに基づいて、エンコードされるべき現在のブロックについての予測されたサンプル値を取得するように構成された第1の取得モジュールと;現在のブロックについての予測されたサンプル値に基づいて、現在のブロックについてのIBCブロック・ベクトルを取得するように構成された第2の取得モジュールと;現在のブロックが現在のフレーム内の最初の符号化ツリー単位(CTU)の最初の符号化ブロックである場合、専用バッファをデフォルト値に初期化されるように構成された初期化モジュールと有するエンコーダが提供される。
本開示の第8の実施形態は、デコード装置によって実装される符号化方法であって、現在のブロックが現在のフレーム(またはピクチャー)内の最初の符号化ツリー単位(CTU)の最初の符号化ブロックである場合、ブロック内コピー(IBC)参照のために使用される専用バッファをデフォルト値に基づいて初期化するステップと、現在のブロックがIBCモードを使用して予測されるか否かを判定するステップと、現在のブロックがIBCモードを使用して予測される場合、現在のブロックについてのIBCブロック・ベクトルを取得するステップと、専用バッファおよび現在のブロックについてのIBCブロック・ベクトルに基づいて、現在のブロックについての予測されたサンプル値を取得するステップとを含む、方法を提供する。
本開示の第9の実施形態は、エンコード装置によって実装される符号化方法であって、現在のブロックが現在のフレーム(またはピクチャー)内の最初の符号化ツリー単位(CTU)の最初の符号化ブロックである場合、ブロック内コピー(IBC)参照のために使用される専用バッファをデフォルト値に基づいて初期化するステップと、専用バッファに基づいて現在のブロックについての予測されたサンプル値を取得するステップと、現在のブロックについての予測されたサンプル値に基づいて現在のブロックについてのIBCブロック・ベクトルを取得するステップとを含む、方法を提供する。
第10の実施形態では、デコード装置によって実装される符号化方法が開示され、該方法は:
現在のブロックが現在のフレーム(またはピクチャー)の最初の符号化ツリー単位(CTU)の最初の符号化ブロックである場合、ブロック内コピー(IBC)参照のために使用される専用バッファをデフォルト値に基づいて初期化するステップと;
現在のブロックがIBCモードを使用して予測されているかどうかを判定するステップと;
現在のブロックがIBCモードを使用して予測されている場合、現在のブロックについてのIBCブロック・ベクトルを取得するステップと;
専用バッファおよび現在のブロックについてのIBCブロック・ベクトルに基づいて、現在のブロックについての予測されたサンプル値を得るステップとを含む。
ある実装では、本方法は、さらに:
現在のブロックが現在のフレーム(またはピクチャー)内のCTU行の最初の符号化ブロックである場合、専用バッファをデフォルト値に基づいて初期化することを含む。
ある実装では、本方法は、さらに:
CTUのある領域のための専用バッファを、現在のブロックが前記CTUの前記領域の最初の符号化ブロックである場合、前記デフォルト値に基づいて初期化することを含む。
ある実装では、CTU内の前記領域は、固定サイズの重ならない領域である。
ある実装では、デフォルト値は、シーケンスについての内部ビット深さに基づいて得られ、ここで、現在のブロックは前記シーケンスのブロックである。
ある実装では、現在のブロックのクロマ成分がIBCモードを使用して予測され、現在のブロックの共位置のルーマ成分がIBCモードを使用せずに予測される場合、現在のブロックのクロマ成分についてのIBCブロック・ベクトルはデフォルトのブロック・ベクトルである。
ある実装では、現在のブロックは、少なくとも2つのサブブロックを含み、サブブロックのクロマ成分がIBCモードを使用して予測され、サブブロックの共位置のルーマ成分がIBCモードを使用せずに予測される場合、サブブロックのクロマ成分についてのIBCブロック・ベクトルはデフォルトのブロック・ベクトルである。
ある実装では、デフォルトのブロック・ベクトルは(0,0)である。
ある実装では、デフォルト・ベクトルは、現在のブロックについての共位置の中央ルーマ・サンプルがIBCモードを使用して予測される場合、現在のブロックについての共位置の中央ルーマ・サンプルのブロック・ベクトルである。
第11の実施形態では、エンコード装置によって実装される符号化方法が開示され、該方法は:
現在のブロックが現在のフレーム(またはピクチャー)の最初の符号化ツリー単位(CTU)の最初の符号化ブロックである場合、ブロック内コピー(IBC)参照のために使用される専用バッファをデフォルト値に基づいて初期化するステップと;
専用バッファに基づいて、現在のブロックについての予測されたサンプル値を取得するステップと;
現在のブロックについての予測されたサンプル値に基づいて、現在のブロックについてのIBCブロック・ベクトルを得るステップとを含む。
ある実装では、本方法は、さらに:
現在のブロックが現在のフレーム(またはピクチャー)のCTU行の最初の符号化ブロックである場合、専用バッファをデフォルト値に基づいて初期化することをさらに含む。
ある実装では、本方法は、さらに:
CTUのある領域のための専用バッファを、現在のブロックが前記CTUの前記領域の最初の符号化ブロックである場合、デフォルト値に基づいて初期化することを含む。
ある実装では、CTU内の前記領域は、固定サイズの重ならない領域である。
ある実装では、デフォルト値は、シーケンスについての内部ビット深さに基づいて得られ、ここで、現在のブロックは前記シーケンスのブロックである。
ある実装では、現在のブロックのクロマ成分がIBCモードを使用して予測され、現在のブロックの共位置のルーマ成分がIBCモードを使用せずに予測される場合、現在のブロックのクロマ成分についてのIBCブロック・ベクトルはデフォルトのブロック・ベクトルである。
ある実装では、現在のブロックは、少なくとも2つのサブブロックを含み、サブブロックのクロマ成分がIBCモードを使用して予測され、サブブロックの共位置のルーマ成分がIBCモードを使用せずに予測される場合、サブブロックのクロマ成分についてのIBCブロック・ベクトルはデフォルトのブロック・ベクトルである。
ある実装では、デフォルトのブロック・ベクトルは(0,0)である。
ある実装では、デフォルト・ベクトルは、現在のブロックについての共位置の中央ルーマ・サンプルがIBCモードを使用して予測される場合、現在のブロックについての共位置の中央ルーマ・サンプルのブロック・ベクトルである。
ある実施形態では、上記の実施形態または実装のうちのいずれかによる方法を実行するための処理回路を備えるエンコーダが開示される。
ある実施形態では、上記の実施形態または実装のうちのいずれかによる方法を実行するための処理回路を備えるデコーダが開示される。
ある実施形態では、上記の実施形態または実装のうちのいずれかによる方法を実行するためのプログラムコードを含むコンピュータ・プログラム製品が開示される。
ある実施形態では、デコーダが開示され、該デコーダは:
一つまたは複数のプロセッサと;
前記プロセッサに結合され、前記プロセッサによる実行のためのプログラミングを記憶する非一時的なコンピュータ読み取り可能記憶媒体とを有しており、前記プログラミングは、前記プロセッサによって実行されると、上記の実施形態または実装のいずれかによる方法を実行するようにデコーダを構成する。
ある実施形態では、エンコーダが開示され、該エンコーダは:
一つまたは複数のプロセッサと;
前記プロセッサに結合され、前記プロセッサによる実行のためのプログラミングを記憶する非一時的なコンピュータ読み取り可能記憶媒体とを有しており、前記プログラミングは、前記プロセッサによって実行されると、上記の実施形態または実装のいずれかによる方法を実行するようにエンコーダを構成する。
一つまたは複数の実施形態の詳細は、添付の図面および下記の説明に記載されている。他の特徴、目的、および利点は、明細書、図面、および特許請求の範囲から明白であろう。
以下では、添付の図および図面を参照して、本開示の実施形態をより詳細に説明する。
本開示の実施形態を実装するように構成されたビデオ符号化システムの例を示すブロック図である。 本開示の実施形態を実装するように構成されたビデオ符号化システムの別の例を示すブロック図である。 本発明の実施形態を実装するように構成されたビデオ・エンコーダの例を示すブロック図である。 本開示の実施形態を実装するように構成されたビデオ・デコーダの例示的な構造を示すブロック図である。 エンコード装置またはデコード装置の例を示すブロック図である。 エンコード装置またはデコード装置の別の例を示すブロック図である。 (a)~(d)は、参照サンプルと現在の符号化ブロックの位置との間の関係についての例を示す。 (a)~(c)は、参照サンプルとIBCバッファとの間の関係についてのさらなる例を示す。 (a)~(c)は、参照サンプルとIBCバッファとの間の関係についてのさらなる例を示す。 (a)~(b)は、ブロック・ベクトルとIBCバッファとの間の関係についてのさらなる例を示す。 CTUについてのIBCバッファの例を示す。 ピクチャーをCTUに分割することの例を示す。 本開示のある実施形態によるビデオ・デコード方法のフローチャートを示す。 本開示のさらなる実施形態によるビデオ・デコード方法のフローチャートを示す。 本開示のある実施形態によるビデオ・エンコード方法のフローチャートを示す。 本開示のさらなる実施形態によるビデオ・エンコード方法のフローチャートを示す。 本開示のある実施形態によるデコード装置の例を示すブロック図を示す。 本開示のある実施形態によるエンコード装置の例を示すブロック図を示す。 コンテンツ配信サービスを実現するコンテンツ供給システムの例示的構造を示すブロック図である。 端末装置の例の構造を示すブロック図である。
下記では、同一の参照符号は、そうでないことが明示的に指定されていない場合は、同一のまたは少なくとも機能的に同等の特徴を指す。
以下の説明では、本開示の一部を形成し、例解のために、本開示の実施形態の特定の側面または本開示の実施形態が使用されうる特定の側面を示す添付の図面を参照する。本開示の実施形態は、他の側面で使用されてもよく、図に描かれていない構造的または論理的な変更を含んでいてもよいことが理解される。よって、以下の詳細な説明は、限定的な意味で解釈されるべきではなく、本開示の範囲は、添付の特許請求の範囲によって定義される。
たとえば、記載された方法に関連する開示は、該方法を実行するように構成された対応する装置またはシステムについても当てはまることがあり、その逆も成り立つことが理解される。たとえば、一つまたは複数の特定の方法ステップが記載されている場合、対応する装置が、記載された一つまたは複数の方法ステップを実行するための一つまたは複数のユニット、たとえば機能ユニット(たとえば、前記一つまたは複数のステップを実行する1つのユニット、または前記複数のステップのうちの一つまたは複数をそれぞれ実行する複数のユニット)を含んでいてもよい。たとえそのような一つまたは複数のユニットが明示的に記載または図示されていなくてもである。他方、たとえば、一つまたは複数のユニット、たとえば、機能ユニットに基づいて特定の装置が記載される場合、対応する方法が、前記一つまたは複数のユニットの機能を実行するための1つのステップ(たとえば、前記一つまたは複数のユニットの機能を実行する1つのステップ、または前記複数のユニットのうちの一つまたは複数のユニットの機能をそれぞれ実行する複数のステップ)を含んでいてもよい。たとえそのような一つまたは複数のステップが明示的に記載または図示されていなくてもである。さらに、本明細書に記載されるさまざまな例示的な実施形態および/または側面の特徴は、特に断りのない限り、互いに組み合わされてもよいことが理解される。
ビデオ符号化(video coding)は、典型的には、ビデオまたはビデオ・シーケンスをなすピクチャーのシーケンスの処理を指す。ビデオ符号化の分野では、「ピクチャー」という用語の代わりに、「フレーム」または「画像」という用語が同義語として使用されることがある。ビデオ符号化(または、一般には符号化)は、ビデオ・エンコードおよびビデオ・デコードの2つの部分を含む。ビデオ・エンコードは、ソース側で実行され、典型的には、(より効率的な記憶および/または伝送のために)ビデオ・ピクチャーを表わすのに要求されるデータ量を減らすために、もとのビデオ・ピクチャーを(たとえば圧縮により)処理することを含む。ビデオ・デコードは、宛先側で実行され、典型的には、ビデオ・ピクチャーを再構成するためにエンコーダに比して、逆の処理を含む。ビデオ・ピクチャー(または、一般にはピクチャー)の「符号化」に言及する実施形態は、ビデオ・ピクチャーまたはそれぞれのビデオ・シーケンスの「エンコード」または「デコード」に関係するものと理解される。エンコード部とデコード部の組み合わせは、コーデック(コーディングおよびデコーディング)とも呼ばれる。損失のないビデオ符号化の場合、もとのビデオ・ピクチャーを再構成することができる。すなわち、再構成されたビデオ・ピクチャーは、もとのビデオ・ピクチャーと同じ品質をもつ(記憶または伝送中に伝送損失またはその他のデータ損失が発生しないと仮定する)。
損失のあるビデオ符号化の場合、ビデオ・ピクチャーを表わすデータの量を減らすために、たとえば量子化によるさらなる圧縮が実行され、ビデオ・ピクチャーはデコーダにおいて完全に再構成することはできない。すなわち、再構成されたビデオ・ピクチャーの品質は、もとのビデオ・ピクチャーの品質に比べてより低い、またはより悪い。
いくつかのビデオ符号化規格は、「損失のあるハイブリッド・ビデオ・コーデック」のグループに属する(すなわち、サンプル領域における空間的および時間的予測と、変換領域における量子化を適用するための2D変換符号化とを組み合わせる)。ビデオ・シーケンスの各ピクチャーは、典型的には、一組の重ならないブロックに分割され、符号化は典型的にはブロック・レベルで実行される。換言すれば、エンコーダでは、ビデオは、典型的には、ブロック(ビデオ・ブロック)レベルで処理される、すなわちエンコードされる。これはたとえば、空間的(ピクチャー内)予測および/または時間的(ピクチャー間)予測を使用して予測ブロックを生成し、現在のブロック(現在処理されている/処理されるべきブロック)から予測ブロックを減算して残差ブロックを得て、残差ブロックを変換し、変換領域で残差ブロックを量子化して、送信されるべきデータ量を低減することによる(圧縮)。一方、デコーダでは、エンコーダに比して逆の処理が、エンコードまたは圧縮されたブロックに適用されて、表現のために現在のブロックを再構成する。さらに、エンコーダはデコーダの処理ループを複製し、そのため両者は、その後のブロックを処理する、すなわち符号化するための、同一の予測(たとえば、イントラ予測およびインター予測)および/または再構成を生成する。
ビデオ符号化システム10の下記の諸実施形態では、ビデオ・エンコーダ20およびビデオ・デコーダ30が図1~図3に基づいて説明される。
図1Aは、例示的な符号化システム10、たとえば、本願の技術を利用してもよいビデオ符号化システム10(または略、符号化システム10)を示す概略ブロック図である。ビデオ符号化システム10のビデオ・エンコーダ20(または略、エンコーダ20)およびビデオ・デコーダ30(または略、デコーダ30)は、本願に記載されるさまざまな例による技術を実行するように構成されうる装置の例を表わす。
図1Aに示されるように、符号化システム10は、源装置12を有しており、該源装置は、エンコードされたピクチャー・データ21を、エンコードされたピクチャー・データ13をデコードするために、たとえば宛先装置14に提供するように構成される。
源装置12は、エンコーダ20を有しており、追加的に、すなわち任意的に、ピクチャー・ソース16、プリプロセッサ(または前処理ユニット)18、たとえばピクチャー・プリプロセッサ18、および通信インターフェースまたは通信ユニット22を有していてもよい。
ピクチャー・ソース16は、任意の種類のピクチャー捕捉装置、たとえば、現実世界のピクチャーを捕捉するためのカメラ、および/または任意の種類のピクチャー生成装置、たとえば、コンピュータ・アニメーション化されたピクチャーを生成するためのコンピュータ・グラフィックス・プロセッサ、または、現実世界のピクチャー、コンピュータ生成されたピクチャー(たとえば、スクリーン・コンテンツ、仮想現実(VR)ピクチャー)、および/またはそれらの任意の組み合わせ(たとえば、拡張現実(AR)ピクチャー)を取得および/または提供するための任意の種類の他の装置を含んでいてもよく、それらの装置であってもよい。ピクチャー・ソースは、上記のピクチャーのいずれかを記憶する任意の種類のメモリまたは記憶装置であってもよい。
プリプロセッサ18および前処理ユニット18によって実行される処理と区別して、ピクチャーまたはピクチャー・データ17は、生のピクチャーまたは生のピクチャー・データ17と称されることもある。
プリプロセッサ18は、(生の)ピクチャー・データ17を受領し、ピクチャー・データ17に対して前処理を実行して、前処理されたピクチャー19または前処理されたピクチャー・データ19を得るように構成されてもよい。プリプロセッサ18によって実行される前処理は、たとえば、トリミング、色フォーマット変換(たとえば、RGBからYCbCrへ)、色補正、またはノイズ除去を含んでいてもよい。前処理ユニット18が、任意的な構成要素であってもよいことが理解できる。
ビデオ・エンコーダ20は、前処理されたピクチャー・データ19を受領し、エンコードされたピクチャー・データ21を提供するように構成されてもよい(さらなる詳細は、たとえば、図2に基づいて後述される)。
源装置12の通信インターフェース22は、エンコードされたピクチャー・データ21を受領し、該エンコードされたピクチャー・データ21(またはその任意のさらなる処理されたバージョン)を通信チャネル13を通じて別の装置、たとえば宛先装置14または任意の他の装置に、記憶または直接再構成のために、送信するように構成されてもよい。
宛先装置14は、デコーダ30(たとえば、ビデオ・デコーダ30)を有しており、追加的に、すなわち任意的に、通信インターフェースまたは通信ユニット28、ポストプロセッサ32(または後処理ユニット32)、および表示装置34を有していてもよい。
宛先装置14の通信インターフェース28は、エンコードされたピクチャー・データ21(またはその任意のさらなる処理されたバージョン)を、たとえば源装置12から直接、または任意の他のソース、たとえばエンコードされたピクチャー・データ記憶装置などの記憶装置から受領し、該エンコードされたピクチャー・データ21をデコーダ30に提供するように構成されてもよい。
通信インターフェース22および通信インターフェース28は、源装置12と宛先装置14との間の直接通信リンク、たとえば直接的な有線もしくは無線接続を介して、または任意の種類のネットワーク、たとえば有線もしくは無線ネットワークまたはそれらの任意の組み合わせ、または任意の種類の私的および公的ネットワーク、またはそれらの任意の種類の組み合わせを介して、エンコードされたピクチャー・データ21またはエンコードされたデータ13を送信または受信するように構成されてもよい。
通信インターフェース22は、通信リンクまたは通信ネットワークを通じた伝送のために、エンコードされたピクチャー・データ21を適切なフォーマット、たとえばパケットにパッケージ化し、および/または任意の種類の伝送エンコードもしくは処理を用いて、エンコードされたピクチャー・データを処理するように構成されてもよい。
通信インターフェース22の相手をなす通信インターフェース28は、送信されたデータを受信し、任意の種類の対応する送信デコードまたは処理および/またはパッケージ化解除を用いて送信データを処理して、エンコードされたピクチャー・データ21を得るように構成されてもよい。
通信インターフェース22および通信インターフェース28は両方とも、源装置12から宛先装置14を指す図1Aの通信チャネル13の矢印によって示されるように、一方向通信インターフェースとして、または双方向通信インターフェースとして構成されてもよく、たとえば接続をセットアップするためのメッセージを送受信し、通信リンクおよび/またはエンコードされたピクチャー・データ送信のようなデータ送信に関連する任意の他の情報を受け取り確認し交換するように構成されてもよい。
デコーダ30は、エンコードされたピクチャー・データ21を受信し、デコードされたピクチャー・データ31またはデコードされたピクチャー31を提供するように構成されてもよい(さらなる詳細は、たとえば図3または図5に基づいて、後述する)。宛先装置14のポストプロセッサ32は、デコードされたピクチャー・データ31(再構成されたピクチャー・データとも称される)、たとえばデコードされたピクチャー31を後処理して、後処理されたピクチャー・データ33、たとえば後処理されたピクチャー33を得るように構成されてもよい。後処理ユニット32によって実行される後処理は、色フォーマット変換(たとえば、YCbCrからRGBへ)、色補正、トリミング、再サンプリング、または任意の他の処理、たとえば、デコードされたピクチャー・データ31をたとえば表示装置34による表示のために準備するための処理の任意の一つまたは複数を含んでいてもよい。
宛先装置14の表示装置34は、ピクチャーをたとえばユーザーまたは観察者に対して表示するために、後処理されたピクチャー・データ33を受信するように構成されてもよい。表示装置34は、統合されたまたは外部のディスプレイまたはモニタのような、再構成されたピクチャーを表現するための任意の種類のディスプレイであってもよく、またはそれを含んでいてもよい。ディスプレイは、液晶ディスプレイ(LCD)、有機発光ダイオード(OLED)ディスプレイ、プラズマディスプレイ、プロジェクタ、マイクロLEDディスプレイ、液晶オン・シリコン(LCoS)、デジタル光プロセッサ(DLP)、または任意の種類の他のディスプレイであってもよい。
図1Aは、源装置12と宛先装置14とを別々の装置として描いているが、装置の実施形態は、両方の装置または両方の機能を、すなわち、源装置12または対応する機能と宛先装置14または対応する機能とを含んでいてもよい。そのような実施形態では、源装置12または対応する機能と宛先装置14または対応する機能は、同じハードウェアおよび/またはソフトウェアを使用して、または別個のハードウェアおよび/またはソフトウェアまたはそれらの任意の組み合わせによって実装されうる。
前記の説明に基づいて当業者には明白であろうように、図1Aに示されるようなこれらの異なるユニットの機能または源装置12および/または宛先装置14内の機能の存在および(厳密な)分割は、実際の装置および用途に依存して変わりうる。
エンコーダ20(たとえば、ビデオ・エンコーダ20)またはデコーダ30(たとえば、ビデオ・デコーダ30)またはエンコーダ20およびデコーダ30の両方は、図1Bに示されるような処理回路を介して実装されてもよい。処理回路は、一つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、離散的論理、ハードウェア、ビデオ符号化専用またはそれらの任意の組み合わせなどである。エンコーダ20は、図2のエンコーダ20および/または本明細書に記載される任意の他のエンコーダ・システムまたはサブシステムに関して論じられるさまざまなモジュールを具現するために、処理回路46を介して実装されてもよい。デコーダ30は、図3のデコーダ30および/または本明細書に記載される任意の他のデコーダ・システムまたはサブシステムに関して論じられるさまざまなモジュールを具現するために、処理回路46を介して実装されてもよい。処理回路は、後述するように、さまざまな動作を実行するように構成されてもよい。図5に示されるように、技術が部分的にソフトウェアで実装される場合、装置は、該ソフトウェアのための命令を、好適な非一時的なコンピュータ読み取り可能な記憶媒体に記憶してもよく、本開示の技術を実行するために一つまたは複数のプロセッサを使用してハードウェアにおいて前記命令を実行してもよい。ビデオ・エンコーダ20およびビデオ・デコーダ30は、たとえば図1Bに示されるように、単一の装置内の組み合わされたエンコーダ/デコーダ(コーデック)の一部として統合されてもよい。
図1Bに示されるビデオ符号化システム40は、ビデオ・エンコーダ20とビデオ・デコーダ30の両方を実装する処理回路を有する。さらに、現実世界のピクチャーを捕捉するためのカメラのような一つまたは複数の撮像装置41、アンテナ42、一つまたは複数のメモリ・ストア44、一つまたは複数のプロセッサ43、および/または上述の表示装置34のような表示装置45が、ビデオ符号化システム40の一部として提供されてもよい。
源装置12および宛先装置14は、任意の種類のハンドヘルドまたは静止装置、たとえばノートブックまたはラップトップコンピュータ、携帯電話、スマートフォン、タブレットまたはタブレットコンピュータ、カメラ、デスクトップコンピュータ、セットトップボックス、テレビ、表示装置、デジタルメディアプレーヤー、ビデオゲームコンソール、ビデオストリーミング装置(コンテンツサービスサーバーまたはコンテンツ配信サーバーなど)、放送受信機装置、放送送信機装置などを含む幅広い範囲の装置のうちの任意のものを含んでいてもよく、オペレーティング・システムを使わなくてもよく、または任意の種類のオペレーティング・システムを使用してもよい。場合によっては、源装置12および宛先装置14は、無線通信のために装備されてもよい。よって、源装置12および宛先装置14は、無線通信装置であってもよい。
場合によっては、図1Aに示されるビデオ符号化システム10は、単に例であり、本願の技術は、必ずしもエンコード装置とデコード装置との間のデータ通信を含まないビデオ符号化システム(たとえば、ビデオ・エンコードまたはビデオ・デコード)に適用されうる。他の例では、データはローカルメモリから取り出される、ネットワークを通じてストリーミングされる、などである。ビデオ・エンコード装置は、データをエンコードし、メモリに格納してもよく、および/またはビデオ・デコード装置は、メモリからデータを取り出し、デコードしてもよい。いくつかの例では、エンコードおよびデコードは、互いに通信せず、単にデータをメモリにエンコードする、および/またはメモリからデータを取り出してデコードする装置によって実行される。
説明の便宜上、本開示の実施形態は、たとえば、高効率ビデオ符号化(High-Efficiency Video Coding、HEVC)または、ITU-Tビデオ符号化エキスパートグループ(Video Coding Experts Group、VCEG)およびISO/IECの動画像エキスパートグループ(Motion Picture Experts Group、MPEG)のビデオ符号化に関する統合協働チーム(Joint Collaboration Team on Video Coding、JCT-VC)によって開発された次世代ビデオ符号化規格である多用途ビデオ符号化(Versatile Video coding、VVC)の参照ソフトウェアを参照することによって、本明細書に記載される。当業者は、本開示の実施形態がHEVCまたはVVCに限定されないことを理解するであろう。
エンコーダおよびエンコード方式
図2は、本願の技術を実装するように構成された例示的なビデオ・エンコーダ20の概略ブロック図を示す。図2の例では、ビデオ・エンコーダ20は、入力201(または入力インターフェース201)、残差計算ユニット204、変換処理ユニット206、量子化ユニット208、逆量子化ユニット210、および逆変換処理ユニット212、再構成ユニット214、ループ・フィルタ・ユニット220、デコード・ピクチャー・バッファ(decoded picture buffer、DPB)230、モード選択ユニット260、エントロピー符号化ユニット270、および出力ユニット272(または出力インターフェース272)を有する。モード選択ユニット260は、インター予測ユニット244と、イントラ予測ユニット254と、分割ユニット262とを含んでいてもよい。インター予測ユニット244は、動き推定ユニットと、動き補償ユニット(図示せず)とを含んでいてもよい。図2に示されるビデオ・エンコーダ20は、ハイブリッド・ビデオ・エンコーダまたはハイブリッド・ビデオ・コーデックによるビデオ・エンコーダと称されることもある。
残差計算ユニット204、変換処理ユニット206、量子化ユニット208、モード選択ユニット260はエンコーダ20の順方向信号経路をなすものとして言及されてもよく、一方、逆量子化ユニット210、逆変換処理ユニット212、再構成ユニット214、ループ・フィルタ220、デコード・ピクチャー・バッファ(DPB)230、インター予測ユニット244、イントラ予測ユニット254は、ビデオ・エンコーダ20の逆方向信号経路をなすものとして言及されてもよく、ビデオ・エンコーダ20の逆方向信号経路はデコーダ(図3のビデオ・デコーダ30参照)の信号経路に対応する。逆量子化ユニット210、逆変換処理ユニット212、再構成ユニット214、ループ・フィルタ220、デコード・ピクチャー・バッファ(DPB)230、インター予測ユニット244、およびイントラ予測ユニット254も、ビデオ・エンコーダ20の「内蔵デコーダ」をなすとも言及される。
ピクチャーおよびピクチャーの分割(ピクチャーとブロック)
エンコーダ20は、たとえば入力201を介して、ピクチャー17(またはピクチャー・データ17)、たとえば、ビデオまたはビデオ・シーケンスを形成するピクチャーのシーケンスのピクチャーを受領するように構成されてもよい。受領されたピクチャーまたはピクチャー・データは、前処理されたピクチャー19(または前処理されたピクチャー・データ19)であってもよい。簡単のため、以下の説明は、ピクチャー17に言及する。ピクチャー17は、現在のピクチャーまたは符号化されるべきピクチャーと称されてもよい(特に、ビデオ符号化においては、現在のピクチャーを他のピクチャー、たとえば、同じビデオ・シーケンス、すなわち、現在のピクチャーも含むビデオ・シーケンスの以前にエンコードおよび/またはデコードされたピクチャーから区別するため)。
(デジタル)ピクチャーは、強度値をもつサンプルの二次元配列またはマトリクスである、またはそのようなものと見なされることができる。配列中のサンプルは、ピクセル(ピクチャー・エレメントの短縮形)またはペル〔画素〕と称されることもある。配列またはピクチャーの水平方向および垂直方向(または軸)におけるサンプル数は、ピクチャーのサイズおよび/または解像度を定義する。色の表現のために、典型的には3つの色成分が使用され、すなわち、ピクチャーは3つのサンプル配列として表現されてもよく、または3つのサンプル配列を含んでいてもよい。RBGフォーマットまたは色空間では、ピクチャーは対応する赤、緑、および青のサンプル配列を含む。しかしながら、ビデオ符号化においては、各ピクセルは、典型的には、ルミナンスおよびクロミナンス・フォーマットまたは色空間、たとえばYCbCrで表現される。YCbCrは、Yによって示されるルミナンス成分(時に代わりにLも使用される)と、CbおよびCrによって示される2つのクロミナンス成分を含む。ルミナンス(または、略、ルーマ)成分Yは明るさまたはグレーレベル強度(たとえばグレースケール・ピクチャーにおけるような)を表わし、2つのクロミナンス(または略、クロマ)成分CbおよびCrは色度または色情報成分を表わす。よって、YCbCrフォーマットのピクチャーは、ルミナンス・サンプル値(Y)のルミナンス・サンプル配列と、クロミナンス値(CbおよびCr)の2つのクロミナンス・サンプル配列とを含む。RGBフォーマットのピクチャーはYCbCrフォーマットに変換または変成されることができ、その逆も成り立つ。このプロセスは、色変成または色変換としても知られている。ピクチャーがモノクロである場合、ピクチャーはルミナンス・サンプル配列のみを含んでいてもよい。よって、ピクチャーは、たとえば、モノクロ・フォーマットでのルーマ・サンプルの配列、または4:2:0、4:2:2、および4:4:4色フォーマットでのルーマ・サンプルの配列とクロマ・サンプルの2つの対応する配列でありうる。
ビデオ・エンコーダ20の実施形態は、ピクチャー17を複数の(典型的には重ならない)ピクチャー・ブロック203に分割するように構成されたピクチャー分割ユニット(図2には示されていない)を有していてもよい。これらのブロックは、ルート・ブロック、マクロブロック(H.264/AVC)または符号化ツリー・ブロック(coding tree block、CTB)または符号化ツリー単位(coding tree unit、CTU)(H.265/HEVCおよびVVCによる)と称されることもある。ピクチャー分割ユニットは、ビデオ・シーケンスのすべてのピクチャーについての同じブロック・サイズと、該ブロック・サイズを定義する対応するグリッドとを使うように構成されてもよく、またはピクチャー間、またはピクチャーのサブセットもしくはグループ間でブロック・サイズを変更し、各ピクチャーを対応するブロックに分割するように構成されてもよい。
さらなる実施形態では、ビデオ・エンコーダは、ピクチャー17のブロック203、たとえば、ピクチャー17を形成する1つの、いくつかの、またはすべてのブロックを直接受領するように構成されてもよい。ピクチャー・ブロック203は、現在のピクチャー・ブロックまたは符号化されるべきピクチャー・ブロックと称されることもある。
ピクチャー17と同様に、ピクチャー・ブロック203は、ピクチャー17よりも小さい寸法ではあるが、強度値(サンプル値)をもつサンプルの二次元配列またはマトリクスである、またはそのようなものと見なされることができる。言い換えると、ブロック203は、たとえば、1つのサンプル配列(たとえば、モノクロ・ピクチャー17の場合のルーマ配列またはカラー・ピクチャーの場合のルーマまたはクロマ配列)または3つのサンプル配列(たとえば、カラー・ピクチャー17の場合のルーマおよび2つのクロマ配列)または適用される色フォーマットに依存して任意の他の数および/または種類の配列を含んでいてもよい。ブロック203の水平方向および垂直方向(または軸)のサンプル数は、ブロック203のサイズを定義する。よって、ブロックは、たとえば、サンプルのM×N(M列×N行)配列、または変換係数のM×N配列を含んでいてもよい。
図2に示されるビデオ・エンコーダ20の実施形態は、ピクチャー17を一ブロックずつエンコードするように構成されてもよく、たとえば、エンコードおよび予測はブロック203毎に実行される。
図2に示されるビデオ・エンコーダ20の実施形態は、さらに、スライス(ビデオ・スライスとも称される)を使用することによってピクチャーを分割および/またはエンコードするように構成されてもよく、ピクチャーは、一つまたは複数のスライス(典型的には、重ならない)に分割され、かかるスライスを使用してエンコードされてもよく、各スライスは一つまたは複数のブロック(たとえば、CTU)を含んでいてもよい。
図2に示されるビデオ・エンコーダ20の実施形態は、タイル・グループ(ビデオ・タイル・グループとも称される)および/またはタイル(ビデオ・タイルとも称される)を用いて、ピクチャーを分割および/またはエンコードするようにさらに構成されてもよく、ピクチャーは、一つまたは複数のタイル・グループ(典型的には重ならない)に分割される、またはかかるタイル・グループを用いてエンコードされてもよく、各タイル・グループは、一つまたは複数のブロック(たとえばCTU)または一つまたは複数のタイルを含んでいてもよく、各タイルは、長方形形状であってもよく、一つまたは複数のブロック(たとえばCTU)、たとえば、完全ブロックまたは半端なブロックを含んでいてもよい。
残差計算
残差計算ユニット204は、ピクチャー・ブロック203および予測ブロック265(予測ブロック265についてのさらなる詳細は後述する)に基づいて残差ブロック205(残差205とも称される)を計算するように構成されてもよい。これはたとえば、ピクチャー・ブロック203のサンプル値から、サンプル毎に(ピクセル毎に)予測ブロック265のサンプル値を減算して、サンプル領域での残差ブロック205を得ることによる。
変換
変換処理ユニット206は、残差ブロック205のサンプル値に対して、離散コサイン変換(DCT)または離散サイン変換(DST)などの変換を適用して、変換領域での変換係数207を得るように構成されてもよい。変換係数207は、変換残差係数と称されることもあり、変換領域で残差ブロック205を表わす。
変換処理ユニット206は、H.265/HEVCについて指定された変換など、DCT/DSTの整数近似を適用するように構成されてもよい。直交DCT変換と比較して、そのような整数近似は、典型的には、ある因子によってスケーリングされる。順変換と逆変換によって処理される残差ブロックのノルムを保存するために、変換プロセスの一部として追加的なスケーリング因子が適用される。スケーリング因子は、典型的には、スケーリング因子がシフト演算のために2の冪乗であること、変換係数のビット深さ、精度と実装コストの間のトレードオフなどのようなある種の制約条件に基づいて選択される。たとえば具体的なスケーリング因子は、たとえば逆変換処理ユニット212による逆変換(およびビデオ・デコーダ30におけるたとえば逆変換処理ユニット312による対応する逆変換)について指定され、エンコーダ20におけるたとえば、変換処理ユニット206による順変換についての対応するスケーリング因子が、それに応じて指定されうる。
ビデオ・エンコーダ20(または変換処理ユニット206)の実施形態は、変換パラメータ、たとえば、変換(単数または複数)のタイプを、たとえば直接、またはエントロピー符号化ユニット270を介してエンコードまたは圧縮されて出力するように構成されてもよく、それにより、たとえばビデオ・デコーダ30は、デコードのために変換パラメータを受領し、使用することができる。
量子化
量子化ユニット208は、たとえばスカラー量子化またはベクトル量子化を適用することによって、変換係数207を量子化して、量子化された係数209を得るように構成されてもよい。量子化された係数209は、量子化された変換係数209または量子化された残差係数209と称されることもある。
量子化プロセスは、変換係数207の一部または全部に関連するビット深さを低減することができる。たとえば、nビット変換係数は、量子化中にmビット変換係数に丸められてもよい。ここで、nはmより大きい。量子化の度合いは、量子化パラメータ(QP)を調整することによって修正されてもよい。たとえば、スカラー量子化の場合、より細かいまたはより粗い量子化を達成するために、異なるスケーリングが適用されてもよい。より小さい量子化ステップサイズはより細かい量子化に対応し、より大きい量子化ステップサイズはより粗い量子化に対応する。適用可能な量子化ステップサイズは、量子化パラメータ(QP)によって示されてもよい。量子化パラメータは、たとえば、適用可能な量子化ステップサイズのあらかじめ定義された集合のインデックスであってもよい。たとえば、小さな量子化パラメータは、細かい量子化(小さな量子化ステップサイズ)に対応してもよく、大きな量子化パラメータは、粗い量子化(大きな量子化ステップサイズ)に対応してもよく、またはその逆であってもよい。量子化は、量子化ステップサイズによる除算を含んでいてもよく、たとえば逆量子化ユニット210による対応するおよび/または逆の量子化解除は、量子化ステップサイズの乗算を含んでいてもよい。いくつかの規格、たとえばHEVCによる実施形態は、量子化ステップサイズを決定するために量子化パラメータを使用するように構成されてもよい。一般に、量子化ステップサイズは、除算を含む式の固定小数点近似を使用して量子化パラメータに基づいて計算されうる。量子化ステップサイズのための式の固定小数点近似において使用されるスケーリングおよび量子化パラメータのために修正を受けることがありうる残差ブロックのノルムを復元するために、量子化および量子化解除について追加的なスケーリング係数が導入されてもよい。ある例示的な実装では、逆変換および量子化解除のスケーリングは組み合わされてもよい。あるいはまた、カスタマイズされた量子化テーブルが使用されてもよく、エンコーダからデコーダへ、たとえばビットストリームにおいて信号伝達されてもよい。量子化は、損失のある演算であり、損失は量子化ステップサイズの増大に伴って増大する。
ビデオ・エンコーダ20(または量子化ユニット208)の実施形態は、たとえば、直接、またはエントロピー符号化ユニット270を介してエンコードされて、量子化パラメータ(QP)を出力するように構成されてもよく、それにより、たとえば、ビデオ・デコーダ30は、デコードのために量子化パラメータを受領し適用することができる。
逆量子化
逆量子化ユニット210は、量子化された係数に対して、量子化ユニット208の逆数量子化を適用して、量子化解除された係数211を得るように構成される。これは、たとえば、量子化ユニット208と同じ量子化ステップサイズに基づいて、または同じ量子化ステップサイズを使用して、量子化ユニット208によって適用される量子化スキームの逆を適用することによる。量子化解除された係数211は、量子化解除された残差係数211と称されてもよく、典型的には、量子化による損失のため変換係数と同一ではないが、変換係数207に対応する。
逆変換
逆変換処理ユニット212は、変換処理ユニット206によって適用された変換の逆変換、たとえば逆離散コサイン変換(DCT)、逆離散サイン変換(DST)、または他の逆変換を適用して、サンプル領域での再構成された残差ブロック213(または対応する量子化解除された係数213)を得るように構成される。再構成された残差ブロック213は、変換ブロック213と称されてもよい。
再構成
再構成ユニット214(たとえば、加算器または合計器214)は、変換ブロック213(すなわち、再構成された残差ブロック213)を予測ブロック265に加算して、サンプル領域での再構成されたブロック215を得るように構成される。これはたとえば、再構成された残差ブロック213のサンプル値と、予測ブロック265のサンプル値とをサンプル毎に加算することによる。
フィルタリング
ループ・フィルタ・ユニット220(または略「ループ・フィルタ」220)は、再構成されたブロック215をフィルタリングして、フィルタリングされたブロック221を得るように、または一般に、再構成されたサンプルをフィルタリングして、フィルタリングされたサンプルを得るように構成される。ループ・フィルタ・ユニットは、ピクセル遷移をなめらかにするように、または、他の仕方でビデオ品質を改善するように構成されてもよい。ループ・フィルタ・ユニット220は、ブロッキング解除フィルタ、サンプル適応型オフセット(SAO)・フィルタなどの一つまたは複数のループ・フィルタまたはバイラテラル・フィルタ、適応型ループ・フィルタ(ALF)、鮮鋭化、平滑化フィルタまたは協働フィルタなどの一つまたは複数の他のフィルタ、またはそれらの任意の組み合わせなどを含んでいてもよい。ループ・フィルタ・ユニット220は、図2において、ループ内フィルタとして示されているが、他の構成では、ループ・フィルタ・ユニット220は、ループ後フィルタとして実装されてもよい。フィルタリングされたブロック221は、フィルタリングされた再構成されたブロック221として言及されてもよい。
ビデオ・エンコーダ20(またはループ・フィルタ・ユニット220)の実施形態は、たとえば、直接、またはエントロピー符号化ユニット270を介してエンコードされて、ループ・フィルタ・パラメータ(たとえば、サンプル適応型オフセット情報)を出力するように構成されてもよく、それにより、たとえば、デコーダ30は、デコードのために、同じループ・フィルタ・パラメータまたはそれぞれのループ・フィルタを受領し適用することができる。
デコード・ピクチャー・バッファ
デコード・ピクチャー・バッファ(decoded picture buffer、DPB)230は、ビデオ・エンコーダ20によってビデオ・データをエンコードするために、参照ピクチャーまたは一般には参照ピクチャー・データを記憶するメモリであってもよい。DPB 230は、同期DRAM(SDRAM)を含む動的ランダムアクセスメモリ(DRAM)、磁気抵抗RAM(MRAM)、抵抗RAM(RRAM)、または他のタイプのメモリデバイスなどの多様なメモリデバイスの任意のものによって形成されうる。デコード・ピクチャー・バッファ(DPB)230は、一つまたは複数のフィルタリングされたブロック221を記憶するように構成されてもよい。デコード・ピクチャー・バッファ230は、さらに、他の以前にフィルタリングされたブロック、たとえば同じ現在のピクチャーの、または異なるピクチャー、たとえば、以前に再構成されたピクチャーの、以前に再構成され、フィルタリングされたブロック221を記憶するように構成されてもよく、完全な以前に再構成された、すなわちデコードされたピクチャー(および対応する参照ブロックおよびサンプル)および/または部分的に再構成された現在のピクチャー(および対応する参照ブロックおよびサンプル)を、たとえばインター予測のために、提供してもよい。デコード・ピクチャー・バッファ(DPB)230は、たとえば再構成されたブロック215がループ・フィルタ・ユニット220によってフィルタリングされない場合には、一つまたは複数のフィルタリングされていない再構成されたブロック215、または一般にはフィルタリングされていない再構成されたサンプルを、あるいは再構成されたブロックまたはサンプルの任意の他のさらなる処理されたバージョンを記憶するように構成されてもよい。
モード選択(分割および予測)
モード選択ユニット260は、分割ユニット262と、インター予測ユニット244と、イントラ予測ユニット254とを有しており、もとのブロック203(現在のピクチャー17の現在のブロック203)などのもとのピクチャー・データと、再構成されたピクチャー・データとを受領または取得するように構成される。該再構成されたピクチャー・データは、同じ(現在の)ピクチャーの、および/または一つもしくは複数の以前にデコードされたピクチャーからの、たとえば、デコード・ピクチャー・バッファ230または他のバッファ(たとえば、図示しないラインバッファ)からの、フィルタリングされたおよび/またはフィルタリングされていない再構成されたサンプルまたはブロックなどである。再構成されたピクチャー・データは、予測ブロック265または予測子265を得るために、予測、たとえばインター予測またはイントラ予測のための参照ピクチャー・データとして使用される。
モード選択ユニット260は、現在のブロック予測モードのための分割(分割なしを含む)および予測モード(たとえば、イントラ予測またはインター予測モード)を決定または選択し、対応する予測ブロック265を生成するように構成されてもよい。該予測ブロックは、残差ブロック205の計算および再構成されたブロック215の再構成のために使用される。
モード選択ユニット260の実施形態は、最良のマッチ、換言すれば、最小の残差(最小の残差は、伝送または記憶のためのよりよい圧縮を意味する)または最小の信号伝達オーバーヘッド(最小の信号伝達オーバーヘッドは、伝送または記憶のためのよりよい圧縮を意味する)を提供する、または両方を考慮するもしくはバランスさせる分割および予測モードを(たとえば、モード選択ユニット260によってサポートされる、またはモード選択ユニット260のために利用可能なものから)選択するように構成されてもよい。モード選択ユニット260は、レート歪み最適化(rate distortion optimization、RDO)に基づいて分割および予測モードを決定する、すなわち、最小のレート歪みを提供する予測モードを選択するように構成されてもよい。この文脈における「最良」、「最小」、「最適」などの用語は、必ずしも全体的な「最良」、「最小」、「最適」などを指すのではなく、値が閾値を超える、または閾値を下回ることのような終了基準または選択基準、または「最適でない選択」につながる可能性があるが複雑さおよび処理時間を低減する他の制約条件を満たすことを指すこともありうる。
換言すれば、分割ユニット262は、ブロック203を、たとえば四分木分割(QT)、二分木分割(BT)、もしくは三分木分割(TT)、またはそれらの任意の組み合わせを逐次反復的に使用して、より小さなブロック・パーティションまたはサブブロック(これらもブロックを再び形成する)に分割し、ブロック・パーティションまたはサブブロックのそれぞれについて予測を実行するように構成されてもよく、モード選択は、分割されたブロック203のツリー構造の選択を含み、予測モードは、ブロック・パーティションまたはサブブロックのそれぞれに適用される。
以下、例示的なビデオ・エンコーダ20によって実行される分割(たとえば、分割ユニット262による)および予測処理(インター予測ユニット244およびイントラ予測ユニット254による)について、より詳細に説明する。
パーティション分割
分割ユニット262は、現在のブロック203を、より小さなパーティション、たとえば正方形または長方形のサイズのより小さなブロックにパーティション分割(または分割)してもよい。これらのより小さなブロック(サブブロックと称されてもよい)は、一層小さなパーティションにさらに分割されてもよい。これは、ツリー分割または階層的ツリー分割とも呼ばれ、たとえば、ルートツリーレベル0(階層レベル0、深さ0)におけるルート・ブロックが再帰的に分割されてもよい。たとえば、ツリーレベル1(階層レベル1、深さ1)のノードなど、次の下位ツリーレベルの2つ以上のブロックに分割されてもよく、これらのブロックが、ツリーレベル2(階層レベル2、深さ2)など、次の下位レベルの2つ以上のブロックに再度分割されてもよい、などと、分割が終了させられるまで行なわれる。分割の終了は、たとえば、終了基準が満たされる、たとえば最大ツリー深さまたは最小ブロック・サイズに達するためである。それ以上分割されないブロックは、ツリーのリーフ・ブロックまたはリーフ・ノードとも呼ばれる。2つのパーティションへの分割を使用するツリーは二分木(BT)と称され、3つのパーティションへの分割を使用するツリーは三分木(TT)と称され、4つのパーティションへの分割を使用するツリーは四分木(QT)と称される。
前述のように、本明細書で使用される「ブロック」という用語は、ピクチャーの一部、特に正方形または長方形の一部であってもよい。たとえば、HEVCおよびVVCを参照すると、ブロック(block)は、符号化ツリー単位(CTU)、符号化単位(CU)、予測単位(PU)、または変換単位(TU)、および/または対応するブロック、たとえば、符号化ツリー・ブロック(CTB)、符号化ブロック(CB)、変換ブロック(TB)、または予測ブロック(PB)であってもよく、またはこれらに対応するものであってもよい。
たとえば、符号化ツリー単位(CTU)は、3つのサンプル配列を有するピクチャーの、ルーマ・サンプルのCTBと、クロマ・サンプルの2つの対応するCTB、または、モノクロ・ピクチャー、または、サンプルを符号化するために使用される3つの別々のカラープレーンおよびシンタックス構造を使用して符号化されるピクチャーのサンプルのCTBであってもよく、または、これらを含んでいてもよい。対応して、符号化ツリー・ブロック(CTB)は、ある成分のCTBへの分割がパーティション分割であるように、Nの何らかの値について、サンプルのN×Nブロックであってもよい。符号化単位(CU)は、3つのサンプル配列を有するピクチャーの、ルーマ・サンプルの符号化ブロックと、クロマ・サンプルの2つの対応する符号化ブロック、または、モノクロ・ピクチャー、または、サンプルを符号化するために使用される3つの別々のカラープレーンおよびシンタックス構造を使用して符号化されるピクチャーのサンプルの符号化ブロックであってもよく、または、これらを含んでいてもよい。対応して、符号化ブロック(CB)は、CTBの符号化ブロックへの分割がパーティション分割であるように、MおよびNの何らかの値についてのサンプルのM×Nブロックであってもよい。
いくつかの実施形態では、たとえばHEVCによれば、符号化ツリー単位(CTU)は、符号化ツリーとして記される四分木構造を使用することによって、CUに分割されてもよい。ピクチャー領域をインターピクチャー(時間的)予測を使用して符号化するかイントラピクチャー(空間的)予測を使用して符号化するかの決定は、CUレベルで行なわれる。各CUはさらに、PU分割タイプに応じて、1つ、2つ、または4つのPUに分割できる。1つのPU内では、同じ予測プロセスが適用され、関連情報はPUごとにデコーダに送信される。PU分割タイプに基づく予測プロセスを適用することによって残差ブロックを得た後、CUは、該CUについての符号化ツリーに類似した別の四分木構造に従って、変換単位(TU)に分割できる。
諸実施形態において、たとえば、多用途ビデオ符号化(VVC)と称される現在開発中の最新のビデオ符号化規格によれば、組み合わされた四分木および二分木(QTBT)分割が、たとえば、符号化ブロックを分割するために使用される。QTBTブロック構造では、CUは正方形または長方形のいずれかの形状を有することができる。たとえば、符号化ツリー単位(CTU)は、まず四分木構造によって分割される。四分木リーフ・ノードは、二分木または三分木(または三進木)構造によってさらに分割される。分割ツリー・リーフ・ノードは、符号化単位(CU)と呼ばれ、該パーティションは、それ以上分割されることなく、予測および変換処理のために使用される。これは、CU、PU、およびTUがQTBT符号化ブロック構造において同じブロック・サイズをもつことを意味する。並行して、複数のパーティション、たとえば、三分木パーティションが、QTBTブロック構造と一緒に使用されてもよい。
一例では、ビデオ・エンコーダ20のモード選択ユニット260は、本明細書に記載される分割技術の任意の組み合わせを実行するように構成されてもよい。
上述のように、ビデオ・エンコーダ20は、(たとえば、あらかじめ決定された)予測モードの集合から最良のまたは最適な予測モードを決定または選択するように構成される。予測モードの集合は、イントラ予測モードおよび/またはインター予測モードを含んでいてもよい。
イントラ予測
イントラ予測モードの集合は、たとえばHEVCで定義されるように、DC(または平均)モードおよび平面モードのような非方向性モード、または、方向性モードといった35個の異なるイントラ予測モードを含んでいてもよく、またはたとえばVVCについて定義されるように、DC(または平均)モードおよび平面モードのような非方向性モード、または、方向性モードといった67個の異なるイントラ予測モードを含んでいてもよい。
イントラ予測ユニット254は、イントラ予測モードの集合からのあるイントラ予測モードに従って、同じ現在のピクチャーの近傍ブロックの再構成されたサンプルを使用して、(イントラ)予測ブロック265を生成するように構成される。
イントラ予測ユニット254(または、一般にはモード選択ユニット260)は、さらに、イントラ予測パラメータ(または、一般には、そのブロックについての選択されたイントラ予測モードを示す情報)を、エンコードされたピクチャー・データ21に含めるためのシンタックス要素266の形で、エントロピー符号化ユニット270に出力するように構成されてもよい。それにより、たとえば、ビデオ・デコーダ30が、デコードのために予測パラメータを受領し、使用することができる。
インター予測
インター予測モードの集合(または可能なインター予測モード)は、利用可能な参照ピクチャー(すなわち、たとえばDBP 230に記憶されている、以前の、少なくとも部分的にデコードされたピクチャー)および他のインター予測パラメータ、たとえば、最もよくマッチする参照ブロックを探すために使用されるのが参照ピクチャー全体か、参照ピクチャーの一部、たとえば、現在のブロックの領域のまわりの探索窓領域のみか、および/または、たとえば、半/半分ペルおよび/または四分の一ペル補間のようなピクセル補間が適用されるか否か、に依存する。
上記の予測モードに加えて、スキップモードおよび/または直接モードが適用されてもよい。
インター予測ユニット244は、動き推定(motion estimation、ME)ユニットおよび動き補償(motion compensation、MC)ユニット(ともに図2には示されていない)を含んでいてもよい。動き推定ユニットは、動き推定のために、ピクチャー・ブロック203(現在のピクチャー17の現在のピクチャー・ブロック203)およびデコードされたピクチャー231、または少なくとも一つまたは複数の以前に再構成されたブロック、たとえば、一つまたは複数の以前にデコードされたピクチャー231の再構成されたブロックを、受領または取得するように構成されてもよい。例として、ビデオ・シーケンスは、現在のピクチャーと、以前にデコードされたピクチャー231とを含んでいてもよく、換言すれば、現在のピクチャーと、以前にデコードされたピクチャー231とは、ビデオ・シーケンスをなすピクチャーのシーケンスの一部であってもよく、または、かかるシーケンスをなしてもよい。
エンコーダ20は、複数の以前にデコードされたピクチャーのうち同じまたは異なるピクチャーの複数の参照ブロックから、参照ブロックを選択し、参照ピクチャー(または参照ピクチャー・インデックス)および/または参照ブロックの位置(x、y座標)と現在のブロックの位置との間のオフセット(空間的オフセット)を、インター予測パラメータとして、動き推定ユニットに提供するように構成されてもよい。このオフセットは動きベクトル(motion vector、MV)とも呼ばれる。
動き補償ユニットは、インター予測パラメータを取得、たとえば受領し、該インター予測パラメータに基づいて、または、該インター予測パラメータを使用して、インター予測を実行して、(インター)予測ブロック265を得るように構成されてもよい。動き補償ユニットによって実行される動き補償は、動き推定によって決定された動き/ブロック・ベクトルに基づいて予測ブロックをフェッチまたは生成すること、場合によってはサブピクセル精度への補間を実行することを含んでいてもよい。補間フィルタリングは、既知のピクセル・サンプルから追加的なピクセル・サンプルを生成することができ、よって、ピクチャー・ブロックを符号化するために使用されうる候補予測ブロックの数を潜在的に増加させる。現在のピクチャー・ブロックのPUについての動きベクトルを受領すると、動き補償ユニットは、参照ピクチャー・リストのうちの1つの参照ピクチャー・リストにおいて動きベクトルがポイントする予測ブロックを位置特定することができる。
動き補償ユニットは、ビデオ・スライスの諸ピクチャー・ブロックをデコードする際にビデオ・デコーダ30が使用するために、ブロックおよびビデオ・スライスに関連付けられたシンタックス要素をも生成してもよい。スライスおよびそれぞれのシンタックス要素に加えて、またはその代替として、タイル・グループおよび/またはタイル、およびそれぞれのシンタックス要素が生成または使用されてもよい。
エントロピー符号化
エントロピー符号化ユニット270は、量子化された係数209、インター予測パラメータ、イントラ予測パラメータ、ループ・フィルタ・パラメータおよび/または他のシンタックス要素に対して、たとえば、エントロピー符号化アルゴリズムまたはスキーム(たとえば、可変長符号化(VLC)スキーム、コンテキスト適応VLCスキーム(CAVLC)、算術符号化スキーム、バイナリ化、コンテキスト適応バイナリ算術符号化(CABAC)、シンタックス・ベースのコンテキスト適応バイナリ算術符号化(SBAC)、確率区間分割エントロピー(PIPE)符号化、または他のエントロピー符号化方法論または技術)を適用するか、またはバイパスし(圧縮なし)、エンコードされたピクチャー・データ21を得るように構成される。該エンコードされたピクチャー・データは、たとえばエンコードされたビットストリーム21の形で、出力272を介して出力されることができる。それにより、ビデオ・デコーダ30は、たとえば、それらのパラメータを受領し、デコードのために使用することができる。エンコードされたビットストリーム21は、ビデオ・デコーダ30に伝送されてもよいし、または後の伝送またはビデオ・デコーダ30による取得のためにメモリに記憶されてもよい。
ビデオ・エンコーダ20の他の構造的変形が、ビデオ・ストリームをエンコードするために使用されることができる。たとえば、非変換ベースのエンコーダ20は、ある種のブロックまたはフレームについて、変換処理ユニット206なしで直接、残差信号を量子化することができる。別の実施形態では、エンコーダ20は、量子化ユニット208と逆量子化ユニット210とを組み合わせて単一のユニットにすることができる。
デコーダおよびデコード方法
図3は、本願の技術を実装するように構成されたビデオ・デコーダ30の例を示す。ビデオ・デコーダ30は、デコードされたピクチャー331を得るために、たとえばエンコーダ20によってエンコードされた、エンコードされたピクチャー・データ21(たとえばエンコードされたビットストリーム21)を受領するように構成される。エンコードされたピクチャー・データまたはビットストリームは、エンコードされたピクチャー・データ、たとえば、エンコードされたビデオ・スライス(および/またはタイル・グループまたはタイル)のピクチャー・ブロックおよび関連するシンタックス要素を表わすデータをデコードするための情報を含む。
図3の例では、デコーダ30は、エントロピー復号ユニット304と、逆量子化ユニット310と、逆変換処理ユニット312と、再構成ユニット314(たとえば、合計器314)と、ループ・フィルタ320と、デコード・ピクチャー・バッファ(DPB)330と、モード適用ユニット360と、インター予測ユニット344と、イントラ予測ユニット354とを有する。インター予測ユニット344は、動き補償ユニットであってもよいし、またはこれを含んでいてもよい。ビデオ・デコーダ30は、いくつかの例では、図2のビデオ・エンコーダ20に関して説明したエンコード・パス(pass)と概して逆のデコード・パスを実行することができる。
エンコーダ20に関して説明したように、逆量子化ユニット210、逆変換処理ユニット212、再構成ユニット214、ループ・フィルタ220、デコード・ピクチャー・バッファ(DPB)230、インター予測ユニット244、およびイントラ予測ユニット254は、ビデオ・エンコーダ20の「内蔵デコーダ」をなすものとも言及される。よって、逆量子化ユニット310は、逆量子化ユニット210と機能的に同一であってもよく、逆変換処理ユニット312は、逆変換処理ユニット212と機能的に同一であってもよく、再構成ユニット314は、再構成ユニット214と機能的に同一であってもよく、ループ・フィルタ320は、ループ・フィルタ220と機能的に同一であってもよく、デコード・ピクチャー・バッファ330は、デコード・ピクチャー・バッファ230と機能的に同一であってもよい。したがって、ビデオ・デコーダ30のそれぞれのユニットおよび機能には、ビデオ20エンコーダのそれぞれのユニットおよび機能について与えられた説明が対応して当てはまる。
エントロピー復号
エントロピー復号ユニット304は、ビットストリーム21(または一般には、エンコードされたピクチャー・データ21)をパースし、たとえば、エンコードされたピクチャー・データ21に対してエントロピー復号を実行し、たとえば、量子化された係数309および/または復号された符号化パラメータ366、たとえばインター予測パラメータ(たとえば、参照ピクチャー・インデックスおよび動きベクトル)、イントラ予測パラメータ(たとえば、イントラ予測モードまたはインデックス)、変換パラメータ、量子化パラメータ、ループ・フィルタ・パラメータ、および/または他のシンタックス要素のいずれかまたは全部を得るように構成される。エントロピー復号ユニット304は、エンコーダ20のエントロピー符号化ユニット270に関して述べたような符号化スキームに対応する復号アルゴリズムまたはスキームを適用するように構成されてもよい。エントロピー復号ユニット304は、モード適用ユニット360にインター予測パラメータ、イントラ予測パラメータおよび/または他のシンタックス要素を、およびデコーダ30の他のユニットに他のパラメータを提供するようにさらに構成されてもよい。ビデオ・デコーダ30は、ビデオ・スライス・レベルおよび/またはビデオ・ブロック・レベルでシンタックス要素を受領してもよい。スライスおよびそれぞれのシンタックス要素に加えて、またはその代替として、タイル・グループおよび/またはタイルおよびそれぞれのシンタックス要素が受領および/または使用されてもよい。
逆量子化
逆量子化ユニット310は、(たとえば、エントロピー復号ユニット304による、たとえばパースおよび/または復号によって、)エンコードされたピクチャー・データ21からの量子化パラメータ(QP)(または一般には、逆量子化に関係した情報)および量子化された係数を受領し、復号された量子化された係数309に対して、量子化パラメータに基づいて逆量子化を適用して、変換係数311と称されることもある量子化解除された係数311を得るように構成されてもよい。逆量子化プロセスは、ビデオ・スライス(またはタイル、またはタイル・グループ)内の各ビデオ・ブロックについてビデオ・エンコーダ20によって決定された量子化パラメータを使用することを含み、量子化の程度、および同様に、適用されるべき逆量子化の程度を決定することを含んでいてもよい。
逆変換
逆変換処理ユニット312は、変換係数311とも称される量子化解除された係数311を受領し、サンプル領域での再構成された残差ブロック313を得るために、量子化解除された係数311に変換を適用するように構成されてもよい。再構成された残差ブロック313は、変換ブロック313と称されることもある。変換は、逆変換、たとえば、逆DCT、逆DST、逆整数変換、または概念的に類似した逆変換プロセスであってもよい。逆変換処理ユニット312は、さらに、(たとえば、エントロピー復号ユニット304による、たとえばパースおよび/または復号によって、)エンコードされたピクチャー・データ21からの変換パラメータまたは対応する情報を受領して、量子化解除された係数311に適用される変換を決定するように構成されてもよい。
再構成
再構築ユニット314(たとえば、加算器または合計器314)は、再構成された残差ブロック313を予測ブロック365に加算して、サンプル領域での再構成されたブロック315を得るように構成されてもよい。これはたとえば、再構成された残差ブロック313のサンプル値と、予測ブロック365のサンプル値とを加算することによる。
フィルタリング
(符号化ループ内または符号化ループ後のいずれかの)ループ・フィルタ・ユニット320は、たとえばピクセル遷移を平滑化する、または他の仕方でビデオ品質を改善するために、再構成されたブロック315をフィルタリングして、フィルタリングされたブロック321を得るように構成される。ループ・フィルタ・ユニット320は、ブロッキング解除フィルタ、サンプル適応型オフセット(SAO)フィルタ、または一つまたは複数の他のフィルタ、たとえばバイラテラル・フィルタ、適応型ループ・フィルタ(ALF)、鮮鋭化、平滑化フィルタ、もしくは協働フィルタ、またはそれらの任意の組み合わせといった、一つまたは複数のループ・フィルタを有していてもよい。ループ・フィルタ・ユニット320は、ループ内フィルタとして図3に示されているが、他の構成では、ループ・フィルタ・ユニット320は、ループ後フィルタとして実装されてもよい。
デコード・ピクチャー・バッファ
次いで、ピクチャーのデコードされたビデオ・ブロック321はデコード・ピクチャー・バッファ330に記憶される。デコード・ピクチャー・バッファは、デコードされたピクチャー331を、他のピクチャーについてのその後の動き補償のためおよび/または出力もしくはそれぞれの表示のために、参照ピクチャーとして記憶する。デコーダ30は、デコードされたピクチャー311を、ユーザーに対する提示または閲覧のために、たとえば出力312を介して出力するように構成される。
予測
インター予測ユニット344は、インター予測ユニット244(特に、動き補償ユニット)と同一であってもよく、イントラ予測ユニット354は、機能的にイントラ予測ユニット254と同一であってもよく、パーティション分割および/または予測パラメータまたはエンコードされたピクチャー・データ21から(たとえば、エントロピー復号ユニット304によるたとえばパースおよび/または復号によって)受領されたそれぞれの情報に基づいて、分割もしくはパーティション分割決定および予測を実行する。モード適用ユニット360は、再構成されたピクチャー、ブロック、またはそれぞれのサンプル(フィルタリングされたまたはフィルタリングされていない)に基づいて、ブロックごとに予測(イントラ予測またはインター予測)を実行して、予測ブロック365を得るように構成されてもよい。
ビデオ・スライスまたはピクチャーが、イントラ符号化された(I)スライスとして符号化されている場合、モード適用ユニット360のイントラ予測ユニット354は、信号伝達されたイントラ予測モードおよび現在のピクチャーの以前にデコードされたブロックからのデータに基づいて、現在のビデオ・スライスのピクチャー・ブロックについての予測ブロック365を生成するように構成される。ビデオ・スライスまたはピクチャーがインター符号化された(すなわち、BまたはP)スライスとして符号化されている場合、モード適用ユニット360のインター予測ユニット344(たとえば、動き補償ユニット)は、エントロピー復号ユニット304から受領された動きベクトルおよび他のシンタックス要素に基づいて、現在のビデオ・スライスのビデオ・ブロックについての予測ブロック365を生成するように構成される。インター予測については、予測ブロックは、参照ピクチャー・リストのうちの1つの参照ピクチャー・リスト内の参照ピクチャーのうちの1つから生成されてもよい。ビデオ・デコーダ30は、DPB 330に記憶された参照ピクチャーに基づくデフォルトの構築技術を使用して、参照ピクチャー・リスト、リスト0およびリスト1を構築することができる。同じまたは類似のアプローチは、スライス(たとえば、ビデオ・スライス)に対して追加的または代替的にタイル・グループ(たとえば、ビデオ・タイル・グループ)および/またはタイル(たとえば、ビデオ・タイル)を使用する実施形態のために、またはかかる実施形態によって、適用されてもよく、たとえば、ビデオは、I、PまたはBタイル・グループおよび/またはタイルを使用して符号化されてもよい。
モード適用ユニット360は、動きベクトルまたは関係した情報および他のシンタックス要素をパースすることによって、現在のビデオ・スライスのビデオ/ピクチャー・ブロックについての予測情報を決定し、該予測情報を使用して、デコードされている現在のビデオ・ブロックについての予測ブロックを生成するように構成される。たとえば、モード適用ユニット360は、受領されたシンタックス要素のいくつかを使用して、ビデオ・スライスのビデオ・ブロックを符号化するために使用される予測モード(たとえば、イントラ予測またはインター予測)、インター予測スライス・タイプ(たとえば、Bスライス、Pスライス、またはGPBスライス)、当該スライスについての参照ピクチャー・リストのうちの一つまたは複数の参照ピクチャー・リストについての構築情報、当該スライスの各インター符号化されたビデオ・ブロックについての動きベクトル、当該スライスの各インター符号化されたビデオ・ブロックについてのインター予測ステータス、および現在のビデオ・スライス内のビデオ・ブロックをデコードするための他の情報を決定する。同じまたは類似のアプローチは、スライス(たとえば、ビデオ・スライス)に対して追加的または代替的にタイル・グループ(たとえば、ビデオ・タイル・グループ)および/またはタイル(たとえば、ビデオ・タイル)を使用する実施形態について、またはかかる実施形態によって適用されてもよく、たとえば、ビデオは、I、PまたはBタイル・グループおよび/またはタイルを使用して符号化されうる。
図3に示されるビデオ・デコーダ30の実施形態は、スライス(ビデオ・スライスとも称される)を使用することによってピクチャーを分割および/またはデコードするように構成されてもよく、ピクチャーは、一つまたは複数のスライス(典型的には重ならない)に分割されてもよく、またはかかるスライスを使ってデコードされてもよく、各スライスは一つまたは複数のブロック(たとえば、CTU)を含んでいてもよい。
図3に示すビデオ・デコーダ30の実施形態は、タイル・グループ(ビデオ・タイル・グループとも称される)および/またはタイル(ビデオ・タイルとも称される)を使用することによって、ピクチャーを分割および/またはデコードするように構成されてもよく、ピクチャーは一つまたは複数のタイル・グループ(典型的には重ならない)に分割されてもよく、またはかかるタイル・グループを使ってデコードされてもよく、各タイル・グループは一つまたは複数のブロック(たとえばCTU)または一つまたは複数のタイルを含んでいてもよく、各タイルは、長方形形状であってもよく、一つまたは複数のブロック(たとえばCTU)、たとえば、完全なまたは半端なブロックを含んでいてもよい。
ビデオ・デコーダ30の他の変形が、エンコードされたピクチャー・データ21をデコードするために使用されることができる。たとえば、デコーダ30は、ループ・フィルタリング・ユニット320なしで出力ビデオ・ストリームを生成することができる。たとえば、非変換ベースのデコーダ30は、ある種のブロックまたはフレームについて、逆変換処理ユニット312なしで直接、残差信号を逆量子化することができる。別の実施形態では、ビデオ・デコーダ30は、逆量子化ユニット310および逆変換処理ユニット312を組み合わせて単一のユニットにすることができる。
エンコーダ20およびデコーダ30では、現在のステップの処理結果がさらに処理され、次いで、次のステップに出力されてもよいことが理解されるべきである。たとえば、補間フィルタリング、動きベクトル導出、またはループ・フィルタリングの後に、クリップまたはシフトなどのさらなる操作が、補間フィルタリング、動きベクトル導出、またはループ・フィルタリングの処理結果に対して実行されてもよい。
現在のブロックの導出された動きベクトル(アフィン・モードの制御点動きベクトル、アフィン、平面、ATMVPモードにおけるサブブロック動きベクトル、時間的動きベクトルなどを含むが、これらに限定されない)には、さらなる操作が適用されてもよいことを注意しておくべきである。たとえば、動きベクトルの値は、その表現ビット数に従って、あらかじめ定義された範囲に制約される。動きベクトルの表現ビット数がbitDepthであるとすると、範囲は-2^(bitDepth-1)~2^(bitDepth-1)-1である。ここで、「^」は冪乗を意味する。たとえば、bitDepthが16に等しく設定されている場合、範囲は-32768~32767であり;bitDepthが18に等しく設定されている場合、範囲は-131072~131071である。たとえば、導出された動きベクトル(たとえば、1つの8×8ブロック内の4つの4×4サブブロックのMV)の値は、4つの4×4サブブロックMVの整数部分の間の最大差が、Nピクセル以下、たとえば1ピクセル以下になるように制約される。以下の記述は、bitDepth〔ビット深さ〕に従って動きベクトルを制約するための2つの方法を提供する。
方法1:以下の操作によってオーバーフローMSB(最上位ビット)を除去する:
Figure 0007375125000003
ここで、mvxは画像ブロックまたはサブブロックの動きベクトルの水平成分であり、mvyは画像ブロックまたはサブブロックの動きベクトルの垂直成分であり、uxおよびuyはそれぞれの中間値を示す。
たとえば、mvxの値が-32769である場合、公式(1)および(2)を適用した後、結果として得られる値は32767である。コンピュータ・システムでは、10進数は2の補数として格納される。-32769の2の補数は、1,0111,1111,1111,1111(17ビット)である。すると、MSBは破棄され、よって、結果として得られる2の補数は0111,1111,1111,1111(10進数は32767)となり、これは公式(1)および(2)を適用することによる出力と同じである。
Figure 0007375125000004
これらの操作は、公式(5)~(8)に示されるように、動きベクトル予測子(moving vector predictor)mvpと動きベクトル差分(moving vector difference)mvdとの和の間に適用されてもよい。
方法2:値をクリッピングすることによりオーバーフローMSBを除去する:
Figure 0007375125000005
ここで、vxは画像ブロックまたはサブブロックの動きベクトルの水平成分であり、vyは画像ブロックまたはサブブロックの動きベクトルの垂直成分であり;x、y、zはそれぞれMVクリッピング・プロセスの3つの入力値に対応し、関数Clip3の定義は次の通りである:
Figure 0007375125000006
図4は、本開示のある実施形態によるビデオ符号化装置400の概略図である。ビデオ符号化装置400は、以下に記載されるように、開示される実施形態を実装するのに好適である。ある実施形態では、ビデオ符号化装置400は、図1Aのビデオ・デコーダ30のようなデコーダ、または図1Aのビデオ・エンコーダ20のようなエンコーダであってもよい。
ビデオ符号化装置400は、データを受信するための入口ポート410(または入力ポート410)および一つまたは複数の受信器ユニット(Rx)420と;該データを処理するためのプロセッサ、論理ユニット、または中央処理ユニット(CPU)430と;該データを送信するための一つまたは複数の送信器ユニット(Tx)440および出口ポート450(または出力ポート450)と;該データを記憶するためのメモリ460とを有していてもよい。ビデオ符号化装置400は、光信号または電気信号の出入りのために、入口ポート410、受信器ユニット420、送信器ユニット440、および出口ポート450に結合された光‐電気(optical-to-electrical、OE)コンポーネントおよび電気‐光(electrical-to-optical、EO)コンポーネントをも有していてもよい。
プロセッサ430は、ハードウェアおよびソフトウェアによって実装されてもよい。プロセッサ430は、一つまたは複数のCPUチップ、コア(たとえば、マルチコアプロセッサとして)、FPGA、ASIC、およびDSPとして実装されてもよい。プロセッサ430は、入口ポート410、受信器ユニット420、送信器ユニット440、出口ポート450、およびメモリ460と通信してもよい。プロセッサ430は、符号化モジュール470を有していてもよい。符号化モジュール470は、上記および下記の開示される実施形態を実装する。たとえば、符号化モジュール470は、さまざまな符号化動作を実装し、処理し、準備し、または提供してもよい。よって、符号化モジュール470を含めることにより、ビデオ符号化装置400の機能に対する実質的な改善が与えられ、ビデオ符号化装置400の異なる状態への変成が実施される。あるいはまた、符号化モジュール470は、メモリ460に記憶された命令として実装され、プロセッサ430によって実行されてもよい。
メモリ460は、一つまたは複数のディスク、テープドライブ、およびソリッドステートドライブを含んでいてもよく、オーバーフロー・データ記憶装置として使用されてもよく、プログラムを、該プログラムが実行のために選択されたときに記憶し、プログラム実行中に読み出された命令およびデータを記憶してもよい。メモリ460は、たとえば、揮発性および/または不揮発性であってもよく、リードオンリーメモリ(ROM)、ランダムアクセスメモリ(RAM)、三値連想記憶メモリ(ternary content-addressable memory、TCAM)、および/またはスタティックランダムアクセスメモリ(SRAM)であってもよい。
図5は、ある例示的実施形態による、図1Aからの源装置12および宛先装置14のいずれかまたは両方として使用されうる装置500の簡略ブロック図である。
装置500内のプロセッサ502は、中央処理ユニットであることができる。あるいはまた、プロセッサ502は、現在存在する、または今後開発される、情報を操作または処理することができる、任意の他のタイプの装置または複数の装置であることができる。開示された実装は、図示されるように単一のプロセッサ、たとえば、プロセッサ502を用いて実施できるが、二つ以上のプロセッサを用いて、速度および効率における利点が達成できる。
装置500内のメモリ504は、ある実装では、リードオンリーメモリ(ROM)デバイスまたはランダムアクセスメモリ(RAM)デバイスであることができる。メモリ504として、任意の他の好適なタイプの記憶装置が使用できる。メモリ504は、バス512を使用してプロセッサ502によってアクセスされるコードおよびデータ506を含むことができる。メモリ504は、さらに、オペレーティング・システム508およびアプリケーション・プログラム510を含むことができ、アプリケーション・プログラム510は、プロセッサ502が本明細書に記載される方法を実行することを許容する少なくとも1つのプログラムを含む。たとえば、アプリケーション・プログラム510は、アプリケーション1ないしNを含むことができ、これは、本明細書に記載される方法を実行するビデオ符号化アプリケーションをさらに含む。
装置500は、ディスプレイ518などの一つまたは複数の出力装置をも含むことができる。ディスプレイ518は、一例では、ディスプレイを、タッチ入力を感知するように動作可能なタッチ感応性要素と組み合わせるタッチ感応性ディスプレイであってもよい。ディスプレイ518は、バス512を介してプロセッサ502に結合できる。
ここでは、単一のバスとして描かれているが、装置500のバス512は、複数のバスから構成されることができる。さらに、二次記憶装置(図示せず)が、装置500の他のコンポーネントに直接結合されることができ、またはネットワークを介してアクセスされることができ、メモリカードのような単一の統合されたユニットまたは複数のメモリカードのような複数のユニットを含むことができる。よって、装置500は、多様な構成で実装できる。
現在ピクチャー参照(Current Picture Referencing、CPR)モードとしても知られるブロック内コピー(Intra block copy、IBC)は、画面内容符号化(Screen Content Coding、SCC)に対するHEVC拡張において採用されるツールである。IBCが画面内容素材の符号化効率を著しく改善することはよく知られている。IBCモードはブロック・レベル符号化モードとして実装されるので、各CUについて、最適なブロック・ベクトル(または動きベクトルとも呼ばれる)を見つけるために、エンコーダにおいて、ブロック・マッチング(block matching、BM)が実行される。ここで、動きベクトルは、現在のブロックから、現在のピクチャーにおいてすでに再構成されている参照ブロックへの変位を示すために使用される。IBC符号化されたCUのルーマ動きベクトルは整数精度である。クロマ動きベクトルも整数精度にクリッピングされる。適応動きベクトル解像度(adaptive motion vector resolution、AMVR)と組み合わされた場合、IBCモードは1ペルと4ペルの動きベクトル精度の間で切り換えることができる。IBC符号化されたCUは、イントラ予測モードまたはインター予測モード以外の第3の予測モードとして扱うことができる。
メモリ消費およびデコーダの複雑さを低減するために、VVCテストモデル4(VVC Test Model 4、VTM4)におけるIBCは、現在のCTUを含むあらかじめ定義された領域の再構成された部分のみを、使用されるために許容する。この制約は、IBCモードが、ハードウェア実装のためにローカルなオンチップメモリを使用して実装されることを許容する。
エンコーダ側では、IBCのためにハッシュ・ベースの動き推定が実行される。エンコーダは、幅または高さのどちらかが16ルーマ・サンプル以下であるブロックについて、レート歪み(rate distortion、D)検査を実行する。非マージモードについては、ブロック・ベクトル探索は、まずハッシュ・ベースの探索を用いて実行される。ハッシュ・ベースの探索が有効な候補を返さない場合には、ブロック・マッチングに基づくローカル探索が実行されることになる。
CUレベルで、IBCモードはフラグを用いて信号伝達され、フラグは次のように、IBC先進動きベクトル予測(Advanced Motion Vector Prediction、AMVP)モードまたはIBCスキップ/マージモードとして信号伝達されることができる。
IBCスキップ/マージモード:近傍の候補IBC符号化ブロックからのリスト内のブロック・ベクトルを示すために使用されるマージ候補インデックス。ブロック・ベクトルは、現在のブロックを予測するために使用される。マージ候補リストは、空間的候補、履歴ベースの動きベクトル予測(History-based Motion Vector Prediction、HMVP)候補、およびペアごとの候補を含む。
IBC AMVPモード:ブロック・ベクトル差分が、動きベクトル差分と同じように符号化される。ブロック・ベクトル予測方法は、予測子として2つの候補を用いる。1つは左隣接ブロックから、1つは上隣接ブロックからである(IBCモードが隣接ブロックを符号化するために使用される場合)。隣接ブロックが利用可能でないときは、デフォルトのブロック・ベクトルが予測子として使用されることになる。ブロック・ベクトル予測子インデックスを示すために、フラグが信号伝達される。
VVCドラフト4.0では、リンクhttp://phenix.it-sudparis.eu/jvet/index.phpのもとに見出すことのできるJVET-M0407を採用することにより、IBCブロック・ベクトルの探索範囲が最適化される。
JVET-M0407では、IBCブロック・サイズが64×64ルーマ・サンプルより大きくなることは許容されない。
以下に記述される方法は、IBCモードについての有効探索範囲が現在のCTUを越えて拡張されることができるように、参照メモリ・バッファをより効率的に利用する。
つまり、参照メモリ・バッファ内の64×64ブロックのうちいずれかが、現在のCTUからの再構成されたサンプルで更新されはじめるとすぐに、その64×64ブロック全体における(左のCTUからの)以前の記憶された参照サンプルは、IBC参照のために利用不能になる。
参照メモリ・バッファ内の64×64ブロックのそれぞれは全体として考えられるので、その64×64ブロックの一部が現在のCTUからの再構成されたサンプルで更新されている場合、この64×64ブロックにおける左のCTUからの参照サンプルは、もはや使用できなくなる。
より具体的には、現在のCTUに対する現在の符号化ブロックの位置に依存して、以下が適用される。
・現在のブロックがIBCモードを使用して予測され、現在のブロックが現在のCTUの左上の64×64ブロック中に入る場合、現在のCTUにおけるすでに再構成されたサンプルに加えて、現在のブロックは、左のCTUの右下64×64ブロックにおける参照サンプルも参照することができる。さらに、現在のブロックは、左のCTUの左下の64×64ブロックにおける参照サンプルを参照することができ、左のCTUの右上の64×64ブロックにおける参照サンプルを参照することができる(図6aに示されるように)。
・現在のブロックがIBCモードを使用して予測され、現在のブロックが現在のCTUの右上の64×64ブロック中に入る場合、現在のCTUにおけるすでに再構成されたサンプルに加えて、現在のCTUに対する位置(0,64)における諸ルーマ・サンプルがまだ再構成されていない場合、現在のブロックは左下の64×64ブロックにおける参照サンプルを参照し、左のCTUの右下の64×64ブロックにおける参照サンプルを参照することができる(図6bに示されるように)。現在のCTUに対する位置(0,64)における諸ルーマ・サンプルがすでに再構成されている場合は、現在のブロックは、左のCTUの右下の64×64ブロックにおける参照サンプルを参照できるが、左のCTUの左下の64×64ブロックにおける参照サンプルは参照できない。
・現在のブロックがIBCモードを使用して予測され、現在のブロックが現在のCTUの左下の64×64ブロック中に入る場合、現在のCTUにおけるすでに再構成されたサンプルに加えて、現在のCTUに対する位置(64,0)における諸ルーマ・サンプルがまだ再構成されていない場合、現在のブロックは右上の64×64ブロックにおける参照サンプルを参照し、IBCモードを用いて左のCTUの右下の64×64ブロックにおける参照サンプルを参照することができる。現在のCTUに対する位置(64,0)における諸ルーマ・サンプルがすでに再構成されている場合は、現在のブロックは、左のCTUの右下の64×64ブロックにおける参照サンプルを参照できる(図6cに示されるように)。
・現在のブロックがIBCモードを使用して予測され、現在のブロックが現在のCTUの右下の64×64ブロック中に入る場合、現在のブロックは、現在のCTUにおけるすでに再構成されたサンプルのみを参照することができる(図6dに示されるように)。
ビットストリームは、一つまたは複数の符号化されたビデオ・シーケンスの系列である。ビットストリームがVVC仕様に準拠するためには、VVC仕様における要件および制約を満たさなければならない。シンタックス制約を満たさなければならない。VVC仕様に準拠しないデータは、単にデコーダによって拒否されることができ;規格は、そのようなデータに遭遇した場合にデコーダが何をすべきかを指定していない。非準拠データは、ビットストリーム・データを含むデータ・パケットのいくつかの損失のように、通信システムにおける問題の結果である可能性がある。
デコーダは、非準拠データに遭遇したとき、デコードを継続しようと試みても試みなくてもよい。ただし、VVCエンコーダの出力は、常にVVC仕様に完全に準拠するものとする。
たとえば、VVC仕様ドラフト5.0(JVET-N1001)では、IBC予測されたブロックについての(0,0)ブロック・ベクトルは、VVC仕様要件において定義されているように無効である。VVCデコーダは、ビットストリームがIBC予測されたブロックの(0,0)ブロック・ベクトルを含まないことに従う必要がある。
VVCドラフト5.0では、IBC参照メモリ・バッファはデコーダ・バッファと組み合わされる。IBC参照サンプルのためのハードウェア・パイプライン・メモリ・サイズを低減するために、上述の変形サイズ参照メモリ・バッファが設計される(JVET-M0407)。該変形サイズのバッファ設計では、ビットストリーム準拠のためのロット(lots)が必要である。VVCデコーダは、受領されたビットストリームが有効なVVCデコード可能ビットストリームであるかどうかを検査する。この検査は、一般にビットストリーム準拠性検査と呼ばれる。ビットストリーム準拠の数を減らすために、JVET-N0472では、IBC参照メモリ・バッファとデコーダ・バッファを混合する代わりに、専用のIBC参照メモリ・バッファが設計される。
128×128 CTUについては、専用のIBCバッファは128×128として定義される。サイズW×HをもつCU(x,y)がデコードされていたら、CU内の再構成されたサンプルは、ループ・フィルタリングの前に、位置(x%128,y%128)から開始して、W×Hのブロック領域に書き込まれる。ここで、モジュロ演算子%は、常に正の数を返す、すなわち、x<0については、
Figure 0007375125000007
たとえば-3%128=125である。このプロセスは、再構成されたサンプルを専用のIBCバッファに書き込み、それがさらなる参照のために使用される。
ブロックがIBCモードを使用して予測される場合、予測されたサンプルはIBC専用メモリからのサンプルを参照する。サンプル(x,y)(またはピクセル(x,y)とも呼ばれる)がブロック・ベクトルBV=(BVx,BVy)を用いてIBCモードで符号化されると想定すると、IBC参照バッファ内のピクセルの予測サンプルは((x+BVx)%128,(y+BVy)%128)に位置する。
バッファがWに等しい幅およびHに等しい高さをもつ領域とみなされるとき、(x,y)から始まるCTUまたはCUをデコードした後、再構成されたピクセルは、ループ・フィルタリングの前に、(x%W,y%H)から始まってバッファ内に格納されることになる。よって、CTUをデコードした後、対応するIBC参照バッファは、それに応じて更新されることになる。そのような場面は、CTUサイズが128×128でない場合にも起こりうる。たとえば、64×64 CTUについては、現在のバッファ・サイズでは、IBC参照バッファは256×64のバッファと考えることができる。
図7aは、現在のCTU、現在のCU、および左のCTUを示す。図7bは、現在のCUの現在のブロックがデコードされる前の、専用のIBCバッファを示す。また、図7cは、現在のブロックがデコードされた後の専用のIBCバッファを示す。
VVCドラフト5.0で使用される可変サイズIBCバッファと比較して、JVET-N0472が設計した専用のIBCバッファは、バイストリーム準拠性制約条件の数を減らした。しかしながら、この設計にはまだ欠点がある。たとえば、ブロック・ベクトル検証検査のために、バイストリーム準拠性が依然として必要とされる。さらに、専用のIBC参照バッファは、ハードウェア・パイプライン・メモリ・サイズを増加させる。
本開示によれば、上記の問題を解決するために、以下の実施形態が提供される。
実施形態1:
VVCドラフト5に開示されているIBC参照サンプル設計によれば、IBCブロック・ベクトル検証検査のために以下のビットストリーム準拠性が要求される。
ルーマ・ブロックまたは単一ツリーの場合について:
・参照サンプルが利用可能でなければならない。
・参照サンプルは、同じCTU行からのものでなければならない。
・参照サンプルは、現在のCTUまたは現在のCTUの左のCTUからのものでなければならない。
・参照サンプルは、図6に示されるように、定義されたIBC参照領域内になければならない。
これらの準拠性制約条件は、リンクhttp://phenix.it-sudparis.eu/jvet/index.phpの下に見出すことができるJVET-N1001の8.6.2.1章において、次のように記述されている。
ルーマ動きベクトルmvLが以下の制約条件に従うことは、ビットストリーム準拠性の要件である:
- 6.4.X項において指定されるブロック利用可能性についての導出プロセス[編集者注(BB):近傍ブロック利用可能性検査プロセスtbd]が、(xCb,yCb)に等しいとおかれた現在のルーマ位置(xCurr,yCurr)と、近傍ルーマ位置(xCb+(mvL[0]>>4),yCb+(mvL[1]>>4))を入力として呼び出されるとき、出力はTRUEに等しい。
- 6.4.X項において指定されるブロック利用可能性についての導出プロセス[編集者注(BB):近傍ブロック利用可能性検査プロセスtbd]が、(xCb,yCb)に等しいとおかれた現在のルーマ位置(xCurr,yCurr)と、近傍ルーマ位置(xCb+(mvL[0]>>4)+cbWidth-1,yCb+(mvL[1]>>4)+cbHeight-1)を入力として呼び出されるとき、出力はTRUEに等しい。
-次の条件の一方または両方が真である:
- (mvL[0]>>4)+cbWidthの値が0以下である。
- (mvL[1]>>4)+cbHeightの値が0以下である。
-次の条件が真である:
Figure 0007375125000008
- (xCb+(mvL[0]>>4)) >> CtbLog2SizeYが(xCb>>CtbLog2SizeY)-1に等しいとき、6.4.X項において指定されるブロック利用可能性についての導出プロセス[編集者注(BB):近傍ブロック利用可能性検査プロセスtbd]は、(xCb,yCb)に等しいとおかれた現在のルーマ位置(xCurr,yCurr)と、近傍ルーマ位置(((xCb+(mvL[0]>>4)+CtbSizeY)>>(CtbLog2SizeY-1))<<(CtbLog2SizeY-1),((yCb+(mvL[1]>>4))>>(CtbLog2SizeY-1))<<(CtbLog2SizeY-1))を入力として呼び出され、出力はFALSEに等しい。
ここで、(xCb,YCb)は、現在の符号化ブロックの左上のサンプルを指定するルーマ位置であり、ルーマ位置は、現在のピクチャーの左上のルーマ・サンプルに対するものであり、mvLは、1/16の分数サンプル精度におけるルーマ動きベクトル(またはブロック・ベクトル)であり、cbWidthは、ルーマ・サンプル単位での現在の符号化ブロックの幅を指定する変数であり、cbHeightは、ルーマ・サンプル単位での現在の符号化ブロックの高さを指定する変数である。CtbSizeYはCTUサイズであり、CtbLog2SizeYはlog2スケールでのCTUサイズである。
個別/デュアルツリーの場合およびクロマ・ブロックについて:
・参照サンプルが利用可能でなければならない。
これらの準拠性制約条件は、JVET-N1001の8.6.1章において次のように記述されている:
-クロマ動きベクトルmvC[xSbIdx][ySbIdx]が以下の制約条件に従うことはビットストリーム準拠性の要件である:
- 6.4.X項において指定されるブロック利用可能性についての導出プロセス[編集者注(BB):近傍ブロック利用可能性検査プロセスtbd]が(xCb/SubWidthC,yCb/SubHeightC)に等しいとおかれた現在のクロマ位置(xCurr,yCurr)と、近傍クロマ位置(xCb/SubWidthC+(mvC[xSbIdx][ySbIdx][0]>>5), yCb/SubHeightC+(mvC[xSbIdx][ySbIdx][1]>>5))を入力として呼び出されるとき、出力はTRUEに等しい。
- 6.4.X項において指定されるブロック利用可能性についての導出プロセス[編集者注(BB):近傍ブロック利用可能性検査プロセスtbd]が(xCb/SubWidthC, yCb/SubHeightC)に等しいとおかれた現在のクロマ位置(xCurr,yCurr)と、近傍クロマ位置(xCb/SubWidthC+(mvC[xSbIdx][ySbIdx][0]>>5)+cbWidth/SubWidthC-1, yCb/SubHeightC+(mvC[xSbIdx][ySbIdx][1]>>5)+cbHeight/SubHeightC-1)を入力として呼び出されるとき、出力はTRUEに等しい。
-次の条件の一方または両方が真である:
- (mvC[xSbIdx][ySbIdx][0]>>5)+xSbIdx*2+2が0以下である。
- (mvC[xSbIdx][ySbIdx][1]>>5)+ySbIdx*2+2が0以下である。
ここで、水平方向のルーマ符号化サブブロックの数numSbXおよび垂直方向のものnumSbYは、次のように導出される:
numSbX=(cbWidth>>2)
numSbY=(cbHeight>>2)
ここで、xSbIdx=0…numSbX-1であり、ySbIdx=0…numSbY-1であり、mvLは、1/16の分数サンプル精度でのルーマ動きベクトル(またはブロック・ベクトル)である。
JVET-N0472によれば、専用IBCバッファは
Figure 0007375125000009
に基づいて参照される。ここで、WおよびHは専用IBCバッファのサイズを表わす。一例では、128×128のCTUについて、WとHの両方が128に等しい。専用IBCバッファ参照規則
Figure 0007375125000010
に基づき、参照サンプルは専用IBC参照メモリ領域を超えたところにはないことになる。したがって、参照サンプルは現在のCTUまたは現在のCTUの左のCTUからのものでなければならず、参照サンプルは図6に示されるように、定義されたIBC参照領域内になければならない。
したがって、N0472では、次のビットストリーム準拠性制約条件は除去される:
・参照サンプルは、図6に示されるように、定義されたIBC参照領域内になければならない。
しかしながら、参照サンプルはルーマまたはクロマについて利用可能でなければならず、同じCTU行からの参照サンプルは、相変わらず保持しなければならない。いくつかのコーナーの場合では、専用IBCバッファが空だからである。たとえば、ピクチャーの最初のCTUでは、専用のIBCバッファは部分的に空であり、左のCTUからのサンプルはない。
実施形態1によれば、IBCブロック・ベクトル検証検査のためのすべてのビットストリーム準拠性制約条件は、単一ツリーの場合と分離ツリーの場合において、ルーマおよびクロマ成分両方について除去される。予測されたIBCブロックは、専用IBCバッファからのサンプルを参照させられ、
Figure 0007375125000011
に基づいて参照される。ここで、xおよびyは、現在のIBCブロックの左上のサンプルの座標であり、BVxおよびBVyは、現在のIBCブロックのブロック・ベクトルである。
ブロックが図11に示されるようなピクチャーの最初のCTUの最初のCUである場合、専用IBCバッファはデフォルト値で初期化される。たとえば、1<<(InternalBitDepth-1)の値がデフォルト値として使用されてもよい。10ビットの内部ビット深さについては、デフォルト値は512であってもよく、8ビットの内部ビット深さについては、デフォルト値は128であってもよい。
JVET-N0472の方法に基づく例が図8aに示される。実線の矢印は有効なブロック・ベクトルであり、これは、エンコーダによってビットストリーム中にエンコードされ、デコーダによってビットストリームからパースされることができる。破線の矢印は無効なブロック・ベクトルであり、これは、エンコーダによってバイストリーム中にエンコードされることがありうるが、VVCデコーダは、ビットストリーム準拠性要件のため、ビットストリームからそれらをパースすることはできない。
実施形態1の方法に基づく例が図8bに示されている。IBCブロック・ベクトル検証検査についてのすべてのビットストリーム準拠性制約条件が除去されるので、すべての実線の矢印は、エンコーダによってビットストリーム中にエンコードされ、デコーダによってビットストリームからパースされることができる有効なブロック・ベクトルである。形式
Figure 0007375125000012
に基づいて、図8bのすべてのブロック・ベクトルは、図8cに示されるように、専用IBCバッファ内の参照ブロックを参照している。
実施形態1の一つの利点は、ブロック・ベクトル検証についてのすべてのビットストリーム準拠性制約条件を除去することである。この実施形態は、符号化されたビットストリームの堅牢性を増す。加えて、この実施形態は、専用のIBCバッファを初期化する。未定義のサンプルは回避される。
実施形態2:
実施形態1とは独立に、または実施形態1と組み合わせて、実施形態2では、専用IBCバッファが各CTU行においてリフレッシュされる。
CTUがピクチャーの最初のCTUである場合に専用IBCバッファを初期化することに加えて、CTU行の最初のCTUも前記デフォルト値で初期化される。
一例では、現在のブロックが図11に示されるようにCTU行における最初のCUである場合、専用IBCバッファはデフォルト値で初期化される。デフォルト値は、1<<(InternalBitDepth-1)として定義されてもよい。10ビットの内部ビット深さ(internal bit depth)については、デフォルト値は512であってもよく、8ビットの内部ビット深さについては、デフォルト値は128であってもよい。
図9は、分離ツリーの場合または単一ツリーの場合のルーマ成分におけるCTU行の最初のCTUについての例を示す。図9aは、JVET-N0472の方法を示す。破線のブロック・ベクトルは無効である。参照サンプルは現在のCTUまたは現在のCTUの左のCTUからのものでなければならないというビットストリーム準拠性要件のため、専用IBCバッファ内の参照領域は空である。図9bは、実施形態2による方法を示しており、ここでは実線のブロック・ベクトルは有効である。参照ブロック領域はデフォルト値で初期化される。
実施形態2では、IBCブロック・ベクトル検証のためのビットストリーム準拠性は要求されない。さらに、最後のCTU行からのサンプルはIBC参照において使用されない。この場合、IBC予測のために追加のラインメモリは使用されない。
実施形態3:
実施形態1および/または2とは独立に、または実施形態1および/または2と組み合わせて、実施形態3では、専用IBCバッファは、各仮想パイプライン処理単位(VPDU)についてリフレッシュされる。たとえば、128×128のCTUについて、VPDUは64×64の重なり合わない領域である。よって、128×128のCTUは4つのVPDUから構築される。ハードウェア実装では、それらのVPDUは逐次的に処理される。
CTUがピクチャーの最初のCTUまたはCTU行の最初のCTUである場合に専用IBCバッファを初期化することに加えて、各VPDUにおいて、専用IBCバッファはデフォルト値でリフレッシュされる必要がある。
一例では、現在のブロックがVPDUの最初のCUである場合、専用IBCバッファはデフォルト値で初期化される。デフォルト値は、1<<(InternalBitDepth-1)として定義されてもよい。10ビットの内部ビット深さについては、デフォルト値は512であってもよく、8ビットの内部ビット深さについては、デフォルト値は128であってもよい。
図10に示されるように、CTUについての専用IBCバッファは、現在再構成されているCTUについてのサンプル、最後のCTUからのサンプル、およびデフォルト値のサンプルから構築できる。
実施形態3では、IBCブロック・ベクトル検証のためのビットストリーム準拠性は要求されない。最後のCTU行からのサンプルは、IBC参照において使用されない。この場合、IBC予測のために追加のラインメモリは使用されない。さらに、IBC参照メモリ・サイズは、現在のVVC設計におけるものと同じである、すなわち、実施形態を実装するために追加のメモリは要求されない。現在のVPDU参照のために、専用IBCバッファにアクセスする必要はない。
さらに、VVCドラフトJVET-N1001では、IBCモードで予測されるCUの最大許容サイズは128×64または64×128である。この場合、CUサイズはVPDUより大きい。
IBC参照メモリ・サイズを、128×64または64×128のサイズのCUについて、それぞれのVVC設計におけるものと同じに保つために、以下の規則の1つが、本実施形態の上に適用されてもよい。
1.) IBCモードを使用して予測される64×128または128×64のサイズのCUは許容されない。一例では、現在のCUサイズの1つの次元の寸法が64より大きい場合、IBCモード・インジケータの値は暗黙的に0に等しくてもよい、または、現在のCUについてはIBCモードを表わす別の値が無効にされてもよい。これにより、ビットストリームからインジケータをパースする必要がない。
2.) VVC JVET-N1001における分割論理に基づいて、64×128または128×64のサイズのCUは2つのVPDUを含む必要がある。この場合、両方のVPDUがデフォルト値によってリフレッシュされる。一例では、デフォルト値は1<<(InternalBitDepth-1)として定義されてもよい。各予測について、現在のPUのVPDU領域はデフォルト値でリフレッシュされてもよい。一例では、現在のCUの左上のサンプルは、現在のCTUの左上のサンプルと同じであってもよく、現在のCU幅は64であってもよく、高さは128であってもよい。この場合、128×128専用IBCバッファの左半分の64×128の領域は、1<<(InternalBitDepth-1)の値でリフレッシュされてもよい。
3.) VVC JVET-N1001における分割論理に基づいて、64×128または128×64のサイズのCUは2つのVPDUを含む必要がある。64×128または128×64のサイズCUがIBCモードを用いて予測される場合、64×128または128×64のサイズの現在のCUの2つの含まれるVPDU領域は、同じブロック・ベクトルをもつ2つの分離された予測単位(PU)とみなされてもよく、予測は別々に実行されてもよい。各予測について、現在のPUのVPDU領域はデフォルト値でリフレッシュされてもよい。一例では、CUがIBCモードを使用して予測される場合、現在のCUの左上のサンプルは、現在のCTUの左上のサンプルと同じであってもよく、現在のCU幅は、64であってもよく、高さは、128であってもよい。この場合、128×128の専用IBCバッファの左上の64×64領域は、現在の64×128 CUの第1の(上の)PUを予測する間にリフレッシュされうる。128×128の専用IBCバッファの左下の64×64の領域は、現在の64×128のCUの第2の(下の)PUを予測する間にリフレッシュされうる。
実施形態4:
現在のVVCドラフト(JVET-N1001)のIBC参照バッファ設計、またはJVET-N0472のIBC参照バッファ設計においては、分離ツリーの場合、クロマ成分はIBC予測モードによって予測できる。しかしながら、クロマ・ブロックについてのIBC予測モードは、次のようなビットストリーム準拠性を要求する。
分離ツリーの場合における現在のクロマ・ブロックは、2×2サブブロックに分割され、各サブブロックは、共位置のルーマ成分サブブロックをもつ。クロマ・ブロックがIBCモードを使用して予測される場合、各2×2クロマ・サブブロックのブロック・ベクトルは、共位置のルーマ・サブブロックがIBCモードで予測される場合は、共位置のルーマ成分サブブロックから継承される。いずれかの共位置のルーマ・サブブロックがIBCモードで予測されない場合、または継承されたBVがクロマ・ブロックについてのVVCドラフト5.0またはJVET-N0472のビットストリーム準拠性に基づいて無効である場合、現在のクロマ・ブロックはIBCモードでは予測できない。
実施形態1、2または3とは独立に、またはそれらと組み合わせて、実施形態4では、クロマ・ブロック・ビットストリーム準拠性検査のためのIBC予測モードは必要とされない。一例では、分離ツリーの場合のクロマ・ブロックは、2×2サブブロックに分割され、各サブブロックは、共位置のルーマ成分サブブロックをもつ。現在のブロックがIBCモードを使用して予測されるとき、各2×2クロマ・サブブロックのブロック・ベクトルは、共位置のルーマ・サブブロックがIBCモードで予測されるとき、共位置のルーマ成分サブブロックから継承される。共位置のルーマ・サブブロックがIBCモードを使用して予測されない場合、対応する2×2クロマ・サブブロックについて、デフォルト・ブロック・ベクトルが設定されてもよい。一例におけるデフォルト・ベクトルは、(0,0)であってもよい。別の例では、デフォルト・ベクトルは、現在のクロマ・ブロックのIBC予測されたルーマの共位置のブロックの中央サンプルのブロック・ベクトルであってもよい。実施形態4に基づいて、分離ツリーの場合におけるクロマ成分について、追加のビットストリーム準拠性検査は回避されうる。
図12は、本開示のある実施形態によるビデオ・デコード方法のフローチャートを示す。ステップ1010では、ブロック内コピー(IBC)参照のための専用バッファが提供される。ステップ1020では、現在の符号化ブロック(CB)が、現在のフレーム内の最初の符号化ツリー単位(CTU)の最初の符号化ブロックであるかどうかが判定される。そうである場合、専用バッファは、ステップ1040においてデフォルト値に初期化される。そうでない場合は、ステップ1030において、現在の符号化ブロックが現在のフレーム内のCTU行の最初の符号化ブロックであるかどうかが判定される。この場合、専用バッファはステップ1040においてデフォルト値に初期化される。その後、ステップ1050において、デコードされるべき現在のブロックがIBCモードを使用して予測されるかどうかが決定される。現在のブロックがIBCモードを使用して予測される場合、ステップ1060において、現在のブロックについて、IBCブロック・ベクトルが得られる。最後に、ステップ1070において、専用バッファからの参照サンプルと、現在のブロックについてのIBCブロック・ベクトルとに基づいて、現在のブロックについて、予測されたサンプル値が得られる。
図13は、本開示のさらなる実施形態によるビデオ・デコード方法のフローチャートを示す。ブロック内コピー(IBC)参照のための専用バッファが提供されている。ステップ1510では、現在の符号化ツリー単位(CTU)がCTU行の最初のCTUであるかどうかが判定される。そうである場合、ステップ1520において、専用バッファがデフォルト値に初期化される。その後、ステップ1530において、デコードされるべき現在のブロックがIBCモードを使用して予測されるかどうかが決定される。現在のブロックがIBCモードを使用して予測される場合、ステップ1540において、現在のブロックについて、IBCブロック・ベクトルが得られる。最後に、ステップ1550において、専用バッファからの参照サンプルと、現在のブロックについてのIBCブロック・ベクトルとに基づいて、現在のブロックについて、予測されたサンプル値が得られる。
図14は、本開示のある実施形態によるビデオ・エンコード方法のフローチャートを示す。ステップ1110では、ブロック内コピー(IBC)参照のための専用バッファが提供される。ステップ1120では、現在の符号化ブロック(CB)が、現在のフレーム内の最初の符号化ツリー単位(CTU)の最初の符号化ブロックであるかどうかが判定される。そうである場合、専用バッファは、ステップ1140においてデフォルト値に初期化される。そうでない場合は、ステップ1130において、現在の符号化ブロックが現在のフレーム内のCTU行の最初の符号化ブロックであるかどうかが判定される。この場合、専用バッファはステップ1040においてデフォルト値に初期化される。その後、専用バッファからの参照サンプルに基づいて、ステップ1150において、符号化されるべき現在のブロックについて、予測されたサンプル値が得られる。最後に、ステップ1160において、現在のブロックについての予測されたサンプル値に基づいて、現在のブロックについてのIBCブロック・ベクトルが得られる。
図15は、本開示のさらなる実施形態によるビデオ・エンコード方法のフローチャートを示す。ブロック内コピー(IBC)参照のための専用バッファが提供されている。ステップ1610では、現在の符号化ツリー単位(CTU)がCTU行の最初のCTUであるかどうかが決定される。そうである場合、ステップ1620において、専用バッファがデフォルト値に初期化される。その後、専用バッファからの参照サンプルに基づいて、ステップ1630において、エンコードされるべき現在のブロックについて、予測されたサンプル値が得られる。最後に、ステップ1640において、現在のブロックについての予測されたサンプル値に基づいて、現在のブロックについて、IBCブロック・ベクトルが得られ、エンコードされる。
図16は、本開示のある実施形態によるデコード装置の例を示すブロック図を示す。デコード装置(30)は、ブロック内コピー(IBC)参照のための専用バッファ(1350)と、専用バッファをデフォルト値に初期化するように構成された初期化モジュール(1310)と、現在のブロックがIBCモードを用いて予測されるかどうかを判定するように構成された決定モジュール(1320)と、現在のブロックがIBCモードを用いて予測されるときに現在のブロックについてのIBCブロック・ベクトルを得るように構成された第1の取得モジュール(1330)と、専用バッファからの参照サンプルおよび現在のブロックについてのIBCブロック・ベクトルに基づいて、現在のブロックについての予測されたサンプル値を得るように構成された第2の取得モジュール(1340)とを有する。初期化モジュール(1310)は、現在の符号化ツリー単位(CTU)がCTU行内の最初のCTUである場合に、専用バッファを初期化するように構成されてもよい。代替的または追加的に、専用バッファは、現在のCTUがピクチャー内の最初のCTUである場合に初期化されてもよい。代替的または追加的に、専用バッファは、デコードされるべき現在のブロックがCTU行および/または現在のフレーム内の最初の符号化ツリー単位(CTU)の最初の符号化ブロックである場合に初期化されてもよい。代替的または追加的に、初期化モジュール(1310)は、CTUのある領域のための前記専用バッファを、デコードされるべき現在の符号化ブロックがそのCTUのその領域内の最初の符号化ブロックである場合に、初期化するように構成されてもよい。
図17は、本開示のある実施形態によるエンコード装置の例を示すブロック図を示す。エンコード装置(20)は、ブロック内コピー(IBC)参照のための専用バッファ(1450)と、専用バッファをデフォルト値に初期化するように構成された初期化モジュール(1410)と、専用バッファからの参照サンプルに基づいて、現在のブロックについての予測されたサンプル値を得るように構成された第1の取得モジュール(1420)と、現在のブロックについての予測されたサンプル値に基づいて、現在のブロックについてのIBCブロック・ベクトルを得るように構成された第2の取得モジュール(1430)とを有する。初期化モジュール(1410)は、現在の符号化ツリー単位(CTU)がCTU行内の最初のCTUである場合に、専用バッファを初期化するように構成されてもよい。代替的または追加的に、専用バッファは、現在のCTUがピクチャー内の最初のCTUである場合に初期化されてもよい。代替的または追加的に、専用バッファは、エンコードされるべき現在のブロックが、CTU行および/または現在のフレーム内の最初の符号化ツリー単位(CTU)の最初の符号化ブロックである場合に、初期化されてもよい。代替的または追加的に、初期化モジュール(1410)は、CTUのある領域についての前記専用バッファを、エンコードされるべき現在の符号化ブロックがそのCTUのその領域内の最初の符号化ブロックである場合に、初期化するように構成されてもよい。
初期化モジュール1310および1410、決定モジュール1320、第1の取得モジュール1330および1420、ならびに第2の取得モジュール1340および1430は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせで実装されうる。ソフトウェアで実装される場合、機能は、一つまたは複数の命令またはコードとして、コンピュータ読み取り可能媒体に記憶されるかまたは通信媒体を通じて伝送され、ハードウェア・ベースの処理ユニットによって実行されてもよい。命令は、一つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の同等の集積されたもしくは離散的な論理回路などの一つまたは複数のプロセッサによって実行されうる。よって、本明細書で使用される「プロセッサ」という用語は、前述の構造、または本明細書に記載される技術の実装のために好適な任意の他の構造のいずれかを指しうる。さらに、いくつかの側面では、本明細書に記載される機能は、エンコードおよびデコードのために構成される専用ハードウェアおよび/またはソフトウェア・モジュール内で提供されてもよく、または組み合わされたコーデックに組み込まれてもよい。また、これらの技術は、一つまたは複数の回路または論理素子で完全に実装されることができる。
専用バッファ1350および1450は、RAM、ROM、EEPROM、CD-ROMまたは他の光ディスク記憶装置、磁気ディスク記憶装置、または他の磁気記憶デバイス、フラッシュメモリ、または所望のデータ構造を記憶するために使用でき、コンピュータによってアクセスできる任意の他の媒体のような、任意のコンピュータ読み取り可能な記憶媒体において実装されうる。専用バッファは、別個のメモリデバイスとして、および/またはCPU、GPUまたはDSPなどの処理回路の一部として提供されてもよい。専用バッファは、同期DRAM(SDRAM)を含むダイナミックランダムアクセスメモリ(DRAM)、磁気抵抗RAM(MRAM)、抵抗RAM(RRAM)、または他のタイプのメモリデバイスのような多様なメモリデバイスの任意のものによって形成されうる。
図18は、コンテンツ配信サービスを実現するためのコンテンツ供給システム3100を示すブロック図である。このコンテンツ供給システム3100は、捕捉装置3102、端末装置3106を含み、および任意的にはディスプレイ3126を含む。捕捉装置3102は、通信リンク3104を通じて端末装置3106と通信する。通信リンクは、上述の通信チャネル13を含んでいてもよい。通信リンク3104は、WIFI、イーサネット、ケーブル、無線(3G/4G/5G)、USB、またはそれらの任意の種類の組み合わせなどを含むが、これらに限定されない。
捕捉装置3102は、データを生成し、上記の諸実施形態に示されるようなエンコード方法によって該データをエンコードしてもよい。あるいはまた、捕捉装置3102は、ストリーミングサーバー(図には示されていない)にデータを配信することができ、サーバーは、データをエンコードし、エンコードされたデータを端末装置3106に送信する。捕捉装置3102は、カメラ、スマートフォンもしくはパッド、コンピュータもしくはラップトップ、ビデオ会議システム、PDA、車載装置、またはそれらのいずれかの組み合わせなどを含むが、これらに限定されない。たとえば、捕捉装置3102は、上述のように源装置12を含んでいてもよい。データがビデオを含む場合、捕捉装置3102に含まれるビデオ・エンコーダ20が、実際にビデオ・エンコード処理を実行してもよい。データがオーディオ(すなわち、声)を含む場合、捕捉装置3102に含まれるオーディオ・エンコーダが、実際にオーディオ・エンコード処理を実行してもよい。いくつかの実際的なシナリオについては、捕捉装置3102は、エンコードされたビデオおよびオーディオ・データを、それらを一緒に多重化することによって配信する。たとえばビデオ会議システムにおける、他の実際的なシナリオについては、エンコードされたオーディオ・データおよびエンコードされたビデオ・データは多重化されない。捕捉装置3102は、エンコードされたオーディオ・データおよびエンコードされたビデオ・データを別々に端末装置3106に配信してもよい。
コンテンツ供給システム3100では、端末装置3106は、エンコードされたデータを受信および再生する。端末装置3106は、スマートフォンもしくはパッド3108、コンピュータもしくはラップトップ3110、ネットワークビデオレコーダ(NVR)/デジタルビデオレコーダ(DVR)3112、TV 3114、セットトップボックス(STB)3116、ビデオ会議システム3118、ビデオ監視システム3120、パーソナルデジタルアシスタント(PDA)3122、車載装置3124、またはそれらのいずれかの組み合わせなどの上記のエンコードされたデータのデコードができるもののような、データの受信および復元機能をもつ装置であってもよい。たとえば、端末装置3106は、上述のような宛先装置14を含みうる。エンコードされたデータがビデオを含む場合、端末装置に含まれるビデオ・デコーダ30が、ビデオ・デコードを実行するために優先される。符号化されたデータがオーディオを含む場合、端末装置に含まれるオーディオ・デコーダが、オーディオ・デコード処理を実行するために優先される。
ディスプレイを有する端末装置、たとえば、スマートフォンもしくはパッド3108、コンピュータもしくはラップトップ3110、ネットワークビデオレコーダ(NVR)/デジタルビデオレコーダ(DVR)3112、TV 3114、パーソナルデジタルアシスタント(PDA)3122、または車載装置3124については、端末装置は、デコードされたデータをそのディスプレイに給送してもよい。ディスプレイを備えない端末装置、たとえば、STB 3116、ビデオ会議システム3118、またはビデオ監視システム3120については、デコードされたデータを受信し、示すために、外部ディスプレイ3126がそこに接触されてもよい。
このシステムの各装置がエンコードまたはデコードを実行する場合、上記実施形態に示されるようなピクチャー・エンコード装置またはピクチャー・デコード装置が使用できる。
図19は、端末装置3106の例の構成を示す図である。端末装置3106が捕捉装置3102からストリームを受信した後、プロトコル進行ユニット3202は、ストリームの伝送プロトコルを解析する。プロトコルは、リアルタイムストリーミングプロトコル(RTSP)、ハイパーテキスト転送プロトコル(HTTP)、HTTPライブストリーミングプロトコル(HLS)、MPEG-DASH、リアルタイムトランスポートプロトコル(RTP)、リアルタイムメッセージングプロトコル(RTMP)、またはそれらの任意の種類の組み合わせなどを含むが、これらに限定されない。プロトコル進行ユニット3202がストリームを処理した後、ストリームファイルが生成される。該ファイルは、多重分離ユニット3204に出力される。多重分離ユニット3204は、多重化されたデータをエンコードされたオーディオ・データおよびエンコードされたビデオ・データに分離することができる。上述したように、たとえばビデオ会議システムにおける、いくつかの実際的なシナリオについては、エンコードされたオーディオ・データおよびエンコードされたビデオ・データは多重化されない。この状況では、エンコードされたデータは、多重分離ユニット3204を通過することなく、ビデオ・デコーダ3206およびオーディオ・デコーダ3208に送信される。多重分離処理を介して、ビデオ・エレメンタリーストリーム(ES)、オーディオES、および任意的には字幕が生成される。上述の実施形態で説明したように、ビデオ・デコーダ30を含むビデオ・デコーダ3206は、上述の実施形態に示されるデコード方法によって、ビデオESをデコードしてビデオ・フレームを生成し、このデータを同期ユニット3212に給送する。オーディオ・デコーダ3208は、オーディオESをデコードしてオーディオ・フレームを生成し、このデータを同期ユニット3212に給送する。あるいはまた、ビデオ・フレームは、同期ユニット3212に給送する前に、バッファ(図19には示されない)に格納されてもよい。同様に、オーディオ・フレームは、同期ユニット3212に給送する前に、バッファ(図19には示されない)に格納されてもよい。
同期ユニット3212は、ビデオ・フレームとオーディオ・フレームを同期させ、該ビデオ/オーディオをビデオ/オーディオ・ディスプレイ3214に供給する。たとえば、同期ユニット3212は、ビデオ情報およびオーディオ情報の提示を同期させる。情報は、符号化されたオーディオおよびビジュアルデータの提示に関するタイムスタンプおよびデータストリーム自体の配送に関するタイムスタンプを使用するシンタックスにおいて符号化することができる。
字幕がストリームに含まれる場合、字幕デコーダ3210は、字幕をデコードし、それをビデオ・フレームおよびオーディオ・フレームと同期させ、ビデオ/オーディオ/字幕をビデオ/オーディオ/字幕ディスプレイ3216に供給する。
本発明は、上述のシステムに限定されるものではなく、上述の実施形態におけるピクチャー・エンコード装置またはピクチャー・デコード装置のいずれかも、他のシステム、たとえば、車両システムに組み込むことができる。
数学的演算子
本願で使用される数学的演算子は、Cプログラミング言語で使用される演算子と同様である。しかしながら、整数除算演算および算術シフト演算の結果は、より精密に定義され、冪乗や実数値除算などの追加的な演算が定義される。番号付けとカウントの規約は、一般に0から始まる。すなわち、「第1」は0番と等価であり、「第2」は1番と等価である、などとなる。
算術演算子
以下の算術演算子は、下記のように定義される:
Figure 0007375125000013
論理演算子
以下の論理演算子は、下記のように定義される:
Figure 0007375125000014
関係演算子
以下の関係演算子は、下記のように定義される:
Figure 0007375125000015
関係演算子が値「na」(not applicable[該当せず])が割り当てられたシンタックス要素または変数に適用される場合、値「na」はそのシンタックス要素または変数についての独特な値として扱われる。値「na」はいかなる他の値とも等しくないとみなされる。
ビット単位の演算子
以下のビット単位の演算子は、下記のように定義される:
& ビット単位の「かつ」。整数引数に対して作用する場合、整数値の2の補数表現に対して作用する。他の引数よりも少ないビットを含むバイナリ引数に対して作用するとき、短いほうの引数は、さらなる、0に等しい有効ビットを加えることによって延長される。
| ビット単位の「または」。整数引数に対して作用する場合、整数値の2の補数表現に対して作用する。他の引数よりも少ないビットを含むバイナリ引数に対して作用するとき、短いほうの引数は、さらなる、0に等しい有効ビットを加えることによって延長される。
^ ビット単位の「排他的なまたは」。整数引数に対して作用する場合、整数値の2の補数表現に対して作用する。他の引数よりも少ないビットを含むバイナリ引数に対して作用するとき、短いほうの引数は、さらなる、0に等しい有効ビットを加えることによって延長される。
x>>y xの2の補数整数表現の、y個の2進数字ぶんの算術右シフト。この関数は、yの負でない整数値についてのみ定義される。右シフトの結果として諸最上位ビット(MSB)にシフトされた諸ビットは、シフト演算の前のxのMSBに等しい値をもつ。
x<<y xの2の補数整数表現の、y個の2進数字ぶんの算術左シフト。この関数は、yの負でない整数値についてのみ定義される。左シフトの結果として諸最下位ビット(LSB)にシフトされた諸ビットは、0に等しい値をもつ。
代入演算子
以下の算術演算子は、下記のように定義される:
= 代入演算子
++ インクリメント、すなわちx++はx=x+1と等価;配列インデックスにおいて使用される場合は、インクリメント演算の前の変数の値に評価される。
-- デクリメント、すなわちx--はx=x-1と等価;配列インデックスにおいて使用される場合は、デクリメント演算の前の変数の値に評価される。
+= 指定された量だけインクリメント。すなわちx+=3はx=x+3と等価であり、x+=(-3)はx=x+(-3)と等価である。
-= 指定された量だけデクリメント。すなわちx-=3はx=x-3と等価であり、x-=(-3)はx=x-(-3)と等価である。
範囲記法
次の記法が、値の範囲を指定するために使用される:
x=y…z xは、yからzまで(両端含む)の整数値をとる。ここで、x、y、zは整数であり、zはyより大きい。
数学的関数
次の数学的関数が定義される:
Figure 0007375125000016

Asin(x) 三角法の逆正弦関数。-1.0から1.0の範囲(両端含む)にある引数xに対して作用する。出力値はラジアン単位で-π÷2からπ÷2の範囲(両端含む)。
Atan(x) 三角法の逆正接関数。引数xに対して作用する。出力値はラジアン単位で-π÷2からπ÷2の範囲(両端含む)。
Figure 0007375125000017
Ceil(x) x以上の最小の整数。
Clip1Y(x)=Clip3(0,(1 << BitDepthY)-1,x)
Clip1C(x)=Clip3(0,(1 << BitDepthC)-1,x)
Figure 0007375125000018
Cos(x) ラジアン単位の引数xに対して作用する三角法の余弦関数。
Floor(x) x以下の最大の整数。
Figure 0007375125000019
Ln(x) xの自然対数(eを底とする対数。ここで、eは自然対数の底の定数2.718281828…)。
Log2(x) 2を底とするxの対数。
Log10(x) 10を底とするxの対数。
Figure 0007375125000020
Sin(x) ラジアン単位の引数xに作用する三角法の正弦関数
Sqrt(x)=√x
Swap(x,y)=(y,x)
Tan(x) ラジアン単位の引数xに作用する三角法の正接関数
演算優先順
式における優先順が括弧を使用して明示的に示されない場合、次の規則が適用される:
-より高い優先順位の演算が、より低い優先順位の演算の前に評価される。
-同じ優先順位の演算は、左から右へ逐次的に評価される。
下記の表は、最高から最低までの演算の優先順位を指定する;表中の、より高い位置は、より高い優先順位を示す。
Cプログラミング言語でも使用される演算子については、本仕様で使用される優先順は、Cプログラミング言語で使用されるものと同じである。
表:最高(表のいちばん上)から最低(表のいちばん下)への演算優先順位
Figure 0007375125000021
論理演算のテキスト記述
テキストでは、数学的に次の形:
if(条件0)
陳述0
else if(条件1)
陳述1

else /* 残りの条件に関する参考用のコメント */
陳述n
で記述される論理演算の陳述は、次のように記述されてもよい:
…次のとおりである/…下記が適用される:
-もし条件0であれば、陳述0
-そうでない場合、条件1であれば、陳述1
-…
-それ以外の場合には(残りの条件に関する参考用のコメント)陳述n。
テキストにおける「もし…であれば…、そうでない場合、…であれば…、そうでない場合…」という各陳述は、「…次のとおりである」または「…下記が適用される」によって導入されてそのすぐ後に「もし…」が続く。「もし…であれば…、そうでない場合、…であれば…、そうでない場合…」の最後の条件は、常に「それ以外の場合…」であってもよい。間にはさまれる「もし…であれば…、そうでない場合、…であれば…、そうでない場合…」という陳述は、「…次のとおりである」または「…下記が適用される」を最後の「それ以外の場合…」と対応させることによって識別できる。
テキストでは、数学的に次の形:
if(条件0a & 条件0b)
陳述0
else if(条件1a || 条件1b)
陳述1

else
陳述n
で記述される論理演算の陳述は、次のように記述されてもよい:
…次のとおりである/…下記が適用される:
-もし次の条件のすべてが真であれば、陳述0:
-条件0a
-条件0b
-そうでない場合、次の条件のうち一つまたは複数が真であれば、陳述1
-条件1a
-条件1b
-…
-それ以外の場合には、陳述n。
テキストでは、数学的に次の形:
if(条件0)
陳述0
if(条件1)
陳述1
で記述される論理演算の陳述は、次のように記述されてもよい:
条件0の場合、陳述0
条件1の場合、陳述1。
本開示の実施形態は、主にビデオ符号化に基づいて説明されてきたが、符号化システム10、エンコーダ20およびデコーダ30(および対応してシステム10)の実施形態、ならびに本明細書に記載される他の実施形態は、静止ピクチャーの処理または符号化、すなわち、ビデオ符号化におけるような何らかの先行または連続するピクチャーから独立した個々のピクチャーの処理または符号化のために構成されてもよいことに注意しておくべきである。一般に、ピクチャー処理符号化が単一のピクチャー17に限定される場合、インター予測ユニット244(エンコーダ)および344(デコーダ)だけは利用可能でないことがある。ビデオ・エンコーダ20およびビデオ・デコーダ30の他のすべての機能(ツールまたは技術とも称される)は、静止ピクチャー処理についても等しく使用されうる。他の機能とは、たとえば、残差計算204/304、変換206、量子化208、逆量子化210/310、(逆)変換212/312、分割262、イントラ予測254/354、および/またはループ・フィルタリング220、320、およびエントロピー符号化270、およびエントロピー復号304である。
たとえばエンコーダ20およびデコーダ30の実施形態、ならびに、たとえばエンコーダ20およびデコーダ30を参照して本明細書に記載される機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせで実装されうる。ソフトウェアで実装される場合、機能は、一つまたは複数の命令またはコードとして、コンピュータ読み取り可能媒体に記憶されるかまたは通信媒体を通じて伝送され、ハードウェア・ベースの処理ユニットによって実行されてもよい。コンピュータ読み取り可能媒体は、データ記憶媒体のような有形の媒体に対応するコンピュータ読み取り可能記憶媒体、または、たとえば通信プロトコルに従って、ある場所から他の場所へのコンピュータ・プログラムの転送を容易にする任意の媒体を含む通信媒体を含んでいてもよい。このようにして、コンピュータ読み取り可能媒体は、一般に、(1)非一時的である有形のコンピュータ読み取り可能記憶媒体、または(2)信号または搬送波のような通信媒体に対応しうる。データ記憶媒体は、本開示に記載される技術の実装のための命令、コードおよび/またはデータ構造を取り出すために、一つまたは複数のコンピュータまたは一つまたは複数のプロセッサによってアクセスできる任意の利用可能な媒体でありうる。コンピュータ・プログラム製品は、コンピュータ読み取り可能媒体を含みうる。
例として、そして限定するものではないが、そのようなコンピュータ読み取り可能記憶媒体は、RAM、ROM、EEPROM、CD-ROMまたは他の光ディスク記憶装置、磁気ディスク記憶装置、または他の磁気記憶デバイス、フラッシュメモリ、または命令またはデータ構造の形で所望のプログラムコードを記憶するために使用でき、コンピュータによってアクセスされることができる他の任意の媒体を含むことができる。また、任意の接続は、適切にコンピュータ読み取り可能媒体と称される。たとえば、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者線(DSL)、または赤外線、電波、およびマイクロ波のような無線技術を用いて、ウェブサイト、サーバー、または他のリモートソースから命令が送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、電波、およびマイクロ波のような無線技術は、媒体の定義に含まれる。しかしながら、コンピュータ読み取り可能記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的な媒体を含まず、代わりに非一時的で有形の記憶媒体に向けられることが理解されるべきである。本明細書で使用されるところのディスク(diskおよびdisc)は、コンパクトディスク(CD)、レーザーディスク、光ディスク、デジタル多用途ディスク(DVD)、フロッピーディスクおよびブルーレイディスクを含み、ディスク(disk)は通例、磁気的にデータを再生し、一方、ディスク(disc)はレーザーを用いて光学的にデータを再生する。上記の組み合わせも、コンピュータ読み取り可能媒体の範囲内に含まれるべきである。
命令は、一つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の同等の集積されたもしくは離散的な論理回路などの一つまたは複数のプロセッサによって実行されうる。よって、本明細書で使用される「プロセッサ」という用語は、前述の構造、または本明細書に記載される技術の実装のために好適な任意の他の構造のいずれかを指しうる。さらに、いくつかの側面では、本明細書に記載される機能は、エンコードおよびデコードのために構成される専用ハードウェアおよび/またはソフトウェア・モジュール内で提供されてもよく、または組み合わされたコーデックに組み込まれてもよい。また、これらの技術は、一つまたは複数の回路または論理素子で完全に実装されることができる。
本開示の技術は、ワイヤレスハンドセット、集積回路(IC)、または一組のIC(たとえば、チップセット)を含む、幅広い多様なデバイスまたは装置で実装されうる。本開示では、開示された技術を実行するように構成された装置の機能的側面を強調するために、さまざまなコンポーネント、モジュール、またはユニットが記載されるが、これらは必ずしも異なるハードウェア・ユニットによる実現を要求するものではない。むしろ、上述のように、さまざまなユニットは、コーデック・ハードウェア・ユニット内で組み合わされてもよく、または、上述のような一つまたは複数のプロセッサを好適なソフトウェアおよび/またはファームウェアとの関連で含む、相互運用されるハードウェア・ユニットの集まりによって提供されてもよい。

Claims (15)

  1. エンコード装置によって実装される符号化方法であって:
    エンコードされるべき現在の符号化ツリー単位CTUがCTU行の最初のCTUである場合(1610)、ブロック内コピーIBC参照のための専用バッファからの参照サンプルをデフォルト値に初期化するステップ(1620)と;
    前記専用バッファからの参照サンプルに基づいて、現在のCTU内の現在のブロックについての予測されたサンプル値を取得するステップ(1630)と;
    前記現在のブロックについての前記予測されたサンプル値に基づいて、前記現在のブロックについてのIBCブロック・ベクトルをエンコードするステップ(1640)とを含む、
    方法。
  2. 前記デフォルト値が-1である、請求項1に記載の方法。
  3. エンコード装置によって実装される符号化方法であって:
    符号化ツリー単位CTUのある領域についての専用バッファを、エンコードされるべき現在の符号化ブロックが前記CTUの前記領域内の最初の符号化ブロックである場合に、初期化するステップと;
    前記現在のブロックがIBCモードを使用して予測される場合、前記現在のブロックについてのIBCブロック・ベクトルを取得するステップと;
    前記専用バッファからの参照サンプルおよび前記現在のブロックについての前記IBCブロック・ベクトルに基づいて、前記現在のブロックについての予測されたサンプル値を取得するステップとを含む、
    方法。
  4. 前記CTUの前記領域は、固定サイズの、重ならない領域である、請求項3に記載の方法。
  5. 前記領域は、仮想パイプライン処理単位VPDUである、請求項3または4に記載の方法。
  6. 前記領域のサイズは64×64である、請求項3ないし5のうちいずれか一項に記載の方法。
  7. エンコード装置によって実装される符号化方法であって:
    エンコードされるべき現在の符号化ツリー単位CTUがピクチャーの最初のCTUである場合に、ブロック内コピーIBC参照のための専用バッファを初期化するステップと;
    前記現在のCTU内の現在のブロックがIBCモードを使用して予測される場合に、前記現在のブロックについてのIBCブロック・ベクトルを取得するステップと;
    前記専用バッファからの参照サンプルおよび前記現在のブロックについての前記IBCブロック・ベクトルに基づいて、前記現在のブロックについての予測されたサンプル値を取得するステップとを含む、
    方法。
  8. 前記専用バッファからの前記参照サンプルは、デフォルト値に初期化される、請求項7に記載の方法。
  9. 前記デフォルト値は-1である、請求項8記載の方法。
  10. エンコード装置によって実装される符号化方法であって:
    現在のブロックが現在の符号化ツリー単位CTU内の最初の符号化ブロックである場合、ブロック内コピーIBC参照のための専用バッファを初期化するステップであって、前記CTUはCTU行の最初のCTUである、ステップと;
    前記現在のCTU内の現在のブロックがIBCモードを用いて予測される場合に、前記現在のブロックについてのIBCブロック・ベクトルを取得するステップと;
    前記専用バッファからの参照サンプルおよび前記現在のブロックについての前記IBCブロック・ベクトルに基づいて、前記現在のブロックについての予測されたサンプル値を取得するステップとを含む、
    方法。
  11. 前記専用バッファからの前記参照サンプルは、デフォルト値に初期化される、請求項10に記載の方法。
  12. 前記デフォルト値は-1である、請求項11に記載の方法。
  13. 請求項1ないし12のうちいずれか一項に記載の方法を実行するための処理回路を有するエンコーダ(20)。
  14. IBC参照サンプルを記憶するための専用バッファをさらに有する、請求項13に記載のエンコーダ(20)。
  15. ンピュータに請求項1ないし12のうちいずれか一項に記載の方法を実行させるためのコンピュータ・プログラム。
JP2022112148A 2019-05-16 2022-07-13 ルーマおよびクロマ成分についてibc専用バッファおよびデフォルト値リフレッシュを使用するエンコーダ、デコーダおよび対応する方法 Active JP7375125B2 (ja)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201962849119P 2019-05-16 2019-05-16
US62/849,119 2019-05-16
EPPCT/EP2019/065540 2019-06-13
EP2019065540 2019-06-13
JP2021505861A JP7106744B2 (ja) 2019-05-16 2020-05-13 ルーマおよびクロマ成分についてibc専用バッファおよびデフォルト値リフレッシュを使用するエンコーダ、デコーダおよび対応する方法
PCT/CN2020/090053 WO2020228744A1 (en) 2019-05-16 2020-05-13 An encoder, a decoder and corresponding methods using ibc dedicated buffer and default value refreshing for luma and chroma component

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2021505861A Division JP7106744B2 (ja) 2019-05-16 2020-05-13 ルーマおよびクロマ成分についてibc専用バッファおよびデフォルト値リフレッシュを使用するエンコーダ、デコーダおよび対応する方法

Publications (2)

Publication Number Publication Date
JP2022140481A JP2022140481A (ja) 2022-09-26
JP7375125B2 true JP7375125B2 (ja) 2023-11-07

Family

ID=73289357

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2021505861A Active JP7106744B2 (ja) 2019-05-16 2020-05-13 ルーマおよびクロマ成分についてibc専用バッファおよびデフォルト値リフレッシュを使用するエンコーダ、デコーダおよび対応する方法
JP2022112148A Active JP7375125B2 (ja) 2019-05-16 2022-07-13 ルーマおよびクロマ成分についてibc専用バッファおよびデフォルト値リフレッシュを使用するエンコーダ、デコーダおよび対応する方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2021505861A Active JP7106744B2 (ja) 2019-05-16 2020-05-13 ルーマおよびクロマ成分についてibc専用バッファおよびデフォルト値リフレッシュを使用するエンコーダ、デコーダおよび対応する方法

Country Status (10)

Country Link
US (1) US11463709B2 (ja)
EP (1) EP3912348A4 (ja)
JP (2) JP7106744B2 (ja)
KR (2) KR102596735B1 (ja)
CN (2) CN113039798B (ja)
AU (1) AU2020276527A1 (ja)
BR (1) BR112021000935A2 (ja)
CA (1) CA3131289C (ja)
MX (1) MX2021001663A (ja)
WO (1) WO2020228744A1 (ja)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020156546A1 (en) 2019-02-02 2020-08-06 Beijing Bytedance Network Technology Co., Ltd. Prediction using extra-buffer samples for intra block copy in video coding
JP7405861B2 (ja) 2019-03-01 2023-12-26 北京字節跳動網絡技術有限公司 映像符号化におけるイントラブロックコピーのための方向に基づく予測
CN117640927A (zh) 2019-03-04 2024-03-01 北京字节跳动网络技术有限公司 视频编解码中的帧内块复制中的实施方式方面
WO2020253650A1 (en) * 2019-06-16 2020-12-24 Beijing Bytedance Network Technology Co., Ltd. Interaction between screen content coding tools and motion information
US11070816B2 (en) 2019-06-18 2021-07-20 Tencent America LLC Conversion of decoded block vector for intra picture block compensation
WO2020256105A1 (ja) * 2019-06-21 2020-12-24 株式会社Jvcケンウッド 動画像符号化装置、動画像符号化方法、及び動画像符号化プログラム、動画像復号装置、動画像復号方法及び動画像復号プログラム
CN115643413A (zh) * 2019-06-25 2023-01-24 Jvc建伍株式会社 动图像编码装置和方法、以及动图像解码装置和方法
MX2022000102A (es) * 2019-07-06 2022-02-03 Beijing Bytedance Network Tech Co Ltd Bufer de prediccion virtual para la copia intra-bloque en codificacion de video.
AU2020312053B2 (en) 2019-07-10 2023-09-14 Beijing Bytedance Network Technology Co., Ltd. Sample identification for intra block copy in video coding
EP3981146A4 (en) * 2019-07-11 2022-08-03 Beijing Bytedance Network Technology Co., Ltd. BITSTREAM CONFORMITY RESTRICTIONS FOR INTRA-BLOCK COPY IN VIDEO ENCODING
CN117499659A (zh) * 2019-07-25 2024-02-02 北京字节跳动网络技术有限公司 帧内块复制虚拟缓冲区的尺寸限制
EP3991423A4 (en) 2019-07-25 2022-09-07 Beijing Bytedance Network Technology Co., Ltd. MAPPING RESTRICTION FOR INTRABLOC COPY VIRTUAL BUFFER
CN117579825A (zh) 2019-09-05 2024-02-20 北京字节跳动网络技术有限公司 帧内块复制模式下块矢量的范围约束
KR20220064968A (ko) * 2019-09-23 2022-05-19 베이징 바이트댄스 네트워크 테크놀로지 컴퍼니, 리미티드 가상 파이프라인 데이터 유닛에 기초한 인트라 블록 복사 가상 버퍼의 설정
CN115362674A (zh) 2020-03-18 2022-11-18 抖音视界有限公司 帧内块复制缓冲区和调色板预测值更新
CN113556542B (zh) * 2021-07-16 2023-04-28 安谋科技(中国)有限公司 帧内块复制单元及方法
WO2024085656A1 (ko) * 2022-10-18 2024-04-25 주식회사 윌러스표준기술연구소 비디오 신호 처리 방법 및 이를 위한 장치

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160241875A1 (en) 2015-02-12 2016-08-18 Mediatek Inc. Method and Apparatus of Constrained Intra Block Copy for Coding Video
WO2017041692A1 (en) 2015-09-08 2017-03-16 Mediatek Inc. Method and system of decoded picture buffer for intra block copy mode
US20170280159A1 (en) 2014-09-01 2017-09-28 Hfi Innovation Inc. Method of Intra Picture Block Copy for Screen Content and Video Coding
US20180103260A1 (en) 2015-06-03 2018-04-12 Mediatek Inc. Method and Apparatus for Resource Sharing between Intra Block Copy Mode and Inter Prediction Mode in Video Coding Systems

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2013228045A1 (en) * 2013-09-13 2015-04-02 Canon Kabushiki Kaisha Method, apparatus and system for encoding and decoding video data
WO2015169200A1 (en) * 2014-05-06 2015-11-12 Mediatek Singapore Pte. Ltd. Method of block vector prediction for intra block copy mode coding
US10212445B2 (en) * 2014-10-09 2019-02-19 Qualcomm Incorporated Intra block copy prediction restrictions for parallel processing
KR102390073B1 (ko) * 2015-06-08 2022-04-25 브이아이디 스케일, 인크. 스크린 콘텐츠 코딩을 위한 인트라 블록 카피 모드
EP3456043A4 (en) * 2016-05-28 2019-11-27 MediaTek Inc. METHOD AND DEVICE FOR REFERENCING THE CURRENT IMAGE FOR VIDEO CODING USING AFFINER MOTION COMPENSATION
WO2018064948A1 (en) * 2016-10-04 2018-04-12 Mediatek Inc. Method and apparatus for intra chroma coding in image and video coding
US10743029B2 (en) * 2018-07-30 2020-08-11 Tencent America LLC Constraints on coding unit partition
US11683501B2 (en) * 2019-01-17 2023-06-20 Tencent America LLC Method and apparatus for video coding
US10904557B2 (en) * 2019-01-22 2021-01-26 Tencent America LLC Method and apparatus for video coding

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170280159A1 (en) 2014-09-01 2017-09-28 Hfi Innovation Inc. Method of Intra Picture Block Copy for Screen Content and Video Coding
US20160241875A1 (en) 2015-02-12 2016-08-18 Mediatek Inc. Method and Apparatus of Constrained Intra Block Copy for Coding Video
US20180103260A1 (en) 2015-06-03 2018-04-12 Mediatek Inc. Method and Apparatus for Resource Sharing between Intra Block Copy Mode and Inter Prediction Mode in Video Coding Systems
WO2017041692A1 (en) 2015-09-08 2017-03-16 Mediatek Inc. Method and system of decoded picture buffer for intra block copy mode

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
Chen-Yen Lai, et al.,CE8-related: A fixed updating order for IBC reference memory,Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11,JVET-N0096-v2,14th Meeting: Geneva, CH,2019年03月,pp.1-5
Han Gao, et al.,CE8-related: Dedicated IBC reference buffer without bitstream restrictions,Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11,JVET-O0248,15th Meeting: Gothenburg, SE,2019年06月,pp.1-7
Han Gao, et al.,Non-CE8: IBC Reference Memory for Arbitrary CTU Size,Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11,JVET-N0175-v2,14th Meeting: Geneva, CH,2019年03月,pp.1-7
Xiaozhong Xu, Xiang Li, Shan Liu, and Eric Chai,CE8: CPR reference memory reuse without increasing memory requirement (CE8.1.2a and CE8.1.2d),Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11,JVET-M0407-v3,13th Meeting: Marrakesh, MA,2019年01月,pp.1-8

Also Published As

Publication number Publication date
JP7106744B2 (ja) 2022-07-26
EP3912348A1 (en) 2021-11-24
KR20210018490A (ko) 2021-02-17
US20210152833A1 (en) 2021-05-20
KR102596735B1 (ko) 2023-11-01
AU2020276527A1 (en) 2021-09-09
WO2020228744A1 (en) 2020-11-19
US11463709B2 (en) 2022-10-04
JP2022140481A (ja) 2022-09-26
MX2021001663A (es) 2021-05-12
JP2021533644A (ja) 2021-12-02
CN113039798B (zh) 2024-03-26
BR112021000935A2 (pt) 2021-04-20
KR102431537B1 (ko) 2022-08-12
CA3131289A1 (en) 2020-11-19
CN113039798A (zh) 2021-06-25
EP3912348A4 (en) 2022-06-22
CN113840143A (zh) 2021-12-24
KR20220116339A (ko) 2022-08-22
CA3131289C (en) 2023-12-12

Similar Documents

Publication Publication Date Title
JP7375125B2 (ja) ルーマおよびクロマ成分についてibc専用バッファおよびデフォルト値リフレッシュを使用するエンコーダ、デコーダおよび対応する方法
JP7271683B2 (ja) エンコーダ、デコーダ、および対応するイントラ予測方法
US11070799B2 (en) Encoder, decoder and corresponding methods for intra prediction
JP7205038B2 (ja) 任意のctuサイズのためのibc検索範囲最適化を用いるエンコーダ、デコーダおよび対応する方法
JP7332703B2 (ja) クロマサブブロックのアフィンベースのインター予測のための方法及び装置
JP7366149B2 (ja) 行列ベースのイントラ予測と二次変換コア選択を調和させるエンコーダ、デコーダ、および対応する方法
US11388422B2 (en) Encoder, a decoder and corresponding methods related to intra prediction mode
JP7314300B2 (ja) イントラ予測のための方法および装置
US11729391B2 (en) Encoder, a decoder and corresponding methods simplifying signaling slice header syntax elements
JP2022551091A (ja) 幾何学的パーティション・モードのためのコーディング・プロセス
KR20220051399A (ko) 시퀀스 파라미터 세트에서의 서브픽처 시그널링을 위한, 인코더, 디코더 및 대응하는 방법
JP2023153193A (ja) クロミナンス量子化パラメータのシグナリングのための方法及び装置
JP2023126744A (ja) 幾何学的区分けモードのためのサンプルの距離の計算
US11876956B2 (en) Encoder, a decoder and corresponding methods for local illumination compensation
JP7267444B2 (ja) イントラ予測のためのイントラモードコーディングを使用するエンコーダ、デコーダ、および対応する方法
KR20220140858A (ko) 슬라이스에 대한 픽처 파티셔닝 정보를 시그널링하기 위한 디코더 및 대응하는 방법
RU2803063C2 (ru) Кодер, декодер и соответствующие способы, которые используются для процесса преобразования
US20220132150A1 (en) Motion field storage optimization for a line buffer
KR20210129180A (ko) 평면 모드를 위한 인트라 예측에 대한 복잡도 감소의 인코더, 디코더 및 대응하는 방법

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220804

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220804

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230620

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230919

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20231025

R150 Certificate of patent or registration of utility model

Ref document number: 7375125

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150