(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-04-19
(45)【発行日】2022-04-27
(54)【発明の名称】フレキシブルなツリー構造における連結符号化単位
(51)【国際特許分類】
H04N 19/96 20140101AFI20220420BHJP
H04N 19/70 20140101ALI20220420BHJP
【ＦＩ】
H04N19/96
H04N19/70
【請求項の数】
14
(21)【出願番号】P 2020550637
(86)(22)【出願日】2019-03-26
(65)【公表番号】
(43)【公表日】2021-07-08
(86)【国際出願番号】 US2019023993
(87)【国際公開番号】W WO2019195026
(87)【国際公開日】2019-10-10
【審査請求日】2020-09-18
(31)【優先権主張番号】62/651,566
(32)【優先日】2018-04-02
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】16/232,752
(32)【優先日】2018-12-26
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】520353802
【氏名又は名称】テンセント・アメリカ・エルエルシー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】リ，シアン
(72)【発明者】
【氏名】ジャオ，シン
(72)【発明者】
【氏名】リィウ，シャン
【審査官】坂東 大五郎
(56)【参考文献】
【文献】国際公開第２０１８／０５６７０３（ＷＯ，Ａ１）
【文献】Xiang Li et al.，Multi-Type-Tree，Joint Video Exploration Team (JVET)，2016年10月20日，[JVET-D0117r1] (version 3)
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｎ １９／００－１９／９８
(57)【特許請求の範囲】
【請求項1】
映像シーケンスを符号化するためにツリー構造にて親符号化単位（ＣＵ）を分割する方法であって、前記親ＣＵを、第１のＣＵ及び第２のＣＵを含む３つ以上のＣＵに分割し、且つ
前記第２のＣＵを前記第１のＣＵに連結することによって連結ＣＵを生成する、
ことを有し、
前記ツリー構造は三分木構造を含み、
前記３つ以上のＣＵは第３のＣＵを含み、
前記第３のＣＵは、前記第１のＣＵと前記第２のＣＵとの間に位置し、連結される前記第１のＣＵ及び前記第２のＣＵは互いに隣接しない、
方法。
【請求項2】
ＣＵレベル構文要素又はＣＵレベル符号化ツールのうちの少なくとも一方が、前記連結ＣＵに適用される、請求項１に記載の方法。
【請求項3】
前記第１のＣＵは、前記第３のＣＵの左又は上に位置し、前記第２のＣＵは、前記第３のＣＵの右又は下に位置する、請求項１又は２に記載の方法。
【請求項4】
前記第３のＣＵの動き情報を予測するときに、前記第２のＣＵからの動き情報が使用される、請求項３に記載の方法。
【請求項5】
前記第２のＣＵは、前記連結ＣＵのサイズが最大ＣＵサイズよりも小さいように、且つ前記連結ＣＵのサイズが利用可能な変換サイズに適合するように選択される、請求項１乃至４のいずれか一項に記載の方法。
【請求項6】
前記連結ＣＵのサイズが利用可能な変換サイズに適合しない場合、当該方法は更に、前記連結ＣＵを、各々が前記利用可能な変換サイズに適合する複数のサブブロックに分割することを有する、請求項１乃至５のいずれか一項に記載の方法。
【請求項7】
前記ツリー構造は更に、四分木－二分木構造、マルチタイプツリー構造、及び非対称二分木構造のうちの少なくとも１つを含む、請求項１乃至６のいずれか一項に記載の方法。
【請求項8】
シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、又はスライスヘッダのうちの少なくとも１つが、連結が許されることのインジケーションを含む、請求項１乃至７のいずれか一項に記載の方法。
【請求項9】
前記第１のＣＵ及び前記第２のＣＵは、前記親ＣＵから分割された他のＣＵとのみ連結することができる、請求項１乃至８のいずれか一項に記載の方法。
【請求項10】
映像シーケンスを符号化するためにツリー構造にて親符号化単位（ＣＵ）を分割する装置であって、プログラムコードを格納するように構成された少なくとも１つのメモリと、
前記プログラムコードを読み出し、前記プログラムコードによって命令されるように動作するよう構成された少なくとも１つのプロセッサと、
を有し、
前記プログラムコードは、
前記少なくとも１つのプロセッサに、前記親ＣＵを、第１のＣＵ及び第２のＣＵを含む３つ以上のＣＵへと分割させる、ように構成された分割コードと、
前記少なくとも１つのプロセッサに、前記第２のＣＵを前記第１のＣＵに連結することによって連結ＣＵを生成させる、ように構成された生成コードと、
を含み、
前記ツリー構造は三分木構造を含み、
前記３つ以上のＣＵは第３のＣＵを含み、
前記第３のＣＵは、前記第１のＣＵと前記第２のＣＵとの間に位置し、連結される前記第１のＣＵ及び前記第２のＣＵは互いに隣接しない、
装置。
【請求項11】
前記連結ＣＵのサイズが利用可能な変換サイズに適合しない場合、前記分割コードは、前記少なくとも１つのプロセッサに、前記連結ＣＵを、各々が前記利用可能な変換サイズに適合する複数のサブブロックへと分割させる、ように構成される、請求項１０に記載の装置。
【請求項12】
前記第１のＣＵは、前記第３のＣＵの左又は上に位置し、前記第２のＣＵは、前記第３のＣＵの右又は下に位置する、請求項１０又は１１に記載の装置。
【請求項13】
前記第３のＣＵの動き情報を予測するときに、前記第２のＣＵからの動き情報が使用される、請求項１２に記載の装置。
【請求項14】
１つ以上のプロセッサに請求項１乃至９のいずれか一項に記載の方法を実行させるプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
この出願は、米国特許商標庁に２０１８年４月２日に出願された米国特許出願第６２／６５１，５６６号に対する優先権を主張するものであり、その開示をその全体にてここに援用する。
【0002】
本開示は、ハイブリッド映像符号化における進歩的なブロック分割（block partitioning）に関する。より具体的には、効率的なブロック分割のためにフレキシブルなツリー構造にて連結される符号化単位（ＣＵ）が開示される。
【背景技術】
【0003】
ＩＴＵ－Ｔ ＶＣＥＧ（Ｑ６／１６）及びＩＳＯ／ＩＥＣ ＭＰＥＧ（ＪＴＣ１／ＳＣ２９／ＷＧ１１）は、２０１３年（第１版）、２０１４年（第２版）、２０１５年（第３版）、そして２０１６年（第４版）に、Ｈ．２６５／ＨＥＶＣ（High Efficiency Video Coding）標準を発行した。それ以降、彼らは、ＨＥＶＣ規格（その拡張を含む）の圧縮能力を大幅に上回る圧縮能力を持つ将来の映像符号化技術の標準化の潜在的ニーズを研究している。これらグループは、彼らのこの分野の専門家によって提案された圧縮技術設計を評価するために、ＪＶＥＴ（Joint Video Exploration Team）として知られる共同協力の取り組みにて、この探索活動に協働している。ＨＥＶＣの能力を超える映像符号化技術を探索するためにＪＶＥＴによって共同探索モデル（Joint Exploration Model；ＪＥＭ）が開発され、ＪＥＭの現在の最新版はＪＥＭ－７．０である。ＪＥＭソフトウェアは、ＨＥＶＣ基準ソフトウェアＨＭに対する大幅の改善を示しており、ＨＥＶＣを超える能力を持つ映像圧縮に関する共同の提案募集（Call for Proposal）が２０１７年１０月に発行されている。新たな世代の映像符号化標準が開発中である。
【0004】
ＨＥＶＣでは、符号化ツリー単位（coding tree unit；ＣＴＵ）が、様々な局所的特性に適応するために、符号化ツリーと呼ばれるクワッド四分木構造を用いることによって複数の符号化単位（coding unit；ＣＵ）に分割される。画像領域を、画像間（時間的）予測を用いて符号化するのか、それとも画像内（空間的）予測を用いて符号化するのかの決定が、ＣＵレベルで行われる。各ＣＵは更に、予測単位（prediction unit；ＰＵ）分割タイプに従って、１つ、２つ、又は４つのＰＵに分割されることができる。１つのＰＵ内では、同じ予測プロセスが適用され、関連情報がＰＵベースでデコーダに伝えられる。ＰＵ分割タイプに基づく予測プロセスを適用することによって残余ブロックを得た後に、ＣＵは、そのＣＵ用の符号化ツリーのような別の四分木構造に従って複数の変換単位（transform unit；ＴＵ）へと分割されることができる。ＨＥＶＣ構造の重要な特徴の１つは、ＣＵ、ＰＵ、及びＴＵを含む複数の分割概念を持つことである。ＨＥＶＣでは、ＣＵ又はＴＵは正方形の形状であることができるのみであり、一方、ＰＵは、インター予測されるブロックで、正方形又は長方形にされ得る。後期のＨＥＶＣにおいて、一部の投稿が、長方形のＰＵをイントラ予測及び変換に可能にすることを提案した。これらの提案は、ＨＥＶＣには採用されなかったが、ＪＥＭで使用されるように拡張された。
【0005】
画像境界において、ＨＥＶＣは、サイズが画像境界に適合するまでブロックが四分木分割を維持することになるように、暗黙の四分木分割を強いている。
【0006】
以前の研究に触発されて、ＣＵ、ＰＵ及びＴＵの概念を一元化してＣＵ分割形状に関するいっそうの柔軟性をサポートするために、四分木－二分木（Quad-tree-Binary-tree；ＱＴＢＴ）構造が開発された。ＱＴＢＴブロック構造では、ＣＵは正方形又は長方形のいずれかの形状を持つことができる。図１に示すように、先ず、符号化ツリー単位（coding tree unit；ＣＴＵ）が四分木構造によって分割される。四分木リーフノードが更に、二分木構造によって分割される。二分木分割には、対称水平分割及び対称垂直分割という２つの分割タイプが存在する。これらの二分木リーフノードが符号化単位（ＣＵ）と呼ばれ、そのセグメンテーションが、更なる分割なしで、予測及び変換の処理に使用される。これは、ＱＴＢＴ符号化ブロック構造ではＣＵ、ＰＵ、及びＴＵが同じブロックサイズを持つことを意味する。ＪＥＭでは、ＣＵは、時にして、異なる色成分の符号化ブロック（coding block；ＣＢ）で構成されることがあり、例えば、４：２：０クロマフォーマットのＰ及びＢスライスの場合に１つのＣＵが１つのルマ（luma）ＣＢと２つのクロマ（chroma）ＣＢを含むことがあり、また時にして、単一成分のＣＢで構成されることがあり、例えば、Ｉスライスの場合に１つのＣＵが１つのルマＣＢのみ又は２つのクロマＣＢのみを含むことがある。
【0007】
以下のパラメータが、ＱＴＢＴ分割スキームのために定義されている：
－ ＣＴＵサイズ：ＨＥＶＣにおいてと同じ概念の、四分木のルートノードサイズ
－ ＭａｘＱＴＤｅｐｔｈ：最大許容四分木深さ
－ ＭｉｎＱＴＳｉｚｅ：最小許容四分木リーフノードサイズ
－ ＭａｘＢＴＳｉｚｅ：最大許容二分木ルートノードサイズ
－ ＭａｘＢＴＤｅｐｔｈ：最大許容二分木深さ
－ ＭｉｎＢＴＳｉｚｅ：最小許容二分木リーフノードサイズ。
－ ＣＴＵサイズ：ＨＥＶＣにおいてと同じ概念の、四分木のルートノードサイズ
－ ＭａｘＱＴＤｅｐｔｈ：最大許容四分木深さ
－ ＭｉｎＱＴＳｉｚｅ：最小許容四分木リーフノードサイズ
－ ＭａｘＢＴＳｉｚｅ：最大許容二分木ルートノードサイズ
－ ＭａｘＢＴＤｅｐｔｈ：最大許容二分木深さ
－ ＭｉｎＢＴＳｉｚｅ：最小許容二分木リーフノードサイズ。
【0008】
ＱＴＢＴ分割構造の一例において、ＣＴＵサイズは、２つの対応する６４×６４ブロックのクロマサンプルを備えた１２８×１２８ルマサンプルとして設定され、ＭｉｎＱＴＳｉｚｅは１６×１６として設定され、ＭａｘＢＴＳｉｚｅは６４×６４として設定され、ＭｉｎＢＴＳｉｚｅ（幅及び高さの両方に関して）は４×４として設定され、そして、ＭａｘＢＴＤｅｐｔｈは４として設定される。先ず、ＣＴＵに四分木分割が適用されて、四分木リーフノードが生成される。四分木リーフノードは、１６×１６（すなわち、ＭｉｎＱＴＳｉｚｅ）から１２８×１２８（すなわち、ＣＴＵサイズ）までのサイズを持ち得る。四分木リーフノードが１２８×１２８である場合、サイズがＭａｘＢＴＳｉｚｅ（すなわち、６４×６４）を超えているので、それは、二分木によって更に分割されることにはならない。それ以外の場合、四分木リーフノードは、二分木によって更に分割され得る。従って、四分木リーフノードは、二分木にとってのルートノードでもあり、それは０として二分木深さを持つ。二分木深さがＭａｘＢＴＤｅｐｔｈ（すなわち、４）に達すると、更なる分割は検討されない。二分木ノードがＭｉｎＢＴＳｉｚｅ（すなわち、４）に等しい幅を持つようになると、更なる水平分割は検討されない。同様に、二分木ノードがＭｉｎＢＴＳｉｚｅに等しい高さをもつようになると、更なる垂直分割は検討されない。二分木のリーフノードは、更なる分割なしで、予測及び変換処理によって更に処理される。ＪＥＭでは、最大ＣＴＵサイズは２５６×２５６ルマサンプルである。
【0009】
図１（左側）は、ＱＴＢＴを用いることによるブロック分割の一例を示し、図１（右側）は、対応するツリー表現を示している。実線は四分木分割を示し、点線は二分木分割を示している。二分木のノード（すなわち、非リーフノード）の各分割において、どの分割タイプ（すなわち、水平又は垂直）が使用されるかを指し示すために、１つのフラグがシグナリングされ、０は水平分割を指し示し、１は垂直分割を指し示す。四分木分割では、分割タイプを指し示す必要はない。何故なら、四分木分割は常に、ブロックを水平方向及び垂直方向の両方で分割して、等しいサイズの４つのサブブロックを生成するからである。
【0010】
さらに、ＱＴＢＴスキームは、ルマ及びクロマが別々のＱＴＢＴ構造を持つことができることをサポートする。現在、Ｐ及びＢスライスでは、１つのＣＴＵのルマＣＴＢ及びクロミナンスＣＴＢが同一のＱＴＢＴ構造を共有している。しかし、Ｉスライスでは、ルマＣＴＢはＱＴＢＴ構造によってＣＵへと分割され、クロマＣＴＢは別のＱＴＢＴ構造によってクロマＣＵへと分割される。これが意味することは、ＩスライスにおけるＣＵは、ルマ成分の符号化ブロック又は２つのクロマ成分の符号化ブロックで構成され、Ｐ又はＢスライスにおけるＣＵは、３つ全ての色成分の符号化ブロックで構成されるということである。
【0011】
ＨＥＶＣでは、小ブロックについてのインター予測が、動き補償のメモリアクセスを削減するために制限され、その結果、４×８及び８×４のブロックで双方向予測がサポートされておらず、４×４ブロックでインター予測がサポートされていない。ＪＥＭのＱＴＢＴでは、これらの制約が取り除かれる。
【0012】
マルチタイプツリー（Multi-type-tree；ＭＴＴ）構造は、ＱＴＢＴよりもフレキシブルなツリー構造である。ＭＴＴでは、四分木（quad-tree；ＱＴ）及び二分木（binary-tree；ＢＴ）以外のツリータイプがサポートされる。図２（ｄ）及び図２（ｅ）にそれぞれ示されるような水平及び垂直のセンター－サイド三分木が導入される。
【0013】
図２（ａ）は、四分木分割の一例を示している。図２（ｂ）は、垂直二分木分割の一例を示している。図２（ｃ）は、水平二分木分割の一例を示している。図２（ｄ）は、垂直センター－サイド三分木分割の一例を示している。図２（ｅ）は、水平センター－サイド三分木分割の一例を示している。
【0014】
領域ツリー（四分木）及び予測ツリー（二分木又は三分木）という２つのレベルのツリーが存在する。ＣＴＵは先ず領域ツリー（region tree；ＲＴ）によって分割される。ＲＴリーフが更に、予測ツリー（prediction tree；ＰＴ）で分割され得る。また、ＰＴノードが更に、最大ＰＴ深さに達するまで、ＰＴで分割され得る。ＰＴに入った後には、もはや、ＲＴ（四分木）を使用することはできない。ＰＴリーフが、基礎となる符号化単位である。
便宜上、それをなおもＣＵと称する。ＣＵを更に分割することはできない。予測及び変換はどちらも、ＪＥＭ－３又はＱＴＢＴと同じやり方でＣＵに適用される。
便宜上、それをなおもＣＵと称する。ＣＵを更に分割することはできない。予測及び変換はどちらも、ＪＥＭ－３又はＱＴＢＴと同じやり方でＣＵに適用される。
【0015】
三分木分割の利点は、四分木及び二分木が常にブロックセンターに沿って分割を行うのに対し、三分木分割が、四分木及び二分木分割の補完として、ブロックセンターに位置するオブジェクトを捕捉できることを含み得る。また、提案された三分木の分割の幅及び高さは、追加の変換が必要とされないよう、常に２のべき乗である。
【0016】
主に複雑さの低減により、２レベルツリーの設計が動機付けられる。理論的に、ツリーを横断することの複雑さはＴＤであり、ただし、Ｔは分割タイプの数を表し、Ｄはツリーの深さを表す。２レベルツリーの設計を用い、且つ第１レベルが四分木のみであることに制約する（特定レベルでのＴの数を減らす）と、妥当な性能を維持したまま、複雑性が大いに低減される。
【0017】
ＱＴＢＴにもまして符号化効率を更に高めるために、非対称二分木（asymmetric binary tree；ＡＢＴ）が提案されている。図３に示すように、サイズＳを持つ符号化単位が、水平方向又は垂直方向のいずれかで、サイズＳ／４及びサイズ３×Ｓ／４を持つ２つのサブＣＵに分割される。実際には、追加される利用可能なＣＵサイズは１２及び２４である。更なる拡張版のツールでは、ＣＵサイズ６及び４８が可能にされ得る。
【0018】
この方法の１つの大きな問題は、ブロックの幅／高さが２のべき乗でないと不都合であることである。例えば、１２及び２４のようなサイズでの変換がサポートされる必要がある。幅／高さが２のべき乗でないブロックを分割するときには、特別な取扱いも必要とされ得る。
【0019】
ＳｐｌｉｔＴｏＳｑｕａｒｅ（スプリット・ツー・スクエア）ツリータイプを使用すると、ブロックが、最大の同じサイズの正方形のサブブロックに分割される。すなわち、入力ブロックが２Ｍ×２Ｎ（Ｍ≠Ｎ）のサイズを持つ長方形ブロックである場合、ＳｐｌｉｔＴｏＳｑｕａｒｅの後に、我々は、サイズが２ｍｉｎ（Ｍ，Ｎ）×２ｍｉｎ（Ｍ，Ｎ）である２Ｍ＋Ｎ－２×ｍｉｎ（Ｍ，Ｎ）個のサブブロックを有することになる。入力ブロックが正方形ブロックである場合には、ＳｐｌｉｔＴｏＳｑｕａｒｅは４つの正方形の同じサイズのサブブロックをもたらし、これは四分木分割と同じである。基本的に、ＳｐｌｉｔＴｏＳｑｕａｒｅは、それがより多くのケースをカバーするので、四分木分割を置き換えるために使用され得る。
【発明の概要】
【0020】
一実施形態において、映像シーケンスを符号化するためにツリー構造にて親符号化単位（ＣＵ）を分割する方法が提供され、当該方法は、親ＣＵを、第１のＣＵ及び第２のＣＵを含む３つ以上のＣＵに分割することと、第２のＣＵを第１のＣＵに連結することによって連結ＣＵを生成することと、を含む。
【0021】
一実施形態において、映像シーケンスを符号化するためにツリー構造にて親符号化単位（ＣＵ）を分割する装置が提供され、当該装置は、プログラムコードを格納するように構成された少なくとも１つのメモリと、該プログラムコードを読み出し、該プログラムコードによって命令されるように動作するよう構成された少なくとも１つのプロセッサと、を含み、該プログラムコードは、親ＣＵを、第１のＣＵ及び第２のＣＵを含む３つ以上のＣＵに分割するための分割コードと、第２のＣＵを第１のＣＵに連結することによって連結ＣＵを生成するための生成コードと、を含む。
【0022】
一実施形態において、命令を格納した非一時的なコンピュータ読み取り可能媒体が提供され、該命令は、映像シーケンスを符号化するためにツリー構造にて親符号化単位（ＣＵ）を分割する装置の１つ以上のプロセッサによって実行されるときに、該１つ以上のプロセッサに、親ＣＵを、第１のＣＵ及び第２のＣＵを含む３つ以上のＣＵに分割させ、且つ第２のＣＵを第１のＣＵに連結することによって連結ＣＵを生成させる。
【図面の簡単な説明】
【0023】
開示に係る事項の更なる特徴、性質、及び様々な利点が、以下の詳細な説明及び添付の図面から、よりいっそう明らかになる。
【図1】ＱＴＢＴ構造の説明図である。
【図3】様々なＣＵ分割モードの説明図である。
【図4】本開示の一実施形態に従った通信システムの簡略ブロック図である。
【図5】ストリーミング環境における映像エンコーダ及びデコーダの配置の図である。
【図6】本開示の一実施形態に従った映像デコーダの機能ブロック図である。
【図7】本開示の一実施形態に従った映像エンコーダの機能ブロック図である。
【図8】本開示の一実施形態に従った、非隣接サブブロックの連結の説明図である。
【図9】本開示の一実施形態に従った、様々なＣＵを分割及び連結することの一例の説明図である。
【図10】本開示の一実施形態に従った、映像シーケンスを符号化するためにツリー構造にて親ＣＵを分割するプロセスの一例のフローチャートである。
【図11】一実施形態に従ったコンピュータシステムの図である。
【発明を実施するための形態】
【0024】
ＡＢＴは符号化効率の改善を示すが、ＴＴと多くの重複を有する。例えば、図３におけるＨＯＲ＿ＵＰの第１のパーティションは、図２（ｅ）における第１のパーティションと重複する。このパーティションは更に、より小さなサブブロックに分割され得るので、エンコーダのパーティションサーチにおける複雑さの重複が実際には非常に高い。
【0025】
ＭＴＴ（ＡＢＴ及びＳｐｌｉｔＴｏＳｑｕａｒｅを含む）構造はフレキシブルであるが、映像内の標準的でないオブジェクトを捕捉するのには依然として十分に効率的でない。
【0026】
図４は、本開示の一実施形態に従った通信システム（３００）の簡略化したブロック図を例示している。通信システム（３００）は、ネットワーク（４５０）を介して相互接続された少なくとも２つの端末（４１０－４２０）を含み得る。データの一方向伝送では、第１の端末（４１０）は、ネットワーク（４５０）を介した他方の端末（４２０）への伝送のために、ローカル位置で映像データを符号化し得る。第２の端末（４２０）は、他方の端末の符号化された映像データをネットワーク（４５０）から受信し、符号化されたデータを復号し、そして、復元された映像データを表示し得る。一方向データ伝送は、メディアサービス提供アプリケーション及びそれに類するものにおいて一般的であり得る。
【0027】
図４は、例えばテレビ会議中に発生し得る符号化された映像の双方向伝送をサポートするように設けられた第２対の端末（４３０、４４０）を例示している。データの双方向伝送では、各端末（４３０、４４０）が、ローカル位置でキャプチャされた映像データを、ネットワーク（４５０）を介した他方の端末への伝送のために符号化し得る。各端末（４３０、４４０）はまた、他方の端末によって送信された符号化された映像データを受信することができ、符号化データを復号し、そして、復元された映像データをローカルのディスプレイ装置に表示し得る。
【0028】
図４では端末（４１０－４４０）がサーバ、パーソナルコンピュータ、及びスマートフォンとして例示され得るが、本開示の原理はそのように限定されるものではない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤ、及び／又は専用のテレビ会議機器での適用を見出すものである。ネットワーク（４５０）は、例えば、有線通信ネットワーク及び／又は無線通信ネットワークを含め、端末（４１０－４４０）間で符号化された映像データを伝達するあらゆる数のネットワークを表す。通信ネットワーク（４５０）は、回線交換チャネル及び／又はパケット交換チャネルにてデータを交換し得る。代表的なネットワークは、遠距離通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、及び／又はインターネットを含む。本説明の目的上、ネットワーク（４５０）のアーキテクチャ及びトポロジーは、以下にて説明しない限り、本開示の動作にとって重要ではないとし得る。
【0029】
図５は、開示に係る事項に関するアプリケーションの一例として、ストリーミング環境における映像エンコーダ及びデコーダの配置を例示している。開示に係る事項は、例えば、テレビ会議や、デジタルＴＶや、ＣＤ、ＤＶＤ、メモリスティック及びこれらに類するものを含むデジタル媒体上での圧縮映像の格納などを含め、映像を使用可能な他の用途にも等しく適用可能であるとし得る。
【0030】
ストリーミングシステムは、キャプチャサブシステム（５１３）を含むことができ、これは、例えば未圧縮の映像サンプルストリーム（５０２）を作り出す例えばデジタルカメラといった映像ソース（５０１）を含むことができる。そのサンプルストリーム（５０２）は、符号化された映像ビットストリームと比較して高いデータボリュームであることを強調するために太線として描かれており、カメラ５０１に結合されたエンコーダ（５０３）によって処理され得る。エンコーダ（５０３）は、更に詳細に後述される開示に係る事項の態様を使用可能にする又は実装するための、ハードウェア、ソフトウェア、又はこれらの組み合わせを含むことができる。符号化された映像ビットストリーム（５０４）は、サンプルストリームと比較して低いデータボリュームであることを強調するために細線として描かれており、後の使用のためにストリーミングサーバ（５０５）に格納されることができる。１つ以上のストリーミングクライアント（５０６、５０８）が、符号化された映像ビットストリーム（５０４）のコピー（５０７、５０９）を取り出すためにストリーミングサーバ（５０５）にアクセスすることができる。クライアント（５０６）は、入ってくる符号化された映像ビットストリームのコピー（５０７）を復号し、出ていく映像サンプルストリーム（５１１）を作り出す映像デコーダ（５１０）を含むことができ、出ていく映像サンプルストリーム（５１１）が、ディスプレイ（５１２）又は他のレンダリング装置（図示せず）上でレンダリングされ得る。一部のストリーミングシステムにおいて、映像ビットストリーム（５０４、５０７、５０９）は、特定の映像符号化／圧縮標準に従って符号化されることができる。それらの標準の例は、ＩＴＵ－Ｔ勧告Ｈ．２６５を含む。非公式にＶＶＣ（Versatile Video Coding）として知られる映像符号化標準が開発中である。開示に係る事項は、ＶＶＣの文脈で使用されてもよい。
【0031】
図６は、本発明の一実施形態に従った映像デコーダ（５１０）の機能ブロック図であるとし得る。
【0032】
受信器（６１０）が、デコーダ（５１０）によって復号される１つ以上の符号化映像シーケンスを受信することができ、同じ又は他の実施形態において、一度に１つの符号化映像シーケンスを受信することができ、各符号化映像シーケンスの復号は、他の符号化映像シーケンスとは独立である。符号化映像シーケンスは、符号化された映像データを格納するストレージ装置へのハードウェア／ソフトウェアリンクとし得るものであるチャネル（６１２）から受信され得る。受信器（６１０）は、符号化映像データを、例えば符号化された音声データ及び／又は補助データストリームといった他のデータと共に受信してもよく、それらのデータは、それらそれぞれの使用エンティティ（図示せず）に転送され得る。受信器（６１０）は、符号化映像シーケンスを他のデータから分離し得る。ネットワークジッタに対抗するために、受信器（６１０）とエントロピーデコーダ／パーサ（６２０）（以下、“パーサ”）との間にバッファメモリ（６１５）が結合され得る。受信器（６１０）が、十分な帯域幅及び可制御性の格納／転送装置から又は等同期ネットワークからデータを受信しているとき、バッファ（６１５）は、必要とされないことがあり、又は小さくされることができる。例えばインターネットなどのベストエフォート型パケットネットワーク上での使用では、バッファ（６１５）が必要とされ得るとともに、比較的大きくされ、そして有利には、適応可能なサイズのものにされ得る。
【0033】
映像デコーダ（５１０）は、エントロピー符号化された映像シーケンスからシンボル（６２１）を再構成するためのパーサ（６２０）を含み得る。それらシンボルのカテゴリは、デコーダ（５１０）の動作を管理するために使用される情報を含むとともに、可能性として、例えばディスプレイ（５１２）などのレンダリング装置を制御する情報を含み得る。ディスプレイ（５１２）などのレンダリング装置は、デコーダの一体部分ではないが、図６に示したようにデコーダに結合されることができる。（１つ以上の）レンダリング装置用の制御情報は、ＳＥＩ（Supplementary Enhancement Information）メッセージ又はＶＵＩ（Video Usability Information）パラメータセットフラグメント（図示せず）の形態とし得る。パーサ（６２０）は、受け取った符号化映像シーケンスを構文解析／エントロピー復号し得る。符号化映像シーケンスの符号化は、映像符号化技術又は標準によることができ、可変長符号化、ハフマン符号化、文脈依存性を持つ又は持たない算術符号化などを含め、当業者に周知の原理に従うことができる。パーサ（６２０）は、符号化映像シーケンスから、グループに対応する少なくとも１つのパラメータに基づいて、映像デコーダにおけるピクセルのサブグループのうちの少なくとも１つに関する一組のサブグループパラメータを抽出することができる。サブグループは、グループ・オブ・ピクチャ（ＧＯＰ）、ピクチャ、タイル、スライス、マクロブロック、符号化単位（ＣＵ）、ブロック、変換単位（ＴＵ）、予測単位（ＰＵ）などを含むことができる。エントロピーデコーダ／パーサはまた、符号化映像シーケンス情報から、例えば変換係数、量子化パラメータ（quantizer parameter；ＱＰ）値、動きベクトルなどの情報を抽出し得る。
【0034】
パーサ（６２０）は、シンボル（６２１）を生み出すよう、バッファ（６１５）から受け取った映像シーケンスにエントロピー復号／構文解析処理を実行し得る。パーサ（６２０）は、符号化されたデータを受け取って、特定のシンボル（６２１）を選択的に復号し得る。さらに、パーサ（６２０）は、特定のシンボル（６２１）が、動き補償予測ユニット（６５３）、スケーラ／逆変換ユニット（６５１）、イントラ予測ユニット（６５２）、又はループフィルタ（６５６）に提供されるべきかを決定し得る。
【0035】
シンボル（６２１）の再構成には、符号化された映像ピクチャ又はその部分のタイプ及び他の要因（例えば、インターピクチャ及びイントラピクチャ、インターブロック及びイントラブロックなど）に応じて、複数の異なるユニットが関与し得る。どのユニットがどのように関与するかは、パーサ（６２０）によって符号化映像シーケンスから構文解析されたサブグループ制御情報によって制御されることができる。パーサ（６２０）と以下の複数ユニットとの間でのこのようなサブグループ制御情報の流れは、明瞭さのために図示していない。
【0036】
既述の機能ブロックを超えて、デコーダ（５１０）は概念的に、後述のような多数の機能ユニットに細分化されることができる。商業上の制約の下で稼働する実用的な実装において、これらのユニットのうちの多くが互いに密接にインタラクトし、少なくとも部分的に互いに統合され得る。しかしながら、開示に係る事項を説明するという目的のためには、以下の機能ユニットへの概念的な細分化が適切である。
【0037】
第１のユニットは、スケーラ／逆変換ユニット（６５１）である。スケーラ／逆変換ユニット（６５１）は、パーサ（６２０）からの（１つ以上の）シンボル（６２１）として、どの変換を使用すべきか、ブロックサイズ、量子化係数、量子化スケーリング行列などを含む制御情報とともに、量子化された変換係数を受け取る。これは、アグリゲータ（６５５）に入力されることが可能な、サンプル値を有するブロックを出力することができる。
【0038】
場合により、スケーラ／逆変換（６５１）の出力サンプルは、イントラ符号化されたブロック、すなわち、先行して再構成されたピクチャからの予測情報を使用していないが、現在ピクチャのうち先行して再構成された部分からの予測情報を使用することができるブロック、に関係し得る。このような予測情報は、イントラピクチャ予測ユニット（６５２）によって提供されることができる。場合により、イントラピクチャ予測ユニット（６５２）は、現在の（部分的に再構成された）ピクチャ（６５６）からフェッチされた周囲の既に再構成された情報を用いて、再構成中のブロックと同じサイズ及び形状のブロックを生成する。アグリゲータ（６５５）は、場合により、サンプル毎に、イントラ予測ユニット（６５２）が生成した予測情報を、スケーラ／逆変換ユニット（６５１）によって提供される出力サンプル情報に付加する。
【0039】
他の場合には、スケーラ／逆変換ユニット（６５１）の出力サンプルは、インター符号化された、動き補償された可能性のあるブロックに関係し得る。このような場合、動き補償予測ユニット（６５３）が、基準ピクチャメモリ（６５７）にアクセスして、予測に使用されるサンプルをフェッチすることができる。フェッチされたサンプルを、ブロックに関係するシンボル（６２１）に従って動き補償した後、これらのサンプルが、アグリゲータ（６５５）によって、スケーラ／逆変換ユニットの出力（この場合、残余サンプル又は残余信号と呼ぶ）に付加されて、出力サンプル情報を生成することができる。そこから動き補償ユニットが予測サンプルをフェッチする基準ピクチャメモリ内のアドレスは、例えばＸ、Ｙ、及び基準ピクチャ成分を有し得るシンボル（６２１）の形態で動き補償ユニットに利用可能な動きベクトルによって制御され得る。動き補償はまた、サブサンプルの正確な動きベクトルが使用されるときに基準ピクチャメモリからフェッチされたサンプル値の補間や、動きベクトル予測メカニズムなどを含むことができる。
【0040】
アグリゲータ（６５５）の出力サンプルは、ループフィルタユニット（６５６）にて様々なループフィルタリング技術に掛けられ得る。映像圧縮技術は、インループ（in-loop）フィルタ技術を含むことができ、これは、符号化映像ビットストリームに含められてパーサ（６２０）からのシンボル（６２１）としてループフィルタユニット（６５６）に利用可能にされるパラメータによって制御されるが、符号化ピクチャ又は符号化映像シーケンスのうちの（復号順で）先行部分の復号中に得られたメタ情報にも応答することができるとともに、先行して再構成されてループフィルタリングされたサンプル値にも応答することができる。
【0041】
ループフィルタユニット（６５６）の出力は、レンダリング装置（５１２）に出力されることが可能なサンプルストリームとすることができ、これはまた、将来のインターピクチャ予測での使用のために基準ピクチャメモリ（６５６）に格納され得る。
【0042】
ある特定の符号化ピクチャは、完全に再構成されると、将来の予測のための基準ピクチャとして使用されることができる。ある符号化ピクチャが完全に再構成され、その符号化ピクチャが基準ピクチャとして（例えば、パーサ（６２０）によって）特定されると、現在の基準ピクチャ（６５６）が基準ピクチャバッファ（６５７）の一部となり得るとともに、次の符号化ピクチャの再構成を開始する前に新しい現在ピクチャメモリが再割り当てされ得る。
【0043】
映像デコーダ（５１０）は、例えばＩＴＵ－Ｔ勧告Ｈ．２６５などの標準にて文書化され得る所定の映像圧縮技術に従って復号処理を実行し得る。符号化映像シーケンスは、映像圧縮技術文書又は標準、特にその中のプロファイル文書の中で規定されるように映像圧縮技術又は標準の構文を忠実に守るという意味で、使用される映像圧縮技術又は標準によって規定される構文に従い得る。また、準拠のためにこれまた必要なことは、符号化映像シーケンスの複雑さが、映像圧縮技術又は標準のレベルによって定められる限度内であることである。場合により、レベルは、最大ピクチャサイズ、最大フレームレート、最大再構成サンプルレート（例えば、毎秒メガサンプルで測定される）、最大基準ピクチャサイズなどを制約する。レベルによって設定される制限は、場合により、仮説的リファレンスデコーダ（Hypothetical Reference Decoder；ＨＲＤ）仕様、及び符号化映像シーケンスにて信号伝達されるＨＲＤバッファ管理用のメタデータを通して更に制約され得る。
【0044】
一実施形態において、受信器（６１０）は、符号化された映像と共に追加（冗長）データを受信し得る。追加データは、（１つ以上の）符号化映像シーケンスの一部として含められ得る。追加データは、データを適切に復号するため、及び／又は元の映像データをいっそう正確に再構成するために、映像デコーダ（５１０）によって使用され得る。追加データは、例えば、時間的、空間的、又は信号対雑音比（ＳＮＲ）エンハンスメントレイヤ、冗長スライス、冗長ピクチャ、順方向誤り訂正符号などの形態とし得る。
【0045】
図７は、本開示の一実施形態に従った映像エンコーダ（５０３）の機能ブロック図とし得る。
【0046】
エンコーダ（５０３）は、エンコーダ（５０３）によって符号化される（１つ以上の）映像画像をキャプチャし得る映像ソース（５０１）（エンコーダの一部ではない）から映像サンプルを受信し得る。
【0047】
映像ソース（５０１）は、エンコーダ（５０３）によって符号化されるソース映像シーケンスを、任意の好適なビット深さ（例えば、８ビット、１０ビット、１２ビット、…）、任意の色空間（例えば、ＢＴ．６０１ Ｙ ＣｒＣＢ、ＲＧＢ、…）、及び任意の好適なサンプリング構造（例えば、Ｙ ＣｒＣｂ ４：２：０、Ｙ ＣｒＣｂ ４：４：４）のものとし得るデジタル映像サンプルストリームの形態で提供し得る。メディアサービス提供システムにおいて、映像ソース（５０１）は、事前に準備された映像を格納したストレージ装置とし得る。テレビ会議システムでは、映像ソース（５０３）は、ローカルな画像情報を映像シーケンスとしてキャプチャするカメラとし得る。映像データは、順に見たときに動きを伝える複数の個々のピクチャとして提供され得る。それらピクチャ自体は、ピクセルの空間アレイとして編成されることができ、各ピクセルが、使用されるサンプリング構造、色空間などに応じて、１つ以上のサンプルを有することができる。当業者は、ピクセルとサンプルとの関係を直ちに理解することができる。以下の説明は、サンプルに焦点を当てている。
【0048】
一実施形態によれば、エンコーダ（５０３）は、ソース映像シーケンスのピクチャを、リアルタイムで、又はアプリケーションによって要求される他の時間制約下で、符号化映像シーケンス（７４３）へと符号化及び圧縮し得る。適切な符号化速度を強制することは、コントローラ（７５０）の１つの機能である。コントローラは、後述するような他の機能ユニットを制御し、それらのユニットに機能的に結合される。その結合は、明瞭さのために図示されていない。コントローラによって設定されるパラメータは、レート制御関連パラメータ（ピクチャスキップ、量子化器、レート歪み最適化技術のラムダ値、…）、ピクチャサイズ、グループ・オブ・ピクチャ（ＧＯＰ）レイアウト、最大動きベクトル探索範囲などを含み得る。当業者は、特定のシステム設計に合わせて最適化される映像エンコーダ（５０３）に関連し得るものとして、コントローラ（７５０）の他の機能を直ちに特定することができる。
【0049】
一部の映像エンコーダは、当業者が“符号化ループ”として直ちに認識するものにて動作する。過度に単純化した説明として、符号化ループは、エンコーダの符号化部分（７３０）（以下、“ソースコーダ”）（符号化される入力ピクチャ及び（１つ以上の）基準ピクチャに基づいてシンボルを作成することを担う）と、エンコーダ（５０３）に埋め込まれた（ローカル）デコーダ（７３３）とで構成されることができ、（ローカル）デコーダ（７３３）は、シンボルを再構成して、（リモート）デコーダも作成し得る（開示に係る事項において検討している映像圧縮技術においては、シンボルと符号化映像ビットストリームとの間の如何なる圧縮も可逆であるため）ものであるサンプルデータを生成する。その再構成されたサンプルストリームが、基準ピクチャメモリ（７３４）に入力される。シンボルストリームの復号は、デコーダ位置（ローカル又はリモート）に依存しないビット正確な結果をもたらすので、基準ピクチャバッファのコンテンツもローカルエンコーダとリモートエンコーダとの間でビット正確である。換言すれば、エンコーダの予測部分は、デコーダが復号中に予測を使用するときに“見る”のとまったく同じサンプル値を基準ピクチャサンプルとして“見る”。この基準ピクチャ同期性の基本原理（及び、例えばチャネルエラーのために、同期性を維持することができない場合に結果として生じるドリフト）は、当業者によく知られている。
【0050】
“ローカル”デコーダ（７３３）の動作は、“リモート”デコーダ（５１０）のものと同じであるとすることができ、それは、図６に関連して既に詳細に上述されている。しかし、図６も簡単に参照するに、シンボルが利用可能であり、且つエントロピーコーダ（７４５）及びパーサ（６２０）によるシンボルの符号化映像シーケンスへの符号化／復号は可逆であるとし得るので、チャネル（６１２）、受信器（６１０）、バッファ（６１５）、及びパーサ（６２０）を含むデコーダ（５１０）のエントロピー復号部分は、ローカルデコーダ（７３３）に完全に実装されなくてよい。
【0051】
この時点で気付くことができることには、デコーダ内に存在する構文解析／エントロピー復号を除く如何なるデコーダ技術も必ず、対応するエンコーダ内で、実質的に同じ機能的形態で存在する必要がある。エンコーダ技術の説明は、徹底して説明したデコーダ技術の逆であるため、省略することができる。特定の分野においてのみ、より詳細な説明が必要とされ、以下に提供される。
【0052】
その動作の一部として、ソースコーダ（７３０）は、入力フレームを、映像シーケンスからの、“基準フレーム”として指定された１つ以上の先に符号化されたフレームに対して予測的に符号化するものである動き補償予測符号化を実行し得る。斯くして、符号化エンジン（７３２）は、入力フレームのピクセルブロックと、入力フレームに対する（１つ以上の）予測基準として選択され得る（１つ以上の）基準フレームのピクセルブロックとの間の差分を符号化する。
【0053】
ローカル映像デコーダ（７３３）は、基準フレームとして指定され得るフレームの符号化映像データを、ソースコーダ（７３０）によって作成されたシンボルに基づいて復号し得る。符号化エンジン（７３２）の動作は、有利には、不可逆プロセスとし得る。符号化映像データが映像デコーダ（図６には示されていない）で復号され得るとき、再構成された映像シーケンスは典型的に、幾分の誤差を伴うソース映像シーケンスのレプリカであり得る。ローカル映像デコーダ（７３３）は、基準フレーム上で映像デコーダによって実行され得る復号プロセスを複製し、再構成された基準フレームを基準ピクチャキャッシュ（７３４）に格納させるようにし得る。斯くして、エンコーダ（５０３）は、ファーエンドの映像デコーダによって得られることになる再構成基準フレームと共通のコンテンツを持つ再構成基準フレームのコピーをローカルに格納し得る。
【0054】
予測器（７３５）は、符号化エンジン（７３２）のために予測探索を実行し得る。すなわち、符号化すべき新たなフレームに関して、予測器（７３５）は、新たなピクチャ用の適切な予測基準としての役割を果たし得るサンプルデータ（候補基準ピクセルブロックとして）又は例えば基準ピクチャ動画ベクトルやブロック形状などの特定のメタデータについて、基準ピクチャメモリ（７３４）を検索し得る。予測器（７３５）は、適切な予測基準を見出すために、ピクセルブロック毎に動作し得る。場合により、予測器（７３５）によって得られた検索結果により決定されるように、入力ピクチャは、基準ピクチャメモリ（７３４）に格納された複数の基準ピクチャから引き出された予測基準を有し得る。
【0055】
コントローラ（７５０）は、例えば、映像データを符号化するのに使用されるパラメータ及びサブグループパラメータの設定を含め、映像コーダ（７３０）の符号化処理を管理し得る。
【0056】
前述の全ての機能ユニットの出力が、エントロピーコーダ（７４５）におけるエントロピー符号化に掛けられ得る。エントロピーコーダは、例えばハフマン符号化、可変長符号化、算術符号化などといった当業者に知られた技術に従ってシンボルを無損失圧縮することによって、様々な機能ユニットによって生成されたシンボルを符号化映像シーケンスへと変換する。
【0057】
送信器（７４０）が、エントロピーコーダ（７４５）によって生成された符号化映像シーケンスをバッファリングし、それを、通信チャネル（７６０）を介した伝送のために準備し得る。通信チャネル（７６０）は、符号化された映像データを格納するストレージ装置へのハードウェア／ソフトウェアリンクとし得る。送信器（７４０）は、映像コーダ（７３０）からの符号化映像データを、例えば符号化オーディオデータ及び／又は補助データストリーム（ソースは図示していない）といった、送信される他のデータとマージし得る。
【0058】
コントローラ（７５０）は、エンコーダ（５０３）の動作を管理し得る。符号化において、コントローラ（７５０）は、各符号化ピクチャに、それぞれのピクチャに適用され得る符号化技術に影響を及ぼし得るものである特定の符号化ピクチャタイプを割り当て得る。例えば、ピクチャはしばしば、以下のフレームタイプの１つとして割り当てられ得る。
【0059】
イントラピクチャ（Ｉピクチャ）は、予測のソースとしてシーケンス内の他のフレームを使用することなく、符号化コード化及び復号され得るものとし得る。一部の映像コーデックは、例えば独立デコーダリフレッシュピクチャを含め、異なるタイプのイントラピクチャを許している。当業者は、Ｉピクチャのそれら異形、並びにそれらそれぞれの用途及び特徴を知っている。
【0060】
予測ピクチャ（Ｐピクチャ）は、各ブロックのサンプル値を予測するために、多くて１つの動きベクトルと基準インデックスとを使用して、イントラ予測又はインター予測を用いて符号化及び復号され得るものとし得る。
【0061】
双方向予測ピクチャ（Ｂピクチャ）は、各ブロックのサンプル値を予測するために、多くて２つの動きベクトルと基準インデックスとを使用して、イントラ予測又はインター予測を用いて符号化及び復号され得るものとし得る。同様に、多重予測画像は、単一のブロックの再構成のために３つ以上の基準ピクチャと関連メタデータとを使用することができる。
【0062】
ソースピクチャは、一般に、空間的に複数のサンプルブロック（例えば、各々４×４、８×８、４×８、又は１６×１６サンプルのブロック）に細分化され、ブロック毎に符号化され得る。ブロックは、それらブロックのそれぞれのピクチャに適用される符号化割り当てによって決定される他の（既に符号化された）ブロックを参照して予測的に符号化され得る。例えば、Ｉピクチャのブロックは非予測的に符号化されることができ、あるいは、それらは同じピクチャの既に符号化されたブロックを参照して予測的に符号化されることができる（空間予測又はイントラ予測）。Ｐピクチャのピクセルブロックは、非予測的に、あるいは、１つの先に符号化された基準ピクチャを参照して空間予測又は時間予測を介して、符号化されることができる。Ｂピクチャのブロックは、非予測的に、あるいは、１つ又は２つの先に符号化された基準ピクチャを参照して空間予測又は時間予測を介して、符号化されることができる。
【0063】
映像エンコーダ（５０３）は、例えばＩＴＵ－Ｔ勧告Ｈ．２６５などの所定の映像符号化技術又は標準に従って符号化処理を実行し得る。その動作において、映像エンコーダ（５０３）は、入力映像シーケンスにおける時間的及び空間的な冗長性を活用する予測的な符号化処理を含め、様々な圧縮処理を実行し得る。符号化された映像データは、それ故に、使用されている映像符号化技術又は標準によって規定される構文に従い得る。
【0064】
一実施形態において、送信器（７４０）は、符号化された映像と共に追加データを送信し得る。映像コーダ（７３０）が、そのようなデータを、符号化映像シーケンスの一部として含め得る。追加データは、時間的／空間的／ＳＮＲエンハンスメントレイヤ、例えば冗長ピクチャ及びスライスなどの他の形態の冗長データ、ＳＥＩ（Supplementary Enhancement Information）メッセージ、ＶＵＩ（Visual Usability Information）パラメータセットフラグメントなどを有し得る。
【0065】
本開示の一部の実施形態は、任意のツリー構造において（例えばＭＴＴにおいてなど）２つ以上の空間的に隣接し合うＣＵを連結することを可能にし、その連結ＣＵが、正規のＣＵと見なされて正規のＣＵレベル構文要素及び符号化ツールを有する単一のＣＵとなるようにする。
【0066】
ＣＵ連結は、新たなＣＵの形状が長方形であり且つ／或いは新たなＣＵのサイズが利用可能な変換によってサポートされるように制約され得る。
【0067】
一実施形態において、連結ＣＵが最大ＣＵサイズよりも大きい場合、連結は許可されない。他の一実施形態において、連結ＣＵが最大ＣＵサイズより小さい場合であっても、連結ＣＵの幅又は高さのいずれかについて適合する変換が存在しない場合、連結は許可されない。例えば、２つの隣接し合うＣＵは１６×１６と１６×４である。連結ＣＵは１６×２０となる。２０ポイントの変換が利用可能でない場合、たとえ最大ＣＵサイズが１２８×１２８であっても、この新たな連結ＣＵは許可されない。
【0068】
一実施形態において、連結ＣＵの高さ及び／又は幅が利用可能な変換サイズに適合しない場合、各サブブロックの高さ及び幅が利用可能な変換サイズに適合するように、ＣＵが２つ以上のサブブロックに分割され得る。ＣＵがどのようにサブブロックに分割されるのかは、信号伝達されてもよいし、あるいは予め定められていてもよい。
【0069】
一実施形態において、ＣＵ連結は、ＣＵが現在ＣＵと同じ親を共有するＣＵにのみ連結することができるように制約され得る。
【0070】
一実施形態において、ＣＵ連結の方向が、ＣＵがその右側又はその下側のＣＵにのみ連結することができるように制約され得る。
【0071】
３つ以上のサブブロック（例えばＴＴ）に分割されるブロックについて、本開示の実施形態は、互いに隣接しない２つ以上のパーティションを連結することを可能にし、連結されたパーティションの残余が、変換及び動き補償を含む更なる処理のための１つのブロックとしてまとめられ得る。
【0072】
一実施形態において、Ｍ×Ｎブロックが例えばＴＴなどの３つのサブブロックに分割される場合、図８に示すように、陰影付きブロックを用いて図示した２つの小さい方のＭ／４×Ｎ（水平センター－サイドＴＴ）又はＭ×Ｎ／４（垂直センター－サイドＴＴ）パーティションが、１つのＭ／２×Ｎ（水平センター－サイドＴＴ）ブロック又はＭ×Ｎ／２（垂直センター－サイドＴＴ）ブロックを形成するようにまとめられる。この場合、これら３つのサブブロックの符号化／復号順序が、例えば、先ず連結された２つのサイドサブブロックを符号化／復号し、次いでセンターサブブロックを符号化／復号する、又は、先ずセンターサブブロックを符号化／復号し、次いで連結された２つのサイドサブブロックを符号化／復号する、などに変更され得る。
【0073】
一実施形態において、２つ以上の隣接しないサブブロックの連結が適用される場合、空間的に隣接する右及び下ブロックの動き情報が、それらが利用可能であるときに、動作補償に使用されてもよい。
【0074】
一実施形態において、水平センター－サイドＴＴの２つの小さい方のサブブロックＭ／４×Ｎが１つのＭ／２×Ｎサブブロックとしてまとめられ、且つＴＴのセンターＭ／２×Ｎサブブロックの前に符号化される場合、センターパーティションの動き情報を予測するときに、その右側の、連結に関与しているＭ／４×Ｎサブブロックからの動きが使用されてもよい。
【0075】
本開示の実施形態は、ＣＵ／ブロック連結の機能が有効にされているか又は無効であるかを、例えばシーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、及び／又はスライスヘッダ内など、ビットストリーム内でシグナリングし得る。許可される／許可されない異なるＣＵ／ブロック連結の組み合わせが、例えばＳＰＳ、ＰＰＳ、及び／又はスライスヘッダ内など、ビットストリーム内でシグナリングされてもよい。
【0076】
一実施形態において、ＣＵ連結は、ＴＴにもましてＡＢＴを模倣するように使用されてもよい。この実施形態において、ＡＢＴ分割は、ＴＴ分割の上で提案されるＣＵ連結を用いて模倣される。
【0077】
図９の左側に示すように、ＴＴ分割後に、３つのパーティションＰ０、Ｐ１、及びＰ２が存在すると仮定する。その上、このブロックでは、右側の図に示すようなＡＢＴ分割の方が効率的であるとする。狙うのは、ＣＵ連結を用いて、ＡＢＴ分割０’及びＰ１’を模倣することである。
【0078】
この実施形態では、ＴＴ分割のための通常の構文要素に加えて、ＴＴ分割による３つのＣＵのうち最初の２つのＣＵについてＣＵが次のＣＵに連結されているかを指し示すために新たなフラグcu_conat_flagがシグナリングされ得る。上の例において、cu_conat_flagはＰ０について真（true）であり、それ故に、左側の図のＰ０及びＰ１が右側の図のＰ０’として連結され、Ｐ２がＰ１’になる。従って、ＡＢＴパーティションが、ＣＵ連結を用いたＴＴによって模倣され得る。
【0079】
関連する構文テーブルは、以下の疑似コードに基づき得る。言及しておくべきことには、以下の疑似コードでは、関数coding_unit()が使用されているので、連結ＣＵに対する更なる分割は許されない。これに代えて、連結ＣＵが更に分割されてもよい。その場合、coding_unit()の代わりに、関数coding_tree_unitが使用される。
coding_tree_unit(x0,y0,w0,h0,cuDepth)
{
splitType = parse_tree_type();
if(splitType == NoSplit)
{
coding_unit(x0,y0,w0,h0,cuDepth);
}
else if(splitType == QuadTreeSplit)
{
coding_tree_unit(x0,y0,w0/2,h0/2,cuDepth+1);
coding_tree_unit(x0+w0/2,y0,w0/2,h0/2,cuDepth+1);
coding_tree_unit(x0,y0+h0/2,w0/2,h0/2,cuDepth+1);
coding_tree_unit(x0+w0/2,y0+y0/2,w0/2,h0/2,cuDepth+1);
}
else if(splitType == BinTreeSplitVer)
{
coding_tree_unit(x0,y0,w0/2,h0,cuDepth+1);
coding_tree_unit(x0+w0/2,y0,w0/2,h0,cuDepth+1);
}
else if(splitType == BinTreeSplitHor)
{
coding_tree_unit(x0,y0,w0,h0/2,cuDepth+1);
coding_tree_unit(x0,y0+h0/2,h0/2,cuDepth+1);
}
else if(splitType == TriTreeSplitVer)
{
cu_concat_flag0 = parse_cu_concat_flag();
if(cu_concat_flag0)
{
coding_unit(x0,y0,w0*3/4,h0,cuDepth);
coding_tree_unit(x0+w0*3/4,y0,w0/4,h0,cuDepth+1);
}
else
{
coding_tree_unit(x0,y0,w0/4,h0,cuDepth+1);
cu_concat_flag1 = parse_cu_concat_flag();
if(cu_concat_flag1)
{
coding_unit(x0+w0/4,y0,w0*3/4,h0,cuDepth);
}
else
{
coding_tree_unit(x0+w0/4,y0,w0/2,h0,cuDepth+1);
coding_tree_unit(x0+w0*3/4,y0,w0/4,h0,cuDepth+1);
}
}
}
else if(splitType == TriTreeSplitHor)
{
cu_concat_flag0 = parse_cu_concat_flag();
if(cu_concat_flag0)
{
coding_unit(x0,y0,w0,h0*3/4,cuDepth);
coding_tree_unit(x0,y0+h0*3/4,w0,h0/4,cuDepth+1);
}
else
{
coding_tree_unit(x0,y0,w0,h0/4,cuDepth+1);
cu_concat_flag1 = parse_cu_concat_flag();
if(cu_concat_flag1)
{
coding_unit(x0,y0+h0/4,w0,h0*3/4,cuDepth);
}
else
{
coding_tree_unit(x0,y0+h0/4,w0,h0/2,cuDepth+1);
coding_tree_unit(x0,y0+h0*3/4,w0,h0/4,cuDepth+1);
}
}
}
}
coding_tree_unit(x0,y0,w0,h0,cuDepth)
{
splitType = parse_tree_type();
if(splitType == NoSplit)
{
coding_unit(x0,y0,w0,h0,cuDepth);
}
else if(splitType == QuadTreeSplit)
{
coding_tree_unit(x0,y0,w0/2,h0/2,cuDepth+1);
coding_tree_unit(x0+w0/2,y0,w0/2,h0/2,cuDepth+1);
coding_tree_unit(x0,y0+h0/2,w0/2,h0/2,cuDepth+1);
coding_tree_unit(x0+w0/2,y0+y0/2,w0/2,h0/2,cuDepth+1);
}
else if(splitType == BinTreeSplitVer)
{
coding_tree_unit(x0,y0,w0/2,h0,cuDepth+1);
coding_tree_unit(x0+w0/2,y0,w0/2,h0,cuDepth+1);
}
else if(splitType == BinTreeSplitHor)
{
coding_tree_unit(x0,y0,w0,h0/2,cuDepth+1);
coding_tree_unit(x0,y0+h0/2,h0/2,cuDepth+1);
}
else if(splitType == TriTreeSplitVer)
{
cu_concat_flag0 = parse_cu_concat_flag();
if(cu_concat_flag0)
{
coding_unit(x0,y0,w0*3/4,h0,cuDepth);
coding_tree_unit(x0+w0*3/4,y0,w0/4,h0,cuDepth+1);
}
else
{
coding_tree_unit(x0,y0,w0/4,h0,cuDepth+1);
cu_concat_flag1 = parse_cu_concat_flag();
if(cu_concat_flag1)
{
coding_unit(x0+w0/4,y0,w0*3/4,h0,cuDepth);
}
else
{
coding_tree_unit(x0+w0/4,y0,w0/2,h0,cuDepth+1);
coding_tree_unit(x0+w0*3/4,y0,w0/4,h0,cuDepth+1);
}
}
}
else if(splitType == TriTreeSplitHor)
{
cu_concat_flag0 = parse_cu_concat_flag();
if(cu_concat_flag0)
{
coding_unit(x0,y0,w0,h0*3/4,cuDepth);
coding_tree_unit(x0,y0+h0*3/4,w0,h0/4,cuDepth+1);
}
else
{
coding_tree_unit(x0,y0,w0,h0/4,cuDepth+1);
cu_concat_flag1 = parse_cu_concat_flag();
if(cu_concat_flag1)
{
coding_unit(x0,y0+h0/4,w0,h0*3/4,cuDepth);
}
else
{
coding_tree_unit(x0,y0+h0/4,w0,h0/2,cuDepth+1);
coding_tree_unit(x0,y0+h0*3/4,w0,h0/4,cuDepth+1);
}
}
}
}
【0080】
図１０は、中間候補を用いてマージ候補リストを生成するプロセス１０００の一例のフローチャートである。一部の実装において、図１０の１つ以上のプロセスブロックは、デコーダ５１０によって実行され得る。一部の実装において、図１０の１つ以上のプロセスブロックは、例えばエンコーダ５０３など、デコーダ５１０とは別個又はそれを含む他の装置又は一群の装置によって実行されてもよい。
【0081】
一実施形態において、プロセス１０００は、映像シーケンスを符号化するためにツリー構造にて親符号化単位（ＣＵ）を分割することを、該親ＣＵを、第１のＣＵ及び第２のＣＵを含む３つ以上のＣＵに分割し、且つ第２のＣＵを第１のＣＵに連結することによって連結ＣＵを生成することにより行うことを含み得る。
【0082】
例えば、図１０に示すように、プロセス１０００は、ＣＵを、例えば３つ以上のＣＵといった複数のＣＵに分割することを含み得る（ブロック１０１０）。それら複数のＣＵは、第１のＣＵ及び第２のＣＵを含み得る。
【0083】
図１０に更に示すように、プロセス１０００は、第１のＣＵ及び第２のＣＵが同一の親ＣＵを持つかどうかを判定することを含み得る（ブロック１０２０）。
【0084】
図１０に更に示すように、プロセス１０００は、第１のＣＵ及び第２のＣＵが同一の親ＣＵを持つ場合に、第１のＣＵと第２のＣＵとを連結することによって連結ＣＵを生成することを含み得る（ブロック１０３０）。
【0085】
図１０に更に示すように、プロセス１０００は、第１のＣＵ及び第２のＣＵが同一の親ＣＵを持たない場合に、連結ＣＵを生成しないことを含み得る（ブロック１０４０）。
【0086】
一実施形態において、ＣＵレベル構文要素又はＣＵレベル符号化ツールのうちの少なくとも一方が、連結ＣＵに適用される。
【0087】
一実施形態において、第２のＣＵは、第１のＣＵに空間的に隣接している。
【0088】
一実施形態において、第２のＣＵは、第１のＣＵの右側、又は第１のＣＵの下側のうちの少なくとも一方に位置する。
【0089】
一実施形態において、第２のＣＵは、連結ＣＵのサイズが最大ＣＵサイズよりも小さいように、且つ連結ＣＵのサイズが利用可能な変換サイズに適合するように選択される。
【0090】
一実施形態において、連結ＣＵのサイズが利用可能な変換サイズに適合しない場合、連結ＣＵは、各々が利用可能な変換サイズに適合する複数のサブブロックに分割され得る。
【0091】
一実施形態において、上記ツリー構造は、四分木－二分木構造、三分木構造、マルチタイプツリー構造、及び非対称二分木構造のうちの少なくとも１つを含む。
【0092】
一実施形態において、上記ツリー構造は三分木構造を有し、上記３つ以上のＣＵは第３のＣＵを含むことができ、第３のＣＵは、第１のＣＵと第２のＣＵとの間に位置し得る。第１のＣＵは、第３のＣＵの左側に位置することができ、第２のＣＵは、第３のＣＵの右側に位置することができ、第１のＣＵの動き情報が、第２のＣＵの動き補償に使用され得る。
【0093】
一実施形態において、シーケンスパラメータセット（ＳＰＳ）、ピクチャパラメータセット（ＰＰＳ）、又はスライスヘッダのうちの少なくとも１つが、連結が許されることのインジケーションを含む。
【0094】
一実施形態において、第１のＣＵ及び第２のＣＵは、同じ親ＣＵから分割された他のＣＵとのみ連結することができる。
【0095】
図１０はプロセス１０００のブロック例を示しているが、一部の実装において、プロセス１０００は、図１０に示したものよりも、追加のブロック、少ないブロック、異なるブロック、又は異なるように配置されたブロックを含み得る。加えて、あるいは代わりに、プロセス１０００のブロックのうちの２つ以上が並行して実行されてもよい。
【0096】
また、提案される方法は、プロセッシング回路（例えば、１つ以上のプロセッサ又は１つ以上の集積回路）によって実装され得る。一例において、１つ以上のプロセッサは、提案される方法のうちの１つ以上を実行するために、非一時的なコンピュータ読み取り可能媒体に格納されたプログラムを実行する。
【0097】
上述の技術は、コンピュータ読み取り可能命令を用いてコンピュータソフトウェアとして実装されることができ、また、１つ以上のコンピュータ読み取り可能媒体に物理的に格納されることができる。例えば、図１１は、開示に係る事項の特定の実施形態を実装するのに好適なコンピュータシステム１１００を示している。
【0098】
コンピュータソフトウェアは、アセンブリ、コンパイル、リンク、又は同様の機構に掛けられることで、直接的に又はインタープリット、マイクロコード実行及びこれらに類するものを介してコンピュータ中央演算処理ユニット（ＣＰＵ）、グラフィックス処理ユニット（ＧＰＵ）、及びこれらに類するものによって実行されることが可能な命令を有するコードを作り出し得るような、任意の好適な機械コード又はコンピュータ言語を用いてコード化され得る。
【0099】
命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーム装置、モノのインターネット装置、及びこれらに類するものを含め、様々なタイプのコンピュータ又はそのコンポーネント上で実行され得る。
【0100】
コンピュータシステム１１００に関して図１１に示したコンポーネントは、本質的に例示的なものであり、本開示の実施形態を実装するコンピュータソフトウェアの使用又は機能性の範囲についての何らかの限定を示唆する意図はない。また、コンポーネントの構成も、コンピュータシステム１１００のこの例示的実施形態に示されたコンポーネントの任意の１つ又は組み合わせに関する何らかの従属性又は要件も持つものとして解釈されるべきでない。
【0101】
コンピュータシステム１１００は、特定のヒューマンインタフェース入力装置を含んでもよい。そのようなヒューマンインタフェース入力装置は、例えば、触覚入力（例えば、キーストローク、スワイプ、データグローブを動かすことなど）、オーディオ入力（例えば、音声、拍手など）、視覚入力（例えば、ジェスチャなど）、嗅覚入力（図示せず）を介した、一人以上の人間ユーザによる入力に応答し得る。ヒューマンインタフェース装置はまた、例えばオーディオ（例えば、会話、音楽、周囲の音など）、画像（例えば、走査画像、静止画カメラから得られる写真画像など）、映像（例えば、２次元映像、立体視映像を含む３次元映像など）などの、人間による意識的な入力には必ずしも直接関係しない特定の媒体を捕捉するために使用されてもよい。
【0102】
入力ヒューマンインタフェース装置は、キーボード１１０１、マウス１１０２、トラックパッド１１０３、タッチスクリーン１１１０、データグローブ１１０４、ジョイスティック１１０５、マイクロフォン１１０６、スキャナ１１０７、カメラ１１０８（各々１つのみ図示している）のうちの１つ以上を含み得る。
【0103】
コンピュータシステム１１００はまた、特定のヒューマンインタフェース出力装置を含み得る。そのようなヒューマンインタフェース出力装置は、例えば、触覚出力、音、光、及び臭い／味を通して、一人以上の人間ユーザの感覚を刺激し得る。そのようなヒューマンインタフェース出力装置は、触覚出力装置（例えば、タッチスクリーン１１１０、データグローブ１１０４、又はジョイスティック１１０５による触覚フィードバックであるが、入力装置として機能しない触覚フィードバック装置もあってもよい）、オーディオ出力装置（例えば、スピーカー１１０９、ヘッドフォン（図示せず）など）、視覚出力装置（例えば、陰極線管（ＣＲＴ）スクリーン、液晶ディスプレイ（ＬＣＤ）スクリーン、プラズマスクリーン、有機発光ダイオード（ＯＬＥＤ）スクリーンを含むスクリーン１１１０（各々がタッチスクリーン入力機能を有する又は有さない。各々が触覚フィードバック機能を有する又は有さない。これらの一部は、二次元の視覚出力、又は例えば立体視出力などの手段を通じて四次元以上の出力を出力することができるとし得る。）、仮想現実グラス（図示せず）、ホログラフィックディスプレイ及びスモークタンク（図示せず）など）、及びプリンタ（図示せず）を含み得る。
【0104】
コンピュータシステム１１００はまた、例えば、ＣＤ／ＤＶＤ若しくは類似の媒体１１２１を有するＣＤ／ＤＶＤ ＲＯＭ／ＲＷ１１２０を含む光媒体、サムドライブ１１２２、取り外し可能なハードドライブ若しくは又はソリッドステートドライブ１１２３、例えばテープ及びフロッピーディスク（登録商標、図示せず）などのレガシー磁気媒体、例えばセキュリティドングルなどの特殊化されたＲＯＭ／ＡＳＩＣ／ＰＬＤベースの装置（図示せず）、及びこれらに類するものなどの、人間アクセス可能なストレージ装置及びそれらの関連媒体を含み得る。
【0105】
当業者がこれまた理解するはずのことには、ここでの開示に係る事項に関連して使用される用語“コンピュータ読み取り可能媒体”は、伝送媒体、搬送波、又は他の一時的な信号を含まない。
【0106】
コンピュータシステム１１００はまた、１つ以上の通信ネットワークへの（１つ以上の）インタフェースを含み得る。ネットワークは、例えば、無線、有線、光とし得る。ネットワークは更に、ローカル、広域、大都市、車両及び産業、リアルタイム、耐遅延などとし得る。ネットワークの例は、例えばイーサネット（登録商標）などのローカルエリアネットワーク、無線ＬＡＮ、グローバルシステムズフォーモバイルコミュニケーションズ（ＧＳＭ）、第３世代（３Ｇ）、第４世代（４Ｇ）、第５世代（５Ｇ）、ロングタームエボリューション（ＬＴＥ）及びこれらに類するものを含むセルラネットワーク、ケーブルＴＶ、衛星ＴＶ、及び地上波放送ＴＶを含むＴＶ有線又は無線広域デジタルネットワーク、ＣＡＮＢｕｓを含む車両及び産業などを含む。特定のネットワークは一般に、特定の汎用データポート又はペリフェラルバス（１１４９）（例えば、コンピュータシステム１１００のユニバーサルシリアルバス（ＵＳＢ）ポートなど）に取り付けられる外付けネットワークインタフェースアダプタを必要とし、他のものは一般に、後述のシステムバスへの取り付けによってコンピュータシステム１１００のコアに統合される（例えば、ＰＣコンピュータシステムへのイーサネットインタフェース、又はスマートフォンコンピュータシステムへのセルラネットワークインタフェース）。これらのネットワークのいずれかを使用して、コンピュータシステム１１００は、他のエンティティと通信することができる。そのような通信は、単方向の受信のみ（例えば、放送ＴＶ）であってもよいし、単方向の送信のみ（例えば、特定のＣＡＮｂｕｓ装置に対するＣＡＮｂｕｓ）であってもよいし、あるいは、例えばローカル又は広域デジタルネットワークを用いた他のコンピュータシステムに対しての、双方向であってもよい。特定のプロトコル及びプロトコルスタックが、上述のようにネットワーク及びネットワークインタフェースの各々上で使用され得る。
【0107】
前述のヒューマンインタフェース装置、人間アクセス可能なストレージ装置、及びネットワークインタフェースは、コンピュータシステム１１００のコア１１４０に取り付けられることができる。
【0108】
コア１１４０は、１つ以上の中央演算処理ユニット（ＣＰＵ）１１４１、グラフィックス処理ユニット（ＧＰＵ）１１４２、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）１１４３の形態の特殊なプログラム可能なプロセッシングユニット、特定のタスク用のハードウェアアクセラレータ１１４４などを含み得る。これらのデバイスは、読み出し専用メモリ（ＲＯＭ）１１４５、ランダムアクセスメモリ（ＲＡＭ）１１４６、例えば内部のユーザアクセス可能でないハードドライブ、ソリッドステートドライブ（ＳＳＤ）、及びこれらに類するものなどの内部大容量ストレージ１１４７と共に、システムバス１１４８を介して接続され得る。一部のコンピュータシステムにおいて、システムバス１１４８は、追加のＣＰＵ、ＧＰＵ、及びこれらに類するものによる拡張を可能にするために、１つ以上の物理プラグの形態でアクセス可能にされ得る。周辺装置は、コアのシステムバス１１４８に直接的に、又はペリフェラルバス１１４９を介して、のいずれで取り付けられてもよい。ペリフェラルバスのアーキテクチャは、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）、ＵＳＢ、及びこれらに類するものを含む。
【0109】
ＣＰＵ１１４１、ＧＰＵ１１４２、ＦＰＧＡ１１４３、及びアクセラレータ１１４４は、組み合わさって前述のコンピュータコードを構成することができる特定の命令を実行し得る。そのコンピュータコードは、ＲＯＭ１１４５又はＲＡＭ１１４６に格納され得る。ＲＡＭ１１４６には過渡的なデータも格納されることができ、永久的なデータは、例えば内部大容量ストレージ１１４７に格納されることができる。メモリデバイスのいずれかへの高速な記憶及び取り出しが、１つ以上のＣＰＵ１１４１、ＧＰＵ１１４２、大容量ストレージ１１４７、ＲＯＭ１１４５、ＲＡＭ１１４６、及びこれらに類するものの近くに付随し得るキャッシュメモリの使用によって可能にされ得る。
【0110】
コンピュータ読み取り可能媒体はその上に、様々なコンピュータ実装処理を実行するためのコンピュータコードを有することができる。媒体及びコンピュータコードは、本開示の目的に合わせて特別に設計及び構築されたものであってもよいし、あるいは、それらは、コンピュータソフトウェア技術の当業者にとって周知且つ利用可能な種類のものであってもよい。
【0111】
一例として、限定ではなく、アーキテクチャ１１００、特にコア１１４０、を有するコンピュータシステムは、１つ以上の有形のコンピュータ読み取り可能媒体に具現化されたソフトウェアを（１つ以上の）プロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡ、アクセラレータ、及びこれらに類するものを含む）が実行することの結果として機能を提供することができる。そのようなコンピュータ読み取り可能媒体は、例えばコア内部の大容量ストレージ１１４７又はＲＯＭ１１４５などの、非一時的性質のものであるコア１１４０の特定のストレージ、及び上で紹介したようなユーザアクセス可能な大容量ストレージに関連する媒体とすることができる。本開示の様々な実施形態を実装するソフトウェアは、そのような装置に格納され、コア１１４０によって実行されることができる。コンピュータ読み取り可能媒体は、具体的なニーズに従って、１つ以上のメモリデバイス又はチップを含み得る。ソフトウェアは、コア１１４０及び特にその中のプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡ、及びこれらに類するものを含む）に、ＲＡＭ１１４６に格納されるデータ構造を規定すること、及びそのようなデータ構造を、ソフトウェアによって規定されたプロセスに従って変更することを含めて、ここに記載された特定のプロセスを又は特定のプロセスの特定の部分を実行させることができる。加えて、又は代替として、コンピュータシステムは、ここに記載された特定のプロセスを又は特定のプロセスの特定の部分を実行するようにソフトウェアの代わりに又はソフトウェアと共に動作することができる回路（例えば、アクセラレータ１１４４）にて配線された又はその他の方法で具体化されたロジックの結果として、機能を提供してもよい。ソフトウェアへの言及はロジックを含み、また、適当な場合にその逆もまた然りである。コンピュータ読み取り可能媒体への言及は、実行のためのソフトウェアを格納した回路（例えば、集積回路（ＩＣ）など）、実行のためのロジックを具体化した回路、又は適当な場合にこれら双方を含み得る。本開示は、ハードウェア及びソフトウェアの好適な組み合わせを含む。
【0112】
この開示は幾つかの例示的な実施形態を記述しているが、開示の範囲に入る変更、置換、及び様々な均等な代替が存在する。従って、理解されることには、当業者は、ここでは明示的に図示されたり説明されたりしていないものの、開示の原理を具体化し、それ故に、その精神及び範囲の中にあるような、数多くのシステム及び方法を考案することができるであろう。
【図1】
【図2(a)】
【図2(b)】
【図2(c)】
【図2(d)】
【図2(e)】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
