JP2020506614A - ３６０ビデオストリーミングのための予測ビットレート選択 - Google Patents

Abstract

【解決手段】３６０度ビデオのためのストリームの予測プリフェッチが、説明される。ユーザビュー方位メタデータが、複数のビューポートについてのデータを含む３６０度ビデオストリームのために取得される。ビューポートのうちの特定のビューポートについての１つ以上の高解像度フレームに対応するデータが、ユーザビュー方位メタデータに基づいてプリフェッチされ、それらのフレームが表示される。高解像度フレームは、残りのビューポートについてよりも高い解像度によって特徴付けられる。【選択図】図１

Description

［優先権の主張］
本出願は、２０１７年４月６日に出願された米国特許出願番号第１５／４８１，３２４号の優先権の利益を主張し、その内容全体が参照によって本明細書に組み込まれる。

本開示の態様は、ビデオストリーミングに関する。特に、本開示は、３６０度ビデオのストリーミングに関する。

３６０度ビデオは、単一点の周りに配列された複数のカメラからビデオストリームを撮ること、及びビデオストリームを繋ぎ合わせて単一の連続ビデオ画像を作成することによって作成される。最新の符号化器は、複数のフレームのビデオストリームに連続ビデオ画像を挟み込む。ネットワークを介して３６０度ビデオを見るために、サーバは、これらの複数のフレームのストリームをクライアントに送信する。クライアントは、ディスプレイ上に提示されている連続画像に、ストリームを復号し、再構築する。

システムは、フレームについての単一の要求を送信し、要求されたフレームをダウンロードし、次いで表示用にそれらを構築し得る。このアクションの組み合わせは、フェッチアクションと呼ばれることがある。概して、中断のないビデオを確実に流すために、クライアントはまた、ビデオをプリフェッチしなければならない。それは、先にダウンロードされたフレームが表示される前に、システムがフレームをダウンロードし、それらを処理しなければならないことを意味する。このようにして、システムは、表示されている処理済みフレームとダウンロード及び処理される必要がある後続フレームとの間で、処理済みフレームのバッファを構築する。

バッファリングは、特に高解像度ビデオを処理し記憶する際に、システムリソース上で非常にコストがかかり得る。帯域幅を節約し、必要なバッファリングの量を減少させるために、クライアントは、ビューポートとも呼ばれる、クライアントの視野範囲内の高解像度ビデオストリームフレームのみを要求してもよい。この場合、クライアントは、クライアントの現在のビュー以外の全てについて低解像度ビデオストリームを受信する。このシステムの問題は、高品質ストリームが要求され、配信され、バッファされ得るよりも早く、クライアントはしばしば視野を移動可能である、ということである。したがって、当技術分野において、クライアントが、３６０度ビデオストリーム内で視野がどこに向けられ得るかを予測し、視野が移動される前に対応する高解像度ビデオストリームをフェッチすることを可能にするシステムに対する必要性が存在する。

先行技術に関連する欠点は、３６０度ビデオストリームについてのユーザビュー方位メタデータを取得することと、ユーザビュー方位メタデータによって判断されるフレームをプリフェッチすることと、ユーザビュー方位メタデータによる３６０度ビデオストリームのより高解像度のフレームを表示することと、を含む３６０度ビデオをプリフェッチする方法に関する本開示の態様によって、克服される。

本開示の教示は、添付図面と併せて以下の詳細な説明を考察することによって容易に理解され得る。

本開示の態様による、３６０度ビデオにおける仮想カメラ視野の図である。 本開示の態様による、正距円筒図法における予測ビデオフェッチの図である。 本開示の態様による、立方体マッピング図法における予測ビデオフェッチの図である。 本開示の態様による、３６０度ビデオを表示するシステムのブロック図である。 本発明の態様による、フレームをいつ変更するかを決定するためのマルコフチェーンの簡略型円形図である。 本開示の態様による、３６０度ビデオを表示する方法を示すフロー図である。

以下の詳細な説明は、例示のための多数の具体的詳細を含むが、当業者であれば誰でも、以下の詳細に対する多数の変形及び変更が発明の範囲内にあると理解するであろう。したがって、以下に記載される発明の例示的実施形態は、特許請求された発明に対して一般性を失うことなく、かつ限定を与えることなく明記される。

