JP7490712B2

JP7490712B2 - ピクチャ・イン・ピクチャ領域内のビデオデータユニットの置換のシグナリング

Info

Publication number: JP7490712B2
Application number: JP2022105485A
Authority: JP
Inventors: ワンイェ－クイ
Original assignee: Lemon Inc
Current assignee: Lemon Inc
Priority date: 2021-06-30
Filing date: 2022-06-30
Publication date: 2024-05-27
Anticipated expiration: 2042-06-30
Also published as: US20230018718A1; CN115550721A; EP4114015A1; EP4114016A1; JP2023008948A; JP2024100938A; KR20230004338A; CN115550722A; US20230018200A1; JP2023008947A; JP7495446B2; CN115550720A; JP2023008949A; US20230019913A1; KR20230004341A; KR20230004340A; US11985333B2; JP7495445B2; EP4114017A1

Description

［関連出願への相互参照］
適用可能な特許法及び／又はパリ条約に従う規則の下で、本願は、２０２１年６月３０日付けで出願された米国特許仮出願第６３／２１６９７５号と、２０２１年７月１日付けで出願された米国特許仮出願第６３／２１７６６５号との優先権及びその利益を適宜請求するためになされたものである。法の下での全ての目的のために、上記の出願の全開示は、本願の開示の部分として参照により援用される。

［技術分野］
本開示は、概して、ビデオストリーミングに関係があり、特に、ハイパーテキスト転送プロトコル上の動的適応ストリーミング（Dynamic Adaptive Streaming over Hypertext Transfer Protocol，ＤＡＳＨ）プロトコルでのピクチャ・イン・ピクチャサービスのサポートに関係がある。

デジタルビデオは、インターネット及び他のデジタル通信ネットワークで最大の帯域幅使用を占めている。映像を受信及び表示可能なユーザデバイスの接続数が増えるにつれて、デジタルビデオ利用のための帯域幅需要は増大し続けることが予想される。

開示されている態様／実施形態は、事前選択要素にインジケータを組み込む技術を提供する。実施形態において、インジケータは、メイン映像の対象ピクチャ・イン・ピクチャ領域を表すビデオデータユニットが補足映像の対応するビデオデータユニットで置換可能である、ことを示す。よって、ビデオコーディングプロセスは、従来のビデオコーディング技術に対して改善される。

第１の態様は、メディアデータを処理する方法に関係がある。方法は、前記メディアデータとメディアデータファイルとの間の変換のために、事前選択要素がインジケータを含むかどうかを決定するステップであり、前記インジケータは、メイン映像の対象ピクチャ・イン・ピクチャ領域を表すビデオデータユニットが補足映像の対応するビデオデータユニットで置換可能であることを示す、ステップと、前記インジケータに基づき前記メディアデータと前記メディアデータファイルとの間の前記変換を実行するステップとを含む。

任意に、上記の態様のいずれかにおいて、当該態様の他の実施は、前記インジケータが前記事前選択要素の属性を有する、ことを提供する。

任意に、上記の態様のいずれかにおいて、当該態様の他の実施は、前記インジケータが＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅ属性を有する、ことを提供する。

任意に、上記の態様のいずれかにおいて、当該態様の他の実施は、＠ｔａｇ属性が前記事前選択要素に存在する場合にのみ、前記インジケータが前記事前選択要素に存在する、ことを提供する。

任意に、上記の態様のいずれかにおいて、当該態様の他の実施は、前記事前選択要素の目的が、前記補足映像が前記メイン映像内の前記対象ピクチャ・イン・ピクチャ領域にオーバーレイされるよう現れるピクチャ・イン・ピクチャ体験を提供するためである、ことを前記事前選択要素内の＠ｔａｇ属性が示す場合にのみ、前記インジケータが前記事前選択要素に存在する、ことを提供する。

任意に、上記の態様のいずれかにおいて、当該態様の他の実施は、前記事前選択要素が前記インジケータを含まないことを決定するステップを提供する。

任意に、上記の態様のいずれかにおいて、当該態様の他の実施は、前記事前選択要素が前記インジケータを含まない場合に、前記メイン映像内の前記対象ピクチャ・イン・ピクチャ領域を表す前記ビデオデータユニットを前記補足映像の前記対応するビデオデータユニットで置換することが未知である、ことを提供する。

任意に、上記の態様のいずれかにおいて、当該態様の他の実施は、前記インジケータが、真の値を有している＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅ属性を有する、ことを提供する。

任意に、上記の態様のいずれかにおいて、当該態様の他の実施は、前記＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅ属性が前記真の値を有している場合に、前記メイン映像内の前記対象ピクチャ・イン・ピクチャ領域を表す前記ビデオデータユニットを前記補足映像の前記対応するビデオデータユニットで置換することを選択することをクライアントに許すステップを提供する。

任意に、上記の態様のいずれかにおいて、当該態様の他の実施は、前記＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅ属性が前記真の値を有している場合に、前記メイン映像内の前記対象ピクチャ・イン・ピクチャ領域を表す前記ビデオデータユニットを前記補足映像の前記対応するビデオデータユニットで置換することを選択することをクライアントに許すことによって、前記メイン映像及び前記補足映像の別々の復号化を回避するステップを提供する。

任意に、上記の態様のいずれかにおいて、当該態様の他の実施は、前記補足映像の前記対応するビデオデータユニットが、前記補足映像の表現における復号化時間同期サンプル内の全てのビデオデータユニットである、ことを提供する。

任意に、上記の態様のいずれかにおいて、当該態様の他の実施は、前記復号化時間同期サンプル内のビデオデータユニットが、前記メイン映像内の特定のピクチャに対応する、ことを提供する。

任意に、上記の態様のいずれかにおいて、当該態様の他の実施は、前記事前選択要素がＰｉｃｎＰｉｃ要素を含む、ことを提供する。

任意に、上記の態様のいずれかにおいて、当該態様の他の実施は、前記インジケータが＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅ属性を有し、前記ＰｉｃｎＰｉｃ要素が前記＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅ属性を含む、ことを提供する。

任意に、上記の態様のいずれかにおいて、当該態様の他の実施は、前記事前選択要素がメディアプレゼンテーション記述（Media Presentation Description，ＭＰＤ）ファイルに配置される、ことを提供する。

任意に、上記の態様のいずれかにおいて、当該態様の他の実施は、前記事前選択要素がＤＡＳＨプレゼンテーション要素である、ことを提供する。

任意に、上記の態様のいずれかにおいて、当該態様の他の実施は、前記変換が、前記メディアデータをビットストリームに符号化することを含む、ことを提供する。

任意に、上記の態様のいずれかにおいて、当該態様の他の実施は、前記変換が、前記メディアデータをビットストリームから復号することを含む、ことを提供する。

第２の態様は、メディアデータを処理する装置に関係がある。装置は、プロセッサと、命令を有する非一時的なメモリとを有する。前記命令は、前記プロセッサによる実行時に、前記プロセッサに、前記メディアデータとメディアデータファイルとの間の変換のために、事前選択要素がインジケータを含むかどうかを決定するステップであり、前記インジケータは、メイン映像の対象ピクチャ・イン・ピクチャ領域を表すビデオデータユニットが補足映像の対応するビデオデータユニットで置換可能であることを示す、ステップと、前記インジケータに基づき前記メディアデータと前記メディアデータファイルとの間の前記変換を実行するステップとを実行させる。

第３の態様は、ビデオ処理装置によって実行された方法によって生成されるビデオのＭＰＤを記憶する非一時的なコンピュータ可読記録媒体に関係がある。前記方法は、事前選択要素がインジケータを含むかどうかを決定するステップであり、前記インジケータは、メイン映像の対象ピクチャ・イン・ピクチャ領域を表すビデオデータユニットが補足映像の対応するビデオデータユニットで置換可能であることを示す、ステップと、前記インジケータに基づき前記ＭＰＤを生成するステップとを有する。

明りょうさのために、上記の実施形態のうちのいずれか１つは、本開示の範囲内で新しい実施形態を作り出すよう、上記の実施形態のうちの他の１つ以上と組み合わされてよい。

これら及び他の特徴は、添付の図面及び特許請求の範囲と併せて以下の詳細な説明から、より明りょうに理解されるだろう。

本開示のより完全な理解のために、これより、添付の図面及び詳細な説明に関連して、以下の簡単な説明が参照される。ここで、同じ参照番号は同じ部分を表す。

ＤＡＳＨで使用されるメディアプレゼンテーション記述（ＭＰＤ）によるビデオの記述を表す概略図である。タイル、スライス、及びサブピクチャにパーティション化されたピクチャの例である。サブピクチャに基づいたビューポート依存の３６０°映像配信方式の例である。サブピクチャ抽出の例である。バーサタイル・ビデオ・コーディング（ＶＶＣ）サブピクチャに基づいたピクチャ・イン・ピクチャサポートの例である。例となるビデオ処理システムを示すブロック図である。ビデオ処理装置のブロック図である。ビデオコーディングシステムの例を表すブロック図である。ビデオエンコーダの例を表すブロック図である。ビデオデコーダの例を表すブロック図である。本開示の実施形態に係るメディアデータ処理方法である。

１つ以上の実施形態の例示的な実施が以下で与えられているが、開示されているシステム及び／又は方法は、現在知られていようが又は存在していようが、任意の数の技術を用いて実装されてよい、ことが最初に理解されるべきである。本開示は、本明細書で例示又は記載されている設計及び実施の例を含め、以下で説明されている例示的な実施、図面、及び技術に決して制限されるべきではなく、添付の特許請求の範囲及びその均等の全範囲内で変更されてもよい。

Ｈ．２６６の用語は、開示されている技術の範囲を限定するためにではなく、その理解を容易にするために、いくつかの説明で使用されている。そのようなものとして、本明細書で記載されている技術は、他のビデオコーデックプロトコル及び設計にも適用可能である。

ビデオコーディング標準規格は、よく知られているＩＴＵ－Ｔ（International Telecommunication Union - Telecommunication）及びＩＳＯ（International Organization for Standardization）／ＩＥＣ（International Electrotechnical Commission）標準規格の開発を通じて主に発展してきた。ＩＴＵ－Ｔは、Ｈ．２６１及びＨ．２６３を作成し、ＩＳＯ／ＩＥＣは、ＭＰＥＧ（Moving Picture Experts Group）－１及びＭＰＥＧ－４Ｖｉｓｕａｌを作成し、２つの組織は共同して、Ｈ．２６２／ＭＰＥＧ－２Ｖｉｄｅｏ及びＨ．２６４／ＭＰＥＧ－４ＡＶＣ（Advanced Video Coding）及びＨ．２６５／ＨＥＶＣ（High Efficiency Video Coding）標準規格を作成した。

Ｈ．２６２以降、ビデオコーディング標準規格は、時間予測に変換コーディングをプラスしたものが利用されるハイブリッドビデオコーディング構造に基づいている。ＨＥＶＣを越える将来のビデオコーディング技術を探求するために、ＪＶＥＴ（Joint Video Exploration Team）が２０１５年にＶＣＥＧ（Video Coding Experts Group）及びＭＰＥＧによって共同で設立された。それ以来、多くの新しい方法がＪＶＥＴによって採用され、ＪＥＭ（Joint Exploration Model）と呼ばれる参照ソフトウェアに置かれてきた。

２０１８年４月に、ＶＣＥＧ（Ｑ６／１６）とＩＳＯ／ＩＥＣＪＴＣ１ＳＣ２９／ＷＧ１１（ＭＰＥＧ）との間のＪＶＥＴ（Joint Video Expert Team）が、ＨＥＶＣと比較して５０％のビットレート低減を目指したＶＶＣ（Versatile Video Coding）標準規格を研究するために作られた。

ＶＶＣ標準規格（ＩＴＵ－ＴＨ．２６６｜ＩＳＯ／ＩＥＣ２３０９０－３）及び関連するＶＳＥＩ（Versatile Supplemental Enhancement Information）標準規格（ＩＴＵ－ＴＨ．２７４｜ＩＳＯ／ＩＥＣ２３００２－７）は、テレビ放送、ビデオ会議、又は記憶媒体からの再生などの従来の使用、及び適応ビットレートストリーミング、ビデオ領域抽出、複数のコーディングされたビデオビットストリームからのコンテンツの合成及びマージ、マルチビュー映像、スケーラブルレイヤードコーディング、及びビューポート適応３６０°没入メディアなどのより新しくかつより高度な使用の両方を含む、最大限に幅広い用途での使用のために設計された。

