JP2008244869A - ライブ配信システム、Ｗｅｂサーバ、エンコーダ及びライブ配信システムにおける配信管理方法 - Google Patents

Abstract

【課題】エンコーダと配信サーバ間のネットワークが不安定な状態になった場合でも、視聴者（クライアント）に安定的にライブ映像を配信できるライブ配信システムを提供すること。
【解決手段】ライブ配信用の映像をカット編集可能な箇所でブロック分割及び圧縮し、ブロック分割した圧縮映像データをサーバに転送するエンコーダ２００−１，２００−２と、配信状況及び又はクライアントの要求に応じて、ブロック分割された映像データを結合して配信番組を作成するサーバ３００とを設けた。これにより、特殊なサーバやビューアを用いずに、すなわち従来の配信システムインフラをほとんど変えずに、視聴者に安定的にライブ映像を配信できるライブ配信システム１００を実現できる。
【選択図】図１

Description

本発明は、インターネットを利用したライブ配信システムに関する。

従来、インターネットを利用したライブ配信として、ストリーミング配信が一般的に行われている。ストリーミング配信は、クライアント（視聴者）が映像データ及び音声データ（以下、これをまとめて単に映像データと呼ぶ）をダウンロードしながら、再生するものである。これにより、クライアントは、コンサートやイベント会場等の撮影現場で撮影された映像を、ライブに近い感覚で視聴することができる。

図１５に、従来のライブ配信システムの構成を示す。複数のカメラ１１ａ，１１ｂで得られた映像はミキサ１２に送出される。ミキサ１２は、各カメラ１１ａ，１１ｂのスイッチングや宣伝の挿入等を行うことで、番組を構成する。なお、図中点線で示したカメラ１１ａ，１１ｂからミキサ１２までは、アナログ信号処理系である。よって、ミキサ１２では、アナログ処理により番組構成処理が行われる。

ミキサ１２により番組構成とされた映像は、エンコーダ１３に送出される。エンコーダ１３は、入力された映像をエンコードし、エンコード後の映像データをサーバ１４に送出する。サーバ１４は、クライアント（ＰＣ）１５の要求に応じて、映像データをクライアント１５に配信する。

従来、クライアントの利便性を考慮して、種々のライブ配信方法が提案されている。

例えば、特許文献１には、配信映像を第１及び第２のエンコーダで生成し、第１のエンコーダではリアルタイムに近い映像をライブ配信し、第２のエンコーダでは映像ファイルを蓄積しておき、視聴者からの要求に応じてリプレイ配信する技術が開示されている。

また、特許文献２には、サーバに映像データを分割して格納し、クライアントからの要求に応じて映像データを再生して配信する技術が開示されている。

また、特許文献３には、リアルタイムに近いライブ映像をマルチキャスト送信する一方、要求に応じてタイムシフト映像をユニキャスト送信する技術が開示されている。

これら特許文献１〜３に記載された技術は、確かに、クライアントの利便性を向上させるものとして有効であると考えられる。
特開２００４−２７４５３１号公報 特開２００５−０１１１５０号公報 特開２００４−０８８４６６号公報

ところで、インターネットにおける映像配信は、テレビやラジオの電波放送と比べ仕組みが大きく異なる。電波放送では、電波の届く範囲に存在する全ての受信機が同時刻に同じ映像を受信できる。つまり、放送可能な範囲は限定されるが、視聴者数が限定されないところに特徴がある。

これに対して、インターネットの映像配信は、土管（ネットワークケーブル）と水（データ）に例えることができる。映像配信サーバと呼ばれる、映像データを供給するサーバから、視聴者が利用する水（映像）を土管（インターネット）に流しだす必要がある。つまり、１００人の視聴者に対し１００人分の水（映像）を供給する必要があり、配信可能エリアは全世界（インターネットで到達可能な範囲）であるが、視聴者の数は限定される。さらに、インターネットの通信はベストエフォート方式と呼ばれ、土管を近隣住人で共有するため、時間によっては期待する量の水を流すことができなくなる（ネットワーク帯域の変化によるデータ到着の遅延）。

インターネットにおける映像視聴のスタイルは、ビデオ・オン・デマンド（ＶＯＤ）方式とライブ方式の２種類が存在する。ＶＯＤは、ユーザ（視聴者）が視聴を希望するときに希望する映像を閲覧するスタイルであり、特許文献１、２に示されている再生映像を配信する方式はこの方式に含まれる。一方、ライブ方式は、どこかで行われているイベントをその時刻に視聴する（ＴＶの生中継と同じ）スタイルである。

インターネットライブ配信における一般的な機器構成とデータの流れは、図１５に示したように、カメラ１１ａ，１１ｂで撮影した映像を、インターネット配信可能な映像データに変換（エンコード）した後、配信サーバ１４を経由し全視聴者に配信する。この場合、図に示すように２種類のネットワークが必要となる。エンコーダ１３と配信サーバ１４間のネットワークと、配信サーバ１４と視聴者ＰＣ１５間のネットワークである。

