JP2013516847A - クライアントデバイスへのマネージドネットワーク上でのテレビ放送およびアンマネージドネットワーク上での双方向コンテンツの提供 - Google Patents

Abstract

クライアントデバイスは、マネージドネットワーク上で双方向識別子を含有する放送コンテンツ信号を受信する。双方向識別子は、ヘッダに含まれるか、またはデジタルビデオデータ内に組み込まれる、トリガであってもよい。トリガの識別に応じて、クライアントデバイスは、アンマネージドネットワーク上で双方向コンテンツのユーザ要求を送信する。
例えば、マネージドネットワークは、一方向衛星テレビネットワーク、ＩＰテレビネットワーク、またはケーブルテレビネットワークであってもよく、アンマネージドネットワークは、インターネットであってもよい。クライアントデバイスは、マネージドネットワークからデータを受信することと、アンマネージドネットワークからデータを受信することとを切り替える。双方向コンテンツのビデオ符号化パラメータは、オーディオ伝送帯域幅の検出された変動に基づいて変化させられる。

Description

（優先権主張および関連出願）
本願は、米国特許出願第１２／６５１，２０３号（本願と同一名称、２００９年１２月３１日出願）の優先権を主張する。

米国特許出願第１２／６５１，２０３号は、米国特許出願第１２／４８９，０１７号（本願と同一名称、２００９年６月２２日出願）の一部継続出願である。

米国特許出願第１２／４８９，０１７号は、米国特許出願第１２／００８，６９７号（２００８年１月１１日出願、名称「Ｉｎｔｅｒａｃｔｉｖｅ Ｅｎｃｏｄｅｄ Ｃｏｎｔｅｎｔ Ｓｙｓｔｅｍ ｉｎｃｌｕｄｉｎｇ Ｏｂｊｅｃｔ Ｍｏｄｅｌｓ ｆｏｒ Ｖｉｅｗｉｎｇ ｏｎ ａ Ｒｅｍｏｔｅ Ｄｅｖｉｃｅ」）の一部継続出願であり、この出願自身は、米国仮特許出願第６０／８８４，７７３号（２００７年１月１２日出願）、米国仮特許出願第６０／８８４，７４４号（２００７年１月１２日出願）および米国仮特許出願第６０／８８４，７７２号（２００７年１月１２日出願）からの優先権を主張する。

米国特許出願第１２／４８９，０１７号は、また、米国特許出願第１２／００８，７２２号（２００８年１月１１日出願、名称「ＭＰＥＧ Ｏｂｊｅｃｔｓ ａｎｄ Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ Ｕｓｉｎｇ ＭＰＥＧ Ｏｂｊｅｃｔｓ」）の一部継続出願であって、この出願自身は、米国仮特許出願第６０／８８４，７７３号（２００７年１月１２日出願）、米国仮特許出願第６０／８８４，７４４号（２００７年１月１２日出願）、および米国仮特許出願第６０／８８４，７７２号（２００７年１月１２日出願）からの優先権を主張する。

米国特許出願第１２／４８９，０１７号は、また、米国仮特許出願第６１／１３３，１０２号（２００８年６月２５日出願、名称「Ｐｒｏｖｉｄｉｎｇ Ｔｅｌｅｖｉｓｉｏｎ Ｂｒｏａｄｃａｓｔｓ ｏｖｅｒ ａ Ｍａｎａｇｅｄ Ｎｅｔｗｏｒｋ ａｎｄ Ｉｎｔｅｒａｃｔｉｖｅ Ｃｏｎｔｅｎｔ ｏｖｅｒ ａｎ Ｕｎｍａｎａｇｅｄ Ｎｅｔｗｏｒｋ ｔｏ ａ Ｃｌｉｅｎｔ Ｄｅｖｉｃｅ」）からの優先権を主張する。

これらの関連出願の開示は、それらの全体が参照することによって本明細書に援用される。

（技術分野）
本発明は、双方向コンテンツを遠隔デバイスに提供するためのシステムおよび方法に関し、より具体的には、マネージドおよびアンマネージドネットワークの両方を採用するシステムおよび方法に関し、アンマネージドネットワークは、高い待ち時間および高い帯域幅の可変性を有する。

ケーブルテレビシステムでは、ケーブルヘッドエンドは、コンテンツを１人以上の加入者に伝送し、コンテンツは、符号化された形式で伝送される。典型的には、コンテンツは、デジタルＭＰＥＧビデオとして符号化され、各加入者は、ＭＰＥＧビデオストリームを復号することが可能であるセットトップボックスまたはケーブルカードを有する。線形コンテンツを提供することを越えて、今ではケーブルプロバイダは、ウェブページ、アクセス限定コンテンツ、ビデオゲーム、ビデオ、双方向カタログ、および映画を含む視聴覚コンテンツのストリーミング配信を含んでもよいボイスオーバーＩＰ（ＶＯＩＰ）テレフォニサービス、および同等物等の双方向コンテンツを提供することができる。ウェブページ上のビデオコンテンツを含み、ビデオコンテンツを復号するためのアプリケーションまたはスクリプトを要求して、インターネットがより動的になるにつれて、ケーブルプロバイダは、これらの動的ウェブページを閲覧する能力を加入者に許容するように適合してきた。符号化された形式で動的ウェブページを要求加入者に伝送するために、ケーブルヘッドエンドは、要求されたウェブページを読み出し、ウェブページをレンダリングする。したがって、ケーブルヘッドエンドは、最初に、動的ウェブページ内に現れる任意の符号化されたコンテンツを復号しなければならない。例えば、ビデオがウェブページ上で再生される場合、ヘッドエンドは、符号化されたビデオを読み出し、ビデオの各フレームを復号しなければならない。次いで、ケーブルヘッドエンドは、各フレームを読み出して、インターネットウェブページの一連のビットマップ画像を形成する。したがって、ウェブページは、ウェブページを形成するコンテンツの全てが最初に復号された場合のみ、ともに合成することができる。いったん合成フレームが完成すると、合成ビデオは、再符号化されるように、ＭＰＥＧエンコーダ等のエンコーダに送信される。次いで、圧縮ＭＰＥＧビデオフレームは、ＭＰＥＧビデオストリームの中でユーザのセットトップボックスへ送信される。

全ての符号化されたコンテンツを最初に復号し、次いで合成し、レンダリングし、再符号化しなければならないため、ケーブルテレビネットワーク内でそのような合成符号化ビデオフレームを作成することは、集中ＣＰＵおよびメモリ処理を必要とする。具体的には、ケーブルヘッドエンドは、リアルタイムでコンテンツの全てを復号し、再符号化しなければならない。したがって、動的ウェブページおよび他の動的コンテンツを有する双方向環境内においてユーザが操作することを可能にすることは、必要な処理に起因して、ケーブル運営者にとっては極めて高コストである。加えて、そのようなシステムは、符号化されたビデオの再符号化によって画質が劣化させられるという付加的な欠点を有する。

衛星テレビシステムは、一方向伝送に限定されるという問題を抱えている。したがって、衛星テレビプロバイダは、「オンデマンド」または双方向サービスを提供することができない。結果として、衛星テレビネットワークは、加入者用のマネージドネットワークを提供することに限定され、双方向情報へのユーザが要求したアクセスを提供することができない。例えば、双方向通信をサポートしない一方向ケーブルカードまたはケーブルシステムを有するケーブル加入者といった他の通信システムは、双方向コンテンツを提供することができない。

関連する特許文献１は、マネージドネットワーク上で一方向放送コンテンツを、アンマネージドネットワーク上で２方向の双方向サービスを提供するためのシステムおよび方法を提供する。しかしながら、アンマネージドネットワークは、正確にはテレビ運営者によって管理されないため、マネージドネットワークよりも高い待ち時間、多くのドロップされたパケット、および多くの可変帯域幅を含む場合がある。そのようなより高い待ち時間、エラー率、および帯域幅の可変性は、双方向サービスにとって不利である。最適な加入者経験を提供するために、多くの双方向サービスは、極めて可変の伝送条件を経験するアンマネージドネットワーク環境を横断して伝送しながら、高いビデオフレームレートおよび高品質のオーディオ、ならびに非常に低いデータエラー率および非常に低い待ち時間を必要とする。事態を複雑にすることに、テレビプロバイダは、ケーブルヘッドエンドに位置するサーバコンピュータよりもはるかに多くの数で生産されている、加入者クライアントセットトップボックスまたはケーブルカードの複雑生を低減することによって、費用を節約することを希望する場合がある。そのような「シン」クライアントは、低減した計算能力を有する場合があり、非常に制約されたハードウェアおよびソフトウェア環境内で最適な加入者経験を提供しなければならない。

信頼性が低いネットワークによって接続されたコンピュータ間でデータを伝送するための方法が当技術分野において公知である。１つの方法例は、非特許文献１（“ＲＦＣ７６８”）において最初に正式に定義されているような、ユーザデータグラムプロトコル（ＵＤＰ）を使用する。ＵＤＰは、最低限のプロトコル機構を用いてデータを相互に送信するように、異なるコンピュータ上のアプリケーションプログラム用の手順を提供する。従来、視聴覚コンテンツのプロバイダは、ＵＤＰの非常に低い待ち時間および低いオーバーヘッドにより、ストリーミングビデオ等の非双方向コンテンツを伝送するためにＵＤＰを使用してきた。しかしながら、つい最近、セキュリティの懸念が、ネットワークファイアウォールの後ろにクライアントデバイスを配置するように、ますます多くのテレビ加入者を促してきた。ファイアウォールは、特に、コンテンツプロバイダからのあるＵＤＰを許可するが、他の有害な接続を許可しないように加入者が構成することが困難な場合がある。さらに、ＵＤＰは、信頼性の高いデータ伝送を提供せず、伝送されたオーディオまたはビデオにおいて「スキップ」または他のアーチファクトを引き起こし、したがって、最適なユーザ経験を提供するための要件を満たさない。

非特許文献２（“ＲＦＣ７９３”）で最初に正式に定義されているような、トランスミッションコントロールプロトコル（ＴＣＰ）は、信頼性の高いデータ伝送を提供しないが、ＴＣＰネットワーク上で双方向サービスをシンクライアントに提供することは問題がある。ＴＣＰは、端末間接続、ならびにパケット再発注および再伝送等の、ＵＤＰが提供しない、いくつかの高レベルサービスを提供する。これらの付加的なサービスは、シンクライアントデバイス上で高需要であり、通信チャネルに再伝送の待ち時間を導入する、貴重なコンピューティングリソースを消費する。別の問題は、ストリーミングムービーで見られるもの等のフルモーションビデオを伝送することが、大量のネットワーク帯域幅を消費することである。ネットワーク３Ｄビデオゲーム等の特殊用途システムは、ゲームデータのみをクライアントデバイスに伝送し、クライアントデバイスに仮想環境をレンダリングさせることによって、この問題に対抗する。そのような解決法は、一般的なビデオアプリケーションには適用できない。さらに、クライアントデバイス上で必要とされる計算およびレンダリング過程は、単純なビデオレンダリング単独よりもさらに多くのコンピューティングリソースを消費し、ビデオゲームをするためにさえも、非常に小型軽量のクライアント上で不適当となる。したがって、ＴＣＰは、加入者への双方向サービスの伝送のためのＵＤＰに比べていくつかの利点を有するが、シンクライアント要件が、これらのサービスの提供を困難にする。

米国特許出願第１２／４８９，０１７号明細書

Ｐｏｓｔｅｌ，Ｊ．，Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ７６８：Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ（Ａｕｇ．１９８０） Ｉｎｆｏｒｍａｔｉｏｎ Ｓｃｉｅｎｃｅｓ Ｉｎｓｔｉｔｕｔｅ，Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ ７９３：Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ（Ｓｅｐｔ．１９８１）

本発明の実施形態は、計算が単純なビットレート検出および伝送されたコンテンツの適応制御を可能にすることによって従来技術の限界に対処する。これらの特徴は、テレビシステム運営者が、安価なシンクライアントを有する加入者に高品質の経験を有する双方向サービスを提供することを可能にする。本発明の第１の実施形態は、ユーザと関連付けられるクライアント復号デバイスへのアンマネージドネットワーク上での双方向コンテンツの信頼性の高い伝送を提供する方法を含む。双方向コンテンツは、ビデオ（ｖｉｄｅｏ）構成要素およびオーディオ（ａｕｄｉｏ）構成要素の両方を有する。クライアント復号デバイスは、アンマネージドネットワーク上で双方向コンテンツを受信することに加えて、マネージドネットワーク上で放送ビデオコンテンツを受信し、表示デバイスに出力するために放送ビデオコンテンツと双方向コンテンツとを切り替えることが可能である。方法は、マネージドネットワーク上で放送ビデオコンテンツをクライアント復号デバイスに伝送するステップから始まり、次いで、アンマネージドネットワーク上で双方向コンテンツをクライアント復号デバイスに提供する要求を受信する。要求が受信された後に、方法は、ビデオ符号化ビットレートに従って双方向ビデオコンテンツの第１の複数のフレームを符号化し、それにより、符号化された双方向コンテンツの第１の部分を形成するステップと、信頼性の高いデータ伝送プロトコルを使用して、アンマネージドネットワーク上で符号化された双方向コンテンツの第１の部分をクライアント復号デバイスに伝送するステップとを続ける。次に、方法は、アンマネージドネットワーク上で第１の部分の伝送帯域幅を決定するステップと、伝送帯域幅に従ってビデオ符号化ビットレートを調整するステップとを含む。いったんこれらの調整が行われると、方法は、ビデオ構成要素に対する調整されたビデオ符号化ビットレート、およびオーディオ構成要素に対する調整されていないオーディオ符号化ビットレートに従って、双方向コンテンツの第２の部分を符号化し、それにより、符号化された双方向コンテンツの第２の部分を形成するステップと、信頼性の高いデータ伝送プロトコルを使用して、アンマネージドネットワーク上で符号化された双方向コンテンツの第２の部分をクライアント復号デバイスに伝送するステップとを続ける。いくつかの関連実施形態では、アンマネージドネットワークは、インターネットの少なくとも一部分を含み、マネージドネットワークは、衛星ネットワーク、ケーブルテレビネットワーク、またはＩＰテレビネットワークを含んでもよい。両方のネットワークは、単一の通信リンク上で動作してもよい。双方向コンテンツは、ＭＰＥＧ規格に従って符号化されてもよい。信頼性の高いデータ伝送プロトコルは、ＴＣＰを含んでもよい。伝送帯域幅を決定するステップは、時間の関数として伝送バッファの中のデータの数量を決定するステップを含んでもよく、ビデオ符号化ビットレートを調整するステップは、決定された伝送帯域幅および／またはその時間導関数に従って、ビデオ符号化ビットレートを比例的に調整するステップを含む。代替として、ビデオフレームレート、連続ビデオフレームの種類のパターン、またはビデオデータ量子化値が調整されてもよい。また、クライアント復号デバイスは、符号化された双方向コンテンツの第２の部分が伝送された後に、放送ビデオコンテンツから双方向コンテンツへその出力を切り替えてもよい。

さらに、決定された帯域幅が双方向コンテンツと関連付けられる最小帯域幅より小さくなるときに、関連方法は、信頼性の高いデータ伝送プロトコルを使用して、アンマネージドネットワーク上で、符号化された双方向コンテンツの代わりにサービス利用不可能コンテンツをクライアント復号デバイスに伝送するステップを含んでもよい。

別の関連方法は、それぞれ最小帯域幅に従って双方向コンテンツを提供する複数の双方向サービスを含むリストを形成するステップと、決定された帯域幅が双方向コンテンツと関連付けられる最小帯域幅よりも小さくなるときに、ビジネスルールに従って双方向サービスをリストから選択するステップと、次いで、信頼性の高いデータ伝送プロトコルを使用して、アンマネージドネットワーク上で、選択された双方向サービスによって提供される符号化された双方向コンテンツをクライアント復号デバイスに伝送するステップとを含む。ビジネスルールは、ユーザと関連付けられるユーザデータに関するルールを含んでもよく、双方向サービスを選択するステップは、ユーザデータに従って選択するステップを含んでもよい。これらの種々の実施形態では、ビデオフレームのうちのいくつかは、複数のビデオソースから符号化された領域の中でともに縫い合わせられてもよい。

第２の実施形態では、ユーザと関連付けられるクライアント復号デバイスにおいて、アンマネージドネットワーク上での双方向コンテンツの受信における様々な状態に適応する、第１の実施形態を補完する方法が提供される。双方向コンテンツは、ビデオ構成要素およびオーディオ構成要素を有し、クライアント復号デバイスは、以前のように、マネージドネットワーク上で放送ビデオコンテンツを受信する。方法は、ビデオディスプレイ上で表示するために、マネージドネットワークからクライアント復号デバイスにおいて受信される放送ビデオコンテンツを出力するステップを含む。次に、方法は、双方向コンテンツが受信される受信帯域幅を決定するステップを含む、信頼性の高いデータ伝送プロトコルを使用して、アンマネージドネットワークからクライアント復号デバイスにおいて双方向コンテンツを受信するステップを含む。いったん双方向コンテンツの受信が始まると、方法は、受信された双方向コンテンツをビデオ構成要素およびオーディオ構成要素に逆多重化するステップと、受信帯域幅に基づいて、オーディオ構成要素の再生を促進するステップと、促進に基づくビットレートで、クライアント復号デバイスにおいてオーディオ構成要素およびビデオ構成要素を復号するステップとを含む。最終的に、方法は、ビデオディスプレイ上で表示するために、復号されたビデオ構成要素を出力するステップを含む。

再生を促進するステップは、時間の関数としてオーディオバッファの中のデータの数量を決定するステップを含んでもよい。復号ビットレートは、受信帯域幅に比例してもよい。方法はさらに、受信帯域幅の関数としてオーディオバッファのサイズを増加または減少させるステップを含んでもよい。関連実施形態では、方法は、マネージドネットワーク上でクライアント復号デバイスにおいて、またはヘッドエンドにおいて、トリガを受信するステップを含み、トリガは、クライアント復号デバイスに、アンマネージドネットワーク上で双方向コンテンツを要求させる。

第１の実施形態およびその関連実施形態は、典型的には、ユーザと関連付けられるクライアント復号デバイスへのアンマネージドネットワーク上での双方向コンテンツの信頼性の高い伝送を提供するステッチャサーバ装置において、テレビシステム運営者の施設内で実装される。

第２の相補的な実施形態およびその関連実施形態は、典型的には、アンマネージドネットワーク上での双方向コンテンツの受信における様々な状態に適応することが可能であり、ステッチャサーバ装置からマネージドネットワーク上で放送ビデオコンテンツを受信する、クライアント復号デバイスにおいて実装される。

本発明の上述の特徴は、付随の図面を参照して、以下の発明を実施するための形態を参考することによって、より容易に理解されるであろう。

