JP7077396B2 - ビデオエンコードの延期されたポストプロセスのためのシステムおよび方法 - Google Patents

Description

本出願は、２０１７年４月２１日に出願された米国仮出願第６２／４８８，５２６号および２０１８年１月１７日に出願された米国仮出願第６２／６１８，４９８号の利益を主張する。

サーバ側のゲームがクライアント側のプレイヤによって制御されるリモートゲーミングアプリケーションは、既存のまたはカスタマイズされたエンコーダを使用し、リアルタイムで３Ｄグラフィックスエンジン（ｇｒａｐｈｉｃｓ ｅｎｇｉｎｅ）からのビデオ出力をエンコードすることを試みていた。しかし、ビデオゲームの会話形式特性、特に、ビデオ出力とプレイヤ入力との間のプレイヤフィードバックループ（ｐｌａｙｅｒ ｆｅｅｄｂａｃｋ ｌｏｏｐ）は、ゲームビデオストリーミングの待機時間（ｌａｔｅｎｃｙ）が一般的なビデオストリーミングよりも極めて長い。既存のビデオコーディング方法は、エンコード時間を減らすために計算能力（ｃｏｍｐｕｔａｔｉｏｎａｌ ｐｏｗｅｒ）を交換することができるが、その他の方法はない。エンコードプロセスをビデオレンダリングプロセスに統合するための新たな方法は、エンコード時間を著しく減らすことはできるが、計算能力を低め、エンコードされたビデオの品質を改善し、既存のハードウェアデバイスの相互運用性を維持するためにオリジナルビットストリームデータ形式（ｏｒｉｇｉｎａｌ ｂｉｔｓｔｒｅａｍ ｄａｔａ ｆｏｒｍａｔ）を維持するようになる。

一般的なビデオレンダリングパイプライン（ｐｉｐｅｌｉｎｅ）は、ビデオエンコードパイプラインから分離した独立的なものであり、２つのドメイン（ｄｏｍａｉｎ）間でプロセスと専門知識（ｅｘｐｅｒｔｉｓｅ）の交差は殆どない。結果的に、ビデオレンダリングパイプラインに適用された視覚効果（ｖｉｓｕａｌ ｅｆｆｅｃｔ）およびポストプロセス（ｐｏｓｔ－ｐｒｏｃｅｓｓ）のうちの一部は、ビデオエンコードプロセスに逆効果をもたらし、ビデオアーティファクト（ａｒｔｉｆａｃｔ）、エンコードされたビデオサイズの増加、エンコード時間の延長に繋がるようになる。しかし、このような視覚効果は、結果的なデコードされたビデオとしては依然として好ましい。

ビデオレンダリングおよびビデオエンコードパイプラインを統合することにより、ポストプロセス効果がエンコードプロセスを改善するために延期されることがある。例えば、シミュレーションされたフィルム型グレーン（ｓｉｍｕｌａｔｅｄ ｆｉｌｍｉｃ ｇｒａｉｎ）は、一般的なエンコーダがビデオ品質または圧縮率に対して相当な費用をかけることなく、処理が困難であり無作為に発生するアニメーショングレーン（ａｎｉｍａｔｅｄ ｇｒａｉｎ）を創出する。いくつかのビデオエンコード方法は、エンコードの前にこのような追加の視覚ノイズの除去を試みたが、このような方法はオフライン専用であり、相当の計算費用がかかる。レンダリングパイプラインでこのような特定のポストプロセスを非活性化することにより、ビデオの自動エンコードが容易となる。この後、ビデオがデコードされた後にポストプロセスが適用される。フィルム型グレーンの場合、デコードされたビデオにグレーンを合成することは計算上求められず、デコーダによってリアルタイムで実行することができ、他のエンコードアーティファクトを偽装することによって主観的なビデオ品質を改善することができる。

国際特許出願ＷＯ２０１６１７２３１４ Ａ１（「３１４出願」）は、芸術的意図を基盤としたコンテンツコーディングに関するシステムおよび方法を開示している。コーディングユーザインタフェースは、ユーザが芸術的セットを指定し、忠実度（ｆｉｄｅｌｉｔｙ）向上、ＱＰ調節値、および／またはポストプロセッシングのような芸術的セットと関連するピクセルおよび／またはブロックの処理を構成するように許容する。ビデオ出力に追加されることのできる芸術的意図の例は、エンコーダがエンコードの前にオリジナル信号からフィルムグレーンを除去し、フィルムグレーンＳＥＩを使用してフィルムグレーンを再生成し、ディスプレイされる前にビデオ信号にこれを追加する方法をデコーダに伝達するときを含む。少なくとも「３１４出願」には、エンコードの前にレンダリングパイプラインで特定のポストプロセスを非活性化した後、ビデオがデコードされた後にこのようなポストプロセスを適用することは開示されていないため、本発明は「３１４出願」とは区分される。結果的に、本発明は、ビデオ品質または圧縮率に対して相当な費用をかけずにビデオデータの改善されたエンコードとデコードを提供するため、このようなコンピュータ技術に対する改善であると言える。さらに、本発明は、結果的に、帯域幅、ビットレート、エンコード時間を改善し、改善されたビデオ品質を有するリアルタイムビデオストリーミングアプリケーションに使用することができるため、改善であると言える。

