JP6216046B2 - コーデックの自動適応化 - Google Patents

Description

本文書は、分散アプリケーション処理シナリオにおけるネットワーク使用量を最小限の計算労力で低減させるためのシステムに関する。より詳細には、本文書は、たとえばネットワーク中心のデータセンターに配備された処理ノードにおけるビデオデータの分散リアルタイム処理の領域に関する。

近年、データ、コンピュータプログラムおよびアプリケーションは益々、ネットワーク中心のデータセンター（「クラウド」）において格納され実行されるようになっている。しかしながら、特に、クラウドにおけるメディアデータの分散リアルタイム処理の技術分野において、帯域幅およびエンドツーエンド遅延要件のために、リアルタイムメディアの処理は、ネットワークリンクを横断した伝送データに関する敏感さを特に必要とする。

サービス型プラットフォーム（ＰａａＳ：Ｐｌａｔｆｏｒｍ−ａｓ−ａ−Ｓｅｒｖｉｃｅ）手法において、ネットワークの異なる部分に配置された処理ノード上に分離可能なソフトウェアコンポーネントから構成されるアプリケーションを自動的に配布する機能が提供される。共有データの局所性を利用して伝送ネットワーク内のトラフィックを最小化し、処理ノードのリソース利用を最適化し、ネットワーク内のユーザ一の位置に近い遅延に敏感なタスクを処理することでユーザ体験を改良するために、この配布は利用される。クラウドベースの処理環境において、別個の処理ノード上で実行される別々のソフトウェアタスクの間の異なるデータ伝送シナリオが適用され得る。典型的なシナリオは、エンドデバイスへの、およびエンドデバイスからネットワークの向こう側のメディア処理ノードへのメディアデータ伝送、単一のデータセンター内の処理ノード間のメディアデータ伝送、および異なるデータセンター内に配置された処理ノード間のメディアデータ伝送である。

サービスプラットフォーム上の分散処理から利益を得る典型的なアプリケーションシナリオは、たとえばビデオチャットである。ビデオチャットのシナリオでは、たとえば、人々のグループが、仮想の共有されたビデオ環境／ビデオチャットルームに参加する。各個人は、自身のカメラのビデオデータをクラウドにストリーミングする。ビデオチャットサービスは、そのような共有環境内に集まっているユーザの全てのメディアストリームを結合し、各参加者に対する仮想ルームの個人用ビューを生成する（すなわち、処理する）。したがって、仮想ルーム内の各個人は、全ての（他の）参加者の個人用のレンダリングされたビューを受信する。

ビデオチャットなどのアプリケーションが、クラウド内の異なる処理ノードを横断して実行される別個の処理部分（すなわち、処理コンポーネント）に分割できると仮定される。典型的なシナリオは、以下を含む：
− データ発生源の近くに位置する処理リソース上に配置されることが好ましい、カメラ信号の前処理、たとえば背景減算、顔または行動検出、たとえば「誰が話しているか」の機能。
− 仮想カメラのパン／チルトおよびズーム要素を選択することで高解像度を有する現実のカメラの信号から抽出されるべきビデオの特定の部分を決定するためのユーザのインタラクションにより制御されるモジュール。
− 全ての参加者に対して「遅延の中心」に配置されることが好ましい、クラウド内の処理リソース上のチャットルーム内の人々の異なるビデオ信号の全てをマージさせるビデオ混合機能。
− エンドユーザの対話型ジェスチャまたは他の手段などにより制御される、このユーザの近くに配置された処理リソース上に配置されることが好ましい、個人視点レンダリング。

たとえば、ビデオチャットアプリケーション内の処理部分は、背景抽出とすることができる。この部分は、色変換、実際のフレームの背景モデルとの比較、背景モデルの統計的更新、前景マスク生成などの別個のタスクを行ういくつかの処理コンポーネントから構築および構成されることがある。

たとえばプラットフォームシナリオでは、コンポーネントは、送信コンポーネントの出力ポートを１つまたは複数の受信コンポーネントの入力ポートに接続するメッセージパッシングインターフェースを介して通信することができる。開発者は、自身のアプリケーションの実行インスタンスを、そのアプリケーションを構成する異なる処理要素から構成される動的サービス論理グラフを編成することで、作成し維持することができる。

グラフの操作には、コンポーネントの作成、修正または除去、および動的なコンポーネント間の接続の確立または解放が含まれる。開発者の視点からは、プラットフォームは単一の仮想処理リソースのように振る舞い、前述のように物理的な基盤リソース上へ適切にアプリケーションの異なるコンポーネントを配備するのはプラットフォームの仕事である。

典型的には、特定のタスクごとに必要な処理能力は、異なるメディアパラメータに依存する。パラメータは、画像解像度、フレームレート、参加者数などとすることができる。さらに、所望の機能を実行するのに必要なリソースの数は、リソース能力と、（すぐに変動し得る）個々の処理ノードの現在の負荷状況とに依存することがある。

したがって、どのようにアプリケーションの異なるコンポーネントが、異なる処理ノードを横断して最も効率良く配布されるかをアプリケーション開発者が予測することは一般的には困難である。プラットフォームのみが必要な情報を有するので、リソース上のサービス実行時に出現するリソースボトルネックを、このリソース上で現在実行中のいくつかの処理部分／コンポーネントを現在あまり利用されていない他のリソースへ再配布することにより解消する方法を決定するのはプラットフォームの仕事である。

しかしながら、ビデオチャットサービスなどのビデオアプリケーションのコンポーネントを配布するための根本的な問題は、多数のメディア処理コンポーネントが主に一連の画素値（すなわち、単一のビデオフレーム）に作用するので、コンポーネント間で交換されるデータの量が大量であることである。このように、コンポーネントは通常、画素値の完全なフレーム、すなわち非圧縮のビデオフレーム（生データ）をその出力ポートに送信する。これにより、生の「ビデオ」トラフィックが、異なる処理ノードを接続するネットワーク上で伝送、すなわち交換される必要があるので、アプリケーションコンポーネントを異なる処理ノードにわたって分割することが困難となり、したがって、ネットワークの輻輳をもたらすことがある。したがって、異なる処理リソース上で実行されるコンポーネント間で交換されるメディアデータは、有意義な方法で圧縮される必要がある。

開発時のサービスグラフの開発者は、どのようにプラットフォームがサービス実行時に異なるサービスコンポーネントを処理リソースにわたって分割することになるかを知らないので、必要に応じて通信経路内に圧縮（すなわち、符号化／復号）を自動的に含むプラットフォーム機能が必要である。

知られているビデオコーデック（コーダおよびデコーダ、たとえばＭＰＥＧ４、ＶＰ８、Ｈ．２６４）は、ビデオ信号用の一般的で効率的な圧縮ユーティリティである。これらのコーデックは、予測ステップおよび合成技術による分析により、元の信号に類似した信号を圧縮されたパラメータから再生できるようにパラメータを抽出することによって、ビデオ信号に内在する時空間の類似性を利用する。画素のブロックがその近傍ブロックに類似していると分かった場合、近傍ブロックへのポインタおよび残差のみが、実際のブロックの完全な情報の代わりに送信される。同様に、ブロックを、前後のフレームと、動きを補償する動きベクトルとから補間することで予測することができる。予測できないブロックは、変換係数（通常はＤＣＴ）を用いて符号化され、量子化される。最後に、データは、さらなる圧縮のためにランレングス符号化される。

特定の処理機能、たとえば物体検出に関して、物体の元のテクスチャおよび再構成されたテクスチャの画素単位の類似性は通常、物体の形状などの他のさらなる特徴情報を保存することよりも重要性が低い。したがって、複雑な予測方法および画素精度の再構成技法は、要件を行き過ぎてしまうことがある。

画像シーケンスから情報を得る他の方法は、具体的な内容を代表する特徴を抽出することである。そのような特徴は、物体検出などの特定の処理機能に有用であるが異なる表現方式を必要とするいくつかの他の処理機能により使用できない元のデータの特殊な表現を形成する。スケール不変特徴変換（ＳＩＦＴ：Ｓｃａｌｅ−Ｉｎｖａｒｉａｎｔ−Ｆｅａｔｕｒｅ−Ｔｒａｎｓｆｏｒｍ）または高速化ロバスト特徴（ＳＵＲＦ：Ｓｐｅｅｄｅｄ−Ｕｐ−Ｒｏｂｕｓｔ−Ｆｅａｔｕｒｅｓ）などのいくつかの特徴は、一連の広範なユースケースに対して一般化されており、物体認識などで使用されるパッチベースの畳み込みフィルタなどの他の特徴は、単一のタスクのみに対して情報保存を提供する。これらの特徴抽出方法は、高度に弁別的であるが、特徴領域から原信号を再構成できないことが多い。また、これらは通常、汎用の表現形式としては適用できない。これらの種類の特徴は、良好な圧縮特性を可能とする疎表現をもたらす付加的な変換処理の例と考えることができる。

本文書は、最小限の計算労力で分散アプリケーション処理シナリオにおける有効ネットワーク使用量を低減させるためのシステムを提供するという技術的問題に対処する。

２つのサービス（処理）コンポーネント間に動的設定可能符号化および表現形式を提供することで、最小限の計算労力で分散処理シナリオにおける有効ネットワーク使用量を低減させるためのシステムおよび方法（ならびにアプリケーション配布ユニット）が提供される。たとえば、どの処理コンポーネントが送信される必要があるデータストリーム（たとえば、ビデオまたは音声データなどのマルチメディアデータ）に作用するかに関する知識に基づいて、必要に応じて受信処理コンポーネントにより最適な方法で情報を保存する特殊なコーデックを自動的に構成することができる。言い換えれば、分散アプリケーション（サービス）の処理コンポーネント間のデータ伝送のための設定可能な表現および圧縮形式が提案される。表現および圧縮形式は、サービスグラフおよび受信側処理機能からの情報を考慮してサービス実行時間中に設定される。たとえば、送信データに対する符号化処理は、後続の処理機能のどの情報が保存されるべきかに関する要件に従って実行時間中に動的に適応化され、これにより最適化されたメディア圧縮が実現される。