図１は、本発明の１つのバージョンを実装するための通信環境を示すブロック図である。 図１Ａは、地域処理オフィスおよびビデオコンテンツ配信ネットワークを示す。 図１Ｂは、サンプル合成ストリーム提示および相互作用レイアウトファイルである。 図１Ｂは、サンプル合成ストリーム提示および相互作用レイアウトファイルである。 図１Ｂは、サンプル合成ストリーム提示および相互作用レイアウトファイルである。 図１Ｂは、サンプル合成ストリーム提示および相互作用レイアウトファイルである。 図１Ｂは、サンプル合成ストリーム提示および相互作用レイアウトファイルである。 図１Ｂは、サンプル合成ストリーム提示および相互作用レイアウトファイルである。 図１Ｃは、オーサリング環境内のフレームの構築を示す。 図１Ｄは、マクロブロックによる要素へのフレームの分解を示す。 図２は、ディスプレイ上で合成された複数のソースを示す概略図である。 図３は、グルーミングを組み込むシステムの概略図である。 図４は、グルーミング前、グルーミング後、およびグルーミングした区分の中にビデオオーバーレイを伴う、ビデオフレームを示す概略図である。 図５は、グルーミングが行われる方法、例えば、Ｂフレームの除去を示す概略図である。 図６は、ＭＰＥＧフレーム構造を示す概略図である。 図７は、Ｉ、Ｂ、およびＰフレームに対するグルーミング過程を示すフローチャートである。 図８は、領域境界動きベクトルの除去を描写する概略図である。 図９は、ＤＣＴ係数の再発注を示す概略図である。 図１０は、代替的なグルーマを示す。 図１１は、ビデオフレームの実施例である。 図１２は、相互に対してランダムな位置で開始するビデオフレームを示す概略図である。 図１３は、ピクチャー内で合成された複数のＭＰＥＧ要素を伴う表示の概略図である。 図１４は、複数の要素から構成されるピクチャーのスライス分解を示す概略図である。 図１５は、ステッチングに備えたスライスベースの符号化を示す概略図である。 図１６は、ピクチャーへのビデオ要素の合成を詳述する概略図である。 図１７は、２４×２４サイズのマクロブロックから構成される背景への１６×１６サイズのマクロブロック要素の合成を詳述する概略図である。 図１８は、合成ピクチャーを符号化し、構築することに関与するステップを示すフローチャートである。 図１９は、グルーミングの単純実施例を提供する概略図である。 図２０は、合成要素が長方形である必要も連続的である必要もないことを示す概略図である。 図２１は、単一の要素が不連続的である、画面上の要素の概略図を示す。 図２２は、複数の処理オフィスおよび／またはセッションプロセッサにマルチキャストするための線形放送コンテンツをグルーミングするためのグルーマを示す。 図２３は、表示デバイス上に表示された時のカスタマイズされたモザイクの実施例を示す。 図２４は、双方向ＭＰＥＧコンテンツを提供するためのＩＰベースのネットワークの概略図である。 図２５は、双方向ＭＰＥＧコンテンツを提供するためのケーブルベースのネットワークの概略図である。 図２６は、ケーブルベースのネットワークとともに使用するためのロードバランサに対するリソース割付過程のフローチャートである。 図２７は、負荷バランシングのためのケーブルネットワーク間の通信を示すために使用される系統図である。 図２８は、アンマネージドＩＰネットワークを通して双方向コンテンツを加入者に提供することができる、マネージド放送コンテンツ衛星ネットワークを示す。 図２９は、クライアントデバイスがマネージドネットワークを通して放送コンテンツを受信し、双方向コンテンツが要求されてもよく、アンマネージドネットワークを通して提供される、別の環境を示す。 図３０は、ステッチャが適応ビットレート検出および制御を行う、本発明のサーバの実施形態を示す。 図３０Ａは、図３０の関連過程のフローチャートを示す。 図３１は、クライアントデバイスが適応待ち時間制御を行う、本発明の実施形態を示す。 図３２は、適応待ち時間制御を行うための代替的なクライアントの実施形態を示す。 図３３は、ビットレート検出から収集されたデータが、１つ以上のビジネスルールに従ってサービスの選択を提供するために使用される、サーバの実施形態を示す。

以下の発明を実施するための形態および添付の請求項において使用されるように、「領域」という用語は、連続的または不連続的であるＭＰＥＧ（Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）スライスの論理グループ化を意味する。ＭＰＥＧという用語が使用されるとき、ＭＰＥＧ−２およびＭＰＥＧ−４を含むＭＰＥＧ規格の全ての変種を指すものとする。以下の実施形態において説明されるような本発明は、双方向ＭＰＥＧコンテンツ用の環境、および処理オフィスとテレビ等の関連ディスプレイを有するクライアントデバイスとの間の通信を提供する。本発明は、具体的には、ＭＰＥＧ仕様および符号化を参照するが、本発明の原理は、ブロックベースの変換に基づく他の符号化技法とともに採用されてもよい。以下の明細書および添付請求項において使用されるように、符号化する、符号化された、および符号化という用語は、デジタルデータ信号を圧縮し、圧縮されたデジタルデータ信号をプロトコルまたは規格にフォーマットする過程を指すものとする。例えば、符号化されたビデオデータは、変換コード化され、量子化され、エントロピー符号化され、またはそれらの任意の組み合わせが行われてもよい。したがって、変換コード化されたデータは、符号化されたと見なされる。

本発明は、表示デバイスをテレビと呼ぶが、表示デバイスは、携帯電話、携帯用情報端末（ＰＤＡ）、またはディスプレイを含む他のデバイスであってもよい。ＭＰＥＧコンテンツを復号することができるセットトップボックス等の復号デバイスを含むクライアントデバイスは、ユーザの表示デバイスと関連付けられる。ある実施形態では、デコーダは、表示デバイスの一部であってもよい。双方向ＭＰＥＧコンテンツは、コンテンツプロバイダおよび線形放送局からのビデオコンテンツを含む種々の要素からの１つ以上の場面を有するアプリケーションを作成する、双方向ＭＰＥＧコンテンツをアプリケーションデザイナが設計することを可能にするオーサリング環境内で作成される。アプリケーションファイルは、アクティブビデオマークアップ言語（ＡＶＭＬ）で形成される。オーサリング環境によって生成されるＡＶＭＬファイルは、単一のフレーム／ページ内のビデオグラフィック要素（すなわち、ＭＰＥＧスライス）、ビデオグラフィック要素のサイズ、各場面の単一のフレーム／ページ内のビデオグラフィック要素のレイアウト、ビデオグラフィック要素へのリンク、および場面のあらゆるスクリプトを定義するＸＭＬベースのファイルである。ある実施形態では、ＡＶＭＬファイルは、テキストエディタで書かれること、またはオーサリング環境によって生成されることとは対照的に、直接書かれてもよい。ビデオグラフィック要素は、静的グラフィック、動的グラフィック、またはビデオコンテンツであってもよい。場面内の各要素は、実際には一連の画像であり、静止グラフィックは、繰り返し表示され、経時的に変化しない画像であることを認識されたい。要素のそれぞれは、グラフィックに対するＭＰＥＧデータおよびグラフィックと関連付けられる操作の両方を含むことができるＭＰＥＧオブジェクトであってもよい。双方向ＭＰＥＧコンテンツは、ユーザが相互作用することができる、場面内の複数の双方向ＭＰＥＧオブジェクトを含むことができる。例えば、場面は、オブジェクトに対するビデオグラフィックを形成する符号化されたＭＰＥＧデータを提供し、また、ボタンの状態を追跡するための手順を含むボタンＭＰＥＧオブジェクトを含んでもよい。ＭＰＥＧオブジェクトは、スクリプトと協調して稼働してもよい。例えば、ＭＰＥＧボタンオブジェクトは、その状態（オン／オフ）を追跡してもよいが、場面内のスクリプトは、そのボタンが押されたときに何が起こるかを決定する。スクリプトは、ビデオコンテンツが再生されているか停止されているかをボタンが示すように、ボタンの状態をビデオプログラムと関連付けてもよい。ＭＰＥＧオブジェクトは常に、オブジェクトの一部として関連動作を有する。ある実施形態では、ボタンＭＰＥＧオブジェクト等のＭＰＥＧオブジェクトは、ボタンの状態を追跡することを越えた動作を行ってもよい。そのような実施形態では、ＭＰＥＧオブジェクトはまた、外部プログラムへの呼び出しを含んでもよく、ＭＰＥＧオブジェクトは、ボタングラフィックが使用中であるときにプログラムにアクセスする。したがって、再生／一時停止ＭＰＥＧオブジェクトボタンについて、ＭＰＥＧオブジェクトは、ボタンの状態を追跡し、状態の変化に基づいてグラフィックオーバーレイを提供し、および／またはボタンの状態に応じてビデオプレーヤオブジェクトにビデオコンテンツを再生または一時停止させる、コードを含んでもよい。

いったんアプリケーションがオーサリング環境内で作成され、双方向セッションが要求クライアントデバイスによって要求されると、処理オフィスが双方向セッションのためのプロセッサを割り当てる。

処理オフィスで動作可能な割り当てられたプロセッサは、仮想マシンを実行し、要求されたアプリケーションにアクセスして実行する。プロセッサは、ＭＰＥＧ形式での伝送のために場面のグラフィック場面を準備する。クライアントデバイスによるＭＰＥＧ伝送の受信およびユーザのディスプレイ上の表示時に、ユーザは、クライアントデバイスと通信している入力デバイスを使用することによって、表示されたコンテンツと相互作用することができる。クライアントデバイスは、通信ネットワークを通して、ユーザから、処理オフィスまたは他の遠隔場所にある割り当てられたプロセッサ上で作動するアプリケーションへ入力要求を送信する。それに応じて、割り当てられたプロセッサは、要求および以降では全体でアプリケーション状態と呼ばれるＭＰＥＧオブジェクトの状態に基づいて、グラフィックレイアウトを更新する。新しい要素が場面に追加されるか、または場面内で置換されてもよく、あるいは完全に新しい場面が作成されてもよい。割り当てられたプロセッサは、場面に対する要素およびオブジェクトを収集し、割り当てられたプロセッサまたは別のプロセッサは、オブジェクトに従ってデータおよび操作を処理し、ユーザのテレビ上で表示するために伝送機に伝送される、ＭＰＥＧ形式の改訂グラフィック表現を生成する。上記の一節は、割り当てられたプロセッサが処理オフィスに位置することを示すが、割り当てられたプロセッサは、遠隔場所に位置してもよく、ネットワーク接続を通して処理オフィスと通信していれば十分である。同様に、割り当てられたプロセッサは、クライアントデバイスとの全てのトランザクションに対処するものとして説明されているが、他のプロセッサもまた、アプリケーションに対するグラフィックレイアウトのコンテンツ（ＭＰＥＧオブジェクト）の要求および組立に関与してもよい。

図１は、本発明の１つのバージョンを実装するための通信環境１００を示すブロック図である。通信環境１００は、アプリケーションプログラマがエンドユーザとの２方向の双方向性のためのアプリケーションを作成することを可能にする。エンドユーザは、テレビ等のクライアントデバイス１１０上でアプリケーションを閲覧し、上流ネットワーク１２０を通してコマンドを上流に送信することによってコンテンツと相互作用することができ、上流および下流は、同じネットワーク、または処理オフィスへの帰還路リンクを提供する別個のネットワークの一部であってもよい。アプリケーションプログラマは、１つ以上の場面を含むアプリケーションを作成する。各場面は、場面内の各要素がビデオシーケンスであることを除いて、ＨＴＭＬウェブページの同等物である。アプリケーションプログラマは、場面のグラフィック表現を設計し、オーディオおよびビデオファイル等の要素、ならびに場面に対するボタンおよび制御等のオブジェクトへのリンクを組み込む。アプリケーションプログラマは、オブジェクトおよび要素をグラフィックで選択するために、グラフィックオーサリングツール１３０を使用する。オーサリング環境１３０は、アプリケーションプログラマがビデオオブジェクトを作成する要素と方法を関連付けることを可能にするグラフィカルインターフェースを含んでもよい。グラフィックは、ＭＰＥＧ符号化ビデオ、グルーミングされたＭＰＥＧビデオ、静止画像、または別の形式のビデオであってもよい。アプリケーションプログラマは、コンテンツプロバイダ１６０（ニュースソース、映画スタジオ、ＲＳＳフィード等）および線形放送ソース（放送媒体およびケーブル、オンデマンドビデオソース、およびウェブベースのビデオソース）１７０を含む、いくつかのソースからのコンテンツをアプリケーションに組み込むことができる。アプリケーションプログラマは、アプリケーションをＡＶＭＬ（アクティブビデオマークアップ言語）でファイルとして作成し、アプリケーションファイルをビデオコンテンツ配信ネットワーク１５０内のプロキシ／キャッシュ１４０へ送信する。ＡＶＭＬファイル形式は、ＸＭＬ形式である。例えば、サンプルＡＶＭＬファイルを示す図１Ｂを参照されたい。

コンテンツプロバイダ１６０は、ビデオコンテンツをＭＰＥＧビデオ／オーディオとして符号化してもよく、コンテンツは、別のグラフィック形式（例えば、ＪＰＥＧ、ビットマップ、Ｈ２６３、Ｈ２６４、ＶＣ−１等）であってもよい。コンテンツは、コンテンツを、ステッチングを可能にする好ましい符号化ＭＰＥＧ形式にするように、後にグルーミングされ、および／またはグルーマ／スケーラ１９０で拡大縮小されてもよい。コンテンツが好ましいＭＰＥＧ形式にされない場合、コンテンツを要求するアプリケーションがクライアントデバイスによって要求されるときに、処理オフィスが形式をグルーミングする。コンテンツプロバイダからのコンテンツのような、放送媒体サービスからの線形放送コンテンツ１７０が、グルーミングされる。線形放送コンテンツは、好ましくは、コンテンツを処理オフィスに渡す前に、ステッチングのための好ましいＭＰＥＧ形式でコンテンツを符号化する、グルーマ／スケーラ１８０でグルーミングおよび／または拡大縮小される。アプリケーションプログラマによって作成されるアプリケーションとともに、コンテンツ製作者１６０からのビデオコンテンツは、ビデオコンテンツ配信ネットワーク１５０を通して配信され、配信ポイント１４０で記憶される。これらの配信ポイントは、図１内でプロキシ／キャッシュとして表されている。コンテンツプロバイダは、ビデオコンテンツ配信ネットワーク内の双方向処理オフィスとともに使用するためのコンテンツを、プロキシ／キャッシュ１４０場所に配置する。したがって、コンテンツプロバイダ１６０は、コンテンツをビデオコンテンツ配信ネットワーク１５０のキャッシュ１４０に提供することができ、本アーキテクチャを実装する１つ以上の処理オフィスは、アプリケーションに必要とされるときに、ビデオコンテンツ配信ネットワーク１５０を通してコンテンツにアクセスしてもよい。ビデオコンテンツ配信ネットワーク１５０は、ローカルネットワーク、地域ネットワーク、またはグローバルネットワークであってもよい。したがって、処理オフィスにある仮想マシンがアプリケーションを要求すると、アプリケーションを配信ポイントのうちの１つから読み出すことができ、アプリケーションのＡＶＭＬファイル内で定義されるようなコンテンツを、同じまたは異なる配信ポイントから読み出すことができる。

システムのエンドユーザは、セットトップボックス等のクライアントデバイス１１０を通して、コマンドを処理オフィス１０５に送信することによって、双方向セッションを要求することができる。図１では、単一の処理オフィスのみが示されている。しかしながら、実世界アプリケーションでは、異なる領域中に位置する複数の処理オフィスがあってもよく、処理オフィスのそれぞれは、図１Ｂに示されるように、ビデオコンテンツ配信ネットワークと通信している。処理オフィス１０５は、双方向セッションのためにエンドユーザ用のプロセッサを割り当てる。プロセッサは、全てのアドレス指定およびリソース割付を含むセッションを維持する。本明細書および添付の請求項で使用されるように、「仮想マシン」１０６という用語は、割り当てられたプロセッサ、ならびに、処理オフィスとクライアントデバイスとの間のセッション管理ならびにリソース割付（すなわち、双方向セッションのためのプロセッサの割当）等の機能を行う、処理オフィスにある他のプロセッサを指すものとする。

仮想マシン１０６は、そのアドレスをクライアントデバイス１１０に伝達し、双方向セッションが確立される。次いで、ユーザは、クライアントデバイス１１０を通して双方向アプリケーション（ＡＶＭＬ）の提示を要求することができる。要求は、仮想マシン１０６によって受信され、それに応じて、仮想マシン１０６は、ＡＶＭＬファイルをプロキシ／キャッシュ１４０から読み出させ、仮想マシン１０６によってアクセス可能であるメモリキャッシュ１０７にインストールさせる。仮想マシン１０６は、複数のクライアントデバイス１１０と同時通信していてもよく、クライアントデバイスは、異なるデバイス種類であってもよいことを認識されたい。例えば、第１のデバイスは、携帯電話であってもよく、第２のデバイスは、セットトップボックスであってもよく、第３のデバイスは、携帯用情報端末であってもよく、各デバイスは、同じまたは異なるアプリケーションにアクセスする。

アプリケーションの要求に応じて、仮想マシン１０６は、アプリケーションを処理し、場面の一部である要素およびＭＰＥＧオブジェクトが、プロキシ／キャッシュから仮想マシン１０６に関連付けられるメモリ１０７の中へ移動させられることを要求する。ＭＰＥＧオブジェクトは、視覚的構成要素および実用的構成要素の両方を含む。視覚的構成要素は、１つ以上のＭＰＥＧスライスとして符号化されるか、または別のグラフィック形式で提供されてもよい。実用的構成要素は、オブジェクトの状態を記憶してもよく、計算を行うこと、関連プログラムにアクセスすること、グラフィック構成要素をアクティブとして識別するようにオーバーレイグラフィックを表示することを含んでもよい。オーバーレイグラフィックは、クライアントデバイスに伝送されている信号によって生成されてもよく、クライアントデバイスは、表示デバイス上のオーバーレイ面の中でグラフィックを作成する。場面は、静止グラフィックではないが、むしろ、フレームのコンテンツが経時的に変化することができる、複数のビデオフレームを含むことを認識されたい。

仮想マシン１０６は、アプリケーションの状態、場面に対する種々の要素およびオブジェクトのサイズおよび場所を含む、場面情報に基づいて決定する。各グラフィック要素は、連続的または不連続的ＭＰＥＧスライスから形成されてもよい。仮想マシンは、各グラフィック要素に対するスライスの全ての場所を追跡する。グラフィック要素を画定するスライスの全ては、領域を含む。仮想マシン１０６は、各領域を追跡する。ＡＶＭＬファイル内の表示位置情報に基づいて、ビデオフレーム内の要素および背景のスライス位置が設定される。グラフィック要素がまだグルーミング形式ではない場合、仮想マシンは、その要素を要素レンダラに渡す。レンダラは、グラフィック要素をビットマップとしてレンダリングし、レンダラは、ビットマップをＭＰＥＧ要素エンコーダ１０９に渡す。ＭＰＥＧ要素エンコーダは、ビットマップをＭＰＥＧビデオシーケンスとして符号化する。ＭＰＥＧエンコーダは、一連のＰフレームを出力するようにビットマップを処理する。まだ事前符号化および事前グルーミングされていないコンテンツの実施例は、個人化されたコンテンツである。例えば、ユーザが処理オフィスに音楽ファイルを記憶しており、提示されるグラフィック要素がユーザの音楽ファイルの一覧である場合、このグラフィックは、仮想マシンによってビットマップとしてリアルタイムで作成される。仮想マシンは、ビットマップをレンダリングし、グルーミングのためにビットマップをＭＰＥＧ要素エンコーダ１０９に渡す要素レンダラ１０８に、ビットマップを渡す。

グラフィック要素がＭＰＥＧ要素エンコーダによってグルーミングされた後、ＭＰＥＧ要素エンコーダ１０９は、他のユーザによる他の双方向セッションのために仮想マシン１０６によって後に読み出すために、グラフィック要素をメモリ１０７に渡す。ＭＰＥＧエンコーダ１０９はまた、ＭＰＥＧ符号化グラフィック要素をステッチャ１１５に渡す。要素のレンダリングおよび要素のＭＰＥＧ符号化は、仮想マシン１０６と同じまたは別個のプロセッサで達成されてもよい。仮想マシン１０６はまた、アプリケーション内に解釈される必要があるスクリプトがあるか否かも決定する。スクリプトがある場合、スクリプトは、仮想マシン１０６によって解釈される。

