(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-12-18
(54)【発明の名称】没入型ビデオにおけるビデオトラックの変更
(51)【国際特許分類】
H04N 21/431 20110101AFI20231211BHJP
H04N 21/435 20110101ALI20231211BHJP
【FI】
H04N21/431
H04N21/435
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023533867
(86)(22)【出願日】2021-12-03
(85)【翻訳文提出日】2023-06-02
(86)【国際出願番号】 EP2021084150
(87)【国際公開番号】W WO2022122580
(87)【国際公開日】2022-06-16
(32)【優先日】2020-12-11
(33)【優先権主張国・地域又は機関】EP
(81)【指定国・地域】
(71)【出願人】
【識別番号】590000248
【氏名又は名称】コーニンクレッカ フィリップス エヌ ヴェ
【氏名又は名称原語表記】Koninklijke Philips N.V.
【住所又は居所原語表記】High Tech Campus 52, 5656 AG Eindhoven,Netherlands
(74)【代理人】
【識別番号】100122769
【氏名又は名称】笛田 秀仙
(74)【代理人】
【識別番号】100163809
【氏名又は名称】五十嵐 貴裕
(74)【代理人】
【識別番号】100145654
【氏名又は名称】矢ヶ部 喜行
(72)【発明者】
【氏名】クローン バルト
(72)【発明者】
【氏名】ファン ヘースト バルトロメウス ウィルヘルムス ダミアヌス
【テーマコード(参考)】
5C164
【Fターム(参考)】
5C164MB13S
5C164PA31
5C164SB08S
5C164SB29S
5C164UB02S
5C164UB10S
5C164UB93P
5C164UD44S
(57)【要約】
マルチトラックビデオをレンダリングするときに、ビデオトラックの第1のセットVT1からビデオトラックの第2のセットVT2に遷移するための方法であって、各ビデオトラックは対応するレンダリング優先度を有する。本方法は、第1のセットの第1のビデオトラックVT1から第2のセットの第2のビデオトラックVT2に遷移する命令を受信することと、ビデオトラックVT2を取得することと、ビデオトラックVT2がビデオトラックVT1と異なる場合、ビデオトラックの第1のセットVT1内のビデオトラックのうちの1つまたは複数のレンダリング優先度に低減関数を適用することと、および/または、ビデオトラックの第2のセットVT2内の1つまたは複数のビデオトラックのレンダリング優先度に増大関数を適用することを含む。低減関数および増大関数は、それぞれ、レンダリングの優先度を経時的に低減および増大させる。レンダリング優先度は、マルチトラックビデオをレンダリングするために使用されるビデオトラックおよび/またはビデオトラックの要素の重み付けの決定に使用される。
【特許請求の範囲】
【請求項1】
マルチトラックビデオをレンダリングするときにビデオトラックの第1のセットVT1からビデオトラックの第2のセットVT2に遷移するための方法であって、それぞれのビデオトラックは対応するレンダリング優先度を有し、当該方法は、
ビデオトラックVT1からビデオトラックVT2へと遷移する命令を受信し、
前記ビデオトラックVT2を取得し、
前記ビデオトラックVT2が前記ビデオトラックVT1と異なる場合に、ビデオトラックの第1のセットVT1内の1つまたは複数のビデオトラックのレンダリング優先度に対して、時間とともにレンダリング優先度を低減させる低減関数を適用し、および/または、ビデオトラックVT2のうちの1つまたは複数のレンダリング優先度に対して、レンダリング優先度を時間とともに増大させる増大関数を適用し、
ビデオトラックのうちの1つまたは複数のレンダリング優先度は、マルチトラックビデオをレンダリングするときに、それぞれのビデオトラックおよび/またはビデオトラックの要素の重み付けを選択する際に使用される、方法。
【請求項2】
前記低減関数および/または前記増大関数は、
0.2秒から2秒の間、または
3フレームから60フレームの間、
の期間にわたって前記レンダリング優先度を変更するように構成される、請求項1に記載の方法。
【請求項3】
前記ビデオトラックVT2を取得することは、
サーバシステムからのビデオトラックVT2を要求すること、または
サーバシステムからビデオトラックVT2を受信すること
に基づく、請求項1または2に記載の方法。
【請求項4】
ビデオトラックVT1からビデオトラックVT2に遷移するときに、後続フレームのうちの1つまたは複数の欠落データを修復するために、前記マルチトラックビデオおよび/または前記ビデオトラックVT1の最新の利用可能なフレームのうちの1つまたは複数を保持することを含む、請求項1から3のいずれか一項に記載の方法。
【請求項5】
ビデオトラックVT1の1つもしくは複数および/もしくはビデオトラックVT2の1つもしくは複数の解像度を低下させること、
ビデオトラックVT1の1つもしくは複数および/もしくはビデオトラックVT2の1つもしくは複数のフレームレートを低下させること、ならびに/または、
ビデオトラックVT1の1つもしくは複数および/もしくはビデオトラックVT2の1つもしくは複数のビットレートを低下させること、
をさらに含む、請求項1から4のいずれか一項に記載の方法。
【請求項6】
処理システムを有するコンピューが装置上で実行され、当該処理システムに、請求項1から5のいずれかに記載の方法を実行させるコンピュータプログラムコードを含むコンピュータプログラム。
【請求項7】
マルチトラックビデオをレンダリングするときに、ビデオトラックの第1のセットVT1からビデオトラックの第2のセットVT2に遷移するためのクライアントシステムであって、それぞれのビデオトラックは対応するレンダリング優先度を有し、当該クライアントシステムは、
サーバシステムからビデオトラックおよび各ビデオトラックのための対応するレンダリング優先度を受信するように構成されたクライアント通信モジュールと、
ビデオトラックVT1からビデオトラックVT2へ遷移する命令を受信し、
前記クライアント通信モジュールからビデオトラックVT2を受信し、
前記ビデオトラックVT2が前記ビデオトラックVT1と異なる場合に、
第1のセットのビデオトラックVT1内の1つもしくは複数のビデオトラックのレンダリング優先度に対して、時間とともにレンダリング優先度を低減させる低減関数を適用し、および/または、ビデオトラックVT2のうちの1つもしくは複数のレンダリング優先度に対して、レンダリング優先度を時間とともにさせると増大関数を適用し、
前記ビデオトラックのうちの1つまたは複数の前記レンダリング優先度を使用して、それぞれのビデオトラックおよび/またはビデオトラックの要素の重み付けを選択する、
ように構成されたクライアント処理システムと、を有し
前記重み付けは前記マルチトラックビデオをレンダリングする際に使用するためのものである、クライアントシステム。
【請求項8】
前記低減関数および/または前記増大関数は、
0.2秒から2秒の間、または、
3フレームから60フレームの間、
の期間にわたって前記レンダリング優先度を変更するように構成される、請求項7に記載のクライアントシステム。
【請求項9】
前記クライアント処理システムが、ビデオトラックVT1からビデオトラックVT2に変更するときに、後続フレームのうちの1つまたは複数の欠落データを修復するために、前記マルチトラックビデオの最新の利用可能なフレームのうちの1つまたは複数を保持するようにさらに構成される、請求項7または8に記載のクライアントシステム。
【請求項10】
前記クライアント処理システムが、
前記クライアント通信モジュールを介してサーバシステムから1つもしくは複数のビデオトラックVT1および/もしくは1つもしくは複数のビデオトラックVT2の低解像度バージョンを要求する、
前記クライアント通信モジュールを介してサーバシステムからビデオトラックVT1の1つもしくは複数および/もしくはビデオトラックVT2の1つもしくは複数の低フレームレートバージョンを要求する、ならびに/または、
前記クライアント通信モジュールを介してサーバシステムから1つもしくは複数のビデオトラックVT1および/もしくは1つもしくは複数のビデオトラックVT2の低ビットレートバージョンを要求する、
ようにさらに構成される、請求項7から9のいずれか一項に記載のクライアントシステム。
【請求項11】
前記クライアント処理システムが、当該クライアント処理システムの前記処理能力に基づいて、低解像度バージョン、低フレームレートバージョン、および/または低ビットレートバージョンを要求するように構成される、請求項10に記載のクライアントシステム。
【請求項12】
マルチトラックビデオをレンダリングするときに、ビデオトラックの第1のセットVT1からビデオトラックの第2のセットVT2に遷移するためのサーバシステムであって、それぞれのビデオトラックは対応するレンダリング優先度を有し、当該サーバシステムは、
ビデオトラックおよび各ビデオトラックのための対応するレンダリング優先度をクライアントシステムに送信するように構成されたサーバ通信モジュールと、
ビデオトラックVT1からビデオトラックVT2に遷移する命令を前記クライアントシステムから受信し、
前記サーバ通信モジュールを介してビデオトラックVT2を前記クライアントシステムに送信し、
ビデオトラックVT2が第1のビューポートに対応するビデオトラックVT1と異なる場合に、
第1のセットのビデオトラックVT1内の1つもしくは複数のビデオトラックのレンダリング優先度に対して、時間とともにレンダリング優先度を低減させる低減関数を適用し、ならびに/または、前記ビデオトラックVT2の1つもしくは複数のレンダリング優先度に対して、時間とともにレンダリング優先度を低減させる増大関数を適用するための命令を、前記サーバ通信モジュールを介して前記クライアントシステムに送信するように構成されたサーバープロセッサシステムと、
を有し、ビデオトラックの1つまたは複数のレンダリング優先度は、マルチトラックビデオをレンダリングするときに、それぞれのビデオトラックおよび/またはビデオトラックの要素の重み付けを選択する際に使用するためのものである、サーバシステム。
【請求項13】
前記低減関数および/または前記増大関数は、
0.2秒から2秒の間、または、
3フレームから60フレームの間、
の期間にわたって前記レンダリング優先度を変更するように構成される、請求項12に記載のサーバシステム。
【請求項14】
前記サーバ処理システムは、
1つまたは複数のビデオトラックVT1および/または1つまたは複数のビデオトラックVT2の低解像度バージョンを、前記サーバ通信モジュールを介して前記クライアントシステムに送信する、
ビデオトラックVT1の1つもしくは複数および/もしくはビデオトラックVT2の1つもしくは複数の低フレームレートバージョンを、前記サーバ通信モジュールを介して前記クライアントシステムに送信する、ならびに/または、
1つもしくは複数のビデオトラックVT1および/もしくは1つもしくは複数のビデオトラックVT2の低ビットレートバージョンを、サーバ通信モジュールを介してクライアントシステムに送信する、
ようにさらに構成される、請求項11から13のいずれか一項に記載のサーバシステム。
【請求項15】
前記サーバ処理システムは、前記クライアントシステムの処理能力に基づいて、低解像度バージョン、低フレームレートバージョン、および/または低ビットレートバージョンを送信するように構成される、請求項14に記載のサーバシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、マルチトラック没入型ビデオの分野に関する。特に、本発明は、マルチトラック没入型ビデオにおけるビデオトラックのセット間の遷移に関する。
【背景技術】
【0002】
3DoF+または6DoFビデオ(DoFは「自由度(degree of freedom)」を表す)としても知られる没入型ビデオは、視野空間内の観察者が大きな視野(FoV)を有することを可能にする。現実世界のシーンの場合、視野空間およびFoVは、ビデオデータをキャプチャするために使用されたカメラシステムによって決定される。コンピュータグラフィックスの場合、より柔軟性があり、例えば、360度の等角投影を直接レンダリングすることができる。
【0003】
没入型ビデオの符号化および送信は、その必要とされるリソースのために難題である。また、総ビットレート、デコーダの数、および、クライアントが復号およびレンダリングすることができる総フレームサイズには、実際的な制約がある。同様に、ライブイベントから、衛星または5Gを介して、およびクラウドサービス間でアップロードすることができるものには、ブロードキャストの費用対効果を維持するために、実際的な限界がある。
【0004】
最新のビデオストリーミングサービスでは、ストリームをクライアントの能力に適合させることが一般的である。ISO/IEC 23009-1 MPEG Dynamic Adaptive Streaming over HTTP (MPEG-DASH)、ISO/IEC 23000-19 Common Media Application Format(CMAF)、Apple's(TM)HTTP Live Streaming(HLS)などの規格は、ビデオを小さなセグメントに分割する方法を規定している。各セグメントは、複数のバージョンで、例えば異なるビットレートで、利用可能である。クライアントは、利用可能な帯域幅およびCPU使用量を測定し、サーバからより低いまたはより高い品質のセグメントを要求することを決定することができる。
【0005】
ISO/IEC 23009 MPEG Omnidirectional MediA Format (OMAF)規格(ISO/IEC 23090-2) は、DASHとCMAFのプロファイルを使用して、VR360 (3DoF) ビデオを送信する方法を規定する。VR360は「3DoF」とも呼ばれ、名称「3DoF+」は、VR360にある程度の視差を加えることによって、この命名方式に由来することに留意されたい。ビューポート非依存モードとビューポート依存モードの両方がサポートされている。後者の場合、ビデオフレームはタイルに分割され、各タイルは別個のビデオトラックである。これは、総ビデオフレームが共通ハードウェアビデオデコーダの能力を超えることを可能にする。
【0006】
例えば、HEVC Main 10 Level 5.2は、360度FoVに使用される場合、ヘッドマウントディスプレイの解像度を下回る4K x 2Kフレームに制限される。VR360 では、8K x 4Kまたは16K x 8Kの解像度が推奨される。
【0007】
MPEG Immersive Video (MIV)のための新しい規格(ISO/IEC 23090-12)は、マルチビュー+奥行きビデオを、2Dビデオコーデックによるコーディングのための複数のテクスチャおよび奥行きアトラスにプルーニングおよびパックする方法を説明する。この規格自体は適応ストリーミングを含まないが、サブビットストリームアクセスのサポートが含まれ、適応ストリーミングなどのシステム態様は、ISO/IEC 23090-10 Carriage of Visual Volumetric Video-based Coding Dataなどの関連するMPEG(または非MPEG)規格で扱われることが期待される。
【0008】
サブビットストリームアクセスのアイデアは、ビットストリーム中のユニットの一部が除去されることができ、依然として有効である、より小さいビットストリームをもたらすことである。サブビットストリームアクセスの一般的な形態は時間的アクセス(すなわち、フレームレートを低下させること)であるが、MIVでは、アトラスのサブセットの除去を可能にすることによって実装される空間的アクセスのサポートもある。各アトラスはビデオトラックを提供し、ビデオトラックの組み合わせがMIVをレンダリングするために使用される。
【発明の概要】
【発明が解決しようとする課題】
【0009】
しかしながら、ビデオトラックの切り替えは、非遮蔽ゾーンおよび任意の非ランバートシーン要素において特に見えるであろう、特定のジャンプに起因する目に見えるアーチファクトを引き起こす可能性がある。例えば、ビューポートの変化はビデオトラックの変化を引き起こす可能性があり、これは、突然の変更に起因するアーチファクトを引き起こす可能性がある。
【課題を解決するための手段】
【0010】
本発明は、請求項により規定される。
【0011】
本発明の一態様による例によれば、マルチトラックビデオをレンダリングするときに、ビデオトラックの第1のセットVT1からビデオトラックの第2のセットVT2に遷移する方法が提供され、各ビデオトラックは対応するレンダリング優先度を有し、当該方法は、
ビデオトラックVT1からビデオトラックVT2へと遷移する命令を受信し、
ビデオトラックVT2を取得し、
ビデオトラックVT2がビデオトラックVT1と異なる場合、
ビデオトラックVT1の第1のセット内のビデオトラックのうちの1つもしくは複数のレンダリング優先度に、時間とともにレンダリング優先度を低減させる低減関数を適用し、および/または、ビデオトラックVT2のうちの1つもしくは複数のレンダリング優先度に、時間とともにレンダリング優先度を増大させる増大関数を適用し、ビデオトラックのうちの1つまたは複数のレンダリング優先度は、マルチトラックビデオをレンダリングするときに、それぞれのビデオトラックおよび/またはビデオトラックの要素の重み付けを選択する際に使用するためのものである。
【0012】
本方法は、重み付けを選択するステップと、重み付けを使用してレンダリングするステップとをさらに含むことができる。
【0013】
大きな視野を有する没入型ビデオは、典型的には、ユーザによって観察されることになる単一のスクリーンに収まることができず、したがって、ビデオの或るビューポート(すなわちビデオ全体のうちの一部)がユーザに表示される。そして、ビューポートは、ユーザ(例えば、ユーザの動きを検出するセンサ、またはジョイスティック/マウスを動かすユーザ)に基づいて、または他の要因(例えばサーバ)に基づいて、変化することができる。
【0014】
上述のように、没入型ビデオは、没入型ビデオ自体を作成するために使用される幾つかのビデオトラックに基づくことができる。しかし、ビューポートが変化すると、ビューポートをレンダリングするために使用されるビデオトラックの変更を引き起こす可能性がある。この変更は、ビデオ内に目に見えるアーチファクトを引き起こす可能性がある。ビデオトラックの同様の変更は、マルチトラックビデオをストリーミングするときの帯域幅の変更などの他の理由のためにも起こり得、したがって、(例えば、より低い解像度でビデオをレンダリングするために、すなわちマルチトラックビデオをストリーミングするために必要な帯域幅を低減するために)マルチトラックビデオをレンダリングするために使用されるビデオトラックを減少させ、場合によっては変更する。
【0015】
本発明は、ビデオトラック間の表示される遷移を改善することに基づく。ビデオトラックの1つのセットから別のセットへの遷移の命令が受信されると(例えば、ユーザがジョイスティックを動かす)、ビデオトラックの新しいセットが取得される。ビデオトラックの新しいセットが以前に使用されたビデオトラックと異なる場合、レンダリング優先度は、ビデオトラックのセットのビデオトラックの幾つか(またはすべて)について徐々に下げられる。
【0016】
レンダリング優先度の低減は、時間とともにレンダリング優先度を表す数値を徐々に低減させる低減関数をビデオトラックのレンダリング優先度に適用することによって行われる。
【0017】
ビデオトラック間の遷移中にレンダリング優先度を徐々に下げることによって、没入型ビデオ(すなわち、MIV)の急激な変化が低減され、したがって、急激な変化によって引き起こされる可視アーチファクトも低減され、したがって、ユーザの観察体験が向上する。
【0018】
同様に(または代替的に)、新しいビデオトラックVT2のレンダリング優先度は、同じ効果のために、徐々に増大させることができる。新しいビデオトラックはまた、増大関数によってレンダリング優先度を徐々に増大させることによって、レンダリングに徐々に導入されることができる。レンダリングへのこの漸進的な「導入」はまた、ユーザの気を散らせて混乱させる可能性がある突然の変化(例えば、突然の品質上昇)を低減する。
【0019】
レンダリング優先度は、没入型ビデオをレンダリングするときに使用されるそれぞれのビデオトラックのためにCPU/GPUによって使用される重み付けを通知する。例えば、レンダリングされた没入型ビデオ上の画素の色は、提供された3つのビデオトラック中の対応する画素の色に基づき得る。レンダリングされた画素の最終的な色は、その各々が重み付けされる3つの画素の色の組み合わせである。3つの色の各々に対する重み付けは、典型的には、例えば、それから画素が取得されるビデオトラックの重要性に依存する。しかしながら、ビデオトラックのレンダリング優先度を徐々に変更することにより、画素に対する重み付けも低くすることができる。
【0020】
一般に、レンダリング優先度は、ビューポートおよびビデオトラックの特性(姿勢、視野など)に基づく。観察者が仮想シーン内を移動するとき、ビューポートポーズは徐々に変化し、したがってレンダリング優先度も変化する。本発明はさらに、ビデオトラックの切り替えプロセスにおいてレンダリング優先度を変更する。
【0021】
低減関数および/または増大関数は、0.2秒から2秒の間、または3フレームから60フレーム、例えば5フレームの間の期間にわたってレンダリング優先度を変更するように構成され得る。
【0022】
あるいは、低減関数および/または増大関数は、指数関数的に減衰する関数であってもよい。この場合、対応するレンダリング優先度が予め定義された値に達したときに、ビデオトラックを除去することができる。この予め定義された値は、レンダリング優先度の値の可能な範囲に依存する。例えば、0から100の範囲では、この予め定義された値は、減衰関数の半減期に応じて、0.01、0.1、1または5とすることができる。同様に、ビデオトラックは、複数の半減期が経過した後に除去されることができる。
【0023】
ビデオトラックは、レンダリング優先度が低い値(例えば、0、0.1など)に達したとき、またはある時間が経過した後に、厳密に「除去」される必要はない(例えば、サーバから要求されない)。例えば、ビデオトラックは、レンダリング優先度が0であり、したがって没入型ビデオをレンダリングするために事実上使用されない間、保持され得る。しかしながら、低いレンダリング優先度を有するビデオトラックが除去されず、新しいビデオトラックが追加される場合、没入型ビデオをレンダリングするために必要とされる計算リソースは著しく増加するだろう。いくつかのビデオトラックは、例えば、レンダリング優先度が予め定義された値に達した後、比較的短い時間保持され得る。
【0024】
ビデオトラックVT2を取得することは、サーバからビデオトラックVT2を要求すること、またはサーバからビデオトラックVT2を受信することに基づき得る。
【0025】
ビデオトラックは、ユーザが望むビューポートに基づいて要求されることができる。例えば、ユーザは、没入型ビデオの特定のビューポートを要求し、したがって所望のビューポートをレンダリングするために必要とされるビデオトラックを要求することができる。
【0026】
あるいは、サーバが、ユーザへの所望の出力に基づいて、ビデオトラックの特定のセットをユーザに送信してもよい。例えば、サーバは、ユーザが特定のビューポートをレンダリングすることを望み、したがってそのようなビューポートをレンダリングするのに必要なビデオトラックをユーザに送信することができる。
【0027】
本方法は、ビデオトラックVT1からビデオトラックVT2に遷移するときに、後続フレームのうちの1つまたは複数の欠落データを修復するために、マルチトラックビデオおよび/またはビデオトラックVT1の最新の利用可能なフレームのうちの1つまたは複数を保持することをさらに含むことができる。
【0028】
古いフレームに基づく新しいフレームにおける欠落データの修復は、フレームをレンダリングするために使用されるビデオトラックの突然の変更に起因して発生するアーチファクトをさらに低減するために使用されることもできる。修復に使用されるフレームは、変更自体および新しいフレームを修復するためにどの情報が必要かに応じて、前のビデオトラックからレンダリングされたマルチトラックビデオからのものであってもよいし、ビデオトラック自体からのフレームであってもよい。
【0029】
本方法はさらに、
ビデオトラックVT1のうちの1つもしくは複数および/もしくはビデオトラックVT2のうちの1つもしくは複数の解像度を低下させること、
ビデオトラックVT1のうちの1つもしくは複数および/もしくはビデオトラックVT2のうちの1つもしくは複数のフレームレートを低下させること、ならびに/または、
1つ以上のビデオトラックVT1のうちの1つもしくは複数および/もしくはビデオトラックVT2のうちの1つもしくは複数のビットレートを低下させることを含む。
【0030】
ビデオトラックのセット間の遷移の間、マルチトラックビデオをレンダリングするために使用されるリソースは、前のビデオトラックに関連するデータと新しいビデオトラックに関連するデータとを同時に処理する必要があるため、データによって圧倒される可能性がある。したがって、ビデオトラックの解像度、フレームレートおよび/またはビットレートを低下させることにより、遷移が完全にレンダリングされ得ることを保証するために、遷移中に処理されなければならないデータの量を低減することができる。特に、これは、ユーザによってストリーミングされるデータ全体が任意のビットレートおよび/または画素レート制限に適合することを保証することができる。
【0031】
また、本発明は、処理システムを有するコンピュータ装置で実行されると、当該処理システムに、ビデオトラックの第1のセットVT1からビデオトラックの第2のセットVT2に遷移するための上で定義された方法のステップのすべてを実行させるコンピュータプログラムコードを含むコンピュータプログラムを提供する。
【0032】
本発明はまた、マルチトラックビデオをレンダリングするときに、ビデオトラックの第1のセットVT1からビデオトラックの第2のセットVT2に遷移するためのクライアントシステムを提供し、各ビデオトラックは対応するレンダリング優先度を有し、当該クライアントシステムは、
サーバシステムからビデオトラックおよび各ビデオトラックの対応するレンダリング優先度を受信するように構成されたクライアント通信モジュールと、
ビデオトラックVT1からビデオトラックVT2に遷移する命令を受信し、
クライアント通信モジュールからビデオトラックVT2を受信し、
ビデオトラックVT2がビデオトラックVT1と異なる場合に、
ビデオトラックVT1の第1のセット内のビデオトラックのうちの1つもしくは複数のレンダリング優先度に、時間とともにレンダリング優先度を低減させる低減関数を適用し、および/または、ビデオトラックVT2のうちの1つもしくは複数のレンダリング優先度に、時間とともにレンダリング優先度を増大させる増大関数を適用するように構成されたクライアント処理システムとを有し、
ビデオトラックのうちの1つまたは複数のレンダリング優先度は、マルチトラックビデオをレンダリングするときに、それぞれのビデオトラックおよび/またはビデオトラックの要素の重み付けを選択する際に使用するためのものである。
【0033】
クライアント処理システムは、重み付けを選択し、重み付けを使用してレンダリングを実行するようにさらに構成され得る。
【0034】
クライアント処理システムは、ビデオトラックVT1からビデオトラックVT2に変更するときに、後続フレームのうちの1つまたは複数の欠落データを修復するために、マルチトラックビデオの最新の利用可能なフレームのうちの1つまたは複数を保持するようにさらに構成され得る。
【0035】
クライアント処理システムはさらに、
ビデオトラックVT1の1つもしくは複数および/またはビデオトラックVT2の1つもしくは複数の低解像度バージョンを、クライアント通信モジュールを介してサーバシステムに要求し、
ビデオトラックVT1の1つもしくは複数および/またはビデオトラックVT2の1つもしくは複数の低フレームレートバージョンを、クライアント通信モジュールを介してサーバシステムに要求し、ならびに/または、
ビデオトラックVT1の1つもしくは複数および/またはビデオトラックVT2の1つもしくは複数の低ビットレートバージョンを、クライアント通信モジュールを介してサーバシステムに要求するように構成される。
【0036】
クライアント処理システムは、クライアント処理システムの処理能力に基づいて、低解像度バージョン、低フレームレートバージョン、および/または低ビットレートバージョンを要求するように構成され得る。
【0037】
本発明はまた、マルチトラックビデオをレンダリングするときに、ビデオトラックの第1のセットVT1からビデオトラックの第2のセットVT2に遷移するためのサーバシステムを提供し、各ビデオトラックは対応するレンダリング優先度を有し、当該サーバシステムは、
ビデオトラックおよび各ビデオトラックの対応するレンダリング優先度をクライアントシステムに送信するように構成されたサーバ通信モジュールと、
ビデオトラックVT1からビデオトラックVT2に遷移する命令を受信し、
サーバ通信モジュールを介してビデオトラックVT2を送信し、
ビデオトラックVT2が第1のビューポートに対応するビデオトラックVT1と異なる場合に、
ビデオトラックVT1の第1のセット内のビデオトラックのうちの1つもしくは複数のレンダリング優先度に、時間とともにレンダリング優先度を低減させる低減関数を適用し、および/または、ビデオトラックVT2のうちの1つもしくは複数のレンダリング優先度に、時間とともにレンダリング優先度を増大させる増大関数を適用するために、サーバ通信モジュールを介して、クライアントシステムに命令を送信するように構成されたサーバプロセッサシステムとを有し、
ビデオトラックのうちの1つまたは複数のレンダリング優先度は、マルチトラックビデオをレンダリングするときに、それぞれのビデオトラックおよび/またはビデオトラックの要素の重み付けを選択する際に使用するためのものである。
【0038】
サーバ処理システムはさらに、
ビデオトラックVT1の1つもしくは複数および/もしくはビデオトラックVT2の1つもしくは複数の低解像度バージョンを、サーバ通信モジュールを介してクライアントシステムに送信し、
ビデオトラックVT1の1つもしくは複数および/もしくはビデオトラックVT2の1つもしくは複数の低フレームレートバージョンを、サーバ通信モジュールを介してクライアントシステムに送信し、ならびに/または
ビデオトラックVT1の1つもしくは複数および/もしくはビデオトラックVT2の1つもしくは複数の低ビットレートバージョンを、サーバ通信モジュールを介してサーバからクライアントシステムに送信するように構成されることができる。
【0039】
サーバ処理システムは、クライアントシステムのクライアント処理システムの処理能力に基づいて、低解像度バージョン、低フレームレートバージョンおよび/または低ビットレートバージョンを送信するように構成されることができる。
【0040】
本発明のこれらおよび他の態様は以下に記載される実施形態から明らかになり、これを参照して説明される。
【図面の簡単な説明】
【0041】
本発明をより良く理解し、本発明をどのように実施することができるかをより明確に示すために、単なる例として、添付の図面を参照する。
【
図1】360度での3Dシーンの2D投影を示す図。
【
図3】クライアントシステムにビデオトラックを送信するサーバシステムを示す図。
【発明を実施するための形態】
【0042】
本発明は、図面を参照して説明される。
【0043】
詳細な説明および特定の例は装置、システムおよび方法の例示的な実施形態を示しているが、例示のみを目的としたものであり、本発明の範囲を限定することを意図したものではないことを理解されたい。本発明の装置、システム及び方法のこれら及び他の特徴、態様及び利点は、以下の説明、添付の特許請求の範囲及び添付の図面からより良く理解されるであろう。図面は単に概略的なものであり、一定の縮尺で描かれていないことを理解されたい。また、同じ参照番号が同じまたは類似の部分を示すために、図面全体にわたって使用されることを理解されたい。
【0044】
本発明は、マルチトラックビデオをレンダリングするときに、ビデオトラックの第1のセットVT1からビデオトラックの第2のセットVT2に遷移するための方法を提供し、各ビデオトラックは、対応するレンダリング優先度を有する。本方法は、第1のセットの第1のビデオトラックVT1(以下、単に「ビデオトラックVT1」と呼ぶ)から第2のセットの第2のビデオトラックVT2(以下、単に「ビデオトラックVT2」と呼ぶ)に遷移する命令を受信することと、ビデオトラックVT2を取得することと、ビデオトラックVT2がビデオトラックVT1とは異なる場合、ビデオトラックVT1の第1のセット中のビデオトラックのうちの1つまたは複数のレンダリング優先度に低減関数を適用することと、および/または、ビデオトラックVT2の第2のセット中の1つまたは複数のビデオトラックのレンダリング優先度に増大関数を適用することを含む。低減関数および増大関数は、それぞれ、レンダリングの優先度を経時的に低減および増大させる。レンダリング優先度は、マルチトラックビデオをレンダリングするために使用されるビデオトラックおよび/またはビデオトラックの要素の重み付けの決定に使用される。
【0045】
図1は、360度の3Dシーンの2D投影102を示す。
図1(a)の3Dシーンは、教室全体のシーンである。2D投影102は、教室の没入型ビデオの360度スクリーンショットであることができる。没入型ビデオでは、ユーザが教室内で振り返ることができ(例えばVR360)、及び/又はビデオ中の教室内で動き回ることができる(例えば、6DoFビデオ)。
【0046】
図1(b)は、例示的なビューポート104を有する3Dシーンの2D投影102を示す。ビューポート104は、(およそ)90度の視野を有する。ビューポート104は、没入型ビデオを見ているユーザによって観察される3Dシーンの最終的な部分である。ユーザが没入型ビデオ中で振り向く及び/又は動くと、ビューポート104は、ユーザが向いている3Dシーンの部分を示すように変化する。
【0047】
ユーザが没入型ビデオ内で動くことができるようにするために、3Dシーンは、3Dシーン内の異なる位置から観察することができなければならない。これは、様々なセンサ(例えばカメラ)を使用して3Dシーンを作成することによって達成することができ、様々なセンサは3Dシーン内の異なる位置に配置される。そして、様々なセンサが、いわゆるアトラスへとグループ化される。
【0048】
図2は、3つのアトラス202の図を示す。各アトラス202は、1つまたは複数のセンサ(例えば、カメラ、奥行きセンサなど)を含む。この説明では3つのアトラス202のみが示され、各アトラス202は3つのセンサ、主カメラ204、および2つの追加の奥行きセンサ206を有する。しかしながら、アトラス202の数、センサの数、およびアトラス202ごとのセンサのタイプは、使用事例に基づいて変わり得る。
【0049】
代替例では、カメラ204は完全な(基本)ビューを提供することができ、センサ206は追加のビューを提供することができる。さらに、すべてのセンサからのビューは、アトラス202にグループ化され、アトラス202は交差しても交差しなくてもよい。
【0050】
MPEG Immersive Video (MIV)は、複数のアトラス202を伴うビットストリームフォーマットを規定する。好ましくは、各アトラス202が少なくともジオメトリ及びテクスチャ属性ビデオを有する。適応ストリーミングの場合、各アトラス202が別個のビデオトラック(例えば、アトラス202ごとのビデオトラック)を形成する複数のタイプのビデオデータを出力することが予想される。各ビデオトラックは、クライアントがサーバから要求されるビデオトラックのサブセットを変更することによって、ビューポートポーズ103の変更に応答することを可能にするために、(例えば秒のオーダーでの)短いセグメントに分割される。
【0051】
アトラスシステムは、複数のカメラビューを含み、距離センサ、奥行き推定または他の方法で、奥行きマップを作成することもできる。これらの全ての組み合わせは、(この場合)アトラス202ごとにビデオトラックを形成する。カメラ204はまた、共通の「シーン」座標系に配置して位置決めされることができる。したがって、各アトラス202の出力は、マルチビュー+奥行き(またはジオメトリ)表現を有する。
【0052】
図3は、ビデオトラック302をクライアントシステム306に送信するサーバシステム304を示す。サーバシステム304は、アトラス202の各々から出力を受信し、各々を符号化する。この例では、或る1つのアトラス202の符号化された出力が1つのビデオトラック302を形成する。次いで、サーバシステム304は、(例えば、クライアントシステム306によって要求されたビューポート104に基づいて)どのビデオトラック302をクライアントシステム306に送信するかを決定する。
図3では、2つのビデオトラック302のみが、アトラス202からサーバシステム304によって受信された3つの潜在的なビデオトラック302からクライアントシステム306に送信される。
【0053】
ストリーミングのために、サーバシステム304は、アトラス202の各々からの出力の全てを符号化することができる。しかしながら、すべてのビデオトラック302を送信することは不可能であるので、ビデオトラック302のサブセットのみがクライアントシステム306に完全に送信される。ビューポート104の特定の領域が、完全に送信されたビデオトラック302によって予測可能でない場合、他のビデオトラック302も部分的に送信され得る。
【0054】
各アトラス202はビューのグループを含み、各アトラス202の出力は別々に符号化され、ビデオトラック302を形成する。
図2および
図3では、ビデオトラック302ごとに1つのアトラス202しかないと仮定されている。アトラス202は、完全なビューおよび追加のビューのいくつかのパッチ(すなわち、台形スライス)を含むことになる。他の場合には、アトラス202が追加のビューのみを含んでもよく、または完全なビューのみを含んでもよく、1つのビデオトラック302が複数のアトラス202の出力から形成されてもよい。
【0055】
ターゲットビューポート104がビデオトラック302に存在するビューのうちの1つの近くにあるとき、他のビデオトラック302は、クライアントシステム306によって必要とされない場合がある。しかしながら、ターゲットビューポート104がソースビューからいくらか離れているとき、クライアントシステム306は、複数のビデオトラック302を有することから恩恵を受けることになる。
【0056】
複数のトラック302を使用して、VR360コンテンツの観察者依存ストリーミングのための視野を拡張することもできる。例えば、各カメラはわずか50度の視野を有する場合があり、シーン全体は180度を超える視野を有する可能性がある。その場合、クライアントシステム306はフル解像度で利用可能な完全な180度シーンを得る代わりに、観察者の向きと一致するビデオトラック302を要求することができる。
【0057】
ビデオトラックの要求とビデオトラック302の送達との間に遅延があり、ビューポートポーズ104が断続的に変化することがあり得る。したがって、クライアントシステム306はまた、リソースを低減するため又はレンダリング品質を改善するために、サブビットストリームアクセス動作を実行し得る。これは送信されるビットレートを低減しないが、クライアントシステム306のCPU、GPUおよびメモリ要件を低減する。さらに、場合によっては、ターゲットビューポート104からさらに離れたビデオトラック302が除去されると、レンダリング品質が改善され得る。次いで、ビデオトラック302の要求されたサブセットがレンダリングされる。
【0058】
全てのレンダリングエラーが人間に見えるわけではないことを考慮することが重要である。例えば、(すなわち、奥行き値の符号化に起因して)大きなパッチが数ピクセルだけ動かされるとき、これは人間の観察者には見えないが、同じ誤差はピーク信号対雑音比(PSNR)などの客観的品質推定の大きな低下を引き起こす。ビデオトラック302の切り替えでは、問題のあるシーン要素が突然異なってレンダリングされ、突然の視覚的変化を引き起こす可能性がある。加えて、人間の視覚系は、特に動きに敏感である。
【0059】
したがって、本発明者らは、ビデオトラック302内の視覚的要素のレンダリング優先度を徐々に変更して、これらのアーチファクトの可視性を低減することを提案した。
【0060】
一般に、レンダリングアーチファクトの量は、ビューポート104の位置がビデオトラック302内の基本ビュー位置からさらに離れているときに増加する。しかしながら、ビデオトラック302の観察空間の外側にあるビューポート104をレンダリングすることが、特にこれが数個のビデオフレームだけに必要であり、したがって観察者に完全には見えない場合には、可能である。ビデオトラック302の可用性の変化に起因する画素値の突然の切り替えは、人間にとって非常に顕著であり、したがって、レンダリング優先度の漸減は変化がより長い期間にわたって行われることを可能にし、変化の視認性を低減する。
【0061】
各ビデオトラックについてのレンダリング優先度は、各ビデオトラックについて単一の変数、または変数のセット(例えば、前景、背景などについての異なるレンダリング優先度変数)として記述されることができる。したがって、レンダリング優先度が変更されている(増加/減少される)とき、これは、レンダリング優先度のそれぞれの変数が同じレートまたは異なるレートで変更されていることを意味し得る。例えば、アトラスから出力されるパッチのセットはそれぞれ異なる変数を有することができ、したがって、変数のセットは、アトラスのレンダリング優先度を形成することになる。ただし、以下の実施例では、説明を簡単にするために、レンダリング優先度を1つの要素として説明する。
【0062】
図4は、ビデオトラック302の変更の第1の例を示す。2つのビデオトラック302aおよび302bが最初に没入型ビデオをレンダリングするために使用される。しかしながら、前のビデオトラック302aは、セグメント2 (404)とセグメント3 (406)との間に新しいビデオトラック302cに変更される。前のビデオトラック302aのレンダリング優先度402は、セグメント2(404)の終わりの前に徐々に下げられ、新しいビデオトラック302cのレンダリング優先度402はセグメント3(406)の始まりから徐々に増加される。この場合、ビデオトラック302bは除去されず、したがって、ビデオをレンダリングするためにさらに使用される。
【0063】
ビデオトラック302が低いレンダリング優先度402を有するとき、それは、必要な情報を有する他のビデオトラック302がないときにのみ使用される。ビデオトラック302がゼロのレンダリング優先度(すなわち、0%)を有するとき、それは、あたかもビデオトラック302がそこに無いかのようである。しかしながら、情報が欠落している場合、それは、ゼロのレンダリング優先度402を有するビデオトラック302で修復され得る。ビデオトラック302のレンダリング優先度402を徐々に変更することによって、レンダリングアーチファクトの突然の出現、消失または置換が低減される。
【0064】
レンダリング優先度402の漸減は、もはや将来のセグメントでは使用されないビデオトラック302のレンダリング優先度402に低減関数を適用することによって達成される。低減関数は、レンダリング優先度402を、例えば、0.2から2秒又は5から200フレームにわたって徐々に下げる。低減関数は、線形、指数関数、二次関数などであってもよい。100%から0%に要する特定の形状および時間は任意であり、特定の使用事例に基づいて選択することができる。同じ理由が、新しいビデオトラック302cに使用される増大関数にも当てはまる。
【0065】
なお、
図4では、クライアント306が来たるビデオトラック302の切り替えを知っているものとする。通常、クライアント306は、ビデオトラック302のセグメントを要求する。しかしながら、サーバ304が送信されるビデオトラック302を制御している場合、サーバ304は、ビデオデータの一部としてメッセージ(例えば、SEIメッセージ)を送信して、クライアント306に切り替えを知らせることができる。セグメントを非常に短くすることには符号化の欠点があり、したがって、サブセグメント時間スケールに関してサーバ304がクライアント306と通信することを可能とすることが考えられることに留意されたい。
【0066】
クライアント306はまた、完全にドロップする前に、以前のビデオトラック302aの低解像度バージョンに(段階的に)切り替えることができ、および/または、最初に新しいビデオトラック302cの低解像度バージョンを要求することができる。これにより、クライアント306は、高解像度に切り替えて前のビデオトラック302aをドロップする前に、3つのビデオトラック302a、302bおよび302cを保持することができる。ビュー混合エンジンは、ビデオトラック302の優先順位付けをするとき、解像度を考慮に入れることができ、この場合、ダウンスケーリングされたビデオトラックのレンダリング優先度402は、さらに下げられ得る。しかし、解像度の急激な低下は視認され得る。したがって、変化を徐々にすることが有用であり得る。
【0067】
クライアント306はまた、完全にドロップする前に、以前のビデオトラック302aの低フレームレートバージョンに(段階的に)切り替えることができ、または最初に新しいビデオトラック302cの低フレームレートバージョンを要求することができる。これにより、クライアント306は、高フレームレートに切り替えて前のビデオトラック302aをドロップする前に、(クライアント306のリソース制約内で)様々なビデオトラック302を保持することができる。
【0068】
図5は、ビデオトラック302の変更の第2の例を示す。ビデオトラック302の変更は、複数のビデオトラック302のうちの1つまたは複数のためのレンダリング優先度402を変更することによって、複数のビデオトラック302のためのビデオデータを受信するときに、より徐々に実行されることができる。しかしながら、クライアント306が1つのビデオトラック302のみを受信するとき、異なる戦略が必要とされ得る。
図5では、前のビデオトラック302aの品質もまた、単一のセグメント502のための前のビデオトラック302aと新しいビデオトラック302cとの同時送信を可能にするために低減される。ビデオトラック302を送信/復号/レンダリングするのに必要なリソースをどのように半分にするかについてのいくつかの例は以下の通りである:
- ビットレートを下げる(例: 10 Mbps → 5 Mbps);
- 空間解像度を下げる(例: 8K×4K → 6K×3K);
-フレームレートを下げる(例: 120Hz → 60Hz)
【0069】
特に、
図7は新しいビデオトラック302cが導入されたときに、前のビデオトラック302aが60 FPSのフレームレートから30 FPSのフレームレートに下げられていることを示す。新しいビデオトラック302aはまた、30 FPSのフレームレートで導入され、そして前のビデオトラック302aが除去されると、60 FPSのフレームレートに増加される。前のビデオトラック302aのレンダリング優先度402は徐々に下げられ、新しいビデオトラック302cのレンダリング優先度402は、単一のセグメント502の間に徐々に上げられる。
【0070】
静止領域(背景など)に特に適したさらなる改善は、ビデオトラック302の最後の利用可能なフレームを維持し、それをさらに数フレーム使用して、より漸進的な低減を可能にすることである。そして、ビデオトラック302の最後の利用可能なフレームは、新しい視点を反映するように外挿される。この改善は、ブリッジされる時間スパンが短い低レイテンシネットワークに特に有用である。クライアント306が動き補償を用いてビデオフレームレート変換することが可能である場合、これは、最後の利用可能なフレーム内の動きベクトルに基づいてビデオトラック302内の動きを外挿するために使用され得る。
【0071】
ビューポートは、典型的には、視点(姿勢、外部データ)と、視野および焦点距離などのカメラ特性(内部データ)とに依存する。
【0072】
クライアントシステムはまた、レンダリングされたビューポートを保存し(フレームバッファ)、そのビューポートからレンダリングして、新しいフレーム内の欠落データを埋めることができる。この戦略は、ビデオトラック302から切り替えるとき、または初期設定で修復ストラテジとしてのみ、有効にされることができる。フレームバッファは、観察者の位置の変化を補償するためにオフセットを用いてレンダリングすることができる。これはまた、(短い時間の間、例えば、ネットワーク遅延のために)新しいビデオトラック302cが存在しないときの良好な予備戦略である。
【0073】
没入型ビデオのためのビデオトラック302における変更/遷移は、複数のトラックを有する3DoFビデオ、3DoF+及び6DoFビデオを指す。それらは、球面ビデオと呼ばれることもある。
【0074】
レンダリング優先度は、本質的に、ビデオ要素のどれだけが最終的なレンダリング結果に関与するかを変更するために修正されることができる1つまたは複数のパラメータに対する包括的な用語である。言い換えれば、レンダリング優先度は、新しい画像のレンダリング中に特定のビデオ要素(例えば、ピクセル)の重み付けに影響を及ぼす1つまたは複数のパラメータを指す。レンダリング優先度は、最終混合重みとも呼ばれ得る。
【0075】
例えば、ビューブレンディングは寄与の重み付けされた合計に基づいており、それによって、各ビューは、(ピクセルごとに均一のまたは変化する)重みを有する。各ビューは別個のバッファにレンダリングされてもよく、バッファはビューポートの各ビューへの近接度に基づいて混合されることができる。この例では、ビューの各々に対するビューポートの近接度を使用して、レンダリング優先度を決定する。
【0076】
従来より、レンダリング優先度は、ビューポートへの近接度に基づいている。また、ビデオトラックが変更されるときにレンダリング優先度を適応させる(すなわち、増加または減少させる)ことが提案される。例えば、3つのビュー[v1, v2, v3]がレンダリングされるが、次のセグメントについて、ビュー[v2, v3, v4]が利用可能である場合、加重和におけるv1の寄与はゼロに向かって徐々に修正され得る。v4が入ってきたとき、その寄与(すなわち、レンダリング優先度)は、ゼロから開始して徐々に上げられる。
【0077】
代替的に、ビューポートの観点で奥行きマップをレンダリングし、次いで、複数のビューからテクスチャをフェッチすることも可能である。この場合、複数のテクスチャ寄与をどのように混合するかを決定するための重み付け関数も存在する。レンダリング優先度を決定するために使用され得るパラメータは、出力ビューへの近接度、およびレンダリングされた奥行きとソース奥行きとの間の奥行き値の差である。
【0078】
他のレンダリングソリューションは、データの一部のみをレンダリングすることができ、その場合、それ以下ではデータが破棄される閾値が存在し得る。例えば、ビデオフレームのパッチまたはブロックをレンダリングするとき、レンダリング優先度は、近接度、パッチのサイズ、パッチの解像度などに基づき得る。将来のパッチ可用性/必要性に基づいてレンダリング優先度を適応させることが提案される。
【0079】
要約すると、レンダリング優先度は、レンダリングされるビューに対するソースビューの近接度、奥行きの差異、パッチのサイズおよびパッチの解像度に基づき得る。レンダリング優先度を決定するための他の方法が当業者に知られている。
【0080】
当業者は、本明細書に記載された如何なる方法も実行するためのプロセッサを容易に開発することができる。したがって、フローチャートの各ステップは、プロセッサによって実行されるそれぞれのアクションを表すことができ、処理プロセッサのそれぞれのモジュールによって実行され得る。
【0081】
プロセッサは、必要とされる様々な機能を実行するために、ソフトウェア及び/又はハードウェアを用いて、様々な態様で実装される。プロセッサは、通例、ソフトウェア(例えば、マイクロコード)を用いて、必要とされる機能を行うようにプログラムされる1つ以上のマイクロプロセッサを用いる。プロセッサは、幾つかの機能を実行するための専用ハードウェアと、他の機能を実行するための1つ以上のプログラムされるマイクロプロセッサ及び関連する回路との組合せとして実施されてもよい。
【0082】
本開示の様々な実施形態に用いられる回路の例は、これらに限定されないが、従来のマイクロプロセッサ、特定用途向け集積回路(ASIC)及びフィールドプログラマブルゲートアレイ(FPGA)を含む。
【0083】
様々な実施において、プロセッサは、例えばRAM、PROM、EPROM及びEEPROMのような揮発性及び不揮発性コンピュータメモリである1つ以上の記憶媒体に関連付けられることができる。この記憶媒体は、1つ以上のプロセッサ及び/又は制御器上で実行されるときに必要とされる機能を実行する1つ以上のプログラムで符号化されてもよい。様々な記憶媒体はプロセッサ又は制御器内に取り付けられてもよいし、又は記憶媒体に記憶される1つ以上のプログラムがプロセッサに読み込まれるように、搬送可能でもよい。
【0084】
開示された実施形態に対する変形例は、図面、詳細な説明および添付の特許請求の範囲の検討から、特許請求された発明を実施する際に当業者によって理解され、実施されることができる。請求項において、用語「有する」は他の要素又はステップを排除するものではなく、不定冠詞「a」又は「an」は複数性を排除するものではない。
【0085】
単一のプロセッサ又は他のユニットが、請求項に列挙されるいくつかの項目の機能を果たすことができる。
【0086】
特定の手段が相互に異なる従属請求項に記載されているという単なる事実は、これらの手段の組み合わせが有利に使用されることができないことを示すものではない。
【0087】
コンピュータプログラムは、他のハードウェアと一緒に、またはその一部として供給される光記憶媒体またはソリッドステート媒体などの適切な媒体上で記憶/配布されることができるが、インターネットまたは他の有線もしくは無線電気通信システムなどを介して、他の形態で配信されることもできる。
【0088】
「に適応する」という用語が請求項又は明細書に用いられる場合、「に適応する」という用語は、「ように構成される」と言う用語と同様であることを意味する。
【0089】
請求項におけるいかなる参照符号も、範囲を限定するものとして解釈されるべきではない。
【国際調査報告】