ライブの場合、屋外や指定された屋内（ホールなど）が会場になるケースが多く、エンコーダ１３から配信サーバ１４までの安定したネットワーク経路を確保することは困難なケースが多い。エンコーダ１３と配信サーバ１４間のネットワークは映像データの源泉であるため、このネットワークの切断、帯域不足は、即配信事故となる。配信サーバ１４と視聴者ＰＣ１５間の帯域の変動は、個人の視聴環境が劣化するだけですむが、上流であるエンコーダ１３と配信サーバ１４間の帯域変動は、全視聴者の環境悪化の直接的原因となる。現状この問題に対する抜本的な解決方法は存在せず、エンコーダ１３と配信サーバ１４間の経路を多重化するなどの措置を講じるのみであった。

本発明は、エンコーダと配信サーバ間のネットワークが不安定な状態になった場合でも、視聴者（クライアント）に安定的にライブ映像を配信できるライブ配信システムを提供する。また、本発明は、クライアントの利便性が向上する新規なサービスを実現できるライブ配信システムを提供する。

本発明のライブ配信システムは、ライブ配信用の映像をカット編集可能な箇所でブロック分割及び圧縮し、ブロック分割した圧縮映像データをサーバに転送するエンコーダと、配信状況及び又はクライアントの要求に応じて、前記ブロック分割された映像データを結合して配信番組を作成するサーバと、を具備する構成を採る。

本発明のライブ配信システムは、コミュニケーショングループ毎に配信情報を管理する配信情報管理部を有するＷｅｂサーバと、前記配信情報管理部からの要求に基づいてライブ映像を結合することで、前記コミュニケーショングループ毎の番組を構成する映像データ結合編集部を有する配信サーバと、を具備する構成を採る。

本発明によれば、エンコーダと配信サーバ間のネットワークが不安定な状態になった場合でも、視聴者（クライアント）に安定的にライブ映像を配信できるライブ配信システムを実現できる。また、コミュニケーショングループ毎に自由に番組を構成でき、さらにコミュニケーショングループ内で同一のライブ番組を視聴できるので、特にチャットや、掲示板、携帯電話等で会話を行うクライアントの利便性が向上する。

本発明の実施の形態を説明にするに先だって、本発明に至った過程について説明する。

本発明の一つの特徴は、エンコーダから配信サーバに、圧縮符号化したファイルをブロック転送したことである。これにより、経路の帯域変動に強く（時間平均で転送データ以上の帯域が確保できればよい）、エンコーダと配信サーバ間の転送を安定して行うことができる。

従来の配信システムでは、デジタル化した映像データを即座に配信サーバに送信し、遅延少なく視聴者へ配信するが、本発明では、ブロック転送の基本思想をライブ配信用インフラとして適用することで、エンコーダと配信サーバ間で安定したデータ転送を行うことができる基本システムを実現できる。このように、本発明の発明者らは、配信システムインフラの着想に至った。

まず、本発明では、基本前提として「従来から存在するサーバやビューアを利用する」ことを念頭に置いた。特殊なサーバやビューアで実現されるシステムは、導入時のコストが高く「普及」という面で現実的でない。本発明のライブ配信システムは、下記の点で従来のライブ配信システムと異なる。

１．映像データをブロック単位で配信サーバに集約することで、ライブのように一連の映像として見せる仕組みを、Ｗｅｂサーバと連携させた再生リストで実現した。

２．配信サーバに映像を集めることで、従来システムでは不可能だった「複数映像ソースの編集」が可能になった。

３．映像データをサーバで蓄積しているため、「番組的に意味のあるところから見せる」などのサービスが実現可能になった。

４．視聴者間の視聴箇所（見ている映像）がバラバラになると、ライブ感を損なう可能性があり、ライブ配信システムとしては大きなマイナスになることから、クライアント（視聴者）間の視聴を同期させる工夫を導入した。本発明では、インターネット視聴者がチャットや掲示板で番組内容について議論するという新しい視聴スタイルを想定し、コミュニケーションしているグループ間で映像を同期して見せる仕掛けの着想に至った。なお、システムでは、コミュニケーショングループ単位で視聴箇所の管理を行うが、独立したクライアントを含む全ての視聴者に対して視聴箇所の管理は必要なので、独立クライアントは１人のコミュニケーショングループとして管理する。

以下、本発明の実施の形態について図面を参照して詳細に説明する。

（１）構成
（１−１）原理構成
図１に、本実施の形態の準ライブ配信システムの原理構成を示す。本実施の形態のライブ配信システムは、カメラ１０１−１，１０１−２で映像・音声を取得してから、クライアント（ＰＣ）４００に配信されるまでに、バッファリングや、番組編集、番組再生等による遅延時間が発生するため、ライブ配信システムとは呼ばずに、準ライブ配信システムと呼ぶことにする。

準ライブ配信システム１００は、複数のカメラ１０１−１，１０１−２で取得した映像・音声をエンコーダ２００−１，２００−２に送出する。ここで、カメラ１０１−１では例えば演奏者の顔が撮影され、カメラ１０１−２では例えば演奏者の手が撮影されている。

