JP6456937B2 - ソフトウェア規定メディアプラットフォーム - Google Patents

Description

米国特許法第１１９条（ｅ）項および連邦規則法典第３７巻第１．７８条に基づく優先権
本非仮出願は、（ｉ）Ｐａｕｌ Ｔｗｅｅｄａｌｅの名において２０１３年１０月１８日付けで出願された先行米国仮特許出願第６１／８９２７３３号「ＳＯＦＴＷＡＲＥ ＤＥＦＩＮＥＤ ＭＥＤＩＡ ＰＬＡＴＦＯＲＭ」に基づく優先権を主張し、各々は全体として参照により本明細書に組み込まれる。

本開示は一般に通信ネットワークに関する。より具体的には、いかなる限定としてでもなく、本開示は、適応ストリーミング環境において動作可能なソフトウェア規定メディアプラットフォームを対象とする。

たとえば適応ストリーミング環境で採用される、現行のメディア配信プラットフォームは、典型的にはリソースおよび設定に関して非常に堅固である。処理リソースは、ライブまたはオンデマンドチャンネルの処理（すなわち、採集、トランスコーディング、暗号化、セグメント化、およびアップローディング）に先行して割り振られ、メディアチャンネルに関して採集が開始すると、セッションを視聴しているダウンストリームユーザにとって望ましくない中断のリスクなしに、そのチャンネルに対するリソースの割り振り／設定を変更することは困難または不可能であり得る。メディア配信プラットフォームの現行のモデルは、需要の変化または基礎をなすリソース可用性にシステムを容易かつ効率的に適合させることができない。

本発明の例示の実施形態は、以下の例示のユースケースシナリオに鑑みて理解されよう。サービスプロバイダ（たとえばコンテンツ配信プロバイダ）が、視聴者の数および構成が時間、曜日、番組などに応じて変化する状態で、いくつかのライブチャンネル（たとえば５０チャンネル）にマルチスクリーンサービスを提供しなければならないと考えてみる。サービスプロバイダは、モバイル／セルラ通信ユーザ、Ｗｉ−Ｆｉユーザ、ならびに他のブロードバンドアクセス技術（たとえばケーブル、衛星など）を備えるユーザが、５０のライブチャンネルすべてにわたって分配され得る自分の一番高評価の番組およびスポーツイベントのうちの特にいくつかで、高品質の体感が得られることを望むであろう。

従来のメディア配信プラットフォームを使用する場合、サービスプロバイダは、すべての様式のアクセス技術（たとえばモバイル／セルラ通信、Ｗｉ−Ｆｉ通信、ケーブルアクセスなど）をサポートするために、各チャンネルに複数バージョンまたは表現のチャンネルコンテンツ、すなわち異なるビットレートでエンコードされたメディアストリームをプロビジョニング（準備）しなければならない。こうしたプロビジョニングは望ましい品質のユーザ体感を提供し得るが、通常は、配信インフラストラクチャの処理リソースを低効率で利用することにより、コストは高くなる。たとえばピーク時には、割り振られたリソースは望ましい品質のサービスの配信で完全に専有されるが、需要の低い別の時点では、リソースは比較的遊休状態であることがある。ピーク動作の割合が低い場合、プロビジョニングされたリソースに関してかなり非効率的である。

本発明の実施形態に従ったソフトウェア規定メディアプラットフォームは、前述の問題に対処するためにサービスプロバイダのリソースのより動的な割り振りを容易にするように設定可能である。さらに上記のユースケースへの言及を続けると、チャンネルの一部、たとえば５０チャンネルのうちの３０を、最低数のビットレートしか必要としない低容量チャンネルとして指定し、そのことによってサービスプロバイダのリソースを節約することができる。しかしながら、こうしたチャンネルのピーク視聴時間中、追加のビットレートおよび関連付けられた処理リソースを動的に追加することができる。プレミアムとみなされるチャンネルであっても、いつでもそのリソースを増加させることができる。通常は、たとえば特にスケジューリングされた時間にピークに達する高解像度コンテンツへの需要がある、サンデーナイトフットボールなどの通常よりも多くの視聴者を有するイベントに対処する上で、これは望ましいことがある。さらに、セルラ顧客が不必要な低ビットレートまで低下しないように保証するためには、より多くのビットレートが必要な可能性がある。加えて、ＨＤまたは超ＨＤディスプレイデバイスでゲームを見ている家庭用Ｗｉ−Ｆｉユーザにサービスを提供するために、より高いビットレートおよび解像度が必要な可能性がある。

本特許出願の実施形態に従った追加の処理リソースの動的割り振りによって、こうしたニーズに適応可能であることを理解されたい。さらに、ユーザ分析、サービスプロバイダの機能、および／または、帯域幅管理ポリシー、サービスレベル契約などの他の要素によって影響を受ける可能性のあるリソース割り振りの動的挙動を可能にするために、ローカルに、および／または、現在のソリューションによって提供されていない分配方法で、リソースを配置するための機能を、実施形態に提供することができる。

一態様において、本明細書で開示されるソフトウェア規定メディアプラットフォーム（ＳＤＭＰ）の実施形態は、コンピュータプログラム命令を実行するための処理回路と、処理中にデータを記憶および転送するためのメモリおよび相互接続と、分散コンピュータハードウェアを、外部デバイスおよび１つまたは複数のデータ通信ネットワークを含むサブシステムに結合するインターフェース回路とを含む、分散コンピュータハードウェアを備え、メモリは、１つまたは複数のトランスコーダ処理ユニットおよび１つまたは複数のパッケージャ処理ユニットを含む対応するメディア処理ユニットを形成するために、分散コンピュータハードウェアによって実行される複数のソフトウェアモジュールを記憶する。各トランスコーダ処理ユニット（ＴＰＵ）は、（ａ）入力メディアストリームを受信およびデコードするため、（ｂ）結果として生じるデコードされたメディアストリームをセグメントに区分するため、ならびに、（ｃ）セグメントを、たとえば私設または内部コンテンツ配信ネットワークなどの１つまたは複数の私設または内部クラウド記憶サービスユニット（ＣＳＵ）にアップロードするための、レコーダ、デコーダ、エンコーダ、セグメンタ、およびアップローダを少なくとも含むことができる。各パッケージャ処理ユニット（ＰＰＵ）は、（ａ）ソースメディアの入力セグメントを取り出すため、（ｂ）最終消費者に配信される出力セグメントを生成するために取り出されたセグメントを再区分するため、ならびに（ｃ）出力セグメントを、メディアストリームの再生用に出力セグメントを取得するために最終消費者によるアクセスが可能な外部クラウド記憶サービスユニット（たとえば公衆コンテンツ配信ネットワーク）にアップロードするための、レコーダ、セグメンタ、およびアップローダを少なくとも含む。他の変形形態において、ＰＰＵが、内部ＣＳＵからのセグメントの代わりにソース入力（たとえばマルチキャストＵＤＰ）を受信できることも可能である。いくつかの例示の実装において、アップローディングは、出力セグメントの暗号化を先行させることが可能であるため、暗号化サービスを含むことができる。したがって例示の実施形態は、好適な暗号化サービスを同様に含むメディア処理ユニットによるアップローディングを含むことができる。ソフトウェア規定メディアプラットフォームは、需要の変化、リソース可用性、および需要に関連してシステム性能に影響を与える他のパラメータに従って動作を適合させるために、メディア処理ユニットおよびメディア処理ユニット間のそれぞれの接続を動的にインスタンス化および設定するように動作可能な、システムマネージャサブシステムをさらに含む。

別の態様において、ソースメディアストリームを１つまたは複数のエンドユーザへの配信用の最終加工成果セグメントに処理するように動作可能な、メディア処理システムの実施形態が開示される。請求される実施形態は、とりわけ、ソースメディアストリームをベース加工成果セグメントのストリームに区分するように設定された入力処理ユニットを備え、各ベース加工成果セグメントは選択時間持続期間を有し、ベースビットレートを有するようにトランスコードされる。複数のトランスコーディング処理ユニット（ＴＰＵ）のカスケードネットワークが提供され、ＴＰＵは、（ｉ）ベース加工成果セグメントを第１レベルの中間加工成果セグメントストリームに処理するように、または、（ｉｉ）ｉ番目レベルの中間加工成果セグメントストリームを、ｉ＋１番目レベルの中間加工成果セグメントストリームに処理し、結果としてｉ番目レベルの中間加工成果セグメントがｉ＋１番目レベルの中間加工成果セグメントよりも高いビットレートを有するように、動作可能である。１つまたは複数のパッケージャ処理ユニット（ＰＰＵ）は、ベース加工成果セグメントストリームおよび／または中間加工成果セグメントストリームのうちの１つまたは複数を、複数の選択ビットレートおよびセグメントサイズ（すなわち持続期間または長さ）を有する最終加工成果セグメントに処理するように設定可能である。１つまたは複数のクラウド記憶／サービスユニット（ＣＳＵ）は、ベース加工成果セグメントのストリームおよび１つまたは複数の中間加工成果セグメントストリームの記憶および移送を容易にするために、入力処理ユニット、複数のＴＰＵ、および１つまたは複数のＰＰＵに、動作可能に結合される。１つまたは複数の設定トリガに応答してソースメディアストリームを適応的に処理するために、１つまたは複数のＣＳＵを介して、入力処理ユニット、複数のＴＰＵ、１つまたは複数のＰＰＵ、およびそれらの間のそれぞれの接続を動的にインスタンス化および設定するように動作可能な、オーケストレーションおよびリソース管理（ＯＲＭ）ユニットが提供される。

