JP2011119869A - 番組制作システム及び番組制作プログラム - Google Patents

Abstract

【課題】利用者端末における負荷及び操作負担を軽減し効率的な番組制作を実現する。
【解決手段】ネットワークに接続された利用者端末を管理する管理サーバにより割り振られたスクリプト情報に対応させて、複数の番組制作装置により映像コンテンツを制作し、制作された映像コンテンツをライブストリーミング信号により前記利用者端末に送信する番組制作システムにおいて、前記複数の番組制作装置に対して、前記映像コンテンツの生成及び伝送効率を含むＣＰＵ負荷の負荷情報を検出する負荷情報検出手段と、検出された前記負荷情報に基づいて、前記管理サーバにより割り振られた前記スクリプト情報のうち少なくとも一部に対応する映像コンテンツを制作する番組制作手段と、制作された映像コンテンツに対応するライブストリーミング信号を生成するストリーム信号生成手段と、を有することにより、上記課題を解決する。
【選択図】図１

Description

本発明は、番組制作システム及び番組制作プログラムに係り、特に、利用者端末における負荷及び操作負担を軽減し効率的な番組制作を実現するための番組制作システム及び番組制作プログラムに関する。

従来、テレビ番組のような番組コンテンツを制作するにあたり、テキスト台本を入力するだけで、映像コンテンツを簡単に生成できるいわゆるＴＶＭＬを用いた制作システムが開示されている（例えば、特許文献１参照。）。

特許文献１に示されているような制作システムは、ローカルコンピュータでテキストデータからなるスクリプトを生成し、生成したスクリプトに基づいて同一のコンピュータ内でＣＧ（Ｃｏｍｐｕｔｅｒ Ｇｒａｐｈｉｃｓ）処理や音声合成処理を行い、目的の映像コンテンツを制作する。そして、制作された映像コンテンツを再生して、ローカルコンピュータのディスプレイ等に表示させることができる。

特開２００１−２４６１０号公報

しかしながら、上述した従来のコンテンツ制作手法においては、映像コンテンツを生成・表示するための利用者端末であるローカルコンピュータに、特殊なＣＧ描画機能や音声合成機能を備える必要があった。そのため、ローカルコンピュータにＣＧ描画、音声合成のための特殊なソフトウェアをインストールしたうえで、そのソフトウェアを実行するため、ローカルコンピュータには高いソフトウェア処理性能が必要であった。

一方、携帯情報端末等のような比較的処理性能の劣る端末の場合でも、上述した理由から、通常、映像コンテンツを生成することが困難であった。

更に、従来の映像コンテンツの生成手法においては、テキスト台本の入力や編集等にワープロ型の編集ツールを用いていたため、ワープロに不慣れなユーザにとってはその操作が困難であるという課題があった。

本発明は、上述した問題点に鑑みなされたものであり、利用者端末における負荷及び操作負担を軽減し効率的な番組制作を実現するための番組制作システム及び番組制作プログラムを提供することを目的とする。

上記課題を解決するために、本件発明は、以下の特徴を有する課題を解決するための手段を採用している。

請求項１に記載された発明は、ネットワークに接続された利用者端末を管理する管理サーバにより割り振られたスクリプト情報に対応させて、複数の番組制作装置により映像コンテンツを制作し、制作された映像コンテンツをライブストリーミング信号により前記利用者端末に送信する番組制作システムにおいて、前記複数の番組制作装置に対して、前記映像コンテンツの生成及び伝送効率を含むＣＰＵ負荷の負荷情報を検出する負荷情報検出手段と、前記負荷情報検出手段により検出された前記負荷情報に基づいて、前記管理サーバにより割り振られた前記スクリプト情報のうち少なくとも一部に対応する映像コンテンツを制作する番組制作手段と、前記番組制作手段により制作された映像コンテンツに対応するライブストリーミング信号を生成するストリーム信号生成手段と、を有することを特徴する。

請求項１記載の発明によれば、利用者端末における負荷及び操作負担を軽減し効率的な番組制作を実現することができる。

請求項２に記載された発明は、前記番組制作手段は、前記スクリプトに対応する映像コンテンツと、前記映像コンテンツからライブストリーミング信号を生成するための再生タイミング情報とを生成することを特徴とする。

請求項３に記載された発明は、前記ストリーム信号生成手段は、前記利用者端末が備える映像コンテンツの再生手段に応じて、予め設定される１又は複数のデータ形式のライブストリーミング信号を生成することを特徴とする。

請求項４に記載された発明は、前記ストリーム信号生成手段は、前記映像コンテンツを再生し、再生された映像音声をリアルタイムにキャプチャすることでエンコードを行い、前記ライブストリーミング信号を生成することを特徴とする。

請求項５に記載された発明は、前記番組制作手段は、前記管理サーバにより前記スクリプト情報に含まれるデータ識別情報により割り振られたスクリプト情報の一部から映像コンテンツを生成し、生成した映像コンテンツに対して前記割り振られたスクリプトを統合するための統合化情報を付加することを特徴とする。

請求項６に記載された発明は、前記番組制作手段は、前記統合化情報を前記再生タイミング情報に付加することを特徴とする。

請求項７に記載された発明は、ネットワークに接続された利用者端末を管理する管理サーバにより割り振られたスクリプト情報に対応させて、複数の番組制作装置により映像コンテンツを制作し、制作された映像コンテンツをライブストリーミング信号により前記利用者端末に送信するための番組制作プログラムにおいて、コンピュータを、前記複数の番組制作装置に対して、前記映像コンテンツの生成及び伝送効率を含むＣＰＵ負荷の負荷情報を検出する負荷情報検出手段、前記負荷情報検出手段により検出された前記負荷情報に基づいて、前記管理サーバにより割り振られた前記スクリプト情報のうち少なくとも一部に対応する映像コンテンツを制作する番組制作手段、及び、前記番組制作手段により制作された映像コンテンツに対応するライブストリーミング信号を生成するストリーム信号生成手段、として機能させる。

請求項７記載の発明によれば、利用者端末における負荷及び操作負担を軽減し効率的な番組制作を実現することができる。また、実行プログラムをコンピュータにインストールすることにより、容易に番組制作処理を実現することができる。

本発明によれば、利用者端末における負荷及び操作負担を軽減し効率的な番組制作を実現することができる。

本実施形態における番組制作システムの概略構成例を示す図である。 ローカルコンピュータの機能構成の一例を示す図である。 管理サーバにおける機能構成の一例を示す図である。 レンダリングサーバにおける機能構成の一例を示す図である。 配信サーバにおける機能構成の一例を示す図である。 番組制作システムの処理手順の一例を示す図である。 本実施形態におけるスクリプト生成画面の一例を示す図である。 本実施形態において生成されたスクリプトの一例を示している。 映像コンテンツの表示結果の一例を示す図である。 他の実施形態におけるレンダリングサーバの選択方法の第１の例を示す図である。 他の実施形態におけるレンダリングサーバの選択方法の第２の例を示す図である。 他の実施形態におけるレンダリングサーバの選択方法の第３の例を示す図である。 レンダリングサーバとライブエンコーダとの構成例を示す図である。

＜本発明について＞
本発明は、例えば、テレビ番組等の映像コンテンツをスクリプト言語で制作・記述し、リアルタイムＣＧ、音声合成等を用いて再生する分野に関わるものであり、映像コンテンツをサーバ側で生成するサーバサイドレンダリングの分野に属する。

具体的には、従来、ローカルコンピュータ側にあった映像コンテンツ生成機能をネットワークに接続されたサーバコンピュータである番組制作装置に配置し、番組制作装置側で生成した映像コンテンツを、ライブストリーミング等を用いてローカルコンピュータに配信して表示する。この仕組みによって、ローカルコンピュータに、例えばＣＧ描画機能、音声合成機能等の映像コンテンツを生成するための機能を有していなくても映像コンンテンンツの生成・表示が可能となる。