各エンコーダ２００−１，２００−２は、映像・音声をエンコード（圧縮符号化）し、エンコード後の映像データ及び音声データ（以下、これをまとめて単に映像データと呼ぶ）をある程度（数分〜数十分）蓄積してから、サーバ３００へブロック転送する。本実施の形態の場合、エンコーダ２００−１，２００−２は、クリップ単位に分割した映像データをサーバ３００にブロック転送する。これにより、エンコーダ２００−１，２００−２とサーバ３００との間のネットワーク経路が不安定であった場合でも、クライアント４００に配信するライブ映像がクリップ内で途切れることを確実に回避でき、安定した配信ができるようになる。なお、図中のブロックの区切りは、１クリップの区切りを表している。

サーバ３００は、到着した映像データを映像データベース３００ａに蓄積する。これにより、映像データの再利用及び番組構成の編集が可能となる。

サーバ３００は、蓄積した映像データを仮想的に並べ番組を作成する（３００ｂ）。このとき、サーバ３００は、コミュニケーショングループ毎に番組を構成する。図では、コミュニケーショングループＡ（５００ａ）に対しては番組（ｍａｉｎ）を構成し、コミュニケーショングループＢ（５００ｂ）に対しては番組（ｓｕｂ１）を構成している。各番組（ｍａｉｎ，ｓｕｂ１）は、コミュニケーショングループ内のクライアント４００の要求に応じて編集される。なお、コミュニケーショングループＣ（５００ｃ）のようにコミュニケーショングループは、一人のクライアントにより形成されていてもよい。

また、サーバ３００は、予め制作された映像データ（宣伝や差込映像など）を番組の間に組み込む。本実施の形態では、これを間繋ぎコンテンツとして利用する。その詳細については、後述する。

クライアント４００は、番組を「きりの良いところから（都合良いところから）」視聴できる。きりの良いとは、例えば「Ａさんの演奏途中からではなくＡさんの最初から」など、番組が意味不明にならないところからの視聴を意味する。

サーバ３００は、チャットや、掲示板、携帯電話等で会話しているコミュニケーショングループ５００ａ，５００ｂには、それぞれ同じ番組中の同じ視聴ポイントを保障する。ここで、インターネットライブ配信では、通常数秒から数分程度のずれは常時発生するため、同程度のずれは許容するものとする。

（１−２）全体構成
図２に、図１の原理構成を具現化した準ライブ配信システム１００の全体構成を示す。

サーバ３００は、Ｗｅｂサーバ３１０と配信サーバ３２０とで構成されている。

エンコーダ２００は、１クリップ単位の映像データを配信サーバ３２０に送出すると共に、１クリップの映像データの配信が完了する度に配信情報更新通知信号をＷｅｂサーバ３１０に送出する。

Ｗｅｂサーバ３１０は、クライアント４００からの要求に応じたＨＴＭＬを送出する。またＷｅｂサーバ３１０は、クライアント４００からの要求に応じて配信画像の再生リストを送出する。さらにＷｅｂサーバ３１０は、クライアント４００と同期情報の送受を行う。

実際上、クライアント４００とサーバ３００は、以下の通信を行う。

クライアント４００は、起動しているＷｅｂブラウザ４００ａから、配信ページ４００ｂを取得し、これを開く。

配信ページ４００ｂには、映像ビューア４１０が組み込まれており、映像ビューア４１０は、起動後のＷｅｂサーバ３１０から再生リスト（映像データを並べた番組内容）を取得する。

映像ビューア４１０は、再生リストに従い、配信サーバ３２０へ映像データを要求し、映像を再生する。

Ｗｅｂサーバ３１０とクライアント４００は、同期情報を交信することで視聴ポイントの同期調整を行う。本実施の形態では、コミュニケーショングループ間での同期調整（以下これを全体同期と呼ぶ）と、コミュニケーショングループ内での同期調整（以下これをグループ同期と呼ぶ）とを行う。

全体同期とは、コミュニケーショングループ内の特定のクライアントをグループリーダとして、Ｗｅｂサーバ３１０がその視聴ポイントを取得する処理である。この全体同期を行う場合、グループリーダであるクライアントのＷｅｂブラウザ４００ａが、一定時間毎に映像ビューア４１０の再生位置（視聴ポイント）をＷｅｂサーバ３１０に送信することで、Ｗｅｂサーバ３１０におけるグループリーダの同期情報を更新する。なお、グループリーダの視聴ポイントは、実在するクライアント４００の視聴ポイントでなく、仮想的に設定した視聴ポイントであってもよい。

グループ同期とは、コミュニケーショングループ内のクライアント（グループメンバー）の視聴ポイントを、強制的にグループリーダと同一の視聴ポイントに合わせる処理である。グループ同期を行う場合、グループメンバーであるクライアント４００のＷｅｂブラウザ４００ａは、一定時間毎にグループリーダの同期情報（視聴ポイント）をＷｅｂサーバ３１０から取得し、映像ビューア４１０が自装置の視聴ポイントとグループリーダの視聴ポイントとを比較し、自装置の視聴ポイントをグループリーダの視聴ポイントに合わせるための調整を行う。

（１−３）エンコーダの構成
図３に、エンコーダ２００の構成を示す。エンコーダ２００は、カメラで取得されたアナログ映像を映像入力部２０１を介してエンコード部２０２に入力する。エンコード部２０２は、アナログ映像信号をデジタル化すると共に圧縮符号化し、これにより得た映像データを映像データ時分割部２０３に送出する。

