JP7405976B2 - クラウドワークフローにおけるタイムアウト及び完了データ入力のシグナリング - Google Patents

Description

［関連出願の相互参照］
本出願は、２０２０年６月２４日に出願された米国仮出願第６３／０４３，６６０号、２０２０年１０月５日に出願された米国仮出願第６３／０８７，７５５号、及び２０２１年４月１９日に出願された米国出願第１７／２３３，７８８号の優先権を主張するものであり、これらは、参照により全体が本出願に明示的に組み込まれる。

１．技術分野
本開示は、ネットワークベースのメディア処理（ＮＢＭＰ）ワークフローとその関数の入力及び出力との関連付け、並びにクラウドワークフローにおける入力データのタイムアウト又は入力データの完了のシグナリングを対象とする。

２．従来技術の説明
ＭＰＥＧ ＮＢＭＰプロジェクトは、クラウド上でメディアを処理するという概念を開発した。しかしながら、現在のＮＢＭＰ設計には、異なるネットワークエンティティ、ＭＰＥ、ソース、又はシンク間でワークフローを分割する品質を測定する能力がないという技術的な問題がある。

ＮＢＭＰ国際仕様案は、メディア処理効率の向上、メディアサービスの高速かつ低コストの展開、及びパブリッククラウドサービス、プライベートクラウドサービス又はハイブリッドクラウドサービスの活用による大規模な展開を提供する能力の大きな可能性を示す。

ＮＢＭＰ仕様でタスク及びワークフローのアイドル状態と実行状態が定義されている場合でも、そのような仕様には変更がどのように発生するかが欠けている。したがって、タスク又はワークフローの各入力の状態を定義し、その状態を変更するための条件を特定できないという技術的な問題がある。したがって、タスク又はワークフローは、その入力内のデータが完了しているか否かを判定することができず、また、タスク又はワークフローには、データが停止しているか否かを判定するためのルールがない。

更に、ネットワークとクラウドプラットフォームを使用して様々なアプリケーションを実行できる場合でも、ＮＢＭＰ規格では、ワークフローの入力と出力をその関数の入力と出力に１対１でマッピングせずに、必要とされる処理を定義するワークフロー記述が定義されている。

現在のＮＢＭＰワークフロー記述は、可能なワークフロー有向非巡回グラフ（ＤＡＧ）を含むワークフローの詳細な説明を提供することができるが、そのような記述には、ワークフロー入力と出力記述を個々の関数の入力又は出力に関連付けることが欠けている。

更に、ワークフローのどの入力が特定の関数インスタンスの入力に関連付けられているか、ワークフローのどの出力が特定の関数インスタンスの出力に関連付けられているかが明確でない場合がある。これは、接続マップが関数間の接続のみを定義し、関数インスタンスとワークフローの入力／出力との間の接続を定義していないという事実によるものである。

ワークフローの入力／出力がすべての最初又は最後の関数の中で異なる場合、ワークフローマネージャは、すべての入力／出力間の各入力／出力の一意性により、関連付けを見つけることができる。ただし、ワークフローに同じ記述を有する複数の入力／出力（ストリームｉｄのみが異なる）が含まれている場合、ワークフローの入力／出力に対して適切な関数入力／出力を識別するには曖昧さがある。

言い換えれば、上記の他の技術的問題の中で、ワークフロー入力と出力を特定の関数入力と出力に割り当てることには曖昧さがある。

１つ又は複数の異なる技術的問題に対処するために、本開示は、例示的な実施形態による、１つ又は複数のビューポートマージン更新に関して没入型ビデオを配信しながら、ネットワークオーバーヘッド及びサーバ計算オーバーヘッドを削減するための技術的解決策を提供する。

方法と、コンピュータプログラムコードを記憶するように構成されたメモリ、及びコンピュータプログラムコードにアクセスし、コンピュータプログラムコードの指示に従って動作するように構成された１つ又は複数のプロセッサを含む装置とが含まれる。コンピュータプログラムコードは、少なくとも１つのプロセッサに、ＮＢＭＰにおけるタスク及びワークフローのうちの少なくとも１つの入力を取得させるように構成された取得コードと、少なくとも１つのプロセッサに、タスク及びワークフローのうちの少なくとも１つの入力のタイムアウトを設定させるように構成された設定コードと、少なくとも１つのプロセッサに、タスク及びワークフローのうちの少なくとも１つが、タイムアウトに等しい期間、入力のデータの欠如を監視したか否かを判定させるように構成され、それにより、少なくとも１つのプロセッサに、タスク及びワークフローのうちの少なくとも１つが、タイムアウトに等しい期間、入力のデータの欠如を監視したことに応じて、入力の更なるデータが利用できないと判定させるように更に構成された判定コードと、少なくとも１つのプロセッサに、入力の更なるデータが利用できないと判定したことに基づいて、ＮＢＭＰにおけるタスク及びワークフローのうちの少なくとも１つに更新を適用させるように構成された適用コードと、少なくとも１つのプロセッサに、更新に基づいて、ＮＢＭＰにおけるタスク及びワークフローのうちの少なくとも１つを処理させるように構成された処理コードとを含む。

例示的な実施形態によれば、判定コードは、少なくとも１つのプロセッサに、タスク及びワークフローのうちの少なくとも１つの状態が実行状態に設定されているか否かを判定させるように更に構成され、判定コードは、状態が実行状態に設定されていると判定した場合、少なくとも１つのプロセッサに、タスク及びワークフローのうちの少なくとも１つが、タイムアウトに等しい期間、入力のデータの欠如を監視したか否かに基づいて、状態を実行状態からアイドル状態に変更するか否かを判定させるように更に構成される。

例示的な実施形態によれば、判定コードは、少なくとも１つのプロセッサに、タスク及びワークフローのうちの少なくとも１つの入力が、関数の入力及び出力のうちの少なくとも１つに関連付けられるか否かを判定させるように更に構成され、コンピュータプログラムコードは、少なくとも１つのプロセッサに、タスク及びワークフローのうちの少なくとも１つの入力が、関数の入力及び出力のうちの少なくとも１つに関連付けられると判定したことに応じて、タスク及びワークフローのうちの少なくとも１つの入力を関数の入力及び出力のうちの少なくとも１つに関連付けさせるように構成された関連付けコードを更に含む。

例示的な実施形態によれば、判定コードは、少なくとも１つのプロセッサに、入力が表示を含むか否かを判定させるように更に構成され、また、判定コードは、少なくとも１つのプロセッサに、入力が表示を含むと判定したことに応じて、入力の更なるデータが利用できないと判定させるように更に構成される。

例示的な実施形態によれば、表示は、タスク及びワークフローのうちの少なくとも１つの入力と共に含まれている入力完了フラグを含む。

例示的な実施形態によれば、表示は、タスク及びワークフローのうちの少なくとも１つの入力と共に提供されたメタデータに含まれている。

例示的な実施形態によれば、取得コードは、少なくとも１つのプロセッサに、タスク及びワークフローのうちの少なくとも１つの、入力を含む複数の入力を取得させるように更に構成され、判定コードは、少なくとも１つのプロセッサに、タスク及びワークフローのうちの少なくとも１つの状態が実行状態に設定されているか否かを判定させるように更に構成され、判定コードは、少なくとも１つのプロセッサに、タスク及びワークフローのうちの少なくとも１つのすべての入力が、タイムアウトに等しい期間、すべての入力のデータの欠如を監視したか否かを判定させるように更に構成され、判定コードは、状態が実行状態に設定されていると判定した場合、少なくとも１つのプロセッサに、タスク及びワークフローのうちの少なくとも１つが、すべての入力のタイムアウトに等しい期間、入力のデータの欠如を監視したか否かに基づいて、状態を実行状態からアイドル状態に変更するか否かを判定させるように更に構成される。

例示的な実施形態によれば、タスク及びワークフローのうちの少なくとも１つのすべての入力が、タイムアウトに等しい期間、すべての入力のデータの欠如を監視したか否かを判定するステップは、タスク及びワークフローのうちの少なくとも１つの入力の少なくとも１つが、タイムアウト表示及び完了表示のいずれかを示すか否かを判定することを含む。

例示的な実施形態によれば、判定コードは、少なくとも１つのプロセッサに、タスク及びワークフローのうちの少なくとも１つの入力のそれぞれが、１つ又は複数の関数の入力及び出力のうちの少なくとも１つにそれぞれ関連付けられるか否かを判定させるように更に構成され、コンピュータプログラムコードは、少なくとも１つのプロセッサに、タスク及びワークフローのうちの少なくとも１つの入力のそれぞれが、１つ又は複数の関数の入力及び出力のうちの少なくとも１つにそれぞれ関連付けられるか否かを判定したことに基づいて、タスク及びワークフローのうちの少なくとも１つの入力を、１つ又は複数の関数の入力及び出力のうちの少なくとも１つにそれぞれ関連付けさせるように構成された関連付けコードを更に含む。

例示的な実施形態によれば、タスク及びワークフローのうちの少なくとも１つの入力のそれぞれが、１つ又は複数の関数の入力及び出力のうちの少なくとも１つにそれぞれ関連付けられるか否かを判定するステップは、タスク及びワークフローのうちの少なくとも１つの入力のそれぞれに対する識別子及びポート名の少なくとも１つを判定し、そして対応する入力ポート及び出力ポートのうちの少なくとも１つの対応するポート名及びストリーム識別子の少なくとも１つを判定することを含む。

