JP7243620B2 - 情報処理装置およびプログラム - Google Patents

情報処理装置およびプログラム Download PDF

Info

Publication number
JP7243620B2
JP7243620B2 JP2019507591A JP2019507591A JP7243620B2 JP 7243620 B2 JP7243620 B2 JP 7243620B2 JP 2019507591 A JP2019507591 A JP 2019507591A JP 2019507591 A JP2019507591 A JP 2019507591A JP 7243620 B2 JP7243620 B2 JP 7243620B2
Authority
JP
Japan
Prior art keywords
information
area
signaled
coverage
processing apparatus
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2019507591A
Other languages
English (en)
Other versions
JPWO2018173875A1 (ja
Inventor
遼平 高橋
俊也 浜田
充 勝股
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Sony Group Corp
Original Assignee
Sony Corp
Sony Group Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp, Sony Group Corp filed Critical Sony Corp
Publication of JPWO2018173875A1 publication Critical patent/JPWO2018173875A1/ja
Application granted granted Critical
Publication of JP7243620B2 publication Critical patent/JP7243620B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106—Processing image signals
    • H04N13/172—Processing image signals image signals comprising non-image signal components, e.g. headers or format information
    • H04N13/178—Metadata, e.g. disparity information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/816—Monomedia components thereof involving special video data, e.g 3D video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/194—Transmission of image signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Library & Information Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)
  • Image Generation (AREA)

Description