映像データ時分割部２０３は、映像データを、指定された時間及びシーン解析結果に基づいて時分割することでクリップを形成し、これを映像データ転送部２０４を介して配信サーバ３２０（映像データ受信部３２１）に転送する。すなわち、エンコーダ２００からは、カット編集可能な箇所でブロック分割された映像データが、配信サーバ３２０にブロック転送される。これにより、経路の帯域変動に強く（時間平均で転送データ以上の帯域が確保できればよい）、エンコーダと配信サーバ間の転送を安定して行うことができる。

因みに、図３では、映像を圧縮符号化後に分割する場合を示したが、映像を分割後に圧縮符号化してもよく、要は、サーバ側でカット編集可能なブロック単位の映像データを形成して転送すればよい。

配信情報更新通知部２０６は、１クリップの映像データの転送が終了する度に、又は、１シーンが終了する度に、Ｗｅｂサーバ３１０（配信情報管理部３１１）に配信情報更新通知信号を送信する。

シーン設定部２０５は、意味のあるまとまり（例えば、１講演や、演奏、イベントなど）の区切りを示すシーン情報を設定する。このシーン情報は、配信情報更新通知部２０６からメッセージとしてＷｅｂサーバ３１０（配信情報管理部３１１）に送信される。

（１−４）Ｗｅｂサーバの構成
図４に、Ｗｅｂサーバ３１０の構成を示す。Ｗｅｂサーバ３１０は、配信情報管理部３１１にエンコーダ２００（配信情報更新通知部２０６）から送られた配信情報更新通知信号を入力する。配信情報管理部３１１は、エンコーダ２００からの配信情報更新通知信号が入力されると、配信情報の更新処理を行うと共に、配信サーバ３２０（映像データ結合編集部３２４）にファイル結合を要求する。

ここで、配信情報管理部３１１は、配信情報入出力部３１２からクライアント（管理者）４００からの編集情報を入力し、配信サーバ３２０にこの編集情報に従ったファイル結合を要求する。これにより、コミュニケーショングループ毎の配信番組が構成される。

再生リスト生成部３１３は、配信情報管理部３１１からの配信情報を入力し、クライアント４００が再生可能な映像データを列挙した再生リストを生成し、これをクライアント４００の映像ビューア４１０（再生リスト要求・受信部４１１）からの再生リスト要求に応じて映像ビューア４１０（再生リスト要求・受信部４１１）に送信する。

配信情報入力部３１２は、配信情報を編集する機能をクライアント（管理者）４００に提供する（図１３参照）と共に、クライアント４００からの編集情報をクライアント４００から受け取る。

同期情報管理部３１５は、グループリーダから参照ポイント（視聴ポイント）を受信すると共にこれを管理する。また同期情報管理部３１５は、グループメンバーに同期情報を送信する。

同期情報入出力部３１４は、同期情報を編集する機能をユーザ（管理者）４００に提供する（図１４参照）。

（１−５）配信サーバの構成
図５に、配信サーバ３２０の構成を示す。配信サーバ３２０は、エンコーダ２００（映像データ転送部２０４）からの映像データを映像データ受信部３２１で受信する。映像データ蓄積部３２２は、映像データを保存すると共に、受信映像をデータベースに登録する。

映像データ結合編集部３２４は、Ｗｅｂサーバ３１０（配信情報管理部３１１）からシーン結合要求を受信すると、関連する映像データを結合することで、１つの映像データを生成する。具体的には、映像データ結合編集部３２４は、コミュニケーショングループ毎の配信番組を構成する。

コンテンツ送信部３２３は、クライアント４００の映像ビューア４１０（コンテンツ要求・受信部４１２）からの要求に応じて、指定された映像データを映像ビューア４１０（コンテンツ要求・受信部４１２）に送信する。

（１−６）映像ビューアの構成
図６に、映像ビューア４１０の構成を示す。再生リスト要求・受信部４１１は、Ｗｅｂサーバ３１０（再生リスト生成部３１３）に再生リストを要求し、Ｗｅｂサーバ３１０（再生リスト生成部３１３）から要求した再生リストを受信する。

コンテンツ要求・受信部４１２は、受信した再生リストに基づき、配信サーバ３２０（コンテンツ送信部３２３）にコンテンツを要求し、配信サーバ３２０（コンテンツ送信部３２３）から要求したコンテンツを受信する。

コンテンツ再生部４１３は、受信した映像データを順次再生する。

参照ポイント取得部４１４は、ビューアのコンテンツ再生位置（視聴ポイント）を取得する。

同期情報設定部４１５は、視聴ポイントを更新するようＷｅｂサーバ３１０（同期管理部３１５）に通知する。

同期情報取得部４１６は、グループＩＤに対応する視聴ポイントをＷｅｂサーバ３１０（同期情報管理部３１５）から取得する。

同期調整部４１７は、参照ポイント取得部４１４で得た視聴ポイントと、同期情報取得部４１６で得た視聴ポイントを比較し、ビューアの視聴ポイントを修正する必要があるか評価し、修正する必要があると評価した場合にはビューアの視聴ポイントを修正する。

参照ポイント設定部４１８は、ビューアの参照ポイント（視聴ポイント）を同期調整部４１７から得た値に更新する。

（２）動作
次に、本実施の形態の準ライブシステム１００の動作について説明する。