開示された主題の更なる特徴、性質、及び様々な利点は、以下の詳細な説明及び添付の図面からより明らかになるであろう。

実施形態による簡略概略図である。 実施形態による簡略概略図である。 実施形態によるデコーダに関する簡略ブロック図である。 実施形態によるエンコーダに関する簡略ブロック図である。 実施形態によるエンコーダに関する簡略ブロック図である。 実施形態によるエンコーダに関する簡略状態図である。 実施形態によるピクチャに関する簡略ブロック図である。 実施形態によるエンコーダに関する簡略ブロック図である。 実施形態による簡略化されたフローチャートである。 実施形態による概略図である。

以下で説明する提案された特徴は、個別に使用することも、任意の順序で組み合わせて使用することもできる。更に、実施形態は、処理回路（例えば、１つ又は複数のプロセッサ又は１つ又は複数の集積回路）によって実装されてもよい。一例では、１つ又は複数のプロセッサは、非一時的なコンピュータ可読媒体に記憶されたプログラムを実行する。

図１は、本開示の一実施形態による通信システム１００の簡略ブロック図を示す。通信システム１００は、ネットワーク１０５を介して相互接続された少なくとも２つの端末１０２及び１０３を含むことができる。データの一方向送信の場合、第１の端末１０３は、ネットワーク１０５を介して他方の端末１０２に送信するために、ローカル位置でビデオデータを符号化することができる。第２の端末１０２は、ネットワーク１０５から他方の端末の符号化ビデオデータを受信し、そして符号化データをデコードして復元されたビデオデータを表示することができる。一方向データ送信は、メディアサービングアプリケーションなどにおいて一般的である可能性がある。

図１は、例えば、ビデオ会議中に発生する可能性のある符号化ビデオの双方向送信をサポートするために提供される第２の対の端末１０１及び１０４を示す。データの双方向送信の場合、各端末１０１及び１０４は、ネットワーク１０５を介して他方の端末に送信するために、ローカル位置でキャプチャされたビデオデータを符号化することができる。各端末１０１及び１０４はまた、他方の端末によって送信された符号化ビデオデータを受信し、符号化データをデコードし、そしてローカルディスプレイデバイスで復元されたビデオデータを表示することができる。

図１において、端末１０１、１０２、１０３及び１０４は、サーバ、パーソナルコンピュータ、及びスマートフォンとして示され得るが、本開示の原理は、そのように限定されない。本開示の実施形態は、ラップトップコンピュータ、タブレットコンピュータ、メディアプレーヤー、及び／又は専用ビデオ会議装置に適用することができる。ネットワーク１０５は、例えば、有線及び／又は無線通信ネットワークを含めて、端末１０１、１０２、１０３及び１０４の間で符号化ビデオデータを伝達する任意の数のネットワークを表す。通信ネットワーク１０５は、回線交換チャネル及び／又はパケット交換チャネルでデータを交換することができる。代表的なネットワークには、電気通信ネットワーク、ローカルエリアネットワーク、広域ネットワーク、及び／又はインターネットが含まれる。本議論の目的のために、ネットワーク１０５のアーキテクチャ及びトポロジーは、本明細書で以下に説明されない限り、本開示の動作にとって重要ではない可能性がある。

図２は、開示された主題の適用の一例として、ストリーミング環境におけるビデオエンコーダ及びデコーダの配置を示す。開示された主題は、例えば、ビデオ会議、デジタルＴＶ、ＣＤ、ＤＶＤ、メモリースティックなどを含むデジタル媒体への圧縮ビデオの保存などを含めて、他のビデオ対応アプリケーションにも同様に適用可能である。

ストリーミングシステムは、例えば、非圧縮ビデオサンプルストリーム２１３を作成するビデオソース２０１、例えばデジタルカメラを含むことができるキャプチャサブシステム２０３を含み得る。そのサンプルストリーム２１３は、エンコードされたビデオビットストリームと比較した場合、高いデータ量として強調されてもよく、またカメラ２０１に結合されたエンコーダ２０２によって処理することができる。エンコーダ２０２は、以下でより詳細に説明されるように、開示された主題の態様を可能にするか又は実施するために、ハードウェア、ソフトウェア、又はそれらの組み合わせを含むことができる。エンコードされたビデオビットストリーム２０４は、サンプルストリームと比較した場合に、より低いデータ量として強調されてもよく、また将来の使用のためにストリーミングサーバ２０５に記憶することができる。１つ又は複数のストリーミングクライアント２１２及び２０７は、ストリーミングサーバ２０５にアクセスして、エンコードされたビデオビットストリーム２０４のコピー２０８及び２０６を検索することができる。クライアント２１２は、エンコードされたビデオビットストリーム２０８の着信コピーをデコードし、そしてディスプレイ２０９又は他のレンダリングデバイス（図示せず）上にレンダリングされ得る発信ビデオサンプルストリーム２１０を作成するビデオデコーダ２１１を含むことができる。一部のストリーミングシステムでは、ビデオビットストリーム２０４、２０６及び２０８は、特定のビデオコーディング／圧縮規格に従ってエンコードすることができる。これらの規格の例は、上記に記載されており、本明細書で更に説明される。

図３は、本発明の一実施形態によるビデオデコーダ３００の機能ブロック図であり得る。

受信機３０２は、デコーダ３００によってデコードされるべき１つ又は複数の符号化ビデオシーケンスを、同じ又は別の実施形態では、一度に１つの符号化ビデオシーケンスで受信することができ、ここで、各符号化ビデオシーケンスのデコードは他の符号化ビデオシーケンスから独立している。符号化ビデオシーケンスは、チャネル３０１から受信されてもよく、チャネルは、エンコードされたビデオデータを記憶する記憶装置へのハードウェア／ソフトウェアリンクであり得る。受信機３０２は、エンコードされたビデオデータを、他のデータ、例えば、符号化オーディオデータ及び／又は補助データストリームと共に受信することができ、これらのデータは、それぞれの使用エンティティ（図示せず）に転送され得る。受信機３０２は、符号化ビデオシーケンスを他のデータから分離することができる。ネットワークジッターに対処するために、バッファメモリ３０３は、受信機３０２とエントロピーデコーダ／パーサ３０４（以降、「パーサ」）との間に結合されてもよい。受信機３０２が十分な帯域幅及び可制御性を有するストア／フォワードデバイスから、又は等同期ネットワークからデータを受信しているとき、バッファ３０３は使用されなくてもよく、又は小さくてもよい。インターネットなどのベストエフォートパケットネットワークで使用するために、バッファ３０３が必要とされる場合があり、それは、比較的大きくてもよく、有利には適応可能なサイズであってもよい。

ビデオデコーダ３００は、エントロピー符号化ビデオシーケンスからシンボル３１３を再構成するためのパーサ３０４を含んでもよい。これらのシンボルのカテゴリには、デコーダ３００の動作を管理するために使用される情報と、デコーダの不可欠な部分ではないがデコーダに結合することができるディスプレイ３１２などのレンダリングデバイスを制御するための潜在的な情報とが含まれる。レンダリングデバイス用の制御情報は、例えば、補足強化情報（ＳＥＩ）メッセージ又はビデオユーザビリティ情報パラメータセットフラグメント（図示せず）の形式であってもよい。パーサ３０４は、受信した符号化ビデオシーケンスを解析／エントロピーデコードすることができる。符号化ビデオシーケンスのコーディングは、ビデオコーディング技術又は規格に従うことができ、また、可変長コーディング、ハフマンコーディング、コンテキスト感度を伴う又は伴わない算術コーディングなどを含めて、当業者に周知の原理に従うことができる。パーサ３０４は、グループに対応する少なくとも１つのパラメータに基づいて、符号化ビデオシーケンスから、ビデオデコーダ内のピクセルのサブグループの少なくとも１つ用のサブグループパラメータのセットを抽出することができる。サブグループは、ピクチャグループ（ＧＯＰ）、ピクチャ、タイル、スライス、マクロブロック、コーディングユニット（ＣＵ）、ブロック、変換ユニット（ＴＵ）、予測ユニット（ＰＵ）などを含むことができる。エントロピーデコーダ／パーサはまた、符号化ビデオシーケンス情報から変換係数、量子化器パラメータ値、動きベクトルなどを抽出することができる。

パーサ３０４は、バッファ３０３から受信したビデオシーケンスに対してエントロピーデコード／解析動作を実行して、シンボル３１３を作成することができる。パーサ３０４は、エンコードされたデータを受信し、そして特定のシンボル３１３を選択的にデコードすることができる。更に、パーサ３０４は、特定のシンボル３１３が動き補償予測ユニット３０６、スケーラ／逆変換ユニット３０５、イントラ予測ユニット３０７、又はループフィルタ３１１に提供されるか否かを判定することができる。

シンボル３１３の再構成には、符号化ビデオピクチャ又はその一部（例えば、インターピクチャ及びイントラピクチャ、インターブロック及びイントラブロック）のタイプ、及び他の要因に応じて、複数の異なるユニットが関与する可能性がある。どのユニットが関与するか、及びどのように関与するかは、パーサ３０４によって符号化ビデオシーケンスから解析されたサブグループ制御情報によって制御することができる。パーサ３０４と以下の複数のユニットとの間のそのようなサブグループ制御情報の流れは、分かりやすくするために示されていない。

