特表2022-521517 | 知財ポータル「IP Force」

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

青山学院大学 (神奈川県相模原市中央区淵野辺)

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

特表2022-521517エンコーディングされたビデオビットストリームをデコーディングする方法、装置、およびコンピュータプログラム

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6A
6B
7
8
9
10

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2022-04-08

(54)【発明の名称】エンコーディングされたビデオビットストリームをデコーディングする方法、装置、およびコンピュータプログラム

(51)【国際特許分類】

H04N 19/132 20140101AFI20220401BHJP

H04N 19/70 20140101ALI20220401BHJP

H04N 19/172 20140101ALI20220401BHJP

【ＦＩ】

H04N19/132

H04N19/70

H04N19/172

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2021549115

(86)(22)【出願日】2020-09-10

(85)【翻訳文提出日】2021-08-19

(86)【国際出願番号】 US2020050077

(87)【国際公開番号】W WO2021055216

(87)【国際公開日】2021-03-25

(31)【優先権主張番号】62/903,601

(32)【優先日】2019-09-20

(33)【優先権主張国・地域又は機関】US

(31)【優先権主張番号】17/009,979

(32)【優先日】2020-09-02

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

(71)【出願人】

【識別番号】520353802

【氏名又は名称】テンセント・アメリカ・エルエルシー

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広信哉

(74)【代理人】

【識別番号】100150197

【弁理士】

【氏名又は名称】松尾直樹

(72)【発明者】

【氏名】ビョンドゥ・チェ

(72)【発明者】

【氏名】ステファン・ヴェンガー

(72)【発明者】

【氏名】シャン・リュウ

【テーマコード（参考）】

5C159

【Ｆターム（参考）】

5C159LB05

5C159MA05

5C159MA21

5C159MC11

5C159ME01

5C159ME17

5C159PP16

5C159RC12

5C159TA06

5C159TB04

5C159TC25

5C159TC34

5C159UA02

5C159UA05

(57)【要約】

少なくとも1つのプロセッサを使用してエンコーディングされたビデオビットストリームをデコーディングする方法であって、現在のピクチャを含むコーディングされたビデオシーケンスにおいて一定のピクチャサイズが使用されるかどうかを示す第1のフラグを取得するステップと、一定のピクチャサイズが使用されることを示す第1のフラグに基づいて、基準ピクチャリサンプリングを実行することなく現在のピクチャをデコーディングするステップと、一定のピクチャサイズが使用されないことを示す第1のフラグに基づいて、適合性ウィンドウサイズがシグナリングされるかどうかを示す第2のフラグを取得するステップと、適合性ウィンドウサイズがシグナリングされることを示す第2のフラグに基づいて、適合性ウィンドウサイズを取得するステップと、適合性ウィンドウサイズに基づいて現在のピクチャと基準ピクチャとの間のリサンプリング比率を決定するステップと、リサンプリング比率を用いて現在のピクチャに関して基準ピクチャリサンプリングを実行するステップとを含む方法。

【特許請求の範囲】

【請求項1】

少なくとも1つのプロセッサを使用してエンコーディングされたビデオビットストリームをデコーディングする方法であって、前記方法は、
現在のピクチャを含むコーディングされたビデオシーケンスにおいて一定のピクチャサイズが使用されるかどうかを示す第1のフラグを取得するステップと、
前記一定のピクチャサイズが使用されることを示す前記第1のフラグに基づいて、基準ピクチャリサンプリングを実行することなく現在のピクチャをデコーディングするステップと、
前記一定のピクチャサイズが使用されないことを示す前記第1のフラグに基づいて、適合性ウィンドウサイズがシグナリングされるかどうかを示す第2のフラグを取得するステップと、
前記適合性ウィンドウサイズがシグナリングされることを示す前記第2のフラグに基づいて、
前記適合性ウィンドウサイズを取得するステップと、
前記適合性ウィンドウサイズに基づいて前記現在のピクチャと基準ピクチャとの間のリサンプリング比率を決定するステップと、
前記リサンプリング比率を用いて前記現在のピクチャに関して前記基準ピクチャリサンプリングを実行するステップと
を含む方法。

【請求項2】

前記適合性ウィンドウサイズは、前記現在のピクチャの境界からの少なくとも1つのオフセット距離としてシグナリングされる、請求項1に記載の方法。

【請求項3】

前記第1のフラグがシーケンスパラメータセット（SPS）でシグナリングされ、
前記第2のフラグが前記SPS及びピクチャパラメータセット（PPS）のうちの1つでシグナリングされる、
請求項1に記載の方法。

【請求項4】

前記第2のフラグは、前記SPSでシグナリングされるとともに、SPS適合性ウィンドウパラメータが前記SPSでシグナリングされるかどうかを示す、請求項3に記載の方法。

【請求項5】

前記SPS適合性ウィンドウパラメータが前記SPSでシグナリングされることを示す前記第2のフラグに基づき、前記適合性ウィンドウサイズが前記SPS適合性ウィンドウパラメータに基づいて取得される、請求項4に記載の方法。

【請求項6】

前記ピクチャサイズが一定ではないことを示す前記第1のフラグに基づいて、PPS適合性ウィンドウパラメータが前記PPSでシグナリングされるかどうかを示す第3のフラグを取得するステップを更に含む、請求項4に記載の方法。

【請求項7】

前記SPS適合性ウィンドウパラメータが前記SPSでシグナリングされることを示す前記第2のフラグと、前記PPS適合性ウィンドウパラメータが前記PPSでシグナリングされないことを示す前記第3のフラグとに基づき、前記適合性ウィンドウサイズが前記SPS適合性ウィンドウパラメータに基づいて取得される、請求項6に記載の方法。

【請求項8】

前記SPS適合性ウィンドウパラメータが前記SPSでシグナリングされないことを示す前記第2のフラグと、前記PPS適合性ウィンドウパラメータが前記PPSでシグナリングされることを示す前記第3のフラグとに基づき、前記適合性ウィンドウサイズが前記PPS適合性ウィンドウパラメータに基づいて取得される、請求項6に記載の方法。

【請求項9】

エンコーディングされたビデオビットストリームをデコーディングするためのデバイスであって、前記デバイスは、
プログラムコードを記憶するように構成される少なくとも1つのメモリと、
前記プログラムコードを読み取って前記プログラムコードにより指示されるように動作するべく構成される少なくとも1つのプロセッサと、
を備え、
前記プログラムコードは、
現在のピクチャを含むコーディングされたビデオシーケンスで一定のピクチャサイズが使用されるかどうかを示す第1のフラグを前記少なくとも1つのプロセッサに取得させるように構成される第1の取得コードと、
前記一定のピクチャサイズが使用されることを示す前記第1のフラグに基づいて基準ピクチャリサンプリングを実行することなく前記現在のピクチャを前記少なくとも1つのプロセッサにデコーディングさせるように構成されるデコーディングコードと、
前記一定のピクチャサイズが使用されないことを示す前記第1のフラグに基づいて、適合性ウィンドウサイズがシグナリングされるかどうかを示す第2のフラグを前記少なくとも1つのプロセッサに取得させるように構成される第2の取得コードと、
前記少なくとも1つのプロセッサに、前記適合性ウィンドウサイズがシグナリングされることを示す前記第2のフラグに基づいて前記適合性ウィンドウサイズを取得させ、前記適合性ウィンドウサイズに基づいて前記現在のピクチャと基準ピクチャとの間のリサンプリング比率を決定させ、及び、前記リサンプリング比率を使用して前記現在のピクチャに関して基準ピクチャリサンプリングを実行させるように構成される実行コードと、
を含むデバイス。

【請求項10】

前記適合性ウィンドウサイズは、前記現在のピクチャの境界からの少なくとも1つのオフセット距離としてシグナリングされる、請求項9に記載のデバイス。

【請求項11】

前記第1のフラグがシーケンスパラメータセット（SPS）でシグナリングされ、
前記第2のフラグが前記SPS及びピクチャパラメータセット（PPS）のうちの1つでシグナリングされる、
請求項9に記載のデバイス。

【請求項12】

前記第2のフラグは、前記SPSでシグナリングされるとともに、SPS適合性ウィンドウパラメータが前記SPSでシグナリングされるかどうかを示す、請求項11に記載のデバイス。

【請求項13】

前記SPS適合性ウィンドウパラメータが前記SPSでシグナリングされることを示す前記第2のフラグに基づき、前記適合性ウィンドウサイズが前記SPS適合性ウィンドウパラメータに基づいて取得される、請求項12に記載のデバイス。

【請求項14】

前記プログラムコードは、前記ピクチャサイズが一定でないことを示す前記第1のフラグに基づいて、PPS適合性ウィンドウパラメータが前記PPSでシグナリングされるかどうかを示す第3のフラグを前記少なくとも1つのプロセッサに取得させるように構成される第3の取得コードを更に含む、請求項12に記載のデバイス。

【請求項15】

前記SPS適合性ウィンドウパラメータが前記SPSでシグナリングされることを示す前記第2のフラグと、前記PPS適合性ウィンドウパラメータが前記PPSでシグナリングされないことを示す前記第3のフラグとに基づき、前記適合性ウィンドウサイズが前記SPS適合性ウィンドウパラメータに基づいて取得される、請求項14に記載のデバイス。

【請求項16】

前記SPS適合性ウィンドウパラメータが前記SPSでシグナリングされないことを示す前記第2のフラグと、前記PPS適合性ウィンドウパラメータが前記PPSでシグナリングされることを示す前記第3のフラグとに基づき、前記適合性ウィンドウサイズが前記SPS適合性ウィンドウパラメータに基づいて取得される、請求項14に記載のデバイス。

【請求項17】

命令を記憶する非一時的コンピュータ可読媒体であって、前記命令は、エンコーディングされたビデオビットストリームをデコーディングするためのデバイスの1つ以上のプロセッサによって実行されるときに、前記1つ以上のプロセッサに、
現在のピクチャを含むコーディングされたビデオシーケンスで一定のピクチャサイズが使用されるかどうかを示す第1のフラグを取得させ、
前記一定のピクチャサイズが使用されることを示す前記第1のフラグに基づいて、基準ピクチャリサンプリングを実行することなく前記現在のピクチャをデコーディングさせ、
前記一定のピクチャサイズが使用されないことを示す前記第1のフラグに基づいて、適合性ウィンドウサイズがシグナリングされるかどうかを示す第2のフラグを取得させ、
前記適合性ウィンドウサイズがシグナリングされることを示す前記第2のフラグに基づいて、前記適合性ウィンドウサイズを取得させ、
前記適合性ウィンドウサイズに基づいて、前記現在のピクチャと基準ピクチャとの間のリサンプリング比率を決定させ、
前記リサンプリング比率を使用して前記現在のピクチャに関して基準ピクチャリサンプリングを実行させる、
1つ以上の命令を含む、非一時的コンピュータ可読媒体。

【請求項18】

前記第1のフラグがシーケンスパラメータセット（SPS）でシグナリングされ、
前記第2のフラグが前記SPS及びピクチャパラメータセット（PPS）のうちの1つでシグナリングされる、
請求項17に記載のデバイス。

【請求項19】

前記第2のフラグは、前記SPSでシグナリングされるとともに、SPS適合性ウィンドウパラメータが前記SPSでシグナリングされるかどうかを示す、請求項18に記載のデバイス。

【請求項20】

前記1つ以上の命令は、前記少なくとも1つのプロセッサに、前記ピクチャサイズが一定でないことを示す前記第1のフラグに基づいて、PPS適合性ウィンドウパラメータが前記PPSでシグナリングされるかどうかを示す第3のフラグを更に取得させる、請求項19に記載のデバイス。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、2019年9月20日に出願された米国仮出願第62／903，601号及び2020年9月2日に出願された米国特許出願第17／009，979号の優先権を主張し、これらの出願の全体は本願に組み入れられる。

