JP2021082882A - 情報処理プログラム、情報処理方法および情報処理装置 - Google Patents

Abstract

【課題】複数の映像データ間で再生時刻情報を整合させる。【解決手段】情報処理装置１の処理部２は、映像データｄ１，ｄ２を受信する。映像データｄ１，ｄ２は、それぞれ再生時刻情報を含む。処理部２は、受信した映像データｄ１，ｄ２の中から再生時刻情報の基準となる第１の映像データを特定する。そして、処理部２は、第１の映像データに含まれる再生時刻情報を基準として、映像データｄ１，ｄ２のうち第１の映像データ以外の第２の映像データに含まれる再生時刻情報を変更する。【選択図】図１

Description

本発明は、情報処理プログラム、情報処理方法および情報処理装置に関する。

ＨＬＳ（HTTP Live Streaming）は、ＨＴＴＰ（Hypertext Transfer Protocol）ベースのストリーミング・プロトコルであり、動画配信を低コストで実現可能な技術として普及しつつある。ＨＬＳでは、サーバにおいて、動画データが１０秒といった所定時間単位で分割された動画ファイルとして用意されるとともに、それらの動画ファイルの再生順を示すプレイリストが用意される。再生機側は、サーバからプレイリストを取得し、プレイリストに基づいて動画ファイルをサーバから順にダウンロードすることで、動画像を再生する。

この仕組みによれば、例えば、同じ映像ソースを異なる品質（例えば異なるビットレート）で符号化した動画ファイルをサーバ側に用意しておくことで、再生機側は、通信状況に合わせて適切な品質の動画ファイルを取得して再生することができる。また、再生機側は、通信状況の変動に応じて、動画ファイルの中からその時点で適切な品質の動画ファイルを取得することで、品質の異なる動画ストリームを適応的に切り替えて受信しながら動画像を再生することもできる。

なお、映像コンテンツの再生に関して、次のような提案がある。例えば、基準時刻送信サーバを利用せずに、複数の受信端末での映像の同期再生を実現することが可能な同期再生方法が提案されている。また、映像コンテンツのデータ形式に関わらず、複数の映像処理装置間で当該映像コンテンツに基づく映像信号の出力を同期させることが可能な映像処理システムが提案されている。

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

ところで、複数の撮像装置それぞれによって撮影された動画像は、それぞれ異なるエンコーダによって符号化されることが多い。また、同じ映像ソースを異なる品質で符号化する場合でも、品質ごとに異なるエンコーダによって符号化されることもある。このように異なるエンコーダによって符号化された動画ストリームの間では、同じ時刻に符号化されたフレームに付加される再生時刻情報（タイムスタンプ）がすべて同じ値になるとは限らない。

上記のＨＬＳでは、品質の異なる動画ストリームの間では、同じ時刻に符号化されたフレームには同じ値の再生時刻情報が付加されていることを前提として、再生機側で動画ストリームを再生中に切り替えることが可能となっている。これは、動画ストリームの切り替えの際に、切り替え直前に受信した画像ファイルの再生時刻情報と、切り替え直後に受信した画像ファイルの再生時刻情報とが連続していないと、動画像を途切れることなく正しく再生できないからである。

しかし、上記のように異なるエンコーダによって符号化された動画ストリームについては、このような前提が成り立たない場合がある。このため、再生機側で動画ストリームを再生中に切り替えた場合に、動画像の再生を正しく継続できない可能性がある。

１つの側面では、本発明は、複数の映像データ間で再生時刻情報を整合させることが可能な情報処理プログラム、情報処理方法および情報処理装置を提供することを目的とする。

１つの案では、コンピュータに、再生時刻情報をそれぞれ含む複数の映像データを受信し、複数の映像データの中から再生時刻情報の基準となる第１の映像データを特定し、第１の映像データに含まれる再生時刻情報を基準として、複数の映像データのうち第１の映像データ以外の第２の映像データに含まれる再生時刻情報を変更する、処理を実行させる情報処理プログラムが提供される。

また、１つの案では、上記の情報処理プログラムにしたがった処理と同様の処理をコンピュータが実行する情報処理方法が提供される。
さらに、１つの案では、上記の情報処理プログラムにしたがった処理と同様の処理を実行する情報処理装置が提供される。

１つの側面では、複数の映像データ間で再生時刻情報を整合させることができる。

第１の実施の形態に係る情報処理装置の構成例および処理例を示す図である。 第２の実施の形態に係る動画配信システムの構成例を示す図である。 Ｗｅｂサーバのハードウェア構成例を示す図である。 ＨＬＳを用いた動画配信処理の比較例を示す第１の図である。 ＨＬＳを用いた動画配信処理の比較例を示す第２の図である。 ＨＬＳを用いた動画配信処理の比較例を示す第３の図である。 第２の実施の形態での動画配信処理の例を示す第１の図である。 第２の実施の形態での動画配信処理の例を示す第２の図である。 第２の実施の形態での動画配信処理の例を示す第３の図である。 Ｗｅｂサーバおよび再生端末が備える処理機能の構成例を示す図である。 グループ管理情報の構成例を示す図である。 プレイリストに記述される情報の例を示す図である。 動画ファイル作成処理の例を示すフローチャートである。 動画データの受信が断絶した場合における動画ファイル作成処理の例を示すフローチャート（その１）である。 動画データの受信が断絶した場合における動画ファイル作成処理の例を示すフローチャート（その２）である。 動画配信処理の例を示すフローチャートである。 再生端末の処理例を示すフローチャートである。

以下、本発明の実施の形態について図面を参照して説明する。
〔第１の実施の形態〕
図１は、第１の実施の形態に係る情報処理装置の構成例および処理例を示す図である。図１に示す情報処理装置１は、処理部２を有する。処理部２は、例えば、情報処理装置１が備える図示しないプロセッサとして実現される。

情報処理装置１は、複数の映像データを受信する。情報処理装置１は、例えば、受信した複数の映像データを他の再生装置に配信する処理を実行する。これらの映像データは、再生時刻情報をそれぞれ含んでいる。また、これらの映像データは、例えば、互いに異なる撮像装置によって撮影された動画像のデータ、あるいは互いに異なるエンコーダによって符号化された動画データなど、互いに再生時刻情報の整合がとれていない可能性のある映像データである。

処理部２は、このような複数の映像データを受信する。すると、処理部２は、受信した複数の映像データの中から、再生時刻情報の基準となる基準映像データを特定する。そして、処理部２は、基準映像データに含まれる再生時刻情報を基準として、これらの複数の映像データのうち基準映像データ以外の他の映像データに含まれる再生時刻情報を変更する。これにより、複数の映像データ間で再生時刻情報を整合させることができる。

以下、図１を用いて処理部２の処理を具体的に説明する。
図１の例では、上記の複数の映像データとして映像データｄ１，ｄ２が情報処理装置１に入力される。映像データｄ１は、先頭側から部分映像データｄ１−１，ｄ１−２，ｄ１−３，・・・を含んでいるとする。映像データｄ２は、先頭側から部分映像データｄ２−１，ｄ２−２，ｄ２−３，・・・を含んでいるとする。これらの部分映像データｄ１−１，ｄ１−２，ｄ１−３，・・・および部分映像データｄ２−１，ｄ２−２，ｄ２−３，・・・は、例えば、それぞれ一定の再生時間分の動画像の情報を含んでいる。

また、部分映像データｄ１−１，ｄ１−２，ｄ１−３，・・・および部分映像データｄ２−１，ｄ２−２，ｄ２−３，・・・は、それぞれ再生時刻情報を含んでいる。以下、再生時刻情報を「タイムスタンプ」（図１中では「ｔｓ」）と記載する。図１の例では、部分映像データｄ１−１，ｄ１−２，ｄ１−３は、それぞれタイムスタンプ「１０」，「２０」，「３０」を含んでおり、部分映像データｄ２−１，ｄ２−２，ｄ２−３は、それぞれタイムスタンプ「２０」，「３０」，「４０」を含んでいる。

部分映像データｄ１−１と部分映像データｄ２−１は、同じ時刻ｔ１に情報処理装置１に受信されたとする。しかし、部分映像データｄ１−１と部分映像データｄ２−１との間ではタイムスタンプの値が異なっている。また、部分映像データｄ１−２と部分映像データｄ２−２は、同じ時刻ｔ２に情報処理装置１に受信されたとする。しかし、部分映像データｄ１−２と部分映像データｄ２−２との間でもタイムスタンプの値が異なっている。さらに、部分映像データｄ１−３と部分映像データｄ２−３は、同じ時刻ｔ３に情報処理装置１に受信されたとする。しかし、部分映像データｄ１−３と部分映像データｄ２−３との間でもタイムスタンプが異なっている。このように、映像データｄ１と映像データｄ２との間では、再生時刻情報の整合がとれていない。

