特開2019-83541(P2019-83541A)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 寰發股▲ふん▼有限公司の特許一覧

特開2019-83541イントラブロックコピー検索と補償範囲の方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】特開2019-83541(P2019-83541A)
(43)【公開日】2019年5月30日
(54)【発明の名称】イントラブロックコピー検索と補償範囲の方法
(51)【国際特許分類】
   H04N 19/593 20140101AFI20190510BHJP
   H04N 19/436 20140101ALI20190510BHJP
   H04N 19/70 20140101ALI20190510BHJP
【FI】
   H04N19/593
   H04N19/436
   H04N19/70
【審査請求】有
【請求項の数】12
【出願形態】OL
【全頁数】25
(21)【出願番号】特願2019-2881(P2019-2881)
(22)【出願日】2019年1月10日
(62)【分割の表示】特願2017-22969(P2017-22969)の分割
【原出願日】2015年7月7日
(31)【優先権主張番号】62/021,291
(32)【優先日】2014年7月7日
(33)【優先権主張国】US
(31)【優先権主張番号】62/025,122
(32)【優先日】2014年7月16日
(33)【優先権主張国】US
(31)【優先権主張番号】62/045,620
(32)【優先日】2014年9月4日
(33)【優先権主張国】US
(31)【優先権主張番号】62/094,140
(32)【優先日】2014年12月19日
(33)【優先権主張国】US
(71)【出願人】
【識別番号】516251901
【氏名又は名称】寰發股▲ふん▼有限公司
【氏名又は名称原語表記】HFI Innovation Inc.
(74)【代理人】
【識別番号】110000486
【氏名又は名称】とこしえ特許業務法人
(72)【発明者】
【氏名】リウ,シャン
(72)【発明者】
【氏名】ライ,ワン−リン
(72)【発明者】
【氏名】チャン,ツ−デァ
(72)【発明者】
【氏名】チェン,チン−エ
(72)【発明者】
【氏名】ファン,ユ−ウェン
(72)【発明者】
【氏名】シュウ,チ−ウェイ
(72)【発明者】
【氏名】シュウ,シャオジョン
【テーマコード(参考)】
5C159
【Fターム(参考)】
5C159KK13
5C159MA04
5C159MA05
5C159MA21
5C159MC11
5C159ME01
5C159NN01
5C159RB09
5C159UA02
5C159UA05
5C159UA33
(57)【要約】      (修正有)
【課題】ピクチャにスライスベースあるいはタイルベース並列処理を用いたビデオ復号の方法を提供する。
【解決手段】ビデオ復号の方法は、現在のスライスあるいは現在のタイルで、現在のブロックに選択される場合に、ビデオビットストリームから、現在のブロックの符号化ブロックを決定する工程及び選択された有効なリファレンス領域から参照ブロックを選択する工程であって、選択された有効なリファレンス領域は、現在のスライスあるいは現在のタイル中の現在のブロックより前の1つ以上の予め再構成されたブロックを有する工程と、参照ブロックの一つ以上のサンプルが有効でない場合、参照ブロックの1つ以上の利用できないサンプルを代替する工程と、参照ブロックを予測因子として用い、IntraBCモードにしたがって符号化ブロックから現在のブロックを再構築する工程とを行う。
【選択図】図15
【特許請求の範囲】
【請求項1】
ピクチャにスライスベースあるいはタイルベース並列処理を用いたビデオ復号の方法において、
現在のピクチャから分割されるとともに、同時に符号化される複数のスライスあるいはタイルに関連するビデオビットストリームを受信する工程を含み、
IntraBCモード(イントラブロックコピーモード)が、現在のスライスあるいは現在のタイルで、現在のブロックに選択される場合に、
前記ビデオビットストリームから、前記現在のブロックの符号化ブロックを決定する工程、及び、
選択された有効なリファレンス領域から参照ブロックを選択する工程であって、前記選択された有効なリファレンス領域は、前記現在のスライスあるいは前記現在のタイル中の前記現在のブロックより前の1つ以上の予め再構成されたブロックを有する工程と、
前記参照ブロックの一つ以上のサンプルが有効でない場合、前記参照ブロックの1つ以上の利用できないサンプルを代替する工程と、
前記参照ブロックを予測因子として用い、前記IntraBCモードにしたがって前記符号化ブロックから前記現在のブロックを再構築する工程とを行う
ことを特徴とする方法。
【請求項2】
前記参照ブロックの一つ以上のサンプルが有効でない場合、隣接する有効なサンプルからの1つ以上のパディングサンプルが、前記参照ブロックの1つ以上の利用できないサンプルを代替するために用いられることを特徴とする請求項1に記載の方法。
【請求項3】
前記参照ブロックの1つ以上のサンプルが有効でない場合、有効でない前記参照ブロックの1つ以上のサンプルあるいは全体の参照ブロックが、所定の値により代替されることを特徴とする請求項1に記載の方法。
【請求項4】
前記所定の値は128に対応することを特徴とする請求項3に記載の方法。
【請求項5】
復号プロセスが前記現在のピクチャに開始される前に、現在のピクチャに再構成されたサンプルが、前記所定の値に初期化され、
前記参照ブロックの1つ以上のサンプルが有効でない場合、前記参照ブロックの前記1つ以上のサンプルは、前記所定の値を有することを特徴とする請求項3に記載の方法。
【請求項6】
前記所定の値は128に対応することを特徴とする請求項5に記載の方法。
【請求項7】
前記所定の値は、高レベルの前記ビデオビットストリームでシグナリングされる主要な色のリストから選択されることを特徴とする請求項3に記載の方法。
【請求項8】
前記高レベルのビデオビットストリームは、スライスレベル、ピクチャレベルあるいはシーケンスレベルに対応することを特徴とする請求項7に記載の方法。
【請求項9】
主要の色の前記リストは、数値N、続いて、N個の主要な色値を用いてシグナリングされ、数値Nは、主要な色値に対応することを特徴とする請求項7に記載の方法。
【請求項10】
前記現在のブロックがInter-スライスにあり、および、前記参照ブロックの一つ以上のサンプルが有効でない場合、有効でない前記参照ブロックの前記1つ以上のサンプル又は参照ブロック全体は、前記現在のブロックと配列される参照フレーム中における、1つ以上の一時的サンプルあるいは時間的参照ブロックの全体ブロックにより代替されることを特徴とする請求項1に記載の方法。
【請求項11】
前記現在のブロックがInter-スライスにあり、且つ、前記参照ブロックの一つ以上のサンプルが有効でない場合、有効でない前記参照ブロックの前記一つ以上のサンプル又は参照ブロック全体は、前記参照ブロックと配列される参照フレーム中における、1つ以上の一時的サンプルあるいは時間的参照ブロックの全体ブロックにより代替されることを特徴とする請求項1に記載の方法。
【請求項12】
ピクチャにスライスベースあるいはタイルベース並列処理を用いたビデオ復号の装置において、
1つ以上の回路を有し、
前記回路は、
現在のピクチャから分割されるとともに、同時に符号化される複数のスライスあるいはタイルに関連するビデオビットストリームを受信し、
IntraBCモード(イントラブロックコピーモード)が、現在のスライスあるいは現在のタイルで、現在のブロックに選択される場合に、
前記ビデオビットストリームから、前記現在のブロックの符号化ブロックを決定し、かつ、
選択された有効なリファレンス領域から参照ブロックを選択し、前記選択された有効なリファレンス領域は、前記現在のスライスあるいは前記現在のタイル中の前記現在のブロックより前の1つ以上の予め再構成されたブロックを有し、
前記参照ブロックの一つ以上のサンプルが有効でない場合、前記参照ブロックの1つ以上の利用できないサンプルを代替し、
前記参照ブロックを予測因子として用い、前記IntraBCモードにしたがって前記符号化ブロックから前記現在のブロックを再構築する装置。
【発明の詳細な説明】
【技術分野】
【0001】
この出願は、2014年7月7日に出願された米国特許仮出願番号62/021291および2014年7月16日に出願された米国特許仮出願番号62/025122および2014年12月19日に出願された米国特許仮出願番号62/094140から、優先権を主張する。本発明は、さらに、2014年9月4日に出願された米国特許仮出願番号62/045620から、優先権を主張する。よって、その内容は引用によって本願に援用される。
【0002】
本発明は、スクリーンコンテンツ向け符号化あるいはビデオ符号化のイントラブロックコピー(IntraBC)モードを用いたビデオ符号化に関するものであって、特に、本発明は、イントラブロックコピー(IntraBC)符号化モードが選択されるとき、スライス/タイルベース並列処理あるいは波状並列処理をサポートする技術に関するものである。
【背景技術】
【0003】
高効率ビデオコーディング(HEVC)標準の範囲拡張(RExt)あるいはスクリーンコンテンツ向け符号化の最近の動向において、これらのツールの目的は、高いビット深さ(たとえば、10、12、14および16)の効果的な圧縮ソリューションを提供することで、YUV420カラーフォーマット以外のカラーフォーマット(たとえば、YU422,YUV444およびRGB444)がすでに開発されて、これらのコンテンツの符号化効率を改善している。イントラブロックにおいて、従来のアプローチによるイントラ予測は、隣接するブロックから再構成された画素に基づいた予測を用いて実行される。イントラ予測は、垂直モード、水平モードおよび各種角度予測モードを含む1組のIntraモードからIntraモードを選択する。HEVC範囲拡張およびスクリーンコンテンツ向け符号化において、イントラブロックコピー(IntraBC)という名の新しい符号化モードが用いられている。IntraBC技術は、Budagaviにより、AHG8で提出された: Video coding using Intra motion compensation, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11, 13th Meeting: Incheon, KR, 18-26 Apr. 2013, Document: JCTVC-M0350 (以下、JCTVC-M0350)を参照されたい。JCTVC-M0350による例が図1に示され、現在の符号化ユニット (CU、110)が、MC(動き補償)を用いて符号化される。予測ブロック (120)は、現在のCUおよび変位ベクトル (112)により配置される。この例において、検索領域は、現在のCTU (coding tree unit)、左のCTUおよび左側の第2CTUに限定される。予測ブロックは、すでに再構成された領域から得られる。その後、動きベクトル (MV)とも称される変位ベクトル、および、現在のCUの余剰が符号化される。HEVCは、CTUとCUブロック構造を基本単位とし、ビデオデータを符号化することが知られている。各ピクチャはCTUに分割され、且つ、各CTUはCUに分割される。予測位相期間中、各CUは、prediction units (PUs)という名の複数のブロックに分割されて、予測プロセスを実行する。予測余剰が各CUに形成された後、各CUに関連する余剰は、transform units (TUs)という名の複数のブロックに分割されて、変換 (たとえば、離散余弦変換 (DCT))を適用する。
【0004】
JCTVC-M0350において、Intra MCは、少なくとも以下の領域中でInter 予測に用いられる動き補償と異なる:
・MVは、Intra MC(つまり、水平あるいは垂直)の1-Dに制限され、Inter 予測は2-D 動き推定を用いる。
・2値化は、Intra MCの固定長さで、Inter 予測は指数関数-Golombを用いる。
・Intra MCは、新しい構文要素を導入して、MVが、水平あるいは垂直か伝達する。
【0005】
JCTVC-M0350に基づいて、Pang等により、Non-RCE3で、いくつかの修正が行われている: Intra Motion Compensation with 2-D MVs, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11, 14th Meeting: Vienna, AT, 25 July - 2 Aug. 2013, Document: JCTVC-N0256 (以下、JCTVC- N0256)。まず、Intra MCが拡張されて、2-D MVsをサポートするので、両MVコンポーネンツは、同時に非ゼロになる。これは、本来のアプローチよりも、Intra MCにさらなるフレキシブル性を提供し、MVは、厳密に、水平あるいは垂直に制約される。
【0006】
JCTVC-N0256において、2個のMV符号化方法が開示されている:
・方法 1 動きベクトル予測. 左側あるいは上方のMVがMV予測因子として選択されて、得られた動きベクトル差 (MVD)が符号化される。フラグが用いられて、MVDがゼロであるか示す。MVDがゼロでない場合、第三順位の指数関数-Golomb 符号が用いられて、残りの絶対レベルのMVDを符号化する。別のフラグが用いられて、サインを符号化する。
・方法 2 動きベクトル予測無し. MVが、HEVC中のMVDに用いられる指数関数-Golomb 符号を用いて符号化される。
【0007】
JCTVC-N0256で開示されるもう1つの差異は、2-D Intra MCは、さらに、経路を考慮したアプローチと組み合わされることである:
1. 補間フィルターが用いられない,
2. MV検索領域が制限される。2個のケースが開示される:
a. 検索領域は、現在のCTUおよび左のCTUである、あるいは、
b. 検索領域は、現在のCTUおよび左のCTUの最右の4カラムサンプルである。
【0008】
JCTVC-N0256において提案される方法において、2-D Intra MC、補間フィルターの除去、現在のCTUおよび左のCTUに制限される検索領域が、新しいバージョンのドラフト標準に採用されている。
【0009】
映像符号化国際標準のHEVC標準化の共同チーム (JCT-VC)による近年のさらなる発展において、JCTVC-Q0031 (Chen et al., Description of screen content coding technology proposal by Qualcomm, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11, 17th Meeting: Valencia, ES, 27 March - 4 April 2014, Document: JCTVC- Q0031) and JCTVC-Q0035 (Li et al., Description of screen content coding technology proposal by Microsoft, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG16 WP3 and ISO/IEC JTC1/SC29/WG11, 17th Meeting: Valencia, ES, 27 March - 4 April 2014, Document: JCTVC- Q0035)中で、既に、フルフレーム IntraBC が開示されている。フルフレーム IntraBC は、検索領域制限を排除して、IntraBCの符号化効率をさらに改善する。つまり、全ての符号化ブロックは、現在のCUと全ての前符号化CU間のデータ依存をもたらす現在のCUにより参照される。フルフレーム IntraBC は元のIntraBCより効率がよいが、ピクチャの復号、特に、HEVCにおけるタイルプロセスあるいは波状並列処理 (WPP)を有効にするとき、このデータ依存は、並列処理ができないようにする。
【0010】
WPPによる並列性が図2に説明され、ピクチャ中のビデオブロックが、ロウごとに処理される。2個のロウを並列に処理することができるようにするために、各ロウは、その上のロウよりも遅くにブロックを開始する。その結果、“curr. CTU 0”, “curr. CTU 1”, “curr. CTU 2” と “curr. CTU 3”として示されるブロックは、各種CTUロウ中で現在処理されるブロックである。これらの現在処理されるブロックは、同時に処理される。同じロウ中の各現在のブロックの左側ブロックは、既に処理されている。HEVCにおいて、このような並列化戦略は、“波状並列処理” (WPP:wavefron parallel process)と称される。これらの現在処理されるブロックは、本開示において、 “波面”と称される。フルフレーム IntraBC中のWPPをサポートするため、現在の IntraBC符号化ブロック (たとえば、現在のCTU)は、まだ処理されていない領域における任意のリファレンスを参照することができない。
【0011】
これにより、フルフレーム IntraBC モードにおけるデータ依存を排除あるいは減少させて、タイルとWPPの並列処理を可能にする方法を発展させることが望まれる。
【0012】
SCM-2.0(Joshi et al., Screen content coding test model 2 (SCM 2), Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP3 and ISO/IEC JTC 1/SC29/WG11, 18th Meeting: Sapporo, JP, 30 June - 9 July 2014, Document: JCTVC-R1014)中、JCTVC-R0309(Pang, et al., Non-SCCE1: Combination of JCTVC-R0185 and JCTVC-R0203, Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP3 and ISO/IEC JTC 1/SC29/WG11, 18th Meeting: Sapporo, JP, 30 June - 9 July 2014, Document: JCTVC-R0309)にしたがって、ブロックベクトル (BV)符号化が修正されて、隣接するBVおよび符号化BVをBV予測因子 (BVP:block vector predictor)として用いる。BV予測因子は、HEVCにおける適応動きベクトル予測 (AMVP)スキームに類似する方式で得られる。予測因子候補リストは、図3に示される優先順序にしたがって、空間的に隣接するブロック a1 と b1 で、BVの有効性をまず確認することにより構成される。空間的隣接ブロックがどちらもブロックベクトルを含まない場合、最後の2個の符号化BVが用いられて、ブロックベクトル候補リストを満たすので、リストは、2個の異なるエントリーを含む。最後の2個の符号化BVは、(-2*CU_width, 0)および (-CU_width, 0)で初期化される。前もって符号化されたBVを保存するラインバッファの必要性をなくすため、空間的に隣接するブロック a1 と b1および現在のCTU外の最後のBV中の任意の1つは、有効でないと認識される。最後の2個の符号化BVは、各CTUに対し、(0, 0)にリセットされて、データ依存を回避する。
【0013】
また、HEVCにおいて、統合候補が、Inter 符号化スライス中の現在の符号化ブロックの空間的/一時的隣接ブロックから生成される。merge_flag が用いられて、現在のブロックがその候補の1つに統合されるかどうか伝達する。そうである場合、別のインデックスが用いられて、どの候補がw Merge モードに用いられるか伝達する。たとえば、図3に示される候補ブロック a1 が、用いられる候補としてシグナリングされる場合、現在のブロックは、ブロック a1.中のそれらと同じ動きベクトルおよびリファレンス画像を共有する。
【0014】
Merge 候補のいくつかが有効でない (たとえば、存在しないあるいはInter モードでない)場合、追加候補が挿入される。追加候補挿入後、Merge 候補リストがまだ十分でない場合、0に等しいrefIdx (つまり、リファレンス画像インデックス)ゼロ動きベクトルが用いられて、全ての空の候補を満たす。
【0015】
以下の2種の追加候補が挿入される。
1. 結合型双予測 Merge 候補 (候補タイプ1)、および、
2. 零ベクトル Merge/AMVP 候補 (候補タイプ2)
【0016】
タイプ1の追加候補の後、タイプ-2の追加候補が挿入される。候補タイプ1において、結合型双予測 Merge 候補は、本来の Merge 候補を結合することにより生成される。特に、mvL0 と refIdxL0、あるいは、mvL1 と refIdxL1を有する2個の本来の候補が用いられて、双予測 Merge 候補を生成する。mvL0 は、リスト0中の動きベクトルを表し、refIdxL0 は、リスト0において、リファレンス画像インデックスを表す。同様に、mvL1 は、リスト1中の動きベクトルを表し、refIdxL1 は、リスト1中のリファレンス画像インデックスを示す。
【0017】
候補タイプ2において、零ベクトルMerge/AMVP 候補は、零ベクトルと参照できるリファレンスインデックスを結合することにより生成される。零ベクトル候補が重複しない場合、Merge/AMVP 候補セットに加えられる。
【0018】
フルフレーム IntraBC モードは、パフォーマンスを大幅に改善し、現在処理されるブロックの参照ブロックは有効ではないので、スライス/タイルベース並列処理あるいは波状並列処理の問題が存在している。これにより、有効でないリファレンスデータに関連する問題を克服する方法が必要とされる。
【発明の概要】
【発明が解決しようとする課題】
【0019】
本発明によるビデオ符号化システムにおけるピクチャのIntraBC モード (イントラブロックコピーモード)符号化を用いたビデオ符号化の方法を提供する。
【課題を解決するための手段】
【0020】
IntraBC モード (イントラブロックコピーモード)が、現在の処理領域において、現在の作業ブロックに選択される場合、有効なはしご形状のリファレンス領域からの参照ブロックは、現在の処理領域中の現在の作業ブロックより前(before)の1つ以上の予め処理済みブロック(previously processed block)、および、1つ以上の前処理領域中の対応する前作業ブロックより前の1つ以上の予め処理済みブロックを有する。第1前CTUロウ(first previous CTU row)より遠く、現在のCTUロウからさらに遠い1つのCTUロウである第2前CTUロウ(second previous CTU row)より前の作業ブロックの位置は、通常、第1前CTUロウより前の作業ブロックと同じ垂直位置あるいは垂直右側の位置である。現在のCTUロウ上の前CTUロウより前の作業ブロックの位置は、通常、現在の作業ブロックと同じ垂直位置または垂直右側の位置である。これにより、有効なリファレンス領域は、はしご形状の領域を形成する。現在の作業ブロックは、参照ブロックを予測因子として、IntraBC モードにしたがって、符号化あるいは復号される。各ブロックは符号化ユニット (CU)に対応し、各処理領域はCTUロウに対応する。
【0021】
現在の作業ブロックに関連する参照ブロックの位置は、エンコーダ側で、ブロックベクトル (BV)を用いてシグナリングされて、デコーダは、BVを用いて、参照ブロックを配置することができる。有効なはしご形状のリファレンス領域は、最後の予め処理済みブロックから開始され、現在の処理領域中の現在の作業ブロックより前の全ての予め処理済みブロックを有する。有効なはしご形状のリファレンス領域は、さらに、最後の予め処理済みブロックから開始され、1つ以上の前処理領域中の1つ以上の各自の前作業ブロックより前の全ての予め処理済みブロックを有する。
【0022】
各種有効なはしご形状のリファレンス領域は、本発明の各種実施形態において開示される。たとえば、現在の作業ブロック (x_cur, y_cur)の有効なはしご形状のリファレンス領域は、(x_ref, y_ref)の予め処理済みブロックを有し、(x_ref, y_ref)は、以下の条件の1つを満たす:
・x_ref < x_cur および y_ref ≦ y_cur; および
・x_cur ≦ x_ref ≦ (x_cur + N x (y_cur - y_ref))および y_ref < y_cur,
Nは1に等しい。
【0023】
現在のピクチャが、複数のCTUロウに分割されて、波状並列処理 (WPP)を複数のCTUロウに適用し、現在の作業ブロックは現在の作業ブロックに対応し、各前作業ブロック(each previous working block)は各前波面ブロックに対応する。デコーダ側で、複数のCTUロウに関連するビデオビットストリームは、複数のWPPサブ-ビットストリームに対応し、各WPPサブ-ビットストリームは、各CTUロウに関連する。
【0024】
一ピクチャのスライスベースあるいはタイルベース並列処理を用いたビデオ符号化方法も開示される。IntraBC モード (イントラブロックコピーモード)が、現在のスライスあるいは現在のタイルにおいて、現在のブロックに選択される場合、選択された有効なリファレンス領域からの参照ブロックは、現在のスライスあるいは現在のタイルの現在のブロックが選択される前の1つ以上の予め処理済みブロックを含む。現在のブロックは、参照ブロックを予測因子として、IntraBC モードにしたがって、符号化あるいは復号される。現在のブロックに関連する参照ブロックの位置は、エンコーダ側で、ブロックベクトル (BV)を用いてシグナリングされるので、デコーダは、BVに基づいて、参照ブロックの位置を決定することができる。
【0025】
BVにより示される参照ブロックの任意の位置が、現在のスライスあるいは現在のタイル外側に位置する場合、BVはクリップBVにクリップされるので、クリップBVにより示される修正された参照ブロックは、現在のスライスあるいは現在のタイル中で全体的に配置される。タイルベース並列処理において、BVクリッピングがまず垂直に適用され、その後、水平に適用される。また、BVクリッピングがまず水平に適用され、その後、垂直に適用される。スライスベース並列処理において、垂直のBVクリッピングが適用される。
【0026】
本発明の実施形態は、参照ブロックの1つ以上のサンプルが有効でないときの状況を処理する。本実施形態において、隣接する有効なサンプルからの1つ以上の冗長サンプルが用いられて、参照ブロックの1つ以上の利用できないサンプルを代替する。別の実施形態において、利用できないサンプルまたは参照ブロック全体は、所定の値、たとえば、128により代替される。さらに別の実施形態において、復号プロセスが現在のピクチャに開始される前、現在のピクチャに再構成されたサンプルが所定の値に初期化され、参照ブロックの1つ以上のサンプルが有効でない場合、参照ブロックの1つ以上のサンプルは所定の値を有する。所定の値は、高レベルのビデオビットストリームでシグナリングされる主要な色のリスト、例えば、スライスレベル、ピクチャレベルあるいはシーケンスレベルから選択される。主要な色のリストは、数値N、続いて、N個の主要な色値を用いてシグナリングされ、数値Nは、主要な色値に対応する。
参照ブロックの1つ以上のサンプルが有効でなく、且つ、現在のブロックが Inter-スライスであるとき、利用できないサンプルあるいは参照ブロック全体は、現在のブロックと配列される時間的参照ブロックから、一時的リファレンスサンプルにより代替される。あるいは、利用できないサンプルあるいは参照ブロック全体は、参照ブロックと配列される時間的参照ブロックから、一時的リファレンスサンプルにより代替される。
【図面の簡単な説明】
【0027】
図1】イントラブロックコピー(IntraBC) モードによるIntra 動き補償の例を示す図で、水平変位ベクトルが用いられる。
図2】HEVC (高効率ビデオコーディング)によるWPP (波状並列処理)の並列性を示す図で、一ピクチャ中のビデオブロックが1ロウずつ処理される。
図3】優先順序にしたがって、空間的に隣接するブロック a1 および b1で、まず、BV有効性を確認することにより構成される予測因子候補リストの例を示す図である。
図4】HEVC (高効率ビデオコーディング)のWPP (波状並列処理)にしたがって、LCU-T, LCU-L, LCU-TRおよびLCU-TLを含む現在のCUおよび隣接するCU間にだけ存在するデータ依存を示す図である。
図5A】有効なリファレンス領域を示す図で、現在のLCUが文字 “C”により示され、現在のLCUの有効なリファレンス領域が、線状領域により示される。
図5B】有効なリファレンス領域を示す図で、現在のLCUが文字 “C”により示され、現在のLCUの有効なリファレンス領域が、線状領域により示される。
図5C】有効なリファレンス領域を示す図で、現在のLCUが文字 “C”により示され、現在のLCUの有効なリファレンス領域が、線状領域により示される。
図6A】各種制約下で、点領域に制約される現在のIntraBCブロックの検索と補償範囲を示す図である。
図6B】各種制約下で、点領域に制約される現在のIntraBCブロックの検索と補償範囲を示す図である。
図6C】各種制約下で、点領域に制約される現在のIntraBCブロックの検索と補償範囲を示す図である。
図6D】各種制約下で、点領域に制約される現在のIntraBCブロックの検索と補償範囲を示す図である。
図6E】各種制約下で、点領域に制約される現在のIntraBCブロックの検索と補償範囲を示す図である。
図6F】各種制約下で、点領域に制約される現在のIntraBCブロックの検索と補償範囲を示す図である。
図7】点領域に制約される現在の IntraBC ブロックの検索と補償範囲の別の例を示す図である。
図8A】ブロックベクトル (BV)予測因子が無効の参照ブロックに示される例を示す図である。
図8B】ブロックベクトル (BV)予測因子が無効の参照ブロックに示される例を示す図である。
図9】IntraBC モード符号化のタイルベース並列処理の例を示す図で、ピクチャが複数のタイルに分割され、各タイルは複数の符号化ツリーユニット(CTUs)から構成される。
図10】IntraBC モード符号化を用いたタイルベース並列処理における無効の参照ブロックに関連するブロックベクトル (BV)の例を示す図である。
図11】IntraBC モード符号化を用いたタイルベース並列処理のブロックベクトル (BV)クリッピングの例を示す図で、クリッピングプロセスがまず、垂直コンポーネントに、その後、水平コンポーネントに適用される。
図12】IntraBC モード符号化を用いたタイルベース並列処理のブロックベクトル (BV)クリッピングを示す図で、クリッピングプロセスが、まず、水平コンポーネントに、その後、垂直コンポーネントに適用される。
図13】IntraBC モード符号化を用いたスライスベース並列処理のブロックベクトル (BV)クリッピングを示す図で、クリッピングプロセスが垂直コンポーネントに適用される。
図14】本発明の実施形態による制限された検索範囲領域を組み込んだビデオエンコーダのIntraBC 符号化のフローチャートである。
図15】本発明の実施形態による制限された検索範囲領域を組み込んだビデオデコーダのIntraBC 符号化のフローチャートである。
図16】本発明の実施形態による制限された検索範囲領域を組み込んだスライス/タイルベース並列処理によるビデオエンコーダのIntraBC 符号化のフローチャートである。
図17】本発明の実施形態による制限された検索範囲領域を組み込んだスライス/タイルベース並列処理によるビデオデコーダのIntraBC 符号化のフローチャートである
【発明を実施するための形態】
【0028】
上述のように、フルフレーム IntraBC (イントラブロックコピー)モードは、大幅にパフォーマンスを改善することができる。しかし、フルフレーム IntraBCモードは、並列処理、たとえば、波状並列処理 (WPP)あるいはスライス/タイルベース並列処理をサポートすることができない。フルフレーム IntraBC モードの拡張した検索範囲のため、改善されたパフォーマンスを活用し、各種並列処理をサポートするため、本発明は、検索範囲を予め処理済みブロックに制限するあるいは予め処理済みブロックの任意のサンプルが有効でない場合、置換データを用いる方法を開示する。
【0029】
WPP-ベースプロセスのIntraBC
前述したように、波状並列処理 (WPP)は、HEVCの並列処理を達成する方法である。WPPにおいて、最後のLCUロウ中で、第1の2個LCUの構文解析プロセス終了後、各LCUロウのビットストリームは、独立して構文解析される。図4に示されるように、再構成ステージ期間中、データ依存は、LCU-T, LCU-L, LCU-TRおよび LCU-TLを含む現在のCUおよび隣接するCU間にだけ存在する。最後のLCUロウ中の右側上方LCU(つまり、図4中の LCU-TR)が復号された後、現在のLCUは、前LCUロウの再構成プロセスの完成を待つ必要なしに復号することができる。これにより、異なるLCUロウは、必要なレイテンシーで同時に復号される。一方、従来のフルフレーム IntraBC は、現在のCUおよび前の符号化CU間で、WPP中で、並行プロセスを妨げるデータ依存をもたらす。
【0030】
WPPにおける並行プロセスを達成するため、フルフレーム IntraBCプロセスの有効なリファレンス領域制約のこれらの例が開示される。以下の記述において、有効なリファレンス領域は、さらに、有効なはしご形状のリファレンス領域あるいは検索と補償範囲と参照される。有効なリファレンス領域制約の第1例によると、WPPが有効であるとき、同じLCUロウ中のその領域だけが、IntraBC プロセスに関連する。第1例は、図5A中に示され、現在のLCUは、文字 “C”により示され、現在のLCUの有効なリファレンス領域は、線状領域により示される。有効なリファレンス領域制約の第2例によると、図5Bに示されるように、左上部分のLCUおよびLCU-TRに属する1つのLCUカラムだけが、IntraBC プロセスで参照される。図5Cに示されるように、有効なリファレンス領域制約の第3例によると、有効なリファレンス領域は、現在のLCUロウおよびリファレンスLCUロウ間の距離にしたがって増加する。
【0031】
IntraBCプロセスの検索と補償範囲における制約を明確にする体系的なアプローチが以下のように開示される。現在のIntraBC ブロックの例の検索と補償範囲は、現在のCTU3(つまり、図6A中の“Curr. CTU3”)において、図6Aに示される点領域に制限される。現在のIntraBC ブロックは、以下の記述で、現在のIntraBC符号化ブロック、現在のビデオブロックあるいは現在の作業ブロックとも称される。現在のビデオブロックの位置あるいは現在のビデオブロックを含むCTUの位置は、 (x_cur, y_cur)として示される。参照ブロックと称されるビデオブロック (あるいは、HEVCコンテキスト中のCTU)の位置は、 (x_ref, y_ref)として示される。この実施形態による現在の IntraBC符号化ブロックの検索と補償範囲は、以下の2つの条件のいずれか1つに制限される:
a. x_ref < x_cur および y_ref ≦ y_cur, および
b. x_cur ≦ x_ref < (x_cur + N x (y_cur - y_ref)) および y_ref < y_cur.
【0032】
Nは、1以上の任意の正の整数である。図6Aに示される例において、Nは3に等しい。条件 a は、点領域610に示される参照ブロックに対応する。条件 b は、垂直距離, vd (つまり、vd = (y_cur - y_ref))に基づいて、リファレンス領域に対応する。vd=1の条件 b は、点領域620に示される参照ブロックに対応する。vd=2の条件 b は、点領域630に示される参照ブロックに対応する。vd=3の条件 b は、点領域640に示される参照ブロックに対応する。制約は、エンコーダおよびデコーダ両方に適用される。BVに関連する情報がシグナリングされて、参照ブロックの位置を示すので、さらに、ブロックベクトル(BVs)の範囲を制約する。
【0033】
図6Bは、N=2の条件a と bに対応する例を示す図である。図6Cは、別の例が、N=1の条件a および b に対応することを示す図である。
【0034】
別の実施形態において、類似条件であるリファレンス領域制約は以下に示される。
a. x_ref < x_cur および y_ref ≦ y_cur, および
b. x_cur ≦ x_ref ≦ (x_cur + N x (y_cur - y_ref)) および y_ref < y_cur.
【0035】
Nは、1以上の任意の正の整数である。図6Dは、N=1の条件c と d.による “curr. CTU 3”の検索と補償範囲の例を示す図である。
【0036】
別の実施形態において、現在の IntraBC符号化ブロックの検索と補償範囲は、以下の2つの条件のいずれか1つを満たす領域に制限され、
a. x_ref < x_cur および y_ref ≦y_cur, および
b. x_cur ≦ x_ref < (x_cur + N) および y_ref < y_cur。
【0037】
Nは、1以上の任意の正の整数である。図6Eは、“curr. CTU 3”の検索と補償範囲 (点領域により示される)を示し、Nは3に等しい。条件 e は、点領域650に示されるように参照ブロックに対応する。条件 f は、点領域660に示されるように、参照ブロックに対応する。制約は、エンコーダおよびデコーダ両方に適用される。BVに関連する情報はシグナリングされて、参照ブロックの位置を示すので、さらに、ブロックベクトル(BVs)の幅を制約する。
【0038】
図6Fは、N=1の条件e と f に対応する例を説明する図である。
【0039】
さらに別の実施形態において、上述の定義された範囲より小さい任意のリファレンス領域が用いられる。たとえば、現在の IntraBC符号化ブロックの検索と補償範囲は、以下の条件の1つに制限される:
(x_cur - N) < x_ref < x_cur および (y_cur - M) <y_ref ≦ y_cur, および
x_cur ≦ x_ref < (x_cur + N) および (y_cur - M) < y_ref < y_cur,
NとMは、任意の1以上の負数である。図7は、 N=3 と M=3の条件g と h による例を示す図である。
【0040】
図6A図6Eおよび図7に示されるように、有効なリファレンス領域は、はしご形状の領域に制限される。つまり、現在の作業ブロックより前の1つ以上の予め処理済みブロックは、IntraBC 予測の参照ブロックとして用いられる。任意の2個の隣接する前CTUロウにおいて、上方CTUロウ中の最後の予め処理済みブロックは、通常、下方CTUロウ中の最後の予め処理済みブロックの同じ垂直位置あるいは同じ垂直位置の後ろにある。現在のCTUロウ上のCTUロウの最後の予め処理済みブロックは、通常、現在の作業ブロックの同じ垂直位置あるいは同じ垂直位置の後ろにある。図6A図6Eおよび図7において、CTUロウの処理順序は、上から下である。これにより、前CTUロウは、現在のCTUロウの上である。さらに、各CTUロウの処理順序は左から右である。これにより、最後の予め処理済みブロックの同じ垂直位置の後ろというのは、最後の予め処理済みブロックの同じ垂直位置の右側であるという意味である。処理順序が変わる場合、有効なリファレンス領域も変化する。
【0041】
さらに、IntraBC 予測のはしご形状のリファレンス領域は、さらに、非-WPP設定に適用される。これにより、ピクチャは、並列処理の複数の領域に分割される必要性がない。はしご形状のリファレンス領域に対する参照ブロックの制限は、フルフレーム検索と比較して、検索複雑性を減少させる。しかし、さらに、フルフレーム検索に類似する改善されたパフォーマンスを提供することができる。
【0042】
ブロックベクトル制約
ブロックベクトルが無効のリファレンスデータ領域を指し示す問題を回避するため、BVクリッピングの方法が開示される。この発明において、クリッピング操作が、IntraBC ブロックベクトル (BV)予測因子および/またはIntraBC Merge 候補のBVに適用される。既存の設計において、IntraBC 符号化ブロックのブロックベクトルはいくつか制約がある。BVは、現在のピクチャ中のすでに再構成された領域()だけを示す。現在のスクリーンコンテンツ向け符号化 (SCC)において、同じ符号化ユニット中の再構成された領域は、IntraBC 補償に用いることができない。前もって符号化されたブロックベクトルが予測因子 (通常のIntraBC モードあるいはIntraBC Merge/Skip モードで)として用いられるとき、現在のブロックにとって有効なベクトルではない。図8A図8Bは、無効の予測因子が発生する状況の例を示す図である。破線矢印 (810と830)は、隣接するIntraBC 符号化ブロックのBVを示し、実線矢印 (820と840)は、現在のIntraBC ブロックの隣接するBVに基づくBV予測因子を示す。破線の長方形や正方形は、対応する IntraBC ブロックの参照ブロックに対応する。図8A図8Bにおいて、ブロックベクトル予測因子は、現在のブロックの空間的相隣によるものである。
【0043】
これにより、いくつかの制約をブロックベクトル予測因子に課す必要があり、よって、現在の IntraBC ブロックの有効なブロックベクトルになる。さらに特に、ブロックベクトル予測因子のX軸コンポーネントおよび/あるいはY軸コンポーネントは、いくつかの要求を満たさなくてはならない。表1において、2個のパラメータHoffsetおよびVoffset が定義されて、このような要求を記述する。
【表1】
【0044】
現在のブロックのBV予測因子が BV = (BV_x, BV_y)、且つ、BVのクリップバージョンがBV’ = (BV_x’, BV_y’)であると仮定する。以下の例は、クリッピング操作の各種ケースを開示する。
【0045】
ケース1: クリッピングの前、ブロックベクトルBVの両コンポーネンツが0以下である場合、BV_x > - Hoffset および BV_y > - Voffset 両方がtrueであるとき、クリッピング操作が要求される。
【0046】
本実施形態によると、クリッピングがケース1に必要である場合、BV_x’ = -Hoffset (および、BV_y’ = BV_y)は、クリッピング操作として用いられる。別の実施形態において、BV_y’ = -Voffset (and BV_x’ = BV_x)は、この場合、クリッピング操作として用いられる。さらに別の実施形態において、BV_y + Voffset, BV_x’ = -Hoffset (および BV_y’ = BV_y)より小さい(あるいは等しい)BV_x + Hoffset がクリッピング操作として用いられるとき; そうでなければ、この場合、BV_y’ = -Voffset (および、 BV_x’ = BV_x) は、クリッピング操作として用いられる。
【0047】
ケース2: BV_x が、クリッピング前に、0より大きい場合、 BV_y > - Voffsetがtrueであるとき、クリッピング操作が要求される。
【0048】
本実施形態にしたがって、この場合、クリッピングがケース2に必要なとき、BV_y’ = -Voffset (および、BV_x’ = BV_x) は、クリッピング操作として用いられる。別の実施形態において、この場合、BV_y’ = -Voffset (and BV_x’ = 0)は、クリッピング操作として用いられる。
【0049】
ケース3: BV_y がクリッピング前、0より大きい場合、BV_x > - Hoffset がtrueであるとき、クリッピング操作が要求される。
【0050】
クリッピングがケース3に必要なとき、BV_x’ = -Hoffset (および、BV_y’ = BV_y)は、この場合、本実施形態にしたがって、クリッピング操作として用いられる。別の実施形態において、BV_x’ = -Hoffset (and BV_y’ = 0)は、この場合、提案されるクリッピング操作として用いられる。
【0051】
スライス/タイルベース並列処理のブロックベクトル制約
スライス/タイルベースプロセスにおいて、1つのピクチャは、複数のスライスあるいはタイルに分割される。並列処理を達成するため、各スライスあるいはタイルは、独立して復号される。しかし、フルフレーム IntraBC モードは、現在のCUおよび予め符号化されたCU間にデータ依存をもたらし、データ依存は、スライスあるいはタイル境界を横切るとともに、並列処理を禁止するという意味を含む。これにより、本発明は、フルフレーム IntraBC モードにおける有効なリファレンス領域上に制約を課す。特に、フルフレーム IntraBC モードの有効なリファレンス領域は、現在のCUが属するスライスあるいはタイルの領域に制限される。この制約を用いることにより、フルフレーム IBC モードにより取り込まれる異なるスライスあるいはタイル間のデータ依存が排除される。よって、同じスライスあるいはタイル中に、現在のCUおよび前もって符号化されたCU間だけにデータ依存が存在する。制約は、エンコーダ側およびデコーダ側に適用される。エンコーダ側において、現在の IntraBC ブロックの検索と補償範囲は、現在のスライスあるいはタイルに制限される。デコーダ側において、現在のIntraBCブロックの補償範囲が、現在のスライスあるいはタイル内でない場合、ビットストリームは、適合ビットストリームではない。
【0052】
たとえば、図9に示されるように、1つのピクチャがCTUに分割され、且つ、ピクチャ中のCTUが、タイルに分割される。数値を有する各正方形は、スキャニング順序で、CTUに対応する。太線はタイル境界に対応する。この実施形態によると、依存状態は、タイル境界で破壊される。これにより、エンコーダおよびデコーダは制約が課される必要があるので、現在の IntraBC符号化ブロックのリファレンスデータが、現在のタイルによりもたらされる。たとえば、現在の IntraBC 符号化CTU46の参照ブロックは、同じタイル中の前もって符号化されたCTU41、42、43、44および45に対応する。BVあるいはクリッピングに与えられる制約がBVに適用されるとき、BV範囲が減少および/あるいはある冗長性が導入され、BV符号化はこれを考慮に入れて、符号化効率を改善する。
【0053】
マルチ-スライスあるいは複数の-タイル IntraBC 符号化において、現在の IntraBC符号化ブロックの補償ブロック (つまり、参照ブロック)は、完全に、現在のスライスあるいはタイル内にあるのではない。図10は、別のタイル中で、参照ブロックA (1020)を示す現在のIntraBC (IBC)符号化ブロックのBV(1010)の例を示す図で、これは、平行なタイルベース IntraBC プロセスを禁止する。タイル境界は太線で示される。
【0054】
本実施形態において、BVは、現在のIntraBC ブロックの有効なBVにクリップされる。2個の異なるクリッピングプロセスが用いられる。第1クリッピングプロセスにしたがって、垂直BVがまずクリップされるので、参照ブロック (1020)の上部に対応する位置は、Tile_y_min より小さくなり、参照ブロックの下部に対応する位置は Tile_y_max より大きくならない(この実施形態において、Tile_y_min は Tile_y_maxより小さい)。その後、水平BVがクリップされるので、参照ブロック (1020)の左側は Tile_x_min より小さくならず、参照ブロック (1020) の右側は Tile_x_maxより大きくならない (この実施形態において、Tile_x_minは、Tile_x_maxより小さい)。図11は、図10中の参照ブロックの例のクリッピングプロセスを説明する図である。垂直クリッピングの後、参照ブロックA (1020)は、位置B(1105)まで下がる。水平クリッピング後、現在のタイル中の新しい位置C (1120)が識別される。対応するクリップBV (1110)も図11中で示される。
【0055】
第2クリッピングプロセスは、まず、水平クリッピング、その後、垂直クリッピングを実行する。水平BVがクリップされるので、参照ブロックの左側に対応する位置は Tile_x_min より小さくならず、参照ブロックの右側に対応する位置はTile_x_maxより大きくならない。その後、垂直BVがクリップされて、参照ブロックの上部は Tile_y_min より小さくならず、参照ブロックの下部は、Tile_y_maxより大きくならない。図12は、図10の参照ブロックのクリッピングプロセスを説明する図である。水平クリッピング後、参照ブロックA (1020)は、位置D (1205)の左に移動する。垂直クリッピングの後、現在のタイル中の新しい位置E(1120)が識別される。対応するクリップBV (1210)も図12で示される。
【0056】
クリッピングプロセスは、さらに、スライスベース並列処理に適用される。図13は、スライスベース並列処理におけるクリッピングプロセスの例を示す図である。現在のピクチャは複数のスライスに分割される。現在の IntraBC符号化ブロックのBV(1310)が、現在のスライス外の参照ブロックA (1320)に向けられる場合、BVはクリップされる必要があるので、クリップBVは有効の参照ブロックを示す。垂直クリッピングの後、参照ブロックA (1320)はブロック位置B (1330)に移動する。そのブロックは現在のスライス中にあるので、ブロックBは最終クリップ参照ブロックである。
【0057】
非有効領域のIntraBC 補償
BVクリッピングが適用されたとしても、デコーダは、依然として、複数のスライス/タイルIntraBC プロセスにおいて、非有効領域を示す復号後のBVを有する。復号BVが非有効領域を示すとき、IntraBC ブロックをどのように補償するかに関するデコーダ操作は定義されない。無効のBVによるデコーダでの潜在的問題を回避するため、本発明の実施形態は、各種プロセスを開示して、無効のBVの潜在的問題を解決する。
【0058】
1. 非有効領域の処理:パディング
IntraBC 参照ブロックが非有効領域と重複する場合、非有効領域中のサンプルは、隣接する有効な画素を用いることにより埋められる。その後、パディングサンプルがIntraBC 補償に用いられる。
【0059】
2. 非-有効領域の処理: 所定の値を用いる
IntraBC 参照ブロックが非有効領域と重複する場合、非有効領域中のサンプルは、所定の値、たとえば、128に設定される。別の実施によると、符号化/復号前に、現在の再構成されたピクチャの画素値が所定の値 (たとえば、128)に設定される。一ブロックが符号化されるとともに再構成された後、再構成されたテクスチャがこのピクチャを満たす。IntraBC 参照ブロックが非有効領域と重複する場合、プリセット画素値が用いられる。
【0060】
3. 非有効領域の処理:有効でない領域中の全画素に所定の値を用いる
IntraBC 参照ブロックが非有効領域と重複する場合、有効でない領域中のサンプルは、所定の値、たとえば、128に設定される。
【0061】
4. 非有効領域の処理: Inter 参照ブロックを予測因子とする
現在のブロックが Inter-スライスにあり、且つ、IntraBC 参照ブロックが非有効領域と重複する場合、参照ブロックの非有効領域あるいは参照ブロック全体は、参照フレームのひとつ中の現在のブロックの配列されたブロックを参照することができる。たとえば、refIdx を有するピクチャが LIST_0中で0に等しい場合、現在のブロックと同じ位置を有するブロックが、IntraBC 予測因子として用いられる。
【0062】
別の実施形態によると、現在のブロックがInter-スライスにあり、且つ、IntraBC 参照ブロックが非有効領域と重複する場合、参照ブロックの非有効領域あるいは参照ブロック全体は、参照フレームの1つ中のIntraBC 参照ブロックの配列されたブロックを参照する。たとえば、refIdxを有するピクチャが LIST_0で0に等しい場合、 IntraBC 参照ブロックと同じ位置を有するブロックは、IntraBC 予測因子として用いられる。
【0063】
5.非有効領域の処理: 1組の所定の値の1つを用いる
別の実施形態によると、複数の主要な色は、ブロックレベルより高いレベルでシグナリングされる。たとえば、スライスヘッダーにおいて、パラメータNは、シグナリングされる主要な色の数を示し、Nは正の整数である。パラメータNがシグナリング後、N個の主要な色に対応するN個の画素値がシグナリングされる。IntraBC 参照ブロックが非有効領域と重複する場合、非有効領域中のテクスチャは、スライスヘッダーでシグナリングされる所定の主要な色値のひとつに設定される。さらに、重複領域中に用いられる色の選択は、スライスヘッダー中の主要な色のリストのインデックスによりシグナリングされる。複数の主要な色は、さらに、ピクチャレベルあるいはシーケンスレベルでシグナリングされる。
【0064】
さらに別の実施によると、IntraBC 参照ブロックが非有効領域と重複する場合、全体ブロックは、スライスヘッダーでシグナリングされる主要な色の1つを使用する。
【0065】
本発明の実施形態を組み込んだシステムのパフォーマンスとSCM 2.0に基づいたアンカーシステムと比較する。比較は、各種テストイメージの全-Intraモード、ランダムアクセスモードおよび低遅延Bピクチャモードを有する3種の異なる符号化設定下で実行される。本発明による実施形態は、SCM 2.0 アンカーシステムがフルフレーム IntraBC リファレンス領域を割り当てるとき、有効なリファレンス領域に制約を課す。第1比較において、この実施形態は、図6Bの有効なリファレンス領域制約に基づく。パフォーマンスは、この領域で既知のパフォーマンス測定であるBD-rateを単位として測定される。図6Bに基づく実施形態のパフォーマンスは、アンカーシステムよりわずかに悪い。BD-レートは、アンカーシステムより2.2% 悪い。図6Eに基づく実施形態のパフォーマンスは、アンカーシステムよりわずかに悪い。BD-レートは、アンカーシステムより2.9%悪い。
【0066】
図14は、本発明の本実施形態による制限された検索範囲領域を組み込んだビデオエンコーダのIntraBC符号化のフローチャートである。現在のピクチャの現在のCTUロウ中の現在の符号化ツリーユニット (CTU)中の現在の作業ブロックが、工程1410で受信される。現在の作業ブロックは、メモリ(たとえば、コンピュータメモリ、バッファ (RAMまたはDRAM)あるいは、その他の媒体)あるいは、プロセッサから検索される。工程1420において、参照ブロックは、有効なはしご形状のリファレンス領域から選択され、有効なはしご形状のリファレンス領域は、現在のCTUロウ中の現在の作業ブロックより前の1つ以上の予め処理済みブロック、および、1つ以上の前CTUロウ中の1つ以上の予め処理済みブロックを有する。第1前CTUロウより、現在のCTUロウからさらに遠い1つのCTUロウである第2前CTUロウの最後の予め処理済みブロックの位置は、通常、第1前CTUロウの最後の予め処理済みブロックの同じ垂直位置あるいは同じ垂直位置の後ろである。現在のCTUロウ上の前CTUロウの最後の予め処理済みブロックの位置は、通常、現在の作業ブロックの同じ垂直位置あるいは同じ垂直位置の後ろである。工程1430において、その後、現在の作業ブロックは、参照ブロックを予測因子として、IntraBC モードにしたがって符号化される。工程1440において、現在の作業ブロックの圧縮データを生成する。
【0067】
図15は、本発明の実施形態による制限された検索範囲領域を組み込んだビデオデコーダのIntraBC符号化のフローチャートである。現在のピクチャの複数のCTUロウに関連するビデオビットストリームが工程1510で受信され、各CTUロウは、複数のブロックを有する。ビデオビットストリームは、メモリ(たとえば、コンピュータメモリ、バッファ (RAMまたはDRAM)あるいはほかの媒体)あるいは、プロセッサから検索される。工程1520において、現在の作業ブロックの符号化ブロックが、現在のCTUロウを含むビデオビットストリームから決定される。工程1530において、参照ブロックは、有効なはしご形状のリファレンス領域から選択され、有効なはしご形状のリファレンス領域は、現在のCTUロウ中の現在の作業ブロックより前の1つ以上の前もって再構成されたブロック、および、1つ以上の前CTUロウ中の1つ以上の前もって構成されたブロックを有する。第1前CTUロウ(first previous CTU row)より、現在のCTUロウからさらに遠い1つのCTUロウである第2前CTUロウ(second previous CTU row)の最後の予め処理済みブロックの位置は、通常、第1前CTUロウの最後の予め処理済みブロックの同じ垂直位置あるいは同じ垂直位置の後ろである。現在のCTUロウ上の前のCTUロウの最後の予め処理済みブロックの位置は、通常、現在の作業ブロックの同じ垂直位置あるいは同じ垂直位置の後ろである。工程1540において、現在の作業ブロックは、IntraBC モードにしたがって、参照ブロックを予測因子として、符号化されたブロックから再構成される。
【0068】
図16は、本発明の本実施形態による制限された検索範囲領域を組み込んだスライス/タイルベース並列処理によるビデオエンコーダのIntraBC 符号化のフローチャートである。工程1610において、現在のピクチャが、複数のスライスあるいはタイルに分割されて、並列符号化プロセスを複数のスライスあるいはタイルに適用する。符号化プロセスは、現在のブロックがIntraBC モードで符号化される場合を説明する。工程1620において、参照ブロックは、有効なリファレンス領域から選択され、有効なリファレンス領域は、現在のスライスあるいは現在のタイルの現在のブロックより前の1つ以上の予め処理済みブロックを含む。工程1630において、現在のブロックは、参照ブロックを予測因子として、IntraBC モードにしたがって、符号化される。工程1640において、現在のスライスあるいは現在のタイルに対応する圧縮データは、エントロピー符号化を、現在のブロックの予測結果に適用することにより生成される。
【0069】
図17は、本発明の本実施形態による制限された検索範囲領域を組み込んだスライス/タイルベース並列処理によるビデオデコーダのIntraBC 符号化のフローチャートである。現在のピクチャから分割され、且つ、同時に符号化される複数のスライスあるいはタイルに関連するビデオビットストリームが、工程1710において受信される。復号プロセスが、現在のブロックがIntraBC モードで符号化される場合を説明する。工程1720において、現在のブロックの符号化ブロックが、ビデオビットストリームから決定される。工程1730において、参照ブロックは、有効なリファレンス領域から選択され、有効なリファレンス領域は、現在のスライスあるいは現在のタイルの現在のブロックより前の1つ以上の前もって再構成されたブロック(previously reconstructed blocks)を含む。工程1740において、現在のブロックは、参照ブロックを予測因子として、IntraBC モードにしたがって、符号化ブロックから再構成される。
【0070】
上記で示されるフローチャートは、本発明によるIntraBC 符号化の例を説明するためのものである。当業者は、本発明の精神と領域を脱しない範囲内で、各ステップを修正、再アレンジ、分割、結合して、本発明を実行することができる。本開示において、特定の構文と語義が用いられて、例を説明し、本発明の実施形態を実行する。当業者は、本発明の精神と領域を脱しない範囲内で、構文と語義を、等価の構文と語義と置き換えることにより、本発明を実施する。
【0071】
上の記述が提示されて、当業者に、特定のアプリケーションとその要求のコンテキストに記述される通り、本発明を行うことができる。当業者なら、記述された具体例への各種修正が理解でき、ここで定義される一般原則は別の実施例にも応用できる。よって、本発明は、記述される特定の実施例に制限することを目的としておらず、原理と新規特徴と一致する最大範囲に一致する。上述の記述において、本発明の十分な理解を提供するため、各種特定の詳細が説明される。当業者なら、本発明が行えることが理解できる。
【0072】
上述の本発明の具体例は、各種ハードウェア、ソフトウェアコード、または、それらの組み合わせで実行される。たとえば、本発明の具体例は、画像圧縮チップに整合される回路、または、画像圧縮ソフトウェアに整合されるプログラムコードで、上述の処理を実行する。本発明の具体例は、デジタルシグナルプロセッサ(DSP)で実行されるプログラムコードで、上述の処理を実行する。本発明は、さらに、コンピュータプロセッサ、デジタルシグナルプロセッサ、マイクロプロセッサ、または、フィールドプログラマブルゲートアレイ(FPGA)により実行される複数の機能を含む。これらのプロセッサは、本発明により具体化される特定の方法を定義する機械読み取り可能ソフトウェアコード、または、ファームウェアコードを実行することにより、本発明による特定のタスクを実行するように設定される。ソフトウェアコード、または、ファームウェアコードは、異なるプログラミング言語、および、異なるフォーマット、または、スタイルで開発される。ソフトウェアコードは、さらに、異なるターゲットプラットフォームにコンパイルされる。しかし、本発明によるタスクを実行するソフトウェアコードの異なるコードフォーマット、スタイル、および、言語、および、設定コードのその他の手段は、本発明の精神を逸脱しない。
【0073】
本発明では好ましい実施例を前述の通り開示したが、これらは決して本発明に限定するものではなく、当該技術を熟知する者なら誰でも、本発明の精神と領域を脱しない範囲内で各種の変動や潤色を加えることができ、従って本発明の保護範囲は、特許請求の範囲で指定した内容を基準とする。
図1
図2
図3
図4
図5A
図5B
図5C
図6A
図6B
図6C
図6D
図6E
図6F
図7
図8A
図8B
図9
図10
図11
図12
図13
図14
図15
図16
図17