コーデックの設定は、実行されたアプリケーションのサービスグラフから、たとえばアプリケーションコンポーネントの機能の記述を考慮して、実行時に導出することができる。（たとえば、ノードの境界を横断し、マルチメディアデータを搬送する）通信チャネルのコーデックは、受信ノードでの後続の処理機能により必要とされるメディア表現の情報に基づいて設定することができる。さらに、送信データ形式は、サービスグラフがアプリケーションの内部サービス論理に従って修正される場合に、サービス実行時に動的に適応させることができる。

さらに、送信データの動的設定により、処理フロー内の後続のコンポーネントの要件に基づいて、ビデオまたは音声データなどを含むメディアデータなどの送信データを最適に表現するために送信データに対する適切な表現形式を選択することが可能になる。たとえば、受信処理機能が送信データから抽出された特徴に作用する場合、送信コンポーネントにおいて特徴を生成し、元のデータの代わりに特徴の表現を送信することがより効率的である場合がある。加えて、受信処理機能が特徴領域において直接的にデータを受信できる場合に、特徴変換の逆演算をデコーダにおいて回避することができる。

以下、「システム」という用語が「プラットフォーム」という単語と交換できることに留意されたい。「データ」という用語は、システムの部分／ノード／コンポーネントの間で交換／転送される情報を示すことができる。「メッセージ」という用語は、メッセージのヘッダと、送信すべきデータ（ペイロード）とを実質的に意味することがある。アプリケーショングラフおよびサービスグラフという用語は、同義的に使用される。

「符号化／復号」という用語は、符号化および／または復号を示す。具体的には、メッセージ／データがそこから送信される一方の側において、データが符号化（圧縮）され、他方側すなわち受信側において、データが復号されることを意味する符号化および復号を示す。以下では、第１のコンポーネントがデータを送信するコンポーネント、すなわち「送信コンポーネント」であること、また、第２のコンポーネントがデータを受信するコンポーネント、すなわち「受信コンポーネント」であることが仮定されることになる。しかしながら、システムが３つ以上のノードおよび３つ以上のコンポーネントを備えることができることに留意されたい。さらに、複数の異なる通信チャネルを、２つ以上のノード間に確立することができる。「受信ノード」および「送信ノード」という用語は、受信／送信コンポーネントを備えるノードを示す。ノードという用語は、少なくとも１つのプロセッサと、少なくとも１つの記憶デバイスと、少なくとも１つのネットワークアダプタとを好ましくは備えるコンピューティングリソースまたはホストを示すことができる。言い換えれば、ノードは、ネットワークにおいて他のノードと接続された完全に動作可能なスタンドアローンの処理ユニットであることが好ましい。

処理コンポーネントの特性に依存した処理コンポーネント間のデータ伝送のための符号化／復号スキーマの選択および／または設定は、具体的には、アプリケーション（サービス）グラフおよびアプリケーションの実際の配備状況、すなわち、どのコンポーネントがどの処理リソース（ノード）上で実行されているか、サービスグラフ内のどの通信チャネルが外部ネットワークリンク（ノード境界）を横断するかを分析することで実現することができる。システム（プラットフォーム）は、どの後続の処理機能（すなわち、処理コンポーネント）および関連するメディアタイプが、遠隔の処理リソースにおいてメディアストリームを処理しているかを決定することができる。この情報に基づいて、コーデック（圧縮および逆圧縮機能）の動作は、受信コンポーネントの機能要件に応じて送信コンポーネントおよび後続のコンポーネントの間のネットワークリンク（通信チャネル）を横断するデータの量を削減するように設定することができる。

自動的に適応するコーデックの態様は、たとえば、変換処理、予測方法などの選択を含むことができる。たとえば、標準的なコーデックでは離散コサイン変換（ＤＣＴ）が用いられ、その理由は、この変換が基本的な構造を保存し、量子化が影響を及ぼすのは、たかだか符号化されたメディアストリームの高周波であって、これらは人間の視聴者にとってあまり重要でないであるからである。エンコーダ／デコーダペアの後方に配置された物体検出などのコンポーネントに関して、より詳細な変換処理を用いることが、特徴空間における疎らさ（ｓｐａｒｓｉｔｙ）を増加させる場合に、さらにいっそう適切であることがある（たとえばエッジフィルタまたは他の関心演算子（ｉｎｔｅｒｅｓｔ ｏｐｅｒａｔｏｒ））。疎表現は、画像の多数の（非関連）部分に零（に近い）値を有することを特徴とする。したがって、量子化は、ネットワークリンクの受信側の遠隔処理ノードにおいて実行される後続の処理ステップについての関連情報のみを保存する。

たとえばコンテンツに適応してエンコーダの量子化テーブルを修正することで、後続のコンポーネントの処理要件に応じて最適化されたコーデック設定を決定する態様に加えて、後続のコンポーネントのデータ消費処理機能により公開されたリアルタイム情報に基づいた、実行時に利用可能な動的コンテンツを意識した適応化のサポートを導入することで、柔軟性の新しい側面が開示される。これは、コンポーネントが、以前に受信されたデータストリームの内部処理の結果に基づいてその受信メディアコンテンツフローを適応させるための情報を提供することが可能な、分散プラットフォームに向けたコンポーネントインターフェースを提供することで実現される。たとえば、コンポーネントは、フレーム毎秒での時間分解能を増加または減少させるようにデータレートを適応させるよう要求することができる。これは、該当するイベントが検出されない限りレートを減少させてもよい監視アプリケーションなどで有用である。同様に、たとえば粒度の粗い分析を許可し、再び最大解像度に戻るべき事象の場合のみ詳細分析を行うように、空間解像度を適応させることができる。元のビデオの動的スライシングにより、エンコーダが、異なる領域に対して独立したデータを生成することと並行して、異なった潜在的に独立なパラメータセットを使用することが可能となる。符号化された信号の複数の受信者を想定すると、これにより、受信者ごとに最適化されたパラメータを用いて特定の関心領域を定義することが可能となる。たとえば、物体追跡アルゴリズムは予測モードとして動き推定のみを使用し、これは、動きベクトルに含まれる情報を遠隔側で直接使用できるためである。

この種の適応化が、ネットワーク帯域幅を節約するために異なる処理リソース上で実行される処理機能の間で効率的なメディア圧縮が必要な場合以外でも有益なことがあることにも留意されたい。この方式は、送信および対応する受信コンポーネントが同一の処理リソース上で実行される場合にも有益である。この態様は、全体的な処理の必要性を低減させることができる。たとえば、上記で説明された監視の例では、メディアストリームの解像度を低減すると、異常な状況が存在するかを検出するためにビデオを処理するための演算が少なくなる。何らかの異常な状況が検出された場合にのみ、受信コンポーネントはより高い解像度を要求し、可能な最善の分析を行うことになる。

加えて、メディアストリームに作用する複数の処理要素が遠隔側で動作し、元の信号と異なる情報を要求することになる場合をサポートするための、複数の変換、スライスグループなどの組み合わせを含むエンコーダ／デコーダコンポーネントの柔軟な設定は、柔軟なメディア伝送コンテナの設定および使用によりさらにサポートされることになり、このコンテナ内で、個別情報を共にグループ化して単一メッセージ内でネットワークを越えて伝送し、遠隔ノードにおいて分解することができる。

一態様によれば、通信チャネルを介して接続された少なくとも２つの処理ノード上で実行されるアプリケーションの処理コンポーネントを自動的に配布するように構成されたアプリケーション配布ユニット（アプリケーション配布機能とも呼ばれる）が説明される。アプリケーション配布ユニットは、送信処理コンポーネントおよび対応する受信処理コンポーネントが異なる処理ノードに配置される場合に、データを受信する処理コンポーネントに関する情報に基づいて、どの表現でデータが送信処理コンポーネントから対応する通信チャネルを介して送信されるべきかを決定するように構成される。

一態様によれば、分散処理環境の処理ノードの間でデータを伝送するための方法が提供される。方法は、通信ネットワークを介して接続された処理ノードにわたって分散処理環境上で実行されるアプリケーションの処理コンポーネントを配布することを備えることができる。データを通信するために、送信処理コンポーネントの発信ポートを受信処理コンポーネントの着信ポートにネットワークに確立された通信チャネルを介して接続することができる。送信処理コンポーネントおよび受信処理コンポーネントが異なるノードに配置されている、すなわち、通信チャネルがノード境界を通って伸びておりネットワークリンクを含むと決定された場合に、方法は、受信処理コンポーネントに関する情報に基づいて、どの表現でデータを対応する通信チャネルを介して送信すべきかを決定することを備えることができる。受信処理コンポーネントに関する情報は、受信コンポーネントにより実行される処理に関する情報、および／または、どのデータを受信コンポーネントが処理中に使用するか、たとえば送信コンポーネントが送信しようとする元のデータのどの部分が受信コンポーネントに関連するかに関する情報を含むことができる。データの表現は、たとえば、元のデータの選択、元のデータの変換、および／または元のデータの符号化（または圧縮）を含むことができる。適切なデータ表現が決定されると、送信すべきデータを決定された表現に変換するためのデータ変換器を呼び出すことができ、決定された表現の変換されたデータを、送信コンポーネントのノードから受信コンポーネントのノードに送信することができる。