ＥＶＣ（Essential Video Coding）標準規格（ＩＳＯ／ＩＥＣ２３０９４－１）は、ＭＰＥＧによって最近開発された他のビデオコーディング標準規格である。

メディアストリーミングアプリケーションは、通常は、インターネットプロトコル（Internet Protocol，ＩＰ）、伝送制御プロトコル（Transmission Control Protocol，ＴＣＰ）、及びハイパーテキスト転送プロトコル（Hypertext Transfer Protocol，ＨＴＴＰ）トランスポート方法に基づいており、通常は、ＩＳＯベースメディアファイルフォーマット（ISO base media file format，ＩＳＯＢＭＦＦ）などのファイルフォーマットに依存する。１つのそのようなストリーミングシステムはＤＡＳＨである。ＩＳＯＢＭＦＦ及びＤＡＳＨとともにビデオフォーマットを使用するために、ＩＳＯ／ＩＥＣ１４４９６－１５：“Information technology - Coding of audio-visual objects - Part 15: Carriage of network abstraction layer (NAL) unit structured video in the ISO base media file format”におけるＡＶＣファイルフォーマット及びＨＥＶＣファイルフォーマットなどのビデオフォーマットに特有のファイルフォーマット仕様が、ＩＳＯＢＭＦＦトラック内並びにＤＡＳＨ表現及びセグメント内のビデオコンテンツのカプセル化のために必要となる。ビデオビットストリームに関する重要な情報、例えば、プロファイル、ティア、及びレベル、並びに多くの他の情報は、コンテンツ選択のために、例えば、ストリーミングセッションの開始時の初期化及びストリーミングセッション中のストリーム適応の両方のための適切なメディアセグメントの選択のために、ファイルフォーマットレベルメタデータ及び／又はＤＡＳＨ表現及びセグメント内のビデオコンテンツメディアプレゼンテーション記述（ＭＰＤ）として公開されることが必要となる。

同様に、ＩＳＯＢＭＦＦとともに画像フォーマットを使用するために、ＩＳＯ／ＩＥＣ２３００８－１２：“Information technology - High efficiency coding and media delivery in heterogeneous environments - Part 12: Image File Format”におけるＡＶＣ画像ファイルフォーマット及びＨＥＶＣ画像ファイルフォーマットなどの画像フォーマットに特有のファイルフォーマット仕様が、必要となる。

ＩＳＯＢＭＦＦに基づいたＶＶＣビデオコンテンツの記憶のためのファイルフォーマットであるＶＶＣビデオファイルフォーマットが、現在、ＭＰＥＧによって開発中である。ＶＶＣビデオファイルフォーマットの最新のドラフト仕様は、ＩＳＯ／ＩＥＣＪＴＣ１／ＳＣ２９／ＷＧ０３出力文書Ｎ００３５，“Potential improvements on Carriage of VVC and EVC in ISOBMFF”，２０２０年１１月に含まれている。

ＩＳＯＢＭＦＦに基づいたＶＶＣを使用してコーディングされた画像コンテンツの記憶のためのファイルフォーマットであるＶＶＣ画像ファイルフォーマットが、現在、ＭＰＥＧによって開発中である。ＶＶＣ画像ファイルフォーマットの最新のドラフト仕様は、ＩＳＯ／ＩＥＣＪＴＣ１／ＳＣ２９／ＷＧ０３出力文書Ｎ００３８，“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)”，２０２０年１１月に含まれている。

図１は、ＤＡＳＨで使用されるＭＰＤ１００によるビデオ又はメディアデータの記述を説明する概略図である。ＭＰＤ１００は、周期１１０、適応セット１２０、表現１３０、及びセグメント１４０に関してメディアストリームを記述する。

ＤＡＳＨでは、マルチメディアコンテンツのビデオ及び／又はオーディオデータのための複数の表現が存在してよく、異なる表現は異なるコーディング特性（例えば、ビデオコーディング標準規格の異なるプロファイル又はレベル、異なるビットレート、異なる空間分解能、など）に対応してよい。そのような表現のマニフェストは、ＭＰＤデータ構造で定義されてよい。メディアプレゼンテーションは、ＤＡＳＨストリーミングクライアントデバイス（例えば、スマートフォン、電子タブレット、ラップトップ、など）がアクセスすることができるデータの構造化された集合に対応してよい。ＤＡＳＨストリーミングクライアントデバイスは、ストリーミングサービスをクライアントデバイスのユーザに提示するためにメディアデータ情報を要求及びダウンロードしてよい。メディアプレゼンテーションは、ＭＰＤのアップデートを含んでもよいＭＰＤデータ構造で記述されてよい。

メディアプレゼンテーションは、１つ以上の周期１１０のシーケンスを含んでよい。各周期１１０は、次の周期１１０の開始まで、又は最後の周期１１０の場合には、メディアプレゼンテーションの終わりまで、延在してよい。各周期１１０は、同じメディアコンテンツのために１つ以上の表現１３０を含んでよい。表現１３０は、オーディオ、ビデオ、時限テキスト（timed text）、又は他のそのようなデータの多数の選択的な符号化バージョンのうちの１つであってよい。表現１３０は、符号化タイプによって、例えば、ビデオデータのビットレート、分解能、及び／又はコーデック、並びにオーディオデータのビットレート、言語、及び／又はコーデックによって、異なってよい。表現１３０という用語は、マルチメディアコンテンツの特定の周期１１０に対応し且つ特定の方法で符号化された符号化オーディオ又はビデオデータのセクションを指すために使用されてよい。

特定の周期１１０の表現１３０は、それらの表現１３０が属する適応セット１２０を示すＭＰＤ１００内の属性によって示されるグループに割り当てられてよい。同じ適応セット１２０内の表現１３０は、クライアントデバイスが、例えば、帯域幅適応を実行するために、それらの表現１３０を動的且つシームレスに切り替えることができる点で、一般的に、互いに代替と見なされる。例えば、特定の周期のビデオデータの各表現１３０は、同じ適応セット１２０に割り当てられてよく、それにより、表現１３０のいずれかが、対応する周期１１０のマルチメディアコンテンツのメディアデータ、例えば、ビデオデータ又はオーディオデータを提示するよう復号化のために選択され得る。１つの周期１１０内のメディアコンテンツは、いくつかの例において、存在する場合にはグループ０からの１つの表現１３０、又は各非ゼログループからの多くても１つの表現の組み合わせ、のどちらか一方によって表現されてよい。周期１１０の各表現１３０の時限データは、その周期１１０の開始時間に対して表されてよい。

表現１３０は、１つ以上のセグメント１４０を含んでよい。各表現１３０は初期化セグメント１４０を含んでよく、あるいは、表現の各セグメント１４０は自己初期化であってよい。存在する場合に、初期化セグメント１４０は、表現１３０にアクセスするための初期化情報を含んでよい。一般的に、初期化セグメント１４０はメディアデータを含まない。セグメント１４０は、ＵＲＬ（Uniform Resource Locator）、ＵＲＮ（Uniform Resource Name）、又はＵＲＩ（Uniform Resource Identifier）などの識別子によって一意に参照されてよい。ＭＰＤ１００は、各セグメント１４０について識別子を供給してよい。いくつかの例において、ＭＰＤ１００はまた、ＵＲＬ、ＵＲＮ、又はＵＲＩによってアクセス可能なファイル内のセグメント１４０のデータに対応し得るバイト範囲を範囲属性の形で供給してもよい。

異なる表現１３０は、異なるタイプのメディアデータの略同時の読み出しのために選択されてよい。例えば、クライアントデバイスは、セグメント１４０を読み出すオーディオ表現１３０、ビデオ表現１３０、及び時限テキスト表現１３０を選択してよい。いくつかの例において、クライアントデバイスは、帯域幅適応を実行するために特定の適応セット１２０を選択してもよい。つまり、クライアントデバイスは、ビデオ表現１３０を含む適応セット１２０、オーディオ表現１３０を含む適応セット１２０、及び／又は時限テキスト表現１３０を含む適応セット１２０を選択し得る。代替的に、クライアントデバイスは、特定のタイプのメディア（例えば、ビデオ）の適応セット１２０を選択し、そして、他のタイプのメディア（例えば、オーディオ及び／又は時限テキスト）の表現１３０を直接に選択してもよい。

典型的なＤＡＳＨストリーミングプロシージャは、次のステップによって示される。

第１に、クライアントはＭＰＤを得る。実施形態において、クライアントデバイスは、クライアントデバイスがＭＰＤを要求した後に、コンテンツソースからＭＰＤを受け取る。

第２に、クライアントはダウンリンク帯域幅を推定し、推定されたダウンリンク帯域幅と、コーデック、復号化能力、表示サイズ、オーディオ言語設定、などとに従って、ビデオ表現１３０及びオーディオ表現１３０を選択する。

第３に、メディアプレゼンテーションの終わりに達しない限りは、クライアントは、選択された表現１３０のメディアセグメント１４０を要求し、ストリーミングコンテンツをユーザに提示する。

第４に、クライアントは、ダウンリンク帯域幅を推定し続ける。帯域幅が有意に変化する（例えば、低くなる）場合に、クライアントは、新たに推定された帯域幅に適合させるよう異なるビデオ表現１３０を選択し、プロシージャは第３のステップに戻る。

ＶＶＣでは、ピクチャは、１つ以上のタイル行及び１つ以上のタイル列に分割（例えば、パーティション化）される。タイルは、ピクチャの長方形領域をカバーするコーディングツリーユニット（Coding Tree Units，ＣＴＵ）の連続である。タイル内のＣＴＵは、そのタイル内でラスタ走査順で走査される。

スライスは、多数の完全なタイル、又はピクチャのタイル内の整数個の連続した完全なＣＰＵ、から成る。

スライスの２つのモード、つまり、ラスタ走査スライスモード及び長方形スライスモード、がサポートされる。ラスタ走査スライスモードでは、スライスは、ピクチャのタイルラスタ走査での完全なスライスの連続を含む。長方形スライスモードでは、スライスは、ピクチャの長方形領域を集合的に形成する多数の完全なタイル、又はピクチャの長方形領域を集合的に形成する１つのタイルの多数の連続した完全なＣＴＵ行、のどちらか一方を含む。長方形スライス内のタイルは、そのスライスに対応する長方形領域内でラスタ走査順で走査される。

サブピクチャは、ピクチャの長方形領域を集合的にカバーする１つ以上のスライスを含む。

図２は、タイル２０２、サブピクチャ／スライス２０４、及びＣＴＵ２０６にパーティション化されたピクチャ２００の例である。図示されるように、ピクチャ２００は、１８個のタイル２０２と、２４個のサブピクチャ／スライス２０４とにパーティション化されている。ＶＶＣでは、各サブピクチャは、図２に示されるように、ピクチャの長方形領域を集合的にカバーする１つ以上の完全な長方形スライスから成る。サブピクチャは、抽出可能（すなわち、同じピクチャ及び復号化順で先のピクチャの他のサブピクチャから独立してコーディングされている）又は抽出不可能のどちらか一方であるよう指定されてよい。サブピクチャが抽出可能であるか否かにかかわらず、エンコーダは、インループフィルタリング（デブロッキング、サンプル適応オフセット（Sample Adaptive Offset，ＳＡＯ）、及び適応ループフィルタ（Adaptive Loop Filter，ＡＬＦ））がサブピクチャ毎に個別的にサブピクチャ境界にわたって適用されるかどうかを制御することができる。

機能的に、サブピクチャは、ＨＥＶＣでの動き制約付きタイルセット（Motion-Constrained Tile Sets，ＭＣＴＳ）に類似している。それらは両方とも、ビューポート依存３６０°ビデオストリーミング最適化及び関心領域（Region of Interest，ＲＯＩ）アプリケーションのような使用ケースのために、コーディングされたピクチャの連続の長方形サブセットの独立したコーディング及び抽出を可能にする。