アプリケーションの中の各場面は、静的グラフィック、ユーザ相互作用に基づいて変化するオブジェクトグラフィック、およびビデオコンテンツを含む、複数の要素を含むことができる。例えば、場面は、オーディオビデオの再生用のメディアプレーヤおよび複数のボタンを含むマルチメディアコンテンツ（オブジェクトグラフィック）とともに、背景（静的グラフィック）と、ストリーミングビデオコンテンツを表示するためのビデオコンテンツウィンドウ（ビデオコンテンツ）とを含んでもよい。メディアプレーヤの各ボタンは、それ事態が、独自の関連方法を含む別個のオブジェクトグラフィックであってもよい。

仮想マシン１０６は、フレームに対するグラフィック要素（背景、メディアプレーヤグラフィック、およびビデオフレーム）のそれぞれを取得し、各要素の場所を決定する。いったんオブジェクトおよび要素（背景、ビデオコンテンツ）の全てが取得されると、要素およびグラフィックオブジェクトは、要素およびＭＰＥＧオブジェクトの位置付け情報とともに、ステッチャ／コンポジタ１１５に渡される。ステッチャ１１５は、仮想マシン１０６によって提供されるマッピングに従って、要素（ビデオコンテンツ、ボタン、グラフィック、背景）のそれぞれを一緒にステッチする。要素のそれぞれは、マクロブロック境界上に配置され、一緒にステッチされると、要素は、ＭＰＥＧビデオフレームを形成する。周期的に、場面フレームの要素の要素は、シーケンスを更新し、ドロップされたマクロブロックを回避するために、参照Ｐフレームを形成するように符号化される。次いで、ＭＰＥＧビデオストリームは、下流ネットワークを通してクライアントデバイスのアドレスに伝送される。過程は、ビデオフレームのそれぞれについて継続する。本明細書は、ＭＰＥＧを符号化過程と呼ぶが、他の過程もまた、このシステムとともに使用されてもよい。

処理オフィス１０５にある仮想マシン１０６あるいは他のプロセッサまたは過程は、要素のそれぞれに関する情報および画面上の要素の場所を維持する。仮想マシン１０６はまた、要素のそれぞれと関連付けられるオブジェクトのための方法にアクセスできる。例えば、メディアプレーヤは、複数のルーチンを含むメディアプレーヤオブジェクトを有してもよい。ルーチンは、再生、停止、早送り、巻き戻し、および一時停止を含むことができる。ルーチンのそれぞれは、コードを含む、ユーザが、ルーチンのうちの１つの起動のために処理オフィス１０５に要求を送信すると、オブジェクトがアクセスされ、ルーチンが実行される。ルーチンは、ＪＡＶＡ（登録商標）ベースのアプレット、解釈されるスクリプト、仮想マシンと関連付けられるオペレーティングシステム内で実行されることが可能な別個のコンピュータプログラムであってもよい。

処理オフィス１０５はまた、テレビと関連付けられるクライアントデバイスからプロセッサによって受信される信号に基づいて、実行または解釈するルーチンを決定するためのリンクされたデータ構造を作成してもよい。リンクされたデータ構造は、含まれたマッピングモジュールによって形成されてもよい。データ構造は、１つおきのリソースおよびオブジェクトに対して、各リソースおよび関連オブジェクトを関連付ける。例えば、ユーザがすでに再生制御に従事している場合、メディアプレーヤオブジェクトが起動され、ビデオコンテンツが表示される。ビデオコンテンツがメディアプレーヤウィンドウの中で再生されている際に、ユーザは、ユーザのリモートコントロール上の指示キーを押下することができる。この実施例では、指示キーの押下は、停止ボタンを押すことを示す。送受信機は、指示信号を生成し、割り当てられたプロセッサは、指示信号を受信する。処理オフィス１０５にある仮想マシン１０６または他のプロセッサは、リンクされたデータ構造にアクセスし、指示キーを押した方向に要素を位置付ける。データベースは、要素がメディアプレーヤオブジェクトの一部である停止ボタンであることを示し、プロセッサは、ビデオコンテンツを停止するためのルーチンを実装する。ルーチンは、要求されたコンテンツを停止させる。最後のビデオコンテンツフレームがフリーズされ、押下された停止ボタングラフィックが、ステッチャモジュールによってフレームに織り込まれる。ルーチンはまた、停止ボタンの周囲に焦点を提供するように、焦点グラフィックを含んでもよい。例えば、仮想マシンは、１マクロブロックの広さである境界を用いて、ステッチャに焦点を有するグラフィックを取り囲ませることができる。したがって、ビデオフレームが復号され、表示されると、ユーザは、ユーザが相互作用することができるグラフィック／オブジェクトを識別できるようになる。次いで、フレームは、マルチプレクサに渡され、下流ネットワークを介してクライアントデバイスに送信される。ＭＰＥＧ符号化ビデオフレームは、クライアントデバイス（携帯電話、ＰＤＡ）上または別個の表示デバイス（モニタ、テレビ）上に表示されて、クライアントデバイスによって符号化される。この過程は、最小の遅延を伴って生じる。したがって、各場面は、メディアプレーヤアプリケーションの状態のスナップショットをそれぞれ表す、複数のビデオフレームをもたらす。

仮想マシン１０６は、クライアントデバイスからコマンドを繰り返し受信し、それに応じて、コマンドは、直接または間接的にオブジェクトにアクセスし、ユーザ相互作用およびアプリケーション相互作用モデルに応じてオブジェクトのルーチンを実行または解釈する。そのようなシステムでは、ユーザのテレビ上に表示されるビデオコンテンツ材料は、復号されたＭＰＥＧコンテンツにすぎず、双方向性のための処理の全ては、処理オフィスで生じ、割り当てられた仮想マシンによって編成される。したがって、クライアントデバイスは、デコーダのみを必要とし、コンテンツのいずれもキャッシュに格納するか、または処理する必要はない。

クライアントデバイスからのユーザ要求を通して、処理オフィスが、ビデオ要素を別のビデオ要素と交換できることを認識されたい。例えば、ユーザは、表示する映画のリストから選択してもよく、したがって、ユーザが２つの映画を切り替えることを選択した場合に、第１のビデオコンテンツ要素が第２のビデオコンテンツ要素に取って代わられる。各要素および要素を形成する領域の場所の一覧を維持する、仮想マシンは、新しいＭＰＥＧビデオフレームを作成する場面内で容易に要素を交換することができ、フレームは、ステッチャ１１５において、新しい要素を含んで一緒にステッチされる。

図１Ａは、デジタルコンテンツ配信ネットワーク１００Ａ、コンテンツプロバイダ１１０Ａ、および処理オフィス１２０Ａの間の相互動作を示す。この実施例では、コンテンツプロバイダ１３０Ａは、コンテンツをビデオコンテンツ配信ネットワーク１００Ａの中へ配信する。ビデオコンテンツ配信ネットワークと関連付けられるコンテンツプロバイダ１３０Ａまたはプロセッサのいずれか一方は、コンテンツを、処理オフィス１２０Ａの双方向ＭＰＥＧコンテンツの作成と互換性があるＭＰＥＧ形式に変換する。デジタルビデオコンテンツ配信ネットワーク１００Ａのコンテンツ管理サーバ１４０Ａは、コンテンツが世界的／国内範囲である場合に、異なる領域中に位置するプロキシ／キャッシュ１５０Ａ−１５４Ａの間でＭＰＥＧ符号化コンテンツを配信する。コンテンツが地域／局所範囲である場合、コンテンツは、地域／ローカルプロキシ／キャッシュの中に存在する。コンテンツは、アクセス時間を増加させるために、異なる場所で国または世界中で反映されてもよい。エンドユーザが、クライアントデバイス１６０Ａを通して、地域処理オフィスからアプリケーションを要求するときに、地域処理オフィスは、要求されたアプリケーションにアクセスする。要求されたアプリケーションは、ビデオコンテンツ配信ネットワーク内に位置してもよく、アプリケーションは、地域処理オフィスにローカルで、または相互接続された処理オフィスのネットワークの中に存在してもよい。いったんアプリケーションが読み出されると、地域処理オフィスに割り当てられた仮想マシンは、読み出される必要があるビデオコンテンツを決定する。コンテンツ管理サーバ１４０Ａは、ビデオコンテンツ配信ネットワーク内のコンテンツを位置付けるのに仮想マシンを支援する。コンテンツ管理サーバ１４０Ａは、コンテンツが地域またはローカルプロキシ／キャッシュ上に位置するかどうかを決定し、また、最も近いプロキシ／キャッシュの場所を特定することができる。例えば、アプリケーションは、広告を含んでもよく、コンテンツ管理サーバは、ローカルプロキシ／キャッシュから広告を読み出すように仮想マシンに命令する。図１Ａに示されるように、中西部および南東部地域処理オフィス１２０Ａはまた、ローカルプロキシ／キャッシュ１５３Ａ、１５４Ａも有する。これらのプロキシ／キャッシュは、地元のニュースおよび地元の広告を含有してもよい。したがって、南東部のエンドユーザに提示される場面は、中西部のエンドユーザとは異なって見えてもよい。各エンドユーザは、異なる地元の新聞記事または異なる広告が提示されてもよい。いったんコンテンツおよびアプリケーションが読み出されると、仮想マシンは、コンテンツを処理し、ＭＰＥＧビデオストリームを作成する。次いで、ＭＰＥＧビデオストリームは、要求クライアントデバイスに方向付けられる。次いで、エンドユーザは、新しいコンテンツを伴う更新された場面を要求して、コンテンツと相互作用してもよく、処理オフィスにある仮想マシンは、ビデオコンテンツ配信ネットワークのプロキシ／キャッシュから新しいビデオコンテンツを要求することによって場面を更新する。

（オーサリング環境）
オーサリング環境は、図１に示すように、Ｃ双方向アプリケーションを開発するためのグラフィックエディタを含む。アプリケーションは、１つ以上の場面を含む。図１Ｂに示されるように、アプリケーションウィンドウは、アプリケーションが３つの場面（場面１、場面２、および場面３）から構成されることを示す。グラフィックエディタは、開発者が、ユーザと関連付けられる表示デバイス上に最終的に示される表示を形成する、場面の中へ配置される要素を選択することを可能にする。いくつかの実施形態では、要素は、アプリケーションウィンドウの中へドラッグアンドドロップされる。例えば、開発者が、メディアプレーヤオブジェクトおよびメディアプレーヤボタンオブジェクトを含むことを望み、ツールバーからこれらの要素を選択し、ウィンドウの中で要素をドラッグアンドドロップする。いったんグラフィック要素がウィンドウの中に入ると、開発者は要素を選択することができ、要素のプロパティウィンドウが提供される。プロパティウィンドウは、少なくともグラフィック要素の場所（アドレス）、およびグラフィック要素のサイズを含む。グラフィック要素がオブジェクトと関連付けられる場合、プロパティウィンドウは、開発者がビットマップイベント画面に切り替え、関連オブジェクトパラメータを変更することを可能にするタブを含む。例えば、ユーザは、ボタンと関連付けられる機能性を変更してもよく、またはボタンと関連付けられるプログラムを定義してもよい。

図１Ｄに示されるように、システムのステッチャは、オーサリング環境の出力であるＡＶＭＬファイルに基づいて、場面に対する一連のＭＰＥＧフレームを作成する。場面内の各要素／グラフィックオブジェクトは、領域を画定する異なるスライスから構成される。要素／オブジェクトを画定する領域は、連続的または不連続的であってもよい。システムは、マクロブロック境界上でグラフィックを形成するスライスのスナップを撮る。各要素は、連続スライスを有する必要がない。例えば、背景は、それぞれが複数のマクロブロックから構成されるいくつかの不連続スライスを有する。背景は、静的である場合、イントラコード化されたマクロブロックによって画定することができる。同様に、ボタンのそれぞれに対するグラフィックをインターコード化することができるが、ボタンは、状態と関連付けられ、複数の可能なグラフィックを有する。例えば、ボタンは、第１の状態「オフ」および第２の状態「オン」を有してもよく、第１のグラフィックは、非押下状態のボタンの画像を示し、第２のグラフィックは、押下状態のボタンを示す。図１Ｃはまた、映画のウィンドウである第３のグラフィック要素も示す。映画スライスは、イントラコード化およびインターコード化されたマクロブロックの混合を用いて符号化され、コンテンツに基づいて動的に変化する。同様に、背景が動的である場合、背景は、グルーミングに関する以下の要件に制約される、イントラコード化およびインターコード化されたマクロブロックの両方を用いて符号化することができる。

ユーザがクライアントデバイスを介してアプリケーションを選択すると、処理オフィスが、オーサリング環境のグラフィックエディタからのレイアウトに従って要素を一緒にステッチする。オーサリング環境の出力は、アクティブビデオマークアップ言語ファイル（ＡＶＭＬ）を含む。ＡＶＭＬファイルは、ボタン、関連グラフィックのアドレス、およびグラフィックのサイズ等の多状態要素に関する状態情報を提供する。ＡＶＭＬファイルは、各要素に対するＭＰＥＧフレーム内の場所を示し、各要素と関連付けられるオブジェクトを示し、ユーザの動作に基づいてＭＰＥＧフレームへの変更を定義するスクリプトを含む。例えば、ユーザが、命令信号を処理オフィスに送信してもよく、処理オフィスが、受信された命令信号に基づいて、一組の新しいＭＰＥＧフレームを構築するためにＡＶＭＬファイルを使用する。ユーザは、種々のビデオ要素を切り替えることを望んでもよく、命令信号を処理オフィスに送信してもよい。処理オフィスは、フレームに対するレイアウト内のビデオ要素を除去し、第２のビデオ要素を選択して、第１のビデオ要素の場所で第２のビデオ要素をＭＰＥＧフレームの中へステッチさせる。この過程は以下で説明される。

（ＡＶＭＬファイル）
アプリケーションプログラミング環境はＡＶＭＬファイルを出力する。ＡＶＭＬファイルは、ＸＭＬベースの構文を有する。ＡＶＭＬファイル構文は、ルートオブジェクト＜ＡＶＭＬ＞を含む。他の最上レベルタグは、アプリケーションが始動したときにロードされる第１の場面を特定する＜ｉｎｉｔｉａｌｓｃｅｎｅ＞を含む。＜ｓｃｒｉｐｔ＞タグは、スクリプトを識別し、＜ｓｃｅｎｅ＞タグは、場面を特定する。また、タグ内でデータを適用するために階級があるように、最上レベルタグのそれぞれに対する下位レベルのタグがあってもよい。例えば、最上レベルストリームタグは、ビデオストリームに対する＜ａｓｐｅｃｔ ｒａｔｉｏ＞、＜ｖｉｄｅｏ ｆｏｒｍａｔ＞、＜ｂｉｔ ｒａｔｅ＞、＜ａｕｄｉｏ ｆｏｒｍａｔ＞、および＜ａｕｄｉｏ ｂｉｔ ｒａｔｅ＞を含んでもよい。同様に、場面タグは、場面内の要素のそれぞれを含んでもよい。例えば、背景に対する＜ｂａｃｋｇｒｏｕｎｄ＞、ボタンオブジェクトに対する＜ｂｕｔｔｏｎ＞、静止グラフィックに対する＜ｓｔａｔｉｃ ｉｍａｇｅ＞である。他のタグは、要素のサイズおよび位置に対する＜ｓｉｚｅ＞および＜ｐｏｓ＞を含み、場面内の各要素に対する下位レベルのタグであってもよい。ＡＶＭＬファイルの実施例が図１Ｂで提供されている。

（グルーマ）
図２は、要求クライアントデバイスのテレビに提供することができる代表的な表示の概略図である。表示２００は、画面上に現れる３つの別個のビデオコンテンツ要素を示す。要素＃１ ２１１は、要素＃２ ２１５および要素＃３ ２１７が挿入される背景である。

図３は、図２の表示を生成することができるシステムの第１の実施形態を示す。この概略図では、要素＃１ ３０３、要素＃２ ３０５、および要素＃３ ３０７といった３つのビデオコンテンツ要素が、符号化されたビデオとして入って来る。グルーマ３１０はそれぞれ、符号化されたビデオコンテンツ要素を受信し、グルーマは、ステッチャ３４０がグルーミングされたビデオコンテンツ要素を単一の合成ビデオ３８０に組み込む前に、各要素を処理する。グルーマ３１０は、単一のプロセッサ、または並行して動作する複数のプロセッサであってもよいことが、当業者によって理解されるべきである。グルーマは、処理オフィス内、コンテンツプロバイダの施設、または線形放送プロバイダの施設に位置してもよい。グルーマは、グルーマ１９０および１８０がステッチャ１１５に直接連結されていない図１に示されるように、ステッチャに直接接続されなくてもよい。

ステッチする過程は、以下で説明され、要素が最初にグルーミングされた場合、さらに効率的に行うことができる。

グルーミングは、圧縮ビデオに存在する相互依存性のうちのいくつかを除去する。グルーマは、ＩおよびＢフレームをＰフレームに変換し、切り取られた、または除去されたビデオの別のフレームの区画を参照する任意の遊離動きベクトルを固定する。したがって、グルーミングされたビデオストリームは、合成ＭＰＥＧビデオストリームを形成するために、他のグルーミングされたビデオストリームおよび符号化された静止画像と組み合わせて使用することができる。各グルーミングされたビデオストリームは、複数のフレームを含み、フレームは、別のグルーミングされたフレームに容易に挿入することができ、合成フレームは、ＭＰＥＧビデオストリームを形成するために一緒にグループ化される。グルーミングされたフレームは、１つ以上のＭＰＥＧスライスから形成されてもよく、ＭＰＥＧビデオストリームの中のＭＰＥＧビデオフレームよりもサイズが小さくてもよいことに留意されたい。

図４は、複数の要素４１０、４２０を含有する合成ビデオフレームの実施例である。この合成ビデオフレームは、例示的な目的で提供されている。図１に示されるようなグルーマは、ビデオシーケンスをステッチャにおいて一緒にステッチすることができるように、単一の要素のみを受信し、要素（ビデオシーケンス）をグルーミングする。グルーマは、複数の要素を同時に受信しない。この実施例では、背景ビデオフレーム４１０は、スライスにつき１行を含む（これは実施例にすぎず、行は任意の数のスライスから構成されることができる）。図１に示されるように、場面内の要素の全ての場所を含むビデオフレームのレイアウトは、ＡＶＭＬファイル内のアプリケーションプログラマによって画定される。例えば、アプリケーションプログラマは、場面に対する背景要素を設計してもよい。したがって、アプリケーションプログラマは、ＭＰＥＧビデオとして符号化される背景を有してもよく、プロキシキャッシュ１４０の中へ配置される背景を有する前に、背景をグルーミングしてもよい。したがって、アプリケーションが要求されると、アプリケーションの場面内の要素のそれぞれは、グルーミングされたビデオであってもよく、グルーミングされたビデオは、容易に一緒にステッチすることができる。コンテンツプロバイダおよび線形放送局に対して、２つのグルーマが図１内に示されているが、グルーマは、システムの他の部分に存在してもよいことに留意されたい。

