JP2019092186A - 配信サーバ、配信プログラムおよび端末 - Google Patents

Abstract

【課題】生配信用の映像データに演出を自動的に付加して体裁を整える。【解決手段】本発明の一態様に係る配信サーバは、受信部と、判定部と、合成部と、配信部とを含む。受信部は、配信者端末から生配信用の映像データを受信する。判定部は、演出条件が満足しているか否かを判定する。合成部は、演出条件が満足している時に、映像データに対して演出データを合成し合成映像データを生成する。配信部は、合成映像データを配信者端末および観客端末へ配信する。【選択図】 図２

Description

本発明は、動画共有システムにおける動画の生配信に関する。

近年、一部の動画共有システムでは、ユーザ（以降、単に配信者と呼ぶ）が撮影した動画を多数の観客へインターネット経由で生配信することが可能である。かかるインターネット経由で生配信される動画（以降、単に生番組と称する）でも、テレビ番組と同様に、配信者には利用可能な時間枠が割り当てられている。

テレビ番組は、通常の録画番組に限らず、生放送番組であっても、オープニング、エンディング、その他の中間演出を付けられることが多い。しかしながら、生番組の配信者が利用可能な技術および人的リソースは、通常、テレビ番組の制作会社と比べて限られているので、配信者が撮影した動画にオープニングやエンディングなどの演出を付加して生配信することは現実的に難しい。このため、生番組は、割り当てられた時間枠に合わせて生番組の本編が唐突に始まり、そして唐突に終わる、ということになりがちで、テレビ番組風の番組構成に慣れ親しんだ観客は違和感を覚えるかもしれない。

また、生配信の開始直後は配信者のフォロワーを中心とする限られた数の観客しか集まらないことも多い。配信者はなるべく多くの観客が集まってからメインの企画に入ることを望むので、しばらく手持ち無沙汰な状態で待っていたり、マイクテストを行ったり、場合によっては離席するなど、間延び感のあるシーンが続いてしまうことがある。観客は、このようなシーンに遭遇すると、退屈に感じて視聴をやめてしまうかもしれない。

特許文献１では、個人向け番組配信システムにおいて、視聴者からの配信要求を受信すると（Ｓ１００）（［００２７］）、番組コンテンツデータベースに記憶される番組コンテンツを抽出し（Ｓ１０６）、個人向けの番組コンテンツを編成し（Ｓ１０８）（［００２８］）、視聴者端末に配信すること（［００３０］）が記載されている。また、編成された個人向け番組コンテンツはタイトルとエンディングを含むこと（［００２７］，［００２９］）が記載されている。

また、特許文献２（特に、［００２２］、［００５７］、［００５９］、要約書）には、撮影した動画データから背景部分を切り取り、予め準備しておいた背景画像または動画データと合成した合成動画データを作成し、さらに合成動画データを編集してオープニングタイトルおよびエンドロールのデータを含む統合動画データを生成し、統合動画データをネットワーク経由で共有する技術が開示されている。

特開２００６−３３９７８０号公報 特開２０１６−１５４０２１号公報

特許文献１には、リアルタイムコンテンツを随時盛り込んだ状態で番組コンテンツを配信することが記載されているものの、このリアルタイムコンテンツは、例えば、定時ニュース、全国ニュース、地域限定のローカルニュース、天気予報の情報等の一般的な時事情報を含み（［００２１］）、例えば、いくつかのニュース写真の画像およびナレーションにより構成されたコンテンツ８２４ａと取材動画によるコンテンツ８２６ａ等とがまとめられることで構成されている（［００２９］）。ここで、取材動画は一般に録画済みの動画を指すから、特許文献１に記載されたリアルタイムコンテンツは、生番組とは異なる。また、個人向け番組コンテンツ８００に含まれるタイトル８１０およびエンディング８５０は、リアルタイムコンテンツ８２０とは別個のコンテンツとして扱われている（図３、［００２９］）。

特許文献２に記載の技術は、全編撮影済みの動画をベースに統合動画データを生成して共有しており、生番組への適用は想定していない。また、オープニングタイトルおよびエンドロールは、合成動画とは独立したデータであり、両者を合成することまでは想定されていない。

従って、生番組の配信にこれらの技術を適用したとしても、生番組の本編とは独立したタイトル、オープニング、エンディング、エンドロールなどが付加されるに過ぎない。故に、ユーザ発信型の生番組に特有な、開始時および終了時の唐突感、開始直後の間延び感、利用可能な表現の幅が限られることによるメリハリ感のなさ、などを改善することは容易でない。

本発明は、生配信用の映像データに演出を自動的に付加して体裁を整えることを目的とする。

本発明の第１の態様に係る配信サーバは、受信部と、判定部と、合成部と、配信部とを含む。受信部は、配信者端末から生配信用の映像データを受信する。判定部は、演出条件が満足しているか否かを判定する。合成部は、演出条件が満足している時に、映像データに対して演出データを合成し合成映像データを生成する。配信部は、合成映像データを配信者端末および観客端末へ配信する。

本発明の第２の態様に係る配信サーバは、受信部と、判定部と、加工部と、配信部とを含む。受信部は、配信者端末から生配信用の映像データを受信する。判定部は、演出条件が満足しているか否かを判定する。加工部は、演出条件が満足している時に、映像データに対して既定の加工を行って加工済み映像データを生成する。配信部は、加工済み映像データを配信者端末および観客端末へ配信する。

本発明の第３の態様に係る配信サーバは、判定部と、受信部と、生成部と、配信部とを含む。判定部は、演出条件が満足しているか否かを判定する。受信部は、配信者端末から生配信用の映像データを受信し、演出条件が満足している場合にはさらに配信者端末および観客端末の少なくとも１つから配信者端末および観客端末の少なくとも１つにおいて映像データに合成される動的な演出データに対する操作要求を受信する。生成部は、操作要求に基づいて動的な演出データの操作データを生成する。配信部は、映像データおよび操作データを配信者端末および観客端末の少なくとも１つへ配信する。

本発明の第４の態様に係る端末は、判定部と、生成部と、送信部と、受信部と、制御部と、合成部とを含む。判定部は、演出条件が満足しているか否かを判定する。生成部は、演出条件が満足している時に、ユーザ入力に応じて動的な演出データに対する操作要求を生成する。送信部は、操作要求を配信サーバへ送信する。受信部は、演出条件が満足している時に、配信サーバから生配信用の映像データおよび操作要求に基づいて生成された動的な演出データの操作データを受信する。制御部は、操作要求に基づいて動的な演出データを制御する。合成部は、映像データに動的な演出データを合成する。

本発明によれば、生配信用の映像データに演出を自動的に付加して体裁を整えることができる。

第１の実施形態に係る動画の生配信システムを例示するブロック図。 第１の実施形態に係る配信サーバを例示するブロック図。 映像データを例示する図。 図３の映像データに演出データを合成した合成映像データを例示する図。 図３の映像データに演出データを合成した合成映像データを例示する図。 図３の映像データに演出データを合成した合成映像データを例示する図。 図３の映像データに演出データを合成した合成映像データを例示する図。 図２の配信サーバの動作を例示するフローチャート。 第２の実施形態に係る配信サーバを例示するブロック図。 第１の実施形態および第２の実施形態に係る端末の変形例を示すブロック図。 第３の実施形態に係る配信サーバを例示するブロック図。 映像データを例示する図。 図１２の映像データを加工した加工済み映像データを例示する図。 図１２の映像データを加工した加工済み映像データを例示する図。 第３の実施形態に係る端末の変形例を示すブロック図。 第４の実施形態に係る配信サーバを例示するブロック図。 図３の映像データに動的な演出データを合成した合成映像データを例示する図。 図３の映像データに動的な演出データを合成した合成映像データを例示する図。 第４の実施形態に係る端末を例示するブロック図。 図１６の変形例を示すブロック図。

以下、図面を参照しながら実施形態の説明を述べる。なお、以降、説明済みの要素と同一または類似の要素には同一または類似の符号を付し、重複する説明については基本的に省略する。例えば、複数の同一または類似の要素が存在する場合に、各要素を区別せずに説明するために共通の符号を用いることがあるし、各要素を区別して説明するために当該共通の符号に加えて枝番号を用いることもある。

（第１の実施形態）
第１の実施形態に係る配信サーバは、図１に例示される動画の生配信システムに組み込むことができる。この生配信システムは、配信者端末１００と、配信サーバ２００と、観客端末３００−１，３００−２，・・・とを含む。

配信サーバ２００は、配信者端末１００および観客端末３００とネットワーク経由で接続しており、データを互いに送受信できる。なお、図１において示される各装置の数は、例示に過ぎない。例えば、観客端末３００の数は、０となることがあり得るし、数百、数千となることもあり得る。また、図１に示されない、Ｗｅｂサーバまたはコメント配信サーバがさらに設けられてもよいし、これらの機能が配信サーバ２００に組み込まれてもよい。

