(実施形態1)
本実施形態に係る映像配信システム10は、図1に示すように、取得部12と、変換部13と、蓄積部14と、配信部15とを備えている。
取得部12は、カメラ2で撮影された映像コンテンツをカメラ2から取得する。変換部13は、映像コンテンツを配信用の標準フォーマットのデータファイルに変換する。蓄積部14は、データファイルを蓄積する。配信部15は、データファイルを蓄積部14から読み出して端末装置3へ配信する。
この映像配信システム10において、変換部13は、映像コンテンツに含まれる映像データについてはコーデックを変えることなく、映像コンテンツをデータファイルに変換するように構成されている。
さらに、本実施形態に係る映像配信システム10は、複数のイベントの開始時刻および終了時刻を示すスケジュールが予め登録されている管理部11を備えている。
そして、取得部12は、スケジュールに従って、カメラ2で撮影された映像コンテンツをカメラ2から取得する。変換部13は、複数のイベントの各々に対応付けて、映像コンテンツを配信用の標準フォーマットのデータファイルに変換する。蓄積部14は、複数のイベントの各々に対応付けて、データファイルを蓄積する。配信部15は、複数のイベントの中のいずれかが端末装置3から指定されると、指定されたイベントに対応するデータファイルを蓄積部14から読み出して端末装置3へ配信する。
ここでいうイベントは、たとえば大学や塾での授業、会議、講演会等のように、開始時刻および終了時刻が事前に決められており、且つ、主として教室や会議室などの特定の空間で行われるイベントである。なお、スケジュール上の開始時刻および終了時刻は、日付を含んでいてもよく、あるイベントについてたとえば開始時刻「2013年12月1日9時00分」、終了時刻「2013年12月1日10時30分」というように設定される。
以下、本実施形態に係る映像配信システム10について詳しく説明する。ただし、以下に説明する映像配信システム10は、本発明の一例に過ぎず、本発明は、下記実施形態に限定されることはなく、この実施形態以外であっても、本発明に係る技術的思想を逸脱しない範囲であれば、設計等に応じて種々の変更が可能である。
本実施形態では、大学の教室で講師が行う講義形式の授業(イベント)の映像をカメラ2で撮影し、この映像を、ネットワークを介して受講者に提供するために用いられる場合を例として、映像配信システム10の構成および機能を説明する。この例では、大学の関係者が映像配信システム10の管理者となり、受講者(学生)が映像配信システム10のユーザとなる。
ここでは、大学において予め定められた時間割に従って行われる授業をイベントの一例とする。時間割では、月曜日から金曜日までの各曜日について、開始時刻および終了時刻で規定される単位時間ごとに、それぞれの教室で行われる予定の授業が割り当てられている。たとえば、火曜日の1時限目(9:00〜10:30)は教室Aで「量子力学」、火曜日の2時限目(10:40〜12:10)は教室Aで「電子工学」、教室Bで「日本史」というように授業が割り当てられる。
本実施形態の映像配信システム10は、このような授業の映像を、音声と共にネットワーク経由でユーザである受講者の持つ端末装置3へ配信する。これにより、受講者においては、大学にて行われる授業を、遠隔地からでも受講することが可能になる。とくに、本実施形態の映像配信システム10は主として、収録した映像コンテンツをデータファイルにして蓄積部14に一旦蓄積(保存)し、端末装置3からの要求に応じて、蓄積部14から読み出した映像(データファイル)を端末装置3へ配信する。そのため、受講者においては、収録済みの授業を、自分の都合のよい時間帯に視聴することができる。本実施形態の映像配信システム10はさらに、開講中の授業の映像をリアルタイムで端末装置3へ配信する機能も備えている。
ただし、本発明に係る映像配信システム10は、このような授業の映像配信に限らず、会議、講演会等の開始時刻および終了時刻が事前に決められているイベントの映像配信に、広く適用可能である。また、映像配信システム10は、少なくとも映像を配信する機能があればよく、音声の配信については必須の機能ではない。さらに、映像配信システム10は、少なくとも蓄積部14に蓄積した映像を配信する機能があればよく、映像をリアルタイムで配信する機能も必須の機能ではない。
次に、本実施形態の映像配信システム10のハードウェア構成について、図2を参照して説明する。映像配信システム10は、図2に示すように、LAN(Local Area Network)スイッチ4に接続された映像配信装置1を、主構成として備えている。映像配信装置1は、ルータ(図示せず)を介してインターネット等のネットワーク100に接続されており、ネットワーク100には端末装置3が接続される。
映像配信装置1は、CPU(Central Processing Unit)およびメモリを有するコンピュータであって、メモリに格納されたプログラムを実行することにより、後述する管理部11、取得部12、変換部13、蓄積部14、配信部15としての機能を実現する。ここでいうプログラムは、コンピュータを映像配信装置1として機能させるプログラムである。
映像配信装置1は、専用のアプリケーション(アプリケーションソフト)をインストールし、このアプリケーションを実行することにより、映像配信装置としての機能を実現する。映像配信装置1として用いられるコンピュータは、上記プログラムを予めメモリに格納していてもよいし、インターネット等の電気通信回線を通じて、あるいは当該プログラムが記憶された記憶媒体からプログラムの提供を受けてもよい。
LANスイッチ4は、スイッチングハブ(レイヤ2スイッチ)であって、図2に示すように、カメラ2およびマイク5に接続されている。すなわち、映像配信装置1は、構内網(LAN)を介してカメラ2およびマイク5と接続されている。
カメラ2は、CCD(Charge Coupled Devices)やCMOS(Complementary Metal-Oxide Semiconductor)のようなイメージセンサ(撮像素子)を有し、撮影した映像を電気信号に変換して出力する。カメラ2で撮影される映像は、ここでは動画とするが、動画に限らず静止画であってもよい。カメラ2は、撮影した映像を、たとえばH.264あるいはH.265などのコーデック(codec)で圧縮し、映像コンテンツとして、映像配信装置1へ出力するように構成されている。このようなカメラ2としては、専用のカメラではなく、LAN接続の機能を持つ汎用のIP(Internet Protocol)カメラ(ネットワークカメラ)が用いられる。
マイク5は、音声を電気信号に変換するマイク本体51と、マイクアンプ52とを有している。マイク5は、マイク本体51に入力された音声を、たとえばG.711やAAC(Advanced Audio Coding)などのコーデックの音声データとして、マイクアンプ52から映像配信装置1へ出力する。なお、マイク本体51とマイクアンプ52とは一体であってもよい。さらに、マイク5はカメラ2に一体化(内蔵)されていてもよい。
カメラ2およびマイク5は、授業が行われる教室に設置される。カメラ2は、少なくとも黒板や白板(ホワイトボード)等の情報表示板6の全体が映るように、配置および向きが設定される。マイク5は、少なくとも授業を行う講師H1の音声を拾えるように、配置および向きが設定される。好ましくは、カメラ2およびマイク5はブラケット(図示せず)によって教室の天井に取り付けられる。
授業が行われる教室が複数ある場合、カメラ2およびマイク5は、教室ごとに設置されていてもよいし、特定の教室のみに設置されていてもよい。本実施形態では、「教室A」と「教室B」と「教室C」とのそれぞれに、カメラ2およびマイク5が設置されていると仮定する。ただし、図2では、教室Aに設けられた1組のカメラ2およびマイク5のみを図示し、教室Bおよび教室Cに設けられたカメラ2およびマイク5の図示を省略している。
なお、映像配信装置1は、カメラ2およびマイク5に対して有線接続されることは必須ではなく、無線LAN等の無線通信によってカメラ2およびマイク5からデータ(映像データ、音声データ)を受信するように構成されていてもよい。
端末装置3は、受講者(ユーザ)が所有するパソコン(パーソナルコンピュータ)、タブレット端末、スマートフォン等であって、各種の表示を行う表示機能およびユーザの操作入力を受け付ける入力機能といったユーザインタフェースを有している。さらに、端末装置3は、有線または無線通信により、ネットワーク100に接続する機能を有している。ここでは、端末装置3は、Webブラウザの機能を搭載しており、映像配信装置1からネットワーク100経由で配信される映像コンテンツを再生(表示)する。つまり、映像配信装置1がサーバ、端末装置3がクライアントとして機能する。
具体的には、端末装置3は、ユーザインタフェースや通信機能に加えて、CPUおよびメモリを有するコンピュータであって、メモリに格納されたプログラムを実行することにより、端末装置としての機能を実現する。ここでいうプログラムは、コンピュータを端末装置3として機能させるプログラムである。
端末装置3は、専用のアプリケーション(アプリケーションソフト)をインストールし、このアプリケーションを実行することにより、端末装置としての機能を実現する。端末装置3として用いられるコンピュータは、上記プログラムを予めメモリに格納していてもよいし、インターネット等の電気通信回線を通じて、あるいは当該プログラムが記憶された記憶媒体からプログラムの提供を受けてもよい。ただし、端末装置3は、少なくともWebブラウザの機能があればよく、専用のアプリケーションは必須ではない。
受講者が複数人いる場合、端末装置3は、全ての受講者が個別に有していてもよいし、特定の受講者のみが有していてもよい。本実施形態では、複数人の受講者がそれぞれ端末装置3を有していると仮定する。ただし、図2では、1台の端末装置3のみを図示し、他の端末装置3の図示を省略している。
映像配信システム10は、本実施形態では映像配信装置1とカメラ2と端末装置3、さらにマイク5とLANスイッチ4とを構成要素として備えることとするが、この構成に限らず、少なくとも映像配信装置1を構成要素に含んでいればよい。つまり、映像配信システム10は、映像配信装置1がカメラ2や端末装置3に対して通信可能に接続されていればよく、カメラ2や端末装置3、マイク5、LANスイッチ4については構成要素に含まなくてもよい。さらに、マイク5やLANスイッチ4は、省略されてもよい。
以上説明した構成の映像配信システム10は、カメラ2、マイク5、LANスイッチ4のいずれにも、特殊な装置を用いる必要がなく、汎用の装置を用いることができるので、システムの導入コストを低く抑えることができる。さらに、映像配信装置1および端末装置3についても、汎用のコンピュータを用いることができるので、映像配信システム10は導入コストを低く抑えることができる。
なお、カメラ2やマイク5は、上述した構成に限らず、たとえばスマートフォンやタブレット端末に搭載されているカメラ、マイクを利用してもよい。
次に、映像配信システム10の主構成である映像配信装置1について、図1を参照して詳しく説明する。図1では、マイク5がカメラ2に一体化(内蔵)されていることとし、マイク5の図示を省略する。そのため、カメラ2から映像配信装置1に入力されるデータは、映像データと音声データとを含んでいる。以下では、音声付きの映像コンテンツを単に「映像コンテンツ」というが、映像コンテンツが音声付きであることは必須ではない。
なお、図1では複数台のカメラ2を図示しており、各カメラ2を区別する場合には、教室Aに設置されたカメラ2を「21」、教室Bに設置されたカメラ2を「22」、教室Cに設置されたカメラ2を「23」という。また、図1では、第1〜3の端末装置3を図示しており、各端末装置3を区別する場合には、第1の端末装置3を「31」、第2の端末装置3を「32」、第3の端末装置3を「33」という。
映像配信装置1は、図1に示すように、管理部11と、取得部12と、変換部13と、蓄積部14と、配信部15とを有している。ここでは、映像配信装置1は、取得部12および変換部13を含む収録ブロック110と、配信部15を含む配信ブロック120とに分かれている。ただし、収録ブロック110と配信ブロック120とは、機能的に分かれているだけであって、物理的には一体である。さらに、本実施形態に係る映像配信装置1は、収録ブロック110に設けられた記録部16と、配信ブロック120に設けられたプロトコル変換部17とを、上記の構成の加えて有している。
また、映像配信装置1は、各種の表示を行う表示機能およびユーザの操作入力を受け付ける入力機能といったユーザインタフェースを有していてもよい。あるいは、映像配信装置1は、パソコン等の他装置と通信を行うことにより、他装置をユーザインタフェースとして利用する構成であってもよい。
管理部11は、複数の授業(イベント)の開始時刻および終了時刻を示すスケジュールが、授業の時間割に従って予め登録されている。ここでは、映像配信システム10の管理者(大学の関係者)が、映像配信システム10に管理者IDでログインすることにより、映像配信装置1は管理モードとなり、ユーザインタフェースを用いて管理部11へのスケジュールの登録が可能になる。そのため、映像配信システム10の管理者は、予め映像配信装置1を管理モードで動作させ、時間割に従って複数の授業の開始時刻および終了時刻を入力することによって、管理部11にスケジュールを登録する。
具体的には、管理部11は、GUI(Graphical User Interface)を利用したカレンダー上でスケジュールを管理する。つまり、管理部11は、たとえば図3に示すように、1ヶ月の各日についてセルが設定されたテーブルTA1上で、スケジュールを管理する。映像配信システム10の管理者は、このテーブルTA1の各セルに対し、開始時刻および終了時刻で規定される単位時間ごとに各教室で行われる予定の授業を割り当てることにより、スケジュールを登録する。単位時間を規定している開始時刻および終了時刻は変更可能である。
図3の例では、たとえば4月1日(月曜日)の1時限目(9:00〜10:30)に教室Aで行われる「政治経済」の授業について、開始時刻「2013年4月1日9時00分」、終了時刻「2013年4月1日10時30分」というように設定される。同様に、4月1日(月曜日)の2時限目(10:40〜12:10)に教室Aで行われる「数学」の授業について、開始時刻「2013年4月1日10時40分」、終了時刻「2013年4月1日12時10分」というように設定される。
図3においては、括弧内の数字が何時限目かを表しており、たとえば火曜日の2時限目の「電子工学」と「日本史」とのように、同一の単位時間に割り当てられている授業は別々の教室で行われる授業である。また、管理部11は、同一の科目であっても、開始時刻(日付を含む)および終了時刻(日付を含む)ごとに個別の授業(イベント)として登録している。たとえば4月1日(月曜日)の1時限目の「政治経済」と、4月8日(月曜日)の1時限目の「政治経済」とは別の授業として登録される。スケジュールには、各授業が行われる教室を特定するための教室情報も含まれている。
このようにして管理部11に登録されたスケジュールは、端末装置3にて表示可能である。ここでは、映像配信システム10のユーザ(受講者)が、映像配信システム10にユーザIDでログインすることにより、映像配信装置1は通常モードとなり、管理部11に登録されているスケジュールを端末装置3に表示させることができる。そのため、ユーザは、図3に例示するようなテーブルTA1上でスケジュールを確認することで、自身が受講する授業の時間割を確認できる。
また、管理部11は、映像配信装置1に設けられている構成に限らず、たとえば映像配信装置1と通信可能な他のコンピュータで実現されていてもよいし、クラウド(クラウドコンピューティング)によって実現されてもよい。
取得部12は、カメラ2から出力される映像コンテンツ(音声付き)を、RTSP(Real Time Streaming Protocol)を使用してストリーミング方式で取得する。ここで、取得部12は、管理部11に登録されているスケジュールに従ってカメラ2から映像コンテンツを取得する。具体的には、取得部12は、管理部11からスケジュールを読み出し、登録されているいずれかの授業の開始時刻になれば、その授業が行われる教室のカメラ2から映像コンテンツを取得し始め、その授業の終了時刻になれば、映像コンテンツの取得を終了する。
しかも、本実施形態では、取得部12は、複数台のカメラ21〜23から映像コンテンツを並行して取得可能に構成されている。つまり、取得部12は、複数台のカメラ21〜23で撮影されている映像を同時に取得できる。ここでは、取得部12が並行して映像コンテンツを取得可能なカメラ2の台数は、最大20台であると仮定する。
取得部12は、カメラ2から取得した映像コンテンツを、たとえばハードディスクドライブ等の記憶装置からなる記録部16に一旦記録(録画)する。このとき、取得部12は、少なくとも撮影日時を表すタイムスタンプと、撮影場所である教室を表す教室情報とに対応付けて、映像コンテンツを記録部16に記録する。ここでいう教室情報は、個々の教室A,B,Cを識別するための情報であって、各教室に設置されているカメラ2の識別情報と予め一対一に対応付けられている。したがって、記録部16に記録された映像コンテンツからは、映像が撮影された日時と、映像が撮影された教室とを特定可能である。
ここで、取得部12は、カメラ2から取得した映像コンテンツを記録部16に安定して記録し続けるために、映像配信装置1のメモリをバッファとして使用する。つまり、取得部12は、映像配信装置1とカメラ2との間の通信状況などによって、カメラ2からのデータの伝送速度と、記録部16への書込み速度との間にずれを生じることがある。このような場合でも、取得部12は、メモリをバッファとして使用することにより、記録部16へのデータの書込み(記録)を安定して継続できる。
なお、映像配信装置1は、記録部16に記録した映像コンテンツを一定期間(たとえば3日間)経過すると自動的に消去するように構成されている。
変換部13は、記録部16に記録されている映像コンテンツを、各授業に対応付けて、配信用の標準フォーマットのデータファイルに変換する。変換部13は、本実施形態では配信用の標準フォーマットとしてmp4のファイル形式を採用することとするが、この構成に限らず、たとえばflvやaviなど、任意のファイル形式を標準フォーマットとして採用できる。
具体的には、変換部13は、管理部11からスケジュールを読み出し、各授業の開始時刻から終了時刻までの間の該授業が行われた教室の映像コンテンツ(音声付き)を記録部16から読み出して、該授業と対応付けてデータファイルに変換する。これにより、変換部13によって変換(作成)された各データファイルは、それぞれ対応付けられた授業の内容を収録した映像コンテンツとなる。
ここで、一般的な映像配信システムは、映像データおよび音声データを配信用のデータファイルに変換する場合、映像データと音声データとの両方について変換を行う。たとえ変換後のデータファイルにおいて元の映像データと同様のコーデックが使用される場合であっても、一般的な映像配信システムは、映像データを一旦デコードしてから再度エンコードする方式が一般的である。ただし、映像配信システムにてこのような変換を行うと、CPUに掛かる負荷が大きくなり、且つ変換に必要な時間も長くなる。
そこで、本実施形態に係る映像配信システム10では、変換部13は、カメラ2から取得した映像コンテンツ(音声付き)のうち、映像部分(映像データ)についてはそのまま使用し、ファイルコンテナのみを変更してファイル化するように構成されている。言い換えれば、変換部13は、映像コンテンツに含まれる映像データについてはコーデックを変えることなく、映像コンテンツをデータファイルに変換するように構成されている。たとえば、変換部13は、元の映像データのコーデックがH.264である場合、映像データについてデコードおよびエンコードを一切行わず、H.264のコーデックのままの映像データを用いてデータファイルを作成する。
このとき、変換部13は、映像コンテンツにおける音声データについてはそのまま使用してもよいし、一旦デコードしてから再度エンコードしてもよい。つまり、変換部13は、たとえば元の音声データのコーデックがAACである場合、音声データについても、映像データ同様にデコードおよびエンコードを一切行わず、AACのコーデックのままの音声データを用いてデータファイルを作成する。一方、元の音声データのコーデックがG.711である場合、変換部13は、コーデックをAACに変換した音声データを用いてデータファイルを作成する。
このように変換部13は映像コンテンツの映像部分についてはそのまま使用するので、映像配信システム10は、映像配信装置1のCPUの変換にかかる負荷を大幅に軽減することができ、結果的に、以下のような利点がある。
まず、第1の利点として、映像配信システム10は、映像コンテンツを配信用のデータファイルに変換する変換処理に要する時間を短縮することができる。一例として、映像配信システム10は、カメラ2が映像を撮影している実時間の1.02倍程度にまで、変換部13での変換処理に要する時間を短縮することができる。たとえば90分の授業であれば、変換処理に要する時間は、実時間(90分)に90〜120秒程度を加えた時間となる。
第2の利点として、取得部12および変換部13は、取得部12による映像コンテンツの取得と、変換部13での変換とを同時に行うことができる。つまり、映像配信システム10は、CPUに、取得部12としての処理と変換部13としての処理とを同時に実行させることで、取得部12による映像コンテンツの取得処理と、変換部13での変換処理とを同時に実行可能である。上記90分の授業の例では、映像配信システム10は、取得部12で映像コンテンツの取得を開始後、5分程度の遅れをもって変換部13での変換処理を開始しても、取得部12での映像コンテンツの取得の終了後、7分以内に変換部13での変換処理を完了する。したがって、映像配信システム10は、授業の終了後、該授業のデータファイルが作成されるまでの時間を短くできる。
第3の利点として、変換部13は、複数台のカメラ2の各々から取得した複数の映像コンテンツについて、並行してデータファイルへの変換を行うことができる。映像配信システム10は、たとえば3台のカメラ21〜23で撮影された映像コンテンツを同時に変換することにより、各映像コンテンツを個別に変換する場合に比べて、変換処理に要する時間を約3分の1にまで短縮できる。たとえば、映像配信装置1のCPUがマルチコアである場合には、1コアに1台のカメラ2を割り当てることにより同時変換が容易に実現可能である。
また、本実施形態では、変換部13は、同一の授業の映像コンテンツが途中で分断されている場合には、自動的に結合して1つのデータファイルに変換する機能を有している。すなわち、映像配信装置1とカメラ2との間の通信障害などにより、映像コンテンツが授業の途中で分断されている場合、変換部13は、これらの映像コンテンツを自動的に判別し、結合処理を行う。具体的には、変換部13は、スケジュールを参照し、ある教室で撮影された映像コンテンツが、授業の開始時刻と終了時刻との間で2つ以上に分断されている場合には、これらの映像コンテンツは同一の授業の映像であると判断し結合処理を行う。
蓄積部14は、たとえばハードディスクドライブ等の記憶装置からなり、上述のようにして変換部13で変換された各データファイルを、スケジュール上の各授業に一対一に対応付けたままの状態で蓄積(保存)する。これにより、蓄積部14には、授業の内容を収録した映像コンテンツからなるデータファイルが、各授業に対応付けられて蓄積されることになる。なお、映像配信装置1は、蓄積部14に記録したデータファイルを一定期間(たとえば1ヵ月間)経過すると自動的に消去するように構成されている。
配信部15は、蓄積部14に蓄積されているデータファイルを読み出して、ネットワーク100(図2参照)を経由して端末装置3へ配信する。本実施形態では、配信部15は、端末装置3からの配信要求を受けると、この配信要求への応答として、配信要求の送信元の端末装置3へデータファイルの配信を行うように構成されている。
具体的には、映像配信装置1は、管理部11に登録されているスケジュールを、図3に例示するようなテーブルTA1として端末装置3に表示させる。この状態において、端末装置3でいずれの授業が選択される操作が為されると、該授業を特定する特定情報(授業の開始時刻と終了時刻と教室情報を含む情報)を含む配信要求が端末装置3から映像配信装置1へ送信される。配信要求を受けた映像配信装置1は、配信要求に含まれる特定情報から授業を特定し、該授業に対応するデータファイルを配信部15にて蓄積部14から読み出す。
配信部15は、データファイルを読み出すと、このデータファイルを、ダウンロード配信やストリーミング配信の適宜の方式で端末装置3へ配信する。ダウンロード配信の場合、端末装置3は、映像コンテンツのデータファイルを完全にダウンロードしてから映像コンテンツの再生が可能になる。ストリーミング配信の場合、端末装置3は、映像コンテンツのデータファイルをダウンロードしながら同時に再生する。ここで、ストリーミングには、プログレッシブダウンロード再生(擬似ストリーミング再生)と、リアルタイムストリーミング再生との両方を含む。プログレッシブ方式では、端末装置3は、配信部15から配信されたデータファイルを保存するが、リアルタイム方式では、端末装置3は、配信部15から配信されたデータファイルの保存を行わない。
しかも、本実施形態では、配信部15は、複数台の端末装置31〜33に対し並行してデータファイルを配信可能に構成されている。つまり、配信部15は、複数台の端末装置31〜33に対して映像コンテンツを同時に配信できる。ここでは、配信部15が並行して映像コンテンツを配信可能な端末装置3の台数は、最大500台であると仮定する。
さらに、映像配信システム10は、配信部15による映像コンテンツの配信を、取得部12による映像コンテンツの取得、および変換部13での変換処理と同時に行うことができる。
また、授業で用いる資料をデータファイル化した添付ファイルがある場合には、配信部15は、添付ファイルについても、映像コンテンツのデータファイルと一緒に端末装置3へ配信することが好ましい。この場合、映像配信システム10の管理者(大学の関係者)が、映像配信システム10に管理者IDでログインした状態で、スケジュール上の各授業に添付ファイルを対応付けて登録する。添付ファイルは、蓄積部14に蓄積されてもよいし、蓄積部14以外の記憶装置に蓄積されてもよい。
端末装置3は、配信部15から配信された映像コンテンツを、たとえば図4に示すような形式で再生(表示)する。図4の例では、画面左側の表示窓W1に再生中の映像コンテンツが表示され、画面右側の詳細テーブルTA2に再生中の映像コンテンツに対応する授業の詳細情報が表示されている。表示窓W1の上部には、再生中の映像コンテンツに対応する授業の概要(日付、開始時刻、終了時刻、教科等)が表示される。詳細テーブルTA2は、学期、学部、教科、周期、時限および教室、教師、閲覧グループ、添付ファイルなど、授業に関する詳細な情報を含んでいる。詳細情報は、映像コンテンツのデータファイルと一緒に配信部15から端末装置3へ送信される。
これにより、ユーザ(受講者)は、映像配信システム10にユーザIDでログインすることにより、スケジュールを端末装置3に表示させ、このスケジュール上で所望の日時の授業を選択することにより、該授業の映像コンテンツを端末装置3で視聴可能となる。
ここで、映像配信システム10は、ログ解析の機能を有していてもよく、これにより端末装置3への映像コンテンツの配信状況を管理可能になる。具体的には、映像配信システム10は、ユーザIDごとに、各授業の映像コンテンツがどこまで視聴されたかを管理することで、ユーザごとの進捗状況を管理できる。
なお、取得部12が、複数台のカメラ21〜23から映像コンテンツを並行して取得する場合、取得部12から配信部15までの各処理においても、複数台のカメラ21〜23からの映像コンテンツは並行して処理可能であることが好ましい。
さらにまた、本実施形態の映像配信システム10では、映像配信装置1は、カメラ2から出力される映像コンテンツを、データファイル化せずに、配信部15から端末装置3へライブ配信する機能も備えている。具体的には、映像配信装置1は、カメラ2からの映像コンテンツについて、プロトコル変換部17でRTSP(Real Time Streaming Protocol)からRTMP(Real Time Messaging Protocol)へのプロトコル変換のみ行い、リアルタイムで配信する。つまり、ライブ配信用の映像コンテンツについては、映像配信装置1は、記録部16や蓄積部14に保存することはない。
これにより、ユーザ(受講者)は、開講中の授業の映像を端末装置3にてリアルタイムで視聴することができる。ライブ配信を利用する場合でも、ユーザは、蓄積部14に蓄積されたデータファイルの配信の場合と同様に、端末装置3においてスケジュール上で所望の日時の授業を選択することにより、該授業の映像コンテンツを端末装置3で視聴可能となる。なお、ライブ配信用の映像は、取得部12にて映像コンテンツの取得が行われるカメラ21〜23と共通のカメラ2で撮影されてもよいし、ライブ配信用のカメラが別に設けられていてもよい。
また、映像配信システム10は、取得部12がカメラ2で撮影された映像コンテンツをカメラ2から直接取得することは必須ではなく、サーバ(図示せず)等で配信(中継)された映像コンテンツを取得部12が取得してもよい。すなわち、たとえば遠隔授業などにおいては、授業の映像がサーバによってストリーミング配信されるので、映像配信システム10は、ストリーミング配信された映像を取得部12にて取得するように構成されていてもよい。これにより、映像配信システム10は、遠隔地からストリーミング配信された授業の映像を、データファイルとして端末装置3へ転送することができる。
また、映像配信システム10は、カメラ2で撮影された映像を常時、記録部16に記録する構成であってもよい。この場合、現時点から遡ること一定期間(たとえば3日間)分の映像コンテンツが、記録部16に記録されることになる。この場合において、変換部13は、事後的にスケジュールに登録された授業についても、記録部16に記録されている映像コンテンツを切り出し、各授業に対応付けて配信用の標準フォーマットのデータファイルに変換することが好ましい。これにより、映像配信システム10は、授業の終了後にスケジュールに登録された授業についても、配信用のデータファイルを作成することができ、スケジュールへの授業の登録処理を忘れたことによる収録漏れにも対応可能となる。
以上説明した本実施形態の映像配信システム10によれば、変換部13は、映像コンテンツに含まれる映像データについてはコーデックを変えることなく、映像コンテンツをデータファイルに変換するように構成されている。そのため、映像配信システム10は、映像コンテンツの変換時のCPUの負荷を軽減し、また、映像コンテンツの取得からデータファイルを配信可能となるまでに要する時間を短縮できる。
また、取得部12はスケジュールに従って映像コンテンツを取得し、変換部13は複数の授業(イベント)の各々に対応付けて映像コンテンツを配信用の標準フォーマットのデータファイルに変換する。さらに、蓄積部14は、複数の授業(イベント)の各々に対応付けてデータファイルを蓄積する。そのため、この映像配信システム10は、映像コンテンツの収録から配信までを自動化することができ、管理者による操作が必要ないので、管理者の操作の手間を省くことができ、また、操作ミス等による映像の収録漏れが生じにくい、という利点がある。
また、本実施形態では、映像配信装置1が1台のコンピュータからなる場合を例示したが、たとえば収録ブロック110と配信ブロック120とは別装置であってもよい。この場合、収録ブロック110と配信ブロック120とは一対一に限らず、一対多(1:N)であってもよい。収録ブロック110と配信ブロック120とが別装置であれば、たとえば収録ブロック110を搭載した装置を教室付近に配置し、配信ブロック120を搭載した装置を遠方のデータセンターに配置する、ということが可能になる。また、撮影対象の教室が多数(たとえば20以上)の場合、収録ブロック110を搭載した装置を複数台設ければ、配信ブロック120を搭載した装置は1台で足りる。
以下に、上述したような構成の映像配信システム10を、授業の映像配信以外の用途へ適用する例を示す。
1つ目の例として、映像配信システム10は、会議を収録するためのシステムとして使用可能である。すなわち、会議室が予約制であって、開始時刻および終了時刻で規定される単位時間ごとに、それぞれの会議室で行われる予定の会議が割り当てられている場合には、会議をイベントとして、会議室に設置したカメラ2にて会議を収録することができる。この場合、映像配信システム10は、カメラ2で撮影された各会議の映像を、各会議に対応付けてデータファイルとして蓄積部14に蓄積できる。
2つ目の例として、映像配信システム10は、動物園での動物の様子を収録するためのシステムとして使用可能である。すなわち、様々な動物の檻にそれぞれカメラ2を設置しておけば、開始時刻および終了時刻で規定される単位時間ごとに、カメラ2にて動物の様子を収録することができる。この場合、たとえば「4月1日9時00分〜10時00分:サル」、「4月1日10時00分〜11時00分:ライオン」というように、開始時刻、終了時刻、動物名によってイベントが表される。映像配信システム10は、このようなイベントごとに、カメラ2で撮影された映像をデータファイルとして蓄積部14に蓄積することができる。
3つ目の例として、映像配信システム10は、遠隔地間で映像および音声を双方向に伝送するテレビ会議システムと連携させて使用可能である。この場合、映像配信システム10は、テレビ会議システムのカメラで撮影された映像コンテンツを取得部12で取得し、配信用のデータファイルに変換して蓄積部14に蓄積する。これにより、映像配信システム10は、テレビ会議システムのカメラを利用できるので、新たにカメラを設けることなく、映像の収録が可能になる。また、テレビ会議システムにおいては、カメラで撮影された映像をデータファイルとして残しておくことが可能になる。
さらに、本実施形態の映像配信システム10は、開始時刻および終了時刻が事前に決められているイベントに限らず、カメラ2で撮影された映像の端末装置への配信に、広く適用可能である。
(実施形態2)
本実施形態に係る映像配信システム10は、図5に示すように、抽出部18と、識別部19と、設定部20とをさらに備える点で、実施形態1の映像配信システム10と相違する。以下、実施形態1と同様の構成については共通の符号を付して適宜説明を省略する。
本実施形態では、抽出部18と識別部19と設定部20とは、いずれも映像配信装置1の収録ブロック110に設けられている。
抽出部18は、映像コンテンツの複数フレーム間の変化に基づいて、移動体を除いた背景映像を抽出するように構成されている。この場合、蓄積部14には、変換部13で変換されたデータファイルとして、背景映像のデータファイルを蓄積するように構成される。つまり、取得部12がカメラ2から取得した映像コンテンツには、黒板や白板等の情報表示板6(図2参照)のような静止体だけでなく、講師H1(図2参照)のような移動体も含まれている。抽出部18は、映像コンテンツから移動体を削除して、静止体の映像のみを背景映像として抽出する。
具体的には、抽出部18は、変換部13の前段において、映像コンテンツの連続する複数フレーム間の差分をとり、画素値の変化量が閾値以上の領域については移動体、その他の領域は静止体であると判断する。抽出部18は、映像コンテンツの各フレームから、移動体と判断した領域を削除し、残りの領域(静止体と判断した領域)を背景映像として抽出し、変換部13に出力する。これにより、変換部13は、背景映像についてのみデータファイル化し、蓄積部14に蓄積することになる。ただし、抽出部18は、少なくとも背景映像と、移動体の映像とを分離できればよく、移動体の映像を背景映像とは別に前景映像として抽出するように構成されていてもよい。
この構成によれば、配信用のデータファイルからは、移動体である講師H1の映像が除かれるので、ユーザ(受講者)は、情報表示板6のような静止物の映像のみを視聴することができる。なお、情報表示板6に表示される文字や記号、図形等の情報は、講師H1が書いたり消したりすることで変化するが、一定時間以上静止している情報については、静止体として背景映像として抽出される。
ここにおいて、背景映像は、少なくとも情報を表示する情報表示板6の映像を含んでいる。この場合、抽出部18は、映像コンテンツの複数フレームから、情報表示板6のうち移動体で隠れた重複領域について、情報表示板6に表示されている情報を復元して背景映像を生成することが好ましい。つまり、情報表示板6の手前に移動体である講師H1がいる場合には、情報表示板6のうち講師H1と重複する領域が重複領域となる。このような重複領域については、単に移動体を削除するだけでは、そもそも情報表示板6に表示されている情報が欠けることがある。
そこで、抽出部18は、講師H1で隠れた部分(重複領域)の情報表示板6の映像を復元することにより、表示されている情報の欠けを擬似的に補った情報表示板6の映像(背景映像)を表示可能とする。具体的には、抽出部18は、過去の1ないし複数フレーム分の背景映像を重ね合わせることにより、重複領域に、過去の背景映像の同じ位置の映像を当てはめる。その結果、抽出部18は、重複領域について、情報表示板6に表示されている情報を復元して背景映像を生成することができる。
また、抽出部18は、背景映像についてシェーディング補正を施すように構成されていることが好ましい。つまり、抽出部18は、シェーディング補正により、濃度(光量)むらをなくすように背景映像を補正する。これにより、抽出部18は、情報表示板6の映像について、情報表示板6に表示されている文字や記号、図形等の情報と、それ以外の領域とを明確に区別した背景映像を抽出することができる。
ところで、情報表示板6には、ガラス、ホーロ、プラスチック等の材料からなる黒板(チョークボード)や白板(マーカーボード)の他、プロジェクタスクリーン、電子黒板(電子白板)、デジタルサイネージなど、複数の種類がある。電子黒板は、スタイラスやペン等で画面上に書き込んだ情報を表示する装置である。情報表示板6における光の反射率や発色などは、これらの情報表示板6の種類によって大きく異なる。そこで、本実施形態の映像配信システム10は、これらの情報表示板6の種類を自動的に識別する機能として識別部19を有している。
識別部19は、背景映像を画像処理することにより情報表示板6の種類を識別するように構成されている。つまり、識別部19は、抽出部18で抽出された背景映像に対して画像処理を施すことにより、背景映像中の情報表示板6の領域を識別し、この領域の光の反射率や発色から、情報表示板6の種類を識別する。
この構成によれば、たとえば教室によって情報表示板6の種類が異なるような場合でも、識別部19が、背景映像中の情報表示板6の種類を自動的に識別する。したがって、映像配信システム10の管理者においては、情報表示板6の種類を予め登録するような操作が不要になる。
また、設定部20は、カメラ2の撮影条件を設定するように構成されている。カメラ2の撮影条件には、少なくともシャッター速度と絞りと感度とを含む。ここでは、設定部20は、識別部19で識別された情報表示板6の種類に応じて、撮影条件を自動的に決定するように構成されている。具体的には、映像配信装置1は、情報表示板6の種類ごとに最適な撮影条件を予め条件リストとしてメモリに登録しており、設定部20では、識別部19で識別された情報表示板6の種類に最適な撮影条件を条件リストから選択する。たとえば黒板に比べると白板の方が光の反射率が高いので、黒板の撮影条件よりも白板の撮影条件において感度が低く設定される。設定部20は、選択した撮影条件をカメラ2に対して取得部12経由で送信して、カメラ2の撮影条件を自動的に変更する。なお、設定部20は、撮影条件を取得部12経由でなくカメラ2に直接送信する構成であってもよい。
以上説明した本実施形態の映像配信システム10によれば、講師H1で隠れた部分(重複領域)の情報表示板6の映像が抽出部18にて復元されるので、表示されている情報の欠けを擬似的に補った情報表示板6の映像(背景映像)を表示可能となる。そのため、配信用のデータファイルにおいて、情報表示板6の手前に講師H1がいる場合でも、ユーザ(受講者)は、情報表示板6のうち講師H1で隠れた部分に表示されている情報についても見ることができる。したがって、映像配信システム10は、情報表示板6に表示されている情報を、ユーザに対し、映像コンテンツにより欠けなく正確に伝達可能となる。
さらに、識別部19が、情報表示板6の種類を自動的に識別し、設定部20は、識別部19で識別された情報表示板6の種類に応じて、カメラ2の撮影条件を自動的に決定する。そのため、情報表示板6が複数種類ある場合でも、カメラ2の設定を手動で変更することなく、カメラ2は情報表示板6の種類に応じた最適な撮影条件で情報表示板6を撮影することができる。
なお、映像配信システム10において、背景映像が情報表示板6の映像を含むことは必須ではない。また、映像配信システム10においては、抽出部18における重複領域について情報表示板6に表示されている情報を復元する機能も必須ではなく、適宜省略可能である。さらに、抽出部18におけるシェーディング補正の機能や、識別部19、設定部20についても映像配信システム10に必須の構成ではなく、適宜省略可能である。
ところで、本実施形態の第1の変形例として、設定部20は、識別部19での識別結果ではなく、スケジュールに従ってカメラ2の撮影条件を決定してもよい。第1の変形例では、設定部20は、スケジュールにおいて複数の授業(イベント)の各々に対応する情報表示板6の種類が指定されている場合には、スケジュールに従って、情報表示板6の種類に応じた撮影条件を自動的に決定するように構成される。
つまり、授業ごとに、使用される情報表示板6の種類が予め決まっている場合、スケジュールにおいて、情報表示板6の種類を授業に対応付けて予め登録することができる。この場合においては、設定部20は、スケジュール上で指定されている情報表示板6の種類に合わせて、最適な撮影条件を選択する。これにより、映像配信システム10は、識別部19で情報表示板6の種類を判別する場合に比べてより簡単な処理で、情報表示板6の種類に応じた最適な撮影条件で情報表示板6を撮影可能となる。
なお、第1の変形例においても、設定部20は、スケジュール上で情報表示板6の指定がされていない授業については、識別部19での識別結果に従って、カメラ2の撮影条件を決定する構成であってもよい。
また、本実施形態の第2の変形例として、取得部12は、情報表示板6に表示されている情報を表示データとして情報表示板6から取得するように構成されていてもよい。この場合、変換部13は、映像コンテンツと情報表示板6から取得した表示データとを、データファイルに変換するように構成される。
すなわち、第2の変形例は、情報表示板6が電子黒板などの表示されている情報を電子データとして出力可能な種類の情報表示板である場合に、情報表示板6から出力される電子データを取得部12にて直接取得する。これにより、映像配信システム10は、情報表示板6に表示されている情報を、カメラ2で撮影された映像からではなく、情報表示板6から直接取得することができるので、ユーザに対して欠けなく正確に伝達可能となる。
具体的には、HDMI(登録商標)(High-Definition Multimedia Interface)出力を持つ電子黒板が情報表示板6として使用されている場合、映像配信装置1は、HDMI(登録商標)ケーブルにより情報表示板6に電気的に接続されている。映像配信装置1は、情報表示板6の起動を検知して情報表示板6から表示データを取得するように構成されている。映像配信装置1は、取得した表示データを、配信用の映像コンテンツの情報表示板6の領域に合成し、映像コンテンツに含めた形で配信してもよいし、映像コンテンツとは別に配信してもよい。表示データが映像コンテンツと別に配信される場合、端末装置3は、映像コンテンツの再生画面と並べて表示データの内容を表示する。
なお、第2の変形例においても、情報表示板6が通常の黒板や白板などの場合、映像配信システム10は、情報表示板6に表示されている情報を、カメラ2で撮影された映像から取得することになる。
その他の構成および機能は実施形態1と同様である。