米国特許第９，６０９，３３０号（「‘３３０特許」）は、モードおよびレファレンス類型データのコンテンツ適応エントロピコーディングを開示しているが、これは、エンコーダの事前－分析器（ｐｒｅ－ａｎａｌｙｚｅｒ）サブシステムがコンテンツを分析してビデオコーディング効率および速度性能を改善するのに有用な多様な類型のパラメータを計算することを意味する。このようなパラメータは、水平および垂直グラディエント（ｇｒａｄｉｅｎｔ）情報（Ｒ_ｓ、Ｃ_ｓ）、分散（ｖａｒｉａｎｃｅ）、ピクチャ（ｐｉｃｔｕｒｅ）あたりの空間複雑度（ｓｐａｔｉａｌ ｃｏｍｐｌｅｘｉｔｙ）、ピクチャあたりの時間複雑度（ｔｅｍｐｏｒａｌ ｃｏｍｐｌｅｘｉｔｙ）、シーン（ｓｃｅｎｅ）変化検出、動作範囲推定、ゲイン（ｇａｉｎ）検出、予想距離推定、オブジェクト数推定、領域境界検出、空間複雑度マップ計算、フォーカス（ｆｏｃｕｓ）推定、およびフィルムグレーン推定を含む。言い換えれば、事前－分析器サブシステムによって生成されたパラメータは、エンコーダによって消費されるか量子化されてデコーダに伝達されるようになる。少なくとも‘３３０に開示された技術は、エンコードの前にレンダリングパイプラインで特定のポストプロセスを非活性化した後、ビデオがデコードされた後にこのようなポストプロセスを適用しないため、本発明はこの技術とは区別される。したがって、本発明は、ビデオ品質または圧縮率に対して相当な費用をかけなくても、ビデオデータの改善されたエンコードおよびデコードを提供するため、さらに改善されたビデオ品質を有するリアルタイムビデオストリーミングアプリケーションに使用することができるため、‘３３０特許のコンピュータ技術に対する改善であると言える。

米国特許第９，７６２，９１１号（「’９１１特許」）は、モーションベクトル（ｍｏｔｉｏｎ ｖｅｃｔｏｒ）のコンテンツ適応予測およびエントロピコーディングと関連する技術のためのシステムおよび方法を開示している。開示された技術は、第１ビデオデータと第２ビデオデータがエントロピエンコーダモジュールでのエントロピコーディングのために受信されるように許容する。第１ビデオデータと第２ビデオデータは、相異するデータ類型（例えば、本文書でさらに説明するように、ヘッダ（ｈｅａｄｅｒ）データ、モーフィング（ｍｏｒｐｈｉｎｇ）パラメータ、合成（ｓｙｎｔｈｅｓｉｚｉｎｇ）パラメータ、またはグローバルマップデータまたはモーションベクトルまたはイントラ予測パーティションデータなど）であってよい。第１エントロピエンコード技術は、例えば、第１ビデオデータの圧縮されたビートの数、第１ビデオデータと関連する予め決定されたインジケータ（ｉｎｄｉｃａｔｏｒ）やフラッグ、予め決定された閾値、または経験的に（ｈｅｕｒｉｓｔｉｃａｌｌｙ）決定された閾値などのような第１ビデオデータと関連するパラメータを基盤として第１ビデオデータのために決定されてよい。いくつかの例において、第１エントロピエンコード技術は、適応型（ａｄａｐｔｉｖｅ）シンボルラン（ｓｙｍｂｏｌ－ｒｕｎ）可変長コーディング技術または適応型プロキシ（ｐｒｏｘｙ）可変長コーディング技術のうちの１つが選択されてよい。第１ビデオデータは、第１エントロピエンコード技術によってエントロピエンコードされてよく、第２ビデオデータは、第１エントロピエンコード技術によってエントロピエンコードされてよい。言い換えれば、少なくとも‘９１１特許に記載された技術は、エンコードの前にレンダリングパイプラインでポストプロセスを選択的に非活性化した後、ビデオがデコードされた後にこのようなポストプロセスを適用することを含んでいないため、本発明とは区分される。言い換えれば、本発明は、ビデオ品質や圧縮率に対して相当な費用をかけなくても、ビデオデータの改善されたエンコードおよびデコードを提供するため、‘９１１特許のコンピュータ技術に対する改善であると言える。さらに、本発明は、結果的に、ビットレートおよびエンコード時間を改善し、改善されたビデオ品質を有するリアルタイムビデオストリーミングアプリケーションに使用することができるため、改善であると言える。

上述の説明によって明らかであるが、ゲーム環境でのビデオエンコードと関連する現在のコンピュータ技術に対する改善が、該当の技術分野において必要である。

したがって、本文書に開示された例示的な実施形態の目的は、該当の技術分野の課題を解決し、技術を用いることによって待機時間とエンコード時間を減少させるためのシステムおよび方法を提供することにあり、その技術において、サーバは、クライアントハードウェア（ｄｉｓａｄｖａｎｔａｇｅｓ）性能（ｃａｐａｂｉｌｉｔｙ）を測定するように、クライアントアプリケーション（ｃｌｉｅｎｔ ａｐｐｌｉｃａｔｉｏｎ）に命令語（ｉｎｓｔｒｕｃｔｉｏｎ）を送信し、クライアントハードウェアに対してどれほど多くのポストプロセス延期候補が延期されるようになるかを評価するために、１つ以上の予め決定されたポストプロセス延期候補の既知荷重（ｋｎｏｗｎ ｌｏａｄ）を合算するように、クライアントアプリケーションに命令語を送信する。クライアントアプリケーションにおいてポストプロセス延期リストがコンパイルされ、逆順に構築される。この後、サーバは、ポストプロセス延期リストを受信し、第１ビデオフレームのポストプロセッシングフェーズ（ｐｈａｓｅ）の間、延期されたポストプロセスのリストをスキップし、イメージをレンダリングするように、クライアントアプリケーションに命令語を送信する。

本発明の他の目的は、クライアントハードウェアの性能を再測定するか否かを判断するように、コールバック（ｃａｌｌｂａｃｋ）を実行するか、１つ以上のオペレーティングシステムイベント（ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ ｅｖｅｎｔ）をポーリングするクライアントアプリケーションを有することにより、待機時間およびエンコード時間を減少させるためのシステムおよび方法を提供することにある。

本発明のまた他の目的は、利用可能な命令語セット、メモリ、ＣＰＵおよび／またはＧＰＵ特性を検出することにより、クライアントハードウェアの性能を測定することにより、待機時間およびエンコード時間を減少させるためのシステムおよび方法を提供することにある。

本発明のさらに他の目的は、フレームレート（ｆｒａｍｅ ｒａｔｅ）および／またはリソース使用量（ｒｅｓｏｕｒｃｅ ｕｓａｇｅ）を測定することにより、クライアントハードウェアに対してどれほど多くのポストプロセス延期候補が延期されるようになるかを評価することにより、待機時間およびエンコード時間を減少させるためのシステムおよび方法を提供することにある。