このような場合、処理部２は、受信した映像データｄ１，ｄ２の中から、タイムスタンプの基準となる基準映像データを特定する。図１の例では、映像データｄ１が基準映像データとして特定されたとする。処理部２は、基準映像データである映像データｄ１に含まれるタイムスタンプを基準として、映像データｄ１，ｄ２のうち基準映像データ以外の映像データｄ２に含まれるタイムスタンプを変更する。

図１の例では、例えば部分映像データｄ１−１と部分映像データｄ２−１の各タイムスタンプを比較することで、映像データｄ１と映像データｄ２との間ではタイムスタンプに「１０」の差分があると判定される。この場合、処理部２は、映像データｄ２における部分映像データｄ２−１〜ｄ２−３のタイムスタンプから「１０」を減算することで、元のタイムスタンプを変更する。その結果、部分映像データｄ２−１，ｄ２−２，ｄ２−３に含まれるタイムスタンプは、それぞれ「１０」，「２０」，「３０」に変更される。

このような処理により、部分映像データｄ１−１と部分映像データｄ２−１との間ではタイムスタンプの値が同じになる。同様に、部分映像データｄ１−２と部分映像データｄ２−２との間でもタイムスタンプの値が同じになり、部分映像データｄ１−３と部分映像データｄ２−３との間でもタイムスタンプの値が同じになる。このように、映像データｄ１と映像データｄ２との間でタイムスタンプを整合させることができる。

このようなタイムスタンプの整合は、例えば、映像データｄ１，ｄ２の一方が配信されて再生装置で再生されている状況において、再生装置が映像データを途中で切り替えながら再生することを可能にする。例えば、再生装置が情報処理装置１から部分映像データｄ１−１，ｄ１−２の配信を受け、次に映像データを切り替えて部分映像データｄ２−３の配信を受けるとする。この場合、処理部２の上記処理によってタイムスタンプが変更された部分映像データｄ２−３が配信されることで、再生装置はタイムスタンプの値が連続した部分映像データを順番に受信することができる。これにより、再生装置は、映像データｄ１，ｄ２を切り替え前後で途切れなく正常に再生できるようになる。

〔第２の実施の形態〕
次に、ストリーミング・プロトコルとしてＨＬＳを用いた動画配信システムについて説明する。

図２は、第２の実施の形態に係る動画配信システムの構成例を示す図である。図２に示す動画配信システムは、Ｗｅｂサーバ１００、カメラ２１０，２２０および再生端末３１０，３２０，３３０を含む。カメラ２１０，２２０とＷｅｂサーバ１００との間は、例えば、図示しないネットワークを介して接続されている。また、再生端末３１０，３２０，３３０とＷｅｂサーバ１００との間も、例えば、図示しないネットワークを介して接続されている。なお、Ｗｅｂサーバ１００は、図１に示した情報処理装置１の一例である。

Ｗｅｂサーバ１００は、カメラ２１０，２２０による撮影によって作成された動画ストリームを配信する配信サーバである。Ｗｅｂサーバ１００は、ＨＬＳのプロトコルにしたがって、各動画ストリームを所定の再生時間単位の動画ファイルに分割して保存し、これらの動画ファイルを再生端末に送信することで動画ストリームを配信する。また、Ｗｅｂサーバ１００は、再生端末からの要求に応じて、配信する動画ストリームを途中から他の動画ストリームに切り替えることが可能になっている。

カメラ２１０，２２０は、それぞれ動画像を撮影し、動画ストリームとしてＷｅｂサーバ１００に送信する。カメラ２１０，２２０は、例えば監視用のカメラである。この場合、カメラ２１０，２２０は、それぞれ異なる位置（視点）から監視対象の領域を撮影する。

再生端末３１０，３２０，３３０は、Ｗｅｂサーバ１００から配信される動画ストリームを受信して動画像を再生表示する端末装置である。再生端末３１０，３２０，３３０は、上記の動画ファイルを再生順にＷｅｂサーバ１００からダウンロードすることで、動画像を再生し、表示装置に表示させる。

また、再生端末３１０，３２０，３３０は、Ｗｅｂサーバ１００から配信される動画ストリームを途中から他の動画ストリームに切り替えることで、動画像を切り替えて再生できるようになっている。例えば、上記のようにカメラ２１０，２２０が監視用のカメラである場合、ユーザは再生端末３１０，３２０，３３０のそれぞれを用いて、異なる位置（視点）からの動画像を切り替えながら監視対象の領域の様子を確認することができる。

なお、Ｗｅｂサーバ１００に接続されるカメラの台数は、図２のように２台に限定されるものではなく、３台以上のカメラがＷｅｂサーバ１００に接続されてもよい。また、Ｗｅｂサーバ１００に接続される再生端末の台数は、図２のように３台に限定されるものではなく、１台以上の任意の数の再生端末がＷｅｂサーバ１００に接続されてもよい。

図３は、Ｗｅｂサーバのハードウェア構成例を示す図である。Ｗｅｂサーバ１００は、例えば、図３に示すようなコンピュータとして実現される。
図３に示すＷｅｂサーバ１００は、プロセッサ１０１、ＲＡＭ（Random Access Memory）１０２、ＨＤＤ（Hard Disk Drive）１０３、グラフィックインタフェース（Ｉ／Ｆ）１０４、入力インタフェース（Ｉ／Ｆ）１０５、読み取り装置１０６および通信インタフェース（Ｉ／Ｆ）１０７を有する。

プロセッサ１０１は、Ｗｅｂサーバ１００全体を統括的に制御する。プロセッサ１０１は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）またはＰＬＤ（Programmable Logic Device）である。また、プロセッサ１０１は、ＣＰＵ、ＭＰＵ、ＤＳＰ、ＡＳＩＣ、ＰＬＤのうちの２以上の要素の組み合わせであってもよい。

ＲＡＭ１０２は、Ｗｅｂサーバ１００の主記憶装置として使用される。ＲＡＭ１０２には、プロセッサ１０１に実行させるＯＳ（Operating System）プログラムやアプリケーションプログラムの少なくとも一部が一時的に格納される。また、ＲＡＭ１０２には、プロセッサ１０１による処理に必要な各種データが格納される。

ＨＤＤ１０３は、Ｗｅｂサーバ１００の補助記憶装置として使用される。ＨＤＤ１０３には、ＯＳプログラム、アプリケーションプログラム、および各種データが格納される。なお、補助記憶装置としては、ＳＳＤ（Solid State Drive）などの他の種類の不揮発性記憶装置を使用することもできる。

グラフィックインタフェース１０４には、表示装置１０４ａが接続されている。グラフィックインタフェース１０４は、プロセッサ１０１からの命令にしたがって、画像を表示装置１０４ａに表示させる。表示装置１０４ａとしては、液晶ディスプレイや有機ＥＬ（ElectroLuminescence）ディスプレイなどを適用可能である。

入力インタフェース１０５には、入力装置１０５ａが接続されている。入力インタフェース１０５は、入力装置１０５ａから出力される信号をプロセッサ１０１に送信する。入力装置１０５ａとしては、キーボードやポインティングデバイスなどを適用可能である。ポインティングデバイスとしては、マウス、タッチパネル、タブレット、タッチパッド、トラックボールなどを適用可能である。

読み取り装置１０６には、可搬型記録媒体１０６ａが脱着される。読み取り装置１０６は、可搬型記録媒体１０６ａに記録されたデータを読み取ってプロセッサ１０１に送信する。可搬型記録媒体１０６ａとしては、光ディスク、光磁気ディスク、半導体メモリなどを適用可能である。

通信インタフェース１０７は、ネットワーク１０７ａを介して他の装置との間でデータの送受信を行う。
以上のようなハードウェア構成によって、Ｗｅｂサーバ１００の処理機能を実現することができる。なお、再生端末３１０，３２０，３３０についても、図３に示すようなコンピュータとして実現可能である。

次に、図４〜図６を用いて、ＨＬＳを用いた動画配信処理の比較例について説明する。図４〜図６では、ＡＢＲ（Adaptive Bitrate）方式の動画配信が行われる場合について例示する。