既に述べた機能ブロックのほか、デコーダ３００は、以下に説明されるように、概念的にいくつかの機能ユニットに再分割することができる。商業的制約の下で動作する実際の実装では、これらのユニットの多くは互いに密接に相互作用し、また少なくとも部分的に互いに統合することができる。しかしながら、開示された主題を説明する目的では、以下の機能ユニットへの概念的な再分割が適切である。

第１のユニットは、スケーラ／逆変換ユニット３０５である。スケーラ／逆変換ユニット３０５は、パーサ３０４から、量子化された変換係数、並びに使用する変換、ブロックサイズ、量子化係数、量子化スケーリング行列などを含む制御情報をシンボル３１３として受信する。 それは、アグリゲータ３１０に入力することができるサンプル値を含むブロックを出力することができる。

場合によっては、スケーラ／逆変換ユニット３０５の出力サンプルは、イントラ符号化ブロック、即ち、以前に再構成されたピクチャからの予測情報を使用しないが、現在ピクチャの以前に再構成された部分からの予測情報を使用できるブロックに関連する可能性がある。そのような予測情報は、イントラピクチャ予測ユニット３０７によって提供することができる。場合によっては、イントラピクチャ予測ユニット３０７は、現在の（部分的に再構成された）ピクチャ３０９からフェッチされた周囲の既に再構成された情報を用いて、再構成中のブロックと同じサイズ及び形状のブロックを生成する。アグリゲータ３１０は、場合によっては、サンプルごとに、イントラ予測ユニット３０７が生成した予測情報を、スケーラ／逆変換ユニット３０５によって提供された出力サンプル情報に追加する。

他の場合には、スケーラ／逆変換ユニット３０５の出力サンプルは、インター符号化され、潜在的に動き補償されたブロックに関連する可能性がある。そのような場合、動き補償予測ユニット３０６は、参照ピクチャメモリ３０８にアクセスして、予測に使用されるサンプルをフェッチすることができる。ブロックに関連するシンボル３１３に従ってフェッチされたサンプルを動き補償した後、アグリゲータ３１０によってこれらのサンプルをスケーラ／逆変換ユニットの出力に追加して（この場合、残差サンプル又は残差信号と呼ばれる）、出力サンプル情報を生成することができる。動き補償ユニットが予測サンプルをフェッチする参照ピクチャメモリ内のアドレスは、動きベクトルによって制御することができ、動きベクトルは、例えば、Ｘ、Ｙ、及び参照ピクチャ成分を有することができるシンボル３１３の形式で動き補償ユニットに利用可能である。動き補償はまた、サブサンプルの正確な動きベクトルが使用されているときに参照ピクチャメモリからフェッチされたサンプル値の補間、動きベクトル予測メカニズムなどを含むことができる。

アグリゲータ３１０の出力サンプルは、ループフィルタユニット３１１において様々なループフィルタリング技術を受けることができる。ビデオ圧縮技術は、インループフィルタ技術を含むことができ、これは、符号化ビデオビットストリームに含まれているパラメータによって制御され、パーサ３０４からのシンボル３１３としてループフィルタユニット３１１に利用可能にされるが、符号化ピクチャ又は符号化ビデオシーケンスの前の（デコード順の）部分のデコード中に得られたメタ情報に応答するだけでなく、以前に再構成及びループフィルタリングされたサンプル値に応答することもできる。

ループフィルタユニット３１１の出力は、レンダリングデバイス３１２に出力され得るだけでなく、将来のインターピクチャ予測に使用するために参照ピクチャメモリに記憶され得るサンプルストリームであり得る。

特定の符号化ピクチャは、完全に再構成されると、将来の予測のための参照ピクチャとして使用することができる。符号化ピクチャが完全に再構成され、また符号化ピクチャが参照ピクチャとして識別されると（例えば、パーサ３０４によって）、現在の参照ピクチャ３０９は参照ピクチャバッファ２０８の一部になることができ、そして次の符号化ピクチャの再構成を開始する前に、新しい現在ピクチャメモリを再割り当てすることができる。

ビデオデコーダ３００は、ＩＴＵ－Ｔ Ｒｅｃ．Ｈ．２６５などの規格に文書化され得る所定のビデオ圧縮技術に従ってデコード動作を実行することができる。符号化ビデオシーケンスは、ビデオ圧縮技術文書又は規格、特にその中のプロファイル文書で指定されているように、ビデオ圧縮技術又は規格の構文に準拠するという意味で、使用されているビデオ圧縮技術又は規格によって指定された構文に準拠することができる。また、準拠のために、符号化ビデオシーケンスの複雑さは、ビデオ圧縮技術又は規格のレベルによって定義された範囲内であることも必要である。場合によっては、レベルによって、最大ピクチャサイズ、最大フレームレート、最大再構成サンプルレート（例えば、１秒あたりのメガサンプルで測定）、最大参照ピクチャサイズなどが制限される。レベルによって設定される制限は、場合によっては、仮想参照デコーダ（ＨＲＤ）仕様及び符号化ビデオシーケンスで通知されるＨＲＤバッファ管理用のメタデータによって更に制限されることがある。

一実施形態では、受信機３０２は、エンコードされたビデオと共に追加の（冗長）データを受信することができる。追加のデータは、符号化ビデオシーケンスの一部として含まれてもよい。追加のデータは、データを適切にデコードするため、及び／又は元のビデオデータをより正確に再構成するために、ビデオデコーダ３００によって使用され得る。追加のデータは、例えば、時間的、空間的、又は信号対雑音比（ＳＮＲ）強化層、冗長スライス、冗長ピクチャ、前方誤り訂正コードなどの形式であり得る。

図４は、本開示の一実施形態によるビデオエンコーダ４００の機能ブロック図であり得る。

ビデオエンコーダ４００は、エンコーダ４００によって符号化されるべきビデオ画像をキャプチャすることができるビデオソース４０１（エンコーダの一部ではない）からビデオサンプルを受信することができる。

ビデオソース４０１は、任意の適切なビット深度（例えば、８ビット、１０ビット、１２ビット…）、任意の色空間（例えば、ＢＴ．６０１ Ｙ ＣｒＣＢ、ＲＧＢ…）、及び任意の適切なサンプリング構造（例えば、Ｙ ＣｒＣＢ ４：２：０、Ｙ ＣｒＣＢ ４：４：４）であり得るデジタルビデオサンプルストリームの形式で、エンコーダ（４００）によって符号化されるべきソースビデオシーケンスを提供することができる。メディアサービングシステムでは、ビデオソース４０１は、以前に準備されたビデオを記憶する記憶装置であってもよい。ビデオ会議システムでは、ビデオソース４０１は、ローカル画像情報をビデオシーケンスとしてキャプチャするカメラであってもよい。ビデオデータは、順番に見たときに動きを与える複数の個別のピクチャとして提供されてもよい。ピクチャ自体は、ピクセルの空間配列として編成することができ、各ピクセルは、使用中のサンプリング構造、色空間などに応じて、１つ又は複数のサンプルを含むことができる。当業者は、ピクセルとサンプルとの間の関係を容易に理解することができる。以下の説明では、サンプルに焦点を当てる。

一実施形態によれば、エンコーダ４００は、リアルタイムで、又はアプリケーションによって必要とされる他の任意の時間制約の下で、ソースビデオシーケンスのピクチャを符号化し、符号化ビデオシーケンス４１０に圧縮することができる。適切なコーディング速度を適用することは、コントローラ４０２の１つの機能である。コントローラは、以下に説明されるように他の機能ユニットを制御し、またこれらのユニットに機能的に結合される。分かりやすくするために、結合は示されていない。コントローラによって設定されるパラメータは、レート制御関連パラメータ（ピクチャスキップ、量子化器、レート歪み最適化技術のラムダ値…）、ピクチャサイズ、ピクチャグループ（ＧＯＰ）レイアウト、最大動きベクトル検索範囲などを含むことができる。当業者は、特定のシステム設計用に最適化されたビデオエンコーダ４００に関係する可能性があるため、コントローラ４０２の他の機能を容易に特定することができる。

一部のビデオエンコーダは、当業者が「コーディングループ」として容易に認識できるもので動作する。過度に単純化された説明として、コーディングループは、エンコーダ４０２（以降、「ソースコーダ」）のエンコーディング部分（符号化されるべき入力ピクチャ及び参照ピクチャに基づいてシンボルを作成する役割を果たす）と、シンボルを再構成してサンプルデータを作成するエンコーダ４００に埋め込まれた（ローカル）デコーダ４０６とから構成することができ、（シンボルと符号化ビデオビットストリームとの間の圧縮が、開示された主題で検討されているビデオ圧縮技術において可逆であるため）（リモート）デコーダもそのサンプルデータを作成する。その再構成されたサンプルストリームは、参照ピクチャメモリ４０５に入力される。シンボルストリームのデコードにより、デコーダの位置（ローカル又はリモート）に関係なくビットエグザクト結果が得られるため、参照ピクチャバッファのコンテンツも、ローカルエンコーダとリモートエンコーダとの間でビットエグザクトである。言い換えれば、エンコーダの予測部分は、デコード中に予測を使用するときにデコーダが「見る」のとまったく同じサンプル値を参照ピクチャサンプルとして「見る」。参照ピクチャの同期性（及び、例えばチャネルエラーのために同期性を維持できない場合、結果として生じるドリフト）のこの基本原理は、当業者に知られている。