添付の図面は、後述する詳細な説明を参照することでより適切に理解することができるため、本発明の完全な理解およびこれによる多くの利点を容易に得ることができるであろう。

本発明の一実施形態における、遠隔クライアントに示すためのビデオをレンダリングする３Ｄグラフィックスエンジンの例を示したブロック図である。 本発明の一実施形態における、ピクセルあたりの（ｐｅｒ－ｐｉｘｅｌ）ポストプロセッシングを延期させることにより、エンコード時間または主観的なビデオ品質を改善するために求められる段階の例を説明するためのフローチャートである。 本発明の一実施形態における、ビデオレンダリング、エンコード、およびデコードフェーズ間の延期されたピクセルあたりの品質の最小実現の例を示した図である。 本発明の実施形態における、延期されたポストプロセスのリストを同期化するためのサーバ－クライアント間の通信例を説明するためのフローチャートである。

図面に示す発明の好ましい実施形態を記述するにあたり、明確化のために、特定の用語に依存することがある。しかし、本発明は、このように選択された特定の用語に限定されることを意図としておらず、それぞれの特定の用語は、類似の目的を達成するために類似の方式で作動するすべての技術的等価物を含むものと理解されなければならない。本発明の好ましい実施形態は、例示の目的として記述されているが、本発明は、図面に具体的に示されていない他の形態によっても実現可能であることが理解されなければならない。

ポストプロセッシングパイプラインは、アンチエイリアス（ａｎｔｉ－ａｌｉａｓｉｎｇ）、モーションブロー（ｍｏｔｉｏｎｂｌｕｒ）、深度（ｄｅｐｔｈ ｏｆ ｆｉｅｌｄ）、カラーグレーディング（ｃｏｌｏｒ ｇｒａｄｉｎｇ）、ブルーム（ｂｌｏｏｍ）、フィルムグレーン、色収差（ｃｈｒｏｍａｔｉｃ ａｂｅｒｒａｔｉｏｎ）、ビネッティング（ｖｉｇｎｅｔｔｉｎｇ）、およびトーンマッピング（ｔｏｎｅ ｍａｐｐｉｎｇ）を含む多くの複雑なプロセスを実行してよい。このような効果のうちの一部は、エンコードプロセスに極めて有害であり、未処理のフレームと比べると、エンコード時間を増加させて圧縮率を減らす。フレームがデコードされるまで特定のポストプロセスの適用を待つことは、主観的なビデオ品質を向上させ、追加の有益なトレードオフ（ｔｒａｄｅ ｏｆｆ）などの提供に繋がる。

クライアントアプリケーションを開発（ｄｅｖｅｌｏｐｍｅｎｔ）するとき、エンコード時間、帯域幅、および主観的な品質の均衡は、ポストプロセスが延期に適した候補であるかを判断するように、レンダリングパイプラインで各ポストプロセスのために評価されなければならない。延期候補のリストは、クライアントで延期されるようになるポストプロセスを決定するように、ランタイム（ｒｕｎｔｉｍｅ）内にクライアントによって使用されるであろう。

各ポストプロセスは、その効果がエンコードプロセスに及ぼす程度を測定するようにテストされなければならない。先ず、一連のレファレンスフレーム（ｒｅｆｅｒｅｎｃｅ ｆｒａｍｅ）は、変更されない（ｕｎａｌｔｅｒｅｄ）レンダリングおよびエンコードパイプラインを経て供給されなければならず、エンコード時間とエンコードされたフレームサイズが測定されなければならない。ポストプロセスは、レンダリングパイプラインで１度に１つずつ解除されなければならず、エンコード時間とエンコードされたフレームサイズは、制御結果と比較されなければならない。このような測定は、ポストプロセスの延期に適した候補であるかを知らせるために役立つであろう。増加したエンコードされたフレームサイズによって測定されるイメージエントロピを増加させる殆どすべてのポストプロセス効果は、延期に適した候補になるであろう。例えば、シミュレーションされたフィルム型グレーン（ｓｉｍｕｌａｔｅｄ ｆｉｌｍｉｃ ｇｒａｉｎ）ポストプロセスは、イメージにランダムノイズ（ｒａｎｄｏｍ ｎｏｉｓｅ）を追加して圧縮率を低める。特定の状況において、色収差およびブルームは、イメージエントロピを増加させ、その結果として圧縮率を低めるようになる。エントロピまたはイメージデータを減少させる殆どすべてのポストプロセス効果は延期されなければならないが、これは、エントロピの減少がエンコードオーバヘッドを減少させることになるためである。

イメージエントロピを変更しないポストプロセスは、主観的なビデオ品質の改善またはサーバ負荷の減少のような二次的な目標を達成するために、延期候補として選択されてよい。例えば、カラーグレーディングは、エンコード時間または帯域幅の使用に影響を及ぼさないこともあるが、クライアントに延期されるときには、サーバ側の計算負荷で注目するだけの減少をもたらすようになる。これと同様に、アンチエイリアスは、延期されるときに主観的なビデオ品質を改善し、サーバ側の負荷を大きく減少させることができる。追加のテストは、これがエントロピ－中立的な（ｅｎｔｒｏｐｙ－ｎｅｕｔｒａｌ）ポストプロセスを延期させるのに有利であるかを判断するように実行されなければならない。例えば、レファレンスフレームを使用する類似のテスト手順は、エントロピ－中立的なポストプロセスを延期させる前後のサーバ負荷を比較するために使用されてよい。