［序論］
典型的には、ネットワークを介して３６０度ビデオをストリーミングすることは、全て１つの品質のビデオストリームのセットを受信することを伴う。より新しいストリーミング技術は、視聴者が着目している領域において高品質のストリームをロードすることのみによって、帯域幅利用を減少させることを可能にする。この技術は、視聴者が、多くの時間またはバッファリソースとして必要とすることなく、より高解像度のビデオストリームをロードすることを可能にするという、追加的な効果を有する。

開示される技術は、視聴者がより高品質のビデオストリームを見ることを可能にするが、ユーザが突然高品質ストリームから離れてビューポートを移動する場合に、不快感を与える解像度の低下を体験することがある。本開示の態様は、このような不快な体験を除去するために開発された。

他の事例では、３６０度ビデオの作者は、３６０度ビデオのあるシーンにおいて視聴者が見るべきものについて、何らかの芸術的構想を有する場合がある。先行技術の方法によれば、視聴者に対して表示されたシーン内のそのような詳細は、低解像度ビデオの表示に起因して、またはビューが別方向を見ている間に、失われることがある。したがって、本開示の態様は、知覚される３６０度ビデオストリームの品質を改善するため、ならびに作者が視聴者のためにビューポート及びビデオ品質を定義することを可能にするために開発された。

［作者主導プリフェッチ］
３６０度ビデオ内において、図１に見られ得るように、画像を見るためにカメラが撮り得る多くの方位が存在し得る。カメラ１０１は、ポイント１０８に固定され、シーン１００が、３６０度可視領域を作成するためにカメラ１０１の周囲を包んでいる。カメラは、シーン内の画像１０３を見るために、固定ポイント１０８を中心に回転してもよい。シーンは、ビューポート１０２と呼ばれる異なる領域に分解されてもよい。各ビューポート１０２は、クライアントによってロードされる、異なるビデオストリームであってもよい。図２に見られるように、ビデオの各セクションが、これらのビューポートに分割されてもよい。カメラ１０１は、任意の方向、例えば、上１０４、下１０６、左１０５、または右１０７に方位を変更して、１つのビューポート１０２から別のビューポートにシフトしてもよい。

図２は、現在の開示の態様による、正距円筒図法を示す。３６０度シーン２００は、一連の等しい大きさの長方形２０１〜２０８から構成される。各長方形は、クライアントデバイスがロードし、表示用に繋ぎ合わせる別々のビデオストリームであってもよい。各長方形は、カメラのビューを包含するのに十分な大きさであってもよく、その場合、それらはビューポート２０１である。代替的に、複数の長方形が、単一ビューポート（図示せず）を共に表してもよい。

ビデオ及び画像の作者は、典型的には、彼らがコンテンツの視聴者に見て欲しいものの何らかのアイデアを有している。３６０度ビデオの作成者も何ら変わりはない。上述のように、先行技術において表示される３６０度ビデオは、解像度が１つだけであった。より低い解像度では、ビデオ画像の重要な態様が視聴者に対して失われることがあった。

本開示の態様によれば、作者は、クライアントがロードするための高解像度フレームの位置２０２を定義し得る。作者は、また、ユーザが見そうな３６０度ビデオの部分に対応するストリームのための高解像度ビデオコンテンツを予測的にロードするためにクライアントが使用し得る、ビデオストリーム内のメタデータ２０９を定義してもよい。限定ではなく例として、メタデータ２０９は、重要性を表す大きさ、及び方向の両方を有するベクトルの形式であってもよい。ある実施態様では、時間が、メタデータ２０９と並んで符号化されてもよく、またはベクトルが、固定の時間ステップ間隔のストリーム内に置かれてもよい。定義済みは、ユーザビュー方位メタデータとも呼ばれる。

いくつかの実施態様において、メタデータは、クライアントによるビュー方位情報の明示的な送信なしで、バックエンドまたはサーバ側で生成されてもよい。限定ではなく例として、サーバは、クライアントがどのストリームを、いつ要求するかに基づいて確率フィールドを構築してもよく、次いで、どのストリームがどのビューポートに属するかマッピングする。これは、クライアントが、現在のクライアントビューポートのために最高品質のストリームを選択すると仮定している。

