JP4502469B2

JP4502469B2 - 放送自動化システムの高速始動用スロットラー

Info

Publication number: JP4502469B2
Application number: JP2000210632A
Authority: JP
Inventors: ケビン・バーナード・ケニー
Original assignee: General Electric Co
Current assignee: General Electric Co
Priority date: 1999-07-14
Filing date: 2000-07-12
Publication date: 2010-07-14
Anticipated expiration: 2020-07-12
Also published as: US6437802B1; EP1069716A3; EP1069716A2; JP2001069097A

Description

【０００１】
【発明の属する技術分野】
本発明は、放送自動化システムに関し、具体的には、このシステムの高速始動方法に関する。
【０００２】
【従来の技術】
一般的に、既存の放送自動化システムはイベント（事象、番組など）の予定表として知られている「プレイリスト(playlist)」に基づいて動作する。これらのイベントは映像装置に対するコマンドとなり、これに従って、その映像装置は、音声／映像データの再生、特殊効果の挿入、特定の入力装置からの映像の取り込み、映像の特定の出力装置への方向づけ、音声／映像放送に関するその他の処理を実行する。
【０００３】
【発明が解決しようとする課題】
放送自動化システムは、全プレイリストの全てのイベントを順々に一回ロードすることによって動作する。このシステムは、最初のプレイリストのロード中にその他の処理を実行できない。次に、このシステムはプレイリストの「編集(edit)」と呼ばれる変更を受け入れることができるが、その編集処理は限定されている。大量の編集を急速に連続的に行うと、その間、このシステムを利用できなくなることがある。さらに、例えば、プレイリストに別のデータ(material)を付け加えるというような、直ぐには生じないイベントに対して編集を行うと、それより早く生じるイベントに対する編集が無期限に遅らされることがある。この結果、その編集が行われなかったり、プレイリストを誤って実行したりすることがある。
【０００４】
【課題を解決するための手段】
本発明の好適な実施の形態では、「スロットラー(throttler) 」と呼ばれるソフトウエア要素によって、プレイリストのロード及び編集を、装置へのコマンドの送信やオペレーターとの交信のような他の処理とインターリーブすることが可能になる。プレイリストをロードし編集する外部要素が、編集コマンドを送信する。各コマンドは、イベントの挿入もしくは削除のいずれか一方である。現在のイベントを修正するには、その現在のイベントを削除した後に、修正されたイベントを挿入する。各々のイベントはそれぞれ個別の「識別子」を持ち、該識別子は、緊急度に応じて配列されて、そのイベントについての挿入と削除の編集処理のコマンド対より成る高速アクセス可能なデータ構造を指示する。
【０００５】
コマンドをインターリーブすることは、最先端の技術システムにとって多くの利点がある。第一に、映像装置が不完全な予定表をすぐに受信して、プレイリスト内の後のイベントが処理中であっても、それを実行し始めることが可能である。放送時間が迫っているイベントを送ることにより、映像処理の始動前に全プレイリストをロードしなければならない場合よりも早く、システムは放送することができる。第２に、プレイリストのダウンロードが完了する前でも、映像装置はプレイリスト内のイベントの状態（ステータス）を報告することができる。このため、システムは精算や故障分析等の目的で実際に再生される映像のタイムリーな記録をとることができる。第３に、オペレータインターフェイスを、映像装置に対するコマンドの最初のダウンロード中に「生きた状態」にしておくことが可能になる。最初のダウンロードが進行中でも、オペレータは機器の状態を調べたり、完成もしくは未完成のプレイリストを見たり、装置と交信したり、プレイリストの編集を要求することができる。
【０００６】
本発明の以下の好適な実施形態を図面を参照して詳細な説明を行うことによって、前述の目的、概要、利点とその他のものの理解が容易になる。
【０００７】
【発明の実施の形態】
複数の図面、特に、図１では、スロットラーの好適な一実施形態によるコマンドと編集のデータの流れが示されている。スロットラー１００は最初のプレイリスト１０６をロードする一方で、編集コマンド１０８も受け入れる。非編集コマンド１１４はスロットラー１００で受信されて、放送自動化システム１１８に直接渡される。ここで、この放送自動化システムは、典型的には、スロットラーと同じＣＰＵ上に存在し、即ち、２つのプロセス間の通信を可能にするようにスロットラーと同じＣＰＵ上にデバイスドライバを少なくとも備える。以下で述べられる方法を使って、スロットラー１００はこれらのイベントと編集コマンドをインターリーブして、予定イベントのプレイリスト１１６の生成や修正を行う。スロットラー１００は実行のためにイベントを放送自動化システム１１８に送信し、放送自動化システム１１８は音声／映像装置１２０を予定されたイベントに基づいて駆動する。プレイリストに関するオペレータの問い合わせや、装置に対するオペレータの直接的コマンドや、機器状態の報告のような非編集コマンドを他のプロセスが処理するための時間を作るために、スロットラーは中央処理装置を周期的に明け渡す。スロットラーによってフォーマットされ送信されたプレイリストを読み出したり、必要ならば再フォーマットし、次に、多数の音声／映像ドライバや放送自動化の操作を行うその他のドライバに編集／非編集コマンドを送る放送自動化システムを使うことで、スロットラーの処理が最適に実行される。また、好適な放送自動化システムは、予定イベントの状態を表示して、ユーザインターフェイスを介したオペレータの手動による修正を可能にする。
【０００８】
スロットラー１００で未処理の各編集コマンド１０８について、２つまでの情報、即ち、１つの削除コマンドと１つの挿入コマンドとが保持される。いずれのコマンドも削除可能である。各々のコマンド、即ち、イベントは、個別の「イベント識別子」をもつ。
【０００９】
スロットラー１００が削除コマンド１１０を受け入れた場合、もし、挿入もしくは削除のいずれか一方の同じイベント識別子にあてはまる前のコマンドが処理されていないならば、そのコマンドを廃棄し、新たに受け入れられた削除コマンドだけを保持する。スロットラー１００が挿入コマンド１１２を受け入れた場合は、同じイベント識別子にあてはまる前の挿入コマンドは廃棄されるが、前の削除コマンドは保持される。
【００１０】
図２は、削除コマンドと挿入コマンドを累積するためのルールを示す。第一の列２００は、プレイリスト中の予定イベントに対する現在の挿入及び削除コマンドに関する２つの可能性を示す。第２の列２０２は新たに受け付けられるコマンドを示し、また、第３の列２０４はそのイベントに対して得られるコマンド構成を示す。例えば、もし、イベント１（２０６）に対して挿入や削除の予定がなく、かつ、削除コマンド２０８が受け入れられたならば、その結果得られる予定イベントは、そのイベントを削除（２１０）したものである。イベント８（２１２）には、削除と挿入の予定がすでにある。もし、このイベントに対して新たな挿入コマンド２１４が受け入れられると、その結果２１６は、削除コマンドを保持し、新たに入力した挿入コマンドを代わりに用いて元の挿入コマンドを廃棄したものになる。図２からわかるように、スロットラーは、自動化システムのイベントを所望のイベントセットに一致させるために必要な最小の変更セットを常に保存する。
【００１１】
コマンド対２００及び２０４は、次いで、最小値の要素を迅速に検索できるデータ構造をもつ「優先待ち行列」に組み込まれる。その対の配列順序はイベントの実行予定時間により規定される。もし、削除コマンドと挿入コマンドの両方があれば、そのイベントの削除されたものと挿入されたものの予定時間の早い方がその対の優先順位を確定する。この方法では、古いイベントの削除後に新たなものを挿入しなければならないという実態を維持しながら、相対的緊急度に応じて複数のコマンドを配列させる。
【００１２】
選ばれた優先待ち行列のデータ構造は、一旦挿入された待ち行列の要素のメモリ位置は変わらないという属性をもつ。メモリ位置を安定に保つことによって、ハッシュ(hash)テーブルが優先待ち行列とは全く異なるデータ構造をもつことができる。もし、待ち行列の要素のメモリ位置が変わるとしたら、その１つを移動させるたびにハッシュテーブルを更新しなければならなくなる。その結果、テーブル対する別の探索を行うか、もしくは、ハッシュテーブルの要素へのポインタを優先待ち行列要素内に保つかのいずれか一方が必要となるので、その待ち行列を維持するプログラムが複雑になる。また、優先待ち行列のデータ構造により、待ち行列内のいかなる位置にある要素をも迅速に削除することができる。これらの制限により、ヒープ(heap)、分類されたベクトル、Ｂツリーは不適当なデータ構造であることがわかる。好適な本実施形態では、当業者にとっては周知の構造である「レフティストツリー(leftist tree)」を使って優先待ち行列を構成する。このデータ構造は、コンピュータプログラミング技術、第３巻、分類と検索、D. E. クヌス著（マサチューセッツ州リーディング：アディソン-ウエズレー、１９７３年、１４９-１５３、１５９、６１９-６２０頁）に完全に記載されている。レフティストツリーでは、待ち行列の前面付近での処理が速いという利点がある。この特性は、ＡＶＬツリー、スプレー(splay) ツリー、もしくは、それに類似の自己編成データ構造を使った別のやり方よりも好ましい。
【００１３】
本技術分野では周知のデータ構造であるハッシュテーブルを使うことによって、優先待ち行列を改良することができる。図３に示すように、ハッシュテーブルは、イベント識別子から待ち行列要素のアドレスへの写像を与える。新たなコマンドの到着時に削除−挿入対の場所を突き止めるために、この構造が使われる。図３では、各イベント識別子３０２は、ハッシュすることによって得られる削除−挿入対の待ち行列要素３０６に対する写像をとるポインタ３０４を備える。
【００１４】
スロットラーで使うアルゴリズムは２つの工程、即ち、「フィル（fill；充填）」と「ドレイン（drain ；排出）」を備える。フィル工程は、図４と図５の方法を使ってコマンドを迅速に受け入れる。ドレイン工程は、新たなコマンドが到着した時でも、放送自動化システムが図６の方法に基づいて装置の制御やオペレータ・インターフェイス等の他の処理の実行を継続するできるような方法で、送信コマンドの調停を行う。
【００１５】
図４では、プレイリストを最初にロードする処理は、機能ブロック４０２で、最初のプレイリスト４０３からイベントを読み込む処理である。決定ブロック４０４でプレイリストに別のイベントがあると判断すると、機能ブロック４０６で、優先待ち行列とハッシュテーブルを以下で述べるフィル工程によって充填する。この工程は、最初のイベントの全てが優先待ち行列にロードされるまで続く。放送自動化システムで実施されているようなイベントを装置に送る処理と比較して、これらの処理は時間がかからない。一旦、最初の優先待ち行列が構成されると、機能ブロック４０８では、フィル工程が外部インターフェイス（例えば、他のプログラム、オペレーター、装置等）からのコマンドを待つ。
【００１６】
決定ブロック４１０では、新たに受信した各コマンドをチェックして、それが編集コマンドであるかどうかを判断する。もしそれが編集コマンドでなければ、機能ブロック４１２では、それをシステムの訂正構成要素に送って処理する。さもなければ、機能ブロック４１４でフィルコマンドを呼び出すことによって、新たなコマンドを追加し、優先待ち行列とハッシュテーブルを更新することにより、プレイリストを編集しなければならない。
【００１７】
図５の機能ブロック５０２では、スロットラーが受け入れた各コマンドに対応して、フィル工程はハッシュ・テーブルをアクセスし、イベントを編集するために以前から存在するコマンド対を見つける。決定ブロック５０４では、もし以前から存在する対を見つけると、機能ブロック５０６では、それを優先待ち行列から除去する。もしそうでなければ、機能ブロック５０８では、新たな空コマンド対を作る。次に、図２に示すルールに従って、新たに到着したコマンドをそのコマンド対に結合する。
【００１８】
機能ブロック５１２では、コマンド対を優先待ち行列に挿入して、それが緊急度に応じて正しく配列されることを確実にする。最後に、機能ブロック５１４では、優先待ち行列への登録事項の新たなアドレスに対応するためハッシュ・テーブルを更新する。機能ブロック５１６では、以下で説明されるドレイン工程を再び動作可能にする。
【００１９】
通常、フィル工程はシステムのその他の工程より高い優先度をもつ。その処理はハッシュテーブルと優先待ち行列を維持するだけのものなので、通常、中央処理装置（ＣＰＵ）の時間全体のうちのわずかな時間だけを消費する。このため、他の工程を締め出すための予防策は不要である。
【００２０】
普通、ドレイン工程は放送自動化システムによって能動化(enable)され、その他の処理のために充分な時間を残しておくよう計算されたある最短の時間間隔でコマンドを検索する。別の方法によれば、これらのイベントを放送自動化装置へ伝送することによって、オペレータ・インターフェイスを一時的に「凍結」させたり、以前のイベントの状況報告を遅らせたり、非編集コマンドの受け付けを延期させたり、もしくは、緊急度の低い処理を不本意にも遅らせてしまうことになったとしても、特定の完了時間未満のコマンドを強制終了させてしまうだろう。
【００２１】
ドレイン工程は、普通、「デバイスドライバ」工程と通信して、それを能動化させる時間を制御する。それを能動化させる時間の制御は非常に単純であり、しばしば、単純なタイマー割り込みによって行われる。このタイマー割り込みにより、最後のコマンド処理後の数ミリ秒で、即ち、装置が「送信空きあり」の合図を出した後の数ミリ秒で、それを能動化する。好ましい性能をもたらす遅延時間の範囲は通常かなり広い。遅延時間が短すぎるとＣＰＵに過大な負担をかけることになり、その結果、他の工程に不本意な遅れが発生する。他方、遅延時間が長すぎると、図６の方法で発生するかもしれないが、予定時間後にイベントが到着したり、図７の別の方法では、常に「緊急」イベントとして処理される。８本の映像チャンネルを扱えるシステムでの通常の処理量が教唆することは、数百ミリ秒から数秒までの全範囲に渡る遅延が好ましい性能をもたらすということである。
【００２２】
図６には、単純なドレイン工程が示されている。始めに、決定ブロック６０２では、優先待ち行列をチェックして、コマンド対が優先待ち行列に存在するかどうかを調べる。もし、待ち行列が空なら、決定ブロック６０４では、コマンド対が到着するまで処理を停止する。図５の機能ブロック５１６で示されているように、ドレイン工程は、フィル工程がこのドレイン工程を再び能動化するまで待つ。もしそうでなければ、決定ブロック６０６で、自動化装置が新たなコマンドを受け入れる準備ができているかどうかをチェックする。もし、できていなければドレイン工程は処理を停止し、システムがコマンドを受け入れる準備ができたときに再び動作可能になる。
【００２３】
機能ブロック６１０では、優先待ち行列から削除するイベントがあり、また、システムがそれらを受信する準備ができている場合、最初のコマンド対を待ち行列から検索する。機能ブロック６１２では、そのコマンド対が検索されると、それを優先待ち行列から削除し、また、それに対応するハッシュテーブル内の登録(entry) も削除する。機能ブロック６１４では、そのコマンド対を放送自動化システムに供給する。機能ブロック６１６では、そのコマンド対の送信が成功すると、本工程がＣＰＵをその他の工程に明け渡すことで、本コマンド処理工程はリクエストに確実に対応することができる。そして、再び、決定ブロック６０２の処理を続けて、優先待ち行列からの他のコマンド対の処理を行う。
【００２４】
緊急コマンドをタイムリーに確実に処理できる別の方法を図７に示す。この工程は、単純なドレイン工程と同様である。始めに、決定ブロック７０２では、優先待ち行列をチェックして、優先待ち行列にコマンド対が存在するかどうかを調べる。機能ブロック７１８では、もし待ち行列が空ならば、コマンド対が到着するか、自動化システムの準備ができるか、緊急イベントのための時間割込みが発生するまで、本工程は停止する。さもなければ、もし待ち行列が空でなければ、機能ブロック７０４では、最初のコマンド対を優先待ち行列から検索する。決定ブロック７０６では、自動化システムが新たなコマンドを受信する準備ができているかどうかをチェックする。もし、準備ができていなければ、決定ブロック７０８では、そのコマンドが緊急のものなのかどうかを決定するテストを行う。もし、それが緊急でなければ、機能ブロック７１０では、最初のイベントが緊急になる時間に対してタイマー割り込みをセットする。機能ブロック７１８では、ドレイン工程が、上述したように再び停止する。もし、ブロック７０８でテストされたそのコマンドが緊急のものであるなら、もしくは、決定ブロック７０６でチェックされたコマンドを受信する準備が自動化システムでできているなら、機能ブロック７１２では、そのコマンド対を優先待ち行列から削除し、それに対応するハッシュテーブル内の登録も削除する。次に、機能ブロック７１４では、そのコマンド対を放送自動化システムへ提供する。そのコマンド対の送信が成功するとすぐに、機能ブロック７１６では、本工程がＣＰＵをその他の工程に明け渡すことで、本コマンド処理工程はリクエストに確実に対応することができる。次に、再び、決定ブロック７０２の処理を続けて、優先待ち行列からの別のコマンド対を処理する。
【００２５】
本発明を好適な一実施形態を参照して説明したが、当業者であれば、本発明の範囲から逸脱することなしに様々な変更が可能であり、また、本構成要素をその等価物に置換できることが理解されよう。さらに、本発明の基本範囲から逸脱することなく多くの修正を行って、特定の状態や材料を本発明が教唆するところに適応させることもできる。従って、本発明は、本発明を実施するために考えられたベストモードとして開示された特定の実施形態に限定されず、本発明は添付の請求項の範囲にある全ての実施形態を含むことができる。
【図面の簡単な説明】
【図１】放送自動化システムに接続されたスロットラーの高レベルのデータ流れ図である。
【図２】削除コマンドと挿入コマンドを蓄積するためのルールを示す図である。
【図３】スロットラーで使用するデータ構造の略図である。
【図４】スロットラーの主工程の方法の流れ図である。
【図５】スロットラーのフィル工程の方法の流れ図である。
【図６】スロットラーのドレイン工程の方法の流れ図である。
【図７】緊急コマンドのために使われるスロットラーのドレイン工程の別の方法の流れ図である。