一態様によれば、送信処理ノードは、少なくとも１つの実行環境と、少なくとも１つの処理コンポーネントと、通信チャネルを経由してデータを送信するために受信処理ノードと通信チャネルを介して接続可能な少なくとも１つの発信ポートとを備えることができる。実行環境は、通信チャネルを確立するように構成することができる。送信処理ノードは、受信処理ノード上に配置された受信処理コンポーネントに関する情報に基づいて、どの表現でデータを通信チャネルを介して送信すべきかを決定するように構成することができる。したがって、送信処理ノードは、アプリケーション配布ユニットを備えることができる。受信処理ノードは、少なくとも１つの処理コンポーネントと、通信チャネルを経由してデータを受信するために送信処理ノードと通信チャネルを介して接続可能な少なくとも１つの着信ポートとを備えることができる。受信処理ノードは、受信処理ノード上に配置された処理コンポーネントに関する情報を送信処理ノードに送信するように構成することができる。あるいは、またはこれに加えて、受信処理ノードは、どの表現でデータが送信されるべきかを送信処理ノードに知らせるように構成されたアプリケーション配布ユニットを備えることができる。

一態様によれば、システムは、少なくとも２つの処理ノードを備えることができる。ノードは、通信ネットワークにより接続することができる。さらに、システムはアプリケーション配布機能を有することができ、または、システムはアプリケーション配布ユニットを備えることができる。アプリケーション配布機能またはユニットは、ノードにわたってシステム上で実行されるアプリケーションの処理コンポーネントを自動的に配布することができる。さらに、ノードは、実行環境を有することができる。実行環境は、データを送信する処理コンポーネントの発信ポートをデータを受信する処理コンポーネントの着信ポートと通信チャネルを介して接続するための手段を含むことができる。さらに、システムは、送信処理コンポーネントおよび対応する受信処理コンポーネントが異なるノードに配置される場合、データを受信する処理コンポーネントに関する情報に基づいて、どの表現でデータを対応する通信チャネルを介して送信すべきかを決定するように構成することができる。システムは、決定された表現でデータを送信するようにさらに構成することができる。

データの可能な表現が、送信処理コンポーネントの元のデータ形式、元のデータの空間的、時間的またはスペクトル的に削減された表現、元のデータの圧縮または符号化された表現、変換領域における表現、および／または元のデータからもしくは上述の表現のうちの１つから抽出された特徴、のうちの１つまたは複数を含むことができる。

言い換えれば、システムは、通信チャネルを介して、どのデータが送信されるべきか、および、どのデータ特性でデータが送信されるべきかを決定するように構成することができる。どのデータが送信されるか、および、どのデータ特性でデータが送信されるかに関する決定は、データを受信する処理コンポーネントに関する情報に基づくことができる。「どのデータ」は、「表現（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）」、たとえば、ＲＧＢ、ＣＭＹＫ、黒／白などの特定の色空間におけるビデオまたは画像データの表現を意味することが好ましい。さらに、表現は、特徴空間におけるメディアデータの特徴の表現、または空間領域におけるメディアデータの表現を指定することができる。たとえば、空間領域におけるビデオデータの表現は、ビデオフレームの一部（切り出し）のみが使用されることを指定することができる。さらに表現は、データが、たとえば符号化された、または生のデータであることを指定することができる。「データ特性」という用語は、メディアデータの解像度サイズなどを含むデータサイズ、データタイプ形式、ビデオデータなどのフレームレートなどの特性を指定することが好ましい。

送信コンポーネントを備えるノードは、送信ノードである。受信コンポーネントを備えるノードは、受信ノードである。符号化／復号は、データが、通信チャネルを介して転送される前に符号化され、受信コンポーネントにより受信される前に復号されることを示す。コーデックという用語は、エンコーダおよびデコーダの対応するペアについて使用される。

上述のシステムの具体的な例は、ビデオサービスの２つの処理コンポーネント間に動的設定可能符号化および表現形式を提供することで、最小限の計算労力で分散ビデオ処理シナリオにおける有効ネットワーク使用量を低減させるためのシステムである。たとえば、どの処理コンポーネントがビデオストリームに依存するかに関する知識に基づいて、依存する処理コンポーネントにより必要に応じて情報を保存する特殊なコーデックが自動的に設定される。

通信チャネルを経由して転送されるデータがメディアデータ、たとえばビデオデータ、音声データおよび／または画像データである場合に、データの符号化表現を決定できることが好ましい。データの符号化表現が決定された場合に、システムは、後続の処理コンポーネントにより適用される処理に関する情報に基づいてエンコーダをインスタンス化し、元のデータの情報保存部分を再構成するためにエンコーダに対応するデコーダをインスタンス化する要求を受信コンポーネントノードに送信するよう送信ノードのコーデックマネージャに指示するようにさらに構成することができる。

さらに、システムは、アプリケーションの実行時間中にエンコーダおよびデコーダをインスタンス化または適応化するためのコーデックマネージャを備えることができる。コーデックは、変換処理の一種、予測方法の一種、量子化の一種、およびエントロピー符号化の一種または代表的な特徴を抽出する方法を含む符号化機能の組み合わせとすることができる。システムは、空間、時間またはスペクトル領域の少なくとも１つにおいてデータを処理することで送信すべきデータをデータ伝送形式に変換するための、メディアストリームエンコーダ、データ圧縮ユニット、および／または特徴抽出ユニットをさらに備えることができる。したがって、データは、空間、時間またはスペクトル領域の少なくとも１つにおいて処理することができる。高い自由度が、コーデックの適応化に関して利用可能である。システムは、特にネットワーク使用量を削減するという観点で、最適なコーデックを用いてアプリケーション処理中に各状況に対処できるように、多数の利用可能なコーデック設定のうちの１つを選択することができる。さらに、コーデックの動的設定により、処理フロー内の後続のコンポーネントの要件に基づいて送信されるメディアデータを最適に表現するために適切な設定を選択できるようになる。コーデック形式は、サービスグラフがアプリケーションの内部サービス論理に従って修正される場合にサービス実行時に動的に適応させることができる。

起こり得るアプリケーションシナリオに対するコーデック設定がすぐに利用可能となるように、使用可能なコーデックの組み合わせをシステムに格納することができる。たとえばビデオデータ処理の場合、高いまたは低いビットレートで、高いまたは低い許容予測誤差レベルでなど、ビデオデータの符号化に関して異なるコーデック設定が利用可能であり得る。さらに、符号化領域をデータ依存性に基づいて選択することができる。たとえば、画像またはビデオデータの背景抽出を行うコンポーネントは、主に空間領域においてデータを要求することがある。したがって、受信コンポーネントがたとえば背景抽出を行うというデータ依存性に関するシステムの知識に基づいて、システムは、それぞれの通信チャネルに対して空間領域で符号化するためだけのコーデックをインスタンス化することができる。

さらに、システムは、空間、時間またはスペクトル領域の少なくとも１つでデータを処理することで送信すべきデータをデータ伝送形式に変換するための、メディアストリームエンコーダ、データ圧縮ユニットおよび／または特徴抽出ユニットをさらに備えることができる。

システムは、処理コンポーネントの間のデータ依存性に関する情報、および／または（直接的もしくは間接的に）受信処理コンポーネントにより実行される処理動作に関する情報を取得するためのサービスグラフアナライザをさらに備えることができる。データ依存性情報および／または処理情報は、データを受信コンポーネントへ送信する表現を決定するために使用される。さらに、システムは、接続マネージャを備えることができる。システムは、処理コンポーネントの間のデータ依存性に関する情報を取得するためにサービスグラフアナライザをアクティブ化するようにさらに構成することができる。データ依存性に関する取得された依存性情報を用いて、表現、すなわちどのデータか、および、どのデータ特性データを用いるかを決定することができる。さらに、接続マネージャまたはシステム機能は、サービスグラフアナライザをアクティブ化することができる。

さらに、依存性情報は、通信チャネルに関する情報を含むことが好ましい。たとえば、通信チャネルに関する依存性情報は、どの処理コンポーネントが通信チャネルを介して他の処理コンポーネントに接続されているかに関する情報を含むことができる。さらに、通信チャネルに関する依存性情報は、通信チャネルがノードの境界を横断する、すなわちノードの外部ネットワークリンクを使用するかを含むことができる。依存性情報は、サービス論理グラフ全体、またはサービス論理グラフの一部のみ、たとえば処理コンポーネント間のいくつかの特定の通信接続を含むことができる。

さらに依存性情報は、どのデータタイプ形式を処理コンポーネントが処理できるかに関する情報を含むことができる。たとえば、異なる離れたノードに配置された２つの処理コンポーネントの間に通信チャネルが確立された場合、転送すべきデータを符号化／復号する必要がある場合があり、通信チャネルの受信側の処理ノードおよび／または処理コンポーネントは、受信コンポーネントが限られた数の符号化／復号形式タイプのみを処理できることを示すことができる。

さらに、依存性情報は、受信処理コンポーネントで実行される処理に関する情報を含むことができる。したがって、受信処理コンポーネントは、受信処理コンポーネントが処理に必要とする必要情報を報告することができる。あるいは、システムは、前記必要情報が具体的にコンポーネントごとに格納されたサービス記述から、受信処理コンポーネントでの処理のための必要情報を決定することができる。１つの例は、通信チャネルの受信コンポーネントがビデオまたは画像データの背景抽出を実行することが依存性情報に含まれてもよいということであろう。したがって、システムは、背景抽出が受信処理コンポーネントで実行されるという依存性情報に基づいて、高解像度データが受信コンポーネントにおいて必要であると決定することができる。したがってシステムは、たとえば、生データまたは小さい量子化誤差信号で符号化されたデータを送信するように決定することができる。

加えて、依存性情報は、たとえば、受信処理ノードに関するさらなる情報、たとえば作業負荷状態、受信コンポーネントおよび／または受信ノードの処理能力などを含むことができる。