「ローカル」デコーダ４０６の動作は、「リモート」デコーダ３００の動作と同じであってもよく、これは、図３に関連して上記で既に詳細に説明されている。しかし、図４も簡単に参照すると、シンボルが利用可能であり、エントロピーコーダ４０８及びパーサ３０４による符号化ビデオシーケンスへのシンボルのエンコード／デコードは可逆であり得るため、チャネル３０１、受信機３０２、バッファ３０３、及びパーサ３０４を含むデコーダ３００のエントロピーデコード部分は、ローカルデコーダ４０６に完全に実装されていない可能性がある。

この時点で行うことができる観察は、デコーダに存在する解析／エントロピーデコードを除くいかなるデコーダ技術も、対応するエンコーダ内に実質的に同一の機能形態で存在する必要があるということである。エンコーダ技術の説明は、それらが包括的に説明されているデコーダ技術の逆である可能性があるため、省略することができる。特定の領域でのみ、より詳細な説明が必要であり、以下に提供される。

その動作の一部として、ソースコーダ４０３は、動き補償予測コーディングを実行することができ、これは、「参照フレーム」として指定されたビデオシーケンスからの１つ又は複数の以前に符号化されたフレームを参照して入力フレームを予測的に符号化する。このようにして、コーディングエンジン４０７は、入力フレームのピクセルブロックと、入力フレームへの予測参照として選択され得る参照フレームのピクセルブロックとの間の差分を符号化する。

ローカルビデオデコーダ４０６は、ソースコーダ４０３によって作成されたシンボルに基づいて、参照フレームとして指定され得るフレームの符号化ビデオデータをデコードすることができる。コーディングエンジン４０７の動作は、有利には、非可逆プロセスであり得る。符号化ビデオデータがビデオデコーダ（図４には示されていない）でデコードされ得る場合、再構成されたビデオシーケンスは、通常、いくつかのエラーを伴うソースビデオシーケンスのレプリカであり得る。ローカルビデオデコーダ４０６は、参照フレームに対してビデオデコーダによって実行され得るデコードプロセスを複製し、再構成された参照フレームを参照ピクチャキャッシュ４０５に記憶させることができる。このようにして、エンコーダ４００は、遠端ビデオデコーダによって取得される再構成された参照フレームとして共通の内容を有する再構成された参照フレームのコピーをローカルに記憶することができる（送信エラーがない）。

予測器４０４は、コーディングエンジン４０７のために予測検索を実行することができる。即ち、符号化されるべき新しいフレームについて、予測器４０４は、参照ピクチャメモリ４０５を検索して、サンプルデータ（候補参照ピクセルブロックとして）又は参照ピクチャ動きベクトル、ブロック形状などの特定のメタデータを探すことができ、それらは、新しいピクチャに対する適切な予測参照として役立つことができる。予測器４０４は、適切な予測参照を見つけるために、ピクセルブロックごとにサンプルブロックで動作することができる。場合によっては、予測器４０４によって得られた検索結果によって決定されるように、入力ピクチャは、参照ピクチャメモリ４０５に記憶された複数の参照ピクチャから抽出された予測参照を有してもよい。

コントローラ４０２は、例えば、ビデオデータをエンコードするために使用されるパラメータ及びサブグループパラメータの設定を含めて、ビデオコーダ４０３のコーディング動作を管理することができる。

前述のすべての機能ユニットの出力は、エントロピーコーダ４０８においてエントロピーコーディングを受けてもよい。エントロピーコーダは、例えばハフマンコーディング、可変長コーディング、算術コーディングなどとして当業者に知られている技術に従ってシンボルを可逆的に圧縮することによって、様々な機能ユニットによって生成されたシンボルを符号化ビデオシーケンスに変換する。

送信機４０９は、エントロピーコーダ４０８によって作成された符号化ビデオシーケンスをバッファリングして、通信チャネル４１１を介した送信に備えることができ、通信チャネルは、エンコードされたビデオデータを記憶する記憶装置へのソフトウェア／ハードウェアリンクであり得る。送信機４０９は、ビデオコーダ４０３からの符号化ビデオデータを、送信されるべき他のデータ、例えば、符号化オーディオデータ及び／又は補助データストリーム（ソースは示されていない）とマージすることができる。

コントローラ４０２は、エンコーダ４００の動作を管理することができる。コーディング中に、コントローラ４０２は、各符号化ピクチャに特定の符号化ピクチャタイプを割り当てることができ、この符号化ピクチャタイプは、それぞれのピクチャに適用され得るコーディング技術に影響を与える可能性がある。例えば、ピクチャは、次のフレームタイプのいずれかとして割り当てられることが多い。

イントラピクチャ（Ｉピクチャ）は、予測のソースとしてシーケンス内の他のフレームを使用することなく符号化及びデコードされ得るものであり得る。一部のビデオコーデックでは、例えば、独立デコーダリフレッシュピクチャを含めて、様々なタイプのイントラピクチャが可能である。当業者は、Ｉピクチャのそれらの変形並びにそれらのそれぞれの用途及び特徴を知っている。

予測ピクチャ（Ｐピクチャ）は、各ブロックのサンプル値を予測するために最大で１つの動きベクトル及び参照インデックスを使用するイントラ予測又はインター予測を用いて符号化及びデコードされ得るものであり得る。

双方向予測ピクチャ（Ｂピクチャ）は、各ブロックのサンプル値を予測するために最大で２つの動きベクトル及び参照インデックスを使用するイントラ予測又はインター予測を用いて符号化及びデコードされ得るものであり得る。同様に、複数の予測ピクチャは、単一のブロックの再構成のために３つ以上の参照ピクチャ及び関連するメタデータを使用することができる。

ソースピクチャは、一般に、空間的に複数のサンプルブロック（例えば、それぞれ４ｘ４、８ｘ８、４ｘ８、又は１６ｘ１６サンプルのブロック）に再分割され、ブロックごとに符号化されてもよい。ブロックは、ブロックのそれぞれのピクチャに適用されるコーディング割り当てによって決定された他の（既に符号化された）ブロックを参照して予測的に符号化されてもよい。例えば、Ｉピクチャのブロックは、非予測的に符号化されてもよく、又はそれらは、同じピクチャの既に符号化されたブロックを参照して予測的に符号化されてもよい（空間予測又はイントラ予測）。Ｐピクチャのピクセルブロックは、以前に符号化された１つの参照ピクチャを参照して、空間予測を介して、又は時間予測を介して非予測的に符号化されてもよい。Ｂピクチャのブロックは、以前に符号化された１つ又は２つの参照ピクチャを参照して、空間予測を介して、又は時間予測を介して、非予測的に符号化されてもよい。

ビデオコーダ４００は、ＩＴＵ－Ｔ Ｒｅｃ．Ｈ．２６５などの所定のビデオコーディング技術又は規格に従ってコーディング動作を実行することができる。その動作において、ビデオコーダ４００は、入力ビデオシーケンスにおける時間的及び空間的冗長性を利用する予測コーディング動作を含めて、様々な圧縮動作を実行することができる。したがって、符号化ビデオデータは、使用されているビデオコーディング技術又は規格によって指定された構文に準拠することができる。

一実施形態では、送信機４０９は、エンコードされたビデオと共に追加のデータを送信することができる。ビデオコーダ４０３は、符号化ビデオシーケンスの一部としてそのようなデータを含むことができる。追加データは、時間／空間／ＳＮＲ強化層、冗長ピクチャ及びスライスなどの他の形式の冗長データ、補足強化情報（ＳＥＩ）メッセージ、ビジュアルユーザビリティ情報（ＶＵＩ）パラメータセットフラグメントなどを含むことができる。

図５は、本明細書の実施形態によるＭＰＥＧネットワークベースのメディア処理（ＮＢＭＰ）アーキテクチャ５００を示し、これは、クラウド処理に関して実装されてもよく、これにより、異なるネットワークエンティティ、ＭＰＥ、ソース、又はシンク間でワークフローを分割する品質を決定して利用することができ、したがって、以下に説明されるようにパブリッククラウドサービス、プライベートクラウドサービス又はハイブリッドクラウドサービスを活用することができる。ＮＢＭＰアーキテクチャ５００は、ＮＢＭＰワークフローＡＰＩ及びワークフロー記述５１１をＮＢＭＰワークフローマネージャ５１３に提供するＮＢＭＰソース５０１を含む。ＮＢＭＰワークフローマネージャ５１３は、関数発見ＡＰＩ及び関数記述５１２を関数リポジトリ５０３と通信することができ、関数リポジトリ５０３はまた、関数発見ＡＰＩ及び関数記述５０２をＮＢＭＰソース５０１と通信することができる。

更に、図５では、ＮＢＭＰワークフローマネージャは、ＮＢＭＰタスクＡＰＩ及び現在のタスクの状態と構成を報告するタスクなどを、ランタイム構成／ストリーム／イベントバインディングエンティティとして動作し得るメディア処理エンティティ（ＭＰＥ）５０５と通信することができる。例えば、メディアソース５０４は、１つ又は複数のメディアフロー５１４を、ＭＰＥ５０５の１つ又は複数のタスク５２１及び５２２に提供することができ、これらはまた、複数のメディアフロー５１４に対してそれぞれ並列化されてもよい。ＭＰＥ５０５は、１つ又は複数のメディアフロー５１５をメディアシンク５０６と通信することができる。

