[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

JP7567481B2 - 情報処理装置および情報処理方法 - Google Patents

情報処理装置および情報処理方法 Download PDF

Info

Publication number
JP7567481B2
JP7567481B2 JP2020563092A JP2020563092A JP7567481B2 JP 7567481 B2 JP7567481 B2 JP 7567481B2 JP 2020563092 A JP2020563092 A JP 2020563092A JP 2020563092 A JP2020563092 A JP 2020563092A JP 7567481 B2 JP7567481 B2 JP 7567481B2
Authority
JP
Japan
Prior art keywords
point cloud
cloud data
information
partial
file
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
JP2020563092A
Other languages
English (en)
Other versions
JPWO2020137642A1 (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 JPWO2020137642A1 publication Critical patent/JPWO2020137642A1/ja
Application granted granted Critical
Publication of JP7567481B2 publication Critical patent/JP7567481B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00—Image coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T17/00—Three dimensional [3D] modelling, e.g. data description of 3D objects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00—Image coding
    • G06T9/001—Model-based coding, e.g. wire frame
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/3068—Precoding preceding compression, e.g. Burrows-Wheeler transformation
    • H03M7/3071—Prediction
    • H03M7/3075—Space
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • 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/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • 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/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234345—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements the reformatting operation being performed only on part of the stream, e.g. a region of the image or a time segment
    • 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/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • 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/81—Monomedia components thereof
    • H04N21/816—Monomedia components thereof involving special video data, e.g 3D video
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2207/00—Indexing scheme for image analysis or image enhancement
    • G06T2207/10—Image acquisition modality
    • G06T2207/10028—Range image; Depth image; 3D point clouds
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/3059—Digital compression and data reduction techniques where the original information is represented by a subset or similar information, e.g. lossy compression
    • H03M7/3064—Segmenting
    • H—ELECTRICITY
    • H03—ELECTRONIC CIRCUITRY
    • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
    • H03M7/00—Conversion of a code where information is represented by a given sequence or number of digits to a code where the same, similar or subset of information is represented by a different sequence or number of digits
    • H03M7/30—Compression; Expansion; Suppression of unnecessary data, e.g. redundancy reduction
    • H03M7/40—Conversion to or from variable length codes, e.g. Shannon-Fano code, Huffman code, Morse code
    • H03M7/4031—Fixed length to variable length coding
    • H03M7/4037—Prefix coding
    • H03M7/4043—Adaptive prefix coding

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Graphics (AREA)
  • Geometry (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Image Generation (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)
  • Information Transfer Between Computers (AREA)

Description

本開示は、情報処理装置および情報処理方法に関し、特に、より高品位なG-PCCストリーム配信を行うことができるようにした情報処理装置および情報処理方法に関する。
従来、MPEG-I Part 9 Geometry-based Point Cloud Compression(ISO/IEC 23090-9)では、３次元空間上に位置情報と属性情報（例えば、色情報や反射情報など）とを同時に持った点の集合であるPoint Cloudの圧縮方法が規定される。
例えば、非特許文献１で開示されているように、Geometry-based Point Cloud Compression (G-PCC) では、Point Cloudを、３次元構造を示すgeometryと、色や反射情報等を示すattributeとに分離して、符号化する。
また、geometryの圧縮には、図１に示すようなoctree符号化が用いられる。例えば、octree符号化は、Voxel表現されたデータにおいて、各ブロック内のポイントの有無を、八分木によって表現する手法である。この手法では、図１に示すように、ポイントが存在するブロックは１、存在しないブロックは０で表現される。
また、attributeの圧縮には、Predicting Weight Lifting，Region Adaptive Hierarchical Transform (RAHT)、またはFix Weight Liftingが用いられる。
w17770, Third Working Draft for G-PCC (Geometry-based PCC), July 2018, Ljubljana, Slovenia w18001, Description of Core Experiment 13.2 for G-PCC: Tile and Slice based Coding of Point Cloud, October 2018, Macau, China
ところで、従来の配信技術では、Point Cloudオブジェクトの３次元構造情報を、図１に示したようなoctree符号化で均一に圧縮したG-PCCストリームを配信する。このように、octree符号化で均一に圧縮する場合、配信されるG-PCCストリームは、周囲360°から視聴できる３次元情報を持ち、かつ、全周囲の精細さが同一となる。このとき、配信時のネットワーク帯域幅の制限から、下記の２つの点が懸念される。
第１に、Point Cloudを構成するポイントが密となる高精細なG-PCCストリームを配信しようとすると、ある特定時間においてユーザが視聴できるPoint Cloudの一部分か否かに関係なく、Point Cloudオブジェクト全体の圧縮率を一律に下げる（即ち、高精細化する）ことになる。このため、不要にビットレートが増加して再生が途切れることが懸念される。
第２に、再生途切れを抑制すべくビットレートを削減する場合、G-PCCストリーム全体の圧縮率を一律に上げる（即ち、低精細化する）ことになる。このため、ある特定時間においてユーザが視聴しているPoint Cloudオブジェクトの一部分まで、Point Cloudを構成するポイントが疎となって低精細となることが懸念される。
このように、従来、ネットワーク帯域幅が効率良くなるように活用されておらず、高精細に視聴され、かつ、途切れずに再生されるような高品位なG-PCCストリーム配信が実現されていなかった。
本開示は、このような状況に鑑みてなされたものであり、より高品位なG-PCCストリーム配信を行うことができるようにするものである。
本開示の第１の側面の情報処理装置は、Point Cloudデータを３次元構造ベースで符号化してPoint Cloudデータ符号化ストリームを生成する際に、前記Point Cloudデータが複数の部分に分割された個々の部分となる部分Point Cloudデータそれぞれの空間上の位置を示す空間位置情報と、それらの部分Point Cloudデータをグルーピングするグルーピング情報とを含むファイルを生成するファイル生成部を備える。
本開示の第１の側面の情報処理方法は、情報処理装置が、Point Cloudデータを３次元構造ベースで符号化してデータ符号化ストリームを生成する際に、前記Point Cloudデータが複数の部分に分割された個々の部分となる部分Point Cloudデータそれぞれの空間上の位置を示す空間位置情報と、それらの部分Point Cloudデータをグルーピングするグルーピング情報とを含むファイルを生成することを含む。
本開示の第１の側面においては、Point Cloudデータを３次元構造ベースで符号化してデータ符号化ストリームを生成する際に、Point Cloudデータが複数の部分に分割された個々の部分となる部分Point Cloudデータそれぞれの空間上の位置を示す空間位置情報と、それらの部分Point Cloudデータをグルーピングするグルーピング情報とを含むファイルが生成される。
本開示の第２の側面の情報処理装置は、Point Cloudデータを３次元構造ベースで符号化してPoint Cloudデータ符号化ストリームを生成する際に、前記Point Cloudデータが複数の部分に分割された個々の部分となる部分Point Cloudデータそれぞれの空間上の位置を示す空間位置情報と、それらの部分Point Cloudデータをグルーピングするグルーピング情報とを含むファイルを解析し、前記部分Point Cloudデータを復号する再生処理部を備える。
本開示の第２の側面の情報処理方法は、情報処理装置が、Point Cloudデータを３次元構造ベースで符号化してPoint Cloudデータ符号化ストリームを生成する際に、前記Point Cloudデータが複数の部分に分割された個々の部分となる部分Point Cloudデータそれぞれの空間上の位置を示す空間位置情報と、それらの部分Point Cloudデータをグルーピングするグルーピング情報とを含むファイルを解析し、前記部分Point Cloudデータを復号することを含む。
本開示の第２の側面においては、Point Cloudデータを３次元構造ベースで符号化してPoint Cloudデータ符号化ストリームを生成する際に、Point Cloudデータが複数の部分に分割された個々の部分となる部分Point Cloudデータそれぞれの空間上の位置を示す空間位置情報と、それらの部分Point Cloudデータをグルーピングするグルーピング情報とを含むファイルを解析し、部分Point Cloudデータが復号される。
octree符号化について説明する図である。 Point Cloudオブジェクトの部分ごとに精細度を変えて符号化する一例を示す図である。 方向情報により示される方向の一例を示す図である。 方向情報のシグナリングの一例を示す図である。 精細度情報のシグナリングの一例を示す図である。 DirectionInformationBoxのシグナル場所の一例を示す図である。 DirectionInformationBoxのシンタックスの一例を示す図である。 ４つに分割されたPoint Cloudオブジェクトの一例を示す図である。 Ｘ軸方向で半分に分割されたobject boxの一例を示す図である。 gpcc:blockInfoの属性の定義を示す図である。 部分G-PCCストリームの空間位置情報およびグルーピング情報のシグナリングの一例を示す図である。 空間位置情報のイメージ図である。 部分G-PCCストリームの精細度情報のシグナリングの一例を示す図である。 データ生成装置の構成例を示すブロック図である。 データ再生装置の構成例を示すブロック図である。 部分G-PCCストリームが格納されたファイルを生成する生成処理を説明するフローチャートである。 部分G-PCCストリームが格納されたファイルを再生する再生処理を説明するフローチャートである。 部分G-PCCストリームの方向対応情報の必要性について説明する図である。 部分G-PCCストリームの方向対応情報のシグナリングの一例を示す図である。 動的に変化する空間位置情報および方向対応情報の必要性について説明する図である。 動的に変化する空間位置情報および方向対応情報のシグナリングの一例を示す図である。 timed metadataのsample entryのシンタックスの一例を示す図である。 timed metadataのsampleのシンタックスの一例を示す図である。 各時間における空間位置情報のシグナリングの一例を示す図である。 BlockGroupBoxのシグナル例を示す図である。 BlockGroupBoxに部分G-PCCストリームの空間位置情報をシグナルするシンタックスの一例を示す図である。 階層化による部分G-PCCストリームの生成について説明する図である。 組み合わせられる各G-PCCストリームの空間位置情報のシグナリングの一例を示す図である。 空間位置情報のイメージ図である。 track referenceの運用例を示す図である。 CombinedAreaLodInfoBox(‘cloi’)のシンタックスの一例を示す図である。 BrickGroupEntryのシンタックスの一例を示す図である。 UnitMapEntryのシンタックスの一例を示す図である。 BrickGroupEntryおよびUnitMapEntryの運用例を示す図である。 動的なbrick構成の変更について説明する図である。 brick base trackおよびbrick trackの構成について説明する図である。 brickの空間位置情報のシグナリングの一例を示す図である。 レンダリング処理方法のシグナリングの一例を示す図である。 RenderingInformationBoxのシグナル例を示す図である。 RenderingInformationBoxのシンタックスの一例を示す図である。 高精細化される部分の処理タイプのシンタックスの一例を示す図である。 combined_track_existsフィールド、comnbined_track_idフィールド、およびcombined_area_typeフィールドを追加したシンタックスの一例を示す図である。 priority_flagフィールドを追加したシンタックスの一例を示す図である。 Sample Group概要を示す図である。 本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。
以下、本技術を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。
＜本開示における３つのポイント＞
まず、本実施の形態において開示される技術において特徴となる第１乃至第３のポイントの概要について説明する。例えば、Point CloudオブジェクトをHMD（Head Mounted Display）やFlat Panel Displayで視聴する場合、視聴方向に対して反対側の表面形状および色は見えないという点を利用した視聴方向適応配信技術が用いられる。
第１のポイントでは、１つのPoint Cloudオブジェクトの部分毎に精細度を変えて符号化したG-PCCストリームを配信する点が特徴となる。例えば、G-PCCストリームにおいて、高精細になっている方向を示す方向情報と、その方向における精細度を示す精細度情報とを付加する。これにより、クライアントは、視聴部分については高精細となり、かつ、視聴部分以外については低精細となるようにG-PCCストリームを取得することができる。従って、第１のポイントにより、ネットワーク帯域幅を有効活用した視聴部分の高精細化を実現することが可能となる。
第２のポイントでは、１つのPoint Cloudオブジェクトを複数の部分オブジェクトに分割し、個々の部分オブジェクトごとに精細度を変えて符号化した部分G-PCCストリームを配信する点が特徴となる。また、第２のポイントでは、空間分割により生成した部分G-PCCストリームを配信する第１の手法と、階層化により生成した部分G-PCCストリームを配信する第２の手法とが提案される。
例えば、第２のポイントの第１の手法においは、各部分G-PCCストリームに空間位置情報および精細度情報を付加する。これにより、クライアントは、視聴部分については高精細な部分G-PCCストリームを取得し、かつ、視聴部分以外については低精細な部分G-PCCストリームを取得することができる。従って、第２のポイントの第１の手法により、ネットワーク帯域幅を有効活用した視聴部分の高精細化を実現することが可能となる。
また、第２のポイントの第２の手法においは、各部分G-PCCストリームに対し、第２のポイントの第１の手法で付加した情報に、高精細化するために組み合わせるべき部分G-PCCストリームを識別するための情報を付加する。これにより、クライアントは、視聴部分を高精細化するために必要な組み合わせで部分G-PCCストリームを取得することができる。従って、第２のポイントの第２の手法によっても、ネットワーク帯域幅を有効活用した視聴部分の高精細化を実現することが可能となる。
第３のポイントでは、Point Cloudオブジェクトの低精細な部分のレンダリング処理を指定する。例えば、G-PCCストリームに対し、低精細な部分の主観品質向上のために必要なレンダリング処理の情報を付加する。これにより、クライアントは、指定されたレンダリング処理を識別し、その処理を実行可能である場合、そのG-PCCストリームを取得することができる。従って、第３のポイントにより、主観品質を維持しつつ、かつ、G-PCCストリーム配信に必要なネットワーク帯域幅を削減することが可能となる。
なお、上述した第１乃至第３のポイントにおいて付加される情報は、DASH MPD（Dynamic Adaptive Streaming over HTTP Media Presentation Description）またはISOBMFF（ISO Base Media File Format）を拡張することによりシグナルされる。
＜第１のポイント＞
図２乃至図７を参照して、部分毎に精細度を変えて符号化したG-PCCストリームを配信する第１のポイントについて説明する。
図２に示すように、G-PCCストリームを生成する際、Point Cloudオブジェクトの部分ごとにVoxelを区切る細かさ（octree depth）を変更することで、部分毎に精細度を変えて符号化することが可能となる。
図２に示す例では、Point Cloudオブジェクトが８つの部分に分けられている。そして、グレーのハッチングが施されている２つの部分が高精細（depth=10）に符号化され、残りの６つの部分が低精細（depth=5）に符号化されている。
これにより、クライアントは、視聴部分については高精細となるように符号化されたG-PCCストリームを取得し、かつ、それ以外については低精細となる符号化されたG-PCCストリームを取得することができる。これにより、ネットワーク帯域幅を有効活用した視聴部分の高精細化が可能となる。このとき、部分毎の精細度はG-PCCストリームをデコードしないと識別できないため、クライアントがサーバー上のG-PCCストリームを選択および取得する際、視聴部分が高精細になっているG-PCCストリームを識別できるようにする必要がある。
例えば、このような識別は、360°全天球映像の領域ごとの高画質化ストリームを視聴方向に応じて選択する際にも必要となる。即ち、360°全天球映像の領域ごとの高画質化ストリームの場合は、視点位置が固定であるため、ユーザの視聴部分は視聴方向に依存するのみであった。そのため、360°全天球映像の領域ごとの高画質化ストリームに対し、高画質化領域の視聴方向対応情報を付加することが一般的に行われている。
これに対し、本技術におけるG-PCCストリームの場合、様々な視点位置から異なる視聴方向でPoint Cloudオブジェクトの同一部分を視聴することができる。このため、360°全天球映像で用いられるような視聴方向対応情報を参照しても、クライアントは、視聴部分が高精細化されているG-PCCストリームを適切に取得することができない。
そこで、第１のポイントでは、G-PCCストリームにおいて、高精細になっている方向をシグナルすることを提案する。これにより、クライアントは、視聴方向および視点位置に応じて、視聴部分が高精細化されているG-PCCストリームを選択して取得することが可能となる。
さらに、第１のポイントでは、G-PCCストリームの高精細になっている方向について、その方向の精細度情報をシグナルすることを提案する。これにより、G-PCCストリームの視聴部分が変化した場合、新たな視聴部分の精細度が、その変化する前の視聴部分の精細度と同等となるG-PCCストリームに切り替えることが可能となる。例えば、視聴部分の変化に伴って精細度が大きく変化する場合には、ユーザの視聴体験が悪化してしまうことが想定されるが、視聴部分の変化によっても精細度の変化を抑制することで、このような視聴体験の悪化を回避することができる。
図３乃至図５を参照して、DASH MPDの拡張について説明する。
例えば、G-PCCストリームにおいて高精細になっている方向の情報として、high lod direction descriptor (schemeIdUri=”urn:mpeg:mepgI:gpcc:high_lod_direction:2018”のSupplementalProperty)を新規定義してAdaptation Setにシグナルする。即ち、gpcc:directionInfo要素のdirection属性に、高精細になっている方向を示す方向情報をシグナルする。
また、図３に示すように、direction属性の取りうる値は、Point Cloudのローカル座標系を基準として、0: X+，1: Y+，2: X-，3: Y-，4: Z+，5: Z-の６方向でシグナルすることができる。その他、45°刻み等、より細かい粒度で方向をシグナルしてもよい。
なお、１つのG-PCCストリーム内で複数方向が高精細化されていてもよい。この場合、複数のgpcc:directionInfo要素を用いてシグナルされる。さらに、”gpcc:”はname space prefixであり、例えば”urn:mpeg:mpegI:gpcc:2018”のname spaceを利用するものとする。
図４には、方向情報のシグナリングの一例が示されており、図４において太字で記載されている個所に方向情報がシグナルされている。
例えば、ユーザがPoint Cloudのローカル座標系のＸ＋方向の部分を視聴している場合、クライアントはhigh lod direction descriptorを参照してAdaptationSet@id=1を選択して、高精細化されている部分を取得することができる。これにより、ユーザの視聴部分を高精細化するPoint Cloudの表示が可能となる。
さらに、high lod direction descriptorに対し、高精細化されている方向の精細度を示す精細度情報を追加し、Representationにシグナルする。例えば、gpcc:directionInfo要素のlod_ranking属性に、精細度ランキング情報をシグナルする。精細度ランキングは、値が小さいほど精細度が高いことを示す。
図５には、精細度情報をシグナルする一例が示されており、図５において太字で記載されている個所に精細度情報がシグナルされている。
例えば、ユーザがPoint Cloudのローカル座標系のＸ＋方向の部分を視聴していて、クライアントが、Representation@id=”1-1”を再生中である場合において、ユーザがＹ＋方向の部分を視聴するように視点位置および視聴方向が変化したとする。このとき、クライアントは、AdaptationSet@id=”2”のRepresentation@id=”2-1”を選択して、視点位置および視聴方向が変化する前と同じ精細度の部分を取得することができる。これにより、視聴部分の変化に伴って精細度が大きく変化してしまうことを抑制し、ユーザの視聴体験が悪化してしまうのを回避することができる。
なお、高精細化されている方向の精細度情報として、精細度ランキング情報ではなく、高精細となっている方向のoctree depthの値をシグナルしてもよい。
図６および図７を参照して、ISOBMFFの拡張について説明する。
例えば、高精細となっている方向を示す方向情報、および、高精細化されている方向における精細度を示す精細度情報は、DirectionInformationBox(‘diri’)を新規定義してシグナルする。
そして、図６に示すように、ISOBMFF trackのsample entryに、そのtrackに格納されるG-PCCストリームの方向情報および精細度情報(‘diri’)をシグナルする。従って、クライアントは、方向情報および精細度情報に基づいて、ISOBMFFに含まれる複数のtrackのうち、視聴部分を高精細化するtrackを選択し、視聴部分を高精細に再生することができる。
図７には、directionInformationBoxのシンタックスの一例が示されている。
図７のシンタックスにおいて、high_lod_directionフィールドと、lod_rankingフィールドとのセマンティクスは、high lod direction descriptorのgpcc:directionInfo要素の同名属性と同様である。
なお、高精細化されている方向の精細度情報として、精細度ランキング情報ではなく、高精細となっている方向のoctree depthの値をシグナルしてもよい。また、精細度情報(‘diri’)は、ISOBMFF trackのsample entry以外にシグナルされてもよい。
＜第２のポイント＞
図８乃至図３７を参照して、部分オブジェクトそれぞれの精細度を変えて符号化した部分G-PCCストリームを配信する第２のポイントについて説明する。
例えば、１つのPoint Cloudオブジェクトを複数の部分Point Cloudオブジェクトに分け、それぞれを符号化して部分G-PCCストリームを生成する。そして、符号化の際、octree depthを変更し、部分G-PCCストリームごとに精細度のバリエーションを持つようにする。これにより、クライアントは、視聴部分が高精細、それ以外は低精細となるよう部分G-PCCストリームを取得することで、帯域幅を有効活用した視聴部分の高精細化ができる。
このとき、部分G-PCCストリームがPoint Cloudオブジェクト全体のどの部分に相当するのかを識別し、また、部分G-PCCストリームの精細度情報はデコードしなくても識別できるようにする必要がある。即ち、クライアントがサーバー上のG-PCCストリームを選択および取得する際、視聴部分を高精細化するための部分G-PCCストリームを適切に選択できるようにする必要がある。
図８乃至図２６を参照して、空間分割により生成した部分G-PCCストリームを配信する第２のポイントの第１の手法について説明する。
図８に示すように、１つのPoint Cloudオブジェクトを空間分割することで、部分Point Cloudを生成し、それぞれを符号化して部分G-PCCストリームを生成・配信することができる。図８には、Point Cloudオブジェクトを4つに空間分割する場合の例が示されている。
このとき、部分G-PCCストリームの空間位置情報、１つの全体Point Cloudオブジェクトを構成する部分G-PCCストリームのグルーピング情報をシグナルする。さらに、部分G-PCCストリームの精細度情報をシグナルする。
これにより、クライアントは、グルーピング情報および部分G-PCCストリームの精細度情報を参照することで、視聴部分を高精細にするための部分G-PCCストリームを取得することができる。
ここで、空間分割の方法、および、空間位置情報について説明する。
例えば、Point Cloudオブジェクトの形状は、最大frame by frameで変わる。そこで、Point Cloudオブジェクトの形状の変化に依存しない、一定の分割ルールを適用することで空間分割を行う。具体的には、Point Cloudオブジェクト全体を含むbox（以下適宜、object boxと称する）に対して、相対的に同じ空間位置を占める直方体ブロック（以下適宜、blockと称する）に含まれる部分Point Cloudオブジェクトを、１つの部分G-PCCストリームとして符号化する。
図９には、object boxをＸ軸方向で半分に分割する例が示されている。
図９に示すように、時刻ｔ０のPoint Cloudオブジェクト全体を含むobject boxが、部分Point Cloudオブジェクトｔ０－ａおよびｔ０－ｂにＸ軸方向で半分に分割される。同様に、時刻ｔ１では、部分Point Cloudオブジェクトｔ１－ａおよびｔ１－ｂに分割れ、時刻ｔ２では、部分Point Cloudオブジェクトｔ２－ａおよびｔ２－ｂに分割れる。そして、ａのG-PCCストリームは、部分Point Cloudオブジェクトｔ０－ａ、部分Point Cloudオブジェクトｔ１－ａ、および部分Point Cloudオブジェクトｔ２－ａにより構成される。一方、ｂのG-PCCストリームは、部分Point Cloudオブジェクトｔ０－ｂ、部分Point Cloudオブジェクトｔ１－ｂ、および部分Point Cloudオブジェクトｔ２－ｂにより構成される。
なお、この方法によれば、部分G-PCCストリームに含まれる部分Point Cloudオブジェクトの全体Point Cloudオブジェクトに対する相対的空間位置が動的に不変となる。相対的空間位置が動的に変わる場合、視聴部分とそれを含む部分G-PCCストリームの関係性が動的に変化する。そのため、クライアントが視聴部分を高精細化するG-PCCストリームを取得する場合、視聴部分が不変であったとしても、取得する高精細なG-PCCストリームを切り替える必要が出てしまう。そこで、この空間分割の手法によって、視聴部分が不変であるときには、取得する高精細なG-PCCストリームを切り替える必要をなくすことができる。
図１０乃至図１３を参照して、DASH MPDの拡張について説明する。
例えば、部分G-PCCストリームの空間位置情報およびグルーピング情報を、block information descriptor (schemeIdUri=”urn:mpeg:mepgI:gpcc:block_information:2018”のSupplementalProperty)を新規定義して、Adaptation Setにシグナルする。
図１０に示すように、空間位置情報は、gpcc:blockInfo要素のblock_offset_x, block_offset_y, block_offset_z, block_size_x, block_size_y, block_size_zの各属性で示す。これらの各属性は、全てobject boxのx, y, z軸の各辺を１とした時の相対値でシグナルする。なお、blockの位置および形状と、部分Point CloudオブジェクトをG-PCC符号化する際のbounding boxの位置および形状は同じものとする。なお、blockの位置および形状のいずれかと、部分Point CloudオブジェクトをG-PCC符号化する際のbounding boxの位置および形状のいずれかが異なる場合には、bounding box内におけるblockの位置および形状を示す情報を別途シグナルすればよい。
また、グルーピング情報は、gpcc:blockInfo要素のobject_id属性で示す。同一のPoint Cloudオブジェクトを構成する部分G-PCCストリームに対して、同じ値のobject_id属性をシグナルする。
図１１には、部分G-PCCストリームの空間位置情報およびグルーピング情報のシグナリングの一例が示されており、図１１において太字で記載されている個所に部分G-PCCストリームの空間位置情報およびグルーピング情報がシグナルされている。
図１２は、各Adaptation Setのblock information descriptorでシグナリングされる空間位置情報のイメージ図である。
なお、gpcc:blockInfo要素に精細度情報をシグナルする属性を追加した上で、block information descriptorで複数のgpcc:blockInfo要素をシグナルすると、1 G-PCCストリームの空間位置ごとの精細度情報シグナリングが可能になる。例えば、上述した第１のポイントにおいて、この拡張したblock information descriptorを参照して、視聴部分が高精細化されているG-PCCストリームの選択処理を行ってもよい。
また、空間位置情報シグナリングの変形例として、object boxのx, y, z軸の各辺のサイズをシグナルし、block_offset_x, block_offset_y, block_offset_z, block_size_x, block_size_y, block_size_を、そのサイズに対する相対値でシグナルしてもよい。
さらに、部分G-PCCストリームの精細度情報を、lod information descriptor (schemeIdUri=”urn:mpeg:mepgI:gpcc:lod_information:2018”のSupplementalProperty)を新規定義して、Representationにシグナルする。例えば、gpcc:lodInfo要素のlod_ranking属性に、精細度ランキング情報をシグナルする。精細度ランキングは、値が小さいほど精細度が高いことを示す。
図１３には、部分G-PCCストリームの精細度情報のシグナリングの一例が示されており、図１３において太字で記載されている個所に部分G-PCCストリームの精細度情報がシグナルされている。
ここで、各Adaptation Setのblock information descriptorのシグナリングは、上述した図１１で示したものと同様である。
なお、精細度情報として、精細度ランキング情報ではなく、octree depthの値をシグナルしてもよい。
また、図１３に示した例において、クライアントがＸ＋方向から視聴している場合、図１２におけるblock bの部分G-PCCストリームを参照するAdaptation Set@id=”2”は高精細（lod_rankingの値が小さいもの）のRepresentationを選択する。さらに、この場合、block aの部分G-PCCストリームを参照するAdaptationSet@id=”1”は低精細（lod_rankingの値が大きいもの）のRepresentationを選択する。そして、それらの選択に従って、部分G-PCCストリームを取得することで、ネットワーク帯域幅を有効活用した視聴部分の高精細化ができる。例えば、Representation@id=”1-2”とRepresentation@id=”2-1”との２つのRepresentationが参照する部分G-PCCストリームを取得する。
＜システム構成＞
図１４および図１５を参照して、本技術を適用したデータ生成装置およびデータ再生装置のシステム構成について説明する。
図１４には、データ生成装置の構成例を示すブロック図が示されている。
図１４に示すように、データ生成装置１１は、制御部２１、メモリ２２、ファイル生成部２３を備えて構成される。例えば、メモリ２２には、制御部２１がファイル生成部２３を制御するのに必要な各種のデータが記憶されており、制御部２１は、そのデータを参照して、ファイル生成部２３におけるファイルの生成を制御する。
ファイル生成部２３は、データ入力部３１、データ符号化・生成部３２、MPD（Media Presentation Description）ファイル生成部３３、記録部３４、および出力部３５を備えて構成される。例えば、データ入力部３１に入力されたデータは、データ符号化・生成部３２およびMPDファイル生成部３３に供給される。そして、データ符号化・生成部３２で生成されたファイルおよびMPDファイル生成部３３で生成されたMPDが、記録部３４を介して出力部３５から出力され、例えば、記録メディアなどに記録される。
データ符号化・生成部３２は、前処理部３６、符号化部３７、およびファイル生成部３８を有している。
前処理部３６は、データ入力部３１から入力されるPoint Cloudオブジェクトを分割し、各部分Point Cloudオブジェクトを生成するのと同時に、空間位置情報およびグルーピング情報を生成する処理を実行する。
符号化部３７は、各部分Point CloudオブジェクトをG-PCC符号化し、部分G-PCCストリームを生成するのと同時に、精細度情報を生成する。
ファイル生成部３８は、各部分G-PCCストリームを個別のファイルに格納して、記録部３４に供給する。
図１５には、データ再生装置の構成例を示すブロック図が示されている。
図１５に示すように、データ再生装置１２は、制御部４１、メモリ４２、および再生処理部４３を備えて構成される。例えば、メモリ４２には、制御部４１が再生処理部４３を制御するのに必要な各種のデータが記憶されており、制御部４１は、そのデータを参照して、再生処理部４３におけるPoint Cloudの再生を制御する。
再生処理部４３は、取得部５１、表示制御部５２、データ解析・復号部５３、および表示部５４を備えて構成される。例えば、取得部５１により取得された、即ち、記録メディアなどから読み出されたファイルおよびMPDは、データ解析・復号部５３に供給される。そして、表示制御部５２による表示制御に従ってデータ解析・復号部５３において生成された表示画面が、表示部５４において表示される。
データ解析・復号部５３は、ファイル解析部５５、復号部５６、および表示情報生成部５７を有している。
ファイル解析部５５は、上述したような各種の情報がシグナリングされたメタデータを解析する。
また、復号部５６は、部分G-PCCストリームを復号する処理を実行する。
また、表示情報生成部５７は、空間位置情報に基づいてPoint Cloudオブジェクトを再構成し、Point Cloudをレンダリングして表示画面を生成して、表示部５４に表示させる。
＜生成処理および再生処理＞
図１６は、データ生成装置１１のデータ符号化・生成部３２が、部分G-PCCストリームが格納されたファイルを生成する生成処理を説明するフローチャートである。
ステップＳ１１において、前処理部３６は、Point Cloudオブジェクトを分割し、各部分Point Cloudオブジェクトを生成するのと同時に、空間位置情報およびグルーピング情報を生成する。
ステップＳ１２において、符号化部３７は、各部分Point CloudオブジェクトをG-PCC符号化し、部分G-PCCストリームを生成するのと同時に、精細度情報を生成する。
ステップＳ１３において、ファイル生成部３８は、各部分G-PCCストリームを個別のファイルに格納して、記録部３４に供給する。
ステップＳ１４において、MPDファイル生成部３３は、各部分G-PCCストリームの空間位置情報、グルーピング情報、および精細度情報を含むMPDを生成して、記録部３４に供給する。そして、記録部３４により、部分G-PCCストリームが格納されたファイルとともにMPDが出力部３５から出力された後、処理は終了される。
図１７は、データ再生装置１２が、部分G-PCCストリームが格納されたファイルを再生する再生処理を説明するフローチャートである。
ステップＳ２１において、取得部５１は、MPDを取得する。
ステップＳ２２において、表示制御部５２は、ステップＳ２１で取得部５１が取得したＭＰＤの空間位置情報に基づいて、現在の視野から見える部分G-PCCストリームのAdaptation Setと、見えない部分G-PCCストリームのAdaptation Setとを識別する。
ステップＳ２３において、表示制御部５２は、ＭＰＤの精細度情報に基づいて、現在の視点位置および視野方向から見える部分G-PCCストリームについて、高精細なRepresentationを選択する。
ステップＳ２４において、表示制御部５２は、ＭＰＤの精細度情報に基づいて、現在の視点位置および視野方向から見えない部分G-PCCストリームについて、低精細なRepresentationを選択する。
ステップＳ２５において、取得部５１は、ステップＳ２３およびＳ２４で表示制御部５２が選択したRepresentationから参照される部分G-PCCストリームを全て取得して、データ解析・復号部５３に供給する。
ステップＳ２６において、データ解析・復号部５３では、復号部５６が、取得した部分G-PCCストリームをデコードし、表示情報生成部５７が、空間位置情報に基づいてPoint Cloudオブジェクトを再構成して表示画面をレンダリングする。そして、表示情報生成部５７によりレンダリングされた表示画面が、表示部５４に表示される。
ステップＳ２７において、表示制御部５２は、ストリームの終端であるか否かを判定する。ステップＳ２７において、表示制御部５２が、ストリームの終端でないと判定した場合、処理はステップＳ２８に進む。
ステップＳ２８において、表示制御部５２は、視野方向が変更されたか否かを判定し、視野方向が変更されていないと判定した場合には処理はステップＳ２６に戻り、視野方向が変更されたと判定した場合には処理はステップＳ２２に戻って、以下、同様の処理が繰り返して行われる。
一方、ステップＳ２７において、表示制御部５２は、ストリームの終端であると判定した場合、処理は終了される。
ところで、前述した空間位置情報のシグナリングのみでは、特定の視聴方向から視聴できる部分G-PCCストリームを全て識別できないことが発生すると想定される。
例えば、図１８においてハッチングが施されている領域は、部分G-PCCストリームa内に存在するが、図１８において矢印で示す視聴方向から視聴可能である。このとき、視聴可能部分を高精細化するためには、空間位置情報をもとに視聴部分として識別される部分G-PCCストリームbに加え、部分G-PCCストリームaも高精細で取得する必要がある。しかしながら、前述した空間位置情報のシグナリングのみでは、部分G-PCCストリームaは低精細で取得してしまうため、高品位なG-PCCストリーム配信とならない。
そこで、Point Cloudオブジェクトのローカル座標系を基準とした方向ごとに、表示に必要な部分G-PCCストリーム全てを識別するための情報を付加する。
例えば、この部分G-PCCストリームの方向対応情報を、block information descriptorを拡張してシグナルする。具体的には、gpcc:directionInfo要素のdirection属性を追加する。
図１９には、部分G-PCCストリームの方向対応情報をシグナリングする一例が示されており、図１９において太字で記載されている個所に部分G-PCCストリームの方向対応情報がシグナルされている。
例えば、Adaptation Set@id=”1”は、図１８における部分G-PCCストリームaに該当し、X+, Y+, X-, Y-, Z+, Z-の全方向を視聴する場合において必要な部分G-PCCストリームであることを示している。また、Adaptation Set@id=”2”は、部分G-PCCストリームbに該当し、X+, Y+, Y-, Z+, Z-の方向を視聴する場合において必要な部分G-PCCストリームであることを示し、X-の方向を視聴する場合には不要である。
このように、方向対応情報をシグナルすることで、クライアントの視聴方向に必要な部分G-PCCストリームを正しく識別し、全て高精細で取得することができる。
なお、１つの部分G-PCCストリームが複数の方向に対応する場合において、direction属性に空白区切りで方向情報をシグナルせずに、複数のgpcc:directionInfo要素をシグナルしてもよい。また、部分G-PCCストリームの方向対応情報のみ、個別のdescriptorでシグナルしてもよい。
さらに、gpcc:directionInfo要素がシグナルされている場合、gpcc:blockInfo要素をシグナルしなくてもよいし、一緒に利用してもよい。一緒に利用する場合、gpcc:directionInfo要素を参照して視聴部分の表示に必要な部分G-PCCストリームを全て識別した上で、gpcc:blockInfo要素を参照してblockごとの細かな精細度変更を行うことができる。
ところで、時間経過とともにPoint Cloudオブジェクトの外形が大きく変わり、ポイントがない、空の部分G-PCCストリームができる場合において、視聴部分に応じた取得処理が適切に行えないことがあるということが懸念される。
図２０を参照して、動的に変化する空間位置情報および方向対応情報の必要性について説明する。
図２０の上側に示すように、クライアントは視聴部分を高精細化する場合、視聴部分に相当するblock bおよびblock dをそれぞれ含む２つの部分G-PCCストリームを、高精細（depth=10）で取得することになる。その後、図２０の下側に示すように、時刻ｔＮにおいてPoint Cloudオブジェクトの外形が変化した場合、block bは空であるにもかかわらず、block bを含む部分G-PCCストリームを高精細で取得することになる。
このため、時刻ｔＮにおける視聴部分を高精細化するためには、block aおよびblock dをそれぞれ含む部分G-PCCストリームを取得する必要がある。
そこで、動的に変化する方向対応情報および空間位置情報を付加する。具体的には、dynamic block information descriptor (schemeIdUri=”urn:mpeg:mepgI:gpcc:dynamic_block_information:2018”のSupplementalProperty)を新規定義して、AdaptationSetにシグナルする。
例えば、gpcc:dynamicBlockInfo要素のblock_info_id属性には、このAdaptation Set内のRepresentationが参照する部分G-PCCストリームに紐づく、動的に変化する空間位置情報および方向対応情報をシグナルするtimed metadataを参照するRepresentationのidがシグナルされる。なお、object_id属性は、前述の通りである。
また、timed metatadataを参照するRepresentationには、このRepresentationを動的に変化する空間位置情報および方向対応情報が適用される部分G-PCCストリームのRepresentationに紐づけるため、Representation@associationIdおよびRepresentation@associationTypeを利用する。さらに、associationTypeには、動的に変化する空間位置情報および方向対応情報であることを示す、”dbif”をシグナルする。
図２１には、動的に変化する空間位置情報および方向対応情報のシグナリングの一例が示されており、図２１において太字で記載されている個所に、動的に変化する空間位置情報および方向対応情報がシグナルされている。
即ち、上記timed metadataのsampleには、各時刻における方向対応情報をシグナルする。これにより、時刻ごとに各blockがどの方向に対応するのかの情報をシグナルできる。
図２２には、timed metadataのsample entryのシンタックスの一例が示されており、図２３には、timed metadataのsampleのシンタックスの一例が示されている。
なお、directionフィールドのセマンティクスは、block information descriptorのgpcc:directionInfo要素のdirection属性と同様である。
また、図２４に示すように、各時間における空間位置情報をシグナルしてもよい。これにより、動的に空間分割方法を変更できるため、空となるblockが生じない空間分割を行うことができる。
なお、各フィールドのセマンティクスは、block information descriptorのgpcc:blockInfo要素の同名属性と同様である。
このようなシグナリングにより、クライアントは、動的に変わる空間位置情報および方向対応情報を参照し、Point Cloudオブジェクトの外形が動的に大きく変わる場合においても、視聴部分を高精細化するための部分G-PCCストリームを適切に取得可能となる。
図２５および図２６を参照して、ISOBMFFの拡張について説明する。
例えば、ISOBMFFファイルの各trackに部分G-PCCストリームを格納する。このとき、１つのPoint Cloudオブジェクトを構成するtrack群を明示するために、ISOBMFFで定義されているtrack group機能を利用してグルーピングする。
具体的には、図２５に示すように、TrackGroupTypeBoxを拡張し、BlockGroupBox (‘blgp’)を新規に定義する。即ち、同じtrack_group_idのBlockGroupBoxがシグナルされるtrackは、同一のPoint Cloudオブジェクトを構成する部分G-PCCストリームを格納していることを示す。
例えば、BlockGroupBoxには、DASH MPD拡張と同様、部分G-PCCストリームの空間位置情報、精細度情報、方向対応情報、並びに、動的に変化する空間位置情報および方向対応情報を持つtimed metadataへの参照情報がシグナルされる。なお、動的に変化する空間位置情報および方向対応情報を持つtimed metadataを格納するtrackは、refrence_type=’dbif’のtrack referenceによって、そのtimed metadataが適用される部分G-PCCストリームを格納するtrackに紐づけられる。
これにより、クライアントは、このblgpの情報を参照してtrack選択を行い、視聴部分に相当する部分G-PCCストリームの優先デコードが可能となる。
図２６には、BlockGroupBoxに部分G-PCCストリームの空間位置情報をシグナルする場合のシンタックスが示されている。ここで、各フィールドのセマンティクスは、block information descriptorのgpcc:blockInfo要素の同名属性と同様である。
なお、track group機能ではなく、EntityToGroupBoxを用いてグルーピングをシグナルしてもよい。また、精細度情報は、個別のBoxとしてtrackのsample entryにシグナルしてもよい。また、動的に変化する空間位置情報および方向対応情報はsample groupでシグナルしてもよい。
さらに、空間位置情報とその空間位置毎の精細度情報を有する新規Boxを定義すると、1 G-PCCストリームの空間位置ごとの精細度情報シグナリングが可能になる。例えば、上述した第１のポイントにおいて、このBoxを参照して、視聴部分が高精細化されているG-PCCストリームを格納しているtrackの選択処理を行ってもよい。
図２７乃至図２９を参照して、空間分割により生成した部分G-PCCストリームを配信する第２のポイントの第２の手法について説明する。
図２７に示すように、１つのPoint Cloudオブジェクトを、低精細な全体Point Cloudオブジェクトと、その一部分を高精細にするための部分Point Cloudオブジェクトに階層化し、それぞれを符号化して部分G-PCCストリームを生成・配信する方法である。図２７には、Point Cloudオブジェクトを、低精細な全体Point Cloudオブジェクトと、２つの部分Point Cloudオブジェクトとに階層化する例が示されている。
例えば、一部分を高精細化する部分G-PCCストリームには、以下のバリエーションがある。
・部分G-PCCストリーム単体で高精細となるもの（バリエーション１）
・部分G-PCCストリーム単体では低精細であり、低精細な全体G-PCCストリームと組み合わせる事で高精細な部分を構成するもの（バリエーション２）
なお、バリエーション２の一部分を高精細化する部分G-PCCストリームは、低精細な全体G-PCCストリームとは重複しないポイントを持つ。
バリエーション１については、第２のポイントの第１の手法と同様のシグナリングを利用することで、クライアントは、全体G-PCCストリーム、部分G-PCCストリームの空間位置情報、グルーピング情報、および精細度情報を識別でき、視聴部分を高精細にするための全体・部分G-PCCストリームを取得することができる。
バリエーション２についても同様のシグナリングを利用することはできるが、クライアントは視聴部分を高精細化するために、組み合わせるべき部分G-PCCストリームと全体G-PCCストリームとを識別することができない。そのため、クライアントは、視聴部分を高精細化するための適切なG-PCCストリームを取得することができない。
そこで、組み合わせて高精細化できる部分G-PCCストリームと全体G-PCCストリームとを紐づける情報をシグナルする。これにより、クライアントは、この情報を参照することで、バリエーション２においても視聴部分を高精細にするための部分G-PCCストリームを取得することができる。
次に、図２８および図２９を参照して、DASH MPDの拡張について説明する。
例えば、MPEG-DASHで規定されるassociationIdおよびassociationTypeを利用して、組み合わせることで高精細な部分を構成する部分G-PCCストリームと全体G-PCCストリームを紐づける。
そして、部分G-PCCストリームのRepresentationにおいて、associationIdには、組み合わせる全体G-PCCストリームのRepresentation@idをシグナルする。さらに、associationTypeには、紐づくRepresentationが部分G-PCCストリームと組み合わせることで高精細化が可能な全体G-PCCストリームであることを示す”pbas”をシグナルする。
また、両者を組み合わせた結果としての精細度情報を、上述した第２のポイントの第１の手法で定義したlod information descriptorを拡張し、gpcc:combinedAreaLodInfoでシグナルする。さらに、combined_rep_id属性には、組み合わせる全体G-PCCストリームのRepresentation@idをシグナルし、lod_ranking属性では、両者を組み合わせた結果としての精細度情報をシグナルする。
図２８には、組み合わせられる各G-PCCストリームの空間位置情報のシグナリングの一例が示されており、図２８において、太字で記載されている個所に、組み合わせられる各G-PCCストリームの空間位置情報がシグナルされている。
図２９には、図２８に示すようにシグナリングされる空間位置情報のイメージ図が示されている。
なお、associationId, associationTypeによる紐づけがなされていない場合、部分G-PCCストリーム単体で高精細となることを示す。
また、部分G-PCCストリームが低精細であり、単独での再生を禁止したい場合、associationIdの代わりにdependencyIdで紐づける。または、SupplementalPropertyもしくはEssentialPropertyを用い、単独再生を禁止するdescriptorを定義してもよい。
さらに、associationId、associationTypeを用いて、全体G-PCCストリームから部分G-PCCストリームを参照してもよい。
このシグナリングにより、クライアントは組み合わせて視聴部分を高精細化するための適切なG-PCCストリーム取得することができる。
なお、このシグナリングは、低精細な部分G-PCCストリーム同士を組み合わせることで高精細な部分を構成する場合にも、利用可能である。
次に、図３０および図３１を参照して、ISOBMFFの拡張について説明する。
図３０に示すように、ISOBMFFファイルの各trackに階層化で生成した部分G-PCCストリームを格納する。このとき、ISOBMFFで定義されているtrack referenceの仕組みを利用することで、組み合わせることで高精細な部分を構成する部分G-PCCストリームと全体G-PCCストリームを紐づける。なお、reference_typeは’pbas’とする。
例えば、track#3は、低精細な全体G-PCCストリーム、track#1およびtrack#2は、それぞれ全体Point Cloudオブジェクトの異なる部分に相当する部分G-PCCストリームを格納している。そして、reference_type=’pbas’のtrefにより、track#3の全体G-PCCストリームと組み合わせて高精細な部分を構成することが示されている。
これにより、クライアントは、このtrack referenceのシグナリングにより、組み合わせて視聴部分を高精細化するための適切なG-PCCストリームを格納するtrackを選択、再生することができる。
さらに、複数のG-PCCストリームを組み合わせた結果としての精細度情報をシグナルするCombinedAreaLodInfoBox(‘cloi’)を新規定義して、上述した第２のポイントの第１の手法で定義したBlockGroupBoxにシグナルする。
図３１には、CombinedAreaLodInfoBox(‘cloi’)のシンタックスが示されている。
図３１に示すように、combined_track_idフィールドで示されるtrackと組み合わせたときの精細度情報を、lod_rankingフィールドでシグナルする。lod_rankingフィールドのセマンティクスは、上述した第１のポイントのDirectionInformationBoxの同名フィールドと同様である。
なお、上述した第２のポイントは、G-PCCのみではなく、Video based PCC (V-PCC)符号化されたストリームや、meshストリームおよびtextureストリームで構成されるものなど、3Dオブジェクト全般に適用可能である。
＜第１および第２のポイントの変形例＞
ここで、第１および第２のポイントの変形例について説明する。
例えば、第１のポイントにおいて、Voxelを区切る細かさを変更し、精細度を変える単位が、Point Cloudオブジェクトの中で独立してエンコードおよびデコードできるポイントの集合であってもよい。このポイントの集合をbrickと呼ぶ。なお、brickは、現在MPEGで議論中の符号化ツールであるtileとしてもよい。tileはsliceの集合であり、sliceは独立してエンコードおよびデコードできるポイントの集合である（上述の非特許文献２参照）。
また、第２のポイントにおいて、部分G-PCCストリームが１つ、もしくは複数のbrickから構成されるように符号化されていてもよい。
いずれの場合も、第１および第２のポイントで上述したようなシグナリングが適用可能である。
さらに、1 G-PCCストリームを複数のbrickから構成されるように符号化することで、視聴部分に相当するbrickから優先的にデコード、レンダリングすることが可能になる。これは、デコードおよびレンダリングのパフォーマンスの低いクライアントにとって価値のあるユースケースである。
また、従来のようにMPEGにおけるtileを用いる技術では、G-PCCストリーム内のbrickデータの空間位置情報はG-PCCストリームにシグナルすることが想定されている。この場合、視聴部分に相当するbrickデータにアクセスするには、一度G-PCCストリームをデコードする必要があり、処理のオーバーヘッドが大きい。また、視聴部分に相当するbrickを選択・デコードする場合において、上述した第２のポイントの第１の手法と同様に、brickの空間位置情報を、G-PCCストリーム内のbrickを構成するデータ単位で紐づける必要がある。
そこで、図３２乃至図３７を参照して、brickの空間位置情報を、G-PCCストリーム内のbrickを構成するデータ単位で紐づけるためのISOBMFFの拡張について説明する。
例えば、ISOBMFFで定義されているsample groupの機能を利用し、brickの空間位置情報を、G-PCCストリーム内のbrickを構成するデータ単位で紐づけることができる。具体的には、brickごとの空間位置情報をシグナルするBrickGroupEntryと、そのbrickごとの空間位置情報をG-PCCストリーム内のbrickを構成するデータ単位で紐づけるためのUnitMapEntryを新たに定義する。
図３２には、BrickGroupEntryのシンタックスが示されており、図３３には、UnitMapEntryのシンタックスが示されている。
図３２および図３３に示すシンタックスにおいて、BrickGroupEntryのbrick_offset_x, brick_offset_y, brick_offset_z, brick_size_x, brick_size_y, brick_size_zのセマンティクスは、上述した第２のポイントの第１の手法におけるBlockGroupBoxのblock_offset_x, block_offset_y, block_offset_z, block_size_x, block_size_y, block_size_zとそれぞれ同一である。
また、UnitMapEntryのunit_indexは、groupIDで紐づくBrickGroupEntryが適用されるG-PCCストリーム内のbrickを構成するデータ単位のインデックス情報を示す。
このunit_indexは、groupIDで紐づくBrickGroupEntryが適用されるG-PCCストリーム内のbrickを構成するGeometry bitstreamおよびAttribute bitstreamについて、それぞれを構成するデータ単位ごとに割り当てられてもよい。
なお、MPEGで議論中の符号化ツールであるtileを適用する場合、BrickGroupEntryのbrick_offset_x, brick_offset_y, brick_offset_z, brick_size_x, brick_size_y, brick_size_zでシグナルされる領域は、tileのbounding boxの領域、または、複数tileのbounding boxの合計領域と一致する。
図３４には、BrickGroupEntryおよびUnitMapEntryの運用例が示されている。
図３４に示すように、G-PCCストリームの1 Point Cloudフレームを1 ISOBMFF sampleとし、brickを構成するデータ単位はGeometry bitstream (Geom)と紐づく、１つまたは複数のAttribute bitstream (Attr)である。
例えば、クライアントが視聴部分に相当するbrickのみデコードしようとする場合、まず、grouping_type=’blif’のSampleGroupDescriptionBoxの各BrickGroupEntryを参照し、所望のbrickのgroupIDを識別する。次に、grouping_type=’unim’のSampleToGroupBoxおよびSampleGroupDescriptionBoxを参照し、各sampleが紐づくUnitMapEntryに所望のbrickのgroupIDのunit_indexが含まれていれば、sample内のそのunitのみデコードする。
このシグナリングにより、図３５に示すように、オブジェクトの動きに合わせて動的にbrick構成を変更し、空のbrickをなくすことができる。
そして、これらのシグナリングを参照することで、視聴部分に相当するbrickデータに直接アクセスし、優先的にデコード、レンダリングすることが可能になる。
さらに、変形例として、brickごとに分割して個別にISOBMFF trackに格納してもよい。例えば、brick base trackおよびbrick trackの２種類を定義する。
brick base trackは、G-PCCストリームは格納せず、そのsample entryに全体G-PCCストリームのproile，level、およびbrick trackに格納されるG-PCCストリームをデコードするために必要な共通のパラメータセットを格納する。なお、sample entryのタイプは、’gpbb’とする。
brick trackは、1つまたは複数のbrickからなるG-PCCストリームを格納し、そのsample entryに、trackに格納するG-PCCストリームのprofile, level、および格納するG-PCCストリームのみのデコードに必要なパラメータセットを格納する。なお、sample entryのタイプは、’gpcb’とする。
さらに、brick base trackからbrick trackへreference_type=’gpbt’のtrack referenceをシグナルし、brick trackからbrick base trackへreference_type=’gpbb’のtrack referenceをシグナルする。
図３６には、brick base trackおよびbrick trackの構成図が示されている。
図３６に示すようなシグナリングにより、brick trackに格納されるパラメータセット、および紐づくbrick base trackに格納されるパラメータセットを参照することで、brick trackを単独デコードできる。つまり、視聴部分に相当するbrickデータを含むbrick trackを選択し、優先的にデコード、レンダリングすることが可能になる。
さらに、brick base trackから参照されるbrick trackに格納されるG-PCCストリームのsampleをもとに全体G-PCCストリームを再構成し、single decoderでデコードできる。
なお、各brick trackをtrack groupまたはEntityToGroupBoxでグルーピングし、brick base trackからのtrack referenceで、track groupの場合にはtrack_group_idを参照し、EntityToGroupの場合にはgorup_idを参照してもよい。
このようなISOBMFF拡張によるシグナリングは、brickで構成されるストリームのみでなく、上述した第２のポイントで言及した部分G-PCCストリームに対しても同様に適用可能である。この際、brickをblockとみなせばよい。
また、図３７に示すように、brickの空間位置情報（brick_offset_x, brick_offset_y, brick_offset_z, brick_size_x, brick_size_y, brick_size_z）を、elementary streamのhigh level syntaxを拡張してシグナルしてもよい。
例えば、G-PCCストリーム中のbrickを構成するデータユニットは、brick_idを通じて空間位置情報と紐づけられる。
これにより、クライアントは、G-PCCストリームをデコードする際、このbrick_inventoryを参照することで全体のbrick構成を容易に識別でき、brick_idを通じて視聴部分に相当するbrickのデータユニットを識別して、デコードすることができる。
＜第３のポイント＞
図３８乃至図４３を参照して、Point Cloudオブジェクトの低精細な部分のレンダリング処理を指定する第３のポイントについて説明する。
例えば、Point Cloudオブジェクトについて、低精細な部分をそのままレンダリングすると、例えば、Point Cloudオブジェクトの反対側が透けて見えるなど、主観品質が低下する。このとき、低精細な部分のポイントのサイズを大きくするなどしてレンダリングすることで、主観品質を向上できる。
従って、コンテンツ生成側が、低精細な部分の主観品質向上のために必要なレンダリング処理を指定し、クライアント側でそのレンダリング処理を実行することで、コンテンツ生成側の意図に沿った形で、Point Cloudオブジェクトの低精細な部分の主観品質を向上することができる。
しかしながら、主観品質向上のためのレンダリングに必要なパラメータはG-PCCストリーム内にシグナルすることが想定されており、クライアントはG-PCCストリーム選択時において、主観品質向上レンダリング処理が必要か否か識別できない。
そのため、レンダリング処理の実行が必要か否かを識別できるのはストリーム取得後になってしまい、クライアントが主観品質向上のためのレンダリング処理に非対応であった場合には、適切なレンダリングを実行することができない。もしくは、主観品質向上のためのレンダリング処理不要な別のストリーム取得し直すことになり、処理効率が低下することになる。
従って、低精細なG-PCCストリームの主観品質向上のためのレンダリング処理が必要か否かを識別するための情報をシグナルすることによって、適切なレンダリングを実行できないことや、処理効率が低下することなど回避することができる。
これにより、クライアントは自身の主観品質向上レンダリング処理能力を考慮し、処理できるならば低精細なG-PCCストリームを取得し、主観品質向上レンダリング処理を行うことで、主観品質は維持しつつ、G-PCCストリーム配信に必要なネットワーク帯域幅を削減することができる。
ここで、DASH MPDの拡張について説明する。
例えば、G-PCCストリームのレンダリング処理方法を、rendering information descriptor (schemeIdUri=”urn:mpeg:mepgI:gpcc:rendering_information:2018”のEssentialProperty)を新規定義して、Representationにシグナルする。
そして、gpcc:renderingInfo要素のtype属性で、レンダリング処理方法をシグナルする。type=0のときは、一般的な処理手法である、Voxel形状でレンダリングすることを示し、type=1のときは、G-PCCストリーム内でシグナルされたパラメータに従いレンダリング処理を実行すること示す。G-PCCストリーム内のパラメータは、例えば、Voxelに内接する球としてレンダリングする、等である。
図３８には、レンダリング処理方法のシグナリングする一例が示されており、図３８において、太字で記載されている個所にレンダリング処理方法がシグナルされている。
例えば、主観品質向上レンダリング処理に対応しているクライアントであれば、帯域が狭い場合において、id=1-3のRepresentation、つまり、より低精細なストリームを取得でき、G-PCCストリーム配信に必要なネットワーク帯域幅を削減できる。
なお、gpcc:renderingInfo要素のtypeでシグナルされた処理を強制するのではなく、コンテンツ生成側のおすすめ処理としてもよい。
次に、ISOBMFFの拡張について説明する。
例えば、ISOBMFF trackにおいて、主観品質向上レンダリング処理の情報をポストデコーディング処理情報としてシグナルする。
具体的には、sample entry下の、ISOBMFFで定義されたRestrictedSchemeInformationBox (‘rinf’) を用いる。rinfは、デコード後のポストプロセス情報を格納するBoxである。rinf下のSchemeTypeBox (‘schm’) のscheme_typeは、主観品質向上レンダリング情報が格納されていることを示すために、’rndi’とする。
図３９には、RenderingInformationBoxのシグナル例が示されている。
図３９に示すように、SchemeInformationBox (‘schi’)は、schmのscheme_typeで指定された情報が格納されるBoxであり、scheme_type=’rndi’に対応するRenderingInformationBox (‘rndi’) をシグナルされる。
図４０には、RenderingInformationBoxのシンタックスの一例が示されている。
なお、typeフィールドのセマンティクスは、rendering information descriptorのgpcc:renderingInfo要素の同名属性と同様である。
図４０に示すようなシグナリングにより、クライアントはrndiのtypeを識別でき、適切なレンダリング処理を実行できる。また、rndiのtypeでシグナルされるレンダリング処理を実行できない場合には、そのtrackを選択せず、同一ISOBMFFファイル内の他のtrackを選択するという処理が可能になる。
ここで、第３のポイントの変形例について説明する。
例えば、上述した第２のポイントの第２の手法のように階層化により生成した部分G-PCCストリーム配信に対して適用する場合、他のG-PCCストリームと組み合わせて高精細化される部分は、主観品質向上のためのレンダリング処理が不要である。この時、クライアントはPoint Cloudオブジェクトの部分ごとに主観品質向上のためのレンダリング処理を変更する必要がある。よって、適切なレンダリング処理を実行できるクライアントのみが前述のG-PCCストリームを取得できるようにするための情報を付加する。
例えば、他のG-PCCストリームと組み合わせることで高精細化される部分の処理タイプをシグナルすることができる。
ここで、DASH MPDの拡張について説明する。
例えば、rendering information descriptorを拡張し、他のG-PCCストリームと組み合わせることで高精細化される部分の処理タイプをシグナルする。
具体的には、gpcc:combinedAreaRenderingInfo要素を追加し、そのcombined_rep_id属性で組み合わせるG-PCCストリームのRepresentation@idをシグナルする。また、gpcc:combinedAreaRenderingInfo要素のtype属性で、組み合わせることで高精細化される部分の処理タイプをシグナルする。なお、セマンティクスはgpcc:renderingInfo要素のtype属性と同一である。
図４１には、高精細化される部分の処理タイプのシンタックスが示されている。図４１において太字で記載されている個所に、高精細化される部分の処理タイプがシグナルされている。
図４１に示すシグナリングにより、gpcc:renderingInfo要素とgpcc:combinedAreaRenderingInfo要素のtypeを踏まえ、クライアント処理能力、例えば、Point Cloudオブジェクトの部分ごとに主観品質向上のためのレンダリング処理を変更して適用できるクライアントであれば、より低精細なストリームを取得できる。
次に、ISOBMFFの拡張について説明する。
例えば、前述のRenderingInformationBox (‘rndi’)を拡張し、combined_track_existsフィールド、comnbined_track_idフィールド、およびcombined_area_typeフィールドをシグナルする。
また、combined_track_existsフィールドは、組み合わせることで高精細な部分を構成するG-PCCストリームにreference_type = ’pbas’のtrack referenceで紐づいているか否かを示す。また、combined_trak_idフィールドは、組み合わせるG-PCCストリームのtrack_idをシグナルする。combined_area_typeフィールドで、組み合わせることで高精細化される部分の処理タイプをシグナルする。
これにより、クライアントは、これらの情報を識別し、適切なレンダリング処理を実行することができる。
図４２には、combined_track_existsフィールド、comnbined_track_idフィールド、およびcombined_area_typeフィールドを追加したシンタックスが示されている。図４２において太字で記載されている個所に、combined_track_existsフィールド、comnbined_track_idフィールド、およびcombined_area_typeフィールドがシグナルされている。
さらに、組み合わせることで高精細化される部分について、位置が一致し、重なるポイントがある場合において、組み合わせるG-PCCストリームのどちらのポイントをレンダリングするかの情報をシグナルしてもよい。この情報により、クライアントはコンテンツ生成側の意図に沿ったレンダリングを実行することが可能となる。
具体的には、RenderingInformationBoxをさらに拡張し、priority_flagフィールドを追加する。そして、priority_flag=1の場合には、そのRenderingInformationBoxを持つtrackのG-PCCストリームがcombined_track_idのtrackのG-PCCストリームよりもレンダリングの優先度が高いことを示し、重なるポイントについては、priority_flag=1のtrackのG-PCCストリームのポイントのみレンダリングされる。一方、priority_flag=0の場合には逆に、重なるポイントについてはcombined_track_idのtrackのG-PCCストリームのポイントのみレンダリングされる。
図４３には、priority_flagフィールドを追加したシンタックスが示されており、図４３において太字で記載されている個所に、priority_flagフィールドがシグナルされている。
ここで、図４４には、上述したSample Group概要が示されている。
図４４に示すSampleToGroupBoxのgrouping_typeは、紐づけられるSampleGroupDescriptionBoxのgrouping_typeを示す。また、1 entryにつき、sample_countとgroup_description_indexがシグナルされる。そして、group_description_indexは、紐づくGroupEntryのindexを示し、sample_countは、そのGroupEntryに属するsample数を示す。
以上のように、本技術は、Point CloudオブジェクトをGeometryベースで符号化したPoint CloudストリームであるG-PCCストリームを、ユーザの視聴部分に応じて配信する際に、第１のポイントとして、１つのPoint Cloudオブジェクトの部分毎に精細度を変えて符号化したG-PCCストリームを配信することができる。または、第２のポイントとして、１つのPoint Cloudオブジェクトを複数の部分オブジェクトに分割し、それらの部分オブジェクトそれぞれの精細度を変えて符号化した部分G-PCCストリームを配信することができる。
そして、第１のポイントでG-PCCストリームを配信するときに、G-PCCストリームに対して高精細となっている方向情報および精細度情報を付加することにより、クライアントは、それらの情報を参照し、視聴部分が高精細となるG-PCCストリームを取得することができる。
または、第２のポイントで部分G-PCCストリームを配信するときに、各部分G-PCCストリームに対して空間位置情報および精細度情報を付加することにより、クライアントは、それらの情報を参照し、視聴部分が高精細となるよう部分G-PCCストリームを取得することができる。
さらに、第３のポイントとして、低精細な部分、つまり、ポイントが疎になっている部分の主観的品質を向上させるために有効なレンダリング処理が必要か否かの情報を付加することができる。これにより、クライアントは、そのレンダリング処理の実行が可能であれば、より低精細な部分を含むG-PCCストリームを取得することで、G-PCCストリーム配信に必要なネットワーク帯域幅を削減することができる。
なお、これらの付加される情報は、DASH MPDまたはISOBMFFを拡張することによりシグナルされる。
そして、以上のようなポイントによって、ユーザの視聴部分が高精細となり、ユーザの視聴部分以外は低精細となるようにG-PCCストリームを配信することで、ネットワーク帯域幅を有効活用し、高品位、つまり途切れず高精細なG-PCCストリーム配信を実現することができる。
＜コンピュータの構成例＞
次に、上述した一連の処理（情報処理方法）は、ハードウェアにより行うこともできるし、ソフトウェアにより行うこともできる。一連の処理をソフトウェアによって行う場合には、そのソフトウェアを構成するプログラムが、汎用のコンピュータ等にインストールされる。
図４５は、上述した一連の処理を実行するプログラムがインストールされるコンピュータの一実施の形態の構成例を示すブロック図である。
プログラムは、コンピュータに内蔵されている記録媒体としてのハードディスク１０５やROM１０３に予め記録しておくことができる。
あるいはまた、プログラムは、ドライブ１０９によって駆動されるリムーバブル記録媒体１１１に格納（記録）しておくことができる。このようなリムーバブル記録媒体１１１は、いわゆるパッケージソフトウェアとして提供することができる。ここで、リムーバブル記録媒体１１１としては、例えば、フレキシブルディスク、CD-ROM(Compact Disc Read Only Memory)，MO(Magneto Optical)ディスク，DVD(Digital Versatile Disc)、磁気ディスク、半導体メモリ等がある。
なお、プログラムは、上述したようなリムーバブル記録媒体１１１からコンピュータにインストールする他、通信網や放送網を介して、コンピュータにダウンロードし、内蔵するハードディスク１０５にインストールすることができる。すなわち、プログラムは、例えば、ダウンロードサイトから、ディジタル衛星放送用の人工衛星を介して、コンピュータに無線で転送したり、LAN(Local Area Network)、インターネットといったネットワークを介して、コンピュータに有線で転送することができる。
コンピュータは、CPU(Central Processing Unit)１０２を内蔵しており、CPU１０２には、バス１０１を介して、入出力インタフェース１１０が接続されている。
CPU１０２は、入出力インタフェース１１０を介して、ユーザによって、入力部１０７が操作等されることにより指令が入力されると、それに従って、ROM(Read Only Memory)１０３に格納されているプログラムを実行する。あるいは、CPU１０２は、ハードディスク１０５に格納されたプログラムを、RAM(Random Access Memory)１０４にロードして実行する。
これにより、CPU１０２は、上述したフローチャートにしたがった処理、あるいは上述したブロック図の構成により行われる処理を行う。そして、CPU１０２は、その処理結果を、必要に応じて、例えば、入出力インタフェース１１０を介して、出力部１０６から出力、あるいは、通信部１０８から送信、さらには、ハードディスク１０５に記録等させる。
なお、入力部１０７は、キーボードや、マウス、マイク等で構成される。また、出力部１０６は、LCD(Liquid Crystal Display)やスピーカ等で構成される。
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。
また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。
さらに、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
また、例えば、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。
また、例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
また、例えば、上述したプログラムは、任意の装置において実行することができる。その場合、その装置が、必要な機能（機能ブロック等）を有し、必要な情報を得ることができるようにすればよい。
また、例えば、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。換言するに、１つのステップに含まれる複数の処理を、複数のステップの処理として実行することもできる。逆に、複数のステップとして説明した処理を１つのステップとしてまとめて実行することもできる。
なお、コンピュータが実行するプログラムは、プログラムを記述するステップの処理が、本明細書で説明する順序に沿って時系列に実行されるようにしても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで個別に実行されるようにしても良い。つまり、矛盾が生じない限り、各ステップの処理が上述した順序と異なる順序で実行されるようにしてもよい。さらに、このプログラムを記述するステップの処理が、他のプログラムの処理と並列に実行されるようにしても良いし、他のプログラムの処理と組み合わせて実行されるようにしても良い。
なお、本明細書において複数説明した本技術は、矛盾が生じない限り、それぞれ独立に単体で実施することができる。もちろん、任意の複数の本技術を併用して実施することもできる。例えば、いずれかの実施の形態において説明した本技術の一部または全部を、他の実施の形態において説明した本技術の一部または全部と組み合わせて実施することもできる。また、上述した任意の本技術の一部または全部を、上述していない他の技術と併用して実施することもできる。
＜構成の組み合わせ例＞
なお、本技術は以下のような構成も取ることができる。
（１）
Point Cloudデータを３次元構造ベースで符号化してPoint Cloudデータ符号化ストリームを生成する際に、前記Point Cloudデータが複数の部分に分割された個々の部分となる部分Point Cloudデータそれぞれの空間上の位置を示す空間位置情報と、それらの部分Point Cloudデータをグルーピングするグルーピング情報とを含むファイルを生成するファイル生成部
を備える情報処理装置。
（２）
前記ファイル生成部により生成された前記ファイルは、前記Point Cloudデータのローカル座標系を基準に前記部分Point Cloudを表示するのに必用となる方向を示す方向対応情報をさらに含む
上記（１）に記載の情報処理装置。
（３）
前記ファイル生成部により生成された前記ファイルは、動的に変化する前記空間位置情報をさらに含む
上記（２）に記載の情報処理装置。
（４）
前記ファイル生成部により生成された前記ファイルは、動的に変化する前記方向対応情報をさらに含む
上記（２）に記載の情報処理装置。
（５）
前記ファイル生成部により生成された前記ファイルは、DASH MPD（Dynamic Adaptive Streaming over HTTP Media Presentation Description）、または、ISOBMFF（ISO Base Media File Format）構造を有するファイルである
上記（３）または（４）に記載の情報処理装置。
（６）
前記部分は、前記Point Cloudデータの中で独立してエンコードおよびデコードできるポイントの集合であるbrickで構成されており、
前記ファイル生成部により生成された前記ファイルは、前記brickの空間位置情報を、前記Point Cloudデータのストリーム内の前記brickを構成するデータ単位で紐づける情報をさらに含む
上記（１）から（５）までのいずれかに記載の情報処理装置。
（７）
前記部分Point Cloudデータは、前記Point Cloudデータの中で独立してエンコードおよびデコードできるポイントの集合であるbrickで構成されており、
前記ファイル生成部により生成された前記ファイルは、前記brickの空間位置情報を、前記部分Point Cloudデータのストリーム内の前記brickを構成するデータ単位で紐づける情報をさらに含む
上記（１）から（６）までのいずれかに記載の情報処理装置。
（８）
前記部分Point Cloudデータは、前記Point Cloudデータの中で独立してエンコードおよびデコードできるポイントの集合であるbrickで構成されており、
前記ファイル生成部により生成された前記ファイルは、前記brickの空間位置情報を、前記部分Point Cloudデータのストリーム内の前記brickを構成するデータ単位で紐づける情報をさらに含む
上記（１）から（７）までのいずれかに記載の情報処理装置。
（９）
情報処理装置が、
Point Cloudデータを３次元構造ベースで符号化してデータ符号化ストリームを生成する際に、前記Point Cloudデータが複数の部分に分割された個々の部分となる部分Point Cloudデータそれぞれの空間上の位置を示す空間位置情報と、それらの部分Point Cloudデータをグルーピングするグルーピング情報とを含むファイルを生成すること
を含む情報処理方法。
（１０）
Point Cloudデータを３次元構造ベースで符号化してPoint Cloudデータ符号化ストリームを生成する際に、符号化された部分の精細度を示す部分精細度情報を生成する符号化部を備え、
前記符号化部は、前記部分精細度情報に基づいて、前記Point Cloudデータのローカル座標系を基準に、相対的に高画質である領域についての方向を示す方向情報を生成する
情報処理装置。
（１１）
前記符号化部により生成された前記部分精細度情報および前記方向情報を含むファイルを生成するファイル生成部
をさらに備える上記（１０）に記載の情報処理装置。
（１２）
前記ファイル生成部により生成された前記ファイルは、DASH MPD、または、ISOBMFF構造を有するファイルである
上記（１１）に記載の情報処理装置。
（１３）
前記ファイル生成部により生成された前記ファイルは、前記Point Cloudデータが複数の部分に分割された個々の部分となる部分Point Cloudデータについて、組み合わせることで高精細化できる前記部分Point Cloudデータの紐づけ情報をさらに含む
上記（１２）に記載の情報処理装置。
（１４）
前記ファイル生成部により生成された前記ファイルは、組み合わせられた前記部分Point Cloudデータの精細度を示す精細度情報をさらに含む
上記（１３）に記載の情報処理装置。
（１５）
前記ファイル生成部により生成された前記ファイルは、低精細な前記部分をレンダリングするためのレンダリング処理情報をさらに含む
上記（１１）から（１４）までのいずれかに記載の情報処理装置。
（１６）
前記ファイル生成部により生成された前記ファイルは、前記部分ごとに異なる主観品質向上のために必要なレンダリング処理を示す主観品質向上レンダリング処理情報をさらに含む
上記（１５）に記載の情報処理装置。
（１７）
情報処理装置が、
Point Cloudデータを３次元構造ベースで符号化してデータ符号化ストリームを生成する際に、符号化された部分の精細度を示す部分精細度情報を生成すること
を含み、
前記部分精細度情報に基づいて、前記Point Cloudデータのローカル座標系を基準に、相対的に高画質である領域についての方向を示す方向情報が生成される
情報処理方法。
なお、本実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。また、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。
１１ データ生成装置， １２ データ再生装置， ２１ 制御部， ２２ メモリ， ２３ ファイル生成部， ３１ データ入力部， ３２ データ符号化・生成部， ３３ MPDファイル生成部， ３４ 記録部， ３５ 出力部， ３６ 前処理部， ３７ 符号化部， ３８ ファイル生成部， ４１ 制御部， ４２ メモリ， ４３ 再生処理部， ５１ 取得部， ５２ 表示制御部， ５３ データ解析・復号部， ５４ 表示部， ５５ ファイル解析部， ５６ 復号部， ５７ 表示情報生成部

Claims (18)

  1. Point Cloudデータを３次元構造ベースで符号化してPoint Cloudデータ符号化ストリームを生成する際に、前記Point Cloudデータが複数の部分に分割された個々の部分となる部分Point Cloudデータそれぞれの空間上の位置を示す空間位置情報と、それらの部分Point Cloudデータをグルーピングするグルーピング情報とを含むファイルを生成するファイル生成部
    を備える情報処理装置。
  2. 前記ファイル生成部により生成された前記ファイルは、前記Point Cloudデータのローカル座標系を基準に前記部分Point Cloudデータを表示するのに必用となる方向を示す方向対応情報をさらに含む
    請求項１に記載の情報処理装置。
  3. 前記ファイル生成部により生成された前記ファイルは、動的に変化する前記空間位置情報をさらに含む
    請求項２に記載の情報処理装置。
  4. 前記ファイル生成部により生成された前記ファイルは、動的に変化する前記方向対応情報をさらに含む
    請求項２に記載の情報処理装置。
  5. 前記ファイル生成部により生成された前記ファイルは、DASH MPD（Dynamic Adaptive Streaming over HTTP Media Presentation Description）、または、ISOBMFF（ISO Base Media File Format）構造を有するファイルである
    請求項３または４に記載の情報処理装置。
  6. 前記部分は、前記Point Cloudデータの中で独立してエンコードおよびデコードできるポイントの集合であるbrickで構成されており、
    前記ファイル生成部により生成された前記ファイルは、前記brickの空間位置情報を、前記Point Cloudデータのストリーム内の前記brickを構成するデータ単位で紐づける情報をさらに含む
    請求項１に記載の情報処理装置。
  7. 前記部分Point Cloudデータは、前記Point Cloudデータの中で独立してエンコードおよびデコードできるポイントの集合であるbrickで構成されており、
    前記ファイル生成部により生成された前記ファイルは、前記brickの空間位置情報を、前記部分Point Cloudデータのストリーム内の前記brickを構成するデータ単位で紐づける情報をさらに含む
    請求項１に記載の情報処理装置。
  8. 前記部分Point Cloudデータは、前記Point Cloudデータの中で独立してエンコードおよびデコードできるポイントの集合であるbrickで構成されており、
    前記ファイル生成部により生成された前記ファイルは、前記brickの空間位置情報を、前記部分Point Cloudデータのストリーム内の前記brickを構成するデータ単位で紐づける情報をさらに含む
    請求項１に記載の情報処理装置。
  9. 情報処理装置が、
    Point Cloudデータを３次元構造ベースで符号化してデータ符号化ストリームを生成する際に、前記Point Cloudデータが複数の部分に分割された個々の部分となる部分Point Cloudデータそれぞれの空間上の位置を示す空間位置情報と、それらの部分Point Cloudデータをグルーピングするグルーピング情報とを含むファイルを生成すること
    を含む情報処理方法。
  10. Point Cloudデータを３次元構造ベースで符号化してPoint Cloudデータ符号化ストリームを生成する際に、前記Point Cloudデータが複数の部分に分割された個々の部分となる部分Point Cloudデータそれぞれの空間上の位置を示す空間位置情報と、それらの部分Point Cloudデータをグルーピングするグルーピング情報とを含むファイルを解析し、前記部分Point Cloudデータを復号する再生処理部
    を備える情報処理装置。
  11. 前記ファイルは、前記Point Cloudデータのローカル座標系を基準に前記部分Point Cloudデータを表示するのに必用となる方向を示す方向対応情報をさらに含む
    請求項１０に記載の情報処理装置。
  12. 前記ファイルは、動的に変化する前記空間位置情報をさらに含む
    請求項１１に記載の情報処理装置。
  13. 前記ファイルは、動的に変化する前記方向対応情報をさらに含む
    請求項１１に記載の情報処理装置。
  14. 前記ファイルは、DASH MPD（Dynamic Adaptive Streaming over HTTP Media Presentation Description）、または、ISOBMFF（ISO Base Media File Format）構造を有するファイルである
    請求項１２または１３に記載の情報処理装置。
  15. 前記部分は、前記Point Cloudデータの中で独立してエンコードおよびデコードできるポイントの集合であるbrickで構成されており、
    前記ファイルは、前記brickの空間位置情報を、前記Point Cloudデータのストリーム内の前記brickを構成するデータ単位で紐づける情報をさらに含む
    請求項１０に記載の情報処理装置。
  16. 前記部分Point Cloudデータは、前記Point Cloudデータの中で独立してエンコードおよびデコードできるポイントの集合であるbrickで構成されており、
    前記ファイルは、前記brickの空間位置情報を、前記部分Point Cloudデータのストリーム内の前記brickを構成するデータ単位で紐づける情報をさらに含む
    請求項１０に記載の情報処理装置。
  17. 前記部分Point Cloudデータは、前記Point Cloudデータの中で独立してエンコードおよびデコードできるポイントの集合であるbrickで構成されており、
    前記ファイルは、前記brickの空間位置情報を、前記部分Point Cloudデータのストリーム内の前記brickを構成するデータ単位で紐づける情報をさらに含む
    請求項１０に記載の情報処理装置。
  18. 情報処理装置が、
    Point Cloudデータを３次元構造ベースで符号化してPoint Cloudデータ符号化ストリームを生成する際に、前記Point Cloudデータが複数の部分に分割された個々の部分となる部分Point Cloudデータそれぞれの空間上の位置を示す空間位置情報と、それらの部分Point Cloudデータをグルーピングするグルーピング情報とを含むファイルを解析し、前記部分Point Cloudデータを復号すること
    を含む情報処理方法。
JP2020563092A 2018-12-28 2019-12-16 情報処理装置および情報処理方法 Active JP7567481B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2018248322 2018-12-28
JP2018248322 2018-12-28
PCT/JP2019/049089 WO2020137642A1 (ja) 2018-12-28 2019-12-16 情報処理装置および情報処理方法

Publications (2)

Publication Number Publication Date
JPWO2020137642A1 JPWO2020137642A1 (ja) 2021-11-11
JP7567481B2 true JP7567481B2 (ja) 2024-10-16

Family

ID=71126235

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020563092A Active JP7567481B2 (ja) 2018-12-28 2019-12-16 情報処理装置および情報処理方法

Country Status (7)

Country Link
US (1) US11532103B2 (ja)
EP (1) EP3905532A4 (ja)
JP (1) JP7567481B2 (ja)
KR (1) KR20210108951A (ja)
CN (1) CN113302844A (ja)
SG (1) SG11202103291YA (ja)
WO (1) WO2020137642A1 (ja)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11403784B2 (en) * 2019-03-19 2022-08-02 Tencent America LLC Method and apparatus for tree-based point cloud compression (PCC) media stream using moving picture experts group (MPEG)-dynamic adaptive streaming over HTTP (DASH)
JP2023536725A (ja) * 2020-08-07 2023-08-29 ヴィド スケール インコーポレイテッド ジオメトリベースのポイントクラウドデータのためのタイルトラック
EP4224871A4 (en) * 2020-09-30 2024-03-20 ZTE Corporation METHOD AND APPARATUS FOR PROCESSING POINT CLOUD DATA, AND STORAGE MEDIUM AND ELECTRONIC APPARATUS
CN116248642A (zh) * 2020-10-14 2023-06-09 腾讯科技（深圳）有限公司 媒体文件的封装方法、媒体文件的解封装方法及相关设备
CN114549778A (zh) 2020-11-26 2022-05-27 腾讯科技（深圳）有限公司 非时序点云媒体的处理方法、装置、设备及存储介质
USD1013717S1 (en) * 2021-01-08 2024-02-06 Sony Group Corporation Display screen or portion thereof with an animated graphical user interface
CN113709093B (zh) * 2021-03-15 2023-08-04 上海交通大学 一种三维点云的封装方法、装置及介质
CN115150384B (zh) 2021-03-31 2023-08-18 腾讯科技（深圳）有限公司 点云编解码方法、装置、计算机可读介质及电子设备
CN115243053B (zh) * 2021-04-22 2024-04-16 腾讯科技（深圳）有限公司 点云编解码方法及相关设备
CN118891884A (zh) * 2022-03-17 2024-11-01 索尼集团公司 信息处理装置和方法
CN119366192A (zh) * 2022-04-22 2025-01-24 Lg电子株式会社 点云数据的发送装置、由发送装置执行的方法、点云数据的接收装置和由接收装置执行的方法
IL317527A (en) * 2022-06-28 2025-02-01 Drnc Holdings Inc Signaling parameter sets for geometry-based point cloud streams
CN115348243A (zh) * 2022-08-15 2022-11-15 上海交通大学 三维点云的传输方法、接收方法、传输装置、接收装置及存储介质
GB2623524A (en) * 2022-10-17 2024-04-24 Canon Kk Method, device, and computer program for improving transmission and/or storage of point cloud data

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017217191A1 (ja) 2016-06-14 2017-12-21 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 三次元データ符号化方法、三次元データ復号方法、三次元データ符号化装置及び三次元データ復号装置

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013038766A (ja) * 2011-07-12 2013-02-21 Sharp Corp 送信装置、送信装置の制御方法、制御プログラム、及び記録媒体
US9467708B2 (en) * 2011-08-30 2016-10-11 Sonic Ip, Inc. Selection of resolutions for seamless resolution switching of multimedia content
KR102224826B1 (ko) * 2016-05-26 2021-03-09 브이아이디 스케일, 인크. 뷰포트 적응형 360도 비디오 전달의 방법 및 장치
US10694210B2 (en) * 2016-05-28 2020-06-23 Microsoft Technology Licensing, Llc Scalable point cloud compression with transform, and corresponding decompression
US10917564B2 (en) * 2016-10-12 2021-02-09 Qualcomm Incorporated Systems and methods of generating and processing files for partial decoding and most interested regions
CN106658011A (zh) * 2016-12-09 2017-05-10 深圳市云宙多媒体技术有限公司 全景视频的编解码方法和装置
FI20166017A (fi) * 2016-12-22 2018-06-23 Nokia Technologies Oy Laitteisto, menetelmä ja tietokoneohjelma videokoodausta ja videokoodauksen purkua varten
US10553015B2 (en) * 2017-03-31 2020-02-04 Google Llc Implicit view-dependent quantization
CN108052058B (zh) * 2018-01-31 2023-11-24 广州市建筑科学研究院有限公司 一种基于“互联网+”的建设工程现场安全巡管事务流转系统
WO2020013661A1 (ko) * 2018-07-13 2020-01-16 한국전자통신연구원 스케일러블 포인트 클라우드 부호화/복호화 방법 및 장치
US20200153885A1 (en) * 2018-10-01 2020-05-14 Lg Electronics Inc. Apparatus for transmitting point cloud data, a method for transmitting point cloud data, an apparatus for receiving point cloud data and/or a method for receiving point cloud data
US10853973B2 (en) * 2018-10-03 2020-12-01 Apple Inc. Point cloud compression using fixed-point numbers

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017217191A1 (ja) 2016-06-14 2017-12-21 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 三次元データ符号化方法、三次元データ復号方法、三次元データ符号化装置及び三次元データ復号装置

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
MAMMOU, Khaled ほか，G-PCC codec description v2，ISO/IEC JTC1/SC29/WG11 N18189 [online]，ISO/IEC JTC1/SC29/WG11，2019年01月，第1頁 - 第40頁，https://mpeg.chiariglione.org/sites/default/files/files/standards/parts/docs/w18189
仲地 孝之，ポスト４Ｋ・８Ｋ時代のメディア伝送技術：ＭＭＴ，Fundamentals Review [online]，Vol.11 No.4，日本，電子情報通信学会 基礎・境界ソサイエティ，2018年04月，pp.288 - 301，https://www.jstage.jst.go.jp/article/essfr/11/4/11_288/_pdf/-char/ja

Also Published As

Publication number Publication date
JPWO2020137642A1 (ja) 2021-11-11
CN113302844A (zh) 2021-08-24
SG11202103291YA (en) 2021-04-29
US20220036593A1 (en) 2022-02-03
EP3905532A1 (en) 2021-11-03
WO2020137642A1 (ja) 2020-07-02
EP3905532A4 (en) 2022-11-30
US11532103B2 (en) 2022-12-20
KR20210108951A (ko) 2021-09-03

Similar Documents

Publication Publication Date Title
JP7567481B2 (ja) 情報処理装置および情報処理方法
JP7563385B2 (ja) 情報処理装置、情報処理方法、再生処理装置及び再生処理方法
JP7415936B2 (ja) 情報処理装置および情報処理方法
JP7501372B2 (ja) 情報処理装置および情報処理方法
JP7544048B2 (ja) 情報処理装置、情報処理方法、再生処理装置及び再生処理方法
KR20230022165A (ko) 정보 처리 장치 및 방법
JP2022512509A (ja) 符号化された点群データの分割
CN116636225A (zh) 信息处理装置和方法
WO2022220291A1 (ja) 情報処理装置および方法
WO2022054744A1 (ja) 情報処理装置および方法
WO2022220278A1 (ja) 情報処理装置および方法
WO2023054156A1 (ja) 情報処理装置および方法
WO2021002142A1 (ja) 情報処理装置、情報処理方法、再生処理装置及び再生処理方法
JP2022063882A (ja) 情報処理装置および方法、並びに、再生装置および方法
WO2024143466A1 (ja) 情報処理装置および方法
WO2020145139A1 (ja) 情報処理装置および情報処理方法
WO2023277062A1 (ja) 情報処理装置および方法
WO2021251141A1 (ja) 情報処理装置および方法
US20220343545A1 (en) Method and apparatus for immersive video encoding and decoding
WO2022220255A1 (ja) 情報処理装置および方法

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20221027

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20240109

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240304

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20240507

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240604

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: 20240903

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240916

R150 Certificate of patent or registration of utility model

Ref document number: 7567481

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150