示されるように、ビデオ要素４２０は、背景ビデオフレーム４１０内に挿入される（同様に実施例にすぎず、この要素も１行当たり複数のスライスから構成されることができる）。元のビデオフレーム４１０内のマクロブロックが、その値を決定する際に別のマクロブロックを参照し、ビデオ画像４２０がその場所に挿入されるので、参照マクロブロックがフレームから除去される場合、マクロブロックの値が再計算される必要がある。同様に、マクロブロックが後続のフレーム内の別のマクロブロックを参照し、そのマクロブロックが除去され、他のソース材料がその場所に挿入される場合、マクロブロック値が再計算される必要がある。これは、ビデオ４３０をグルーミングすることによって対処される。ビデオフレームは、行が複数のスライスを含有し、そのうちのいくつかが、代替ビデオコンテンツに合致するように特異的にサイズ決定され、位置するように処理される。この過程が完了した後、現在のスライスのうちのいくつかをオーバーレイビデオと交換し、オーバーレイ４４０を有するグルーミングされたビデオをもたらすことは簡単なタスクである。グルーミングされたビデオストリームは、その特定のオーバーレイに対処するように具体的に定義されている。異なるオーバーレイが、異なるグルーミングパラメータを決定付ける。したがって、この種類のグルーミングは、ステッチングに備えてビデオフレームをスライスに区分化する過程に対処する。オーバーレイ要素にスライスを追加する必要性は決してないことに留意されたい。スライスは、受信要素、つまり、オーバーレイが配置される要素に追加されるだけである。グルーミングされたビデオストリームは、ストリームのグルーミングされた特性に関する情報を含有することができる。提供することができる特性は、１．グルーミングされたウィンドウの左上および右下隅の位置、２．左上隅のみの位置、次いで、ウィンドウのサイズを含む。スライスのサイズは、ピクセルレベルに正確である。

また、ビデオストリームの中で特性情報を提供する２つの方法もある。第１は、スライスヘッドの中でその情報を提供することができる。第２は、拡張データスライス構造の中で情報を提供することである。これらのオプションのいずれか一方は、仮想マシンおよびステッチャ等の将来の処理段階に必要な情報を成功裏に渡すために使用することができる。

図５は、グルーミング前後のビデオグラフィック要素に対するビデオシーケンスを示す。元の着信符号化ストリーム５００は、当業者に公知であるように、ＭＰＥＧ Ｉフレーム５１０、Ｂフレーム５３０、５５０、およびＰフレーム５７０のシーケンスを有する。この元のストリームでは、Ｉフレームは、ＢおよびＰの両方の全ての他のフレームに対する参照５１２として使用される。これは、Ｉフレームから全ての他のフレームまでの矢印を介して示される。また、Ｐフレームは、両方のＢフレームに対する参照フレーム５７２として使用される。グルーマは、ストリームを処理し、全てのフレームをＰフレームと交換する。第１の元のＩフレーム５１０は、イントラコード化されたＰフレーム５２０に変換される。次に、Ｂフレーム５３０、５５０は、Ｐフレーム５４０および５６０に変換され５３５、直前のフレームのみを参照するように修正される。また、Ｐフレーム５７０は、元のＩフレーム５１０から、それら自体のすぐ前に先行する新たに作成されたＰフレーム５６０に参照を移動させる５７４ように修正される。結果として生じるＰフレーム５８０は、グルーミングされた符号化フレーム５９０の出力フレームに示される。

図６は、標準ＭＰＥＧ−２ビットストリーム構文の概略図である。ＭＰＥＧ−２は、実施例として使用され、本発明は、この実施例に限定されると見なされるべきではない。ビットストリームの階級構造は、シーケンスレベルから始まる。これは、その後にピクチャーのグループ（ＧＯＰ）データ６０５が続くシーケンスヘッダ６００を含有する。ＧＯＰデータは、その後にピクチャーデータ６２５が続くＧＯＰヘッダ６２０を含有する。ピクチャーデータ６２５は、その後にスライスデータ６４５が続くピクチャーヘッダ６４０を含有する。スライスデータ６４５は、その後にマクロブロックデータ６６５が続く、何らかのスライスオーバーヘッド６６０から構成される。最終的に、マクロブロックデータ６６５は、その後にブロックデータ６８５が続く、何らかのマクロブロックオーバーヘッド６８０から構成される（ブロックデータはさらに分解されるが、それはこの参照目的では必要とされない）。シーケンスヘッダは、グルーマにおいて正常としての役割を果たす。しかしながら、全てのフレームがＰフレームであるため、グルーマのＧＯＰヘッダ出力がない。残りのヘッダは、必要とされる出力パラメータを満たすように修正されてもよい。

図７は、ビデオシーケンスをグルーミングするためのフローを提供する。最初に、フレーム種類が、Ｉフレーム７０３、Ｂフレーム７０５、またはＰフレーム７０７を決定している７００。Ｉフレーム７０３は、Ｂフレーム７０５のように、Ｐフレームに変換される必要がある。加えて、Ｉフレームは、ステッチャが必要とするピクチャー情報に合致する必要がある。例えば、この情報は、ピクチャーヘッダの中の符号化パラメータセットを示してもよい。したがって、第１のステップは、ピクチャーヘッダの中の情報が全てのグルーミングされたビデオシーケンスについて一貫しているように、ピクチャーヘッダ情報７３０を修正することである。ステッチャ設定は、アプリケーションに含まれてもよいシステムレベル設定である。これらは、全てのレベルのビットストリームに使用されるパラメータである。修正を必要とするアイテムは、以下の表で提供される。

次に、スライスオーバーヘッド情報７４０を修正しなければならない。修正するパラメータが以下の表に挙げられる。

次に、マクロブロックオーバーヘッド７５０情報は、修正を必要としてもよい。修正される値は、以下の表に挙げられる。

最終的に、ブロック情報７６０は、修正を必要としてもよい。修正される項目は、以下の表に挙げられる。

いったんブロック変更が完了すると、過程はビデオの次のフレームからもう一度やり直すことができる。

フレーム種類がＢフレーム７０５である場合、Ｉフレームに必要とされる同じステップはまた、Ｂフレームにも必要とされる。しかしながら、加えて、動きベクトル７７０が修正される必要がある。ＢフレームがＩフレームまたはＰフレームのすぐ後に続くか、またはＢフレームが別のＢフレームに続くという、２つのシナリオがある。ＢフレームがＩまたはＰフレームのいずれか一方に続く場合、ＩまたはＰフレームを参照として使用する動きベクトルは、同じままとなることができ、残りのみが変化する必要がある。これは、前向きの動きベクトルを残りに変換するのと同じくらい単純であってもよい。

別のＢフレームに続くＢフレームについては、動きベクトルおよびその残りが両方とも修正される必要がある。第２のＢフレームは、その直前に先行する新たに作成されたＢからＰのフレームを参照しなければならない。第１に、Ｂフレームおよびその参照が復号され、動きベクトルおよび残りが再計算される。フレームが動きベクトルを更新するように復号されている間に、ＤＣＴ係数を再符号化する必要性がないことに留意しなければならない。これらは同じままとなる。動きベクトルおよび残りのみが再計算され、修正される。

最後のフレーム種類はＰフレームである。このフレーム種類も、Ｉフレームと同じ経路を辿る。図８は、領域境界に隣接するマクロブロックに対する動きベクトル修正の概略図である。領域境界上の動きベクトルは、他のビデオ要素が挿入される背景要素に最も関連することを認識されたい。したがって、背景要素のグルーミングは、アプリケーション作成者によって達成されてもよい。同様に、ビデオ要素が切り取られ、背景要素の「穴」に挿入されている場合、切り取られた要素は、「穴」の外側の場所を指し示す動きベクトルを含んでもよい。切り取られた画像に対する動きベクトルをグルーミングすることは、ビデオ要素が切り取られる必要があるサイズをコンテンツ作成者が知っている場合に、コンテンツ作成者によって行われてもよく、またはグルーミングは、挿入されるビデオ要素が背景の「穴」のサイズよりも大きい場合に、要素レンダラおよびＭＰＥＧエンコーダと組み合わせて仮想マシンによって達成されてもよい。

図８は、背景要素から除去されている領域を包囲する動きベクトルとともに発生する問題を図形的に示す。図８の実施例では、場面は、２つの領域、＃１ ８００および＃２ ８２０を含む。不適切な動きベクトル参照の２つの実施例がある。第１の事例では、領域＃１ ８００（背景）に挿入している領域＃２ ８２０は、領域＃１ ８００（背景）を動きの参照８４０として使用する。したがって、領域＃２の中の動きベクトルは補正される必要がある。不適切な動きベクトル参照の第２の事例は、領域＃１ ８００が領域＃２ ８２０を動きの参照８６０として使用する場合に発生する。グルーマは、同じ領域内のフレームを使用して、これらの不適切な動きベクトル参照を再符号化すること、またはイントラコード化されたブロックになるようにマクロブロックを変換することによって、それらを除去する。

動きベクトルを更新し、フレーム種類を変更することに加えて、グルーマはまた、フィールドベースの符号化されたマクロブロックをフレームベースの符号化されたマクロブロックに変換してもよい。図９は、フレームベースへのフィールドベースの符号化されたマクロブロックの変換を示す。参照のため、フレームベースの一組のブロック９００が圧縮される。圧縮されたブロックセット９１０は、同じブロックの中に同じ情報を含有するが、ここでは圧縮形態で含有されている。一方で、フィールドベースのマクロブロック９４０も圧縮される。これが行われると、全ての偶数行（０、２、４、６）が上方ブロック（０および１）の中に配置される一方で、奇数行（１、３、５、７）が下方ブロック（２および３）の中に配置される。圧縮されたフィールドベースのマクロブロック９５０がフレームベースのマクロブロック９７０に変換されると、係数は１つのブロックから別のブロックへ移動させられる必要がある９８０。つまり、行は、奇数偶数よりもむしろ番号順に再構築されなければならない。フィールドベースの符号化においてブロック２および３の中にあった行１および３は、ここでは、それぞれブロック０または１へ上方に戻されている。それに対応して、行４および６は、ブロック０および１から移動させられ、ブロック２および３の中に下方に配置される。

図１０は、グルーミングプラットフォームの第２の実施形態を示す。全ての構成要素は、第１の実施形態と同じであり、グルーマ１１１０Ａおよびステッチャ１１４０Ａである。入力も同じであり、入力＃１ １１０３Ａ、入力＃２ １１０５Ａ、および入力＃３ １１０７Ａ、ならびに合成出力１２８０である。このシステムの違いは、ステッチャ１１４０Ａが、フィードバック、同期化およびフレーム種類情報の両方を、グルーマ１１１０Ａのそれぞれに提供することである。同期化およびフレーム種類情報を用いて、ステッチャ１１４０Ａは、グルーマ１１１０Ａが辿るＧＯＰ構造を画定することができる。このフィードバックおよびＧＯＰ構造を用いて、グルーマの出力は、もはやＰフレームではないだけでなく、ＩフレームおよびＢフレームを含むこともできる。フィードバックがない実施形態への制限は、どのような種類のフレームをステッチャが構築していたかを、いずれのグルーマも知らないことである。ステッチャ１１４０Ａからのフィードバックを伴うこの第２の実施形態では、グルーマ１１１０Ａが、どのようなピクチャー種類をステッチャが構築しているかを知るので、グルーマは、合致するフレーム種類を提供する。これは、同じデータレートを仮定して画質を向上させ、およびＢフレームが許容されるので、同時にビットレートを低減しながら、より多くの参照フレームおよび既存フレームのより少ない修正に起因して、品質レベルが一定に保たれることを仮定して、データレートを減少させ得る。

（ステッチャ）
図１１は、図１に示されるステッチャ等のステッチャモジュールを実装するための環境を示す。ステッチャ１２００は、異なるソースからビデオ要素を受信する。非圧縮コンテンツ１２１０は、ステッチャ１２００に着信する前に、図１に示されるＭＰＥＧ要素エンコーダ等のエンコーダ１２１５において符号化される。圧縮または符号化されたビデオ１２２０は、符号化される必要がない。しかしながら、両方の場合において、ビデオ１２１９、１２２９からオーディオ１２１７、１２２７を分離する必要性がある。オーディオは、ストリームの中に含まれるように、オーディオセレクタ１２３０に投入される。ビデオは、バッファ１２５０の中に入れられる前にフレーム同期化ブロック１２４０に投入される。フレームコンストラクタ１２７０は、コントローラ１２７５からの入力に基づいてバッファ１２５０からデータを引き出す。フレームコンストラクタ１２７０から出たビデオは、ビデオと整列するようにオーディオが遅延させられた１２６０後に、オーディオとともにマルチプレクサ１２８０に投入される。マルチプレクサ１２８０は、オーディオとビデオストリームとを組み合わせ、任意の標準デコーダ上で再生することができる合成された符号化出力ストリーム１２９０を出力する。データストリームをプログラムまたは輸送ストリームへと多重化することは、当業者に周知である。符号化されたビデオソースは、リアルタイム、記憶された場所から、または両方の組み合わせとなり得る。ソースの全てがリアルタイムで着信するという必要はない。

図１２は、時間的に同期していない３つのビデオコンテンツ要素の実施例を示す。３つの要素を同期化するために、要素＃１ １３００が「アンカ」または「参照」フレームとして使用される。つまり、それはマスタフレームとして使用され、全ての他のフレームがそれと整列させられる（つまり、実施例にすぎないが、システムは、着信ビデオソースのいずれかとは別個の独自のマスタフレーム参照を有することができる）。出力フレームタイミング１３７０、１３８０は、要素＃１ １３００のフレームタイミングに合致するように設定される。要素＃２ １３２０および要素＃３ １３４０は、要素＃１ １３００と整列しない。したがって、それらのフレーム開始が位置し、それらはバッファに記憶される。例えば、要素＃２ １３２０が１フレーム遅延されるので、参照フレームとともに合成される前に、フレーム全体が利用可能である。要素＃３は、参照フレームよりもはるかに遅い。要素＃３は、２つのフレームにわたって収集され、２つのフレームにわたって提示される。つまり、要素＃３ １３４０の各フレームは、参照フレームのフレームレートに合致するために、２つの連続フレームに対して表示される。逆に、示されていないフレームが、参照フレームのレートの速度の２倍で走行していた場合には、１つおきのフレームがドロップされる（図示せず）。おそらく全ての要素がほぼ同じ速度で走行しているので、同期化を維持するためにフレームが反復またはドロップされる必要はたまにしかない。

図１３は、合成ビデオフレーム例１４００を示す。この実施例では、フレームは、ピクチャーにつき３０行１４２０を伴って、１行当たり４０個のマクロブロック１４１０から構成される。サイズは実施例として使用され、本発明の範囲を限定することを目的としていない。フレームは、種々の場所において合成された要素１４４０を有する背景１４３０を含む。これらの要素１４４０は、ビデオ要素、静的要素等となり得る。つまり、フレームは、全背景から構築され、それは次いで、異なる要素と交換される特定の領域を有する。この特定の実施例は、背景上に合成された４つの要素を示す。

図１４は、ピクチャー内のスライスを図示する画面のより詳細なバージョンを示す。この概略図は、１行当たり４０個のマクロブロックおよびピクチャーにつき３０行から構成されるピクチャーを描写する（非限定的であって、例示目的にすぎない）。しかしながら、それはまた、スライスに分割されたピクチャーも示す。スライスのサイズは、行全体１５９０（影付きとして示される）または行１５８０内のいくつかのマクロブロック（要素＃４ １５２８の内側の斜線付きの長方形として示される）となり得る。背景１５３０は、各領域の幅に合致するスライスサイズを有する複数の領域に分解されている。これは、要素＃１ １５２２を見ることによって、より良好に分かる。要素＃１ １５２２は、１２個のマクロブロックの幅となるように画定されている。次いで、背景１５３０および要素＃１ １５２２の両方に対する、この領域のスライスサイズは、正確な数のマクロブロックとなるように画定される。次いで、要素＃１ １５２２は、６つのスライスから成り、各スライスは、１２個のマクロブロックから構成される。同様に、要素＃２ １５２４は、スライス当たり８個のマクロブロックの４個のスライスから成り、要素＃３ １５２６は、スライス当たり２３個のマクロブロックの１８個のスライスであり、要素＃４ １５２８は、スライス当たり５個のマイクロブロックの１７個のスライスである。背景１５３０および要素は、任意の数のスライスから構成されるように画定することができ、スライスは次に、任意の数のマイクロブロックとなり得ることが明らかである。これは、所望される任意の様式でピクチャーおよび要素を配設する完全なフレキシビリティを与える。ビデオフレーム内の要素の位置付けとともに、各要素に対するスライスコンテンツを決定する過程は、ＡＶＭＬファイルを使用して、図１の仮想マシンによって決定される。

図１５は、ステッチングがステッチャにおいて発生するための仮想マシンによる背景１６００の分離を示す。仮想マシンは、ＡＶＭＬファイルに基づいて非圧縮背景を集め、背景を要素エンコーダに転送する。仮想マシンは、要素がフレームの中に配置される背景内の場所を転送する。示されるように、背景１６２０は、背景を要素エンコーダに渡す前に要素が配置される場所と正確に整列する穴を伴って、仮想マシンによって特定のスライス構成に分解されている。エンコーダは、要素が配置される「１つの穴」または「複数の穴」を残して背景を圧縮する。エンコーダは、圧縮された背景をメモリに渡す。次いで、仮想マシンは、メモリにアクセスし、場面に対する各要素を読み出し、要素のそれぞれに対する各スライスの場所のリストとともに、符号化された要素をステッチャに渡す。ステッチャは、スライスのそれぞれを取り出し、スライスを適正な位置に配置する。

この特定の種類の符号化は、「スライスベースの符号化」と呼ばれる。スライスベースのエンコーダ／仮想マシンは、出力フレームの所望のスライス構造を認識し、その符号化を適切に行うものである。つまり、エンコーダは、スライスのサイズおよびそれらが属する場所を知っている。それは、必要とされる場合に穴を残す場所を知っている。所望の出力スライス構成を認識することによって、仮想マシンは、容易にステッチされる出力を提供する。

図１６は、背景要素が圧縮された後の合成過程を示す。背景要素１７００は、要素１７４０が配置される穴を伴って、７個のスライスに圧縮されている。合成画像１７８０は、背景要素１７００と要素１７４０との組み合わせの結果を示す。合成ビデオフレーム１７８０は、グレーで挿入されているスライスを示す。この概略図は、背景上に合成される単一の要素を描写するが、ユーザのディスプレイ上に嵌合する任意の数の要素を合成することが可能である。さらに、背景または要素に対する１行当たりのスライスの数は、示されているものよりも大きくなり得る。背景と要素とのスライス始点およびスライス終点は整列しなければならない。

図１７は、背景要素１８００（２４ピクセル×２４ピクセル）と追加されるビデオコンテンツ要素１８４０（１６ピクセル×１６ピクセル）との間の異なるマクロブロックサイズを示す概略図である。合成ビデオフレーム１８８０は、２つの場合を示す。水平方向に、ピクセルは、背景８００では２４ピクセル／ブロック×４ブロック＝幅９６ピクセル、およびビデオコンテンツ要素１８４０については１６ピクセル／ブロック＊６ブロック＝幅９６ピクセルがあるように整列する。しかしながら、垂直方向には違いがある。背景１８００は、２４ピクセル／ブロック＊３ブロック＝高さ７２ピクセルである。要素１８４０は、１６ピクセル／ブロック＊４ブロック＝高さ６４ピクセルである。これは、８ピクセルの垂直方向の間隙１８６０を残す。ステッチャは、そのような違いを認識しており、要素または背景のいずれか一方を外挿して間隙を埋めることができる。また、濃い色または明るい色の境界領域があるように、間隙を残すことも可能である。この実施例は、２４×２４および１６×１６のマクロブロックサイズを使用するが、マクロブロックサイズの任意の組み合わせが容認可能である。ＤＣＴベースの圧縮形式は、本発明の意図された範囲から逸脱することなく、１６×１６以外のサイズのマクロブロックに依存してもよい。同様に、ＤＣＴベースの圧縮形式はまた、本発明の意図された範囲から逸脱することなく、時間予測のために可変サイズのマクロブロックに依存してもよい。最終的に、本発明の意図された範囲から逸脱することなく、他のフーリエ関連変換を使用して、コンテンツの周波数領域表現も達成されてもよい。