更に、図５において、ＮＢＭＰソース５０１、ＮＢＭＰワークフローマネージャ５１３、関数リポジトリ５０３及びＭＰＥ５０５の間の通信は、制御フローと見なされてもよく、メディアソース５０４、ＭＰＥ５０５、及びメディアシンク５０６の間の通信は、データフローと見なされてもよい。

例示的な実施形態によれば、ワークフロー記述５１１の入力及び出力は、入力及び出力記述子によって記述され、例示的な実施形態によれば、ワークフローの関数インスタンス間の相互接続は、処理記述子の接続マップ配列において定義されてもよく、それにより、対応するオブジェクトが以下の表１～表３に示される。

例示的な実施形態によれば、オブジェクトｆｒｏｍ及びｔｏは、表４に定義されている。

図６は、例示的な実施形態によるタスクライフサイクル状態図６００を示す。例えば、インスタンス化状態６０１に対してｏｎＩｎｓｔａｎｔｉａｔｉｏｎ信号６１１を受信することができる。インスタンス化状態６０１は、ｏｎＴａｓｋＣｏｎｆｉｇｕｒａｔｉｏｎ信号６１２によってアイドル状態６０２に移行することができ、アイドル状態６０２は、ｏｎＲｅｓｅｔ信号６１７によってインスタンス化状態６０１に戻ることができる。アイドル状態６０２は、ｏｎＴａｓｋＣｏｎｆｉｇｕｒａｔｉｏｎ信号６１３によってループすることもでき、またｏｎＳｔａｒｔ信号６１４によって実行状態６０３に移行することもできる。実行状態６０３は、ｏｎＴａｓｋＣｏｎｆｉｇｕｒａｔｉｏｎ信号６１５によってループすることができ、またｏｎＳｔｏｐ信号及び／又はｏｎＣｏｍｐｌｅｔｉｏｎ信号６１６によってアイドル状態６０２に移行することができる。実行状態６０３はまた、ｏｎＥｒｒｏｒ信号６２３によってエラー状態６０４に移行することができ、またエラー状態６０４は、それぞれｏｎＥｒｒｏｒＨａｎｄｌｉｎｇ信号６２４、ｏｎＲｅｓｅｔ信号６２５、及びｏｎＴｅｒｍｉｎａｔｉｏｎ信号６２６によってアイドル状態６０２、インスタンス化状態６０１、及び破壊状態６０５に移行することができる。更に、実行状態６０３、アイドル状態６０２、及びインスタンス化状態６０１はそれぞれ、ｏｎＴｅｒｍｉｎａｔｉｏｎ信号６２１、ｏｎＴｅｒｍｉｎａｔｉｏｎ信号６２２、及びｏｎＴｅｒｍｉｎａｔｉｏｎ信号６１１によって破壊状態６０５に移行することができる。

例示的な実施形態によれば、ｏｎＳｔｏｐ信号及びｏｎＣｏｍｐｌｅｔｉｏｎ信号を追加することもできる。例えば、ｏｎＳｔｏｐ信号は、メディアデータ又はメタデータがＭＰＥ５０５に到着するのを停止するとき、例えば、タスク５２１及び／又はタスク５２２が、その状態を実行状態６０３からアイドル状態６０２に移行させなければならないことを示すことができる。更に、例えば、ｏｎＣｏｍｐｌｅｔｉｏｎ信号は、ＭＰＥ５０５などで処理が完了すると、タスク５２１及び／又はタスク５２２が、その状態を実行状態６０３からアイドル状態６０２に移行させなければならないことを示すことができる。例示的な実施形態によれば、そのような特徴は、ＭＰＥ５０５に提供されるだけでなく、少なくともそれらの状態、実行状態６０３とアイドル状態６０２との間の移行もワークフローマネージャ５１３に提供されてもよい。

例示的な実施形態によれば、ＮＢＭＰ入力記述子及びパラメータは、以下の表５～表７に関して説明されるようなタイムアウトパラメータを用いて（例えば、入力記述子へのタイムアウトの例示的な追加によって）提供及び拡張することができる。

タイムアウトパラメータは、実施形態によれば、表７のように定義することができる。

図７は、入力ｉ１並びに複数の出力ｏ１、ｏ２、ｏ３、及びｏ４を有するワークフロー記述子７００の例示的な実施形態を示すが、そのような入力及び出力の数は、実施形態に応じて変更されてもよい。同様に、図８は、出力ｔ１、ｔ２、ｔ３、及びｔ４をそれぞれ有する複数のタスクＴ１、Ｔ２、Ｔ３、及び別のＴ３に分割された入力Ｉ１を有するタスクＴ０を有するタスク図８００の例示的な実施形態を示すが、そのような入力及び出力の数は、実施形態に応じて変更されてもよい。しかしながら、ワークフロー記述子７００及びタスク図８００を見ると、（ｏ１、ｏ２、ｏ３、ｏ４）と（ｔ１、ｔ２、ｔ３、ｔ４）との間の関連付けについての記述の欠如に関する技術的問題がある。したがって、実施形態は、以下の表８及び表９に提供される情報を参照し、それらに依拠することができる。

実施形態によれば、オブジェクトｆｒｏｍ及びｔｏは、表９に定義されており、表３に以前に提供された定義を置き換えることができる。

図９は、例示的な実施形態による簡略化されたフローチャート９００を示す。Ｓ９０１において、入力情報及び出力情報を受信する。

Ｓ９０２において、インスタンスを取得する。例えば、タスク及びワークフローのいずれか１つ又は複数の１つ又は複数の入力及び／又は出力を取得することができる。

Ｓ９０３において、マッピングする。図７及び図８に関して説明した例の中の関数インスタンス間の接続を定義することができるが、技術的問題として、ワークフローのどの入力が特定の関数インスタンスの入力に関連付けられているか、ワークフローのどの出力が特定の関数インスタンスの出力に関連付けられているかが明確でない場合がある。これは、接続マップが関数間の接続のみを定義し、関数インスタンスとワークフローの入力／出力との間の接続を定義していないという事実が原因である可能性がある。ワークフロー入力／出力がすべての最初又は最後の関数の中で異なる場合、ワークフローマネージャ５１３は、すべての入力／出力間の各入力／出力の一意性により、関連付けを見つけることができるが、ワークフローに同じ記述（ストリームｉｄのみが異なる）を有する複数の入力／出力が含まれている場合、ワークフローの入力／出力に対して適切な関数入力／出力を識別するには曖昧さがある。言い換えれば、ワークフロー入力と出力を特定の関数入力と出力に割り当てることには曖昧さがある。そのような場合の例が図７及び図８に示されており、これは、本明細書の技術的解決策により解決される。

例えば、Ｓ９０３において、実施形態は、接続マップにワークフロー入力／出力を含め、即ち、接続マップは、ワークフローのすべての入力及び出力を含むものとする。例えば、ｐｏｒｔ－ｎａｍｅを関数ｉｄとして使用し、ｓｔｒｅａｍ－ｉｄをインスタンスとして使用することができる。更に、例えば、以下のテキストなどを表８に含めることができる。
ｃｏｎｎｅｃｔｉｏｎ－ｍａｐオブジェクトの配列は、メディアワークフローＤＡＧ、即ち、グラフ内の異なるタスク間の接続情報を記述する。ＤＡＧのエッジを表すこの配列の各要素は、表８に定義されており、表３の定義を置き換えることができる。

更に、例示的な実施形態によれば、表８はまた、一般記述子のすべての入力ポートと出力ポートを、それぞれ「ｆｒｏｍ」と「ｔｏ」オブジェクトの形式で含む必要があり（入力ポートごとに１つの「ｆｒｏｍ」オブジェクト、出力ポートごとに１つの「ｔｏ」オブジェクト）、例えば、対応する各ワークフロー入力／出力の「ｉｄ」と「ｐｏｒｔ－ｎａｍｅ」は、一般記述子の対応する入力ポート／出力ポートの対応する「ｐｏｒｔ－ｎａｍｅ」と「ｓｔｒｅａｍ－ｉｄ」に設定する必要がある。そのような接続の場合、フロー制御パラメータ、併置フラグ、及び他のパラメータは無視されてもよく、そのような例示的な実施形態では、そこに含まれないことに留意されたい。