さらに別の態様において、ソースメディアストリームを１つまたは複数のエンドユーザへの配信用の最終加工成果セグメントに処理するための、メディア処理方法の実施形態が開示される。請求される実施形態は、とりわけ、ソースメディアストリームを受信すること、ならびに、ソースメディアストリームを、１つまたは複数の設定トリガに応答して動的にインスタンス化および設定され得る複数のＴＰＵによって、異なるメディア特徴を有する１つまたは複数レベルの加工成果セグメントに処理することを含む。請求される実施形態は、１つまたは複数レベルの加工成果セグメントを、選択メディア特徴を有する最終加工成果セグメントにパッケージングすること（たとえば必要な場合、再区分化することを含む）、および、１人または複数のエンドユーザまたは消費者への配信用に、１つまたは複数のＰＰＵによって最終加工成果セグメントをアップロードすることを、さらに含む。ＴＰＵと同様に、ＰＰＵは、１つまたは複数の設定トリガに応答して動的にインスタンス化および設定することも可能である。一実装において、ＴＰＵ／ＰＰＵは、カスタムハードウェア実装、ソフトウェア実装、シングルルート入力／出力仮想化（ＳＲ−ＩＯＶ）配置構成、およびマルチルート入力／出力仮想化（ＭＲ−ＩＯＶ）配置構成のうちの１つで構成可能である。１つまたは複数の設定トリガは、たとえば（ｉ）最終加工成果セグメントストリームのエンドユーザへの配信に関連したネットワーク分析、（ｉｉ）サービスオペレータ始動アラーム、（ｉｉｉ）ハードウェアまたはソフトウェア障害、（ｉｖ）地理的領域内のソースメディアストリーム（１０６）のスケジューリング情報を含む電子プログラムガイド（ＥＰＧ）のうちの、少なくとも１つに応答して生成され得る。他の実装において、加工成果セグメントの選択メディア特徴は、複数のエンコーディングビットレート、セグメントサイズ（すなわち長さまたは持続期間）、およびフレームレートのうちの少なくとも１つを含むことができる。

さらに他の態様において、１つまたは複数のＴＰＵ、ＰＰＵ、および／またはＯＲＭサブシステムで動作可能な方法の追加または代替の実施形態が、本明細書の教示に従って提供され得る。さらに他の関連する態様において、本明細書に記載の１つまたは複数の分散プロセス、方法、および／またはスキームを実行するための、記憶されたプログラム命令またはコード部分を含む持続性の有形コンピュータ可読メディアの実施形態が開示される。

上記に鑑み、当業者であれば、本明細書に記載の実施形態が、メディア配信環境に割り振られたリソースの処理の動的インスタンス化を有利に提供することを理解されよう。特に、本開示の実施形態に従って使用情報（たとえば分析）に関連して動的なリソースインスタンス化を使用することで、サービスプロバイダは他の利益の中でとりわけ、その投資をより適切に最大化することができる可能性がある。

様々な実施形態の他の特徴は、従属請求項で請求されている通りである。実施形態の追加の利益および利点は、以下の説明および添付の図面に鑑みて明らかとなろう。

本開示の実施形態は、同様の参照記号が同様の要素を示す添付の図面の図中に、限定としてではなく例として示されている。本開示における「実施形態」または「一実施形態」という異なる言及は必ずしも同じ実施形態に対するものではなく、こうした言及は少なくとも１つを意味し得ることに留意されたい。さらに、実施形態に関して特定の機能、構造、または特徴を説明する場合、他の実施形態に関してこうした機能、構造、または特徴を実施することが、明示的に説明されるか否かにかかわらず、当業者の知識の範囲内にあることが提示される。

添付の図面は、本開示の１つまたは複数の例示の実施形態を図示するために本明細書に組み込まれ、その一部を形成する。本開示の様々な利点および機能は、添付の特許請求の範囲に関して、および添付の図面を参照して説明される、以下の発明を実施するための形態から理解されよう。

本特許出願の実施形態に従った、ソースメディアストリームを適応的に処理するための例示のソフトウェア規定メディアプラットフォーム（ＳＤＭＰ）の全体的アーキテクチャを示す図である。 ＳＤＭＰアーキテクチャの実施形態で使用するための、例示のトランスコーディング処理ユニット（ＴＰＵ）を示すブロック図である。 ＳＤＭＰアーキテクチャの実施形態で使用するための、冗長設定で提供される例示のパッケージャ処理ユニット（ＰＰＵ）を示すブロック図である。 本特許出願に関するソースメディア処理方法を実行するために、１つまたは複数の実施形態において組み合わせ可能な、様々な機能、ステップ、および動作に関するブロックを伴うフローチャートを示す図である。 本特許出願の教示に従った、ソフトウェア規定メディアプラットフォームの実施形態が実装可能な様々な例示の設定を示す図である。 本特許出願の教示に従った、ソフトウェア規定メディアプラットフォームの実施形態が実装可能な様々な例示の設定を示す図である。 本特許出願の教示に従った、ソフトウェア規定メディアプラットフォームの実施形態が実装可能な様々な例示の設定を示す図である。 実施形態に従った、ＴＰＵの仮想化ベースの実装を示す図である。 実施形態に従った、ソフトウェア規定メディアプラットフォームのＩａａＳベースの実装を示す図である。 実施形態に従った、設定トリガに応答してＴＰＵ、ＰＰＵ、およびそれらの間の相互接続を動的にインスタンス化および設定するように動作可能な、オーケストレーションおよびリソース管理（ＯＲＭ）サブシステムを示すブロック図である。 実施形態に従った、本特許出願のＳＤＭＰアーキテクチャの１つまたは複数のメディア処理ユニットおよび／または他のサブシステムを実現するように設定され得る、分散ハードウェアプラットフォームを示すブロック図である。

以下の説明では、本特許開示の１つまたは複数の実施形態に関して、多数の特有の細部が記載される。しかしながら、１つまたは複数の実施形態は、こうした特有の細部なしに実施可能であることを理解されたい。他の事例では、例示の実施形態の理解を不明瞭にしないために、周知の回路、サブシステム、構成要素、構造、および技法は詳細に示されていない。したがって、当業者であれば、本開示の実施形態はこうした特有の構成要素ベースの細部なしに実施可能であることを理解されよう。当業者であれば、本明細書に記載の発明を実施するための形態の助けにより、さらに添付の図面を参照しながら、必要以上の実験をせずに１つまたは複数の実施形態を作成および使用できることをさらに理解されたい。

加えて、「結合された」および「接続された」などの用語は、その派生語と共に、以下の説明、特許請求の範囲、またはその両方で使用可能である。これらの用語は必ずしも互いの同義語として意図されないことを理解されたい。「結合された」は、２つ以上の要素が、互いに直接物理的または電気的に接触し得るか否かに関わらず、互いに協働または相互作用することを示すために使用可能である。「接続された」は、互いに結合された２つ以上の要素間での通信の確立、すなわち通信関係を示すために使用可能である。さらに本明細書に記載の１つまたは複数の例示の実施形態では、一般的に言えば、要素が機能を実行できるか、または実行するように別の方法で構造的に配置構成できる場合、その機能を実行するように要素、構成要素、またはモジュールを設定することができる。

本明細書で使用する場合、メディア処理要素またはノードは、仮想化されるかまたは他の方法で、ネットワーク上の他の機器（たとえば他のネットワーク要素、エンドステーションなど）と通信可能に相互接続している、ハードウェアおよびソフトウェアを含む、１つまたは複数のサービス機器からなり得、様々な用途およびネットワーク条件に適合的に動的にインスタンス化および設定可能である。エンドユーザステーションは、加入者エンドステーション、クライアントデバイス、またはユーザ機器とも呼ばれ、とりわけ、ストリーミングアプリケーション仕様に従って、ストリーミングサーバまたはコンテンツプロバイダからコンテンツを受信するために、少なくとも１つのクライアントアプリケーション（たとえばＡＢＲストリーミングクライアントアプリケーション）を実行するように設定された、任意のデバイスを備えることができる。したがって、例示のクライアントデバイスは、配信ネットワーク（たとえばＩＰネットワーク）を介して提供されるライブまたはオンデマンドのコンテンツ／サービスにアクセスするかまたは消費することが可能な、セットトップボックス、パーソナル／デジタルビデオレコーダ（ＰＶＲ／ＤＶＲ）、ワークステーション、ラップトップ、ネットブック、パームトップ、モバイルフォン、スマートフォン、マルチメディアフォン、ネットワーク化プロジェクタまたはメディアプレーヤ、モバイル／ワイヤレスユーザ機器、ＩＰ対応高解像度（ＨＤ）または超ＨＤ ＴＶ端末、ポータブルメディアプレーヤ、位置把握加入者機器、ゲーミングシステムまたはコンソール（Ｗｉｉ（登録商標）、Ｐｌａｙ Ｓｔａｔｉｏｎ ３（登録商標）、Ｘｂｏｘ ３６０（登録商標））などを含むことが可能であり、メディアは本明細書に記載の１つまたは複数の実施形態に従ってソフトウェア規定プラットフォーム内で処理することができる。さらにクライアントデバイスは、ブロードキャストネットワーク（たとえばケーブルおよび衛星ネットワーク）、ならびに、好適なサービスプロバイダアクセスネットワークを介したインターネットなどのパケット交換ワイドエリア公衆ネットワークを介して提供される、コンテンツ／サービスにアクセスするかまたは消費することも可能である。さらに他の変形形態において、クライアントデバイスまたは加入者エンドステーションも、インターネット上にオーバーレイされた（たとえばインターネットを介してトンネリングされた）仮想私設ネットワーク（ＶＰＮ）上に提供されるコンテンツ／サービスにアクセスするかまたは消費することが可能である。