（２−１）同期処理
先ず、間繋ぎコンテンツを利用した同期処理と、グループ同期について説明する。

＜間繋ぎコンテンツを利用した同期＞
図７に、間繋ぎコンテンツを利用した同期処理のイメージを示す。

図７Ａは、クライアントＡがコンテンツ２を見終わるとき、まだコンテンツ３が存在しない状態であり、クライアントＢはクライアントＡよりも後方（過去）の視聴ポイントにいる。

図７Ｂに示すように、クライアントＡには、予めサーバに蓄積してある間繋ぎコンテンツａを番組として視聴させる。

次に、図７Ｃに示すように、クライアントＡがａを視聴しているときコンテンツ３が到着し、クライアントＢが２を見終わったとする。

すると、図７Ｄに示すように、クライアントＢには、間繋ぎコンテンツａは飛ばし、コンテンツ３を視聴させる。

このように、後行するクライアントＢには、間繋ぎコンテンツを視聴させないことで、全体の同期調整を行うことができる。また、リアルタイムから遠い視聴ポイントから視聴を開始したクライアントＢでも、間繋ぎコンテンツａを飛ばしていくことで、ライブ映像を途切れさせることなく、リアルタイムに近い視聴ポイントに近づけることができる。この結果、視聴開始が遅かったクライアントＢでも、徐々にライブ感の高い映像を視聴できるようになる。

＜グループ同期＞
図８に、グループ同期のイメージを示す。

図８Ａ及び図８Ｂは、グループリーダがクライアントの場合を示すものである。

図８Ａは、コミュニケーショングループＡのリーダ（クライアント）Ａと、このコミュニケーショングループＡに所属しないクライアントＢが異なる場所を視聴している状態を示す。

図８Ｂに示すように、クライアントＢがコミュニケーショングループＡに加わると、クライアントＢを強制的にグループリーダであるクライアントＡの視聴ポイントにジャンプさせる。

図８Ｃ及び図８Ｄは、グループリーダが仮想クライアントの場合を示すものである。

図８Ｃにおける点線はグループリーダである仮想クライアントの視聴ポイントを示すものであり、この視聴ポイント（参照ポイント）は、Ｗｅｂサーバ３１０の同期情報入出力部３１４から同期情報管理部３１５に番組視聴開始時刻（ｈｈ：ｍｍ：ｓｓ）を与え、同期情報管理部３１５によってコミュニケーショングループＢの参照ポイントとして自動で算出されたものである。

図８Ｄに示すように、クライアントＢがコミュニケーショングループＢに加わると、クライアントＢを強制的に仮想参照ポイントにジャンプさせる。

因みに、実際には、グループ内で最も先行した視聴ポイント（すなわち、最もリアルタイムに近い視聴ポイント）を視聴しているクライアントを、又は配信可能な視聴ポイントの中で最もリアルタイムに近い視聴ポイントを仮想的にグループリーダの視聴ポイントに設定すれば、コミュニケーショングループ全体のライブ感を高めることができる。

（２−２）エンコーダの動作
図９のフローチャートを用いて、エンコーダ２００の動作を説明する。

エンコーダ２００は、ＳＴＡＲＴ９ａでエンコード処理を開始すると、映像入力部２０１から映像を取り込み（ＳＴ１１）、エンコード部２０２でそれをエンコードし（ＳＴ１２）、これにより得た映像データをエンコード部２０２の記憶装置に書き出す（ＳＴ１３）。

また、エンコーダ２００は、ＳＴＡＲＴ９ｂで映像データの分割・配信サーバへの送信・Ｗｅｂサーバへの通知処理を開始すると、映像データ時分割部２０３にてステップＳＴ１４−ＳＴ１５−ＳＴ１４を繰り返すことで、分割編集ポイントがくるのを待ち受ける。映像データ時分割部２０３は、分割編集ポイントを検出すると（ＳＴ１５；ＹＥＳ）、映像データを分割する（ＳＴ１６）。これにより、カット編集可能な箇所でブロック分割されたブロックデータが形成される。

次に、エンコーダ２００は、分割した映像データを配信サーバ３２０へブロック転送し（ＳＴ１７）、転送後、Ｗｅｂサーバ３１０へ配信情報更新通知を送信する（ＳＴ１８）。エンコーダ２００は、ステップＳＴ１８の処理の後、再びステップＳＴ１４に戻って、同様の処理を繰り返す。

（２−３）Ｗｅｂサーバの動作
図１０のフローチャートを用いて、Ｗｅｂサーバ３１０の動作を説明する。

Ｗｅｂサーバ３１０は、ＳＴＡＲＴ１０ａで配信情報更新処理を開始すると、配信情報管理部３１１においてステップＳＴ２１−ＳＴ２２−ＳＴ２１の処理を繰り返すことで、エンコーダ２００からの配信情報の更新通知を待ち受ける。

エンコーダ２００から配信情報の更新要求があると（ＳＴ２２；ＹＥＳ）、配信情報管理部３１１は、ステップＳＴ２３で更新通知内容が「映像データの追加」であるか否か判断し、更新通知内容が「映像データの追加」であれば（ＳＴ２３；ＹＥＳ）、ステップＳＴ２４に移って配信情報に追加映像に関する情報を追加することで配信情報を更新し、次にステップＳＴ２１に戻ると共に更新した配信情報を再生リスト生成部３１３に送出する。