配信者端末１００は、例えばビデオカメラなどの動画ソースに接続されたコンピュータなどの電子デバイス、例えば、テレビ受像機（インターネットテレビを含む）、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、モバイル端末（例えば、タブレット、スマートフォン、ラップトップ、フィーチャーフォン、ポータブルゲーム機、デジタルミュージックプレイヤー、電子書籍リーダなど）、ＶＲ（Ｖｉｒｔｕａｌ Ｒｅａｌｉｔｙ）端末、ＡＲ(Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ)端末などであり得るが、これらに限られない。配信者端末１００は、動画ソースから出力されるエンコード済みの映像データを配信サーバ２００へ逐次送信する。

配信サーバ２００は、映像データの生配信に割り当てられた時間枠に亘って、配信者端末１００から逐次送信される、エンコード済みの映像データを受信する。配信サーバ２００は、基本的には、この映像データをそのまま配信者端末１００および観客端末３００へ配信する。

ただし、後述される演出条件が満足されている時には、配信サーバ２００は、映像データに後述される演出データを合成し、合成された映像データ（以降、合成映像データと称する）を配信者端末１００および観客端末３００へ配信する。かかる演出条件の満足／不満足の判定、演出データの作成、および演出データの合成は、例えば配信サーバ２００がスクリプトを実行することで実現されてもよい。

観客端末３００は、配信者端末１００と同様の電子デバイスであり得るが、配信者端末１００とは異なり動画ソースに接続される必要はない。

配信サーバ２００がこのような演出データの自動合成を行うことで、例えば、オープニング演出、エンディング演出または中間演出を、配信者は手軽に利用することができる。かかる演出の付加は配信サーバ２００によって行われるので、配信者が高度な動画編集スキル、動画編集用のハードウェアまたはソフトウェアがない、演出家などのサポーターがいない場合であっても支障がない。故に、配信者は、テレビ番組風に体裁の整った動画を容易に生配信することができる。

以下、図１中の配信サーバ２００の構成および動作について順に図面を用いて説明する。

配信サーバ２００は、コンピュータであって、配信者端末１００から受信する映像データの配信制御、演出条件の判定、演出データの作成、演出データの合成、配信者端末１００および観客端末３００から受信する種々の要求等の解釈とこれに対する応答の生成、などを行うプロセッサと、かかる処理を実現するために当該プロセッサによって実行されるプログラムおよび当該プロセッサによって使用されるデータなどを一時的に格納するメモリとを含んでいる。

配信サーバ２００は、さらに、ネットワークに接続するための通信装置と、大容量のデータを蓄積するための補助記憶装置とを利用可能である。通信装置および補助記憶装置は、配信サーバ２００に内蔵されてもよいし、配信サーバ２００に外付けされてもよい。

通信装置は、ネットワーク経由で配信者端末１００および観客端末３００と通信をする。例えば、通信装置は、配信者端末１００から映像データを受信したり、観客端末３００からの配信要求に対する応答を送信したりする。

補助記憶装置は、例えば、演出条件、演出データなどのデータを蓄積する。補助記憶装置は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）などの不揮発性記憶媒体であることが好ましい。補助記憶装置は、配信サーバ２００にネットワーク経由で接続されたファイルサーバであり得る。

次に、図２を用いて配信サーバ２００の構成例の説明を続ける。図２の配信サーバ２００は、受信部２０１と、時計部２０２と、配信制御部２０３と、演出条件判定部２０４と、演出条件記憶部２０５と、演出データ作成部２０６と、演出データ合成部２０７と、映像配信部２０８とを含む。

受信部２０１は、ネットワーク経由で種々のデータを受信する。受信部２０１は、前述の通信装置であってもよいし、当該通信装置とのインターフェースであってもよい。 具体的には、受信部２０１は、配信者端末１００から生配信用の映像データを受信する。受信部２０１は、この映像データを演出条件判定部２０４へ送る。また、受信部２０１は、観客端末３００からこの映像データの配信要求を受信する。受信部２０１は、配信要求を配信制御部２０３へ送る。

さらに、受信部２０１は、配信者端末１００または観客端末３００において所定のユーザ入力があったことを示す情報を受信し、これを演出条件判定部２０４へ送ってもよい。また、受信部２０１は、図１に示されないコメント配信サーバから上記映像データに対して投稿されたコメントを受信し、これを演出条件判定部２０４へ送ってもよい。なお、配信サーバ２００が、コメント配信サーバの機能を備える場合には、受信部２０１は配信者端末１００または観客端末３００から直接的にコメントを受信し、これを演出条件判定部２０４へ送り得る。

時計部２０２は、日時を指示する。時計部２０２は、例えば、固定周波数で振動する水晶発振器と、その出力を分周して１Ｈｚの信号を得る分周回路と、この信号をカウントして日時を示すシリアル値を得るカウンタとを含む。時計部２０２の指示する日時は、配信制御部２０３および演出条件判定部２０４によって参照され得る。

配信制御部２０３は、映像データの生配信を制御する。配信制御部２０３は、前述のプロセッサおよびメモリであってよい。
具体的には、配信制御部２０３は、時計部２０２の指示する日時と、映像データの生配信に割り当てられた時間枠とを比較し、映像データの生配信の開始および終了を管理する。また、配信制御部２０３は、観客端末３００による配信要求を受信部２０１から受け取り、当該観客端末３００へ映像データが配信されるように映像配信部２０８を制御する。なお、配信制御部２０３は、受け取った配信要求に基づいて、観客数の管理を行ってもよい。配信制御部２０３の管理する時間枠、観客数などの情報は、演出条件判定部２０４または演出データ作成部２０６によって参照され得る。

演出条件判定部２０４は、受信部２０１から映像データを受け取り、演出条件記憶部２０５から当該映像データについての演出条件を読み出し、演出条件が満足しているか否かを判定する。演出条件判定部２０４は、演出条件が満足していると判定した場合には映像データを演出データ合成部２０７へ送り、そうでなければ映像データを映像配信部２０８へ送る。演出条件判定部２０４は、前述のプロセッサおよびメモリであってよい。

演出条件判定部２０４は、演出条件が満足しているか否かを判定するために、必要に応じて、時計部２０２の指示する日時、配信制御部２０３の管理する時間枠、観客数、受信部２０１によって受信された、コメント、配信者端末１００または観客端末３００において所定のユーザ入力があったことを示す情報、映像データの再生映像または再生音声、などを参照し得る。

ここで、演出条件は、例えば、オープニング演出、エンディング演出、または中間演出を付加するか否か判定するための基準である。具体的には、オープニング演出を付加するための演出条件（オープニング演出条件）は、映像データに割り当てられた時間枠の始まりに、または、この始まりから所定時間後に設定された演出開始地点に、時計部２０２の指示する日時が到達してから、演出終了条件が満足するまでの間に満足するように定められてもよい。

オープニング演出条件は、映像データの観客数が所定の条件を満足してから演出終了条件が満足するまでの間に満足するように定められてもよい。ここでの条件は、例えば、観客数が所定数に達したことなどであり得る。

オープニング演出条件は、配信者端末１００または観客端末３００において所定のユーザ入力があってから演出終了条件が満足するまでの間に満足するように定められてもよい。所定のユーザ入力は、例えば、配信者端末１００に表示される、演出開始を指示するためのボタンなどのＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）部品を選択することであり得る。

オープニング演出条件は、映像データに対して投稿されたコメントが所定の条件を満足してから演出終了条件が満足するまでの間に満足するように定められてもよい。ここでの条件は、例えば、コメント数が所定数に達したこと、特定のキーワードを含むコメント数が所定数に達したこと、レアワードを含むコメントがあったことなどであり得る。

オープニング演出条件は、映像データの再生映像または再生音声が所定の条件を満足してから演出終了条件が満足するまでの間に満足するように定められてもよい。ここでの条件は、再生映像から例えば配信者が所定のジェスチャまたは表情を採ったことが認識されたこと、再生音声から例えば配信者が所定のフレーズを発話したことが認識されたこと、などであり得る。

オープニング演出の演出終了条件は、例えば、演出開始から所定時間が経過した時、観客数またはコメント数が必要数に達した時、または配信者端末１００若しくは観客端末３００に所定のユーザ入力があった時、映像データの再生映像から例えば配信者が所定のジェスチャまたは表情を採ったことが認識された時、再生音声から例えば配信者が所定のフレーズを発話したことが認識された時、などに満足するように定められてよい。

時間枠の始まりからずれた地点からオープニング演出を開始することにより、生配信の開始直後は映像データがそのまま配信され、観客がある程度集まった頃合いにオープニング演出が始まり、生番組の本編への観客の期待を高めて継続して視聴する動機付けをすることができる。他方、時間枠の始まりと一致またはこれに近い地点からオープニング演出を開始することにより、最初期の観客が、オープニング演出を待てず離れてしまうのを防ぐことができる。

また、エンディング演出を付加するための演出条件（エンディング演出条件）は、映像データに割り当てられた時間枠の終わりから所定時間前に設定された演出開始地点に、時計部２０２の指示する日時が到達してから、演出終了条件が満足するまでの間に満足するように定められてもよい。その他、エンディング演出条件は、前述したオープニング演出条件と同様に定められ得る。