以下に、上述したような特徴を有する本発明における番組制作システム及び番組制作プログラムを好適に実施した形態について、図面を用いて詳細に説明する。

なお、本実施形態では、制作する映像コンテンツの一例として番組を用いる。また、本実施形態では、番組の生成や提示等に用いられるスクリプトの一例として、ＴＶＭＬ（ＴＶ ｐｒｏｇｒａｍ Ｍａｒｋｉｎｇ Ｌａｎｇｕａｇｅ）を用いる。また、以下に説明する本発明の一実施形態として使用されるコンテンツ制作システムは、自動番組制作システム（ＴＶ４Ｕ）の機能を有する。

ここで、ＴＶＭＬとは、テレビ番組を制作するためのオブジェクトベース記述言語であり、テレビ番組の映像や音声等を、素材データと台本（演出内容等）とに分けて記述することができ、制作側で台本を記述することで、パソコンやサーバ等で動作するソフトウェア等がこれを読み取り、台本に記述された素材データを取得して即座にテレビ番組として再生・視聴することができる。

なお、上述のＴＶ４Ｕは、例えばクライアント側の端末で編集用のユーザインタフェイスを用いて番組の台本を作成し、その台本に任意の番組制作エンジンを適用して番組を制作するものである。

なお、番組制作エンジンとは、番組に登場するＣＧキャラクタや番組における１つの動作の単位で「タイトル表示」、「ズームイン」、「ＣＧキャラクタの動作」等のイベントが予め定義されたものである。これを用いて、例えば番組の内容を表す台本からのテキストデータ等を入力すると、それを元に番組の自動生成に必要なＴＶＭＬスクリプトを出力する。このように、番組制作エンジンを用いることで効率的に番組制作を実現することができる。

＜番組制作システムの概略構成例＞
図１は、本実施形態における番組制作システムの概略構成例を示す図である。図１に示す番組制作システム１０は、１又は複数のローカルコンピュータ（利用者端末）１１−１〜１１−ｎと、管理サーバ１２と、１又は複数のレンダリングサーバ（番組制作装置）１３−１〜１３−ｎと、配信サーバ１４とを有するよう構成されている。なお、図１に示す番組制作システム１０では、ローカルコンピュータ１１−１〜１１−ｎ、管理サーバ１２、レンダリングサーバ１３−１〜１３−ｎ、配信サーバ１４は、それぞれインターネット等の通信ネットワーク１５を介してデータの送受信が可能な状態で接続されている。

ローカルコンピュータ１１−１〜１１−ｎは、１又は複数のローカルコンピュータが映像コンテンツを生成するためのスクリプトを生成し、配信サーバ１４から配信された映像コンテンツを表示する。具体的には、ローカルコンピュータ１１−１〜１１−ｎは、スクリプトを生成する際には専用のソフトウェアを事前にインストールし、そのインストールされたソフトウェアを起動して生成するのではなく、インターネット等の通信ネットワーク１５を用いてＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）等のアドレス情報に基づいて、所定のサーバ（例えば、管理サーバ１２等）にアクセスしてブラウザ等でスクリプト生成画面を閲覧し、その生成画面に対して所望する映像に対応するスクリプトを生成する。なお、スクリプトを生成するための画面は、管理サーバ１２以外の外部装置で管理されていてもよく、例えばローカルコンピュータ１１から参照可能なＷｅｂサーバであればよい。

また、ローカルコンピュータ１１−１〜１１−ｎは、管理サーバ１２に生成したスクリプトを送信し、配信サーバ１４から生成されたスクリプトに対する映像や音声情報等のコンテンツを取得し、コンテンツを再生して画面に表示する。

このように、ローカルコンピュータは、ブラウザに表示される画面を用いて映像コンテンツを生成するためのスクリプトを生成し、生成したスクリプトを、通信ネットワーク１５を介して管理サーバ１２に送信することで、ＣＧ描画、音声合成のための特殊なソフトウェアをインストールすることなく、スクリプトに基づいて生成された映像コンテンツを取得し、再生することができる。したがって、ローカルコンピュータ１１−１〜１１−ｎは、例えば携帯端末やＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ）等の携帯情報端末等、低性能なローカルコンピュータ等を用いることができる。

管理サーバ１２は、ローカルコンピュータ１１−１〜１１−ｎから得られたスクリプトに対して複数ある管理対象のレンダリングサーバ１３−１〜１３−ｎのうち、１又は複数のレンダリングサーバを選択してスクリプトを出力する。

このとき、管理サーバ１２は、管理対象のレンダリングサーバ１３−１〜１３−ｎの負荷状況や、管理サーバ１２と各レンダリングサーバ１３−１〜１３−ｎ間における通信速度、伝送効率等の負荷監視を定期的に行い、スクリプトから迅速且つ高精度に映像コンテンツ及び音声を生成するレンダリングサーバを選択する。

なお、レンダリングサーバ１３−１〜１３−ｎのうち、全てが同一の機能（ＣＧ描画機能、音声合成機能等）を有している場合には、管理対象の全てのレンダリングサーバから１又は複数のレンダリングサーバ１３を選択する。また、例えば、レンダリングサーバ１３−１〜１３−ｎの全てが同一の機能ではなく、一部（数台）のレンダリングサーバ１３がＣＧ描画機能を有しているような場合には、対象となる機能を有しているレンダリングサーバを対象に負荷状況等を比較し、効率よく処理が行えるレンダリングサーバを選択する。

レンダリングサーバ１３−１〜１３−ｎは、管理サーバ１２から得られたスクリプトに対してレンダリング機能によって、ＣＧ、音声合成を使用して、再生処理を行い、その結果を画面に表示する。このとき、図１に示す実施形態では、レンダリングサーバ（番組制作装置）１３−１〜１３−ｎに、それぞれライブエンコーダ（ストリーム信号生成手段）１６−１〜１６−ｎが設けられている。ライブエンコーダ１６−１〜１６−ｎは、再生されている映像音声をリアルタイムにキャプチャしながら、エンコードを行い、映像音声ストリームを含むライブストリーミング信号を生成する。

なお、キャプチャ手法としては、例えば、レンダリングサーバ１３でリアルタイムタイムに番組を再生し、画面上に表示した映像と音声とを共にライブエンコーダ１６で直接キャプチャしたり、又はレンダリング機能とライブエンコーダとを共にハードウェア上で実行させ、レンダリングマシンの映像音声出力をライブエンコーダマシンに外部入力したりすることでキャプチャを行う。更には、レンダリング機能の映像音声出力を外部入力デバイスとして仮想化し、同一マシンで実行しているライブエンコーダに入力してキャプチャを行う。

また、レンダリングサーバ１３のレンダリング機能は、ライブエンコーダに再生の開始と終了のタイミング情報を生成する。なお、レンダリングサーバ１３−１〜１３−ｎが有する機能は、それぞれ同一の機能であってもよく、またそれぞれが１つ又は複数の特殊な機能を有していてもよい。例えば、レンダリングサーバ１３−１では、画像編集処理機能を備えたレンダリング機能を有していてもよく、またレンダリングサーバ１３−２では、言語解析処理機能を備えたレンダリング機能を有していてもよい。なお、この場合には、レンダリングサーバ１３−１及び１３−２は、再生処理機能といった共有の機能も有することができる。

つまり、管理サーバ１２は、各ローカルコンピュータ１１−１〜１１−ｎから得られるそれぞれのスクリプトの内容を、そのスクリプトに含まれる各データを識別するタグ情報等で記述されている識別情報を参照し、その内容から処理内容を推測し、その処理内容に適したレンダリングサーバをレンダリングサーバ１３−１〜１３−ｎから選択して、選択したレンダリングサーバに対応するスクリプトを出力する。また、管理サーバ１２は、上述したタグ情報からスクリプトの内容を処理内容毎に複数に分割し、それぞれの分割スクリプトに、それぞれを識別するための識別情報を付加し、そのスクリプトの処理内容に適応したレンダリングサーバ１３を選択して、送信することもできる。

