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

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

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

特許7326463アクセスユニットのデリミター信号化のための方法、装置、およびコンピュータプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-08-04
(45)【発行日】2023-08-15
(54)【発明の名称】アクセスユニットのデリミター信号化のための方法、装置、およびコンピュータプログラム
(51)【国際特許分類】
   H04N 19/169 20140101AFI20230807BHJP
   H04N 19/172 20140101ALI20230807BHJP
   H04N 19/174 20140101ALI20230807BHJP
   H04N 19/70 20140101ALI20230807BHJP
【FI】
H04N19/169 200
H04N19/172
H04N19/174
H04N19/70
【請求項の数】 9
(21)【出願番号】P 2021558674
(86)(22)【出願日】2020-09-22
(65)【公表番号】
(43)【公表日】2022-05-26
(86)【国際出願番号】 US2020051973
(87)【国際公開番号】W WO2021061629
(87)【国際公開日】2021-04-01
【審査請求日】2021-09-29
(31)【優先権主張番号】62/904,361
(32)【優先日】2019-09-23
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】17/023,711
(32)【優先日】2020-09-17
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】520353802
【氏名又は名称】テンセント・アメリカ・エルエルシー
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】チョイ,ビョンドゥ
(72)【発明者】
【氏名】ウェンジャー,ステファン
(72)【発明者】
【氏名】リィウ,シャン
【審査官】久保 光宏
(56)【参考文献】
【文献】米国特許出願公開第2016/0044309(US,A1)
【文献】特開2013-251752(JP,A)
【文献】Byeongdoo Choi, et al.,"AHG8: On spatial scalability support with reference picture resampling",JVET-O0333,version 1,[online], Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11,2019年06月26日,Pages 1-6,[令和4年9月13日検索], インターネット, <URL: https://jvet-experts.org/doc_end_user/current_document.php?id=6938> and <URL: https://jvet-experts.org/doc_end_user/documents/15_Gothenburg/wg11/JVET-O0333-v1.zip>.
【文献】Byeongdoo Choi, et al.,"AHG17: Parameters in AUD",JVET-P0222,version 2,[online], Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11,2019年09月26日,Pages 1-2,[令和4年9月13日検索], インターネット, <URL: https://jvet-experts.org/doc_end_user/current_document.php?id=8011> and <URL: https://jvet-experts.org/doc_end_user/documents/16_Geneva/wg11/JVET-P0222-v2.zip>.
【文献】大久保 榮 監修,「インプレス標準教科書シリーズ H.265/HEVC教科書」,初版,日本,株式会社インプレスジャパン,2013年10月21日,第63,93-95,101,162,192-197,208-214頁,及び第291,292,298,333頁, ISBN: 978-4-8443-3468-2.
(58)【調査した分野】(Int.Cl.,DB名)
H04N19/00-19/98
CSDB(日本国特許庁)
学術文献等データベース(日本国特許庁)
IEEEXplore(IEEE)
(57)【特許請求の範囲】
【請求項1】
少なくとも1つのプロセッサによって実行されるビデオ符号化方法であって、
ビデオデータを獲得するステップと、
前記ビデオデータを符号化してアクセスユニットを生成するステップと、
前記生成されたアクセスユニットの境界を示すアクセスユニットデリミターを各々のアクセスユニットに対応付けて生成するステップと、を有し、
前記アクセスユニットデリミターは、
対応するアクセスユニットを構成するスライスのスライスタイプ値を示すシンタックス要素、および、
対応するアクセスユニットを構成するスライスが格納されるネットワーク抽象化レイヤ(NAL)ユニットのユニットタイプを示すランダムアクセスポイント(RAP)シンタックス要素、を有し、
前記各々のシンタックス要素は、当該シンタックス要素を生成する必要があることが、シンタックスに基づいて判断された場合に生成されて、前記アクセスユニットデリミターに格納され、
前記RAPシンタックス要素が0に設定されていることは、
前記RAPシンタックス要素を含む前記アクセスユニットデリミターが対応付けられているアクセスユニットが、トレーリングピクチャ値の符号化スライス、ステップ毎の時間的サブレイヤアクセス(STSA)ピクチャ値の符号化スライス、ランダムアクセススキップ先行(RASL)ピクチャ値の符号化スライス、および、ランダムアクセス復号可能先行(RADL)ピクチャ値の符号化スライスのうち少なくとも1つを含む、ことを意味する、
方法。
【請求項2】
前記アクセスユニットデリミターは、さらに、
隣接するアクセスユニット間の関連するアクセスユニットを識別するアクセスユニットオーダーカウント値を示すシンタックス要素、を有し、
前記アクセスユニットオーダーカウント値は、前記アクセスユニットの境界を識別するために使用され、前記アクセスユニットオーダーカウント値を解析することによって、前記アクセスユニットの喪失を確認することができる、
請求項1に記載の方法。
【請求項3】
前記RAPシンタックス要素が1に設定されていることは、
前記RAPシンタックス要素を含む前記アクセスユニットデリミターが対応付けられているアクセスユニットが、即時デコーダ参照(IDR)ピクチャ値の符号化スライス、クリーンランダムアクセス(CRA)ピクチャ値の符号化スライス、および、段階的デコーディング参照(GDR)ピクチャ値の符号化スライスのうちの少なくとも1つを含む、ことを意味する、
請求項1に記載の方法。
【請求項4】
記アクセスユニットオーダーカウント値は、
前記シンタックスに基づいて、0から225までの範囲内のいずれかの値とされる、
請求項に記載の方法。
【請求項5】
前記シンタックスに基づいて、
前記スライスタイプ値を、0、1、および2のいずれかの値に設定するステップ、を含む、
請求項に記載の方法。
【請求項6】
前記シンタックスに基づいて、
前記スライスタイプ値は、イントラ予測スライスおよびインター予測スライスのうち少なくとも1つの存在を示す、
請求項に記載の方法。
【請求項7】
ビデオ符号化のための装置であって、
コンピュータプログラムコードを保管するように構成された、少なくとも1つのメモリと、
前記コンピュータプログラムコードにアクセスし、かつ、前記コンピュータプログラムコードの指示によって動作するように構成された、少なくとも1つのプロセッサと、を含み、
前記プロセッサによって実行されると、前記コンピュータプログラムコードは、前記装置に、
請求項1乃至のいずれか一項に記載の方法を実施させる、
装置。
【請求項8】
コンピュータにプロセスを実行させるコンピュータプログラムであって、前記コンピュータプログラムは、命令を含み、プロセッサによって前記命令が実行されると、前記プロセスは、
請求項1乃至のいずれか一項に記載の方法を実施する、
コンピュータプログラム。
【請求項9】
少なくとも1つのプロセッサによって実行されるビデオ復号方法であって、
符号化ビデオビットストリームを獲得するステップと、
前記符号化ビデオビットストリームからアクセスユニットを獲得するステップと、
前記獲得されたアクセスユニットの境界を示すアクセスユニットデリミターを獲得するステップと、を有し、
前記アクセスユニットデリミターは、
対応するアクセスユニットを構成するスライスのスライスタイプ値を示すシンタックス要素、および、
対応するアクセスユニットを構成するスライスが格納されるネットワーク抽象化レイヤ(NAL)ユニットのユニットタイプを示すランダムアクセスポイント(RAP)シンタックス要素、を有し、
前記各々のシンタックス要素は、当該シンタックス要素を生成する必要があることが、シンタックスに基づいて判断された場合に生成されて、前記アクセスユニットデリミターに格納され、
前記RAPシンタックス要素が0に設定されていることは、
前記RAPシンタックス要素を含む前記アクセスユニットデリミターが対応付けられているアクセスユニットが、トレーリングピクチャ値の符号化スライス、ステップ毎の時間的サブレイヤアクセス(STSA)ピクチャ値の符号化スライス、ランダムアクセススキップ先行(RASL)ピクチャ値の符号化スライス、および、ランダムアクセス復号可能先行(RADL)ピクチャ値の符号化スライスのうち少なくとも1つを含む、ことを意味する、
方法。