また、合成ビデオフレーム内に重複があることも可能である。図１７を再び参照すると、要素１８４０は、４個のスライスから構成される。この要素が実際には５個のスライスである場合、合成ビデオフレーム１８８０内の背景要素１８００と重複する。この対立を解決するための複数の方法があり、最も容易な方法は、要素の４個のスライスのみを合成して、第５のスライスをドロップすることである。また、第５のスライスを背景行の中へ合成し、スライスの中への相反する背景行を壊し、第５の要素スライスと対立する背景スライスを除去する（次いで、おそらく第６の要素スライスを追加して間隙を埋める）ことも可能である。

異なるスライスサイズの可能性は、着信背景およびビデオ要素のチェックを行って、それらが適正であると確認するために、合成機能を必要とする。つまり、それぞれが完全（例えば、フルフレーム）であること、サイズ対立がないこと等を確認する。

図１８は、フレームの要素を描写する概略図である。単純合成ピクチャー１９００は、要素１９１０および背景要素１９２０から構成される。要求された場面に対するビデオフレームの構築を制御するために、ステッチャは、仮想マシンによって提供されるような各要素の位置情報に基づいて、データ構造１９４０を構築する。データ構造１９４０は、いくつのマクロブロックがあり、どこにマクロブロックが位置するかを説明するリンクされたリストを含有する。例えば、データ行１ １９４３は、背景に対するバッファであるバッファＢから、ステッチャが４０個のマクロブロックを取るべきであることを示す。データ行２ １９４５は、バッファＢから１２個のマクロブロックを、バッファＥ（要素１９１０に対するバッファ）から８個のマクロブロックを、次いで、バッファＢからさらに２０個のマクロブロックを取るべきである。これは、ステッチャがバッファＢから４０個のマクロブロックを取るためにデータ構造を使用する最後の行１９４７まで続く。バッファ構造１９７０は、各背景または要素に対する別個の領域を有する。Ｂバッファ１９７３は、Ｂマクロブロックをステッチするための全ての情報を含有する。Ｅバッファ１９７５は、Ｅマクロブロックをステッチするための情報を有する。

図１９は、複数の符号化された要素からピクチャーを構築するための過程を描写するフローチャートである。シーケンス２０００は、ビデオフレーム合成２０１０を開始することによって始まる。第１に、フレームが同期化され２０１５、次いで、各行２０２０が、適切なスライス２０３０を把持することによって構築される。次いで、スライスは、挿入され２０４０、システムは、それが行の終了２０５０であるか否かを確かめる。もしそうでなければ、行の終了２０５０に達するまで、過程は「次のスライスを取り出す」ブロック２０３０に戻る。いったん行が完成すると、システムは、それがフレームの終了２０８０であるか否かを確かめる。もしそうでなければ、過程は「各行について」２０２０ブロックに戻る。いったんフレームが完成すると、システムは、それが場面に対するシーケンスの終了２０９０であるか否かを確かめる。もしそうでなければ、過程は「フレームを構成する」２０１０に戻る。もしそうであれば、場面に対するフレームまたは一連のビデオフレームが完成する２０９０。もしそうでなければ、フレーム構築過程を繰り返す。シーケンスの終了２０９０に達した場合、場面が完成し、過程が終了するか、または別のフレームの構築を開始することができる。

ステッチャの性能は、フレーム形式についてのステッチャ事前情報を提供することによって向上させることができる（より少ないプロセッサ出力でフレームをより高速で構築する）。例えば、仮想マシンは、挿入されるフレーム内の領域の開始場所およびサイズをステッチャに提供してもよい。代替として、情報は、各スライスの開始場所となり得て、次いで、ステッチャは、サイズ（２つの開始場所の間の差）を把握することができる。この情報は、仮想マシンによって外部から提供することができ、または仮想マシンは、情報を各要素に組み込むことができる。例えば、この情報を運ぶためにスライスヘッダの一部を使用することができる。ステッチャは、必要とされる前に要素を一緒にうまく合成し始めるために、このフレーム構造の予備知識を使用することができる。

図２０は、システムのさらなる改良を示す。グルーマの項において上記で説明されたように、グラフィックビデオ要素をグルーミングすることができ、それにより、すでに圧縮されており、一緒にステッチされるために復号される必要がないステッチ可能な要素を提供する。図２０では、フレームは、いくつかの符号化されたスライス２１００を有する。各スライスは、行全体である（これは実施例のみとして使用され、行はグルーミング前の複数のスライスから構成されることができる）。仮想マシンは、ＡＶＭＬファイルと組み合わせて、合成ビデオフレーム内の特定の場所に配置された特定のサイズの要素２１４０が存在するべきであると決定する。グルーマは、着信背景２１００を処理し、行全体の符号化されたスライスを、所望の要素２１４０の場所の周囲および中の領域に合致するより小さいスライスに変換する。結果として生じるグルーミングされたビデオフレーム２１８０は、所望の要素２１４０に合致するスライス構成を有する。次いで、ステッチャは、グルーミングされたフレーム２１８０の＃３および＃６を除いた全てのスライスを選択することによって、ストリームを構築する。これらのスライスの代わりに、ステッチャは、要素２１４０のスライスを把持し、その場所で使用する。このようにして、背景は、圧縮領域を決して残さず、システムは、依然として要素２１４０をフレームに合成することができる。

図２１は、合成される要素を画定するために利用可能なフレキシビリティを示す。要素は、異なる形状およびサイズとなり得る。要素は、連続的に存在する必要はなく、実際、背景によって分離される複数の画像から単一の要素を形成することができる。この図は、その上に合成された単一の要素２２１０（白に着色された領域）を有する背景要素２２３０（グレーに着色された領域）を示す。この概略図では、合成要素２２１０は、移行されているか、異なるサイズであるか、または単一の行の上に要素の複数の部分さえあるような領域を有する。ステッチャは、表示を作成するために使用される複数の要素があるかのように、このステッチングを行うことができる。フレームに対するスライスは、連続的にＳ１−Ｓ４５と標識される。これらは、要素が配置されるスライスの場所を含む。要素はまた、ＥＳ１−ＥＳ１４のスライス番号も有する。要素スライスは、たとえ単一の要素ファイルから引き出されたとしても、所望される場所で背景の中に配置することができる。

要素スライスのソースは、いくつかのオプションのうちのいずれか１つとなり得る。それは、リアルタイム符号化ソースに由来することができる。それは、一方は背景を有し、他方はテキストを有する別個のスライスから構築される複合スライスとなり得る。それは、キャッシュから取り出される事前符号化された要素となり得る。これらの実施例は、例示目的にすぎず、要素ソースのオプションを限定することを目的としていない。

図２２は、線形放送コンテンツをグルーミングするためのグルーマ２３４０を使用した実施形態を示す。コンテンツは、リアルタイムでグルーマ２３４０によって受信される。各チャネルは、コンテンツをともに容易にステッチすることができるように、グルーマ２３４０によってグルーミングされる。図２２のグルーマ２３４０は、線形放送チャネルの全てをグルーミングするための複数のグルーマモジュールを含んでもよい。次いで、グルーミングされたチャネルは、アプリケーションで使用するために、１つ以上の処理オフィス２３１０、２３２０、２３３０、および処理オフィスのそれぞれの内側の１つ以上の仮想マシンにマルチキャストされてもよい。示されるように、クライアントデバイスは、クライアントによって選択される線形放送ソースおよび／または他のグルーミングされたコンテンツのモザイク２３５０の受信用のアプリケーションを要求する。モザイク２３５０は、図２３に示されるように、複数のソース２３７１−２３７６の視聴を同時に可能にする背景フレーム２３６０を含む。例えば、ユーザが見ることを希望する複数のスポーツイベントがある場合、ユーザは、モザイク内で同時に視聴するためにスポーツイベントを運ぶチャネルのそれぞれを要求することができる。ユーザは、ＭＰＥＧオブジェクト（編集）２３８０を選択し、次いで、表示される所望のコンテンツソースを編集することさえできる。例えば、グルーミングされたコンテンツは、線形／生放送から、また、他のビデオコンテンツ（すなわち、映画、事前録画されたコンテンツ等）からも選択することができる。モザイクは、ユーザ選択された材料、および広告等の処理オフィス／セッションプロセッサによって提供された材料の両方さえ含んでもよい。図２２に示されるように、クライアントデバイス２３０１−２３０５はそれぞれ、チャネル１を含むモザイクを要求する。したがって、チャネル１に対するマルチキャストのグルーミングされたコンテンツは、個人化モザイクの中で異なる仮想マシンおよび異なる処理オフィスによって使用される。

クライアントデバイスがモザイクアプリケーションの要求を送信すると、クライアントデバイスと関連付けられる処理オフィスは、要求されたモザイクアプリケーションに対するクライアントデバイスにプロセッサ／仮想マシンを割り当てる。割り当てられた仮想マシンは、ステッチャを使用して、所望のチャネルからのグルーミングされたコンテンツを合成することによって、個人化モザイクを構築する。仮想マシンは、クライアントが要求したチャネルのモザイクを有するＭＰＥＧストリームをクライアントデバイスに送信する。したがって、コンテンツを一緒にステッチすることができるように最初にコンテンツをグルーミングすることによってモザイクを作成する仮想マシンは、最初に所望のチャネルを復号し、ビットマップとして背景内でチャネルをレンダリングし、次いで、ビットマップを符号化する必要がない。

モザイク等のアプリケーションは、クライアントデバイスと関連付けられるディスプレイ上でのアプリケーションの表示のために、クライアントデバイスを通して直接、またはＰＣ等の別のデバイスを通して間接的に要求することができる。ユーザは、ユーザのアカウントに関する情報を提供することによって、処理オフィスと関連付けられるウェブサイトにログインすることができる。処理オフィスと関連付けられるサーバは、アプリケーションを選択するための選択画面をユーザに提供する。ユーザがモザイクアプリケーションを選択した場合、サーバは、ユーザがモザイク内で視聴することを希望するコンテンツをユーザが選択することを可能にする。モザイクに対する選択されたコンテンツに応じて、ユーザの情報を使用して、処理オフィスサーバは、セッションプロセッサに要求を方向付け、ユーザのクライアントデバイスとの双方向セッションを確立する。次いで、セッションプロセッサは、所望のアプリケーションの処理オフィスサーバによって形成される。セッションプロセッサは、所望のアプリケーション、この実施例ではモザイクアプリケーションを読み出し、必要なＭＰＥＧオブジェクトを取得する。次いで、処理オフィスサーバは、要求されたビデオコンテンツについてセッションプロセッサに知らせ、セッションプロセッサは、ステッチャと連携して動作し、モザイクを構築し、ＭＰＥＧビデオストリームとしてのモザイクをクライアントデバイスに提供する。したがって、処理オフィスサーバは、双方向セッションを設定すること、アプリケーションを要求すること、および表示することのためのコンテンツを選択する際に、クライアントデバイスの機能を果たすためのスクリプトまたはアプリケーションを含んでもよい。モザイク要素は、アプリケーションによって事前決定されてもよいが、また、ユーザ構成可能であってもよく、個人化モザイクをもたらす。

図２４は、ＩＰベースのコンテンツ送達システムの概略図である。このシステムでは、コンテンツは、放送ソース２４００、コンテンツプロバイダ２４１０によって投入されるプロキシキャッシュ２４１５、構成および管理ファイル２４２０を含有するネットワーク接続ストレージ（ＮＡＳ）２４２５、または示されていない他のソースに由来してもよい。例えば、ＮＡＳは、コンテンツの場所に関する情報を提供するアセットメタデータを含んでもよい。このコンテンツは、負荷バランシングスイッチ２４６０を介して利用可能となり得る。ブレードセッションプロセッサ／仮想マシン２４６０は、コンテンツに異なる処理機能を行い、それを送達のために準備することができる。コンテンツは、セットトップボックス２４９０等のクライアントデバイスを介してユーザに要求される。この要求は、このコンテンツを提供するようにリソースおよび経路を構成する、コントローラ２４３０によって処理される。クライアントデバイス２４９０は、コンテンツを受信し、それをユーザのディスプレイ２４９５上で提示する。

図２５は、ケーブルベースのコンテンツ送達システムの概略図を提供する。構成要素の多くは同じであり、コントローラ２５３０、放送ソース２５００、プロキシキャッシュ２５１５を介してコンテンツを提供するンテンツプロバイダ２５１０、ファイルサーバＮＡＳ２５２５を介した構成および管理ファイル２５２０、セッションプロセッサ２５６０、負荷バランシングスイッチ２５５０、セットトップボックス２５９０等のクライアントデバイス、およびディスプレイ２５９５である。しかしながら、異なる物理的媒体により、いくつかの必要とされる付加的な機器もある。この場合、追加されたリソースは、ＱＡＭ変調器２５７５、帰還路受信機２５７０、結合器およびダイプレクサ２５８０、ならびにセッションおよびリソースマネージャ（ＳＲＭ）２５４０を含む。ＱＡＭアップコンバータ２５７５は、ユーザへ下流にデータ（コンテンツ）を伝送するように要求される。これらの変調器は、データを、ユーザまで進む同軸ケーブルを横断して運ぶことができる形式に変換する。それに対応して、帰還路受信機２５７０はまた、セットトップ２５９０からケーブルまで達するデータを復調するために使用される。結合器およびダイプレクサ２５８０は、下流ＱＡＭチャネルを組み合わせ、上流帰還チャネルを分割する受動デバイスである。ＳＲＭは、ＱＡＭ変調器がどのように構成され、割り当てられるか、およびストリームがどのようにクライアントデバイスに送られるかを制御する実体である。

これらの付加的なリソースは、システムに費用を追加する。結果として、所望されることは、ＩＰネットワーク等の非遮断システムを模倣するレベルの性能をユーザに送達するために必要とされる付加的なリソースの数を最小化することである。ケーブルネットワークリソースとネットワーク上のユーザとの間に１対１の対応がないので、リソースを共有しなければならない。共有されたリソースは、ユーザがリソースを必要とするときに割り当てることができ、ユーザがそのリソースを利用し終わったときに解放することができるように、管理されなければならない。これらのリソースの適正な管理は、それがなければ、最も必要とされるときにリソースが利用不可能となり得るので、操作者にとって重要である。これが起こった場合、ユーザは、「お待ち下さい」というメッセージ、または最悪の場合は「サービス利用不可能」というメッセージを受信する。

図２６は、ユーザからの入力に基づいて新しい双方向セッションを構成するために必要とされるステップを示す概略図である。この概略図は、割り付けられなければならない、または管理されなければならない、あるいは割付または管理を行うために使用されなければなれない項目のみを描写する。典型的な要求は、以下に記載されるステップに従う。
（１）セットトップボックス２６０９が、コントローラ２６０７からコンテンツ２６１０を要求する
（２）コントローラ２６０７が、ＳＲＭ２６０３からＱＡＭ帯域幅２６２０を要求する
（３）ＳＲＭ２６０３が、ＱＡＭ可用性２６２５をチェックする
（４）ＳＲＭ２６０３が、ＱＡＭ変調器２６３０を割り付ける
（５）ＱＡＭ変調器が、確認２６３５を返信する
（６）ＳＲＭ２６０３が、コントローラにＱＡＭ割付成功２６４０を確認する
（７）コントローラ４０７が、セッションプロセッサ２６５０を割り付ける
（８）セッションプロセッサが、割付成功２６５３を確認する
（９）コントローラ２６０７が、コンテンツ２６５５を割り付ける
（１０）コントローラ２６０７が、セットトップ２６０９を構成する２６６０。これは、
ａ．同調する周波数
ｂ．獲得するプログラム、または代替として復号するＰＩＤ
ｃ．キーストロークキャプチャのためにセッションプロセッサに接続するＩＰポート
を含む。
（１１）セットトップ２６０９が、チャネル２６６３に同調する
（１２）セットトップ２６０９が、コントローラ２６０７に成功２６６５を確認する
コントローラ２６０７は、セットトップボックス２６０９からのサービスの要求に基づいてリソースを割り付ける。それは、セットトップまたはサーバが「セッションの終了」を送信するときに、これらのリソースを解放する。コントローラ２６０７が、最小の遅延を伴って迅速に反応することができる一方で、ＳＲＭ２６０３は、１秒当たりに設定された数のＱＡＭセッション、すなわち、２００を割り付けることしかできない。この速度を超える需要は、ユーザにとって容認不可能な遅延をもたらす。例えば、５００の要求が同時に来た場合、最後のユーザは、要求が承認される前に５秒待たなければならない。また、要求が承認されるよりもむしろ、「サービス利用不可能」などのエラーメッセージを表示できることも可能である。

上記の実施例が、ケーブルＴＶネットワーク上のＡＶＤＮセッションに対する要求および応答シーケンスを説明する一方で、以下の実施例は、ＩＰＴＶネットワーク上の同様のシーケンスを説明する。シーケンスは、それ自体が請求項ではないが、むしろＡＶＤＮがＩＰＴＶネットワーク上でどのように稼働するかを例示することに留意されたい。
（１）クライアントデバイスが、セッションマネージャ（すなわち、コントローラプロキシ）を介してコントローラからコンテンツを要求する。
（２）セッションマネージャが、要求をコントローラに転送する。
（３）コントローラが、セッションマネージャ（すなわち、クライアントプロキシ）を介して要求されたコンテンツに反応する。
（４）セッションマネージャが、ユニキャストセッションを開き、ユニキャストＩＰセッション上でコントローラ応答をクライアントに転送する。
（５）クライアントデバイスが、ユニキャストＩＰセッション上でコントローラ応答を獲得する。
（６）セッションマネージャが、帯域幅使用最適化技法として、同じコンテンツを同時に要求するノードグループ上で他のクライアントと共有するように、マルチキャストＩＰセッション上で応答を同時にナローキャストしてもよい。

図２７は、性能向上のために各領域を分解するために使用される簡略化システム図である。この概略図は、管理されるデータおよび機器のみに焦点を当て、全ての他の管理されていない項目を除去する。したがって、スイッチ、帰還路、結合器等は、明確にするために除去されている。この概略図は、エンドユーザからコンテンツ起点に戻るように作動する各アイテムを通して進めるために使用される。

第１の問題は、ＳＲＭ２７２０によるＱＡＭ２７７０およびＱＡＭチャネル２７７５の割当である。具体的には、ＳＲＭ過負荷を防止するようにリソースを管理しなければならない、つまり、ＳＲＭ２７２０への要求が１秒当たりのセッションを超えるときにユーザが経験する遅延を排除しなければならない。

ＳＲＭ「過負荷」を防止するために、「時間ベースのモデリング」が使用されてもよい。時間ベースのモデリングのために、コントローラ２７００は、過去のトランザクション、特に、高負荷期間の履歴を監視する。この以前の履歴を使用することによって、コントローラ２７００は、例えば、０時に高負荷期間が発生する場合があるときを予測することができる。コントローラ２７００は、期間が来る前にリソースを事前に割り付けるために、この知識を使用する。つまり、それは、将来のリソース要件を決定するために、予測アルゴリズムを使用する。実施例として、ユーザが特定の時間に参加しようとしているとコントローラ２７００が考える４７５場合、ロードがヒットしたときに、リソースがすでに割り付けられており、いずれのユーザも遅延を経験しないように、それらのリソースを５秒早く割り付け始めることができる。

第２に、リソースは、操作者からの入力に基づいて事前に割り付けることができる。主要なイベント、例えば、有料スポーツイベントが来るべきことを操作者が知っている場合、予期してリソースを事前に割り当てることを希望してもよい。両方の場合において、ＳＲＭ２７２０は、使用されていないとき、およびイベント後に、未使用のＱＡＭ２７７０リソースを解放する。

第３に、ＱＡＭ２７７０は、以前の履歴とは無関係である「変化率」に基づいて割り付けることができる。例えば、コントローラ２７００がトラフィックの急上昇を認識する場合、付加的なセッションを追加するときにＱＡＭ割付ステップを回避するために、必要以上のＱＡＭ帯域幅を要求することができる。予期しない急上昇の実施例は、ユーザがこのボタンを選択した場合に獲得することができる賞を示すプログラムの一部としてのボタンとなる場合がある。