レンダリングサーバ１３−１〜１３−ｎは、生成した映像音声ストリーム及びタイミング情報を、通信ネットワーク１５を介して配信サーバ１４に送信する。

配信サーバ１４は、レンダリングサーバ１３−１〜１３−ｎから得られる映像音声ストリーム及びタイミング情報を、予め蓄積されたローカルコンピュータ１１に対応するアドレス情報（ＵＲＬ等）に基づいて、スクリプトを送信したローカルコンピュータ及び／又は予め設定された視聴者としてのローカルコンピュータに配信する。

なお、配信サーバ１４は、ローカルコンピュータに映像音声ストリームを送信する際、ライブストリーミング信号によるライブ配信を行う。つまり、ローカルコンピュータ１１は、ライブストリーミング機能により配信サーバ１４から配信された映像音声コンテンツからなる番組をブラウザ等により容易且つ低負荷で表示することができる。

なお、上述した番組制作システム１０においては、本発明においてはこれに限定されるものではなく、例えば管理サーバ１２、又は配信サーバ１４のない構成でもよく、その場合には、ローカルコンピュータ１１とレンダリングサーバ間でデータの送受信が行われる。また、レンダリングサーバ１３は、１台でもよく、ライブエンコーダ１６は、レンダリングサーバ１３の内部にあってもよく、外部のエンコーダを使用してもよい。

次に、上述した本実施形態におけるローカルコンピュータ１１、管理サーバ１２、レンダリングサーバ１３、配信サーバ１４について具体的に説明する。

＜ローカルコンピュータ１１：機能構成例＞
本実施形態における利用者端末であるローカルコンピュータ１１の機能構成例について図を用いて説明する。図２は、ローカルコンピュータの機能構成の一例を示す図である。図２に示すローカルコンピュータ１１は、入力手段２１と、出力手段２２と、蓄積手段２３と、スクリプト生成手段２４と、再生手段２５と、送受信手段２６と、制御手段２７とを有するよう構成されている。

入力手段２１は、番組制作者等のユーザ（利用者）等からの台本（演出）に対応するスクリプトの生成指示や、再生指示等のコンテンツ制作における各入力を受け付ける。なお、入力手段２１は、例えばキーボードや、マウス等のポインティングデバイス、マイク等の音声入力デバイス等からなる。

出力手段２２は、入力手段２１により入力された指示内容や、各指示内容に基づいて生成されたスクリプトや番組等の内容を表示し、音声を出力する。なお、出力手段２２は、ディスプレイ等の画面表示機能やスピーカ等の音声出力機能等を有する。

蓄積手段２３は、番組台本スクリプト、素材データ、音声映像ストリームや、映像コンテンツを生成するサイトのアドレス（ＵＲＬ等）情報、管理サーバ１２のアドレス情報、レンダリングサーバのアドレス情報等が蓄積されており、必要に応じて読み出しや書き込みが行われる。また、蓄積手段２３は、上述した各種データを通信ネットワーク等に接続された外部装置等から取得することもできる。

スクリプト生成手段２４は、実際の番組を生成するための演出情報等を含めた台本データをスクリプトとして生成する。なお、スクリプト生成手段２４は、再生手段２５により表示されたブラウザ画面を参照して、ＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）に基づく番組コンテンツのスクリプトを生成する。なお、スクリプト生成手段２４により生成されるスクリプトの内容については後述する。

再生手段２５は、ブラウザ機能を有し、スクリプトを生成させるために、蓄積手段２３に蓄積されているアドレス情報に基づいて通信ネットワーク１５を介して管理サーバ１２の所定のページにアクセスし、ブラウザ上に表示させる。また、再生手段２５は、ライブストリーミング機能により配信サーバ１４から送信された映像音声ストリームを含むライブストリーミング信号を、タイミング情報から得られる出力タイミングに併せて再生する。

なお、本実施形態における再生手段２５は、生成したＴＶＭＬスクリプトを再生し、映像又は音声等により出力手段２２によりビューアーとして表示させることもできる。また、再生手段２５は、処理内容やサーバの機能毎に別々のレンダリングサーバ等で生成されたスクリプト等の制御データがそれぞれ非同期で送られてきた場合でも入力された映像音声ストリームをタイミング信号に合わせて統合化を行い、連結して再生を行う。

なお、再生手段２５は、予め設定される制御データの優先順位に基づいて再生する順序も優先させて再生させることができる。これにより、例えばキャラクタ動作に関するスクリプトを優先的に再生させることで、リアルタイム動作を実現することができる。

また、再生手段２５は、リアルタイム再生を行わない場合には、入力されるＴＶＭＬスクリプトを一時的にメモリ等の蓄積手段２３に保存し、台本データと照合して適切な順序に並べ替えた後、再生するようにしてもよい。これにより、所望する番組の演出を分担させた制御データから柔軟な番組演出を実現することができる。

また、再生手段２５は、ブラウザにスクリプト表示画面を表示する際、ユーザに作業させ易くするため、レンダリングサーバ１３が所有する番組制作エンジンや台本データ、素材データ等の各種情報を表示することができる。

送受信手段２６は、通信ネットワークを介して制御データ、ビューアーとして表示された番組情報、番組制作エンジン、素材データ、台本データ、番組データ等の各種データを、番組制作システム１０を構成する他の端末に送信し、他の端末から各種データを受信するための通信インタフェイスである。

制御手段２７は、番組制作システム１０におけるローカルコンピュータ１１の各機能構成全体の制御を行う。具体的には、制御手段２７は、入力手段２１により入力されたユーザからの入力情報に基づいてスクリプトを生成したり、他の端末からの要求に対して蓄積手段２３に蓄積された対応する各種データを抽出し、送受信手段２６を介して他の端末に送信させたり、映像コンテンツを再生手段２５によりストリーミング再生させたり、ブラウザを生成させる等の各種制御を行う。

上述したように、本実施形態によれば、例えば携帯端末等のように、低性能なデバイスであっても生成されたスクリプトに対応する映像コンテンツを容易に取得することができる。

＜管理サーバ１２：機能構成例＞
次に、上述したコンテンツ制作システム１０における管理サーバ１２の機能構成例について図を用いて説明する。図３は、管理サーバにおける機能構成の一例を示す図である。図３に示す管理サーバ１２は、入力手段３１と、出力手段３２と、蓄積手段３３と、負荷検出手段３４と、レンダリングサーバ選定手段３５と、コンテンツ管理手段３６と、送受信手段３７と、制御手段３８とを有するよう構成されている。

入力手段３１は、ユーザ等からの負荷検出指示やレンダリングサーバ選定指示、コンテンツ管理指示、送受信指示等の本実施形態での番組制作における管理に対する各入力を受け付ける。また、入力手段３１は、ローカルコンピュータ１１からのスクリプトを入力する機能も有する。なお、入力手段３１は、例えばキーボードや、マウス等のポインティングデバイス、マイク等の音声入力デバイス等からなる。

出力手段３２は、入力手段３１により入力された指示内容や、各指示内容に基づいて生成されたレンダリングサーバ１３の負荷検出結果やレンダリングサーバ選定結果等の内容を表示し、音声を出力する。なお、出力手段３２は、ディスプレイ等の画面表示機能やスピーカ等の音声出力機能等を有する。

蓄積手段３３は、ローカルコンピュータ１１からのスクリプト情報、ローカルコンピュータ１１−１〜１１−ｎの全アドレス情報、レンダリングサーバの全アドレス情報を蓄積する。なお、アドレス情報とは、ＵＲＬ等の通信ネットワーク１５を介して接続可能とするための情報や、その端末の利用者名、地域、管理対象期間、年齢、性別、住所、メールアドレス等も含む。