図４は、ＨＬＳを用いた動画配信処理の比較例を示す第１の図である。
ＨＬＳでは、動画ストリームは所定再生時間（以下、例として１０秒とする）を単位として動画ファイルに分割される。図４の例では、カメラ４０１による撮影によって作成された動画ストリームが、トランスコーダ４０２に入力される。トランスコーダ４０２は、入力された動画ストリームを互いに異なる品質の動画ストリームにトランスコードし、配信サーバであるＷｅｂサーバ４０３に出力する。図４の例では、高品質、低品質の２つの動画ストリームが、トランスコーダ４０２からＷｅｂサーバ４０３に出力されている。これら２つの動画ストリームは、例えば圧縮率や解像度を変えることで、異なるビットレートの動画ストリームとして作成される。

Ｗｅｂサーバ４０３では、高品質、低品質の各動画ストリームが１０秒分のストリームに分割されることで動画ファイルが作成される。すなわち、作成される動画ファイルは、１０秒分の動画像を表示するためのストリームデータである。図４の例では、高品質の動画ストリームを基に動画ファイル４１１−１，４１１−２，４１１−３，・・・が作成され、Ｗｅｂサーバ４０３に保存される。また、低品質の動画ストリームを基に動画ファイル４１２−１，４１２−２，４１２−３，・・・が作成され、Ｗｅｂサーバ４０３に保存される。

また、Ｗｅｂサーバ４０３では、高品質の動画ストリームに対応するプレイリスト４２１と、低品質の動画ストリームに対応するプレイリスト４２２とが作成され、保存される。プレイリスト４２１には、動画ファイル４１１−１，４１１−２，４１１−３，・・・のファイル名や格納場所の情報が、再生順に記述される。プレイリスト４２２には、動画ファイル４１２−１，４１２−２，４１２−３，・・・のファイル名や格納場所の情報が、再生順に記述される。

さらに、Ｗｅｂサーバ４０３では、ＡＢＲプレイリスト４２０が作成され、保存される。ＡＢＲプレイリスト４２０には、プレイリスト４２１，４２２のファイル名や格納場所の情報が記述される。

図５は、ＨＬＳを用いた動画配信処理の比較例を示す第２の図である。この図５を用いて、図４に示した動画ストリームの配信手順について説明する。
再生端末は、最初にＡＢＲプレイリスト４２０をＷｅｂサーバ４０３からダウンロードし、ＡＢＲプレイリスト４２０に基づいて、所望品質の動画ストリームに対応するプレイリストの送信をＷｅｂサーバ４０３に要求する。そして、再生端末は、Ｗｅｂサーバ４０３から送信されたプレイリストに基づいて、所望品質の動画ストリームに対応する動画ファイルの送信を、順番にＷｅｂサーバ４０３に要求することができる。

図５の例では、再生端末４０４は、Ｗｅｂサーバ４０３との間の通信品質が高いため、高品質の動画ストリームを再生しようとする。この場合、再生端末４０４は、プレイリスト４２１をダウンロードし、プレイリスト４２１に基づいて動画ファイル４１１−１，４１１−２，４１１−３，・・・の送信を、順番にＷｅｂサーバ４０３に要求する。再生端末４０４は、Ｗｅｂサーバ４０３から動画ファイル４１１−１，４１１−２，４１１−３，・・・を順番に受信してデコードすることで、高品質の動画ストリームに基づく動画像を再生表示できる。

また、図５の例では、再生端末４０５は、Ｗｅｂサーバ４０３との間の通信品質が低いため、低品質の動画ストリームを再生しようとする。この場合、再生端末４０５は、プレイリスト４２２をダウンロードし、プレイリスト４２２に基づいて動画ファイル４１２−１，４１２−２，４１２−３，・・・の送信を、順番にＷｅｂサーバ４０３に要求する。再生端末４０５は、Ｗｅｂサーバ４０３から動画ファイル４１２−１，４１２−２，４１２−３，・・・を順番に受信してデコードすることで、低品質の動画ストリームに基づく動画像を再生表示できる。

さらに、再生端末４０４，４０５は、Ｗｅｂサーバ４０３との間の通信品質の変動に応じて、一方の動画ストリームの再生中に、再生する動画ストリームを他方の動画ストリームに切り替えることができる。ここで、図６を用いて、再生端末４０４が再生する動画ストリームを切り替える場合の例について説明する。

図６は、ＨＬＳを用いた動画配信処理の比較例を示す第３の図である。図６では、再生端末４０４は、高品質の動画ストリームに対応する動画ファイル４１１−１〜４１１−３を順番に受信し、これらをデコードして動画像を再生表示する。また、動画ファイル４１１−３を受信した時点で、Ｗｅｂサーバ４０３と再生端末４０４との間の通信品質が低下したとする。この場合、再生端末４０４は、再生対象の動画ストリームを高品質から低品質に切り替えることができる。

再生端末４０４はこの切り替えのために、まず、ＡＢＲプレイリスト４２０に基づいて、低品質の動画ストリームに対応するプレイリスト４２２の送信をＷｅｂサーバ４０３に要求する。再生端末４０４は、プレイリスト４２２を受信すると、プレイリスト４２２に基づき、低品質の動画ストリームに対応する動画ファイルの中から、動画ファイル４１１−３の次に取得すべき動画ファイルを特定する。

図６の例では、次に取得すべき動画ファイルとして動画ファイル４１２−４が特定され、再生端末４０４は、動画ファイル４１２−４の送信をＷｅｂサーバ４０３に要求する。再生端末４０４は、動画ファイル４１２−４を受信し、動画ファイル４１１−３に続いてデコードすることで、低品質の動画ストリームに基づく動画像を連続して再生表示することができる。この後、再生端末４０４は、次の動画ファイル４１２−５をＷｅｂサーバ４０３から取得して、低品質の動画ストリームに基づく動画像の再生表示を継続する。

このように、ＨＬＳを用いた動画配信では、再生端末は、配信サーバとの間の通信品質の変動に応じて最適な品質の動画ストリームを受信し、動画像を再生表示することができる。ＨＬＳでは、このような処理を、所定の再生時間単位で細切れにされた動画ファイルをプレイリストにしたがって順次選択する、という簡単な仕組みで実現できる。

ここで、動画ファイルに付加されるタイムスタンプ（再生時刻情報）について説明する。以下の説明において、図中に示される各動画ファイルのタイムスタンプ（ＴＳ）は、動画ファイルによって再生されるフレームのうち、先頭フレームに付加されるタイムスタンプを示す。また、以下の説明におけるタイムスタンプは、例えば、ＭＰＥＧ−２ ＴＳ（Moving Picture Experts Group-2 Transport Stream）におけるＰＴＳ（Presentation Time Stamp）である。

図４〜図６の比較例では、トランスコーダ４０２により、高品質、低品質それぞれの動画ストリームのトランスコードが同期して実行される。これにより、各動画ストリームにおいては、同じタイミングでトランスコードされたフレームに対応する動画データには、同じ値のタイムスタンプが付加される。

例えば、動画ファイル４１１−１，４１２−１は同じタイミングでトランスコードされるので、これらには同じタイムスタンプが付加される。図６の例では、これらにはタイムスタンプ「１００」が付加されている。また、動画ファイル４１１−２，４１２−２は同じタイミングでトランスコードされるので、これらには同じタイムスタンプが付加される。図６の例では、これらにはタイムスタンプ「２００」が付加されている。さらに、動画ファイル４１１−３，４１２−３は同じタイミングでトランスコードされるので、これらには同じタイムスタンプが付加される。図６の例では、これらにはタイムスタンプ「３００」が付加されている。

このように各動画ストリームの画像ファイル間でタイムスタンプの整合が図られることで、再生端末４０４は、再生する動画ストリームを切り替えたときに、動画像を途切れることなく連続的に再生表示できるようになる。例えば図６では、再生端末４０４は、高品質の動画ストリームに対応する動画ファイル４１１−１〜４１１−３を受信した後、再生する動画ストリームを切り替える。このとき再生端末４０４は、前述のようにＡＢＲプレイリスト４２０およびプレイリスト４２２に基づいて低品質の動画ストリームに対応する動画ファイル４１２−４，４１２−５を受信する。