本特許開示の１つまたは複数の実施形態は、ソフトウェア、ファームウェア、および／またはハードウェアの異なる組み合わせを使用して実装可能である。したがって、図（たとえばフローチャート）に示される技法のうちの１つまたは複数は、１つまたは複数の電子デバイスまたはノード（たとえばネットワーク要素、メディア処理ユニット、システム管理ノード、または加入者ステーションなど）上で記憶および実行されるコードおよびデータを使用して実装可能である。こうした電子デバイスは、持続性コンピュータ可読記憶メディア（たとえば磁気ディスク、光ディスク、ランダムアクセスメモリ、読み取り専用メモリ、フラッシュメモリデバイス、相変化メモリなど）、一時コンピュータ可読伝送メディア（たとえば電気、光、音響、または、搬送波、赤外線信号、デジタル信号などの他の形の伝搬信号）などの、コンピュータ可読メディアを使用して、コードおよびデータを（内部的に、および／または、ネットワークを介する他の電子デバイスを用いて）記憶または通信することができる。加えて、こうしたネットワーク要素は、典型的には、１つまたは複数の記憶デバイス（たとえば持続性機械可読記憶メディア）、ならびに、記憶データベース、ユーザ入力／出力デバイス（たとえばキーボード、タッチスクリーン、ポインティングデバイス、および／またはディスプレイ）、ならびに、シグナリングおよび／またはベアラメディア伝送を実現するためのネットワーク接続などの、１つまたは複数の他の構成要素に結合された、１つまたは複数のプロセッサのセットを含むことができる。プロセッサおよび他の構成要素のセットの結合は、典型的には、任意の既知の（たとえば対称／共有マルチプロセッシング）またはこれまで未知のアーキテクチャで配置構成された、１つまたは複数のバスおよびブリッジ（バスコントローラとも呼ばれる）を介することが可能である。したがって、記憶デバイスまたは所与の電子デバイスもしくはネットワーク要素の構成要素は、本開示の１つまたは複数の技法を実装するために、その要素、ノード、または電子デバイスの１つまたは複数のプロセッサ上で実行するためのコードおよび／またはデータを記憶するように設定可能である。

次に図面、より具体的には図１を参照すると、本特許出願の実施形態に従い、ソースメディアストリームを適応的に処理するための、例示のソフトウェア規定メディアプラットフォーム（ＳＤＭＰ）１００の汎用アーキテクチャが示されている。第１に、例示のＳＤＭＰアーキテクチャ１００用の全体フレームワークを直下で説明する。本開示の教示に従い、ＳＤＭＰアーキテクチャ１００の実施形態は、以下でより詳細に説明するソフトウェア実装「処理ユニット」を採用する。ＳＤＭＰアーキテクチャ１００の重要な態様は、処理全体を、各部分のデータを容易に通信および転送できる別個の部分に分割できることである。これは、たとえばマルチキャストドメイン１０４Ａなどのドメインからセグメントまたはベース加工成果（必要な範囲で）へと生じるソースストリーム１０６の、初期処理によって容易となり、さらなる処理中にセグメントを記憶および取り出すために使用可能なＵＲＩ／ＵＲＬに関連して記憶され得る、サービスプロバイダ環境のＨＴＴＰドメイン１０４Ｂ内の「リソース」として識別されることになる。この初期処理は、図１に示された全体アーキテクチャのマルチキャストドメイン１０４Ａ内に配設された、入力処理ユニット（ＩＰＵ）１０８によって示される。一実施形態において、ソースストリームは、マルチキャストまたはユニキャストを介して提供されるＭＰＥＧ−ＴＳストリームである。他の実施形態において、他の特定のストリームタイプが採用可能である。さらに他の実施形態において、ソースストリームは暗号化および／またはエンコード、ならびにセグメント化または非セグメント化することができる。

本コンテキストにおいて、「セグメント」または「中間加工成果」または「ベース加工成果」は、（一般に、より長いセグメントによって促進される）伝送効率と、可変配信条件（たとえば、一般により短いセグメントによって促進される、使用可能なネットワーク帯域幅や、たとえばセルラおよびＷｉ−Ｆｉなどのアクセス技術間の遷移など）に適合させるための柔軟性とを平衡させる、持続期間（すなわち長さ）を有するメディアアイテムの連続部分を指す。例示の一実装において、セグメントは、約１秒から約１０秒の範囲の持続期間を有することができる。いくつかの実施形態または動作条件では、持続期間は潜在的により短くまたはより長くなり得る。

現行のシステムでは、サービスプロバイダは典型的には、マルチキャストＭＰＥＧ−ＴＳ形式のすべてのライブチャンネルを含む中央局を有することが可能であり、シングルトランスコーディング処理ユニット（メディアプラットフォーム上で実行する）は、チャンネルを、ＨＴＴＰドメイン、たとえばＨＴＴＰライブストリーミング（ＨＬＳ）、ＤＡＳＨ、またはＨＤＳセグメントに変換するように動作可能である。他方で、開示されたＳＤＭＰアーキテクチャは、たとえば様々なレベルの細分性で、ＨＴＴＰを介してアクセス可能なセグメント化形式のメディアストリームの存在を可能にし、より効率的かつ動的に設定可能な様式での最終配信のためにより多くのビットレートおよび再セグメント化サイズ（すなわち持続期間）を作成するための、他の処理ユニットによる処理を容易にする。

セグメント化された加工成果の記憶および転送を容易にするために、クラウド記憶／配信サービスネットワークが有利に採用可能である。当業者であれば、クラウド記憶は、分散様式またはその他で、私設、公衆、またはハイブリッドのネットワークとして実装可能であることを理解されよう。たとえば図１のＣＳＵ １１４は、「クラウド記憶ユニット」、すなわち、メディアコンテンツアイテムを記憶し、そのアイテムを（たとえばマルチキャスト配信技法を使用して）潜在的に多数の同時および／またはダウンストリーム消費者に配信するように特別に調整された、クラウドサービスまたはコンテンツ配信ネットワークを指す。

ＳＤＭＰアーキテクチャ１００は、ＨＴＴＰを使用するライブメディアプログラミングおよび／またはオンデマンドコンテンツを含む、様々なデジタル資産またはプログラム資産ならびにサービス（以下、「メディアコンテンツ」と呼ぶ）の、高性能ストリーミングを容易にすることを理解されたい。一般に、「メディアコンテンツ」または「コンテンツファイル」（または単に「コンテンツ」）という用語は、本特許開示の少なくともいくつかの実施形態に言及する際に使用される場合、ライブキャプチャメディアまたはオンデマンドメディア、たとえば無線無料ネットワークテレビ（ＴＶ）の番組またはプログラム、ケーブルネットワークまたは衛星ネットワークを介した有料ＴＶ放送プログラム、無料衛星ＴＶ番組、ＩＰＴＶ番組、オーバーザトップ（ＯＴＴ）およびビデオオンデマンド（ＶＯＤ）またはムービーオンデマンド（ＭＯＤ）の番組またはプログラム、タイムシフトＴＶ（ＴＳＴＶ）コンテンツなどを含むことが可能な、任意のタイプのオーディオ／ビデオコンテンツなどの、デジタル資産またはプログラム資産を含むことができる。したがって、図１のソースメディアストリーム１０６は、上記で指摘したようにベースセグメントまたは加工成果１０７を生成するために、入力処理ユニット（ＩＰＵ）１０８によって最初に処理される、任意のこうしたストリームを含むことが可能である。一実装において、ＩＰＵ １０８は、たとえば選択セグメント長さ／持続期間、フレームレート、およびベースビットレートでのエンコード／トランスコードなどの、選択メディア特徴を含む、ベースセグメントまたは加工成果（ＢＷＰ）１０７を生成するために、ソースメディアストリーム１０６を処理することができる。１つまたは複数のＣＳＵ １１４に結合された複数の処理ユニット１１２−１から１１２−Ｎは、複数レベルで追加の中間加工成果（ＩＷＰ）へのベースセグメントストリーム１０７を処理することが可能であり、セグメントは、図１では例示的にＩＷＰ １１５−１から１１５−３として示された異なるメディア特徴を有することが可能である。

１つまたは複数の出力処理ユニット（ＯＰＵ）１１６は、入力ストリーム、ＢＷＰストリーム、および／または様々なレベルのＩＷＰストリームにアクセスするように、ならびに、ＣＳＵ １１８に関連付けられた好適なストリーミング配信インフラストラクチャ１２０を介した、１つまたは複数のエンドユーザ機器またはデバイス、たとえばＵＥ １２２−１からＵＥ １２２−Ｎへの配信のためにＣＳＵ １１８にアップロード可能な、望ましいメディア特徴を有する最終加工成果（ＦＷＰ）１１７としてセグメントをパッケージングおよびアップロードするためにストリームを処理するように、動的に設定可能である。出力処理ユニット１１６は、最終セグメントに関して適切なマニフェストファイルを生成するため、ならびに、セグメント同期化およびフレーム整合を容易にするための、責務も負う。加えて、たとえばストリームアクセスポイント（ＳＡＰ）情報、プログラムクロック基準（ＰＣＲ）値、表示タイムスタンプ（ＰＴＳ）値、およびデコーディングタイムスタンプ（ＤＴＳ）値などの、最終セグメントに関する適切なタイミング情報も、出力処理ユニット１１６によって提供可能である。当業者であれば、アップロードされたＦＷＰセグメントは、Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ（ＭＰＥＧ）Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ（ＭＰＥＧ−ＤＡＳＨ）規格、ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ（ＨＬＳ）規格、ＳｉｌｖｅｒＬｉｇｈｔ（登録商標）Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ規格、およびＨＴＴＰ Ｄｙｎａｍｉｃ Ｓｔｒｅａｍｉｎｇ（ＨＤＳ）規格などのうちの少なくとも１つに準拠した、好適な適合ビットレート（ＡＢＲ）ストリーミング環境でアクセス可能であることを理解されよう。

