JP2001500692A - デジタルスタジオの指令及び制御アーキテクチャー - Google Patents

Abstract

(57)【要約】 圧縮されたデジタルテレビジョン放送スタジオ（１００）のための指令及び制御アーキテクチャー。このアーキテクチャーはセッション管理、スタジオ動作のリアルタイム制御、ハイレベルな制御を与えないオブジェクトと通信を確立するプロキシオブジェクトの使用、スタジオフィルタデバイス（１５４）の制御及びストリーム管理のための設備を含む。この発明にはデジタルスタジオに特に適したオブジェクトアーキテクチャーが含まれる。

Description

【発明の詳細な説明】 デジタルスタジオの指令及び制御アーキテクチャー 契約Ｎｏ．７０ＮＡＮＢ５Ｈ１１７４に基づく政府支援を得てこの発明がなされ た。政府はこの発明に関する権利を有する。 関連出願のクロス・リファレンス ３５Ｕ．Ｓ．Ｃ．１１１（ａ）に基づき出願されたこの正規な（ｎｏｎ−ｐｒ ｏｖｉｓｉｏｎａｌ）Ｕ．Ｓ．国内出願は、３５Ｕ．Ｓ．Ｃ．１１１（ｂ）に基 づき１９９６年９月１３日に出願された仮の（ｐｒｏｖｉｓｉｏｎａｌ）Ｕ．Ｓ ．出願Ｎｏ．６０／０２６，０５６の出願期日の恵益を、３５Ｕ．Ｓ．Ｃ．１１ ９（ｅ）に基づき権利主張する。 技術分野 本発明は指令及び制御アーキテクチャーに関し、より詳細には、デジタルテレ ビジョン放送スタジオ内のデジタルビットストリーム管理のための指令及び制御 アーキテクチャー並びに付随した方法に関する。 背景技術 デジタル情報の拡散が“デジタルスタジオ（ｄｉｇｉｔａｌ ｓｔｕｄｉｏ） ”の概念を用いた新たなＨＤＴＶ（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｔｅｌｅ ｖｉｓｉｏｎ：高画質テレビジョン）産業を創出した。 簡略に述べれば、デジタルスタジオとは、多数の構成要素を含む環境又はシステ ムであって、そこでは多数のクライアントが様々なデジタル情報のソースに対し （リアルタイムに又はディレイモードで）選択的にアクセスして操作できる。例 えば、カスタマが“ライブ（ｌｉｖｅ）”放送の辺りの映画を予約して、この映 画をプロバイダによりカスタマのテレビへ特定の時間に送らせ、“ライブ（ｌｉ ｖｅ）”放送を送るときには 映画を休止させておいて、中断箇所から映画を再開させるようにすることができ る。またデジタル情報を圧縮したビットストリームに変換することがしばしば行 われていて、待ち時間やデータレート条件等の問題を生じている。このため、様 々なデジタルスタジオ構成要素を統合する必要があり、そのための指令及び制御 アーキテクチャーはユニークなチャレンジを提供する。 現在、デジタル格納メディア指令及び制御（ＤＳＭ−ＣＣ：Ｄｉｇｉｔａｌ Ｓｔｏｒａｇｅ Ｍｅｄｉａ Ｃｏｍｍａｎｄ ａｎｄ Ｃｏｎｔｒｏｌ）アー キテクチャー（ＩＳＯ／ＩＥＣ １３８１８−６、参照により本書の一部となす ）があり、これはＩＳＯ／ＩＥＣ １１１７２ 動画像技術者グループ（ＭＰＥ Ｇ−１：Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅｓ ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）及び ＩＳＯ／ＩＥＣ １３８１８（ＭＰＥＧ−２）ビットストリームの機能及び操作 を管理するプロトコル集の仕様になっている。より詳細に述べれば、ＤＳＭ−Ｃ Ｃプロトコル集はサーバからクライアント、例えば、セット・トップボックスに ＭＰＥＧビデオストリームを送るシステムアーキテクチャーへ指令及び制御を与 えるため、特別に設計されている。しかしながら、デジタルテレビジョン放送ス タジオの数々の構成要素が分配制御下に置かれることを想定すれば、現在のＤＳ Ｍ−ＣＣプロトコル集はデジタルスタジオに将来求められる自在性及び特徴に欠 けている。 発明の開示 圧縮されたデジタルテレビジョン放送スタジオのための指令及び制御アーキテ クチャー。このアーキテクチャーはセッション管理、スタジオ動作のリアルタイ ム制御、ハイレベルな制御を与えないオブジェクトと通信を確立するプロキシオ ブジェクトの使用、スタジオフィルタデバイスの制御及びストリーム管理のため の設備を含む。この発明にはデジタルスタジオに特に適したオブジェクトアーキ テクチャーが含まれる。 図面の簡単な説明 本発明の教示内容は次の詳細な説明を添付図面に絡めて考慮することにより容 易に理解でき、添付図面中： 図１はデジタルスタジオのブロック図を示し； 図２はデジタルスタジオの一態様の詳細ブロック図を示し； 図３はデジタルスタジオ内のデバイス又は構成要素に対するスタジオクラス階 層（スタジオオブジェクト界）の実施形態をグラフィックに示す図であり； 図４はスタジオオブジェクトディレクトリ構造を示し； 図５はプロキシ制御デバイスを含むスタジオのＤＳ−ＣＣダイアローグをグラ フィックに示す図であり； 図６は図５に示すＤＳ−ＣＣダイアローグのタイミング図であり； 図７は２つのプロキシ制御デバイスを含むスタジオのＤＳ−ＣＣダイアローグ をグラフィックに示す図であり； 図８は図７に示すＤＳ−ＣＣダイアローグのタイミング図であり； 図９はビデオストリームがトランスコーダフィルタを通るＤＳ−ＣＣダイアロ ーグをグラフィックに示す図であり； 図１０は図９に示すＤＳ−ＣＣダイアローグのタイミング図であり； 図１１はスイッチャに接続された２つのサーバを含むスタジオのＤＳ−ＣＣダ イアローグをグラフィックに示す図であり； 図１２は図１１に示すＤＳ−ＣＣダイアローグのタイミング図であり； 図１３はビデオをサーバからクライアントへ格納するＤＳ−ＣＣダイアローグ をグラフィックに示す図であり； 図１４は図１３に示すＤＳ−ＣＣダイアローグのタイミング図であり； 図１５はＤＳ−ＣＣダイアローグをグラフィックに示す図で、多数受信者及び 共用クライアントへのビデオの分配を示し； 図１６は図１５に示すＤＳ−ＣＣダイアローグのタイミング図であ り；そして 図１７は図１５に示すＤＳ−ＣＣダイアローグのタイミング図の他の実施形態 である。 発明を実施するための最良の形態 本発明は、それに限定はしないが、図１に示すようなデジタルスタジオのセッ ション管理、リアルタイム制御、プロキシデバイス制御及びストリーム管理を含 む事項をアドレスする指令及び制御アーキテクチャーを提供する。 図１はスタジオデータルータ１２０、複数のサーバ１１０、複数の放送／分配 デバイスもしくはネットワーク１４０、複数の入出力デバイス及び複数のクライ アント１３０からなるデジタルスタジオ１００のブロック図を示す。デジタルス タジオ１００は様々なスタジオ資源にたいする選択的なアクセス及び／又は制御 をクライアント１３０に許容し、その際クライアントにはセットトップボックス 、コンピュータ又は格納デバイスを含めてよいが、これに限定しない。実際、デ ジタルスタジオは分配制御下におかれると想定しており、他のスタジオ構成要素 、例えば、デジタルスタジオの各種サーバもクライアントとしての立場にたち得 る。 デジタルスタジオシステム構成要素は、スタジオデータルータ１２０と呼ばれ るセントラルスイッチを介して物理的に相互に接続される。スタジオデータルー タ１２０はデジタルスタジオを通るビデオストリームを処理し、指令及び制御サ ービス等のサービス供与も行う。 スタジオ構成要素には放送／分配デバイスもしくはネットワーク１４０を含め てよく、これにはサテライト分配ネットワーク、放送ネットワークもしくはロー カルな“ライブ・フィード”ネットワーク及び多量の格納されたデジタル情報を 含む各種サーバ１１０を含めてよいが、それに限定しない。またスタジオ構成要 素にはモニタ１５２及び各種フィルタ１５４、例えば、トランスコーダ、コンバ ータ、コーデック、インターフェースデバイス及びスイッチャ等を含めてよい。 そうした様々なス タジオ構成要素の各々は所要ハードウエア（例えば、１つ以上のプロセッサ、コ ンピュータ又はワークステーション）を取り入れて、ソフトウェアルーチンもし くはオブジェクトを格納もしくは実行してよい。実際、諸種のスタジオ構成要素 は、その間で、他の直接的な信号接続要素（図示せず）を取り入れ、相互に直接 通信を行える。 上記デジタルスタジオ及びこの指令及び制御アーキテクチャーで使用できる１ つのローレベルトランスポートプロトコルが非同期伝送モード（ＡＴＭ：Ａｓｙ ｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）で、これは単一ポイントへ 多数のデータストリームを与えるのに適している。ただし、当業者には、他の適 宜なローレベルトランスポートプロトコルを利用できることが分かる。そこで、 この明細書には、図１の環境又は他の、例えば図２に示すような、同等なデジタ ルスタジオの態様のための指令及び制御アーキテクチャーが開示されている。 このデジタルスタジオの指令及び制御アーキテクチャーは、ＨＤＴＶ圧縮ビッ トストリーム技術を用いる放送スタジオが、分配制御下にあるインテリゼント協 同システム資源／構成要素を含むであろうとの認識に基づいている。このように 、今日のスタジオ環境は、データがスタジオ構成要素間をフレーム同期的に移動 する“プレイ・リストマネジャ（ｐｌａｙ−ｌｉｓｔ ｍａｎａｇｅｒｓ）”に 基礎をおいた制御の階層をモデルとしているが、それに代わる本アーキテクチャ ーでは、スタジオビデオサーバ、ライブフィード、モニタ、トランスコーダ及び スイッチャがワークステーションユーザインターフェースを介してアクセスされ るソフトウェアオブジェクトの分配制御下にある。このオブジェクト界には、現 在のプレイ・リストマネジャに調和した機能を提供する“プレイリスト（Ｐｌａ ｙＬｉｓｔ）”クラスが含まれよう。この環境に好適なプログラミング例が、共 通オブジェクト要求ブローカアーキテクチャー（ＣＯＲＢＡ：Ｃｏｍｍｏｎ Ｏ ｂｊｅｃｔ Ｒｅｑｕｅｓｔ Ｂｒｏｋｅｒ Ａｒｃｈｉｔｅｃｔｕｒｅ）モデ ル等、分配オブジェクトを指向した計算の概念である。ＣＯＲＢＡの詳細な説明 については「分か るＣＯＲＢＡ（Ｕｎｄｅｒｓｔａｎｄｉｎｇ ＣＯＲＢＡ）」 （オットー外著、 プレンティスホールピーティーアール、１９９６刊）を参照されたい。 “デジタルスタジオ指令及び制御（Ｄｉｇｉｔａｌ Ｓｔｕｄｉｏ Ｃｏｍｍ ａｎｄ ａｎｄ Ｃｏｎｔｒｏｌ）”（以下ＤＳ−ＣＣ）と称するこの指令及び 制御アーキテクチャーは、ＤＳ−ＣＣがスタジオ環境を規定する点においてＤＳ Ｍ−ＣＣの改良である。特に、時間制御、記録その他スタジオに関係した条件及 び機能を規定すべくデータストリームが拡張されている。第２に、“プロキシ（ ｐｒｏｘｉｅｓ）”の概念を開示して、すべてのスタジオ構成要素をスタジオ指 令及び制御プロセスに関与させることできるようにしている。最後に、資源の管 理を拡張し、スタジオの規範内でストリーム管理に供されている構成要素（例え ば、トランスコーダ及びスイッチャ）を含めている。このように、この指令及び 制御アーキテクチャーはＤＳＭ−ＣＣプロトコールとの関係において説明される が、当業者にはそれに限定されないことが分かるであろう。 図３は、例えば、図２に示すようなデジタルスタジオ内のデバイス又は構成要 素に対するスタジオクラス階層５００（スタジオオブジェクト界）の実施形態を グラフィックに示す。クラスというのは、特定タイプのオブジェクトに対する手 法及び変数を定義するテンプレートである。 当業者には“オブジェクト（ｏｂｊｅｃｔ）”及び“クラス（ｃｌａｓｓ）”と いう用語がオブジェクト指向計算の範疇で使われていることが分かるであろう。 オブジェクトクラス階層のルーツ、即ち、（ＤＳＭ−ＣＣの用語でいう）“ネ ーミングコンテキスト（Ｎａｍｉｎｇ Ｃｏｎｔｅｘｔ）”はベースクラス５０ ５である。このベースクラスには、オブジェクトクラスである“デバイス（Ｄｅ ｖｉｃｅｓ）”５１０、“サーバ（Ｓｅｒｖｅｒｓ）”５２０、“スタジオ（ｓ ｔｕｄｉｏｓ）”５３０と、様々なソフトウェア資源５４０、例えば、プレイリ ストマネジャ（“プレイリストＭｇｒ（ＰｌａｙＬｉｓｔＭｇｒｓ）”）がある 。デバイスクラス は、ソース、フィルタ及びシンクという構成要素の３つの広義なカテゴリを含む 。より詳細には、デバイスクラス６１０が、“ライブフィード（ＬｉｖｅＦｅｅ ｄｓ）”５１２（ソース）、“フィルタ（Ｆｉｌｔｅｒｓ）”５１４及び“トラ ンスミッタ（Ｔｒａｎｓｍｉｔｔｅｒｓ）”（シンク）５１６のクラスを含み、 フィルタクラス５１４は“スイッチャ（Ｓｗｉｔｃｈｅｒｓ）”５１８及び“ト ランスコーダ（Ｔｒａｎｓｃｏｄｅｒｓ）”５１９のクラスを含む。同様に、サ ーバクラス５２０は“ＰＴＡサーバ（ＰＴＡＳｅｒｖｅｒｓ）”（プレイ・ツー ・エア（Ｐｌａｙ−ｔｏ−Ａｉｒ））５２２、“ネットワークサーバ（Ｎｅｔｗ ｏｒｋ Ｓｅｒｖｅｒ）”及び“ＰｒｏｄＰｒｏｇサーバ(ＰｒｏｄＰｒｏｇＳ ｅｒｖｅｒ)”(制作プログラムサーバ(Ｐｒｏｄｕｃｔｉｏｎ Ｐｒｏｇｒａｍ Ｓｅｒｖｅｒ))５２４を含む。最終的に、各クラスには、特定なスタジオデバ イスの個別な事例を定める数値的な定義、例えば、“ライブフィード−１（ｌｉ ｖｅＦｅｅｄｓ−１）”、“スイッチャ−１（Ｓｗｉｔｃｈｅｒｓ−１）”、“ トランスコーダ−１（Ｔｒａｎｓｃｏｄｅｒ−１）”、その他を含めてよい。 さらに、各クラスには、（新たなオブジェクトを創る“オブジェクトコンスト ラクタ（ｏｂｊｅｃｔ ｃｏｎｓｔｒｕｃｔｏｒ）”としても知られる）“ファ クトリ（ｆａｃｔｏｒｙ）”を設け、これを用いて対象となるクラスを生成し管 理する。例えば、デバイスクラス５１０には、“デバイスファクトリ（Ｄｅｖｉ ｃｅＦａｃｔｏｒｙ）”が在りデバイスオブジェクトを創出する設計になってい ると見立てる。こうしたクラスから派生するオブジェクトの場所には、図４に示 すようなスタジオ規模のディレクトリ構造６００を介してアクセスできる。 図４はゲートウェイサービスインターフェース６０５をルーツディレクトリと するスタジオオブジェクトディレクトリ構造６００を示す。ゲートウェイサービ スインターフェースはサービスのディレクトリを提供し、クライアントがサービ ス領域へアタッチできるようにする。一実施形態としては、ＤＳＭ−ＣＣサービ スゲートウェイがゲートウェイサー ビスインターフェースとなる。 ゲートウェイサービスインターフェース６０５には、“デバイス（Ｄｅｖｉｃ ｅｓ）”６１０、“サーバ（Ｓｅｒｖｅｒｓ）”６２０、“スタジオ（ｓｔｕｄ ｉｏｓ）”６３０及び“ソフトウェア資源（ｓｏｆｔｗａｒｅ Ｒｅｓｏｕｒｃ ｅｓ）”６４０（ＳＷ資源（ＳＷＲｅｓｏｕｒｃｅｓ）のクラスディレクトリが ある。このオブジェクト階層での安全性は、ＤＳＭ−ＣＣ内の安全規定を用いて 提供される。各クラスの一般的な特徴を以下に述べる。 “デバイス（Ｄｅｖｉｃｅｓ）”ディレクトリ６１０は他のオブジェクトによ り操作可能な（即ちアドレスできる）スタジオ内のすべての構成要素に対応する 。デバイスの幾つかの例としては、一般クラスの“ライブフィード（ＬｉｖｅＦ ｅｅｄｓ）”６１２、“フィルタ（Ｆｉｌｔｅｒｓ）”６１４、“トランスミッ タ（Ｔｒａｎｓｍｉｔｔｅｒｓ）”６１６及び“モニタ（Ｍｏｎｉｔｏｒｓ）” （図示せず）がある。そして、“ライブフィード（Ｌｉｖｅｆｅｅｄ）”ディレ クトリ６１２はサーバの自由を与えない場所から出ているビデオソースに対応す るクラスのオブジェクトを含む。ライブフィードの例は、カメラ、並びに別の場 所からのサテライトフィードである。概して、このクラスのオブジェクトは専ら 制限された制御機能性を持つであろう。 フィルタディレクトリ６１４は、ビデオストリームが流れるがエンドポイント とは考えないクラスのオブジェクトを含む。このフィルタの例には、トランスコ ーダ及びスイッチャが含まれ、それらのオブジェクトがそれぞれ“スイッチャ（ Ｓｗｉｔｃｈｅｒｓ）”ディレクトリ６１８及び“トランスコーダ（Ｔｒａｎｓ ｃｏｄｅｒｓ）”ディレクトリ６１９に含まれる。 “トランスコーダ（Ｔｒａｎｓｃｏｄｅｒｓ）”ディレクトリ６１９は、ビデ オストリームの特性、例えば、画像フレームレート又は画像アスペクト比を扱う クラスのオブジェクトを含む。“スイッチャ（Ｓｗｉｔｃｈｅｒｓ）”ディレク トリ６１８は幾つかのビデオストリームをソ ースとして取り上げ、そしてストリーム間のスイッチング（もしくはスプライシ ング）により、いずれの入力とも異なる出力ストリームを生成することができる 。 “トランスミッタ（Ｔｒａｎｓｍｉｔｔｅｒｓ）”ディレクトリ６１６はビデ オシンクに対応するクラスのオブジェクトを含む。トランスミッタの例には、放 送トランスミッタ及びサテライトトランスミッタが含まれるが、これに限らない 。 “モニタ（Ｍｏｎｉｔｏｒｓ）”ディレクトリ（図示せず）はスタジオモニタ に対応するクラスのオブジェクトを含む。これらは極めて一般的な資源であり、 多くのソフトウェア資源に用いられることになる。 “サーバ（Ｓｅｒｖｅｒｓ）”ディレクトリ６２０はスタジオ内でのスタジオ サーバの名称を含む。一例として、サーバディレクトリ６２０は、プレイツーエ アサーバ（“ＰＴＡサーバ（ＰＴＡＳｅｒｖｅｒ）”）６２２、ネットワークプ ログラムサーバ（“ＮＰＳサーバ（ＮＰＳｅｒｖｅｒ）”）及び制作プログラム サーバ（“ＰＰＳサーバ（ＮＰＳｅｒｖｅｒ）”）６２４の３つのサーバを含む 。これらのサーバはビデオオブジェクトを格納し、他のオブジェクトの要求に応 じて、要求場所へのビデオストリームの送出及び／又は格納を行う。 “スタジオ（ｓｔｕｄｉｏｓ）”ディレクトリ６３０はスタジオオブジェクト の名称を含む。各スタジオディレクトリには、そのローカルスタジオ自体に対応 する名称“ローカル（Ｌｏｃａｌ）”が含まれる。 “ＳＷ資源（ＳＷＲｅｓｏｕｒｃｅｓ）”ディレクトリ６４０は、スタジオ管 理のためにスタジオ環境内で使用されるオブジェクトクラスの名称を含む。そう したタイプのクラスの１つが“プレイリストＭｇｒ（ＰｌａｙＬｉｓｔＭｇｒｓ ）”クラスである。“プレイリストマネジャ（Ｐｌａｙ Ｌｉｓｔ Ｍａｎａｇ ｅｒｓ）”ディレクトリ６４２は特定タイプのプレイリスト、例えば、“プレイ リストＭｇｒ−１（ＰｌａｙＬｉｓｔＭｇｒ−１）”に対応するオブジェクトを 提供する。プレイリストＭｇｒオブジェクトとは、単一ストリームを提供すべく ビデオストリ ーム間での切り換え及び開始によりプレイリストを管理するオブジェクトである 。 つまり、図４はデジタルスタジオの異なる構成要素の機能が分配されているす べての異なるデジタルスタジオ構成要素のネーミングスペースと考えることがで きる。このように、ネーミングスペースを通ることは１つの構成要素から多の構 成要素へ物理的に移動することに等しい。 上述の指令及び制御アーキテクチャーはリアルタイムなストリーム制御に備え る。ＤＳ−ＣＣストリーム指令は、要求を受けたオブジェクトが指令を開始すべ き絶対時間を定める。例えば、ＤＳ−ＣＣ“プレイ（Ｐｌａｙ）”指令は“（何 時）にプレイ（ＰｌａｙＡｔ（時間））”で、時間は何等かのスタジオ正時（ｓ ｔｕｄｉｏ ａｃｃｕｒａｔｅ ｎｏｔｉｏｎ ｏｆ ｔｉｍｅ）に基づく。別 のＤＣ−ＣＣストリーム指令（例えば、停止、休止、その他）も、同様に事象の 絶対時間を規定すべく拡張できる。 本ＤＳ−ＣＣアーキテクチャーの詳細な説明を以下に図５−１７を参照して行 う。これらの図は、あるスタジオ内の異なる操作シナリオに対するＤＳ−ＣＣア ーキテクチャーの適用を示す。各シナリオに関連するタイムシーケンス図も付し 、操作の明瞭化を図る。図５、７、９、１１、１３、及び１５中、諸種ブロック の外側の表示が物理的なスタジオ構成要素を示し、それらのブロックの内側の表 示は概ねソフトウェアオブジェクトを表している点に留意されたい。 同様に、図６、８、１０、１２、１４、１６及び１７中、タイムシーケンス図 頂部の括弧（）内の表示が物理的なスタジオ構成要素を示し、それらの括弧（） の上側の表示は概ねソフトウェアオブジェクトを表している点に留意されたい。 また、影領域はユーザからネットワークへのダイアローグ及びＡＴＭ接続制御に 対応し、これはＩＴＵ−Ｔ勧告Ｑ．２３９１，アクセス信号用Ｂ−ＩＳＤＮアプ リケーションプロトコル（キーワードＱ．２９３１で表示）の規定による。エン ドポイントのある構成要素及び短い両矢印の付いたものがこのダイアローグに関 与する。ユ ーザツーユーザ（ＵＵ：Ｕｓｅｒ ｔｏ ｕｓｅｒ）ダイアローグは片側矢印で 示す。このダイアローグは別のユーザプロトコルエンティティのサービスを要求 するユーザプロトコルエンティティを表す。多分に、Ｃ＋＋形言語が使用される 。パスが多数の構成要素を通る場合には、最終の構成要素を指摘するだけでＵＵ ダイアローグのラインを示す。 スタジオ内のすべての構成要素が分配オブジェクト向けインターフェース、例 えば、ＣＯＲＢＡインタフェースの提供及び他スタジオのＣＯＲＢＡ的オブジェ クトとの通信ダイアローグへの参加を完全に行えるとは考えない。このハイレベ ルな制御を供与しない構成要素がある場合、本指令及び制御アーキテクチャーは “プロキシサーバ（ｐｒｏｘｙ ｓｅｒｖｅｒ）”オブジェクトを用いる。プロ キシサーバオブジェクト（又はプロキシオブジェクト）は、それが代表している 構成要素の代わりにスタジオ構成要素と通信するものである。その際、このオブ ジェクトは、インターネットエンジニアリングタスクフォース（ＩＥＴＦ：Ｉｎ ｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）の簡易ネット ワーク管理プロトコル（ＳＮＭＰ：Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇ ｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）又は所有通信プロトコル等のローレベル通信プ ロトコルを用いる構成要素と直接に通信する。プロキシオブジェクトはデジタル スタジオ内でのオープンアーキテクチャーを可能にする点で顕著である。 図５は、プロキシデバイス（トランスミッタ）７３０を制御するＤＳ−ＣＣダ イアローグの一例をブロック図で示す。トランスミッタ７３０のプロキシオブジ ェクト７１２がＰＴＡＳ（サーバ）７１０に示されている。このプロキシオブジ ェクト７１２は、ＰＴＡＳ（サーバ）７１０に存在するように示されているが、 それに限られない。図５は、むしろ、代表される物理的デバイスとは異なる他の スタジオ構成要素にそれが存在できるというソフトウェアの自在さを示している 。 プレイ・ツー・エア制御ワークステーション（ＰＴＡＣＷＳ：Ｐｌａｙ−ｔｏ −Ａｉｒ Ｃｏｎｔｒｏｌ Ｗｏｒｋｓｔａｔｉｏｎ）（サー バ）ソフトウェアクライアントオブジェクト７４２はプロキシオブジェクト７１ ２へアクセスし、次いでこれがトランスミッタ７３０とローレベルな通信路７５ ０、例えば、ＲＳ２３２ポートを介し、直接に通信を行う。実際のＡＴＭ接続は ビデオソース、ＰＴＡＳサーバ７１０と相手側、トランスミッタ７３０との間に 、ＤＳＭ−ＣＣで開示されるシステム資源マネジャ（ＳＲＭ：ｓｙｓｔｅｍ ｒ ｅｓｏｕｒｃｅ ｍａｎａｇｅｒ）を備えたルータ７２０を介して構築される。 ＳＲＭは、通常、ネットワークサービスに責任を持ち、例えば、スタジオ構成要 素間でバンド幅及び通信チャネルを設定し、あるいはネットワーク資源の管理（ 例えば、ネットワーク資源のスケジューリング）を行う。 図５に示されたシナリオのＤＳ−ＣＣタイムシーケンス図が図６にある。図６ はプロキシ構成要素のセッション管理のためのメソッド８００と見ることができ る。図６にはスタジオ構成要素（ＰＴＡＣＷＳ、ＰＴＡＳ、トランスミッタ及び ルータ／ネットワーク）間の相互作用が上から下へ進むタイムシーケンス図とし て示される。ＳＲＭはしばしば“ネットワーク（ｎｅｔｗｏｒｋ）”として参照 されており、このようにネットワークがルータ内に存在する点に留意されたい。 より詳細には、ステップ８０５で、クライアントがネットワークにセッション の開始を要求する。セッションは、２つのユーザ若しくはネットワークアプリケ ーション間の論理的関係、例えば、“オンライン（ｏｎｌｉｎｅ）”になるスタ ジオ構成要素を定める。 ステップ８１０で、クライアントがサービスゲートウェイにアタッチする。こ れはクライアントがスタジオ構成要素を使用するとの意図を表明していることを 示す。サービスゲートウェイはＤＳＭ−ＣＣで定義され、アクセスポイントと見 ることができる。 ステップ８１５で、図４のディレクトリ構造において説明したネーミングコン テキストを用いてトランスミッタの位置を出す。トランスミッタは“デバイスデ ィレクトリ／トランスミッタディレクトリ（Ｄｅｖｉｃｅｓ Ｄｉｒｅｃｔｏｒ ｙ／Ｔｒａｎｓｍｉｔｔｅｒｓ Ｄｉｒｅｃ ｔｏｒｙ）”を介して見つける。図４は分配されたネーミングコンテキストなの で、“オープン（Ｏｐｅｎ）”仕様が出たときは、所望オブジェクトの位置出し 前にメソッド８００で異なるポイントを通ってもよい。このように、プロキシト ランスミッタ７１２がＰＴＡＳに在ることから、ステップ８１５の矢印は最終的 にＰＴＡＳのサーバを指す。 またステップ８１５は（“ファインド（Ｆｉｎｄ）”を用いて）適宜なファク トリを見いだす操作からなる。このように、“オープン（Ｏｐｅｎ）”という用 語をステップ８１５で使用してはいるが、当業者にはそれが実際は“ファインド （Ｆｉｎｄ）”仕様であることが分かるであろう。 ステップ８２０では、メソッド８００のクライアントがトランスミッタを開き 、そのトランスミッタを代表するオブジェクト（プロキシオブジェクト）を受け 取る。トランスミッタ自体へアクセスするときには、“オープン（Ｏｐｅｎ）” 仕様がファクトリ要求となる、即ち、（“オープン（Ｏｐｅｎ）”を用いて）デ バイスの事例を創出する点に留意されたい。スタジオデバイス、つまりトランス ミッタ、を開くとき、メソッド８００は接続ポートを受け戻し、例えば、将来の 接続用にＶＣＩ／ＶＰＩを返す。つまり、メソッド８００のクライアントがスタ ジオデバイスを開いたとき、効果的にこのスタジオデバイスへのコントロールを 得る。このため、破線部により、プロキシオブジェクトと実デバイスとの間のロ ーレベルダイアローグが示されている。 ステップ８２５では、図４のディレクトリ構造で説明したようにネーミングコ ンテキストを再度用いてサーバ／ＰＴＡサーバの位置を出す。 これは、前記ステップ８１５同様に、（“ファインド（Ｆｉｎｄ）”を用いて） 適宜なファクトリサーバを見いだす操作からなる。ただし、特に示されてはいな いが、ステップ８２５も、さらにＰＴＡＳ自体へアクセスするステップを備えて いる。従って、“オープン（Ｏｐｅｎ）”仕様が再びファクトリ要求となる、即 ち、（“オープン（Ｏｐｅｎ）”を用いてサーバの事例を創出する。このように 、“オープン（Ｏｐｅｎ）” という用語をステップ８２５で使用してはいるが、当業者にはそれが実際は“オ ープン（Ｏｐｅｎ）”及び“ファインド（Ｆｉｎｄ）”仕様であることが分かる であろう。またスタジオデバイス、つまりＰＴＡＳ、を開くとき、メソッド８０ ０も接続ポートを受け戻し、例えば、将来の接続用にＶＣＩ／ＶＰＩを返す。 ステップ８３０で、メソッド８００は“プロキシオープン（ＰｒｏｘｙＯｐｅ ｎ）”仕様を用いて“ビデオクリップワン（ＶｉｄｅｏＣｌｉｐＯｎｅ）”と呼 ばれるビデオクリップを仕向先、これがトランスミッタとなる、へ送り出す。つ まり、メソッド８００は、ＰＴＡＳ７１０からトランスミッタ７３０へ、図５に ７６０として示されたパス（ビデオストリーム）を開いている。連続的なフィー ドセッションを想定している。 ステップ８３５では、ＰＴＡＳのサーバとプロキシトランスミッタとの間でＳ ＲＭを介したローレベルダイアローグが確立され、例えば、PＴＡＳがプロキシ トランスミッタへ資源を要求しプロキシトランスミッタがトランスミッタと通信 を行う。破線はプロキシオブジェクトと実デバイスとの間のローレベルダイアロ ーグを示す。“別資源（ＡｄｄＲｅｓｏｕｒｃｅ）”接続要求はＳＲＭの動作で ある点に留意されたい。 ステップ８４０では、直接的な接続、例えば、ＳＲＭ（７２０）により管理さ れたトランスミッタへのＰＴＡＳからのＱ．２９３１もしくはＡＴＭ接続が確立 する。要するに、ＰＴＡＳとトランスミッタとの間で直接接続が確立しハイレベ ルなダイアローグが成立する。さらに重要なこととして、メソッド８００は、こ こで、選択的に制御可能な“ストリーム（ｓｔｒｅａｍ）”（“ｓｔｒｍ”）を 得ている。“ストリーム（ｓｔｒｅａｍ）”はＰＴＡＳに在るソフトウェアオブ ジェクトである点に留意されたい。つまり、“ストリーム（ｓｔｒｅａｍ）”は 、下位にあるビデオクリップの状態に対応したソフトウェアオブジェクトになっ ている。このソフトウェアオブジェクトはステップ８４５及び８５０で説明する 有用な仕方でアクセスできる。 オプションステップ８４５で、メソッド８００はオブジェクトストリームに対 する選択的なアクセス及び取り扱いが可能で、例えば、ストリームを所定時間（ ６：００ＰＭ、その他）に始めることができる。 オプションステップ８５０で、メソッド８００はオブジェクトストリームに対 する選択的なアクセス及び取り扱いが可能で、例えば、ストリームを所定時間に 停止できる。実際、様々なＶＣＲ的機能、例えば、巻き戻し、休止又は早送りが 考慮されている。 ステップ８５５では、クライアントがサービスゲートウェイからデタッチする 。これは、クライアントがスタジオ構成要素へのアクセスを終了する意志を表明 していることを示す。 最後に、ステップ８６０で、クライアントがネットワークにセッションの破棄 を要求してもよい。このため、図６に示すメソッド８００では、プロキシトラン スミッタオブジェクトへの要求があると、接続情報を返しており、ビデオソース と仕向先（トランスミッタ）との間で直接に接続確立を進められる。この一般的 な手法は、次に説明する更に複雑なケースで有利となる。 図７は、デジタルスタジオの２つのプロキシオブジェクトを制御するＤＳ−Ｃ Ｃダイアローグの一例をブロック図で示し、この実施形態ではソースも着先も直 接には制御されない。つまり、ＰＴＡＣＷＳ９２０（サーバ）上のソフトウェア クライアントオブジェクト９２２（例えば、プレイリスト−１オブジェクト）が 、プロキシオブジェクトライブフィード９１２及びプロキシオブジェクトトラン スミッタ９１４へ単にアクセスして、ビデオストリームをソース（ライブ・フィ ード）９３０からルータ９４０を介し着先（トランスミッタ）９５０へ転送させ る。そのとき、図５の例同様に、プロキシオブジェクト（プロキシズ）が、ロー レベル通信路９７０を介し、ライブフィード構成要素９３０及びトランスミッタ ９５０と直接に通信する。この例では、ソース及び着先が共にプロキシを有し、 それらのプロキシがいずれもスタジオ構成要素ＰＴＡＳ上にある。 図７に示されたシナリオのＤＳ−ＣＣタイムシーケンス図が図８にある。図８ は２つのプロキシ構成要素のセッション管理のためのメソッド１０００と見るこ とができる。図８にはスタジオ構成要素（ＰＴＡＣＷＳ、ＰＴＡＳ、ライブフィ ード、トランスミッタ及びルータ／ネットワーク）間の相互作用が上から下へ進 むタイムシーケンス図として示される。 より詳細には、ステップ１００５で、クライアントがネットワークにセッショ ンの開始を要求する。ステップ１０１０で、クライアントがサービスゲートウェ イにアタッチする。これはクライアントがスタジオ構成要素を使用するとの意図 を表明していることを示す。 ステップ１０１５で、メソッド１０００はトランスミッタ９５０をオープンし 、このトランスミッタの制御を得る。ステップ１０１５はトランスミッタのオー プニングを単一ステップで示しているが、これは前に図６で説明した同様なステ ップ８１５及び８２０のショートカット表示に過ぎない。 ステップ１０２０で、メソッド１０００はライブフィード９３０をオープンし 、このライブフィードの制御を得る。実際、図示してはいないが、ステップ１０ １５もライブフィードをオープンするステップを含み、この点も既述のごとく８ １５及び８２０に類似する。初めのオープンはトランスミッタ資源をリザーブす るだけだが、第２のオープンはソースと着先との間の接続を成立させる。また、 この第２のオープン仕様はここで広く利用される。接続は一般にクリエートスト リーム（図６のステップ８２５及び８３０と類似）の操作により成立する。つま り、クリエートストリーム操作は既述のごとくソースと着先と間にパスを開設す ることに関係したステップからなることが当業者には分かるであろう。プロキシ フィードはＳＲＭに連続フィードセッションを行わせて接続要求を開始する。 ステップ１０２２及び１０２４では、ＳＲＭによりライブフィードとトランス ミッタとの間にコネクションがオープンされ、これには例えば スイッチから出た一対のＩＴＵ−ＴＱ．２９３１コールセットアップインディケ ーションが用いられる。これはプロキシトランスミッタオブジェクトでのＤＳＭ −ＣＣセッションセットアップインディケーションとなり、プロキシライブフィ ードオブジェクトへのレスポンスとなる。そのとき、この動作状態がプロキシラ イブフィードオブジェクトにより発信者へ返される。 同様に、オプションステップ１０２５及び１０３０でも、本例におけるＶＣＲ 的機能の有用性が示される。最後に、ステップ１０３５で、クライアントがサー ビスゲートウェイからデタッチする。またクライアントはステップ１０４０でネ ットワークにセッションの終了を要求してもよい。ソース着先間パスが規定され ている場合、下位のテーマが再度上程され、それにより通信ダイアローグが確立 する。 要するに、クライアントオブジェクトから出たオリジナルの指令がプロキシラ イブフィードへ往き、これがライブフィード構成要素との接続を行ったのである 。次いで、プロキシライブフィードがＳＲＭとダイアローグを始めて物理的トラ ンスミッタと物理的ライブフィードとの間の接続を確立しているのであって、こ れによりトランスミッタとライブフイードとの間にローレベルなＡＴＭ接続９６ ０ができている。 図９は、デジタルスタジオ内のトランスコーダにビデオストリームを通して２ つのプロキシオブジェクトを制御するＤＳ−ＣＣダイアローグの一例をブロック 図で示し、この実施形態ではソースも着先も直接には制御されない。つまり、Ｐ ＴＡＣＷＳ１１２０（サーバ）上のソフトウェアクライアントオブジェクト１１ ２２が、プロキシオブジェクトライブフィード１１１２及びプロキシオブジェク トトランスミッタ１１１４へ単にアクセスして、ビデオストリームをソース（ラ イブ・フィード）１１３０からトランスコーダ１１８０及びルータ１１４０を介 し着先（トランスミッタ）１１５０へ転送させる。プロキシズは、ローレベル通 信路１１７０を介し、ライブフィード構成要素１１３０及びトランスミッタ１１ ５０と直接に通信する。この例では、ソース及び着先が共にプロ キシを有し、それらのプロキシがいずれもスタジオ構成要素ＰＴＡＳ上にある。 また、今回は、ライブフィードからのビデオパス１１３５がトランスコーダ１ １８０を通るが、これはフレームレート変換、アスペクト比変換等のタスクを幾 つか実行し、組み合わせてスキャン変換又はビットレート変換を漸進させている とみなす。次いで、トランスコーダからのビデオパス１１６０がルータを通り、 トランスミッタへ来る。トランスコーダ１１８０はプロキシオブジェタト１１９ ０により制御され、これはスタジオ構成要素上にあり、これが本例ではルータ１ １４０になっている。 図９に示したサービスのＤＳ−ＣＣタイムシーケンス図を図１０に示す。ステ ップ１２０５、１２１０、１２２５、１２３０、１２４０、１２４５、１２５０ 、１２６０及び１２６５についての説明は前記図６及び８の説明を参照し、説明 の繰り返しを省く。 より詳細には、図示のごとく、制御している各オブジェクトが責任を持ち、実 際に通信接続を確立する上で必要な構成要素資源（フィルタ、スイッチャ、その 他）を事前に獲得する。本例では、トランスコーダが先ずステップ１２１５で（ オープン指令により）確保され、次に、ステップ１２２０においてトランスミッ タからトランスコーダまでの、またステップ１２３５においてビデオサーバから トランスコーダまでの接続がなされる。これらの各パスは分離接続と考える（即 ち、トランスコーダにおいて、“そこから”と“そこへ”との２つのコールが存 在する。一旦パスが確立すれば、前述のごとく、ステップ１２５５でトランスコ ーダにより実行される更に別の機能によりビデオが制御される。接続はすべてＳ ＲＭが管理しており、従ってＳＲＭはシステムトポロジが完全に分かっている点 に注意されたい。資源オラクルオブジェクトがＳＲＭにアタッチして、オーソラ イズされたユーザによるスタジオ管理のためのトポロジ情報を与えてもよい。 図１１は、デジタルスタジオ実施形態中のスイッチャ１３８０にビデ オストリームを通して２つのプロキシを制御するＤＳ−ＣＣダイアローグの一例 をブロック図で示す。即ち、ＰＴＡＣＷＳ１３２０（サーバ）上のソフトウェア クライアントオブジェクト１３２２が、プロキシトランスミッタオブジェクト１ ３１２、ＰＰＳサーバ１３３０、ＰＴＡＳサーバ１３１０及びＰＴＡＳＷ（スイ ッチャ）１３８０へ単にアクセスして、２つのストリームを一緒に（又はスプラ イス）してニューストリームを生成する。この点、スイッチャ１３８０（スプラ イサ）が存在し、これが２つ以上の入力ストリーム１３７０及び１３７５を取り 上げ、その間の切換を、パス１３６０を経由しルータ１３４０を介したトランス ミッタへの外的制御下で行えると考える。図１１に示す実施形態では、２つのソ ースＰＴＡＳ１３１０及びＰＰＳ１３３０からビデオストリームが構成される。 着先はトランスミッタ１３５０であり、これがＰＴＡＳ１３１０上のプロキシオ ブジェクト１３１３により制御される。クライアント（制御しているオブジェク ト１３２２）はＰＴＡＣＷＳ１３２０上に在る。 図１１に示したサービスのＤＳ−ＣＣタイムシーケンス図を図１２に示す。ス テップ１４０５、１４１０、１４２５、１４３０、１４４０、１４４５、１４５ ５、１４６０、１４６５及び１４７０についての説明は前記図６、８及び１０の 説明を参照し、説明の繰り返しを省く。 図１２は、制御しているオブジェクト（例えば、プレイリスト−１オブジェク ト）の典型的なシナリオをタイムシーケンス図で示す。前述のごとく、各構成要 素資源を先ず“オープン（Ｏｐｅｎ）”指令を用いて獲得し、次いでそれ自身と このビデオシーケンスに関与することになる他のオブジェクトとの間で接続を行 う。本例では、スイッチ１３８０がステップ１４１５でオープンされる最初のス タジオ構成要素となる。メソッド１４００では、次いで、トランスミッタ１４２ ０、ソース１及びソース２をそれぞれステップ１４２０、１４３５及び１４５０ でオープンする。 タイムシーケンス図の最後の制御シーケンスは、ビデオパスに関係し たあらゆる遅れを計算することが、制御しているオブジェクトにどの程度の責任 となっているかを示す。先ず、ストリームｓｔｒｍ−１がステップ１４６５で指 令を受けて（多分６：００ｐｍ前に）プレイし、従ってトランスミッタ１３５０ への出力はｓｔｒｍ−１となる。６：００ｐｍ−１０ｍｓｅｃに指令がストリー ムｓｔｒｍ−２にステップ１４７０で送られて、６：００ｐｍ−５ｍｓｅｃにプ レイを開始する。この出された指令に起因する遅れは５ｍｓｅｃ未満とみなす。 ビデオストリームの第１ビットがスイッチ１３８０へ着くまでの時間を５ｍｓｅ ｃとし、従って第１のフレームの開始が丁度６：００ｐｍにスイッチャへ到着す るものと考える。ステップ１４７５での６：００ｐｍのスイッチへの指令は、ス イッチャへは、スイッチで必要となるよりも少し前に出され、この場合、６：０ ０ｐｍ−５ｍｓｅｃである。切換はスイッチャ１３８０内で６：００ｐｍに起こ り、得られるストリームはストリームｓｔｒｍ−２から派生する。このとき、ｓ ｔｒｍ−１は終了してよい。 図１３は、デジタルスタジオ実施形態中でサーバ１５１０からクライアント１ ５２０へビデオを格納するためのＤＳ−ＣＣダイアローグの一例をブロック図で 示す。格納は、ルータ１５３０を経由したクライアント制御下で行う。圧縮され たデジタルスタジオのコンテキスト内ではストリームを格納することは大切な要 件であり、例えば、一連の編集で構築されたニューストリームを、ビデオサーバ にニューオブジェクトとしてバックストリングすることが必要ともなる。図１３ は、サーバ（ＰＰＳ）１５１０からＰＴＡＳ１５２０上の新たな格納オブジェク トへのビデオの格納を示している。 図１３に示したサービスのＤＳ−ＣＣタイムシーケンス図を図１４に示す。ス テップ１６０５、１６１０、１６３０、１６３５、１６４０、１６４５、１６５ ０及び１６５５についての説明は前記図６、８、１０及び１２の説明を参照し、 説明の繰り返しを省く。 新たな格納オブジェクトは、メソッド１６００によりステップ１６１５で先ず （“ニュー（Ｎｅｗ）”を用いて）生成する必要がある点に注 意されたい。このオブジェクトは、次に、ステップ１６２０で、このオブジェク トの接続情報を返す“オープンライト（ＯｐｅｎＷｒｉｔｅ）”と呼ばれる新構 造を用いて、オープンされる。すると、ステップ１６２５において、通常の仕方 でストリームが生成される。この場合、通常のプレイ時間で複写を行うが、プレ イ及びプレイアット指令を拡張することによりリアルタイム伝送より高速（又は 低速）にすることもできる。 図１５は、ルータ１７４０を介して、ビデオストリームを多数の受信者及び共 用クライアントへ分配するためのＤＳ−ＣＣダイアローグの一例をブロック図で 示す。図１５に示された実施形態では、ＰＴＡＣＷＳ１７２０上のクライアント １ １７２２が先ず２つの着先、つまりプロキシトランスミッタ１７１２を介し たトランスミッタ１７５０及びアーカイブバックアップ１７３０ＰＰＳ、へのビ デオフィードをオープンする。これら２つのビデオフィードは同じソースから派 生しているので、分けて制御することができない。少し経った時点で、クライア ント２ １７１４も（オーソライゼーションを条件に）ビデオストリーム１７４ ２にアタッチし、プロキシモニタ１７１６を経由して、出力をモニタ１７６０へ 向ける。実施形態では、クライアント１はストリーム１７４２を制御できるが、 クライアント２はできない。 図１５に示したサービスのＤＳ−ＣＣタイムシーケンス図を図１６に示す。ス テップ１８０５、１８１０、１８１５、１８２０、１８２５、１８３０、１８４ ５、１８５０、１８５５、１８６４、１８６６及び１８６８についての説明は前 記図６、８、１０、１２及び１４の説明を参照し、説明の繰り返しを省く。 クライアント１がステップ１８３５で第２の着先を開くときには、仕様を与え て、あるパラメータ機構を介し接続が既存のものから増加すること表示すると理 解できる。図１５では、これがパラメータモード＝リーフジョインにより、メソ ッド１８００のステップ１８４０で表示される。これは、Ｑ２９３１コールセッ トアップインディケーションとして、ビデオサーバに適宜な接続情報により表明 してもよい。第２のストリー ムをオープンする仕方が幾通りかあることを指摘しておきたい。１つは、（図中 でＣ１：リーフジョインの最初の出現により示される）ビデオソースを指定する 仕方である。もう１つのアプローチは、（図の下側の影領域に示されたステップ １８６０）着先構成要素の１つを指定する仕方である。この場合には、どのソー スがビデオストリームを供給しているのかＳＲＭが特定し、このソースからのジ ョインを開始する。いずれの場合にも、得られるストリームはソースから派生し 、スイッチ内で分けられる。このことは性能を考察する上で重要である。 もう１つの考えられるスタジオ動作として、第２のクライアントが前にオープ ンされたストリームへのアクセスを要求する。この場合を、クライアント２の場 合について図１７に示す。ステップ１９０５、１９１０、１９２５及び１９３０ についての説明は前記図６、８、１０、１２、１４及び１６の説明を参照し、説 明の繰り返しを省く。 クライアントは、通常のセッションセットアップ及びオープンを着先プロキシ に対しステップ１９１５で開始する（この場合はモニタ）。次いで、プロキシは 、ステップ１９２０でモード＝リーフジョイン表示を用いることによりストリー ムにリンクされる。この場合、ストリームに対するソース名が指定される。 複数のスタジオ構成要素を含むデジタルスタジオの指令及び制御アーキテクチ ャーを説明した。このアーキテクチャーは１つのスタジオ構成要素の位置を決め る手段と、前記位置を決める手段に結合され、前記スタジオ構成要素の制御を獲 得する手段と；前記獲得する手段に結合され、前記スタジオ構成要素を介したス トリームを確立する制御の下に前記スタジオ構成要素への連結を規定する手段と からなる。位置を決める手段は前記スタジオ構成要素に対応する、プロキシオブ ジェクト等の、オブジェクトの位置を決めることができる。 位置を決めることは、階層的ディレクトリ構造を備えたネーミングコンテキス トを用いて行うことができ、前記階層的ディレクトリ構造はルーツレベルのサー ビスゲートウェイを含む。ストリームは下位にあるデ ジタルデータの状態に対応したオブジェクトであり得、選択的に操作してスタジ オ動作のリアルタイム制御を行える。 確立されたストリームは多数のクライアント、多数の受信者及びデジタルデー タの格納をサポートでき、またデジタルスタジオ内の他のストリームからスプラ イスできる。 上記において明らかにした手段を用い、複数のスタジオ構成要素を含むデジタ ルスタジオのデジタルデータを管理するための方法も説明した。 スプライシング、格納及びトランスコーディング等の典型的なスタジオ操作の ためのオリジナルな制御方法論を開示した。 ここに教示した装置及び操作方法は発明の例示的なものであると理解されるべ きである。当業者であれば、発明の精神及び範囲を逸脱することなく変更例を容 易に考案できよう。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＢＲ，ＣＡ，ＣＮ，Ｊ Ｐ，ＫＲ，ＭＸ (72)発明者 ホマン，デイヴィッド，ビー. アメリカ合衆国 ニュー ジャージー州 ホープウェル コロンビア アヴェニュー 21