更新通知内容が「映像データの追加」でなければ（ＳＴ２３；ＮＯ）、配信情報管理部３１１は、ステップＳＴ２５で更新通知内容が「映像結合」であるか否か判断し、更新通知内容が「映像結合」であれば（ＳＴ２５；ＹＥＳ）、結合要求を配信サーバ３２０に送信し（ＳＴ２６）、更新通知内容が「映像結合」でなければ（ＳＴ２５；ＮＯ）、ステップＳＴ２１に戻る。

配信情報管理部３１１は、ステップＳＴ２６の後、配信サーバ３２０から映像結合処理を完了したことの通知があるまでステップＳＴ２７−ＳＴ２８−ＳＴ２７を繰り返し、通知があると（ＳＴ２８；ＹＥＳ）、ステップＳＴ２９に移って配信情報に結合映像に関する情報を追加することで配信情報を更新し（ＳＴ２９）、ステップＳＴ２１に戻ると共に更新した配信情報を再生リスト生成部３１３に送出する。

また、Ｗｅｂサーバ３１０は、ＳＴＡＲＴ１０ｂで再生リスト作成処理を開始し、再生リスト作成部３１３がステップＳＴ３１−ＳＴ３２−ＳＴ３１を繰り返すことで映像ビューア４１０からの再生リスト作成の要求を待つ。再生リスト作成部３１３は、映像ビューア４１０から再生リスト作成の要求があると（ＳＴ３２；ＹＥＳ）、配信情報管理部３１１の配信情報に基づいて、視聴可能コンテンツを検索することで、再生リストを要求したクライアント４００が視聴可能なコンテンツを列挙し（ＳＴ３３）、ステップＳＴ３４に進む。

再生リスト作成部３１３は、ステップＳＴ３４で視聴可能なコンテンツがあると判断すると（ＳＴ３４；ＹＥＳ）、視聴可能な映像データの一覧を取得し（ＳＴ３５）、映像データ一覧を並べて再生リストを作成する（ＳＴ３７）。これに対して、ステップＳＴ３４で視聴可能なコンテンツがないと判断すると（ＳＴ３４；ＮＯ）、間繋ぎコンテンツを選択し（ＳＴ３６）、間繋ぎコンテンツを含む再生リストを作成する（ＳＴ３７）。

次に、再生リスト作成部３１３は、作成した再生リストをクライアント４００の映像ビューア４１０に送信する（ＳＴ３８）。再生リスト作成部３１３は、ステップＳＴ３８の処理の後、再びステップＳＴ３１に戻って、同様の処理を繰り返す。

（２−４）Ｗｅｂサーバ及び映像ビューアにおけるグループ同期動作
図１１のフローチャートを用いて、Ｗｅｂサーバ３１０及び映像ビューア４１０におけるグループ同期動作を説明する。

Ｗｅｂサーバ３１０は、ＳＴＡＲＴ１１ａで同期情報更新処理を開始する。このＳＴＡＲＴ１１ａで開始する同期情報更新処理とは、グループリーダが実際のクライアントである場合の、グループリーダであるクライアントの視聴ポイントを更新する処理に相当する。Ｗｅｂサーバ３１０の同期情報管理部３１５は、ステップＳＴ４１−ＳＴ４２−ＳＴ４１の処理を繰り返すことで、グループリーダの同期情報設定部４１５からの同期情報を待ち受ける。同期情報管理部３１５は、同期情報を受信すると（ＳＴ４２；ＹＥＳ）、同期データデータベース（同期データＤＢ）３１５−１に格納したグループリーダに関する同期情報を、この受信した同期情報に更新する（ＳＴ４３）。なお、同期データＤＢ３１５−１は、同期情報管理部３１５内に設けられている。

一方、グループリーダが仮想的なものである場合は、Ｗｅｂサーバ３１０は、ＳＴＡＲＴ１１ｂで仮想同期情報の入力処理を開始し、同期情報管理部３１５が同期情報入出力部３１４から入力された仮想同期情報を、グループリーダの同期情報として同期データＤＢ３１５−１に追加する（ＳＴ５１）。

各クライアント４００の映像ビューア４１０は、ＳＴＡＲＴ１１ｃで同期補正処理を開始する。映像ビューア４１０は、ステップＳＴ６１で参照ポイント取得部４１４がビューアの参照ポイント（視聴ポイント）を取得する。次に、ステップＳＴ６２で同期情報取得部４１６が所属するグループリーダの同期情報をＷｅｂサーバ３１０の同期情報管理部３１５から取得する。

次に、ステップＳＴ６３で同期調整部４１７においてグループリーダの同期情報と自装置の同期情報（すなわちグループリーダの視聴ポイントと自装置の視聴ポイント）を比較する、同期調整処理を行う。同期調整部４１７は、グループリーダの視聴ポイントと自装置の視聴ポイントがずれている場合には、自装置の視聴ポイントの更新が必要であると判断し（ＳＴ６４；ＹＥＳ）、自装置の参照ポイントをグループリーダの視聴ポイントに合わせる参照ポイント更新処理を行う（ＳＴ６５）。すなわち、参照ポイント設定部４１８で設定する参照ポイントをグループリーダの視聴ポイントに合わせる。映像ビューア４１０は、ステップＳＴ６４で自装置の参照ポイントの更新が必要ないと判断した場合（ＳＴ６４；ＮＯ）又は参照ポイント更新処理（ＳＴ６５）が終了すると、ステップＳＴ６１に戻る。