メタデータ２０９は、ユーザによるビデオストリーム内のビューポート２０１の動きについての可能性に関連し得る。代替的には、作者定義プリフェッチベクトルの形式におけるメタデータ２０９は、作者の芸術的構想に従って視聴者のために理想化された移動ベクトルであってもよい。クライアントデバイスは、ビューポートの実際の動き２１０とメタデータ２０９の両方を追跡してもよい。クライアントデバイスは、実際のビューポート２０１内のフレーム、及び作者定義プリフェッチベクトルに沿ったフレーム２０２、２０３をプリフェッチしてもよい。代替的には、クライアントは、視聴者が３６０度ストリーム内の異なる位置にビューポートを移動するように促すために、作者定義ベクトルに沿って高解像度フレーム２０２、２０３をフェッチするだけであってもよい。

作者定義プリフェッチメタデータは、ベクトルである必要はない。作者は、表示のある時間の間、高解像度であることを彼らが所望するフレーム２０２を単に定義してもよい。したがって、クライアントは、作者によって定義されたある時間において、作者定義の高解像度フレームをフェッチしてもよい。

作者は、また、ズーム機能のために、フレームのある領域を高解像度として定義してもよい。作者は、フレームのあるサブセクションが高解像度として符号化されるように、フレームのサブセクションのための詳細情報のレベルを提供してもよい。この高解像度サブセクションの位置をクライアントに通知するメタデータは、クライアントがそのストリームをプリフェッチし得るように、クライアントに送信され得る。

メタデータ２０９は、また、ビデオの表示中にビューポート２０１を制御するために使用されてもよい。作者は、ビューポート２０１を視聴者の入力なしでメタデータ２０９に沿って移動するように選択してもよい。このようにして、仮想カメラマン機能が実現され得る。作者は、３６０度ディスプレイにおいて芸術的構想をより良く表示し得る。

［演出定義プリフェッチ］
演出とも呼ばれる、ビデオストリームのフレームの効果の追加中に、クライアントが、演出効果に合致するように高解像度フレームをプリフェッチすることが望ましい場合がある。限定ではなく例として、クライアントが、大きな音の見かけ方向の高解像度フレームをプリフェッチすることが望ましい場合がある。代替的には、演出中に、クライアントが、多くの特殊効果または特殊なカメラの動きがある場所におけるフレームをプリフェッチすることが望ましい場合がある。

本開示の態様によれば、クライアントは、演出中に定義されたあるフレームをクライアントにプリフェッチさせるメタデータを受信してもよい。これらの定義済みフレームは、上述のような芸術的構想よりも、特殊効果及びサウンドキューに対応し得る。演出定義プリフェッチメタデータもまた、ユーザ方位メタデータと呼ばれ得る。

［予測プリフェッチ］
本開示の代替的な態様によれば、クライアントは、図２及び図３に見られるように、予測メタデータを使用して、潜在的な将来のビューポートにあると判断されるストリームをプリフェッチしてもよい。予測メタデータは、エンドユーザが、単一解像度ストリームを採用するシステムにおけるよりも高解像度のフレームを彼らの視野内で受信することを保証するために、演出中に生成されてもよい。

スタジオは、３６０度ビデオの視聴者から収集されたスクリーニングデータを使用して、視聴者が任意の時間にビデオを見ている可能性がある場所の確率モデルを生成してもよい。この確率モデルは、３６０度ビデオにおける現在のビュー方位、ビデオ内の時間コード、ビデオの過去ビューなどの変数に基づいて、ユーザが現在のフレーム２０１から別のフレーム２０２へと移動する可能性、または現在のフレーム２０１に留まる可能性を定義し得る。フレームを変更する確率は、現在表示されている３６０度ビデオ内の各フレームに結び付けられた確率によって表されてもよい。これは、図２に見られる各フレーム２０１〜２０８内のパーセンテージによって表される。予測プリフェッチデータは、ユーザ方位メタデータと呼ばれてもよい。

代替的には、予測プリフェッチメタデータは、否定的な、または逆／反対のデータであってもよい。言い換えると、ユーザが見そうな場所の確率の代わりに、プリフェッチメタデータは、視聴者が見そうにない場所の１つ以上の確率を代わりに表してもよい。