上記のように動画ファイル４１１−１〜４１１−３にそれぞれタイムスタンプ「１００」，「２００」，「３００」が付加されている場合、切り替え後の動画ファイル４１２−４，４１２−５にはそれぞれタイムスタンプ「４００」，「５００」が付加されている。このように、切り替え前後でタイムスタンプの連続性が維持されている。このため、再生端末４０４は、動画ファイル４１１−１，４１１−２，４１１−３，４１２−４，４１２−５を順番にデコードすることで、切り替え前後で動画像を途切れることなく連続して再生表示できる。

次に、図７〜図９を用いて、第２の実施の形態での動画配信処理について説明する。
図７は、第２の実施の形態での動画配信処理の例を示す第１の図である。図７に示すように本実施の形態では、カメラ２１０は、撮像部２１１とエンコーダ２１２を備える。また、カメラ２２０は、撮像部２２１とエンコーダ２２２を備える。

撮像部２１１は、撮像素子によって動画像を撮影する。エンコーダ２１２は、撮像部２１１から入力される動画像のデータをエンコードし、動画ストリームとしてＷｅｂサーバ１００に送信する。一方、撮像部２２１は、撮像素子によって動画像を撮影する。エンコーダ２２２は、撮像部２２１から入力される動画像のデータをエンコードし、動画ストリームとしてＷｅｂサーバ１００に送信する。なお、各動画ストリームの品質は、同じであってもよいし、違ってもよい。また、エンコーダ２１２，２２２は、ハードウェアによって実現されてもよいし、ソフトウェアによって実現されてもよい。

Ｗｅｂサーバ１００は、カメラ２１０からの動画ストリームを再生時間１０秒分ごとに分割することで、動画ファイルＦ１−１，Ｆ１−２，Ｆ１−３，・・・を作成して保存する。また、Ｗｅｂサーバ１００は、カメラ２２０からの動画ストリームを再生時間１０秒分ごとに分割することで、動画ファイルＦ２−１，Ｆ２−２，Ｆ２−３，・・・を作成して保存する。

さらに、Ｗｅｂサーバ１００は、カメラ２１０に対応するプレイリストＬ１と、カメラ２２０に対応するプレイリストＬ２と、ＡＢＲプレイリストＬ０を作成して保存する。プレイリストＬ１には、カメラ２１０からの動画ストリームに対応する動画ファイルＦ１−１，Ｆ１−２，Ｆ１−３，・・・のファイル名や格納場所を示す情報が、再生順に記述される。プレイリストＬ２には、カメラ２２０からの動画ストリームに対応する動画ファイルＦ２−１，Ｆ２−２，Ｆ２−３，・・・のファイル名や格納場所を示す情報が、再生順に記述される。ＡＢＲプレイリストＬ０には、プレイリストＬ１，Ｌ２のファイル名や格納場所を示す情報が記述される。

再生端末は、このようなＡＢＲプレイリストＬ０およびプレイリストＬ１，Ｌ２を参照することにより、上記の比較例と同様に、所望の動画ストリームに対応する動画ファイルを順番に取得して動画像を再生表示することができる。また、再生端末は、上記の比較例と同様の手順により、動画像の再生処理中に、異なる動画ストリームに対応する動画ファイルを切り替えて取得することができる。これにより、再生端末のユーザは、異なるカメラ２１０，２２０によって撮影された動画像を、リアルタイムに切り替えながら閲覧できる。ただし、切り替えの前後で動画像を正しく再生表示できるようにするためには、後述するようなＷｅｂサーバ１００側でのタイムスタンプの制御が行われる。

図７に示すように、本実施の形態では、各動画ストリームは個別のエンコーダ２１２，２２２によって作成される。エンコーダ２１２とエンコーダ２２２との間では、エンコード処理が同期されない。このため、次の図８の例のように、これらの動画ストリームの間では、同じ時刻にエンコードされたフレームの動画データに同じ値のタイムスタンプが付加されるとは限らない。

図８は、第２の実施の形態での動画配信処理の例を示す第２の図である。図８の左上に示す動画データＤ１−１，Ｄ１−２，Ｄ１−３，・・・は、カメラ２１０から送信される動画ストリームに含まれる動画データである。また、図８の左下に示す動画データＤ２−１，Ｄ２−２，Ｄ２−３，・・・は、カメラ２２０から送信される動画ストリームに含まれる動画データである。これらの動画データは、Ｗｅｂサーバ１００において１つの動画ファイルに含められるデータであるとする。

動画データＤ１−１，Ｄ２−１は、同じ時刻Ｔ１にエンコードされたものであるとする。同様に、動画データＤ１−２，Ｄ２−２は、同じ時刻Ｔ２にエンコードされたものであり、動画データＤ１−３，Ｄ２−３は、同じ時刻Ｔ３にエンコードされたものであるとする。

しかしながら、これらの動画ストリームの間では、同じ時刻にエンコードされた動画像データには異なる値のタイムスタンプが付加されている。例えば、動画データＤ１−１，Ｄ２−１には、それぞれタイムスタンプ「１００」，「２００」が付加されている。動画データＤ１−２，Ｄ２−２には、それぞれタイムスタンプ「２００」，「３００」が付加されている。動画データＤ１−３，Ｄ２−３には、それぞれタイムスタンプ「３００」，「４００」が付加されている。

このような場合に、Ｗｅｂサーバ１００が、同じ時刻に受信した各動画ストリームの動画データを基に、付加されているタイムスタンプをそのまま用いて動画ファイルを作成したとする。この場合、再生端末は、動画ストリームを切り替えたときに動画像を連続して再生表示できなくなる。例えば、再生端末が、動画データＤ１−２に基づく動画ファイルを受信した後に、動画データＤ２−３に基づく動画ファイルを受信したとすると、タイムスタンプは「２００」の次に「４００」となる。このようにタイムスタンプの連続性がなくなることから、切り替え直後において動画像の再生表示が一時的に停止してしまう。また、以上の例では切り替え後にタイムスタンプが過度に増加してしまうが、逆に、切り替え後にタイムスタンプが減少してしまう場合には、再生表示を継続できない場合もある。

そこで、本実施の形態では、Ｗｅｂサーバ１００は次のような手順で動画ファイルを作成する。
Ｗｅｂサーバ１００は、入力される動画ストリームの中から、メイン動画ストリームを選択する。メイン動画ストリームとしては、例えば、最も先に入力された動画ストリームが選択される。Ｗｅｂサーバ１００は、メイン動画ストリームのタイムスタンプを基準値として用いて、それ以外の動画ストリーム（サブ動画ストリーム）のタイムスタンプを書き換える。

図８の例では、カメラ２１０からの動画ストリームがメイン動画ストリームＳＴ１として選択され、カメラ２２０からの動画ストリームがサブ動画ストリームＳＴ２として選択されている。Ｗｅｂサーバ１００は、メイン動画ストリームＳＴ１およびサブ動画ストリームＳＴ２の動画データのうち、同じ時刻に受信した動画データのタイムスタンプの差分を算出する。図８では例えば、動画データＤ１−１のタイムスタンプ「１００」から動画データＤ２−１のタイムスタンプ「２００」を減算することで、差分時間「−１００」が算出される。

Ｗｅｂサーバ１００は、メイン動画ストリームＳＴ１については、タイムスタンプをそのまま用いて動画ファイルを作成する。図８の例では、動画データＤ１−１〜Ｄ１−３からそれぞれ動画ファイルＦ１−１〜Ｆ１−３が作成される。動画ファイルＦ１−１，Ｆ１−２，Ｆ１−３には、それぞれタイムスタンプ「１００」，「２００」，「３００」が付加される。

一方、Ｗｅｂサーバ１００は、サブ動画ストリームＳＴ２については、各動画データに付加されているタイムスタンプに、上記のように算出された差分時間を加算し、加算後のタイムスタンプを動画ファイルに付加する。図８の例では、差分時間は「−１００」であるので、サブ動画ストリームＳＴ２の各動画データに付加されたタイムスタンプに対して「−１００」が加算される（すなわち、タイムスタンプから「１００」が減算される）。したがって、動画データＤ２−１〜Ｄ２−３からそれぞれ動画ファイルＦ２−１〜Ｆ２−３が作成されたとき、動画ファイルＦ２−１，Ｆ２−２，Ｆ２−３にはそれぞれタイムスタンプ「１００」，「２００」，「３００」が付加される。

このような処理により、Ｗｅｂサーバ１００が同じ時刻に受信した各動画ストリームの動画データを基に作成された動画ファイルには、同じ値のタイムスタンプが付加される。これにより、動画ストリーム間におけるタイムスタンプの整合をとることができる。