３６０°ビデオ（別名、全方位ビデオ）のストリーミングでは、如何なる特定の時点でも、全方位ビデオ球全体の一部（例えば、現在のビューポート）のみがユーザにレンダリングされることになる一方、ユーザは、見る方向、結果として、現在のビューポートを変更するために、いつでも自身の頭部を回転させることができる。クライアントで利用可能な現在のビューポートによってカバーされていないが、ユーザが突然に自身の見る方向を球上のどこかに変える場合に備えてユーザにレンダリングされる用意ができているエリアの表現を少なくとも若干低品質とすることが望まれる一方で、全方位ビデオの高品質の表現は、いずれかの所与の時点でユーザにレンダリングされている現在のビューポートにのみ必要とされる。全方位ビデオ全体の高品質の表現を適切な粒度でサブピクチャに分けることは、左側にある１２個の高解像度サブピクチャと、右側にある低解像度の全方位ビデオの残り１２個のサブピクチャとを含む、図２に示されるような最適化を可能にする。

図３は、サブピクチャに基づいたビューポート依存３６０°映像配信方式３００の例である。図３に示されるように、全映像の高解像度表現のみがサブピクチャを使用する。全映像の低解像度表現はサブピクチャを使用せず、高解像度表現よりも頻度の少ないランダムアクセスポイント（Random Access Points，ＲＡＰ）でコーディングされ得る。クライアントは、低解像度で全映像を受信し、一方、高解像度の映像については、クライアントは、現在のビューポートをカバーするサブピクチャのみを受信して復号する。

サブピクチャとＭＣＴＳとの間にはいくつかの設計相違がある。第１に、ＶＶＣでのサブピクチャ特徴は、サブピクチャが抽出可能である場合でさえ、コーディングブロックの動きベクトルがサブピクチャの外を指すことを可能にする。そうするために、サブピクチャ特徴は、この場合にはピクチャ境界に類似するサブピクチャ境界でサンプルパディングを適用する。第２に、マージモードでの及びＶＶＣのデコーダ側動きベクトル精緻化（decoder side motion vector refinement）プロセスでの動きベクトルの選択及び導出のために、追加の変更が導入された。これは、ＭＣＴＳのためにエンコーダ側で適用される非規範的な動き制約と比べて高いコーディング効率を可能にする。第３に、スライスヘッダ（Slice Headers，ＳＨ）（及び存在する場合に、ピクチャヘッダ（Picture Header，ＰＨ）ネットワーク抽象化レイヤ（Network Abstraction Layer，ＮＡＬ）ユニット）を書き換えることは、適合（conforming）ビットストリームであるサブビットストリームを生成するためにピクチャの連続から１つ以上の抽出可能なサブピクチャを抽出する場合に、不要である。ＨＥＶＣＭＣＴＳに基づいたサブビットストリーム抽出では、ＳＨの書き換えが必要である。ＨＥＶＣＭＣＴＳ抽出及びＶＶＣサブピクチャ抽出の両方で、シーケンスパラメータセット（Sequence Parameter Sets，ＳＰＳ）及びピクチャパラメータセット（Picture Parameter Sets，ＰＰＳ）の書き換えが必要である点に留意されたい。しかし、通常、ビットストリームには少数のパラメータセットしかないが、各ピクチャは少なくとも１つのスライスを有する。従って、ＳＨの書き換えは、アプリケーションシステムにとって大きな負担になる可能がある。第４に、ピクチャ内の異なるサブピクチャのスライスは、異なるＮＡＬユニットタイプを有することを許されている。これは、以下で更に詳細に論じられている、ピクチャ内の混合ＮＡＬユニットタイプ又は混合サブピクチャタイプとしばしば呼ばれる特徴である。第５に、ＶＶＣは、サブピクチャシーケンスの仮説参照デコーダ（Hypothetical Reference Decoder，ＨＲＤ）及びレベル定義を指定するので、各抽出可能なサブピクチャシーケンスのサブビットストリームの適合性（conformance）がエンコーダによって確かにされ得る。

ＡＶＣ及びＨＥＶＣでは、ピクチャ内の全てのＶＣＬＮＡＬユニットが同じＮＡＬユニットタイプを有する必要がある。ＶＶＣは、ピクチャ内の特定の異なるＶＣＬＮＡＬユニットタイプとサブピクチャを混合するオプションを導入するので、ピクチャレベルでだけでなくサブピクチャレベルでもランダムアクセスのためのサポートを提供する。ＶＶＣでは、サブピクチャ内のＶＣＬＮＡＬユニットが依然として同じＮＡＬユニットタイプを有する必要がある。

イントラランダムアクセスピクチャ（Intra Random Access Pictures，ＩＲＡＰ）サブピクチャからのランダムアクセスの能力は、３６０°ビデオアプリケーションにとって有益である。図３に示されているものに類似したビューポート依存３６０°映像配信方式では、空間に隣接するビューポートのコンテンツが大きく重なり合っており、つまり、ビューポート内のサブピクチャの一部のみが、ビューポートの向きの変更中に、新しいサブピクチャで置換され、一方、ほとんどのサブピクチャはビューポート内に残る。新たにビューポートに導入されるサブピクチャシーケンスは、ＩＲＡＰスライスから開始しなければならないが、残りのサブピクチャがビューポート変化時にインター予測を行えるようにする場合に、全体の伝送ビットレートの大幅な低下が達成され得る。

ピクチャがただ１つのタイプのＮＡＬユニットを含むか、それとも１よりも多いタイプを含むかの指示は、ピクチャによって参照されるＰＰＳで（つまり、pps_mixed_nalu_types_in_pic_flagと呼ばれるフラグを用いて）供給される。ピクチャは、ＩＲＡＰスライスを含むサブピクチャと、トレーリング（trailing）スライスを含むサブピクチャとを同時に有してよい。ピクチャ内の異なるＮＡＬユニットタイプのいくつかの他の組み合わせも許可される。これには、ＮＡＬユニットタイプのリーディング（leading）ピクチャスライスであるＲＡＳＬ（Random Access Skipped Leading）及びＲＡＤＬ（Random Access Decodable Leading）が含まれ、これにより、サブピクチャシーケンスを、異なるビットストリームから抽出されたオープングループ・オブ・ピクチャ（Groupe of Picture，ＧＯＰ）及びクローズＧＯＰ構造とマージして、１つのビットストリームにすることができる。

ＶＶＣ内のサブピクチャのレイアウトはＳＰＳでシグナリングされるので、コーディングレイヤビデオシーケンス（Coded Layer Video Sequence，ＣＬＶＳ）内で一定である。各サブピクチャは、その左上ＣＴＵの位置と、ＣＴＵの数で表したその幅及び高さとによってシグナリングされるので、サブピクチャがＣＴＵ粒度でピクチャの長方形領域をカバーすることが確かになる。サブピクチャがＳＰＳでシグナリングされる順序は、ピクチャ内の各サブピクチャのインデックスを決定する。

ＳＨ又はＰＨを書き換えずにサブピクチャシーケンスの抽出及びマージを可能にするために、ＶＶＣでのスライスアドレッシング方式は、サブピクチャＩＤと、スライスをサブピクチャに関連付けるサブピクチャ固有スライスインデックスとに基づく。スライスヘッダ（ＳＨ）では、スライスを含むサブピクチャのサブピクチャ識別子（ＩＤ）と、サブピクチャレベルのスライスインデックスとがシグナリングされる。特定のサブピクチャのサブピクチャＩＤの値は、そのサブピクチャインデックスの値とは異なる可能性がある点に留意されたい。２つの間のマッピングは、ＳＰＳ又はＰＰＳ（決して両方ではない）でシグナリングされるか、あるいは、暗黙的に推測されるかのどちらかである。存在する場合に、サブピクチャＩＤマッピングは、サブピクチャサブビットストリーム抽出プロセス中にＳＰＳ及びＰＰＳを書き換える場合に書き換え又は追加される必要がある。サブピクチャＩＤ及びサブピクチャレベルのスライスインデックスは一緒に、復号されたピクチャの復号化ピクチャバッファ（Decoded Picture Buffer，ＤＰＢ）スロット内のスライスの最初の復号化されたＣＴＵの正確な位置をデコーダに示す。サブビットストリーム抽出後、サブピクチャのサブピクチャＩＤは変化しないままであるが、サブピクチャインデックスは変化する可能性がある。サブピクチャ内のスライスの最初のＣＴＵのラスタ走査ＣＴＵアドレスが原ビットストリーム内の値と比較して変化している場合でさえ、各々のＳＨ内のサブピクチャＩＤ及びサブピクチャレベルのスライスインデックスの不変な値は、抽出されたサブビットストリームの復号されたピクチャ内の各ＣＴＵの位置を依然として正確に決定する。

図４は、サブピクチャ抽出４００の例である。特に、図４は、サブピクチャ抽出４００の例を可能にするためのサブピクチャＩＤ、サブピクチャインデックス、及びサブピクチャレベルのスライスインデックスの利用を表す。表されている実施形態では、サブピクチャ抽出４００は、２つのサブピクチャ及び４つのスライスを含む。

サブピクチャ抽出４００と同様に、異なるビットストリームが（例えば、個別のサブピクチャＩＤ、しかし、そうではない場合には、ＣＴＵサイズ、クロマフォーマット、コーディングツールなどのような、大部分が整列されたＳＰＳ、ＰＰＳを及びＰＨパラメータ、を用いて）協調的に生成されるという条件で、サブピクチャのシグナリングは、ＳＰＳ及びＰＰＳの書き換えのみによって、異なるビットストリームからのいくつかのサブピクチャを１つのビットストリームにマージすることを可能にする。

サブピクチャ及びスライスがＳＰＳ及びＰＰＳで夫々独立してシグナリングされる一方で、適合ビットストリームを形成するためにサブピクチャレイアウトとスライスレイアウトとの間には固有の相互制約がある。第１に、サブピクチャの存在は長方形スライスを義務づけ、ラスタ走査スライスを禁止する。第２に、所与のサブピクチャのスライスは、復号化順で連続したＮＡＬユニットであり、つまり、サブピクチャレイアウトは、ビットストリーム内のコーディングされたスライスＮＡＬユニットの順序を制約する。

ピクチャ・イン・ピクチャサービスは、解像度が小さいピクチャを、解像度がより大きいピクチャ内に含める能力を提供する。そのようなサービスは、同時に２つのビデオをユーザに示すのに役立ち得る。これによって、解像度がより大きい映像はメイン映像と見なされ、解像度がより小さい映像は補足映像と見なされる。そのようなピクチャ・イン・ピクチャサービスは、メイン映像がサイネージ映像によって補われるアクセシビリティ（accessibility）サービスを提供するために使用され得る。

ＶＶＣサブピクチャは、ＶＶＣサブピクチャの抽出及びマージの両方の特性を使用することによって、ピクチャ・イン・ピクチャサービスのために使用され得る。そのようなサービスのために、メイン映像は、多数のサブピクチャを用いて符号化される。サブピクチャの１つは補足映像と同じサイズであり、これは、補足映像がメイン映像に重ね合わされるよう意図される正確な位置に位置している。補足映像は、抽出を可能にするよう独立してコーディングされる。ユーザが、補足映像を含むサービスのバージョンを見ることを選ぶとき、メイン映像のピクチャ・イン・ピクチャエリアに対応するサブピクチャがメイン映像ビットストリームから抽出され、補足映像ビットストリームがその場所でメイン映像ビットストリームとマージされる。

図５は、ＶＶＣサブピクチャに基づいたピクチャ・イン・ピクチャサポート５００の例である。ＳｕｂｐｉｃＩＤ０とラベル付けされているメイン映像の部分は、メイン映像のその部分がＳｕｂｐｉｃＩＤ０を有する補足映像で置換されることになるので、対象ピクチャ・イン・ピクチャ領域と本明細書では呼ばれ得る。つまり、補足映像は、図５に示されるメイン映像の中に埋め込まれるか又はその上にオーバーレイされる。例において、メイン映像及び補足映像のピクチャは、同じビデオ特性を共有する。特に、メイン映像及び補足映像のビットデプス、サンプルアスペクト比、サイズ、フレームレート、色空間及び転送特性、並びにクロマサンプル位置は、同じでなければならない。メイン映像ビットストリーム及び補足映像ビットストリームは、各ピクチャ内で同じＮＡＬユニットタイプを使用する必要はない。しかし、メイン映像ビットストリーム及び補足映像ビットストリームにおけるピクチャのコーディング順序は、同じである必要がある。