サービスグラフアナライザは、データ依存性が変化したかを前記アプリケーションの実行時間中に決定するようにさらに構成することができる。コーデックマネージャは、好ましくはデータ依存性が変化した場合に、既存の通信チャネルに関してインスタンス化された対応するエンコーダおよびデコーダのペアを再設定するように構成することができる。したがって、サービスグラフアナライザは、前記アプリケーションの実行時間中に、処理コンポーネントの配布が変化したかを決定するように適応させることができる。配布の変化は、新たなコンポーネントが作成される、および／または、処理コンポーネントがさらなる処理能力を必要とする場合などに、生じることがある。言い換えれば、コーデックを、実行時間中に、変化したデータ依存性に適応させることができる。データ依存性の変化は、処理コンポーネントの再配布（再割当）が発生したときに生じ得る。たとえば、通信チャネルの処理コンポーネントが、あるノードから他のノードへ移動された場合である。それゆえ、システムは、アプリケーション処理の実行時間中に変化に自動的に応答し対処できるようになる。アプリケーション開発者は、これらの変化に注意を払う必要がない。

さらに、システムは、通信チャネルがノードの境界を横断するかを判定し、通信チャネルがノードの境界を横断する場合に、通信チャネルを介して転送されるデータの符号化／復号が必要かを決定するように構成することができる。ノードの境界の横断は、通信チャネルが外部伝送ネットワークを使用したときに検出することができる。たとえば、ノードが、プロセッサ、記憶手段およびネットワーク端子を備えるユニットである場合に、外部伝送ネットワークは、ノードを、より具体的にはノードのネットワーク端子を互いに接続するネットワークであると定義することができる。ノードの境界の横断は、ネットワークリンクの横断と定義することができる。ノードの境界の横断は、ネットワークプロトコル、たとえばＲＴＰ、ＴＣＰ、ＵＤＰ、ＩＰが通信チャネルを経由してデータを送信するために使用される場合に検出できることが好ましい。したがって、システムは、通信チャネルを介した符号化されたデータ転送が必要であるかを自動的に決定することができる。システム機能のさらなる自動化により、システムは必要時に随時、データトラフィックを柔軟に削減できるようになる。アプリケーション開発者は、符号化／復号に、もはや注意を払う必要がない。

他の態様では、受信コンポーネントの処理に関して重要性が低い送信メディアストリーム内の情報に対するデータレートを低下させるかまたは無関係な情報を完全に省略することで、分散処理環境における有効ネットワーク使用量を削減するための方法およびシステムが提供される。関連性に関する情報は、受信コンポーネントにより、受信されたコンテンツの関連性を決定する関連性分析機能または他の手段を適用することで提供される。この関連性情報は、サービス実行中に該当する通信チャネルに対して適応的にコンテンツ（データ）圧縮を改良するようにエンコーダを導くことができ、たとえば、空間、時間またはスペクトル解像度の削減をより少ない伝送エンティティあたりのビット数へと導く。ノード上で動作するプラットフォーム機能は、処理コンポーネントから関連性情報を収集し、この情報を送信コンポーネントに提供することができる。この目的のために、フィードバックチャネルを、ノード間および処理コンポーネント間にセットアップすることができる。したがって、コンテンツ適応データ圧縮が、受信側処理機能から利用可能にされた情報を考慮して実現される。通信チャネルの送信側にフィードバックされた情報は、送信コンポーネントをホストするノードのコーデックマネージャにより、コンテンツの関連性に基づいて、適用される圧縮機能（たとえばビデオエンコーダ）の設定などを適応させるために使用することができる。エンコーダ（および対応するデコーダ）は、コンテンツの関連性に基づいて空間解像度、時間レートおよび／または特定の符号化／復号パラメータの精度を増加または減少させて、処理労力および伝送帯域幅を制限することができる。

これは、より良い圧縮結果を実現するために、受信側（受信ノード）からの、実行時に利用可能であって分析に利用可能な情報を利用する。たとえば、ビデオストリーミング、音声ストリーミング、ビデオチャットなどのアプリケーションに対して、受信コンポーネントの処理に無関係な送信データストリーム内の情報に対するデータレートを低下させることで、分散アプリケーション処理シナリオにおいて有効ネットワーク使用量を低減させることが可能となる。言い換えれば、関連性情報は、全体の処理に対して考慮され得る。

受信コンポーネントにより、たとえば受信されたコンテンツの関連性を決定可能なそれらの処理および分析機能または他の手段を適用することによって、関連性（またはそれぞれ無関係）に関する情報を公開することができる。圧縮されたリンク（これは符号化されたデータを送信する通信チャネルを意味する）の後方のこのちょうど間に合った情報により、サービス実行時間中に該当リンクに対してコンテンツ適応的な方法で圧縮の適応化を改良するようにエンコーダを導くことができる。

上述の利点は、従来技術の符号化技術で行われているように、ソース（すなわち送信処理リソース／コンポーネント）において利用可能な情報のみを用いることでは実現できない。むしろ、各ホスト／ノード上で動作するプラットフォーム機能は、圧縮されたネットワークリンクの後方で実行されるコンポーネントから情報を収集し、符号化されたリンクの送信コンポーネントをホストする処理リソースに、伝送におけるフィードバックチャネルを用いることでこれを返送する。そして、実行時に利用可能なこの情報を用いて、送信コンポーネントをホストする処理リソース上で実行される設定可能な圧縮ユーティリティ（たとえばエンコーダ）を適応させる。これがそのようなサービスのアプリケーション開発者に透過的に実行されることに留意されたいが、その理由は、コンポーネントが同一または別個のリソース上で実行される場合にサービス論理フローからは注意が払われる必要がないためである。メディア圧縮は、基本となるプラットフォームにより自律的に、および必要な場合にのみ、コンポーネントの通信経路に含めることができる。

さらに、メディアストリームのコンテンツを「関連性マップ（ｒｅｌｅｖａｎｃｅ ｍａｐ）」により表現することが提案される。そのような関連性マップは、空間、時間またはスペクトル領域における受信されたコンテンツの予想される重要性の表現として理解することができる。コンポーネントは、特定のデータ項目が実際の現在進行中の処理に寄与した、すなわち関連した程度を決定することができ、また、このデータが、たとえばビデオ処理の場合に、次のフレームのメディア処理に寄与または関連することになる程度を予測することができる。関連性がより低いと、より少ないビットを使用するか、またはより高い予測／再構成誤差を許容するようにコーデックが導かれるので、関連性情報は、ビデオデータなどのデータをより良く圧縮するのに役立つことがある。

関連性マップは多次元マトリクスとして表現することができ、これは最初は、関連性情報を識別する一様なマトリクスとすることができる。最初は、関連性マップは、元の（無補正の）コンテンツを識別する。たとえば、最初は、関連性マップは、値「１」のみ、または値「２５５」のみ、あるいは任意の他の適用可能な値のみを備えるマトリクスとすることができる。関連性マップがたとえば「１」の値のみを含むマトリクスである場合、コーデックは静的設定に従って動作する。ビデオストリームが受信コンポーネントにより時間とともに処理される場合、受信処理コンポーネントは、メディアストリーム内のどの情報（転送すべきデータまたはペイロード）が、現在そのメディア処理タスクを実行するのに最も重要なものであるかに関する情報を提供することができる。そして、この情報を用いて、関連性マップを更新することができる。したがって、関連性マップが、たとえば「１」の値のみを含むマトリクスから、メディア処理機能の現在の需要に合わせたより最適化されたマトリクスに時間とともに進化することができる。

関連性マップは、対応する受信コンポーネントの処理に必要な情報保存の下限を具体化することができる。これは、同一のデータに依存する複数のコンポーネントに対する最適化された設定を発見できるように、異なるコンポーネントの関連性マップを組み合わせることができるので有利である。関連性マップは、逆方向チャネルを用いて先行するホストに送信することができる。逆方向チャネルは、転送すべきデータ、たとえばビデオまたは音声データなどの（マルチ）メディアデータを含む（順方向の）通信チャネルと共同で初期化することができる。

一態様によれば、送信コンポーネントおよび受信コンポーネントのノードを、逆方向チャネルを介してさらに接続することができる。逆方向チャネルは、受信コンポーネントのノードから送信コンポーネントのノードへ逆方向情報を転送するように構成することができる。送信ノードは、受信された逆方向情報に基づいて、どの表現で送信コンポーネントおよび受信コンポーネントの間の通信チャネルを介してデータを送信すべきかを決定するように構成することができる。

さらに、逆方向チャネルを経由して送信可能な逆方向情報は、通信チャネルを介して、どのデータが送信されるか、および、どのデータ特性でデータが送信されるかを決定するために使用可能な、関連性情報および／または依存性情報および／または処理情報とすることができる。したがって、通信チャネルおよび逆方向チャネルを介して接続された処理コンポーネントは、システム機能の代わりに、またはこれに加えて、表現、すなわちどのデータが通信チャネルを介してどのデータ特性で送信されるべきかに関する情報を送信することができる。結果として、データ依存性の評価に関連するシステムレベルの作業負荷を削減することができ、処理コンポーネントのレベルにシフトさせることができる。

受信ノードは、受信ノードの少なくとも１つの処理コンポーネントに対する受信データの関連性情報を収集するおよび／または組み合わせるための関連性マネージャをさらに備えることができる。

さらに、関連性情報を関連性マップに格納することができ、関連性情報は、空間、時間および／またはスペクトル領域における処理コンポーネントの処理に対するデータの関連性に関する情報を含むことができる。関連性情報がそれぞれの処理コンポーネントの処理に対するデータの寄与に関する情報とすることができると好ましい。