【発明の詳細な説明】
【技術分野】
【0001】
本開示は、ランダムアクセスユニット(AU)情報の指示およびAU境界検出のロバスト性を改善することに向けられている。
【0002】
関連出願の相互参照
本出願は、2019年9月23日に出願された米国仮特許出願第62/904361号、および、2020年9月17日に出願された米国特許出願第17/023711号について優先権を主張するものであり、それらの全体が本明細書に組み込まれている。
【背景技術】
【0003】
ITU-T VCEG(Q6/16)およびISO/IEC MPEG(JTC 1/SC 29/WG11)は、2013年(バージョン1)、2014年(バージョン2)、2015年(バージョン3)、および2016年(バージョン4)にH.265/HEVC(High Efficiency Video Coding)規格を公表した。2017年10月には、HEVCを超えた次世代映像符号化規格の開発の可能性を探るため、2015年に両標準組織がJVET(Joint Video Exploration Team)を結成し、HEVCを超える映像圧縮の提案に関する共同募集(Call for Proposals on Video Compression with Capability beyond HEVC、CfP)を発表した。2018年2月15日までに、標準ダイナミックレンジ(SDR)について合計22個のCfP応答、高ダイナミックレンジ(HDR)について12個のCfP応答、および、360のビデオカテゴリーについて12個のCfP応答をそれぞれ提出した。2018年4月には、第122回のMPEG/第10回JVET会議において、全てのCfP回答が評価された。この会議の結果、JVETは、HEVCを超えた次世代ビデオ符号化の標準化プロセスを正式に開始した。この新しい規格はVersatile Video Coding(VVC)と命名され、そして、JVETはJoint Video Expert Teamに改名された。VTM(VVC Test Model)の現在のバージョン、すなわちVTM 6である。
【0004】
そうした技術分野におけるアクセスユニット境界を示すためにアクセスユニットデリミター(Access Unit Delimiter、AUD)を義務的に信号化するか否かは不明であり、かくして、信号伝達におけるそうしたロバスト性の欠如、および、従って正確性および効率性に対する技術的解決策が望まれている。
【発明の概要】
【0005】
方法および装置が含まれており、それらは、コンピュータプログラムコードを保管するように構成されたメモリと、コンピュータプログラムコードにアクセスし、かつ、コンピュータプログラムコードにより指示されて動作するように構成されたプロセッサと、を含んでいる。前記コンピュータプログラムコードは、前記少なくとも1つのプロセッサに、ビデオデータを獲得させるように構成された獲得コードと、前記少なくとも1つのプロセッサに、前記ビデオデータの少なくとも1つのネットワーク抽象化レイヤ(NAL)ユニットに係るアクセスユニットのデリミターシンタックスを決定させるように構成された第1決定コードと、前記少なくとも1つのプロセッサに、前記アクセスユニットのデリミターシンタックスが、前記NALユニットのスライスタイプ値を示すか否かを決定させるように構成された第2決定コードと、前記少なくとも1つのプロセッサに、前記NALユニットに係る前記アクセスユニットのデリミターシンタックスが、前記NALユニットのビデオ符号化レイヤ(VCL)値およびアクセスユニットオーダーカウント値のうち少なくとも1つを示すか否かを決定させるように構成された第3決定コードと、前記少なくとも1つのプロセッサに、前記アクセスユニットのデリミターシンタックスが、前記スライスタイプ値、前記VCL値、および、前記アクセスユニットオーダーカウント値のうち少なくとも1つを示すか否かに応じて、前記NALユニットのアクセスユニット境界値を信号化させるように構成された信号化コードと、を含む。
【0006】
典型的な実施形態に従って、前記第3決定コードは、さらに、前記少なくとも1つのプロセッサに、前記VCL値の少なくとも1つが、0、1、および2のいずれかの値に設定されているか否かを決定することによって、前記NALユニットの前記アクセスユニットのデリミターシンタックスが、前記NALユニットのVCL値およびアクセスユニットオーダーカウント値のうち少なくとも1つを示すか否かを決定することを実施させる。
【0007】
典型的な実施形態に従って、前記信号化コードは、さらに、前記少なくとも1つのプロセッサに、VCL値のうち少なくとも1つが0に設定されていることを前記アクセスユニットのデリミターが示す、との決定に基づいて、トレーリングピクチャ値の符号化スライス、ステップ毎の時間的サブレイヤアクセス(STSA)ピクチャ値の符号化スライス、ランダムアクセススキップ先行(RASL)ピクチャ値の符号化スライス、および、ランダムアクセス復号可能先行(RADL)ピクチャ値の符号化スライスのうち少なくとも1つを信号化することによって、前記NALユニットのアクセス境界値を信号化することを実施させる。
【0008】
典型的な実施形態に従って、前記信号化コードは、さらに、前記少なくとも1つのプロセッサに、VCL値のうち少なくとも1つが1に設定されていることを前記アクセスユニットのデリミターが示す、との決定に基づいて、即時デコーダ参照(IDR)ピクチャ値の符号化スライス、クリーンランダムアクセス(CRA)ピクチャ値の符号化スライス、および、段階的デコーディング参照(GDR)ピクチャ値の符号化スライスのうちの少なくとも1つを信号化することによって、前記NALユニットのアクセス境界値を信号化することを実施させる。
【0009】
典型的な実施形態に従って、前記信号化コードは、さらに、前記少なくとも1つのプロセッサに、VCL値のうち少なくとも1つが2に設定されていることを前記アクセスユニットのデリミターが示す、との決定に基づいて、アクセスユニット内の符号化画像の複数のスライスについて、複数のVCL値を信号化することを実施させる。
【0010】
典型的な実施形態に従って、前記第3決定コードは、さらに、前記少なくとも1つのプロセッサに、前記NALユニットのアクセスユニットオーダーカウント値が、アクセスユニットを識別するか否かを決定することによって、前記NALユニットに係る前記アクセスユニットのデリミターシンタックスが、前記NALユニットのVCL値およびアクセスユニットオーダーカウント値のうち少なくとも1つを示すか否かを決定することを実施させる。
【0011】
典型的な実施形態に従って、前記第3決定コードは、さらに、前記少なくとも1つのプロセッサに、前記アクセスユニットオーダーカウント値が、0から225までの範囲内にあるか否かを決定することによって、前記NALユニットに係る前記アクセスユニットのデリミターシンタックスが、前記NALユニットのVCL値およびアクセスユニットオーダーカウント値のうち少なくとも1つを示すか否かを決定することを実施させる。
【0012】
典型的な実施形態に従って、前記第3決定コードは、さらに、前記少なくとも1つのプロセッサに、前記NALユニットに係る前記アクセスユニットオーダーカウント値が、隣接するアクセスユニット間で前記アクセスユニットを識別するか否かを決定することによって、前記NALユニットに係る前記アクセスユニットのデリミターシンタックスが、前記NALユニットのVCL値およびアクセスユニットオーダーカウント値のうち少なくとも1つを示すか否かを決定することを実施させる。
【0013】
典型的な実施形態に従って、前記第2決定コードは、さらに、前記少なくとも1つのプロセッサに、前記スライスタイプ値が、0、1、および2のいずれかの値に設定されているか否かを決定することによって、前記アクセスユニットのデリミターシンタックスが、前記NALユニットのスライスタイプ値を示すか否かを決定することを実施させる。
【0014】
典型的な実施形態に従って、前記第2決定コードは、さらに、イントラ予測スライスおよびインター予測スライスのうち少なくとも1つの存在を決定することによって、前記アクセスユニットのデリミターシンタックスが、前記スライスタイプ値を示すか否かを決定することを実施させる。
【図面の簡単な説明】
【0015】
開示された技術的事項(subject matter)のさらなる特徴、性質、および種々の利点は、以下の詳細な説明および添付の図面からより明らかになるだろう
図1図1は、実施形態に従った、模式図の簡略化された図である。
図2図2は、実施形態に従った、模式図の簡略化された図である。
図3図3は、実施形態に従った、模式図の簡略化された図である。
図4図4は、実施形態に従った、模式図の簡略化された図である。
図5図5は、実施形態に従った、ダイアグラムの簡略化された図である。
図6図6は、実施形態に従った、ダイアグラムの簡略化された図である。
図7図7は、実施形態に従った、ダイアグラムの簡略化された図である。
図8図8は、実施形態に従った、ダイアグラムの簡略化された図である。
図9A図9Aは、実施形態に従った、ダイアグラムの簡略化された図である。
図9B図9Bは、実施形態に従った、ダイアグラムの簡略化された図である。
図10図10は、実施形態に従った、フローチャートの簡略化された図である。
図11図11は、実施形態に従った、簡略化されたフロー図である。
図12A図12Aは、実施形態に従った、ダイアグラムの簡略化された図である。
図12B図12Bは、実施形態に従った、ダイアグラムの簡略化された図である。
図13図13は、実施形態に従った、フローチャートの簡略化された図である。
図14図14は、実施形態に従った、フローチャートの簡略化された図である。
図15図15は、実施形態に従った、模式図の簡略化された図である。
【発明を実施するための形態】
【0016】
以下で説明される提案された特徴は、別々に、または、任意の順序で組み合わせて使用され得る。さらに、実施形態は、処理回路(例えば、1つ以上のプロセッサまたは1つ以上の集積回路)によって実施されてよい。一つの例において、1つ以上のプロセッサは、非一時的なコンピュータ読取り可能媒体に保管されたプログラムを実行する。
【0017】
図1は、本開示の一つの実施形態に従った、通信システム100の簡略化されたブロック図を示す。通信システム100は、ネットワーク105を介して相互接続された少なくとも2つの端末(terminals)102および103を含んでよい。データの一方向(unidirectional)伝送のために、第1端末103は、ネットワーク105を介して他方の端末102に伝送するために、ローカル位置のビデオデータを符号化することができる。第2端末102は、ネットワーク105から他方の端末の符号化されたビデオデータを受信し、符号化されたデータを復号し、回復されたビデオデータを表示することができる。一方向性データ伝送は、メディア提供アプリケーション、等において一般的である。
【0018】
図1は、例えば、ビデオ会議中に発生し得る符号化ビデオの双方向(bidirectional)伝送をサポートするために備えられた端末101および104の第2ペアを示す。データの双方向伝送のために、各端末101および104は、ローカル位置でキャプチャされたビデオデータを、ネットワーク105を介して他方の端末に伝送するために符号化することができる。各端末101および104はまた、他方の端末によって送信された符号化ビデオデータを受信することができ、符号化データを復号することができ、そして、復元されたビデオデータをローカルディスプレイ装置に表示することができる。
【0019】
図1において、端末101、102、103および104は、サーバ、パーソナルコンピュータ、およびスマートフォンとして図示することができるが、本開示の原理は、それに限定されるものではない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディア・レーヤ、及び/又は専用のビデオ会議装置への適用を見出す。ネットワーク105は、例えば、有線及び/又は無線通信ネットワークを含む、端末101、102、103、および104の間で符号化されたビデオデータを伝達する任意の数のネットワークを表す。通信ネットワーク105は、回線交換及び/又はパケット交換チャネル内のデータを交換することができる。代表的なネットワークには、通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、及び/又はインターネットが含まれる。本説明の目的のために、ネットワーク105のアーキテクチャおよびトポロジーは、以下で説明しされなければ、本開示の動作にとって重要ではない。
【0020】
図2は、開示される技術的事項についてアプリケーションの実施例として、ストリーミング環境におけるビデオエンコーダおよびデコーダの配置を示している。開示される技術的事項は、他のビデオ可能化アプリケーションにも同様に適用可能であり、例えば、ビデオ会議、デジタルTV、および、CD、DVD、メモリスティックなどを含むデジタルメディア上の圧縮ビデオの保管、などを含んでいる。
【0021】
ストリーミングシステムは、キャプチャ・サブシステム203を含んでよく、例えば、非圧縮ビデオサンプルストリーム213を生成するビデオソース201、例えばデジタルカメラを含むことができる。このサンプルストリーム213は、エンコードされたビデオビットストリームと比較した場合に、高いデータボリュームとして強調することができ、カメラ201に結合されたエンコーダ202によって処理することができる。エンコーダ202は、以下でより詳細に説明されるように、開示される技術的事項の態様を可能にし、または、実施するために、ハードウェア、ソフトウェア、または、それらの組み合わせを含むことができる。サンプルストリームと比較すると、より低いデータボリュームとして強調することができる符号化ビデオビットストリーム204は、将来の使用のためにストリーミングサーバ205に保管することができる。1つ以上のストリーミングクライアント212および207は、ストリーミングサーバ205にアクセスして、符号化ビデオビットストリーム204のコピー208および206を検索(retrieve)することができる。クライアント212は、符号化ビデオビットストリーム208の入力コピーをデコードし、ディスプレイ209または他のレンダリング装置(図示なし)でレンダリング可能な出力ビデオサンプルストリーム210を生成するビデオデコーダ211を含むことができる。いくつかのストリーミングシステムにおいて、ビデオビットストリーム204、206および208は、特定のビデオ符号化/圧縮標準に従って符号化することができる。これらの標準の例は、上述されており、かつ、ここにおいてさらに説明される。
【0022】
図3は、本発明の一つの実施形態に従った、ビデオデコーダ300の機能ブロック図であり得る。
【0023】
受信器302は、デコーダ300によってデコードされるべき1つ以上のコーデックビデオシーケンスを受信することができ、同じ実施形態または別の実施形態において、一度に1つの符号化ビデオシーケンスを受信することができ、ここで、各符号化ビデオシーケンスのデコードは、他の符号化ビデオシーケンスから独立している。符号化ビデオシーケンスは、符号化されたビデオデータを保管する記憶装置へのハードウェア/ソフトウェアリンクであり得る、チャネル301から受信され得る。受信器302は、符号化されたビデオデータを、例えば、符号化されたオーディオデータ及び/又は補助的なデータストリームなどの他のデータと共に受信することができ、これらのデータは、それぞれのエンティティ(図示なし)を使用して転送することができる。受信器302は、符号化ビデオシーケンスを他のデータから分離することができる。ネットワークジッタに対抗するために、バッファメモリ303は、受信器302とエントロピーデコーダ/パーサ304(以下、「パーサ(“parser”)」)との間に接続されてよい。受信器302が、十分な帯域幅および制御可能性を有するストア/フォワード装置から、または、アイソシンクロナス(isosychronous)ネットワークからデータを受信している場合、バッファ303は不要であってよく、または、小さくてもよい。インターネットといったベストエフォート型パケットネットワークでの使用のためには、バッファ303が、必要とされ、そして、比較的大きく、有利に適応サイズであり得る。
【0024】
ビデオデコーダ300は、エントロピー符号化ビデオシーケンスからシンボル313を再構成するためのパーサ304を含んでよい。これらのシンボルのカテゴリは、デコーダ300の動作を管理するために使用される情報と、デコーダの不可欠な部分ではないが、デコーダに結合することができるディスプレイ312といったレンダリング装置を制御する潜在的な情報とを含む。レンダリングデバイスの制御情報は、補足拡張情報(Supplementary Enhancement Information)(SEI message)、またはビデオユーザビリティ情報パラメータセットフラグメント(図示なし)の形式であってよい。パーサ304は、受信した符号化ビデオシーケンスを解析/エントロピー復号することができる。符号化ビデオシーケンスの符号化は、ビデオ符号化技術または標準に従うことができ、可変長符号化、ハフマン符号化(Huffman coding)、コンテキスト感度を伴うか又は伴わない算術符号化、などを含む、当業者にとって周知の原理に従うことができる。パーサ304は、グループに対応する少なくとも1つのパラメータに基づいて、ビデオデコーダ内のピクセルのサブグループのうち少なくとも1つに対するサブグループパラメータのセットである符号化ビデオシーケンスから抽出することができる。サブグループには、画像のグループ(GOP)、画像、タイル、スライス、マクロブロック、コーディングユニット(CU)、ブロック、変換ユニット(TU)、予測ユニット(PU)、等が含まれる。エントロピーデコーダ/パーサは、また、変換係数、量子化パラメータ値、動きベクトル、等の符号化ビデオシーケンス情報から抽出することもできる。
【0025】
パーサ304は、シンボル313を生成するために、バッファ303から受信したビデオシーケンスに対してエントロピー復号/解析(parsing)動作を実行することができる。パーサ304は、符号化されたデータを受信し、そして、特定のシンボル313を選択的に復号することができる。さらに、パーサ304は、特定のシンボル313が、動き補償予測ユニット306、スケーラ/逆変換ユニット305、イントラ予測ユニット307、またはループフィルタ311に提供されるか否かを決定することができる。
【0026】
シンボル313の再構成は、符号化されたビデオ画像のタイプまたはその部分(画像間および画像内、ブロック間およびブロック内、といったもの)および他の要因に応じて、複数の異なるユニットを含むことができる。どのユニットが関与し、そして、どのように制御されるかは、パーサ304により符号化ビデオシーケンスから解析されたサブグループ制御情報によって、制御することができる。パーサ304と、以下の複数ユニットとの間のそうしたサブグループ制御情報の流れは、明確にするために図示されていない。
【0027】
既に述べた機能ブロックの他に、デコーダ300は、概念的には、以下に説明するように、いくつかの機能ユニットに分割することができる。商業的制約の下で動作する実用的な実装では、これらのユニットの多くは、互いに密接に相互作用し、そして、少なくとも部分的には、互いに統合することができる。しかしながら、開示される技術的事項を説明するためには、以下の機能単位へと概念的に細分化することが適切である。
【0028】
第1ユニットは、スケーラ/逆変換ユニット305である。スケーラ/逆変換ユニット305は、使用するための変換、ブロックサイズ、量子化係数、量子化スケーリング行列(matrices)、等を含む制御情報とともに、量子化された変換係数をパーサ304からシンボル313として受信する。それは、アグリゲータ(aggregator)310への入力であり得る、サンプル値を含むブロックを出力することができる。
【0029】
場合によって、スケーラ/逆変換305の出力サンプルは、イントラ符号化ブロック(intra coded block)、すなわち、以前に再構成された画像からの予測情報を使用していないが、現在の画像の以前に再構成された部分からの予測情報を使用することができるブロック、に関連付けることができる。そうした予測情報は、イントラ画像予測ユニット307によって提供することができる。場合によって、イントラ画像予測ユニット307は、現在の(部分的に再構成された)画像309から取り出された既に再構成された周囲の情報を使用して、再構成中のブロックと同じサイズおよび形状のブロックを生成する。アグリゲータ310は、場合によって、サンプル毎に、イントラ予測ユニット307が生成した予測情報を、スケーラ/逆変換ユニット305によって提供される、出力サンプル情報に追加する。
【0030】
他の場合に、スケーラ/逆変換ユニット305の出力サンプルは、インター符号化(inter coded)され、かつ、潜在的に動き補償された(motion compensated)ブロックに関連することができる。そうした場合に、動き補償予測ユニット306は、予測のために使用されるサンプルを取り出すために参照画像メモリ308にアクセスすることができる。ブロックに関連するシンボル313に従ってフェッチされたサンプルを動き補償した後で、これらのサンプルは、出力サンプル情報を生成するために、アグリゲータ310によってスケーラ/逆変換ユニットの出力(この場合は、残留サンプルまたは残留信号と呼ばれる)に追加され得る。動き補償ユニットが予測サンプルをフェッチする参照画像メモリ形態内のアドレスは、例えばX、Y、および参照画像コンポーネントを有することができるシンボル313の形態で、動き補償ユニットに利用可能な動きベクトルによって制御され得る。また、動き補償は、サブサンプルの正確な動きベクトルが使用されているときに基準ピクチャメモリからフェッチされるサンプル値の補間、動きベクトル予測メカニズムなどを含むこともできる。
【0031】
アグリゲータ310の出力サンプルは、ループフィルタユニット311内の様々なループフィルタリング技術に従うことができる。ビデオ圧縮技術は、符号化ビデオビットストリームに含まれるパラメータによって制御され、パーサ304からシンボル313としてループフィルタユニット311に利用可能にされるが、符号化画像または符号化ビデオシーケンスの前の(復号化順における)部分の復号化中に獲得されたメタ情報に応答することができ、また、以前に再構成されループフィルタリングされたサンプル値に応答することができる、ループ内フィルタ技術を含むことができる。
【0032】
ループフィルタユニット311の出力は、レンダリング装置312に出力することができ、同様に、将来の画像間予測に使用するために参照画像メモリ557内に保管することができる、サンプルストリームであり得る。
【0033】
所定の符号化画像は、一旦、完全に再構成されると、将来の予測のための参照画像(reference image)として使用することができる。一旦、符号化画像が完全に再構成され、そして、符号化画像が参照画像として識別されると(例えば、パーサ304によって)、現在の参照画像309は、参照画像バッファ308の一部となり、そして、次の符号化画像の再構成を開始する前に、新しい現在の画像メモリが再割り当てされる。
【0034】
ビデオデコーダ300は、ITU-T Rec.H.265といった、標準で文書化され得る既定のビデオ圧縮技術に従ってデコーディング動作を実行することができる。符号化ビデオシーケンスは、ビデオ圧縮技術文書または標準の中で、特にその中のプロファイル文書の中で規定されているように、ビデオ圧縮技術または標準のシンタックスに従うという意味で、使用されているビデオ圧縮技術または標準によって規定されたシンタックスに適合することができる。また、コンプライアンスのために必要なことは、符号化ビデオシーケンスの複雑さが、ビデオ圧縮技術または標準のレベルによって定義される範囲内にあることである。場合によって、レベルは、最大画像サイズ、最大フレームレート、最大再構成サンプルレート(例えば、毎秒メガサンプルで測定される)、最大参照画像サイズ、などを制限する。レベルによって設定された制限値は、場合によって、符号化されたビデオシーケンスにおいて信号化されたHRDバッファ管理のための仮想参照デコーダ(Hypothetical Reference Decoder、HRD)仕様およびメタデータを通してさらに制限することができる。
【0035】
一つの実施形態において、受信器302は、符号化されたビデオと共に追加の(冗長な)データを受信することができる。追加データは、符号化ビデオシーケンスの一部として含まれ得る。追加データは、データを適切にデコードするため、かつ/あるいは、元のビデオデータをより正確に再構成するために、ビデオデコーダ300によって使用されてよい。追加のデータは、例えば、時間的、空間的、または信号対雑音比強化層、冗長スライス、冗長画像、順方向エラー補正コードなどの形態であり得る。
【0036】
図4は、本開示の一つの実施形態に従った、ビデオエンコーダ400の機能ブロック図であり得る。
【0037】
エンコーダ400は、エンコーダ400によって符号化されるビデオ画像をキャプチャすることができるビデオソース401(エンコーダの一部ではない)からビデオサンプルを受け取ることができる。
【0038】
ビデオソース401は、任意の適切なビット深さ(例えば、8ビット、10ビット、12ビット、...)、任意の色空間(例えば、BT.601 Y CrCB、RGB、...)、および任意の適切なサンプリング構造(例えば、Y CrCb 4:2:0、Y CrCb 4:4:4)であり得る、デジタルビデオサンプルストリームの形態で、エンコーダ(303)によって符号化されるソースビデオシーケンスを提供することができる。メディア配信システムにおいて、ビデオソース401は、事前に準備されたビデオを保管するストレージ装置であってよい。ビデオ会議システムにおいて、ビデオソース401は、ローカル画像情報をビデオシーケンスとしてキャプチャするカメラであってよい。ビデオデータは、シーケンスで見たときに動きを伝える複数の個々の画像として提供されてよい。画像自体は、ピクセルの空間アレイとして構成されてもよく、各ピクセルは、使用中のサンプリング構造、色空間、等に応じて、1つ以上のサンプルを含むことができる。当業者であれば、画素と試料との関係を容易に理解することができる。以下の説明は、サンプルに焦点を当てている。
【0039】
一つの実施形態に従って、エンコーダ400は、ソースビデオシーケンスの画像を、アプリケーションによって要求されるように、リアルタイムで、または、任意の他の時間制約下で、符号化ビデオシーケンス410へと符号化および圧縮することができる。適切な符号化速度を実施することは、コントローラ402の1つの機能である。コントローラは、以下に説明されるように他の機能ユニットを制御し、これらのユニットに機能的に結合されている。結合は、明確にするために示されていない。コントローラによって設定されるパラメータは、レート(rate)制御関連パラメータ(ピクチャスキップ、量子化器、レート歪み最適化技法のラムダ値(lambda value)、...)、ピクチャサイズ、ピクチャグループ(group of pictures、GOP)レイアウト、最大動きベクトル探索範囲、などを含み得る。当業者であれば、コントローラ402の他の機能を、それらが所定のシステム設計のために最適化されたビデオエンコーダ400に関連し得るので、容易に識別することができる。
【0040】
いくつかのビデオエンコーダは、当業者が「符号化ループ(“coding loop”)」として容易に認識できるように動作する。単純化されすぎた説明として、符号化ループは、エンコーダ402(以下、「ソースコーダ(“source coder”)」)(符号化される入力ピクチャおよび参照画像に基づいてシンボルを生成する責任を負う)の符号化部分、および、
エンコーダ400に埋め込まれた(ローカル)デコーダ406とから構成され、これは、(リモート)デコーダが生成する、サンプルデータを生成するためのシンボルを再構成する(シンボルと符号化ビデオビットストリームとの間の任意の圧縮が、開示される技術的事項において考慮されるビデオ圧縮技術において可逆的であるため)エンコーダ400に埋め込まれた(ローカル)デコーダ406、から構成され得る。再構成されたサンプルストリームは、参照画像メモリ405に入力される。シンボルストリームの復号化は、デコーダ位置(ローカルまたはリモート)に依存しないビット正確な結果をもたらすので、参照画像バッファコンテンツもローカルエンコーダとリモートエンコーダの間でビット正確である。言い換えると、エンコーダの予測ユニット部分は、デコーダが復号の最中に予測を使用するときに「見る(“see”)」のと同一のサンプル値を参照画像サンプルとして「見る」。参照画像同期性のこの基本原理(および、例えば、チャンネルエラーのために同期性を維持することができない場合の結果として生じるドリフト)は、当業者にとって周知である。
【0041】
「ローカル(“local”)」デコーダ406の動作は、「リモート(“remote”)」デコーダ300と同一であってよく、図3に関連して既に詳細に説明された。図4も、また、簡単に参照すると、しかしながら、シンボルが利用可能であり、かつ、エントロピーコーダ408およびパーサ304による符号化ビデオシーケンスへのシンボルの符号化/復号化が可逆であり得るので、チャネル301、受信器302、バッファ303、およびパーサ304を含むデコーダ300のエントロピー復号部分は、ローカルデコーダ406において完全には実装されなくてよい。
【0042】
この時点で行うことができる観察は、デコーダ内に存在する解析/エントロピー復号を除く任意のデコーダ技術も、また、対応するエンコーダ内に実質的に同一の機能的形態で存在する必要があることである。エンコーダ技術の説明は、包括的に記述されたデコーダ技術の逆であるため、省略することができる。所定の分野においてのみ、より詳細な説明が必要であり、以下に提供される。
【0043】
その動作の一部として、ソースコーダ403は、動き補償予測符号化を実行することができる。それは、「参照フレーム(“reference frame”)」として指定されたビデオシーケンスからの1つ以上の事前に符号化されたフレームに関して入力フレームを予測的に符号化するものである。このようにして、符号化エンジン407は、入力フレームの画素ブロックと、入力フレームに対する予測基準として選択され得る参照フレームの画素ブロックとの間の差を符号化する。
【0044】
ローカルビデオデコーダ406は、ソースコーダ403によって生成されたシンボルに基づいて、参照フレームとして指定され得るフレームの符号化されたビデオデータをデコードすることができる。符号化エンジン407の動作は、有利なことに、損失プロセスであり得る。符号化されたビデオデータがビデオデコーダ(図4には示されていない)でデコードされ得る場合、再構成されたビデオシーケンスは、典型的には、いくつかのエラーを伴うソースビデオシーケンスのレプリカであり得る。ローカルビデオデコーダ406は、参照フレーム上でビデオデコーダによって実行される復号化プロセスを複製し、再構成された参照フレームを参照画像キャッシュ405に保管させることができる。このようにして、エンコーダ400は、遠端(far-end)のビデオデコーダによって(伝送エラーなく)獲得される再構成された参照フレームとして共通のコンテンツを有する再構成された参照フレームのコピーを、ローカルに保管することができる。
【0045】
予測器404は、符号化エンジン407の予測探索を実行することができる。すなわち、符号化されるべき新しいフレームに対して、予測器404は、サンプルデータ(参照ピクセルブロック候補として)、または、参照画像動きベクトル、ブロック形状など、といった、いくつかのメタデータについて参照画像メモリ405を検索することができ、そして、これらは、新しいピクチャのための適切な予測参照として役立ち得る。予測器404は、適切な予測参照を見出すために、サンプルブロック毎に動作することができる。場合によっては、予測器404によって獲得された検索結果によって決定されるように、入力ピクチャは、参照画像メモリ405に保管された複数の参照画像から引き出された予測参照を有し得る。
【0046】
コントローラ402は、例えば、ビデオデータを符号化するために使用されるパラメータおよびサブグループパラメータの設定を含む、ビデオコーダ403の符号化動作を管理することができる。
【0047】
全ての前述の機能ユニットの出力は、エントロピーコーダ408におけるエントロピー符号化を受け得る。エントロピーコーダは、例えば、ハフマン符号化、可変長符号化、算術符号化など、当業者に知られた技術に従って、符号を損失なく(loss-less)圧縮することによって、種々の機能ユニットによって生成された記号を符号化ビデオシーケンスへと変換する。
【0048】
送信器409は、エントロピーコーダ408によって生成されるように符号化ビデオシーケンスをバッファすることができ、通信チャネル411を介した送信の準備をする。それは、符号化ビデオデータを保管するストレージ装置に対するハードウェア/ソフトウェアリンクであり得る。送信器409は、ビデオコーダ403からの符号化されたビデオデータを、例えば、符号化されたオーディオデータ及び/又は補助的なデータストリーム(ソースは図示されていない)など、送信される他のデータとマージすることができる。
【0049】
コントローラ402は、エンコーダ400の動作を管理することができる。符号化の最中、コントローラ405は、各符号化画像に対して所定の符号化画像タイプを割り当てることができ、これは、それぞれの画像に適用され得る符号化技術に影響を及ぼし得る。例えば、写真は、しばしば次に続くフレームタイプの1つとして割り当てられ得る。
【0050】
イントラピクチャ(Iピクチャ)は、予測のソースとしてシーケンス内の他のフレームを使用せずに、符号化され、かつ、復号され得るものであってよい。いくつかのビデオコーデックは、例えば、独立デコーダ・リフレッシュ・ピクチャ(Independent Decoder Refresh Pictures)を含む、異なるタイプのイントラピクチャを許容する。当業者であれば、Iピクチャのこれらの変形例、並びに、それらのそれぞれのアプリケーションおよび特徴を把握している。
【0051】
予測ピクチャ(Pピクチャ)は、各ブロックのサンプル値を予測するために、最大で1つの動きベクトルおよび参照インデックスを用いるイントラ予測(intra prediction)またはインター予測(inter prediction)を使用して、符号化され、かつ、復号され得るものであってよい。
【0052】
双方向予測ピクチャ(Bピクチャ)は、各ブロックのサンプル値を予測するために、最大で2つの動きベクトルと参照インデックスを用いるイントラ予測またはインター予測を使用して、符号化され、かつ、復号され得るものであってよい。同様に、複数の予測画像は、1つのブロックの再構成のために、2つ以上の参照画像および関連するメタデータを使用することができる。
【0053】
ソース画像は、通常、空間的に複数のサンプルブロック(例えば、4×4、8×8、4×8、または16×16の各サンプルのブロック)に分割され、そして、ブロック毎に符号化される。ブロックは、ブロックのそれぞれの画像に適用される符号化割り当てによって決定されるように、他の(既に符号化された)ブロックを参照して予測的に符号化され得る。例えば、Iピクチャのブロックは、非予測的に符号化されてよく、または、それらは、同じ画像の既に符号化されたブロック(空間的(spatial)予測またはイントラ予測)を参照して予測的に符号化されてよい。Pピクチャの画素ブロックは、以前に符号化された1つの参照画像を参照して、非予測的に、空間的予測または時間的予測を介して符号化され得る。Bピクチャのブロックは、1つまたは2つの以前に符号化された参照画像を参照して、非予測的に、空間的予測または時間的予測を介して符号化され得る。
【0054】
ビデオコーダ400は、ITU-T Rec. H.265といった、既定のビデオ符号化技術または標準に従って符号化動作を実行することができる。その動作において、ビデオコーダ400は、入力ビデオシーケンスにおける時間的および空間的冗長性を利用(exploit)する予測符号化動作を含む、種々の圧縮動作を実行することができる。従って、符号化されたビデオデータは、使用されているビデオ符号化技術または標準によって指定されたシンタックスに適合し得る。
【0055】
一つの実施形態において、送信器409は、符号化されたビデオと共に追加データを送信することができる。ソースコーダ403は、符号化ビデオシーケンスの一部として、そうしたデータを含み得る。追加のデータは、時間的/空間的/SNR強調層、冗長画像およびスライスといった他の形式の冗長データ、補足強調情報(Supplementary Enhancement Information、SEI)メッセージ、視覚的ユーザビリティ情報(Visual Usability Information、VUI)パラメータセットフラグメント、などを含み得る。
【0056】
図5は、HEVCおよびJEMにおいて使用されるイントラ予測モードを示す。自然のビデオ(natural video)で提示される任意のエッジ方向をキャプチャするために、方向性(directional)イントラモードの数は、HEVCで使用されるように、33から65に拡張されている。HEVCの上のJEMにおける追加の方向性モードは、図1(b)の点線矢印として示されており、平面モードとDCモードは同じままである。これらのより高密度の方向性イントラ予測モードは、全てのブロックサイズについて、および、ルマ(luma)とクローマ(chroma)両方のイントラ予測について適用される。図5に示すように、奇数イントラ予測モードインデックスに関連する、点線矢印により識別される方向性イントラ予測モードは、奇数イントラ予測モードと呼ばれる。偶数イントラ予測モードインデックスに関連する、実線矢印により識別される方向性イントラ予測モードは、偶数イントラ予測モードと呼ばれる。この文書において、図5における実線または点線の矢印によって示される、方向性イントラ予測モードは、また、角度モード(angular modes)とも呼ばれる。
【0057】
JEMでは、合計67のイントラ予測モードがルマ・イントラ予測のために使用される。イントラモードを符号化するために、隣接ブロックのイントラモードに基づいて、サイズ6の最確モード(most probable mode、MPM)リストが構築される。イントラモードがMPMリストからではない場合、イントラモードが選択されたモードに属するか否かを示すフラグが信号化される。JEM-3.0では、16個の選択モードが存在し、4番目の角度モードごとに一様に選択される。JVET-D0114およびJVET-G0060では、一様に選択されたモードを置き換えるために16個のセカンダリMPMが導出されている。
【0058】
図6は、イントラ方向性モードのために利用されるN個の参照ティア(tiers)を示す。ブロックユニット611、セグメントA 601、セグメントB 602、セグメントC 603、セグメントD 604、セグメントE 605、セグメントF 606、第1参照ティア(reference tier)610、第2参照ティア609、第3参照ティア608、および第4参照ティア607が存在している。
【0059】
HEVCとJEMの両方、並びに、H.264/AVCといったいくつかの他の規格において、現在ブロックを予測するために使用される参照サンプルは、最も近い参照ライン(行または列)に制限されている。複数の参照ラインのイントラ予測に係る方法において、候補の参照ライン(行または列)の数は、イントラ方向性モードについて、1(すなわち最も近い)からNまで増加され、ここで、Nは1以上の整数である。図2では、多重ライン(multiple line)イントラ方向性予測法の概念を示すために、一つの例として4×4予測ユニット(PU)を採用している。イントラ方向性モードは、予測子(predictors)を生成するためにN個の参照ティアのうち1つを任意に選択することができる。言い換えると、予測子p(x,y)は、参照サンプルS1,S2,...,SNのうちの1つから生成される。フラグは、イントラ方向性モードのためにどの参照ティアが選択されるかを示すために信号化される。Nが1として設定される場合、イントラ方向性予測の方法は、JEM 2.0における従来の方法と同じである。図6において、参照ライン610、609、608、および607は、左上の参照サンプルと共に6個のセグメント601、602、603、604、605、および606から構成される。この文書において、参照ティアは、また、参照ラインとも呼ばれる。現在ブロックユニット内の左上の画素の座標は(0,0)であり、そして、第1参照ラインにおける左上の画素は(-1,-1)である。
【0060】
JEMでは、ルマ・コンポーネントについて、イントラ予測サンプル生成のために使用される隣接サンプルは、生成プロセスの前にフィルタリングされる。フィルタリングは、所与のイントラ予測モードおよび変換ブロックサイズによって制御される。イントラ予測モードがDCであり、または、変換ブロックサイズが4×4の場合、隣接するサンプルはフィルタリングされない。所与のイントラ予測モードと垂直モード(または、水平モード)との間の距離が事前に定義された閾値よりも大きい場合に、フィルタリングプロセスはイネーブル(enabled)される。隣接するサンプルフィルタリングのために、[1,2,1]フィルタおよび双線形フィルタが使用される。
【0061】
位置依存イントラ予測結合(position dependent intra prediction combination、PDPC)法は、フィルタリングされていない境界参照サンプルと、フィルタリングされた境界参照サンプルを用いるHEVCスタイルのイントラ予測との組み合わせを呼び出す(invoke)イントラ予測法である。(x,y)に位置する各予測サンプルpred[x][y]は、以下のように計算される。
pred[x][y]=(wL*R-1,y+wT*Rx,-1+wTL*R-1,-1+(64-wL-wT-wTL)*pred[x][y]+32)>>6
(式2-1)
ここで、Rx,-1、R-1,yは、現在サンプル(x,y)の上および左に位置するフィルタリングされていない参照サンプルを、それぞれに、表しており、そして、R-1,-1は、現在ブロックの左上隅に位置するフィルタリングされていない参照サンプルを表している。重み付け(weightings)は、以下のように計算される。
wT=32>>((y<<1)>>shift) (式2-2)
wL=32>>((x<<1)>>shift) (式2-3)
wTL=-(wL>>4)-(wT>>4) (式2-4)
shift=(log2(width)+log2(height)+2)>>2 (式2-5)
【0062】
図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で与えられる。
【0063】
図8は、局所照明補正(Local Illumination Compensation、LIC)ダイアグラム800を示しており、そして、スケーリング係数aおよびオフセットbを使用する、照明変化のための線形モデルに基づいている。そして、各インターモード符号化コーディングユニット(coding unit、CU)に対して適応的にイネーブルまたはディセーブルにされる。
【0064】
CUについてLICを適用する場合、現在CUの隣接するサンプルおよびそれらの対応する参照サンプルを使用することによって、パラメータaおよびbを導出するために、最小二乗誤差法が使用される。より具体的には、図8に示されるように、サブサンプリングされた(2:1サブサンプリング)CUの隣接サンプル、および、参照画像内の対応するサンプル(現在CUまたはサブCUの動き情報によって特定されるもの)が使用される。ICパラメータが導出され、そして、各予測方向について別々に適用される。
【0065】
CUがマージモードで符号化される場合、LICフラグは、マージモードでの動き情報コピーと同様の方法で隣接ブロックからコピーされる。さもなければ、LICフラグは、LICが適用されるか否かを示すために、CUについて信号化される。
【0066】
図9Aは、HEVCで使用されるイントラ予測モード900を示す。HEVCでは、計35のイントラ予測モードが存在しており、そのうち、モード10が水平モード、モード26が垂直モード、モード2、モード18およびモード34が対角モードである。イントラ予測モードは、3個の最も可能性の高いモード(MPM)と32個の残りのモードによって信号化される。
【0067】
図9Bは、VVCの実施形態における、イントラ予測モードを示す。そこでは、モード18が水平モードであり、モード50が垂直モードであり、モード2、モード34およびモード66が対角モードである。モード-1~-10、および、モード67~-76は、広角イントラ予測(Wide-Angle Intra Prediction、WAIP)モードと呼ばれる。
【0068】
位置(x,y)に置かれた予測サンプルpred(x,y)は、イントラ予測モード(DC,プレーナ,角度)およびPDPC式に従った参照サンプルの線形結合を使用して、予測される。
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は、現在のブロックの左上隅に位置する参照サンプルを表している。
【0069】
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プロセスにおける隣接するサンプルの重み付け係数は、この初期重み付け係数と等しいか、または、それ未満であるべきである。
【0070】
平面(planar)モードについてwTL=0であり、一方で、水平モードについてwTL=wTであり、かつ、垂直モードについてwTL=wLである。PDPCの重み付けは、加算とシフトのみを用いて計算できる。pred(x,y)の値は、式(1)を使用して、一段階で計算され得る。
【0071】
ここで、提案される方法は、別々に、または、任意の順序で組み合わせて使用することができる。さらに、方法(または、実施形態)、エンコーダ、およびデコーダそれぞれは、処理回路(例えば、1つ以上のプロセッサ、または1つ以上の集積回路)によって実装されてよい。一つの例において、1つ以上のプロセッサは、非一時的なコンピュータ読取り可能媒体に保管されたプログラムを実行する。以下において、ブロックという用語は、予測ブロック、符号化ブロック、またはコーディングユニット、すなわちCUとして解釈され得る。
【0072】
図10は、例示的な実施形態に従った、簡略化されたフローチャート1000を示す。S10では、図4のエンコーダ400に関して説明したような、エンコーダが、入力画像を獲得し、そして、S11では、各々がヘッダおよびペイロードデータを有するNAL(network abstraction layer)ユニットの生成を含むエンコーディングなどを用いて、それらの画像を符号化する。NALユニットの1つは、パラメータセットを含み、かつ、他のものは、画像について符号化されたサンプルを搬送する。そして、それらの画像のうち、種々のユニットは、互いに独立しているか、または、依存し得る、複数のスライス、スライスセグメントのうち1つ以上に特有であり得る。S12では、NALユニットのビットストリーム単独、または、図3で説明したデコーダ300といった、デコーダについてネットワークに沿った他のデータの供給がある。
【0073】
図13は、フローチャート1300を示しており、そこでは、S30において、図10のS11のように、図11といった、アクセスユニットのデリミター(delimiter)シンタックスが生成される。S31では、pic_typeシンタックス1101に関して、そうしたシンタックスが、対応するデータが符号化によって生成されるか否か、および、もしそうであれば、そのpic_typeシンタックス1101によって何の値が信号化され得るかを決定することによって設定されるか否かの決定がある。例えば、pic_typeシンタックス1101が存在する場合、図12に従った0、1、または2の値を示すか否かが決定されてよく、それによって、1つ以上のslice_type値が、アクセスユニットのデリミターを含むアクセスユニット内の符号化された画像スライス内に存在してよく、かつ、それに応じて、S34において設定され、信号化され得ることを示している。
【0074】
図13のS32では、rap_typeシンタックス1102に関して、対応するデータが符号化によって生成されるか否か、および、もしそうであれば、そのrap_typeシンタックス1102によって何の値が信号化され得るかを決定することによって、そうしたシンタックスが設定されるか否かの決定がある。例えば、rap_typeシンタックス1102が存在する場合、図12Bに従った0、1、または2の値を示すか否かが決定されてよく、それによって、符号化された全てのスライスについてのVCL nuh_unit_type値が、アクセスユニットのデリミターを含むアクセスユニット内の符号化された画像スライス内に存在してよく、かつ、それに応じて、S34において設定され、信号化され得ることを示している。
【0075】
図14のS43では、au_order_cntシンタックス1103に関して、そうしたシンタックスが、対応するデータが符号化によって生成されるか否か、および、もしそうであれば、そのau_order_cntシンタックス1103によって何の値が信号化され得るかを決定することによって、そうしたシンタックスが設定されるか否かの決定がある。例えば、au_order_cntシンタックス1103が存在する場合、隣接するアクセスユニット間の関連するアクセスユニットを識別するアクセスユニットオーダーカウントの値を示し、0から255までの範囲内であり得るか否かが判定されてよく、そうした情報は、それに応じて、S34において設定され、信号化され得る。
【0076】
S31、S32、およびS33は、図13に示すように、順番に、または並列に実行されてよく、そして、それらのS31、S32、およびS33のうち1つ以上での決定の結果に応じて、上記の情報は、S34で指定されて、例示的な実施形態に従って、図11のaccess_unit_delimiter_rbspシンタックス1100の可能なシンタックス要素に関する1つ以上のNALアクセスユニットの一部として設定され得る。
【0077】
さらに、図10において、NALユニットの1つ以上が、図11に関して説明されたデータ、および、ここにおいて説明された種々の情報を示す可能性のあるアクセスユニットデリミターといった他の関連する図と共にS13において符号化され、かつ、受信され、そして、S14において、データが解析され、かつ、復号されて、ここにおいて説明されるようにS14で1つ以上の出力画像を結果として生じる。
【0078】
図11は、例示的な実施形態に従った、ビデオフレームの開始に関して信号化するためのアクセスユニットのデリミターについて、アクセスユニットデリミター・ローバイト・シーケンスペイロード(raw byte sequence payload、rbsp)シンタックステーブル1100を示し、そして、図12は、slice_type値を示すテーブル1200を表している。
【0079】
pic_typeシンタックス1101は、アクセスユニットデリミターNALユニットを含むアクセスユニット内の符号化画像の全てのスライスに対するslice_type値が、pic_typeの与えられた値に対して表1100にリストされたセットのメンバーであることを示す。pic_typeの値は、この明細書のこのバージョンに準拠するビットストリームにおいて0、1、または2に等しい。例示的な実施形態に従った、図12の表1200を参照すると、そこでは、pic_type値の0は、slice_type値I(イントラ予測のみを伴うスライス)の符号化画像中の存在を示し、pic_type値の1は、P(1つのIまたはPスライスからのインター予測を伴うスライス)およびIのいずれかのslice_type値の符号化画像中の存在を示し、pic_type値の2は、B(2つのIまたはPスライスからのインター予測を伴うスライス)、P、およびIのいずれかのslice_type値の符号化画像中の存在を示す。pic_type値の他の値は、ITU T|ISO/IECが将来使用するためにリザーブされている。この明細書のこのバージョンに準拠するデコーダは、pic_typeのリザーブされた値を無視する。
【0080】
図14は、フローチャート1400を示す。そこでは、S40において、図10のS13のように、アクセスユニットデリミターシンタックスが、図11のように、獲得され、解析される。S41では、pic_typeシンタックス1101に関して、そうしたシンタックスが存在するか否か、そして存在する場合、そのpic_typeシンタックス1101によって何の値が信号化され得るかの決定がある。例えば、pic_typeシンタックス1101が存在する場合、図12に従った0、1、または2の値を示すか否かが決定されてよく、それによって、1つ以上のslice_type値が、アクセスユニットのデリミターを含むアクセスユニット内の符号化された画像スライス中に存在し得ることを示している。
【0081】
実施形態に従った、NALユニットは、NALユニットのタイプのデータおよびペイロードデータを示すバイトを含む符号化ビデオデータを含んでよく、そして、上述のエンコーダ400といったエンコーダによって生成され得ることが理解されよう。ビデオ符号化層(video coding layer、VCL)NACユニットは、例えば、シーケンスパラメータセット(SPS)を参照して、画像パラメータセット(PPS)を参照する識別子を含むことができ、そして、キャリアチャネル毎の種々の配信スキームのために、帯域内及び/又は帯域外のパラメータセットとして送信することができる。
【0082】
また、アクセスユニットは、各アクセスユニットのデコーディングが復号された画像を生じ得るNALユニットのセットを含み得ることも理解されるであろう。上述のように、アクセスユニットのデリミターをプレフィックス(prefixing)することが達成されてもよく、そして、各アクセスユニットに係るVCL NALユニットのセットは、ビデオ画像のサンプルを表すスライスまたはスライスデータパーティションを含む一次(primary)符号化画像を含んでよい。
【0083】
rap_typeシンタックス1102は、アクセスユニットデリミターNALユニットを含むアクセスユニット内の符号化された画像の全てのスライスに対するVCL nuh_unit_type(NALユニットヘッダ「nuh」)値が、rap_typeに係る所与の値について表1200Bにリストされたセットのメンバーであることを指定する。rap_typeの値は、この明細書のこのバージョンに準拠するビットストリームでは0、1、または2に等しい。例示的な実施形態に従った図12Bの表1200Bを参照すると、そこで、rap_type値の0は、TRAIL_NUT(後続NALユニットヘッダ(NUT))、STSA_NUT(段階的時間的サブレイヤアクセス(stepwise temporal sublayer access、STSA)NUT)、RASL_NU(ランダムアクセススキップ先行画像(random access skipped leading picture、RASL)NUT)、RADL_NUT(ランダムアクセス復号可能画像(random access decodable picture、RADL)NUT)のいずれかに係るnuh_layer_id値の符号化画像における存在を示し得る。かつ、そこで、rap_type値の1は、IDR_W_RADL(瞬間的デコーダリフレッシュ(instantaneous decoder refresh、IDR)W RADL(先行画像を有し得る))、IDR_N_LP(先行画像を有さない)、CRA_NUT(クリーンランダムアクセスポイント(clean random access point、CRA)NUT)、GDR_NUT(段階的デコーダリフレッシュ(gradual decoder refresh、GDR)NUT)のいずれかに係る符号化画像における存在を示し得る。かつ、そこで、rap_type値の2は、全てのVCL nuh_unit_type_valuesに係る符号化画像における存在を示し得る。rap_typeの他の値は、ITU T|ISO/IECによる将来の使用のためにリザーブされている。この明細書のこのバージョンに準拠するデコーダは、rap_typeのリザーブされた値を無視する。rap_typeは、アクセスユニット内の符号化画像が、非IRAP(イントラランダムアクセスポイント)NALユニットのみ、IRAP NALユニットのみ、または、IRAPと非IRAPの両方を含むか否かを指定することができる。rap_typeの値は、ランダムアクセスポイントがアクセスユニット内に存在するかを示すために使用することができる。HEVCにおける画像のクラスは、例示的な実施形態に従って、IRAPピクチャ(時間的なサブレイヤ0に属し、かつ、参照データのために他の画像コンテンツを使用することなく符号化され得るもの)、先行(leading)画像(復号化順でIRAPピクチャの後に続き、出力順で先行する)、および、後続(trailing)画像(復号化順と出力順の両方でのIRAPピクチャの後に続くもの)を含んでよい。
【0084】
図14のS42では、rap_typeシンタックス1102に関して、そうしたシンタックスが存在するか否か、そして存在する場合には、そのrap_typeシンタックス1102によって何の値が信号化され得るかの決定がある。例えば、rap_typeシンタックス1102が存在する場合、図12Bに従った0、1、または2の値を示すか否かが決定されてよく、それによって、符号化された全てのスライスについてVCL nuh_unit_type値が、アクセスユニットのデリミターを含むアクセスユニット内の符号化された画像スライスに存在し得ることを示している。
【0085】
例示的な実施形態に従って、アクセスユニットの境界を示すためにAUDに信号を送る(signal)ことを義務付けることができる。AUDでは、シンタックス要素pic_typeは、アクセスユニットデリミターNALユニットを含むアクセスユニット内の符号化された画像のスライス内に存在するslice_type値を示すように信号化されてよく、そして、pic_typeは、AUが他のAUから独立しているか、または、依存しているかを識別するのに有用である。
【0086】
さらに、au_order_cntシンタックス1103は、隣接するアクセスユニット間で関連するアクセスユニットを識別するアクセスユニットオーダーカウントの値を指定する。au_order_cntの値は、例示的な実施形態に従って、0から255までの範囲である。アクセスユニットオーダーカウント値は、特に、1つ以上のAUDが失われた場合に、アクセスユニットの境界を識別するために使用され得る。
【0087】
図14のS43では、au_order_cntシンタックス1103に関して、そうしたシンタックスが存在するか否か、そして存在する場合、そのau_order_cntシンタックス1103によって何の値が信号化され得るかの決定がある。例えば、au_order_cntシンタックス1103が存在する場合、隣接するアクセスユニット間の関連するアクセスユニットを識別するアクセスユニットオーダーカウントの値を示すか否かが決定されてよく、そして、0から255までの範囲内であってよい。
【0088】
S41、S42、およびS43は、図14に示されるように、順番に、または、並列に実行されてよく、そして、これらのS41、S42、およびS43のうち1つ以上での決定の結果に応じて、上記の情報は、例示的な実施形態に従って、図11のaccess_unit_delimiter_rbspシンタックス1100の可能なシンタックス要素に関して、S44で指定され、かつ、信号化され得る。
【0089】
ここにおいて説明されるように、例示的な実施形態に従って、ここにおいて記載されている値の個々の間の所定のデルタ値(差異)を決定または保管するように構成された、バッファ、算術論理ユニット、メモリ命令といった、1つ以上のハードウェアプロセッサおよびコンピュータコンポーネントが存在し得る。
【0090】
従って、ここにおいて説明される例示的な実施形態によって、上述の技術的問題は、これらの技術的解決策の1つ以上により有利に改善され得る。すなわち、実施形態に従って、1つ以上の異なる技術的問題に対処するために、本開示は、新規な技術的態様を説明する。そこでは、アクセスユニットデリミターNALユニットを含むアクセスユニット内の符号化された画像のスライス内にどのslice_type値が存在するかを示すように、アクセスユニットデリミター(AUD)が、有利に信号化され得る。pic_typeは、AUが外部AUから独立しているか、または、依存しているかを識別するのに役立ち得る。さらに、そうした新規なシンタックス要素信号化は、例示的な実施形態に従って、ランダムアクセスAUおよびAU境界検出のロバスト性の指標において、それぞれに、有利であり、そして、従って、例えば、改善された精度および効率にとって有利であることが主張される。
【0091】
上述の技術は、コンピュータで読取り可能な命令を用いてコンピュータソフトウェアとして実装することができ、1つ以上のコンピュータで読取り可能な媒体に、または、1つ以上のハードウェアプロセッサによって物理的に保管することができる。例えば、図12は、開示される技術的事項の特定の実施形態を実施するのに適したコンピュータシステム1200を示す。
【0092】
コンピュータソフトウェアは、アセンブリ、コンパイル、リンク、もしくは、同様のメカニズムの対象となり得る任意の適切な機械コードまたはコンピュータ言語を用いて符号化することができ、コンピュータ中央処理ユニット、グラフィックス処理ユニットなどによって、直接的に、または、解釈(interpretation)、マイクロコード実行などを通して、実行可能な命令を含むコードを作成することができる。
【0093】
命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーム装置、モノのインターネット、等を含む種々のタイプのコンピュータ、または、そのコンポーネント上で実行することができる。
【0094】
コンピュータシステム1500のための図15に示されるコンポーネントは、本質的に例示的なものであり、本開示の実施形態を実装するコンピュータソフトウェアの使用範囲または機能性に関する制限を示唆することを意図するものではない。また、コンポーネントの構成は、コンピュータシステム1500の例示的な実施形態に示されるコンポーネントの任意の1つ、または、組み合わせに関するいかなる従属性または要件も有するものとして解釈されてはならない。
【0095】
コンピュータシステム1500は、特定のヒューマンインターフェイス入力デバイスを含んでよい。そうしたヒューマンインターフェイス入力装置は、例えば、触覚入力(例えば、キーストローク、スワイプ、データグローブの動き)、音声入力(例えば、音声、拍手)、視覚入力(例えば、ジェスチャ)、嗅覚入力(図示なし)を介して、1人以上の人間ユーザによる入力に応答することができる。また、ヒューマンインターフェイス装置は、オーディオ(例えば、スピーチ、音楽、周囲の音)、画像(例えば、走査画像、静止画像カメラから得られる写真画像)、ビデオ(例えば、2次元ビデオ、立体画像を含む3次元ビデオ)といった、人間による意識的入力に必ずしも直接関係しない特定の媒体をキャプチャするために使用することができる。
【0096】
入力ヒューマンインターフェイス装置は、キーボード1501、マウス1502、トラックパッド1503、タッチスクリーン1510、ジョイスティック1505、マイクロホン1506、スキャナ1508、カメラ1507のうちの1つ以上を含んでよい。
【0097】
コンピュータシステム1500は、また、所定のヒューマンインターフェイス出力デバイスを含んでよい。そうしたヒューマンインターフェイス出力装置は、例えば、触覚出力、音、光、および嗅覚/味覚を通して、1人以上の人間ユーザの感覚を刺激することができる。そうしたヒューマンインターフェイス出力装置は、触覚出力装置(例えば、タッチスクリーン1510またはジョイスティック1505による触覚フィードバック)、オーディオ出力装置(例えば、スピーカー1509、ヘッドフォン(図示なし)など)、視覚出力装置(各々がタッチスクリーン入力能力を有するか、または、有さないスクリーン1510、LCDスクリーン、プラズマスクリーン、OLEDスクリーンなど、触覚フィードバック能力を有するまたは有さないスクリーン -これらのうちのいくつかは、立体画像出力といった手段を介して2次元の視覚出力または3次元以上の視覚出力を出力することができる、仮想現実メガネ(図示なし)、ホログラフィックディスプレイ、およびスモークタンク(図示なし))、および、プリンタ(図示なし)を含んでよい。
【0098】
コンピュータシステム1500は、また、人間がアクセス可能な記憶装置、および、それらの関連媒体を含むことができる。CD/DVD1511を伴うCD/DVD ROM/RW1520または類似の媒体を含む光媒体、サムドライブ(thumb-drive)1522、リムーバブルハードドライブまたはソリッドステートドライブ1523、テープおよびフロッピー(登録商標)ディスク(図示なし)といったレ従来の磁気媒体、セキュリティドングル(図示なし)といった特殊化されたROM/ASIC/PLDベースの装置など、といったものである。
【0099】
当業者であれば、また、現在開示されている技術的事項に関連して使用される用語「コンピュータで読取り可能な媒体」は、伝送媒体、搬送波、または他の過渡信号を包含しないことを理解すべきである。
【0100】
コンピュータシステム1500は、また、1つ以上の通信ネットワーク1598へのインターフェイス1599を含むことができる。ネットワーク1598は、例えば、無線、有線、光であり得る。ネットワーク1598は、さらに、ローカル、ワイドエリア、メトロポリタン、車両および工業、リアルタイム、遅延耐性(delay-tolerant)、等であり得る。ネットワーク1598の例は、ローカルエリアネットワークを含む。イーサネット、無線LAN、GSM、3G、4G、5G、LTE、等を含むセルラーネットワーク、ケーブルTVを含むTV有線または無線ワイドエリアデジタルネットワーク、衛星TV、地上放送TV、CANBusを含む車両および工業、などといったものである。所定のネットワーク1598は、一般的に、特定の汎用データポートまたはペリフェラルバス(1550および1551)に接続される外部ネットワークインターフェイスアダプタを必要とする。例えば、コンピュータシステム1500のUSBポートといったものであり、その他は、一般的に、後述するシステムバスに接続されることにより、コンピュータシステム1500のコアへ(例えば、イーサネットインターフェイスがPCコンピュータシステムへ、または、セルラーネットワークインターフェイスがスマートフォンコンピュータシステムへ)統合される。これらのネットワーク1598のいずれかを使用して、コンピュータシステム1500は、他のエンティティと通信することができる。そうした通信は、単指向性(uni-directional)、受信のみ(例えば、放送テレビ)、単指向性送信専用(例えば、所定のCANbusデバイスへのCANbus)、または、双指向性、例えば、ローカルまたはワイドエリアデジタルネットワークを使用する他のコンピュータシステムに対して、であり得る。所定のプロトコルおよびプロトコルスタックは、上述のように、それらのネットワークおよびネットワークインターフェイスそれぞれで使用することができる。
【0101】
前述のヒューマンインターフェイス装置、人間がアクセス可能なストレージ装置、および、ネットワークインターフェイスは、コンピュータシステム1500のコア1540に取り付けることができる。
【0102】
コア1540は、1つ以上の中央処理装置1541、グラフィックス処理装置1542、グラフィックスアダプタ1517、フィールドプログラマブルゲートエリア(FPGA)1543の形態における特殊化されたプログラマブル処理装置、所定のタスク1544のためのハードウェアアクセラレータ、などを含んでよい。これらの装置は、読出し専用メモリ(ROM)1545、ランダムアクセスメモリ1546、内部非ユーザアクセス可能ハードドライブといった内部大容量ストレージ装置、SSD等1547と共に、システムバス1548を介して接続することができる。いくつかのコンピュータシステムにおいて、システムバス1548は、追加のCPU、GPU、などによる拡張を可能にするために、1つ以上の物理的プラグの形態においてアクセス可能である。ペリフェラル装置は、コアのシステムバス1548に直接的に、または、ペリフェラルバス1551を介して取り付けることができる。ペリフェラルバスのアーキテクチャは、PCI、US、Bなどを含む。
【0103】
CPU1541、GPU1542、FPGA1543、およびアクセラレータ1544は、組み合わせて、上述のコンピュータコードを構成し得る所定の命令を実行することができる。そのコンピュータコードは、ROM1545またはRAM1546に保管することができる。移行データは、また、RAM1546に保管することができ、永久データは、例えば、内部大容量ストレージ装置1547に保管することができる。1つ以上のCPU1541、GPU1542、大容量ストレージ装置1547、ROM1545、RAM1546、などと密接に関連付けることができるキャッシュメモリを使用することによって、メモリデバイスのいずれかへの高速記憶および検索を可能にすることができる。
【0104】
コンピュータで読取り可能な媒体は、種々のコンピュータ実装された動作を実行するためのコンピュータコードをその上に有することができる。媒体およびコンピュータコードは、本開示の目的のために特別に設計および構築されたものであってよく、または、それらは、コンピュータソフトウェア技術に熟練した者について周知であり、かつ、入手可能な種類のものであってよい。
【0105】
一例として、限定するものではなく、アーキテクチャ1500、具体的にはコア1540を有するコンピュータシステムは、1つ以上の有形のコンピュータ可読媒体に具現化されたソフトウェアを実行するプロセッサ(CPU、GPU、FPGA、アクセラレータなどを含む)の結果として機能性を提供することができる。そうしたコンピュータで読取り可能な媒体は、コア内部大容量ストレージ装置1547またはROM1545といった非一時的な性質のコア1540の特定の記憶装置と同様に、上述のようなユーザがアクセス可能な大容量ストレージ装置と関連する媒体であってよい。本開示の様々な実施形態を実装するソフトウェアは、そうした装置に保管され、コア1540によって実行され得る。コンピュータで読取り可能な媒体は、特定のニーズに応じて、1つ以上のメモリデバイスまたはチップを含むことができる。ソフトウェアは、RAM1546に保管されたデータ構造を定義し、ソフトウェアによって定義されたプロセスに従って、そうしたデータ構造を修正することを含む、ここにおいて説明された特定のプロセスまたは特定の部分を、コア1540、特にその中のプロセッサ(CPU、GPU、FPGAなどを含む)に実行させることができる。加えて、または、代替として、コンピュータシステムは、回路(例えば、アクセラレータ1544)内に配線された、または、その他の方法で具現化された論理の結果として、機能性を提供することができ、この回路は、ここにおいて説明される特定のプロセス、または、特定のプロセスの特定の部分を実行するために、ソフトウェアの代わりに、または、ソフトウェアと共に動作することができる。ソフトウェアへの参照は、論理を含み、または、必要に応じて、その逆も同様である。コンピュータで読取り可能な媒体への参照は、実行のためのソフトウェアを保管する回路、実行のためのロジックを具体化する回路、または、適切な場合には、その両方を含むことができる。本開示は、ハードウェアおよびソフトウェアの任意の適切な組み合わせを包含する。
【0106】
本開示は、いくつかの例示的な実施形態を説明してきたが、変更、置換、および種々の代替等価物が存在し、それらは、本開示の範囲内にある。従って、当業者であれば、ここにおいて明示的に示されておらず、または、説明されていないが、本開示の原理を具体化し、従って、本開示の精神および範囲内にある多くのシステムおよび方法を考案することができることが理解されるだろう。
図1
図2
図3
図4
図5
図6
図7
図8
図9A
図9B
図10
図11
図12A
図12B
図13
図14
図15