したがって、Ｓ９０３において、タスク及びワークフローのうちの少なくとも１つの入力が、関数の入力及び出力のうちの少なくとも１つに関連付けられるか否かを判定し、タスク及びワークフローのうちの少なくとも１つの入力が、関数の入力及び出力のうちの少なくとも１つに関連付けられると判定したことに応じて、タスク及びワークフローのうちの少なくとも１つの入力を、関数の入力及び出力のうちの少なくとも１つに関連付ける。これはまた、タスク及びワークフローのうちの少なくとも１つの、前記入力を含む複数の入力を取得することに関してであってもよく、それにより、タスク及びワークフローのうちの少なくとも１つの入力のそれぞれが、１つ又は複数の関数の入力及び出力のうちの少なくとも１つにそれぞれ関連付けられるか否かを判定し、タスク及びワークフローのうちの少なくとも１つの入力のそれぞれが、１つ又は複数の関数の入力及び出力のうちの少なくとも１つにそれぞれ関連付けられるか否かを判定したことに基づいて、タスク及びワークフローのうちの少なくとも１つの入力を、１つ又は複数の関数の入力及び出力のうちの少なくとも１つにそれぞれ関連付ける。例えば、例示的な実施形態によれば、そのような判定は、タスク及びワークフローのうちの少なくとも１つの入力のそれぞれが、１つ又は複数の関数の入力及び出力のうちの少なくとも１つにそれぞれ関連付けられるか否かを判定することを含み、これは、タスク及びワークフローのうちの少なくとも１つの入力のそれぞれに対する識別子及びポート名の少なくとも１つを判定し、そして対応する入力ポート及び出力ポートのうちの少なくとも１つの対応するポート名及びストリーム識別子の少なくとも１つを判定することを含む。

Ｓ９０４において、例えば、タスク及びワークフローのうちの少なくとも１つの入力のいずれかのタイムアウトを設定する。Ｓ９０４及びＳ９０３の特徴は、並列に又は順番に実装されてもよく、したがって、本明細書では、各ワークフロー入力及び出力を、関連する個々の関数の入力及び出力に関連付けるための方法が開示されており、ここで、ワークフローの各入力又は出力は、接続マップグラフを用いて、ワークフローの関数インスタンス／タスクの入力又は出力の１つに接続され、各入力及び出力は明確に識別することができ、これは、上記の技術的問題に対する技術的解決策を表す。

Ｓ９０５において、１つ又は複数のタスクなどの動作を実行する。しかしながら、追加の技術的問題として、タスク又はワークフローは、その入力内のデータが完了しているか否かを判定することができない可能性がある。したがって、「ｏｎＳｔｏｐ、メディアデータ又はメタデータの到着が停止すると、タスクはその状態を実行状態からアイドル状態に移行させなければならない」などのＮＢＭＰ仕様のステートメントは、タスク又はワークフローにデータが停止しているか否かを判定するためのルールがない可能性があるため、技術的に不十分である可能性がある。

したがって、例示的な実施形態によれば、タスク又はワークフローが入力の到着が停止したか否かを認識するなどの問題に対する技術的解決策があり、各入力に対して、「Ｔｉｍｅｏｕｔ：入力でデータが受信されない場合、入力データが完了したと見なされる時間間隔」及び「Ｃｏｍｐｌｅｔｅ：「ｔｒｕｅ」に設定されている場合、この入力にそれ以上のデータが到着せず、入力データが完了したと見なされることを意味する入力フラグ」という追加の２つのパラメータが定義され、したがって、タイムアウトパラメータは、Ｓ９０４において、ワークフローの入力に対してＮＢＭＰソースによって設定されるか、又はタスクの入力に対してワークフローマネージャによって設定されてもよい。次に、ワークフロー又はタスクは入力を監視し、タイムアウトの期間中にデータが到着しなくなるとすぐに、データが停止したと結論付けることができる。

Ｓ９０６において、１つ又は複数のフラグが受信されたか否かを考慮し、受信されなかった場合、処理は、そのような１つ又は複数のフラグをチェックし続けることができる。したがって、Ｓ９０６において、完了した入力において、入力用のフラグがあるか否かを考慮することができ、メディアソース又は接続タスクにデータがない場合、このフラグを「ｔｒｕｅ」に設定し、それにより、ワークフロー又はタスクはこの入力の追加データを受信しないことを認識する。したがって、上記の表６では、追加されたＮＢＭＰ入力記述子及びパラメータは、タイムアウトパラメータを用いて拡張されたため、技術的な利点がある。したがって、各メディア又はメタデータ入力に対して、各関数が入力パラメータを定義することができるように、入力用の完了フラグがあり得り、パラメータ「ｃｏｍｐｌｅｔｅ ｆｌａｇ」は、「ｔｒｕｅ」に設定されると、入力が完了しており、即ち、この入力に追加のデータが受信されないように定義されてもよい。Ｓ９０７において、アイドル状態が存在するか否かを考慮し、存在しない場合、処理は、そのような状態をチェックし続けることができる。Ｓ９０８において、状態を変更するか否かを考慮し、変更しない場合、処理は、その状態を変更するか否かを続けることができる。Ｓ９０９において、処理を終了するか否かを考慮し、終了しない場合、処理を継続することができる。Ｓ９１０において、そのような処理を終了し、次に、Ｓ９０１に進んで入力及び出力のいずれかが更に受信されるのを待つ。したがって、タスク及びワークフローのうちの少なくとも１つが、タイムアウトに等しい期間、入力のデータの欠如を監視したか否かを判定し、タスク及びワークフローのうちの少なくとも１つが、タイムアウトに等しい期間、入力のデータの欠如を監視したことに応じて、入力の更なるデータが利用できないと判定し、タスク及びワークフローのうちの少なくとも１つの状態が実行状態に設定されているか否かを判定し、状態が実行状態に設定されていると判定した場合、タスク及びワークフローのうちの少なくとも１つが、タイムアウトに等しい期間、入力のデータの欠如を監視したか否かに基づいて、状態を実行状態からアイドル状態に変更するか否かを判定する。また、入力が表示を含むか否かを判定し、入力が表示を含むと判定したことに応じて、入力の更なるデータが利用できないと判定する。そのような表示は、タスク及びワークフローのうちの少なくとも１つの入力と共に含まれている入力完了フラグを含んでもよく、又は、タスク及びワークフローのうちの少なくとも１つの入力と共に提供されたメタデータとして提供されてもよい。

更に、Ｓ９０６及びＳ９０７のいずれかで判定されたタイムアウトパラメータ及び完了フラグに基づいて、図６に示すような状態の変更によって、更に拡張することができ、例えば、Ｓ９０８において「ｏｎＳｔｏｐ、すべてのメディアデータ又はメタデータの到着が停止すると（すべての入力でタイムアウト値又は「ｔｒｕｅ」に設定された完了フラグ、あるいはこれら２つの任意の組み合わせを監視し、受信した入力の処理を完了することによって）、実行状態からアイドル状態に移行すべきである」など、及び「ｏｎＣｏｍｐｌｅｔｉｏｎ、処理が完了すると（すべての入力でタイムアウト値又は「ｔｒｕｅ」に設定された完了フラグ、あるいはこれら２つの任意の組み合わせを監視し、受信した入力の処理を完了することによって）、実行状態からアイドル状態に移行すべきである」などのいずれかが存在するか否かを考慮する。例示的な実施形態によれば、本明細書におけるそのようなステートメントは、タスク及びワークフローの両方を含めて、タスク及びワークフローのいずれかに適用することができる。したがって、Ｓ９０１において、タスク及びワークフローの少なくとも１つの、前記入力を含む複数の入力を取得することに関して、Ｓ９０６及びＳ９０７のいずれかに応答して、又はＳ９０８において独立して、例えば、Ｓ９０７でタスク及びワークフローのうちの少なくとも１つのすべての入力が、タイムアウトに等しい期間、すべての入力のデータの欠如を監視したか否かを追加的に判定することに関して、タスク及びワークフローのうちの少なくとも１つの状態が実行状態に設定されているか否かを判定することができ、そして、Ｓ９０８で状態が実行状態に設定されていると判定した場合、タスク及びワークフローのうちの少なくとも１つが、Ｓ９０６及びＳ９０７のいずれかの結果に基づくすべての入力のタイムアウトに等しい期間、入力のデータの欠如を監視したか否かに基づいて、状態を実行状態からアイドル状態に変更するか否かを判定することができる。例えば、タスク及びワークフローのうちの少なくとも１つが、タイムアウトに等しい期間、すべての入力のデータの欠如を監視したか否かを判定することは、タスク及びワークフローのうちの少なくとも１つの入力の少なくとも１つが、Ｓ９０７におけるタイムアウト表示及び／又はＳ９０６における完了表示のいずれかを示すか否かを判定することによって行うことができる。

したがって、タスク又はワークフローの各入力に対してタイムアウトを設定する方法により、タスク又はワークフローが、タイムアウトに等しい期間、その対応する入力でデータを監視しなかった場合、タスク又はワークフローは、その入力に利用可能なデータがそれ以上ないと結論づけることができ、メディア、メタデータ、又は他の任意の入力に対する入力の入力完了フラグを使用して、追加の入力データが利用可能でないことを通知する方法により、データ送信エンティティは、この入力にデータが送信されないことをタスク又はワークフローに通知することができ、それによりタスク又はワークフローは、これ以上のデータが到着しないと結論づけることができ、すべての入力のタイムアウト及びそのすべての入力のすべての完了フラグの監視に基づいて、タスク又はワークフローの状態を実行状態からアイドル状態に変更する方法により、すべてのタスク又はワークフローの入力がタイムアウト又は完了状態のいずれか場合、タスク又はワークフローはその状態を実行状態からアイドル状態に変更する必要があり、これらの方法を提供するこのような特徴には技術的な利点があり、そうでなければ、これらの方法は、本明細書の実施形態によって記載されるように有利に解決されるそのような技術的問題を考慮すると、少なくともＮＢＭＰ実装などでは、利用できなかったであろう。