図９は、第２の実施の形態での動画配信処理の例を示す第３の図である。この図９では、図８のようにして作成された動画ファイルＦ１−１，Ｆ１−２，Ｆ１−３，・・・および動画ファイルＦ２−１，Ｆ２−２，Ｆ２−３，・・・を用いた動画配信時の処理例を示す。ここでは例として、再生端末３１０が動画像を再生表示するものとする。

再生端末３１０は、最初にＡＢＲプレイリストＬ０をＷｅｂサーバ１００からダウンロードし、ＡＢＲプレイリストＬ０に基づいて、所望のカメラからの動画ストリームに対応するプレイリストの送信をＷｅｂサーバ１００に要求する。図９ではカメラ２１０からの動画ストリームを再生しようとするものとすると、再生端末３１０は、カメラ２１０に対応するプレイリストＬ１をＷｅｂサーバ１００からダウンロードし、プレイリストＬ１に基づいて、カメラ２１０に対応する動画ファイルの送信を順番にＷｅｂサーバ１００に要求する。

図９の例では、再生端末３１０は、Ｗｅｂサーバ１００から動画ファイルＦ１−１〜Ｆ１−３を順番に受信し、これらに基づいて動画像の再生表示を行う。また、動画ファイルＦ１−３を受信したタイミングで、カメラ切り替え（カメラ２１０からカメラ２２０への切り替え）の操作がユーザにより行われたとする。この場合、再生端末３１０は、ＡＢＲプレイリストＬ０に基づいて、カメラ２２０に対応するプレイリストＬ２をＷｅｂサーバ１００からダウンロードする。再生端末３１０は、受信したプレイリストＬ２に基づき、カメラ２２０に対応する動画ファイルの中から、動画ファイルＦ１−３の次に取得すべき動画ファイルを特定する。

図９の例では、次に取得すべき動画ファイルとして動画ファイルＦ２−４が特定され、再生端末３１０は、動画ファイルＦ２−４の送信をＷｅｂサーバ１００に要求する。再生端末３１０は、動画ファイルＦ２−４を受信し、動画ファイルＦ２−４を動画ファイルＦ１−３に続いてデコードして、動画ファイルＦ２−４に基づく動画像の再生表示を行う。動画ファイルＦ１−３にはタイムスタンプ「３００」が付加され、動画ファイルＦ２−４にはタイムスタンプ「４００」が付加されている。このようにタイムスタンプの連続性が維持されているので、再生端末３１０は、カメラの切り替え前後で動画像を途切れることなく連続して再生表示することができる。

以下、第２の実施の形態に係る動画配信システムについて、さらに詳しく説明する。
図１０は、Ｗｅｂサーバおよび再生端末が備える処理機能の構成例を示す図である。
まず、Ｗｅｂサーバ１００は、受信バッファ１１１、管理情報記憶部１１２、画像バッファ１１３、ファイル記憶部１１４、ファイル作成部１２１および配信処理部１２２を備える。受信バッファ１１１、管理情報記憶部１１２、画像バッファ１１３およびファイル記憶部１１４は、例えばＲＡＭ１０２など、Ｗｅｂサーバ１００が備える記憶装置の記憶領域によって実現される。ファイル作成部１２１および配信処理部１２２の処理は、例えば、Ｗｅｂサーバ１００が備えるプロセッサ１０１が所定のプログラムを実行することで実現される。

受信バッファ１１１には、カメラ２１０，２２０から受信した動画ストリームのデータが一時的に格納される。ファイル作成部１２１は、受信バッファ１１１に格納されたデータに基づいて配信用の動画ファイルを作成し、ファイル記憶部１１４に格納する。また、ファイル作成部１２１は、プレイリストを作成してファイル記憶部１１４に格納する。

管理情報記憶部１１２は、ファイル作成部１２１の処理で参照される管理情報を記憶する。画像バッファ１１３には、ファイル作成部１２１の処理中に利用されるバッファ領域であり、例えばタイムスタンプが書き換えられた動画データが一時的に格納される。

配信処理部１２２は、再生端末３１０，３２０からの要求に応じて、ファイル記憶部１１４に格納されたプレイリストや動画ファイルを送信する。これにより、配信処理部１２２は、動画ストリームを配信する配信サーバとしての機能を果たす。

次に、再生端末３１０は、画像取得部３１１、デコーダ３１２および表示処理部３１３を備える。画像取得部３１１、デコーダ３１２および表示処理部３１３の処理は、例えば、再生端末３１０が備える図示しないプロセッサが所定のプログラムを実行することで実現される。

画像取得部３１１は、Ｗｅｂサーバ１００の配信処理部１２２からプレイリストや動画ファイルを取得する。デコーダ３１２は、画像取得部３１１が取得した動画ファイルをデコードする。表示処理部３１３は、デコーダ３１２によってデコードされた動画データに基づいて動画像を生成し、図示しない表示装置に表示させる。

なお、図１０では再生端末３１０の構成を例示したが、再生端末３２０も再生端末３１０と同様の処理機能を備えている。
図１１は、グループ管理情報の構成例を示す図である。図１１に示すグループ管理情報１３０は、Ｗｅｂサーバ１００の管理情報記憶部１１２に記憶される管理情報の一例である。

グループ管理情報１３０は、動画ストリームのグループごとのグループ管理テーブル１３１を含む。グループとは、再生端末が切り替えて受信可能な動画ストリームの組み合わせを示し、例えばＷｅｂサーバ１００の管理者によって任意に設定される。なお、前述のＡＢＲプレイリストは、グループごとに作成されてファイル記憶部１１４に記憶される。そして、各グループに含まれる動画ストリームごとに、動画ファイルの格納場所および再生順を示すプレイリストが作成されて、ファイル記憶部１１４に記憶される。

グループ管理テーブル１３１は、ストリームＩＤ、メインフラグ、受信状態および差分時間の各項目を有する。ストリームＩＤは、グループに含まれる動画ストリームの識別番号を示す。メインフラグは、動画ストリームがメイン動画ストリームか否かを示すフラグ情報である。ここでは例として、メイン動画ストリームの場合に「１」が登録され、サブ動画ストリームの場合に「０」が登録される。受信状態は、動画ストリームが受信中の状態か、受信していない状態かを示す。差分時間は、タイムスタンプの差分を示す。

図１２は、プレイリストに記述される情報の例を示す図である。図１２には、１つのグループに対応するＡＢＲプレイリストＬ０およびプレイリストＬ１，Ｌ２を例示している。すなわち、このグループには、プレイリストＬ１，Ｌ２に対応する２つの動画ストリームが含まれている。

ＡＢＲプレイリストＬ０には、プレイリストＬ１，Ｌ２のファイル名や格納場所の情報が記述される。図１２の例では、第２行および第３行にプレイリストＬ１に関する情報が記述され、第４行および第５行にプレイリストＬ２に関する情報が記述されている。例えば、第３行には、プレイリストＬ１のファイル名「ｃａｍＡ．ｍ３ｕ８」とそのパス情報が記述され、第５行にはプレイリストＬ２のファイル名「ｃａｍＢ．ｍ３ｕ８」とそのパス情報が記述されている。

プレイリストＬ１には、一方の動画ストリームに対応する動画ファイルのファイル名や格納場所の情報が、動画ファイルの再生順（配信順）に記述される。図１２の例では、第５行および第６行に先頭の動画ファイルに関する情報が記述され、第７行および第８行に２番目の動画ファイルに関する情報が記述され、第９行および第１０行に３番目の動画ファイルに関する情報が記述されている。この例では、先頭から３番目までの動画ファイルのファイル名はそれぞれ「ｃａｍＡ＿ｆｉｌｅ１．ｔｓ」，「ｃａｍＡ＿ｆｉｌｅ２．ｔｓ」，「ｃａｍＡ＿ｆｉｌｅ３．ｔｓ」であり、第６行、第８行、第１０行に各動画ファイルのファイル名およびパス情報が記述されている。

プレイリストＬ２には、他方の動画ストリームに対応する動画ファイルのファイル名や格納場所の情報が、動画ファイルの再生順（配信順）に記述される。図１２の例では、第５行および第６行に先頭の動画ファイルに関する情報が記述され、第７行および第８行に２番目の動画ファイルに関する情報が記述され、第９行および第１０行に３番目の動画ファイルに関する情報が記述されている。この例では、先頭から３番目までの動画ファイルのファイル名はそれぞれ「ｃａｍＢ＿ｆｉｌｅ１．ｔｓ」，「ｃａｍＢ＿ｆｉｌｅ２．ｔｓ」，「ｃａｍＢ＿ｆｉｌｅ３．ｔｓ」であり、第６行、第８行、第１０行に各動画ファイルのファイル名およびパス情報が記述されている。