一般に、ＳＤＭＰアーキテクチャ１００の様々な処理ユニットは、主にそれぞれの機能に応じて、トランスコーディング／トランスコード処理ユニット（ＴＰＵ）またはパッケージャ処理ユニット（ＰＰＵ）のいずれかに分類可能である。ある意味で、処理ユニットが入力ストリームのビットレートとは異なるビットレートを有する１つまたは複数の出力ストリームを生成するために入力ストリームを処理するように動作可能である場合、こうした処理ユニットをＴＰＵと呼ぶことができる。したがって、いくつかの実装において、着信処理ユニット（たとえばＩＰＵ １０８）はＰＰＵまたはＴＰＵを含むことができる。たとえば、ソースメディアストリーム１０６が、最終加工成果のビットレートになるようなビットレートですでにセグメント化およびエンコードされている場合、そのストリームをトランスコードする必要はないため、ＰＰＵはＩＰＵ １０８として動作するように設定可能である。他方で、ソースメディアストリーム１０６がエンコーディングまたはトランスコーディングを必要とする場合、ＴＰＵはＩＰＵ １０８として動作するように提供可能である。ＳＤＭＰ １００の出力処理機能に関しては、一般に、フェイルオーバー冗長性ならびに複数のＣＳＵ １１８へのＦＷＰの効率的なアップロードを促進させるために、マスターＰＰＵが１つまたは複数のスレーブＰＰＵに対して同期化される、マスター／スレーブ関係で組織することが可能な、複数のＰＰＵによって実行される。いくつかの事例では、１つまたは複数のＰＰＵが（セグメントが独立に作成された）自律ユニットとして動作可能である。ＩＰＵおよびＯＰＵの両方として動作するＰＰＵが、内部ＣＳＵからのセグメント（すなわちＢＷＰストリームおよび／またはＩＷＰストリーム）ではなくソース入力（たとえばマルチキャストＵＤＰ）を受信できることも可能であることを理解されたい。残りの処理ユニット１１２−１から１１２−Ｎは、一般に、分散ネットワークで、たとえばカスケードネットワークとして組織可能であり、各々が、入力ストリームを受信し、これを処理して異なるセットのメディア特徴を有する出力ストリームを生成するように動作する、ＴＰＵからなる（したがって、ＩＰＵ １０８もＴＰＵである、中間ＴＰＵとも呼ぶことができる）。したがって、中間ＴＰＵは、（ｉ）ベース加工成果セグメント１０７を第１レベルのＩＷＰストリームに処理するように、または、（ｉｉ）ｉ番目レベルのＩＷＰストリームを、ｉ＋１番目レベルのＩＷＰストリームに処理し、結果としてｉ番目レベルの加工成果セグメントがｉ＋１番目レベルの加工成果セグメントよりも高いビットレートを有するように動作可能な、処理ユニットとみなされ得る。ここでｉ＝１からＮである。追加／代替実施形態において、ＴＰＵは、代わりに入力の他のメディア特徴を変更するように動作可能であり、たとえばビットレートは同じままであり得るが、フレームレートおよび／または解像度は変換可能である。こうしたシナリオにおいて、ｉ番目レベルの加工成果セグメントおよびｉ＋１番目レベルの加工成果セグメントの特徴は、ビットレート関係と類似するが、必要な変更が加えられた他の関係を有することができる。

さらに、図１に示されるＳＤＭＰアーキテクチャ１００は、好ましくはたとえば需要の変化、リソースの可用性、需要に対してシステム性能に影響を与える他のパラメータなどのトリガ要因に従った、処理ユニットの作成および破壊（すなわち動的インスタンス化）を含むシステム動作の監視および制御、異なる用途に対するシステムリソース（たとえばハードウェアコンピューティングリソース）の請求および解除、処理ユニットの内部的（すなわち、たとえば特定のビットレートエンコーディングなどの特定タスクについての処理ユニットの動作をカスタマイズすること）および外部的（すなわち、別個のビットレートのセットに対するそれぞれの処理系統などの、望ましいより高度なフローまたは機能を達成するために、処理ユニットの入力および出力をまとめて接続すること）な両方の設定、などに対する責務を負う、全体システム管理エンティティとして動作可能であり得るオーケストレーションおよびリソース管理（ＯＲＭ）システムまたはサブシステム１２４を含む。特定の実装に応じて、トリガ要因の範囲および組み合わせは、かなり変化する可能性があり、たとえばネットワーク分析１２６−１（たとえば、エンドユーザへの最終加工成果セグメントストリームの配信に対する使用率）、手動またはその他であり得るサービスオペレータ始動信号またはアラーム１２６−２、特定のＳＤＭＰ設定の様々なエンティティに関してハードウェア／ソフトウェア障害またはサービス障害（たとえば停電、ハードウェア破壊、または他の機能不良など）に応答して生成される信号として、グループ化することができる。他の実装において、プログラム可用性（たとえば、特定の地理的領域内でのチャンネルまたはソースメディアストリームのスケジューリング情報を含む電子番組ガイド（ＥＰＧ）に基づく）ならびにネットワーク帯域幅利用およびサービス品質（ＱｏＳ）ベース基準１２６−３に基づく静的条件付けは、適切なトリガを生成するように動作可能である。さらに他の実装において、コンテンツ消費の予測モデリングを採用して、加入者層などに依存し得るある番組に対する需要急増を予測することが可能であり、好適なＴＰＵおよびＰＰＵを積極的にインスタンス化および設定するように、適応的なフィードバック制御シグナリングをＯＲＭ １２４に提供するように動作可能である。例示的な一実施形態において、ＯＲＭサブシステム１２４はソフトウェア実装型であり得、専用コンピュータハードウェア（たとえば分散型またはスタンドアロン型コンピュータ、サーバなどのいずれか）を使用するか、または同じコンピュータハードウェアを処理ユニット自体と共有することが可能である。処理ユニット、ＯＲＭサブシステム、および潜在的なＳＤＭＰ設定に関する他の詳細は、以下で説明する。

前述のＴＰＵおよびＰＰＵは、ＳＤＭＰアーキテクチャ１００の基本構築ブロックとして提供可能であり、処理ユニットは、ソフトウェア、ハードウェア、および／またはそれらの任意の組み合わせで実現または仮想化可能であることを理解されたい。一般に、こうした処理ユニットは、ソフトウェア実装ユニット、たとえば、説明する機能を提供するためにあるアプリケーションプログラムの命令を実行する好適なコンピュータハードウェアを、備えることができる。たとえばレコーダなどの構成要素または下位構成要素は、以下で説明するレコーダ関連機能を提供するためのレコーダアプリケーションプログラムの命令を実行する、コンピュータハードウェアによって構築され得る。処理ユニット（ＴＰＵまたはＰＰＵ）は、好ましくはメディアを変換し、これを、たとえば採集地点からパッケージングおよび配信地点などへと、ある段階から別の段階へと移動させるために相互動作する、アプリケーションプログラムの規定セットを含む。一般に、所与の処理ユニットの構成要素および／または下位構成要素は、たとえば単一サーバコンピュータなどの、密結合コンピュータハードウェアのセットによって形成され得る。しかしながら、異なる処理ユニットを、異なるコンピューティングハードウェア（たとえば異なるサーバ）上、または共有コンピューティングハードウェア（たとえば単一サーバ上の複数の処理ユニット）上に、配置することができる。当業者であれば、こうして下位のホストハードウェア要素から処理ユニットを抽出することは、開示された実施形態の有利な機能であることを理解されよう。

次に図２および図３に進むと、それぞれ、本特許出願の実施形態に従った、例示のＴＰＵおよびＰＰＵサブシステムのブロック図が示されている。図２において、ＴＰＵ ２００は例示的に複数の構成要素または下位構成要素、すなわちレコーダ（Ｒ）２０４、デコーダ（Ｄ）２０６、エンコーダ（Ｅ）２０８、セグメンタ（Ｓ）２１０、およびアップローダ（Ｕ）２１２を備えるものとして示されている。ＩＰＵの一部として使用される場合、レコーダ２０４はソースメディア（たとえばマルチキャスト、ＦＴＰ、ＨＴＴＰなど）のダウンロードの責務を負う。中間ＴＰＵの実装において、レコーダ２０４は、任意のＩＷＰストリームを含むアップストリームユニットからの入力ストリームを、ＣＳＵを介して受信するように動作可能である。もしも必要であれば、復号サービスも提供可能である。デコーダ２０６は、たとえばライブまたはＶＯＤコンテンツのいずれかなどの、ソースストリームに対して、ビデオデコードサービスを提供するように動作可能である。エンコーダ２０８は、１つまたは複数のビットレート（たとえば５００ Ｋｂから２．５ Ｍｂの範囲）にビデオエンコードサービスを提供するように動作可能である。セグメンタ２１０は、適用可能なセグメント化サービス（たとえばＨＬＳセグメントおよびｍ３ｕ８ファイル、スムーズストリーミングなど）を提供する。アップローダ２１２は、１つまたは複数のＣＳＵに対して暗号化およびアップロードのサービスを提供するように動作可能であり、動作条件および要件によって規定され得る。

ＴＰＵ ２００は、好ましくは複数タイプの設定を実装可能にする。１つのケースでは、ＴＰＵは単一ビットレートのみを出力可能であり、分散フレームワーク内で複数のビットレートを生成するために、他の単一出力ＴＰＵと組み合わせて使用可能である。他の設定では、ＴＰＵは、潜在的にシステムの分散型の性質を制限するが、デコード／エンコードの観点からシステムを最適化するために、複数のビットレートを出力することができる。例として、図２の入力２０２は、ソースメディアストリームまたはＩＷＰストリーム（特定のビットレートを有する）を含み得、出力２１４−１から２１４−Ｎは、Ｎ個の異なるビットレートでトランスコードされるコンテンツのＮ個の表現を含み得る。ＴＰＵ ２００は本発明のＳＤＭＰアーキテクチャ内の基礎的な構築ブロックであり、好ましくはローカルハードウェア（たとえば中央局内のローカルネットワークによって結合されたコンピュータ）を使用して、かつ／または、分散クラウドベース環境（たとえばワイドエリアネットワークによって相互接続された別々の局またはデータセンター内に配置されたコンピュータを使用する）内に、配設可能であることを理解されたい。