クライアントアプリケーションは、各延期候補のためにポストプロセッシング計算を実行しなければならない。いくつかのコード（ｃｏｄｅ）のリファクタリング（ｒｅｆａｃｔｏｒｉｎｇ）が、このような機能をクライアントアプリケーションに移動させるために必要となる場合がある。フィルム型グレーン、色収差、またはビネティングのようなレンダリングパイプラインの末端でのポストプロセスは、一般的に、アンチエイリアスまたは深度のようなレンダリングパイプラインで初期に発生するものよりも、クライアントアプリケーションに移動する方が容易である。ポストプロセスを延期させることが、これが色収差、ブルーム、またはビネティングのようなトーンマッピング前に適用されるこのようなポストプロセスのような線形空間に一般的に適用されるとき、これが非線形空間に適用されることで引き起こるいくつかのケースが考えられる。プロセスはガンマ空間に直接に適用されてよく、数学的に正確でない場合もあるが、その差はビューア（ｖｉｅｗｅｒ）では認識することができず、全体の主観的な品質が改善されるようになる。そうでなければ、いくつかのクライアント側の計算周期（ｃｏｍｐｕｔｅ ｃｙｃｌｅ）の費用とイメージ品質の損失により、クライアントアプリケーションがイメージを線形空間に再変換し、ポストプロセスを適用した後、ガンマ空間に再変換することも可能ではある。しかし、イメージは、エンコード中に量子化されて圧縮されるはずであるため、線形空間への再変換は、一部の品質を低下させることになるであろう。このような主観的な品質決定は、クライアントアプリケーションの開発（ｄｅｖｅｌｏｐｍｅｎｔ）中に行われなければならない。

クライアントアプリケーションが実行することのできるすべてのポストプロセスは、延期候補リストの基礎を形成する。延期候補のリストは、いずれかの従属性を維持するために、レンダリングパイプラインに現れる手順と等しくなければならない。さらに、リストにおいて、各延期候補は、メモリ最小値またはＧＰＵ要求事項のようなハードウェアの特徴要求事項と対をなさなければならない。

図１は、ビデオレンダリング中にピクセル品質（ｐｉｘｅｌ－ｑｕａｌｉｔｙ）ポストプロセスが延期されたシステムの例を示した図である。このようなシステムの例は、他の類型のビデオシステムと比較するとき、ピクセルあたりの（ｐｅｒ－ｐｉｘｅｌ）品質プロセスを延期させることにより、提供される主観的な品質改善と減少されたエンコード時間から最大の利点を得ることのできるリアルタイム遠隔ゲームストリーミングアプリケーションを示す。このようなシステムにおいて、サーバ１００は、ビデオ出力をレンダリングするビデオゲームソフトウェア１０２と、グラフィックスエンジン１０４をホスティングする。ビデオは、コーデック（ｃｏｄｅｃ）１０６でエンコードされ、エンコードされたビデオデータ１０８は遠隔クライアントに送信される。サーバアキテクチャ１００は、グラフィックスエンジン１０４とコーデック１０６の両者の機能をすべて支援することのできるハードウェアまたはソフトウェアのいずれかの組み合わせである。図に示す例において、グラフィックスエンジン１０４は、例えば、いくつかのコンピュータ読み取り可能なメモリ１１２にロードされたビデオゲームソフトウェア１０２を実行するＧＰＵ１１０として実現可能であり、コーデック１０６（エンコーダともいう）は、ビデオエンコードソフトウェアを実行するＣＰＵ１１４として実現可能である。

遠隔クライアントコンピュータシステム１１６は、送信されたエンコードされたビデオデータ１０８をデコードするようにクライアント側のコーデック１１８を実行させ、延期されたピクセル品質ポストプロセスを適用するようにクライアントアプリケーション１２０を実行させてよい。また、クライアントコンピュータシステム１１６は、ディスプレイハードウェア（ｄｉｓｐｌａｙ ｈａｒｄｗａｒｅ）１２４を実行させるためのディスプレイコントローラ（ｄｉｓｐｌａｙ ｃｏｎｔｒｏｌｌｅｒ）１２２を含む。クライアント側の入力周辺装置１２６からの入力は、クライアントアプリケーション１２０により、サーバ１００上で実行されるゲームソフトウェア１０２に再送信されるコントロールデータ（ｃｏｎｔｒｏｌ ｄａｔａ）１２８に変換されるであろう。延期されたピクセル品質ポストプロセッシングの特定の実現に基づき、正確なポストプロセスが与えられたビデオフレームのために適用されるように保障するために、いくつかの追加のコントロールデータ１２８がサーバ側のソフトウェア１０２からクライアントアプリケーション１２０に動く必要がある。

図２は、ビデオをレンダリング、エンコード、およびデコードするシステにおいて、ポストプロセッシングを延期させるために求められる段階を示している。段階２００で、レンダリングパイプラインがサーバ１００で通常どおりに（ａｓ ｕｓｕａｌ）始まる。ポストプロセッシングフェーズの前に、レンダリングプロセスに対する変化は必要ない。
段階２０２で、サーバ１００のグラフィックスエンジン１０４でのビデオレンダリングポストプロセッシングフェーズにおいて、いずれかの延期されるポストプロセスがスキップ（ｓｋｉｐ）されなければならない。クライアントコンピュータシステム１１６がすべての延期されたポストプロセスを適用するために求められる計算能力を有すれば、いずれかの数のポストプロセスがスキップされるようになる。図４は、サーバ１００によってポストプロセスが延期されるかを判断する方法をさらに詳細に説明する。いずれかの延期されたポストプロセスをスキップした後、レンダリングパイプラインは、フレームが完全にレンダリングされるまで継続しなければならない。

段階２０４で、結果フレームは、コーデック１０６でエンコードされる。延期されたポストプロセスの選択に基づき、エンコード時間はより速く、エンコードされたデータはさらに少ない帯域幅を必要とするようになる。例えば、フィルム型グレーンポストプロセスが延期されると、コーデック１０６は、導入されるノイズなく、フレームをエンコードするのにさらに容易な時間を有するであろう。

段階２０６で、エンコードされたビデオデータ１０８は、必要によっては、格納されるか、遠隔クライアントコンピュータシステム１１６に送信される。リアルタイムビデオゲームストリーミングアプリケーションにおいて、図１に示す例のように、ビデオデータ１０８は即時に送信されるであろう。他の実施形態に係るシステムにおいて、エンコードされたビデオデータ１０８は、注文型ストリーミング（ｄｅｍａｎｄ ｓｔｒｅａｍｉｎｇ）のためにサーバ１００に格納されるか、物理的メディアに格納されてよい。

段階２０８で、エンコードされたビデオは、遠隔クライアントコンピュータシステム１１６のコーデック１１８でデコードされる。デコードプロセスに変更される必要はない。

