(57)【要約】  本発明の実施形態は、メディア情報処理方法および装置を開示する。方法は、メディアデータのメタデータ情報を取得するステップであって、メタデータ情報がメタデータのソース情報を含み、ソース情報がメディアデータのレコメンダを示すために使用され、メディアデータが全方向メディアデータである、ステップと、メタデータのソース情報に基づいてメディアデータを処理するステップとを含む。本発明の実施形態におけるメディア情報処理方法および装置によれば、メディアデータのレコメンダに関する情報は、データ処理中にクライアント向けの参照として使用されてよく、それにより、ユーザのための選択肢が増え、ユーザ体験が改善される。
2020526969.tif 000002
【特許請求の範囲】
【請求項１】
メディア情報処理方法であって、前記方法が、
メディアデータのメタデータ情報を取得するステップであって、前記メタデータ情報がメタデータのソース情報を備え、前記ソース情報が前記メディアデータのレコメンダを示すために使用され、前記メディアデータが全方向メディアデータである、ステップと、
前記メタデータの前記ソース情報に基づいて前記メディアデータを処理するステップと
を備える、方法。
【請求項２】
メディアデータのメタデータ情報を取得する前記ステップが、
前記メディアデータのメタデータトラック（track）を取得するステップであって、前記メタデータトラックが前記メタデータの前記ソース情報を備える、ステップ
を備える、請求項1に記載の方法。
【請求項３】
メディアデータのメタデータ情報を取得する前記ステップが、
前記メディアデータのメディアプレゼンテーション記述ファイルを取得するステップであって、前記メディアプレゼンテーション記述ファイルが前記メタデータの前記ソース情報を備える、ステップ
を備える、請求項1に記載の方法。
【請求項４】
メディアデータのメタデータ情報を取得する前記ステップが、
前記メディアデータを備えるビットストリームを取得するステップであって、前記ビットストリームが補足拡張情報（supplementary enhancement information、SEI）をさらに備え、前記補足拡張情報が前記メタデータの前記ソース情報を備える、ステップ
を備える、請求項1に記載の方法。
【請求項５】
前記メタデータの前記ソース情報がソースタイプ識別子である、請求項1から4のいずれか一項に記載の方法。
【請求項６】
前記メタデータの前記ソース情報が、前記メディアデータの前記レコメンダの意味表現を備える、請求項1から4のいずれか一項に記載の方法。
【請求項７】
メディア情報処理装置であって、前記装置が、
メディアデータのメタデータ情報を取得するように構成された情報取得モジュールであって、前記メタデータ情報がメタデータのソース情報を備え、前記ソース情報が前記メディアデータのレコメンダを示すために使用され、前記メディアデータが全方向メディアデータである、情報取得モジュールと、
前記メタデータの前記ソース情報に基づいて前記メディアデータを処理するように構成された処理モジュールと
を備える、装置。
【請求項８】
前記情報取得モジュールが、具体的に、前記メディアデータのメタデータトラック（track）を取得するように構成され、前記メタデータトラックが前記メタデータの前記ソース情報を備える、請求項7に記載の装置。
【請求項９】
前記情報取得モジュールが、具体的に、前記メディアデータのメディアプレゼンテーション記述ファイルを取得するように構成され、前記メディアプレゼンテーション記述ファイルが前記メタデータの前記ソース情報を備える、請求項7に記載の装置。
【請求項１０】
前記情報取得モジュールが、具体的に、前記メディアデータを備えるビットストリームを取得するように構成され、前記ビットストリームが補足拡張情報（supplementary enhancement information、SEI）をさらに備え、前記補足拡張情報が前記メタデータの前記ソース情報を備える、請求項7に記載の装置。
【請求項１１】
前記メタデータの前記ソース情報がソースタイプ識別子である、請求項7から10のいずれか一項に記載の装置。
【請求項１２】
前記メタデータの前記ソース情報が、前記メディアデータの前記レコメンダの意味表現を備える、請求項7から10のいずれか一項に記載の装置。
【請求項１３】
メディア情報処理方法であって、前記方法が、
複数のクライアントによって送信されたいくつかのユーザビューポート情報を受信するステップであって、前記ユーザビューポート情報が、ユーザが全方向メディアデータを視聴するためのビューポートを示すために使用される、ステップと、
すべての前記ユーザビューポート情報に基づいてターゲットビューポートを決定するステップと、
前記ターゲットビューポートに対応するメディアデータを送信するステップと
を備える、方法。
【請求項１４】
メディア情報処理方法であって、前記方法が、
複数のクライアントによって送信されたいくつかのユーザビューポート情報を受信するステップであって、前記ユーザビューポート情報が、ユーザが全方向メディアデータを視聴するためのビューポートを示すために使用される、ステップと、
すべての前記ユーザビューポート情報に基づいてターゲットビューポートを決定するステップと、
前記ターゲットビューポートに基づいてメディアデータのメタデータ情報を生成するステップと
を備える、方法。
【請求項１５】
メディア情報処理装置であって、前記装置が、
複数のクライアントによって送信されたいくつかのユーザビューポート情報を受信するように構成された受信機であって、前記ユーザビューポート情報が、ユーザが全方向メディアデータを視聴するためのビューポートを示すために使用される、受信機と、
すべての前記ユーザビューポート情報に基づいてターゲットビューポートを決定するように構成されたプロセッサと、
前記ターゲットビューポートに対応するメディアデータを送信するように構成された送信機と
を備える、装置。
【請求項１６】
メディア情報処理装置であって、前記装置が、
複数のクライアントによって送信されたいくつかのユーザビューポート情報を受信するように構成された受信機であって、前記ユーザビューポート情報が、ユーザが全方向メディアデータを視聴するためのビューポートを示すために使用される、受信機と、
すべての前記ユーザビューポート情報に基づいてターゲットビューポートを決定し、前記ターゲットビューポートに基づいてメディアデータのメタデータ情報を生成するように構成されたプロセッサと
を備える、装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストリーミングメディア送信技術の分野に関し、詳細には、メディア情報処理方法および装置に関する。
【背景技術】
【０００２】
ISO／IEC23090−2標準規格は、OMAF（Omnidirectional media format、全方向メディア形式）標準規格とも呼ばれる。この規格は、アプリケーション内で全方向メディアのプレゼンテーションを実装することができるメディアアプリケーション形式を定義する。全方向メディアは、主に、全方向ビデオ（360°ビデオ）および関連するオーディオを指す。OMAF規格は、最初に球状ビデオを2次元ビデオに変換するために使用できる投影方法のリストを指定し、次いで、ISOベースメディアファイル形式（ISO base media file format、ISOBMFF）を使用して、メディアに関連付けられた全方向メディアおよびメタデータを記憶する方法、ならびにメディアストリーミングシステム内で全方向メディアのデータをカプセル化し送信する方法、たとえば、ISO／IEC23009−1規格内で指定されたダイナミック適応ストリーミングオーバハイパーテキスト転送プロトコル（Dynamic Adaptive Streaming over HTTP（HyperText Transfer Protocol、HTTP）、DASH）を指定する。
【０００３】
ISOベースメディアファイル形式は一連のボックス（box）を備え、boxは、メタデータboxおよびメディアデータboxを含む他のboxを含んでよい。メタデータbox（moov box）はメタデータを含み、メディアデータbox（mdat box）はメディアデータを含む。メタデータboxおよびメディアデータboxは、同じファイルまたは別々のファイル内にあってよい。時限メタデータがISOベースメディアファイル形式を使用してカプセル化されている場合、メタデータboxは時限メタデータを記述するメタデータを含み、メディアデータboxは時限メタデータを含む。
【０００４】
従来技術では、クライアントはデータのソースを正確に識別することができないので、クライアントがメタデータに基づいてメディアデータを選択すると、ユーザ要件を完全に満たすことができず、ユーザ体験は比較的不十分である。
【発明の概要】
【課題を解決するための手段】
【０００５】
本発明の実施形態は、クライアントがメタデータのソースに基づいて異なる処理方式を選択することができるように、メディア情報処理方法および装置を提供する。
【０００６】
本発明の第1の態様の一実施形態では、メディア情報処理方法が開示され、方法は、
メディアデータのメタデータ情報を取得するステップであって、メタデータ情報がメタデータのソース情報を含み、ソース情報がメディアデータのレコメンダを示すために使用され、メディアデータが全方向メディアデータである、ステップと、
メタデータのソース情報に基づいてメディアデータを処理するステップと
を含む。
【０００７】
本発明のこの実施形態における全方向メディアデータは、ビデオデータまたはオーディオデータであってよい。可能な実装形態では、全方向メディアの関連する例については、ISO／IEC23090−2標準規格内の関連規定を参照されたい。
【０００８】
可能な実装形態では、メタデータは、ビデオデータに対応する継続時間、ビットレート、フレームレート、球面座標系内の位置などのビデオデータのいくつかの属性に関する情報である。
【０００９】
可能な実装形態では、全方向ビデオの領域は、全方向ビデオに対応するビデオ空間内の領域である。
【００１０】
可能な実装形態では、メタデータのソース情報は、メタデータに対応するビデオデータが全方向ビデオの作者によって推奨されていることを示してもよく、メタデータに対応するビデオデータが全方向ビデオのユーザによって推奨されていることを示してもよく、メタデータに対応するビデオデータが複数のユーザによる全方向ビデオの視聴結果に関する統計データが収集された後に推奨されていることを示してもよい。
【００１１】
本発明のこの実施形態におけるメディア情報処理方法によれば、メディアデータのレコメンダに関する情報は、データ処理中にクライアント向けの参照として使用されてよく、それにより、ユーザのための選択肢が増え、ユーザ体験が改善される。
【００１２】
本発明のこの実施形態の可能な実装形態では、メディアデータのメタデータ情報を取得するステップは、
メディアデータのメタデータトラック（track）を取得するステップであって、メタデータトラックがメタデータのソース情報を含む、ステップ
を含む。
【００１３】
可能な実装形態では、メタデータトラックのアドレス情報は、メディアプレゼンテーション記述ファイルを使用して取得されてよく、次いで、メディアデータのメタデータトラックを受信し取得するために、このアドレスに情報取得要求が送信されてよい。
【００１４】
可能な実装形態では、メタデータトラックのアドレス情報は別個のファイルを使用して取得されてよく、次いで、メディアデータのメタデータトラックを受信し取得するために、このアドレスに情報取得要求が送信されてよい。
【００１５】
可能な実装形態では、サーバはメディアデータのメタデータトラックをクライアントに送信する。
【００１６】
可能な実装形態では、トラック（track）は、ISOベースメディアファイル形式（ISO base media file format、ISOBMFF）に従ってカプセル化されたサンプルの時限シーケンスである。たとえば、ビデオtrack、ビデオサンプルは、ISOBMFFの規格に従って、ビデオエンコーダが各フレームを符号化した後に生成されるビットストリームをカプセル化することによって取得される。トラックの具体的な定義については、ISO／IEC14496−12の関連説明を参照されたい。
【００１７】
可能な実装形態では、メディアプレゼンテーション記述ファイルの関連属性およびデータ構造については、ISO／IEC23009−1の関連説明を参照されたい。
【００１８】
可能な実装形態では、メタデータのソース情報はメタデータトラックに新しく追加されたボックス（box）に記憶されてよく、メタデータのソース情報はbox内のデータを構文解析することによって取得されてよい。
【００１９】
可能な実装形態では、メタデータのソース情報はメタデータトラック内の既存のボックスに追加された属性であってよく、メタデータのソース情報はその属性を構文解析することによって取得されてよい。
【００２０】
メタデータのソース情報はメタデータトラックにカプセル化され、その結果、クライアントはメタデータトラックを取得するときにメタデータのソース情報を取得することができ、クライアントはメタデータの別の属性およびメタデータのソース情報を包括的に検討して、関連するメディアデータに対して次の処理を実行することができる。
【００２１】
本発明のこの実施形態の可能な実装形態では、メディアデータのメタデータ情報を取得するステップは、
メディアデータのメディアプレゼンテーション記述ファイルを取得するステップであって、メディアプレゼンテーション記述ファイルがメタデータのソース情報を含む、ステップ
を含む。
【００２２】
クライアントは、サーバにHTTP要求を送信することにより、メディアプレゼンテーション記述ファイルを取得することができ、またはサーバは、クライアントにメディアプレゼンテーション記述ファイルを直接プッシュすることができる。あるいは、クライアントは、別の可能な方式でメディアプレゼンテーション記述ファイルを取得することができる。たとえば、クライアントは、別のクライアント側と対話することにより、メディアプレゼンテーション記述ファイルを取得することができる。
【００２３】
可能な実装形態では、メディアプレゼンテーション記述ファイルの関連属性およびデータ構造については、ISO／IEC23009−1の関連説明を参照されたい。
【００２４】
可能な実装形態では、メタデータのソース情報は記述子に示された情報であってもよく、メタデータのソース情報は属性情報であってもよい。
【００２５】
可能な実装形態では、メタデータのソース情報は、メディアプレゼンテーション記述ファイル内の適応セット（adaptation set）レベルまたは表現（representation）レベルにあってよい。
【００２６】
本発明のこの実施形態の可能な実装形態では、メディアデータのメタデータ情報を取得するステップは、
メディアデータを含むビットストリームを取得するステップであって、ビットストリームが補足拡張情報（supplementary enhancement information、SEI）をさらに含み、補足拡張情報がメタデータのソース情報を含む、ステップ
を含む。
【００２７】
可能な実装形態では、クライアントはサーバにメディアデータ取得要求を送信し、次いで、サーバによって送信されたメディアデータを受信することができる。たとえば、クライアントは、メディアプレゼンテーション記述ファイル内の関連属性およびアドレス情報を使用してユニフォームリソースロケータ（Uniform Resource Locator、URL）を構築し、URLにHTTP要求を送信し、次いで、対応するメディアデータを受信することができる。
【００２８】
可能な実装形態では、クライアントはサーバによってプッシュされたメディアデータストリームを受信することができる。
【００２９】
本発明のこの実施形態の可能な実装形態では、メタデータのソース情報はソースタイプ識別子である。異なるソースタイプ識別子またはソースタイプ識別子の値は、対応するソースタイプを示すことができる。たとえば、1ビットを有するフラグがソースタイプを示すために使用されてよく、またはより多くのビットを有するフィールドがソースタイプを識別するために使用されてよい。一例では、クライアント側は、ソースタイプ識別子とソースタイプとの間の対応関係のファイルを記憶し、したがって、クライアントは、ソースタイプ識別子の異なる値または異なるソースタイプ識別子に基づいて、対応するソースタイプを特定することができる。
【００３０】
可能な実装形態では、1つのソースタイプが1人のレコメンダに対応する。たとえば、ソースタイプは、ビデオ作者の推奨、ユーザの推奨、または複数のユーザの視聴結果に関する統計情報が収集された後に行われた推奨であってよい。
【００３１】
本発明のこの実施形態の可能な実装形態では、メタデータのソース情報は、メディアデータのレコメンダの意味表現を含む。たとえば、ISO−639−2／T内のコードワードは、様々なタイプのセマンティクスを表すために使用されてよい。
【００３２】
本発明のこの実施形態の可能な実装形態では、メタデータのソース情報に基づいてメタデータに対応するメディアデータを処理するステップは、以下の実装形態を含む：
クライアント側がメタデータに対応するメディアデータを取得していない場合、クライアント側は、ユーザによって選択されたソース情報に基づいて、サーバ側もしくは別の端末側に対応するメディアデータを要求することができ、
クライアント側がメタデータに対応するメディアデータを取得している場合、クライアント側は、ユーザによって選択されたソース情報に基づいて、メディアデータを提示もしくは送信することができ、または
方法がサーバ側で実行される場合、サーバは、メタデータのソース情報に基づいて、クライアントにメディアデータをプッシュすることができる。
【００３３】
可能な実装形態では、サーバは、複数のいくつかのメタデータの受信されたソース情報に基づいて、プッシュされるべきメディアデータを決定することができる。たとえば、サーバは、規格に従って複数の推奨から選択を実行し、次いで、選択結果に基づいてメディアデータをプッシュする。あるいは、サーバは、規格に従って複数の推奨に対して計算を実行し、次いで、計算結果に基づいてメディアデータをプッシュする。
【００３４】
本発明の第2の態様の一実施形態では、メディア情報処理装置が開示され、装置は、
メディアデータのメタデータ情報を取得するように構成された情報取得モジュールであって、メタデータ情報がメタデータのソース情報を含み、ソース情報がメディアデータのレコメンダを示すために使用され、メディアデータが全方向メディアデータである、情報取得モジュールと、メタデータのソース情報に基づいてメディアデータを処理するように構成された処理モジュールと
を含む。
【００３５】
本発明のこの実施形態におけるメディア情報処理装置によれば、メディアデータのレコメンダに関する情報は、データ処理中にクライアント向けの参照として使用されてよく、それにより、ユーザのための選択肢が増え、ユーザ体験が改善される。
【００３６】
可能な実装形態では、情報取得モジュールは、具体的に、メディアデータのメタデータトラック（track）を取得するように構成され、メタデータトラックはメタデータのソース情報を含む。
【００３７】
可能な実装形態では、情報取得モジュールは、具体的に、メディアデータのメディアプレゼンテーション記述ファイルを取得するように構成され、メディアプレゼンテーション記述ファイルはメタデータのソース情報を含む。
【００３８】
可能な実装形態では、情報取得モジュールは、具体的に、メディアデータを含むビットストリームを取得するように構成され、ビットストリームは補足拡張情報（supplementary enhancement information、SEI）をさらに含み、補足拡張情報はメタデータのソース情報を含む。
【００３９】
可能な実装形態では、メタデータのソース情報はソースタイプ識別子である。
【００４０】
可能な実装形態では、メタデータのソース情報はメディアデータのレコメンダの意味表現を含む。
【００４１】
本発明の装置実施形態の具体例および実装形態については、第1の態様の前述の方法実施形態における関連する例を参照されたい。詳細は本明細書では記載されない。
【００４２】
本発明の第3の態様の一実施形態では、メディア情報処理方法が開示され、方法は、
複数のクライアントによって送信されたいくつかのユーザビューポート情報を受信するステップであって、ユーザビューポート情報が、ユーザが全方向メディアデータを視聴するためのビューポートを示すために使用される、ステップと、すべてのユーザビューポート情報に基づいてターゲットビューポートを決定するステップと、ターゲットビューポートに対応するメディアデータを送信するステップと
を含む。
【００４３】
本発明のこの実施形態におけるメディア情報処理方法によれば、次のユーザがビデオを視聴するときにビューポートを推奨する効果的な方式を提供するために、複数のユーザが同じビデオを視聴するためのビューポートに対して統計分析が実行されてよく、それにより、ユーザ体験が改善される。
【００４４】
可能な実装形態では、方法は、サーバ側で、たとえば、コンテンツ準備サーバ、コンテンツ配信ネットワーク（Content distribution network、CDN）、またはプロキシサーバによって実行される。
【００４５】
可能な実装形態では、クライアントによって送信されるユーザビューポート情報は、別個のファイルを使用して送信されてもよく、クライアントによって送信される別のデータファイルに含まれてもよい。
【００４６】
可能な実装形態では、全方向メディアおよびビューポートの説明および例については、第1の態様の前述の実施形態の例および具体的な実装形態を参照されたい。詳細は本明細書では記載されない。
【００４７】
可能な実装形態では、すべてのユーザビューポート情報に基づいてターゲットビューポートを決定するステップは、事前設定された規格および統計原理に従って複数のビューポートからターゲットビューポートを選択するステップ、またはターゲットビューポートを取得するために、ある方式で複数のビューポートのデータに対して計算を実行するステップであってよい。
【００４８】
可能な実装形態では、ターゲットビューポートに対応するメディアデータはクライアントに直接プッシュされてよく、またはターゲットビューポートに対応するメディアデータは配信サーバにプッシュされてよく、または、全方向メディアデータに対するクライアントの取得要求が受信されると、ターゲットビューポートに対応するメディアデータはクライアントにフィードバックされてよい。
【００４９】
本発明の第4の態様の一実施形態では、メディア情報処理方法が開示され、方法は、
複数のクライアントによって送信されたいくつかのユーザビューポート情報を受信するステップであって、ユーザビューポート情報が、ユーザが全方向メディアデータを視聴するためのビューポートを示すために使用される、ステップと、すべてのユーザビューポート情報に基づいてターゲットビューポートを決定するステップと、ターゲットビューポートに基づいてメディアデータのメタデータ情報を生成するステップと
を含む。
【００５０】
本発明のこの実施形態におけるメディア情報処理方法によれば、次のユーザがビデオを視聴するときにビューポートを推奨する効果的な方式を提供するために、複数のユーザが同じビデオを視聴するためのビューポートに対して統計分析が実行されてよく、それにより、ユーザ体験が改善される。
【００５１】
可能な実装形態では、方法は、サーバ側で、たとえば、コンテンツ準備サーバ、コンテンツ配信ネットワーク（Content distribution network、CDN）、またはプロキシサーバによって実行される。
【００５２】
可能な実装形態では、クライアントによって送信されるユーザビューポート情報は、別個のファイルを使用して送信されてもよく、クライアントによって送信される別のデータファイルに含まれてもよい。
【００５３】
可能な実装形態では、全方向メディアおよびビューポートの説明および例については、第1の態様の実施形態の例および具体的な実装形態を参照されたい。詳細は本明細書では記載されない。
【００５４】
可能な実装形態では、すべてのユーザビューポート情報に基づいてターゲットビューポートを決定するステップは、事前設定された規格および統計原理に従って複数のビューポートからターゲットビューポートを選択するステップ、またはターゲットビューポートを取得するために、ある方式で複数のビューポートのデータに対して計算を実行するステップであってよい。
【００５５】
本発明の第5の態様の一実施形態では、メディア情報処理装置が開示され、装置は、
複数のクライアントによって送信されたいくつかのユーザビューポート情報を受信するように構成された受信機であって、ユーザビューポート情報が、ユーザが全方向メディアデータを視聴するためのビューポートを示すために使用される、受信機と、すべてのユーザビューポート情報に基づいてターゲットビューポートを決定するように構成されたプロセッサと、ターゲットビューポートに対応するメディアデータを送信するように構成された送信機と
を含む。
【００５６】
本発明の第6の態様の一実施形態では、メディア情報処理装置が開示され、装置は、
複数のクライアントによって送信されたいくつかのユーザビューポート情報を受信するように構成された受信機であって、ユーザビューポート情報が、ユーザが全方向メディアデータを視聴するためのビューポートを示すために使用される、受信機と、すべてのユーザビューポート情報に基づいてターゲットビューポートを決定し、ターゲットビューポートに基づいてメディアデータのメタデータ情報を生成するように構成されたプロセッサと
を含む。
【００５７】
本発明の第5の態様および第6の態様の装置実施形態の具体例および実装形態については、第3の態様および第4の態様の前述の方法実施形態における関連する例を参照されたい。詳細は本明細書では記載されない。
【００５８】
本発明の第7の態様の一実施形態では、メディア情報処理装置が開示され、装置は、1つまたは複数のプロセッサとメモリとを含む。メモリは1つまたは複数のプロセッサに結合される。メモリはコンピュータプログラムコードを記憶するように構成され、コンピュータプログラムコードは命令を含む。1つまたは複数のプロセッサが命令を実行すると、処理装置は、第1の態様、第3の態様、第4の態様、または前述の態様の任意の可能な実装形態によるメディア情報処理方法を実行する。
【００５９】
本発明の第8の態様の一実施形態では、コンピュータ可読記憶媒体が開示される。コンピュータ可読記憶媒体は命令を記憶し、命令がデバイス上で実行されると、デバイスは、第1の態様、第3の態様、第4の態様、または前述の態様の任意の可能な実装形態によるメディア情報処理方法を実行することが可能になる。
【００６０】
本発明の実施形態における技術的解決策をより明確に記載するために、以下で、実施形態を記載するために必要とされる添付図面を簡単に記載する。明らかに、以下の説明における添付図面は本発明のいくつかの実施形態を示すにすぎず、当業者は、創造的な努力なしに、これらの添付図面から他の図面を導出することができる。
【図面の簡単な説明】
【００６１】
【図１】本発明の一実施形態による、全方向ビデオ用のビューポートの変更の一例を示す図である。
【図２】本発明の一実施形態による、全方向ビデオに対応する空間を空間オブジェクトに分割する一例を示す図である。
【図３】本発明の一実施形態による、全方向ビデオに対応する空間内の空間オブジェクトの相対位置の概略図である。
【図４】本発明の一実施形態による、空間オブジェクトを記述するための座標系の一例を示す図である。
【図５】本発明の一実施形態による、空間オブジェクトを記述するための座標系の別の例を示す図である。
【図６】本発明の一実施形態による、空間オブジェクトを記述するための座標系のさらに別の例を示す図である。
【図７】本発明の一実施形態による、方法および装置のアプリケーションシナリオの一例を示す図である。
【図８】本発明の一実施形態による、メディア情報処理方法の概略フローチャートである。
【図９】本発明の一実施形態による、メディア情報処理装置の概略構造図である。
【図１０】本発明の一実施形態による、メディア情報処理装置の具体的なハードウェアの概略図である。
【図１１（ａ）】本発明の一実施形態による、空間オブジェクトとビデオデータとの間のマッピング関係の概略図である。
【図１１（ｂ）】本発明の一実施形態による、空間オブジェクトとビデオデータとの間のマッピング関係の概略図である。
【発明を実施するための形態】
【００６２】
以下で、本発明の実施形態における添付図面を参照して、本発明の実施形態における技術的解決策を明確かつ完全に記載する。
【００６３】
本発明のいくつかの実施形態では、トラック（track）は、ISOベースメディアファイル形式（ISO base media file format、ISOBMFF）に従ってカプセル化されたサンプルの時限シーケンスである。たとえば、ビデオtrack、ビデオサンプルは、ISOBMFFの規格に従って、ビデオエンコーダが各フレームを符号化した後に生成されるビットストリームをカプセル化することによって取得される。
【００６４】
Trackは、ISO／IEC14496−12規格内で「timed sequence of related samples（q．v．）in an ISO base media file．NOTE：For media data，a track corresponds to a sequence of images or sampled audio；for hint tracks，a track corresponds to a streaming channel．」と定義されている。
【００６５】
中国語訳は、「ISOベースメディアファイル内の関連するサンプルの時限シーケンス（q．v．）。NOTE：For media data，a track corresponds to a sequence of images or sampled audio；for hint tracks，a track corresponds to a streaming channel．」と定義されている。
【００６６】
ISOBMFFファイルは複数のボックス（box）を備え、1つのboxは別のboxを含んでよい。
【００６７】
boxは、ISO／IEC14496−12規格内で「object−oriented building block defined by a unique type identifier and length．NOTE：Called‘atom’in some specifications，including the first definition of MP4．」と定義されている。
【００６８】
中国語訳は、「一意のタイプ識別子および長さによって定義されるオブジェクト指向のビルディングブロック。NOTE：Called‘atom’in some specifications，including the first definition of MP4．」と定義されている。
【００６９】
補足拡張情報（supplementary enhancement information、SEI）は、国際電気通信連合（International Telecommunication Union、ITU）によって公開されたビデオコーディングおよび復号規格h．264およびh．265内で定義されたネットワークアクセスユニット（Network Abstract Layer Unit、NALU）の1タイプである。
【００７０】
メディアプレゼンテーション記述（Media presentation description、MPD）は、ISO／IEC23009−1規格で指定されたファイルであり、このファイルは、クライアントがHTTP−URLを構築するためのメタデータを含む。MPDは、1つまたは複数のperiod（周期）要素を含み、各periodは1つまたは複数の適応セット（adaptationset）を含み、各adaptationsetは1つまたは複数の表現（representation）を含み、各representationは1つまたは複数のセグメントを含む。クライアントは、MPD内の情報に基づいて表現を選択し、セグメントのHTTP−URLを構築する。
【００７１】
現在、360度ビデオなどのVRビデオを視聴するためのアプリケーションの人気が高まるにつれて、広角VRビデオを視聴する体験に参加するユーザが増えている。そのような新しいビデオ視聴アプリケーションは、ユーザに新しいビデオ視聴モードおよび新しい視覚体験をもたらすだけでなく、新しい技術的課題ももたらす。360度ビデオ（360度ビデオは、本発明の実施形態における説明のための一例として使用される）などの広角ビデオを視聴するプロセスでは、VRビデオの空間領域（空間領域は空間オブジェクトと呼ばれる場合もある）は、人間の目の通常の視覚範囲を超える360度パノラマ空間（または全方向空間もしくはパノラマ空間オブジェクトと呼ばれる）である。したがって、ビデオを視聴するとき、ユーザはいつでもビューポート（視野、FOV）を変更する。異なるビューポートを使用すると、ユーザは異なる映像を見る。この場合、ビデオに提示されるコンテンツは、ユーザのビューポートとともに変更される必要がある。図1は、ビューポートの変更に対応する概略ビューポート図である。ブロック1およびブロック2は、ユーザの2つの異なるビューポートを表す。ビデオを視聴するとき、ユーザは、目の動き、頭の動き、またはビデオ視聴デバイス上の画像の切替えなどの動作を介して、ユーザがビデオを視聴するためのビューポートをブロック1からブロック2に切り替えることができる。ビューポートがブロック1であるときにユーザが視聴する映像は、ビューポートに対応する1つまたは複数の空間オブジェクト内でこの瞬間に提示される映像である。ユーザのビューポートは、次の瞬間にブロック2に切り替わる。この場合、ユーザが視聴する映像は、ブロック2に対応する空間オブジェクト内でその瞬間に提示された映像に切り替わるべきである。
【００７２】
いくつかの実現可能な実装形態では、広角360度映像の出力のために、サーバは全方向ビデオに対応するビューポート範囲内のパノラマ空間（またはパノラマ空間オブジェクトと呼ばれる）を複数の空間オブジェクトに分割することができる。各空間オブジェクトは、ユーザの1つのサブビューポートに対応することができる。複数のサブビューポートは、完全な人間の目の観察ビューポートにつなぎ合わされる。各空間オブジェクトは、パノラマ空間の1つのサブ領域に対応する。すなわち、人間の目のビューポート（以下、ビューポートと呼ばれる）は、分割後に取得される1つまたは複数の空間オブジェクトに対応することができる。ビューポートに対応する空間オブジェクトは、人間の目のビューポート範囲内のコンテンツオブジェクトに対応するすべての空間オブジェクトである。人間の目の観察ビューポートは動的に変更されてよい。しかしながら、ビューポート範囲は、通常、120度×120度であってよい。120度×120度の人間の目のビューポート範囲内のコンテンツオブジェクトに対応する空間オブジェクトには、分割を介して取得される1つまたは複数の空間オブジェクト、たとえば、図1のブロック1に対応するビューポート1およびブロック2に対応するビューポート2を含んでよい。さらに、クライアントは、MPDを使用することにより、空間オブジェクトごとにサーバによって準備されたビデオビットストリームの空間情報を取得することができ、次いで、クライアントは、ビューポート要件に基づいてサーバに、時間期間内の1つまたは複数の空間オブジェクトに対応する1つまたは複数のビデオビットストリームセグメントを要求し、ビューポート要件に基づいて対応する空間オブジェクトを出力することができる。クライアントは、同じ時間期間内に、360度ビューポート範囲内のすべての空間オブジェクトに対応するビデオビットストリームセグメントを出力して、360度パノラマ空間全体の時間期間内に完全な映像を出力し表示する。
【００７３】
分割による360度空間オブジェクトの具体的な実装形態では、サーバは最初に球面を平面にマッピングし、平面を空間オブジェクトに分割してもよい。具体的には、サーバは、経度および緯度のマッピング方式で、球面を経度および緯度の平面図にマッピングすることができる。図2は、本発明の一実施形態による、空間オブジェクトの概略図である。サーバは、球面を経度および緯度の平面図にマッピングし、経度および緯度の平面図を複数の空間オブジェクトA〜Iに分割することができる。さらに、サーバは、代替として、球面を立方体にマッピングし、次いで、立方体の複数の表面を展開して平面図を取得することができ、またはサーバは、球面を別の多面体にマッピングし、次いで、多面体の複数の表面を展開して平面図を取得することができる。あるいは、サーバは、より多くのマッピング方式で球面を平面にマッピングすることができる。これは、実際のアプリケーションシナリオの要件に基づいて具体的に決定されてよく、本明細書では限定されない。以下で、図2を参照して、経度および緯度のマッピング方式に基づく説明を提供する。図2に示されたように、球面のパノラマ空間を複数の空間オブジェクトA〜Iに分割した後、サーバは、空間オブジェクトごとにビデオビットストリームの1つのグループを準備することができる。各空間オブジェクトは、ビデオビットストリームの1つのグループに対応する。クライアントユーザがビデオを視聴するためのビューポートを切り替えると、クライアントは、ユーザによって選択された新しいビューポートに基づいて、新しい空間オブジェクトに対応するビットストリームを取得し、さらに、新しいビューポート内で、新しい空間オブジェクトに対応するビットストリームのビデオコンテンツを提示することができる。
【００７４】
ビデオを制作するとき、ビデオプロデューサ（以下、作者と呼ばれる）は、ビデオのプロットの要件に基づいて、ビデオ再生用のメインプロットラインを設計することができる。ビデオ再生プロセスでは、ユーザは、プロットについて知るためにメインプロットラインに対応する映像を視聴するだけでよく、別の映像はオプションである。ビデオ再生プロセスでは、クライアントは、ビデオデータ用の送信リソースおよび記憶空間リソースを節約し、ビデオデータの処理効率を上げるために、再生用のプロットに対応する映像を選択することができ、別の映像を提示しなくてよいことが分かる。メインプロットを設計した後、作者は、メインプロットラインに基づいて、ビデオ再生中の各再生の瞬間にユーザに提示される映像を指定することができる。メインプロットラインのプロットは、すべての再生の瞬間に時系列で映像をつなぎ合わせることによって取得されてよい。各再生の瞬間にユーザに提示されるべき映像は、各再生の瞬間に対応する空間オブジェクトに提示されるべき映像、すなわち、この時間期間内に空間オブジェクト内で提示されるべき映像である。具体的な実装形態では、各再生の瞬間に提示されるべき映像に対応するビューポートは、作者ビューポートとして設定されてよく、作者ビューポート内の映像が提示される空間オブジェクトは、作者空間オブジェクトとして設定されてよく、作者ビューポートオブジェクトに対応するビットストリームは、作者ビューポートビットストリームとして設定されてよい。作者ビューポートビットストリームは、複数のビデオフレームのビデオフレームデータ（複数のビデオフレームの符号化データ）を含む。各ビデオフレームは1つのピクチャとして提示されてよい。すなわち、作者ビューポートビットストリームは複数のピクチャに対応する。ビデオ再生プロセスでは、各再生の瞬間に、作者ビューポートに提示されるピクチャは、ビデオ全体で提示されるべきパノラマピクチャ（またはVRピクチャもしくは全方向ピクチャと呼ばれる）の一部にすぎない。様々な再生の瞬間に、作者ビューポートに対応するピクチャに関連付けられた空間オブジェクトの空間情報は、異なっていても同じであってもよい。
【００７５】
作者が各再生の瞬間での作者ビューポートを設計した後、ビューポートに対応する領域情報は、メタデータトラックにカプセル化されてよい。メタデータトラックを受信した後、クライアントは、メタデータトラック内で搬送される領域に対応するビデオビットストリームをサーバに要求し、ビデオビットストリームを復号することができる。次いで、作者ビューポートに対応するプロット画像がユーザに提示されてよい。サーバは、作者ビューポート以外のビューポートに対応する（非作者ビューポート、すなわち、静的ビューポートビットストリームとして設定される）ビットストリームをクライアントに送信する必要がなく、それにより、ビデオデータ用の送信帯域幅などのリソースが節約される。
【００７６】
作者ビューポートは、事前設定された空間オブジェクトに提示されるべき、ビデオのプロットに基づいて作者によって設定されたピクチャであり、作者空間オブジェクトは、異なる再生の瞬間において異なっていても同じであってもよい。したがって、作者ビューポートは、再生の瞬間に絶えず変更されるビューポートであり、作者空間オブジェクトは、その位置が絶えず変更される動的な空間オブジェクトであることが分かる。すなわち、パノラマ空間内のすべての再生の瞬間に対応する作者空間オブジェクトの位置は、完全に同じではない。図2に示された空間オブジェクトは、事前設定された規則に従って分割を介して取得され、パノラマ空間内のそれらの相対位置が固定されている空間オブジェクトである。任意の再生の瞬間に対応する作者空間オブジェクトは、必ずしも図2に示された固定空間オブジェクトの1つではなく、グローバル空間内の相対位置が絶えず変化する空間オブジェクトである。
【００７７】
空間情報の可能な実装形態では、空間情報は、空間オブジェクトの中心点の位置情報、または空間オブジェクトの左上点の位置情報を含んでよく、空間情報は、空間オブジェクトの幅および高さをさらに含んでよい。
【００７８】
空間情報に対応する座標系が角座標系であるとき、空間情報はヨー角を使用して記述されてよく、または空間情報に対応する座標系がピクセル座標系であるとき、空間情報は、経度および緯度のグラフ内の空間位置を使用するか、もしくは別の立体幾何図形を使用して記述されてよい。このことは本明細書では限定されない。空間情報がヨー角を使用して記述される場合、ピッチ（pitch）角θ、ヨー（yaw）角ψ、ロール（roll）角Φなどは、角度範囲の幅および高さを表すために使用される。図3は、パノラマ空間内の空間オブジェクトの中心点の相対位置の概略図である。図3では、点Oは、360度VRパノラマビデオ球面ピクチャに対応する球面中心であり、VRパノラマピクチャを視聴するための人間の目の位置と見なされてよい。点Aはターゲット空間オブジェクトの中心点である。CおよびFは、ターゲット空間オブジェクトの水平軸に沿って、点Aを通り、ターゲット空間オブジェクト内にある円弧上の境界点である。EおよびDは、ターゲット空間オブジェクトの垂直軸に沿って、点Aを通り、ターゲット空間オブジェクト内にある境界点である。Bは、球経線に沿った点Aが赤道に投影される点であり、Iは、赤道上の水平方向の開始座標点である。要素は以下の通りに記載される。
【００７９】
ピッチ角は、垂直方向にあり、ターゲット空間オブジェクト内のピクチャの中心位置がパノラマ球面（すなわち、グローバル空間）ピクチャ内にマッピングされた点の偏向角、たとえば、図3の∠AOBである。
【００８０】
ヨー角は、水平方向にあり、ターゲット空間オブジェクト内のピクチャの中心位置がパノラマ球面ピクチャ内にマッピングされた点の偏向角、たとえば、図3の∠IOBである。
【００８１】
ロール角は、球の中心とヨー角での空間オブジェクト内のピクチャの中心位置がパノラマ球面ピクチャ内でマッピングされる点との間の線の方向の回転角、たとえば、図3の∠DOBである。
【００８２】
ピッチ角は、角度範囲の高さ（角座標系内のターゲット空間オブジェクトの高さ）、すなわち、空間オブジェクト内にあり、パノラマ球面ピクチャ内にあるピクチャのビューポートの高さを示すために使用される。ピッチ角は、垂直方向のビューポートの最大角度、たとえば、図3の∠DOEによって表される。ヨー角は、角度範囲の幅（角座標系内のターゲット空間オブジェクトの幅）、すなわち、ターゲット空間オブジェクト内にあり、パノラマ球面ピクチャ内にあるピクチャのビューポートの幅を示すために使用される。ヨー角は、水平方向のビューポートの最大角度、たとえば、図3の∠COFによって表される。
【００８３】
空間情報の別の可能な実装形態では、空間情報は、空間オブジェクトの左上点の位置情報と、空間オブジェクトの右下点の位置情報とを含んでよい。
【００８４】
空間情報のさらに別の可能な実装形態では、空間オブジェクトが長方形ではないとき、空間情報は、空間オブジェクトの形状タイプ、空間オブジェクトの半径、および空間オブジェクトの周長のうちの少なくとも1つを含んでよい。
【００８５】
いくつかの実施形態では、空間情報は、空間オブジェクトの空間回転情報を含んでよい。
【００８６】
いくつかの実施形態では、空間情報は、空間情報データまたは空間情報トラック（track）にカプセル化されてよい。空間情報データは、ビデオデータのビットストリーム、ビデオデータのメタデータ、またはビデオデータと無関係のファイルであってよい。空間情報トラックは、ビデオデータと無関係のトラックであってよい。
【００８７】
いくつかの実施形態では、空間情報は、ビデオの空間情報メタデータ（track matedata）にカプセル化されてよい。たとえば、空間情報はcovi boxなどの同じboxにカプセル化される。
【００８８】
いくつかの実施形態では、ターゲット空間オブジェクトの幅および高さを記述するために使用される座標系が図4に示されている。球上のハッチング部分はターゲット空間オブジェクトを表し、ターゲット空間オブジェクトの4つの角度の頂点はB、E、G、およびIである。図4では、Oは360度VRパノラマビデオ球面ピクチャに対応する球の中心であり、頂点B、E、G、およびIは、球の中心を通る円（円は、各々球の中心Oを円の中心として使用し、円の半径は、各々360度VRパノラマビデオ球面ピクチャに対応する球の半径であり、円はz軸を通り、2つの円が存在し、1つの円は点B、A、I、およびOを通り、他の円は点E、F、G、およびOを通る）と、x軸およびy軸に平行な円（円は、各々球の中心Oを円の中心として使用せず、2つの円が存在し、2つの円は互いに平行であり、1つの円は点B、D、およびEを通り、他の円は点I、H、およびGを通る）との間の交点の球上の点である。Cはターゲット空間オブジェクトの中心点である。辺DHに対応する角度はターゲット空間オブジェクトの高さとして表され、辺AFに対応する角度はターゲット空間オブジェクトの幅として表される。辺DHおよび辺AFは点Cを通る。辺BI、辺EG、および辺DHに対応する角度は同じであり、辺BE、辺IG、および辺AFに対応する角度は同じである。辺BEに対応する角度の頂点はJであり、Jは、z軸とB、D、およびEを通る円との間の交点である。それに対応して、辺IGに対応する角度の頂点は、z軸とI、H、およびGを通る円との間の交点である。辺AFに対応する角度の頂点は点Oであり、辺BI、辺EG、および辺DHに対応する角度の頂点も各々点Oである。
【００８９】
前述の説明は一例にすぎないことに留意されたい。あるいは、ターゲット空間オブジェクトは、球の中心を通る2つの大きい円が2つの平行な円と交差した後に取得されてよい。あるいは、ターゲット空間オブジェクトは、2つのヨー角円が2つのピッチ角円と交差した後に取得されてよい。ヨー角円の場合、円上の点は同じヨー角をもち、ピッチ角円の場合、円上の点は同じピッチ角をもつ。あるいは、ターゲット空間オブジェクトは、2つの経度の円が2つの緯度の円と交差した後に取得されてよい。
【００９０】
いくつかの実施形態では、ターゲット空間オブジェクトの幅および高さを記述するために使用される座標系が図5に示されている。球上のハッチング部分はターゲット空間オブジェクトを表し、ターゲット空間オブジェクトの4つの角度の頂点はB、E、G、およびIである。図5では、Oは360度VRパノラマビデオ球面ピクチャに対応する球の中心であり、頂点B、E、G、およびIは、z軸を通る円（円は、各々球の中心Oを円の中心として使用し、円の半径は、各々360度VRパノラマビデオ球面ピクチャに対応する球の半径であり、2つの円が存在し、1つの円は点B、A、およびIを通り、他の円は点E、F、およびGを通る）と、y軸を通る円（円は、各々球の中心Oを円の中心として使用し、円の半径は、各々360度VRパノラマビデオ球面ピクチャに対応する球の半径であり、2つの円が存在し、1つの円は点B、D、およびEを通り、他の円は点I、H、およびGを通る）との間の交点の球上の点である。Cはターゲット空間オブジェクトの中心点である。辺DHに対応する角度はターゲット空間オブジェクトの高さとして表され、辺AFに対応する角度はターゲット空間オブジェクトの幅として表される。辺DHおよび辺AFは点Cを通る。辺BI、辺EG、および辺DHに対応する角度は同じであり、辺BE、辺IG、および辺AFに対応する角度は同じである。辺BEに対応する角度の頂点はJであり、Jは、z軸と、2つの点BおよびEを通り、x軸およびy軸に平行な円との間の交点である。辺IGに対応する角度の頂点は、z軸と、2つの点IおよびGを通り、x軸およびy軸に平行な円との間の交点である。辺AFに対応する角度の頂点は点Oであり、辺BIに対応する角度の頂点は点Lであり、点Lは、y軸と、2つの点BおよびIを通り、z軸およびx軸に平行な円との間の交点である。辺EGに対応する角度の頂点は、y軸と、2つの点EおよびGを通り、z軸およびy軸に平行な円との間の交点である。辺DHに対応する角度の頂点も点Oである。
【００９１】
前述の説明は一例にすぎないことに留意されたい。あるいは、ターゲット空間オブジェクトは、x軸を通る2つの円がz軸を通る2つの円と交差した後に取得されてよい。あるいは、ターゲット空間オブジェクトは、x軸を通る2つの円がy軸を通る2つの円と交差した後に取得されてよい。あるいは、ターゲット空間オブジェクトは、球の中心を通る4つの円が交差した後に取得されてよい。
【００９２】
いくつかの実施形態では、ターゲット空間オブジェクトの幅および高さを記述するために使用される座標系が図6に示されている。球上のハッチング部分はターゲット空間オブジェクトを表し、ターゲット空間オブジェクトの4つの角度の頂点はB、E、G、およびIである。図6では、Oは360度VRパノラマビデオ球面ピクチャに対応する球の中心であり、頂点B、E、G、およびIは、x軸およびz軸に平行な円（円は、各々球の中心Oを円の中心として使用せず、2つの円が存在し、2つの円は互いに平行であり、2つの円が存在し、1つの円は点B、A、およびIを通り、他の円は点E、F、およびGを通る）と、x軸およびy軸に平行な円（円は、各々球の中心Oを円の中心として使用せず、2つの円が存在し、2つの円は互いに平行であり、1つの円は点B、D、およびEを通り、他の円は点I、H、およびGを通る）との間の交点の球上の点である。Cはターゲット空間オブジェクトの中心点である。辺DHに対応する角度はターゲット空間オブジェクトの高さとして表され、辺AFに対応する角度はターゲット空間オブジェクトの幅として表される。辺DHおよび辺AFは点Cを通る。辺BI、辺EG、および辺DHに対応する角度は同じであり、辺BE、辺IG、および辺AFに対応する角度は同じである。辺BE、辺IG、および辺AFに対応する角度の頂点は各々点Oであり、辺BI、辺EG、および辺DHに対応する角度の頂点も各々点Oである。
【００９３】
前述の説明は一例にすぎないことに留意されたい。あるいは、ターゲット空間オブジェクトは、y軸およびz軸に平行で球の中心を通らない2つの円が、y軸およびx軸に平行で球の中心を通らない2つの円と交差した後に取得されてよい。あるいは、ターゲット空間オブジェクトは、y軸およびz軸に平行で球の中心を通らない2つの円が、z軸およびx軸に平行で球の中心を通らない2つの円と交差した後に取得されてよい。
【００９４】
図5の点Jおよび点Lを取得する方式は、図4の点Jを取得する方式と同じである。辺BEに対応する角度の頂点は点Jであり、辺BIに対応する角度の頂点は点Lである。図6では、辺BEおよび辺BIに対応する頂点は各々点Oである。
【００９５】
図11（a）および図11（b）は、本発明の一実施形態による、空間オブジェクトとビデオデータとの間のマッピング関係の概略図である。図11（a）は、全方向ビデオ（左側の大きいピクチャ）および全方向ビデオのサブ領域（右側の小さいピクチャ）を示す。図11（b）は、全方位ビデオに対応するビデオ空間（球面）、および全方位ビデオのサブ領域に対応する空間オブジェクト（球面上の陰影部分）を示す。
【００９６】
球面上の領域（region）の時限メタデータトラック（timed metadata track）は、既存のOMAF規格内で指定されている。メタデータトラックでは、メタデータboxは球面上のregionを記述するメタデータを含み、メディアデータboxは球面上のregionに関する情報を含む。メタデータboxは、時限メタデータトラックの意図、すなわち、球面上のregionの使用を記述する。規格は、2つのタイプの時限メタデータトラック：推奨ビューポートの時限メタデータトラック（The recommended viewport timed metadata track）および初期視点トラック（the initial viewpoint timed metadata track）を記述している。推奨ビューポートトラックは、プレゼンテーション用に端末に推奨されるビューポートの領域を記述し、初期視点トラックは、全方向ビデオを視聴するための初期プレゼンテーション方向を記述する。
【００９７】
以下では、本発明の一実施形態のアプリケーションシナリオを記載する。
【００９８】
図7に示されたように、サーバ側701はコンテンツ準備7011およびコンテンツサービス7012を含む。
【００９９】
コンテンツ準備7011は、メディアデータ取込みデバイスまたはメディアデータトランスコーダであってよく、ストリーミングメディアのメディアコンテンツおよび関連するメタデータなどの情報を生成することに関与する。たとえば、コンテンツ準備7011は、メディアファイル（ビデオ、オーディオなど）の圧縮、カプセル化、および記憶／送信を担当する。コンテンツ準備7011は、メタデータ情報、およびメタデータのソースが配置されたファイルを生成することができる。メタデータは、メタデータトラックにカプセル化されてよく、またはメタデータは、ビデオデータトラックのSEIにカプセル化されてよい。メタデータトラックのサンプル（sample）は、コンテンツジェネレータによって指定された全方向ビデオの一部の領域、またはコンテンツプロデューサによって指定された全方向ビデオの一部の領域を指す。メタデータのソースは、メタデータトラックにカプセル化されるか、またはMPD内で搬送される。メタデータがSEIにカプセル化される場合、メタデータのソース情報はSEI内で搬送されてよい。一実装形態では、メタデータのソース情報は、メタデータがコンテンツのプロデューサまたはディレクタによって推奨された視聴領域を示すことを示すことができる。
【０１００】
コンテンツサービス7012は、ネットワークノード、たとえば、コンテンツ配信ネットワーク（Content distribution network、CDN）またはプロキシサーバであってよい。コンテンツサービス7012は、コンテンツ準備7011から記憶されたデータまたは送信されるべきデータを取得し、端末側702にデータを転送することができる。あるいは、コンテンツサービス7012は、端末側702から端末によってフィードバックされた領域情報を取得し、フィードバックされた情報に基づいて領域メタデータトラックまたは領域SEI情報を生成し、領域情報のソースを搬送するファイルを生成することができる。領域メタデータトラックまたは領域SEI情報を生成することは、全方向ビデオの領域のフィードバックされた視聴情報に関する統計データを収集すること、ユーザが関心をもつ領域のサンプルを生成するために、収集された統計データに基づいて1つまたは複数の最も視聴された領域を選択すること、サンプルをメタデータトラックまたはSEIにカプセル化すること、およびトラック内の領域メタデータのソース情報をカプセル化するか、またはMPDに領域メタデータのソース情報を追加するか、またはSEIに領域メタデータのソース情報を追加することであってよい。情報のこのソースは、領域メタデータ情報がサーバの統計データに由来することを示し、メタデータトラックに記述された領域が、ほとんどのユーザが関心をもつ領域であることを示す。領域メタデータトラック内の領域情報または領域SEI内の領域情報は、代替として、サーバによって指定されたユーザによってフィードバックされた領域情報であってよい。領域メタデータトラックまたは領域SEIはフィードバックされた情報に基づいて生成され、領域メタデータのソース情報は領域メタデータトラックまたはMPDまたはSEI内で搬送される。領域情報のソースは領域メタデータが由来するユーザを記述する。
【０１０１】
コンテンツ準備7011およびコンテンツサービス7012は、サーバの同じハードウェアデバイス上に配置されてもよく、異なるハードウェアデバイス上に配置されてもよいことが理解されよう。コンテンツ準備7011とコンテンツサービス7012の両方は、1つまたは複数のハードウェアデバイスを含んでよい。
【０１０２】
端末側702はメディアデータを取得および提示し、端末側702は、全方向ビデオ内でユーザに提示されるコンテンツの領域情報を取得する。端末側702はコンテンツサービス側701に領域情報をフィードバックする。あるいは、端末側702は、メディアデータ、メタデータ、およびメタデータのソース情報を搬送するデータを取得する。端末側702は、メタデータのソース情報を構文解析し、端末ユーザによって選択されたメタデータのソースに基づいて対応するメタデータを構文解析して、メディアプレゼンテーション用の領域情報を取得する。
【０１０３】
可能な実装形態では、モジュールがメタデータトラックのソース情報を処理する方式は以下の通りである。
【０１０４】
モジュールはメタデータのソース情報を取得する。ソース情報は、メタデータに関連付けられた領域がコンテンツプロデューサもしくはディレクタまたは指定されたユーザによって推奨されていることを示すことができ、またはメタデータに関連付けられた領域が、ユーザが関心をもち、関連する統計データに基づいて取得された領域であり得ることを示すことができる。あるいは、ソース情報は、全方向ビデオを視聴するためのコンテンツプロデューサもしくはディレクタによってユーザに推奨されたビューポート、またはユーザが最も関心をもち、サーバによって推奨された領域、またはユーザによって推奨されたビューポートを示すことができる。
【０１０５】
モジュールは領域情報を取得する。本明細書の領域情報は領域のいくつかのメタデータを指す。領域情報は、コンテンツプロデューサもしくはディレクタによって推奨もしくは指定された領域、またはユーザが最も関心をもち、ユーザフィードバック情報に関する統計データを収集することによって取得された領域、または端末ユーザが全方向ビデオを視聴するための領域を示すことができる。領域は、2次元平面上の領域、または球面上の領域であってよい。二次元平面領域情報は、二次元平面上の領域の左上ピクセルの座標位置、ならびに領域の幅および高さによって表される。領域が球面上にある場合、領域情報は、球面上の領域の中心点の位置、ならびに球面上の領域のヨー角およびピッチ角によって表される。球面上の領域を示す前述の関連する例、たとえば、図1〜図6に示された方式に対して参照が行われてよい。一実施形態では、領域は、代替として、球面上の方向または球面上の点であってよい。この場合、領域は幅および高さに関する情報なしに表される。
【０１０６】
モジュールは、関連するメタデータおよびメタデータのソースをメタデータトラックにカプセル化してメタデータトラックファイルを生成するか、またはメタデータをメタデータトラックにカプセル化してメタデータトラックファイルを生成し、MPDにメタデータのソースを追加してMPDファイルを生成するか、またはメタデータおよびメタデータのソースをSEIにカプセル化してビットストリームファイルを生成する。モジュールによって生成されたファイルは、ローカルに記憶されるか、または受信端に送信されてよく、受信端は端末側またはコンテンツサービス側にあってよい。
【０１０７】
メタデータトラックのソース情報を処理するためのモジュールは、図7のコンテンツ準備7011、コンテンツサービス7012、または端末側702の中の単一のサブモジュールであってよく、または関連する機能は前述のデバイスに統合されてよい。
【０１０８】
本発明の実施形態の技術的解決策は、主に、コンテンツ準備側（トランスコーダ）、インテリジェントネットワークノード（CNDまたはプロキシサーバ）、および端末プレーヤ側で実施される。
【０１０９】
領域メタデータを生成するとき、トランスコーディングサーバ、ネットワークサーバ、および端末は、メタデータを独立したトラックまたはSEIにカプセル化し、メタデータのソースをメタデータトラックまたはSEIまたはMPDファイルにカプセル化する。
【０１１０】
図8に示されたように、本発明の一態様の一実施形態では、メディア情報処理方法S80が開示される。方法S80は以下のステップを含む。
【０１１１】
S801：メディアデータのメタデータ情報を取得し、メタデータ情報はメタデータのソース情報を含み、ソース情報はメディアデータのレコメンダを示すために使用され、メディアデータは全方向メディアデータである。
【０１１２】
S802：メタデータのソース情報に基づいてメディアデータを処理する。
【０１１３】
図9に示されたように、本発明の一態様の一実施形態では、メディア情報処理装置90が開示される。装置90は情報取得モジュール901および処理モジュール902を含む。情報取得モジュール901は、メディアデータのメタデータ情報を取得するように構成される。メタデータ情報はメタデータのソース情報を含み、ソース情報はメディアデータのレコメンダを示すために使用され、メディアデータは全方向メディアデータである。処理モジュール902は、メタデータのソース情報に基づいてメディアデータを処理するように構成される。
【０１１４】
本発明のこの実施形態の可能な実装形態では、メタデータのソース情報はメタデータトラック内で搬送される。
【０１１５】
メタデータトラックでは、メタデータトラック内のサンプルデータのソースを記述するために1つのboxが新しく追加され、トラックのソースがbox内で記述される。この実施形態では、新しく追加されたboxの形式は以下の通りである。
SourceInformationBox extends Box（‘sinf’）｛
Unsigned int（8）source＿type；／／メタデータのソースを示す：ディレクタ／事前に収集された統計データ／人気者による事前設定
｝
【０１１６】
この例では、source＿typeは、boxが配置されたトラックのソース情報を記述する。source＿typeが0に等しいとき、それはトラック内の領域情報がビデオプロデューサによって推奨されていることを示すか、または、それはトラック内の領域情報がコンテンツプロデューサもしくはディレクタに由来することを示し、たとえば、それはトラック内の領域情報がディレクタによって推奨されたビューポートに由来することを示す。端末側は、トラック内の情報を使用することにより、ディレクタがユーザに提示することを予想するメディアコンテンツをユーザに提示することができる。source＿typeが1に等しいとき、それはトラック内の領域情報が、ほとんどのユーザが関心をもつ領域であることを示すか、または、それはトラック内の領域情報が、ユーザが最も関心をもち、統計データ収集を介して取得された領域に由来することを示す。端末側は、トラック内の情報を使用することにより、ほとんどのユーザが関心をもち、全方向メディア内にある領域をユーザに提示することができる。source＿typeが2に等しいとき、それはトラック内の領域情報が、端末ユーザが全方向メディアを視聴するための領域であることを示すか、または、それはトラック内の領域情報が特定の人物に由来することを示す。端末側は、ユーザが全方向メディアを視聴するためのビューポートを再現することができる。
【０１１７】
前述のtypeは、本発明のこの実施形態の理解を助けるために使用される一例にすぎず、具体的な制限ではないことが理解されよう。typeの値は別の値であってよく、または別のソースタイプを表すために使用されてよい。
【０１１８】
端末側で取得されたメタデータトラック内の情報を処理する手順は以下の通りである。
1．端末がメタデータトラックを取得し、メタデータトラック内のメタデータbox（moov box）を構文解析し、boxを構文解析してsinf boxを取得する。
2．端末がsinf boxを構文解析してSource−type情報を取得する。source＿typeが0に等しい場合、トラック内の領域情報はビデオプロデューサによって推奨されている。source＿typeが1に等しい場合、トラック内の領域情報はほとんどのユーザが関心をもつ領域である。source＿typeが2に等しい場合、トラック内の領域情報は端末ユーザが全方向メディアを視聴するための領域である。端末によって取得されたメタデータ内のsource＿typeが0に等しいと仮定する。
3．端末が情報のソースをユーザに提示し、ユーザの選択を受け入れる。
4．ユーザがビデオプロデューサまたはディレクタによって推奨されたビューポート内で視聴することを選択した場合、端末がメタデータトラック内のサンプルを構文解析して領域情報を取得し、取得された領域に対応する全方向メディアの中のメディアをユーザに提示する。
【０１１９】
メタデータのソース情報はメタデータトラック内で搬送される。ソース情報は、メタデータが全方向ビデオプロデューサ、または全方向ビデオを視聴するユーザ、またはユーザが関心をもち、統計データ収集を介して取得されたビューポートのデータに由来することを示す。あるいは、情報によって記述されるメタデータの目的は、メタデータが全方向ビデオプロデューサの推奨、または全方向ビデオを視聴するユーザの推奨、または使用されたビューポートに関する統計データを収集して取得されたデータに基づく推奨に由来することである。領域メタデータを受信すると、クライアントは異なるソースからのメタデータを区別することができる。複数の領域メタデータが存在する場合、ユーザは個人的な要件に基づいて視聴する推奨領域を選択することができる。
【０１２０】
本発明の一実装形態では、メタデータのソース情報はMPD内で搬送される。
【０１２１】
ソース情報記述子は、ISO／IEC23009−1内で指定された標準要素Supplemental Property／Essential Propertyに追加され、記述子のschemeは＝“urn：mpeg：dash：purpose”であり、記述子がMPDの表現内の情報のソースを提供することを示す。記述子の値は以下の表に記載される。
【０１２２】
【表１】
2020526969.tif 000003
【０１２３】
前述の記述子は、MPDのadaptationSet要素またはMPDのrepresentation要素内にあってよい。以下の具体例では、記述子はrepresentation要素内にある。
＜？xml version＝“1．0”encoding＝“UTF−8”？＞
＜MPD
xmlns＝“urn：mpeg：dash：schema：mpd：2011”
type＝“static”
mediaPresentationDuration＝“PT10S”
minBufferTime＝“PT1S”
profiles＝“urn：mpeg：dash：profile：isoff−on−demand：2011”＞
＜Period＞
＜！−メタデータトラック−−＞
＜AdaptationSet segmentAlignment＝“true”subsegmentAlignment＝“true”subsegmentStartsWithSAP＝“1”＞
＜Representationid＝“metadata”．．．bandwidth＝“100”＞
＜EssentialProperty schemeIdUri＝“urn：mpeg：dash：purpose”value＝“0”／＞
＜BaseURL＞metadata．mp4＜／BaseURL＞
＜SegmentBase indexRangeExact＝“true”indexRange＝“837−988”／＞
＜／Representation＞
＜／AdaptationSet＞
．．．
＜／Period＞
＜／MPD＞
【０１２４】
この例では、表現内のソース情報は記述子を使用して記述されている。あるいは、表現のソースを記述するために、adaptationSet要素またはrepresentation要素に1つの属性が追加されてよい、たとえば、属性はsourceTypeである。sourceTypeが0に等しいとき、それはトラック内の領域情報がビデオプロデューサによって推奨されていることを示すか、または、それはトラック内の領域情報がコンテンツプロデューサもしくはディレクタに由来することを示し、たとえば、それはトラック内の領域情報がディレクタによって推奨されたビューポートに由来することを示す。端末側は、トラック内の情報を使用することにより、ディレクタがユーザに提示することを予想するメディアコンテンツをユーザに提示することができる。sourceTypeが1に等しいとき、それはトラック内の領域情報がほとんどのユーザが関心をもつ領域であることを示すか、または、それはトラック内の領域情報がユーザが最も関心をもち、統計データ収集を介して取得された領域に由来することを示す。端末側は、トラック内の情報を使用することにより、ほとんどのユーザが関心をもち、全方向メディア内にある領域をユーザに提示することができる。sourceTypeが2に等しいとき、それはトラック内の領域情報が、端末ユーザが全方向メディアを視聴するための領域であることを示すか、または、それはトラック内の領域情報が特定の人物に由来することを示す。端末側は、ユーザが全方向メディアを視聴するためのビューポートを再現することができる。
【０１２５】
MPDの例は以下の通りである。
＜？xml version＝“1．0”encoding＝“UTF−8”？＞
＜MPD
xmlns＝“urn：mpeg：dash：schema：mpd：2011”
type＝“static”
mediaPresentationDuration＝“PT10S”
minBufferTime＝“PT1S”
profiles＝“urn：mpeg：dash：profile：isoff−on−demand：2011”＞
＜Period＞
＜！−メタデータトラック−−＞
＜AdaptationSet segmentAlignment＝“true”subsegmentAlignment＝“true”subsegmentStartsWithSAP＝“1”＞
＜Representationid＝“metadata”．．．bandwidth＝“100”soureceType＝“0”＞
＜BaseURL＞metadata．mp4＜／BaseURL＞
＜SegmentBase indexRangeExact＝“true”indexRange＝“837−988”／＞
＜／Representation＞
＜／AdaptationSet＞
．．．
＜／Period＞
＜／MPD＞
【０１２６】
MPDの前述の2つの例では、表現によって記述されたmetadata．mp4ファイル内の領域情報がビデオプロデューサによって推奨されていることを示すために、記述子および属性がそれぞれ使用される。
【０１２７】
端末側で取得された例の中の情報を処理する手順は以下の通りである。
1．端末がMPDファイルを取得および構文解析し、構文解析後に取得されたadaptationSet要素またはrepresentation要素が、そのschemeがurn：mpeg：dash：purposeである記述子を含む場合、記述子のvalueを構文解析する。
2．valueが0に等しい場合、表現内の領域情報はビデオプロデューサによって推奨されている。valueが1に等しい場合、表現内の領域情報はほとんどのユーザが関心をもつ領域である。valueが2に等しい場合、表現内の領域情報は端末ユーザが全方向メディアを視聴するための領域である。端末によって取得されたMPD内のvalueが0に等しいと仮定する。
3．端末が情報のソースをユーザに提示し、ユーザの選択を受け入れる。
4．ユーザがビデオプロデューサまたはディレクタによって推奨されたビューポート内で視聴することを選択した場合、端末がセグメントを取得するためにMPD内の情報に基づいてrepresentation内のセグメントに対する要求を構築し、セグメントの領域情報を構文解析して領域情報を取得し、取得された領域に対応する全方向メディアの中のメディアをユーザに提示する。
【０１２８】
本発明の一実施形態では、メタデータのソース情報はSEI内で搬送される。
【０１２９】
たとえば：
【０１３０】
【表２】
2020526969.tif 000004
【０１３１】
前述の構文内のSRCは、具体的な値、たとえば、190を表す。このことは本明細書では限定されない。SEIのペイロードタイプがSRCであるとき、SEIの構文は以下の表に記載される。
【０１３２】
【表３】
2020526969.tif 000005
【０１３３】
このペイロード内のsource＿typeは、SEIによって記述された領域情報のソース情報を記述する。source＿typeが0に等しいとき、それはSEIによって記述された領域情報がビデオプロデューサによって推奨されていることを示すか、または、それはSEIによって記述された領域情報がコンテンツプロデューサもしくはディレクタに由来することを示し、たとえば、それはSEIによって記述された領域情報がディレクタによって推奨されたビューポートに由来することを示す。端末側は、SEIによって記述された領域情報を使用することにより、ディレクタがユーザに提示することを予想するメディアコンテンツをユーザに提示することができる。source＿typeが1に等しいとき、それはSEIによって記述された領域情報が、ほとんどのユーザが関心をもつ領域であることを示すか、または、それはSEIによって記述された領域情報が、ユーザが最も関心をもち、統計データ収集を介して取得された領域に由来することを示す。端末側は、SEIによって記述された領域情報を使用することにより、ほとんどのユーザが関心をもち、全方向メディア内にある領域をユーザに提示することができる。source＿typeが2に等しいとき、それはSEIによって記述された領域情報が、端末ユーザが全方向メディアを視聴するための領域であることを示すか、または、それはSEIによって記述された領域情報が特定の人物に由来することを示す。端末側は、ユーザが全方向メディアを視聴するためのビューポートを再現することができる。
【０１３４】
端末側で取得されたビデオビットストリームを処理する手順は以下の通りである。
1．端末がビデオビットストリームを取得し、ビットストリーム内のNALUヘッダ情報を構文解析し、構文解析後に取得されたヘッダ情報タイプがSEIタイプである場合、SEI NALUを構文解析してSEIのペイロードタイプを取得する。
2．構文解析後に取得されたペイロードタイプが190である場合、それは領域メタデータのソース情報がSEI内で搬送されることを示す。端末は構文解析を続行してSource−type情報を取得する。source＿typeが0に等しい場合、このトラック内の領域情報はビデオプロデューサによって推奨されている。source＿typeが1に等しい場合、このトラック内の領域情報はほとんどのユーザが関心をもつ領域である。source＿typeが2に等しい場合、このトラック内の領域情報は端末ユーザが全方向メディアを視聴するための領域である。SEI内の端末によって取得されたsource＿typeが0に等しいと仮定する。
3．端末が情報のソースをユーザに提示し、ユーザの選択を受け入れる。
4．ユーザがビデオプロデューサまたはディレクタによって推奨されたビューポート内で視聴することを選択した場合、端末がビデオビットストリーム内の領域情報を構文解析して領域情報を取得し、取得された領域に対応する全方向メディアの中のメディアをユーザに提示する。
【０１３５】
本発明の一実施形態では、前述の実施形態において列挙されたソース情報のタイプに加えて、ソース情報のセマンティクスはさらに拡張されてよい。
【０１３６】
たとえば：
【０１３７】
1．メタデータトラック内の構文拡張：
SourceInformationBox extends Box（‘sinf’）｛
．．．
unsigned int（5）［3］language；／／ISO−639−2／T language code
string sourceDescription；
｝
【０１３８】
セマンティクス：
language：後続の文字列の言語を示す。この値は、ISO−639−2／T内の言語コードワードを使用して様々な言語を表す。
sourceDescription：は文字列であり、領域メタデータのソースのコンテンツを指定する。sourceDescriptionはソースの説明を指定する。たとえば、この値は「a director’s cut」であってよく、メタデータが作者に由来するか、または作者によって推奨されていることを示す。あるいは、sourceDescriptionはレコメンダの名前を指定する。たとえば、この値は「Tom」であってよく、メタデータがTomに由来するか、またはTomによって推奨されていることを示す。
【０１３９】
2．MPD内の拡張：
【０１４０】
【表４】
2020526969.tif 000006
【０１４１】
3．SEI内の拡張：（構文のセマンティクスは前述のセマンティクスと同じである）
【０１４２】
【表５】
2020526969.tif 000007
【０１４３】
本発明の一実施形態では、前述の実施形態において列挙されたソース情報のタイプに加えて、ソース情報のセマンティクスはさらに拡張されてよい。
【０１４４】
たとえば：
【０１４５】
1．メタデータトラック内の構文拡張：
SourceInformationBox extends Box（‘sinf’）｛
．．．
Int（64）data；
｝
【０１４６】
セマンティクス：
Data：メタデータトラックが生成／推奨された時間、たとえば、2011年7月4日、月曜日、05：50：30 GMTを指定する。
【０１４７】
2．MPD内の拡張：
【０１４８】
【表６】
2020526969.tif 000008
【０１４９】
3．SEI内の拡張：（構文のセマンティクスは前述のセマンティクスと同じである）
【０１５０】
【表７】
2020526969.tif 000009
【０１５１】
本発明の一実施形態では、前述の実施形態において列挙されたソース情報のタイプに加えて、ソース情報のセマンティクスはさらに拡張されてよい。
【０１５２】
たとえば：
【０１５３】
1．メタデータトラック内の構文拡張：
SourceInformationBox extends Box（‘sinf’）｛
．．．
string reason＿description；
｝
【０１５４】
セマンティクス：
reason＿description：メタデータを推奨する理由または推奨されたメタデータに対応するビデオコンテンツの説明情報を指定する。
【０１５５】
2．MPD内の拡張：
【０１５６】
【表８】
2020526969.tif 000010
【０１５７】
3．SEI内の拡張：（構文のセマンティクスは前述のセマンティクスと同じである）
【０１５８】
【表９】
2020526969.tif 000011
【０１５９】
本発明の一実施形態では、前述の実施形態において列挙されたソース情報のタイプに加えて、ソース情報のセマンティクスはさらに拡張されてよい。
【０１６０】
たとえば：
【０１６１】
1．メタデータトラック内の構文拡張：
SourceInformationBox extends Box（‘sinf’）｛
．．．
string person＿description；
｝
【０１６２】
セマンティクス：
person＿description：推奨メタデータのユーザ年齢情報、または子供、若者、もしくは高齢者などの年齢範囲、または統計データ収集を介して取得された0〜10もしくは10〜20を指定する。
【０１６３】
2．MPD内の拡張：
【０１６４】
【表１０】
2020526969.tif 000012
【０１６５】
3．SEI内の拡張：（構文のセマンティクスは前述のセマンティクスと同じである）
【０１６６】
【表１１】
2020526969.tif 000013
【０１６７】
本発明の一実施形態では、SourceInformationBoxはscheme information boxに含まれてよい。
【０１６８】
構文：
aligned（8）class SourceInformationBox extends FullBox（‘inf’，0，0）｛
unsigned int（8）source＿type；
unsigned int（64）date；
unsigned int（32）ID＿lenght；
string sourceDescription
unsigned int（32）reason＿lenght；
string reason＿description
｝
【０１６９】
セマンティクス：
source＿typeは整数値をもち、メタデータのソースタイプを示す。異なる値は以下のソースタイプを示す。
0：メタデータはコンテンツプロデューサまたはディレクタに由来する。
1：メタデータはユーザが最も関心をもち、統計データ収集を介して取得された領域に由来する。
2：メタデータは特定の人に由来する。
別の値が予約されている。
【０１７０】
dateはメタデータが生成／推奨された時間を指定する。
【０１７１】
ID＿lenghtはID＿descriptionの長さを示し、この値はID＿descriptionの長さから1を引いて取得される。
【０１７２】
ID＿descriptionはレコメンダの名前を指定する。
【０１７３】
reason＿lenghtはreason＿descriptionの長さを示し、この値はreason＿descriptionの長さから1を引いて取得される。
【０１７４】
reason＿descriptionは、メタデータを推奨する理由または推奨されたメタデータに対応するビデオコンテンツの説明情報を指定する。
【０１７５】
SourceInformationBoxは、代替として、別の名前、たとえば、natrueInformationBoxを使用できることが理解されよう。
【０１７６】
可能な実装形態では、natrueInformationBoxの例は以下の通りである。
Box Type：‘ninf’
Container：Scheme Information box（‘schi’）
Mandatory：No
Quantity：Zero or one
natrueInformationBoxの構文は以下の通りである。
aligned（8）class natrueInformationBox extends FullBox（‘ninf’，0，0）｛
unsigned int（8）natrue＿type；
unsigned int（64）date；
unsigned int（32）ID＿lenght；
string ID＿description
unsigned int（32）reason＿lenght；
string reason＿description
｝
【０１７７】
本明細書では、natrue＿typeは整数値をもち、メタデータのソースタイプを示す。異なる値は以下のソースタイプを示す。
1：メタデータはコンテンツプロデューサまたはディレクタに由来する。
2：メタデータはユーザが最も関心をもち、統計データ収集を介して取得された領域に由来する。
3：メタデータは特定の人に由来する。
別の値が予約されている。
【０１７８】
dateはメタデータが生成／推奨された時間を指定し、dateは、秒単位で計算された整数時間であってもよく、別の時間形式で表現されてもよい。
【０１７９】
ID＿lenghtはID＿descriptionの長さを示し、この値はID＿descriptionの長さから1を引いて取得される。
【０１８０】
ID＿descriptionはレコメンダの名前を指定する。
【０１８１】
reason＿lenghtはreason＿descriptionの長さを示し、この値はreason＿descriptionの長さから1を引いて取得される。
【０１８２】
reason＿descriptionは、メタデータを推奨する理由または推奨されたメタデータに対応するビデオコンテンツの説明情報を指定する。
【０１８３】
具体例では：
【０１８４】
natrue＿type an integer that indicates the type of nature．（natrue＿typeは自然のタイプを示す整数である。）The following values for natrue＿type are specified：（natrue＿type用の以下の値が指定される。）
1：The recommended viewport timed metadata track is used for indicating a director’s cut．（1：推奨ビューポートの時限メタデータトラックは、director’s cutを示すために使用される。）
2：The recommended viewport timed metadata track is used for indicating the statistically most−viewed viewport．（2：推奨ビューポートの時限メタデータトラックは、統計的に最も視聴されたビューポートを示すために使用される。）
3：The recommended viewport timed metadata track is used for indicating a particular person or user．（3：推奨ビューポートの時限メタデータトラックは特定の人またはユーザを示すために使用される。）
Other values of natrue＿type are reserved．（natrue＿typeの他の値が予約されている。）
【０１８５】
date is an integer that declares the recommended time of the metadate（in seconds since midnight，Jan．1，1904，in UTC time）．（dateは（協定世界時1904年1月1日深夜からの秒単位で）メタデータの推奨時間を表す整数である。）
【０１８６】
ID＿lenght indicates the length in byte of the ID＿description field minus one．（ID＿lenghtはID＿descriptionフィールドのバイト単位の長さマイナス1を示す。）
【０１８７】
ID＿description specifies the name of the recommended person．（ID＿descriptionは推奨された人の名前を指定する。）It is a null−terminated string in UTF−8 characters containing a file group name．（それはファイルグループ名を含むUTF−8文字のヌルで終わる文字列である。）
【０１８８】
reason＿lenght indicates the length in byte of the reason＿description field minus one．（reason＿lenghtはreason＿descriptionフィールドのバイト単位の長さマイナス1を示す。）
【０１８９】
reason＿description specifies the recommended reason or the description of the media content corresponding to the metadata．（reason＿descriptionはメタデータに対応するメディアコンテンツの推奨理由または説明を指定する。）It is a null−terminated string in UTF−8 characters containing a file group name．（それはファイルグループ名を含むUTF−8文字のヌルで終わる文字列である。）
【０１９０】
本発明のすべての前述の実施形態における構文は、メディア（media）トラック内で搬送されてよい。たとえば、SourceInformationBoxまたはnatrueInformationBoxは、media trackのtref box内で搬送されてよい。ISO／IEC14496−12規格は、trefがtrack reference boxであることを指定し、boxは現在のメディアtrackに関連付けられたtrackを指定する。SourceInformationBoxまたはnatrueInformationBoxは、tref box の拡張であってよい。aligned（8）class SourceInformationBox extends tref（‘sinf’，0，0）．（aligned（8）クラスのSourceInformationBoxはtref（‘sinf’，0，0）を拡張する。）
【０１９１】
本発明の一実施形態では、メタデータの目的／ソースに関する情報は、代替として、sample entry typeによって表されてよい。たとえば、ほとんどのユーザが関心をもつ領域のsample entry typeは「mroi」であってよく、ユーザの推奨は「proi」であってよく、作者またはディレクタの推奨は「droi」であってよい。
【０１９２】
本発明の一実施形態では、端末側は、ユーザに推奨され得るメタデータトラックの説明情報をユーザに提示し、ユーザは説明情報に基づいて視聴する推奨を選択する。端末は、ユーザの選択に基づいて、選択に対応するメタデータトラックを取得し、取得されたメタデータトラックを構文解析してトラック内の領域情報を取得し、領域情報に基づいて全方向メディアを提示する。あるいは、端末は、ユーザによって選択された推奨に関する情報をコンテンツサーバ側にフィードバックする。コンテンツサービス側は、フィードバックされたユーザの選択に基づいてメタデータトラックを取得し、メタデータトラック情報を構文解析して領域情報を取得し、領域情報に基づいて、領域情報に対応するメディアデータを端末に送信する。端末側では、メタデータトラック内の領域情報はさらに、ユーザのために、移動可能な視聴環境を作成するために使用されてよい。回転シミュレーションは、領域情報内にあるヨー角、ピッチ角、および回転角に基づいて視聴環境で実行される。たとえば、視聴環境は回転可能な椅子であってよく、椅子は、領域情報に基づいて、左もしくは右に移動し、前方もしくは後方に傾き、または回転することができる。
【０１９３】
図10は、本発明の一実施形態による、コンピュータデバイス100のハードウェア構造の概略図である。図10に示されたように、コンピュータデバイス100は、ストリーミングメディア情報処理装置の実装形態、またはストリーミングメディア情報処理方法の実装形態として使用されてよい。コンピュータデバイス100は、プロセッサ101、メモリ102、入出力インターフェース103、およびバス105を含み、通信インターフェース104をさらに含んでよい。プロセッサ101、メモリ102、入出力インターフェース103、および通信インターフェース104は、バス105を使用して互いに通信可能に接続される。
【０１９４】
プロセッサ101は、汎用中央処理装置（Central Processing Unit、CPU）、マイクロプロセッサ、特定用途向け集積回路（Application Specific Integrated Circuit、ASIC）、または1つもしくは複数の集積回路を使用してよい。プロセッサ101は、本発明の実施形態で提供されたストリーミングメディア情報処理装置内のモジュールによって実行される必要がある機能を実現するか、または本発明の方法実施形態に対応するストリーミングメディア情報処理方法を実行するために、関連するプログラムを実行するように構成される。プロセッサ101は集積回路チップであってよく、信号処理能力を有する。実施プロセスでは、前述の方法におけるステップは、プロセッサ101内のハードウェア集積論理回路を使用することにより、またはソフトウェアの形態の命令を使用することによって実施することができる。プロセッサ101は、汎用プロセッサ、デジタル信号プロセッサ（DSP）、特定用途向け集積回路（ASIC）、フィールドプログラマブルゲートアレイ（FPGA）もしくは別のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理デバイス、または個別ハードウェア構成要素であってよい。プロセッサ101は、本発明の実施形態で開示された方法、ステップ、および論理ブロック図を実装または実行することができる。汎用プロセッサはマクロプロセッサであってよく、またはプロセッサは任意の従来のプロセッサなどであってよい。本発明の実施形態を参照して開示された方法のステップは、ハードウェア復号プロセッサを使用して直接実行および完了されてもよく、復号プロセッサ内のハードウェアモジュールとソフトウェアモジュールの組合せを使用して実行および完了されてもよい。ソフトウェアモジュールは、ランダムアクセスメモリ、フラッシュメモリ、読取り専用メモリ、プログラマブル読取り専用メモリ、電気的消去可能プログラマブルメモリ、またはレジスタなどの、当技術分野の成熟記憶媒体内に配置されてよい。記憶媒体はメモリ102内に配置される。プロセッサ101は、メモリ102内の情報を読み取り、プロセッサ101のハードウェアを用いて、本発明の実施形態で提供されたストリーミングメディア情報処理装置に含まれるモジュールによって実行される必要
がある機能を実行するか、または本発明の方法実施形態で提供されたストリーミングメディア情報処理方法を実行する。
【０１９５】
メモリ102は、読取り専用メモリ（Read Only Memory、ROM）、静的記憶装置、動的記憶装置、またはランダムアクセスメモリ（Random Access Memory、RAM）であってよい。メモリ102は、オペレーティングシステムおよび別のアプリケーションプログラムを記憶してよい。本発明の実施形態で提供されたストリーミングメディア情報処理装置に含まれるモジュールによって実行される必要がある機能が、ソフトウェアもしくはファームウェアを使用して実施されるか、または本方法の実施形態で提供されたストリーミングメディア情報処理方法が実行されるとき、本発明の実施形態で提供された技術的解決策を実施するために使用されるプログラムコードはメモリ102に記憶され、プロセッサ101は、ストリーミングメディア情報処理装置に含まれるモジュールによって実行される必要がある動作を実行するか、または本発明の方法実施形態で提供されたメディアデータ処理方法を実行する。
【０１９６】
入出力インターフェース103は、入力データおよび情報を受け取り、演算結果などのデータを出力するように構成される。
【０１９７】
通信インターフェース104は、送受信装置、たとえば、限定はしないが、トランシーバを使用して、コンピューティングデバイス100と別のデバイスまたは通信ネットワークとの間の通信を実施する。通信インターフェース104は、処理装置内の取得モジュールまたは送信モジュールとして使用されてよい。
【０１９８】
バス105は、コンピュータデバイス100の（プロセッサ101、メモリ102、入出力インターフェース103、および通信インターフェース104などの）構成要素間で情報を転送するためのチャネルを含んでよい。
【０１９９】
図10では、コンピュータデバイス100のプロセッサ101、メモリ102、入出力インターフェース103、通信インターフェース104、およびバス105のみが示されているが、具体的な実装プロセスでは、当業者は、コンピュータデバイス100が通常の動作に必要な別の構成要素をさらに含むことを理解するべきであることに留意されたい。たとえば、コンピュータデバイス100は、再生されるべきビデオデータを表示するように構成されたディスプレイをさらに含んでよい。加えて、当業者は、コンピュータデバイス100が、具体的な要件に基づいて、別の追加機能を実装するためのハードウェア構成要素をさらに含んでよいことを理解するべきである。さらに、当業者は、コンピュータデバイス100が、本発明の実施形態を実装するために必要な構成要素のみを含んでよく、必ずしも図10に示されたすべての構成要素を含むとは限らないことを理解すべきである。
【０２００】
説明を簡単にするために、前述の方法実施形態は一連の動作として記載されていることに留意されたい。しかしながら、いくつかのステップは、本発明に従って別の順序で実行されるか、または同時に実行されてよいので、本発明は記載された動作順序に限定されないことを当業者は理解するべきである。加えて、本明細書に記載されたすべての実施形態は好ましい実施形態であり、関連する動作およびモジュールは必ずしも本発明に必須ではないことも、当業者は諒解するべきである。当業者は、実施形態における方法のプロセスのうちのすべてまたは一部が、関連するハードウェアに命令するコンピュータプログラムによって実施されてよいことを理解することができる。プログラムはコンピュータ可読記憶媒体に記憶されてよい。プログラムが実行されると、実施形態における方法のプロセスが実行される。前述の記憶媒体は、磁気ディスク、光ディスク、読取り専用メモリ（ROM：Read−Only Memory）、またはランダムアクセスメモリ（RAM：Random Access Memory）であってよい。
【０２０１】
本発明は、実施形態を参照して記載されているが、保護を主張する本発明を実装するプロセスにおいて、当業者は、添付の図面、開示された内容、および添付の特許請求の範囲を参照することにより、開示された実施形態の別の変形形態を理解し実装することができる。特許請求の範囲では、「備える」（comprising）は別の構成要素または別のステップを排除せず、「a」または「one」は「複数」のケースを排除しない。単一のプロセッサまたは別のユニットは、特許請求の範囲に列挙されたいくつかの機能を実装することができる。いくつかの手段は互いに異なる従属請求項に記録されるが、これは、これらの手段を組み合わせてより良い効果を生み出すことができないことを意味しない。コンピュータプログラムは、光記憶媒体または半導体媒体などの適切な媒体に記憶／分配され、他のハードウェアとともに提供されるか、またはハードウェアの一部として使用されてよいか、あるいは、別の方式で、たとえば、Internetまたは別の有線もしくはワイヤレスの電気通信システムを使用して分配されてよい。
【符号の説明】
【０２０２】
90  メディア情報処理装置
101  プロセッサ
102  メモリ
103  入出力インターフェース
104  通信インターフェース
105  バス
701  サーバ側、コンテンツサービス側
7011  コンテンツ準備
7012  コンテンツサービス
702  端末側
901  情報取得モジュール
902  処理モジュール
【図１】
2020526969.tif 000014
【図２】
2020526969.tif 000015
【図３】
2020526969.tif 000016
【図４】
2020526969.tif 000017
【図５】
2020526969.tif 000018
【図６】
2020526969.tif 000019
【図７】
2020526969.tif 000020
【図８】
2020526969.tif 000021
【図９】
2020526969.tif 000022
【図１０】
2020526969.tif 000023
【図１１（ａ）】
2020526969.tif 000024
【図１１（ｂ）】
2020526969.tif 000025
【手続補正書】
【提出日】令和2年2月14日(2020.2.14)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】００８７
【補正方法】変更
【補正の内容】
【００８７】
いくつかの実施形態では、空間情報は、ビデオの空間情報メタデータ（track metadata）にカプセル化されてよい。たとえば、空間情報はcovi boxなどの同じboxにカプセル化される。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０１０８
【補正方法】変更
【補正の内容】
【０１０８】
本発明の実施形態の技術的解決策は、主に、コンテンツ準備側（トランスコーダ）、インテリジェントネットワークノード（CDNまたはプロキシサーバ）側、および端末プレーヤ側で実施される。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０１８５
【補正方法】変更
【補正の内容】
【０１８５】
date is an integer that declares the recommended time of the metadata（in seconds since midnight，Jan．1，1904，in UTC time）．（dateは（協定世界時1904年1月1日深夜からの秒単位で）メタデータの推奨時間を表す整数である。）
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０２００
【補正方法】変更
【補正の内容】
【０２００】
説明を簡単にするために、前述の方法実施形態は一連の動作として記載されていることに留意されたい。しかしながら、いくつかのステップは、本発明に従って別の順序で実行されるか、または同時に実行されてよいので、本発明は記載された動作順序に限定されないことを当業者は理解するべきである。加えて、本明細書に記載されたすべての実施形態は実施形態であり、関連する動作およびモジュールは必ずしも本発明に必須ではないことも、当業者は諒解するべきである。当業者は、実施形態における方法のプロセスのうちのすべてまたは一部が、関連するハードウェアに命令するコンピュータプログラムによって実施されてよいことを理解することができる。プログラムはコンピュータ可読記憶媒体に記憶されてよい。プログラムが実行されると、実施形態における方法のプロセスが実行される。前述の記憶媒体は、磁気ディスク、光ディスク、読取り専用メモリ（ROM：Read−Only Memory）、またはランダムアクセスメモリ（RAM：Random Access Memory）であってよい。
【手続補正５】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
メディア情報処理方法であって、前記方法が、
メディアデータのメタデータ情報を取得するステップであって、前記メタデータ情報がメタデータのソース情報を備え、前記ソース情報が前記メディアデータのレコメンダを示すために使用され、前記メディアデータが全方向メディアデータである、ステップと、
前記メタデータの前記ソース情報に基づいて前記メディアデータを処理するステップと
を備える、方法。
【請求項２】
メディアデータのメタデータ情報を取得する前記ステップが、
前記メディアデータのメタデータトラック（track）を取得するステップであって、前記メタデータトラックが前記メタデータの前記ソース情報を備える、ステップ
を備える、請求項1に記載の方法。
【請求項３】
メディアデータのメタデータ情報を取得する前記ステップが、
前記メディアデータのメディアプレゼンテーション記述ファイルを取得するステップであって、前記メディアプレゼンテーション記述ファイルが前記メタデータの前記ソース情報を備える、ステップ
を備える、請求項1または2に記載の方法。
【請求項４】
メディアデータのメタデータ情報を取得する前記ステップが、
前記メディアデータを備えるビットストリームを取得するステップであって、前記ビットストリームが補足拡張情報（supplementary enhancement information、SEI）をさらに備え、前記補足拡張情報が前記メタデータの前記ソース情報を備える、ステップ
を備える、請求項1から3のいずれか一項に記載の方法。
【請求項５】
前記メタデータの前記ソース情報がソースタイプ識別子である、請求項1から4のいずれか一項に記載の方法。
【請求項６】
前記メタデータの前記ソース情報が、前記メディアデータの前記レコメンダの意味表現を備える、請求項1から5のいずれか一項に記載の方法。
【請求項７】
メディア情報処理装置であって、前記装置が、
メディアデータのメタデータ情報を取得するように構成された情報取得モジュールであって、前記メタデータ情報がメタデータのソース情報を備え、前記ソース情報が前記メディアデータのレコメンダを示すために使用され、前記メディアデータが全方向メディアデータである、情報取得モジュールと、
前記メタデータの前記ソース情報に基づいて前記メディアデータを処理するように構成された処理モジュールと
を備える、装置。
【請求項８】
前記情報取得モジュールが、具体的に、前記メディアデータのメタデータトラック（track）を取得するように構成され、前記メタデータトラックが前記メタデータの前記ソース情報を備える、請求項7に記載の装置。
【請求項９】
前記情報取得モジュールが、具体的に、前記メディアデータのメディアプレゼンテーション記述ファイルを取得するように構成され、前記メディアプレゼンテーション記述ファイルが前記メタデータの前記ソース情報を備える、請求項7または8に記載の装置。
【請求項１０】
前記情報取得モジュールが、具体的に、前記メディアデータを備えるビットストリームを取得するように構成され、前記ビットストリームが補足拡張情報（supplementary enhancement information、SEI）をさらに備え、前記補足拡張情報が前記メタデータの前記ソース情報を備える、請求項7から9のいずれか一項に記載の装置。
【請求項１１】
前記メタデータの前記ソース情報がソースタイプ識別子である、請求項7から10のいずれか一項に記載の装置。
【請求項１２】
前記メタデータの前記ソース情報が、前記メディアデータの前記レコメンダの意味表現を備える、請求項7から11のいずれか一項に記載の装置。
【請求項１３】
メディア情報処理方法であって、前記方法が、
複数のクライアントによって送信されたいくつかのユーザビューポート情報を受信するステップであって、前記ユーザビューポート情報が、ユーザが全方向メディアデータを視聴するためのビューポートを示すために使用される、ステップと、
すべての前記ユーザビューポート情報に基づいてターゲットビューポートを決定するステップと、
前記ターゲットビューポートに対応するメディアデータを送信するステップと
を備える、方法。
【請求項１４】
メディア情報処理方法であって、前記方法が、
複数のクライアントによって送信されたいくつかのユーザビューポート情報を受信するステップであって、前記ユーザビューポート情報が、ユーザが全方向メディアデータを視聴するためのビューポートを示すために使用される、ステップと、
すべての前記ユーザビューポート情報に基づいてターゲットビューポートを決定するステップと、
前記ターゲットビューポートに基づいてメディアデータのメタデータ情報を生成するステップと
を備える、方法。
【請求項１５】
メディア情報処理装置であって、前記装置が、
複数のクライアントによって送信されたいくつかのユーザビューポート情報を受信するように構成された受信機であって、前記ユーザビューポート情報が、ユーザが全方向メディアデータを視聴するためのビューポートを示すために使用される、受信機と、
すべての前記ユーザビューポート情報に基づいてターゲットビューポートを決定するように構成されたプロセッサと、
前記ターゲットビューポートに対応するメディアデータを送信するように構成された送信機と
を備える、装置。
【請求項１６】
メディア情報処理装置であって、前記装置が、
複数のクライアントによって送信されたいくつかのユーザビューポート情報を受信するように構成された受信機であって、前記ユーザビューポート情報が、ユーザが全方向メディアデータを視聴するためのビューポートを示すために使用される、受信機と、
すべての前記ユーザビューポート情報に基づいてターゲットビューポートを決定し、前記ターゲットビューポートに基づいてメディアデータのメタデータ情報を生成するように構成されたプロセッサと
を備える、装置。
【請求項１７】
メディア情報処理装置であって、前記装置は、1つまたは複数のプロセッサとメモリとを含み、前記メモリは前記1つまたは複数のプロセッサに結合され、前記メモリはコンピュータプログラムコードを記憶するように構成され、前記コンピュータプログラムコードは命令を含み、前記1つまたは複数のプロセッサが前記命令を実行すると、前記処理装置は、請求項1から14のいずれか一項に記載の前記メディア情報処理方法を実行する、装置。
【請求項１８】
コンピュータ可読記憶媒体であって、前記コンピュータ可読記憶媒体は命令を記憶し、前記命令がデバイス上で実行されると、前記デバイスは請求項1から14のいずれか一項に記載の前記メディア情報処理方法を実行することが可能になる、コンピュータ可読記憶媒体。
【請求項１９】
コンピュータに請求項1から14のいずれか一項に記載の方法を実行させるように構成されたコンピュータプログラム。
【国際調査報告】
2020526969.tif 000026
2020526969.tif 000027
2020526969.tif 000028
2020526969.tif 000029