サブピクチャのマージがここでは使用されるので、メイン映像及び補足映像の中で使用されるサブピクチャＩＤは重複することができない。補足映像ビットストリームが、これ以上のタイル又はスライスパーティショニングもなしでただ１つのサブピクチャから成る場合でさえ、サブピクチャ情報（例えば、特に、サブピクチャＩＤ及びサブピクチャＩＤ長）は、メイン映像ビットストリームとの補足映像ビットストリームのマージを可能にするためにシグナリングされる必要がある。補足映像ビットストリームのスライスＮＡＬユニット内のサブピクチャＩＤシンタックス要素の長さをシグナリングするために使用されるサブピクチャＩＤ長は、メイン映像ビットストリームのスライスＮＡＬユニット内のサブピクチャＩＤをシグナリングするために使用されるサブピクチャＩＤ長と同じでなければならない。更に、ＰＰＳパーティショニング情報を書き換える必要なしにメイン映像ビットストリームとの補足映像ビットストリームのマージを簡単にするために、メイン映像の対応するエリア内で補足映像を符号化するためにただ１つのスライス及び１つのタイルを使用することが有益であり得る。メイン映像ビットストリーム及び補足映像ビットストリームは、ＳＰＳ、ＰＰＳ、及びピクチャヘッダで同じコーディングツールをシグナリングする必要がある。これは、ブロックパーティショニングのための同じ最大及び最小許容サイズと、ＰＰＳでシグナリングされたのと同じ初期量子化パラメータの値（pps_init_qp_minus26シンタックス要素の同じ値）とを使用することを含む。コーディングツールの利用は、スライスヘッダレベルで変更され得る。

メイン映像ビットストリーム及び補足映像ビットストリームの両方がＤＡＳＨベースの配信システムにより利用可能である場合に、ＤＡＳＨＰｒｅｓｅｌｅｃｔｉｏｎ（事前選択）が、一緒にマージ及びレンダリングされるよう意図されるメイン映像ビットストリーム及び補足映像ビットストリームをシグナリングするために使用されてよい。ＤＡＳＨＰｒｅｓｅｌｅｃｔｉｏｎは、ＤＡＳＨプレイヤーによって一緒に消費されると予想されるＭＰＤのメディアコンポーネントのサブセットを定義する。ここで、消費は、復号化及びレンダリングを有し得る。ＤＡＳＨＰｒｅｓｅｌｅｃｔｉｏｎのためのメインメディアコンポーネントを含む適応セットは、メイン適応セット（main Adaptation Set）と呼ばれる。更に、各ＤＡＳＨＰｒｅｓｅｌｅｃｔｉｏｎは、１つ又は複数の部分的な適応セットを含み得る。部分的な適応セットは、メイン適応セットと組み合わせて処理される必要があり得る。メイン適応セット及び部分的な適応セットは、事前選択記述子によって、又は事前選択要素によって、指示されてよい。

あいにく、次の問題が、ＤＡＳＨでピクチャ・イン・ピクチャサービスをサポートしようと試みるときに確認された。第１に、ピクチャ・イン・ピクチャ体験のためにＤＡＳＨ事前選択を使用することが可能である一方で、そのような目的の指示は欠けている。

第２に、（例えば、上述されたように）ピクチャ・イン・ピクチャ体験のためにＶＶＣサブピクチャを使用することが可能である一方で、メイン映像内の対象ピクチャ・イン・ピクチャ領域を表すコーディングされたビデオデータユニットを補足映像の対応するビデオデータユニットで置換することができない他のコーデック及び方法を使用する可能性もある。そのため、そのような置換が可能であるかどうかを示す必要がある。

第３に、上記の置換が可能である場合に、クライアントは、置換を行うことができるように、メイン映像の各ピクチャ内のどのコーディングされたビデオデータユニットが対象ピクチャ・イン・ピクチャ領域を表すのかを知る必要がある。そのため、この情報がシグナリングされる必要がある。

第４に、コンテンツ選択のために（また、場合により、他の目的のためにも）、メイン映像内の対象ピクチャ・イン・ピクチャ領域の位置及びサイズをシグナリングすることが有用となる。

本明細書では、上記の問題の１つ以上を解決する技術が開示される。例えば、本開示は、事前選択要素にインジケータを組み込む技術を提供する。実施形態において、インジケータは、メイン映像の対象ピクチャ・イン・ピクチャ領域を表すビデオデータユニットが補足映像の対応するビデオデータユニットで置換可能である、ことを示す。よって、ビデオコーディングプロセスは、従来のビデオコーディング技術と比較して改善される。

以下の詳細な実施形態は、概要を説明するための例と見なされるべきである。これらの実施形態は、狭い意味で解釈されるべきではない。更に、これらの実施形態は、如何なる方法でも組み合わされ得る。

以下の説明で、ビデオユニット（別名、ビデオデータユニット）は、ピクチャの連続、ピクチャ、スライス、タイル、ブリック、サブピクチャ、ＣＴＵ／コーディングツリーブロック（Coding Tree Block，ＣＴＢ）、ＣＴＵ／ＣＴＢ行、１つ又は複数の仮想パイプラインデータユニット（Virtual Pipeline Data Unit，ＶＰＤＵ）、ピクチャ／スライス／タイル／ブリック内のサブ領域であってよい。父ビデオユニット（別名、親ビデオユニット）は、ビデオユニットよりも大きいユニットを表す。通常、父ビデオユニットはいくつかのビデオユニットを含み、例えば、ビデオユニットがＣＴＵである場合には、父ビデオユニットはスライス、ＣＴＵ行、複数のＣＴＵ、などであってよい。いくつかの実施形態において、ビデオユニットはサンプル／ピクセルであってよい。いくつかの実施形態において、ビデオユニットはビデオデータユニットと呼ばれることがある。

［例１］
１）第１の問題を解決するために、指示がＭＰＤでシグナリングされる。指示は、事前選択（別名、Ｐｒｅｓｅｌｅｃｔｉｏｎ又はＤＡＳＨＰｒｅｓｅｌｅｃｔｉｏｎ）がピクチャ・イン・ピクチャ体験を提供するためである、ことを示す。つまり、事前選択要素内のインジケータは、事前選択要素の目的が、補足映像がメイン映像内の対象ピクチャ・イン・ピクチャ領域にオーバーレイされるよう現れるピクチャ・イン・ピクチャ体験を提供するためである、ことを示す。

ａ．一例で、指示は、事前選択の＠ｔａｇ属性の特定の値によって（例えば、ＣｏｍｍｏｎＡｔｔｒｉｂｕｔｅｓＥｌｅｍｅｎｔｓを通じて）シグナリングされる。実施形態において、＠ｔａｇの値は“ＰｉｃＩｎＰｉｃ”である。

ｂ．一例で、指示は、事前選択のＲｏｌｅ要素の＠ｖａｌｕｅ属性の特定の値によってシグナリングされる。実施形態において、＠ｖａｌｕｅの特定の値は“ＰｉｃＩｎＰｉｃ”である。

［例２］
２）第２の問題を解決するために、指示はＭＰＤでシグナリングされる。指示は、メイン映像内の対象ピクチャ・イン・ピクチャ領域を表すコーディングされたビデオデータユニットが補足映像の対応するビデオデータユニットで置換可能であるかどうかを示す。

ａ．一例で、指示は、属性によってシグナリングされる。実施形態において、属性は、事前選択の＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅで指定又は指名される。

ｂ．一例で、指示は、任意であるよう指定される。

ｉ．一例で、指示は、事前選択の＠ｔａｇ属性が、事前選択の目的がピクチャ・イン・ピクチャ体験を提供するためであることを示す場合にのみ、存在することができる。

ｃ．指示が存在しない場合に、そのような置換が可能であるかどうかは未知である。

ｄ．一例で、＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅが真である場合に、クライアントは、ビデオデコーダへ送る前に、メイン映像内の対象ピクチャ・イン・ピクチャ領域を表すコーディングされたビデオデータユニットを補足映像の対応するビデオデータユニットで置換することを選択し得る、ことが指定される。このようにして、メイン映像及び補足映像の別々の復号化は回避され得る。

ｅ．一例で、メイン映像内の特定のピクチャについて、補足映像の対応するビデオデータユニットは、補足映像表現における復号化時間同期サンプル内の全てのコーディングされたビデオデータユニットである、ことが指定される。

［例３］
３）第３の問題を解決するために、領域ＩＤのリストがＭＰＤでシグナリングされる。領域ＩＤのリストは、メイン映像の各ピクチャ内のどのコーディングされたビデオデータユニットが対象ピクチャ・イン・ピクチャ領域を表すかを示す。

ａ．一例で、領域ＩＤのリストは、事前選択の属性としてシグナリングされる。実施形態において、属性は、＠ｒｅｇｉｏｎｓＩｄｓと指名される。

ｂ．一例で、指示は、任意であるよう指定される。

ｃ．一例で、領域ＩＤの具体的なセマンティクスが特定のビデオコーデックについて明示的に指定される必要がある、ことが指定される。

ｉ．一例で、ＶＶＣの場合に、領域ＩＤはサブピクチャＩＤであり、コーディングされたビデオデータユニットはＶＣＬＮＡＬユニットである、ことが指定される。メイン映像内の対象ピクチャ・イン・ピクチャ領域を表すＶＣＬＮＡＬユニットは、補足映像の対応するＶＣＬＮＡＬユニット内のサブピクチャＩＤと同じであるこれらのサブピクチャＩＤを有するものである。通常、補足映像内の１つのピクチャの全てのＶＣＬＮＡＬユニットは、明示的にシグナリングされる同じサブピクチャＩＤを共有する。この場合に、領域ＩＤのリストには１つの領域ＩＤしかない。

レイヤは、nuh_layer_idの特定の値を全てが有しているＶＣＬＮＡＬユニットと、関連する非ＶＣＬＮＡＬユニットとの組である。ネットワーク抽象化レイヤ（ＮＡＬ）ユニットは、続くデータのタイプと、エミュレーション防止バイトが必要に応じて散りばめられているローバイトシーケンスペイロード（Raw Byte Sequence Payload，ＲＢＳＰ）の形でそのデータを含むバイトとの指示を含むシンタックス構造である。ビデオコーディングレイヤ（ＶＣＬ）ＮＡＬユニットは、コーディングされたスライスＮＡＬユニットと、ＶＶＣ標準規格でＶＣＬＮＡＬユニットとして分類されるnal_unit_typeのリザーブ値を持つＮＡＬユニットのサブセットとの総称である。

ｉｉ．一例で、ＶＶＣの場合に、クライアントが、ビデオデコーダへ送る前に、メイン映像内の対象ピクチャ・イン・ピクチャ領域を表すコーディングされたビデオデータユニット（ＶＣＬＮＡＬユニットである）を補足映像の対応するＶＣＬＮＡＬユニットで置換することを選択する場合に、各サブピクチャＩＤについて、メイン映像内のＶＣＬＮＡＬユニットは、対応するＶＣＬＮＡＬユニットの順序を変えずに、補足映像内のそのサブピクチャＩＤを有している対応するＶＣＬＮＡＬユニットで置換される。

［例４］
４）第４の問題を解決するために、メイン映像の位置及びサイズに関する情報がＭＰＤでシグナリングされる。実施形態において、メイン映像の位置及びサイズの情報は、メイン映像よりもサイズが小さい補足映像を埋め込む／オーバーレイするときに使用され得る。

ａ．一例で、位置及びサイズの情報は、４つの値、つまり、ｘ、ｙ、幅、及び高さのシグナリングによって、シグナリングされる。この実施形態では、ｘ及びｙは、領域の左上隅の位置を指定し、幅及び高さは、領域の幅及び高さを指定する。ユニットは、ルーマサンプル／ピクセルにあることができる。

ｂ．一例で、位置及びサイズの情報は、事前選択の属性又は要素によってシグナリングされる。

ｃ．一例で、位置及びサイズの情報は、事前選択のメイン適応セットの属性及び要素によってシグナリングされる。