【0002】

開示される主題は、ビデオコーディング及びデコーディングに関し、より具体的には、ピクチャごとに又はピクチャ部分ごとに変化し得るピクチャ又はピクチャ部分のサイズのシグナリングに関する。

【背景技術】

【0003】

動き補償を伴うピクチャ間予測を用いたビデオコーディング及びデコーディングが知られている。非圧縮デジタルビデオは一連のピクチャから成ることができ、各ピクチャは、例えば1920×1080のルミナンスサンプル及び関連するクロミナンスサンプルの空間寸法を有する。一連のピクチャは、例えば毎秒60ピクチャ又は60 Hzの所定の又は可変のピクチャレート（非公式にはフレームレートとしても知られる）を有することができる。非圧縮ビデオは、かなりのビットレート要件を有する。例えば、サンプル当たり8ビットの1080p60 4：2：0ビデオ（60 Hzのフレームレートで1920×1080のルミナンスサンプル分解能）は、1．5 Gbit／sに近い帯域幅を必要とする。そのようなビデオの1時間は、600 GByteを超える記憶空間を必要とする。

【0004】

ビデオコーディング及びデコーディングの1つの目的は、圧縮による入力ビデオ信号における冗長性の低減となり得る。圧縮は、前述の帯域幅又は記憶空間要件を場合によっては2桁以上低減するのに役立ち得る。可逆圧縮及び非可逆圧縮の両方、並びに、それらの組み合わせを使用することができる。可逆圧縮とは、元の信号の正確なコピーを圧縮された元の信号から再構成できる技術を指す。非可逆圧縮を使用する場合、再構成された信号は元の信号と同一ではない場合があるが、元の信号と再構成された信号との間の歪みは、再構成された信号を意図された用途にとって役立つようにするのに十分小さい。ビデオの場合、非可逆圧縮が幅広く採用される。許容される歪みの量は用途に依存し、例えば、特定の消費者ストリーミングアプリケーションのユーザは、テレビ貢献アプリケーションのユーザよりも高い歪みを許容し得る。達成可能な圧縮比は、より高い許容／耐容歪みがより高い圧縮比をもたらし得ることを反映することができる。

【0005】

ビデオエンコーダ及びデコーダは、例えば、動き補償、変換、量子化、及び、エントロピーコーディングを含む幾つかの広範なカテゴリーからの技術を利用することができ、それらの幾つかが以下で紹介される。

【0006】

歴史的に、ビデオエンコーダ及びデコーダは、殆どの場合、コーディングされたビデオシーケンス（CVS）、グループオブピクチャ（GOP）、又は、同様のマルチピクチャタイムフレームに関して規定されて変わらない所定のピクチャサイズで動作する傾向があった。例えば、MPEG－2において、システム設計は、シーンのアクティビティなどの要因に応じて水平分解能（それによって、ピクチャサイズ）を変更することが知られているが、Iピクチャにおいてのみであり、したがって一般にGOP用である。CVS内の異なる分解能を使用するための基準ピクチャのリサンプリングは、例えばITU－T Rec．H．263 Annex Pから知られている。しかしながら、ここでは、ピクチャサイズは変化せず、基準ピクチャのみがリサンプリングされ、その結果、潜在的に、ピクチャキャンバスの一部のみが使用される（ダウンサンプリングの場合）、或いは、シーンの一部のみが捕捉される（アップサンプリングの場合）。更に、H．263 Annex Qは、個々のマクロブロックを上方又は下方に（それぞれの次元で）2倍だけリサンプリングできるようにする。この場合も先と同様に、ピクチャサイズが同じままである。マクロブロックのサイズは、H．263では固定され、したがって、シグナリングされる必要がない。

【0007】

予測された画像におけるピクチャサイズの変更は、最新のビデオコーディングにおいてより主流になった。例えば、VP9は、基準ピクチャリサンプリング及びピクチャ全体に関する分解能の変更を可能にする。同様に、VVC（例えば、その全体が本願に組み入れられる、Hendryらの「On adaptive resolution change（ARC）for VVC」、Joint Video Team文書JVET－M 0135－v 1、2019年1月9日－19日を含む）に向けてなされたある提案は、異なる－より高い又はより低い－分解能への基準ピクチャ全体のリサンプリングを可能にする。その文書では、異なる候補分解能が、シーケンスパラメータセット内でコーディングされてピクチャパラメータセット内のピクチャごとの構文要素によって参照されるべく提案される。

【発明の概要】

【課題を解決するための手段】

【0008】

一実施形態では、少なくとも1つのプロセッサを使用してエンコーディングされたビデオビットストリームをデコーディングする方法であって、現在のピクチャを含むコーディングされたビデオシーケンスにおいて一定のピクチャサイズが使用されるかどうかを示す第1のフラグを取得するステップと、一定のピクチャサイズが使用されることを示す第1のフラグに基づいて、基準ピクチャリサンプリングを実行することなく現在のピクチャをデコーディングするステップと、一定のピクチャサイズが使用されないことを示す第1のフラグに基づいて、適合性ウィンドウサイズがシグナリングされるかどうかを示す第2のフラグを取得するステップと、適合性ウィンドウサイズがシグナリングされることを示す第2のフラグに基づいて、適合性ウィンドウサイズを取得するステップと、適合性ウィンドウサイズに基づいて現在のピクチャと基準ピクチャとの間のリサンプリング比率を決定するステップと、リサンプリング比率を用いて現在のピクチャに関して基準ピクチャリサンプリングを実行するステップとを含む方法が提供される。

【0009】

一実施形態では、エンコーディングされたビデオビットストリームをデコーディングするためのデバイスであって、プログラムコードを記憶するように構成される少なくとも1つのメモリと、
前記プログラムコードを読み取って前記プログラムコードにより指示されるように動作するべく構成される少なくとも1つのプロセッサとを備え、プログラムコードは、現在のピクチャを含むコーディングされたビデオシーケンスで一定のピクチャサイズが使用されるかどうかを示す第1のフラグを少なくとも1つのプロセッサに取得させるように構成される第1の取得コードと、一定のピクチャサイズが使用されることを示す第1のフラグに基づいて基準ピクチャリサンプリングを実行することなく現在のピクチャを少なくとも1つのプロセッサにデコーディングさせるように構成されるデコーディングコードと、一定のピクチャサイズが使用されないことを示す第1のフラグに基づいて、適合性ウィンドウサイズがシグナリングされるかどうかを示す第2のフラグを少なくとも1つのプロセッサに取得させるように構成される第2の取得コードと、少なくとも1つのプロセッサに、適合性ウィンドウサイズがシグナリングされることを示す第2のフラグに基づいて適合性ウィンドウサイズを取得させ、適合性ウィンドウサイズに基づいて現在のピクチャと基準ピクチャとの間のリサンプリング比率を決定させ、及び、リサンプリング比率を使用して現在のピクチャに関して基準ピクチャリサンプリングを実行させるように構成される実行コードとを含むデバイスが提供される。

【0010】

一実施形態では、命令を記憶する非一時的コンピュータ可読媒体であって、命令は、エンコーディングされたビデオビットストリームをデコーディングするためのデバイスの1つ以上のプロセッサによって実行されるときに、1つ以上のプロセッサに、現在のピクチャを含むコーディングされたビデオシーケンスで一定のピクチャサイズが使用されるかどうかを示す第1のフラグを取得させ、一定のピクチャサイズが使用されることを示す第1のフラグに基づいて、基準ピクチャリサンプリングを実行することなく現在のピクチャをデコーディングさせ、一定のピクチャサイズが使用されないことを示す第1のフラグに基づいて、適合性ウィンドウサイズがシグナリングされるかどうかを示す第2のフラグを取得させ、適合性ウィンドウサイズがシグナリングされることを示す第2のフラグに基づいて、適合性ウィンドウサイズを取得させ、適合性ウィンドウサイズに基づいて、現在のピクチャと基準ピクチャとの間のリサンプリング比率を決定させ、リサンプリング比率を使用して現在のピクチャに関して基準ピクチャリサンプリングを実行させる、1つ以上の命令を含む、非一時的コンピュータ可読媒体が提供される。

【0011】

開示された主題の更なる特徴、性質、及び、様々な利点は、以下の詳細な説明及び添付図面からより明らかである。

【図面の簡単な説明】

【0012】

【図1】一実施形態に係る通信システムの簡略ブロック図の概略図である。

【図2】一実施形態に係る通信システムの簡略ブロック図の概略図である。

【図3】一実施形態に係るデコーダの簡略ブロック図の概略図である。

【図4】一実施形態に係るエンコーダの簡略ブロック図の概略図である。

【図5】一実施形態に係るARC／RPRパラメータをシグナリングするためのオプションの概略図である。

【図6A】一実施形態に係る構文テーブルの例の概略図である。

【図6B】一実施形態に係る構文テーブルの例の概略図である。

【図7】一実施形態に係るSPSにおけるシグナリングピクチャサイズ及び適合性ウィンドウの概略図である。

【図8】実施形態に係るPPSにおけるシグナリングピクチャサイズ及び適合性ウィンドウの概略図である。

【図9】一実施形態に係るエンコーディングされたビデオビットストリームをデコーディングするためのプロセスの一例のフローチャートである。

【図10】一実施形態に係るコンピュータシステムの概略図である。

【発明を実施するための形態】

【0013】

図1は、本開示の一実施形態に係る通信システム（100）の簡略ブロック図を示す。システム（100）は、ネットワーク（150）を介して相互接続される少なくとも2つの端末（110－120）を含んでもよい。データの一方向の送信に関し、第1の端末（110）は、ネットワーク（150）を介して他の端末（120）に送信するために局所位置でビデオデータをコーディングしてもよい。第2の端末（120）は、ネットワーク（150）から他の端末のコーディングされたビデオデータを受信して、コーディングされたデータをデコーディングするとともに、復元されたビデオデータを表示してもよい。一方向データ送信は、メディアサービングアプリケーションなどにおいて一般的となり得る。

【0014】

図1は、例えばビデオ会議中に起こり得るコーディングされたビデオの双方向送信をサポートするために提供される端末（130、140）の第2の対を示す。データの双方向送信に関して、各端末（130、140）は、ネットワーク（150）を介して他の端末に送信するために局所位置で捕捉されたビデオデータをコーディングしてもよい。また、各端末（130、140）は、他方の端末によって送信されるコーディングされたビデオデータを受信してもよく、コーディングされたデータをデコーディングしてもよく、復元されたビデオデータをローカルディスプレイデバイスで表示してもよい。

【0015】

図1において、端末（110－140）は、サーバ、パーソナルコンピュータ、及び、スマートフォンとして例示されてもよいが、本開示の原理はそのように限定されなくてもよい。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤ、及び／又は、専用ビデオ会議機器を伴う用途を見出す。ネットワーク（150）は、例えば有線及び／又は無線通信ネットワークを含む、コーディングされたビデオデータを端末（110－140）間で伝える任意の数のネットワークを表す。通信ネットワーク（150）は、回路交換チャネル及び／又はパケット交換チャネルでデータをやりとりしてもよい。代表的なネットワークとしては、電気通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、及び／又は、インターネットが挙げられる。本説明の目的のために、ネットワーク（150）のアーキテクチャ及びトポロジーは、本明細書中において以下で説明されなければ、本開示の動作に重要ではない場合がある。

【0016】

図2は、開示された主題に関する用途の一例として、ストリーミング環境におけるビデオエンコーダ及びデコーダの配置を示す。開示された主題は、例えば、ビデオ会議、デジタルTV、CD、DVD、メモリスティックなどを含むデジタル媒体への圧縮ビデオの記憶などを含めて、他のビデオ対応用途にも等しく適用可能となり得る。