また、蓄積手段３３は、ローカルコンピュータ１１からのスクリプト生成画面の閲覧要求に対して、予め設定された対応する生成画面をＷｅｂ上に表示し、ローカルコンピュータ１１に使用させるための各種情報を蓄積しておくこともできる。

負荷検出手段３４は、全てのレンダリングサーバ１３−１〜１３−ｎの負荷を検出する。なお、負荷情報としては、例えば、映像コンテンツの生成や、伝送効率等に対応するデータ伝送時のＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）負荷（負荷情報測定時におけるＣＰＵ使用率等）や、通信負荷、機器毎の処理能力等も含む。なお、負荷検出手段３４は、全てのレンダリングサーバ１３−１〜１３−ｎについて所定の周期又はユーザからの指示に基づいて負荷情報を検出し、検出した負荷情報を蓄積手段３３に検出した日時情報と共に出力する。更に負荷検出手段３４は、予めレンダリングサーバ１３がそれぞれどのような処理機能を有しているかを蓄積手段３３から取得し、ローカルコンピュータ１１から得られるスクリプトの内容を分析して、対応するレンダリングサーバ１３に対して負荷を検出するようにしてもよい。

レンダリングサーバ選定手段３５は、負荷検出手段３４から得られる負荷情報からレンダリングサーバ１３を１又は複数選択する。具体的には、レンダリングサーバ選定手段３５は、予め設定されているレンダリングサーバ１３−１〜１３−ｎ毎の実行可能な処理機能と、ローカルコンピュータ１１−１〜１１−ｎから得られるスクリプトの内容とを照合して、そのスクリプトを処理可能なレンダリングサーバ１３を選択する。

したがって、上述の処理を実現するために、レンダリングサーバ選定手段３５は、スクリプトの内容についてスクリプトに含まれるタグ情報等、データの内容を識別する識別情報を参照し、参照した識別情報から必要な処理機能を推測するスクリプト解析手段と、スクリプト解析手段により解析した結果から、スクリプトに含まれる画像や映像等の量や大きさ等に応じて負荷を推定する負荷推定手段とを有し、スクリプト解析手段や負荷推定手段により推定された負荷量やスクリプトの内容（ジャンル）等に応じて、その分野の処理が得意なレンダリングサーバを選定する。

コンテンツ管理手段３６は、どのローカルコンピュータのどのスクリプトに対して、どのレンダリングサーバ１３−１〜１３−ｎに処理させているかを管理する。つまり、コンテンツ管理手段３６は、全レンダリングサーバ１３−１〜１３−ｎに対する実行状況を管理する。

送受信手段３７は、ローカルコンピュータからスクリプトを受信する。また、送受信手段３７は、レンダリングサーバ１３にスクリプトを送信する。

制御手段３８は、番組制作システム１０における管理サーバ１２の各機能構成全体の制御を行う。具体的には、制御手段３８は、入力手段３１により入力されたユーザからの入力情報に基づいてレンダリングサーバ１３−１〜１３−ｎのそれぞれの負荷を検出したり、レンダリングサーバを選定したり、コンテンツを管理したり、他の端末からの要求に対して蓄積手段３３に蓄積された対応する各種データを抽出し、送受信手段３７を介して他の端末に送信させる等の各種制御を行う。

＜レンダリングサーバ１３：機能構成例＞
次に、上述したコンテンツ制作システム１０におけるレンダリングサーバ１３の機能構成例について図を用いて説明する。図４は、レンダリングサーバにおける機能構成の一例を示す図である。図４に示すレンダリングサーバ１３は、入力手段４１と、出力手段４２と、蓄積手段４３と、レンダリング手段（番組制作手段）４４と、エンコード手段（ライブエンコーダ）４５と、送受信手段４６と、制御手段４７とを有するよう構成されている。

入力手段４１は、ユーザ等からのレンダリング指示、エンコード指示等の本実施形態での番組制作におけるレンダリングに対する各入力を受け付ける。また、入力手段４１は、管理サーバ１２からのスクリプトを入力する機能も有する。なお、入力手段４１は、例えばキーボードや、マウス等のポインティングデバイス、マイク等の音声入力デバイス等からなる。

出力手段４２は、入力手段４１により入力された指示内容や、各指示内容に基づいてレンダリングにより生成された映像、音声情報やエンコードされたストリーム情報等を表示し、音声を出力する。なお、出力手段４２は、ディスプレイ等の画面表示機能やスピーカ等の音声出力機能等を有する。

蓄積手段４３は、スクリプトから映像コンテンツを生成するための番組制作エンジン、台本データ、素材データ、番組（ストリーム）、ライブエンコーダのアドレス情報、配信サーバ１４のアドレス情報等の各種情報を蓄積する。なお、アドレス情報とは、ＵＲＬ等の通信ネットワーク１５を介して接続可能とするための情報や、その端末の利用者名、地域、管理対象期間、年齢、性別、住所、メールアドレス等も含む。

レンダリング手段４４は、管理サーバ１２から得られるスクリプトに基づいて、蓄積手段４３から必要な番組制作エンジン、台本データ、素材データ等を抽出し、抽出した情報に基づいて映像ストリームを生成する。なお、スクリプトは、例えばＴＶＭＬスクリプトを用いている場合には、対応する番組制作エンジン等の番組制作エンジンを抽出する。また、レンダリング手段４４は、生成された映像コンテンツに基づいて対応する映像音声コンテンツを生成する。

なお、本実施形態では、複数のレンダリングサーバ１３−１〜１３−ｎを有しているため、レンダリング手段４４は、上述した管理サーバ１２における負荷情報検出手段３４により得られる負荷情報により割り振られたスクリプト情報の少なくとも一部に対応する映像コンテンツを生成する。

なお、レンダリング手段４４は、例えば複数のスクリプトを受信した場合には、そのスクリプトの重複部分を統合するスクリプト統合手段と有していてもよい。これにより、重複部分を除いて効率的に映像ストリームを生成することができる。

また、レンダリング手段４４は、管理サーバ１２により各レンダリングサーバ１３に割り振られたスクリプト情報の一部について映像コンテンツを生成する場合には、その後、ローカルコンピュータ１１で割り振られたスクリプトに対応して生成された映像コンテンツを統合するために、統合化情報を付加する。このとき、統合化情報は、映像コンテンツデータの最後や所定のレングスに付加してもよく、タイミング情報に付加するのが好ましい。

また、レンダリング手段４４は、ユーザの利便性や管理性能を向上させるために、ユーザ毎にレンダリング可能な内容、回数等に制限を与える権限設定手段や、レンダリングできる内容をサーバ毎に設定するレンダリング設定手段等を有していてもよい。

エンコード手段４５は、レンダリング手段４４により生成されたコンテンツ及びタイミング情報に基づいて対応する映像音声ストリームを生成する。また、エンコード手段４５は、ストリーム信号生成手段として、ストリーミング機能等が実現可能なファイル形式のストリームファイルを形成する。

具体的には、Ｒｅａｌ Ｐｌａｙｅｒ（登録商標）やＭａｃｒｏｍｅｄｉａ Ｆｌａｓｈ（登録商標）、Ｗｉｎｄｏｗｓ Ｍｅｄｉａ Ｐｌａｙｅｒ（登録商標）、Ｑｕｉｃｋ Ｔｉｍｅ（登録商標）等のような、ソフトウェアで再生可能な予め設定される１又は複数のライブストリーミング信号を生成する。なお、エンコード手段４５は、予め配信されるローカルコンピュータ１１の再生手段のファイル形式が把握できる場合には、その把握している再生手段に対応する１又複数のデータフォーマットのライブストリーミング信号を生成してもよい。