エンディング演出の演出終了条件は、オープニング演出の演出終了条件と同様であってもよいし、映像データに割り当てられた時間枠の終わりに時計部２０２の指示する日時が達した時に満足するように定められてもよい。

中間演出は、例えば、映像データに割り当てられた時間枠の途中で、例えばファンファーレなどの演出映像、映像データにリプレイ映像またはスローモーション再生映像を合成することで実現されてもよい。リプレイ映像またはスローモーション再生映像は、直前の映像を対象としてもよいがこれに限られない。また、生番組がマルチカメラで撮影されている場合には、別視点の映像を合成し、或いは視点の切り替えを行ってもよい。

中間演出を付加するための演出条件（中間演出条件）は、映像データに割り当てられた時間枠の始まりから所定時間後に設定された演出開始地点に、時計部２０２の指示する日時が到達してから、演出終了条件が満足するまでの間に満足するように定められてもよい。また、中間演出条件は、生番組に付与された広告や商品紹介を配信者または観客がクリックした場合または、広告や商品紹介の対象となった商品を配信者または観客が購入した場合に、その購入の所定時間後から演出終了条件が満足するまでの間に満足するように定められてもよい。ここで、広告や商品紹介は、例えば配信者端末１００または観客端末３００において、生番組の表示ページ内、または当該表示ページから遷移可能なページで表示され得る。その他、中間演出条件は、前述したオープニング演出条件と同様に定められ得る。また、中間演出の演出終了条件は、オープニング演出の演出終了条件と同様であってもよい。

例えば、映像データの観客数、または映像データに対して投稿されたコメント数が急上昇した時に、ファンファーレの映像を合成する中間演出が開始するようにしてもよい。また、例えば「リプレイ」、「スロー」、「もう１回」などの特定のキーワードを含むコメントが映像データに対して所定時間内に所定数以上投稿された時に、リプレイ映像またはスローモーション再生映像を合成する中間演出が開始するようにしてもよい。

演出条件記憶部２０５は、前述の種々の演出条件を格納する。演出条件記憶部２０５に格納された演出条件は、演出条件判定部２０４および演出データ作成部２０６によって必要に応じて読み出される。演出条件記憶部２０５は、前述の補助記憶装置であってもよいし、当該補助記憶装置とのインターフェースであってもよい。

演出データ作成部２０６は、演出データを作成し、演出データ合成部２０７へ送る。演出データ作成部２０６は、前述のプロセッサおよびメモリであってよい。
演出データは、動的な演出データと静的な演出データとに大別することができる。静的な演出データは、映像データの内容に左右されない固定の動画データまたは静止画データであり得る。固定の動画データは、例えば、生配信対象の映像データの再生映像をはめ込むための領域を有する、様々なアニメーションまたは実写映像であってもよい。固定の静止画データは、例えば、映像データの再生映像の画面端を装飾する枠、映像データの再生映像の覆うオブジェクトなどであってもよい。なお、後述する動的な演出データを利用しない場合には、静的な演出データをプリセットしておくことにより、演出データ作成部２０６を省略することができる。

動的な演出データは、例えば、演出終了条件が満足するための必要条件を動的に示す情報を含む動画データまたは静止画データであってもよいし、映像データの生配信が開始された後に生じた事象に関する情報を含む動画データまたは静止画データであってもよいし、生配信の対象となる映像データのリプレイ映像またはスローモーション再生映像であってもよいし、別視点の映像であってもよいし、例えば動画タイトル、クレジットタイトル、配信者コメントまたは説明文などを含む動画データまたは静止画データであってもよい。かかる情報は、配信者、観客もしくはサービス運営者が生配信の開始前に入力した情報、または配信サーバ２００またはその他のサーバにより自動的に付与された情報から抽出され得る。例えば、演出データは、生番組に対して付与されたキーワードである動画タグ、または生番組に対して付与されたスポンサー名、などのメタデータから自動的に生成される情報、例えば、番組カテゴリ、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）、などを含む動画データまたは静止画データであってもよい。ここで、動画タグおよびスポンサー名は、配信者、観客またはサービス運営者により人力で付与されることもあり得るし、配信サーバ２００またはその他のサーバにより自動的に付与されることもあり得る。

さらに、動的な演出データは、生番組に関連するウェブページに表示される情報に基づいて自動的に生成されてもよい。例えば、動画像共有サービスのフロントページなどの番組紹介ページでは、現在公開中の多数の生番組のサムネイルが並べて表示されることがある。そして、かかる番組紹介ページでは、サムネイルの周辺に、例えば「人気上昇中」などの生番組に関する補足情報が表示されることがある。かかる補足情報が付与されたサムネイルに対応する生番組には、当該補足情報そのものまたは当該補足情報から抽出・加工された情報を含む演出データが適用されてもよいし、適用される演出データが当該補足情報に依存して切り替えられてもよい。例えば、補足情報から抽出された情報に基づいて自動的に編集された番組タイトル、補足情報から抽出されたスポンサー名、などが演出データに含まれてもよい。

具体的には、演出データ作成部２０６は、演出終了条件が満足するための必要条件として、映像データの現在の観客数またはコメント数と必要数とのギャップを、例えばカウントダウン形式で示す情報、例えば「あと○○人」、「あと○○コメント」などのテキストを含む演出データを作成してもよい。映像データの現在の観客数またはコメント数の情報は、例えば配信制御部２０３から取得することができる。また、演出終了条件が満足するために必要な観客数またはコメント数の情報は、例えば演出条件記憶部２０５から取得することができる。かかる情報が表示されることで、観客は、生番組の本編開始までの目安時間を把握し、それまで待てるかどうか、また、離席してよいのかどうかの判断をすることができる。

また、演出データ作成部２０６は、映像データの生配信が開始された後に生じた事象に関する情報として、例えば映像データの観客数、映像データに対して投稿されたコメントの一部（例えばダイジェスト）、映像データに対して投稿されたコメント数、および映像データに対してコメントを投稿した観客名、生番組に付与された広告や商品紹介のクリック数、広告や商品紹介から購入された商品に関する情報（例えば商品の名称、購入数、購入総額、写真、購入者情報など）、などを示す情報を含む演出データを作成してもよい。かかる情報を例えばエンドロールとして用いることで、個々の映像データの生配信の態様にふさわしいエンディング演出が可能となる。

また、演出データ作成部２０６は、配信者端末１００または観客端末３００になされたユーザ入力、または配信者端末１００または観客端末３００によって投稿されたコメントに反応して変化する演出データを作成してもよい。例えば、演出データは、映像データの再生映像の画面を遮るオブジェクト（例えば、紙吹雪、拍手を意味する「８」のシンボル、花束、ハートマーク、雲、人垣、配信者の設定したアイコン、動画像共有サービスのマスコットキャラクターなど）を含んでいてもよい。

この場合に、演出データ作成部２０６は、演出開始時に、画面全体にかかるオブジェクトが敷き詰められた演出データを作成し、配信者端末１００または観客端末３００に所定のユーザ入力（例えばオブジェクト、またはボタンなどのＧＵＩの選択）またはコメント投稿がなされると、オブジェクトを消滅、移動、縮小させるなどして徐々に映像データの再生映像の画面が見えるようにしてもよい。逆に、演出データ作成部２０６は、演出開始時に、オブジェクトを零または少数含む演出データを作成し、配信者端末１００または観客端末３００に所定のユーザ入力（例えばオブジェクト、またはボタンなどのＧＵＩの選択）、またはコメント投稿がなされると、オブジェクトを出現、移動、拡大させるなどして徐々に映像データの再生映像の画面が見えなくなるようにしてもよい。

徐々に映像データの再生映像の画面が見えるようにする演出は、オープニングに適しているがこれに限定されるものではない。徐々に映像データの再生映像の画面が見えなくなる演出は、エンディングに適しているがこれに限定されるものではない。

なお、オブジェクトの状態が全端末間で完全に同期していなかったとしても、生番組の本編の視聴体験には影響しないので、同期を行う頻度を減らしてサーバの負荷を軽減してもよい。

また、この例において、演出終了条件がオブジェクトの数、大きさ、位置などによって定められてもよい。この場合に、配信者および観客は、合成映像データの再生映像に含まれるオブジェクトの状態から演出終了条件が満足するための必要条件、例えばあとどれくらいオブジェクトを減らす必要があるのか、あとどれくらいオブジェクトを増やす必要があるのかを把握し得る。故に、かかるオブジェクトもまた、演出終了条件が満足するための必要条件を動的に示す情報の一例に相当する。