【0017】

ストリーミングシステムは、例えば非圧縮ビデオサンプルストリーム（202）を形成するビデオソース（201）、例えばデジタルカメラを含むことができる捕捉サブシステム（213）を含んでもよい。エンコーディングされたビデオビットストリームと比較して高いデータ量を強調するために太線として描かれるそのサンプルストリーム（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として非公式に知られているビデオコーディング規格が開発中である。開示された主題はVVCとの関連で使用され得る。

【0018】

図3は、本開示の一実施形態に係るビデオデコーダ（210）の機能ブロック図となり得る。

【0019】

受信機（310）が、デコーダ（210）によってデコーディングされるべき1つ以上のコーデックビデオシーケンスを受信してもよく、同じ又は他の実施形態では、一度に1つのコーディングされたビデオシーケンスを受信してもよく、この場合、それぞれのコーディングされたビデオシーケンスのデコーディングは、他のコーディングされたビデオシーケンスから独立している。コーディングされたビデオシーケンスは、エンコーディングされたビデオデータを記憶する記憶デバイスへのハードウェア／ソフトウェアリンクであってもよいチャネル（312）から受信されてもよい。受信機（310）は、他のデータ、例えば、コーディングされたオーディオデータ及び／又は補助データストリームを伴うエンコーディングされたビデオデータを受信してもよく、これらのデータは、それらのそれぞれの使用するエンティティ（図示せず）に転送されてもよい。受信機（310）は、コーディングされたビデオシーケンスを他のデータから分離してもよい。ネットワークジッタに対抗するために、バッファメモリ（315）が、受信機（310）とエントロピーデコーダ／パーサ（320）（以下「パーサ」）との間に結合されてもよい。受信機（310）が十分な帯域幅及び制御可能性の記憶／転送デバイスから又はアイソシンクロナスネットワークからデータを受信しているときには、バッファ（315）が必要とされない場合がある又は小さくなり得る。インターネットなどのベストエフォートパケットネットワークで使用するために、バッファ（315）は、必要とされる場合がある、比較的大きくなり得る、及び、好適には適応サイズを有し得る。

【0020】

ビデオデコーダ（210）は、エントロピーコーディングされたビデオシーケンスからシンボル（321）を再構成するためのパーサ（320）を含んでもよい。これらのシンボルのカテゴリーは、デコーダ（210）の動作を管理するために使用される情報、及び、潜在的には、図3に示されたようにデコーダの一体部分ではないがそれに結合され得るディスプレイ（212）などのレンダリングデバイスを制御するための情報を含む。レンダリングデバイスのための制御情報は、補足エンハンスメント情報（SEIメッセージ）又はビデオ使用性情報（VUI）パラメータセット断片（図示せず）の形態であってもよい。パーサ（320）は、受信されるコーディングされたビデオシーケンスを構文解析／エントロピーデコーディングしてもよい。コーディングされたビデオシーケンスのコーディングは、ビデオコーディング技術又は規格に従うことができるとともに、可変長コーディング、ハフマンコーディング、コンテキスト感度を伴う又は伴わない算術コーディングなどを含む、当業者に良く知られている原理に従うことができる。パーサ（320）は、グループに対応する少なくとも1つのパラメータに基づき、コーディングされたビデオシーケンスから、ビデオデコーダ内のピクセルのサブグループのうちの少なくとも1つのためのサブグループパラメータのセットを抽出してもよい。サブグループとしては、グループオブピクチャ（GOP）、ピクチャ、サブピクチャ、タイル、スライス、ブリック、マクロブロック、コーディングツリーユニット（CTU）コーディングユニット（CU）、ブロック、変換ユニット（TU）、予測ユニット（PU）などを挙げることができる。タイルは、ピクチャ内の特定のタイル縦列内及び横列内のCU／CTUの矩形領域を示してもよい。ブリックは、特定のタイル内のCU／CTU横列の矩形領域を示してもよい。スライスは、NALユニットに含まれるピクチャの1つ以上のブリックを示してもよい。サブピクチャは、ピクチャ内の1つ以上のスライスの矩形領域を示してもよい。また、エントロピーデコーダ／パーサは、コーディングされたビデオシーケンスから、変換係数、量子化器パラメータ値、動きベクトルなどのような情報を抽出してもよい。

【0021】

パーサ（320）は、シンボル（321）を形成するために、バッファ（315）から受信されたビデオシーケンスに関してエントロピーデコーディング／構文解析動作を実行してもよい。

【0022】

シンボル（321）の再構成は、コーディングされたビデオピクチャ又はその一部（インターピクチャ及びイントラピクチャ、インターブロック及びイントラブロックなど）のタイプ、及び、他の因子に応じて複数の異なるユニットを含み得る。いずれのユニットがどのように関与するかは、コーディングされたビデオシーケンスからパーサ（320）によって解析されたサブグループ制御情報によって制御され得る。パーサ（320）と以下の複数のユニットとの間のそのようなサブグループ制御情報の流れについては明確にするために描かれない。

【0023】

既に述べた機能ブロックの他に、デコーダ210は、以下に記載されるように概念的に幾つかの機能ユニットに細分化され得る。商業的制約下で行なう実際の実施では、これらのユニットの多くが互いに密接に相互作用して少なくとも部分的に互いに組み込まれ得る。しかしながら、開示された主題を説明する目的で、以下の機能ユニットへの概念的細分化が適切である。

【0024】

第1のユニットがスケーラ／逆変換ユニット（351）である。スケーラ／逆変換ユニット（351）は、いずれの変換を使用すべきか、ブロックサイズ、量子化係数、量子化スケーリング行列などを含む量子化変換係数並びに制御情報をシンボル（321）としてパーサ（320）から受信する。スケーラ／逆変換ユニットは、アグリゲータ（355）に入力され得るサンプル値を含むブロックを出力できる。

【0025】

場合によっては、スケーラ／逆変換（351）の出力サンプルは、イントラコーディングされたブロック、すなわち、既に再構成されたピクチャからの予測情報を使用しないが現在のピクチャの既に再構成された部分からの予測情報を使用することができるブロックに関連し得る。そのような予測情報は、イントラピクチャ予測ユニット（352）によって与えられ得る。場合によっては、イントラピクチャ予測ユニット（352）は、現在の（部分的に再構成された）ピクチャ（358）からフェッチされる周囲の既に再構成された情報を用いて、再構成下のブロックの同じサイズ及び形状のブロックを生成する。アグリゲータ（355）は、場合によっては、サンプル単位で、イントラ予測ユニット（352）が生成した予測情報を、スケーラ／逆変換ユニット（351）により与えられる出力サンプル情報に付加する。

【0026】

他の場合には、スケーラ／逆変換ユニット（351）の出力サンプルは、インターコーディングされた潜在的に動き補償されるブロックに関連し得る。そのような場合、動き補償予測ユニット（353）が、予測のために使用されるサンプルをフェッチするべく基準ピクチャメモリ（357）にアクセスし得る。ブロックに関連するシンボル（321）にしたがってフェッチされたサンプルを動き補償した後、これらのサンプルは、出力サンプル情報を生成するために、アグリゲータ（355）によってスケーラ／逆変換ユニットの出力（この場合、残差サンプル又は残差信号と呼ばれる）に付加され得る。動き補償ユニットが予測サンプルをフェッチする基準ピクチャメモリ形式内のアドレスは、例えばX成分、Y成分、及び、基準ピクチャ成分を有することができるシンボル（321）の形式で動き補償ユニットに利用可能な動きベクトルによって制御され得る。また、動き補償は、サブサンプルの正確な動きベクトルが使用されているときに基準ピクチャメモリからフェッチされるサンプル値の補間、動きベクトル予測メカニズムなどを含むこともできる。

【0027】

アグリゲータ（355）の出力サンプルは、ループフィルタユニット（356）における様々なループフィルタリング技術に晒され得る。ビデオ圧縮技術は、コーディングされたビデオビットストリームに含まれるパラメータによって制御されてパーサ（320）からのシンボル（321）としてループフィルタユニット（356）に利用可能にされるインループフィルタ技術を含むことができるが、コーディングされたピクチャ又はコーディングされたビデオシーケンスの（デコーディング順で）前の部分のデコーディング中に取得されたメタ情報に応答することもでき、並びに、既に再構成されてループフィルタリングされたサンプル値に応答することもできる。

【0028】

ループフィルタユニット（356）の出力は、レンダリングデバイス（212）に出力され得るとともに将来のピクチャ間予測で用いるために基準ピクチャメモリに記憶され得るサンプルストリームとなり得る。

【0029】

特定のコーディングされたピクチャは、完全に再構成された時点で、将来の予測のための基準ピクチャとして使用され得る。コーディングされたピクチャが完全に再構成されて、コーディングされたピクチャが基準ピクチャとして（例えば、パーサ（320）によって）特定されてしまった時点で、現在の基準ピクチャ（358）が基準ピクチャバッファ（357）の一部になることができ、また、後続のコーディングされたピクチャの再構成を開始する前に新しい現在のピクチャメモリが再割り当てされ得る。

【0030】

ビデオデコーダ210は、ITU－T Rec．H．265などの規格において文書化され得る所定のビデオ圧縮技術にしたがってデコーディング動作を実行してもよいコーディングされたビデオシーケンスは、ビデオ圧縮技術文書又は規格において定められるように、特にその中のプロファイル文書で定められるように、それがビデオ圧縮技術又は規格の構文を順守するという意味で、使用されているビデオ圧縮技術又は規格により定められる構文に準拠してもよい。また、コーディングされたビデオシーケンスの複雑さがビデオ圧縮技術又は規格のレベルによって規定される境界内にあることもコンプライアンスのために必要となり得る。場合によっては、レベルが、最大ピクチャサイズ、最大フレームレート、最大再構成サンプルレート（例えば毎秒メガサンプルで測定される）、最大基準ピクチャサイズなどを制限する。レベルによって設定される限界は、場合によっては、仮想基準デコーダ（HRD）仕様とコーディングされたビデオシーケンスにおいてシグナリングされるHRDバッファ管理のためのメタデータとによって更に制限され得る。

【0031】

一実施形態において、受信機（310）は、エンコーディングされたビデオを伴う更なる（冗長な）データを受信してもよい。更なるデータは、コーディングされたビデオシーケンスの一部として含まれてもよい。更なるデータは、データを適切にデコーディングするために及び／又は元のビデオデータをより正確に再構成するためにビデオデコーダ（210）によって使用されてもよい。更なるデータは、例えば、時間、空間、又は、SNR拡張層、冗長スライス、冗長ピクチャ、前方誤り訂正符号などの形態を成すことができる。

【0032】

図4は、本開示の一実施形態に係るビデオエンコーダ（203）の機能ブロック図となり得る。

【0033】

エンコーダ（203）は、エンコーダ（203）によってコーディングされるべきビデオ画像を捕捉し得るビデオソース（201）（エンコーダの一部ではない）からビデオサンプルを受信してもよい。

【0034】

ビデオソース（201）は、任意の適したビット深度（例えば、8ビット、10ビット、12ビット、．．．）、任意の色空間（例えば、BT．601 Y CrCB、RGB、．．．）、及び、任意の適したサンプリング構造（例えば、Y CrCb 4：2：0、Y CrCb 4：4：4）を有することができるデジタルビデオサンプルストリームの形態でエンコーダ（203）によりコーディングされるべきソースビデオシーケンスを与えてもよい。メディアサービングシステムにおいて、ビデオソース（201）は、既に前処理されたビデオを記憶する記憶デバイスであってもよい。ビデオ会議システムにおいて、ビデオソース（203）は、ビデオシーケンスとして局所画像情報を捕捉するカメラであってもよい。ビデオデータは、連続して見たときに動きを与える複数の個々のピクチャとして与えられてもよい。ピクチャ自体は、ピクセルの空間アレイとして編成されてもよく、その場合、各ピクセルは、使用中のサンプリング構造、色空間などに応じて1つ以上のサンプルを含むことができる。当業者であれば、ピクセルとサンプルとの間の関係を容易に理解することができる。以下の説明は、サンプルに焦点を当てる。

