【文献】
今泉浩幸(外4名),「ストリーミング放送における中継サーバ上での映像切替・合成制御方式」,情報処理学会第66回(平成16年)全国大会講演論文集(5),日本,社団法人情報処理学会,2004年 3月 9日,第5-101〜5-104頁
(58)【調査した分野】(Int.Cl.,DB名)
クライアントデバイスに圧縮映像コンテンツとして送信される映像コンテンツとの双方向性を可能にするシステムであって、前記圧縮映像コンテンツは、複数の合成映像フレームを含み、
前記システムは、
前記クライアントデバイスから離れて配置され、前記クライアントデバイスとの双方向セッションを制御し、前記圧縮映像コンテンツに含まれる第1の圧縮グラフィカル要素についての状態情報を保持するためのプロセッサと、
前記プロセッサに応答して、周波数ドメインにおいて、少なくとも前記第1の圧縮グラフィカル要素と第2の圧縮グラフィカル要素を共にステッチングして新たな圧縮映像フレームを形成するステッチャと、を備え、
前記状態情報は、前記第1の圧縮グラフィカル要素の状態を含み、前記状態は、前記第1圧縮グラフィカル要素に関して行われたユーザ入力操作に関連付けられ、
前記プロセッサが、前記第1の圧縮グラフィカル要素の状態における変化を要求する信号を受信した場合に、前記プロセッサは、前記第1の圧縮グラフィカル要素の状態変化を示す新たな圧縮グラフィカル要素を取得し、前記ステッチャは、前記周波数ドメインにおいて、前記新たな圧縮グラフィカル要素を前記第2の圧縮グラフィカル要素にステッチすることにより、前記クライアントデバイスに送信される新たな圧縮映像コンテンツを定義する新たな合成映像フレームを形成することを特徴とする、システム。
【発明を実施するための形態】
【0011】
(特定の実施形態の詳細な説明)
以下の詳細な説明および添付の特許請求の範囲において使用されるように、用語「領域」は、連続状または非連続状であるMPEG(Motion Picture Expert Group)スライスの論理グループ化を意味するものとする。用語「MPEG」が使用される場合、MPEG−2およびMPEG−4を含む、MPEG規格のあらゆる変形例を指すものとする。以下の実施形態に説明されるような本発明は、双方向MPEGコンテンツの環境と、処理局とテレビ等の関連付けられたディスプレイを有するクライアントデバイスとの間の通信とを提供する。本発明は、MPEG仕様および符号化を詳細に参照するが、本発明の原理は、ブロックベースの変換に基づく他の符号化技術と併用されてもよい。以下の明細書および添付の特許請求の範囲において使用されるように、用語「符号化する」、「符号化される」、および「符号化」は、デジタルデータ信号を圧縮し、圧縮されたデジタルデータ信号をプロトコルまたは規格にフォーマットするプロセスを指すものとする。符号化映像データは、空間表現以外の任意の状態にあることが可能である。例えば、符号化映像データは、変換符号化、量子化、およびエントロピ符号化されるか、またはそれらの任意の組み合わせであってもよい。したがって、変換符号化されたデータは、符号化されているとみなされよう。
【0012】
本願は、テレビとして表示デバイスを指すが、表示デバイスは、携帯電話、パーソナルデジタルアシスタント(PDA)、またはディスプレイを含む他のデバイスであってもよい。MPEGコンテンツを復号化可能なセットトップボックス等の復号化デバイスを含むクライアントデバイスは、ユーザの表示デバイスと関連付けられる。ある実施形態では、デコーダは、表示デバイスの一部であってもよい。双方向MPEGコンテンツは、オーサリング環境内に生成され、アプリケーション設計者に、コンテンツプロバイダおよび一次放送局からの映像コンテンツを含む、種々の要素からの1つ以上の場面を有するアプリケーションを生成する双方向MPEGコンテンツを設計させる。アプリケーションファイルは、アクティブビデオマークアップ言語(AVML)で形成される。オーサリング環境によって生成されるAVMLファイルは、単一フレーム/ページ内の映像グラフィカル要素(すなわち、MPEGスライス)、映像グラフィカル要素のサイズ、各場面に対するページ/フレーム内の映像グラフィカル要素のレイアウト、映像グラフィカル要素へのリンク、および場面に対する任意のスクリプトを定義する、XMLベースのファイルである。ある実施形態では、AVMLファイルは、テキストエディタ内における作成またはオーサリング環境による生成とは対照的に、直接作成されてもよい。映像グラフィカル要素は、静的グラフィック、動的グラフィック、または映像コンテンツであってもよい。場面内の各要素は、実際には、画像のシーケンスであって、静的グラフィックは、繰り返し表示され、経時的に変化しない画像であることを認識されたい。要素はそれぞれ、グラフィックのためのMPEGデータおよびグラフィックと関連付けられた動作の両方を含むことが可能なMPEGオブジェクトであってもよい。双方向MPEGコンテンツは、ユーザが対話可能な場面内に複数の双方向MPEGオブジェクトを含むことが可能である。例えば、場面は、ボタンMPEGオブジェクトであって、そのオブジェクトに対する映像グラフィックを形成する符号化MPEGデータを提供するボタンMPEGオブジェクトを含んでもよく、また、ボタン状態を追跡するための手順を含んでもよい。MPEGオブジェクトは、スクリプトと協働して作用してもよい。例えば、MPEGボタンオブジェクトは、その状態(オン/オフ)を追跡し得る一方、場面内のスクリプトは、そのボタンが押下された際に何が生じるかを判定する。スクリプトは、映像コンテンツが再生または停止されているかどうかをボタンが示すように、ボタン状態を映像プログラムと関連付けてもよい。MPEGオブジェクトは、常にオブジェクトの一部として関連付けられたアクションを有する。ある実施形態では、ボタンMPEGオブジェクト等のMPEGオブジェクトは、ボタンの状態の追跡記録以上のアクションを行なってもよい。また、そのような実施形態では、MPEGオブジェクトは、外部プログラムに対する呼び出しを含んでもよく、MPEGオブジェクトは、ボタングラフィックが使用中となると、プログラムにアクセスする。したがって、再生/一時停止MPEGオブジェクトボタンの場合、MPEGオブジェクトは、ボタンの状態を追跡するコードを含んでもよく、状態変化に基づいてグラフィカルオーバーレイを提供し、および/または映像プレイヤオブジェクトに、ボタンの状態に応じて、映像コンテンツを再生もしくは一時停止させる。
【0013】
アプリケーションがオーサリング環境内に生成され、双方向セッションが要求クライアントデバイスによって要求されると、処理局は、双方向セッションのためのプロセッサを割り当てる。
【0014】
処理局において動作可能な割り当てられたプロセッサは、仮想マシンを起動し、要求されたアプリケーションにアクセスし、実行する。プロセッサは、MPEG形式での伝送のために、場面のグラフィカル部分を調製する。クライアントデバイスによるMPEG伝送の受信およびユーザのディスプレイ上での表示に応じて、ユーザは、クライアントデバイスと通信する入力デバイスを使用することによって、表示されたコンテンツと対話可能である。クライアントデバイスは、通信ネットワークを通して、処理局または他の遠隔場所において割り当てられたプロセッサ上で動作するアプリケーションに、ユーザからの入力要求を送信する。それに応答して、割り当てられたプロセッサは、MPEGオブジェクトの要求および状態(以下、総称して、アプリケーション状態と称される)に基づいて、グラフィカルレイアウトを更新する。新しい要素は、場面に追加されるか、または場面内で差し替えられるか、あるいは完全に新しい場面が生成されてもよい。割り当てられたプロセッサは、場面に対する要素およびオブジェクトを収集し、割り当てられたプロセッサまたは別のプロセッサのいずれかが、オブジェクト(単数または複数)に従って、データおよび動作を処理し、ユーザのテレビ上への表示のために送受信機に伝送される、MPEG形式における修正されたグラフィカル表現を生成する。上述の流れは、割り当てられたプロセッサが処理局に位置することを示すが、割り当てられたプロセッサは、遠隔場所に位置して、ネットワーク接続を通して、処理局との通信のみを必要としてもよい。同様に、割り当てられたプロセッサは、クライアントデバイスとのあらゆるトランザクションを扱うように説明されるが、また、他のプロセッサが、アプリケーションのためのグラフィカルレイアウトのコンテンツ(MPEGオブジェクト)の要求およびアセンブリに関与してもよい。
【0015】
図1は、本発明の一変形例を実装するための通信環境100を示すブロック図である。通信環境100は、アプリケーションプログラマに対して、エンドユーザとの2方向の双方向性のためのアプリケーションを作成可能にする。エンドユーザは、テレビ等のクライアントデバイス110上でアプリケーションを視聴し、アップストリームネットワーク120を通して、コマンドをアップストリームに送信することによって、コンテンツと対話可能であって、アップストリームおよびダウンストリームは、処理局へのリターンパスリンクを提供する、同一ネットワークまたは別個のネットワークの一部であってもよい。アプリケーションプログラマは、1つ以上の場面を含むアプリケーションを生成する。各場面は、HTMLウェブページと同等物であるが、場面内の各要素は、映像のシーケンスである点が異なる。アプリケーションプログラマは、場面のグラフィカル表現を設計し、音声および映像ファイル等の要素ならびにボタン等のオブジェクトへのリンクを組み込み、場面を制御する。アプリケーションプログラマは、グラフィカルオーサリングツール130を使用して、オブジェクトおよび要素をグラフィカルに選択する。オーサリング環境130は、アプリケーションプログラマに、映像オブジェクトを生成する要素と方法を関連付けさせる、グラフィカルインターフェースを含んでもよい。グラフィックは、MPEG符号化映像、グルーミングされたMPEG映像、静止画像、または別の形式における映像であってもよい。アプリケーションプログラマは、コンテンツプロバイダ160(ニュースソース、映画スタジオ、RSSフィード等)および一次放送ソース(放送メディアおよびケーブル、オンデマンド映像ソース、ならびにウェブベースの映像ソース)170を含むいくつかのソースからのコンテンツをアプリケーションに組み込み可能である。アプリケーションプログラマは、AVML(アクティブビデオマークアップ言語)におけるファイルとしてアプリケーションを生成し、映像コンテンツ配信ネットワーク150内のプロキシ/キャッシュ140にアプリケーションファイルを送信する。AVMLファイル形式は、XML形式である。例えば、サンプルのAVMLファイルを示す
図1Bを参照されたい。
【0016】
コンテンツプロバイダ160は、MPEG映像/音声として映像コンテンツを符号化してもよく、またはコンテンツは、別のグラフィカル形式(例えば、JPEG、BITMAP、H263、H264、VC−1等)であってもよい。続いて、コンテンツは、グルーマ/スケーラ190において、グルーミングおよび/またはスケーリングされ、ステッチングを可能にする好ましい符号化MPEG形式にコンテンツを配置してもよい。コンテンツが好ましいMPEG形式に配置されない場合、処理局は、コンテンツを要求するアプリケーションがクライアントデバイスによって要求されると、形式をグルーミングする。コンテンツプロバイダからのコンテンツ等、放送メディアサービスからの一次放送コンテンツ170は、グルーミングされるであろう。一次放送コンテンツは、好ましくは、コンテンツを処理局に転送する前に、ステッチングのために、好ましいMPEG形式にコンテンツを符号化するグルーマ/スケーラ180において、グルーミングおよび/またはスケーリングされる。
【0017】
コンテンツプロデューサ160からの映像コンテンツは、アプリケーションプログラマによって生成されるアプリケーションとともに、映像コンテンツ配信ネットワーク150を通して配信され、配信点140に保存される。これらの配信点は、
図1内のプロキシ/キャッシュとして表される。コンテンツプロバイダは、双方向処理局と併用するために、映像コンテンツ配信ネットワーク内のプロキシ/キャッシュ140位置にそのコンテンツを配置する。したがって、コンテンツプロバイダ160は、そのコンテンツを映像コンテンツ配信ネットワーク150のキャッシュ140に提供可能であって、本アーキテクチャを実装する1つ以上の処理局は、アプリケーションのために必要とされると、映像コンテンツ配信ネットワーク150を通して、コンテンツにアクセスしてもよい。映像コンテンツ配信ネットワーク150は、ローカルネットワーク、地域ネットワーク、またはグローバルネットワークであってもよい。したがって、処理局における仮想マシンがアプリケーションを要求すると、アプリケーションは、配信点のうちの1つから読み出されることが可能であって、アプリケーションのAVMLファイル内に定義されるようなコンテンツが、同一または異なる配信点から読み出されることが可能である。
【0018】
システムのエンドユーザは、セットトップボックス等のクライアントデバイス110を通して、処理局105にコマンドを送信することによって、双方向セッションを要求可能である。
図1では、単一の処理局のみが示される。しかしながら、実際のアプリケーションでは、異なる地域に位置する複数の処理局が存在してもよく、処理局はそれぞれ、
図1Bに示されるように、映像コンテンツ配信ネットワークと通信する。処理局105は、双方向セッションのために、エンドユーザのためのプロセッサを割り当てる。プロセッサは、あらゆるアドレッシングおよびリソースの割り当てを含むセッションを維持する。明細書および添付の特許請求の範囲において使用されるように、用語「仮想マシン」106は、割り当てられたプロセッサ同様に、処理局とクライアントデバイスとの間のセッション管理、およびリソースの割り当て(すなわち、双方向セッションのためのプロセッサの割り当て)等の機能を果たす、処理局における他のプロセッサを指すものとする。
【0019】
仮想マシン106は、そのアドレスをクライアントデバイス110に通信し、双方向セッションが確立される。次いで、ユーザは、クライアントデバイス110を通して、双方向アプリケーション(AVML)の提示を要求可能である。要求は、仮想マシン106によって受信され、それに応答して、仮想マシン106は、プロキシ/キャッシュ140からAVMLファイルを読み出し、仮想マシン106によってアクセス可能なメモリキャッシュ107内にインストールさせる。仮想マシン106は、複数のクライアントデバイス110と同時通信してもよく、クライアントデバイスは、異なるデバイスタイプであってもよいことを認識されたい。例えば、第1のデバイスは、携帯電話であってもよく、第2のデバイスは、セットトップボックスであってもよく、第3のデバイスは、パーソナルデジタルアシスタントであってもよく、ここで、各デバイスは、同一または異なるアプリケーションにアクセスする。
【0020】
アプリケーションに対する要求に応答して、仮想マシン106は、アプリケーションを処理し、場面の一部である要素およびMPEGオブジェクトをプロキシ/キャッシュから、仮想マシン106と関連付けられたメモリ107内へと移動させることを要求する。MPEGオブジェクトは、視覚的成分およびアクション可能な成分の両方を含む。視覚的成分は、1つ以上のMPEGスライスとして符号化されるか、または別のグラフィカル形式で提供されてもよい。アクション可能な成分は、オブジェクトの状態を保存していてもよく、計算を行なうか、関連付けられたプログラムにアクセスするか、またはオーバーレイグラフィックを表示してグラフィカル成分をアクティブとして識別することを含んでもよい。オーバーレイグラフィックは、クライアントデバイスに伝送される信号によって生成されてもよく、ここで、クライアントデバイスは、表示デバイス上のオーバーレイプレーン内にグラフィックを生成する。場面は、静的グラフィックではなく、むしろ、フレームのコンテンツが経時的に変化し得る複数の映像フレームを含むことを認識されたい。
【0021】
仮想マシン106は、アプリケーション状態を含む場面情報に基づいて、場面に対する種々の要素およびオブジェクトの、サイズおよび位置を判定する。各グラフィカル要素は、連続状または非連続状MPEGスライスから形成されてもよい。仮想マシンは、各グラフィカル要素に対するスライスのすべての位置を追跡する。グラフィカル要素を規定するスライスはすべて、領域を形成する。仮想マシン106は、各領域を追跡する。AVMLファイル内の表示位置情報に基づいて、映像フレーム内の要素および背景に対するスライス位置が設定される。グラフィカル要素が未だグルーミングされた形式にない場合、仮想マシンは、その要素を要素レンダラに転送する。レンダラは、グラフィカル要素をビットマップとしてレンダリングし、レンダラは、ビットマップをMPEG要素エンコーダ109に転送する。MPEG要素エンコーダは、ビットマップをMPEG映像シーケンスとして符号化する。MPEGエンコーダは、一連のP−フレームを出力するように、ビットマップを処理する。未だ事前符号化および事前グルーミングされていないコンテンツの実施例は、パーソナライズされたコンテンツである。例えば、ユーザが音楽ファイルを処理局に保存しており、提示されるグラフィック要素がユーザの音楽ファイルのリストである場合、本グラフィックは、仮想マシンによって、ビットマップとしてリアルタイムで生成されるであろう。仮想マシンは、ビットマップをレンダリングし、かつグルーミングのために、ビットマップをMPEG要素エンコーダ109に転送する、要素レンダラ108にビットマップを転送する。
【0022】
グラフィカル要素がMPEG要素エンコーダによってグルーミングされた後、MPEG要素エンコーダ109は、他のユーザによる他の双方向セッションのための仮想マシン106によるその後の読み出しのために、グラフィカル要素をメモリ107に転送する。また、MPEGエンコーダ109は、MPEG符号化グラフィカル要素をステッチャ115に転送する。要素のレンダリングおよび要素のMPEG符号化は、仮想マシン106と同一または別個のプロセッサ内で達成されてもよい。また、仮想マシン106は、アプリケーション内に解釈される必要がある何かしらのスクリプトが存在するかどうか判定する。スクリプトが存在する場合、スクリプトは、仮想マシン106によって解釈される。
【0023】
アプリケーション内の各場面は、静的グラフィック、ユーザ対話に基づいて変化するオブジェクトグラフィック、および映像コンテンツを含む、複数の要素を含むことが可能である。例えば、場面は、複数のボタンを有する音声映像およびマルチメディアコンテンツ(オブジェクトグラフィック)の再生のためのメディアプレイヤとともに、背景(静的グラフィック)、およびストリーミング映像コンテンツを表示するための映像コンテンツウインドウ(映像コンテンツ)を含んでもよい。メディアプレイヤの各ボタンそれ自体が、その独自の関連付けられた方法を含む、別個のオブジェクトグラフィックであってもよい。
【0024】
仮想マシン106は、フレームに対して、グラフィカル要素(背景、メディアプレイヤグラフィック、および映像フレーム)のそれぞれを取得し、各要素の位置を判定する。オブジェクトおよび要素(背景、映像コンテンツ)のすべてが取得されると、要素およびグラフィカルオブジェクトは、要素およびMPEGオブジェクトに対する位置付け情報とともに、ステッチャ/合成器115に転送される。ステッチャ115は、仮想マシン106によって提供されるマッピングに従って、要素(映像コンテンツ、ボタン、グラフィック、背景)のそれぞれをステッチングしてまとめる。要素はそれぞれ、マクロブロック境界上に配置され、ステッチングしてまとめられると、要素は、MPEG映像フレームを形成する。定期的に、シーケンスをレフレッシュし、欠落マクロブロックを回避するために、場面フレームの要素がすべて符号化され、参照P−フレームを形成する。次いで、MPEG映像ストリームは、ダウンストリームネットワークを通して、クライアントデバイスのアドレスに伝送される。プロセスは、映像フレームのそれぞれに対して継続する。本明細書は、符号化プロセスとしてMPEGを参照するが、また、他の符号化プロセスが、本システムと併用されてもよい。
【0025】
仮想マシン106、または他のプロセッサ、あるいは処理局105におけるプロセスは、要素のそれぞれおよび画面上の要素の位置に関する情報を維持する。また、仮想マシン106は、要素のそれぞれと関連付けられたオブジェクトに対する方法へのアクセスを有する。例えば、メディアプレイヤは、複数のルーチンを含む、メディアプレイヤオブジェクトを有してもよい。ルーチンは、再生、停止、早送り、巻き戻し、および一時停止を含むことが可能である。ルーチンはそれぞれ、コードを含み、ルーチンのうちの1つの起動のために、ユーザが要求を処理局105に送信すると、オブジェクトがアクセスされ、ルーチンが実行される。ルーチンは、JAVA(登録商標)ベースのアプレット、解釈されるスクリプト、または仮想マシンと関連付けられたオペレーティングシステム内で実行可能な別個のコンピュータプログラムであってもよい。
【0026】
また、処理局105は、テレビと関連付けられたクライアントデバイスからプロセッサによって受信された信号に基づいて実行または解釈するために、ルーチンを判定するためのリンクされたデータ構造を生成してもよい。リンクされたデータ構造は、内包のマッピングモジュールによって形成されてもよい。データ構造は、各リソースおよび関連付けられたオブジェクトを、それぞれ他のリソースおよびオブジェクトに対して関連付ける。例えば、ユーザが、既に再生コントロールを使用中である場合、メディアプレイヤオブジェクトが起動され、映像コンテンツが表示される。映像コンテンツがメディアプレイヤウインドウ内で再生されるのに伴って、ユーザは、ユーザの遠隔コントロール上の方向キーを押下可能である。本実施例では、方向キーの押下は、停止ボタンの押下を示す。送受信機は、方向信号を生成し、割り当てられたプロセッサは、方向信号を受信する。仮想マシン106または処理局105における他のプロセッサは、リンクされたデータ構造にアクセスし、方向キー押下の方向に要素の位置を特定する。データベースは、要素がメディアプレイヤオブジェクトの一部である停止ボタンであることを示し、プロセッサは、映像コンテンツを停止するためのルーチンを実行する。ルーチンは、要求されたコンテンツを停止させる。最後の映像コンテンツフレームは、静止され、押下された停止ボタングラフィックは、ステッチャモジュールによって、フレーム内に組み込まれる。また、ルーチンは、フォーカスグラフィックを含むことにより、停止ボタンの周囲にフォーカスを提供してもよい。例えば、仮想マシンは、ステッチャに、1マクロブロック幅の境界線で、フォーカスを有するグラフィックを内包させることが可能である。したがって、映像フレームが復号化および表示されると、ユーザは、ユーザが対話可能なグラフィック/オブジェクトを識別可能となる。次いで、フレームは、マルチプレクサに転送され、ダウンストリームネットワークを通して、クライアントデバイスに送信される。MPEG符号化映像フレームは、クライアントデバイス(携帯電話、PDA)または別個の表示デバイス(モニタ、テレビ)のいずれか上に表示されるクライアントデバイスによって復号化される。本プロセスは、最小の遅延を伴って生じる。このようにして、アプリケーションからの各場面は、複数の映像フレームをもたらし、それぞれ、メディアプレイヤアプリケーション状態のスナップショットを表す。
【0027】
仮想マシン106は、クライアントデバイスからコマンドを繰り返し受信し、コマンドに応答して、直接または間接的にオブジェクトにアクセスし、ユーザ対話およびアプリケーション対話モデルに応答して、オブジェクトのルーチンを実行または解釈する。そのようなシステムでは、ユーザのテレビ上に表示される映像コンテンツ題材は、単なる復号化されたMPEGコンテンツであって、双方向性のための処理はすべて、処理局において生じ、割り当てられた仮想マシンによって編成される。したがって、クライアントデバイスは、デコーダのみを必要とし、コンテンツのいずれかをキャッシュまたは処理する必要はない。
【0028】
クライアントデバイスからのユーザ要求を通して、処理局は、映像要素を別の映像要素と置換可能であることを認識されたい。例えば、ユーザは、映画のリストから選択して表示してもよく、したがって、ユーザが2つの映画間の切り替えを選択する場合、第1の映像コンテンツ要素は、第2の映像コンテンツ要素によって差し替えられる。各要素の位置、および要素を形成する領域の、リストを維持する仮想マシンは、場面内の要素を容易に置換し、新しいMPEG映像フレームを生成可能であって、フレームは、ステッチングしてまとめられ、ステッチャ115内の新しい要素を含む。
【0029】
図1Aは、デジタルコンテンツ配信ネットワーク100Aと、コンテンツプロバイダ110Aと、処理局120Aとの間の相互運用を示す。本実施例では、コンテンツプロバイダ130Aは、コンテンツを映像コンテンツ配信ネットワーク100Aに配信する。コンテンツプロバイダ130Aまたは映像コンテンツ配信ネットワークと関連付けられたプロセッサのいずれかが、処理局120Aの双方向MPEGコンテンツの生成と互換性のあるMPEG形式にコンテンツを変換する。デジタルコンテンツ配信ネットワーク100Aのコンテンツ管理サーバ140Aは、コンテンツが世界的/全国的範囲のものである場合、異なる領域に位置するプロキシ/キャッシュ150A−154A間にMPEG符号化コンテンツを配信する。コンテンツが地域的/ローカル的範囲のものである場合、コンテンツは、地域的/ローカル的プロキシ/キャッシュ内に常駐する。コンテンツは、アクセス回数を増加させるために、全国または全世界を通して異なる位置においてミラーリングされてもよい。エンドユーザが、そのクライアントデバイス160Aを通して、地域処理局からアプリケーションを要求すると、地域処理局は、要求されたアプリケーションにアクセスする。要求されたアプリケーションは、映像コンテンツ配信ネットワーク内に位置してもよく、あるいはアプリケーションは、地域処理局または相互接続された処理局のネットワーク内にローカルに常駐してもよい。アプリケーションが読み出されると、地域処理局において割り当てられた仮想マシンは、読み出される必要がある映像コンテンツを判定する。コンテンツ管理サーバ140Aは、仮想マシンが映像コンテンツ配信ネットワーク内のコンテンツの位置を特定する補助を行なう。コンテンツ管理サーバ140Aは、コンテンツが、地域またはローカルのプロキシ/キャッシュ上に位置するかどうか判定可能であり、また、最も近いプロキシ/キャッシュを特定可能である。例えば、アプリケーションは、広告を含んでもよく、コンテンツ管理サーバは、ローカルプロキシ/キャッシュから広告を読み出すように仮想マシンに指図する。また、
図1Aに示されるように、中西部および南東部の地域処理局120Aは両方とも、ローカルプロキシ/キャッシュ153A、154Aを有する。これらのプロキシ/キャッシュは、ローカルニュースおよびローカル広告を含有してもよい。したがって、南東部内のエンドユーザに提示される場面は、中西部内のエンドユーザへのものとは異なって現れてもよい。各エンドユーザには、異なるローカルニュース記事または異なる広告が提示されてもよい。コンテンツおよびアプリケーションが読み出されると、仮想マシンは、コンテンツを処理し、MPEG映像ストリームを生成する。次いで、MPEG映像ストリームは、要求クライアントデバイスへと向けられる。次いで、エンドユーザは、コンテンツと対話して、新しいコンテンツによって更新された場面を要求してもよく、処理局における仮想マシンは、映像コンテンツ配信ネットワークのプロキシ/キャッシュから新しい映像コンテンツを要求することによって、場面を更新する。
【0030】
(オーサリング環境)
オーサリング環境は、双方向アプリケーションを開発するために、
図1Cに示されるようなグラフィカルエディタを含む。アプリケーションは、1つ以上の場面を含む。
図1Bに示されるように、アプリケーションウインドウは、アプリケーションが3つの場面(場面1、場面2、および場面3)から構成されることを示す。グラフィカルエディタは、デベロッパに、ユーザと関連付けられた表示デバイス上に最終的に示されるであろう表示を形成する場面の中に配置される要素を選択させる。いくつかの実施形態では、要素は、アプリケーションウインドウ内にドラッグ・アンド・ドロップされる。例えば、デベロッパは、メディアプレイヤオブジェクトおよびメディアプレイヤボタンオブジェクトを含むことを所望してもよく、ツールバーからこれらの要素を選択し、ウインドウ内に要素をドラッグ・アンド・ドロップするであろう。グラフィカル要素がウインドウ内にあると、デベロッパは、要素を選択可能となり、要素のためのプロパティウインドウが提供される。プロパティウインドウは、少なくとも、グラフィカル要素の位置(アドレス)、およびグラフィカル要素のサイズを含む。グラフィカル要素がオブジェクトと関連付けられる場合、プロパティウインドウは、デベロッパが、ビットマップイベント画面に切り替え、関連付けられたオブジェクトパラメータを変更することを可能にするタブを含むであろう。例えば、ユーザは、ボタンと関連付けられた機能を変更してもよく、またはボタンと関連付けられたプログラムを定義してもよい。
【0031】
図1Dに示されるように、システムのステッチャは、オーサリング環境の出力であるAVMLファイルに基づいて、場面に対する一連のMPEGフレームを生成する。場面内の各要素/グラフィカルオブジェクトは、領域を定義する異なるスライスから構成される。要素/オブジェクトを定義する領域は、連続状または非連続状であってもよい。システムは、マクロブロック境界上にグラフィックを形成するスライスをスナップする。各要素は、連続状スライスを有する必要はない。例えば、背景は、それぞれが複数のマクロブロックから構成されるいくつかの非連続状スライスを有する。背景は、静的である場合、内部符号化されたマクロブロックによって定義可能である。同様に、ボタンのそれぞれに対するグラフィックは、内部符号化可能である。しかしながら、ボタンは、状態と関連付けられ、複数の可能なグラフィックを有する。例えば、ボタンは、第1の状態「オフ」および第2の状態「オン」を有してもよく、第1のグラフィックは、非押下状態にあるボタンの画像を示し、第2のグラフィックは、押下状態にあるボタンを示す。また、
図1Cは、映画に対するウインドウである、第3のグラフィカル要素を示す。映画スライスは、内部符号化および相互符号化マクロブロックの混合で符号化され、コンテンツに基づいて、動的に変化する。同様に、背景が動的である場合、背景は、グルーミングに関する以下の要件に従って、内部符号化および相互符号化マクロブロックの両方で符号化可能である。
【0032】
ユーザがクライアントデバイスを通してアプリケーションを選択すると、処理局は、オーサリング環境のグラフィカルエディタからのレイアウトに従って、要素をステッチングしてまとめる。オーサリング環境の出力は、アクティブビデオマークアップ言語ファイル(AVML)を含む。AVMLファイルは、ボタン、関連付けられたグラフィックのアドレス、およびグラフィックのサイズ等の多状態要素に関する状態情報を提供する。AVMLファイルは、各要素に対するMPEGフレーム内の位置を示し、各要素と関連付けられたオブジェクトを示し、ユーザのアクションに基づいて、MPEGフレームに対する変更を定義するスクリプトを含む。例えば、ユーザは、命令信号を処理局に送信してもよく、処理局は、受信した命令信号に基づいて、AVMLファイルを使用して、一式の新しいMPEGフレームを構築する。ユーザは、種々の映像要素間の切り替えを所望してもよく、命令信号を処理局に送信してもよい。処理局は、フレームに対するレイアウト内の映像要素を除去し、第2の映像要素を選択し、第2の映像要素をMPEGフレーム内の第1の映像要素の位置にステッチングさせる。本プロセスは、以下に説明される。
【0033】
(AVMLファイル)
アプリケーションプログラミング環境は、AVMLファイルを出力する。AVMLファイルは、XMLベースの構文を有する。AVMLファイル構文は、ルートオブジェクト<AVML>を含む。他の最上位レベルタグは、アプリケーションが開始するとロードされる第1の場面を指定する<initialscene>を含む。<script>タグは、スクリプトを識別し、<scene>タグは、場面を識別する。また、タグ内のデータを適用するための階層が存在するように、最上位レベルタグのそれぞれに対して下位レベルタグが存在してもよい。例えば、最上位レベルストリームタグは、映像ストリームのための<aspect ratio>、<video format>、<bit rate>、<audio format>、および<audio bit rate>を含んでもよい。同様に、場面タグは、場面内の要素のそれぞれを含んでもよい。例えば、背景のための<background>、ボタンオブジェクトのための<button>、および静止グラフィックのための<static image>である。他のタグは、要素のサイズおよび位置のための<size>および<pos>を含み、場面内の各要素に対する下位レベルタグであってもよい。AVMLファイルの実施例は、
図1Bに提供される。
【0034】
(グルーマ)
図2は、要求クライアントデバイスのテレビに提供可能な代表的表示の略図である。ディスプレイ200は、画面上に現れる3つの別個の映像コンテンツ要素を示す。要素#1
211は、要素#2 215および要素#3 217が挿入される背景である。
【0035】
図3は、
図2の表示を生成可能なシスムの第1の実施形態を示す。本略図では、3つの映像コンテンツ要素が、要素#1 303、要素#2 305、および要素#3 307の符号化映像として供給される。グルーマ310はそれぞれ、符号化映像コンテンツ要素を受信し、グルーマは、ステッチャ340がグルーミングされた映像コンテンツ要素を単一の合成された映像380に結合する前に、各要素を処理する。当業者には、グルーマ310が、単一プロセッサまたは並行に動作する複数のプロセッサであってもよいことを理解されたい。グルーマは、コンテンツプロバイダの施設または一次放送提供者の施設における、処理局内に位置してもよい。グルーマは、グルーマ190および180がステッチャ115に直接連結されてない
図1に示されるように、ステッチャに直接接続されなくてもよい。
【0036】
ステッチングのプロセスは、以下に説明されるが、要素が最初にグルーミングされる場合、はるかにより効率的に行なうことが可能である。
【0037】
グルーミングは、圧縮された映像内に存在する相互依存性の一部を除去する。グルーマは、IおよびBフレームをPフレームに変換し、クロッピングまたは除去された映像の別のフレームのセクションを参照する、任意の迷子の(stray)動きベクトルを固定する。したがって、グルーミングされた映像ストリームは、他のグルーミングされた映像ストリームおよび符号化静止画像と組み合わせて使用され、合成MPEG映像ストリームを形成可能である。各グルーミングされた映像ストリームは、複数のフレームを含み、これらフレームは、別のグルーミングされたフレーム内に容易に挿入可能であって、複数の合成フレームは、一緒にグループ化され、MPEG映像ストリームを形成する。グルーミングされたフレームは、1つ以上のMPEGスライスから形成されてもよく、MPEG映像ストリーム内のMPEG映像フレームよりサイズが小さくてもよいことに留意されたい。
【0038】
図4は、複数の要素410、420を含有する合成映像フレームの実施例である。本合成映像フレームは、例証目的のために提供される。
図1に示されるようなグルーマは、映像シーケンスがステッチャ内でステッチングされてまとめらることが可能であるように、単一要素のみを受信し、その要素(映像シーケンス)をグルーミングする。グルーマは、複数の要素を同時に受信しない。本実施例では、背景映像フレーム410は、スライス当たり1列を含む(これは、実施例に過ぎず、列は、任意の数のスライスから構成され得る)。
図1に示されるように、場面内の要素すべての位置を含む、映像フレームのレイアウトは、AVMLファイル内のアプリケーションプログラマによって定義される。例えば、アプリケーションプログラマは、場面に対する背景要素を設計してもよい。したがって、アプリケーションプログラマは、MPEG映像として符号化される背景を有してもよく、背景がプロキシキャッシュ140内に配置されるのに先立って、背景をグルーミングしてもよい。したがって、アプリケーションが要求されると、アプリケーションの場面内の要素はそれぞれ、グルーミングされた映像であってもよく、グルーミングされた映像は、容易にステッチングしてまとめることが可能である。コンテンツプロバイダおよび一次放送局に対して、2つのグルーマが
図1内に示されるが、グルーマは、システムの他の部分に存在してもよいことに留意されたい。
【0039】
示されるように、映像要素420は、背景映像フレーム410内に挿入される(また、実施例に過ぎないが、本要素は、列当たり複数のスライスからも構成され得る)。オリジナル映像フレーム410内のマクロブロックが、その値を判定する際、別のマクロブロックを参照し、動画像420がその場所に挿入されるために参照マクロブロックがフレームから除去される場合、マクロブロック値は、再計算される必要がある。同様に、後続フレーム内の別のマクロブロックをマクロブロックが参照し、そのマクロブロックが除去され、他のソース題材がその場所に挿入される場合、マクロブロック値は、再計算される必要がある。これは、映像430をグルーミングすることによって対処される。映像フレームは、列が複数のスライスを含有し、その一部が、代用映像コンテンツと整合するように特異的にサイズ調整および配置されるように処理される。本プロセスが完了後は、現在のスライスの一部をオーバーレイ映像と置換し、オーバーレイ440を伴うグルーミングされた映像をもたらすという単純な作業である。グルーミングされた映像ストリームは、その特定のオーバーレイを対処するように特異的に定義されている。異なるオーバーレイは、異なるグルーミングパラメータを指図するであろう。したがって、このタイプのグルーミングは、ステッチングに備えて、映像フレームを複数のスライスにセグメント化するプロセスに対処する。スライスをオーバーレイ要素に追加する必要は決してないことに留意されたい。スライスは、受信要素、すなわち、オーバーレイが配置されるであろう要素にのみ追加される。グルーミングされた映像ストリームは、ストリームのグルーミングされた特徴に関する情報を含有可能である。提供可能な特徴は、1.グルーミングされたウインドウの左上および右下角の位置、2.左上角のみの位置、次いで、ウインドウのサイズ、を含む。スライスのサイズは、画素レベルまで正確である。
【0040】
また、映像ストリーム内の特徴情報を提供するための2つの方法が存在する。1つ目は、スライスヘッダ内に情報を提供することである。2つ目は、拡張データスライス構造内にその情報を提供することである。これらの選択肢のうちのいずれかを使用して、仮想マシンおよびステッチャ等の後続処理段階に、必要情報の転送を成功させることが可能である。
【0041】
図5は、グルーミング前後の映像グラフィカル要素に対する映像シーケンスを示す。オリジナルの到来する符号化ストリーム500は、当業者に公知であるように、MPEG I−フレーム510、B−フレーム530、550、およびP−フレーム570のシーケンスを有する。このオリジナルストリームでは、I−フレームは、他のフレームすべて(BおよびPの両方)に対する参照512として使用される。これは、I−フレームから他のフレームすべてへの矢印を介して示される。また、P−フレームは、両方のB−フレームに対する参照フレーム572として使用される。グルーマは、ストリームを処理し、全フレームをP−フレームと置換する。最初に、オリジナルI−フレーム510が、内部符号化されたP−フレーム520に変換される。次に、B−フレーム530、550が、P−フレーム540および560に変換535され、直前のフレームのみ参照するように修正される。また、P−フレーム570は、その参照574をオリジナルI−フレーム510からP−フレーム570の直前の新しく生成されたP−フレーム560に移動させるように修正される。結果として得られるP−フレーム580は、グルーミングされた符号化フレーム590の出力ストリームに示される。
【0042】
図6は、標準的MPEG−2ビットストリーム構文の略図である。MPEG−2は、実施例として使用され、本発明は、本実施例に限定されるものとしてみなされるべきではない。ビットストリームの階層構造は、シーケンスレベルで開始する。これは、シーケンスヘッダ600を含有し、ピクチャのグループ(GOP)データ605が続く。GOPデータは、GOPヘッダ620を含有し、ピクチャデータ625が続く。ピクチャデータ625は、ピクチャヘッダ640を含有し、スライスデータ645が続く。スライスデータ645は、あるスライスオーバーヘッド660から成り、マクロブロックデータ665が続く。最後に、マクロブロックデータ665は、あるマクロブロックオーバーヘッド680から成り、ブロックデータ685が続く(ブロックデータは、さらに分割されるが、この参照の目的のためには必要とされない)。シーケンスヘッダは、グルーマ内で規準として作用する。しかしながら、全フレームがP−フレームであるため、グルーマのGOPヘッダ出力は存在しない。ヘッダの残りは、必要とされる出力パラメータを満たすように修正されてもよい。
【0043】
図7は、映像シーケンスをグルーミングするためのフローを提供する。最初に、フレームタイプが判定される700(I−フレーム703、B−フレーム705、またはP−フレーム707)。I−フレーム703は、B−フレーム705同様に、P−フレームに変換される必要がある。加えて、I−フレームは、ステッチャが必要とするピクチャ情報に整合させる必要がある。例えば、この情報は、ピクチャヘッダ内に設定される符号化パラメータを示してもよい。したがって、第1のステップは、ピクチャヘッダ内の情報が、全グルーミングされた映像シーケンスに対して一貫性であるように、ピクチャヘッダ情報730を修正することである。ステッチャ設定は、アプリケーション内に含まれ得るシステムレベル設定である。これらは、ビットストリームの全レベルに対して使用されるであろうパラメータである。修正を必要とする項目は、以下の表に提供され、
【0044】
【表1】
次に、スライスオーバーヘッド情報740が修正されなければならない。修正するパラメータは、以下の表に提供され、
【0045】
【表2】
次に、マクロブロックオーバーヘッド750情報が、修正を必要としてもよい。修正されるべき値は、以下の表に提供され、
【0046】
【表3】
最後に、ブロック情報760が、修正を必要としてもよい。修正される項目は、以下の表に与えられる。すなわち、
【0047】
【表4】
ブロック変更が完了すると、プロセスを映像の次のフレームから再開可能である。
【0048】
フレームタイプがB−フレーム705である場合、また、I−フレームに必要とされる同一ステップが、B−フレームに必要とされる。しかしながら、加えて、動きベクトル770が修正を必要とする。2つのシナリオが存在する。B−フレームは、I−フレームまたはP−フレーム直後に続く、あるいはB−フレームは、別のB−フレームに続く。B−フレームがIまたはPフレームのいずれかに続く場合、IまたはPフレームを参照として使用する動きベクトルは、同一のままであることが可能であって、残差のみ、変更が必要とされるであろう。これは、前向き参照動きベクトルが残差であるように変換するくらい単純であってもよい。
【0049】
別のB−フレームに続くB−フレームの場合、動きベクトルおよびその残差は両方とも、修正される必要があるであろう。第2のB−フレームは、ここでは、その直前のPフレームに新しく変換されたBを参照しているはずである。最初に、B−フレームおよびその参照が復号化され、動きベクトルおよび残差が再計算される。フレームが復号化され、動きベクトルを更新するが、DCT係数を再符号化する必要がないことに留意されたい。これらは、同一のままである。動きベクトルおよび残差のみ、計算および修正される。
【0050】
最後のフレームタイプは、P−フレームである。また、本フレームタイプは、I−フレームと同一パスを辿る。
図8は、領域境界に隣接するマクロブロックに対する動きベクトルの修正を示す。領域境界上の動きベクトルは、他の映像要素が挿入される背景要素と最も関連することを認識されたい。したがって、背景要素のグルーミングは、アプリケーションクリエイタによって達成されてもよい。同様に、映像要素がクロッピングされ、背景要素内の「ホール」に挿入される場合、クロッピングされた要素は、「ホール」外側の位置をポイントする動きベクトルを含んでもよい。クロッピングされた画像に対する動きベクトルのグルーミングは、映像要素がクロッピングされる必要があるサイズをコンテンツクリエイタが既知の場合、コンテンツクリエイタによって行なわれてもよく、またはグルーミングは、挿入されるべき映像要素が背景内の「ホール」のサイズより大きい場合、要素レンダラおよびMPEGエンコーダと組み合わせて、仮想マシンによって達成されてもよい。
【0051】
図8は、背景要素から除去される領域を囲繞する動きベクトルによって生じる課題をグラフィック的に示す。
図8の実施例では、場面は、2つの領域、#1 800および#2
820を含む。不適切な動きベクトル参照の2つの実施例が存在する。第1の事例では、領域#1 800(背景)に挿入される領域#2 820は、動き840に対する参照として、領域#1 800(背景)を使用する。したがって、領域#2内の動きベクトルは、補正される必要がある。不適切な動きベクトル参照の第2の事例は、領域#1 800が、動き860に対する参照として、領域#2 820を使用する場合に生じる。グルーマは、同一領域内のフレームを使用して再符号化するか、またはマクロブロックを内部符号化されたブロックに変換することのいずれかによって、これらの不適切な動きベクトル参照を除去する。
【0052】
また、動きベクトルを更新し、フレームタイプを変更することに加えて、グルーマは、フィールドベースの符号化マクロブロックからフレームベースの符号化マクロブロックに変換してもよい。
図9は、フィールドベースからフレームベースの符号化マクロブロックへの変換を示す。参照として、フレームベースのブロック集合900が圧縮される。圧縮されたブロック集合910は、同一ブロック内に同一情報を含有するが、ここでは、圧縮された形態で含有されている。一方、また、フィールドベースのマクロブロック940も、圧縮される。これが行なわれると、全偶数列(0、2、4、6)は、上方ブロック(0および1)に配置される一方、奇数列(1、3、5、7)は、下方ブロック(2および3)に配置される。圧縮されたフィールドベースのマクロブロック950が、フレームベースのマクロブロック970に変換されると、係数は、あるブロックから別のブロックに移動される必要がある980。すなわち、列は、奇偶ではなく、番号順に再構築されなければならない。フィールドベースの符号化では、ブロック2および3にあった列1および3は、ここでは、それぞれ、ブロック0または1に戻される。対応して、列4および6は、ブロック0および1から移動し、ブロック2および3に配置される。
【0053】
図10は、グルーミングプラットフォームの第2の実施形態を示す。全構成要素は、第1の実施形態のグルーマ1110Aおよびステッチャ1130Aと同一である。また、入力も、同一である(入力#1 1103A、入力#2 1105A、および入力#3 1107A、ならびに合成された出力1280)。本システムにおける差異は、ステッチャ1140Aが、同期およびフレームタイプ情報の両方のフィードバックをグルーマ1110Aのそれぞれに提供することである。同期およびフレームタイプ情報によって、ステッチャ1240は、グルーマ1110Aが続くGOP構造を定義可能である。本フィードバックおよびGOP構造によって、グルーマの出力は、もはやP−フレームだけではなく、I−フレームおよびB−フレームを含むことも可能である。フィードバックを伴わない実施形態の制限は、いずれのグルーマにもステッチャが構築していたフレームのタイプが未知であることである。ステッチャ1140Aからのフィードバックを伴うこの第2の実施形態では、グルーマ1110Aには、ステッチャが構築しているピクチャタイプを既知であって、したがって、グルーマは、整合するフレームタイプを提供するであろう。これは、同一データレートを仮定すると、ピクチャ品質を改良し、より多くの参照フレームおよび既存フレームのより少ない修正に起因して、品質レベルが一定に維持されると仮定すると、データレートを低下させる一方、同時に、B−フレームが許容されるため、ビットレートを低減する。
【0054】
(ステッチャ)
図11は、
図1に示されるステッチャ等のステッチャモジュールを実装するための環境を示す。ステッチャ1200は、異なるソースから映像要素を受信する。非圧縮コンテンツ1210は、ステッチャ1200におけるその到着に先立って、
図1に示されるMPEG要素エンコーダ等のエンコーダ1215内で符号化される。圧縮または符号化された映像1220は、符号化される必要はない。しかしながら、両方の場合において、音声1217、1227を映像1219、1229から分離する必要がある。音声は、ストリーム内に含まれるように、音声セレクタ1230に供給される。映像は、バッファ1250に入れられる前に、フレーム同期ブロック1240に供給される。フレームコンストラクタ1270は、コントローラ1275からの入力に基づいて、バッファ1250からデータを引き出す。フレームコンストラクタ1270からの映像は、映像と整合するように音声が遅延1260された後、音声とともに、マルチプレクサ1280に供給される。マルチプレクサ1280は、音声および映像ストリームを結合し、任意の標準的デコーダ上で再生可能な合成された符号化出力ストリーム1290を出力する。プログラムまたはトランスポートストリームにデータストリームを多重化することは、当業者には周知である。符号化映像ソースは、リアルタイム、保存場所からのもの、または両方の組み合わせであることが可能である。ソースすべてがリアルタイムで到着する必要はない。
【0055】
図12は、一時的に同期していない3つの映像コンテンツ要素の実施例を示す。3つの要素を同期させるために、要素#1 1300は、「アンカ」または「参照」フレームとして使用される。すなわち、それはマスタフレームとして使用され、他の全フレームは、それに整合されるであろう(これは、実施例に過ぎず、システムは、到来する映像ソースのいずれからも別個のその独自のマスタフレーム参照を有し得る)。出力フレームタイミング1370、1380は、要素#1 1300のフレームタイミングと整合するように設定される。要素#2および#3 1320、1340は、要素#1 1300と整合しない。したがって、そのフレーム開始の位置が特定され、バッファ内に保存される。例えば、要素#2 1320は、1フレーム遅延され、したがって、参照フレームとともに合成される前に、全体的フレームが利用可能である。要素#3は、参照フレームよりもはるかに遅い。要素#3は、2つのフレームにわたって集められ、2つのフレームにわたって提示される。すなわち、要素#3 1340の各フレームは、参照フレームのフレームレートと整合するために、2つの連続的フレームに対して表示される。反対に、フレーム(図示せず)が参照フレームの2倍の速度で流れる場合、フレームが1つおきに欠落されるであろう(図示せず)。恐らく、全要素がほぼ同一速度で流れているため、フレームが、同期を維持するために、繰り返されるかまたは欠落される必要がある頻度は低いであろう。
【0056】
図13は、例示的合成映像フレーム1400を示す。本実施例では、フレームは、ピクチャ当たり30列1420を伴う列当たり40マクロブロック1410から成る。サイズは、実施例として使用され、本発明の範囲を制限するように意図されるものではない。フレームは、種々位置に合成される要素1440を有する背景1430を含む。これらの要素1440は、映像要素、静止要素等であることが可能である。すなわち、フレームは、全体的な背景で構築され、次いで、異なる要素と置換される特定のエリアを有する。この特定の実施例は、背景上に合成される4つの要素を示す。
【0057】
図14は、ピクチャ内のスライスを例示する画面のより詳細な変形例を示す。略図は、列当たり40マクロブロックおよびピクチャ当たり30列(非制限的、例示目的に過ぎない)から成るピクチャを描写する。しかしながら、また、スライスに分割されるピクチャも示す。スライスのサイズは、列全体1590(陰影として示される)または列内の数マクロブロック1580(要素#4 1528内の斜線を伴う矩形として示される)であることが可能である。背景1530は、各領域の幅に整合するスライスサイズを伴う複数の領域に分割されている。これは、要素#1 1522を見ると、より分かるであろう。要素#1 1522は、12のマクロブロック幅であるように定義されている。次いで、背景1530および要素#1 1522の両方に対する本領域のスライスサイズは、そのマクロブロックの正確な数となるように定義される。次いで、要素#1 1522は、6つのスライスから成り、各スライスは、12のマクロブロックを含有する。同様に、要素#2 1524は、スライス当たり8つのマクロブロックの4つのスライスから成り、要素#3 1526は、スライス当たり23のマクロブロックの18のスライスであって、要素#4 1528は、スライス当たり5つのマクロブロックの17のスライスである。背景1530および要素は、任意の数のスライスから成るように定義可能であって、ひいては、任意の数のマクロブロックであり得ることは明白である。これは、所望の任意の様式にピクチャおよび要素を配列するために、完全なる柔軟性を提供する。映像フレーム内の要素の位置付けとともに、各要素に対するスライスコンテンツを決定するプロセスは、AVMLファイルを使用して、
図1の仮想マシンによって決定される。
【0058】
図15は、仮想マシンによる、ステッチャ内でステッチングを生じさせるための背景1600の調製を示す。仮想マシンは、AVMLファイルに基づいて、非圧縮背景を収集し、背景を要素エンコーダに転送する。仮想マシンは、背景内の位置を転送し、要素は、フレーム内に配置されるであろう。示されるように、背景1620は、仮想マシンによって、背景の要素エンコーダへの転送に先立って、要素(単数または複数)が配置される(べき)場所と正確に整合するホールとともに、特定のスライス構成に分割されている。エンコーダは、背景を圧縮し、要素(単数または複数)が配置される場所に「ホール」または「複数のホール」を残す。エンコーダは、圧縮された背景をメモリに転送する。次いで、仮想マシンは、メモリにアクセスし、場面に対する各要素を読み出し、要素のそれぞれに対する各スライスの位置のリストとともに、符号化要素をステッチャに転送する。ステッチャは、スライスのそれぞれを取り込み、スライスを適切な位置に配置する。
【0059】
この特定のタイプの符号化は、「スライスベースの符号化」と呼ばれる。スライスベースのエンコーダ/仮想マシンは、出力フレームの所望のスライス構造を認知しており、その符号化を適切に行なうものである。すなわち、エンコーダは、スライスのサイズおよびそれらが属する場所を知っている。必要とされる場合にホールを残す場所を知っている。所望の出力スライス構成を認知していることによって、仮想マシンは、容易にステッチングされる出力を提供する。
【0060】
図16は、背景要素が圧縮された後の合成プロセスを示す。背景要素1700は、要素1740が配置されるべきホールとともに、7つのスライスに圧縮されている。合成画像1780は、背景要素1700および要素1740の組み合わせの結果を示す。合成映像フレーム1780は、挿入されたスライスを灰色で示す。本略図は、背景上に合成される単一要素を描写するが、ユーザのディスプレイ上に適合するであろう任意の数の要素を合成可能である。さらに、背景または要素に対する列当たりスライスの数は、示されているものよりも多いことも可能である。背景および要素の、スライス開始およびスライス終了点は、整合されなければならない。
【0061】
図17は、背景要素1800(24画素×24画素)と追加された映像コンテンツ要素1840(16画素×16画素)との間の異なるマクロブロックサイズを示す略図である。合成された映像フレーム1880は、2つの場合を示す。水平には、画素は、背景800内には、24画素/ブロック×4ブロック=96画素幅、映像コンテンツ要素1840に対しては、16画素/ブロック×6ブロック=96画素幅であるように整合される。しかしながら、垂直には、差異が存在する。背景1800は、24画素/ブロック×3ブロック=72画素高である。要素1840は、16画素/ブロック×4ブロック=64画素高である。これは、8画素の垂直ギャップ1860を残す。ステッチャは、そのような差異を認知し、要素または背景のいずれかを外挿し、ギャップを充填可能である。また、明暗の境界領域が存在するように、ギャップを残すことも可能である。本実施例は、24×24および16×16のマクロブロックサイズを使用するが、マクロブロックサイズの任意の組み合わせを容認可能である。DCTベースの圧縮形式は、意図される本発明の範囲から逸脱することなく、16×16以外のサイズのマクロブロックに依存してもよい。同様にまた、DCTベースの圧縮形式は、意図される本発明の範囲から逸脱することなく、時間的予測のために、可変サイズのマクロブロックに依存してもよい。最後に、また、コンテンツの周波数領域表現は、意図される本発明の範囲から逸脱することなく、他のフーリエ関連変換を使用して達成されてもよい。
【0062】
また、合成された映像フレーム内にオーバーラップが存在することも可能である。再び
図17を参照すると、要素1840は、4つのスライスから成る。本要素が、実際には、5つのスライスである場合、合成された映像フレーム1880内の背景要素1800とオーバーラップするであろう。本衝突を解決するための複数の方法が存在するが、最も容易には、要素の4つのスライスのみ合成し、5つ目を欠落させる。また、第5のスライスを背景列に合成し、衝突する背景列をスライスに分割し、第5の要素スライスと衝突する背景スライスを除去することも可能である(次いで、第6の要素スライスを追加し、任意のギャップを充填することも可能である)。
【0063】
異なるスライスサイズの可能性は、到来する背景および映像要素が適切であるか確認するためのチェックを行なう合成機能を必要とする。すなわち、それぞれが完全(例えば、フレーム全体)である、サイズ衝突が存在しないか等を確かめる。
【0064】
図18は、フレームの要素を描写する略図である。単純合成ピクチャ1900は、要素1910および背景要素1920から成る。要求された場面に対する映像フレームの構築を制御するために、ステッチャは、仮想マシンによって提供されるような各要素に対する位置情報に基づいて、データ構造1940を構築する。データ構造1940は、マクロブロックの数およびマクロブロックが位置する場所を記述する、リンクされたリストを含有する。例えば、データ列1 1943は、ステッチャが、背景に対するバッファであるバッファBから、40のマクロブロックを取り込むはずであることを示す。データ列2 1945は、バッファBから12のマクロブロック、次いで、バッファE(要素1910に対するバッファ)から8つのマクロブロック、次いで、バッファBから別の20のマクロブロックを取り込むはずである。これは、ステッチャがデータ構造を使用して、バッファBから40のマクロブロックを取り込む、最後の列1947まで継続する。バッファ構造1970は、各背景または要素に対して別個のエリアを有する。Bバッファ1973は、Bマクロブロック内にステッチングのための全情報を含有する。Eバッファ1975は、Eマクロブロック内にステッチングのための情報を有する。
【0065】
図19は、複数の符号化要素からピクチャを構築するためのプロセスを描写するフローチャートである。シーケンス2000は、映像フレーム組成2010を開始することによって始まる。最初に、フレームが、同期2015され、次いで、各列2020が、適切なスライス2030をつかむことによって構築される。次いで、スライスが、挿入2040され、システムは、それが列の終了2050であるかどうかチェックする。そうでない場合、プロセスは、列の終了2050に到達するまで、「次のスライスをフェッチ」ブロック2030に戻る。列が完了すると、システムは、それがフレームの終了2080であるかどうかチェックする。そうではない場合、プロセスは、「各列に対して」2020ブロックに戻る。フレームが完了すると、システムは、それが場面に対するシーケンスの終了2090であるかどうかチェックする。そうではない場合、「フレームを合成」2010ステップに戻る。そうである場合、場面に対するフレームまたは映像フレームのシーケンスは、完了2090する。そうではない場合、フレーム構築プロセスを繰り返す。シーケンスの終了2090に到達した場合、場面は完了であって、プロセスが終了するか、または別のフレームの構築を開始可能である。
【0066】
ステッチャの性能は、ステッチャにフレーム形式に関する情報を事前に提供することによって、改良(より少ないプロセッサパワーでより高速にフレームを構築)可能である。例えば、仮想マシンは、ステッチャに、挿入されるフレーム内のエリアの開始位置およびサイズを提供してもよい。代替として、情報は、各スライスに対する開始位置であり得、次いで、ステッチャは、サイズ(2つの開始位置間の差異)を解明可能である。本情報は、仮想マシンによって外部から提供可能であるか、または仮想マシンは、情報を各要素に組み込み可能である。例えば、スライスヘッダの一部を使用して、本情報を伝えることが可能である。ステッチャは、フレーム構造のこの事前知識を使用して、必要とされる十分前に、要素の合成を開始可能である。
【0067】
図20は、システムのさらなる改良を示す。上記グルーマセクションにて説明したように、グラフィカル映像要素は、グルーミング可能であって、それによって、既に圧縮され、かつ、ステッチングしてまとめられるために復号化される必要がない、ステッチング可能な要素を提供する。
図20では、フレームは、いくつかの符号化スライス2100を有する。各スライスは、列全体である(これは、実施例として使用されているに過ぎず、列は、グルーミングに先立って、複数のスライスから成り得る)。仮想マシンは、AVMLファイルと組み合わせて、合成された映像フレーム内において特定の位置に配置される特定のサイズの要素2140が存在すべきであるかどう判定する。グルーマは、到来する背景2100を処理し、列全体の符号化スライスを、所望の要素2140位置の周囲およびその中のエリアに整合する、より小さいスライスに変換する。結果として得られるグルーミングされた映像フレーム2180は、所望の要素2140に整合するスライス構成を有する。次いで、ステッチャは、グルーミングされたフレーム2180から、#3および#6を除く全スライスを選択することによって、ストリームを構築する。それらのスライスの代わりに、ステッチャは、要素2140スライスをつかみ、所定の場所でそれを使用する。このように、背景は、圧縮された領域を残すことなく、システムは、依然として、要素2140をフレームに合成可能である。
【0068】
図21は、合成されるべき要素を規定するために利用可能な柔軟性を示す。要素は、異なる形状およびサイズであることが可能である。要素は、連続的に常駐する必要はなく、実際、単一要素は、背景によって分離される複数の画像から形成可能である。本図は、背景要素2230(灰色エリア)を示し、その上に合成される単一要素2210(白色エリア)を有している。本略図では、合成される要素2210は、エリアであって、シフトされる、異なるサイズである、かつ単一列上に要素の複数の部分が存在する場所でさえある、エリアを有する。ステッチャは、表示を生成するために使用される複数の要素があたかも存在しているかのように、本ステッチングを行なうことが可能である。フレームに対するスライスは、連続的に、S1〜S45と標識される。これらは、要素が配置されるであろうスライス位置を含む。また、要素は、ES1〜ES14のそのスライス番号付けを有する。要素スライスは、単一要素ファイルから引き出される場合であっても、所望に応じて、背景内に配置可能である。
【0069】
要素スライスに対するソースは、いくつかの選択肢のうちの任意の1つであることが可能である。それは、リアルタイム符号化ソースに由来可能である。別個のスライスから構築される複合スライスであることが可能であって、1つは、背景を有し、他は、テキストを有する。キャッシュからフェッチされる事前符号化要素であることも可能である。これらの実施例は、例示目的に過ぎず、要素ソースに対する選択肢を限定するように意図されない。
【0070】
図22は、一次放送コンテンツをグルーミングするためのグルーマ2340を使用する実施形態を示す。コンテンツは、グルーマ2340によって、リアルタイムで受信される。各チャネルは、コンテンツが容易にステッチングしてまとめられることが可能であるように、グルーマ2340によってグルーミングされる。
図22のグルーマ2340は、一次放送チャネルのすべてをグルーミングするために、複数のグルーマモジュールを含んでもよい。次いで、グルーミングされたチャネルは、1つ以上の処理局2310、2320、2330、および、アプリケーション内での使用のために、処理局のそれぞれの内の1つ以上の仮想マシンにマルチキャストされてもよい。示されるように、クライアントデバイスは、クライアントによって選択される、一次放送ソースおよび/または他のグルーミングされたコンテンツのモザイク2350の受信のためのアプリケーションを要求する。モザイク2350は、
図23に示されるように、複数のソース2371〜2376を同時に視聴可能な背景フレーム2360を含む場面である。例えば、ユーザが視聴を所望する複数のスポーツイベントが存在する場合、ユーザは、モザイク内で同時視聴するために、スポーツイベントを搬送するチャネルのそれぞれを要求可能である。ユーザは、MPEGオブジェクト(編集)2380を選択し、次いで、表示されるべき所望のコンテンツソースを編集することさえ可能である。例えば、グルーミングされたコンテンツは、一次/ライブ放送から、また、他の映像コンテンツ(すなわち、映画、事前録画されたコンテンツ等)からも選択可能である。モザイクは、ユーザ選択された題材、および、広告等の処理局/セッションプロセッサによって提供される題材の両方を含むことさえあり得る。
図22に示されるように、クライアントデバイス2301〜2305はそれぞれ、チャネル1を含むモザイクを要求する。したがって、チャネル1に対してマルチキャストグルーミングされたコンテンツは、個人化されたモザイクの構造内で異なる仮想マシンおよび異なる処理局によって使用される。
【0071】
クライアントデバイスがモザイクアプリケーションに対する要求を送信すると、クライアントデバイスと関連付けられた処理局は、要求されたモザイクアプリケーションに対するクライアントデバイスのために、プロセッサ/仮想マシンを割り当てる。割り当てられた仮想マシンは、ステッチャを使用して、所望のチャネルから、グルーミングされたコンテンツを合成することによって、個人化されたモザイクを構築する。仮想マシンは、クライアントが要求したチャネルのモザイクを有するMPEGストリームをクライアントデバイスに送信する。したがって、コンテンツをステッチングしてまとめることが可能なように、最初に、コンテンツをグルーミングすることによって、モザイクを生成する仮想マシンは、最初に、所望のチャネルを復号化し、背景内のチャネルをビットマップとしてレンダリングし、次いで、ビットマップを符号化する必要がない。
【0072】
モザイク等のアプリケーションは、クライアントデバイスと関連付けられたディスプレイ上のアプリケーションの表示のために、クライアントデバイスを通して直接、またはPC等の別のデバイスを通して間接的に、要求可能である。ユーザは、ユーザのアカウントに関する情報を提供することによって、処理局と関連付けられたウェブサイトにログイン可能である。処理局と関連付けられたサーバは、アプリケーションを選択するための選択画面をユーザに提供するであろう。ユーザがモザイクアプリケーションを選択する場合、サーバは、ユーザがモザイク内での視聴を所望するコンテンツをユーザに選択させるであろう。モザイクに対して選択されたコンテンツに応答して、かつユーザのアカウント情報を使用して、処理局サーバは、要求をセッションプロセッサに向け、ユーザのクライアントデバイスとの双方向セッションを確立する。次いで、セッションプロセッサは、処理局サーバによって所望のアプリケーションを通知される。セッションプロセッサは、所望のアプリケーション(本実施例では、モザイクアプリケーション)を読み出し、要求されたMPEGオブジェクトを取得する。次いで、処理局サーバは、要求された映像コンテンツをセッションプロセッサに通知し、セッションプロセッサは、ステッチャと協働して、モザイクを構築し、モザイクをMPEG映像ストリームとしてクライアントデバイスに提供する。したがって、処理局サーバは、双方向セッションを設定し、アプリケーションを要求し、表示のためのコンテンツを選択する際、クライアントデバイスの機能を果たすためのスクリプトまたはアプリケーションを含んでもよい。モザイク要素は、アプリケーションによって既定であってもよいが、また、ユーザ構成可能であって、個人化されたモザイクをもたらしてもよい。
【0073】
図24は、IPベースのコンテンツ配信システムの略図である。本システムでは、コンテンツは、放送ソース2400、コンテンツプロバイダ2410によって供給されるプロキシキャッシュ2415、構成および管理ファイル2420を含有するネットワーク接続ストレージ(NAS)2425、または他の図示されないソースに由来してもよい。例えば、NASは、コンテンツの位置に関する情報を提供するアセットメタデータを含んでもよい。本コンテンツは、負荷平衡スイッチ2460を通して利用可能であり得る。BladeSessionプロセッサ/仮想マシン2460は、コンテンツに対して異なる処理機能を果たすことにより、配信のためにコンテンツを準備可能である。コンテンツは、セットトップボックス2490等のクライアントデバイスを介して、ユーザによって要求される。本要求は、コントローラ2430によって処理され、コントローラ2430は、次いで、リソースおよびパスを構成することにより、本コンテンツを提供する。クライアントデバイス2490は、コンテンツを受信し、それをユーザのディスプレイ2495上に提示する。
【0074】
図25は、ケーブルベースのコンテンツ配信システムの略図である。構成要素の多くは、同一であって、コントローラ2530、放送ソース2500、プロキシキャッシュ2515を介してそのコンテンツを提供するコンテンツプロバイダ2510、ファイルサーバNAS2525を介する構成および管理ファイル2520、セッションプロセッサ2560、負荷平衡スイッチ2550、セットトップボックス2590等のクライアントデバイス、およびディスプレイ2595を含む。しかしながら、また、異なる物理的メディアに起因して必要とされる機器のいくつかの付加的部品も存在する。この場合、追加されるリソースは、QAM変調器2575、リターンパス受信機2570、結合器およびダイプレクサ2580、ならびにセッションおよびリソースマネージャ(SRM)2540を含む。QAMアップコンバータ2575は、ユーザにデータ(コンテンツ)をダウンストリーム伝送することを要求される。これらの変調器は、ユーザへと続く同軸ケーブルを通して搬送可能な形態にデータを変換する。相応して、リターンパス受信機2570はまた、セットトップ2590からのケーブルをたどるデータを復調するために使用される。結合器およびダイプレクサ2580は、ダウンストリームQAMチャネルを結合し、かつアップストリームリターンチャネルを分割する、受動的デバイスである。SRMは、QAM変調器が構成され、かつ割り当てられる方法、およびストリームがクライアントデバイスにルーティングされる方法を制御する存在である。
【0075】
これらの付加的リソースは、システムにコストを追加する。その結果、IPネットワーク等の非ブロッキングシステムに類似するあるレベルの性能をユーザに配信するために必要とされる、付加的リソースの数を最小化することが所望される。ケーブルネットワークリソースとネットワーク上のユーザとの間に1対1の対応が存在しないため、リソースは、共有されなければならない。共有されるリソースは、ユーザがリソースを要求すると割り当てされ、次いで、ユーザがそのリソースの利用を終了すると解除可能なように管理されなければならない。これらのリソースの適切な管理は、それが行なわれない場合、リソースが最も必要とされる時に利用不可能であり得るため、オペレータにとって重要である。これが生じる場合、ユーザは、「お待ちください」メッセージ、または最悪の場合、「サービス利用不可」メッセージのいずれかを受信する。
【0076】
図26は、ユーザからの入力に基づいて、新しい双方向セッションを構成するために必要とされるステップを示す略図である。本略図は、割り当てられるか、または管理されるか、あるいは割当もしくは管理を行なうために使用されなければならない項目のみを描写する。典型的要求は、以下に列挙されるステップを辿るであろう。すなわち、
(1)セットトップボックス2609が、コントローラ2607からコンテンツを要求する2610
(2)コントローラ2607が、SRM2603からQAM帯域幅を要求する2620
(3)SRM2603が、QAMの可用性をチェックする2625
(4)SRM2603が、QAM変調器を割り当てる2630
(5)QAM変調器が、確認を返す2635
(6)SRM2603が、コントローラにQAM割り当ての成功を確認する2640
(7)コントローラ407が、セッションプロセッサを割り当てる2650
(8)セッションプロセッサが、割り当ての成功を確認する2653
(9)コントローラ2607が、コンテンツを割り当てる2655
(10)コントローラ2607が、セットトップ2609を構成する2660
これは、以下を含む:
a.同調する周波数
b.取得するプログラム、または代替として、復号化するためのPID
c.キーストロークのキャプチャのために、セッションプロセッサに接続するためのIPポート
(11)セットトップ2609が、チャネルに同調する2663
(12)セットトップ2609が、コントローラ2607に成功を確認する2665
である。
【0077】
コントローラ2607は、セットトップボックス2609からサービスに対する要求に基づいて、リソースを割り当てる。コントローラ2607は、セットトップまたはサーバが「セッションの終了」を送信すると、これらのリソースを解除する。コントローラ2607は、最小の遅延で迅速に反応可能であるが、SRM2603は、設定数の毎秒QAMセッション、すなわち、200のみを割り当て可能である。本レートを超える需要は、ユーザに容認不可能な遅延をもたらす。例えば、500の要求が同時に到着する場合、最後のユーザは、その要求が叶うまで5秒待機する必要があるであろう。また、要求が叶うのではなく、「サービス利用不可能」等のエラーメッセージが表示され得る可能性もある。
【0078】
上述の実施例は、ケーブルTVネットワーク上のAVDNセッションに対する要求および応答シーケンスを説明するが、以下の実施例は、IPTVネットワーク上の類似シーケンスを説明する。シーケンス自体は、特許請求の範囲ではなく、AVDNがIPTVネットワーク上でどのように作用するかの例示であることに留意されたい。すなわち、
(1)クライアントデバイスが、セッションマネージャ(すなわち、コントローラプロキシ)を介して、コントローラからコンテンツを要求する
(2)セッションマネージャは、コントローラに要求を転送する
(3)コントローラは、セッションマネージャ(すなわち、クライアントプロキシ)を介して、要求されたコンテンツに応答する
(4)セッションマネージャは、ユニキャストセッションをオープンし、ユニキャストIPセッション上で、クライアントにコントローラ応答を転送する
(5)クライアントデバイスは、ユニキャストIPセッション上で送信されるコントローラ応答を取得する
(6)セッションマネージャは、マルチキャストIPセッション上で応答を同時にナローキャストすることにより、帯域幅使用量最適化技術と同一のコンテンツを同時に要求するノードグループ上の他のクライアントと共有してもよい
である。
【0079】
図27は、性能改良のために各エリアを開示するために使用される、簡略化システムの略図である。本略図は、管理されるであろうデータおよび機器のみに焦点を当て、他の全ての非被管理項目を除去する。したがって、スイッチ、リターンパス、結合器等は、明確化のために除去される。本略図を使用して、エンドユーザからコンテンツ起点に戻るように作用する各項目を検討する。
【0080】
第1の問題は、SRM2720によるQAM2770およびQAMチャネル2775の割り当てである。特に、リソースは、SRM過負荷を防止するように、すなわち、SRM2720に対する要求がその毎秒セッションのレートを超える際に、ユーザが認識するであろう遅延を排除するように管理されなければならない。
【0081】
SRM「過負荷」を防止するために、「時間ベースのモデル化」が使用されてもよい。時間ベースのモデル化の場合、コントローラ2700は、過去のトランザクション、特に、高負荷期間の履歴を監視する。この以前の履歴を使用することによって、コントローラ2700は、高負荷期間が生じ得る時、例えば、毎時0分を予測可能である。コントローラ2700は、本知識を使用して、その期間が生じる前に、リソースを事前に割り当てる。すなわち、予測アルゴリズムを使用して、将来のリソース要求を判定する。実施例として、コントローラ2700が、475名のユーザが特定の時間に参加するであろうと考える場合、その負荷に遭遇する際には、リソースが既に割り当てられており、ユーザが遅延を認識できないように、それらのリソースの割り当てを5秒早く開始可能である。
【0082】
第2に、リソースは、オペレータからの入力に基づいて、事前に割り当て可能である。オペレータが、主要イベント、例えば、有料スポーツイベントが放送されることを既知の場合、見越して、リソースを事前に割り当てることを所望してもよい。両方の場合において、SRM2720は、非使用時およびイベント後、使用していないQAM2770リソースを解放する。
【0083】
第3に、QAM2770は、以前の履歴から独立した「変化率」に基づいて割り当て可能である。例えば、コントローラ2700が、トラフィックの突然の急増を認識する場合、付加的セッションを追加する際にQAM割り当てステップを回避するために、必要とされるものよりも多くのQAM帯域幅を要求可能である。突然の予想外の急増の例は、賞金が獲得され得ることを示すプログラムの一部としてのボタンをユーザが選択する場合である。
【0084】
現在、各セッションが追加される場合、SRM2720に対する要求は1つである。代わりに、コントローラ2700は、QAM2770全体または単一のQAMの帯域幅の大部分を要求し、本発明がそのQAMチャネル2775内のデータを取り扱うことを可能にし得る。本システムの一側面は、わずか1、2、または3Mb/秒のチャネルを生成する能力であるため、これは、最大27の要求を単一要求と置換することによって、SRM2720に対する要求数を低減可能である。
【0085】
また、ユーザは、既にアクティブセッション中にある場合であっても、異なるコンテンツを要求すると、遅延を経験するであろう。現在、セットトップ2790が、アクティブセッション中であって、新しい集合のコンテンツ2730を要求する場合、コントローラ2700は、SRM2720に、QAM2770の割り当てを解除するように指図する必要があり、次いで、コントローラ2700は、セッションプロセッサ2750およびコンテンツ2730の割り当てを解除しなければならず、次いで、SRM2720から別のQAM2770を要求し、次いで、異なるセッションプロセッサ2750およびコンテンツ2730を割り当てる。代わりに、コントローラ2700は、QAM変調器2770に供給している映像ストリーム2755を変更し、それによって、以前に確立されたパスを未変化のまま残すことが可能である。変更を達成するためのいくつかの方法が存在する。第1に、QAM変調器2770は、ネットワーク上に存在するので、コントローラ2700は、単に、QAM2770を駆動するセッションプロセッサ2750を変更可能である。第2に、コントローラ2700は、セッションプロセッサ2750からセットトップ2790への接続を未変化のまま残すが、セッションプロセッサ2750に供給するコンテンツ2730を変更することが可能である(例えば、「CNN Headline News」から「CNN World Now」)。これらの方法は両方とも、QAM初期化およびセットトップ同調遅延を排除する。
【0086】
したがって、リソースは、これらの双方向サービスを提供するために必要とされる機器の量を最小限にするように知的に管理される。特に、コントローラは、QAM2770に供給する映像ストリーム2755を操作可能である。これらのストリーム2755をプロファイリングすることによって、コントローラ2700は、QAM2770内のチャネル使用量を最大限にすることが可能である。すなわち、各QAMチャネル2775内のプログラム数を最大限にし、無駄な帯域幅およびQAM2770の必要数を低減可能である。ストリームをプロファイリングするための3つの主要手段が存在する(定式、事前プロファイリング、およびライブフィードバック)。
【0087】
第1のプロファイリング方法は、QAMチャネル2775を充填するために使用される種々の映像ストリームのビットレートを加算することから成る、定式である。特に、単一映像ストリーム2755を生成するために使用される多くの映像要素が存在する場合がある。各要素の最大ビットレートが合算されることにより、映像ストリーム2755に対する総計ビットレートを取得可能である。全映像ストリーム2755のビットレートを監視することによって、コントローラ2700は、最も効率的にQAMチャネル2775を使用する映像ストリーム2755の組み合わせを生成可能である。例えば、4つの映像ストリーム2755(2つは、16Mb/秒、2つは、20Mb/秒)が存在する場合、コントローラは、各チャネル当たりビットレートのうちの1つを割り当てることによって、38.8Mb/秒QAMチャネル2775を最良に充填可能である。次いで、これは、映像を配信するために、2つのQAMチャネル2775を必要とする。しかしながら、定式プロファイリングを伴わない場合、恐らく、2つの16Mb/秒映像ストリーム2755は、単一の38.8Mb/秒QAMチャネル2775に結合され、次いで、各20Mb/秒映像ストリーム2755は、その独自の38.8Mb/秒QAMチャネル2775を有さなければならないため、3つのQAMチャネル2775の結果となり得る。
【0088】
第2の方法は、事前プロファイリングである。本方法では、コンテンツ2730に対するプロファイルは、受信または内部生成される。プロファイル情報は、ストリームとともにメタデータに、または別個のファイルに、提供可能である。プロファイリング情報は、映像全体から、または代表的サンプルから生成可能である。次いで、コントローラ2700は、ストリーム内の種々の時間におけるビットレートを認知し、本情報を使用して、効果的に映像ストリーム2755を結合可能である。例えば、2つの映像ストリーム2755が両方とも、20Mb/秒のピークレートを有した場合、そのピークに基づいて割り当てられる帯域幅であるなら、異なる38.8Mb/秒QAMチャネル2775に割り当てられる必要があるであろう。しかしながら、コントローラが、公称ビットレートが14Mb/秒であることを既知であって、かつそのそれぞれのプロファイルを既知であって、したがって、同時ピークが存在しない場合、コントローラ2700は、ストリーム2755を単一の38.8Mb/秒QAMチャネル2775に結合可能である。特定のQAMビットレートは、上述の実施例のみに対して使用され、限定として解釈されるべきではない。
【0089】
プロファイリングのための第3の方法は、システムによって提供されるフィードバックを介する。システムは、コントローラ2700に、ストリームを構築するために使用される全映像要素に対する現在のビットレート、および構築後のストリームの総計ビットレートを通知可能である。さらに、システムは、コントローラ2700に、保存された要素のビットレートをその使用に先立って通知可能である。本情報を使用して、コントローラ2700は、QAMチャネル2775を充填するための最も効率的態様で映像ストリーム2755を結合可能である。
【0090】
また、3つのプロファイリング方法のいずれかまたはすべてを組み合わせて使用することも容認可能であることに留意されたい。すなわち、これら方法が個別に使用されなければならないという制限はない。
【0091】
また、システムは、リソース自体の使用量に対処可能である。例えば、セッションプロセッサ2750が100名のユーザをサポート可能であって、現在、350名のアクティブなユーザが存在する場合、4つのセッションプロセッサを必要とする。しかしながら、需要が、例えば、80名のユーザに低下すると、それらのリソースを単一のセッションプロセッサ2750に再割り当てし、それによって、3つのセッションプロセッサの残りのリソースを節約することは理にかなうであろう。また、これは、故障の状況において有用である。リソースが故障する場合、本発明は、セッションを、利用可能な他のリソースに再割り当て可能である。このように、ユーザへの途絶が最小限にされる。
【0092】
また、システムは、予想される使用量に応じて、機能を他の目的に転用可能である。セッションプロセッサ2750は、いくつかの異なる機能、例えば、映像の処理、音声の処理等を実装可能である。コントローラ2700は、使用量の履歴を有するため、セッションプロセッサ2700上の機能を調節し、予測される需要を満たすことが可能である。例えば、昼下がりに、典型的に、音楽に対する需要が高い場合、コントローラ2700は、需要を見越して、付加的セッションプロセッサ2750を再割り当てし、音楽を処理可能である。相応して、夕方に、ニュースに対する需要が高い場合、コントローラ2700は、需要を見越して、セッションプロセッサ2750を適宜再割り当てする。システムの柔軟性および予測は、最小量の機器で最適なユーザ経験を提供可能にする。すなわち、機器は、単一の目的のみを有し、その目的は要求されるのではないため、アイドル状態の機器は存在しない。
【0093】
図28は、非管理IPネットワークを通して加入者に双方向コンテンツを提供することができる、管理された放送コンテンツ衛星ネットワークを示す。被管理ネットワークは、伝送されるコンテンツがサービスプロバイダによってのみ決定され、エンドユーザによっては決定されない通信ネットワークである。したがって、サービスプロバイダが、提示されるコンテンツに対する運営管理上の制御を有する。この定義は、物理的な相互接続とは無関係であり、論理的関連である。実際、両方のネットワークが同一物理リンク上で動作してもよい。被管理ネットワークでは、ユーザは、サービスプロバイダによって放送される複数のチャネルからあるチャネルを選択することができるが、全体のコンテンツはサービスプロバイダによって決定され、ユーザはネットワーク外の他のいずれのコンテンツにもアクセスすることができない。被管理ネットワークは、閉鎖型ネットワークである。非被管理ネットワークは、ユーザがサービスプロバイダ以外の団体にコンテンツを要求し、コンテンツを受信することを可能にする。例えば、インターネットは非被管理ネットワークであり、インターネットと通信中のユーザは、複数のソースのうちの1つからのコンテンツを受信するように選択することができ、インターネットサービスプロバイダ(ISP)によって提供されるコンテンツによって限定されない。被管理ネットワークは、例えば、衛星ネットワーク、ケーブルネットワーク、およびIPテレビネットワークであってもよい。
【0094】
図28に示されるように、放送コンテンツは、被管理ネットワーク局2801によって1つ以上の指定されたチャネル上で衛星2800にアップロードされる。チャネルは、別個の周波数であってもよく、あるいはチャネルは、デリミタ(すなわち、ヘッダ情報)によってまとめて関係付けられるデータの関連であってもよい。受信衛星2800は、加入者によって選択され得る複数のチャネルを含む放送コンテンツを再伝送する。加入者宅の衛星受信機2802は伝送を受信し、セットトップボックス等のクライアントデバイス2803にその伝送を転送する。クライアントデバイスは衛星伝送を復号化し、加入者の表示デバイス2804上での視聴のために、選択されたチャネルを提供する。
【0095】
放送された伝送の放送コンテンツ内には、1つ以上のトリガが存在する。トリガは、可能な双方向コンテンツの指示子である。例えば、トリガには、放送コンテンツ内に挿入されるか、または放送コンテンツを含有するフレームの一部であるかのいずれかである広告が付随してもよい。トリガは、1つ以上の映像フレームと関連付けられてもよく、1つ以上の映像フレームに対するヘッダ内に埋め込まれてもよく、アナログ伝送信号の一部であってもよく、または、放送コンテンツが伝送されるメディアに依存して、デジタルデータの一部であってもよい。広告に応答して、ユーザはリモコン等のユーザ入力デバイス(図示せず)を使用して、その広告に関係する双方向コンテンツを要求してもよい。他の実施形態において、トリガは自動的に双方向セッションを開始させ、コンテンツを受信するためのネットワークを被管理ネットワークと非被管理ネットワークとの間で切り替えさせる。それに応じて、クライアントデバイス2803は、衛星ネットワーク2800からの放送コンテンツ2805の受信と、インターネット等の非被管理ネットワーク2806を介したコンテンツの受信および伝送とを切り替える。クライアントデバイスは、被管理ネットワークからの伝送を受信および復号化する単一のボックスを含んでもよく、また、非被管理ネットワークとの双方向通信も含んでもよい。したがって、クライアントデバイスは、2つの別個の受信機と、少なくとも1つの送信機とを含んでもよい。クライアントデバイスは、被管理ネットワークおよび非被管理ネットワークの両方に共有される単一プロセッサを有してもよく、またはクライアントデバイス内に別個のプロセッサがあってもよい。ソフトウェアモジュールが、2つのネットワーク間の切り替えを制御する。
【0096】
このように、ソフトウェアモジュールは、両方のネットワークと通信する中心的な構成要素である。代替の実施形態では、2つのボックスが通信チャネルを含む、別個のクライアント復号化ボックスが、被管理ネットワークおよび非被管理ネットワークに利用されてもよい。例えば、2つのボックスは、IPまたはUDPプロトコルを介して通信してもよく、ここで、第1のボックスが第2のボックスに割り込みを送信するか、または出力抑制信号を送信してもよい。ボックスには、いつポート同士が接続され、2つのボックスともが接続を調整するかを認識する、ディスカバリエージェントを提供してもよい。通信チャネルは、2つのボックスが、ボックスの出力を切り替えることができるように通信することを可能にする。したがって、各ボックスは、ボックスがコマンドを送信し、もう一方のボックスの少なくとも出力ポートを制御することを可能にする、共通の通信プロトコルを使用して動作する。衛星ベースのシステムに関する本実施形態の説明は、例示目的であるに過ぎず、この説明は、被管理ネットワークおよび非被管理ネットワークの両方を含む実施形態に容易に適用され得ることを認識されたい。
【0097】
ユーザが、クライアントデバイス2802に伝送を送信することによって双方向コンテンツを要求すると、クライアントデバイス2802はトリガを抽出し、非被管理ネットワークを通して処理局2810にトリガを伝送する。処理局2810は、ルックアップテーブル内の双方向コンテンツに関連するインターネットアドレスの検索か、クライアントデバイスから受信された伝送からのインターネットアドレスの抽出のいずれかを行なう。処理局は、インターネット2830を通して適切なコンテンツサーバ2820に要求を転送する。双方向コンテンツは処理局2810に戻され、処理局2810は、クライアントデバイス2803と互換性のある形式になるように双方向コンテンツを処理する。例えば、処理局2810は、上記で論議されたようなMPEG映像ストリームとしてのそのコンテンツのステッチングをスケーリングすることによって、トランスコーディングを符号化してもよい。映像ストリームはその後、一連のIPパケットとして非被管理ネットワーク2806を介して処理局2810からクライアントデバイス2803へと伝送することができる。そのような実施形態では、クライアントデバイス2802は衛星デコーダを含み、また、非管理IPネットワークを介して通信を送信および受信するためのポートも含む。要求された双方向コンテンツがクライアントデバイス2803によって受信されると、クライアントデバイスは、衛星放送チャネルの出力と、非被管理ネットワークを介して受信された双方向コンテンツの出力とを切り替えることができる。ある実施形態では、音声コンテンツは引き続き衛星伝送によって受信され、映像のみが衛星通信チャネルとIP通信チャネルとの間で切り替えられてもよい。衛星伝送からの音声チャネルは、非管理IPネットワークを通して受信される映像と混合される。他の実施形態において、音声および映像の両方の信号が、被管理ネットワークと非被管理ネットワークとの間で切り替えられる。
【0098】
当業者には、トリガが広告に限定される必要はなく、他の形態の双方向コンテンツと関係し得ることを認識されたい。例えば、放送される伝送は、スポーツイベントを競技しているチームの統計に関する双方向コンテンツのユーザによる読み出しを可能にする、スポーツイベント中のトリガを含んでもよい。
【0099】
いくつかの実施形態では、トリガが伝送内で識別されると、双方向セッションが自動的に確立され、上述のように2つ以上のソースからの双方向コンテンツがともにマージされる。次いで、双方向コンテンツが通信ネットワークを通してクライアントデバイスに提供され、復号化される。したがって、ユーザは、双方向セッションが確立される前にクライアントデバイスへの入力を提供する必要はない。
【0100】
ある実施形態では、クライアントデバイスは、被管理ネットワークおよび非被管理ネットワークの両方からコンテンツを受信してもよく、一方からの情報をもう一方からの情報と置換してもよい。例えば、放送コンテンツは、広告用の識別可能な挿入ポイント(例えば、タイムコード、ヘッダ情報等)とともに被管理ネットワークを介して伝送されてもよい。放送コンテンツは挿入ポイントに広告を含有してもよく、クライアントデバイスは、放送される広告を被管理ネットワークを介して伝送される広告と置換することができ、ここで、クライアントデバイスは、被管理ネットワークと非被管理ネットワークとを広告の時間の間切り替える。
【0101】
図29は、クライアントデバイス2902が被管理ネットワーク2900を通して放送コンテンツを受信し、かつ、非被管理ネットワーク2901を通して双方向コンテンツが要求および提供される、別の環境を示す。本実施形態では、処理局2910は、ケーブルシステム2900を介して放送コンテンツを配信する。放送コンテンツは、複数の放送プログラムのうちの1つの選択に備えるセットトップボックス2902との対話に基づいて、ユーザによって選択可能である。放送プログラムのうちの1つ以上が、放送内(すなわち、放送と関連付けられるヘッダ内、デジタルデータ内、またはアナログ信号内)にトリガを含む。クライアントデバイス2910が放送信号を受信し、選択された放送コンテンツを出力すると、クライアントデバイス2902上で実行中のプログラムはトリガを識別し、一時バッファにトリガを保存する。放送プログラムの進行につれてトリガが変化する場合、クライアントデバイスはバッファを更新する。例えば、トリガは時間的有効期限を有してもよい。トリガは、映像コンテンツからのいくつかの映像フレームと関連付けられてもよく、したがって、時間的に制限され得る。他の実施形態において、トリガは処理局に送信され、そこで保存されてもよい。そのような実施形態では、各放送チャネルに対するトリガのうちの1つのコピーのみを保存する必要がある。
【0102】
ユーザは、クライアントデバイス2902と通信するユーザ入力デバイス(すなわち、リモコン)を使用して、双方向コンテンツを要求してもよい。例えば、クライアントデバイスは、セットトップボックス、メディアゲートウェイ、またはビデオゲームシステムであってもよい。クライアントデバイスが要求を受信すると、クライアントデバイスは、トリガを保持する一時バッファにアクセスすることにより、その要求と関連付けられたトリガを識別する。トリガは単に、非被管理ネットワーク2901を通して処理局2910にアップストリーム転送される識別子であってもよく、あるいはトリガは、ルーティング情報(すなわち、IPアドレス)を含有してもよい。クライアントデバイス2902は、クライアントデバイスの識別子とともにトリガを処理局に伝送する。処理局2910は双方向コンテンツのための要求を受信し、トリガ識別子を使用して、IPアドレスのリストを含有するルックアップテーブルにアクセスするか、または、処理局がインターネット2930を通してコンテンツサーバ2920に位置する双方向コンテンツをIPアドレスに要求するかのいずれかを行う。クライアントデバイスと処理局との間で連結される非被管理ネットワークは、インターネットの一部とみなされてもよい。双方向コンテンツは、インターネット上のサーバまたはコンテンツサーバのいずれかから処理局に送信される。処理局は、双方向コンテンツをクライアントデバイスと互換性のある形式に処理する。双方向コンテンツは、MPEG映像ストリームに変換されて、処理局からクライアントデバイスへと複数のIPパケットとしてダウンストリーム送信されてもよい。MPEG映像ストリームはMPEGに準拠し、標準的なMPEGデコーダによって容易に復号化可能である。双方向コンテンツは1つ以上のソースから発生してもよく、コンテンツは、一連の映像フレームを形成するために再フォーマットされ、スケーリングされ、およびステッチングしてまとめられてもよい。双方向コンテンツは、静止要素、動的要素、ならびに静止要素および動的要素の両方を、双方向コンテンツを構成する1つ以上の映像フレーム内に含んでもよい。クライアントデバイス2902が双方向コンテンツを受信すると、クライアントデバイスは、被管理ネットワークから受信されている放送コンテンツを、非被管理ネットワークからの双方向コンテンツの受信へと切り替える。クライアントデバイス2902は受信された双方向コンテンツを復号化し、ユーザは、双方向コンテンツと対話することができ、処理局が、クライアントデバイスからコンテンツにおける変更に対する要求を受信する。要求に応答して、処理局はコンテンツを読み出し、コンテンツを映像ストリームとして符号化し、非被管理ネットワークを介してクライアントデバイスにコンテンツを送信する。
【0103】
他の実施形態において、双方向セッションに対する要求を生じさせるトリガは、放送コンテンツの外部で生じてもよい。例えば、要求は、ユーザのリモコン等の入力デバイスとの対話に応答してもたらされてもよい。リモコンによって生成された信号はクライアントデバイスに送信され、クライアントデバイスは、被管理ネットワークを介した放送コンテンツの受信を、非被管理ネットワークを介した双方向セッションに対する要求を行うことへと切り替えることによって応答する。双方向セッションに対する要求は、通信ネットワークを介して処理局に伝送される。処理局はプロセッサを割り当て、プロセッサとクライアントデバイスとの間で接続が調整される。クライアントデバイスは、セットトップボックス、メディアゲートウェイ、消費者電子デバイス、または、インターネット等のネットワークを通して遠隔制御信号を伝送し、標準的なMPEG符号化された映像ストリームを受信および復号化することができる他のデバイスであってもよい。処理局のプロセッサは、2つ以上のソースから双方向コンテンツを収集する。例えば、MPEGオブジェクトを含むAVMLテンプレートを使用してもよく、MPEG映像コンテンツは、ローカルに保存されたソース、またはネットワーク接続を通して到達可能であるソースから読み出されてもよい。例えば、ネットワークはIPネットワークであってもよく、MPEG映像コンテンツは、インターネット内のサーバ上に保存されてもよい。割り当てられたプロセッサは、双方向コンテンツをステッチングしてまとめさせる。次いで、ステッチされたコンテンツは、ネットワーク接続を介してクライアントデバイスに伝送され、クライアントデバイスは、復号化して、復号化されたコンテンツを表示デバイスに提示する。
【0104】
一実施例として、外付け式または内蔵型QAMチューナを含むテレビは、ケーブルテレビ放送信号を受信する。ケーブルテレビ放送信号は、1つ以上のトリガを含むか、あるいはユーザが入力デバイスを使用して要求信号を生成する。テレビは、ケーブルテレビ放送信号の復号化中にトリガを解析するか、または入力デバイスから要求を受信するかのいずれかを行い、その結果、インターネット(非被管理ネットワーク)に連結されるIPデバイスへの信号を生成させる。テレビは、ディスプレイへのケーブルテレビ放送信号の出力を抑制する。IPデバイスは、インターネット接続上に位置する処理局との双方向セッションを要求することによって、トリガまたは要求信号に応答する、別個の外付けボックスであるか、またはテレビに内蔵型であってもよい。プロセッサが処理局によって割り当てられ、IPデバイスと割り当てられたプロセッサとの間で接続が調整される。割り当てられたプロセッサは、2つ以上のソースから双方向コンテンツを生成し、MPEG基本ストリームを生成する。MPEG基本ストリームは、IPデバイスに伝送される。次いで、IPデバイスがMPEG基本ストリームをテレビに出力し、テレビは、双方向コンテンツを復号化し、テレビのディスプレイに提示する。入力デバイスとのユーザによるさらなる対話に応答して、割り当てられたプロセッサによって、基本ストリームへの更新が達成され得る。ユーザがテレビ放送コンテンツに戻ることを決定するか、または双方向コンテンツが終了すると、テレビは、テレビコンテンツ放送信号の抑制を中止し、テレビ放送信号を復号化し、ディスプレイに提示する。したがって、システムは、トリガまたは要求信号の結果として、被管理ネットワークと非被管理ネットワークとの間で切り替え、ここで、双方向コンテンツ信号が、テレビから遠隔の場所で2つ以上のソースから生成される
当業者には、前述の実施形態が、衛星テレビシステムおよびケーブルテレビシステムに制限されず、本実施形態は、電話システムを使用するIPTVネットワーク等のIPTVネットワークにも等しく適用可能であることを認識されたい。そのような実施形態では、IPTVネットワークが被管理ネットワークになり、非被管理ネットワークはインターネットへの接続(例えば、DSLモデム、無線インターネットネットワーク接続、Ethernet(登録商標)インターネット接続)となる。
【0105】
本発明は、多くの異なる形態で具現化されてもよく、プロセッサ(例えば、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、または汎用コンピュータ)と併用するためのコンピュータプログラム論理、プログラマブル論理デバイス(例えば、フィールド・プログラマブル・ゲート・アレイ(FPGA)または他のPLD)と併用するためのプログラマブル論理、個別の部品、集積回路(例えば、特定用途向け集積回路(ASIC))、あるいはそれらの任意の組み合わせを含む任意の他の手段を含むが、それらに決して限定されない。本発明の一実施形態では、主に、並べ換え論理はすべて、コンピュータ可読メディア内等に保存されるコンピュータ実行可能形態に変換され、かつ、オペレーティングシステムの制御下のアレイ内のマイクロプロセッサによって実行される、一式のコンピュータプログラム命令として実装されてもよい。
【0106】
本明細書に前述した機能の全部または一部を実装するコンピュータプログラム論理は、種々の形態で具現化されてもよく、ソースコード形態、コンピュータ実行可能形態、および種々の中間形態(例えば、アセンブラ、コンパイラ、ネットワーカー、またはロケータによって生成される形態)を含むが、それらに決して限定されない。ソースコードは、種々のオペレーティングシステムまたはオペレーティング環境と併用するための種々のプログラミング言語(例えば、オブジェクトコード、アセンブリ言語、あるいはFORTRAN、C、C++、JAVA(登録商標)、またはHTML等の高水準言語)のいずれかに実装される一連のコンピュータプログラム命令を含んでもよい。ソースコードは、種々のデータ構造および通信メッセージを定義および使用してもよい。ソースコードは、コンピュータ実行可能形態(例えば、インタプリタを介して)であってもよく、あるいはソースコードは、(例えば、トランスレータ、アセンブラ、またはコンパイラを介して)コンピュータ実行可能形態に変換されてもよい。
【0107】
コンピュータプログラムは、半導体メモリデバイス(例えば、RAM、ROM、PROM、EEPROM、またはフラッシュプログラマブルRAM)、磁気メモリデバイス(例えば、ディスケットまたは固定ディスク)、光学メモリデバイス(例えば、CD−ROM)、PCカード(例えば、PCMCIAカード)、あるいは他のメモリデバイス等の有形記憶媒体内に永久もしくは一時的に、任意の形態(例えば、ソースコード形態、コンピュータ実行可能形態、または中間形態)で固定されてもよい。コンピュータプログラムは、種々の通信技術のいずれかを使用して、コンピュータに伝送可能な信号中に、任意の形態で固定されてもよく、アナログ技術、デジタル技術、光技術、無線技術、ネットワーク技術、およびネットワーク間通信技術を含むが、それらに決して限定されない。コンピュータプログラムは、付随の印刷されたまたは電子ドキュメント付きのリムーバブル記憶媒体(例えば、パッケージソフトウェアまたは磁気テープ)として任意の形態で配信されるか、コンピュータシステム(例えば、システムROMまたは固定ディスク上)にプリインストールされるか、あるいは通信システム(例えば、インターネットまたはワールドワイドウェブ)を介してサーバまたは電子掲示板から配信されてもよい。
【0108】
本明細書に前述した機能の全部または一部を実装するハードウェア論理(プログラマブル論理デバイスと併用するためのプログラマブル論理を含む)は、従来の手動方法を使用して設計されてもよく、あるいは、コンピュータ支援設計(CAD)、ハードウェア記述言語(例えば、VHDLまたはAHDL)、またはPLDプログラミング言語(例えば、PALASM、ABEL、またはCUPL)等の種々のツールを使用して、設計、キャプチャ、シミュレーション、もしくは電子的に文書化されてもよい。
【0109】
本発明は、特に、特定の実施形態を参照して、図示および説明されたが、当業者は、添付の請求項によって規定されるように、本発明の意向および範囲から逸脱することなく、形態および詳細における種々の変更が実施形態において成され得ることを理解するであろう。当業者には明白であるように、パノラマに対する上述の技術は、非パノラマ画像としてキャプチャされた画像に適用されてもよく、その逆も然りである。
【0110】
本発明の実施形態は、限定することなく、以下の請求項によって説明され得る。これらの実施形態は、プロセスステップによって、請求項に説明されたが、また、以下の請求項におけるプロセスステップを実行可能な、関連付けられたディスプレイを有するコンピュータを備える装置も、本発明に含まれる。同様に、以下の請求項におけるプロセスステップを実行するためのコンピュータ実行可能命令を含み、コンピュータ可読メディア上に保存される、コンピュータプログラム製品も、本発明内に含まれる。