段階２１０で、ソフトウェアアプリケーションは、レンダリングパイプラインに現れるときと同じ順序で、延期されたいずれかのポストプロセスを適用するであろう。また、クライアントアプリケーション１２０として、図１に示すようなソフトウェアは、延期されたポストプロセスがフレームごとに変更されると、サーバ１００からコントロールデータ１２８を受信する必要がある場合がある。また、クライアントアプリケーション１２０は、ビデオゲームストリーミングシステムのようにビデオが会話形式であれば、コントロールデータ１２８を送信する必要がある場合がある。クライアントアプリケーション１２０は、延期されたポストプロセスの計算複雑度の要求事項にしたがってスパース（ｓｐａｒｓｅ）してよく、これは、クライアントで広範囲の計算能力を許容してよい。

図３は、図１のシステムで延期されたポストプロセッシングを実現する例を示した図である。サーバ１００に位置する「レンダリングパイプライン」段階３００に示される一般的な３Ｄレンダリングパイプラインは、「アプリケーション」段階３０２、「ジオメトリ（ｇｅｏｍｅｔｒｙ）」段階３０４、および「ラスタライゼーション（ｒａｓｔｅｒｉｚａｔｉｏｎ）」段階３０６に示されるラスタライゼーションフェーズによって実行される。「ラスタライゼーション」段階３０６において、ラスタライゼーションフェーズの出力は、完全なビデオフレームであって、これは「ポストプロセッシング」段階３０８でポストプロセッシングによって大体が向上する。いくつかのポストプロセスは、「エンコード」段階３１０でエンコードプロセス中にエンコード時間または帯域幅に悪影響を及ぼし、このようなポストプロセスは、クライアントが後にこれらを適用するようになれば、「ポストプロセッシング」段階３０８のポストプロセッシングフェーズでスキップされる。クライアント１１６に対して延期されなかった残りのポストプロセスは、「ポストプロセッシング」段階３０８でポストプロセッシング中に通常どおりに（ａｓ ｕｓｕａｌ）適用される。出力されるビデオフレームは「エンコード」段階３１０でエンコードされ、「送信」段階３１２で送信される。

クライアント１１６は、エンコードされたビデオフレームを受信し、これは「デコード」段階３１４でデコードされる。この時点で、すべての延期されたポストプロセスが「延期されたポストプロセッシング」段階３１６でデコードされたフレームに適用される。例えば、フィルム型グレーンの場合、アニメーション効果（ａｎｉｍａｔｅｄ ｅｆｆｅｃｔ）は予めキャッシングされ、比較的低い計算費用でデコードされたフレームに合成されようになる。カラーグレーディング、ディザリング（ｄｉｔｈｅｒｉｎｇ）およびビデオ鮮明化のためのリアルタイムソリューション（ｓｏｌｕｔｉｏｎ）が既に存在しており、クライアントの計算能力に基づいて適用されるようになる。結果、ビデオフレームは、「ディスプレイ」段階３１８でディスプレイされる。

図４は、クライアントアプリケーション１２０が延期されるポストプロセスのリストを構築してサーバ１００にリストを伝達するプロセスを示している。

段階４００において、クライアントアプリケーション１２０は、クライアント１１６に対して延期されるようになるポストプロセスを決定するように、クライアントハードウェアの性能を測定するであろう。クライアント性能は、利用可能な命令語セット、メモリ、ＣＰＵまたはＧＰＵのようなハードウェア情報に対する特徴検出によって測定されてよい。

段階４０２で、クライアントアプリケーション１２０は、延期候補のリストを読み取り、クライアントによってハードウェア要求事項が満たされていない延期候補を廃棄する。延期候補ポストプロセスは、リアルタイムクライアント性能を測定するようにクライアントでベンチマーキング（ｂｅｎｃｈｍａｒｋｉｎｇ）されなければならない。延期候補は、クライアントがこれ以上、フレームレート（ｆｒａｍｅ ｒａｔｅ）、リソース使用量（ｒｅｓｏｕｒｃｅ ｕｓａｇｅ）、または他のリアルタイム測定によって測定された好ましい性能を維持することができなくなるまで、ベンチマーキングプロセスに１度に１つずつ追加される。ベンチマーキングは、クライアントアプリケーションのインストール中、クライアントアプリケーション１２０の初期負荷中、またはアプリケーションの負荷ごとに、実行されてよい。

クライアント１１６は、できるだけ多くの延期候補に対してポストプロセッシングを実行しなければならない。延期リストは、全体作業の順序をオリジナルレンダリングパイプラインの順序に近づけて維持するために逆順に構築される。例えば、モバイルデバイス（ｍｏｂｉｌｅ ｄｅｖｉｃｅ）は、最後のポストプロセスだけを実行してよく、ラップトップ（ｌａｐｔｏｐ）は、レンダリングパイプラインの末端から３つのポストプロセスを実行してよい反面、新たなデスクトップ（ｄｅｓｋｔｏｐ）コンピュータは、延期候補リストのすべてのポストプロセスを実行してよい。

段階４０４で、クライアント１１６は、延期させるポストプロセスのリストをサーバ１００に送信する。

段階２０２で、サーバ１００は、第１ビデオフレームのポストプロセッシングフェーズ中に延期されたポストプロセスのリストを使用する。延期リストのすべてのポストプロセスはスキップされる。

段階２０６で、エンコードされたビデオデータストリーム１０８は、クライアント１１６への送信を始める。クライアント１１６は、いずれかのフレームが生成される前に延期リストを送信したため、追加のメタデータがサーバ１００からクライアント１１６に送信される必要はない。クライアント１１６は、ポストプロセスが延期されたことを自動で知ることになるであろう。

段階２１０で、クライアント１１６は、すべてのポストプロセスを延期リストに適用する。クライアント１１６は、追後のフレームに延期されたポストプロセスを継続して適用するであろう。