本開示は、情報処理装置およびプログラムに関し、特に、より多様なプロジェクションフォーマットで全天球映像の領域情報をシグナリングすることができるようにした情報処理装置およびプログラムに関する。
IPTV（Internet Protocol Television）等のインターネットストリーミングにおける標準化の流れとして、HTTP（Hypertext Transfer Protocol）ストリーミングによるVOD（Video On Demand）ストリーミングや、ライブストリーミングに適用される方式の標準化が行われている。
特に、ISO/IEC/MPEGで標準化が行われているMPEG-DASH（Moving Picture Experts Group Dynamic Adaptive Streaming over HTTP)が注目されている（例えば、非特許文献１参照）。
また、MPEGでは、VR標準化（MPEG-I: Coded Representation of Immersive media）が進行中している。例えば、全天球映像の視聴に一般的に使用されるHMD（Head Mounted Display）では、一度に表示される映像は360°全てではなく、一部の領域の映像のみとなる。そのため、VRで使用される全天球映像では、表示される一部の領域を表す領域情報をシグナリングする必要がある。また、MPEG-DASHにより全天球映像のネットワーク配信を行う場合、帯域幅に制限があるため、その有効活用を目的としたviewport dependent processingが検討中である。
ISO/IEC 23009-1:2012 Information technology Dynamic adaptive streaming over HTTP (DASH)
ところで、従来、OMAF CD（Omnidirectional Media Application Format Committee Draft）では、CoverageInformationBoxとして球面上領域カバレッジをシグナルしている。しかしながら、従来のOMAF CDでは対応することができないプロジェクションフォーマットがあり、より多様なプロジェクションフォーマットへの対応が求められていた。
本開示は、このような状況に鑑みてなされたものであり、より多様なプロジェクションフォーマットで全天球映像の領域情報をシグナリングすることができるようにするものである。
本開示の第１の側面の情報処理装置は、コンテンツのカバレッジ情報に基づいて、多面体の前記カバレッジ情報に対応する面ごとに各面の中心方向と水平方向および垂直方向の角度幅をシグナルし、前記シグナルを用いて球面上に形成される面領域を、前記カバレッジ情報に対応する面の数に応じてシグナルすることで球面上の領域を表現する領域情報を生成する生成部を備える。
本開示の第１の側面の情報処理方法またはプログラムは、コンテンツのカバレッジ情報に基づいて、多面体の前記カバレッジ情報に対応する面ごとに各面の中心方向と水平方向および垂直方向の角度幅をシグナルし、前記シグナルを用いて球面上に形成される面領域を、前記カバレッジ情報に対応する面の数に応じてシグナルすることで球面上の領域を表現する領域情報を生成するステップを含む。
本開示の第１の側面においては、コンテンツのカバレッジ情報に基づいて、多面体のカバレッジ情報に対応する面ごとに各面の中心方向と水平方向および垂直方向の角度幅をシグナルし、そのシグナルを用いて球面上に形成される面領域を、カバレッジ情報に対応する面の数に応じてシグナルすることで球面上の領域を表現する領域情報が生成される。
本開示の第２の側面の情報処理装置は、コンテンツのカバレッジ情報に基づいて、多面体の前記カバレッジ情報に対応する面ごとに各面の頂点をシグナルし、それらの頂点どうしを球面上の最短距離で結ぶことで形成される面領域を、前記カバレッジ情報に対応する面の数に応じてシグナルすることで球面上の領域を表現する領域情報を生成する生成部を備える。
本開示の第２の側面においては、コンテンツのカバレッジ情報に基づいて、多面体のカバレッジ情報に対応する面ごとに各面の頂点をシグナルし、それらの頂点どうしを球面上の最短距離で結ぶことで形成される面領域を、カバレッジ情報に対応する面の数に応じてシグナルすることで球面上の領域を表現する領域情報が生成される。
本開示の第１および第２の側面によれば、より多様なプロジェクションフォーマットで全天球映像の領域情報をシグナリングすることができる。
viewport dependent processingについて説明する図である。 viewport情報を取り扱う球座標系を示す図である。 MPEGで規定されている領域情報の一例を示す図である。 shape_typeによる二種類の球面上領域表現を示す図である。 コンテンツのカバレッジ情報であるcoviの格納場所を示す図である。 従来のシンタックスでは正確に表現できない例を説明する図である。 三角形面で構成されるプロジェクションフォーマットの例を示す図である。 第１の実施の形態による球面上領域のシグナルの第１の例を示す図である。 第１の実施の形態による球面上領域のシグナルの第２の例を示す図である。 立方体の２つの面をシグナルすることの応用例について説明する図である。 第１の実施の形態における拡張されたISOBMFFの一例を示す図である。 point_yaw/pitchによる表現だけでは、カバレッジが一意に決まらない例を説明する図である。 第１の実施の形態におけるパラメータの定義を示す図である。 立方体の３面をシグナルする例を示す図である。 立方体の３面をシグナルする場合のパラメータを示す図である。 八面体の２面をシグナルする例を示す図である。 八面体の２面をシグナルする場合のパラメータを示す図である。 第２の実施の形態による球面上領域のシグナルの一例を示す図である。 第２の実施の形態における拡張されたISOBMFFの一例を示す図である。 exclude_flagについて説明する図である。 第２の実施の形態におけるパラメータの定義を示す図である。 立方体の３面をシグナルする第１の例を示す図である。 立方体の３面をシグナルする第２の例を示す図である。 八面体の２面をシグナルする例を示す図である。 三角形領域表現に限定してシグナルする例を説明する図である。 図２５の例におけるRegionOnSphereStructの一例を示す図である。 図２５の例におけるパラメータの定義を示す図である。 第３の実施の形態における拡張されたISOBMFFでのtcovの第１の記述例を示す図である。 図２８の例におけるパラメータの定義を示す図である。 第３の実施の形態における拡張されたISOBMFFでのtcovの第２の記述例を示す図である。 図３０の例におけるパラメータの定義を示す図である。 第３の実施の形態における拡張されたISOBMFFでのtcovの第３の記述例を示す図である。 図３２の例におけるパラメータの定義を示す図である。 第３の実施の形態における拡張されたISOBMFFでのtcovの第４の記述例を示す図である。 図３４の例におけるパラメータの定義を示す図である。 第３の実施の形態において、main fraction trackにのみtcovを持つケースについて説明する図である。 第３の実施の形態において、すべてのfraction trackにtcovを持つケースについて説明する図である。 立方体の６面をシグナルする例を示す図である。 第４の実施の形態における拡張されたDASH MPDの第１の例を示す図である。 パラメータの定義を示す図である。 パラメータの定義を示す図である。 第１の実施の形態のシンタックスを使用する際の変形例を説明する図である。 パラメータの定義を示す図である。 第４の実施の形態における拡張されたDASH MPDの第２の例を示す図である。 パラメータの定義を示す図である。 パラメータの定義を示す図である。 第２の実施の形態のシンタックスを使用する際の変形例を説明する図である。 八面体の８面をシグナルする例を示す図である。 図４８のシグナルが記述されたMPDの記述例を示す図である。 第４の実施の形態の変形例を説明する図である。 本技術を適用した配信システムの構成例を示すブロック図である。 生成装置の構成例を示すブロック図である。 再生装置の構成例を示すブロック図である。 ファイル生成処理を説明するフローチャートである。 ファイル取得処理を説明するフローチャートである。 本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。
以下、本技術を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。
＜従来の全天球映像の領域情報＞
まず、図１乃至図７を参照して、従来の全天球映像の領域情報について説明する。
従来、複数の領域に分割された全天球映像について、クライアントの視点および視野に応じて適切な領域の映像を取得して表示するviewport dependent processingという技術が利用されている。また、viewport dependent processingでは、表示されない領域は取得する必要がない。
例えば、図１には、全天球映像が正距円筒図法により平面的に展開された状態が示されており、その全体が１８の領域に分割され、それぞれの領域が個別のビデオストリームとされている。そして、クライアントの視点および視野に応じた領域が二重線の矩形で示されており、その領域に応じてビデオストリームが取得される。図１の例では、３番、４番、９番、および１０番の領域のビデオストリームが取得され、クライアントの視点および視野に応じた領域の表示に使用される。
また、viewport dependent processingを実現するためには、全天球映像の各領域の位置情報およびサイズ情報をシグナルする必要がある。そして、クライアントは、それらの情報をもとに、viewportに応じたビデオ領域を取得して表示することができる。なお、全天球映像の各領域情報は、球面上の領域情報（球座標系）としてシグナルされる。
例えば、クライアントは、HMDであることが想定される。HMDの内部では、図２に示すような球座標系（yaw，pitch，roll)で、viewport情報が取り扱われるのが一般的であり、座標系を揃えることで処理の簡易化が可能となる。
図３には、MPEGで規定されている領域情報の一例が示されている。
このような領域情報において、例えば、CoverageInformationBoxは、trackに格納される全天球映像が表示される球面上領域の情報をシグナルする。そして、center_yawにより領域中心のyaw角が示され、center_pitchにより領域中心のpitch角が示され、hor_rangeにより水平方向の角度レンジが示され、ver_rangeにより垂直方向の角度レンジが示される。
さらに、図４に示すように、shape_typeにより二種類の球面上の領域表現を行うことができる。
例えば、図４の左側に示すshape_type=0は、four great circlesで囲まれる領域形状により球面上の領域表現を行う。また、図４の右側に示すshape_type=1は、two small two grate circlesで囲まれる領域形状により球面上の領域表現を行う。ここで、great circleは、球の中心と一致する中心を持つ断面の円を表しており、small circleは、それ以外の円を表している。なお、現時点におけるカバレッジ表現としては、shape_type=1のみが運用されている。
図５には、コンテンツのカバレッジ情報であるcoviの格納場所が示されている。
ところで、shape_type＝0は、キューブプロジェクションマッピング（Cube Projection Mapping；CMP）の面領域を１面ずつシグナルすることができ、正距円筒プロジェクション（Equirectangular projection；ERP）の矩形領域をシグナルすることができる。しかしながら、従来、キューブプロジェクションマッピングの２面以上の領域や、これら以外のプロジェクションフォーマットには対応することができていなかった。
例えば、図６の上側において、グレーのハッチングが施されている立方体の２面のカバレッジを表現する場合、現在のシンタックスでは正確に表現することができなかった。例えば、（center_yaw，center_pitch，hor_range，ver_range）＝（45，0，180，90）とシグナルすると、図６の下側において太線で囲われる半球領域となってしまう。そのため、立方体の２面でカバーできる球面上領域が狭くなる。つまり、図６の上側において太線で囲うように、球面の１／３の領域がカバーされるのに対し、図６の下側において太線で囲うように、球面の１／４の領域しかカバーされなくなってしまう。
さらに、従来、図７に示すような三角形面で構成されるプロジェクションフォーマット（OHP：オクタへドロンプロジェクション、ISP：イコサへドロンプロジェクション）の領域表現には対応していなかった。
そこで、従来技術で対応できない、CMPの2面以上の領域や、ERPまたはCMP以外で一般的に使用されており、将来OMAFに採用される可能性のあるプロジェクションフォーマット（OHPまたはISP）の領域表現に対応することが求められていた。さらに、OHPおよびISPのみでなく、多面体を用いるあらゆるプロジェクションフォーマットに対応することも求められていた。
＜ISOBMFFにおけるトラックの領域シグナル方法＞
図８乃至図１７を参照して、本技術の第１の実施の形態として、ISOBMFFにおけるトラックの領域シグナル方法の第１の例について説明する。
第１の実施の形態では、ISOBMFF trackに格納されるコンテンツのカバレッジについて、複数の頂点をyawおよびpitchでシグナルし、頂点どうしを球面上の最短距離で結ぶことで形成される領域で表現する。
例えば、図８には、３つの頂点をシグナルし、その３つの頂点どうしを球面上の最短距離で結ぶことで球面上の領域表現を行う第１の例が示されている。同様に、図９には、６つの頂点をシグナルし、その６つの頂点どうしを球面上の最短距離で結ぶことで球面上の領域表現を行う第２の例が示されている。
このとき、それぞれの頂点を結ぶ球面上の線分はgreat circleの一部となる。また、このようなシグナルにより、図７に示したようなOHPおよびISPだけでなく、その他の多面体に対応するプロジェクションフォーマットが可能となる。
また、図９に示したように、立方体の２つの面をシグナルすることができるため、例えば、クライアントの視点および視野に応じた領域が、立方体の２つの面に跨るような場合でも、効率良くストリーミングすることができる。
ここで、図１０を参照して、立方体の２つの面をシグナルすることの応用例について説明する。
例えば、キューブプロジェクションマッピングにおいて、立方体は、図示するような６つの面Ａ、面Ｂ、面Ｃ、面Ｄ、面Ｅ、および面Ｆにより構成される。
そして、それらの６つの面を２面ごとに３つに分割してファイル化する。即ち、面Ｂおよび面Ｃの２面からなるファイルと、面Ａおよび面Ｃの２面からなるファイルと、面Ｅおよび面Ｆの２面からなるファイルとにファイル化される。このとき、それぞれのファイルでは、上述の図９に示したように、それぞれ２つの面ごとに、coviによる球面上領域にシグナルされる。
ここで、例えば、クライアントの視点および視野に応じた領域が面Ｂおよび面Ｃに跨っている場合、即ち、図１０においてグレーでハッチングされている領域をユーザが見ようとした場合、coviの情報をもとに、面Ｂおよび面Ｃの２面からなるファイルが取得される。
即ち、従来、キューブプロジェクションマッピングの２面以上の領域をシグナルすることができないため、クライアントの視点および視野に応じた領域が面Ｂおよび面Ｃに跨っている場合には、効率良くストリーミングすることができなかった。これに対し、複数の面をシグナルすることができることにより、クライアントの視点および視野に応じた領域が複数の面に跨っていても、それらの面からなるファイルをストリーミングすることで、ストリーミングを効率良く行うことができるようになる。
ところで、複数の頂点をyawおよびpitchでシグナルし、頂点どうしを球面上の最短距離で結ぶことで領域表現を行う場合には、従来よりISOBMFFを拡張する必要がある。
図１１には、拡張されたISOBMFF（CoverageInformationBox）およびArbitraryRegionOnSphereStructの一例が示されている。
図１１に示すISOBMFFでは、shape_type=2が導入されている。例えば、shape_type=2では、各頂点は、i=0とi=1，i=1とi=2，・・・，i=n-1とi＝n，i=nとi=0の規則で、それぞれが球面上の最短距離で結ばれるように定義される。
また、図１１に示すISOBMFF において、covered_yaw，covered_pitchは、カバレッジに含まれる代表点のyaw，pitch（例えば、領域の中心点）を示すように定義される。即ち、covered_yaw/pitchは、point_yaw/pitchで表現される領域の内側の点をシグナルしなければならない。例えば、立方体の３面をカバレッジする場合、point_yaw/pitchによる表現だけでは、カバレッジが一意に決まらないため、covered_yaw/pitchによるシグナルが必要となる。
図１２を参照して、point_yaw/pitchによる表現だけでは、カバレッジが一意に決まらない例について説明する。
図１２に示すように、立方体を３面ごとに分割する場合、手前側の３面からなる形状と奥側の３面からなる形状とに分割される。この場合、それぞれの形状カバレッジをシグナルすると、シグナルされる点は同一になる。従って、これらの２つの形状を区別するためには、covered_yaw/pitchにより方向（手前側の３面、または、奥側の３面）をシグナルする必要ある。
図１３には、このような拡張されたISOBMFFにおけるトラックの領域シグナル方法において使用されるパラメータの定義が示されている。
次に、第１の実施の形態による実際のシグナル例について説明する。
例えば、図１４の下側に示すような座標系に従って、図１４の上側に示すような立方体の手前側の３面をシグナルする場合、図１５に示すようにパラメータが設定される。また、この座標系において、yaw角は、－180°以上、かつ、180°より小さく、pitch角は、－90°以上、かつ、90°以下であり、roll角は、－180°以上、かつ、180°以下とされる。
同様に、図１６に示すような八面体の手前側の２面をシグナルする場合、図１７に示すようにパラメータが設定される。
このように、第１の実施の形態では、拡張されたISOBMFFを用いて、球面上の点をyawおよびpitchでシグナルすることより、実装上扱いやすいというメリットがある。例えば、クライアント側は、自身のviewport情報を方向とfield of view（FoV）とで持つため、そのviewport範囲内に、シグナルされた点で囲まれた領域が含まれるか否かを判別するのは容易である。ところで、第１の実施の形態では、非連続領域のシグナルには対応していない。
なお、第１の実施の形態の変形例として、例えば、shape_typeに替えてflagsを用いてもよい。また、ArbitraryRegionOnSphereStructの中身を、RegionOnSphereStructの中でシグナルし、それらをshape_typeで切り替えてもよい。
＜ISOBMFFにおけるトラックの領域シグナル方法＞
図１８乃至図２７を参照して、本技術の第２の実施の形態として、ISOBMFFにおけるトラックの領域シグナル方法の第２の例について説明する。
第２の実施の形態では、ＩＳＯＢＭＦＦ ｔｒａｃｋに格納されるコンテンツのカバレッジについて、多面体ごとにその多面体の頂点をｙａｗおよびｐｉｔｃｈでシグナルし、頂点どうしを球面上の最短距離で結ぶことで形成される面領域を面の数だけ複数シグナルして表現する。
例えば、図１８には、２つの面ごとに、それらの面の頂点をシグナルし、頂点どうしを球面上の最短距離で結ぶことで形成される面領域となる２つの面をシグナルすることで領域表現を行う例が示されている。
このとき、それぞれの頂点を結ぶ球面上の線分はgreat circleの一部となる。また、このようなシグナルにより、図７に示したようなOHPおよびISPだけでなく、その他の多面体に対応するプロジェクションフォーマットが可能となる。
図１９には、拡張されたISOBMFF（CoverageInformationBox）およびArbitraryRegionOnSphereStructの一例が示されている。
図１９に示すＩＳＯＢＭＦＦでは、ｓｈａｐｅ＿ｔｙｐｅ＝２が導入されている。例えば、ｓｈａｐｅ＿ｔｙｐｅ＝２では、各頂点は、ｉ＝０とｉ＝１，ｉ＝１とｉ＝２，・・・，ｉ＝ｎ－１とｉ＝ｎ，ｉ＝ｎとｉ＝０の規則で、それぞれが球面上の最短距離で結ばれるように定義される。そして、ＩＳＯＢＭＦＦに示すように、面の数でｆｏｒ ｌｏｏｐを回すことにより、複数の面からなる領域をシグナルすることができる。
また、図１９に示すＩＳＯＢＭＦＦでは、ｅｘｃｌｕｄｅ＿ｆｌａｇが導入されている。ｅｘｃｌｕｄｅ＿ｆｌａｇが１の場合、シグナルされた領域以外がｃｏｖｅｒａｇｅとなる
図２０を参照して、exclude_flagについて説明する。図２０では、立方体の５面分(グレーのハッチングが施されている面以外)のカバレッジシグナルの例が示されている。
例えば、図２０の上側に示すように、exclude_flag＝0の場合には、カバレッジとして５面分の面に応じた２０点のシグナルが必要になる。これに対して、図２０の下側に示すように、exclude_flag=1の場合には、カバレッジから除く１面分の面に応じた４点のシグナルでよい。このように、exclude_flagを使用することで、カバレッジシグナルに必要なビット数の最適化を図ること、即ち、より少ないビット数でカバレッジすることができる。
図２１には、このような拡張されたISOBMFFにおけるトラックの領域シグナル方法において使用されるパラメータの定義が示されている。
次に、第２の実施の形態による実際のシグナル例について説明する。
例えば、図２２には、shape_type=0の場合、即ち、上述の図４の左側に示したような方法で、立方体の３面をシグナルする例が示されている。この場合、図２２の下側に示すようにパラメータが設定される。
図２３には、shape_type=２の場合、即ち、第２の実施の形態で説明した方法で、立方体の３面をシグナルする例が示されている。この場合、図２３の下側に示すようにパラメータが設定される。
図２４には、shape_type=２の場合、即ち、第２の実施の形態で説明した方法で、八面体の手前側の２面をシグナルする例が示されている。この場合、図２４の下側に示すようにパラメータが設定される。
このように、第２の実施の形態では、拡張されたISOBMFFを用いて、球面上の点をyawおよびpitchでシグナルすることより、実装上扱いやすいというメリットがある。例えば、クライアント側は、自身のviewport情報を方向とfield of view（FoV）とで持つため、そのviewport範囲内に、シグナルされた点で囲まれた領域が含まれるか否かを判別するのは容易である。
さらに、第２の実施の形態では、領域を面単位で複数シグナルできるので、非連続領域のシグナルが可能である。また、上述したようにexclude_flagを利用することで、シグナルする頂点数を最適化することができる。ところで、第２の実施の形態では、上述した第１の実施の形態と比較して、頂点情報に重複が生じることがあり、Boxのサイズが増加することがある。
なお、第２の実施の形態の変形例として、shape_typeに替えてflagsを用いてもよい。例えば、ArbitraryRegionOnSphereStrcutの中身を、RegionOnSphereStructの中でシグナルし、shape_typeで切り替えてもよい。また、領域ごとにshape_typeが変わってもよい。
さらに、num_pointsを３に限定することで、shape_type=2を三角形領域の表現のみに用いるようにしてもよい。例えば、第２の実施の形態を、三角形領域の表現に限定した場合、球面上の三角形領域は、図２５に示すように表現することもできる。このとき、classTriangleRegionOnSphereStructは、図２６に示す通りであり、パラメータは、図２７に示すように定義される。
＜ISOBMFFにおけるファイル単位の領域シグナル方法＞
図２８乃至図３８を参照して、本技術の第３の実施の形態として、ISOBMFFにおけるファイル単位の領域シグナル方法について説明する。
第３の実施の形態では、ISOBMFFファイルが格納するコンテンツのトータルカバレッジについて、上述した第１および第２の実施の形態のシグナル方法を用いて表現する。即ち、領域のシグナルは、上述した第１および第２の実施の形態と同様のシンタックス・セマンティクスを用いる。
例えば、従来技術ではtrack単位のカバレッジ情報のみ規定しており、ISOBMFFファイルが複数trackから構成される場合における、全trackをまとめたカバレッジ (=ファイル単位のトータルカバレッジ)はシグナルできなかった。
これに対し、第３の実施の形態では、複数trackから構成されるISOBMFFについて、ファイル単位でのviewport dependent processingが可能となる。
また、第３の実施の形態において、ファイル単位でのトータルカバレッジ情報をシグナルすることで、クライアントはそのファイル再生時に表示可能な領域を容易に取得できる。例えば、全天球すべてをカバーしていない場合に、あらかじめ映像表示できない部分をクライアント独自の映像、もしくはISOBMFFで指定されたデータで埋めておくことができる。
例えば、第３の実施の形態では、tcov（Total Coverage Information Box）は、povd（ProjectedOmnidirectionalVideoBox）の下に配置される。
ここで、以下の説明において、main fraction trackにのみtcovを持つ方式をケース１とする。そして、ケース１において、tcovが、total coverage情報のみ持つ方式をケース１－１とし、tcovが、total coverage情報に加え、全てのfraction track（main含む）のcoverage情報を持つ方式をケース１－２とする。
また、すべてのfraction trackにtcovを持つ方式をケース２とする。そして、ケース２において、tcovが、total coverage情報のみ持つ方式をケース２－１とし、tcovが、total coverage情報に加え、全てのfraction track（main含む）のcoverage情報を持つ方式をケース２－２とする。
このように、それぞれのケースに基づいて、tcovのシンタックスのバリエーションは4種類となる。
例えば、tcovのシンタックスの第１のバリエーションでは、tcovでシグナルされる情報は、total coverage情報のみ持ち、領域シグナル方法は、上述した第１の実施の形態と同一の方法とされる。
従って、tcovのシンタックスの第１のバリエーションでは、図２８に示すようにISOBMFF（CoverageInformationBox）は記述され、ArbitraryRegionOnSphereStructは、上述の図１１（第１の実施の形態）と同一とされる。また、パラメータは図２９に示すように定義される。なお、上述した第１の実施の形態の変形例も含むことができる。
また、tcovのシンタックスの第２のバリエーションでは、tcovでシグナルされる情報は、total coverage情報のみ持ち、領域シグナル方法は、上述した第２の実施の形態と同一の方法とされる。
従って、tcovのシンタックスの第２のバリエーションでは、図３０に示すようにISOBMFF（CoverageInformationBox）は記述され、ArbitraryRegionOnSphereStructは、上述の図１９（第２の実施の形態）と同一とされる。また、パラメータは図３１に示すように定義される。なお、上述した第２の実施の形態の変形例も含むことができる。
また、tcovのシンタックスの第３のバリエーションでは、tcovでシグナルされる情報は、total coverage情報に加え、全てのfraction track（main含む）のcoverage情報を持ち、領域シグナル方法は、上述した第１の実施の形態と同一の方法とされる。
従って、tcovのシンタックスの第３のバリエーションでは、図３２に示すようにISOBMFF（CoverageInformationBox）は記述され、ArbitraryRegionOnSphereStructは、上述の図１１（第１の実施の形態）と同一とされる。また、パラメータは図３３に示すように定義される。なお、上述した第１の実施の形態の変形例も含むことができる。
なお、tcovのシンタックスの第３のバリエーションの変形例として、num_track_partitionは、TotalCoverageInformationBoxを持つ自trackを除いた数を設定し、tp_idで自trackのtrack_idをシグナルしなくてもよい。
また、tcovのシンタックスの第４のバリエーションでは、tcovでシグナルされる情報は、total coverage情報に加え、全てのfraction track（main含む）のcoverage情報を持ち、領域シグナル方法は、上述した第２の実施の形態と同一の方法とされる。
従って、tcovのシンタックスの第４のバリエーションでは、図３４に示すようにISOBMFF（CoverageInformationBox）は記述され、ArbitraryRegionOnSphereStructは、上述の図１９（第２の実施の形態）と同一とされる。また、パラメータは図３５に示すように定義される。なお、上述した第２の実施の形態の変形例も含むことができる。
なお、tcovのシンタックスの第４のバリエーションの変形例として、num_track_partitionは、TotalCoverageInformationBoxを持つ自trackを除いた数を設定し、tp_idで自trackのtrack_idをシグナルしなくてもよい。
図３６を参照して、第３の実施の形態において、main fraction trackにのみtcovを持つケース１について説明する。
例えば、ケース１では、tcovを持つのがmain fraction trackとし、tcovを持たないのがfraction trackとする。そして、main fraction trackはTrack Reference(‘ofrc’)でfraction trackを参照することができ、fraction trackはTrack Reference(‘omfr’)でmain fraction trackを参照することができる。また、main fraction trackにのみTotalCoverageInformationBoxを持つ。
ここで、例えば、tcovがtotal coverage情報のみ持つケース１－１の場合、カバレッジに関して重複する情報がない、シンプルな表現が可能となる。但し、total coverageを取得するために、main fraction trackを参照する必要があり、他のfraction trackのcoverageは、各fraction trackを参照しないと取得できない。
また、例えば、tcovがtotal coverage情報に加え、全てのfraction track（main含む）のcoverage情報を持つケース１－２の場合、fraction trackのcoverageをmain fraction track内で取得できる。但し、total coverageを取得するために、main fraction trackを参照する必要がある。なお、ケース１の変形例として、prfrをmain fraction trackのみに持つようにしてもよい。また、ケース１－２の場合、tref (‘ofrc’)はなくてもよい。
図３７を参照して、第３の実施の形態において、すべてのfraction trackにtcovを持つケース２について説明する。
例えば、ケース２では、main fraction track, fraction trackの区別はない。また、各fraction trackが相互にtrack reference‘omfr’で参照することができる。
ここで、例えば、tcovがtotal coverage情報のみ持つケース２－１の場合、いずれのfraction trackもtotal coverageを有するため、total coverage情報を取得するのが容易である。但し、重複情報を持つためファイルサイズはケース１－１と比較して大きくなり、他のfraction trackのcoverageは、各fraction trackを参照しないと取得できない。
また、例えば、tcovがtotal coverage情報に加え、fraction track（main含む）のcoverage情報を持つケース２－２の場合、total coverage, 各fraction trackのcoverageを一つのfraction track内で取得できる。但し、重複情報を持つためファイルサイズは、ケース１－１、ケース１－２、およびケース２－１のいずれと比較しても大きくなる。なお、ケース２－２の場合、tref (‘omfr’)はなくてもよい。
次に、第３の実施の形態による実際のシグナル例について説明する。
図３８では、ケース２－２で、tcovのシンタックスの第４のバリエーションを用い、各面をregionとして一つずつtrackに格納する。例えば、Region[0]はtrack_id:1とし、Region[1]はtrack_id:2とし、以下同様に、Region[5]はtrack_id:6とする。また、tcovのシグナルは、図３８の下側に示すように記述される。
なお、第３の実施の形態の変形例として、total_full_sphereの代わりに、flagsを用いてもよい。
＜DASH MPDにおける領域シグナル方法＞
図３９乃至図５０を参照して、本技術の第４の実施の形態として、DASH MPDにおける領域シグナル方法について説明する。
例えば、DASH MPDにおいて、各Representationがカバーする領域をシグナルすることができる。
シグナル方法としては、EssentialPropertyまたはSupplementalPropertyを用いることができ、EssentialPropertyはAdaptationSetの下に格納され、SupplementalPropertyはRepresentationの下に格納される。
例えば、SupplementalPropertyは、このPropertyを理解できないPlayerは、このProperty値を無視して、そのAdaptationSet（もしくはRepresentation, Sub-Representation）を利用してもよい。また、EssentialPropertyは、このPropertyを理解できないPlayerは、このPropertyの書かれているAdaptationSet（もしくはRepresentation, Sub-Representation）を無視しなければならない。
図３９には、拡張されたDASH MPDの第１の例が示されており、ここでは、上述した第１の実施の形態のシンタックスが使用されている。
このようなシンタックスにおいて、coverage:arbitrary, totalcoverage:arbitraryの場合、０～２はmandatoryとなり、３以降はnum_pointsに応じる。また、coverageがシグナルされない場合、カバレッジは360degreeフルを示す。一方、coverageのspatial_set_idがシグナルされる場合で、トータルカバレッジが360degreeフルでなければ、同じspatial_set_idを持つtotal coverageが必須となる。また、CoverageとTotalCoverageを一つのEssentialPropertyまたはSupplementalPropertyにまとめてもよい。
図４０および図４１には、図３９に示すような拡張されたDASH MPDにおいて使用されるパラメータの定義が示されている。
なお、上述した第１の実施の形態のシンタックスを使用する際の変形例として、Coverage, TotalCoverageのshape_type=2の場合について、点の数だけ図４２に示すEssentialProperty(coverage:arbitrary, totalcoverage:arbitrary)をシグナルする。このとき、点を結ぶ順番は、EssentialPropertyまたはSupplementalPropertyの記載の順番でもよいし、EssentialPropertyまたはSupplementalProperty内に順番を示すパラメータを持ってもよい。
また、図４３には、図４２に示すシンタックスで使用されるパラメータの定義が記載されている。
図４４には、拡張されたDASH MPDの第２の例が示されており、ここでは、上述した第２の実施の形態のシンタックスが使用されている。
このようなシンタックスにおいて、coverage:arbitrary, totalcoverage:arbitraryの場合、kは2以上であり、２からnum_points-1までとされ、lは、0からnum_regions-1までとされる。
また、coverageがシグナルされない場合、カバレッジは360degreeフルを示す。一方、coverageのspatial_set_idがシグナルされる場合で、トータルカバレッジが360degreeフルでなければ、同じspatial_set_idを持つtotal coverageが必須となる。また、CoverageとTotalCoverageを一つのEssentialPropertyまたはSupplementalPropertyにまとめてもよい。
図４５および図４６には、図４４に示すような拡張されたDASH MPDにおいて使用されるパラメータの定義が示されている。
なお、上述した第２の実施の形態のシンタックスを使用する際の変形例として、領域の数だけ、図４７に示すEssentialPropertyまたはSupplementalPropertyをシグナルする。そして、シグナルされた領域の合計がCoverageまたはTotal Coverageとなる。
次に、第４の実施の形態による実際のシグナル例について説明する。
図４８では、上述したように拡張されたDASH MPDにおいて、第２の実施の形態のシンタックスを使用する例が示されている。つまり、図４８の上側に示すように、八面体の８つの面が一つずつregionに分割されている。また、図４８の下側には、各regionのpointのシグナルが示されており、図４９には、そのシグナルが記述されたMPDの記述例が示されている。
なお、第４の実施の形態の変形例として、shape_type=2の場合のcoverage, total coverageについても、shape_type=0, 1と同じsyntaxを用いて表現してもよい。また、パラメータは、図４６に示したパラメータが用いられる。
このとき、center_pitch, center_yaw, hor_range, ver_rangeでシグナルされる領域は、実際のコンテンツのカバレッジと一致しなくてよい。ただし、実際のコンテンツカバレッジに包含され、かつ最大の領域がシグナルされる。例えば、図５０に示すように、略三角形の実際のコンテンツカバレッジに包含され、かつ最大の領域となる略矩形の領域がシグナルされる。
＜システムの構成例および処理例＞
図５１乃至図５５を参照して、上述したように球面上の領域をシグナルして全天球画像を配信するシステムについて説明する。
図５１は、本技術を適用した配信システムの構成例を示すブロック図である。
図５１の配信システム１１は、撮影装置１２、生成装置１３、配信サーバ１４、再生装置１５、およびヘッドマウントディスプレイ１６により構成される。配信システム１１は、撮影装置１２により撮影された撮影画像から全天球画像を生成し、全天球画像を用いて視聴者の視野範囲の表示画像を表示する。
具体的には、配信システム１１の撮影装置１２は、６個のカメラ１２Ａ－１乃至１２Ａ－６およびマイクロフォン１２Ｂにより構成される。なお、以下では、カメラ１２Ａ－１乃至１２Ａ－６を特に区別する必要がない場合、それらをまとめてカメラ１２Ａという。
各カメラ１２Ａは動画像を撮影し、マイクロフォン１２Ｂは周囲の音声を取得する。配信システム１１は、各カメラ１２Ａにより撮影された６方向の動画像である撮影画像とマイクロフォン１２Ｂにより取得された音声を、動画コンテンツとして生成装置１３に供給する。なお、撮影装置１２が備えるカメラの数は、複数であれば、６個以外であってもよい。
生成装置１３は、正距円筒図法を用いた方法により、撮影装置１２から供給される撮影画像から全天球画像を生成し、１以上のビットレートで符号化して、各ビットレートの正距円筒ストリームを生成する。また、生成装置１３は、キューブマッピングにより、撮影画像から全天球画像を生成し、１以上のビットレートで符号化して、各ビットレートのキューブストリームを生成する。また、生成装置１３は、撮影装置１２から供給される音声を符号化し、オーディオストリームを生成する。
生成装置１３は、各ビットレートの正距円筒ストリーム、各ビットレートのキューブストリーム、およびオーディオストリームを、ISOBMFFファイル化する。生成装置１３は、その結果生成されたISOBMFFファイルを配信サーバ１４にアップロードする。
なお、ここでは、正距円筒ストリームとキューブストリームのビットレートが１以上であるようにするが、ビットレート以外の条件（例えば、画像のサイズ等）が１以上であるようにしてもよい。
また、生成装置１３は、動画コンテンツのセグメントファイルを管理するMPDファイルを生成し、配信サーバ１４にアップロードする。セグメントとは、ビデオストリーム、オーディオストリームを数秒から１０秒程度の時間単位でファイル化したものである。例えば、RegionMappingBoxを含むISOBMFFがセグメントファイルとして配信される。
例えばMEPG-DASH (ISO/IEC 23009-1)を用いた配信を行う配信サーバ１４は、生成装置１３からアップロードされたセグメントファイルとMPDファイルを格納する。配信サーバ１４は、クライアントとしての再生装置１５からの要求に応じて、格納しているセグメントファイルを再生装置１５に送信する。
再生装置１５は、配信サーバ１４にISOBMFF ファイルを要求し、その要求に応じて送信されてくるISOBMFFファイルを受け取る。また、再生装置１５は、ISOBMFFファイルに基づいて、再生装置１５で行うことが可能なマッピングに対応する全天球画像の生成方法で生成された全天球画像のセグメントファイルを要求し、その要求に応じて送信されてくるセグメントファイルを受け取る。再生装置１５は、受け取ったセグメントファイルに含まれるキューブストリーム(または正距円筒ストリームであってもよい)を復号する。再生装置１５は、復号の結果得られる全天球画像を３Ｄモデルにマッピングすることにより、３Ｄモデル画像を生成する。
また、再生装置１５は、カメラ１５Ａを内蔵し、ヘッドマウントディスプレイ１６に付されたマーカ１６Ａを撮影する。そして、再生装置１５は、マーカ１６Ａの撮影画像に基づいて、３Ｄモデルの座標系における視聴位置を検出する。さらに、再生装置１５は、ヘッドマウントディスプレイ１６のジャイロセンサ１６Ｂの検出結果を、ヘッドマウントディスプレイ１６から受け取る。再生装置１５は、ジャイロセンサ１６Ｂの検出結果に基づいて、３Ｄモデルの座標系における視聴者の視線方向を決定する。再生装置１５は、視聴位置と視線方向に基づいて、３Ｄモデルの内部に位置する視聴者の視野範囲を決定する。
再生装置１５は、視聴位置を焦点として、３Ｄモデル画像を視聴者の視野範囲に透視投影することにより、視聴者の視野範囲の画像を表示画像として生成する。再生装置１５は、表示画像をヘッドマウントディスプレイ１６に供給する。
ヘッドマウントディスプレイ１６は、視聴者の頭部に装着され、再生装置１５から供給される表示画像を表示する。ヘッドマウントディスプレイ１６には、カメラ１５Ａにより撮影されるマーカ１６Ａが付されている。従って、視聴者は、ヘッドマウントディスプレイ１６を頭部に装着した状態で、移動することにより視聴位置を指定することができる。また、ヘッドマウントディスプレイ１６には、ジャイロセンサ１６Ｂが内蔵され、そのジャイロセンサ１６Ｂによる角速度の検出結果は再生装置１５に伝送される。従って、視聴者は、ヘッドマウントディスプレイ１６を装着した頭部を回転させることにより、視線方向を指定することができる。
図５２は、生成装置の構成例を示すブロック図である。
図５２の生成装置１３は、スティッチング処理部２１、マッピング処理部２２、region-wise packing処理部２３、エンコーダ２４、音声処理部２５、エンコーダ２６、ファイル生成部２７、およびアップロード部２８により構成される。
スティッチング処理部２１は、フレームごとに、図５１のカメラ１２Ａから供給される６方向の撮影画像の色や明るさを同一にし、重なりを除去して接続するスティッチング処理を行う。スティッチング処理部２１は、スティッチング処理後のフレーム単位の撮影画像をマッピング処理部２２に供給する。
マッピング処理部２２は、この例ではキューブマッピングにより、スティッチング処理部２１から供給される撮影画像から全天球画像を生成する。具体的には、マッピング処理部２２は、スティッチング処理後の撮影画像をテクスチャとして立方体にマッピングし、その立方体の展開図の画像を全天球画像として生成する。マッピング処理部２２は、全天球画像をregion-wise packing処理部２３に供給する。なお、スティッチング処理部２１とマッピング処理部２２は、一体化されていてもよい。
region-wise packing処理部２３はregion-wise packing処理を行う。すなわち、projected frameを領域ごとに位置とサイズを変更して２次元面上に配置してパッキング（packing）し、packed frameを生成する。region-wise packing処理部２３はまた、margin_flag, region_margin_typeを含むRegionMappingBoxを生成する。
エンコーダ２４は、region-wise packing処理部２３から供給される全天球画像を１以上のビットレートで符号化し、キューブストリームを生成する。エンコーダ２４は、各ビットレートのキューブストリームをファイル生成部２７に供給する。
音声処理部２５は、図５１のマイクロフォン１２Ｂから供給される音声を取得し、エンコーダ２６に供給する。エンコーダ２６は、音声処理部２５から供給される音声を符号化し、オーディオストリームを生成する。エンコーダ２６は、オーディオストリームをファイル生成部２７に供給する。
ファイル生成部２７は、各ビットレートのキューブストリーム、およびオーディオストリームを、セグメント単位でファイル化する。ファイル生成部２７は、その結果生成されたセグメントファイルをアップロード部２８に供給する。ファイル生成部２７はまた、ISOBMFFファイルを生成し、アップロード部２８に供給する。
このとき、ファイル生成部２７は、上述したように拡張されたISOBMFFを生成することができ、そのISOBMFFには、領域情報がシグナルされている。即ち、ファイル生成部２７は、球面上の複数の頂点をシグナルし、それらの頂点どうしを球面上の最短距離で結ぶことで球面上の領域を表現する領域情報（第１の実施の形態）を生成してISOBMFFに記述する。また、ファイル生成部２７は、球面上の面ごとに各面の頂点をシグナルし、それらの頂点どうしを球面上の最短距離で結ぶことで形成される面領域を、面の数に応じてシグナルすることで球面上の領域を表現する領域情報（第２の実施の形態）を生成してISOBMFFに記述する。または、ファイル生成部２７は、MPDを生成する際に、同様に、拡張されたMPDに領域情報がシグナル（第４の実施の形態）されるようにしてもよい。
アップロード部２８は、ファイル生成部２７から供給されるセグメントファイルとISOBMFFファイルとを、図５１の配信サーバ１４にアップロードする。
次に、画像を処理する場合を例として、再生装置１５の構成例について説明する。
図５３は、再生装置の構成例を示すブロック図である。
図５３の再生装置１５は、ファイル取得部３１、ストリーム抽出部３２、デコーダ３３、projected frame生成部３４，マッピング処理部３５、描画部３６、受け取り部３７、視線検出部３８、およびカメラ１５Ａを有している。
ファイル取得部３１は、図５１の配信サーバ１４から再生対象のファイルを取得する。ストリーム抽出部３２は、ファイル取得部３１により取得されたファイルから、ビデオストリームを抽出する。デコーダ３３は、ストリーム抽出部３２により抽出されたビデオストリームをデコードする。projected frame生成部３４は、デコーダ３３によりデコードされた画像データからprojected frameを生成する。
マッピング処理部３５は、projected frame生成部３４から供給される全天球画像を立方体の６面のそれぞれにテクスチャとしてマッピングする。
描画部３６は、マッピング処理部３５から供給される３Ｄモデル画像を、視線検出部３８から供給される視聴位置を焦点として、視聴者の視野範囲に透視投影することにより、視聴者の視野範囲の画像を表示画像として生成する。描画部３６は、表示画像をヘッドマウントディスプレイ１６に供給する。
受け取り部３７は、図５１のジャイロセンサ１６Ｂの検出結果を、ヘッドマウントディスプレイ１６から受け取り、視線検出部３８に供給する。
視線検出部３８は、受け取り部３７から供給されるジャイロセンサ１６Ｂの検出結果に基づいて、３Ｄモデルの座標系における視聴者の視線方向を決定する。また、視線検出部３８は、カメラ１５Ａからマーカ１６Ａの撮影画像を取得し、その撮影画像に基づいて、３Ｄモデルの座標系における視聴位置を検出する。視線検出部３８は、３Ｄモデルの座標系における視聴位置と視線方向に基づいて、３Ｄモデルの座標系における視聴者の視野範囲を決定する。視線検出部３８は、視聴者の視野範囲と視聴位置を描画部３６に供給する。
図５４のフローチャートを参照して、図５２のファイル生成部２７が実行するファイル生成処理について説明する。
ステップＳ１１において、ファイル生成部２７は、全天球ビデオは複数に分割されているか否かを判定する。
ステップＳ１１において、全天球ビデオは複数に分割されていると判定された場合、処理はステップＳ１２に進み、ファイル生成部２７は、全ての全天球ビデオの領域情報をもとに、tcovおよびEssentialProperty (totalcoverage) 情報を決定する。
ステップＳ１３において、ファイル生成部２７は、個々の全天球ビデオの領域情報をもとに、それぞれのcoviおよびEssentialProperty(coverage)を決定する。
一方、ステップＳ１１において、全天球ビデオは複数に分割されていないと判定された場合、処理はステップＳ１４に進み、ファイル生成部２７は、全天球ビデオの領域情報をもとに、coviとEssentialProperty(coverage)情報を決定する。
ステップＳ１３またはＳ１４の処理後、処理はステップＳ１５に進み、ファイル生成部２７は、MPDとISOBMFFを生成した後、処理は終了される。
図５５のフローチャートを参照して、図５３のファイル取得部３１が実行するファイル取得処理について説明する。
ステップＳ２１において、ファイル取得部３１は、MPDのAdaptationSetのEssentialProperty（totalcoverage）を参照し、所望のtotal coverageとなるspatial_set_idを取得する。
ステップＳ２２において、ファイル取得部３１は、MPDのAdaptationSetのEssentialProperty（coverage）を参照し、ステップＳ２１で取得したspatial_set_idを持ち、かつ視聴方向に適合するAdaptationSetを選択する。
ステップＳ２３において、ファイル取得部３１は、選択したAdaptationSetの中で、帯域幅に応じてRepresentationを選択して、参照されているファイルを取得して、処理は終了される。
以上のように、ファイル生成部２７は、MPDおよびISOBMFFを生成することができ、ファイル取得部３１は、生成対象のファイルを取得することができる。
なお、上述のフローチャートを参照して説明した各処理は、必ずしもフローチャートとして記載された順序に沿って時系列に処理する必要はなく、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含むものである。また、プログラムは、１のCPUにより処理されるものであっても良いし、複数のCPUによって分散処理されるものであっても良い。
また、上述した一連の処理（情報処理方法）は、ハードウエアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、プログラムが記録されたプログラム記録媒体からインストールされる。
図５６は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。
コンピュータにおいて、CPU（Central Processing Unit）１０１，ROM（Read Only Memory）１０２，RAM（Random Access Memory）１０３は、バス１０４により相互に接続されている。
バス１０４には、さらに、入出力インタフェース１０５が接続されている。入出力インタフェース１０５には、キーボード、マウス、マイクロフォンなどよりなる入力部１０６、ディスプレイ、スピーカなどよりなる出力部１０７、ハードディスクや不揮発性のメモリなどよりなる記憶部１０８、ネットワークインタフェースなどよりなる通信部１０９、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１を駆動するドライブ１１０が接続されている。
以上のように構成されるコンピュータでは、CPU１０１が、例えば、記憶部１０８に記憶されているプログラムを、入出力インタフェース１０５及びバス１０４を介して、RAM１０３にロードして実行することにより、上述した一連の処理が行われる。
コンピュータ（CPU１０１）が実行するプログラムは、例えば、磁気ディスク（フレキシブルディスクを含む）、光ディスク（CD-ROM(Compact Disc-Read Only Memory),DVD(Digital Versatile Disc)等）、光磁気ディスク、もしくは半導体メモリなどよりなるパッケージメディアであるリムーバブルメディア１１１に記録して、あるいは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供される。
そして、プログラムは、リムーバブルメディア１１１をドライブ１１０に装着することにより、入出力インタフェース１０５を介して、記憶部１０８にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部１０９で受信し、記憶部１０８にインストールすることができる。その他、プログラムは、ROM１０２や記憶部１０８に、あらかじめインストールしておくことができる。
＜構成の組み合わせ例＞
なお、本技術は以下のような構成も取ることができる。
（１）
球面上の複数の頂点をシグナルし、それらの頂点どうしを球面上の最短距離で結ぶことで球面上の領域を表現する領域情報を生成する生成部
を備える情報処理装置。
（２）
前記領域情報には、複数の前記頂点を結ぶ規則が導入される
上記（１）に記載の情報処理装置。
（３）
前記領域情報には、複数の頂点でカバーされる領域に含まれる代表点がシグナルされる
上記（１）または（２）に記載の情報処理装置。
（４）
前記領域情報は、拡張されたISOBMFFによりシグナルされる
上記（１）から（３）までのいずれかに記載の情報処理装置。
（５）
前記領域情報は、tcovによりシグナルされる
上記（１）から（３）までのいずれかに記載の情報処理装置。
（６）
前記領域情報は、拡張されたDASH MPDによりシグナルされる
上記（１）から（３）までのいずれかに記載の情報処理装置。
（７）
球面上の複数の頂点をシグナルし、それらの頂点どうしを球面上の最短距離で結ぶことで球面上の領域を表現する領域情報を生成する
ステップを含む情報処理方法。
（８）
球面上の複数の頂点をシグナルし、それらの頂点どうしを球面上の最短距離で結ぶことで球面上の領域を表現する領域情報を生成する
ステップを含む情報処理をコンピュータに実行させるプログラム。
（９）
球面上の面ごとに各面の頂点をシグナルし、それらの頂点どうしを球面上の最短距離で結ぶことで形成される面領域を、面の数に応じてシグナルすることで球面上の領域を表現する領域情報を生成する生成部
を備える情報処理装置。
（１０）
前記領域情報には、複数の前記頂点を結ぶ規則が導入され、前記面の数に従ってループを回すことで前記面領域がシグナルされる
上記（９）に記載の情報処理装置。
（１１）
前記領域情報には、シグナルされた領域をカバーするか、シグナルされた領域以外をカバーするかを示すフラグが含まれる
上記（９）または（１０）に記載の情報処理装置。
（１２）
前記領域情報は、拡張されたISOBMFFによりシグナルされる
上記（９）から（１１）までのいずれかに記載の情報処理装置。
（１３）
前記領域情報は、tcovによりシグナルされる
上記（９）から（１１）までのいずれかに記載の情報処理装置。
（１４）
前記領域情報は、拡張されたDASH MPDによりシグナルされる
上記（９）から（１１）までのいずれかに記載の情報処理装置。
（１５）
球面上の面ごとに各面の頂点をシグナルし、それらの頂点どうしを球面上の最短距離で結ぶことで形成される面領域を、面の数に応じてシグナルすることで球面上の領域を表現する領域情報を生成する
ステップを含む情報処理方法。
（１６）
球面上の面ごとに各面の頂点をシグナルし、それらの頂点どうしを球面上の最短距離で結ぶことで形成される面領域を、面の数に応じてシグナルすることで球面上の領域を表現する領域情報を生成する
ステップを含む情報処理をコンピュータに実行させるプログラム。
なお、本実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。
１１ 配信システム， １２ 撮影装置， １２Ａ カメラ， １２Ｂ マイクロフォン， １３ 生成装置， １４ 配信サーバ， １５ 再生装置， １５Ａ カメラ， １６ ヘッドマウントディスプレイ， １６Ａ マーカ， １６Ｂ ジャイロセンサ， ２１ スティッチング処理部， ２２ マッピング処理部， ２３ region-wise packing処理部， ２４ エンコーダ， ２５ 音声処理部， ２６ エンコーダ， ２７ ファイル生成部， ２８ アップロード部， ３１ ファイル取得部， ３２ ストリーム抽出部， ３３ デコーダ， ３４ projected frame生成部， ３５ マッピング処理部， ３６ 描画部， ３７ 受け取り部， ３８ 視線検出部

