特許第6496033号(P6496033)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ノキア テクノロジーズ オサケユイチアの特許一覧

特許6496033画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト
<>
  • 特許6496033-画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト 図000004
  • 特許6496033-画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト 図000005
  • 特許6496033-画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト 図000006
  • 特許6496033-画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト 図000007
  • 特許6496033-画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト 図000008
  • 特許6496033-画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト 図000009
  • 特許6496033-画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト 図000010
  • 特許6496033-画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト 図000011
  • 特許6496033-画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト 図000012
  • 特許6496033-画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト 図000013
  • 特許6496033-画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト 図000014
  • 特許6496033-画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト 図000015
  • 特許6496033-画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト 図000016
  • 特許6496033-画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト 図000017
  • 特許6496033-画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト 図000018
  • 特許6496033-画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト 図000019
  • 特許6496033-画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト 図000020
  • 特許6496033-画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト 図000021
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】6496033
(24)【登録日】2019年3月15日
(45)【発行日】2019年4月3日
(54)【発明の名称】画像シーケンストラックを処理する方法、装置、及びコンピュータプログラムプロダクト
(51)【国際特許分類】
   H04N 21/231 20110101AFI20190325BHJP
   H04N 21/236 20110101ALI20190325BHJP
   H04N 21/845 20110101ALI20190325BHJP
【FI】
   H04N21/231
   H04N21/236
   H04N21/845