ランタイム中にクライアント性能が変わることにより、延期されたポストプロセスのリスト変更を求めるというシナリオが考えられる。例えば、クライアントアプリケーションがバッテリ節約モードに突入したモバイルデバイスで実行されていれば、クライアントは、延期されたポストプロセスのリストの縮小を試みるようになる。このような例において、クライアントアプリケーションは、バッテリ状態の変化に応じて受信するため、コールバック（ｃａｌｌｂａｃｋ）を登録するか、オペレーティングシステム（ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ：ＯＳ）イベントなどをポーリングする必要が生じるようになる。段階４１２で、クライアントアプリケーション１２０は、クライアント性能を再測定することにより、最近の環境変化に応答する。環境変化は、遠隔クライアントコンピュータシステム１１６のハードウェア性能に影響を及ぼす、何らかの変化であってよい。上述した例として、バッテリ節約モードは、直接にフェッチ（ｆｅｔｃｈ）される倍率（ｍｕｌｔｉｐｌｉｅｒ）でクロックレート（ｃｌｏｃｋ ｒａｔｅ）を減らす。クロックレートの倍率の変化は、クライアント性能の変化に対する大略的な推定を提供することができる。そうでなければ、バッテリ節約モードでの追加のベンチマーキングは、段階４０２で説明したベンチマーキングフェーズに追加されてよい。

クライアント性能が変わると、クライアントアプリケーション１２０は、段階４１４で延期されるようになるポストプロセスを再評価するであろう。バッテリ節約モードを例に挙げると、延期リストは、クロックレートの倍率の変化に比例して減少するようになる。例えば、バッテリ節約モードは、５０％程度のクロックレートを減らせば、延期リストを少なくとも半分程度に減らすことができるであろう。クライアント１１６が４つのポストプロセスを延期させたとすれば、リストを２つのポストプロセスに減らすことができるであろう。そうでなければ、バッテリ節約モードのベンチマーキングが既に実行されていれば、延期リストは既に認知されているはずである。

延期リストが変わると、クライアント１１６は、段階４１６において、変更された延期リストをサーバ１００に送信するであろう。クライアント１１６は、サーバ１００からメッセージを受信するまで、オリジナル延期リストからのポストプロセスを継続して適用するはずであり、メッセージは、他の延期されたポストプロセスのリストで構成されることが好ましい。

段階４１８で、サーバ１００は、次の利用可能なフレームに変更された延期リストを適用する。クライアント１１６と同期化するために、一部のメタデータがこのフレームに適用される。

段階４２０で、エンコードされたビデオデータ１０８のフレームは、これに対応するメタデータとともに送信される。

クライアントは、メタデータフラッグ（ｆｌａｇ）を受信するまで待機する。段階４２２で、クライアント１１６は、変更された延期リストにしたがってフレームの処理を始める。クライアント１１６は、変更された延期リストにしたがい、延期されたポストプロセスを継続して適用するであろう。ランタイム環境が再び変わると、段階４１２から始まり、延期リストは再び増加したり減少したりするようになる。延期リストがモバイルデバイスのバッテリ節約モードのような一時的なランタイム環境変化によって縮小されると、クライアントアプリケーション１２０は、可能な限り最大のポストプロセスが与えられた時間に延期されるように、最も早い機会に延期リストを増加させなければならない。

例１：ベンチマーキングテストの結果
フィルム型グレーンは、エンコーダの圧縮率に大きな影響をもたらす、無作為に発生する視覚的ノイズを出す。クライアント側にフィルム型グレーンのようなポストプロセスを適用することは、エンコードされたフレームサイズがより小さくなるという結果をもたらすであろう。

実験的なビットレート値は、グラフィックスエンジンが１秒あたり６０フレームで１２８０×７２０の解像度で出力を生成する間に採択され、平均ビットレートを見つけ出すために６０フレームに渡って平均した。測定された値は、サーバ側でフィルム型グレーンが適用されるビデオストリームのビットレートと、フィルム型グレーンがクライアントに対して延期されたビデオストリームのビットレートとを比較する。このような測定は、３種類の大きさのフィルム型グレーンと２つのエンコーダ品質設定値に対して繰り返される。フィルム型グレーン１は最も小さなグレーンサイズを示す反面、フィルム型グレーン３は最大のグレーンサイズを示す。実験結果は、以下の表１および表２に示した。表１は１６のエンコーダ品質を使用した結果を示しており、表２は２０のエンコーダ品質を使用した結果を示している。

実験結果に基づき、フィルム型グレーンのようなポストプロセスは、より大きなエンコードされたフレームサイズをもたらすことが分かるが、これは好ましくないことが明らかである。このような否定的な影響は、エンコーダ品質値が高いほどより明らかになり、導入したノイズの量が増加することによってより明らかになる。しかし、クライアントに対してフィルム型グレーンを延期させることにより、ビットレートにおける劇的な減少は、表１および表２に示すように達成されるようになるが、ここで、ビットレートはそれぞれ、２７０Ｋｂｙｔｅ／ｓおよび１４０Ｋｂｙｔｅ／ｓに減少する。導入したノイズの量とは関係なく、このような実験でフィルム型グレーンのサイズによって測定されることにより、ビットレートは与えられたエンコーダ品質に対して安定的に維持される。

これと同様に、以下の表３に示すように、グラフィックスエンジンが多数のエンコーダ品質設定のために６０フレームで１２８０×７２０の解像度で出力を生成する間、実験的なエンコード時間が測定された。測定された値は、サブ側でフィルム型グレーンが適用されるビデオストリームに対するエンコード時間と、フィルム型グレーンがクライアントに対して延期されたビデオストリームのエンコード時間とを比較する。フィルム型グレーンのサイズは、すべての測定で固定的に維持される。表３に示すように、本文書で説明される技術を適用するエンコード時間の減少は、より高いエンコーダ品質の設定でより明らかになることを確認することができる。