現在、各セッションが追加されるためのＳＲＭ２７２０への１つの要求がある。代わりに、コントローラ２７００は、ＱＡＭ全体２７７０または単一のＱＡＭの帯域幅の大部分を要求し、本発明がそのＱＡＭチャネル２７７５内でデータを処理することを可能にすることができる。このシステムの一側面が、わずか１、２、または３Ｍｂ／秒であるチャネルを作成する能力であるので、これは、最大２７の要求を単一の要求と置き換えることによって、ＳＲＭ２７２０への要求の数を削減することができる。

ユーザはまた、たとえすでにアクティブセッション中であっても異なるコンテンツを要求するときに、遅延を経験する。現在、セットトップ２７９０がアクティブセッション中であり、新しい一組のコンテンツ２７３０を要求する場合、コントローラ２７００は、ＱＡＭ２７７０の割付を解除するようにＳＲＭ２７２０に伝えなければならず、次いで、コントローラ２７００は、セッションプロセッサ２７５０およびコンテンツ２７３０の割付を解除し、ＳＲＭ２７２０から別のＱＡＭ２７７０を要求し、次いで、異なるセッションプロセッサ２７５０およびコンテンツ２７３０を割り付けなければならない。代わりに、コントローラ２７００は、ＱＡＭ変調器２７７０に投入するビデオストリーム２７５５を変更し、それにより、以前に確立された経路をそのままにしておくことができる。第１に、ＱＡＭ変調器２７７０がネットワーク上にあるため、コントローラ２７００は、ＱＡＭ２７７０を駆動するセッションプロセッサ２７５０を変更することしかできない。第２に、コントローラ２７００は、セッションプロセッサ２７５０とセットトップ２７９０との接続をそのままにしておくが、セッションプロセッサ２７５０に投入するコンテンツ２７３０を、例えば、「ＣＮＮ Ｈｅａｄｌｉｎｅ Ｎｅｗｓ」または「ＣＮＮ Ｗｏｒｌｄ Ｎｏｗ」に変更することができる。これらの方法の両方は、ＱＡＭ初期化およびセットトップ同調遅延を排除する。

したがって、リソースは、これらの双方向サービスを提供するために必要とされる機器の量を最小化するように知的に管理される。具体的には、コントローラは、ＱＡＭ２７７０に投入するビデオストリーム２７５５を操作することができる。これらのストリーム２７５５をプロファイルすることによって、コントローラ２７００は、ＱＡＭ２７７０内のチャネル使用を最大化することができる。つまり、各ＱＡＭチャネル２７７５におけるプログラムの数を最大化し、無駄な大気幅およびＱＡＭ２７７０の必要数を削減することができる。定型、事前プロファイリング、および生フィードバックといった、ストリームをプロファイルする３つの主要な手段がある。

第１のプロファイリング方法、定型は、ＱＡＭチャネル２７７５を満たすために使用される種々のビデオストリームのビットレートを加算することから構成される。具体的には、単一のビデオストリーム２７５５を作成するために使用される多くのビデオ要素があってもよい。ビデオストリーム２７５５の総ビットレートを求めるために、各要素の最大ビットレートを一緒に加算することができる。全てのビデオストリーム２７５５のビットレートを監視することによって、コントローラ２７００は、ＱＡＭチャネル２７７５を最も効率的に使用するビデオストリーム２７５５の組み合わせを作成することができる。例えば、４つのビデオストリーム２７５５、１６Ｍｂ／秒であった２つ、および２０Ｍｂ／秒であった２つがあった場合、コントローラは、チャネル当たり各ビットレートの１つを割り付けることによって、３８．８Ｍｂ／秒ＱＡＭチャネル２７７５を最も良好に満たすことができる。次いで、これは、２つのＱＡＭチャネル２７７５がビデオを送達することを要求する。しかしながら、定型プロファイリングがないと、おそらく２つの１６Ｍｂ／秒ビデオストリーム２７５５が、単一の３８．８Ｍｂ／秒ＱＡＭチャネル２７７５に組み込まれ、次いで、各２０Ｍｂ／秒ビデオストリーム２７５５が独自の３８．８Ｍｂ／秒ＱＡＭチャネル２７７５を持たなければならないため、結果は、最終的には３つのＱＡＭチャネル２７７５となり得る。

第２の方法は、事前プロファイリングである。この方法では、コンテンツ２７３０に対するプロファイルは、内部で受信または生成される。プロファイル情報は、ストリームを伴うメタデータの中または別個のファイルの中で提供することができる。プロファイリング情報は、ビデオ全体から、または代表的なサンプルから生成することができる。次いで、コントローラ２７００は、ストリームの中の種々の時間におけるビットレートを認識し、ビデオストリーム２７５５をともに効果的に組み合わせるために、この情報を使用することができる。例えば、２つのビデオストリーム２７５５が両方とも２０Ｍｂ／秒のピーク速度を有する場合、それらのピークに基づく割り付けられた帯域幅であれば、それらは異なる３８．８Ｍｂ／秒ＱＡＭチャネル２７７５に割り付けられる必要がある。しかしながら、公称ビットレートが１４Ｍｂ／秒であることをコントローラが知っており、それぞれのプロファイルを知っているため、同時ピークがない場合、コントローラ２７００は、ストリーム２７５５を単一の３８．８Ｍｂ／秒ＱＡＭチャネル２７７５に組み込むことができる。特定のＱＡＭビットレートは、上記の実施例のみに使用され、制限として解釈されるべきではない。

プロファイリングのための第３の方法は、システムによって提供されるフィードバックを介する。システムは、ストリームを構築するために使用される全てのビデオ要素に対する現在のビットレート、およびストリームが構築された後のストリームの総ビットレートについて、コントローラ２７００に知らせることができる。さらに、それは、使用前の記憶された要素のビットレートについて、コントローラ２７００に知らせることができる。この情報を使用して、コントローラ２７００は、ＱＡＭチャネル２７７５を満たすための最も効率的な方式でビデオストリーム２７５５を組み合わせることができる。

また、３つのプロファイリング方法のいずれかまたは全てを組み合わせて使用することも容認可能であると留意されたい。つまり、それらが独立して使用されなければならないという制限はない。

システムはまた、リソース自体の使用に対処することもできる。例えば、セッションプロセッサ２７５０が１００人のユーザをサポートすることができ、現在アクティブである３５０人のユーザがいる場合、４つのセッションプロセッサを必要とする。しかしながら、需要が、例えば、８０人のユーザまで低下すると、これらのリソースを単一のセッションプロセッサ２７５０に割り付け、それにより、３つのセッションプロセッサの残りのリソースを節約する価値がある。これはまた、故障の状況でも有用である。リソースが故障した場合、本発明は、セッションを利用可能である他のリソースに再び割り当てることができる。このようにして、ユーザにとっての混乱が最小化される。

システムはまた、予期される使用に応じて、機能を再利用することもできる。セッションプロセッサ２７５０は、例えば、ビデオを処理する、オーディオを処理する等といった、いくつかの異なる機能を実装することができる。コントローラ２７００は、使用履歴を有するので、予期された需要を満たすようにセッションプロセッサ２７００上の機能を調整することができる。例えば、昼過ぎに、典型的には、音楽の高い需要がある場合、コントローラ２７００は、需要を予期して音楽を処理するように付加的なセッションプロセッサ２７５０を再び割り当てることができる。それに対応して、夕方にニュースについての高い需要がある場合、コントローラ２７００は、需要を予期し、それに従ってセッションプロセッサ２７５０を再び割り当てる。システムのフレキシビリティおよび予測は、最小量の機器を用いて最適なユーザ経験を提供することを可能にする。つまり、単一の目的しかないため、いずれの機器も待機状態ではなく、その目的は必要とされない。

図２８は、アンマネージドＩＰネットワークを介して双方向コンテンツを加入者に提供することができるマネージド放送コンテンツ衛星ネットワークを示す。マネージドネットワークは、伝送されるコンテンツがエンドユーザによってではなく、サービスプロバイダのみによって決定される通信ネットワークである。したがって、サービスプロバイダは、提示されたコンテンツの運営制御を有する。マネージドネットワークでは、ユーザは、サービスプロバイダによって放送される複数のチャネルからチャネルを選択してもよいが、全体的なコンテンツはサービスプロバイダによって決定され、ユーザは、ネットワーク外のいずれの他のコンテンツにもアクセスすることができない。マネージドネットワークは、閉鎖ネットワークである。マネージドネットワークは、例えば、衛星ネットワーク、ケーブルネットワーク、およびＩＰテレビネットワークであってもよい。アンマネージドネットワークは、ユーザがコンテンツを要求し、サービスプロバイダ以外の相手から受信することを可能にする。例えば、インターネットは、アンマネージドネットワークであり、インターネットと通信しているユーザは、複数のソースのうちの１つからコンテンツを受信することを選択することができ、インターネットサービスプロバイダ（ＩＳＰ）によって提供されるコンテンツによって限定されない。これらの定義は、物理的相互接続から独立しており、論理関連である。実際に、マネージドネットワークおよびアンマネージドネットワークの両方は、同じ物理的通信リンク上で動作してもよい。

図２８に示されるように、放送コンテンツは、１つ以上の指定チャネル上でマネージドネットワークオフィス２８０１によって衛星２８００にアップロードされる。チャネルは、別個の周波数であってもよく、またはチャネルは、デリミタ（すなわち、ヘッダ情報）によってともに関係付けられるデータの関連であってもよい。受信衛星２８００は、加入者によって選択することができる複数のチャネルを含む放送コンテンツを再伝送する。加入者の家庭にある衛星受信機２８０２は、伝送を受信し、伝送をセットトップボックス等のクライアントデバイス２８０３に転送する。クライアントデバイスは、衛星伝送を復号し、加入者の表示デバイス２８０４上で視聴するために選択されたチャネルを提供する。

放送伝送の放送コンテンツ内には１つ以上のトリガがある。トリガは、可能な双方向コンテンツの指定子である。例えば、トリガは、放送コンテンツ内に挿入されるか、または放送コンテンツを含有するフレームの一部である宣伝を伴ってもよい。トリガは、１つ以上のビデオフレームと関連付けられてもよく、１つ以上のビデオフレームに対するヘッダ内に組み込むことができ、アナログ伝送信号の一部であってもよく、または放送コンテンツが伝送される媒体に応じてデジタルデータの一部であってもよい。広告に応じて、ユーザは、広告に関係する双方向コンテンツを要求するために、リモートコントロール等のユーザ入力デバイス（図示せず）を使用してもよい。他の実施形態では、トリガは、自動的に双方向セッションを開始させ、コンテンツを受信するためのネットワークをマネージドおよびアンマネージドネットワークとの間で切り替わらせてもよい。それに応じて、クライアントデバイス２８０３は、衛星ネットワーク２８００から放送コンテンツ２８０５を受信することと、インターネット等のアンマネージドネットワーク２８０６を介してコンテンツを受信および伝送することを切り替える。クライアントデバイスは、マネージドネットワークから伝送を受信し、復号する単一のボックスを含んでもよく、また、アンマネージドネットワークとの２方向通信も含む。したがって、クライアントデバイスは、２つの別個の受信機と、少なくとも１つの伝送機とを含んでもよい。クライアントデバイスは、マネージドおよびアンマネージドネットワークの両方に対する単一の共有プロセッサを有してもよく、またはクライアントデバイス内に別個のプロセッサがあってもよい。ソフトウェアモジュールは、２つのネットワーク間の切替を制御する。

そのようにして、ソフトウェアモジュールは、両方のネットワークと通信する中心構成要素である。代替的実施形態では、別個のクライアント復号ボックスが、マネージドおよびアンマネージドネットワークに採用されてもよく、２つのボックスは、通信チャネルを含む。例えば、２つのボックスは、ＩＰまたはＵＤＰプロトコルを介して通信してもよく、第１のボックスは、割り込みを第２のボックスに送信するか、または出力抑制信号を送信してもよい。ボックスは、ポートがともに接続され、２つのボックス全てが接続を交渉するときを認識する発見エージェントが提供されてもよい。通信チャネルは、ボックスの出力が切り替えられてもよいように、２つのボックスが通信することを可能にする。したがって、各ボックスは、ボックスがコマンドを送信し、少なくとも他方のボックスの出力ポートを制御することを可能にする共通通信プロトコルを使用して動作する。衛星ベースのシステムに関する本実施形態の説明は、説明が目的にすぎず、説明は、マネージドおよびアンマネージドネットワークの両方を含む実施形態に容易に適用されてもよいことを認識されたい。

ユーザが伝送をクライアントデバイス２８０２に送信することによって双方向コンテンツを要求すると、クライアントデバイス２８０２は、トリガを抽出し、アンマネージドネットワークを介してトリガを処理オフィス２８１０に伝送する。処理オフィス２８１０は、参照テーブルの中の双方向コンテンツの関連インターネットアドレスを調べるか、またはクライアントデバイスからの受信された伝送からインターネットアドレスを抽出する。処理オフィスは、インターネット２８３０を介して要求を適切なコンテンツサーバ２８２０に転送する。双方向コンテンツは、処理オフィス２８１０に返信され、処理オフィス２８１０は、双方向コンテンツをクライアントデバイス２８０３と互換性がある形式に処理する。例えば、処理オフィス２８１０は、上記で論議されたように、ＭＰＥＧビデオストリームとしてコンテンツを拡大縮小し、ステッチすることによって、トランスコーディングを符号化する。次いで、一連のＩＰパケットとして、アンマネージドネットワーク２８０６上で処理オフィス２８１０からクライアントデバイス２８０３までビデオストリームを伝送することができる。そのような実施形態では、クライアントデバイス２８０２は、衛星デコーダと、また、アンマネージドＩＰネットワークを介して通信を送受信するためのポートとを含む。要求された双方向コンテンツがクライアントデバイス２８０３によって受信されると、クライアントデバイスは、衛星放送チャネルを出力することと、アンマネージドネットワークを介して受信される双方向コンテンツを出力することとを切り替えることができる。ある実施形態では、オーディオコンテンツは、衛星伝送によって受信され続けてもよく、ビデオのみが、衛星通信チャネルとＩＰ通信チャネルとの間で切り替えられる。衛星伝送からのオーディオチャネルは、アンマネージドＩＰネットワークを通して受信されるビデオと混合される。他の実施形態では、オーディオおよびビデオ信号の両方が、マネージドおよびアンマネージドネットワークの間で切り替えられる。

トリガは、広告に限定される必要はないが、他の形態の双方向コンテンツに関係してもよいことが、当業者によって認識されるべきである。例えば、放送伝送は、ユーザが、スポーツイベントをするチームの統計に関する双方向コンテンツを読み出すことを可能にする、スポートイベント中のトリガを含んでもよい。

いくつかの実施形態では、トリガが伝送内で識別されると、双方向セッションが自動的に確立され、２つ以上のソースからの双方向コンテンツが上記で説明されたようにともに合併される。次いで、双方向コンテンツは、通信ネットワークを通してクライアントデバイスに提供され、復号される。したがって、ユーザは、双方向セッションが確立される前に入力をクライアントデバイスに提供する必要がない。

ある実施形態では、クライアントデバイスは、マネージドおよびアンマネージドネットワークの両方からコンテンツを受信してもよく、一方からの情報を他方と置き換えてもよい。例えば、放送コンテンツは、広告のための識別可能な挿入点（例えば、時間コード、ヘッダ情報等）とともに、マネージドネットワーク上で伝送されてもよい。放送コンテンツは、挿入点に広告を含有してもよく、クライアントデバイスは、放送広告をマネージドネットワーク上で伝送された広告と置き換えることができ、クライアントデバイスは、広告の長さにわたってネージドおよびアンマネージドネットワークを切り替える。

図２９は、クライアントデバイス２９０２がマネージドネットワーク２９００を通して放送コンテンツを受信し、双方向コンテンツが要求されてもよく、アンマネージドネットワーク２９０１を通して提供される、別の環境を示す。この実施形態では、処理オフィス２９１０が、ケーブルシステム２９００を介して放送コンテンツを送達する。放送コンテンツは、複数の放送プログラムのうちの１つの選択を提供するセットトップボックス２９０２との相互作用に基づいて、ユーザによって選択可能である。放送プログラムのうちの１つ以上は、放送内（すなわち、放送と関連付けられるヘッダ内、デジタルデータ内、またはアナログ信号内）トリガを含む。クライアントデバイス２９１０が放送信号を受信し、選択された放送コンテンツを出力すると、クライアントデバイス２９０２上で作動するプログラムが、トリガを識別し、一時バッファにトリガを記憶する。放送プログラムが進行するにつれてトリガが変化する場合、クライアントデバイスがバッファを更新する。例えば、トリガは、時間的期限を有してもよい。トリガは、ビデオコンテンツからのビデオのいくつかのフレームと関連付けられてもよく、したがって、時間的に制限される。他の実施形態では、トリガは、処理オフィスに送信され、そこに記憶されてもよい。そのような実施形態では、各放送チャネルに対するトリガの１つだけのコピーが記憶される必要がある。

ユーザは、クライアントデバイス２９０２と通信するユーザ入力デバイス（すなわち、リモートコントロール）を使用して、双方向コンテンツを要求してもよい。例えば、クライアントデバイスは、セットトップボックス、メディアゲートウェイ、またはビデオゲームシステムであってもよい。クライアントデバイスが要求を受信すると、クライアントデバイスは、トリガを保持する一時バッファにアクセスすることによって、要求と関連付けられるトリガを識別する。トリガは単純に、アンマネージドネットワーク２９０１を通して処理オフィス２９１０へ上流に渡される識別子であってもよく、またはトリガは、ルーティング情報（すなわち、ＩＰアドレス）を含有してもよい。クライアントデバイス２９０２は、クライアントデバイスの識別子とともに、トリガを処理オフィスに伝送する。処理オフィス２９１０は、双方向コンテンツの要求を受信し、ＩＰアドレスの一覧を含有する参照テーブルにアクセスするためにトリガ識別子を使用し、または処理オフィスは、インターネット２９３０を通して、コンテンツサーバ２９２０に位置する双方向コンテンツのＩＰアドレスに要求を行う。クライアントデバイスと処理オフィスとの間に結合されるアンマネージドネットワークは、インターネットの一部と見なされてもよい。双方向コンテンツは、インターネット上のサーバから、またはコンテンツサーバから処理オフィスに送信される。処理オフィスは、双方向コンテンツをクライアントデバイスと互換性がある形式に処理する。双方向コンテンツは、ＭＰＥＧビデオストリームに変換され、複数のＩＰパケットとして処理オフィスからクライアントデバイスへ下流に送信されてもよい。ＭＰＥＧビデオストリームは、ＭＰＥＧ準拠であり、標準ＭＰＥＧデコーダによって容易に復号可能である。双方向コンテンツは、１つ以上のソースに由来してもよく、コンテンツは、一連のビデオフレームを形成するように、再フォーマットされ、拡大縮小され、一緒にステッチされてもよい。双方向コンテンツは、双方向コンテンツを構成する１つ以上のビデオフレームの中に、静的要素、動的要素、ならびに静的および動的要素の両方を含んでもよい。クライアントデバイス２９０２が双方向コンテンツを受信すると、クライアントデバイスは即時に、マネージドネットワークから受信されている放送コンテンツから、アンマネージドネットワークから双方向コンテンツを受信することに切り替わってもよい。代替として、クライアントデバイス２９０２は、トリガによって定義される所与の遅延後に、アンマネージドネットワークから双方向コンテンツを受信することに切り替わってもよい。クライアントデバイス２９０２は、受信された双方向コンテンツを復号し、ユーザは、双方向コンテンツと相互作用してもよく、処理オフィスは、クライアントデバイスからコンテンツの変更の要求を受信する。要求に応じて、処理オフィスは、コンテンツを読み出し、コンテンツをビデオストリームとして符号化し、アンマネージドネットワークを介してコンテンツをクライアントデバイスに送信する。