演出データ合成部２０７は、演出条件判定部２０４から映像データを受け取り、演出データ作成部２０６から演出データを受け取る。演出データ合成部２０７は、映像データに演出データを合成し、合成映像データを生成する。演出データ合成部２０７は、例えば、アルファブレンド、ピクチャーインピクチャーなどの公知の技法を用いて、映像データに演出データを合成してもよい。演出データ合成部２０７は、合成映像データを映像配信部２０８へ送る。演出データ合成部２０７は、前述のプロセッサおよびメモリであってよい。なお、合成に用いられる演出データの種類は、所定のアルゴリズムにより自動的に決定されてもよいし、配信者および／または観客のユーザ入力情報により決定されてもよいし、両者の組み合わせにより決定されてもよい。例えば、生番組に付与された広告や商品紹介のクリック数、広告や商品紹介から購入された商品に関する情報、例えば商品の購入数、購入総額など、の情報により、エンディング演出に用いられる演出データが切り替えられてもよい。

演出データ合成部２０７は、例えば、映像データの再生映像の画面の一部または全部をリサイズして、または画面の一部をトリミングして演出データと合成してもよいし、映像データの再生映像の画面の一部が露出し、残部が隠れるように映像データを演出データと合成してもよい。図３に映像データを例示し、図４乃至図７に合成映像データを例示する。

演出データ合成部２０７は、図４に例示されるように、図３の映像データの再生映像の画面の一部（例えば、配信者の顔領域）および全部をそれぞれ小さくリサイズして、演出データとしての動画データまたは静止画データにはめ込んでもよい。また、図４の例では、クレジットタイトルとして、「出演 ○○○」のテキストが演出データに含まれている。このように、映像データの再生映像の画面の全部を小さくリサイズしてから演出データと合成することで、画面が演出データによってマスクされないようにすることができる。故に、配信者が観客に見せたい部分が演出データによって隠されてしまうハプニングを防ぐことができる。他方、映像データの再生映像の画面の全部ではなく一部を小さく、または大きくリサイズしてから演出データと合成すれば、配信者が観客に見せたい部分を過度に縮小しないように、或いはより強調することができる。画面の一部は、例えば画面の中心に近い領域など静的な領域であってもよいし、配信者の顔がある領域、動きの大きい領域など動的な領域であってもよい。動的な領域を抽出する場合には、例えば、公知の顔認識技術、動体検出技術などが利用されてよい。

このように、映像データの再生映像の画面のリサイズを行ってから演出データと合成することで、配信者および観客に、生番組の本編とは異なる特別な演出が付加されていることを意識させることができる。

演出データ合成部２０７は、図５および図６に例示されるように、図３の映像データに演出データを合成し、映像データの再生映像の画面を遮るオブジェクトが合成された合成映像データを生成してもよい。図５の例では、演出開始時には、画面一杯にテレビをモチーフとするマスコットキャラクターのシルエットのオブジェクトが敷き詰められており、観客（および配信者）がこのオブジェクトを例えばタップしていくことで、オブジェクトが徐々に消え去り、演出が完了する。また、図６の例では、演出開始時には、画面下部に「８」のシンボルが少数積もった状態、または積もっていない状態であり、観客（および配信者）が例えば画面をタップ、または「８」のコメントを投稿することで、このオブジェクトが徐々に積もっていき、演出が完了する。なお、図５および図６の演出において、ユーザ入力が全くない場合にも時間経過に応じて、オブジェクトが自動的に消え去り、またはオブジェクトが自動的に積もるようにしてもよい。

演出データ合成部２０７は、図７に例示されるように、図３の映像データの再生映像の画面の全部を小さくリサイズしてから、エンドロールを表示するための領域を含む演出データを合成してもよい。図７の例では、図３の映像データの観客数、コメント投稿した観客名などの情報がエンドロールの一部として表示される。なお、図７の例は、エンディング演出に限られず、例えば生配信の前半部分を締めくくるための中間演出として適用されてもよい。

映像配信部２０８は、演出条件判定部２０４からの映像データ、または演出データ合成部２０７からの合成映像データを受け取り、これを配信者端末１００および観客端末３００へ配信する。映像配信部２０８は、例えば映像データの配信先などを配信制御部２０３によって制御される。映像配信部２０８は、前述の通信装置であってもよいし、当該通信装置とのインターフェースであってもよい。

なお、映像配信部２０８は、配信済みの映像データ（または合成映像データ）を直ちに破棄してもよいが、例えば前述のリプレイまたはスローモーション再生を伴う演出を可能とするために所定期間バッファリングしておき、演出データ作成部２０６による参照を許容してもよい。

次に図８を用いて、配信サーバ２００の動作例を説明する。図８の動作は、例えば映像データに割り当てられた時間枠の始まりと共に開始する。図８の動作が開始すると、処理はステップＳ４０１へ進む。

ステップＳ４０１において、受信部２０１は配信者端末１００から生配信用の映像データを受信する。演出条件判定部２０４は、ステップＳ４０１において受信された映像データについて予め定められた演出条件が満足するか否かを判定する（ステップＳ４０２）。演出条件が満足すれば処理はステップＳ４０３へ進み、そうでなければ処理はステップＳ４０５へ進む。

ステップＳ４０３において、演出データ合成部２０７は、ステップＳ４０１において受信された映像データを演出データと合成する。なお、演出データ合成部２０７は、映像データの再生映像のリサイズ、トリミングなどの加工を必要に応じて行ってから、演出データと合成してもよい。そして、映像配信部２０８は、ステップＳ４０３において生成された合成映像データを観客端末３００へ配信する（ステップＳ４０４）。他方、ステップＳ４０５において、映像配信部２０８は、ステップＳ４０１において受信された映像データを観客端末３００へ配信する。

ステップＳ４０４またはステップＳ４０５の終了時に、時計部２０２の指示する日時が、生配信対象の映像データに割り当てられた時間枠の終わりに達していたならば図８の動作は終了し、そうでなければ処理はステップＳ４０１に戻る（ステップＳ４０６）。

以上説明したように、第１の実施形態に係る配信サーバは、生配信用の映像データに対して演出データを条件付きで自動合成する。これにより、配信者は、高度な動画編集スキルやリソースを必要とすることなく、例えばオープニング演出、エンディング演出、中間演出などが付加されテレビ番組風に体裁の整った動画を容易に生配信することができる。

特に、オープニング演出を付加することにより、配信者および観客に生番組の始まりを意識させ、配信者がマイクテスト、休憩を取るなどして準備を整えたり、生番組の本編に入る前にコメントを介して観客とコミュニケーションを取ったり、観客に間延び感をあまり感じさせずることなく生番組の本編の開始を待ってもらったりすることができる。

また、エンディング演出を付加することにより、配信者および観客に生番組の終わりを意識させ、配信者がまとめに入ったり、次回予告を行ったり、観客とコメントを介してコミュニケーションを取ったりするなどの時間を取りやすくなる。

さらに、中間演出として、盛り上がった場面でファンファーレなどの配信者を鼓舞する映像効果を加えたり、決定的瞬間のリプレイ、スローモーション再生を可能としたりすることで、生配信において利用可能な表現の幅を広げることができる。

（第２の実施形態）
第２の実施形態に係る配信サーバは、生配信用の映像データおよび演出データをどのように合成するかを配信者および／または観客が指定することができる。具体的には、どのようなレイアウト（位置合わせ）で両者を合成するか、すなわち一方または両方をどれだけ平行移動させるかを指定したり、一方または両方に対する回転、反転、リサイズおよび／またはトリミングの設定を指定したりすることが可能である。

図９に第２の実施形態に係る配信サーバ５００が例示される。以降の説明では、配信サーバ５００と配信サーバ２００との相違点を中心に述べる。配信サーバ５００は、映像データの生配信に割り当てられた時間枠に亘って、配信者端末１００から逐次送信される、エンコード済みの映像データを受信する。配信サーバ５００は、演出条件が満足されている時には、映像データに演出データを配信者および／または観客の指定に従って合成し、合成映像データを配信者端末１００および観客端末３００へ配信する。ここで、演出条件は、第１の実施形態において説明した演出条件と同一または類似であり得る。

配信サーバ５００がこのような演出データの自動合成を配信者および／または観客の指定に従って行うことで、第１の実施形態において説明した、オープニング演出、エンディング演出または中間演出の表現の幅をさらに広げることができる。例えば、映像データを演出データに対してはめ込み合成する場合に、より自然に見えるようにしたり、敢えて不自然に見えるようにしたりすることが可能となる。

以下、配信サーバ５００の機能的構成について図９を用いて説明する。なお、配信サーバ５００のハードウェア構成は、配信サーバ２００と同一または類似であり得るのでこれに関する説明を省略する。

配信サーバ５００は、受信部５０１と、時計部５０２と、配信制御部５０３と、演出条件判定部５０４と、演出条件記憶部５０５と、演出データ作成部５０６と、演出データ合成部５０７と、映像配信部５０８とを含む。このうち、時計部５０２、配信制御部５０３、演出条件記憶部５０５、演出データ作成部５０６および映像配信部５０８は、それぞれ配信サーバ２００における同名の要素と同一または類似であり得る。以下、その他の要素について、配信サーバ２００における同名の要素との相違点を中心に説明する。

