ホーム > 特許ランキング > ＢＹＴＥＤＡＮＣＥ ＩＮＣ．
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-09-20
(54)【発明の名称】ビデオ処理のための方法、デバイス、及び媒体
(51)【国際特許分類】
H04N 21/435 20110101AFI20240912BHJP
H04N 21/431 20110101ALI20240912BHJP
H04N 21/44 20110101ALI20240912BHJP
H04N 21/84 20110101ALI20240912BHJP
H04N 19/46 20140101ALI20240912BHJP
【ＦＩ】
H04N21/435
H04N21/431
H04N21/44
H04N21/84
H04N19/46
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024518807
(86)(22)【出願日】2022-09-26
(85)【翻訳文提出日】2024-03-29
(86)【国際出願番号】 US2022077048
(87)【国際公開番号】W WO2023049916
(87)【国際公開日】2023-03-30
(31)【優先権主張番号】63/248,852
(32)【優先日】2021-09-27
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】520477474
【氏名又は名称】バイトダンス インコーポレイテッド
【氏名又は名称原語表記】ＢＹＴＥＤＡＮＣＥ ＩＮＣ．
【住所又は居所原語表記】１２６５５ Ｗｅｓｔ Ｊｅｆｆｅｒｓｏｎ Ｂｏｕｌｅｖａｒｄ， Ｓｉｘｔｈ Ｆｌｏｏｒ， Ｓｕｉｔｅ Ｎｏ． １３７ Ｌｏｓ Ａｎｇｅｌｅｓ， Ｃａｌｉｆｏｒｎｉａ ９００６６ Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100229448
【弁理士】
【氏名又は名称】中槇 利明
(72)【発明者】
【氏名】ワン，イェ－クイ
【テーマコード（参考）】
5C159
5C164
【Ｆターム（参考）】
5C159MA04
5C159MA05
5C159MC11
5C159ME01
5C159PP04
5C159RC12
5C159UA02
5C159UA05
5C164FA06
5C164MA02S
5C164MB13P
5C164SC03S
5C164UB01P
5C164UB10P
5C164UB85P
(57)【要約】
本開示の実施形態は、ビデオ処理のための方案を提供する。ビデオ処理のための方法が提案される。前記方法は、第１のデバイスによって、サーバからメタデータファイルを受信するステップと、前記メタデータファイルから、第２のビデオ内の第２セットの符号化ビデオユニットによって置き換え可能なターゲットピクチャ・イン・ピクチャ領域を表す、第１のビデオの各ピクチャ内の第１セットの符号化ビデオデータユニットを示すための領域識別子（ID）のリスト、を決定するステップと、を含む。
【選択図】 図8
【選択図】 図8
【特許請求の範囲】
【請求項1】
ビデオ処理方法であって、第１のデバイスによって、サーバからメタデータファイルを受信するステップと、
前記メタデータファイルから、第２のビデオ内の第２セットの符号化ビデオユニットによって置き換え可能なターゲットピクチャ・イン・ピクチャ領域を表す、第１のビデオの各ピクチャ内の第１セットの符号化ビデオデータユニットを示すための領域識別子（ID）のリストを決定するステップとを含む、方法。
【請求項2】
前記領域IDのリストは、前記メタデータファイル内の記述子の要素の属性である、請求項１に記載の方法。
【請求項3】
前記属性はregionIdsである、請求項２に記載の方法。
【請求項4】
前記領域IDのリスト内の１つの領域IDは、前記第１のビデオを復号する前に、前記第１のビデオ内の領域IDを有する前記第１セットの符号化ビデオデータユニットを、前記第２のビデオ内の領域IDを有する前記第２セットの符号化ビデオユニットに置き換えることを可能にする、請求項１～３のいずれか一項に記載の方法。
【請求項5】
前記領域IDのリスト内の領域IDは、サブピクチャIDであり、前記第１セットの符号化ビデオデータユニットは、第１セットのビデオ符号化層ネットワーク抽象化層（VCL NAL）ユニットを含み、
前記第２セットの符号化ビデオデータユニットは、第２セットのVCL NALユニットを含む、請求項１～４のいずれか一項に記載の方法。
【請求項6】
ビデオ処理方法であって、第２のデバイスでメタデータファイルを決定するステップであって、前記メタデータファイルは、第２のビデオ内の第２セットの符号化ビデオユニットによって置き換え可能なターゲットピクチャ・イン・ピクチャ領域を表す、第１のビデオの各ピクチャ内の第１セットの符号化ビデオデータユニットを示すための領域識別子（ID）のリストを含むステップと、
前記メタデータファイルを第１のデバイスに送信するステップとを含む、方法。
【請求項7】
前記領域IDのリストは、前記メタデータファイル内の記述子の要素の属性である、請求項６に記載の方法。
【請求項8】
前記属性はregionIdsである、請求項７に記載の方法。
【請求項9】
前記領域IDのリスト内の１つの領域IDは、前記第１のビデオを復号する前に、前記第１のビデオ内の領域IDを有する前記第１セットの符号化ビデオデータユニットを、前記第２のビデオ内の領域IDを有する前記第２セットの符号化ビデオユニットに置き換えることを可能にする、請求項６～８のいずれか一項に記載の方法。
【請求項10】
前記領域IDのリスト内の領域IDは、サブピクチャIDであり、前記第１セットの符号化ビデオデータユニットは、第１セットのビデオ符号化層ネットワーク抽象化層（VCL NAL）ユニットを含み、
前記第２セットの符号化ビデオデータユニットは、第２セットのVCL NALユニットを含む、請求項６～９のいずれか一項に記載の方法。
【請求項11】
プロセッサと命令を備えた非一時的メモリとを含むビデオデータを処理する装置であって、前記命令は、前記プロセッサによって実行されると、前記プロセッサに請求項１～１０のいずれか一項に記載の方法を実行させる、装置。
【請求項12】
プロセッサに請求項１～１０のいずれか一項に記載の方法を実行させる命令を記憶する、非一時的なコンピュータ可読記憶媒体。【発明の詳細な説明】
【技術分野】
【0001】
本開示の実施形態は、概して、ビデオ符号化技術に関し、より具体的には、ファイルフォーマットでのデジタルオーディオビデオメディア情報の生成、記憶、及び消費に関する。
【0002】
関連出願の相互参照
本出願は、２０２１年９月２７日に出願された米国仮出願第63/248,852号に対する優先権の利益を主張するものであり、その全内容は、参照により本明細書に組み込まれている。
本出願は、２０２１年９月２７日に出願された米国仮出願第63/248,852号に対する優先権の利益を主張するものであり、その全内容は、参照により本明細書に組み込まれている。
【背景技術】
【0003】
メディアストリーミングアプリケーションは、通常、インターネットプロトコル（IP）、伝送制御プロトコル（TCP）、及びハイパーテキスト転送プロトコル（HTTP）の転送方法に基づいており、通常、ISOベースメディアファイルフォーマット（ISOBMFF）などのファイルフォーマットに依存している。このようなストリーミングシステムの１つは、HTTPベースの動的適応型ストリーミング（DASH）である。HTTPベースの動的適応型ストリーミング（DASH）では、マルチメディアコンテンツのビデオ及び／又はオーディオデータの多重表現が存在し得るが、異なる表現は、異なる符号化特性（例えば、ビデオ符号化規格の異なるプロファイル又はレベル、異なるビットレート、異なる空間解像度、など）に対応し得る。また、「ピクチャ・イン・ピクチャ」と呼ばれる技術が提案されている。したがって、ピクチャ・イン・ピクチャサービスをサポートするDASHについては研究する価値がある。
【発明の概要】
【0004】
本開示の実施形態は、ビデオ処理のための方案を提供する。
【0005】
第１の態様では、ビデオ処理のための方法が提案される。前記方法は、第１のデバイスによって、第２のデバイスからメタデータファイルを受信するステップと、前記メタデータファイルから、補助ビデオ内の第２セットの符号化ビデオユニットによって置き換え可能なターゲットピクチャ・イン・ピクチャ領域を表す、メインビデオの各ピクチャ内の第１セットの符号化ビデオデータユニットを示すための領域識別子（ID）のリスト、を決定するステップと、を含む。このようにして、前記第１のデバイスは、前記第１のビデオの各ピクチャ内のどの符号化ビデオデータユニットがターゲットピクチャ・イン・ピクチャ領域を表すかを知り、置き換えを実行できる。
【0006】
第２の態様では、別のビデオ処理のための方法が提案される。前記方法は、第２のデバイスによって、メタデータファイルを決定するステップであり、前記メタデータファイルは、第２のビデオ内の第２セットの符号化ビデオユニットによって置き換え可能なターゲットピクチャ・イン・ピクチャ領域を表す、第１のビデオの各ピクチャ内の第１セットの符号化ビデオデータユニットを示すための領域識別子（ID）のリスト、を含むステップと、前記メタデータファイルを、第１のデバイスに送信するステップと、を含む。このようにして、前記第１のデバイスは、前記第１のビデオの各ピクチャ内のどの符号化ビデオデータユニットがターゲットピクチャ・イン・ピクチャ領域を表すかを知り、置き換えを実行できる。
【0007】
第３の態様では、ビデオデータを処理する装置が提案される。前記ビデオデータを処理する装置は、プロセッサと、命令を備えた非一時的メモリとを含む。前記命令は、前記プロセッサによって実行されると、前記プロセッサに本開示の第１又は第２の態様による方法を実行させる。
【0008】
第４の態様では、非一時的なコンピュータ可読記憶媒体が提案される。前記非一時的なコンピュータ可読記憶媒体は、前記プロセッサに、本開示の第１又は第２の態様による方法を実行させる命令を記憶する。
【0009】
この発明の内容は、以下の詳細な説明でさらに記述される概念の選択を簡略化した形で紹介するために提供される。この発明の内容は、請求される技術的事項の主な特徴又は本質的な特徴を特定することを意図したものではなく、また、請求される技術的事項の範囲を制限するために使用されることを意図したものでもない。
【図面の簡単な説明】
【0010】
添付の図面を参照した以下の詳細な説明を通じて、本開示の例示的な実施形態の上記及び他の目的、特徴、及び利点がより明らかになるであろう。本開示の例示的な実施形態では、同じ参照番号は、通常、同じ構成要素を指す。
【図1】本開示のいくつかの実施形態に従った、例示的なビデオ符号化システムに係るブロック図を示す。
【図2】本開示のいくつかの実施形態に従った、ビデオエンコーダの第１の例に係るブロック図を示す。
【図3】本開示のいくつかの実施形態に従った、例示的なビデオデコーダに係るブロック図を示す。
【図4】１８個のタイル、２４個のスライス、及び２４個のサブピクチャに分割されたピクチャの概略図を示す。
【図5】一般的なサブピクチャベースのビューポート依存の３６０度ビデオ配信スキームに係る概略図を示す。
【図6】２つのサブピクチャと４つのスライスを含むビットストリームからの１つのサブピクチャの抽出に係る概略図を示す。
【図7】VVCサブピクチャに基づくピクチャ・イン・ピクチャサポートに係る概略図を示す。
【図8】本開示の実施形態に従った、方法のフローチャートを示す。
【図9A】ピクチャ・イン・ピクチャの概略図を示す。
【図9B】ピクチャ・イン・ピクチャの概略図を示す。
【図10】本開示の実施形態に従った、方法のフローチャートを示す。
【図11】本開示の様々な実施形態を実施できるコンピューティングデバイスに係るブロック図を示す。
【0011】
図面の全体にわたって、同じ又は類似の参照番号は、通常、同じ又は類似の要素を指す。
【発明を実施するための形態】
【0012】
次に、いくつかの実施形態を参照して、本開示の原理を説明する。これらの実施形態は、説明のみを目的として記載されており、当業者が本開示を理解し実施するのを助けるものであり、本開示の範囲に関して、いかなる限定も示唆するものではないことを理解すべきである。本明細書に記載の開示は、以下に記載する方法以外にも、様々な方法で実施することができる。
【0013】
以下の説明及び特許請求の範囲において、別段の定義がない限り、本明細書で使用されるすべての技術用語及び科学用語は、本開示が属する技術分野の当業者によって一般に理解されるものと同じ意味を有する。
【0014】
本開示における「一つの実施形態」、「一実施形態」、「例示的な実施形態」などへの言及は、記載される実施形態が、特定の特徴、構造、又は特性を含み得ることを示すが、必ずしもすべての実施形態が、特定の特徴、構造、又は特性を含むとは限らない。また、そのような語句は、必ずしも同じ実施形態を指しているわけではない。さらに、特定の特徴、構造、又は特性が、例示的な実施形態に関連して説明される場合、明示的に記載されているかどうかにかかわらず、他の実施形態に関連して、そのような特徴、構造、又は特性に影響を与えることは、当業者の知識の範囲内であることが指摘される。
【0015】
「第１」及び「第２」などの用語は、本明細書では、様々な要素を説明するために使用され得るが、これらの要素は、これらの用語によって限定されるべきではないことを理解すべきである。これらの用語は、ある要素を別の要素と区別するためにのみ使用されている。例えば、例示的な実施形態の範囲から逸脱することなく、第１の要素が第２の要素と呼ばれ得る。同様に、第２の要素が第１の要素と呼ばれ得る。本明細書で使用される「及び／又は」という用語には、列挙された用語の１つ又は複数のあらゆる組み合わせが含まれる。
【0016】
本明細書で使用される用語は、特定の実施形態を説明することのみを目的としており、例示的な実施形態を限定することを意図したものではない。本明細書で使用されるように、単数形「a（一つの）」、「an（一つの）」、及び「the（その）」は、文脈上明らかに別段の指示がない限り、複数形も含むものとする。「含む」、「備える」、「有する」、「持つ」、「含む」、及び／又は「包含する」という用語は、本明細書で使用される場合、記載された特徴、要素、及び／又は、構成要素など、の存在を特定するが、１つ又は複数の他の特徴、要素、構成要素、及び／又は、それらの組み合わせの存在又は追加を排除するものではないことが、さらに理解されるであろう。
【0017】
例示的な環境
図１は、本開示の技術を利用し得る例示的なビデオ符号化システム１００を示すブロック図である。図示されるように、ビデオ符号化システム１００は、ソースデバイス１１０、及び、宛先デバイス１２０を含み得る。ソースデバイス１１０は、ビデオ符号化デバイスとも呼ばれ得る。宛先デバイス１２０は、ビデオ復号デバイスとも呼ばれ得る。動作中、ソースデバイス１１０は、符号化されたビデオデータを生成するように構成され、宛先デバイス１２０は、ソースデバイス１１０によって生成された符号化されたビデオデータを復号するように構成され得る。ソースデバイス１１０は、ビデオソース１１２と、ビデオエンコーダ１１４と、入出力（I/O）インターフェース１１６とを含み得る。
図１は、本開示の技術を利用し得る例示的なビデオ符号化システム１００を示すブロック図である。図示されるように、ビデオ符号化システム１００は、ソースデバイス１１０、及び、宛先デバイス１２０を含み得る。ソースデバイス１１０は、ビデオ符号化デバイスとも呼ばれ得る。宛先デバイス１２０は、ビデオ復号デバイスとも呼ばれ得る。動作中、ソースデバイス１１０は、符号化されたビデオデータを生成するように構成され、宛先デバイス１２０は、ソースデバイス１１０によって生成された符号化されたビデオデータを復号するように構成され得る。ソースデバイス１１０は、ビデオソース１１２と、ビデオエンコーダ１１４と、入出力（I/O）インターフェース１１６とを含み得る。
【0018】
ビデオソース１１２は、ビデオキャプチャデバイスなどのソースを含み得る。ビデオキャプチャデバイスの例には、ビデオコンテンツプロバイダからビデオデータを受信するインターフェース、ビデオデータを生成するコンピュータグラフィックスシステム、及び／又は、それらの組み合わせが含まれるが、これらに限定されない。
【0019】
ビデオデータは、１つ又は複数のピクチャを含み得る。ビデオエンコーダ１１４は、ビデオソース１１２からのビデオデータを符号化して、ビットストリームを生成する。ビットストリームには、ビデオデータの符号化表現を形成する一連のビットが含まれ得る。ビットストリームには、符号化ピクチャ及び関連データが含まれ得る。符号化ピクチャは、ピクチャの符号化表現である。関連データには、シーケンスパラメータセット、ピクチャパラメータセット、及び、他のシンタックス構造が含まれ得る。I/Oインターフェース１１６は、変調器/復調器、及び／又は、送信機を含み得る。符号化されたビデオデータは、I/Oインターフェース１１６を介して、ネットワーク１３０Ａを通して、宛先デバイス１２０に直接送信され得る。符号化されたビデオデータは、宛先デバイス１２０によるアクセスのために、記憶媒体/サーバ１３０Ｂに記憶され得る。
【0020】
宛先デバイス１２０は、I/Oインターフェース１２６と、ビデオデコーダ１２４と、表示デバイス１２２とを含み得る。I/Oインターフェース１２６は、受信機及び／又はモデムを含み得る。I/Oインターフェース１２６は、ソースデバイス１１０又は記憶媒体/サーバ１３０Ｂから、符号化されたビデオデータを取得し得る。ビデオデコーダ１２４は、符号化されたビデオデータを復号し得る。表示デバイス１２２は、復号されたビデオデータを、ユーザに表示し得る。表示デバイス１２２は、宛先デバイス１２０と一体化されてもよいし、或いは、外部表示デバイスとインターフェースするように構成された、宛先デバイス１２０の外部にあってもよい。
【0021】
ビデオエンコーダ１１４及びビデオデコーダ１２４は、High Efficiency Video Coding（高効率ビデオ符号化、HEVC）規格、Versatile Video Coding（多用途ビデオ符号化、VVC）規格、及び、他の現在及び／又はさらなる規格などのビデオ圧縮規格に従って、動作し得る。
【0022】
【0023】
ビデオエンコーダ２００は、本開示の技術のいずれか又はすべてを実施するように構成され得る。図２の例において、ビデオエンコーダ２００は、複数の機能コンポーネントを含む。本開示で説明される技術は、ビデオエンコーダ２００の様々なコンポーネント間で共有され得る。いくつかの例において、プロセッサは、本開示で説明された技術のいずれか又はすべてを実行するように構成され得る。
【0024】
いくつかの実施形態において、ビデオエンコーダ２００は、分割ユニット２０１と、モード選択ユニット２０３、動き推定ユニット２０４、動き補償ユニット２０５、及びイントラ予測ユニット２０６を含み得る予測ユニット２０２と、残差生成ユニット２０７と、変換ユニット２０８と、量子化ユニット２０９と、逆量子化ユニット２１０と、逆変換ユニット２１１と、再構築ユニット２１２と、バッファ２１３と、エントロピー符号化ユニット２１４とを含み得る。
【0025】
他の例において、ビデオエンコーダ２００は、より多くの、より少ない、又は、異なる機能コンポーネントを含み得る。一例において、予測ユニット２０２は、イントラブロックコピー（IBC）ユニットを含み得る。IBCユニットは、少なくとも１つの参照ピクチャが、現在ビデオブロックが位置するピクチャである、IBCモードで予測を実行し得る。
【0026】
さらに、動き推定ユニット２０４及び動き補償ユニット２０５などのいくつかの構成要素は統合され得るが、図２の例では、説明の目的で別々に表されている。
【0027】
分割ユニット２０１は、ピクチャを１つ又は複数のビデオブロックに分割し得る。ビデオエンコーダ２００及びビデオデコーダ３００は、多様なビデオブロックサイズをサポートし得る。
【0028】
モード選択ユニット２０３は、例えば、エラー結果に基づいて、イントラ符号化モード又はインター符号化モードのうちの１つを選択し、その結果から得られるイントラ符号化又はインター符号化されたブロックを、残差ブロックデータを生成するように残差生成ユニット２０７に提供し、符号化されたブロックを再構築して、参照ピクチャとして使用するように再構築ユニット２１２に提供し得る。いくつかの例では、モード選択ユニット２０３は、予測がインター予測信号及びイントラ予測信号に基づくイントラ及びインター予測の組み合わせ（CIIP）モードを選択し得る。モード選択ユニット２０３は、インター予測の場合、ブロックの動きベクトルの解像度（例えば、サブピクセル又は整数ピクセル精度）を選択し得る。
【0029】
現在ビデオブロックに対してインター予測を実行するために、動き推定ユニット２０４は、バッファ２１３からの１つ又は複数の参照フレームを現在ビデオブロックと比較することによって、現在ビデオブロックの動き情報を生成し得る。動き補償ユニット２０５は、現在ビデオブロックに関連するピクチャ以外のバッファ２１３からのピクチャの動き情報及び復号化サンプルに基づいて、現在ビデオブロックの予測ビデオブロックを決定し得る。
【0030】
動き推定ユニット２０４及び動き補償ユニット２０５は、例えば、現在ビデオブロックがIスライス、Pスライス、又はBスライスのいずれにあるかに応じて、現在ビデオブロックに対して異なる演算を実行し得る。本明細書で使用されるように、「Iスライス」は、マクロブロックから構成されるピクチャの一部を指すことができ、そのすべてが同じピクチャ内のマクロブロックに基づいている。さらに、本明細書で使用されるように、いくつかの態様では、「Pスライス」及び「Bスライス」は、同じピクチャ内のマクロブロックに依存しないマクロブロックから構成されるピクチャの部分を指し得る。
【0031】
いくつかの例では、動き推定ユニット２０４は、現在ビデオブロックに対して単方向予測を実行することができ、動き推定ユニット２０４は、現在ビデオブロックの参照ビデオブロックに対するリスト０又はリスト１の参照ピクチャを探し得る。次に、動き推定ユニット２０４は、参照ビデオブロックを含むリスト０又はリスト１内の参照ピクチャを示す参照インデックスと、現在ビデオブロックと参照ビデオブロックとの間の空間変位を示す動きベクトルとを生成し得る。動き推定ユニット２０４は、参照インデックス、予測方向指示子、及び動きベクトルを、現在ビデオブロックの動き情報として出力し得る。動き補償ユニット２０５は、現在ビデオブロックの動き情報によって示される参照ビデオブロックに基づいて、現在ビデオブロックの予測ビデオブロックを生成し得る。
【0032】
代替形態として、他の例では、動き推定ユニット２０４は、現在ビデオブロックに対して双方向予測を実行し得る。動き推定ユニット２０４は、現在ビデオブロックの参照ビデオブロックに対するリスト０内の参照ピクチャを探してもよいし、現在ビデオブロックの別の参照ビデオブロックに対するリスト１内の参照ピクチャを探してもよい。次に、動き推定ユニット２０４は、参照ビデオブロックを含むリスト０及びリスト１内の参照ピクチャを示す参照インデックス、及び、参照ビデオブロックと現在ビデオブロックとの間の空間変位を示す動きベクトルを生成し得る。動き推定ユニット２０４は、現在ビデオブロックの参照インデックス及び動きベクトルを、現在ビデオブロックの動き情報として出力し得る。動き補償ユニット２０５は、現在ビデオブロックの動き情報によって示される参照ビデオブロックに基づいて、現在ビデオブロックの予測ビデオブロックを生成し得る。
【0033】
いくつかの例では、動き推定ユニット２０４は、デコーダの復号処理のためのフルセットの動き情報を出力し得る。代替形態として、いくつかの実施形態では、動き推定ユニット２０４は、別のビデオブロックの動き情報を参照して、現在ビデオブロックの動き情報をシグナリングし得る。例えば、動き推定ユニット２０４は、現在ビデオブロックの動き情報が隣接するビデオブロックの動き情報と十分に類似していると判定し得る。
【0034】
一例では、動き推定ユニット２０４は、現在ビデオブロックに関連付けられたシンタックス構造において、現在ビデオブロックが別のビデオブロックと同じ動き情報を有することをビデオデコーダ３００に示す値を示し得る。
【0035】
別の例では、動き推定ユニット２０４は、現在ビデオブロックに関連付けられたシンタックス構造において、別のビデオブロック及び動きベクトル差分（MVD）を識別し得る。動きベクトル差分は、現在ビデオブロックの動きベクトルと、指示されたビデオブロックの動きベクトルとの間の差分を示す。ビデオデコーダ３００は、指示されたビデオブロックの動きベクトル及び動きベクトル差分を使用して、現在ビデオブロックの動きベクトルを決定し得る。
【0036】
上で論じたように、ビデオエンコーダ２００は、動きベクトルを予測的にシグナリングし得る。ビデオエンコーダ２００によって実施され得る予測シグナリング技術の２つの例には、アドバンスト動きベクトル予測（AMVP）及びマージモードシグナリングが含まれる。
【0037】
イントラ予測ユニット２０６は、現在ビデオブロックに対してイントラ予測を実行し得る。イントラ予測ユニット２０６が現在ビデオブロックに対してイントラ予測を実行するとき、イントラ予測ユニット２０６は、同じピクチャ内の他のビデオブロックの復号されたサンプルに基づいて、現在ビデオブロックに対する予測データを生成し得る。現在ビデオブロックに対する予測データには、予測されたビデオブロック及び様々なシンタックス要素が含まれ得る。
【0038】
残差生成ユニット２０７は、現在ビデオブロックから現在ビデオブロックの予測ビデオブロックを減算する（例えば、マイナス記号によって示される）ことによって、現在ビデオブロックに対する残差データを生成し得る。現在ビデオブロックの残差データは、現在ビデオブロック内のサンプルの異なるサンプル成分に対応する残差ビデオブロックを含み得る。
【0039】
他の例では、例えば、スキップモードにおいて、現在ビデオブロックに対する残差データが存在しなくてもよいし、残差生成ユニット２０７は減算演算を実行しなくてもよい。
【0040】
変換処理ユニット２０８は、現在ビデオブロックに関連付けられた残差ビデオブロックに１つ又は複数の変換を適用することによって、現在ビデオブロックに対する１つ又は複数の変換係数ビデオブロックを生成し得る。
【0041】
変換処理ユニット２０８が現在ビデオブロックに関連付けられた変換係数ビデオブロックを生成した後で、量子化ユニット２０９は、現在ビデオブロックに関連付けられた１つ又は複数の量子化パラメータ（QP）値に基づいて、現在ビデオブロックに関連付けられた変換係数ビデオブロックを量子化し得る。
【0042】
逆量子化ユニット２１０及び逆変換ユニット２１１は、それぞれ、変換係数ビデオブロックに逆量子化及び逆変換を適用して、変換係数ビデオブロックから残差ビデオブロックを再構築し得る。再構築ユニット２１２は、再構築された残差ビデオブロックを、予測ユニット２０２によって生成された１つ又は複数の予測ビデオブロックからの対応するサンプルに追加して、バッファ２１３に記憶するために現在ビデオブロックに関連付けられた再構築ビデオブロックを生成し得る。
【0043】
再構築ユニット２１２がビデオブロックを再構成した後で、ループフィルタリング動作が実行されて、ビデオブロック内のビデオブロッキングアーティファクトを低減し得る。
【0044】
エントロピー符号化ユニット２１４は、ビデオエンコーダ２００の他の機能コンポーネントからデータを受信し得る。エントロピー符号化ユニット２１４がデータを受信すると、エントロピー符号化ユニット２１４は、１つ又は複数のエントロピー符号化動作を実行して、エントロピー符号化データを生成し、エントロピー符号化データを含むビットストリームを出力し得る。
【0045】
【0046】
ビデオデコーダ３００は、本開示の技術のいずれか又はすべてを実行するように構成され得る。図３の例では、ビデオデコーダ３００は複数の機能コンポーネントを含む。本開示で説明される技術は、ビデオデコーダ３００の様々なコンポーネント間で共有され得る。いくつかの例では、プロセッサは、本開示で説明された技術のいずれか又はすべてを実行するように構成され得る。
【0047】
図３の例では、ビデオデコーダ３００は、エントロピー復号ユニット３０１と、動き補償ユニット３０２と、イントラ予測ユニット３０３と、逆量子化ユニット３０４と、逆変換ユニット３０５と、再構築ユニット３０６と、バッファ３０７とを含む。ビデオデコーダ３００は、いくつかの例では、ビデオエンコーダ２００に関して説明した符号化パスとは、一般に、逆の復号パスを実行し得る。
【0048】
エントロピー復号ユニット３０１は、符号化されたビットストリームを検索し得る。符号化されたビットストリームは、エントロピー符号化されたビデオデータ（例えば、ビデオデータの符号化されたブロック）を含み得る。エントロピー復号ユニット３０１は、エントロピー符号化されたビデオデータを復号することができ、エントロピー復号されたビデオデータから、動き補償ユニット３０２は、動きベクトル、動きベクトル精度、参照ピクチャリストインデックス、及び他の動き情報を含む動き情報を決定し得る。動き補償ユニット３０２は、例えば、AMVP及びマージモードを実行することによって、そのような情報を決定し得る。AMVPが使用され、隣接するPB及び参照ピクチャからのデータに基づいた、最もあり得るいくつかの候補の導出を含む。動き情報には、通常、水平及び垂直動きベクトル変位値、１つ又は２つの参照ピクチャインデックス、及びBスライス内の予測領域の場合は、どの参照ピクチャリストが各インデックスに関連付けられているかの識別が含まれる。本明細書で使用されるように、いくつかの態様では、「マージモード」は、空間的又は時間的に隣接するブロックから動き情報を導出することを指し得る。
【0049】
動き補償ユニット３０２は、おそらく、補間フィルタに基づいて補間を実行しながら、動き補償されたブロックを生成し得る。サブピクセル精度で使用される補間フィルタの識別子は、シンタックス要素に含まれ得る。
【0050】
動き補償ユニット３０２は、ビデオブロックの符号化中にビデオエンコーダ２００によって使用される補間フィルタを使用して、参照ブロックのサブ整数ピクセルに対する補間値を計算し得る。動き補償ユニット３０２は、受信したシンタックス情報に従って、ビデオエンコーダ２００によって使用される補間フィルタを決定し、その補間フィルタを使用して、予測ブロックを生成し得る。
【0051】
動き補償ユニット３０２は、シンタックス情報の少なくとも一部を使用して、符号化されたビデオシーケンスのフレーム及び／又はスライスを符号化するために使用されるブロックのサイズ、符号化されたビデオシーケンスのピクチャの各マクロブロックがどのように分割されるかを説明するパーティション情報、各パーティションがどのように符号化されるかを示すモード、各インターエンコードされたブロックの１つ又は複数の参照フレーム(及び、参照フレームリスト)、及び、符号化されたビデオシーケンスを復号するその他の情報を決定し得る。本明細書で使用されるように、いくつかの態様では、「スライス」は、エントロピー符号化、信号予測、及び残差信号再構築に関して、同じピクチャの他のスライスから独立して復号できるデータ構造を指し得る。スライスは、ピクチャ全体又はピクチャの領域のいずれかになり得る。
【0052】
イントラ予測ユニット３０３は、例えば、ビットストリームで受信されたイントラ予測モードを使用して、空間的に隣接するブロックから予測ブロックを形成し得る。逆量子化ユニット３０４は、ビットストリームで提供され、エントロピー復号ユニット３０１によって復号された量子化ビデオブロック係数を逆量子化、即ち、量子化解除する。逆変換ユニット３０５は、逆変換を適用する。
【0053】
再構築ユニット３０６は、例えば、残差ブロック、及び、動き補償ユニット３０２又はイントラ予測ユニット３０３によって生成された対応する予測ブロックを加算することによって、復号されたブロックを取得し得る。必要に応じて、デブロッキングフィルタが適用されて、ブロックノイズアーティファクトを除去するよう、復号されたブロックをフィルタリングしてもよい。次に、復号されたビデオブロックは、バッファ３０７に記憶され、バッファ３０７は、後続の動き補償/イントラ予測のための参照ブロックを提供し、また、表示デバイス上にプレゼンテーションするための復号されたビデオも生成する。
【0054】
本開示のいくつかの例示的な実施形態について、以下に、詳細に説明することにする。本明細書では、理解を容易にするためにセクション見出しが使用されているが、セクションで開示される実施形態をそのセクションのみに限定するものではないことを理解すべきである。さらに、特定の実施形態が多用途ビデオ符号化又は他の特定のビデオコーデックを参照して説明されているが、開示された技術は、他のビデオ符号化技術にも適用可能である。さらに、いくつかの実施形態は、ビデオ符号化ステップを詳細に説明するが、符号化を元に戻す対応する復号化ステップは、デコーダによって実施されることが理解されるであろう。さらに、ビデオ処理という用語には、ビデオの符号化又は圧縮、ビデオの符号化又は解凍、及び、ビデオピクセルを１つの圧縮フォーマットから別の圧縮フォーマット又は異なる圧縮ビットレートで表現するビデオトランス符号化が包含される。
【0055】
１．概要
本開示の実施形態は、ビデオストリーミングに関する。具体的には、新しい記述子を介したDynamic Adaptive Streaming over HTTP（DASH）でのピクチャ・イン・ピクチャサービスのサポートに関する。このアイデアは、DASH規格やその拡張などに基づいて、メディアストリーミングシステムに個別に又は様々な組み合わせで適用され得る。
本開示の実施形態は、ビデオストリーミングに関する。具体的には、新しい記述子を介したDynamic Adaptive Streaming over HTTP（DASH）でのピクチャ・イン・ピクチャサービスのサポートに関する。このアイデアは、DASH規格やその拡張などに基づいて、メディアストリーミングシステムに個別に又は様々な組み合わせで適用され得る。
【0056】
２．背景
２．１ ビデオ符号化規格
ビデオ符号化規格は、主によく知られたITU-T及びISO/IEC規格の開発を通じて進化してきた。ITU-TがH.261及びH.263を作成し、ISO/IECがMPEG-1及びMPEG-4 Visualを作成し、この２つの組織が共同でH.262/MPEG-2 Video及びH.264/MPEG-4 Advanced Video Coding（AVC）及びH.265/HEVC規格を作成した。H.262以来、ビデオ符号化規格は、時間予測プラス変換符号化が利用されるハイブリッドビデオ符号化構造に基づいている。HEVCを超える未来ビデオ符号化技術を探すために、ジョイントビデオエクスプロレーションチーム(Joint Video Exploration Team、JVET)が２０１５年にVCEGとMPEGによって共同で設立された。それ以来、多くの新しい方法がJVETによって採用され、ジョイントエクスプロレーションモデル（Joint Exploration Model、JEM）という名前のリファレンスソフトウェアに組み込まれた。その後、Versatile Video coding(VVC)プロジェクトが正式に開始されたときに、JVETはJoint Video Experts Team(JVET)に名前変更された。VVCは、HEVCと比較して、５０％ビットレート低減を目標とする新しい符号化規格であり、２０２０年７月１日に終了した第１９回会議でJVETによって最終完了された。
２．１ ビデオ符号化規格
ビデオ符号化規格は、主によく知られたITU-T及びISO/IEC規格の開発を通じて進化してきた。ITU-TがH.261及びH.263を作成し、ISO/IECがMPEG-1及びMPEG-4 Visualを作成し、この２つの組織が共同でH.262/MPEG-2 Video及びH.264/MPEG-4 Advanced Video Coding（AVC）及びH.265/HEVC規格を作成した。H.262以来、ビデオ符号化規格は、時間予測プラス変換符号化が利用されるハイブリッドビデオ符号化構造に基づいている。HEVCを超える未来ビデオ符号化技術を探すために、ジョイントビデオエクスプロレーションチーム(Joint Video Exploration Team、JVET)が２０１５年にVCEGとMPEGによって共同で設立された。それ以来、多くの新しい方法がJVETによって採用され、ジョイントエクスプロレーションモデル（Joint Exploration Model、JEM）という名前のリファレンスソフトウェアに組み込まれた。その後、Versatile Video coding(VVC)プロジェクトが正式に開始されたときに、JVETはJoint Video Experts Team(JVET)に名前変更された。VVCは、HEVCと比較して、５０％ビットレート低減を目標とする新しい符号化規格であり、２０２０年７月１日に終了した第１９回会議でJVETによって最終完了された。
【0057】
Versatile Video Coding(VVC)規格（ITU-T H.266 |ISO/IEC 23090-3）及び関連する多用途拡張情報（Versatile Supplemental Enhancement Information、VSEI）規格（ITU-T H.274|ISO/IEC 23002-7）は、テレビ放送、ビデオ会議、又は記憶媒体からの再生などの従来の用途と、アダプティブビットレートストリーミング、ビデオ領域の抽出、多重コード化ビデオビットストリームからのコンテンツの合成と結合、マルチビュービデオ、スケーラブルなレイヤードコーディング、及びビューポートアダプティブ３６０度イマーシブメディアなどのより新しく高度な用途の両方を含む、最大限広範囲のアプリケーションで使用されるように設計されている。
【0058】
Essential Video Coding（EVC）規格（ISO/IEC 23094-1）は、MPEGによって最近開発された別のビデオ符号化規格である。
【0059】
２．２ ファイルフォーマット規格
メディアストリーミングアプリケーションは、通常、IP、TCP、及びHTTPトランスポート方法に基づいており、ISOベースメディアファイルフォーマット(ISOBMFF)などのファイルフォーマットに依存する。このようなストリーミングシステムの１つは、HTTPベースの動的適応型ストリーミング(DASH)でする。ISOBMFF及びDASHでビデオフォーマットを使用する場合、ISO/IEC 14496-15のAVCファイルフォーマットやHEVCファイルフォーマットなど、ビデオフォーマットに特有なファイルフォーマット仕様：「情報技術－オーディオビジュアルオブジェクトのコーディング－パート15:ISOベースメディアファイルフォーマット」でのネットワークアブストラクションレイヤー(NAL)ユニット構造化ビデオの搬送は、ISOBMFFトラック及びDASH表現とセグメントでのビデオコンテンツのカプセル化に必要な場合がある。ビデオビットストリームに関する重要な情報、例えば、プロファイル、階層、レベル、その他多くの情報は、コンテンツ選択の目的、例えば、ストリーミングセッションの開始時の初期化とストリーミングセッション中のストリーム適応の両方のための適切なメディアセグメントの選択のために、ファイルフォーマットレベルメタデータ及び／又はDASHメディアプレゼンテーション記述（MPD）として公開されるべきである場合がある。
メディアストリーミングアプリケーションは、通常、IP、TCP、及びHTTPトランスポート方法に基づいており、ISOベースメディアファイルフォーマット(ISOBMFF)などのファイルフォーマットに依存する。このようなストリーミングシステムの１つは、HTTPベースの動的適応型ストリーミング(DASH)でする。ISOBMFF及びDASHでビデオフォーマットを使用する場合、ISO/IEC 14496-15のAVCファイルフォーマットやHEVCファイルフォーマットなど、ビデオフォーマットに特有なファイルフォーマット仕様：「情報技術－オーディオビジュアルオブジェクトのコーディング－パート15:ISOベースメディアファイルフォーマット」でのネットワークアブストラクションレイヤー(NAL)ユニット構造化ビデオの搬送は、ISOBMFFトラック及びDASH表現とセグメントでのビデオコンテンツのカプセル化に必要な場合がある。ビデオビットストリームに関する重要な情報、例えば、プロファイル、階層、レベル、その他多くの情報は、コンテンツ選択の目的、例えば、ストリーミングセッションの開始時の初期化とストリーミングセッション中のストリーム適応の両方のための適切なメディアセグメントの選択のために、ファイルフォーマットレベルメタデータ及び／又はDASHメディアプレゼンテーション記述（MPD）として公開されるべきである場合がある。
【0060】
同様に、ISOBMFFで画像フォーマットを使用する場合、ISO/IEC23008-12：「情報技術-高効率符号化と異種環境でのメディア配信－パート12：画像ファイルフォーマット」でのAVC画像ファイルフォーマット及びHEVC画像ファイルフォーマットなど、画像フォーマットに特有のファイルフォーマット仕様が必要な場合がある。
【0061】
ISOBMFFに基づいたVVCビデオコンテンツを保存するためのファイルフォーマットである、VVCビデオファイルフォーマットは、現在MPEGによって開発されている。VVCビデオファイルフォーマットの最新の仕様草案は、ISO/IEC JTC １/SC 29/WG 03出力文書N0035「Potential improvements on Carriage of VVC and EVC in ISOBMFF（ISOBMFFにおけるVVC及びEVCの搬送に関する潜在的な改善）」に含まれている。
【0062】
ISOBMFFに基づいた、VVCを使用して符号化された画像コンテンツを保存するためのファイル形式である、VVC画像ファイルフォーマットは、現在MPEGによって開発されている。VVC画像ファイルフォーマットの最新のドラフト仕様は、ISO/IEC JTC 1/SC 29/WG 03出力文書N0038「Information technology－High efficiency coding and media delivery in heterogeneous environments－Part 12: Image File Format－Amendment 3: Support for VVC, EVC, slideshows and other improvements (CD stage)（情報技術-異種環境での高効率符号化とメディア配信－パート12:画像ファイルフォーマット－修正3：VVC、EVC、スライドショーに対するサポート及びその他の改善(CDステージ)）」に含まれている。
【0063】
２．３ DASH
Dynamic Adaptive Streaming over HTTP(DASH)では、マルチメディアコンテンツのビデオ及び／又はオーディオデータの多重表現が存在し得るが、異なる表現は、異なる符号化特性（例えば、ビデオ符号化規格の異なるプロファイル又はレベル、異なるビットレート、異なる空間解像度など）に対応し得る。このような表現のマニフェストは、Media Presentation Description(MPD)データ構造で定義され得る。メディアプレゼンテーションは、DASHストリーミングクライアントデバイスにアクセス可能なデータの構造化コレクションに対応し得る。DASHストリーミングクライアントデバイスは、クライアントデバイスのユーザにストリーミングサービスを提供するようにメディアデータ情報を要求し、ダウンロードし得る。メディアプレゼンテーションは、MPDの更新を含むMPDデータ構造で記述され得る。
Dynamic Adaptive Streaming over HTTP(DASH)では、マルチメディアコンテンツのビデオ及び／又はオーディオデータの多重表現が存在し得るが、異なる表現は、異なる符号化特性（例えば、ビデオ符号化規格の異なるプロファイル又はレベル、異なるビットレート、異なる空間解像度など）に対応し得る。このような表現のマニフェストは、Media Presentation Description(MPD)データ構造で定義され得る。メディアプレゼンテーションは、DASHストリーミングクライアントデバイスにアクセス可能なデータの構造化コレクションに対応し得る。DASHストリーミングクライアントデバイスは、クライアントデバイスのユーザにストリーミングサービスを提供するようにメディアデータ情報を要求し、ダウンロードし得る。メディアプレゼンテーションは、MPDの更新を含むMPDデータ構造で記述され得る。
【0064】
メディアプレゼンテーションには、一連の１つ又は複数の期間が含まれ得る。各期間は、次の期間の開始まで、又は、最後の期間の場合は、メディアプレゼンテーションの終了まで延長され得る。各期間には、同じメディアコンテンツの１つ又は複数の表現が含まれ得る。表現は、オーディオ、ビデオ、タイムドテキスト、又はその他のそのようなデータの多数の代替的符号化バージョンのうちの１つになり得る。表現は、符号化タイプ、例えば、ビデオデータのビットレート、解像度、及び／又はコーデック、及びオーディオデータのビットレート、言語、及び／又はコーデックによって異なり得る。表現という用語は、マルチメディアコンテンツの特定の期間に対応し、特定の方式で符号化された、符号化されたオーディオ又はビデオデータのセクションを指すために使用され得る。
【0065】
特定の期間の表現は、その表現が属するアダプテーションセットを示すMPDにおける属性によって示されるグループに割り当てられ得る。同じアダプテーションセット内の表現は、クライアントデバイスがこれらの表現を、動的かつシームレスに切り替えて、例えば、帯域幅アダプテーションを実行できるという点で、一般に、互いの代替と見なされる。例えば、特定の期間のビデオデータの各表現は、同じアダプテーションセットに割り当てられ得るが、対応する期間のマルチメディアコンテンツのビデオデータ又はオーディオデータなどのメディアデータを提示するように、いずれかの表現が復号化用に選択され得る。１つの期間内のメディアコンテンツは、いくつかの例では、グループ０（存在する場合）からの１つの表現、又は、各非ゼログループからの最大１つの表現の組み合わせのいずれかによって表現され得る。期間の各表現のタイミングデータは、期間の開始時刻に対して相対的に表され得る。
【0066】
表現には、１つ又は複数のセグメントが含まれ得る。各表現には、初期化セグメントが含まれ、表現の各セグメントは、自己初期化であり得る。存在する場合、初期化セグメントは、その表現にアクセスするための初期化情報が含まれ得る。一般に、初期化セグメントには、メディアデータが含まれない。セグメントは、ユニフォームリソースロケーター(URL)、ユニフォームリソース名(URN)、又はユニフォームリソース識別子(URI)などの識別子によって、一意的に参照され得る。MPDは、各セグメントに識別子を提供し得る。いくつかの例では、MPDは、URL、URN、又はURIによってアクセス可能なファイル内のセグメントのデータに対応し得るバイト範囲を範囲属性の形式で提供してもよい。
【0067】
異なるタイプのメディアデータを実質的に同時に検索するために、異なる表現が選択され得る。例えば、クライアントデバイスは、セグメントを検索するためのオーディオ表現、ビデオ表現、及びタイムドテキスト表現を選択し得る。いくつかの例では、クライアントデバイスは、帯域幅適応を実行するための特定の適応セットを選択し得る。即ち、クライアントデバイスは、ビデオ表現を含むアダプテーションセット、オーディオ表現を含むアダプテーションセット、及び／又は、タイムドテキストを含むアダプテーションセットを選択し得る。代替形態として、クライアントデバイスは、特定の種類のメディア（例えば、ビデオ）のアダプテーションセットを選択し、他の種類のメディア（例えば、オーディオ及び／又はタイムドテキスト）の表現を直接的に選択し得る。
【0068】
一般的なDASHストリーミング手順を次のステップで示す。
【0069】
１）クライアントは、MPDを取得する。
【0070】
２）クライアントは、ダウンリンク帯域幅を推定し、推定されたダウンリンク帯域幅及びコーデック、復号能力、表示サイズ、音声言語設定に従って、ビデオ表現及びオーディオ表現を選択する。
【0071】
３）メディアプレゼンテーションの終わりに達しない限り、クライアントは、選択された表現のメディアセグメントを要請し、ストリーミングコンテンツをユーザに提示する。
【0072】
４）クライアントは、ダウンリンク帯域幅を推定し続ける。帯域幅がある方向に著しく変化した場合(例えば、低くなった場合)、クライアントは、新たに推定された帯域幅に合致する異なるビデオ表現を選択し、ステップ３に進む。
【0073】
２．４ VVCでのピクチャ分割及びサブピクチャ
VVCでは、ピクチャは、１つ又は複数のタイル行と、１つ又は複数のタイル列とに分かれる。タイルは、ピクチャの長方形の領域をカバーする一連のCTUである。タイル内のCTUは、そのタイル内で、ラスタースキャン順序でスキャンされる。
VVCでは、ピクチャは、１つ又は複数のタイル行と、１つ又は複数のタイル列とに分かれる。タイルは、ピクチャの長方形の領域をカバーする一連のCTUである。タイル内のCTUは、そのタイル内で、ラスタースキャン順序でスキャンされる。
【0074】
スライスは、整数の完全なタイル、又はピクチャのタイル内の整数の連続する完全なCTU行で構成される。
【0075】
スライスの２つのモード、即ち、ラスタースキャンスライスモードと長方形スライスモードとがサポートされる。ラスタースキャンスライスモードでは、スライスには、ピクチャのタイルラスタースキャン内の完全なタイルのシーケンスが含まれる。長方形スライスモードでは、スライスには、集合的にピクチャの長方形領域を形成する多数の完全なタイル、又は、集合的にピクチャの長方形領域を形成する１つのタイルの連続する完全なCTU行のいずれかが含まれる。長方形スライス内のタイルは、そのスライスに対応する長方形領域内で、タイルラスタースキャン順序でスキャンされる。
【0076】
サブピクチャには、ピクチャの長方形領域を集合的にカバーする１つ又は複数のスライスが含まれる。
【0077】
２．４．１ サブピクチャコンセプト及び機能
VVCでは、各サブピクチャは、例えば、図４に示すように、ピクチャの長方形領域を集合的にカバーする１つ又は複数の完全な長方形のスライスからなる。図４は、１８個のタイル、２４個のスライス、２４個のサブピクチャに分割されたピクチャの概略図４００を示す。サブピクチャは、抽出可能（即ち、同じピクチャ及び復号順序で前のピクチャの他のサブピクチャとは独立して符号化される）、又は、抽出不可能であるように指定され得る。サブピクチャが抽出可能かどうかに関係なく、エンコーダは、インループ・フィルタリング(デブロッキング、SAO、ALFを含む)がサブピクチャ境界を越えて、サブピクチャごとに個別に適用されるかどうかを制御できる。
VVCでは、各サブピクチャは、例えば、図４に示すように、ピクチャの長方形領域を集合的にカバーする１つ又は複数の完全な長方形のスライスからなる。図４は、１８個のタイル、２４個のスライス、２４個のサブピクチャに分割されたピクチャの概略図４００を示す。サブピクチャは、抽出可能（即ち、同じピクチャ及び復号順序で前のピクチャの他のサブピクチャとは独立して符号化される）、又は、抽出不可能であるように指定され得る。サブピクチャが抽出可能かどうかに関係なく、エンコーダは、インループ・フィルタリング(デブロッキング、SAO、ALFを含む)がサブピクチャ境界を越えて、サブピクチャごとに個別に適用されるかどうかを制御できる。
【0078】
機能的には、サブピクチャは、HEVCでの動き制約タイルセット(MCTS)に類似している。両方ともビューポート依存３６０度ビデオストリーミング最適化及び関心領域(ROI)アプリケーションのようなユースケースに対する、独立した符号化及び符号化ピクチャのシーケンスの長方形のサブセットの抽出を可能にする。
【0079】
３６０度ビデオ(別名、全方位ビデオ)のストリーミングでは、特定の瞬間に全方位ビデオ球体全体のサブセット(即ち、現在ビューポート)のみがユーザにレンダリングされ得るが、ユーザは、いつでも頭を回転させて表示方向、結果的には、現在ビューポートを変更できる。現在ビューポートでカバーされていない領域の少なくともある程度の低品質表現をクライアントで利用可能にして、ユーザが突然球上のどこかに表示方向を変更した場合に備えてユーザにレンダリングされるようにしておくことが望ましいが、全方位ビデオの高品質表現は、いかなる瞬間にもユーザにレンダリングされている現在ビューポートにのみ必要である。全方位ビデオ全体の高品質表現を適切な粒度でサブピクチャに分割することで、左側に１２個の高解像度サブピクチャが表示され、右側に低解像度の全方位ビデオの残りの１２個のサブピクチャが表示される、図４に示すような最適化を可能にする。
【0080】
図５は、一般的なサブピクチャベースのビューポート依存３６０度ビデオ配信スキームの概略図５００を示す。別の一般的なサブピクチャベースのビューポート依存３６０度ビデオ配信スキームを図５に示すが、ここで、フルビデオの高解像度表現のみがサブピクチャで構成され、フルビデオの低解像度表現はサブピクチャを使用せず、高解像度表現よりも少ない頻度のＲＡＰで符号化できる。クライアントは、低解像度のフルビデオを受信するが、高解像度のビデオの場合、クライアントは、現在ビューポートをカバーするサブピクチャのみを受信して復号する。
【0081】
２．４．２ サブピクチャとMCTSの違い
サブピクチャとMCTSとの間には、いくつかの重要な設計上の違いがある。第一に、VVCでのサブピクチャ特徴により、この場合、ピクチャ境界と同様に、サブピクチャ境界にサンプルパディングを適用することで、サブピクチャが抽出可能である場合でも、符号化ブロックの動きベクトルがサブピクチャの外側を指すことを可能にする。第二に、マージモード及びVVCのデコーダ側動きベクトルリファインメントプロセスでの動きベクトルの選択と導出に、追加の変更が導入された。これにより、MCTSのエンコーダ側で適用される非規範的な動き制約と比較して、より高い符号化効率が可能になる。第三に、ピクチャのシーケンスから１つ又は複数の抽出可能なサブピクチャを抽出して、適合するビットストリームであるサブビットストリームを作成するときに、SH(及び、存在する場合は、PH NALユニット)の書き換えは必要ない。HEVC MCTSに基づくサブビットストリーム抽出では、SHの書き換えが必要である。HEVC MCTS抽出及びVVCサブピクチャ抽出の両方ともに、SPS、PPSの書き換えが必要となることに留意すべきである。ただし、通常、ビットストリームには少数のセットのパラメータしかなく、各ピクチャには少なくとも１つのスライスがあるため、SHの書き換えは、アプリケーションシステムにとって大きな負担となり得る。第四に、ピクチャ内の異なるサブピクチャのスライスは、異なるNALユニットタイプを持つことが許される。これは、ピクチャ内の混合NALユニットタイプ又は混合サブピクチャタイプと呼ばれることが多い特徴であるが、以下で、詳しく説明される。第五に、VVCは、サブピクチャシーケンスのHRD及びレベル定義を指定するため、抽出可能な各サブピクチャシーケンスのサブビットストリームの適合性をエンコーダによって保証できる。
サブピクチャとMCTSとの間には、いくつかの重要な設計上の違いがある。第一に、VVCでのサブピクチャ特徴により、この場合、ピクチャ境界と同様に、サブピクチャ境界にサンプルパディングを適用することで、サブピクチャが抽出可能である場合でも、符号化ブロックの動きベクトルがサブピクチャの外側を指すことを可能にする。第二に、マージモード及びVVCのデコーダ側動きベクトルリファインメントプロセスでの動きベクトルの選択と導出に、追加の変更が導入された。これにより、MCTSのエンコーダ側で適用される非規範的な動き制約と比較して、より高い符号化効率が可能になる。第三に、ピクチャのシーケンスから１つ又は複数の抽出可能なサブピクチャを抽出して、適合するビットストリームであるサブビットストリームを作成するときに、SH(及び、存在する場合は、PH NALユニット)の書き換えは必要ない。HEVC MCTSに基づくサブビットストリーム抽出では、SHの書き換えが必要である。HEVC MCTS抽出及びVVCサブピクチャ抽出の両方ともに、SPS、PPSの書き換えが必要となることに留意すべきである。ただし、通常、ビットストリームには少数のセットのパラメータしかなく、各ピクチャには少なくとも１つのスライスがあるため、SHの書き換えは、アプリケーションシステムにとって大きな負担となり得る。第四に、ピクチャ内の異なるサブピクチャのスライスは、異なるNALユニットタイプを持つことが許される。これは、ピクチャ内の混合NALユニットタイプ又は混合サブピクチャタイプと呼ばれることが多い特徴であるが、以下で、詳しく説明される。第五に、VVCは、サブピクチャシーケンスのHRD及びレベル定義を指定するため、抽出可能な各サブピクチャシーケンスのサブビットストリームの適合性をエンコーダによって保証できる。
【0082】
２．４．３ ピクチャ内の混合サブピクチャタイプ
AVC及びHEVCでは、ピクチャ内のすべてのVCL NALユニットが同じNALユニットタイプを持つ必要がある。VVCは、サブピクチャをピクチャ内で特定の異なるVCL NALユニットタイプと混合するオプションを導入し、したがって、ピクチャレベルだけでなく、サブピクチャレベルでもランダムアクセスに対するサポートを提供する。VVC VCLでは、サブピクチャ内のNALユニットは、依然として同じNALユニットタイプを持つ必要がある。
AVC及びHEVCでは、ピクチャ内のすべてのVCL NALユニットが同じNALユニットタイプを持つ必要がある。VVCは、サブピクチャをピクチャ内で特定の異なるVCL NALユニットタイプと混合するオプションを導入し、したがって、ピクチャレベルだけでなく、サブピクチャレベルでもランダムアクセスに対するサポートを提供する。VVC VCLでは、サブピクチャ内のNALユニットは、依然として同じNALユニットタイプを持つ必要がある。
【0083】
IRAPサブピクチャからのランダムアクセス能力は、３６０度ビデオアプリケーションにとって有益である。図５に示したものと同様のビューポート依存３６０度ビデオ配信スキームでは、空間的に隣接するビューポートのコンテンツが大きく重なり、即ち、ビューポートの向きの変更中に、ビューポート内のサブピクチャの一部のみが新しいサブピクチャに置き換えられるが、ほとんどのサブピクチャは、ビューポートに残る。ビューポートに新たに導入されるサブピクチャシーケンスは、IRAPスライスで開始すべきであるが、残りのサブピクチャがビューポート変更時にインター予測を実行することが許されると、全体の伝送ビットレートを大幅に低減できる。
【0084】
ピクチャに単一タイプのNALユニットだけが含まれるか、複数のタイプのNALユニットが含まれるかの指示は、ピクチャによって参照されるPPSで提供される(即ち、pps_mixed_nalu_types_in_pic_flagと呼ばれるフラグを使用する)。ピクチャは、IRAPスライスを含むサブピクチャ、及び、トレーリングスライスを同時に含むサブピクチャで構成され得る。NALユニットタイプRASL及びRADLのリーディングピクチャスライスを含む、ピクチャ内の異なるNALユニットタイプの他のいくつかの組み合わせも許可され、これにより、異なるビットストリームから抽出されたオープンGOP及びクローズGOP符号化構造を持つサブピクチャシーケンスを、１つのビットストリームにマージすることを可能にする。
【0085】
２．４．４ サブピクチャのレイアウト及びＩＤシグナリング
VVCのサブピクチャのレイアウトは、SPSでシグナリングされ、したがって、CLVS内で一定になる。各サブピクチャは、左上のCTUの位置及びCTUの数で表した幅と高さによってシグナリングされるため、サブピクチャがCTU粒度でピクチャの長方形領域をカバーすることが保証される。SPSでサブピクチャが信号でシグナリングされる順序によって、ピクチャ内の各サブピクチャのインデックスが決まる。
VVCのサブピクチャのレイアウトは、SPSでシグナリングされ、したがって、CLVS内で一定になる。各サブピクチャは、左上のCTUの位置及びCTUの数で表した幅と高さによってシグナリングされるため、サブピクチャがCTU粒度でピクチャの長方形領域をカバーすることが保証される。SPSでサブピクチャが信号でシグナリングされる順序によって、ピクチャ内の各サブピクチャのインデックスが決まる。
【0086】
SHやPHを書き換えることなく、サブピクチャシーケンスの抽出及びマージを可能にするために、VVCのスライスアドレッシングスキームは、サブピクチャID及びサブピクチャ特有のスライスインデックスに基づいて、スライスをサブピクチャに関連付ける。SHでは、スライスを含むサブピクチャのサブピクチャID及びサブピクチャレベルのスライスインデックスがシグナリングされる。特定のサブピクチャのサブピクチャIDの値は、そのサブピクチャインデックスの値とは異なり得ることに留意すべきである。２つの間のマッピングは、SPS又はPPSでシグナリングされるか(両方ではない)、或いは、暗黙的に推論される。存在する場合、サブピクチャサブビットストリーム抽出プロセス中にSPS及びPPSを書き換えるときに、サブピクチャIDマッピングを書き換えるか、追加する必要がある。サブピクチャID及びサブピクチャレベルのスライスインデックスは、一緒に、復号されたピクチャのDPBスロット内のスライスの最初に復号されたCTUの正確な位置をデコーダに示す。サブビットストリーム抽出後、サブピクチャのサブピクチャIDは変更されないが、サブピクチャインデックスは変更され得る。サブピクチャ内のスライス内の最初のCTUのラスタースキャンCTUアドレスが元のビットストリーム内の値と比較して変更された場合でも、それぞれのSH内のサブピクチャID及びサブピクチャレベルのスライスインデックスの変更されていない値により、依然として、抽出されたサブビットストリームの復号化ピクチャ内の各CTUの位置が正確に決まる。図６は、２つのサブピクチャ及び４つのスライスを含む例で、サブピクチャ抽出を可能にするためのサブピクチャID、サブピクチャインデックス、及びサブピクチャレベルスライスインデックスの使用の概略図６００を示す。
【0087】
サブピクチャ抽出と同様に、サブピクチャのシグナリングにより、異なるビットストリームが協調的に生成されるという条件で(例えば、別個のサブピクチャIDを使用するが、そうでない場合は、CTUサイズ、クロマフォーマット、符号化ツールなど、ほとんど整列したSPS、PPS、及びPHパラメータ)、SPSとPPSを書き換えるだけで、異なるビットストリームからのいくつかのサブピクチャを単一ビットストリームにマージすることが可能になる。
【0088】
サブピクチャ及びスライスは、それぞれ、SPS及びPPSで独立してシグナリングされるが、適合したビットストリームを形成するために、サブピクチャとスライスのレイアウト間には固有の相互制約がある。第一に、サブピクチャの存在は、長方形のスライスの使用を必要とし、ラスタースキャンスライスが禁止される。第二に、与えられたサブピクチャのスライスは、復号順序で連続したNALユニットであるべきであるが、これは、サブピクチャレイアウトがビットストリーム内の符号化されたスライスNALユニットの順序を制約することを意味する。
【0089】
２．５ ピクチャ・イン・ピクチャサービス
ピクチャ・イン・ピクチャサービスは、より大きな解像度の画像内に小さな解像度の画像を含める能力を提供する。このようなサービスは、ユーザに２つのビデオを同時に表示するのに有益であり得る。それによって、解像度の高いビデオがメインビデオとみなされ、解像度の低いビデオが補助ビデオとみなされる。このようなピクチャ・イン・ピクチャサービスは、メインビデオがサイネージビデオによって補助されるアクセシビリティサービスを提供するために使用できる。
ピクチャ・イン・ピクチャサービスは、より大きな解像度の画像内に小さな解像度の画像を含める能力を提供する。このようなサービスは、ユーザに２つのビデオを同時に表示するのに有益であり得る。それによって、解像度の高いビデオがメインビデオとみなされ、解像度の低いビデオが補助ビデオとみなされる。このようなピクチャ・イン・ピクチャサービスは、メインビデオがサイネージビデオによって補助されるアクセシビリティサービスを提供するために使用できる。
【0090】
VVCサブピクチャは、VVCサブピクチャの抽出及び結合プロパティの両方を使用することにより、ピクチャ・イン・ピクチャサービスに使用できる。このようなサービスの場合、メインビデオは、多数のサブピクチャを使用して符号化され、そのうちの１つは補助ビデオと同じサイズで、補助ビデオがメインビデオに合成されて独立して符号化されようとする正確な位置に位置して、抽出を可能にする。図７は、２つのサブピクチャ及び４つのスライスを含むビットストリームからの１つのサブピクチャの抽出の概略図７００を示す。図７に示すように、ユーザが補助ビデオを含むバージョンのサービスの視聴を選択する場合、メインビデオのピクチャ・イン・ピクチャ領域に対応するサブピクチャがメインビデオビットストリームから抽出され、補助ビデオビットストリームは、その場所でメインビデオビットストリームとマージされる。
【0091】
この場合、メイン及び補助ビデオのピクチャは、同じビデオ特性を共有しなければならず、特に、ビット深度、サンプルのアスペクト比、サイズ、フレームレート、色空間と転送特性、クロマサンプル位置が同じでなければならない。メイン及び補助ビデオビットストリームでは、各ピクチャ内でNALユニットタイプを使用する必要はない。ただし、マージには、メイン及び補助ビットストリームのピクチャの符号化順序が同じである必要がある。
【0092】
ここでは、サブピクチャのマージが必要であるため、メインビデオ及び補助ビデオ内で使用されるサブピクチャIDが重複することはできない。補助ビデオビットストリームが、追加のタイルやスライス分割を行わずに１つのサブピクチャのみで構成されている場合でも、補助ビデオビットストリームとメインビデオビットストリームのマージを可能にするように、サブピクチャ情報、特に、サブピクチャID及びサブピクチャID長をシグナリングする必要がある。補助ビデオビットストリームのスライスNALユニット内のサブピクチャIDシンタックス要素の長さをシグナリングするために使用されるサブピクチャIDの長さは、メインビデオビットストリームのスライスNALユニット内のサブピクチャIDをシグナリングするために使用されるサブピクチャIDの長さと同じでなければならない。さらに、PPS分割情報を書き換えることなく、補助ビデオビットストリームとメインビデオビットストリームのマージを簡略化するために、補助ビデオの符号化とメインビデオの対応する領域内で１つのスライス及び１つのタイルのみを使用することが有益であり得る。メイン及び補助ビデオビットストリームは、SPS、PPS及びピクチャヘッダで同じ符号化ツールをシグナリングしなければならない。これには、ブロック分割に同じ最大許容サイズと最小許容サイズ、及び、PPSでシグナリングされる初期量子化パラメータの同じ値(pps_init_qp_minus２６シンタックス要素の同じ値)を使用することが含まれる。符号化ツールの使用法は、スライスヘッダーレベルで修正できる。
【0093】
メイン及び補助ビットストリームの両方が、DASHベースの配信システム経由で利用可能である場合、DASH Preselections（プリセレクション）を使用して、マージして一緒にレンダリングされようとするメイン及び補助ビットストリームをシグナリングし得る。
【0094】
３．問題点
DASHでのピクチャ・イン・ピクチャサービスのサポートに関して、次の問題が観察されている。
DASHでのピクチャ・イン・ピクチャサービスのサポートに関して、次の問題が観察されている。
【0095】
１）ピクチャ・イン・ピクチャエクスペリエンスのためのDASH Preselectionsを使用することは可能であるが、そのような目的の指示が足りない。
【0096】
２）例えば、上述したように、ピクチャ・イン・ピクチャエクスペリエンスのためにVVCサブピクチャを使用することは可能であるが、メインビデオ内のターゲットピクチャ・イン・ピクチャ領域を表す符号化ビデオデータユニットを、補助ビデオの対応するビデオデータユニットに置き換えることができずに、他のコーデック及び方法を使用することも可能である。したがって、そのような置き換えが可能かどうかを示す必要がある。
【0097】
３）上記の置き換えが可能な場合、クライアントは、置き換えを実行できるように、メインビデオの各ピクチャ内のどの符号化ビデオデータユニットがターゲットピクチャ・イン・ピクチャ領域を表すかを知る必要がある。したがって、この情報をシグナリングする必要がある。
【0098】
４）コンテンツ選択の目的、及び、場合によっては他の目的でも、メインビデオ内のターゲットピクチャ・イン・ピクチャ領域の位置及びサイズをシグナリングすると有用である。
【0099】
４．本開示の実施形態
上記問題を解決するために、以下のように要約された方法を開示する。実施形態は、一般的な概念を説明するための例として考慮されるべきであり、狭く解釈されるべきではない。さらに、これらの実施形態は、個別に適用することも、任意の方法で組み合わせて適用することもできる。
上記問題を解決するために、以下のように要約された方法を開示する。実施形態は、一般的な概念を説明するための例として考慮されるべきであり、狭く解釈されるべきではない。さらに、これらの実施形態は、個別に適用することも、任意の方法で組み合わせて適用することもできる。
【0100】
１）１番目の問題を解決するために、例えば、ピクチャ・イン・ピクチャ記述子と名付けられた新しい記述子を定義され、プリセレクションにおけるこの記述子の存在は、プリセレクションの目的がピクチャ・イン・ピクチャエクスペリエンスを提供することであることを示す。
【0101】
ａ．一例では、この新しい記述子は、SupplementalProperty要素を拡張することによって補助記述子として定義される。
【0102】
ｂ．一例では、この新しい記述子は、「urn:mpeg:dash:pinp:2021」又は類似のURN文字列に等しい@schemeIdUri属性の値によって識別される。
【0103】
２）２番目の問題を解決するために、新しいピクチャ・イン・ピクチャ記述子において、メインビデオ内のターゲットピクチャ・イン・ピクチャ領域を表す符号化ビデオデータユニットを補助ビデオの対応するビデオデータユニットで置き換えることができるかどうかの指示をシグナリングする。
【0104】
ａ．一例では、この指示は、新しいピクチャ・イン・ピクチャ記述子の要素の、例えば、@dataUnitsReplacableという名前の属性によってシグナリングされる。
【0105】
３）３番目の問題を解決するために、新しいピクチャ・イン・ピクチャ記述子において、メインビデオの各ピクチャ内のどの符号化ビデオデータユニットがターゲットピクチャ・イン・ピクチャ領域を表すかを示す領域IDのリストがシグナリングされる。
【0106】
ａ．一例では、領域IDのリストは、例えば、@regionIdsという名前の、新しいピクチャ・イン・ピクチャ記述子の要素の属性としてシグナリングされる。
【0107】
４）４番目の問題を解決するために、新しいピクチャ・イン・ピクチャ記述子において、メインビデオよりもサイズが小さい補助ビデオをエンベッディング/オーバーレイするためのメインビデオ内の位置及びサイズに関する情報をシグナリングする。
【0108】
ａ．一例では、これは、４つの値(x、y、幅、高さ)のシグナリングによってシグナリングされ、x、yは、領域の左上隅の位置を指定し、幅と高さは、領域の幅と高さを指定する。単位は、輝度サンプル/ピクセルであり得る。
【0109】
ｂ．一例では、これは、新しいピクチャ・イン・ピクチャ記述子の要素の多数の属性によってシグナリングされる。
【0110】
５．実施形態
以下は、セクション４で上記に要約された本開示項目、及び、それらの下位項目のいくつかに関するいくつかの例示的な実施形態である。
以下は、セクション４で上記に要約された本開示項目、及び、それらの下位項目のいくつかに関するいくつかの例示的な実施形態である。
【0111】
５．１ 実施形態１
この実施形態は、セクション４で上記に要約されたすべての本開示項目及びその下位項目に関するものである。
この実施形態は、セクション４で上記に要約されたすべての本開示項目及びその下位項目に関するものである。
【0112】
５．１．１ DASHピクチャ・イン・ピクチャ記述子
@schemeIdUri属性が「urn:mpeg:dash:pinp:2021」に等しいSupplementalProperty要素は、ピクチャ・イン・ピクチャ記述子と呼ばれる。
@schemeIdUri属性が「urn:mpeg:dash:pinp:2021」に等しいSupplementalProperty要素は、ピクチャ・イン・ピクチャ記述子と呼ばれる。
【0113】
Preselection（プリセレクション）レベルに最大１つのピクチャ・イン・ピクチャ記述子が存在し得る。Preselection内のピクチャ・イン・ピクチャ記述子の存在は、Preselectionの目的がピクチャ・イン・ピクチャエクスペリエンスを提供することであることを示す。
【0114】
ピクチャ・イン・ピクチャサービスは、より大きな空間解像度のビデオ内に、より小さな空間解像度のビデオを含める能力を提供する。この場合、メインビデオの異なるビットストリーム/表現はPreselectionのMain Adaptation Set（主適応セット）に含まれ、補助ビデオの異なるビットストリーム/表現はPreselectionのPartial Adaptation Set（部分適応セット）に含まれる。
【0115】
ピクチャ・イン・ピクチャ記述子がプリセレクションに存在し、picInPicInfo@dataUnitsReplacable属性が存在し、かつ、trueに等しい場合、クライアントは、ビデオデコーダに送信する前に、メインビデオ内のターゲットピクチャ・イン・ピクチャ領域を表す符号化ビデオデータユニットを補助ビデオの対応する符号化ビデオデータユニットに置き換えることを選択し得る。このようにして、メインビデオと補助ビデオを別々に復号することを回避できる。メインビデオの特定のピクチャの場合、補助ビデオの対応するビデオデータユニットは、補助ビデオRepresentation（表現）の復号-時間-同期化-サンプルにおける、すべての符号化ビデオデータユニットである。
【0116】
VVCの場合、クライアントが、ビデオデコーダに送信する前に、メインビデオ内のターゲットピクチャ・イン・ピクチャ領域を表す符号化ビデオデータユニット(VCL NAL ユニットである)を補助ビデオの対応するVCL NALユニットに置き換えることを選択する場合、各サブピクチャIDごとに、メインビデオ内のVCL NALユニットは、対応するVCL NALユニットの順序を変更せずに、補助ビデオ内のそのサブピクチャIDを持つ、対応するVCL NALユニットに置き換えられる。
【0117】
ピクチャ・イン・ピクチャ記述子の@value属性は、存在しないべきである。ピクチャ・イン・ピクチャ記述子には、次の表に指定されている属性を持つpicInPicInfo要素が含まれる。
【0118】
【表1】
【0119】
５．３．１１．６．３ PicInpicInfo要素のXMLシンタックス
【表2】
【0120】
図８は、本開示のいくつかの実施形態によるビデオ処理のための方法８００のフローチャートを示す。方法８００は、第１のデバイスで実施され得る。例えば、方法８００は、クライアント又は受信機に埋め込まれ得る。本明細書で使用される「クライアント」という用語は、コンピュータネットワークのクライアントサーバモデルの一部としてサーバによって利用可能にされるサービスにアクセスするコンピューターハードウェア又はソフトウェアを指し得る。単なる例として、クライアントは、スマートフォン又はタブレットであり得る。いくつかの実施形態では、第１のデバイスは、図１に示される宛先デバイス１２０で実施され得る。
【0121】
ブロック８１０で、第１のデバイスは、第２のデバイスからメタデータファイルを受信する。前記メタデータファイルは、ビデオビットストリームに関する重要な情報、例えば、プロファイル、階層、レベルなどを含み得る。例えば、前記メタデータファイルは、コンテンツ選択の目的、例えば、ストリーミングセッションの開始時の初期化及びストリーミングセッション中のストリーム適応の両方について適切なメディアセグメントの選択のための、DASHメディアプレゼンテーション記述（MPD）であり得る。
【0122】
ブロック８２０で、第１のデバイスは、メタデータファイル内のデータ構造における記述子を決定する。前記述子の存在は、そのデータ構造がピクチャ・イン・ピクチャサービスを提供するためのものであることを示す。言い換えれば、データ構造が記述子を含む場合、そのデータ構造は、ピクチャ・イン・ピクチャサービスを提供するためのものであることを意味する。ピクチャ・イン・ピクチャサービスは、より大きな空間解像度のビデオ内に、より小さな空間解像度のビデオを含める能力を提供し得る。このようにして、ピクチャ・イン・ピクチャエクスペリエンスにDASH Preselectionを使用することを示すことができる。
【0123】
ブロック８２０で、第１のデバイスは、メタデータファイルからターゲットピクチャ・イン・ピクチャ領域を表す第１のビデオの各ピクチャ内の第１セットの符号化ビデオデータユニットを示すための領域識別子（ID）のリストを決定する。いくつかの実施形態では、領域IDのリストは、メタデータファイル内の記述子の要素の属性であり得る。例えば、前記属性は、regionIdsであり得る。いくつかの実施形態では、領域IDのリスト内の領域IDは、サブピクチャIDであり得る。ターゲットピクチャ・イン・ピクチャ領域は、第２のビデオ内の第２セットの符号化ビデオユニットによって置き換えられ得る。いくつかの実施形態では、第１セットの符号化ビデオデータユニットは、第１セットのビデオ符号化層ネットワーク抽象化層（VCL NAL）ユニットを含み、第２セットの符号化ビデオデータユニットは、第２セットのVCL
NALユニットを含み得る。このようにして、第１のデバイスは、第１のビデオの各ピクチャ内のどの符号化ビデオデータユニットがターゲットピクチャ・イン・ピクチャ領域を表すかを知り、置き換えを実行できる。
NALユニットを含み得る。このようにして、第１のデバイスは、第１のビデオの各ピクチャ内のどの符号化ビデオデータユニットがターゲットピクチャ・イン・ピクチャ領域を表すかを知り、置き換えを実行できる。
【0124】
いくつかの実施形態では、領域IDのリストにより、第１セットの符号化ビデオデータユニットを、第２セットの符号化ビデオユニットで置き換えることが可能になり得る。例えば、領域IDのリスト内の１つの領域IDについて、第１のデバイスは、第1のビデオ内の領域IDを有する第１セットの符号化ビデオデータユニットを、第２のビデオ内の領域IDを有する第２セットの符号化ビデオユニットに置き換えてもよい。図９Ａに示すように、第１のビデオは、サブピクチャ（subpic）ＩＤ００、０１、０２、０３を有するサブピクチャを含み得る。例えば、メタデータファイル内の領域IDのリストが、サブピクチャID００を含む場合、第１のビデオ９１０内のサブピクチャID００を有する符号化ビデオデータユニットのセットは、第２のビデオ９２０内のサブピクチャID００を有する第２の符号化ビデオユニットで置き換えられ得る。
【0125】
一例として、VVCの場合、第１のデバイスが、ビデオデコーダに送信する前に、メインビデオ内のターゲットピクチャ・イン・ピクチャ領域を表す符号化ビデオデータユニット（VCL NALユニットである）を補助ビデオの対応するVCL NALユニットに置き換えることを選択する場合、各サブピクチャIDごとに、メインビデオ内のVCL NALユニットは、対応するVCL NALユニットの順序を変更することなく、補助ビデオ内のそのサブピクチャIDを有する対応するVCL NALユニットで置き換えられ得る。例えば、以下の表２は、記述子におけるその属性を持つピクチャ・イン・ピクチャ要素の例を示している。表２は、単なる一例であり、限定ではないことに留意すべきである。
【0126】
【表3】
【0127】
いくつかの実施形態では、第１のデバイスは、メタデータファイルから、第１のビデオ内のターゲットピクチャ・イン・ピクチャ領域を表す第１セットの符号化ビデオデータユニットが、第２のビデオ内の第２セットの符号化ビデオデータユニットによって置き換え可能であるかどうかを示すための指示、を決定し得る。いくつかの実施形態では、指示は、メタデータファイル内の記述子（例えば、ピクチャ・イン・ピクチャ記述子）における要素の属性であり得る。例えば、属性は、dataUnitsReplacableであり得る。このようにして、メインビデオ及び補助ビデオの別々の復号を回避できる。また、メインビデオ及び補助ビデオを伝送するための伝送リソースも節約できる。
【0128】
いくつかの例では、指示により、第１セットの符号化ビデオデータユニットが第２セットの符号化ビデオデータユニットによって置き換えられることが、可能になる。例えば、前記指示が、第１のビデオ内のターゲットピクチャ・イン・ピクチャ領域を表す第１セットの符号化ビデオデータユニットが第２のビデオ内の第２セットの符号化ビデオデータユニットによって置き換え可能であることを示す場合、第１セットの符号化ビデオデータユニットは、第２セットの符号化ビデオデータユニットで置き換えられ得る。この場合、補助ビデオからの第２セットの符号化ビデオデータユニットを構成するメインビデオが、復号され得る。一例として、記述子（即ち、ピクチャ・イン・ピクチャ記述子）がPreselectionに存在し、picInPicInfo@dataUnitsReplacable属性が存在し、かつ、trueに等しい場合、第１のデバイスは、ビデオデコーダに送信する前に、メインビデオ内のターゲットピクチャ・イン・ピクチャ領域を表す符号化ビデオデータユニットを、補助ビデオの対応する符号化ビデオデータユニットに置き換えることを選択し得る。メインビデオ内の特定のピクチャについて、補助ビデオの対応するビデオデータユニットは、補助ビデオRepresentation（表現）における復号-時間-同期化サンプルにおける、すべての符号化ビデオデータユニットであり得る。例えば、以下の表３は、記述子におけるその属性を持つピクチャ・イン・ピクチャ要素の例を示している。表３は、単なる一例であり、限定ではないことに留意すべきである。
【0129】
【表4】
【0130】
いくつかの実施形態では、メタデータファイルは、記述子（即ち、ピクチャ・イン・ピクチャ記述子）を含み得る。この場合、記述子の存在は、そのデータ構造がピクチャ・イン・ピクチャサービスを提供するためのものであることを示す。言い換えれば、データ構造が記述子を含む場合、そのデータ構造は、ピクチャ・イン・ピクチャサービスを提供するためのものであることを意味する。ピクチャ・イン・ピクチャサービスは、より大きな空間解像度のビデオ内に、より小さな空間解像度のビデオを含める能力を提供し得る。このようにして、ピクチャ・イン・ピクチャエクスペリエンスにDASH Preselectionを使用することを示すことができる。
【0131】
データ構造は、ピクチャ・イン・ピクチャサービスのための、第１のビデオの第１セットのビットストリーム及び第２のビデオの第２セットのビットストリームの選択を示し得る。第１のビデオは「メインビデオ」とも呼ばれ、第２のビデオは「補助ビデオ」とも呼ばれ得る。ピクチャ・イン・ピクチャサービスは、より大きな空間解像度のビデオ(即ち、第１のビデオ又はメインビデオ)内に、より小さな空間解像度のビデオ(即ち、第２のビデオ又は補助ビデオ)を含める能力を提供し得る。いくつかの実施形態では、データ構造は、メタデータファイルのPreselectionであり得る。言い換えれば、記述子は、Preselectionレベルに存在し得る。プリセレクションは、同時に復号及びレンダリングされる１つ又は複数のオーディオ及び／又はビデオコンポーネントによって作成されるオーディオ及び／又はビデオエクスペリエンスを定義し得る。一例として、いくつかの実施形態では、最大１つの記述子がPreselectionレベルに存在し得る。いくつかの実施形態では、メタデータファイルは、１つ又は複数のPreselectionを含み得る。いくつかの実施形態では、データ構造の主適応は、第１のビデオの第１セットのビットストリームを含み、データ構造の部分適応セットは、補助ビデオの第２セットのビットストリームを含み得る。例えば、上で述べたように、ピクチャ・イン・ピクチャサービスは、より大きな空間解像度のビデオ(即ち、第１のビデオ/メインビデオ)内に、より小さな空間解像度のビデオ(即ち、第２のビデオ/補助ビデオ)を含める能力を提供し得る。この場合、第１のビデオの異なるビットストリーム/表現は、PreselectionのMain Adaptation Setに含まれ、第２のビデオの異なるビットストリーム/表現は、PreselectionのPartial Adaptation Setに含まれ得る。
【0132】
いくつかの実施形態では、記述子は、メタデータファイル内のSupplementalProperty要素に基づいて補助記述子として定義され得る。いくつかの実施形態では、記述子は、ユニフォームリソース名（URN）文字列に等しい属性の値によって識別され得る。例えば、属性はschemeIdUri属性である。いくつかの実施形態では、UR文字列は、「urn:mpeg:dash:pinp:2022」であり得る。UR文字列は、任意の適切な値であり得るが、例えば、UR文字列は、「urn:mpeg:dash:pinp:2021」又は「urn:mpeg:dash:pinp:2023」であり得る。一例として、「urn:mpeg:dash:pinp:2022」に等しい@schemeIdUri属性を持つSupplementalProperty要素は、記述子、即ちピクチャ・イン・ピクチャ記述子と呼ばれ得る。
【0133】
いくつかの実施形態では、記述子は、第２のビデオをエンベッディング又はオーバーレイするための第１のビデオ内の領域の位置情報及びサイズ情報を示し得る。この場合、領域のサイズは、第１のビデオよりも小さくてもよい。いくつかの実施形態では、領域は、輝度サンプル又は輝度ピクセルを含み得る。このようにして、前記領域の位置情報及びサイズ情報に基づいて、コンテンツを適切に選択できる。
【0134】
いくつかの実施形態では、位置情報は、領域の左上隅の水平位置及び領域の左上隅の垂直位置を示し得る。代替形態として、又は、それに加えて、サイズ情報は、領域の幅及び領域の高さを示し得る。一例では、これは、４つの値(x、y、幅、高さ)のシグナルによってシグナリングされ、x、yは領域の左上隅の位置を指定し、幅と高さは領域の幅と高さを指定する。例えば、図９Ｂに示すように、位置情報は、第１のビデオ９１０におけるピクチャ・イン・ピクチャ領域９０１の水平位置X及び垂直位置Yを示し得る。サイズ情報は、ピクチャ・イン・ピクチャ領域９０１の幅９０２及び高さ９０３も含み得る。
【0135】
いくつかの実施形態では、記述子における要素の一セットの属性は、領域の位置情報及びサイズ情報を示し得る。例えば、以下の表４は、記述子におけるその属性を持つピクチャ・イン・ピクチャ要素の例を示している。表４は単なる一例であり、限定ではないことに留意すべきである。
【0136】
【表5】
【0137】
図１０は、本開示のいくつかの実施形態によるビデオ処理のための方法１０００のフローチャートを示す。方法１０００は、第２のデバイスで実施され得る。例えば、方法１０００は、サーバ又は送信機に埋め込まれ得る。本明細書で使用される「サーバ」という用語は、コンピューティング可能なデバイスを指し得るが、その場合、クライアントは、ネットワーク経由でサービスにアクセスする。サーバは、物理コンピューティングデバイス又は仮想コンピューティングデバイスであり得る。いくつかの実施形態では、第２のデバイスは、図１に示されるソースデバイス１１０で実施され得る。
【0138】
ブロック１０１０で、第２のデバイスは、メタデータファイルを決定する。前記メタデータファイルは、ターゲットピクチャ・イン・ピクチャ領域を表す第１のビデオの各ピクチャ内の第１セットの符号化ビデオデータユニットを示すための領域識別子（ID）のリストを含む。前記ターゲットピクチャ・イン・ピクチャ領域は、第２のビデオ内の第２セットの符号化ビデオユニットによって置き換え可能である。
【0139】
いくつかの実施形態では、領域IDのリストは、メタデータファイル内の記述子における要素の属性であり得る。例えば、属性は、regionIdsであり得る。いくつかの実施形態では、領域IDのリスト内の領域IDは、サブピクチャIDであり得る。ターゲットピクチャ・イン・ピクチャ領域は、第２のビデオ内の第２セットの符号化ビデオユニットによって置き換え可能であり得る。いくつかの実施形態では、第１セットの符号化ビデオデータユニットは、第１セットのビデオ符号化層ネットワーク抽象化層（VCL NAL）ユニットを含み、第２セットの符号化ビデオデータユニットは、第２セットのVCL NALユニットを含み得る。
【0140】
ブロック１０２０で、第２のデバイスは、メタデータファイルを第１のデバイスに送信する。このようにして、第１のデバイスは、第１のビデオの各ピクチャ内のどの符号化ビデオデータユニットがターゲットピクチャ・イン・ピクチャ領域を表すかを知り、置き換えを実行できる。
【0141】
いくつかの実施形態では、メタデータファイルは、第１のビデオ内のターゲットピクチャ・イン・ピクチャ領域を表す第１セットの符号化ビデオデータユニットが、第２のビデオ内の第２セットの符号化ビデオデータユニットによって置き換え可能であるかどうかを示すための指示も含み、メタデータファイルから決定され得る。いくつかの実施形態では、指示は、メタデータファイル内の記述子（例えば、ピクチャ・イン・ピクチャ記述子）における要素の属性であり得る。例えば、属性は、dataUnitsReplacableであり得る。このようにして、メインビデオ及び補助ビデオの別々の復号を回避できる。また、メインビデオ及び補助ビデオを伝送するための伝送リソースも節約できる。
【0142】
いくつかの例では、指示が、第１のビデオ内のターゲットピクチャ・イン・ピクチャ領域を表す第１セットの符号化ビデオデータユニットが、第２のビデオ内の第２セットの符号化ビデオデータユニットによって置き換え可能であることを示す場合、第１セットの符号化ビデオデータユニットは、第２セットの符号化ビデオデータユニットで置き換えられ得る。この場合、補助ビデオからの第２セットの符号化ビデオデータユニットを構成するメインビデオが、復号され得る。一例として、記述子（即ち、ピクチャ・イン・ピクチャ記述子）がPreselectionに存在し、picInPicInfo@dataUnitsReplacable属性が存在し、かつ、trueに等しい場合、第１のデバイスは、ビデオデコーダに送信する前に、メインビデオ内のターゲットピクチャ・イン・ピクチャ領域を表す符号化ビデオデータユニットを、補助ビデオの対応する符号化ビデオデータユニットに置き換えることを選択し得る。メインビデオ内の特定のピクチャについて、補助ビデオの対応するビデオデータユニットは、補助ビデオRepresentation（表現）における復号-時間-同期化サンプルにおける、すべての符号化ビデオデータユニットであり得る。
【0143】
前記メタデータファイルは、ビデオビットストリームに関する重要な情報、例えば、プロファイル、階層、レベルなど、を含み得る。例えば、前記メタデータファイルは、コンテンツ選択の目的、例えば、ストリーミングセッションの開始時の初期化及びストリーミングセッション中のストリーム適応の両方について適切なメディアセグメントの選択のための、DASHメディアプレゼンテーション記述（MPD）であり得る。
【0144】
いくつかの実施形態では、メタデータファイルは、記述子、例えばピクチャ・イン・ピクチャ記述子を含み得る。この場合、記述子の存在は、そのデータ構造がピクチャ・イン・ピクチャサービスを提供するためのものであることを示す。言い換えれば、データ構造が記述子を含む場合、そのデータ構造は、ピクチャ・イン・ピクチャサービスを提供するためのものであることを意味する。ピクチャ・イン・ピクチャサービスは、より大きな空間解像度のビデオ内に、より小さな空間解像度のビデオを含める能力を提供し得る。
【0145】
いくつかの実施形態では、記述子は、メタデータファイル内のSupplementalProperty要素に基づいて、補助記述子として定義され得る。いくつかの実施形態では、記述子は、ユニフォームリソース名（URN）文字列に等しい属性の値によって、識別され得る。例えば、属性は、schemeIdUri属性である。いくつかの例示的な実施形態では、UR文字列は、「urn:mpeg:dash:pinp:2022」であり得る。UR文字列は、任意の適切な値であり得るが、例えば、UR文字列は、「urn:mpeg:dash:pinp:2021」又は「urn:mpeg:dash:pinp:2023」であり得る。一例として、「urn:mpeg:dash:pinp:2022」に等しい@schemeIdUri属性を持つSupplementalProperty要素は、記述子、即ち、ピクチャ・イン・ピクチャ記述子と呼ばれ得る。
【0146】
いくつかの実施形態では、データ構造は、ピクチャ・イン・ピクチャサービスのための、第１のビデオの第１セットのビットストリーム及び第２のビデオの第２セットのビットストリームの選択を示し得る。いくつかの実施形態では、データ構造はメタデータファイルのPreselectionであり得る。言い換えれば、記述子はPreselectionレベルに存在し得る。プリセレクションは、同時に復号及びレンダリングされる１つ又は複数のオーディオ及び／又はビデオコンポーネントによって作成されるオーディオ及び／又はビデオエクスペリエンスを定義し得る。一例として、いくつかの実施形態では、最大１つの記述子がPreselectionレベルに存在し得る。いくつかの実施形態では、メタデータファイルは、１つ又は複数のPreselectionを含み得る。
【0147】
いくつかの実施形態では、データ構造の主適応は、第１のビデオの第１セットのビットストリームを含み、データ構造の部分適応セットは、第２のビデオの第２セットのビットストリームを含み得る。例えば、上で述べたように、ピクチャ・イン・ピクチャサービスは、より大きな空間解像度のビデオ(即ち、第１のビデオ又はメインビデオ）内に、より小さな空間解像度のビデオ(即ち、第２のビデオ又は補助ビデオ)を含める能力を提供し得る。この場合、第１のビデオの異なるビットストリーム／表現は、PreselectionのMain Adaptation Setに含まれ、第２のビデオの異なるビットストリーム／表現は、PreselectionのPartial Adaptation Setに含まれ得る。
【0148】
いくつかの実施形態では、記述子は、第２のビデオをエンベッディング又はオーバーレイするための第１のビデオ内の領域の位置情報及びサイズ情報を示し得る。この場合、領域のサイズは、第１のビデオよりも小さくてもよい。いくつかの実施形態では、領域は、輝度サンプル又は輝度ピクセルを含み得る。このようにして、領域の位置情報及びサイズ情報に基づいて、コンテンツを適切に選択できる。
【0149】
いくつかの実施形態では、位置情報は、領域の左上隅の水平位置及び領域の左上隅の垂直位置を示し得る。代替形態として、又は、それに加えて、サイズ情報は、領域の幅及び領域の高さを示し得る。一例では、これは、４つの値(x、y、幅、高さ)のシグナルによってシグナリングされ、x、yは領域の左上隅の位置を指定し、幅と高さは領域の幅と高さを指定する。いくつかの実施形態では、記述子における要素の一セットの属性は、領域の位置情報及びサイズ情報を示し得る。
【0150】
本開示の実施形態は、個別に実施されることができる。代替形態として、本開示の実施形態は、任意の適切な組み合わせで実施されることができる。本開示の実施は、以下の条項を考慮して説明することができ、その特徴は任意の合理的な方式で組み合わせることができる。
【0151】
条項１．ビデオ処理方法であって、第１のデバイスによって、サーバからメタデータファイルを受信するステップと、前記メタデータファイルから、第２のビデオ内の第２セットの符号化ビデオユニットによって置き換え可能なターゲットピクチャ・イン・ピクチャ領域を表す、第１のビデオの各ピクチャ内の第１セットの符号化ビデオデータユニットを示すための領域識別子（ID）のリスト、を決定するステップと、を含む方法。
【0152】
条項２.前記領域IDのリストは、前記メタデータファイル内の記述子の要素の属性である、条項１に記載の方法。
【0153】
条項３．前記属性は、regionIdsである、条項２に記載の方法。
【0154】
条項４．前記領域IDのリスト内の１つの領域IDは、前記第１のビデオを復号する前に、前記第１のビデオ内の領域IDを有する前記第１セットの符号化ビデオデータユニットを、前記第２のビデオ内の領域IDを有する前記第２セットの符号化ビデオユニットに置き換えることを可能にする、条項１から３のいずれか一項に記載の方法。
【0155】
条項５．前記領域IDのリスト内の領域IDは、サブピクチャIDであり、前記第１セットの符号化ビデオデータユニットは、第１セットのビデオ符号化層ネットワーク抽象化層（VCL NAL）ユニットを含み、前記第２セットの符号化ビデオデータユニットは、第２セットのVCL NALユニットを含む、条項１から４のいずれか一項に記載の方法。
【0156】
条項６．ビデオ処理方法であって、第２のデバイスによって、メタデータファイルを決定するステップであり、前記メタデータファイルは、第２のビデオ内の第２セットの符号化ビデオユニットによって置き換え可能なターゲットピクチャ・イン・ピクチャ領域を表す、メインビデオの各ピクチャ内の第１セットの符号化ビデオデータユニットを示すための領域識別子（ID）のリスト、を含むステップと、前記メタデータファイルを、第１のデバイスに送信するステップと、を含む方法。
【0157】
条項７．前記領域IDのリストは、前記メタデータファイル内の記述子の要素の属性である、条項６に記載の方法。
【0158】
条項８．前記属性は、regionIdsである、条項７に記載の方法。
【0159】
条項９．前記領域IDのリスト内の１つの領域IDは、前記第１のビデオを復号する前に、前記第１のビデオ内の領域IDを有する前記第１セットの符号化ビデオデータユニットを、前記第２のビデオ内の領域IDを有する前記第２セットの符号化ビデオユニットに置き換えることを可能にする、条項６から８のいずれか一項に記載の方法。
【0160】
条項１０．前記領域IDのリスト内の領域IDは、サブピクチャIDであり、前記第１セットの符号化ビデオデータユニットは、第１セットのビデオ符号化層ネットワーク抽象化層（VCL NAL）ユニットを含み、前記第２セットの符号化ビデオデータユニットは、第２セットのVCL NALユニットを含む、条項６から９のいずれか一項に記載の方法。
【0161】
条項１１．プロセッサと、命令を備えた非一時的メモリとを含むビデオデータを処理する装置であって、前記命令は前記プロセッサによって実行されると、前記プロセッサに条項１から１０のいずれか一項に記載の方法を実行させる装置。
【0162】
条項１２．プロセッサに条項１から１０のいずれか一項に記載の方法を実行させる命令を記憶する、非一時的なコンピュータ可読記憶媒体。
【0163】
例示的なデバイス
図１１は、本開示の様々な実施形態を実施できるコンピューティングデバイス１１００のブロック図を示す。コンピューティングデバイス１１００は、ソースデバイス１１０（或いは、ビデオエンコーダ１１４又は２００）又は宛先デバイス１２０（或いは、ビデオデコーダ１２４又は３００）として実施されるか、又は、それに含まれ得る。
図１１は、本開示の様々な実施形態を実施できるコンピューティングデバイス１１００のブロック図を示す。コンピューティングデバイス１１００は、ソースデバイス１１０（或いは、ビデオエンコーダ１１４又は２００）又は宛先デバイス１２０（或いは、ビデオデコーダ１２４又は３００）として実施されるか、又は、それに含まれ得る。
【0164】
図１１に示されるコンピューティングデバイス１１００は、単に説明を目的としたものであり、本開示の実施形態の機能及び範囲をいかなる形でも制限することを示唆するものではないことが理解されるだろう。
【0165】
図１１に示すように、コンピューティングデバイス１１００は、汎用コンピューティングデバイス１１００を含む。コンピューティングデバイス１１００は、少なくとも１つ又は複数のプロセッサ又は処理ユニット１１１０と、メモリ１１２０と、記憶ユニット１１３０と、１つ又は複数の通信ユニット１１４０と、１つ又は複数の入力デバイス１１５０と、１つ又は複数の出力デバイス１１６０と、を含み得る。
【0166】
いくつかの実施形態では、コンピューティングデバイス１１００は、コンピューティング能力を有する任意のユーザ端末又はサーバ端末として実施され得る。前記サーバ端末は、サービスプロバイダが提供するサーバや大規模コンピューティングデバイスなどであり得る。前記ユーザ端末は、例えば、携帯電話、ステーション、ユニット、デバイス、マルチメディアコンピュータ、マルチメディアタブレット、インターネットノード、コミュニケータ、デスクトップコンピュータ、ラップトップコンピュータ、ノートブックコンピュータ、ネットブックコンピュータ、タブレットコンピュータ、パーソナルコミュニケーションシステム(PCS)デバイス、パーソナルナビゲーションデバイス、携帯情報端末(PDA)、オーディオ/ビデオプレーヤー、デジタルカメラ/ビデオカメラ、測位デバイス、テレビ受信機、ラジオ放送受信機、電子ブックデバイス、ゲームデバイス、又は、それらの任意の組み合わせ（これらのデバイスのアクセサリ及び周辺機器、又は、それらの任意の組み合わせを含む）を含む、任意のタイプの移動端末、固定端末、又は、携帯端末であり得る。コンピューティングデバイス１１００は、ユーザに対する任意のタイプのインターフェース（「ウェアラブル」回路など）をサポートできることが考えられる。
【0167】
処理ユニット１１１０は、物理又は仮想プロセッサであり、メモリ１１２０に格納されたプログラムに基づいて様々なプロセスを実施し得る。マルチプロセッサシステムでは、コンピューティングデバイス１１００の並列処理能力を向上させるために、複数の処理ユニットが、コンピュータ実行可能命令を並列に実行する。処理ユニット１１１０は、中央処理ユニット（CPU）、マイクロプロセッサ、コントローラ、又はマイクロコントローラと呼ばれ得る。
【0168】
コンピューティングデバイス１１００は、通常、様々なコンピュータ記憶媒体を含む。このような媒体は、揮発性及び不揮発性媒体、又は、取り外し可能及び取り外し不可能な媒体を含むが、これらに限定されない、コンピューティングデバイス１１００によってアクセス可能な任意の媒体であり得る。メモリ１１２０は、揮発性メモリ（例えば、レジスタ、キャッシュ、ランダムアクセスメモリ（RAM））、不揮発性メモリ（例えば、読み取り専用メモリ（ROM）、電気的に消去可能なプログラム可能な読み取り専用メモリ（EEPROM）、フラッシュ メモリ）、又は、それらの任意の組み合わせであり得る。記憶ユニット１１３０は、任意の取り外し可能又は取り外し不可能な媒体であり、情報及び／又はデータを記憶するために使用でき、コンピューティングデバイス１１００でアクセスできる、メモリ、フラッシュメモリドライブ、磁気ディスク、又は別の他の媒体などの機械可読媒体を含み得る。
【0169】
コンピューティングデバイス１１００は、追加の取り外し可能／取り外し不可能、揮発性／不揮発性メモリ媒体をさらに含み得る。なお、図１１には示していないが、着脱可能な不揮発性磁気ディスクの読み書きを行う磁気ディスクドライブや、着脱可能な不揮発性光ディスクの読み書きを行う光ディスクドライブを提供することが可能である。このような場合、各ドライブは、１つ又は複数のデータ媒体インターフェースを介して、バス(図示せず)に接続され得る。
【0170】
通信ユニット１１４０は、通信媒体を介して、さらなるコンピューティングデバイスと通信する。さらに、コンピューティングデバイス１１００内のコンポーネントの機能は、通信接続を介して通信できる単一のコンピューティングクラスタ又は複数のコンピューティングマシンによって実施することができる。したがって、コンピューティングデバイス１１００は、１つ又は複数の他のサーバ、ネットワーク化されたパーソナルコンピュータ（PC）、又は、さらなる一般的なネットワークノードとの論理接続を使用して、ネットワーク化された環境で動作することができる。
【0171】
入力デバイス１１５０は、マウス、キーボード、トラッキングボール、音声入力デバイスなどの様々な入力デバイスのうちの１つ又は複数であり得る。出力デバイス１１６０は、ディスプレイ、スピーカ、プリンタなどの様々な出力デバイスのうちの１つ又は複数であり得る。通信ユニット１１４０によって、コンピューティングデバイス１１００は、記憶デバイス及び表示デバイスなどの１つ又は複数の外部デバイス（図示せず）とさらに通信することができ、１つ又は複数のデバイスにより、ユーザがコンピューティングデバイス１１００と対話可能にするか、又は、必要に応じて、任意のデバイス（ネットワークカード、モデムなど）により、コンピューティングデバイス１１００が１つ又は複数の他のコンピューティングデバイスと通信可能にする。このような通信は、入出力(I/O)インターフェース(図示せず)を介して、実行できる。
【0172】
いくつかの実施形態では、単一のデバイスに統合される代わりに、コンピューティングデバイス１１００のいくつかの又はすべてのコンポーネントが、クラウドコンピューティングアーキテクチャに配置され得る。クラウドコンピューティングアーキテクチャでは、コンポーネントは遠隔的に提供され、連携して本開示で説明される機能を実施し得る。いくつかの実施形態では、クラウドコンピューティングは、コンピューティング、ソフトウェア、データアクセス及びストレージサービスを提供し、これらのサービスを提供するシステム又はハードウェアの物理的な位置又は構成をエンドユーザが認識する必要はない。様々な実施形態において、クラウドコンピューティングは、適切なプロトコルを使用して、広域ネットワーク（インターネットなど）を介して、サービスを提供する。例えば、クラウドコンピューティングプロバイダーは、Webブラウザ又はその他のコンピューティングコンポーネントを通じてアクセスできる、広域ネットワーク経由でアプリケーションを提供する。クラウドコンピューティングアーキテクチャのソフトウェア又はコンポーネント及び対応するデータは、遠隔地にあるサーバに保存され得る。クラウドコンピューティング環境におけるコンピューティングリソースは、リモートデータセンターの場所に併合又は分散され得る。クラウドコンピューティングインフラストラクチャは、ユーザにとって単一のアクセスポイントとして動作するが、共有データセンターを通じて、サービスを提供し得る。したがって、クラウドコンピューティングアーキテクチャを使用して、本明細書で説明されるコンポーネント及び機能を、遠隔地にあるサービスプロバイダから提供し得る。代替形態として、それらは、従来のサーバから提供されるか、又は、クライアントデバイスに直接又はその他の方法でインストールされ得る。
【0173】
コンピューティングデバイス１１００は、本開示の実施形態において、ビデオ符号化／復号化を実施するために使用され得る。メモリ１１２０は、１つ又は複数のプログラム命令を有する１つ又は複数のビデオ符号化モジュール１１２５を含み得る。これらのモジュールは、本明細書で説明される様々な実施形態の機能を実行するように、処理ユニット１１１０によって、アクセス可能かつ実行可能である。
【0174】
ビデオ符号化を実行する例示的な実施形態では、入力デバイス１１５０は、符号化されるビデオデータを、入力１１７０として受信し得る。ビデオデータは、例えば、ビデオ符号化モジュール１１２５によって処理されて、符号化されたビットストリームを生成し得る。符号化されたビットストリームは、出力デバイス１１６０を介して、出力１１８０として提供され得る。
【0175】
ビデオ復号を実行する例示的な実施形態では、入力デバイス１１５０は、符号化されたビットストリームを、入力１１７０として受信し得る。符号化されたビットストリームは、例えば、ビデオ符号化モジュール１１２５によって処理されて、復号されたビデオデータを生成し得る。復号されたビデオデータは、出力デバイス１１６０を介して、出力１１８０として提供され得る。
【0176】
本開示は、その好ましい実施形態を参照して、特に、図示及び説明されたが、添付の特許請求の範囲によって定義される本出願の精神及び範囲から逸脱することなく、形態及び詳細における様々な変更を行うことができることが当業者には理解されるであろう。このような変形は、本出願の範囲に含まれるものとする。したがって、本出願の実施形態に関する前述の説明は、限定することを意図したものではない。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9A】
【図9B】
【図10】
【図11】
【手続補正書】
【提出日】2024-03-29
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
ビデオ処理方法であって、第１のデバイスによって、サーバからメタデータファイルを受信するステップと、
前記メタデータファイルから、第２のビデオ内の第２セットの符号化ビデオユニットによって置き換え可能なターゲットピクチャ・イン・ピクチャ領域を表す、第１のビデオの各ピクチャ内の第１セットの符号化ビデオデータユニットを示すための領域識別子（ID）のリスト、を決定するステップと、
を含む、方法。
【請求項2】
前記領域IDのリストは、前記メタデータファイル内の記述子の要素の属性である、請求項１に記載の方法。
【請求項3】
前記属性は、regionIdsである、請求項２に記載の方法。
【請求項4】
前記領域IDのリスト内の１つの領域IDは、前記第１のビデオを復号する前に、前記第１のビデオ内の領域IDを有する前記第１セットの符号化ビデオデータユニットを、前記第２のビデオ内の領域IDを有する前記第２セットの符号化ビデオユニットに置き換えることを可能にする、請求項１に記載の方法。
【請求項5】
前記領域IDのリスト内の領域IDは、サブピクチャIDであり、前記第１セットの符号化ビデオデータユニットは、第１セットのビデオ符号化層ネットワーク抽象化層（VCL NAL）ユニットを含み、
前記第２セットの符号化ビデオデータユニットは、第２セットのVCL NALユニットを含む、
請求項１に記載の方法。
【請求項6】
ビデオ処理方法であって、第２のデバイスによって、メタデータファイルを決定するステップであり、
前記メタデータファイルは、第２のビデオ内の第２セットの符号化ビデオユニットによって置き換え可能なターゲットピクチャ・イン・ピクチャ領域を表す、第１のビデオの各ピクチャ内の第１セットの符号化ビデオデータユニットを示すための領域識別子（ID）のリスト、を含むステップと、
前記メタデータファイルを、第１のデバイスに送信するステップと、
を含む、方法。
【請求項7】
前記領域IDのリストは、前記メタデータファイル内の記述子の要素の属性である、請求項６に記載の方法。
【請求項8】
前記属性は、regionIdsである、請求項７に記載の方法。
【請求項9】
前記領域IDのリスト内の１つの領域IDは、前記第１のビデオを復号する前に、前記第１のビデオ内の領域IDを有する前記第１セットの符号化ビデオデータユニットを、前記第２のビデオ内の領域IDを有する前記第２セットの符号化ビデオユニットに置き換えることを可能にする、請求項６に記載の方法。
【請求項10】
前記領域IDのリスト内の領域IDは、サブピクチャIDであり、前記第１セットの符号化ビデオデータユニットは、第１セットのビデオ符号化層ネットワーク抽象化層（VCL NAL）ユニットを含み、
前記第２セットの符号化ビデオデータユニットは、第２セットのVCL NALユニットを含む、
請求項６に記載の方法。
【請求項11】
プロセッサと、命令を備えた非一時的メモリとを含むビデオデータを処理する装置であって、前記命令は、前記プロセッサによって実行されると、前記プロセッサに請求項１に記載の方法を実行させる、
装置。
【請求項12】
プロセッサに請求項１に記載の方法を実行させる命令を記憶する、非一時的なコンピュータ可読記憶媒体。
【国際調査報告】