Claims (19)

  1. コンテンツのカバレッジ情報に基づいて、多面体の前記カバレッジ情報に対応する面ごとに各面の中心方向と水平方向および垂直方向の角度幅をシグナルし、前記シグナルを用いて球面上に形成される面領域を、前記カバレッジ情報に対応する面の数に応じてシグナルすることで球面上の領域を表現する領域情報を生成する生成部
    を備える情報処理装置。
  2. コンテンツのカバレッジ情報に基づいて、多面体の前記カバレッジ情報に対応する面ごとに各面の頂点をシグナルし、それらの頂点どうしを球面上の最短距離で結ぶことで形成される面領域を、前記カバレッジ情報に対応する面の数に応じてシグナルすることで球面上の領域を表現する領域情報を生成する生成部
    を備える情報処理装置。
  3. 前記頂点どうしを球面上の最短距離で結ぶ線分はｇｒｅａｔ ｃｉｒｃｌｅの一部である
    請求項２に記載の情報処理装置。
  4. 前記領域情報は、非連続な複数の前記面領域を形成する
    請求項３に記載の情報処理装置。
  5. 前記領域情報には、複数の頂点でカバーされる領域に含まれる代表点がシグナルされる
    請求項１に記載の情報処理装置。
  6. 前記領域情報は、非連続な複数の前記面領域を形成する
    請求項１に記載の情報処理装置。
  7. 前記領域情報は、拡張されたＩＳＯＢＭＦＦによりシグナルされる
    請求項１に記載の情報処理装置。
  8. 前記領域情報は、拡張されたＤＡＳＨ ＭＰＤによりシグナルされる
    請求項１に記載の情報処理装置。
  9. 前記領域情報は、前記面の数に従ってループを回すことで前記面領域がシグナルされる
    請求項１に記載の情報処理装置。
  10. 前記領域情報には、シグナルされた領域をカバーするか、シグナルされた領域以外をカバーするかを示すフラグが含まれる
    請求項１に記載の情報処理装置。
  11. コンテンツのカバレッジ情報に基づいて、多面体の前記カバレッジ情報に対応する面ごとに各面の中心方向と水平方向および垂直方向の角度幅をシグナルし、前記シグナルを用いて球面上に形成される面領域を、前記カバレッジ情報に対応する面の数に応じてシグナルすることで球面上の領域を表現する領域情報を生成する
    ステップを含む情報処理をコンピュータに実行させるプログラム。
  12. コンテンツのカバレッジ情報に基づいて、多面体の前記カバレッジ情報に対応する面ごとに各面の中心方向と水平方向および垂直方向の角度幅をシグナルし、前記シグナルを用いて球面上に形成される面領域を、前記カバレッジ情報に対応する面の数に応じてシグナルすることで球面上の領域を表現する領域情報を取得する取得部と、
    取得された前記領域情報を解析して前記球面上の領域に関連する処理を行う処理部と
    を備える情報処理装置。
  13. 前記領域情報には、複数の頂点でカバーされる領域に含まれる代表点がシグナルされる
    請求項１２に記載の情報処理装置。
  14. 前記領域情報は、非連続な複数の前記面領域を形成する
    請求項１２に記載の情報処理装置。
  15. 前記領域情報は、拡張されたＩＳＯＢＭＦＦによりシグナルされる
    請求項１２に記載の情報処理装置。
  16. 前記領域情報は、拡張されたＤＡＳＨ ＭＰＤによりシグナルされる
    請求項１２に記載の情報処理装置。
  17. 前記領域情報は、前記面の数に従ってループを回すことで前記面領域がシグナルされる
    請求項１２に記載の情報処理装置。
  18. 前記領域情報には、シグナルされた領域をカバーするか、シグナルされた領域以外をカバーするかを示すフラグが含まれる
    請求項１２に記載の情報処理装置。
  19. コンテンツのカバレッジ情報に基づいて、多面体の前記カバレッジ情報に対応する面ごとに各面の中心方向と水平方向および垂直方向の角度幅をシグナルし、前記シグナルを用いて球面上に形成される面領域を、前記カバレッジ情報に対応する面の数に応じてシグナルすることで球面上の領域を表現する領域情報を取得するステップと、
    取得された前記領域情報を解析して前記球面上の領域に関連する処理を行うステップと
    を含む情報処理をコンピュータに実行させるプログラム。