受信部５０１は、受信部２０１によって受信されるデータに加えて、配信者端末１００および／または観客端末３００から指定データを受信し得る。この指定データは、生配信用の映像データおよび演出データをどのように合成するかを指定する。具体的には、指定データは、映像データおよび演出データの合成位置、映像データの拡大／縮小率、演出データの拡大／縮小率、映像データの回転量、演出データの回転量、映像データにおける特定の領域、ならびに演出データにおける特定の領域、などを指定し得る。受信部５０１は、この指定データを演出条件判定部５０４へ送る。

演出条件判定部５０４は、演出条件が満足している場合に、映像データに加えて指定データを演出データ合成部５０７へ送る。なお、配信者および観客が生配信用の映像データおよび演出データをどのように合成するかを特に指定しなければ、指定データが存在しないこともあり得る。

演出データ合成部５０７は、演出条件判定部５０４から映像データおよび指定データを受け取り、演出データ作成部５０６から演出データを受け取る。演出データ合成部５０７は、指定データに従って映像データおよび／または演出データに前処理を行ってから両者を合成し、合成映像データを生成する。

具体的には、指定データが映像データおよび演出データの合成位置を指定する場合に、演出データ合成部５０７は、映像データおよび／または演出データを平行移動させて両者の合成位置を制御し得る。

また、指定データが映像データの拡大／縮小率、および／または演出データの拡大／縮小率を指定する場合に、演出データ合成部５０７は、映像データおよび／または演出データをリサイズし得る。さらに、指定データが映像データの回転量、および／または演出データの回転量を指定する場合に、演出データ合成部５０７は映像データおよび／または演出データを回転し得る。ここで、回転は、画像平面上での２次元的な回転に限らず、上下反転および左右反転、ならびにこれら組み合わせを含む３次元的な回転を意味し得る。

さらに、指定データが映像データにおける特定の領域、および／または演出データにおける特定の領域を指定する場合に、演出データ合成部５０７は、映像データおよび／または演出データにおいて指定された領域をトリミングし得る。

演出データ合成部５０７が、以上のような前処理を行うことで、配信者および／観客の好みに合わせて、映像データおよび演出データを合成することが可能となる。一例として演出データが顔抜きフレームなどである場合に映像データの顔と顔抜きフレームのはめ込み部分とを自然に見えるように、または敢えて不自然に見えるように合成することが可能となる。

以上説明したように、第２の実施形態に係る配信サーバは、映像データおよび演出データをどのように合成するかを指定する指定データを配信者端末および／または観客端末から受信し、これに従って映像データおよび／または演出データに前処理を行ってから両者を合成する。故に、この配信サーバによれば、第１の実施形態において説明した、オープニング演出、エンディング演出または中間演出の表現の幅をさらに広げることが可能となる。

（変形例）
ところで、前述の第１の実施形態および本実施形態では配信サーバが映像データおよび演出データを合成する。これにより、配信者および観客の視聴する合成映像データを同期させやすい、端末の処理負荷を減らすことができる、といったメリットがある。配信サーバから端末への通信量の削減というメリットもある。しかしながら、端末が映像データおよび演出データを合成することも可能である。以下、簡単に説明する。

この変形例に係る端末６００を図１０に例示する。なお、端末６００は、配信者端末および観客端末のどちらであってもよいので、配信者端末および観客端末それぞれに固有の部分については説明を省略する。

端末６００は、配信者端末１００に関して説明した種々の電子デバイスであり得る。端末６００は、例えば、入出力制御、通信制御、演出条件の判定、演出データの作成、映像データおよび演出データの合成、などを行うプロセッサを含む。ここで、プロセッサは、典型的にはＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）および／またはＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）であるが、マイコン、ＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）、またはＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、などであってもよい。また、端末６００は、かかる処理を実現するためにプロセッサによって実行されるプログラムおよび当該プロセッサによって使用されるデータなどを一時的に格納するメモリを含んでいる。

なお、端末６００は、全てのデータをオンメモリの状態で扱ってもよいし、一部のデータが補助記憶装置に退避されていてもよい。補助記憶装置は、例えば、端末６００に内蔵または外付けされたＨＤＤ、ＳＳＤ、フラッシュメモリなどであってもよいし、端末６００からアクセス可能なデータベースサーバであってもよい。

また、端末６００は、複数の電子デバイスの組み合わせであってよい。例えば、端末６００における異なる機能部が別個の電子デバイスに分散して実装されてもよい。

端末６００は、さらに、ネットワークに接続するための通信Ｉ／Ｆ（インターフェース）、コンテンツを出力するための出力装置、などを利用可能である。通信Ｉ／Ｆおよび／または表示装置は、端末６００に内蔵されてもよいし、端末６００に外付けされてもよい。

通信Ｉ／Ｆは、ネットワーク経由で、配信サーバ５００（もしくは配信サーバ２００）または図示されない他のサーバと通信をするためのモジュールであり得る。出力装置は、動画像、静止画像、テキストなどを表示するための表示装置および／または音声、楽曲などを出力するためのスピーカを含み得る。表示装置は、例えば、液晶ディスプレイ、有機ＥＬ（ｅｌｅｃｔｒｏｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）ディスプレイなどである。なお、表示装置は、タッチスクリーンのように入力装置の機能を備えていてもよい。

端末６００は、受信部６０１と、演出条件判定部６０４と、演出条件記憶部６０５と、演出データ作成部６０６と、演出データ合成部６０７と、表示制御部６０８とを含む。

受信部６０１は、ネットワーク経由で例えば配信サーバ５００から種々のデータを受信し、受信したデータを例えば演出条件判定部６０４へ送る。受信部６０１は、前述の通信Ｉ／Ｆであってもよい。

具体的には、受信部６０１は、生配信用の映像データを受信する。この映像データは、配信者端末１００から配信サーバ５００へ送信（アップロード）された映像データそのものであってもよいし、これに何らかの加工、例えば再エンコード、を施したものであってもよい。また、受信部６０１は、前述の指定データを受信することもあり得る。この指定データは、例えば配信サーバ５００により配信者端末１００および／または観客端末３００から収集され、各端末６００へ配信されたものであり得る。さらに、受信部６０１は、例えば第１の実施形態において説明した、演出条件の判定に必要なデータを受信し得る。

演出条件判定部６０４は、演出条件判定部５０４（または演出条件判定部２０４）と同一または類似であり得る。すなわち、演出条件判定部６０４は、受信部６０１から映像データ（および指定データ）を受け取り、演出条件記憶部６０５から演出条件を読み出し、演出条件が満足しているか否かを判定する。演出条件判定部６０４は、演出条件が満足していると判定した場合には映像データおよび指定データを演出データ合成部６０７へ送り、そうでなければ映像データを表示制御部６０８へ送る。演出条件判定部６０４は、前述のプロセッサおよびメモリであってよい。

演出データ作成部６０６は、演出データ作成部２０６と同一または類似であり得る。すなわち、演出データ作成部６０６は、演出データを作成し、演出データ合成部６０７へ送る。演出データ作成部２０６は、前述のプロセッサおよびメモリであってよい。

演出データ合成部６０７は、演出データ合成部５０７（または演出データ合成部２０７）と同一または類似であり得る。すなわち、演出データ合成部６０７は、演出条件判定部６０４から映像データおよび指定データを受け取り、演出データ作成部６０６から演出データを受け取る。演出データ合成部６０７は、指定データに従って映像データおよび／または演出データに前処理を行ってから両者を合成し、合成映像データを生成する。演出データ合成部６０７は、合成映像データを表示制御部６０８へ送る。演出データ合成部６０７は、前述のプロセッサおよびメモリであってよい。

表示制御部６０８は、前述の表示装置を制御し、映像データまたは合成映像データを当該表示装置の画面に表示する。表示制御部６０８は、例えば前述のプロセッサおよびメモリであってよい。

以上説明したように、この変形例に係る端末は、第１の実施形態および第２の実施形態において説明した、映像データおよび演出データの合成を行う。故に、この端末によれば、配信サーバがかかる機能を利用可能でない場合にも、第１の実施形態および第２の実施形態において説明した演出を生配信用の映像データに付加することが可能となる。なお、図１０の例では、端末が演出条件の判定を行っているが、配信サーバが演出条件の判定を行うようにさらに変形することも可能である。

（第３の実施形態）
前述の第１の実施形態および第２の実施形態では、映像データに演出データを合成することにより演出が実現される。第３の実施形態に係る配信サーバは、生配信用の映像データそのものを加工することで演出を実現する。

図１１に第３の実施形態に係る配信サーバ７００が例示される。以降の説明では、配信サーバ７００と配信サーバ２００または配信サーバ５００との相違点を中心に述べる。配信サーバ７００は、映像データの生配信に割り当てられた時間枠に亘って、配信者端末１００から逐次送信される、エンコード済みの映像データを受信する。配信サーバ７００は、演出条件が満足されている時には、映像データを加工し、加工済み映像データを配信者端末１００および観客端末３００へ配信する。ここで、演出条件は、第１の実施形態において説明した演出条件と同一または類似であり得る。

