本発明の実施形態についての本明細書の説明において、本発明の実施形態の完全な理解を提供するために、構成要素および/または方法の例など、多数の特定の詳細が提供される。しかしながら、本発明の実施形態は、特定の詳細のうちの1つまたは複数なしに、または他の装置、システム、アセンブリ、方法、構成要素、材料、部品などを用いて実施され得ることが、当業者には理解されよう。他の例では、本発明の実施形態の態様を曖昧にすることを回避するために、よく知られている構造、材料、または動作は、特に図示されておらず、また詳細に説明されていない。したがって、本開示の実施形態が、そのような特定の構成要素なしで実施され得ることが、当業者には理解されよう。本明細書に記載の発明を実施するための形態を用いること、また添付図面を参照することにより、当業者であれば、過度の実験なしに1つまたは複数の実施形態を作成および使用できることをさらに認識されたい。
さらに、「結合された」および「接続された」などの用語は、それらの派生語と共に、以下の説明、特許請求の範囲、またはその両方で使用され得る。これらの用語は、必ずしも相互の同義語として意図されているわけではないことを理解すべきである。「結合された」は、互いに直接物理的または電気的に接触していてもいなくてもよい2つ以上の要素が互いに協働または相互作用することを示すために使用され得る。「接続された」は、互いに結合された2つ以上の要素間の通信すなわち通信関係の確立を示すために使用され得る。さらに、本明細書に記載の1つまたは複数の例示的な実施形態において、一般的に言えば、要素が機能を実行するようにプログラムされ得るか、あるいはその機能を実行するように構造的に配置され得る場合、要素、構成要素、またはモジュールは、その機能を実行するように設定され得る。
本明細書で使用される場合、ネットワーク要素、ノード、またはサブシステムは、ネットワーク上の他の機器(たとえば、他のネットワーク要素、エンドステーションなど)を通信可能に相互接続するハードウェアおよびソフトウェアを含む、1つまたは複数のサービスネットワーク機器から構成され得、ストリームベースまたはファイルベースのメカニズムを使用してメディアコンテンツ資産が配布および配信され得るメディア配布ネットワークにおいてコンテンツを受信/消費するように動作する複数の加入者および関連するユーザ機器(UE)ノードに対する1つまたは複数のアプリケーションまたはサービスを、仮想化環境/非仮想化環境のいずれかでホストするように適合される。したがって、いくつかのネットワーク要素は、ワイヤレス無線ネットワーク環境に配置され得るが、他のネットワーク要素は、パブリックの、プライベートの、または複合のコンテンツ配信ネットワーク(CDN:content delivery network)を含み得る好適なCDNインフラストラクチャを含むかまたはそれらに関与する、パブリックパケット交換ネットワークインフラストラクチャに配置され得る。さらに、本明細書に記載の1つまたは複数の実施形態を含む好適なネットワーク要素には、地上および/または衛星ブロードバンド配信インフラストラクチャ、たとえば、デジタル加入者線(DSL:Digital Subscriber Line)ネットワークアーキテクチャ、データオーバーケーブルサービスインターフェース仕様(DOCSIS:Data Over Cable Service Interface Specification)準拠のケーブルモデム終端システム(CMTS:Cable Modem Termination System)アーキテクチャ、スイッチドデジタルビデオ(SDV:switched digital video)ネットワークアーキテクチャ、光・同軸ハイブリッド(HFC:Hybrid Fiber-Coaxial)ネットワークアーキテクチャ、好適な衛星アクセスネットワークアーキテクチャ、または、セルラーおよび/もしくはWiFi接続を介したブロードバンド無線アクセスネットワークアーキテクチャが含まれ得る。したがって、いくつかのネットワーク要素は、複数のアプリケーションサービス(たとえば、変化する品質または精細度で360°没入型ビデオ資産(360度ビデオ資産または単に360ビデオ資産とも呼ばれる)を含むデータおよびマルチメディアアプリケーション)に対するサポートを提供することに加えて、複数のネットワークベースの機能(たとえば、360°没入型A/Vメディア準備配信ポリシー管理、セッション制御、QoSポリシー施行、帯域幅スケジューリング管理、コンテンツプロバイダ優先ポリシー管理、ストリーミングポリシー管理など)に対するサポートを提供する、「複数サービスネットワーク要素」を含み得る。加入者エンドステーションまたはクライアントデバイスの例には、特定の実施形態においては何らかのタイプのレート適応を含み得るストリーミングおよび/またはファイルベースのダウンロード技術を使用してメディアコンテンツ資産を消費または配信することができる、テザーまたはアンテザーの様々なデバイスが含まれ得る。したがって、例示的なクライアントデバイスまたはUEデバイスは、特に、HTTP、HTTPS、RTPなどを使用して、たとえばブロードバンドアクセスネットワークを介して1つまたは複数のコンテンツプロバイダから、仮想現実(VR)メディア、拡張現実(AR)メディア、複合現実(MR:Mixed Reality)メディアを含み得る、360ビデオコンテンツ、ライブメディア、および/または静的/オンデマンドメディアを、受信、記録、記憶、および/または復号/レンダリングするための1つまたは複数のクライアントアプリケーションを実行するように設定された任意のデバイスを含み得る。したがって、このようなクライアントデバイスには、本明細書に記載の1つまたは複数の実施形態に従って帯域幅および体感品質(QoE:Quality of Experience)方式が提供され得る好適なメディア配布ネットワークを介して提供される360度コンテンツ/サービスにアクセスする、またはそれらを消費することができる、次世代IPベースのSTB、ネットワーク化されたTV、パーソナル/デジタルビデオレコーダ(PVR:personal video recorder/DVR:digital video recorder)、ネットワーク化されたメディアプロジェクタ、ポータブルラップトップコンピュータ、ネットブック、パームトップ、タブレット、スマートフォン、マルチメディア/ビデオ電話、モバイル/無線ユーザ機器、ポータブルメディアプレーヤ、3D表示デバイスと連携して動作するポータブルゲームシステムまたはコンソール(Wii(登録商標)、Play Station 3(登録商標)など)などが含まれ得る。
本特許開示の1つまたは複数の実施形態は、ソフトウェア、ファームウェア、および/またはハードウェアの異なる組合せを使用して実装され得る。したがって、図(たとえば、流れ図)に示される技法のうちの1つまたは複数は、1つまたは複数の電子デバイスまたはノード(たとえば、加入者クライアントデバイスまたはエンドステーション、ネットワーク要素など)上で記憶および実行されるコードならびにデータを使用して実装され得る。このような電子デバイスは、非一時的なコンピュータ可読記憶媒体(たとえば、磁気ディスク、光ディスク、ランダムアクセスメモリ、読み取り専用メモリ、フラッシュメモリデバイス、相変化メモリなど)、一時的なコンピュータ可読伝送媒体(たとえば、搬送波、赤外線信号、デジタル信号などの、電気的、光学的、音響的、または他の形式の伝搬信号)などのコンピュータ可読媒体を使用して、コードおよびデータを(内部的に、かつ/またはネットワークを介して他の電子デバイスを用いて)記憶および通信し得る。さらに、このようなネットワーク要素は、典型的には、1つまたは複数の記憶デバイス(たとえば、非一時的な機械可読記憶媒体)、ならびに、記憶データベース、ユーザ入力/出力デバイス(たとえば、キーボード、タッチスクリーン、ポインティングデバイス、および/またはディスプレイ)、およびシグナリングおよび/またはベアラメディア送信を実現するためのネットワーク接続などの1つまたは複数の他の構成要素に結合された1つまたは複数のプロセッサのセットを含み得る。プロセッサのセットと他の構成要素との結合は、典型的には、任意の知られているアーキテクチャ(たとえば、対称型/共有型マルチプロセッシング)、またはこれまでに知られていないアーキテクチャに配置された1つまたは複数のバスおよびブリッジ(バスコントローラとも呼ばれる)を介するものであり得る。したがって、所与の電子デバイスまたはネットワーク要素の記憶デバイスまたは構成要素は、本開示の1つまたは複数の技法を実装する目的で、その要素、ノード、または電子デバイスの1つまたは複数のプロセッサ上で実行するためのコードおよび/またはデータを記憶するように設定され得る。
ここで、図面、より具体的には図1を参照すると、1つまたは複数の鑑賞デバイスによる消費のために様々な設定上で配布される没入型ビデオを提供するための本発明の1つまたは複数の実施形態が実施され得る、一般化された例示的なネットワーク環境100が示されている。例示的なビデオソース/キャプチャシステム102は、無数のクライアントデバイス環境における360°鑑賞用にレンダリング可能なメディアを記録、生成、読込み、復号、提供、あるいは取得するように設定された任意の構成を例示しており、この無数のクライアントデバイス環境には、本特許出願の他の箇所に記載されているように、様々なアクセス/接続技術で動作する、テザーデバイスまたはアンテザーデバイス、スタンドアロンの機器、加入者施設機器、ゲーム機器、および/または3D表示デバイスとペアで組み合わされて動作する機器などが含まれ得る。例示として、コンピュータ/ディスプレイ144は、ヘッドマウントディスプレイ(HMD)またはヘッドセット142に関連付けられ得、ヘッドマウントディスプレイ(HMD)またはヘッドセット142もまた、集合的にデバイス140として示されるタブレット、スマートフォン、ファブレット、ゲーム機などのポータブルデバイスなどに関連付けられ得、これらは概して、クライアントデバイス138として示されている。コンピュータ/ディスプレイ144は、以下でさらに詳細に説明するように、本発明の教示に従って符号化および帯域幅最適化され得る様々なタイプの360°ビデオコンテンツを復号およびレンダリングするように設定され得る。一実施形態では、例示的な360°没入型ビデオソース/キャプチャシステム102は、全方向カメラもしくはパノラマカメラなどを含む1つまたは複数の高精細カメラ(たとえば、4K、8Kなど)、またはいくつかの方法でソースビデオストリームを提供するように設定され得るビデオストレージを含み得る。ビデオ前処理に関する設定および統合レベルに応じて、例示的な360°没入型ビデオソース/キャプチャ102からの出力ストリームは、1つまたは複数のインターフェース、すなわち高精細マルチメディアインターフェース(HDMI:High Definition Multimedia Interface)、シリアルデジタルインターフェース(SDI:Serial Digital Interface)、高精細SDI(HD-SDI)、または他のフォーマットと互換性のあるストリームとして提供され得、これらの出力ストリームは、投影マッピングの有無に関わらず、またソースビデオ符号化の有無に関わらず、ステッチされていないストリームまたはステッチされたストリームを含み得る。たとえば、投影マッピングのないステッチされていないソースストリーム104Aは、重なり合う角度をカバーするストリームを組み合わせてステッチされたストリーム108を作るビデオステッチャ106に提供され得る。別の実施形態では、ビデオソースストリームは、ステッチされたHDMI/SDI/HD-DSIストリーム104Bを含み得る。また、les修正を含み得る、キャプチャされたビデオの他の処理があり得る。ストリームが投影マッピングされていない場合、投影マッピングシステム110は、好適なマップ投影方式、たとえば、正距円筒図法投影、キューブマップ投影、等角キューブマップ投影、角錐投影、魚眼投影などを含むがこれらに限定されない球面画像投影を使用して、ステッチされたストリーム104B/108から、投影マッピングされたストリーム114を生成するように動作する。さらに別の実施形態では、ビデオストリームは、ソースビデオ符号化モジュール112に提供され得る、ステッチされ投影マッピングされたストリーム104Cを含み得、ソースビデオ符号化モジュール112は、実装に応じて、H.264またはアドバンスドビデオコーディング(MPEG-4 AVC:Advanced Video Coding)、高効率ビデオコーディング(HEVC)またはH.265(MPEG-Hパート2)、H.262(MPEG-2)、H.264(MPEG-4、パート2)、Alliance for Open Media(AOMedia)ビデオ1(AV1)、H.266、多用途ビデオコーディング(VVC)、フューチャビデオコーディング(FVC:Future Video Coding)などを含むがこれらに限定されない1つまたは複数の符号化方式または圧縮方式を実現するように動作し、これらの方式のいくつかは、タイル符号化を含む場合と含まない場合があり、かつ/または適応ビットレート(ABR:adaptive bitrate)トランスコーディングを含む場合と含まない場合がある。一構成では、投影マッピングシステム110からの投影マッピングされたストリームは、適切なビデオ圧縮を実現するためにエンコーダシステム112にも提供され得る。本発明の教示によれば、有利には、投影マッピングシステム110から受信した非圧縮ビデオストリーム(ビデオストリーム114)、エンコーダシステム112から受信した圧縮ビデオストリーム(ビデオストリーム116)、またはビデオソース/キャプチャシステム102からのビデオストリーム104Cを処理するために、メディア準備における前処理に関する設定および統合レベルに応じて、タイル化エンコーダ/トランスコーダ120が提供される。以下でさらに詳細に説明するように、いくつかの実施形態では、タイル化エンコーダ/トランスコーダ120の機能は、エンコーダシステム112および/または投影マッピングシステム110と統合され得、タイル化エンコーダ/トランスコーダ120は、360°没入型ビデオ資産またはプログラムに対応する入力ビデオストリームの複数のビットレート表現の符号化ストリームを生成するように動作し、一定のビデオ品質レベルを有する各ビットレート表現は、帯域幅が最適化された360°ビデオ配布を容易にするために、適切に変更されたタイル、フレーム、および/またはスライスデータを有するフレームを含むように符号化され得る。タイル化パッケージャ122は、ストレージ124のためにエンコーダ/トランスコーダ120からの符号化ストリームをパッケージ化し、符号化ストリームのタイルのグループ化、タイルのロケーション、メディアタイプおよび関連する特性を記述した関連するマニフェストファイル126を提供するように動作する。以下でさらに説明するように、タイル選択およびストリーム生成システム132は、制御入力に応答して適切なタイルを選択し、鑑賞デバイス138にサーブするアクセスネットワーク136に関連付けられた配信サーバ134によって配信され得る多重化ビデオ出力ストリームを生成するように動作する。例示的な実装形態では、エンドユーザへの多重化ビデオストリームの配信は、本特許出願の他の箇所に記載されているように、様々なネットワークインフラストラクチャを介して、いくつかのプロトコル、たとえば、HTTP/S、チャンク化されたHTTP/S、RTP/RTCPなどに基づいて実現され得る。
前述の一般化された例示的なネットワーク環境100が、たとえば、ソースストリームステッチング、投影マッピング、ソースメディア圧縮、タイル化/ABRの符号化/トランスコーディング、パッケージ化などを含む、メディアキャプチャおよび準備、ならびに1人または複数のオペレータ、コンテンツ配信ネットワーク(CDN)、エッジネットワークなどを含む、異なる階層レベルに配置された異なるネットワーク部分で行われる配布/アップロードおよびエッジノードプロセスの様々な態様を用いて階層ネットワークアーキテクチャで実装され得ることが、当業者には理解されよう。さらに、いくつかの実装形態では、前述の装置およびプロセスの少なくともいくつかは、クラウドベースであり得る。いくつかの構成では、CDNは、インターネットまたは他のパブリック/プライベート通信ネットワークに接続された複数のデータセンターに展開されたサーバの大規模分散システムとすることができる。CDNは、管理対象ネットワークまたは管理対象外ネットワークとすることができ、管理対象ネットワークまたは管理対象外ネットワークの連合体とすることもできる。
したがって、前述の例示的なネットワーク環境内で動作可能に関連付けられたメディアサーバ/ソースシステムの例示的な実施形態は、ライブソースおよび/または静的ファイルソース、たとえば、Hulu(登録商標)、Netflix(登録商標)、YouTube(登録商標)、またはAmazon(登録商標)Primeなどのオンラインコンテンツプロバイダ、ならびに、Disney、Warner、Sonyなどの、VODカタログもしくはコンテンツのプロバイダまたはスタジオからのメディアコンテンツを受け入れるように、たとえばグローバルヘッドエンドとして設定され得る。ライブソースからのメディアコンテンツは、広告メディアチャネルなどの任意の二次メディア挿入を含む、任意のタイプのイベント、たとえばスポーツ/エンターテインメント/ゲームイベント、コンサート、ライブTV番組、たとえば、全国放送局(たとえば、NBC、ABCなど)、ならびにCNN、ESPN、CNBCなどのTime Warnerチャネルのようなケーブル放送局チャネル、およびローカル放送局などのライブニュース放送ソースなどに関連してキャプチャされたライブプログラミングを含み得る。
限定されないが、図2に、本発明の一実施形態による没入型ビデオの最適化されたタイル符号化を容易にするための例示的なネットワークアーキテクチャ200(図1に示す環境の一部を形成し得る)が示されている。メディア入力ストリーム202は、図3に示されるように好適にステッチされ、投影マッピングされ、かつ/または符号化され得る360°ビデオ資産に対応するビデオストリームを例示しており、オペレータコンテンツ配信ネットワーク206に関連付けられたCDNオリジンサーバ204に配布、アップロード、または別の方法で提供され得る。大まかに言えば、メディア入力ストリーム202は、ライブTVコンテンツ、IPTVコンテンツ、タイムシフト(TS)TVコンテンツ、プレイスシフト(PS)TVコンテンツ、ゲームコンテンツ、ビデオオンデマンド(VOD)コンテンツ、VR/AR/MRコンテンツ、ネットワーク化されたデジタルビデオレコーダ(nDVR)コンテンツなど、または360°鑑賞体感のために(前)処理された任意のコンテンツのうちの少なくとも1つに対応するストリームを含み得る。CDN206に結合されたCDNエッジサーバ208は、それぞれのビデオ資産に対応するアップロードされたメディアストリーム202を受信するように設定され得、アップロードされたメディアストリーム202は、好適なデータベース(特に図示せず)に格納され得る。タイル化エンコーダ210は、標準コーデック方式(たとえば、HEVC、AV1など)に準拠して動作するように設定され得、各ストリームが(アスペクト比に応じて)特定の解像度、ビットレート、および画素サイズのタイルを含み得る複数のタイル化適応ビットレートストリーム212を生成するように動作する。例示として、ストリーム212は、1つまたは複数の32Kストリーム(30730水平画素×17280垂直画素)、16Kストリーム(15360水平画素×8640垂直画素)、1つまたは複数の8Kストリーム(7680水平画素×4320垂直画素)、1つまたは複数の4Kストリーム(3840水平画素×2160垂直画素)、1つまたは複数のHDストリーム(1920水平画素×1080垂直画素)、1つまたは複数の720pストリーム(1280水平画素×720垂直画素)などを含み得、より高い解像度のストリームはより高いビットレート範囲で符号化され得、より低い解像度のストリームはより低いビットレート範囲で符号化され得る。たとえば、32Kストリームは800~1000メガビット/秒(すなわちMbps)の範囲で符号化され得、16Kストリームは200~300Mbpsの範囲で符号化され得、8Kストリームは80~100Mbpsの範囲で符号化され得、1.2~3Mbpsの範囲で符号化され得る720pストリームまで以下同様である。さらに、タイル符号化ビットストリームとも呼ばれるタイル化適応ビットレートストリーム212は、採用されている方式に応じて、フレームごとに好適な数のタイル、たとえば4Kの場合は128タイルを有するフレームを含み得る。
一構成では、タイル化エンコーダ210は、メディア入力ストリーム202の各ビットレート表現に対して、複数の位相符号化ストリームとしてタイル符号化ビットストリームを生成するように設定され得、特定のビットレート表現に対する各位相符号化ストリームには、以下でさらに詳細に説明するように、位相に応じて、ストリームのグループオブピクチャ(GOP)構造内の特定のロケーションに、特殊化されたフレームが提供される。この符号化方式は、本発明の特定の実施形態に関して、位相符号化(PE)方式と呼ばれ得る。別の構成では、タイル化エンコーダ210は、メディア入力ストリーム202の各ビットレート表現に対して、タイル符号化ビットストリームのペア、たとえば、第1および第2のタイル符号化ビットストリームを生成するように設定され得、以下でさらに説明するように、第1の符号化ビットストリームは、知られている、またはこれまでに知られていないコーディング方式に従って生成された通常または標準のタイルコード化ビットストリームを含み得、第2の符号化ビットストリームは、GOP構造の各ロケーションに、特殊化されたフレームが提供されるように、コード化され得る。この符号化方式は、本発明の特定の実施形態に関して、ブロックイントラ符号化(BIE:Block-Intra Encoding)または全イントラ符号化(AIE:All-Intra Encoding)方式と呼ばれ得る。
PEコーディング方式またはBIEコーディング方式のどちらが使用されるかに関わらず、パッケージャ214は、タイル符号化ビットストリーム212をパッケージ化し、各タイル符号化ビットストリームのフレームごとに、タイルグループ化の特性、たとえば、タイルロケーション、スライスヘッダ情報、ピクチャタイミングを含む様々なタイプのメタデータ、色空間情報、ビデオパラメータ情報などを記述した好適なマニフェストファイルを生成するように動作し、マニフェストファイルは、好適なストリームマニフェスト241と共に、好適なパッケージ化されたメディア記憶ファシリティ240に記憶され得る。複数のモジュールまたはサブシステムを備えるビデオ最適化システム215を含むネットワークエッジノード216は、概してノードまたは要素230によって表される好適なアクセスネットワーク(たとえば、ルータ、DSLAM/CMTS要素などを含み得る好適なインフラストラクチャを有するDSL/DOCSISネットワーク部、または特定の実装形態における固定無線インフラストラクチャを含む好適な3G/4G/5G無線アクセスネットワーク要素など)を介して実現される管理対象帯域幅パイプ232によってサーブされる加入者宅234の宅内デバイス236との360°没入型ビデオセッションを実現するために、ビデオバックオフィスシステム238と関連して動作する。
一構成では、ビデオ最適化システム215は、帯域幅アニーリングおよびQoE管理ポリシー、ならびに特にユーザ注視ベクトル情報に対応して、異なるビデオ品質ビットストリームから選択されたタイル220を、タイル結合およびストリーム生成サブシステム222に提供するように動作する、タイル選択サブシステム218を備え得る。異なるビットストリーム224からのタイルを有する多重化ビデオフレームは、多重化タイルストリーム228の、下流インフラストラクチャ230への送信を容易にするために、配信サービス226に提供され得る。大まかに言えば、360°没入型ビデオセッションを求めるユーザ要求250が生成されると、ユーザ要求250は、ビデオバックオフィスシステム238によって処理され、セッションID、および要求された360°メディア用の関連するロケーション情報を取得するために、メッセージ252を介してビデオ最適化システム215に転送される。ビデオバックオフィスシステム238は、ビデオ最適化システム215からの応答メッセージ251に応答して、メディア用の適切なURL情報およびセッションIDを含む応答248を要求側デバイス236に提供するように動作する。(最初はデフォルト設定であり得る)ユーザ注視情報、および関連するセッションID情報は、メッセージ246としてインフラストラクチャ要素230に提供され得、メッセージ246は、メッセージ254としてビデオ最適化システム215に伝播され得る。また、インフラストラクチャ要素230は、関連するまたは別個のプロセスにおいて、セッションID情報を含む動的帯域幅割当メッセージ254を、ビデオ最適化システム215に提供するように動作する。前述のように、タイル選択サブシステム218は、帯域幅割当、ユーザ注視ベクトル情報、またはその両方に関連する制御メッセージに応答して、異なるビデオ品質を有するタイルを選択するために動作するように設定され得、異なるビデオ品質を有するタイルは、多重タイル符号化ビデオ出力ストリームを生成するめに、フレームに結合またはステッチされ得る。一構成では、タイル結合およびストリーム生成サブシステム222は、ビデオストリーム配信中にビデオ最適化システム215の一部として提供され得る。別の構成では、タイルステッチングは、プレイアウト中に、サーバ側ではなくクライアント側(たとえば、クライアントデバイス236またはそれに関連する何らかの他の宅内機器)で実現され得る。この構成では、クライアント側のステッチング機能は、選択されたタイルを受信し、復号およびレンダリング対象のステッチされたストリームを生成するために必要なステッチングを実行するように動作する。前述のプロセス、サブシステム、および構成要素に関連する様々な実施形態を、以下のセクションでさらに詳細に説明する。
図3は、図2のネットワークアーキテクチャの構成内で動作するように設定されたメディア準備および/または処理システムの一部として提供され得る例示的なタイルエンコーダ300のブロック図を示す。限定されないが、タイル符号化と互換性のある、たとえばH.265、H.266、VVC、AV1などの知られているまたはこれまでに知られていない標準コーデック方式に準拠しながら各メディア資産に関して異なる品質を有する、マルチビットレートのビデオストリームを生成するための、PEコーディング方式またはBIEコーディング方式のいずれかを実現するように設定され得る例示的なタイルエンコーダ300を、以下に説明する。大まかに言えば、一実施形態では、予測コード化(P)ピクチャまたはフレームとして符号化される(すなわち、フレームをPフレームとして識別するヘッダを有する)が、イントラコード化ブロックまたはユニット(すなわち、Iブロック)として符号化されたコーディングブロックまたはユニットを含む、特殊化されたフレーム(または、やや同義的にはピクチャ)が生成される。別の実施形態では、特殊化されたフレームは、双予測(B)フレームとして識別されるフレームを含み得るが、Iブロックのみを含む。本特許出願において、これらの特殊化されたフレームは、「ブロックイントラ」フレームまたは「X」フレームと呼ばれ、すべてのブロックのメディア画像データは、イントラコード化されるものとしてコード化される(すなわち、時間的な推定も予測もない)。
本明細書の例示的な実施形態において、GOP構造とは、イントラフレームおよびインターフレームが配置される順序を指定する、コード化されたビデオストリーム内の連続するピクチャのグループである。コード化された各ビデオストリームは、連続するGOPを備え、そこから可視フレームが生成され得る。一般に、GOP構造は、次のピクチャタイプを含み得る。(1)IピクチャまたはIフレーム(イントラコード化ピクチャ) - 他のすべてのピクチャとは独立してコード化されたピクチャ。各GOPは、(復号順で)このタイプのピクチャから始まる。(2)PピクチャまたはPフレーム(予測コード化ピクチャ) - 以前に復号されたピクチャと比較した動き補償差分情報を含む。MEPG-1、H.262/MPEG-2、およびH.263などのより古い設計では、各P画像は1つのピクチャしか参照することができず、そのピクチャは、表示順でも復号順でもPピクチャの前に位置しなければならず、IピクチャまたはPピクチャでなければならない。これらの制約は、たとえば、H.264/MPEG-4AVC、H.265/HEVCなどのより新しい規格には適用されない。(3)BピクチャまたはBフレーム(双予測コード化ピクチャまたは双方向予測コード化ピクチャ) - GOP内の前後のIフレームまたはPフレームからの差分情報を含み、以前に復号されたピクチャと比較した動き補償差分情報を含む。MPEG-1およびH.262/MPEG-2などのより古い設計では、各Bピクチャは、表示順でBピクチャの前のピクチャと後ろのピクチャの2つのピクチャのみしか参照することができず、参照されるピクチャはすべて、IピクチャまたはPピクチャでなければならない。これらの制約は、たとえば、H.264/MPEG-4AVC、H.265/HEVCなどのより新しい規格には適用されない。(4)DピクチャまたはDフレーム(DCダイレクトコード化ピクチャ) - 特定のタイプのビデオ(たとえば、MPEG-1ビデオ)における損失耐性または早送りのために、ピクチャの高速アクセス表現として機能する。
一般に、IフレームはGOPの先頭を示す。その後に、いくつかのPフレームおよびBフレームが続き得る。Iフレームはフル画像を含み、画像を再構築するために追加情報を必要としない。典型的には、エンコーダは、GOP構造を使用して、各Iフレームを「クリーンランダムアクセスポイント」にし、これにより、復号をIフレーム上でクリーンに開始することができ、GOP構造内のエラーは、正しいIフレームを処理した後に修正される。GOP構造は、しばしば、2つの数字、たとえば、M=3、N=12で表される。1つ目の数字は、2つのアンカフレーム(IまたはP)間の距離を示す。2つ目の数字は、GOPサイズである、2つのフル画像(Iフレーム)間の距離を示す。M=3、N=12の例の場合、GOP構造は{IBBPBBPBBPBBI}である。Mパラメータの代わりに、2つの連続するアンカフレーム間のBフレームの最大数を使用することができる。たとえば、パターン{IBBBBPBBBBPBBBBI}のシーケンスでは、GOPサイズは15(2つのIフレーム間の長さ)に等しく、2つのアンカフレーム間の距離(M値)は5(IフレームとPフレームの間の長さ、または2つの連続するPフレーム間の長さ)である。
典型的なGOPはIフレームで始まるが、本明細書のいくつかの実施形態は、以下でさらに詳細に説明するように、Xフレームを特定のロケーションに配置すること、またはGOP構造内のPフレームおよび/またはBフレームを置き換えることに加えて、代わりにGOPがXフレームで始まり得る構造を提供する。
たとえば、特にコーディング効率、並列処理などを容易にするために、ピクチャまたはフレームが、コーデックの実装に応じて、異なるレベルの粒度でいくつかの方法に分割され得ることが、当業者には理解されよう。一構成では、フレームは、いくつかのコーディングツリーユニット(CTU)に分割され得、各CTUは、一定の数の輝度コーディングツリーブロック(CTB)および彩度CTBを含み、CTBは、複数のコーディングブロック(CB)を備え得る。フレームは、1つまたは複数のスライスに分割され得、各スライスは、フレームの空間的に別個の領域であり、同じフレーム内の他の領域とは別に符号化され、スライスヘッダで識別され得る。一般に、スライスは自己完結型であり、ラスタ走査の順序で処理される一連のCTUを含み、スライスは、Iフレーム、Pフレーム、またはBフレームと同様に、それぞれIスライス、Pスライス、またはBスライスとしてコード化され得る。一構成では、スライスは、再同期を実現してデータ損失を最小限に抑えるために使用され得、ビデオシーンにおけるアクティビティに応じて、スライスごとに様々な数のCTUを含み得る。図4Aは、複数のスライス402-1~402-Nを含む例示的なビデオフレーム400Aを示し、例示的なスライス402-Nは、いくつかのCTU404を含む。
符号化方式は、スライスに加えて、フレームごとにタイルの数も規定し得、符号化段階および復号段階での並列処理を容易にするために、タイルは、グリッドを形成するための垂直と水平の分割に基づいて、ピクチャの自己完結型で独立して復号可能な長方形または正方形の領域であるようにも設定され得る。一変形例では、自己完結型で独立して復号可能なタイルは、以前に符号化されたピクチャまたはフレームの同一位置のタイルからの時間予測を使用し得る。複数のタイルは、同じスライスに含まれることによってヘッダ情報を共有し得、タイルは、一定の数のCTUを備え得る。各タイルが同じ数のCTUを含む必要はない。したがって、一構成では、フレームのタイルは、異なるサイズを有し得る。フレームが単一のスライスを含む場合、フレームのタイルは、同じスライスヘッダおよびピクチャヘッダ情報を有する。別の構成では、フレームは1つまたは複数のスライスを含み得、各スライスは1つまたは複数のタイルを含み、同様に各タイルは1つまたは複数のCTUを含む。図4Bは、タイル406-1~406-Nの行列または配列に編成された複数のCTUを含む例示的なビデオフレーム400Bを示し、各タイルは、2×2設定の4つのCTU408を有する正方形として示されている。さらなる例示として、図4Cには、HEVCによる例示的な4Kビデオフレーム400Cが示されており、16列および8行に分割されて128タイルとなる、3840水平画素×2160垂直画素の配列を含み得る。前述のように、これらのタイルは、フレーム400C内で必ずしも同じサイズであるとは限らない。
本特許出願において、ビデオフレームは多くの方法で異なるレベルで分割され得るので、「コーディングツリーユニット」、「コーディングツリーブロック」、「コーディングユニット」、「マクロブロック」、もしくは「ブロック」という用語、または同様の趣旨の用語は、一般に、特定のビデオ圧縮規格または技術に限定されることなく、タイル、スライス、および/またはフレームに対して適用され得るコーディングの抽象的な単位として扱われる。
図3に戻ると、例示的なタイルエンコーダ300は、PEベースまたはBIEベースの方式に関連して、Xフレームを生成するように設定され得、Xフレームは、対応するヘッダを有するがイントラコード化された個々のスライスおよび/もしくはタイルを伴うPフレームまたはBフレームとして、すなわち、Iブロックのみを含む、Iスライスおよび/またはIタイルとしてコード化される。言い換えると、Xフレームは、PフレームまたはBフレーム(または、フレームごとに1つのスライスのみが提供される場合は、PスライスもしくはBスライス)のヘッダ情報を含み得るが、すべてのメディア画像データは、Iフレームのデータとしてイントラコード化される。ビデオシーケンスの残りのフレームは、前述のように、知られているまたはこれまでに知られていない方式に従って、通常通り符号化され得る。したがって、一般コーダ制御306は、1つまたは複数の入力ビデオ信号304に関するPE方式またはBIE方式の特定の実装に従って必要に応じて特殊フレームの符号化を強制するように、タイルエンコーダのフロントエンド部302の残りの構成要素および構造に適切な制御信号および/またはパラメータを提供するために、PE方式308とBIE方式310のいずれかを選択するように設定され得る。一般に、PE方式における各ピクチャは、以下でさらに詳細に説明するように、通常のIフレーム(たとえば、シーケンスの最初のピクチャ用)または位相/周期に一致する入力ピクチャ用のXフレームのいずれかとして、またビデオシーケンスの他のすべてのピクチャ用の通常のPフレームまたはBフレームとして符号化される。BIE方式に関しては、シーケンスのGOP構造のすべてのPフレームおよびBフレームにXフレームが提供される、BIEコード化シーケンスが提供され得る。したがって、イントラ/インター選択ブロック312は、イントラピクチャ推定/予測316が常にアクティブであり、ピクチャのすべてのブロックに使用されるように設定される。同様に、すべてのブロックがXフレームに対してイントラコード化されるので、動き補償および推定318は、無効にされ得る。例示的な実施形態において、変換、スケーリング、および量子化314と、逆方向変換320と、フィルタ制御322と、デブロッキングおよびサンプル適応オフセット(SAO:sample adaptive offset)フィルタリング324と、復号ピクチャバッファ326とを含む残りのブロックは、タイルエンコーダの実装によっては、影響を受けないままであり得る。一般制御データ328、量子化変換係数データ330、イントラ予測およびフィルタ制御データ332、ならびに動きデータ334は、ビデオ資産の各ビットレート表現に対応する1つまたは複数のコード化ビットストリーム338を生成するために、ヘッダフォーマッタおよびエントロピエンコーダ336(たとえば、コンテキスト適応バイナリ算術コーディング(CABAC:context-adaptive binary arithmetic coding)エンジン)に提供され得る。前述のように、コード化ビットストリーム338は、適切な下流ネットワークロケーションでの資産の(事前)プロビジョニングを容易にするために、パッケージ化およびマニフェスト生成のためのタイル化パッケージャ(この図3には図示せず)に提供され得る。
図6は、本発明の一実施形態による、例示的なメディア準備/処理の一部として実装され得るPE方式またはBIE方式のいずれかを含む例示的な符号化構成600の様々なブロック、ステップ、および/または動作を例示する。ブロック604において、前述のように、符号化されていない、符号化されている、ステッチされている、投影マッピングされている、または別の方法で前処理され得る、ビデオソースストリーム602が受信される。ブロック606において、PEを選択するかBIEを選択するかの決定が行われ得る。タイルエンコーダシステム、たとえば、図3のタイルエンコーダ300内のモードセレクタは、その選択に応じて適切に設定され得る。PEを選択すると、ブロック608に記載のように、ビデオソースストリーム602は、異なる品質および/またはビットレートを有する複数のストリームに符号化/トランスコーディングされ得、各ストリームは、タイルを用いて符号化される。各品質またはビットレートストリームは、複数のPEストリーム610を生成するために位相符号化される。例示として、参照番号614-1は、対応する位相615-1~615-P(XフレームがGOP構造のどこに配置されているかに依存し、Pは、GOPサイズである)を有する位相符号化ストリーム612-1のセットに関する品質情報を指し、PEストリームはすべて、量子化パラメータ(QP:Quantization Parameter)設定値が30、および/またはビットレートが約7.0メガビット/秒であり、これは品質の下限を示し得る。同様に、参照番号614-Nは、対応する位相615-1~615-Pを有する位相符号化ストリーム612-Nのセットに関する品質情報を指し、ストリームはすべて、QP設定値が16、および/またはビットレートが約105.6メガビット/秒であり、これは品質の上限を示し得る。
(本特許出願の他の箇所に記載されているように、全イントラ符号化とも呼ばれる)BIEが選択された場合、ビデオソースストリーム602は、変化する品質および/またはビットレートを有する複数のストリームに符号化/トランスコーディングされ得る(ブロック616)。例示的な実施形態では、ストリームのそれぞれは、標準的なコーディング方式(たとえば、HEVC、AV1など)を使用してタイル符号化されて、標準または通常のタイル符号化ストリーム618が生成される。位相タイル化ストリーム610に関する上記の説明と同様に、参照番号622-1は、例示として、QP設定値が30および/またはビットレートが約7.0メガビット/秒である通常のタイル符号化ストリーム620-1に関する品質情報を指し、これは品質の下限を示し得る。同様に、参照番号622-Nは、QP設定値が16および/またはビットレートが約105.6メガビット/秒である通常のタイル符号化ストリーム620-Nに関する品質情報を指し、これは、より高品質のストリームを示し得る。
さらに、ビデオソースストリーム602はまた、対応する品質および/またはビットレートを有する複数のストリームに符号化/トランスコーディングされ(ブロック617)、各ストリームは、そのGOP構造のすべてのフレームがXフレームとして提供されるようにタイル符号化される。例示として、参照番号632は、複数のBIEコード化およびタイル化されたストリームを指し、QP設定値が30および/またはビットレートが約7.0メガビット/秒(MbまたはMb/秒と略されることもある)である品質情報636-1は、より低品質のBIEコード化タイルストリーム634-1に関し、一方、QP設定値が16および/またはビットレートが約105.6メガビット/秒である品質情報636-Nは、より高品質のBIEコード化タイルストリーム634-Nに関する。
本明細書を参照することにより、エンコーダがターゲットQPを有するように設定されるとき、符号化ビットストリームのビットレートが、ビットストリームにわたってある程度平均化されることが、当業者には理解されよう。たとえば、ソース符号化方式でQP10がターゲットにされる場合、動きのないエリアでは低ビットレートが見られ得る(たとえば、4Mbsになる)可能性がある。動きが多いエリアでは、ビットレートが200Mbsに急上昇する可能性がある。したがって、前述のように特定のQPをターゲットとする例示的な符号化方式では、出力ストリームのビットレートは、ある範囲にわたって可変であり得る。したがって、図6のPEストリームまたはBIEストリームのQPに関連して示されたビットレートは、一般に時間の経過に伴う平均ビットレートを示すことを理解されたい。以下でさらに理解されるように、符号化方式においてQPがターゲットとされる(それに対応して変化するビットレートを有する)とき、タイル選択に関する本発明の特定の実施形態は、タイルを選択し、特定の360度没入型ビデオセッションに対して割り当てられた全体的なビットレートに従ってそれらのタイルを適合させるように設定され得る。追加のまたは代替の実施形態では、例示的なエンコーダは、ターゲットQPの代わりに特定のターゲットビットレートを有するコード化ビットストリームを生成するように設定され得る。しかしながら、このような構成では、出力ビットストリームは特定のビットレートを維持し得る一方で、QP値は変化する可能性がある。したがって、タイル選択の一実施形態は、異なる符号化パラメータおよび設定値によって制御され得るビデオ品質に基づいてタイルを選択し、それに応じてそれらのタイルを適合させて、割り当てられた帯域幅を最適化することができる。本特許出願において、「品質」、「ビデオ品質」という用語、およびコード化ビットストリームまたはビットレート表現に関する同様の趣旨の用語は、QP、ビットレート、他の指標に幅広く関連し、かつ/またはそれらに基づき得る。したがって、ターゲットとされるQPに基づく本明細書に記載のPE/BIE符号化、タイル選択、ステッチングなどに関する実施形態は、ターゲットとされるQPビットレートを有するビットストリームにも等しく準用される。
したがって、本開示内の説明の特定の例および部分は、ストリームごとの固定量子化(QP)値の使用を想定して提供されるが、実際のストリームは、上記のように、ピクチャ間およびピクチャ内で変化するQP値を含み得ることを、読者は理解すべきである。本発明の一実施形態によるエンコーダは、レート制御などによってその出力ビットレートを制御し、それによりピクチャ間のQP値を変化させ得る。エンコーダはまた、ストリームの視覚品質を最適化するために、変化するQP値を使用して1つのストリーム内のピクチャを符号化し得る。当技術分野で知られているように、QP値は、1つのピクチャ内で、たとえば、視覚品質を最適化するため適応量子化メカニズムを使用してブロック間で変化し得る。本開示内の語句における「QP」の使用、たとえば、限定はされないが、「そのQPを用いて符号化された」、「異なるQP値のビデオ」、「異なるQP値を用いて生成されたビデオ」、「QP値Nを有するストリーム」、「ビデオストリームのQP値」などは、より低いQP値に関連付けられたストリームが、より高いQP値に関連付けられたストリームよりも高いビットレートおよびより高い品質であり、QPがストリーム内の各ブロックで静的に保たれているわけではないようなストリームを特徴付ける方法として理解されるべきである。
様々なタイプの符号化および/またはトランスコーディングが異なるシーケンスおよび/または並列プロセスで行われ得るように、例示的な実施形態では、メディア資産の適応ビットレート符号化およびタイル符号化が、コンテンツ準備システムの一部として装置内に統合され得ることをさらに理解されたい。さらに、投影マッピング、ソースストリームステッチング、パッケージ化などの追加機能も、実装形態に応じて、本特許出願のタイルコーディング/トランスコーディング方式と組み合わされるか、または別の方法でそれらと統合され得る。
図5は、本発明の1つまたは複数の実施形態による、本開示の追加の流れ図のブロック、ステップ、および/または動作の有無に関わらず1つまたは複数の構成で(再)結合され得る、最適化された360°没入型ビデオを容易にするための方法500の様々なブロック、ステップ、および/または動作を例示する流れ図である。ブロック502において、メディアキャプチャ、および没入型ビデオのためのメディア入力ストリームの前処理に関連する様々な動作、たとえば、ソースストリームステッチング、符号化、投影マッピングなどが実現され得る。ブロック504において、前処理されたメディア入力ストリームの、異なるビデオ品質を有する(たとえば、変化するQP値を有する)複数のビットレート表現またはストリームへの適応型ビットレート符号化/トランスコーディングが、タイル符号化方式に関連して実現され得る。前述のように、PEベースのコーディングプロセス(ブロック506A)またはBIEベースのコーディングプロセス(ブロック506B)のいずれかが、コード化ビットストリーム出力を生成するように設定され得る。ブロックの適応型ビットレート符号化/トランスコーディング504が、単一の符号化プロセスを使用して、PE方式(ブロック506A)またはBIE方式(ブロック506B)のいずれかを使用して行われるように、ブロック504および506A/Bのプロセスは、単一の符号化動作として実行され得ることに留意されたい。その後、コード化ビットストリームは、好適なエンドユーザ機器を使用するクライアントによる配信および消費のために、パッケージ化され(ブロック508)、適切なネットワークエッジロケーションに配布され得る(ブロック510)。特定のメディア資産を求めるユーザ要求が受信および処理されると、メディア資産の異なるビットレート表現(すなわち、異なる品質)からタイルを選択するために、制御入力、たとえば、送信条件、帯域幅割当、および/または注視ベクトルの入力などに基づいたタイル選択プロセスが実現され得る(ブロック512)。選択されたタイルを、要求側クライアントデバイスに配信すべき出力ビデオストリームとしてフレームにステッチするための、ストリーム生成プロセスが実現され得る(ブロック514)。
前述のステップ、動作、または動作の少なくとも一部が、上記の図1および図2に例示されたネットワーク環境またはアーキテクチャに配布された1つまたは複数の360°没入型ビデオ資産に対するメディア準備および(事前)プロビジョニングを含み得ることが、当業者には理解されよう。図7を参照すると、本発明の例示的な実施形態による、BIE方式700に関する追加の詳細が示されている。ブロック702およびブロック704において、360°没入型ビデオ資産に関連するメディア入力ストリームが受信され、異なる/別個の品質を有する複数のビットレート表現を生成するように処理され、たとえば、各ビデオ品質は、各ビットレート表現に使用される対応するターゲットQP値および/もしくはターゲットビットレートもしくはそれぞれの品質の他の指標に関連するかまたはそれらによって制御され得る。各ビットレート表現は、特定のGOP構造を伴う複数のフレームを含む第1のコード化ビットストリームにコード化され、各GOPは、Iフレームで始まり、その後に少なくとも1つのPフレームまたはBフレームを含むフレームのセットが続く(ブロック706)。さらに、ブロック708に記載のように、各ビットレート表現は、第1のコード化ビットストリームのGOP構造のサイズと同一の広がりのサイズを有するGOP構造を伴う複数のフレームを含む第2のコード化ビットストリームに符号化され、第2のコード化ビットストリームの各GOPは、Iフレームで始まり、その後に複数のXフレームが続き、各XフレームはPフレームまたはBフレームのスライス/ピクチャヘッダを用いてコード化され、イントラコード化メディア画像データのみを含む(すなわち、GOPのIフレームと同様である)。前述のように、第1のコード化ビットストリームおよび第2のコード化ビットストリームは、任意のタイル互換圧縮方式を使用して、それぞれのタイル符号化ストリームとして符号化され得、タイル符号化ビットストリームの各フレームは、フレームごとに少なくとも1つのスライスに編成されたタイルの配列を含み、各タイルは、いくつかのコーディングユニット、ブロック、またはツリーとして形成されたフレームのメディアデータの一部を含む。一実装形態では、図5のブロック504および506A/Bに関して前述したように、ブロック704およびブロック706のプロセスが単一の符号化プロセスで実行され得ることが、当業者には理解されよう。たとえば、実際には、計算複雑性を最小限に抑え、タンデムまたはカスケード符号化によってもたらされる劣化を最小限に抑えるために、単一プロセスの符号化/トランスコーディングが望ましい。
図11は、例示的な実施形態における、BIEベースのタイル化エンコーダシステムによって生成された、異なる品質またはQPを有する複数のコード化ビットストリーム1100を示す。参照番号1102-1~1102-Nは、対応する品質またはQPを有するN個のストリームまたはビットレート表現を指す。特定のビットレート表現、たとえば、QP-N 1102-Nに対応する、通常通り符号化されたタイル化ストリーム1104Aが示されており、GOP構造1106Aは、Iフレームで始まり3つのPフレームが続く4つのフレームを有する。対応するBIEコード化ストリーム1104Bは、同様に、Iフレームで始まり3つのXフレームが続く4つのフレームで示されたGOP構造1106Bを有する。
図8Aは、本発明の例示的な実施形態による、タイル符号化構成でBIE方式を設定するためのプロセス800Aを例示する流れ図である。限定されないが、例示的なプロセス800Aは、一定のパラメータの変更に基づいてBIEを実行するためのHEVC方式を設定すること関連して説明されるが、他の方式もまた、本明細書の目的に適用され得る。
一般に、BIE設定方法の一実施形態は、360°没入型ビデオのソースビデオストリームおよび出力ビデオ品質のリスト(たとえば、{QP1=16、QP2=18、QP3=20、QP4=22、QP5=24、QP6=26、QP7=28、QP8=30、またはターゲットビットレートに基づく他の指標}などのQP値のリスト)を、入力として受信または取得するように設定され得る。したがって、限定されないが、前述のように、すべての出力ビデオ品質(たとえば、すべてのQP値)について、そのQPまたは品質を有する通常/標準のHEVCビデオ、およびそのQP/品質を有するブロックイントラHEVCビデオの、2つのビデオストリームが符号化され得る。後で(たとえば、復号の直前に)異なる品質からのタイルを同じビットストリームにステッチできるようにするために、一実施形態の符号化の位相は、すべてのビデオストリームが同じ(以下に規定される)base_qpを有し、一方、異なるQP値のビデオ間の実際の差分は、ベースQPからの(以下に規定される)qp_deltaを使用して実現され得る。たとえば、設定値base_qp=22が設定されてもよく、パラメータ値base_qp=22およびqp_delta=-6を使用して、QP=16を達成することができる。一般に、これら2つのパラメータは、ビデオストリームの品質(QP)の設定に関連する。異なるqp値で生成されたすべてのビデオは同じbase_qpを有する必要があり、base_qpからqp_deltaを使用することによって異なるQP値が達成され得ることを想起されたい。この要件は、1つの特定の時間インスタンスに基づいて課され得る。すなわち、ビットストリーム内のピクチャに番号が付けられている場合、同じ番号でステッチするための入力として使用される2つのビットストリームからの2つのピクチャは、1つの構成において同じbase_qp値を使用しなければならない。本発明において、「base_qp」は、次のように説明され得る: 同じビデオのすべての符号化されたバージョンまたはビットレート表現におけるi番目のフレーム(各i=1~N、ここでNはビデオシーケンス内のフレームの総数)は、同じスライスQP値を有することになる。言い換えると、スライスQPは、base_qpである。スライスQPは、生成されたすべてのストリームで同じ値として設定され得るが、時間の経過と共に変化する可能性がある。本発明において、パラメータdelta_qpは、次のように説明され得る: 所与のqp_deltaを代入することによって、QPをシグナリングする各タイル内の最初のブロックは、delta_qp(ベースQPからの分散量)をシグナリングするように設定される。いくつかの実施形態では、ステッチング後にデブロッキング不一致が存在する可能性があることに留意されたい。
本発明において規定され得る別のパラメータは、ROI:Region of Interest(関心領域)であり、ROIは、タイルが独立して符号化され得るフレームのエリアを決定し、それにより、ROIに対応するビットストリームのサブセットが、容易に抽出されて別のビットストリームに再構築され得る。上記のように、後で異なるQPのビデオをステッチするために、base_qpおよびdelta_qpの機能を利用することが望ましい。これは、たとえば、1つの例示的な実装でHEVC ROI符号化の機能を使用する場合にサポートされる。したがって、一実施形態においてROIを用いて符号化する場合、ROIグリッドのi番目の行およびj番目の列のグリッドのエリアが独自のdelta_qpを得るように、(フレームのタイルのグリッド/配列から独立して規定される)ROIグリッドを規定することに加えて、スライスQPヘッダ用のbase_qpパラメータが規定され得る。一般に、これにより、一実施形態は、異なるdelta_qpをROIグリッドの異なるエリアに代入することができ、それにより、本発明において、選択的なdelta_qp値が使用され得る。たとえば、所与の所望のQP(たとえば、QP=16)を達成するために、通常のqpパラメータを使用してbase_qp(たとえば、base_qp=22)が規定され得、次いでROIグリッドを使用することによって、すべてのターゲットエリアに-6というdelta_qpが代入され得、このようにして、ROIグリッド内のすべてのタイルに対して16というQPを効率的に達成する。
一実施形態では、異なる品質のコンテンツが、特定のフレームに対して同じbase_qp(スライスQP)を使用して符号化され得る。そのフレームの品質ごとに、特定の所望のQPが設定され得、そのフレームのすべてのブロック(あるいは代替として、可能な限り多くのブロック、または所望の数のブロック)がその所望のQPで符号化されるように、delta_qp構文要素が使用され得る。HEVCに基づくBIE設定方式の追加の態様は、以下のように説明され得る。
エンコーダは、タイル符号化を使用するように設定され得る。このタイル符号化は、セットアップ中に、タイル符号化のための適切なフラグを設定すること、ならびに(たとえば、図4Cに示すように)タイルの特定のグリッド構造を設定することによって達成され得る。例示として、4Kビデオ入力の場合、エンコーダは、16×8グリッド構造のタイルを提供するようにされ得、各フレームに128個のタイルがもたらされる。
エンコーダは、時間動きベクトル予測を無効にするように設定され得る。例示的なBIE方式は、MV(動きベクトル)を使用しないが、後でステッチングを有効にするために、時間動きベクトル予測(TMVP:temporal motion vector prediction)設定は、ストリーム全体にわたって同一である必要があり得る。BIEの実施形態はTMVPを無効にすることなく実施され得るという点で、この設定は任意選択である。
また、スライスヘッダの他の多くの要素は、ストリーム全体にわたって同一になるように設定され得る。たとえば、要素とは、使用する参照ピクチャの数、参照ピクチャセット、L0にどの参照ピクチャを使用するか、使用するピクチャパラメータセット(PPS:Picture Parameter Set)、ピクチャの順序数、SAOパラメータなどである。さらに、復号順は、ビットストリーム切替えの入力として使用されるすべてのビットストリームで同じである必要もある。本明細書を参照することにより、例示的なBIE実装形態において、様々なスライスヘッダ要素が適宜に設定され得ることが、当業者には理解されよう。
スライスは、単一PPS idコードワードを使用して、どのPPSを使用すべきかを識別し、PPSは、1つの単一シーケンスパラメータセット(SPS:Sequence Parameter Set)を参照するので、例示的な実施形態では、すべての符号化は、同一のPPSおよびSPS id値を使用して行われ得る。同様に、SPSおよびPPSにおける多くの構文要素も、複数の符号化について同一になるように設定され得る。したがって、必須の要件ではないが、例示的なBIEの実施形態は、符号化が同一のSPSおよびPPSを使用して実現されるように設定され得る。しかしながら、一定の構成では、SPSおよびPPSにおけるいくつかの要素が必ず同一である必要がある。
図8Aに戻ると、例示的なBIE設定プロセス800Aは、エンコーダのモードセレクタを初期化して、上記のように入力ビデオストリームを符号化するためにBIEを選択することで開始し得る(ブロック802)。ブロック804において、エンコーダは、フレームごとに特定のグリッドまたは配列構成でタイルを使用するように設定され得る。ブロック806において、符号化ストリームのすべてのスライスQPヘッダ内に、base_qpパラメータが記述され得る。(同じbase_qpを有するが)異なる品質のストリームを符号化するために、上記のように、ターゲットQPに基づいて各ストリームに対してqp_deltaパラメータが設定され得る(ブロック808)。たとえば、特定のストリームに対してターゲットQP22を達成するには、base_qpが32である場合、-10というqp_deltaが設定され得る。前述のように、ステッチング用の入力として使用される同じピクチャ番号を有するすべてのピクチャは、同じbase_qp値を使用しなければならない。したがって、一実施形態において、すべてのストリームヘッダに同じbase_qpパラメータを設定することは、必須の要件ではない。空間動きベクトル予測は、タイル内のみに制限されるように設定され得る(ブロック810)。すなわち、例示的な実施形態では、動きベクトルは、タイル境界を越えることはできない(すなわち、タイル内予測のみが可能である)。これは、動きベクトルが、タイル内のブロックの動き補償補間中に任意の同一位置のタイルの境界外のサンプルが読み取られないように設定されることを意味する。エンコーダがフレームの特定の領域に関して特定のストリームを符号化するためにqp_delta情報を使用するように、エンコーダ用にROIグリッドが設定され得る(ブロック812)。さらに、TMVPはまた、上記のように例示的なBIE設定プロセスにおいて無効にされ得る(ブロック814)。
前述のBIE設定プロセス800Aは一定のパラメータを使用するが、BIE方式が、図8Aの流れ図に例示されているパラメータに加えてかつ/またはその代わりに他のパラメータを利用するように設定され得る、追加のまたは代替の実施形態が実施され得ることに留意されたい。
図8Bは、本発明の実施形態による、例示的なBIE方式800Bにおける追加のブロック、ステップ、および/または動作を例示する流れ図である。一般に、エンコーダは、BIEベースのタイルコード化中にいくつかの判定を実現するように設定され得る。Pフレームの一部であるタイルの符号化中、エンコーダは、前のフレームに依存して任意の動きベクトルを使用して特定のタイルを符号化すべきかどうか、または、タイルが自己完結型であり、前のフレームに依存しない(すなわち、前のフレームからの予測を使用しない)「イントラ」モードで、そのタイルを符号化すべきかどうかを判定する。前述のように、BIEでのPフレームの符号化中、エンコーダは、イントラモードを使用してすべてのブロックを符号化するように強制される。ブロック834において、符号化のためにビデオ入力832が受信される。ブロック836において、タイル化エンコーダは、上記のようにBIEプロセスを実装するように設定される。フレーム単位で適切なコーディング判定を実現するために、ビデオ入力のフレームごとに反復プロセスが実装され得、反復プロセスは、ビデオシーケンスがその終端に到達したかどうかに関する判定から開始する(ブロック838)。終端に到達していない場合(すなわち、処理を必要とするフレームがビデオシーケンス内に残っている場合)、次のフレームが取得される(ブロック840)。フレームがGOP構造の最初のフレームであると判断された場合(ブロック842)、フレームは、通常のIフレームとして符号化され(ブロック854)、プロセスの流れは次のフレームを取得することに戻る(ブロック840)。それ以外の場合、フレームは、Pフレームとして符号化される(ブロック844)。Pフレームのスライスごとに、スライスは、Pスライスヘッダを用いて符号化または提供される(ブロック846)。Pスライスのブロックまたは任意の他の好適なコーディングユニットごとに、エンコーダは、画像データをイントラモードで符号化するように設定される(ブロック848)。その後、プロセスの流れは戻り、すべてのフレームが処理されたかどうかを判定する(ブロック838)。処理された場合、ビデオシーケンスの符号化が確定され(ブロック850)、ブロック852に記載のように、ビデオシーケンスは、下流エンティティ(たとえば、パッケージ化システム)にBIEタイル化ビットストリームとして提供され得る。代替の構成では、本特許出願の他の箇所に記載されているように、Xフレームを生成するために、Pフレームの代わりにBフレームが使用され得る。したがって、ブロック844、846は、この構成をサポートするように好適に変更され得る。
本発明のさらなる実施形態では、Xフレームは、前述のように、PE方式に基づいて、(BIEのように複数回ではなく)各GOPにおいて1回使用され得る。基本的に、PEベースのタイル符号化は、Iフレームである最初のフレームを除いてすべてのフレームがPスライスヘッダを有し、周期的にXフレーム(すなわち、BIEフレームまたはAIEフレーム)があり、すべてのブロックがイントラ符号化されるが、スライスヘッダがPスライス(または、Bフレームもシーケンスで符号化されるBスライス)であるストリームを生成するためのプロセスおよび装置を含む。一般に、ステッチングへの入力として使用される可能性のある任意の2つのピクチャのすべてのスライスは、同じスライスタイプ、スライスqp、ならびにスライスヘッダおよびPPSにおけるいくつかの他の設定を有する必要がある。GOPのすべてのフレームが最初のフレームを除いてXフレームである上記のBIE方式とは対照的に、PE方式の一実施形態は、2つのパラメータ、すなわち周期(GOPのサイズ、すなわちGOP内のフレーム数)、および位相({0~[周期-1]}の範囲の整数)に応じて、選択されたフレームロケーションでのみXフレームを提供するように設定される。PE方式においてXフレームが現れるフレームロケーションは、次のように決定され得る。Nをストリーム内のフレームの総数とする。最初のフレームは、Iフレームとして符号化される。i番目の位置のフレーム、2≦i≦Nに関しては、{i Mod (周期)≠位相}の場合、フレームは通常のPフレームとして符号化され、それ以外(すなわち、{i Mod (周期)=位相})の場合、フレームはXフレームとして符号化される(Pスライスヘッダおよびすべてのブロックが、前のフレームとは独立してイントラモードで符号化される)。例示的なPE方式は、メディア入力の品質/ビットレート表現ごとに、GOP内のフレームロケーション(すなわち、GOPサイズ)と同じ数の位相符号化ストリームを提供し得ることに留意されたい。
本発明では、XフレームにおいてIスライスヘッダではなくPスライスヘッダまたはBスライスヘッダを使用することによって、例示的な実施形態において、ユーザ鑑賞環境におけるGOP途中の切替えを容易にすることを含むがこれに限定されないいくつかの利点が実現され得る。ユーザが360°没入型ビデオプログラムまたはコンテンツを見ており、直接注視された視野(FoV:field of view)は高品質(すなわち、より低いQP)であり、ユーザがGOPの途中で自分の頭部を動かすと仮定する。ユーザは、次に、新しい視野またはビューポートで低品質(より高いQP)のビデオを見る。サーバは、次のGOPの開始時に高品質(低いQP)のIフレームを送ることができるが、これは、ビューポートに対する次のGOPの高品質のIフレームが提示されるまでに時間がかかるので、大幅なレイテンシが発生する。GOPの途中で、できるだけ早く高品質で符号化された新しい視野のIフレームを受信または取得することが望ましい。しかし、従来の没入型ビデオ鑑賞環境において、GOPの途中にIフレームをそのまま配置することは実現不可能である。したがって、本発明の一実施形態は、Xフレーム(すなわち、ブロックイントラコード化フレームまたは全イントラコード化フレーム)を生成し、それをGOPの途中で(たとえば、GOP構造内の任意のフレームロケーションで)送信することによって、高品質のタイルを伴うGOPの途中でIフレームが提示された場合の効果と同様に、視野の品質を効果的にアップグレードすることができる。したがって、本発明の一実施形態は、AI符号化フレームまたはBI符号化フレーム(すなわち、AIE/BIEフレーム、またはXフレーム)にPスライスヘッダを提供することによって、FoVの関心領域(ROI)内に高品質のデータを有するフレームを、GOPの途中で使用できるようにする。
さらに、フレームがタイルおよびスライスに分割されるタイル符号化方式において、Xフレームを含む本発明の一実施形態は、単一の出力圧縮フレーム内でタイルを混合することを可能にし、いくつかのタイルは、空間予測または時間予測(すなわち、インターピクチャ予測)を使用し得、いくつかのタイルは、(たとえば、イントラコード化ブロックのみを含む)空間予測のみを使用し得る。イントラコード化ブロックのみで構成されるタイルは、Xフレームから発生し得る。本特許出願の文脈において、「混合」、「多重化」、「ステッチング」、「スプライシング」という用語、または出力ストリーム生成に関する同様の趣旨の用語は、1つの圧縮タイル(たとえば、タイルA)を別の圧縮タイル(たとえば、タイルB)と連結して、単一の出力フレームを表すビットストリームの一部を形成するための手段および方法を指す場合があり、タイルAおよびタイルBは、コンテンツの個別の符号化に由来する場合があり、これについては、以下でさらに詳細に説明する。
PE方式の利点の1つは、BIE方式に存在し得るドリフトの問題を克服すること(すなわち、ドリフトの除去または低減)に関する。BIEは、前のビューポートのPフレームを新しいビューポートのXフレームに置き換えることを可能にするが、次に続くフレームは、前のフレームに対して行われた予測で符号化された新しいビューポートの通常のPフレームであることを理解されたい。したがって、PフレームがXフレームに置き換えられ、次いで、次に続くフレームが、通常のビットストリームの元のフレームの代わりにこのXフレームを予測に使用する場合、予測誤差が蓄積し得るドリフトが生じる可能性がある。一方、位相符号化では、生成されたストリームは、次に続くPフレームの予測のために、位置=<位相>+i*<周期>でXフレームを使用し、それにより、Pフレームが、符号化中に使用されるフレームとは異なるフレームを予測に使用するという状況が回避される。したがって、符号化中に生成されたフレームとは異なるフレームから予測することによって生じる予測誤差はなく、その結果、このタイプの予測誤差による潜在的なドリフトは回避される。しかしながら、GOP内のXフレームに続くPフレームのストレージが必要であるので、PE方式ではより多くのストレージが必要になり得る。
さらに、有利には、PE方式の一実施形態は、フレームの段階的リフレッシュを容易にするために利用され得、これにより、タイルのサブセットのみを選択してそれらの品質をアップグレードし、それらの適切な位相符号化タイルを送ることによって、プレイアウト中により低いレイテンシが達成される。BIE方式の一実施形態では、PフレームがXフレームで置き換えられるが、段階的リフレッシュフレームアニーリング方式において、PEコード化ストリームは、選択されたタイルを適切なPEコード化ストリームから取られた対応するタイルで置き換えるために使用され得る。一方、別の実施形態において、有利には、BIE方式もまた、タイル単位で動作することができる。したがって、PEベースの実施形態に関して、周期がPであり、フレーム番号がXである場合、次の式:位相={X Mod P}によって、対応する位相を得ることができる。したがって、コード化されたビデオシーケンスの配信またはプレイアウト中、フレームX内で、QP品質qにアップグレードするために特定のタイルTが選択されたと仮定すると、(フレームX、およびTの次のアップグレード/ダウングレードまたはビューポート変更までの次に続くフレーム内で)選択されたタイルを、次の関係、すなわち、QP=qで位相={X Mod P}を満たす位相を有するストリームからのタイルTに置き換えることができる。その後、同じGOPに属する、フレームXに続くフレーム内の同一位置のタイルは、同じPE符号化ストリームからの対応する同一位置のタイルに置き換えられる。ユーザが注視方向を変更するときに異なるストリームからのタイルを連結することの利点は、ユーザがGOPの途中で自分の注視を変更する上記のシナリオと同様であることを理解されたい。2つの入力タイルが異なる実際のQPで符号化され、ピクチャごとに単一のスライスで符号化された場合、スライスQPが異なると、ストリームの下位レベルの書き換えなしで出力ストリーム内のタイルのQPを正しい状態にすることは不可能になるので、タイルの切替え/置換えに同一のスライスQPが使用される。段階的リフレッシュフレームアニーリングおよびタイル選択に関するさらなる詳細について、本特許出願の追加の実施形態を参照して、以下でさらに説明する。
PEに関する潜在的な欠点は、入力ストリームが多くの位相で符号化され、(BIEのように2つのストリームだけではなく)GOPサイズと同じ数のストリームが生成される可能性があるので、より多くのストレージが必要になることであり得る。この欠点は、例示的な実装形態において、ドリフトなしでレイテンシが短縮されるという利点とトレードオフされ得る。最速の品質変更応答の場合、位相の数は、GOPのサイズ、すなわち周期Pに等しく設定され得るが、例示的な実施形態は、タイルのアップグレードが次の位相でのみ行われるので、使用する位相がより少なく、ストレージの消費がより少ない一方で、品質のアップグレードのレイテンシはより長くなる可能性があるというトレードオフを提供し得る。
図9は、本発明の例示的な実施形態によるPE方式900を例示する流れ図である。ブロック902において、360°没入型ビデオ資産に対応するメディア入力ストリームが受信され得る。前と同様に、メディア入力ストリームの複数のビットレート表現が生成され得、各ビットレート表現は、たとえば、ビットレート表現に使用される対応するターゲットQP値および/もしくはターゲットビットレートもしくはそれぞれの品質の他の指標に関連するかまたはそれらによって制御される、別個のビデオ品質を有する(ブロック904)。対応するQPによって制御される各ビットレート表現は、複数の位相符号化ビットストリームに符号化され、特定のビットレート表現に属する各位相符号化ビットストリームは、GOPサイズ(p)を有する特定のGOP構造を伴う(N)個のフレームを含み、複数の位相符号化ビットストリームの数は、GOPサイズに等しい。一構成では、GOPサイズ、すなわちp>1である。p番目の位相符号化ビットストリームごとに、N個のフレームは、次のように符号化される。(i)少なくとも最初のフレームは、イントラ符号化(I)フレームとして符号化され、(ii)2≦i≦Nの場合、{i Mod (GOPサイズ)}=pの関係を満たすフレーム位置iのフレームは、Pフレームのスライスヘッダを有し、かつイントラコード化メディア画像データのみのブロックを含むXフレームとして符号化される(すなわち、Iフレームと同様)。それ以外の場合、そのフレームは、Pスライスヘッダを伴う予測コード化フレームのメディアデータを有する通常のPフレームとして符号化される(ブロック906)。いくつかの構成では、Pフレームは、イントラコード化データも含み得る。一実施形態において、Bフレームも符号化される場合、前述のプロセスと同様に、通常のBフレームの代わりにXフレームが提供され得る。図5および図7に関して前述したように、例示的な一実施形態において、ブロック904およびブロック906に記載の動作は、計算効率のために単一の符号化プロセスで実行されるように組み合わされ得る。
PE方式の追加のまたは代替の実施形態では、位相符号化ビットストリームは、コード化されたビデオシーケンスの最初のフレームとして、Iフレーム以外のフレームを有し得、これは、本明細書の教示によるエンコーダにおける適切な設定によって達成され得る。たとえば、最初のフレームは、Xフレーム(または、他の非Iフレーム)であり得る。コード化されたシーケンスの他のすべてのフレームは、位相に基づいて好適なロケーションに予測フレーム(P/Bフレーム)およびXフレームを含み得る。
図12は、例示的な実施形態における、PEベースのタイル化エンコーダシステムによって生成された、特定のビットレート表現に対して異なる位相を有する複数のコード化ビットストリーム1200を示す。例示として、QP値22を有するQP-Nストリーム1202-Nは、本例では4つのフレームのGOPサイズを使用するので、4つの位相符号化ストリーム1204-1~1204-4として符号化されるか、または別の方法で提供される。PEストリーム1204-1~1204-4ごとに、最初のフレームが、Iフレーム1206-1~1206-4として符号化される。各PEストリーム内の残りのフレームは、上記の位相と位置の関係に基づいて、PフレームまたはXフレームとして符号化される。
図10Aを参照すると、本発明の例示的な実施形態による、タイル符号化構成でPE方式を設定するためのプロセス1000Aを例示する流れ図が示されている。ブロック1002において、360°没入型ビデオ資産に対応するメディア入力ストリームに関してPE方式を選択するために、エンコーダが初期化され得る。ブロック1008において、周期および位相のパラメータが取得されるか、または別の方法で設定され、周期はGOPサイズに等しく(ブロック1004)、位相はGOPサイズ以下である(ブロック1006)。ブロック1010において、エンコーダは、タイル符号化を使用して、フレームごとに特定のグリッド/配列構成でタイルを生成するように設定され得る。前述のBIE設定プロセスと同様に、符号化ストリームのスライスQPヘッダ内に、base_qpパラメータが記述され得る(ブロック1012)。前述のように、ステッチング用の入力として使用される同じピクチャ番号を有するすべてのピクチャは、同じbase_qp値を使用しなければならない。したがって、例示的な実施形態において、すべてのストリームヘッダに同じbase_qpパラメータを設定することは、必須の要件ではない。(同じbase_qpを有するが)異なる品質のストリームの符号化を容易にするために、上記のように、ターゲットQPに基づいて各ストリームのqp_deltaパラメータが設定され得る(ブロック1014)。前述のように例示的なBIE設定プロセスでは、特定のストリームに対してターゲットQP22を達成するために、base_qpが32である場合、-10というqp_deltaが設定され得る。空間動きベクトル予測は、タイル内のみに制限されるように設定され得る(ブロック1016)。すなわち、例示的な実施形態では、動きベクトルは、タイル境界を越えることはできない(すなわち、タイル内予測のみが可能であり、タイル境界を越えるインター予測またはコンテキスト選択は不可能である)。これは、動きベクトルが、タイル内のブロックの動き補償補間中に任意の同一位置のタイルの境界外のサンプルが読み取られないように設定されることを意味する。エンコーダがフレームの特定の領域に関して特定のストリームを符号化するためにqp_delta情報を使用するように、エンコーダ用のROIグリッドが設定され得る(ブロック1018)。さらに、TMVPはまた、上述の例示的なPE設定プロセスにおいて無効にされ得る(ブロック1020)。
例示的なPE設定プロセスは、一実施形態におけるBIE設定プロセスにほぼ類似しており、GOPサイズに応じてすべての「位相」ストリームに対して実行され得ることに留意されたい。さらに、一定のパラメータを使用するBIE設定プロセス800Aと同様に、PE設定プロセスの追加のまたは代替の実施形態は、図10Aの流れ図に例示されているパラメータに加えてかつ/またはその代わりに他のパラメータを含み得る。
図10Bは、本発明の実施形態による、例示的なPE実装形態におけるブロック、ステップ、および/または動作を例示する流れ図である。一般に、エンコーダは、PEベースのタイルコード化中にいくつかの判定を実現して、各位相符号化ストリームの特定のフレームロケーションでのみXフレームを生成するように設定され得る。ブロック1034において、符号化のためにビデオ入力1032が受信される。ブロック1040において、タイル化エンコーダは、上記のように、周期(ブロック1036)および位相(ブロック1038)に基づいて、PEプロセスを実装するように設定される。ストリームごとに、最初のフレームが、Iフレームとして符号化される(ブロック1042)。その後、フレーム単位で適切なコーディング判定を実現するために、反復プロセスが実装され得、反復プロセスは、ビデオシーケンスがその終端に到達したかどうかに関する判定から開始する(ブロック1044)。終端に到達していない場合(すなわち、処理を必要とするフレームがビデオシーケンス内に残っている場合)、フレームインデックス(i)がインクリメントされ(ブロック1046)、次のフレームが取得され、そのフレームがi番目のフレームとして示される(ブロック1048)。モジュラ関係{i Mod (周期)=位相}が満たされているかどうかが判定される。満たされている場合、ブロック1054、1056、および1058に記載のように、フレームは、Xフレームとして符号化される。満たされてない場合、フレームは、通常のPフレームとして符号化される(ブロック1052)。その後、プロセスの流れは戻り、ビデオストリームのすべてのフレームが処理されたかどうかを判定する(ブロック1044)。処理された場合、プロセスの流れは進み、ビデオストリームの符号化を確定し(ブロック1060)、ブロック1062に記載のように、ビデオストリームが、下流エンティティ(たとえば、パッケージ化システム)にPEタイル化ビットストリームとして提供され得る。
前述のように、PEベースのタイル符号化方式は、360°ビデオ配信中の段階的リフレッシュアニーリングプロセスを容易にし、これについては、以下でさらに詳しく説明する。位相符号化の一実施形態は、プレイアウト中にも使用され得、異なる品質のタイルを組み合わせるために、サーバ側またはクライアント側で実行されるステッチャが使用され得る。したがって、再生されているビデオのすべてのフレームにおいて、各タイルは、タイルが取られたビデオストリームのQP値、ターゲットビットレート、または他の指標に対応し得る現在の品質を有する。帯域幅が十分に大きい場合、またはユーザが頭部を動かしてビューポートが変更された場合、いくつかのタイル(たとえば、新しいビューポート上のタイル)の品質をアップグレードする(たとえば、QPを下げる)ことが望ましい。さらに、デコーダ側のバッファの使用量を低減することによってレイテンシを低減するために、本発明の一実施形態では、ビューポート全体が一度にアップグレードされ得るのではなく、ビューポートを段階的リフレッシュによって段階的にアップグレードし、すべてのフレームで少数のタイルのみをアップグレードし、デコーダのバッファを小さく保ち、これによりレイテンシを低減する。以下でさらに詳細に説明するように、例示的な帯域幅アニーリング装置は、帯域幅、ビューポート、および/または現在のバッファ使用率に基づいて、アップグレードするタイルを決定するためのプロセスをいつでも実現するように設定され得る。さらに、このようなプロセスは、タイルがアップグレードされるべき品質レベル(すなわち、どのQPか)を決定するように設定され得る。
たとえば、プレイアウト中、(以下でさらに詳細に説明する)タイル選択装置がi番目のフレームでタイルTを品質QP=qにアップグレードすることを決定すると仮定する。この決定は、タイル/フレームステッチャモジュールへの制御入力として提供され得、タイル/フレームステッチャモジュールは、位相符号化を使用して品質QP=base_qp+delta_qp=qで符号化されたビデオストリームのi番目のフレームから、タイルTを検索、受信、または別の方法で取得し、位相は、モジュラ関係{位相=i Mod (周期)}によって決定される。次いで、次回タイル選択プロセスがこのタイルの品質を変更することを決定するまで、タイルTは、同じストリーム(すなわち、品質QP=qおよび同じ位相で位相符号化されたストリーム)から取られる。したがって、アップグレード中にタイルの段階的リフレッシュを実行する能力を超えたPE方式のさらなる利点は、より良いビデオ品質であることが理解されよう。全体として、位相符号化は、Xフレームが位相なしで置換されることによりドリフトが発生し、ピーク信号対雑音(PSNR:peak signal-to-noise)値が低くなり、それによりGOPの残りの部分のQoEストリームが低くなる可能性があるBIE方式よりも優れたQoEを提供する。前述のように、位相符号化の潜在的な欠点は、複数のストリームが必要になり、これにより、符号化処理のオーバーヘッドおよび記憶空間がかなり大きなものなる可能性があることである。
PE方式またはBIE方式のいずれかを使用してタイル符号化ビットストリームをステッチする方法に関する例示的な実施形態を、以下に説明する。前述のように、タイルステッチングの実施形態は、ストリーム配信段階中にサーバで、またはプレイアウトのためにクライアント側で実装され得る。一般に、タイルをステッチするための例示的な実施形態は、(たとえば、異なるQP、ターゲットビットレート、または他の指標に基づいて)異なる品質のビットストリームを利用すること、ならびに、タイルが選択され得るビットストリームの中で、ビデオピクチャに関連する様々なパラメータデータ、たとえば、ビデオパラメータセット(VPS:Video Parameter Set)、シーケンスパラメータセット(SPS:Sequence Parameter Set)、ピクチャパラメータセット(PPS:Picture Parameter Set)、補足強化情報(SEI:Supplemental Enhancement Information)などに対する互換性があることを保証することを含む。一般に、タイル構造は、好ましくは、ステッチングを容易にするために経時的に一定しているべきであり、これは、本発明のエンコーダによって実行されるタイル符号化プロセスに関連する。ビットストリームステッチャモジュールは、異なるタイル符号化ストリームからのタイルのリストを含む入力に応答して動作し、異なるタイル符号化ストリームを組み合わせて新しい出力ビットストリームを生成することができ、新しい出力ビットストリームでは、ビューポートに近いタイルがビューポートから離れたタイルと比較してより高い品質を有する。さらに、本発明の教示による、タイルの組合せおよびストリームの多重化を実行するための例示的な実施形態は、出力ストリームの生成が、MPEG HEVC/ITU-T/ISO23008パート2/H.265仕様などの知られているコーデック規格、ならびにAV1、H.266、VVCなどの新興の規格に依然として準拠するように設定され得る。
BIEコード化ストリームをステッチする場合、(たとえば、ユーザの注視または帯域幅割当に基づいて何らかの制御入力が提供されるまで、)スプライシングに、通常のストリームからのタイルがデフォルトで使用され得る。BIEコード化ストリームからタイルが取られる唯一のインスタンスは、ビューポートが変更された場合(したがって、GOPの途中に適合し得るPスライスヘッダを有するフレームであるXフレームを必要とするが、タイルがイントラ符号化されるため、新しいビューポートが提示され得る)、または帯域幅アニーリングプロセスがタイルの品質をアップグレードすることを決定する場合(この場合、Pスライスヘッダを有するブロックイントラフレームは、アップグレードされた、より高品質のタイルを含む)のどちらかである。
図13Aは、本発明のいくつかの例示的な実施形態による、BIEコード化タイルストリームを含む例示的なタイルステッチング方式1300Aの様々なブロック、ステップ、および/または動作を例示する。ブロック1302において、BIEビットストリームステッチャは、異なるQPの入力ビットストリームを受信し、第1のセットは、通常のタイルコード化ストリームを含み、第2のセットは、BIEタイルコード化ストリームを含む。上記のように、例示的な実施形態におけるストリームは、動きが制約されており、各フレームNについて、他の任意のフレームNにおけるベースQPと同じbase_qpを有する。タイル選択モジュールは、異なるQPを有するタイルのリストを提供し(ブロック1306)、リストは、各タイルの説明およびパラメータ情報、およびタイルが検索または取得されるべき特定のQPビットストリームに関する入力全体の一部を形成する(ブロック1304)。ブロック1308に記載のように、タイルステッチングプロセスは、タイル単位で実現され得る。ビューポートおよび/またはタイルQPが変更された場合(ブロック1310)、タイルは適切なQPを有するBIEコード化ストリームから取られ、フレームにステッチされる(ブロック1312)。それ以外の場合、タイルは通常のタイル符号化ストリームから取られ、それに応じてステッチされる(ブロック1314)。すべてのタイルが(所定のグリッド配列で)フレームにステッチされた後、タイルの異なる品質を有するステッチされたフレームが、出力として提供され得る(ブロック1316)。処理(たとえば、符号化、ステッチング)に対してさらなるビデオフレームが残っている場合、プロセスの流れは継続し得る。
例示として、(1)より低品質の通常のストリーム(たとえば、QP設定値30)、(2)より高品質の通常のストリーム(たとえば、QP設定値22)、および(3)より高品質のBIE(全イントラ)ストリームという少なくとも3つのストリームがある、ブロックイントラストリームステッチングのシナリオについて考察する。大まかに言えば、ビューポートが変更されると、いくつかのタイルの品質が向上し得る。ステッチングは、ブロック1312で行われ、たとえば、前のピクチャにおいてストリーム(1)から取られた位置Aのタイルが、ここではストリーム(3)から取られることを意味する。次のピクチャでは、タイルがまだビューポート内にある場合、位置Aのタイルは、ストリーム(2)から取られるべきである。タイルがもはやビューポート内にない場合、位置Aのタイルは、ストリーム(1)から取られ得る。より具体的には、ステッチングは、さらに注視ベクトル情報に依存し得る。言い換えると、タイル選択に使用される(以下でさらに詳細に説明する)注視対重み決定方式では、ステッチングは、位置Aのタイルがビューポートにあるかどうかだけでなく、タイルがどこに位置しているかに依存する。したがって、本発明の例示的な実施形態において、ビューポート内のタイルは、それらが位置する場所に応じて、タイルが直線視線からどれだけ離れているかに基づいてアップグレードまたはダウングレードされ得ることを理解されたい。
同様の方法で、図13Bに、PEベースのタイル化ストリームを含む例示的なタイルステッチング方式1300Bを例示する。PEビットストリームステッチャは、それぞれが複数の位相符号化ビットストリームに符号化された、異なるQPの入力ビットストリームを受信するように動作する(ブロック1332)。タイル選択モジュールは、異なるQPを有するタイルのリストを提供し(ブロック1336)、リストは、各タイルの説明およびパラメータ情報と、タイルを検索または取得すべき特定のQPビットストリームとに関する入力全体の一部を形成する(ブロック1334)。ブロック1338に記載のように、タイルステッチングプロセスは、BIEタイルステッチングと同様に、タイル単位で実現され得る。ビューポートおよび/またはタイルQPが変更され、それにより現在のタイルの品質を変更する必要がある場合(ブロック1340)、タイルは、位相フレームモジュラ関係に基づいて適切なQPを有するPEコード化ストリームから取られ、フレームにステッチされる(ブロック1342)。たとえば、フレームIのタイルのQPがQP=qに変更された場合、タイルは、位相={i Mod (周期)}かつQP=qのストリームから取られ、タイルグリッドの適切なロケーションでステッチされる。それ以外の場合、タイルは、前のフレームで取られたものと同じビットストリームから取られ、それに応じてステッチされる(ブロック1344)。すべてのタイルが(所定のグリッド配列で)フレームにステッチされた後、タイルの異なる品質を有するステッチされたフレームが、出力として提供され得る(ブロック1346)。さらに、処理(たとえば、符号化、ステッチング)に対してさらなるビデオフレームが残っている場合、プロセスの流れは継続し得る。
BIEコード化ビットストリームまたはPEコード化ビットストリームのどちらからのタイルがステッチされるかに関わらず、ステッチングの例示的な実施形態は、前述のような他のパラメータ情報に加えて、互換性のあるスライスヘッダを有する異なるストリームからタイルを取ることを含み得る。一般に、互換性および準拠性を保証するために、スライスタイプ(すなわち、I/P/Bスライス)、スライスQP、およびCABAC復号プロセスに影響を与え得る他のフィールドまたはパラメータが監視され得る。さらに、図13A/13Bに記載の例示的な実施形態などのいくつかの実施形態は、以前に復号されたピクチャのみを使用してインター予測が行われることを必要とする場合がある。
図13Cを参照すると、本発明の例示的な実施形態による、例示的なタイルステッチング/スプライシング方式に関する追加のブロック、ステップ、および/または動作を例示する流れ図が示されている。ブロック1362において、(ステッチされるべき)現在のフレームについて、異なるQPのタイルが入力として取得される。タイル選択プロセスに基づいて選択された(BIEストリームまたはPEストリームのいずれかからの)タイルのデータが、メモリにコピーされる(ブロック1364)。ブロック1366において、ヘッダフィールド、オフセットフィールドなどを含み得るプロトタイプスライスヘッダで、スプライシングプロセスが開始する(ブロック1368)。タイルインデックス(i)の場合、タイルサイズから、entry_point_offset[i]が決定され得る(ブロック1368)。entry_point_offset[i]の最大値に必要なビットが決定される(ブロック1370)。スライスヘッダは、以前に決定されたすべてのタイルインデックスの最大オフセット値に基づいて、新しいエントリポイントオフセット(EPO:Entry Point Offset)の長さで調整され得る(ブロック1372)。ブロック1374において、EPOフィールドがスライスヘッダに書き込まれる。その後、タイルは、スライスヘッダの後に共に連結され(ブロック1376)、それにより、ステッチされたフレームの出力ビットストリームを生成する(ブロック1378)。
タイルをスプライスするために、タイル選択プロセスに対応した特定のソースビットストリームからタイルを検索する必要があることが、当業者には理解されよう。効率的な検索を容易にするために、スプライシングの一実施形態は、タイルに対応する解析済みファイルのより迅速な参照を可能にするメモリマップされたタイルポインタキャッシュを提供することを含み得、ファイルフォーマットは、RAMに解析されるのではなく、メモリマッピングされるように最適化される。例示的なスプライシングの実施形態における、例示的なファイルフォーマットを以下に示す。
図14を参照すると、本発明の一実施形態による、異なる品質またはQPを有するコード化ビットストリームから選択およびスプライスされたタイルを含む例示的な360°ビデオフレーム1400が示されている。例示として、ビデオフレーム1400は、4Kビデオ入力の128タイル(16列×8行)から形成され、ラップされていないフォーマットで示されており(すなわち、3D球形空間に投影されない)、フィールド1402は、ビューポートまたは注視ベクトルのロケーションに基づくフレーム1400のROIに対応し得る。本明細書の教示によれば、ROI1402は、高品質のタイル(すなわち、低いQP、たとえばQP-16を有する105.6Mbpsでコード化ビットストリームから選択され、ステッチングプロセスで連結されるタイル)をスプライスすることから形成され得る。ROI1402に近接して/隣接して配置された領域またはフィールドは、中程度の品質のタイルを有し得る(たとえば、フィールド1404)。一方、領域1406および1408によって例示されるように、ROI1402から遠位に配置されたフィールドまたは領域、たとえば、ビューポートからより遠いものは、より低品質のタイルから形成され得る。
注視ベースのタイル選択制御を容易にするために、本発明の追加の実施形態は、ユーザが360°没入型ビデオプログラム内のどこを鑑賞しているか(すなわち、ユーザのビューポート)監視し、ユーザの注視に基づいて適切なタイル重みを決定することを含む。一般に、注視ベクトル(GV:gaze vector)は、ユーザ/クライアントデバイスが、360°ビデオを表示している3D没入型空間における注視方向、たとえばヘッドセットが向けられている方向を規定することによって返され得る。さらなる実施形態では、同様の目的で、ユーザの眼球の動きが追跡され得る。以下で理解されるように、タイル化フレームのタイルは、3D表示環境においてフレームがどのようにマッピングされているかに基づいた(ユーザの注視に依存しない)方向ベクトルも有する。タイルベクトルと注視ベクトルのドット積(スカラ積または内積とも呼ばれる)を算出して、注視方向とフレームの任意のタイルの中央の方向との間の分離角を決定することができ、分離角は、対応するタイル重みを決定するための重み付け関数モジュールに提供され得る。
図15Aおよび図15Bは、本発明の1つまたは複数の実施形態による、本開示の追加の流れ図のブロック、ステップ、および/または動作の有無に関わらず1つまたは複数の構成で(再)結合され得る、最適化されたタイル選択を容易にするための注視制御方式の様々なブロック、ステップ、および/または動作を例示する流れ図である。プロセス1500Aは、360°没入型ビデオ資産をユーザに表示するように動作するクライアントデバイスから注視ベクトルを受信することを含み、各ビデオフレームは、ユーザが没入する、ユーザによって鑑賞される3次元(3D)表示環境に投影されたタイルの配列を含み、注視ベクトルは、ユーザが任意の特定の時間に鑑賞している3D表示環境における注視方向を規定する(ブロック1502)。一実施形態では、注視ベクトル情報は、表示環境に関連付けられ得る3Dデカルト座標系内の(x,y,z)情報を含み得る。別の実施形態では、注視ベクトル情報は、正距円筒図法投影マッピングに基づく3D球座標系内の(ρ、θ、φ)情報を含み得る。別の実施形態では、3D注視ベクトルは、(単位長の方向ベクトルを取得するために)正規化され得る。したがって、GV情報は、特定の実装形態で使用される幾何学的モデリング、投影マッピング、計算方法論などに応じていくつかの方法で提供され得ることが、当業者には理解されよう。ブロック1504において、注視ベクトルと、3D表示環境におけるタイルの配列にそれぞれ対応する各タイルロケーションに関連付けられた方向ベクトルとの間の分離角がどれだけかについての決定が行われ得、これもまた、特定の幾何学的モデリング、投影マッピング、計算方法論などに依存し得る。ブロック1506において、クライアントデバイスに配信されるビデオフレームを組み立てるために360°没入型ビデオ資産の異なるビットレート品質(QP)のタイルを選択する際に使用する、タイルの配列に対応した複数のタイル重みが、分離角に応じて決定される。一般に、注視ベクトルに近い、もしくは注視ベクトルから任意の角距離内にあるタイル(または、より広義には、タイルの位置もしくはロケーション)には、より高い値が代入され得、一方、注視ベクトルとは真逆(すなわち、180°またはπラジアン)のタイルには、最も低い重み値が代入され得、その間にある(水平方向と垂直方向の両方の)残りのタイルは、任意の好適な数学的関係(たとえば、線形、2次方程式など)に従って最大値から最小値の間で変化する重み値を受け取る。
プロセス1500Bは、例示的な実施形態において注視ベースの制御を実現することに関するさらなる詳細を示す。ブロック1522において、注視ベクトルと、360°没入型ビデオ資産の2Dビデオフレームの好適な3D空間投影におけるタイルロケーションに対応する方向ベクトルとの間の分離角の余弦の関数として、タイル重みが決定され得る。ブロック1524において、タイル重みは、動的帯域幅割当入力と共に、タイル選択および帯域幅アニーリングプロセスへの入力として提供され得、これについては、本特許出願の他の箇所でさらに説明する。
例示的な一実施形態では、注視ベクトルに対してタイルがどのロケーションにあるかに応じて、重みに対応するそのタイルロケーションにどの程度の帯域幅を割り当てるかの決定が行われる。注視ベクトルをベクトル
、タイル方向ベクトルをベクトル
で示す場合、それらのドット積は、次のように決定され得る。
正規化の際、すなわち、
の場合、|a|=1である。同様に、
を代入すると、|b|=1である。したがって、正規化することによって、前述の関係は次のように単純化される。
本発明の一実施形態は、重みを決定するためにcos(θ)をθにマッピングして戻すのではなく、次のように、cos(θ)から重みにマッピングするための数学関数を規定することを含む。x=cos(θ)であり、x≧0の場合、f(x)={x+1}、x<0の場合、[α{x+1}]であり、式中、α=スケーリング係数、たとえば、0.1である。したがって、注視ベクトルとタイル方向ベクトルの間の分離角が0°である場合、cos(θ)=1であり、f(x)=2である。同様に、注視ベクトルから60°または300°離れているタイルの場合、cos(θ)=0.5であり、対応するf(x)値は1.5である。3Dフレームの正距円筒図法投影では、ユーザが見ている場所とは正反対の角度は180°であり、cos(θ)=-1.0が得られ、その結果、スケーリング係数に関わらず、重みf(x)値は0になる。したがって、例示的な実施形態は、フレーム内の注視方向に関連してタイル品質がどの程度滑らかにまたは急速に変化し得るかに基づいて、好適なスケーリング係数を提供し得る。
図16Aは、ユーザの視線方向とタイル位置との間の分離角の決定を容易にするための例示的な円形ユニットの幾何学的配置1600Aを示す。ユーザロケーション1602は、3D球形空間の円形ユニットの断面の中心として設定される。第1の参照軸(たとえば、X軸)1604に沿ってユーザの注視を参照することによって、タイルロケーションの異なる角変位が、上記のように決定され得る。例示として、参照番号1606および1608は、注視方向1604から30°および60°離れている2つのタイル方向ベクトルを指す。一般に、注視方向1604に対して+90°またはそのあたり(たとえば、参照番号1610A/1610B)に近づくタイルロケーションは、ユーザの中遠方周辺視野を暗示し、このような領域およびそれを超える領域内のタイルは、帯域幅のより速い削減(すなわち、より低い品質)が割り当てられ得るように重み付けられたスケーリング係数を利用でき得る。方向ベクトルロケーション1614では、タイルは、注視方向1604から+180°離れている。
例示的な実施形態では、実際の角変位の代わりに、異なるロケーションに対応する余弦値が、注視方向に関して提供され得る。たとえば、タイルの方向ベクトルが注視ベクトルから90°または270°である場合、x=0.0が重み付け関数に入力されると、重みは1.0になる。同様に、タイル方向ベクトルが330°離れている場合、x=0.866が重み付け関数に提供され、その結果、重み値は1.866になる。さらなる例として、タイル方向ベクトルが120°離れている場合、x=-0.5が重み付け関数に提供され、その結果、(α=0.1と仮定すると)重み値は0.05になり、これは、タイル方向が注視ベクトルから240°離れている場合も同様である。
さらに、行と列によるタイルの識別を容易にするために、注視ベクトル情報とタイル方向ベクトル情報はどちらも、メディア準備中にタイル符号化で使用されるタイルグリッドに対する適切なタイル座標情報に変換され得、これらは、重み情報と共にタイル選択および帯域幅アニーリングプロセスに入力され得る。タイル座標情報の決定は、例示的な実施形態で使用される投影マッピングに依存することが、当業者には理解されよう。図16Bは、タイルが表面を形成する球形の表示環境1600Bをもたらす正距円筒図法投影マッピング方式を示す。例示的な一実装形態は、北極1605を{0,0,1}の方向に、南極1607を反対方向に配置しており、一方、タイル化フレームの左端と右端は{0,0,1}の方向にあり、画像(すなわち、タイル化フレーム)の中心は{0,0,-1}の方向にある。均一なタイルサイズを含む例示的な実装形態では、本発明の一実施形態は、方向ベクトル1611を有するタイル1609のロケーションを決定するための装置および方法を提供し、この装置および方法は、n
x(タイル列の数)とn
y(タイル行の数)の所与のグリッド配置についてのt
x(タイルの列インデックス)とt
y(タイルの行インデックス)を、以下、
のように計算するように設定され得、式中、θは極角、φは球座標系の方位角である。
符号化が不均一なタイルサイズを有する場合、前述の方程式は、たとえば、個々のタイルの画素面積などに基づいて修正され得る。例示として、(i)をタイル列iの左端のタイルインデックス、(j)をタイル行jの上端のタイルインデックスとして使用し、wは画素列の数であり、hは画素行の数であり、本発明の実施形態は、以下、
を決定するように設定され得、例示的なコーディングユニットまたはブロックサイズ(たとえば、64画素)の使用に関して、x
iとy
jはどちらも、丸める(すなわち、小数部分を切り捨てる)ための「フロア」演算子を含む。
図16Cは、本発明の1つまたは複数の実施形態における例示的な360°没入型ビデオ鑑賞環境1600Cを例示する。加入者宅1640に関連付けられた宅内ノードまたはゲートウェイ(GW)1642は、没入型メディアコンテンツを提供するための配信パイプ1644によってサーブされる。一構成では、このような没入型メディアコンテンツは、加入者/ユーザによって装着される好適なヘッドセット内で鑑賞される3Dパノラマ仮想空間に提示され得る。例示的なUEは、たとえば、1つまたは複数のゲームアプリケーションまたはメディアアプリケーションを実行してユーザの頭部1628にまたはその上に取り付けられた表示デバイス1636などの1つまたは複数のデバイスに好適な信号を提供する、ゲームコンソール、ラップトップコンピュータ、またはスマートフォンなどの、GW1642によってサーブされるCPE1646を含み得る。このようなデバイスのさらなる例には、ユーザを取り巻く没入型鑑賞空間を表示または実現することができる、バイザー、ゴーグル、有線/無線ヘッドギアまたはヘルメット、マスクなどが含まれ得る。例示的な表示デバイス構成では、頭部の追跡を容易にするために、すなわち、ユーザ1628が自分の頭部を動かす、それに応じて、ユーザによって注視されている空間(すなわち、ビューポート)の一部と共に、シミュレートされた空間の周りの視野が移動するようにするための、ジャイロスコープ、加速度計、および磁力計などの追加の計器が存在し得る。したがって、頭部追跡ヘッドセットでは、ユーザが上下を向く、頭部を左右に動かす、または頭部に角度を付けるとき、視円錐または視野と同様にユーザのビューポートも動き回る。例示的なシステムは、ユーザの頭部を、ピッチ、ヨー、およびロールとしても知られるX軸、Y軸、およびZ軸を用いてプロットして、頭部の動きを測定することができる、いわゆる6自由度(6DoF:six degrees of freedom)構成を含み得、これは、シミュレートされた3Dパノラマ鑑賞空間内でユーザの視点を追跡するために使用され得る。
例示として、CPE1646は、1つまたは複数のプロセッサ1656と、揮発性および不揮発性/永続メモリ1654と、入力/出力(I/O)インターフェース1660(たとえば、タッチスクリーン、ゲームコントローラ、ハンド追跡グローブなど)と、ヘッドマウントディスプレイ(HMD)1636を装着しているユーザ1628のために3D仮想鑑賞空間または「スクリーン」1620を実現することができる1つまたは複数の360度メディア/ゲームアプリケーション1638とを含むプラットフォーム1648として具現化され得る。例示的な一構成では、HMD1636は、無線インターフェース1642を介してCPE1646に無線で結合され得る。複数のデコーダバッファ1645は、ユーザ1628にとって利用可能な1つまたは複数の360°没入型ビデオコンテンツチャネルに対応する例示的なCPEプラットフォーム1646/1648の一部として提供され得る。
追加の3Dメディア対応CPE1634(たとえば、タブレット、ファブレット、またはスマートフォンなど)も、別個にまたは任意選択で提供され得る。HMD1636と連動して共にまたは別個に動作する例示的なCPE装置1646/1634は、3D仮想鑑賞空間1620を実現するように動作し得、ビューポート3D仮想鑑賞空間1620は、ユーザ1628が3D環境内で規定された垂直面、水平面、または両方の面のうちのいずれかで自分の視点をフル360°で動かすことができ、それに応じてビューポート1624が変化する、没入型環境である。追加のまたは代替の構成では、HMD1636と連動して動作するCPE装置1646/1634は、いずれかの軸に沿って360°未満であるという点で部分的に没入型であり得る3D仮想鑑賞空間1620を実現するように動作し得る。
動きおよび注視検出モジュール1662は、加入者1628が鑑賞空間1620内で自分の注視を移動させるとき、3D仮想鑑賞空間1620に対するユーザ/加入者1628の視点または注視方向の動きを検出し、好適な注視ベクトル出力をサービングノードに提供するように動作する。一実施形態では、タイル重み付けモジュールは、360°ビデオ最適化ノード(たとえば、図2のノード216)で動作して、注視ベクトル情報に基づいて適切なタイル重みを決定するように設定され得る。別の実施形態では、タイル重み付けは、例示的な装置1646/1634および/またはHMD1636でローカルに実行され得る。
図17Aは、本発明の例示的な実施形態による、例示的な360°没入型ビデオ最適化プロセスに関する追加のブロック、ステップ、および/または動作を例示する流れ図である。具体的には、プロセス1700Aは、一実装形態における注視/動き検出に関するクライアント側の処理を例示する。ブロック1702において、ユーザが360°ビデオセッションを開始すると、クライアントデバイスは、要求された360°ビデオ資産に関する要求を、バックオフィスノード(たとえば、図2のノード238)に送る(ブロック1704)。ブロック1706において、バックオフィスノードは、要求された資産に対するURLによって応答し、クライアントにビデオセッションIDを提供する。これに応答して、クライアントデバイスは、URLで識別されたロケーションから、符号化されたビデオ資産を、ストリーミングを介して受信することを開始し、クライアントデバイスのデバイスプレーヤが、符号化されたビデオ資産を復号し、3D没入型環境でレンダリングする(ブロック1710)。また、クライアントデバイスは、進行中の360°ビデオセッションに関連してクライアントデバイスを動作させているユーザの頭部/眼の動きを監視または追跡を開始し得る(ブロック1708)。動きが検出されたとの検出に応答して(ブロック1712)、現在のビューポートに関する注視ベクトル情報が、360°ビデオ最適化ノード(たとえば、図2のノード216)に提供され、360°ビデオ最適化ノードは、帯域幅アニーリングおよびタイル選択プロセスの際に、注視ベクトル情報を他の情報と組み合わせて利用する(ブロック1714)。一実施形態では、決定ブロック1712および1716を含む反復ループに示されるように、注視ベクトル情報は、ユーザがビデオの再生を停止するまで、かつ/または(たとえば、一定期間にわたって)頭部/眼の動きが検出されなくなるまで生成され得る。一実施形態では、注視ベクトルは、所定の頻度(たとえば、毎秒40回)で生成され得る。以下で理解されるように、すべての注視ベクトルが、例示的な帯域幅アニーリングおよびタイル選択プロセスで利用され得るわけではなく、タイル品質の変更、たとえば、アップグレードまたはダウングレードが必要な場合にのみトリガされるように設定され得る。ユーザがビデオ資産の再生を停止すると、配信サーバに対する適切なセッション終了要求/メッセージが生成され得(ブロック1718)、その後すぐに、プロセスの流れが終了し得る(ブロック1720)。
以下に、例示的な実装形態における、設定可能な時間ウィンドウにわたってクライアントデバイスによって提供された注視ベクトルのリストを示す。
正規化されていないフォーマットでは、デカルト座標系における例示的なGVは、[3,5,1]、[10,4,1]などの(x,y,z)値を含み得る。正規化された球座標系では、GV値は、たとえば(59.04°,80.27°)などの角度のセットを含み得、r=半径は正規化され、θ=極傾斜、φ=方位角である。フォーマットに関わらず、注視ベクトル情報は、設定可能な頻度、時間期間などで提供または別の方法で取得され得るが、すべての注視ベクトルがタイル重み決定プロセスで利用される必要があるとは限らない場合がある。たとえば、特定の実施形態に関して前述したように、タイル重みは、タイル選択および帯域幅アニーリングプロセスをトリガしたことに応答してのみ、決定および利用され得る。したがって、このような実施形態では、未使用の注視ベクトル情報は定期的に破棄され得る。
図17Bは、本発明の例示的な実施形態による、例示的な360°没入型ビデオ最適化プロセスのさらなる態様に関する追加のブロック、ステップ、および/または動作を例示する流れ図である。具体的には、プロセス1700Bは、例示的な実装形態における、特に、注視/動き検出に基づくタイル重み決定、および帯域幅アニーリングおよびタイル選択におけるタイル重みの利用に関するサーバ側の処理を示す。ブロック1742において、ビデオバックオフィスノードが、セッションを開始することを求めるユーザ要求を受信すると、360°ビデオ最適化システムに対するセッションセットアップ要求が生成され得る(ブロック1744)。バックオフィスは、適切な情報、たとえばセッションID、セッションのマニフェストURLなどを取得したことに応答して、要求されたビデオ資産を開始するために必要な情報をクライアントデバイスに提供する(ブロック1746)。タイル選択機能を備えた帯域幅アニーリングおよびQoE管理モジュール(いくつかの実施形態ではBWA-TSモジュールとも呼ばれる)は、すべての符号化表現において、要求されたビデオ資産に関連するマニフェストを取得、検索、読込み、および/または処理するように動作する(ブロック1748)。ブロック1750において、BWA-TSモジュールはまた、クライアントデバイスのビデオセッションに関する動的帯域幅通知を、配信ネットワークインフラストラクチャ(たとえば、例示的な実施形態ではDSLAM/CMTS)から受信するように設定され得る。ブロック1752において、BWA-TSモジュールは、タイル符号化ストリームまたは表現から特定のタイルを抽出するように動作する。ブロック1754において、BWA-TSモジュールは、360°没入型ビデオセッション用の帯域幅割当ならびに任意の注視ベクトル情報に関する制御入力を受信するように動作する(ブロック1756、1758)。前述のように、注視ベクトル入力が最初に利用可能ではない場合、コンテンツタイプ、コンテンツプロバイダポリシー、クライアントデバイスのタイプおよび能力などに基づいて設定可能なデフォルト値が利用され得る。BWA-TS機能は、制御入力に応答して、帯域幅およびタイル重みに基づいて選択されたタイルのセットを生成するか、または別の方法で示すように動作する(ブロック1754)。(いくつかの実施形態ではTC-SGモジュールとも呼ばれる)タイル結合/ステッチングおよびストリーム生成機能は、選択されたタイルセットを受信するように動作し(ブロック1760)、選択されたタイルセットは、上記のように連結され得る。したがって、一実装形態では、ビデオスライスヘッダは、選択されたタイルと連結され、適用可能なエントリポイントオフセットを含むように適切に修正される(ブロック1762)。タイルステッチングの目的で、一定の動作が、ネットワーク抽象化層(NAL)アクセスユニットレベルで実行され得、コード化されたビデオデータは、タイル化階層内の複数のNALユニットに編成される。NALアクセスユニットは、事実上、整数のバイトを含むパケットであり、バイナリオーディオ/ビデオフローによって形成され、かつビットストリーム操作アクセスを容易にするために圧縮された、エレメンタリストリームの論理サブ構造として扱われ得る。一実装形態では、NALアクセスユニットは、層圧縮を含む同期システムに属することができる最小のデータ編成であり、ビデオパラメータ情報間の一貫性(たとえば、空間/時間冗長性など)が維持されることを考慮に入れて、MPEG復号動作が行われ得る。
引き続き図17Bを参照すると、ブロック1764において、結合されたタイルを含む1つのフレーム/ピクチャのデータのセグメントがTC-SGモジュールに提供され、フレーム/ピクチャは、好適なコンテナフォーマット、たとえば、MPEG-2トランスポートストリームコンテナフォーマット(M2TS、またMP2TSと呼ばれることもある)、MPEG4パート14(MP4)コンテナフォーマット、またはISOベースメディアファイルフォーマット(ISOBMFF)コンテナフォーマットなどでコンテナ化され得る(ブロック1766)。配信サーバは、多重化されたピクチャ/フレームを好適なネットワークを介してクライアントデバイスに配信するように設定され得る(ブロック1768)。図17Bの実施形態に記載のように、プロセス1700BのBWA-TS、TC-SG、および配信サービスを含む動作は、配信通信ソケットが閉鎖またはタイムアウトするまで継続して行われ得る(ブロック1770)。その後、クライアントデバイスとの360°ビデオセッションは、終了され得る(ブロック1772)。
例示的な実施形態では、例示的な360°没入型ビデオセッションに対する帯域幅割当は、19Mb/秒であり得る。ビデオは、128タイルグリッドを使用してフル360ビデオで符号化され得、最高のQP値16での105.6Mb/秒から、最低のQP値30での7Mb/秒までの、異なるビットレートをカバーする。より高品質のタイルは、ユーザの直接視野でのターゲットとされる。タイルの品質は、ユーザの直接視野からの距離に比例して低下する(すなわち、QP値が上昇する)。BWA-TSの機能は、360ビデオセッションの全体的な帯域幅を超えないことを保証する。タイルの選択は、各タイルのビットレートに基づく。ユーザがシーンの中で曇り空を見上げているときの例では、そのビューポートに提供されるタイルのほとんどは、比較的高品質である。このようなシナリオで見上げているときのタイルのコンテンツは比較的静的である(すなわち、動きが非常に少ない)ので、エンコーダによって動きの少ないエリアに割り当てられるビットはそれほど多くない。これにより、QP値16での最高品質のビデオ符号化によるタイルを表示できるようになる。360°ビデオに対する帯域幅割当が(たとえば、19Mb/秒から7Mb/秒に)減少すると、タイルの品質も低下する。前述の例では、直接視野内の最高品質のタイルは、ビットレートが22.4Mb/秒、QP値が22であり得る。
図18Aは、16×8配列のタイルを含む、タイルで重み付けされたフレーム1800Aを示し、例示的な実装形態において、各タイルは、クライアントデバイスによって提供された{0.783,0.396,-0.481}の注視ベクトルに基づく重みが割り当てられている。参照番号1802は、注視に関連付けられたビューポートを指し、タイルには、本発明の教示に従って最高値が与えられている。ビューポートが変化するにつれて、最高値を有するタイルの領域も同時に変化することが、当業者には理解されよう。したがって、正距円筒図法投影に基づく360°没入型ビデオ表示空間では、最高値を有するタイルの領域は、たとえば、ユーザが真上もしくは真下を注視している場合は極域に対して、またユーザがピクチャの真ん中を注視している場合は赤道に対して移動する。例示として、図18Cは、3D没入型表示または鑑賞空間1800Cを示しており、ユーザが真上を見ているとき、最高品質のタイルは北極領域1852の近くにあり、徐々に低品質となるタイルが没入型空間の残りの部分を形成し、最低品質のタイルは南極領域1854の近くにある。同様に、図18Dは、3D没入型表示または鑑賞空間1800Dを示しており、ユーザが真下を見ているとき、より高品質のタイルが南極領域1854の近くにあり、徐々に低品質となるタイルが北極1852に向かって広がっている。
図18Bは、例示的な実施形態におけるデバイスフレームバッファ1800Bを示す。バッファ内の3つの連続するフレーム1822A~1822Cが示されており、それぞれ、Pスライスヘッダを有するが、ヘッドセットビューに基づくビューポート1820内に、異なるタイルのセットを含む。現在のフレーム1822Aでは、そのビューポート1820内がすべてIタイルであるが、次に続くフレームでは、ビューポート1820がPタイルを有する状態で示されている。
上記のように、BWA-TSモジュールの機能の一態様は、(たとえば、ネットワークオペレータポリシー、コンテンツプロバイダポリシー、加入者/デバイスポリシー、またはそれらの任意の組合せに基づいて)例示的な360°没入型ビデオセッションの全体的な帯域幅が、指定された帯域幅割当を超えないことを保証すると同時に、品質および鑑賞体感をなおも最大化することである。したがって、好適なビットレート品質を有する最適化されたタイル選択は、直接注視から遠ざかるほど品質が低下することにより直接視線内のタイルが可能な限り最良の品質を有するように、ユーザの視野、帯域幅割当/制限、タイルごとのビットレート、および送信バッファモデルに対応するように設定され得る。
図19は、本発明の1つまたは複数の実施形態による、本開示の追加の流れ図のブロック、ステップ、および/または動作の有無に関わらず1つまたは複数の構成で(再)結合され得る、BWA-TSプロセス1900の様々なブロック、ステップ、および/または動作を例示する流れ図である。ブロック1902に記載のように、プロセス1900は、BIE方式またはPE方式に従って生成され得る複数のタイル符号化ストリームに関して、360°ビデオ資産パッケージャ(たとえば、図2のパッケージャ214)によって提供される1つまたは複数のストリームマニフェストファイルを受信、検索、または別の方法で取得することで開始するか、またはそれに応答して開始し得る。一般に、マニフェストファイルは、メディア入力ストリームの複数のビットレート表現のうちの特定のビットレート表現に対応する各タイル符号化ビットストリームについて、ロケーションURL、ビットレート、スライス/ブロックタイプ、メディアタイプなどを含む、フレームごとのタイルグループ化の様々な特性を記述した情報またはデータを含み得る。一構成では、マニフェストは、階層的な方法で編成され得、すなわち、一定のマニフェストは、コード化ビットストリーム全体を記述するためのものであり、ストリーム内の個々のタイルを記述するために、他のマニフェストが提供され得る。本特許出願の各所に記載されているように、各ストリームは、たとえば、ビットレート表現に使用される対応するQPおよび/もしくはターゲットビットレートもしくは他の指標に関連するかまたはそれらによって制御されるビデオ品質を有するソースメディアの特定のビットレート表現であり、タイル符号化ビットストリームの各フレームは、フレームごとに少なくとも1つのスライスに編成されたタイルの配列を含み、複数のフレームが、タイル符号化ビットストリームのGOP構造を形成する。プロセス1900はブロック1904に進み、注視ベクトル情報を受信、検索、または別の方法で取得し、それに応答して、たとえば、注視ベクトルに基づいて、またはデフォルト設定に基づいて、フレームを形成するタイルの配列に対応するタイル重みを決定する。プロセス1900はブロック1906に進み、メディア入力ストリームの複数のビットレート表現または関連するタイル符号化ビットストリームに対応するバリアント重みを受信、検索、または別の方法で取得する。一構成では、バリアント重みは、ストリームのポリシーベースのプロパティと規定され得、より高品質のストリーム表現(すなわち、バリアント)に、重みベースのナップサックパッキング選択を含むさらなる計算で使用され得るより高い優先度または重みが与えられる。ブロック1908において、タイル符号化ビットストリームのそれぞれについて、妥当性メトリック値が、GOP構造全体のフレームのセットにわたる各タイル/GOPタプルの組合せごとのバリアント重みとタイル重みの関数として決定される。プロセス1900はブロック1910に進み、妥当性メトリック値に少なくとも部分的に対応して、フレームを組み立てるための対応するタイル符号化ビットストリームから、異なるビットレート品質を有するタイルを選択し、選択されたタイルのビットレート品質は、多重化されたビデオ出力ストリームを送信するための送信バッファモデルを満たすように最適化される。その後、多重化されたビデオ出力ストリームの一部として、選択されたタイルを含むフレームを生成するために、選択されたタイルのリストが、タイルステッチャに提供され得る(ブロック1912)。本特許出願の他の箇所に記載されているように、例示的な実施形態において、タイルステッチングがデバイス側の実施形態で実行される場合、選択されたタイルは、クライアントデバイスに提供され得る。
本発明の一実施形態における例示的なストリームレベルのマニフェストを以下に示す。
複数の位相符号化ストリームを含む本発明の一実施形態におけるDASH-MPDに基づく例示的な下位レベルのマニフェストを以下に示す。
図20は、本発明の一実施形態による、例示的なタイル選択および帯域幅アニーリングプロセスに関する追加のブロック、ステップ、および/または動作を例示する流れ図である。一構成では、前に指摘したように、注視ベクトル、帯域幅割当/制限、ストリームの重みなどを含む入力に基づくタイル選択およびアニーリングのために、ナップサック組合せ最適化が使用され得る。ブロック2002において、ビデオ最適化に関連するサーバまたはノードで実行されるプロセス2000は、360°没入型ビデオセッション要求を受信することで開始するか、またはそれに応答して開始する。プロセス2000はブロック2004に進み、必要なタイルを抽出するために詳細レベルの検査および処理に基づいてビデオ特性のすべての態様を決定できるように、タイル化ストリームのマニフェスト規定を検索するか、または別の方法で取得し、詳細レベルの検査および処理は、ストリームマニフェストを解析することによって実現され得る(ブロック2006)。各ストリームについて、グリッドレイアウト、たとえば、フレームごとの列および行が決定される(ブロック2008)。例示的な変形形態では、プロセス2000は、要求されたセッションに割り当てられた/決定された帯域幅に関連する通知メッセージを受信するように、ネットワーク管理およびオーケストレーションノードに登録する(ブロック2010)。帯域幅割当が受信された場合(ブロック2012)、注視ベクトル情報が受信されたかどうかの判定がさらに行われ得る(ブロック2014)。その後、注視ベクトル情報に基づいてタイル重みが決定される(ブロック2016)。利用可能な帯域幅割当の通知に対応して、ナップサックアニーリングプロセスとして、タイル選択が実行され得る(ブロック2018)。ブロック2020において、選択されたタイルは、(サーバまたはクライアントデバイスで実行する)タイルステッチングプロセスに提供される。
図21Aおよび図21Bは、本発明の例示的な実施形態による、タイル選択および帯域幅アニーリングプロセスのさらなる態様に関する追加のブロック、ステップ、および/または動作を例示する流れ図である。具体的には、図21Aに示すプロセス2100Aは、比較的単純なナップサックアニーリングプロセスを例示しており、このプロセスは、計算コストがより高い場合があり、タイルスプライシングに約1秒かかる可能性がある。ブロック2102において、タイルは、最低品質まで初期化される。ストリームバリアント重みとタイル重みの比として、妥当性メトリックが決定され得、妥当性メトリックは、すべての<タイル,GOP>タプルまたは組合せについて提供され得る(ブロック2104)。ブロック2108に記載のように、最も妥当性が低い(すなわち、最も不適切である)<タイル,GOP>タプルをアップグレードすることに関する決定が行われる。送信バッファモデルに違反しているか、送信バッファモデルを満たしているかの判定が行われる(ブロック2110)。バッファモデルを満たしていない(すなわち、違反している)場合、ブロック2112に示すように、そのタイル/GOPの組合せは、アップグレードに不適格と見なされ得、プロセスの流れは、アップグレードするための次のタイル/GOPの組合せの検討に戻る。バッファモデルに違反していない場合、タイル/GOPの組合せの品質がアップグレードされる(ブロック2114)。前述のプロセスは、最大品質未満の不適格でないタイル/GOPの組合せがなくなるまで、反復して実行され得る(ブロック2116)。最大品質未満の不適格でないタイル/GOPの組合せがない場合、ブロック2118に記載のように、選択されたタイルを、タイル多重化およびストリーム生成プロセスに送ることによって、プロセス2100Aは完了する。
図21Bを参照すると、性能が最適化されたタイル選択およびアニーリングプロセス2100Bが示されており、このプロセスは、いくつかの実装形態において、より高速なタイル選択をもたらし、全体的なタイルスプライシング時間を約10ミリ秒程度にすることができる。大まかに言えば、Iタイルのアップグレードに関してペナルティ係数が課せられ得(Iタイルは、より多くのデータをパックするので、Pタイルのアップグレードよりもコストがかかる)、アップグレードが妥当性メトリックに準拠しているかどうかに関わらずタイルのアップグレードが送信バッファモデルと照合されない「ナイーブ」アップグレードシーケンスが最初に先行し得る。さらに、ROI/ビューポート内のタイルが最初にアップグレードされ、続いてフレームの残りのタイルがアップグレード/更新されるので、例示的な実施形態は、タイル位置がどこにあるかに基づいてペナルティを計算に入れることができる。たとえば、タイル位置が注視ベクトルに近い場合、その位置に関連するペナルティはより低くなり得る。さらに、ペナルティは、アップグレードすべきタイルの品質/タイプとフレーム内のタイルの場所との間のバランスとしても、タイル位置に関連し得る。例示的な実施形態において、ナイーブアップグレードシーケンスで使用される妥当性メトリックを好適に調整することによって、ペナルティ係数または組合せの効果が、アニーリングプロセスに組み込まれ得る。
図21Aの実施形態と同様に、すべてのビデオ符号化のタイルは、最低品質まで初期化される(ブロック2132)。ストリームバリアント重みとタイル重みの比にペナルティ係数を乗算したものとして、妥当性メトリックが決定され得、妥当性メトリックは、すべての<タイル,GOP>タプルまたは組合せに対して提供され得る(ブロック2136)。ブロック2134において、(たとえば、メモリの大きなプールとしての)ヒープ構造は、すべての<タイル,GOP>タプルの妥当性値を含むように設定され得る。ブロック2138において、ヒープから妥当性が最も低いタイルが取り出され、ナイーブアップグレードシーケンスまたはプロセスに記録される。タイル品質をさらにアップグレードできる場合(ブロック2140)、そのアップグレードが実行され、アップグレードされたタイルの妥当性メトリックが決定される(ブロック2142)。ヒープが空になり、アップグレード可能なすべてのタイルがアップグレードされるまで、上記のプロセスが反復ループで実行され得る(ブロック2144)。所与の送信バッファモデルに従う最後の有効状態を見出すために、ナイーブシーケンス上で二分探索シーケンスが実現され得(ブロック2146)、最後の有効状態は、開始タイル状態として使用され得る(ブロック2148)。新しいアップグレードヒープが、タイル/GOP状態を含むように設定され得る(ブロック2150)。ヒープから妥当性が最も低いタイル/GOPの組合せが取り出され(ブロック2152)、送信バッファモデルと突き合わせて検証される(ブロック2154)。取り出されたタイル/GOPがバッファモデルを満たすことができない場合、そのタイル/GOPは、将来のアップグレードに不適格と見なされる(ブロック2158)。それ以外の場合、そのタイル/GOPをさらにアップグレードできるかどうかの判定が行われる(ブロック2156)。アップグレードできる場合、送信バッファモデルを満たすアップグレードされたタイル/GOPの組合せの妥当性値が決定される(ブロック2160)。ブロック2162に記載のように、新しいアップグレードヒープが空になるまで前述の動作が反復して実行される。ブロック2164に記載のように、新しいアップグレードヒープが空である場合、選択されたタイルを、タイル多重化およびストリーム生成プロセスに送ることによって、プロセス2100Bは完了する。
本明細書に記載の例示的なアニーリングプロセスは、有利には、ビューポートまたは帯域幅が変更されたときにフレームの段階的リフレッシュを容易にし、それによって、ユーザの視野に基づいて品質を向上させる際のレイテンシを最小限に抑え、同時に帯域幅を過負荷にしないようにする能力を可能にする。通常、すべてのタイルで同時に品質変更を実行するよう試みると、PタイルをIタイルに同時に変更した結果、符号化されたビットレートの点でコストがかかるため、いくつかの問題が発生する可能性がある。一方、この置換を最小限のクライアントバッファで実行すると、Iスライス/フレームを配信する際に大幅な遅延が発生する可能性がある。
段階的リフレッシュを採用する例示的な実施形態では、ビデオストリームは、Iフレームを有していない(最初のIフレーム、またはインスタントデコードリフレッシュ(Instant Decode Refresh)すなわちIDRフレームのような他の特殊フレームを除く)。代わりに、ビデオストリームは、IブロックまたはIタイルを有し、これらは、たとえば、本特許出願の前のセクションで詳細に説明されているように位相符号化ストリームによって、スクリーン上の特定のスポットが一定間隔でIブロックを得るように時系列全体にわたって分布し得る。したがって、このようなシナリオでは、すべての画素がIブロックによってリフレッシュされるというフレームは存在しない。本発明の例示的な実施形態は、有利には、段階的リフレッシュアニーリングを実行することによって、フレームサイズを(すなわち、コード化された画像データの量を単位として)平準化し、Iフレームを投入することによる帯域幅への影響を低減して、FoVまたはビューポートに入るタイルの品質をアップグレードするように設定され得る。PE方式では、時間/フレームシーケンスにおいてタイルの選択的な早期リフレッシュが可能であり得るが、(たとえば、フレーム内に複数のIタイルを有することにより、そのビデオフレームの転送に対応するその時間間隔に必要とされる帯域幅が増加する可能性があるので)一定の帯域幅コストがかかる場合がある。しかしながら、PEを含む例示的な実施形態は、より安定したレベルのバイト/フレームを有するという利点がそのようなコストを上回るように設定され得る。
PEベースの実施形態は、フレームシーケンスにおける時間の経過と共に、Iタイルが再び時間内にほぼ均等に分布するまで、周囲の様々なタイルの位相の操作を可能にし得る。この再分布を発生させるには、ユーザが自分の視野を再分布が発生するのに十分な時間だけ安定に保つ必要があるので、このような機能は、再分布がいつ発生するかに関して、ユーザおよび/またはコンテンツに依存するように設定され得る。帯域幅を埋めるタイルを選択するために、例示的な実施形態は、将来にわたって3つのGOPに伸ばすフレームのバイトサイズをモデル化することと(この選択は任意である)、(たとえば、先読みのシナリオでの3つのGOPを用いて)バッファモデルに基づいて仮定的早期リフレッシュ(HER:hypothetical early refresh)を実行することとを含み得る。図21Aおよび図21Bに記載された実施形態に基づけば、このようなプロセスは、すべてのタイルの最小品質のストリームを選択することによって開始し、次いで、現在のフレームと将来のフレームの両方についてタイルの各GOPを検討し、そのGOPをアップグレードすることが帯域幅の制約(個々のフレームサイズとバッファの考慮事項の組合せ)に違反するかどうかを評価することが理解され得る。(将来ではなく)現在のタイルとGOPの組合せを、すでに配信されているIフレームの品質を超えてアップグレードすることを検討する場合、本発明の実施形態は、このタイルを、(スプライシングウィンドウ内の残りのフレームに影響を与え得る)Iフレームで始まるように一時的に再調整することができる。可能なアップグレードのリストが取得されると、そのアップグレードは、品質およびFoV内のタイルの位置に応じて重み付けされ得る(したがって、視界の中心に近いタイルが、アップグレードに優先されることになる)。一実施形態では、前述のアップグレードのステップは、バッファ制約によりそれ以上のアップグレードが不可能になるまで、繰り返され得る。
例示的なアップグレードプロセスは、先読みのGOPモデル化に応じて、時間的にも空間的にも変動し得ることを理解されたい。一構成では、各タイルは、プロセスが反復されるときにそれぞれアップグレードされ得る3~4つのGOP範囲を有することができ、将来のGOPアップグレードは、将来にわたって3~4つのGOPをカバーする早期リフレッシュの潜在的な将来の拡張のためのものである。
HERベースの実装形態を検討する場合、好適なトレードオフを得るために、いくつかの潜在的なメトリック、とりわけ、(i)放送中断、(ii)最大バッファレベル、および(iii)エンドバッファレベルが識別および/または採用され得る。例示的な一実装形態では、HERアップグレードの主要な基準として最大バッファレベルが重み付けされ得、タイルGOP品質のアップグレードを可能にするのに十分な帯域幅が解放され得る。
図21Bの実施形態に記載のように、アップグレード反復の終了に達すると、タイルのセットを使用してスライス/フレームが多重化され得、これにより、多重化されたスライス/スライスのバイトサイズが算出され得、次のスライス/フレームが所与の送信バッファモデルに従って正確に制約されるように、送信バッファに対するその影響が記録され得る。次回フレームがスプライスされるとき(たとえば、ユーザの注視が変化し、それによって調整が行われるとき)、前の動作に関連して1つの追加のフレームがモデル化される、ナップサックアニーリングプロセスが繰り返され得、これにより、ナップサック/アニーリングプロセスを検証および/または微調整することができる。
図21Bの実施形態で採用されたヒープメモリ構造は、反復ごとにタイルGOPアップグレードのスコアを再算出することを回避できるので、アップグレード可能なタイルを追跡するのに特に有利であることが、当業者には理解されよう。前述のように、妥当性メトリックは、アップグレードするタイルを選択する際に使用される、タイルのスコア化に対して規定され、variant_weight、tile_weight、penaltyなどのパラメータが、所望のアップグレードシナリオを捕捉するのに好適な数学的関係で提供される。したがって、variant_weightパラメータは、符号化ストリームのプロパティと規定され得、(より低いQPを有する)より高品質のストリームバリアントは、より高いvariant_weightを有する。いくつかの例示的なvariant_weightは、{1/QP}、{100-QP}、または上記のマニフェストの例で規定された値であり、あるいは、ストリーム全体のビットレートであり得る。tile_weightは、上記のように、注視に対するタイルの位置の関数としても提供され得る。一般に、ユーザの直接FoV内またはROI/ビューポート内のタイルには、より高いtile_weightが割り当てられ得る。図21A/Bの実施形態に記載されている例示的な妥当性メトリックの定式化は、ストリーム品質が上がるにつれて妥当性値も上がり、また注視ベクトルにより近いタイルが、注視ベクトルから遠い同じ品質のタイルよりも妥当性が低くなるように設定される(これにより、アニーリングプロセスは、注視ベクトルから離れたタイルをアップグレードする前に、注視ベクトルにより近いタイルをアップグレードするように設定される)。
さらに、例示的な実施形態は、上記のように、アップグレードプロセスのためにタイルをスコア化する際のペナルティ係数も含む。一構成では、現在のGOPのタイルが前のスライス/フレームの品質を超えてアップグレードされるべきであり、Iタイルによる早期リフレッシュが必要とされる場合、ペナルティが課され得る。このようなペナルティには、そのタイルの妥当性を高め、ヒープ内の他のタイルと比較してアップグレードを遅らせる効果がある。これにより、注視が十分に変化したときはタイルのアップグレードが可能になるが、わずかな場合は早期リフレッシュが先送りされる。
本発明の範囲内のいくつかの変形形態において、タイルのアップグレードをスコア化するために追加の/代替の定式化が使用され得ることは、当業者には明らかであろう。
図22は、本発明の例示的な実施形態による、タイル選択および帯域幅アニーリング構成で使用するための送信バッファモデルプロセスを例示する。一般に、送信バッファモデルは、実装形態に応じたフレームレート(たとえば、30fps、60fpsなど)と一致するように設定され得、オーバーフロー(すなわち、違反)が発生し得るかどうか、またいつ発生し得るかを判断するために、データがどのようにバッファに追加され、どのようにバッファから送信されるかに関する時間的変化が、パラメータ化され得る。例示的な送信バッファモデル2200において、b0は開始バッファレベルであり、biはアクセスユニットまたはNALユニットを追加する前のバッファのサイズであり、niはアクセス/NALユニットのサイズであり、aiはアクセス/NALユニットを追加した後のバッファのサイズであり、i≧1の場合、ai=bi+niである。送信レートをr、Δt=1/フレームレートと仮定すると、次の関係が得られる。
bi+1=Max{0,ai-r(ti+1-ti)}
buffer_sizeパラメータは、次のように規定され得る。
buffer_size=r(latency_frames)Δt
前述のモデルによれば、Max(ai)>buffer_sizeである場合、これは、バッファオーバーフロー状態として示され得る。したがって、タイルのアップグレードプロセスに従って異なるniが追加されているので、アップグレードプロセスにおいてバッファ違反が発生しないことを保証するために、バッファエンドポイントレベルが、算出されたバッファサイズと照合され得る。
図23を参照すると、本特許開示の一実施形態における、クライアントUEデバイスが360°没入型ビデオ最適化の特定の態様を実行するように設定され得る構成2300が示されている。好適な360°表示デバイスを有するユーザ2310は、ビデオ最適化クライアントモジュール2306と、表示デバイスへの好適なプレイバック信号を生成するように配置されたコネクテッドプレーヤ2308とを含む、コネクテッドUEデバイス2302を用いて操作する。一実施形態では、プレーヤ2308は、適切なビデオデコーダ2314、表示レンダラ2316、オーディオデコーダ2318、およびサウンドレンダラ2320を有するように設定された、HEVCまたはAV1プレーヤを備え得る。上記の例示的な実施形態と同様に、コネクテッドUEデバイス2302と共に、注視追跡モジュール2312が提供され得、注視追跡モジュール2312は、ABRストリーミング環境においてインターネット2304を介して配信される360°没入型ビデオコンテンツを消費するように設定され得る。
クライアント最適化モジュール2306は、好ましくは、マニフェストパーサ2328と、ビデオタイルおよびオーディオストリームダウンローダ2330と、帯域幅推定モジュール2326と、タイル選択モジュール2324とを備える360°没入型ビデオインターフェースモジュール2321を含み、これらは、デバイス中心の好適な変更を加えて、上記の実施形態と同様の方法で動作するように設定され得る。特定のコンテンツに関するマニフェスト2340に基づいて、インターネット2304を介して、ネットワークロケーション、たとえば、コンテンツプロバイダネットワークまたはクラウドベースのストレージへのHEVCタイル/オーディオ要求2344が生成され得る。要求されたビデオタイルおよびオーディオデータは、経路2342を介して受信され得る。注視追跡モジュール2312から(たとえば、経路2322を介して)没入型ビデオインターフェースモジュール2321に提供される注視ベクトル情報は、フレームごとのタイルを選択する際の帯域幅推定と共に利用され得、これは、動的に割り当てられたビデオバッファ2332にビデオ信号経路2331を介して提供され得る。同様に、対応するオーディオセグメントが、オーディオ信号経路2338を介してオーディオバッファ2336に提供され得る。異なる品質のタイルが、タイルコンバイナ2334に提供され得、タイルコンバイナ2334は、プレーヤのビデオデコーダ2314への多重化された符号化ビデオストリーム2346を生成する。オーディオバッファ2336から、オーディオデコーダ2318への符号化オーディオストリーム2348が生成され得る。プレーヤ2308のそれぞれのレンダラ2320、2316に提供される復号されたオーディオおよびビデオデータは、本質的に前述の例示的な実施形態と同様に、ユーザの表示デバイスによって実現される没入型環境での表示/提示に適するようにレンダリングされる。
図24は、本発明の一実施形態による、360°没入型ビデオ処理、準備、およびタイル選択最適化の1つまたは複数の態様を実現するためのプラットフォーム、ノード、または要素として(再)設定および/または(再)構成され得るコンピュータ実装装置のブロック図を示す。実装および/またはネットワークアーキテクチャに応じて、装置2400は、(たとえば、図1および図2に示すような)例示的な環境の1つまたは複数の階層レベルでの動作に好適な異なる構成で設定されるかまたは別の方法で統合され得る。1つまたは複数のプロセッサ2402は、装置2400のオーバーコール制御を提供するのに好適なコンピュータアーキテクチャの一部として提供され得、プロセッサ2402は、上記で詳細に説明したように、メディア準備、前処理、適応ビットレート符号化/トランスコーディングを含むBIE/PEベースのタイル符号化、最適化されたタイル選択および帯域幅アニーリング、タイル化されたメディアのパッケージ化、タイルステッチングなどに特有の追加のモジュールまたはブロックを含む、適切なメモリモジュールまたはブロック、たとえば、永続メモリ2408に記憶された様々なプログラム命令を実行するように設定され得る。たとえば、このようなモジュールには、タイルベースのPE/BIEエンコーダ2404、ABRエンコーダ/トランスコーダ2406、GV処理およびタイル重み処理モジュール2413、タイル選択およびアニーリングモジュール2416、パッケージャおよびマニフェストジェネレータ2410、投影マッパー2418などが含まれ得る。また、例示的な実施形態では、装置2400の実装に応じて、パッケージ化されたメディアのデータベース2419が提供され得る。したがって、ネットワーク階層レベルおよび/または統合に応じて、ビデオバックオフィス要素、DRMエンティティ、オリジンサーバ、クライアントコントローラノード、ソースメディアノード、管理ノード、およびキャッシュデータベースを含むネットワークインフラストラクチャ要素との通信を実現するように動作する、様々なネットワークインターフェース、たとえば、I/F2414-1~2414-L、ならびに、たとえば、配信サーバ、DSLAM/CMTS要素、RANインフラストラクチャ要素、宅内ゲートウェイノードなどを含む1つまたは複数の下流ノードとの通信セッションを実現するためのインターフェース2412-1~2412-Kが、装置2400の一部として提供され得る。
図25は、本特許開示の1つまたは複数の実施形態による、様々なクライアント側プロセスを実行するように設定された例示的なクライアントUEデバイスまたは加入者ステーション2500のブロック図を示す。クライアントデバイス2500は、概して、上記の1つまたは複数の図に示される様々な鑑賞デバイスを表し、実装形態に応じて、とりわけ、メディア要求生成、注視ベクトル生成、タイル選択、および帯域幅推定に関連するデバイス側プロセスのいずれかを(個別にまたはそれらの任意の組合せで)実行するように設定された、適切なハードウェア/ソフトウェア構成要素およびサブシステムを含み得る。1つまたは複数のマイクロコントローラ/プロセッサ2502は、クライアントデバイス2500の全体的な制御、およびデバイス2500のメモリサブシステム2511の一部であり得る1つまたは複数の永続メモリモジュールで具現化される様々な記憶されたプログラム命令の実行のために提供される。たとえば、VRアプリケーションを含む360°没入型ビデオクライアントアプリケーション2513Aは、帯域幅推定器2513Bおよび関連するタイルセレクタ2513Cと共に動作し得、これらは、メモリサブシステム2511の一部として提供され得る。マニフェストパーサ2517は、適切なロケーションへのメディア要求の生成を容易にするために提供され得る。参照番号2502によって示されるコントローラ/プロセッサ複合体もまた、好適なビデオおよびオーディオインターフェース(特に図示せず)と関連して動作する、グラフィックプロセッサ、ビデオプロセッサ、デジタル信号プロセッサ(DSP:digital signal processor)などの他の特殊処理モジュールを表し得る。DSL/CMTSネットワーク2598または衛星ネットワーク2596を介して受信されたIPTVおよび他のコンテンツ信号を処理するため、またそれらとインターフェースするための、チューナ、復調器、デスクランブラ、MPEG/H.264/H.265/AV1デコーダ/デマルチプレクサを含むまたはそれらと共に動作する、ネットワークI/Fモジュール2504および2506などの適切なネットワークインターフェースが含まれ得る。例示的なクライアントデバイスまたはアプリケーションとして、STBが設定される場合、好適な復調器も含まれ得る。クライアントデバイス2500の他のサブシステム、たとえば、ユーザインターフェース2520と連動して動作するための、1つまたは複数のメディアプレーヤ2514が提供され得、これは、チャネル変更要求およびトリックモード動作を含むメディアプレイバックに対するユーザ制御を容易にするための追加のサブシステムを有するようにさらに設定され得る。たとえば、クライアント/ユーザ制御機能には、再生されている特定の360度没入型ビデオ資産に対する、一時停止、再開、早送り、巻き戻し、シーク、ブックマークなどが含まれ得る。例示的なメディアプレーヤは、知られているまたはこれまでに知られていない規格または仕様に基づいて、1つまたは複数のA/Vコーダ/デコーダ(コーデック)機能で動作するように設定され得る。
デバイス設定に応じて、没入型表示インターフェース2515、タッチスクリーンもしくはキーパッドインターフェース2520、USB/HDMIポート2518、イーサネットI/F2508、ならびに短距離および広域無線接続インターフェース2512などの他のI/Oまたはインターフェースも提供され得る。様々な動き検出および注視追跡センサ2516も含まれ得、それらのいくつかは、ジャイロスコープ、加速度計、位置センサなどを備え得る。例示的な実装形態では、プログラム資産のローカルストレージ用に、ハードディスクドライブ(HDD:hard disk drive)またはローカルDVRシステム2510が含まれ得る。好適な電源ブロック2522は、デバイス2500に電力を供給するためのAC/DC電力変換を含み得る。デバイス2500のための実際の電力アーキテクチャは、使用されるハードウェアプラットフォームによって、たとえば、コアSoC(システムオンチップ)、メモリ、アナログフロントエンド、アナログ信号チェーン構成要素、および特定のプラットフォームで使用されるインターフェースに応じて、異なり得ることを理解されたい。
前述の実施形態に関する様々な装置およびシステム、ならびに上記の基礎となるネットワークインフラストラクチャが、本特許開示の追加のまたは代替の実施形態においてネットワーク機能仮想化(NFV:network function virtualization)アーキテクチャに従って仮想化環境で設計され得ることが、当業者には理解されよう。たとえば、上記のソースメディア処理インフラストラクチャ、メディアコンテナ化、PE/BIEタイル符号化およびパッケージ化などを含む、本適用例の例示的なストリーミングネットワーク内で実行する様々な物理リソース、データベース、サービス、アプリケーション、および機能は、仮想アプライアンス、マシン、または機能として提供され得、リソースおよびアプリケーションが、好適な仮想化層を介して好適な仮想ネットワーク機能(VNF:virtual network function)または仮想ネットワーク要素(VNE:virtual network element)に仮想化される。計算リソース、メモリリソース、およびネットワークインフラストラクチャリソースを含むリソースは、対応する仮想リソースに仮想化され、仮想計算リソース、仮想メモリリソース、および仮想ネットワークリソースは、VNF層をサポートするように集合的に動作し、その全体的な管理およびオーケストレーションの機能は、VNFマネージャおよびNFVオーケストレータと組み合わせた仮想化インフラストラクチャマネージャ(VIM:virtualized infrastructure manager)によってサポートされ得る。運用支援システム(OSS:Operation Support System)および/またはビジネス支援システム(BSS:Business Support System)構成要素は、典型的には、ネットワーク管理、障害管理、設定管理、サービス管理、加入者管理などのネットワークレベルの機能をハンドリングするために提供され得、好適なインターフェースを介して、VNF層およびNFVオーケストレーション構成要素とインターフェースし得る。
さらに、本明細書に開示される例示的なネットワークアーキテクチャの少なくとも一部は、上記のように仮想化され得、設定可能な仮想リソースの共有プールを含むクラウドコンピューティング環境において設計され得る。PE/BIEタイル符号化、パッケージ化、帯域幅アニーリングおよびタイル選択、タイルの多重化およびコンテナ化などに関連する様々なハードウェア/ソフトウェアは、本発明の例示的な実施形態の異なる特徴を提供する複数のエンティティによって、サービス指向アーキテクチャ、たとえばソフトウェアアズアサービス(SaaS:Software as a Service)、プラットフォームアズアサービス(PaaS:Platform as a Service)、インフラストラクチャアズアサービス(IaaS:Infrastructure as a Service)などにおいて実装され得、仮想化環境の1つまたは複数の層は、商用既製品(COTS:commercial off the shelf)ハードウェアでインスタンス化され得る。当業者はまた、このようなクラウドコンピューティング環境が、プライベートクラウド、パブリッククラウド、ハイブリッドクラウド、コミュニティクラウド、分散型クラウド、マルチクラウド、およびインタークラウド(たとえば、「クラウドオブクラウド」)などのうちの1つまたは複数を含み得ることも理解するであろう。
追加の例示的な実施形態について、以下で説明する。
1.没入型ビデオ最適化システムにおいて動作する方法であって、メディア入力ストリームの複数のビットレート表現のうちの特定のビットレート表現に対応する各タイル符号化ビットストリームについて、フレームごとのタイルグループ化の特性を記述した1つまたは複数のストリームマニフェストファイルを検索することであって、各ビットレート表現が、各ビットレート表現に使用される対応する量子化パラメータ(QP)値に関連する別個のビデオ品質を有し、タイル符号化ビットストリームの各フレームが、フレームごとに少なくとも1つのスライスに編成されたタイルの配列を含み、複数のフレームがタイル符号化ビットストリームのグループオブピクチャ(GOP)構造を形成する、1つまたは複数のストリームマニフェストファイルを検索することと、フレームを形成するタイルの配列に対応するタイル重みを取得することと、メディア入力ストリームの複数のビットレート表現に対応するバリアント重みを取得することと、タイル符号化ビットストリームのそれぞれについて、妥当性メトリック値を、GOP構造全体の各タイル/GOPの組合せごとのバリアント重みとタイル重みの関数として決定することと、妥当性メトリック値に対応して、フレームを形成するための対応するタイルコード化ビットストリームから、異なるビットレート品質を有するタイルを選択することであって、選択されたタイルのビットレート品質が、多重化されたビデオ出力ストリームを送信するための送信バッファモデルを満たすように最適化される、タイルを選択することと、多重化されたビデオ出力ストリームの一部として、選択されたタイルを含むフレームを生成するために、選択されたタイルをマルチプレクサに提供することとを含む、方法。
2.タイル符号化ビットストリームが、高効率ビデオコーディング(HEVC)H.265圧縮、Alliance for Open Media(AOMedia)ビデオ1(AV1)圧縮、およびH.266/多用途ビデオコーディング(VVC)圧縮のうちの少なくとも1つに基づいて、複数の位相符号化ビットストリームとして生成される、請求項1に記載の方法。
3.タイル符号化ビットストリームの一部が、高効率ビデオコーディング(HEVC)H.265圧縮、Alliance for Open Media(AOMedia)ビデオ1(AV1)圧縮、およびH.266/多用途ビデオコーディング(VVC)圧縮のうちの少なくとも1つに基づいて、ブロックイントラ符号化ビットストリームとして生成される、請求項1に記載の方法。
4.タイル重みが、360°没入型ビデオ資産をユーザに表示するように動作するクライアントデバイスからの注視ベクトルに対応して決定され、タイル重みが、注視ベクトルと、ユーザによって鑑賞される3次元(3D)表示環境に投影された復号されたフレームのタイルの配列にそれぞれ対応する各タイルロケーションに関連付けられた方向ベクトルとの間の分離角に基づく、請求項1に記載の方法。
5.送信バッファモデルが、一定期間にわたって所定の数のフレームを送信するためのバッファ使用要件を推定するように動作する、請求項4に記載の方法。
6.360°没入型ビデオ資産を含むマルチメディアセッションのためにクライアントデバイスにとって利用可能な帯域幅の推定量を受信することと、最適なビットレート品質を有するタイルを選択するために、帯域幅の推定量に基づいて、タイルの妥当性メトリック値を反復してアップグレードすることとをさらに含む、請求項5に記載の方法。
7.最適なビットレート品質を有するタイルを選択するとき、イントラコード化(I)フレームタイルをアップグレードすることに関連する初期妥当性メトリック値を計算する際に、ペナルティ値を適用することをさらに含む、請求項6に記載の方法。
8.没入型ビデオ最適化システムであって、1つまたは複数のプロセッサと、プログラム命令が記憶された1つまたは複数の永続メモリモジュールであって、前記プログラム命令が、1つまたは複数のプロセッサによって実行されると、1つまたは複数のプロセッサに関連して次の動作、すなわち、メディア入力ストリームの複数のビットレート表現のうちの特定のビットレート表現に対応する各タイル符号化ビットストリームについて、フレームごとのタイルグループ化の特性を記述した1つまたは複数のストリームマニフェストファイルを検索することであって、各ビットレート表現が、各ビットレート表現に使用される対応する量子化パラメータ(QP)値に関連する別個のビデオ品質を有し、タイル符号化ビットストリームの各フレームが、フレームごとに少なくとも1つのスライスに編成されたタイルの配列を含み、複数のフレームがタイル符号化ビットストリームのグループオブピクチャ(GOP)構造を形成する、1つまたは複数のストリームマニフェストファイルを検索することと、フレームを形成するタイルの配列に対応するタイル重みを取得することと、メディア入力ストリームの複数のビットレート表現に対応するバリアント重みを取得することと、タイル符号化ビットストリームのそれぞれについて、妥当性メトリック値を、GOP構造全体の各タイル/GOPの組合せごとのバリアント重みとタイル重みの関数として決定することと、妥当性メトリック値に対応して、フレームを形成するための対応するタイルコード化ビットストリームから、異なるビットレート品質を有するタイルを選択することであって、選択されたタイルのビットレート品質が、多重化されたビデオ出力ストリームを送信するための送信バッファモデルを満たすように最適化される、タイルを選択することと、多重化されたビデオ出力ストリームの一部として、選択されたタイルを含むフレームを生成するために、選択されたタイルをマルチプレクサに提供することとを実行する、1つまたは複数の永続メモリモジュールとを備える、没入型ビデオ最適化システム。
9.タイル符号化ビットストリームが、高効率ビデオコーディング(HEVC)H.265圧縮、Alliance for Open Media(AOMedia)ビデオ1(AV1)圧縮、およびH.266/多用途ビデオコーディング(VVC)圧縮のうちの少なくとも1つに基づいて、複数の位相符号化ビットストリームとして生成される、請求項8に記載の没入型ビデオ最適化システム。
10.タイル符号化ビットストリームの一部が、高効率ビデオコーディング(HEVC)H.265圧縮、Alliance for Open Media(AOMedia)ビデオ1(AV1)圧縮、およびH.266/多用途ビデオコーディング(VVC)圧縮のうちの少なくとも1つに基づいて、ブロックイントラ符号化ビットストリームとして生成される、請求項8に記載の没入型ビデオ最適化システム。
11.タイル重みが、360°没入型ビデオ資産をユーザに表示するように動作するクライアントデバイスからの注視ベクトルに対応して決定され、タイル重みが、注視ベクトルと、ユーザによって鑑賞される3次元(3D)表示環境に投影された復号されたフレームのタイルの配列にそれぞれ対応する各タイルロケーションに関連付けられた方向ベクトルとの間の分離角に基づく、請求項8に記載の没入型ビデオ最適化システム。
12.送信バッファモデルが、一定期間にわたって所定の数のフレームを送信するためのバッファ使用要件を推定するように動作する、請求項11に記載の没入型ビデオ最適化システム。
13.プログラム命令が、360°没入型ビデオ資産を含むマルチメディアセッションのためにクライアントデバイスにとって利用可能な帯域幅の推定量を受信することと、最適なビットレート品質を有するタイルを選択するために、帯域幅の推定量に基づいて、タイルの妥当性メトリック値を反復してアップグレードすることとを実行するように設定された命令をさらに含む、請求項12に記載の没入型ビデオ最適化システム。
14.プログラム命令が、最適なビットレート品質を有するタイルを選択するとき、イントラコード化(I)フレームタイルをアップグレードすることに関連する初期妥当性メトリック値を計算する際に、ペナルティ値を適用するように設定された命令をさらに含む、請求項13に記載の没入型ビデオ最適化システム。
15.没入型ビデオ最適化システムの1つまたは複数のプロセッサによって実行されると、最小のレイテンシで360°没入型ビデオ資産の提示用に最適化されたタイル選択プロセスを実現する命令が記憶された、1つまたは複数の非一時的な有形のコンピュータ可読媒体であって、メディア入力ストリームの複数のビットレート表現のうちの特定のビットレート表現に対応する各タイル符号化ビットストリームについて、フレームごとのタイルグループ化の特性を記述した1つまたは複数のストリームマニフェストファイルを検索するためのコード部分であって、各ビットレート表現が、各ビットレート表現に使用される対応する量子化パラメータ(QP)値に関連する別個のビデオ品質を有し、タイル符号化ビットストリームの各フレームが、フレームごとに少なくとも1つのスライスに編成されたタイルの配列を含み、複数のフレームがタイル符号化ビットストリームのグループオブピクチャ(GOP)構造を形成する、1つまたは複数のストリームマニフェストファイルを検索するためのコード部分と、フレームを形成するタイルの配列に対応するタイル重みを取得するためのコード部分と、メディア入力ストリームの複数のビットレート表現に対応するバリアント重みを取得するためのコード部分と、タイル符号化ビットストリームのそれぞれについて、妥当性メトリック値を、GOP構造全体の各タイル/GOPの組合せごとのバリアント重みとタイル重みの関数として決定するためのコード部分と、妥当性メトリック値に対応して、フレームを形成するための対応するタイルコード化ビットストリームから、異なるビットレート品質を有するタイルを選択するためのコード部分であって、選択されたタイルのビットレート品質が、多重化されたビデオ出力ストリームを送信するための送信バッファモデルを満たすように最適化される、タイルを選択するためのコード部分と、多重化されたビデオ出力ストリームの一部として、選択されたタイルを含むフレームを生成するために、選択されたタイルをマルチプレクサに提供するためのコード部分とを含む、1つまたは複数の非一時的な有形のコンピュータ可読媒体。
16.タイル符号化ビットストリームが、高効率ビデオコーディング(HEVC)H.265圧縮、Alliance for Open Media(AOMedia)ビデオ1(AV1)圧縮、およびH.266/多用途ビデオコーディング(VVC)圧縮のうちの少なくとも1つに基づいて、複数の位相符号化ビットストリームとして生成される、請求項15に記載の非一時的な有形のコンピュータ可読媒体。
17.タイル符号化ビットストリームの一部が、高効率ビデオコーディング(HEVC)H.265圧縮、Alliance for Open Media(AOMedia)ビデオ1(AV1)圧縮、およびH.266/多用途ビデオコーディング(VVC)圧縮のうちの少なくとも1つに基づいて、ブロックイントラ符号化ビットストリームとして生成される、請求項15に記載の非一時的な有形のコンピュータ可読媒体。
18.タイル重みが、360°没入型ビデオ資産をユーザに表示するように動作するクライアントデバイスからの注視ベクトルに対応して決定され、タイル重みが、注視ベクトルと、ユーザによって鑑賞される3次元(3D)表示環境に投影された復号されたフレームのタイルの配列にそれぞれ対応する各タイルロケーションに関連付けられた方向ベクトルとの間の分離角に基づく、請求項15に記載の非一時的な有形のコンピュータ可読媒体。
19.送信バッファモデルが、一定期間にわたって所定の数のフレームを送信するためのバッファ使用要件を推定するように動作する、請求項18に記載の非一時的な有形のコンピュータ可読媒体。
20.360°没入型ビデオ資産を含むマルチメディアセッションのためにクライアントデバイスにとって利用可能な帯域幅の推定量を受信することと、最適なビットレート品質を有するタイルを選択するために、帯域幅の推定量に基づいて、タイルの妥当性メトリック値を反復してアップグレードすることとを実行するように設定された命令をさらに含む、請求項19に記載の非一時的な有形のコンピュータ可読媒体。
21.最適なビットレート品質を有するタイルを選択するとき、イントラコード化(I)フレームタイルをアップグレードすることに関連する初期妥当性メトリック値を計算する際に、ペナルティ値を適用するように設定された命令をさらに含む、請求項20に記載の非一時的な有形のコンピュータ可読媒体。
本開示の様々な実施形態の上記の説明において、本明細書で使用される用語は、特定の実施形態を説明することのみを目的としており、本発明を限定することを意図するものではないことを理解されたい。別段の規定がない限り、本明細書で使用される(技術用語および科学用語を含む)用語はすべて、本発明が属する技術分野の当業者によって一般に理解されるものと同じ意味を有する。一般的に使用される辞書で規定されているような用語は、本明細書および関連技術の文脈におけるそれらの意味と一致する意味を有すると解釈されるべきであり、本明細書で明示的に規定されている理想的または過度に形式的な意味で解釈されてはならないことがさらに理解されよう。
少なくともいくつかの例示的な実施形態は、本明細書において、コンピュータ実装方法、装置(システムおよび/もしくはデバイス)および/もしくはコンピュータプログラム製品のブロック図ならびに/または流れ図を参照して説明されている。ブロック図および/または流れ図のブロック、ならびにブロック図および/または流れ図中のブロックの組合せは、1つまたは複数のコンピュータ回路によって実行されるコンピュータプログラム命令によって実装され得ることが理解されよう。このようなコンピュータプログラム命令は、汎用コンピュータ回路、専用コンピュータ回路のプロセッサ回路、および/またはマシンを作成するための他のプログラム可能なデータ処理回路に提供され得、その結果、命令は、コンピュータのプロセッサおよび/または他のプログラム可能なデータ処理装置を介して実行されると、ブロック図および/または流れ図の1つもしくは複数のブロックで指定された機能/動作を実装するように、トランジスタ、メモリロケーションに記憶された値、およびこのような回路内の他のハードウェア構成要素を変換および制御し、それによって、ブロック図および/または流れ図ブロックで指定された機能/動作を実装するための手段(機能)および/または構造を作成する。さらに、コンピュータまたは他のプログラム可能なデータ処理装置に特定の方法で機能するように指示することができるコンピュータプログラム命令はまた、有形のコンピュータ可読媒体に記憶され得、その結果、コンピュータ可読媒体に記憶された命令は、ブロック図および/または流れ図の1つまたは複数のブロックで指定された機能/動作を実装する命令を含む製造品を生成する。
前に指摘したように、有形の非一時的なコンピュータ可読媒体は、電子、磁気、光学、電磁、または半導体のデータ記憶システム、装置、またはデバイスを含み得る。コンピュータ可読媒体のより具体的な例には、以下の、ポータブルコンピュータディスケット、ランダムアクセスメモリ(RAM)回路、読み取り専用メモリ(ROM)回路、消去可能なプログラム可能な読み取り専用メモリ(EPROMまたはフラッシュメモリ)回路、ポータブルコンパクトディスク読み取り専用メモリ(CD-ROM)、およびポータブルデジタルビデオディスク読み取り専用メモリ(DVD/Blu-ray)が含まれ得る。コンピュータプログラム命令はまた、コンピュータおよび/または他のプログラム可能なデータ処理装置にロードあるいはダウンロードされて、コンピュータおよび/または他のプログラム可能な装置上で一連の動作ステップを実行させて、コンピュータ実装プロセスを生成し得る。したがって、本発明の実施形態は、ハードウェアにおいて、および/または、「回路」、「モジュール」もしくはその変形と総称され得るプロセッサもしくはコントローラ上で実行されるソフトウェア(ファームウェア、常駐ソフトウェア、マイクロコードなどを含む)において具現化され得る。さらに、例示的な処理ユニットには、例示として、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ(DSP)、複数のマイクロプロセッサ、DSPコアに関連する1つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(ASIC:Application Specific Integrated Circuit)、フィールドプログラマブルゲートアレイ(FPGA:Field Programmable Gate Array)回路、任意の他のタイプの集積回路(IC:integrated circuit)、および/またはステートマシンが含まれ得る。理解され得るように、例示的なプロセッサユニットは、特定の実施形態において分散処理を採用することができる。
さらに、少なくともいくつかの追加のまたは代替の実装形態において、ブロックに記載されている機能/動作は、流れ図に示されている順序から外れて生じ得る。たとえば、連続して示される2つのブロックは、実際には、実質的に同時に実行され得るか、またはブロックは、関与する機能/動作に応じて、逆の順序で実行されることがあり得る。さらに、流れ図および/もしくはブロック図の所与のブロックの機能は、複数のブロックに分離され得、かつ/または、流れ図および/もしくはブロック図の2つ以上のブロックの機能は、少なくとも部分的に統合され得る。さらに、図のいくつかは、通信経路上に通信の主な方向を示すための矢印を含むが、通信は、示された矢印とは反対の方向に発生し得ることを理解されたい。最後に、図示されているブロックの間に、他のブロックが追加/挿入され得る。
したがって、本開示の図に示す流れ図のいずれかに図示されている動作、ステップ、機能、構成要素、もしくはブロックの順序またはシーケンスは、特定の動作、ステップ、機能、構成要素、またはブロックの削除または省略を含め、特定の流れ図内で修正、変更、置換、カスタマイズ、または別の方法で再配置され得ることを明確に理解されたい。さらに、特定の流れ図に示されている動作、ステップ、機能、構成要素、またはブロックは、本特許開示の教示を実施する目的で1つまたは複数のプロセスに対する追加の変形形態、修正形態、および設定を実現するために、別の流れ図に示されている動作、ステップ、機能、構成要素、またはブロックと混合され得るか、または別の方法で相互配置もしくは再配置され得る。
様々な実施形態が詳細に示され、説明されてきたが、特許請求の範囲は、特定の実施形態または実施例に限定されない。上記の発明を実施するための形態のいずれも、特定の構成要素、要素、ステップ、動作、または機能が、特許請求の範囲に含まれなければならないほど不可欠であることを意味するものとして読まれるべきではない。単数形の要素についての言及は、明示的に明記されていない限り、「唯一の」を意味するのではなく、「1つ以上」を意味することを意図している。当業者に知られている上記の実施形態の要素とのすべての構造的および機能的な均等物は、参照により本明細書に明示的に組み込まれ、本特許請求の範囲に含まれることを意図している。したがって、本明細書に記載の例示的な実施形態が、添付の特許請求の範囲の趣旨および範囲内で様々な修正および変更を加えて実施され得ることが、当業者には理解されよう。