【0035】

一実施形態によれば、エンコーダ（203）は、リアルタイムで又は用途によって要求される任意の他の時間制約下で、ソースビデオシーケンスのピクチャをコーディングするとともにコーディングされたビデオシーケンス（443）に圧縮してもよい。適切なコーディング速度を強制することがコントローラ（450）の一機能である。コントローラは、以下に説明されるように他の機能ユニットを制御し、これらのユニットに機能的に結合される。明確にするために結合は描かれない。コントローラによって設定されるパラメータは、レート制御関連パラメータ（ピクチャスキップ、量子化器、レート歪み最適化技術のラムダ値、．．．）、ピクチャサイズ、グループオブピクチャ（GOP）レイアウト、最大動きベクトル探索範囲などを含むことができる。当業者であれば、あるシステム設計のために最適化されたビデオエンコーダ（203）に関連し得るものとしてコントローラ（450）の他の機能を容易に特定することができる。

【0036】

幾つかのビデオエンコーダは、当業者が「コーディングループ」として容易に認識するもので動作する。過度に簡略化された説明として、コーディングループは、エンコーダ（430）のエンコーディング部分（以下、「ソースコーダ」）（コーディングされるべき入力ピクチャと基準ピクチャとに基づいてシンボルを形成することに関与する）と、（開示された主題で考慮されるビデオ圧縮技術では、シンボルとコーディングされたビデオビットストリームとの間の任意の圧縮が可逆的であるため）（リモート）デコーダも形成するサンプルデータを形成するべくシンボルを再構成するエンコーダ（203）に埋め込まれる（ローカル）デコーダ（433）とから成ることができる。その再構成されたサンプルストリームは、基準ピクチャメモリ（434）に入力される。シンボルストリームのデコーディングはデコーダ位置（ローカル又はリモート）とは無関係なビットイグザクト結果をもたらすため、基準ピクチャバッファコンテンツもローカルエンコーダとリモートエンコーダとの間でビットイグザクトである。言い換えると、エンコーダの予測部分は、デコーディング中に予測を使用するときにデコーダが「見る」のと全く同じサンプル値を基準ピクチャサンプルとして「見る」。基準ピクチャ同期性（及び、例えばチャネルエラーに起因して、同期性を維持できない場合には、結果として生じるドリフト）のこの基本原理は、当業者に良く知られている。

【0037】

「ローカル」デコーダ（433）の動作は、図3に関連して既に詳しく前述した「リモート」デコーダ（210）の動作と同じになり得る。しかしながら、図4も簡単に参照すると、シンボルが利用可能であるとともに、エントロピーコーダ（445）及びパーサ（320）によるコーディングされたビデオシーケンスに対するシンボルのエンコーディング／デコーディングは可逆的となり得るため、チャネル（312）、受信機（310）、バッファ（315）、及び、パーサ（320）を含むデコーダ（210）のエントロピーデコーディング部分は、ローカルデコーダ（433）において完全に実施されない場合がある。

【0038】

この時点で成され得る所見は、デコーダ内に存在する構文解析／エントロピーデコーディングを除く任意のデコーダ技術も必然的に対応するエンコーダにおいて実質的に同一の機能形態で存在する必要があるということである。このため、開示された主題はデコーダ動作に焦点を合わせる。エンコーダ技術の説明は、それらが包括的に説明されたデコーダ技術の逆であるため、省略され得る。特定の領域においてのみ、より詳細な説明が必要とされて以下で与えられる。

【0039】

ソースコーダ（430）は、その動作の一部として、「基準フレーム」として指定されたビデオシーケンスからの1つ以上の既にコーディングされたフレームに関連して入力フレームを予測的にコーディングする動き補償された予測コーディングを実行してもよい。このようにして、コーディングエンジン（432）は、入力フレームのピクセルブロックと、入力フレームに対する予測基準として選択され得る基準フレームのピクセルブロックとの間の差をコーディングする。

【0040】

ローカルビデオデコーダ（433）は、ソースコーダ（430）によって形成されるシンボルに基づいて、基準フレームとして指定され得るフレームのコーディングされたビデオデータをデコーディングしてもよい。コーディングエンジン（432）の動作は、好適には非可逆プロセスであってもよい。コーディングされたビデオデータがビデオデコーダ（図4には示されない）でデコーディングされ得る場合、再構成されたビデオシーケンスは、一般に、幾つかのエラーを伴うソースビデオシーケンスのレプリカであってもよい。ローカルビデオデコーダ（433）は、ビデオデコーダによって実行され得るデコーディング処理を基準フレームに関して複製し、また、再構成された基準フレームが基準ピクチャキャッシュ（434）に記憶されるようにしてもよい。このようにして、エンコーダ（203）は、遠端ビデオデコーダ（送信エラーなし）によって取得される再構成された基準フレームとして共通のコンテンツを有する再構成された基準フレームのコピーを局所的に記憶してもよい。

【0041】

予測器（435）は、コーディングエンジン（432）の予測検索を実行してもよい。すなわち、コーディングされるべき新たなフレームに関し、予測器（435）は、（候補基準ピクセルブロックとしての）サンプルデータ、或いは、新たなピクチャに適した予測基準としての機能を果たし得る基準ピクチャ動きベクトル、ブロック形状などの特定のメタデータのための基準ピクチャメモリ（434）を検索してもよい。予測器（435）は、適切な予測基準を見い出すためにサンプルブロック×ピクセルブロック方式で動作してもよい。場合によっては、予測器（435）によって取得される検索結果により決定されるように、入力ピクチャは、基準ピクチャメモリ（434）に記憶される複数の基準ピクチャから引き出される予測基準を有してもよい。

【0042】

コントローラ（450）は、例えば、ビデオデータをエンコーディングするために使用されるパラメータ及びサブグループパラメータの設定を含む、ビデオコーダ（430）のコーディング動作を管理してもよい。

【0043】

前述の全ての機能ユニットの出力は、エントロピーコーダ（445）においてエントロピーコーディングに晒されてもよい。エントロピーコーダは、例えばハフマンコーディング、可変長コーディング、算術コーディングなどのような当業者に知られている技術にしたがってシンボルを無損失圧縮することによって、様々な機能ユニットにより生成されるシンボルをコーディングされたビデオシーケンスに変換する。

【0044】

送信機（440）は、エントロピーコーダ（445）によって形成されるコーディングされたビデオシーケンスをバッファリングして、それを、エンコーディングされたビデオデータを記憶する記憶デバイスへのハードウェア／ソフトウェアリンクであってもよい通信チャネル（460）を介した送信のために前処理してもよい。送信機（440）は、ビデオコーダ（430）からのコーディングされたビデオデータを、送信されるべき他のデータ、例えば、コーディングされたオーディオデータ及び／又は補助データストリーム（図示しないソース）とマージしてもよい。

【0045】

コントローラ（450）は、エンコーダ（203）の動作を管理してもよい。デコーディング中、コントローラ（450）は、それぞれのコーディングされたピクチャに特定のコーディングされたピクチャタイプを割り当ててもよく、これは、それぞれのピクチャに適用され得るコーディング技術に影響を及ぼし得る。例えば、ピクチャは、多くの場合、以下のフレームタイプのうちの1つとして割り当てられてもよい。

【0046】

イントラ画像（Iピクチャ）は、シーケンス内の任意の他のフレームを予測のソースとして使用せずにコーディング及びデコーディングされ得るものであってもよい。幾つかのビデオコーデックは、例えば、独立したデコーダリフレッシュピクチャを含む、異なるタイプのイントラピクチャを可能にする。当業者は、Iピクチャのこれらの変形及びそれらのそれぞれの用途及び特徴を認識している。

【0047】

予測ピクチャ（Pピクチャ）が、各ブロックのサンプル値を予測するために最大で1つの動きベクトル及び基準インデックスを使用するイントラ予測又はインター予測を用いてコーディング及びデコーディングされ得るものであってもよい。

【0048】

双方向予測ピクチャ（Bピクチャ）が、各ブロックのサンプル値を予測するために最大で2つの動きベクトル及び基準インデックスを使用するイントラ予測又はインター予測を用いてコーディング及びデコーディングされ得るものであってもよい。同様に、多重予測ピクチャは、単一のブロックの再構成のために3つ以上の基準ピクチャ及び関連するメタデータを使用することができる。

【0049】

ソースピクチャは、一般に、複数のサンプルブロック（例えば、4×4、8×8、4×8、又は、16×16のブロックのそれぞれ）に空間的に細分化されてブロックごとにコーディングされてもよい。ブロックは、ブロックのそれぞれのピクチャに適用されるコーディング割り当てによって決定されるように他の（既にコーディングされた）ブロックに関連して予測的にコーディングされてもよい。例えば、Iピクチャのブロックは、非予測的にコーディングされてもよく、或いは、同じピクチャの既にコーディングされたブロックに関連して予測的にコーディングされてもよい（空間予測又はイントラ予測）。Pピクチャの画素ブロックは、1つの既にコーディングされた基準ピクチャに関連して空間予測によって又は時間予測によって非予測的にコーディングされてもよい。Bピクチャのブロックは、1つ又は2つの既にコーディングされた基準ピクチャに関連して空間予測によって又は時間予測によって非予測的にコーディングされてもよい。

【0050】

ビデオコーダ（203）は、ITU－T Rec．H．265などの所定のビデオコーディング技術又は規格にしたがってコーディング動作を実行してもよい。ビデオコーダ（203）は、その動作において、入力ビデオシーケンスにおける時間的及び空間的な冗長性を利用する予測コーディング動作を含む、様々な圧縮動作を実行してもよい。したがって、コーディングされたビデオデータは、使用されているビデオコーディング技術又は規格によって定められる構文に準拠し得る。

【0051】

一実施形態において、送信機（440）は、エンコーディングされたビデオを伴う更なるデータを送信してもよい。ビデオコーダ（430）は、コーディングされたビデオシーケンスの一部としてそのようなデータを含んでもよい。更なるデータは、時間／空間／SNR拡張層、冗長ピクチャ及びスライスなどの他の形態の冗長データ、補足拡張情報（SEI）メッセージ、視覚的有用性情報（VUI）パラメータセット断片などを含んでもよい。

【0052】

最近、複数の意味的に独立したピクチャ部分の単一ビデオピクチャへの圧縮領域集約又は抽出が、幾らかの注目を集めてきた。特に、例えば、360コーディング又は特定の監視用途との関連で、複数の意味的に独立したソースピクチャ（例えば、立方体投影された360シーンの6つの立方体表面又はマルチカメラ監視セットアップの場合の個々のカメラ入力）は、所定の時点における異なるシーンごとのアクティビティに対処するべく別個の適応分解能設定を必要とする場合がある。言い換えると、エンコーダは、所定の時点において、360シーン又は監視シーンの全体を形成する異なる意味的に独立したピクチャに関して異なるリサンプリング係数を使用することを選択できる。単一のピクチャに組み込まれる場合、それは、コーディングされたピクチャの部分に関して、基準ピクチャのリサンプリングが実行されて適応分解能コーディングシグナリングが利用可能であることを必要とする。

【0053】

以下、この説明の残りの部分で参照される幾つかの用語を紹介する。

【0054】