Claims (1)

1. 【特許請求の範囲】 １．複数のスタジオ構成要素を有するデジタルスタジオの指令及び制御アーキ テクチャーであって、 １つのスタジオ構成要素の位置を決める手段と、 前記位置を決める手段に結合され、前記スタジオ構成要素の制御を獲得する手 段と、 前記獲得する手段に結合され、前記スタジオ構成要素を介したストリームを確 立する制御の下に前記スタジオ構成要素への連結を規定する手段と を含む指令及び制御アーキテクチャー。 ２．前記位置を決める手段は、前記スタジオ構成要素に対応するオブジェクト の位置を決める請求項１に記載の指令及び制御アーキテクチャー。 ３．前記位置を決める手段は、階層的ディレクトリ構造を備えたネーミングコ ンテキストを用いて前記オブジェクトの位置を決め、前記階層的ディレクトリ構 造は、ルーツレベルのサービスゲートウェイを有している請求項２に記載の指令 及び制御アーキテクチャー。 ４．前記ストリームは、下位にあるデジタルデータの状態に対応したオブジェ クトである請求項１に記載の指令及び制御アーキテクチャー。 ５．前記確立されたストリームは、デジタルスタジオ内の他のストリームから スプライスされている請求項１に記載の指令及び制御アーキテクチャー。 ６．複数のスタジオ構成要素を有するデジタルスタジオのデジタルデータを管 理するための方法であって、 １つのスタジオ構成要素の位置を決める工程と、 前記スタジオ構成要素の制御を獲得する工程と、 前記スタジオ構成要素を介したストリームを確立する制御の下に前記スタジオ 構成要素への連結を規定する工程と を含む方法。 ７．前記位置を決める工程は、前記スタジオ構成要素に対応するオブジェクト の位置を決める請求項６に記載の方法。 ８．前記オブジェクトは、プロキシオブジェクトである請求項７に記載の方法 。 ９．前記ストリームは、下位にあるデジタルデータの状態に対応したオブジェ クトである請求項６に記載の方法。 １０．前記ストリームを選択的に操作して、スタジオ動作のリアルタイム制御 を行う請求項９に記載の方法。 １１．コンピュータ読出し可能なメディアの中のスタジオクラスディレクトリ 構造であって、 ルーツディレクトリとしてのゲートウェイサービスインターフェースと、 前記ルーツディレクトリに結合されたデバイスクラスディレクトリと、 前記ルーツディレクトリに結合されたサーバクラスディレクトリと、 前記ルーツディレクトリに結合されたスタジオクラスディレクトリと、 前記ルーツディレクトリに結合されたソフトウェア資源クラスディレクトリと を含むスタジオクラスディレクトリ構造。 １２．前記デバイスクラスディレクトリに結合されたライブフィードズディレ クトリと、 前記デバイスクラスディレクトリに結合されたフィルタディレクトリと、 前記デバイスクラスディレクトリに結合されたトランスミッタディレクトリと をさら含む請求項１１に記載のスタジオクラスディレクトリ構造。 １３．前記フィルタクラスディレクトリに結合されたスイッチャズディレクト リと、 前記フィルタクラスディレクトリに結合されたトランスコーダディレ クトリと を含む請求項１２に記載のスタジオクラスディレクトリ構造。 １４．前記サーバクラスディレクトリに結合されたプレイ・ツー・エアサーバ ディレクトリと、 前記サーバズクラスディレクトリに結合された制作プログラムサーバディレク トリと、 前記サーバズクラスディレクトリに結合されたネットワークプログラムサーバ ディレクトリと をさら含む請求項１１に記載のスタジオクラスディレクトリ構造。