(57)【要約】  符号化ビデオシーケンスを復号する方法は、第1のタイルレイアウトによって規定される第1のタイル境界と、第2のタイルレイアウトによって規定される第2のタイル境界とを含む少なくとも1つのタイルを復号するステップを含み、符号化ビデオシーケンスは、少なくとも1つの第1の予測メカニズムが第1のタイル境界を横切って利用可能であり、少なくとも1つの第1の予測メカニズムが第2のタイル境界を横切って利用不可能であることを示す。
2021521752.tif 000002
【特許請求の範囲】
【請求項１】
デコーダが実行する、符号化ビデオシーケンスを復号する方法であって、
前記デコーダが、第1のタイルレイアウトによって規定される第1のタイル境界と、第2のタイルレイアウトによって規定される第2のタイル境界とを含む少なくとも1つのタイルを復号するステップを含み、
前記符号化ビデオシーケンスは、少なくとも1つの第1の予測メカニズムが前記第1のタイル境界を横切って利用可能であり、前記少なくとも1つの第1の予測メカニズムが前記第2のタイル境界を横切って利用不可能であることを示す、方法。
【請求項２】
前記第1のタイルレイアウトは、並列処理主導のタイルレイアウトを含み、
前記第2のタイルレイアウトは、アプリケーション主導のタイルレイアウトを含む、請求項１に記載の方法。
【請求項３】
前記符号化ビデオシーケンスは、前記少なくとも1つの第2の予測メカニズムが前記第1のタイル境界及び前記第2のタイル境界を横切って利用可能であることを示す、請求項１又は２に記載の方法。
【請求項４】
前記第1のタイルレイアウトは、前記符号化ビデオシーケンスの第1のシンタックス構造で記述され、
前記第2のタイルレイアウトは、前記符号化ビデオシーケンスの第2のシンタックス構造で記述され、
前記第1のシンタックス構造は前記第2のシンタックス構造と異なる、請求項１乃至３のうちいずれか１項に記載の方法。
【請求項５】
前記第1のシンタックス構造は、前記第2のシンタックス構造よりもハイレベルのシンタックス構造である、請求項４に記載の方法。
【請求項６】
前記第1のシンタックス構造は、シーケンスパラメータセットを含み、
前記第2のシンタックス構造は、ピクチャパラメータセットを含む、請求項５に記載の方法。
【請求項７】
前記第1のタイルレイアウト及び前記第2のタイルレイアウトは、シーケンスパラメータセット、ピクチャパラメータセット、スライスヘッダ、ピクチャヘッダ又はグループオブピクチャのヘッダのうち少なくとも1つに記述される、請求項１乃至６のうちいずれか１項に記載の方法。
【請求項８】
前記少なくとも1つの第1の予測メカニズムは、シンタックス予測、コンテキスト適応バイナリ算術符号化リセット、イントラ予測、ピクチャ内参照ブロック予測、イントラブロックコピー、動きベクトル予測又は動き補償予測のうち少なくとも1つを含む、請求項１乃至７のうちいずれか１項に記載の方法。
【請求項９】
前記第1のタイルレイアウトの記述は、前記少なくとも1つの第1の予測メカニズムが前記第1のタイル境界を横切って利用可能であることを示すシンタックスエレメントを含む、請求項１乃至８のうちいずれか１項に記載の方法。
【請求項１０】
前記第2のタイルレイアウトの記述は、前記少なくとも1つの第1の予測メカニズムが前記第2のタイル境界を横切って利用不可能であることを示すシンタックスエレメントを含む、請求項１乃至９のうちいずれか１項に記載の方法。
【請求項１１】
符号化ビデオシーケンスを復号するデバイスであって、
第1のタイルレイアウトによって規定される第1のタイル境界と、第2のタイルレイアウトによって規定される第2のタイル境界とを含む少なくとも1つのタイルを復号するように構成された復号部を含み、
前記符号化ビデオシーケンスは、少なくとも1つの第1の予測メカニズムが前記第1のタイル境界を横切って利用可能であり、前記少なくとも1つの第1の予測メカニズムが前記第2のタイル境界を横切って利用不可能であることを示す、デバイス。
【請求項１２】
前記第1のタイルレイアウトは、並列処理主導のタイルレイアウトを含み、
前記第2のタイルレイアウトは、アプリケーション主導のタイルレイアウトを含む、請求項１１に記載のデバイス。
【請求項１３】
前記符号化ビデオシーケンスは、前記少なくとも1つの第2の予測メカニズムが前記第1のタイル境界及び前記第2のタイル境界を横切って利用可能であることを示す、請求項１１又は１２に記載のデバイス。
【請求項１４】
前記第1のタイルレイアウトは、前記符号化ビデオシーケンスの第1のシンタックス構造で記述され、
前記第2のタイルレイアウトは、前記符号化ビデオシーケンスの第2のシンタックス構造で記述され、
前記第1のシンタックス構造は前記第2のシンタックス構造と異なる、請求項１１乃至１３のうちいずれか１項に記載のデバイス。
【請求項１５】
前記第1のシンタックス構造は、前記第2のシンタックス構造よりもハイレベルのシンタックス構造である、請求項１４に記載のデバイス。
【請求項１６】
前記第1のシンタックス構造は、シーケンスパラメータセットを含み、
前記第2のシンタックス構造は、ピクチャパラメータセットを含む、請求項１５に記載のデバイス。
【請求項１７】
前記少なくとも1つの第1の予測メカニズムは、シンタックス予測、コンテキスト適応バイナリ算術符号化リセット、イントラ予測、ピクチャ内参照ブロック予測、イントラブロックコピー、動きベクトル予測又は動き補償予測のうち少なくとも1つを含む、請求項１１乃至１６のうちいずれか１項に記載のデバイス。
【請求項１８】
前記第1のタイルレイアウトの記述は、前記少なくとも1つの第1の予測メカニズムが前記第1のタイル境界を横切って利用可能であることを示すシンタックスエレメントを含む、請求項１１乃至１７のうちいずれか１項に記載のデバイス。
【請求項１９】
前記第2のタイルレイアウトの記述は、前記少なくとも1つの第1の予測メカニズムが前記第2のタイル境界を横切って利用不可能であることを示すシンタックスエレメントを含む、請求項１１乃至１８のうちいずれか１項に記載のデバイス。
【請求項２０】
符号化ビデオシーケンスを復号するデバイスの1つ以上のプロセッサによって実行されると、前記1つ以上のプロセッサに、
第1のタイルレイアウトによって規定される第1のタイル境界と、第2のタイルレイアウトによって規定される第2のタイル境界とを含む少なくとも1つのタイルを復号させ、
前記符号化ビデオシーケンスは、少なくとも1つの第1の予測メカニズムが前記第1のタイル境界を横切って利用可能であり、前記少なくとも1つの第1の予測メカニズムが前記第2のタイル境界を横切って利用不可能であることを示す、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
［関連出願への相互参照］
本願は、2018年7月16日に米国特許商標庁に出願された米国特許出願第62/698,534号に対する35U.S.C.§119による主張を行う。この出願の全内容が参照によって本明細書に組み込まれる。
【０００２】
［技術分野］
開示の対象物は、ビデオ符号化及び復号に関し、より具体的には、複数の重複するタイルのセットの(同時)使用に関する。1つのタイルのセットは、例えば、並列符号化をサポートするように設計されてもよく、他のものは、例えば、立方体投影の表面のような360°のビデオ表面をサポートするピクチャ分割を行うように設計されてもよい。タイルのセットは、タイル境界を横切るピクチャ内及びピクチャ間予測メカニズムの中断に関して異なる特性を有してもよい。
【背景技術】
【０００３】
動き補償を有するインターピクチャ予測を使用したビデオ符号化及び復号は数十年間も知られている。非圧縮ディジタルビデオは、一連のピクチャで構成されることができ、各ピクチャは、例えば、1920×1080の輝度サンプル及び関連する色差サンプルの空間次元を有する。一連のピクチャは、例えば、毎秒60ピクチャ又は60Hzの固定又は可変のピクチャレート(非公式には、フレームレートとしても知られている)を有することができる。非圧縮ビデオは、かなりのビットレート要件を有する。例えば、サンプル当たり8ビットの1080p60  4:2:0ビデオ(60Hzのフレームレートの1920×1080の輝度サンプル解像度)は、1.5Gbit/sに近い帯域幅を必要とする。1時間のこのようなビデオは、600Gバイトを超える記憶空間を必要とする。
【０００４】
ビデオ符号化及び復号の1つの目的は、圧縮を通じて入力ビデオ信号の冗長性を低減できることである。圧縮は、場合によっては2桁以上も上記の帯域幅又は記憶空間の要件を低減するのに役立つことができる。可逆圧縮及び不可逆圧縮の双方並びにこれらの組み合わせを使用することができる。可逆圧縮とは、元の信号の正確なコピーが圧縮された元の信号から復元できる技術を示す。不可逆圧縮を使用する場合、復元された信号は、元の信号と同一ではない可能性があるが、元の信号と復元された信号との間の歪みは、復元された信号を目的のアプリケーションにとって有用にするほど十分に小さい。ビデオの場合、不可逆圧縮が広く使用されている。許容される歪みの量はアプリケーションに依存する。例えば、特定の消費者のストリーミングアプリケーションのユーザは、テレビ配信アプリケーションのユーザよりも高い歪みを許容する可能性がある。達成可能な圧縮比は、より高い許容可能な歪み/許容される歪みがより高い圧縮比をもたらすことができるということを反映できる。
【０００５】
ビデオエンコーダ及びデコーダは、例えば、動き補償、変換、量子化及びエントロピー符号化を含むいくつかの広いカテゴリからの技術を利用でき、これらのうちいくつかを以下に紹介する。
【０００６】
タイルは、符号化ビデオビットストリームを分割するのを助ける、特定のビデオコーデックで利用可能ないくつかのメカニズムの1つである。タイルは、ピクチャの矩形領域とすることができる。ブロック、マクロブロックとしても知られる符号化ユニット(CU,  coding  unit)の走査順は、タイルにローカルであり、左上から右へ、次いで、上から下へとすることができる。ピクチャは複数のタイルに分割されることができ、各CUがちょうど1つのタイルの一部とすることができる。タイルの外部からの情報の予測は制限されることがあり、ビデオ圧縮技術又は標準でハードコードされる。例えば、H.265では、(独立の)タイルは、タイル内部のCUの復元のために同じピクチャの外部のCUからのデータを使用しないが、復号順に前のピクチャからの動き補償されたサンプルデータを使用してもよい。動き制限タイル(motion  constraint  tile)はそのデータを使用することすらせず、これはH.263の矩形スライスに相当する。タイルは、各プロセッサ又はコアが、符号化されるピクチャの一部のみに注意を集中させることを可能にすることによって、並列符号化(及び復号)を可能にするために導入された。この場合、他のタイルを担うプロセッサへの通信は、最終的なビットストリーム生成処理を除き、必要とされない。
【０００７】
他のビットストリーム分割ツールは、スライスとして知られている。スライスは、走査順の符号化されたCUの集合である。走査順は、全体のピクチャ(タイルが使用されていない場合)又はタイル内のローカルのいずれかにすることができる。特定のビデオ圧縮技術は、タイルとスライスとの間の相互作用に対して特定の制限を課している。スライスの主な目的は、最大伝送ユニット(MTU,  Maximum  Transfer  Unit)サイズの整合であり、たとえ符号化されたピクチャが複数のパケットにまたがることがあるとしても、スライスを単一のパケットに入れることができるように、ピクチャの独立復号可能な部分が1つより多くのMTUにまたがることがないことを確保することである。
【０００８】
タイルとスライスとの間の相互作用は、例えば、H.265の標準化プロセスの間に研究されてきた。
【発明の概要】
【０００９】
一実施形態では、符号化ビデオシーケンスを復号する方法が提供され、第1のタイルレイアウトによって規定される第1のタイル境界と、第2のタイルレイアウトによって規定される第2のタイル境界とを含む少なくとも1つのタイルを復号するステップを含み、符号化ビデオシーケンスは、少なくとも1つの第1の予測メカニズムが第1のタイル境界を横切って利用可能であり、少なくとも1つの第1の予測メカニズムが第2のタイル境界を横切って利用不可能であることを示す。
【００１０】
一実施形態では、符号化ビデオシーケンスを復号するデバイスが提供され、当該デバイスは、プログラムコードを記憶するように構成された少なくとも1つのメモリと、プログラムコードを読み取り、プログラムコードによって命令される通りに動作するように構成された少なくとも1つのプロセッサとを含み、当該プログラムコードは、第1のタイルレイアウトによって規定される第1のタイル境界と、第2のタイルレイアウトによって規定される第2のタイル境界とを含む少なくとも1つのタイルを復号する復号コードを含み、符号化ビデオシーケンスは、少なくとも1つの第1の予測メカニズムが第1のタイル境界を横切って利用可能であり、少なくとも1つの第1の予測メカニズムが第2のタイル境界を横切って利用不可能であることを示す。
【００１１】
一実施形態では、命令を記憶した非一時的なコンピュータ読み取り可能媒体が提供され、当該命令は、符号化ビデオシーケンスを復号するデバイスの1つ以上のプロセッサによって実行されると、1つ以上のプロセッサに、第1のタイルレイアウトによって規定される第1のタイル境界と、第2のタイルレイアウトによって規定される第2のタイル境界とを含む少なくとも1つのタイルを復号させ、符号化ビデオシーケンスは、少なくとも1つの第1の予測メカニズムが第1のタイル境界を横切って利用可能であり、少なくとも1つの第1の予測メカニズムが第2のタイル境界を横切って利用不可能であることを示す。
【図面の簡単な説明】
【００１２】
開示の対象物の更なる特徴、性質及び様々な利点は、以下の詳細な説明及び添付の図面からより明らかになる。
【００１３】
【図１】一実施形態による通信システムの簡略化したブロック図の概略図である。
【００１４】
【図２】ストリーミング環境におけるビデオエンコーダ及びデコーダの配置の図である。
【００１５】
【図３】本開示の一実施形態によるビデオデコーダの機能ブロック図である。
【００１６】
【図４】本開示の一実施形態によるビデオエンコーダの機能ブロック図である。
【００１７】
【図５】本開示の一実施形態による柔軟なタイルレイアウトの一例の図である。
【００１８】
【図６】本開示の一実施形態による階層的なタイルレイアウトの一例の図である。
【００１９】
【図７】本開示の一実施形態による符号化ビデオストリームを復号する例示的な処理のフローチャートである。
【００２０】
【図８】一実施形態によるコンピュータシステムの図である。
【発明を実施するための形態】
【００２１】
図１は、本開示の一実施形態による通信システム(100)の簡略化したブロック図を示す。通信システム(100)は、ネットワーク(150)を介して相互接続された少なくとも2つの端末 (110-120)を含んでもよい。データの双方向伝送のために、第1の端末(110)は、ネットワーク(150)を介して他の端末(120)に送信するためにローカル位置にあるビデオデータを符号化してもよい。第2の端末(120)は、ネットワーク(150)から他の端末の符号化ビデオデータを受信し、符号化ビデオデータを復号し、復元されたビデオデータを表示してもよい。一方向データ伝送は、メディア提供アプリケーション等において一般的でもよい。
【００２２】
図１は、例えば、テレビ会議中に発生し得る符号化ビデオデータの双方向伝送をサポートするように提供された第2の対の端末(130,140)を示す。データの双方向伝送のために、各端末(130,140)は、ネットワーク(150)を介して他の端末に送信するために、ローカル位置でキャプチャされたビデオデータを符号化してもよい。また、各端末(130,140)は、他の端末デバイスによって送信された符号化ビデオデータを受信してもよく、符号化ビデオデータを復号してもよく、ローカル表示デバイスにおいて復元されたビデオデータを表示してもよい。
【００２３】
図１では、端末(110-140)は、サーバ、パーソナルコンピュータ及びスマートフォンとして示されることがあるが、本開示の原理はこれらに限定されない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレイヤ及び/又は専用のテレビ会議機器に適用がある。ネットワーク(150)は、例えば、有線及び/又は無線通信ネットワークを含む、端末(110-140)の間で符号化ビデオデータを伝達するいずれかの数のネットワークを表す。通信ネットワーク(150)は、回線交換チャネル及び/又はパケット交換チャネル内のデータを交換してもよい。代表的なネットワークは、電気通信ネットワーク、ローカルエリアネットワーク、広域ネットワーク及び/又はインターネットを含む。本説明の目的では、ネットワーク(150)のアーキテクチャ及びトポロジは、本明細書において以下に説明しない限り、本開示の動作には重要ではない。
【００２４】
図２は、開示の対象物のアプリケーションの例として、ストリーミング環境におけるビデオエンコーダ及びデコーダの配置を示す。開示の対象物は、例えば、テレビ会議、デジタルTV、デジタルメディア(CD、DVD、メモリスティック等を含む)上の圧縮ビデオの記憶等を含む、他のビデオ可能なアプリケーションにも同様に適用可能である。
【００２５】
ストリーミングシステムはキャプチャサブシステム(213)を含んでもよく、当該キャプチャサブシステム(213)は、例えば、非圧縮ビデオサンプルストリーム(202)を生成するビデオソース(201)(例えば、デジタルカメラ)を含んでもよい。符号化ビデオビットストリームと比較したときに高いデータ量であることを強調する太線として描かれるサンプルストリーム(202)は、カメラ(201)に結合されたエンコーダ(203)によって処理されてもよい。エンコーダ(203)は、以下により詳細に説明するように、開示の対象物の態様を可能にするため或いは実装するために、ハードウェア、ソフトウェア又はこれらの組み合わせを含んでもよい。サンプルストリームと比較したときにより低いデータ量であることを強調するために細線として描かれる符号化ビデオビットストリーム(204)は、将来の使用のためにストリーミングサーバ(205)に記憶されてもよい。1つ以上のストリーミングクライアント(206,208)は、ストリーミングサーバ(205)にアクセスして符号化ビデオビットストリーム(204)のコピー(207,209)を取得してもよい。クライアント(206)はビデオデコーダ(210)を含んでもよく、当該ビデオデコーダ(210)は、符号化ビデオビットストリーム(207)の入力コピーを復号し、ディスプレイ(212)又は他のレンダリングデバイス(図示せず)上にレンダリングできる出力ビデオサンプルストリーム(211)を生成する。いくつかのストリーミングシステムでは、ビデオビットストリーム(204,207,209)は、特定のビデオ符号化/圧縮標準に従って符号化されてもよい。これらの標準の例は、ITU-T勧告H.265を含む。開発中のビデオ符号化標準は、VVC(Versatile  Video  Coding)として非公式に知られている。開示の対象物は、VVCの背景において使用されてもよい。
【００２６】
図３は、本開示の一実施形態によるビデオデコーダ(210)の機能ブロック図でもよい。
【００２７】
受信機(310)は、デコーダ(210)によって復号されるべき1つ以上の符号化ビデオシーケンスを受信してもよく、同一又は他の実施形態では、一度に1つの符号化ビデオシーケンスを受信してもよく、各符号化ビデオシーケンスの復号は、他の符号化ビデオシーケンスとは独立している。符号化ビデオシーケンスは、チャネル(312)から受信されてもよく、当該チャネルは、符号化ビデオデータを記憶する記憶デバイスへのハードウェア/ソフトウェアリンクでもよい。受信機(310)は、符号化ビデオデータを、他のデータ(例えば、符号化オーディオデータ及び/又は補助データストリーム)と共に受信してもよく、これらは、それぞれの使用エンティティ(図示せず)に転送されてもよい。受信機(310)は、符号化ビデオシーケンスを他のデータから分離してもよい。ネットワークジッタを防止するために、バッファメモリ(315)は、受信機(310)とエントロピーデコーダ/パーサ(320)(以下、「パーサ」という)との間に結合されてもよい。受信機(310)が、十分な帯域幅及び制御可能性を有する記憶/転送デバイスから、或いは、アイソクロナスネットワークからデータを受信している場合、バッファメモリ(315)は必要なくてもよく或いは小さくすることができる。インターネットのようなベストエフォート型パケットネットワークでの使用については、バッファメモリ(315)が必要とされてもよく、比較的大きくすることができ、有利には適応的なサイズとすることができる。
【００２８】
ビデオデコーダ(210)は、エントロピー符号化ビデオシーケンスからシンボル(321)を復元するためのパーサ(320)を含んでもよい。これらのシンボルのカテゴリは、デコーダ(210)の動作を管理するために使用される情報を含み、ディスプレイ(212)のようなレンダリングデバイスを制御するための情報を潜在的に含む。当該ディスプレイ(212)は、図３に示されているように、デコーダの一体的な部分ではないが、デコーダに結合されてもよい。レンダリングデバイスの制御情報は、補足エンハンスメント情報(SEI,  Supplemental  Enhancement  Information)(SEIメッセージ)又はビデオユーザビリティ情報(VUI,  Video  Usability  Information)パラメータセットフラグメント(図示せず)の形式でもよい。パーサ(320)は、受信した符号化ビデオシーケンスを解析/エントロピー復号してもよい。符号化ビデオシーケンスの符号化は、ビデオ符号化技術又は標準に従ってもよく、可変長符号化、ハフマン符号化、コンテキスト感度を伴う或いは伴わない算術符号化等を含む当業者に周知の原理に従ってもよい。パーサ(320)は、グループに対応する少なくとも1つのパラメータに基づいて、符号化ビデオシーケンスから、ビデオデコーダ内の画素のサブグループのうち少なくとも1つについてのサブグループパラメータのセットを抽出してもよい。サブグループは、グループオブピクチャ(GOP,  Group  of  Picture)、ピクチャ、タイル、スライス、マクロブロック、符号化ユニット(CU,  Coding  Unit)、ブロック、変換ユニット(TU,  Transformation  Unit)、予測ユニット(PU,  Prediction  Unit)等を含んでもよい。また、エントロピーデコーダ/パーサは、符号化ビデオシーケンスから、変換係数、量子化パラメータ(QP, quantizer  parameter)値、動きベクトル等のような情報を抽出してもよい。
【００２９】
パーサ(320)は、シンボル(321)を生成するために、バッファ(315)から受信したビデオシーケンスに対してエントロピー復号/解析動作を実行してもよい。パーサ(320)は、符号化データを受信し、特定のシンボル(321)を選択的に復号してもよい。さらに、パーサ(320)は、特定のシンボル(321)が、動き補償予測ユニット(353)に提供されるべきか、スケーラ/逆変換ユニット(351)に提供されるべきか、イントラ予測ユニット(352)に提供されるべきか、ループフィルタ(356)に提供されるべきかを決定してもよい。
【００３０】
シンボル(321)の復元には、符号化ビデオピクチャ又はその部分のタイプ(例えば、インターピクチャ及びイントラピクチャ、インターブロック及びイントラブロック)及び他の要因に依存して、複数の異なるユニットが関与してもよい。どのユニットがどのように関与するかは、パーサ(320)によって符号化ビデオシーケンスから解析されたサブグループ制御情報によって制御されてもよい。パーサ(320)と以下の複数ユニットとの間のこのようなサブグループ制御情報の流れは、明確にするために図示されていない。
【００３１】
上記の機能ブロックの他に、デコーダ(210)は、概念的に、以下に説明するような複数の機能ユニットに細分されてもよい。商用的な制約の下で動作する実用的な実装では、これらのユニットの多くは互いに密接に相互作用し、少なくとも部分的に互いに統合されてもよい。しかし、開示の対象物を説明する目的で、以下の機能ユニットに概念的に細分することが適切である。
【００３２】
第1のユニットは、スケーラ/逆変換ユニット(351)である。スケーラ/逆変換ユニット(351)は、パーサ(320)からシンボル(621)として、制御情報(どの変換を使用するべきか、ブロックサイズ、量子化係数、量子化スケーリング行列等を含む)と共に、量子化された変換係数を受信する。スケーラ/逆変換ユニット(351)は、アグリゲータ(355)に入力できるサンプル値を含むブロックを出力してもよい。
【００３３】
場合によっては、スケーラ/逆変換(351)の出力サンプルは、イントラ符号化ブロックに関連してもよく、すなわち、前に復元されたピクチャからの予測情報を使用していないが、カレントピクチャの前に復元された部分からの予測情報を使用できるブロックに関連してもよい。このような予測情報は、イントラピクチャ予測ユニット(352)によって提供されてもよい。場合によっては、イントラピクチャ予測ユニット(352)は、カレントピクチャ(部分的に復元されたもの)(356)から取り出された周囲の既に復元された情報を使用して、復元中のブロックの同じサイズ及び形状のブロックを生成する。場合によっては、アグリゲータ(355)は、サンプル毎に、イントラ予測ユニット(352)が生成した予測情報を、スケーラ/逆変換ユニット(351)によって提供された出力サンプル情報に追加する。
【００３４】
他の場合には、スケーラ/逆変換ユニット(351)の出力サンプルは、インター符号化されて潜在的に動き補償されたブロックに関連してもよい。このような場合、動き補償予測ユニット(353)は、参照ピクチャメモリ(357)にアクセスして、予測に使用されるサンプルを取り出してもよい。ブロックに関連するシンボル(321)に従って、取り出されたサンプルを動き補償した後に、これらのサンプルは、出力サンプル情報を生成するために、アグリゲータ(355)によってスケーラ/逆変換ユニットの出力(この場合には、残差サンプル又は残差信号と呼ばれる)に追加されてもよい。動き補償ユニットに利用可能な、動き補償ユニットが予測サンプルを取り出す参照ピクチャメモリ内のアドレスは、例えば、X、Y及び参照ピクチャ成分を有することができるシンボル(321)の形式で、動きベクトルによって制御されてもよい。また、動き補償は、サブサンプルの正確な動きベクトルが使用されているときに参照ピクチャメモリから取り出されるサンプル値の補間、動きベクトル予測メカニズム等を含んでもよい。
【００３５】
アグリゲータ(355)の出力サンプルは、ループフィルタユニット(356)内の様々なループフィルタリング技術を受けてもよい。ビデオ圧縮技術はループ内フィルタ技術を含んでもよく、当該ループ内フィルタ技術は、符号化ビデオビットストリームに含まれるパラメータによって制御され、パーサ(320)からシンボル(321)としてループフィルタユニット(356)に利用可能にされるが、符号化ピクチャ又は符号化ビデオシーケンスの(復号順に)前の部分の復号の間に取得されたメタ情報に応答する共に、前に復元されてループフィルタリングされたサンプル値にも応答してもよい。
【００３６】
ループフィルタユニット(356)の出力はサンプルストリームでもよく、当該サンプルストリームは、レンダリングデバイス(212)に出力されると共に、将来のインターピクチャ予測に使用するために参照ピクチャメモリ(356)に記憶されてもよい。
【００３７】
特定の符号化ピクチャは、完全に復元されると、将来の予測のための参照ピクチャとして使用されてもよい。符号化ピクチャが完全に復元され、符号化ピクチャが(例えば、パーサ(320)によって)参照ピクチャとして識別されると、カレント参照ピクチャ(656)は参照ピクチャバッファ(357)の一部となってもよく、新たなカレントピクチャメモリが、後続の符号化ピクチャの復元を開始する前に再割り当てされてもよい。
【００３８】
ビデオデコーダ(210)は、ITU-T  Rec.  H.265のような標準において文書化され得る所定のビデオ圧縮技術に従って復号動作を実行してもよい。符号化ビデオシーケンスがビデオ圧縮技術の文書又は標準(特に、そのプロファイル文書)に指定されたビデオ圧縮技術又は標準のシンタックスに従うという意味で、符号化ビデオシーケンスは、使用されているビデオ圧縮技術又は標準によって指定されたシンタックスに適合してもよい。また、コンプライアンスのために必要なことは、符号化ビデオシーケンスの複雑さが、ビデオ圧縮技術又は標準のレベルによって定義される範囲内にあることである。場合によっては、レベルは、最大ピクチャサイズ、最大フレームレート、最大復元サンプルレート(例えば、毎秒当たりのメガサンプル単位で測定される)、最大参照ピクチャサイズ等を制限する。場合によっては、レベルによって設定される制限は、仮想参照デコーダ(HRD,  Hypothetical  Reference  Decoder)仕様及び符号化ビデオシーケンスで伝達されるHRDバッファ管理についてのメタデータを通じて更に制限されてもよい。
【００３９】
一実施形態では、受信機(310)は、符号化ビデオと共に更なる(冗長な)データを受信してもよい。更なるデータは、符号化ビデオシーケンスの一部として含まれてもよい。更なるデータは、データを適切に復号するために、及び/又は元のビデオデータをより正確に復元するために、ビデオデコーダ(210)によって使用されてもよい。更なるデータは、例えば、時間、空間又は信号対雑音比(SNR,  signal-to-noise  ratio)エンハンスメント層、冗長スライス、冗長ピクチャ、前方誤り訂正コード等の形式でもよい。
【００４０】
図６は、本開示の一実施形態によるビデオエンコーダ(203)の機能ブロック図でもよい。
【００４１】
エンコーダ(203)は、ビデオソース(201)(エンコーダの一部ではない)からビデオサンプルを受信してもよく、当該ビデオソース(201)は、エンコーダ(203)によって符号化されるべきビデオ画像をキャプチャしてもよい。
【００４２】
ビデオソース(201)は、デジタルビデオサンプルストリームの形式でエンコーダ(203)によって符号化されるべきソースビデオシーケンスを提供してもよく、当該デジタルビデオサンプルストリームは、いずれかの適切なビット深度(例えば、8ビット、10ビット、12ビット等)、いずれかの色空間(例えば、BT.601  Y  CrCB、RGB等)及びいずれかの適切なサンプリング構造(例えば、Y  CrCb  4:2:0、Y  CrCb  4:4:4)でもよい。メディア提供システムにおいて、ビデオソース(201)は、事前に準備されたビデオを記憶する記憶デバイスでもよい。テレビ会議システムでは、ビデオソース(203)は、ローカル画像情報をビデオシーケンスとしてキャプチャするカメラでもよい。ビデオデータは、順に見たときに動きを伝える複数の個々のピクチャとして提供されてもよい。ピクチャ自体は、画素の空間配列として構成されてもよく、各画素は、使用中のサンプリング構造、色空間等に依存して、1つ以上のサンプルを含んでもよい。当業者は、画素とサンプルとの関係を容易に理解することができる。以下の説明は、サンプルに焦点を当てる。
【００４３】
一実施形態によれば、エンコーダ(203)は、リアルタイムで或いはアプリケーションによって要求されるいずれかの他の時間制約下で、ソースビデオシーケンスのピクチャを、符号化ビデオシーケンス(443)に符号化及び圧縮してもよい。適切な符号化速度を実現することは、コントローラ(450)の1つの機能である。コントローラ(450)は、以下に説明するように、他の機能ユニットを制御し、これらの機能ユニットに機能的に結合される。結合は、明確にするために図示されていない。コントローラによって設定されるパラメータは、レート制御関連パラメータ(ピクチャスキップ、量子化、レート歪み最適化技術のラムダ値当)、ピクチャサイズ、グループオブピクチャ(GOP)のレイアウト、最大動きベクトル探索範囲等を含んでもよい。当業者は、特定のシステム設計のために最適化されたビデオエンコーダ(203)に関連するコントローラ(450)の他の適切な機能を容易に識別できる。
【００４４】
いくつかのビデオエンコーダは、当業者が「符号化ループ」として容易に認識するもので動作する。非常に簡略化した説明として、一例では、符号化ループは、エンコーダ(430)の符号化部分(以下、「ソースコーダ」という)符号化されるべき入力ピクチャ及び参照ピクチャに基づいて、シンボルを生成することを担う)と、エンコーダ(203)に埋め込まれた(ローカル)デコーダ(433)とを含んでもよい。デコーダ(433)は、(リモート)デコーダが生成するサンプルデータを生成するように(シンボルと符号化ビデオビットストリームとの間のいずれかの圧縮が、開示の対象物において検討されるビデオ圧縮技術において可逆であるように)、シンボルを復元する。その復元されたサンプルストリーム(サンプルデータ)は、参照ピクチャメモリ(434)に入力される。シンボルストリームの復号は、デコーダの位置(ローカル又はリモート)と独立したビット単位の正確な結果をもたらすので、参照ピクチャバッファの内容も、ローカルエンコーダとリモートエンコーダとの間でビット単位で正確である。言い換えると、エンコーダの予測部分は、デコーダが復号中に予測を使用するときに「見る」のと全く同じサンプル値を参照ピクチャサンプルとして「見る」。参照ピクチャの同期(例えば、チャネルエラーの理由で同期が維持できない場合の結果として生じるドリフトを含む)のこの基本原理は、当業者に周知である。
【００４５】
「ローカル」デコーダ(433)の動作は、「リモート」デコーダ(210)と同じでもよく、これは、図３に関連して上記において既に詳細に説明した。しかし、図６を簡単に参照すると、シンボルが利用可能であり、エントロピーコーダ(445)及びパーサ(320)による符号化ビデオシーケンスへのシンボルの符号化/復号が可逆になり得るので、チャネル(312)、受信機(310)、バッファ(315)及びパーサ(320)を含むデコーダ(210)のエントロピー復号部分は、ローカルデコーダ(433)に完全には実装されなくてもよい。
【００４６】
この時点で行うことができる考察は、デコーダ内に存在する解析/エントロピー復号を除く如何なるデコーダ技術も、必然的に対応するエンコーダ内に実質的に同一の機能形式で存在する必要があることである。エンコーダ技術の説明は、包括的に記載されるデコーダ技術の逆であるので、省略できる。特定の領域においてのみ、より詳細な説明が必要であり、以下に提供される。
【００４７】
動作の一部として、ソースコーダ(430)は、動き補償予測符号化を実行してもよく、当該動き補償予測符号化は、「参照フレーム」として指定されたビデオシーケンスからの1つ以上の前に符号化されたフレームを参照して入力フレームを予測的に符号化する。このように、符号化エンジン(432)は、入力フレームの画素ブロックと、入力フレームに対する予測参照として選択され得る参照フレームの画素ブロックとの間の差を符号化する。
【００４８】
ローカルビデオデコーダ(433)は、ソースコーダ(430)によって生成されたシンボルに基づいて、参照フレームとして指定され得るフレームの符号化ビデオデータを復号してもよい。符号化エンジン(432)の動作は、有利には、不可逆処理でもよい。符号化ビデオデータがビデオデコーダ(図６に図示せず)で復号され得る場合、復元されたビデオシーケンスは、典型的には、いくつかのエラーを伴うソースビデオシーケンスのレプリカになり得る。ローカルビデオデコーダ(433)は、参照フレームに対してビデオデコーダによって実行され得る復号処理を複製し、復元された参照フレームを参照ピクチャキャッシュ(434)に記憶させてもよい。このように、エンコーダ(203)は、遠端のビデオデコーダによって取得される(送信エラーのない)復元された参照フレームとして、共通の内容を有する復元された参照フレームのコピーをローカルに記憶してもよい。
【００４９】
予測器(435)は、符号化エンジン(432)のための予測探索を実行してもよい。すなわち、符号化されるべき新たなフレームについて、予測器(435)は、(候補参照画素ブロックとしての)サンプルデータ又は特定のメタデータ(参照ピクチャ動きベクトル、ブロック形状等)を求めて参照ピクチャメモリ(434)を検索してもよい。これらは、新たなピクチャについての適切な予測参照として機能してもよい。予測器(435)は、適切な予測参照を検出するために、サンプルブロック毎画素ブロック毎(sample  block-by-pixel  block)に動作してもよい。場合によっては、予測器(435)によって取得された検索結果によって決定された入力ピクチャは、参照ピクチャメモリ(434)に記憶された複数の参照ピクチャから引き出された予測参照を有してもよい。
【００５０】
コントローラ(450)は、例えば、ビデオデータを符号化するために使用されるパラメータ及びサブグループパラメータの設定を含む、ビデオコーダ(430)の符号化動作を管理してもよい。
【００５１】
全ての上記の機能ユニットの出力は、エントロピーコーダ(445)におけるエントロピー符号化を受けてもよい。エントロピーコーダは、ハフマン符号化、可変長符号化、算術符号化等のような当業者に既知の技術に従って、シンボルを可逆圧縮することによって、様々な機能ユニットによって生成されたシンボルを符号化ビデオシーケンスに変換する。
【００５２】
送信機(440)は、エントロピーコーダ(445)によって生成された符号化ビデオシーケンスをバッファして、通信チャネル(460)を介した送信の準備をしてもよく、当該通信チャネル(460)は、符号化ビデオデータを記憶する記憶デバイスへのハードウェア/ソフトウェアリンクでもよい。送信機(440)は、ビデオコーダ(430)からの符号化ビデオデータを、送信されるべき他のデータ(例えば、符号化オーディオデータ及び/又は補助データストリーム(図示せず))とマージしてもよい。
【００５３】
コントローラ(450)は、エンコーダ(203)の動作を管理してもよい。符号化中に、コントローラ(450)は、各符号化ピクチャに、特定の符号化ピクチャタイプを割り当ててもよい。当該符号化ピクチャタイプは、各ピクチャに適用され得る符号化技術に影響を与えてもよい。例えば、ピクチャは、しばしば、以下のフレームタイプのうち1つとして割り当てられてもよい。
【００５４】
イントラピクチャ(Iピクチャ)は、予測のソースとしてシーケンス内の他のフレームを使用せずに、符号化及び復号され得るものでもよい。いくつかのビデオコーデックは、例えば、独立デコーダリフレッシュ(Independent  Decoder  Refresh)ピクチャを含む、異なるタイプのイントラピクチャを許容する。当業者は、Iピクチャのこれらの変形例と、それぞれの用途及び特徴を認識する。
【００５５】
予測ピクチャ(Pピクチャ)は、各ブロックのサンプル値を予測するために、最大で1つの動きベクトル及び参照インデックスを使用して、イントラ予測又はインター予測を使用して符号化及び復号され得るものでもよい。
【００５６】
双方向予測ピクチャ(Bピクチャ)は、各ブロックのサンプル値を予測するために、最大で2つの動きベクトル及び参照インデックスを使用して、イントラ予測又はインター予測を使用して符号化及び復号され得るものでもよい。同様に、複数の予測ピクチャは、単一のブロックの復元のために、2つより多くの参照ピクチャ及び関連するメタデータを使用してもよい。
【００５７】
一般的に、ソースピクチャは、空間的に複数のサンプルブロック(例えば、それぞれ4×4、8×8、4×8又は16×16のサンプルのブロック)に細分され、ブロック毎に符号化されてもよい。ブロックは、ブロックのそれぞれのピクチャに適用される符号化割り当てによって決定される通り、他の(既に符号化された)ブロックを参照して予測的に符号化されてもよい。例えば、Iピクチャのブロックは、非予測的に符号化されてもよく、或いは、同じピクチャの既に符号化されたブロックを参照して予測的に符号化されてもよい(空間予測又はイントラ予測)。Pピクチャの画素ブロックは、1つ前に符号化された参照ピクチャを参照して、空間予測又は時間予測を介して非予測的に符号化されてもよい。Bピクチャのブロックは、1つ又は2つ前に符号化された参照ピクチャを参照して、空間予測又は時間予測を介して非予測的に符号化されてもよい。
【００５８】
ビデオコーダ(203)は、ITU-T  Rec.  H.265のような所定のビデオ符号化技術又は標準に従って符号化動作を実行してもよい。その動作において、ビデオコーダ(203)は、入力ビデオシーケンスにおける時間的及び空間的冗長性を利用する予測符号化動作を含む様々な圧縮動作を実行してもよい。したがって、符号化ビデオデータは、使用されているビデオ符号化技術又は標準によって指定されたシンタックスに適合してもよい。
【００５９】
一実施形態では、送信機(440)は、符号化ビデオと共に更なるデータを送信してもよい。ビデオコーダ(430)は、符号化ビデオシーケンスの一部としてこのようなデータを含んでもよい。更なるデータは、時間/空間/SNRエンハンスメント層、冗長ピクチャ及びスライス、補足エンハンスメント情報(SEI)メッセージ、ビジュアルユーザビリティ情報(VUI,   Visual  Usability  Information)パラメータセットフラグメント等のような他の形式の冗長データを含んでもよい。
【００６０】
近年、投影されるビデオ(例えば、360°ビデオ)の圧縮は、或る程度の関心を集めている。360°ビデオでは、球体の表面は、立方体投影を通じて6個の平面の正方形表面を通じて表されてもよい。開示の対象物は、このようなシナリオにおいて使用されてもよい。以下に議論のために使用される他の使用例は、異なる定義された関心領域を有する平面の表面の符号化である。
【００６１】
図５を参照すると、例えば、監視カメラからのシーンが示されており、当該シーンは、様々なサイズ及び形状の矩形ブロックとして示される特定の数のタイル(501,502)に分割される。H.265では、シンタックスの制限のため、図示の細分は可能でない場合があるが、このような分割を可能にするためのシンタックスの変更が研究されている。例えば、http://phenix.it-sudparis.eu/jvet/doc_end_user/documents/11_Ljubljana/wg11/JVET-K0260-v2.zipから入手可能なR.  Sjoberg,  et.  al.,「Flexible  Tiles」,  JVET-K0260,  7/2018を参照する。図示の分割は、特定の特性を有するシーンの領域をカバーするCUをタイルにまとめるために使用されてもよい。監視カメラの場合、例えば、空を示すタイル(501)は、タイル(502)によってキャプチャされる建物の入り口ほど関連しなくてもよい。上記のように、タイルは、独立して復号可能でもよい。したがって、デコーダが全体のシーンを復号するのに十分なパワーを有さないシナリオでは、アプリケーションにあまり関連しないCUを含むタイル(タイル501内のCU等)を破棄し、むしろ、関連するタイル(タイル502内のCU等)のみを復号してもよい。同様に、ネットワーク内の選択的転送ユニット(SFU,  selective  forwarding  unit)がカメラから全シーンを受信するが、その出力リンクが不十分な帯域幅を有する場合、場合によっては、SFUはアプリケーションにあまり関連しないタイルを破棄してもよい。これは、柔軟なタイルメカニズムが有用になり得る動機の1つに過ぎない。他の例は、立方体マップの全ての6個の表面を単一のピクチャで送信することでもよい。各表面は1つのタイルで表される。立方体を逆投影法でレンダリングする場合、立方体の外側のいずれか所与の視点からレンダリングするためには、最大で3つの表面が必要である。したがって、最小で3つの表面は、送信される必要も復号される必要もない。したがって、柔軟なタイルは、ビットストリームを分割するのを助けることができ、その結果、SFU又はデコーダは、ハイレベルのシンタックスの決定に基づいて、不要な表面を含む不要なタイルを破棄することができる。
【００６２】
タイルは、エンコーダの並列処理をサポートするために最初に導入された。このようなシナリオでは、タイルレイアウトは、エンコーダが利用可能なプロセッサの性質に大きく影響される。例えば、4つのコア上で動作するエンコーダは、その負荷のバランスを取るために、ピクチャを、ソースピクチャとほぼ同じサイズ及びほぼ同じアスペクト比の4つの矩形領域に分割してもよい。同様のアスペクト比は、イントラ予測、動き補償等のような2次元符号化ツールを利用するために有利になり得る。
【００６３】
H.265のタイルのシンタックスが、例えばSjoberg  et  al.において提案されたように修正されたとしても、1つの重要な問題が残されている。アプリケーションのニーズに基づいてピクチャをタイル分割する場合、タイル分割が並列処理に最適でない可能性があり、逆も同様である。
【００６４】
上記の欠点を克服するために使用できる多数の可能な技術が存在する。
【００６５】
(1)コア/プロセッサへのCUカウントによるタイルの割り当て
【００６６】
依然として図５を参照すると、一実施形態では、エンコーダは、その分割方式を使用し、タイルのサイズに基づいてタイルをコアに割り当ててもよく、その結果、各コアは、ほぼ同じ作業負荷を伴うタイルで動作する。その作業負荷は、例えば、サンプル数、CU数(CUが同じサイズであると仮定する)又は同様の指標として測定されてもよい。一例として、タイル(501)が空を示す大きい領域(容易に検出可能であり且つ監視シナリオにおいて限られた関連性を有し、したがって、容易に符号化できる)を含むという理論に基づいて、エンコーダは、タイル(501,503,504)を一方のコアに割り当て、残りのタイルを他方のコアに割り当ててもよい。したがって、残りのタイルに対してタイル(501,503,504)のより大きい空間領域は重要ではない。このようなメカニズムの犠牲は、所与のコアが担うタイルが隣接していない可能性があり、このことが更なるメモリアクセスをもたらす可能性があることである。いくつかのビデオエンコーダでは、メモリアクセスがボトルネックとなる可能性がある。他の問題は、アプリケーション主導のタイルレイアウトは、(タイルに含まれるCU数の観点から)適切なサイズのタイルが利用可能であることを保証できないことである。したがって、或る時間間隔毎にk個のCUがそれぞれ可能なn個のコアの所与のエンコーダは、n×k個のCUのタイルで繋げられたピクチャをリアルタイムに符号化できることを保証できず、安全係数を計算することは困難である。このようなシナリオにおけるタイルレイアウトはアプリケーション主導とすることができ、エンコーダはアプリケーション主導の制約に従わざるを得ないので、これはリアルタイムアプリケーションにとって重要になり得る。場合によっては、エンコーダは、アプリケーション主導のタイルレイアウトに対処するように準備される必要があってもよく、この場合、アプリケーションが全てのCUを単一のタイルに入れることを決定するかもしれないという単純な理由で、タイルに基づくエンコーダベースの並列処理が想定できない。
【００６７】
(2)アプリケーションのニーズのためのタイルと並列処理のためのタイルとの機能の分離:階層的タイル
【００６８】
より明確な解決策は、並列処理の目的のタイルとアプリケーションのニーズのためのタイルとの機能を分離することでもよい。
【００６９】
図６を参照すると、図５と同じアプリケーション主導のタイルレイアウトが示されている(実線601として示されている)が、並列処理のために最適化された等しいサイズのタイル(太い破線602として示されている)の2×2のグリッドの更なるオーバーレイがある。このシナリオでは、細線と太線の双方が、ビットストリーム構成の目的のタイル境界を形成する。したがって、ピクチャが分割されるタイルの数は増加する。
【００７０】
同一又は他の実施形態では、並列エンコーダは、並列処理タイル領域内に位置するタイルがそれぞれのコアに割り当てられて処理されるということを除き、このタイルレイアウト(細線と太線の双方で生成されるもの)で通常の方法で動作する。「アプリケーション」のタイルレイアウトは、ビットストリーム生成処理の間に観察されるが、コアの割り当てに使用されない。したがって、アプリケーション主導のタイルレイアウトがない場合と同じ程度の良好な並列処理が、アプリケーション主導のタイルレイアウトによっても達成できる。コストは、ビットストリームにおける更なるタイルの使用であり、これは、更なるビットを要する可能性があり、また、防止するステップが取られない限り(これも更なるビットを要する)、タイル境界における復元された画質を損なう可能性がある。
【００７１】
(3)階層的タイルセット
【００７２】
H.265では、タイル形状の制御情報は、ピクチャパラメータセット(PPS,  Picture Parameter  Set)に位置する。したがって、タイル形状は、ピクチャ毎に変化する可能性がある。アプリケーション主導のタイルレイアウトの目的で、それは賢明な設計選択である。その理由は、例えば、パン・チルト・ズームカメラを使用する場合、又は高速移動物体及びタイル境界を識別するための物体認識を使用する場合、シーンの内容が急速に変化する可能性があるからである。しかし、並列処理の目的のために、これは最良の解決策ではない可能性がある。今日主流のエンコーダアーキテクチャでは、符号化されるべきピクチャの部分へのコアの動的な割り当ては、初期化時に一度行われてもよく、通常では以降は一定に保たれる。
【００７３】
その状況を反映するために、同一又は他の実施形態では、タイル制御情報は階層に分割される。破線(602)によって表される「よりハイレベル」のタイル制御情報は、主に並列処理のために使用されてもよい。これは、よりハイレベルのシンタックス構造(シーケンスパラメータセット(SPS,  sequence  parameter  set)等)で符号化できる一方で、アプリケーション主導のタイル制御情報(実線601として示されるタイル境界を表す)は、ピクチャパラメータセット(PPS,  picture  parameter  set)を使用し続けることができる。このような割り当ては、並列処理タイルレイアウト(602)の静的なハードウェア主導の性質を反映する一方で、アプリケーションタイルレイアウト(601)の動的な復元の可能性を尊重する。これらのタイル制御情報を他のシンタックスエレメント(他のパラメータセット、スライスヘッダ、ピクチャヘッダ、GOPヘッダ等)に割り当てることももちろん可能である。
【００７４】
タイルへのビットストリームの細分は、ピクチャ内又はピクチャ間予測の観点から、特定の特性を有することができることが既に指摘されている。全てのタイル方式はシンタックス予測を中断し、CABACをリセットするが、特定のタイル方式は、カレントピクチャ又は参照ピクチャのタイルの外側からのサンプル予測を可能にする。タイル制御情報を階層に分割することによって、タイル境界毎の予測の性質が、ニーズ(例えば、アプリケーションのニーズ又は並列処理のニーズ等)に合わせて設計できる。例えば、タイルが並列処理に使用される少なくともいくつかの実装では、タイル境界を横切る動き補償が可能である。これは、参照ピクチャが全てのコアによって共有される低速メモリに記憶される可能性があるので、動作可能である。他方、アプリケーションのニーズのために、サンプル境界を横切る動き補償は禁止されてもよい。その理由は、境界を横切って、タイル内のサンプルと意味的にほとんど或いは全く共通点がないサンプルが存在し得るからである。一例として、立方体投影の立方体表面に沿って延びるタイル境界について検討する。しかし、タイル境界がより制限されるほど、タイル境界に対する符号化効率ペナルティは、考えられるアーチファクトは言うまでもなく、より高くなり得る。
【００７５】
したがって、並列処理のために導入されたタイル境界を、アプリケーションのニーズのために導入されたタイル境界とは異なるように処理することは、符号化効率の観点から有用になり得る。
【００７６】
同一又は他の実施形態では、タイル境界は、エンコーダ及びデコーダがタイル境界を横切る予測の程度を決定するために使用することができる、タイル境界に関連する制御情報を有してもよい。このような情報は、例えば、フラグのセットで表現されてもよく、フラグは、例えば、シンタックス予測、CABACリセット、イントラ予測、ピクチャ内参照ブロック予測(別名、イントラブロックコピー(IBC,  intra  block  copy))、動きベクトル予測、動き補償予測(サンプルレベル)等の特定のタイプの予測の中断を表す。当業者は、ビデオ符号化技術又は標準の性質に基づいて、適切な数のこのようなフラグを容易に考えることができる。
【００７７】
タイル境界毎にこのような情報を記憶することは、レート歪みの観点から負担が大きく非効率的になり得る。しかし、異なる境界について異なる予測メカニズムを有効/無効にさせる理由は、これらの境界の性質(例えば、アプリケーション主導又は並列処理主導)のためでもよい。したがって、同一又は他の実施形態では、フラグのセットは、例えば、SPS及びPPSに記憶されるタイル階層のそれぞれに配置されて関連付けられてもよい。
【００７８】
復号の際、使用中の適切な予測メカニズムは制御情報から導出されてもよい。使用中の予測メカニズムは、同じタイルの異なる境界について異なってもよい。例えば、タイル(603)を復号する場合、タイル(603)の上の境界は、関連するSPSの予測メカニズム(例えば、動き補償を可能にする)を有してもよく、タイル(603)の残りのタイル境界は、PPSにおいて定義される予測メカニズム(例えば、動きが制限され得る)を有してもよい。
【００７９】
図７は、符号化ビデオシーケンスを復号する例示的な処理700のフローチャートである。いくつかの実装では、図７の1つ以上の処理ブロックは、デコーダ210によって実行されてもよい。いくつかの実装では、図７の1つ以上の処理ブロックは、エンコーダ207のように、デコーダ210とは別の他のデバイス若しくはデバイスのグループ、又は、デコーダ210を含む他のデバイス若しくはデバイスのグループによって実行されてもよい。
【００８０】
図７に示すように、処理700は、符号化ビデオシーケンスから、少なくとも1つの第1の予測メカニズムが第1のタイル境界を横切って利用可能であると決定すること(ブロック710)を含んでもよい。
【００８１】
図７に更に示されるように、処理700は、符号化ビデオシーケンスから、少なくとも1つの第1の予測メカニズムが第2のタイル境界を横切って利用不可能であると決定すること(ブロック720)を含んでもよい。
【００８２】
図７に更に示されるように、処理700は、第1のタイルレイアウトによって規定される第1のタイル境界と、第2のタイルレイアウトによって規定される第2のタイル境界とを含んでもよい少なくとも1つのタイルを復号すること(ブロック730)を含んでもよい。
【００８３】
一実施形態では、第1のタイルレイアウトは、並列処理主導のタイルレイアウトを含んでもよく、第2のタイルレイアウトは、アプリケーション主導のタイルレイアウトを含んでもよい。
【００８４】
一実施形態では、符号化ビデオシーケンスは、少なくとも1つの第2の予測メカニズムが第1のタイル境界及び第2のタイル境界を横切って利用可能であることを示す。
【００８５】
一実施形態では、第1のタイルレイアウトは、符号化ビデオシーケンスの第1のシンタックス構造で記述され、第2のタイルレイアウトは、符号化ビデオシーケンスの第2のシンタックス構造で記述され、第1のシンタックス構造は第2のシンタックス構造と異なる。
【００８６】
一実施形態では、第1のシンタックス構造は、第2のシンタックス構造よりもハイレベルのシンタックス構造である。
【００８７】
一実施形態では、第1のシンタックス構造は、シーケンスパラメータセットを含んでもよく、第2のシンタックス構造は、ピクチャパラメータセットを含んでもよい。
【００８８】
一実施形態では、第1のタイルレイアウト及び第2のタイルレイアウトは、シーケンスパラメータセット、ピクチャパラメータセット、スライスヘッダ、ピクチャヘッダ又はグループオブピクチャのヘッダのうち少なくとも1つに記述される。
【００８９】
一実施形態では、少なくとも1つの第1の予測メカニズムは、シンタックス予測、コンテキスト適応バイナリ算術符号化リセット、イントラ予測、ピクチャ内参照ブロック予測、イントラブロックコピー、動きベクトル予測又は動き補償予測のうち少なくとも1つを含んでもよい。
【００９０】
一実施形態では、第1のタイルレイアウトの記述は、少なくとも1つの第1の予測メカニズムが第1のタイル境界を横切って利用可能であることを示すシンタックスエレメントを含んでもよい。
【００９１】
一実施形態では、第2のタイルレイアウトの記述は、少なくとも1つの第1の予測メカニズムが第2のタイル境界を横切って利用不可能であることを示すシンタックスエレメントを含んでもよい。
【００９２】
図７は、処理700の例示的なブロックを示しているが、いくつかの実装では、処理700は、図７に示されているものよりも、更なるブロック、より少ないブロック、異なるブロック又は異なる配置のブロックを含んでもよい。さらに或いは代替として、処理700のブロックのうち2つ以上は、並行して実行されてもよい。
【００９３】
さらに、提案の方法は、処理回路(例えば、1つ以上のプロセッサ又は1つ以上の集積回路)によって実装されてもよい。一例では1つ以上のプロセッサは、提案の方法のうち1つ以上を実行するために、非一時的なコンピュータ読み取り可能媒体に記憶されたプログラムを実行する。
【００９４】
上記の技術は、コンピュータ読み取り可能命令を使用してコンピュータソフトウェアとして実装され、1つ以上のコンピュータ読み取り可能媒体に物理的に記憶されてもよい。例えば、図８は、開示の対象物の特定の実施形態を実装するのに適したコンピュータシステム800を示す。
【００９５】
コンピュータソフトウェアは、いずれかの適切な機械コード又はコンピュータ言語を使用して符号化されてもよく、当該機械コード又はコンピュータ言語は、命令を含むコードを生成するために、アセンブリ、コンパイル、リンク又は類似のメカニズムを受けてもよく、当該命令は、コンピュータ中央処理装置(CPU,  central  processing  unit)、グラフィックス処理ユニット(GPU,  Graphics  Processing  Unit)等によって、直接的に或いはインタープリタ、マイクロコード実行等を通じて実行されてもよい。
【００９６】
命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、モノのインターネットのデバイス等を含む様々なタイプのコンピュータ又はその構成要素上で実行されてもよい。
【００９７】
コンピュータシステム800について図８に示される構成要素は、本質的に例示的なものであり、本開示の実施形態を実装するコンピュータソフトウェアの使用範囲又は機能に関する如何なる限定も示唆することを意図するものではない。また、構成要素の構成も、コンピュータシステム800の例示的な実施形態に示される構成要素のいずれか1つ又は組み合わせに関する如何なる依存性又は要件も有するものとして解釈されるべきではない。
【００９８】
コンピュータシステム800は、特定のヒューマンインタフェース入力デバイスを含んでもよい。このようなヒューマンインタフェース入力デバイスは、例えば、触覚入力(キーストローク、スワイプ、データグローブの動き等)、オーディオ入力(音声、拍手等)、視覚入力(ジェスチャ等)、嗅覚入力(図示せず)を通じて、1人以上の人間のユーザによる入力に応答してもよい。また、ヒューマンインタフェースデバイスは、オーディオ(例えば、会話、音楽、周辺音)、画像(スキャンされた画像、静止画カメラから取得された写真画像)、ビデオ(2次元ビデオ、立体ピクチャを含む3次元ビデオ等)のような、人間による意識的入力に必ずしも直接関連しない特定のメディアをキャプチャするために使用されてもよい。
【００９９】
入力ヒューマンインタフェースデバイスは、キーボード801、マウス802、トラックパッド803、タッチ画面810、データグローブ804、ジョイスティック805、マイクロフォン806、スキャナ807、カメラ808のうち1つ以上を含んでもよい(それぞれ1つのみが図示されている)。
【０１００】
また、コンピュータシステム800は、特定のヒューマンインタフェース出力デバイスを含んでもよい。このようなヒューマンインタフェース出力デバイスは、例えば、触覚出力、音、光及び嗅覚/味覚を通じて、1人以上の人間のユーザの感覚を刺激してもよい。このようなヒューマンインタフェース出力デバイスは、触覚出力デバイス(例えば、タッチ画面810、データグローブ804又はジョイスティック805による触覚フィードバック、ただし、入力デバイスとして機能しない触覚フィードバックデバイスが存在してもよい)と、オーディオ出力デバイス(スピーカ809、ヘッドフォン(図示せず)等)と、視覚出力デバイス(それぞれがタッチ画面入力機能を有しても有さなくてもよく、それぞれが触覚フィードバック機能を有しても有さなくてもよく、いくつかが2次元視覚出力又は立体出力のような手段を通じた3次元以上の出力を出力可能でもよい陰極線管(CRT,  cathode  ray  tube)画面、液晶ディスプレイ(LCD,  liquid-crystal  display)画面、プラズマ画面、有機発光ダイオード(OLED,  organic  light-emitting  diode)画面を含む画面810、仮想現実メガネ(図示せず)、ホログラフィックディスプレイ及びスモークタンク(図示せず))と、プリンタ(図示せず)とを含んでもよい。
【０１０１】
また、コンピュータシステム800は、CD/DVD又は同様の媒体821を有するCD/DVD  ROM/RW820を含む光媒体のような人間がアクセス可能な記憶デバイス及び関連する媒体、サムドライブ822、取り外し可能ハードドライブ又はソリッドステートドライブ823、テープ及びフロッピーディスク(図示せず)のようなレガシー磁気媒体、セキュリティドングル(図示せず)のような特殊なROM/ASIC/PLDに基づくデバイス等を含んでもよい。
【０１０２】
また、当業者は、ここに開示の対象物に関連して使用される用語「コンピュータ読み取り可能媒体」が伝送媒体、搬送波又は他の非一時的な信号を含まないことを理解すべきである。
【０１０３】
また、コンピュータシステム800は、1つ以上の通信ネットワークへの1つ以上のインタフェースを含んでもよい。ネットワークは、例えば、無線、有線、光でもよい。ネットワークは、ローカル、広域、メトロポリタン、車両及び産業、リアルタイム、遅延耐性等でもよい。ネットワークの例は、イーサネット、無線LAN、セルラネットワーク(GSM(global  systems  for  mobile  communications)、第3世代(3G)、第4世代(4G)、第5世代(5G)、ロングタームエボリューション(LTE,  Long-Term  Evolution)等を含む)、TV有線又は無線広域デジタルネットワーク(ケーブルTV、衛星TV、及び地上放送TVを含む)、車両及び産業(CANBusを含む)等を含む。特定のネットワークは、一般的に、特定の汎用データポート又は周辺バス(849)に取り付けられる外部ネットワークインタフェースアダプタ(例えば、コンピュータシステム800のユニバーサルシリアルバス(USB,  universal  serial  bus)ポート等)を必要とし、他のネットワークインタフェースアダプタは、一般的に、以下に説明するシステムバス(例えば、PCコンピュータシステムへのイーサネットインタフェース又はスマートフォンコンピュータシステムへのセルラネットワーク)に取り付けられることによって、コンピュータシステム800のコアに統合される。これらのネットワークのいずれかを使用して、コンピュータシステム800は、他のエンティティと通信することができる。このような通信は、一方向の受信のみ(例えば、放送TV)、一方向の送信のみ(例えば、特定のCANbusデバイスへのCANbus)でもよく、或いは、例えば、ローカル又は広域デジタルネットワークを使用する他のコンピュータシステムへの双方向でもよい。特定のプロトコル及びプロトコルスタックは、上記のようなネットワーク及びネットワークインタフェースのそれぞれにおいて使用されてもよい。
【０１０４】
上記のヒューマンインタフェースデバイス、人間がアクセス可能な記憶デバイス及びネットワークインタフェースは、コンピュータシステム800のコア840に取り付けられてもよい。
【０１０５】
コア840は、1つ以上の中央処理装置(CPU)841、グラフィックス処理ユニット(GPU)842、フィールドプログラマブルゲートアレイ(FPGA,  Field  Programmable  Gate  Area)843の形式の特殊なプログラム可能処理ユニット、特定のタスク用のハードウェアアクセラレータ844等を含んでもよい。これらのデバイスは、読み取り専用メモリ(ROM)845、ランダムアクセスメモリ(RAM)846、内部大容量記憶装置(内部のユーザアクセス不可能なハードドライブ、ソリッドステートドライブ(SSD,  solid-state  drive)等)847と共に、システムバス848を通じて接続されてもよい。いくつかのコンピュータシステムでは、システムバス848は、更なるCPU、GPU等による拡張を可能にするために、1つ以上の物理プラグの形式でアクセス可能でもよい。周辺デバイスは、コアのシステムバス848に直接取り付けられてもよく、或いは、周辺バス849を通じて取り付けられてもよい。周辺バスのアーキテクチャは、ペリフェラルコンポーネントインターコネクト(PCI,  peripheral  component  interconnect)、USB等を含む。
【０１０６】
CPU841、GPU842、FPGA843及びアクセラレータ844は特定の命令を実行してもよく、当該特定の命令は、組み合わせによって上記のコンピュータコードを構成してもよい。当該コンピュータコードは、ROM845又はRAM846に記憶されてもよい。また、一時的なデータは、RAM846に記憶されてもよいが、永続的なデータは、例えば、内部大容量記憶装置847に記憶されてもよい。1つ以上のCPU841、GPU842、大容量記憶装置847、ROM845、RAM846等と密接に関連してもよいキャッシュメモリを使用することによって、メモリデバイスのいずれかへの高速記憶及び検索が可能になってもよい。
【０１０７】
コンピュータ読み取り可能媒体は、様々なコンピュータに実装された動作を実行するためのコンピュータコードを有してもよい。媒体及びコンピュータコードは、本開示の目的のために特に設計及び構築されたものでよく、或いは、コンピュータソフトウェア分野における当業者に周知で入手可能なようなものでもよい。
【０１０８】
限定ではなく一例として、アーキテクチャ800、具体的には、コア840を有するコンピュータシステムは、1つ以上の有形のコンピュータ読み取り可能媒体に具現されたソフトウェアを実行するプロセッサ(CPU、GPU、FPGA、アクセラレータ等を含む)の結果として機能を提供できる。このようなコンピュータ読み取り可能媒体は、コア内部の大容量記憶装置847又はROM845のような非一時的な性質のコア840の特定の記憶装置と同様に、上記のようなユーザがアクセス可能な大容量記憶装置に関連する媒体でもよい。本開示の様々な実施形態を実装するソフトウェアは、このようなデバイスに記憶されてコア840によって実行されてもよい。コンピュータ読み取り可能媒体は、特定のニーズに従って、1つ以上のメモリデバイス又はチップを含んでもよい。ソフトウェアは、コア840、具体的には、その中のプロセッサ(CPU、GPU、FPGA等を含む)に、RAM846に記憶されたデータ構造を定義し、ソフトウェアによって定義された処理に従ってこのようなデータ構造を修正することを含む、本明細書に記載の特定の処理又は特定の処理の特定の部分を実行させてもよい。さらに或いは代替として、コンピュータシステムは、回路(例えば、アクセラレータ844)内に配線されたロジック又は他の方法で具現されたロジックの結果として、機能を提供してもよく、当該回路は、本明細書に記載の特定の処理又は特定の処理の特定の部分を実行するために、ソフトウェアの代わりに或いはソフトウェアと共に動作してもよい。ソフトウェアへの言及は、ロジックを含み、必要に応じて、その逆も可能である。コンピュータ読み取り可能媒体への言及は、必要に応じて、実行するためのソフトウェアを記憶する回路(集積回路(IC)等)、実行するためのロジックを具現する回路又はこれらの双方を含んでもよい。本開示は、ハードウェア及びソフトウェアのいずれかの適切な組み合わせを含む。
【０１０９】
本開示は、いくつかの例示的な実施形態を記載しているが、本開示の範囲内に入る変更、置換及び様々な代替の等価物が存在する。したがって、当業者は、本明細書に明示的に図示又は記載されていないが、本開示の原理を具現し、したがって、本開示の真意及び範囲内にある多数のシステム及び方法を考案することができることが認識される。
【図１】
2021521752.tif 000003
【図２】
2021521752.tif 000004
【図３】
2021521752.tif 000005
【図４】
2021521752.tif 000006
【図５】
2021521752.tif 000007
【図６】
2021521752.tif 000008
【図７】
2021521752.tif 000009
【図８】
2021521752.tif 000010
【国際調査報告】
2021521752.tif 000011