他の実施形態では、双方向セッションの要求を引き起こすトリガは、放送コンテンツの外部で生じてもよい。例えば、要求は、リモートコントロール等の入力デバイスとのユーザの相互作用に応じて起こってもよい。リモートコントロールによって生成される信号は、クライアントデバイスに送信され、クライアントデバイスは、マネージドネットワーク上で放送コンテンツを受信することと、アンマネージドネットワーク上で双方向セッションの要求を行うこととを切り替えることによって応答する。双方向セッションの要求は、通信ネットワーク上で処理オフィスに伝送される。処理オフィスはプロセッサを割り当て、接続がプロセッサとクライアントデバイスとの間で交渉される。クライアントデバイスは、セットトップボックス、メディアゲートウェイ、消費者電子デバイス、またはインターネット等のネットワークを通してリモートコントロール信号を伝送し、標準ＭＰＥＧ符号化ビデオストリームを受信し、復号することができる他のデバイスとなる場合がある。処理オフィスにあるプロセッサは、１つ以上のソースから双方向コンテンツを集める。例えば、ＭＰＥＧオブジェクトを含むＡＶＭＬテンプレートが使用されてもよく、ＭＰＥＧビデオコンテンツが、ローカルに記憶されたソースまたはネットワーク接続を通して到達可能であるソースから読み出されてもよい。例えば、ネットワークは、ＩＰネットワークであってもよく、ＭＰＥＧビデオコンテンツは、インターネット内のサーバ上に記憶されてもよい。割り当てられたプロセッサは、双方向コンテンツを一緒にステッチさせる。次いで、ステッチされたコンテンツは、ネットワーク接続を介して、復号し、復号されたコンテンツを表示デバイスに提示するクライアントデバイスに伝送される。

実施例として、内部または外部ＱＡＭチューナを含むテレビは、放送ケーブルテレビ信号を受信する。放送ケーブルテレビ信号は、１つ以上のトリガを含み、またはユーザが、要求信号を作成するために入力デバイスを使用する。テレビは、放送ケーブルテレビ信号の復号中にトリガを解析するか、または入力デバイスから要求を受信し、結果として、インターネット（アンマネージドネットワーク）に連結されるＩＰデバイスへ信号を生成させる。テレビは、ディスプレイへの放送ケーブルテレビ信号の出力を抑制する。ＩＰデバイスは、インターネット接続上に位置する処理オフィスとの双方向セッションを要求することによって、トリガまたは要求信号に応答する、別個の外部ボックスであってもよく、またはテレビの内部にあってもよい。プロセッサが処理オフィスによって割り当てられ、接続がＩＰデバイスと割り当てられたプロセッサとの間で交渉される。割り当てられたプロセッサは、２つ以上のソースから双方向コンテンツを生成し、ＭＰＥＧ基本ストリームを生じる。ＭＰＥＧ基本ストリームは、ＩＰデバイスに伝送される。次いで、ＩＰデバイスは、双方向コンテンツを復号し、テレビディスプレイに提示するテレビに、ＭＰＥＧ基本ストリームを出力する。入力デバイスとのユーザによるさらなる相互作用に応じて、基本ストリームへの更新は、割り当てられたプロセッサによって達成することができる。ユーザが放送テレビコンテンツに戻ることを決定するか、または双方向コンテンツが終了すると、テレビは、放送テレビコンテンツ信号の抑制を一時停止し、テレビは、放送テレビ信号を復号し、ディスプレイに提示する。したがって、システムは、トリガまたは要求信号の結果としてマネージドネットワークとアンマネージドネットワークとを切り替え、双方向コンテンツ信号は、テレビから遠隔の場所で２つ以上のソースから作成される。

先述の実施形態は、衛星およびケーブルテレビシステムに制限されず、実施形態は、電話システムを使用するＩＰＴＶネットワーク等のＩＰＴＶネットワークに等しく適用可能であってもよいことが、当業者によって認識されるべきである。そのような実施形態では、ＩＰＴＶネットワークは、マネージドネットワークとなり、アンマネージドネットワークは、インターネットへの接続となる（例えば、ＤＳＬモデム、無線インターネットネットワーク接続、イーサネット（登録商標）インターネット接続）。

（適応ビットレート検出および制御）
上記で説明された本発明の実施形態は、シンクライアントデバイスに関連して使用されてもよい。シンクライアントデバイスは、表示デバイス上に表示するための符号化されたオーディオおよびビデオを受信し、復号するため、ならびにキーストロークおよびボタンを押すコマンドを処理オフィスに伝送するためのハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組み合わせを含む。典型的には、シンクライアントは、大量生産のために安価となるように、および視聴覚コンテンツの基本的表示のみを可能にする状況で使用するために単純となるように設計されているが、他の機能を有する、より高価で複雑なデバイス（例えば、スマートフォン）が、本明細書で説明される方法およびシステムに従って採用されてもよい。

シンクライアント環境でのアンマネージドネットワークの使用は、双方向コンテンツを提供するテレビ放送局の能力を限定する制限を含む。エンドユーザ経験の質に最も影響を及ぼす制限は、アンマネージドネットワークが、クライアントデバイスと双方向サービスプロバイダとの間の利用可能なチャネル容量（帯域幅）の急速で予測不可能な変動を経験する場合があることである。この理由により、クライアントデバイスで最小のアルゴリズムの複雑性を使用しながら、最適なユーザ経験を提供するように、これらの変動を補う、システムおよび方法を提供することが望ましい。

これらの制限は、クライアントおよびサーバの両方で適応ビットレート制御を使用した対処されてもよい。概して、アンマネージドネットワーク上でクライアントデバイスと接続される双方向サービスプロバイダは、接続帯域幅の定期的な測定を行う。この帯域幅の変化が生じると、サーバは、サービスの伝送ビットレートを変化させる。クライアントデバイスは、受信された双方向サービスデータ内で提供されたデータを使用して、対応する帯域幅の測定を行い、それに従って、その視聴覚出力を調整する。したがって、双方向サービスの質は、アンマネージドネットワークの可変伝送能力に従って、最適なユーザ経験を維持するように動的に向上または低下させられてもよい。伝送能力が、特定の双方向サービスに対する最適なユーザ経験を防止するように限定される場合、双方向サービスプロバイダは、「サービス利用不可能」というメッセージを提供するか、あるいはユーザのアカウント情報または選好を反映するビジネスルールに従って、ユーザが使用することを希望し得る代替的なサービスを提案してもよい。

本発明の例示的実施形態によれば、適応ビットレート制御は、一定のオーディオビットレートを保つ、視聴覚サービスのビデオ部分上で提供される。そのようなアプローチは、いくつかの利点を有する。第１の固定オーディオビットレートは、アンマネージドネットワークさえも使用して、エンドユーザ視聴覚経験の少なくとも一部分の一貫した質を保証する。固定オーディオビットレートの第２の伝送では、サービスとのユーザ双方向性中に、最小の情報がクライアントに伝達されなければならない。第３に、クライアントデバイスは、アンマネージドネットワークの実際の性能を動的に測定するように、受信されたオーディオデータに対して期待された固定オーディオビットレートを比較してもよい。第４に、視聴覚サービスのビデオ部分のみのビットレートを変化させることは、オーディオおよびビデオ部分の両方を別個に変化させるよりも少ない処理リソースをサービスプロバイダによって必要とする。これらの利点を具現化するために、適応ビットレート制御は、伝送された双方向サービスのビデオ構成要素を一緒にステッチするステッチャ（ステッチャ１１５、ステッチャ３４０、またはステッチャ１１４０Ａ等）によって提供される。この機能を提供するために、双方向サービスの他の物理または論理構成要素が使用されてもよいことが、当業者によって理解されるであろう。

図３０は、ステッチャが適応ビットレート検出および制御を行う、本発明のサーバの実施形態を示す。ＭＰＥＧ符号化オーディオ３０１０およびビデオ３０１２が、システムに入力される。ステッチャにおいて、上記で詳細に説明されたようにビデオ３０１２がステッチされ、符号化される。ステッチャにおける符号化過程は、画像データ量子化および１秒当たりのフレームの数（フレームレート）等の、ビデオストリームの最終的なビットレートに影響を及ぼすある符号化パラメータを利用する。符号化ビットレートコントローラ３０２０は、エンドユーザ経験を最適化するように、以下で説明される過程を介して取得される利用可能な帯域幅に従って、これらのパラメータを変化させる。いったんビデオが最適なパラメータを使用して符号化されると、ハードウェアまたはソフトウェア輸送マルチプレクサ３０３０においてオーディオ３０１０と組み合わされ、それにより、本発明のクライアントデバイスの実施形態によって復号されることが可能な視聴覚データストリームを形成する。ストリームは、伝送のために伝送コントローラ３０４０に送信される。伝送コントローラ３０４０は、示されるように、アンマネージドネットワーク３０６０を使用して、視聴覚データをクライアントデバイスに伝送するために、ＴＣＰ等の信頼性の高い伝送プロトコル３０５０を使用する。伝送コントローラ３０４０はまた、伝送プロトコル３０５０から、現在の帯域幅利用を計算することを可能にする伝送に関するデータΔを取得する。次いで、この帯域幅は、最適なビデオ符号化パラメータの計算への入力として、矢印３０７０によって示されるように、符号化ビットレートコントローラ３０２０に提供される。

伝送コントローラ３０４０は、視聴覚ストリームの伝送に関するデータΔおよび時間の関数として帯域幅を計算する。したがって、帯域幅は、式Ｆ（Δ，ｔ）によって求められる。信頼性の高い伝送プロトコルを使用する一実施形態では、送信されるデータは、再伝送が必要である場合にバッファに格納される。データが伝送コントローラ３０４０によってバッファに追加され、伝送プロトコルによってバッファから除去されるとき、バッファの中のデータの量が変化する。式として、ｂｕｆ（ｔ）が所与の時間ｔにおけるバッファのサイズである場合には、ｂｕｆ（ｔ_２）＝ｂｕｆ（ｔ_１）＋ｎｅｗ（ｔ_１，ｔ_２）−ｔｒａｎｓ（ｔ_１，ｔ_２）であり、式中、ｎｅｗ（ｔ_１，ｔ_２）は、時間ｔ_１、ｔ_２の間にバッファに追加されるデータの量であり、ｔｒａｎｓ（ｔ_１，ｔ_２）は、時間ｔ_１、ｔ_２の間にクライアントデバイスに伝送されるデータの量である。帯域幅が単位時間当たりのクライアントデバイスに伝送されるデータの量であることに留意すると、これを再編成して、帯域幅の式、Ｆ（Δ，ｔ）＝ｔｒａｎｓ（ｔ_１，ｔ_２）／（ｔ_２−ｔ_１）＝（ｎｅｗ（ｔ_１，ｔ_２）−Δ）／（ｔ_２−ｔ_１）が得られ得、式中、Δ＝ｂｕｆ（ｔ_２）−ｂｕｆ（ｔ_１）は、バッファのサイズの変化である。上述のように、Δの値は、伝送プロトコル３０５０から得られてもよい。（ｔ_１，ｔ_２）の値は、伝送コントローラ３０４０によって監視されてもよく、それにより、Δの連続標本値から帯域幅を計算するために必要な情報の全てを提供する。伝送コントローラ３０４０は、同期的または非同期的に、帯域幅値Ｆ（Δ，ｔ）を符号化ビットレートコントローラ３０２０に提供する。

符号化ビットレートコントローラ３０２０は、伝送コントローラ３０４０によって提供される帯域幅値３０７０を使用する任意の適切なアルゴリズムによって、符号化パラメータを設定することができる。具体的には、増加した利用可能な帯域幅に応じて、ビデオフレームの全体的な量子化レベルが増加させられ得、帯域幅が減少すると、量子化が減少させられ得る。本発明の実施形態によるもののように、帯域幅が変化するにつれて経時的に変化する全体的な量子化レベルは、空間的に変化する量子化レベルと併せて有用であり得る。空間的に変化する量子化の一実施例は、人間の視覚系および全体的な量子化レベルに基づいて、単一のビデオフレーム内の個々のマクロブロックの最適化された量子化値を決定することを教示する米国特許６，８３１，９４７号に開示されている。符号化ビットレートコントローラ３０２０はまた、ビデオデータに対する変化するチャネル容量に対応するように、ビデオフレームレートを変更してもよい。したがって、帯域幅が半分だけ減少した場合、符号化ビットレートコントローラ３０２０は、半分だけの数のビデオフレームが伝送されるように、フレームレートを半分だけ低減してもよい。代替として、符号化ビットレートコントローラ３０２０は、例えば、利用可能な帯域幅が減少するにつれて、Ｂフレームを選択的にドロップするか、またはＩフレームの伝送を遅延させ、帯域幅が増加するにつれてそれらを修復することによって、符号化されるフレームの種類を変更してもよい。

さらに、符号化ビットレートコントローラ３０２０は、帯域幅Ｆ（Δ，ｔ）の実際の値だけでなく、その時間導関数にも基づいて、符号化パラメータを変更してもよい。当技術分野で周知であるように、導関数は、そのパラメータのうちの１つに関する関数の瞬間変化率であり、時間に関する関数の導関数は、関数の将来の挙動を予測するために使用することができる。この場合、帯域幅の時間関数は、将来の帯域幅値を予測するために使用されてもよい。したがって、例えば、負の第１の時間関数Ｆ’（ｔ）が、利用可能な帯域幅が減少していることを示す一方で、正の第２の時間関数Ｆ”（ｔ）は、減少傾向が逆転させられていることを示す。いくつかの実施形態では、符号化ビットレートコントローラ３０２０は、テイラー多項式等の当技術分野で周知の方法に従って、何らかの計算限界まで過去の帯域幅値に最良に適合する曲線の式を形成するために、帯域幅関数の時間導関数を使用する。時間において前方へ近似曲線を辿ることによって、将来の帯域幅値が予測され、符号化ビットレートコントローラ３０２０は、最適な符号化パラメータを決定するために、この予測情報を使用してもよい。したがって、利用可能な帯域幅が増加している場合、符号化ビットレートコントローラは、そうでなければ未加工の帯域幅値のみを監視することによって示されている場合がある将来のより高い符号化ビットレートを示すテイラー多項式を計算してもよい。選択されたビットレートが先制的に増加させられる量は、それ自体が、近似曲線の二次導関数によって示されるように、帯域幅傾向が逆転しているか加速しているかに基づいてもよい。

図３０Ａは、前述のような過程を行うためのフローチャートを示す。シーケンスは、サーバが、マネージドネットワークからの放送された非双方向視聴覚データの受信を、アンマネージドネットワークからの双方向視聴覚データの受信に切り替えるようにクライアント復号デバイスに命令する過程３００２Ａで始まる。別の過程（図示せず）では、クライアントデバイスが、このコマンドを受信し、受信を切り替える。ほぼ同時に、または切替の直前に、クライアントがサーバからコンテンツを受信するために必要以上の遅延を経験しないように、クライアントデバイスは、アンマネージドネットワークを使用して、双方向コンテンツの要求をサーバに送信する。過程３０１０Ａでは、サーバは、クライアントデバイスから双方向コンテンツの要求を受信する。それに応じて、サーバは、過程３０２０Ａで、ビデオ符号化ビットレートに従って複数のビデオフレームを符号化する。サイクルの始めに、サーバは、デフォルトビットレート、または当技術分野で公知の他の手段を介して決定されるビットレートを使用してもよいが、以降の符号化過程は、実際の測定された帯域幅を使用する。いったんビデオフレームが符号化されると、それらは、過程３０３０Ａにおいて、アンマネージドネットワーク上でクライアントデバイスに伝送される。最初の符号化されたビデオフレームは、受信切替え後に必要以上の遅延を伴わずにクライアントデバイスに着信し、前述のように、伝送は、ＴＣＰ等の信頼性の高い伝送プロトコルを使用する。過程３０４０Ａでは、サーバは、双方向サービスの一部として符号化する付加的なビデオフレームがあるか否かを決定する。例えば、加入者が別のチャネルにナビゲートすること、または双方向セッションが双方向モードで使用するために利用可能な視聴覚材料の終了に達することにより、あるいは別の理由により、双方向サービスが終了させられた場合、シーケンスは、ブロック３０４２Ａによって示されるように終了する。そうでなければ、シーケンスは、伝送プロトコルから取得されたデータを使用して、サーバが伝送帯域幅を決定する過程３０５０Ａで継続する。これらのデータは、伝送バッファに記憶されたデータの量を含む。いったん伝送帯域幅が分かると、過程３０６０Ａにおいて、サーバは、クライアントデバイス上の視聴覚提示の視聴経験を最適化するように、ビデオ符号化ビットレートを調整する。次いで、この新しいビデオ符号化ビットレートは、示されるように、フィードバックループにおいてさらに複数のビデオフレームを符号化するために使用される。サイクルは、双方向サービスが終了させられるまで継続する。

多重化視聴覚データストリームからオーディオおよびビデオを取得するためのクライアント過程は、クライアントデバイスが、オーディオおよび／またはビデオ再生をシミュレートすることによって適応待ち時間制御を行う、本発明の好ましい実施形態を示す図３１を参照して説明される。そのようなシミュレーションは、視聴覚データがエンドユーザに実際に提示される前に適切なエンドユーザ経験を決定する。シミュレーションは、例えば、時間単位当たりに受信されたオーディオフレームの数を数え、このカウントを、所与のオーディオビットレートに対して受信されることが見込まれるフレームの数と比較することによって行われてもよい。図３２の代替的実施形態では、再生は、エンドユーザによって聞かれる復号されたオーディオの実際のビットレートに基づいて調整される。この場合、再生のシミュレーションは必要ではないが、オーディオおよびビデオデータが出力される速度に行われる調整は、両方の実施形態で同様の計算によって行われてもよい。

図３１に示されるクライアント復号デバイスにおいて、視聴覚データは、伝送プロトコル３１２０においてアンマネージドネットワーク３１１０から受信される。クライアント伝送プロトコル３１２０は、サーバ伝送プロトコル３０５０を補完し、例えば、サーバ伝送プロトコル３０５０がＴＣＰサーバである場合、クライアント伝送プロトコル３１２０は、ＴＣＰクライアントである。いったんデータが受信されると、オーディオおよびビデオデータは、ハードウェアまたはソフトウェア輸送デマルチプレクサ３１３０によって分離される。例示的実施形態のオーディオデータが、図の上の経路を辿る一方で、ビデオデータは、下の経路を辿り、異なるように処理される。具体的には、オーディオデータは、クライアントデバイスがオーディオおよびビデオ出力の両方を制御するために使用する実際の伝送ビットレートを決定するように分析される。

オーディオデータは、符号化されたオーディオデータを抽出するオーディオストリームパーサ３１４０に提供される。これらの符号化されたオーディオデータは、クライアントデバイスが一定の速度で出力オーディオデータを提供することを可能にするオーディオバッファ３１５０に記憶される。同様に、ビデオデータは、ビデオストリームパーサ３１４２に提供され、解析された符号化ビデオデータは、ビデオバッファ３１５２に記憶される。この実施形態では、再生シミュレーション速度コントローラ３１６０が、矢印３１６２、３１６４によって示されるように、符号化されたオーディオ出力３１７０および符号化されたビデオ出力３１７２を制御する。再生シミュレーション速度コントローラ３１６０はまた、いくつかの実施形態では、その中の水平矢印によって示されるように、オーディオバッファ３１５０のサイズを制御してもよい。次いで、符号化されたオーディオ３１７０および符号化されたビデオ３１７２は、表示デバイスによる出力のためにアナログオーディオおよびビデオを生成するオーディオおよびビデオでコーダに提示される。