Claims

処理装置を
イベントに基づいた音声及び映像装置の駆動が順次行われるように、複数のイベントの予定を含むプレイリストをロードする手段と、
前記プレイリストを編集する複数の編集コマンドと前記プレイリストを編集しない非編集コマンドをオペレータから受け入れる手段と、
前記編集コマンドを前記編集コマンドと別の時間に処理される非編集コマンドとインターリーブする手段と、
前記非編集コマンドを放送自動化システムに与える手段と、
前記編集コマンドにより編集したプレイリストのイベントを前記放送自動化システムに送る手段として機能させる、放送自動化システムの高速始動用スロットラーを備える、処理装置。
前記編集コマンドは、前記プレイリストにイベントを挿入する挿入コマンドか前記プレイリストからイベントを削除する削除コマンドのいずれか一方であり、
１つのイベントにはただ１つの挿入コマンドとただ１つの削除コマンドより成るコマンド対のみが対応し、
前記編集コマンドの各々はイベント識別子に対応付けられており、
前記１つのイベントに対して新たな挿入コマンドが受け入れられると、元の挿入コマンドが廃棄されることを特徴とする請求項１の処理装置。
前記複数のイベントの各々は、対応する実行予定時間を有し、前記コマンド対の各々は、前記イベントの各々の実行予定時間にしたがって配列された高速アクセス可能な優先待ち行列となる前記編集したプレイリストに格納されることを特徴とする請求項２の処理装置。
前記優先待ち行列に格納されたコマンド対は、イベント識別子によってアドレス可能であり、
前記優先待ち行列は、前記イベント識別子によって識別されたコマンド対の削除を可能とすることを特徴とする請求項３の処理装置。
前記非編集コマンドが、前記プレイリストに関するオペレータの問い合わせ、装置に対するオペレータの直接的コマンド、機器状態の報告の内のいずれかに該当するコマンドであり、
前記インターリーブする手段は、コマンド対を前記優先待ち行列に挿入する手段と、前記優先待ち行列のコマンド対を前記放送自動化システムへ送ることによってコマンド対を前記優先待ち行列から「排出する」手段と、をさらに備えることを特徴とする請求項３又は４の処理装置。
前記スロットラーと共に前記放送自動化システムを備え、
前記放送自動化システムは、前記処理装置を前記スロットラーから送られたイベントに基づいて音声及び映像装置を駆動する手段として機能させ、
前記処理装置の前記スロットラーとは異なるプロセスが前記非編集コマンドを処理し、
前記スロットラーは、前記処理装置が前記非編集コマンドを処理するための時間を作るために、前記処理装置を周期的に明け渡すことを特徴とする請求項１乃至５のいずれかに記載の処理装置。
放送自動化システムに使われるコマンドを調整する方法であって、
イベントに基づいた音声及び映像装置の駆動が順次行われるように、複数のイベントの予定を含むプレイリストをロードする工程と、
外部インターフェイスを介してコマンドをオペレータから受信する工程と、
前記受信されたコマンドが前記プレイリストを編集する編集コマンドであるか前記プレイリストを編集しない非編集コマンドであるかを確定する工程と、
前記編集コマンドを前記編集コマンドと別の時間に処理される非編集コマンドとインターリーブし、該非編集コマンドを放送自動化システムへ送る工程と、
前記編集コマンドを使って、前記プレイリストを編集する工程と、
前記編集コマンドにより編集したプレイリストのイベントを前記放送自動化システムに送る工程と、を有することを特徴とする方法。
前記プレイリストは複数のイベントを含み、前記イベントの各々は前記プレイリストにイベントを挿入する挿入コマンドか前記プレイリストからイベントを削除する削除コマンドのいずれか一方である編集コマンドを含み、また、１つのイベントにはただ１つの挿入コマンドとただ１つの削除コマンドより成るコマンド対のみが対応し、前記編集コマンドの各々は個別のイベント識別子に対応付けられており、
前記１つのイベントに対して新たな挿入コマンドが受け入れられると、元の挿入コマンドが廃棄されることを特徴とする請求項７の方法。
前記非編集コマンドが、前記プレイリストに関するオペレータの問い合わせ、装置に対するオペレータの直接的コマンド、機器状態の報告の内のいずれかに該当するコマンドであり、
前記複数のイベントの各々は、対応する実行予定時間を有し、前記コマンド対の各々は、前記イベントの各々の実行予定時間にしたがって配列された高速アクセス可能な優先待ち行列となる前記編集したプレイリストに格納されることを特徴とする請求項８の方法。
前記優先待ち行列に格納されたコマンド対は、イベント識別子によってアドレス可能であり、
前記優先待ち行列は、前記イベント識別子によって識別されたコマンド対の削除を可能とすることを特徴とする請求項９の方法。
前記放送自動化システムが、前記処理装置を前記スロットラーから送られたイベントに基づいて音声及び映像装置を駆動する工程と、
前記処理装置の前記スロットラーとは異なるプロセスが前記非編集コマンドを処理する工程と、
前記スロットラーが、前記処理装置が前記非編集コマンドを処理するための時間を作るために、前記処理装置を周期的に明け渡す工程とを有する請求項７乃至１０のいずれかに記載の方法。