ｄ．一例で、＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅが真であり、位置及びサイズの情報が存在する場合に、位置及びサイズは、メイン映像内の対象ピクチャ・イン・ピクチャ領域を正確に表すべきである、ことが指定される。

ｅ．一例で、＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅが偽であり、位置及びサイズの情報が存在する場合に、位置及びサイズの情報は、補足映像を埋め込む／オーバーレイするための望ましい領域を示す（すなわち、クライアントは、メイン映像の異なる領域に補足映像をオーバーレイすることを選択し得る）、ことが指定される。

ｆ．一例で、＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅが偽であり、位置及びサイズの情報が存在しない場合に、補足映像をどこにオーバーレイすべきかに関する情報又は推奨は示唆されず、補足映像をどこにオーバーレイすべきかは、完全にクライアントが選択すべきものである、ことが指定される。

［例５］
５）代替的に、要素、例えば、ＰｉｃｎＰｉｃ要素と呼ばれる、が事前選択要素に加えられる。このＰｉｃｎＰｉｃ要素は、次のうちの少なくとも１つ以上を含む：
ａ．上記と同様に、＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅ属性，
ｂ．上記と同様に、＠ｒｅｇｉｏｎｓＩｄｓ属性，
ｃ．メイン映像内の対象ピクチャ・イン・ピクチャ領域の左上符号化ビデオピクセル（サンプル）の水平位置を指定する＠ｘ属性。単位はビデオピクセル（サンプル）である。４つの属性＠ｘ、＠ｙ、＠ｗｉｄｔｈ、及び＠ｈｅｉｇｈｔが全て存在するか又は全て存在しないかのどちらかである，
ｄ．メイン映像内の対象ピクチャ・イン・ピクチャ領域の左上符号化ビデオピクセル（サンプル）の垂直位置を指定する＠ｙ属性。単位はビデオピクセル（サンプル）である，
ｅ．メイン映像内の対象ピクチャ・イン・ピクチャ領域の幅を指定する＠ｗｉｄｈｔｈ属性。単位はビデオピクセル（サンプル）である，
ｆ．メイン映像内の対象ピクチャ・イン・ピクチャ領域の高さを指定する＠ｈｅｉｇｈｔ属性。単位はビデオピクセル（サンプル）である。

［例６］
６）代替的に、要素、例えば、ＰｉｃｎＰｉｃ要素と呼ばれる、が事前選択要素に加えられる。このＰｉｃｎＰｉｃ要素は、次のうちの少なくとも１つ以上を含む：
ａ．上記と同様に、＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅ属性，
ｂ．上記と同様に、＠ｒｅｇｉｏｎｓＩｄｓ属性，
ｃ．少なくとも次を含む、例えば、Ｒｅｇｉｏｎ要素と呼ばれる、要素：
ｉ．メイン映像内の対象ピクチャ・イン・ピクチャ領域の左上符号化ビデオピクセル（サンプル）の水平位置を指定する＠ｘ属性。単位はビデオピクセル（サンプル）である，
ｉｉ．メイン映像内の対象ピクチャ・イン・ピクチャ領域の左上符号化ビデオピクセル（サンプル）の垂直位置を指定する＠ｙ属性。単位はビデオピクセル（サンプル）である，
ｉｉｉ．メイン映像内の対象ピクチャ・イン・ピクチャ領域の幅を指定する＠ｗｉｄｈｔｈ属性。単位はビデオピクセル（サンプル）である，
ｉｖ．メイン映像内の対象ピクチャ・イン・ピクチャ領域の高さを指定する＠ｈｅｉｇｈｔ属性。単位はビデオピクセル（サンプル）である。

以下は、上述された例に対応するいくつかの例示的な実施形態である。実施形態はＤＡＳＨに適用可能である。以下のシンタックス及び／又はセマンティクスにおいて追加又は変更されている最も関連する部分は、イタリック体で示されている。本質的に編集的であって、故に強調表示されていないいくつかの追加の他の変更があり得る。

事前選択要素のセマンティクスが提供される。事前選択記述子に代わるものとして、事前選択はまた、表２５で提供される事前選択要素により定義されてもよい。事前選択の選択は、事前選択要素に含まれている属性及び要素に基づく。

拡張可能マークアップ言語（Extensible Markup Language，ＸＭＬ）シンタックスが提供される。

事前選択に基づいたピクチャ・イン・ピクチャ。

事前選択要素のセマンティクスは他の実施形態で提供される。事前選択記述子に代わるものとして、事前選択はまた、表２５で提供される事前選択要素により定義されてもよい。事前選択の選択は、事前選択要素に含まれている属性及び要素に基づく。

ＸＭＬシンタックスが供給される。

事前選択に基づいたピクチャ・イン・ピクチャ。

図６は、本明細書で開示されている様々な技術が実装され得る例示的なビデオ処理システム６００を示すブロック図である。様々な実施は、ビデオ処理システム６００のコンポーネントのいくつか又は全てを含み得る。ビデオ処理システム６００は、ビデオコンテンツを受ける入力部６０２を含み得る。ビデオコンテンツは、生の又は圧縮されていないフォーマット、例えば、８又は１０ビットのマルチコンポーネントピクセル値で受け取られてよく、あるいは、圧縮又は符号化されたフォーマットにあってもよい。入力部６０２は、ネットワークインターフェース、ペリフェラルバスインターバス、又はストレージインターフェースに相当し得る。ネットワークインターフェースの例には、Ｅｔｈｅｒｎｅｔ（登録商標）、受動光ネットワーク（Passive Optical Network，ＰＯＮ）などのような無線インターフェース、及びＷｉ－Ｆｉ又はセルラーネットワークなどの無線インターフェースが含まれる。

ビデオ処理システム６００は、本明細書で記載されている様々なコーディング又は符号化方法を実装し得るコーディングコンポーネント６０４を含んでもよい。コーディングコンポーネント６０４は、ビデオのコーディングされた表現を生成するよう、入力部６０２からコーディングコンポーネント６０４の出力部へのビデオの平均ビットレートを低減し得る。コーディング技術は、従って、ビデオ圧縮又はビデオトランスコーディング技術と時々呼ばれる。コーディングコンポーネント６０４の出力は、コンポーネント６０６によって表されるように、保存されても、あるいは、接続された通信を介して伝送されてもよい。入力部６０２で受け取られたビデオの保存又は通信されたビットストリーム（又はコーディングされた）表現は、ピクセル値又は表示インターフェース６１０へ送られる表示可能なビデオを生成するコンポーネント６０８によって使用されてもよい。ユーザが見ることができるビデオをビットストリーム表現から生成するプロセスは、ビデオ圧縮解除と時々呼ばれる。更に、特定のビデオ処理動作が「コーディング」動作又はツールと呼ばれる一方で、そのようなコーディングツール又は動作はエンコーダで使用され、コーディングの結果を入れ替える対応する復号化ツール又は動作は、デコーダによって実行されることになることが理解されるだろう。

ペリフェラルバスインターフェース又は表示インターフェースの例には、ユニバーサルシリアルバス（ＵＳＢ）又は高精細マルチメディアインターフェース（ＨＤＭＩ（登録商標））又はＤｉｓｐｌａｙｐｏｒｔ（登録商標）などが含まれ得る。ストレージインターフェースの例には、ＳＡＴＡ（Serial Advanced Technology Attachment）、ＰＣＩ（Peripheral Component Interconnect）、ＩＤＥ（Integrated Drive Electronics）インターフェース、などがある。本明細書で説明されている技術は、携帯電話機、ラップトップ、スマートフォン、あるいは、デジタルデータ処理及び／又はビデオ表示を実行する能力がある他のデバイスなどの、様々な電子デバイスで具現化されてもよい。

図７は、ビデオ処理装置７００のブロック図である。ビデオ処理装置７００は、本明細書で記載されている方法の１つ以上を実装するために使用され得る。ビデオ処理装置７００は、スマートフォン、タブレット、コンピュータ、インターネット・オブ・シングス（ＩｏＴ）レシーバ、などで具現化されてもよい。ビデオ処理装置７００は、１つ以上のプロセッサ７０２、１つ以上のメモリ７０４、及びビデオ処理ハードウェア７０６（別名、ビデオ処理回路）を含み得る。プロセッサ７０２は、本明細書で記載される１つ以上の方法を実装するよう構成され得る。メモリ（複数のメモリ）７０４は、本明細書で記載される方法及び技術を実装するために使用されるデータ及びコードを記憶するために使用され得る。ビデオ処理ハードウェア７０６は、ハードウェア回路において、本明細書で記載されるいくつかの技術を実装するために使用され得る。いくつかの実施形態において、ビデオ処理ハードウェア７０６は、部分的に全体的に、プロセッサ７０２、例えば、グラフィクスプロセッサの中に位置してもよい。

図８は、本開示の技術を利用し得るビデオコーディングシステム８００の例を表すブロック図である。図８に示されるように、ビデオコーディングシステム８００は、送信元デバイス８１０及び送信先デバイス８２０を含んでよい。送信元デバイス８１０は、符号化されたビデオデータを生成し、ビデオ符号化と呼ばれ得る。送信先デバイス８２０は、送信元デバイス８１０によって生成された符号化されたビデオデータを復号することができ、ビデオ復号化デバイスと呼ばれ得る。

送信元デバイス８１０は、ビデオソース８１２、ビデオエンコーダ８１４、及び入力／出力（Ｉ／Ｏ）インターフェース８１６を含んでよい。

ビデオソース８１２は、ビデオ捕捉デバイスなどのソース、ビデオコンテンツプロバイダからビデオデータを受け取るインターフェース、及び／又はビデオデータを生成するコンピュータグラフィクスシステム、あるいは、そのようなソースの組み合わせを含んでよい。ビデオデータは１つ以上のピクチャを有してもよい。ビデオエンコーダ８１４は、ビットストリームを生成するようビデオソース８１２からのビデオデータを符号化する。ビットストリームは、ビデオデータのコーディングされた表現を形成するビットの連続を含んでよい。ビットストリームは、コーディングされたピクチャ及び関連するデータを含んでもよい。コーディングされたピクチャは、ピクチャのコーディングされた表現である。関連するデータは、シーケンスパラメータセット、ピクチャパラメータセット、及び他のシンタックス構造を含んでもよい。Ｉ／Ｏインターフェース８１６は、変調器／復調器（モデム）及び／又は送信器を含んでよい。符号化されたビデオデータは、Ｉ／Ｏインターフェース８１６を介して送信先デバイス８２０に対してネットワーク８３０を通じて直接に伝送されてよい。符号化されたビデオデータはまた、送信先デバイス８２０によるアクセスのために記憶媒体／サーバ８４０に記憶されてもよい。

送信先デバイス８２０は、Ｉ／Ｏインターフェース８２６、ビデオデコーダ８２４、及び表示デバイス８２２を含んでよい。

Ｉ／Ｏインターフェース８２６は、受信器及び／又はモデムを含んでよい。Ｉ／Ｏインターフェース８２６は、送信元デバイス８１０又は記憶媒体／サーバ８４０から符号化されたビデオデータを取得してよい。ビデオデコーダ８２４は、符号化されたビデオデータを復号してよい。表示デバイス８２２は、復号されたビデオデータをユーザに表示してよい。表示デバイス８２２は、送信先デバイス８２０と一体化されてもよく、あるいは、外付け表示デバイスとインターフェース接続するよう構成されて送信先デバイス８２０の外にあってもよい。

ビデオエンコーダ８１４及びビデオデコーダ８２４は、ＨＥＶＣ（High Efficiency Video Coding）標準規格、ＶＶＣ（Versatile Video Coding）標準規格、並びに他の現在の及び／又は更なる標準規格などのビデオ圧縮規格に従って作動してもよい。

図９は、ビデオエンコーダ９００の例を表すブロックであり、図８に表されているビデオコーディングシステム８００のビデオエンコーダ８１４であってよい。

ビデオエンコーダ９００は、本開示の技術のいずれか又は全てを実行するよう構成されてよい。図９の例では、ビデオエンコーダ９００は、複数の機能コンポーネントを含む。本開示で記載される技術は、ビデオエンコーダ９００の様々なコンポーネントの間で共有されてもよい。いくつかの例では、プロセッサが、本開示で記載される技術のいずれか又は全てを実行するよう構成されてもよい。