所与のシステムにおけるＴＰＵの性能は、所与のプラットフォーム上での分析、テスト、または動的評価（たとえば埋め込まれたテストスイートの実行による）のいずれかによって、適切に理解されることが好ましい。いずれのリソースが使用可能であるか、およびそのリソースらがシステム内でどのように配置されることになるかに関する判定は、ＴＰＵの理解された性能に基づくものとすることができる。一般的に、ＴＰＵは少なくともリアルタイム速度でストリームを処理し、好ましくは余裕を与えるために幾分速いことが要求され得る。所与のストリームについてリアルタイム要件に合致しないＴＰＵは、たとえばより低いビットレートのストリームを処理する場合、またはヴォールティング（vaulting）／記録（archival）などの非リアルタイム用途などの、他の方法で有用な可能性がある。ＴＰＵ実装は、そのサブシステムのうちの１つまたは複数、たとえばデコーダ２０６を、動的に使用不可にすることも可能である。これによってシステムは、関連付けられた機能が必要でないときにリソース消費を即時に低減させることができるが、その後、システムの動作環境における変化によって要求されたときには機能を即時に再導入することも可能である。さらに他の変形形態では、例示のＴＰＵ実装は、必要であればＰＰＵと共にトランスマックス（transmux）モードで動作するように設定することも可能である。ＴＰＵの観点から、トランスマックスは、ストリームのビデオおよびオーディオセルに手が加えられず、そのままで渡されることを意味することができる。エンドユーザ形式への最終変換は、ＰＰＵによって提供可能である。典型的には、ＴＰＵの出力は、ある持続期間のＭＰＥＧ−ＴＳセグメント（たとえば、１秒セグメントなどの時間スケール単位、またはピクチャ群（ＧＯＰ）単位のいずれかで、最低１ ＧＯＰもしくはその何分の一か）を含むことができる。

当業者であれば理解されるように、任意のセグメント化ベースシステムは、転送バジェットを考慮する前に、生成されるセグメントの少なくとも持続期間に等しい固有の待ち時間を有する可能性がある。ライブ線形アプリケーションでは、必ずしも短い待ち時間は要求されないが、たとえばスポーツイベントなどの動きの豊富なメディアを含むいくつかの特別なケースでは、待ち時間を短くすることが望ましい場合もあり得る。前述のＳＤＭＰアーキテクチャ１００は、ＴＰＵを別のＴＰＵの出力（たとえばデイジーチェーンまたはカスケード）から供給することが可能であるため、最低でもソースセグメントの持続期間に等しい待ち時間が生成されることになる。この待ち時間は、いくつかの方法で最小限にすることができる。たとえばＴＰＵによって生成されるセグメント持続期間は、最低でも１ ＧＯＰ（典型的には１〜３秒の間）またはＧＯＰの選択部分まで低減させることができる。次いでＰＰＵは、ＴＰＵ出力を組み合わせて、エンドユーザクライアントによる消費にとって望ましい最終セグメント持続期間（典型的には１０秒）を達成することができる。追加または代替として、ＴＰＵは、ハイエンドまたは特殊コンピューティングリソースが使用可能なときに、いくつかまたはすべての必要なビットレートを同時に生成することができる。

図３は、冗長設定３００で提供されるＰＰＵ ３１０Ａ／３１０Ｂの例示の実装のブロック図を示す。典型的には、単一のＰＰＵは、ソースメディア（たとえばＨＴＴＰまたは他のプロトコル）のダウンロードの責務を負い、もしも必要であればオプションとして復号サービスを容易にする、レコーダ（Ｒ）と、セグメント化および同期化サービス（たとえばＨＬＳセグメントおよびｍ３ｕ８ファイル、スムーズストリーミングなど）のためのセグメンタ（Ｓ）と、暗号化および（複数ＣＳＵへの）アップロードサービスのためのアップローダ（Ｕ）との、構成要素を備える。図３の冗長設定３００において、ＰＰＵ ３１０Ａはレコーダ３０４Ａ、セグメンタ３０６Ａ、およびアップローダ３０８Ａを備えるものとして示されている。同様に、ＰＰＵ ３１０Ａと同期関係３１６にあるＰＰＵ ３１０Ｂも、対応するレコーダ３０４Ｂ、セグメンタ３０６Ｂ、およびアップローダ３０８Ｂを備える。一般に、ＰＰＵは１つまたは複数のＴＰＵから出力を取得し、持続期間およびタイムスタンプ同期の両方の観点から、これらを再セグメント化する。次いで最終出力が１つまたは複数のＣＳＵにアップロードされ、消費デバイス（たとえばエンドユーザデバイス）によってアクセスされることになる。一実装において、ＰＰＵは、ＴＰＵによって直接エンコードされたデータまたは生のソースのいずれかを、トランスマックスするための機能も提供可能である。さらにＰＰＵは、異なるビットレートを有する複数の入力、または選択ビットレートを有する単一の入力のみを取り扱うように、設定可能である。複数の物理プラットフォーム全体にわたるスケーラビリティを可能にするために、ＰＰＵは、マスターまたはスレーブ／自律モードのいずれかで動作するように設定可能であり、マスターは、ｍ３ｕ８ファイルなどに更新が行われる前に、すべてのセグメントがＣＳＵにアップロードされていることを保証する。マスターＰＰＵは、複数のＣＳＵにアップロードするための動的設定も実行可能であり得、その設定によって、ボリュームが大きいときなどに追加のＣＳＵサービスを活動化させ得ることを理解されたい。

例として、図３のＰＰＵ ３１０Ａは、１つまたは複数のＴＰＵによって提供され得る複数の入力３０２−１から３０２−Ｍを受信するように動作可能な、マスターモードで示されている。マスターＰＰＵ ３１０Ａのアップローダ３０８Ａは、好適なビットレートの最終加工成果またはセグメントなどを、対応するインターフェース３１２−１から３１２−Ｎを介して複数のＣＳＵ ３１４−１から３１４−Ｎへアップロードするように動作可能である。当業者であれば、ＣＳＵが単に、データをあちこちに移動させ最終的にエンドユーザに提供するためにＳＤＭＰシステムによって使用される、分散型または集中型の記憶サービスであり得ることを理解されよう。一実装において、こうしたサービスは、外側から見ると（たとえばエンドユーザの観点からすると）従来のＣＤＮサービスのように見える可能性のある、クラウドベースサービスとして設定可能である。他の設定では、ＣＳＵは、ＴＰＵ、ＰＰＵ、および他の外部ＣＳＵの間でデータを記憶および移動させるためにＳＤＭＰによって使用される、私設ＣＳＵとしてプロビジョニング可能である。エンドユーザデバイスは、私設クラウド記憶ユニット内に含まれるデータにアクセスできないことになる。データは、システムに必要なセキュリティの全体レベルに応じて、暗号化される場合またはされない場合がある。別の設定では、ＣＳＵは、エンドユーザデバイスによって消費されることになる最終加工成果を記憶するために、システムによって使用され得る、外部または公衆ＣＳＵとして配置することができる。典型的には、このコンテンツは好適なデジタル著作権管理（ＤＲＭ）機構によって暗号化および保護することができる。コンテンツは、地理的性能（たとえばエッジサーバの位置を最適化するため）または冗長性の理由で、いくつかのＣＳＵ上で重複させることもできる。

図４は、本特許出願のためにソースメディア処理方法４００を実行するための１つまたは複数の実施形態で組み合わせ可能な様々な機能、ステップ、および動作に関するブロックを備える、フローチャートを示す。いくつかのブロック／動作がフロー形式で示されているが、本明細書の実施形態を実施するために必ずしもすべてのブロックまたは動作が必要であるとは限らないことを理解されたい。ブロック４０２で、たとえばＴＰＵまたはＰＰＵとすることが可能な入力処理ユニットによって、着信ソースメディアストリームが受信される。着信ソースメディアストリームの特徴に関して、たとえば、メディアストリームはセグメント化されるか否か、エンコードおよび／または暗号化されるか、適切なビットレートおよびフレームレート、セグメントサイズ（すなわち持続期間）などの、１つまたは複数の判定を行うことが可能であり、意思判定ブロック４０４に図示されている。着信メディアストリームが好適な特徴を有する場合、さらなる判定は、適切なパッケージャ処理が必要であるかどうかであり得る。必要である場合、処理ユニットはトランスマックスモードで動作可能であり、たとえば着信ストリームを処理し、結果として生じる最終加工成果を１つまたは複数のＣＳＵにアップロードするために適切に（再）パッケージおよび（再）セグメント化することができる。パッケージャ処理が必要でない場合、着信メディアは最小限に処理およびアップロードすることができる。これらの機能は、ブロック４０６、４１０、および４１２で示されている。ブロック４１０に示されているパッケージャ処理は、代替／追加実施形態において、アップローディング前に追加の処理が必要とされ得る、他の処理ユニット（たとえばＴＰＵ）に呼応して動作する様々なレベルのＰＰＵ機能の代表であり得ることを理解されたい。したがって、意思判定ブロック４０４の判定が、さらなる処理が保証されることを求めるものである場合、着信ソースメディアストリームは、異なる特徴（たとえばビットレート、セグメントサイズまたは持続期間、フレームレートなど）を有する複数レベルの加工成果へと処理することができる。前述のように、こうした処理は、動的に設定可能な配置構成で配置構成された１つまたは複数のＴＰＵによって実現可能である（ブロック４０８）。その後、ブロック４１０のパッケージャ処理は、加工成果を、配信およびエンドユーザによる消費のためにアップロードされ得る好適なメディア特徴を有する最終加工成果に（再）セグメント化および（再）パッケージングすることができる（ブロック４１２）。ＴＰＵ処理、ＰＰＵ処理、およびアップローディング（ブロック４０８、４１０、および４１２に記載）に必要なリソースは、ブロック４１４に図示されるように、リソースの動的設定のためのフィードバック制御信号として動作する様々なトリガに基づいて、動的にインスタンス化可能である。