さらに、受信コンポーネントは、受信データの一部が現在進行中の処理に寄与している程度を決定し、前記データがアプリケーションの時間的に後の処理ステップにおける処理に寄与することになる程度を予測するように構成することができる。決定された寄与情報を、逆方向情報として送信コンポーネントをホストするノードに送信することができる。アプリケーションの後続ステップにおける処理へのデータの寄与は、たとえば時間的な側面、すなわち時間的に後の処理ステップへのデータ寄与に関連することがあり、および／または、サービス論理の側面、すなわちサービス論理において実際の処理コンポーネントの後方に割り当てられた処理コンポーネント上に配置されたアプリケーションの処理ステップへのデータ寄与に関連することがある。逆方向情報を用いて、関連性マップを更新することができる。

関連性マップの値は、逆方向チャネルを経由して提供された逆方向情報に基づいてアプリケーション処理中に更新することができる。さらに、マージされた関連性マップが作成され得るように、複数の処理コンポーネントの複数の関連性マップの値を組み合わせることができる。さらに、データが送信コンポーネントから複数の受信コンポーネントへ少なくとも１つの通信チャネルを経由して送信される場合、コーダおよびデコーダを、各受信コンポーネントに対する関連性情報を含み得る前記マージされた関連性マップに基づいて適応化することができる。関連性マップ内の値は、「０」および「１」の間、または「０」および「２５５」の間、または任意の他の適用可能な値の間に設定することができる。「０」および「１」の間の値が使用される場合、値「０」は関連がないことを示し、値「１」は完全に関連があることを示す。関連性情報は、たとえば配列またはマトリクスに格納することができる。マトリクスは、多次元とすることができる。さらに、マトリクスは、最初は「１」の値のみを備えることができる。関連性マップを用いることで、処理されたデータの関連性に関する実行時に利用可能な情報に基づいて処理要件の自動かつ効率的な適応化が可能となる。ネットワーク使用量は最小限にとどめることができる。

関連性マップの値が通信チャネルを経由して送信されるデータの一部に関して減少した場合、より少ない符号化ビットが、符号化された信号のこの現在より関連性が低い部分に費やされ、および／または、より高い予測誤差がコーダおよびデコーダにより許容され得るように、通信チャネルにより接続されたノードのエンコーダおよびデコーダを、関連性マップの値に基づいて適応させることができる。これにより、実際の関連性情報および／または依存性情報を考慮して柔軟にシステムの作業負荷を適応させることが可能となる。

関連性マップが関連性を考慮してアプリケーション処理の最も実際に即した状態を常に反映できるように、処理が処理コンポーネントで実行される場合に、関連性マップの値を適応させることができる。

さらに、異なる処理コンポーネントの異なる関連性マップの値は、マージされた関連性マップを作成できるように組み合わせることができる。送信コンポーネントから複数の受信コンポーネントに１つの物理的な通信チャネルを経由してデータが送信されると仮定すると、受信コンポーネントごとの関連性情報を含むことができる前記マージされた関連性マップに基づいて、コーダおよびデコーダを適応させることができる。これには、いくつかの受信コンポーネントが１つの送信コンポーネントから、および／または１つの通信チャネルを経由してデータを受信でき、各受信コンポーネントがその処理に関連するデータを、データが通信チャネルを経由して送信された後に使用できるという利点がある。

一態様によれば、分散処理環境の処理ノードの間でデータを伝送するための方法は、ノードにわたって分散処理環境上で実行されるアプリケーションの処理コンポーネントを配布することを備えることができる。さらに、方法は、送信処理コンポーネントの発信ポートを受信処理コンポーネントの着信ポートと通信チャネルを介して接続することを備えることができる。さらに、方法は、送信処理コンポーネントおよび受信処理コンポーネントが異なるノードに配置されているかを決定することを備えることができる。送信処理コンポーネントおよび受信処理コンポーネントが異なるノードに配置されていると決定された場合、受信処理コンポーネントに関する情報に基づいて、どの表現でデータを対応する通信チャネルを介して送信すべきかを決定することができる。さらに、方法は、送信すべきデータを決定された表現に変換することと、決定された表現の変換されたデータを、送信コンポーネントのノードから受信コンポーネントのノードに送信することとを備えることができる。

上述の態様の逆の部分もカバーされていることに留意されたい。異なるリソース上で以前に動作していた２つのコンポーネントが何らかの理由でサービス実行時に同一のリソース上に配置された場合に、以前に外部であった通信経路は内部になるので、メディア符号化および復号機能はプラットフォームにより通信経路から自動的に除去することができる。

まとめると、再設定可能な表現および圧縮形式を、サービスグラフおよび受信側処理機能からの情報を考慮して提供することで、後続の処理機能の要件に応じて実行時間中に動的に符号化処理を適応させることができ、これにより最適化されたメディア圧縮が実現される。

さらに、フィードバック（逆方向）チャネルを確立することで受信側処理機能から利用可能にされた情報を考慮して、コンテンツ適応圧縮形式が提供される。フィードバックチャネルの情報を送信機側で用いて、コンテンツの関連性に基づいて圧縮機能の設定を適応させることができる。コーデックは、処理労力および伝送帯域幅を制限するために、たとえば空間および時間レートまたは特定のパラメータの精度を増加／減少させることができる。結果として、分散アプリケーション処理シナリオにおける有効ネットワーク使用量が低減され、または、同じネットワーク使用量を用いて品質が改善される。

上記で概説された態様が、プロセッサを備える装置において実施可能であることに留意されたい。コンピュータメモリに記憶されたコンピュータプログラム命令は、プロセッサにより実行された場合に、態様を実施することができる。

以下では、添付の図面を参照して実施形態が説明される。

分散アプリケーション処理シナリオの一例示的サービスグラフの図である。 システムの概観の図である。 ２つのリソースの間に１対のエンコーダおよびデコーダを有するサービスグラフの例の図である。 ３つのリソース間に２対のエンコーダおよびデコーダを有するサービスグラフの例の図である。 ビデオ内に表示された人物に名前を提供する分散アプリケーション処理の図である。 システムの３つの異なるノードへの図５のアプリケーションの配布の図である。 各ノード内に関連性マネージャを有するさらなるシステムの概観の図である。 関連性マップにより提供される関連性情報を用いた分散ビデオアプリケーション処理の例の図である。 関連性マップにより提供される関連性情報を用いた分散ビデオアプリケーション処理の例の図である。 関連性マップにより提供される関連性情報を用いた分散ビデオアプリケーション処理の例の図である。 関連性マップにより提供される関連性情報を用いた分散ビデオアプリケーション処理の例の図である。

実施形態が、配布可能なビデオおよび他のマルチメディアアプリケーションをホストするクラウドサーバ、エンドデバイスたとえば携帯電話、パーソナルコンピュータ、または他のコンピューティングデバイス、ビデオおよびマルチメディアコンテンツを記録または表示可能なネットワークカメラおよび他のエンティティ、実際の規格に準拠したネットワークデバイスと提案された符号化形式を組み込んだプラットフォームサービスとの間の接続点として機能するインターネットゲートウェイにおいて技術的に実装可能であることに留意されたい。

クラウドベースの処理環境において、特に、別個の処理ノード上で実行される別々のソフトウェアタスクの間の以下のデータ伝送シナリオが適用され得る。１）エンドデバイス（たとえばカメラ、ディスプレイ、スマートフォン）への、およびエンドデバイスから公衆インターネットなどのネットワークの向こう側のメディア処理ノードへのメディアデータ伝送。２）単一のデータセンター内の処理ノード間のメディアデータ伝送。メディア処理は計算が複雑（すなわち高度な処理）であるためにメディア処理タスクが単一の処理ノードから外へ簡単に拡大（ｓｃａｌｅ）するので、このセットアップは行われる。３）たとえばネットワーク内でリソースを伝送して全体のリソース消費を最適化し、たとえばユーザがいる場所の近くに処理を配置してマンマシンインタラクションに関する遅延を制限するために、異なるデータセンター内に配置された処理ノード間のメディアデータ伝送。

本実施形態が、特にケース２）および３）に対処し、エンドデバイスおよびクラウドノードの間の伝送の制御が、たとえばデバイス上で専用のソフトウェアを実行する能力を有することで提供されると仮定したケース１）もカバーすることをここでは留意されたい。

たとえば、サービスプラットフォーム上の分散処理から利益を得る典型的なアプリケーションシナリオは、たとえばビデオチャットである。ビデオチャットのシナリオでは、たとえば、人々のグループが、仮想の共有されたビデオ環境／ビデオチャットルームに参加する。各個人は、自身のカメラのビデオデータをクラウドにストリーミングする。ビデオチャットサービスは、そのような共有環境内に集まっているユーザの全てのメディアストリームを結合し、各参加者に対する仮想ルームの個人用ビューを生成する（すなわち、処理する）。したがって、仮想ルーム内の各個人は、他の参加者の個人用のレンダリングされたビューを受信する。

以下では、アプリケーションの後続の処理コンポーネントにより行われる処理の知識に基づいた（コーデックのインスタンス化とも呼ばれる）コーデックの選択および／または設定は、２つの処理ノード１を備えるシステムを示す図２に基づいて説明される。受信側では、コンポーネント固有のコーデック設定をサポートする１つまたは複数の処理要素が存在する。第１のコンポーネント３は、送信コンポーネント３である（すなわちデータを送信する）が、２つの受信コンポーネント３に接続する。受信コンポーネント３は、遠隔ノード１に配置される。接続マネージャ１０は、依存性グラフを発見し分析するために、サービスグラフアナライザ９を呼び出す。依存性グラフは、サービスグラフの一部である。依存性グラフは、サービスグラフアナライザ９により生成することができる。依存性グラフは、特定の処理コンポーネント３の内容に基づいて依存性を決定することを可能にすることができる。