ビデオエンコーダ９００の機能コンポーネントは、パーティションユニット９０１と、モード選択ユニット９０３、動き推定ユニット９０４、動き補償ユニット９０５及びイントラ予測ユニット９０６を含み得る予測ユニット９０２と、残差生成ユニット９０７と、変換ユニット９０８と、量子化ユニット９０９と、逆量子化ユニット９１０と、逆変換ユニット９１１と、再構成ユニット９１２と、バッファ９１３と、エントロピ符号化ユニット９１４とを含んでよい。

他の例では、ビデオエンコーダ９００は、より多い、より少ない、又は異なる機能コンポーネントを含んでもよい。例において、予測ユニット９０２は、イントラブロックコピー（Intra Block Copy，ＩＢＣ）ユニットを含んでもよい。ＩＢＣユニットは、少なくとも１つの参照ピクチャが、現在のビデオブロックが位置しているピクチャであるところの、ＩＢＣモードで、予測を実行してよい。

更に、動き推定ユニット９０４及び動き補償ユニット９０５などのいくつかのコンポーネントは、高度に集積されてもよいが、説明のために図９の例では別々に表されている。

パーティションユニット９０１は、ピクチャを１つ以上のビデオブロックにパーティション化し得る。図８のビデオエンコーダ８１４及びビデオデコーダ８２４は、様々なビデオブロックサイズをサポートしてよい。

モード選択ユニット９０３は、例えば、エラー結果に基づいて、イントラ又はインターのコーディングモードの１つを選択し、結果として得られたイントラ又はインターコーディングされたブロックを、残差ブロックデータを生成する残差生成ユニット９０７へ、及び参照ピクチャとしての使用のために、符号化されたブロックを再構成する再構成ユニット９１２へ供給してよい。いくつかの例において、モード選択ユニット９０３は、予測がインター予測信号及びイントラ予測信号に基づくイントラ－インター複合予測（Combination of Intra and Inter Prediction，ＣＩＩＰ）モードを選択してもよい。モード選択ユニット９０３はまた、インター予測の場合に、ブロックの動きベクトルのための分解能（例えば、サブピクセル又は整数ピクセル精度）を選択してもよい。

現在のビデオブロックに対してインター予測を実行するために、動き推定ユニット９０４は、バッファ９１３からの１つ以上の参照フレームを現在のビデオブロックと比較することによって、現在のビデオブロックの動き情報を生成し得る。動き補償ユニット９０５は、動き情報と、現在のビデオブロックに関連したピクチャ以外のバッファ９１３からのピクチャの復号されたサンプルとに基づいて、現在のビデオブロックの予測されたビデオブロックを決定し得る。

動き推定ユニット９０４及び動き補償ユニット９０５は、例えば、現在のビデオブロックがＩスライス、Ｐスライス、又はＢスライスであるかどうかに応じて、現在のビデオブロックのために異なる動作を実行してもよい。Ｉスライス（又はＩフレーム）は、圧縮率が最も低くなるもの、復号するために他のビデオフレームを必要としない。Ｐスライス（又はＰフレーム）は、圧縮解除するために前のフレームからのデータを使用することができ、Ｉフレームよりも圧縮率が高い。Ｂスライス（又はＢフレーム）は、最も高いデータ圧縮量を得るように、データ参照のために前のフレーム及び次のフレームの両方を使用することができる。

いくつかの例において、動き推定ユニット９０４は、現在のビデオブロックのために一方向予測を実行してもよく、動き推定ユニット９０４は、現在のビデオブロックのための参照ビデオブロックをリスト０又はリスト１の参照ピクチャから探してもよい。動き推定ユニット９０４は、次いで、参照ビデオブロックを含むリスト０又はリスト１内の参照ピクチャを示す参照インデックスと、現在のビデオブロックと参照ビデオブロックとの間の空間変位を示す動きベクトルとを生成してよい。動き推定ユニット９０４は、現在のビデオブロックの動き情報として参照インデックス、予測方向インジケータ、及び動きベクトルを出力してもよい。動き補償ユニット９０５は、現在のビデオブロックの動き情報によって示されている参照ビデオブロックに基づいて、現在のブロックの予測されたビデオブロックを生成してもよい。

他の例では、動き推定ユニット９０４は、現在のビデオブロックのために双方向予測を実行してもよく、動き推定ユニット９０４は、現在のビデオブロックのための参照ビデオブロックをリスト０内の参照ピクチャから探してもよく、また、現在のビデオブロックのためのもう１つの参照ビデオブロックをリスト１内の参照ピクチャから探してもよい。動き推定ユニット９０４は、次いで、参照ビデオブロックを含むリスト０及びリスト１内の参照ピクチャを示す参照インデックスと、それらの参照ビデオブロックと現在のビデオブロックとの間の空間変位を示す動きベクトルとを生成してもよい。動き推定ユニット９０４は、現在のビデオブロックの動き情報として、現在のビデオブロックの参照インデックス及び動きベクトルを出力してもよい。動き補償ユニット９０５は、現在のビデオブロックの動き情報によって示されている参照ビデオブロックに基づいて、現在のビデオブロックの予測されたビデオブロックを生成してもよい。

いくつかの例において、動き推定ユニット９０４は、デコーダの復号化処理のために動き情報のフルセットを出力してもよい。

いくつかの例において、動き推定ユニット９０４は、現在のビデオの動き情報のフルセットを出力しなくてもよい。むしろ、動き推定ユニット９０４は、他のビデオブロックの動き情報を参照して現在のビデオブロックの動き情報をシグナリングしてもよい。例えば、動き推定ユニット９０４は、現在のビデオブロックの動き情報が隣接ビデオブロックの動き情報と十分に類似していることを決定してもよい。

一例において、動き推定ユニット９０４は、現在のビデオブロックに関連したシンタックス構造において、現在のビデオブロックが他のビデオブロックと同じ動き情報を有していることをビデオデコーダ８２４に示す値を示してもよい。

他の例では、動き推定ユニット９０４は、現在のビデオブロックに関連したシンタックス構造において、他のビデオブロック及び動きベクトル差分（Motion Vector Difference，ＭＶＤ）を特定してもよい。動きベクトル差分は、現在のビデオブロックの動きベクトルと、指示されたビデオブロックの動きベクトルとの間の差を示す。ビデオデコーダ８２４は、現在のビデオブロックの動きベクトルを決定するために、指示されたビデオブロックの動きベクトル及び動きベクトル差分を使用し得る。

上述されたように、ビデオエンコーダ８１４は、動きベクトルを予測的にシグナリングしてもよい。ビデオエンコーダ８１４によって実装され得る予測シグナリング技術の２つの例には、アドバンスド動きベクトル予測（Advanced Motion Vector Prediction，ＡＭＶＰ）及びマージモードシグナリングがある。

イントラ予測ユニット９０６は、現在のビデオブロックに対してイントラ予測を実行してよい。イントラ予測ユニット９０６が現在のビデオブロックに対してイントラ予測を実行する場合に、イントラ予測ユニット９０６は、同じピクチャ内の他のビデオブロックの復号されたサンプルに基づいて、現在のビデオブロックの予測データを生成し得る。現在のビデオブロックの予測データは、予測されたビデオブロック及び様々なシンタックス要素を含み得る。

残差生成ユニット９０７は、現在のビデオブロックから現在のビデオブロックの予測されたビデオブロックを減じること（例えば、マイナス符号によって示される）によって、現在のビデオブロックの残差データを生成してよい。現在のビデオブロックの残差データは、現在のビデオブロック内のサンプルの異なるサンプルコンポーネントに対応する残差ビデオブロックを含み得る。

他の例では、例えば、スキップモードで、現在のビデオブロックの残差データは存在しない場合があり、残差生成ユニット９０７は、減算演算を実行しなくてもよい。

変換処理ユニット９０８は、現在のビデオブロックに関連した残差ビデオブロックに１つ以上の変換を適用することによって、現在のビデオブロックの１つ以上の変換係数ビデオブロックを生成してよい。

変換処理ユニット９０８が現在のビデオブロックに関連した変換係数ビデオブロックを生成した後、量子化ユニット９０９は、現在のビデオブロックに関連した１つ以上の量子化パラメータ（ＱＰ）値に基づいて、現在のビデオブロックに関連した変換係数ビデオブロックを量子化してよい。

逆量子化ユニット９１０及び逆変換ユニット９１１は、変換係数ビデオブロックに各々逆量子化及び逆変換を適用して、変換係数ビデオブロックから残差ビデオブロックを再構成してよい。再構成ユニット９１２は、再構成された残差ビデオブロックを、予測ユニット９０２によって生成された１つ以上の予測されたビデオブロックからの対応するサンプルに加えて、バッファ９１３での記憶のために、現在のブロックに関連した再構成されたビデオブロックを生成してよい。

再構成ユニット９１２がビデオブロックを再構成した後、ループフィルタリング動作が、ビデオブロックにおいてビデオブロッキングアーチファクトを低減するよう実行されてもよい。

エントロピ符号化ユニット９１４は、ビデオエンコーダ９００の他の機能コンポーネントからデータを受け取ってもよい。エントロピ符号化ユニット９１４がデータを受け取るとき、エントロピ符号化ユニット９１４は、エントロピ符号化されたデータを生成するよう１つ以上のエントロピ符号化動作を実行し、そのエントロピ符号化されたデータを含むビットストリームを出力し得る。

図１０は、ビデオデコーダ１０００の例を表すブロック図であり、図８で表されているビデオコーディングシステム８００のビデオデコーダ８２４であってよい。

ビデオデコーダ１０００は、本開示の技術のいずれか又は全てを実行するよう構成されてよい。図１０の例では、ビデオデコーダ１０００は、複数の機能コンポーネントを含む。本開示で記載される技術は、ビデオデコーダ１０００の様々なコンポーネントの間で共有されてもよい。いくつかの例では、プロセッサが、本開示で記載される技術のいずれか又は全てを実行するよう構成されてもよい。

図１０の例では、ビデオデコーダ１０００は、エントロピ復号化ユニット１００１と、動き補償ユニット１００２と、イントラ予測ユニット１００３と、逆量子化ユニット１００４と、逆変換ユニット１００５と、再構成ユニット１００６と、バッファ１００７とを含む。ビデオデコーダ１０００は、いくつかの例において、ビデオエンコーダ８１４（図８）に関して記載された符号化パスとは概して逆の復号化パスを実行してもよい。

エントロピ復号化ユニット１００１は、符号化されたビットストリームを取り出し得る。符号化されたビットストリームは、エントロピコーディングされたビデオデータ（例えば、ビデオデータの符号化されたブロック）を含んでもよい。エントロピ復号化ユニット１００１は、エントロピコーディングされたビデオデータを復号してよく、エントロピ復号されたビデオデータから、動き補償ユニット１００２は、動きベクトル、動きベクトル精度、参照ピクチャリストインデックス、及び他の動き情報を含む動き情報を決定し得る。動き補償ユニット１００２は、例えば、ＡＭＶＰ及びマージモードを実行することによって、そのような情報を決定してよい。

動き補償ユニット１００２は、場合により、補間フィルタに基づいた補間を実行して、動き補償されたブロックを生成してよい。サブピクセル精度で使用される補間フィルタのための識別子が、シンタックス要素に含まれてもよい。

動き補償ユニット１００２は、参照ブロックのサブ整数ピクセルについて補間値を計算するために、ビデオブロックの符号化中にビデオエンコーダ８１４によって使用された補間フィルタを使用し得る。動き補償ユニット１００２は、受け取られたシンタックス情報に従って、ビデオエンコーダ８１４によって使用された補間フィルタを決定し、その補間フィルタを使用して、予測ブロックを生成し得る。

動き補償ユニット１００２は、符号化されたビデオシーケンスのフレーム及び／又はスライスを符号化するために使用されるブロックのサイズと、符号化されたビデオシーケンスのピクチャの各マクロブロックがどのようにパーティション化されるかを記述するパーティション情報と、各パーティションがどのように符号化されるかを示すモードと、各インター符号化されたブロックについての１つ以上の参照フレーム（及び参照フレームリスト）と、符号化されたビデオシーケンスを復号するための他の情報とを決定するために、シンタックス情報のいくつかを使用してもよい。