次に図５〜図７に進むと、本特許出願の教示に従い、ソフトウェア規定メディアプラットフォームの実施形態が設定可能な様々な例示のネットワーク環境が示されている。図５の参照番号５００は、例示のＳＤＭＰアーキテクチャを採用しているメディア配信システムに関する潜在的な設定を示す。こうしたシステムでは、処理ユニットがデータを共有できるようにするために私設ＣＳＵを、特に、処理ユニットが実行しているメディアプラットフォームと共同設置されたＣＳＵを使用することが望ましい場合がある。しかしながら、ＣＳＵはクラウド内にあるか、またはハイブリッド設定であり得ることを理解されたい。図５において、参照番号５０８Ａ〜５０８Ｃは、３つのＴＰＵ ５０２、５０４、５０６と、同期制御通信５１２を介してマスター−スレーブ関係で提供される２つのＰＰＵ ５１０Ａ、５１０Ｂとの間に配設された、３つの代表的な私設ＣＳＵを指す。システム５００は、ライブプログラムが典型的にマルチキャストＭＰＥＧ−ＴＳストリームである、入力ソース（１）上で動作するように設定され得る。ＴＰＵ ５０２は、ソースストリーム（１）を受信し、私設ＣＳＵ ５０８Ａを介してＴＰＵ ５０４およびマスターＰＰＵ ５１０Ａの両方によって消費される、選択持続期間（たとえば１秒セグメント）およびビットレートのセグメント（３ａ）を作成する。ＴＰＵ ５０４および５０６によって追加のビットレートが作成可能であり、追加の私設ＣＳＵ ５０８Ｂおよび５０８Ｃを使用してＰＰＵ ５１０Ｂによって消費可能である。ビットレート関係に関して、セグメント３ａ、３ｂ、および３ｃのビットレートは同一であり得、これはセグメント６ａ、６ｂ、および６ｃのビットレートよりは高い可能性があり、セグメント６ａ、６ｂ、および６ｃのビットレートはセグメント９ａおよび９ｂのビットレートよりも高い可能性がある。ＰＰＵ ５１０Ａ、５１０Ｂは、アップロードおよび配信に適切なビットレート、セグメント持続期間などの最終加工成果セグメントを生成するために、これらの様々なセグメントを処理するように動作可能である。典型的には、ＰＰＵ ５１０Ａ、５１０Ｂのうちの１つを、アップロードされることになる最終セグメントに関するマスターマニフェストファイル、たとえばＰＰＵ ５１０Ａを生成するように指定することができる。マスターＰＰＵ ５１０Ａは、すべての対応するセグメントがアップロードされると、好適なインターフェース５１６−Ａ（１）から５１６−Ａ（Ｋ）を介して１つまたは複数のＣＳＵ ５１４−１から５１４−Ｋに記憶されるｍ３ｕ８制御ファイル（たとえばプレイリスト）を更新するように、さらに動作可能である。制御チャネル５１２を介してＰＰＵ ５１０ＡとＰＰＵ ５１０Ｂとの間で実現される同期化によって、引き継ぐことが必要になった場合、ＰＰＵ ５１０Ｂも、好適なインターフェース５１６−Ｂ（１）から５１６−Ｂ（Ｋ）を介してＣＳＵ ５１４−１から５１４−Ｋにファイルをアップロードするように動作可能である。

ＴＰＵ ５０２、５０４、５０６、およびＰＰＵ ５１０Ａ〜５１０Ｂに関して、それらが配置される位置に応じていくつかの設定が可能である。一配置構成では、システム５００のＴＰＵおよびＰＰＵのうちの１つまたは複数は、（たとえば単一の局またはデータセンター内の）それぞれの処理機能を実行するローカルハードウェアメディアプラットフォームに配置可能である。クラウド配置構成では、システム５００のＴＰＵおよびＰＰＵのうちの１つまたは複数は、クラウドサービスプロバイダ（ＣＳＰ）によって提供される別々のハードウェア処理リソース上でホスト可能である。したがって、ハイブリッド設定を含む設定の範囲は、プロビジョニングに関するＴＰＵ／ＰＰＵの組み合わせに応じて実装可能である。たとえば、１つのハイブリッド設定において、ＴＰＵ ５０２、ＴＰＵ ５０４、およびＰＰＵ ５１０Ａはそれぞれのローカルハードウェアメディアプラットフォームに配置可能であるが、ＴＰＵ ５０６およびＰＰＵ ５１０ＢはＣＳＰまたはそれぞれのＣＳＰによってサポート可能である。同様に、いくつかの他の設定が有利に取得可能である。

図６は、単一のＰＰＵ設定を有する例示のシステム６００を示す。図７は、単一のＰＰＵ設定と組み合わされたマルチビットレートＴＰＵ設定を有する、例示のシステム７００を示す。当業者であれば、図５のシステム５００に関して上記で述べた説明が、変更すべきところは変更して、図６および図７の実施形態にも一般に適用可能であるため、反復しないことを理解されよう。システム６００に関して、単一のＰＰＵ ６０２は、パッケージャの処理、および続く対応するインターフェース６０４−１から６０４−Ｋを介したＣＳＵ ５１４−１から５１４−Ｋへのアップロードのために、３つのＩＷＰセグメントストリーム３ｂ、６ｂ、および９ｂのすべてをそれぞれＣＳＵ ５０８Ａ〜５０８Ｃを介して受信するように動作可能であることに留意されたい。図７のシステム７００では、２つのＣＳＵ ５０８Ａ、５０８Ｂに結合された２つのＴＰＵ ５０２、５０４のみが提供される。ＴＰＵ ５０４は、ＣＳＵ ５０８Ａを介して受信した１つの入力セグメントストリーム３ｃから、２つの出力セグメントストリーム６ａおよび９ａを生成するように動作可能である。出力セグメントストリーム６ａおよび９ａの両方がＣＳＵ ５０８Ｂに提供され、ＣＳＵ ５０８Ａを介して受信したセグメントストリーム３ｂに加えて、ストリーム６ｂおよび９ｂとして単一のＰＰＵ ６０２によって消費される。

以前に指摘したように、例示のＳＤＭＰアーキテクチャの処理ユニットは、たとえばソフトウェア実装、カスタムハードウェア実装などの多くの方法で、ならびに適切な仮想化技法を使用して実装可能である。ＴＰＵエンティティを例として使用し、あるＩ／Ｏ仮想化（ＩＯＶ）ベースの実装について直下で説明する。

図８は、実施形態に従ったＴＰＵのＩＯＶベースの実装を示す。本明細書で開示されるＴＰＵ／ＰＰＵのアーキテクチャは、たとえばＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ−Ｓｐｅｃｉａｌ Ｉｎｔｅｒｅｓｔ Ｇｒｏｕｐ（ＰＣＩ−ＳＩＧ）、またはその変形であるＰＣＩ−ＳＩＧ ＥｘｐｒｅｓｓもしくはＰＣＩ−ＳＩＧｅなどの、Ｉ／Ｏ仮想化技術を利用する実装を可能にすることを理解されたい。特に、実行可能ＰＣＩｅデバイスがいかなるランタイムオーバーヘッドとも直接共有されないようにできるＰＣＩ−ＳＩＧ ＩＯＶ標準化機構が、仮想化アーキテクチャ内に実装可能である。参照番号８００はシングルルートＩＯＶ（ＳＲ−ＩＯＶ）アーキテクチャを指し、物理機能（ＰＦ）ドライバ８１６は、下位のＳＲ−ＩＯＶ対応ハードウェア８０６の機能を確立および設定するために、起動時に物理機能（ＰＦ）８１４と通信するように動作可能である。一配置構成において、ＳＲ−ＩＯＶ対応ハードウェア８０６は、仮想機能（ＶＦ０からＶＦＮ）のブロック８０８に関連付けられたハードウェア圧縮システムオンチップ（ＳＯＣ）８１２を備えることができる。仮想機械モニタ（ＶＭＭ）８０４は、仮想機械（ＶＭ）環境８０２内でサポートされる１つまたは複数のＴＰＵ ８２０−１から８２０−Ｋがリソースを利用できるようにする、仮想機能（ＶＦ）ドライバ８１８へのアクセスを提供するように動作可能である。典型的な設定において、ＴＰＵは、１つはデコード用、１つはエンコード用の、２つのＶＦリソースを利用して、入力８２２から複数の出力８２４−１から８２４−Ｎを生成することができる。同じ分散ＶＭシステム８０２において、他のＴＰＵは、必要であれば、より低品質の出力に対しては単に汎用計算リソースを利用すればよい。以下で詳細に説明するように、静的または動的のいずれかの様式で（ＶＭＭ／ＰＦドライバを介して）使用可能なリソースを管理するために、オーケストレーションおよびリソース管理（ＯＲＭ）サブシステムを提供することができる。

図９に示される別の実装において、例示のＳＤＭＰアーキテクチャ９００は、Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ（ＩａａＳ）プロビジョニングモデル（たとえばＯｐｅｎＳｔａｃｋ）と、シングルルートおよびマルチルートのＩＯＶ（ＳＲ／ＭＲ−ＩＯＶ）リソースを含む特殊ハードウェアリソースとの両方を含むことができる。仮想化プロビジョニングモデルとして、例示のＳＤＭＰのＩａａＳ ９０２は、各々がＳＤＭＰの１つまたは複数のエンティティまたはサブシステムを実行する、複数のＶＭをサポートするように動作可能である。ＶＭ ９０４はＯＲＭ、ＣＳＵ、およびＰＰＵサブシステムをサポートするように動作可能であり、ＶＭ ９０６は複数のＴＰＵをサポートするように動作可能である。ＶＭはＶＭ ９０８によって示されるように、単一のＴＰＵをサポートすることもできる。ＩａａＳ ９０２とハードウェアリソースとの間のアクセスは、複数のＶＭＭ ９１０〜９１４によって容易にすることができる。例として、汎用計算および記憶リソース９１６、ならびに複数のＳＲ／ＭＲ−ＩＯＶ ９１８−１から９１８−３が例示され、特定のＩＯＶがハードウェア圧縮ＳＯＣおよび関連付けられたＶＦモジュールを含む。他の例として、ＳＲ／ＭＲ−ＩＯＶ ９１８−１のＶＦ０〜ＶＦ２はＴＰＵの第１のブロック９０６Ａをサポートすることが可能であり、ＳＲ／ＭＲ−ＩＯＶ ９１８−２のＶＦ０〜ＶＦ２はＶＭ ９０６のＴＰＵの第２のブロック ９０６Ｂをサポートすることが可能である。同様に、単一の仮想機能、たとえばＳＲ／ＭＲ−ＩＯＶ ９１８−３のＶＦ０は、ＶＭ ９０８の単一のＴＰＵをサポートすることが可能である。