各ノード１において、サービスグラフアナライザ９は、各コンポーネント３に対するコーデック用の必要な設定パラメータを取り出すために、コンポーネントリポジトリ１１に連絡する。依存性グラフ内の全ての依存性が解決された後、接続マネージャ１０は、ローカルのコーデックマネージャ７に連絡して、エンコーダ５をインスタンス化し、対応するデコーダ６をインスタンス化しサービス論理の転送テーブルを更新する要求を遠隔の接続マネージャ１０に送信する。その後、メッセージをコンポーネント間で、たとえば標準的なメッセージパッシング原則（ｍｅｓｓａｇｅ ｐａｓｓｉｎｇ ｐｒｉｎｃｉｐｌｅｓ）を用いて交換することができる。他の例は、コーデックマネージャ７が接続マネージャ１０の代わりにコーデック要件を交渉することを含むことができる。

可能な動作方法が、以下、図２に基づいて説明される。第１のステップ（（１）とマークされた矢印参照）において、送信ノード１の接続マネージャ１０は、（図２で「コンポーネント１、２および３」として識別される）コンポーネント３の間の接続に関する情報を受信する。さらなるステップ（矢印（２）参照）において、接続マネージャ１０は、サービスグラフアナライザ９に、たとえば依存性グラフの一部であるデータ依存性を取得するように要求する。さらなるステップ（矢印（３ａ、３ｂ）参照）において、サービスグラフアナライザは、データ依存性を取得し、上述のようにコンポーネントレジストリ１１から情報をさらに取得する。さらに、受信側のサービスグラフアナライザも、受信ノード１のコンポーネントレジストリからデータを取得し（矢印（４）参照）、両方のノード１の接続マネージャ１０は、コンポーネント３の間に確立された通信チャネル４に対する選択されたコーデック設定について互いに知らせる（矢印（５）参照）。そして、各ノード１の接続マネージャ１０は、選択されたコーデックを設定するために各ノード１のコーデックマネージャ７をアクティブ化する。さらに、コーデックマネージャ７は、選択されたコーデックをインスタンス化し、エンコーダ５およびデコーダ６が通信チャネル４を介して送信されるデータを符号化／復号し始められるようにする。

処理要素の例は、たとえば、顔認識器または物体追跡器である。顔検出器の典型的な実装は、顔の特徴、たとえば頬より暗い目の領域、鼻梁より暗い目などを識別するための単純な弁別分類器のカスケード接続セットを用いたフィルタ操作に基づいて関心領域を決定する。物体追跡器は、１つまたは複数のフレーム間の関心領域の空間的な位置ずれを決定する。コンポーネント３が作用する基本特徴セットの記述を提供することができる。この記述は、基本となるプラットフォームにより、最も適合するエンコーダ５およびデコーダ６のペアを決定しパラメータ化するために使用することができる。

（離れて配置されたコンポーネント３の間の接続を作成するか、またはコンポーネント３を他のノード１に移動させることによる）分散コンポーネント設定では、接続マネージャ１０は、データ依存性に関してアプリケーショングラフを分析する（すなわち、どの後続コンポーネント３が、圧縮すべきデータストリームに作用するか）。実施形態では、アプリケーショングラフの分析は、プラットフォームにより、依存関係を識別するために、たとえば圧縮される必要があるデータストリームに直接的または間接的に作用する全てのコンポーネント３を発見するために、受信ノード１のサービス論理を表す転送テーブルを分析することで行われ得る。テーブルは、送信および受信処理コンポーネント３を互いに接続する通信チャネル４に関するエントリをとりわけ含むことができる。分析は再帰的に、すなわち、同一の処理パイプラインに属するコンポーネント３をホストする全てのノード１からの情報を評価することで、行うことができる。これらのコンポーネント３の各々について、コンポーネント３により処理可能なデータ形式は、プラットフォームにより、コンポーネント開発者により与えられたコンポーネント記述から評価される。データ形式から取り出された情報から、プラットフォームは、ノード１の間で交換される圧縮メディアストリーム内にどの情報が含まれる必要があるかを結論付けることができる。

アプリケーショングラフ分析の結果は、圧縮機能がインスタンス化されることになるノード１へ返送され、隣接ノード１上の現在圧縮されているデータストリームに作用しているコンポーネントの処理要求に適応した効率的な符号化方式をインスタンス化するために用いられる。

図１に、目に見える人物の名前をテキストキャプチャとしてビデオストリームに追加するアプリケーションを実現するサービス論理の一例示的フローグラフを示す。ビデオ信号は、外部ソース（たとえばカメラ）から受信され、プラットフォームで復号される（デコーダ６参照）。そして、１つまたは複数のフィルタ（たとえばホワイトバランスフィルタ）が、ビデオ改善のために適用される。顔検出器は、目に見える人物の名前を識別するために、画像を監視する。物体追跡器は、物体を追跡して、キャプチャが配置されるべきフレーム内の座標を発見する（たとえば人物の直下）。新たなビデオストリームが符号化され（エンコーダ５参照）、クライアント（または他のアプリケーション）に送信される前に、名前は指定位置にレンダリングされる。各コンポーネント３に対して、その処理タスクを行うために入力ポートで必要な情報が指定され、対応する受け入れられるデータ形式が示されている（「入力：」参照）。同様に、コンポーネント出力において利用可能なデータと、対応するデータ形式とが示されている（「出力：」参照）。

ネットワークおよびコンピューティングリソース利用に応じた物理的な処理リソースへの論理グラフの有効な割り当ては、「顔検出」および「物体追跡」コンポーネント３を同一の処理ノード１に配置して、コンポーネント３の残りを別の処理ノード１上で動作させることである場合がある。この場合、「ホワイトバランス」コンポーネント３の出力は、処理ノード１の間のネットワークリンク４を通過するために、圧縮（すなわち符号化）される必要がある。この例示的な割り当ては、図３に示されている。プラットフォームは、「顔検出」および「物体追跡」コンポーネント３をリソースＢに配置することを決定した一方で、サービスグラフの残りの部分はリソースＡで実行される。符号化５および復号６機能は、プラットフォームにより提供される。

コンポーネント記述から取り出された情報に基づいて、プラットフォーム（システム）は、リソースＡおよびＢの間の物理ネットワークの帯域幅要件を制限することになるリソースＡおよびＢの間の最良の適用可能な圧縮形式を決定する。どのように論理アプリケーションがリソースに配布されるかに基づいて（すなわち、どのコンポーネントが物理ネットワークリンクの後方に配備されるかということと、そのコンポーネントの処理機能のために保存される必要がある情報とに基づいて）この形式がサービス実行時に決定され、グラフの配備が変化した場合に変化し得ることに留意されたい。リソースＢ（図３）上のプラットフォーム機能は、「顔検出」および「物体追跡」コンポーネント３から、どのメディア情報が対応するメディア処理機能に関連するかを取り出すかまたは要求／収集する。この情報は、分散プラットフォーム機能によりリソースＡに渡され、メディアエンコーダ５は、論理フローを維持するためにコンポーネント間の情報が渡される必要がある帯域幅が制限されたネットワーク接続の後方にある後続のコンポーネント３にとって必要な関連情報のみを含むように構成されており、リソースＡ上の分散プラットフォームによりインスタンス化される。加えて、分散プラットフォームは、対応するメディア復号機能もリソースＢ上でインスタンス化されることを保証する。上記の例では、エンコーダ６は、たとえばハール特徴変換をＤＣＴの代わりに組み込み、これは顔検出器に関連する情報を保存する。動き推定パラメータは、物体追跡器により必要に応じて予測モデルにおいて計算および符号化することができる。任意の他の特徴（画像再構成に必要な細部を含む）を、除去（たとえば色情報）または交換（たとえばパッチベースの情報保存再構成モデルのコードブックベクトルによる画像細部）することができる。デコーダ６は、元の画像内の他の特徴の冗長性（または量子化）を利用して、保存される必要がある情報への最小限の影響で信号をその情報から再構成する（たとえば暗い領域および明るい領域ならびに動きベクトルを補正する）。したがって、再構成された画像は、人間の視聴者によって必ずしも「解釈可能」ではない。

図３に示された例では、リソースＡおよびリソースＢの間に１つの符号化されたメディアストリームが存在する。この符号化されたメディアストリームは、リソースＢにおける全ての受信コンポーネントに関する関連情報を保持する。（たとえばリソースＡおよび／またはＢ上の）プラットフォーム機能は、関連情報のみがそれぞれの受信コンポーネント３に渡されることを保証する。あるいは、両方のコンポーネント３は、メディアストリームに含まれる全ての情報を受信することができる。リソース（ノード）は、どの情報がどのコンポーネントに関連するかを選択し、その情報をそれぞれ転送することができる。

リソースＡおよびＢの間の符号化／復号のための異なるセットアップが可能である。たとえば、図４に、３つ以上の処理リソース（ノード）を有する配備を示す。図４に、２つの符号化／復号ペアが、受信コンポーネント３ごとに１つずつ存在することが示されている。したがって、各それぞれの受信コンポーネント３に関する関連情報のみが、各それぞれの符号化されたメディアストリームに含まれる。他の代替案では、システムは、２つのリソースのみを有することがあるが（リソースＢおよびＣが結合されることになる）、図４に示されたように２つの符号化／復号ペアを受信コンポーネント３ごとに１つずつなおも使用する。

異なる処理リソース間での（メディア）情報の符号化された伝送をサービス配備が必要とする場合はいつでも、プラットフォーム（システム）がサービス実行時に符号化／復号ペア（コーデック）を自律的にインスタンス化することに留意されたい。コンポーネント記述から取得された情報に基づいて、プラットフォームは、外部リンク４を介して、すなわちノード１の境界を越えて通信する２つのコンポーネント３の間でメディアストリームを符号化／圧縮する必要があるか、および、どのようにメディアストリームに対してコーデックを設定するかを独立して決定することができる。

