知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-03-27
(45)【発行日】2023-04-04
(54)【発明の名称】データ・ストリーム変更を制御するシステムおよび方法
(51)【国際特許分類】
H04N 21/234 20110101AFI20230328BHJP
H04N 21/854 20110101ALI20230328BHJP
【ＦＩ】
H04N21/234
H04N21/854
【請求項の数】
23
(21)【出願番号】P 2019506161
(86)(22)【出願日】2017-08-03
(65)【公表番号】
(43)【公表日】2019-08-22
(86)【国際出願番号】 CA2017050930
(87)【国際公開番号】W WO2018023199
(87)【国際公開日】2018-02-08
【審査請求日】2020-07-30
(31)【優先権主張番号】62/370,489
(32)【優先日】2016-08-03
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】517351983
【氏名又は名称】デジェロ ラブス インコーポレイテッド
(74)【代理人】
【識別番号】100114775
【弁理士】
【氏名又は名称】高岡 亮一
(74)【代理人】
【識別番号】100121511
【弁理士】
【氏名又は名称】小田 直
(74)【代理人】
【識別番号】100202751
【弁理士】
【氏名又は名称】岩堀 明代
(74)【代理人】
【識別番号】100191086
【弁理士】
【氏名又は名称】高橋 香元
(72)【発明者】
【氏名】セー，デイビッド
(72)【発明者】
【氏名】オーバホルツァー，ジョナサン
(72)【発明者】
【氏名】シュナイダー，トッド
(72)【発明者】
【氏名】フルシナ，ボグダン
【審査官】長谷川 素直
(56)【参考文献】
【文献】特開２００８－１１８２７１（ＪＰ，Ａ）
【文献】特開２００２－２６１７１０（ＪＰ，Ａ）
【文献】特開２００８－２２８３１３（ＪＰ，Ａ）
【文献】特開２００８－２１９４８９（ＪＰ，Ａ）
【文献】特開２０１０－２１３１１９（ＪＰ，Ａ）
【文献】特開２０１４－２３６４６５（ＪＰ，Ａ）
【文献】米国特許出願公開第２００９／０１４４７８５（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｎ ２１／００－２１／８５８
(57)【特許請求の範囲】
【請求項1】
データ・ストリーム変更を制御するためのシステムであって、前記システムは、プレビュー・データ・ストリームを受信する制御デバイスであって、前記制御デバイスは、前記プレビュー・データ・ストリームに基づいて、前処理されたデータ・ストリームを変更する処理命令の１つ以上のセットを生成するように構成される、制御デバイスと、
前記前処理されたデータ・ストリームを受信し、少なくとも、前記前処理されたデータ・ストリームの処理において前記処理命令の１つ以上のセットを実行することに基づいて、１つ以上のデータ変更を適用するように構成されたデータ・ストリーム処理デバイスであって、前記データ・ストリーム処理デバイスは、前記データ変更を含む出力の処理されたストリームを生成する、データ・ストリーム処理デバイスと、
を含み、
前記プレビュー・データ・ストリームおよび前記前処理されたデータ・ストリームは、両方ともソース・ビデオ・データ・ストリームから導出され、
前記プレビュー・データ・ストリームの対応するフレームおよび前記前処理されたデータ・ストリームの対応するフレームの受信は、前記プレビュー・データ・ストリームと前記前処理されたデータ・ストリームとの間の、データ・ストリームの生成中の符号化パラメータにおける１つ以上の差に少なくとも部分的に起因してお互いに対して相対的に時間的にシフトされ、
前記制御デバイスによる、前記プレビュー・データ・ストリームの対応するフレームの受信は、前記データ・ストリーム処理デバイスによる、前記前処理されたデータ・ストリームの対応するフレームの受信の前に発生する、システム。
【請求項2】
前記前処理されたデータ・ストリームは、ソース・ビデオ・データ・ストリームから生成された作品品質データ・ストリームである、請求項１に記載のシステム。
【請求項3】
前記プレビュー・データ・ストリームおよび前記前処理されたデータ・ストリームを別々のデータ・ストリームとして受信するように構成された少なくとも１つの受信器を含む、請求項１に記載のシステム。
【請求項4】
前記システムは、前記ソース・ビデオ・データ・ストリームを受信するように構成された少なくとも１つの受信器と、
前記ソース・ビデオ・データ・ストリームから前記プレビュー・データ・ストリームを生成するように構成された第１の符号器と、
前記ソース・ビデオ・データ・ストリームから前記前処理されたデータ・ストリームを生成するように構成された第２の符号器と、
を含み、
前記プレビュー・データ・ストリームは、前記前処理されたデータ・ストリームより低いビットレートで生成される、請求項１に記載のシステム。
【請求項5】
前記第２の符号器は、前記プレビュー・データ・ストリームの対応するフレームに対する相対的な、前記前処理されたデータ・ストリームの対応するフレームの受信の時間シフトを引き起こすために、前記データ・ストリーム処理デバイスへの前記前処理されたデータ・ストリームの送信を遅延させる機構を含む、請求項４に記載のシステム。
【請求項6】
前記第１の符号器および前記第２の符号器のうちの少なくとも１つの動作特性は、前記プレビュー・データ・ストリームの対応するフレームの受信と前記前処理された・データ・ストリームの対応するフレームとの間の時間遅延を変更するために制御可能である、請求項４に記載のシステム。
【請求項7】
前記制御デバイスおよび前記データ・ストリーム処理デバイスは、マスタ－スレーブ構成で動作するように構成され、これによって、前記処理命令の１つ以上のセットは、前記データ・ストリーム処理デバイスによる実行のための単一方向処理ステップを表し、前記プレビュー・データ・ストリームと前記前処理されたデータ・ストリームとの間の、データ・ストリームの生成中の符号化パラメータにおける差は、前記プレビュー・データ・ストリームの対応するフレームの受信と前記前処理されたデータ・ストリームの対応するフレームとの間の最小時間遅延をもたらし、
前記制御デバイスは、データ変更を識別し、前記識別されたデータ変更を表す処理命令の１つ以上のセットを生成するように構成され、前記処理命令の１つ以上のセットは、前記データ・ストリーム処理デバイスによって実行される時に、前記前処理されたデータ・ストリームを前記出力の処理されたストリームに変換する、請求項１に記載のシステム。
【請求項8】
前記制御デバイスは、少なくとも前記プレビュー・データ・ストリームの対応するフレームの受信と前記前処理されたデータ・ストリームの対応するフレームとの間の時間シフトによって定義される時間的制約以内に前記処理命令の１つ以上のセットを生成するように構成される、請求項７に記載のシステム。
【請求項9】
前記前処理されたデータ・ストリームを変更する処理命令の１つ以上のセットの各セットは、少なくとも、変更に関して選択された、前記前処理されたデータ・ストリームのフレームのフレーム識別子と、前記前処理されたデータ・ストリームの選択されたフレームに関連する画像操作命令またはオーディオ操作命令とを有するデータ構造を含む、請求項８に記載のシステム。
【請求項10】
前記データ変更を含む前記出力の処理されたストリームの生成が前記時間的制約以内に発生するように、前記前処理されたデータ・ストリームの処理を調整するように構成された処理オーケストレーション・コントローラを含む、請求項８に記載のシステム。
【請求項11】
前記処理オーケストレーション・コントローラは、実施のためまたは前記制御デバイスおよび前記データ・ストリーム処理デバイスのうちの少なくとも１つによる使用のために、複数のクラウド・コンピューティング・リソースから前記複数のクラウド・コンピューティング・リソースのサブセットを選択するように構成される、請求項１０に記載のシステム。
【請求項12】
前記処理オーケストレーション・コントローラは、前記複数のクラウド・コンピューティング・リソースのうちのクラウド・コンピューティング・リソースの間の１つ以上のネットワーキング接続を制御するようにさらに構成され、前記処理オーケストレーション・コントローラは、処理命令の１つ以上のセットを生成するのに必要な総時間を変更するために前記１つ以上のネットワーキング接続を制御し、前記総時間は、前記時間的制約の中に含まれる、請求項１１に記載のシステム。
【請求項13】
前記複数のクラウド・コンピューティング・リソースの各クラウド・コンピューティング・リソースは、対応する地理空間的特性に関連付けられ、前記処理オーケストレーション・コントローラは、各クラウド・コンピューティング・リソースの地理空間的特性に少なくとも部分的に基づいて前記複数のクラウド・コンピューティング・リソースのサブセットを選択する、請求項１２に記載のシステム。
【請求項14】
前記処理オーケストレーション・コントローラは、処理のために要求される時に特定のクラウド・コンピューティング・リソースを割り振るように構成され、前記処理が完了する時に前記割り振られたクラウド・コンピューティング・リソースを解放するように構成される、請求項１３に記載のシステム。
【請求項15】
前記処理オーケストレーション・コントローラは、オフピーク使用を有する時間帯領域から選択されるクラウド・コンピューティング・リソースの回転するセットを割り振り、その後に解放するように構成される、請求項１４に記載のシステム。
【請求項16】
各クラウド・コンピューティング・リソースの地理空間的特性は、地理的位置、時間帯、および対応するクラウド・コンピューティング・リソースとの間の通信に関するネットワーキング待ち時間のうちの少なくとも１つを含む、請求項１３に記載のシステム。
【請求項17】
前記処理オーケストレーション・コントローラは、処理が条件の現在のセットを考慮して前記時間的制約を超える可能性が高いとの判定の際に、高優先順位のネットワーキング・リソースを要求するように構成される、請求項１６に記載のシステム。
【請求項18】
前記処理オーケストレーション・コントローラは、前記プレビュー・データ・ストリームと前記前処理されたデータ・ストリームとの間の時間シフトの持続時間を制御するように構成される、請求項１０に記載のシステム。
【請求項19】
前記処理命令の１つ以上のセットの生成は、クラウド・コンピューティング・リソースのチェーンのクラウド・コンピューティング・リソースのサブセットによって形成されるクラウド・コンピューティング・リソースのチェーンにまたがって行われ、期待されるエンド・ツー・エンド待ち時間は、ソース送信器からのネットワーク待ち時間と、前記クラウド・コンピューティング・リソースのそれぞれで要求される処理時間と、前記クラウド・コンピューティング・リソースのそれぞれの間の１つ以上のネットワーク待ち時間と、前記データ・ストリーム処理デバイスへのネットワーク待ち時間とを集計することによって周期的に判定され、前記期待されるエンド・ツー・エンド待ち時間が、前記時間的制約より長いとの判定の際に、前記処理オーケストレーション・コントローラは、前記期待されるエンド・ツー・エンド待ち時間が前記時間的制約の中に含まれるように、前記期待されるエンド・ツー・エンド待ち時間を短縮する補償アクションを開始するように構成される、請求項１０に記載のシステム。
【請求項20】
データ・ストリーム変更を制御するための方法であって、前記方法は、制御デバイスでプレビュー・データ・ストリームを受信することと、
前記プレビュー・データ・ストリームに基づいて、前処理されたデータ・ストリームを変更する処理命令の１つ以上のセットを生成することと、
データ・ストリーム処理デバイスで前記前処理されたデータ・ストリームを受信することと、
少なくとも、前記前処理されたデータ・ストリームの処理において前記処理命令の１つ以上のセットを実行することに基づいて、１つ以上のデータ変更を適用することと、
前記データ変更を含む出力の処理されたストリームを生成することと、
を含み、
前記プレビュー・データ・ストリームおよび前記前処理されたデータ・ストリームは、両方ともソース・ビデオ・データ・ストリームから導出され、
前記プレビュー・データ・ストリームの対応するフレームおよび前記前処理されたデータ・ストリームの対応するフレームの受信は、前記プレビュー・データ・ストリームと前記前処理されたデータ・ストリームとの間の、データ・ストリームの生成中の符号化パラメータにおける１つ以上の差に少なくとも部分的に起因してお互いに対して相対的に時間的にシフトされ、
前記制御デバイスによる、前記プレビュー・データ・ストリームの対応するフレームの受信は、前記データ・ストリーム処理デバイスによる、前記前処理されたデータ・ストリームの対応するフレームの受信の前に発生する、方法。
【請求項21】
機械可読命令を記憶するコンピュータ可読媒体であって、前記機械可読命令は、プロセッサによって実行される時に、前記プロセッサに、ストリーム・データ変更を制御する方法を実行させ、前記方法は、制御デバイスでプレビュー・データ・ストリームを受信することと、
前記プレビュー・データ・ストリームに基づいて、前処理されたデータ・ストリームを変更する処理命令の１つ以上のセットを生成することと、
データ・ストリーム処理デバイスで前記前処理されたデータ・ストリームを受信することと、
少なくとも、前記前処理されたデータ・ストリームの処理において前記処理命令の１つ以上のセットを実行することに基づいて、１つ以上のデータ変更を適用することと、
前記データ変更を含む出力の処理されたストリームを生成することと、
を含み、
前記プレビュー・データ・ストリームおよび前記前処理されたデータ・ストリームは、両方ともソース・ビデオ・データ・ストリームから導出され、
前記プレビュー・データ・ストリームの対応するフレームおよび前記前処理されたデータ・ストリームの対応するフレームの受信は、前記プレビュー・データ・ストリームと前記前処理されたデータ・ストリームとの間の、データ・ストリームの生成中の符号化パラメータにおける１つ以上の差に少なくとも部分的に起因してお互いに対して相対的に時間的にシフトされ、
前記制御デバイスによる、前記プレビュー・データ・ストリームの対応するフレームの受信は、前記データ・ストリーム処理デバイスによる、前記前処理されたデータ・ストリームの対応するフレームの受信の前に発生する、コンピュータ可読媒体。
【請求項22】
データ変更を含む出力の処理されたストリームの生成が時間的制約以内に発生するように、前処理されたデータ・ストリームの処理を調整するための処理オーケストレーション・コントローラであって、前記処理オーケストレーション・コントローラは、複数のクラウド・コンピューティング・リソースの１つ以上の処理特性と複数のネットワーク接続の１つ以上のネットワーク特性とを記憶するデータ構造を維持するように構成されたデータ・ストレージと、
ネットワーク・インターフェースの第１のセットであって、
前記前処理されたストリームを変更する処理命令の１つ以上のセットをプレビュー・データ・ストリームに基づいて生成するように構成された制御デバイスに供給されるプレビュー・データ・ストリームを生成し、
前記前処理されたデータ・ストリームを生成する
ように構成された送信器にプロセッサを結合する、ネットワーク・インターフェースの第１のセットと、
複数のクラウド・コンピューティング・リソースの各クラウド・コンピューティング・リソースに前記プロセッサを結合する、ネットワーク・インターフェースの第２のセットと、
プロセッサであって、
識別されたデータ変更を表す処理命令の１つ以上のセットを生成するために前記複数のクラウド・コンピューティング・リソースのサブセットを選択し、
前記処理命令の１つ以上のセットの生成が、少なくとも前記プレビュー・データ・ストリームの対応するフレームの受信と前記前処理されたデータ・ストリームの対応するフレームとの間の時間シフトによって定義される時間的制約以内に発生するように、クラウド・コンピューティング・リソースのサブセットによる、前記前処理されたデータ・ストリームの処理を調整する制御信号を送信し、
期待されるエンド・ツー・エンド待ち時間を判定するために、前記１つ以上の処理特性および前記１つ以上のネットワーク特性を継続的に監視し、
前記期待されるエンド・ツー・エンド待ち時間が前記時間的制約より長いとの判定に応答して、前記期待されるエンド・ツー・エンド待ち時間が前記時間的制約の中に含まれるように、前記期待されるエンド・ツー・エンド待ち時間を短縮する補償アクションを開始する
ように構成された、プロセッサと、
を含み、
前記プレビュー・データ・ストリームおよび前記前処理されたデータ・ストリームは、両方ともソース・ビデオ・データ・ストリームから導出され、
前記プレビュー・データ・ストリームの対応するフレームおよび前記前処理されたデータ・ストリームの対応するフレームの、前記送信器による生成は、前記プレビュー・データ・ストリームと前記前処理されたデータ・ストリームとの間の、データ・ストリームの生成中の符号化パラメータにおける１つ以上の差に少なくとも部分的に起因してお互いに対して相対的に時間的にシフトされる、処理オーケストレーション・コントローラ。
【請求項23】
プレビュー・データ・ストリームを受信するための、かつ、出力データ・ストリームを生成するために前処理されたデータ・ストリームを変更する処理命令の１つ以上のセットを前記プレビュー・データ・ストリームに基づいて生成するための制御デバイスであって、前記制御デバイスは、識別されたデータ変更のセットを表す処理命令の１つ以上のセットを生成する、複数のクラウド・コンピューティング・リソースから選択されたクラウド・コンピューティング・リソースのサブセットと、
前記処理命令の１つ以上のセットの生成が、少なくとも前記プレビュー・データ・ストリームの対応するフレームの生成と前処理されたデータ・ストリームの対応するフレームとの間の時間シフトによって定義される時間的制約以内に発生するように、前記クラウド・コンピューティング・リソースのサブセットによる処理命令の１つ以上の生成を調整する調整コントローラと、
を含む、制御デバイス。
【発明の詳細な説明】
【技術分野】
【0001】
本明細書で説明する実施形態は、全般的にはデータ通信に関し、より具体的には、オーディオ・データおよび／またはビデオ・データのストリームを含むがこれに限定されないデータ通信に対するデータ変更を制御するシステム、方法、およびコンピュータ・プログラム製品に関する。
【背景技術】
【0002】
オーディオ・データおよびビデオ・データの複数のストリームの処理は、テレビ局調整室などであるがこれに限定されない環境での共通の要件である。現場からのライブ・フィードなどのオリジナル・ビデオ・ソースが、調整室に入って、グラフィックスおよび効果を追加され、広告を含む他のフィードとミキシングされ、最終的に、無線で視聴者に送り出される。処理は、計算集中的になる可能性があり、たとえば生または生に近いタイプの放送フィードに関して、必要な総処理時間を短縮することが望ましい場合がある。
【発明の概要】
【0003】
処理時間および処理リソースは、特に時間に敏感な送信（たとえば、生放送、生イベント、ニュース速報）の文脈において、有限である。効果の追加または処理を行うことと、生イベントの時間的近接との間にバランスがある場合がある。たとえば、生のスポーツ・インベントに関して、言語キャプション（たとえば、アナウンサが話していることのコンピュータ生成されたクローズド・キャプション近似）またはグラフィックス（たとえば、アメリカン・フットボールの「ファースト・ダウン」について要求されるヤード数を示す黄色いライン）を付加することが望ましい場合がある。視聴者による遅延の許容範囲（たとえば、３０秒）が、そのようなデータ・ストリーム変更を付加するのに使用可能である場合がある。
【0004】
本明細書では、処理時間および処理リソースを最適化できるようにする、データ・ストリームの処理の制御および管理を対象とする様々な実施形態を説明する。実施形態を、たとえば、データ・ストリーム（たとえば、ビデオ・ストリーム）のダウンストリーム処理に関する命令セットを生成するように構成されたプロセッサを使用して実施することができる。固有のまたは能動的に提示される処理遅延、送信遅延、その他と、リソースの調整された管理および制御とが、より広い範囲の処理オプションを所与の時間期間内に行うことを可能にし得る。いくつかの実施形態は、コスト効率のよい分散リソース（たとえば、オフピーク可用性を利用する）にまたがってアクティビティを分散させ、割り振ることをさらに対象とする。
【0005】
ソース・データ・ストリーム（たとえば、ソース・ビデオまたはソース・オーディオ）が、最終的には消費者、顧客、テレビジョン・チャネル、実質的に「生」の放送フィードなどの様々なエンドポイントへの送信のために提供される。このソース・データ・ストリームは、エンドポイントへの送信の準備ができる前に、あるレベルの処理を必要とする場合がある。しかし、この処理が、時間集中型かつリソース集中型であり、計算的に難しい（たとえば、翻訳、サブタイトルの追加、グラフィックスの変更）場合がある。この技術的課題は、通信リンクにまたがるスループットが非理想的であり（たとえば、戦場）、配信されるストリームが、高品位フォーマットで送信される（たとえば、４Ｋ送信）ことが要求される場合に、悪化する。
【0006】
様々な実施形態は、異なるタイミング制御の技法、機構、およびプロセスがコンピュータおよびネットワーキング構成要素（たとえば、プロセッサ、スマート・ルータ、ネットワーク・インターフェース、ネットワーク・コントローラ、トラフィック輻輳コントローラ）を使用して実施される、技術的解決策を説明する。これらの制御技法、制御機構、および制御プロセスを、たとえば、様々なリソースに処理タスクを動的に割り振り、割り当て、さらに、総処理時間を減らすか他の形で管理できるように通信リンクを割り振り、割り当てるのに利用することができる。
【0007】
ソース・データ・ストリームは、いくつかの実施形態で、プレビュー・データ・ストリーム（たとえば、低ビットレートで非圧縮のダウンスケーリングされたストリーム）と、前処理されたデータ・ストリーム（たとえば、前処理された形または前処理する形の、放送品質で高解像度の圧縮されたストリーム）とに分割される。たとえば、プレビュー・データ・ストリームおよび前処理されたデータ・ストリームの分割および生成を、異なる符号化特性および判断基準の下でソース・データ・ストリームを符号化する、一緒に働く様々な符号器によって実行することができる。前処理されたストリームが、それでも、追加処理が行われることを要求する場合がある。
【0008】
スケーラブル符号器を使用して、前処理されたデータ・ストリームを生成することができ、スケーラブル符号器は、スケーラブル符号器が符号化の総量（したがって符号化のために要求される時間）のスケーリングを可能にするように、処理複雑さの異なるレベルとオプションとの間でのスケーリングを可能にする。
【0009】
いくつかの実施形態では、プレビュー・データ・ストリームは、最小限の遅延を伴って（たとえば、おそらくダウンスケーリングと圧縮なし／低レベルの圧縮とを伴って）生成され、高優先順位のネットワーク接続（たとえば、短待ち時間、潜在的により高コスト）を介して制御デバイスのセット（たとえば、エディタ・コンピューティング・デバイス）に送信され得、この制御デバイスのセットは、プレビュー・データ・ストリームを受信し、データ・ストリームがエンドポイントに供給される前に要求される異なるタイプの処理に基づいて、処理命令の命令セットを生成するためにプレビュー・データ・ストリームの処理を開始する。他の実施形態では、プレビュー・データ・ストリームを、単純に生のソース・データ・ストリームとすることができる。
【0010】
制御デバイス（たとえば、エディタ・コンピューティング・デバイス）は、いくつかの例で、高い複雑さの処理動作（たとえば、罵り言葉を識別するためのニューラル・ネットワークの適用、グラフィックス効果、画面注釈）を行い、高い複雑さの処理動作からの出力を処理命令のセット（たとえば、識別された罵り言葉に起因してｔ＝５ｓとｔ＝５．５ｓとの間にオーディオ・トラック１をオフに切り替える、ホッケー・パックの位置を表すためにフレーム５～１０に座標ＸおよびＹを中心とする円を描く）に縮小し、かつ／または他の形で変形するように設計される。処理命令のセットは、たとえば、いくつかの実施形態では単純化され得、処理中に実行される必要がある、より低水準のアクション（たとえば、サウンドをオフに切り替える、正方形を描く）を表し、この処理中には、より高水準の処理（たとえば、画像処理に基づいてプレイヤを識別するためのニューラル・ネットワーク分析）を、制御デバイスによって行うことができる。たとえば、命令セットを利用して、要求される処理を識別するか、関心領域（たとえば、プレイ・アクションを実質的にブロックせずにスコアボードを配置するためのよいターゲットになる、ストリーム・フレームの座標ベースの空間的区域）を識別することによって処理を容易にすることができる。
【0011】
前処理されたデータ・ストリームを、処理命令のセットに従う変更のためにデータ・ストリーム処理構成要素に供給することができる。
【0012】
処理命令のこの単純化されたセットは、データ・ストリーム処理構成要素に供給され、このデータ・ストリーム処理構成要素は、前処理されたデータ・ストリームを処理して、最終的に様々なエンドポイントによって消費されまたはダウンストリーム処理に使用され得る出力の処理されたストリームを生成する。データ・ストリーム処理構成要素は、単純化された処理命令を受信し、必要な最小限の処理時間で変更を適用する（たとえば、元の計算的に複雑なタスクに対する相対的な命令セットの単純化に起因して）。
【0013】
フレーム受信のタイミング差は、プレビュー・データ・ストリームおよび前処理されたデータ・ストリームによって受信される潜在的に異なるコンピューティング処理の結果または送信に利用される異なるネットワーキング接続の結果として発生する。たとえば、前処理されたデータ・ストリームは、より高い帯域幅要件のおかげで、より低速であるがより高スループットの接続に沿って送信され得る。したがって、プレビュー・データ・ストリームおよび前処理されたデータ・ストリームの対応するフレームが、お互いに対して相対的に時間においてシフトされる（符号化の差またはルーティングの差に起因して）場合がある。たとえば、プレビュー・データ・ストリームが、時間的に、前処理されたデータ・ストリームの４５秒前になる場合がある。
【0014】
非限定的な例では、プレビュー・データ・ストリームを、最小限に遅延されるダウンスケーリングされたデータ・ストリーム、生のデータ・ストリーム、またはフレームレートを下げられたデータ・ストリームとすることができ、前処理されたデータ・ストリームは、様々なコーデックおよび他の変換符号化が適用されて、高ビットレート／解像度での消費のために符号化され得る。これらの異なる符号化処理の結果として、いくつかの実施形態では、少なくとも固有の遅延が導入される。他の実施形態では、人工的な導入される遅延を利用することもでき、あるいは、人工的な遅延と固有の遅延との組合せを利用することができる。
【0015】
ストリームの間のこの相対遅延は、送信がソース・フィードからエンドポイント（たとえば、消費者）にもたらされ得るエンド・ツー・エンド時間に大きくは影響せずに、より前に受信されるプレビュー・データ・ストリームを使用して、計算集中型の技法、分析、および変形を単純化する機会を提供する。
【0016】
いくつかの実施形態では、単純化された命令セット生成および処理するアクティビティの管理が、たとえばプレビュー・データ・ストリームと前処理されたデータ・ストリームとの間の時間シフトされた差（たとえば７分）から導出されるタイミング制約に従う（たとえば、その中におさまる）ことが望ましい。単純化された命令セットの生成および送信を、タイミング制約の特定のセットの中で行うことができる場合に、エンドポイントへの配信の時刻に大きくは影響せずに、命令セットを実施のためにデータ・ストリーム処理デバイスに中継することができる。したがって、潜在的な利益は、プレビュー・ストリームおよび前処理されたデータ・ストリームに関して発生する計算機能、処理機能、および／または制御機能の考え抜かれた調整およびオーケストレーションを介する、あるレベルの計算集中的な処理が要求される準ライブ放送に関する改善されたエンド・ツー・エンド送信時間とすることができる。
【0017】
制御デバイスは、命令セットを生成する際に相互運用する複数の処理構成要素からなるものとすることができ、これらの複数の処理構成要素は、それぞれ、異なる可用性特性、コスト特性、性能特性、および速度特性を有する可能性がある。これらの複数の構成要素は、地理空間的に配置される場合もあり、お互いとリモートである（たとえば、ネットワーク・リンケージによってリンクされた分散クラウド・リソースとして）場合がある。
【0018】
構成要素は、同一のネットワークの一部または異なるネットワーク上とすることができる。たとえば、クラウドベースのコンピューティング実施態様では、構成要素は、リソースのプールから要求されるオンデマンド・リソースを表すことができ、制御デバイスまたは他のコントローラは、リソースを要求し、処理のために命令／データ・ストリームを送ることができるものとすることができる。そのような実施形態では、ルータが、コントローラとして働き、コンピューティング・リソースを、リソースの仮想クラスタからプロビジョニングされるコンピューティング・ノードとして扱うことができる。
【0019】
タスクの動作特性、選択、プロビジョニング、割当、および特定の処理構成要素への割振りを、命令セットの生成のオーケストレーションの要因とすることができる。いくつかの実施形態では、「クラウド・コントローラ」が、とりわけ各クラウド・コンピューティング構成要素、ネットワーキング・インターフェース、ネットワーキング接続に関連する特性および情報を収容するデータ構造を動的に維持する中央スケジューラ／ルータである、あるタイプの処理オーケストレーション・コントローラとして提供される。処理オーケストレーション・コントローラは、プレビュー・データ・ストリームおよび前処理されたデータ・ストリームの生成に関連する符号化パラメータをも制御することができる制御相互接続を含むことができる。
【0020】
処理オーケストレーション・コントローラは、協力して、コンピューティング構成要素、ネットワーク接続、プレビュー／前処理されたデータ・ストリーム符号器が最終的な出力データ・ストリーム（たとえば、エンドポイントへの）を提供する際にタイミング制約を満足することができるように、調整されオーケストレーションされた処理アクティビティの全体的な管理を有するように構成される。したがって、処理オーケストレーション・コントローラは、感知されたイベントおよび／または監視されるイベントに応答して、１つ以上のタイミング制約を満足するためにタスクを割り当て、プロビジョニングし、プロビジョニング解除し、割り振り、優先順位を付け、優先順位を下げ、割振り解除するために、データ構造をトラバースすることができる。
【0021】
処理オーケストレーション・コントローラは、複数のソース・ビデオ・ストリームをオーケストレーションするために構成され得、様々なタイミング制約が満足されることを保証するために結果的にバランスのとれた形でコンピューティング・リソースの制限されたセットを割り振り、プロビジョニングすること（たとえば、全体的な処理オーケストレーション・コントローラが所与の時刻に複数の生放送を制御すること）を要求され得る。
【0022】
処理オーケストレーション・コントローラは、たとえば、独立型のユニット（たとえば、スマート・ルータ）とするか、処理特性のデータ構造（たとえば、データベース内の）を記憶する、１つ以上のネットワーク接続およびプロセッサを含む特殊目的コンピューティング・デバイスとすることができる。たとえば、処理オーケストレーション・コントローラは、オン・デマンドでまたは予約ベースでネットワーク内部リソースおよびネットワーク外部リソースの混合物を利用し、性能、コスト、可用性などのような様々な要因に基づいて負荷平衡化を行う、ソフトウェア定義の広域ネットワークを制御することができる。
【0023】
処理オーケストレーション・コントローラは、クラウド・コンピューティング・リソース（たとえば、潜在的にエッジ・ノードまたは、クラウド・コンピューティング・クラスタなどの外部ネットワーク内のノード）を制御するための信号を送信し、特定の構成要素／構成要素のグループにタスクを動的に割り当て、かつ／またはタイミング制約を満足するためにタイミング・シーケンスおよびスケジュールを動的に制御することができる。これらのクラウド・コンピューティング・リソースは、たとえば、とりわけプレビュー・ストリームに基づくデータ・ストリーム変更、前処理されたストリームのデータ・ストリーム処理を識別するエディタ・コンピューティング・デバイス／制御デバイスの機能を実行するというタスクを与えられ得る。
【0024】
クラウド・コンピューティングの文脈では、クラウド・コンピューティング・リソースの地理空間的特徴または「仮想距離」態様を、たとえばプレビュー・データ・ストリームまたは前処理されたデータ・ストリームを処理する様々なタスクをそうでなければオフピーク使用（たとえば、より安価な可用性またはコスト節約がある可能性がある）に使用されるコンピューティング・デバイス上で行うことによって、総コストを削減する際に処理オーケストレーション・コントローラによってさらに利用することができる。
【0025】
いくつかの実施形態では、処理オーケストレーション・コントローラは、受動的管理ではなく、時間的制約の能動的管理のために構成される。これらの実施形態では、処理オーケストレーション・コントローラは、時間的制約が現在使用可能なリソースの可用性と一致するように時間的制約を増減するためまたは総処理コストを削減するために、前処理されたストリームの生成またはその送信の特性を故意に変更する。
【0026】
一実施形態では、データ・ストリーム変更を制御するシステムであって、システムは、プレビュー・データ・ストリームを受信する、制御デバイスであって、制御デバイスは、プレビュー・データ・ストリームに基づいて、前処理されたデータ・ストリームを変更する処理命令の１つ以上のセットを生成するように構成される、制御デバイスと、前処理されたデータ・ストリームを受信し、少なくとも、前処理されたデータ・ストリームの処理において処理命令の１つ以上のセットを実行することに基づいて、１つ以上のデータ変更を適用するように構成されたデータ・ストリーム処理デバイスであって、データ・ストリーム処理デバイスは、データ変更を含む出力の処理されたストリームを生成する、データ・ストリーム処理デバイスとを含み、プレビュー・データ・ストリームおよび前処理されたデータ・ストリームは、両方ともソース・ビデオ・データ・ストリームから導出され、プレビュー・データ・ストリームの対応するフレームの受信および前処理されたデータ・ストリームの対応するフレームは、プレビュー・データ・ストリームと前処理されたデータ・ストリームとの間の１つ以上の符号化の差に少なくとも部分的に起因してお互いに対して相対的に時間的にシフトされ、制御デバイスによるプレビュー・データ・ストリームの対応するフレームの受信は、データ・ストリーム処理デバイスによる前処理されたデータ・ストリームの対応するフレームの受信の前に発生するシステムが提供される。
【0027】
別の実施形態では、前処理されたデータ・ストリームは、ソース・ビデオ・データ・ストリームから生成された作品品質データ・ストリームである。
【0028】
別の実施形態では、このシステムは、プレビュー・データ・ストリームおよび前処理されたデータ・ストリームを別々のデータ・ストリームとして受信するように構成された少なくとも１つの受信器を含む。
【0029】
別の実施形態では、このシステムは、ソース・ビデオ・データ・ストリームを受信するように構成された少なくとも１つの受信器と、ソース・ビデオ・データ・ストリームからプレビュー・データ・ストリームを生成するように構成された第１の符号器と、ソース・ビデオ・データ・ストリームから前処理されたデータ・ストリームを生成するように構成された第２の符号器とを含み、プレビュー・データ・ストリームは、前処理されたデータ・ストリームより低いビットレートで生成される。
【0030】
別の実施形態では、第２の符号器は、プレビュー・データ・ストリームの対応するフレームに対する相対的な前処理されたデータ・ストリームの対応するフレームの受信の時間シフトを引き起こすために、データ・ストリーム処理デバイスへの前処理されたデータ・ストリームの送信を遅延させる機構を含む。
【0031】
別の実施形態では、第１の符号器および第２の符号器のうちの少なくとも１つの動作特性は、プレビュー・データ・ストリームの対応するフレームの受信と前処理された・データ・ストリームの対応するフレームとの間の時間遅延を変更するために制御可能である。
【0032】
別の実施形態では、制御デバイスおよびデータ・ストリーム処理デバイスは、マスタ－スレーブ構成で動作するように構成され、これによって、処理命令の１つ以上のセットは、データ・ストリーム処理デバイスによる実行のための単一方向処理ステップを表し、プレビュー・データ・ストリームと前処理されたデータ・ストリームとの間の符号化の差は、プレビュー・データ・ストリームの対応するフレームの受信と前処理されたデータ・ストリームの対応するフレームとの間の最小時間遅延をもたらし、制御デバイスは、データ変更を識別し、識別されたデータ変更を表す処理命令の１つ以上のセットを生成するように構成され、処理命令の１つ以上のセットは、データ・ストリーム処理デバイスによって実行される時に、前処理されたデータ・ストリームを出力の処理されたストリームに変換する。
【0033】
別の実施形態では、制御デバイスは、少なくともプレビュー・データ・ストリームの対応するフレームの受信と前処理されたデータ・ストリームの対応するフレームとの間の時間シフトによって定義される時間的制約以内に処理命令の１つ以上のセットを生成するように構成される。
【0034】
前処理されたデータ・ストリームを変更する処理命令の１つ以上のセットの各セットは、少なくとも、変更に関して選択された前処理されたデータ・ストリームのフレームのフレーム識別子と前処理されたデータ・ストリームの選択されたフレームに関連する画像操作命令またはオーディオ操作命令とを有するデータ構造を含む、請求項８に記載のシステム。
【0035】
別の実施形態では、制御デバイスは、プレビュー・データ・ストリームのうちの少なくとも１つと処理命令の１つ以上のセットとをプレビュー視覚化デバイスに送信するようにさらに構成される。
【0036】
別の実施形態では、このシステムは、データ変更を含む出力の処理されたストリームの生成が時間的制約以内に発生するように、前処理されたデータ・ストリームの処理を調整するように構成された処理オーケストレーション・コントローラをさらに含む。
【0037】
別の実施形態では、処理オーケストレーション・コントローラは、実施のためまたは制御デバイスおよびデータ・ストリーム処理デバイスのうちの少なくとも１つによる使用のために、複数のクラウド・コンピューティング・リソースから複数のクラウド・コンピューティング・リソースのサブセットを選択するように構成される。
【0038】
別の実施形態では、処理オーケストレーション・コントローラは、複数のクラウド・コンピューティング・リソースのうちのクラウド・コンピューティング・リソースの間の１つ以上のネットワーキング接続を制御するようにさらに構成され、処理オーケストレーション・コントローラは、処理命令の１つ以上のセットを生成するのに必要な総時間を変更するために１つ以上のネットワーキング接続を制御し、総時間は、時間的制約の中に含まれる
【0039】
別の実施形態では、複数のクラウド・コンピューティング・リソースの各クラウド・コンピューティング・リソースは、対応する地理空間的特性に関連付けられ、処理オーケストレーション・コントローラは、各クラウド・コンピューティング・リソースの地理空間的特性に少なくとも部分的に基づいて複数のクラウド・コンピューティング・リソースのサブセットを選択する。
【0040】
別の実施形態では、処理オーケストレーション・コントローラは、処理のために要求される時に特定のクラウド・コンピューティング・リソースを割り振るように構成され、処理が完了する時に割り振られたクラウド・コンピューティング・リソースを解放するように構成される。
【0041】
別の実施形態では、処理オーケストレーション・コントローラは、オフピーク使用を有する時間帯領域から選択されるクラウド・コンピューティング・リソースの回転するセットを割り振り、その後に解放するように構成される。
【0042】
別の実施形態では、各クラウド・コンピューティング・リソースの地理空間的特性は、地理的位置、時間帯、および対応するクラウド・コンピューティング・リソースとの間の通信に関するネットワーキング待ち時間のうちの少なくとも１つを含む。
【0043】
別の実施形態では、処理オーケストレーション・コントローラは、処理が条件の現在のセットを考慮した時間的制約を超える可能性が高いとの判定の際に、高優先順位のネットワーキング・リソースを要求するように構成される。
【0044】
別の実施形態では、処理オーケストレーション・コントローラは、プレビュー・データ・ストリームと前処理されたデータ・ストリームとの間の時間シフトの持続時間を制御するように構成される。
【0045】
別の実施形態では、処理命令の１つ以上のセットの生成は、複数のクラウド・コンピューティング・リソースのサブセットによって形成されるクラウド・コンピューティング・リソースのチェーンにまたがって行われ、期待されるエンド・ツー・エンド待ち時間は、ソース送信器からのネットワーク待ち時間と、クラウド・コンピューティング・リソースのそれぞれで要求される処理時間と、クラウド・コンピューティング・リソースのそれぞれの間の１つ以上のネットワーク待ち時間と、データ・ストリーム処理デバイスへのネットワーク待ち時間とを集計することによって周期的に判定され、期待されるエンド・ツー・エンド待ち時間が、時間的制約より長いとの判定の際に、処理オーケストレーション・コントローラは、期待されるエンド・ツー・エンド待ち時間が時間的制約の中に含まれるように、期待されるエンド・ツー・エンド待ち時間を短縮する補償アクションを開始するように構成される。
【0046】
別の実施形態では、データ・ストリーム変更を制御する方法であって、方法は、制御デバイスでプレビュー・データ・ストリームを受信することと、プレビュー・データ・ストリームに基づいて、前処理されたデータ・ストリームを変更する処理命令の１つ以上のセットを生成することと、データ・ストリーム処理デバイスで前処理されたデータ・ストリームを受信することと、少なくとも、前処理されたデータ・ストリームの処理において処理命令の１つ以上のセットを実行することに基づいて、１つ以上のデータ変更を適用することと、データ変更を含む出力の処理されたストリームを生成することとを含み、プレビュー・データ・ストリームおよび前処理されたデータ・ストリームは、両方ともソース・ビデオ・データ・ストリームから導出され、プレビュー・データ・ストリームの対応するフレームの受信および前処理されたデータ・ストリームの対応するフレームは、プレビュー・データ・ストリームと前処理されたデータ・ストリームとの間の１つ以上の符号化の差に少なくとも部分的に起因してお互いに対して相対的に時間的にシフトされ、制御デバイスによるプレビュー・データ・ストリームの対応するフレームの受信は、データ・ストリーム処理デバイスによる前処理されたデータ・ストリームの対応するフレームの受信の前に発生する方法が提供される。
【0047】
別の実施形態では、機械可読命令を記憶するコンピュータ可読媒体であって、機械可読命令は、プロセッサによって実行される時に、プロセッサに、ストリーム・データ変更を制御する方法を実行させ、方法は、制御デバイスでプレビュー・データ・ストリームを受信することと、プレビュー・データ・ストリームに基づいて、前処理されたデータ・ストリームを変更する処理命令の１つ以上のセットを生成することと、データ・ストリーム処理デバイスで前処理されたデータ・ストリームを受信することと、少なくとも、前処理されたデータ・ストリームの処理において処理命令の１つ以上のセットを実行することに基づいて、１つ以上のデータ変更を適用することと、データ変更を含む出力の処理されたストリームを生成することとを含み、プレビュー・データ・ストリームおよび前処理されたデータ・ストリームは、両方ともソース・ビデオ・データ・ストリームから導出され、プレビュー・データ・ストリームの対応するフレームの受信および前処理されたデータ・ストリームの対応するフレームは、プレビュー・データ・ストリームと前処理されたデータ・ストリームとの間の１つ以上の符号化の差に少なくとも部分的に起因してお互いに対して相対的に時間的にシフトされ、制御デバイスによるプレビュー・データ・ストリームの対応するフレームの受信は、データ・ストリーム処理デバイスによる前処理されたデータ・ストリームの対応するフレームの受信の前に発生するコンピュータ可読媒体が提供される。
【0048】
別の実施形態では、データ変更を含む出力の処理されたストリームの生成が時間的制約以内に発生するように、前処理されたデータ・ストリームの処理を調整する処理オーケストレーション・コントローラであって、処理オーケストレーション・コントローラは、複数のクラウド・コンピューティング・リソースの１つ以上の処理特性と複数のネットワーク接続の１つ以上のネットワーク特性とを記憶するデータ構造を維持するように構成されたデータ・ストレージと、コンピュータ可読記憶媒体と、前処理されたストリームを変更する処理命令の１つ以上のセットをプレビュー・データ・ストリームに基づいて生成するように構成された制御デバイスに供給されるプレビュー・データ・ストリームを生成し、前処理されたデータ・ストリームを生成するように構成された送信器にプロセッサを結合する、ネットワーク・インターフェースの第１のセットと、複数のクラウド・コンピューティング・リソースの各クラウド・コンピューティング・リソースにプロセッサを結合する、ネットワーク・インターフェースの第２のセットと、識別されたデータ変更を表す処理命令の１つ以上のセットを生成するために複数のクラウド・コンピューティング・リソースのサブセットを選択し、処理命令の１つ以上のセットの生成が、少なくともプレビュー・データ・ストリームの対応するフレームの受信と前処理されたデータ・ストリームの対応するフレームとの間の時間シフトによって定義される時間的制約以内に発生するように、クラウド・コンピューティング・リソースのサブセットによる前処理されたデータ・ストリームの処理を調整する制御信号を送信し、期待されるエンド・ツー・エンド待ち時間を判定するために、１つ以上の処理特性および１つ以上のネットワーク特性を継続的に監視し、期待されるエンド・ツー・エンド待ち時間が時間的制約より長いとの判定に応答して、期待されるエンド・ツー・エンド待ち時間が時間的制約の中に含まれるように、期待されるエンド・ツー・エンド待ち時間を短縮する補償アクションを開始するように構成されたプロセッサとを含み、プレビュー・データ・ストリームおよび前処理されたデータ・ストリームは、両方ともソース・ビデオ・データ・ストリームから導出され、プレビュー・データ・ストリームの対応するフレームおよび前処理されたデータ・ストリームの対応するフレームの、送信器による生成は、プレビュー・データ・ストリームと前処理されたデータ・ストリームとの間の１つ以上の符号化の差に少なくとも部分的に起因してお互いに対して相対的に時間的にシフトされる処理オーケストレーション・コントローラが提供される。
【0049】
別の実施形態では、プレビュー・データ・ストリームを受信し、出力データ・ストリームを生成するために前処理されたデータ・ストリームを変更する処理命令の１つ以上のセットをプレビュー・データ・ストリームに基づいて生成する制御デバイスであって、制御デバイスは、識別されたデータ変更のセットを表す処理命令の１つ以上のセットを生成する、複数のクラウド・コンピューティング・リソースから選択されたクラウド・コンピューティング・リソースのサブセットと、処理命令の１つ以上のセットの生成が、少なくともプレビュー・データ・ストリームの対応するフレームの生成と前処理されたデータ・ストリームの対応するフレームとの間の時間シフトによって定義される時間的制約以内に発生するように、クラウド・コンピューティング・リソースのサブセットによる処理命令の１つ以上の生成を調整する調整コントローラとを含む、制御デバイスが提供される。
【0050】
一実施形態では、少なくとも２つのデータ・ストリームの送信のために構成された少なくとも１つの送信器であって、少なくとも２つのデータ・ストリームは、少なくともより低品質のプレビュー・ストリームとより高品質のコンテンツ・ストリームとを含む、少なくとも１つの送信器と、少なくとも１つの送信器からリモートに配置された複数のエディタ・コンピューティング・デバイスであって、各エディタ・コンピューティング・デバイスは、少なくともプロセッサと非一時的コンピュータ可読メモリとを含み、複数のエディタ・コンピューティング・デバイスは、少なくともより低品質のプレビュー・ストリームを受信し、複数のエディタ・コンピューティング・デバイスは、より低品質のプレビュー・ストリームに対する処理および編集を容易にするように構成され、処理および編集は、処理および編集を表す機械可読命令のセットを生成するのに使用される、複数のエディタ・コンピューティング・デバイスと、少なくとも１つの送信器からリモートに配置された複数のルーティング・コンピューティング・デバイスであって、各ルーティング・コンピューティング・デバイスは、少なくともプロセッサと非一時的コンピュータ可読メモリとを含み、複数のルーティング・コンピューティング・デバイスは、少なくともより高品質のコンテンツ・ストリームと機械可読命令のセットとを受信し、複数のルーティング・コンピューティング・デバイスは、出力コンテンツ・ストリームを生成するために機械可読命令のセットに従ってより高品質のコンテンツ・ストリームを符号化することによってより高品質のコンテンツ・ストリームを処理するように構成される、複数のルーティング・コンピューティング・デバイスと、処理および編集がより低品質のプレビュー・ストリームに対する相対的なより高品質のコンテンツ・ストリームに関する送信の間の遅延の持続時間内に実行されるように、監視されたネットワーク特性に基づいて複数のエディタ・コンピューティング・デバイスのサブセットを選択するように構成されたコントローラ・コンピューティング・デバイスとを含む、データ・ストリームをリモートに処理するシステムが提供される。
【0051】
別の実施形態では、遅延の持続時間は、より低品質のプレビュー・ストリームに対する相対的なより高品質のコンテンツ・ストリームに関する送信の間に導入される遅延を含む。
【0052】
別の実施形態では、このシステムは、複数の配信管理コンピューティング・デバイスであって、配信管理コンピューティング・デバイスのそれぞれは、１つ以上のエンドポイントへの配信特性と、１つ以上のエンドポイントへの出力コンテンツ・ストリームの送信とを決定するように構成される、複数の配信管理コンピューティング・デバイスをさらに含む。
【0053】
別の実施形態では、少なくとも１つの送信器は、複数のエディタ・コンピューティング・デバイスと複数のルーティング・コンピューティング・デバイスとの間でデータ・ストリームをルーティングするように動作可能なルータを含む。
【0054】
別の実施形態では、少なくとも１つの送信器は、ビデオ・ソースからの単一のコンテンツ・ストリームから少なくとも２つのデータ・ストリームを生成するように構成された、２つの並列符号器およびスケーラブル符号器を含む。
【0055】
別の実施形態では、スケーラブル符号器は、少なくとも２つのデータ・ストリームの解像度に比例するコーディング遅延を提供するように構成される。
【0056】
別の実施形態では、より低品質のプレビュー・ストリームは、リアルタイムまたは近リアルタイムで提供され、より高品質のコンテンツ・ストリームは、導入された遅延または固有の遅延を伴って提供される。
【0057】
別の実施形態では、処理および編集は、サブタイトルの追加、グラフィカル・スコアボードの追加、グラフィカル・アイコンの追加、広告の追加、オーバーレイの追加、キュレーティング、および検閲のうちの少なくとも１つを含む。
【0058】
別の実施形態では、少なくとも１つの送信器は、メタデータ・データ・ストリームを送信するように構成され、メタデータ・データ・ストリームは、複数のエディタ・コンピューティング・デバイスに提供され、機械可読命令のセットの生成の際に処理される。
【0059】
別の実施形態では、このシステムは、スケジューラ・コンピューティング・デバイスであって、スケジューラ・コンピューティング・デバイスは、対応する複数のエディタ・コンピューティング・デバイスおよび複数のルーティング・コンピューティング・デバイスでの少なくとも２つのデータ・ストリームの到着に関する送信特性を監視し、監視された送信特性に基づいて、少なくとも１つのエンドポイントへの出力コンテンツ・ストリームの送信を含むデータ・パケットの送信をスケジューリングするように構成される、スケジューラ・コンピューティング・デバイスをさらに含む。一実施形態では、異なる通信経路が、全体的なネットワーク状態に基づいて選択され、送信に使用され、第１の接続は、エディタ・コンピューティング・デバイスへの送信に利用され、第２の接続は、ルーティング・コンピューティング・デバイスへの送信に利用され、第１および第２の接続は、とりわけ、待ち時間、帯域幅、冗長性の必要などの様々な判断基準を満足するためにストリームを編集機構Ａに送るために、コントローラによって選択される。
【0060】
別の実施形態では、データ・ストリームをリモートに処理する方法であって、少なくとも２つのデータ・ストリームを送信することであって、少なくとも２つのデータ・ストリームは、少なくともより低品質のプレビュー・ストリームとより高品質のコンテンツ・ストリームとを含む、送信することと、少なくとも１つの送信器からリモートに配置された複数のエディタ・コンピューティング・デバイスで、少なくともより低品質のプレビュー・ストリームを受信することであって、複数のエディタ・コンピューティング・デバイスは、より低品質のプレビュー・ストリームに対する処理および編集を容易にするように構成され、処理および編集は、処理および編集を表す機械可読命令のセットを生成するのに使用される、受信することと、少なくとも１つの送信器からリモートに配置された複数のルーティング・コンピューティング・デバイスで、少なくともより高品質のコンテンツ・ストリームと機械可読命令のセットとを受信することであって、複数のルーティング・コンピューティング・デバイスは、出力コンテンツ・ストリームを生成するために機械可読命令のセットに従ってより高品質のコンテンツ・ストリームを符号化することによってより高品質のコンテンツ・ストリームを処理するように構成される、受信することと、処理および編集がより低品質のプレビュー・ストリームに対する相対的なより高品質のコンテンツ・ストリームに関する送信の間の遅延の持続時間内に実行されるように、監視されたネットワーク特性に基づいて複数のエディタ・コンピューティング・デバイスのサブセットを選択することとを含む方法が提供される。
【0061】
別の実施形態では、この方法は、１つ以上のエンドポイントへの配信特性を決定することと、１つ以上のエンドポイントへの出力コンテンツ・ストリームの送信を制御することとを含む。
【0062】
別の実施形態では、この方法は、２つの並列符号器およびスケーラブル符号器によって、ビデオ・ソースからの単一のコンテンツ・ストリームから少なくとも２つのデータ・ストリームを同時に生成することを含む。
【0063】
別の実施形態では、この方法は、少なくとも２つのデータ・ストリームの解像度に比例するコーディング遅延を提供することをさらに含む。
【0064】
別の実施形態では、この方法は、メタデータ・データ・ストリームを送信することを含み、メタデータ・データ・ストリームは、複数のエディタ・コンピューティング・デバイスに提供され、機械可読命令のセットの生成の際に処理される。
【0065】
別の実施形態では、この方法は、対応する複数のエディタ・コンピューティング・デバイスおよび複数のルーティング・コンピューティング・デバイスでの少なくとも２つのデータ・ストリームの到着に関する送信特性を監視することと、監視された送信特性に基づいて、少なくとも１つのエンドポイントへの出力コンテンツ・ストリームを含むデータ・パケットの送信をスケジューリングすることとを含む。一実施形態では、異なる通信経路が、全体的なネットワーク状態に基づいて選択され、第１の接続は、低品質プレビューに利用され、第２の接続は、高品質ストリームに利用され、第１および第２の接続は、とりわけ、待ち時間、帯域幅、冗長性の必要などの様々な判断基準を満足するためにストリームを編集機構Ａに送るために、コントローラによって選択される。
【0066】
別の実施形態では、データ・ストリームをリモートに処理するコンピュータ可読媒体であって、コンピュータ可読媒体は、機械可読命令をその上に記憶され、この機械可読命令は、プロセッサによって実行される時に、プロセッサに、データ・ストリームをリモートに処理する方法であって、少なくとも２つのデータ・ストリームを送信することであって、少なくとも２つのデータ・ストリームは、少なくともより低品質のプレビュー・ストリームとより高品質のコンテンツ・ストリームとを含む、送信することと、少なくとも１つの送信器からリモートに配置された複数のエディタ・コンピューティング・デバイスで、少なくともより低品質のプレビュー・ストリームを受信することであって、複数のエディタ・コンピューティング・デバイスは、より低品質のプレビュー・ストリームに対する処理および編集を容易にするように構成され、処理および編集は、処理および編集を表す機械可読命令のセットを生成するのに使用される、受信することと、少なくとも１つの送信器からリモートに配置された複数のルーティング・コンピューティング・デバイスで、少なくともより高品質のコンテンツ・ストリームと機械可読命令のセットとを受信することであって、複数のルーティング・コンピューティング・デバイスは、出力コンテンツ・ストリームを生成するために機械可読命令のセットに従ってより高品質のコンテンツ・ストリームを符号化することによってより高品質のコンテンツ・ストリームを処理するように構成される、受信することと、処理および編集がより低品質のプレビュー・ストリームに対する相対的なより高品質のコンテンツ・ストリームに関する送信の間の遅延の持続時間内に実行されるように、監視されたネットワーク特性に基づいて複数のエディタ・コンピューティング・デバイスのサブセットを選択することとを含む方法を実行させる、コンピュータ可読媒体が提供される。
【0067】
様々なさらなる態様では、本開示は、対応するシステムおよびデバイスと、そのようなシステム、デバイス、および方法を実施する機械実行可能なコーディングされた命令セットなどの論理構造とを提供する。
【0068】
この点で、少なくとも１つの実施形態を詳細に説明する前に、諸実施形態が、以下の説明で示されまたは図面に示された構造の詳細および構成要素の配置への適用に限定されないことを理解されたい。また、本明細書で使用される語法および用語が、説明のためのものであって限定的とみなされてはならないことを理解されたい。
【0069】
本明細書で説明される実施形態に関する多数のさらなる特徴およびその組合せが、本開示を読んだ後に、当業者に明白になる。開示される特徴の異なる組合せ、変形形態、および配置が企図されている。
【0070】
図面では、実施形態が例として図示される。この説明および図面が、例示のみのためのものであり、理解の助けとして意図されていることを特に理解されたい。
【0071】
これから、添付図面を参照して、例としてのみ、諸実施形態を説明する。
【図面の簡単な説明】
【0072】
【図1】いくつかの実施形態による、テレビジョン調整室またはスタジオを介するビデオの既存のシステムを示す例の概略図である。
【図2A】いくつかの実施形態による、様々な処理アクティビティに関するクラウドベースの機構を介するビデオまたは他のデータのための代替システムを示す例の概略図である。
【図2B】いくつかの実施形態による、スマートスケジューラ／ルータの構成要素を示す例のブロック概略図である。
【図2C】いくつかの実施形態による、第１のデータ・ストリームおよび第２のデータ・ストリームと相互運用するスマートスケジューラ／ルータを示す図である。
【図2D】いくつかの実施形態による、スマートスケジューラ／ルータによってオーケストレーションされたエディタ・コンピューティング・デバイスおよびルーティング・コンピューティング・デバイスのセットを示すブロック概略図である。
【図2E】いくつかの実施形態によるシステムを示すブロック概略図である。
【図3】いくつかの実施形態による、フレームが受信され処理される時に提供され得るパケット・タイミングを示す時間変動図である。
【図4A】いくつかの実施形態による、クラウド処理を可能にするためのより低品質のストリームおよびより高品質のストリームの生成を示すサンプル概略図である。
【図4B】いくつかの実施形態による、クラウド処理を可能にするためのより低品質のストリームおよびより高品質のストリームの生成を示すサンプル概略図である。
【図4C】いくつかの実施形態による、クラウド処理を可能にするためのより低品質のストリームおよびより高品質のストリームの生成を示すサンプル概略図である。
【図4D】いくつかの実施形態による、クラウド処理を可能にするためのより低品質のストリームおよびより高品質のストリームの生成を示すサンプル概略図である。
【図5A】ビデオ・ソースに関する様々な構成要素を分離し、操作される関連する編集構成要素／キューイング構成要素にそれらを送るシステムを示す例の概略図である。
【図5B】スマート・クラウド・ルータに送られる前に切り替えられる複数のビデオ・ソースを含むシステムを示す例の概略図である。
【図6】いくつかの実施形態による、並列クラウド処理を可能にするために、別々のオーディオ・ストリームおよびメタデータ・ストリームと共により低品質のビデオ・ストリームおよびより高品質のビデオ・ストリームを使用することによるビデオ・ストリームのリアルタイム処理の可能化を示す例のタイミング図である。
【図7】いくつかの実施形態による、スマート・ルーティング・システムの要素を含むシステムを示す例の概略図である。
【図8A】多数の同一の処理ユニットにストリーム要素を送ることに基づいて冗長性を提供するシステムを示す例の概略図である。
【図8B】多数の同一のスマート・ルータにストリームを送ることに基づいて冗長性を提供するシステムを示す例の概略図である。
【図9】いくつかの実施形態による、リモート処理に関するサンプル手法を示すワークフローである。
【図10】一実施形態の典型的なコンピューティング・デバイスを示す概略図である。
【発明を実施するための形態】
【0073】
いくつかの解決策は、一般に、特殊化されたＳｅｒｉａｌ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅ（ＳＤＩ）ルータを介してルーティングされるＳＤＩを介して同軸ケーブルによって処理ユニットの間でオーディオ・データおよびビデオ・データを転送することを含む。
【0074】
複数のオーディオ／ビデオ・ストリームが、調整室によって同時に処理される必要がある場合があるので、大容量の（かつ高価な）ＳＤＩルータが、保証された容量を提供するために必要になる。さらに、ＳＤＩケーブル長の制限と様々な処理ユニットの配置および管理に関するオプションとが、追加の複雑化する要因である。
【0075】
ビデオ制作作業でのＩＰベースのワークフローへのシフトに伴って、スタジオを介してＩＰネットワーク上で一般に非圧縮のＳＤＩ信号をカプセル化することによって、調整室内でのＳＤＩ信号の符号化、送信、および受信を可能にする試みが行われてきた。そのような解決策への寄与は、映画テレビ技術者協会（ＳＭＰＴＥ）（商標）によるＳＭＰＴＥ ２０２２プロトコルおよびＳＭＰＴＥ ２０５９プロトコルの作成と、ＮｅｗＴｅｋ（商標）のＮｅｔｗｏｒｋ Ｄｅｖｉｃｅ Ｉｎｔｅｒｆａｃｅ（ＮＤＩ）とを含む。しかし、そのような解決策は、一般に、様々な処理をクラウドを介してリモートに行うことができる広域ネットワーク（ＷＡＮ）ではなく、テレビ局またはスタジオ内のローカル・エリア・ネットワーク（ＬＡＮ）内で働くように設計される。
【0076】
ＩＰベースのワークフローは、媒体処理に関するネットワーク化されたワークフローの１タイプを表し、他の実施形態および技術を利用することができる。
【0077】
いくつかの実施形態で説明されるように、リモート処理解決策を利用して、ローカル処理解決策の文脈で他の形で使用可能または適用可能ではないはずの処理の利益を提供することができる。
【0078】
そのようなリモート処理を、「クラウド」と考えることができ、クラウドは、リソースの間で直接におよび／または間接に確立されたデータ通信ストリームの使用を介して総合接続された分散リソースのセットを含む。リソースは、たとえば、プロセッサ、コンピュータ可読媒体、ストレージ、ネットワーキング機器、その他を含むコンピューティング・リソースの「プール」の形で提供されるリソースなど、使用のために必要な時に必ず作動させることのできる実コンピューティング・デバイスまたは仮想コンピューティング・デバイスとすることができる。
【0079】
仮想インスタンスを、同一のコンピューティング・デバイス上または異なるコンピューティング・デバイス上で提供することができ、たとえば、単一のサーバを、複数のインスタンスをホスティングするように構成することができ、あるいは、単一のインスタンスを、一緒に働く複数のコンピューティング・システムによって提供することができる。
【0080】
様々な実施形態で説明するように、分散リソースにまたがる処理のオーケストレーションを助けるコンピューティング・リソースのプールのコンピュータ化された調整が、いくつかの例で、とりわけ、要求される全体的な計算能力の削減、全体的なコスト（たとえば、オフピーク・コンピューティング・リソースの使用）、処理時間／ルーティング時間の削減（たとえば、最終的な宛先に関するより短い待ち時間を有するリソースの選択による）を可能にする、潜在的な利点がある。
【0081】
いくつかの実施形態では、リソース（たとえば、コンピューティング、ネットワーキング）を動的にプロビジョニングすることができ、ローカル処理解決策の文脈で他の形で入手可能ではないはずのさらなる処理の利益を得るのに利用できるリソースに関連する特性がある場合がある。たとえば、リソースを、必要な時に動的にプロビジョニングし、かつ／またはプロビジョニング解除することができ（たとえば、リソースの共通プールの使用を効率的に共有することを可能にすること、そうでなければ浪費される過剰な容量を活用すること）、リソースが、地理的な位置の考慮事項を有する場合があり、リソースが、お互いとは異なるネットワーク通信ストリーム特性を有する場合もある。ストリーム特性は、たとえば、とりわけ、帯域幅、待ち時間、輻輳、可用性、コストを含む。リソースが、命令のキュー、アクセスの変更など、制御され得る優先順位付け態様を有する場合がある。
【0082】
生じる可能性がある例のシナリオは、リソースが「ピーク時間」（たとえば、地方の夕方のニュース放送）に基づいて特定の局の専用である時である。追加のリソースが、時刻に基づいて使用される場合があり、リソースは、そのサイクルの終りにそのユーザ／局に関してプロビジョニング解除されて、「次の」時間帯に別の局によって再利用されるのみである。したがって、回転する「ピーク時間」を使用して、制限されたリソースを需要を満足するためにどのように共有できるのかを判定するように、リソースの動的にプロビジョニングされるセットを、時間帯にまたがって有利に利用することができる。
【0083】
いくつかのシナリオでは、いくつかの時間帯が、他の時間帯より少数の局を有する場合があり、その場合に、アクティブ・リソースの全体的なプールは、時間帯の間で増大し、縮小するはずである。したがって、これらの状況、異なる構成がある可能性があり、ある構成では、所与の局が、期待される使用に従って１日全体でそれ自体のリソース・プールを増大／縮小させ、ある構成では、リソース・プール全体が、あるタイム・スロット内の期待される使用に応じて１日にわたって増大しまたは縮小する可能性がある（たとえば、リソースを要求すると期待される局のグループが１日の間に増大し、縮小する時に）。負荷は、必ず予測可能とは限らず、たとえば、英国での深夜のニュース放送でのリソース要件のスパイクは、ニュー・ヨークの放送がその時間の通常より多数のニュースを有する時に東京でのニュース速報イベントと一致する可能性がある、ニュー・ヨークでの夕食時の放送と一致する可能性があり（ロンドンの夕方のニュース放送と一致するという事実が予測可能である可能性があるので）、東京でのニュース速報が、不均一で予測不能な可用性につながる可能性がある。
【0084】
動的リソースをサポートする物理リソースの地理空間的性質は、クラウド・リソースが配置される位置が、どのリソースを利用すべきかを決定する際の関連する要因である可能性があるので、重要である可能性がある。時間が進行するにつれて、異なる時間帯に配置されたリソースが、「回転され」て、その時間帯での局の要件を反映する場合がある。その代わりに、いくつかの実施形態では、ピーク時間に、リソースがスピン・アップされる複数の地理がある場合があり、トラフ・タイム（ｔｒｏｕｇｈ ｔｉｍｅ）には、ネットワーク待ち時間が制約ではないリソース／アクションに関して、システムを、特定の位置（たとえば、最低の電気コストまたは人員コストを有する位置、たとえば人間の介入を必要とするすべての編集アクティビティまたは他のアクティビティがトラフ・タイム中にインドに送られ、ニュー・ヨークなどの伝統的により高価な地理内のリソースは、ピーク時にのみ束縛される）のリソースのみを使用する（またはその使用を強調する）ように構成することができる。他の実施形態では、ある種のアクティビティがある種の個人（たとえば、組合に加入している局スタッフ、特定の機密情報取り扱い許可を有する個人）によって実行されることを必要とするルールがある場合があり、これが、どのリソースを利用すべきかをさらに制限する可能性がある。
【0085】
いくつかの実施形態では、たとえば使用量および／または期待される／予約された使用量のスケジュールのレコードを記憶するデータ構造を維持することによって、１つ以上のコンピューティング・デバイスのピーク時使用量および容量を追跡し、かつ／または監視するコントローラ（たとえば、処理オーケストレーション・コントローラ）が利用される。移動平均値または他のメトリックを維持して、期待される利用率を確立することができる。たとえば、ある時間期間の間により低い期待される利用率を有するリソースは、分散リソースにまたがる負荷平衡化のよい候補である可能性がある。
【0086】
地理空間的距離は、必ずリソースの間の「通信距離」と等しくなるとは限らず、たとえば、２つの別個の地理的位置の間の高速の高帯域幅接続がある場合があり、逆に、２つの近い地理的位置に関して、悪い接続性に起因して、通信の展望からはそれらが「遠く離れて」見える場合がある。この区別を、たとえば、どのリソースを利用すべきかを判定する時に考慮に入れることができる。
【0087】
いくつかの実施形態では、待ち時間、使用可能な帯域幅、および／またはパケット送信特性が、ある時間期間にわたって測定され、監視され、その結果、過去の特性（たとえば、低変動性待ち時間統計または所定のしきい値未満の待ち時間）に基づいて予測および判断を行えるようになる。いくつかの状況では、予想外の待ち時間および／または悪い通信ストリームがダウンストリームの依存するプロセスに影響する可能性があるので、通信の予測可能性および信頼性は、利用に関して分散リソースを選択する時の考慮事項である。
【0088】
選択プロセスを利用して、特定のアプリケーションに最適に適する（または、少なくとも現状に関してより適する）特定の仮想化されたリソースを判定することができ、選択プロセスは、性能要因だけではなく、コスト要因、冗長性要因などをも含むことができる。いくつかの実施形態では、コントローラは、特定の文脈または状況に関してより効率的なリソース（たとえば、強いグラフィックス能力を有するリソースは、複雑なグラフィックス集中型のタスクによりよく適する可能性があるが、大きいキャッシュを有するリソースは、多数のストレージ読取／書込を伴うタスクによりよく適する可能性がある）を識別するための予備判定を行うのに利用される。コントローラは、予備判定を利用して、期待される割当また一時的割当を確立することができ、この期待される割当また一時的割当は、期待される選択要因に関するより多くの情報が使用可能になる時に、更新されまたは改訂され得る（たとえば、リソースＡが、予備判定に基づいて選択されるが、使用の時刻が接近する時に、リソースＡが、突然に重い負荷を受け、リソースＢがよりよいターゲットになる）。
【0089】
たとえば、地理的位置および／または特定のリソースの間の通信ストリームを、コスト、待ち時間、処理時間、その他などの複数の要因に基づいて選択することができる。たとえば、これらのリソースを、たとえば、機能性、既知の必要な処理時間、既知の必要な最大待ち時間などに基づいてリソースを割り振るのに使用することのできる重み付け手法および重み付け方法論に基づいて選択することができる。リソースは、処理に限定されるのではなく、通信ネットワーク、編集リソース、ストレージ・リソース、および関連リソース、またはその任意の組合せをも含むことができる。
【0090】
これらの考慮事項は、ビデオ・ストリームにサブタイトルまたはスコアボードを追加するのに必要な時間の長さ、または、イベント発生と放送との間の既知の遅延時間（たとえば、補足の検閲の機会を提供するための）など、なんらかの使用に関して先験的に知られ得る（たとえば、固定されまたは過去の平均値として）。いくつかの実施形態では、考慮事項は、それらが感知され、かつ／または監視される時に動的に調整される。たとえば、変化するコスト考慮事項、ネットワーク状態、冗長性考慮事項、リソース供給、リソース需要、負荷平衡化要件などがある場合がある。
【0091】
いくつかの実施形態では、リソースは、メイン・コントローラによって中央で管理され、このメイン・コントローラは、完全に別々のストリームおよび要件に関して、複数のソースおよび／または宛先の間で相互運用することができる。たとえば、メイン・コントローラは、ニュース送信、クローズド・サーキット・システム、およびスポーツ送信のためのクラウドベースのリソースのブローカとして同時に相互運用していると同時に、媒体コンテンツ処理リソースを平衡化しているものとすることができる。平衡化を最適化して、単一の使用だけではなく、システムの全体的なプロビジョニングに関して有益な結果をもたらすことができる。いくつかの実施形態では、様々な使用に、他の使用に対して優先順位を与えることができ、優先順位は、送信のセットに関する変化するルールに起因してまたは新規送信の包含および既存送信の完了によって、動的に変化する。
【0092】
システムがストリームの要件に関するさらなる情報を入手する時に、システムは、自動化されたおよび／または半自動化された意思決定をよりよくサポートすることができる。固定された締切期限を有する生のおよび／またはリアルタイムの送信がある場合に、リソースは、締切期限が必ず満足されるようにするために、専用にされる必要がある場合がある。
【0093】
逆に、クリップのオフライン編集および再符号化は、厳しい締切期限を有しない場合があり、したがって、コントローラは、全体的なコストを最適化する（たとえば、待つことのできるタスクのためにより多くのクラウド・リソースをスピン・アップする必要を減らす）ために、やはり締切期限を有しない他のタスクと共にそのタスクをタイム・スライス化すると決定することができる。
【0094】
編集および／または処理のタイプと締切期限の切迫とに応じて、システムは、遅延が以前には存在しない場合に、信号の処理／前処理に分散リソースを利用するために、遅延（たとえば、人工的な遅延）を導入する制御信号を発行することができ、この遅延は、たとえば、リソース帯域幅、通信ストリーム／接続性特性、要求される処理のタイプ、経済的実行可能性、その他などの分散リソースの特性に基づいて決定される。いくつかの実施形態では、アプリケーション駆動のＳＤ ＷＡＮ（ソフトウェア定義広域ネットワーク）を、選択された使用可能なクラウド・リソースから動的に形成することができる。
【0095】
いくつかの実施形態では、コントローラは、１つ以上の時間期間中に所与のタスクに関して使用可能な処理リソースの量を測定し、人工的な遅延の持続時間に関する初期決定を行うように構成される。非限定的な例では、検閲プロセスが乱暴な言葉をフィルタリングによって除去でき（たとえば、午後９：００に放送分岐されて番組が生放送されている）、検閲プロセスが既知の量の処理リソースを消費することを保証することがクリティカルである場合がある。この場合に、いくつかの実施形態のコントローラは、検閲プロセスが発生することが可能になるように、人工的な遅延の持続時間を動的に確立し、かつ／または判定するように構成される。理想的には、遅延のサイズはできる限り最小限であるが、いくつかの場合に、コストまたは他の制約がある場合があり、コントローラは、供給された処理優先順位のセットに基づいてバランスを探すように構成され得る。いくつかの状況では、遅延のサイズが、特に関連する考慮事項ではない場合があり、コストを最適化することができる（たとえば、オフピーク・コンピューティング・リソースを使用することによって）。
【0096】
より多くの時間が要求される場合に、「安全クッション」を、処理に関して対応するフレームの間の判定された遅延に追加することができる（たとえば、リソースＡ、Ｂ、およびＣを使用して、３秒の遅延が通常は十分であると期待され、コントローラが、処理が完了することを保証するのを助けるために５０％のクッションを追加し、４．５秒の遅延を挿入できる）。いくつかのさらなる実施形態では、システムは、実際の処理時間対期待される処理時間および提供される遅延を追跡し、比較し、モデル化された統計的標準偏差および分散に基づいて経時的に安全クッション・レベルを変更するように構成される。たとえば、固定された要因ではなく安全クッションを設けて、処理が１つ、２つ、または３つの標準偏差などの範囲内の遅延の間に完了できなければならないことを保証し、遅延機構の正しいサイズを設定するためのより粒度の高い手法を提供することができる。
【0097】
通信ストリームを、１つ以上のリンクを介して提供することができ、たとえば、通信リンクは、１つ以上の通信ストリームをホスティングすることができる。いくつかの実施形態では、システムは、単一の通信リンクを送信器に供給し、複数の送信器が処理されている場合には、複数のリンクを送信器に同時に供給するように構成される。いくつかの実施形態では、通信ストリームあたり１つの通信リンクだけがあり、他の実施形態では、各通信リンクが複数の通信ストリームを有する。通信ストリームの分離は、物理的、仮想的、またはこの両方の組み合わせとすることができる。たとえば、１つの通信リンクを、論理的に複数の通信ストリームに分離することなどができる。通信リンクを、通信リンクの特性（たとえば、速度、帯域幅、パケット消失、待ち時間［過去のまたは動的な］）に基づいて特定のデータ・ストリームと共に使用するために選択的に選択することができる。
【0098】
いくつかの実施形態では、通信ストリームが同一のリンクを介して提供される場合に、たとえば、低解像度ストリームが最初に到着し、実行される必要があるすべての動作に関して適当な時間を保証するのに十分な遅延が使用されることを保証するのに使用できるサービス品質プロトコルを適用することによって、競合を管理することができる。１つ以上の通信リンクが、いくつかの実施形態では、システムによって、必要な遅延を示す情報を用いて選択され得（たとえば、短待ち時間セル上で低品質編集可能プレビューを送り、長待ち時間衛星上でフル画像を送る）、いくつかの実施形態では、サービス品質プロトコルが、「同一リンク」上であることに頼る必要がない。送信性能を改善する手法の一例を、参照によって本明細書に組み込まれている米国特許出願第１４／３６０３７２号（米国特許第９３５７４２７号として認可）に見出すことができる。
【0099】
通信リンクは、コントローラとコンピューティング・デバイス（たとえば、エディタ・コンピューティング・デバイスまたはルーティング・コンピューティング・デバイス）との間、または、いくつかの場合にコンピューティング・デバイス自体の間とすることができる。異なるトポロジが可能であり、たとえば、いくつかのトポロジでは、コントローラは、各コンピューティング・デバイスに接続されるが、他のトポロジでは、コンピューティング・デバイスを、並列または直列の形でお互いに接続することができる（たとえば、処理の「ステージ」が完了する時にコンピューティング・デバイスの間で情報を渡す）。一例では、第２のタイプの処理に専用の第２のエディタ・コンピューティング・デバイスに渡す前に発生しなければならない第１のタイプの処理に専用の第１のエディタ・コンピューティング・デバイス。
【0100】
いくつかの実施形態で提供したように、クラウドベースの解決策は、スケーラビリティ、負荷平衡化、柔軟性、冗長性、並列性、「従量制」の能力、およびビデオ出力の局間転送を実行する能力を含むがこれに限定されない、テレビジョン局の内部で通常は行われるビデオ処理を処理する際の利点を提供する。他の形で使用不能であったはずの追加のコンピューティング処理能力を、分散リソースの使用を介して経済的に実行可能にすることができる。たとえば、特に集中的な符号化／トランスコーディング・プロセスを、分散リソース／リソース共有の使用を介して実行可能にすることができるが、これは、処理ユニットが特定の局／調整室で購入され管理されなければならなかった場合に実行可能ではなかったはずである。
【0101】
したがって、より効率的な使用が使用可能であり、制限された量のリソースを用いて品質を改善し／データ送信ストリームに効果を追加するための編集または他の処理を行う機会および能力を高める。
【0102】
ビデオ処理、特にトランスコーディング／符号化動作は、特に高品位および／または高解像度フォーマットに関して非常にプロセッサ集中型であり、したがって、リソースが、高価になると同時に欠乏する可能性がある。処理タスクは、たとえば、とりわけ、スケーリング、信号変換／変形、インターレース／デインターレース、アーティファクト除去、輝度／コントラスト調整、デジタル・ズームおよびデジタル・パン、色点変換（ｃｏｌｏｒ ｐｏｉｎｔ ｃｏｎｖｅｒｓｉｏｎ）、雑音／ひずみ低減、動き補償、動き予測圧縮に関する補償、圧縮、境界効果補償を含むことができる。
【0103】
これらの利点を達成するために、様々な技術的問題を克服する必要がある可能性がある。たとえば、クラウドベースの解決策は、異なる位置の複数のリソースを含む、待ち時間およびマシン・クロックと人間のアクティビティとの両方の同期を管理する際の課題をもたらす可能性がある。いくつかの実施形態では、コンピューティング・リソースおよびコントローラは、共通のクロック機構に同期化され、このクロック機構は、正確なタイムスタンピングを処理動作に提供する。さらなる複雑化する要因は、分散リソースの地理的位置、分散リソースの間の通信ストリームの品質、誤り訂正などを含む可能性がある。特に通信ストリームを介して送信されているデータがクリティカルまたは異例に時間に敏感である場合に、リソース管理の高められた複雑さがある場合がある。
【0104】
いくつかの実施形態では、システムは、タスクをより小さい部分に分割し、これらを処理のためにアイドル・クラウド・リソースに割り当てるように構成される。これらのリソースは、それ自体では低い計算能力を有し、したがって、タスク全体を個々のノードに割り当てる素朴なシステムでは未使用になる可能性がある。課題は、要求されるタスクを実行するのに十分な処理能力を全体として提供するように、これらのわずかな過剰容量を活用できるシステムを設計することにあるはずである。たとえば、このシステムを、信号の分散並列処理を引き受け、分散（クラウド）コンピューティング・リソース、ストレージ・リソース、およびネットワーキング・リソースを最適に利用するように構成することができる。リソースの１つの領域またはクラスタ内の過剰能力を並列処理で利用することができ、処理ステップを間に合って行うことができ、依存する処理ステップが進行できるように、そのような処理を調整することに、技術的課題が生じる。
【0105】
ビデオ／媒体コンテンツ処理の文脈では、これらのタイプの信号が、一般に既知の処理要件を有する可能性があり、それぞれが特定の特性および要件を有する複数の部分（たとえば、オーディオ、ビデオ、オーバーレイ、キャプショニング、メタデータ）に分割され得るので、特定の利点が入手可能である可能性がある。
【0106】
送信に関する既知の許容できるおよび／または導入される遅延レベル（たとえば、検閲組織が生テレビジョン放送から「罵り言葉」を除去できるようにするために実施される５秒日）がある可能性があるので、並列処理は、他の形では計算的に不可能であるはずの信号の後処理（たとえば、アーティファクト除去、オーバーレイの追加、変形処理）にこれらの既知のおよび／または導入される遅延レベル（たとえば、５秒の遅延）を利用することができる。リソースが制約される場合に、通信ストリームを利用して、過剰容量を利用し、かつ／または処理のために追加容量をプロビジョニングすることができる。いくつかの実施形態では、検察に関する潜在的に処理的により重いシナリオ／代替のシナリオが可能である場合がある（たとえば、生放送での意図されない裸体または暴力的コンテンツに関して、犠牲者をぼかすか、覆面捜査官／兵士のアイデンティティを隠す）。これらの例に示されているように、必要になる前に処理（検閲）の潜在的要件を識別することは、必ず可能とは限らない。したがって、いくつかの実施形態で説明される処理遅延は、割り振られたコンピューティング・リソースが、自動化された識別（たとえば、ニューラル・ネットワークまたは検閲要件を識別する役割を与えられた個人を介する）および／または遅延持続時間中に提供される機会中の検閲（たとえば、検閲がプロセッサ集中型であり、たとえば、モザイク処理、変更／フィルタ／効果の適用を必要とする場合がある）を行う時間を与えるので役立つ。
【0107】
分散リソースおよび／または動的にプロビジョニングされるリソースに関する負荷使用量を判定する際の潜在的要因は、作業へのリアルタイム制約／締切期限の追加である。作業を使用可能なノードの間で分割する時に、作業は、完了時刻がそれでも締切期限を満足する形で割り当てられなければならない。
【0108】
一実施形態では、ショット前選択／切替（たとえば、「低品質プレビュー」方法が提供される場合に、本明細書でさらにより詳細に説明される品質プレビュー）に利用され得るシステムが提供される。ショット前選択／切替を、仮想化された構成要素の第１のセットを使用して提供することができ、ショット後処理を、仮想化された構成要素の第２のセットを使用して提供することができる。要求される時間の長さとショット前選択／切替およびショット後処理に関して要求される各コンテンツ・ストリーム内で要求されるコンテンツ品質のレベルとに依存して、待ち時間的制約および／または帯域幅制約を有利に利用して、その後にショット後処理に適用される命令セットのカプセル化に関するショット前選択／切替での編集判断を同時に提供することができる。
【0109】
低品質のビデオ、オーディオ、および／またはメタデータの使用を介するショット後選択処理の並列処理を利用して、「クラウド内」にあるものとすることができるエディタ／プロセッサを使用することによって、品質を維持しながら待ち時間を短縮することができる。いくつかの実施形態では、ショット前編集およびショット後処理の一方または両方を、「クラウド内」で行うことができる。
【0110】
この例では、フル処理／編集ツールによって編集され、処理される、より早く到着する低品質ストリーム構成要素のセットは、ルータと他のクラウド編集ツールとの間のトラフィックおよび待ち時間を除去する（フル・レート・ビデオをユニットからユニットに移動させないことによって）、（その後に）ルータを介して渡される時に高品質ストリームを操作するはずのプロセッサに戻って供給され得る圧縮された命令セットを提供することができる。
【0111】
したがって、限られたリソースをより効率的に利用することができ、計算機構を介して、データの編集および処理を行うのに待ち時間／データ送信時間を利用することができる。仮想化された構成要素を、所与の１つ以上の局に関するセットされた番組制作スケジュールに従うためのストリームの配信のバッファリングまたは他の形での管理など、他の特徴のために利用することもできる。たとえば、そのようなシステムは、待ち時間（たとえば、ネットワーク制約によってもたらされる）、遅延（たとえば、検閲に十分な時間をもたらすため）、要件、および／またはネットワーク輻輳パターン（たとえば、プライムタイムまたはピーク時間中の）が既知である場合に有益である可能性がある。これらの組込み遅延は、分散コンピューティング・リソースを使用する並列化（たとえば、パイプライン化）の機会を提供する。
【0112】
本出願人は、米国特許出願第１４／３２９１１２号および米国特許出願第１５／０９５００２号を含む、媒体データ処理に関する複数の特許出願をも出願済みである。これらの特許出願は、参照によって本明細書に組み込まれている。
【0113】
いくつかの実施形態では、待ち時間を事前にセットされた値とすることができ、この場合に、様々な処理アクティビティ、たとえば、ビデオ編集、サウンド編集、ピクチャへのオーバーレイの追加などは、その事前にセットされた長さの時間内に実行されなければならない。
【0114】
いくつかの実施形態では、待ち時間は、ソースからクラウドへの送信時間の測定されたもしくは推定された待ち時間、クラウドベースもしくは局ベースの処理エンジンとスマート・ルータとの間の送信時間の測定されたもしくは推定された待ち時間、またはビデオの処理（機械または人間による）に必要な推定時間、あるいはこれらもしくは他の要因の任意の組合せなどの変数を使用して計算される値とすることができる。
【0115】
いくつかの実施形態では、低品質プレビュー・ストリームを、ビデオのみ（いくつかの他の実施形態ではオーディオのみ）とすることができる。別の実施形態では、低品質プレビュー・ストリームは、オーディオ、ＧＰＳ座標、ショットに関するメタデータ（タイムスタンプ、インタビューされる人に関する情報などのショットのコンテキストを提供するテキスト）、その他など、異なる種類の複数のストリームを含むことができる。
【0116】
いくつかの実施形態では、処理および編集は、サブタイトルの追加（たとえば、クローズド・キャプショニング、説明、多言語サポートのための）、グラフィカル・スコアボードの追加（たとえば、スポーツ・ゲーム、政党大会統計に関する）、グラフィカル・アイコンの追加（たとえば、ロゴ、チャネル指定、ブランディング要素）、広告の追加（たとえば、バナー、広告コンテンツ）、オーバーレイの追加（たとえば、分割スクリーン、マスク）、および検閲（たとえば、単語を「ピー」という音で消す、随伴者に「モザイクをかける」）のうちの少なくとも１つを含む。配置のための区域（たとえば、座標、関心領域）の識別は、最良の位置がどこであるのかが先験的に既知ではない場合に、特に計算集中型であり、最良の位置は、オンデマンド・ベースで識別される必要がある（たとえば、アメリカン・フットボールのスクリーン上にファースト・ダウン・ラインを描く）。
【0117】
画像／物体／音声認識（通常はセキュリティ／監視の文脈で使用される）が、計算的に複雑な処理機能の例である。解決策は、粗粒度物体認識ノードに低品質プレビューを送ることによってこれらのプロセスをより効率的にすることとすることができ、その後、この粗粒度物体認識ノードは、選択された関心領域に関するヒント（時間的にまたは空間的にのいずれか、たとえば、ファースト・ダウン・ラインが座標Ｘ１，Ｙ１－Ｘ２，Ｙ２の付近でなければならない）を返すことができる。その後、これらの領域の高品質バージョンを、より詳細な分析／認識のために他の処理ユニットに送ることができ、これは、減らされたデータ送信の必要およびコストをもたらすことができる。画像認識は、たとえば、最終的な出力ストリームからの除去のための、競合製品による製品配置、裸体、その他を識別しまたは確率的に推定するのに使用され得る。
【0118】
処理および編集の一部が、ソース・ストリームに対する計算集中型の変更を必要とする場合があり、たとえば、処理および編集の一部が、データの変形および／またはフィルタの適用を含む場合がある。たとえば、「ｄｉｆｆｅｒｅｎｃｅ ｏｆ Ｇａｕｓｓｉａｎｓ」手法をエッジ検出に使用することができ、ピクチャを飽和させ／飽和除去し、雑音追加／雑音除去し、特徴鮮鋭化／強化するなどが可能である。特定の所望の出力信号に応じて、トランスコーディング、再符号化、アップ・コンバート、ダウン・コンバートに関する処理および編集がある場合もある。
【0119】
したがって、いくつかの実施形態で説明するように、分散リソースを使用して処理されるストリームに関する処理特徴および編集特徴の一部またはすべては、分散リソースおよびシステム／ネットワーク待ち時間の性質をより効率的に利用し、電子コンテンツ処理システムの機能を改善する技法および手法を使用して、有利に実行され得る。
【0120】
たとえば、クラウド・エディタは、優勢な条件に適する（たとえば、最もよく適する、または最適化に基づいて適する）ために、ある頻度またはイントラコーディングされたピクチャ・フレーム（Ｉフレーム）の特定のリストのいずれかを用いる、無限のＧＯＰ（グループ・オブ・ピクチャ）ストリームへの１つ以上のＩフレームの挿入を要求することができる。いくつかの実施形態では、挿入は、人間の編集者によって指示され、他の実施形態では、アプリケーション自体による自動化された手法が利用される（たとえば、エディタと送信器との同期を試みる）。Ｉフレームおよび他のタイプの制御フレームは、たとえば、システムの様々な構成要素の間の正しい同期を保証するのに使用され得、いくつかの実施形態では、プレビュー・ストリームと前処理されたストリームとの間としてソース・ビデオ・ストリームの対応するフレームの間の時間シフトの差をシステムが追跡できることを保証するのに有用である。
【0121】
挿入は、プレビュー・ストリームまたは前処理されたストリームのいずれかに関して発生することができる（たとえば、編集者が時刻ｘ、ｙ、およびｚでのエディット・イン／アウトを望むので、これらの時刻にフル・ストリーム上で前処理されたものを送ってください）。代替の例では、このシステムは、システムが帯域幅を節約するか所望の前処理された部分のより良い品質を可能にするように構成されるのでシステムがＩフレームを望まないので、制御信号の形で「ｘとｙとの間にＩフレームを送信するなと示すことができる）。
【0122】
図１は、いくつかの実施形態による、テレビジョン調整室またはスタジオを介するビデオのシステムの例の概略図である。
【0123】
システム１００は、ビデオを処理するインハウス・システムとして提供され得、たとえば、ソース信号を供給する一連の構成要素１０２を含むことができ、ソース信号は、その後、内部ＳＤＩルータ１０４にルーティングされ、内部ＳＤＩルータ１０４は、ストレージ１０６上に情報を保存し、記憶し、または再生するように構成される。
【0124】
追加のグラフィックスおよびパッケージの送出１０８は、ＳＤＩルータ１０４とインターフェースすることができ、ＳＤＩルータ１０４は、コンテンツを処理し、さらに、構成要素１１０を介する出力のために信号を準備するために１０２から入手したソース材料を処理することができる。提供される構成要素１１０は、たとえば、とりわけ、広告、クローズド・キャプショニング、局グラフィックスのプロビジョニングを含むことができる。
【0125】
通常、このシステムは、接続の間のわずかな待ち時間を有するが、使用可能なコンピューティング・リソースの量によって制限もされる、オンサイト・データ・センタの形で提供され得る。さらに、ネットワーク帯域幅およびストレージが制限される場合がある。構成要素１０８および１１０は、ＳＤＩルータ１０４の処理能力の量によっても制限され、ＳＤＩルータ１０４は、通常は固定された地理的領域に配置される。
【0126】
たとえば、あるタイプの処理が、特定の時間枠（たとえば、信号遅延に起因して１秒）以内に要求される場合に、ＳＤＩルータ１０４は、構成要素１１０を介して出力を供給することを強制される前の１秒の時間枠の下でできる限り多く計算することだけができるという点で、使用可能なリソースによって制限される。
【0127】
図２Ａは、いくつかの実施形態による、様々な処理アクティビティに関するクラウドベースの機構を介するビデオまたは他のデータのための代替システムを示す例の概略図である。
【0128】
代替の分散リソース機構は、たとえば、多様な機能的特性、地理空間的特性、および／またはネットワーキング特性を有する異なるコンピューティング・リソースの間でタスクを割り振り、他の形でプロビジョニングする能力を含む、図１の実施態様に対する大幅な改善を提供することができる。
【0129】
リソースは、選択的に「スピン・アップされ」または「スピン・ダウンされ」（たとえば、割り当てられ、プロビジョニングされ、ブートされ、予約され）得、いくつかの場合に、予約され、「スポット」ベースで供給されまたは「オン・デマンド」ベースで供給され、異なるコスト要因および可用性要因を有することができる。リソースの固定されたセットを使用するのではなく、要求される総処理時間／コストを削減しまたは管理するために、時間シフトおよび時間的制約を有利に使用できるように、プレビュー・データ・ストリームおよび前処理されたデータ・ストリームのうちの少なくとも１つに関連する様々なタスクを実行するためにオンデマンド・リソースを知的に割り当てることができる。
【0130】
システム２００は、「クラウド」の形で図示された構成要素のそれぞれが、ネットワーク化されたコンピューティング・デバイスの分散されたセットとして提供される、分散リソース・ベースの実施態様として図示されている。ソース信号２０２を供給する一連の構成要素、ストレージ２０６にデータを記憶するスマートスケジューラ／ルータ２０４、グラフィックス構成要素／パッケージの送出構成要素、および効果構成要素２０８、ならびに信号処理構成要素２１０があるものとすることができる。信号処理構成要素２１０は、たとえば、マスタ制御スイッチャ、広告プレイヤ（広告データベースに動作可能に接続され得る）、送出サーバ、クローズド・キャプショニング・プロセッサ、および局グラフィックス・エンジンを含むことができる。他の構成要素２１０が可能であり、上記は、例として提供される。データベース２０５は、たとえばクラウドと処理ユニットとの間（または処理ユニットの間）の待ち時間を追跡し、かつ／または予測するのに使用されるレコードを記憶するために設けられ得る。他のタイプのデータ・ストレージ（たとえば、リレーショナル・データベース、非リレーショナル・データベース、フラット・ファイル、リンク・リスト）が可能であり、データベース２０５は、例として示されている。
【0131】
システム２００の基礎をなす特定のコンピューティング構成要素は、たとえば、複数のユーザおよび／または使用および／または位置にまたがって負荷平衡化される、使用可能なリソースのプールの形で提供されるコンピューティング・リソースとすることができる。これらの使用可能なリソースは、たとえば、ウェブ・ホスティング、暗号通貨マイニング、データ・センタ、バイオインフォマティクス処理などに使用されるプロセッサなど、ビデオ／媒体処理とは別個のタスクと共に「クラウド内で」共有され得る。
【0132】
システム２００の構成要素の間で確立される通信ストリームがあり、基礎になるコンピューティング構成要素の地理に応じて、特に使用されている分散リソースが地理的な距離および領域にわたる場合に、システム１００に対する相対的な、ネットワーク／システム特性の相違（たとえば、待ち時間、帯域幅、および伝搬時間）がある場合がある。この形でネットワークをブレンドすることによって、システム２００は、アプリケーションを意識したネットワーキングを提供するように構成される。たとえば、基礎になる処理タスクまたは目的に対する重要性および致命度に基づいて様々なコンテンツ・ストリームに関連する優先順位レベルを上げまたは下げるようにコントローラを構成することができる。
【0133】
より高価なネットワーキング・リンクを、これらの目的などのために予約することができ、いくつかの実施形態では、システム２００は、処理時間を増加させた予想外の処理問題（たとえば、より高価なリンクが補償機構として利用される）にもかかわらず、識別／全体的な処理を特定の時間枠内に（たとえば、時間的制約以内に）行えるように、より高価であるがより高スループット／短待ち時間のネットワーキング・リンクを活用するように設計される。
【0134】
図２Ｂは、いくつかの実施形態による、スマートスケジューラ／ルータ２０４の構成要素を示す例のブロック概略図である。
【0135】
図示されているように、スマートスケジューラ／ルータ２０４は、ストリーム・コントローラ２５０を有することができ、ストリーム・コントローラ２５０は、様々な目的が満足されるように様々なストリームからのデータの流れを管理するように構成されたコンピューティング・デバイスである。ストリーム・コントローラ２５０は、ビデオ・ソースから受信されるストリームを制御し、または、プレビュー・ストリームおよび／もしくは前処理されたストリームがどのように生成されるのかを変更することができる。
【0136】
いくつかの実施形態では、ストリーム・コントローラ２５０は、プレビュー・ストリームおよび／または前処理されたストリームの対応するフレームでの相対時間シフトを確立できるように、プレビュー・ストリームおよび／または前処理されたストリームの符号化を変更すること制御信号を送るフィードバック経路を含む。いくつかの場合に、固定された時間シフト（たとえば、対応するフレームが５秒離れている）が維持され、他の場合には、時間シフトの相違が許容される。ストリーム・コントローラ２５０は、ストリームにタイムスタンプを供給し、いくつかの実施形態では、キーフレームまたは他のタイミング特徴をフレーム内に挿入し、その結果、プレビュー・ストリームおよび／または前処理されたストリームの対応するフレームを識別できるようにする。
【0137】
一貫したタイミングの維持は、調整の消失がシステム性能に対する重大な影響になり得る（たとえば、クラウド・リソースの調整およびその予約が調整不良になる可能性がある）ので、特に重要である可能性がある。
【0138】
ストリーム・コントローラ２５０は、ソース特性監視エンジン２５２、処理要件特性監視エンジン２５４、分散リソース監視エンジン２５６、ネットワーク特性監視エンジン２５８、出力品質監視エンジン２６０、クロック同期化ツール２６２、およびフレーム同期化ツール２６４と相互運用することができる。
【0139】
これらの目的は、トリガ、条件、論理ルールなどの形で提供され、ソース特性監視エンジン２５２、処理要件特性監視エンジン２５４、分散リソース監視エンジン２５６、ネットワーク特性監視エンジン２５８、および出力品質監視エンジン２６０のうちの１つ以上から受信される監視された信号条件をストリーム・コントローラ２５０が素早くトリアージし、処理することを可能にする命令セットに変換され得る。
【0140】
ソース特性監視エンジン２５２は、たとえばビットレート、許容できる遅延の量（存在する場合）、コンテンツのタイプ、要求される処理などを含むソース信号の特性を追跡するように構成される。処理要件特性監視エンジン２５４は、要求される処理を追跡し、要件を分散処理の要求に解析するように構成され得る。
【0141】
処理要件は、前処理されたストリームの処理に限定されるのではなく、制御デバイスでの識別タスクに関して要求される処理をも含む（たとえば、関心領域の識別、前処理されたストリームのダウンストリーム処理に関する命令セットの生成）。
【0142】
分散リソース監視エンジン２５６は、リソースが処理に使用可能であるかどうか、そのスケジューリングされた作業負荷、その地理空間的距離、その「仮想」距離、リソースが追加のプロビジョニング／プロビジョニング解除時間を必要とするかどうかなどを含む、分散リソースの現在の状態を追跡する。
【0143】
ネットワーク特性監視エンジン２５８は、様々な通信ストリームおよび／または通信リンクに関する待ち時間、パケット消失、サービス品質、使用可能な帯域幅などを監視するように構成され、出力品質監視エンジン２６０は、出力を指定された持続時間内に供給できたかどうかを含めて、出力が処理判断基準を満足するかどうかを判定するために、処理された出力を追跡するように構成され得る。
【0144】
したがって、ソース信号２０２は、データ・ストリームのリモートな処理（またはそのルーティング）のために構成され得るスマートスケジューラ／ルータ２０４との通信のために少なくとも２つのデータ・ストリームを供給する送信器から供給され得る。１つ以上の送信器があってもよく、各送信器は、オーディオ・データおよび／またはビデオ・データを含むデータ信号を供給する。いくつかの実施形態では、送信器は、単一のコンテンツ・ストリーム（たとえば、ビデオ・ソースからの）からデータ・ストリームを生成する符号器を含む。ビデオ・ソースは、たとえば、ニュース・サイト、スポーツ・イベントなどからの生送信とすることができ、ビデオ・ソースにおいて特定の解像度およびビットレートで取り込まれ得る。
【0145】
しかし、ビデオ・データは、ビデオ・ソースからのフル・レートの生データの送出が、とりわけ使用可能な帯域幅または送信スループットの制限に起因して実行不能である場合があるので、圧縮／他のタイプの処理および変形を必要とする場合がある。いくつかの実施形態では、送信器は、同一のソースからの複数のストリームを生成する、並列に動作する２つの符号器など、１つ以上の符号器を含み、複数のストリームは、異なる特性を有する（たとえば、第１の「プレビュー」ストリームは、大幅に下げられたビットレートを有し、第２の「フル・レート」／放送品質の前処理されたストリームは、より高いビットレートを有する）。異なるストリームを、異なるプロトコルおよび／またはトランスポート・コンテナを使用して符号化／トランスコーディングすることができる（たとえば、プレビュー・ストリームは、ｓｔａｇｇｅｒｅｄ ｊｐｇ画像のストリームであるが、前処理されたストリームは、動き圧縮／予測コーデックを使用して圧縮された、生成されたｍｐ４ストリームである）。
【0146】
異なるストリームが、符号化のために要求される処理に起因して、異なる出力時間を有する場合があり、異なる出力時間は、２つのストリームの間の遅延の自然な源である可能性がある。他の実施形態では、追加の遅延が、ストリームの間の時間的間隔をさらに追加するために、ストリームの間に注入されまたは他の形で追加される。この遅延時間は、様々な実施形態で説明されるように、たとえば編集者または自動化された編集デバイスが、プレビュー・ストリームを見、命令を送るか、エンドポイントに供給する前にフル・レート・ストリーミングに対して効果を他の形で発生させることによって、追加の処理および／または編集が発生することを可能にすることができる。たとえば、とりわけ、様々な視覚効果を追加することができ、望ましくない要素を除去することができ、単語または他の情報を編集しまたは検閲することができる。
【0147】
いくつかの実施形態では、符号化パラメータを変更する（たとえば、スケーリングする）ことによって遅延持続時間を管理できるように、スケーラブル符号器が、ストリームのうちの少なくとも１つに関して使用される。たとえば、スケーラブル符号器は、少なくとも２つのデータ・ストリームの解像度に比例するコーディング遅延を供給するように構成され得る（たとえば、４８０ｐストリームおよび１０８０ｐストリームの生成は、ストリームが異なるタイミングを有することを引き起こす）。そのような例では、より多くの時間が送信器での処理のために使用可能なので、人工的に追加された遅延持続時間さえもが、有益な符号化結果を得るのに使用され得る。
【0148】
２つ以上のストリームが、送信器によって同時に生成されるが、符号化時間の相違および／または任意の他の遅延機構（たとえば、バッファ）の実施態様が、２つ以上のストリームのそれぞれの中で生成されるフレームの相対タイミングの間の遅延を確立する場合がある。いくつかの実施形態では、ダウンストリーム・コンピューティング・デバイスが、ストリームを受信し、ストリームおよび／または各ストリームの現在のフレーム・シーケンスの間の遅延の量を判定できるように、送信器および／または符号器は、ストリームおよび／またはそのフレームにタイムスタンプを付け、かつ／またはメタデータ識別子（たとえば、ヘッダ情報）を他の形で追加するように構成される。様々な実施形態で説明するように、相対タイミングおよびフレーム同期は、ダウンストリームの処理構成要素および／またはルーティング構成要素による調整された処理を保証する上で重要である可能性がある。いくつかの実施形態では、メタデータおよび／または他の同期情報は、送信器および／または符号器からの別々のメタデータ・ストリーム内で供給され、メタデータ・ストリームは、たとえば、タイムスタンピング、調整を助け、符号化タイプ、使用されたコーデック、時間的制約、その他などの他の情報を示す。
【0149】
いくつかの実施形態では、送信器は、ダウンストリーム構成要素へのデータ・ストリームの送信を制御するのに利用される１つ以上のルーティング構成要素を含み、たとえば、ルーティング構成要素は、たとえばデータ・ストリームの送信のための１つ以上の通信リンクの優先順位を上げ、優先順位を下げ、待ち時間を導入し、待ち時間を短縮し、スループットを高め、その他のためにネットワーキング・パラメータを変更するように構成される。したがって、個々のストリームの間の相対遅延を、送信器のルーティング・ネットワーキング構成要素を介して送信器から導入することもできる。
【0150】
その後、スマートスケジューラ／ルータ２０４は、既知の制約（たとえば、時間しきい値、使用可能なリソース）および監視された特性（たとえば、コンピューティング・デバイスの間の接続に関するネットワーク輻輳）に従って、処理、編集、その他を実行するために様々なコンピューティング・デバイスを管理するために、所望の送信特性を識別し、制御信号を生成することができる（たとえば、処理開始時刻、所望の処理終了時刻、消費されるリソースの量）。
【0151】
いくつかの実施形態では、スマートスケジューラ／ルータ２０４は、たとえば、ストリーム・ソースに命令信号を送ること（たとえば、どのストリームを選択すべきか、ソース・ストリーム特性の変更、異なるコンピューティング・リソースへのルーティングを示すために）、その他を含む、着信ストリームのトラフィック・フローを管理するように構成される。したがって、スマートスケジューラ／ルータ２０４は、エッジ・ノードを制御し、ダウンストリーム・コンピューティング構成要素へのルーティングに関する情報をスケジューリングし、カプセル化し、変形するように構成される。分散リソースが利用される場合に、スマートスケジューラ／ルータ２０４は、単純に、様々なコンピューティング・タスクに関する割当または予約に使用可能な様々な性能および／または他の特性を有するノードとして、すべての分散リソースを定義するように構成され得る。
【0152】
優先順位付けを、異なるネットワーキング構成要素の間で確立して、確立された遅延期間内のコンテンツの配信および／またはコンテンツの処理を保証するのを助けることができる。
【0153】
スマートスケジューラ／ルータ２０４は、物理的な局または仮想局での放送時間番組制作スケジュールに基づいてビデオを送り出すように構成されたバッファを利用するスケジューラ・デバイスを含むことができる。スマートスケジューラ／ルータ２０４は、実際の遅延および期待される遅延を追跡し、いくつかの実施形態では、ある時間期間にわたって性能および遅延持続時間を監視するためのローカル・ストレージを含む。期待される遅延および実際の遅延がお互いにより密に追跡するのを助けるために制御フィードバック・ループ機構を継続的にまたは周期的に提供するために、パターン認識法を利用することができる。たとえばＰ、ＰＩ、ＰＩＤ、または他のタイプの制御フィードバック・トポロジを、ビデオ処理効果を実行するための追加時間を提供する目的で挿入される人工的な遅延に関連する誤差値を減らすことに関連して利用することができる。
【0154】
さらに、スマートスケジューラ／ルータ２０４は、様々なコンピューティング・デバイスをアクティブ化しかつ／または非アクティブ化し、プロビジョニングしかつ／またはプロビジョニング解除し、構成しかつ／または再構成する制御信号を生成するようにも構成され得る。たとえば、デバイスが、使用の前に「スピン・アップされ」または「スピン・ダウンされる」のに時間を必要とする場合があり（たとえば、ハード・ディスク・ドライブは、動作状態になる前にある時間期間を必要とする）、いくつかの実施形態のスマートスケジューラ／ルータ２０４は、処理が要求される時にこれらのコンピューティング・デバイスの準備ができるようにこれらを制御することによって、これらのコンピューティング・デバイスのアクティビティをオーケストレーションすることができる。使用の前のデバイスの正しい初期化の保証は、導入された遅延機構によって割り当てられるものより長い時間を処理が要求する可能性を減らすのを助ける。
【0155】
たとえば、ストリーム・コントローラ２５０を、特定の必要に関して使用可能なリソースからリソースの最適のまたは優れたセットを判定し、かつ／または識別するように構成することができる（すべての使用可能なリソースが同等とは限らないので）。たとえば、ルーティングは、とりわけ、様々なソースおよび宛先のビジネス・ルールの適用に基づくものとすることができる（たとえば、あるソースは暗号化される必要があり、ある処理ユニットは料金を支払えば使用可能であるなど）。経路最適化ツールは、たとえば、情報を受信し、その情報を使用してストリーム要素と最終的なピクチャとの両方の経路をプロットするために、適用され得る。
【0156】
いくつかの実施形態では、スマートスケジューラ／ルータ２０４は、処理および編集の過程で異なる経路をたどる可能性がある少なくとも２つの異なるデータ・ストリームを管理するように適合される。
【0157】
様々なプレビュー・ストリームを受信し、処理ユニットまたは宛先の要求するものに応じて、それらを結合解除し（ｄｅ－ｂｏｎｄ）（着信ソースが結合されている場合）、またはそれらを異なる（一つまたは複数の）フォーマットに再符号化する、復号器（またはトランスコーダ）ユニットを設けることができる。ストリームの結合および結合解除は、それぞれが参照によって本明細書に組み込まれている、米国特許出願第１２／４９９１５１号（米国特許第８８７３５６０号を含む）および米国特許出願第１４／３４１０５７号に記載されている。
【0158】
データベース２０５は、たとえばクラウドと処理ユニットとの間（または処理ユニットの間）の待ち時間を追跡し、かつ／または予測するのに使用されるレコードまたはデータ構造を記憶するのに利用され得る。たとえば、タイムスタンプ付きのまたは時間符号化されたデータ・レコードを維持することができる（たとえば、開始時刻、期待される停止時刻、実際の停止時刻、遭遇した誤り）。このデータをさらに処理して、デバイスに関する、処理機能性またはネットワーク機能性における識別可能なパターン（たとえば、デバイスの年齢、運転時間、ピーク時間中のネットワーク輻輳）などの性能メトリックを入手することができる。
【0159】
統計（たとえば待ち時間から導出され、たとえば標準偏差、相関、スキュー、分布プロファイル、分散を含む）が収集され、どの一つまたは複数の接続上でデータを送るべきかまたはどの編集デバイスを使用しまたは除外すべきかに関する性能（および分散）ベースの判断を行うために分析されるように、データベース２０５を構成することができる。
【0160】
たとえば、データベース２０５は、あるユニットでの「待ち時間」を追跡するために維持されるレコードを含むことができる（たとえば、自動的にまたは人間の介入を伴ってのいずれかで、処理にどれだけの時間を要するか（１５秒のクリップにおいて、編集者が、システムの残りに戻ってこれを吐き出す前にこれを処理するために ３０秒を要する可能性があり、または、単語が話されることとトランスクリプションが発生することとの間に余分な５秒間クローズド・キャプション・システムを占有するので））。いくつかの実施形態のデータベース２０５は、ネットワーク接続の追跡と、通信に関してネットワーク接続を含め、変更し、または除外する能力とを含む。通信の特性を知的に変更する能力は、特定の接続を選択する能力と組み合わされて、本制御機構が全体的な処理時間を補償しまたは他の形で丁度いいサイズにするための改善されたレベルの柔軟性をもたらす。
【0161】
たとえば、処理が、期待より長い時間を要する（たとえば、使いすぎに起因してビデオ・カードが予想外に障害を発生する）場合に、データベース２０５は、たとえば、そうでなければ遅延される命令を処理ユニットに転送するためにより高速の（たとえば、潜在的により高価な）ネットワーク接続を使用することによる、時間補償の可能性を識別するために、スマートスケジューラ／ルータ２０４によって利用され、トラバースされる。したがって、いくつかの実施形態では、スマートスケジューラ／ルータ２０４は、検出された遅延（たとえば、プレビュー・ストリーム上での処理命令の生成は、他の点で時間的制約に含まれない）に応答して、時間の損失を保証するために変更され得る１つ以上の潜在的なネットワーキング要因（またはその組合せ）を識別するためにデータベース２０５をトラバースするように構成され得る。
【0162】
時間補償機構は、時間的制約が満足されることに致命度がある応用例で有用である。たとえば、いくつかの状況で、時間的制約は、ダウンストリーム・システム依存性に起因して課せられる。
【0163】
その後、スマートスケジューラ／ルータ２０４は、一連のルーティング・オプションを生成し、最適化された要因（たとえば、適当な安全クッションを提供しながらの最低コスト）に基づいてオプションを選択し、その後、信号を再スケジューリングし、再ルーティングし（たとえば、新しいネットワーキング・リソースを要求し）、その結果、処理が、時間的制約内で発生するようになる。たとえば、そうでなければ範囲外のタイミング値が期待される時の使用のために、より高い優先順位の回線を一時的に再割振りすることができる。
【0164】
クロック同期化ツール２６２を設けて、待ち時間を様々なクラウド処理ユニットの間で正しく追跡でき、測定できることを保証することができる。フレーム同期化ツール２６４は、１つ以上のフレーム（たとえば、最後のフレーム）を同期状態に保つために設けられ得る。ストリーム処理ユニット２６６（「ヘッドレス処理ユニット」）は、様々な処理ユニットから来る命令セットに基づいて１つ以上のストリーム（たとえば、フル・レート／放送の準備ができたストリーム）に対してある種のアクションを実行するように構成され得る。ストリーム処理ユニット２６６は、応急処理のために構成され、いくつかの実施形態では、低水準データ命令の受信および実施のために最適化される（たとえば、メモリ使用を改善するための低水準最適化は、強度低減置換、不変コードの識別を引き起こし、限られた個数の使用可能な命令だけに命令セットを制限する）。
【0165】
処理ユニットは、たとえば、様々な宛先への最終的な符号化に利用される符号器を含むことができる。いくつかの実施形態では、米国特許出願第１５／０９５００２号に記載されたものに類似するマルチポイント符号器を設けることができる。たとえば、符号器が、エンドポイントに１対１で信号を提供している場合があるが、送信が、積み重ねられ符号器の形でも提供され得るなどである。
【0166】
図２Ｃは、いくつかの実施形態による、第１のデータ・ストリーム２８２および第２のデータ・ストリーム２８４と相互運用するスマートスケジューラ／ルータ２０４の図である。いくつかの実施形態では、第１のデータ・ストリーム２８２および第２のデータ・ストリーム２８４は、通信ストリームのバンドルまたはセットを表す。たとえば、少なくとも２つのデータ・ストリーム２８２および２８４は、少なくとも（１）より低品質のプレビュー・ストリーム２８２および（２）より高品質のコンテンツ・ストリーム２８４を含むことができる。
【0167】
複数のエディタ・コンピューティング・デバイス２００２を、少なくとも１つの送信器からリモートに配置することができ、各エディタ・コンピューティング・デバイス２００２は、少なくとも、プロセッサおよび非一時的コンピュータ可読メモリを含む。
【0168】
複数のエディタ・コンピューティング・デバイス２００２は、少なくとも、より低品質のプレビュー・ストリーム２８２を受信するように構成され、複数のエディタ・コンピューティング・デバイス２００２は、より低品質のプレビュー・ストリームの処理および編集を容易にするように構成され、処理および編集は、処理および編集を表す機械可読命令のセット２１００を生成するのに使用される。
【0169】
このシステムは、編集命令を２つの主要なカテゴリすなわち時間および空間にセグメント化するように構成され得る。時間編集コマンドは、たとえば、カットまたは保存のいずれかを行うべきビデオのオフセットを示す、［開始，停止］時間オフセットの対を含むことができる。空間編集は、たとえば、［フレーム番号，コマンド］の形の対を含むことができ、コマンドは、クロッピング、サイズ変更、パディング、ぼかし、合成、オーバーレイ、その他などの一般的な画像操作とすることができる。
【0170】
順次処理対並列処理に関して、並列は、編集待ち時間を編集待ち時間１＋編集待ち時間２＋…編集待ち時間ＮではなくＭａｘ（編集待ち時間１，編集待ち時間２…編集待ち時間Ｎ）に低減できるという意味で、順次より潜在的に有利である可能性がある。クラウド・リソースの使用に関して、潜在的な利点は、編集待ち時間をさらに低減する、調整室内より強力なクラウド内のリソース（より強力なコンピュータまたはソフトウェア・ツール）の使用である。同様の利益を、「送信待ち時間１…Ｎ」の文脈で獲得することができるが、さらなる複雑化がある可能性がある。というのは、個々の待ち時間が、各要素に関して、伝統的な調整室内より長くなる可能性がある（かつ、そうなる可能性が高い）からである（したがって、送信待ち時間の低減対並列性が、より長い個々の待ち時間によって、および潜在的に、編集を最後に最終的なピクチャに再組立しなければならないことによって引き起こされる追加の編集待ち時間によって、克服され得る）。
【0171】
より低品質の（したがって潜在的により短い待ち時間の）ストリームをエディタに送ることによって、このシステムは、直接に（より少ないデータが送られ、おそらくは誤りに対処するために必要なより短い時間につながる）またはより短い待ち時間、より小容量のネットワークを利用することによってのいずれかで、送信待ち時間（またはコストなど）を低減できる可能性がある。たとえば、より低コストのネットワークを選択し、待ち時間の利益を得ないものとすることもできる。特定の例として、このシステムを、より低品質のプレビューに関して短待ち時間／小容量のセルを使用し、フル・ビデオに関して長待ち時間／大容量／高信頼性の衛星を使用するように構成することができる。
【0172】
複数のルーティング・コンピューティング・デバイス２００４が設けられ、少なくとも１つの送信器からリモートに配置され、各ルーティング・コンピューティング・デバイスは、少なくとも、プロセッサおよび非一時的コンピュータ可読メモリを含む。
【0173】
複数のルーティング・コンピューティング・デバイス２００４は、少なくとも、より高品質のコンテンツ・ストリーム２８４および機械可読命令のセット２１００を受信するように構成され、複数のルーティング・コンピューティング・デバイス２００４は、出力コンテンツ・ストリームを生成するために機械可読命令のセット２１００に従ってより高品質のコンテンツ・ストリームを符号化することによって、より高品質のコンテンツ・ストリームを処理するように構成される。
【0174】
いくつかの実施形態では、複数の配信管理コンピューティング・デバイスが設けられ、配信管理コンピューティング・デバイスのそれぞれは、１つ以上のエンドポイントへの配信特性と１つ以上のエンドポイントへの出力コンテンツ・ストリームの送信とを決定するように構成される。
【0175】
複数のエディタ・コンピューティング・デバイスおよび複数のルーティング・コンピューティング・デバイスの一方または両方を、クラウド内のデータ・センタの形で設けることができる。データ・センタは、より低品質のプレビュー・ストリームとより高品質のコンテンツ・ストリームとの両方を受信するように構成され得、データ・センタは、受信されたデータ・ストリームを複数のエディタ・コンピューティング・デバイスと複数のルーティング・コンピューティング・デバイスとの間でルーティングするように動作可能なルータを含む。
【0176】
いくつかの実施形態では、処理命令のセットを、メタデータ・データ・ストリームの形で提供することができる。たとえば、メタデータ・データ・ストリームを、複数のエディタ・コンピューティング・デバイス２００２に供給し、機械可読命令のセット２１００の生成の際に処理することができる。
【0177】
いくつかの実施形態では、ストリーム・コントローラ２５０は、スケジューラ・コンピューティング・デバイスを含むことができ、スケジューラ・コンピューティング・デバイスは、対応する複数のエディタ・コンピューティング・デバイスおよび複数のルーティング・コンピューティング・デバイスへの少なくとも２つのデータ・ストリームの到着に関する送信特性を監視し、監視された送信特性に基づいて、たとえば信号の短待ち時間ブレンドを配信するためにネットワーク監視エンジンに通信するために、少なくとも１つのエンドポイントへの出力コンテンツ・ストリームを含むデータ・パケットの送信をスケジューリングするように構成される。
【0178】
編集を特定のタイムラインまでに完了しなければならないケースがある場合がある（たとえば、番組（原稿を読むニュース・アンカのスタジオ・ショットなど、クラウド内で生成／管理されるのではない他のコンテンツを使用している場合がある）に収めるためにある時点に達しなければならない場合の、事前に計画された放送。この場合に、スケジューラは、すべての要求される／要求された編集が発生することを保証するために着信ストリームの要素を管理するだけではなく、厳しい締切期限に合わせてそれらを管理してもいるはずである。依存性が、リンケージの形でタイムスタンプに基づいてデータベース２６０内で追跡され、遅延に出会う場合には、新たに更新された期待される時間枠に基づいて複数のコンピューティング・デバイスにまたがって命令セットを変更し、命令セット変更をカスケードするために、依存性リンケージをトラバースすることができる。
【0179】
番組制作スケジュールが流動的であり、締切期限が多少はより柔軟である（たとえば、生ビデオに関する特定のテキスト・オーバーレイの表現が「即座に」行われるかどうかが問題ではなく、それが「早く」行われることが問題である可能性がある）場合、または、締切期限が存在するが、かなり柔軟である、その後の放送のためにコンテンツが編集されている（したがって、スケジューラが、編集タスクの完了により長い時間を与えることができる）場合に、他のケースが存在する（たとえば、生のニュース速報の状況）。
【0180】
いくつかの実施形態では、ソース信号２０２は、ビデオ・ソースからの単一のコンテンツ・ストリームから少なくとも２つのデータ・ストリームを生成するように構成されたコンピューティング・デバイスを含む送信器を使用して供給され得、より低品質のプレビュー・ストリーム２８２は、リアルタイムまたは近リアルタイムで供給され、より高品質のコンテンツ・ストリーム２８４は、遅延（ストリームの符号化時間に固有である場合があり、またはシステムによって導入され得る）を伴って供給される。
【0181】
たとえば、超低品質ストリーム（たとえば、１００ｋｂｐｓまたは１ｆｐｓまたはなんらかの他の要素）が特定の編集ツールに十分であるが、「中」品質ストリーム（たとえば、１ｍｂｓまたは１５ｆｐｓまたはなんらかの他の要素）が他の何かのために必要である場合。いくつかの状況では、スケジューラは、編集ツールのすべてによって要求される最小品質（たとえば、Ｍａｘ［ｍｉｎ１，ｍｉｎ２，ｍｉｎ ｎ］）を送るために命令を生成するように構成され得るが、他の時には、追加のプレビュー・ストリームを作成することを選択することができる（たとえば、長い編集待ち時間を有するツールが低品質プレビューのみを要求する場合、または特定の瞬間に使用可能な唯一のクラウド・リソースがプレビュー・ストリーム内の特定の品質／待ち時間を要求する場合）。
【0182】
いくつかの実施形態では、スケジューラは、たとえば送信するデバイスが、制限された計算容量を有し、多数のストリームを作成しまたは送信することができない場合に、プレビュー・ストリームの個数を制限すると決定することができる。いくつかの実施形態では、この手法が、待ち時間目標に達するために管理される結合された接続に対して行われる必要がある場合がある。
【0183】
完全に異なるコンテンツ（たとえば、オーディオ、ビデオ、メタデータ）を含む複数のストリームがある場合がある。いくつかのシナリオでは、複数のオーディオ・プレビュー・ストリーム、複数のビデオ・ストリーム、その他、またはその任意の組合せがある（あるものはそのデータ・タイプの１つのストリームだけを送り、あるものはデータ・タイプごとに複数のプレビュー・ストリームを送る）。プレビューの個数が、ネットワーク容量によって制限される場合もある。システムは、「エッジ・ノード制御」を提供することができ、ここで、システムは、送信器を制御し、とりわけ、ネットワーク状態およびリソース状態に基づいて、データに関して行うべきこと、遅延、およびフレームレートなどに関する命令を供給する。
【0184】
図２Ｄは、いくつかの実施形態による、スマートスケジューラ／ルータ２０４によってオーケストレーションされたエディタ・コンピューティング・デバイス２００２およびルーティング・コンピューティング・デバイス２００４のセットのブロック概略図である。
【0185】
エディタ・コンピューティング・デバイス２００２は、たとえば、ルーティング・コンピューティング・デバイス２００４によって実行される処理命令のセットを生成する、制御デバイスとすることができ、ルーティング・コンピューティング・デバイス２００４は、エンドポイント（および最終的に消費者）へのプロビジョニングの前に、放送品質の第２のデータ・ストリーム２８４に対してオーディオ／ビデオ処理ステップを実行することができる。処理命令は、たとえば、ルーティング・コンピューティング・デバイス２００４が第２のデータ・ストリーム２８４から出力データ・ストリームを準備している時の処理（たとえば、スコアボードの描画、ブランディングの追加、注釈の提供）に関する、時間枠、区域または関心領域を示すことができる。
【0186】
いくつかの実施形態では、エディタ・コンピューティング・デバイス２００２は、たとえばルーティング・コンピューティング・デバイス２００４によって要求される処理の、高水準識別を行う際に計算的「重労働」を実行する。エディタ・コンピューティング・デバイス２００２が、準ライブ・アメリカン・フットボール・ゲームのファースト・ダウン・ラインを描く仕事を課される、非限定的な例では、エディタ・コンピューティング・デバイス２００２は、ファースト・ダウン・ラインを描かなければならない領域を自動的に識別する（ニューラル・ネットワークを適用することによって）ために、かなりのコンピューティング・リソースを含む可能性がある。ファースト・ダウン・ラインの描画は、技術的にむずかしく、いくつかの場合に、フィールドの３Ｄモデルが描かれ（その輪郭を含む）フットボールの位置が識別され、特にカメラが移動している場合に、カメラのパースが、遠近法効果を追跡するために判定されなければならないなどである。ファースト・ダウン・ラインが、プレイヤの上に描かれないことも必要であり、したがって、ラインは、様々なプレイヤの「下」に現れなければならない。
【0187】
エディタ・コンピューティング・デバイス２００２は、プレビュー・ストリーム２８２を使用してこの情報を処理し、ルーティング・コンピューティング・デバイス２００４に送信される命令セットを生成する。命令セットは、単純化され、変更のパラメータ（フレーム５０００～５５４４に座標点Ｘ１，Ｙ１とＸ２，Ｙ２との間の特定の太さの黄色いラインを描くが、黄色いラインは、プレイヤがラインをカバーするか他の形でラインを踏んでいる特定の他の座標領域には描かれない）を示す命令のベクトルまたはアレイを単純に含む。
【0188】
図２Ｄの例では、第１のデータ・ストリーム２８２および第２のデータ・ストリーム２８４は、より高品質の前処理する第２のデータ・ストリーム２８４を生成する際に導入される処理遅延の結果としての固有の遅延と遅延機構２０００２によって供給される導入された遅延との組合せである遅延持続時間Ｘを有する。いくつかの実施形態では、固有の遅延が、より高品質の第２のデータ・ストリーム２８４の特性の変更によってスケーリングされることも可能であり、送信器は、処理リソースの監視された可用性に基づいてスマートスケジューラ／ルータ２０４から制御信号を受信することができる。たとえば、より高品質の第２のデータ・ストリーム２８４の生成は、異なるタイプのコーデック、カプセル化／トランスポート・パッケージ、プロトコル、圧縮、動き予測、ビットレート、解像度、ヘッダ、制御フレーム、その他の選択および実施によって変更され得る。スマートスケジューラ／ルータ２０４は、遅延を追跡し（たとえば、遅延が、既存の符号化選択に起因してＹである）、処理遅延を実施し（たとえば、遅延が、スマートスケジューラ／ルータ２０４の選択された符号化選択に起因してＹになる）、または、遅延を固定する（たとえば、遅延が、固有の遅延Ｙと一緒にネットワーク遅延または他の遅延Ｚを変更することによって、事前定義の値Ｘに固定される）ことができる。
【0189】
アメリカン・フットボールの黄色いラインの例を戻って参照すると、黄色いラインは、第２のデータ・ストリーム２８４が符号化されている間に命令セットを生成する際により高速の第１のデータ・ストリーム２８２を使用して、他の形で可能なものより高速に描かれ得る。したがって、出力データ・ストリームは、ダウンストリームのフットボールを見る聴衆による消費のために、黄色いラインを追加するのに必要な最小限の時間だけを伴って、より高速に準備され得る。
【0190】
追加の遅延を、第２のデータ・ストリーム２８４とルーティング・コンピューティング・デバイス２００４との間のネットワーク接続を選択しまたは制御することによって、送信器またはスマートスケジューラ／ルータ２０４のいずれかによって導入することができる。たとえば、より低速でより高スループットの接続を選択することができ、より高速でより低スループットの接続を選択することができ、あるいは任意の他の組合せを選択することができる。したがって、遅延Ｘは、様々な構成要素を有することができ、遅延持続時間は、いくつかの実施形態でスマートスケジューラ／ルータ２０４によって動的に管理され得る。
【0191】
この例のエディタ・コンピューティング・デバイス２００２は、異なる地理空間特性、リソース特性、およびネットワーキング特性を有する。スマートスケジューラ／ルータ２０４は、スマートスケジューラ／ルータ２０４とエディタ・コンピューティング・デバイス２００２との間のネットワーキング接続の特性を変更することを含めて、エディタ・コンピューティング・デバイス２００２へのデータ転送を制御するように構成される。スマートスケジューラ／ルータ２０４は、処理アクティビティを行う際に使用可能な遅延持続時間を追跡するように構成され、それに応じてエディタ・コンピューティング・デバイス２００２を選択／プロビジョニングする。
【0192】
この例では、エディタ・コンピューティング・デバイス２００２は、それぞれが現在はオフピークである時間帯に配置されたデバイス２０００４、２０００６、および２０００８を含む。特定の挑戦的な処理が要求される場合に、リソースの回転するセットを利用することができ、これによって、デバイス２０００４、２０００６、および２０００８は、異なるデバイスがピーク可用性およびオフピーク可用性を通って交番するので、様々な時間帯を通って「回転する」。第１のデータ・ストリーム２８２が、スマートスケジューラ／ルータ２０４に供給され、その結果、第１のデータ・ストリーム２８２と第２のデータ・ストリーム２８４との間の遅延持続時間を利用して、１つ以上の処理タスクを行い、かつ／または引き起こすことができるようになる。
【0193】
スマートスケジューラ／ルータ２０４は、各ステップで要求される処理時間ならびに、とりわけ通信に関する総ネットワーキング遅延（たとえば、ネットワーク接続２００１０、２００１２、２１００に沿って移動するための時間）などの他の要因を追跡するように構成され得る。この例では、特定の順序が、エディタ・コンピューティング・デバイス２００２を用いて導入され、デバイス２０００４は、処理の第１ラウンドを行うためにデバイス２０００６と並列に動作し、処理は、その後に最終的な処理のためにデバイス２０００８に供給される。デバイス２０００８は、処理命令のパッケージをカプセル化し、処理命令のこのパッケージは、エディタ・コンピューティング・デバイス２００２によって前処理されており、様々な変形（たとえば、挿入、除去）および効果（たとえば、シフト、色補正）と処理命令のパッケージとを表す（たとえば、様々なエンドポイント受信器（たとえば、ＴＶ放送局）に高品質データ・ストリーム・フィード（たとえば、グラフィックスを付加され、検閲アルゴリズムを適用されたスポーツ放送）をプロビジョニングする前に、第２のデータ・ストリーム２８４の処理のためにルーティング・コンピューティング・デバイス２００４に送信される。
【0194】
いくつかの実施形態では、エディタ・コンピューティング・デバイス２００２は、編集者が第１のデータ・ストリーム２８２の出力に重畳されまたは他の形で適用される変形および効果を見られるように、処理されたプレビュー出力をプレビュー・エンドポイント（たとえば、スタジオ・トラック）に供給するようにさらに構成される。いくつかの実施形態では、エディタ・コンピューティング・デバイスは、処理の調整のためにルーティング・コンピューティング・デバイス２００４に処理されたプレビュー出力を供給する（たとえば、命令を送ることに対する代替案としてまたはこれと併せて）。いくつかの実施形態では、エンドポイントへの出力としてエディタ・コンピューティング・デバイス２００２からの処理されたプレビュー出力を供給するようにシステムを構成することができる。
【0195】
スマートスケジューラ／ルータ２０４は、遅延の総持続時間を追跡し、遅延エンベロープ持続時間の境界を超えないことを保証するために、それに応じてエディタ・コンピューティング・デバイス２００２およびネットワーキング経路を選択し、構成する。いくつかの実施形態では、特定の動作が、完了に、期待より長い時間を要する場合またはネットワーキング経路が低速である場合に、スマートスケジューラ／ルータ２０４は、たとえば使用されるエディタ・コンピューティング・デバイス２００２をより高速の（潜在的により高価な）デバイスと交換することまたはより高速の（潜在的により高価な）ネットワーク通信リソースを要求することのいずれかによって、予想外の遅延を補償するように構成され得る。したがって、いくつかの実施形態では、処理時間および送信時間がこれによって管理され、ルーティング・コンピューティング・デバイス２００４が受信器エンドポイントへの送信の前に処理効果を実施するのに十分な時間期間内に命令を受信できるように、一貫したまたは実質的に一貫した処理時間を確立するのに補償機構が利用される、エンドツーエンド・コンピューティング解決策をオーケストレーションするように、スマートスケジューラ／ルータ２０４が構成される。したがって、いくつかの実施形態のスマートスケジューラ／ルータ２０４は、たとえば、とりわけ、障害を発生するハードウェア、悪い時間推定、ネットワーク輻輳の結果として発生する可能性がある期待される処理時間／ネットワーキング送信時間からの変動を補償することがよりよくできる。スマートスケジューラ／ルータ２０４は、補償を達成する際に、ルーティング、経路、処理の順序、処理割当などを変更する。
【0196】
図２Ｅは、いくつかの実施形態によるシステムのブロック概略図である。図２Ｅでは、エディタ・コンピューティング・デバイス２００２が、送信器の非常に近くに配置され、クラウド・リソースに対する代替物として、スマートスケジューラ／ルータ２０４が、エディタ・コンピューティング・デバイス２００２のセットを制御する。そのデバイスは、一例では、送信器の非常に近くで（たとえば、同一のハウジング内または１ユニットとして）動作することができる。この例では、送信器は、２つのストリームを生成し、その一方は他方に対して遅延され、２つのストリームの間の遅延は、処理命令の生成に利用される。
【0197】
ルーティング・コンピューティング・デバイス２００４の別々のセットを有するのではなく、代替実施形態では、処理命令が、ネットワーク経路２１００に沿って第２のデータ・ストリーム２８４の符号器に戻って送信され、この符号器は、第２のデータ・ストリーム２８４を符号化している間に同時に命令を処理する。一実施形態では、第１のデータ・ストリーム２８２は、プレビューまたは低レートのデータ・ストリームであるのではなく、単純に、追加の処理または符号化を与えられないソース・データ・フィードである。この実施形態は、エディタ・コンピューティング・デバイス２００２への大容量接続がある場合、たとえば、デバイスが、同一の部屋または施設内に配置され、高スループット有線接続（たとえば、Ｃａｔ ６＋接続）を使用して接続される場合に好ましい可能性がある。
【0198】
図３は、いくつかの実施形態による、フレームが受信され処理される時に提供され得るパケット・タイミングを示す時間変動図である。図３００に示されているように、フレームＡが、供給され得、システム２００を介して移動することができる。フレームＡを、編集構成要素によって与えられる命令（たとえば、フレームＡ～Ａ＋Ｘでオーバーレイを追加する）と共に、低品質フレームの形で供給することができる。処理される命令に基づいて、ストリームの対応する高品質バージョンが、時間の「τ」単位だけ後にシステムを通過する時に作用した）。
【0199】
【0200】
いくつかの実施形態では、ストリーム２８２と２８４との両方が、システム２００の分散リソースに供給され、送信コスト（低品質送信の追加）、おそらくは送信時間（オーバーラップする２つのフィードがあるので高品質フィードに関してより長い時間を要する可能性がある）、および必要な計算能力（ソースで両方のストリームを符号化する必要）のトレードオフがあるが、処理（低品質に関してより少ない）とクラウドへの送信待ち時間との両方を得ることによってτを潜在的に増加させまたは最大化する。入力は、ストリームに適応される編集リソースの個数またはタイプと、エンドポイントに送信されるストリームに関する締切期限のタイプとを含む可能性がある。
【0201】
図４Ｂは、いくつかの実施形態による、クラウド処理を可能にするためのより低品質のストリーム２８２およびより高品質のストリーム２８４を生成する構造および方法を示すサンプル概略図４００Ｂである。この例では、スイッチが、ビデオ・ソースで設けられる。スイッチは、どのストリームがスマート・クラウド・ルータに供給され、どのストリームが他のリソースに供給され得るのかを決定することができる。したがって、いくつかの例では、２つのストリームは、必ずしも同時にはストリーミングされない。
【0202】
図示されているように、低品質のストリーム２８２が使用され、その後、クラウドで行われるショット選択判断（たとえば、たとえば米国特許出願第１４／３２９１１２号に記載のシステムを介する）に基づいて、命令バックを生成し、選択されたソースのビデオ品質基準を素早く高めるためにそのソースに送信することができ、「選択解除」される時に、オペレータは、ビデオ・ソースの品質を下げるためにビデオ・ソースに命令を送り返すことができる。たとえば、命令は、たとえば所望のビットレート、フレームレート、解像度の表現を含むデータの特定のコーディングされたセットに向けられ、おそらくは、とりわけ順方向誤り訂正データおよび／または待ち時間を増加する意図の送信の手間をかけるべきか否かを判断することができる。アップリンクのすべてのモードに適用可能な別の実施形態では、局の編集者が、送信器にローカルな編集ツールを使用してコンテンツに対してある種の編集を実行する命令を送信器または送信器オペレータに送り、送信器からの最終的な編集点が、クラウドに送り返され（高品質ストリームが既にアップロードされ、記憶されている可能性がある場合）、編集の実際の実行に関して、編集された材料の追加のアップロードを節約する。
【0203】
この手法は、異なるショットが使用可能であり、どれが放送中に使用されることになるのかに関して明瞭ではない時と、オペレータがコスト（必要な時に限って高品質を送信することによってまたは潜在的な輻輳（クラウド内では、局からインターネットへのパイプが固定される局ほど重大な問題ではない）のいずれかを低減することに注意を向けている場合に、有益である可能性がある。
【0204】
図４Ｃは、いくつかの実施形態による、クラウド処理を可能にするためのより低品質のストリーム２８２およびより高品質のストリーム２８４を生成する構造および方法を示すサンプル概略図４００Ｃである。「クラウド」トランスコーダ４０２Ｃが、データ・ストリームの処理および／または符号化に利用される。
【0205】
この手法は、ソースからフル品質ストリーム２８４を送信することと、その後、クラウド内に来た後に低品質ストリーム２８２を再符号化する（最初のクラウド・トランスコーダ４０２Ｃで）こととを含むことができる。この手法は、初期待ち時間（元の送信器とルータとの間）を増加させる可能性があるが、この手法は、いくつかのシナリオで、低品質ストリーム２８２のより素早い符号化を可能にすることができる、クラウド内の仮定される高められた計算能力の使用を容易にし、データ・ソースで必要な計算能力を低減することができる。
【0206】
潜在的な利点は、送信するデバイス（たとえば、複数のストリームの生成がデバイスの動作寿命に大きい影響を有する可能性がある、バッテリ電力を用いるもの）上でのより少ない電力使用、および／または送られるデータの量の低減を含むことができる。
【0207】
この手法は、ビデオ・ソースが、クラウドへの制限された初期接続性を有するか、使用可能な制限された処理能力を有するか、または単純に複数のストリームを生成できない状況で、特に役立つ可能性がある。たとえば、この手法は、より短い時間がより非「手動の」アクティビティのために必要になると期待され（ビジュアル編集など）、システムからシステムへの時間を低減することを試みる時に、改善をもたらすことができる。この手法は、ビデオ・ソースでの送信コスト（ソースからクラウドへの低品質プレビューの送信がもはや発生しないので、ソースからクラウドへの低品質プレビューの量だけ（経路の最も高コストの部分である可能性がある））および計算能力の必要を低減する。様々なモデルを利用することができ、たとえば、生＋蓄積転送モデルをシステムによって実施することができる、ここで、セットされた待ち時間を有する生ストリームが、まずシステムに送られ、待ち時間に関する懸念なしに、後に送られるより高品質のストリームがこれに続く。
【0208】
【0209】
いくつかの実施形態では、編集アクティビティがより長い処理時間を要求することがわかっている可能性がある場合に、意図的な遅延を実施することができる（たとえば、セットされた量または可変量）。たとえば、最高品質の「高品質」送信が送られる（たとえば、生＋蓄積転送モデルに関して）ことを保証する必要がある状況において。
【0210】
いくつかの実施形態では、低品質プレビューおよび高品質バージョンが作成され、それらがどのように輸送されるのかを、ビデオ・ソースの位置、ビデオ・ソース・デバイスの計算能力、ビデオ・ソースとクラウド・リソースとの間のネットワーク容量などに関するルールのセットに基づいてセットすることができる場合に。いくつかの実施形態では、送信方法に関する様々な判断点およびトリガをリアルタイムで作ることができる。
【0211】
他の形で可能であるはずのものよりより高品質のビデオを送ることを可能にする（たとえば、コンテンツに対する符号器の追加パスを追加するなど、より厳密な符号化を可能にするためにより長い時間を与える）ために、意図的な遅延を導入することができる。逆に、コンテンツの実際の送信時間の前に、プリエンプティブ処理を利用することもできる。
【0212】
命令された固定遅延（たとえば、原音を消すピーを可能にするためのｘ秒）または必要になる可能性がある最短編集時間（たとえば、タスクＸ、Ｙ、およびＺを実行するのに１５秒を要する）があり、したがって、システムを介して高品質ビデオを即座に得ることが必要ではない場合もある。別の例のシナリオは、パッケージのショットがその後の放送のために撮影され、高品質ビデオがしばらくは放送されない可能性があるが、システムが、編集のためのより長い時間を与えるために編集プロセスを即座に開始するために、放送とより低品質のプレビューの処理とを開始する場合を含む。
【0213】
いくつかの実施形態では、送信全体に関して送信方法を固定することができ、他の実施形態では、送信中に送信方法を変更する（たとえば、図４Ｂの構造／方法から開始し、ストリーム内のある点で図４Ｃの構造／方法にシフトする）ことができる。
【0214】
マルチパス符号化などの他の技法が、いくつかの実施形態で、総ビットレートを下げ、したがってデータを節約する（品質を高めるのではなく、またはそれに加えて）ために提供される。構造的類似性などのメトリックを適用して、制約（品質またはサイズ／コスト）を前提とする最適ピクチャ品質を確認することができる。プリエンプティブ処理を利用して、たとえばある種のタスク（たとえば、より低い難しさ）ある種のオーバーレイの追加またはオーディオ分析の実行などの送信器での処理を実行することができる。送信器でのプリエンプティブ処理は、期待されるネットワーク・スループットをよりよく利用することまたはより低い送信コストによる利益を提供することもできる。
【0215】
いくつかの実施形態では、より低品質のプレビュー・ストリームは、より高品質のコンテンツ・ストリームの送信で検出された誤りに基づく両方向誤り訂正パケットを含む。
【0216】
単一方向誤り訂正は、送信側が前もって冗長性パーセンテージを推定することを要求する場合がある（たとえば、データの５％がＦＥＣである場合に、ネットワークの５％までの消失を許容することができる）。消失の実際の量がこの推定値とは異なる場合に、誤り訂正が非効率的である（チャネルが推定より信頼できるので多すぎる冗長性を送信している）か、またはＦＥＣが不十分である（ネットワークが推定より信頼できない）かのいずれかである。リアルタイムでフィードバックに基づいてＦＥＣパーセンテージを調整できるように、両方向通信方法を利用することができる。
【0217】
ＦＥＣは、図４Ｄの例に限定されず、本明細書で説明される様々な実施形態と併せて実施され得る。
【0218】
図５Ａは、ビデオ・ソースに関する様々な構成要素を分離し、操作される関連する編集構成要素／キューイング構成要素にそれらを送るように構成されたシステムを示す例の概略図である。
【0219】
いくつかの実施形態では、異なる処理構成要素に送るべきオーディオおよびメタデータ（たとえば、クローズド・キャプショニング用のオーディオ、検閲用のオーディオおよび低品質ビデオ、自動オーバーレイを可能にするためのメタデータ（たとえば、ショットの位置））を分離する要件がある場合がある。いくつかの実施形態では、ビデオ・ソースに戻って供給され得る制御チャネルがさらにある場合がある。
【0220】
図５Ａに示されているように、スマート・クラウド・ルータは、処理のために異なる分散クラウド・コンピューティング・リソースに供給されるストリームの様々な非限定的な例を示す。図示の例は、単に例であり、他の、代替の、異なる、より多数の、またはより少数のプロセス・フローをスマート・クラウド・ルータによって実施することができる。たとえば、代替言語オーディオだけへの「低品質ビデオ・プロキシ」だけの送出を、スポーツ放送に関して行うことができ、ここで、システムは、（たとえば、スペイン人の）コメンテータがそれ以外は英語の放送で見ているものに関してそのコメンテータがコメントするために適合される処理を容易にするように構成される。他の場合に、システムは、オーディオとビデオとの両方またはオーディオのみ（英語／第１言語コメントを別の言語に実際に翻訳したい場合）など異なるデータ・ストリームを送るように構成され得る。
【0221】
いくつかの実施形態では、ストリームの分離された部分は、様々な要因に従って並列にではなく、直列に処理ユニットのセットに進むことができる（たとえば、待ち時間、異なるアクティビティの間の論理接続（たとえば、まず翻訳に進むことができ、その後（おそらく複数言語オーディオ・ストリームが）クローズド・キャプショニングに進むはずである）。
【0222】
いくつかの実施形態では、送信器での（たとえば、データ・ストリームの生成時の）処理の変更または前処理を引き起こすために、ある種の命令を、送信するデバイスに戻って送信することもできる。
【0223】
いくつかの実施形態では、スケジューラ／ルータは、処理の順序を決定するように構成される。そのような決定は、たとえば、所定のルール・セットに基づくか、または使用可能なクラウド編集リソースのセットによって要求されもしくは暗示されるルール・セットに基づくかのいずれかとすることができる。たとえば、いくつかの場合に、ストリームは、クローズド・キャプショナ・システムＸ、他の時にはクローズド・キャプショナ・システムＹを通過することができ、Ｙ上のソフトウェアは、他のアクティビティの前にある種のアクティビティが発生することを要求する場合があるが、Ｘは無関係である。
【0224】
他のストリームまたはプレビューに続くはずの、高品質の「放送に値する」ストリームを供給することができる。高品質ストリームは、たとえば、直列にまたは並列にのいずれかで、処理ユニットのそれぞれへの所定の経路に沿って提供され得、あるいは、ヘッドレス処理ユニットによって操作され得る（図７参照）。ヘッドレス処理ユニットは、たとえば、他の処理ユニットから命令セットを戻って受信し（たとえば、高品質ストリームの到着の前に低品質プレビューを操作していたオペレータによって決定される編集点のセットを受信する）、これによって、高品質ストリームをより効率的な形で処理する（たとえば、変更する）ことを可能にする。
【0225】
複数のストリームを生成する機構（すなわち、それらが生成され、切り替えられるところ）が、図４Ａ／Ｂ／Ｃ／Ｄの低品質／高品質の例に示されている。
【0226】
いくつかの実施形態では、いくつかの「プレビュー」（オーディオの、または低品質ビデオ）が、同一のストリームに対して異なる方法および手法を利用することができ（たとえば、オーディオが、ソースからフル品質であり、クラウド（図４Ｃに示されたものに類似）に送信される時により低いビットレートで符号化されるが、ビデオは、ソースから低品質で提供される（図４Ａに示されているように））、これによって、高品質ストリームが個々のエディタ・コンピューティング・デバイスのそれぞれに進むことを回避することを可能にする。
【0227】
【0228】
図示されているように、いくつかの実施形態では、カメラ／ビデオ・ソースは、スマート・クラウド・ルータに供給される前に、ビデオ・スイッチャと相互作用することができる。たとえば、スイッチャは、単一の瞬間に異なる観点に向けられた複数のカメラがある場合があるが、カメラのうちの１つ以上だけが、エンド・ユーザへの送信を提供するのに能動的に使用される（たとえば、１つのカメラだけが、焦点を合わせて使用されている）、スポーツ・スタジアムの文脈で有用である可能性がある。いくつかの実施形態では、たとえば様々な処理制約および／またはネットワーク制約に基づいて、スイッチャを自動的に制御することができる。たとえば、ビデオ・スイッチャが査定された内容に基づいて自動的に切り替わる（どのカメラが最良のビューまたは最良のオーディオを有するのかに基づいて被疑者（または検査されている資産）に自動的に切り替わる）場合に、セキュリティまたは検査内容を利用することができる。
【0229】
図６は、いくつかの実施形態による、並列クラウド処理を可能にするために、別々のオーディオ・ストリームおよびメタデータ・ストリームと一緒により低品質のビデオ・ストリームおよびより高品質のビデオ・ストリームを使用することによるビデオ・ストリームのリアルタイム処理の可能化の手法を示す例の概略図６００である。図６に示されているように、信号のそれぞれは、管理すべき別々の待ち時間を含む場合がある（たとえば、いくつかの状況で、たとえば、システム２００は、メタデータを非常に素早く供給し、これを使用するためのより長い時間を与えることができる場合がある）。図３とは対照的に、τより多くがある場合があり、他のストリームの追加の待ち時間が、「φ」および／または「χ」の形で表される場合がある。図６に示されているように、フレームＡが、データのフレームが分散ルータによって処理されているのと同一の「時間」に含まれない場合がある。複数の異なる待ち時間が示されているが、「ｎ」個の異なる要素に関して「ｎ」個の待ち時間値がある可能性がある。
【0230】
これらの複数の待ち時間は、制御／スケジューリングのために平衡化され、かつ／または使用され得る。パイプラインの終りでは、異なる待ち時間を有するデータの並行ストリームが、消費のために一緒に元に戻されなければならない。一部のストリームは、これを消費する視聴者が、オーディオがビデオと一致するのを見るようにするために、非常に密に同期化されることを必要とする場合がある（たとえば、オーディオおよびビデオ）。他のストリーム（たとえば、メタデータ、クローズド・キャプショニング）は、目標関数（たとえば、最低の処理コスト）に関して最適化するためにスケジューラが利用できる、同期化に関するよりゆるやかな制約を有する場合がある。
【0231】
図７は、いくつかの実施形態による、スマート・ルーティング・システムの要素を含むシステム７００を示す例の概略図である。図示されているように、「スマート・クラウド・ルータ」は、たとえば図２Ａ、２Ｂ、２Ｃで提供されるシステムとし、様々な特徴および構成を有することができる。このシステムは、とりわけ、同期化、可用性を追跡し、負荷平衡化を実行し、「ヘッドレス」の形で処理を実行し、符号化を実行し、スケジューリングを実行し、待ち時間、処理時間などの動作特性を監視し、経路最適化を行うように構成され得る。分散リソース「クラウドベースの」解決策の使用は、高められた冗長性、スケーラビリティ、拡張性、従量制などを提供することができるが、全環境の制御を有しないという課題と、構成要素の間のより長い待ち時間の可能性とをも提供する。
【0232】
ヘッドレス動作は、いくつかの実施形態で、他の処理ユニットによって生成された命令を適用する（それ自体の命令を生成するのではなく）ヘッドレス・ユニットによって行われる。
【0233】
「クラウド」／分散リソース環境内に示された構成要素は、単一のクラウド位置内の同一位置に配置されるなど、様々な位置で提供され得、あるいは、様々な位置に分散され得る（図１で描写されているような物理的調整室内に残されたいくつかの要素を含む）。
【0234】
図８Ａは、多数の同一の処理ユニットにストリームを送ることに基づいて冗長性を提供するシステムを示す例の概略図である。図８は、冗長性を有する（同一のタイプ／機能の複数の処理ユニットへストリームを送らせること、たとえば、同一のオーディオ・ストリームを３つのクローズド・キャプショニング・サーバに送らせ、３つのストリームを戻させる（かつ、冗長なパケットを捨ててそれらをシーケンシングさせる）ことによる）ことの１つの方法の視覚的表現を提供する。
【0235】
多数の処理ユニットは、高可用性がすべての他の要因（たとえば、コスト）に勝つ状況で有用である可能性がある。処理ユニットが同一である場合に、それらのどれもが障害を発生していない正常なケースでは、破棄される冗長な努力をもたらす。しかし、処理ユニットおよび／またはそのユニットとのネットワーク通信が障害を発生する場合に、冗長なユニットは、その障害を補償することができる。
【0236】
図８Ｂは、いくつかの実施形態による、多数の同一のスマート・ルータにストリームを送ることに基づいて冗長性を提供するシステムを示す例の概略図である。図８Ｂは、複数のクラウド・ルータに送ることによるより早い段階での冗長性の視覚的表現を提供し、様々な構成要素に接続され、とりわけ、異なるスマート・ルータを監視し、プロキシへのルーティング情報を与えるように構成された、マスタ・コントローラ８０２が設けられる。
【0237】
いくつかの実施形態では、所与の局の番組スケジュール内にリストされた時刻に達するために（たとえば、広告挿入などの態様は、別々のスケジュール内のセットされた時刻に発生する）、プロセスの終りに（放送の前に）フレームを保持することができる。
【0238】
図９は、いくつかの実施形態による、リモート処理に関するサンプル手法を示すワークフローである。
【0239】
データ・ストリームをリモートに処理する方法９００が示され、この方法は、少なくとも２つのデータ・ストリームを送信するステップ９０２を含み、少なくとも２つのデータ・ストリームは、少なくともより低品質のプレビュー・ストリームとより高品質のコンテンツ・ストリームとを含む。
【0240】
９０４では、少なくとも１つの送信器からリモートに配置された複数のエディタ・コンピューティング・デバイスで、少なくともより低品質のプレビュー・ストリームを受信し、複数のエディタ・コンピューティング・デバイスは、より低品質のプレビュー・ストリームに対する処理および編集を容易にするように構成され、処理および編集は、処理および編集を表す機械可読命令のセットを生成するのに使用される。
【0241】
９０６では、少なくとも１つの送信器からリモートに配置された複数のルーティング・コンピューティング・デバイスで、少なくともより高品質のコンテンツ・ストリームと機械可読命令のセットとを受信し、複数のルーティング・コンピューティング・デバイスは、９０８で、出力コンテンツ・ストリームを生成するために機械可読命令のセットに従ってより高品質のコンテンツ・ストリームを符号化することによってより高品質のコンテンツ・ストリームを処理するように構成される。
【0242】
より高品質のコンテンツ・ストリームが、より低品質のプレビューのコンテンツと完全には一致しない場合がある。いくつかの実施形態では、高品質ストリームの選択された部分だけが送信される必要があり、これによって、他の利益の中でもコスト、待ち時間、および送信時間を低減できるように、プレビューに基づく「ラフ・カット」が発生することが可能である。９１０では、受信された制御フィードバックに基づいて、制御信号を送信器に返すことができる。
【0243】
図１０は、一実施形態の典型的なコンピューティング・デバイス１０００の概略図である。図示されているように、コンピューティング・デバイス１０００は、少なくとも１つのプロセッサ１００２、メモリ１００４、少なくとも１つのＩ／Ｏインターフェース１００６、および少なくとも１つのネットワーク・インターフェース１００８を含む。
【0244】
各プロセッサ１００２は、たとえば、マイクロプロセッサもしくはマイクロコントローラ、デジタル信号処理（ＤＳＰ）プロセッサ、集積回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、再構成可能プロセッサ、プログラム可能読取専用メモリ（ＰＲＯＭ）、またはその任意の組合せとすることができる。
【0245】
メモリ１００４は、たとえば、ランダム・アクセス・メモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、コンパクト・ディスク読取専用メモリ（ＣＤＲＯＭ）、電気光学メモリ、光磁気メモリ、消去可能プログラム可能読取専用メモリ（ＥＰＲＯＭ）、電気的消去可能プログラム可能読取専用メモリ（ＥＥＰＲＯＭ）、強磁性ＲＡＭ（ＦＲＡＭ（登録商標））、または類似物など、内部または外部のいずれかに配置されたコンピュータ・メモリの組合せを含むことができる。
【0246】
各Ｉ／Ｏインターフェース１００６は、コンピューティング・デバイス１０００が、キーボード、マウス、カメラ、タッチ・スクリーン、およびマイクロフォンなどの１つもしくは複数の入力デバイスまたはディスプレイ・スクリーンおよびスピーカなどの１つもしくは複数の出力デバイスと相互接続することを可能にする。
【0247】
各ネットワーク・インターフェース１００８は、コンピューティング・デバイス１０００が、他の構成要素と通信し、他の構成要素とデータを交換し、ネットワーク・リソースにアクセスし、これに接続し、アプリケーションのために働き、インターネット、イーサネット（登録商標）、ｐｌａｉｎ ｏｌｄ ｔｅｌｅｐｈｏｎｅ ｓｅｒｖｉｃｅ（ＰＯＴＳ）回線、公衆交換電話網（ＰＳＴＮ）、統合デジタル通信網（ＩＳＤＮ）、デジタル加入者回線（ＤＳＬ）、同軸ケーブル、光ファイバ、衛星、モバイル、無線（たとえば、Ｗｉ－Ｆｉ、ＭｉＭＡＸ）、ＳＳ７シグナリング・ネットワーク、固定回線、ローカル・エリア・ネットワーク、広域ネットワーク、および他（これらの組合せを含む）を含む、データを搬送することのできるネットワーク（または複数のネットワーク）に接続することによって他のコンピューティング・アプリケーションを実行することを可能にする。
【0248】
別々の実施形態で、特殊目的機械が、構成され、使用のために提供される。そのような特殊目的機械は、制限された範囲の機能を伴って構成され、特に、組み込まれたファームウェアまたはソフトウェアからの命令に従って特定の機能を実行するようにプログラムされる効率的なデバイス内で特徴を提供するように構成される。この実施形態では、特殊目的機械は、一般的なコンピューティング機能を提供しない。たとえば、コントローラ基板およびスケジューラを含む特定のデバイスを、特定用途向け集積回路などの集積回路の形で提供することができる。
【0249】
この特定用途向け集積回路は、ゲートの特定の構成を介して、上で説明した複雑な機能性を実行するために一緒に組み合わされるプログラムされたゲートを含むことができる。これらのゲートは、たとえば、セルおよびお互いの間の電気接続を有する、より低水準の構造を形成することができる。特定用途向け集積回路の潜在的な利点は、改善された効率、短縮された伝搬遅延、および低減された電力消費である。特定用途向け集積回路は、回路網の空間および体積が関連要因である場合の微細か要件を満足するのに役立つ可能性もある。
【図1】
【図2A】
【図2B】
【図2C】
【図2D】
【図2E】
【図3】
【図4A】
【図4B】
【図4C】
【図4D】
【図5A】
【図5B】
【図6】
【図7】
【図8A】
【図8B】
【図9】
【図10】