サブピクチャとは、場合によっては、意味的にグループ化されるとともに変更された分解能で独立してコーディングされ得るサンプル、ブロック、マクロブロック、コーディングユニット、又は、同様のエンティティの矩形配置を指す場合がある。1つ以上のサブピクチャが1つのピクチャを形成してもよい。1つ以上のコーディングされたサブピクチャが1つのコーディングされたピクチャを形成してもよい。1つ以上のサブピクチャが1つのピクチャへとアセンブルされてもよく、また、1つ以上のサブピクチャが1つのピクチャから抽出されてもよい。特定の環境において、1つ以上のコーディングされたサブピクチャは、コーディングされたピクチャへとサンプルレベルまでトランスコーディングすることなく圧縮領域でアセンブルされてもよく、また、同じ又は他の場合には、1つ以上のコーディングされたサブピクチャが圧縮領域でコーディングされたピクチャから抽出されてもよい。

【0055】

基準ピクチャリサンプリング（RPR）又は適応分解能変更（ARC）とは、例えば基準ピクチャリサンプリングにより、コーディングされたビデオシーケンス内のピクチャ又はサブピクチャの分解能の変更を可能にするメカニズムを指す場合がある。以後、RPR／ARCパラメータとは、適応分解能変更を実行するために必要とされる制御情報を指し、該情報は、例えば、フィルタパラメータ、スケーリングファクタ、出力及び／又は基準ピクチャの分解能、様々な制御フラグなどを含んでもよい。

【0056】

実施形態では、単一の意味的に独立したコーディングされたビデオピクチャに関してコーディング及びデコーディングが実行されてもよい。独立したRPR／ARCパラメータを伴う複数のサブピクチャのコーディング／デコーディングの意味あい及びその含意される更なる複雑さを説明する前に、RPR／ARCパラメータをシグナリングするためのオプションについて説明するものとする。

【0057】

図5を参照すると、RPR／ARCパラメータをシグナルするための幾つかの実施形態が示される。実施形態のそれぞれにより述べられたように、これらの実施形態は、コーディング効率、複雑さ、及び、アーキテクチャの観点から、特定の利点及び特定の欠点を有し得る。ビデオコーディング規格又は技術は、RPR／ARCパラメータをシグナリングするために、これらの実施形態のうちの1つ以上又は関連技術から知られているオプションを選択してもよい。実施形態は、相互に排他的でなくてもよく、また、用途のニーズ、関連する標準技術、又は、エンコーダの選択に基づいて交換されてもよいと考えられる。

【0058】

RPR／ARCパラメータのクラスは以下を含んでもよい。

【0059】

－X次元及びY次元において別個又は組み合わせられるアップ／ダウンサンプル係数

【0060】

－所定の数のピクチャに関して一定速度のズームイン／アウトを示す、時間次元の付加を伴う、アップ／ダウンサンプル係数

【0061】

－上記の2つのいずれかは、因子を含むテーブルを指すことができる1つ以上のおそらく短い構文要素のコーディングを伴ってもよい。

【0062】

－組み合わされた又は別個での、入力ピクチャ、出力ピクチャ、基準ピクチャ、コーディングされたピクチャのサンプル、ブロック、マクロブロック、コーディングユニット（CU）、又は、任意の他の適切な粒度の単位におけるX次元又はY次元の分解能。2つ以上の分解能（例えば、入力ピクチャにおける分解能、基準ピクチャにおける分解能など）が存在すれば、特定の場合、値の1つのセットが値の他のセットから推測され得る。そのようなものは、例えば、フラグの使用によってゲーティングされ得る。より詳細な例については、以下を参照されたい。

【0063】

－この場合も先と同様に前述したような適切な粒度における、H．263 Annex Pで使用されるものと同様の「ワーピング」座標H．263 Annex Pは、そのようなワーピング座標をコーディングするための1つの効率的な方法を規定するが、おそらく、他の潜在的により効率的な方法を考え出すこともできる。例えば、Annex Pのワーピング座標の可変長可逆「ハフマン」型コーディングは、適切な長さのバイナリコーディングに置き換えることができ、この場合、バイナリコードの長さは、例えば、最大ピクチャサイズの境界外の「ワーピング」を可能にするべく、最大ピクチャサイズから導出され、場合によっては、特定の係数が掛け合わされて特定の値によってオフセットされ得る。

【0064】

－アップサンプルフィルタパラメータ又はダウンサンプルフィルタパラメータ。実施形態では、アップサンプリング及び／又はダウンサンプリングのための単一のフィルタのみが存在してもよい。しかしながら、実施形態では、フィルタ設計においてより高い柔軟性を可能にすることが望ましく、それはフィルタパラメータのシグナリングを必要とし得る。そのようなパラメータが想定し得るフィルタ設計のリスト内のインデックスによって選択されてもよく、フィルタが完全に定められてもよく（例えば、適切なエントロピーコーディング技術を使用して、フィルタ係数のリストによって）、フィルタがアップ／ダウンサンプル比率によって非明示的に選択されて、それに従い、アップ／ダウンサンプル比率が前述のメカニズムのいずれかに基づいてシグナリングされてもよく、以下同様である。

【0065】

以下において、説明は、コードワードによって示される、アップ／ダウンサンプル係数（X次元及びY次元の両方で使用されるべき同じ係数）の有限セットのコーディングを想定する。そのコードワードは、例えば、H．264及びH．265などのビデオコーディング仕様における特定の構文要素に共通の拡張ゴロム符号を使用して、可変長コーディングされてもよい。アップ／ダウンサンプル係数に対する値の1つの適したマッピングは、例えば、表1に従うことができる。

【0066】

【表1】

【0067】

用途のニーズとビデオ圧縮技術又は規格で利用可能なアップスケールメカニズム及びダウンスケールメカニズムの能力とにしたがって多くの同様のマッピングを考え出すことができる。テーブルは、より多くの値に拡張することができる。また、値は、例えばバイナリコーディングを使用して、拡張ゴロム符号以外のエントロピーコーディングメカニズムによって表されてもよい。それは、例えばMANEによって、リサンプリング係数がビデオ処理エンジン（第一に、エンコーダ及びデコーダ）自体の外部で対象であった場合には特定の利点を有し得る。分解能変更が必要とされない状況では、短く、上記のテーブルでは1ビットにすぎない拡張ゴロム符号を選択することができることに留意すべきである。それは、最も一般的な場合にバイナリコードを使用することに優るコーディング効率利点を有することができる。

【0068】

テーブル内のエントリの数、並びに、それらの意味論は、完全に又は部分的に構成可能であってもよい。例えば、テーブルの基本的な概要は、シーケンス又はデコーダパラメータセットなどの「高」パラメータセットで伝えられてもよい。実施形態において、1つ以上のそのようなテーブルは、ビデオコーディング技術又は規格において規定されてもよく、また、例えばデコーダ又はシーケンスパラメータセットによって選択されてもよい。

【0069】

以下、前述のようにコーディングされたアップサンプル／ダウンサンプル係数（ARC情報）がビデオコーディング技術又は標準構文にどのように含まれ得るのかについて説明する。アップ／ダウンサンプルフィルタを制御する1つ又は幾つかのコードワードにも同様の考慮事項が当てはまり得る。フィルタ又は他のデータ構造に関して比較的大量のデータが必要とされる場合の説明については以下を参照されたい。

【0070】

図5に示されるように、H．263 Annex Pは、具体的にはH．263 PLUSPTYPE（503）ヘッダ拡張において、ピクチャヘッダ（501）内への4つのワーピング座標の形態でARC情報（502）を含む。これは、a）利用可能なピクチャヘッダが存在し、b）ARC情報の頻繁な変更が予期される場合に、賢明な設計選択となり得る。しかしながら、H．263型シグナリングを使用する場合のオーバーヘッドは非常に高くなる可能性があり、また、ピクチャヘッダが一時的な性質を有し得るため、スケーリングファクタがピクチャ境界間で関係しない場合がある。

【0071】

同じ又は他の実施形態において、ARCパラメータのシグナリングは、図6A－図6Bに概説されるような詳細な例に従うことができる。図6A－図6Bは、例えば少なくとも1993年からビデオコーディング規格で使用されているように、C型プログラミングにほぼ従う表記法を使用した表現のタイプの構文図を描く。太字の線はビットストリームに存在する構文要素を示し、太字を伴わない線は、多くの場合、制御フロー又は変数の設定を示す。

【0072】

図6Aに示されるように、ピクチャの（場合によっては長方形の）一部分に適用可能なヘッダの典型的な構文構造としてのタイルグループヘッダ（601）は、条件付きで、可変長拡張ゴロム符号化構文要素dec＿pic＿size＿idx（602）（太字で描かれる）を含むことができる。タイルグループヘッダ内のこの構文要素の存在を、適応分解能（603）、ここでは太字で描かれないフラグの値の使用時にゲーティングすることができ、このことは、フラグが構文図内で発生するポイントでフラグがビットストリーム内に存在することを意味する。適応分解能がこのピクチャ又はその一部のために使用されているか否かは、ビットストリームの内部又は外部の任意の高レベル構文構造でシグナリングされ得る。示される例において、適応分解能がこのピクチャ又はその一部のために使用されているか否かは、以下に概説するようにシーケンスパラメータセットでシグナリングされる。

【0073】

図6Bを参照すると、シーケンスパラメータセット（610）の抜粋も示される。示される第1の構文要素はadaptive＿pic＿resolution＿change＿flag（611）である。真である場合、そのフラグは適応分解能の使用を示すことができ、適応分解能は特定の制御情報を必要とする場合がある。この例において、そのような制御情報は、パラメータセット（612）内のif（）文に基づくフラグの値と、タイルグループヘッダ（601）とに基づいて、条件付きで存在する。

【0074】

適応分解能が使用されている場合、この例では、コーディングされるのがサンプル単位の出力分解能である（613）。数字613は、出力ピクチャの分解能を共に規定できる、output＿pic＿width＿in＿luma＿samples及びoutput＿pic＿height＿in＿luma＿samplesの両方を指す。ビデオコーディング技術又は規格における他の場所では、いずれかの値に対する特定の制限を規定できる。例えば、レベル規定は、総出力サンプルの数を制限する場合があり、その数は、出力サンプルの2つの構文要素の値の積となり得る。また、特定のビデオコーディング技術又は規格、或いは、例えばシステム規格などの外部技術又は規格は、番号付け範囲（例えば、一方又は両方の寸法が2の累乗で割り切れなければならない）、或いは、アスペクト比（例えば、幅と高さとが4：3又は16：9などの関係を成さなければならない）を制限する場合がある。そのような制限は、ハードウェア実装を容易にするために又は他の理由で導入されてもよく、当技術分野において良く知られている。

【0075】

特定の用途では、サイズが出力ピクチャサイズであると非明示的に仮定するのではなく特定の基準ピクチャサイズを使用するようにエンコーダがデコーダに指示することが望ましい可能性がある。この例において、構文要素reference＿pic＿size＿present＿flag（614）は、基準ピクチャ寸法（615）（この場合も先と同様に、数字が幅及び高さの両方を指す）の条件付き存在をゲーティングする。

【0076】

最後に、想定し得るデコーディングピクチャの幅及び高さのテーブルが示される。そのようなテーブルは、例えば、テーブル表示（num＿dec＿pic＿size＿in＿luma＿samples＿minus 1）（616）によって表され得る。「minus 1」は、その構文要素の値の解釈を指すことができる。例えば、コーディングされた値が0であれば、1つのテーブルエントリが存在する。値が5であれば、6つのテーブルエントリが存在する。テーブル内のそれぞれの「ライン」に関しては、デコーディングされたピクチャの幅及び高さが其の後に構文（617）に含まれる。

【0077】

タイルグループヘッダ内の構文要素dec＿pic＿size＿idx（602）を使用して提示されたテーブルエントリ（617）をインデックス付けすることができ、それにより、タイルグループごとに異なるデコーディングサイズ－実際にはズーム比－を可能にする。

