▶ フラウンホッファー−ゲゼルシャフト ツァ フェルダールング デァ アンゲヴァンテン フォアシュンク エー．ファオの特許一覧
特表2024-532664ストリーミングシナリオにおける動きベクトルの処理のためのビデオ符号化概念
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-09-10
(54)【発明の名称】ストリーミングシナリオにおける動きベクトルの処理のためのビデオ符号化概念
(51)【国際特許分類】
H04N 19/70 20140101AFI20240903BHJP
H04N 19/597 20140101ALI20240903BHJP
H04N 19/51 20140101ALI20240903BHJP
H04N 19/105 20140101ALI20240903BHJP
【ＦＩ】
H04N19/70
H04N19/597
H04N19/51
H04N19/105
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2024503505
(86)(22)【出願日】2022-08-05
(85)【翻訳文提出日】2024-03-14
(86)【国際出願番号】 IB2022057331
(87)【国際公開番号】W WO2023021362
(87)【国際公開日】2023-02-23
(31)【優先権主張番号】21192028.5
(32)【優先日】2021-08-18
(33)【優先権主張国・地域又は機関】EP
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕ－ｒａｙ
(71)【出願人】
【識別番号】591037214
【氏名又は名称】フラウンホッファー－ゲゼルシャフト ツァ フェルダールング デァ アンゲヴァンテン フォアシュンク エー．ファオ
(74)【代理人】
【識別番号】110002952
【氏名又は名称】弁理士法人鷲田国際特許事務所
(72)【発明者】
【氏名】スクピン ロベルト
(72)【発明者】
【氏名】バートニク クリスチャン
(72)【発明者】
【氏名】ヴィツコフスキー アダム
(72)【発明者】
【氏名】サンチェス デ ラ フエンテ ヤゴ
(72)【発明者】
【氏名】ヘルゲ コーネリアス
(72)【発明者】
【氏名】ブロス ベンヤミン
(72)【発明者】
【氏名】ツェル トーマス
(72)【発明者】
【氏名】ウィーガンド トーマス
(72)【発明者】
【氏名】マーペ デトレフ
【テーマコード（参考）】
5C159
【Ｆターム（参考）】
5C159MA04
5C159MA05
5C159MA21
5C159MC11
5C159ME01
5C159PP03
5C159PP16
5C159RC12
5C159TA30
5C159TA79
5C159TC32
5C159UA02
5C159UA05
(57)【要約】
動きベクトルラップアラウンド符号化ツールは、例えば、異なるビデオビットストリーム表現の間のスイッチングの下におけるセグメントのビデオビットストリーム形成に関して信頼できて利用されてもよい。ビデオエンコーダは、ピクチャのシーケンスに対して有効であって、ピクチャのシーケンス内の特定または全てのＲａｎｄｏｍ Ａｃｃｅｓｓ Ｓｋｉｐｐｅｄ Ｌｅａｄｉｎｇ（ＲＡＳＬ）ピクチャが、ラップアラウンド動き補償ツールを含む１つ以上の符号化ツールの所定のセットを除く方法で符号化されることを示す指示とビデオとをデータストリームに符号化する。ビデオデコーダは、ピクチャのシーケンス内の特定または全てのＲＡＳＬピクチャが、ラップアラウンド動き補償ツールを含む１つ以上の符号化ツールの所定のセットを除く方法で符号化されることを示す指示をデータストリームから復号化する。
【特許請求の範囲】
【請求項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】
前記エンコーダは、イントラ予測ブロック符号化モードとインター予測ブロック符号化モードとをサポートするよう構成される、請求項２０から２５の何れか一項に記載のビデオエンコーダ。
【請求項27】
前記ピクチャのシーケンスは、符号化順序で連続するピクチャを含み、前記ピクチャのシーケンスは、ＩＲＡＰピクチャから符号化順序で始まる、請求項２０から２６の何れか一項に記載のビデオエンコーダ。
【請求項28】
前記ピクチャのシーケンスは、符号化順序でＩＤＲピクチャに直接先行するピクチャにおいて終了し、前記ピクチャのシーケンスは、エンドオブシーケンスピクチャであると示されるピクチャにおいて終了する、請求項２７に記載のビデオエンコーダ。
【請求項29】
前記１つ以上の符号化ツールのセットは、１つ以上の非アクティブ化可能な符号化ツールを含み、各々はピクチャブロックへのそれの適用に関して、前記データストリーム内のコンフィギュレーション信号処理によってピクチャ又はスライスの単位で非アクティブ化可能である、請求項２０から２８の何れか一項に記載のビデオエンコーダ。
【請求項30】
前記指示は、前記ピクチャのシーケンス内の全てのＲＡＳＬピクチャが前記１つ以上の符号化ツールの所定のセットを除く方法で符号化される、請求項２０から２９の何れか一項に記載のビデオエンコーダ。
【請求項31】
前記指示は、前記ピクチャのシーケンス内の特定のＲＡＳＬピクチャが前記１つ以上の符号化ツールの所定のセットを除く方法で符号化され、前記特定のＲＡＳＬピクチャは、各ＲＡＳＬピクチャが関連付けされるＣＲＡピクチャに符号化順序で先行するリファレンスピクチャを有し、以降のピクチャの時間動きベクトル予測リファレンスピクチャとして機能し、及び／又は最も高い時間レイヤに属さない全てのＲＡＳＬピクチャを含む、請求項２０から３０の何れか一項に記載のビデオエンコーダ。
【請求項32】
前記１つ以上の符号化ツールのセットは更に、クロスコンポーネントリニアモデルベース予測ツールと、デコーダ側動きベクトル精緻化ツールとを含む、請求項２０から３１の何れか一項に記載のビデオエンコーダ。
【請求項33】
前記１つ以上の符号化ツールのセットは更に、クロスコンポーネントリニアモデルベース予測ツール（１００）を含む、請求項２０から３２の何れか一項に記載のビデオエンコーダ。
【請求項34】
前記クロスコンポーネントリニアモデルベース予測ツールによると、ピクチャブロック（１０ａ）のクロマコンポーネント（１０２）は、パラメータが前記ピクチャブロックの既に符号化された近傍（１１２）における外部のルマ及びクロマ値（１１０）から決定されるリニアモデル（１０６）を利用して、前記ピクチャブロック（１０ａ）のルマコンポーネント（１０４）から予測される、請求項３２又は３３に記載のビデオエンコーダ。
【請求項35】
前記１つ以上の符号化ツールのセットは、デコーダ側動きベクトル精緻化ツール（４００）を含む、請求項２０から３４の何れか一項に記載のビデオエンコーダ。
【請求項36】
前記デコーダ側動きベクトル精緻化ツールは、前記信号処理された動きベクトルにおいて及び周辺で動きベクトル候補からベストマッチサーチを実行することによって前記信号処理された動きベクトルを精緻化することによって、リファレンスピクチャ（４０４）から所定のインター予測ブロック（１０ｄ）をインター予測するため前記データストリームに符号化される信号処理された動きベクトル（４０２）を向上させるためである、請求項３４又は３５に記載のビデオエンコーダ。
【請求項37】
前記デコーダ側動きベクトル精緻化ツールは、前記リファレンスピクチャに関して前記インター予測ブロックの既に符号化された近傍を利用して前記ベストマッチサーチを実行するよう構成される、請求項３５に記載のビデオエンコーダ。
【請求項38】
前記デコーダ側動きベクトル精緻化ツールは、信号処理された動きベクトルのペアを含む及び周辺で動きベクトルペア候補からベストマッチサーチを実行することによって、所定のインター双方向予測ブロック（１０ｄ）のピクチャの時間的に以前及び以降に配置されるリファレンスピクチャ（４０４）のペアから前記所定のインター双方向予測ブロック（１０ｄ）をインター予測するため前記データストリームに符号化される信号処理された動きベクトル（４０２）のペアを精緻化するよう構成される、請求項３２又は３５に記載のビデオエンコーダ。
【請求項39】
データストリームにビデオを符号化するビデオエンコーダであって、前記ビデオエンコーダは、動き補償時間インター予測をサポートし、それによると、前記エンコーダは、リファレンスピクチャのリファレンスブロックに基づいてピクチャのインター予測ブロックを符号化するためのインター予測信号を取得し、動きベクトルは、前記ピクチャ内の前記インター予測ブロックの位置に関して前記リファレンスピクチャ内の前記リファレンスブロックの位置を示し、ラップアラウンド動き補償ツールによると、動き補償時間インター予測によって示される前記リファレンスブロックが前記ピクチャのピクチャコンテンツ境界を超える場合、前記ピクチャコンテンツ境界の対向するピクチャコンテンツ境界のラップアラウンドが前記リファレンスブロック及び／又は前記動きベクトルに適用され、
前記エンコーダは、前記リファレンスピクチャがピクチャサイズ及びスケーリングウィンドウの一方又は双方において前記ピクチャと異なる場合、前記リファレンスブロックが前記ピクチャの前記リファレンスピクチャの前記リファレンスブロック内に完全に配置されるように、前記ピクチャに対して前記動きベクトルを選択するよう構成される、ビデオエンコーダ。
【請求項40】
符号化されたビデオを有するデータストリームであって、前記ビデオのピクチャのシーケンスに対して有効であり、前記ピクチャのシーケンス内の特定又は全てのＲＡＳＬピクチャが、ラップアラウンド動き補償ツールを含む１つ以上の符号化ツールの所定のセットを除く方法で符号化されることを示す指示を含む、データストリーム。
【請求項41】
請求項２０から３８の何れか一項に記載のエンコーダによって生成される、請求項４０に記載のデータストリーム。
【請求項42】
符号化されたビデオを有するデータストリームであって、前記ビデオは、動き補償時間インター予測を利用して符号化され、それによると、前記ビデオは、リファレンスピクチャのリファレンスブロックに基づいてピクチャのインター予測ブロックを符号化するためのインター予測信号を利用して符号化され、動きベクトルは、前記ピクチャ内の前記インター予測ブロックの位置に関して前記リファレンスピクチャ内の前記リファレンスブロックの位置を示し、前記ラップアラウンド動き補償ツールによると、動き補償時間インター予測のため動きベクトルによって示される前記リファレンスブロックが前記ピクチャのピクチャコンテンツ境界を超える場合、前記ピクチャコンテンツ境界の対向するピクチャコンテンツ境界へのラップアラウンドが、前記リファレンスブロック及び／又は前記動きベクトルに適用され、
前記ビデオは、前記リファレンスピクチャがピクチャサイズ及びスケーリングウィンドウの一方又は双方において前記ピクチャと異なる場合、前記リファレンスブロックが前記ピクチャの前記リファレンスピクチャの前記リファレンスブロック内に完全に配置されるように、前記ピクチャのため前記動きベクトルを選択することによって符号化される、データストリーム。
【請求項43】
請求項３９に記載のエンコーダによって生成される、請求項４２に記載のデータストリーム。
【請求項44】
上記のデコーダ及びエンコーダの何れかによって実行される方法。
【請求項45】
コンピュータ上で実行されると、請求項４４に記載の方法の何れかを実行するプログラムコードを有するコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本出願の実施例は、ビデオビットストリーム、ビデオエンコーダ、ビデオデコーダ、ビデオシーケンスをビデオビットストリームに符号化する方法、及び、ビデオビットストリームからビデオシーケンスを復号化する方法に関する。さらなる実施例は、３６０度ビデオストリーミングにおける動きベクトル、動きベクトルラップアラウンド及び／又はオープンＧＯＰストリームスイッチングの処理に関する。
【背景技術】
【0002】
３６０度ビデオ又は全方位ビデオでは、等方形投影（ＥＲＰ）などのいくつかの投影フォーマットは、経時的に１つの垂直方向ピクチャ境界に向かって移動し、それを通過する物体を描写した特性を有し、反対の垂直方向ピクチャ境界上のピクチャプレーンに再び入る。ＶＶＣでは、ラップアラウンド動き補償と呼ばれる動き補償予測モードを使用して、符号化効率を高めるために投影フォーマットのこの特性を利用することができる。これは、移動ベクトルが垂直ピクチャ境界（又はピクチャ内の何らかの他の定義された垂直位置）を完全に又は部分的に包み込み、拡張された予測ブロック信号、例えば、両方のピクチャ境界からのサンプル位置からの複合的な予測信号を一度に提供することを可能にすることによって実現される。図６は、現在ブロックの位置（実線）及びそのリファレンスブロックの位置（破線）が描かれるラップアラウンド動き補償の原理の例示を示す。リファレンスブロックのサンプルは、部分的に右ピクチャ境界の外側に位置し、この場合、左ピクチャ境界からのサンプルが予測信号を生成するために使用されることが分かる。
【0003】
例えば、このような３６０度ビデオストリーミングシナリオは、ＨＴＴＰストリーミングによって実現されてもよい。符号化ビデオのＨＴＴＰストリーミングは、過去１０年間にわたるビデオ配信の重要なパスとなっており、ＯＴＴサービスプロバイダは、現在、公衆インターネットを介して何億人ものユーザに到達することができる。ダイナミック・アダプティブ・ストリーミング・オーバＨＴＴＰ（ＤＡＳＨ）のような標準的なプロトコルは、サービスプロバイダが時間的にセグメント化された形式で様々なビットレートでメディアをサーバに提供させることによって、メディアをクライアントにストリーミングすることを可能にする。次いで、クライアントデバイスは、利用可能なネットワークバンド幅及びその復号化能力に従って特定のセグメントの提供された変形例の中からダイナミックで適応的な方法で選択することによって、連続的な再生のための連続するセグメントをダウンロードすることができる。実際には、コンテンツは、特定のビットレートに対して知覚される品質を最適化し、それによってユーザ体験を最適化するため、しばしば複数の解像度及び忠実度を伴う最適化されたビットレートラダーによって生成される複数のいわゆる表現として提供される。各セグメントは、典型的には、いわゆるクローズド・グループ・オブ・ピクチャ（ＧＯＰ）符号化構造を使用して、以前のセグメントに依存せずに符号化されるため、ダウンロード及びデパケット化されたセグメントデータは、準拠するビットストリームに連結され、デコーダに供給されうる。このようなクローズドＧＯＰ構造とは反対に、いわゆるオープンＧＯＰ符号化構造を使用するセグメントは、符号化効率に利益をもたらす以前のセグメントにおけるピクチャからのインター予測を使用するいくつかのピクチャを含む。以前のセグメントからのインター予測を使用するピクチャは、プレゼンテーション順序で最初に来るセグメントにランダムにアクセスするとき、再生問題又は視覚的アーチファクトなしに出力されることからスキップされうるが、これらのピクチャはそのような非シームレススイッチでスキップされるため、連続再生中に解像度スイッチが行われるとき、問題が生じる。純粋なビットレートスイッチングにおいてさえ、セグメントがスイッチングのために適切には符号化されないとき、いくつかのピクチャはドロップされるか、又は深刻な視覚的アーチファクトを表しうる。
【0004】
ストリーミングシナリオの更なる例では、ＥＲＰのような３６０度ビデオの異なる部分が異なる解像度で提供され、ユーザが高品質で消費する可能性が高い部分を提供する一方で、フォールバックオプションとして意図されたより低い品質の他の部分のみを提供することを目的とする。このようにして、ストリーミングされなければならないデータの量が低減されうる。また、このシナリオでは、デコーダに提供されるピクチャの解像度は変化しうる。
【0005】
ＡＶＣ及びＨＥＶＣなどの普及した以前の世代のコーデックは、異なる解像度のリファレンスピクチャを使用するために必要とされるリファレンスピクチャリサンプリング（ＲＰＲ）機能を提供しない。従って、解像度スイッチング後、そのようなオープンＧＯＰ構造で実行されると、セグメントのいくつかのピクチャは、以前のセグメントからのリファレンスピクチャが必要とされる解像度で利用可能でないため、正しく復号化できず、その結果、ドロップされたピクチャからのセグメントスイッチにおける一定でないフレームレートの再生を生じさせる。オープンＧＯＰ解像度スイッチングの問題を克服するためのいくつかのアプローチは、ＨＥＶＣ復号化処理に対する規範的な変更を利用すること、又はＲＰＲ機能を提供するＨＥＶＣ（ＳＨＶＣ）のあまり普及していないスケーラブル拡張を利用することを含む。しかしながら、これらのアプローチは、現在、ＨＴＴＰストリーミングにおけるオープンＧＯＰ符号化の実質的な採用を可能にしない。
【0006】
ＶＶＣ（Ｖｅｒｓａｔｉｌｅ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）規格の最近のバージョン１は、ＩＴＵ－ＴのＶｉｄｅｏ Ｃｏｄｉｎｇ Ｅｘｐｅｒｔ Ｇｒｏｕｐ及びＭｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐとしても知られるＩＳＯ／ＩＥＣのＳｕｂ Ｃｏｍｍｉｔｔｅｅ ２９の共同作業から出現した最新のビデオ符号化規格である。より以前の世代のコーデックと比較して符号化効率を大幅に向上させることは別として、ＶＶＣはまた、ＲＰＲなどの初期のＭａｉｎ １０プロファイルに多くのアプリケーションドリブンな特徴を含む。ＶＶＣの開発中、ＲＰＲは主に低遅延符号化構造による会話シナリオの文脈で研究された。そこでは、遅延とバッファサイズに対する現実世界の要件が、解像度スイッチングのためのイントラ符号化ピクチャの挿入の実現性の厳しい限界を設定した。
【0007】
しかしながら、ＶＶＣにおけるＲＰＲは、ストリーミング領域のためのビデオ符号化における符号化効率に実質的な利益を提供することもできる。
【0008】
動きベクトルの信頼できる処理、特に、ストリーミングシナリオにおける動きベクトルのラップアラウンドの信頼できる処理を可能にする概念を手元に有することが好ましい。特に、ＶＶＣのようなコーデックを用いたＨＴＴＰストリーミングにおけるオープンＧＯＰ解像度スイッチングに関して、動作ベクトルラップアラウンドを処理するための概念を有することが好ましいであろう。
【発明の概要】
【0009】
したがって、例えば、異なるビデオビットストリーム表現の間のスイッチングの下、セグメントビデオビットストリーム形成のコンテキストに関して、動きベクトルのラップアラウンドコーディングツールの信頼できる使用を可能にするビデオコーディング概念を提供することが課題である。
【0010】
この課題は、本出願の独立請求項の主題によって達成される。本出願の有利な態様は、従属請求項の主題である。本出願の例示的な実施例が、図面に関して以下に説明される。
【図面の簡単な説明】
【0011】
【図1】例えば、変換ベースの残差符号化を利用してピクチャをデータストリームに予測符号化する装置を示す。
【図2】対応するデコーダを示す。
【図3】再構成される信号と、データストリームに信号化されるような予測残差信号と予測信号との組み合わせとの間の関係を示す。
【図4】所与のレイヤまですべてのピクチャを復号化することが所与のフレームレートに対応し、対応する時間Ｉｄ（Ｔｅｍｐｏｒａｌ Ｉｄ：Ｔｉｄ）値が８つのピクチャのＧＯＰサイズの各ピクチャに割り当てられる時間スケーラビリティに利用されるＧＯＰの階層構造の一例を示す。
【図5】ピクチャを符号化するのに適用されうるラップアラウンド動き補償ツールを示す。
【図6】現在ブロック（実線）の位置とそれのリファレンスブロック（破線）の位置とが示される３６０度ビュー及びラップアラウンド動き補償を表すピクチャの例を示す。
【図8】ボトムにおいて１つの低品質フォールバックタイルと時間的に可変数の高品質タイルとを備えるタイルベースのビューポート適応的ストリーミングの例を示す。
【図9】実施例によるビデオデコーダを示す。
【図10】ビデオをデータストリームに符号化するエンコーダを示す。
【発明を実施するための形態】
【0012】
以下では、実施例について詳述するが、本実施例は、広く多様なビデオ符号化概念に具現化され得る多くの適用可能な概念を提供することを理解されるべきである。説明される具体的な実施例は、本概念を実施及び利用するための具体的な方法の単なる例示であり、本実施例の範囲を限定するものではない。以下の説明では、本開示の実施例をより完全に説明するため複数の詳細が説明される。しかしながら、他の実施例がこれら具体的な詳細なしに実施され得ることは、当業者には明らかであろう。他の例では、周知の構成及びデバイスは、ここで説明される具体例を不明瞭にすることを避けるため、詳細ではなくブロック図の形式で示される。さらに、ここに説明される異なる実施例の特徴は、特に断りのない限り、互いに組み合わせることができる。
【0013】
以下の実施例の説明において、同一の機能を有する同一又は類似の要素には、同一の参照符号を付したり、又は、同一の名称を付し、同一の参照符号が付されたり、又は、同一の名称によって識別される要素の繰り返しの説明は、典型的には省略される。したがって、同じ参照符号を有する要素又は同じ名称で識別される要素について提供される説明は、相互に交換可能であるか、又は、様々な実施例で互いに適用され得る。
【0014】
図面の以下の説明は、実施形態が組み込まれ得る符号化フレームワークの例を形成するため、ビデオのピクチャを符号化するためのブロックベースの予測コーデックのエンコーダ及びデコーダの説明を提示することから始まる。エンコーダ及びデコーダはそれぞれ、図１～図３に関して説明される。以下では、例示的な実施例の説明は、そのような概念をそれぞれ図１及び図２のエンコーダ及びデコーダにどのように組み込むことができるかに関する説明とともに提示されるが、後続の図４以降で説明する実施例は、図１及び図２のエンコーダ及びデコーダの基礎をなす符号化フレームワークに従って動作しないエンコーダ及びデコーダを形成するため利用されてもよい。
【0015】
図１は、例示的に変換ベースの残差符号化を利用して、ピクチャＡ１２をデータストリームＡ１４に予測符号化するための装置を示す。装置又はエンコーダは、参照符号Ａ１０を使用して示される。図２は、対応するデコーダＡ２０、すなわち、変換ベース残残差復号化を利用してデータストリームＡ１４からピクチャＡ１２´を予測復号化するように構成された装置Ａ２０を示す。ここで、アポストロフィは、デコーダＡ２０によって再構成されたピクチャＡ１２´が、予測残差信号の量子化によって導入される符号化損失に関して装置Ａ１０によって最初に符号化されたピクチャＡ１２から乖離することを示すために使用されている。図１及び図２は、例示的に変換ベースの予測残差符号化を利用するが、本出願の実施例は、このタイプの予測残差符号化に限定されない。これは、以下に概説されるように、図１及び図２に関連して説明される他の詳細にも成り立つ。
【0016】
エンコーダＡ１０は、予測残差信号に空間スペクトル変換に実行し、このようもして得られた予測残差信号をデータストリームＡ１４に符号化するように構成される。同様に、デコーダＡ２０は、データストリームＡ１４から予測残差信号を復号化し、このようにして得られた予測残差信号にスペクトル空間変換を実行するように構成される。
【0017】
内部的には、エンコーダＡ１０は、元の信号、すなわちピクチャＡ１２からの予測信号Ａ２６の乖離を測定するため、予測残差Ａ２４を生成する予測残差信号形成器Ａ２２を備え得る。予測残差信号形成器Ａ２２は、例えば、元の信号から、すなわちピクチャＡ１２から予測信号を減算する減算器であってもよい。エンコーダＡ１０は、次いで、予測残差信号Ａ２４に空間スペクトル変換を実行し、スペクトル領域予測残差信号Ａ２４´を取得する変換器Ａ２８をさらに備え、スペクトル領域予測残差信号Ａ２４´は、エンコーダＡ１０に含まれる量子化器Ａ３２によって量子化される。このように量子化された予測残差信号Ａ２４″は、ビットストリームＡ１４に符号化される。 この目的のため、エンコーダＡ１０は、データストリームＡ１４に変換及び量子化される予測残差信号をエントロピー符号化するエントロピー符号化器Ａ３４を任意的に備えることができる。予測信号Ａ２６は、データストリームＡ１４に符号化され、そこから復号化可能な予測残差信号Ａ２４″に基づいてエンコーダＡ１０の予測ステージＡ３６によって生成される。この目的のため、図１に示されるように、予測ステージＡ３６は、量子化損失以外の信号Ａ２４´に対応するスペクトル領域予測残差信号Ａ２４´´´を得るため、予測残差信号Ａ２４″を逆量子化する逆量子化器Ａ３８を含んでもよく、その後、予測残差信号Ａ２４´´´に逆変換を実行し、すなわちスペクトル空間変換を実行し、量子化損失以外の元の予測残差信号Ａ２４に対応する予測残差信号Ａ２４″″を得る逆変換器Ａ４０を含み得る。予測ステージＡ３６の合成器Ａ４２は、例えば加算によって、予測信号Ａ２６及び予測残差信号Ａ２４″″を再合成し、再構成される信号Ａ４６、すなわち元の信号Ａ１２の再構成を得る。再構成された信号Ａ４６は、信号Ａ１２´に対応し得る。予測ステージＡ３６の予測モジュールＡ４４は、次いで、例えば、空間予測、すなわち、イントラピクチャ予測及び／又は時間予測、すなわち、インターピクチャ予測を利用することによって、信号Ａ４６に基づいて予測信号Ａ２６を生成する。
【0018】
同様に、デコーダＡ２０は、図２に示されるように、予測ステージＡ３６に対応する構成要素から内部的に構成され、また対応する方法で相互接続され得る。特に、デコーダＡ２０のエントロピーデコーダＡ５０は、データストリームから量子化されたスペクトル領域予測残差信号Ａ２４″をエントロピー復号化することができ、逆量子化器Ａ５２、逆変換器Ａ５４、合成器Ａ５６及び予測モジュールＡ５８は、予測ステージＡ３６のモジュールに関して上述した方法で相互接続されて協働すると、予測残差信号Ａ２４″に基づいて再構成された信号を復元し、その結果、図２に示すように、合成器Ａ５６の出力は、再構成された信号、すなわちピクチャＡ１２´をもたらす。
【0019】
具体的には上述されていないが、エンコーダＡ１０は、例えば、あるレート及び歪みに関連する基準、すなわち、符号化コストを最適化する方法など、いくつかの最適化スキームに従って、例えば、予測モード、動きパラメータなどを含むいくつかの符号化パラメータを設定し得ることは、容易に明らかである。例えば、エンコーダＡ１０及びデコーダＡ２０並びに対応するそれぞれのモジュールＡ４４、Ａ５８は、イントラ符号化モード及びインター符号化モードなどの異なる予測モードをサポートし得る。エンコーダ及びデコーダがこれらの予測モードタイプ間で切り替わる粒度は、それぞれ、ピクチャＡ１２及びＡ１２´の符号化セグメント又は符号化ブロックへの分割に対応し得る。これらの符号化セグメントの単位では、例えば、ピクチャは、イントラ符号化されているブロックとインター符号化されているブロックとに再分割され得る。イントラ符号化されたブロックは、以下でより詳細に概説するように、それぞれのブロックの空間的なすでに符号化／復号化された近傍に基づいて予測される。いくつかのイントラ符号化モードが存在し、それぞれの方向性イントラ符号化モードに固有のある方向に沿って近傍のサンプル値をそれぞれのイントラ符号化セグメントに外挿することによって各セグメントが充填される方向性又は角度イントラ符号化モードを含むそれぞれのイントラ符号化セグメントのために選択され得る。イントラ符号化モードは、例えば、それぞれのイントラ符号化ブロックの予測がそれぞれのイントラ符号化セグメント内の全てのサンプルにＤＣ値を割り当てるＤＣ符号化モード、及び／又は、それぞれのブロックの予測が隣接するサンプルに基づいて２次元線形関数によって定義される平面の駆動傾斜及びオフセットによってそれぞれのイントラ符号化ブロックのサンプル位置にわたって２次元線形関数によって記述されるサンプル値の空間分布であると近似又は決定される平面イントラ符号化モードなどの１つ以上のさらなるモードを備え得る。それと比較して、インター符号化ブロックは、例えば、時間的に予測され得る。インター符号化ブロックについて、動きベクトルはデータストリーム内に信号化され、当該動きベクトルは、それぞれのインター符号化ブロックの予測信号を取得するため、以前に符号化／復号化されたピクチャがサンプリングされるピクチャＡ１２が属するビデオの以前に符号化されたピクチャの部分の空間変位を示す。これは、量子化スペクトル領域予測残差信号Ａ２４″を表すエントロピー符号化変換係数レベルなど、データストリームＡ１４によって構成される残差信号符号化に加えて、データストリームＡ１４は、符号化モードを様々なブロックに割り当てるための符号化モードパラメータ、インター符号化セグメントのための動きパラメータなど、ブロックのいくつかのための予測パラメータ、及びピクチャＡ１２、Ａ１２´の分割をそれぞれセグメントに制御及び信号化するためのパラメータなど、任意のさらなるパラメータを符号化し得ることを意味する。デコーダＡ２０は、これらのパラメータを使用して、エンコーダが行ったのと同じ方法でピクチャを分割し、セグメントに同じ予測モードを割り当て、同じ予測を実行して同じ予測信号を得る。
【0020】
図３は、一方では再構成された信号、すなわち、再構成されたピクチャＡ１２´と、他方ではデータストリームＡ１４に信号化された予測残差信号Ａ２４″″と予測信号Ａ２６との組み合わせとの間の関係を示す。上述したように、当該組み合わせは加算であってもよい。予測信号Ａ２６は、図３において、ハッチングで例示的に示されるイントラ符号化ブロックと、ハッチングで例示的に示されないインター符号化ブロックとへのピクチャ領域の分割として示されている。当該分割は、ピクチャ領域を正方形ブロック又は非正方形ブロックの行及び列に規則的に細分すること、又はツリールートブロックからクワッドツリー細分などの可変サイズの複数のリーフブロックにピクチャＡ１２をマルチツリー細分することなど、任意の細分であってよく、図３には、ピクチャ領域が最初にツリールートブロックの行及び列に細分され、次いで、再帰的マルチツリー細分に従って１つ以上のリーフブロックにさらに細分される、それらの混合が示される。
【0021】
再び、データストリームＡ１４は、イントラ符号化ブロックＡ８０のためにそれに符号化されたイントラ符号化モードを有してもよく、イントラ符号化ブロックＡ８０は、いくつかのサポートされるイントラ符号化モードのうちの１つをそれぞれのイントラ符号化ブロックＡ８０に割り当てる。インター符号化ブロックＡ８２について、データストリームＡ１４は、それに符号化された１つ以上の動きパラメータを有し得る。一般的に言えば、インター符号化ブロックＡ８２は、時間的に符号化されることに限定されない。あるいは、インター符号化ブロックＡ８２は、ピクチャＡ１２が属するビデオ、例えばビュー又はレイヤの以前に符号化されたピクチャ、又はエンコーダ及びデコーダがそれぞれスケーラブルエンコーダ及びデコーダである場合における他のビュー又は階層的に下位のレイヤのピクチャなど、現在ピクチャＡ１２自体を超える以前に符号化された一部から予測される任意のブロックであり得る。
【0022】
図３の予測残差信号Ａ２４″″は、ピクチャ領域をブロックＡ８４に細分するものとして示される。これらのブロックは、符号化ブロックＡ８０及びＡ８２と区別するために、変換ブロックと呼ばれることがある。実際には、図３は、エンコーダＡ１０及びデコーダＡ２０が、それぞれピクチャＡ１２及びピクチャＡ１２´のブロックへの２つの異なる分割、すなわち、符号化ブロックＡ８０及びＡ８２への１つの分割と、変換ブロックＡ８４へのもう１つの分割とを利用し得ることを示す。双方の分割は同じであってもよく、すなわち、各符号ブロックＡ８０及びＡ８２は変換ブロックＡ８４を同時に形成してもよいが、図３は、例えば、変換ブロックＡ８４への分割が符号化ブロックＡ８０、Ａ８２への分割の拡張を形成し、その結果、ブロックＡ８０及びＡ８２の２つのブロック間の境界が２つのブロックＡ８４の間の境界をオーバレイするか、又は、あるいは、各ブロックＡ８０、Ａ８２が変換ブロックＡ８４のうちの１つと一致するか、又は、変換ブロックＡ８４のクラスタと一致するケースを示す。しかしながら、変換ブロックＡ８４がブロックＡ８０、Ａ８２の間のブロック境界を代替的に横切ることができるように、分割はまた互いに独立して決定又は選択されてもよい。変換ブロックＡ８４への分割に関する限り、同様の説明がブロックＡ８０、Ａ８２への分割に関して提起されるものとして成り立ち、すなわち、ブロックＡ８４は、ピクチャ領域のブロックへの通常の分割の結果（行及び列への配置によって又は配置によってでない）、ピクチャ領域の再帰的マルチツリー分割の結果、又はそれらの組み合わせ若しくは何れか他のタイプのブロック化の結果であり得る。換言すると、ブロックＡ８０、Ａ８２及びＡ８４は、二次、矩形又は任意の他の形状に限定されないことに留意されたい。図３は、予測信号Ａ２６と予測残差信号Ａ２４″″との組み合わせが再構成された信号Ａ１２´を直接もたらすことをさらに示す。しかしながら、代替的な実施例に従ってピクチャＡ１２´をもたらすため、２つ以上の予測信号Ａ２６が予測残差信号Ａ２４″″と組み合わされ得ることに留意されたい。
【0023】
図３において、変換ブロックＡ８４は、以下の重要性を有するものとする。変換器Ａ２８及び逆変換器Ａ５４は、これらの変換ブロックＡ８４の単位でそれらの変換を実行する。例えば、多くのコーデックは全ての変換ブロックＡ８４に対してあるタイプのＤＳＴ又はＤＣＴを利用する。いくつかのコーデックは、変換ブロックＡ８４のうちのいくつかについて、予測残差信号が空間領域において直接符号化されるように、変換をスキップすることを可能にする。しかしながら、以下で説明する実施例によると、エンコーダＡ１０及びデコーダＡ２０は、それらがいくつかの変換を支援するように構成される。例えば、エンコーダＡ１０及びデコーダＡ２０によってサポートされる変換は以下を構成しうる。
・ＤＣＴ－ＩＩ（又はＤＣＴ－ＩＩＩ）、ここでＤＣＴは離散コサイン変換を表す
・ＤＳＴ－ＩＶ、ここで、ＤＳＴは離散サイン変換を表す
・ＤＣＴ－ＩＶ
・ＤＳＴ－ＶＩＩ
・恒等変換（ＩＴ）
・ＤＣＴ－ＩＩ（又はＤＣＴ－ＩＩＩ）、ここでＤＣＴは離散コサイン変換を表す
・ＤＳＴ－ＩＶ、ここで、ＤＳＴは離散サイン変換を表す
・ＤＣＴ－ＩＶ
・ＤＳＴ－ＶＩＩ
・恒等変換（ＩＴ）
【0024】
当然ながら、変換器Ａ２８はこれらの変換の順変換バージョンの全てをサポートするが、デコーダＡ２０又は逆変換器Ａ５４はそれの対応する後方又は逆変換バージョンをサポートするであろう。
・逆ＤＣＴ－ＩＩ（又は逆ＤＣＴ－ＩＩＩ）
・逆ＤＳＴ－ＩＶ
・逆ＤＣＴ－ＩＶ
・逆ＤＳＴ－ＶＩＩ
・恒等変換（ＩＴ）
・逆ＤＣＴ－ＩＩ（又は逆ＤＣＴ－ＩＩＩ）
・逆ＤＳＴ－ＩＶ
・逆ＤＣＴ－ＩＶ
・逆ＤＳＴ－ＶＩＩ
・恒等変換（ＩＴ）
【0025】
以降の説明は、何れの変換がエンコーダＡ１０及びデコーダＡ２０によってサポート可能な更なる詳細を説明する。何れの場合においても、サポートされる変換のセットは、あるスペクトル空間又は空間スペクトル変換などの単に１つの変換から構成されてもよいことに留意すべきである。
【0026】
上述したように、図１～３は、本出願によるエンコーダ及びデコーダの具体例を形成するために、以下でさらに説明する本発明の概念が実装され得る例として提示されている。その限りにおいて、図１及び図２のエンコーダ及びデコーダはそれぞれ、ここで以下に説明するエンコーダ及びデコーダの可能な実施形態を表し得る。しかしながら、図１及び図２は単なる具体例である。しかしながら、本出願の実施例によるエンコーダは、以下でより詳しく概説される概念を使用してピクチャＡ１２のブロックベース符号化を実行することができ、例えば、ブロックＡ８０への分割が、図３に例示されるものとは異なる方法で実行されるなど、図１のエンコーダとは異なる概念を利用してピクチャＡ１２のブロックベース符号化を実行することができる。同様に、本出願の実施例によるデコーダは、以下でさらに概説される符号化概念を利用して、データストリームＡ１４からピクチャＡ１２´のブロックベース復号化を実行することができるが、例えば、図２のデコーダＡ２０とは、同じものがイントラ予測をサポートしないという点で、又は、同じものがピクチャＡ１２´を、図３に関して説明されるものとは異なる方法でブロックに分割するという点で、及び／又は、同じものが変換領域でなく空間領域においてデータストリームＡ１４から予測残差を導出する点で、異なりうる。
【0027】
上述したように、図１～３は、本出願の後述される実施例が基づきうるビデオコーデックの概略を提供することを単に意図している。例えば、ＶＶＣは、図１及び２のビデオデコーダ及びビデオエンコーダが調整されうるビデオコーデックの具体例である。
【0028】
以下の説明は、以下のように構成される。予備的には、ＶＶＣがビデオコーデック環境の例として使用され、この例に基づいて、以下の説明は、セグメントスイッチにおけるピクチャ品質インパクトと同様に、オープンＧＯＰ符号化構造の一般的な符号化効率インパクトを調査する実験に関する報告を提供する。ここでも、後述する実施例は、ＶＶＣに限定されず、これらの実施例に関して論じられる符号化ツールは、ＶＶＣに関して論じられるものに限定されず、これらの試験とその結果の提示は、後述する実施例につながる動機付けを提供する。さらに、以降の説明は、ＧＯＰ符号化構造及びセグメント化の概要を提供し、次いで、オープンＧＯＰ解像度スイッチングなどのオープンＧＯＰスイッチングを可能にするための制約された符号化を提示し、スイッチングに関連するドリフトを効果的に制限する。その後、本出願のいくつかの実施例が提示され、それらは、ＶＶＣに関する考察から明らかになる。
【0029】
以下は、ストリーミングのためのＶＶＣビットストリーム及びメディアセグメンテーション内の構造の概要を提供する。メディアセグメントは、一般に、イントラ符号化ツールのみを使用して、イントラランダムアクセスポイント（ＩＲＡＰ）ピクチャと整列される。ＩＲＡＰピクチャは、シーキング又は早送りなどの機能を可能にするためだけでなく、適応ＨＴＴＰストリーミングのためのスイッチングポイントとしても働くため、符号化ビデオビットストリームに頻繁に現れうる。ビデオオンデマンド（ＶｏＤ）ストリーミングのためのシステムは、典型的には、セグメントをＩＲＡＰピクチャ期間と整列させ、すなわち、ＩＲＡＰピクチャは、典型的には、セグメントスタートに配置され、所望のセグメント持続時間は、ＩＲＡＰピクチャ間の時間的距離を決定する。しかしながら、例えば、全てのメディアセグメントがＩＲＡＰピクチャを含むとは限らない非常に低遅延のストリーミングのようなユースケースが存在し、その結果、小さなセグメントはＩＲＡＰピクチャを待つ必要なく送信に利用可能とすることができ、従って、コンテンツ生成側での遅延を低減する。セグメントサイズは、ターゲットアプリケーションに応じて長さが異なりうる。例えば、ＶｏＤサービスは、プレーヤがスループット変動を克服するためより大きなバッファ（例えば、３０秒）を構築することを可能にし、数秒（例えば、５秒）までのセグメントサイズが１つの可能なアプローチであり得る。しかしながら、より厳しいエンドツーエンド遅延を要求するライブサービスは、クライアント側でそのような大きなバッファを許容せず、したがって、より頻繁なスイッチングポイント及び１秒以下のより短いセグメントを要求する。
【0030】
２つのＩＲＡＰピクチャの間のピクチャは、典型的には、復号化遅延要件が許す限り、提示の前に再順序付けを含む双方向予測された階層的ＧＯＰ構造に符号化される。なぜなら、そのような構造は、ＡＶＣに導入されたような実質的な符号化効率の利点を提供するからである。ＧＯＰの階層構造は、所与のレイヤまですべてのピクチャを復号化することは所与のフレームレートに対応し、対応する時間Ｉｄ（Ｔｉｄ）値が、８ピクチャのＧＯＰサイズに対して、図４に示すように、各ピクチャに割り当てられる時間スケーラビリティに用いることができる。ＧＯＰは、復号順序において、第１のＴｉｄ ０ピクチャから以降のＴｉｄ ０ピクチャを含まない全てのピクチャとして規定できる。典型的には、セグメントは、ＩＲＡＰ期間及びＧＯＰサイズに応じて１つ以上のＧＯＰ構造を含む。ＨＥＶＣでは、復号化ピクチャバッファ（ＤＢＰ）内のリファレンスピクチャスロットの数は、１６ピクチャの典型的なＧＯＰサイズを可能にしたが、ＤＰＢ容量はＶＶＣにおいて増加し、最大３２ピクチャまでの階層的ＧＯＰサイズを可能にする。
【0031】
復号化順序でＩＲＡＰピクチャに続くが、提示順序でそれに先行するピクチャは、ＨＥＶＣに導入され、リーディングピクチャと呼ばれる。それらはさらに、ランダムアクセススキップリーディング（ＲＡＳＬ）及びランダムアクセスデコーダブルリーディング（ＲＡＤＬ）に区別することができる。ＲＡＤＬピクチャは、復号化順序においてＩＲＡＰピクチャからのリファレンスピクチャのみを使用することができるが、ＲＡＳＬピクチャは、加えてＩＲＡＰに先行するリファレンスピクチャを利用してもよい。瞬間ランダムアクセス（Ｉｎｓｔａｎｔａｎｅｏｕｓ Ｒａｎｄｏｍ Ａｃｃｅｓｓ：ＩＤＲ）タイプのＩＲＡＰピクチャは、ＤＢＰをリセットし、いわゆるクローズドＧＯＰ構造をもたらすＲＡＤＬピクチャであるリーディングピクチャのみを有することができる。他方、クリーンランダムアクセス（Ｃｌｅａｎ Ｒａｎｄｏｍ Ａｃｃｅｓｓ：ＣＲＡ）タイプのさらなるＩＲＡＰピクチャは、ＤＰＢをリセットしない。したがって、復号化順序でＣＲＡの前から再構成されたピクチャは、以降のピクチャ、すなわち、いわゆるオープンＧＯＰ符号化構造を可能にするＲＡＳＬピクチャのリファレンスとして利用可能である。ＲＡＳＬピクチャは、ＲＡＤＬピクチャと比較して符号化効率の向上を示すが、リファレンスピクチャが利用可能でないとき、例えば、以前のセグメントを復号化することなく、セグメントの開始時の関連付けられたＩＲＡＰにおけるランダムアクセス中に、復号化不可にし得る。ＶＶＣのハイレベルシンタックスのより詳細な概要が、Y.-K. Wang et al., “The High-Level Syntax of the Versatile Video Coding (VVC) Standard,” IEEE Trans. Circuits Syst. Video Technol., in pressに記載されている。
【0032】
図４は、例えば、異なる解像度を有する２つの連続するセグメントの連結からのビデオデータストリームの形成を示し、第２のセグメントは第１のセグメントからのリファレンスピクチャを有するオープンＧＯＰ符号化構造を使用する。特に、参照されるリファレンスピクチャは、矢印が出現する図４の矩形である。矢印自体は予測の相互依存性を示し、すなわち、それらはリファレンスピクチャから参照しているピクチャを指す。各ピクチャは、特定の時間ＩＤ Ｔｉｄに関連付けられ、理解できるように、符号化順序はピクチャの出力／提示順序から乖離する。理解できるように、出力順序ランク９～１５のピクチャは、自らのセグメント、セグメント１のＣＲＡピクチャを直接的又は間接的に参照するＲＡＳＬピクチャとともに、以前のセグメント、セグメント０に由来するピクチャ、主に出力順序ランク８を有するピクチャに属する。
【0033】
ＲＡＳＬピクチャのリファレンスピクチャが以前のセグメントに位置し、ストリーミングクライアントがそのような以前のセグメントの後に表現をスイッチするとき、クライアントによってダウンロードされて構成されたビットストリームを受信するクライアントデコーダは、エンコーダ側と比較して、リファレンスピクチャの少なくとも一部の異なる変形を利用してＲＡＳＬピクチャを復号化する。そのような状況は、内容が適切に生成されない場合、又は、再構成されたＲＡＳＬピクチャにおいて重大な不一致になり、このドリフトが、関連するＣＲＡピクチャまでであるがそれを含まない全てのＲＡＳＬピクチャに伝搬し得る場合、不適合ビットストリームにつながり得る。以下では、セグメントスイッチにおけるビットストリーム適合性を維持し、スイッチ中の視覚的な品質に有害である望ましくないドリフトを回避しながら、オープンＧＯＰ構造を使用することを可能にするコンテンツの適切な生成について説明する。
【0034】
例えば、図４に示す２つのセグメントは、データストリームに符号化されたビデオのピクチャの系列の一部であってもよい。ピクチャのシーケンスは、例えば、符号化ビデオシーケンス（ＣＶＳ）であり得る。ピクチャのシーケンスのピクチャは、符号化順序で連続し得る。ピクチャのシーケンスは、ＩＲＡＰピクチャ、例えば、ＩＤＲピクチャ又はＣＲＡピクチャからスタートしうる。ピクチャのシーケンスは、符号化順序でピクチャの連続するシーケンスの第１のピクチャに直接先行するピクチャ、すなわち、ＩＤＲ又はＣＲＡピクチャに直接先行するピクチャで終了し得る。後者の場合、最後のピクチャは、ビットストリームにおいてシーケンスの終わりのピクチャであることが示され得る。
【0035】
図５は、ピクチャ１２、例えば図１のピクチャＡ１２を符号化する際に適用され得るラップアラウンド動き補償ツールを示す。図５では、提示順序２２の異なるタイムスタンプに属する２つのピクチャ１２１及び１２２が示される。図５に示されるシナリオによると、ピクチャ１２１は、ピクチャ１２２をリファレンスピクチャとして使用する動き補償時間インター予測を利用して符号化される。このため、ピクチャ１２１のブロック１０は、リファレンスピクチャ１２２のリファレンスブロック１１を使用してインター予測される。リファレンスピクチャ１２２はピクチャ１２１より以前又は以後の別のタイムフレームに属するため、コンテンツはピクチャ１２１に関してリファレンスピクチャ内を移動していてもよい。したがって、リファレンスブロック１１は、リファレンスピクチャ１２２内のブロック１０のコロケートされた位置１０´に対してシフトされ得る。動きベクトル１３は、ブロック１０のコロケートされた位置１０´に対するリファレンスブロック１１の位置を示すために使用される。図５では、リファレンスブロック１１の２つの具体例、すなわち、その位置が動きベクトル１３１によって示されるリファレンスブロック１１１と、その位置が動きベクトル１３２によって示されるリファレンスブロック１１２とが示されている。
【0036】
リファレンスブロック１１１の例に示されるように、リファレンスブロックは、ピクチャ境界、例えば、図５の例では垂直方向のピクチャ境界であるピクチャ境界１５を超えることができるが、概して、ピクチャ平面の第１の向きのピクチャ境界であってもよい。同様に、動きベクトル１３２に例示されるように、動きベクトルは、ピクチャ境界１５を超えてもよい。ビデオ、したがってピクチャ１２１、１２２は、例えば、３６０度ビューを表すことができ、すなわち、ピクチャ１２のコンテンツは、ピクチャ平面の少なくとも１つの方向、例えば、水平方向において、３６０度ビューをカバーする。したがって、ピクチャ境界１６におけるピクチャのコンテンツは、ピクチャ境界１５とは反対であり、第１の方向に沿っても配向されているが、ピクチャ境界１６からピクチャ境界１５への方向を考慮すると、ピクチャ境界１５におけるコンテンツの続きである。したがって、リファレンスブロック１１１がピクチャ境界１５を超える場合、リファレンスブロック１１１のピクチャ境界を超える部分１７が、リファレンスピクチャ１２２の部分１７´にマッピングされ得る。部分１７´は、対向するピクチャ境界１６においてリファレンスピクチャ１２２内に位置する。例えば、その部分は、リファレンスブロック１１１の部分１７と垂直方向に関して同じ位置、すなわち、概してピクチャ境界１５の方向を有することができる。言い換えれば、ラップアラウンドは、リファレンスブロック１１１に適用されてもよい。同様に、ピクチャ境界１５を超える動きベクトル１３２は、対向するピクチャ境界１６において継続され得る。すなわち、画像境界１５を超える動きベクトル１３２の一部１９は、図５にマッピングされた動きベクトル１９´として示されるように、対向する画像境界１６にマッピング又は変換され得る。マッピングされた動きベクトル１９´は、リファレンスブロック１１２の位置を示す。例えば、マッピングされた動きベクトル１９´は、動きベクトル１３２がピクチャ境界１５に当たるか、又は交差する位置と同じ座標をピクチャ境界１５の方向に有する対向ピクチャ境界１６の位置で継続されてもよい。リファレンスブロック及び／又は動きベクトルのラップアラウンドは、ラップアラウンド動き補償ツールと呼ばれる。
【0037】
さらなる例では、第１の方向は水平方向であり得る。さらなる例では、ピクチャ１２は、水平方向と垂直方向との両方において３６０度ビューを表す。後者の場合、ラップアラウンド動き補償は、一方向又は双方向に適用されてもよく、すなわち、リファレンスブロック及び／又は動きベクトルが垂直ピクチャ境界及び／又は水平ピクチャ境界を超える場合、ラップアラウンド動き補償が適用され得る。ＶＶＣの例では、ラップアラウンド動き補償が垂直ピクチャ境界に適用され得る。
【0038】
３６０度のピクチャの例では、ピクチャ１２によって表されるビュー、すなわちピクチャコンテンツは、３６０度を超えることがあり、アーチファクトを回避するために有益であり得ることに留意されたい。これらの場合、ラップアラウンド動き補償の上記の説明は等しく適用されてもよく、ピクチャ境界１５は、ピクチャコンテンツ境界を表し、すなわち、ピクチャコンテンツ境界として理解されるべきであり、対向するピクチャ境界１６は、対向ピクチャコンテンツ境界を表し、すなわち、対向ピクチャコンテンツ境界として理解されるべきである。ビューが３６０度を超える場合、ピクチャコンテンツ境界及び／又は対向ピクチャコンテンツ境界は、サンプルアレイが終了する境界に関してピクチャの境界と一致しない。しかしながら、ピクチャ１２が正確に３６０度ビューを表す例では、図５に示すように、ピクチャコンテンツ境界及び対向ピクチャコンテンツ境界は、サンプルアレイが終了する境界に関してピクチャの境界と一致し得る。言い換えれば、ピクチャコンテンツ境界１５と対向ピクチャコンテンツ境界１６との間のピクチャ１２のコンテンツは、３６０度ビューを表し得る。ピクチャコンテンツ境界と対向ピクチャコンテンツ境界とは、必ずしもピクチャのサンプルアレイの境界と一致しない。
【0039】
図６は、本明細書の導入部分に記載したように、３６０度ビューとラップアラウンド動き補償を表すピクチャ１２の例を示し、当該部分はまた、例示的な実施例において実装され得るように、ラップアラウンド動き補償の例としても理解されるべきである。
【0040】
そのようなラップアラウンド動き補償が問題となり得るいくつかのユースケースがある。例えば、そのような３６０ビデオコンテンツを消費するとき、重要なコンテンツの大部分が「赤道」領域の周りに位置する可能性が高いため、ユーザは球の極、すなわち、上部及び底面を頻繁に見ないことが典型的なケースである。いくつかのリソースを節約する（チャネルを介してより少ないデータを送信する、又は、エンドデバイス上でより少ないデータを処理する）非常に有益な方法は、視聴者ビューポートに適応する（潜在的には予測を利用して）こと、及び、送信又は処理されるデータの量を適応させることである。ユーザが極（例えば、これらの領域は興味深い特徴を示す）を見る可能性が高い時刻では、ＥＲＰ全体が送信され、一方、ユーザが極を見ないことが明らかな他の時刻では、極を除外するＥＲＰのサブセットのみが送信される。
【0041】
そのようなケースに遭遇する問題は、ＰＰＳで示されるとき、及び現在のピクチャとリファレンスピクチャの“フォーマット”が同じである、すなわち、同じピクチャサイズ、同じスケーリングウィンドウであるときに、ラップアラウンドツールがアクティブ化されることである。これは、そのようなピクチャフォーマットの変更が、送信されるＥＲＰピクチャの部分を適応させた結果として起こるときはいつでも、ラップアラウンドは、それに応じてアクティブ化又は非アクティブ化される必要があることを意味する。エンコーダがストリーミングループ内にあるとき、すなわち、エンコーダがビューワからフィードバックを取得し、ユーザに現在送信されているものを認識しているとき、これは、エンコーダ側で単に適用することができ、このオン／オフツール制御は、符号化ステージで必要なときに行うことができる。
【0042】
しかしながら、エンコーダがストリーミングループにあることなく、同じアプローチを実行することができる。そのような場合、例えば、エンコーダは、３つのサブピクチャを使用してＥＲＰを符号化することを想定することができ、１つは、図７に示される領域の各々についてのものであり、すなわち、その例では、２つの極についての２つのサブピクチャと、ＥＲＰピクチャの赤道についての１つのサブピクチャとである。そのような場合、エンコーダは、３６０ＥＲＰ全体がいつ送信されるか、及び、赤道部分のみがいつ送信されるかを認識しない。中間デバイスが適応化をいつ実行されることができるかを知るため、ラップアラウンドツールがいつ使用されるか、及び、どこでは使用しないかを知ることが不可欠であり、その結果、ラップアラウンドを利用しないピクチャは、ＥＲＰ全体を赤道のみに送信することから、又はその反対に切り替えるために使用されることができる。したがって、１つの実施例では、ピクチャが、１つのピクチャフォーマット（すなわち、特定のスケーリングウィンドウが定義されたピクチャサイズ）から別のピクチャフォーマットへの変更を可能にする潜在的なスイッチングポイントであることを示す信号がビットストリーム内に提供され、なぜなら、それはラップアラウンドを使用せず、符号化順序で後続するピクチャが、スイッチングポイントに先行するリファレンスピクチャを使用してラップアラウンド動き補償予測を使用しないためである。ストリーミングシナリオでは、そのようなピクチャはそれの関連付けられたＲＡＳＬピクチャとともにＣＲＡピクチャであってもよく、すなわち、ＣＲＡピクチャは、当然に動き補償予測を利用せず、全て又はいくつかのＲＡＳＬピクチャは、適合するスイッチングを可能にするために、ラップアラウンド動き補償を使用しないように制約される。
【0043】
さらにより洗練されたシナリオでは、このような３６０度ビデオコンテンツをストリーミングする際のビューポート適応化は、コンテンツのモザイクから、それの現在（又は予測される以降）のビューポートに従ってダウンロードされるコンテンツの部分を選択するクライアントに個々の高品質／高分解能タイルを提供することによって実行される。そのようなケースでは、フル３６０度フォールバックタイルは、典型的には、提供することに含まれ、その結果、ユーザはビューイング方向の突然で予期されない、又は予測されない変化を実行し、クライアントは適切な高品質コンテンツを時間内にダウンロードすることができない場合、クライアントは高品質タイルのクライアント選択内にないコンテンツの少なくとも低品質バージョンを示すことができる。そのようなシナリオでは、クライアントは、典型的には、全てのダウンロードされたタイルの個々のビットストリームを単一の圧縮されたビットストリームに合成して、デコーダに供給する。図８において、このような合成されたビットストリームと可変タイル選択（１つの低品質フォールバックタイルを維持しながら、２つから３つの高品質タイルに切り替える）の例を示す。
【0044】
図８は、時間的に変化する数の高品質タイルと１つの低品質フォールバックタイルをボトムに有するタイルベースのビューポート適応的ストリーミングの例を示す。図８の時刻ｔ＋１に示すように、このような設定におけるクライアント側でダウンロードされる高品質タイルの個数は経時的に変化する可能性がある理由は様々である。例えば、クライアントビューポートは、視線方向及び投影特性に応じた可変数のタイルに対応する。さらに、クライアント側のビューポート予測は、３６０度ビデオのダウンロードされた高品質部分に関して、より多くのオーバープロビジョニングを必要とする時間の経過に伴って精度が変化し得る。さらに、コンテンツ特性の知識は、クライアントが特定の時間に潜在的に興味のあるコンテンツ領域を特定し、対応する高品質タイルをダウンロードすることを可能にし得る。これら全ての理由から、ダウンロードされた高品質タイルの量の変更が行われ、したがって、画像解像度が変化することがある。このようなシナリオでは、より高い符号化効率のために、ラップアラウンド動き補償を用いてフル３６０度フォールバックタイルを符号化することが有益であるが、準拠するビットストリームを維持しながら、ダウンロードされた高品質タイルの個数を経時的に変更するため、合成されたビットストリームの特定のピクチャ（図８のスイッチングポイント）でラップアラウンド動き補償を完全に無効にする必要がある。
【0045】
ラップアラウンドを効率的に使用するために何らかの追加情報を必要とする別のケースは、図４を参照して説明されるように、一般的なビデオコンテンツのＨＴＴＰストリーミングにおける解像度スイッチングである。ＨＴＴＰストリーミングでは、同じビデオコンテンツが様々なビットレート及び解像度で符号化、セグメント化及び提供され、多様な能力を有するクライアントに役立つか、又は、ダウンロードされたビットストリームを観察されたスループットにクライアント側での適応化、フルスクリーン対ウィンドウ表示などのクライアント側でのコンテンツ提示の変更、ユーザからディスプレイまでの距離の変更、周辺光環境の変化を可能にすることが一般的である。クライアントは、ストリーミングセッション中にセグメントの変形の間で連続的にスイッチングし、デコーダに供給される連結されたビットストリームを生成することができる。オープンＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅ）符号化構造が使用されるとき、すなわち、ランダムアクセスポイント（ＲＡＰ）ピクチャが、予測のためのリファレンスピクチャとしてＲＡＰピクチャに先行するピクチャを使用するリーディングピクチャ（例えば、ＶＶＣにおけるＲＡＳＬピクチャ）を有するとき、符号化効率は概して増加するが、セグメント変形の間のスイッチングは、リーディングピクチャがセグメントを符号化するときに元々使用された以前のセグメントのリファレンスピクチャの異なる変形を使用し得るという事実をもたらす。リファレンスピクチャを含むこのセグメント変形は、例えば、リーディングピクチャを含むセグメントと異なる解像度を有してもよく、この場合、連結されたクライアント側のビットストリームは、デコーダが一致する解像度を有するリファレンスピクチャを生成するため、リファレンスピクチャリサンプリング（ＲＰＲ）に関連する技術の利用を示すべきである。図４は、ストリーミングセッションにおける２つの連続するセグメントから形成されるビットストリームにおけるピクチャ及び予測依存性を示すことによってそのような状況の例を示し、ここで、第１のセグメントは、以前のセグメントを参照することのないクローズドＧＯＰ構造であり、第２のセグメントは、以前のセグメントを参照するＲＡＳＬピクチャを含む。
【0046】
このようなビットストリームスイッチング動作（例えば、解像度を適応させる）を可能にするようにビットストリームを符号化するとき、エンコーダが特定の制約に従うことをビットストリームにおいて示すことが重要であるため、適切な制約信号は、ＪＶＥＴ－Ｖ００６０及びＪＶＥＴ－Ｗ０１３３において最初に提案され、いわゆる、制約付きＲＡＳＬ符号化指示ＳＥＩメッセージとしてＶＶＣバージョン２ドラフトに統合された。
【0047】
しかしながら、残りの問題は、この信号処理の最新の設計によると、関連する制約は、例えば、ラップアラウンド動き補償を使用しない場合と比較して、ＲＡＳＬピクチャをより効率的に符号化する目的のため、ビットストリームにおけるリーディングピクチャのためのラップアラウンド動き補償の使用を排除しないことである。しかしながら、クライアントが、セグメント境界（例えば、そのような不適切に制約されたリーディングピクチャを有するＲＡＰピクチャからスタートする）においてストリーミングセッションにおいて解像度スイッチングを実行しようとするとき、不正な準拠しないビットストリームは、ラップアラウンド動き補償として生成され、ＲＰＲはＶＶＣにおける同じ符号化ピクチャにおいて利用することができない。
【0048】
図９は、一実施例によるビデオデコーダ２０を示す。例えば、デコーダ２０は、図２のデコーダＡ２０として実装され得る。デコーダ２０は、データストリーム１４からビデオのピクチャを復号化する。図９によるデコーダ２０は、データストリーム１４から指示９３０を復号化するように構成される。指示９３０は、ピクチャのシーケンス、例えば図４に関して説明したようなＣＶＳに対して有効である。データストリームに存在する場合、指示９３０は、当該指示が参照するピクチャのシーケンスのＲＡＳＬピクチャ９１２´又は全てのＲＡＳＬピクチャ９１２´が、１つ以上の符号化ツールの所定のセット９４０を除外する方法で符号化されることを示す。所定のセット９４０は、例えば、上述のようなラップアラウンド動き補償ツールを含む。
【0049】
上述したように、ＲＡＳＬピクチャ（図４の符号化順序１０のピクチャなど）は、ＲＡＳＬピクチャが関連付けられたＣＲＡピクチャ（図４の符号化順序９のＣＲＡピクチャ）に符号化順序で先行するピクチャ（例えば、図４の符号化順序１）への時間的インター予測リファレンスを含み得る。関連するＣＲＡピクチャに先行するピクチャは、以前のセグメントに属してもよく、したがって、図４～図８のシナリオに関して説明されるように、ピクチャ形式、例えば、ピクチャサイズ、スケーリングウィンドウ、解像度の１つ以上を有し得る。本発明者らは、ビットストリームにおけるラップアラウンド動き補償とリファレンスピクチャリスケーリングとの組合せは、より高い符号化効率を可能にするが、特定の条件下で特定のピクチャにおいて、例えば、ＨＴＴＰストリーミングにおいてストリームスイッチングが行われるとき、又は、ミドルボックスがビットストリームの部分をドロップすることを決定するとき、不正なビットストリームをもたらす可能性があることを認識した。したがって、異なる表現の間のスイッチングを可能にするため、又は、例えば、３６０度のビデオの異なる部分の可変的な品質の上述のシナリオにおいて準拠したビットストリームを保証するため、ラップアラウンド動き補償ツールを非アクティブ化することが有益である。
【0050】
例えば、デコーダ２０は、図５に関して説明したような動き補償された時間インター予測をサポートし、動き補償された時間インター予測を適用する際に、例えば、データストリーム１４が図５～図８に関して説明したような３６０度ビデオを表す場合、ラップアラウンド動き補償ツールを使用することができる。
【0051】
一実施例によると、指示９４０は、データストリーム１４における補完拡張情報（ＳＥＩ）メッセージの一部であるか、又は、データストリームにおける特定のＳＥＩメッセージの存在によって表される。例えば、指示９４０は、ピクチャのシーケンスのための制約付きＲＡＳＬ符号化指示（ＣＲＥＩ）ＳＥＩメッセージの存在によって表される。すなわち、デコーダは、ＣＲＥＩ ＳＥＩメッセージがピクチャのシーケンスのためのデータストリーム１４に存在する場合、特定のＲＡＳＬピクチャ又は全てのＲＡＳＬピクチャのための所定のセット９４０の符号化ツールを非アクティブ化し得る。
【0052】
したがって、第１の実施例では、指示９３０は、当該指示が参照するピクチャのシーケンスの全てのＲＡＳＬピクチャが１つ以上の符号化ツールの所定のセット９４０を排除する方法で符号化されることを示す。
【0053】
換言すると、１つの態様は、ＲＡＳＬピクチャがラップアラウンド動き補償を利用しないことをビットストリームにおいて指示することである。例えば、当該指示は、制約付きのＲＡＳＬ符号化指示ＳＥＩメッセージの最新バージョンにありうる。換言すると、ＶＶＣに実現される実施例によると、ＣＲＥＩ ＳＥＩメッセージは指示９４０として利用される。
【0054】
テーブル１は、制約付きＲＡＳＬ符号化指示ＳＥＩメッセージに基づく実施例を示し、最後のアイテムはそのような制約を表す。
【表1】
【0055】
ＣＲＥＩ ＳＥＩメッセージの存在は、以下の条件の全てがＣＶＳにおける各ＲＡＳＬピクチャに適用されることを示す。
ＰＨシンタックス構造は、１に等しいｐｈ＿ｄｍｖｒ＿ｄｉｓａｂｌｅｄ＿ｆｌａｇを有する。
０（Ｂ）又は１（Ｐ）に等しいｓｈ＿ｓｌｉｃｅ＿ｔｙｐｅにおけるＣＵの何れも１に等しいｃｃｌｍ＿ｍｏｄｅ＿ｆｌａｇを有さない。
コロケートされたリファレンスピクチャの何れも復号化順序においてＲＡＳＬピクチャに関連するＣＲＡピクチャに先行しない。
ＲＡＳＬピクチャによって参照されるピクチャパラメータセット（ＰＰＳ）の何れも１に等しいｐｐｓ＿ｒｅｆ＿ｗｒａｐａｒｏｕｎｄ＿ｅｎａｂｌｅｄ＿ｆｌａｇを有さない（すなわち、ラップアラウンド動き補償は、ＲＡＳＬピクチャに対して有効とされない）。
ＰＨシンタックス構造は、１に等しいｐｈ＿ｄｍｖｒ＿ｄｉｓａｂｌｅｄ＿ｆｌａｇを有する。
０（Ｂ）又は１（Ｐ）に等しいｓｈ＿ｓｌｉｃｅ＿ｔｙｐｅにおけるＣＵの何れも１に等しいｃｃｌｍ＿ｍｏｄｅ＿ｆｌａｇを有さない。
コロケートされたリファレンスピクチャの何れも復号化順序においてＲＡＳＬピクチャに関連するＣＲＡピクチャに先行しない。
ＲＡＳＬピクチャによって参照されるピクチャパラメータセット（ＰＰＳ）の何れも１に等しいｐｐｓ＿ｒｅｆ＿ｗｒａｐａｒｏｕｎｄ＿ｅｎａｂｌｅｄ＿ｆｌａｇを有さない（すなわち、ラップアラウンド動き補償は、ＲＡＳＬピクチャに対して有効とされない）。
【0056】
第２の実施例によると、指示９３０は、当該指示が参照するピクチャのシーケンスの特定のＲＡＳＬピクチャが１つ以上の符号化ツールの所定のセット９４０を排除する方法で符号化されることを示す。一実施例では、特定のＲＡＳＬピクチャは、直接的なリファレンスピクチャとして、符号化順序で各ピクチャに先行するＣＲＡピクチャを有する全てのＲＡＳＬピクチャを含む。
【0057】
換言すると、上記の制約は、実際に必要とされるより制約的であってもよい。復号化順序においてＣＲＡに先行する何れのピクチャにも依存しないＲＡＳＬピクチャがあってもよく、したがって、そのようなＲＡＳＬピクチャは、異なるフォーマットによる何れかのピクチャをリファレンスとして利用しない（例えば、符号化順序１５によるピクチャを参照されたい）。したがって、他の第２の実施例では、上述した制約はＣＲＡに先行するアクティブリファレンスを有するＲＡＳＬピクチャに適用される。
【0058】
図１０は、データストリーム１４にビデオを符号化するエンコーダ１０１０を示す。例えば、エンコーダ１０１０は、図１のエンコーダＡ１０として実現されうる。エンコーダ１０１０は、図９に関して説明したような指示９３０をデータストリーム１４に符号化する。
【0059】
換言すると、エンコーダ１０１０は、指示９３０をデコーダ２０に提供する。したがって、指示９３０は、ＲＡＳＬピクチャ９１２が所定のセット９４０の符号化ツールなしに符号化されるデコーダ２０の前提を表す。
【0060】
実際、上記の第２の実施例は、必要よりもさらに限定的であり、符号化効率に対して負の影響を有しうる。例えば、符号化順序１０による図４におけるピクチャに留意されたい。そのようなピクチャは、２つの不リファレンスピクチャを有し、１つはＣＲＡであり、他方は符号化順序でＣＲＡに先行するピクチャである。実際、動き補償がリファレンスとしてＣＲＡにより適用されるとき、ピクチャフォーマットは同じであるため、ラップアラウンドが利用可能である。そして、動き補償が符号化順序でＣＲＡに先行するピクチャに適用されるとき、ラップアラウンドは回避されるべきである。ＶＶＣ仕様において利用可能なオン／オフ機構は、リファレンスピクチャごとの信号処理でなく、信号処理を搬送するＰＰＳに関連する特定のピクチャの全てのリファレンスピクチャに適用されるため、各リファレンスピクチャに対してラップアラウンド動き補償をアクティブ化することはできない。したがって、他の第２の実施例では、さらなる代替として、一部のピクチャ（例えば、ＨＴＴＰにおける解像度スイッチング又は上記のサブピクチャによる具体例におけるいわゆるスイッチングポイントのためのＲＡＳＬなど）のＰＰＳにおける制御フラグを０に設定することによるラップアラウンド動き補償をオフにすることを必要とする代わりに、エンコーダは、ＣＵ毎にＭＶを制限し、ラップアラウンドがアクティブ化されるときでさえ、現在のピクチャとリファレンスピクチャとが異なるピクチャフォーマットを有するとき、ラップアラウンドをトリガーするピクチャ領域の外部には何れのＭＶも指し示さない。
【0061】
したがって、一実施例によると、エンコーダ１０１０は、データストリーム１４に指示９３０を必ずしも含まず、ＲＡＳＬピクチャ９１２に動き補償インター予測を適用する際、ピクチャ境界を超過するリファレンスブロックを生じさせないものに動きベクトルの選択を制限する。
【0062】
実施例によると、デコーダ２０とエンコーダ１０１０とは、例えば、導入部において説明したように、リファレンスピクチャリサンプリング（ＲＳＲ）をサポートする。
【0063】
ＲＳＲは、リファレンスピクチャとインター予測ブロックが含まれるピクチャとの間のスケーリングウィンドウサイズ乖離又はサンプル解像度乖離を埋めて、インター予測ブロックのインター予測信号を提供するため、インター予測ブロックのリファレンスピクチャのサンプルのリサンプリングを含んでもよい。すなわち、ＲＳＲによると、現在符号化されるピクチャ１２１又はそのブロック１０と、インター予測に利用されるリファレンスピクチャ１２２又はそのリファレンスブロック１１とのスケーリングウィンドウ及び／又は解像度が、例えば、リファレンスピクチャ又はリファレンスブロックをリサンプリングすることによって、互いに適応化されてもよい。
【0064】
実施例によると、所定のセット９４０はさらに、テーブル１の上記の実施例など、クロスコンポーネントリニアモデル（ＣＣＬＭ）ベース予測及び／又はデコーダ側動きベクトル精緻化ツールを含み、それによると、所定のセット９４０は、これらのツールの双方を含む、ＣＣＬＭツールの実現例が以下に説明される。
【0065】
クロスコンポーネントリニアモデル（ＣＣＬＭ）は、リニアモデルを利用して各ルマコンポーネントからブロックのクロマコンポーネントをイントラ予測することを可能にし、モデルパラメータは、再構成されたルマサンプル値から導出される。リニアモデルは、以下によってサブサンプリングされたルマサンプルｒｅｃ´Ｌをクロマ予測に変換する。
Ｐ（ｉ，ｊ）＝ａ・ｒｅｃ´Ｌ（ｉ，ｊ）＋ｂ
ここで、パラメータａ及びｂは、以下のような近傍のルマ及びクロマサンプルから導出される。２つの最大の近傍サンプルの平均と２つの最小の近傍サンプルの平均とを示すＸｌ及びＸｓと、対応するクロマサンプルペアの平均を示すＹｌ及びＹｓとによると、パラメータは、以下のように導出される。
ａ＝（Ｙｌ－Ｙｓ）／（Ｘｌ－Ｘｓ）
ｂ＝Ｙｓ－ａ・Ｘｓ
Ｐ（ｉ，ｊ）＝ａ・ｒｅｃ´Ｌ（ｉ，ｊ）＋ｂ
ここで、パラメータａ及びｂは、以下のような近傍のルマ及びクロマサンプルから導出される。２つの最大の近傍サンプルの平均と２つの最小の近傍サンプルの平均とを示すＸｌ及びＸｓと、対応するクロマサンプルペアの平均を示すＹｌ及びＹｓとによると、パラメータは、以下のように導出される。
ａ＝（Ｙｌ－Ｙｓ）／（Ｘｌ－Ｘｓ）
ｂ＝Ｙｓ－ａ・Ｘｓ
【0066】
パラメータ乖離処理は近傍のサンプル値の極値を説明するだけであるため、当該処理は、近傍ブロックにおいて単一サンプルドリフト外れ値のケースでさえ網羅的なドリフトである傾向がある。また、リニアモデルのため、ａが大きい場合、ルマドリフトは増幅されうる。近傍のサンプル値の全てを説明するリニアモデルのため、ドリフト伝搬はあまり明確でなく、線形には増幅し得ない。この本来的な不安定さのため、このモデルは、ＨＴＴＰ適応的ストリーミングにおけるオープンＧＯＰスイッチングとして、制約されたドリフトが許容されるアプリケーションに適用される際、特別なケアを必要とする。この先頭において、上述したアプリケーションに関して、ドリフトはＲＡＳＬフレーム、すなわち、動き予測されたフレームにおいてのみ行われうる。エンコーダがＣＣＬＭ、すなわち、イントラ予測モードを利用することを決定した場合、これは、通常は適切な動き補償予測子の欠落に由来し、高い時間アクティビティの領域を意味する。そのような領域では、オープンスイッチングのための予想される再構成ドリフトは、高いことが予想され、説明される不安定性の効果にさらに大きく貢献する。
【0067】
いくつかの態様が装置に関して説明されたが、これらの態様はまた、ブロック又はデバイスが方法ステップ又は方法ステップの特徴に対応する対応する方法の説明を表す。効果的には、方法ステップに関して説明される態様はまた、対応する装置の対応するブロック、アイテム又は特徴の説明を表す。
【0068】
方法ステップの一部又は全ては、例えば、マイクロプロセッサ、プログラマブルコンピュータ又は電子回路などのハードウェア装置によって実行（又は利用）されてもよい。いくつかの実施例では、最も重要な方法ステップの１つ以上は、そのような装置によって実行されてもよい。
【0069】
本発明のデータストリームは、デジタル記憶媒体に格納可能であるか、又はインターネットなどの有線送信媒体又は無線送信媒体などの送信媒体上で送信可能である。すなわち、さらなる実施例は、例えば、ビデオビットストリームを格納したデジタル記憶媒体など、ここに説明される実施例によるビデオビットストリームを含むビデオビットストリーム製品を提供する。
【0070】
特定の実現要求に依存して、実施例はハードウェア又はソフトウェアにより実現可能である。実現形態は、各方法が実行されるプログラマブルコンピュータシステムと協調する（又は協調可能である）電子的に可読な制御信号を格納したデジタル記憶媒体、例えば、フロッピーディスク、ＤＶＤ、Ｂｌｕ－Ｒａｙ、ＣＤ、ＲＯＭ、ＰＲＯＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ又はＦＬＡＳＨメモリなどを利用して実行可能である。したがって、デジタル記憶媒体は、コンピュータ可読であってもよい。
【0071】
いくつかの実施例は、ここに説明された方法の１つが実行されるように、プログラマブルコンピュータシステムと協調可能な電子的に可読な制御信号を有するデータキャリアを含む。
【0072】
一般に、実施例は、プログラムコードを備えたコンピュータプログラム製品として実現可能であり、当該プログラムコードは、コンピュータプログラム製品がコンピュータ上で実行されるとき、方法の１つを実行するため作用する。プログラムコードは、例えば、機械可読キャリア上に格納されてもよい。
【0073】
他の実施例は、機械可読キャリアに格納され、ここに説明される方法の１つを実行するためのコンピュータプログラムを含む。
【0074】
すなわち、本発明の方法の実施例は、したがって、コンピュータプログラムがコンピュータ上に実行されるとき、ここに説明される方法の１つを実行するためのプログラムコードを有するコンピュータプログラムである。
【0075】
本発明の方法のさらなる実施例は、したがって、ここに説明される方法の１つを実行するためのコンピュータプログラムを記録したデータキャリア（又はデジタル記憶媒体若しくはコンピュータ可読媒体）である。データキャリア、デジタル記憶媒体又は記録媒体は、典型的には、有形であり、及び／又は非一時的である。
【0076】
本発明の方法のさらなる実施例は、したがって、ここに説明される方法の１つを実行するためのコンピュータプログラムを表すデータストリーム又は信号シーケンスである。データストリーム又は信号シーケンスは、例えば、インターネットなどを介しデータ通信説明を介し伝送されるよう構成されてもよい。
【0077】
さらなる実施例は、例えば、ここに説明される方法の１つを実行するよう構成又は適応されるコンピュータ又はプログラマブル論理デバイスなどのプロセッサを含む。
【0078】
さらなる実施例は、ここに説明される方法の１つを実行するためのコンピュータプログラムをインストールしたコンピュータを含む。
【0079】
さらなる実施例は、ここに説明される方法の１つを実行するためのコンピュータプログラムを受信機に（例えば、電子的又は光学的に）伝送するよう構成される装置又はシステムを含む。受信機は、例えば、コンピュータ、モバイルデバイス、メモリデバイスなどであってもよい。装置又はシステムは、例えば、コンピュータプログラムを受信機に伝送するためのファイルサーバを含んでもよい。
【0080】
いくつかの実施例では、プログラマブル論理デバイス（例えば、フィールドプログラマブルゲートアレイ）が、ここに説明される方法の機能の一部又は全てを実行するのに利用されてもよい。いくつかの実施例では、フィールドプログラマブルゲートアレイはここに説明される方法の１つを実行するためマイクロプロセッサと連携してもよい。一般に、方法は、好ましくは何れかのハードウェア装置によって実行される。
【0081】
ここに説明される装置は、ハードウェア装置を利用して、コンピュータを利用して、又は、ハードウェア装置とコンピュータとの組み合わせを利用して実現されてもよい。
【0082】
ここに説明される装置又はここに説明される装置の何れかのコンポーネントは、少なくとも部分的にハードウェア及び／又はソフトウェアにより実現されてもよい。
【0083】
ここに説明される方法は、ハードウェア装置を利用して、コンピュータを利用して、又は、ハードウェア装置とコンピュータとの組み合わせを利用して実現されてもよい。
【0084】
ここに説明される方法又はここに説明される装置の何れかのコンポーネントは、少なくとも部分的にハードウェア及び／又はソフトウェアにより実現されてもよい。
【0085】
上述した実施例は単なる例示である。ここに説明される構成及び詳細の変更及び変形は当業者に明らかであることが理解される。したがって、それは、係属中の特許請求項の範囲のみによって限定され、ここでの実施例の記載及び説明によって提供される具体的な詳細によって限定されるものでない。
【0086】
参照によってここに含まれる文書
[1] ISO/IEC JTC 1, Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats, ISO/IEC 23009-1, 2012 (and subsequent editions).
[2] J. De Cock, Z. Li, M. Manohara, A. Aaron. "Complexity-based consistent-quality encoding in the cloud." 2016 IEEE International Conference on Image Processing (ICIP). IEEE, 2016
[3] DASH Industry Forum Implementation Guidelines. [Online]. Available: https://dashif.org/guidelines/
[4] ITU-T and ISO/IEC JTC 1, Advanced Video Coding for generic audio-visual services, Rec. ITU-T H.264 and ISO/IEC 14496-10 (AVC), May 2003 (and subsequent editions).
[5] ITU-T and ISO/IEC JTC 1, “High Efficiency Video Coding,” Rec. ITU-T H.265 and ISO/IEC 23008-2 (HEVC), April 2013 (and subsequent editions).
[6] Y. Yan, M. Hannuksela, and H. Li. "Seamless switching of H. 265/HEVC-coded dash representations with open GOP prediction structure." 2015 IEEE International Conference on Image Processing (ICIP). IEEE, 2015.
[7] ITU-T and ISO/IEC JTC 1, “Versatile video coding”, Rec. ITU-T H.266 and ISO/IEC 23090-3 (VVC), August 2020.
[8] V. Baroncini and M. Wien, “VVC verification test report for UHD SDR video content”, doc. JVET-T2020 of ITU-T/ISO/IEC Joint Video Experts Team (JVET), 21th meeting: October 2020.
[9] D. Luo, V. Seregin, W. Wan. “Description of Core Experiment 1 (CE1): Reference picture resampling filters“, doc. JVET-Q2021 of ITU-T/ISO/IEC Joint Video Experts Team (JVET), 15th meeting: July 2019
[10] H. Schwarz, D. Marpe, and T. Wiegand, “Analysis of hierarchical B pictures and MCTF”, ICME 2006, IEEE International Conference on Multimedia and Expo, Toronto, Ontario, Canada, July 2006.
[11] Y.-K. Wang et al., “The High-Level Syntax of the Versatile Video Coding (VVC) Standard” IEEE Trans. Circuits Syst. Video Technol., in press
[12] H. Yang et al., “Subblock based Motion Derivation and Inter-Prediction Refinement in Versatile Video Coding Standard”, IEEE Trans. Circuits Syst. Video Technol., in press
[13] W.-J. Chien et al., “Motion Vector Coding and Block Merging in Versatile Video Coding Standard”, IEEE Trans. Circuits Syst. Video Technol., in press
[1] ISO/IEC JTC 1, Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats, ISO/IEC 23009-1, 2012 (and subsequent editions).
[2] J. De Cock, Z. Li, M. Manohara, A. Aaron. "Complexity-based consistent-quality encoding in the cloud." 2016 IEEE International Conference on Image Processing (ICIP). IEEE, 2016
[3] DASH Industry Forum Implementation Guidelines. [Online]. Available: https://dashif.org/guidelines/
[4] ITU-T and ISO/IEC JTC 1, Advanced Video Coding for generic audio-visual services, Rec. ITU-T H.264 and ISO/IEC 14496-10 (AVC), May 2003 (and subsequent editions).
[5] ITU-T and ISO/IEC JTC 1, “High Efficiency Video Coding,” Rec. ITU-T H.265 and ISO/IEC 23008-2 (HEVC), April 2013 (and subsequent editions).
[6] Y. Yan, M. Hannuksela, and H. Li. "Seamless switching of H. 265/HEVC-coded dash representations with open GOP prediction structure." 2015 IEEE International Conference on Image Processing (ICIP). IEEE, 2015.
[7] ITU-T and ISO/IEC JTC 1, “Versatile video coding”, Rec. ITU-T H.266 and ISO/IEC 23090-3 (VVC), August 2020.
[8] V. Baroncini and M. Wien, “VVC verification test report for UHD SDR video content”, doc. JVET-T2020 of ITU-T/ISO/IEC Joint Video Experts Team (JVET), 21th meeting: October 2020.
[9] D. Luo, V. Seregin, W. Wan. “Description of Core Experiment 1 (CE1): Reference picture resampling filters“, doc. JVET-Q2021 of ITU-T/ISO/IEC Joint Video Experts Team (JVET), 15th meeting: July 2019
[10] H. Schwarz, D. Marpe, and T. Wiegand, “Analysis of hierarchical B pictures and MCTF”, ICME 2006, IEEE International Conference on Multimedia and Expo, Toronto, Ontario, Canada, July 2006.
[11] Y.-K. Wang et al., “The High-Level Syntax of the Versatile Video Coding (VVC) Standard” IEEE Trans. Circuits Syst. Video Technol., in press
[12] H. Yang et al., “Subblock based Motion Derivation and Inter-Prediction Refinement in Versatile Video Coding Standard”, IEEE Trans. Circuits Syst. Video Technol., in press
[13] W.-J. Chien et al., “Motion Vector Coding and Block Merging in Versatile Video Coding Standard”, IEEE Trans. Circuits Syst. Video Technol., in press
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【手続補正書】
【提出日】2024-03-19
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
少なくとも１つのプロセッサを有し、前記少なくとも１つのプロセッサは、
データストリームからＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）メッセージを復号化するよう構成され、
前記ＳＥＩメッセージは、ピクチャのシーケンス内の全てのＲＡＳＬ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｓｋｉｐｐｅｄ Ｌｅａｄｉｎｇ）ピクチャの符号化が１つ以上の符号化ツールの所定のセットを除く方法で制限されることを通知し、前記所定のセットはラップアラウンド動き補償ツールを含み、前記ピクチャのシーケンスは、少なくとも１つのＲＡＳＬピクチャと前記少なくとも１つのＲＡＳＬピクチャに関連するＣＲＡ（Ｃｌｅａｎ Ｒａｎｄｏｍ Ａｃｃｅｓｓ）ピクチャとを含む、ビデオデコーダ。
【請求項2】
前記ラップアラウンド動き補償ツールは、水平方向ラップアラウンド動き補償ツールである、請求項１に記載のビデオデコーダ。
【請求項3】
前記ラップアラウンド動き補償ツールによると、動き補償された時間インター予測のため動きベクトルによって示されたリファレンスブロックの一部がリファレンスピクチャのピクチャコンテンツ境界を超過する場合、前記ピクチャコンテンツ境界を超過した前記リファレンスブロックの一部が反対のピクチャコンテンツ境界に配置される前記リファレンスピクチャの一部にマッピングされ、及び／又は、前記ピクチャコンテンツ境界を超過した前記動きベクトルの一部が前記反対のピクチャコンテンツ境界に続く、請求項１に記載のビデオデコーダ。
【請求項4】
前記少なくとも１つのプロセッサは、リファレンスピクチャリサンプリングをサポートするよう構成される、請求項１に記載のビデオデコーダ。
【請求項5】
前記リファレンスピクチャリサンプリングによると、インター予測されるブロックのリファレンスピクチャは、前記リファレンスピクチャと、前記インター予測されるブロックが前記インター予測されるブロックのインター予測信号を提供するよう含まれるピクチャとの間のスケーリングウィンドウサイズ乖離又はサンプル解像度乖離を埋めるためサンプルリサンプリングを受ける、請求項４に記載のビデオデコーダ。
【請求項6】
前記ピクチャのシーケンスは、符号化順に連続するピクチャを含み、前記ピクチャのシーケンスは、符号化順にＣＲＡピクチャからスタートする、請求項１に記載のビデオデコーダ。
【請求項7】
前記１つ以上の符号化ツールの所定のセットはさらに、クロスコンポーネントリニアモデルに基づく予測ツールとデコーダサイド動きベクトルリファイメントツールとを含む、請求項１に記載のビデオデコーダ。
【請求項8】
少なくとも１つのプロセッサを有し、前記少なくとも１つのプロセッサは、
データストリームにＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）メッセージを符号化するよう構成され、前記ＳＥＩメッセージは、ピクチャのシーケンス内の全てのＲＡＳＬ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｓｋｉｐｐｅｄ Ｌｅａｄｉｎｇ）ピクチャの符号化が１つ以上の符号化ツールの所定のセットを除く方法で制限されることを通知し、前記所定のセットはラップアラウンド動き補償ツールを含み、前記ピクチャのシーケンスは、少なくとも１つのＲＡＳＬピクチャと前記少なくとも１つのＲＡＳＬピクチャに関連するＣＲＡ（Ｃｌｅａｎ Ｒａｎｄｏｍ Ａｃｃｅｓｓ）ピクチャとを含む、ビデオエンコーダ。
【請求項9】
前記ラップアラウンド動き補償ツールは、水平方向ラップアラウンド動き補償ツールである、請求項８に記載のビデオエンコーダ。
【請求項10】
前記ラップアラウンド動き補償ツールによると、動き補償された時間インター予測のため動きベクトルによって示されたリファレンスブロックの一部がリファレンスピクチャのピクチャコンテンツ境界を超過する場合、前記ピクチャコンテンツ境界を超過した前記リファレンスブロックの一部が反対のピクチャコンテンツ境界に配置される前記リファレンスピクチャの一部にマッピングされ、及び／又は、前記ピクチャコンテンツ境界を超過した前記動きベクトルの一部が前記反対のピクチャコンテンツ境界に続く、請求項８に記載のビデオエンコーダ。
【請求項11】
前記少なくとも１つのプロセッサは、リファレンスピクチャリサンプリングをサポートするよう構成される、請求項８に記載のビデオエンコーダ。
【請求項12】
前記リファレンスピクチャリサンプリングによると、インター予測されるブロックのリファレンスピクチャは、前記リファレンスピクチャと、前記インター予測されるブロックが前記インター予測されるブロックのインター予測信号を提供するよう含まれるピクチャとの間のスケーリングウィンドウサイズ乖離又はサンプル解像度乖離を埋めるためサンプルリサンプリングを受ける、請求項１１に記載のビデオエンコーダ。
【請求項13】
前記ピクチャのシーケンスは、符号化順に連続するピクチャを含み、前記ピクチャのシーケンスは、符号化順にＣＲＡピクチャからスタートする、請求項８に記載のビデオエンコーダ。
【請求項14】
前記１つ以上の符号化ツールのセットはさらに、クロスコンポーネントリニアモデルに基づく予測ツールとデコーダサイド動きベクトルリファイメントツールとを含む、請求項８に記載のビデオエンコーダ。
【請求項15】
ビデオ復号化の方法であって、データストリームからＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）メッセージを復号化することを含み、
前記ＳＥＩメッセージは、ピクチャのシーケンス内の全てのＲＡＳＬ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｓｋｉｐｐｅｄ Ｌｅａｄｉｎｇ）ピクチャの符号化が１つ以上の符号化ツールの所定のセットを除く方法で制限されることを通知し、前記所定のセットはラップアラウンド動き補償ツールを含み、前記ピクチャのシーケンスは、少なくとも１つのＲＡＳＬピクチャと前記少なくとも１つのＲＡＳＬピクチャに関連するＣＲＡ（Ｃｌｅａｎ Ｒａｎｄｏｍ Ａｃｃｅｓｓ）ピクチャとを含む、方法。
【請求項16】
ビデオ符号化の方法であって、データストリームにＳＥＩ（Ｓｕｐｐｌｅｍｅｎｔａｌ Ｅｎｈａｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）メッセージを符号化することを含み、
前記ＳＥＩメッセージは、ピクチャのシーケンス内の全てのＲＡＳＬ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｓｋｉｐｐｅｄ Ｌｅａｄｉｎｇ）ピクチャの符号化が１つ以上の符号化ツールの所定のセットを除く方法で制限されることを通知し、前記所定のセットはラップアラウンド動き補償ツールを含み、前記ピクチャのシーケンスは、少なくとも１つのＲＡＳＬピクチャと前記少なくとも１つのＲＡＳＬピクチャに関連するＣＲＡ（Ｃｌｅａｎ Ｒａｎｄｏｍ Ａｃｃｅｓｓ）ピクチャとを含む、方法。
【国際調査報告】