JP2019507591A 2017-03-24 2018-03-14 情報処理装置およびプログラム Active JP7243620B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2017060221 2017-03-24
JP2017060221 2017-03-24
PCT/JP2018/009913 WO2018173875A1 (ja) 2017-03-24 2018-03-14 情報処理装置および情報処理方法、並びにプログラム

Publications (2)

Publication Number Publication Date
JPWO2018173875A1 JPWO2018173875A1 (ja) 2020-02-20
JP7243620B2 true JP7243620B2 (ja) 2023-03-22

Family

ID=63586527

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019507591A Active JP7243620B2 (ja) 2017-03-24 2018-03-14 情報処理装置およびプログラム

Country Status (10)

Country Link
US (1) US20190394445A1 (ja)
EP (1) EP3606085A4 (ja)
JP (1) JP7243620B2 (ja)
KR (1) KR20190129865A (ja)
CN (1) CN110476436A (ja)
AU (1) AU2018238632A1 (ja)
BR (1) BR112019019311A2 (ja)
CA (1) CA3056739A1 (ja)
RU (1) RU2019129256A (ja)
WO (1) WO2018173875A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020071111A1 (ja) * 2018-10-02 2020-04-09 ソニー株式会社 情報処理装置および情報処理方法、並びにプログラム
WO2021194483A1 (en) * 2020-03-25 2021-09-30 Alcacruz Inc. Generating a representation of a spherical image
US11888913B2 (en) 2021-04-28 2024-01-30 Lemon Inc. External stream representation properties

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009133798A (ja) 2007-12-03 2009-06-18 Furuno Electric Co Ltd 位置検出方法および位置検出装置
WO2015060165A1 (ja) 2013-10-22 2015-04-30 シャープ株式会社 表示処理装置、配信装置、および、メタデータ
JP2016509418A (ja) 2013-01-18 2016-03-24 キヤノン株式会社 分割された時分割メディアデータをカプセル化するための方法、デバイス、およびコンピュータプログラム
JP2019525675A (ja) 2016-08-25 2019-09-05 エルジー エレクトロニクス インコーポレイティド 全方位ビデオを伝送する方法、全方位ビデオを受信する方法、全方位ビデオの伝送装置及び全方位ビデオの受信装置
JP2020501389A (ja) 2016-11-17 2020-01-16 インテル コーポレイション パノラマビデオのための提案されるビューポート指示

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003141562A (ja) * 2001-10-29 2003-05-16 Sony Corp 非平面画像の画像処理装置及び画像処理方法、記憶媒体、並びにコンピュータ・プログラム
JP2004272590A (ja) * 2003-03-07 2004-09-30 Sony Corp データ符号化装置及びデータ符号化方法、並びにコンピュータ・プログラム
JP4945578B2 (ja) * 2007-01-04 2012-06-06 肇 鳴川 情報処理方法
JP6344723B2 (ja) * 2015-07-14 2018-06-20 パナソニックＩｐマネジメント株式会社 映像表示システム、映像表示装置及び映像表示方法
WO2017142353A1 (ko) * 2016-02-17 2017-08-24 엘지전자 주식회사 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치
KR102506480B1 (ko) * 2016-06-14 2023-03-07 삼성전자주식회사 영상 처리 장치 및 그 영상 처리 방법
CN205793093U (zh) * 2016-07-12 2016-12-07 冯心斌 一种带夹子的机顶盒
KR102498598B1 (ko) * 2016-10-18 2023-02-14 삼성전자주식회사 영상 처리 장치 및 그 영상 처리 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009133798A (ja) 2007-12-03 2009-06-18 Furuno Electric Co Ltd 位置検出方法および位置検出装置
JP2016509418A (ja) 2013-01-18 2016-03-24 キヤノン株式会社 分割された時分割メディアデータをカプセル化するための方法、デバイス、およびコンピュータプログラム
WO2015060165A1 (ja) 2013-10-22 2015-04-30 シャープ株式会社 表示処理装置、配信装置、および、メタデータ
JP2019525675A (ja) 2016-08-25 2019-09-05 エルジー エレクトロニクス インコーポレイティド 全方位ビデオを伝送する方法、全方位ビデオを受信する方法、全方位ビデオの伝送装置及び全方位ビデオの受信装置
JP2020501389A (ja) 2016-11-17 2020-01-16 インテル コーポレイション パノラマビデオのための提案されるビューポート指示

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
「DB2 for Linux, Unix, and Windows Spatial ExtenderおよびGeodetic Data Management Feature ユーザーズ・ガイドおよびリファレンス 2012年7月更新版 バージョン９ リリース７」，SC88-5900-02，日本，日本アイ・ビー・エム株式会社，2012年05月，第１４１～１４６頁.
Jill Boyce, et al.，"HEVC Additional Supplemental Enhancement Information (Draft 1)"，Document: JCTVC-Z1005, [online]，JCTVC-Z1005 (version 1)，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，2017年02月04日，Pages 1-19，[平成30年4月10日検索], インターネット, <URL: http://phenix.it-sudparis.eu/jct/doc_end_user/documents/26_Geneva/wg11/JCTVC-Z1005-v1.zip>.
Jill Boyce, et al.，"Spherical viewport SEI for HEVC and AVC 360 video"，Document: JCTVC-Z0034, [online]，JCTVC-Z0034 (version 3)，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，2017年01月13日，Pages 1-5，[令和4年4月1日検索], インターネット, <URL: http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=10651> and <URL: http://phenix.it-sudparis.eu/jct/doc_end_user/documents/26_Geneva/wg11/JCTVC-Z0034-v3.zip>.
Jill Boyce，"Omnidirectional recommended viewport SEI Message"，Document: JCTVC-AA0036, [online]，JCTVC-AA0036 (version 1)，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，2017年03月22日，Pages 1-3，[令和4年4月1日検索], インターネット, <URL: http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=10712> and <URL: http://phenix.it-sudparis.eu/jct/doc_end_user/documents/27_Hobart/wg11/JCTVC-AA0036-v1.zip>.
Sejin Oh, et al.，"SEI message for signaling of 360-degree video information"，Document: JCTVC-Z0026, [online]，JCTVC-Z0026 (version 3)，Joint Collaborative Team on Video Coding (JCT-VC) of ITU-T SG 16 WP 3 and ISO/IEC JTC 1/SC 29/WG 11，2017年01月18日，Pages 1-6，[平成30年4月10日検索], インターネット, <URL: http://phenix.it-sudparis.eu/jct/doc_end_user/documents/26_Geneva/wg11/JCTVC-Z0026-v3.zip>.
株式会社構造システム編，「こんなに簡単！ＤＲＡ－ＣＡＤ１２ ３次元編 －モデリング／レンダリングから日影図／天空図まで－」，初版，日本，株式会社構造システム，2014年04月，第３９頁，ISBN: 978-4-87735-055-0.