したがって、上記のＳ９０６～Ｓ９０９に関する任意の更新に基づいて、Ｓ９０５において、入力の更なるデータが利用できないと判定したことに基づいて、ＮＢＭＰにおけるタスク及びワークフローのうちの少なくとも１つに更新を適用することができ、それにより、ＮＢＭＰにおけるタスク及びワークフローのうちの少なくとも１つの処理は更新に基づいて進む。

上記の技術は、コンピュータ可読命令を使用し、かつ１つ又は複数のコンピュータ可読媒体に物理的に記憶されたコンピュータソフトウェアとして実装することができる。例えば、図１０は、開示された主題の特定の実施形態を実施するのに適したコンピュータシステム１０００を示す。

コンピュータソフトウェアは、任意の適切な機械語又はコンピュータ言語を使用して符号化することができ、これらは、アセンブリ、コンパイル、リンク、又は同様のメカニズムを受けて、コンピュータ中央処理装置（ＣＰＵ）、グラフィック処理装置（ＧＰＵ）などによって直接、又は解釈、マイクロコード実行などを通じて実行できる命令を含むコードを作成することができる。

命令は、例えば、パーソナルコンピュータ、タブレットコンピュータ、サーバ、スマートフォン、ゲーム装置、モノのインターネット装置などを含めて、様々なタイプのコンピュータ又はその構成要素上で実行することができる。

コンピュータシステム１０００について図１０に示されている構成要素は、本質的に例示的なものであり、本開示の実施形態を実施するコンピュータソフトウェアの使用範囲又は機能に関するいかなる限定も示唆することを意図するものではない。また、構成要素の構成は、コンピュータシステム１０００の例示的な実施形態に示されている構成要素のいずれか１つ又は組み合わせに関連する依存性又は要件を有すると解釈されるべきではない。

コンピュータシステム１０００は、特定のヒューマンインターフェース入力デバイスを含むことができる。そのようなヒューマンインターフェース入力デバイスは、例えば、触覚入力（キーストローク、スワイプ、データグローブの動きなど）、音声入力（声、拍手など）、視覚入力（ジェスチャーなど）、嗅覚入力（図示せず）を介して、１人以上の人間ユーザによる入力に応答することができる。ヒューマンインターフェースデバイスはまた、オーディオ（音声、音楽、周囲音など）、画像（走査画像、静止画像カメラから取得した写真画像など）、ビデオ（２次元ビデオ、立体ビデオを含む３次元ビデオなど）など、必ずしも人間による意識的な入力に直接関連しない特定のメディアをキャプチャするために使用することができる。

入力ヒューマンインターフェースデバイスは、キーボード１００１、マウス１００２、トラックパッド１００３、タッチスクリーン１０１０、ジョイスティック１００５、マイクロフォン１００６、スキャナ１００８、及びカメラ１００７のうちの1つ以上を含むことができる（それぞれのうちの１つのみを示す）。

コンピュータシステム１０００はまた、特定のヒューマンインターフェース出力デバイスを含むことができる。そのようなヒューマンインターフェース出力デバイスは、例えば、触覚出力、音、光、及び匂い／味覚を通じて、１人以上の人間ユーザの感覚を刺激することができる。そのようなヒューマンインターフェース出力デバイスは、触覚出力デバイス（例えば、タッチスクリーン１０１０、又はジョイスティック１００５による触覚フィードバックであるが、入力デバイスとして機能しない触覚フィードバックデバイスもあり得る）、オーディオ出力デバイス（スピーカ１００９、ヘッドフォン（図示せず）など）、視覚出力デバイス（それぞれがタッチスクリーン入力機能を有する又は有せず、それぞれが触覚フィードバック機能を有する又は有せず、一部がステレオグラフィック出力などの手段を介して２次元視覚出力又は３次元以上の出力を出力することができる、ＣＲＴスクリーン、ＬＣＤスクリーン、プラズマスクリーン、ＯＬＥＤスクリーンを含むスクリーン１０１０、仮想現実メガネ（図示せず）、ホログラフィックディスプレイ及びスモークタンク（図示せず）など）、及びプリンタ（図示せず）を含むことができる。

コンピュータシステム１０００はまた、人間がアクセス可能な記憶装置、及びＣＤ／ＤＶＤ１０１１付きのＣＤ／ＤＶＤ ＲＯＭ／ＲＷ１０２０を含む光学媒体又は同様の媒体、サムドライブ１０２２、リムーバブルハードドライブ又はソリッドステートドライブ１０２３、テープ及びフロッピーディスクなどのレガシー磁気媒体（図示せず）、セキュリティドングルなどの特殊なＲＯＭ／ＡＳＩＣ／ＰＬＤベースのデバイス（図示せず）などの関連する媒体を含むことができる。

当業者はまた、現在開示されている主題に関連して使用される「コンピュータ可読媒体」という用語が、伝送媒体、搬送波、又は他の一時的な信号を包含しないことを理解すべきである。

コンピュータシステム１０００はまた、１つ又は複数の通信ネットワーク１０９８へのインターフェース１０９９を含むことができる。ネットワーク１０９８は、例えば、無線、有線、光であり得る。ネットワーク１０９８は更に、ローカル、広域、メトロポリタン、自動車及び産業用、リアルタイム、遅延耐性などであり得る。ネットワーク１０９８の例としては、イーサネットなどのローカルエリアネットワーク、無線ＬＡＮ、ＧＳＭ、３Ｇ、４Ｇ、５Ｇ、ＬＴＥなどを含むセルラーネットワーク、ケーブルＴＶ、衛星ＴＶ、地上波放送ＴＶを含むＴＶ有線又は無線広域デジタルネットワーク、ＣＡＮＢｕｓを含む自動車及び産業用ネットワークなどが挙げられる。特定のネットワーク１０９８では一般に、特定の汎用データポート又は周辺バス（１０５０及び１０５１）（例えば、コンピュータシステム１０００のＵＳＢポートなど）に接続された外部ネットワークインターフェースアダプタが必要であり、他のネットワークは、一般に、以下に説明されるように、システムバスに接続することによってコンピュータシステム１０００のコアに統合される（例えば、ＰＣコンピュータシステムへのイーサネットインターフェース又はスマートフォンコンピュータシステムへのセルラーネットワークインターフェース）。これらのネットワーク１０９８のいずれかを使用して、コンピュータシステム１０００は他のエンティティと通信することができる。そのような通信は、例えば、ローカル又は広域デジタルネットワークを使用する他のコンピュータシステムへの一方向、受信のみ（例えば、放送ＴＶ）、一方向送信のみ（例えば、特定のＣＡＮｂｕｓデバイスへのＣＡＮｂｕｓ）、又は双方向であり得る。上記のように、特定のプロトコル及びプロトコルスタックをこれらのネットワーク及びネットワークインターフェースのそれぞれで使用することができる。

前述のヒューマンインターフェースデバイス、人間がアクセス可能な記憶装置、及びネットワークインターフェースは、コンピュータシステム１０００のコア１０４０に接続することができる。

コア１０４０は、１つ又は複数の中央処理装置（ＣＰＵ）１０４１、グラフィック処理装置（ＧＰＵ）１０４２、グラフィックアダプタ１０１７、フィールドプログラマブルゲートエリア（ＦＰＧＡ）の形態の特殊なプログラマブルプロセッシングユニット１０４３、特定のタスク用のハードウェアアクセラレータ１０４４などを含むことができる。これらのデバイスは、読み取り専用メモリ（ＲＯＭ）１０４５、ランダムアクセスメモリ１０４６、ユーザがアクセスできない内部ハードドライブ、ＳＳＤなどの内部大容量記憶装置１０４７と共に、システムバス１０４８を介して接続されてもよい。一部のコンピュータシステムでは、システムバス１０４８は、追加のＣＰＵ、ＧＰＵなどによる拡張を可能にするために、１つ又は複数の物理プラグの形態でアクセス可能である。周辺機器は、コアのシステムバス１０４８に直接接続することも、周辺バス１０５１を介して接続することもできる。周辺バスのアーキテクチャには、ＰＣＩ、ＵＳＢなどが含まれる。

ＣＰＵ１０４１、ＧＰＵ１０４２、ＦＰＧＡ１０４３、及びアクセラレータ１０４４は、特定の命令を実行することができ、これらの命令は、組み合わせて前述のコンピュータコードを構成することができる。そのコンピュータコードは、ＲＯＭ１０４５又はＲＡＭ１０４６に記憶することができる。移行データはＲＡＭ１０４６に記憶することもできるが、永久データは、例えば内部大容量記憶装置１０４７に記憶することができる。１つ又は複数のＣＰＵ１０４１、ＧＰＵ１０４２、大容量記憶装置１０４７、ＲＯＭ１０４５、ＲＡＭ１０４６などと密接に関連付けることができるキャッシュメモリを使用することで、任意のメモリデバイスへの高速記憶及び検索を可能にすることができる。

コンピュータ可読媒体は、様々なコンピュータ実装動作を実行するためのコンピュータコードを有することができる。媒体及びコンピュータコードは、本開示の目的のために特別に設計及び構築されたものであってもよく、又はそれらは、コンピュータソフトウェア技術の当業者によく知られ、利用可能な種類のものであってもよい。