【0078】

特定のビデオコーディング技術又は規格、例えばVP9は、空間スケーラビリティを可能にするために、（開示された主題とは全く異なってシグナリングされる）特定の形式の基準ピクチャリサンプルを時間スケーラビリティと関連して実施することによって、空間スケーラビリティをサポートする。特に、特定の基準ピクチャは、ARC型技術を使用してより高い分解能にアップサンプリングされて、空間拡張層のベースを形成してもよい。これらのアップサンプリングされたピクチャは、詳細を付加するために、高分解能で通常の予測メカニズムを使用して精緻化され得る。

【0079】

本明細書中で論じられる実施形態は、そのような環境で使用され得る。場合によっては、同じ又は他の実施形態では、NALユニットヘッダ内の値、例えばTemporal IDフィールドを使用して、時間層だけでなく空間層も示すことができる。そうすることは、特定のシステム設計にとって特定の利点を有し得る。例えば、NALユニットヘッダTemporal ID値に基づいて時間層選択転送のために形成されて最適化される既存の選択転送ユニット（SFU）は、スケーラブル環境のために、修正を伴うことなく使用され得る。それを可能にするために、コーディングされたピクチャサイズと時間層との間のマッピングがNALユニットヘッダ内のTemporal IDフィールドによって示されるための要件が存在してもよい。

【0080】

【0081】

実施形態では、再構成されたピクチャの全てのサンプルが出力を意図するとは限らない。エンコーダは、適合性ウィンドウを使用して出力を意図したピクチャの矩形のサブ部分を示すことができる。適合性ウィンドウは、例えば、ピクチャサイズによって規定されるようなピクチャエッジからの左及び右オフセットによって記述され又は示されてもよい。オーバースキャン、マルチビューシステムにおけるビューの空間的アセンブリ、又は、適合性ウィンドウが出力されるべき幾つかのキューブマップ面のうちの1つを示し得る360システムを含む、適合性ウィンドウが関連し得る特定の使用ケースを特定することができる。

【0082】

全ての用途が適合性ウィンドウの使用を必要とするとは限らないため、及び、適合性ウィンドウパラメータが、ビットストリーム内に特定量のビットを必要とする場合があり、したがって、使用されない場合には、コーディング効率を損なう場合があるため、そのようなパラメータの存在がフラグによってゲーティングされてもよい。

【0083】

実施形態において、適合性ウィンドウサイズは、ピクチャパラメータセット（PPS）でシグナリングされてもよい。基準ピクチャの適合性ウィンドウサイズが現在のピクチャの適合性ウィンドウサイズと異なる場合には、適合性ウィンドウサイズを定め得る適合性ウィンドウパラメータがリサンプリング比率を計算するために使用されてもよい。デコーダは、リサンプリングプロセスが必要とされるかどうかを決定するために、各ピクチャの適合性ウィンドウサイズを認識する必要があり得る。リサンプリング比率が1に等しくない場合には、出力ピクチャサイズがCVS内で一定ではなく、ディスプレイのためのアップスケーリング／ダウンスケーリングのような出力ピクチャの特別な取り扱い及び後処理が使用されてもよい。

【0084】

実施形態では、デコーディングされた／出力されたピクチャが同じサイズを有し且つリサンプリング比率がCVS／ビットストリーム内で1に等しいかどうかを示すフラグが、デコーディングパラメータセット（DPS）、ビデオパラメータセット（VPS）、又は、シーケンスパラメータセット（SPS）などの高レベルパラメータセットでシグナリングされてもよい。フラグは、ビデオストリーミングのためのセッションネゴシエーション又はデコーダ及びディスプレイ設定の構成のために使用されてもよい。

【0085】

図7を参照すると、1に等しいフラグconstant＿pic＿size＿flag（704）は、CVS内のピクチャのピクチャサイズが同じであることを示してもよい。0に等しいconstant＿pic＿size＿flagは、CVS内のピクチャのピクチャサイズが同じであってもなくてもよいことを示してもよい。constant＿pic＿size＿flagの値が1に等しければ、フラグsps＿conformance＿window＿flag（705）がSPS（701）内に存在し得る。1に等しいsps＿conformance＿window＿flagは、適合性クロッピングウィンドウオフセットパラメータが適切な位置で、例えば次にSPSにおいて続くことを示してもよい。0に等しいsps＿conformance＿window＿flagは、適合性クロッピングウィンドウオフセットパラメータが存在しないことを示してもよい。

【0086】

実施形態において、sps＿conf＿win＿left＿offset（706）、sps＿conf＿win＿right＿offset（707）、sps＿conf＿win＿top＿offset（708）、及び、sps＿conf＿win＿bottom＿offset（709）は、出力のためのピクチャ座標において定められる矩形領域に関して、デコーディングプロセスから出力されるCVS内のピクチャのサンプルを定めてもよい。

【0087】

実施形態では、構文要素sps＿conf＿win＿left＿offset、sps＿conf＿win＿right＿offset、sps＿conf＿win＿top＿offset、及びsps＿conf＿win＿bottom＿offsetが存在しない場合には、sps＿conf＿win＿left＿offset、sps＿conf＿win＿right＿offset、sps＿conf＿win＿top＿offset、及び、sps＿conf＿win＿bottom＿offsetの値が0に等しいと推測されてもよい。

【0088】

実施形態において、図8を参照すると、pic＿width＿in＿luma＿samples（802）は、ルミナンスサンプルの単位でPPS（801）を参照するそれぞれのデコーディングされたピクチャの幅を定めてもよい。実施形態において、pic＿width＿in＿luma＿samplesは、0に等しくなくてもよく、Max（8、MinCbSizeY）の整数倍であってもよく、pic＿width＿max＿in＿luma＿samples以下であってもよい。存在しない場合、pic＿width＿in＿luma＿samplesの値は、pic＿width＿max＿in＿luma＿samplesに等しいと推測されてもよい。pic＿height＿in＿luma＿samples（803）は、ルミナンスサンプル単位でPPSを参照するそれぞれのデコーディングされたピクチャの高さを定めてもよい。pic＿height＿in＿luma＿samplesは、場合によっては、0に等しくなくてもよく、Max（8、MinCbSizeY）の整数倍であってもよく、pic＿height＿max＿in＿luma＿samples以下であってもよい。存在しない場合、pic＿height＿in＿luma＿samplesの値は、pic＿height＿max＿in＿luma＿samplesに等しいと推測されてもよい。

【0089】

実施形態において、更に図8を参照すると、1に等しいconformance＿window＿flag（804）は、適合性クロッピングウィンドウオフセットパラメータが適切な位置で、例えば次にPPS（801）において続くことを示してもよい。0に等しいconformance＿window＿flagは、適合性クロッピングウィンドウオフセットパラメータが存在しないことを示してもよい。conf＿win＿left＿offset（805）、conf＿win＿right＿offset（806）、conf＿win＿top＿offset（807）、及び、conf＿win＿bottom＿offset（808）は、出力のためにピクチャ座標で定められる矩形領域に関して、デコーディングプロセスから出力されるPPSを参照するピクチャのサンプルを定めてもよい。

【0090】

同じ実施形態において、構文要素conf＿win＿left＿offset，conf＿win＿right＿offset，conf＿win＿top＿offset，及びconf＿win＿bottom＿offsetが存在しない場合、conf＿win＿left＿offset，conf＿win＿right＿offset，conf＿win＿top＿offset，及び、conf＿win＿bottom＿offsetの値は、sps＿conf＿win＿left＿offset，sps＿conf＿win＿right＿offset，sps＿conf＿win＿top＿offset，及び、sps＿conf＿win＿bottom＿offsetの値にそれぞれ等しいと推測されてもよい。

【0091】

実施形態において、適合性クロッピングウィンドウは、SubWidthC＊conf＿win＿left＿offsetからpic＿width＿in＿luma＿samples－（SubWidthC＊conf＿win＿right＿offset＋1）までの水平ピクチャ座標と、SubHeightC＊conf＿win＿top＿offsetからpic＿height＿in＿luma＿samples－（SubHeightC＊conf＿win＿bottom＿offset＋1）までを含めた垂直ピクチャ座標とを伴うルミナンスサンプルを含んでもよい。

【0092】

SubWidthC＊（conf＿win＿left＿offset＋conf＿win＿right＿offset）の値は、pic＿width＿in＿luma＿samples未満であってもよく、SubHeightC＊（conf＿win＿top＿offset＋conf＿win＿bottom＿offset）の値は、pic＿height＿in＿luma＿samples未満であってもよい。

【0093】

変数PicOutputWidthL及びPicOutputHeightLは、以下の式1及び式2に示されるように導出されてもよい。
PicOutputWidthL＝pic＿width＿in＿luma＿samples－SubWidthC＊（conf＿win＿right＿offset＋conf＿win＿left＿offset）（式1）
PicOutputHeightL＝pic＿height＿in＿luma＿samples－SubHeightC＊（conf＿win＿bottom＿offset＋conf＿win＿top＿offset）（式2）

【0094】

実施形態において、基準ピクチャリサンプリングを伴う端数補間プロセスは、以下のように処理されてもよい。

【0095】

このプロセスへの入力は、現在のピクチャの左上ルミナンスサンプルに対する現在のコーディングサブブロックの左上サンプルを定めるルミナンス位置（xSb、ySb）、現在のコーディングサブブロックの幅を定める変数sbWidth、現在のコーディングサブブロックの高さを定める変数sbHeight、動きベクトルオフセットmvOffset、精緻化された動きベクトルrefMvLX、選択された基準ピクチャサンプルアレイrefPicLX、半サンプル補間フィルタインデックスhpelIfIdx、双方向光学フローフラグbdofFlag、及び、現在のブロックの色成分インデックスを定める変数cIdxであってもよい。

【0096】

このプロセスの出力は、予測サンプル値の（sbWidth＋brdExtSize）x（sbHeight＋brdExtSize）アレイpredSamplesLXであってもよい。

【0097】

予測ブロック境界拡張サイズbrdExtSizeは、以下の式3に示されるように導出されてもよい。
brdExtSize＝（bdofFlag｜｜（inter＿affine＿flag［xSb］［ySb］＆＆sps＿affine＿prof＿enabled＿flag））？2：0 （式3）

【0098】

変数fRefWidthは、ルミナンスサンプルにおける基準ピクチャのPicOutputWidthLに等しく設定されてもよい。変数fRefHeightは、ルミナンスサンプルにおける基準ピクチャのPicOutputHeightLに等しく設定されてもよい。動きベクトルmvLXは、（refMvLX－mvOffset）に等しく設定されてもよい。

【0099】