図１０は、実施形態に従った設定トリガに応答して、ＴＰＵ、ＰＰＵ、およびその間の相互接続を動的にインスタンス化および設定するように動作可能な、例示のＯＲＭアーキテクチャ１０００のブロック図を示す。広義には、ＯＲＭアーキテクチャ１０００は、例示のＳＤＭＰシステム内での動的設定機能およびリソース認識／割り振りを容易にするための、クラウドコンピューティングプラットフォーム１００２上へのＯＲＭ機能のプロビジョニングを含む。ＯＲＭアーキテクチャ１０００は、需要、ネットワーク利用、ＱｏＳなどに一致する適切なネットワーキング、記憶、および計算サービスがシステムに割り振られることを保証するために、クラウドサービス（たとえばＯｐｅｎＳｔａｃｋ）を活用するように設定可能である。ＯＲＭ機能のネットワーキングモジュールまたはサブシステム１００４は、例示のＳＤＭＰ向けに適切なＴＰＵ、ＰＰＵ、およびＣＳＵを動的に作成および設定するように要求するための責務を負う。ＯＲＭ機能内で調整可能なフィーチャ設定１００６は、たとえばＴＳＴＶ、ネットワークベースビデオレコーディング（ＮＰＶＲ）などのコンテンツのある操作を容易にするための、ＴＰＵおよび／またはＰＰＵの設定をサポートするように動作可能である。たとえばＴＳＴＶは、新しいプログラムディレクトリを作成し、フィーチャ設定モジュール１００６によって容易にされ得るプログラム作成のためのインバンドまたはアウトバンドシグナリングを受信するように、ＰＰＵを設定するように要求する。加えて、ＴＰＵ／ＰＰＵに使用可能な汎用計算リソース／サービス１０１０、およびＴＰＵに使用可能な特殊計算リソース／サービス１０１２が、圧縮のための専用ハードウェアを含むことが可能なＯＲＭによって動的にプロビジョニング可能である。可能であれば、リソースは有用性を最大限にするために（前述のようなＳＲ−ＩＯＶおよびＭＲ−ＩＯＶなどの技術を介して）仮想化することができる。

ＯＲＭ機能は、様々なリソースをインスタンス化および設定するため、ならびに、たとえば処理１０１６などの好適なハードウェアを使用するメディア処理方法の実施形態（たとえば図４に記載）を実現するために、不揮発性メモリに記憶された適切なＳＤＭＰサービス論理１０１４をさらに含むことができる。加えて、ＳＤＭＰ論理１０１４への入力として動作可能な設定トリガ信号を含む、制御信号の通信を容易にするために、適切なネットワークインターフェース（Ｉ／Ｆ）１０１８を提供することができる。

ＯＲＭアーキテクチャ１０００を利用する例示のＳＤＭＰシステムが、予め特定のチャンネルに対して動的なサービス品質を規定するように設定可能であることを理解されたい。たとえばＯＲＭ機能は、しきい値、要求、トラップ、および外部イベントに基づいてリソースを再割り振りするための責務を負うことができる。例としてＯＲＭ機能は、以下のうちの１つまたはいくつかを実行することができる。
（ｉ）チャンネルに対して最低サービス品質、すなわち最低数の適応的ビットレート、解像度、フレームレートおよびビットレートをセットする。採集要求が受け入れられると、この最低サービス品質が保証されることになる。
（ｉｉ）リソースが許可する場合、より高いサービス品質、すなわち適応的ビットレート数の増加をセットする。
（ｉｉｉ）最終コンテンツを消費しているアクティブクライアントの数に基づいてサービス品質を管理する、エンドユーザしきい値をセットする。典型的には、より多数のアクティブユーザが、統計的に帯域幅がより大きく変動する（たとえばより多くの人がセルラネットワークを介して視聴している、など）という事実により、より適応的なビットレートを要求することになる。
（ｉｖ）電子番組ガイド情報および／または他の制御対象外チャンネルに基づくしきい値、すなわちスポーツイベントに関する最低サービス品質。
（ｖ）チャンネルに対する待ち時間しきい値。より短い待ち時間は、生のソースのデコードおよび後続のエンコードを同時に行うための追加のリソースを必要とする可能性がある。

当業者であれば理解可能なように、これらのタイプのしきい値およびトラップは、有利なことにシステム全体が任意の所与の時点で適切なサービス品質をアクティブに管理できるようにし得る。

さらに例示のＳＤＭＰシステムは、アーキテクチャ全体のスケーラブルかつ分散的な性質により、シームレスおよび非シームレスの両方の冗長性をサポートすることができる。例として、以下のタイプの冗長性が実装可能である。
（ｉ）非稼働のＴＰＵ、ＰＰＵ、およびＣＳＵの自動交換。ＯＲＭエンティティは稼働中エンティティを監視し、障害を検出した場合、新しいリソースをスピンアップする。
（ｉｉ）リソースが制約されている場合、ＯＲＭエンティティは他のサービスをその最低サービス品質まで低下させ、結果として障害のあるエンティティを交換するためにリソースを解放することができる。
（ｉｉｉ）シームレスなフェイルオーバーの場合、代替のＣＳＵ位置にアップロードするか、またはシームレスに切り替える準備の整った、依然としてアクティブモードにある重複ＴＰＵ、ＰＰＵ、およびＣＳＵが作成可能である。

次に図１１を参照すると、実施形態に従った例示のＳＤＭＰアーキテクチャの要素を実現するように設定可能な、分散ハードウェアプラットフォーム１１００のブロック図が示されている。プラットフォーム１１００は、ＴＰＵ、ＰＰＵ、もしくはＯＲＭサブシステム、またはそれらの任意の組み合わせ／下位組み合わせとして動作するように個別化および／または仮想化することが可能であることを理解されたい。バス構造１１０４に結合された１つまたは複数のプロセッサまたはプロセッサボード１１０２−１から１１０２−Ｎが、プラットフォーム１１００の分散処理および全体制御をサポートするために提供可能である。バス１１０４は、追加または周辺バス１１０８、１１１０まで延在させるかまたはこれらに結合するために、１つまたは複数のバスブリッジまたはバスコントローラ１１０６−１、１１０６−２に結合可能であり、追加または周辺バス１１０８、１１１０は複数のインターフェース（Ｉ／Ｆ）をサポート可能である。一具体化において、こうしたインターフェースのうちの１つまたは複数は、内部および外部のデータベース、コンテンツプロバイダ、他のＴＰＵ、ＰＰＵ、および私設ＣＳＵなどの内部エンティティとのインターフェースを実現可能である。加えて、１つまたは複数のインターフェースは、内部および／または外部のネットワークおよびエンティティとインターフェースしているトリガ信号をサポートすることができる。例として、Ｉ／Ｆ １１１２−１／１１１２−２および１１１４−１／１１１４−２は、例示の実装において動作可能なこうしたインターフェースの代表である。

プラットフォーム１１００が提供されたメモリサブシステム１１１９は、複数のメモリモジュール１１１８−１から１１１８−Ｍ、ならびに、永続メモリモジュール１１１７などの不揮発性メモリモジュールに関してメモリ動作を制御するための、１つまたは複数のメモリコントローラ１１１６を含むことができる。本開示の教示に従い、１つまたは複数のソフトウェアプロセス、モジュール、ブロック、ルーチン、スレッドなどとして組織および／または実行され得るプログラム命令は、メディア処理論理および／またはＴＰＵ、ＰＰＵ、もしくはＯＲＭサブシステムの１つまたは複数の機能を実現するために、永続メモリ１１１７に記憶するかまたはアップロード／ダウンロードすることができる。したがって命令を含む持続性コンピュータ可読メディアが永続メモリモジュール１１１７の一部として具現化可能であり、命令は、たとえばＳＤＭＰ論理ならびに好適なアプリケーションプロセスの実行を含む、プラットフォーム１１００の個別化された具体化において、様々な機能を実現するように実行可能である。

前述の発明を実施するための形態に基づき、本発明の実施形態は、プロバイダが以下の非網羅的リストに記載したいくつかの方法で投資を最大化できるようにし得るものであることを理解されたい。
− ビットレートを動的に追加／除去する。
− クラウド記憶へのアップロードを動的に追加／除去する。
− 分析を使用して、（たとえば、視聴者の増加に対処する、品質を向上させるなどのために）追加のビットレートが追加／除去されるべきであるかどうかを判別する。
− 分析を使用して、リソースをシフトする（すなわち、需要ごとに３ＧビットレートからＷｉ−Ｆｉビットレートへ；多くの需要および帯域幅の可用性に基づき細分性のより高い使用可能ビットレート）。
− より高品質のイベント（たとえば、サンデーナイトゲーム）をスケジューリングする。
− リソース（たとえばＴＰＵ／ＰＰＵ）をクラウド内に配置する。
− 高速ウォームスタートアップ（すなわち、低ビットトランスコードは実行しているが、セグメント化／アップロードは発生していない）。
− 冗長性（たとえば、上昇可能な実行中の低ビットレートのバックアップチャンネルを有するなど）。
− リソースを割り振り、以下の例を含む様々な入力に基づいて設定する。（１）電子番組ガイド（ＥＰＧ）からのプログラミング情報、（２）位置、サービスレベル契約（ＳＬＡ）などのユーザプロファイル情報、（３）性能の変化（たとえば電力管理のための内部調整）に関する処理ユニットからの情報。
− トランスコーディング機能に対してＩ／Ｏハードウェア抽象化を提供する。

本開示の様々な実施形態の上記説明において、本明細書で使用される用語は特定の実施形態を説明するためのみのものであり、本発明を限定することは意図されていないことを理解されたい。特に規定されていない限り、本明細書で使用されるすべての用語（技術用語および科学用語を含む）は、本発明が属する分野の当業者が一般的に理解するのと同じ意味を有する。一般に使用される辞書に規定されているような用語は、本明細書および関連分野との関連におけるその用語の意味に一致する意味を有するものと解釈されるべきであり、本明細書で明示的に規定される理想的または過度に形式的な意味で解釈されないものであることを、さらに理解されよう。