再生シミュレーション速度コントローラ３１６０は、データがスピーカまたはディスプレイ上に実際にレンダリングされることを要求せずに、実デバイス上でオーディオおよび／またはビデオの再生をシミュレートする。再生シミュレーション速度コントローラ３１６０は、上記で説明された伝送バッファの中のデータの監視を並行させる方式で、オーディオバッファ３１５０の中のオーディオフレームの数を監視することによって、この機能を達成する。バッファの中のオーディオフレームの数を時間の関数として決定することによって、再生シミュレーション速度コントローラ３１６０は、オーディオデータが受信されている帯域幅を決定することができる。これを期待されたオーディオ帯域幅に対して比較することによって、速度コントローラ３１６０は、オーディオおよびビデオ再生をシミュレートし、必要に応じてオーディオバッファのサイズを増大または減少させて、ユーザ経験の質を減少させるバッファリング遅延を回避することができる。さらに、速度コントローラ３１６０は、バッファ３１５０、３１５２の出力を同期化する方法を決定するために、動的シミュレーションを使用することができる。例えば、ビデオフレームは、楽しめるユーザ経験を提供するために、オーディオフレームに同期化されなければならない。シミュレーションを慎重に監視することによって、速度コントローラ３１６０は、同期化を確保するように、オーディオデータおよびビデオデータが同時に出力されることを保証する。速度コントローラ３１６０が伝送プロトコル３１２０と相互作用しないため、それぞれは、潜在的な製造上の利点およびクライアントデバイス設計の単純性を提供するハードウェアを含む独立型機能モジュールとして具現化されてもよい。

図３２は、適応待ち時間制御を行うための代替的なクライアントの実施形態を示す。この実施形態では、クライアントデバイスは、オーディオおよびビデオ処理の後半段階で帯域幅監視を行う。この後半段階において、実際のオーディオおよびビデオ出力が監視されてもよく、シミュレーションは必要ではない。したがって、バッファに符号化されたオーディオおよびビデオデータを記憶するよりもむしろ、これらのデータは、バッファ３２２０、３２２２２の中に格納される前に、それぞれ、オーディオデコーダ３２１０およびビデオデコーダ３２１２においてさらに復号される。上記で詳細に説明されたことと同様に、この実施形態では、再生速度コントローラ３２３０が、オーディオバッファ３２２０の中の復号されたオーディオデータの質を監視し、そのサイズ、ならびにオーディオおよびビデオバッファのサイズおよび出力を制御する。これらの出力、すなわち、復号されたオーディオ３２４０および復号されたビデオ３２４２は、ユーザが視聴するようにクライアント表示デバイスに直接提示される。

種々の修正が、図３０−３２に関連して上記で説明された基本クライアント／サーバシステムに行われてもよい。図３３は、１つ以上のビジネスルールに従ってサービスの選択を提供するために、ビットレート検出から集められたデータが使用されるサーバの実施形態を示す。この実施形態では、フレームアセンブリコントローラ３３１０は、利用可能な帯域幅を使用して、アンマネージドネットワーク上で双方向サービスが提供されてもよいかどうかを決定し、その決定に基づいて、いくつかの双方向ビデオおよびオーディオソースから選択する。したがって、ステッチャは、いくつかの異なるビデオコンテンツソース３３１８Ａ、３３１８Ｂを使用して、ビデオフレーム組立ておよび符号化３３２０を制御するフレーム組立コントローラ３３１０を含む。次いで、組み立てられ、符号化されたビデオフレームは、前述の輸送マルチプレクサ３０３０において、選択されたオーディオコンテンツ３３３０と多重化され、残りの伝送経路は、図３０と同じである。前述のように、伝送コントローラ３０４０は、帯域幅Ｆ（Δ，ｔ）を計算し、符号化ビットレートコントローラ３０２０の機能を果たすフレーム組立コントローラ３３１０に、それ３３１２を提供する。

フレーム組立コントローラ３３１０は、ここで説明されるように、この実施形態において付加的な機能を果たす。フレーム組立コントローラ３３１０は、利用可能な帯域幅値を監視し、それらをビジネスルール３３１４に提供する。これらのビジネスルールは、現在利用可能な帯域幅が、選択された双方向サービスをクライアントデバイスに提供するために十分であるか否かを決定する。この決定に基づいて、ビジネスルール３３１４は、記憶ネットワーク３３１６を使用して、適切なビデオコンテンツ３３１８およびオーディオコンテンツ３３３０にアクセスする。

ビジネスルール３３１４は、典型的には、コンピュータプロセッサに対する一組の命令において具現化され、当技術分野で公知の技法を使用して実装されてもよい。ビジネスルール３３１４は、クライアントデバイス識別子、加入者識別子、加入者によって支払われたサービスのレベル、双方向コンテンツにアクセスしている加入者の現在の数、特定の加入者分類または地理的グループ化の中の全ての加入者に提供されている双方向サービスの帯域幅、記憶ネットワーク３３１６内のオーディオおよびビデオコンテンツの可用性、コンテンツ製作者によって決定されるような同コンテンツの最初の公開日、または、現在の帯域幅値を考慮して、どの双方向サービスが要求クライアントデバイスに提供されてもよいかという決定で使用されてもよい任意の他の関連データ等の情報を含んでもよい。命令は、これらのデータに作用して、利用可能な双方向サービスのリストを生成し、次いで、そのオーディオおよびビデオコンテンツは、示されるように、フレーム組立および符号化３３２０および輸送マルチプレクサ３３３０に提供される。最小帯域幅要件が、そうでなければ加入者またはクライアントデバイスに利用可能な双方向サービスについて満たされない場合、ビジネスルール３３１４は、アンマネージドネットワーク上で、「サービス利用不可能」コンテンツをクライアントデバイスに伝送させてもよい。最小帯域幅要件が、現在提供されている双方向サービスについて満たされないが、要件が異なる双方向サービスについて満たされる場合、ビジネスルール３３１４は、クライアントデバイスへの伝送のために代替的なサービスを選択してもよく、またはクライアントデバイスに、最小要件が満たされている異なる双方向サービスのメニューを表示させてもよい。加入者がメニューの中のオプションを選択した後、フレーム組立コントローラ３３１０は、適切なビデオコンテンツ３３１８およびオーディオコンテンツ３３３０を符号化させ、クライアントデバイスに伝送させる。

本発明は、プロセッサ（例えば、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、または汎用コンピュータ）によって使用するためのコンピュータプログラム論理、プログラム可能論理デバイス（例えば、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）または他のＰＬＤ）によって使用するためのプログラム可能論理、離散構成要素、集積回路（例えば、特定用途向け集積回路（ＡＳＩＣ））、またはそれらの任意の組み合わせを含む任意の他の手段を含むが、決してそれらに限定されない多くの異なる形態で具現化されてもよい。本発明の実施形態では、記憶論理の全ては主に、コンピュータ実行可能形式に変換され、コンピュータ可読媒体等に記憶され、オペレーティングシステムの制御下でアレイ内のマイクロプロセッサによって実行される一組のコンピュータプログラム命令として実装されてもよい。

本明細書で以前に説明されている機能性の全体または一部を実装するコンピュータプログラム論理は、ソースコード形態、コンピュータ実行可能形態、および種々の中間形態（例えば、アセンブラ、コンパイラ、ネットワーカ、またはロケータによって生成される形態）を含むが、決してそれらに限定されない種々の形態で具現化されてもよい。ソースコードは、種々のオペレーティングシステムまたはオペレーティング環境とともに使用するための種々のプログラミング言語（例えば、オブジェクトコード、アセンブリ言語、またはＦＯＲＴＲＡＮ、Ｃ、Ｃ＋＋、ＪＡＶＡ（登録商標）、あるいはＨＴＭＬ等の高レベル言語）のうちのいずれかで実装される一連のコンピュータプログラム命令を含んでもよい。ソースコードは、種々のデータ構造および通信メッセージを定義し、使用してもよい。ソースコードは、（例えば、インタープリタを介した）コンピュータ実行可能形態でであってもよく、またはソースコードは、（例えば、翻訳装置、アセンブラ、またはコンパイラを介して）コンピュータ実行可能形態に変換されてもよい。

コンピュータプログラムは、半導体メモリデバイス（例えば、ＲＡＭ、ＲＯＭ、ＰＲＯＭ、ＥＥＰＲＯＭ、またはフラッシュプログラマブルＲＡＭ）、磁気メモリデバイス（例えば、ディスケットまたは固定ディスク）、光学メモリデバイス（例えば、ＣＤ−ＲＯＭ）、ＰＣカード（例えば、ＰＣＭＣＩＡカード）、または他のメモリデバイス等の、有形記憶媒体の中で永久的または一時的に、任意の形態（例えば、ソースコード形態、コンピュータ実行可能形態、または中間形態）で固定されてもよい。コンピュータプログラムは、アナログ技術、デジタル技術、光学技術、無線技術、ネットワーキング技術、およびインターネットワーキング技術を含むが、決してそれらに限定されない、種々の通信技術のうちのいずれかを使用してコンピュータに伝送可能である信号の中で、任意の形態で固定されてもよい。コンピュータプログラムは、添付印刷または電子文書（例えば、収縮包装されたソフトウェアまたは磁気テープ）を伴う可撤性記憶媒体として任意の形態で配信され、（例えば、システムＲＯＭまたは固定ディスク上で）コンピュータシステムに事前搭載され、または通信システム（例えば、インターネットまたはワールドワイドウェブ）上でサーバまたは電子掲示板から配信されてもよい。

本明細書において以前に説明されている機能性の全体または一部を実装するハードウェア論理（プログラム可能論理デバイスとともに使用するためのプログラム可能論理を含む）は、従来の手動方法を使用して設計されてもよく、あるいは、コンピュータ支援設計（ＣＡＤ）、ハードウェア記述言語（例えば、ＶＨＤＬまたはＡＨＤＬ）、またはＰＬＤプログラミング言語（例えば、ＰＡＬＡＳＭ、ＡＢＥＬ、またはＣＵＰＬ）等の種々のツールを使用して、設計され、捕捉され、シミュレートされ、または電子的に文書化されてもよい。

本発明は、具体的実施形態を参照して具体的に示され、説明されているが、添付条項によって定義されるような本発明の精神および範囲から逸脱することなく、形態および詳細の種々の変更が行われてもよいことが、当業者によって理解されるであろう。当業者に明白となるように、パノラマについて上記で説明された技法は、非パノラマ画像として捕捉されている画像にも適用されてもよく、逆もまた同様である。

本発明の実施形態は、以下の節によって限定することなく説明され得る。これらの実施形態は、この節において過程ステップによって説明されているが、以下の節における過程ステップを実行することが可能な関連ディスプレイを有するコンピュータを備える装置も、本発明に含まれる。同様に、以下の節における過程ステップを実行するためのコンピュータ実行可能命令を含み、コンピュータ可読媒体上に記憶されるコンピュータプログラム製品が、本発明の中に含まれる。

Claims (30)

1. ビデオ構成要素とオーディオ構成要素とを有する双方向コンテンツの信頼性の高い伝送をアンマネージドネットワーク上でユーザと関連付けられるクライアント復号デバイスまで提供する方法であって、該クライアント復号デバイスは、マネージドネットワーク上で放送ビデオコンテンツを受信し、および表示デバイスに出力するために該放送ビデオコンテンツと該双方向コンテンツとの間で切り替えることが可能であり、該方法は、
   該放送ビデオコンテンツを該マネージドネットワーク上で該クライアント復号デバイスまで伝送することと、
   該双方向コンテンツを該アンマネージドネットワーク上で該クライアント復号デバイスまで提供する要求を受信することと、
   ビデオ符号化ビットレートに従って該双方向ビデオコンテンツの第１の複数のフレームを符号化することであって、それにより、符号化された双方向コンテンツの第１の部分を形成する、ことと、
   信頼性の高いデータ伝送プロトコルを使用して、該符号化された双方向コンテンツの第１の部分を該アンマネージドネットワーク上で該クライアント復号デバイスまで伝送することと、
   該アンマネージドネットワーク上での該第１の部分の伝送帯域幅を決定することと、
   該伝送帯域幅に従って該ビデオ符号化ビットレートを調整することと、
   該ビデオ構成要素に対する該調整されたビデオ符号化ビットレート、および該オーディオ構成要素に対する調整されていないオーディオ符号化ビットレートに従って、該双方向コンテンツの第２の部分を符号化することであって、それにより、該符号化された双方向コンテンツの第２の部分を形成する、ことと、
   該信頼性の高いデータ伝送プロトコルを使用して、該符号化された双方向コンテンツの第２の部分を該アンマネージドネットワーク上で該クライアント復号デバイスまで伝送することと
   を含む、方法。
2. 前記アンマネージドネットワークは、インターネットの少なくとも一部分を含む、請求項１に記載の方法。
3. 前記マネージドネットワークは、衛星ネットワーク、ケーブルテレビネットワーク、またはＩＰテレビネットワークを含む、請求項１に記載の方法。
4. 前記アンマネージドネットワークと前記マネージドネットワークとは、単一の通信リンク上で動作する、請求項１に記載の方法。
5. 前記双方向コンテンツを符号化することは、ＭＰＥＧ規格に従って符号化することを含む、請求項１に記載の方法。
6. 前記信頼性の高いデータ伝送プロトコルは、ＴＣＰを含む、請求項１に記載の方法。
7. 前記伝送帯域幅を決定することは、伝送バッファの中のデータの数量を時間の関数として決定することを含む、請求項１に記載の方法。
8. 前記ビデオ符号化ビットレートを調整することは、該ビデオ符号化ビットレートを前記決定された伝送帯域幅に従って比例的に調整することを含む、請求項１に記載の方法。
9. 前記ビデオ符号化ビットレートを調整することは、該ビデオ符号化ビットレートを前記時間の関数として決定された伝送帯域幅の導関数に従って調整することを含む、請求項１に記載の方法。
10. 前記ビデオ符号化ビットレートを調整することは、ビデオフレームレートを調整すること、連続ビデオフレームに対してパターンの種類を選択すること、またはビデオデータ量子化値を調整することを含む、請求項１に記載の方法。
11. 前記クライアント復号デバイスは、前記符号化された双方向コンテンツの第２の部分が伝送された後に、自身の出力を前記放送ビデオコンテンツから前記双方向コンテンツまで切り替える、請求項１に記載の方法。
12. 前記決定された帯域幅が前記双方向コンテンツと関連付けられる最小帯域幅よりも小さくなるときに、前記信頼性の高いデータ伝送プロトコルを使用して、前記アンマネージドネットワーク上で、前記符号化された双方向コンテンツの代わりにサービス利用不可能コンテンツを前記クライアント復号デバイスまで伝送することをさらに含む、請求項１に記載の方法。
13. 複数の双方向サービスを含むリストを形成することであって、該リストの中の各双方向サービスは、最小帯域幅に従って双方向コンテンツを提供する、ことと、
    前記決定された帯域幅が該双方向コンテンツと関連付けられる最小帯域幅よりも小さくなるときに、ビジネスルールに従って双方向サービスを該リストから選択することと、
    前記信頼性の高いデータ伝送プロトコルを使用して、前記アンマネージドネットワーク上で、該選択された双方向サービスによって提供される符号化された双方向コンテンツを前記クライアント復号デバイスまで伝送することと
    をさらに含む、請求項１に記載の方法。
14. 前記ビジネスルールは、前記ユーザと関連付けられるユーザデータに関するルールを含み、前記双方向サービスを選択することは、該ユーザデータに従って選択することを含む、請求項１３に記載の方法。
15. 前記第１の複数のビデオフレームのうちの少なくとも１つのフレームは、複数のビデオソースから符号化された領域の中で一緒にステッチされる、請求項１に記載の方法。
16. ステッチャサーバ装置であって、該装置は、アンマネージドネットワーク上での、ユーザと関連付けられるクライアント復号デバイスまでのビデオ構成要素とオーディオ構成要素とを有する双方向コンテンツの信頼性の高い伝送を請求項１−１５のうちのいずれかに記載のステップに従って提供する、装置。
17. 有形のコンピュータ可読媒体を備えるコンピュータプログラム製品であって、該媒体には、ステッチャサーバ装置において請求項１−１５のうちのいずれかに記載のステップを実行するためのコンピュータ可読命令が含有されている、製品。
18. ユーザと関連付けられるクライアント復号デバイスにおいて、アンマネージドネットワーク上での双方向コンテンツの受信における変化する状態に適応する方法であって、該双方向コンテンツは、ビデオ構成要素とオーディオ構成要素とを有し、該方法は、
    ビデオディスプレイ上に表示するために、該クライアント復号デバイスにおいてマネージドネットワークから受信される放送ビデオコンテンツを出力することと、
    信頼性の高いデータ伝送プロトコルを使用して、該クライアント復号デバイスにおいて該アンマネージドネットワークから該双方向コンテンツを受信することであって、該双方向コンテンツが受信される受信帯域幅を決定することを含む、ことと、
    該受信された双方向コンテンツを該ビデオ構成要素および該オーディオ構成要素へと逆多重化することと、
    該受信帯域幅に基づく該オーディオ構成要素の再生を促進することと、
    該オーディオ構成要素および該ビデオ構成要素を該クライアント復号デバイスにおいて該促進に基づくビットレートで復号することと、
    該ビデオディスプレイ上に表示するために、該復号されたビデオ構成要素を出力することと
    を含む、方法。
19. 前記アンマネージドネットワークは、インターネットの少なくとも一部分を含む、請求項１８に記載の方法。
20. 前記マネージドネットワークは、衛星ネットワーク、ケーブルテレビネットワーク、またはＩＰテレビネットワークを含む、請求項１８に記載の方法。
21. 前記アンマネージドネットワークおよび前記マネージドネットワークは、単一の通信リンク上で動作する、請求項１８に記載の方法。
22. 前記双方向コンテンツを符号化することは、ＭＰＥＧ規格に従って符号化することを含む、請求項１８に記載の方法。
23. 前記信頼性の高いデータ伝送プロトコルは、ＴＣＰを含む、請求項１８に記載の方法。
24. 前記再生を促進することは、オーディオバッファの中のデータの数量を時間の関数として決定することを含む、請求項１８に記載の方法。
25. 前記復号ビットレートは、前記受信帯域幅に比例する、請求項１８に記載の方法。
26. オーディオバッファのサイズを前記受信帯域幅の関数として増加または減少させることをさらに含む、請求項１８に記載の方法。
27. 前記マネージドネットワーク上で前記クライアント復号デバイスにおいてトリガを受信することをさらに含み、該トリガは、該クライアント復号デバイスに、該アンマネージドネットワーク上で前記双方向コンテンツを要求させる、請求項１８に記載の方法。
28. ヘッドエンドにおいてトリガを受信することをさらに含み、該トリガは、該ヘッドエンドが前記アンマネージドネットワーク上での前記双方向コンテンツを要求するように前記クライアント復号デバイスに命令するようにさせる、請求項１８に記載の方法。
29. ユーザと関連付けられるクライアント復号デバイスであって、該デバイスは、アンマネージドネットワーク上での双方向コンテンツの受信における変化する状態に適応することが可能であり、ステッチャサーバ装置からマネージドネットワーク上で放送ビデオコンテンツを受信し、および請求項１８−２８のうちのいずれかに記載のステップを行うように構成される、デバイス。
30. 有形のコンピュータ可読媒体を備えるコンピュータプログラム製品であって、該媒体には、請求項１８−２８のうちのいずれかに記載のステップをクライアント復号デバイス上で実行するためのコンピュータ可読命令が含有されている、製品。

Images