（２−５）配信サーバの動作
図１２のフローチャートを用いて、配信サーバ３２０の動作を説明する。

配信サーバ３２０は、ＳＴＡＲＴ１２ａで映像データ保存処理を開始すると、ステップＳＴ７１−ＳＴ７２−ＳＴ７１を繰り返すことでエンコード２００からの映像データを待ち受け、映像データを受信すると（ＳＴ７２；ＹＥＳ）、ステップＳＴ７３に移って映像データ蓄積部３２２の映像データＤＢ３２２−１に映像データを保存する。

配信サーバ３２０は、ＳＴＡＲＴ１２ｂで映像配信処理を開始すると、ステップＳＴ８１−ＳＴ８２−ＳＴ８１を繰り返すことでクライアント４００の映像ビューア４１０からのコンテンツ配信の要求を待ち受け、要求があると（ＳＴ８２；ＹＥＳ）、要求された映像データをクライアント４００の映像ビューア４１０に送信する（ＳＴ８３）。

配信サーバ３２０は、ＳＴＡＲＴ１２ｃで映像データ結合処理を開始すると、ステップＳＴ９１−ＳＴ９２−ＳＴ９１を繰り返すことでＷｅｂサーバ３１０からの映像データの結合要求を待ち受け、結合要求があると（ＳＴ９２；ＹＥＳ）、ステップＳＴ９３に移って映像データ結合編集部３２４によって要求に応じた関連映像データを１つの映像データに結合する。これにより、コミュニケーショングループ毎の番組が構成される。

次に、配信サーバ３２０は、結合した映像データを映像データＤＢ３２２−１に書き込み（ＳＴ９４）、結合が完了したことをＷｅｂサーバ３１０に通知する（ＳＴ９５）。

（３）管理画面
図１３に、配信情報管理画面を示す。図１３の配信情報管理画面は、配信サーバ３２０で管理している映像データの利用状態や、Ｗｅｂサーバ３１０で管理している番組構成（並べ方）を編集する機能を、Ｗｅｂブラウザ４００ａで提供する実現例を示すものである。

また図１４に、同期情報管理画面を示す。図１４の同期情報管理画面は、Ｗｅｂサーバ３１０で管理している同期情報の編集と、仮想同期情報の登録が行える機能を、Ｗｅｂブラウザ４００ａで提供する実現例を示すものである。

（４）効果
以上説明したように、本実施の形態によれば、ライブ配信用の映像をカット編集可能な箇所でブロック分割及び圧縮し、ブロック分割した圧縮映像データをサーバに転送するエンコーダ２００−１，２００−２と、配信状況及び又はクライアントの要求に応じて、ブロック分割された映像データを結合して配信番組を作成するサーバ３００とを設けたことにより、特殊なサーバやビューアを用いずに、すなわち従来の配信システムインフラをほとんど変えずに、エンコーダ２００−１，２００−２と配信サーバ３２０間で安定したデータ転送を行うことができ、エンコーダ２００−１，２００−２と配信サーバ３２０間のネットワークが不安定な状態になった場合でも、視聴者に安定的にライブ映像を配信できるライブ配信システム１００を実現できる。

コミュニケーショングループ毎に配信情報を管理する配信情報管理部３１１を有するＷｅｂサーバ３１０と、配信情報管理部３１１からの要求に基づいてライブ映像を結合することで、コミュニケーショングループ毎の番組を構成する映像データ結合編集部３２４を有する配信サーバ３２０とを設けたことにより、コミュニケーショングループ内のクライアントは同一のライブ番組を視聴しながら、チャットや、掲示板、携帯電話等で会話を行うことができるようになる。

また、Ｗｅｂサーバ３１０に、コミュニケーショングループ毎の同期情報を管理し、コミュニケーション毎に異なる同期情報を、クライアント４００に送信する同期情報管理部３１５を設けたので、同一のコミュニケーショングループに属するクライアント４００の視聴ポイントを同一位置とすることができるので、同一のコミュニケーショングループ内のクライアント４００は同一視聴ポイントの映像・音声を視聴しながら、会話できるようになる。すなわち、配信される番組が同じでも視聴ポイントが異なると、会話がかみ合わなくなるおそれがあるが、これを有効に回避することができる。

また、配信サーバ３２０によって、配信番組中に、ライブ映像とは異なる間繋ぎコンテンツを挿入し、映像ビューア４１０によって、視聴ポイントに応じて、間繋ぎコンテンツを飛ばした映像を再生するようにしたので、リアルタイムから遠い視聴ポイントから視聴を開始した場合でも、間繋ぎコンテンツを飛ばしていくことで、ライブ映像を途切れさせることなく、リアルタイムに近い視聴ポイントに近づけることができる。この結果、視聴開始が遅かったクライアント４００でも、徐々にライブ感の高い映像を視聴できるようになる。

