▶ テレフオンアクチーボラゲット エル エム エリクソン（パブル）の特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-08-24
(45)【発行日】2023-09-01
(54)【発明の名称】後方互換性を有するメディアビットストリーム
(51)【国際特許分類】
H04N 21/236 20110101AFI20230825BHJP
H04N 19/597 20140101ALI20230825BHJP
H04N 21/2662 20110101ALI20230825BHJP
H04N 21/434 20110101ALI20230825BHJP
H04N 21/431 20110101ALI20230825BHJP
【ＦＩ】
H04N21/236
H04N19/597
H04N21/2662
H04N21/434
H04N21/431
【請求項の数】
20
(21)【出願番号】P 2021515155
(86)(22)【出願日】2019-09-24
(65)【公表番号】
(43)【公表日】2022-01-06
(86)【国際出願番号】 EP2019075713
(87)【国際公開番号】W WO2020064733
(87)【国際公開日】2020-04-02
【審査請求日】2021-06-04
(31)【優先権主張番号】62/736,002
(32)【優先日】2018-09-25
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】598036300
【氏名又は名称】テレフオンアクチーボラゲット エルエム エリクソン（パブル）
(74)【代理人】
【識別番号】100109726
【弁理士】
【氏名又は名称】園田 吉隆
(74)【代理人】
【識別番号】100161470
【弁理士】
【氏名又は名称】冨樫 義孝
(74)【代理人】
【識別番号】100194294
【弁理士】
【氏名又は名称】石岡 利康
(74)【代理人】
【識別番号】100194320
【弁理士】
【氏名又は名称】藤井 亮
(74)【代理人】
【識別番号】100150670
【弁理士】
【氏名又は名称】小梶 晴美
(72)【発明者】
【氏名】ペッテション， マルティン
(72)【発明者】
【氏名】ダムガニアン， ミトラ
(72)【発明者】
【氏名】ショバーリ， リキャルド
【審査官】富樫 明
(56)【参考文献】
【文献】国際公開第２０１７／１４２９４９（ＷＯ，Ａ１）
【文献】特表２００９－５０２０５５（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｎ ２１／００－２１／８５８
Ｈ０４Ｎ １９／００－１９／９８
(57)【特許請求の範囲】
【請求項1】
後方互換性のあるビットストリームを生成する方法（１１００）であって、前記ビットストリームのエントリＥにおいて、メディアビットストリームシンタックス仕様の第１のバージョンによって規定される特徴の第１のバージョンを有する第１のエントリＡを含むこと（ｓ１１０２）と、
前記ビットストリームの前記エントリＥにおいて、前記メディアビットストリームシンタックス仕様の更新バージョンによって規定される前記特徴の前記第１のバージョンの拡張である前記特徴の第２のバージョンを有する第２のエントリＢを含むこと（ｓ１１０４）と、を含み、
前記エントリＡおよび前記エントリＢは、構造体、コンテナ、またはボックスであり、
前記メディアビットストリームシンタックス仕様はＩＳＯ／ＩＥＣ １４４９６－１２（ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ）の第１のバージョンであり、
更新された前記メディアビットストリームシンタックス仕様はＩＳＯ／ＩＥＣ １４４９６－１２（ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ）の更新バージョンであり、
前記エントリＥは、ｉ）前記特徴の前記第２のバージョンが前記特徴の前記第１のバージョンの更新であること、または、ｉｉ）前記特徴の前記第２のバージョンが前記特徴の前記第１のバージョンの拡張であることを指示する情報を含んでいる、方法。
【請求項2】
前記エントリＥは、前記ビットストリームにおける１つまたは複数のシンタックスエレメントのセットを有する構造体またはコンテナの位置に対するポインタである、請求項１に記載の方法。
【請求項3】
前記特徴の前記第１のバージョンは領域別パッキングであり、前記特徴の前記第２のバージョンは前記領域別パッキングの更新バージョンまたは拡張バージョンであり、前記メディアビットストリームシンタックス仕様は全方向メディアフォーマット（ＯＭＡＦ）の第１のバージョンであり、更新された前記メディアビットストリームシンタックス仕様は全方向メディアフォーマット（ＯＭＡＦ）の更新バージョンである、請求項１または２に記載の方法。
【請求項4】
前記エントリＥにおいて、前記特徴の前記第２のバージョンが前記特徴の前記第１のバージョンの拡張であることを指示する情報を含むことをさらに含む、請求項１から３のいずれか一項に記載の方法。
【請求項5】
メディアビットストリームをパースしかつ処理するための方法（１７００）であって、前記メディアビットストリームに含まれているエントリＥを受信すること（ｓ１７０１）と、
前記エントリＥをパースすること（ｓ１７０２）と、
前記エントリＥを前記パースすることに基づいて、前記エントリＥが、ｉ）メディアビットストリームシンタックス仕様の第１のバージョンに適合する特徴の第１のバージョンを含んでいる第１のエントリＡ、およびｉｉ）前記メディアビットストリームシンタックス仕様の更新バージョンに適合する前記特徴の第２のバージョンを含んでいる第２のエントリＢを両方共含んでいるかを判定すること（ｓ１７０４）であって、前記エントリＥは、前記特徴の前記第２のバージョンが前記特徴の前記第１のバージョンの拡張であることを指示する情報を含んでいる、ことに応答して、
前記エントリＢをパースすること（ｓ１７０５）と、
前記エントリＢを前記パースすることに基づいて、前記特徴の前記第２のバージョンが前記特徴の前記第１のバージョンの拡張であるかを判定すること（ｓ１７０８）に応答して、
前記エントリＡにおける前記特徴の前記第１のバージョンおよび前記エントリＢにおける前記特徴の前記第２のバージョンを両方共パースすること、および、
前記エントリＡからの前記特徴の前記第１のバージョンおよび前記エントリＢからの前記特徴の前記第２のバージョンを組み合わせることと、を含み、
前記エントリＡおよび前記エントリＢは、構造体、コンテナ、またはボックスであり、前記メディアビットストリームシンタックス仕様はＩＳＯ／ＩＥＣ １４４９６－１２（ＩＳＯＢＭＦＦ）の第１のバージョンであり、更新された前記メディアビットストリームシンタックス仕様はＩＳＯ／ＩＥＣ １４４９６－１２（ＩＳＯＢＭＦＦ）の更新バージョンである、方法。
【請求項6】
前記エントリＥは、前記メディアビットストリームにおける１つまたは複数のシンタックスエレメントのセットを有する構造体またはコンテナの位置に対するポインタである、請求項５に記載の方法。
【請求項7】
前記メディアビットストリームはオーディオおよび／またはビデオビットストリームである、請求項５または６に記載の方法。
【請求項8】
前記特徴の前記第１のバージョンは領域別パッキングであり、前記特徴の前記第２のバージョンは前記領域別パッキングの拡張バージョンであり、前記メディアビットストリームシンタックス仕様は全方向メディアフォーマット（ＯＭＡＦ）の第１のバージョンであり、更新された前記メディアビットストリームシンタックス仕様は全方向メディアフォーマット（ＯＭＡＦ）の更新バージョンである、請求項５から７のいずれか一項に記載の方法。
【請求項9】
前記特徴の前記第１のバージョンおよび前記第２のバージョンを復号すること、および／または前記メディアビットストリームをレンダリングするために前記特徴の前記第１のバージョンおよび前記第２のバージョンを使用することをさらに含む、請求項５から８のいずれか一項に記載の方法。
【請求項10】
前記方法はメディアプレーヤーで実行される、請求項５から９のいずれか一項に記載の方法。
【請求項11】
後方互換性のあるビットストリームのエントリＥにおいて、メディアビットストリームシンタックス仕様の第１のバージョンによって規定される特徴の第１のバージョンを有する第１のエントリＡを含むように、および前記後方互換性のあるビットストリームの前記エントリＥにおいて、前記メディアビットストリームシンタックス仕様の更新バージョンによって規定される前記特徴の前記第１のバージョンの拡張である前記特徴の第２のバージョンを有する第２のエントリＢを含むように設定され、
前記エントリＡおよび前記エントリＢは、構造体、コンテナ、またはボックスであり、
前記メディアビットストリームシンタックス仕様はＩＳＯ／ＩＥＣ １４４９６－１２（ＩＳＯＢＭＦＦ）の第１のバージョンであり、
更新された前記メディアビットストリームシンタックス仕様はＩＳＯ／ＩＥＣ １４４９６－１２（ＩＳＯＢＭＦＦ）の更新バージョンであり、
前記エントリＥは、ｉ）前記特徴の前記第２のバージョンが前記特徴の前記第１のバージョンの更新であること、または、ｉｉ）前記特徴の前記第２のバージョンが前記特徴の前記第１のバージョンの拡張であることを指示する情報を含んでいる、ビットストリーム発生器（１３０２）。
【請求項12】
前記エントリＥは、前記ビットストリームにおける１つまたは複数のシンタックスエレメントのセットを有する構造体またはコンテナの位置に対するポインタである、請求項１１に記載のビットストリーム発生器。
【請求項13】
前記ビットストリーム発生器は、前記エントリＥにおいて、前記特徴の前記第２のバージョンが前記特徴の第１のバージョンの拡張であることを指示する情報を含むようにさらに設定される、請求項１１または１２に記載のビットストリーム発生器。
【請求項14】
メディアビットストリームに含まれているエントリＥを受信するように、前記エントリＥをパースするように、
前記エントリＥを前記パースすることに基づいて、前記エントリＥが、ｉ）メディアビットストリームシンタックス仕様の第１のバージョンに適合する特徴の第１のバージョンを含んでいる第１のエントリＡ、およびｉｉ）前記メディアビットストリームシンタックス仕様の更新バージョンに適合する前記特徴の第２のバージョンを含んでいる第２のエントリＢを両方共含んでいるかを判定することであって、前記エントリＥは、前記特徴の前記第２のバージョンが前記特徴の前記第１のバージョンの拡張であることを指示する情報を含んでいる、ことに応答して、
前記エントリＢをパースする（ｓ１７０５）ように、
前記エントリＢを前記パースすることに基づいて、前記特徴の前記第２のバージョンが前記特徴の前記第１のバージョンの拡張であるかを判定することに応答して、
前記エントリＡにおける前記特徴の前記第１のバージョンおよび前記エントリＢにおける前記特徴の前記第２のバージョンを両方共パースすること、および、
前記エントリＡからの前記特徴の前記第１のバージョンおよび前記エントリＢからの前記特徴の前記第２のバージョンを組み合わせること、を行うように設定される、デバイスであって、
前記エントリＡおよび前記エントリＢは、構造体、コンテナ、またはボックスであり、前記メディアビットストリームシンタックス仕様はＩＳＯ／ＩＥＣ １４４９６－１２（ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ）の第１のバージョンであり、更新された前記メディアビットストリームシンタックス仕様はＩＳＯ／ＩＥＣ １４４９６－１２（ＩＳＯ Ｂａｓｅ Ｍｅｄｉａ Ｆｉｌｅ Ｆｏｒｍａｔ）の更新バージョンである、デバイス。
【請求項15】
前記エントリＥは、前記メディアビットストリームにおける１つまたは複数のシンタックスエレメントのセットを有する構造体またはコンテナの位置に対するポインタである、請求項１４に記載のデバイス。
【請求項16】
前記メディアビットストリームはオーディオおよび／またはビデオビットストリームである、請求項１４または１５に記載のデバイス。
【請求項17】
前記特徴の前記第１のバージョンおよび前記第２のバージョンを復号するように、および／または前記メディアビットストリームをレンダリングするために前記特徴の前記第１のバージョンおよび前記第２のバージョンを使用するようにさらに設定される、請求項１４から１６のいずれか一項に記載のデバイス。
【請求項18】
請求項１から４のいずれか一項に記載の方法に従って生成される、または請求項１１から１３のいずれか一項に記載のビットストリーム発生器によって生成される後方互換性のあるビットストリームを受信するようにさらに設定される、請求項１４から１７のいずれか一項に記載のデバイス。
【請求項19】
前記デバイスはメディアプレーヤー（１５０２）である、請求項１４から１８のいずれか一項に記載のデバイス。
【請求項20】
デバイスのプロセッサによって実行されるプログラムコードを含むコンピュータプログラムであって、前記プロセッサによる前記プログラムコードの実行によって前記デバイスに請求項１から１０のいずれか一項に記載の方法による動作を行わせる、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
例えば、Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅｓ Ｅｘｐｅｒｔ Ｇｒｏｕｐ（ＭＰＥＧ）のビットストリームなど、後方互換性のあるメディアビットストリームを作成しかつ処理することに関する実施形態が開示される。
【背景技術】
【0002】
近年、仮想現実（ＶＲ）はますます普及している。ヘッドマウントディスプレイ（ＨＭＤ）の進歩によって、バリアが動かされて高品質ＶＲをマスマーケットに参入させやすくなっている。ＶＲの使用事例には、全方位ビデオまたは３６０度ビデオともいうゲームおよびＶＲビデオが含まれる。
【0003】
１．ＭＰＥＧおよび没入型ビデオ
Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅｓ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）は現在、ＭＰＥＧ－Ｉの一連の標準で公開されるように没入型ビデオのためのいくつかのアクティビティに取り組んでいる。１つのアクティビティは、ユーザが、ヘッドマウントディスプレイ（ＨＭＤ）を使用する天球の全方向ではあるが、原点を中心とした固定された頭部位置で見ることができる３自由度（３ＤｏＦ）、別名３６０度ビデオに関係する。
Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅｓ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ（ＭＰＥＧ）は現在、ＭＰＥＧ－Ｉの一連の標準で公開されるように没入型ビデオのためのいくつかのアクティビティに取り組んでいる。１つのアクティビティは、ユーザが、ヘッドマウントディスプレイ（ＨＭＤ）を使用する天球の全方向ではあるが、原点を中心とした固定された頭部位置で見ることができる３自由度（３ＤｏＦ）、別名３６０度ビデオに関係する。
【0004】
別のアクティビティは、ユーザが３ＤｏＦのような全天球を体感するが、頭部をわずかに移動させることによってある程度自由にオブジェクトを見回せる拡張された３自由度（３ＤｏＦ＋）ビデオに関係する。これを技術的に実現するために、３ＤｏＦ＋シーンはテクスチャおよび深度情報両方を含んでいる多数のビューからビルドされる。中間ビューは隣接ビューからのテクスチャおよび深度を使用して合成される。
【0005】
ＭＰＥＧは、６自由度（６ＤｏＦ）ビデオのためのアクティビティも有する。６ＤｏＦビデオでは、ユーザは、ユーザが立って、場合によっては歩き回れるようにするのに十分な、３ＤｏＦ＋と比較してかなり大きくなったボリュームでオブジェクトを見回せるのに十分な柔軟性を有する。６ＤｏＦビデオを実現するための計画は、背景ビデオおよびポイントクラウドオブジェクトの組み合わせを使用することを含む。ポイントクラウドオブジェクトは、幾何学情報（３Ｄ空間における点）およびポイントクラウドにおけるそれぞれの点に付けられる属性で表される。属性は、明度（例えば、ＲＧＢテクスチャ）、反射率、占有率、および不透明度を含む。
【0006】
３ＤｏＦ、３ＤｏＦ＋、および６ＤｏＦの範囲は図１に示されている。３ＤｏＦ、３ＤｏＦ＋、および６ＤｏＦの全ては、立体観察をサポートすることが可能である。
【0007】
２．ＯＭＡＦ
ＭＰＥＧ－Ｉ標準化作業の一部は、全方向ビデオ用のメディアフォーマットを開発することである。このメディアフォーマットは、全方向メディアフォーマット（ＯＭＡＦ）と称される。ＯＭＡＦの第１のバージョンは、最終決定されており、ＯＭＡＦの第２のバージョン（ＯＭＡＦ ｖ２）に関する作業は進行中であり、このバージョンは、３ＤｏＦ＋ビデオのサポートを含む機能の追加を含むことが予想される。例えば、Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）などのシグナリングイネーブラ（ｓｉｇｎａｌｉｎｇ ｅｎａｂｌｅｒ）と組み合わせて、ＯＭＡＦを使用してインターネット上で全方向ビデオのシグナリングをサポートする。
ＭＰＥＧ－Ｉ標準化作業の一部は、全方向ビデオ用のメディアフォーマットを開発することである。このメディアフォーマットは、全方向メディアフォーマット（ＯＭＡＦ）と称される。ＯＭＡＦの第１のバージョンは、最終決定されており、ＯＭＡＦの第２のバージョン（ＯＭＡＦ ｖ２）に関する作業は進行中であり、このバージョンは、３ＤｏＦ＋ビデオのサポートを含む機能の追加を含むことが予想される。例えば、Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＤＡＳＨ）などのシグナリングイネーブラ（ｓｉｇｎａｌｉｎｇ ｅｎａｂｌｅｒ）と組み合わせて、ＯＭＡＦを使用してインターネット上で全方向ビデオのシグナリングをサポートする。
【0008】
ＯＭＡＦの最初のバージョンでは、２つのビデオコード：（１）Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＡＶＣ）／Ｈ．２６４および（２）高効率符号化（ＨＥＶＣ）がサポートされる。両方のコーデックは、ＭＰＥＧとＩＴＵ－Ｔとの間の協調作業である共同作業部会（ＪＣＴ－ＶＣ）において開発されている。ＭＰＥＧおよびＩＴＵ－Ｔは、現在、Ｊｏｉｎｔ Ｖｉｄｅｏ Ｅｘｐｅｒｔｓ Ｔｅａｍ（ＪＶＥＴ）内で、汎用ビデオコーデック（ＶＶＣ）と称される次世代ビデオコーデックに取り組んでいる。ＯＭＡＦの将来のバージョンによってサポートされる可能性があるＶＶＣは、ＡＶＣおよびＨＥＶＣよりも全方向ビデオに対するサポートが一層良くなっていることが見込まれている。
【0009】
３．投影フォーマット
カメラ（またはカメラのリグ）、およびカメラが３６０度ビデオをどのようにキャプチャするかに応じて、種々のフォーマットが存在する。ＯＭＡＦによってサポートされる２つの一般的な投影フォーマットは、（１）正距円筒図法および（２）キューブマップ投影である。正距円筒フォーマットは、世界地図によって容易に説明でき、この場合、赤道は左から右に及んでおり、両極における画素は上罫線および下罫線に沿って広がっている。よって粒度は両極で高くなっている。キューブマップ投影は、立方体形状における６つの２Ｄビデオ投影によってビルドされる。キューブマップビデオは、６つの異なる直交方向：上、下、前、後ろ、左、および右で６つのカメラによって２Ｄビデオをキャプチャすることによって作成されてよい。図２は、典型的なキューブマップの一例を示す。
カメラ（またはカメラのリグ）、およびカメラが３６０度ビデオをどのようにキャプチャするかに応じて、種々のフォーマットが存在する。ＯＭＡＦによってサポートされる２つの一般的な投影フォーマットは、（１）正距円筒図法および（２）キューブマップ投影である。正距円筒フォーマットは、世界地図によって容易に説明でき、この場合、赤道は左から右に及んでおり、両極における画素は上罫線および下罫線に沿って広がっている。よって粒度は両極で高くなっている。キューブマップ投影は、立方体形状における６つの２Ｄビデオ投影によってビルドされる。キューブマップビデオは、６つの異なる直交方向：上、下、前、後ろ、左、および右で６つのカメラによって２Ｄビデオをキャプチャすることによって作成されてよい。図２は、典型的なキューブマップの一例を示す。
【0010】
３６０度ビデオを効率的に圧縮するために、カメラによってキャプチャされる投影済みビデオフォーマットは、典型的には、圧縮により適したピクチャにパッキングされる。このピクチャはパックドピクチャと称される。パックドピクチャを復号後、パックドピクチャは、ＨＭＤまたはディスプレイにレンダリングされる前に、アンパッキングされて、プロジェクテッドピクチャと称される投影フォーマットを有するピクチャになる。
【0011】
プロジェクテッドピクチャをパックドピクチャにパッキングすることが有用である時の簡易な使用事例は、正距円筒フォーマットに対するものである。正距円筒図法での極がプロジェクテッドピクチャの残りの部分より高い粒度を有するため、圧縮用のパックドピクチャは両極における画素に関して圧縮されてよい。これは、上部分および下部分がプロジェクテッドピクチャと比較してパックドピクチャで収縮されている図３に例示されている。
【0012】
図４は、３６０度カメラがシーンをキャプチャし、かつ３６０度ビデオをサーバに送る３６０度ビデオの典型的な使用事例の一例を示す。サーバは、さらにまた、ビデオをＨＭＤでユーザに送る。プロジェクテッドピクチャの解像度はパックドピクチャの解像度より大きくてよい。
【0013】
容易くなされるある観察は、ユーザが天球上でビデオコンテンツを１方向に一度しか見られないことである。天球上でユーザによって見られるものは観察地点と称される。観察地点外のものはユーザには見られず、この部分のビデオデータを少なくとも高品質で送ることは無駄である。
【0014】
４．タイル化されたビデオ
ＯＭＡＦにおける特徴のうちの１つは、ビデオのタイル化をサポートすることである。ピクチャのタイルはピクチャの領域と称される時がある。タイル化されたビデオは互いに別々にコード化されたいくつかのタイルによってビルドされるが、これは、単一のタイルが符号化されたビットストリームから抽出可能であり、また別々に復号可能であることを意味する。これは、現在のビューポートを含めているタイルのみを高品質で送るために３６０度ビデオストリーミングで利用される。他のタイルはスキップされてよい、または低品質で送信されてよい。
ＯＭＡＦにおける特徴のうちの１つは、ビデオのタイル化をサポートすることである。ピクチャのタイルはピクチャの領域と称される時がある。タイル化されたビデオは互いに別々にコード化されたいくつかのタイルによってビルドされるが、これは、単一のタイルが符号化されたビットストリームから抽出可能であり、また別々に復号可能であることを意味する。これは、現在のビューポートを含めているタイルのみを高品質で送るために３６０度ビデオストリーミングで利用される。他のタイルはスキップされてよい、または低品質で送信されてよい。
【0015】
図５は、タイルが、観察地点に対しては高品質を、他の部分に対しては低品質を可能にするように利用される典型的な使用事例の一例を示す。図５に示されるように、カメラは３６０度ビデオをキャプチャしかつこれをサーバに送る。サーバは、３６０度ビデオの高品質バージョンおよび低品質バージョンを作成する。ビデオは、ＯＭＡＦおよびＤＡＳＨを使用してＨＭＤデバイスでユーザにストリーミングされる。ＨＭＤデバイスは、ユーザはどの方向を見ているのかを検出し、かつビューポートには高品質タイルを、残りの部分には低品質タイルを要求する。サーバは、要求された高品質タイルおよび低品質タイルをパッキングされたビデオピクチャにパッキングし、かつこれをＨＭＤに送る。ＨＭＤは該ピクチャをアンパッキングし、かつパッキングされたタイルをプロジェクテッドピクチャ上の正しい場所に投影する。
【0016】
５．保護帯域
ＯＭＡＦにおいて、投影のためにタイルをつなぎ合わせる時の画質を改善するためにパックドピクチャにおいて保護帯域を使用するオプションがある。保護帯域は、２つの領域間の境界をシームレスに混合させるために使用されてよい。保護帯域は、ＯＭＡＦではレンダリングされないパックドピクチャにおける部分として規定されるが、つなぎ目などの視覚アーティファクトが、パックドピクチャからの領域を一緒につなぎ合わせることを回避するまたは軽減するようにパックドピクチャのレンダリング部分を改善するために使用されてよい。図６は、投影領域を有するプロジェクテッドピクチャ、および周りに保護帯域を有するパックドピクチャにおけるこの対応するパッキング領域の一例を示す。
ＯＭＡＦにおいて、投影のためにタイルをつなぎ合わせる時の画質を改善するためにパックドピクチャにおいて保護帯域を使用するオプションがある。保護帯域は、２つの領域間の境界をシームレスに混合させるために使用されてよい。保護帯域は、ＯＭＡＦではレンダリングされないパックドピクチャにおける部分として規定されるが、つなぎ目などの視覚アーティファクトが、パックドピクチャからの領域を一緒につなぎ合わせることを回避するまたは軽減するようにパックドピクチャのレンダリング部分を改善するために使用されてよい。図６は、投影領域を有するプロジェクテッドピクチャ、および周りに保護帯域を有するパックドピクチャにおけるこの対応するパッキング領域の一例を示す。
【0017】
６．領域別パッキング
ＯＭＡＦはパックドピクチャに対する２５５の種々の領域をサポートする。ＯＭＡＦにおける領域別パッキングは、パックドピクチャにおける領域がプロジェクテッドピクチャにおける領域にどのようにアンパッキングされるのかを規定する。パックドピクチャにおける領域を復号した後、この領域は、ディスプレイまたはＨＭＤにレンダリングされる前に、ビットストリームにおける領域別パッキング情報を使用してプロジェクテッドピクチャの領域に投影される。
ＯＭＡＦはパックドピクチャに対する２５５の種々の領域をサポートする。ＯＭＡＦにおける領域別パッキングは、パックドピクチャにおける領域がプロジェクテッドピクチャにおける領域にどのようにアンパッキングされるのかを規定する。パックドピクチャにおける領域を復号した後、この領域は、ディスプレイまたはＨＭＤにレンダリングされる前に、ビットストリームにおける領域別パッキング情報を使用してプロジェクテッドピクチャの領域に投影される。
【0018】
現在のＯＭＡＦ ｖ２の作業草案（ＷＤ）（Ｍ１７８２７ｖ１）における領域別パッキングのシンタックスおよびセマンティクスは、以下の表および説明において以下に示されている。
【0019】
ＯＭＡＦ仕様ではまた、「ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘがないことは、領域別パッキングが適用されていないこと、すなわち、パックドピクチャがプロジェクテッドピクチャと同一であることを指示している」ことが述べられている。よって、これは、ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘがない時の既定動作である。
【0020】
７．領域別パッキング情報のコンパクトな記述
領域別パッキング情報の表示をよりコンパクトにするための提案が取り入れられた。この提案は以下の３つの異なる部分から成るものであった。
領域別パッキング情報の表示をよりコンパクトにするための提案が取り入れられた。この提案は以下の３つの異なる部分から成るものであった。
【0021】
（１）スケールファクター－矩形領域パッキング構造における投影領域およびパッキング領域に対する幅、高さ、上オフセット、および左オフセットのビット数を低減したスケールファクターおよびスケーリングされた値をシグナリングする。フラグを使用してスケーリングが使用されることになるかどうかを指示する。
【0022】
（２）コピーサイズ－全ての領域が同じサイズを有する場合に第１の領域のみの領域幅および高さをシグナリングする。フラグは、プロジェクテッドピクチャおよびパックドピクチャのそれぞれが、全ての領域が同じサイズを有するかどうかを指示するために使用される。
【0023】
（３）ラスタスキャン順序－全ての領域がラスタスキャン順序で順序付けされる場合、領域の上オフセットおよび左オフセットをシグナリングしない。該オフセットは、ピクチャ幅、ならびに領域の幅および高さを使用して受信側で再構成可能である。フラグは、プロジェクテッドピクチャおよびパックドピクチャのそれぞれが、全ての領域がラスタスキャン順序で順序付けされるかどうかを指示するために使用される。
【0024】
上述した提案は、「ｍ４３４３６－領域別パッキング情報のコンパクトな記述に関して」の寄書においてＭＰＥＧに対して提案された。該寄書は、ＯＭＡＦの検討中の技術（ＴｕＣ）文書で採用された。
【0025】
前述の提案は、ＯＭＡＦビットストリームおよびファイルにおける領域別パッキング情報のよりコンパクトな記述のための手段を提供するが、この提案の欠点は、ＯＭＡＦの以前のバージョン（ＯＭＡＦ ｖ１）と後方互換性がないことである。
【0026】
ＯＭＡＦ ｖ１のみをサポートするメディアプレーヤーは、更新されたＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘによってメディアビットストリームを正しくパースすることができなくなる。メディアプレーヤーはＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘがＯＭＡＦ ｖ１に適合すると考えるため、プレーヤーはＯＭＡＦ ｖ１の仕様に従ってボックスにおけるビットをパースしようとするが、ビットが、ＯＭＡＦの更新バージョンにおけるＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘの更新された仕様に従って書き込まれているため、達成できず、場合によってはクラッシュする。
【0027】
この問題は、ＯＭＡＦにおける領域別パッキング情報の機能に対してだけでなくメディアビットストリームシンタックス仕様の第１のバージョンのみをサポートするメディアプレーヤーがメディアビットストリームシンタックス仕様の更新バージョンをサポートするメディアビットストリームをパースすることができると予想される時、後方互換性が望まれるメディアビットストリームシンタックス仕様に対して機能の更新がなされる何らかの状況に対しても存在する。
【発明の概要】
【0028】
本開示には、メディアビットストリームシンタックス仕様の種々のバージョンに適合するメディアビットストリームおよびメディアプレーヤーに関して後方互換性を提供するための実施形態が記載されている。
【0029】
１つの実施形態では、メディアビットストリームにおいて利用可能な特徴に対する第１のエントリ（例えば、第１のボックス）およびメディアビットストリームにおいて利用可能な更新された特徴に対する第２のエントリ（例えば、第２のボックス）をビットストリームに含むことによってビットストリームを後方互換性があるものにし、ここで第１のエントリは、シンタックス仕様の第１のバージョンをサポートするメディアプレーヤーおよびシンタックス仕様の更新バージョンをサポートするメディアプレーヤー両方によって理解され、第２のエントリは、シンタックス仕様の更新バージョンをサポートするメディアプレーヤーによって理解されるが、シンタックス仕様の第１のバージョンをサポートするメディアプレーヤーによって理解されない。例えば、第１のエントリはシンタックス仕様の第１のバージョンの元の特徴を含んでおり、第２のエントリはシンタックス仕様の更新バージョンの更新された特徴を含んでいる。このように、メディアビットストリームは、シンタックス仕様の第１のバージョンのみをサポートするメディアプレーヤーと後方互換性があるように徹底することができるが、シンタックス仕様の更新バージョンをサポートするメディアプレーヤーに更新された特徴を依然提供する。
【0030】
提案された実施形態の利点は、メディアビットストリームシンタックス仕様の第１のバージョンのみをサポートするメディアプレーヤーが、メディアビットストリームシンタックス仕様の更新バージョンに適合するメディアビットストリームをパースできるものとすることが予想されるメディアビットストリームシンタックス仕様に対して後方互換性を提供することができることである。
【0031】
別のより具体的な実施形態では、ＯＭＡＦ仕様の以前のバージョンと後方互換性がある領域別パッキング情報のよりコンパクトな記述が提供される。これは、１つの実施形態では、新しいボックスを、領域別パッキング情報のよりコンパクトな記述を提供するＯＭＡＦの新しいバージョン、ＥｘｔｅｎｄｅｄＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘに加えることによって行われ、領域別パッキングをより広範囲に実現するための機能を加える。ＯＭＡＦ仕様の以前のバージョンに最初に規定される元の領域別パッキングボックスも含むことによって、後方互換性を徹底することができる。ビットレートを低く抑えるために、元の領域別パッキングボックスは、パックドピクチャとプロジェクテッドピクチャとの間に簡略化されているが有効なマッピングを提供することができる。このより具体的な実施形態の利点は、領域別パッキング情報のよりコンパクトな記述を提供する機能でＯＭＡＦ仕様を更新する時に領域別パッキング情報機能に対して後方互換性が提供されることである。
【0032】
本明細書に組み込まれ、かつ本明細書の一部を形成する添付の図面は、さまざまな実施形態を示す。
【図面の簡単な説明】
【0033】
【図1】没入型ビデオの３つの例を示す図である。
【図2】典型的なキューブマップの一例を示す図である。
【図3】正距円筒ピクチャを、圧縮により適したパックドピクチャにパッキングする一例を示す図である。
【図4】３６０度ビデオの典型的な使用事例を示す図である。
【図5】タイルによる例示の使用事例を示す図である。
【図6】パッキング領域周りの保護帯域と共にプロジェクテッドピクチャおよびパックドピクチャを示す図である。
【図7A】特徴の第１のバージョンを保持する第１のエントリを有するビットストリームを示す図である。
【図7B】特徴の第２のバージョンを保持する第２のエントリを有するビットストリームを示す図である。
【図7C】特徴の第１のバージョンおよび特徴の第２のバージョンを保持する第２のエントリを有するビットストリームを示す図である。
【図7D】特徴の第１のバージョンおよび特徴の第２のバージョンを保持する第１のエントリを有するビットストリームを示す図である。
【図8A】第１の実施形態を示す図である。
【図8B】第２の実施形態を示す図である。
【図9】ＲＷＰおよびＥＲＷＰを使用する２つの解像度によるキューブマップの領域別パッキングを示す図である。
【図10】ＲＷＰおよびＥＲＷＰを使用する２つの解像度によるキューブマップの領域別パッキングの代替バージョンを示す図である。
【図11】１つの実施形態によるプロセスを示すフローチャートである。
【図12】１つの実施形態によるプロセスを示すフローチャートである。
【図13】１つの実施形態によるビットストリーム発生器（ＢＧ）のブロック図である。
【図14】１つの実施形態によるＢＧの機能ユニットを示す略図である。
【図15】１つの実施形態によるメディアプレーヤー（ＭＰ）のブロック図である。
【図16】１つの実施形態によるＭＰの機能単位を示す略図である。
【図17】１つの実施形態によるプロセスを示すフローチャートである。
【図18】１つの実施形態によるＭＰの機能単位を示す略図である。
【発明を実施するための形態】
【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】
Ａ７．エントリＥは、特徴Ｘ２が特徴Ｘの更新であるかどうかかつ実施形態２に従ってエントリＡは破棄されるべきかどうか、または、特徴Ｘ２が特徴Ｘの拡張であるかどうか、および実施形態３に従ってパースされかつ特徴Ｘ２と組み合わせられるべきかどうかの指示を含んでいる、実施形態Ａ１～Ａ６のいずれか１つの方法。
【0098】
Ａ８．エントリＡおよびエントリＢは同じエントリタイプを有し、エントリＡは第１のバージョンを指示するバージョンインジケータを含んでおり、エントリＢは第２のバージョンを指示するバージョンインジケータを含んでおり、第２のバージョンは第１のバージョンより高い、実施形態Ａ１～Ａ７のいずれか１つの方法。
【0099】
Ｂ１．メディアプレーヤーによって実行される方法であって、メディアプレーヤーが実施形態Ａ１～Ａ８のいずれか１つの後方互換性のあるビットストリームを受信することを含む、方法。
【0100】
Ｂ２．後方互換性のあるビットストリームを受信することは、エントリＢを受信すること、エントリＢをパースすること、エントリＡを受信すること、エントリＡを破棄するか否かを判定すること、およびピクチャを処理する（例えば、レンダリングするおよび／または復号する）ために少なくとも特徴Ｘ２を使用することを含む、実施形態Ｂ１の方法。
【0101】
Ｂ３．第１のエントリＡを破棄するか否かを判定することは、特徴Ｘ２が特徴Ｘの更新であるかまたは特徴Ｘの拡張であるかどうかを判定することを含む（例えば、この判定はエントリＢおよび／またはエントリＡに含まれるバージョン番号に基づくことができる）、実施形態Ｂ２の方法。
【0102】
Ｂ４．プレーヤーが、特徴Ｘ２が特徴Ｘの更新であると判定した結果として第１のエントリＡを破棄することをさらに含む、実施形態Ｂ３の方法。
【0103】
Ｂ５．第２のエントリＢは、特徴Ｘ２が特徴Ｘの更新であることを指示する情報を含む、実施形態Ｂ４の方法。
【0104】
Ｂ６．第１のエントリＡをパースすること、および、特徴Ｘ２が特徴Ｘの拡張であると判定した結果としてピクチャを処理するために特徴Ｘおよび特徴Ｘ２を使用すること、をさらに含む、実施形態Ｂ３の方法。
【0105】
Ｂ７．第２のエントリＢは、特徴Ｘ２が特徴Ｘの拡張であることを指示する情報を含む、実施形態Ｂ６の方法。
【0106】
Ｂ８．第２のエントリＢはビットストリームのコンテナに含まれており、メディアプレーヤーは、第１のエントリＡがまたコンテナに含まれていると判定した結果として第１のエントリＡを破棄する、実施形態Ｂ２の方法。
【0107】
Ｂ９．コンテナはＰｒｏｊｅｃｔｅｄＯｍｎｉＶｉｄｅｏＢｏｘである、実施形態Ｂ８の方法。
【0108】
Ｃ１．メディアビットストリームシンタックス仕様の更新バージョンＳ２に従ってメディアビットストリームをパースしかつ処理する（例えば、レンダリングするおよび／または復号する）ための方法であって、ビットストリームシンタックスの更新バージョンＳ２は、メディアビットストリームシンタックス仕様の第１のバージョンＳに適合する第１の特徴Ｘを含んでいる第１のエントリＡ、および、メディアビットストリームシンタックス仕様の更新バージョンＳ２に適合する第２の特徴Ｘ２を含んでいる第２のエントリＢの、どれも含んでいない、いずれか、または両方を含んでいる場合があるエントリＥを指定し、方法は、エントリＥをパースする時、エントリＥにエントリＡは含まれておりエントリＢは含まれていないかどうかを判定し、そうである場合、エントリＡにおける特徴Ｘをパースすることと、エントリＥをパースする時、エントリＥにエントリＢは含まれておりエントリＡは含まれていないかどうかを判定し、そうである場合、エントリＢにおける特徴Ｘ２をパースすることと、エントリＥをパースする時、エントリＥにエントリＡおよびエントリＢが両方共含まれているかどうかを判定し、そうである場合、エントリＢにおける特徴Ｘ２をパースすることと、エントリＥにエントリＡまたはエントリＢのどちらかが含まれている場合、パースされた特徴を使用してメディアビットストリームを処理することと、を含む、方法。
【0109】
Ｃ２．エントリＥをパースしかつエントリＡおよびエントリＢが両方共エントリＥに含まれているかを判定する時、特徴Ｘ２が特徴Ｘの更新である場合、エントリＡを破棄しかつエントリＢにおける特徴Ｘ２をパースする、実施形態Ｃ１の方法。
【0110】
Ｃ３．エントリＥをパースしかつエントリＡおよびエントリＢが両方共エントリＥに含まれていることを判定する時、特徴Ｘ２が特徴Ｘの拡張である場合、エントリＡにおける特徴ＸおよびエントリＢにおける特徴Ｘ２を両方共パースする、実施形態Ｃ１の方法。
【0111】
Ｃ４．特徴Ｘ２は、特徴Ｘと比較して特徴の現実化の表現を圧縮するための手段を含む、実施形態Ｃ１～Ｃ３のいずれか１つの方法。
【0112】
特有のＯＭＡＦの事例
Ｃ５．メディアビットストリームはオーディオおよび／またはビデオビットストリームである、実施形態Ｃ１～Ｃ４のいずれか１つの方法。
Ｃ５．メディアビットストリームはオーディオおよび／またはビデオビットストリームである、実施形態Ｃ１～Ｃ４のいずれか１つの方法。
【0113】
Ｃ６．エントリは、ポインタ、構造体、コンテナ、ボックス、プロパティ、またはアトムである、実施形態Ｃ１～Ｃ５のいずれか１つの方法。
【0114】
Ｃ７．メディアビットストリームシンタックス仕様ＳはＯＭＡＦの第１のバージョンであり、メディアビットストリームシンタックス仕様Ｓ２はＯＭＡＦの更新バージョンである、実施形態Ｃ１～Ｃ６のいずれか１つの方法。
【0115】
Ｃ８．特徴Ｘは領域別パッキングであり、特徴Ｘ２は領域別パッキングの拡張バージョンである、実施形態Ｃ１～Ｃ７のいずれか１つの方法。
【0116】
Ｃ９．特徴Ｘは領域別パッキングであり、特徴Ｘ２は領域別パッキングの更新バージョンである、実施形態Ｃ１～Ｃ７のいずれか１つの方法。
【0117】
Ｃ１０．エントリＥは、特徴Ｘ２が特徴Ｘの更新であるかどうか、およびエントリＡは破棄されるものとするかどうか、または特徴Ｘ２が特徴Ｘの拡張であり、かつ特徴Ｘ２と組み合わせられるものとするかどうかの指示を含んでいる、実施形態Ｃ１～Ｃ９のいずれか１つの方法。
【0118】
Ｃ１１．エントリＡおよびエントリＢは同じエントリタイプを有するが、エントリＢはエントリＢのバージョンインジケータより高いバージョンインジケータを含んでいる、実施形態Ｃ１～Ｃ１０のいずれか１つの方法。
【0119】
さまざまな実施形態が（いずれの付録も含んで）本明細書で説明されているが、これらは例示としてのみ提示されており限定するものではないことは理解されるべきである。よって、本開示の広さおよび範囲は、上述した例示の実施形態のいずれかによって限定されるべきでない。また、これらの全ての可能な変形における上述した要素の任意の組み合わせは、別段本明細書で指示されない限り、または明らかに文脈に矛盾しない限り、本開示に包含される。
【0120】
さらに、上述されかつ図面に示されるプロセスは一連のステップとして示されるが、これは単に例証のためになされたものである。それ故に、いくつかのステップが追加される場合があり、いくつかのステップが省略される場合があり、ステップの順序が配列し直される場合があり、いくつかのステップが並列に行われる場合があることが考えられる。
【0121】
以下の説明は、付録から、本出願が優先権を主張する米国特許仮出願までである。付録は国際標準化機構（ＩＳＯ）の寄書の関連テキストを含んだものである。
【0122】
１．要約
これは、リュブリャナでのＭＰＥＧ会議で提案されたｍ４３４３６のその後の寄書である。会議では、領域別パッキング情報のコンパクトな記述を取り入れたｍ４３４３６が後方互換性問題を有することが論評された。この寄書では、後方互換性問題を解決するための解決策が提案されている。
これは、リュブリャナでのＭＰＥＧ会議で提案されたｍ４３４３６のその後の寄書である。会議では、領域別パッキング情報のコンパクトな記述を取り入れたｍ４３４３６が後方互換性問題を有することが論評された。この寄書では、後方互換性問題を解決するための解決策が提案されている。
【0123】
新しいボックス、ＥｘｔｅｎｄｅｄＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘをＯＭＡＦ ｖ２仕様に追加することが提案される。ＯＭＡＦ ｖ１との完全な後方互換性が所望される時、ビットストリームにおいてＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘおよびＥｘｔｅｎｄｅｄＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘ両方を送ることが推奨される。ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＰｒｏｐｅｒｔｙに対して同じ解決策が提案される。
【0124】
提案された変更についてのテキストはこの寄書に含まれる。このテキストを、ＯＭＡＦ ｖ２作業草案（ＷＤ）の次のバージョンに追加することが提案される。
【0125】
２．序文
ＯＭＡＦ第２版ＷＤは領域別パッキングについてのテキストを含む。領域別パッキング構造はパックドピクチャにおけるそれぞれの領域をプロジェクテッドピクチャ上にどのようにアンパッキングしかつ投影するのかについての情報を含んでいる。
ＯＭＡＦ第２版ＷＤは領域別パッキングについてのテキストを含む。領域別パッキング構造はパックドピクチャにおけるそれぞれの領域をプロジェクテッドピクチャ上にどのようにアンパッキングしかつ投影するのかについての情報を含んでいる。
【0126】
ｍ４３４３６において、領域別パッキング情報のコンパクトな記述が提案された。ｍ４３４３６における解決策は、領域別パッキング情報を圧縮するための３つの方法を含んでいた。
【0127】
（１）スケールファクター－矩形領域パッキング構造における投影領域およびパッキング領域についての幅、高さ、上オフセット、および左オフセットに対するビット数を低減したスケールファクターおよびスケーリングされた値がシグナリングされる。フラグを使用してスケーリングが使用されることになるかどうかを指示する。
【0128】
（２）コピーサイズ－全ての領域が同じサイズを有する場合に第１の領域のみの領域幅および高さがシグナリングされる。フラグは、プロジェクテッドピクチャおよびパックドピクチャのそれぞれが、全ての領域が同じサイズを有するかどうかを指示するために使用される。
【0129】
（３）ラスタスキャン順序－全ての領域がラスタスキャン順序で順序付けされる場合、領域の上オフセットおよび左オフセットをシグナリングしない。該オフセットは、ピクチャ幅、ならびに領域の幅および高さを使用して受信側で再構成可能である。フラグは、全ての領域がラスタスキャン順序で順序付けされるかどうかを指示するためにプロジェクテッドピクチャおよびパックドピクチャのそれぞれに使用される。
【0130】
方法は、互いに別々に適用可能である、または最大圧縮のために組み合わせ可能である。
【0131】
リュブリャナの会議では、ＯＭＡＦの検討中技術（ＴｕＣ）にこの提案を含ませることが合意され、ここで「以下のシンタックスは後方互換性がない場合があることは留意されたい」という編集後記が付けられた。
【0132】
シンタックスのいくつかの態様は、ＯＭＡＦ ｖ１クライアントが新しいパラメータでの提案された更新済みＲＷＰシグナリングによってコンテンツを扱うことができないかもしれないという後方互換性問題を有することが論評された。
【0133】
３．提案
この寄書では、ＯＭＡＦ ｖ２仕様における新しいボックスおよび新しいエントリ、ＥｘｔｅｎｄｅｄＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘおよびＥｘｔｅｎｄｅｄＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＰｒｏｐｅｒｔｙを取り入れることによってリュブリャナ会議で特定された後方互換性問題を解決することが提案されている。新しいボックスおよびエントリは両方共、ＯＭＡＦ ＴｕＣにおいて説明される領域別パッキングのコンパクトな記述に対する機能を含む、新しいＥｘｔｅｎｄｅｄＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＳｔｒｕｃｔを含んでいる。
この寄書では、ＯＭＡＦ ｖ２仕様における新しいボックスおよび新しいエントリ、ＥｘｔｅｎｄｅｄＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘおよびＥｘｔｅｎｄｅｄＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＰｒｏｐｅｒｔｙを取り入れることによってリュブリャナ会議で特定された後方互換性問題を解決することが提案されている。新しいボックスおよびエントリは両方共、ＯＭＡＦ ＴｕＣにおいて説明される領域別パッキングのコンパクトな記述に対する機能を含む、新しいＥｘｔｅｎｄｅｄＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＳｔｒｕｃｔを含んでいる。
【0134】
ＥｘｔｅｎｄｅｄＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘについてのテキストは、以下の注記を含んでいる（同様の注記がＥｘｔｅｎｄｅｄＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＰｒｏｐｅｒｔｙのテキストに加えられている）：「ＯＭＡＦ ｖ１との後方互換性について、ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘは、ＰｒｏｊｅｃｔｅｄＯｍｎｉＶｉｄｅｏＢｏｘにおいてＥｘｔｅｎｄｅｄＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘの後に存在するものとする。ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘは、パックドピクチャとプロジェクテッドピクチャとの間の少なくとも１つの有効なマッピングを含むものとする。ＯＭＡＦ ｖ２プレーヤーは、ＥｘｔｅｎｄｅｄＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘが利用可能である場合、ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘを破棄するものとする。」
【0135】
よって、ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘおよびＥｘｔｅｎｄｅｄＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘを両方共含んでいるビットストリームは、ＯＭＡＦ ｖ１プレーヤーおよびＯＭＡＦ ｖ２プレーヤー両方によって扱われる可能性がある。ＯＭＡＦ ｖ１プレーヤーは、プレーヤーには未知であるためＥｘｔｅｎｄｅｄＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘを破棄し、ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘをパースし、この情報を使用してコンテンツをレンダリングする。ＯＭＡＦ ｖ２プレーヤーは、ＥｘｔｅｎｄｅｄＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘをパースし、かつこの情報を使用してコンテンツをレンダリングする。
【0136】
ビットレートを低く抑えるために、ＲｅｇｉｏｎＷｉｓｅＰａｃｋｉｎｇＢｏｘが、パックドピクチャとプロジェクテッドピクチャとの間の簡略化されているが有効なマッピングを提供することが好ましい。
【0137】
４．提案されたテキスト変更
以下の表に含まれているテキストをＯＭＡＦ ｖ２ ＷＤの次の改訂版に追加することが提案される。
以下の表に含まれているテキストをＯＭＡＦ ｖ２ ＷＤの次の改訂版に追加することが提案される。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7A】
【図7B】
【図7C】
【図7D】
【図8A】
【図8B】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】