なお、エンコード手段４５は、複数のエンコーダがある場合に、処理性能等の予め設定された条件に応じてどのエンコーダを選定するかといったエンコーダ選定手段を有していてもよい。

送受信手段４６は、管理サーバ１２又はローカルコンピュータ１１（管理サーバ１２がない場合）からスクリプトを取得する。また、送受信手段４６は、エンコード手段４５により得られたライブストリーミング信号を配信サーバ１４又はローカルコンピュータ１１に送信する。

制御手段４７は、番組制作システム１０におけるレンダリングサーバ１３の各機能構成全体の制御を行う。具体的には、制御手段４７は、入力手段４１により入力されたユーザからの入力情報に基づいてスクリプトデータからＴＶＭＬスクリプトに基づく映像コンテンツを生成したり、映像コンテンツから所定のライブストリーミング信号を生成したり、他の端末からの要求に対して蓄積手段４３に蓄積された対応する各種データを抽出し、送受信手段４６を介して他の端末に送信させる等の各種制御を行う。

ここで、本実施形態におけるレンダリングサーバ１３において、エンコード手段４５は、レンダリングサーバ１３の内部又は外部にあってもよい。なお、外部にライブエンコーダがある場合には、既存のエンコーダを使用することができる。その場合は、映像音声及びタイミングは、キャプチャ機能を用いて抽出する。また、映像音声とタイミング情報とを別々にエンコーダに送信することもできる。

＜配信サーバ１４：機能構成例＞
次に、上述したコンテンツ制作システム１０における配信サーバ１４の機能構成例について図を用いて説明する。図５は、配信サーバにおける機能構成の一例を示す図である。図５に示す配信サーバ１４は、入力手段５１と、出力手段５２と、蓄積手段５３と、配信条件設定手段５４と、配信先選定手段５５と、送受信手段５６と、制御手段５７とを有するよう構成されている。

入力手段５１は、ユーザ等からの配信条件設定指示、配信先選定指示、送受信指示等の本実施形態での番組制作におけるレンダリングに対する各入力を受け付ける。また、入力手段５１は、レンダリングサーバ１３からの映像音声ストリームを含むライブストリーミング信号を入力する機能も有する。なお、入力手段５１は、例えばキーボードや、マウス等のポインティングデバイス、マイク等の音声入力デバイス等からなる。

出力手段５２は、入力手段５１により入力された指示内容やライブストリーミング信号等を表示し、音声を出力する。なお、出力手段５２は、ディスプレイ等の画面表示機能やスピーカ等の音声出力機能等を有する。

蓄積手段５３は、ローカルコンピュータ１１−１〜１１−ｎのアドレスや配信条件（例えば、どのコンピュータにいつ配信するか）、レンダリングサーバ１３からのライブストリーミング信号等を蓄積する。

配信条件設定手段５４は、どのローカルコンピュータ１１−１〜１１−ｎに、いつ、どのレンダリングサーバ１３−１〜１３−ｎからの番組等のライブストリーミング信号を送信するか等の配信条件を設定する。設定された配信条件は、蓄積手段５３に蓄積され、必要に応じて読み出すことができる。

なお、配信条件設定手段５４は、例えば、複数のレンダリングサーバ得られたライブストリーミング信号を所定の条件（ジャンル等）に基づいて統合し、又は選択して配信するストリーム統合手段を有していてもよい。また、配信条件設定手段５４は、例えば、ユーザ毎に配信可能なストリームの権限（ストリームの内容の制限、視聴回数の制限等）を与えるユーザ権限設定手段等を有していてもよい。

配信先選定手段５５は、複数のローカルコンピュータ１１−１〜１１−ｎのうち、配信条件に合う配信先を選定する。また、配信先選定手段５５は、そのスクリプトを生成したローカルコンピュータ以外の端末にも送信を行うことができる。

送受信手段５６は、レンダリングサーバ１３又はライブエンコーダからのライブストリーミング信号を受信する。また、送受信手段５６は、選定した配信先のローカルコンピュータにライブストリーミング信号を配信する。

制御手段５７は、番組制作システム１０における配信サーバ１４の各機能構成全体の制御を行う。具体的には、制御手段５７は、入力手段５１により入力されたユーザからの入力情報に基づいて配信条件を設定したり、配信先を選定したり、他の端末からの要求に対して蓄積手段５３に蓄積された対応する各種データを抽出し、送受信手段５６を介して他の端末に送信させる等の各種制御を行う。

＜実行プログラム＞
ここで、上述した番組制作システム１０は、ＣＰＵ、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の揮発性の記憶媒体、ＲＯＭ等の不揮発性の記憶媒体、マウスやキーボード、ポインティングデバイス等の入力装置、画像やデータを表示する表示部、並びに外部と通信するためのインタフェイスを備えたコンピュータによって構成することができる。

したがって、番組制作システムが有する各機能は、これらの機能を記述したプログラムをＣＰＵに実行させることによりそれぞれ実現可能となる。また、これらのプログラムは、磁気ディスク（フロッピィーディスク、ハードディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ等）、半導体メモリ等の記録媒体に格納して頒布することもできる。

つまり、上述した各構成における処理をコンピュータに実行させるための実行プログラム（番組制作プログラム）を生成し、例えば、汎用のパーソナルコンピュータやサーバ等にそのプログラムをインストールすることにより、コンテンツ制作処理を実現することができる。

次に、本発明における実行プログラムによる処理手順についてコンテンツ制作システムにおけるコンテンツ制作処理についてフローチャートを用いて説明する。なお、以下の処理の説明では、コンテンツの一例として番組を用い、その制作対象として台本データを用いるが、本発明におけるコンテンツの種類についてはこれに限定されるものではない。

＜番組制作システムの処理手順例＞
図６は、番組制作システムの処理手順の一例を示す図である。なお、図６に示す番組制作システムは、ローカルコンピュータ１１と、管理サーバ１２と、レンダリングサーバ１３と、ライブエンコーダ１６と、配信サーバ１４とを有するよう構成されている。なお、図６に示すライブエンコーダ１６は、レンダリングサーバ１３とは別体に設けられている例を示しているが、両者が一体に構成されていてもよい。更に、図６の処理手順では、スクリプトを生成したローカルコンピュータ１１に対し、レンダリングサーバ１３及びライブエンコーダ１６を用いて生成されたそのスクリプトに対応する番組用の映像音声ストリームを含むライブストリーミング信号を配信する例について説明するが、本発明においてはこれに限定されるものではなく、ライブエンコーダ１６にて生成された映像音声ストリームを配信サーバ１４により設定された１又は複数の他のローカルコンピュータに配信してもよい。

まず、ローカルコンピュータ１１は、所望する番組映像を得るためのスクリプトを生成し（Ｓ０１）、生成したスクリプトを管理サーバ１２に送信する（Ｓ０２）。管理サーバ１２は、スクリプトが受信したか否かを判断し（Ｓ０３）、スクリプトを受信していない場合（Ｓ０３において、ＮＯ）、受信するまで待機する。また、Ｓ０３の処理において、スクリプトを受信した場合（Ｓ０３において、ＹＥＳ）、レンダリングサーバを選択する（Ｓ０４）。

このとき、管理サーバ１２は、予め又は定期的に管理対象のレンダリングサーバに対する処理の負荷情報を抽出して蓄積しておき、その負荷情報に基づいて負荷の少ないレンダリングサーバを選択する。

更に、管理サーバ１２は、ローカルコンピュータ１１から送信されたスクリプトを解析し、そのスクリプトに示された編集内容に基づいて、その分野の処理を得意とするレンダリングサーバを選択することもできる。また、複数のレンダリングサーバに対して、上述した負荷情報やスクリプトの編集内容に基づいて、スクリプトを分割して、それぞれ複数のレンダリングサーバに処理させてもよい。