また、エンコーダ２００によって、クリップ単位に分割した映像データを配信サーバ３２０に送信すると共に、クリップ毎に映像データの送信が終了したことをＷｅｂサーバ３１０に通知するようにしたので、配信サーバ３２０は、エンコーダ２００からのクリップ映像が確実に到達してから、配信番組を構成し、クライアント４００にライブ映像を配信できるようになる。この結果、エンコーダ２００と配信サーバ３２０との間の回線状態等に応じて、クライアント４００に配信するライブ映像がクリップ内で途切れることを確実に回避できる。

本発明は、インターネットを利用したライブ配信システムに広く適用可能である。

本発明の実施の形態に係る準ライブ配信システムの原理構成を示す模式図 実施の形態の準ライブ配信システムの全体構成を示すブロック図 エンコーダの構成を示すブロック図 Ｗｅｂサーバの構成を示すブロック図 配信サーバの構成を示すブロック図 映像ビューアの構成を示すブロック図 間繋ぎコンテンツを利用した同期処理のイメージを示す図 グループ同期のイメージを示す図 エンコーダの動作の説明に供するフローチャート Ｗｅｂサーバの動作の説明に供するフローチャート Ｗｅｂサーバと映像ビューアの動作の説明に供するフローチャート 配信サーバの動作の説明に供するフローチャート 配信情報管理画面の実現例を示す図 同期情報管理画面の実現例を示す図 従来のライブ配信システムの構成例を示す図

符号の説明

１００ 準ライブ配信システム
２００ エンコーダ
２０３ 映像データ時分割部
２０５ シーン設定部
２０６ 配信情報更新通知部
３００ サーバ
３１０ Ｗｅｂサーバ
３１１ 配信情報管理部
３１５ 同期情報管理部
３２０ 配信サーバ
３２４ 映像データ結合編集部
４００ クライアント
４００ａ Ｗｅｂブラウザ
４００ｂ 配信ページ
４１０ 映像ビューア
４１４ 参照ポイント取得部
４１５ 同期情報設定部
４１６ 同期情報取得部
４１７ 同期調整部
５００ａ，５００ｂ，５００ｃ コミュニケーショングループ

Claims (10)

1. ライブ配信用の映像をカット編集可能な箇所でブロック分割及び圧縮し、ブロック分割した圧縮映像データをサーバに転送するエンコーダと、
   配信状況及び又はクライアントの要求に応じて、前記ブロック分割された映像データを結合して配信番組を作成するサーバと、
   を具備するライブ配信システム。
2. 前記サーバは、
   コミュニケーショングループ毎に配信情報を管理する配信情報管理部を有するＷｅｂサーバと、
   前記配信情報管理部からの要求に基づいてライブ映像を結合することで、前記コミュニケーショングループ毎の配信番組を構成する映像データ結合編集部を有する配信サーバと、
   を具備する請求項１に記載のライブ配信システム。
3. コミュニケーショングループ毎に配信情報を管理する配信情報管理部を有するＷｅｂサーバと、
   前記配信情報管理部からの要求に基づいてライブ映像を結合することで、前記コミュニケーショングループ毎の配信番組を構成する映像データ結合編集部を有する配信サーバと、
   を具備するライブ配信システム。
4. 前記Ｗｅｂサーバは、前記コミュニケーショングループ毎の同期情報を管理し、コミュニケーション毎に異なる同期情報を、前記クライアント端末に送信する同期情報管理部を、さらに具備する
   請求項３に記載のライブ配信システム。
5. 前記同期情報管理部は、前記コミュニケーショングループ内の特定のクライアント端末の視聴ポイント、又は、仮想的に設定した視聴ポイントを、前記コミュニケーショングループに属する複数のクライアント端末に、前記同期情報として送信する
   請求項４に記載のライブ配信システム。
6. 前記配信サーバは、前記配信番組中に、ライブ映像とは異なる間繋ぎコンテンツを挿入し、
   クライアント端末の映像ビューアは、視聴ポイントに応じて、前記間繋ぎコンテンツを飛ばした映像を再生する
   請求項３から請求項５のいずれかに記載のライブ配信システム。
7. コミュニケーショングループ毎に配信情報を管理する配信情報管理部と、
   前記コミュニケーショングループ毎の同期情報を管理し、コミュニケーション毎に異なる同期情報を、前記クライアント端末に送信する同期情報管理部と、
   を具備するＷｅｂサーバ。
8. 前記同期情報管理部は、前記コミュニケーショングループ内の特定のクライアント端末の視聴ポイント、又は、仮想的に設定した視聴ポイントを、前記コミュニケーショングループに属する複数のクライアント端末に、前記同期情報として送信する
   請求項７に記載のＷｅｂサーバ。
9. ライブ配信システムのサーバに回線により接続され、前記サーバにライブ映像データを供給するエンコーダであって、
   クリップ単位に分割した圧縮映像データを前記サーバに送信すると共に、クリップ毎に圧縮映像データの送信が終了したことを前記サーバに通知する
   エンコーダ。
10. サーバにおいてコミュニケーショングループ毎に配信番組を構成するステップと、
    コミュニケーショングループ毎に視聴ポイントの同期をとるステップと、
    を含む、ライブ配信システムにおける配信管理方法。
    

Images