上述した説明および図面は、本発明の原理を例示するためのものに過ぎない。本発明は、好ましい実施形態によって制限されるように意図されてはならず、該当の技術分野において通常の知識を有する者にとって明白である、多様な方式で実現されるであろう。本発明の多数の応用は、該当の技術分野において通常の知識を有する者によって容易に実現されるであろう。したがって、開示された特定の例示または図に示されて説明された正確な構成と動作によって本発明を制限することは好ましくない。むしろ、すべての適切な修正および均等物が、本発明の範囲内に属するものと理解されなければならない。
〔付記１〕
段階を含むポストプロセス（ｐｏｓｔ－ｐｒｏｃｅｓｓ）を延期させる（ｄｅｆｅｒｒｉｎｇ）のためにコンピュータで実現される方法であって、
段階は、
クライアントハードウェア（ｃｌｉｅｎｔ ｈａｒｄｗａｒｅ）性能（ｃａｐａｂｉｌｉｔｙ）を測定するように、クライアントアプリケーション（ｃｌｉｅｎｔ ａｐｐｌｉｃａｔｉｏｎ）に命令語（ｉｎｓｔｒｕｃｔｉｏｎ）を送信する段階、および
クライアントハードウェアに対してどれほど多くのポストプロセス延期候補が延期されるようになるかを評価するために、１つ以上の予め決定されたポストプロセス延期候補の既知荷重（ｋｎｏｗｎ ｌｏａｄ）を合算するように、クライアントアプリケーションに命令語を送信する段階を含み、
ポストプロセス延期リストがコンパイルされ、
前記ポストプロセス延期リストは逆順に構築され、
サーバが前記ポストプロセス延期リストを受信し、第１ビデオフレームのポストプロセッシングフェーズ（ｐｈａｓｅ）の間、延期されたポストプロセスのリストをスキップし、イメージをレンダリングするように、クライアントアプリケーションに命令語を送信する、方法。
〔付記２〕
前記ポストプロセス延期リストは、ベンチマーキング（ｂｅｎｃｈｍａｒｋｉｎｇ）プロセスに追加される、付記１に記載の方法。
〔付記３〕
前記クライアントアプリケーションは、
１つ以上の環境変化に応答して前記クライアントハードウェアの前記性能を再測定する、付記１に記載の方法。
〔付記４〕
前記クライアントアプリケーションは、
前記クライアントハードウェアの前記性能を再測定するか否かを判断するように、コールバック（ｃａｌｌｂａｃｋ）を実行するか、１つ以上のオペレーティングシステムイベント（ｏｐｅｒａｔｉｎｇ ｓｙｓｔｅｍ ｅｖｅｎｔ）をポーリングする、付記３に記載の方法。
〔付記５〕
前記クライアントアプリケーションは、
フレームレート（ｆｒａｍｅｒａｔｅ）および／またはリソース使用量（ｒｅｓｏｕｒｃｅ ｕｓａｇｅ）を測定することにより、前記クライアントハードウェアに対してどれほど多くのポストプロセス延期候補が延期されるようになるかを評価する、付記１に記載の方法。
〔付記６〕
前記サーバは、
次の利用可能なビデオフレームにアップデートされた延期リストを適用する、付記１に記載の方法。
〔付記７〕
前記サーバがポストプロセスと関連するメタデータなしで、前記クライアントアプリケーションにエンコードされたビデオデータを送信する段階をさらに含む、付記１に記載の方法。
〔付記８〕
前記クライアントハードウェアの前記性能は、
利用可能な命令語セット、メモリ、ＣＰＵおよび／またはＧＰＵ特性を検出することによって測定される、付記１に記載の方法。
〔付記９〕
前記ポストプロセス延期候補のリストは、
前記クライアントハードウェアのバッテリ状態に対する変化を基盤として再計算される、付記１に記載の方法。
〔付記１０〕
前記サーバは、
メタデータフラッグ（ｍｅｔａｄａｔａ ｆｌａｇ）とともに、前記クライアントアプリケーションに前記第１または次の利用可能なビデオフレームをリターンする、付記１に記載の方法。
〔付記１１〕
ポストプロセスを延期させるためのシステムであって、ネットワークを介し、サーバは、
クライアントハードウェア性能を測定するように、クライアントアプリケーションに命令語を送信し、
クライアントハードウェアに対してどれほど多くのポストプロセス延期候補が延期されるようになるかを評価するために、１つ以上の予め決定されたポストプロセス延期候補の既知荷重を合算するように、クライアントアプリケーションに命令語を送信し、
ポストプロセス延期リストがコンパイルされ、
前記ポストプロセス延期リストは逆順に構築され、
サーバが前記ポストプロセス延期リストを受信し、第１ビデオフレームのポストプロセッシングフェーズの間、延期されたポストプロセスのリストをスキップし、イメージをレンダリングするように、クライアントアプリケーションに命令語を送信する、システム。
〔付記１２〕
前記ポストプロセス延期リストは、ベンチマーキングプロセスに追加される、付記１１に記載のシステム。
〔付記１３〕
前記クライアントアプリケーションは、
１つ以上の環境変化に応答して前記クライアントハードウェアの前記性能を再測定する、付記１１に記載のシステム。
〔付記１４〕
前記クライアントアプリケーションは、
前記クライアントハードウェアの前記性能を再測定するか否かを判断するように、コールバックを実行するか、１つ以上のオペレーティングシステムイベントなどをポーリングする、付記１３に記載のシステム。
〔付記１５〕
前記クライアントアプリケーションは、
フレームレートおよび／またはリソース使用量を測定することにより、前記クライアントハードウェアに対してどれほど多くのポストプロセス延期候補が延期されるようになるかを評価する、付記１１に記載のシステム。
〔付記１６〕
前記サーバは、
次の利用可能なビデオフレームにアップデートされた延期リストを適用する、付記１１に記載のシステム。
〔付記１７〕
前記サーバは、
ポストプロセスと関連するメタデータなしで、前記クライアントアプリケーションにエンコードされたビデオデータを送信する、付記１１に記載のシステム。
〔付記１８〕
前記クライアントハードウェアの前記性能は、
利用可能な命令語セット、メモリ、ＣＰＵおよび／またはＧＰＵ特性を検出することによって測定される、付記１１に記載のシステム。
〔付記１９〕
前記ポストプロセス延期候補のリストは、
前記クライアントハードウェアのバッテリ状態に対する変化を基盤として再計算される、付記１１に記載のシステム。
〔付記２０〕
前記サーバは、
メタデータフラッグとともに、前記クライアントアプリケーションに前記第１または次の利用可能なビデオフレームをリターンする、付記１１に記載のシステム。