配信サーバ７００がこのような映像データの加工を行うことで、第１の実施形態および第２の実施形態において説明した演出とは異なる表現の演出を利用することができる。例えば、映像データの特定の領域（例えば、顔領域）または全領域にフィルターをかける加工があり得る。フィルターは、例えば、モザイク、セピア、モノクロ、レトロ、ぼかし、暗視スコープ風エフェクト、歪み、漫画風エフェクト、などの様々な各種エフェクトを付加することで、映像データの視覚的な印象を変えることができる。さらに、映像データの特定の領域の複製を当該映像データに貼り付ける、という加工もあり得る。

以下、配信サーバ７００の機能的構成について図１１を用いて説明する。なお、配信サーバ７００のハードウェア構成は、配信サーバ２００または配信サーバ５００と同一または類似であり得るのでこれに関する説明を省略する。

配信サーバ７００は、受信部７０１と、時計部７０２と、配信制御部７０３と、演出条件判定部７０４と、演出条件記憶部７０５と、映像加工部７０７と、映像配信部７０８とを含む。このうち、映像加工部７０７以外の要素は、それぞれ配信サーバ２００または配信サーバ５００における同名の要素と同一または類似であり得る。故に、以下、映像加工部７０７を説明する。

映像加工部７０７は、演出条件判定部７０４から映像データ（および指定データ）を受け取る。まず、映像加工部７０７は、指定データを受け取った場合には映像データに第２の実施形態において説明した前処理を行う。それから、映像加工部７０７は、演出条件判定部７０４からの映像データ、またはこれに前処理を行った映像データに対して、既定の加工を行って加工済み映像データを生成する。映像加工部７０７は、加工済み映像データを映像配信部７０８へ送る。映像加工部７０７は、前述のプロセッサおよびメモリであってよい。

具体的には、映像加工部７０７は、前述のフィルターのいずれかを映像データに対して適用してもよい。或いは、映像加工部７０７は、映像データの特定の領域の複製を当該映像データに貼り付けてもよい。例えば、図１２のような映像データに対して、映像加工部７０７は図１３または図１４に例示される加工を行ってもよい。

図１３の例では、破線で示す中心軸よりも左側の領域の複製を左右反転した映像が当該中心軸よりも右側に貼り付けられている。なお、反転の基準となる対象軸の数、それぞれの位置および角度は、自動的に決定されてもよいし、配信者および／または観客が例えば指定データを通じて指定可能としてもよい。

図１４の例では、映像データ中の人物周辺の領域の複製そのもの、または当該複製に前処理を施した映像が、破線で示す領域に貼り付けられている。なお、映像データ中のいずれの領域を複製するか、複製に前処理を行うか否か、複製にどのような前処理を行うか、および貼り付けの位置および数、などは、自動的に決定されてもよいし、配信者および／または観客が例えば指定データを通じて指定可能としてもよい。

以上説明したように、第３の実施形態に係る配信サーバは、映像データを加工することで演出を実現する。故に、この配信サーバによれば、第１の実施形態および第２の実施形態において説明した演出とは異なる表現の演出を利用することができる。

（変形例）
ところで、本実施形態では配信サーバが映像データを加工する。これにより、配信者および観客の視聴する合成映像データを同期させやすい、端末の処理負荷を減らすことができる、といったメリットがある。配信サーバから端末への通信量の削減というメリットもある。しかしながら、端末が映像データを加工することも可能である。以下、簡単に説明する。

この変形例に係る端末８００を図１５に例示する。なお、端末８００のハードウェア構成は、端末６００と同一または類似であり得るのでこれに関する説明を省略する。また、端末８００は、配信者端末および観客端末のどちらであってもよいので、配信者端末および観客端末それぞれに固有の部分については説明を省略する。

端末８００は、受信部８０１と、演出条件判定部８０４と、演出条件記憶部８０５と、映像加工部８０７と、表示制御部８０８とを含む。このうち、映像加工部８０７以外の要素は、端末６００における同名の要素と同一または類似であり得る。故に、以下、映像加工部８０７を説明する。

映像加工部８０７は、映像加工部７０７と同一または類似であり得る。すなわち、映像加工部８０７は、演出条件判定部８０４から映像データ（および指定データ）を受け取る。まず、映像加工部８０７は、指定データを受け取った場合には映像データに第２の実施形態において説明した前処理を行う。それから、映像加工部８０７は、演出条件判定部８０４からの映像データ、またはこれに前処理を行った映像データに対して、第３の実施形態において説明した既定の加工を行って加工済み映像データを生成する。映像加工部８０７は、加工済み映像データを映像配信部７０８へ送る。映像加工部８０７は、前述のプロセッサおよびメモリであってよい。

以上説明したように、この変形例に係る端末は、第３の実施形態において説明した、映像データの加工を行う。故に、この端末によれば、配信サーバがかかる機能を利用可能でない場合にも、第３の実施形態において説明した演出を生配信用の映像データに付加することが可能となる。なお、図１５の例では、端末が演出条件の判定を行っているが、配信サーバが演出条件の判定を行うようにさらに変形することも可能である。

（第４の実施形態）
前述の第１の実施形態では、映像データに対して動的な演出データを合成して演出することが可能である。第４の実施形態では、この動的な演出データを配信者および／または観客からの操作要求に応じて制御することでインタラクティブ性の高い演出を実現する。

図１６に第４の実施形態に係る配信サーバ９００が例示される。以降の説明では、配信サーバ９００と配信サーバ２００、配信サーバ５００または配信サーバ７００との相違点を中心に述べる。

配信サーバ９００は、映像データの生配信に割り当てられた時間枠に亘って、配信者端末１００から逐次送信される、エンコード済みの映像データを受信する。配信サーバ９００は、演出条件が満足されている時には、配信者端末１００および／または観客端末３００から映像データに合成される動的な演出データに対する操作要求を受信し、これに基づいて当該動的な演出データの操作データを生成する。そして、配信サーバ９００は、映像データに加えてこの操作データを配信者端末１００および観客端末３００へ送信する。配信者端末１００および観客端末３００は、それぞれ受信した操作データに基づいて動的な演出データを制御し、受信した映像データに合成して表示装置の画面に表示する。ここで、演出条件は、第１の実施形態において説明した演出条件と同一または類似であり得る。

配信サーバ９００が操作要求に基づいてこのような動的な演出データの操作データを生成、配信し、配信者端末１００および観客端末３００が当該操作データに基づいて動的な演出データを制御して映像データに合成することで、インタラクティブ性の高い演出が可能となる。

以下、配信サーバ９００の機能的構成について図１６を用いて説明する。なお、配信サーバ９００のハードウェア構成は、配信サーバ２００、配信サーバ５００または配信サーバ７００と同一または類似であり得るのでこれに関する説明を省略する。

配信サーバ９００は、受信部９０１と、時計部９０２と、配信制御部９０３と、演出条件判定部９０４と、演出条件記憶部９０５と、映像配信部９０８と、操作データ生成部９０９とを含む。このうち、時計部９０２、配信制御部９０３、および演出条件記憶部９０５は、それぞれ配信サーバ２００、配信サーバ５００または配信サーバ７００における同名の要素と同一または類似であり得る。以下、その他の要素について、配信サーバ２００、配信サーバ５００または配信サーバ７００における同名の要素との相違点を中心に説明する。

受信部９０１は、受信部２０１によって受信されるデータに加えて、配信者端末１００および／または観客端末３００から、動的な演出データに対する操作要求を受信し得る。この操作要求は、例えば動的な演出データを生成する種々のツール、例えば、お絵かきアプリ、手書き入力アプリ、ストップウォッチ、タイマー、カウンタ、サイコロ、トランプ、おみくじ、ビンゴゲーム、じゃんけんゲーム、静止画ビューワを含む生配信中に引用するコンテンツのプレイヤー、などを操作するために対応するプログラムに与えられる入力データ、例えばオブジェクトの選択など、に相当し得る。受信部９０１は、この操作要求を演出条件判定部９０４へ送る。

演出条件判定部９０４は、演出条件の判定結果に関わらず、映像データを映像配信部９０８へ送る。さらに、演出条件判定部９０４は、演出条件が満足している場合に、操作要求を操作データ生成部９０９へ送る。なお、配信者および観客が操作要求を発行するための入力を行っていなければ、操作要求が存在しないこともあり得る。

操作データ生成部９０９は、演出条件判定部９０４から操作要求を受け取り、これに基づいて動的な演出データの操作データを生成する。操作データ生成部９０９は、操作データを映像配信部９０８へ送る。操作データ生成部９０９は、前述のプロセッサおよびメモリであってよい。なお、複数の端末が操作要求を略同時に送信すると、操作要求の衝突が生じ得る。すなわち、ある端末からの操作要求が、他の端末からの操作要求と矛盾することがあるが、操作データ生成部９０９はかかる衝突の調停を行ってから操作データを生成してもよい。