管理サーバ１２は、上述のようにして選択したレンダリングサーバ１３に対応するスクリプトを送信する（Ｓ０５）。

レンダリングサーバ１３は、スクリプトを受信したか否かを判断し（Ｓ０６）、スクリプトを受信していない場合（Ｓ０６において、ＮＯ）、受信するまで待機する。また、Ｓ０６の処理において、スクリプトを受信した場合（Ｓ０６において、ＹＥＳ）、スクリプトに記述された内容に対応させて映像コンテンツを生成する（Ｓ０７）。このとき、Ｓ０６の処理では、映像コンテンツの再生時におけるタイミング情報も生成される。生成された映像コンテンツ及びタイミング情報は、レンダリングサーバ１３に蓄積される。

次に、レンダリングサーバ１３は、生成された映像コンテンツをライブエンコーダ１６に送信する（Ｓ０８）。ライブエンコーダ１６は、映像コンテンツを受信しかた否かを判断し（Ｓ０９）、映像コンテンツを受信していない場合（Ｓ０９において、ＮＯ）、受信するまで待機する。また、Ｓ０９の処理において、映像コンテンツを受信した場合（Ｓ０９において、ＹＥＳ）、映像コンテンツをキャプチャし（Ｓ１０）、キャプチャした映像コンテンツをエンコードして映像ストリームを生成する（Ｓ１１）。

次に、ライブエンコーダ１６は、生成された映像音声ストリームを配信サーバ１４へ送信する（Ｓ１２）。配信サーバ１４では、ライブエンコーダ１６から映像音声ストリームを受信したか否かを判断し（Ｓ１３）、映像音声ストリームを受信していない場合（Ｓ１３において、ＮＯ）、受信するまで待機する。

また、Ｓ１３の処理において、映像音声ストリームを受信した場合（Ｓ１３において、ＹＥＳ）、生成された映像音声コンテンツ毎、スクリプトの内容、管理サーバ１２による設定、レンダリングサーバ１３による設定、ライブエンコーダ１６による設定、配信サーバ１４による設定等により予め設定されたアドレス情報に基づいて、その配信対象のローカルコンピュータ１１に映像音声ストリームを含むライブストリーミング信号を送信する（Ｓ１４）。

なお、図６の例では、配信サーバ１４が配信する配信先をそのスクリプトを生成したローカルコンピュータ１１にしているが、本発明においてはこれに限定されるものではなく、他のローカルコンピュータであってもよい。

ローカルコンピュータ１１は、配信サーバ１４からの映像音声ストリームを受信したか否かを判断し（Ｓ１５）、映像音声ストリームを受信していない場合（Ｓ１５において、ＮＯ）、映像音声ストリームを受信するまで待機する。また、Ｓ１５の処理において、映像音声ストリームを受信した場合（Ｓ１５において、ＹＥＳ）、その映像音声ストリームをライブストリーミングにより再生表示する（Ｓ１６）。

なお、図６に示す番組制作システムは一例を示すものであり、本発明においてはこれに限定されず、例えば、管理サーバ１２や配信サーバ１４の何れか或いは両方を介さず、ローカルコンピュータ１１とレンダリングサーバ１３或いはライブエンコーダ１６とがそれぞれ通信ネットワーク１５を介してデータの送受信を行うようにしてもよい。

＜Ｓ０１；スクリプト生成画面＞
次に、本実施形態における上述したスクリプト生成の例について、具体的に説明する。図７は、本実施形態におけるスクリプト生成画面の一例を示す図である。図７に示すスクリプト生成画面６０は、スクリプト作成領域６１と、ライブストリーミング表示領域６２と、ツールボックス表示領域６３とを有するよう構成されている。なお、これらの各領域のレイアウトについては、図７に特定されるものではない。

ここで、図７に示す実施形態では、一例としてＦｌａｓｈが動作するウェブブラウザを用いた「ＴＶＣｌｅａｔｏｒ」である。つまり、図７に示す画面は、他の特別なソフトウェアをインストールする必要がなく、ウェブブラウザを用いることで、ドラックアンドドロップ（以下、適宜「Ｄ＆Ｄ」と略称する。）型のユーザインタフェイスを提供することができる。

スクリプト作成領域６１は、予め設定されたキャラクタ（動作、セリフ等）、カメラワーク（クローズアップ、ツーショット）、タイトル（スーパーインポーズ等）、素材（静止画、動画、ＢＧＭ等）のカテゴリー毎にアイコン化されて表示されている。したがって、スクリプト作成領域６１を用いてスクリプトを生成する際、その時点でのカテゴリーの配置を容易に把握することができる。また、配列されたスクリプトの一部に新たなスクリプトを挿入する場合、本実施形態では、ツールボックス表示領域６３から上述したカテゴリーを選択し、スクリプト作成領域の所定の場所まで画面上からＤ＆Ｄを行うことにより、容易にスクリプトを作成することができる。つまり、本実施形態によればカテゴリー毎に予めアイコン化されたコマンドが選択できる。ユーザにはこのツールボックスから予め登録されているアイコンをＤ＆Ｄで台本領域であるスクリプト作成領域６１に貼り付けることで、必要なパラメータが入力されスクリプト（台本）の制作が行われる。

なお、ツールボックス表示領域６３に表示されている予め管理サーバ１２の蓄積手段に蓄積されたツールボックスには、例えばキャラクタ、カメラ、タイトル、コマンド、素材等に対応するデータ群がアイコンかされて管理されている。

ライブストリーミング表示領域６２は、スクリプト作成領域６１に記述されたスクリプトに基づいて、レンダリングサーバ１３にてレンダリングされ、ライブエンコーダ１６によりエンコードされた映像音声ストリームを表示する。

また、ツールボックス表示領域６３は、上述した処理カテゴリーのアイコンを表示するだけでなく、そのカテゴリーに対応して、文書データを直接入力することもできる。

また、図８は、本実施形態において生成されたスクリプトの一例を示している。なお、図８では、説明上左端に行番号を付している。また、図８の例は、図７に示すスクリプト作成領域６１に応じて作成されたスクリプト本文である。

例えば、図８の（０８）行目に示す「ｄｒａｗｉｎｇ：ｓｅｔｉｍａｇｅ（ｎａｍｅ＝ＮＥＷＳＩＭＡＧＥ７，ｆｉｌｅｎａｍｅ＝“２４＿０６＿ｖ＿ｓ．ｊｐｇ”，ａｓｐｅｃｔ＝ｆｒｅｅ）」は、“２４＿０６＿ｖ＿ｓ．ｊｐｇ”という画像を読み込むカテゴリー（スクリプト）であることを示している。

また、（２３），（２４）行目の「ｄｒａｗｉｎｇ：ｓｅｔｔｅｘｔ（ｎａｍｅ＝ＴＩＣＫＥＲＴＥＸＴ８，ｔｅｘｔ＝“Ｇｏｖｔ ｔｏ ｕｓｅ ｒｅｓｅｒｖｅ ｆｕｎｄｓ ｔｏ ｉｍｐｏｒｔ Ｈ１Ｎ１ ｖａｃｃｉｎｅ”，ｆｏｎｔｓｉｚｅ＝５０％，ｆｏｎｔ＝“ＭＳ ＰＧｏｔｈｉｃ”ｒ＝１，ｇ＝１，ｂ＝１，ｓｔｙｌｅ＝ｂｏｌｄ）」は、スーパーインポーズの作成を行うカテゴリー（スクリプト）であることを示している。