Also Published As

Publication number Publication date
EP3606085A1 (en) 2020-02-05
AU2018238632A1 (en) 2019-10-10
RU2019129256A3 (ja) 2021-03-17
CA3056739A1 (en) 2018-09-27
KR20190129865A (ko) 2019-11-20
EP3606085A4 (en) 2020-02-05
BR112019019311A2 (pt) 2020-04-14
JPWO2018173875A1 (ja) 2020-02-20
CN110476436A (zh) 2019-11-19
RU2019129256A (ru) 2021-03-17
WO2018173875A1 (ja) 2018-09-27
US20190394445A1 (en) 2019-12-26

Similar Documents

Publication Publication Date Title
JP7218826B2 (ja) 再生装置および画像生成方法
US10909761B1 (en) 2D video with option for projected viewing in modeled 3D space
JP7151486B2 (ja) 生成装置、生成方法、再生装置および再生方法
US11115644B2 (en) Video generation method and apparatus using mesh and texture data
JP2019516297A (ja) ビューを意識した３６０度ビデオストリーミング
US20200329266A1 (en) Information processing apparatus, method for processing information, and storage medium
KR20190008901A (ko) 가상 현실 미디어 콘텐트의 스트리밍을 개선하는 방법, 디바이스, 및 컴퓨터 프로그램
JP7243620B2 (ja) 情報処理装置およびプログラム
JP6860485B2 (ja) 情報処理装置、および情報処理方法、並びにプログラム
US20180176650A1 (en) Information processing apparatus and information processing method
WO2017195881A1 (ja) ファイル生成装置およびファイル生成方法、並びに、再生装置および再生方法
JP7035401B2 (ja) 画像処理装置およびファイル生成装置
TW201921918A (zh) 影像處理裝置及檔案生成裝置
KR102656191B1 (ko) 360 비디오 환경에서 포인트 클라우드 콘텐트 액세스 및 전달을 위한 방법 및 장치
KR102413098B1 (ko) 영상 처리 방법 및 이를 이용한 영상 재생 장치
JP7239029B2 (ja) 画像処理装置およびファイル生成装置
JP2022036123A (ja) 自由視点映像のリプレイ映像を再生するシステムおよび方法

Legal Events

Date Code Title Description
A529 Written submission of copy of amendment under article 34 pct

Free format text: JAPANESE INTERMEDIATE CODE: A5211

Effective date: 20190805

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210202

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220412

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220606

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220830

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20221021

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230207

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230220

R151 Written notification of patent or utility model registration

Ref document number: 7243620

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151