プレイリストＬ１，Ｌ２のいずれにも、新たな動画ファイルが作成されるたびにその動画ファイルの情報が順次追加されていく。例えば、リアルタイム再生が行われる場合、再生端末は、動画ファイルをダウンロードするたびに、最新のプレイリストをＷｅｂサーバ１００から取得し、新たに追加された次の動画ファイルを認識して、その動画ファイルをＷｅｂサーバ１００からダウンロードできる。

なお、例えば、各動画ストリームに対応する動画ファイルでは、ファイル名の末尾（拡張子を除く）に再生の順番を示す数字が記述される。また、動画ストリームの間では、同じ時刻に再生される動画像の動画ファイルについて、ファイル名の末尾（拡張子を除く）に記述された数字が同じ値となっている。これにより、再生端末は、受信する動画ストリームを切り替える際に、切り替え後の動画ストリームに対応する動画ファイルの中からどの動画ファイルをダウンロードするべきかを判断できる。すなわち、再生端末は、切り替え後の動画ストリームに対応する動画ファイルの中から、ファイル名の末尾の数字が、切り替え直前にダウンロードしたファイル名の末尾の数字に「１」を加算した値になっている動画ファイルを、次にダウンロードするべき動画ファイルと判断できる。

次に、Ｗｅｂサーバ１００の処理について、フローチャートを用いて説明する。
図１３は、動画ファイル作成処理の例を示すフローチャートである。
［ステップＳ１１］ファイル作成部１２１は、管理者からの操作に応じて、グループを設定する。この処理では、グループに対応するグループ管理テーブル１３１がグループ管理情報１３０に新たに登録され、グループに含まれる各動画ストリームに関する情報がグループ管理テーブル１３１に登録される。各動画ストリームに対応するレコードでは、メインフラグが「０」に設定され、受信状態が受信していないことを示す「未受信」に設定され、差分時間が「０」に設定される。また、グループ管理テーブル１３１に登録される各ストリームＩＤには、例えば、対応する動画ストリームの送信元となるカメラの識別情報が関連付けられる。

また、ファイル作成部１２１は、このグループに対応するＡＢＲプレイリストと、グループに含まれる各動画ストリームに対応するプレイリストとを作成して、ファイル記憶部１１４に格納する。なお、この時点では、各動画ストリームに対応するプレイリストには、動画ファイルのファイル名や格納位置を示す情報は記述されない。

続いて、設定されたグループを処理対象としてステップＳ１２以降の処理が実行される。
［ステップＳ１２］グループに含まれるいずれかの動画ストリームについての動画データをＷｅｂサーバ１００が受信すると、その動画データは受信バッファ１１１に格納される。ファイル作成部１２１は、受信された動画データを受信バッファ１１１から取得する。

なお、ステップＳ１２での処理単位となる動画データは、動画ストリームに含まれるデータのうち、所定の送信単位となるひとまとまりのデータである。このような動画データとしては、例えば、一定数のフレームについてのデータが含まれるＧＯＰ（Group Of Picture）のデータを適用可能である。

［ステップＳ１３］ファイル作成部１２１は、ステップＳ１２で取得した動画データが、グループ内の最初の動画データであるかを判定する。ファイル作成部１２１は、取得した動画データがグループ内の最初の動画データである場合、処理をステップＳ１４に進め、取得した動画データがグループ内の最初の動画データでない場合、処理をステップＳ１５に進める。

［ステップＳ１４］ファイル作成部１２１は、ステップＳ１２で取得した動画データに対応する動画ストリームを、メイン動画ストリームに設定する。このとき、グループ管理テーブル１３１におけるこの動画ストリームに対応するレコードにおいて、メインフラグが「１」に設定される。

［ステップＳ１５］ファイル作成部１２１は、ステップＳ１２で取得した動画データが、メイン動画ストリームに対応する動画データであるかを判定する。ファイル作成部１２１は、取得した動画データがメイン動画ストリームに対応する動画データである場合、処理をステップＳ１９に進め、取得した動画データがメイン動画ストリームに対応する動画データでない場合、処理をステップＳ１６に進める。

［ステップＳ１６］ファイル作成部１２１は、ステップＳ１２で取得した動画データが、その動画データに対応する動画ストリームにおける最初の動画データであるかを判定する。ファイル作成部１２１は、取得した動画データが最初の動画データである場合、処理をステップＳ１７に進め、取得した動画データが最初の動画データでない場合、処理をステップＳ１８に進める。

［ステップＳ１７］ファイル作成部１２１は、ステップＳ１２で取得した動画データに付加されているタイムスタンプを取得する。また、ファイル作成部１２１は、直近に受信バッファ１１１から取得した、メイン動画ストリームに対応する動画データについて、その動画データに付加されているタイムスタンプを取得する。ファイル作成部１２１は、後者のタイムスタンプから前者のタイムスタンプを減算することで、差分時間を算出する。ファイル作成部１２１は、グループ管理テーブル１３１において、ステップＳ１２で取得した動画データに対応する動画ストリームに対応付けられた差分時間の項目に、算出された差分時間を登録する。

［ステップＳ１８］ファイル作成部１２１は、グループ管理テーブル１３１から、ステップＳ１２で取得した動画データに対応する動画ストリームに対応付けられた差分時間を読み出し、この差分時間に基づいて、取得した動画データに付加されているタイムスタンプを書き換える。この処理では、ファイル作成部１２１は、取得した動画データに付加されていたタイムスタンプに、グループ管理テーブル１３１から読み出した差分時間を加算し、加算後のタイムスタンプによって元のタイムスタンプを書き換える。

［ステップＳ１９］ファイル作成部１２１は、ファイル作成条件を満たすかを判定する。ステップＳ１２で取得した動画データと、画像バッファ１１３に蓄積されている動画データのうちステップＳ１２で取得した動画データと同じ動画ストリームに対応する動画データとの合計数が一定数に達していた場合、ファイル作成条件を満たすと判定される。ファイル作成部１２１は、ファイル作成条件を満たさない場合、処理をステップＳ２０に進め、ファイル作成条件を満たす場合、処理をステップＳ２１に進める。

［ステップＳ２０］ファイル作成部１２１は、ステップＳ１２で取得した動画データを画像バッファ１１３に格納する。このとき、ステップＳ１８においてタイムスタンプの書き換えが行われていた場合には、タイムスタンプが書き換えられた動画データが画像バッファ１１３に格納される。この後、処理はステップＳ１２に進められる。

［ステップＳ２１］ファイル作成部１２１は、画像バッファ１１３から、ステップＳ１２で取得した動画データと同じ動画ストリームに対応するすべての動画データを読み出す。ファイル作成部１２１は、読み出した動画データとステップＳ１２で取得した動画データとを用いて、動画ファイルを作成し、ファイル記憶部１１４に格納する。また、ファイル作成部１２１は、作成された画像ファイルのファイル名や格納場所を示す情報を、対応するプレイリストに追記する。この後、処理はステップＳ１２に進められる。

図１４、図１５は、動画データの受信が断絶した場合における動画ファイル作成処理の例を示すフローチャートである。
［ステップＳ３１］ファイル作成部１２１は、グループに含まれる１つの動画ストリームの受信が断絶したことを検出すると、ステップＳ３２以降の処理を実行する。

［ステップＳ３２］ファイル作成部１２１は、グループに対応するグループ管理テーブル１３１を参照し、グループに含まれる各動画ストリームの受信状態を確認する。
［ステップＳ３３］ファイル作成部１２１は、ステップＳ３１の受信断絶によりグループ内の全動画ストリームの受信が断絶したかを判定する。ファイル作成部１２１は、全動画ストリームの受信が断絶した場合、処理をステップＳ３４に進め、受信中の動画ストリームが１つ以上ある場合、処理をステップＳ３６に進める。

［ステップＳ３４］ファイル作成部１２１は、グループに対応するグループ管理テーブル１３１において、各動画ストリームについての差分時間をすべて破棄する（「０」に初期化する）。