cIdxが0に等しい場合、以下が適用されてもよい。
－スケーリングファクタ及びそれらの固定小数点表示は、以下の式4及び式5にしたがって規定されてもよい。
hori＿scale＿fp＝（（fRefWidth＜＜14）＋（PicOutputWidthL＞＞1））／PicOutputWidthL （式4）
vert＿scale＿fp＝（（fRefHeight＜＜14）＋（PicOutputHeightL＞＞1））／PicOutputHeightL （式5）
－（xIntL、yIntL）をフルサンプル単位で与えられるルミナンス位置としてもよく、（xFracL、yFracL）を1／16サンプル単位で与えられるオフセットしてもよい。これらの変数は、基準サンプルアレイrefPicLX内の分画サンプル位置を定めるためにこの条項で使用され得る。
－基準サンプルパディング（xSbInt_L、ySbInt_L）のための境界ブロックの左上の座標は、（xSb＋（mvLX［0］＞＞4），ySb＋（mvLX［1］＞＞4））に等しく設定されてもよい。
－予測ルミナンスサンプルアレイpredSamplesLX内のそれぞれのルミナンスサンプル位置（x_L＝0．．sbWidth－1＋brdExtSize，yL＝0．．sbHeight－1＋brdExtSize）ごとに、対応する予測ルミナンスサンプル値predSamplesLX［x_L］［y_L］が以下のように導出される。
－（refxSb_L、refySb_L）及び（refx_L，refy_L）を1／16サンプル単位で与えられる動きベクトル（refMvLX、refMvLX）によって指し示されるルミナンス位置とする。変数refxSb_L，refx_L，refySb_L，及びrefy_Lは、以下の式6－9に示されるように導出されてもよい。
refxSb_L＝（（xSb＜＜4）＋refMvLX［0］）＊hori＿scale＿fp （式6）
refx_L＝（（Sign（refxSb）＊（（Abs（refxSb）＋128）＞＞8）
＋x_L＊（（hori＿scale＿fp＋8）＞＞4））＋32）＞＞6 （式7）
refySb_L＝（（ySb＜＜4）＋refMvLX［1］）＊vert＿scale＿fp （式8）
refyL＝（（Sign（refySb）＊（（Abs（refySb）＋128）＞＞8）＋yL＊
（（vert＿scale＿fp＋8）＞＞4））＋32）＞＞6 （式9）
－変数xInt_L、yInt_L、xFrac_L及びyFrac_Lは、以下の式10－13に示されるように導出されてもよい。
xInt_L＝refx_L＞＞4 （式10）
yInt_L＝refy_L＞＞4 （式11）
xFrac_L＝refx_L＆15 （式12）
yFrac_L＝refy_L＆15 （式13）
－bdofFlagがTRUE orに等しい（sps＿affine＿prof＿enabled＿flagがTRUEに等しく、inter＿affine＿flag［xSb］［ySb］がTRUEに等しい）とともに、以下の条件のうちの1つ以上が真である場合、予測ルミナンスサンプル値predSamplesLX［x_L］［y_L］は、入力として（xInt_L＋（xFrac_L＞＞3）－1），yInt_L＋（yFrac_L＞＞3）－1）及びrefPicLXを伴う、ビデオコーディング仕様の適切な条項で定められるルミナンス整数サンプルフェッチングプロセスを呼び出すことによって導出されてもよい。
1．x_Lは0に等しい。
2．x_LはsbWidth＋1に等しい。
3．y_Lは0に等しい。
4．y_LはsbHeight＋1に等しい。
－それ以外の場合、予測ルミナンスサンプル値predSamplesLX［xL］［yL］は、（xIntL－（brdExtSize＞0？を伴うビデオコーディング仕様の適切な条項で定められるルミナンスサンプル8タップ補間フィルタリングプロセスを呼び出すことによって導出されてもよい。1：0），yIntL－（brdExtSize＞0？1：0）），（xFracL，yFracL），（xSbInt_L，ySbInt_L），refPicLX，hpelIfIdx，sbWidth，sbHeight、及び、入力としての（xSb，ySb）

【0100】

それ以外の場合（cIdxが0に等しくない場合）、以下が適用されてもよい：
1．（xIntC，yIntC）をフルサンプル単位で与えられるクロミナンス位置とし、（xFracC，yFracC）を1／32サンプル単位で与えられるオフセットとする。これらの変数は、基準サンプルアレイrefPicLX内の一般的な分画サンプル位置を定めるためにこの条項で使用されてもよい。
2．基準サンプルパディング（xSbIntC、ySbIntC）のための境界ブロックの左上座標は、（（xSb／SubWidthC）＋（mvLX［0］＞＞5）、（ySb／SubHeightC）＋（mvLX［1］＞＞5））に等しく設定される。
3．予測クロミナンスサンプルアレイpredSamplesLX内のそれぞれのクロミナンスサンプル位置（xC＝0．．sbWidth－1，yC＝0．．sbHeight－1）ごとに、対応する予測クロミナンスサンプル値predSamplesLX［xC］［yC］は、以下のように導出されてもよい。
－（refxSb_C，refySb_C）及び（refx_C，refy_C）を、1／32サンプル単位で与えられる動きベクトル（mvLX［0］、mvLX［1］）によって指し示されるクロミナンス位置とする。変数refxSb_C、refySb_C、refx_C及びrefy_Cは、以下の式14－17に示されるように導出されてもよい。
refxSb_C＝（（xSb／SubWidthC＜＜5）＋mvLX［0］）＊hori＿scale＿fp （式14）
refx_C＝（（Sign（refxSb_C）＊（（Abs（refxSb_C）＋256）＞＞9）
＋xC＊（（hori＿scale＿fp＋8）＞＞4））＋16）＞＞5 （式15）
refySb_C＝（（ySb／SubHeightC＜＜5）＋mvLX［1］）＊vert＿scale＿fp （式16）
refy_C＝（（Sign（refySb_C）＊（（Abs（refySb_C）＋256）＞＞9）
＋yC＊（（vert＿scale＿fp＋8）＞＞4））＋16）＞＞5 （式17）
－変数xInt_C、yInt_C、xFrac_C及びyFrac_Cは、以下の式18－21に示されるように導出されてもよい。
xInt_C＝refx_C＞＞5 （式18）
yInt_C＝refy_C＞＞5 （式19）
xFrac_C＝refy_C＆31 （式20）
yFrac_C＝refy_C＆31 （式21）

【0101】

予測サンプル値predSamplesLX［xC］［yC］は、入力としての（xIntC、yIntC）、（xFracC、yFracC）、（xSbIntC、ySbIntC）、sbWidth、sbHeight及びrefPicLXを伴う先に定められたプロセスを呼び出すことによって導出されてもよい。

【0102】

図9は、エンコーディングされたビデオビットストリームをデコーディングするためのプロセス900の一例のフローチャートである。幾つかの実施において、図9の1つ以上のプロセスブロックは、デコーダ210によって実行されてもよい。幾つかの実施において、図9の1つ以上のプロセスブロックは、エンコーダ203など、デコーダ210とは別個の又はデコーダ203を含む他のデバイス又はデバイスのグループによって実行されてもよい。

【0103】

図9に示されるように、プロセス900は、現在のピクチャを含むコーディングされたビデオシーケンスにおいて一定のピクチャサイズが使用されているかどうかを示す第1のフラグを取得する（ブロック910）ことを含んでもよい。

【0104】

図9に更に示されるように、プロセス900は、第1のフラグから、一定のピクチャサイズが使用されるかどうか決定する（ブロック920）ことを含んでもよい。

【0105】

図9に更に示されるように、プロセス900は、一定のピクチャサイズが使用される（ブロック920においてYES）ことを示す第1のフラグに基づいて、基準ピクチャリサンプリングを実行することなく現在のピクチャをデコーディングする（ブロック930）ことを含んでもよい。

【0106】

図9に更に示されるように、一定のピクチャサイズが使用されない（ブロック920においてNO）ことを示す第1のフラグに基づいて、プロセス900は、ブロック940、ブロック950、ブロック960、及び、ブロック970に進んでもよい。

【0107】

図9に更に示されるように、プロセス900は、適合性ウィンドウサイズがシグナリングされるかどうかを示す第2のフラグを取得する（ブロック940）ことを含んでもよい。

【0108】

図9に更に示されるように、プロセス900は、適合性ウィンドウサイズがシグナリングされることを示す第2のフラグに基づき、適合性ウィンドウサイズを取得すること（ブロック950）と、適合性ウィンドウサイズに基づいて現在のピクチャと基準ピクチャとの間のリサンプリング比率を決定すること（ブロック960）と、リサンプリング比率を使用して現在のピクチャに関して基準ピクチャリサンプリングを実行すること（ブロック970）を含んでもよい。

【0109】

一実施形態において、適合性ウィンドウサイズは、現在のピクチャの境界からの少なくとも1つのオフセット距離としてシグナリングされてもよい。

【0110】

一実施形態では、第1のフラグがシーケンスパラメータセット（SPS）でシグナリングされてもよく、また、第2のフラグがSPS及びピクチャパラメータセット（PPS）のうちの1つでシグナリングされてもよい。

【0111】

一実施形態において、第2のフラグは、SPSでシグナリングされてもよく、SPS適合性ウィンドウパラメータがSPSでシグナリングされるかどうかを示してもよい。

【0112】

一実施形態では、SPS適合性ウィンドウパラメータがSPSでシグナリングされることを示す第2のフラグに基づいて、適合性ウィンドウサイズがSPS適合性ウィンドウパラメータに基づいて取得されてもよい。

【0113】

一実施形態では、ピクチャサイズが一定ではないことを示す第1のフラグに基づいて、プロセス900は、PPS適合性ウィンドウパラメータがPPSでシグナリングされるかどうかを示す第3のフラグを取得することを含んでもよい。

【0114】

一実施形態では、SPS適合性ウィンドウパラメータがSPSでシグナリングされることを示す第2のフラグと、PPS適合性ウィンドウパラメータがPPSでシグナリングされないことを示す第3のフラグとに基づき、適合性ウィンドウサイズがSPS適合性ウィンドウパラメータに基づいて取得されてもよい。

【0115】

一実施形態では、SPS適合性ウィンドウパラメータがSPSでシグナリングされないことを示す第2のフラグと、PPS適合性ウィンドウパラメータがPPSでシグナリングされることを示す第3のフラグとに基づき、適合性ウィンドウサイズがPPS適合性ウィンドウパラメータに基づいて取得されてもよい。

【0116】

図9はプロセス900のブロックの例を示すが、幾つかの実施において、プロセス900は、付加的なブロック、より少ないブロック、図9に示されるものとは異なるブロック、又は、図9に示されるものとは異なって配置されるブロックを含んでもよい。これに加えて又は代えて、プロセス900のブロックのうちの2つ以上が並行して実行されてもよい。

【0117】

更に、提案された方法は、処理回路（例えば、1つ以上のプロセッサ又は1つ以上の集積回路）によって実施されてもよい。1つの例において、1つ以上のプロセッサは、非一時的コンピュータ可読媒体に記憶されるプログラムを実行して、提案された方法のうちの1つ以上を実行する。

【0118】

前述の技術は、コンピュータ可読命令を使用するとともに1つ以上のコンピュータ可読媒体に物理的に記憶されるコンピュータソフトウェアとして実装され得る。例えば、図10は、開示された主題の特定の実施形態を実施するのに適したコンピュータシステム1000を示す。

【0119】

コンピュータソフトウェアは、任意の適切な機械コード又はコンピュータ言語を使用してコーディング可能であり、任意の適切な機械コード又はコンピュータ言語は、コンピュータ中央処理ユニット（CPU）、グラフィック処理ユニット（GPU）などによって直接に又は解釈やマイクロコード実行などを介して実行され得る命令を含むコードを作成するべくアセンブリ、コンパイル、リンクなどの機構に晒されてもよい。

【0120】

命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲームデバイス、モノのインターネットデバイスなどを含む様々なタイプのコンピュータ又はその構成要素で実行され得る。

【0121】

コンピュータシステム1000に関して図10に示される構成要素は、本質的に例示的であり、本開示の実施形態を実施するコンピュータソフトウェアの使用又は機能の範囲に関する任意の制限を示唆しようとするものではない。構成要素の形態は、コンピュータシステム1000の典型的な実施形態に示される構成要素のいずれか1つ又は組み合わせに関連する任意の依存関係又は要件を有すると解釈されるべきでない。

【0122】