更に、（３２），（３３）行目の「ｃｈａｒａｃｔｅｒ：ｔａｌｋ（ｎａｍｅ＝Ａ，ｔｅｘｔ＝“Ｗｉｔｈ ｔｈｅ Ｈ１Ｎ１ ｉｎｆｌｕｅｎｚａ ｓｐｒｅａｄｉｎｇ ａｃｒｏｓｓ Ｊａｐａｎ，ｔｈｅ ｇｏｖｅｒｎｍｅｎｔ ｉｓ ｍａｋｉｎｇ ｐｌａｎｓ ｔｏ ｉｍｐｏｒｔ ｖａｃｃｉｎｅｓ．Ｒｅｓｅｒｖｅ ｆｕｎｄｓ ｆｒｏｍ ｔｈｅ ｃｕｒｒｅｎｔ ｆｉｓｃａｌ ｙｅａｒ ｗｉｌｌ ｂｅ ｕｓｅｄ ｔｏ ｉｍｐｏｒｔ ｔｈｅ ｖａｃｃｉｎｅｓ．”，ｐｉｔｃｈ＝１．２，ｒａｔｅ＝１．０，ｖｏｌｕｍｅ＝１．０）」は、コメントの読み上げを行うカテゴリー（スクリプト）であることを示している。

また、図９は、映像コンテンツの表示結果の一例を示す図である。本実施形態により図９（ａ）においては、スーパーインポーズのスライドインの様子が示されており、図９（ｂ）においては、コメントの読み上げ（音声出力）が行われている。

このように、上述したスクリプト生成画面６０を用いることで、図８に示すような文字列を直接入力する必要がなく、スクリプト生成を容易且つ正確に行うことができる。したがって、ユーザにとっては、ツールボックスから演出コマンドをＤ＆Ｄを行うだけでよいため、従来よりも使用性の向上が実現できる。

具体的には、例えば、ローカルコンピュータ１１である「ＴＶＣｒｅａｔｏｒ」におけるプレビュー機能である「Ｆｌａｓｈ版ＴＶＣｒｅａｔｏｒ」で作成された台本データは、プレビュー時にＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式で管理サーバ１２にアップロードされ、台本データは、台本データで、ＴＶＭＬスクリプトに変換され、ＴＶＭＬ処理用のレンダリングサーバ１３に送信される。レンダリングサーバ１３は、ＴＶＭＬ描画機能を有し、リアルタイムで描画・再生を行い、その描画結果は、逐次Ｆｌａｓｈメディアサーバに送信され、ライブストリーミング配信を用いて「Ｆｌａｓｈ版ＴＶＣｒｅａｔｏｒ」に送られ、プレビューが表示される。
なお、図８の例では、映像コンテンツ記述用のスクリプト言語にＴＶＭＬ、レンダリング機能にＴＶＭＬＰｌａｙｅｒを使用しているが、本発明においてはこれに限定されるものではない。

これにより、例えば、Ｆｌａｓｈを通して３ＤＣＧや音声合成を用いた映像コンテンツをプレビューすることが可能となる。なお、本実施形態におけるブロードバンドストリーミングデータ再生手段としては、“ＭａｃｒｏｍｅｄｉａＦｌａｓｈ（登録商標）”又は“ＲｅａｌＰｌａｙｅｒ（登録商標）”又は“ＷｉｎｄｏｗｓＭｅｄｉａＰｌａｙｅｒ（登録商標）”又は“ＱｕｉｃｋＴｉｍｅ（登録商標）”の何れか１つ又は複数のストリーミングデータを用いることができる。

＜他の実施形態＞
なお、本実施形態により、ローカルコンピュータ１１は、低性能でも対応することができるため、例えばローカルコンピュータを携帯端末等として実施することもできる。

ここで、携帯端末によっては、表示できる動画の画面サイズやビットレート、動画フォーマットに制限がある。そこで、レンダリング要求の際に、これらの情報を管理サーバ１２に送信し、管理サーバ１２は、受信したそれらの情報に基づいて描画・エンコードの設定やレンダリングサーバ１３の選定を行うことができる。ここで、上述した内容について図を用いて説明する。

＜レンダリングサーバの選択方法：第１の例＞
図１０は、他の実施形態におけるレンダリングサーバの選択方法の第１の例を示す図である。なお、図１０に示す例では、ローカルコンピュータとしての携帯端末７１からのレンダリング要求(エンコーダによってレンダリングサーバを選択)の例を示している。

図１０に示すように、携帯端末７１から「エンコード：３ＧＰＰ２、画面サイズ：３２０×２４０（要ビデオ性能１００）」として描画要求があった場合、３ＧＰＰ２エンコーダを持つレンダリングサーバは、全レンダリングサーバのうち、レンダリング１３−２しかないため、管理サーバ１２はレンダリングサーバ１３−２を指定して描画要求を行う。