本明細書では、コンピュータ実装方法、装置（システムおよび／もしくはデバイス）ならびに／またはコンピュータプログラム製品のブロック図および／またはフローチャートの図を参照しながら、少なくともいくつかの例示の実施形態を説明する。ブロック図および／またはフローチャートの図のブロック、ならびにブロック図および／またはフローチャートの図内のブロックの組み合わせは、１つまたは複数のコンピュータ回路によって実行されるコンピュータプログラム命令によって実装可能であることを理解されよう。こうしたコンピュータプログラム命令は、汎用コンピュータ回路、特定用途向けコンピュータ回路、および／または、機械を製造するための他のプログラマブルデータ処理回路のプロセッサ回路に提供可能であるため、結果として、コンピュータおよび／または他のプログラマブルデータ処理装置のプロセッサを介して実行する命令は、ブロック図および／またはフローチャートのブロックに指定された機能／動作を実装するために、トランジスタ、メモリ位置に記憶された値、およびこうした回路内の他のハードウェア構成要素を変換および制御し、そのことによって、ブロック図および／またはフローチャートのブロックに指定された機能／動作を実装するための手段（機能）および／または構造を作成する。加えて、特定の様式で機能するようにコンピュータまたは他のプログラマブルデータ処理装置に命じることが可能な、コンピュータプログラム命令は、有形のコンピュータ可読メディア内にも記憶可能であり、結果として、コンピュータ可読メディア内に記憶された命令は、ブロック図および／またはフローチャートのブロックに指定された機能／動作を実施する命令を含む製品を製造する。

前述のような有形で持続性のコンピュータ可読メディアは、電子、磁気、光、電磁、または半導体データ記憶のシステム、装置、またはデバイスを含むことができる。コンピュータ可読メディアのより特定の例は、ポータブルコンピュータディスケット、ランダムアクセスメモリ（ＲＡＭ）回路、読み取り専用メモリ（ＲＯＭ）回路、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭまたはフラッシュメモリ）回路、ポータブルコンパクトディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、およびポータブルデジタルビデオディスク読み取り専用メモリ（ＤＶＤ／ブルーレイ）を含む。コンピュータプログラム命令は、コンピュータおよび／または他のプログラマブルデータ処理装置にロードするかまたは別の方法でダウンロードし、コンピュータ実装プロセスを生成するためにコンピュータおよび／または他のプログラマブル装置上で一連の動作ステップを実行させることも可能であり、結果としてコンピュータまたは他のプログラマブル装置上で実行する命令は、ブロック図および／またはフローチャートのブロックに指定された機能／動作を実装するためのステップを提供する。したがって本発明の実施形態は、集合的に「回路」、「モジュール」、またはそれらの変形として呼ばれることのある、デジタル信号プロセッサなどのプロセッサ上で実行するハードウェアおよび／またはソフトウェア（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）内で具現化可能である。

さらに、少なくともいくつかの追加または代替の実装において、ブロック内に記載された機能／動作は、フローチャートに示された順序とは異なって生じることが可能である。たとえば連続して示されている２つのブロックはほぼ同時に実行可能であるか、または関連する機能／動作に応じて、ブロックは時には逆順で実行可能である。さらにフローチャートおよび／またはブロック図の所与のブロックの機能は、複数のブロックに分離可能であり、かつ／または、フローチャートおよび／またはブロック図の２つまたはそれ以上のブロックの機能は少なくとも部分的に統合可能である。さらに、いくつかの図は、通信の主要方向を示すために通信経路上に矢印を含むが、通信は示された矢印とは反対の方向にも発生可能であることを理解されたい。最終的に、図示されたブロック間に他のブロックを追加／挿入することが可能である。

したがって、本開示の図面に示されたフローチャートのいずれかに示された、動作、ステップ、機能、構成要素、またはブロックの順序またはシーケンスは、特定の動作、ステップ、機能、構成要素、またはブロックの削除または省略を含めて、特定のフローチャート内で修正、変更、置換、カスタマイズ、または別の方法で再配置可能であることを、はっきりと理解されたい。さらに、本特許開示の教示を実施するための１つまたは複数のプロセスに関して、追加の変形、修正、および構成を実現するために、特定のフローチャート内に示された動作、ステップ、機能、構成要素、またはブロックは、別のフローチャート内に示された動作、ステップ、機能、構成要素、またはブロックを用いて、相互に混合するかまたは別の方法で相互に配置または再配置することが可能である。

様々な実施形態を詳細に図示および説明してきたが、特許請求の範囲はいかなる特定の実施形態または例にも限定されるものではない。上記の発明を実施するための形態のいずれも、任意の特定の構成要素、要素、ステップ、動作、または機能が不可欠であり、特許請求の範囲に含まれなければならないことを示唆するものと読み取るべきではない。単数形で言及されている要素は、特に明示的に記載されていない限り「唯一」を意味するものとは意図されておらず、「１つまたは複数」を意味する。当業者にとって既知の上記で説明する実施形態の要素と等価のすべての構造および機能は、参照により本明細書に明示的に組み込まれ、本特許請求の範囲によって包含されることが意図される。したがって、当業者であれば、本明細書で説明する例示の実施形態は、以下に添付の特許請求の範囲の趣旨および範囲内にある様々な修正および変更によって実施可能であることを理解されよう。

Claims (7)

1. ソースメディアストリーム（１０６）を１つまたは複数のエンドユーザ（１２２−１から１２２−Ｎ）への配信用の最終加工成果セグメント（１１７）に処理するように動作可能な、メディア処理システム（１００）であって、
   前記ソースメディアストリーム（１０６）をベース加工成果セグメントのストリーム（１０７）に区分するように設定された入力処理ユニット（１０８）であって、各ベース加工成果セグメントは選択時間持続期間を有し、ベースビットレートを有するようにトランスコードされる、入力処理ユニット（１０８）と、
   複数のトランスコーディング処理ユニット（１１２−１から１１２−Ｎ、２００）のカスケードネットワークであって、トランスコーディング処理ユニット（２００）は、（ｉ）前記ベース加工成果セグメント（１０７）を第１レベルの中間加工成果セグメントストリームに処理するように、または、（ｉｉ）ｉ番目レベルの中間加工成果セグメントストリームを、ｉ＋１番目レベルの中間加工成果セグメントストリームに処理し、結果として前記ｉ番目レベルの中間加工成果セグメントが前記ｉ＋１番目レベルの中間加工成果セグメントよりも高いビットレートを有するように、動作可能である、カスケードネットワークと、
   前記ベース加工成果セグメントのストリーム（１０７）および中間加工成果セグメントストリーム（１１５−１から１１５−３）のうちの１つまたは複数を、複数のビットレートおよびセグメントサイズを有する前記最終加工成果セグメント（１１７）に処理するように設定された、１つまたは複数のパッケージャ処理ユニット（１１６、３００）と、
   前記ベース加工成果セグメントのストリーム（１０７）および１つまたは複数の中間加工成果セグメントストリーム（１１５−１から１１５−３）の記憶および移送を容易にするために、前記入力処理ユニット（１０８）、複数のトランスコーディング処理ユニット（１１２−１から１１２−Ｎ、２００）、および前記１つまたは複数のパッケージ処理ユニット（１１６、３００）に、動作可能に結合された、１つまたは複数のクラウド記憶／サービスユニット（１１４）と、
   １つまたは複数の設定トリガ（１２６−１から１２６−３）に応答して前記ソースメディアストリーム（１０６）を適応的に処理するために、前記１つまたは複数のクラウド記憶サービスユニット（１１４）を介して、前記入力処理ユニット（１０８）、複数のトランスコーディング処理ユニット（１１２−１から１１２−Ｎ、２００）、および前記１つまたは複数のパッケージ処理ユニット（１１６、３００）、およびそれらの間のそれぞれの接続を、動的にインスタンス化および設定するように動作可能な、オーケストレーションおよびリソース管理ユニット（１２４）と
   を備える、システム（１００）。
2. 前記入力処理ユニット（１０８）、複数のトランスコーディング処理ユニット（１１２−１から１１２−Ｎ、２００）、および前記パッケージ処理ユニット（１１６、３００）のうちの少なくとも１つは、クラウドネットワーク内に配設されている、請求項１に記載のメディア処理システム（１００）。
3. 前記入力処理ユニット（１０８）、複数のトランスコーディング処理ユニット（１１２−１から１１２−Ｎ、２００）、および前記パッケージ処理ユニット（１１６、３００）のうちの少なくとも１つは、ローカルハードウェアメディアプラットフォーム内に配設されている、請求項１に記載のメディア処理システム（１００）。
4. 前記パッケージャ処理ユニット（１１６、３００）のうちの１つはマスターモードで動作するように設定され、残りのパッケージャ処理ユニットはスレーブまたは自律モードで動作するように設定されている、請求項１に記載のメディア処理システム（１００）。
5. 前記マスターモードのパッケージャ処理ユニット（１１６、３００）は、セグメントサイズを同期し、フレーム整合を容易にし、適切なタイミング情報を提供し、前記最終加工成果セグメント（１１７）に対するマニフェストファイルを生成するように動作可能である、請求項４に記載のメディア処理システム（１００）。
6. 前記マスターモードのパッケージャ処理ユニット（１１６、３００）は、前記最終加工成果セグメント（１１７）および関連付けられたマニフェストファイルを、前記１つまたは複数のエンドユーザがアクセス可能なクラウド配信ネットワーク（１１８、１２０）にアップロードするように動作可能である、請求項４に記載のメディア処理システム（１００）。
7. 前記１つまたは複数の設定トリガ（１２６−１から１２６−３）は、（ｉ）前記最終加工成果セグメントのストリーム（１１７）の前記エンドユーザ（１２２−１から１２２−Ｎ）への前記配信に関連したネットワーク分析、（ｉｉ）サービスオペレータ始動アラーム、（ｉｉｉ）ハードウェアまたはソフトウェア障害、（ｉｖ）地理的領域内の前記ソースメディアストリーム（１０６）のスケジューリング情報を含む電子プログラムガイド（ＥＰＧ）のうちの、少なくとも１つに応答して生成される、請求項１に記載のメディア処理システム（１００）。

Images