ビデオフレームのプリフェッチは、高解像度及び低解像度のストリームに限定されない。図２に見られるように、システムは、ある閾値レベルの確率を有するフレーム２０５、２０６についての中間解像度をプリフェッチするように選択してもよい。同様に、ビューポートである低い確率を有するフレーム２０４、２０７、２０８は、表示低解像度画像とともにプリフェッチされるだけである。追加的な態様として、低いビューポート確率フレーム２０４、２０７、２０８は、限定ではなく例として、より高い確率フレームより少ない更新を受信してもよい。低い確率フレームは、例えば、高い確率ストリームの２回の更新毎に１回だけ、更新してもよい。さらに概して、最適な／高い確率ストリームの任意の要因が、それらがビュー内か否かに依存して低確率ストリームを更新するために使用されてもよい。いくつかの実施態様において、依然としてビュー内にある低確率ストリームが、繋ぎ合わされたフレーム間の顕著な同期ずれを回避するために、完全な高確率更新速度で更新されてもよい。

この確率メタデータを使用してストリームをプリフェッチするかどうかを判断するために、クライアントは、定義済み閾値確率レベルを有してもよい。視聴者があるフレーム内にビューポートを移動する確率が閾値確率レベルを超えると、確率メタデータが判断するとき、クライアントは、そのフレームをプリフェッチする。代替的な実施形態では、クライアントは、確率メタデータの忠実性に基づいて、フレームをプリフェッチしてもよい。

［予測忠実性チェック］
図３は、本開示の態様による、立方体マッピング図法を示す。各フレーム内にパーセンテージとして表される予測データは、ビューポート３０１の実際の動き３０５に合致しない。この例では、作者予測のプリフェッチベクトル３０３もまた、ビューポート３０１の実際の移動ベクトル３０５に合致しない。図３に提示される場合において、実際のビューポートは、結局３０２となる一方、システムは、予測データに基づくフレーム３０１、または作者定義プリフェッチベクトルに基づくフレーム３０４のいずれかをプリフェッチする。よって、図３の場合、システムは、視聴者方位メタデータに従い続けるか、あるいはデフォルトで単一品質レベルとなるかを判断してもよい。

クライアントは、確率的及び作者定義のメタデータの忠実性の、連続的または断続的チェックを実行してもよい。クライアントは、確率メタデータ及び実際のビューポート３０１の方位に基づいて、高解像度フレームを最初にプリフェッチしてもよい。クライアントは、次いで、ビューポートの方位及びメタデータに従って、高解像度フレームを表示してもよい。クライアントは、視聴者が、確率メタデータまたは作者定義メタデータに従って高解像度フレームにビューポートを移動したかどうかを判断するためにチェックしてもよい。

ビューポートが、確率メタデータまたは作者定義プリフェッチベクトルに従ってプリフェッチされたフレーム内にないと判断すると、クライアントは、プリフェッチのためにメタデータを使用するのを止め、ビューポートの現在の視野内の高解像度フレームをフェッチするだけであってもよい。代替的な実施形態では、クライアントは、相関関係についてのメタデータを用いてビューポートの動きを連続的にチェックしてもよい。クライアントは、確率メタデータに従わないビューポートの動きについての許容誤差レベルを有してもよい。この許容誤差レベルは、限定ではなく例として、見られた予測フレームに対する見落とされた予測フレームの比率であってもよい。その事例において、比率が１まで増えるにつれて、クライアントは、実際のビューポート内のフレームのみをフェッチすることへとシフトしてもよい。さらに概して、許容誤差レベルは、値のセット内の変化の量を統計的に数量化することによって判断されてもよい。任意の適当な可変性の尺度、例えば、標準偏差が、固定またはスライディングウィンドウのユーザのセット及びメタデータに対して適用されてもよい。

［演出後プリフェッチ生成］
本開示の別の態様は、最終視聴者データに基づく予測メタデータの生成である。クライアントデバイスは、ビューポートの方位に関して視聴者からデータを収集してもよい。クライアントデバイスは、この視聴者データを使用して、予測データを生成し、予測データに従ってビデオストリームをプリフェッチしてもよい。クライアントデバイスは、また、ビデオストリームのための確率メタデータを生成し、または精密化するために、他のクライアントまたはサーバと予測データを共有してもよい。