【請求項の数】12
【全頁数】40
(21)【出願番号】特願2017-542061(P2017-542061)
(86)(22)【出願日】2016年2月2日
(65)【公表番号】特表2018-513574(P2018-513574A)
(43)【公表日】2018年5月24日
(86)【国際出願番号】FI2016050064
(87)【国際公開番号】WO2016128613
(87)【国際公開日】20160818
【審査請求日】2017年9月27日
(31)【優先権主張番号】14/618,650
(32)【優先日】2015年2月10日
(33)【優先権主張国】US
(73)【特許権者】
【識別番号】515076873
【氏名又は名称】ノキア テクノロジーズ オサケユイチア
(74)【代理人】
【識別番号】100099759
【弁理士】
【氏名又は名称】青木 篤
(74)【代理人】
【識別番号】100123582
【弁理士】
【氏名又は名称】三橋 真二
(74)【代理人】
【識別番号】100092624
【弁理士】
【氏名又は名称】鶴田 準一
(74)【代理人】
【識別番号】100141162
【弁理士】
【氏名又は名称】森 啓
(74)【代理人】
【識別番号】100196829
【弁理士】
【氏名又は名称】中澤 言一
(74)【代理人】
【識別番号】100141254
【弁理士】
【氏名又は名称】榎原 正巳
(72)【発明者】
【氏名】バイノッド クマール マラマル バダキタル
(72)【発明者】
【氏名】ミスカ ハンヌクセラ
(72)【発明者】
【氏名】ヤニ ライネマ
【審査官】 久保 光宏
(56)【参考文献】
【文献】 特開2011−49927(JP,A)
【文献】 特開2005−196832(JP,A)
【文献】 特表2007−508779(JP,A)
【文献】 特開2012−114909(JP,A)
【文献】 特表2011−528868(JP,A)
【文献】 "ISO/IEC 14496-12:2012(E)",ISO/IEC,2012年 9月15日,Corrected version of Fourth edition,Pages 1-25,63-66,87-90
【文献】 "ISO/IEC 14496-15:2014(E)",ISO/IEC,2014年 7月 1日,Third edition,Pages 1-9,39-45,55-63
(58)【調査した分野】(Int.Cl.,DB名)
H04N21/00−21/858
H04N5/76−5/956
CSDB(日本国特許庁)
IEEEXplore(IEEE)
(57)【特許請求の範囲】
【請求項1】
エンコーティング方法であって、
−静的メディアアイテムをコンテナファイル内に包含するステップと、
−一つ以上のメディアトラックを前記コンテナファイル内に包含するステップと、
−前記コンテナファイル内において、識別子値のリストによって、前記静的メディアアイテム及び前記一つ以上のメディアトラックがグループのエンティティであることを通知するステップと、
−前記コンテナファイル内において、前記グループのグループ化タイプを通知するステップであって、前記グループ化タイプは、前記グループの前記エンティティがデコーディング及び表示のための互いの代替肢であることを示し、識別子値の前記リストは、デコーディング及び表示のための選好順序を示す、ステップと、
を具備する方法。
【請求項2】
代替ピクチャの情報を前記コンテナファイル内に包含するステップを具備する、請求項1に記載の方法。
【請求項3】
代替ピクチャの情報は、異なる空間分解能、異なるピクチャアスペクト比、異なるビット深度、異なる色域のうちの一つに基づいて、ピクチャの代替グループに関係している、請求項に記載の方法。
【請求項4】
デコーディング方法であって、
−コンテナファイルから、静的メディアアイテム及び一つ以上のメディアトラックがグループのエンティティであることを示す識別子値のリストを解析するステップと、
−前記コンテナファイルから、前記グループのグループ化タイプを解析するステップと、
−前記グループ及び前記グループ化タイプに基づいて前記静的メディアアイテム及び前記一つ以上のメディアトラックのための処理を判定するステップであって、前記グループ化タイプは、前記グループの前記エンティティがデコーディング及び表示のための互いの代替肢であることを示し、識別子値の前記リストは、デコーディング及び表示のための選好順序を示す、ステップと、
を具備する方法。
【請求項5】
前記コンテナファイルから代替ピクチャの情報を解析するステップ、を具備する、請求項に記載の方法。
【請求項6】
第一ピクチャと関連付けられた第一値と第二ピクチャと関連付けられた第二値とが同一の値を有することを解析することにより、前記第一ピクチャと前記第二ピクチャとが代替肢であることを判定するステップ、を更に具備する、請求項に記載の方法。
【請求項7】
−静的メディアアイテムをコンテナファイル内に包含し、
−一つ以上のメディアトラックを前記コンテナファイル内に包含し、
−前記コンテナファイル内において、識別子値のリストによって、前記静的メディアアイテム及び前記一つ以上のメディアトラックがグループのエンティティであることを通知し、
−前記コンテナファイル内において、前記グループのグループタイプを通知し、前記グループ化タイプは、前記グループの前記エンティティがデコーディング及び表示のための互いの代替肢であることを示し、識別子値の前記リストは、デコーディング及び表示のための選好順序を示す
ように構成されたエンコーディング用の装置。
【請求項8】
代替ピクチャの情報を前記コンテナファイル内に包含するように更に構成されている、請求項に記載の装置。
【請求項9】
代替ピクチャの情報は、異なる空間分解能、異なるピクチャアスペクト比、異なるビット深度、異なる色域、という特性のうちの一つに基づいて、ピクチャの代替グループに関係している、請求項に記載の装置。
【請求項10】
−コンテナファイルから、静的メディアアイテム及び一つ以上のメディアトラックがグループのエンティティであることを示す識別子値のリストを解析し、
−前記コンテナファイルから、前記グループのグループ化タイプを解析し、
−前記グループ及び前記グループ化タイプに基づいて前記静的メディアアイテム及び前記一つ以上のメディアトラックのための処理を判定し、前記グループ化タイプは、前記グループの前記エンティティがデコーディング及び表示のための互いの代替肢であることを示し、識別子値の前記リストは、デコーディング及び表示のための選好順序を示す
ように構成されたデコーディング用の装置。
【請求項11】
前記コンテナファイルから、代替ピクチャの情報を解析するように更に構成されている、請求項10に記載の装置。
【請求項12】
第一ピクチャと関連付けられた第一値と第二ピクチャと関連付けられた第二値とが同一の値を有することを解析するように構成されることにより、前記第一ピクチャと前記第二ピクチャとが代替肢であると判定するように構成されている、請求項11に記載の装置。
【発明の詳細な説明】
【技術分野】
【0001】
本出願は、画像ファイルフォーマットに関し、且つ、更に詳しくは、意味的に関係付けられた画像シーケンストラックの処理に関する。
【背景技術】
【0002】
本節は、請求項において記述されている本発明の背景又は文脈を提供することを意図したものである。本節における説明は、実行可能ではあったものの、必ずしもこれまでに着想又は実行されたものではない概念を含んでいる場合がある。従って、そうではない旨が本節において示されていない限り、本節において記述されているものは、本出願における説明及び請求項にとって従来技術ではなく、且つ、本節における包含により、従来技術であることが承認されるものでもない。
【0003】
MPEG-H画像ファイルフォーマットは、ISOベースメディアファイルフォーマット(ISOBMFF:ISO Base Media File Format)の派生仕様の一つである。これは、現時点においては、HEVCコーディングされたスチール画像と、画像シーケンスと、を(包含により、且つ/又は、参照により)含むものと規定されている。この画像ファイルフォーマットは、ISOBMFFと同様に、オブジェクト指向のメカニズムを使用しており、この場合に、それぞれのオブジェクトは、ボックスと呼称されている。すべてのメディアデータ及びその関係したメタデータがボックス内にカプセル化されている。それぞれのボックスは、4文字コード(4CC:Four Character Code)によって識別され、且つ、ボックスのタイプ及びサイズについて通知するヘッダによって始まっている。
【0004】
ISOBMFFは、代替グループメカニズム、トラックグループメカニズム、及びサンプルグループ化メカニズムを具備する。代替グループメカニズムは、トラックが互いに代替肢であることを通知するべく使用することができる。トラックグループ化メカニズムは、トラックが、通知されたグループ化基準に従ってグループ化されていることを通知するべく、使用することができる。サンプルグループ化メカニズムは、特定のプロパティが、トラック内の通知されたサンプルのグループに対して適用されることを通知するべく、使用することができる。
【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】
図1図1は、一実施形態によるビデオコーディングシステムのブロックダイアグラムを示す。
図2図2は、一実施形態による装置のレイアウトを示す。
図3図3は、一実施形態による複数の装置、ネットワーク、及びネットワーク要素を有するビデオコーディング用の構成を示す。
図4図4は、一実施形態によるビデオエンコーダのブロックダイアグラムを示す。
図5図5は、一実施形態によるビデオデコーダのブロックダイアグラムを示す。
図6a図6a及び図6bは、画像及びそのitem_id、並びに、アイテムの異なるグループ化を示す。
図6b図6a及び図6bは、画像及びそのitem_id、並びに、アイテムの異なるグループ化を示す。
図7図7は、一実施形態による「grpl」ボックスのコンテンツを示す。
図8図8は、トラックベースメディア及びアイテムに基づいたメディア、並びに、それらの関係の一例を示す。
図9図9は、一実施形態による「grpl」ボックスのコンテンツを示す。
図10図10は、画像アイテムのグループ化の一例を示す。
図11図11は、一実施形態による「grpl」ボックスのコンテンツを示す。
図12図12は、有効な表示可能画像を出力するメディアアイテム及び派生画像アイテムのグループ化の一例を示す。
図13図13は、一実施形態による「grpl」ボックスのコンテンツを示す。
図14図14は、事前演算された派生画像アイテム及び派生画像に属するアイテムのグループ化の一例を示す。
図15図15は、一実施形態による「grpl」ボックスのコンテンツを示す。
図16図16は、一実施形態によるエンコーディング用の方法のフローチャートである。
図17図17は、一実施形態によるデコーディング用の方法のフローチャートである。
【発明を実施するための形態】
【0031】
図1は、一実施形態による機器又は電子装置50の概略ブロックダイアグラムとしてビデオコーディングシステムを示している。電子装置50は、一実施形態によればコーデックを内蔵することができる。図2は、一実施形態による装置のレイアウトを示している。以下、図1及び図2の要素について説明することとする。
【0032】
電子装置50は、例えば、無線通信システムのモバイル端末又はユーザ機器であってもよい。但し、本発明の実施形態は、エンコーディング及びデコーディングを必要とし得る、或いは、ビデオ画像のエンコーディング又はデコーディングを必要とし得る、任意の電子装置又は機器内において実装され得ることを理解されたい。
【0033】
装置50は、装置を内蔵又は保護するためのハウジング30を具備することができる。装置50は、液晶ディスプレイの形態のディスプレイ32を更に具備することができる。その他の実施形態においては、ディスプレイは、画像又はビデオの表示に適した任意の適切なディスプレイ技術であってもよい。装置50は、キーパッド34を更に具備することができる。一実施形態によれば、任意の適切なデータ又はユーザインタフェースメカニズムが利用されてもよい。例えば、ユーザインタフェースは、接触感知型ディスプレイの一部として、仮想キーボード又はデータエントリシステムとして実装されてもよい。装置は、マイクロフォン36又は任意の適切なオーディオ入力を具備していてもよく、これは、デジタル又はアナログ信号入力であってもよい。装置50は、オーディオ出力装置を更に具備していてもよく、これは、一実施形態によれば、イヤピース38、スピーカ、又はアナログオーディオ又はデジタルオーディオ出力接続のうちの任意のものであってよい。又、装置50は、電池40を具備することもできる(或いは、一実施形態においては、装置は、太陽電池、燃料電池、又はクロックワーク発電機(clockwork generator)などの、任意の適切な可動型エネルギー装置によって電力供給されてもよい)。装置は、画像及び/又はビデオを記録又はキャプチャする能力を有するカメラ42を更に具備することができる。一実施形態によれば、装置50は、その他の装置に対する近距離見通し通信用の赤外線ポートを更に具備することができる。一実施形態によれば、装置50は、例えば、Bluetooth無線接続又はUSB/firewire有線接続などの、任意の適切な近距離通信解決策を更に具備することができる。
【0034】
装置50は、装置50を制御するためのコントローラ56又はプロセッサを具備することができる。コントローラ56は、メモリ58に接続されていてもよく、メモリ58は、一実施形態によれば、画像の形態のデータとオーディオデータの両方を保存し得ると共に/又は、コントローラ56上における実装用の命令をも保存することができる。コントローラは、オーディオ及び/又はビデオデータのコーディング及びデコーディングの実行又はコントローラ56によって実行されるコーディング及びデコーディングの支援に適したコーデック回路54に更に接続されていてもよい。
【0035】
装置56は、ユーザ情報を提供するための、且つ、ネットワークにおけるユーザの認証及び認可用の認証情報を提供するのに適した、例えば、UICC及びUICCリーダなどの、カードリーダ48及びスマートカード46を更に具備することができる。
【0036】
装置50は、コントローラに接続されると共に、例えば、セルラー通信ネットワーク、無線通信システム、又は無線ローカルエリアネットワークとの通信用の、無線通信信号を生成するの適した、無線インタフェース回路52を更に具備することができる。装置50は、無線インタフェース回路52において生成された高周波信号をその他の一つ以上の装置に対して送信すると共に一つ以上のその他の装置から高周波信号を受信するための無線インタフェース回路52に接続されたアンテナ44を更に具備することができる。
【0037】
一実施形態によれば、装置50は、個々のフレームを記録又は検出する能力を有するカメラを具備しており、これらのフレームは、次いで、処理のためにコーデック54又はコントローラに伝達される。一実施形態によれば、装置は、送信及び/又は保存の前に、別の装置から、処理のためにビデオ画像データを受信することができる。一実施形態によれば、装置50は、無線で、或いは、有線接続により、コーディング/デコーディング用の画像を受信することができる。
【0038】
図3は、一実施形態による複数の装置、ネットワーク、及びネットワーク要素を具備するビデオコーディング用の構成を示している。図3との関係において、本発明の実施形態が利用され得るシステムの一例が示されている。システム10は、一つ以上のネットワークを通じて通信し得る複数の通信装置を具備する。システム10は、限定を伴うことなしに、無線セルラー電話ネットワーク(GSM、UMTS、CDMAネットワークなど)、IEEE802.x規格のいずれかによって定義されているものなどの無線ローカルエリアネットワーク(WLAN:Wireless Local Area Network)、Bluetoothパーソナルエリアネットワーク、Ethrenetローカルエリアネットワーク、トークンリングローカルエリアネットワーク、ワイドエリアネットワーク、及びインターネットを含む、有線又は無線ネットワークの任意の組合せを具備することができる。
【0039】
システム10は、実施形態の実装に適した有線及び無線通信装置又は機器50の両方を含むことができる。例えば、図3に示されているシステムは、携帯電話ネットワーク11と、インターネットの表現28と、を示している。インターネット28への接続は、限定を伴うことなしに、長距離無線接続、近距離無線接続、並びに、限定を伴うことなしに、電話線、ケーブルライン、電力線、及び類似の通信経路を含む様々な有線接続を含むことができる。
【0040】
システム10内において示されている例示用の通信装置は、限定を伴うことなしに、電子装置又は機器50、パーソナルデジタルアシスタント(PDA:Personal Digital Assistant)及び携帯電話機の任意の組合せ14、PDA16、統合型メッセージング装置(IMD:Integrated Messaging Device)18、デスクトップコンピュータ20、ノードブックコンピュータ22を含むことができる。装置50は、固定型であってもよく、或いは、移動する個人によって携行される際には、可動型であってもよい。又、装置50は、限定を伴うことなしに、自動車、トラック、タクシー、バス、列車、ボート、飛行機、自転車、オートバイ、又は任意の類似した適切な搬送のモードを含む、搬送モードにおいて配置されてもよい。
【0041】
いくつかの又は更なる装置は、通話又はメッセージを送信及び受信し得ると共に、基地局24に対する無線接続25を通じてサービスプロバイダと通信することができる。基地局24は、携帯電話ネットワーク11とインターネット28との間の通信を許容するネットワークサーバ26に接続されていてもよい。システムは、更なる通信装置及び様々なタイプの通信装置を含むことができる。
【0042】
通信装置は、限定を伴うことなしに、符号分割多重アクセス(CDMA:Code Division Multiple Access)、移動体通信用グローバルシステム(GSM:Global Systems for Mobile communication)、ユニバーサル移動体通信システム(UMTS:Universal Mobile Telecommunications System)、時分割多重アクセス(TDMA:Time Divisional Multiple Access)、周波数分割多重アクセス(FDMA:Frequency Division Multiple Access)、伝送制御プロトコル−インターネットプロトコル(TCP-IP:Transmission Control Protocol-Internet Protocol)、ショートメッセージングサービス(SMS:Short Messaging Service)、マルチメディアメッセージングサービス(MMS:Multimedia Messaging Service)電子メール、インスタントメッセージングサービス(IMS:Instant Messaging Service)、Bluetooth、IEEE802.11、及び任意の類似した無線通信技術を含む、様々な送信技術を使用して通信することができる。本発明の様々な実施形態の実装に関与する通信装置は、限定を伴うことなし、高周波、赤外線、レーザ、ケーブル接続、及び任意の適切な接続を含む、様々な媒体を使用して通信することができる。
【0043】
ビデオコーダは、入力ビデオを保存/送信に適した圧縮表現に変換するエンコーダと、圧縮されたビデオ表現を視聴可能な形態に圧縮解除して戻すことができるデコーダと、を具備することができる。エンコーダは、相対的にコンパクトな形態において(即ち、相対的に低いビットレートにおいて)ビデオを表すべく、オリジナルビデオシーケンス内のいくつかの情報を破棄してもよい。ビデオエンコーダは、後から定義されているように、画像シーケンスをエンコーディングするべく使用されてもよく、且つ、ビデオデコーダは、コーディング済みの画像シーケンスをデコーディングするべく使用されてもよい。ビデオエンコーダ、又はビデオエンコーダのイントラコーディング部分、或いは、画像エンコーダは、画像をエンコーディングするべく使用されてもよく、且つ、ビデオデコーダ、又はビデオデコーダのインターデコーディング部分、或いは、画像デコーダは、コーディング済みの画像をデコーディングするべく使用されてもよい。
【0044】
図4には、エンコーディングプロセスが示されている。図4は、ビデオエンコーダの一例を示しており、この場合に、Inは、エンコーディング対象の画像であり、P’nは、画像ブロックの予測表現であり、Dnは、予測誤差信号であり、D’nは、再構築された予測誤差信号でり、I’nは、予備再構築画像であり、R’nは、最終再構築画像であり、T、T-1は、変換及び逆変換であり、Q、Q-1は、量子化及び逆量子化であり、Eは、エントロピーエンコーディングであり、RFMは、基準フレームメモリであり、Pinterは、インター予測であり、Pintraは、イントラ予測であり、MSは、モード選択であり、Fは、フィルタリングである。
【0045】
図5には、デコーディングプロセスが示されている。図5は、ビデオデコーダのブロックダイアグラムを示しており、この場合に、P’nは、画像ブロックの予測表現であり、D’nは、再構築された予測誤差信号であり、I’nは、予備再構築画像であり、R’nは、最終再構築画像であり、T-1は、逆変換であり、Q-1は、逆量子化であり、E-1は、エントロピーデコーディングであり、RFMは、基準フレームメモリであり、Pは、予測(インター又はイントラ)であり、Fは、フィルタリングである。
【0046】
アドバンストビデオコーディング(H.264/AVC、別称:AVC(Advanced Video Coding))規格は、国際電気通信連合の電気通信標準化部門(ITU-T:International Telecommunication Union-Telecommunication standardization sector)のビデオコーディング専門家グループ(VCEG:Video Coding Experts Group)と国際標準化機構(ISO:Internatinal Organisation for Standardization)/国際電気標準会議(IEC:International Electrotechnical Commission)の動画専門家グループ(MPEG:Moving Picture Experts Group)のジョイントビデオチーム(JVT:Joint Video Team)によって開発されたものである。H.264/AVC規格は、両方の親標準化団体によって公開されており、且つ、ITU-T推奨H.264及びISO/IEC国際規格14496-10と呼称され、MPEG-4 Part 10アドバンストビデオコーディング(AVC)とも呼称されている。新しい拡張又は特徴を仕様に統合したH.264/AV規格の複数のバージョンが存在している。これらの拡張は、スケーラブルビデオコーディング(SVC:Scalable Video Coding)及びマルチビュービデオコーディング(MVC:Multiview Video Coding)を含む。
【0047】
高効率ビデオコーディング(H.265/HEVC、別称:HEVC(High Efficiency Video Coding))規格のバージョン1は、VCEG及びMPEGのジョイント協力チーム−ビデオコーディング(JCT-VC:Joint Collaborative Team-Video Coding)によって開発されたものである。この規格は、両方の親標準化団体によって公開されており、且つ、ITU-T推奨H.265及びISO/IEC国際規格23008-2と呼称され、MPEG-H Part 2 高効率ビデオコーディング(HEVC)とも呼称されている。H.265/HEVCのバージョン2は、スケーラブルな、マルチビューの、且つ、忠実度範囲の拡張を含んでおり、これらは、それぞれ、SHVC、MV-HEVC、及びREXTと省略され得る。H.265/HEVCのバージョン2は、ITU-T推奨H.265(10/2014)として事前公開されており、且つ、2015年において、ISO/IEC23008-2の第二版として公開される可能性が高い。現時点において、それぞれ、3D-HEVC及びSCCと省略され得る3次元及びスクリーンコンテンツコーディング拡張を含む、H.265/HEVCに対する更なる拡張を開発するための継続中の標準化プロジェクトが存在している。
【0048】
ユニフォームリソース識別子(URI:Uniform Resource Identifier)は、リソースの名称を識別するべく使用される文字のストリングとして定義されてもよい。このような識別情報は、特定のプロトコルを使用したネットワーク上におけるリソースの表現との間におけるやり取りを可能にする。URIは、URI用の具体的なシンタックス及び関連したプロトコルを規定する方式を通じて定義されている。ユニフォームリソースロケータ(URL:Uniform Resource Locator)及びユニフォームリソース名(URN:Uniform Resource Name)が、URIの形態である。URLは、ウェブリソースを識別すると共に、リソースの表現に対して作用すると共にこれを取得することにより、そのプライマリアクセスメカニズム及びネットワーク場所の両方を規定する手段を規定した、URIとして定義されてもよい。URNは、特定の名前空間内において、名前によってリソースを識別するURIとして定義されてもよい。URNは、その場所又はそのアクセス方法を示すことなしにリソースを識別するべく、使用されてもよい。
【0049】
利用可能なメディアファイルフォーマット規格は、ISOベースメディアファイルフォーマット(ISO/IEC14496-12、ISOBMFFと省略され得る)のみならず、MPEG-4ファイルフォーマット(ISO/IEC14496-14、MP4フォーマットとも呼称される)、NALユニット構造化ビデオ用のファイルフォーマット(ISO/IEC14496-15)、及び3GPPファイルフォーマット(3GPP TS26.244、3GPフォーマットとも呼称される)などの、ISOBMFFから導出された規格をも、含む。ISO/IEC14496-15は、ISOBMFF準拠ファイル内におけるH.264/AVC及び/又はHEVC並びに/或いはその拡張のビットストリームの保存を規定している。上述のファイルフォーマット(ISOファイルフォーマット自体を含む)のみならず、ISOBMFFから導出されたその他のファイルフォーマットは、ISOファイルフォーマットファミリーと呼称されてもよい。
【0050】
以下、実施形態が実装され得るコンテナファイルフォーマットの一例として、ISOBMFFのいくつかの概念、構造、及び仕様について説明する。本発明の態様は、ISOBMFFに限定されるものではなく、むしろ、この説明は、本発明が部分的に又は全体的に実現され得る一つの可能な基礎を目的として、付与されるものである。
【0051】
ISOベースメディアファイルフォーマット内の一つの構築ブロックは、ボックスと呼称されている。それぞれのボックスは、ヘッダと、ペイロードと、を有することができる。ボックスヘッダは、ボックスのタイプと、バイトの観点におけるボックスのサイズと、を通知している。ボックスは、その他のボックスを含んでいてもよく、且つ、ISOファイルフォーマットは、特定のタイプのボックス内において許容されているボックスのタイプを規定している。更には、いくつかのボックスの存在が、それぞれのファイル内において必須であってもよく、その他のボックスの存在は、任意選択であってもよい。これに加えて、いくつかのボックスタイプの場合には、一つのファイル内において複数のボックスが存在することを許容可能であってもよい。従って、ISOベースメディアファイルフォーマットは、ボックスの階層構造を規定していると見なすことができる。ISOベースメディアファイルのそれぞれのボックスは、4文字コード(4CC、four-Character Code)によって識別することができる。4文字コードは、(8ビット値への文字の特定の変換、特定のビットエンディアン性、及び特定のバイトエンディアン性を仮定することにより)32ビット符号なし整数によって相互交換可能に表されてもよい。ヘッダは、ボックスのタイプ及びサイズに関する情報を提供することができる。
【0052】
ISOファイルフォーマットファミリーによれば、ファイルは、別個のボックス内において含まれ得るメディアデータ及びメタデータを含むことができる。例示用の実施形態においては、メディアデータは、メディアデータ(mdat)ボックス内において提供されてもよく、且つ、ムービー(moov)ボックスは、メタデータを包含するべく、使用されてもよい。いくつかのケースにおいては、ファイルが動作可能となるには、mdat及びmoovボックスの両方が存在していなければならない。ムービー(moov)ボックスは、一つ以上のトラックを含んでいてもよく、且つ、それぞれのトラックは、一つの対応したトラック(trak)ボックス内において存在することができる。それぞれのトラックは、トラックタイプを規定した、4文字コードによって識別される、ハンドラと関連付けられている。ビデオ、オーディオ、及び画像シーケンストラックは、メディアトラックと総称することが可能であり、且つ、これらは、基本メディアストリームを含む。その他のトラックタイプは、ヒントトラック及びタイミング設定されたメタデータトラックを具備する。トラックは、オーディオ又はビデオフレームなどのサンプルを具備する。メディアトラックとは、メディア圧縮フォーマット(並びに、ISOベースメディアファイルフォーマットに対するそのカプセル化)に従ってフォーマットされた(メディアサンプルと呼称され得る)サンプルを意味している。ヒントトラックとは、通知された通信プロトコル上における送信用のパケットを構築するためのクックブック命令を含むヒントサンプルを意味している。クックブック命令は、パケットヘッダ構築用のガイダンスを含み得ると共に、パケットペイロード構造を含むことができる。パケットペイロード構造内においては、その他のトラック又はアイテム内に存在しているデータが参照されてもよい。従って、例えば、その他のトラック又はアイテム内に存在しているデータは、パケット構築プロセスにおいてパケット内に複写されるように命令されている特定のトラック又はアイテム内のデータ片に関する参照により、通知されてもよい。タイミング設定されたメタデータトラックとは、参照されたメディアを記述したサンプル及び/又はヒントサンプルを意味し得る。一つのメディアタイプの提示のために、一つのメディアトラックが選択されてもよい。トラックのサンプルは、通知されたサンプルのデコーディング順序において、例えば、1だけ、増分され得るサンプル番号と黙示的に関連付けられてもよい。トラック内の第一サンプルは、サンプル番号1と関連付けられてもよい。
【0053】
「trak」ボックスは、「サンプルテーブル」ボックスを含む。「サンプルテーブル」ボックスは、例えば、トラック内のメディアサンプルのすべての時間及びデータインデックス付けを具備する。「サンプルテーブル」ボックスは、「サンプル記述」ボックスを含む必要がある。「サンプル記述」ボックスは、ボックス内に含まれているサンプルエントリの数を規定した、エントリカウントフィールドを含む。「サンプル記述」ボックスは、少なくとも一つのサンプルエントリを含む必要がある。サンプルエントリフォーマットは、トラックのハンドラタイプに依存している。サンプルエントリは、使用されるコーディングタイプに関する詳細な情報と、そのコーディングに必要とされるすべての初期化情報と、を付与している。
【0054】
ISOベースメディアファイルフォーマットは、一つのプレゼンテーションが一つのファイルに含まれるように、限定してはいない。従って、一つのプレゼンテーションがいくつかのファイル内において含まれていてもよい。一例として、一つのファイルは、プレゼンテーション全体のメタデータを含んでいてもよく、且つ、これにより、プレゼンテーションを自己完結型とするべく、すべてのメディアデータを含むことができる。その他のファイルは、使用される場合に、ISOベースメディアファイルフォーマットへのフォーマッティングが施されなくてもよく、且つ、メディアデータを含むべく、使用されてもよく、且つ、使用されていないメディアデータ又はその他の情報を含んでいてもよい。ISOベースメディアファイルフォーマットは、プレゼンテーションファイルの構造にのみ関係している。メディアデータファイルのフォーマットは、メディアファイル内のメディアデータが、ISOベースメディアファイルフォーマット又はその他の派生フォーマットにおいて規定されているようにフォーマッティングされるという点においてのみ、ISOベースメディアファイルフォーマット又はその派生フォーマットにより、制約され得る。
【0055】
外部ファイルを参照する能力は、データ参照を通じて実現することができる。いくつかの例においては、それぞれのトラック内に含まれていたサンプル記述ボックスが、サンプルエントリのリストを提供してもよく、サンプルエントリのそれぞれは、使用されているコーディングタイプに関する詳細情報と、そのコーディングに必要とされるすべての初期化情報と、を提供する。すべてのチャンクのサンプル及びすべてのトラックフラグメントのサンプルは、同一のサンプルエントリを使用してもよい。一つのチャンクは、一つのトラックについての連続的なサンプルの組として定義されてもよい。こちらもそれぞれのトラック内において含まれ得る、「データ参照(dref)」ボックスは、ユニフォームリソースロケータ(URL)、ユニフォームリソース名(URN)のインデックス付けされたリスト、及び/又は、メタデータを含むファイルに対する自己参照を定義してもよい。サンプルエントリは、「データ参照」ボックスの一つのインデックスを指し示すことにより、個々のチャンク又はトラックフラグメントのサンプルを含むファイルを通知することができる。
【0056】
ムービーフラグメントは、例えば、記録アプリケーションが、クラッシュした場合、メモリ空間を使い果たした場合、或いは、なんらかのその他の事故が発生した場合に、データの喪失を回避するべく、例えば、コンテンツをISOファイルに記録する際に、使用されてもよい。ムービーフラグメントが存在しない場合には、データ喪失が発生する場合があり、その理由は、例えば、ムービーボックスなどの、すべてのメタデータが、ファイルの一つの連続的なエリア内において書き込まれることをファイルフォーマットが必要とし得るからである。更には、ファイルを記録する際に、利用可能なストレージのサイズにおいて、ムービーボックスをバッファ処理するための十分な量のメモリ空間(例えば、ランダムアクセスメモリRAM)が存在していない場合があり、従って、ムービーがクローズされた際にムービーボックスのコンテンツの再演算が過剰に低速となる場合がある。更には、ムービーフラグメントは、通常のISOファイルパーサーを使用したファイルの同時記録及び再生を可能にすることもできる。更には、ムービーフラグメントが使用されており、且つ、処理ムービーボックスが、同一のメディアコンテンツを具備するファイルとの比較において相対的に小さいが、ムービーフラグメントを有することなしに構造化されている際には、例えば、ファイルの同時受信及び再生などの漸進的ダウンローディングのために、相対的に短い初期バッファリングの持続時間が必要とされる場合もある。
【0057】
ムービーフラグメント機能は、さもなければムービーボックス内に存在し得るメタデータを複数片に分割することを可能にすることができる。それぞれの断片は、トラックの特定の期間に対応し得る。換言すれば、ムービーフラグメント機能は、ファイルメタデータ及びメディアデータのインターリービングを可能にすることができる。その結果、ムービーボックスのサイズが制限され得ると共に、上述のユースケースを実現することができる。
【0058】
いくつかの例においては、ムービーフラグメントのメディアサンプルは、moovボックスと同一のファイル内に存在している場合には、mdatボックス内に存在することができる。但し、ムービーフラグメントのメタデータの場合には、moofボックスが提供されてもよい。moofボックスは、以前にmoovボックス内に存在していたであろう特定の再生時間の持続時間の情報を含んでいてもよい。moovボックスは、それ自体で、有効なムービーを依然として表すことができるが、これに加えて、ムービーフラグメントが同一のファイル内において後続することになることを通知するmvexボックスを含んでいてもよい。ムービーフラグメントは、時間においてmoovボックスと関連付けられたプレゼンテーションを拡張することができる。
【0059】
ムービーフラグメント内には、ゼロ〜複数個/トラックのうちのいずれかを含む、トラックフラグメントの組が存在することができる。そして、トラックフラグメントは、ゼロ〜複数個のうちのいずれかのトラックランを含んでいてもよく、この文書のそれぞれは、そのトラック用の連続的なサンプルのランである。これらの構造内においては、多くのフィールドが、任意選択であり、且つ、既定値に設定されてもよい。いくつかのケースにおいては、moofボックス内に含まれ得るメタデータは、moovボックス内に含まれ得るメタデータのサブセットに限定されてもよく、且つ、異なる方式によってコーディングされてもよい。moofボックス内に含まれ得るボックスに関する詳細は、ISOベースメディアファイルフォーマット仕様において見出すことができる。自己完結型のムービーフラグメントは、ファイル順序において連続的であると共に、mdatボックスが、(moofボックスがメタデータを提供する)ムービーフラグメントのサンプルを含んでいるが、なんらのその他のムービーフラグメントのサンプル(即ち、なんらのその他のmoofボックス)をも含んでいない、moofボックス及びmdatボックスから構成されるものと定義されてもよい。
【0060】
ISOベースメディアフォーマットは、サンプルグループ、タイミング設定されたメタデータトラック、及びサンプル補助情報という、特定のサンプルと関連付けられ得るタイミング設定されたメタデータ用の三つのメカニズムを含む。派生仕様は、これらの三つのメカニズムのうちの一つ以上を有する類似の機能を提供することができる。
【0061】
AVCファイルフォーマット及びSVCファイルフォーマットなどの、ISOベースメディアファイルフォーマット及びその派生物におけるサンプルグループ化は、グループ化基準に基づいた、一つのサンプルグループのメンバとなるためのトラック内のそれぞれのサンプルの割当として定義されてもよい。サンプルグループ化内のサンプルグループは、連続的サンプルであることに限定されるものではなく、且つ、隣接していないサンプルを含むことができる。トラック内のサンプルについて、複数のサンプルグループ化が存在し得ることから、それぞれのサンプルグループ化は、グループ化のタイプを通知するべく、タイプフィールドを具備することができる。サンプルグループ化は、二つのリンクされたデータ構造によって表されてもよく、(1)SampleToGroupボックス(sbgpボックス)は、サンプルグループに対するサンプルの割当を表し、且つ、(2)SampleGroupDescriptionボックス(sgpdボックス)は、グループのプロパティを記述するそれぞれのサンプルグループごとのサンプルグループエントリを含む。異なるグループ化基準に基づいて、SampleToGroup及びSampleGroupDescriptionボックスの複数のインスタンスが存在してもよい。これらは、グループ化のタイプを通知するべく使用されるタイプフィールドによって弁別することができる。「sbgp」及び「sgpd」ボックスは、grouping_typeの値を使用することにより、且つ、ボックスのいくつかのバージョンにおいては、更にgrouping_type_parameterの値を使用することにより、リンクされてもよい。「sbgp」ボックスは、特定のサンプルが属するサンプルグループ記述エントリのインデックスを通知している。
【0062】
ISOBMFFに準拠したファイルは、メタボックス内において、アイテム、メタアイテム、又はメタデータアイテムと呼称される、任意のタイミング設定されていないオブジェクトを含むことができる(4文字コード:「meta」)。メタボックスという名称は、メタデータを参照しているが、アイテムは、一般に、メタデータ又はメディアデータを含むことができる。メタボックスは、ムービーボックス(4文字コード:「moov」)内において、且つ、トラックボックス(4文字コード:「trak」)内において、ファイルのトップレベルにおいて存在し得るが、最大で、一つのメタボックスが、ファイルレベル、ムービーレベル、又はトラックレベルのそれぞれにおいて発生することができる。メタボックスは、「meta」ボックスコンテンツの構造又はフォーマットを通知する「hdlr」ボックスを含むことが必要とされる場合がある。メタボックスは、参照され得る任意の数のアイテムを列挙及び特徴付けし得ると共に、それらのそれぞれのものは、ファイル名と関連付けることが可能であり、且つ、整数値であるアイテム識別子(item_id)により、ファイルと共に一意に識別される。メタデータアイテムは、例えば、メタボックスの「idat」ボックス内において、或いは、「mdat」ボックス内において、保存されてもよく、或いは、別個のファイル内に存在することもできる。メタデータが、ファイルの外部において配置されている場合には、その場所は、DataInformationBoxによって宣言されてもよい(4文字コード:「dinf」)。メタデータがXMLシンタックスを使用してフォーマッティングされており、且つ、MetaBox内において直接的に保存されることが必要とされている特定のケースにおいては、メタデータは、XMLBox(4文字コード:「xml」)又はBinaryXMLBox(4文字コード:「bxml」)内にカプセル化されてもよい。アイテムは、連続的なバイト範囲として保存されてもよく、或いは、それぞれが連続的なバイト範囲であるいくつかの領域内において保存されてもよい。換言すれば、アイテムは、例えば、インターリービングを可能にするべく、複数の領域にフラグメント化された状態において、保存されてもよい。一つの領域は、リソースの連続的なバイトのサブセットであり、リソースは、領域を連結することによって形成することができる。
【0063】
階層構造の任意のレベル(ファイル、ムービー、又はトラック)において複数のメタボックスをサポートするべく、メタボックスコンテナボックス(「meco」)が、一つのISOベースメディアファイルフォーマットとして使用されてもよい。メタボックスコンテナボックスは、階層構造の任意のレベル(ファイル、ムービー、又はトラック)において任意の数の更なるメタボックスを保持してもよい。これは、例えば、同一のメタデータが、二つの異なる代替メタデータシステム内において提示されることを許容することができる。メタボックス関係ボックス(「mere」)は、例えば、正確に同一の(但し、異なる方式によって記述された)メタデータを含んでいるのか、或いは、一つのものが別のもののスーパーセットを表しているのかなどの、異なるメタボックスが互いに関係している方式の記述を可能にすることができる。
【0064】
(フラグメント識別子を伴うことなしに)URLのベース部分によって通知された、ファイルなどの、リソースの一部分にアクセスするべく、特定のコンテンツタイプについて、URLフラグメント識別子(これも、URL形態と呼称され得る)が規定されてもよい。URLフラグメント識別子は、例えば、URL内において、ハッシュ(「#」)文字によって識別されてもよい。ISOBMFFの場合には、URLフラグメント「#X」が、Xに等しいtrack_IDを有するトラックを参照し、「#item_ID=」及び「#item_name」が、一つ以上のファイルレベルのメタボックスを参照し、「#/item_ID=」及び「#/item_name=」が、Movieボックス内の一つ以上のメタボックスを参照し、且つ、「#track_ID=X/item_ID=」及び「#track_ID=X/item_name=」が、ムービーフラグメント内において潜在的に見出されるメタデータを含む、Xに等しいtrack_IDを有するトラック内のメタボックスを参照するものと規定されてもよい。
【0065】
マトリョーシカファイルフォーマットは、ビデオ、オーディオ、ピクチャ、又はサブタイトルトラックのいずれか(但し、これらに限定されない)を一つのファイル内において保存する能力を有する。マトリョーシカは、WebMなどの、派生ファイルフォーマット用の基本フォーマットとして使用されてもよい。マトリョーシカは、拡張可能バイナリメタ言語(EBML:Extensible Binary Meta Language)を基礎として使用している。EBMLは、XMLの原理によって着想された、バイナリ及びオクテット(バイト)によってアライメントされたフォーマットを規定している。EBML自体は、バイナリマークアップの技法の一般化された記述である。マトリョーシカファイルは、EBML「文書」を構成する要素から構成されている。要素は、要素ID、要素のサイズ用の記述子、及びバイナリデータ自体を内蔵している。要素は、ネストさせることができる。マトリョーシカのセグメント要素は、その他のトップレベル(レベル1)要素用のコンテナである。一つのマトリョーシカファイルは、一つのセグメントを有することができる(但し、一つに限定されてはいない)。マトリョーシカファイル内のマルチメディアデータは、クラスタ(又は、クラスタ要素)として編成されており、クラスタのそれぞれは、通常、数秒のマルチメディアデータを含んでいる。クラスタは、BlockGroup要素を有し、BlockGroup要素は、ブロック要素を有する。キュー要素は、ランダムアクセス又はシーキングを支援し得るメタデータを有し、且つ、ファイルポインタ又はシークポイント用の個々のタイムスタンプを含むことができる。
【0066】
MPEG-H画像ファイルフォーマット(ISO/IEC23008-12)は、ISOベースメディアファイルフォーマット(ISOBMFF)の派生仕様である。本特許出願を作成している時点においては、ISO/IEC23008-12は、ドラフト規格であった。従って、規格の名称及び/又はニックネームは、結果的に、規格の最終バージョンにおいて変化し得ることを理解する必要がある。ISO画像ファイルフォーマット(ISOIFF)及びMPEG画像ファイルフォーマットなどの名称が検討されている。規格の仕様自体においては(或いは、さもなければ、文脈が明白である際には)、ISO/IEC23008-12を参照するべく、「画像ファイルフォーマット」という名称を使用することができる。
【0067】
以下、実施形態が実装され得るコンテナファイルフォーマットの一例として、MPEG-H画像ファイルフォーマットのいくつかの概念、構造、及び仕様について説明する。本発明の態様は、MPEG-H画像ファイルフォーマットに限定されるものではなく、むしろ、この説明は、本発明が部分的に又は完全に実現され得る一つの可能な基礎を目的として、付与されるものである。
【0068】
MPEG-H画像ファイルフォーマットは、ISOBMFFから、その基本構造を導出している。従って、ISOBMFFと同様に、MPEG-H画像ファイルフォーマットは、オブジェクト指向のメカニズムを使用しており、この場合に、それぞれのオブジェクトは、ボックスと呼称されている。すべてのメディアデータ及びその関係したメタデータは、ボックス内にカプセル化されている。それぞれのボックスは、4文字コード(4CC)によって識別され、且つ、ボックスのタイプ及びサイズについて通知するヘッダにより、始まっている。
【0069】
MPEG-H画像ファイルフォーマットによれば、スチール画像は、アイテムとして保存されている。コーディング済みの画像を含む画像アイテムが、独立的にコーディングされ、且つ、そのデコーディングの際になんらのその他のアイテムにも依存していないことが必要とされ得る。
【0070】
MPEG-H画像ファイルフォーマットの文脈においては、以下のボックスが、ルートレベルの「メタ」ボックス内において含まれてもよく、且つ、以下において記述されているように使用されてもよい。MPEG-H画像ファイルフォーマットにおいては、「メタ」ボックスのハンドラボックスのハンドラ値は、「pict」である。コーディングされたメディアデータを含むリソース(同一のファイル内であるのか、又はユニフォームリソース識別子によって識別された外部ファイル内であるのかを問わない)は、データ情報(「dinf」)ボックスを通じて解決され、アイテム場所(「iloc」)ボックスは、参照されたファイル内のすべてのアイテムの位置及びサイズを保存している。アイテム参照(「iref」)ボックスは、タイプ入力された参照付けを使用してアイテムの間の関係を記述している。なんらかの方式において、その他のものとの比較において、最も重要であると考えられるアイテムがアイテムの集合体の中に存在している際に、このアイテムは、プライマリアイテム(「pitm」)ボックスによってシグナリングされる。又、本明細書において記述されているボックスとは別に、「meta」ボックスは、アイテムを記述するべく必要とされ得るその他のボックスを含むように、柔軟である。
【0071】
「meta」ボックス方式を使用することによって保存されたコレクション画像が付与された場合に、しばしば、画像の間の特定の関係を修正することが不可欠である。このような関係の例は、コレクション用のカバー画像の通知、コレクション内の画像のいくつか又はすべて用のサムネイル画像の提供、及びコレクション内のいくつか又はすべての画像のアルファプレーンなどの補助画像との間の関連付けを含む。画像のコレクションのうちのカバー画像は、「pitm」ボックスを使用することにより、通知される。サムネイル画像又は補助画像は、それぞれ、「thmb」又は「auxl」タイプのアイテム参照を使用することにより、プライマリ画像アイテムに対してリンクされる。
【0072】
MPEG-H画像ファイルフォーマットは、派生画像をサポートしている。アイテムは、別のアイテムに対する「dimg」アイテム参照を含んでいる際に、派生画像である。派生画像は、回転などの規定された動作を規定された入力画像に対して実行することにより、得られる。派生画像を得るべく実行される動作は、アイテムのitem_typeにより、識別される。派生画像に対する入力として使用される画像アイテムは、例えば、「hvcl」アイテムタイプを有する、コーディング済みの画像であってもよく、或いは、その他の派生画像アイテムであってもよい。
【0073】
MPEG-H画像ファイルフォーマット仕様は、クリーンアパーチャ(即ち、クロッピング)動作、複数回にわたる90度回転のための回転動作、及び画像オーバーレイ動作の仕様を含む。画像オーバーレイである「iovl」派生画像は、相対的に大きなキャンバス内において所与の層化順序において一つ以上の入力画像を配置している。
【0074】
MPEG-H画像ファイルフォーマットの派生画像機能は、外部仕様のみならず、MPEG-H画像ファイルフォーマット自体の後のバージョンが、新しい動作を規定し得るように、拡張可能である。
【0075】
以下の定義は、例えば、MPEG-H画像ファイルフォーマット又は類似のファイルフォーマットの文脈において、使用されてもよい。コーディング済みの画像は、画像のコーディングされた表現として定義されてもよい。派生画像は、通知された画像に対する通知された動作により、ファイル内において表されている画像として定義されてもよく、且つ、通知された画像に対して通知された動作を実行することにより、取得することができる。画像は、画像という用語が使用されている文脈に応じて、コーディング済みの画像、派生画像、又は異なる色成分のピクセルの一つ以上のアレイとして、定義されてもよい。画像コレクションは、MPEG-H画像ファイルフォーマット(又は、これに類似したもの)に従って、単一ファイルのアイテムとして保存された画像の組として定義されてもよい。補助画像は、表示が意図されていなくてもよいが、個々のプライマリ画像を補完する透明性データなどの補完情報を提供し得る、画像として定義されてもよい。カバー画像は、画像コレクション又は画像シーケンスを表す画像として定義されてもよく、且つ、その他の情報が、画像コレクション又は画像シーケンスの好ましい表示方法において利用可能ではない際に、表示されることになろう。事前演算された派生画像は、一つ以上のその他の画像から導出されたコーディング済みの画像として定義されてもよい。プライマリ画像は、アイテムとして保存されると共に補助画像又はサムネイル画像ではない画像として定義されてもよい。サムネイル画像は、プライマリ画像の相対的に低い分解能の表現として定義されてもよい。
【0076】
画像シーケンスは、勧告タイミングと関連付けられ得ると共に画像がインター予測され得る画像のシーケンスとして定義されてもよい。MPEG-H画像ファイルフォーマットにおいては、画像シーケンスは、ISOBMFFのトラックメカニズムに従って保存される。画像シーケンストラックは、画像の間にコーディング依存性が存在している際に、或いは、画像の再生がタイミング設定されている際に、使用される。画像シーケンストラックにおけるタイミングは、プレーヤのための勧告であると定義されてもよい。画像シーケンスとモーションビデオを弁別するべく、MPEG-H画像ファイルフォーマットには、新しい「pict」ハンドラタイプが導入されている。
【0077】
MPEG-H画像ファイルフォーマットは、HEVCコーディングされたスチール画像及び画像シーケンスを(包含により、且つ/又は、参照により)MPEG-H画像ファイルフォーマットに準拠したファイル内にカプセル化するための仕様を含む。その他のコーディングフォーマットによってコーディング済みの画像及び画像シーケンスのMPEG-H画像ファイルフォーマットに準拠したファイル内へのカプセル化を規定することができる。
【0078】
グループ化メカニズムは、「meta」ボックス内のアイテムについては、まだ利用可能ではない。更には、「meta」ボックス構造を使用して定義された画像及びトラック構造を使用して定義された画像シーケンス(或いは、その他のタイミング設定されたメディア)の組が意味的にリンクされ得るユースケースも存在している。この異なる方式によってコーディングされた構造の間の意味的なリンクを通知するための方法は、まだ、MPEG-H画像ファイルフォーマットによって定義されてはいない。
【0079】
MPEG-H画像ファイルフォーマットの現時点の仕様においては、意味的に関係付けられたスチール画像のグループ及び画像シーケンストラックのグループを取り扱う一貫性のある方法は存在していない。又、例えば、画像キャプチャ装置は、高品質画像のキャプチャと共に、画像の短いバーストを記録することもできる。画像バースト及び高品質画像は、いずれも、画像ファイルフォーマットにおいて保存することができる。但し、現時点においては、画像バーストと高品質画像が意味的に関係付けられていることを示唆する方法が、存在しておらず、且つ、従って、ファイルのコンテンツを提示する方法を決定することができる。
【0080】
別の例においては、コンテンツプロバイダは、独立的にコーディング済みの画像の組としてマルチビュー画像を保存するように、決定してもよい。これをMPEG-H画像フォーマットにおいて保存する際には、これらのビューのそれぞれは、HEVCスチール画像プロファイルを使用してコーディングすることができる。但し、現時点においては、ファイル内に保存されている画像の組がマルチビュー画像としてレンダリングされ得ることをリーダに通知する方法は、存在していない。
【0081】
現時点においては、トラックが互いに代替肢であることを通知するべく、ISOBMFFの代替グループメカニズムを使用することができる。「トラックヘッダ」ボックスは、alternate_groupシンタックス要素を含んでいる。alternate_groupの値が、二つ以上のトラックについて等しい際には、これらのトラックは、同一のトラックの代替グループに属しており、且つ、互いに代替肢であると定義することができる。再生のために選択するべきは、代替グループ内の一つのトラックのみである。
【0082】
代替グループ内のすべてのトラックが、メディア選択用の候補であるが、セッションにおいて又は再生においてそれらのトラックのいくつかの間においてスイッチングすることは、意味をなしえないであろう。例えば、異なるビットレートを有するビデオトラックの間におけるスイッチングを許容すると共にフレームサイズを維持することはできるが、異なるフレームサイズのトラックの間におけるスイッチングを許容することはできない。同様に、異なるビデオコーデック又は異なるオーディオ言語のトラックの間における―スイッチングではなく―選択を可能にすることが望ましい場合がある。選択及びスイッチングのためのトラックの間の区別には、代替グループに加えて、トラックをスイッチグループに割り当てることにより、対処することができる。一つの代替グループは、一つ以上のスイッチグループを含むことができる。代替グループ内のすべてのトラックは、メディア選択用の候補であり、スイッチグループ内のトラックも、セッションにおけるスイッチングのために利用可能である。異なるスイッチグループは、異なるフレームサイズや高い/低い品質などのような、異なる動作点を表すものと見なされてもよい。
【0083】
ISOBMFFのサブトラック機能は、トラックが互いに代替肢であるかどうか、並びに、セッションにおいてトラックの間においてスイッチングすることが意味を成すかどうか、を通知するべく、それらのトラック(全体)が代替及びスイッチグループに割り当てられ得るのと同一の方法により、トラックの一部分を代替及びスイッチグループに割り当てるべく、使用されてもよい。サブトラックは、層化されたメディアに適しており、この場合に、サブトラックは、トラックによって表されている層のサブセットを含むことができる。サブトラックレベルにおいて代替及びスイッチグループを定義することにより、メディア選択及び層化されたコーデックのスイッチング用の既存の規則の使用を可能にすることができる。サブトラックレベルの代替及びスイッチグループは、トラックレベルのグループと同一の番号付けを使用する。番号付けは、グループがトラック及びサブトラック境界に跨って定義され得るように、すべてのトラックにわたってグローバルである。サブトラックに対するコーディングされたデータのマッピングは、使用中のメディアコーディングに依存し得る。
【0084】
ISOBMFFのトラックグループ化メカニズムは、トラックが、通知されたグループ化基準に従ってグループ化されていることを通知するべく、使用することができる。「トラック」ボックス内に含まれている「トラックグループ」ボックスは、トラックのグループの通知を可能にし、この場合に、それぞれのグループは、特定の特性を共有しており、或いは、グループ内のトラックは、特定の関係を有する。ボックスは、ゼロ又はこれ以上の数のボックスを含み、且つ、特定の特性又は関係は、含まれているボックスのボックスタイプによって通知される。含まれているボックスは、識別子(32ビット符号なし整数)を含み、この識別子は、同一のトラックグループに属するトラックを結論付けるために使用することができる。「トラックグループボックス」内において同一タイプの含まれたボックスを含むと共にこれらの含まれたボックス内において同一の識別子値を有するトラックは、同一のトラックグループに属している。
【0085】
但し、トラックの代替グループメカニズム及びトラックグループ化メカニズムは、いずれも、トラックに対するアイテムの関係を通知することができない。
【0086】
更には、ISOBMFFのサンプルグループ化メカニズムは、特定のプロパティがトラック内の通知されたサンプルのグループに適用されることを通知するべく、使用することができる。このメカニズムは、静的アイテムの場合には、利用可能ではない。
【0087】
以下、いくつかの例を提供することとする。
【0088】
本実施形態によれば、コンテナファイルフォーマットは、静的メディアアイテム(例えば、画像)及びタイミング設定されたメディア(例えば、ビデオ)のグループ化を可能にするメカニズムを含んでおり、これらのアイテム及びメディアは、トラック内において論理的に配置することができる。
【0089】
図16には、一実施形態による方法が、フローチャートとして示されている。方法は、静的メディアアイテムをコンテナファイル内に包含するステップと、メディアトラックをコンテナファイル内に包含するステップと、ファイル内において、静的メディアアイテム及びメディアトラックがグループを形成していることを通知するステップと、ファイル内において、グループのグループ化タイプを通知するステップと、を具備する。
【0090】
図17には、別の実施形態による方法が、フローチャートとして示されている。方法は、コンテナファイルから、静的メディアアイテム及びメディアトラックがグループを形成していることを解析するステップと、コンテナファイルから、グループのグループ化タイプを解析するステップと、グループ及びグループ化タイプに基づいて静的メディアアイテム及びメディアトラック用の処理を判定するステップと、を具備する。
【0091】
一実施形態においては、方法は、静的メディアアイテムをコンテナファイル内に包含するステップと、一つ以上のトラックをコンテナファイル内に包含するステップと、ファイル内において、静的メディアアイテム及び以下のエンティティのうちの一つ以上がグループを形成していることを通知するステップと、
−一つ以上のトラックのうちの通知されたトラック
−一つ以上のトラックの通知されたグループであって、これは、例えば、トラックの代替グループであってもよく(且つ、例えば、ISOBMFFのalternate_groupシンタックス要素又は類似のシンタックス要素の値によって識別されてもよい)、或いは、特定の通知されたタイプのトラックグループであってもよい。
−通知されたサブトラック
−サンプルグループ化の任意のサンプルグループ記述エントリに対してマッピングされたすべてのサンプルを参照するトラックの通知されたサンプルグループ化
−通知されたトラックの通知されたサンプルグループ化の一つ以上の特定の通知されたサンプルグループ記述エントリに対してマッピングされたサンプル
−別の静的メディアアイテム
ファイル内において、グループのグループ化タイプを通知するステップと、
を具備する。
【0092】
一実施形態においては、方法は、コンテナファイルから、静的メディアアイテム及び以下のエンティティのうちの一つ以上がグループを形成していることを解析するステップと、
−一つ以上のトラックのうちの通知されたトラック
−一つ以上のトラックの通知されたグループであって、これは、例えば、トラックの代替グループであってもよく(且つ、例えば、ISOBMFFのalternate_groupシンタックス要素又は類似のシンタックス要素の値によって識別されてもよい)、或いは、特定の通知されたタイプのトラックグループであってもよい。
−サンプルグループ化の任意のサンプルグループ記述エントリに対してマッピングされたすべてのサンプルを参照するトラックの通知されたサンプルグループ化
−通知されたトラックの通知されたサンプルグループ化の一つ以上の特定の通知されたサンプルグループ記述エントリに対してマッピングされたサンプル
−別の静的メディアアイテム
コンテナファイルから、グループのグループ化タイプを解析するステップと、
グループ及びグループ化タイプに基づいて静的メディアアイテム及び以下のエンティティのうちの一つ以上用の処理を判定するステップと、
を具備する。
【0093】
エンティティという用語は、アイテム、トラック、トラックのグループ、サブトラック、サンプルグループ化に対してマッピングされたサンプルの組、及びサンプルグループ化の特定のサンプルグループ記述エントリに対してマッピングされたサンプルの組の任意のサブセットを集合的に意味することができる。一つのエンティティは、アイテムであってもよく、且つ、別のエンティティは、トラックであってもよい。それぞれのエンティティは、32ビット符号なし整数値などの識別子を有することができる。エンティティは、その他のエンティティの組を有することができる。
【0094】
一実施形態においては、エンティティは、静的メディアアイテム、トラック、トラックのグループ、トラックのサンプルのグループ、又はサブトラックを具備しており、且つ、方法は、第一エンティティをコンテナファイル内に包含するステップと、第二エンティティをコンテナファイル内に包含するステップと、ファイル内において、第一エンティティ及び第二エンティティがグループを形成していることを通知するステップと、ファイル内において、グループのグループ化タイプを通知するステップと、を具備する。
【0095】
一実施形態においては、エンティティは、例えば、エンティティのデータ構造内において識別子を含むことにより、32ビット符号なし整数などの、識別子と関連付けられている。方法は、第一識別子値を第一エンティティに割り当てると共に第二識別子値を第二エンティティに割り当てるステップを更に有しており、この場合に、第一識別子値は、第一エンティティ及び第二エンティティのタイプとは無関係に、第二識別子値と異なっている。エンティティの識別子値は、エンティティグループ化がファイル内において通知されている際には、エンティティのタイプとは無関係に、同一の値空間を使用しているものと見なすことができる。
【0096】
一実施形態においては、エンティティは、静的メディアアイテム、トラック、トラックのグループ、トラックのサンプルのグループ、又はサブトラックを具備しており、方法は、コンテナファイルから、第一エンティティ及び第二エンティティがグループを形成していることを解析するステップと、コンテナファイルから、グループのグループ化タイプを解析するステップと、グループ及びグループ化タイプに基づいて第一エンティティ及び第二エンティティ用の処理を判定するステップと、を具備する。
【0097】
一実施形態においては、グループ及び/又はエンティティを通知するべく、URLフラグメント識別子が規定されている。例えば、URLフラグメント「#entity_ID=」は、エンティティを参照しており、エンティティは、アイテム又はトラックなどの、上述の任意のタイプを有することができる。#entity_IDフラグメントを含むURLの一例は、http://www.example.com/file.mp4#entity_ID=100というものであってもよい。別の例においては、URLフラグメント「#group=4cc.id」は、4ccというタイプと、idというgoup_idと、を有するエンティティグループ化を意味している。#entity_IDフラグメントを含むURLの一例は、http://www.example.com/file.mp4#group=altr.99というものであってもよい。クライアントは、例えば、HTTP GET要求内において、上述のURLフラグメントを使用することにより、特定のエンティティ又はエンティティの特定のグループを含むファイルのサブセットを要求することができる。サーバ、送信装置、ゲートウェイ、又はこれらに類似したものは、例えば、HTTP GET応答のペイロード内においてなどのように、解決されたURL内において、要求されたエンティティ又は要求されたエンティティのグループを有するファイルのサブセットを包含することにより、上述のURLフラグメントを含むURLを解決することができる。
【0098】
画像ファイルフォーマット(例えば、MPEG-H)が、画像及び画像シーケンスをカプセル化するべく、使用される際には、独立的にコーディングされた画像アイテムのグループ化(メタボックス構造のみが使用される際)又は独立的にコーディングされた画像アイテム及び画像シーケンスのトラックのグループ化が必要とされるユースケースが存在している。本実施形態は、このようなグループ化メカニズムを可能にするシグナリング構造を画像ファイルフォーマットに提供している。シグナリング構造は、現時点の且つ将来のユースケースによって必要とされるすべての想定可能なグループ化を許容するように、その特性が包括的である。
【0099】
グループ化メカニズムは、グループ化のタイプを通知するための方法を含む。グループ化のタイプは、(限定を伴うことなしに)以下のうちの一つ以上であってもよい。
−グループ化されたアイテム及びトラックが互いに代替肢であることを通知する代替グループ化であり、且つ、通常、処理(例えば、デコーディング及び表示)を要するのは、これらのうちの一つのみである。
−識別されたアイテム又はトラックが、別の識別されたアイテム又はトラックのプレビュー目的のために使用されることを通知するプレビューグループ化。例えば、ビデオトラック及びスチール画像は、いずれも、逐次的な又はオーバーラップした方式によってキャプチャされてもよく、且つ、ビデオトラックが、スチール画像用のプレビューとして使用され得る、或いは、その逆に、スチール画像が、ビデオトラック用のプレビュー又はカバーピクチャとして使用され得ることが通知されてもよい。
−例えば、事前演算された派生画像のコレクションが、同一の入力画像から導出されているなどの、アイテム又はトラックが同一の供給源を有することを通知するグループ化。これは、例えば、異なる露光時間を有する同一のシーンの同一の画像の組の異なるバーションについて使用されてもよい。
−グループ化されたアイテム又はトラックが、異なる視点からの同一の画像を表していることを通知するマルチビューグループ化。
−等価なアイテム又はトラックを通知する、即ち、同一の画像コンテンツを表すアイテム又はトラックを通知する、グループ化。このグループ化は、正確に一つの派生画像がこのグループ化に対してマッピングされ、且つ、画像グループ化の一つのそれぞれのコーディング済みの画像は、エンコーディングに対する入力として派生画像を使用することにより、エンコーディングされており、且つ、従って、派生画像のコーディングされた表現であるケースについてのみ、使用又は許容されてもよい。
−グループに対してマッピングされたアイテム又はトラックが、正確に同一のコーディング済みの画像データを含んでいることを通知するグループ化。このグループ化は、画像が、アイテム及びトラックのサンプル(一つのサンプルのみを含む)としてファイル内に包含されているケースにおいて使用されてもよく、これは、ファイル内に含まれているタイミング設定されたメディアとの関係において画像のタイミングを通知するべく使用されてもよい。
【0100】
代替グループ化は、(限定を伴うことなしに)以下の目的又はユースケースのうちの一つ以上について使用されてもよい。
デコーディング及び表示されるべく、正確に一つのエンティティ(例えば、一つのアイテム又はトラック)が選択される代替グループの通知。
アニメーション(又は、これに類似したもの)及びスチール画像が代替肢であることの通知。代替肢は、例えば、アニメーション及びスチール画像が、表示される代替肢である場合に、使用されてもよく、且つ、プレーヤは、例えば、アニメーションをデコーディングするその能力に基づいて、表示されるように、アニメーション又はスチール画像を選択することができる。
派生画像の任意選択の動作の通知。第一派生画像が第二派生画像よりも少ない数の動作を有するように、第一派生画像と第二派生画像とが、入力及び動作の観点においてのみ、異なっている状態において、第一派生画像及び第二派生画像は、互いに代替肢であると通知される場合がある。従って、第二派生画像との比較において第一派生画像において欠けている動作は、受け入れ可能な画像(第二派生画像)が、前記欠けている動作を実行することなしに、得られ得るという意味において、任意選択の動作であると見なされてもよい。従って、派生画像の任意選択の動作を通知するべく、代替グループ化メカニズムを使用することができる。
事前演算された派生画像及び個々の派生画像が代替肢であることの通知であり、(派生画像又は派生画像に本質的に類似した画像がエンコーディングのための入力となっている)派生画像及び個々のコーデック画像のグループ化。事前演算された派生画像は、その再構築において、派生画像よりも少ない処理を必要とし得る一方で、それは、いくつかのコーディングアーチファクトを伴う場合がある。その一方で、派生画像は、事前演算された派生画像が構築された方式に関するメタデータとして機能してもよく、且つ、更なる導出が必要とされる場合に(その際の事前演算された派生画像のコーディングアーチファクトを回避するべく)入力として使用することができる。
【0101】
一実施形態においては、(例えば、グループ化されたアイテム及び/又はトラックを列挙したデータ構造内において)アイテム及び/又はトラックをグループ化する順序は、選好順序などの、セマンティクスを有することができる。セマンティクスは、グループ化タイプに依存し得る。
【0102】
エンティティグループ化メカニズムの一実施形態によれば、GroupsListボックス(「grpl」)と呼称される新しいコンテナボックスが、例えば、ファイルレベルの「meta」ボックス内における任意選択のボックスのうちの一つとして、ファイル内に含まれている。最大で、一つの「grpl」ボックスが存在していることが必要とされ得る。このボックスの機能は、ファイル内において使用されているすべての異なるエンティティグループ化を完全に定義した、EntityToGroupボックスと呼称される一つ以上のその他のボックスを含むというものである。それぞれのEntityToGroupボックスは、一意の4文字コード値によって弁別された状態において、一つの特定のグループ化について、専用となっている。ファイル内において同一のグループ化のタイプを有するエンティティの複数の組が存在し得ることを通知する「grpl」ボックス内に含まれた同一の4文字コード値を有する複数のボックスが存在してもよい。
【0103】
一実施形態においては、グループ自体は、group_idを使用して識別されてもよい。このgroup_idは、有用であり、その理由は、これが、相対的に大きなグループ内においても、このグループ内のエンティティを含むべく、使用され得るからである。グループのメンバは、識別子のリストであり、この場合に、識別子のそれぞれは、有効なエンティティ識別子値であり、これは、例えば、item_id、track_id、又はgroup_idであってもよい。
【0104】
GroupsListBox及びEntityToGroupBoxのシンタックスは、例えば、以下のように規定されてもよい。この例においては、group_idシンタックス要素は、EntityToGroupBox内に含まれている。この実施形態は、group_idシンタックス要素を伴うことなしに、同様に実現され得ることを理解する必要がある。
【0105】
aligned (8) class GroupsListBox extends Box(<x>grpl') {

aligned (8) class EntityToGroupBox (grouping_type, version, flags )
extends FullBox (grouping_type, version, flags) {
unsigned int(32) group_id;
unsigned int(32) num_entities_in_group;
for(i=0; i<num_entities_in_group; i++) {
unsigned int(32) entity_id;
【0106】
一実施形態においては、EntityToGroupBoxのセマンティクスは、例えば、以下のように規定されてもよい。
−grouping_typeは、グループ化タイプを表す4文字コードである。それぞれのgrouping_typeコードは、グループ化について記述したセマンティクスと関連付けられている。
−group_idは、特定のグループ化に対して割り当てられた一意の非負整数である。group_idは、item_id又はtrack_idとして、同一の数字空間から選択される。
−entity_idは、それぞれ、このグループに含まれるトラック、画像、又はその他のグループのtrack_id、item_id、又は別のgroup_idである。
【0107】
一実施形態においては、EntiteyToGroupBoxのセマンティクスは、例えば、以下のように規定されてもよい。
−grouping_typeは、グループ化タイプを表す4文字コードである。それぞれのgrouping_typeコードは、グループ化について記述するセマンティクスと関連付けられている。
−group_idは、特定のグループ化に対して割り当てられた非負整数である。
−entity_idは、以下のように、アイテム或いはトラック又はサブトラックの代替グループに対して解決される。
・entity_idに等しいitem_idを有するアイテムが存在している際には、そのアイテムは、この特定のグループ化に対してマッピングされる。
・grouping_typeが「altr」に等しい際には、entity_idに等しいalternate_groupを有するそれぞれのトラック又はサブトラックは、このグループの一部分である。
【0108】
一実施形態においては、その特性を十分に特徴付けするべく、更なるパラメータが、ファイル内において含まれていてもよく、或いは、グループ化について、ファイルから解析されてもよい。これを目的として、例示用の一実装形態においては、抽象ベースクラスであるGroupingParametersの継承されたオブジェクトであるgrouping_parametersフィールドが、EntityToGroupボックス内に含まれている。grouping_parametersオブジェクト内のフィールドは、グループ化ごとに(即ち、それぞれの一意のgrouping_type値ごとに)定義されてもよく、且つ、EntityToGroupボックスによって定義されたそのgrouping_typeについて必要とされている場合にのみ、EntiryToGroupボックス内に含まれるという点において、任意選択である。例えば、以下のシンタックスが使用されてもよい。この例においては、group_idシンタックス要素がEntityToGroupBox内に含まれている。この実施形態は、group_idシンタックス要素を伴うことなしに、同様に実現され得ることを理解する必要がある。
【0109】
abstract class GroupingParameters (grouping_type, version) { }
aligned ( 8 ) class EntityToGroupBox (grouping_type, version, flags )
extends FullBox (grouping_type, version, flags) {
unsigned int(32) group_id;
unsigned int(32) num_entities_in_group;
for(i=0; i<num_entities_in_group; i++) {
unsigned int(32) entity_id;

GroupingParameters grouping_parameters (grouping_type, version) ; //optional
【0110】
別の例示用の実装形態においては、EntityToGroupボックス内に含まれている属性のリストとして、更なるパラメータが含まれてもよい。属性のリストの存在には、グループ化タイプごとに、条件が付与されてもよく、例えば、これは、(例えば、「altr」4文字コードによって通知される)代替グループ化についてのみ、存在してもよい。属性の数が、EntityToGroupボックス(例えば、以下のシンタックスにおけるnum_attributes)内に含まれていてもよく、これにより、例えば、このグループ化のセマンティクスについて記述した記述又は弁別属性の数が通知される。リスト内のそれぞれの属性は、例えば、4文字コードであってもよい。例えば、以下のシンタックスが使用されてもよい。
【0111】
aligned (8) class EntityToGroupBox (grouping_type, version, flags)
extends FullBox (grouping_type, version, flags) {
unsigned int(32) group_id;
unsigned int(32) num_entities_in_group;
for(i=0; i<num_entities_in_group; i++)
unsigned int(32) entity_id;
if (grouping_type == 'altr') {
unsigned int(8) num_attributes ;
for(i=0; i<num_attributes ; i++) {
unsigned int (32) attribute;


【0112】
ファイルライタは、ファイル内において、画像アイテムが、表示を意図したものであるかどうかの情報を包含することができる。例えば、画像アイテムにリンクされた初期化アイテム又はメタデータアイテム内の、例えば、item_in_presentationと呼称される、フラグが、この目的のために使用されてもよい。item_in_presentationが0に等しい際には、画像アイテムは、プレゼンテーションの一部分ではなく、即ち、表示されることにならない。item_in_presentationが0を上回っている際には、画像アイテムは、プレゼンテーションの一部分であり、即ち、表示されてもよい。0に等しいitem_in_presentationは、表示を意図した別の派生画像の導出のための入力として使用される中間画像である派生画像の場合に、使用されてもよい。ファイルリーダは、ファイルから、画像アイテムが、表示を意図したものであるかどうか、に関する情報を解析してもよい。例えば、例えば、item_in_presentationと呼称され得る、フラグが、画像アイテムにリンクされた初期化アイテム又はメタアイテムから、解析されてもよい。
【0113】
一実施形態においては、様々な実施形態におけるグループ及びグループ化タイプに基づいた処理の前記判定は、アイテム又はトラックなどのデコーディング及び表示されるエンティティの判定を有する。例示用の一実施形態においては、画像アイテムを処理することができるが、画像シーケンストラックを処理することができないリーダは、以下の順序付けされたステップのうちの一つ以上に従って動作している。この例示用の実施形態においては、上述の例示用のシンタックス内のentity_idが、item_id又はalternate_groupを通知しているものと仮定されている。表示されるエンティティを判定する類似のプロセスが、許容されたエンティティタイプのその他の選択肢、シンタックスのその他の選択肢、及び判定ステップ用のその他の順序又はコンテンツについて、形成され得ることを理解する必要がある。
−ファイルが、例えば、ファイルエクスプローラアプリケーション内において、プレビューされる場合には、アプリケーション又はユースケースに最良に適するカバー画像のサムネイル画像(存在する場合)又はカバー画像が表示される。
−さもなければ、リーダが一つの画像のみの表示をサポートしている場合には、或いは、アプリケーション又はユースケースが、一つの画像のみが表示されるようになっている場合には、カバー画像が表示される。
−さもなければ(リーダが、複数の画像の表示をサポートしており、且つ、アプリケーション又はユースケースが、複数の画像が表示され得るようになっている場合)、表示される画像の組は、以下のように解決され、且つ、次いで、例えば、画像のグリッドを表示するなどのように、アプリケーション又はユースケースに最良に適するように、表示される。
・すべての画像は、まず、表示される画像の組内に包含される。
・サムネイル画像及び補助画像が、表示される画像の組から除外される。
・0に等しいitem_in_presentationを有する画像アイテムが、表示される画像の組から除外される。
・画像アイテムの代替グループが解決される。リーダがデコーディング及び再生し得ると共にアプリケーション又はユースケースに適したそれぞれの代替グループの第一画像のみが、表示される画像の組内において維持され、代替グループのその他の画像は、表示される画像の組から除外される。
【0114】
例示用の一実施形態においては、画像アイテム及び画像シーケンストラックを処理することができるリーダは、一つ以上の画像アイテム及び一つ以上のシーケンストラックの両方を含むファイルが入力として付与されている際に、以下の順序付けられたステップのうちの一つ以上に従って動作している。この例示用の実施形態においては、上述の例示用のシンタックス内のentity_idが、item_id又はalternate_groupを通知しているものと仮定されている。表示されるエンティティを判定する類似のプロセスが、許容されたエンティティタイプのその他の選択肢、シンタックスのその他の選択肢、及び判定ステップのその他の順序又はコンテンツについて、形成され得ることを理解する必要がある。
−例えば、ファイルが、ファイルエクスプローラアプリケーション内において、プレビューされ、且つ、アプリケーション又はユースケースが、プレビューの際に、タイミング設定された再生をサポートしていない場合には、アプリケーション又はユースケースに最良に適したカバー画像のサムネイル画像又はカバー画像が表示されることを要する。
−さもなければ、ファイルがプレビューされ、且つ、アプリケーション又はユースケースが、プレビューの際に、タイミング設定された再生をサポートしている場合に、以下の内容が適用される。
・カバー画像が、代替グループ(「altr」)の一部分である場合には、アプリケーション又はユースケースの目的に最良に適した、カバー画像のサムネイル、或いは、デコーディング及び表示され得るその代替グループからの第一エンティティが、表示されることを要する。
・さもなければ、アプリケーション又はユースケースに最良に適した、カバー画像のサムネイル又はカバー画像が、表示されることを要する。
−さもなければ、表示されるエンティティの組は、以下のように、解決され、且つ、次いで、アプリケーション又はユースケースに最良に適するように、表示される。
・すべての画像アイテム及び画像シーケンストラックが、まず、表示されるエンティティの組内に包含される。
・サムネイル画像及び補助画像が、表示されるエンティティの組から除外される。
・0に等しいitem_in_presentationを有する画像アイテムが、表示されるエンティティの組から除外される。
・表示が意図されていない画像シーケンストラックが、表示されるエンティティの組から除外される。例えば、1に等しいTrack_in_previewを有するISOBMFFトラックにおいては、0に等しいTrack_in_movie又は0に等しいTrack_enabledが、表示されるエンティティの組から除外される。補助ビデオ又は画像シーケンストラックが、0に等しいTrack_in_movieを有することが必要とされてもよく、或いは、補助ビデオ又は画像シーケンストラックが、表示されるエンティティの組から明示的に除外されてもよい。
・トラックの代替グループが解決される。アプリケーション又はユースケースに最良に適した代替グループ当たりに一つのトラックのみが、表示されるエンティティの組内において維持され、その他のものは、表示されるエンティティの組から除外される。
・エンティティの代替グループが解決される。リーダがデコーディング及び再生し得ると共にアプリケーション又はユースケースに適したそれぞれの代替グループの第一画像アイテムのみが、表示されるエンティティの組内において維持され、代替グループのその他のエンティティは、表示される画像の組から除外される。表示されるエンティティが、トラックの代替グループである場合には、それは、以前のブレットポイントの結果として、単一トラック内に既に解決されている。
【0115】
例えば、アイテムが閲覧可能であるかどうかを通知するべく、item_in_presentationなどのフラグの使用の代わりに又はこれに加えて、プライマリアイテムではないと共に「altr」タイプの任意のグループに対してマッピングされていない画像アイテムが表示されないことが、必要とされてもよく、或いは、推奨されてもよい。
【0116】
一実施形態においては、様々な実施形態におけるグループ及びグループ化タイプに基づいた処理の前記判定は、デコーディング及び表示されるアイテム又はトラックなどのエンティティの判定を有する。例示用の一実施形態においては、画像アイテムを処理することはできるが、画像シーケンストラックを処理することができないリーダは、以下の順序付けされたステップのうちの一つ以上に従って動作している。この例示用の実施形態においては、上述の例示用のシンタックス内のentity_idが、item_id又はalternate_groupを通知しているものと仮定されている。表示されるエンティティの判定の類似のプロセスが、許容されたエンティティタイプのその他の選択肢、シンタックスのその他の選択肢、及び判定ステップのその他の順序又はコンテンツについて、形成され得ることを理解する必要がある。
−リーダが、一つの画像のみの表示をサポートしている場合には、或いは、アプリケーション又はユースケースが、一つの画像のみが表示されるようになっている場合には、デコーディングされ得ると共にアプリケーション又はユースケースに最良に適した以下の画像又はそのサムネイル画像のうちの一つが、表示されることを要する。
・プライマリアイテム
・プライマリアイテムを含む代替グループ(「altr」)からの画像
−さもなければ(リーダが、複数の画像の表示をサポートしており、且つ、アプリケーション又はユースケースが、複数の画像が表示され得るようになっている場合)、表示される画像の組は、以下のように解決され、且つ、次いで、例えば、画像のグリッドを表示するなどのように、アプリケーション又はユースケースに最良に適するように、表示される。
・画像アイテムの代替グループが解決される。リーダがデコーディング及び再生し得ると共にアプリケーション又はユースケースに最良に適したそれぞれの代替グループの第一画像アイテムのみが、表示される画像の組内に包含される。
・プライマリアイテムが任意の代替グループの中に存在していない際には、それは、表示される画像の組内に包含される。
【0117】
例示用の一実施形態においては、画像アイテム及び画像シーケンストラックを処理することができるリーダは、一つ以上のアイテム及び一つ以上の画像シーケンストラックの両方を含むファイルが入力として付与された際には、以下の順序付けされたステップのうちの一つ以上に従って動作している。この例示用の実施形態においては、上述の例示用のシンタックス内のentity_idが、item_id又はalternate_groupを通知しているものと仮定されている。表示されるエンティティの判定の類似のプロセスが、許容されたエンティティタイプのその他の選択肢、シンタックスのその他の選択肢、及び判定ステップのその他の順序又はコンテンツについて、形成され得ることを理解する必要がある。
−リーダが、一つの画像又は画像シーケンスのみの表示をサポートしている場合には、或いは、アプリケーション又はユースケースが、一つの画像又は画像シーケンスのみが表示されるようになっている場合には、デコーディングされ得ると共にアプリケーション又はユースケースに最良に適した以下の画像又はその他のサムネイル画像のうちの一つが表示されることを要する。
・プライマリアイテム
・プライマリアイテムを含む代替グループ(「altr」)からのエンティティ
−さもなれば、表示されるエンティティの組は、以下のように解決され、且つ、次いで、アプリケーション又はユースケースに最良に適するように、表示される。
・エンティティの代替グループが解決される。リーダがデコーディング及び再生し得ると共にアプリケーション又はユースケースに適したそれぞれの代替グループの第一エンティティのみが、表示されるエンティティの組内に包含され、代替グループのその他のエンティティは、表示される画像の組から除外される。表示されるエンティティがトラックの代替グループである場合には、それは、次のブレットポイントの結果として、単一トラック内に解決される。
・エンティティのいずれの代替グループ内にも含まれていなかった、或いは、表示されるエンティティとして以前のブレットポイントにおいて選択された、トラックの代替グループが、解決される。アプリケーション又はユースケースに最良に適した、代替グループ当たりに一つのトラックのみが、表示されるエンティティの組内に包含される。
・プライマリアイテムが、いずれの代替グループの中にも存在しておらず、且つ、デコーディング可能である際には、それは、表示される画像の組内に包含される。
・トラックが、トラックの任意の代替グループの一部分であると通知されておらず(即ち、ISOBMFF内において0に等しいalternate_groupを有する)、再生可能であり(即ち、ISOBMFF内において、1に等しいTrack_in_movie及び1に等しいTrack_enabledを有する)、且つ、デコーディング可能である際には、それは、表示されるエンティティの組内に包含される。
【0118】
第一ユースケースの一例として、画像アイテムの信号代替表現について開示する。互いに代替肢である画像は、グループ内のアイテムが互いに代替肢であり、且つ、最良にレンダリングし得るグループ内のアイテムのいずれかを選択することができるとファイルリーダに通知するべく、アイテム−グループを使用することができる。
【0119】
例えば、三つの画像(画像0、画像1、画像2)の組を考えてみよう。ここで、それぞれの画像は、図6aに示されているように、三つの異なる空間分解能(Res0、Res1、Res2)においてコーディングされている。これらの画像は、「meta」構造を使用することにより、アイテム(I0、I1、I2、I3、I4、I5、I6、I7、I8)として保存されている。画像の異なる空間分解能がファイル内において保存されており、その理由は、リーダがその表示能力に最も適した画像を使用することをコンテンツプロバイダが所望しているからである。代替表現をシグナリングするべく、図6bに示されているグループ化(G0、G1、G2)を使用することが可能であり、この場合に、グループ化自体のシグナリングは、本実施形態を使用している。
【0120】
本出願において提示されているグループ化メカニズムを使用すれば、4文字コード値「alti」を有する新しいグループ化を使用することにより、アイテムの上述のグループ化を実装することができる。それぞれの「alti」ボックスは、互いに代替表現であるアイテムをグループ化する。次いで、すべての「alti」ボックスは、「grpl」ボックス内に収集される。これが、コンテンツ又は「grpl」ボックスを示す図7に示されている。
【0121】
第二のユースケースの一例として、代替メディア表現のシグナリングについて開示する。グループ化メカニズムは、二つの異なるメディアタイプをグループ化するべく、使用することもできる。カメラが、シーンをキャプチャするべく、高分解能画像と共に、小さな画像シーケンスを撮影するという例を考えてみよう。画像シーケンス及び高分解能画像は、いずれも、同一のファイル内において保存される。次いで、リーダは、自身が最良にレンダリングするメディアを選択するか、或いは、レンダリングを所望するメディアを選択するための選択肢をユーザに対して提供する。図8には、この例の図が示されており、この場合に、トラックベースメディア(トラックT0)及びアイテムに基づいたメディア(アイテムI0)は、互いに関係付けられており、且つ、一つのグループ(グループG0)と見なすことができる。
【0122】
本出願において提示されているグループ化メカニズムを使用すれば、4文字コード値「altm」を有する新しいグループ化を使用することにより、アイテム及びトラックの組合せのグループ化を実装することができる。それぞれの「altm」ボックスは、互いに代替表現であるアイテム及びトラックをグループ化する。次いで、すべての「altm」ボックスは、「grpl」ボックス内に収集される。これが、「grpl」ボックスのコンテンツを示す図9に示されている。
【0123】
第三のユースケースの一例として、マルチビューグループのシグナリングについて開示する。画像アイテム(Item-I0、Item-I1、Item-I2、Item-I3)は、それらがマルチビューグループに属することをシグナリングするべく、グループ化することもできる(Group-G0)。画像自体は、すべて独立的にコーディングされており、従って、これらは、いずれも、正常な画像レンダラにより、個々にレンダリングすることができる。但し、リーダが、(ビュー補間技法を使用することにより)画像のコレクションのマルチビューレンダリングを提供する能力を有する場合には、本出願において提示されているグループ化方法を使用することができる。図10は、このようなグループ化を示している。異なる視野角において同一のシーンをキャプチャした画像アイテムのグループ化である。これらの画像アイテムは、いずれも、出力画像をレンダリングするべくマルチビュー画像レンダラが使用し得るグループを形成している。
【0124】
本出願において提示されているグループ化メカニズムを使用すれば、4文字コード値「mlvw」を有する新しいグループ化を使用することにより、複数の角度において同一のシーンをレンダリングする画像コレクションに対して、マルチビューグループであるものとシグナリングすることができる。それぞれの「mlvw」ボックスが、マルチビューグループに属するアイテムをグループ化する。次いで、すべての「mlvw」ボックスは、「grpl」ボックス内に収集される。これが、「grpl」ボックスのコンテンツを示す図11に示されている。
【0125】
このグループ化は、grouping_parametersフィールドが固有のカメラパラメータをシグナリングすることを必要としている。固有のカメラパラメータは、画像ポイントのピクセル座標をカメラ基準フレーム内の対応した座標と関連付けている。カメラのオプティクスに起因した幾何学的歪と関係した焦点距離及びパラメータの仕様については、ISO/IEC14496-10の付属書Hにおいて付与されている。
【0126】
aligned(8) class MLVWGroupingParameters (<x>mlvw' , version)
extends GroupingParameters ( ) {
for(i=0; i<num_entities_in_group; i++) {
unsigned int(32) prec_focal_length;
unsigned int(32) prec_principal_point ; unsigned int(32) prec_skew_factor ;
unsigned int(8) exponent_focal_length_x;
signed int (64) mantissa_focal_length_x;
unsigned int (8) exponent_focal_length_y;
signed int (64) mantissa focal length unsigned int(8) exponent principal point x;
signed int (64) mantissa_principal_point_x;
unsigned int (8) exponent principal point y;
signed int (64) mantissa_principal_point_y;
unsigned int (8) exponent_skew_factor;
signed int (64) mantissa_skew_factor;

【0127】
セマンティクス:
−prec_focal_lengthは、2-prec_focal_lengthによって付与される、focal_length_x及びfocal_length_yの最大許容可能切り捨て誤差の指数を規定している。prec_focal_lengthの値は、両端を含む0〜31の範囲内となる。
【0128】
−prec_principal_pointは、2-prec_principal_pointによって付与される、principal_point_x及びprincipal_point_yの最大許容可能切り捨て誤差の指数を規定している。prec_principal_pointの値は、両端を含む0〜31の範囲内となる。
【0129】
−prec_skew_factorは、2-prec_skew_factorによって付与されるスキュー係数の最大許容可能切り捨て誤差の指数を規定している。prec_skew_factorの値は、両端を含む0〜31の範囲内となる。
【0130】
−exponent_focal_length_xは、水平方向における焦点距離の指数部分を規定している。exponent_focal_length_xの値は、両端を含む0〜62の範囲内となる。63という値が、ITU-T|ISO/IECによる将来の使用のために予約されている。デコーダは、規定されていない焦点距離を通知するものとして、63という値を取り扱うことになる。
【0131】
−mantissa_focal_length_xは、水平方向におけるi番目のカメラの焦点距離の仮数部分を規定している。
【0132】
−exponent_focal_length_yは、垂直方向における焦点距離の指数部分を規定している。exponent_focal_length_yの値は、両端を含む0〜62の範囲内となる。63という値は、ITU-T|ISO/IECによる将来の使用のために予約されている。デコーダは、規定されていない焦点距離を通知するものとして、63という値を取り扱うことになる。
【0133】
−mantissa_focal_length_yは、垂直方向における焦点距離の仮数部分を規定している。
【0134】
−mantissa_principal_point_xは、水平方向における主点の仮数部分を規定している。
【0135】
−exponent_principal_point_yは、垂直方向における主点の指数部分を規定している。exponent_principal_point_yの値は、両端を含む0〜62の範囲内となる。63という値は、ITU-T|ISO/IECによる将来の使用のために予約されている。デコーダは、規定されていない主点を通知するものとして、63という値を取り扱うことになる。
【0136】
−mantissa_principal_point_yは、垂直方向における主点の仮数部分を規定している。
【0137】
−exponent_skew_factorは、スキュー係数の指数部分を規定している。exponent_skew_factorの値は、両端を含む0〜62の範囲内となる。63という値は、ITU-T|ISO/IECによる将来の使用のために予約されている。デコーダは、規定されていないスキュー係数を通知するものとして、63という値を取り扱うことになる。
【0138】
−mantissa_skew_factorは、スキュー係数の仮数部分を規定している。
【0139】
カメラ用の固有行列Aは、以下のように表現されてもよい。
【0140】
【数1】
【0141】
固有行列のそれぞれのコンポーネントは、表1に規定されている変数から、以下のように演算される変数xとして、取得される。
−0<e<63である場合には、x=2e-31*(1+n÷2v)であり、ここで、v=max(0,e+p-31)である。
−eが0に等しい場合には、x=2-(30+v)*nであり、ここで、v=max(0,p-30)である。
【0142】
表1は、カメラパラメータ変数とシンタックス要素との間の関連を示している。
【0143】
【表1】
【0144】
第四のユースケースの一例として、提示可能な画像アイテムグループのシグナリングについて開示する。
【0145】
本出願において提示されているグループ化メカニズムにおいては、コーディング済みの画像アイテム及び別の画像を導出するための命令を提供するアイテムは、リーダがそのように所望している場合には、グループ内のアイテムが表示され得る画像を形成することをシグナリングするべく、グループ化することができる。このグループ化は、画像導出のチェーンに沿ったアイテムの特定の組合せが、提示されるべく意図されてはいないことをリーダに通知するために、有用である。このようなグループ化は、多層化することが可能であり、即ち、相対的に大きなグループを相対的に小さなグループから構成することができる。
【0146】
図12は、画像アイテム及び有効な表示可能画像を出力する派生画像アイテムのグループ化を示している。この例においては、item-I0及びitem-I1は、コーディング済みの画像である。item-I2は、(派生画像アイテムタイプ「clap」を使用して)item-I0の画像をクロッピングすることにより、item-I0を変更している。item-I3は、(派生画像アイテムタイプ「irot」を使用して)item-I1から回転された画像を導出している。item-I4は、(アイテムタイプ「iovl」を使用して)オーバーレイ画像を形成するべく、item-I2及びitem-I3の出力において得られた派生画像を組み合わせている。アイテムのいずれの組合せが提示可能な画像グループを結果的にもたらすのかをリーダに通知するべく、グループを形成することができる。
【0147】
この提示可能なピクチャを結果的にもたらすアイテムの組合せをシグナリングするべくグループ化メカニズムを使用する例においては、4文字コード値「oput」を有する新しいグループ化を構築することができる。それぞれの「oput」ボックスは、出力においてピクチャを生成するべく組み合わせられるアイテムをグループ化する。次いで、すべての「oput」ボックスは、「grpl」ボックス内に収集される。これが、「grpl」ボックスのコンポーネントを示す図13において示されている。
【0148】
第五のユースケースの一例として、派生画像及びその事前演算された画像代替肢を通知するためのグループ化を開示する。
【0149】
いくつかのユースケースにおいては、派生画像(その他の画像を導出するべく使用される命令との組合せにおける画像アイテム)及び既に事前演算されたバージョンを同一のファイル内において包含することができる。これは、簡単な画像レンダラが、(導出の複雑なプロセスを回避するべく)事前演算された画像を取得すると共に表示することを依然として許容しつつ、オリジナル画像に対して適用された編集のステップをリトレースすると共に、恐らくは、導出プロセスにおけるステップを変更する機能をエディタが有することを可能にするためのものである。本出願において記述されているグループ化方法は、ファイル内に含まれている代替肢についてファイル読取りエンティティにシグナリングするべく、使用することができる。
【0150】
これを例によって示すべく、item-I4におけるオーバーレイ動作の後に得られる派生画像を事前演算する、別の画像アイテムである、item-I5を含むように、提示可能なアイテムグループの以前の例を拡張する。これが、図14に示されている。図15は、「grpl」ボックスのコンテンツを列挙している。
【0151】
その他の実施形態とは独立的に又はこれと共に適用され得る一実施形態においては、ファイルクリエータが、ファイル内において、代替ピクチャの情報を包含させてもよく、且つ/又は、ファイルプレーヤが、ファイルから、代替ピクチャに関する情報を解析してもよい。
【0152】
二つ以上のピクチャは、ファイルプレーヤが、二つ以上のピクチャのうちの一つのみを表示することを要する場合に、互いに代替肢であると定義されてもよい。
【0153】
ピクチャの代替グループは、互いに代替肢であるピクチャの組として定義されてもよい。
【0154】
代替グループは、サブタイプを有することにより、第二ピクチャと第一ピクチャとを弁別する特性及び/又は基準を通知することができる。
【0155】
一実施形態によれば、第一ピクチャは、ファイル内において、代替グループ識別子の第一値と関連付けられてもよく、且つ、第二ピクチャは、ファイル内において、代替グループ識別子の第二値と関連付けられてもよい。ファイルクリエータは、第一値及び第二値を同一の値に設定することにより、第一ピクチャと第二ピクチャとが代替肢であることを通知してもよい。ファイルクリエータは、第一値及び第二値を互いに異なる値に設定することにより、第一ピクチャと第二ピクチャとが代替肢ではないことを通知してもよい。ファイルプレーヤは、ファイルから、第一値が第二値と等しいことを解析することにより、第一ピクチャ及び第二ピクチャが代替肢であることを判定してもよい。ファイルプレーヤは、ファイルから、第一値が第二値とは等しくないことを解析することにより、第一ピクチャ及び第二ピクチャが代替肢ではないことを判定してもよい。
【0156】
一実施形態によれば、ファイルクリエータは、ファイル内において、ピクチャの複数の代替グループに関する情報を含むことができる。一実施形態においては、ピクチャは、複数の代替グループに属していてもよい。一実施形態においては、ファイルクリエータは、ファイル内において、代替グループがそれに従って形成されている特性及び/又は基準を含むことができる。例えば、代替グループが、同一のピクチャコンテンツの異なる空間分解能及び/又はピクチャアスペクト比を表していることが通知されてもよい。別の例においては、代替グループが、同一のピクチャコンテンツの異なるビット深度及び/又は色域を表していることが通知されてもよい。一実施形態においては、ファイルプレーヤは、ファイルから、代替グループがそれに従って形成されている特性及び/又は基準を解析してもよく、且つ、特性及び/又は基準が、ファイルプレーヤが代替グループの中のピクチャの中においてピクチャを選択するために重要であり得るようなものである場合には、ファイルプレーヤは、ファイルから、特性及び/又は基準に関係付けられたピクチャ固有の情報を解析してもよく、且つ、ピクチャ固有の情報に従って、代替グループの中においてピクチャを選択してもよい。
【0157】
一実施形態によれば、ファイルクリエータは、一つ以上の(個々の)ピクチャ及び一つ以上の画像シーケンスが代替肢であることを通知することができる。例えば、ファイルクリエータは、シネマグラフなどのアニメーションがスチールピクチャの代替肢であることを通知することができる。画像ファイルフォーマット又はその他のISOBMFF派生フォーマットにおいては、ファイルクリエータは、ピクチャを表す一つ以上のメタアイテムが、通常は、画像シーケンス又はビデオを表す一つ以上のトラックの代替肢であることを通知することができる。
【0158】
一実施形態によれば、ファイルプレーヤは、ファイルから、一つ以上の(個々の)ピクチャ及び一つ以上の画像シーケンスが代替肢であることを解析することができる。例えば、ファイルパーサーは、ファイルから、シネマグラフなどのアニメーションがスチールピクチャの代替肢であることを解析することができる。画像ファイルフォーマット又はその他のISOBMFF派生フォーマットにおいては、ファイルパーサーは、ファイルから、ピクチャを表す一つ以上のメタアイテムが、通常は、画像シーケンス又はビデオを表す一つ以上のトラックの代替肢であることを解析することができる。
【0159】
画像ファイルフォーマット又はその他のISOBMFF派生フォーマットに適用可能な一実施形態においては、メタアイテム及びトラックなどのエンティティは、同一の値空間から予約された識別子値(それぞれ、item_id及びtrack_id値)を有するものと通知されてもよい。換言すれば、通知された際に、item_id及びtrack_id値は、等しくなることが許容されてはいない。通知は、例えば、「画像ファイルフォーマット」ブランドが、メジャーブランドとして、又は互換性を有するブランドとして、含まれている際には常に、メタアイテム及びトラックが、同一の値空間から予約された識別子値(それぞれ、item_id及びtrack_id値)を有するものと通知され得るように、例えば、ブランド要件において含まれていてもよい。
【0160】
一実施形態によれば、代替グループは、メタアイテム及びトラックが、同一の値空間から予約された識別子値(それぞれ、item_id及びtrack_id値)を有するものと通知され得る場合には、item_id又はtrack_id値であると解決され得る識別子値の組として、通知されてもよい。
【0161】
一実施形態によれば、代替ピクチャ又はピクチャシーケンスに対する参照は、一つ以上の識別子値として通知されてもよい。一つ以上の識別子値は、メタアイテム及びトラックが、同一の値空間から予約された識別子値(それぞれ、item_id及びtrack_id値)を有するものと通知され得る場合には、item_id値又はtrack_id値であるものと解決することができる。いくつかの実施形態においては、参照は、トラックにも適用されるように一般化されたアイテム参照であり、いくつかの実施形態においては、参照は、アイテムにも適用されるように一般化されたトラック参照であり、いくつかの実施形態においては、参照は、アイテム参照及びトラック参照の両方であってもよい。
【0162】
これらの実施形態は、利点を提供している。これらの実施形態は、アイテムやアイテムとトラックとの組合せをグループ化するための、或いは、相対的に小さなグループをいくつかの共通セマンティクスを表す相対的に大きなグループにグループ化するための、メカニズムを提供している。ファイルリーダは、グループ化を使用することにより、ファイルの最良の使用法について決定することができる。
【0163】
以上においては、いくつかの実施形態は、特定のシンタックス及び/又は特定のセマンティクスを参照して記述されている。実施形態は、これらのシンタックス及び/又はセマンティクスの特定の断片に限定されるものではなく、その他のシンタックス又はセマンティクスと共に同様に実現され得ることを理解する必要がある。
【0164】
以上においては、いくつかの実施形態は、MPEG-H画像ファイルフォーマット及び/又はISOベースメディアファイルフォーマットについて記述されている。実施形態は、これらのフィルフォーマットに限定されるものではなく、マトリョーシカなどのその他のファイルフォーマットについて同様に記述され得ることを理解する必要がある。
【0165】
以上においては、いくつかの実施形態は、画像アイテムとの関係において記述されている。実施形態は、任意のタイプのアイテム及び/又はその他のエンティティに適用され得ることを理解する必要がある。例えば、フォトグラフィックメタデータは、交換可能な画像ファイルフォーマット(Exif)メタデータに従ってフォーマッティングされたメタデータを含む第一アイテムと、拡張可能メタデータプラットフォーム(XMP:eXtensible Metadata Platform)仕様に従ってフォーマッティングされたメタデータを含む第二アイテムと、を使用することにより、保存されてもよい。第一アイテム及び第二アイテムが同一のメタデータを表している際には、これらは、(例えば、上述の「eqvl」グループ化タイプなどの)エンティティグループ化メカニズムを使用することにより、等価であるものと通知されてもよい。例えば、第一の列挙されたアイテムが意味的に同一のグループ化における第二の列挙されたアイテムのスーパーセットであるスーパーセット関係などのように、その他の関係が、その他のグループ化タイプによって規定されてもよい。
【0166】
以上においては、いくつかの実施形態は、プレーヤ又はファイルプレーヤとの関係において記述されている。リーダ、パーサー、ユーザエージェント、又はクライアントなどの、その他の用語が相互交換可能に使用され得ることを理解する必要がある。プレーヤは、スタンドアロンアプリケーションであってもよいが、これは必須ではないことを理解する必要がある。プレーヤは、例えば、ウェブブラウザ内において埋め込まれることが可能であり、且つ/又は、メディア処理のチェーン又はフィルタグラフ内のコンポーネントであってもよい。
【0167】
以上においては、いくつかの実施形態は、ファイルクリエータとの関係において記述されている。ライタ、ファイルライタ、ファイルジェネレータ、又はコンテンツプロバイダなどの、その他の用語が相互交換可能に使用され得ることを理解する必要がある。クリエータは、スタンドアロンアプリケーションであってもよいが、これは必須ではないことを理解する必要がある。ファイルクリエータは、例えば、スクリプトを使用することにより、例えば、ウェブサーバ内において埋め込まれることが可能であり、且つ/又は、メディア処理のチェーン又はフィルタグラフ内のコンポーネントであってもよい。
【0168】
本発明の様々な実施形態は、メモリ内に存在すると共に適切な装置が本発明を実行するようにするコンピュータプログラムコードの支援によって実装することができる。例えば、装置は、データを取扱い、受信し、且つ、送信するための回路及び電子機器と、メモリ内のコンピュータプログラムコードと、コンピュータプログラムコードを実行した際に、装置が一実施形態の特徴を実行するようにするプロセッサと、を有することができる。更には、サーバのようなネットワーク装置は、データを取扱い、受信し、且つ、送信するための回路及び電子機器と、メモリ内のコンピュータプログラムコードと、コンピュータプログラムコードを実行した際に、ネットワーク装置が一実施形態の特徴を実行するようにするプロセッサと、を有することができる。
【0169】
様々な実施形態は、コンピュータと共に使用されるべくその内部において実施されたコンピュータプログラムコードを保持するコンピュータ可読媒体を有するコンピュータプログラムプロダクトによって更に実装することが可能であり、コンピュータプログラムコードは、静的メディアアイテムをコンテナファイル内に包含するステップと、メディアトラックをコンテナファイル内に包含するステップと、ファイル内において、静的メディアアイテム及びメディアトラックがグループを形成していることを通知するステップと、ファイル内において、グループのグループ化タイプを通知するステップと、を具備する。更には、様々な実施形態は、コンピュータと共に使用されるべくその内部において実施されたコンピュータプログラムコードを保持するコンピュータ可読媒体を有するコンピュータプログラムプロダクトによって更に実装することが可能であり、コンピュータプログラムコードは、コンテナファイルから、静的メディアアイテム及びメディアトラックがグループを形成していることを解析するステップと、コンテナファイルから、グループのグループ化タイプを解析するステップと、グループ及びグループ化タイプに基づいて静的メディアアイテム及びメディアトラック用の処理を判定するステップと、を具備する。
【0170】
様々な実施形態は、処理用の手段と、エンコーディング用の手段と、静的メディアアイテムをコンテナファイル内に包含する手段と、メディアトラックをコンテナフィル内に包含する手段と、ファイル内において、静的メディアアイテム及びメディアトラックがグループを形成していることを通知する手段と、ファイル内において、グループのグループ化タイプを通知する手段と、を有する装置によって更に実装することができる。更には、様々な実施形態は、処理用の手段と、デコーディング用の手段と、コンテナファイルから、静的メディアアイテム及びメディアトラックがグループを形成していることを解析する手段と、コンテナファイルから、グループのグループ化タイプを解析する手段と、グループ及びグループ化タイプに基づいて静的メディアアイテム及びメディアトラック用の処理を判定する手段と、を具備する装置により、更に実装することができる。
【0171】
本発明は、以上において提示されている実施形態にのみ限定されるものではなく、添付の請求項の範囲内において変更され得ることが明らかである。
図1
図2
図3
図4
図5
図6a
図6b
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17