Claims (15)

1. ポストプロセス（ｐｏｓｔ－ｐｒｏｃｅｓｓ）を延期させる（ｄｅｆｅｒｒｉｎｇ）のためにコンピュータで実現される方法であって、
   クライアントハードウェア（ｃｌｉｅｎｔ ｈａｒｄｗａｒｅ）性能（ｃａｐａｂｉｌｉｔｙ）を測定するように、クライアントアプリケーション（ｃｌｉｅｎｔ ａｐｐｌｉｃａｔｉｏｎ）に命令語（ｉｎｓｔｒｕｃｔｉｏｎ）を送信する段階、および
   クライアントハードウェアに対してどれほど多くのポストプロセス延期候補が延期されるようになるかを評価するために、１つ以上の予め決定されたポストプロセス延期候補の既知荷重（ｋｎｏｗｎ ｌｏａｄ）を合算するように、クライアントアプリケーションに命令語を送信する段階
   を含み、
   ポストプロセス延期リストは逆順にコンパイルされ、
   サーバは、前記ポストプロセス延期リストを受信し、第１ビデオフレームのポストプロセッシングフェーズ（ｐｈａｓｅ）の間、前記リストに含まれるポストプロセスをスキップし、イメージをレンダリングするようにクライアントアプリケーションに命令語を送信する、
   コンピュータで実現される方法。
2. 前記サーバは、メタデータフラッグ（ｍｅｔａｄａｔａ ｆｌａｇ）とともに、前記クライアントアプリケーションに前記第１ビデオフレームまたは次の利用可能なビデオフレームをリターンする、請求項１に記載のコンピュータで実現される方法。
3. 前記サーバがポストプロセスと関連するメタデータなしで、前記クライアントアプリケーションにエンコードされたビデオデータを送信する段階をさらに含む、請求項１に記載のコンピュータで実現される方法。
4. ポストプロセスを延期させるためのシステムであって、ネットワークを介し、サーバは、
   クライアントハードウェア性能を測定するように、クライアントアプリケーションに命令語を送信し、
   クライアントハードウェアに対してどれほど多くのポストプロセス延期候補が延期されるようになるかを評価するために、１つ以上の予め決定されたポストプロセス延期候補の既知荷重を合算するように、クライアントアプリケーションに命令語を送信し、
   ポストプロセス延期リストは逆順にコンパイルされ、
   サーバは、前記ポストプロセス延期リストを受信し、第１ビデオフレームのポストプロセッシングフェーズの間、前記リストに含まれるポストプロセスをスキップし、イメージをレンダリングするようにクライアントアプリケーションに命令語を送信する、システム。
5. 前記サーバは、メタデータフラッグ（ｍｅｔａｄａｔａ ｆｌａｇ）とともに、前記クライアントアプリケーションに前記第１ビデオフレームまたは次の利用可能なビデオフレームをリターンする、請求項４に記載のシステム。
6. 前記サーバは、ポストプロセスと関連するメタデータなしで、前記クライアントアプリケーションにエンコードされたビデオデータを送信する、請求項４に記載のシステム。
7. ポストプロセスを延期させるためのコンピュータで実現される方法であって、
   クライアントコンピュータから受信したポストプロセス延期リストであって、前記クライアントコンピュータにおけるポストプロセスのベンチマーキングに少なくとも基づき構築された前記ポストプロセス延期リストを使用して、延期のための１つ以上のポストプロセスを識別する段階、
   １つ以上の識別された前記ポストプロセスをスキップする段階、
   コーデックで１つ以上のフレームを１つ以上のエンコードされたビデオにエンコードする段階であって、スキップされた前記ポストプロセスは、エンコードには使用されない、段階、および、
   前記１つ以上のエンコードされたビデオを前記クライアントコンピュータに送信する段階であって、前記クライアントコンピュータは、スキップされた前記ポストプロセスを出力前の前記エンコードされたビデオに適用する、段階
   を含む、コンピュータで実現される方法。
8. ポストプロセスのスキップは、グラフィックスエンジン（ｇｒａｐｈｉｃｓ ｅｎｇｉｎｅ）で起こる、請求項７に記載のコンピュータで実現される方法。
9. 前記エンコードされたビデオのうちの少なくとも１つは、前記クライアントコンピュータへの送信前にサーバに格納される、請求項７に記載のコンピュータで実現される方法。
10. 前記ポストプロセス延期リストは、前記クライアントコンピュータの計算能力（ｃｏｍｐｕｔａｔｉｏｎ ｐｏｗｅｒ）にも基づき構築された、請求項７に記載のコンピュータで実現される方法。
11. 前記サーバは、前記クライアントコンピュータからコントロールデータを受信する、請求項９に記載のコンピュータで実現される方法。
12. ポストプロセスを延期させるためのシステムであって、ネットワークを介し、サーバは、
    クライアントコンピュータから受信したポストプロセス延期リストであって、前記クライアントコンピュータにおけるポストプロセスのベンチマーキングに少なくとも基づき構築された前記ポストプロセス延期リストを使用して、延期のための１つ以上のポストプロセスを識別することと、
    １つ以上の識別された前記ポストプロセスをスキップすることと、
    コーデックで１つ以上のフレームを１つ以上のエンコードされたビデオにエンコードすることであって、スキップされた前記ポストプロセスは、エンコードには使用されない、エンコードすることと、
    前記１つ以上のエンコードされたビデオをクライアントコンピュータに送信することであって、前記エンコードされたビデオのうちの少なくとも１つは、前記クライアントコンピュータへの送信前に格納される、送信することと
    を行う、システム。
13. ポストプロセスのスキップは、グラフィックスエンジン（ｇｒａｐｈｉｃｓ ｅｎｇｉｎｅ）で起こる、請求項１２に記載のシステム。
14. 前記エンコードされたビデオのうちの少なくとも１つは、前記クライアントコンピュータへの送信前にサーバに格納される、請求項１２に記載のシステム。
15. 前記ポストプロセス延期リストは、前記クライアントコンピュータの計算能力にも基づき構築された、請求項１２に記載のシステム。

Images