プラットフォームは、圧縮されたネットワークリンク４の後方に論理的に配置された各後続のコンポーネント３の処理にどのメディア情報が関連するかを、コンポーネント記述から読み出すことができる。分散プラットフォーム機能（下記参照）は、適切に設定された符号化および復号機能が、関連する処理リソース上にセットアップされることを保証する。論理サービスグラフの配備が経時的に変化することがあるので、分散プラットフォーム機能は、どのように論理サービスグラフが分散処理リソース上に現在マッピングされているかに応じて、異なるリソースの間に符号化／復号機能を含ませ、また、除去する。

論理サービスグラフの開発者がこの符号化／復号機能のセットアップに注意を払う必要がないことに留意するのは重要である。開発者は、自身のサービスを定義する際に、関連コンポーネント記述情報を定義すれば十分である。さらに、これによりサービスの開発が開発者にとってさらに簡単になり、その理由は、サービス論理に注意を払えば十分であり（すなわち、サービスグラフを定義し、サービス実行時間中にサービスグラフの論理を変更する）、論理サービスグラフのどの部分がどのリソースで実行される必要があるかに注意を払わないためである。提案された自動符号化／復号機能の助けを得て、コンポーネントの配置は、分散プラットフォーム機能により排他的に行うことができる。

実施形態では、コンポーネント３は、画素領域または変換／特徴領域でデータを受信する手段を提供して、再構成ステップの必要性を無くすことができる。

次に、特にビデオまたは音声データなどのマルチメディアデータなどを扱うアプリケーションに対して、フィードバックループを実装し関連性マップ重み付けを用いたシステムを用いた上述の例の拡張が説明される。アプリケーションは、各コンポーネント３が別個の独立機能を提供するコンポーネントベースのシステムとして実現される。コンポーネント３は、具体的にはメッセージの一方向交換によって通信する。たとえば、メッセージは、ヘッダおよび転送すべきデータ（ペイロード）を備えることが好ましい。メッセージ伝送は、メッセージの受信者を決定する通信チャネル４（通信システムまたはリンク）を経由して実現される。

コンポーネント３の間で交換されるデータは、データが特定の処理ノード１から離れて外部ネットワークリンク４を用いて他の処理ノード１へ向かう場合に、圧縮が必要なかなりのサイズおよび／またはデータレートを有することがある。好ましくは、実施形態は、分散環境において、たとえば多数のネットワーク接続された処理ノード１（図２参照）上でホストされるコンポーネント３に関する。コンポーネント３の間で通信される必要があるデータの量を削減するために、受信コンポーネントは、その処理に関する全ての受信データの関連性を記述したデータセットを公開する。

１つの例示的な例は、ビデオチャット用のビデオアプリケーションを備え、このアプリケーションでは、処理ノード１上でカメラ信号が前処理され（たとえばホワイトバランス）、さらなる処理ノード１上で顔検出器が実行される。さらなる処理ノード１上では、背景モデリングおよび後処理が適用される。顔が検出されると、物体検出器が起動され、処理パイプラインに挿入される（図５参照）。たとえば３つの物理リソース／ノード１を用いた分散クラウド環境におけるコンポーネント３の可能な配備が、図６に示されている。符号化／復号機能５、６をインスタンス化してノード間で伝送されるメディアストリームを圧縮し、これにより必要な伝送帯域幅を低減させる。

図７に、一実施形態のアーキテクチャのスケッチが示されている。各ノード上で、実行環境２が動作し、好ましくは、コンポーネント３と、コンポーネント３の間の接続と、コンポーネント３の間のメッセージ交換との管理を担当する。さらに、ノード１上で動作する全てのコンポーネントから「関心（ｉｎｔｅｒｅｓｔｓ）」を受信するノード内部機能である「関連性マネージャ」１３が提供される。「関心要求」を受信したとき、関連性マネージャ１３は、適応化が必要かを確認するために実行環境２と相互作用することでデータストリームに作用するコンポーネント３の依存性を分析する。

データストリームに対するデコーダ６が存在する場合、たとえば、関連性マネージャ１３は、送信側関連性マネージャ１３に、対応するエンコーダ５を相応に適応させるように指示する。続いて、適応化されたデータ形式で受信された第１のメッセージは、トリガを有することになる。トリガは、ローカルデコーダ６が、トリガを有するメッセージを受信したときに相応に適応化されるべきであることを示す。処理されたデータが処理ノードの外部ネットワークリンクを越えて伝送される場合のみ、コーダ５が２つのコンポーネント３の間で交換されるべきデータの圧縮ステップを実行してもよいことに留意されたい。

上述のサービス論理を用いてシステムの機能が説明され、ここでは、コンポーネント３は説明されたようにインスタンス化され、コンポーネント３は、図７の文脈内で説明されたプラットフォーム機能を用いてコンテンツへの関心を公開する。たとえば、最初に、背景モデリングおよび顔検出器は、統計モデルが生成される必要があるので、利用可能な完全なデータを必要とする（図８）。背景コンポーネントの関心は、全ての利用可能なデータが通信される必要があるということである。モデルが収束すると、背景抽出モデルは、データレートをたとえば５０％に低減させることを決定することができる。もちろん、これは、たとえば７０％または２０％の場合もある。この情報（図９参照）は先行するホワイトバランス機能により提供される１つおきのフレームを省略し、したがってデータの半分のみを背景コンポーネントへ配信するプラットフォーム機能をトリガする。データが処理ノード１の外部ネットワークリンク４を横断する必要がある場合、トラフィックを削減するためにデータが圧縮される必要があるかにかかわらず、この例が生データストリームに適用されることがある。顔検出コンポーネントは、図９に示されるように全てのデータを受信するようにさらに要求することができる。

上記の態様は、以下で、たとえば空間的関連性についてのフレームのデータの関連性に応じてコーデックを適応させることで拡張される。言い換えれば、たとえば、画像のどの（空間）部分が後続の処理機能に関連があるかが決定され、これらの部分は、符号化方式の優先度において考慮され（たとえば関連部分に対してより多くのビットを与える）、これにより効率が改善する。非関連部分は無視されるか、低解像度で符号化される。

関連性マップを生成し、図７の関連性マネージャ１２に公開することができる。あるいは、関連性マネージャ１２は、関連性マップを生成するための関連性情報を要求することができる。たとえば、顔検出器モデルの出力は、原画像内の非顔領域から顔を分離することを可能にするマスクである。顔が検出された後、追跡器をインスタンス化して、物体を追跡することができる（図１０および図１１）。たとえば図１０では、背景抽出コンポーネント３が前景のみに関心がありそれぞれの関連性マップをそれに従って更新することが図示されていることに留意されたい。顔検出コンポーネント３は顔領域に関心があるので、それぞれの関連性マップがそれに従って更新される。輪郭データ（図１１参照）に関心がある物体追跡コンポーネント３のインスタンス化の後、顔検出器および物体追跡器の関連性マップは、結合する／組み合わせることができる。

物体追跡器コンポーネント３は、背景抽出器により公開された情報を使用してその関心マスクを定義することができる（図１１）。したがって、図１０および図１１に示された例では、物体追跡器コンポーネント３は、関連性マップを正確に更新するために画像またはビデオフレームの前景および背景の間の境界領域に関心がある。前景領域の変化が検出の精度に簡単に影響を及ぼすことがあるので、前景領域はここでは、たとえば、より高い関連性がある。

したがって、顔検出器コンポーネント３および物体追跡器コンポーネント３の関連性マップを組み合わせて、たとえば特定の領域における解像度をそれらの関心に応じて適応させる（図１１）。これは、原画像の各画素またはブロックに対して関連性情報を含むマトリクスとして表されるマスク画像を提供することで行うことができる。たとえば、マトリクスの値は、０（使用されない）および１（完全に関連がある）の間に設定される。この情報をコーデックにおいて使用して、特定のブロックを符号化するために費やされるビットレートを適応させるか、または、たとえば値「０」を含む領域におけるフレームのブロックを標準的なブロックと置き換えることで符号化を簡易化する。

実施形態は、独立したコンポーネント３によっても、適切な算術演算を用いて関連性マップを組み合わせることも可能にする。同一のデータストリーム上で、さらなるコンポーネント３が、プライバシー関連データ、たとえば画像上の背景内のホワイトボード上の文章などを除去すると仮定する。両方のコンポーネント３が独立に動作し得るので、顔領域およびホワイトボード領域は、２つの異なる関連性マップからマージされ得る。

関連性マップの値を変更することで、たとえば、スライスの数、および／または、スライス境界の位置を修正することができる。あるいは、値の変更は、量子化パラメータの適応化につながることがあり、これはデータの精度へのより高い／より低い関心を示す。

提案されたシステムは、分散（クラウドベースの）実行環境におけるマルチメディアアプリケーションの非常に柔軟な配備を可能にする。アプリケーション開発者は、リソース制約を覚えておく必要がなく、サービス論理のみを管理する。これは、クラウドが仮想的に単一のリソースとなることを意味する。

上記では特定の実施形態により実行される特定の順序の動作を説明しているが、代替的実施形態が、異なる順序で動作を実行する、特定の動作を組み合わせる、特定の動作を重複させるなどしてもよいので、そのような順序が例示的であることは理解されたい。所与の実施形態への本明細書における言及は、記載の実施形態が特定の機能、構造または特徴を含み得ることを示すが、全ての実施形態が特定の機能、構造または特徴を必ずしも含まないことがある。

記述および図面が提案方法およびシステムの原理を例示するものにすぎないことに留意されたい。したがって、本明細書には明示的に説明または図示されていないが、様々な構成を当業者が考案できるであろうことは理解されよう。さらに、本明細書に列挙された全ての例は、主に、提案方法およびシステムの原理と、発明者により当技術の発展に捧げられた概念とを理解する際に読者を補助する教育上の目的のためのものにすぎないことが明らかに意図されており、そのような具体的に列挙された例および条件に限定されないものと解釈されたい。さらに、原理、態様、および実施形態、ならびにこれらの具体例を列挙した本明細書の全ての記述は、それらの均等物を含むものとする。