また、多数の端末から操作要求を略同時に送信し、操作データ生成部９０９が当該操作要求を全て考慮して操作データを生成することは負荷が大きい。そこで、上記衝突の調停とも関連するが、操作データ生成部９０９は、操作要求の一部を破棄するフィルタリングを行い、残余の操作要求に基づいて操作データを生成してもよい。一例として、操作データ生成部９０９は、観客のうち課金をした者、配信者のチャンネル会員である者、特定の地域に居る者、抽選に当選した者、などからの操作要求を維持し、他の操作要求を破棄してもよい。

本実施形態において動的な演出データは、少なくとも操作データに応じて画面遷移、すなわち外観的な変化を生じる映像データであり得る。具体的には、操作データに応じた画面遷移の例として、トランプの山札を選択する操作データに応じた手札の画像の更新、サイコロを選択する操作データに応じたサイコロの出目の更新、手書き入力に基づく操作データに応じたお絵かき画像の更新、などが挙げられる。また、操作データに加えて時間の経過に応じた画面遷移もあり得る。例えば、スタートのボタンを選択する操作データに応じて、ストップウォッチまたはタイマーの表示部の画像がカウントダウンまたはカウントアップするように変化し始める。以後の表示部の画像は、時間の経過に応じて更新されることになる。

画面遷移は、全端末共通であってもよいし、そうでなくてもよい。後者の例として、動的な演出データは、図１７および図１８に例示されるじゃんけんゲームの実行画面データであってもよい。この例では、当初、図１７に示されるように選択可能な手を表す画像が映像データに合成され、操作データ生成部９０９は、既定の締め切り時間まで配信者および／または観客からの操作要求を待ち受け、当該締め切り時間の終了後に操作データを生成する。締め切り時間の終了後、じゃんけんの結果を表す画像への画面遷移が生じる。この結果、配信者端末１００は、図１８に例示されるように、観客との勝負の結果、例えば配信者が選んだ手と、３つの手毎にその手を選んだ人数とを表す演出データを生成し、映像データに合成することができる。また、観客端末３００は、配信者との勝負の結果、例えば配信者が選んだ手と、当該観客端末３００を操作した観客が選んだ手とを表す演出データを生成し、映像データに合成することができる。或いは、配信者端末１００および／または観客端末３００は、勝者〜名、敗者〜名、あいこ〜名のように勝敗結果の集計を表す演出データを生成し、映像データに合成してもよい。

映像配信部９０８は、演出条件判定部９０４から映像データを受け取り、さらに操作データ生成部９０９から操作データを受け取ることもある。映像配信部９０８は、映像データ（および操作データ）を配信者端末１００および観客端末３００へ配信する。

図１９に第４の実施形態に係る端末１０００が例示される。以降の説明では、端末６００または端末８００との相違点を中心に述べる。なお、端末１０００のハードウェア構成は、端末６００または端末８００と同一または類似であり得るのでこれに関する説明を省略する。また、端末１０００は、配信者端末および観客端末のどちらであってもよいので、配信者端末および観客端末それぞれに固有の部分については説明を省略する。

端末１０００は、受信部１００１と、演出条件判定部１００４と、演出条件記憶部１００５と、演出データ制御部１００６と、演出データ合成部１００７と、表示制御部１００８と、入力部１０１０と、操作要求生成部１０１１と、送信部１０１２とを含む。このうち、演出条件記憶部１００５、演出データ合成部１００７および表示制御部１００８は、それぞれ端末６００または端末８００における同名の要素と同一または類似であり得る。以下、その他の要素について、端末６００または端末８００における同名の要素との相違点を中心に説明する。

入力部１０１０は、ユーザ入力を受け取り、ユーザ入力データを生成する。入力部１０１０は、ユーザ入力データを演出条件判定部１００４へ送る。入力部１０１０は、端末１０００に内蔵され、または外付けされた入力装置であり得る。入力装置は、例えば、キーボード、マウス、テンキーなどであってもよいし、タッチスクリーンのように表示装置の機能を備えていてもよい。ユーザ入力は、典型的には、タップ、クリック、特定のキーの押下などであり、ユーザ入力データはこれらイベントの発生を表すデータであり得る。このほか、ユーザ入力データは、例えば、マイクロフォンによって捉えられる音声、生体センサによって検出される生体データ（例えば体温、表情など）、ＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）または基地局情報によって識別される位置データ、加速度センサによって検出される加速度データに基づいて推定されるユーザのアクション（例えば、端末１０００を振り回した）などを含むこともできる。

演出条件判定部１００４は、演出条件が満足している場合に、ユーザ入力データを操作要求生成部１０１１へ送る。

操作要求生成部１０１１は、演出条件判定部１００４からユーザ入力データを受け取り、これに応じて操作要求を生成する。操作要求生成部１０１１は、この操作要求を送信部１０１２へ送る。操作要求生成部１０１１は、前述のプロセッサおよびメモリであってよい。

送信部１０１２は、操作要求生成部１０１１から操作要求を受け取り、これを配信サーバ９００へ送信する。送信部１０１２は、前述の通信Ｉ／Ｆであってもよい。

受信部１００１は、生配信用の映像データを受信する。この映像データは、配信者端末１００から配信サーバ９００へ送信（アップロード）された映像データそのものであってもよいし、これに何らかの加工を施したものであってもよい。また、受信部１００１は、演出条件が満足している時には、操作データを受信し得る。さらに、受信部１００１は、前述の指定データ、演出条件の判定に必要なデータ、などを受信することもあり得る。受信部１００１は、操作データを演出データ制御部１００６へ送り、映像データおよび指定データを演出データ合成部１００７へ送り、演出条件の判定に必要なデータを演出条件判定部１００４へ送る。

演出データ制御部１００６は、受信部１００１から操作データを受け取り、当該操作データに基づいて動的な演出データを制御する。具体的には、演出データ制御部１００６は、前述の種々のツールに対応するプログラム（アプリケーション）を実行しており、当該プログラムに操作データを与える。なお、操作データは、時間データと当該時間データに対応する操作入力データとを含み得る。この場合に、演出データ制御部１００６は、時間データの示す時間に、当該時間データに対応する操作入力データをプログラムに与え得る。プログラムは、与えられた操作入力データに応じて画面遷移する映像を実行結果、すなわち動的な演出データとして生成し得る。演出データ制御部１００６は、動的な演出データを演出データ合成部１００７へ送る。演出データ制御部１００６は、前述のプロセッサおよびメモリであってよい。ここで、プログラムは、生配信用の映像データを再生するためのプレイヤーに組み込まれていてもよいし、当該プレイヤーから見て外部プログラムであってもよい。

以上説明したように、第４の実施形態に係る配信サーバは、動的な演出データに対する操作要求を配信者端末および／または観客端末から収集し、当該動的な演出データの操作データを生成、配信する。そして、本実施形態に係る端末は、この操作データに基づいて動的な演出データを制御し、生配信用の映像データに合成する。故に、この配信サーバおよび端末によれば、例えば配信者および観客がリアルタイムに一緒に遊ぶなどのインタラクティブ性の高い演出が可能となる。

（変形例）
ところで、本実施形態では端末が動的な演出データの制御と、映像データおよび動的な演出データの合成とを行っている。しかしながら、配信サーバが、動的な演出データの制御を行い、映像データに合成されるべき演出データを端末に逐次送信することも可能であるし、第１の実施形態と同様に映像データと動的な演出データとの合成までも行ってもよい。これにより、配信者および観客の視聴する合成映像データを同期させやすい、端末の処理負荷を減らすことができる、といったメリットがある。配信サーバが、動的な演出データの制御と映像データおよび動的な演出データの合成とを行う例について簡単に説明する。

この変形例に係る配信サーバ１１００を図２０に例示する。なお、配信サーバ１１００のハードウェア構成は、配信サーバ２００、配信サーバ５００、配信サーバ７００または配信サーバ９００と同一または類似であり得るのでこれに関する説明を省略する。

配信サーバ１１００は、受信部１１０１と、時計部１１０２と、配信制御部１１０３と、演出条件判定部１１０４と、演出条件記憶部１１０５と、演出データ制御部１１０６と、演出データ合成部１１０７と、映像配信部１１０８と、操作データ生成部１１０９とを含む。このうち、受信部１１０１、時計部１１０２、配信制御部１１０３、演出条件判定部１１０４、演出条件記憶部１１０５、演出データ合成部１１０７、映像配信部１１０８、および操作データ生成部１１０９は、配信サーバ２００、配信サーバ５００、配信サーバ７００または配信サーバ９００における同名の要素と同一または類似であり得る。故に、以下、演出データ制御部１１０６を説明する。

演出データ制御部１１０６は、演出データ制御部１００６と同一または類似であり得る。すなわち、演出データ制御部１１０６は、操作データ生成部１１０９から操作データを受け取り、当該操作データに基づいて動的な演出データを制御する。演出データ制御部１１０６は、動的な演出データを演出データ合成部１１０７へ送る。演出データ制御部１１０６は、前述のプロセッサおよびメモリであってよい。