クライアントデバイスは、ビューポート方位データを使用して予測データを生成してもよい。限定ではなく例として、クライアントデバイスは、ビューポートの移動ベクトル３０５を使用して、ベクトル上にあり、移動速度を考慮に入れる高解像度ビデオストリームを予測的にフェッチしてもよい。ユーザ生成された予測プリフェッチデータは、ユーザ方位メタデータと呼ばれてもよい。

クライアントは、将来の視聴のためのより良い確率メタデータを生成するために、ビューポート方位データをデータ収集センタに送信してもよい。データ収集センタは、作者定義プリフェッチデータに加えてビューポート方位データを使用して、ビデオストリームのためのメタデータを生成してもよい。クライアントが過去のユーザ定義視聴ベクトルに厳密に従っていない限り、作者定義ストリームのプリフェッチが優先されるように、生成されたメタデータは、作者定義プリフェッチデータに重み付けしてもよい。

［サーバ側プリフェッチ］
本開示の代替的な実施形態において、サーバは、メタデータを使用して、クライアントデバイスに送信するために高解像度ストリームを選択する。本実施形態の態様によれば、サーバによって使用されるメタデータは、作者定義、視聴者から生成された確率データ、または他の予測データであってもよい。サーバは、３６０度ビデオストリームについての要求をクライアントデバイスから受信してもよい。サーバは、要求されたストリームについての視聴者方位メタデータについてチェックしてもよい。このようなメタデータを見つけると、サーバは、メタデータに従って高解像度ストリームをクライアントに送信してもよい。サーバは、また、実際の視聴者方位データを受信し、実際のビューポートのビューにおける高解像度ストリームを送信してもよい。さらに、サーバがメタデータに基づいて高解像度ビデオストリームを送信し続けるべきかどうかを判断するために、サーバは、上述のような予測忠実性チェックを実行してもよい。

［実施態様］
図４は、本開示の態様によるシステムを示す。システムは、ディスプレイ４０１及びユーザ入力デバイス４０２に連結されたコンピューティングデバイス４００を含んでもよい。ディスプレイデバイス４０１は、陰極線管（ＣＲＴ）、フラットパネルスクリーン、タッチスクリーン、またはテキスト、数字、グラフィカルシンボル、もしくは他の視覚的対象物を表示する他のデバイスの形式であってもよい。ユーザ入力デバイス４０２は、コントローラ、タッチスクリーン、またはユーザがユーザビュー方位と対話し、３６０度ビデオストリームを選択することを可能にする他のデバイスであってもよい。いくつかの実施態様において、ディスプレイ４０１は、没入型３６０度ビデオ体験のために３６０度ビデオの複数のビューポートを同時に表示するように構成される、３６０度ディスプレイであってもよい。他の実施態様において、ディスプレイ４０１は、従来の二次元ディスプレイであってもよい。このような実施態様では、ユーザは、コンピューティングデバイスとの対話によってビューポートを判断することが可能であってもよい。

コンピューティングデバイス４００は、例えば、シングルコア、デュアルコア、クアッドコア、マルチコア、プロセッサ−コプロセッサ、セルプロセッサなどの周知のアーキテクチャに従って構成され得る、１つ以上のプロセッサユニット４０３を含んでもよい。コンピューティングデバイスは、また、１つ以上のメモリユニット４０４（例えば、ランダムアクセスメモリ（ＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、読み出し専用メモリ（ＲＯＭ）など）を含んでもよい。

プロセッサユニット４０３は、１つ以上のプログラムを実行してもよく、その一部は、メモリ４０４に記憶されてもよく、プロセッサ４０３は、例えば、データバス４０５を介してメモリにアクセスすることによって、メモリに動作可能に連結されてもよい。プログラムは、そのビデオストリームについて受信されたメタデータ４１０に基づいて、ビデオストリームについてのフレームを要求するように構成されてもよい。プロセッサによる実行時に、プログラムが、システムに高解像度フレームを復号４０８させ、バッファ４０９に視聴者のビューポート内の可能性のあるフレームを記憶させてもよい。