さらに、様々な上述の方法のステップおよび記載のシステムのコンポーネントが、プログラムされたコンピュータにより実施可能であることに留意されたい。本明細書では、いくつかの実施形態はまた、機械可読またはコンピュータ可読であり機械実行可能またはコンピュータ実行可能な命令のプログラムを符号化するものであって、前記命令が前記上述の方法のステップの一部または全部を実施する、デジタルデータ記憶媒体などのプログラム記憶デバイスを含むものとする。プログラム記憶デバイスは、たとえば、デジタルメモリ、磁気記憶媒体たとえば磁気ディスクおよび磁気テープ、ハードドライブ、または光学的可読デジタルデータ記憶媒体とすることができる。実施形態はまた、上述の方法の前記ステップを実施するようにプログラムされたコンピュータを含むものとする。

加えて、本特許文書に記載の様々な要素の機能を、専用ハードウェア、ならびに適切なソフトウェアと関連してソフトウェアを実行可能なハードウェアを用いて提供できることに留意されたい。これらの機能は、プロセッサにより提供する場合、単一の専用プロセッサ、単一の共有プロセッサ、または一部が共有され得る複数の個別プロセッサにより提供することができる。さらに、「プロセッサ」または「コントローラ」という用語の明示的な使用は、ソフトウェアを実行可能なハードウェアを排他的に指すように解釈されるべきではなく、暗黙的に、限定はしないが、デジタル信号プロセッサ（ＤＳＰ）ハードウェア、ネットワークプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、ソフトウェアを記憶するための読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、および不揮発性記憶装置を含むことができる。他のハードウェアも、従来型および／またはカスタム型にかかわらず、同様に含むことができる。

最後に、本明細書の任意のブロック図が概念図を表すことは理解されたい。同様に、任意のフローチャート、流れ図、状態遷移図、疑似コードなどが、実質的にコンピュータ可読媒体に表現可能であって、したがってコンピュータまたはプロセッサにより、そのようなコンピュータまたはプロセッサが明示的に示されていようといまいと、実行可能である様々な処理を表すことは理解されよう。

Claims (15)

1. 通信チャネル（４）を介して接続された少なくとも２つの処理ノード（１）上で実行されるアプリケーションの処理コンポーネント（３）を自動的に配布するように構成されたアプリケーション配布ユニットであって、
   アプリケーション配布ユニットは、
   自動的に配布されている送信処理コンポーネントおよび対応する受信処理コンポーネントが、異なる処理ノード（１）に配置されているかを決定し、
   送信処理コンポーネントおよび対応する受信処理コンポーネントが異なる処理ノード（１）に配置されていると決定された場合に、データを受信する処理コンポーネント（３）によって実行される処理動作に関する情報に基づいて、どの表現でデータが対応する通信チャネル（４）を介して送信されるべきかを決定し、
   データ変換器に、送信処理コンポーネントから受信処理コンポーネントに送信すべきデータを決定されたデータ表現に変換させる、
   ようにさらに構成される、アプリケーション配布ユニット。
2. ネットワークにより接続された少なくとも２つの処理ノード（１）を備えるシステムであって、ノード（１）にわたってシステム上で実行されるアプリケーションの処理コンポーネント（３）を自動的に配布するように構成された請求項１に記載のアプリケーション配布ユニットを備え、
   各ノード（１）が実行環境（２）を有し、各実行環境（２）が、データを送信する処理コンポーネント（３）の発信ポートをデータを受信する処理コンポーネント（３）の着信ポートと通信チャネル（４）を介して接続するための手段を含む、システム。
3. データの可能な表現が、
   送信処理コンポーネントの元のデータ形式、元のデータの空間的、時間的またはスペクトル的に削減された表現、元のデータの圧縮または符号化された表現、変換領域における表現、および元のデータから抽出された特徴、のうちの１つまたは複数を含む、請求項２に記載のシステム。
4. 通信チャネル（４）を経由して転送されるデータがメディアデータ、たとえばビデオデータ、音声データおよび／または画像データである場合に、データの符号化表現が決定される、請求項２または３に記載のシステム。
5. データの符号化表現が決定された場合に、システムが、後続の処理コンポーネントにより適用される処理に関する情報に基づいてエンコーダ（５）をインスタンス化し、エンコーダ（５）に対応するデコーダ（６）をインスタンス化する要求を受信コンポーネント（３）に送信するよう送信ノード（１）のコーデックマネージャ（７）に指示するようにさらに構成された、請求項２から４のいずれか一項に記載のシステム。
6. 変換処理の一種、予測方法の一種、量子化の一種、およびエントロピー符号化の一種を含む符号化機能を組み合わせることで、アプリケーションの実行時間中にエンコーダ（５）およびデコーダ（６）をインスタンス化または適応化するためのコーデックマネージャ（７）をさらに備える、請求項４または５に記載のシステム。
7. 処理コンポーネント（３）の間のデータ依存性に関する情報、および／または受信処理コンポーネントにより実行される処理動作に関する情報を取得するためのサービスグラフアナライザ（９）
   をさらに備え、
   データ依存性情報および／または処理情報が、データを受信コンポーネントへ送信する表現を決定するために使用される、
   請求項２から６のいずれか一項に記載のシステム。
8. サービスグラフアナライザ（９）が、データ依存性が変化したかを前記アプリケーションの実行時間中に決定するようにさらに構成され、コーデックマネージャ（７）が、既存の通信チャネル（４）に関してインスタンス化された対応するエンコーダ（５）およびデコーダ（６）のペアを再設定するように構成された、請求項７に記載のシステム。
9. 送信コンポーネント（３）および受信コンポーネント（３）のノードが、逆方向チャネル（１２）を介してさらに接続され、
   逆方向チャネル（１２）が、受信コンポーネント（３）のノードから送信コンポーネント（３）のノードへ逆方向情報を転送するように構成され、
   送信ノードが、受信された逆方向情報に基づいて、どの表現で送信コンポーネントおよび受信コンポーネントの間の通信チャネルを介してデータを送信すべきかを決定するように構成された、
   請求項２から８のいずれか一項に記載のシステム。
10. 受信ノード（１）が、受信ノード（１）の処理コンポーネント（３）に対する受信データの関連性を決定するための関連性マネージャ（１３）をさらに備え、
    関連性情報が関連性マップに格納され、関連性情報が、空間、時間および／またはスペクトル領域における処理コンポーネント（３）の処理に対するデータの関連性に関する情報を含む、
    請求項９に記載のシステム。
11. 受信コンポーネント（３）が、受信データのどの部分が現在進行中の処理に寄与しているかを決定し、前記データがアプリケーションの時間的に後の処理ステップにおける処理に寄与することになるかを予測するように構成され、
    決定された寄与情報が、逆方向情報として送信コンポーネント（３）に送信される、
    請求項８から１０のいずれか一項に記載のシステム。
12. 関連性マップの値が、逆方向チャネル（１２）を経由して提供された逆方向情報に基づいてアプリケーション処理中に更新され、
    マージされた関連性マップが作成されるように、複数の処理コンポーネント（３）の複数の関連性マップの値が組み合わせ可能であり、
    データが送信コンポーネント（３）から複数の受信コンポーネント（３）へ少なくとも１つの通信チャネル（４）を経由して送信される場合、コーダ（５）およびデコーダ（６）が、各受信コンポーネント（３）に対する関連性情報を含む前記マージされた関連性マップに基づいて適応化される、
    請求項１０または１１に記載のシステム。
13. 少なくとも１つの実行環境（２）と、
    少なくとも１つの処理コンポーネント（３）と、
    通信チャネル（４）を経由してデータを送信するために受信処理ノード（１）と通信チャネル（４）を介して接続可能な少なくとも１つの発信ポートと
    を備え、
    実行環境（２）が、通信チャネル（４）を確立するように構成され、
    受信処理ノード（１）上に配置された受信処理コンポーネント（３）によって実行される処理動作に関する情報に基づいて、どの表現でデータを通信チャネル（４）を介して送信すべきかを決定するように構成された、請求項１に記載のアプリケーション配布ユニットをさらに備える、
    送信処理ノード（１）。
14. 実行環境（２）と、
    請求項１に記載のアプリケーション配布ユニットによって受信処理ノード（１）に自動的に配布される、少なくとも１つの処理コンポーネント（３）と、
    通信チャネル（４）を経由してデータを受信するために送信処理ノード（１）と通信チャネル（４）を介して接続可能な少なくとも１つの着信ポートと
    を備え、
    受信処理ノード（１）上に配置された処理コンポーネント（３）によって実行される処理動作に関する情報をアプリケーション配布ユニットに送信するように構成された、
    受信処理ノード（１）。
15. 分散処理環境の処理ノード（１）の間でデータを伝送するための方法であって、
    ノード（１）にわたって分散処理環境上で実行されるアプリケーションの処理コンポーネント（３）を配布することと、
    送信処理コンポーネント（３）の発信ポートを受信処理コンポーネント（３）の着信ポートと通信チャネル（４）を介して接続することと、
    送信処理コンポーネント（３）および受信処理コンポーネント（３）が異なるノード（１）に配置されているかを決定することと、
    送信処理コンポーネント（３）および受信処理コンポーネント（３）が異なるノード（１）に配置されていると決定された場合に、受信処理コンポーネント（３）によって実行される処理動作に関する情報に基づいて、どの表現でデータを対応する通信チャネル（４）を介して送信すべきかを決定することと、
    送信すべきデータを決定された表現に変換することと、
    決定された表現の変換されたデータを、送信コンポーネント（３）のノードから受信コンポーネント（３）のノードに送信することと
    を備える、方法。

Images