コンピュータシステム1000は、特定のヒューマンインタフェース入力デバイスを含んでもよい。そのようなヒューマンインタフェース入力デバイスは、例えば、触覚入力（キーストローク、スワイプ、データグローブ移動など）、音声入力（例えば、声、拍手）、視覚入力（ジェスチャなど）、嗅覚入力（図示せず）を介した1人以上の人間のユーザによる入力に応答してもよい。ヒューマンインタフェースデバイスは、音声（発話、音楽、周囲音など）、画像（走査画像、静止画像カメラから取得される写真画像など）、ビデオ（2次元ビデオ、立体ビデオを含む3次元ビデオなど）など、必ずしも人間による意識的な入力に直接関連しない特定の媒体を捕捉するために使用することもできる。

【0123】

入力ヒューマンインタフェースデバイスは、キーボード1001、マウス1002、トラックパッド1003、タッチスクリーン1010及び関連するグラフィックスアダプタ1050、データグローブ、ジョイスティック1005、マイクロフォン1006、スキャナ1007、カメラ1008のうちの1つ以上（それぞれのうちの1つのみが描かれる）を含んでもよい。

【0124】

また、コンピュータシステム1000は、特定のヒューマンインタフェース出力デバイスを含んでもよい。そのようなヒューマンインタフェース出力デバイスは、例えば、触覚出力、音、光、及び、匂い／味によって1人又は複数の人間のユーザの感覚を刺激していてもよい。そのようなヒューマンインタフェース出力デバイスとしては、触覚出力デバイス（例えば、タッチスクリーン1010、データグローブ、又は、ジョイスティック1005による触覚フィードバックであるが、入力デバイスとして機能しない触覚フィードバックデバイスも存在し得る）、音声出力デバイス（スピーカ1009、ヘッドホン（図示せず））、視覚出力デバイス（陰極線管（CRT）スクリーン、液晶ディスプレイ（LCD）スクリーン、プラズマスクリーン、有機発光ダイオード（OLED）スクリーンを含むべくスクリーン1010などであり、それぞれがタッチスクリーン入力能力を伴う又は伴わない、それぞれが触覚フィードバック能力を伴う又は伴わない－そのうちの幾つかは、立体出力などの手段を介して二次元視覚出力又は三次元出力を超える出力を出力することが可能であり得る；仮想現実メガネ（図示せず）、ホログラフィックディスプレイ、及び、煙タンク（図示せず））、及び、プリンタ（図示せず）を挙げることができる。

【0125】

また、コンピュータシステム1000は、人間がアクセス可能な記憶デバイス及びCD／DVDなどの媒体を伴うCD／DVD ROM／RW 1020を含む光学媒体1021、サムドライブ1022、リムーバブルハードドライブ又はソリッドステートドライブ1023、テープ及びフロッピー（登録商標）ディスク（図示せず）などのレガシー磁気媒体、セキュリティドングル（図示せず）などの専用ROM／ASIC／PLDベースのデバイスなどのそれらの関連媒体を含むこともできる。

【0126】

また、当業者は、本開示の主題に関連して使用される「コンピュータ可読媒体」という用語が、送信媒体、搬送波、又は、他の一時的信号を包含しないことも理解すべきである。

【0127】

また、コンピュータシステム1000は、1つ以上の通信ネットワーク（1155）に対するインタフェースを含むこともできる。ネットワークは、例えば、無線、有線、光となり得る。ネットワークは、更に、ローカル、広域、メトロポリタン、車両及び産業、リアルタイム、遅延耐性などとなり得る。ネットワークの例としては、イーサネット（登録商標）、無線LANなどのローカルエリアネットワーク、モバイル通信用グローバルシステム（GSM）、第3世代（3G）、第4世代（4G）、第5世代（5G）、ロングタームエボリューション（LTE）などを含むべくセルラーネットワーク、ケーブルTV、衛星TV、及び、地上波放送TVを含むべくテレビ有線又は無線広域デジタルネットワーク、CANBusを含むべく車両及び産業用などが挙げられる。特定のネットワークは、一般に、特定の汎用データポート又は周辺バス（1149）（例えばコンピュータシステム1000のユニバーサルシリアルバス（USB）ポートなど；他のものは、一般に、後述するようにシステムバスに対する取り付けによってコンピュータシステム1000のコアに組み込まれる（例えば、PCコンピュータシステムへのイーサネットインターフェース又はスマートフォンコンピュータシステムへのセルラーネットワークインターフェース）に取り付けられる外部ネットワークインタフェースアダプタ（1154）を必要とする。一例として、ネットワーク1055は、ネットワークインタフェース1054を使用して周辺機器用バス1049に接続されてもよい。これらのネットワークのいずれかを使用して、コンピュータシステム1000は他のエンティティと通信することができる。そのような通信は、例えば、ローカル又は広域デジタルネットワークを使用する他のコンピュータシステムに対して、単方向、受信のみ（例えば、放送TV）、単方向送信のみ（例えば、特定のCANbusデバイスへのCANbus）、又は双方向となり得る。前述したように特定のプロトコル及びプロトコルスタックをそれらのネットワーク及びネットワークインタフェース（1154）のそれぞれで使用することができる。

【0128】

前述のヒューマンインタフェースデバイス、ヒューマンアクセス記憶デバイス、及び、ネットワークインタフェースをコンピュータシステム1000のコア1040に取り付けることができる。

【0129】

コア1040は、1つ以上の中央処理ユニット（CPU）1041、グラフィック処理ユニット（GPU）1042、フィールドプログラマブルゲートエリア（FPGA）1043の形態を成す専用プログラマブル処理ユニット、特定のタスクのためのハードウェアアクセラレータ1044などを含むことができる。これらのデバイスは、リードオンリーメモリ（ROM）1045、ランダムアクセスメモリ（RAM）1046、内部非ユーザアクセス可能ハードドライブなどの内部大容量記憶装置、ソリッドステートドライブ（SSD）など1047と共に、システムバス1048を介して接続されてもよい。幾つかのコンピュータシステムにおいて、システムバス1048は、更なるCPU、GPUなどによって拡張を可能にするべく1つ以上の物理プラグの形態でアクセス可能となり得る。周辺機器は、コアのシステムバス1048に対して直接に又は周辺機器用バス1049を介して取り付けられ得る。周辺バス用のアーキテクチャは、ペリフェラルコンポーネントインターコネクト（PCI）、USBなどを含む。

【0130】

CPU 1041、GPU 1042、FPGA 1043、及び、アクセラレータ1044は、組み合わせて前述のコンピュータコードを構成できる特定の命令を実行することができる。そのコンピュータコードは、ROM 1045又はRAM 1046に記憶され得る。また、移行データをRAM 1046に記憶することもでき、一方、永久データを例えば内部大容量ストレージ1047に記憶することができる。メモリデバイスのいずれかへの高速記憶及び検索は、1つ以上のCPU 1041、GPU 1042、大容量記憶装置1047、ROM 1045、及び、RAM 1046などと密接に関連付けられ得るキャッシュメモリの使用によって可能にされ得る。

【0131】

コンピュータ可読媒体は、様々なコンピュータ実装動作を実行するためのコンピュータコードを有することができる。媒体及びコンピュータコードは、本開示の目的のために特別に設計及び構成されたものであってもよく、或いは、コンピュータソフトウェア技術の当業者に良く知られて利用可能な種類のものであってもよい。

【0132】

限定ではなく、一例として、アーキテクチャ及び具体的にはコア1040を有するコンピュータシステム1000は、1つ以上の有形のコンピュータ可読媒体で具現化されるソフトウェアを実行するプロセッサ（CPU、GPU、FPGA、アクセラレータなどを含む）の結果として機能を与えることができる。そのようなコンピュータ可読媒体は、先に紹介されたようなユーザアクセス可能な大容量記憶装置に関連する媒体の他、コア内部大容量記憶装置1047又はROM 1045などの非一時的な性質をもつコア1040の特定の記憶装置と関連付けられる媒体となり得る。本開示の様々な実施形態を実施するソフトウェアは、そのようなデバイスに記憶されてコア1040により実行され得る。コンピュータ可読媒体は、特定のニーズにしたがって、1つ以上のメモリデバイス又はチップを含むことができる。ソフトウェアにより、コア1040、具体的にはコア内のプロセッサ（CPU、GPU、FPGA等を含む）は、RAM 1046に記憶されたデータ構造を規定すること及びソフトウェアによって規定されたプロセスにしたがってそのようなデータ構造を改変することを含む、本明細書中に記載の特定のプロセス又は特定のプロセスの特定の部分を実行できる。これに加えて又は代えて、コンピュータシステムは、ソフトウェアの代わりに又はソフトウェアと共に動作して本明細書に記載の特定のプロセス又は特定のプロセスの特定の部分を実行できる、ハードワイヤードの或いはさもなければ回路（例えば、アクセラレータ1044）に具現化されるロジックの結果として機能を与えることができる。ソフトウェアへの言及は、適切な場合には、ロジックを包含することができ、逆もまた同様である。コンピュータ可読媒体への言及は、適切な場合には、実行のためのソフトウェアを記憶する回路（集積回路（IC）など）、実行のためのロジックを具現化する回路、又は、これらの両方を包含することができる。本開示は、ハードウェアとソフトウェアとの任意の適した組み合わせを包含する。

【0133】

この開示は幾つかの典型的な実施形態を説明してきたが、本開示の範囲内に入る変更、置換、及び、様々な代替の等価物が存在する。したがって、本明細書に明示的に示されていない又は記載されていないが、本開示の原理を具体化し、したがって、その思想及び範囲内にある多数のシステム及び方法を当業者が考え出すことができることが理解される。

【符号の説明】

【0134】

100 通信システム
110 第1の端末
120 第2の端末
130 端末
140 端末
150 ネットワーク
201 ソース
202 非圧縮ビデオサンプルストリーム
203 エンコーダ
204 ビデオビットストリーム
205 ストリーミングサーバ
207 ビデオビットストリーム
208 ストリーミングクライアント
209 ビデオビットストリーム
210 デコーダ
211 発信ビデオサンプルストリーム
212 ディスプレイ
213 捕捉サブシステム
312 チャネル
310 受信機
315 バッファメモリ
320 パーサ
321 シンボル
351 スケーラ/逆変換ユニット
352 イントラ予測ユニット
353 動き補償予測ユニット
355 アグリゲータ
356 ループフィルタ
357 基準ピクチャバッファ
358 現在のピクチャ
430 ソースコーダ
432 コーティングエンジン
433 デコーダ
434 基準ピクチャメモリ
435 予測器
440 送信機
443 ビデオシーケンス
445 エントロピーコーダ
450 コントローラ
460 チャネル
501 ピクチャヘッダ
502 ARC情報
503 ARC（ワーピング座標）
601 タイルグループヘッダ
602 構文要素dec＿pic＿size＿idx
603 適応分解能
610 シーケンスパラメータセット
612 パラメータセット
613 サンプル単位の出力分解能
614 構文要素reference＿pic＿size＿present＿flag
615 基準ピクチャ寸法
616 テーブル表示（num＿dec＿pic＿size＿in＿luma＿samples＿minus 1）
617 テーブルエントリ
1000 コンピュータシステム
1001 キーボード
1002 マウス
1003 トラックパッド
1005 ジョイスティック
1006 マイクロフォン
1007 スキャナ
1008 カメラ
1009 スピーカ
1010 タッチスクリーン
1020 CD／DVD ROM／RW
1021 光学媒体
1022 サムドライブ
1023 リムーバブルハードドライブ又はソリッドステートドライブ
1040 コア
1041 CPU
1042 GPU
1043 フィールドプログラマブルゲートエリア（FPGA）
1044 ハードウェアアクセラレータ
1045 リードオンリーメモリ（ROM）
1046 ランダムアクセスメモリ（RAM）
1047 内部大容量ストレージ
1048 システムバス
1049 周辺機器用バス
1050 グラフィックスアダプタ
1054 ネットワークインタフェース
1149 周辺バス
1154 外部ネットワークインタフェースアダプタ
1155 通信ネットワーク

【図1】