コンピューティングデバイス４００は、また、入力／出力（Ｉ／Ｏ）回路４０７、電源（Ｐ／Ｓ）４１１、クロック（ＣＬＫ）４１２、及びキャッシュ４１３などの周知のサポート回路を含んでもよく、それらは、例えば、バス４０５を介してシステムの他のコンポーネントと通信し得る。コンピューティングデバイスは、ネットワークインタフェース４１４を含んでもよい。プロセッサユニット４０３及びネットワークインタフェース４１４は、ＰＡＮのための、例えばＢｌｕｅｔｏｏｔｈ（登録商標）などの適当なネットワークプロトコルを介して、ローカルエリアネットワーク（ＬＡＮ）またはパーソナルエリアネットワーク（ＰＡＮ）を実施するように構成されてもよい。コンピューティングデバイスは、任意で、ディスクドライブ、ＣＤ−ＲＯＭドライブ、テープドライブ、フラッシュメモリなどの大容量記憶デバイス４１５を含んでもよい。大容量記憶デバイスは、プログラム及び／またはデータを記憶してもよい。コンピューティングデバイスは、また、システム及びユーザ間の対話を容易にするためのユーザインタフェース４１６を含んでもよい。ユーザインタフェースは、キーボード、マウス、ライトペン、ゲーム制御パッド、タッチインタフェース、または他のデバイスを含んでもよい。いくつかの実施態様において、ユーザは、インタフェース４１６を使用して、例えば、マウスでスクロールすること、またはジョイスティックの操作によって、ビューポートを変更してもよい。いくつかの実施態様において、ディスプレイ４０１は、スマートフォン、タブレットコンピュータ、またはポータブルゲームデバイスにおけるような、手持ちディスプレイであってもよい。このような実施態様において、ユーザインタフェース４１６は、ディスプレイ４０１の一部である加速度計を含んでもよい。このような実施態様において、プロセッサ４０３は、例えば、適当なプログラミングによって、ディスプレイの方位の変化を検出し、この情報を使用してビューポートを判断するように構成され得る。したがって、ユーザは、ディスプレイを単に移動することによって、ビューポートを変更することができる。

いくつかの実施態様において、予測メタデータは、マルコフチェーンを実施するように構成されてもよい。図５は、現在の開示の態様による、マルコフチェーンのグラフィカル表示を示す。それぞれの円は、状態５０１〜５０６、例えば、３６０度ビデオ内のビューポート方位を表す。立方体マッピングされたビデオストリームを表す、このマルコフチェーンには６つの状態が存在する。それぞれの矢印は、ビューポートが、ビデオストリームのビューポートのうちの別のビューポートに変わる確率を表す。これらの転移確率は、監督者または製作者によって、手動で設定され、フォーカスグループデータから、または実際の視聴者データから判断され得る。各フレームは、ビデオストリーム内の各時点においてそれ自体のマルコフ確率を有し得る。本開示の１つの実施形態によれば、システムは、現在のビューポート方位から異なる方位への遷移についてのマルコフ確率を表すメタデータを受信するだけであってもよい。例えば、５０１における現在のビューポートを表示するクライアントが、現在のビューポート５０１から複数のビューポート５０２〜５０６のうちの異なるビューポートへと移動する確率、または現在のビューポート５０１に留まる確率を受信するだけである。このようにして、システムは、ストリームを受信する間に現在の状態からの遷移の確率のみを受信することによって、初期ロード時間及び帯域幅利用を減少させ得る。代替的には、システムは、ビデオストリームの開始において各時点におけるビデオストリームについてのマルコフ確率モデル全体を受信してもよい。この実施形態は、ストリームについての初期ロード時間を増加させるが、ストリーミング中に処理される必要がある情報全体を減少させる。別の実施形態では、システムは、３６０度ビデオのストリーミング中の各時点におけるマルコフ確率モデルを受信してもよい。この実施形態は、ストリーム処理を犠牲にして先行投資のロード時間を減少させるが、クライアントとサーバとの間の同期ずれの場合に、追加的なマルコフ確率データをさらに含む。

上述のような作者定義プリフェッチメタデータを、マルコフチェーンモデルを用いて実装するために、システムは、作者定義プリフェッチベクトルに沿った状態への移行確率に重みを付けてもよい。したがって、重みを加えた移動の確率が閾値を上回る場合に、クライアントは、その状態のプリフェッチを開始する。

