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

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

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

特許7297929符号化映像ストリームにおける長方形スライス分割を信号送信する方法、コンピュータシステム、およびコンピュータプログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-06-16
(45)【発行日】2023-06-26
(54)【発明の名称】符号化映像ストリームにおける長方形スライス分割を信号送信する方法、コンピュータシステム、およびコンピュータプログラム
(51)【国際特許分類】
   H04N 19/30 20140101AFI20230619BHJP
   H04N 19/70 20140101ALI20230619BHJP
【FI】
H04N19/30
H04N19/70
【請求項の数】 6
(21)【出願番号】P 2021562369
(86)(22)【出願日】2021-02-15
(65)【公表番号】
(43)【公表日】2022-07-01
(86)【国際出願番号】 US2021018101
(87)【国際公開番号】W WO2021202001
(87)【国際公開日】2021-10-07
【審査請求日】2021-10-20
(31)【優先権主張番号】63/003,101
(32)【優先日】2020-03-31
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】17/098,892
(32)【優先日】2020-11-16
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】520353802
【氏名又は名称】テンセント・アメリカ・エルエルシー
(74)【代理人】
【識別番号】100110364
【弁理士】
【氏名又は名称】実広 信哉
(74)【代理人】
【識別番号】100150197
【弁理士】
【氏名又は名称】松尾 直樹
(72)【発明者】
【氏名】ビョンドゥ・チェ
(72)【発明者】
【氏名】シャン・リュウ
(72)【発明者】
【氏名】ステファン・ヴェンガー
【審査官】岩井 健二
(56)【参考文献】
【文献】Ping Wu,AHG9: On indication of rectangular slice height in video subpictures ,Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11,JVET-Q0164,17th Meeting: Brussels, BE,2019年12月,pp.1-12
【文献】Yao-Jen Chang, Vadim Seregin, Muhammed Coban, and Marta Karczewicz,AhG12: On the slice number signaling dependent on subpictures,Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11,JVET-Q0332r2,17th Meeting: Brussels, BE,2020年01月,pp.1-3
【文献】Byeongdoo Cho,i Stephan Wenger, and Shan Liu,AHG9/AHG12: On signaling of subpicture and slice in PPS,Joint Video Experts Team (JVET) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11,JVET-R0117-v2 ,18th Meeting: by teleconference,2020年04月,pp.1-6
(58)【調査した分野】(Int.Cl.,DB名)
H04N 19/00 - 19/98
(57)【特許請求の範囲】
【請求項1】
プロセッサによって実行可能な、映像データを復号する方法であって、
1つ以上のサブピクチャを含む映像データを受信するステップと、
ピクチャとして扱うサブピクチャに対応するフラグ(subpic_treated_as_pic_flag)が設定されていることに基づいて、1つ以上のサブピクチャを含む現ピクチャを決定するステップと、
現ピクチャ内のサブピクチャの数、及び現ピクチャ内の前記サブピクチャの数と現ピクチャ内の長方形スライスの数との間の差であるデルタ値をピクチャパラメータセットで受信するステップと、
前記サブピクチャの数と前記デルタ値とに基づいて、前記長方形スライスの数を導き出すステップと
を含み、
ピクチャがCLVSの第1のピクチャでなく、前記ピクチャ内のサブピクチャのサブピクチャ識別子の値が、同じレイヤにおいて、復号順で前のピクチャのサブピクチャ識別子の値と等しくない場合、ピクチャとして扱うサブピクチャに対応するフラグ(subpic_treated_as_pic_flag)及びサブピクチャにわたるループフィルタリングに対応するフラグ(loop_filter_across_subpic_enabled_flag)が前記サブピクチャに設定される、方法。
【請求項2】
分割が設定されていないピクチャに対応するフラグ(no_pic_partition_flag)に基づいて、前記長方形スライスの数が1と推定される、請求項1に記載の方法。
【請求項3】
サブピクチャ毎に1つのスライスに対応するフラグ(single_slice_per_subpic_flag)が設定されていることに基づいて、前記サブピクチャの数と長方形スライスの数との間の前記デルタ値がゼロと推定される、請求項1に記載の方法。
【請求項4】
前記サブピクチャの数が、前記長方形スライスの数未満である、請求項1に記載の方法。
【請求項5】
映像データを符号化するためのコンピュータシステムであって、前記コンピュータシステムは、
コンピュータプログラムコードを記憶するように構成された、1つ以上のコンピュータ可読非一時的記憶媒体と、
前記コンピュータプログラムコードにアクセスし、前記コンピュータプログラムコードに命令された通りに動作するように構成された、1つ以上のコンピュータプロセッサであって、前記コンピュータプログラムコードが、請求項1から4のいずれか一項に記載の方法を行う、コンピュータプロセッサと
を備える、コンピュータシステム。
【請求項6】
映像データを符号化するためのコンピュータプログラムであって、前記コンピュータプログラムは、1つ以上のコンピュータプロセッサに、請求項1から4のいずれか一項に記載の方法を実行させる
ように構成される、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本出願は、2020年3月31日に出願された米国仮特許出願第63/003,101号、及び米国特許商標庁に2020年11月16日に出願された米国特許出願第17/098,892号の優先権を主張し、これらの特許の開示内容は、参照することによってその全体が本明細書に組み込まれる。
【0002】
開示する主題は、映像符号化及び復号に関し、より詳細には、符号化映像ストリームにおけるスライス分割の信号送信に関する。
【背景技術】
【0003】
動き補償を伴ったインターピクチャ予測を使用する、映像の符号化及び復号は、数十年前から知られている。圧縮されていないデジタル映像は一連のピクチャからなっていてもよく、各ピクチャは、例えば、1920×1080のルミナンスサンプルと、関連するクロミナンスサンプルの空間次元を有する。一連のピクチャは、例えば、1秒毎に60ピクチャ、又は60Hzの固定又は可変のピクチャレート(非公式にはフレームレートとしても知られている)を有することができる。圧縮されていない映像は、かなりのビットレート要件を有する。例えば、サンプル当たり8ビットの1080p60 4:2:0の映像(60 Hzのフレームレートで1920×1080ルミナンスサンプル解像度)は、1.5ギガビット/秒近い帯域幅を必要とする。このような映像は1時間分で、600ギガバイトを超える記憶空間を必要とする。
【0004】
映像の符号化及び復号は、圧縮によって入力映像信号の冗長性を低減することを1つの目的とすることができる。圧縮は、前述した帯域幅又は記憶空間要件を、場合によっては100倍以上低減するのに役立ち得る。可逆圧縮及び非可逆圧縮の両方、並びにこれらの組合せが使用されてもよい。可逆圧縮とは、圧縮された原信号から、原信号の完全なコピーを再構築できる技術のことをいう。非可逆圧縮を使用すると、再構築された信号は原信号と同一にならない場合があるが、原信号と再構築された信号との間の歪みは、再構築された信号が意図した用途に充分に役立つほど小さくなる。映像に関しては、非可逆圧縮が広く使用されている。歪み量は用途に応じて許容され、例えば、いくつかの消費者ストリーミングアプリケーションのユーザは、テレビに寄与するアプリケーションのユーザよりも高次の歪みを許容し得る。達成可能な圧縮比は、可能な/許容可能な歪みが高次になるほど高い圧縮比が得られるということを反映し得る。
【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らによって2019年1月9~19日に発表された、その全体が本開示に組み込まれる’’On adaptive resolution change(ARC)for VVC’’,Joint Video Team document JVET-M0135-v1を含む)によって、参照ピクチャ全体に対して異なる(高解像度又は低解像度の)リサンプリングをすることが可能になっている。当該文書では、シーケンスパラメータセットで符号化される別の候補解像度が示されており、ピクチャパラメータセット内のピクチャ毎の構文要素に言及している。
【発明の概要】
【課題を解決するための手段】
【0008】
実施形態は、映像データを符号化するための方法、システム、及びコンピュータ可読媒体に関する。一態様によれば、映像データを符号化する方法が提供される。本方法は、1つ以上のサブピクチャを含む映像データを受信するステップを含み得る。サブピクチャの数、及びサブピクチャの数と長方形スライスの数との間のデルタ値が信号送信される。長方形スライスの数は、サブピクチャの数とデルタ値とに基づいて導かれる。
【0009】
別の態様によれば、映像データを符号化するコンピュータシステムが提供される。コンピュータシステムは、1つ以上のプロセッサと、1つ以上のコンピュータ可読メモリと、1つ以上のコンピュータ可読有形記憶装置と、1つ以上のメモリの少なくとも1つを介して、1つ以上のプロセッサの少なくとも1つで実行するための、1つ以上の記憶装置の少なくとも1つに記憶されたプログラム命令と、を含んでもよく、これによってコンピュータシステムは、方法を実行することが可能になる。本方法は、1つ以上のサブピクチャを含む映像データを受信するステップを含み得る。サブピクチャの数、及びサブピクチャの数と長方形スライスの数との間のデルタ値が信号送信される。長方形スライスの数は、サブピクチャの数とデルタ値とに基づいて導かれる。
【0010】
さらに別の態様によれば、映像データを符号化するコンピュータ可読媒体が提供される。コンピュータ可読媒体は、1つ以上のコンピュータ可読記憶装置、及び1つ以上の有形記憶装置の少なくとも1つに記憶されたプログラム命令を含んでもよく、プログラム命令はプロセッサによって実行される。プログラム命令は、1つ以上のサブピクチャを含む映像データを受信するステップを含み得る、方法を実行するためのプロセッサによって実行可能である。サブピクチャの数、及びサブピクチャの数と長方形スライスの数との間のデルタ値が信号送信される。長方形スライスの数は、サブピクチャの数とデルタ値とに基づいて導かれる。
【0011】
これらその他の主題、特徴、及び利点は、以下の例示的な実施形態の詳細な説明で明らかにされ、これは添付の図面と併せて読まれるべきである。図は、詳細な説明と併せて、当業者の理解を容易にして分かりやすくするためのものであり、図面のさまざまな特徴は縮尺通りには描かれていない。
【図面の簡単な説明】
【0012】
図1】実施形態による、通信システムの簡素化されたブロック図の概略図である。
図2】実施形態による、通信システムの簡素化されたブロック図の概略図である。
図3】実施形態による、復号器の簡素化されたブロック図の概略図である。
図4】実施形態による、符号器の簡素化されたブロック図の概略図である。
図5】前述した通りに、従来技術又は実施形態に従ってARCパラメータを信号送信するためのオプションの概略図である。
図6】実施形態による、構文テーブルの例である。
図7】実施形態による、コンピュータシステムの概略図である。
図8】適応的解像度変更(adaptive resolution change)を用いたスケーラビリティの予測構造の例である。
図9】実施形態による、構文テーブルの例である。
図10】アクセスユニット毎のPOCサイクルの構文解析及び復号、並びにアクセスユニットカウント値の、簡素化されたブロック図の概略図である。
図11】複数レイヤのサブピクチャを含む、映像ビットストリーム構造の概略図である。
図12】解像度がエンハンスされた、選択したサブピクチャの表示の概略図である。
図13】複数レイヤのサブピクチャを含む映像ビットストリームの、復号及び表示プロセスのブロック図である。
図14】サブピクチャのエンハンスメントレイヤを含む、360度映像表示の概略図である。
図15】サブピクチャのレイアウト情報、並びにその対応するレイヤ及びピクチャの予測構造の例である。
図16】局所領域の空間スケーラビリティのモダリティを有する、サブピクチャのレイアウト情報、並びにその対応するレイヤ及びピクチャの予測構造の例である。
図17】サブピクチャレイアウト情報の構文テーブルの例である。
図18】サブピクチャレイアウト情報用のSEIメッセージの構文テーブルの例である。
図19】出力レイヤ、及び各出力レイヤセットに対するプロファイル/層/レベル情報を示す構文テーブルの例である。
図20】各出力レイヤセットに対して出力レイヤモードがオンであることを示す構文テーブルの例である。
図21】各出力レイヤセットに対する、各レイヤの現在のサブピクチャを示す構文テーブルの例である。
図22】サブピクチャ識別子を示す構文テーブルの例である。
図23】サブピクチャの数を示すSPS構文テーブルの例である。
図24】スライス分割を示すPPS構文テーブルの例である。
図25ピクチャ内のスライスの数を示すPPS構文テーブルの例である。
図26】変更された構文を含む、ピクチャ内のスライスの数を示すPPS構文テーブルの別の例である。
【発明を実施するための形態】
【0013】
本明細書では、特許請求される構造及び方法の詳細な実施形態が開示されるが、開示される実施形態は、さまざまな形態で具体化され得る、特許請求される構造及び方法の単なる例示であることが理解されよう。しかしながら、これらの構造及び方法はさまざまな形態で具体化されてもよく、本明細書に記載されている例示的な実施形態に限定されると解釈されるべきではない。それどころか、これらの例示的な実施形態は、本開示を細心かつ完全にし、当業者に範囲を完全に伝えるために提供される。記述において、提示されている実施形態が不必要に不明瞭になるのを避けるために、よく知られている特徴及び技術の詳細については省略される場合がある。
【0014】
前述したように、圧縮されていないデジタル映像は一連のピクチャからなっていてもよく、各ピクチャは、例えば、1920×1080のルミナンスサンプルと、関連するクロミナンスサンプルの空間次元を有する。一連のピクチャは、例えば、1秒毎に60ピクチャ、又は60Hzの固定又は可変のピクチャレート(非公式にはフレームレートとしても知られている)を有することができる。圧縮されていない映像は、かなりのビットレート要件を有する。例えば、サンプル当たり8ビットの1080p60 4:2:0の映像(60 Hzのフレームレートで1920×1080ルミナンスサンプル解像度)は、1.5ギガビット/秒近い帯域幅を必要とする。このような映像は1時間分で、600ギガバイトを超える記憶空間を必要とする。しかしながら、ピクチャは1つ以上のサブピクチャに分割でき、各サブピクチャは1つ以上のスライスにさらに分割することができる。したがって、より効率的な信号送信方法として、サブピクチャ又はピクチャ毎に分割したスライスを信号送信すれば有利であろう。
【0015】
本明細書では、さまざまな実施形態に従って、方法、装置(システム)、及びコンピュータ可読媒体のフローチャート図及び/又はブロック図を参照しながら態様を説明する。フローチャート図及び/又はブロック図の各ブロック、並びにフローチャート図及び/又はブロック図におけるブロックの組合せは、コンピュータ可読プログラム命令によって実施できることが理解されよう。
【0016】
図1は、本開示の実施形態による、通信システム(100)の簡素化されたブロック図を示す。システム(100)は、ネットワーク(150)を介して相互接続された、少なくとも2つの端末(110、120)を含んでもよい。データの一方向伝送の場合、第1の端末(110)は、ネットワーク(150)を介してもう一方の端末(120)に送信する映像データをローカル位置で符号化してもよい。第2の端末(120)は、ネットワーク(150)からもう一方の端末の符号化された映像データを受信し、符号化されたデータを復号して、回復された映像データを表示してもよい。一方向のデータ伝送は、媒体供給用途などにおいて一般的であろう。
【0017】
図1は、例えば、ビデオ会議中に生じる場合がある、符号化された映像の双方向伝送をサポートするために提供される、第2の対の端末(130、140)を示す。データの双方向伝送の場合、各端末(130、140)は、ネットワーク(150)を介してもう一方の端末に送信する、ローカル位置で捕捉した映像データを符号化してもよい。各端末(130、140)は、もう一方の端末によって送信された符号化された映像データを受信してもよく、符号化されたデータを復号してもよく、かつ回復された映像データをローカルの表示装置に表示してもよい。
【0018】
図1では、端末(110~140)は、サーバ、パソコン、及びスマートフォンとして示されてもよいが、本開示の原理はそのように限定されない場合がある。本開示の実施形態は、ノートパソコン、タブレットコンピュータ、メディアプレーヤ、及び/又は専用のビデオ会議機器にも適用される。ネットワーク(150)は、符号化された映像データを端末(110~140)間に伝達する、例えば有線及び/又は無線通信ネットワークなどを含む任意の数のネットワークを表す。通信ネットワーク(150)は、回線交換チャネル及び/又はパケット交換チャネルでデータを交換してもよい。代表的なネットワークは、電気通信ネットワーク、ローカルエリアネットワーク、広域ネットワーク、及び/又はインターネットを含む。本考察の目的のために、ネットワーク(150)のアーキテクチャ及びトポロジは、以下で説明されない限り、本開示の運用には無関係な場合がある。
【0019】
図2は、開示される主題の適用例として、ストリーミング環境における映像符号器及び復号器の配置を示す。開示される主題は、例えば、ビデオ会議や、デジタルテレビや、CD、DVD、メモリスティックなどのデジタル媒体への圧縮映像の記憶などを含む、他の映像使用用途に等しく適用することができる。
【0020】
ストリーミングシステムは捕捉サブシステム(213)を含んでもよく、捕捉サブシステム(213)は、例えば、圧縮されていない映像サンプルストリーム(202)を作成する、デジタルカメラなどの映像ソース(201)を含むことができる。符号化映像ビットストリームと比較してデータ量が大きいことを強調するために太線で示されているサンプルストリーム(202)は、カメラ(201)に結合された符号器(203)によって処理することができる。以下でより詳細に説明するように、符号器(203)は、開示される主題の態様を可能にする、又は実施するために、ハードウェア、ソフトウェア、又はこれらの組合せを含むことができる。サンプルストリームと比較してデータ量が小さいことを強調するために細線で示されている符号化映像ビットストリーム(204)は、後で使用するためにストリーミングサーバ(205)に記憶することができる。1つ以上のストリーミングクライアント(206、208)は、符号化映像ビットストリーム(204)のコピー(207、209)を検索するために、ストリーミングサーバ(205)にアクセスすることができる。クライアント(206)は、着信した符号化映像ビットストリームのコピー(207)を復号して、発信する映像サンプルストリーム(211)を生成する、映像復号器(210)を含むことができ、映像サンプルストリーム(211)は、表示装置(212)、又は他の表示装置(図示せず)に表示することができる。一部のストリーミングシステムでは、映像ビットストリーム(204、207、209)は、いくつかの映像符号化/圧縮標準に従って符号化することができる。このような標準の例は、ITU-T勧告H.265を含む。非公式には汎用映像符号化(Versatile Video Coding、VVC)として知られる、映像符号化標準が開発中である。開示される主題は、VVCに関連して使用され得る。
【0021】
図3は、1つ以上の実施形態による、映像復号器(210)の機能ブロック図である。
【0022】
受信機(310)は、復号器(210)によって復号される1つ以上のコーデック映像シーケンスを受信してもよく、同一又は別の実施形態では、1つの符号化された映像シーケンスを同時に受信してもよく、符号化された映像シーケンスそれぞれの復号は、他の符号化された映像シーケンスから独立している。符号化された映像シーケンスは、チャネル(312)から受信されてもよく、チャネル(312)は、符号化された映像データを記憶する記憶装置と連結する、ハードウェア/ソフトウェアであってもよい。受信機(310)は、符号化された音声データ及び/又は補助データストリームなどの他のデータとともに符号化された映像データを受信してもよく、これはそれぞれが使用するエンティティ(図示せず)に転送されてもよい。受信機(310)は、符号化された映像シーケンスを他のデータから分離してもよい。ネットワークのジッタに対抗するために、受信機(310)とエントロピー復号器/構文解析器(320)(以下「構文解析器」とする)との間にバッファメモリ(315)が結合されてもよい。受信機(310)が、帯域幅及び制御性が充分な記憶装置/転送装置から、又はアイソシンクロナスネットワークからデータを受信しているときは、バッファ(315)は必要でない場合がある、或いは小さくすることができる。バッファ(315)は、インターネットなどのベストエフォートのパケットネットワークで使用するために必要とされる場合があり、比較的大型で、好適には適応可能なサイズにすることができる。
【0023】
映像復号器(210)は、エントロピー符号化された映像シーケンスからシンボル(321)を再構築するために、構文解析器(320)を備えてもよい。図2に示されていたように、このようなシンボルの分類は、復号器(210)の動作を管理するのに使用される情報、及び復号器の一体部品ではないがこれに結合できる表示装置(212)などの、表示装置を制御するための潜在的な情報を含む。(複数の)表示装置のための制御情報は、補助拡張情報(Supplementary Enhancement Information)(SEIメッセージ)、又は映像有用性情報(Video Usability Information、VUI)パラメータ集合フラグメント(図示せず)の形態にされてもよい。構文解析器(320)は、受信した符号化された映像シーケンスを、構文解析/エントロピー復号してもよい。符号化された映像シーケンスの符号は、映像符号化技術又は標準に従っていてもよく、可変長符号化、ハフマン符号化、文脈従属又は非文脈従属の算術符号化などを含む、当業者によく知られている原理に従っていてもよい。構文解析器(320)は、符号化された映像シーケンスから、グループに対応する少なくとも1つのパラメータに基づいて、映像復号器内の、画素のサブグループの少なくとも1つに対する、一群のサブグループパラメータを抽出してもよい。サブグループは、ピクチャのグループ(GOP)、ピクチャ、タイル、スライス、マクロブロック、符号化ユニット(CU)、ブロック、変換ユニット(TU)、予測ユニット(PU)などを含むことができる。また、エントロピー復号器/構文解析器は、符号化された映像シーケンスから、変換係数、量子化器パラメータ値、動きベクトルなどの情報を抽出してもよい。
【0024】
構文解析器(320)は、シンボル(321)を生成するために、バッファ(315)から受信した映像シーケンスにエントロピー復号/構文解析動作を実行してもよい。
【0025】
シンボル(321)の再構築は、符号化された映像又はその部分の種別(例えば、インターピクチャ及びイントラピクチャ、インターブロック及びイントラブロック)、並びに他の要素に応じて、複数の異なるユニットを含むことができる。どのユニットがどのように含まれるかについては、構文解析器(320)によって符号化された映像シーケンスから構文解析された、サブグループ制御情報によって制御することができる。構文解析器(320)と、以下の複数のユニットとの間のこのようなサブグループ制御情報の流れは、明確にするために図示されていない。
【0026】
すでに述べた機能ブロック以外に、復号器210は、以下で説明するように、概念的にいくつかの機能ユニットに再分割することができる。商業的な制約の下で運用される実際の実施では、このようなユニットの多くは互いに密接に相互作用し、少なくとも部分的に互いに統合することができる。しかしながら、開示する主題を説明する目的のためには、以下の機能ユニットに概念的に再分割するのが適切である。
【0027】
第1のユニットは、スケーラ/逆変換ユニット(351)である。スケーラ/逆変換ユニット(351)は、量子化変換係数、並びに制御情報を受信し、これには、構文解析器(320)からの(複数の)シンボル(321)として、使用する変換、ブロックサイズ、量子化因子、量子化スケーリング行列などが含まれている。スケーラ/逆変換ユニット(351)はサンプル値を含むブロックを出力でき、これを集約装置(355)に入力することができる。
【0028】
場合によっては、スケーラ/逆変換(351)の出力サンプルは、イントラ符号化されたブロックに関係することができ、つまり、以前に再構築されたピクチャからの予測情報を使用していないブロックは、現ピクチャの以前に再構築された部分からの予測情報を使用することができる。このような予測情報は、イントラピクチャ予測ユニット(352)によって提供することができる。場合によっては、イントラピクチャ予測ユニット(352)は、現在の(部分的に再構築された)ピクチャ(356)から取り出した、周囲のすでに再構築された情報を使用して、再構築中のブロックと同じサイズ及び形状のブロックを生成する。集約装置(355)は、場合により、イントラ予測ユニット(352)が生成した予測情報をサンプル毎に、スケーラ/逆変換ユニット(351)によって提供された出力サンプル情報に追加する。
【0029】
他の事例では、スケーラ/逆変換ユニット(351)の出力サンプルはインター符号化され、かつ潜在的には動き補償されたブロックに関係することができる。このような事例では、動き補償予測ユニット(353)が、予測に使用するサンプルを取り出すために、参照ピクチャバッファ(357)にアクセスすることができる。ブロックに関連するシンボル(321)に従って、取り出されたサンプルを動き補償した後に、これらのサンプルは、出力サンプル情報を生成するように、集約装置(355)によってスケーラ/逆変換ユニットの出力(この場合は残差サンプル又は残差信号と呼ばれる)に追加することができる。動き補償ユニットが予測サンプルを取り出す参照ピクチャメモリ内のアドレスは、動きベクトルによって制御することができ、シンボル(321)の形態で動き補償ユニットに使用可能で、例えば、X、Y、及び参照ピクチャ成分を有することができる。また動き補償は、サブサンプルの正確な動きベクトルが使用されているときに参照ピクチャメモリから取り出されたサンプル値の補間、動きベクトル予測機構などを含むことができる。
【0030】
集約装置(355)の出力サンプルは、ループフィルタユニット(356)のさまざまなループフィルタリング技術にかけることができる。映像圧縮技術は、符号化映像ビットストリームに含まれるパラメータによって制御され、構文解析器(320)からのシンボル(321)としてループフィルタユニット(356)に対して使用可能になる、ループ内フィルタ技術を含むことができるが、さらに、符号化されたピクチャ又は符号化された映像シーケンスの以前の(復号順で)部分の復号中に取得されたメタ情報にも応答し、同様に以前に再構築されてループフィルタリングされたサンプル値にも応答することができる。
【0031】
ループフィルタユニット(356)の出力は、表示装置(212)に出力でき、かつ以後のインターピクチャ予測に使用するために参照ピクチャバッファ(357)に記憶できる、サンプルストリームであってもよい。
【0032】
いくつかの符号化ピクチャは、いったん完全に再構築されると、以後の予測用の参照ピクチャとして使用することができる。符号化ピクチャが完全に再構築され、符号化されたピクチャが(例えば、構文解析器(320)によって)参照ピクチャとして特定されていると、現在の参照ピクチャ(356)が参照ピクチャバッファ(357)の一部になることができ、後続の符号化されたピクチャの再構築を開始する前に、新しい現ピクチャメモリを再配分することができる。
【0033】
映像復号器210は、ITU-T Rec.H.265などの標準に記述され得る所定の映像圧縮技術に従って、復号動作を実行してもよい。符号化された映像シーケンスは、映像圧縮技術又は標準の構文を遵守しているという意味において、映像圧縮技術文書又は標準で、かつ具体的にはそこに記述されているプロファイルで指定される通りに、使用される映像圧縮技術又は標準によって指定される構文に従っているといえる。遵守のためにさらに必要なことは、符号化された映像シーケンスの複雑性が、映像圧縮技術又は標準のレベルによって規定される範囲内にあることであろう。場合によっては、水準によって最大ピクチャサイズ、最大フレームレート、最大再構築サンプルレート(例えば、メガサンプル/秒で測定される)、最大参照ピクチャサイズなどが制限される。レベルによって設定される制限は、場合によっては、仮想参照復号器(Hypothetical Reference Decoder、HRD)仕様、及び符号化された映像シーケンスで信号送信されたHRDバッファ管理のメタデータによってさらに制限される可能性がある。
【0034】
一実施形態では、受信機(310)は、符号化された映像とともに追加(冗長)データを受信してもよい。追加データは、(複数の)符号化された映像シーケンスの一部として含められてもよい。追加データは、映像復号器(210)によって、データを適切に復号するため、かつ/又は元の映像データをより正確に再構築するために使用されてもよい。追加データは、例えば、時間的、空間的、又はSNRエンハンスメントレイヤ、冗長スライス、冗長ピクチャ、転送エラー修正コードなどの形態であってもよい。
【0035】
図4は、本開示の実施形態による、映像符号器(203)の機能ブロック図である。
【0036】
符号器(203)は、符号器(203)によって符号化される映像を捕捉し得る映像ソース(201)(符号器の一部ではない)から、映像サンプルを受信してもよい。
【0037】
映像ソース(201)は、符号器(203)によって符号化されるソース映像シーケンスを、任意の適切なビット深度(8ビット、10ビット、12ビット~など)、任意の色空間(BT.601 Y CrCB、RGBなど)、及び任意の適切なサンプリング構造(Y CrCb 4:2:0、Y CrCb 4:4:4など)にすることが可能なデジタル映像サンプルストリームの形態で提供し得る。媒体供給システムでは、映像ソース(201)は、以前に準備した映像を記憶している記憶装置であってもよい。ビデオ会議システムでは、映像ソース(203)は、ローカル画像情報を映像シーケンスとして捕捉するカメラであってもよい。映像データは、シーケンスで見たときに動きを伝える複数の個別のピクチャとして提供されてもよい。ピクチャ自体は画素の空間的配列として編成されてもよく、各画素は、使用時のサンプリング構造、色空間などに応じて1つ以上のサンプルを含むことができる。当業者であれば、画素とサンプルとの関係を容易に理解できるであろう。以下、サンプルを中心に説明する。
【0038】
一実施形態によれば、符号器(203)は、リアルタイムで、又は用途によって必要とされる他の時間制約下で、ソース映像シーケンスのピクチャを符号化し圧縮して、符号化された映像シーケンス(443)にし得る。適切な符号化速度にすることが、コントローラ(450)の1つの機能である。コントローラは、後述するように他の機能ユニットを制御し、かつこれらのユニットに機能的に結合される。明確にするために、結合については図示しない。コントローラによって設定されたパラメータは、レート制御関連パラメータ(ピクチャスキップ、量子化、レート-歪み最適化技術のラムダ値など)、ピクチャサイズ、ピクチャのグループ(GOP)のレイアウト、最大動きベクトル検索範囲などを含むことができる。当業者であれば、コントローラ(450)の他の機能は、いくつかのシステム設計用に最適化された映像符号器(203)に関連し得るため、容易に特定することができる。
【0039】
いくつかの映像符号器は、当業者には「符号化ループ」として容易に認識されるもので動作する。過度に単純化した説明になるが、符号化ループは、符号器(430)(以後「ソース符号器」)(符号化される入力ピクチャ、及び(複数の)参照ピクチャに基づくシンボルの生成に関与する)の符号化部と、(シンボル及び符号化映像ビットストリーム間の圧縮は、開示されている主題で考慮される映像圧縮技術において可逆であるために)(リモート)復号器も生成するであろうサンプルデータを生成するために、シンボルを再構築する符号器(203)に組み込まれた、(ローカル)復号器(433)と、からなっていてもよい。再構築されたサンプルストリームは、参照ピクチャメモリ(434)に入力される。シンボルストリームの復号が、復号器の位置(ローカル又はリモート)とは無関係に、結果としてビットパーフェクト(bit-exact)になると、参照ピクチャバッファのコンテンツもまた、ローカル符号器とリモート符号器との間でビットパーフェクトになる。言い換えれば、符号器の予測部は、参照ピクチャサンプルを、復号中に予測を使用しているときに復号器が「みなす」ものとまったく同じサンプル値と「みなす」。参照ピクチャ共時性のこの基本原理(及び、例えばチャネルエラーのために共時性を維持できない場合は、結果として生じるドリフト)は、当業者にはよく知られている。
【0040】
「ローカル」復号器(433)の動作は、「リモート」復号器(210)と同じであってもよく、これについては、図3に関連してすでに詳細に上述した。しかしながら、一時的に図3も参照すると、シンボルが使用可能であり、かつエントロピー符号器(445)及び構文解析器(320)によって、シンボルを符号化された映像シーケンスに可逆的に符号化/復号できるので、チャネル(312)、受信機(310)、バッファ(315)、及び構文解析器(320)を含む復号器(210)のエントロピー復号部は、ローカル復号器(433)で完全に実施されなくてもよい。
【0041】
現時点で考えられることは、復号器内に存在する、構文解析/エントロピー復号を除く復号器技術はいずれも、対応する符号器内にもほぼ同一の機能的形態で存在することが当然必要になる。このため、開示される主題は復号器の動作に重点を置いている。符号器技術の説明は、包括的に述べられている復号器技術の逆なので、省略することができる。いくつかの領域においてのみ、より詳細な説明が必要とされ以下で説明される。
【0042】
ソース符号器(430)は、その動作の一部として動き補償された予測符号化を実行してもよく、「参照フレーム」として指定された映像シーケンスから、1つ以上の以前に符号化されたフレームに関して、入力フレームを予測的に符号化する。この方法では、符号化エンジン(432)は、入力フレームの画素ブロックと、入力フレームに対する(複数の)予測参照として選択され得る(複数の)参照フレームの画素ブロックとの差異を符号化する。
【0043】
ローカル映像復号器(433)は、ソース符号器(430)によって生成されたシンボルに基づいて、参照フレームとして指定され得るフレームの符号化された映像データを復号してもよい。符号化エンジン(432)の動作は、好適には非可逆の工程であってもよい。符号化された映像データが、映像復号器(図4には図示せず)で復号されてもよいときは、再構築された映像シーケンスは、通常はいくつかのエラーを伴う、ソース映像シーケンスの複製であってもよい。ローカル映像復号器(433)は、映像復号器によって参照フレームに対して実行されてもよく、かつ再構築された参照フレームが参照ピクチャキャッシュ(434)に記憶されるようにし得る、復号工程を複製する。この方法では、符号器(203)は、遠端の映像復号器(伝送エラーのない)によって取得される、再構築された参照フレームと共通のコンテンツを有する、再構築された参照フレームのコピーを局所的に記憶してもよい。
【0044】
予測子(435)は、符号化エンジン(432)用の予測検索を実行してもよい。つまり、予測子(435)は、符号化される新しいフレームに対して、参照ピクチャメモリ(434)からサンプルデータ(候補参照画素ブロックとしての)、又は参照ピクチャ動きベクトル、ブロック形状などのいくつかのメタデータを検索してもよく、これは新しいピクチャの適切な予測参照として機能する。予測子(435)は、適切な予測参照を見つけるために、ブロック×画素ブロックを基準として、サンプルで動作してもよい。場合によっては、予測子(435)によって取得された検索結果によって決定されるように、入力ピクチャは、参照ピクチャメモリ(434)に記憶された複数の参照ピクチャから引き出された予測参照を有してもよい。
【0045】
コントローラ(450)は、例えば、映像データの符号化に使用される、パラメータ及びサブグループパラメータの設定を含む、映像符号器(430)の符号化動作を管理してもよい。
【0046】
前述した全機能ユニットの出力は、エントロピー符号器(445)でエントロピー符号化されてもよい。エントロピー符号器は、さまざまな機能ユニットによって生成されると、ハフマン符号化、可変長符号化、算術符号化などとして当業者に知られている技術でシンボルを可逆圧縮することによって、シンボルを符号化された映像シーケンスに変換する。
【0047】
送信機(440)は、通信チャネル(460)を介した送信に備えるために、エントロピー符号器(445)によって生成された際に、符号化された映像シーケンスをバッファリングしてもよく、これは、符号化された映像データを記憶する記憶装置に対するハードウェア/ソフトウェア連携であってもよい。送信機(440)は、映像符号器(430)の符号化された映像データを、送信される他のデータ、例えば、符号化された音声データ及び/又は補助データストリーム(ソースは図示せず)とマージしてもよい。
【0048】
コントローラ(450)は、符号器(203)の動作を管理してもよい。符号化中に、コントローラ(450)は、符号化されたピクチャのそれぞれにいくつかの符号化ピクチャ種別を割り当ててもよく、これは、各ピクチャに適用され得る符号化技術に影響を及ぼす場合がある。例えば、ピクチャは、以下のフレーム種別のうちの1つに割り当てられることが多い。
【0049】
イントラピクチャ(Iピクチャ)は、予測のソースとしてシーケンス内の他のフレームを使用せずに符号化及び復号され得るものである。いくつかの映像コーデックは、例えば、即時復号器リフレッシュ(Independent Decoder Refresh)ピクチャを含む、異なる種類のイントラピクチャを許容する。当業者には、このようなIピクチャの変形、並びにその各用途及び特徴が知られている。
【0050】
予測ピクチャ(Pピクチャ)は、各ブロックのサンプル値を予測するために、最大で1つの動きベクトル及び参照インデックスを使用して、イントラ予測又はインター予測を用いて符号化及び復号され得るものである。
【0051】
双方向予測ピクチャ(Bピクチャ)は、各ブロックのサンプル値を予測するために、最大で2つの動きベクトル及び参照インデックスを使用して、イントラ予測又はインター予測を用いて符号化及び復号され得るものである。同様に多重予測ピクチャは、1つのブロックを再構築するために、2つよりも多い参照ピクチャ、及び関連するメタデータを使用することができる。
【0052】
ソースピクチャは、通常は空間的に複数のサンプルブロック(例えば、それぞれ4×4、8×8、4×8、又は16×16サンプルのブロック)に再分割されて、ブロック毎に符号化されてもよい。ブロックは、ブロックの各ピクチャに適用された符号割当てによって決定される際に、他の(すでに符号化された)ブロックを参照して予測的に符号化されてもよい。例えば、Iピクチャのブロックは、非予測的に符号化されてもよく、或いは同じピクチャのすでに符号化されたブロックを参照して、予測的に符号化されてもよい(空間予測又はイントラ予測)。Pピクチャの画素ブロックは、1つの以前に符号化された参照ピクチャを参照して、空間予測によって、又は時間予測によって、非予測的に符号化されてもよい。Bピクチャのブロックは、1つ又は2つの以前に符号化された参照ピクチャを参照して、空間予測によって、又は時間予測によって、非予測的に符号化されてもよい。
【0053】
映像符号器(203)は、ITU-T Rec.H.265などの所定の映像符号化技術又は標準に従って、符号化動作を実行してもよい。その動作において、映像符号器(203)はさまざまな圧縮動作を実行してもよく、これには入力映像シーケンスで時間的及び空間的冗長性を利用する予測符号化動作が含まれる。したがって符号化された映像データは、使用される映像符号化技術又は標準によって指定された構文に従っていてもよい。
【0054】
一実施形態では、送信機(440)は、符号化された映像とともに追加データを送信してもよい。映像符号器(430)は、符号化された映像シーケンスの一部としてこのようなデータを含んでもよい。追加データは、時間/空間/SNRエンハンスメントレイヤ、冗長ピクチャ及びスライス、補助拡張情報(Supplementary Enhancement Information、SEI)メッセージ、視覚的有用性情報(Visual Usability Information、VUI)パラメータ集合フラグメントなどの他の形式の冗長データを含んでもよい。
【0055】
開示されている主題のいくつかの態様をさらに詳しく説明する前に、本明細書の残りの部分で言及されるいくつかの用語について説明しておく必要がある。
【0056】
サブピクチャとは、以後、場合によっては、セマンティックにグループ化された、サンプル、ブロック、マクロブロック、符号化ユニット、又は類似エンティティの長方形配置のことを指し、変更された解像度で独立して符号化されてもよい。1つ以上のサブピクチャが、ピクチャを形成してもよい。1つ以上の符号化サブピクチャが、符号化ピクチャを形成してもよい。1つ以上のサブピクチャが組み合わされてピクチャになってもよく、かつ1つ以上のサブピクチャピクチャから抽出されてもよい。いくつかの実施形態では、サンプルレベルにトランスコードすることなく、圧縮領域で1つ以上の符号化サブピクチャが組み合わされて符号化ピクチャにされてもよく、同じ事例、又はいくつかの他の事例では、圧縮領域で、符号化ピクチャから1つ以上の符号化サブピクチャが抽出されてもよい。
【0057】
適応的解像度変更(Adaptive Resolution Change、ARC)とは、以後、例えば参照ピクチャリサンプリングによって、符号化映像シーケンス内のピクチャ又はサブピクチャの解像度を変更できるようにする機構のことを指す。ARCパラメータとは、以後、適応的解像度変更を実行するのに必要な制御情報のことを指し、これには例えば、フィルタパラメータ、スケーリング係数、出力及び/又は参照ピクチャの解像度、さまざまな制御フラグなどが含まれ得る。
【0058】
上記の説明は、単一の、セマンティックに独立した符号化映像ピクチャの符号化及び復号に重点を置いている。独立したARCパラメータで複数のサブピクチャを符号化/復号することの意味、及びそれが示す複雑性の増加について説明する前に、ARCパラメータを信号送信するためのオプションについて説明する。
【0059】
図5を参照すると、ARCパラメータを信号送信するためのいくつかの新規のオプションが示されている。各オプションに記載されているように、符号化効率、複雑性、及びアーキテクチャの観点から、これらには一定の利点と一定の欠点がある。映像符号化標準又は技術では、ARCパラメータを信号送信するために、これらのオプション、又は従来技術で知られているオプションのうちの1つ以上を選択する場合がある。これらのオプションは相互に排他的とは限らず、場合によっては、用途の必要性、関連する標準技術、又は符号器の選択に基づいて相互に交換されてもよい。
【0060】
ARCパラメータのクラスには、以下のものが含まれ得る。
【0061】
-X及びY次元に分割又は結合される、アップ/ダウンサンプル係数。
【0062】
-時間次元を追加し、所与の数のピクチャに対する一定速度のズームイン/アウトを示す、アップ/ダウンサンプル係数。
【0063】
-上記2つのいずれかは、1つ以上の推定上短い構文要素の符号化を伴う場合があり、これらは係数を含むテーブルを指す場合がある、
【0064】
-結合又は分割された、入力ピクチャ、出力ピクチャ、参照ピクチャ、符号化ピクチャの、サンプル、ブロック、マクロブロック、CU、その他任意の適切な粒状度を単位とする、X又はY次元の解像度。(入力ピクチャに1つ、参照ピクチャに1つなど)解像度が1つより多い場合は、場合によっては、1組の値は、別の組の値から来たものと推定されてもよい。このような場合は、例えば、フラグを使用してゲーティングすることができる。さらに詳細な例については、以下を参照されたい。
【0065】
-これも上述したような適切な粒状度の、H.263 Annex Pで使用されているものと類似の「ワーピング」座標。H.263 Annex Pでは、このようなワーピング座標を符号化するための1つの効率的な方法が定義されているが、場合によっては、他の潜在的により効率的な方法も考えられる。例えば、可変長可逆な、Annex Pのワーピング座標の「ハフマン」方式の符号化は、適切な長さの2値符号化に置き換えることができ、2値符号語の長さは、例えば、最大ピクチャサイズから導かれ、場合によっては、一定の係数を乗じ、一定の値でオフセットすることによって、最大ピクチャサイズの境界の外部での「ワーピング」が可能になる。
【0066】
-アップ又はダウンサンプルフィルタパラメータ。最も簡単な事例では、アップ及び/又はダウンダンプリングに対するフィルタが1つだけあってもよい。しかしながら、場合によっては、フィルタ設計にさらに柔軟性を持たせたほうが有利な場合があり、そのことがフィルタパラメータの信号送信に必要な場合がある。このようなパラメータは、可能なフィルタ設計のリストにあるインデックスによって選択されてもよく、フィルタは、(例えば、適切なエントロピー符号化技術を使用したフィルタ係数のリストによって)完全に指定されてもよく、フィルタは、アップ/ダウンサンプル比によって暗黙的に選択されてもよく、それに応じて、上述した機構などのいずれかに従って順番に信号送信される。
【0067】
以後、符号語によって示される、アップ/ダウンサンプル係数(X次元及びY次元ともに同じ係数を使用する)の有限集合の符号化を想定して説明する。この符号語は、例えば、H.264及びH.265などの映像符号化仕様におけるいくつかの構文要素に共通する指数ゴロム符号を使用して、有利に可変長符号化することができる。アップ/ダウンサンプル係数に対する1つの適切な値のマッピングは、例えば、以下の表に従ったものになり得る。
【0068】
【表1】
【0069】
用途上の必要性、並びに映像圧縮技術又は標準で使用可能なアップスケール及びダウンスケール機構の性能に応じて、同様のマッピングを多数考案することができる。この表は、より多くの値に拡張することができる。値は指数ゴロム符号ではなくエントロピー符号化機構、例えば、2値符号化を使用して表されてもよい。これによりリサンプリング係数が、MANEなど、映像処理エンジン(主に符号器及び復号器)以外で重要になったときに、一定の利点が得られる場合がある。解像度変更を必要としない、最も一般的な事例(と推定される)には短い指数ゴロム符号を選択でき、上記のテーブルではわずか1ビットであることに留意されたい。最も一般的な事例に2値符号を使用することで、符号化効率上の利点が得られる。
【0070】
テーブルの項目数並びにそのセマンティックは、完全に又は部分的に構成可能であってもよい。例えば、テーブルの基本的な概要は、シーケンス又は復号器パラメータセットなどの「高次の」パラメータセットで伝達されてもよい。これに代えて、又はこれに加えて、1つ以上のこのようなテーブルが映像符号化技術又は標準で定義されてもよく、復号器又はシーケンスパラメータセットなどによって選択されてもよい。
【0071】
以後、アップサンプル/ダウンサンプル係数(ARC情報)が、どのようにして上述の通りに符号化されるかについて説明し、これには映像符号化技術又は標準の構文が含まれる場合がある。アップ/ダウンサンプルフィルタを制御する1つ、又はいくつかの符号語に、同様の考察が当てはまる場合がある。フィルタその他のデータ構造に比較的大量のデータが必要とされるときの考察については、以下を参照されたい。
【0072】
H.263 Annex PはARC情報502を4つのワーピング座標の形態、具体的にはH.263 PLUSPTYPE(503)ヘッダ拡張子で、ピクチャヘッダ501に含める。これは、a)使用可能なピクチャヘッダがあり、b)ARC情報の頻繁な変更が予想されるときは、理にかなった設計選択になる可能性がある。しかしながら、H.263方式の信号送信を使用したときのオーバーヘッドが極めて大きくなる場合があり、かつピクチャヘッダが一時的性質を持ち得るために、ピクチャ境界間にスケーリング係数が適用されない場合がある。
【0073】
上述したJVCET-M135-v1は、ピクチャパラメータセット(504)内に配置されたARC参照情報(505)(インデックス)を含み、目標解像度を含むテーブル(506)をインデックス修飾し、これはその後、シーケンスパラメータセット(507)の内部に配置される。シーケンスパラメータセット(507)内のテーブル(506)の可能な解像度の配置は、作成者によって作成された言語的記述に従って、能力交換中の相互運用性のネゴシエーション点として、SPSを使用して位置を調整することができる。解像度は、テーブル(506)内の値によって設定された制限内で、適切なピクチャパラメータセット(504)を参照することによって、ピクチャ毎に変更することができる。
【0074】
図5をさらに参照すると、映像ビットストリームにARC情報を伝達するために、以下の追加のオプションが存在し得る。このような各オプションは、上述したように既存の技術に対していくつかの利点がある。オプションは、同じ映像符号化技術又は標準に同時に存在してもよい。
【0075】
実施形態において、スライスヘッダ、GOBヘッダ、タイルヘッダ、又はタイルグループヘッダ(以後タイルグループヘッダとする)(508)内に、リサンプリング(ズーム)係数などのARC情報(509)が存在してもよい。例えば、先に示したように、単一の可変長ue(v)、又は数ビットの固定長符号語など、ARC情報が小さい場合にはこれで充分であろう。ARC情報がタイルグループヘッダディレクトリ内にあれば、例えば、ピクチャ全体ではなくそのタイルグループで表されるサブピクチャにARC情報が適用可能になるという別の利点がある。また、以下も参照されたい。さらに、映像圧縮技術又は標準が、ピクチャ全体の適応的解像度変更(これと対照的なものとして、例えば、タイルグループに基づく適応的解像度変更がある)しか想定していない場合であっても、タイルグループヘッダの中にARC情報を入れることは、H.263方式のピクチャヘッダの中に入れることに比べて、エラー耐性の観点において一定の利点がある。
【0076】
同じ又は別の実施形態において、ARC情報(512)自体が、ピクチャパラメータセット、ヘッダパラメータセット、タイルパラメータセット、適合パラメータセットなどの適切なパラメータセット(511)内に存在してもよい(適合パラメータセットが図示されている)。そのパラメータセットの範囲は、好適にはピクチャよりも大きくなくてもよく、タイルグループなどにすることができる。ARC情報は、関連するパラメータセットを活動化することによって、暗黙的に使用される。例えば、映像符号化技術又は標準がピクチャに基づくARCのみを想定しているときは、ピクチャパラメータセットやこれと等価のものが適切な場合がある。
【0077】
同じ又は別の実施形態において、タイルグループヘッダ(514)又は類似のデータ構造内に、ARC参照情報(513)が存在してもよい。ARC参照情報(513)は、シーケンスパラメータセット又は復号器パラメータセットなどの、1つのピクチャを超えた範囲のパラメータセット(516)で使用可能な、ARC情報(515)のサブセットを参照することができる。
【0078】
ピクチャパラメータセットは、シーケンスパラメータセットと同様に能力のネゴシエーション又はアナウンスに使用できる(またRFC3984などのいくつかの標準では使用されている)ため、JVET-M0135-v1で使用されているような、タイルグループヘッダ、PPS、SPSからの、別のレベルの間接参照が示すPPSの活動化は不要と思われる。しかしながら、例えば、タイルグループで表されるサブピクチャにもARC情報を適用できるようにする必要がある場合は、適合パラメータセット又はヘッダパラメータセットなど、活動化範囲がタイルグループに限定されているパラメータセットがより良い選択になる場合がある。また、ARC情報が無視できる大きさより大きい場合、例えば、多数のフィルタ係数などのフィルタ制御情報を含む場合は、符号化効率の観点からは、ヘッダ(508)を直接使用するよりもパラメータのほうがより良い選択であり、それは、その後のピクチャ又はサブピクチャが、同じパラメータセットを参照することによって、これらの設定を再使用できることによる。
【0079】
範囲がまたがる複数ピクチャにシーケンスパラメータセット、又は別のより高次のパラメータセットを使用するときは、以下のようないくつかの考察が当てはまる場合がある。
【0080】
1.ARC情報テーブルを記憶するパラメータセット(516)は、場合によっては、シーケンスパラメータセットであってもよいが、それ以外の場合は、復号器パラメータセットが好適である。復号器パラメータセットは、複数のCVS、即ち符号化映像ストリーム、言い換えればセッション開始からセッション分解までの全符号化映像ビットの活動化範囲を含むことができる。考えられるARC要因は復号器機能であり、おそらくハードウェアで実施され、ハードウェア機能はCVSによって変化しない傾向があるため(少なくとも一部の娯楽システムは長さが1秒以下のピクチャのグループである)、このような範囲がより適切であろう。そうではあるものの、シーケンスパラメータセットへのテーブルの挿入は、具体的には以下の第2の項目に関連して、本明細書で説明する配置オプションに明確に含まれている。
【0081】
2.ARC参照情報(513)は、JVCET-M0135-v1におけるようなピクチャパラメータセットの中ではなく、ピクチャ/スライスタイル/GOB/タイルグループヘッダ(以後、タイルグループヘッダとする)(514)の中に直接配置されるのが好適であろう。その理由は、符号器がピクチャパラメータセット内の、ARC参照情報などの1つの値を変更したいときは、新しいPPSを生成して、その新しいPPSを参照しなければならないからである。ARC参照情報のみを変更して、PPS内の量子化マトリックス情報などの他の情報はそのまま残すことを想定している。このような情報はかなりの大きさになる可能性があり、新しいPPSを完成させるために再送信する必要がある。ARC参照情報はテーブル(513)中のインデックスのように単一の符号語であってもよく、これが変化する唯一の値であるため、量子化マトリックス情報などを全て再送信するのは煩雑かつ無駄ということになる。このように、JVET-M0135-v1で提案されているように、PPSによる間接参照を避けることは、符号化効率の観点からかなり優れている可能性がある。同様に、PPSにARC参照情報を挿入することには、ピクチャパラメータセットの活動化の範囲がピクチャであるために、ARC参照情報(513)に参照されるARC情報を、サブピクチャではなく全ピクチャに適用することが必ず必要になるという別の欠点がある。
【0082】
同じ又は別の実施形態において、ARCパラメータの信号送信は、図6に概要が示されているような、詳細な例に従っていてもよい。図6には、少なくとも1993年以降の映像符号化標準で使用されている表現で構文図が記載されている。このような構文図の表記は、概ねCスタイルのプログラミングに従ったものである。太字の行は、ビットストリーム内に存在する構文要素を示し、太字でない行は、主に制御フロー又は変数の設定を示す。
【0083】
ピクチャの(おそらくは長方形の)部分に適用可能な、ヘッダの例示的な構文構造としてのタイルグループヘッダ(601)は、可変長の指数ゴロム符号化構文要素dec_pic_size_idx(602)(太字で記載されている)を条件付きで含むことができる。タイルグループヘッダにおけるこの構文要素の存在は、適応的解像度(603)の使用時にゲーティングされてもよく、ここではフラグの値は太字で記載されていないが、これは、構文図に現れた時点で、そのフラグがビットストリーム内に存在していることを意味する。このピクチャ又はその部分に適応的解像度が使用されているかどうかは、ビットストリーム内外の任意の高位構文構造で信号送信されることができる。図示されている例では、以下で概説するように、シーケンスパラメータセットで信号送信される。
【0084】
図6をさらに参照すると、シーケンスパラメータセット(610)の抜粋がさらに示されている。図示されている第1の構文要素は、adaptive_pic_resolution_change_flag(611)である。真のとき、このフラグは適応的解像度の使用を示すことができ、その後、いくつかの制御情報が必要になる場合がある。例では、このような制御情報は、パラメータセット(612)内のif()文、及びタイルグループヘッダ(601)に基づくフラグの値に基づいて、条件付きで存在する。
【0085】
適応的解像度が使用されているときは、この例では、出力解像度がサンプル単位で符号化される(613)。符号613は、output_pic_width_in_luma_samples及びoutput_pic_height_in_luma_samplesの両方を指し、これらはともに出力ピクチャの解像度を定義することができる。映像符号化技術又は標準のどこかで、いずれかの値に対する一定の制限が定義されている可能性がある。例えば、レベル定義によって総出力サンプル数を制限してもよく、これは、これら2つの構文要素の値の積であってもよい。また、いくつかの映像符号化技術又は標準、或いはシステム標準などの外部技術又は標準では、ナンバリング範囲が制限されたり(例えば、1つ又は2つの寸法が2のべき乗で割り切れなければならない)、或いはアスペクト比が制限されたりする(例えば、幅及び高さが4:3又は16:9などの関係になっていなければならない)場合がある。このような制限は、ハードウェア実装を容易にするため、又は他の理由で導入される場合があり、当業者にはよく知られている。
【0086】
用途によっては、サイズが出力ピクチャサイズになるものと暗黙的に想定するのではなく、符号器が復号器に対して、一定の参照ピクチャサイズを使用するよう命じることが望ましい場合がある。この例では、構文要素reference_pic_size_present_flag(614)が、参照ピクチャ寸法(615)の存在条件をゲーティングする(ここでも符号は高さ及び幅の両方を指す)。
【0087】
最後に、可能な復号ピクチャ幅及び高さのテーブルが示されている。このようなテーブルは、例えば、テーブル表示(num_dec_pic_size_in_luma_samples_minus1)(616)で表すことができる。「minus1」は、その構文要素の値の解釈を指すことができる。例えば、符号化値がゼロであれば、1つのテーブル項目が存在する。値が5であれば、6つのテーブル項目が存在する。次に、テーブル内の各「行」で、復号ピクチャ幅及び高さが構文(617)に含まれる。
【0088】
提示されているテーブル項目(617)は、タイルグループヘッダ内の構文要素dec_pic_size_idx(602)を使用してインデックス修飾でき、これによってタイルグループ毎に別の復号サイズ(実際にはズーム係数)が可能になる。
【0089】
VP9などのいくつかの映像符号化技術又は標準は、空間スケーラビリティが可能になるように、時間スケーラビリティとともに一定の形態の参照ピクチャリサンプリング(開示されている主題とはまったく異なる手法で信号送信される)を実施することによって、空間スケーラビリティをサポートする。特に、いくつかの参照ピクチャは、空間エンハンスメントレイヤの基礎を形成するために、ARC方式の技術を使用して、より高解像度にアップサンプリングされてもよい。このようなアップサンプリングされたピクチャは、細部を追加するために、通常の予測機構を使用して、高解像度で精細化することができる。
【0090】
開示される主題は、このような環境で使用することができる。場合によっては、同じ又は別の実施形態において、時間レイヤだけでなく空間レイヤを示すために、NALユニットヘッダ内の値、例えば、Temporal IDフィールドを使用することができる。そうすることによって、いくつかのシステム設計に一定の利点があり、例えば、NALユニットヘッダのTemporal ID値に基づいて、時間レイヤ選択転送用に生成され最適化された既存の選択転送ユニット(Selected Forwarding Unit、SFU)を、変更せずにスケーラブルな環境用に使用することができる。これを可能にするために、符号化ピクチャサイズと時間レイヤとの間のマッピングが要求される場合があることが、NALユニットヘッダの時間IDフィールドで示されている。
【0091】
一部の映像符号化技術では、アクセスユニット(AU)は、符号化ピクチャ、スライス、タイル、NALユニットなどを指す場合があり、これらは所与の時間に捕捉されて、それぞれピクチャ、スライス、タイル、NALユニットのビットストリームに構成されたものである。その時間とは、構成時間であってもよい。
【0092】
HEVC、その他のいくつかの映像符号化技術では、復号ピクチャバッファ(DPB)内に記憶された複数の参照ピクチャの中から選択した参照ピクチャを示すために、ピクチャ順序カウント(POC)値を使用することができる。アクセスユニット(AU)が1つ以上のピクチャ、スライス、又はタイルを含んでいるときは、同じAUに属する各ピクチャ、スライス、又はタイルは、同じPOC値を持っている場合があり、そこから、それらが同じ構成時間のコンテンツから作成されたことを導き出すことができる。言い換えれば、2つのピクチャ/スライス/タイルが同じ所与のPOC値を持っている状況では、それは2つのピクチャ/スライス/タイルが同じAUに属し、かつ同じ構成時間を有していることを示している可能性がある。逆に、POC値が異なる2つのピクチャ/タイル/スライスは、これらのピクチャ/スライス/タイルが別のAUに属し、かつ構成時間が異なっていることを示している可能性がある。
【0093】
開示されている主題の実施形態において、アクセスユニットが、POC値が異なるピクチャ、スライス、又はタイルを含み得ることによって、前述した固定的な関係を緩和することができる。AU内のPOC値の相違を許容することによって、表示時間が同一の、潜在的に独立して復号可能なピクチャ/スライス/タイルを識別するためにPOC値を使用することが可能になる。次に、以下でさらに詳しく説明するように、参照ピクチャ選択信号送信(例えば、参照ピクチャセット信号送信、又は参照ピクチャリスト信号送信)を変更することなく、複数のスケーラブルレイヤをサポートすることが可能になる。
【0094】
しかしながら、POC値が異なる他のピクチャ/スライス/タイルに対して、ピクチャ/スライス/タイルが属するAUをPOC値のみで識別できることがやはり望ましい。これは、以下で述べる通りに実現することができる。
【0095】
同じ又は他の実施形態において、アクセスユニットカウント(AUC)は、NALユニットヘッダ、スライスヘッダ、タイルグループヘッダ、SEIメッセージ、パラメータセット、又はAUデリミタなどの高位構文構造で信号送信されてもよい。AUCの値は、所与のAUにどのNALユニット、ピクチャ、スライス、又はタイルが属しているかを識別するのに使用され得る。AUCの値は、異なる構成時間インスタンスに対応し得る。AUC値は、POC値の倍数と等しくてもよい。POC値を整数値で割ることによって、AUC値が計算され得る。場合によっては、除算演算は、復号器を実施する際に一定の負荷をかける可能性がある。このような事例では、AUC値のナンバリング空間の制約を小さくすることで、除算演算をシフト演算で代用することが可能になる場合がある。例えば、AUC値は、POC値範囲の最上位ビット(MSB)値と等しくてもよい。
【0096】
同じ実施形態において、AU毎のPOCサイクル(poc_cycle_au)の値は、NALユニットヘッダ、スライスヘッダ、タイルグループヘッダ、SEIメッセージ、パラメータセット、又はAUデリミタなどの高位構文構造で信号送信されてもよい。poc_cycle_auは、異なる連続したPOC値が、同じAUにいくつ関連付けられるかを示し得る。例えば、poc_cycle_auの値が4であれば、POC値が0から3までのピクチャ、スライス、又はタイルはAUC値が0のAUに関連付けられ、POC値が4から7までのピクチャ、スライス、又はタイルは、AUC値が1のAUに関連付けられる。したがって、AUCの値は、POC値をpoc_cycle_auの値で割ることによって推定され得る。
【0097】
同じ又は別の実施形態において、poc_cyle_auの値は、映像パラメータセット(VPS)内などに配置された情報から導かれ得、これは、符号化映像シーケンス内のいくつかの空間レイヤ又はSNRレイヤを識別する。そのような可能な関係について、以下で簡単に説明する。上述の導出により、VPSの数ビットが節約でき、符号化効率が向上する可能性がある一方で、映像パラメータセットの下で階層的に、適切な高位構文構造でpoc_cycle_auを明示的に符号化し、ピクチャなどのビットストリームの所与の小さい部分に対するpoc_cycle_auを、最小化できるようにすれば有利であろう。POC値(及び/又はPOCを間接的に参照する構文要素の値)は下位構文構造で符号化されてもよいため、この最適化によって、上述の導出プロセスによって節約できるものよりも、多くのビットが節約され得る。
【0098】
前述した適応的解像度パラメータを信号送信するための技術は、コンピュータ可読命令を使用するコンピュータソフトウェアとして実施でき、1つ以上のコンピュータ可読媒体に物理的に記憶される。例えば、図7は、開示される主題のいくつかの実施形態の実施に適したコンピュータシステム700を示す。
【0099】
コンピュータソフトウェアは、任意の適切な機械コード又はコンピュータ言語を使用して符号化でき、これは、コンピュータ中央処理ユニット(CPU)、グラフィック処理ユニット(GPU)などによって、直接、又は解釈、マイクロコードの実行などを介して実行できる命令を含むコードを作成するために、アセンブリ、コンパイル、リンクなどの機構に従ってもよい。
【0100】
命令は、パソコン、タブレットコンピュータ、サーバ、スマートフォン、ゲーム機、IoT(internet of things)装置など、さまざまな種類のコンピュータ又はその構成要素で実行することができる。
【0101】
図7に示すコンピュータシステム700の構成要素は本来例示的であって、本開示の実施形態を実施するコンピュータソフトウェアの使用又は機能の範囲に対して、限定を示唆することは意図されていない。構成要素の構成は、コンピュータシステム700の例示的な実施形態に示されている構成要素のいずれか1つ、又は構成要素の組合せに関して、従属性を有するものとも要件を有するものとも解釈されてはならない。
【0102】
コンピュータシステム700は、いくつかの人的インターフェース入力装置を備えてもよい。このような人的インターフェース入力装置は、例えば、触覚入力(キーを押す、スワイプする、データグローブを動かすなど)、音声入力(声、手をたたくなど)、視覚入力(身振りなど)、嗅覚入力(図示せず)による、1人以上のユーザによる入力に応答し得る。人的インターフェース装置は、音声(発話、音楽、周囲音など)、画像(走査画像、静止画像カメラで取得される写真画像など)、映像(二次元映像、立体映像を含む三次元映像など)などの人による意識的な入力に必ずしも直接関与しない、いくつかのメディアの捕捉にさらに使用することができる。
【0103】
入力人的インターフェース装置は、キーボード701、マウス702、トラックパッド703、タッチスクリーン710、データグローブ704、ジョイスティック705、マイク706、スキャナ707、カメラ708のうちの1つ以上を含んでもよい(それぞれ1つのみが図示されている)。
【0104】
コンピュータシステム700は、いくつかの人的インターフェース出力装置を備えてもよい。このような人的インターフェース出力装置は、触覚出力、音声、光、及び臭い/味など、1人以上のユーザの感覚を刺激し得る。このような人的インターフェース出力装置は、触覚出力装置(例えば、タッチスクリーン710、データグローブ704、又はジョイスティック705による触覚フィードバック、ただし入力装置として機能しない触覚フィードバック装置もあり得る)、音声出力装置(スピーカ709、ヘッドホン(図示せず))、視覚出力装置(それぞれがタッチスクリーン入力能力を有するか又は有せず、それぞれが触覚フィードバック能力を有するか又は有せず、そのうちのいくつかは二次元映像出力、又は立体出力などの手段によって三次元を上回る出力を出力可能であってもよい、CRTスクリーン、LCDスクリーン、プラズマスクリーン、OLEDスクリーンを含むスクリーン710など、仮想現実めがね(図示せず)、ホログラフィック表示装置、煙発生装置(smoke tank(図示せず))、並びにプリンタ(図示せず))を含んでもよい。
【0105】
コンピュータシステム700は、人的にアクセス可能な記憶装置、及びCD/DVDなどのメディア721を含むCD/DVD ROM/RW720、USBメモリ(thumb-drive)722、取り外し可能なハードドライブ又はソリッドステートドライブ723、テープ及びフロッピーディスクなどのレガシー磁気メディア(図示せず)、セキュリティドングルなどの専門化されたROM/ASIC/PLDに基づく装置(図示せず)を含む光学メディアなどの、その関連メディアをさらに含むことができる。
【0106】
ここで開示されている主題に関して使用される「コンピュータ可読メディア」という用語は、伝送メディア、搬送波、又はその他の一時的な信号は含まないことを当業者にはさらに理解されたい。
【0107】
コンピュータシステム700は、1つ以上の通信ネットワークに対するインターフェースをさらに備えることができる。ネットワークは、例えば、無線、有線、光であってもよい。ネットワークはさらに、ローカル、広域、メトロポリタン、車載及び産業用、リアルタイム、遅延耐性などであってもよい。ネットワークの例は、イーサネットなどのローカルエリアネットワーク、無線LAN、GSM、3G、4G、5G、LTEなどを含む移動体通信ネットワーク、ケーブルテレビ、衛星テレビ、及び地上波テレビを含む有線テレビ又は無線の広域デジタルネットワーク、車載及びCANBusを含む産業用ネットワークなどを含む。いくつかのネットワークは一般に、いくつかの汎用データポート又は周辺バス749(例えば、コンピュータシステム700のUSBポート)に取り付けられる外部ネットワークインターフェースアダプタを必要とし、他のネットワークは一般に、後述するようにシステムバスに取り付けることによって(例えば、イーサネットインターフェースをPCコンピュータシステムに、又は移動体通信ネットワークインターフェースをスマートフォンのコンピュータシステムに)、コンピュータシステム700のコアに統合される。このような任意のネットワークを使用して、コンピュータシステム700は他のエンティティと通信することができる。このような通信は、一方向通信、受信専用通信(例えば、テレビ放送)、一方向送信専用通信(例えば、CANbusからCANbusに送信する装置)、或いは、例えば、ローカル又は広域デジタルネットワークを使用する、他のコンピュータシステムに対する双方向通信であってもよい。前述したように、いくつかのプロトコル及びプロトコルスタックをこのような各ネットワーク及び各ネットワークインターフェースに使用することができる。
【0108】
前述した人的インターフェース装置、人的にアクセス可能な記憶装置、及びネットワークインターフェースは、コンピュータシステム700のコア740に取り付けることができる。
【0109】
コア740は、1つ以上の中央処理ユニット(CPU)741、グラフィック処理ユニット(GPU)742、FPGA(Field Programmable Gate Areas)の形態の専門化されたプログラム可能処理ユニット743、いくつかのタスク用のハードウェアアクセラレータ744などを含むことができる。このような装置は、読出し専用メモリ(ROM)745、ランダムアクセスメモリ746、内部のユーザがアクセスできないハードドライブ、SSDなど747の内部大容量記憶装置とともに、システムバス748を介して接続されてもよい。いくつかのコンピュータシステムでは、システムバス 748は、追加のCPU、GPUなどによる拡張が可能なように、1つ以上の物理プラグの形態でアクセスすることができる。周辺装置は、コアのシステムバス748に直接取り付ける、又は周辺バス749を介して取り付けることができる。周辺バスのアーキテクチャは、PCI、USBなどを含む。
【0110】
CPU741、GPU742、FPGA743、及びアクセラレータ744は、前述したコンピュータコードを作成できるいくつかの命令を、組み合わせて実行することができる。コンピュータコードは、ROM745又はRAM746に記憶させることができる。過渡的なデータもRAM746に記憶でき、これに反し永続的なデータは、例えば、内部大容量記憶装置747に記憶することができる。キャッシュメモリを使用することによって、任意のメモリ装置に素早く記憶し検索することが可能になり、1つ以上のCPU741、GPU742、大容量記憶装置747、ROM745、RAM746などに密接に関連付けることができる。
【0111】
コンピュータ可読媒体は、さまざまなコンピュータ実施動作を実行するためのコンピュータコードを有することができる。メディア及びコンピュータコードは、本開示の目的のために特別に設計され構築されたものにすることができ、或いはコンピュータソフトウェアの分野の当業者によく知られ、当業者が使用可能な種類のものであってもよい。
【0112】
例として、かつ制限する目的ではなく、アーキテクチャ、具体的にはコア740を有するコンピュータシステム700は、1つ以上の有形のコンピュータ可読媒体に具体化されたソフトウェアを実行する、(複数の)プロセッサ(CPU、GPU、FPGA、アクセラレータなど)の結果としての機能性を提供することができる。このようなコンピュータ可読媒体は、先に紹介したようなユーザがアクセス可能な大容量記憶装置、並びにコア内部大容量記憶装置747又はROM745などの、非一時的な性質を持つ、コア740のいくつかの記憶装置に関連する媒体であってもよい。本開示のさまざまな実施形態を実施するソフトウェアは、このような装置に記憶させて、コア740によって実行することができる。コンピュータ可読メディアは、特定の需要に従って、1つ以上のメモリ装置又はチップを含むことができる。ソフトウェアは、コア740及び具体的にはその中のプロセッサ(CPU、GPU、FPGAなどを含む)に、RAM746に記憶されているデータ構造の定義、及びソフトウェアによって定義された工程に従ったこのようなデータ構造の変更を含む、本明細書で説明する特定の工程、又は特定の工程の特定の部分を実行させることができる。これに加えて、又はこれに代えて、コンピュータシステムは、回路(例えば、アクセラレータ744)に配線された、或いは他の方法で具体化された論理の結果としての機能性を提供でき、本明細書で説明する特定の工程、又は特定の工程の特定の部分を実行するために、ソフトウェアの代わりに、又はソフトウェアとともに動作させることができる。ソフトウェアに対する言及は、必要に応じて論理を包含することができ、その逆もまた可能である。コンピュータ可読メディアに対する言及は、必要に応じて実行するソフトウェアを記憶する(集積回路(IC)などの)回路、実行する論理を具体化する回路、又はその両方を包含することができる。本開示は、ハードウェア及びソフトウェアの任意の適切な組合せを包含する。
【0113】
図8は、temporal_id、layer_id、POC及びAUC値を適応的解像度変更と組み合わせた、映像シーケンス構造の例を示す。この例では、AUC=0の第1のAU内のピクチャ、スライス、又はタイルは、temporal_id=0、及びlayer_id=0又は1を有してもよく、AUC=1の第2のAU内のピクチャ、スライス、又はタイルは、temporal_id=1、及びlayer_id=0又は1をそれぞれ有してもよい。POCの値は、temporal_id及びlayer_idの値とは無関係に、ピクチャ毎に1増加する。この例では、poc_cycle_auの値は2になり得る。好ましくは、poc_cycle_auの値は、(空間スケーラビリティ)レイヤの数と等しくなるように設定されてもよい。したがってこの例では、POCの値は2増加し、AUCの値は1増加する。
【0114】
上述の実施形態では、インターピクチャ又はインターレイヤ予測構造の全て又はサブセット、及び参照ピクチャ表示は、HEVCの既存の参照ピクチャセット(RPS)信号送信、又は参照ピクチャリスト(RPL)信号送信を使用することによってサポートされ得る。RPS又はRPLでは、選択した参照ピクチャは、POCの値、又は現ピクチャと、選択した参照ピクチャとの間のPOCのデルタ値を信号送信することによって表示される。開示されている主題の場合、信号送信を変更することなくインターピクチャ又はインターレイヤ予測構造を表示するためにRPS及びRPLを使用できるが、以下の制限がある。参照ピクチャのtemporal_idの値が、現ピクチャのtemporal_idの値より大きい場合は、現ピクチャは動き補償その他の予測に参照ピクチャを使用しない場合がある。参照ピクチャのlayer_idの値が、現ピクチャのlayer_idの値より大きい場合は、現ピクチャは動き補償又はその他の予測に参照ピクチャを使用しない場合がある。
【0115】
同じ及び他の実施形態において、時間動きベクトル予測に対するPOCの相違に基づく動きベクトルスケーリングが、アクセスユニット内の複数のピクチャにわたって無効にされる場合がある。したがって、アクセスユニット内で各ピクチャのPOC値が異なっていても、動きベクトルはアクセスユニット内でスケーリングされず、時間動きベクトル予測に使用されない。これは、同じAU内のPOCが異なる参照ピクチャが、同じ時間インスタンスを有する参照ピクチャとみなされるためである。したがって、実施形態では、参照ピクチャが、現ピクチャに関連付けられたAUに属しているときは、動きベクトルスケーリング関数は1を返してもよい。
【0116】
同じ及び他の実施形態において、参照ピクチャの空間解像度が現ピクチャの空間解像度とは異なっているときは、時間動きベクトル予測に対するPOCの相違に基づいた動きベクトルスケーリングが、複数のピクチャにわたって任意で無効にされる場合がある。動きベクトルスケーリングが可能なときは、動きベクトルは、現ピクチャと参照ピクチャとの間のPOCの相違、及び空間解像度比の両方に基づいてスケーリングされる。
【0117】
同じ又は別の実施形態において、動きベクトルは、特にpoc_cycle_auの値が一定でないとき(vps_contant_poc_cycle_per_au==0のとき)は、時間動きベクトル予測に対するPOCの相違ではなく、AUCの相違に基づいてスケーリングされてもよい。これに当てはまらない場合(vps_contant_poc_cycle_per_au==1のとき)は、AUCの相違に基づく動きベクトルスケーリングは、POCの相違に基づく動きベクトルスケーリングと同一であってもよい。
【0118】
同じ又は別の実施形態において、AUCの相違に基づいて動きベクトルがスケーリングされると、現ピクチャと同じAU内の参照動きベクトル(同じAUC値を持つ)は、AUCの相違に基づいたスケーリングはされず、現ピクチャと参照ピクチャとの間の空間解像度比に基づいて、スケーリングあり又はスケーリングなしの動きベクトル予測に使用される。
【0119】
同じ又は他の実施形態において、AUC値はAUの境界を識別するために使用され、かつAUの粒状度での入出力タイミングを必要とする、仮想標準復号器(HRD)の動作に使用される。ほとんどの場合、AU内で最高次のレイヤを有する復号ピクチャが表示として出力され得る。出力ピクチャを識別するために、AUC値及びlayer_id値を使用することができる。
【0120】
一実施形態では、ピクチャは1つ以上のサブピクチャからなっていてもよい。各サブピクチャは、ピクチャの局所領域、又は全領域をカバーしてもよい。サブピクチャによってサポートされている領域は、別のサブピクチャによってサポートされている領域と重なってもよく、或いは重ならなくてもよい。1つ以上のサブピクチャで構成されている領域がピクチャの全領域をカバーしてもよく、或いはカバーしなくてもよい。ピクチャがサブピクチャからなっている場合は、サブピクチャによってサポートされる領域は、ピクチャによってサポートされる領域と同一である。
【0121】
同じ実施形態において、サブピクチャは、符号化ピクチャに使用される符号化方法と同様の符号化方法によって符号化されてもよい。サブピクチャは独立して符号化されてもよく、或いは別のサブピクチャ又は符号化ピクチャに応じて符号化されてもよい。サブピクチャは、別のサブピクチャ又は符号化ピクチャに対して、構文解析従属性がある場合もない場合もある。
【0122】
同じ実施形態において、符号化サブピクチャは、1つ以上のレイヤに含まれていてもよい。レイヤ内の符号化サブピクチャは、空間解像度が異なっていてもよい。元のサブピクチャは、空間的にリサンプリング(アップサンプリング又はダウンサンプリング)され、別の空間解像度パラメータで符号化され、レイヤに対応するビットストリームに含まれてもよい。
【0123】
同じ又は別の実施形態において、(W,H)を伴うサブピクチャは、Wはサブピクチャの幅を、Hはサブピクチャの高さをそれぞれ示し、符号化されてレイヤ0に対応する符号化ビットストリーム内に含まれてもよく、元の空間解像度が(W*Sw,k,H*Sh,k)のサブピクチャからアップサンプリング(又はダウンサンプリング)されたサブピクチャは、符号化されてレイヤkに対応する符号化ビットストリーム内に含まれてもよく、ここでSw,k、Sh,kは水平方向及び垂直方向のリサンプリング比を示す。値Sw,k、Sh,kが1より大きい場合は、リサンプリングはアップサンプリングである。これに対し、値Sw,k、Sh,kが1より小さい場合は、リサンプリングはダウンサンプリングである。
【0124】
同じ又は別の実施形態において、同じサブピクチャ又は別のサブピクチャ内で、レイヤ内の符号化サブピクチャが、別のレイヤ内の符号化サブピクチャとは異なる視覚品質を有する場合がある。例えば、レイヤn内のサブピクチャiは、量子化パラメータQi,nで符号化され、レイヤm内のサブピクチャjは、量子化パラメータQj,mで符号化される。
【0125】
同じ又は別の実施形態において、レイヤ内の符号化サブピクチャは独立して復号可能な場合があり、同じ局所領域の別のレイヤ内の符号化サブピクチャに対して、いかなる構文解析従属性又は復号従属性も持たない。同じ局所領域の別のサブピクチャレイヤを参照することなく独立して復号可能であり得るサブピクチャレイヤは、独立サブピクチャレイヤである。独立サブピクチャレイヤ内の符号化サブピクチャは、同じサブピクチャレイヤ内で以前に符号化されたサブピクチャに対し、復号従属性又は構文解析従属性がある場合もない場合もあるが、符号化サブピクチャは、別のサブピクチャレイヤ内の符号化ピクチャに対して、いかなる従属性も持ち得ない。
【0126】
同じ又は別の実施形態において、レイヤ内の符号化サブピクチャは従属的に復号可能な場合があり、同じ局所領域の別のレイヤ内の符号化サブピクチャに対して、何らかの構文解析従属性又は復号従属性を持つ。同じ局所領域の別のサブピクチャレイヤを参照して従属的に復号可能であり得るサブピクチャレイヤは、従属サブピクチャレイヤである。従属サブピクチャ内の符号化サブピクチャは、同じサブピクチャに属する符号化サブピクチャ、同じサブピクチャレイヤ内の以前に符号化されたサブピクチャ、又はこれら両方の参照サブピクチャを参照する場合がある。
【0127】
同じ又は別の実施形態において、符号化サブピクチャは、1つ以上の独立サブピクチャレイヤ、及び1つ以上の従属サブピクチャレイヤからなる。しかしながら、符号化サブピクチャには少なくとも1つの独立サブピクチャレイヤが存在し得る。独立サブピクチャレイヤは、レイヤ識別子(layer_id)の値が0であってもよく、この値はNALユニットヘッダ又は別の高位構文構造に存在してもよい。layer_idが0のサブピクチャレイヤは、ベースサブピクチャレイヤである。
【0128】
同じ又は別の実施形態において、ピクチャは、1つ以上の前景サブピクチャ、及び1つの背景サブピクチャからなる。背景サブピクチャによってサポートされる領域は、ピクチャの領域と等しくなり得る。前景サブピクチャによってサポートされる領域が、背景サブピクチャによってサポートされる領域と重なってもよい。背景サブピクチャはベースサブピクチャレイヤであってもよく、前景サブピクチャは非ベース(エンハンスメント)サブピクチャレイヤであってもよい。1つ以上の非ベースサブピクチャレイヤが、復号のために同じベースレイヤを参照してもよい。layer_idがaの各非ベースサブピクチャレイヤは、layer_idがbの非ベースサブピクチャレイヤを参照してもよく、ここでaはbより大きい。
【0129】
同じ又は別の実施形態において、ピクチャは、背景サブピクチャあり又はなしの、1つ以上の前景サブピクチャからなっていてもよい。各サブピクチャは、それ自身のベースサブピクチャレイヤと、1つ以上の非ベース(エンハンスメント)レイヤとを有してもよい。各ベースサブピクチャレイヤは、1つ以上の非ベースサブピクチャレイヤに参照されてもよい。layer_idがaの各非ベースサブピクチャレイヤは、layer_idがbの非ベースサブピクチャレイヤを参照してもよく、ここでaはbより大きい。
【0130】
同じ又は別の実施形態において、ピクチャは、背景サブピクチャあり又はなしの、1つ以上の前景サブピクチャからなっていてもよい。(ベース又は非ベース)サブピクチャレイヤ内の各符号化サブピクチャは、同じサブピクチャに属する1つ以上の非ベースレイヤサブピクチャ、及び同じサブピクチャに属さない1つ以上の非ベースレイヤサブピクチャに参照されてもよい。
【0131】
同じ又は別の実施形態において、ピクチャは、背景サブピクチャあり又はなしの、1つ以上の前景サブピクチャからなっていてもよい。レイヤa内のサブピクチャは、同じレイヤ内でさらに複数のサブピクチャに分割されてもよい。レイヤb内の1つ以上の符号化サブピクチャは、レイヤa内の分割されたサブピクチャを参照してもよい。
【0132】
同じ又は別の実施形態において、符号化映像シーケンス(CVS)は、符号化ピクチャのグループであってもよい。CVSは、1つ以上の符号化サブピクチャシーケンス(CSPS)からなっていてもよく、CSPSは、ピクチャの同じ局所領域をカバーする、符号化サブピクチャのグループであってもよい。CSPSは、符号化映像シーケンスと同じ、又はこれとは異なる時間解像度を有してもよい。
【0133】
同じ又は別の実施形態において、CSPSは符号化され1つ以上のレイヤに含まれていてもよい。CSPSは、1つ以上のCSPSレイヤからなっていてもよい。CSPSに対応する1つ以上のCSPSレイヤを復号することによって、同じ局所領域に対応するサブピクチャのシーケンスを再構築してもよい。
【0134】
同じ又は別の実施形態において、CSPSに対応するCSPSレイヤの数は、別のCSPSに対応するCSPSレイヤの数と同一である、又は異なっていてもよい。
【0135】
同じ又は別の実施形態において、CSPSレイヤは、別のCSPSレイヤとは異なる時間解像度(例えば、フレームレート)を有してもよい。元の(非圧縮の)サブピクチャシーケンスは、時間的にリサンプリング(アップサンプリング又はダウンサンプリング)され、別の時間解像度パラメータで符号化され、レイヤに対応するビットストリームに含まれてもよい。
【0136】
同じ又は別の実施形態において、フレームレートFのサブピクチャシーケンスは、符号化されてレイヤ0に対応する符号化ビットストリームに含まれてもよく、元のサブピクチャシーケンスから時間的にアップサンプリングされた(又はダウンサンプリングされた)、F*St,kを伴うサブピクチャシーケンスは、符号化されてレイヤkに対応する映像ビットストリームに含まれてもよく、ここでSt,kは、レイヤkの時間サンプリング比を示す。St,kの値が1より大きい場合は、時間リサンプリングプロセスはフレームレートアップ変換と等しい。これに対し、St,kの値が1より小さい場合は、時間リサンプリングプロセスはフレームレートダウン変換と等しい。
【0137】
同じ又は別の実施形態において、動き補償又は任意のインターレイヤ予測のために、CSPSレイヤaを有するサブピクチャが、CSPSレイヤbを有するサブピクチャによって参照されるときに、CSPSレイヤaの空間解像度がCSPSレイヤbの空間解像度とは異なっている場合は、CSPSレイヤa内の復号画素がリサンプリングされて参照に使用される。リサンプリングプロセスは、アップサンプリングフィルタリング又はダウンサンプリングフィルタリングを必要とする場合がある。
【0138】
図9は、符号化映像シーケンス内の全てのピクチャ/スライスに使用されるpoc_cycle_auを示す、VPS(又はSPS)におけるvps_poc_cycle_auの構文要素、並びにスライスヘッダ内の現在のスライスのpoc_cycle_auを示す、slice_poc_cycle_auの構文要素を信号送信するための構文テーブルの例を示す。POC値がAU毎に均一に増加する場合は、VPSにおけるvps_contant_poc_cycle_per_auは1になるように設定され、VPSでvps_poc_cycle_auが信号送信される。この場合、slice_poc_cycle_auは明示的に信号送信されず、POCの値をvps_poc_cycle_auで割ることによって、各AUに対するAUCの値が計算される。POC値がAU毎に均一に増加しない場合は、VPSにおけるvps_contant_poc_cycle_per_auが0になるように設定される。この場合は、vps_access_unit_cntは信号送信されず、各スライス又はピクチャに対して、スライスヘッダでslice_access_unit_cntが信号送信される。各スライス又はピクチャは、slice_access_unit_cntの値が異なっていてもよい。各AUに対するAUCの値は、POCの値をslice_poc_cycle_auで割ることによって計算される。図10は、関連するワークフローを図示するブロック図を示している。
【0139】
同じ又は別の実施形態において、ピクチャ、スライス、又はタイルのPOCの値は異なっていてもよいが、同じAUC値を有する、AUに対応するピクチャ、スライス、又はタイルは、同じ復号又は出力の時間インスタンスに関連付けられてもよい。したがって、同じAU内のピクチャ、スライス、又はタイルにまたがるいかなるインター構文解析従属性/復号従属性もなく、同じAUに関連付けられたピクチャ、スライス、又はタイルの全て又はサブセットが並行して復号され、同じ時間インスタンスで出力されてもよい。
【0140】
同じ又は別の実施形態において、ピクチャ、スライス、又はタイルのPOCの値は異なっていてもよいが、同じAUC値を有する、AUに対応するピクチャ、スライス、又はタイルは、同じ構成/表示の時間インスタンスに関連付けられてもよい。構成時間がコンテナ形式に含まれるときは、ピクチャが異なるAUに対応していても、ピクチャの構成時間が同じであれば、同じ時間インスタンスでピクチャを表示することができる。
【0141】
同じ又は他の実施形態において、各ピクチャ、スライス、又はタイルは、同じAU内で同じ時間識別子(temporal_id)を有してもよい。時間インスタンスに対応するピクチャ、スライス、又はタイルの全て又はサブセットは、同じ時間サブレイヤに関連付けられてもよい。同じ又は他の実施形態において、各ピクチャ、スライス、又はタイルは、同じAU内で、同じ又は異なる空間レイヤID(layer_id)を有してもよい。時間インスタンスに対応するピクチャ、スライス、又はタイルの全て又はサブセットが、同じ又は異なる空間レイヤに関連付けられてもよい。
【0142】
図11は、layer_idが0の背景映像CSPS、及び複数の前景CSPSレイヤを含む、例示的な映像ストリームを示す。符号化サブピクチャは1つ以上のCSPSレイヤからなっていてもよく、いずれの前景CSPSレイヤにも属さない背景領域は、ベースレイヤからなっていてもよい。ベースレイヤが背景領域と前景領域とを含み得る一方で、エンハンスメントCSPSレイヤは前景領域を含む。エンハンスメントCSPSレイヤは、同じ領域において、ベースレイヤよりも良好な視覚品質を有する場合がある。エンハンスメントCSPSレイヤは、同じ領域に対応する、再構築画素及びベースレイヤの動きベクトルを参照してもよい。
【0143】
同じ又は別の実施形態において、ベースレイヤに対応する映像ビットストリームはトラックに含まれ、各サブピクチャに対応するCSPSレイヤは、映像ファイル内の別のトラックに含まれる。
【0144】
同じ又は別の実施形態において、ベースレイヤに対応する映像ビットストリームはトラックに含まれ、同じlayer_idを有するCSPSレイヤは別のトラックに含まれる。この例では、レイヤkに対応するトラックは、レイヤkのみに対応するCSPSレイヤを含む。
【0145】
同じ又は別の実施形態において、各サブピクチャの各CSPSレイヤは、別のトラックに記憶される。各トラックは、1つ以上の他のトラックに対する構文解析従属性又は復号従属性が、ある場合もない場合もある。
【0146】
同じ又は別の実施形態において、各トラックは、サブピクチャの全て又はサブセットの、CSPSレイヤのレイヤiからレイヤjに対応するビットストリームを含んでもよく、ここで0<i=<j=<kであり、kはCSPSの最高次のレイヤになる。
【0147】
同じ又は別の実施形態において、ピクチャは、深度マップ、アルファマップ、3D形状データ、占有マップなどを含む、1つ以上の関連するメディアデータからなる。このような関連する時分割メディアデータは、それぞれが1つのサブピクチャに対応する、1つ又は複数のデータサブストリームに分割することができる。
【0148】
同じ又は別の実施形態において、図12は、複数レイヤサブピクチャ方式に基づくビデオ会議の例を示す。映像ストリームには、背景ピクチャに対応する1つのベースレイヤ映像ビットストリームと、前景サブピクチャに対応する、1つ以上のエンハンスメントレイヤ映像ビットストリームとが含まれる。各エンハンスメントレイヤ映像ビットストリームは、CSPSレイヤに対応する。表示装置には、デフォルトでベースレイヤに対応するピクチャが表示される。これには、1つ以上のユーザのピクチャピクチャ(PIP)が含まれる。クライアントの制御によって特定ユーザが選択されると、選択したユーザに対応するエンハンスメントCSPSレイヤが復号され、エンハンスされた品質又は空間解像度で表示される。図13は、動作図を示している。
【0149】
同じ又は別の実施形態において、ネットワークミドルボックス(ルータなど)は、その帯域幅に応じて、ユーザに送信するレイヤのサブセットを選択してもよい。ピクチャ/サブピクチャ構造が帯域幅適合に使用されてもよい。例えば、ユーザが帯域幅を有していない場合、ルータは重要性に応じて、レイヤを削除する、又は使用されている設定に基づいていくつかのサブピクチャを選択し、これは動的に実行して帯域幅に使用することができる。
【0150】
図14は、360度映像の使用事例を示す。360度の球体のピクチャが平面ピクチャに投影されると、360度ピクチャの投影は、ベースレイヤとして複数のサブピクチャに分割され得る。特定のサブピクチャのエンハンスメントレイヤが、符号化されてクライアントに送信されてもよい。復号器は、全サブピクチャを含むベースレイヤ、及び選択したサブピクチャのエンハンスメントレイヤの両方を復号し得る。現在のビューポートが選択したサブピクチャと同一のときは、表示されるピクチャは、エンハンスメントレイヤを含む復号サブピクチャを使用した、より高品質なものになり得る。そうでない場合は、ベースレイヤを含む復号ピクチャは、低品質で表示される可能性がある。
【0151】
同じ又は別の実施形態において、表示するための任意のレイアウト情報が、補助情報(SEIメッセージ又はメタデータなど)としてファイル内に存在してもよい。信号送信されたレイアウト情報に応じて、1つ以上の復号サブピクチャが再配置されて表示されてもよい。レイアウト情報は、ストリーミングサーバ又は放送事業者によって信号送信されてもよく、或いはネットワークエンティティ又はクラウドサーバによって再生成されてもよく、或いはユーザのカスタマイズ設定によって決定されてもよい。
【0152】
実施形態において、入力ピクチャが1つ以上の(長方形の)サブ領域に分割されると、各サブ領域は、独立レイヤとして符号化されてもよい。局所領域に対応する各独立レイヤは、固有のlayer_id値を有していてもよい。各独立レイヤに対して、サブピクチャサイズ及び位置情報が信号送信されてもよい。例えば、ピクチャサイズ(幅、高さ)、左上隅のオフセット情報(x_offset、y_offset)などである。図15は、分割されたサブピクチャのレイアウト、そのサブピクチャサイズ及び位置情報、並びにその対応するピクチャ予測構造の例を示す。サブピクチャサイズ及びサブピクチャ位置を含むレイアウト情報は、パラメータセット、スライス又はタイルグループのヘッダ、又はSEIメッセージなどの高位構文構造で信号送信されてもよい。
【0153】
同じ実施形態において、独立レイヤに対応する各サブピクチャは、AU内にその固有のPOC値を有してもよい。DPBに記憶されたピクチャ中の参照ピクチャが、RPS又はRPL構造内の構文要素を使用して示されているときは、レイヤに対応する各サブピクチャのPOC値が使用されてもよい。
【0154】
同じ又は別の実施形態において、(インターレイヤ)予測構造を示すために、layer_idが使用されずに、POC(デルタ)値が使用されてもよい。
【0155】
同じ実施形態において、レイヤ(又は局所領域)に対応する、POC値がNのサブピクチャは、動き補償予測のための同じレイヤ(又は同じ局所領域)に対応する、POC値がN+Kのサブピクチャの参照ピクチャとして使用されてもよく、又は使用されなくてもよい。ほとんどの場合、数Kの値は、(独立)レイヤの最大数と等しくなってもよく、サブ領域の数と同一になり得る。
【0156】
同じ又は別の実施形態において、図16は、図15のさらに詳しい事例を示す。入力ピクチャが複数の(例えば4つの)サブ領域に分割されると、各局所領域は、1つ以上のレイヤを用いて符号化されてもよい。この事例では、独立レイヤの数はサブ領域の数と等しくてもよく、1つ以上のレイヤがサブ領域に対応してもよい。したがって、各サブ領域は、1つ以上の独立レイヤ、及び0個以上の従属レイヤを用いて符号化されてもよい。
【0157】
同じ実施形態において、図16では、入力ピクチャは、4つのサブ領域に分割されてもよい。右上のサブ領域は、レイヤ1及びレイヤ4の2つのレイヤとして符号化されてもよく、右下のサブ領域は、レイヤ3及びレイヤ5の2つのレイヤとして符号化されてもよい。この場合、レイヤ4は、動き補償予測のためにレイヤ1を参照してもよく、レイヤ5は、動き補償のためにレイヤ3を参照してもよい。
【0158】
同じ又は別の実施形態において、レイヤ境界をまたいだループ内フィルタリング(非ブロック化フィルタリング、適応的ループ内フィルタリング、リシェーパ、双方向フィルタリング、又は任意の深層学習に基づくフィルタリングなど)は、(任意で)無効にされてもよい。
【0159】
同じ又は別の実施形態において、レイヤ境界をまたいだ動き補償予測又はイントラブロックコピーは、(任意で)無効にされてもよい。
【0160】
同じ又は別の実施形態において、サブピクチャの境界における、動き補償予測又はループ内フィルタリングのための境界パディングが、任意で処理されてもよい。境界パディングが処理されるかどうかを示すフラグは、パラメータセット(VPS、SPS、PPS、又はAPS)、スライス又はタイルグループヘッダ、或いはSEIメッセージなどの高位構文構造で信号送信されてもよい。
【0161】
同じ又は別の実施形態において、サブ領域(又はサブピクチャ)のレイアウト情報は、VPS又はSPSで信号送信されてもよい。図17は、VPS及びSPSの構文要素の例を示す。この例では、vps_sub_picture_dividing_flagがVPSで信号送信される。フラグは、入力ピクチャが複数のサブ領域に分割されたかどうかを示し得る。vps_sub_picture_dividing_flagの値が0のときは、現在のVPSに対応する符号化映像シーケンス内の入力ピクチャは、複数のサブ領域に分割されなくてもよい。この場合、入力ピクチャサイズは、符号化ピクチャサイズ(pic_width_in_luma_samples、pic_height_in_luma_samples)と等しくてもよく、これはSPSで信号送信される。vps_sub_picture_dividing_flagの値が1のときは、入力ピクチャは複数のサブ領域に分割されてもよい。この場合は、構文要素vps_full_pic_width_in_luma_samplesとvps_full_pic_height_in_luma_samplesとがVPSで信号送信される。vps_full_pic_width_in_luma_samples及びvps_full_pic_height_in_luma_samplesの値は、入力ピクチャの幅及び高さとそれぞれ等しくなり得る。
【0162】
同じ実施形態において、vps_full_pic_width_in_luma_samples及びvps_full_pic_height_in_luma_samplesの値は、復号に使用されないが、構成及び表示に使用される場合がある。
【0163】
同じ実施形態において、vps_sub_picture_dividing_flagの値が1のときは、構文要素pic_offset_x及びpic_offset_yがSPSで信号送信されてもよく、これは特定のレイヤに対応する。この場合は、SPSで信号送信される符号化ピクチャサイズ(pic_width_in_luma_samples、pic_height_in_luma_samples)は、特定のレイヤに対応するサブ領域の幅及び高さと等しくなり得る。また、サブ領域の左上隅の位置(pic_offset_x、pic_offset_y)が、SPSで信号送信されてもよい。
【0164】
同じ実施形態において、サブ領域の左上隅の位置情報(pic_offset_x、pic_offset_y)は、復号に使用されないが、構成及び表示に使用される場合がある。
【0165】
同じ又は別の実施形態において、入力ピクチャのサブ領域の全て又はサブセットのレイアウト情報(サイズ及び位置)、レイヤ間の従属性情報が、パラメータセット又はSEIメッセージで信号送信されてもよい。図18は、サブ領域のレイアウト、レイヤ間の従属性、及びサブ領域と1つ以上のレイヤとの関係の情報を示すための、構文要素の例を示す。この例では、構文要素num_sub_regionは、現在の符号化映像シーケンス内の(長方形の)サブ領域の数を示し、構文要素num_layersは、現在の符号化映像シーケンス内のレイヤの数を示す。num_layersの値は、num_sub_regionの値と等しいか、又は大きくてもよい。任意のサブ領域が1つのレイヤとして符号化されるときは、num_layersの値は、num_sub_regionの値と等しくなり得る。1つ以上のサブ領域が複数のレイヤとして符号化されるときは、num_layersの値は、num_sub_regionの値より大きくなり得る。構文要素direct_dependency_flag[ i ][ j ]は、j番目のレイヤからi番目のレイヤまでの従属性を示す。num_layers_for_region[ i ]は、i番目のサブ領域に関連付けられるレイヤの数を示す。sub_region_layer_id[ i ][ j ]は、i番目のサブ領域に関連付けられるj番目のレイヤのlayer_idを示す。sub_region_offset_x[ i ]及びsub_region_offset_y[ i ]は、i番目のサブ領域の左上隅の水平位置及び垂直位置をそれぞれ示す。sub_region_width [ i ]及びsub_region_height[ i ]は、i番目のサブ領域の幅及び高さをそれぞれ示す。
【0166】
1つの実施形態において、プロファイル層レベル情報あり又はなしで出力される1つ以上のレイヤを表示するために、出力レイヤセットを指定する1つ以上の構文要素が、VPS、DPS、SPS、PPS、APS又はSEIメッセージなどの高位構文構造で信号送信されてもよい。図19を参照すると、VPSを参照している符号化映像シーケンス内の出力レイヤセット(OLS)の数を示す構文要素num_output_layer_setsが、VPSで信号送信されてもよい。各出力レイヤセットに対して、出力レイヤと同じ数だけoutput_layer_flagが信号送信されてもよい。
【0167】
同じ実施形態において、output_layer_flag[ i ]が1であれば、i番目のレイヤが出力であることを示す。vps_output_layer_flag[ i ]が0であれば、i番目のレイヤが出力でないことを示す。
【0168】
同じ又は別の実施形態において、各出力レイヤセットに対してプロファイル層レベル情報を指定する1つ以上の構文要素が、VPS、DPS、SPS、PPS、APS又はSEIメッセージなどの高位構文構造で信号送信されてもよい。図19をさらに参照すると、VPSを参照している符号化映像シーケンス内の、OLS毎のプロファイル層レベル情報の数を示す構文要素num_profile_tile_levelが、VPSで信号送信されてもよい。各出力レイヤセットに対して、プロファイル層レベル情報に対する1組の構文要素、又はプロファイル層レベル情報内のエンティティ中の、特定のプロファイル層レベル情報を示すインデックスが、出力レイヤと同じ数だけ信号送信されてもよい。
【0169】
同じ実施形態において、profile_tier_level_idx[ i ][ j ]は、VPS内のprofile_tier_level()構文構造のリストの中に、i番目のOLSのj番目のレイヤに適用される、profile_tier_level()構文構造のインデックスを指定する。
【0170】
同じ又は別の実施形態において、図20を参照すると、最大レイヤの数が1より大きい(vps_max_layers_minus1>0)ときは、構文要素num_profile_tile_level及び/又はnum_output_layer_setsが信号送信されてもよい。
【0171】
同じ又は別の実施形態において、図20を参照すると、i番目の出力レイヤセットの出力レイヤ信号送信のモードを示す構文要素vps_output_layers_mode[ i ]が、VPSに存在してもよい。
【0172】
同じ実施形態において、vps_output_layers_mode[ i ]が0であれば、i番目の出力レイヤセットで最高次のレイヤのみが出力されることを指定する。vps_output_layers_mode[ i ]が1であれば、i番目の出力レイヤセットで全てのレイヤが出力されることを指定する。vps_output_layers_mode[ i ]が2であれば、出力されるレイヤは、i番目の出力レイヤセットを含む、vps_output_layer_flag[ i ][ j ]が1のレイヤであることを指定する。より多くの値が保存されてもよい。
【0173】
同じ実施形態において、output_layer_flag[ i ][ j ]は、i番目の出力レイヤセットに対するvps_output_layers_mode[ i ]の値に応じて、信号送信される場合もされない場合もある。
【0174】
同じ又は別の実施形態において、図20を参照すると、i番目の出力レイヤセットに対して、フラグvps_ptl_signal_flag[ i ]が存在し得る。vps_ptl_signal_flag[ i ]の値に応じて、i番目の出力レイヤセットのプロファイル層レベル情報は、信号送信される場合もされない場合もある。
【0175】
同じ又は別の実施形態において、図21を参照すると、現在のCVS内のサブピクチャの数max_subpics_minus1が、VPS、DPS、SPS、PPS、APS又はSEIメッセージなどの高位構文構造で信号送信されてもよい。
【0176】
同じ実施形態において、図21を参照すると、サブピクチャの数が1よりも多いとき(max_subpics_minus1>0)は、i番目のサブピクチャのサブピクチャ識別子sub_pic_id[i]が信号送信されてもよい。
【0177】
同じ又は別の実施形態において、各出力レイヤセットの各レイヤに属するサブピクチャ識別子を示す1つ以上の構文要素が、VPSで信号送信されてもよい。図22を参照すると、sub_pic_id_layer[i][j][k]は、k番目のサブピクチャが、i番目の出力レイヤセットのj番目のレイヤに存在していることを示す。このような情報を用いて、復号器は、特定の出力レイヤセットの各レイヤに対して、どのサブピクチャが復号され出力されてもよいかを認識し得る。
【0178】
実施形態において、ピクチャヘッダ(PH)は、符号化ピクチャの全スライスに適用する構文要素を含む構文構造である。ピクチャユニット(PU)は、指定された分類ルールに従って互いに関連し、復号順に連続し、正確に1つの符号化ピクチャを含む1組のNALユニットである。PUは、ピクチャヘッダ(PH)、及び符号化ピクチャを構成する1つ以上のVCL NALユニットを含んでもよい。
【0179】
実施形態において、SPS(RBSP)は、それが参照される前に、復号プロセスに使用可能になってもよく、TemporalIdが0の少なくとも1つのAUに含まれる、又は外部手段によって提供され得る。
【0180】
実施形態において、SPS(RBSP)は、それが参照される前に、復号プロセスに使用可能になってもよく、SPSを参照する1つ以上のPPSを含む、CVS内でTemporalIdが0の少なくとも1つのAUに含まれる、又は外部手段によって提供され得る。
【0181】
実施形態において、SPS(RBSP)は、1つ以上のPPSによってそれが参照される前に、復号プロセスに使用可能になってもよく、nuh_layer_idが、(SPSを参照する1つ以上のPPSを含む)CVS内の、SPS NALユニットを参照するPPS NALユニットのnuh_layer_idの最低値と等しい、少なくとも1つのPUに含まれる、又は外部手段によって提供され得る。
【0182】
実施形態において、SPS(RBSP)は、1つ以上のPPSによってそれが参照される前に、復号プロセスに使用可能になってもよく、TemporalIdが0であり、nuh_layer_idが、SPS NALユニットを参照するPPS NALユニットの、nuh_layer_idの最低値と等しい少なくとも1つのPUに含まれる、又は外部手段によって提供され得る。
【0183】
実施形態において、SPS(RBSP)は、1つ以上のPPSによってそれが参照される前に、復号プロセスに使用可能になってもよく、TemporalIdが0であり、nuh_layer_idが、(SPSを参照する1つ以上のPPSを含む)CVS内の、SPS NALユニットを参照するPPS NALユニットのnuh_layer_idの最低値と等しい、少なくとも1つのPUに含まれる、又は外部手段によって提供され得る。
【0184】
同じ又は別の実施形態において、pps_seq_parameter_set_idは、参照されるSPSのsps_seq_parameter_set_idの値を指定する。pps_seq_parameter_set_idの値は、CLVS内で符号化ピクチャに参照される、全PPSで同じであってもよい。
【0185】
同じ又は別の実施形態において、CVS内で特定の値のsps_seq_parameter_set_idを有する全SPS NALユニットは、同じコンテンツを有し得る。
【0186】
同じ又は別の実施形態において、nuh_layer_id値とは無関係に、SPS NALユニットは、sps_seq_parameter_set_idの同じ値空間を共有してもよい。
【0187】
同じ又は別の実施形態において、SPS NALユニットのnuh_layer_id値は、SPS NALユニットを参照する、PPS NALユニットのnuh_layer_idの最低値と等しくてもよい。
【0188】
実施形態において、nuh_layer_idがmのSPSが、nuh_layer_idがnの1つ以上のPPSによって参照されるときは、nuh_layer_idがmのレイヤは、nuh_layer_idがnのレイヤ、或いは(直接的又は間接的に)nuh_layer_idがmのレイヤの参照レイヤと同じであってもよい。
【0189】
実施形態において、PPS(RBSP)は、それが参照される前に復号プロセスに使用可能になり、TemporalIdがPPS NALユニットのTemporalIdと等しい少なくとも1つのAUに含まれる、又は外部手段によって提供されるものとする。
【0190】
実施形態において、PPS(RBSP)は、それが参照される前に、復号プロセスに使用可能になってもよく、PPSを参照する1つ以上のPH(又は符号化スライスNALユニット)を含むCVS内の、TemporalIdがPPS NALユニットのTemporalIdと等しい、少なくとも1つのAUに含まれる、又は外部手段によって提供され得る。
【0191】
実施形態において、PPS(RBSP)は、1つ以上のPH(又は符号化スライスNALユニット)によってそれが参照される前に、復号プロセスに使用可能になってもよく、nuh_layer_idが、(PPSを参照する1つ以上のPH(又は符号化スライスNALユニット)を含む)CVS内のPPS NALユニットを参照する、符号化スライスNALユニットのnuh_layer_idの最低値と等しい、少なくとも1つのPUに含まれる、又は外部手段によって提供され得る。
【0192】
実施形態において、PPS(RBSP)は、1つ以上のPH(又は符号化スライスNALユニット)によってそれが参照される前に、復号プロセスに使用可能になってもよく、TemporalIdがPPS NALユニットのTemporalIdと等しく、かつnuh_layer_idが、(PPSを参照する1つ以上のPH(又は符号化スライスNALユニット)を含む)CVS内のPPS NALユニットを参照する、符号化スライスNALユニットのnuh_layer_idの最低値と等しい、少なくとも1つのPUに含まれる、又は外部手段によって提供され得る。
【0193】
同じ又は別の実施形態において、PHにおけるph_pic_parameter_set_idは、使用時に参照されるPPSの、pps_pic_parameter_set_idの値を指定する。pps_seq_parameter_set_idの値は、CLVS内で符号化ピクチャに参照される、全PPSで同じであってもよい。
【0194】
同じ又は別の実施形態において、PU内で特定の値のpps_pic_parameter_set_idを有する全PPS NALユニットは、同じコンテンツを有するものとする。
【0195】
同じ又は別の実施形態において、nuh_layer_id値とは無関係に、PPS NALユニットは、pps_pic_parameter_set_idの同じ値空間を共有してもよい。
【0196】
同じ又は別の実施形態において、PPS NALユニットのnuh_layer_id値は、PPS NALユニットを参照するNALユニットを参照する、符号化スライスNALユニットのnuh_layer_idの最低値と等しくてもよい。
【0197】
実施形態において、nuh_layer_idがmのPPSが、nuh_layer_idがnの1つ以上の符号化スライスNALユニットによって参照されるときは、nuh_layer_idがmのレイヤは、nuh_layer_idがnのレイヤ、或いは(直接的又は間接的に)nuh_layer_idがmのレイヤの参照レイヤと同じであってもよい。
【0198】
実施形態において、PPS(RBSP)は、それが参照される前に復号プロセスに使用可能になり、TemporalIdがPPS NALユニットのTemporalIdと等しい少なくとも1つのAUに含まれる、又は外部手段によって提供されるものとする。
【0199】
実施形態において、PPS(RBSP)は、それが参照される前に、復号プロセスに使用可能になってもよく、PPSを参照する1つ以上のPH(又は符号化スライスNALユニット)を含むCVS内の、TemporalIdがPPS NALユニットのTemporalIdと等しい、少なくとも1つのAUに含まれる、又は外部手段によって提供され得る。
【0200】
実施形態において、PPS(RBSP)は、1つ以上のPH(又は符号化スライスNALユニット)によってそれが参照される前に、復号プロセスに使用可能になってもよく、nuh_layer_idが、(PPSを参照する1つ以上のPH(又は符号化スライスNALユニット)を含む)CVS内のPPS NALユニットを参照する、符号化スライスNALユニットのnuh_layer_idの最低値と等しい、少なくとも1つのPUに含まれる、又は外部手段によって提供され得る。
【0201】
実施形態において、PPS(RBSP)は、1つ以上のPH(又は符号化スライスNALユニット)によってそれが参照される前に、復号プロセスに使用可能になってもよく、TemporalIdがPPS NALユニットのTemporalIdと等しく、かつnuh_layer_idが、(PPSを参照する1つ以上のPH(又は符号化スライスNALユニット)を含む)CVS内のPPS NALユニットを参照する、符号化スライスNALユニットのnuh_layer_idの最低値と等しい、少なくとも1つのPUに含まれる、又は外部手段によって提供され得る。
【0202】
同じ又は別の実施形態において、PHにおけるph_pic_parameter_set_idは、使用時に参照されるPPSの、pps_pic_parameter_set_idの値を指定する。pps_seq_parameter_set_idの値は、CLVS内で符号化ピクチャに参照される、全PPSで同じであってもよい。
【0203】
同じ又は別の実施形態において、PU内で特定の値のpps_pic_parameter_set_idを有する全PPS NALユニットは、同じコンテンツを有するものとする。
【0204】
同じ又は別の実施形態において、nuh_layer_id値とは無関係に、PPS NALユニットは、pps_pic_parameter_set_idの同じ値空間を共有してもよい。
【0205】
同じ又は別の実施形態において、PPS NALユニットのnuh_layer_id値は、PPS NALユニットを参照するNALユニットを参照する、符号化スライスNALユニットのnuh_layer_idの最低値と等しくてもよい。
【0206】
実施形態において、nuh_layer_idがmのPPSが、nuh_layer_idがnの1つ以上の符号化スライスNALユニットによって参照されるときは、nuh_layer_idがmのレイヤは、nuh_layer_idがnのレイヤ、或いは(直接的又は間接的に)nuh_layer_idがmのレイヤの参照レイヤと同じであってもよい。
【0207】
実施形態において、図22に示すように、ピクチャパラメータセット内のpps_subpic_id[ i ]は、i番目のサブピクチャのサブピクチャIDを指定する。pps_subpic_id[ i ]構文要素の長さは、pps_subpic_id_len_minus1+1ビットである。
【0208】
iの各値が0からsps_num_subpics_minus1までの範囲内にある変数SubpicIdVal[ i ]は、以下の通りに導かれる。
for(i=0;i<=sps_num_subpics_minus1;i++)
if(subpic_id_mapping_explicitly_signalled_flag)
SubpicIdVal[ i ]=subpic_id_mapping_in_pps_flag ? pps_subpic_id[ i ]:sps_subpic_id[ i ](80)
else
SubpicIdVal[ i ]=i
【0209】
同じ又は別の実施形態において、0からsps_num_subpics_minus1までの範囲内の、i及びjの任意の2つの異なる値については、SubpicIdVal[ i ]がSubpicIdVal[ j ]と等しくならない場合がある。
【0210】
同じ又は別の実施形態において、現ピクチャがCLVSの第1のピクチャではないときは、0からsps_num_subpics_minus1までの範囲内のiの各値に対し、SubpicIdVal[ i ]の値が、同じレイヤにおいて、復号順で前のピクチャのSubpicIdVal[ i ]の値と等しくない場合は、サブピクチャインデックスiの現ピクチャ内のサブピクチャの、全符号化スライスNALユニットに対するnal_unit_typeは、IDR_W_RADLからCRA_NUTまでの範囲内で特定の値と等しくなり得る。
【0211】
同じ又は別の実施形態において、現ピクチャがCLVSの第1のピクチャではないときは、0からsps_num_subpics_minus1までの範囲内のiの各値に対し、SubpicIdVal[ i ]の値が、同じレイヤにおいて、復号順で前のピクチャのSubpicIdVal[ i ]の値と等しくない場合は、sps_independent_subpics_flagは1になり得る。
【0212】
同じ又は別の実施形態において、現ピクチャがCLVSの第1のピクチャではないときは、0からsps_num_subpics_minus1までの範囲内のiの各値に対し、SubpicIdVal[ i ]の値が、同じレイヤにおいて、復号順で前のピクチャのSubpicIdVal[ i ]の値と等しくない場合は、subpic_treated_as_pic_flag[ i ]及び loop_filter_across_subpic_enabled_flag[ i ]は1になり得る。
【0213】
同じ又は別の実施形態において、現ピクチャがCLVSの第1のピクチャではないときは、0からsps_num_subpics_minus1までの範囲内のiの各値に対し、SubpicIdVal[ i ]の値が、同じレイヤにおいて、復号順で前のピクチャのSubpicIdVal[ i ]の値と等しくない場合は、sps_independent_subpics_flagが1になる、或いはsubpic_treated_as_pic_flag[ i ]及び loop_filter_across_subpic_enabled_flag[ i ]が1になるものとする。
【0214】
同じ又は別の実施形態において、サブピクチャが、別のサブピクチャを参照することなく独立して符号化されるときは、領域のサブピクチャ識別子の値が、符号化映像シーケンス内で変化する場合がある。
【0215】
ピクチャ内のサブピクチャの数は、SPSで信号送信されてもよい。例えば、図23において、sps_num_subpics_minus1に1を加えたものは、CLVS内の各ピクチャのサブピクチャの数を指定する。sps_num_subpics_minus1の値は、0からCeil(pic_width_max_in_luma_samples÷CtbSizeY)*Ceil(pic_height_max_in_luma_samples÷CtbSizeY)-1までの範囲内にあるものとする。この範囲にない場合は、sps_num_subpics_minus1の値は0になると推定される。
【0216】
同じ又は別の実施形態において、ピクチャ内のサブピクチャの数がPPSで送信されてもよい。例えば、図24において、pps_num_subpics_minus1は各ピクチャのサブピクチャの数を指定し、sps_num_subpics_minus1と等しくなり得る。
【0217】
ピクチャ内のスライスの数が、PPSで信号送信されてもよい。例えば、図24において、num_slices_in_pic_minus1に1を加えたものは、PPSを参照する各ピクチャ内の長方形スライスの数を指定する。num_slices_in_pic_minus1の値は、0からMaxSlicesPerPicture-1までの範囲にあってもよく、MaxSlicesPerPictureはAnnex Aで指定されている。no_pic_partition_flagが1のときは、num_slices_in_pic_minus1の値は0になると推定される。single_slice_per_subpic_flagが1のときは、num_slices_in_pic_minus1の値はpps_num_subpics_minus1と等しくなると推定される。
【0218】
サブピクチャの数は、スライスの数より多くなくてもよい。ピクチャによって参照される、PPS内のsingle_slice_per_subpic_flagの値が1のときは、サブピクチャの数は、ピクチャ内のスライスの数と等しい。
【0219】
同じ実施形態において、ピクチャ内のスライスの数を示す変数NumSlicesInPicの値は、NumSlicesInPic=num_slices_in_pic_minus1+1で導かれる。
【0220】
サブピクチャの数とスライスの数との差分値は、PPSで信号送信されてもよく、ピクチャ内のスライスの数は、サブピクチャの数、及び信号送信された、サブピクチャの数とスライスの数の差から導かれる。
【0221】
実施形態において、図25に示すように、num_slices_in_pic_minus_num_sub_picsにpps_num_subpics_minus1+1を加えたものは、PPSを参照する各ピクチャ内の長方形スライスの数を示す。num_slices_in_pic_minus_num_sub_picsの値は、0からMaxSlicesPerPicture-pps_num_subpics_minus1-1までの範囲にあるものとし、MaxSlicesPerPictureはAnnex Aで指定されている。single_slice_per_subpic_flagが1のときは、num_slices_in_pic_minus_num_sub_picsの値は0になると推定される。
【0222】
同じ実施形態において、ピクチャ内のスライスの数を示す変数NumSlicesInPicの値は、以下の通りに導かれる。
if(no_pic_partition_flag==1)
NumSlicesInPic=1
else
NumSlicesInPic=pps_num_subpics_minus1+num_slices_in_pic_minus_num_sub_pics+1
【0223】
別の実施形態において、図26に示すように、num_slices_in_pic_minus_num_sub_pics_minus1にpps_num_subpics_minus1+2を加えたものは、PPSを参照する各ピクチャ内の長方形スライスの数を示す。num_slices_in_pic_minus num_sub_pics_minus1の値は、0からMaxSlicesPerPicture-pps_num_subpics_minus1-2までの範囲にあるものとし、MaxSlicesPerPictureはAnnex Aで指定されている。single_slice_per_subpic_flagが1のときは、num_slices_in_pic_minus_num_sub_pics_minus1の値は0になると推定される。
【0224】
同じ実施形態において、ピクチャ内のスライスの数を示す変数NumSlicesInPicの値は、以下の通りに導かれる。
if(no_pic_partition_flag==1)
NumSlicesInPic=1
else if(single_slice_per_subpic_flag==1)
NumSlicesInPic=pps_num_subpics_minus1+1
else
NumSlicesInPic=pps_num_subpics_minus1+num_slices_in_pic_minus_num_sub_pics_minus1+2
【0225】
同じ又は別の実施形態において、rect_slice_flagが1のとき、i番目のスライス内のCTUの数を指定する、0からNumSlicesInPic-1までの範囲のiのリストNumCtusInSlice[ i ]、スライス内の第1のCTUを含むタイルのタイルインデックス、及びi番目のスライス内でj番目のCTBのピクチャラスタスキャンアドレスを指定する、0からNumSlicesInPic-1までの範囲のi、及び0からNumCtusInSlice[ i ]-1までの範囲のjのマトリックスCtbAddrInSlice[ i ][ j ]を指定する、0からNumSlicesInPic-1までの範囲のiのリストSliceTopLeftTileIdx[ i ]、並びにi番目のスライスを含む、タイル内のスライスの数を指定する、変数NumSlicesInTile[ i ]は以下の通りに導かれる。
if(single_slice_per_subpic_flag){
for(i=0;i<=sps_num_subpics_minus1;i++){
NumCtusInSlice[ i ]=0
if(subpicHeightLessThanOneTileFlag[ i ])/*The slice consists of a number of CTU rows in a tile.*/
AddCtbsToSlice(i,subpic_ctu_top_left_x[ i ],
subpic_ctu_top_left_x[ i ]+subpic_width_minus1[ i ]+1,subpic_ctu_top_left_y[ i ],
subpic_ctu_top_left_y[ i ]+subpic_height_minus1[ i ]+1)
else { /*The slice consists of a number of complete tiles covering a rectangular region.*/
tileX=CtbToTileColBd[ subpic_ctu_top_left_x[ i ] ]
tileY=CtbToTileRowBd[ subpic_ctu_top_left_y[ i ] ]
for(j=0;j<SubpicHeightInTiles[ i ];j++)
for(k=0;k<SubpicWidthInTiles[ i ];k++)
AddCtbsToSlice(i,tileColBd[ tileX+k ],tileColBd[ tileX+k+1 ],tileRowBd[ tileY+j ],
tileRowBd[ tileY+j+1 ])


} else {
tileIdx=0
for(i=0;i<NumSlicesInPic;i++)
NumCtusInSlice[ i ]=0
for(i=0;i<NumSlicesInPic;i++){
SliceTopLeftTileIdx[ i ]=tileIdx
tileX=tileIdx % NumTileColumns
tileY=tileIdx/NumTileColumns
if(i<num_slices_in_pic_minus1){
sliceWidthInTiles[ i ]=slice_width_in_tiles_minus1[ i ]+1
sliceHeightInTiles[ i ]=slice_height_in_tiles_minus1[ i ]+1
} else {
sliceWidthInTiles[ i ]=NumTileColumns-tileX
sliceHeightInTiles[ i ]=NumTileRows-tileY
NumSlicesInTile[ i ]=1

if(slicWidthInTiles[ i ]==1&&sliceHeightInTiles[ i ]==1){(30)
if(num_exp_slices_in_tile[ i ]==0){
NumSlicesInTile[ i ]=1
sliceHeightInCtus[ i ]=RowHeight[ SliceTopLeftTileIdx[ i ]/NumTileColumns ]
} else {
remainingHeightInCtbsY=RowHeight[ SliceTopLeftTileIdx[ i ]/NumTileColumns ]
for(j=0;j<num_exp_slices_in_tile[ i ]-1;j++){
sliceHeightInCtus[ i+j ]=exp_slice_height_in_ctus_minus1[ i ][ j ]+1
remainingHeightInCtbsY-=sliceHeightInCtus[ i+j ]

uniformSliceHeight=exp_slice_height_in_ctus_minus1[ i ][ j ]+1
while(remainingHeightInCtbsY>=uniformSliceHeight){
sliceHeightInCtus[ i+j ]=uniformSliceHeight
remainingHeightInCtbsY-=uniformSliceHeight
j++

if(remainingHeightInCtbsY>0){
sliceHeightInCtus[ i+j ]=remainingHeightInCtbsY
j++

NumSlicesInTile[ i ]=j

ctbY=tileRowBd[ tileY ]
for(j=0;j<NumSlicesInTile[ i ];j++){
AddCtbsToSlice(i+j,tileColBd[ tileX ],tileColBd[ tileX+1 ],
ctbY,ctbY+sliceHeightInCtus[ i+j ])
ctbY+=sliceHeightInCtus[ i+j ]

i+=NumSlicesInTile[ i ]-1
} else
for(j=0;j<sliceHeightInTiles[ i ];j++)
for(k=0;k<sliceWidthInTiles[ i ];k++)
AddCtbsToSlice(i,tileColBd[ tileX+k ],tileColBd[ tileX+k+1 ],
tileRowBd[ tileY+j ],tileRowBd[ tileY+j+1 ])
if(i<num_slices_in_pic_minus1){
if(tile_idx_delta_present_flag)
tileIdx+=tile_idx_delta[ i ]
else {
tileIdx+=sliceWidthInTiles[ i ]
if(tileIdx % NumTileColumns==0)
tileIdx+=(sliceHeightInTiles[ i ]-1)*NumTileColumns



【0226】
ここで関数AddCtbsToSlice(sliceIdx,startX,stopX,startY,stopY)が、以下の通り指定される。
for(ctbY=startY;ctbY<stopY;ctbY++)
for(ctbX=startX;ctbX<stopX;ctbX++){
CtbAddrInSlice[ sliceIdx ][ NumCtusInSlice[ sliceIdx ] ]=ctbY * PicWidthInCtbsY+ctbX(31)
NumCtusInSlice[ sliceIdx ]++
【0227】
0からnum_slices_in_pic_minus1までの範囲のiに対するNumCtusInSlice[ i ]の値が0よりも大きくなることが、ビットストリーム適合の要件である。また、0からnum_slices_in_pic_minus1までの範囲のi、及び0からNumCtusInSlice[ i ]-1までの範囲のjのマトリックスCtbAddrInSlice[ i ][ j ]が、0からPicSizeInCtbsY-1までの範囲の全CTBアドレスのそれぞれを1度だけ含むことが、ビットストリーム適合の要件である。
【0228】
i番目のサブピクチャ内の長方形スライスの数を指定する、リストNumSlicesInSubpic[ i ]は、以下の通りに導かれる。
for(i=0;i<=sps_num_subpics_minus1;i++){
NumSlicesInSubpic[ i ]=0
for(j=0;j<NumSlicesInPic;j++){
posX=CtbAddrInSlice[ j ][ 0 ] % PicWidthInCtbsY
posY=CtbAddrInSlice[ j ][ 0 ]/PicWidthInCtbsY
if((posX>=subpic_ctu_top_left_x[ i ])&&(32)
(posX<subpic_ctu_top_left_x[ i ]+subpic_width_minus1[ i ]+1)&&
(posY>=subpic_ctu_top_left_y[ i ])&&
(posY<subpic_ctu_top_left_y[ i ]+subpic_height_minus1[ i ]+1))
NumSlicesInSubpic[ i ]++
【0229】
本開示は、いくつかの例示的な実施形態について説明してきたが、変更、置換、及びさまざまな代替的な等価物があり、これらは本開示の範囲内に含まれる。したがって当業者であれば、本明細書に明示的に図示又は説明されていなくても、本開示の原理を具体化し、したがってその原理と範囲内に含まれる多くのシステム及び方法を考案できることは理解されよう。
【符号の説明】
【0230】
100 通信システム
110 第1の端末
120 第2の端末
130、140 対の端末
150 通信ネットワーク
200 ストリーミングシステム
201 映像ソース
202 映像サンプルストリーム
203 映像符号器
204 符号化映像ビットストリーム
205 ストリーミングサーバ
206 ストリーミングクライアント
207 符号化映像ビットストリームのコピー
208 ストリーミングクライアント
209 符号化映像ビットストリームのコピー
210 映像復号器
211 映像サンプルストリーム
212 表示装置
213 捕捉サブシステム
310 受信機
312 チャネル
315 バッファメモリ
320 構文解析器
321 シンボル
351 スケーラ/逆変換ユニット
352 イントラピクチャ予測ユニット
353 動き補償予測ユニット
355 集約装置
356 ループフィルタユニット
356 現ピクチャ
357 参照ピクチャバッファ
430 ソース符号器
432 符号化エンジン
433 ローカル映像復号器
434 参照ピクチャメモリ
435 予測子
440 送信機
443 映像シーケンス
445 エントロピー符号器
450 コントローラ
460 通信チャネル
501 ピクチャヘッダ
502 ARC情報
503 ヘッダ拡張子(ARC(ワーピング座標))
504 ピクチャパラメータセット(PPS)
505 ARC参照情報
506 テーブル
507 シーケンスパラメータセット(SPS)
508 タイルグループヘッダ
509 ARC情報
511 適切なパラメータセット(APS)
512 ARC情報
513 ARC参照情報
514 タイルグループヘッダ
515 ARC情報
516 パラメータセット
601 タイルグループヘッダ
602 構文要素
603 適応的解像度
610 シーケンスパラメータセット
611 構文要素
612 パラメータセット
613 出力解像度
614 構文要素
615 参照ピクチャ寸法
616 テーブル表示
617 テーブル項目
700 コンピュータシステム
701 キーボード
702 マウス
703 トラックパッド
704 データグローブ
705 ジョイスティック
706 マイク
707 スキャナ
708 カメラ
709 音声出力装置(スピーカ)
710 タッチスクリーン
720 光学メディア
721 メディア
722 USBメモリ
723 ソリッドステートドライブ
740 コア
741 中央処理ユニット(CPU)
742 グラフィック処理ユニット(GPU)
743 プログラム可能処理ユニット(FPGA)
744 ハードウェアアクセラレータ
745 読出し専用メモリ(ROM)
746 ランダムアクセスメモリ(RAM)
747 内部大容量記憶装置
748 システムバス
749 周辺バス
750 グラフィックアダプタ
754 ネットワークインターフェース
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26