限定ではなく、一例として、アーキテクチャ１０００、具体的にはコア１０４０を有するコンピュータシステムは、プロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡ、アクセラレータなどを含む）が１つ又は複数の有形のコンピュータ可読媒体に具体化されたソフトウェアを実行する結果として機能を提供することができる。そのようなコンピュータ可読媒体は、上記で紹介したユーザがアクセス可能な大容量記憶装置に関連付けられた媒体、及びコア内部大容量記憶装置１０４７又はＲＯＭ１０４５などの非一時的な性質を有するコア１０４０の特定の記憶装置であり得る。本開示の様々な実施形態を実施するソフトウェアは、そのようなデバイスに記憶され、コア１０４０によって実行され得る。コンピュータ可読媒体は、特定の必要に応じて、１つ又は複数のメモリデバイス又はチップを含むことができる。ソフトウェアは、コア１０４０、特にその中のプロセッサ（ＣＰＵ、ＧＰＵ、ＦＰＧＡなどを含む）に、ＲＡＭ１０４６に記憶されたデータ構造を定義すること、及びソフトウェアによって定義されたプロセスに従ってそのようなデータ構造を修正することを含めて、本明細書に記載の特定のプロセス又は特定のプロセスの特定の部分を実行させることができる。更に又は代替として、コンピュータシステムは、ソフトウェアの代わりに又はソフトウェアと共に動作して本明細書に記載の特定のプロセス又は特定のプロセスの特定の部分を実行することができる回路（例えば、アクセラレータ１０４４）に配線され、又は他の方法で具体化された論理の結果として機能を提供することができる。ソフトウェアへの言及は、論理を包含することができ、必要に応じてその逆も同様である。コンピュータ可読媒体への言及は、実行用のソフトウェアを記憶する回路（集積回路（ＩＣ）など）、実行用の論理を具体化する回路、又は必要に応じてその両方を包含することができる。本開示は、ハードウェア及びソフトウェアの任意の適切な組み合わせを包含する。

本開示は、いくつかの例示的な実施形態を説明してきたが、本開示の範囲内にある変更、変形、及び様々な置換同等物が存在する。したがって、当業者は、本明細書に明示的に示されていないか又は記載されていないが、本開示の原理を具体化し、したがってその精神及び範囲内にある多数のシステム及び方法を考案することができることが理解されるであろう。

１００ 通信システム
１０１、１０２、１０３、１０４ 端末
１０５ ネットワーク

Claims (9)

1. コンピュータが実行する、ネットワークベースのメディア処理（ＮＢＭＰ）の方法であって、
   ＮＢＭＰにおけるタスク及びワークフローのうちの少なくとも１つの入力を取得するステップと、
   前記タスク及び前記ワークフローのうちの前記少なくとも１つの前記入力のタイムアウトを設定するステップと、
   前記タスク及び前記ワークフローのうちの前記少なくとも１つが、前記タイムアウトに等しい期間、前記入力のデータの欠如を監視したか否かを判定するステップと、
   前記タスク及び前記ワークフローのうちの前記少なくとも１つが、前記タイムアウトに等しい前記期間、前記入力のデータの欠如を監視したことに応じて、前記入力の更なるデータが利用できないと判定するステップと、
   前記タスク及び前記ワークフローのうちの前記少なくとも１つの、前記入力を含む複数の入力のそれぞれに対する識別子及びポート名の少なくとも１つを判定し、そして対応する入力ポート及び出力ポートのうちの少なくとも１つの対応するポート名及びストリーム識別子の少なくとも１つを判定することによって、前記タスク及び前記ワークフローのうちの前記少なくとも１つの前記複数の入力のそれぞれが、１つ又は複数の関数の入力及び出力のうちの少なくとも１つにそれぞれ関連付けられるか否かを判定するステップと、
   前記タスク及び前記ワークフローのうちの前記少なくとも１つの前記複数の入力のそれぞれが、１つ又は複数の関数の入力及び出力のうちの少なくとも１つにそれぞれ関連付けられるか否かを判定したことに基づいて、前記タスク及び前記ワークフローのうちの前記少なくとも１つの前記複数の入力を、前記１つ又は複数の関数の前記入力及び前記出力のうちの前記少なくとも１つにそれぞれ関連付けるステップと、
   前記入力の更なるデータが利用できないと判定したことに基づいて、ＮＢＭＰにおける前記タスク及び前記ワークフローのうちの前記少なくとも１つに更新を適用するステップと、
   前記更新に基づいて、ＮＢＭＰにおける前記タスク及び前記ワークフローのうちの前記少なくとも１つを処理するステップと、を含む方法。
2. 前記タスク及び前記ワークフローのうちの前記少なくとも１つが実行状態に設定されているか否かを判定するステップと、
   前記タスク及び前記ワークフローのうちの前記少なくとも１つが前記実行状態に設定されていると判定した場合、前記タスク及び前記ワークフローのうちの前記少なくとも１つが、前記タイムアウトに等しい期間、前記入力のデータの欠如を監視したか否かに基づいて、前記タスク及び前記ワークフローのうちの前記少なくとも１つについて、前記実行状態からアイドル状態に設定の変更をするか否かを判定するステップと、を更に含む、請求項１に記載の方法。
3. 前記入力が特定の表示を含むか否かを判定するステップと、
   前記入力が前記特定の表示を含むと判定したことに応じて、前記入力の更なるデータが利用できないと判定するステップと、を更に含む、請求項１に記載の方法。
4. 前記特定の表示は、前記タスク及び前記ワークフローのうちの前記少なくとも１つの前記入力と共に含まれている入力完了フラグを含む、請求項３に記載の方法。
5. 前記特定の表示は、前記タスク及び前記ワークフローのうちの前記少なくとも１つの前記入力と共に提供されたメタデータに含まれている、請求項３に記載の方法。
6. 前記タスク及び前記ワークフローのうちの前記少なくとも１つの、前記入力を含む前記複数の入力を取得するステップと、
   前記タスク及び前記ワークフローのうちの前記少なくとも１つが実行状態に設定されているか否かを判定するステップと、
   前記タスク及び前記ワークフローのうちの前記少なくとも１つのすべての前記入力が、前記タイムアウトに等しい前記期間、すべての前記入力のデータの欠如を監視したか否かを判定するステップと、
   前記タスク及び前記ワークフローのうちの前記少なくとも１つが前記実行状態に設定されていると判定した場合、前記タスク及び前記ワークフローのうちの前記少なくとも１つが、すべての前記入力の前記タイムアウトに等しい期間、前記入力のデータの欠如を監視したか否かに基づいて、前記タスク及び前記ワークフローのうちの前記少なくとも１つについて、前記実行状態からアイドル状態に設定の変更をするか否かを判定するステップと、を更に含む、請求項３に記載の方法。
7. 前記タスク及び前記ワークフローのうちの前記少なくとも１つのすべての前記入力が、前記タイムアウトに等しい前記期間、すべての前記入力のデータの欠如を監視したか否かを判定するステップは、前記タスク及び前記ワークフローのうちの前記少なくとも１つの前記入力の少なくとも１つが、タイムアウト表示及び完了表示のいずれかを示すか否かを判定することを含む、請求項６に記載の方法。
8. 請求項１～７のいずれか１項に記載の方法を実行する、装置。
9. コンピュータにネットワークベースのメディア処理（ＮＢＭＰ）のプロセスを実行させるコンピュータプログラムであって、前記プロセスは、
   ＮＢＭＰにおけるタスク及びワークフローのうちの少なくとも１つの入力を取得するステップと、
   前記タスク及び前記ワークフローのうちの前記少なくとも１つの前記入力のタイムアウトを設定するステップと、
   前記タスク及び前記ワークフローのうちの前記少なくとも１つが、前記タイムアウトに等しい期間、前記入力のデータの欠如を監視したか否かを判定するステップと、
   前記タスク及び前記ワークフローのうちの前記少なくとも１つが、前記タイムアウトに等しい前記期間、前記入力のデータの欠如を監視したことに応じて、前記入力の更なるデータが利用できないと判定するステップと、
   前記タスク及び前記ワークフローのうちの前記少なくとも１つの、前記入力を含む複数の入力のそれぞれに対する識別子及びポート名の少なくとも１つを判定し、そして対応する入力ポート及び出力ポートのうちの少なくとも１つの対応するポート名及びストリーム識別子の少なくとも１つを判定することによって、前記タスク及び前記ワークフローのうちの前記少なくとも１つの前記複数の入力のそれぞれが、１つ又は複数の関数の入力及び出力のうちの少なくとも１つにそれぞれ関連付けられるか否かを判定するステップと、
   前記タスク及び前記ワークフローのうちの前記少なくとも１つの前記複数の入力のそれぞれが、１つ又は複数の関数の入力及び出力のうちの少なくとも１つにそれぞれ関連付けられるか否かを判定したことに基づいて、前記タスク及び前記ワークフローのうちの前記少なくとも１つの前記複数の入力を、前記１つ又は複数の関数の前記入力及び前記出力のうちの前記少なくとも１つにそれぞれ関連付けるステップと、
   前記入力の更なるデータが利用できないと判定したことに基づいて、ＮＢＭＰにおける前記タスク及び前記ワークフローのうちの前記少なくとも１つに更新を適用するステップと、
   前記更新に基づいて、ＮＢＭＰにおける前記タスク及び前記ワークフローのうちの前記少なくとも１つを処理するステップとを含む、コンピュータプログラム。

Images