本開示の態様によれば、クライアントは、ビデオストリームから独立して要求されたビデオストリームのための視聴者方位メタデータを受信してもよい。メタデータがビデオストリームから独立して受信される場合、それは、ストリームに時間同期しなければならない。現在の開示の代替的な態様において、メタデータは、限定ではなく例として、３６０度ビデオストリームのヘッダにおいて、ビデオストリーム自体の一部として受信されてもよい。

図６は、本開示の態様による、予測ビットレート選択についてのフロー図を示す。システムは、ネットワークからビデオストリームを要求６０１してもよい。ビデオストリームの要求時に、システムは、ネットワークから、または大容量記憶メモリ４１５にローカルに記憶された、またはコンパクトディスクなどの記憶媒体から、または当技術分野において既知の任意の適当な種類のデータ記憶から、ユーザビュー方位メタデータを取得６０２してもよい。上述のように、ユーザビュー方位メタデータは、ストリーミング中にも取得され得ることに留意すべきである。視聴者方向メタデータは、上述のようにユーザがまだ入っていない潜在的なビューポートを含む、表示前にフェッチするフレームをシステムに通知してもよい。したがって、システムは、上述のように、より高い解像度における初期開始ビューポートフレーム、及びより低い解像度における３６０度ビデオストリーム内の残りのフレームだけでなく、潜在的なビューポートまたは所望のビューポートであるフレームをプリフェッチ６０３する。システムは、次いで、例えば上述のようなディスプレイデバイス４０１を通して、プリフェッチされたフレームを表示６０４する。プリフェッチされたフレームを表示６０４する間、システムは、中断のない３６０度ビデオストリーミング体験をユーザの視野内の高解像度フレームを用いて作成するために、フレームのプリフェッチ６０３を継続６０５してもよい。任意で、システムは、予測忠実性チェック６０７を使用６０６して、ビュー方位メタデータに従ってフレームをプリフェッチし続けるか、あるいは現在のビューポート内のフレームだけがより高解像度でプリフェッチされる、現在のロード状態に入るかを判断６０８してもよい。現在のロード状態において、システムは、上述のように予測が正確になるまで、予測忠実性のチェックを継続６０９してもよい。その時点で、システムは、ユーザビュー方位メタデータに基づいてプリフェッチ６０３を再開６０８することができる。

上記は、本発明の好ましい実施形態の完全な説明であるが、多様な代替物、修正物、及び均等物を使用することが可能である。したがって、本発明の範囲は、上記説明を参照することなく判断されるべきであるが、その代わりに、添付の特許請求の範囲を、その均等物の全範囲とともに参照して判断されるべきである。いかなる特徴も、好ましいか否かに関わらず、いかなる他の特徴とも、好ましいか否かに関わらず組み合わされてもよい。続く特許請求の範囲において、不定冠詞「Ａ」または「Ａｎ」は、そうでないと明示的に述べられている場合を除いて、冠詞に続く項目のうちの１つ以上の量をいう。そのような限定が「ための手段（ｍｅａｎｓ ｆｏｒ）」という句を使用して所与の請求項において明示的に列挙されない限り、添付の特許請求の範囲は、ミーンズプラスファンクション限定を含むものとして解釈されるべきでない。指定された機能を実行する「ための手段（ｍｅａｎｓ ｆｏｒ）」を明示的に述べない、請求項の中の任意の要素は、米国特許法第１１２条第６項において指定される「手段」または「ステップ」として解釈されるべきでない。

Claims (20)

1. ａ）複数のビューポートについてのデータを含む、３６０度ビデオストリームのためのユーザビュー方位メタデータを取得することと、
   ｂ）前記ユーザビュー方位メタデータによって判断される前記複数のビューポートのうちの特定のビューポートについての１つ以上の高解像度フレームに対応するデータをプリフェッチすることと、
   ｃ）前記１つ以上の高解像度フレームを表示することであって、前記１つ以上の高解像度フレームが、前記複数のビューポートのうちの残りのビューポートについてよりも高い解像度によって特徴付けられる、前記表示することと、
   を含む方法。