ここで、管理サーバ１２にスクリプト解析手段を有している場合には、例えばＴＶＭＬスクリプトでは声質として音声合成のボイス名を指定する。音声合成は、レンダリングサーバ１３毎にそのボイス(声質)の有無や、各国言語に対応しているかどうかによって、レンダリングサーバの特性が異なる。したがって、管理サーバ１２は各レンダリングサーバ１３−１〜１３−ｎにどの音声合成が入っているかを管理しており(又はレンダリングサーバ１３に問い合わせて）、ＴＶＭＬスクリプトで指定されるボイスで再生可能なレンダリングサーバに割り振るという機能が必要となる。なお、字幕等で表示するフォントについても上述と同様のことのことがいえる。

例えば、ロシア語の字幕を表示する場合、レンダリングサーバがロシア語フォントを表示できなければならず、これも管理サーバ１２でコントロールされることになる。ここで、上述の内容が具体的に管理サーバ１２でどのようにコントロールされるかについて、図を用いて具体的に説明する。

＜レンダリングサーバの選択方法：第２の例＞
図１１は、他の実施形態におけるレンダリングサーバの選択方法の第２の例を示す図である。なお、図１１に示す例では、ローカルコンピュータとしての携帯端末７１から「エンコード：ＦＬＶ、画面サイズ：６４０×４８０（要ビデオ性能２００）」としたレンダリング要求(言語(音声合成・フォント)によってレンダリングサーバを選択)の例を示している。

図１１では、スクリプト内にロシア語の音声合成の指定、及び、ロシア語のフォント表示がある例を示している。この場合、ロシア語の音声合成、フォントを備えているのが全レンダリングサーバ１３−１〜１３−３のうち、レンダリングサーバ１３−３しかないため、レンダリングサーバ１３−３を選択する。なお、本実施形態において、例えば、要求内容に対応するレンダリングサーバが無かった場合には、エラーを返す処理等を行う。

ここで、本実施形態の管理サーバ１２における負荷推定手段に関しては、クライアントからのレンダリング要求の中に画面サイズを入れ、管理サーバは各レンダリングサーバの描画能力や負荷状態をモニタリングしておき、描画サイズと描画能力・負荷状態を突き合わせて、適切なレンダリングサーバを選定するという機能が必要となる。ここで、上述の内容が具体的に管理サーバ１２でどのようにコントロールされるかについて、図を用いて具体的に説明する。

＜レンダリングサーバの選択方法：第３の例＞
図１２は、他の実施形態におけるレンダリングサーバの選択方法の第３の例を示す図である。なお、図１２に示す例では、ローカルコンピュータとしての通常のＰＣであるローカルコンピュータ１１から「エンコード：ＦＬＶ、画面サイズ：１２８０×７２０（要ビデオ性能４００）」としたレンダリング要求（ビデオ性能・負荷状態によってレンダリングサーバを選択）の例を示している。

図１２では、高負荷を要求するようなレンダリング要求の例であり、この場合には必要なビデオ性能４００を満たすレンダリングサーバがレンダリングサーバ１３−１しかないため、レンダリングサーバ１３−１を選択する。

ここで、上述した説明において、「ビデオ性能」とは、レンダリングサーバ１３のレンダリング・エンコードの性能を指標化したものであり、負荷率はそのうち何％が使用中かを表すものである。すなわち、ビデオ性能９００で負荷率５０％の場合、４５０が使用可能なビデオ性能となる。

なお、ビデオ性能は、例えばビデオメモリの量と置き換えると、ビデオメモリ１０２４ＭＢで負荷率５０％の場合、５１２ＭＢが使用中で残り５１２ＭＢが使用可能ということになる。

＜レンダリングサーバ１３及びライブエンコーダ１６について＞
次に、上述した本実施形態におけるレンダリングサーバ１３及びエンコーダ１６との関係について図を用いて具体的に説明する。図１３は、レンダリングサーバとライブエンコーダとの構成例を示す図である。本実施形態においては、レンダリング機能とライブエンコーダ機能とを、図１３（ａ）,（ｃ）に示すように１つのハードウェアで一体に構成されていてもよく、また図１３（ｂ）に示すように、それぞれを２つのハードウェアに分けて構成することもできる。

図１３（ａ）の例では、ライブエンコーダで画面をキャプチャする領域を決めて、同じ領域についてレンダリングする。この場合、レンダリング機能からライブエンコーダに対して画面映像、音声、タイミング信号が送信される。

また、図１３（ｂ）の例では、レンダリングした結果の映像音声信号をハードウェアから出力し、別ハードウェアの入力端子経由でライブエンコーダに入力する。この場合、タイミング情報は、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等の通信端子を通して送信される。これにより、外部映像音声入力を用いているため、例えば、一般的なＷｅｂカメラと同様に扱うことができる。したがって、様々なエンコーダソフトウェアに容易に対応することができる。

また、図１３（ｃ）の例では、レンダリングの映像音声出力をライブエンコーダの映像音声入力に送信する。具体的には、専用のドライバ等を作成することにより、レンダリングの映像音声出力をライブエンコーダに外部Ｗｅｂカメラとして認識させる。この場合、タイミング情報は、図１３（ａ）と同じようにソフトウェアで送信される。

図１３（ｃ）に示すように、レンダリング機能の映像音声出力を仮想的な外部映像音声入力としてハードウェアに認識させることにより、実際の映像音声信号は直接ハードウェア内でやり取りされる。これにより、図１３（ｂ）の例と同様に外部映像音声入力デバイスとして扱うことができ、更に、図１３（ｂ）に示すようにレンダリング機能とライブエンコーダを２つのハードウェアに分けることなく運用することができる。

ここで、上述したタイミング情報は、同期信号のようなものではなく、「開始」と「終了」を通知するだけのものである。したがって、レンダリング機能は、タイミングを抽出するのではなく、スクリプトを受信してレンダリングを始める際に「開始」信号を送り、スクリプトのレンダリングが終わった時点で「終了」信号を送る。

このように、タイミング情報は、「開始」、「終了」の信号であるため、エンコーダは「開始」信号を受け取って映像音声入力のエンコードを開始し、「終了」信号を受け取ってエンコードを終了する。

なお、上述した本実施形態の構成を有することにより、例えば１つのレンダリング機能を使って生成した映像音声とタイミング情報の何れかを、ライブエンコーダに入力する前に他のレンダリング機能等を使って再編集したり、映像音声とタイミング情報とをそれぞれ別のレンダリング機能から生成させたり、複数の映像音声を１つの基準となるタイミング情報を使用して映像音声ストリームを生成したりすることも可能となる。つまり、タイミング、映像、音声、それぞれ別々に入出力することができる。

上述したように本発明によれば、利用者端末における負荷及び操作負担を軽減し効率的な番組制作を実現することができる。つまり、本発明によれば、ローカルコンピュータにＣＧ描画機能、音声合成機能がなくても映像コンテンツの生成・表示が可能となる。また、携帯端末等の操作性及び処理性能の低いデバイスでも本実施形態を適用して時間的ロスがなく快適に映像コンテンツを表示させることができる。

以上本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形、変更が可能である。

１０ 番組制作システム
１１ ローカルコンピュータ（利用者端末）
１２ 管理サーバ
１３ レンダリングサーバ（番組制作装置）
１４ 配信サーバ
１５ 通信ネットワーク
１６ ライブエンコーダ
２１，３１，４１，５１ 入力手段
２２，３２，４２，５２ 出力手段
２３，３３，４３，５３ 蓄積手段
２４ スクリプト生成手段
２５ 再生手段
２６，３７，４６，５６ 送受信手段
２７，３８，４７，５７ 制御手段
３４ 負荷検出手段
３５ レンダリングサーバ選定手段
３６ コンテンツ管理手段
４４ レンダリング手段（番組制作手段）
４５ エンコード手段
５４ 配信条件設定手段
５５ 配信先選定手段
６０ スクリプト生成画面
６１ スクリプト作成領域
６２ ライブストリーミング表示領域
６３ ツールボックス表示領域
７１ 携帯端末

Claims (7)

1. ネットワークに接続された利用者端末を管理する管理サーバにより割り振られたスクリプト情報に対応させて、複数の番組制作装置により映像コンテンツを制作し、制作された映像コンテンツをライブストリーミング信号により前記利用者端末に送信する番組制作システムにおいて、
   前記複数の番組制作装置に対して、前記映像コンテンツの生成及び伝送効率を含むＣＰＵ負荷の負荷情報を検出する負荷情報検出手段と、
   前記負荷情報検出手段により検出された前記負荷情報に基づいて、前記管理サーバにより割り振られた前記スクリプト情報のうち少なくとも一部に対応する映像コンテンツを制作する番組制作手段と、
   前記番組制作手段により制作された映像コンテンツに対応するライブストリーミング信号を生成するストリーム信号生成手段と、
   を有することを特徴する番組制作システム。
2. 前記番組制作手段は、
   前記スクリプトに対応する映像コンテンツと、前記映像コンテンツからライブストリーミング信号を生成するための再生タイミング情報とを生成することを特徴とする請求項１に記載の番組制作システム。
3. 前記ストリーム信号生成手段は、
   前記利用者端末が備える映像コンテンツの再生手段に応じて、予め設定される１又は複数のデータ形式のライブストリーミング信号を生成することを特徴とする請求項１又は２に記載の番組制作システム。
4. 前記ストリーム信号生成手段は、
   前記映像コンテンツを再生し、再生された映像音声をリアルタイムにキャプチャすることでエンコードを行い、前記ライブストリーミング信号を生成することを特徴とする請求項１乃至３の何れか１項に記載の番組制作システム。
5. 前記番組制作手段は、
   前記管理サーバにより前記スクリプト情報に含まれるデータ識別情報により割り振られたスクリプト情報の一部から映像コンテンツを生成し、生成した映像コンテンツに対して前記割り振られたスクリプトを統合するための統合化情報を付加することを特徴とする請求項１乃至４の何れか１項に記載の番組制作システム。
6. 前記番組制作手段は、
   前記統合化情報を前記再生タイミング情報に付加することを特徴とする請求項５に記載の番組制作システム。
7. ネットワークに接続された利用者端末を管理する管理サーバにより割り振られたスクリプト情報に対応させて、複数の番組制作装置により映像コンテンツを制作し、制作された映像コンテンツをライブストリーミング信号により前記利用者端末に送信するための番組制作プログラムにおいて、
   コンピュータを、
   前記複数の番組制作装置に対して、前記映像コンテンツの生成及び伝送効率を含むＣＰＵ負荷の負荷情報を検出する負荷情報検出手段、
   前記負荷情報検出手段により検出された前記負荷情報に基づいて、前記管理サーバにより割り振られた前記スクリプト情報のうち少なくとも一部に対応する映像コンテンツを制作する番組制作手段、及び、
   前記番組制作手段により制作された映像コンテンツに対応するライブストリーミング信号を生成するストリーム信号生成手段、
   として機能させるための番組制作プログラム。