JP2020522166A - 魚眼ビデオデータのための高レベルシグナリング - Google Patents

魚眼ビデオデータのための高レベルシグナリング Download PDF

Info

Publication number
JP2020522166A
JP2020522166A JP2019564866A JP2019564866A JP2020522166A JP 2020522166 A JP2020522166 A JP 2020522166A JP 2019564866 A JP2019564866 A JP 2019564866A JP 2019564866 A JP2019564866 A JP 2019564866A JP 2020522166 A JP2020522166 A JP 2020522166A
Authority
JP
Japan
Prior art keywords
video data
box
fisheye video
fisheye
video
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.)
Granted
Application number
JP2019564866A
Other languages
English (en)
Other versions
JP7035088B2 (ja
JP2020522166A5 (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.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
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 Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2020522166A publication Critical patent/JP2020522166A/ja
Publication of JP2020522166A5 publication Critical patent/JP2020522166A5/ja
Application granted granted Critical
Publication of JP7035088B2 publication Critical patent/JP7035088B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106—Processing image signals
    • H04N13/172—Processing image signals image signals comprising non-image signal components, e.g. headers or format information
    • H04N13/178—Metadata, e.g. disparity information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
    • 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/46—Embedding additional information in the video signal during the compression process
    • 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
    • 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/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
    • 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
    • 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/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • 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
    • 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/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Library & Information Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Testing, Inspecting, Measuring Of Stereoscopic Televisions And Televisions (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Closed-Circuit Television Systems (AREA)
  • Studio Devices (AREA)

Abstract

実例的な方法は、魚眼ビデオデータを含むファイルを処理することと、ファイルは、魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造を含み、ここにおいて、複数のシンタックス要素は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第１のシンタックス要素と、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを暗示的に示す１つまたは複数のシンタックス要素とを含み、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、第１のシンタックス要素に基づいて決定することと、モノスコープまたはステレオスコープとして、魚眼ビデオデータを決定に基づいてレンダリングすることとを含む。【選択図】図１２

Description

関連出願の相互参照
[0001]本願は、２０１７年５月２５日に出願された米国仮特許出願第６２／５１１，１８９号の利益を主張し、その内容全体が、参照によってここに組み込まれる。
[0002]この開示は、符号化されたビデオデータの記憶およびトランスポートに関する。
[0003]デジタルビデオ能力は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末（ＰＤＡ）、ラップトップまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲーミングデバイス、ビデオゲームコンソール、セルラまたは衛星無線電話、ビデオテレビ会議デバイス、および同様のものを含む、幅広い範囲のデバイスに組み込まれることができる。デジタルビデオデバイスは、デジタルビデオ情報をより効率的に送信および受信するために、ＭＰＥＧ−２、ＭＰＥＧ−４、ＩＴＵ−Ｔ Ｈ．２６３またはＩＴＵ−Ｔ Ｈ．２６４／ＭＰＥＧ−４、Ｐａｒｔ １０、アドバンスドビデオコーディング（ＡＶＣ）、（高効率ビデオコーディング（ＨＥＶＣ）とも呼ばれる）ＩＴＵ−Ｔ Ｈ．２６５、およびそのような規格の拡張によって定義される規格において記述されているもののような、ビデオ圧縮技法をインプリメントする。
[0004]ビデオ圧縮技法は、ビデオシーケンスに内在する冗長性を低減または取り除くために、空間的予測および／または時間的予測を実行する。ブロックベースのビデオコーディングの場合、ビデオフレームまたはスライスは、複数のマクロブロックへと区分化され得る。各マクロブロックはさらに区分化されることができる。イントラコーディングされた（Ｉ）フレームまたはスライス中のマクロブロックは、近隣のマクロブロックに対して空間的予測を使用して符号化される。インターコーディングされた（ＰまたはＢ）フレームまたはスライス中のマクロブロックは、同じフレームまたはスライス中の近隣のマクロブロックに対して空間的予測を、あるいは他の基準フレームに対して時間的予測を使用し得る。
[0005]ビデオデータが符号化された後に、ビデオデータは、送信または記憶のためにパケット化され得る。ビデオデータは、国際標準化機構（ＩＳＯ）ベースメディアファイルフォーマット、およびＡＶＣのようなその拡張のような、多様な規格のうちの任意のものに準拠するビデオファイルへとアセンブルされ得る。
[0006]一例では、方法は、魚眼ビデオデータを含むファイルを処理することと、ファイルは、魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造を含み、ここにおいて、複数のシンタックス要素は、魚眼ビデオデータがモノスコープ（monoscopic）であるかまたはステレオスコープ（stereoscopic）であるかを明示的に示す第１のシンタックス要素と、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを暗示的に示す１つまたは複数のシンタックス要素とを含み、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、第１のシンタックス要素に基づいて決定することと、モノスコープまたはステレオスコープとして、魚眼ビデオデータを決定に基づいてレンダリングすることとを含む。
[0007]別の例では、デバイスは、魚眼ビデオデータを含むファイルの少なくとも一部分を記憶するように構成されたメモリと、ファイルは、魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造を含み、ここにおいて、複数のシンタックス要素は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第１のシンタックス要素と、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを暗示的に示す１つまたは複数のシンタックス要素とを含み、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、第１のシンタックス要素に基づいて決定することと、モノスコープまたはステレオスコープとして、魚眼ビデオデータを決定に基づいてレンダリングすることとを行うように構成された１つまたは複数のプロセッサと含む。
[0008]別の例では、方法は、魚眼ビデオデータと、魚眼ビデオデータをキャプチャするために使用されるカメラの外部（extrinsic）パラメータとを取得することと、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、外部パラメータに基づいて決定することと、魚眼ビデオデータと、魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造とをファイル中に符号化することとを含み、ここにおいて、複数のシンタックス要素は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第１のシンタックス要素と、魚眼ビデオデータをキャプチャするために使用されるカメラの外部パラメータを明示的に示す１つまたは複数のシンタックス要素とを含む。
[0009]別の例では、デバイスは、魚眼ビデオデータを記憶するように構成されたメモリと、魚眼ビデオデータをキャプチャするために使用されるカメラの外部パラメータを取得することと、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、外部パラメータに基づいて決定することと、魚眼ビデオデータと、魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造とをファイル中に符号化することとを行うように構成された１つまたは複数のプロセッサとを含み、ここにおいて、複数のシンタックス要素は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第１のシンタックス要素と、魚眼ビデオデータをキャプチャするために使用されるカメラの外部パラメータを明示的に示す１つまたは複数のシンタックス要素とを含む。
[0010]１つまたは複数の例の詳細は、添付の図面および以下の説明に記載されている。他の特徴、目的、および利点が、説明、図面、および特許請求の範囲から明らかとなるであろう。
この開示に説明される１つまたは複数の実例的な技法にしたがった、全方位画像コンテンツをキャプチャするための実例的なデバイスを例示するブロック図である。 この開示に説明される１つまたは複数の実例的な技法にしたがった、全方位画像コンテンツをキャプチャするための実例的なデバイスを例示するブロック図である。 複数の魚眼画像を含むピクチャの例である。 この開示に説明される１つまたは複数の実例的な技法にしたがった、全方位画像の様々な外部パラメータおよび視野を例示する概念図である。 この開示に説明される１つまたは複数の実例的な技法にしたがった、全方位画像の様々な外部パラメータおよび視野を例示する概念図である。 この開示に説明される１つまたは複数の実例的な技法にしたがった、全方位画像の様々な外部パラメータおよび視野を例示する概念図である。 この開示に説明される１つまたは複数の実例的な技法にしたがった、全方位画像の様々な外部パラメータおよび視野を例示する概念図である。 この開示に説明される１つまたは複数の実例的な技法にしたがった、全方位画像の様々な外部パラメータおよび視野を例示する概念図である。 この開示に説明される１つまたは複数の実例的な技法にしたがった、全方位画像の様々な外部パラメータおよび視野を例示する概念図である。 ネットワークを通してメディアデータをストリーミングするための技法をインプリメントする実例的なシステムを例示するブロック図である。 実例的なマルチメディアコンテンツの要素を例示する概念図である。 実例的なビデオファイルの要素を例示するブロック図であり、それは、リプレゼンテーション（a representation）のセグメントに対応し得る。 この開示の１つまたは複数の技法にしたがった、魚眼ビデオデータを含むファイルを処理するための実例的な技法を例示するフローチャートである。 この開示の１つまたは複数の技法にしたがった、魚眼ビデオデータを含むファイルを生成するための実例的な技法を例示するフローチャートである。
詳細な説明
[0019]この開示に説明される実例的な技法は、全方位ビデオまたは画像データを表すファイルを処理することに関する。全方位メディアコンテンツがある特定のデバイス（例えば、ヘッドマウントディスプレイおよびヘッドフォン）で消費される（consumed）とき、メディアがキャプチャされた場所および時間（例えば、（1つまたは複数の）カメラがあったところ）にユーザがいたかのように、ユーザの視聴している向き（viewing orientation）に対応するメディアの一部のみがレンダリングされる。全方位メディアアプリケーションの最もポピュラーな形態のうちの１つは、３６０度ビデオとしても知られる全方位ビデオである。全方位ビデオは、最大で３６０度までのシーンをカバーする複数のカメラによって典型的にキャプチャされる。
[0020]一般に、全方位ビデオは、全方位画像のシーケンスから形成される。それ故に、この開示に説明される実例的な技法は、全方位画像コンテンツを生成することに関して説明される。その後、全方位ビデオコンテンツのために、これらの全方位画像は、順次に表示されることができる。いくつかの例では、ユーザは、（例えば、ユーザの３６０度周囲全体のスナップショットとして）全方位画像のみを撮ることを所望し得、およびこの開示に説明される技法は、そのような実例的なケースにも適用可能である。
[0021]全方位ビデオは、ステレオスコープ（stereoscopic）またはモノスコープ（monoscopic）であり得る。ビデオがステレオスコープであるときは、視聴者が奥行きを知覚し得るように、異なる画像が各目に示される。そのため、ステレオスコープビデオは、各方向を向いた２つのカメラを使用して典型的にキャプチャされる。ビデオがモノスコープであるときは、同じ画像が両目に示される。
[0022]ビデオデータは、１つまたは複数の魚眼レンズを使用してキャプチャされる魚眼ビデオデータである（あるいは、１つまたは複数の魚眼レンズを使用してキャプチャされたかのように見えるように生成された）と考えられ得る。魚眼レンズは、広パノラマまたは半球の画像（hemispherical image）を作成することを意図された強度の視覚的歪みを生じさせる超広角レンズであり得る。
[0023]本技法は、キャプチャされたビデオコンテンツ、仮想現実、および概してビデオおよび画像を表示することに適用可能であり得る。本技法は、モバイルデバイスにおいて使用され得るが、本技法は、モバイルアプリケーションに限定されると見なされるべきではない。一般に、本技法は、仮想現実アプリケーション、ビデオゲームアプリケーション、または３６０度球状ビデオ／画像環境が所望される他のアプリケーションのためのものであり得る。
[0024]いくつかの例では、全方位画像コンテンツは、２つの魚眼レンズを含むカメラデバイスでキャプチャされ得る。２つの魚眼レンズが画像コンテンツの球（sphere）の対向する両部分（opposite portions）をキャプチャするために、カメラデバイスの対向する両側（opposing sides）上に位置付けられる場合、画像コンテンツは、モノスコープであり、および３６０度ビデオの全球をカバーし得る。同様に、２つの魚眼レンズが画像コンテンツの球の同じ部分をキャプチャするために、カメラデバイスの同じ側上に位置付けられる場合、画像コンテンツは、ステレオスコープであり、および３６０度ビデオの球の半分をカバーし得る。カメラによって生成される画像は、円形画像である（例えば、１つの画像フレームが、２つの円形画像を含む）。
[0025]図１Ａおよび１Ｂは、この開示に説明される１つまたは複数の実例的な技法にしたがった、全方位画像コンテンツをキャプチャするための実例的なデバイスを例示するブロック図である。図１Ａに例示されているように、コンピューティングデバイス１０Ａは、球全体をカバーするモノスコープ画像コンテンツ（例えば、全３６０度ビデオコンテンツ）をキャプチャするために、コンピューティングデバイス１０Ａの両側上にロケートされた魚眼レンズ１２Ａと魚眼レンズ１２Ｂとを含むビデオキャプチャデバイスである。図１Ｂに例示されているように、コンピューティングデバイス１０Ｂは、球のほぼ半分をカバーするステレオスコープ画像コンテンツをキャプチャするために、コンピューティングデバイス１０Ｂの同じ側上にロケートされた魚眼レンズ１２Ｃと魚眼レンズ１２Ｄとを含むビデオキャプチャデバイスである。
[0026]上記で説明されたように、カメラデバイスは、複数の魚眼レンズを含む。いくつかの実例的なカメラデバイスは、２つの魚眼レンズを含むが、実例的な技法は、２つの魚眼レンズに限定されない。１つの実例的なカメラデバイスは、１６個のレンズ（例えば、３Ｄ ＶＲコンテンツを撮影するための１６台のカメラアレイ）を含み得る。別の実例的なカメラデバイスは、各々が１９５度の画角（angle of view）を有する８つのレンズを含み得る（例えば、各レンズが、３６０度の画像コンテンツのうちの１９５度をキャプチャする）。他の実例的なカメラデバイスは、３つまたは４つのレンズを含む。いくつかの例は、３６０度の画像コンテンツをキャプチャする３６０度レンズを含み得る。
[0027]この開示に説明される実例的な技法は概して、全方位画像／ビデオをキャプチャする２つの魚眼レンズに関して説明される。しかしながら、実例的な技法は、それに限定されない。実例的な技法は、複数のレンズ（例えば、２つ以上）をそれらレンズが魚眼レンズでない場合であっても含む、および複数の魚眼レンズを含む、実例的なカメラデバイスに適用可能であり得る。例えば、実例的な技法は、キャプチャされた画像を繋ぎ合わせる方法を説明し、および本技法は、複数のレンズ（例として、それらは魚眼レンズであり得る）からの複数のキャプチャされた画像が存在する例に適用可能であり得る。実例的な技法が２つの魚眼レンズに関して説明される一方で、実例的な技法は、それに限定されず、および全方位画像／ビデオをキャプチャするために使用される様々なカメラタイプに適用可能である。
[0028]この開示の技法は、ＩＳＯベースメディアファイルフォーマット（例えば、ＩＳＯＢＭＦＦ、ＩＳＯ／ＩＥＣ １４４９６−１２）、およびＭＰＥＧ−４ファイルフォーマット（ＩＳＯ／ＩＥＣ １４４９６−１５）、第３世代パートナーシッププロジェクト（３ＧＰＰ（登録商標））ファイルフォーマット（３ＧＰＰ ＴＳ ２６．２４４）、およびビデオコーデックのＡＶＣおよびＨＥＶＣファミリのためのファイルフォーマット（ＩＳＯ／ＩＥＣ １４４９６−１５）、または他の同様のビデオファイルフォーマットを含む、ＩＳＯＢＭＦＦから派生した他のファイルフォーマットのうちの任意のものにしたがってカプセル化されたビデオデータに準拠するビデオファイルに適用され得る。
[0029]ＩＳＯＢＭＦＦは、ＡＶＣファイルフォーマットのような多くのコーデックカプセル化フォーマットの、ならびに、ＭＰＥＧ−４ファイルフォーマット、３ＧＰＰファイルフォーマット（３ＧＰ）、およびＤＶＢファイルフォーマットのような多くのマルチメディアコンテナフォーマットの基礎として使用される。オーディオおよびビデオのような連続メディアに加えて、画像のような静的メディア、ならびにメタデータが、ＩＳＯＢＭＦＦに準拠するファイル中に記憶されることができる。ＩＳＯＢＭＦＦにしたがって構造化されたファイルは、ローカルメディアファイル再生、リモートファイルのプログレッシブダウンロード、ＨＴＴＰを通した動的適応型ストリーミング（ＤＡＳＨ）のためのセグメント、ストリーミングされることになるコンテンツのためのコンテナおよびそのパケット化命令、および受信されるリアルタイムメディアストリームの記録を含む、多くの目的のために使用され得る。
[0030]ボックスは、ＩＳＯＢＭＦＦにおけるエレメンタリシンタックス構造であり、４キャラクタコード化ボックスタイプ、ボックスのバイトカウント、およびペイロードを含む。ＩＳＯＢＭＦＦファイルは、ボックスのシーケンスから成り、およびボックスは、他のボックスを包含し得る。ムービーボックス（「ｍｏｏｖ」）は、ファイル中に存在する連続メディアストリームについてのメタデータを包含し、各々は、トラックとしてファイル中に表される。トラックについてのメタデータは、トラックボックス（「ｔｒａｋ」）中にエンクローズされる（enclosed）が、その一方でトラックのメディアコンテンツは、メディアデータボックス（「ｍｄａｔ」）中にエンクローズされるか、または別個のファイル中に直接エンクローズされるかのいずれかである。トラックについてのメディアコンテンツは、オーディオまたはビデオアクセスユニットのようなサンプルのシーケンスから成る。
[0031]魚眼ビデオデータをレンダリングするとき、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかをビデオ復号器が決定することが望まれ得る。例えば、ビデオ復号器が魚眼ビデオデータのピクチャ中に含まれる円形画像を表示および／または繋ぎ合わせる方式は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかに直接依存する。
[0032]いくつかの例では、ビデオ復号器は、ファイルによって記述される魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを暗示的に示す、ファイル中に含まれた１つまたは複数のシンタックス要素に基づいて、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを決定し得る。例えば、ビデオ符号化器は、魚眼ビデオデータをキャプチャするために使用されるカメラの各々の外部パラメータ（例えば、ヨー角（yaw angle）、ピッチ角、ロール角、および１つまたは複数の空間的オフセットのような物理／ロケーション属性）を記述するシンタックス要素をファイル中に含め得、およびビデオ復号器は、ファイルによって記述されるビデオデータがモノスコープであるかまたはステレオスコープであるかを算出するために、外部パラメータを処理し得る。一例として、外部パラメータの処理が、カメラが同じ方向を向いており、且つ空間的オフセットを有しているというインジケーションをもたらす場合、ビデオ復号器は、ビデオデータがステレオスコープであると決定し得る。別の例として、外部パラメータの処理が、カメラが対向する方向（opposite directions）を向いていることを示す場合、ビデオ復号器は、ビデオデータがモノスコープであると決定し得る。しかしながら、いくつかの例では、そのような追加のリソース集約的な（resource intensive）算出を実行する必要なしに、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかをビデオ復号器が決定することが可能であることが望ましくあり得る。加えて、いくつかの例では、外部パラメータの処理は、モノスコープまたはステレオスコープとしてのビデオデータの正しい（例えば、意図された通りの）分類をもたらさないことがあり得る。一例として、外部パラメータの値は、符号化／送信／復号中に破損し得る。別の例として、外部パラメータは、符号化器において正確に提供されていないことがあり得る。
[0033]この開示の１つまたは複数の技法にしたがって、ビデオ符号化器は、ファイルによって記述される魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第１のシンタックス要素をファイル中に含め得る。ファイルは、魚眼ビデオデータの外部パラメータであるシンタックス要素に加えて、第１のシンタックス要素を含み得る。そのため、ファイルは、ファイルによって記述される魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかの明示的インジケーション（すなわち、第１のシンタックス要素）と暗示的インジケーション（すなわち、外部パラメータであるシンタックス要素）との両方を含み得る。このように、ビデオ復号器は、（例えば、外部パラメータに基づいて追加の算出を実行する必要なしに）ビデオデータがモノスコープであるかまたはステレオスコープであるかを正確に決定し得る。
[0034]ＩＳＯＢＭＦＦは、次のタイプのトラックを指定する：エレメンタリメディアストリームを包含するメディアトラック、メディア送信命令を含むか、または受信されたパケットストリームを表すかのいずれかであるヒントトラック、および時間同期されたメタデータを備える時間指定された（timed）メタデータトラック。
[0035]当初は記憶のために設計されたにも関わらず、ＩＳＯＢＭＦＦは、ストリーミングに、例えば、プログレッシブダウンロードまたはＤＡＳＨに非常に有益であることが証明されている。ストリーミングの目的のために、ＩＳＯＢＭＦＦにおいて定義されたムービーフラグメントが使用されることができる。
[0036]各トラックについてのメタデータは、サンプル記述エントリのリストを含み、各々は、そのトラック中で使用されるコーディングまたはカプセル化フォーマット、およびそのフォーマットを処理するために必要とされる初期化データを提供する。各サンプルは、トラックのサンプル記述エントリのうちの１つに関連付けられる。
[0037]ＩＳＯＢＭＦＦは、様々なメカニズムを用いてサンプル固有メタデータを指定することを可能にする。サンプルテーブルボックス（「ｓｔｂｌ」）内の特定のボックスは、共通のニーズに応えるために標準化されている。例えば、同期サンプルボックス（「ｓｔｓｓ」）は、トラックのランダムアクセスサンプルをリストするために使用される。サンプルグルーピングメカニズムは、ファイル中にサンプルグループ記述エントリとして指定された同じプロパティを共有するサンプルのグループへの４キャラクタグルーピングタイプにしたがったサンプルのマッピングを可能にする。いくつかのグルーピングタイプが、ＩＳＯＢＭＦＦにおいて指定されている。
[0038]仮想現実（ＶＲ）は、非物理的世界とインタラクトすることを可能にする没入したユーザの動きによって相関された自然および／または合成イメージおよびサウンドのレンダリングによって作成されたその世界の中に仮想的に存在するための能力である。ヘッドマウントディスプレイ（ＨＭＤ）のようなレンダリングデバイスと、（３６０度ビデオと呼ばれることも多い）ＶＲビデオ作成とにおいてなされた近年の進歩により、有意な品質のエクスペリエンスが提供されることができる。ＶＲアプリケーションは、ゲーミング、トレーニング、教育、スポーツビデオ、オンラインショッピング、アダルトエントレインメント（entrainment）、等を含む。
[0039]典型的なＶＲシステムは、次のコンポーネントのうちの１つまたは複数を含み得、それらは、次のステップのうちの１つまたは複数を実行し得る：
１）異なる方向に向いており、且つ理想的には集合的にカメラセットの周囲の全てのビューポイントをカバーしている複数の個々のカメラから典型的に成るカメラセット。
２）天球ビデオ（spherical video）になるが、（世界地図のような）正距円筒図法（equi-rectangular）または立方体（cube）マップのような長方形フォーマットにマッピングされるイメージスティッチング。ここで、複数の個々のカメラによって撮られたビデオピクチャは、時間ドメイン中で同期され、および空間ドメイン中でステッチされる（stitched）。
３）マッピングされた長方形フォーマットのビデオは、ビデオコーデック、例えば、Ｈ．２６５／ＨＥＶＣまたはＨ．２６４／ＡＶＣ、を使用して符号化／圧縮される。
４）圧縮されたビデオビットストリーム（１つまたは複数）は、メディアフォーマットで記憶および／またはカプセル化され、および受信機にネットワークを通じて送信され得る（ことによると、ユーザによって見られているエリアのみをカバーするサブセットのみ）。
５）受信機は、ことによるとあるフォーマットでカプセル化されたビデオビットストリーム（１つ以上）またはその一部を受信し、およびレンダリングデバイスに復号されたビデオ信号またはその一部を送る。
６）レンダリングデバイスは、例えば、頭の動きおよび目の動きの瞬間さえもトラックすることができるＨＭＤであり、および没入型のエクスペリエンスがユーザに配信されるようにビデオの対応する部分をレンダリングすることができる。
[0040]全方位メディアアプリケーションフォーマット（ＯＭＡＦ：Omnidirectional Media Application Format）は、全方位メディアアプリケーションを可能にするメディアアプリケーションフォーマットを定義するために、ＭＰＥＧによって開発されており、３６０°ビデオおよび関連するオーディオを伴うＶＲアプリケーションに重点を置いている。ＯＭＡＦは、天球または３６０°ビデオの２次元長方形ビデオへの変換のために使用されることができる投影（プロジェクション）およびリージョンワイズパッキング（region-wise packing）を指定し、それに続いてＩＳＯベースメディアファイルフォーマット（ＩＳＯＢＭＦＦ）を使用して全方位メディアおよび関連するメタデータをどのように記憶するかと、ＨＴＴＰを通した動的適応型ストリーミング（ＤＡＳＨ）を使用して全方位メディアをどのようにカプセル化、シグナリング、およびストリーミングするかと、そして最後に、全方位メディア信号の圧縮および再生のためにどのビデオおよびオーディオコーデックならびにメディアコーディング構成が使用されることができるかとを指定する。
[0041]投影およびリージョンワイズパッキングは、投影される全方位ビデオのための天球（sphere）信号から２Ｄビデオピクチャを生成するために、コンテンツ生成側において使用される処理である。投影は通常、スティッチングとともに行われ、それは、各ビデオピクチャのための複数のカメラキャプチャされた画像（the multiple camera captured images）から天球信号を生成し得る。投影は、ＶＲビデオにおける基本的な処理ステップであり得る。典型的な投影タイプは、正距円筒図法および立方体マップを含む。ＯＭＡＦ国際規格案（ＤＩＳ）は、正距円筒図法の投影タイプのみをサポートする。リージョンワイズパッキングは、（コンテンツ生成側のビューポートからの）投影後のオプションのステップである。リージョンワイズパッキングは、符号化前のパッキングされたピクチャの任意の長方形（rectangular）領域の操作（サイズ変更、再位置付け、回転、およびミラーリング）を可能にする。
[0042]図２は、複数の魚眼画像を含むピクチャの例である。ＯＭＡＦ ＤＩＳは、魚眼ＶＲ／３６０ビデオフォーマットをサポートし、ここにおいて、符号化前に２Ｄビデオを生成するために、投影およびオプションとしてリージョンワイズパッキングを適用する代わりに、各アクセスユニットについて、キャプチャするカメラからの円形画像が、２Ｄピクチャ中に直接埋め込まれる。例えば、図２に示されているように、第１の魚眼画像２０２および第２の魚眼画像２０４が、２Ｄピクチャ２００中に埋め込まれている。
[0043]そのような魚眼ビデオはその後、符号化され得、およびビットストリームは、ＩＳＯＢＭＦＦファイル中にカプセル化され得、およびＤＡＳＨリプレゼンテーションとしてさらにカプセル化され得る。加えて、魚眼ビデオの特性を示すパラメータを含む魚眼ビデオのプロパティが、シグナリングされ、およびクライアント側において３６０ビデオを正しくレンダリングするために使用され得る。魚眼ＶＲ／３６０ビデオアプローチの１つの利点は、それがモバイル端末による低コストユーザ生成ＶＲコンテンツをサポートすることである。
[0044]ＯＭＡＦ ＤＩＳでは、制限されたビデオサンプルエントリタイプ「ｒｅｓｖ」に対する魚眼全方位ビデオスキームの使用は、復号されたピクチャが魚眼ビデオピクチャであることを示す。魚眼全方位ビデオスキームの使用は、SchemeTypeBox内の「ｆｏｄｖ」（魚眼全方位ビデオ）に等しいscheme_typeによって示される。魚眼ビデオのフォーマットは、SchemeInformationBox内に包含されたFisheyeOmnidirectionalVideoBoxで示され、それは、サンプルエントリ中に含まれているRestrictedSchemeInfoBox中に含まれている。ＯＭＡＦ ＤＩＳの現在の草案（Information technology - Coded representation of immersive media (MPEG-I) - Part 2: Omnidirectional media format, ISO/IEC FDIS 14496-15:2014(E), ISO/IEC JTC 1/SC 29/WG 11, w16824, 2014-01-13、以下において「ＯＭＡＦ ＤＩＳの現在の草案」と記載される）では、スキームタイプが「ｆｏｄｖ」であるときに、１つおよび１つのみのFisheyeOmnidirectionalVideoBoxが、SchemeInformationBox中に存在すべきである。FisheyeOmnidirectionalVideoBoxがSchemeInformationBox中に存在するとき、StereoVideoBoxおよびRegionWisePackingBoxは、同じSchemeInformationBox中に存在するべきではない。ＯＭＡＦ ＤＩＳの第６節（clause 6）中に規定されているようなFisheyeOmnidirectionalVideoBoxは、魚眼ビデオプロパティパラメータを包含するFisheyeOmnidirectionalVideoInfo( )シンタックス構造を包含する。
[0045]ＯＭＡＦ ＤＩＳの現在の草案中のFisheyeOmnidirectionalVideoInfo( )シンタックス構造のシンタックスは、次の通りである。
aligned(8) class FisheyeOmnidirectionalVideoInfo( ) {
bit(24) reserved = 0;
unsigned int(8) num_circular_images;
for(i=0; i< num_circular_images; i++) {
unsigned int(32) image_center_x;
unsigned int(32) image_center_y;
unsigned int(32) full_radius;
unsigned int(32) picture_radius;
unsigned int(32) scene_radius;
unsigned int(32) image_rotation;
bit(30) reserved = 0;
unsigned int(2) image_flip;
unsigned int(32) image_scale_axis_angle;
unsigned int(32) image_scale_x;
unsigned int(32) image_scale_y;
unsigned int(32) field_of_view;
bit(16) reserved = 0;
unsigned int (16) num_angle_for_displaying_fov;
for(j=0; j< num_angle_for_displaying_fov; j++) {
unsigned int(32) displayed_fov;
unsigned int(32) overlapped_fov;
}
signed int(32) camera_center_yaw;
signed int(32) camera_center_pitch;
signed int(32) camera_center_roll;
unsigned int(32) camera_center_offset_x;
unsigned int(32) camera_center_offset_y;
unsigned int(32) camera_center_offset_z;
bit(16) reserved = 0;
unsigned int(16) num_polynomial_coefficeients;
for(j=0; j< num_polynomial_coefficients; j++) {
unsigned int(32) polynomial_coefficient_K;
}
bit(16) reserved = 0;
unsigned int (16) num_local_fov_region;
for(j=0; j<num_local_fov_region; j++) {
unsigned int(32) start_radius;
unsigned int(32) end_radius;
signed int(32) start_angle;
signed int(32) end_angle;
unsigned int(32) radius_delta;
signed int(32) angle_delta;
for(rad=start_radius; rad<= end_radius; rad+=radius_delta) {
for(ang=start_angle; ang<= ang_radius; ang+=angle_delta) {
unsigned int(32) local_fov_weight;
}
}
}
bit(16) reserved = 0;
unsigned int(16) num_polynomial_coefficients_lsc;
for(j=0; j< num_polynomial_coefficients_lsc; j++) {
unsigned int (32) polynomial_coefficient_K_lsc_R;
unsigned int (32) polynomial_coefficient_K_lsc_G;
unsigned int (32) polynomial_coefficient_K_lsc_B;
}
}
bit(24) reserved = 0;
unsigned int(8) num_deadzones;
for(i=0; i< num_deadzones; i++) {
unsigned int(16) deadzone_left_horizontal_offset;
unsigned int(16) deadzone_top_vertical_offset;
unsigned int(16) deadzone_width;
unsigned int(16) deadzone_height;
}
}
[0046]ＯＭＡＦ ＤＩＳの現在の草案中のFisheyeOmnidirectionalVideoInfo( )シンタックス構造のセマンティクスは、次の通りである。
[0047]num_circular_imagesは、このボックスが適用される各サンプルのコーディングされたピクチャ中の円形画像（circular images）の数を指定する。典型的に、値は２に等しいが、他の非ゼロ値もまた可能である。
[0048]image_center_xは、このボックスが適用される各サンプルのコーディングされたピクチャ中の円形画像の中心の水平座標をルーマサンプルで指定する固定小数点１６．１６値である。
[0049]image_center_yは、このボックスが適用される各サンプルのコーディングされたピクチャ中の円形画像の中心の垂直座標をルーマサンプルで指定する固定小数点１６．１６値である。
[0050]full_radiusは、円形画像の中心から全周画像（the full round image）の端までの半径をルーマサンプルで指定する固定小数点１６．１６値である。
[0051]picture_radiusは、円形画像の中心から画像境界の最も近い端までの半径をルーマサンプルで指定する固定小数点１６．１６値である。円形魚眼画像は、カメラピクチャによってクロップされ得る(may be cropped)。したがって、この値は、円の半径を示し、ここにおいて、ピクセルが使用可能である。
[0052]scene_radiusは、円形画像の中心から画像中のエリアの最も近い端までの半径をルーマサンプルで指定する固定小数点１６．１６値であり、ここで、カメラ本体自体からの障害物が存在せず、およびエンクローズされたエリア内では、繋ぎ合わせる（ステッチする(stitching)）のに大きすぎるレンズ歪みは存在しないことが保証される。
[0053]image_rotationは、円形画像の回転の量を度(degree)で指定する固定小数点１６．１６値である。画像は、画像＋／−９０度、または＋／−１８０度、または任意の他の値だけ回転され得る。
[0054]image_flipは、画像が反転されているかどうか、およびどのように画像が反転されているか、そしてこのことから、逆反転動作が適用される必要があるかどうか、およびどのように逆反転動作が適用される必要があるかを指定する。値０は、画像が反転されていないことを示す。値１は、画像が垂直に反転されていることを示す。値２は、画像が水平に反転されていることを示す。値３は、画像が垂直および水平の両方に反転されていることを示す。
[0055]image_scale_axis_angle、image_scale_x、および image_scale_yは、画像が軸に沿ってスケーリングされているかどうか、およびどのように画像が軸に沿ってスケーリングされているかを指定する３つの固定小数点１６．１６値である。軸は、image_scale_axis_angleの値によって度(degree)で示されるような単一の角度によって定義される。０度の角度は、水平ベクトルが完全に水平であり、および垂直ベクトルが完全に垂直であることを意味する。image_scale_xおよびimage_scale_yの値は、軸に対してそれぞれ平行および直交である方向のスケーリング比を示す。
[0056]field_of_viewは、魚眼レンズの視野を度で指定する固定小数点１６．１６値である。半球魚眼レンズについての典型的な値は、１８０．０度である。
[0057]num_angle_for_displaying_fovは、角度の数を指定する。num_angle_for_displaying_fovの値にしたがって、displayed_fovおよびoverlapped_fovの複数の値は、等しい間隔で定義され、それは、１２時において開始し、および時計回りに進む。
[0058]displayed_fovは、各魚眼カメラ画像の表示された視野および対応する画像エリアを指定する。overlapped_fovは、オーバラップされた領域を含む領域を指定し、それは通常、複数の円形画像間の視野の観点から、ブレンディングのために使用される。displayed_fovおよびoverlapped_fovの値は、field_of_viewの値以下である。
[0059]注記：field_of_viewの値は、各魚眼レンズの物性によって決定されるが、その一方でdisplayed_fovおよびoverlapped_fovは、複数の魚眼レンズの構成によって決定される。例えば、num_circular_imagesの値が２に等しく、および２つのレンズが対称的にロケートされているとき、displayed_fovおよびoverlapped_fovの値は、デフォルトでそれぞれ１８０および１９０として設定されることができる。しかしながら、値は、レンズの構成とコンテンツの特性とに依存して変更されることができる。例えば、displayed_fov値（左カメラ＝１７０および右カメラ＝１９０）およびoverlapped_fov値（左カメラ１８５および右カメラ＝１９０）でのスティッチング品質がデフォルト値（１８０および１９０）での品質より良い場合、またはカメラの物理的構成が非対称である場合、等しくないdisplayed_fovおよびoverlapped_fov値が取られることができる。加えて、複数の（Ｎ＞２）魚眼画像に関して言えば、単一のdisplayed_fov値は、各魚眼画像の正確なエリアを指定することができない。図６に示されているように、displayed_fov（６０２）は、方向にしたがって変動する。複数の（Ｎ＞２）魚眼画像を操作するために、num_angle_for_displaying_fovが導入される。例えば、この値が１２に等しい場合、魚眼画像は、各セクタ角度が３０度である１２個のセクタへと分割される。
[0060]camera_center_yawは、各サンプルのコーディングされたピクチャ中の円形画像の中心ピクセルが球面に投影される地点のヨー角を２-16度の単位で指定する。これは、グローバル座標軸に対するカメラ外部パラメータを指定する３つの角度のうちの第１のものである。camera_center_yawは、両端値を含む、−１８０＊２16〜１８０＊２16−１の範囲中にあるべきである。
[0061]camera_center_pitchは、各サンプルのコーディングされたピクチャ中の円形画像の中心ピクセルが球面に投影される地点のピッチ角を２-16度の単位で指定する。camera_center_pitchは、両端値を含む、−９０＊２16〜９０＊２16の範囲中にあるべきである。
[0062]camera_center_rollは、各サンプルのコーディングされたピクチャ中の円形画像の中心ピクセルが球面に投影される地点のロール角を２-16度の単位で指定する。camera_center_rollは、両端値を含む、−１８０＊２16〜１８０＊２16−１の範囲中にあるべきである。
[0063]camera_center_offset_x、camera_center_offset_yおよびcamera_center_offset_zは、コーディングされたピクチャ中の円形画像中のピクセルが投影される単位球の原点からのＸＹＺオフセット値を示す固定小数点８．２４値である。camera_center_offset_x、camera_center_offset_yおよびcamera_center_offset_zは、両端値を含む、−１．０〜１．０の範囲中にあるべきである。
[0064]num_polynomial_coefficientsは、存在する多項式係数の数を指定する整数である。多項式係数polynomial_coefficient_Kのリストは、魚眼空間から歪められていない（undistored）平面画像への変換を指定する多項式中の係数を表す固定小数点８．２４値である。
[0065]num_local_fov_regionは、異なる視野を有するローカルフィッティング領域の数を指定する。
[0066]start_radius、end_radius、start_angle、およびend_angleは、ローカルに表示するための実際の視野を変更するために、ローカルフィッティング／ワーピング（local fitting/warping）のための領域を指定する。start_radiusおよびend_radiusは、最小および最大半径値を指定する固定小数点１６．１６値である。start_angleおよびend_angleは、１２時において開始し、時計回りに増大する最小および最大角度値を２-16度の単位で指定する。start_angleおよびend_angleは、両端値を含む、−１８０＊２16〜１８０＊２16−１の範囲中にあるべきである。
[0067]radius_deltaは、各半径についての異なる視野を表すためのデルタ半径値を指定する固定小数点１６．１６値である。
[0068]angle_deltaは、各角度についての異なる視野を表すためのデルタ角度値を２-16度の単位で指定する。
[0069]local_fov_weightは、start_radius、end_radius、start_angle、end_angle、角度インデックスｉおよび半径インデックスｊによって指定される位置の視野についての重み付け値を指定する８．２４固定小数点フォーマットである。local_fov_weightの正の値は、視野の拡大を指定するが、その一方で負の値は、視野の縮小を指定する。
[0070]num_polynomial_coefficeients_lscは、レンズシェーディング曲線（the lens shading curve）の多項式近似の次数（the order）であるべきである。
[0071]polynomial_coefficient_K_lsc_R、polynomial_coefficient_K_lsc_G、およびpolynomial_coefficient_K_lsc_Bは、半径方向に沿って色を低減するシェーディングアーティファクト（the shading artifact）を補償するために、ＬＳＣパラメータを指定する８．２４固定小数点フォーマットである。当初の色に乗算されるべき補償重み（ｗ）は、多項式を使用して画像中心からの半径の曲線関数（curve function）として近似される。それは、
Figure 2020522166
 として定式化され、ここで、ｐは、polynomial_coefficient_K_lsc_R、polynomial_coefficient_K_lsc_Gまたはpolynomial_coefficient_K_lsc_Bに等しい係数値を示し、ｒは、full_radiusによる正規化後の半径値を示す。Ｎは、num_polynomial_coefficeients_lscの値に等しい。
[0072]num_deadzonesは、このボックスが適用される各サンプルのコーディングされたピクチャ中の死角（dead zones）の数を指定する整数である。
[0073]deadzone_left_horizontal_offset、deadzone_top_vertical_offset、deadzone_width、およびdeadzone_heightは、ピクセルが使用可能でない死角の長方形エリアの位置およびサイズを指定する整数値である。deadzone_left_horizontal_offsetおよびdeadzone_top_vertical_offsetは、コーディングされたピクチャ中の死角の左上隅の水平座標および垂直座標をそれぞれルーマサンプルで指定する。deadzone_widthおよびdeadzone_heightは、死角の幅および高さをそれぞれルーマサンプルで指定する。ビデオを表すためのビットを節約するために、死角内の全てのピクセルは、同じピクセル値、例えば、全て黒、に設定されるべきである。
[0074]図３〜８は、上記のシンタックスおよびセマンティクスの様々な態様を例示する概念図である。図３は、image_center_xおよびimage_center_yシンタックスを中心３０２として、full_radiusシンタックスを全半径３０４として、picture_radiusをフレーム３００のフレーム半径３０６として、scene_radiusをシーン半径３０８（例えば、カメラ本体５１０からの障害物がないエリア）として例示している。図４は、２つの魚眼画像についてのdisplayed_fov（すなわち、表示された視野（ＦＯＶ：field of view））を例示している。ＦＯＶ４０２は、１７０度の視野を表し、およびＦＯＶ４０４は、１９０度の視野を表す。図５は、複数の（例えば、Ｎ＞２）魚眼画像についてのdisplayed_fov（すなわち、表示された視野（ＦＯＶ））およびoverlapped_fovを例示している。ＦＯＶ５０２は、第１の視野を表し、およびＦＯＶ５０４は、第２の視野を表す。図６は、camera_center_offset_x（ｏx）、camera_center_offset_y（ｏy）、およびcamera_center_offset_z（ｏz）シンタックスの例示である。図７は、ローカル視野に関するパラメータを例示する概念図である。図８は、ローカル視野の例を例示する概念図である。
[0075]ＯＭＡＦ ＤＩＳの現在の草案中の魚眼ビデオのシグナリングは、１つまたは複数の不利な点を提示し得る。
[0076]ＯＭＡＦ ＤＩＳの現在の草案中の魚眼ビデオのシグナリングの１つの実例的な不利な点として、各魚眼ビデオピクチャ中に２つの円形画像が存在するとき（例えば、FisheyeOmnidirectionalVideoInfo( )シンタックス構造中のnum_circular_imagesが２に等しい場合）、カメラ外部パラメータ（例えば、camera_center_yaw、camera_center_pitch、camera_center_roll、camera_center_offset_x、camera_center_offset_y、およびcamera_center_offset_z）の値に依存して、魚眼ビデオは、モノスコープまたはステレオスコープのいずれかであることができる。特に、２つの円形画像をキャプチャする２つのカメラが同じ側上にあるとき、魚眼ビデオは、球のほぼ半分（すなわち、水平に１８０度）をカバーするステレオスコープであり、および２つのカメラが互いに反対側（opposite sides）にあるとき、魚眼ビデオは、モノスコープであるが、ほぼ球全体（すなわち、水平に３６０度）をカバーする。例えば、カメラ外部パラメータ値の２つのセットが次の通りであるとき、魚眼ビデオは、モノスコープである：
第１のセット（1st set）:
camera_center_yaw = 0 degrees (+/- 5 degrees)
camera center_pitch = 0 degrees (+/- 5 degrees)
camera center roll = 0 degrees (+/- 5 degrees)
camera_center_offset_x = 0 mm (+/- 3 mm)
camera_center_offset_y = 0 mm (+/- 3 mm)
camera_center_offset_z = 0 mm (+/- 3 mm)
第２のセット（2nd set）:
camera_center_yaw = 180 degrees (+/- 5 degrees)
camera center_pitch = 0 degrees (+/- 5 degrees)
camera center roll = 0 degrees (+/- 5 degrees)
camera_center_offset_x = 0 mm (+/- 3 mm)
camera_center_offset_y = 0 mm (+/- 3 mm)
camera_center_offset_z = 0 mm (+/- 3 mm)
[0077]上記のパラメータ値は、図１Ｂのコンピューティングデバイス１０Ｂのカメラ外部パラメータ値に対応し得る。別の例として、カメラ外部パラメータ値の２つのセットが次の通りであるとき、魚眼ビデオは、ステレオスコープである：
第１のセット（1st set）:
camera_center_yaw = 0 degrees (+/- 5 degrees)
camera center_pitch = 0 degrees (+/- 5 degrees)
camera center roll = 0 degrees (+/- 5 degrees)
camera_center_offset_x = 0 mm (+/- 3 mm)
camera_center_offset_y = 0 mm (+/- 3 mm)
camera_center_offset_z = 0 mm (+/- 3 mm)
第２のセット（2nd set）:
camera_center_yaw = 0 degrees (+/- 5 degrees)
camera center_pitch = 0 degrees (+/- 5 degrees)
camera center roll = 0 degrees (+/- 5 degrees)
camera_center_offset_x = 64 mm (+/- 3 mm)
camera_center_offset_y = 0 mm (+/- 3 mm)
camera_center_offset_z = 0 mm (+/- 3 mm)
[0078]上記のパラメータ値は、図１Ａのコンピューティングデバイス１０Ａのカメラ外部パラメータ値に対応し得る。６４ｍｍのステレオオフセットＸ距離が２．５インチに同等であり、それは、人間の目の間の平均距離であることに留意されたい。
[0079]言い換えれば、魚眼ビデオがモノスコープであるかまたはステレオスコープであるかに関する情報は、隠されている（すなわち、暗示的にはコーディングされるが、明示的にはコーディングされない）。しかしながら、コンテンツ選択のような高レベルシステムの目的の場合、（例えば、コンテンツ選択関数を実行するエンティティが、対応するビデオデータがモノスコープであるかまたはステレオスコープであるかを決定するために、FisheyeOmnidirectionalVideoInfo( )シンタックス構造中の多くの情報を構文解析する必要がないように）この情報がファイルフォーマットレベルとＤＡＳＨレベルとの両方で容易にアクセス可能であることが望まれ得る。
[0080]ＯＭＡＦ ＤＩＳの現在の草案中の魚眼ビデオのシグナリングの別の実例的な不利な点として、各魚眼ビデオピクチャ中に２つの円形画像が存在し（例えば、FisheyeOmnidirectionalVideoInfo( )シンタックス構造中のnum_circular_imagesが２に等しい場合）、および魚眼ビデオがステレオスコープであるとき、クライアントデバイスは、２つの円形画像のうちのどちらが左目のビューであり、およびどちらが右目のビューであるかをカメラ外部パラメータから決定し得る。しかしながら、クライアントデバイスが、どちらの画像が左目のビューであり、およびどちらが右目のビューであるかをカメラ外部パラメータから決定しなければならないことは、望ましくないことがあり得る。
[0081]ＯＭＡＦ ＤＩＳの現在の草案中の魚眼ビデオのシグナリングの別の実例的な不利な点として、各側上に２つずつ、魚眼ビデオをキャプチャするための４つの魚眼カメラが存在するとき、魚眼ビデオは、球全体をカバーするステレオスコープとなるであろう。このケースでは、各魚眼ビデオピクチャ中に４つの円形画像が存在する（例えば、FisheyeOmnidirectionalVideoInfo( )シンタックス構造中のnum_circular_imagesは、４に等しい）。そのようなケースでは（各魚眼ビデオピクチャ中に２つより多くの円形画像が存在するとき）、クライアントデバイスは、同じビューに属するある特定の２つの円形画像のペアリングをカメラ外部パラメータから決定し得る。しかしながら、クライアントデバイスが、同じビューに属するある特定の２つの円形画像のペアリングをカメラ外部パラメータから決定しなければならないことは、望ましくないことがあり得る。
[0082]ＯＭＡＦ ＤＩＳの現在の草案中の魚眼ビデオのシグナリングの別の実例的な不利な点として、投影される全方位ビデオのために、カバレッジ情報（例えば、球上のどのエリアがビデオによってカバーされるか）は、CoverageInformationBoxを使用して明示的にシグナリングされるか、または、存在しないときは、全球となるようにクライアントデバイスによって推論されるかのいずれかである。クライアントデバイスは、カメラ外部パラメータからカバレッジを決定し得るが、ここでも、この情報が容易にアクセス可能となるように明示的にシグナリングすることが望まれ得る。
[0083]ＯＭＡＦ ＤＩＳの現在の草案中の魚眼ビデオのシグナリングの別の実例的な不利な点として、リージョンワイズパッキングの使用は、投影される全方位ビデオに対しては許容されるが、魚眼ビデオに対しては許容されない。しかしながら、投影される全方位ビデオに適用可能であるリージョンワイズパッキングのいくつかの利益はまた、魚眼ビデオにも適用可能であり得る。
[0084]ＯＭＡＦ ＤＩＳの現在の草案中の魚眼ビデオのシグナリングの別の実例的な不利な点として、サブピクチャトラック中での投影される全方位ビデオの搬送は、コンポジショントラックグルーピング（the composition track grouping）を使用することによって、ＯＭＡＦ ＤＩＳ中に規定されている。しかしながら、サブピクチャトラック中での魚眼全方位ビデオの伝達は、サポートされていない。
[0085]この開示は、上記の問題に対するソリューションを提示する。これらの技法のうちのいくつかは、独立して適用され得、およびそれらのうちのいくつかは、組み合わせて適用され得る。
[0086]この開示の１つまたは複数の技法にしたがって、魚眼ビデオデータを含むファイルは、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかの明示的なインジケーションを含み得る。言い換えれば、魚眼ビデオがモノスコープであるかまたはステレオスコープであるかのインジケーションは、明示的にシグナリングされ得る。このように、クライアントデバイスは、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを他のパラメータから推論しなければならないことを避け得る。
[0087]一例として、FisheyeOmnidirectionalVideoInfo( )シンタックス構造中の最初の２４ビットのうちの１つまたは複数は、モノスコープまたはステレオスコープのインジケーションをシグナリングするためのフィールド（例えば、１ビットフラグ）を形成するために使用され得る。第１の特定の値（例えば、０）に等しいフィールドは、魚眼ビデオがモノスコープであることを示し得、および第２の特定の値（例えば、１）に等しいフィールドは、魚眼ビデオがステレオスコープであることを示し得る。例えば、魚眼ビデオデータを含むファイルを生成するとき、コンテンツ準備デバイス（例えば、図９のコンテンツ準備デバイス２０、および特定の例では、コンテンツ準備デバイス２０のカプセル化ユニット３０）は、ファイル内にボックス（例えば、FisheyeOmnidirectionalVideoBox）を符号化し得、ボックスは、魚眼ビデオデータについてのパラメータを包含するシンタックス構造（例えば、FisheyeOmnidirectionalVideoInfo( )）を含み、およびシンタックス構造は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかの明示的なインジケーションを含む。クライアントデバイス（例えば、図９のクライアントデバイス４０、および特定の例では、クライアントデバイス４０の取り出しユニット５２）は、モノスコープまたはステレオスコープの明示的なインジケーションを取得するために、ファイルを同様に処理し得る。
[0088]別の例として、フィールド、例えば、１ビットフラグ、いくつかのリザーブされたビット、およびことによると何らかの他の情報を包含する新しいボックスは、モノスコープまたはステレオスコープのインジケーションをシグナリングするために、FisheyeOmnidirectionalVideoBoxに追加され得る。第１の特定の値（例えば、０）に等しいフィールドは、魚眼ビデオがモノスコープであることを示し得、および第２の特定の値（例えば、１）に等しいフィールドは、魚眼ビデオがステレオスコープであることを示し得る。例えば、魚眼ビデオデータを含むファイルを生成するとき、コンテンツ準備デバイス（例えば、図９のコンテンツ準備デバイス２０）は、ファイル内に第１のボックス（例えば、FisheyeOmnidirectionalVideoBox）を符号化し得、第１のボックスは、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示すフィールドを含む第２のボックスを含む。クライアントデバイス（例えば、図９のクライアントデバイス４０）は、モノスコープまたはステレオスコープの明示的なインジケーションを取得するために、ファイルを同様に処理し得る。
[0089]別の例として、フィールド（例えば、１ビットフラグ）は、このインジケーションをシグナリングするために、FisheyeOmnidirectionalVideoBoxに直接追加され得る。例えば、魚眼ビデオデータを含むファイルを生成するとき、コンテンツ準備デバイス（例えば、図９のコンテンツ準備デバイス２０）は、ファイル内にボックス（例えば、FisheyeOmnidirectionalVideoBox）を符号化し得、ボックスは、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示すフィールドを含む。クライアントデバイス（例えば、図９のクライアントデバイス４０）は、モノスコープまたはステレオスコープの明示的なインジケーションを取得するために、ファイルを同様に処理し得る。
[0090]この開示の１つまたは複数の技法にしたがって、複数の円形画像としての魚眼ビデオデータを含むファイルは、複数の円形画像のそれぞれの円形画像ごとに、それぞれのビュー識別情報（ビューＩＤ：view identification）の明示的なインジケーションを含み得る。言い換えれば、魚眼ビデオデータの各円形画像について、各円形画像のビューＩＤを示すフィールドが追加され得る。２つのビューＩＤ値０および１のみが存在するとき、０に等しいビューＩＤを有するビューは、左のビューであり得、および１に等しいビューＩＤを有するビューは、右のビューであり得る。例えば、複数の円形画像が２つの円形画像のみを含む場合、第１の予め定められたビデオ識別情報を有する、複数の円形画像のうちの１つの円形画像は、左のビューであり、第２の予め定められたビデオ識別情報を有する、複数の円形画像のうちの１つの円形画像は、右のビューである。このように、クライアントデバイスは、どちらの円形画像が左のビューであり、およびどちらが右のビューであるかを他のパラメータから推論しなければならないことを避け得る。
[0091]シグナリングされるビューＩＤはまた、同じビューに属する任意の２つの円形画像のペアリング関係を示すために使用されることができる（例えば、それらは両方とも、同じ値のシグナリングされるビューＩＤを有し得るため）。
[0092]円形画像についての全ての魚眼ビデオパラメータを構文解析する必要なしにビューＩＤが容易にアクセスされることを可能にするために、num_circular_imagesフィールドの後に、および既存のループの前に、ループが追加され得る。例えば、ファイルを処理することは、ビュー識別情報の明示的インジケーションを第１のループ中で構文解析することと、円形画像の他のパラメータを第１のループの後にある第２のループ中で構文解析することと、を含み得る。例えば、ビューＩＤおよび他のパラメータは、次の通りに構文解析され得る：
aligned(8) class FisheyeOmnidirectionalVideoInfo( ) {
bit(24) reserved = 0;
unsigned int(8) num_circular_images;
for(i=0; i< num_circular_images; i++) {
unsigned int(8) view_id;
bit(24) reserved = 0;
}
for(i=0; i< num_circular_images; i++) {
unsigned int(32) image_center_x;
unsigned int(32) image_center_y;
…
}
}
[0093]view_idは、円形画像が属するビューのビュー識別子を示す。全ての円形画像について２つの値のview_id ０および１のみが存在するとき、０に等しいview_idを有する円形画像は、左のビューに属し得、および１に等しいview_idを有する円形画像は、右のビューに属し得る。いくつかの例では、ビュー識別子を示すシンタックス要素（１つ以上）（すなわち、どちらの円形画像が左のビューであり、およびどちらが右のビューであるかを示すシンタックス要素）は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示すシンタックス要素と同じであり得る。
[0094]この開示の１つまたは複数の技法にしたがって、魚眼ビデオデータを含むファイルは、魚眼ビデオデータについてのパラメータを包含するシンタックス構造を含む第１のボックスを含み得、および魚眼ビデオデータについてのカバレッジ情報を示す第２のボックスをオプションとして含み得る。例えば、魚眼全方位ビデオについてのカバレッジ情報のシグナリングは、FisheyeOmnidirectionalVideoBoxに追加され得る。例えば、ＯＭＡＦ ＤＩＳ中に定義されているようなCoverageInformationBoxは、FisheyeOmnidirectionalVideoBox中にオプションとして包含されることを許容され得、およびそれがFisheyeOmnidirectionalVideoBox中に存在しないときは、全球カバレッジが、魚眼ビデオについて推論され得る。CoverageInformationBoxがFisheyeOmnidirectionalVideoBox中に存在するとき、魚眼ビデオピクチャによって表される球面領域は、２つのヨー円（yaw circles）および２つのピッチ円(pitch circles)によって指定された領域であり得る。このように、クライアントデバイスは、他のパラメータからカバレッジ情報を推論しなければならないことを避け得る。
[0095]この開示の１つまたは複数の技法にしたがって、魚眼ビデオデータを含むファイルは、スキーム情報を含む第１のボックスを含み得、第１のボックスは、魚眼ビデオデータについてのパラメータを包含するシンタックス構造を含む第２のボックスを含み得、および第１のボックスは、魚眼ビデオデータのピクチャがリージョンワイズパッキングされているかどうかを示す第３のボックスをオプションとして含み得る。例えば、RegionWisePackingBoxは、魚眼全方位ビデオのためにSchemeInformationBox中にオプションとして含まれ得る（例えば、FisheyeOmnidirectionalVideoBoxがSchemeInformationBox中に存在するとき、RegionWisePackingBoxは、同じSchemeInformationBox中に存在することができる）。このケースでは、RegionWisePackingBoxの存在は、魚眼ビデオピクチャがリージョンワイズパッキングされており、およびレンダリングより前にアンパッキングを必要とすることを示す。このように、リージョンワイズパッキングの１つまたは複数の利益が、魚眼ビデオのために得られ得る。
[0096]この開示の１つまたは複数の技法にしたがって、サブピクチャコンポジション（sub-picture composition）が、魚眼全方位ビデオのためにグループ化に使用され得、およびサブピクチャコンポジショングルーピング（the sub-picture composition grouping）の適用に関する仕様が、魚眼全方位ビデオに追加され得る。その仕様は、サブピクチャコンポジショントラックグループにマッピングされるトラックのうちの任意のものが、サンプルエントリ中に含まれるSchemeTypeBox中に「ｆｏｄｖ」に等しいscheme_type、「ｒｅｓｖ」に等しいサンプルエントリタイプを有するときに適用され得る。このケースでは、各コンポーズされたピクチャ（composed picture）は、任意のFisheyeOmnidirectionalVideoBoxによって示された魚眼フォーマットと、サブピクチャコンポジショントラックグループにマッピングされるトラックのサンプルエントリ中に含まれた任意のRegionWisePackingBoxによって示されたリージョンワイズパッキングフォーマットとを有するパッキングされたピクチャである。加えて、以下が適用され得る：
[0097]１）このグルーピングにマッピングされる各トラックは、「ｒｅｓｖ」に等しいサンプルエントリタイプを有するべきである。scheme_typeは、サンプルエントリ中に含まれるSchemeTypeBox中の「ｆｏｄｖ」に等しくあるべきである。
[0098]２）同じサブピクチャコンポジショントラックグループにマッピングされるトラックのサンプルエントリ中に含まれるFisheyeOmnidirectionalVideoBoxの全てのインスタンスのコンテンツは、同一であるべきである。
[0099]３）同じサブピクチャコンポジショントラックグループにマッピングされるトラックのサンプルエントリ中に含まれるRegionWisePackingBoxの全てのインスタンスのコンテンツは、同一であるべきである。
[0100]ＨＴＴＰストリーミングでは、頻繁に使用される動作は、ＨＥＡＤ、ＧＥＴ、および部分的ＧＥＴを含む。ＨＥＡＤ動作は、所与のユニフォームリソースロケータ（ＵＲＬ）またはユニフォームリソース名（ＵＲＮ）に関連付けられたファイルのヘッダを、そのＵＲＬまたはＵＲＮに関連付けられたペイロードを取り出すことなしに、取り出す。ＧＥＴ動作は、所与のＵＲＬまたはＵＲＮに関連付けられたファイル全体を取り出す。部分的ＧＥＴ動作は、入力パラメータとしてバイト範囲を受信し、およびファイルの連続数のバイトを取り出し、ここで、バイトの数は、受信されるバイト範囲に対応する。このことから、ムービーフラグメントは、部分的ＧＥＴ動作が１つまたは複数の個々のムービーフラグメントを得ることができることから、ＨＴＴＰストリーミングのために提供され得る。ムービーフラグメントでは、異なるトラックのいくつかのトラックフラグメントが存在することができる。ＨＴＴＰストリーミングでは、メディアプレゼンテーション（a media presentation）は、クライアントにとってアクセス可能であるデータの構造化された集合であり得る。クライアントは、ユーザにストリーミングサービスを提示するために、メディアデータ情報を要求およびダウンロードし得る。
[0101]ＨＴＴＰストリーミングを使用して３ＧＰＰデータをストリーミングする例では、マルチメディアコンテンツのビデオおよび／またはオーディオデータについての複数のリプレゼンテーションが存在し得る。以下に説明されるように、異なるリプレゼンテーションは、異なるコーディング特性（例えば、ビデオコーディング規格の異なるプロファイルまたはレベル）、異なるコーディング規格または（マルチビューおよび／またはスケーラブル拡張のような）コーディング規格の拡張、あるいは異なるビットレートに対応し得る。そのようなリプレゼンテーションのマニフェストは、メディアプレゼンテーション記述（ＭＰＤ：Media Presentation Description）データ構造で定義され得る。メディアプレゼンテーションは、ＨＴＴＰストリーミングクライアントデバイスにとってアクセス可能であるデータの構造化された集合に対応し得る。ＨＴＴＰストリーミングクライアントデバイスは、クライアントデバイスのユーザにストリーミングサービスを提示するために、メディアデータ情報を要求およびダウンロードし得る。メディアプレゼンテーションは、ＭＰＤデータ構造で記述され得、それは、ＭＰＤの更新を含み得る。
[0102]メディアプレゼンテーションは、１つまたは複数の期間（Period）のシーケンスを包含し得る。各期間は、次の期間の開始まで、また最後の期間のケースではメディアプレゼンテーションの終了まで拡張し得る。各期間は、同じメディアコンテンツについての１つまたは複数のリプレゼンテーションを包含し得る。リプレゼンテーションは、オーディオ、ビデオ、時間指定されたテキスト、または他のそのようなデータのいくつかの代替の符号化されたバージョンのうちの１つであり得る。リプレゼンテーションは、符号化タイプによって、例えば、ビデオデータについてのビットレート、解像度、および／またはコーデックと、オーディオデータについてのビットレート、言語、および／またはコーデックとによって異なり得る。リプレゼンテーションという用語は、マルチメディアコンテンツの特定の期間に対応し、且つ特定の方法で符号化された、符号化されたオーディオまたはビデオデータのセクションを指すために使用され得る。
[0103]特定の期間のリプレゼンテーションは、リプレゼンテーションが属する適合セット（an adaptation set）を示すＭＰＤ中の属性によって示されるグループに割り当てられ得る。同じ適合セット中のリプレゼンテーションは概して、クライアントデバイスが、例えば、帯域幅適合を実行するためにこれらのリプレゼンテーション間を動的およびシームレスに切り替えることができるという点において、互いに対して代替であると考えられる。例えば、特定の期間についてのビデオデータの各リプレゼンテーションは、同じ適合セットに割り当てられ得、それにより、リプレゼンテーションのうちの任意のものが、対応する期間についてのマルチメディアコンテンツの、ビデオデータまたはオーディオデータのようなメディアデータを提示するための復号のために選択され得る。１つの期間内のメディアコンテンツは、存在する場合には、グループ０からの１つのリプレゼンテーションか、またはいくつかの例では、各非ゼログループからの多くとも１つのリプレゼンテーションの組み合わせ、のいずれかによって表され得る。ある期間の各リプレゼンテーションについてのタイミングデータは、その期間の開始時間に相対的に表され得る。
[0104]リプレゼンテーションは、１つまたは複数のセグメントを含み得る。各リプレゼンテーションは、初期化セグメントを含み得る、またはリプレゼンテーションの各セグメントは、自己初期化し得る。存在するとき、初期化セグメントは、リプレゼンテーションにアクセスするための初期化情報を包含し得る。一般に、初期化セグメントは、メディアデータを包含しない。セグメントは、ユニフォームリソースロケータ（ＵＲＬ）、ユニフォームリソース名（ＵＲＮ）、またはユニフォームリソース識別子（ＵＲＩ）のような識別子によって一意に参照され得る。ＭＰＤは、各セグメントについての識別子を提供し得る。いくつかの例では、ＭＰＤはまた、範囲属性の形態でバイト範囲を提供し得、それは、ＵＲＬ、ＵＲＮ、またはＵＲＩによってアクセス可能であるファイル内のセグメントについてのデータに対応し得る。
[0105]異なるリプレゼンテーションは、異なるタイプのメディアデータについての実質的に同時の取り出しのために選択され得る。例えば、クライアントデバイスは、それらからセグメントを取り出すためのオーディオリプレゼンテーション、ビデオリプレゼンテーション、および時間指定されたテキストリプレゼンテーションを選択し得る。いくつかの例では、クライアントデバイスは、帯域幅適合を実行するための特定の適合セットを選択し得る。すなわち、クライアントデバイスは、ビデオリプレゼンテーションを含む適合セット、オーディオリプレゼンテーションを含む適合セット、および／または時間指定されたテキストを含む適合セットを選択し得る。代替として、クライアントデバイスは、ある特定のタイプのメディア（例えば、ビデオ）についての適合セットを選択し、および他のタイプのメディア（例えば、オーディオおよび／または時間指定されたテキスト）についてのリプレゼンテーションを直接選択し得る。
[0106]図９は、ネットワークを通してメディアデータをストリーミングするための技法をインプリメントする実例的なシステム１０を例示するブロック図である。この例では、システム１０は、コンテンツ準備デバイス２０、サーバデバイス６０、およびクライアントデバイス４０を含む。クライアントデバイス４０およびサーバデバイス６０は、ネットワーク７４によって通信可能に結合され、それは、インターネットを備え得る。いくつかの例では、コンテンツ準備デバイス２０およびサーバデバイス６０もまた、ネットワーク７４または別のネットワークによって結合され得るか、あるいは直接通信可能に結合され得る。いくつかの例では、コンテンツ準備デバイス２０およびサーバデバイス６０は、同じデバイスを備え得る。
[0107]図９の例におけるコンテンツ準備デバイス２０は、オーディオソース２２およびビデオソース２４を備える。オーディオソース２２は、例えば、オーディオ符号化器２６によって符号化されることになるキャプチャされたオーディオデータを表す電気信号を生じさせるマイクロフォンを備え得る。代替として、オーディオソース２２は、以前に記録されたオーディオデータを記憶する記憶媒体、コンピュータ化されたシンセサイザのようなオーディオデータ生成器、またはオーディオデータの任意の他のソースを備え得る。ビデオソース２４は、ビデオ符号化器２８によって符号化されることになるビデオデータを生じさせるビデオカメラ、以前に記録されたビデオデータで符号化された記憶媒体、コンピュータグラフィックスソースのようなビデオデータ生成ユニット、またはビデオデータの任意の他のソースを備え得る。コンテンツ準備デバイス２０は、必ずしも全ての例においてサーバデバイス６０に通信可能に結合されるわけではなく、サーバデバイス６０によって読み取られる別個の媒体にマルチメディアコンテンツを記憶し得る。
[0108]生オーディオおよびビデオデータは、アナログまたはデジタルデータを備え得る。アナログデータは、オーディオ符号化器２６および／またはビデオ符号化器２８によって符号化される前にデジタル化され得る。オーディオソース２２は、話す参加者から、その話す参加者が話している間にオーディオデータを取得し得、およびビデオソース２４は、その話す参加者のビデオデータを同時に取得し得る。他の例では、オーディオソース２２は、記憶されたオーディオデータを備えるコンピュータ可読記憶媒体を備え得、およびビデオソース２４は、記憶されたビデオデータを備えるコンピュータ可読記憶媒体を備え得る。このように、この開示に説明される技法は、ライブの、ストリーミングの、リアルタイムのオーディオおよびビデオデータに、またはアーカイブされ、事前に記録されたオーディオおよびビデオデータに適用され得る。
[0109]ビデオフレームに対応するオーディオフレームは概して、ビデオフレーム内に包含される、ビデオソース２４によってキャプチャされた（または生成された）ビデオデータと同時にオーディオソース２２によってキャプチャされた（または生成された）オーディオデータを包含するオーディオフレームである。例えば、話す参加者が概して話すことによってオーディオデータを生じさせる間、オーディオソース２２は、オーディオデータをキャプチャし、およびビデオソース２４は、同時に、すなわち、オーディオソース２２がオーディオデータをキャプチャしている間に、話す参加者のビデオデータをキャプチャする。故に、オーディオフレームは、１つまたは複数の特定のビデオフレームに時間的に対応し得る。それ故に、ビデオフレームに対応するオーディオフレームは概して、オーディオデータとビデオデータとが同時にキャプチャされた状況に対応し、およびそれについて、オーディオフレームとビデオフレームとは、同時にキャプチャされたオーディオデータとビデオデータとをそれぞれ備える。
[0110]いくつかの例では、オーディオ符号化器２６は、符号化されたオーディオフレームについてのオーディオデータが記録された時間を表す各符号化されたオーディオフレーム中のタイムスタンプを符号化し得、および同様に、ビデオ符号化器２８は、符号化されたビデオフレームについてのビデオデータが記録された時間を表す各符号化されたビデオフレーム中のタイムスタンプを符号化し得る。そのような例では、ビデオフレームに対応するオーディオフレームは、タイムスタンプを備えるオーディオフレームと、同じタイムスタンプを備えるビデオフレームとを備え得る。コンテンツ準備デバイス２０は、オーディオ符号化器２６および／またはビデオ符号化器２８がそれからタイムスタンプを生成し得る、あるいは、オーディオソース２２とビデオソース２４とが、オーディオデータとビデオデータとをそれぞれタイムスタンプに関連付けるために使用し得る、内部クロックを含み得る。
[0111]いくつかの例では、オーディオソース２２は、オーディオデータが記録された時間に対応するデータをオーディオ符号化器２６に送り得、およびビデオソース２４は、ビデオデータが記録された時間に対応するデータをビデオ符号化器２８に送り得る。いくつかの例では、オーディオ符号化器２６は、符号化されたオーディオデータの相対時間的順序（a relative temporal ordering）を示すために、しかしオーディオデータが記録された絶対時間を必ずしも示すことなしに、符号化されたオーディオデータ中のシーケンス識別子を符号化し得、および同様に、ビデオ符号化器２８もまた、符号化されたビデオデータの相対時間的順序を示すために、シーケンス識別子を使用し得る。同様に、いくつかの例では、シーケンス識別子は、マッピングされ得るか、またはそうでない場合は、タイムスタンプと相関され得る。
[0112]オーディオ符号化器２６は概して、符号化されたオーディオデータのストリームを生じさせ、その一方でビデオ符号化器２８は、符号化されたビデオデータのストリームを生じさせる。（オーディオであれビデオであれ）データの各個々のストリームは、エレメンタリストリームと呼ばれ得る。エレメンタリストリームは、リプレゼンテーションの単一のデジタルにコーディングされた（ことによると圧縮された）コンポーネントである。例えば、リプレゼンテーションのコーディングされたビデオまたはオーディオ部分は、エレメンタリストリームであることができる。エレメンタリストリームは、ビデオファイル内にカプセル化される前に、パケット化されたエレメンタリストリーム（ＰＥＳ）へと変換され得る。同じリプレゼンテーション内で、ストリームＩＤは、ある１つのエレメンタリストリームに属するＰＥＳパケットを他のものと区別するために使用され得る。エレメンタリストリームのデータの基本単位は、パケット化されたエレメンタリストリーム（ＰＥＳ）パケットである。このことから、コーディングされたビデオデータは概して、エレメンタリビデオストリームに対応する。同様に、オーディオデータは、１つまたは複数のそれぞれのエレメンタリストリームに対応する。
[0113]ＩＴＵ Ｈ．２６４／ＡＶＣおよび高効率ビデオコーディング（ＨＥＶＣ）規格のような多くのビデオコーディング規格は、誤りのないビットストリームのためのシンタックス、セマンティクス、および復号処理を定義し、それらのうちのいずれも、ある特定のプロファイルまたはレベルに準拠する。ビデオコーディング規格は典型的に、符号化器を指定しないが、符号化器は、生成されるビットストリームが復号器に対して規格準拠（standard-compliant）であることを保証するタスクを課される。ビデオコーディング規格のコンテキストでは、「プロファイル」は、アルゴリズム、機能（features,）、またはツールのサブセット、およびそれらに適用される制約に対応する。Ｈ．２６４規格によって定義されているように、例えば、「プロファイル」は、Ｈ．２６４規格によって指定されているビットストリームシンタックス全体のサブセットである。「レベル」は、例えば、復号器メモリおよび消費のような復号器リソース消費の制限に対応し、それらは、ピクチャの解像度、ビットレート、およびブロック処理レートに関連する。プロファイルは、profile_idc（プロファイルインジケータ）値でシグナリングされ得、その一方でレベルは、level_idc（レベルインジケータ）値でシグナリングされ得る。
[0114]Ｈ．２６４規格は、例えば、所与のプロファイルのシンタックスによって課せられる限度（the bounds）内で、復号されたピクチャの指定されたサイズのような、ビットストリーム中のシンタックス要素によって取られる値に依存して、符号化器と復号器との性能において大きな変動を要求することは依然として可能であることを認識している。Ｈ．２６４規格はさらに、多くのアプリケーションで、特定のプロファル内のシンタックスの全ての仮定的な使用に対処することが可能である復号器をインプリメントすることは実用的でも経済的でもないことを認識している。それ故に、Ｈ．２６４規格は、ビットストリーム中のシンタックス要素の値に対して課せられる制約の指定されたセットとして「レベル」を定義する。これらの制約は、値に対する単純な制限であり得る。代替として、これらの制約は、値の算術的組み合わせ（例えば、ピクチャ幅にピクチャの高さを乗算したものに、毎秒復号されるピクチャの数を乗算したもの）に対する制約の形態を取り得る。Ｈ．２６４規格はさらに、個々のインプリメンテーションが各サポートされるプロファイルについて異なるレベルをサポートし得ることを規定する。
[0115]プロファイルに準拠する復号器は通常、プロファイル中に定義された全ての機能をサポートする。例えば、コーディング機能として、Ｂピクチャコーディングは、Ｈ．２６４／ＡＶＣのベースラインプロファイル中でサポートされていないが、Ｈ．２６４／ＡＶＣの他のプロファイル中でサポートされている。あるレベルに準拠する復号器は、そのレベル中で定義された制限を超えるリソースを必要としないあらゆるビットストリームを復号することが可能であるべきである。プロファイルおよびレベルの定義は、解釈可能性（interpretability）に役に立ち得る。例えば、ビデオ送信中に、プロファイルおよびレベル定義のペアが、送信セッション全体についてネゴシエートおよび同意され得る。より具体的には、Ｈ．２６４／ＡＶＣでは、レベルは、処理される必要があるマクロブロックの数、復号ピクチャバッファ（ＤＰＢ）サイズ、コーディングピクチャバッファ（ＣＰＢ）サイズ、垂直動きベクトル範囲、２つの連続するＭＢあたりの動きベクトルの最大数、およびＢブロックが８ｘ８ピクセル未満のサブマクロブロック区分を有することができるかどうか、に対する制限を定義し得る。このように、復号器は、復号器がビットストリームを適正に復号することが可能であるかどうかを決定し得る。
[0116]図９の例では、コンテンツ準備デバイス２０のカプセル化ユニット３０は、ビデオ符号化器２８からのコーディングされたビデオデータを備えるエレメンタリストリームと、オーディオ符号化器２６からのコーディングされたオーディオデータを備えるエレメンタリストリームとを受信する。いくつかの例では、ビデオ符号化器２８およびオーディオ符号化器２６は各々、符号化されたデータからＰＥＳパケットを形成するためのパケタイザを含み得る。他の例では、ビデオ符号化器２８およびオーディオ符号化器２６は各々、符号化されたデータからＰＥＳパケットを形成するためのそれぞれのパケタイザとインターフェースし得る。さらに他の例では、カプセル化ユニット３０は、符号化されたオーディオおよびビデオデータからＰＥＳパケットを形成するためのパケタイザを含み得る。
[0117]ビデオ符号化器２８は、ピクセル解像度、フレームレート、様々なコーディング規格への準拠、様々なコーディング規格についての様々なプロファイルおよび／またはプロファイルのレベルへの準拠、（例えば、２次元または３次元再生のための）１つまたは複数のビューを有するリプレゼンテーション、あるいは他のそのような特性のような様々な特性を有する、および様々なビットレートにおける、マルチメディアコンテンツの異なるリプレゼンテーションを生じさせるために、多様な方法でマルチメディアコンテンツのビデオデータを符号化し得る。この開示に使用されているようなリプレゼンテーションは、オーディオデータ、ビデオデータ、（例えば、クローズドキャプションのための）テキストデータ、または他のそのようなデータのうちの１つを備え得る。リプレゼンテーションは、オーディオエレメンタリストリームまたはビデオエレメンタリストリームのようなエレメンタリストリームを含み得る。各ＰＥＳパケットは、ＰＥＳパケットが属するエレメンタリストリームを識別するstream_idを含み得る。カプセル化ユニット３０は、エレメンタリストリームを様々なリプレゼンテーションのビデオファイル（例えば、セグメント）へとアセンブルすることを担う。
[0118]カプセル化ユニット３０は、オーディオ符号化器２６およびビデオ符号化器２８からリプレゼンテーションのエレメンタリストリームについてのＰＥＳパケットを受信し、およびＰＥＳパケットから対応するネットワーク抽象化レイヤ（ＮＡＬ）ユニットを形成する。コーディングされたビデオセグメントは、ＮＡＬユニットへと編成され得、それは、ビデオ電話通信、記憶、ブロードキャスト、またはストリーミングのようなアプリケーションを扱う「ネットワークフレンドリーな」ビデオリプレゼンテーションを提供する。ＮＡＬユニットは、ビデオコーディングレイヤ（ＶＣＬ）ＮＡＬユニットおよび非ＶＣＬ ＮＡＬユニットにカテゴリ化されることができる。ＶＣＬユニットは、コア圧縮エンジンを包含し得、ブロック、マクロブロック、および／またはスライスレベルのデータを含み得る。他のＮＡＬユニットは、非ＶＣＬ ＮＡＬユニットであり得る。いくつかの例では、プライマリのコーディングされたピクチャ（a primary coded picture）として通常提示される１つの時間インスタンス中のコーディングされたピクチャは、アクセスユニット中に包含され得、それは、１つまたは複数のＮＡＬユニットを含み得る。
[0119]非ＶＣＬ ＮＡＬユニットは、中でもとりわけ、パラメータセットＮＡＬユニットおよびＳＥＩ ＮＡＬユニットを含み得る。パラメータセットは、（シーケンスパラメータセット（ＳＰＳ）中に）シーケンスレベルヘッダ情報、および（ピクチャパラメータセット（ＰＰＳ）中に）まれに変化するピクチャレベルヘッダ情報を包含し得る。パラメータセット（例えば、ＰＰＳおよびＳＰＳ）では、まれに変化する情報は、シーケンスまたはピクチャごとに繰り返される必要がなく、故に、コーディング効率が改善され得る。さらに、パラメータセットの使用は、重要なヘッダ情報の帯域外送信を可能にし得、誤り耐性のための冗長送信の必要性を避ける。帯域外送信の例では、パラメータセットＮＡＬユニットは、ＳＥＩ ＮＡＬユニットのような他のＮＡＬユニットとは異なるチャネル上で送信され得る。
[0120]補足エンハンスメント情報（ＳＥＩ：Supplemental Enhancement Information）は、ＶＣＬ ＮＡＬユニットからのコーディングされたピクチャサンプルを復号するために必要ではない情報を包含し得るが、復号、表示、誤り耐性、および他の目的に関連したプロセスを支援し得る。ＳＥＩメッセージは、非ＶＣＬ ＮＡＬユニット中に包含され得る。ＳＥＩメッセージは、いくつかの規格仕様書（standard specifications）の規範的部分であり、およびこのことから、規格準拠の復号器インプリメンテーションのために常に必須なわけではない。ＳＥＩメッセージは、シーケンスレベルＳＥＩメッセージまたはピクチャレベルＳＥＩメッセージであり得る。何らかのシーケンスレベル情報が、ＳＶＣの例におけるスケーラビリティ情報ＳＥＩメッセージ、およびＭＶＣ中でのビュースケーラビリティ情報ＳＥＩメッセージのようなＳＥＩメッセージ中に包含され得る。これらの実例的なＳＥＩメッセージは、例えば、動作点の抽出および動作点の特性に関する情報を伝達し得る。加えて、カプセル化ユニット３０は、リプレゼンテーションの特性を記述するメディアプレゼンテーション記述子（ＭＰＤ：a media presentation descriptor）のようなマニフェストファイルを形成し得る。カプセル化ユニット３０は、拡張可能マークアップ言語（ＸＭＬ）にしたがってＭＰＤをフォーマットし得る。
[0121]カプセル化ユニット３０は、出力インターフェース３２に、マニフェストファイル（例えば、ＭＰＤ）とともに、マルチメディアコンテンツの１つまたは複数のリプレゼンテーションについてのデータを提供し得る。出力インターフェース３２は、ユニバーサルシリアルバス（ＵＳＢ）インターフェース、ＣＤまたはＤＶＤライタまたはバーナ、磁気またはフラッシュ記憶媒体に対するインターフェース、あるいは媒体データを記憶または送信するための他のインターフェースのような、記憶媒体に書き込むためのインターフェースまたはネットワークインターフェースを備え得る。カプセル化ユニット３０は、出力インターフェース３２にマルチメディアコンテンツのリプレゼンテーションの各々のデータを提供し得、それは、ネットワーク送信または記憶媒体を介してサーバデバイス６０にデータを送り得る。図９の例では、サーバデバイス６０は、それぞれのマニフェストファイル６６と１つまたは複数のリプレゼンテーション６８Ａ〜６８Ｎ（リプレゼンテーション６８）とを各々が含む様々なマルチメディアコンテンツ６４を記憶する記憶媒体６２を含む。いくつかの例では、出力インターフェース３２はまた、ネットワーク７４に直接データを送り得る。
[0122]いくつかの例では、リプレゼンテーション６８は、適合セットに分けられ得る。すなわち、リプレゼンテーション６８の様々なサブセットは、コーデック、プロファイルおよびレベル、解像度、ビューの数、セグメントのためのファイルフォーマット、復号され、且つ、例えば、スピーカによって提示されるべきオーディオデータおよび／またはリプレゼンテーションとともに表示されるべきテキストの言語または他の特性を識別し得るテキストタイプ情報、適合セット中のリプレゼンテーションについてのシーンの実世界カメラパースペクティブ（real-world camera perspective）またはカメラアングルを記述し得るカメラアングル情報、特定のオーディエンスに対するコンテンツ適性を記述するレーティング情報、または同様のもののような、特性のそれぞれの共通セットを含み得る。
[0123]マニフェストファイル６６は、特定の適合セットに対応するリプレゼンテーション６８のサブセット、ならびにその適合セットについての共通特性、を示すデータを含み得る。マニフェストファイル６６はまた、適合セットの個々のリプレゼンテーションについての、ビットレートのような個々の特性を表すデータを含み得る。このように、適合セットは、簡略化されたネットワーク帯域幅適合を提供し得る。適合セット中のリプレゼンテーションは、マニフェストファイル６６の適合セット要素の子要素を使用して示され得る。いくつかの例では、マニフェストファイル６６は、ここに論述されたFisheyeOmnidirectionalVideoInfo( )のデータ、あるいは同様のデータ、のうちのいくつかまたは全てを含み得る。加えてまたは代替として、リプレゼンテーション６８のセグメントは、ここに論述されたFisheyeOmnidirectionalVideoInfo( )のデータ、あるいは同様のデータ、のうちのいくつかまたは全てを含み得る。
[0124]サーバデバイス６０は、要求処理ユニット７０とネットワークインターフェース７２とを含む。いくつかの例では、サーバデバイス６０は、複数のネットワークインターフェースを含み得る。さらに、サーバデバイス６０の機能のうちの任意のものまたは全ては、ルータ、ブリッジ、プロキシデバイス、スイッチ、または他のデバイスのような、コンテンツ配信ネットワークの他のデバイス上でインプリメントされ得る。いくつかの例では、コンテンツ配信ネットワークの中間デバイスは、マルチメディアコンテンツ６４のデータをキャッシュし得、およびサーバデバイス６０のものと実質的に一致するコンポーネントを含み得る。一般に、ネットワークインターフェース７２は、ネットワーク７４を介してデータを送受信するように構成される。
[0125]要求処理ユニット７０は、記憶媒体６２のデータを求めるネットワーク要求をクライアントデバイス４０のようなクライアントデバイスから受信するように構成される。例えば、要求処理ユニット７０は、RFC 2616, “Hypertext Transfer Protocol - HTTP/1.1,” by R. Fielding et al, Network Working Group, IETF, June 1999中に説明されているようなハイパーテキスト転送プロトコル（ＨＴＴＰ）バージョン１．１をインプリメントし得る。すなわち、要求処理ユニット７０は、ＨＴＴＰ ＧＥＴまたは部分的ＧＥＴ要求を受信し、およびそれら要求に応答してマルチメディアコンテンツ６４のデータを提供するように構成され得る。それら要求は、例えば、セグメントのＵＲＬを使用して、リプレゼンテーション６８のうちの１つのセグメントを指定し得る。いくつかの例では、それら要求はまた、セグメントの１つまたは複数のバイト範囲を指定し得、このことから、部分的ＧＥＴ要求を備える。要求処理ユニット７０はさらに、リプレゼンテーション６８のうちの１つのセグメントのヘッダデータを提供するために、ＨＴＴＰ ＨＥＡＤ要求をサービスするように構成され得る。いずれのケースでも、要求処理ユニット７０は、クライアントデバイス４０のような要求しているデバイスに要求されたデータを提供するために、それら要求を処理するように構成され得る。
[0126]加えてまたは代替として、要求処理ユニット７０は、ｅＭＢＭＳのようなブロードキャストまたはマルチキャストプロトコルを介してメディアデータを配信するように構成され得る。コンテンツ準備デバイス２０は、説明されたのと実質的に同じ方法でＤＡＳＨセグメントおよび／またはサブセグメントを作成し得るが、サーバデバイス６０は、ｅＭＢＭＳあるいは別のブロードキャストまたはマルチキャストネットワークトランスポートプロトコルを使用してこれらのセグメントまたはサブセグメントを配信し得る。例えば、要求処理ユニット７０は、クライアントデバイス４０からマルチキャストグループ参加要求（a multicast group join request）を受信するように構成され得る。すなわち、サーバデバイス６０は、特定のメディアコンテンツ（例えば、ライブイベントのブロードキャスト）に関連付けられた、クライアントデバイス４０を含むクライアントデバイスに、マルチキャストグループに関連付けられたインターネットプロトコル（ＩＰ）アドレスをアドバタイズし得る。クライアントデバイス４０は次に、マルチキャストグループに加わるための要求をサブミットし得る。この要求は、ネットワーク７４、例えば、ネットワーク７４を構成するルータ、全体を通じて伝搬され得、それにより、それらルータは、クライアントデバイス４０のような加入しているクライアントデバイスに、マルチキャストグループに関連付けられたＩＰアドレスに宛てられたトラフィックを向けさせられる（caused to direct）。
[0127]図９の例において例示されているように、マルチメディアコンテンツ６４は、マニフェストファイル６６を含み、それは、メディアプレゼンテーション記述（ＭＰＤ）に対応し得る。マニフェストファイル６６は、異なる代替のリプレゼンテーション６８の記述を包含し得（例えば、異なる品質を有するビデオサービス）、および記述は、例えば、コーデック情報、プロファイル値、レベル値、ビットレート、およびリプレゼンテーション６８の他の記述的特性を含み得る。クライアントデバイス４０は、リプレゼンテーション６８のセグメントにどのようにアクセスするかを決定するために、メディアプレゼンテーションのＭＰＤを取り出し得る。
[0128]特に、取り出しユニット５２は、ビデオ復号器４８の復号能力とビデオ出力４４のレンダリング能力とを決定するために、クライアントデバイス４０の構成データ（図示せず）を取り出し得る。構成データはまた、クライアントデバイス４０のユーザによって選択された言語選好、クライアントデバイス４０のユーザによって設定された奥行き選好に対応する１つまたは複数のカメラパースペクティブ、および／またはクライアントデバイス４０のユーザによって選択されたレーティング選好のうちの任意のものまたは全てを含み得る。取り出しユニット５２は、例えば、ＨＴＴＰ ＧＥＴおよび部分的ＧＥＴ要求をサブミットするように構成されたメディアクライアントまたはウェブブラウザを備え得る。取り出しユニット５２は、クライアントデバイス４０の１つまたは複数のプロセッサあるいは処理ユニット（図示せず）によって実行されるソフトウェア命令に対応し得る。いくつかの例では、取り出しユニット５２に関して説明された機能のうちの全てまたは一部分は、ハードウェア、あるいはハードウェア、ソフトウェア、および／またはファームウェアの組み合わせにおいてインプリメントされ得、ここで、必須のハードウェアは、ソフトウェアまたはファームウェアのための命令を実行するために提供され得る。
[0129]取り出しユニット５２は、クライアントデバイス４０の復号およびレンダリング能力を、マニフェストファイル６６の情報によって示されるリプレゼンテーション６８の特性と比較し得る。例えば、取り出しユニット５２は、（ビデオ出力４４のような）クライアントデバイス４０がステレオスコープデータをレンダリングすることが可能であるか、またはモノスコープデータのみをレンダリングすることが可能であるかを決定し得る。取り出しユニット５２は初めに、リプレゼンテーション６８の特性を決定するために、マニフェストファイル６６の少なくとも一部分を取り出し得る。例えば、取り出しユニット５２は、１つまたは複数の適合セットの特性を記述するマニフェストファイル６６の一部分を要求し得る。取り出しユニット５２は、クライアントデバイス４０のコーディングおよびレンダリング能力によって満たされることができる特性を有するリプレゼンテーション６８（例えば、適合セット）のサブセットを選択し得る。取り出しユニット５２はその後、適合セット中のリプレゼンテーションについてのビットレートを決定し、ネットワーク帯域幅の現在利用可能な量を決定し、およびネットワーク帯域幅によって満たされることができるビットレートを有するリプレゼンテーションのうちの１つからセグメントを取り出し得る。この開示の技法にしたがって、取り出しユニット５２は、対応する魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを示すデータを取り出し得る。例えば、取り出しユニット５２は、リプレゼンテーション６８のうちの１つのファイル（例えば、セグメント）の最初の部分を、そのファイルがモノスコープ魚眼ビデオデータを含むかまたはステレオスコープ魚眼ビデオデータを含むかを決定し、およびそのファイルのビデオデータを取り出すかどうかを決定するために、またはリプレゼンテーション６８のうちの異なる１つの異なるファイルを、クライアントデバイス４０がそのファイルの魚眼ビデオデータをレンダリングすることが可能であるか否かにしたがって、取り出し得る。
[0130]一般に、より高いビットレートリプレゼンテーションは、より高品質のビデオ再生をもたらし得、その一方でより低いビットレートリプレゼンテーションは、利用可能なネットワーク帯域幅が減少したときに十分な品質のビデオ再生を提供し得る。それ故に、利用可能なネットワーク帯域幅が比較的高いとき、取り出しユニット５２は、比較的高いビットレートリプレゼンテーションからデータを取り出し得るのに対して、利用可能なネットワーク帯域幅が低いとき、取り出しユニット５２は、比較的低いビットレートリプレゼンテーションからデータを取り出し得る。このように、クライアントデバイス４０は、ネットワーク７４の変化するネットワーク帯域幅の可用性に適合もしながら、ネットワーク７４を通してマルチメディアデータをストリーミングし得る。
[0131]加えてまたは代替として、取り出しユニット５２は、ｅＭＢＭＳまたはＩＰマルチキャストのようなブロードキャストまたはマルチキャストネットワークプロトコルにしたがってデータを受信するように構成され得る。そのような例では、取り出しユニット５２は、特定のメディアコンテンツに関連付けられたマルチキャストネットワークグループに加わるための要求をサブミットし得る。マルチキャストグループに加わった後に、取り出しユニット５２は、サーバデバイス６０またはコンテンツ準備デバイス２０に発行されるさらなる要求なしに、マルチキャストグループのデータを受信し得る。取り出しユニット５２は、例えば、再生を停止するために、または異なるマルチキャストグループにチャネルを変更するために、マルチキャストグループのデータがもはや必要とされないときに、マルチキャストグループを去るための要求をサブミットし得る。
[0132]ネットワークインターフェース５４は、選択されたリプレゼンテーションのセグメントのデータを受信し、およびそれを取り出しユニット５２に提供し得、それは次に、デカプセル化（decapsulation）ユニット５０にそれらセグメントを提供し得る。デカプセル化ユニット５０は、構成要素（constituent）ＰＥＳストリームへとビデオファイルの要素をデカプセル化し、符号化されたデータを取り出すためにＰＥＳストリームをデパケット化（depacketize）し、および、例えば、ストリームのＰＥＳパケットヘッダによって示されているように、その符号化されたデータがオーディオストリームの一部であるかまたはビデオストリームの一部であるかに依存して、オーディオ復号器４６またはビデオ復号器４８のいずれかにその符号化されたデータを送り得る。オーディオ復号器４６は、符号化されたオーディオデータを復号し、およびオーディオ出力４２に復号されたオーディオデータを送り、その一方でビデオ復号器４８は、符号化されたビデオデータを復号し、およびビデオ出力４４に復号されたビデオデータを送り、それは、ストリームの複数のビューを含み得る。
[0133]ビデオ符号化器２８、ビデオ復号器４８、オーディオ符号化器２６、オーディオ復号器４６、カプセル化ユニット３０、取り出しユニット５２、およびデカプセル化ユニット５０は各々、適宜、１つまたは複数のマイクロプロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ディスクリートロジック回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組み合わせのような、多様な適した処理回路のうちの任意のものとしてインプリメントされ得る。ビデオ符号化器２８およびビデオ復号器４８の各々は、１つまたは複数の符号化器または復号器中に含まれ得、それらのうちのいずれも、組み合わされたビデオ符号化器／復号器（ＣＯＤＥＣ）の一部として統合され得る。同様に、オーディオ符号化器２６およびオーディオ復号器４６の各々は、１つまたは複数の符号化器または復号器中に含まれ得、それらのうちのいずれも、組み合わされたＣＯＤＥＣの一部として統合され得る。ビデオ符号化器２８、ビデオ復号器４８、オーディオ符号化器２６、オーディオ復号器４６、カプセル化ユニット３０、取り出しユニット５２、および／またはデカプセル化ユニット５０を含む装置は、集積回路、マイクロプロセッサ、および／またはセルラ電話のようなワイヤレス通信デバイスを備え得る。
[0134]クライアントデバイス４０、サーバデバイス６０、および／またはコンテンツ準備デバイス２０は、この開示の技法にしたがって動作するように構成され得る。例を目的として、この開示は、クライアントデバイス４０およびサーバデバイス６０に関するこれらの技法を説明している。しかしながら、コンテンツ準備デバイス２０が、サーバデバイス６０の代わりに（またはそれに加えて）、これらの技法を実行するように構成され得ることが理解されるべきである。
[0135]カプセル化ユニット３０は、ＮＡＬユニットが属するプログラムを識別するヘッダ、ならびにペイロード、例えば、オーディオデータ、ビデオデータ、あるいはＮＡＬユニットが対応するトランスポートまたはプログラムストリームを記述するデータ、を備えるＮＡＬユニットを形成し得る。例えば、Ｈ．２６４／ＡＶＣでは、ＮＡＬユニットは、１バイトのヘッダと変動するサイズのペイロードとを含む。そのペイロード中にビデオデータを含むＮＡＬユニットは、様々な粒度（granularity）レベルのビデオデータを備え得る。例えば、ＮＡＬユニットは、ビデオデータのブロック、複数のブロック、ビデオデータのスライス、またはビデオデータのピクチャ全体を備え得る。カプセル化ユニット３０は、エレメンタリストリームのＰＥＳパケットの形状で、ビデオ符号化器２８から符号化されたビデオデータを受信し得る。カプセル化ユニット３０は、各エレメンタリストリームを対応するプログラムと関連付け得る。
[0136]カプセル化ユニット３０はまた、複数のＮＡＬユニットからアクセスユニットをアセンブルし得る。一般に、アクセスユニットは、ビデオデータのフレーム、ならびにそのフレームに対応するオーディオデータが利用可能であるときにはそのようなオーディオデータ、を表すための１つまたは複数のＮＡＬユニットを備え得る。アクセスユニットは概して、１つの出力時間インスタンスについての全てのＮＡＬユニット、例えば、１つの時間インスタンスについての全てのオーディオおよびビデオデータ、を含む。例えば、各ビューが２０フレーム／秒（ｆｐｓ）のフレームレートを有する場合、各時間インスタンスは、０．０５秒の時間間隔に対応し得る。この時間間隔中に、同じアクセスユニット（同じ時間インスタンス）の全てのビューについての特定のフレームは、同時にレンダリングされ得る。一例では、アクセスユニットは、１つの時間インスタンス中にコーディングされたピクチャを備え得、それは、プライマリのコーディングされたピクチャとして提示され得る。
[0137]それ故に、アクセスユニットは、共通の時間的インスタンスの全てのオーディオおよびビデオフレーム、例えば、時間Ｘに対応する全てのビュー、を備え得る。この開示はまた、特定のビューの符号化されたピクチャを「ビューコンポーネント」と呼ぶ。すなわち、ビューコンポーネントは、特定の時間における特定のビューについての符号化されたピクチャ（またはフレーム）を備え得る。それ故に、アクセスユニットは、共通の時間的インスタンスの全てのビューコンポーネントを備えるものとして定義され得る。アクセスユニットの復号順序は、出力または表示順序とは必ずしも同じである必要はない。
[0138]メディアプレゼンテーションは、メディアプレゼンテーション記述（ＭＰＤ）を含み得、それは、異なる代替のリプレゼンテーションの記述を包含し得（例えば、異なる品質を有するビデオサービス）、および記述は、例えば、コーデック情報、プロファイル値、およびレベル値を含み得る。ＭＰＤは、マニフェストファイル６６のようなマニフェストファイルの一例である。クライアントデバイス４０は、様々なプレゼンテーションのムービーフラグメントにどのようにアクセスするかを決定するために、メディアプレゼンテーションのＭＰＤを取り出し得る。ムービーフラグメントは、ビデオファイルのムービーフラグメントボックス（ｍｏｏｆボックス）中にロケートされ得る。
[0139]（例えば、ＭＰＤを備え得る）マニフェストファイル６６は、リプレゼンテーション６８のセグメントの可用性をアドバタイズし得る。すなわち、ＭＰＤは、リプレゼンテーション６８のうちの１つの第１のセグメントが利用可能になるウォールクロック時間（the wall-clock time）を示す情報、ならびにリプレゼンテーション６８内のセグメントの持続時間を示す情報を含み得る。このように、クライアントデバイス４０の取り出しユニット５２は、特定のセグメントに先行するセグメントの持続時間ならびに開始時間に基づいて、各セグメントがいつ利用可能になるかを決定し得る。
[0140]カプセル化ユニット３０が受信されたデータに基づいてＮＡＬユニットおよび／またはアクセスユニットをビデオファイルへとアセンブルした後に、カプセル化ユニット３０は、出力のために出力インターフェース３２にそのビデオファイルを渡す。いくつかの例では、カプセル化ユニット３０は、クライアントデバイス４０に直接ビデオファイルを送るというよりはむしろ、出力インターフェース３２を介してリモートサーバにビデオファイルを送り得るか、またはビデオファイルをローカルに記憶し得る。出力インターフェース３２は、例えば、送信機、トランシーバ、例えば、光学ドライブ、磁気媒体ドライブ（例えば、フロッピー（登録商標）ドライブ）、ユニバーサルシリアルバス（ＵＳＢ）ポート、ネットワークインターフェース、または他の出力インターフェースのような、コンピュータ可読媒体にデータを書き込むためのデバイスを備え得る。出力インターフェース３２は、例えば、送信信号、磁気媒体、光学媒体、メモリ、フラッシュドライブ、または他のコンピュータ可読媒体のようなコンピュータ可読媒体にビデオファイルを出力する。
[0141]ネットワークインターフェース５４は、ネットワーク７４を介してＮＡＬユニットまたはアクセスユニットを受信し、および取り出しユニット５２を介してデカプセル化ユニット５０にＮＡＬユニットまたはアクセスユニットを提供し得る。デカプセル化ユニット５０は、構成要素ＰＥＳストリームへとビデオファイルの要素をデカプセル化し、符号化されたデータを取り出すためにＰＥＳストリームをデパケット化し、および、例えば、ストリームのＰＥＳパケットヘッダによって示されているように、その符号化されたデータがオーディオストリームの一部であるかまたはビデオストリームの一部であるかに依存して、オーディオ復号器４６またはビデオ復号器４８のいずれかにその符号化されたデータを送り得る。オーディオ復号器４６は、符号化されたオーディオデータを復号し、およびオーディオ出力４２に復号されたオーディオデータを送り、その一方でビデオ復号器４８は、符号化されたビデオデータを復号し、およびビデオ出力４４に復号されたビデオデータを送り、それは、ストリームの複数のビューを含み得る。
[0142]このように、クライアントデバイス４０は、メディアデータを取り出すためのデバイスの例を表し、そのデバイスは、上述されたような、および／または以下の特許請求の範囲に記載されたような、魚眼ビデオデータファイルを取り出すためのデバイスを含む。例えば、クライアントデバイス４０は、魚眼ビデオデータファイルを取り出し得、および／または魚眼ビデオがモノスコープであるかまたはステレオスコープであるかの決定に基づいて魚眼ビデオをレンダリングし得、およびこの決定は、魚眼ビデオがモノスコープであるかまたはステレオスコープであるかを明示的に指定するシンタックス要素に基づき得る。
[0143]同様に、コンテンツ準備デバイス２０は、上述されたような、および／または以下の特許請求の範囲に記載されたような、魚眼ビデオデータファイルを生成するためのデバイスを表す。例えば、コンテンツ準備デバイス２０は、魚眼ビデオがモノスコープであるかまたはステレオスコープであるかを明示的に指定するシンタックス要素を、魚眼ビデオデータ中に含め得る。
[0144]図１０は、実例的なマルチメディアコンテンツ１２０の要素を例示する概念図である。マルチメディアコンテンツ１２０は、マルチメディアコンテンツ６４（図９）、または記憶媒体６２中に記憶された別のマルチメディアコンテンツに対応し得る。図１０の例では、マルチメディアコンテンツ１２０は、メディアプレゼンテーション記述（ＭＰＤ）１２２と複数のリプレゼンテーション１２４Ａ〜１２４Ｎ（リプレゼンテーション１２４）とを含む。リプレゼンテーション１２４Ａは、オプションのヘッダデータ１２６とセグメント１２８Ａ〜１２８Ｎ（セグメント１２８）とを含み、その一方でリプレゼンテーション１２４Ｎは、オプションのヘッダデータ１３０とセグメント１３２Ａ〜１３２Ｎ（セグメント１３２）とを含む。Ｎの文字は、便宜上、リプレゼンテーション１２４の各々中の最後のムービーフラグメントを指定するために使用されている。いくつかの例では、リプレゼンテーション１２４間に異なる数のムービーフラグメントが存在し得る。
[0145]ＭＰＤ１２２は、リプレゼンテーション１２４とは別個のデータ構造を備え得る。ＭＰＤ１２２は、図９のマニフェストファイル６６に対応し得る。一般に、ＭＰＤ１２２は、コーディングおよびレンダリング特性、適合セット、ＭＰＤ１２２が対応するプロファイル、テキストタイプ情報、カメラアングル情報、レーティング情報、トリックモード情報（例えば、時間的サブシーケンスを含むリプレゼンテーションを示す情報）、および／または（例えば、再生中におけるメディアコンテンツへのターゲット広告の挿入のための）リモート期間を取り出すための情報のような、リプレゼンテーション１２４の特性を概して記述するデータを含み得る。
[0146]ヘッダデータ１２６は、存在するとき、セグメント１２８の特性、例えば、ランダムアクセスポイント（ＲＡＰ、ストリームアクセスポイント（ＳＡＰ）とも呼ばれる）の時間的ロケーション、セグメント１２８のうちのどれがランダムアクセスポイントを含むか、セグメント１２８内のランダムアクセスポイントに対するバイトオフセット、セグメント１２８のユニフォームリソースロケータ（ＵＲＬ）、またはセグメント１２８の他の態様を記述し得る。ヘッダデータ１３０は、存在するとき、セグメント１３２についての同様の特性を記述し得る。加えてまたは代替として、そのような特性は、ＭＰＤ１２２内に完全に含まれ得る。
[0147]セグメント１２８、１３２は、１つまたは複数のコーディングされたビデオサンプルを含み、それらの各々は、ビデオデータのフレームまたはスライスを含み得る。セグメント１２８のコーディングされたビデオサンプルの各々は、同様の特性、例えば、高さ、幅、および帯域幅要件を有し得る。そのような特定は、ＭＰＤ１２２のデータによって記述され得るが、そのようなデータは、図１０の例には例示されていない。ＭＰＤ１２２は、この開示に説明されるシグナリングされる情報のうちの任意のものまたは全ての追加とともに、３ＧＰＰ仕様書によって説明されるような特性を含み得る。
[0148]セグメント１２８、１３２の各々は、一意のユニフォームリソースロケータ（ＵＲＬ）に関連付けられ得る。このことから、セグメント１２８、１３２の各々は、ＤＡＳＨのようなストリーミングネットワークプロトコルを使用して、独立して取り出し可能であり得る。このように、クライアントデバイス４０のような宛先デバイスは、セグメント１２８または１３２を取り出すために、ＨＴＴＰ ＧＥＴ要求を使用し得る。いくつかの例では、クライアントデバイス４０は、セグメント１２８または１３２の特定のバイト範囲を取り出すために、ＨＴＴＰ部分的ＧＥＴ要求を使用し得る。
[0149]図１１は、実例的なビデオファイル１５０の要素を例示するブロック図であり、それは、図１０のセグメント１１４、１２４のうちの１つのような、リプレゼンテーションのセグメントに対応し得る。セグメント１２８、１３２の各々は、図１１の例において例示されているデータの配列に実質的に一致するデータを含み得る。ビデオファイル１５０は、セグメントをカプセル化すると言われ得る。上述されたように、ＩＳＯベースメディアファイルフォーマットおよびその拡張にしたがったビデオファイルは、「ボックス」と呼ばれる一連のオブジェクト中にデータを記憶する。図１１の例では、ビデオファイル１５０は、ファイルタイプ（ＦＴＹＰ）ボックス１５２、ムービー（ＭＯＯＶ）ボックス１５４、セグメントインデックス（ｓｉｄｘ）ボックス１６２、ムービーフラグメント（ＭＯＯＦ）ボックス１６４、およびムービーフラグメントランダムアクセス（ＭＦＲＡ）ボックス１６６を含む。図１１は、ビデオファイルの例を表しているが、他のメディアファイルが、ＩＳＯベースメディアファイルフォーマットおよびその拡張にしたがった、ビデオファイル１５０のデータと同様に構造化された他のタイプのメディアデータ（例えば、オーディオデータ、時間指定されたテキストデータ、または同様のもの）を含み得ることが理解されるべきである。
[0150]ファイルタイプ（ＦＴＹＰ）ボックス１５２は概して、ビデオファイル１５０についてのファイルタイプを記述する。ファイルタイプボックス１５２は、ビデオファイル１５０についての最良の使用を記述する仕様を識別するデータを含み得る。ファイルタイプボックス１５２は代替として、ＭＯＯＶボックス１５４、ムービーフラグメントボックス１６４、および／またはＭＦＲＡボックス１６６の前に配置され得る。
[0151]いくつかの例では、ビデオファイル１５０のようなセグメントは、ＦＴＹＰボックス１５２の前にＭＰＤ更新ボックス（図示せず）を含み得る。ＭＰＤ更新ボックスは、ＭＰＤを更新するための情報とともに、ビデオファイル１５０を含むリプレゼンテーションに対応するＭＰＤが更新されるべきであることを示す情報を含み得る。例えば、ＭＰＤ更新ボックスは、ＭＰＤを更新するために使用されるべきリソースについてのＵＲＩまたはＵＲＬを提供し得る。別の例として、ＭＰＤ更新ボックスは、ＭＰＤを更新するためのデータを含み得る。いくつかの例では、ＭＰＤ更新ボックスは、ビデオファイル１５０のセグメントタイプ（ＳＴＹＰ）ボックス（図示せず）の直後に後続し得、ここで、ＳＴＹＰボックスは、ビデオファイル１５０についてのセグメントタイプを定義し得る。
[0152]ＭＯＯＶボックス１５４は、図１１の例では、ムービーヘッダ（ＭＶＨＤ）ボックス１５６、トラック（ＴＲＡＫ）ボックス１５８、および１つまたは複数のムービー拡張（ＭＶＥＸ）ボックス１６０を含む。一般に、ＭＶＨＤボックス１５６は、ビデオファイル１５０の一般の特性を記述し得る。例えば、ＭＶＨＤボックス１５６は、いつビデオファイル１５０が当初に作成されたか、いつビデオファイル１５０が最後に修正されたか、ビデオファイル１５０についての時間スケール、ビデオファイル１５０についての再生の持続時間、またはビデオファイル１５０を概して記述する他のデータ、を記述するデータを含み得る。
[0153]ＴＲＡＫボックス１５８は、ビデオファイル１５０のトラックについてのデータを含み得る。ＴＲＡＫボックス１５８は、ＴＲＡＫボックス１５８に対応するトラックの特性を記述するトラックヘッダ（ＴＫＨＤ）ボックスを含み得る。いくつかの例では、ＴＲＡＫボックス１５８は、コーディングされたビデオピクチャを含み得、その一方で他の例では、トラックのコーディングされたビデオピクチャは、ムービーフラグメント１６４中に含まれ得、それは、ＴＲＡＫボックス１５８および／またはｓｉｄｘボックス１６２のデータによって参照され得る。
[0154]いくつかの例では、ビデオファイル１５０は、１つより多くのトラックを含み得る。それ故に、ＭＯＯＶボックス１５４は、ビデオファイル１５０中のトラックの数に等しいいくつかのＴＲＡＫボックスを含み得る。ＴＲＡＫボックス１５８は、ビデオファイル１５０の対応するトラックの特性を記述し得る。例えば、ＴＲＡＫボックス１５８は、対応するトラックについての時間的および／または空間的情報を記述し得る。ＭＯＯＶボックス１５４のＴＲＡＫボックス１５８と同様なＴＲＡＫボックスは、カプセル化ユニット３０（図９）がビデオファイル１５０のようなビデオファイル中にパラメータセットトラックを含めるときに、パラメータセットトラックの特性を記述し得る。カプセル化ユニット３０は、パラメータセットトラックを記述するＴＲＡＫボックス内で、パラメータセットトラック中のシーケンスレベルＳＥＩメッセージの存在をシグナリングし得る。
[0155]ＭＶＥＸボックス１６０は、例えば、ある場合には、ＭＯＯＶボックス１５４内に含まれるビデオデータに加えて、ビデオファイル１５０がムービーフラグメント１６４を含むことをシグナリングするために、対応するムービーフラグメント１６４の特性を記述し得る。ビデオデータをストリーミングすることのコンテキストでは、コーディングされたビデオピクチャは、ＭＯＯＶボックス１５４中というよりはむしろムービーフラグメント１６４中に含まれ得る。それ故に、全てのコーディングされたビデオサンプルは、ＭＯＯＶボックス１５４中というよりはむしろ、ムービーフラグメント１６４中に含まれ得る。
[0156]ＭＯＯＶボックス１５４は、ビデオファイル１５０中のムービーフラグメント１６４の数に等しいいくつかのＭＶＥＸボックス１６０を含み得る。ＭＶＥＸボックス１６０の各々は、ムービーフラグメント１６４のうちの対応するものの特性を記述し得る。例えば、各ＭＶＥＸボックスは、ムービーフラグメント１６４のうちの対応するものについての時間的持続時間（a temporal duration）を記述するムービー拡張ヘッダボックス（ＭＥＨＤ）ボックスを含み得る。
[0157]さらに、この開示の技法にしたがって、ビデオファイル１５０は、SchemeInformationBox中にFisheyeOmnidirectionalVideoBoxを含み得、それは、ＭＯＯＶボックス１５４中に含まれ得る。いくつかの例では、FisheyeOmnidirectionalVieoBoxは、ビデオファイル１５０の異なるトラックがモノスコープまたはステレオスコープ魚眼ビデオデータを含み得る場合に、ＴＲＡＫボックス１５８中に含まれ得る。いくつかの例では、FisheyeOmnidirectionalVieoBoxは、ＦＯＶボックス１５７中に含まれ得る。
[0158]上述されたように、カプセル化ユニット３０は、実際のコーディングされたビデオデータを含まないビデオサンプル中にシーケンスデータセットを記憶し得る。ビデオサンプルは概して、アクセスニットに対応し得、それは、特定の時間インスタンスにおけるコーディングされたピクチャのリプレゼンテーションである。ＡＶＣのコンテキストでは、コーディングされたピクチャは、アクセスユニットの全てのピクセルを構築するための情報を包含する１つまたは複数のＶＣＬ ＮＡＬユニットと、ＳＥＩメッセージのような他の関連する非ＶＣＬ ＮＡＬユニットとを含み得る。それ故に、カプセル化ユニット３０は、ムービーフラグメント１６４のうちの１つ中にシーケンスデータセットを含め得、それは、シーケンスレベルＳＥＩメッセージを含み得る。カプセル化ユニット３０はさらに、ムービーフラグメント１６４のうちの１つに対応するＭＶＥＸボックス１６０のうちの１つ内で、ムービーフラグメント１６４のうちの１つ中に存在するものとして、シーケンスレベルＳＥＩメッセージおよび／またはシーケンスデータセットの存在をシグナリングし得る。
[0159]ＳＩＤＸボックス１６２は、ビデオファイル１５０のオプションの要素である。すなわち、３ＧＰＰファイルフォーマット、または他のそのようなファイルフォーマットに準拠するビデオファイルは、必ずしもＳＩＤＸボックス１６２を含むわけではない。３ＧＰＰファイルフォーマットの例にしたがって、ＳＩＤＸボックスは、セグメント（例えば、ビデオファイル１５０内に包含されるセグメント）のサブセグメントを識別するために使用され得る。３ＧＰＰファイルフォーマットは、サブセグメントを、「対応するメディアデータボックス（１つ以上）を有する１つまたは複数の連続するムービーフラグメントボックスの内蔵された（self-contained）セットであって、ムービーフラグメントボックスによって参照されるデータを包含するメディアデータボックスは、そのムービーフラグメントボックスに後続し、および同じトラックについての情報を包含する次のムービーフラグメントボックスに先行しなければならない」と定義している。３ＧＰＰファイルフォーマットはまた、ＳＩＤＸボックスが、「ボックスによってドキュメントされる（サブ）セグメントのサブセグメントへの参照のシーケンスを包含する。参照されるサブセグメントは、提示時間において連続している。同様に、セグメントインデックスボックスによって参照されるバイトは常に、セグメント内で連続している。参照されるサイズは、参照されるマテリアル中のバイトの数のカウントを示す（gives）」ことを示す。
[0160]ＳＩＤＸボックス１６２は概して、ビデオファイル１５０中に含まれるセグメントの１つまたは複数のサブセグメントを表す情報を提供する。例えば、そのような情報は、サブセグメントが始まるおよび／または終了する再生時間、サブセグメントについてのバイトオフセット、サブセグメントがストリームアクセスポイント（ＳＡＰ）を含む（例えば、それから開始する）かどうか、ＳＡＰについてのタイプ（例えば、ＳＡＰが瞬時復号器リフレッシュ（ＩＤＲ：instantaneous decoder refresh）ピクチャ、クリーンランダムアクセス（ＣＲＡ）ピクチャ、ブロークンリンクアクセス（ＢＬＡ）ピクチャ、または同様のものであるか）、サブセグメント中の（再生時間および／またはバイトオフセットの観点からの）ＳＡＰの位置、および同様のもの、を含み得る。
[0161]ムービーフラグメント１６４は、１つまたは複数のコーディングされたビデオピクチャを含み得る。いくつかの例では、ムービーフラグメント１６４は、１つまたは複数のピクチャのグループ（ＧＯＰ：group of pictures）を含み得、それらの各々は、いくつかのコーディングされたビデオピクチャ、例えば、フレームまたはピクチャを含み得る。加えて、上述されたように、ムービーフラグメント１６４は、いくつかの例ではシーケンスデータセットを含み得る。ムービーフラグメント１６４の各々は、ムービーフラグメントヘッダボックス（ＭＦＨＤ、図１１には図示せず）を含み得る。ＭＦＨＤボックスは、ムービーフラグメントについてのシーケンス番号のような、対応するムービーフラグメントの特性を記述し得る。ムービーフラグメント１６４は、ビデオファイル１５０中にシーケンス番号の順序で含まれ得る。
[0162]ＭＦＲＡボックス１６６は、ビデオファイル１５０のムービーフラグメント１６４内のランダムアクセスポイントを記述し得る。これは、ビデオファイル１５０によってカプセル化されたセグメント内の特定の時間的ロケーション（すなわち、再生時間）に対してシークを実行するといったような、トリックモードを実行することを支援し得る。ＭＦＲＡボックス１６６は概してオプションであり、およびいくつかの例では、ビデオファイル中に含まれる必要はない。同様に、クライアントデバイス４０のようなクライアントデバイスは、ビデオファイル１５０のビデオデータを正しく復号および表示するために、必ずしもＭＦＲＡボックス１６６を参照する必要はない。ＭＦＲＡボックス１６６は、ビデオファイル１５０のトラックの数に等しいか、またはいくつかの例では、ビデオファイル１５０のメディアトラック（例えば、非ヒントトラック）の数に等しい、いくつかのトラックフラグメントランダムアクセス（ＴＦＲＡ）ボックス（図示せず）を含み得る。
[0163]いくつかの例では、ムービーフラグメント１６４は、ＩＤＲピクチャのような１つまたは複数のストリームアクセスポイント（ＳＡＰ）を含み得る。同様に、ＭＦＲＡボックス１６６は、ＳＡＰのビデオファイル１５０内のロケーションのインジケーションを提供し得る。それ故に、ビデオファイル１５０の時間的サブシーケンスは、ビデオファイル１５０のＳＡＰから形成され得る。時間的サブシーケンスはまた、ＳＡＰに従属する（depend from）Ｂフレームおよび／またはＰフレームのような他のピクチャを含み得る。時間的サブシーケンスのフレームおよび／またはスライスは、サブシーケンスの他のフレーム／スライスに依存する時間的サブシーケンスのフレーム／スライスが適正に復号されることができるように、セグメント内に配列され得る。例えば、データの階層的配列では、他のデータについての予測のために使用されるデータもまた、時間的サブシーケンス中に含まれ得る。
[0164]図１２は、この開示の１つまたは複数の技法にしたがった、魚眼ビデオデータを含むファイルを処理するための実例的な技法を例示するフローチャートである。図１２の技法は、図９のクライアントデバイス４０によって実行されるものとして説明されるが、クライアントデバイス４０以外の構成を有するデバイスが、図１２の技法を実行し得る。
[0165]クライアントデバイス４０は、魚眼ビデオデータと、魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造とを含むファイルを受信し得る（１２０２）。上述されたように、複数のシンタックス要素は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第１のシンタックス要素と、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを暗示的に示す１つまたは複数のシンタックス要素とを含み得る。魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを暗示的に示す１つまたは複数のシンタックス要素は、魚眼ビデオデータをキャプチャするために使用されるカメラの外部（extrinsic）パラメータを明示的に示すシンタックス要素であり得る。いくつかの例では、１つまたは複数のシンタックス要素は、ＯＭＡＦ ＤＩＳの現在の草案中のFisheyeOmnidirectionalVideoInfo( )シンタックス構造中に含まれるシンタックス要素であり得るか、またはそれと同様であり得る。いくつかの例では、第１のシンタックス要素は、シンタックス構造の最初のビット（initial bits）のセット（例えば、FisheyeOmnidirectionalVideoInfo( )シンタックス構造の最初の(initial)２４ビット）中に含まれ得る。
[0166]クライアントデバイス４０は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、第１のシンタックス要素に基づいて決定し得る（１２０４）。第１のシンタックス要素の値は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示し得る。一例として、第１のシンタックス要素が第１の値を有する場合、クライアントデバイス４０は、魚眼ビデオデータがモノスコープである（すなわち、魚眼ビデオデータのピクチャ中に含まれる円形画像が、揃えられた(aligned)光軸を有し、且つ対向方向（opposite directions）を向いている）と決定し得る。別の例として、第１のシンタックス要素が第２の値を有する場合、クライアントデバイス４０は、魚眼ビデオデータがステレオスコープである（すなわち、魚眼ビデオデータのピクチャ中に含まれる円形画像が、平行な光軸を有し、且つ同じ方向を向いている）と決定し得る。
[0167]上述されたように、魚眼ビデオデータをキャプチャするために使用されるカメラの外部パラメータを明示的に示すシンタックス要素に基づいて、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかをクライアントデバイス４０が決定することは可能であり得るが、そのような算出は、クライアントデバイス４０上での計算負荷を増大させ得る。このように、実行される算出（およびこのことから、使用される計算リソース）を低減するために、クライアントデバイス４０は、第１のシンタックス要素に基づいて、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを決定し得る。
[0168]クライアントデバイス４０は、その決定に基づいて、魚眼ビデオデータをレンダリングし得る。例えば、魚眼ビデオデータがモノスコープであると決定することに応答して、クライアントデバイス４０は、モノスコープとして魚眼データをレンダリングし得る（１２０６）。例えば、クライアントデバイス４０は、ビューポート（すなわち、ユーザが現在「見ている」球の一部分）を決定することと、ビューポートに対応する魚眼ビデオデータの円形画像の一部分を識別することと、視聴者の目の各々に円形画像の同じ部分を表示することとを行い得る。同様に、魚眼ビデオデータがステレオスコープであると決定することに応答して、クライアントデバイス４０は、ステレオスコープとして魚眼データをレンダリングし得る（１２０８）。例えば、クライアントデバイス４０は、ビューポート（すなわち、ユーザが現在「見ている」球の一部分）を決定することと、ビューポートに対応する魚眼ビデオデータの円形画像の各々のそれぞれの部分を識別することと、視聴者の目に円形画像のそれぞれの部分を表示することとを行い得る。
[0169]図１３は、この開示の１つまたは複数の技法にしたがった、魚眼ビデオデータを含むファイルを生成するための実例的な技法を例示するフローチャートである。図１３の技法は、図９のコンテンツ準備デバイス２０によって実行されるものとして説明されるが、コンテンツ準備デバイス２０以外の構成を有するデバイスが、図１３の技法を実行し得る。
[0170]コンテンツ準備デバイス２０は、魚眼ビデオデータと、魚眼ビデオデータをキャプチャするために使用されるカメラの外部パラメータとを取得し得る（１３０２）。例えば、コンテンツ準備デバイス２０は、ＨＥＶＣのようなビデオコーデックを使用して符号化されている魚眼ビデオデータのピクチャを取得し得る。魚眼ビデオデータのピクチャの各々は、魚眼レンズを有する異なるカメラによってキャプチャされた画像に各々対応する複数の円形画像を含み得る（例えば、ピクチャは、図１Ａの魚眼レンズ１２Ａを介してキャプチャされた第１の円形画像と、図１Ａの魚眼レンズ１２Ｂを介してキャプチャされた第２の円形画像とを含み得る）。外部パラメータは、カメラの様々な属性を指定し得る。例えば、外部パラメータは、魚眼ビデオデータをキャプチャするために使用されるカメラの各々のヨー角、ピッチ角、ロール角、および１つまたは複数の空間的オフセットを指定し得る。
[0171]コンテンツ準備デバイス２０は、魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、外部パラメータに基づいて決定し得る（１３０４）。一例として、カメラ外部パラメータ値の２つのセットが次の通りであるとき、コンテンツ準備デバイス２０は、魚眼ビデオがステレオスコープであると決定し得る：
第１のセット（1st set）:
camera_center_yaw = 0 degrees (+/- 5 degrees)
camera center_pitch = 0 degrees (+/- 5 degrees)
camera center roll = 0 degrees (+/- 5 degrees)
camera_center_offset_x = 0 mm (+/- 3 mm)
camera_center_offset_y = 0 mm (+/- 3 mm)
camera_center_offset_z = 0 mm (+/- 3 mm)
第2のセット（2nd set）:
camera_center_yaw = 0 degrees (+/- 5 degrees)
camera center_pitch = 0 degrees (+/- 5 degrees)
camera center roll = 0 degrees (+/- 5 degrees)
camera_center_offset_x = 64 mm (+/- 3 mm)
camera_center_offset_y = 0 mm (+/- 3 mm)
camera_center_offset_z = 0 mm (+/- 3 mm)
[0172]別の例として、カメラ外部パラメータ値の２つのセットが次の通りであるとき、コンテンツ準備デバイス２０は、魚眼ビデオがモノスコープであると決定し得る：
第１のセット（1st set）:
camera_center_yaw = 0 degrees (+/- 5 degrees)
camera center_pitch = 0 degrees (+/- 5 degrees)
camera center roll = 0 degrees (+/- 5 degrees)
camera_center_offset_x = 0 mm (+/- 3 mm)
camera_center_offset_y = 0 mm (+/- 3 mm)
camera_center_offset_z = 0 mm (+/- 3 mm)
第２のセット（2nd set）:
camera_center_yaw = 180 degrees (+/- 5 degrees)
camera center_pitch = 0 degrees (+/- 5 degrees)
camera center roll = 0 degrees (+/- 5 degrees)
camera_center_offset_x = 0 mm (+/- 3 mm)
camera_center_offset_y = 0 mm (+/- 3 mm)
camera_center_offset_z = 0 mm (+/- 3 mm)
[0173]コンテンツ準備デバイス２０は、魚眼ビデオデータと、魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造とをファイル中で符号化し得る（１３０６）。複数のシンタックス要素は、次を含む：魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第１のシンタックス要素、および魚眼ビデオデータをキャプチャするために使用されるカメラの外部パラメータを明示的に示す１つまたは複数のシンタックス要素。
[0174]１つまたは複数の例では、説明された機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組み合わせにおいてインプリメントされ得る。ソフトウェアにおいてインプリメントされる場合、それら機能は、１つまたは複数の命令またはコードとして、コンピュータ可読媒体上に記憶され得るか、またはコンピュータ可読媒体を通して送信され得、およびハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、例えば、通信プロトコルにしたがって、コンピュータプログラムのある場所から別の場所への転送を容易にする任意の媒体を含む通信媒体、またはコンピュータ可読記憶媒体を含み得、それは、データ記憶媒体のような有形媒体に対応する。このように、コンピュータ可読媒体は概して、（１）非一時的である有形コンピュータ可読記憶媒体、あるいは（２）信号または搬送波のような通信媒体に対応し得る。データ記憶媒体は、この開示に説明された技法のインプリメンテーションのための命令、コード、および／またはデータ構造を取り出すために、１つまたは複数のコンピュータあるいは１つまたは複数のプロセッサによってアクセスされることができる任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。
[0175]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ−ＲＯＭまたは他の光ディスク記憶装置、磁気ディスク記憶装置、または他の磁気記憶デバイス、フラッシュメモリ、あるいはデータ構造もしくは命令の形態で所望されるプログラムコードを記憶するために使用されることができ、且つコンピュータによってアクセスされることができる任意の他の媒体を備えることができる。また、任意の接続は、厳密にはコンピュータ可読媒体と称される。例えば、命令が、ウェブサイト、サーバ、あるいは同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）、または赤外線、無線、およびマイクロ波のようなワイヤレス技術を使用する他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、ＤＳＬ、または赤外線、無線、およびマイクロ波のようなワイヤレス技術は、媒体の定義中に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象にすることが理解されるべきである。ディスク（disk）およびディスク（disc）は、ここに使用される場合、コンパクトディスク（disc）（ＣＤ）、レーザーディスク（登録商標）（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピーディスク（disk）、およびＢｌｕ−ｒａｙ（登録商標）ディスク（disc）を含み、ここで、ディスク（disk）は通常、磁気的にデータを再生し、その一方でディスク（disc）は、レーザーを用いて光学的にデータを再生する。上記の組み合わせもまた、コンピュータ可読媒体の範囲内に含まれるべきである。
[0176]命令は、１つまたは複数のデジタルシグナルプロセッサ(ＤＳＰ)、汎用マイクロプロセッサ、特定用途向け集積回路(ＡＳＩＣ)、フィールドプログラマブルロジックアレイ(ＦＰＧＡ)、あるいは他の同等な集積またはディスクリートロジック回路のような１つまたは複数のプロセッサによって実行され得る。それ故に、「プロセッサ」という用語は、ここに使用される場合、前述の構造のうちの任意のものまたはここに説明された技法のインプリメンテーションに適した任意の他の構造を指し得る。加えて、いくつかの態様では、ここに説明された機能は、符号化および復号のために構成された専用ハードウェアおよび／またはソフトウェアモジュール内で提供され得るか、あるいは組み合わされたコーデック中に組み込まれ得る。また、それら技法は、１つまたは複数の回路またはロジック要素において十分にインプリメントされることができる。
[0177]この開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）またはＩＣのセット（例えば、チップセット）を含む、幅広い多様なデバイスまたは装置においてインプリメントされ得る。様々なコンポーネント、モジュール、またはユニットは、開示された技法を実行するように構成されたデバイスの機能的な態様を強調するためにこの開示に説明されているが、必ずしも異なるハードウェアユニットによる実現を必要とするわけではない。むしろ、上述されたように、様々なユニットは、コーデックハードウェアユニット中で組み合わされ得るか、あるいは、適したソフトウェアおよび／またはファームウェアと併せて、上述されたような１つまたは複数のプロセッサを含む、相互運用ハードウェアユニットの集合によって提供され得る。
[0178]様々な例が説明されてきた。これらおよび他の例は、次の特許請求の範囲内にある。

Claims (38)

  1. ビデオデータを含むファイルを処理する方法であって、前記方法は、
    魚眼ビデオデータを含むファイルを処理することと、前記ファイルは、前記魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造を含み、ここにおいて、前記複数のシンタックス要素は、前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第１のシンタックス要素と、前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを暗示的に示す１つまたは複数のシンタックス要素とを含む、
    前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、前記第１のシンタックス要素に基づいて決定することと、
    モノスコープまたはステレオスコープとしてレンダリングするために、前記魚眼ビデオデータを前記決定に基づいて出力することと、
    を備える、方法。
  2. 前記第１のシンタックス要素は、前記シンタックス構造の最初のビットのセット中に含まれる、請求項１に記載の方法。
  3. 前記最初のビットのセットは、長さが２４ビットである、請求項２に記載の方法。
  4. 前記ファイルは、前記シンタックス構造を含むボックスを含む、請求項１に記載の方法。
  5. 前記ボックスは、スキーム情報を含む第２のボックス中に含まれている第１のボックスであり、前記方法は、
    前記魚眼ビデオデータのピクチャがリージョンワイズパッキングされているかどうかを示す第３のボックスを前記第１のボックスが含むかどうかを決定すること、
    をさらに備える、請求項４に記載の方法。
  6. 前記第１のボックスが前記第３のボックスを含むと決定することに応答して、前記魚眼ビデオデータの前記ピクチャをレンダリングするより前に前記魚眼ビデオデータの前記ピクチャをアンパッキングすること、または、
    前記第１のボックスが前記第３のボックスを含まないと決定することに応答して、前記魚眼ビデオデータの前記ピクチャをアンパッキングすることなしに前記魚眼ビデオデータの前記ピクチャをレンダリングすること、
    をさらに備える、請求項５に記載の方法。
  7. 前記第１のボックスは、SchemeInformationBoxであり、前記第２のボックスは、FisheyeOmnidirectionalVideoBoxであり、および前記第３のボックスは、RegionWisePackingBoxである、請求項５に記載の方法。
  8. 前記シンタックス構造は、前記魚眼ビデオデータの各ピクチャ中に含まれる円形画像の数を指定する第２のシンタックス要素をさらに含む、請求項１に記載の方法。
  9. 前記シンタックス構造は、それぞれの円形画像ごとに、前記それぞれの円形画像のビュー識別子を示すそれぞれの第３のシンタックス要素を備える、請求項８に記載の方法。
  10. 前記シンタックス構造は、前記ファイルによってカプセル化されるビデオコーディングレイヤ（ＶＣＬ）データの外部にある、請求項１に記載の方法。
  11. 前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを決定することは、
    前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、前記第１のシンタックス要素に基づいて、および前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを暗示的に示す前記シンタックス要素にかかわらず決定すること、
    を備える、請求項１に記載の方法。
  12. ビデオデータを含むファイルを生成するための方法であって、前記方法は、
    魚眼ビデオデータと、前記魚眼ビデオデータをキャプチャするために使用されるカメラの外部パラメータとを取得することと、
    前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、前記外部パラメータに基づいて決定することと、
    前記魚眼ビデオデータと、前記魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造とを、ファイル中で符号化することと、ここにおいて、前記複数のシンタックス要素は、前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第１のシンタックス要素と、前記魚眼ビデオデータをキャプチャするために使用される前記カメラの前記外部パラメータを明示的に示す１つまたは複数のシンタックス要素とを含む、
    を備える、方法。
  13. 前記第１のシンタックス要素を符号化することは、前記シンタックス構造の最初のビットのセット中の前記第１のシンタックス要素を符号化することを備える、請求項１２に記載の方法。
  14. 前記最初のビットのセットは、長さが２４ビットである、請求項１３に記載の方法。
  15. 前記ファイルは、前記シンタックス構造を含むボックスを含む、請求項１２に記載の方法。
  16. 前記ボックスは、スキーム情報を含む第２のボックス中に含まれている第１のボックスであり、前記方法は、
    前記魚眼ビデオデータのピクチャがリージョンワイズパッキングされているかどうかを示す第３のボックスを、前記第１のボックス中に符号化すること、
    をさらに備える、請求項１５に記載の方法。
  17. 前記第１のボックスは、SchemeInformationBoxであり、前記第２のボックスは、FisheyeOmnidirectionalVideoBoxであり、および前記第３のボックスは、RegionWisePackingBoxである、請求項１６に記載の方法。
  18. 前記シンタックス構造は、前記魚眼ビデオデータの各ピクチャ中に含まれる円形画像の数を指定する第２のシンタックス要素をさらに含む、請求項１２に記載の方法。
  19. 前記シンタックス構造は、それぞれの円形画像ごとに、前記それぞれの円形画像のビュー識別子を示すそれぞれの第３のシンタックス要素を備える、請求項１８に記載の方法。
  20. 前記魚眼ビデオデータは、ビデオコーディングレイヤ（ＶＣＬ）中に符号化され、および前記シンタックス構造は、前記ＶＣＬの外部にある、請求項１２に記載の方法。
  21. ビデオデータを処理するためのデバイスであって、前記デバイスは、
    魚眼ビデオデータを含むファイルの少なくとも一部分を記憶するように構成されたメモリと、前記ファイルは、前記魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造を含み、ここにおいて、前記複数のシンタックス要素は、前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第１のシンタックス要素と、前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを暗示的に示す１つまたは複数のシンタックス要素とを含む、
    1つまたは複数のプロセッサと、
    を備え、前記1つまたは複数のプロセッサは、
    前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、前記第１のシンタックス要素に基づいて決定することと、
    モノスコープまたはステレオスコープとしてレンダリングするために、前記魚眼ビデオデータを前記決定に基づいて出力することと、
    を行うように構成された、デバイス。
  22. 前記第１のシンタックス要素は、前記シンタックス構造の最初のビットのセット中に含まれる、請求項２１に記載のデバイス。
  23. 前記最初のビットのセットは、長さが２４ビットである、請求項２２に記載のデバイス。
  24. 前記ファイルは、前記シンタックス構造を含むボックスを含む、請求項２１に記載のデバイス。
  25. 前記ボックスは、スキーム情報を含む第２のボックス中に含まれている第１のボックスであり、前記１つまたは複数のプロセッサは、
    前記魚眼ビデオデータのピクチャがリージョンワイズパッキングされているかどうかを示す第３のボックスを前記第１のボックスが含むかどうかを決定すること、
    を行うようにさらに構成される、請求項２４に記載のデバイス。
  26. 前記第１のボックスが前記第３のボックスを含むと決定することに応答して、前記１つまたは複数のプロセッサは、前記魚眼ビデオデータの前記ピクチャをレンダリングするより前に前記魚眼ビデオデータの前記ピクチャをアンパッキングするようにさらに構成される、または、
    前記第１のボックスが前記第３のボックスを含まないと決定することに応答して、前記１つまたは複数のプロセッサは、前記魚眼ビデオデータの前記ピクチャをアンパッキングすることなしに前記魚眼ビデオデータの前記ピクチャをレンダリングするようにさらに構成される、
    請求項２５に記載のデバイス。
  27. 前記第１のボックスは、SchemeInformationBoxであり、前記第２のボックスは、FisheyeOmnidirectionalVideoBoxであり、および前記第３のボックスは、RegionWisePackingBoxである、請求項２５に記載のデバイス。
  28. 前記シンタックス構造は、前記魚眼ビデオデータの各ピクチャ中に含まれる円形画像の数を指定する第２のシンタックス要素をさらに含む、請求項２１に記載のデバイス。
  29. 前記シンタックス構造は、前記ファイルによってカプセル化されるビデオコーディングレイヤ（ＶＣＬ）データの外部にある、請求項２１に記載のデバイス。
  30. 前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを決定するために、前記１つまたは複数のプロセッサは、
    前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、前記第１のシンタックス要素に基づいて、および前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを暗示的に示す前記シンタックス要素にかかわらず決定すること
    を行うように構成される、請求項２１に記載のデバイス。
  31. ビデオデータを含むファイルを生成するためのデバイスであって、前記デバイスは、
    魚眼ビデオデータを記憶するように構成されたメモリと、
    1つまたは複数のプロセッサと、を備え、前記1つまたは複数のプロセッサは、
    前記魚眼ビデオデータをキャプチャするために使用されるカメラの外部パラメータを取得することと、
    前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを、前記外部パラメータに基づいて決定することと、
    前記魚眼ビデオデータと、前記魚眼ビデオデータの属性を指定する複数のシンタックス要素を含むシンタックス構造とをファイル中で符号化することと、ここにおいて、前記複数のシンタックス要素は、前記魚眼ビデオデータがモノスコープであるかまたはステレオスコープであるかを明示的に示す第１のシンタックス要素と、前記魚眼ビデオデータをキャプチャするために使用される前記カメラの前記外部パラメータを明示的に示す１つまたは複数のシンタックス要素とを含む、
    を行うように構成された、デバイス。
  32. 前記第１のシンタックス要素を符号化するために、前記１つまたは複数のプロセッサは、前記シンタックス構造の最初のビットのセット中の前記第１のシンタックス要素を符号化するように構成される、請求項３１に記載のデバイス。
  33. 前記最初のビットのセットは、長さが２４ビットである、請求項３２に記載のデバイス。
  34. 前記ファイルは、前記シンタックス構造を含むボックスを含む、請求項３１に記載のデバイス。
  35. 前記ボックスは、スキーム情報を含む第２のボックス中に含まれている第１のボックスであり、前記１つまたは複数のプロセッサは、
    前記魚眼ビデオデータのピクチャがリージョンワイズパッキングされているかどうかを示す第３のボックスを、前記第１のボックス中に符号化すること、
    を行うようにさらに構成される、請求項３４に記載のデバイス。
  36. 前記第１のボックスは、SchemeInformationBoxであり、前記第２のボックスは、FisheyeOmnidirectionalVideoBoxであり、および前記第３のボックスは、RegionWisePackingBoxである、請求項３５に記載のデバイス。
  37. 前記シンタックス構造は、前記魚眼ビデオデータの各ピクチャ中に含まれる円形画像の数を指定する第２のシンタックス要素をさらに含む、請求項３１に記載のデバイス。
  38. 前記魚眼ビデオデータは、ビデオコーディングレイヤ（ＶＣＬ）中で符号化され、および前記シンタックス構造は、前記ＶＣＬの外部にある、請求項３１に記載のデバイス。
JP2019564866A 2017-05-25 2018-05-24 魚眼ビデオデータのための高レベルシグナリング Active JP7035088B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201762511189P 2017-05-25 2017-05-25
US62/511,189 2017-05-25
US15/987,231 2018-05-23
US15/987,231 US10992961B2 (en) 2017-05-25 2018-05-23 High-level signaling for fisheye video data
PCT/US2018/034435 WO2018218047A1 (en) 2017-05-25 2018-05-24 High-level signalling for fisheye video data

Publications (3)

Publication Number Publication Date
JP2020522166A true JP2020522166A (ja) 2020-07-27
JP2020522166A5 JP2020522166A5 (ja) 2021-08-12
JP7035088B2 JP7035088B2 (ja) 2022-03-14

Family

ID=62713080

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019564866A Active JP7035088B2 (ja) 2017-05-25 2018-05-24 魚眼ビデオデータのための高レベルシグナリング

Country Status (16)

Country Link
US (1) US10992961B2 (ja)
EP (1) EP3632124B1 (ja)
JP (1) JP7035088B2 (ja)
KR (1) KR102339197B1 (ja)
CN (1) CN110622516B (ja)
AU (1) AU2018271975A1 (ja)
BR (1) BR112019024653A2 (ja)
CA (1) CA3059215A1 (ja)
CL (2) CL2019003415A1 (ja)
CO (1) CO2019013048A2 (ja)
MX (1) MX2019014043A (ja)
MY (1) MY194493A (ja)
PH (1) PH12019502369A1 (ja)
RU (1) RU2767300C2 (ja)
TW (1) TW201907717A (ja)
WO (1) WO2018218047A1 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4254035A3 (en) * 2016-10-12 2023-12-06 Samsung Electronics Co., Ltd. Method, apparatus, and recording medium for processing image
US11481961B2 (en) 2018-10-02 2022-10-25 Sony Corporation Information processing apparatus and information processing method
WO2020190270A1 (en) * 2019-03-15 2020-09-24 STX Financing, LLC Systems and methods for compressing and decompressing a sequence of images
US11153481B2 (en) * 2019-03-15 2021-10-19 STX Financing, LLC Capturing and transforming wide-angle video information
WO2020250387A1 (ja) * 2019-06-13 2020-12-17 日本電気株式会社 画像処理装置、画像処理方法及びプログラム
US10997693B2 (en) * 2019-07-03 2021-05-04 Gopro, Inc. Apparatus and methods for non-uniform processing of image data
US20230300338A1 (en) * 2022-03-16 2023-09-21 Apple Inc. Resolution-based video encoding

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013534747A (ja) * 2010-06-09 2013-09-05 サムスン エレクトロニクス カンパニー リミテッド フラグメント基盤のマルチメディアストリーミングサービス提供方法とその装置、並びにフラグメント基盤のマルチメディアストリーミングサービス受信方法とその装置

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101530713B1 (ko) * 2008-02-05 2015-06-23 삼성전자주식회사 영상 파일을 생성하고 표시하기 위한 장치 및 방법
US9124874B2 (en) * 2009-06-05 2015-09-01 Qualcomm Incorporated Encoding of three-dimensional conversion information with two-dimensional video sequence
US20150358539A1 (en) 2014-06-06 2015-12-10 Jacob Catt Mobile Virtual Reality Camera, Method, And System
US10979691B2 (en) * 2016-05-20 2021-04-13 Qualcomm Incorporated Circular fisheye video in virtual reality
CN106507178B (zh) * 2016-12-09 2019-11-15 北京小米移动软件有限公司 视频播放方法及装置
CN110574381B (zh) * 2017-04-25 2023-06-20 夏普株式会社 解析全向视频质量信息语法元素的方法及设备
JP6721631B2 (ja) * 2017-07-07 2020-07-15 ノキア テクノロジーズ オーユー ビデオの符号化・復号の方法、装置、およびコンピュータプログラムプロダクト

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013534747A (ja) * 2010-06-09 2013-09-05 サムスン エレクトロニクス カンパニー リミテッド フラグメント基盤のマルチメディアストリーミングサービス提供方法とその装置、並びにフラグメント基盤のマルチメディアストリーミングサービス受信方法とその装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
OH, SEJIN AND OH, HYUNMOOK: "SEI message for signaling of 360-degree video information", JOINT COLLABORATIVE TEAM ON VIDEO CODING (JCT-VC) OF ITU-T SG 16 WP 3 AND ISO/IEC JTC 1/SC 29/WG 11, vol. JCTVC-Z0026 (version 3), JPN6021042744, 18 January 2017 (2017-01-18), ISSN: 0004631684 *

Also Published As

Publication number Publication date
CL2021001937A1 (es) 2022-02-25
WO2018218047A1 (en) 2018-11-29
RU2767300C2 (ru) 2022-03-17
US10992961B2 (en) 2021-04-27
KR20200012857A (ko) 2020-02-05
TW201907717A (zh) 2019-02-16
JP7035088B2 (ja) 2022-03-14
AU2018271975A1 (en) 2019-10-31
MY194493A (en) 2022-11-30
MX2019014043A (es) 2020-02-05
CN110622516A (zh) 2019-12-27
KR102339197B1 (ko) 2021-12-13
CA3059215A1 (en) 2018-11-29
CO2019013048A2 (es) 2020-01-17
RU2019137457A3 (ja) 2021-08-20
PH12019502369A1 (en) 2020-07-20
EP3632124C0 (en) 2023-08-02
CL2019003415A1 (es) 2020-05-15
CN110622516B (zh) 2022-01-11
EP3632124A1 (en) 2020-04-08
RU2019137457A (ru) 2021-06-25
EP3632124B1 (en) 2023-08-02
US20180343472A1 (en) 2018-11-29
BR112019024653A2 (pt) 2020-06-09

Similar Documents

Publication Publication Date Title
US10587883B2 (en) Region-wise packing, content coverage, and signaling frame packing for media content
US10575018B2 (en) Enhanced high-level signaling for fisheye virtual reality video in dash
JP7035088B2 (ja) 魚眼ビデオデータのための高レベルシグナリング
US10659760B2 (en) Enhanced high-level signaling for fisheye virtual reality video
US10567734B2 (en) Processing omnidirectional media with dynamic region-wise packing
CN110832878B (zh) 增强区域取向包封及视区独立高效视频译码媒体配置文件

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210427

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210427

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210629

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20210629

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20211028

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20211102

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211215

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220302

R150 Certificate of patent or registration of utility model

Ref document number: 7035088

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150