(57)【要約】【課題】記録を目的としないライブ配信において、視聴しているユーザが所望のタイミングで録画を要求して速やかに録画画像を取得できるようにする。【解決手段】映像配信サーバ１０２は、記録開始点または記録終了点についての情報を携帯端末１０４から受信する。そして、記録開始点から前記記録終了点までの範囲のパケットをバッファ１１から読み出して携帯端末１０４に対してＨＴＴＰストリーミングで送信したり、ＭＰ４ファイルを生成してメールに添付して送信したり、生成したＭＰ４ファイルのダウンロードを促したりして提示するようにして、記録を目的としないライブ配信において、視聴しているユーザは、所望のタイミングで録画を要求して速やかに録画画像を取得できるようにする。【選択図】図１
2008187505.tif 000002
【特許請求の範囲】
【請求項１】
受信端末に対して映像及び音声をストリーミング配信する映像送信装置であって、
前記受信端末に対してストリーミング配信する映像及び音声をバッファに記録する制御を行う記録制御手段と、
前記映像及び音声の記録開始点または記録終了点に係わる情報を前記受信端末から受信する受信手段と、
前記受信手段によって受信された情報における記録開始点から記録終了点までの範囲の映像及び音声を前記バッファから読み出して前記受信端末に提供する提供手段とを有することを特徴とする映像送信装置。
【請求項２】
前記受信手段によって受信された情報を用いて前記記録制御手段が記録に要する時間を算出する算出手段を有し、
前記記録制御手段は、前記算出手段により算出された記録に要する時間に応じて前記バッファからパケットを削除することを特徴とする請求項１に記載の映像送信装置。
【請求項３】
前記算出手段は、前記受信手段によって受信された情報を用いて前記記録制御手段が記録に必要なバッファサイズを算出し、
前記記録制御手段は、前記バッファを前記算出手段により算出された記録に必要なバッファサイズに変更することを特徴とする請求項２に記載の映像送信装置。
【請求項４】
前記記録開始点から記録終了点までの範囲のパケットをファイル形式で生成するファイル生成手段を有することを特徴とする請求項１に記載の映像送信装置。
【請求項５】
前記受信端末からの記録指示情報を含む管理テーブルを有し、
前記記録制御手段は、前記管理テーブルを用いて記録の制御と前記バッファの制御とを行うことを特徴とする請求項１に記載の映像送信装置。
【請求項６】
映像及び音声をストリーミング配信する映像送信装置に対して前記映像及び音声を要求する受信端末であって、
前記映像送信装置から配信される映像及び音声を受信する映像受信手段と、
前記映像送信装置から配信される映像及び音声を記録する際に、前記映像及び音声の記録開始点または記録終了点を入力する入力手段と、
前記入力手段によって入力された記録開始点または記録終了点に係わる情報を前記映像送信装置に送信する送信手段とを有することを特徴とする受信端末。
【請求項７】
前記記録開始点または記録終了点が他の装置により設定されている場合は、前記入力手段は、前記記録開始点から前記記録終了点までの範囲のパケットを要求するか否かを入力し、
前記送信手段は、前記入力手段によって入力された、前記パケットを要求するか否かに係わる情報を前記映像送信装置に送信することを特徴とする請求項６に記載の受信端末。
【請求項８】
請求項１〜５の何れか１項に記載の映像送信装置と、請求項６または７に記載の受信端末とを有することを特徴とする動画像記録システム。
【請求項９】
受信端末に対して映像及び音声をストリーミング配信する映像送信方法であって、
前記受信端末に対してストリーミング配信する映像及び音声をバッファに記録する制御を行う記録制御工程と、
前記映像及び音声の記録開始点または記録終了点に係わる情報を前記受信端末から受信する受信工程と、
前記受信工程おいて受信した情報における記録開始点から記録終了点までの範囲の映像及び音声を前記バッファから読み出して前記受信端末に提供する提供工程とを有することを特徴とする映像送信方法。
【請求項１０】
映像及び音声をストリーミング配信する映像送信装置に対して前記映像及び音声を要求する受信端末の制御方法であって、
前記映像送信装置から配信される映像及び音声を受信する映像受信工程と、
前記映像送信装置から配信される映像及び音声を記録する際に、前記映像及び音声の記録開始点または記録終了点を入力する入力工程と、
前記入力工程において入力した記録開始点または記録終了点に係わる情報を前記映像送信装置に送信する送信工程とを有することを特徴とする受信端末の制御方法。
【請求項１１】
受信端末に対して映像及び音声をストリーミング配信する映像送信方法の各工程をコンピュータに実行させるプログラムであって、
前記受信端末に対してストリーミング配信する映像及び音声をバッファに記録する制御を行う記録制御工程と、
前記映像及び音声の記録開始点または記録終了点に係わる情報を前記受信端末から受信する受信工程と、
前記受信工程おいて受信した情報における記録開始点から記録終了点までの範囲の映像及び音声を前記バッファから読み出して前記受信端末に提供する提供工程とをコンピュータに実行させることを特徴とするプログラム。
【請求項１２】
映像及び音声をストリーミング配信する映像送信装置に対して前記映像及び音声を要求する受信端末の制御方法の各工程をコンピュータに実行させるプログラムであって、
前記映像送信装置から配信される映像及び音声を受信する映像受信工程と、
前記映像送信装置から配信される映像及び音声を記録する際に、前記映像及び音声の記録開始点または記録終了点を入力する入力工程と、
前記入力工程において入力した記録開始点または記録終了点に係わる情報を前記映像送信装置に送信する送信工程とをコンピュータに実行させることを特徴とするプログラム。
【請求項１３】
請求項１１または１２に記載のプログラムを記憶したことを特徴とするコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は映像送信装置、受信端末、動画像記録システム、映像送信方法、受信端末の制御方法、プログラム及び記憶媒体に関し、特に、リアルタイム性を重視した映像を配信する際に、ユーザが所望するタイミングで確実に保存できるようにするために用いて好適な技術に関する。
【背景技術】
【０００２】
近年の通信システムの発展により、カメラのライブ映像や蓄積された動画映像をインターネットなどの通信回線を通じて見ることが一般的に行われるようになってきた。また、無線通信機器が安価になったことや、通信回線が大容量化されてきたことにより、家庭内や職場内においても、ネットワークで接続された機器から動画映像を参照する機会も増加している。
【０００３】
特に、ライブ映像に関しては、監視カメラや定点カメラ、またはコンサートやイベントの映像の配信を行い、それらのライブ映像を携帯電話やＰＤＡのような携帯機器で視聴する形態も普及してきた。
【０００４】
一般に、記録済みのコンテンツを視聴する場合には、ダウンロード再生のように視聴しながらコンテンツを取得し、市販のアプリケーションを用いて編集を行う目的で使用される場合もある。ところが、ライブ映像の場合は、記録を伴わない映像配信機器も多く、その場合、過去に戻った編集を行うことができない。
【０００５】
また、記録を並行して行うライブ配信においても、特に監視カメラや定点カメラの場合には記録指定範囲が明確でないため、記録するには巨大な記録領域が必要である。このように、ライブ映像を携帯機器で視聴する際には、携帯電話やＰＤＡのような携帯機器では、蓄積容量がＰＣや動画像蓄積機器と比較して一般的に小さいということもあり、視聴のみを目的とした手段として考えられている。
【０００６】
しかし、そのような携帯機器で視聴しているユーザにとっては、稀に視聴したライブ映像の部分的な動画像データを必要とする場合がある。例えば、監視カメラを視聴していたら異常部分を確認し、その状況が治まる期間の映像を取得したかったり、イベントやコンサートで知り合いや自分の好きなタレントが出演する部分のみを取得したかったりといった状況が考えられる。
【０００７】
従来、そのような場合には、ライブ視聴目的のストリームと並行して蓄積機器へ記録を行う。そして、その蓄積された全体の映像から所望する部分の抽出を行うステップを要する。このように、常時記録された映像やイベントを記録した全体の映像からある部分を抽出するには、旧型のビデオテープによる記録方法の場合は、その蓄積機器の設置場所に赴く必要がある。もしくはそのテープを入手して蓄積された映像から所望の映像の凡その時間を参考に再生を行い、所望部分の映像を取得する必要がある。また、電子データの場合でも、データファイルを自分の動画像編集可能なＰＣ等の機器に一度取り込み、専用のアプリケーションにより再生を行いながら同様に時間などを参考にして、所望の部分を確認し編集作業を行う必要がある。
【０００８】
このように、従来、ライブ映像の部分抽出を行う場合には、一度記録した動画像データが存在することが前提としている。さらに、再生を行って再度確認してから編集するといった作業が必要となるので、リアルタイムな画像を視聴してから所望する動画像を実際に取得するまでには、手間がかかるとともに大きなタイムラグが発生する問題点があった。
【０００９】
そこで、前記のようなライブ映像を一度記録した後に、データファイルを自分の端末に取り込むことなく編集を行うために、記録済みの動画像コンテンツが保存されているサーバ装置からストリーミング再生する。そして、再生を行っているプレーヤに編集ポイントのイベントを送出して、編集点の時間長を取得するといった処理を行い、それら編集情報をサーバに送信する。これにより、データファイルの送受信を行わずに編集を可能とする編集方法が提案されている（例えば、特許文献１参照）。
【００１０】
【特許文献１】特開２００３−１２５３３９号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、特許文献１に記載の編集方法では、記録済みコンテンツをネットワーク上に保存しておく蓄積容量が必要であり、また、記録済みのファイルに関してのみ有効であるため、記録を行わないライブ配信に関しては適用されなかった。さらに、それぞれの編集点を算出し、編集点の算出が完了した上で、サーバへ情報配信が行われて初めてコンテンツの編集が可能となる。このため、編集点を算出してから編集した動画像を取得するまでに長い時間がかかってしまうという問題点があった。
【００１２】
本発明は前述の問題点に鑑み、視聴しているユーザが所望する範囲の動画像を、ユーザが所望するタイミングで確実に保存可能とすることを、大容量の蓄積領域や装置を用いることなく実現できるようにすることを目的とする。
【課題を解決するための手段】
【００１３】
本発明の映像送信装置は、受信端末に対して映像及び音声をストリーミング配信する映像送信装置であって、前記受信端末に対してストリーミング配信する映像及び音声をバッファに記録する制御を行う記録制御手段と、前記映像及び音声の記録開始点または記録終了点に係わる情報を前記受信端末から受信する受信手段と、前記受信手段によって受信された情報における記録開始点から記録終了点までの範囲の映像及び音声を前記バッファから読み出して前記受信端末に提供する提供手段とを有することを特徴とする。
【００１４】
本発明の受信端末は、映像及び音声をストリーミング配信する映像送信装置に対して前記映像及び音声を要求する受信端末であって、前記映像送信装置から配信される映像及び音声を受信する映像受信手段と、前記映像送信装置から配信される映像及び音声を記録する際に、前記映像及び音声の記録開始点または記録終了点を入力する入力手段と、前記入力手段によって入力された記録開始点または記録終了点に係わる情報を前記映像送信装置に送信する送信手段とを有することを特徴とする。
【００１５】
本発明の動画像記録システムは、前記に記載の映像送信装置と、前記に記載の受信端末とを有することを特徴とする。
【００１６】
本発明の映像送信方法は、受信端末に対して映像及び音声をストリーミング配信する映像送信方法であって、前記受信端末に対してストリーミング配信する映像及び音声をバッファに記録する制御を行う記録制御工程と、前記映像及び音声の記録開始点または記録終了点に係わる情報を前記受信端末から受信する受信工程と、前記受信工程おいて受信した情報における記録開始点から記録終了点までの範囲の映像及び音声を前記バッファから読み出して前記受信端末に提供する提供工程とを有することを特徴とする。
【００１７】
本発明の受信端末の制御方法は、映像及び音声をストリーミング配信する映像送信装置に対して前記映像及び音声を要求する受信端末の制御方法であって、前記映像送信装置から配信される映像及び音声を受信する映像受信工程と、前記映像送信装置から配信される映像及び音声を記録する際に、前記映像及び音声の記録開始点または記録終了点を入力する入力工程と、前記入力工程において入力した記録開始点または記録終了点に係わる情報を前記映像送信装置に送信する送信工程とを有することを特徴とする。
【００１８】
本発明のプログラムは、受信端末に対して映像及び音声をストリーミング配信する映像送信方法の各工程をコンピュータに実行させるプログラムであって、前記受信端末に対してストリーミング配信する映像及び音声をバッファに記録する制御を行う記録制御工程と、前記映像及び音声の記録開始点または記録終了点に係わる情報を前記受信端末から受信する受信工程と、前記受信工程おいて受信した情報における記録開始点から記録終了点までの範囲の映像及び音声を前記バッファから読み出して前記受信端末に提供する提供工程とをコンピュータに実行させることを特徴とする。
本発明のプログラムの他の特徴とするところは、映像及び音声をストリーミング配信する映像送信装置に対して前記映像及び音声を要求する受信端末の制御方法の各工程をコンピュータに実行させるプログラムであって、前記映像送信装置から配信される映像及び音声を受信する映像受信工程と、前記映像送信装置から配信される映像及び音声を記録する際に、前記映像及び音声の記録開始点または記録終了点を入力する入力工程と、前記入力工程において入力した記録開始点または記録終了点に係わる情報を前記映像送信装置に送信する送信工程とをコンピュータに実行させることを特徴とする。
【００１９】
本発明の記憶媒体は、前記の何れかに記載のプログラムを記憶したことを特徴とする。
【発明の効果】
【００２０】
本発明によれば、受信端末において指定された記録開始点または記録終了点と付帯情報とを含む情報を受信した場合には、前記記録開始点から前記記録終了点までの範囲のパケットをバッファから読み出して前記受信端末に提供するようにした。これにより、記録を目的としないライブ配信において、視聴しているユーザが所望する範囲の動画像を、ユーザが所望するタイミングで確実に保存できるようにすることを、大容量の蓄積領域や装置を用いることなく実現することができる。
【発明を実施するための最良の形態】
【００２１】
（第１の実施形態）
以下、図面を参照しながら本発明の実施形態について説明する。
図１は、本実施形態における映像視聴システム（動画像記録システム）の構成例を示す図である。図１に示すように、カメラ１０１で撮像した映像及び音声からなる動画像データを映像配信サーバ１０２でストリーミング配信を行い、ネットワーク１０３を介して携帯端末１０４で視聴するという構成を例に説明する。
【００２２】
なお、映像配信サーバ１０２から携帯端末１０４へ映像の配信に使用されるプロトコルとして、本実施形態ではＲＴＰ（Real-time Transport Protocol、RFC 3550、The Internet Society）を利用する。また、ＲＴＰ制御プロトコルとして同様にＲＦＣ３５００で定義されているＲＴＣＰ（RTP Control Protocol）も用いるものとする。
【００２３】
ＲＴＣＰのパケットは、受信レポート（ＲＲ：Receiver Report）、送信レポート（ＳＲ：Sender Report）、ソース記述（ＳＤＥＳ：Source Description）、メンバシップ管理（ＢＹＥ）、及びアプリケーション定義（ＡＰＰ：Application-Defined）の５種類で定義されている。本実施形態では主に受信レポートを使用するため、図３を参照しながらＲＴＣＰパケットのＲＲタイプの構成を説明する。
【００２４】
ＲＴＣＰパケット（ＲＲ）は、前述したように受信レポートと呼ばれており、ストリーム受信装置からストリーム送信装置へ送信される。ＲＴＣＰパケットは、ＲＴＣＰヘッダ３０１とＲＴＣＰヘッダ３０１のＲＣ（Reception Report Count）３０６に示す個数分の「reception report block」３０２とプロファイル依存拡張部分３０３とから構成される。
【００２５】
「reception report block」３０２は、ストリーム受信装置がストリーム送信装置へ報告するストリームの受信状態を表しており、パケット廃棄率やジッタ等の情報を含む。また、ＬＳＲ３０４は最後に受信した送信レポート（ＳＲ）のタイムスタンプを表し、ＤＬＳＲ３０５は最後に受信した送信レポート（ＳＲ）から経過した経過時間を表している。このＬＳＲ３０４、及びＤＬＳＲ３０５を用いることによってサーバとクライアントとの間のネットワークの往復時間も取得することができる。
【００２６】
［視聴端末からサーバに対する記録指示及びその処理の概要］
以下、本実施形態に関わる携帯端末１０４から映像配信サーバ１０２に対する記録指示及びその処理の概要について説明する。図１１は、本実施形態における映像配信サーバ１０２及び携帯端末１０４の機能構成例を示すブロック図である。
【００２７】
ライブ配信を行う映像配信サーバ１０２には、リングバッファのような小さなデータ保存領域（バッファ）１１を確保する。このバッファ１１は、ストリーミング配信を行ったパケットを一定期間保存しておく領域として使用される。そして、通信部１０を介して行われるストリーミング配信と同時に、送信するパケットを記録制御部１２がバッファ１１にコピーして保存する。
【００２８】
ユーザが配信データの記録を希望した場合には、ライブ配信を視聴しているクライアント側で記録開始イベントを設定する。イベント設定に関しては、図２に示すように、携帯端末１０４に「記録開始ボタン」２０１、及び「記録終了ボタン」２０２が予め割り当てられている。そして、ライブ動画像データ（映像データ及び音声データ）を視聴中にこれらのボタン２０１、２０２が押下された時に、それぞれ、記録開始イベント、記録終了イベントが発生する。
【００２９】
記録開始イベントが発生すると、携帯端末１０４は、その視聴時点のパケットの情報であるシーケンスナンバとＴｉｍｅＳｔａｍｐとを取得し、開始点（以下、ＩＮという）を設定する。また、記録終了イベントが発生すると、同様にその時点のパケットの情報を取得して終了点（以下、ＯＵＴという）を設定する。
【００３０】
次に、携帯端末１０４の「記録開始ボタン」２０１が押下された場合の処理の詳細を説明する。前述したように、携帯端末１０４の「記録開始ボタン」２０１が押下されると、入力部２２から入力される信号に基づいて記録開始イベントが発生し、ＩＮ／ＯＵＴ設定部２３で視聴時点のパケットの情報を取得してＩＮを設定する。そのＩＮの関する情報は、図４に示すような記述として文字列を生成し、ＲＴＣＰパケットのプロファイル依存拡張部分３０３に付加する。
【００３１】
図４に示す記述の内容には、付帯情報として記録を行うか否かの制御（Control）とその制御内容を表す文字列と、記録のポイント（Point）をそのポイント内容を表す文字列とがある。さらに、その該当するパケットのシーケンスナンバ（SeqNo）やタイムスタンプ(TimeStamp)のようなパケットを識別する値がある。
【００３２】
映像配信サーバ１０２から携帯端末１０４へ送信するパケットの流れと、携帯端末１０４から映像配信サーバ１０２に対する記録指示の処理の概念図を図５に示す。映像配信サーバ１０２側は、携帯端末１０４から通信部２１を介して送られたＲＴＣＰパケットのプロファイル依存拡張部分３０３に記述された記録開始命令、及びその該当するパケットのシーケンスナンバやTimeStampを判断する。そして、バッファ１１から該当するパケットを読み出す。そして、提供方法としては、蓄積可能な容量が確保された視聴クライアントに対して、別セッションにてその読み出したパケットをＨＴＴＰストリーミングで送信する。
【００３３】
このＨＴＴＰストリーミングで送信する視聴クライアントの指定は、視聴開始前に予め映像配信サーバ１０２へ通知される。記録終了ポイントの場合も同様にＲＴＣＰパケットのプロファイル依存拡張部分３０３に、図４の記述例に従って終了を指示する文字列を付加して映像配信サーバ１０２に通知される。これにより、ＨＴＴＰストリーミングを終了する。
【００３４】
また、他の提供方法として、終了が決定した時点で、ファイル生成部１３でＭＰ４ファイルとして動画像コンテンツファイルを生成し、視聴クライアントへその生成したＭＰ４ファイルを添付してメールを送信してもよい。もしくはＭＰ４ファイルのダウンロードを促す方法を例えばメールで提供したりしてもよい。
【００３５】
なお、最終的な区間指定を行った記録ファイルの取得方法において、前述のＨＴＴＰストリーミング、ＭＰ４ファイルのメール送信、ＭＰ４ファイルのダウンロードの何れかの方法を選択させる機能を携帯端末１０４に持たせてもよい。
【００３６】
なお、前述した記録ファイルの取得方法のうち、記録範囲の指定が完了してからＭＰ４ファイルを映像配信サーバ１０２上で予め生成する方法に関しては、ＩＮからＯＵＴまでのパケットを映像配信サーバ１０２内で保存しておくことが必要となる。このため、バッファ１１のサイズによっては、ＩＮからＯＵＴまでのパケットを同一バッファ１１内で保存できない場合がある。その場合には、ＩＮからバッファ１１が満たされた時点までのパケットで仮のＭＰ４ファイルを生成し、この生成を繰り返して最終的にＯＵＴを受け取った際に、それまでの分割された複数のＭＰ４ファイルを連結するようにしてもよい。
【００３７】
また、同じユーザで同一カメラにおける複数の記録要求をＭＰ４ファイルで希望する場合には、その都度作成された断片の映像を時系列に従って自動連結するようにしてもよい。この場合、煩雑なファイルの整理と再視聴の利便性とにおいて有効である。
【００３８】
［バッファのサイズ］
映像配信サーバ１０２側のバッファ１１のサイズに関しては、時間／サイズ算出部１４において記録に必要なバッファサイズを算出し、記録制御部１２がバッファサイズを変更する。すなわち、システムとして固定値あるいは前述のＲＴＣＰパケットの送信間隔やＲＴＣＰ情報による映像配信サーバ１０２と携帯端末１０４との間の遅延情報から動的にバッファサイズを変更することができる。
【００３９】
［バッファのクリア］
映像受信側（携帯端末１０４側）から送られる記録開始を通知するＲＴＣＰパケットのプロファイル依存拡張部分３０３に記録開始の記述が無い場合には、記録制御部１２はバッファ１１内に記録されたパケットをクリアする手段を有するようにしている。また、クリアするパケットの範囲に関しては、時間／サイズ算出部１４において算出する。前述のＲＴＣＰパケットの送信間隔や、映像を配信する映像配信サーバ１０２側（映像配信側）と、映像を受信する携帯端末１０４側（映像受信側）との間の遅延情報から、次に受信するＲＴＣＰパケットでＩＮの指定の可能性がないパケットの範囲を計算できる。さらに、映像配信サーバ１０２側にＴｉｍｅＯｕｔ値を予め設定し、そのＴｉｍｅＯｕｔ時間を超えた場合には該当データ（パケット）を削除することができる。
【００４０】
［複数クライアント接続時の処理］
複数のクライアントと接続する場合には、映像配信サーバ１０２側で確保可能なバッファ１１のサイズには上限があるため、接続クライアントが１つの場合にはバッファ１１をフルに使用し、ある程度の画像データの保存が可能である。しかし、複数の場合には、最少でもＲＴＣＰの送信間隔分のバッファ１１が確保できるクライアント数を決定し、そのクライアント数を超過した場合には、その旨のエラーメッセージを表示し、接続不可能にする。そして、バッファ１１に保存したパケットを用いて、前述の携帯端末１０４から映像配信サーバ１０２に対する記録指示に従い処理を行うようにする。
【００４１】
また、複数のクライアントを管理する場合には、映像配信サーバ１０２側は図６に示すような記録指示情報を含んだ管理テーブルを保持する。図６に示す管理テーブルには、ユーザ名、セッションＩＤ、カメラＩＤ、ＩＮ（ＤＡＴＥ、ＴｉｍｅＳｔａｍｐ）、ＯＵＴ（ＤＡＴＥ、ＴｉｍｅＳｔａｍｐ）、記録済みフラグの情報等のような、記録指示情報が含まれる。
【００４２】
次に、複数のクライアントに対する管理テーブルを用いた処理について説明する。映像配信サーバ１０２がＩＮの要求を受け取った場合には、パケットの保存と同時にその情報を管理テーブルに書き込む。記録コンテンツの提供方法がＨＴＴＰストリーミングの場合には、ＩＮの指定パケットからＨＴＴＰストリーミングで送信する。そして、他のクライアントからＩＮ要求を受け取り、かつそのＩＮの指定パケットがバッファ１１に記録済みの場合には、管理テーブルに情報の書き込みを行い、クライアント指定のＨＴＴＰストリーミングを開始する。
【００４３】
次に、ＯＵＴの処理に関して、クライアントが複数存在する時におけるＯＵＴイベント発生時の映像配信サーバ１０２における処理の詳細について、図１０に示すフローチャートを参照しながら説明する。
映像配信サーバ１０２がＲＴＣＰパケットのＯＵＴ指示を受けると、まず、記録コンテンツの提供方法がＨＴＴＰストリーミングの場合には、ＨＴＴＰストリーミングを終了する。また、ＭＰ４ファイル形式で提供する場合には、指定区間のＭＰ４ファイルを生成する（ステップＳ１００１）。
【００４４】
次に、映像配信サーバ１０２が保持する管理テーブル内の該当するユーザに送信するデータへＯＵＴのデータを挿入する（ステップＳ１００２）。次に、ステップＳ１００１でＨＴＴＰストリーミングが終了するか、またはＭＰ４ファイルが生成されたので、ステップＳ１００２で完了したオーダに関して管理テーブル上の記録済みフラグを「Ｙ」に変更する。もしくは管理テーブルからデータの削除を行う（ステップＳ１００３）。
【００４５】
次に、バッファ１１内に保存されているパケットのうち、管理テーブル内の最も古いＴｉｍｅＳｔａｍｐよりも古いＴｉｍｅＳｔａｍｐのパケットが存在するか否かチェックする（ステップＳ１００４）。このチェックの結果、存在しない場合は、処理を終了する。
【００４６】
一方、ステップＳ１００４のチェックの結果、存在する場合は、バッファ１１内に保存されているパケットのうち、管理テーブル内の記録済みフラグが「Ｎ」で最も古いＴｉｍｅＳｔａｍｐよりも古いパケットを全て削除する（ステップＳ１００５）。そして、処理を終了する。
【００４７】
以上、図１０に示すフローチャートを参照しながら説明したクライアントが複数存在する時におけるＯＵＴイベント発生時の映像配信サーバ１０２による処理の概念図を図９に示す。映像配信サーバ１０２においてパケットの記録中９０１に、第１のユーザからＯＵＴイベントが発生９０３した場合、第１のユーザの分のパケットのうち、他の記録中のユーザと重複しない部分のパケットをバッファ１１から削除する。そして、第２のユーザ及び第３のユーザの分のパケットの記録９０２を継続する。
【００４８】
［通信エラーにおける対処］
クライアントからＩＮ／ＯＵＴが指定されて記録を行うにあたり、映像配信サーバ１０２がＩＮを受け取った後、クライアントがＯＵＴを送信する前にネットワーク接続が切断される場合、または、ＯＵＴのパケットがパケットロスする場合がある。この場合には、映像配信サーバ１０２側で予め設定したＴｉｍｅＯｕｔ値により記録終了地点を決定する。すなわち、指定されたＩＮにＴｉｍｅＯｕｔ値を加算したＴｉｍｅＳｔａｍｐのパケットを強制的にＯＵＴのパケットとする。
【００４９】
このように、このＴｉｍｅＯｕｔ値は、記録指定時間の最大値として用いられるとともに、通信エラー時において強制的にＯＵＴのパケットを決定する際に用いられることも可能である。または、クライアントからＩＮを送る場合に、クライアントが予め設定したＴｉｍｅＯｕｔ値を付加して送ることにより、ＯＵＴ無しの場合にはその送られたＴｉｍｅＯｕｔ値を使用するようにしてもよい。
【００５０】
また、反対に映像配信サーバ１０２がＩＮを受け取らずにＯＵＴのみを受信した場合には、バッファ１１に保存されている部分のみを記録し、映像配信サーバ１０２からＲＴＣＰパケットにエラーメッセージを付加して送信する。または、独自パケットを用いてクライアントへ記録不可能な状態にあることを通知するようにしてもよい。
【００５１】
以上のように本実施形態においては、映像配信サーバ１０２は、記録開始点または記録終了点についての情報を携帯端末１０４から受信する。そして、記録開始点から前記記録終了点までの範囲のパケットをバッファ１１から読み出して携帯端末１０４に提示するようにした。これにより、記録を目的としないライブ配信において、視聴しているユーザから、録画が要求された際には、ユーザが所望する範囲の動画像を素早く配信することが可能となるので、ユーザは録画画像を速やかに取得することができる。
【００５２】
（第２の実施形態）
第１の実施形態において、クライアントからＩＮ、ＯＵＴによる記録区間が指定されることにより記録範囲を決定した。これに対し、本実施形態では、センサが何かを検知したら記録するカメラサーバシステムについて説明する。記録範囲はセンサによって決定され、決定された記録範囲における記録の要／不要をクライアントが指定する。
【００５３】
また、本実施形態では、記録と並行してユーザが携帯端末で視聴している時に、センサによる記録の指示の有無も合わせて取得できる。そして、その記録範囲において記録を行うか否かの通知をクライアント（携帯端末）からサーバ側に行い、不要の場合にはサーバ側での記録を中止し、必要な場合には記録を要求する。
【００５４】
これにより、センサの記録要因の検知をした上で、さらにクライアントから記録の指示要求が発生した場合のみサーバ側で記録を行うようにすることが可能となり、不要な記録が行われるのをリアルタイムで制御できる。これにより、記録領域の節約が可能となる。
【００５５】
本実施形態のシステム構成について図７に示す。カメラ１０１で撮像したデータを映像配信サーバ１０２でネットワーク１０３を介して携帯端末１０４に配信する点は、第１の実施形態のシステム構成と同じである。本実施形態では、第１の実施形態のシステム構成に加え、センサ７０１がカメラ１０１に接続されており、バッファとは別に映像を記録する記録装置７０２が映像配信サーバ１０２に接続されている。なお、機能構成については第１の実施形態と同じであるため、説明は省略する。
【００５６】
まず、センサ７０１により何らかの要因を検知した場合に記録するシステムについて説明する。まず、カメラ１０１で撮像した映像を携帯端末１０４にて視聴している際に、センサ７０１により記録指示が発生している場合には、記録対象区間であることを示す情報であるイベント番号や開始時刻が携帯端末１０４に通知される。通知方法については第１の実施形態と同様にＲＴＣＰパケットの送信レポート（ＳＲ）を利用する。あるいは、ＲＴＰパケットのヘッダ拡張部分を利用することも可能である。
【００５７】
クライアント側の携帯端末１０４では、「記録不要ボタン」、「記録要求ボタン」が予め設定されている。この「記録不要ボタン」が押下された場合には、図４の記述の例に従い、制御指示（Control）を「ＣＡＮＣＥＬ」にする。また、本実施形態では、記録ポイント（Point）はセンサ７０１が判断するシステムであるため、第１の実施形態とは異なり「ＮＯＮＥ」に設定する。
【００５８】
さらに、映像配信サーバ１０２から取得したイベント番号を「EventNo=X」として付加して文字列の生成を行い、第１の実施形態と同様にＲＴＣＰパケット（ＲＲ）のプロファイル依存拡張部分３０３を用いて記録の中止命令を送信する。映像配信サーバ１０２は、この中止命令を受信した場合には、該当するイベント番号の記録を中止する。または、記録済みの場合には該当イベント番号の記録部分の削除を行う。
【００５９】
次に、センサ７０１により何らかの要因を検知はするが、基本的に記録は行わず、クライアント側から指示された場合に記録が初めて開始されるようなシステム構成の場合に関して説明する。
クライアント側の携帯端末１０４で視聴を行うと同時に、センサ７０１の検知イベントが発生している通知を受信している際に、その部分の記録を希望する場合には、図４の記述の例に従い、制御指示（Control）を「ＲＥＣ」に設定する。
【００６０】
また、記録ポイント（Point）を「ＮＯＮＥ」に設定する。さらに、映像配信サーバ１０２から取得したイベント番号を「EventNo=X」として付加して文字列の生成を行い第１の実施形態と同様にＲＴＣＰパケット（ＲＲ）のプロファイル依存拡張部分３０３を用いて記録命令を送信する。なお、イベントの記録範囲の管理は、図６で示した映像配信サーバ１０２上の管理テーブルにイベント番号の項目を追加した形式で管理が可能である。
【００６１】
（第３の実施形態）
第１の実施形態における記録開始、及び記録終了の指定方法においては、クライアントで設定されたボタンが押下されたタイミングで記録開始、及び記録終了を指示した。これに対し、本実施形態では、ボタンを押下したタイミングよりも長く時間的に余裕を持たせて記録を行ったり、その都度タイミングを微妙に変更したりすることができる。
【００６２】
［記録開始、終了時間の秒数指定方法］
サーバに開始点（ＩＮ）に余裕を持たせた時間（Ｘ秒）と終了点（ＯＵＴ）に余裕を持たせた時間（Ｙ秒）とを予め設定しておき、それぞれのＩＮ、ＯＵＴ要求に設定値を加減して記録を行う。これにより、クライアントの開始指示タイミングの遅れや終了指示が早かった場合の補填が可能となる。また、携帯端末１０４で「記録開始ボタン」が押下されることによるＩＮ指定の場合に、図８に示すような操作画面８０１を表示し、ＩＮからの記録調節位置を秒数で指定できるようにする。終了点（ＯＵＴ）も同様の操作で記録終了位置を秒数指定により操作できるものとする。
【００６３】
（本発明に係る他の実施形態）
第１〜第３の実施形態では、ストリーミング方法としてＲＴＰ（リアルタイムデータ転送プロトコル）を用いて説明してきた。一方、ＨＴＴＰを用いたストリーミングにおいての記録指示の場合には、映像配信サーバ１０２に記録処理を行うプログラム（ＣＧＩ）を作成し、そのプログラムをＧＥＴメソッドを用いて、図４で示されるような文字列を付加する方法で同様の機能を提供できる。
【００６４】
以上、本発明を好適な実施形態に基づいて説明してきた。しかし、前述した実施形態は本発明の単なる例示に過ぎず、何ら本発明を限定するものではない。例えば、サーバへの通知方法はＲＴＰ／ＲＴＣＰを用いたり、ＨＴＴＰを用いたりして説明したが、これに限らずに独自のパケットによる開始点（ＩＮ）、終了点（ＯＵＴ）の通知も可能とする。
【００６５】
前述した本発明の実施形態における映像送信装置、受信端末を構成する各手段、並びに映像送信方法、受信端末の制御方法の各工程は、コンピュータのＲＡＭやＲＯＭなどに記憶されたプログラムが動作することによって実現できる。このプログラム及び前記プログラムを記録したコンピュータ読み取り可能な記憶媒体は本発明に含まれる。
【００６６】
また、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施形態も可能であり、具体的には、複数の機器から構成されるシステムに適用してもよいし、また、一つの機器からなる装置に適用してもよい。
【００６７】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では図１０に示すフローチャートに対応したプログラム）を、システムまたは装置に直接、または遠隔から供給する場合も含む。そして、そのシステムまたは装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。
【００６８】
したがって、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。
【００６９】
その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。
【００７０】
プログラムを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスクなどがある。さらに、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ、ＤＶＤ−Ｒ）などもある。
【００７１】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する方法がある。そして、前記ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記憶媒体にダウンロードすることによっても供給できる。
【００７２】
また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。
【００７３】
また、その他の方法として、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。
【００７４】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。さらに、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【００７５】
さらに、その他の方法として、まず記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。そして、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によっても前述した実施形態の機能が実現される。
【図面の簡単な説明】
【００７６】
【図１】本発明の第１の実施形態のシステム構成例を示すブロック図である。
【図２】本発明の第１の実施形態の携帯端末における操作及び画面の構成を示す図である。
【図３】ＲＴＣＰパケット（ＲＲタイプ）の構成を示す図である。
【図４】本発明の第１の実施形態のＲＴＣＰパケットへ記述する文字列の一例を示す図である。
【図５】本発明の第１の実施形態のサーバ側とクライアント側とでの処理及び操作の一例の概要を示す図である。
【図６】本発明の第１の実施形態の映像配信サーバの管理テーブルの一例を示す図である。
【図７】本発明の第２の実施形態のシステム構成例を示すブロック図である。
【図８】本発明の第３の実施形態の携帯端末における操作及び画面の構成を示す図である。
【図９】本発明の第１の実施形態において、クライアントが複数存在する時における処理の概要を示す図である。
【図１０】本発明の第１の実施形態において、クライアントが複数存在する時におけるＯＵＴイベント発生時の映像配信サーバによる処理手順の一例を示すフローチャートである。
【図１１】本発明の第１の実施形態における映像配信サーバと携帯端末との機能構成例を示すブロック図である。
【符号の説明】
【００７７】
１０  通信部
１１  バッファ
１２  記録制御部
１３  ファイル生成部
１４  時間／サイズ算出部
２１  通信部
２２  入力部
２３  ＩＮ／ＯＵＴ設定部
１０１  カメラ
１０２  映像配信サーバ
１０３  ネットワーク
１０４  携帯端末
【図１】
2008187505.tif 000003
【図２】
2008187505.tif 000004
【図３】
2008187505.tif 000005
【図４】
2008187505.tif 000006
【図５】
2008187505.tif 000007
【図６】
2008187505.tif 000008
【図７】
2008187505.tif 000009
【図８】
2008187505.tif 000010
【図９】
2008187505.tif 000011
【図１０】
2008187505.tif 000012
【図１１】
2008187505.tif 000013