［ステップＳ３５］ファイル作成部１２１は、グループに対応するグループ管理テーブル１３１において、ステップＳ３１で受信が断絶した動画ストリームについての受信状態を、受信していないことを示す「未受信」に更新する。これにより、グループに含まれるすべての動画ストリームについての受信状態が「未受信」となる。また、ファイル作成部１２１は、ステップＳ３１で受信が断絶した動画ストリームについてのメインフラグを「０」に更新する。以上の処理が終了すると、処理が図１３のステップＳ１２に進められる。

［ステップＳ３６］ファイル作成部１２１は、ステップＳ３１で受信が断絶した動画ストリームがメイン動画ストリームであるかを判定する。ファイル作成部１２１は、当該動画ストリームがメイン動画ストリームの場合、処理をステップＳ３７に進め、サブ動画ストリームの場合、処理をステップＳ３８に進める。

［ステップＳ３７］ファイル作成部１２１は、メイン動画ストリームを、グループ内の受信中のサブ動画ストリームの１つに変更する。具体的には、グループに対応するグループ管理テーブル１３１において、変更対象のサブ動画ストリームについてのメインフラグが「１」に更新される。なお、この処理では、新たなメイン動画ストリームについての差分時間はそのまま維持される。すなわち、メイン動画ストリームについての差分時間として「０」以外の値が登録された状態となる。

［ステップＳ３８］ファイル作成部１２１は、グループに対応するグループ管理テーブル１３１において、ステップＳ３１で受信が断絶した動画ストリームについての差分時間を破棄する（「０」に初期化する）。

［ステップＳ３９］ファイル作成部１２１は、グループに対応するグループ管理テーブル１３１において、ステップＳ３１で受信が断絶した動画ストリームについての受信状態を、受信していないことを示す「未受信」に更新する。また、ファイル作成部１２１は、ステップＳ３１で受信が断絶した動画ストリームについてのメインフラグを「０」に更新する。以上の処理が終了すると、処理が図１５のステップＳ４１に進められる。

以下、図１５を用いて説明を続ける。
［ステップＳ４１］グループに含まれるいずれかの動画ストリームについての動画データをＷｅｂサーバ１００が受信すると、その動画データは受信バッファ１１１に格納される。ファイル作成部１２１は、受信された動画データを受信バッファ１１１から取得する。

［ステップＳ４２］ファイル作成部１２１は、ステップＳ４１で取得した動画データが、メイン動画ストリームに対応する動画データであるかを判定する。ファイル作成部１２１は、取得した動画データがメイン動画ストリームに対応する動画データである場合、処理をステップＳ４３に進め、取得した動画データがメイン動画ストリームに対応する動画データでない場合、処理をステップＳ４４に進める。

［ステップＳ４３］ファイル作成部１２１は、グループに対応するグループ管理テーブル１３１から、ステップＳ４１で取得した動画データに対応する動画ストリーム（メイン動画ストリーム）に対応付けられた差分時間を読み出す。読み出した差分時間が「０」でない場合、ファイル作成部１２１は、ステップＳ４１で取得した動画データに付加されていたタイムスタンプに、読み出した差分時間を加算し、加算後のタイムスタンプによって元のタイムスタンプを書き換える。

［ステップＳ４４］ファイル作成部１２１は、ステップＳ４１で取得した動画データが、サブ動画ストリームにおける最初の動画データであるかを判定する。ファイル作成部１２１は、取得した動画データが最初の動画データである場合、処理をステップＳ４５に進め、取得した動画データが最初の動画データでない場合、処理をステップＳ４６に進める。

［ステップＳ４５］ファイル作成部１２１は、ステップＳ４１で取得した動画データに付加されているタイムスタンプを取得する。また、ファイル作成部１２１は、直近に受信バッファ１１１から取得した、メイン動画ストリームに対応する動画データについて、その動画データに付加されているタイムスタンプを取得する。ファイル作成部１２１は、後者のタイムスタンプから前者のタイムスタンプを減算することで、差分時間を算出する。ファイル作成部１２１は、グループ管理テーブル１３１において、ステップＳ４１で取得した動画データに対応する動画ストリームに対応付けられた差分時間の項目に、算出された差分時間を登録する。

［ステップＳ４６］ファイル作成部１２１は、グループ管理テーブル１３１から、ステップＳ４１で取得した動画データに対応する動画ストリームに対応付けられた差分時間を読み出し、この差分時間に基づいて、取得した動画データに付加されているタイムスタンプを書き換える。この処理では、ファイル作成部１２１は、取得した動画データに付加されていたタイムスタンプに、グループ管理テーブル１３１から読み出した差分時間を加算し、加算後のタイムスタンプによって元のタイムスタンプを書き換える。

［ステップＳ４７］ファイル作成部１２１は、ファイル作成条件を満たすかを判定する。ステップＳ４１で取得した動画データと、画像バッファ１１３に蓄積されている動画データのうちステップＳ４１で取得した動画データと同じ動画ストリームに対応する動画データとの合計数が一定数に達していた場合、ファイル作成条件を満たすと判定される。ファイル作成部１２１は、ファイル作成条件を満たさない場合、処理をステップＳ４８に進め、ファイル作成条件を満たす場合、処理をステップＳ４９に進める。

［ステップＳ４８］ファイル作成部１２１は、ステップＳ４１で取得した動画データを画像バッファ１１３に格納する。このとき、ステップＳ４３またはステップＳ４６においてタイムスタンプの書き換えが行われていた場合には、タイムスタンプが書き換えられた動画データが画像バッファ１１３に格納される。この後、処理はステップＳ４１に進められる。

［ステップＳ４９］ファイル作成部１２１は、画像バッファ１１３から、ステップＳ４１で取得した動画データと同じ動画ストリームに対応するすべての動画データを読み出す。ファイル作成部１２１は、読み出した動画データとステップＳ４１で取得した動画データとを用いて、動画ファイルを作成し、ファイル記憶部１１４に格納する。また、ファイル作成部１２１は、作成された画像ファイルのファイル名や格納場所を示す情報を、対応するプレイリストに追記する。この後、処理はステップＳ４１に進められる。

以上の図１４、図１５の処理によれば、グループ内のメイン動画ストリームの受信が断絶した場合、サブ動画ストリームの１つが新たなメイン動画ストリームに設定される（ステップＳ３７）。新たなメイン動画ストリームについては、すでに算出されていた差分時間がそのまま維持され、その差分時間によってタイムスタンプが書き換えられ続ける（ステップＳ４３）。これにより、どの動画ストリームの受信が断絶した場合でも、切り替え前後で問題なく再生可能な動画ストリームの動画ファイルを作成し続けることができる。

図１６は、動画配信処理の例を示すフローチャートである。
［ステップＳ５１］配信処理部１２２は、再生端末からプレイリストまたは動画ファイルの送信要求を受信する。

［ステップＳ５２］送信対象のデータ（送信が要求されたデータ）が判定される。プレイリストの送信が要求された場合、処理はステップＳ５３に進められ、動画ファイルの送信が要求された場合、処理はステップＳ５４に進められる。

［ステップＳ５３］配信処理部１２２は、送信が要求されたプレイリストまたはＡＢＲプレイリストをファイル記憶部１１４から読み出し、要求元の再生端末に送信する。
［ステップＳ５４］配信処理部１２２は、送信が要求された動画ファイルをファイル記憶部１１４から読み出し、要求元の再生端末に送信する。

次に、再生端末の処理について、フローチャートを用いて説明する。
図１７は、再生端末の処理例を示すフローチャートである。図１７では例として再生端末３１０の処理について示すが、再生端末３２０，３３０も同様の処理を実行可能である。

［ステップＳ６１］再生端末３１０の画像取得部３１１は、Ｗｅｂサーバ１００に対してＡＢＲプレイリストの送信を要求する。
［ステップＳ６２］送信が要求されたＡＢＲプレイリストがＷｅｂサーバ１００から送信され、画像取得部３１１は、このＡＢＲプレイリストを受信する。

［ステップＳ６３］画像取得部３１１は、ユーザによる動画ストリームの選択の操作を受け付ける。この動画ストリームは、受信したＡＢＲプレイリストに記述された動画ストリームの中から選択される。

［ステップＳ６４］画像取得部３１１は、受信したＡＢＲプレイリストから、選択された動画ストリームに対応するプレイリストのパス情報を読み出し、このパス情報に基づいて当該プレイリストの送信をＷｅｂサーバ１００に要求する。