2. 前記ユーザビュー方位メタデータが、作者定義プリフェッチベクトルである、請求項１に記載の方法。
3. 前記ユーザビュー方位メタデータが、前記３６０度ビデオストリームのシーンにおける演出効果に合致するように作成されるプリフェッチベクトルである、請求項１に記載の方法。
4. 前記ビュー方位メタデータが、ビューポートフレーム変更の予測確率である、請求項１に記載の方法。
5. 前記予測確率が、フォーカスグループによって生成される、請求項４に記載の方法。
6. 前記予測確率が、ユーザ生成のフレーム位置データを用いて生成される、請求項４に記載の方法。
7. 前記予測確率がまた、作者定義プリフェッチベクトルを含む、請求項４に記載の方法。
8. 前記作者定義プリフェッチベクトルが、ビューポートフレーム変更の前記確率に適用される重みである、請求項７に記載の方法。
9. フレームを前記プリフェッチすることが、前記ユーザビュー方位メタデータに第１の閾値を適用して、前記複数のビューポートのうちの前記特定のビューポートを判定することを含む、請求項４に記載の方法。
10. ビューポートフレーム変更の前記予測確率が、マルコフモデルについての確率である、請求項４に記載の方法。
11. 前記ユーザビュー方位メタデータが、移動ベクトルである、請求項１に記載の方法。
12. ｂ）が、前記予測確率が第２の閾値を超えるときに、中間解像度フレームをプリフェッチすることを含む、請求項９に記載の方法。
13. 前記ユーザビュー方位メタデータが、ユーザが見そうな場所の確率を表す、請求項１に記載の方法。
14. 前記ユーザビュー方位メタデータが、ユーザが見そうにない場所の確率を表す、請求項１に記載の方法。
15. 前記ユーザビュー方位メタデータを実際のユーザビュー方位と対照してチェックすることと、
    前記ユーザビュー方位メタデータが表示中の前記実際のユーザビュー方位と一致しないときに、プリフェッチを無効にすることと、
    をさらに含む、請求項１に記載の方法。
16. 前記ユーザビュー方位メタデータが表示中の前記実際のユーザビュー方位と一致しないときに、プリフェッチを無効にすることが、見落としフレーム閾値を適用して、プリフェッチを無効にするかどうかを判断することを含む、請求項１５に記載の方法。
17. 前記ユーザビュー方位メタデータによって判断される１つ以上の高解像度フレームに対応するデータをプリフェッチすることが、残りの前記フレームよりも高い解像度のセクションを有するフレームをプリフェッチすることを含む、請求項１に記載の方法。
18. ａ）複数のビューポートについてのデータを含む、３６０度ビデオストリームのためのユーザビュー方位メタデータを取得することと、
    ｂ）前記ユーザビュー方位メタデータによって判断される前記複数のビューポートのうちの特定のビューポートについての１つ以上の高解像度フレームに対応するデータをプリフェッチすることと、
    ｃ）前記１つ以上の高解像度フレームを表示することであって、前記１つ以上の高解像度フレームが、前記複数のビューポートのうちの残りのビューポートについてよりも高い解像度によって特徴付けられる、前記表示することと、
    の方法をコンピュータに実行させるプログラム命令を含む、非一時的コンピュータ可読媒体。
19. プロセッサと、
    前記プロセッサに連結されたディスプレイと、
    具現化されるプロセッサ実行可能命令を有する前記プロセッサに連結されたメモリであって、前記命令が、前記プロセッサによる実行時に方法を実施するように構成される、前記メモリと、
    を含むシステムであって、
    前記方法が、
    ａ）複数のビューポートについてのデータを含む、３６０度ビデオストリームのためのユーザビュー方位メタデータを取得することと、
    ｂ）前記ユーザビュー方位メタデータによって判断される前記複数のビューポートのうちの特定のビューポートについての１つ以上の高解像度フレームに対応するデータをプリフェッチすることと、
    ｃ）前記ディスプレイを用いて前記１つ以上の高解像度フレームを表示することであって、前記１つ以上の高解像度フレームが、前記複数のビューポートのうちの残りのビューポートについてよりも高い解像度によって特徴付けられる、前記表示することと、
    を含む、システム。
20. 前記ディスプレイが、前記複数のビューポートを同時に表示するように構成される３６０度ディスプレイである、請求項１９に記載のシステム。