ホーム > 特許ランキング > ＢＹＴＥＤＡＮＣＥ ＩＮＣ．
知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-09-20
(54)【発明の名称】ビデオ処理ための方法、装置、および媒体
(51)【国際特許分類】
H04N 21/84 20110101AFI20240912BHJP
H04N 21/845 20110101ALI20240912BHJP
【ＦＩ】
H04N21/84
H04N21/845
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024519069
(86)(22)【出願日】2022-09-26
(85)【翻訳文提出日】2024-03-27
(86)【国際出願番号】 US2022077042
(87)【国際公開番号】W WO2023049910
(87)【国際公開日】2023-03-30
(31)【優先権主張番号】63/248,832
(32)【優先日】2021-09-27
(33)【優先権主張国・地域又は機関】US
(81)【指定国・地域】
(71)【出願人】
【識別番号】520477474
【氏名又は名称】バイトダンス インコーポレイテッド
【氏名又は名称原語表記】ＢＹＴＥＤＡＮＣＥ ＩＮＣ．
【住所又は居所原語表記】１２６５５ Ｗｅｓｔ Ｊｅｆｆｅｒｓｏｎ Ｂｏｕｌｅｖａｒｄ， Ｓｉｘｔｈ Ｆｌｏｏｒ， Ｓｕｉｔｅ Ｎｏ． １３７ Ｌｏｓ Ａｎｇｅｌｅｓ， Ｃａｌｉｆｏｒｎｉａ ９００６６ Ｕｎｉｔｅｄ Ｓｔａｔｅｓ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100229448
【弁理士】
【氏名又は名称】中槇 利明
(72)【発明者】
【氏名】ワン，イエ－クォイ
【テーマコード（参考）】
5C164
【Ｆターム（参考）】
5C164MA02S
5C164MB13P
5C164MB41P
5C164UB85S
(57)【要約】
本開示の実施形態は、ビデオ処理のための解決策を提供する。第１のビデオのメディアファイルと前記第１のビデオのビットストリームとの間の変換を実行するステップを含みビデオ処理のための方法であって、前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を備える方法、ビデオ処理方法。提案される方法は、有利なことに、ＩＳＯベースメディアファイル形式(ＩＳＯＢＭＦＦ)に基づくメディアファイルにおいてピクチャインピクチャサービスをサポートすることを可能にする。
【特許請求の範囲】
【請求項1】
第１のビデオのメディアファイルと前記第１のビデオのビットストリームとの間の変換を実行するステップを含み、前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、ビデオ処理方法。
【請求項2】
前記指示は、第１のタイプのトラックリファレンスを含む、請求項１に記載の方法。
【請求項3】
第１のビデオの空間解像度が第２のビデオの空間解像度よりも小さく、前記第１のタイプのトラックリファレンスが「ｐｉｐｍ」トラックリファレンスである、請求項２に記載の方法。
【請求項4】
前記第２のビデオの空間解像度が前記第１のビデオの空間解像度よりも小さく、前記第１のタイプのトラックリファレンスが「ｐｉｐｓ」トラックリファレンスである、請求項２に記載の方法。
【請求項5】
前記トラックリファレンスは、前記第２のトラックを指示する、請求項２～４のいずれか１項に記載の方法。
【請求項6】
前記第２のビデオのメディアファイルは、第２のタイプのトラックリファレンスを含み、前記第２のタイプのトラックリファレンスは、前記第１のトラックと第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを指示する、請求項２～５のいずれか１項に記載の方法。
【請求項7】
前記変換は、前記メディアファイルを生成して前記ビットストリームを前記メディアファイルに記憶することを含む、請求項１～６のいずれか１項に記載の方法。
【請求項8】
前記変換は、前記メディアファイルを解析して前記ビットストリームを再構築することを含む、請求項１～６のいずれか１項に記載の方法。
【請求項9】
プロセッサと、命令を有する非一時的なメモリとを備え、前記命令が前記プロセッサによって実行されると、前記プロセッサに、請求項１～８のいずれか１項に記載の方法を実行させる、ビデオデータを処理するための装置。
【請求項10】
プロセッサに請求項１～８のいずれか１項に記載の方法を実行させる命令を記憶する非一時的なコンピュータ可読記憶媒体。
【請求項11】
ビデオ処理装置によって実行される方法によって生成された第１のビデオのビットストリームを記憶し、前記方法は、前記第１のビデオのメディアファイルと前記ビットストリームとの間の変換を実行するステップを含み、
前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、非一時的なコンピュータ可読記録媒体。
【請求項12】
第１のビデオのビットストリームを記憶するための方法であって、前記第１のビデオのメディアファイルと前記ビットストリームとの間の変換を実行するステップと、
前記ビットストリームを非一時的なコンピュータ可読記録媒体に記憶するステップと、を含み、
前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、方法。
【請求項13】
ビデオ処理装置によって実行される方法によって生成される第１のビデオのメディアファイルを記憶し、前記方法は、前記メディアファイルと前記第１のビデオのビットストリームとの間の変換を実行するステップを含み、
前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、非一時的なコンピュータ可読記録媒体。
【請求項14】
第１のビデオのメディアファイルを記憶するための方法であって、前記メディアファイルと前記第１のビデオのビットストリームとの間の変換を実行するステップと、
前記メディアファイルを非一時的なコンピュータ可読記録媒体に記憶するステップを含み、
前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、方法。
【発明の詳細な説明】
【技術分野】
【0001】
［関連出願の相互参照］
本出願は、２０２１年９月２７日に出願されたその米国仮特許出願第６３/２４８,８３２号に基づく優先権を主張するものであり、この米国出願の開示内容は、その全てを本明細書に組み込むものとする。
本出願は、２０２１年９月２７日に出願されたその米国仮特許出願第６３/２４８,８３２号に基づく優先権を主張するものであり、この米国出願の開示内容は、その全てを本明細書に組み込むものとする。
【0002】
本開示の実施形態は、概して、ビデオ処理技術に関し、より詳細には、ピクチャインピクチャサポートのためのファイル形式設計に関する。
【背景技術】
【0003】
メディアストリーミングアプリケーションは、一般的に、ＩＰ、ＴＣＰ、およびＨＴＴＰトランスポート方法に基づいており、一般的に、ＩＳＯベースのメディアファイルフォーマット（ＩＳＯＢＭＦＦ）などのファイルフォーマットに依存する。そのようなストリーミングシステムの１つは、ＨＴＴＰ（ＤＡＳＨ）を介した動的適応ストリーミングである。ＤＡＳＨでは、マルチメディアコンテンツのビデオおよび/または音声データのための多重表現があり得、異なる表現が異なる符号化特性(たとえば、ビデオ符号化規格の異なるプロファイルまたはレベル、異なるビットレート、異なる空間解像度など)に対応してもよい。また、「ピクチャインピクチャ」と呼ばれる技術が提案されている。これにより、ピクチャインピクチャサービスをサポートするファイル形式について研究する価値がある。
【発明の概要】
【0004】
本開示の実施形態は、ビデオ処理のための解決策を提供する。
【0005】
第１の態様では、ビデオ処理のための方法であって、この方法は、第１のビデオのメディアファイルと第１のビデオのビットストリームとの間の変換を実行することを含む。前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する（carry：含む）第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、ビデオ処理方法。
【0006】
提案される方法によれば、２つのトラックがピクチャインピクチャサービスを提供するためのトラックペアであることを示すために指示が採用される。それによって、提案される方法は、有利なことに、ＩＳＯＢＭＦＦに基づくメディアファイル中のピクチャインピクチャサービスをサポートすることを可能にする。
【0007】
第２の態様では、ビデオデータを処理するための装置が提案される。プロセッサと、命令を有する非一時的なメモリとを含む、メディア・データを処理する装置であって、命令は、プロセッサによって実行されると、プロセッサに、本開示の第１の態様に従って方法を実行させる。
【0008】
第３の態様では、非一時的なコンピュータ可読記憶媒体が提案される。非一時的なコンピュータ可読記憶媒体は、本開示の第１の態様に記載の方法をプロセッサに実行させる命令を記憶する。
【0009】
第４の態様では、別の非一時的なコンピュータ可読記録媒体が提案される。メディア・データ処理装置によって実行される方法によって生成された第１のビデオのビットストリームを記憶している非一時的なコンピュータ可読記録媒体であって、前記方法は、第１のビデオのメディアファイルとビットストリームとの間の変換を実行することを含む。前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、ビデオ処理方法。
【0010】
第５の態様では、第１のビデオのビットストリームを記憶するための方法が提案される。前記方法は、第１のビデオのメディアファイルとビットストリームとの間の変換を実行するステップと、ビットストリームを非一時的なコンピュータ可読記録媒体に記憶させることを含む。前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、ビデオ処理方法。
【0011】
第６の態様では、別の非一時的なコンピュータ可読記録媒体が提案される。非一時的なコンピュータ可読記録媒体は、ビデオ処理装置によって実行される方法によって生成された第１のビデオのメディアファイルを記憶している。前記方法は、メディアファイルと第１のビデオのビットストリームとの間の変換を実行することを含む。前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、ビデオ処理方法。
【0012】
第７の態様では、第１のビデオのメディアファイルを記憶するための方法が提案される。前記方法は、メディアファイルと第１のビデオのビットストリームとの間の変換を実行するステップと、メディアファイルを非一時的なコンピュータ可読記録媒体に記憶するステップとを含む。前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、ビデオ処理方法。
【0013】
この発明の概要は、簡略な形で、詳細な説明においてさらに説明されるコンセプトの集まりを紹介するために記載されたものである。この要約は、請求項に記載された主題の本質的な特徴または要点を特定することを意図しておらず、特許請求される主題の範囲を限定するために使用されることを意図するものでもない。
【図面の簡単な説明】
【0014】
添付図面を参照する以下の詳細な説明を通して、本開示の例示的な実施形態の上記および他の目的、特徴、および利点がより明らかになるだろう。本開示の例示的な実施形態において、同一の符号を付された構成要素は、通常、同じ構成要素を指す。
【図1】本開示のいくつかの実施形態によるビデオ符号化システムのブロック図の一例を図示している。
【図2】本開示のいくつかの実施形態によるビデオ符号化装置を示すブロック図の第１の例を図示している。
【図3】本発明のいくつかの実施形態によるビデオ復号化装置を示すブロック図の一例を図示している。
【図4】１８個のタイル、２４個のスライス、および２４個のサブピクチャに区分されたピクチャを図示している。
【図5】典型的なサブピクチャベースのビューポート依存３６０°映像配信方式を図示している。
【図6】２つのサブピクチャおよび４つのスライスを含むビットストリームからの１つのサブピクチャの抽出を図示している。
【図7】ＶＶＣサブピクチャに基づくピクチャインピクチャサポートの一例を図示している。
【図8】本開示のいくつかの実施形態による、ビデオ処理のための方法のフローチャートを図示している。
【図9】本開示の様々な実施形態が実装され得るコンピューティング装置のブロック図を示している。 図面全体において同一または類似の参照番号は、通常、同一または類似の要素を指す。
【発明を実施するための形態】
【0015】
次に、いくつかの実施形態を参照して、本開示の原理を説明する。これらの実施形態は、説明のみを目的として記載されており、本開示の範囲に関していかなる制限も示唆することなく、当業者が本開示を理解し、実施するのに役立つことを理解されたい。本開示に記載の以下の形態以外にも様々な方法で実施されてもよい。
【0016】
以下の説明および特許請求の範囲において、別段の定めがない限り、本明細書で使用される全ての技術的および科学的用語は、この開示が属する技術分野の当業者によって一般的に理解されるものと同一の意味を有する。
【0017】
本開示における「一実施形態」、「ある実施形態」、「例示的な実施形態」などへの言及は、説明される実施形態が特性的特徴、構造、または特性を含んでいてもよいことを示すが、すべての実施形態がその特性的特徴、構造、または特性を含む必要はない。さらに、そのような字句は、必ずしも同じ実施形態を参照するに限定されるものではない。さらに、特定の特徴、構造、または特性が例示的な実施形態に関連して説明する場合、明白に記載されていなくても、他の実施形態に関連してそのような特徴、構造、または特性に影響を及ぼすことは当業者の知識の範囲内であることが提示される。
【0018】
「第１の」および「第２の」などの用語は、様々な素子を説明するために本明細書で使用され得るが、これらの素子はこれらの用語によって限定されるべきではないことを理解されたい。これらの用語は、１つの素子を別の素子と区別するためにのみ使用される。たとえば、例示的な実施形態の範囲から逸脱することなく、第１の素子は第２の素子と称されることがあり、同様に、第２の素子は第１の素子と称されることがある。本明細書で使用される「および／または」という用語は、列挙された用語のうちの１つ以上の組合せを含む。
【0019】
明細書において用いられる用語は、特定の態様のみを記述することを目的としており、例示的な実施形態を限定されることを意図してはいない。明細書において用いられるように、単数形（の表現）である「ａ」、「ａｎ」、および「ｔｈｅ」は文脈において別途明確に示さない限り、複数形（のもの）もまた包含することを意図されている。明細書において用いられる場合の用語「含む（ｃｏｍｐｒｉｓｅｓ）」、「含んでいる（ｃｏｍｐｒｉｓｉｎｇ）」、「含む（ｉｎｃｌｕｄｅｓ）」、および／または「含んでいる（ｉｎｃｌｕｄｉｎｇ）」は、記載された特徴、素子、コンポーネントの存在を明示するものであり、一つまたは複数の他の特徴、素子、コンポーネントおよび／またはそれらの群の存在を排除するものではないことをさらに理解されたい。
【0020】
一例の環境
図１は、本開示の技法を利用し得る例示的なビデオ符号化システム１００を示すブロック図である。図示のようにビデオ符号化システム１００は、送信元の装置１１０と送信先の装置１２０とを含んでもよい。前記送信元の装置１１０は、ビデオ符号化装置と呼ばれることもあり、送信先の装置１２０は、ビデオ復号化装置と呼ばれることもある。動作中、送信元の装置１１０は、符号化されたビデオデータを生成するように構成され、送信先の装置１２０は、送信元の装置１１０によって生成された符号化されたビデオデータを復号するように構成されることができる。前記送信元の装置１１０は、ビデオソース１１２と、ビデオ符号化装置１１４と、入力/出力(Ｉ／Ｏ)インターフェース１１６とを含んでもよい。
図１は、本開示の技法を利用し得る例示的なビデオ符号化システム１００を示すブロック図である。図示のようにビデオ符号化システム１００は、送信元の装置１１０と送信先の装置１２０とを含んでもよい。前記送信元の装置１１０は、ビデオ符号化装置と呼ばれることもあり、送信先の装置１２０は、ビデオ復号化装置と呼ばれることもある。動作中、送信元の装置１１０は、符号化されたビデオデータを生成するように構成され、送信先の装置１２０は、送信元の装置１１０によって生成された符号化されたビデオデータを復号するように構成されることができる。前記送信元の装置１１０は、ビデオソース１１２と、ビデオ符号化装置１１４と、入力/出力(Ｉ／Ｏ)インターフェース１１６とを含んでもよい。
【0021】
前記ビデオソース１１２は、ビデオ捕捉装置などのソースを含んでもよい。ビデオ捕捉装置の例には、これらに限定されないが、ビデオコンテンツプロバイダーからビデオデータを受信するためのインターフェース、ビデオデータを生成するためのコンピューターグラフィックスシステム、および／またはそれらの組み合わせが含まれる。
【0022】
前記ビデオデータは、１つ以上のピクチャを含んでもよい。前記ビデオ符号化装置１１４は、ビデオソース１１２からのビデオデータを符号化して、ビットストリームを生成する。前記ビットストリームは、ビデオデータの符号化された表現を形成するビットのシーケンスを含んでもよい。前記ビットストリームは、符号化ピクチャおよび関連データを含んでもよい。前記符号化ピクチャは、ピクチャの符号化表現である。前記関連するデータは、シーケンスパラメータセット、ピクチャパラメータセット、および他の構文構造を含んでもよい。前記Ｉ／Ｏインターフェース１１６は、変復調装置および／または送信器を含んでもよい。符号化されたビデオデータは、ネットワーク１３０Ａを経由してＩ／Ｏインターフェース１１６を介して送信先の装置１２０に直接送信され得る。符号化されたビデオデータはまた、送信先の装置１２０によるアクセスのために記憶媒体/サーバ１３０Ｂに記憶してもよい。
【0023】
前記送信先の装置１２０は、Ｉ／Ｏインターフェース１２６、ビデオ復号化装置１２４、および表示装置１２２を含んでもよい。前記Ｉ／Ｏインターフェース１２６は、受信器および／またはモデムを含んでもよい。前記Ｉ／Ｏインターフェース１２６は、送信元の装置１１０または記憶媒体/サーバ１３０Ｂから符号化されたビデオデータを取得してもよい。ビデオ復号化装置１２４は、符号化されたビデオデータを復号してもよい。前記表示装置１２２は、復号されたビデオデータをユーザに表示してもよい。前記表示装置１２２は、送信先の装置１２０と統合されてもよく、または外部表示装置を搭載するインターフェースに構成される送信先の装置１２０の外部にあってもよい。
【0024】
前記ビデオ符号化装置１１４および前記ビデオ復号化装置１２４は、高効率ビデオ符号化（ＨＥＶＣ）規格、汎用ビデオ符号化（ＶＶＣ）規格、および他の現在および／または更なる規格等のビデオ圧縮規格に従って動作してもよい。
【0025】
【0026】
前記ビデオ符号化装置２００は、本開示の技術のいずれかまたは全部を実装するように構成されてもよい。図２の実施例において、前記ビデオ符号化装置２００は、複数の機能コンポーネントを含む。本開示で説明される技法は、前記ビデオ符号化装置２００の様々なコンポーネント間で共有されてもよい。いくつかの例では、プロセッサ（処理装置）は、本開示で説明される技術のいずれかまたはすべてを実行するように構成してもよい。
【0027】
いくつかの実施形態において、ビデオ符号化装置２００の機能コンポーネントは、分割ユニット２０１と、モード選択ユニット２０３、動き推定ユニット２０４、動き補償ユニット２０５およびイントラ予測ユニット２０６を含んでもよい予測ユニット２０２と、残差生成ユニット２０７と、変換ユニット２０８と、量子化ユニット２０９と、逆量子化ユニット２１０と、逆変換ユニット２１１と、再構築ユニット２１２と、バッファ２１３と、エントロピー符号化ユニット２１４と、を含んでもよい。
【0028】
他の例において、前記ビデオ符号化装置２００は、より多くの、より少ない、または異なる機能コンポーネントを含んでもよい。一例では、前記予測ユニット２０２は、イントラブロックコピー（ＩＢＣ）ユニットを含んでもよい。ＩＢＣユニットは、少なくとも１つの参照ピクチャが現在のビデオブロックが位置するピクチャであるＩＢＣモードにおいて予測を実行することができる。
【0029】
さらに、前記動き推定ユニット２０４および前記動き補償ユニット２０５などのいくつかのコンポーネントは、統合されてもよいが、説明のために、図２の例においては個別に表現されている。
【0030】
前記分割ユニット２０１は、１つのピクチャを１または複数のビデオブロックに分割してよい。前記ビデオ符号化装置２００およびビデオ復号化装置３００は、様々なビデオブロックサイズをサポートしてもよい。
【0031】
前記モード選択ユニット２０３は、例えば、エラー結果に基づいて、イントラまたはインターのいずれかの符号化モードの１つを選択し、得られたイントラ符号化またはインター符号化ブロックを、残差生成ユニット２０７に供給して残差ブロックデータを生成し、また再構築ユニット２１２に供給して参照ピクチャとして使用するために符号化ブロックを再構築してもよい。いくつかの例では、前記モード選択ユニット２０３は、インター予測信号およびイントラ予測信号に基づいて予測を実行するイントラおよびインター組み合わせ予測（ＣＩＩＰ）モードを選択してもよい。前記モード選択ユニット２０３は、インター予測の場合、ブロックのために動きベクトルの解像度（例えば、サブピクセルまたは整数ピクセル精度）を選択してもよい。
【0032】
現在のビデオブロックに対してインター予測を実行するために、前記動き推定ユニット２０４は、バッファ２１３からの１または複数の参照フレームと現在のビデオブロックとを比較することにより、現在のビデオブロックのために動き情報を生成してもよい。前記動き補償ユニット２０５は、現在のビデオブロックに関連付けられたピクチャ以外の前記バッファ２１３からのピクチャの動き情報および復号化サンプルに基づいて、現在のビデオブロックのために予測ビデオブロックを判定してもよい。
【0033】
前記動き推定ユニット２０４および動き補償ユニット２０５は、例えば、現在のビデオブロックがＩスライスであるか、Ｐスライスであるか、またはＢスライスであるかに基づいて、現在のビデオブロックに対して異なる演算を実行してもよい。本明細書で使用される場合、「Ｉスライス」は、すべてが同じピクチャ内のマクロブロックに基づくマクロブロックで構成されているピクチャの一部分を指す場合がある。さらに、本明細書で使用する、いくつかの態様では、「Ｐスライス」および「Ｂスライス」は、同じピクチャ中のマクロブロックに依存しないマクロブロックで構成されているピクチャの一部分を指すことがある。
【0034】
いくつかの例において、前記動き推定ユニット２０４は、現在のビデオブロックに対して単方向予測を実行し、前記動き推定ユニット２０４は、現在のビデオブロックに対する参照ビデオブロックのために、リスト０またはリスト１の参照ピクチャを検索してもよい。動き推定ユニット２０４は、次いで、参照ビデオブロックを含んでいるリスト０またはリスト１中の参照ピクチャを示す参照インデックスと、現在ビデオブロックと参照ビデオブロックとの間の空間変位を示す動きベクトルとを生成し得る。前記動き推定ユニット２０４は、参照インデックス、予測方向インジケータ、および動きベクトルを、現在のビデオブロックの動き情報として出力してもよい。前記動き補償ユニット２０５は、現在のビデオブロックの動き情報が示す参照ビデオブロックに基づいて、現在のビデオブロックの予測ビデオブロックを生成してもよい。
【0035】
代替的に、他の実施例では、前記動き推定ユニット２０４は、現在の映像ブロックを双方向予測してもよく、前記動き推定ユニット２０４は、リスト０における参照ピクチャの中から現在の映像ブロックために参照映像ブロックを検索してもよく、また、リスト１における参照ピクチャの中から現在の映像ブロックのために別の参照映像ブロックを検索してもよい。そして、前記動き推定ユニット２０４は、参照ビデオブロックを含むリスト０およびリスト１における参照ピクチャを示す参照インデックスと、参照ビデオブロックと現在のビデオブロックとの間の空間的変位を示す動きベクトルとを生成してもよい。前記動き推定ユニット２０４は、現在のビデオブロックの参照インデックスおよび動きベクトルを、現在のビデオブロックの動き情報として出力してもよい。前記動き補償ユニット２０５は、現在のビデオブロックの動き情報が示す参照ビデオブロックに基づいて、現在のビデオブロックの予測ビデオブロックを生成してもよい。
【0036】
いくつかの実施例では、前記動き推定ユニット２０４は、デコーダの復号化処理のために、動き情報のフルセットを出力してもよい。代替的に、いくつかの実施形態において、前記動き推定ユニット２０４は、別のビデオブロックの動き情報を参照して、現在のビデオブロックの動き情報を信号通知してもよい。例えば、前記動き推定ユニット２０４は、現在のビデオブロックの動き情報が近傍のビデオブロックの動き情報に十分に類似していると判定してもよい。
【0037】
一実施例では、前記動き推定ユニット２０４は、現在のビデオブロックに関連付けられた構文構造において、現在のビデオブロックが別のビデオブロックと同じ動き情報を有することをビデオ復号化装置３００に示す値を示してもよい。
【0038】
別の例では、前記動き推定ユニット２０４は、現在のビデオブロックに関連付けられた構文構造において、別のビデオブロックと、動きベクトル差（ＭＶＤ）と、を識別してもよい。前記動きベクトル差は、現在のビデオブロックの動きベクトルと、示されたビデオブロックの動きベクトルとの差分を示す。前記ビデオ復号化装置３００は、指示されたビデオブロックの動きベクトルと、動きベクトル差と、を用いて、現在のビデオブロックの動きベクトルを判定してもよい。
【0039】
上述したように、ビデオ符号化装置２００は、動きベクトルを予測的に信号通知してもよい。ビデオ符号化装置２００によって実装され得る予測信号通知技法の２つの例は、先進動きベクトル予測（ＡＭＶＰ）およびマージモード信号通知を含む。
【0040】
前記イントラ予測ユニット２０６は、現在のビデオブロックに対してイントラ予測を行ってもよい。前記イントラ予測ユニット２０６が現在のビデオブロックをイントラ予測する場合、前記イントラ予測ユニット２０６は、同じピクチャにおける他のビデオブロックの復号されたサンプルに基づいて、現在のビデオブロックのための予測データを生成してもよい。現在のビデオブロックのための予測データは、予測されたビデオブロックおよび様々な構文要素を含んでもよい。
【0041】
前記残差生成ユニット２０７は、現在のビデオブロックから現在のビデオブロックの予測されたビデオブロックを減算することによって（例えば、マイナス符号によって示されている）、現在のビデオブロックのために残差データを生成してもよい。現在のビデオブロックの残差データは、現在のビデオブロックにおけるサンプルの異なるサンプル成分に対応する残差ビデオブロックを含んでもよい。
【0042】
他の例において、例えば、スキップモードにおいて、現在のビデオブロックのための残差データがなくてもよく、前記残差生成ユニット２０７は、減算演算を実行しなくてもよい。
【0043】
前記変換処理ユニット２０８は、現在のビデオブロックに関連付けられた残差ビデオブロックに１または複数の変換を適用することによって、現在のビデオブロックのために１または複数の変換係数ビデオブロックを生成してもよい。
【0044】
前記変換処理ユニット２０８が現在のビデオブロックに関連付けられた変換係数ビデオブロックを生成した後、前記量子化ユニット２０９は、現在のビデオブロックに関連付けられた１または複数の量子化パラメータ（ＱＰ）の値に基づいて、現在のビデオブロックに関連付けられた変換係数ビデオブロックを量子化してもよい。
【0045】
前記逆量子化ユニット２１０および前記逆変換ユニット２１１は、変換係数ビデオブロックに逆量子化および逆変換をそれぞれ適用し、変換係数ビデオブロックから残差ビデオブロックを再構築してもよい。前記再構築ユニット２１２は、予測ユニット２０２が生成した１または複数の予測ビデオブロックから対応するサンプルに再構築された残差ビデオブロックを加え、バッファ２１３での記憶のために現在のビデオブロックに関連付けられた再構築されたビデオブロックを生成してよい。
【0046】
前記再構築ユニット２１２がビデオブロックを再構築した後、ビデオブロックにおけるビデオブロッキングアーチファクトを縮小するために、ループフィルタリング動作を行ってもよい。
【0047】
前記エントロピー符号化ユニット２１４は、ビデオ符号化装置２００の他の機能コンポーネントからデータを受信してもよい。前記エントロピー符号化ユニット２１４がデータを受信した場合、前記エントロピー符号化ユニット２１４は、１または複数のエントロピー符号化動作を行い、エントロピー符号化されたデータを生成し、エントロピー符号化されたデータを含むビットストリームを出力してもよい。
【0048】
図３は、本開示のいくつかの実施形態による、ビデオ復号化装置３００の一例を示すブロック図であり、このビデオ復号化装置３００は、図１に示すシステム１００における前記ビデオ復号化装置１２４の一例であってもよい。
【0049】
ビデオ復号化装置３００は、本開示の技術のいずれか又は全部を実行するように構成されてもよい。図３の実施例において、ビデオ復号化装置３００は、複数の機能性モジュールを含む。本開示で説明される技法は、ビデオ復号化装置３００の様々なコンポーネント間で共有されてもよい。いくつかの例では、プロセッサ（処理装置）は、本開示で説明される技術のいずれかまたはすべてを実行するように構成してもよい。
【0050】
図３の実施例において、ビデオ復号化装置３００は、エントロピー復号化ユニット３０１、動き補償ユニット３０２、イントラ予測ユニット３０３、逆量子化ユニット３０４、逆変換ユニット３０５、および再構築ユニット３０６、並びにバッファ３０７を含む。前記ビデオ復号化装置３００は、いくつかの例では、ビデオ符号化装置２００（図５）に関して説明した復号化パスとほぼ逆の復号化パスを行ってもよい。
【0051】
前記エントロピー復号化ユニット３０１は、符号化されたビットストリームを取り出す。符号化されたビットストリームは、エントロピー符号化されたビデオデータ（例えば、ビデオデータの符号化されたブロック）を含んでもよい。前記エントロピー復号化ユニット３０１は、エントロピー符号化されたビデオデータを復号化し、エントロピー復号されたビデオデータから、前記動き補償ユニット３０２は、動きベクトル、動きベクトル精度、参照ピクチャリストインデックス、および他の動き情報を含む動き情報を決定してもよい。前記動き補償ユニット３０２は、例えば、ＡＭＶＰ及びマージモードを実行することにより、このような情報を判定してもよい。隣接するＰＢおよび参照ピクチャからのデータに基づくいくつかの最有力候補の導出を含む、ＡＭＶＰが使用される。動き情報は、一般に、水平および垂直動きベクトル変位値と、１つまたは２つの参照ピクチャインデックスと、Ｂスライス中の予測領域の場合、どの参照ピクチャリストが各インデックスに関連するかの識別情報とを含む。本明細書で使用される、いくつかの態様では、「マージモード」は、空間的または時間的に近傍のブロックから動き情報を導出することを指す場合がある。
【0052】
前記動き補償ユニット３０２は、動き補償されたブロックを生成してもよく、場合によっては、補間フィルタに基づいて補間を実行する。サブピクセルの精度で使用される補間フィルタのための識別子が、構文要素に含んでもよい。
【0053】
前記動き補償ユニット３０２は、ビデオブロックの符号化の間に前記ビデオ符号化装置２００によって使用されるような前記補間フィルタを使用して、参照ブロックのサブ整数ピクセルのための補間値を計算してもよい。前記動き補償ユニット３０２は、前記受信した構文情報に基づいて、前記ビデオ符号化装置２００が使用する補間フィルタを判定し、この補間フィルタを使用して予測ブロックを生成してもよい。
【0054】
前記動き補償ユニット３０２は、符号化されたビデオシーケンスのフレームおよび／またはスライスを符号化するために使用されるブロックのサイズを判定するための構文情報、符号化されたビデオシーケンスのピクチャの各マクロブロックがどのように分割されるかを記述する分割情報、各分割がどのように符号化されるかを示すモード、各インター符号化されたブロックに対する１または複数の参照フレーム（および参照フレームリスト）、および符号化されたビデオシーケンスを復号化するための他の情報の少なくとも一部を使用してもよい。本明細書で使用される場合、いくつかの態様では、「スライス」は、エントロピー符号化、信号予測、および残差信号再構築に関して、同じピクチャの他のスライスから独立して復号され得るデータ構造を指す場合がある。スライスは、ピクチャ全体またはピクチャのある領域であることができる。
【0055】
前記イントラ予測ユニット３０３は、例えば、ビットストリームにおいて受信したイントラ予測モードを使用して、空間的に隣接するブロックから予測ブロックを形成してもよい。前記逆量子化ユニット３０４は、ビットストリームに提供され、エントロピー復号化ユニット３０１によって復号された量子化されたビデオブロック係数を逆量子化（すなわち、逆量子化）する。前記逆変換ユニット３０５は、逆変換を適用する。
【0056】
前記再構築ユニット３０６は、例えば、残差ブロックを動き補償ユニット３０２またはイントラ予測ユニット３０３によって生成された対応する予測ブロックと加算することによって、復号されたブロックを取得してもよい。所望であれば、ブロックアーチファクトを除去するために、復号されたブロックをフィルタリングするためにデブロッキングフィルタを適用してもよい。復号化されたビデオブロックは、前記バッファ３０７に記憶され、バッファ３０７は、後続の動き補償／イントラ予測のために参照ブロックを提供し、且つ表示デバイスに表示するために復号化されたビデオを生成する。
【0057】
以下、本開示のいくつかの例示的な実施形態を詳細に説明する。本明細書では、理解を容易にするために章の見出しを使用しており、その技術および章に記載された実施形態の適用可能性をその章のみに限定するものではないことが理解されるべきである。さらに、特定の実施形態では、汎用ビデオ符号化または他の特定のビデオコーデックに関して説明されるが、開示される技法は、他のビデオ符号化技術にも適用可能である。さらに、いくつかの実施形態は、ビデオ符号化ステップを詳細に説明するが、符号化を取り消し対応するステップ復号化が復号器よって実装されることが理解される。さらに、ビデオ処理という用語は、ビデオ符号化または圧縮、ビデオ復号化または解凍、およびビデオピクセルが１つの圧縮形式から別の圧縮形式に、または異なる圧縮ビットレートで表されるビデオトランス符号化を包含する。
１．要約
本開示は、ビデオファイル形式に関する。具体的には、本開示は、メディア
ファイルにおけるメディア ファイルのサポートに関する。この考えは、例えば、ＩＳＯベースメディアファイル形式(ＩＳＯＢＭＦＦ)またはその拡張に基づいて、メディアファイルフォーマットに、個々にまたは様々な組合せで適用されてもよい。
２．背景技術
２．１ビデオ符号化規格
ビデオ符号化規格は、主に周知のＩＴＵ－ＴおよびＩＳＯ／ＩＥＣ規格の開発によって発展してきた。ＩＴＵ－ＴはＨ．２６１とＨ．２６３を作り、ＩＳＯ／ＩＥＣはＭＰＥＧ－１とＭＰＥＧ－４Ｖｉｓｕａｌを作り、両団体はＨ．２６２／ＭＰＥＧ－２ＶｉｄｅｏとＨ．２６４／ＭＰＥＧ－４
高度映像符号化（ＡＶＣ）とＨ．２６５／ＨＥＶＣ規格を共同で作った。Ｈ．２６２以降、ビデオ符号化規格は、時間予測と変換符号化が利用されるハイブリッドビデオ符号化構造に基づく。ＨＥＶＣを超えた将来のビデオ符号化技術を探索するため、２０１５年には、ＶＣＥＧとＭＰＥＧが共同で共同ビデオエキスパートチーム（ＪＶＥＴ）を設立した。それ以来、多くの新しい方法がＪＶＥＴによって採用され、ＪＥＭ（ＪｏｉｎｔＥｘｐｌｏｒａｔｉｏｎＭｏｄｅ）と呼ばれる参照ソフトウェアに組み込まれてきた。ＪＶＥＴは、後に汎用ビデオ符号化（ＶＶＣ）プロジェクトが正式に始まったとき、共同ビデオエキスパートチーム（ＪＶＥＴ）に改称された。ＶＶＣは新しい符号化規格であり、ＨＥＶＣに比べて５０％のビットレート低減を目指し、２０２０年７月１日に終了した第１９回ＪＶＥＴ総会において完成した。
汎用映像符号化（ＶＶＣ）規格（ＩＴＵ－Ｔ Ｈ．２６６｜ＩＳＯ／ＩＥＣ２３０９０－３）と汎用補助拡張情報（ＶＳＥＩ）規格（ＩＴＵ－Ｔ Ｈ．２７４｜ＩＳＯ／ＩＥＣ２３００２－７）は、テレビ放送、ビデオ会議、記憶媒体からの再生などの従来の用途に加え、適応ビットレートストリーミング、映像領域抽出、複数の符号化映像ビットストリームからのコンテンツの合成・結合、マルチビュー映像、スケーラブルレイヤードコーディング、ビューポートに適応した３６０°没入型メディアなど、より新しく、より高度な用途を含め、最大限に幅広いアプリケーションで使用できるように設計されている。
基本ビデオ符号化(ＥＶＣ)規格(ＩＳＯ/ＩＥＣ２３０９４-１)は、ＭＰＥＧによって最近開発された別のビデオ符号化規格である。
２．２ ファイル形式規格
メディアストリーミングアプリケーションは、一般的に、ＩＰ、ＴＣＰ、およびＨＴＴＰトランスポート方法に基づいており、一般的に、ＩＳＯベースのメディアファイルフォーマット（ＩＳＯＢＭＦＦ）［７］などのファイル形式に依存する。そのようなストリーミングシステムの１つは、ＨＴＴＰ（ＤＡＳＨ）を介した動的適応ストリーミングである。ＩＳＯＢＭＦＦおよびＤＡＳＨを有するビデオフォーマットを使用するために、ＩＳＯＢＭＦＦトラック並びにＤＡＳＨ表現およびセグメントにおけるビデオコンテンツのカプセル化のために、ＡＶＣファイル形式およびＨＥＶＣファイル形式のような、ビデオフォーマットに特定のファイル形式仕様が必要とされる。ビデオビットストリームに関する重要な情報、例えば、プロファイル、階層、レベル、その他多数は、コンテンツ選択のために、例えば、ストリーミングセッションの開始時の初期化およびストリーミングセッション中のストリーム適応の両方のために、ファイル形式レベルのメタデータおよび／またはＤＡＳＨメディアプレゼンテーション記述（ＭＰＤ）として公開される必要がある。
同様に、ＩＳＯＢＭＦＦを有するピクチャフォーマットを使用するために、ＡＶＣピクチャファイル形式およびＨＥＶＣピクチャファイル形式等の、ピクチャフォーマットに特定のファイル形式仕様が必要とされる。
ＩＳＯＢＭＦＦに基づくＶＶＣビデオコンテンツを記憶するためのファイル形式であるＶＶＣビデオビデオファイル形式は、現在、ＭＰＥＧによって開発されている。ＩＳＯＢＭＦＦに基づく、ＶＶＣを使用して符号化されたピクチャ内容を記憶するためのファイル形式であるＶＶＣピクチャファイル形式は、現在、ＭＰＥＧによって開発されている。
２．３ＶＶＣにおけるピクチャの分割およびサブピクチャ
ＶＶＣにおいて、１つのピクチャは、１つ以上のタイル行および１つ以上のタイル列に分割される。タイルは、ピクチャの矩形領域をカバーするＣＴＵのシーケンスである。１つのタイルは、１つのピクチャの１つの矩形領域を覆う１つのＣＴＵのシーケンスである。１つのタイルにおけるＣＴＵは、そのタイル内でラスタスキャン順にスキャンされる。
１つのスライスは、１つのピクチャのタイル内において、整数個の完全なタイルまたは整数個の連続した完全なＣＴＵ行によって構成されている。
２つのモードのスライス、即ち前記ラスタスキャンスライスモードおよび前記矩形スライスモードに対応している。前記ラスタスキャンスライスモードにおいて、１つのスライスは、１つのピクチャのタイルラスタスキャンにおける完全なタイルのシーケンスを含む。前記矩形スライスモードにおいて、１つのスライスは、前記ピクチャの矩形領域を集合的に形成する完全なタイルの数、または前記ピクチャの矩形領域を集合的に形成する１つのタイルの連続した完全なＣＴＵ行の数のいずれかを含む。矩形スライス内のタイルを、そのスライスに対応する矩形領域内で、タイルラスタスキャンの順にスキャンする。
１つのサブピクチャは、１つのピクチャの矩形領域を集合的に覆う１つ以上のスライスを含む。
２．３．１サブピクチャの概念および機能
ＶＶＣでは、各サブピクチャは、たとえば図４に示すように、ピクチャの矩形領域を集合的に覆う１つの唯一の矩形スライスで構成される。サブピクチャは、抽出可能であるように規定される(すなわち、同じピクチャの他のサブピクチャおよび復号化順で前のピクチャとは独立して符号化)か、または抽出不可能であるように規定してもよい。サブピクチャが抽出可能であるか否かにかかわらず、符号器は、(デブロッキング、ＳＡＯ、およびＡＬＦを含む)ループ内フィルタリングがサブピクチャの境界を越えて適用されるかどうかを各サブピクチャごとに個々に制御することができる。
機能的に、サブピクチャは、ＨＥＶＣにおける動き制約タイルセット(ＭＣＴＳ)と同様である。それらは両方とも、ビューポート依存３６０°ビデオストリーミング最適化および関心領域(ＲＯＩ)アプリケーションのような使用事例のために、符号化ピクチャのシーケンスの長方形サブセットの独立した符号化および抽出を可能にする。着目領域。
３６０°ビデオのストリーミング、とりわけ、全方向性ビデオでは、いかなる特定の瞬間にも、全方向性ビデオ球全体のサブセット(すなわち、現在のビューポート)のみがユーザに対して表示することになり、一方、利用者は、いつでも自分の首を回せ、視聴方向、したがって現在のビューポートを変更することができる。現在のビューポートによってカバーされないエリアの少なくともいくつかのより低い品質の表現をクライアントにおいて利用可能にし、ユーザが自分の閲覧方向を球体のどこかに突然変更した場合にユーザに対して表示する準備ができていることが望ましいが、全方向性ビデオの高品質表現は、いかなる時点においても、ユーザに対して表示されている現在のビューポートのみに必要とされる。全方位ビデオ全体の高品質表現を適切な粒度のサブピクチャに分割することは、１２個の高解像度サブピクチャを左側に有し、それより低い解像度で全方位ビデオの残りの１２個のサブピクチャを右側に有する図４に示すような最適化を可能にする。
他の典型的なサブピクチャベースのビューポート依存３６０°ビデオ配信スキームが図５に示されており、高めの解像度の表現のフルビデオのみがサブピクチャで構成され、一方で、低めの解像度の表現のフルビデオは、サブピクチャを使用せずに、高めの解像度の表現よりも少ない頻度のＲＡＰで符号化されることができる。クライアントは低めの解像度のフルビデオを受信する一方で、高めの解像度のビデオについて、クライアントは、現在ビューポートを覆うサブピクチャのみを受信して復号する。
２．３．２サブピクチャとＭＣＴＳとの間の違い
サブピクチャとＭＣＴＳとの間には幾つかの重要な設計上の違いがある。第１に、ＶＶＣにおけるサブピクチャ機能は、ピクチャ境界においてと同様に、この場合にはサブピクチャ境界においてサンプルパディングを適用することによって、サブピクチャが抽出可能である場合であっても、サブピクチャの外を指す符号化グブロックの動きベクトルを可能にする。第２に、マージモードおよびＶＶＣのデコーダ側動きベクトル精緻化プロセスにおける動きベクトルの選択及び導出のために追加の変更が導入された。これは、ＭＣＴＳに対して符号器側で適用される非標準の動き制約と比較してより高い符号化効率を可能にする。第３に、適合ビットストリームであるサブビットストリームを作成するためにピクチャのシーケンスから１つ以上の抽出可能なサブピクチャを抽出するときに、ＳＨ（及び、存在する場合にＰＨ ＮＡＬユニット）の書き換えが必要とされない。ＨＥＶＣ ＭＣＴＳに基づくサブビットストリーム抽出では、ＳＨの書き換えが必要とされる。なお、ＨＥＶＣ ＭＣＴＳ抽出及びＶＶＣサブピクチャ抽出のどちらでも、ＳＰＳ及びＰＰＳの書き換えは必要とされる。しかしながら、典型的に、ビットストリーム内には少しのパラメータセットしか存在しない一方で、各ピクチャは少なくとも１つのスライスを持ち、従って、ＳＨの書き換えはアプリケーションシステムにとってかなりの負担となり得る。第４に、ピクチャ内の異なるサブピクチャのスライスは異なるＮＡＬユニットタイプを持つことが許される。これは、以下でより詳細に説明される、ピクチャ内の混合ＮＡＬユニットタイプまたは混合サブピクチャタイプとしばしば呼ばれる特徴である。第５に、ＶＶＣは、サブピクチャシーケンスについてのＨＲＤおよびレベル定義を規定しており、従って、抽出可能なサブピクチャシーケンス各々のサブビットストリームの適合性がエンコーダによって保証され得る。
２．３．３ピクチャ内の混合サブピクチャタイプ
ＡＶＣおよびＨＥＶＣでは、ピクチャ内のすべてのＶＣＬ ＮＡＬユニットが同じＮＡＬユニットタイプを持つ必要がある。ＶＶＣは、特定の相異なるＶＣＬ ＮＡＬユニットタイプを持つサブピクチャ同士をピクチャを混ぜるオプションを導入し、従って、ピクチャレベルだけでなくサブピクチャレベルでも、ランダムアクセスに対するサポートを提供する。ＶＶＣにおいて、サブピクチャ内のＶＣＬ ＮＡＬユニットは、同じＮＡＬユニットタイプを持つことが依然として必要とされる。
ＩＲＡＰサブピクチャからのランダムアクセスの能力は、３６０°ビデオアプリケーションにとって有益である。図５に示したものと同様のビューポート依存３６０°ビデオ配信スキームにおいて、空間的に隣接するビューポートのコンテンツ同士が大きく重なり合い、すなわち、ビューポート内のサブピクチャのうちの一部のみがビューポートの向きの変更中に新しいサブピクチャによって入れ替え、大部分のサブピクチャはビューポート内に留まる。ビューポートに新たに導入されるサブピクチャシーケンスは、ＩＲＡＰスライスで開始しなければならないが、残りのサブピクチャがビューポート変更時にインター予測を実行することを可能にされるとき、全体的な伝送ビットレートの大幅な低減を達成することができる。
ピクチャがただ１つのタイプのＮＡＬユニットを含むのか、２つ以上のタイプを含むのかの指示が、そのピクチャによって参照されるＰＰＳ内で（すなわち、ｐｐｓ_ｍｉｘｅｄ_ｎａｌｕ_ｔｙｐｅｓ_ｉｎ_ｐｉｃ_ｆｌａｇと呼ばれるフラグを用いて）提供される。ピクチャは、ＩＲＡＰスライスを含むサブピクチャと、トレーリングスライスを含むサブピクチャを同時に構成され得る。ＮＡＬユニットタイプＲＡＳＬ及びＲＡＤＬのリーディングピクチャスライスを含め、ピクチャ内での異なるＮＡＬユニットタイプの他の組み合わせも少数ながら可能にされ、これは、異なるビットストリームから抽出されたオープンＧＯＰ及びクローズＧＯＰ符号化構造を有するサブピクチャシーケンスを１つのビットストリームにマージすることを可能にする。
２．３．４サブピクチャレイアウトおよびＩＤ信号通知
ＶＶＣにおけるサブピクチャのレイアウトはＳＰＳ内で信号通知され、従って、ＣＬＶＳ内で一定である。各サブピクチャは、その左上ＣＴＵの位置、並びにＣＴＵ数でのその幅及び高さによって信号通知され、従って、サブピクチャがＣＴＵ粒度でピクチャの矩形領域をカバーすることが保証される。それらのサブピクチャがＳＰＳ内で信号通知される順序が、ピクチャ内の各サブピクチャのインデックスを決定する。
ＳＨまたはＰＨの書き換えなくサブピクチャシーケンスの抽出及びマージを可能にするために、ＶＶＣにおけるスライスアドレシングスキームは、サブピクチャＩＤ、及びスライスをサブピクチャに関連付けるためのサブピクチャ固有スライスインデックスに基づく。ＳＨでは、そのスライスを含むサブピクチャのサブピクチャＩＤ及びサブピクチャレベルスライスインデックスが信号通知される。なお、特定のサブピクチャのサブピクチャＩＤの値は、そのサブピクチャインデックスの値とは異なることができる。２つの間のマッピングは、ＳＰＳ又はＰＰＳ（しかし、決して両方ではない）内で信号通知されるか、又は黙示的に推定されるかのいずれかである。存在する場合、サブピクチャＩＤマッピングは、サブピクチャサブビットストリーム抽出プロセスでＳＰＳ及びＰＰＳを書き換えるときに書き換えられるか又は追加されるかする必要がある。サブピクチャＩＤ及びサブピクチャレベルスライスインデックスの両方は、復号ピクチャのＤＰＢスロット内のスライスの最初の復号ＣＴＵの正確な位置をデコーダに示す。サブビットストリーム抽出の後、サブピクチャのサブピクチャＩＤは変更されないままであるが、サブピクチャインデックスは変わり得る。サブピクチャ内のスライス内の最初のＣＴＵのラスタスキャンＣＴＵアドレスが元のビットストリームでの値と比較して変化した時であっても、各自のＳＨ内のサブピクチャＩＤ及びサブピクチャレベルスライスインデックスの変化していない値がなおも、抽出されたサブビットストリームの復号ピクチャ内の各ＣＴＵの位置を正確に決定する。図６は、２つのサブピクチャおよび４つのスライスを含む例を用いてサブピクチャ抽出を可能にするためのサブピクチャＩＤ、サブピクチャインデックスおよびサブピクチャレベルスライスインデックスの使用を示す。
サブピクチャ抽出と同様に、サブピクチャについての信号通知は、異なるビットストリームが協調的に生成される(たとえば、別個のサブピクチャＩＤを使用するが、それ以外は、ＣＴＵサイズ、クロマフォーマット、符号化ツールなど、ほぼ整合されたＳＰＳ、ＰＰＳ、およびＰＨパラメータを使用して)という条件で、ＳＰＳおよびＰＰＳを書き換えるだけで、異なるビットストリームからのいくつかのサブピクチャを１つのビットストリームにマージすることを可能にする。
サブピクチャ及びスライスは、それぞれ、ＳＰＳ及びＰＰＳ内で独立に信号通知されるが、適合ビットストリームを形成するために、サブピクチャレイアウトとスライスレイアウトとの間に固有の相互制約が存在する。第１に、サブピクチャの存在は、矩形スライスを用いることを必要とし、ラスタスキャンスライスを禁止する。第２に、所与のサブピクチャのスライスは、復号化の順序で連続したＮＡＬユニットであるとされ、これが意味することは、サブピクチャレイアウトが、ビットストリーム内の符号化されるスライスＮＡＬユニットの順序を制約するものとする。
２．４ピクチャインピクチャサービス
ピクチャインピクチャサービスは、より大きい解像度を有するピクチャ内に、小さい解像度を有するピクチャを含む能力を提供する。そのようなサービスは、２つのビデオをユーザに同時に示すのに有益であり得、それによって、より大きい解像度を有するビデオが主ビデオと見なされ、より小さい解像度を有するビデオが補助ビデオと見なされる。そのようなピクチャインピクチャサービスは、主ビデオがサイネージビデオによって補完されるアクセシビリティサービスを提供するために使用され得る。
ＶＶＣサブピクチャは、ＶＶＣサブピクチャの抽出特性とマージ特性の両方を使用することによって、ピクチャインピクチャサービスに使用できる。そのようなサービスの場合、主ビデオは、いくつかのサブピクチャを使用して符号化され、サブピクチャのうちの１つは、補助ビデオと同じサイズであり、補助ビデオが主ビデオに合成されることが意図される正確な位置に配置され、抽出を可能にするために独立に符号化される。ユーザが補助ビデオを含むバージョンのサービスを視聴することを選択した場合、図７に示すように、主ビデオのピクチャインピクチャ領域に対応するサブピクチャが主ビデオビットストリームから抽出され、補助ビデオビットストリームがその場所で主ビデオビットストリームとマージされる。図７は、ＶＶＣサブピクチャに基づくピクチャインピクチャサポートの一例を示す。
この場合、主ビデオおよび補助ビデオのピクチャは、同じビデオ特性を共有しなければならず、特に、ビット深度、サンプルアスペクト比、サイズ、フレームレート、色空間および伝達特性、クロマサンプル位置が同じでなければならない。主および補助ビデオビットストリームは、各ピクチャ内のＮＡＬユニットタイプを使用する必要はない。しかしながら、マージングは、主および補助ビットストリーム中のピクチャの符号化の順序が同じであることを必要とする。
サブピクチャのマージングがここで必要とされるので、主ビデオおよび補助ビデオ内で使用されるサブピクチャＩＤは重複することができない。補助ビデオビットストリームが更なるタイルまたはスライス分割なしに１つのサブピクチャのみから構成される場合であっても、補助ビデオビットストリームの主ビデオビットストリームとのマージングを可能にするために、サブピクチャ情報、特にサブピクチャＩＤおよびサブピクチャＩＤ長が信号通知される必要がある。前記補助ビデオビットストリームのスライスＮＡＬユニット内のサブピクチャＩＤ構文要素の長さを信号通知するために使用されるサブピクチャＩＤ長は、主ビデオビットストリームのスライスＮＡＬユニット内のサブピクチャＩＤを信号通知するために使用されるサブピクチャＩＤ長と同じでなければならない。さらに、ＰＰＳ区分情報を書き換える必要なしに補助ビデオビットストリームを主ビデオビットストリームとマージすることを簡略化するために、主ビデオの対応するエリア内で、１つのスライスおよび１つのタイルのみを使用して補助ビデオを符号化することが有益であり得る。主および補助ビデオビットストリームは、ＳＰＳ、ＰＰＳおよびピクチャヘッダ中で同じ符号化ツールを信号通知しなければならない。それは、ブロック区分のための同じ最大および最小許容サイズと、ＰＰＳ中で信号通知されるものと同じ初期量子化パラメータの値(ｐｐｓ_ｉｎｉｔ_ｑｐ_ｍｉｎｕｓ２６構文要素の同じ値)とを使用することを含む。符号化ツールの使用は、スライスヘッダレベルで修正することができる。
主および補助ビットストリームの両方がＩＳＯＢＭＦＦベースのメディアファイルにおいて利用可能であるとき、主および補助ビットストリームは、２つの別個のファイル形式トラックに記憶することができる。
３．課題
ＩＳＯＢＭＦＦベースのメディアファイルにおけるピクチャインピクチャのサポートについて、以下の課題が観察されてきた。
１）ピクチャインピクチャ主および補助ビットストリームを別々に記憶するために異なるファイル形式トラックを使用することが可能であるが、ＩＳＯＢＭＦＦに基づくメディアファイル中のトラックのそのようなペアについてそのような目的の指示のための機構を欠く。
２）例えば上述したように、ピクチャインピクチャエクスペリエンスのためにＶＶＣサブピクチャを使用することが可能であるが、主ビデオ中のターゲットピクチャインピクチャ領域を表す符号化されたビデオデータユニットを補助ビデオの対応するビデオデータユニットと入れ替えることができない他のコーデックおよび方法を使用することも可能である。したがって、そのような入替が可能であるかどうかをＩＳＯＢＭＦＦベースのメディアファイル中で示す必要がある。
３）上記の入替が可能である場合、クライアントは、入替を実行することができるように、主ビデオの各ピクチャ中のどの符号化されたビデオデータユニットがターゲットピクチャインピクチャ領域を表すかを知る必要がある。したがって、この場合、この情報は、ＩＳＯＢＭＦＦベースのメディアファイル中で信号通知される必要がある。
４）コンテンツ選択目的および場合によっては他の目的のためにも、ＩＳＯＢＭＦＦベースのメディアファイル中で、主ビデオ中のターゲットピクチャインピクチャ領域の位置およびサイズを信号通知することは有用になるであろう。
４．例示的な実施形態
上述した課題を解決するために、以下に示す方法が開示されている。本実施形態は、一般概念を説明するための例と見なされるべきであり、狭義に解釈されるべきではない。さらに、これらの実施形態は、個々に適用されてもよく、または任意の方法で組み合わされてもよい。説明の都合上、一体となってピクチャインピクチャエクスペリエンスを与える主および補助ビットストリームを担持するトラックのペアは、ピクチャインピクチャトラックのペアまたはピクチャインピクチャトラックペアと呼ばれる。
１）第１の課題を解決するために、トラックリファレンスを含むトラックおよびトラックリファレンスによって参照されるトラックがピクチャインピクチャトラックのペアであることを示すために、新しいタイプのトラックリファレンスが定義される。
ａ．一例では、この新しいタイプのトラックリファレンスは、特定の値に等しいトラックリファレンスタイプ、たとえば、「ｐｉｐｓ」(「ピクチャインピクチャ補助ビットストリームを参照すること」を意味する)によって示され、このトラックリファレンスを含むトラックはメインビットストリームを搬送し、トラックリファレンスによって参照されるトラックは補助ビットストリームを搬送する。
ｂ．別の例では、この新しいタイプのトラックリファレンスは、特定の値に等しいトラックリファレンスタイプ、たとえば、「ｐｉｐｍ」(「ピクチャインピクチャ メイン ビットストリームを参照すること」を意味する)によって示され、このトラックリファレンスを含むトラックは補助ビットストリームを搬送し、トラックリファレンスによって参照されるトラックは補助ビットストリームを搬送する。
ｃ．さらに別の例において、上記で説明した両方のトラックリファレンスタイプが定義される。
２）第１および第２の課題を解決するために、メインビットストリームを担持するトラック中に含まれるべき２つの新しいタイプのトラックリファレンスが定義され、一方は、主ビデオ中のターゲットピクチャインピクチャ領域を表す符号化されたビデオデータユニットを補助ビットストリームの対応するビデオデータユニットと入れ替えることを可能にするピクチャインピクチャトラックのペアを示し、他方は、そのようなビデオデータユニット入替が可能にされないピクチャインピクチャトラックのペアを示す。
ａ．一例では、これらの２つの新しいタイプのトラックリファレンスは、それぞれ、「ｐｐｓｒ」(「映像データユニット入替が有効化された、ピクチャインピクチャ補助ビットストリームを指すこと」を意味する)および「ｐｐｓｎ」(「映像データユニット入替が有効化されていない、ピクチャインピクチャ補助ビットストリームを指すこと」を意味する)に等しいトラックリファレンスタイプ値によって示される。
３）第１および第２の課題を解決するために、代替的に、補助ビットストリームを担持するトラック中に含まれるべき２つの新しいタイプのトラックリファレンスが定義され、一方は、主ビデオ中のターゲットピクチャインピクチャ領域を表す符号化されたビデオデータユニットを補助ビデオの対応するビデオデータユニットと入れ替えることを可能にするピクチャインピクチャトラックのペアを示し、他方は、そのようなビデオデータユニット入替が可能にされないピクチャインピクチャトラックのペアを示す。
ａ．一例では、これらの２つの新しいタイプのトラックリファレンスは、それぞれ、「ｐｐｍｒ」(「映像データユニット入替が有効化された、ピクチャインピクチャメインビットストリームを指すこと」を意味する)および「ｐｐｍｎ」(「映像データユニット入替が有効化されていない、ピクチャインピクチャメインビットストリームを指すこと」を意味する)に等しいトラックリファレンスタイプ値によって示される。
４）第１および第２の課題を解決するために、代替的に、上記の項目２および３に記載された４つの新しいタイプのトラックリファレンスが定義される。
５）第４の課題すべてを解決するために、以下に示す新しいタイプのエンティティグループ化が定義される。
ａ．新しいタイプのエンティティグループ化は、ピクチャインピクチャエンティティグループ化と命名され、ｇｒｏｕｐｉｎｇ_ｔｙｐｅは「ｐｉｎｐ」に等しい(または、異なる名前もしくは異なるグループ化タイプ値であるが、以下で説明するように同様の特徴を有する)。
ｂ．一例では、エンティティグループ内の各エンティティがビデオトラックでなければならないことが指定される。
ｃ．ＰｉｃＩｎＰｉｃＥｎｔｉｔｙＧｒｏｕｐＢｏｘは、ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘを拡張することによって、以下の情報のうちの少なくとも１つまたは複数を搬送するように定義された。
ｉ．メインビットストリームトラックの数Ｎ。ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ中の最初のＮ個のｅｎｔｉｔｙ_ｉｄ値によって識別されるエンティティ(すなわち、このコンテキストではトラック)はメインビットストリームトラックであり、ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ中の他のｅｎｔｉｔｙ_ｉｄ値によって識別されるエンティティは補助ビットストリームトラックである。ピクチャインピクチャエクスペリエンスを再生するために、メインビットストリームトラックのうちの１つが選択され、補助ビットストリームトラックのうちの１つが選択される。
１．代替的に、メインビットストリームトラックは、ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ中のｅｎｔｉｔｙ_ｉｄ値のリストへのインデックスのリストによって信号通知され、エンティティグループ中の他のエンティティ/トラックは補助ビットストリームトラックである。
２．代替的に、メインビットストリームトラックは、ｔｒａｃｋ_ｉｄ値のリストへのインデックスのリストによって信号通知され、エンティティグループ中の他のエンティティ/トラックは補助ビットストリームトラックである。
ｉｉ．主ビデオ中のターゲットピクチャインピクチャ領域を表す符号化されたビデオデータユニットを補助ビデオの対応するビデオデータユニットと入れ替えることが可能であるかどうかを示す指示。
１．一例では、標示は、ｄａｔａ_ｕｎｉｔｓ_ｒｅｐｌａｃａｂｌｅと称する１ビットフラグによって信号通知され、値１および０は、それぞれ、そのような映像データユニット入替が有効および無効であることを示す。
ｉｉｉ．主ビデオの各ピクチャ中のどの符号化されたビデオデータユニットがターゲットピクチャインピクチャ領域を表すかを示すための領域ＩＤのリスト。
１．一例では、領域ＩＤの明確的セマンティクスが特定のビデオコーデックのために明確的に指定される必要があることが指定される。
ａ．一例では、ＶＶＣの場合、領域ＩＤはサブピクチャＩＤであり、符号化されたビデオデータユニットはＶＣＬ ＮＡＬユニットであることが指定される。主ビデオ中のターゲットピクチャインピクチャ領域を表すＶＣＬ ＮＡＬユニットは、補助ビデオの対応するＶＣＬ ＮＡＬユニット中のサブピクチャＩＤと同じである、これらのサブピクチャＩＤを有するものである(一般に、補助ビデオ中の１つのピクチャのすべてのＶＣＬ ＮＡＬユニットは、明確的に信号通知される同じサブピクチャＩＤを共有し、この場合、領域ＩＤのリスト中に１つの領域ＩＤのみがある)。
ｂ．一例では、ＶＶＣの場合、クライアントが、ビデオ復号化装置に送る前に、主ビデオ中のターゲットピクチャインピクチャ領域を表す(ＶＣＬ ＮＡＬユニットである)符号化されたビデオデータユニットを補助ビデオの対応するＶＣＬ ＮＡＬユニットと入れ替えることをクライアントが選定したとき、サブピクチャＩＤごとに、主ビデオ中のＶＣＬ ＮＡＬユニットは、対応するＶＣＬ ＮＡＬユニットの順序を変更することなしに、補助ビデオ中のそのサブピクチャＩＤを有する対応するＶＣＬ ＮＡＬユニットと入れ替えることが規定される。
ｉｖ．主ビデオよりもサイズが小さい補助ビデオを埋め込む/オーバーレイするための主ビデオ内の位置およびサイズ。
１．一例では、これは、４つの値(ｘ、ｙ、幅、高さ)を信号通知することによって信号通知され、ｘ、ｙは領域の左上の位置を指定し、幅および高さは領域の幅および高さを指定する。単位は、ルーマサンプル/ピクセルであり得る。
２．一例では、ｄａｔａ_ｕｎｉｔｓ_ｒｅｐｌａｃａｂｌｅが１に等しく、位置およびサイズ情報が存在するとき、位置およびサイズは、主映像中のターゲットピクチャインピクチャ領域を正確に表すものとすることが指定される。
３．一例では、ｄａｔａ_ｕｎｉｔｓ_ｒｅｐｌａｃａｂｌｅが０に等しく、位置およびサイズ情報が存在するとき、位置およびサイズは、補助映像にオーバーレイして埋め込むための好ましい領域を示す(すなわち、クライアントは、主映像の異なる領域中に補助映像をオーバーレイすることを選択し得る)。
４．一例では、ｄａｔａ_ｕｎｉｔｓ_ｒｅｐｌａａｂｌｅが０に等しく、位置およびサイズ情報が存在するとき、位置およびサイズは、補助映像にオーバーレイして埋め込むための好ましい領域を示す(すなわち、クライアントは、主映像の異なる領域中に補助映像をオーバーレイすることを選択し得る)。
５．実施形態
以下は、例示的な実施形態の項目５および上記のセクション４に要約されたそのサブ項目のいくつかについてのいくつかの例示的な実施形態である。
これらの実施形態は、ＩＳＯＢＭＦＦに適用され得る。
５．１ピクチャインピクチャエンティティグループ化
５．１．１定義
ピクチャインピクチャサービスは、補助ビデオおよび主ビデオとそれぞれ呼ばれる、より大きい空間解像度を有するビデオ内により小さい空間解像度を有するビデオを含む能力を提供する。「ｐｉｎｐ」に等しいｇｒｏｕｐｉｎｇ_ｔｙｐｅを有する同じエンティティグループ内のトラックは、主映像を含むように示されるトラックのうちの１つ、および(補助映像を含む)他のトラックのうちの１つを選択することによって、ピクチャインピクチャサービスのサポートのために使用され得る。
ピクチャインピクチャエンティティグループ内のすべてのエンティティは、ビデオトラックであるものとする。
５．１．２構文
ａｌｉｇｎｅｄ(８) ｃｌａｓｓ ＰｉｃＩｎＰｉｃＥｎｔｉｔｙＧｒｏｕｐＢｏｘ ｅｘｔｅｎｄｓ ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ('ｐｉｎｐ',０,０) {
ｕｎｓｉｇｎｅｄ ｉｎｔ(８) ｎｕｍ_ｍａｉｎ_ｖｉｄｅｏ_ｔｒａｃｋｓ;
ｕｎｓｉｇｎｅｄ ｉｎｔ(１) ｄａｔａ_ｕｎｉｔｓ_ｒｅｐｌａｃａｂｌｅ;
ｕｎｓｉｇｎｅｄ ｉｎｔ(１) ｐｉｎｐ_ｗｉｎｄｏｗ_ｉｎｆｏ_ｐｒｅｓｅｎｔ;
ｂｉｔ (６) ｒｅｓｅｒｖｅｄ =
０;
ｉｆ(ｄａｔａ_ｕｎｉｔｓ_ｒｅｐｌａｃａｂｌｅ)
{
ｕｎｓｉｇｎｅｄ ｉｎｔ(８) ｎｕｍ_ｒｅｇｉｏｎ_ｉｄｓ;
ｆｏｒ(ｉ=０; ｉ<ｎｕｍ_ｒｅｇｉｏｎ_ｉｄｓ; ｉ++)
ｕｎｓｉｇｎｅｄ ｉｎｔ(１６) ｒｅｇｉｏｎ_ｉｄ[ｉ];
}
ｉｆ(ｐｉｎｐ_ｗｉｎｄｏｗ_ｉｎｆｏ_ｐｒｅｓｅｎｔ) {
ｕｎｓｉｇｎｅｄ ｉｎｔ(１６) ｘ;
ｕｎｓｉｇｎｅｄ ｉｎｔ(１６) ｙ;
ｕｎｓｉｇｎｅｄ ｉｎｔ(１６) ｗｉｄｔｈ;
ｕｎｓｉｇｎｅｄ ｉｎｔ(１６) ｈｅｉｇｈｔ;
}
}
５．１．３セマンティクス
ｎｕｍ_ｍａｉｎ_ｖｉｄｅｏ_ｔｒａｃｋｓは、ピクチャインピクチャ主映像を搬送するこのエンティティグループ中のトラックの数を指定する。
ｄａｔａ_ｕｎｉｔｓ_ｒｅｐｌａｃａｂｌｅは、主映像中のターゲットピクチャインピクチャ領域を表す符号化された映像データユニットが補助映像の対応する映像データユニットによって入れ替えるかどうかを示す。値１は、そのようなビデオデータユニット入替が有効にされることを示し、値０は、そのようなビデオデータユニット入替が有効にされないことを示す。
ｄａｔａ_ｕｎｉｔｓ_ｒｅｐｌａｃａｂｌｅが１に等しいとき、プレーヤは、復号のために映像復号化装置に送る前に、主映像中のターゲットピクチャインピクチャ領域を表す復号化された映像データユニットを補助映像の対応する符号化された映像データユニットと入れ替えることを選定し得る。この場合、主ビデオ中の特定のピクチャについて、補助ビデオの対応するビデオデータユニットは、補助ビデオトラック中の復号化時間同期サンプル中のすべての符号化されたビデオデータユニットである。ＶＶＣの場合、クライアントが、各サブピクチャＩＤについて、ビデオ復号化装置に送る前に、主ビデオ中のターゲットピクチャインピクチャ領域を表す(ＶＣＬ ＮＡＬユニットである)符号化されたビデオデータユニットを補助ビデオの対応するＶＣＬ ＮＡＬユニットと入れ替えることを選択したとき、主ビデオ中のＶＣＬ ＮＡＬユニットは、対応するＶＣＬ ＮＡＬユニットの順序を変更することなしに、補助ビデオ中のそのサブピクチャＩＤを有する対応するＶＣＬ ＮＡＬユニットと入れ替える。
１に等しいｐｉｎｐ_ｗｉｎｄｏｗ_ｉｎｆｏ_ｐｒｅｓｅｎｔは、フィールドｘ、ｙ、幅、および高さが存在することを指定する。値１は、これらのフィールドが存在しないことを指定する。
ｎｕｍ_ｒｅｇｉｏｎ_ｉｄｓは、後続のｒｅｇｉｏｎ_ｉｄ[ｉ]フィールドの数を指定する。
ｒｅｇｉｏｎ_ｉｄ[ｉ]は、ターゲットピクチャインピクチャ領域を表す符号化された映像データユニットのためのｉ番目のＩＤを指定する。
領域ＩＤの明確なセマンティクスは、特定のビデオコーデックのために明確的に指定される必要がある。ＶＶＣの場合、領域ＩＤはサブピクチャＩＤであり、符号化されたビデオデータユニットはＶＣＬ ＮＡＬユニットである。主ビデオ中のターゲットピクチャインピクチャ領域を表すＶＣＬ ＮＡＬユニットは、補助ビデオの対応するＶＣＬ ＮＡＬユニット中のサブピクチャＩＤと同じである、これらのサブピクチャＩＤを有するものである。
ｘは、主映像内のターゲットピクチャインピクチャ領域の左上符号化映像ピクセル(サンプル)の水平位置を指定する。単位はビデオピクセル(サンプル)である。
ｙは、主映像中のターゲットピクチャインピクチャ領域の左上の符号化映像ピクセル(サンプル)の垂直位置を指定する。単位はビデオピクセル(サンプル)である。
ｗｉｄｔｈは、主映像中のターゲットピクチャインピクチャ領域の幅を指定する。単位はビデオピクセル(サンプル)である。
ｈｅｉｇｈｔは、主映像中のターゲットピクチャインピクチャ領域の高さを指定する。単位はビデオピクセル(サンプル)である。
１．要約
本開示は、ビデオファイル形式に関する。具体的には、本開示は、メディア
ファイルにおけるメディア ファイルのサポートに関する。この考えは、例えば、ＩＳＯベースメディアファイル形式(ＩＳＯＢＭＦＦ)またはその拡張に基づいて、メディアファイルフォーマットに、個々にまたは様々な組合せで適用されてもよい。
２．背景技術
２．１ビデオ符号化規格
ビデオ符号化規格は、主に周知のＩＴＵ－ＴおよびＩＳＯ／ＩＥＣ規格の開発によって発展してきた。ＩＴＵ－ＴはＨ．２６１とＨ．２６３を作り、ＩＳＯ／ＩＥＣはＭＰＥＧ－１とＭＰＥＧ－４Ｖｉｓｕａｌを作り、両団体はＨ．２６２／ＭＰＥＧ－２ＶｉｄｅｏとＨ．２６４／ＭＰＥＧ－４
高度映像符号化（ＡＶＣ）とＨ．２６５／ＨＥＶＣ規格を共同で作った。Ｈ．２６２以降、ビデオ符号化規格は、時間予測と変換符号化が利用されるハイブリッドビデオ符号化構造に基づく。ＨＥＶＣを超えた将来のビデオ符号化技術を探索するため、２０１５年には、ＶＣＥＧとＭＰＥＧが共同で共同ビデオエキスパートチーム（ＪＶＥＴ）を設立した。それ以来、多くの新しい方法がＪＶＥＴによって採用され、ＪＥＭ（ＪｏｉｎｔＥｘｐｌｏｒａｔｉｏｎＭｏｄｅ）と呼ばれる参照ソフトウェアに組み込まれてきた。ＪＶＥＴは、後に汎用ビデオ符号化（ＶＶＣ）プロジェクトが正式に始まったとき、共同ビデオエキスパートチーム（ＪＶＥＴ）に改称された。ＶＶＣは新しい符号化規格であり、ＨＥＶＣに比べて５０％のビットレート低減を目指し、２０２０年７月１日に終了した第１９回ＪＶＥＴ総会において完成した。
汎用映像符号化（ＶＶＣ）規格（ＩＴＵ－Ｔ Ｈ．２６６｜ＩＳＯ／ＩＥＣ２３０９０－３）と汎用補助拡張情報（ＶＳＥＩ）規格（ＩＴＵ－Ｔ Ｈ．２７４｜ＩＳＯ／ＩＥＣ２３００２－７）は、テレビ放送、ビデオ会議、記憶媒体からの再生などの従来の用途に加え、適応ビットレートストリーミング、映像領域抽出、複数の符号化映像ビットストリームからのコンテンツの合成・結合、マルチビュー映像、スケーラブルレイヤードコーディング、ビューポートに適応した３６０°没入型メディアなど、より新しく、より高度な用途を含め、最大限に幅広いアプリケーションで使用できるように設計されている。
基本ビデオ符号化(ＥＶＣ)規格(ＩＳＯ/ＩＥＣ２３０９４-１)は、ＭＰＥＧによって最近開発された別のビデオ符号化規格である。
２．２ ファイル形式規格
メディアストリーミングアプリケーションは、一般的に、ＩＰ、ＴＣＰ、およびＨＴＴＰトランスポート方法に基づいており、一般的に、ＩＳＯベースのメディアファイルフォーマット（ＩＳＯＢＭＦＦ）［７］などのファイル形式に依存する。そのようなストリーミングシステムの１つは、ＨＴＴＰ（ＤＡＳＨ）を介した動的適応ストリーミングである。ＩＳＯＢＭＦＦおよびＤＡＳＨを有するビデオフォーマットを使用するために、ＩＳＯＢＭＦＦトラック並びにＤＡＳＨ表現およびセグメントにおけるビデオコンテンツのカプセル化のために、ＡＶＣファイル形式およびＨＥＶＣファイル形式のような、ビデオフォーマットに特定のファイル形式仕様が必要とされる。ビデオビットストリームに関する重要な情報、例えば、プロファイル、階層、レベル、その他多数は、コンテンツ選択のために、例えば、ストリーミングセッションの開始時の初期化およびストリーミングセッション中のストリーム適応の両方のために、ファイル形式レベルのメタデータおよび／またはＤＡＳＨメディアプレゼンテーション記述（ＭＰＤ）として公開される必要がある。
同様に、ＩＳＯＢＭＦＦを有するピクチャフォーマットを使用するために、ＡＶＣピクチャファイル形式およびＨＥＶＣピクチャファイル形式等の、ピクチャフォーマットに特定のファイル形式仕様が必要とされる。
ＩＳＯＢＭＦＦに基づくＶＶＣビデオコンテンツを記憶するためのファイル形式であるＶＶＣビデオビデオファイル形式は、現在、ＭＰＥＧによって開発されている。ＩＳＯＢＭＦＦに基づく、ＶＶＣを使用して符号化されたピクチャ内容を記憶するためのファイル形式であるＶＶＣピクチャファイル形式は、現在、ＭＰＥＧによって開発されている。
２．３ＶＶＣにおけるピクチャの分割およびサブピクチャ
ＶＶＣにおいて、１つのピクチャは、１つ以上のタイル行および１つ以上のタイル列に分割される。タイルは、ピクチャの矩形領域をカバーするＣＴＵのシーケンスである。１つのタイルは、１つのピクチャの１つの矩形領域を覆う１つのＣＴＵのシーケンスである。１つのタイルにおけるＣＴＵは、そのタイル内でラスタスキャン順にスキャンされる。
１つのスライスは、１つのピクチャのタイル内において、整数個の完全なタイルまたは整数個の連続した完全なＣＴＵ行によって構成されている。
２つのモードのスライス、即ち前記ラスタスキャンスライスモードおよび前記矩形スライスモードに対応している。前記ラスタスキャンスライスモードにおいて、１つのスライスは、１つのピクチャのタイルラスタスキャンにおける完全なタイルのシーケンスを含む。前記矩形スライスモードにおいて、１つのスライスは、前記ピクチャの矩形領域を集合的に形成する完全なタイルの数、または前記ピクチャの矩形領域を集合的に形成する１つのタイルの連続した完全なＣＴＵ行の数のいずれかを含む。矩形スライス内のタイルを、そのスライスに対応する矩形領域内で、タイルラスタスキャンの順にスキャンする。
１つのサブピクチャは、１つのピクチャの矩形領域を集合的に覆う１つ以上のスライスを含む。
２．３．１サブピクチャの概念および機能
ＶＶＣでは、各サブピクチャは、たとえば図４に示すように、ピクチャの矩形領域を集合的に覆う１つの唯一の矩形スライスで構成される。サブピクチャは、抽出可能であるように規定される(すなわち、同じピクチャの他のサブピクチャおよび復号化順で前のピクチャとは独立して符号化)か、または抽出不可能であるように規定してもよい。サブピクチャが抽出可能であるか否かにかかわらず、符号器は、(デブロッキング、ＳＡＯ、およびＡＬＦを含む)ループ内フィルタリングがサブピクチャの境界を越えて適用されるかどうかを各サブピクチャごとに個々に制御することができる。
機能的に、サブピクチャは、ＨＥＶＣにおける動き制約タイルセット(ＭＣＴＳ)と同様である。それらは両方とも、ビューポート依存３６０°ビデオストリーミング最適化および関心領域(ＲＯＩ)アプリケーションのような使用事例のために、符号化ピクチャのシーケンスの長方形サブセットの独立した符号化および抽出を可能にする。着目領域。
３６０°ビデオのストリーミング、とりわけ、全方向性ビデオでは、いかなる特定の瞬間にも、全方向性ビデオ球全体のサブセット(すなわち、現在のビューポート)のみがユーザに対して表示することになり、一方、利用者は、いつでも自分の首を回せ、視聴方向、したがって現在のビューポートを変更することができる。現在のビューポートによってカバーされないエリアの少なくともいくつかのより低い品質の表現をクライアントにおいて利用可能にし、ユーザが自分の閲覧方向を球体のどこかに突然変更した場合にユーザに対して表示する準備ができていることが望ましいが、全方向性ビデオの高品質表現は、いかなる時点においても、ユーザに対して表示されている現在のビューポートのみに必要とされる。全方位ビデオ全体の高品質表現を適切な粒度のサブピクチャに分割することは、１２個の高解像度サブピクチャを左側に有し、それより低い解像度で全方位ビデオの残りの１２個のサブピクチャを右側に有する図４に示すような最適化を可能にする。
他の典型的なサブピクチャベースのビューポート依存３６０°ビデオ配信スキームが図５に示されており、高めの解像度の表現のフルビデオのみがサブピクチャで構成され、一方で、低めの解像度の表現のフルビデオは、サブピクチャを使用せずに、高めの解像度の表現よりも少ない頻度のＲＡＰで符号化されることができる。クライアントは低めの解像度のフルビデオを受信する一方で、高めの解像度のビデオについて、クライアントは、現在ビューポートを覆うサブピクチャのみを受信して復号する。
２．３．２サブピクチャとＭＣＴＳとの間の違い
サブピクチャとＭＣＴＳとの間には幾つかの重要な設計上の違いがある。第１に、ＶＶＣにおけるサブピクチャ機能は、ピクチャ境界においてと同様に、この場合にはサブピクチャ境界においてサンプルパディングを適用することによって、サブピクチャが抽出可能である場合であっても、サブピクチャの外を指す符号化グブロックの動きベクトルを可能にする。第２に、マージモードおよびＶＶＣのデコーダ側動きベクトル精緻化プロセスにおける動きベクトルの選択及び導出のために追加の変更が導入された。これは、ＭＣＴＳに対して符号器側で適用される非標準の動き制約と比較してより高い符号化効率を可能にする。第３に、適合ビットストリームであるサブビットストリームを作成するためにピクチャのシーケンスから１つ以上の抽出可能なサブピクチャを抽出するときに、ＳＨ（及び、存在する場合にＰＨ ＮＡＬユニット）の書き換えが必要とされない。ＨＥＶＣ ＭＣＴＳに基づくサブビットストリーム抽出では、ＳＨの書き換えが必要とされる。なお、ＨＥＶＣ ＭＣＴＳ抽出及びＶＶＣサブピクチャ抽出のどちらでも、ＳＰＳ及びＰＰＳの書き換えは必要とされる。しかしながら、典型的に、ビットストリーム内には少しのパラメータセットしか存在しない一方で、各ピクチャは少なくとも１つのスライスを持ち、従って、ＳＨの書き換えはアプリケーションシステムにとってかなりの負担となり得る。第４に、ピクチャ内の異なるサブピクチャのスライスは異なるＮＡＬユニットタイプを持つことが許される。これは、以下でより詳細に説明される、ピクチャ内の混合ＮＡＬユニットタイプまたは混合サブピクチャタイプとしばしば呼ばれる特徴である。第５に、ＶＶＣは、サブピクチャシーケンスについてのＨＲＤおよびレベル定義を規定しており、従って、抽出可能なサブピクチャシーケンス各々のサブビットストリームの適合性がエンコーダによって保証され得る。
２．３．３ピクチャ内の混合サブピクチャタイプ
ＡＶＣおよびＨＥＶＣでは、ピクチャ内のすべてのＶＣＬ ＮＡＬユニットが同じＮＡＬユニットタイプを持つ必要がある。ＶＶＣは、特定の相異なるＶＣＬ ＮＡＬユニットタイプを持つサブピクチャ同士をピクチャを混ぜるオプションを導入し、従って、ピクチャレベルだけでなくサブピクチャレベルでも、ランダムアクセスに対するサポートを提供する。ＶＶＣにおいて、サブピクチャ内のＶＣＬ ＮＡＬユニットは、同じＮＡＬユニットタイプを持つことが依然として必要とされる。
ＩＲＡＰサブピクチャからのランダムアクセスの能力は、３６０°ビデオアプリケーションにとって有益である。図５に示したものと同様のビューポート依存３６０°ビデオ配信スキームにおいて、空間的に隣接するビューポートのコンテンツ同士が大きく重なり合い、すなわち、ビューポート内のサブピクチャのうちの一部のみがビューポートの向きの変更中に新しいサブピクチャによって入れ替え、大部分のサブピクチャはビューポート内に留まる。ビューポートに新たに導入されるサブピクチャシーケンスは、ＩＲＡＰスライスで開始しなければならないが、残りのサブピクチャがビューポート変更時にインター予測を実行することを可能にされるとき、全体的な伝送ビットレートの大幅な低減を達成することができる。
ピクチャがただ１つのタイプのＮＡＬユニットを含むのか、２つ以上のタイプを含むのかの指示が、そのピクチャによって参照されるＰＰＳ内で（すなわち、ｐｐｓ_ｍｉｘｅｄ_ｎａｌｕ_ｔｙｐｅｓ_ｉｎ_ｐｉｃ_ｆｌａｇと呼ばれるフラグを用いて）提供される。ピクチャは、ＩＲＡＰスライスを含むサブピクチャと、トレーリングスライスを含むサブピクチャを同時に構成され得る。ＮＡＬユニットタイプＲＡＳＬ及びＲＡＤＬのリーディングピクチャスライスを含め、ピクチャ内での異なるＮＡＬユニットタイプの他の組み合わせも少数ながら可能にされ、これは、異なるビットストリームから抽出されたオープンＧＯＰ及びクローズＧＯＰ符号化構造を有するサブピクチャシーケンスを１つのビットストリームにマージすることを可能にする。
２．３．４サブピクチャレイアウトおよびＩＤ信号通知
ＶＶＣにおけるサブピクチャのレイアウトはＳＰＳ内で信号通知され、従って、ＣＬＶＳ内で一定である。各サブピクチャは、その左上ＣＴＵの位置、並びにＣＴＵ数でのその幅及び高さによって信号通知され、従って、サブピクチャがＣＴＵ粒度でピクチャの矩形領域をカバーすることが保証される。それらのサブピクチャがＳＰＳ内で信号通知される順序が、ピクチャ内の各サブピクチャのインデックスを決定する。
ＳＨまたはＰＨの書き換えなくサブピクチャシーケンスの抽出及びマージを可能にするために、ＶＶＣにおけるスライスアドレシングスキームは、サブピクチャＩＤ、及びスライスをサブピクチャに関連付けるためのサブピクチャ固有スライスインデックスに基づく。ＳＨでは、そのスライスを含むサブピクチャのサブピクチャＩＤ及びサブピクチャレベルスライスインデックスが信号通知される。なお、特定のサブピクチャのサブピクチャＩＤの値は、そのサブピクチャインデックスの値とは異なることができる。２つの間のマッピングは、ＳＰＳ又はＰＰＳ（しかし、決して両方ではない）内で信号通知されるか、又は黙示的に推定されるかのいずれかである。存在する場合、サブピクチャＩＤマッピングは、サブピクチャサブビットストリーム抽出プロセスでＳＰＳ及びＰＰＳを書き換えるときに書き換えられるか又は追加されるかする必要がある。サブピクチャＩＤ及びサブピクチャレベルスライスインデックスの両方は、復号ピクチャのＤＰＢスロット内のスライスの最初の復号ＣＴＵの正確な位置をデコーダに示す。サブビットストリーム抽出の後、サブピクチャのサブピクチャＩＤは変更されないままであるが、サブピクチャインデックスは変わり得る。サブピクチャ内のスライス内の最初のＣＴＵのラスタスキャンＣＴＵアドレスが元のビットストリームでの値と比較して変化した時であっても、各自のＳＨ内のサブピクチャＩＤ及びサブピクチャレベルスライスインデックスの変化していない値がなおも、抽出されたサブビットストリームの復号ピクチャ内の各ＣＴＵの位置を正確に決定する。図６は、２つのサブピクチャおよび４つのスライスを含む例を用いてサブピクチャ抽出を可能にするためのサブピクチャＩＤ、サブピクチャインデックスおよびサブピクチャレベルスライスインデックスの使用を示す。
サブピクチャ抽出と同様に、サブピクチャについての信号通知は、異なるビットストリームが協調的に生成される(たとえば、別個のサブピクチャＩＤを使用するが、それ以外は、ＣＴＵサイズ、クロマフォーマット、符号化ツールなど、ほぼ整合されたＳＰＳ、ＰＰＳ、およびＰＨパラメータを使用して)という条件で、ＳＰＳおよびＰＰＳを書き換えるだけで、異なるビットストリームからのいくつかのサブピクチャを１つのビットストリームにマージすることを可能にする。
サブピクチャ及びスライスは、それぞれ、ＳＰＳ及びＰＰＳ内で独立に信号通知されるが、適合ビットストリームを形成するために、サブピクチャレイアウトとスライスレイアウトとの間に固有の相互制約が存在する。第１に、サブピクチャの存在は、矩形スライスを用いることを必要とし、ラスタスキャンスライスを禁止する。第２に、所与のサブピクチャのスライスは、復号化の順序で連続したＮＡＬユニットであるとされ、これが意味することは、サブピクチャレイアウトが、ビットストリーム内の符号化されるスライスＮＡＬユニットの順序を制約するものとする。
２．４ピクチャインピクチャサービス
ピクチャインピクチャサービスは、より大きい解像度を有するピクチャ内に、小さい解像度を有するピクチャを含む能力を提供する。そのようなサービスは、２つのビデオをユーザに同時に示すのに有益であり得、それによって、より大きい解像度を有するビデオが主ビデオと見なされ、より小さい解像度を有するビデオが補助ビデオと見なされる。そのようなピクチャインピクチャサービスは、主ビデオがサイネージビデオによって補完されるアクセシビリティサービスを提供するために使用され得る。
ＶＶＣサブピクチャは、ＶＶＣサブピクチャの抽出特性とマージ特性の両方を使用することによって、ピクチャインピクチャサービスに使用できる。そのようなサービスの場合、主ビデオは、いくつかのサブピクチャを使用して符号化され、サブピクチャのうちの１つは、補助ビデオと同じサイズであり、補助ビデオが主ビデオに合成されることが意図される正確な位置に配置され、抽出を可能にするために独立に符号化される。ユーザが補助ビデオを含むバージョンのサービスを視聴することを選択した場合、図７に示すように、主ビデオのピクチャインピクチャ領域に対応するサブピクチャが主ビデオビットストリームから抽出され、補助ビデオビットストリームがその場所で主ビデオビットストリームとマージされる。図７は、ＶＶＣサブピクチャに基づくピクチャインピクチャサポートの一例を示す。
この場合、主ビデオおよび補助ビデオのピクチャは、同じビデオ特性を共有しなければならず、特に、ビット深度、サンプルアスペクト比、サイズ、フレームレート、色空間および伝達特性、クロマサンプル位置が同じでなければならない。主および補助ビデオビットストリームは、各ピクチャ内のＮＡＬユニットタイプを使用する必要はない。しかしながら、マージングは、主および補助ビットストリーム中のピクチャの符号化の順序が同じであることを必要とする。
サブピクチャのマージングがここで必要とされるので、主ビデオおよび補助ビデオ内で使用されるサブピクチャＩＤは重複することができない。補助ビデオビットストリームが更なるタイルまたはスライス分割なしに１つのサブピクチャのみから構成される場合であっても、補助ビデオビットストリームの主ビデオビットストリームとのマージングを可能にするために、サブピクチャ情報、特にサブピクチャＩＤおよびサブピクチャＩＤ長が信号通知される必要がある。前記補助ビデオビットストリームのスライスＮＡＬユニット内のサブピクチャＩＤ構文要素の長さを信号通知するために使用されるサブピクチャＩＤ長は、主ビデオビットストリームのスライスＮＡＬユニット内のサブピクチャＩＤを信号通知するために使用されるサブピクチャＩＤ長と同じでなければならない。さらに、ＰＰＳ区分情報を書き換える必要なしに補助ビデオビットストリームを主ビデオビットストリームとマージすることを簡略化するために、主ビデオの対応するエリア内で、１つのスライスおよび１つのタイルのみを使用して補助ビデオを符号化することが有益であり得る。主および補助ビデオビットストリームは、ＳＰＳ、ＰＰＳおよびピクチャヘッダ中で同じ符号化ツールを信号通知しなければならない。それは、ブロック区分のための同じ最大および最小許容サイズと、ＰＰＳ中で信号通知されるものと同じ初期量子化パラメータの値(ｐｐｓ_ｉｎｉｔ_ｑｐ_ｍｉｎｕｓ２６構文要素の同じ値)とを使用することを含む。符号化ツールの使用は、スライスヘッダレベルで修正することができる。
主および補助ビットストリームの両方がＩＳＯＢＭＦＦベースのメディアファイルにおいて利用可能であるとき、主および補助ビットストリームは、２つの別個のファイル形式トラックに記憶することができる。
３．課題
ＩＳＯＢＭＦＦベースのメディアファイルにおけるピクチャインピクチャのサポートについて、以下の課題が観察されてきた。
１）ピクチャインピクチャ主および補助ビットストリームを別々に記憶するために異なるファイル形式トラックを使用することが可能であるが、ＩＳＯＢＭＦＦに基づくメディアファイル中のトラックのそのようなペアについてそのような目的の指示のための機構を欠く。
２）例えば上述したように、ピクチャインピクチャエクスペリエンスのためにＶＶＣサブピクチャを使用することが可能であるが、主ビデオ中のターゲットピクチャインピクチャ領域を表す符号化されたビデオデータユニットを補助ビデオの対応するビデオデータユニットと入れ替えることができない他のコーデックおよび方法を使用することも可能である。したがって、そのような入替が可能であるかどうかをＩＳＯＢＭＦＦベースのメディアファイル中で示す必要がある。
３）上記の入替が可能である場合、クライアントは、入替を実行することができるように、主ビデオの各ピクチャ中のどの符号化されたビデオデータユニットがターゲットピクチャインピクチャ領域を表すかを知る必要がある。したがって、この場合、この情報は、ＩＳＯＢＭＦＦベースのメディアファイル中で信号通知される必要がある。
４）コンテンツ選択目的および場合によっては他の目的のためにも、ＩＳＯＢＭＦＦベースのメディアファイル中で、主ビデオ中のターゲットピクチャインピクチャ領域の位置およびサイズを信号通知することは有用になるであろう。
４．例示的な実施形態
上述した課題を解決するために、以下に示す方法が開示されている。本実施形態は、一般概念を説明するための例と見なされるべきであり、狭義に解釈されるべきではない。さらに、これらの実施形態は、個々に適用されてもよく、または任意の方法で組み合わされてもよい。説明の都合上、一体となってピクチャインピクチャエクスペリエンスを与える主および補助ビットストリームを担持するトラックのペアは、ピクチャインピクチャトラックのペアまたはピクチャインピクチャトラックペアと呼ばれる。
１）第１の課題を解決するために、トラックリファレンスを含むトラックおよびトラックリファレンスによって参照されるトラックがピクチャインピクチャトラックのペアであることを示すために、新しいタイプのトラックリファレンスが定義される。
ａ．一例では、この新しいタイプのトラックリファレンスは、特定の値に等しいトラックリファレンスタイプ、たとえば、「ｐｉｐｓ」(「ピクチャインピクチャ補助ビットストリームを参照すること」を意味する)によって示され、このトラックリファレンスを含むトラックはメインビットストリームを搬送し、トラックリファレンスによって参照されるトラックは補助ビットストリームを搬送する。
ｂ．別の例では、この新しいタイプのトラックリファレンスは、特定の値に等しいトラックリファレンスタイプ、たとえば、「ｐｉｐｍ」(「ピクチャインピクチャ メイン ビットストリームを参照すること」を意味する)によって示され、このトラックリファレンスを含むトラックは補助ビットストリームを搬送し、トラックリファレンスによって参照されるトラックは補助ビットストリームを搬送する。
ｃ．さらに別の例において、上記で説明した両方のトラックリファレンスタイプが定義される。
２）第１および第２の課題を解決するために、メインビットストリームを担持するトラック中に含まれるべき２つの新しいタイプのトラックリファレンスが定義され、一方は、主ビデオ中のターゲットピクチャインピクチャ領域を表す符号化されたビデオデータユニットを補助ビットストリームの対応するビデオデータユニットと入れ替えることを可能にするピクチャインピクチャトラックのペアを示し、他方は、そのようなビデオデータユニット入替が可能にされないピクチャインピクチャトラックのペアを示す。
ａ．一例では、これらの２つの新しいタイプのトラックリファレンスは、それぞれ、「ｐｐｓｒ」(「映像データユニット入替が有効化された、ピクチャインピクチャ補助ビットストリームを指すこと」を意味する)および「ｐｐｓｎ」(「映像データユニット入替が有効化されていない、ピクチャインピクチャ補助ビットストリームを指すこと」を意味する)に等しいトラックリファレンスタイプ値によって示される。
３）第１および第２の課題を解決するために、代替的に、補助ビットストリームを担持するトラック中に含まれるべき２つの新しいタイプのトラックリファレンスが定義され、一方は、主ビデオ中のターゲットピクチャインピクチャ領域を表す符号化されたビデオデータユニットを補助ビデオの対応するビデオデータユニットと入れ替えることを可能にするピクチャインピクチャトラックのペアを示し、他方は、そのようなビデオデータユニット入替が可能にされないピクチャインピクチャトラックのペアを示す。
ａ．一例では、これらの２つの新しいタイプのトラックリファレンスは、それぞれ、「ｐｐｍｒ」(「映像データユニット入替が有効化された、ピクチャインピクチャメインビットストリームを指すこと」を意味する)および「ｐｐｍｎ」(「映像データユニット入替が有効化されていない、ピクチャインピクチャメインビットストリームを指すこと」を意味する)に等しいトラックリファレンスタイプ値によって示される。
４）第１および第２の課題を解決するために、代替的に、上記の項目２および３に記載された４つの新しいタイプのトラックリファレンスが定義される。
５）第４の課題すべてを解決するために、以下に示す新しいタイプのエンティティグループ化が定義される。
ａ．新しいタイプのエンティティグループ化は、ピクチャインピクチャエンティティグループ化と命名され、ｇｒｏｕｐｉｎｇ_ｔｙｐｅは「ｐｉｎｐ」に等しい(または、異なる名前もしくは異なるグループ化タイプ値であるが、以下で説明するように同様の特徴を有する)。
ｂ．一例では、エンティティグループ内の各エンティティがビデオトラックでなければならないことが指定される。
ｃ．ＰｉｃＩｎＰｉｃＥｎｔｉｔｙＧｒｏｕｐＢｏｘは、ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘを拡張することによって、以下の情報のうちの少なくとも１つまたは複数を搬送するように定義された。
ｉ．メインビットストリームトラックの数Ｎ。ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ中の最初のＮ個のｅｎｔｉｔｙ_ｉｄ値によって識別されるエンティティ(すなわち、このコンテキストではトラック)はメインビットストリームトラックであり、ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ中の他のｅｎｔｉｔｙ_ｉｄ値によって識別されるエンティティは補助ビットストリームトラックである。ピクチャインピクチャエクスペリエンスを再生するために、メインビットストリームトラックのうちの１つが選択され、補助ビットストリームトラックのうちの１つが選択される。
１．代替的に、メインビットストリームトラックは、ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ中のｅｎｔｉｔｙ_ｉｄ値のリストへのインデックスのリストによって信号通知され、エンティティグループ中の他のエンティティ/トラックは補助ビットストリームトラックである。
２．代替的に、メインビットストリームトラックは、ｔｒａｃｋ_ｉｄ値のリストへのインデックスのリストによって信号通知され、エンティティグループ中の他のエンティティ/トラックは補助ビットストリームトラックである。
ｉｉ．主ビデオ中のターゲットピクチャインピクチャ領域を表す符号化されたビデオデータユニットを補助ビデオの対応するビデオデータユニットと入れ替えることが可能であるかどうかを示す指示。
１．一例では、標示は、ｄａｔａ_ｕｎｉｔｓ_ｒｅｐｌａｃａｂｌｅと称する１ビットフラグによって信号通知され、値１および０は、それぞれ、そのような映像データユニット入替が有効および無効であることを示す。
ｉｉｉ．主ビデオの各ピクチャ中のどの符号化されたビデオデータユニットがターゲットピクチャインピクチャ領域を表すかを示すための領域ＩＤのリスト。
１．一例では、領域ＩＤの明確的セマンティクスが特定のビデオコーデックのために明確的に指定される必要があることが指定される。
ａ．一例では、ＶＶＣの場合、領域ＩＤはサブピクチャＩＤであり、符号化されたビデオデータユニットはＶＣＬ ＮＡＬユニットであることが指定される。主ビデオ中のターゲットピクチャインピクチャ領域を表すＶＣＬ ＮＡＬユニットは、補助ビデオの対応するＶＣＬ ＮＡＬユニット中のサブピクチャＩＤと同じである、これらのサブピクチャＩＤを有するものである(一般に、補助ビデオ中の１つのピクチャのすべてのＶＣＬ ＮＡＬユニットは、明確的に信号通知される同じサブピクチャＩＤを共有し、この場合、領域ＩＤのリスト中に１つの領域ＩＤのみがある)。
ｂ．一例では、ＶＶＣの場合、クライアントが、ビデオ復号化装置に送る前に、主ビデオ中のターゲットピクチャインピクチャ領域を表す(ＶＣＬ ＮＡＬユニットである)符号化されたビデオデータユニットを補助ビデオの対応するＶＣＬ ＮＡＬユニットと入れ替えることをクライアントが選定したとき、サブピクチャＩＤごとに、主ビデオ中のＶＣＬ ＮＡＬユニットは、対応するＶＣＬ ＮＡＬユニットの順序を変更することなしに、補助ビデオ中のそのサブピクチャＩＤを有する対応するＶＣＬ ＮＡＬユニットと入れ替えることが規定される。
ｉｖ．主ビデオよりもサイズが小さい補助ビデオを埋め込む/オーバーレイするための主ビデオ内の位置およびサイズ。
１．一例では、これは、４つの値(ｘ、ｙ、幅、高さ)を信号通知することによって信号通知され、ｘ、ｙは領域の左上の位置を指定し、幅および高さは領域の幅および高さを指定する。単位は、ルーマサンプル/ピクセルであり得る。
２．一例では、ｄａｔａ_ｕｎｉｔｓ_ｒｅｐｌａｃａｂｌｅが１に等しく、位置およびサイズ情報が存在するとき、位置およびサイズは、主映像中のターゲットピクチャインピクチャ領域を正確に表すものとすることが指定される。
３．一例では、ｄａｔａ_ｕｎｉｔｓ_ｒｅｐｌａｃａｂｌｅが０に等しく、位置およびサイズ情報が存在するとき、位置およびサイズは、補助映像にオーバーレイして埋め込むための好ましい領域を示す(すなわち、クライアントは、主映像の異なる領域中に補助映像をオーバーレイすることを選択し得る)。
４．一例では、ｄａｔａ_ｕｎｉｔｓ_ｒｅｐｌａａｂｌｅが０に等しく、位置およびサイズ情報が存在するとき、位置およびサイズは、補助映像にオーバーレイして埋め込むための好ましい領域を示す(すなわち、クライアントは、主映像の異なる領域中に補助映像をオーバーレイすることを選択し得る)。
５．実施形態
以下は、例示的な実施形態の項目５および上記のセクション４に要約されたそのサブ項目のいくつかについてのいくつかの例示的な実施形態である。
これらの実施形態は、ＩＳＯＢＭＦＦに適用され得る。
５．１ピクチャインピクチャエンティティグループ化
５．１．１定義
ピクチャインピクチャサービスは、補助ビデオおよび主ビデオとそれぞれ呼ばれる、より大きい空間解像度を有するビデオ内により小さい空間解像度を有するビデオを含む能力を提供する。「ｐｉｎｐ」に等しいｇｒｏｕｐｉｎｇ_ｔｙｐｅを有する同じエンティティグループ内のトラックは、主映像を含むように示されるトラックのうちの１つ、および(補助映像を含む)他のトラックのうちの１つを選択することによって、ピクチャインピクチャサービスのサポートのために使用され得る。
ピクチャインピクチャエンティティグループ内のすべてのエンティティは、ビデオトラックであるものとする。
５．１．２構文
ａｌｉｇｎｅｄ(８) ｃｌａｓｓ ＰｉｃＩｎＰｉｃＥｎｔｉｔｙＧｒｏｕｐＢｏｘ ｅｘｔｅｎｄｓ ＥｎｔｉｔｙＴｏＧｒｏｕｐＢｏｘ('ｐｉｎｐ',０,０) {
ｕｎｓｉｇｎｅｄ ｉｎｔ(８) ｎｕｍ_ｍａｉｎ_ｖｉｄｅｏ_ｔｒａｃｋｓ;
ｕｎｓｉｇｎｅｄ ｉｎｔ(１) ｄａｔａ_ｕｎｉｔｓ_ｒｅｐｌａｃａｂｌｅ;
ｕｎｓｉｇｎｅｄ ｉｎｔ(１) ｐｉｎｐ_ｗｉｎｄｏｗ_ｉｎｆｏ_ｐｒｅｓｅｎｔ;
ｂｉｔ (６) ｒｅｓｅｒｖｅｄ =
０;
ｉｆ(ｄａｔａ_ｕｎｉｔｓ_ｒｅｐｌａｃａｂｌｅ)
{
ｕｎｓｉｇｎｅｄ ｉｎｔ(８) ｎｕｍ_ｒｅｇｉｏｎ_ｉｄｓ;
ｆｏｒ(ｉ=０; ｉ<ｎｕｍ_ｒｅｇｉｏｎ_ｉｄｓ; ｉ++)
ｕｎｓｉｇｎｅｄ ｉｎｔ(１６) ｒｅｇｉｏｎ_ｉｄ[ｉ];
}
ｉｆ(ｐｉｎｐ_ｗｉｎｄｏｗ_ｉｎｆｏ_ｐｒｅｓｅｎｔ) {
ｕｎｓｉｇｎｅｄ ｉｎｔ(１６) ｘ;
ｕｎｓｉｇｎｅｄ ｉｎｔ(１６) ｙ;
ｕｎｓｉｇｎｅｄ ｉｎｔ(１６) ｗｉｄｔｈ;
ｕｎｓｉｇｎｅｄ ｉｎｔ(１６) ｈｅｉｇｈｔ;
}
}
５．１．３セマンティクス
ｎｕｍ_ｍａｉｎ_ｖｉｄｅｏ_ｔｒａｃｋｓは、ピクチャインピクチャ主映像を搬送するこのエンティティグループ中のトラックの数を指定する。
ｄａｔａ_ｕｎｉｔｓ_ｒｅｐｌａｃａｂｌｅは、主映像中のターゲットピクチャインピクチャ領域を表す符号化された映像データユニットが補助映像の対応する映像データユニットによって入れ替えるかどうかを示す。値１は、そのようなビデオデータユニット入替が有効にされることを示し、値０は、そのようなビデオデータユニット入替が有効にされないことを示す。
ｄａｔａ_ｕｎｉｔｓ_ｒｅｐｌａｃａｂｌｅが１に等しいとき、プレーヤは、復号のために映像復号化装置に送る前に、主映像中のターゲットピクチャインピクチャ領域を表す復号化された映像データユニットを補助映像の対応する符号化された映像データユニットと入れ替えることを選定し得る。この場合、主ビデオ中の特定のピクチャについて、補助ビデオの対応するビデオデータユニットは、補助ビデオトラック中の復号化時間同期サンプル中のすべての符号化されたビデオデータユニットである。ＶＶＣの場合、クライアントが、各サブピクチャＩＤについて、ビデオ復号化装置に送る前に、主ビデオ中のターゲットピクチャインピクチャ領域を表す(ＶＣＬ ＮＡＬユニットである)符号化されたビデオデータユニットを補助ビデオの対応するＶＣＬ ＮＡＬユニットと入れ替えることを選択したとき、主ビデオ中のＶＣＬ ＮＡＬユニットは、対応するＶＣＬ ＮＡＬユニットの順序を変更することなしに、補助ビデオ中のそのサブピクチャＩＤを有する対応するＶＣＬ ＮＡＬユニットと入れ替える。
１に等しいｐｉｎｐ_ｗｉｎｄｏｗ_ｉｎｆｏ_ｐｒｅｓｅｎｔは、フィールドｘ、ｙ、幅、および高さが存在することを指定する。値１は、これらのフィールドが存在しないことを指定する。
ｎｕｍ_ｒｅｇｉｏｎ_ｉｄｓは、後続のｒｅｇｉｏｎ_ｉｄ[ｉ]フィールドの数を指定する。
ｒｅｇｉｏｎ_ｉｄ[ｉ]は、ターゲットピクチャインピクチャ領域を表す符号化された映像データユニットのためのｉ番目のＩＤを指定する。
領域ＩＤの明確なセマンティクスは、特定のビデオコーデックのために明確的に指定される必要がある。ＶＶＣの場合、領域ＩＤはサブピクチャＩＤであり、符号化されたビデオデータユニットはＶＣＬ ＮＡＬユニットである。主ビデオ中のターゲットピクチャインピクチャ領域を表すＶＣＬ ＮＡＬユニットは、補助ビデオの対応するＶＣＬ ＮＡＬユニット中のサブピクチャＩＤと同じである、これらのサブピクチャＩＤを有するものである。
ｘは、主映像内のターゲットピクチャインピクチャ領域の左上符号化映像ピクセル(サンプル)の水平位置を指定する。単位はビデオピクセル(サンプル)である。
ｙは、主映像中のターゲットピクチャインピクチャ領域の左上の符号化映像ピクセル(サンプル)の垂直位置を指定する。単位はビデオピクセル(サンプル)である。
ｗｉｄｔｈは、主映像中のターゲットピクチャインピクチャ領域の幅を指定する。単位はビデオピクセル(サンプル)である。
ｈｅｉｇｈｔは、主映像中のターゲットピクチャインピクチャ領域の高さを指定する。単位はビデオピクセル(サンプル)である。
【0058】
本開示の実施形態は、ピクチャインピクチャサポートのためのファイル形式設計に関する。本明細書で用いる、「ピクチャインピクチャ(ＰｉＰ)サービス」は、より大きい空間解像度を有するビデオ(「主ビデオ」とも呼ばれる)内に、より小さい空間解像度を有するビデオ(「補助ビデオ」または「ＰｉＰビデオ」とも呼ばれる)を含む能力を提供する。
【0059】
図８は、本開示のいくつかの実施形態による、ビデオ処理のための方法８００についてのフローチャートである。方法８００は、クライアントまたはサーバにおいて実装されてもよい。本明細書で使用される「クライアント」という用語は、コンピュータネットワークのクライアント-サーバモデルの一部としてサーバによって利用可能にされたサービスにアクセスする１つのコンピュータハードウェアまたはソフトウェアを指すことができる。例として、クライアントはスマートフォンまたはタブレットであってもよい。本明細書で使用される「サーバ」という用語は、コンピューティングが可能な装置を指すことがあり、その場合、クライアントはネットワークを介してサービスにアクセスする。サーバは、物理的なコンピューティング装置であってもよいし、仮想的なコンピューティング装置であってもよい。
【0060】
図８に示されるように、方法８００は８０２で開始し、第１のビデオのメディアファイルと第１のビデオのビットストリームとの間の変換を実行する。前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、ビデオ処理方法。一例として、第１のビデオの空間解像度が第２のビデオの空間解像度より小さい場合、指示は「ｐｉｐｍ」トラックリファレンスであり得る。すなわち、「ｐｉｐｍ」トラックリファレンスを担持するトラックは、補助ビデオのビットストリームを担持し、トラックリファレンスによって参照されるトラックは、主ビデオのビットストリームを担持する。上記の例は、単に説明のために記載されていることが理解されるべきである。本開示の範囲は、この点において限定されない。
【0061】
方法８００によれば、２つのトラックがピクチャインピクチャサービスを提供するためのトラックペアであることを示すために指示が採用される。それによって、提案される方法は、有利なことに、ＩＳＯＢＭＦＦに基づくメディアファイル中のピクチャインピクチャサービスをサポートすることを可能にする。
【0062】
いくつかの実施形態において、指示は、第１のタイプのトラックリファレンスを含んでもよい。また、トラックリファレンスは、第２のトラックを示してもよい。一例では、上記で説明したように、第１のビデオの空間解像度が第２のビデオの空間解像度よりも小さい場合、第１のタイプのトラックリファレンスは「ｐｉｐｍ」トラックリファレンスである。別の例では、第２のビデオの空間解像度が第１のビデオの空間解像度よりも小さい場合、第１のタイプのトラックリファレンスは「ｐｉｐｓ」トラックリファレンスである。すなわち、「ｐｉｐｓ」トラックリファレンスを担持するトラックは、主ビデオのビットストリームを担持し、トラックリファレンスによって参照されるトラックは、補助ビデオのビットストリームを担持する。
【0063】
いくつかの実施形態において、第２のビデオのメディアファイルはまた、第１のトラックおよび第２のトラックがピクチャインピクチャサービスを提供するためのトラックペアであることを示す第２のタイプのトラックリファレンスを含んでもよい。示例的に、第１のビデオの空間解像度が第２のビデオの空間解像度よりも小さい場合、第２のタイプのトラックリファレンスは「ｐｉｐｓ」トラックリファレンスである。
【0064】
いくつかの実施形態において、変換は、メディアファイルを生成して前記ビットストリームを前記メディアファイルに記憶することを含んでもよい。いくつかの追加的または代替的な実施形態では、変換は、前記メディアファイルを解析して前記ビットストリームを再構築することを含んでもよい。
【0065】
いくつかの実施形態において、第１のビデオのビットストリームは、非一時的なコンピュータ可読記録媒体に記憶されてもよい。第１のビデオのビットストリームは、ビデオ処理装置によって実行される方法によって生成させることができる。この方法によれば、第１のビデオのメディアファイルとビットストリームとの間の変換を実行する。前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、ビデオ処理方法。
【0066】
いくつかの実施形態において、第１のビデオのメディアファイルとビットストリームとの間の変換を実行する。前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む。前記ビットストリームを非一時的なコンピュータ可読記録媒体に記憶されてもよい。
【0067】
いくつかの実施形態において、第１のビデオのメディアファイルは、非一時的なコンピュータ可読記録媒体に記憶されてもよい。前記第１のビデオのメディアファイルは、ビデオ処理装置によって実行される方法によって生成させることができる。この方法によれば、第１のビデオのメディアファイルとビットストリームとの間の変換を実行する。前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、ビデオ処理方法。
【0068】
いくつかの実施形態において、第１のビデオのメディアファイルとビットストリームとの間の変換を実行する。前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む。前記メディアファイルは、非一時的なコンピュータ可読記録媒体に記憶されてもよい。
【0069】
本開示の実施態様は、以下の条項を考慮して説明することができ、その特徴は、任意の妥当な態様で組み合わせることができる。
【0070】
項目１：第１のビデオのメディアファイルと前記第１のビデオのビットストリームとの間の変換を実行するステップを含み、ビデオ処理のための方法であって、前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を備える方法、ビデオ処理方法。
【0071】
項目２：前記指示は、第１のタイプのトラックリファレンスを含む、項目１に記載の方法。
【0072】
項目３：第１のビデオの空間解像度が第２のビデオの空間解像度よりも小さく、前記第１のタイプのトラックリファレンスが「ｐｉｐｍ」トラックリファレンスである、項目２に記載の方法。
【0073】
項目４：第２のビデオの空間解像度が第１のビデオの空間解像度よりも小さく、第１のタイプのトラックリファレンスが「ｐｉｐｓ」トラックリファレンスであって、項目２に記載の方法。
【0074】
項目５：トラックリファレンスは、第２のトラックを示す、条項２～４のいずれか１項に記載の方法。
【0075】
項目６：前記第２のビデオのメディアファイルは、第２のタイプのトラックリファレンスを含み、前記第２のタイプのトラックリファレンスは、前記第１のトラックと第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを指示する、項目２～５のいずれか１項に記載の方法。
【0076】
項目７：前記変換は、前記メディアファイルを生成して前記ビットストリームを前記メディアファイルに記憶することを含む、項目１～６のいずれか１項に記載の方法。
【0077】
項目８：前記変換は、前記メディアファイルを解析して前記ビットストリームを再構築することを含む、項目１～６のいずれか１項に記載の方法。
【0078】
項目９：プロセッサと、命令を有する非一時的なメモリとを備え、前記命令が前記プロセッサによって実行されると、前記プロセッサに、項目１～８のいずれか１項に記載の方法を実行させる、ビデオデータを処理するための装置。
【0079】
項目１０：プロセッサに項目１～８のいずれか１項に記載の方法を実行させる命令を記憶する非一時的なコンピュータ可読記憶媒体。
【0080】
項目１１：ビデオ処理装置によって実行される方法によって生成された第１のビデオのビットストリームを記憶し、前記方法は、前記第１のビデオのメディアファイルと前記ビットストリームとの間の変換を実行するステップを含み、前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、非一時的なコンピュータ可読記録媒体。
【0081】
項目１２：第１のビデオのビットストリームを記憶するための方法であって、前記第１のビデオのメディアファイルと前記ビットストリームとの間の変換を実行するステップと、前記ビットストリームを非一時的なコンピュータ可読記録媒体に記憶するステップと、を含み、前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、ビデオ処理方法。
【0082】
項目１３：ビデオ処理装置によって実行される方法によって生成される第１のビデオのメディアファイルを記憶し、前記方法は、前記メディアファイルと前記第１のビデオのビットストリームとの間の変換を実行するステップを含み、前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、ビデオ処理方法。
【0083】
項目１４：第１のビデオのメディアファイルを記憶するための方法であって、前記メディアファイルと前記第１のビデオのビットストリームとの間の変換を実行するステップと、前記メディアファイルを非一時的なコンピュータ可読記録媒体に記憶するステップを含み、前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、ビデオ処理方法。
【0084】
装置の例
図９は、本開示の様々な実施形態が実装することができるコンピューティング装置９００のブロックを図示している。コンピューティング装置９００は、送信元の装置１１０(またはビデオ符号化装置１１４もしくは２００)または送信先の装置１２０(またはビデオ復号化装置１２４もしくは３００)として実装されるか、またはそれらに含んでもよい。
図９は、本開示の様々な実施形態が実装することができるコンピューティング装置９００のブロックを図示している。コンピューティング装置９００は、送信元の装置１１０(またはビデオ符号化装置１１４もしくは２００)または送信先の装置１２０(またはビデオ復号化装置１２４もしくは３００)として実装されるか、またはそれらに含んでもよい。
【0085】
図９に示されるコンピューティング装置９００は、単に説明のみを目的とし、本開示の実施形態の機能および範囲に対するいかなる限定も示唆するものではないことが理解されよう。
【0086】
図９に示されるように、コンピューティング装置９００は、汎用コンピューティング装置９００を含む。コンピューティング装置９００は、少なくとも、１つ以上のプロセッサまたは処理ユニット９１０、メモリ９２０、記憶ユニット９３０、１つ以上の通信ユニット９４０、１つ以上の入力装置９５０、および１つ以上の出力装置９６０を含んでもよい。
【0087】
いくつかの実施形態において、コンピューティング装置９００は、コンピューティング能力を有する任意のユーザ端末またはサーバ端末として実装されてもよい。前記サーバ端末は、サービスプロバイダーによって提供されるサーバ、大規模コンピューティング装置などであってもよい。ユーザ端末は、たとえば、携帯電話、局、ユニット、装置、マルチメディアコンピュータ、マルチメディアタブレット、インターネットノード、コミュニケータ、ＰＣ、ノートＰＣ、ノート型コンピュータ、ネットブックコンピュータ、タブレット型コンピュータ、パーソナル移動通信システム(ＰＣＳ)装置、パーソナルナビゲーションデバイス、携帯情報端末(ＰＤＡ)、音声/ビデオプレーヤ、デジタルカメラ/ビデオカメラ、位置決め装置、テレビ受信器、ラジオ放送受信器、電子書籍端末、ゲーム機、またはこれらの装置のアクセサリおよび周辺機器を含むこれらの任意の組合せ、あるいはこれらの任意の組合せを含む、任意のタイプの移動端末、固定端末、またはポータブル端末であってもよい。コンピューティング装置９００は、ユーザに任意のタイプのインターフェース(「ウェアラブル」回路など)をサポートすることができると考えることができる。
【0088】
処理ユニット９１０は、物理または仮想プロセッサであってもよく、メモリ９２０に記憶されたプログラムに基づいて様々なプロセスを実施することができる。マルチプロセッサシステムでは、複数の処理ユニットがコンピュータ実行可能命令を並列に実行して、コンピューティング装置９００の並列処理能力を向上させる。処理ユニット９１０は、中央処理装置(ＣＰＵ)、マイクロプロセッサ、コントローラ、またはマイクロコントローラーと呼ばれることもある。
【0089】
コンピューティング装置９００は、通常、様々なコンピュータ記憶媒体を含む。そのような媒体は、揮発性および不揮発性媒体、または取り外し可能および取り外し不能媒体を含むが、これらに限らない、コンピューティング装置９００によってアクセス可能な任意の媒体とすることができる。メモリ９２０は、揮発性メモリ(たとえば、レジスタ、キャッシュ、ランダムアクセスメモリ(ＲＡＭ))、非揮発性メモリ(読取り専用メモリ(ＲＯＭ)、電気的に消去可能でプログラム可能な読み取り専用メモリ(ＥＥＰＲＯＭ)、もしくはフラッシュメモリなど)、またはそれらの任意の組合せとすることができる。記憶ユニット９３０は、任意の取り外し可能または取り外し不可能な媒体であってもよく、情報および/またはデータを記憶するために使用することができ、コンピューティング装置９００においてアクセスすることができる、メモリ、フラッシュメモリドライブ、磁気ディスク、または別の他の媒体などの機械可読媒体を含んでもよい。
【0090】
コンピューティング装置９００は、追加の取り外し可能/取り外し不可能な揮発性/非揮発性メモリ媒体をさらに含んでもよい。なお、図９には示していないが、着脱可能な不揮発性の磁気ディスクに対して読み書きを実行する磁気ディスクドライブや、着脱可能な不揮発性の光ディスクに対して読み書きを実行する光ディスクドライブを設けてもよい。そのような場合、各ドライブは、１つまたは複数のデータ媒体インターフェースを介してバス(図示省略)に接続されてもよい。
【0091】
通信ユニット９４０は、通信媒体を介してさらなるコンピューティング装置と通信する。さらに、コンピューティング装置９００内のコンポーネントの機能は、通信接続を介して通信することができる単一のコンピューティングクラスターまたは複数のコンピューティングマシンによって実装することができる。したがって、コンピューティング装置９００は、１つまたは複数の他のサーバ、ネットワークＰＣ(ＰＣｓ)、またはさらなる一般的なネットワークノードとの論理的接続を使用して、ネットワーク化された環境で動作することができる。
【0092】
入力装置９５０は、マウス、キーボード、トラッキングボール、音声入力装置などの様々な入力装置のうちの１つまたは複数とすることができる。出力装置９６０は、ディスプレイ、スピーカー、プリンタなどの様々な出力装置のうちの１つまたは複数とすることができる。通信ユニット９４０によって、コンピューティング装置９００は、記憶装置および表示装置などの１つまたは複数の外部装置(図示せず)とさらに通信することができ、１つまたは複数の装置は、ユーザがコンピューティング装置９００と交信することを可能にし、または必要に応じて、任意の装置(ネットワークカード、モデムなど)は、コンピューティング装置９００が１つまたは複数の他のコンピューティング装置と通信することを可能にする。そのような通信は、入力/出力(Ｉ／Ｏ)インターフェース(図示省略)を介して実行することができる。
【0093】
いくつかの実施形態において、単一の装置に統合される代わりに、コンピューティング装置９００の一部又は全てのコンポーネントは、さらに、クラウドコンピューティングアーキテクチャに配置されてもよい。クラウドコンピューティングアーキテクチャでは、コンポーネントは、リモートに提供され、本開示で説明される機能を実装するために連携してもよい。いくつかの実施形態において、クラウドコンピューティングは、コンピューティング、ソフトウェア、データアクセスおよびストレージサービスを提供し、これらのサービスを提供するシステムまたはハードウェアの物理的位置または構成をエンドユーザが認識することを必要としない。様々な実施形態において、クラウドコンピューティングは、適切なプロトコルを使用して広域ネットワーク(インターネットなど)を介してサービスを提供する。例えば、クラウドコンピューティンプロバイダーは、Ｗｅｂブラウザまたは任意の他のコンピューティングコンポーネントを通じてアクセスすることができるアプリケーションをＬＡＮを介して提供する。クラウドコンピューティングアーキテクチャのソフトウェアまたはコンポーネントおよび対応するデータは、遠隔位置のサーバに格納されてもよい。クラウドコンピューティング環境内のコンピューティングリ元は、遠隔データセンター内の位置でマージまたは分散されてもよい。クラウドコンピューティングインフラストラクチャは、共有データセンターを介してサービスを提供することができるが、ユーザにとっては単一のアクセスポイントとして動作する。したがって、クラウドコンピューティングアーキテクチャは、本明細書で説明されるコンポーネントおよび機能を、遠隔地にあるサービスプロバイダーから提供するために使用してもよい。代替的に、それらは、従来のサーバから提供されるか、またはクライアント装置上に直接もしくは他の方法でインストールされてもよい。
【0094】
コンピューティング装置９００は、本開示の実施形態におけるビデオ符号化/復号化を実装するために使用してもよい。メモリ９２０は、１つまたは複数のプログラム命令を有する１つまたは複数のビデオ符号化モジュール９２５を含んでもよい。これらのモジュールは、本明細書で説明される様々な実施形態の機能を実行するために、処理ユニット９１０によってアクセス可能かつ実行可能である。
【0095】
ビデオ符号化を実行する例示的な実施形態では、入力装置９５０は、符号化される入力９７０としてビデオデータを受信してもよい。ビデオデータは、符号化されたビットストリームを生成するために、たとえば、ビデオ符号化モジュール９２５によって処理されてもよい。符号化されたビットストリームは、出力装置９８０として出力９６０を介して提供されてもよい。
【0096】
ビデオ復号化を実行する例示的な実施形態では、出力９５０は、入力９７０として符号化されたビットストリームを受信ししてもよい。符号化されたビットストリームは、たとえば、ビデオ符号化モジュール９２５によって処理されて、復号されたビデオデータを生成されてもよい。復号されたビデオデータは、出力装置９８０として出力９６０を介して提供されてもよい。
【0097】
本開示は、その好ましい実施形態を参照して具体的に示され、説明してきたが、添付の特許請求の範囲によって定義されるように、本開示の要旨と範囲から離れることなく、形態および詳細における種々の変更が可能なことが当業者に理解できよう。このような変更形態は、本出願の範囲に含まれるように意図される。したがって、本出願の実施形態の前述の説明は、限定することを意図していない。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【手続補正書】
【提出日】2024-03-27
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
第１のビデオのメディアファイルと前記第１のビデオのビットストリームとの間の変換を実行するステップを含み、前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、ビデオ処理方法。
【請求項2】
前記指示は、第１のタイプのトラックリファレンスを含む、請求項１に記載の方法。
【請求項3】
第１のビデオの空間解像度が第２のビデオの空間解像度よりも小さく、前記第１のタイプのトラックリファレンスが「ｐｉｐｍ」トラックリファレンスである、請求項２に記載の方法。
【請求項4】
前記第２のビデオの空間解像度が前記第１のビデオの空間解像度よりも小さく、前記第１のタイプのトラックリファレンスが「ｐｉｐｓ」トラックリファレンスである、請求項２に記載の方法。
【請求項5】
前記トラックリファレンスは、前記第２のトラックを指示する、請求項２に記載の方法。
【請求項6】
前記第２のビデオのメディアファイルは、第２のタイプのトラックリファレンスを含み、前記第２のタイプのトラックリファレンスは、前記第１のトラックと第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを指示する、請求項２に記載の方法。
【請求項7】
前記変換は、前記メディアファイルを生成して前記ビットストリームを前記メディアファイルに記憶することを含む、請求項１に記載の方法。
【請求項8】
前記変換は、前記メディアファイルを解析して前記ビットストリームを再構築することを含む、請求項１に記載の方法。
【請求項9】
プロセッサと、命令を有する非一時的なメモリとを備え、前記命令が前記プロセッサによって実行されると、前記プロセッサに、請求項１～８のいずれか１項に記載の方法を実行させる、ビデオデータを処理するための装置。
【請求項10】
プロセッサに請求項１～８のいずれか１項に記載の方法を実行させる命令を記憶する非一時的なコンピュータ可読記憶媒体。
【請求項11】
ビデオ処理装置によって実行される方法によって生成された第１のビデオのビットストリームを記憶し、前記方法は、前記第１のビデオのメディアファイルと前記ビットストリームとの間の変換を実行するステップを含み、
前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、非一時的なコンピュータ可読記録媒体。
【請求項12】
第１のビデオのビットストリームを記憶するための方法であって、前記第１のビデオのメディアファイルと前記ビットストリームとの間の変換を実行するステップと、
前記ビットストリームを非一時的なコンピュータ可読記録媒体に記憶するステップと、を含み、
前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、方法。
【請求項13】
ビデオ処理装置によって実行される方法によって生成される第１のビデオのメディアファイルを記憶し、前記方法は、前記メディアファイルと前記第１のビデオのビットストリームとの間の変換を実行するステップを含み、
前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、非一時的なコンピュータ可読記録媒体。
【請求項14】
第１のビデオのメディアファイルを記憶するための方法であって、前記メディアファイルと前記第１のビデオのビットストリームとの間の変換を実行するステップと、
前記メディアファイルを非一時的なコンピュータ可読記録媒体に記憶するステップを含み、
前記メディアファイルは、前記第１のビデオの前記ビットストリームを担持する第１のトラックと第２のビデオのビットストリームを担持する第２のトラックとがピクチャインピクチャサービスを提供するためのトラックペアであることを示す指示を含む、方法。
【国際調査報告】