イントラ予測ユニット１００３は、空間的に隣接するブロックから予測ブロックを形成するよう、例えば、ビットストリームで受け取られたイントラ予測モードを使用してもよい。逆量子化ユニット１００４は、ビットストリームで供給されてエントロピ復号化ユニット１００１によって復号された量子化されたビデオブロック係数を逆量子化、すなわち、量子化解除する。逆変換ユニット１００５は逆変換を適用する。

再構成ユニット１００６は、動き補償ユニット１００２又はイントラ予測ユニット１００３によって生成された対応する予測ブロックを残差ブロックに加算して、復号されたブロックを形成し得る。望まれる場合には、デブロッキングフィルタも、ブロッキネスアーチファクトを取り除くために、復号されたブロックにフィルタをかけるよう適用されてもよい。復号されたビデオブロックは、次いで、バッファ１００７に格納され、バッファ１００７は、その後の動き補償／イントラ予測のために参照ブロックを供給し、更には、復号されたビデオを表示デバイスでの提示のために生成する。

図１１は、本開示の実施形態に係るメディアデータ処理方法１１００である。方法１１００は、プロセッサ及びメモリを備えているコーディング装置（例えば、エンコーダ）によって実行されてよい。方法１１００は、ピクチャ・イン・ピクチャサービスが指示される必要がある場合に実装されてよい。

ブロック１１０２で、コーディング装置は、メディアデータとメディアデータファイルとの間の変換のために、事前選択要素がインジケータを含むかどうかを決定する。実施形態において、インジケータは、メイン映像の対象ピクチャ・イン・ピクチャ領域を表すビデオデータユニットが補足映像の対応するビデオデータユニットで置換可能であることを示す。

ブロック１１０４で、コーディング装置は、インジケータに基づきメディアデータとメディアデータファイルとの間の変換を実行する。エンコーダで実装される場合に、変換は、メディアファイル（例えば、ビデオユニット）を受信し、メディアファイルをビットストリームに符号化することを含む。デコーダで実装される場合に、変換は、メディアファイルを含むビットストリームを受信し、ビットストリームを復号してメディアファイルを取得することを含む。

実施形態において、インジケータは、事前選択要素の属性を有する。実施形態において、インジケータは、＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅ属性を有する。

実施形態において、インジケータは、＠ｔａｇ属性が前記事前選択要素に存在する場合にのみ、事前選択要素に存在する。実施形態において、インジケータは、事前選択要素の目的が、補足映像がメイン映像内の対象ピクチャ・イン・ピクチャ領域にオーバーレイされるよう現れるピクチャ・イン・ピクチャ体験を提供するためである、ことを事前選択要素内の＠ｔａｇ属性が示す場合にのみ、事前選択要素に存在する。

実施形態において、方法は、事前選択要素がインジケータを含まないことを決定するステップを更に有する。実施形態において、メイン映像内の対象ピクチャ・イン・ピクチャ領域を表すビデオデータユニットを補足映像の対応するビデオデータユニットで置換することは、事前選択要素がインジケータを含まない場合に未知である。

実施形態において、インジケータは、真の値（例えば、１）を有している＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅ属性を有する。実施形態において、方法は、＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅ属性が真の値を有している場合に、メイン映像内の対象ピクチャ・イン・ピクチャ領域を表すビデオデータユニットを補足映像の対応するビデオデータユニットで置換することを選択することをクライアントに許すステップを更に有する。

実施形態において、方法は、＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅ属性が真の値を有している場合に、メイン映像内の対象ピクチャ・イン・ピクチャ領域を表すビデオデータユニットを補足映像の対応するビデオデータユニットで置換することを選択することをクライアントに許すことによって、メイン映像及び補足映像の別々の復号化を回避するステップを更に有する。

実施形態において、補足映像の対応するビデオデータユニットは、補足映像の表現における復号化時間同期サンプル内の全てのビデオデータユニットである。実施形態において、復号化時間同期サンプル内のビデオデータユニットは、メイン映像内の特定のピクチャに対応する。

実施形態において、事前選択要素は、ＰｉｃｎＰｉｃ要素を含む。実施形態において、インジケータは、＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅ属性を有し、ＰｉｃｎＰｉｃ要素が、＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅ属性を含む。

実施形態において、事前選択要素は、メディアプレゼンテーション記述（ＭＰＤ）ファイルに配置される。実施形態において、事前選択要素は、ハイパーテキスト転送プロトコル上の動的適応ストリーミング（ＤＡＳＨ）プレゼンテーション要素である。

実施形態において、変換は、メディアデータをビットストリームに符号化することを含む。実施形態において、変換は、メディアデータをビットストリームから復号することを含む。

実施形態において、方法１１００は、本明細書で開示されている他の方法の特徴又はプロセスのうちの１つ以上を利用しても又は組み込んでもよい。

いくつかの実施形態によって好ましい解決法のリストが、次に与えられる。

次の解決法は、本開示で説明されている技術の例示的な実施形態（例えば、例１）を示す。

解決法１．ビデオデータを処理する方法であって、
ビデオデータと該ビデオデータの記述子との間の変換を実行するステップを有し、
前記記述子はフォーマット規則に従い、
前記フォーマット規則は、前記記述子が、該記述子の事前選択シンタックス構造のピクチャ・イン・ピクチャ使用を示すシンタックス要素を含む、ことを指定する、
方法。

解決法２．解決法１に記載の方法であって、
前記シンタックス要素は、前記事前選択シンタックス構造のタグ属性である、
方法。

解決法３．解決法１に記載の方法であって、
前記シンタックス要素は、前記事前選択シンタックス構造の役割属性である、
方法。

解決法４．ビデオデータを処理する方法であって、
ビデオデータと該ビデオデータの記述子との間の変換を実行するステップを有し、
前記記述子はフォーマット規則に従い、
前記フォーマット規則は、前記記述子が、ピクチャ・イン・ピクチャ領域に対応する前記ビデオデータ内のメイン映像のビデオデータユニットが前記ビデオデータ内の補足映像のビデオデータユニットで置換可能であるかどうか、を示すシンタックス要素を選択的に含む、ことを指定する、
方法。

解決法５．解決法４に記載の方法であって、
前記シンタックス要素は、前記記述子内の属性フィールドである、
方法。

解決法６．解決法４に記載の方法であって、
前記シンタックス要素は、前記記述子内のタグ属性の値に基づき、選択的に含まれる、
方法。

解決法７．ビデオデータを処理する方法であって、
ビデオデータと該ビデオデータの記述子との間の変換を実行するステップを有し、
前記記述子はフォーマット規則に従い、
前記フォーマット規則は、前記記述子が、対象ピクチャ・イン・ピクチャ領域に対応する前記ビデオデータ内のメイン映像のピクチャ内のビデオデータユニットを示す領域識別子のリストを含む、ことを指定する、
方法。

解決法８．解決法７に記載の方法であって、
前記リストは、前記記述子内の事前選択シンタックス構造の属性として含まれる、
方法。

解決法９．解決法７又は８に記載の方法、
前記領域識別子は、前記メイン映像をコーディングするために使用されるコーディングスキームに従って前記ビデオデータユニットを示すために使用されるシンタックスフィールドに対応する、
方法。

解決法１０．ビデオデータを処理する方法であって、
ビデオデータと該ビデオデータの記述子との間の変換を実行するステップを有し、
前記記述子はフォーマット規則に従い、
前記フォーマット規則は、前記記述子が、補足映像をオーバーレイする又は埋め込むために使用されるメイン映像内の領域の位置及び／又はサイズの情報を示す１つ以上のフィールドを含む、ことを指定する、
方法。

解決法１１．解決法１０に記載の方法であって、
前記位置及び前記サイズの情報は、前記領域の位置座標、高さ及び幅を含む４つの値を有する、
方法。

解決法１２．解決法１０又は１１に記載の方法であって、
前記１つ以上のフィールドは、事前選択シンタックス構造の属性又は要素を有する、
方法。

解決法１３．解決法１０乃至１２のうちいずれかに記載の方法であって、
前記領域が正確な置換可能領域又は好ましい置換可能領域であるかどうかは、他のシンタックス要素に基づき決定される、
方法。

解決法１４．解決法１乃至１３のうちいずれかに記載の方法であって、
前記記述子は、メディアプレゼンテーション記述（ＭＰＤ）である、
方法。

解決法１５．解決法１乃至１４のうちいずれかに記載の方法であって、
前記フォーマット規則は、特定のシンタックス要素が前記記述子に含まれる、ことを指定し、
前記特定のシンタックス要素は、ピクチャ・イン・ピクチャ情報を含む、
方法。

解決法１６．解決法１乃至１５のうちいずれかに記載の方法であって、
前記変換は、ビデオからビットストリームを生成することを含む、
方法。

解決法１７．解決法１乃至１５のうちいずれかに記載の方法であって、
前記変換は、ビットストリームからビデオを生成することを含む、
方法。

解決法１８．解決法１乃至１７のうちの１つ以上に記載の方法を実装するよう構成されるプロセッサを有するビデオ復号化装置。

解決法１９．解決法１乃至１７のうちの１つ以上に記載の方法を実行するよう構成されるプロセッサを有するビデオ符号化装置。

解決法２０．プロセッサによって実行される場合に、該プロセッサに、解決法１乃至１７のうちいずれかに記載の方法を実装させるコンピュータコードを記憶しているコンピュータプログラム製品。

解決法２１．ビデオ処理の方法であって、
解決法１乃至１７のうちのいずれか１つ以上に記載の方法に従ってビットストリームを生成するステップと、
前記ビットストリームをコンピュータ可読媒体に記憶するステップと
を有する方法。

解決法２２．本明細書で記載される方法、装置、又はシステム。

次の文献は、それらの全文を参照により援用される：
[1] ITU-T and ISO/IEC, “High efficiency video coding”, Rec. ITU-T H.265 | ISO/IEC 23008-2 (in force edition)
[2] J. Chen, E. Alshina, G. J. Sullivan, J.-R. Ohm, J. Boyce, “Algorithm description of Joint Exploration Test Model 7 (JEM7),” JVET-G1001, Aug. 2017
[3] Rec. ITU-T H.266 | ISO/IEC 23090-3, “Versatile Video Coding”, 2020
[4] B. Bross, J. Chen, S. Liu, Y.-K. Wang (editors), “Versatile Video Coding (Draft 10),” JVET-S2001
[5] Rec. ITU-T Rec. H.274 | ISO/IEC 23002-7, “Versatile Supplemental Enhancement Information Messages for Coded Video Bitstreams”, 2020
[6] J. Boyce, V. Drugeon, G. Sullivan, Y.-K. Wang (editors), “Versatile supplemental enhancement information messages for coded video bitstreams (Draft 5),” JVET-S2007
[7] ISO/IEC 14496-12: "Information technology - Coding of audio-visual objects - Part 12: ISO base media file format"
[8] ISO/IEC 23009-1: "Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats"（ＤＡＳＨ標準規格仕様の第４版はＭＰＥＧ入力文書ｍ５２４５８で入手可能である。）
[9] ISO/IEC 14496-15: "Information technology - Coding of audio-visual objects - Part 15: Carriage of network abstraction layer (NAL) unit structured video in the ISO base media file format"
[10] ISO/IEC 23008-12: "Information technology - High efficiency coding and media delivery in heterogeneous environments - Part 12: Image File Format"
[11] ISO/IEC JTC 1/SC 29/WG 03 output document N0035, "Potential improvements on Carriage of VVC and EVC in ISOBMFF", Nov. 2020
[12] ISO/IEC JTC 1/SC 29/WG 03 output document 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)", Nov. 2020.