以上説明したように、この変形例に係る配信サーバは、第４の実施形態において説明した演出を行い、合成映像データを配信者端末および観客端末へ配信する。故に、この配信サーバによれば、配信者および観客の視聴する合成映像データを同期させやすい、端末の処理負荷を減らすことができる、といったメリットがある。配信サーバから端末への通信量の削減というメリットもある。

なお、本実施形態では、端末および配信サーバの両方が演出条件の判定を行っているが、一方のみが行うようにしてもよい。例えば、端末のみが演出条件の判定を行い、演出条件が満足したことを配信サーバに通知してもよい。逆に、配信サーバのみが演出条件の判定を行い、演出条件が満足したことを端末に通知してもよい。

上述の実施形態は、本発明の概念の理解を助けるための具体例を示しているに過ぎず、本発明の範囲を限定することを意図されていない。実施形態は、本発明の要旨を逸脱しない範囲で、様々な構成要素の付加、削除または転換をすることができる。

上記各実施形態において説明された種々の機能部は、回路を用いることで実現されてもよい。回路は、特定の機能を実現する専用回路であってもよいし、プロセッサのような汎用回路であってもよい。

上記各実施形態の処理の少なくとも一部は、汎用のコンピュータを基本ハードウェアとして用いることでも実現可能である。上記処理を実現するプログラムは、コンピュータで読み取り可能な記録媒体に格納して提供されてもよい。プログラムは、インストール可能な形式のファイルまたは実行可能な形式のファイルとして記録媒体に記憶される。記録媒体としては、磁気ディスク、光ディスク（ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ等）、光磁気ディスク（ＭＯ等）、半導体メモリなどである。記録媒体は、プログラムを記憶でき、かつ、コンピュータが読み取り可能であれば、何れであってもよい。また、上記処理を実現するプログラムを、インターネットなどのネットワークに接続されたコンピュータ（サーバ）上に格納し、ネットワーク経由でコンピュータ（クライアント）にダウンロードさせてもよい。

１００・・・配信者端末
２００，５００，７００，９００，１１００・・・配信サーバ
２０１，５０１，６０１，７０１，８０１，９０１，１００１，１１０１・・・受信部 ２０２，５０２，７０２，９０２，１１０２・・・時計部
２０３，５０３，７０３，９０３，１１０３・・・配信制御部
２０４，５０４，６０４，７０４，８０４，９０４，１００４，１１０４・・・演出条件判定部
２０５，５０５，６０５，７０５，８０５，９０５，１００５，１１０５・・・演出条件記憶部
２０６，５０６，６０６・・・演出データ作成部
２０７，５０７，６０７，１００７，１１０７・・・演出データ合成部
２０８，５０８，７０８，９０８，１１０８・・・映像配信部
３００・・・観客端末
６００，８００，１０００・・・端末
６０８，８０８，１００８・・・表示制御部
７０７，８０７・・・映像加工部
９０９，１１０９・・・操作データ生成部
１００６，１１０６・・・演出データ制御部
１０１０・・・入力部
１０１１・・・操作要求生成部
１０１２・・・送信部

Claims (17)

1. 配信者端末から生配信用の映像データを受信する受信部と、
   演出条件が満足しているか否かを判定する判定部と、
   前記演出条件が満足している時に、前記映像データに対して演出データを合成し合成映像データを生成する合成部と、
   前記合成映像データを前記配信者端末および観客端末へ配信する配信部と
   を具備する、配信サーバ。
2. 前記演出条件は、（１）前記映像データの生配信のために割り当てられた時間枠内に設定された演出開始地点に前記配信サーバの参照する日時が達してから第１の演出終了条件が満足するまで、（２）前記映像データの観客数が所定の条件を満足してから第２の演出終了条件が満足するまで、（３）前記配信者端末または前記観客端末へ所定のユーザ入力があってから第３の演出終了条件が満足するまで、（４）前記映像データに対して投稿されたコメントが所定の条件を満足してから第４の演出終了条件が満足するまで、および（５）前記映像データの再生映像または再生音声が所定の条件を満足してから第５の演出終了条件が満足するまで、のうち少なくとも１つの間に満足する、請求項１に記載の配信サーバ。
3. 前記第１の演出終了条件、前記第２の演出終了条件、前記第３の演出終了条件、前記第４の演出終了条件および前記第５の演出終了条件のいずれかが満足するための必要条件を動的に示す情報を含む前記演出データを作成する作成部をさらに具備する、請求項２に記載の配信サーバ。
4. 前記作成部は、前記映像データの観客数またはコメント数と必要数とのギャップを示す情報を含む前記演出データを作成する、請求項３に記載の配信サーバ。
5. 前記映像データの生配信が開始された後に生じた事象に関する情報を含む前記演出データを作成する作成部をさらに具備する、請求項１または請求項２に記載の配信サーバ。
6. 前記作成部は、前記映像データの観客数、前記映像データに対して投稿されたコメントの一部、前記映像データに対して投稿されたコメント数、および前記映像データに対してコメントを投稿した観客名のうち少なくとも１つを示す情報を含む前記演出データを作成する、請求項５に記載の配信サーバ。
7. （１）前記配信者端末および前記観客端末の少なくとも一方になされたユーザ入力、ならびに（２）前記配信者端末および前記観客端末の少なくとも一方によって投稿されたコメント、のうち少なくとも一方に反応して変化する演出データを作成する作成部をさらに具備する、請求項１または請求項２に記載の配信サーバ。
8. 前記映像データに付与されたメタデータおよび前記映像データに関連するウェブページに表示される情報の少なくとも一方に基づいて生成された情報を含む前記演出データを作成する作成部をさらに具備する、請求項１または請求項２に記載の配信サーバ。
9. 前記合成部は、前記映像データの再生映像の画面の一部または全部をリサイズして前記演出データと合成し、前記合成映像データを生成する、請求項１乃至請求項７のいずれか１項に記載の配信サーバ。
10. 前記合成部は、前記映像データの再生映像の画面の一部が露出し、残部が隠れるように前記映像データを前記演出データと合成し、前記合成映像データを生成する、請求項１乃至請求項７のいずれか１項に記載の配信サーバ。
11. コンピュータを、
    配信者端末から生配信用の映像データを受信する手段、
    演出条件が満足しているか否かを判定する手段、
    前記演出条件が満足している時に、前記映像データに対して演出データを合成し合成映像データを生成する手段、
    前記合成映像データを前記配信者端末および観客端末へ配信する手段
    として機能させるための配信プログラム。
12. 前記受信部は、前記配信者端末および前記観客端末の少なくとも１つから前記映像データおよび前記演出データの合成位置、前記映像データの拡大／縮小率、前記演出データの拡大／縮小率、前記映像データの回転量、前記演出データの回転量、前記映像データにおける特定の領域、ならびに前記演出データにおける特定の領域の少なくとも１つを指定する指定データをさらに受信し、
    前記合成部は、前記指定データに従って前記映像データおよび前記演出データの少なくとも一方に対して平行移動、リサイズ、回転、反転およびトリミングの少なくとも１つを行ってから前記映像データおよび前記演出データを合成し、前記合成映像データを生成する、
    請求項１乃至請求項１０のいずれか１項に記載の配信サーバ。
13. 配信者端末から生配信用の映像データを受信する受信部と、
    演出条件が満足しているか否かを判定する判定部と、
    前記演出条件が満足している時に、前記映像データに対して既定の加工を行って加工済み映像データを生成する加工部と、
    前記加工済み映像データを前記配信者端末および観客端末へ配信する配信部と
    を具備する、配信サーバ。
14. 前記加工部は、前記演出条件が満足している時に、前記映像データにおける特定の領域の複製をそのまま、または回転、反転およびリサイズの少なくとも１つを行ってから、前記映像データに貼り付け、前記加工済み映像データを生成する、請求項１３に記載の配信サーバ。
15. 演出条件が満足しているか否かを判定する判定部と、
    配信者端末から生配信用の映像データを受信し、前記演出条件が満足している場合にはさらに前記配信者端末および観客端末の少なくとも１つから前記配信者端末および前記観客端末の少なくとも１つにおいて前記映像データに合成される動的な演出データに対する操作要求を受信する受信部と、
    前記操作要求に基づいて前記動的な演出データの操作データを生成する生成部と、
    前記映像データおよび前記操作データを前記配信者端末および観客端末の少なくとも１つへ配信する配信部と
    を具備する、配信サーバ。
16. 前記動的な演出データは、前記操作データに応じて画面遷移する映像データである、請求項１５に記載の配信サーバ。
17. 演出条件が満足しているか否かを判定する判定部と、
    前記演出条件が満足している時に、ユーザ入力に応じて動的な演出データに対する操作要求を生成する生成部と、
    前記操作要求を配信サーバへ送信する送信部と、
    前記演出条件が満足している時に、前記配信サーバから生配信用の映像データおよび前記操作要求に基づいて生成された前記動的な演出データの操作データを受信する受信部と、
    前記操作要求に基づいて前記動的な演出データを制御する制御部と、
    前記映像データに前記動的な演出データを合成する合成部と、
    を具備する、端末。