システム構築
さて、
システム全体の概要
バックエンド
- 1．動画関連システム
- テレビ録画
- 動画フォーマット変換
- 動画サムネイル切り出し
- 実況データヒストグラムからダイジェスト版作成
- 2．実況データシステム
- 2ch実況データ取得保存
- twitter実況データ取得保存
- 実況データヒストグラム作成
- 3．ウェブシステム
- 番組一覧提供
- 実況データ提供API
- 実況データヒストグラム提供API
- 動画、
画像提供
フロントエンド
- 1．PCウェブ
- 動画ストリーミング再生
- 実況データ取得、
表示 - ヒストグラム取得、
表示
- 2．モバイル
- 動画ストリーミング再生
- 実況データ取得、
表示 - ヒストグラム取得、
表示
システム詳細
バックエンド
- 1．動画関連システムについて
-
このシステムでは、
動画の作成変換など動画に関する操作を行います。テレビ番組の録画自体は、 I-O DATAのGV-MVP/ RZ を使用しており、windows XPマシンで録画を行っています。 この製品では録画ファイルの管理をxmlファイルを用いて行っています。たまたま知ったんですが、
このファイルをクロール、 解析することで今回のサービスの実現性を感じました。 ウェブサーバとDBサーバはFedora Coreで行います。当該サーバはXPの録画ディレクトリを定期的に参照し録画中のステータスが無いかチェックします。もし録画中の番組があった場合はその番組データをMySQLに登録し、
番組マスターとして蓄積を行います （ステータスは未処理）。 GV-MVPで録画した動画をウェブコンテンツとして再生するべく、
シュリンクとフォーマット変換を行っていますが、 そのサーバが動画変換サーバとなります。OSはCenｔOSを使用しています。変換後のデータとサムネイルはNASに保存します。変換が終了したらDBサーバの番組マスターを更新します （ステータスは処理済み）。 図1 動画関連システム構成図 
- 2．実況データシステム
-
実況データシステムでは録画中の番組についてリアルタイムで交わされている実況データを取得します。2chの実況スレッドは時間が経過すると消えてしまうので、
録画中のステータスを確認したらある程度リアルタイムで取得することが求められます。 twitterについても同様にハッシュタグでの検索を行い、
取得した発言データを時系列でDBに保存します。保存都度、 一定の時間間隔での発言数集計を行い、 どの時間帯が盛り上がったか （発言数が多かったか） を判別するデータ作成する。 図2 実況データシステム構成図 
- 3．ウェブシステム
-
さてこのシステムがクライアントと直接やりとりを行うシステムとなります。今回のケースではウェブサービスということですので、
当然ウェブサービスが立ち上がっていることが必須となります。 クライアントからのリクエストに応じてステータスが処理済みの番組について、
ウェブページを返しますが、 ここでの実況データの提供はAPI形式となっていてクライアントからの動的なリクエストによってデータを返すことになります。 APIとすることで別のサービスでも使用できるという利点があります。たとえば、
動画は自前で用意するとか。この辺がAPI化を行う最大の利点でしょうね。 基本的には、
番組を特定するキーと動画の再生位置から時刻を算出しパラメータとして渡すことになります。 図3 ウェブシステム構成図 
バックエンドのシステムだけでも結構なボリュームになりますネ。
コンテンツが手元にないと言うことはそれだけ別のシステムに頼ることになるので致し方ないですが、
また、
その辺は目をつぶっていただくとして、