本明細書で記載されている開示された及び他の解決法、例、実施形態、モジュール、及び機能動作は、デジタル電子回路で、又は本明細書で開示されている構造及びそれらの構造的同等物を含むコンピュータソフトウェア、ファームウェア、若しくはハードウェアで、あるいは、それらの１つ以上の組み合わせで実装され得る。開示された及び他の実施形態は、１つ以上のコンピュータプログラム製品、つまり、データ処理装置によって実行されるか又はその動作を制御するコンピュータ可読媒体で符号化されているコンピュータプログラム命令の１つ以上のモジュール、として実装され得る。コンピュータ可読媒体は、マシン可読記憶デバイス、マシン可読記憶基板、メモリデバイス、マシン可読な伝播信号に影響を与える物質の組成、又はそれらの１つ以上の組み合わせであることができる。「データ処理装置」という用語は、例として、プログラム可能なプロセッサ、コンピュータ、又は複数のプロセッサ若しくはコンピュータを含む、データを処理するための全ての装置、デバイス、及びマシンを包含する。装置は、ハードウェアに加えて、問題となっているコンピュータプログラムのための実行環境を作り出すコード、例えば、プロセッサファームウェア、プロトコルスタック、データベース管理システム、オペレーティングシステム、又はそれらの１つ以上の組み合わせを構成するコードを含むことができる。伝播信号は、人工的に生成された信号、例えば、マシンで生成された電気、光、又は電磁気信号であり、適切な受信器装置への伝送のために情報を符号化するよう生成されている。

コンピュータプログラム（プログラム、ソフトウェア、ソフトウェアアプリケーション、スクリプト、又はコードとしても知られる。）は、コンパイル済み又は解釈済みの言語を含む如何なる形式のプログラミング言語でも記述可能であり、それは、スタンドアロンプログラムとして又はコンピューティング環境における使用に適したモジュール、コンポーネント、サブルーチン、若しくは他のユニットとして、を含め、如何なる形式でもデプロイ可能である。コンピュータプログラムは、必ずしもファイルシステムにおけるファイルに対応しない。プログラムは、問題となっているプログラムに専用の単一のファイルで、又は複数の協調したファイル（例えば、１つ以上のモジュール、サブプログラム、又はコードの部分を保存するファイル）で、他のプログラム又はデータ（例えば、マークアップ言語文書で保存された１つ以上のスクリプト）を保持するファイルの部分において保存可能である。コンピュータプログラムは、１つのコンピュータで、あるいは、１つの場所に位置しているか、又は複数の場所にわたって分布しており、通信ネットワークによって相互接続されている複数のコンピュータで、実行されるようデプロイ可能である。

本明細書で説明されているプロセス及びロジックフローは、入力データに作用して出力を生成することによって機能を実行するよう１つ以上のコンピュータプログラムを実行する１つ以上のプログラム可能なプロセッサによって実行可能である。プロセス及びロジックフローはまた、専用のロジック回路、例えば、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）又は特定用途向け集積回路（ＡＳＩＣ）によっても実行可能である。

コンピュータプログラムの実行に適したプロセッサは、例として、汎用のマイクロプロセッサ及び専用のマイクロプロセッサの両方、並びにあらゆる種類のデジタルコンピュータのいずれか１つ以上のプロセッサを含む。一般に、プロセッサは、リード・オンリー・メモリ若しくはランダム・アクセス・メモリ又はその両方から命令及びデータを受け取る。コンピュータの必須の要素は、命令を実行するプロセッサと、命令及びデータを保存する１つ以上のメモリデバイスとである。一般に、コンピュータはまた、データを保存する１つ以上の大容量記憶デバイス、例えば、磁気、光学磁気ディスク、又は光ディスクを含むか、あるいは、そのような１つ以上の大容量記憶デバイスからのデータの受信若しくはそれへのデータの転送又はその両方のために動作可能に結合される。しかし、コンピュータは、そのようなデバイスを有する必要はない。コンピュータプログラム命令及びデータを保存するのに適したコンピュータ可読媒体は、例として、半導体メモリデバイス、例えば、消去可能なプログラム可能リード・オンリー・メモリ（ＥＰＲＯＭ）、電気的消去可能なプログラム可能リード・オンリー・メモリ（ＥＥＰＲＯＭ）、及びフラッシュメモリデバイス；磁気ディスク、例えば、内蔵ハードディスク又はリムーバブルディスク；光学磁気ディスク；並びにコンパクト・ディスク型リード・オンリー・メモリ（ＣＤＲＯＭ）及びデジタル・バーサタイル・ディスク型リード・オンリー・メモリ（ＤＶＤ－ＲＯＭ）ディスクを含む全ての形式の不揮発性メモリ、媒体及びメモリデバイスを含む。プロセッサ及びメモリは、専用のロジック回路によって強化されるか、あるいは、それに組み込まれ得る。

本明細書は、多数の詳細を含むが、それらは、あらゆる対象の又は請求される可能性があるものの範囲に対する限定としてではなく、むしろ、特定の技術の特定の実施形態に特有であり得る特徴の説明として解釈されるべきである。別々の実施形態に関連して本明細書で説明されている特定の特徴は、単一の実施形態と組み合わせても実装可能である。逆に、単一の実施形態に関連して説明されている様々な特徴はまた、複数の実施形態で別々に、又は何らかの適切なサブコンビネーションで実装可能である。更に、特徴は、特定の組み合わせで動作するものとして先に説明され、更には、そのようなものとして最初に請求されることがあるが、請求されている組み合わせからの１つ以上の特徴は、いくつかの場合に、その組み合わせから削除可能であり、請求されている組み合わせは、サブコンビネーション又はサブコンビネーションの変形に向けられてもよい。

同様に、動作は、特定の順序で図面において表されているが、これは、所望の結果を達成するために、そのような動作が示されているその特定の順序で又は順次的な順序で実行されること、あるいは、表されている全ての動作が実行されることを求めている、と理解されるべきではない。更に、本明細書で説明されている実施形態における様々なシステムコンポーネントの分離は、全ての実施形態でそのような分離を求めている、と理解されるべきではない。

ほんのわずかの実施及び例が説明されており、他の実施、強化及び変形は、本特許文献で記載及び例示されているものに基づいて行われ得る。

１００ＭＰＤ
２００ピクチャ
２０２タイル
２０４サブピクチャ／スライス
２０６ＣＴＵにパーティション
６００ビデオ処理システム
６０２入力部
６０４コーディングコンポーネント
７００ビデオ処理装置
７０２プロセッサ
７０４メモリ
７０６ビデオ処理ハードウェア
８００ビデオコーディングシステム
８１０送信元デバイス
８１２ビデオソース
８１４，９００ビデオエンコーダ
８１６，８２６Ｉ／Ｏインターフェース
８２０送信先デバイス
８２２表示デバイス
８２４，１０００ビデオデコーダ
８３０ネットワーク
８４０記憶媒体／サーバ
９０１パーティションユニット
９０２予測ユニット
９０３モード選択ユニット
９０４動き推定ユニット
９０５動き補償ユニット
９０６イントラ予測ユニット
９０７残差生成ユニット
９０８変換ユニット
９０９量子化ユニット
９１０逆量子化ユニット
９１１逆変換ユニット
９１２再構成ユニット
９１３，１００７バッファ
９１４エントロピ符号化ユニット
１００１エントロピ復号化ユニット
１００２動き補償ユニット
１００３イントラ予測ユニット
１００４逆量子化ユニット
１００５逆変換ユニット
１００６再構成ユニット

Claims

メディアデータを処理する方法であって、
映像である前記メディアデータとハイパーテキスト転送プロトコル上の動的適応ストリーミング（ＤＡＳＨ）のためのメディアデータファイルとの間の変換のために、事前選択要素がインジケータを含むかどうかを決定するステップであり、前記インジケータは、前記メディアデータのメイン映像の対象ピクチャ・イン・ピクチャ領域を表すビデオデータユニットが前記メディアデータの補足映像の対応するビデオデータユニットで置換可能であることを示す、ステップと、
前記インジケータに基づき前記メディアデータと前記メディアデータファイルとの間の前記変換を実行するステップと
を有し、
前記インジケータは、前記事前選択要素の属性を含む、方法。
前記インジケータは、＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅ属性を有する、
請求項１に記載の方法。
前記インジケータは、＠ｔａｇ属性が前記事前選択要素に存在する場合にのみ、前記事前選択要素に存在する、
請求項１に記載の方法。
前記インジケータは、前記事前選択要素の目的が、前記補足映像が前記メイン映像内の前記対象ピクチャ・イン・ピクチャ領域に視覚的にオーバーレイされるピクチャ・イン・ピクチャ体験を提供するためである、ことを前記事前選択要素内の＠ｔａｇ属性が示す場合にのみ、前記事前選択要素に存在する、
請求項１に記載の方法。
前記事前選択要素が前記インジケータを含まないことを決定するステップを更に有する、
請求項１に記載の方法。
前記メイン映像内の前記対象ピクチャ・イン・ピクチャ領域を表す前記ビデオデータユニットを前記補足映像の前記対応するビデオデータユニットで置換することは、前記事前選択要素が前記インジケータを含まない場合に未知である、
請求項５に記載の方法。
前記インジケータは、真の値を有している＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅ属性を有する、
請求項１に記載の方法。
前記＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅ属性が前記真の値を有している場合に、前記メイン映像内の前記対象ピクチャ・イン・ピクチャ領域を表す前記ビデオデータユニットを前記補足映像の前記対応するビデオデータユニットで置換することを選択することをクライアントに許すステップを更に有する、
請求項７に記載の方法。
前記＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅ属性が前記真の値を有している場合に、前記メイン映像内の前記対象ピクチャ・イン・ピクチャ領域を表す前記ビデオデータユニットを前記補足映像の前記対応するビデオデータユニットで置換することを選択することをクライアントに許すことによって、前記メイン映像及び前記補足映像の別々の復号化を回避するステップを更に有する、
請求項７に記載の方法。
前記補足映像の前記対応するビデオデータユニットは、前記補足映像の表現における復号化時間同期サンプル内の全てのビデオデータユニットである、
請求項１に記載の方法。
前記復号化時間同期サンプル内のビデオデータユニットは、前記メイン映像内の特定のピクチャに対応する、
請求項１０に記載の方法。
前記事前選択要素は、ＰｉｃｉｎＰｉｃ要素を含む、
請求項１に記載の方法。
前記インジケータは、＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅ属性を有し、
前記ＰｉｃｉｎＰｉｃ要素が、前記＠ｄａｔａＵｎｉｔｓＲｅｐｌａｃｅａｂｌｅ属性を含む、
請求項１２に記載の方法。
前記事前選択要素は、メディアプレゼンテーション記述（ＭＰＤ）ファイルに配置される、
請求項１に記載の方法。
前記事前選択要素は、ＤＡＳＨプレゼンテーション要素である、
請求項１に記載の方法。
前記変換は、前記メディアデータを前記メディアデータファイルに符号化することを含む、
請求項１乃至１５のうちいずれか一項に記載の方法。
前記変換は、前記メディアデータを前記メディアデータファイルから復号することを含む、
請求項１乃至１５のうちいずれか一項に記載の方法。
メディアデータを処理する装置であって、
プロセッサと、命令を有する非一時的なメモリとを有し、
前記命令は、前記プロセッサによる実行時に、前記プロセッサに、
映像である前記メディアデータとハイパーテキスト転送プロトコル上の動的適応ストリーミング（ＤＡＳＨ）のためのメディアデータファイルとの間の変換のために、事前選択要素がインジケータを含むかどうかを決定するステップであり、前記インジケータは、前記メディアデータのメイン映像の対象ピクチャ・イン・ピクチャ領域を表すビデオデータユニットが前記メディアデータの補足映像の対応するビデオデータユニットで置換可能であることを示す、ステップと、
前記インジケータに基づき前記メディアデータと前記メディアデータファイルとの間の前記変換を実行するステップと
を実行させ、
前記インジケータは、前記事前選択要素の属性を含む、
装置。
ハイパーテキスト転送プロトコル上の動的適応ストリーミング（ＤＡＳＨ）のためのメディアデータファイルを記憶する方法であって、
映像であるメディアデータについて、事前選択要素がインジケータを含むかどうかを決定するステップであり、前記インジケータは、前記メディアデータのメイン映像の対象ピクチャ・イン・ピクチャ領域を表すビデオデータユニットが前記メディアデータの補足映像の対応するビデオデータユニットで置換可能であることを示す、ステップと、
前記インジケータに基づき前記メディアデータファイルを生成するステップと、
前記メディアデータファイルを非一時的なコンピュータ可読記録媒体に記憶するステップと
を有し、
前記インジケータは、前記事前選択要素の属性を含む、
方法。