IP Force 特許公報掲載プロジェクト 2022.1.31 β版

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

▶ テンセント・アメリカ・エルエルシーの特許一覧

特許7378485QT/BT/TTサイズの改善されたヘッダシンタックス
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-11-02
(45)【発行日】2023-11-13
(54)【発明の名称】QT/BT/TTサイズの改善されたヘッダシンタックス
(51)【国際特許分類】
   H04N 19/70 20140101AFI20231106BHJP
   H04N 19/96 20140101ALI20231106BHJP
【FI】
H04N19/70
H04N19/96
【請求項の数】 4
(21)【出願番号】P 2021548146
(86)(22)【出願日】2020-08-26
(65)【公表番号】
(43)【公表日】2022-04-01
(86)【国際出願番号】 US2020047960
(87)【国際公開番号】W WO2021041516
(87)【国際公開日】2021-03-04
【審査請求日】2021-08-17
(31)【優先権主張番号】62/892,246
(32)【優先日】2019-08-27
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】16/999,657
(32)【優先日】2020-08-21
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】520353802
【氏名又は名称】テンセント・アメリカ・エルエルシー
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100150197
【弁理士】
【氏名又は名称】松尾 直樹
(72)【発明者】
【氏名】イシン・ドゥ
(72)【発明者】
【氏名】シアン・リ
(72)【発明者】
【氏名】シン・ジャオ
(72)【発明者】
【氏名】シャン・リュウ
(72)【発明者】
【氏名】ビョンドゥ・チェ
(72)【発明者】
【氏名】ステファン・ヴェンガー
【審査官】間宮 嘉誉
(56)【参考文献】
【文献】国際公開第2020/057572(WO,A1)
【文献】BROSS, Benjamin et al.,Versatile Video Coding (Draft 6),JVET-O2001 (version 14),ITU,2019年07月31日,pp.37-40, 50-54, 57-58, 60-62, 125
【文献】BROSS, Benjamin et al.,Versatile Video Coding (Draft 2),JVET-K1001 (version 4),ITU,2019年08月17日,pp.25, 37
(58)【調査した分野】(Int.Cl.,DB名)
H04N 7/12
H04N 19/00-19/98
(57)【特許請求の範囲】
【請求項1】
少なくとも1つのプロセッサが実行するビデオコーディング方法であって、
ビデオデータからコーディングツリーユニット(CTU)を取得するステップと、
前記CTUを四分木構造によってパーティションするステップと、
前記パーティションされたCTUのリーフノードを、二分木構造および三分木構造の少なくとも一方によってパーティションするステップと、
前記CTUを前記四分木構造によってパーティションすることと、前記パーティションされたCTUのリーフノードを前記二分木構造および前記三分木構造の少なくとも一方によってパーティションすることとのうちの少なくとも一方の結果として得られるサンプルのサイズの基数2の対数と、少なくとも1つの値の基数2の対数との間の差分をシグナリングするステップと、を含むビデオコーディング方法であって、
前記少なくとも1つの値は、前記CTUのサイズを含み、
前記サンプルの前記サイズは、前記CTUを前記四分木構造によってパーティションした結果得られるルマリーフブロックのルマサンプルにおける最小サイズである、
ビデオコーディング方法。
【請求項2】
少なくとも1つのプロセッサが実行するビデオコーディング方法であって、
ビデオデータからコーディングツリーユニット(CTU)を取得するステップと、
前記CTUを四分木構造によってパーティションするステップと、
前記パーティションされたCTUのリーフノードを、二分木構造および三分木構造の少なくとも一方によってパーティションするステップと、
前記CTUを前記四分木構造によってパーティションすることと、前記パーティションされたCTUのリーフノードを前記二分木構造および前記三分木構造の少なくとも一方によってパーティションすることとのうちの少なくとも一方の結果として得られるサンプルのサイズの基数2の対数と、少なくとも1つの値の基数2の対数との間の差分をシグナリングするステップと、を含むビデオコーディング方法であって、
前記少なくとも1つの値は、前記CTUのサイズを含み、
前記サンプルの前記サイズは、前記CTUを前記四分木構造によってパーティションした結果得られるクロマリーフブロックの最小サイズである、
ビデオコーディング方法。
【請求項3】
コンピュータプログラムコードを記憶するように構成される少なくとも1つのメモリと、
前記コンピュータプログラムコードにアクセスし、前記コンピュータプログラムコードによって命令された通りに動作するように構成される少なくとも1つのプロセッサと、を備えるビデオコーディング装置であって、
前記コンピュータプログラムコードは、
前記少なくとも1つのプロセッサに、請求項1または2に記載のビデオコーディング方法を実行させるように構成されるビデオコーディング装置。
【請求項4】
コンピュータに、請求項1または2に記載のビデオコーディング方法を実行させるように構成されるプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
[1]本出願は、2019年8月27日に提出された仮出願第US62/892,246号、および2020年8月21日に提出された非仮出願第US16/999,657号の優先権を主張する。これらの出願の全ての内容は、参照により本願に組み込むものとする。
【0002】
1、分野
[2]本開示は、改善されたQT/BT/TTサイズシンタックスを含む一連の高度なビデオコーディング技術によってビット効率を改善することを目的とする。
【背景技術】
【0003】
2、関連技術の説明
[3]ITU-T VCEG(Q6/16)およびISO/IEC MPEG(JTC 1/SC 29/WG 11)は、H.265/HEVC(High Efficiency Video Coding:高効率ビデオコーディング)規格を、2013年(バージョン1)、2014年(バージョン2)、2015年(バージョン3)および2016年(バージョン4)に公開した。2015年、これら2つの標準化団体が共同でJVET(Joint Video Exploration Team:共同ビデオ探索チーム)を結成し、HEVCを超える次のビデオコーディング規格の開発の可能性を探った。2017年10月、「HEVCを超える性能を備えたビデオ圧縮に関する提案の共同募集(CfP)」を発行した。2018年2月15日までに、標準ダイナミックレンジ(SDR)に関するCfP回答が計22件、ハイダイナミックレンジ(HDR)に関するCfP回答が計12件、360ビデオカテゴリに関するCfP回答が計12件、それぞれ提出された。2018年4月、122 MPEG / 10th JVET会議において、受信されたCfP回答がすべて評価された。この会議の結果、JVETはHEVCを超える次世代ビデオコーディングの標準化プロセスを正式に開始した。新しい規格は多用途ビデオコーディング(Versatile Video Coding、VVC)と名付けられ、JVETは共同ビデオエキスパートチーム(Joint Video Expert Team)と改称された。VTM(VVC Test Model)の現在のバージョンは、VTM 6である。
【0004】
[4]VVC Draft 6では、以下の表1および表2のハイライト領域に示されるように、QT/BT/TTのサイズを記述するシンタックス要素がある。前述した各シンタックスは、2つの数値の基数2の対数間のデフォルトの差分を指定する。
【0005】
【表1】
【0006】
【表2】
【0007】
[5]上記を踏まえて、CTUを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズの基数2の対数と、スライスにおけるルマCUsのルマサンプル内の最小コーディングブロックサイズの基数2の対数とのデフォルトの差分を指定するシンタックスsps_log2_diff_min_qt_min_cb_intra_slice_lumaを例として考える。従って、0以上CtbLog2SizeY - MinCbLog2SizeY以下の範囲とされる。CtbLog2SizeYは、log2_ctu_size_minus5+5として導出されるため、CTUサイズがそれぞれ32×32、64×64、128×128の場合、その値は[5,6,7]以内となる。一方、VVC Draft 6では、MinCbLog2SizeYの値が2であると指定されている。したがって、sps_log2_diff_min_qt_min_cb_intra_slice_lumaの最大値は、CTUサイズに応じて[3,4,5]以内となる。
【0008】
[6]しかし、QT/BT/TTのmax値が一般的にCTUサイズに設定されているため、max QT/BT/TTとmin QT/CBとの間の差分をシグナリングすることは、ビット効率が良くない。
【0009】
[7]このため、そのような問題に対する技術的な解決策が望まれている。
【発明の概要】
【課題を解決するための手段】
【0010】
[8]1つまたは複数の異なる課題に対処するために、本開示は、QT/TT/BTサイズを記述するように設計された新しいシンタックスおよびその使用について説明した。実施形態によれば、これらのシンタックスは、基数をmin CB/QTからCTUに変更しており、実施形態では、QT/TT/BTのサイズをより小さな数値(numbers)を用いてシグナリングすることが可能となる。したがって、コーディング効率の向上を図ることができる。
【0011】
[9]コンピュータプログラムコードを記憶するように構成されるメモリと、前記コンピュータプログラムコードにアクセスし、前記コンピュータプログラムコードによって命令された通りに動作するように構成される1以上のプロセッサとを含む方法および装置が含まれる。前記コンピュータプログラムコードは、前記少なくとも1つのプロセッサに、ビデオデータからコーディングツリーユニット(CTU)を取得させるように構成される取得コードと、前記少なくとも1つのプロセッサに、前記CTUを四分木構造によってパーティションさせるように構成されるパーティションコードと、前記少なくとも1つのプロセッサに、前記パーティションされたCTUのリーフノードを、二分木構造および三分木構造の少なくとも一方によってパーティションさせるように構成される更なるパーティションコードと、前記少なくとも1つのプロセッサに、前記CTUを前記四分木構造によってパーティションすることと、前記パーティションされたCTUのリーフノードを前記二分木構造および前記三分木構造の少なくとも一方によってパーティションすることとのうちの少なくとも一方の結果として得られるサンプルのサイズと、少なくとも1つの値との間の差分を、基数2の対数でシグナリングさせるように構成されるシグナリングコードと、を含む。
【0012】
[10]実施形態によれば、前記少なくとも1つの値は、前記CTUのサイズを含む。
【0013】
[11]実施形態によれば、前記サンプルのサイズは、前記CTUを前記四分木構造によってパーティションした結果得られるルマリーフブロックのルマサンプルにおける最小サイズの基数2の対数である。
【0014】
[12]実施形態によれば、前記サンプルのサイズは、前記パーティションされたCTUの前記リーフノードを前記二分木構造によってパーティションした結果得られるルマコーディングブロックのルマサンプルにおける最大サイズの基数2の対数である。
【0015】
[13]実施形態によれば、前記サンプルのサイズは、前記パーティションされたCTUの前記リーフノードを前記三分木構造によってパーティションした結果得られるルマコーディングブロックのルマサンプルにおける最大サイズの基数2の対数である。
【0016】
[14]実施形態によれば、前記サンプルのサイズは、前記パーティションされたCTUの前記リーフノードを前記二分木構造によってパーティションした結果得られるクロマコーディングブロックの最大サイズの基数2の対数である。
【0017】
[15]実施形態によれば、前記サンプルのサイズは、前記パーティションされたCTUの前記リーフノードを前記三分木構造によってパーティションした結果得られるクロマコーディングブロックの最大サイズの基数2の対数である。
【0018】
[16]実施形態によれば、前記サンプルのサイズは、前記CTUを前記四分木構造によってパーティションした結果得られるクロマリーフブロックの最小サイズの基数2の対数である。
【0019】
[17]実施形態によれば、前記少なくとも1つの値は、前記CTUのコーディングブロック(CB)の最小サイズを含む。
【0020】
[18]実施形態によれば、前記少なくとも1つの値は、所定値である。
【0021】
[19]開示された主題のさらなる特徴、本質、および様々な利点は、以下の詳細な説明および添付の図面からより明らかになるであろう。
【図面の簡単な説明】
【0022】
図1】実施形態による簡略図である。
図2】実施形態による概略図である。
図3】実施形態による概略図である。
図4】実施形態による概略図である。
図5】実施形態による簡略図である。
図6】実施形態による簡略図である。
図7】実施形態による簡略図である。
図8】実施形態による簡略図である。
図9A】実施形態による簡略図である。
図9B】実施形態による簡略図である。
図10A】実施形態による簡略図である。
図10B】実施形態による簡略図である。
図10C】実施形態による簡略図である。
図11】実施形態による簡略流れ図である。
図12】実施形態による図を示す概略図である。
【発明を実施するための形態】
【0023】
[35]以下に説明する提案された特徴は、別々に使用しても、任意の順序で組み合わせてもよい。さらに、実施形態は、処理回路(例えば、1つまたは複数のプロセッサ或いは1つまたは複数の集積回路)によって実装されてもよい。一例では、1つまたは複数のプロセッサは、非一時的なコンピュータ読取可能な媒体に記憶されているプログラムを実行する。
【0024】
[36]図1は、本開示の一実施形態による通信システム100の簡略ブロック図を示している。通信システム100は、ネットワーク105を介して相互接続された少なくとも2つの端末102および103を含み得る。データの単方向送信の場合、第1の端末103は、ネットワーク105を介して他方の端末102へ送信するために、ビデオデータをローカル位置でコード化してもよい。第2の端末102は、ネットワーク105から他方の端末のコード化されたビデオデータを受信し、コード化されたデータをデコードし、復元されたビデオデータを表示することができる。単方向のデータ送信は、メディア供給アプリケーションなどで一般的である。
【0025】
[37]図1は、例えばビデオ会議中に発生し得るコード化されたビデオの双方向送信をサポートするために提供される第2の対の端末101および104を示している。データの双方向送信の場合、各端末101および104は、ネットワーク105を介して他方の端末へ送信するために、ローカル位置でキャプチャされたビデオデータをコード化してもよい。また、各端末101および104は、他方の端末で送信されたコード化されたビデオデータを受信し、コード化されたデータをデコードし、復元されたビデオデータをローカルの表示装置に表示することができる。
【0026】
[38]図1において、端末101,102,103および104は、サーバ、パーソナルコンピュータ、およびスマートフォンとして示され得るが、本開示の原理はこれに制限されることはない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤーおよび/または専用のビデオ会議機器における用途を見出す。ネットワーク105は、例えば有線および/または無線通信ネットワークを含む、端末101,102,103および104間でコード化されたビデオデータを伝達する任意の数のネットワークを表す。通信ネットワーク105は、回線交換および/またはパケット交換チャネルでデータを交換することができる。代表的なネットワークとしては、電気通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワークおよび/またはインターネットが挙げられる。本議論の目的のために、ネットワーク105のアーキテクチャおよびトポロジーは、以下に説明されない限り、本開示の動作にとって重要ではないかもしれない。
【0027】
[39]図2は、開示された主題のアプリケーションの一例として、ストリーミング環境におけるビデオエンコーダおよびデコーダの配置を示している。開示された主題は、例えば、ビデオ会議、デジタルTV、および、CD、DVD、メモリスティックなどを含むデジタルメディアへの圧縮されたビデオの記憶など、を含む他のビデオ対応アプリケーションに等しく適用可能である。
【0028】
[40]ストリーミングシステムは、例えば非圧縮のビデオサンプルストリーム213を作成するデジタルカメラのようなビデオソース201を含むことができるキャプチャサブシステム203を含んでもよい。そのサンプルストリーム213は、符号化されたビデオビットストリームと比較して高データ量として強調されることがあり、カメラ201に結合されたエンコーダ202によって処理されることができる。エンコーダ202は、以下でより詳細に説明するように、開示された主題の態様を可能にするかまたは実施するために、ハードウェア、ソフトウェア、またはそれらの組み合わせを含むことができる。サンプルストリームと比較してより低いデータ量として強調され得る符号化されたビデオビットストリーム204は、将来使うためにストリーミングサーバ205に記憶されることができる。1つまたは複数のストリーミングクライアント212および207は、ストリーミングサーバ205にアクセスして、符号化されたビデオビットストリーム204のコピー208および206を検索することができる。クライアント212は、符号化されたビデオビットストリームの入り方向コピー208をデコードし、ディスプレイ209または他のレンダリングデバイス(図示せず)でレンダリングできる出方向ビデオサンプルストリーム210を作成するビデオデコーダ211を含むことができる。一部のストリーミングシステムにおいて、ビデオビットストリーム204、206および208は、特定のビデオコーディング/圧縮規格に従って符号化されることができる。これらの規格の例は、上で述べられ、ここでさらに説明される。
【0029】
[41]図3は、本発明の一実施形態によるビデオデコーダ300の機能ブロック図である。
【0030】
[42]受信機302は、デコーダ300によってデコードされる1つまたは複数のコード化されたビデオシーケンスを受信することができ、同一または別の実施形態では、一度に1つのコーディングされたビデオシーケンスを受信してもよく、各コード化されたビデオシーケンスのデコードは、他のコード化されたビデオシーケンスから独立している。コード化されたビデオシーケンスは、符号化されたビデオデータを記憶する記憶装置へのハードウェア/ソフトウェアリンクであり得るチャネル301から受信されることができる。受信機302は、それぞれの使用エンティティ(図示せず)に転送され得る他のデータ、例えば、コード化されたオーディオデータおよび/または補助データストリームとともに、符号化されたビデオデータを受信し得る。受信機302は、コード化されたビデオシーケンスを他のデータから分離することができる。ネットワークジッタを防止するために、バッファメモリ303は、受信機302とエントロピーデコーダ/パーサ304(以降、「パーサ」)の間に結合されてもよい。受信機302が十分な帯域幅および可制御性を有する記憶/転送装置から、または等同期ネットワークからデータを受信する際に、バッファ303は必要とされないことがあり、または小さくされることがある。インターネットのようなベストエフォートパケットネットワークで使用するために、バッファ303が必要になる場合があり、バッファ303は、比較的大きいことがあり、有利には適応サイズであることができる。
【0031】
[43]ビデオデコーダ300は、エントリピーコード化されたビデオシーケンスからシンボル313を再構築するパーサ304を含んでもよい。これらのシンボルのカテゴリは、デコーダ300の動作を管理するために使用される情報、および、デコーダの不可欠な部分ではないが、デコーダに結合され得るディスプレイ312のようなレンダリングデバイスを制御する潜在的情報を含む。レンダリングデバイスのための制御情報は、補助強化情報(SEIメッセージ)またはビデオユーザビリティ情報(VUI)パラメータセットフラグメント(図示せず)の形態であってよい。パーサ304は、受信されたコード化されたビデオシーケンスを構文解析/エントロピーデコードすることができる。コード化されたビデオシーケンスのコーディングは、ビデオコーディング技術または規格に合わせることができ、可変長コーディング、ハフマンコーディング、文脈感受性を有するもしくは有さない算術コーディングなどを含む、当業者によく知られている原理に従うことができる。パーサ304は、グループに対応する少なくとも1つのパラメータに基づいて、コード化されたビデオシーケンスから、ビデオデコーダ内の画素の少なくとも1つのサブグループのためのサブグループパラメータのセットを抽出することができる。サブグループは、ピクチャ群(GOPs)、ピクチャ、タイル、スライス、マクロブロック、コーディングユニット(CUs)、ブロック、変換ユニット(TUs)、予測ユニット(PUs)などを含むことができる。エントロピーデコーダ/パーサは、コード化されたビデオシーケンスから変換係数、量子化パラメータ値、動きベクトルのような情報をも抽出することができる。
【0032】
[44]パーサ304は、シンボル313を作成するために、バッファ303から受信されたビデオシーケンスに対してエントロピーデコード/構文解析動作を実行することができる。パーサ304は、符号化されたデータを受信し、特定のシンボル313を選択的にデコードしてもよい。さらに、パーサ304は、特定のシンボル313を、動き補償予測ユニット306、スケーラ/逆変換ユニット305、イントラ予測ユニット307、またはループフィルタ311のいずれに提供するか否かを決定してもよい。
【0033】
[45]シンボル313の再構築は、コード化されたビデオピクチャまたはその一部(例えば、インターおよびイントラピクチャ、インターおよびイントラブロック)のタイプ、および他の要因に応じて、複数の異なるユニットが関与することができる。どのユニットが、どのように関与するかは、パーサ304によって、コード化されたビデオシーケンスから構文解析されたサブグループ制御情報によって制御されることができる。パーサ304と以下の複数のユニットとの間のそのようなサブグループ制御情報の流れは、明確にするために示されていない。
【0034】
[46]すでに述べた機能ブロックに加え、デコーダ300は、以下に説明されるようにいくつかの機能ユニットに概念的に細分されることができる。商業的な制約の下で実際の実施動作にあたっては、これらのユニットの多くは互いに密接に相互作用し、少なくとも一部は互いに統合することができる。しかしながら、開示された主題の説明の目的で、以下の機能ユニットへの概念的な細分は、適切に行われる。
【0035】
[47]第1のユニットは、スケーラ/逆変換ユニット305である。スケーラ/逆変換ユニット305は、使用する変換、ブロックサイズ、量子化因子、量子化スケーリングマトリックスなどを含む制御情報と、量子化された変換係数をシンボル313としてパーサ304から受信する。スケーラ/逆変換ユニット305は、アグリゲータ310に入力可能なサンプル値を含むブロックを出力することができる。
【0036】
[48]場合によっては、スケーラ/逆変換305の出力サンプルは、イントラコーディングブロック、すなわち、予め再構築されたピクチャからの予測情報を使用していないが、現在ピクチャの予め再構築された部分からの予測情報を使用できるブロックに関係することがある。このような予測情報は、イントラピクチャ予測ユニット307によって提供されることができる。場合によっては、イントラピクチャ予測ユニット307は、現在の(一部再構築された)ピクチャ309から取り出された周囲の既に再構築された情報を用いて、再構築中のブロックの同じサイズおよび形状のブロックを生成する。アグリゲータ310は、場合によっては、サンプルごとに、イントラ予測ユニット307が生成した予測情報を、スケーラ/逆変換ユニット305によって提供される出力サンプル情報に追加する。
【0037】
[49]他の場合では、スケーラ/逆変換ユニット305の出力サンプルは、インターコード化された、潜在的に動き補償されたブロックに関係することがある。このような場合、動き補償予測ユニット306は、参照ピクチャメモリ308にアクセスして、予測に使用されるサンプルを取り出すことができる。取り出されたサンプルをブロックに関係するシンボル313に従って動き補償した後、出力サンプル情報を生成するように、これらのサンプルは、アグリゲータ310によってスケーラ/逆変換ユニットの出力に追加されることができる(この場合、残差サンプルまたは残差信号と呼ばれる)。動き補償予測ユニットが予測サンプルを取り出す参照ピクチャメモリ内のアドレスは、例えば、X、Y、および参照ピクチャ成分を有し得るシンボル313の形態で動き補償予測ユニットに利用可能な動きベクトルによって制御されることができる。動き補償は、サブサンプル正確な動きベクトルが使用中であるときに参照ピクチャメモリから取り出されたサンプル値の補間、動きベクトル予測メカニズムなどを含むこともできる。
【0038】
[50]アグリゲータ310の出力サンプルは、ループフィルタユニット311において様々なループフィルタリング手法を受けられる。ビデオ圧縮技術は、コード化されたビデオストリームに含まれる、パーサ304からのシンボル313としてループフィルタユニット311に利用可能とされたパラメータによって制御されることができ、それに、コード化ピクチャまたはコード化ビデオシーケンスの(デコード順で)前の部分のデコード中に取得されたメタ情報に応じるとともに、予め再構築されループフィルタリングされたサンプル値に応じることもできるループ内フィルタ技術を含むことができる。
【0039】
[51]ループフィルタユニット311の出力は、レンダリングデバイス312へ出力されることができるとともに、将来のインターピクチャ予測で使用するために参照ピクチャメモリ557に記憶されることができるサンプルストリームであり得る。
【0040】
[52]特定のコード化ピクチャは、完全に再構築されると、将来の予測のために参照ピクチャとして使用されることができる。コード化ピクチャが完全に再構築され、コード化ピクチャが(例えば、パーサ304によって)参照ピクチャとして識別されると、現在参照ピクチャ309は、参照ピクチャバッファ308の一部になることができ、次のコード化ピクチャの再構築を開始する前に新しい現在ピクチャメモリを再割当てすることができる。
【0041】
[53]ビデオデコーダ300は、ITU-T Rec.H.265のような規格で文書化され得る所定のビデオ圧縮技術に従ってデコード動作を実行することができる。コード化されたビデオシーケンスは、ビデオ圧縮技術の文書または規格、具体的にはその中のプロファイル文書で指定された、ビデオ圧縮技術または規格のシンタックスに準拠するという意味で、使用されているビデオ圧縮技術または規格によって指定されたシンタックスに準拠し得る。コード化されたビデオシーケンスの複雑さがビデオ圧縮技術または規格のレベルによって定義される範囲内にあることも、コンプライアンスに必要である。場合によっては、最大ピクチャサイズ、最大フレームレート、最大再構築サンプルレート(例えば、1秒あたりのメガサンプルで測定される)、最大参照ピクチャサイズなどがレベルによって制限される。レベルによって設定された制限は、場合によっては、仮想参照デコーダ(HRD)仕様およびコード化されたビデオシーケンスでシグナリングされたHRDバッファ管理のためのメタデータによってさらに制限され得る。
【0042】
[54]一実施形態では、受信機302は、符号化されたビデオとともに追加の(冗長な)データを受信することができる。追加のデータは、コード化されたビデオシーケンスの一部として含まれてもよい。追加のデータは、データを適切にデコードし、および/または、元のビデオデータをより正確に再構築するためにビデオデコーダ300によって使用され得る。追加のデータは、例えば、時間的、空間的、または信号対雑音比(SNR)エンハンスメントレイヤ、冗長スライス、冗長ピクチャ、前方向誤り訂正コードのような形態にされることができる。
【0043】
[55]図4は、本開示の一実施形態によるビデオエンコーダ400の機能ブロック図である。
【0044】
[56]エンコーダ400は、エンコーダ400によってコード化されるビデオ画像をキャプチャし得るビデオソース401(デコーダの一部ではない)からビデオサンプルを受信することができる。
【0045】
[57]ビデオソース401は、エンコーダ(303)によってコード化されるソースビデオシーケンスを、任意の適切なビット深度(例えば、8ビット、10ビット、12ビット、・・・)、任意の色空間(例えば、BT.601 Y CrCB、RGB、・・・)および任意の適切なサンプリング構造(例えば、Y CrCb 4:2:0、Y CrCb 4:4:4)であり得るデジタルビデオサンプルストリームの形態で提供し得る。メディア供給システムでは、ビデオソース401は、予め準備されたビデオを記憶する記憶装置であり得る。ビデオ会議システムでは、ビデオソース401は、ローカル画像情報をビデオシーケンスとしてキャプチャするカメラであり得る。ビデオデータは、順番に見られるときに動きが与えられる複数の個別のピクチャとして提供されてもよい。ピクチャ自体は、画素の空間アレイとして編成されてもよく、各画素は、使用中のサンプリング構造、色空間などに応じて1つまたは複数のサンプルを含むことができる。当業者は、画素とサンプルとの関係を容易に理解することができる。以下の説明ではサンプルを中心に説明する。
【0046】
[58]一実施形態によれば、エンコーダ400は、リアルタイムでまたはアプリケーションが要求する任意の他の時間制約の下でソースビデオシーケンスのピクチャをコード化し、コード化されたビデオシーケンス410に圧縮することができる。適切なコーディング速度を実施することは、コントローラ402の機能の1つである。コントローラは、以下に説明される他の機能ユニットを制御し、これらのユニットに機能的に結合される。分かりやすくするために、カップリングは示されていない。コントローラによって設定されるパラメータは、レート制御関連パラメータ(ピクチャスキップ、量子化、レート歪み最適化手法のラムダ値、・・・)、ピクチャサイズ、ピクチャ群(GOP)レイアウト、最大動きベクトル検索範囲などを含むことができる。当業者であれば、特定のシステム設計に対して最適化されたビデオエンコーダ400に関係し得るので、コントローラ402の他の機能を容易に認識することができる。
【0047】
[59]ビデオエンコーダの中には、当業者が容易に認識できる「コーディングループ」で動作するものがある。過度に簡略化した説明として、コーディングループは、エンコーダ402(以降、「ソースコーダ」)(コーディング対象となる入力ピクチャおよび参照ピクチャに基づくシンボルの作成を担当する)と、エンコーダ400に埋め込まれた(ローカル)デコーダ406であって、シンボルを再構築して、(リモート)デコーダも作成するであろうサンプルデータを作成する(シンボルとコード化されたビデオビットストリーム間の如何なる圧縮は、開示された主題で考慮されるビデオ圧縮技術では可逆であるためである)デコーダ406とから構成され得る。再構築されたサンプルストリームは参照ピクチャメモリ405に入力される。シンボルストリームのデコードにより、デコーダの位置(ローカルまたはリモート)に関係なくビット正確な結果が得られるため、参照ピクチャバッファのコンテンツもローカルエンコーダとリモートエンコーダの間でビット正確である。言い換えれば、エンコーダの予測部分は、参照ピクチャサンプルとして、デコード中に予測を使用するときにデコーダが「見る」のと全く同じサンプル値を「見る」。参照ピクチャの同期性の該基本原理(および例えばチャネルエラーに起因して同期性を維持できない場合に生じるドリフト)は、当業者によく知られている。
【0048】
[60]「ローカル」デコーダ406の動作は、前文で図3に関連して既に詳細に説明された、「リモート」デコーダ300の動作と同様であり得る。しかしながら、図4も簡単に参照し、シンボルが使用可能であり、エントロピーコーダ408およびパーサ304によるコード化されたビデオシーケンスへのシンボルのエンコード/デコードは可逆であり得るので、チャネル301、受信機302、バッファ303、およびパーサ304を含むデコーダ300のエントロピーデコード部分は、ローカルデコーダ406では完全に実施されない場合がある。
【0049】
[61]これで分かるように、デコーダに存在する構文解析/エントロピーデコード以外の如何なるデコーダ技術も、対応するエンコーダにて実質的に同一の機能的形態で必ず存在する必要がある。エンコーダ技術の説明は、包括的に説明されたデコーダ技術の逆であるため、省略できる。特定の領域でのみ、より詳細な説明が必要であり、以下に提供される。
【0050】
[62]その動作の一部として、ソースコーダ403は、「参照フレーム」として指定されたビデオシーケンスからの1つまたは複数の予めコード化されたフレームを参照して入力フレームを予測的にコード化する動き補償予測コーディングを実行してもよい。このようにして、コーディングエンジン407は、入力フレームの画素ブロックと、入力フレームへの予測基準として選択され得る参照フレームの画素ブロックとの差異をコード化する。
【0051】
[63]ローカルビデオデコーダ406は、ソースコーダ403で作成されたシンボルに基づいて、参照フレームとして指定され得るフレームのコード化ビデオデータをデコードすることができる。コーディングエンジン407の動作は、有利にはロッシープロセスであり得る。コード化ビデオデータがビデオデコーダ(図4に示されていない)でデコードされ得るとき、再構築されたビデオシーケンスは、通常、いくつかのエラーを伴うソースビデオシーケンスのレプリカであってもよい。ローカルビデオデコーダ406は、ビデオデコーダによって参照フレームに対して実行され得るデコードプロセスを再現し、再構築された参照フレームを参照ピクチャキャッシュ405に記憶させることができる。このようにして、エンコーダ400は、遠端ビデオデコーダによって取得される再構築された参照フレームと共通するコンテンツ(送信エラー無し)を有する再構築された参照フレームのコピーをローカルに記憶し得る。
【0052】
[64]予測器404は、コーディングエンジン407の予測検索を実行することができる。つまり、コード化対象となる新しいフレームについて、予測器404は、(候補の参照画素ブロックとしての)サンプルデータ、または、参照ピクチャの動きベクトル、ブロック形状など、新しいピクチャの適切な予測基準として機能し得る特定のメタデータを参照ピクチャメモリ405で検索することができる。予測器404は、適切な予測基準を見つけるために、サンプルブロック/画素ブロックごとに動作することができる。場合によっては、予測器404で取得された検索結果によって決定されるように、入力ピクチャは、参照ピクチャメモリ405に記憶された複数の参照ピクチャから引き出された予測基準を有してもよい。
【0053】
[65]コントローラ402は、例えば、ビデオデータをエンコードするために使用されるパラメータおよびサブグループパラメータの設定を含む、ソースコーダ403のコーディング動作を管理することができる。
【0054】
[66]前述のすべての機能ユニットの出力は、エントロピーコーダ408においてエントロピーコーディングを受けられる。エントロピーコーダは、例えば、ハフマンコーディング、可変長コーディング、算術コーディングなどの当業者に知られている技術に従ってシンボルを可逆圧縮することにより、様々な機能ユニットによって生成されたシンボルをコード化されたビデオシーケンスに変換する。
【0055】
[67]送信機409は、符号化されたビデオデータを記憶する記憶装置へのハードウェア/ソフトウェアリンクであり得る通信チャネル411を介した送信の準備のために、エントロピーコーダ408によって作成されたコード化されたビデオシーケンスをバッファリングすることができる。送信機409は、ソースコーダ403からのコード化ビデオデータを、送信されるべき他のデータ、例えば、コード化オーディオデータおよび/または補助データストリーム(ソースは示されていない)とマージすることができる。
【0056】
[68]コントローラ402は、エンコーダ400の動作を管理してもよい。コーディング中、コントローラ405は、各コード化ピクチャに特定のコード化ピクチャタイプを割り当てることができ、これは、それぞれのピクチャに適用され得るコーディング手法に影響を及ぼし得る。例えば、ピクチャは、多くの場合、次のフレームタイプのいずれかとして割り当てられ得る。
【0057】
[69]イントラピクチャ(Iピクチャ)は、予測のソースとしてシーケンス内の他のいかなるフレームを使用せずにコード化および復号され得るものであり得る。一部のビデオコーデックは、例えば、インディペンデントデコーダリフレッシュピクチャ(Independent Decoder Refresh Pictures)を含む、異なるタイプのイントラピクチャを許容する。当業者は、Iピクチャのこれらの変形およびそれらのそれぞれの用途および特徴を知っている。
【0058】
[70]予測ピクチャ(Pピクチャ)は、各ブロックのサンプル値を予測するために最大1つの動きベクトルおよび参照インデックスを使用したイントラ予測またはインター予測によりコード化および復号され得るものであり得る。
【0059】
[71]双方向予測ピクチャ(Bピクチャ)は、各ブロックのサンプル値を予測するために最大2つの動きベクトルおよび参照インデックスを使用したイントラ予測またはインター予測によりコード化および復号され得るものであり得る。同様に、多重予測ピクチャは、単数のブロックの再構築のために2つを超えた参照ピクチャおよび関連メタデータを使用することができる。
【0060】
[72]ソースピクチャは、一般に、複数のサンプルブロック(例えば、それぞれ、4×4、8×8、4×8、または16×16サンプルのブロック)に空間的に細分され、ブロック単位でコード化され得る。ブロックは、ブロックのそれぞれのピクチャに適用されるコーディング割り当てによって決定された他の(既にコード化された)ブロックを参照して予測的にコード化され得る。例えば、Iピクチャのブロックは、非予測的にコード化されてもよく、或いは、同一のピクチャの既にコード化されたブロックを参照して予測的にコード化されてもよい(空間予測またはイントラ予測)。Pピクチャの画素ブロックは、1つの予めコード化された参照ピクチャを参照して、空間予測を介してまたは時間予測を介して非予測的にコード化され得る。Bピクチャのブロックは、1つまたは2つの予めコード化された参照ピクチャを参照して、空間予測を介してまたは時間予測を介して非予測的にコード化され得る。
【0061】
[73]ビデオコーダ400は、ITU-T Rec.H.265などの所定のビデオコーディング技術または規格に従って、コーディング動作を実行することができる。動作中、ビデオコーダ400は、入力ビデオシーケンスの時間的および空間的冗長性を利用する予測コーディング動作を含む、様々な圧縮動作を実行することができる。したがって、コード化ビデオデータは、使用されるビデオコーディング技術または規格によって指定されたシンタックスに準拠する場合がある。
【0062】
[74]一実施形態では、送信機409は、符号化されたビデオとともに追加のデータを送信することができる。ソースコーダ403は、このようなデータをコード化されたビデオシーケンスの一部として含み得る。追加のデータは、時間的/空間的/SNRエンハンスメントレイヤ、冗長なピクチャやスライスなどの他の形態での冗長データ、補助強化情報(SEI)メッセージ、ビデオユーザビリティ情報(VUI)パラメータセットフラグメントなどを含み得る。
【0063】
[75]図5は、HEVCとJEMで使用されるイントラ予測モードを示している。自然なビデオに見られる任意のエッジ方向をキャプチャするために、方向性イントラモードの数をHEVCで使用される33から65に拡張している。HEVCの上にあるJEMの追加の方向性モードは図1(b)では点線の矢印で示されており、平面(planar)およびDCモードは変わらない。これらのより高密度の方向性イントラ予測モードは、すべてのブロックサイズ、およびルマとクロマの両方のイントラ予測に適用される。図5に示されるように、奇数イントラ予測モードインデックスに関連付けられた、点線の矢印で識別される方向性イントラ予測モードは、奇数イントラ予測モードと呼ばれる。また、偶数イントラ予測モードインデックスに関連付けられた、実線の矢印で識別される方向性イントラ予測モードは、偶数イントラ予測モードと呼ばれる。本明細書では、図5の実線または点線の矢印で示されている方向性イントラ予測モードは、角度モードとも呼ばれる。
【0064】
[76]JEMでは、ルマイントラ予測に合計67通りのイントラ予測モードが使用されている。イントラモードをコード化するためには、隣接ブロックのイントラモードに基づいて、サイズ6の最確モード(Most Probable Mode、MPM)リストが構築される。イントラモードがMPMリストからのものではない場合、イントラモードが選択されたモードに属するか否かを示すフラグがシグナリングされる。JEM-3.0では、第4の角度モードごとに一様に選択される、16通りの選択されたモードがある。JVET-D0114およびJVET-G0060では、一様に選択されたモードを置き換えるために、16通りの二次MPMsが導出される。
【0065】
[77]図6は、イントラ方向性モードに利用されるN個の参照階層を示している。ブロックユニット611、セグメントA 601、セグメントB 602、セグメントC 603、セグメントD 604、セグメントE 605、セグメントF 606、第1の参照階層610、第2の参照階層609、第3の参照階層608、および第4の参照階層607がある。
【0066】
[78]HEVCとJEMの両方、およびH.264/AVCのような他の規格では、現在のブロックを予測するために使用される参照サンプルは、最も近い参照線(行または列)に制限されている。複数参照線イントラ予測の方法では、候補の参照線(行または列)の数は、イントラ方向性モードでは、1(すなわち最も近い)からNまで増加し、ここで、Nは1以上の整数である。図2では、4×4予測ユニット(PU)を例として取り上げ、複数線イントラ方向性予測法の概念を示す。イントラ方向性モードでは、N個の参照階層のうちの1つを任意に選択して、予測子を生成することができる。言い換えれば、予測子p(x,y)は、参照サンプルS1、S2、...、SNのうちの1つから生成される。イントラ方向性モードに対してどの参照階層が選択されるかを示すようにフラグがシグナリングされる。Nを1とすると、イントラ方向性予測法は、JEM2.0の従来の方法と同じである。図6では、参照線610、609、608、および607は、左上の参照サンプルとともに、6つのセグメント601、602、603、604、605、および606から構成される。本明細書では、参照階層は参照線とも呼ばれる。現在のブロックユニット内の左上の画素の座標は(0,0)であり、第1の参照線内の左上の画素の座標は(-1,-1)である。
【0067】
[79]JEMでは、ルマ成分について、イントラ予測サンプルの生成に使用される隣接サンプルは、生成プロセスの前にフィルタリングされる。このフィルタリングは、与えられたイントラ予測モードおよび変換ブロックサイズによって制御される。イントラ予測モードがDCであるか、または変換ブロックサイズが4×4に等しい場合、隣接サンプルはフィルタリングされない。与えられたイントラ予測モードと垂直モード(または水平モード)との間の距離が、事前定義された閾値よりも大きい場合、フィルタリングプロセスが有効になる。隣接サンプルのフィルタリングには、[1,2,1]フィルタおよびバイリニアフィルタが使用される。
【0068】
[80]位置依存イントラ予測組み合わせ(PDPC)法は、フィルタリングされていない境界参照サンプルと、フィルタリングされた境界参照サンプルを用いたHEVCスタイルのイントラ予測の組み合わせを呼び出すイントラ予測法である。(x,y)にある各予測サンプルpred[x][y]は、以下のように算出される。
【0069】
【数1】
【0070】
ただし、Rx,-1,R-1,yは、それぞれ現在のサンプル(x,y)の上と左にあるフィルタリングされていない参照サンプルを表し、R-1,-1は、現在のブロックの左上隅にあるフィルタリングされていない参照サンプルを表す。重み付けは以下のように算出される。
【0071】
【数2】
【0072】
[81]図7は、1つの4×4ブロック内の(0,0)および(1,0)の位置に対するDCモードPDPC重み(wL,wT,wTL)を示す図700を示している。PDPCがDC、平面、水平、および垂直イントラモードに適用される場合、HEVC DCモードの境界フィルタや水平/垂直モードのエッジフィルタのような追加の境界フィルタは必要ない。図7は、右上対角線モードに適用されるPDPCの参照サンプルRx,-1、R-1,y、およびR-1,-1の定義を示している。予測サンプルpred(x’,y’)は、予測ブロック内の(x’,y’)にある。参照サンプルRx,-1の座標xは、x=x’+y’+1で与えられ、参照サンプルR-1,yの座標yは、同様に、y=x’+y’+1で与えられる。
【0073】
[82]図8は、局所照明補償(LIC)のダイアグラム800を示しており、スケーリング係数aとオフセットbを使用した、照明変化に対する線形モデルに基づいている。そして、各インターモードコード化されたコーディングユニット(CU)に対して適応的に有効化または無効化される。
【0074】
[83]LICがCUに適用される場合、現在のCUの隣接サンプルとそれらに対応する参照サンプルを用いてパラメータaおよびbを導出するために、最小二乗誤差法が採用される。より具体的には、図8に示されるように、CUのサブサンプリング(2:1サブサンプリング)された隣接サンプルおよび参照ピクチャ中の対応するサンプル(現在のCUまたはサブCUの動き情報によって特定される)が使用される。ICパラメータが導出され、予測方向ごとに個別に適用される。
【0075】
[84]CUをマージモードでコード化する場合、マージモードでの動き情報のコピーと同様の方法で、LICフラグを隣接ブロックからコピーする。それ以外の場合、LICが適用されるか否かを示すようにLICフラグをCUのためにシグナリングする。
【0076】
[85]図9Aは、HEVCで使用されるイントラ予測モード900を示している。HEVCでは、合計35通りのイントラ予測モードがあり、そのうち、モード10は水平モード、モード26は垂直モード、モード2、モード18、およびモード34は対角線モードである。イントラ予測モードは、3通りの最確モード(MPMs)と32通りの残りのモードによってシグナリングされる。
【0077】
[86]図9Bに示されるように、VVCの実施形態において、合計87通りのイントラ予測モードがあり、ここで、モード18は水平モード、モード50は垂直モード、モード2、モード34、およびモード66は対角線モードである。モード-1~-10およびモード67~76は、広角イントラ予測(Wide-Angle Intra Prediction、WAIP)モードと呼ばれる。
【0078】
[87]位置(x,y)にある予測サンプルpred(x,y)は、次のPDPC表現式に従って、イントラ予測モード(DC、平面、角度)および参照サンプルの線形結合を用いて予測される。
pred(x,y) = ( wL × R-1,y + wT × Rx,-1 - wTL × R-1,-1 + (64 - wL - wT + wTL) × pred(x,y) + 32 ) >> 6
ここで、Rx,-1、R-1,yは、それぞれ現在のサンプル(x,y)の上と左にある参照サンプルを表し、R-1,-1は、現在のブロックの左上隅にある参照サンプルを表す。
【0079】
[88]DCモードの場合、幅と高さの寸法を持つブロックに対して、重みは次のように算出される。
wT = 32 >> ( ( y<<1 ) >> nScale ), wL = 32 >> ( ( x<<1 ) >> nScale ), wTL = ( wL>>4 ) + ( wT>>4 )、
nScale = ( log2( width ) - 2 + log2( height ) - 2 + 2 ) >> 2とする。ここで、wTは、同じ水平座標を持つ上方の参照線にある参照サンプルの重み付け係数を示し、wLは、同じ垂直座標を持つ左の参照線にある参照サンプルの重み付け係数を示し、wTLは、現在のブロックの左上の参照サンプルの重み付け係数を示す。nScaleは、軸に沿って重み付け係数がどれくらいの速さで減少するか(wLが左から右に減少するか、またはwTが上から下に減少する)、つまり重み付け係数の減少率を指定するもので、現在の設計ではX軸(左から右へ)とY軸(上から下へ)に沿って同じである。また、32は隣接サンプルの初期重み付け係数を示し、初期重み付け係数は、現在のCBにおける左上のサンプルに割り当てられた上(左または左上)の重み付けでもあり、PDPCプロセスにおける隣接サンプルの重み付け係数は、この初期重み付け係数に等しいか、それより小さいことが望ましい。
【0080】
[89]平面モードの場合wTL=0、水平モードの場合wTL=wT、垂直モードの場合wTL=wLとなる。PDPC重みは加算とシフトのみで算出されることができる。pred(x,y)の値は、式(1)を用いてワンステップで演算されることができる。
【0081】
[90]ここで、提案された方法は、別々に使用されても、任意の順序で組み合わせられてもよい。さらに、方法(または実施形態)、エンコーダ、およびデコーダのそれぞれは、処理回路(例えば、1つまたは複数のプロセッサ、或いは1つまたは複数の集積回路)によって実施されてもよい。一例では、1つまたは複数のプロセッサは、非一時的なコンピュータ読取可能な媒体に記憶されているプログラムを実行する。以下では、ブロックという用語は、予測ブロック、コーディングブロック、またはコーディングユニット、すなわちCUとして解釈され得る。
【0082】
[91]図10Aは、QTBTを使用することによるブロックパーティションの例1000を示しており、図10Bは、対応するツリー表現1001を示している。実線は四分木分割を示し、点線は二分木分割を示す。二分木の各分割(すなわち、非リーフ)ノードでは、どちらの分割タイプ(すなわち、水平または垂直)が使用されるかを示すように1つのフラグがシグナリングされ、ここで、0は水平分割を示し、1は垂直分割を示す。四分木分割の場合、四分木分割は常にブロックを水平と垂直の両方に分割し、同じサイズの4つのサブブロックを生成するため、分割タイプを示す必要はない。
【0083】
[92]HEVCでは、様々な局所特性に適応するように、コーディングツリーとして示される四分木構造を用いることでCTUをCUsに分割する。インターピクチャ(時間的)予測またはイントラピクチャ(空間的)予測を使用してピクチャ領域をコード化するか否かの決定は、CUレベルで行われる。各CUは、PU分割タイプに応じて、さらに1つ、2つ、または4つのPUsに分割されることができる。1つのPU内で、同じ予測プロセスが適用され、関連する情報がPU単位でデコーダに送信される。PU分割タイプに基づいて予測プロセスを適用することで残余ブロックを取得した後、CUのコーディングツリーのような別の四分木構造に従って、CUを変換ユニット(TUs)にパーティションすることができる。HEVC構造の重要な特徴の1つは、CU、PU、およびTUを含む複数のパーティション概念があることである。
【0084】
[93]実施形態によれば、QTBT構造は、複数のパーティションタイプの概念をなくし、すなわち、CU、PU、およびTU概念の分離をなくし、CUのパーティション形状のより高い柔軟性をサポートする。QTBTブロック構造では、CUは、正方形または長方形のいずれかの形状を有することができる。図11の流れ図1100において、例示的な実施形態によれば、S11で取得されたコーディングツリーユニット(CTU)またはCUを、まずS12において四分木構造によってパーティションする。さらに、S14において、四分木リーフノードを二分木構造によってパーティションするか否かを決定し、そうであれば、S15において、例えば図10Cを用いて説明したように、二分木分割には、対称的な水平分割と対称的な垂直分割の2つの分割タイプがある。二分木リーフノードは、コーディングユニット(CUs)と呼ばれ、そのセグメンテーションは、それ以上のパーティションをせずに、予測および変換処理に使用される。これは、QTBTコーディングブロック構造では、CU、PU、およびTUが同じブロックサイズを持っていることを意味する。VVCでは、CUは、異なる色成分のコーディングブロック(CBs)から構成されることがあり、例えば、4:2:0クロマフォーマットのPおよびBスライスの場合、1つのCUが1つのルマCBと2つのクロマCBsを含み、また、単一成分のCBから構成されることがあり、例えば、Iスライスの場合、1つのCUが1つのルマCBのみ、または2つのクロマCBsのみを含む。
【0085】
[94]実施形態によれば、QTBTパーティションスキームには以下のパラメータが定義されている。
- CTUサイズ:四分木のルートノードサイズで、HEVCでのものと同じ概念である。
- MinQTSize:最小許容四分木リーフノードサイズ、
- MaxBTSize:最大許容二分木ルートノードサイズ、
- MaxBTDepth:最大許容二分木深度、
- MinBTSize:最小許容二分木リーフノードサイズ。
【0086】
[95]QTBTパーティション構造の一例では、CTUサイズは、クロマサンプルの2つの対応する64×64ブロックを有する128×128ルマサンプルに設定され、MinQTSize(QTはQuad Tree)は16×16に設定され、MaxBTSizeは64×64に設定され、MinBTSize(幅と高さの両方)は4×4に設定され、MaxBTDepthは4に設定されている。四分木パーティションが、まずCTUに適用され、S12またはS15において四分木リーフノードが生成される。四分木リーフノードは、16×16(すなわち、MinQTSize)から128×128(すなわち、CTUサイズ)までのサイズを持つことができる。リーフ四分木ノードが128×128である場合、S14でチェックされたように、そのサイズがMaxBTSize(すなわち、64×64)を超えているので、二分木によってさらに分割されることはない。それ以外の場合、S15において、リーフ四分木ノードは、二分木によってさらにパーティションされる可能性がある。したがって、四分木リーフノードは、二分木のルートノードでもあり、その二分木深度が0である。二分木深度がMaxBTDepth(すなわち、4)に達すると、S14ではそれ以上の分割は考慮されない。二分木ノードの幅がMinBTSize(すなわち、4)に等しい場合、S14ではそれ以上の水平分割は考慮されない。同様に、二分木ノードの高さがMinBTSizeに等しい場合、S14ではそれ以上の垂直分割は考慮されない。S16での信号は、QT/TT/BTサイズを記述するシンタックスに関して後述するように、S17において、予測および変換処理によってさらに処理される二分木のリーフノードなどの行列のために提供され、そのような予測および変換処理に関して本明細書で議論されたのと同様なように、更なるパーティションは行われない。また、このようなシグナリングは、例示的な実施形態に従って、図11に示されるように、S12の後のS13で提供されてもよい。JEMでは、最大CTUサイズは256×256ルマサンプルである。
【0087】
[96]さらに、実施形態によれば、QTBTスキームは、ルマおよびクロマが別々のQTBT構造を有する能力/柔軟性をサポートする。現在、PおよびBスライスの場合、1つのCTU内のルマおよびクロマコーディングツリーブロック(CTBs)は、同じQTBT構造を共有している。しかし、Iスライスの場合、ルマCTBはQTBT構造によってCUsにパーティションされ、クロマCTBsは別のQTBT構造によってクロマCUsにパーティションされる。これは、IスライスにおけるCUが、ルマ成分のコーディングブロックまたは2つのクロマ成分のコーディングブロックで構成され、PまたはBスライスのCUが、3つの色成分すべてのコーディングブロックで構成されることを意味する。
【0088】
[97]HEVCでは、動き補償のメモリアクセスを低減するために、小ブロックのインター予測が制限されているため、4×8および8×4ブロックでは双予測がサポートされず、4×4ブロックではインター予測がサポートされていない。JEM-7.0で実施されたQTBTでは、これらの制限が解除されている。
【0089】
[98]図10Cは、含まれるマルチタイプツリー(MTT)構造1002に関する簡略化されたブロック図1100 VVCを示しており、この構造は、図示された四分木(QT)と、ネストされた二分木(BT)および三重/三分木(TT)との組み合わせであるQT/BT/TTである。CTUまたはCUは、まずQTによって正方形のブロックに再帰的にパーティションされる。次に、各QTのリーフは、BTまたはTTによってさらにパーティションされ、ここで、BTおよびTT分割は再帰的に適用され、インターリーブされることができるが、それ以上のQTパーティションは適用されることができない。関連するすべての提案において、TTは、長方形のブロックを垂直または水平に1:2:1の割合で3つのブロックに分割する(したがって、2の累乗以外の幅と高さを回避する)。パーティションエミュレーション防止のために、MTTに典型的には追加の分割制約が課され、図10Cの簡略図1002に示されるように、ブロック1103(クワッド)、1104(バイナリー、JEM)、および1105(ターナリー)に対する、VVCにおけるQT/BT/TTブロックパーティションがあり、重複したパーティションを回避する(例えば、垂直/水平のターナリー分割の結果得られる中央のパーティションでの垂直/水平のバイナリー分割を禁止する)。BTおよびTTの最大深度に更なる制限が設けられることがある。
【0090】
[99]ここで、例示的な実施形態に従ってQT/TT/BTサイズを記述するための新しいシンタックスが設計されている。これらのシンタックスは、基数(base)をmin CB/QTからCTUに変更する。提案された方法では、例示的な実施形態に従って、QT/TT/BTサイズをより小さな数値を用いてシグナリングすることが可能となり、したがって、ビット効率などのコーディング効率の向上を達成することができる。
【0091】
[100]例示的な実施形態によれば、例示的な実施形態によるS16で述べたように、QT/TT/BTサイズを記述するシンタックスが変更され、本開示において、AとBとの間のデルタ値をシグナリングすると言う場合、AとBとの間のデルタ値の基数2の対数をシグナリングすることも意味し得ることが理解されるであろう。また、本開示において、Aの絶対値をシグナリングすると言う場合、Aの絶対値の基数2の対数をシグナリングすることも意味し得る。
【0092】
[101]例示的な実施形態によれば、シグナリングは、QT/TT/BTサイズとCTUサイズとの間のデルタ値をシグナリングすることを含んでもよい。
【0093】
[102]例示的な実施形態によれば、シグナリングは、デルタシグナリングを行わずに、QT/TT/BTの絶対値を明示的にシグナリングすることを含んでもよい。
【0094】
[103]例示的な実施形態によれば、シグナリングは、QT/TT/BTサイズとmin CBサイズとの間のデルタ値をシグナリングすることを含んでもよい。
【0095】
[104]例示的な実施形態によれば、シグナリングは、QT/TT/BTサイズとmin QTサイズとの間のデルタ値をシグナリングすることを含んでもよい。
【0096】
[105]例示的な実施形態によれば、シグナリングは、QT/TT/BTサイズと任意の事前定義された値との間のデルタ値をシグナリングすることを含んでもよい。
【0097】
[106]例示的な実施形態によれば、シグナリングは、QT/TT/BTサイズと、任意のパラメータセット(デコードパラメータセット(DPS)、ビデオパラメータセット(VPS)、シーケンスパラメータセット(SPS)、ピクチャパラメータセット(PPS)および/または適応パラメータセット(APS))でシグナリングされる任意の値との間のデルタ値をシグナリングすることを含んでもよい。
【0098】
[107]例示的な実施形態によれば、SPSおよびスライスヘッダに関する修正されたVVC Draft 6を以下に示し、変更点は太字で強調され、取り消し線は削除されたテキストを示す。
【0099】
【表3】
【0100】
【表4】
【0101】
[108]例示的な実施形態によれば、sps_log2_diff_ctu_min_qt_intra_slice_lumaは、SPSを参照した、CTUを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズの基数2の対数(slice_typeが2(I)に等しいスライス内のルマCUsのルマサンプルにおける最小コーディングブロックサイズの基数2の対数を伴うかまたは伴わない)と、ctuサイズの基数2の対数との間のデフォルトの差分を指定する。partition_constraints_override_flagが1に等しい場合、デフォルトの差分は、SPSを参照したスライスのスライスヘッダに存在するslice_log2_diff_ctu_min_qt_lumaによって上書きされることができる。sps_log2_diff_ctu_min_qt_intra_slice_lumaの値は、0以上CtbLog2SizeY - MinCbLog2SizeY以下の範囲とされる。CTUを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズの基数2の対数は、以下のように導出される。
MinQtLog2SizeIntraY = log2_ctu_size_minus5 + 5 - sps_log2_diff_ctu_min_qt_intra_slice_luma - 式(7-24)
【0102】
[109]例示的な実施形態によれば、sps_log2_diff_ctu_min_qt_inter_sliceは、四分木分割およびSPSへの参照の結果得られるルマリーフブロックのルマサンプルにおける最小サイズの基数2の対数と、ctuサイズの基数2の対数との間のデフォルトの差分を指定する。partition_constraints_override_flagが1に等しい場合、デフォルトの差分は、SPSを参照したスライスのスライスヘッダに存在するslice_log2_diff_ctu_min_qt_lumaによって上書きされることができる。sps_log2_diff_ctu_min_qt_inter_sliceの値は、0以上CtbLog2SizeY - MinCbLog2SizeY以下の範囲とされる。CTUを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズの基数2の対数は、以下のように導出される。
MinQtLog2SizeInterY = log2_ctu_size_minus5 + 5 - sps_log2_diff_ctu_min_qt_inter_slice - 式(7-25)
【0103】
[110]例示的な実施形態によれば、sps_log2_diff_ctu_max_bt_intra_slice_lumaは、SPSを参照した、バイナリー分割を用いて分割可能なルマコーディングブロックのルマサンプルにおける最大サイズ(幅または高さ)の基数2の対数(slice_typeが2(I)に等しいスライス内のCTUを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズ(幅または高さ)を伴うかまたは伴わない)と、ctuサイズの基数2の対数との間のデフォルトの差分を指定する。partition_constraints_override_ flagが1に等しい場合、デフォルトの差分は、SPSを参照したスライスのスライスヘッダに存在するslice_log2_diff_ctu_max_bt_lumaによって上書きされることができる。sps_log2_diff_ctu_max_bt_intra_slice_lumaの値は、0以上CtbLog2SizeY - MinQtLog2SizeIntraY以下の範囲とされる。sps_log2_diff_ctu_max_bt_intra_slice_lumaが存在しない場合、sps_log2_diff_ctu_max_bt_intra_slice_lumaの値は0に等しいと推測される。
【0104】
[111]例示的な実施形態によれば、sps_log2_diff_ctu_max_tt_intra_slice_lumaは、SPSを参照した、ターナリー分割を用いて分割可能なルマコーディングブロックのルマサンプルにおける最大サイズ(幅または高さ)の基数2の対数(slice_typeが2(I)に等しいスライス内のCTUを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズ(幅または高さ)を伴うかまたは伴わない)と、ctuサイズの基数2の対数との間のデフォルトの差分を指定する。partition_constraints_override_ flagが1に等しい場合、デフォルトの差分は、SPSを参照したスライスのスライスヘッダに存在するslice_log2_diff_ctu_max_tt_lumaによって上書きされることができる。sps_log2_diff_ctu_max_tt_intra_slice_lumaの値は、0以上CtbLog2SizeY - MinQtLog2SizeIntraY以下の範囲とされる。sps_log2_diff_ctu_max_tt_intra_slice_lumaが存在しない場合、sps_log2_diff_ctu_max_tt_intra_slice_lumaの値は0に等しいと推測される。
【0105】
[112]例示的な実施形態によれば、sps_log2_diff_ctu_max_bt_inter_sliceは、SPSを参照した、バイナリー分割を用いて分割可能なルマコーディングブロックのルマサンプルにおける最大サイズ(幅または高さ)の基数2の対数(slice_typeが0(B)または1(P)に等しいスライス内のCTUを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズ(幅または高さ)を伴うかまたは伴わない)と、ctuサイズの基数2の対数との間のデフォルトの差分を指定する。partition_constraints_override_ flagが1に等しい場合、デフォルトの差分は、SPSを参照したスライスのスライスヘッダに存在するslice_log2_diff_ctu_max_bt_lumaによって上書きされることができる。sps_log2_diff_ctu_max_bt_inter_sliceの値は、0以上CtbLog2SizeY - MinQtLog2SizeInterY以下の範囲とされる。sps_log2_diff_ctu_max_bt_inter_sliceが存在しない場合、sps_log2_diff_ctu_max_bt_inter_sliceの値は0に等しいと推測される。
【0106】
[113]例示的な実施形態によれば、sps_log2_diff_ctu_max_tt_inter_sliceは、SPSを参照した、ターナリー分割を用いて分割可能なルマコーディングブロックのルマサンプルにおける最大サイズ(幅または高さ)の基数2の対数(およびslice_typeが0(B)または1(P)に等しいスライス内のCTUを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズ(幅または高さ))と、ctuサイズの基数2の対数との間のデフォルトの差分を指定する。partition_constraints_override_flagが1に等しい場合、デフォルトの差分は、SPSを参照したスライスのスライスヘッダに存在するslice_log2_diff_ctu_max_tt_lumaによって上書きされることができる。sps_log2_diff_ctu_max_tt_inter_sliceの値は、0以上CtbLog2SizeY - MinQtLog2SizeInterY以下の範囲とされる。sps_log2_diff_ctu_max_tt_inter_sliceが存在しない場合、sps_log2_diff_ctu_max_tt_inter_sliceの値は0に等しいと推測される。
【0107】
[114]例示的な実施形態によれば、sps_log2_diff_ctu_max_bt_intra_slice_chromaは、SPSを参照した、バイナリー分割を用いて分割可能なクロマコーディングブロックのルマサンプルにおける最大サイズ(幅または高さ)の基数2の対数(slice_typeが2(I)に等しいスライスにおける、treeTypeがDUAL_TREE_CHROMAに等しいクロマCTUを四分木分割した結果得られるクロマリーフブロックのルマサンプルにおける最小サイズ(幅または高さ)を伴うかまたは伴わない)と、ctuサイズの基数2の対数との間のデフォルトの差分を指定する。partition_constraints_override_flagが1に等しい場合、デフォルトの差分は、SPSを参照したスライスのスライスヘッダに存在するslice_log2_diff_ctu_max_bt_chromaによって上書きされることができる。sps_log2_diff_ctu_max_bt_intra_slice_chromaの値は、0以上CtbLog2SizeY - MinQtLog2SizeIntraC以下の範囲とされる。sps_log2_diff_ctu_max_bt_intra_slice_chromaが存在しない場合、sps_log2_diff_ctu_max_bt_intra_slice_chromaの値は0に等しいと推測される。
【0108】
[115]例示的な実施形態によれば、sps_log2_diff_ctu_max_tt_intra_slice_chromaは、SPSを参照した、ターナリー分割を用いて分割可能なクロマコーディングブロックのルマサンプルにおける最大サイズ(幅または高さ)の基数2の対数(slice_typeが2(I)に等しいスライスにおける、treeTypeがDUAL_TREE_CHROMAに等しいクロマCTUを四分木分割した結果得られるクロマリーフブロックのルマサンプルにおける最小サイズ(幅または高さ)を伴うかまたは伴わない)と、ctuサイズの基数2の対数との間のデフォルトの差分を指定する。partition_constraints_override_flagが1に等しい場合、デフォルトの差分は、SPSを参照したスライスのスライスヘッダに存在するslice_log2_diff_ctu_max_tt_chromaによって上書きされることができる。sps_log2_diff_ctu_max_tt_intra_slice_chromaの値は、0以上CtbLog2SizeY - MinQtLog2SizeIntraC以下の範囲とされる。sps_log2_diff_ctu_max_tt_intra_slice_chromaが存在しない場合、sps_log2_diff_ctu_max_tt_intra_slice_chromaの値は0に等しいと推測される。
【0109】
[116]例示的な実施形態によれば、slice_log2_diff_ctu_min_qt_lumaは、現在のスライスにおける、CTUを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズの基数2の対数(ルマCUsのルマサンプルにおける最小コーディングブロックサイズの基数2の対数を伴うかまたは伴わない)と、ctuサイズの基数2の対数との間の差分を指定する。slice_log2_diff_ctu_min_qt_lumaの値は、0以上CtbLog2SizeY - MinCbLog2SizeY以下の範囲とされる。存在しない場合、slice_log2_diff_ctu_min_qt_lumaの値は以下のように推測される。
- slice_typeが2(I)に等しい場合、slice_log2_diff_ctu_min_qt_lumaの値は、sps_log2_diff_ctu_min_qt_intra_slice_lumaに等しいと推測される。
- それ以外の場合(slice_typeが0(B)または1(P)に等しい)、slice_log2_diff_ctu_min_qt_lumaの値は、sps_log2_diff_ctu_min_qt_inter_sliceに等しいと推測される。
【0110】
[117]例示的な実施形態によれば、slice_log2_diff_ctu_max_bt_lumaは、現在のスライスにおける、CTUを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズ(幅または高さ)、および、バイナリー分割を用いて分割可能なルマコーディングブロックのルマサンプルにおける最大サイズ(幅または高さ)の基数2の対数と、ctuサイズの基数2の対数との間の差分を指定する。slice_log2_diff_ctu_max_bt_lumaの値は、0以上CtbLog2SizeY - MinQtLog2SizeY以下の範囲とされる。存在しない場合、slice_log2_diff_ctu_max_bt_lumaの値は、以下のように推測される。
- slice_typeが2(I)に等しい場合、slice_log2_diff_ctu_max_bt_lumaの値は、sps_log2_diff_ctu_max_bt_intra_slice_lumaに等しいと推測される。
- それ以外の場合(slice_typeが0(B)または1(P)に等しい)、slice_log2_diff_ctu_max_bt_lumaの値は、sps_log2_diff_ctu_max_bt_inter_sliceに等しいと推測される。
【0111】
[118]例示的な実施形態によれば、slice_log2_diff_ctu_max_tt_lumaは、現在のスライスにおける、ターナリー分割を用いて分割可能なルマコーディングブロックのルマサンプルにおける最大サイズ(幅または高さ)の基数2の対数(CTUを四分木分割した結果得られるルマリーフブロックのルマサンプルにおける最小サイズ(幅または高さ)を伴うかまたは伴わない)と、ctuサイズの基数2の対数との間の差分を指定する。slice_log2_diff_ctu_max_tt_lumaの値は、0以上CtbLog2SizeY - MinQtLog2SizeY以下の範囲とされる。存在しない場合、slice_log2_diff_ctu_max_tt_lumaの値は、以下のように推測される。
- slice_typeが2(I)に等しい場合、slice_log2_diff_ctu_max_tt_lumaの値は、sps_log2_diff_ctu_max_tt_intra_slice_lumaに等しいと推測される。
- それ以外の場合(slice_typeが0(B)または1(P)に等しい)、slice_log2_diff_ctu_max_tt_lumaの値は、sps_log2_diff_ctu_max_tt_inter_sliceに等しいと推測される。
【0112】
[119]例示的な実施形態によれば、slice_log2_diff_ctu_min_qt_chromaは、現在のスライスにおける、treeTypeがDUAL_TREE_CHROMAに等しいクロマCTUを四分木分割した結果得られるクロマリーフブロックのルマサンプルにおける最小サイズの基数2の対数(treeTypeがDUAL_TREE_CHROMAに等しいクロマCUsのルマサンプルにおける最小コーディングブロックサイズの基数2の対数を伴うかまたは伴わない)と、ctuサイズの基数2の対数との間の差分を指定する。slice_log2_diff_ctu_min_qt_chromaの値は、0以上CtbLog2SizeY - MinCbLog2SizeY以下の範囲とされる。存在しない場合、slice_log2_diff_ctu_min_qt_chromaの値は、sps_log2_diff_ctu_min_qt_intra_slice_chromaに等しいと推測される。
【0113】
[120]例示的な実施形態によれば、slice_log2_diff_ctu_max_bt_chromaは、現在のスライスにおける、バイナリー分割を用いて分割可能なクロマコーディングブロックのルマサンプルにおける最大サイズ(幅または高さ)の基数2の対数(treeTypeがDUAL_TREE_CHROMAに等しいクロマCTUを四分木分割した結果得られるクロマリーフブロックのルマサンプルにおける最小サイズ(幅または高さ)を伴うかまたは伴わない)と、ctuサイズの基数2の対数との間の差分を指定する。slice_log2_diff_ctu_max_bt_chromaの値は、0以上CtbLog2SizeY - MinQtLog2SizeC以下の範囲とされる。存在しない場合、slice_log2_diff_ctu_max_bt_chromaの値は、sps_log2_diff_ctu_max_bt_intra_slice_chromaに等しいと推測される。
【0114】
[121]例示的な実施形態によれば、slice_log2_diff_ctu_max_tt_chromaは、現在のスライスにおける、ターナリー分割を用いて分割可能なクロマコーディングブロックのルマサンプルにおける最大サイズ(幅または高さ)(およびtreeTypeがDUAL_TREE_CHROMAに等しいクロマCTUを四分木分割した結果得られるクロマリーフブロックのルマサンプルにおける最小サイズ(幅または高さ))の基数2の対数と、ctuサイズの基数2の対数との間の差分を指定する。slice_log2_diff_ctu_max_tt_chromaの値は、0以上CtbLog2SizeY - MinQtLog2SizeC以下の範囲とされる。存在しない場合、slice_log2_diff_ctu_max_tt_chromaの値は、sps_log2_diff_ctu_max_tt_intra_slice_chromaに等しいと推測される。
【0115】
[122]本明細書に記載されているように、例示的な実施形態に従って本明細書に記載されている値の間の所定のデルタ値(差)を決定または記憶するように構成される、バッファ、算術論理ユニット、メモリ命令のような1つまたは複数のハードウェアプロセッサおよびコンピュータコンポーネントが存在してもよい。
【0116】
[123]したがって、本明細書に記載された例示的な実施形態により、上述した技術的課題は、これらの技術的な解決策の1つまたは複数によって有利に改善され得る。つまり、実施形態によれば、1つまたは複数の異なる技術的課題に対処するために、本開示では、QT/TT/BTサイズを記述するように設計された新しいシンタックスおよびその使用について説明した。実施形態によれば、これらのシンタックスは、基数をmin CB/QTからCTUに変更しており、実施形態では、QT/TT/BTサイズをより小さな数値を用いてシグナリングすることが可能となる。したがって、コーディング効率の向上を図ることができる。
【0117】
[124]以上で説明された手法は、コンピュータ読取可能な命令を使用するコンピュータソフトウェアとして実施されることができ、1つまたは複数のコンピュータ読取可能な媒体に物理的に記憶されるか、または特別に構成された1つまたは複数のハードウェアプロセッサによって記憶されることができる。例えば、図12は、開示された主題の特定の実施形態を実施することに適したコンピュータシステム1200を示す。
【0118】
[125]コンピュータソフトウェアは、アセンブリ、コンパイル、リンク、またはそのようなメカニズムを施されて、コンピュータ中央処理装置(CPUs)、グラフィックスプロセッシングユニット(GPUs)などによって直接、または解釈、マイクロコード実行などによって実行されることができる命令を含むコードを作成する任意の適切な機械コードまたはコンピュータ言語を用いてコード化されることができる。
【0119】
[126]命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、モノのインターネットデバイスなどを含む、様々なタイプのコンピュータまたはそのコンポーネント上で実行されることができる。
【0120】
[127]コンピュータシステム1200について、図12に示される例示的なコンポーネントは、本質的に例示的なものであり、本開示の実施形態を実施するコンピュータソフトウェアの使用または機能の範囲に関していかなる限定を示唆することも意図しない。コンポーネントの構成は、コンピュータシステム1200の例示的な実施形態で示されるコンポーネントのうちのいずれか1つ又は組み合わせに関する任意の依存性又は必要性を有するとして解釈されるべきではない。
【0121】
[128]コンピュータシステム1200は、特定のヒューマンインターフェース入力デバイスを含み得る。このようなヒューマンインターフェース入力デバイスは、例えば、触覚入力(キーストローク、スワイプ、データグローブの動きなど)、オーディオ入力(音声、拍手など)、視覚入力(ジェスチャーなど)、嗅覚入力(図示せず)によって、1人以上のユーザによる入力に応答することができる。ヒューマンインターフェースデバイスは、オーディオ(音声、音楽、環境音など)、画像(走査画像、静止画像カメラから取得される写真画像など)、ビデオ(2次元ビデオ、立体ビデオを含む3次元ビデオなど)など、人間による意識的な入力に必ずしも直接関係しない特定のメディアをキャプチャすることにも使用できる。
【0122】
[129]入力ヒューマンインターフェースデバイスは、キーボード1201、マウス1202、トラックパッド1203、タッチスクリーン1210、ジョイスティック1205、マイクフォン1206、スキャナ1208、カメラ1207(それぞれ1つのみ示されている)のうちの1つまたは複数を含み得る。
【0123】
[130]コンピュータシステム1200は、特定のヒューマンインターフェース出力デバイスをも含み得る。このようなヒューマンインターフェース出力デバイスは、例えば、触覚出力、音声、光、および嗅覚/味覚を介して1人以上のユーザの感覚を刺激し得る。このようなヒューマンインターフェース出力デバイスは、触覚出力デバイス(例えば、タッチスクリーン1210、またはジョイスティック1205による触覚フィードバックがあるが、入力デバイスとして機能しない触覚フィードバックデバイスであってもよい)、オーディオ出力デバイス(スピーカ1209、ヘッドホン(図示せず)など)、視覚出力デバイス(CRTスクリーン、LCDスクリーン、プラズマスクリーン、OLEDスクリーンを含むスクリーン1210(それぞれタッチスクリーン入力能力を有するかもしくは有せず、それぞれ触覚フィードバック能力を有するかもしくは有しない。それらの一部は、ステレオグラフィック出力などの手段を介して、2次元の視覚出力または3次元以上の出力を出力することができる)、仮想現実眼鏡(図示せず)、ホログラフィックディスプレおよびスモークタンク(図示せず)など)、およびプリンタ(図示せず)を含み得る。
【0124】
[131]コンピュータシステム1200は、人間がアクセス可能な記憶装置およびそれらの関連する媒体、例えば、CD/DVD1211などの媒体付きのCD/DVD ROM/RW1220を含む光学媒体、サムドライブ1222、リムーバブルハードドライブまたはソリッドステートドライブ1223、テープやフロッピーディスクなどの従来の磁気媒体(図示せず)、セキュリティドングルなどの専用のROM/ASIC/PLDベースのデバイス(図示せず)などをも含むことができる。
【0125】
[132]ここで開示された主題に関連して使用される「コンピュータ読取可能な媒体」という用語は、送信媒体、搬送波、または他の一時的な信号を包含しないことをも当業者が理解するべきである。
【0126】
[133]コンピュータシステム1200は、1つまたは複数の通信ネットワーク1298へのインターフェース1299をさらに含むことができる。ネットワーク1298は、例えば、無線、有線、光学的であり得る。ネットワーク1298は、さらに、ローカル、広域、大都市圏、車両用および産業用、リアルタイム、遅延耐性などであり得る。ネットワーク1298の例は、イーサネット、無線LANsなどのローカルエリアネットワーク、GSM、3G、4G、5G、LTEなどを含むセルラーネットワーク、ケーブルTV、衛星TV、および地上放送TVを含むTV有線または無線広域デジタルネットワーク、CANBusを含む車両用や産業用などを含む。特定のネットワーク1298は、一般に、特定の汎用データポートまたは周辺バス(1250および1251)(例えば、コンピューターシステム1200のUSBポートなど)に接続された外部ネットワークインターフェースアダプターを必要とする。他のものは一般に、以下に説明するようにシステムバスに接続することにより、コンピューターシステム1200のコアに統合される(例えば、PCコンピューターシステムへのイーサネットインターフェースまたはスマートフォンコンピューターシステムへのセルラーネットワークインターフェース)。これらのネットワーク1298のいずれかを用いて、コンピュータシステム1200は、他のエンティティと通信することができる。このような通信は、単方向、受信のみ(例えば、放送TV)、単方向の送信のみ(例えば、特定のCANbusデバイスへのCANbus)、または双方向、例えばローカルまたはワイドエリアデジタルネットワークを用いる他のコンピュータシステムへの送信であり得る。特定のプロトコルおよびプロトコルスタックを上述したこれらのネットワークおよびネットワークインターフェースのそれぞれで使用することができる。
【0127】
[134]前述のヒューマンインターフェースデバイス、人間がアクセス可能な記憶装置、およびネットワークインターフェースは、コンピュータシステム1200のコア1240に接続されることができる。
【0128】
[135]コア1240は、1つまたは複数の中央処理装置(CPU)1241、グラフィックスプロセッシングユニット(GPU)1242、グラフィックスアダプタ1217、フィールドプログラマブルゲートエリア(FPGA)1243の形態での専用プログラマブル処理ユニット、特定のタスクのためのハードウェアアクセラレータ1244などを含むことができる。これらのデバイスは、リードオンリーメモリ(ROM)1245、ランダムアクセスメモリ1246、非ユーザアクセス可能な内部ハードドライブ、SSDsなどの内部大容量記憶装置1247とともに、システムバス1248を介して接続されてもよい。一部のコンピュータシステムでは、システムバス1248は、1つまたは複数の物理プラグの形態でアクセスでき、追加のCPUs、GPUなどによる拡張を可能にする。周辺機器は、コアのシステムバス1248に直接、または周辺バス1251を介して接続されることができる。周辺バスのアーキテクチャは、PCI、USBなどを含む。
【0129】
[136]CPUs 1241、GPUs 1242、FPGAs 1243、およびアクセラレータ1244は、組み合わせて、前述のコンピュータコードを構成することができる特定の命令を実行することができる。そのコンピュータコードは、ROM 1245またはRAM 1246に記憶されることができる。推移データはRAM 1246にも記憶できるが、永続データは、例えば、内部大容量ストレージ1247に記憶されることができる。1つまたは複数のCPU 1241、GPU 1242、大容量ストレージ1247、ROM 1245、RAM 1246などと密接に関連付けることができるキャッシュメモリを使用することにより、任意のメモリデバイスへの高速保存および検索が可能になる。
【0130】
[137]コンピュータ読取可能な媒体は、様々なコンピュータ実施操作を実行するためのコンピュータコードを備えることができる。媒体およびコンピュータコードは、本開示の目的のために特別に設計および構築されたものであり得るか、もしくは、それらは、コンピュータソフトウェア技術の当業者に周知であって利用可能な種類のものであり得る。
【0131】
[138]限定ではなく、一例として、アーキテクチャを有するコンピュータシステム1200、特にコア1240は、1つまたは複数の有形のコンピュータ読取可能な媒体に組み込まれたソフトウェアを実行するプロセッサ(CPU、GPU、FPGA、アクセラレータなどを含む)の結果としての機能性を提供することができる。このようなコンピュータ読取可能な媒体は、以上で説明したようにユーザがアクセス可能な大容量ストレージ、および、コア内部大容量ストレージ1247またはROM 1245などの非一時的な性質を持つコア1240の特定のストレージに関連付けられた媒体であり得る。本開示の様々な実施形態を実行するソフトウェアは、このようなデバイスに記憶され、コア1240によって実行されることができる。コンピュータ読取可能な媒体は、特定の必要に応じて、1つまたは複数のメモリデバイスまたはチップを含むことができる。ソフトウェアは、コア1240、具体的にはその中のプロセッサ(CPU、GPU、FPGAなどを含む)に、RAM 1246に記憶されたデータ構造を定義すること、および、ソフトウェアで定義されたプロセスに従ってこのようなデータ構造を変更する言を含む、ここで説明する特定のプロセスまたは特定のプロセスの特定の部分を実行させることができる。加えて、または、代替として、コンピュータシステムは、本明細書に記載された特定のプロセスまたは特定のプロセスの特定の部分を実行するためにソフトウェアの代わりにまたは一緒に動作することができる回路(例えば、アクセラレータ1244)に有線接続されたまたは組み込まれたロジックの結果としての機能性を提供することができる。ソフトウェアへの言及は、必要に応じて、ロジックを含むことができ、その逆も同様である。コンピュータ読取可能な媒体への言及は、必要に応じて、実行のためのソフトウェアを記憶する回路(集積回路(IC)など)、実行のためのロジックを具現化する回路、またはその両方を含むことができる。本開示は、ハードウェアとソフトウェアの任意の適切な組み合わせを含む。
【0132】
[139]本開示は一部の例示的な実施形態を説明してきたが、本開示の範囲内に含まれる変更、置換、および様々な代替の均等物が存在する。したがって、当業者は、本明細書では明示的に示されていないか、または記載されていないが、本開示の原理を具現化し、その思想および範囲内に含まれる様々なシステムおよび方法を考案できることが理解されよう。
【符号の説明】
【0133】
100 通信システム
101,102,103,104 端末
105 ネットワーク
図1
図2
図3
図4
図5
図6
図7
図8
図9A
図9B
図10A
図10B
図10C
図11
図12