［ステップＳ６５］送信が要求されたプレイリストがＷｅｂサーバ１００から送信され、画像取得部３１１は、このプレイリストを受信する。
［ステップＳ６６］画像取得部３１１は、受信したプレイリストに基づいて、次に受信するべき動画ファイルを選択する。なお、ステップＳ６６の初回実行時には、例えば、プレイリスト内の先頭の動画ファイルが選択される。あるいは、初回実行時には、ユーザの操作によって指定された動画ファイルが選択されてもよい。

［ステップＳ６７］画像取得部３１１は、受信したプレイリストから、選択された動画ファイルのパス情報を読み出し、このパス情報に基づいて当該動画ファイルの送信をＷｅｂサーバ１００に要求する。

［ステップＳ６８］送信が要求された動画ファイルがＷｅｂサーバ１００から送信され、画像取得部３１１は、この動画ファイルを受信してデコーダ３１２に入力する。デコーダ３１２は、入力された動画ファイルをデコードし、デコードされた動画データを表示処理部３１３に入力する。表示処理部３１３は、入力された動画データに基づく画像を表示装置に表示させる。

［ステップＳ６９］画像取得部３１１が、ユーザによる動画ストリームの切り替え操作を受け付けた場合、処理はステップＳ７１に進められる。一方、動画ストリームの切り替え操作を受け付けていない場合、処理はステップＳ７０に進められる。

［ステップＳ７０］画像取得部３１１は、直近にプレイリストの送信を要求した際に用いたパス情報に基づいて、前回受信したプレイリストと同じファイル名のプレイリストの送信をＷｅｂサーバ１００に要求する。この後、処理がステップＳ６５に進められ、要求したプレイリストがＷｅｂサーバ１００から送信される。この場合、現在再生中の動画ストリームの再生表示が継続される。

［ステップＳ７１］画像取得部３１１は、ステップＳ６２で受信したＡＢＲプレイリストから、切り替え後の動画ストリームに対応するプレイリストのパス情報を読み出し、このパス情報に基づいて当該プレイリストの送信をＷｅｂサーバ１００に要求する。この場合、切り替え後の動画ストリームに対応するプレイリストの送信が要求される。したがって、この後に処理がステップＳ６５に進められると、切り替え後の動画ストリームに対応するプレイリストがＷｅｂサーバ１００から送信される。これにより、再生する動画ストリームが切り替えられる。前述のように、切り替え前の動画ストリームに対応する動画ファイルのタイムスタンプと、切り替え後の動画ストリームに対応する動画ファイルのタイムスタンプとの間では、連続性が保証される。このため、切り替え前後で問題なく動画像の再生表示が継続される。

なお、上記の第２の実施の形態では、個別のカメラにより撮影されて作成された動画ストリームを、Ｗｅｂサーバ１００が配信する場合について説明した。しかし、Ｗｅｂサーバ１００が配信する動画ストリームは、このような例に限定されない。例えば、同一のカメラにより撮影された動画像に基づき、タイムスタンプが互いに連携されない個別のエンコーダを用いて作成された品質の異なる動画ストリームをＷｅｂサーバ１００が配信する場合にも適用可能である。この場合、各エンコーダは同一のサーバ（例えばＷｅｂサーバ１００）に搭載されていてもよいし、異なるコンピュータ上にそれぞれ搭載されていてもよい。各エンコーダが同一のサーバに搭載されるケースとしては、例えば、各エンコーダが個別のハードウェアとして用意されるケースがある。

また、上記の各実施の形態に示した装置（例えば、情報処理装置１、Ｗｅｂサーバ１００、再生端末３１０，３２０，３３０）の処理機能は、コンピュータによって実現することができる。その場合、各装置が有すべき機能の処理内容を記述したプログラムが提供され、そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記憶装置、光ディスク、半導体メモリなどがある。磁気記憶装置には、ハードディスク装置（ＨＤＤ）、磁気テープなどがある。光ディスクには、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）、ブルーレイディスク（Blu-ray Disc：ＢＤ、登録商標）などがある。

プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤなどの可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムまたはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムにしたがった処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムにしたがった処理を実行することもできる。また、コンピュータは、ネットワークを介して接続されたサーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムにしたがった処理を実行することもできる。

１ 情報処理装置
２ 処理部
ｄ１，ｄ２ 映像データ
ｄ１−１〜ｄ１−３，ｄ２−１〜ｄ２−３ 部分映像データ
ｔ１〜ｔ３ 時刻

Claims (10)

1. コンピュータに、
   再生時刻情報をそれぞれ含む複数の映像データを受信し、
   前記複数の映像データの中から前記再生時刻情報の基準となる第１の映像データを特定し、
   前記第１の映像データに含まれる前記再生時刻情報を基準として、前記複数の映像データのうち前記第１の映像データ以外の第２の映像データに含まれる前記再生時刻情報を変更する、
   処理を実行させる情報処理プログラム。
2. 前記再生時刻情報の変更では、
   前記第１の映像データと前記第２の映像データとの間で、同一時刻に受信したフレームについての前記再生時刻情報の差分を算出し、
   算出された前記差分に基づいて前記第２の映像データに含まれる前記再生時刻情報を変更する、
   請求項１記載の情報処理プログラム。
3. 前記再生時刻情報の変更では、算出された前記差分に基づき、前記第１の映像データと前記第２の映像データとの間で、同一時刻に受信したフレームについての前記再生時刻情報が一致するように、前記第２の映像データに含まれる前記再生時刻情報を変更する、
   請求項２記載の情報処理プログラム。
4. 前記コンピュータに、
   前記第１の映像データに基づいて、所定の再生時間ごとの第１の映像データファイルを作成して記憶部に格納し、
   前記再生時刻情報が変更された前記第２の映像データに基づいて、前記再生時間ごとの第２の映像データファイルを作成して前記記憶部に格納し、
   再生装置からの選択指示に応じて、前記第１の映像データファイルおよび前記第２の映像データファイルの中から前記選択指示に対応する映像データファイルを前記記憶部から読み出し、前記再生装置に配信する、
   処理をさらに実行させる請求項１乃至３のいずれか１項に記載の情報処理プログラム。
5. 前記コンピュータに、
   前記第１の映像データファイルの再生順を示す第１の再生順情報と、前記第２の映像データファイルの再生順を示す第２の再生順情報のうちの少なくとも一方を、前記再生装置に送信する、
   処理をさらに実行させ、
   前記選択指示は、前記第１の再生順情報と前記第２の再生順情報のうち前記再生装置に送信された情報に基づいて、前記再生装置から送信される、
   請求項４記載の情報処理プログラム。
6. 前記コンピュータに、
   前記複数の映像データのうち一の映像データの受信が断絶した場合、前記一の映像データが前記第１の映像データであるかを判定し、
   前記一の映像データが前記第１の映像データである場合、前記第２の映像データの中から前記再生時刻情報の基準となる第３の映像データを特定し、
   前記第３の映像データに含まれる前記再生時刻情報を、前記第３の映像データと前記第１の映像データとの間で算出された前記差分に基づいて変更し続けるとともに、前記第２の映像データのうち前記第３の映像データ以外の映像データに含まれる前記再生時刻情報を、前記第３の映像データに含まれる前記再生時刻情報を基準として変更する、
   処理をさらに実行させる請求項２乃至５のいずれか１項に記載の情報処理プログラム。
7. 前記複数の映像データは、それぞれ異なるエンコーダによって動画像を符号化することで生成されたデータである、
   請求項１乃至６のいずれか１項に記載の情報処理プログラム。
8. 前記複数の映像データは、それぞれ異なる撮像装置によって撮影された動画像に基づいて生成されたデータである、
   請求項１乃至６のいずれか１項に記載の情報処理プログラム。
9. コンピュータが、
   再生時刻情報をそれぞれ含む複数の映像データを受信し、
   前記複数の映像データの中から前記再生時刻情報の基準となる第１の映像データを特定し、
   前記第１の映像データに含まれる前記再生時刻情報を基準として、前記複数の映像データのうち前記第１の映像データ以外の第２の映像データに含まれる前記再生時刻情報を変更する、
   情報処理方法。
10. 再生時刻情報をそれぞれ含む複数の映像データを受信し、
    前記複数の映像データの中から前記再生時刻情報の基準となる第１の映像データを特定し、
    前記第１の映像データに含まれる前記再生時刻情報を基準として、前記複数の映像データのうち前記第１の映像データ以外の第２の映像データに含まれる前記再生時刻情報を変更する、処理部、
    を有する情報処理装置。

Images