JP7175658B2 - 映像配信装置、配信方法及びプログラム - Google Patents

Description

本発明は、映像配信装置、配信方法及びプログラムに関する。

動画サービスにおいて、ＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）を用いたＡｄａｐｔｉｖｅ Ｂｉｔｒａｔｅ Ｓｔｒｅａｍｉｎｇ技術が普及してきている。ここで、Ａｄａｐｔｉｖｅ Ｂｉｔｒａｔｅ Ｓｔｒｅａｍｉｎｇ技術としては、ＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）やＨＬＳ（ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ）等が挙げられる。ＤＡＳＨは、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）によって規格化された技術である。ＨＬＳは、Ａｐｐｌｅの主導で規格化された技術である。これらの映像配信技術では、特別なクライアントアプリケーションが必要であるといったＲＴＰ（Ｒｅａｌ－ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｃｏｌ）における問題が解決され、通常のブラウザ上で動画配信を受信再生できる。

例えば、一般的なＤＡＳＨ配信では、配信サーバで解像度やビットレートが異なる複数の動画データを数秒単位のセグメントと言われる動画ファイルに分割し、クライアントは表示性能や通信帯域に合わせて動画ファイルを順次ダウンロードして再生する。具体的には、クライアントはまず動画の全体情報が記載されているＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）ファイルを取得し、その中から適切な解像度やビットレートの動画ストリームを選択する。そして、クライアントは、ＭＰＤの記載に従って、ＭＰＥＧ２ ＴＳストリームまたはＭＰ４ファイルの動画データをセグメント単位でダウンロードして再生する。

特に、ライブ配信では、配信サーバは動画データをセグメント単位に分割して一定時間バッファリングしておき、クライアントは配信サーバのバッファリング期間中にセグメントをタイミングよく取得してスムーズに再生しなければならない。このため、配信サーバのセグメントを準備するタイミングとクライアントのセグメント取得タイミングを合わせることが重要である。特許文献１には、配信サーバが、前回送信したファイル一覧に含まれていたファイルに変化があった場合に、変化があったことを示すようにファイル名を変更した一覧をクライアントに送信する技術が開示されている。

特開２０１３－１２２３１号公報

上述のように、Ａｄａｐｔｉｖｅ Ｂｉｔｒａｔｅ Ｓｔｒｅａｍｉｎｇ技術を使ったライブ配信では、ファイル名の雛形を配信サーバとクライアントで共有し、クライアントは時刻や経過時間を考慮して適切なタイミングでファイルを取得する必要がある。しかし、配信中にクライアントの時刻が変更された場合や、クライアントと配信サーバのＣＰＵクロックの誤差などによりファイル取得タイミングのずれが大きくなった場合は、配信処理を継続できずに切断されることがあるという問題がある。

本発明はこのような問題点に鑑みなされたもので、映像配信中に映像配信装置とクライアント装置の時刻にずれが発生した場合であっても、通信を切断することなく配信処理を継続することを目的とする。

そこで、本発明は、映像データをクライアント装置に送信する映像配信装置であって、一連の映像データを構成する複数の区間データを再生順に生成する生成手段と、前記映像データを構成する複数の区間データのうち一の区間データの取得要求をクライアント装置から受信する受信手段と、前記取得要求に応じた区間データを前記クライアント装置に送信する送信手段と、を備え、前記送信手段は、第１の区間データの送信後でかつ前記第１の区間データに続く第２の区間データの送信前のタイミングにおいて、前記第２の区間データの再生タイミングを基準とした時間範囲に含まれないタイミングを再生タイミングとする区間データである第３の区間データの取得要求を受信した場合に、前記第３の区間データと異なる区間データであって、前記第１の区間データよりも後に生成された区間データを前記第３の区間データとして送信することを特徴とする。

本発明によれば、映像配信中に映像配信装置とクライアント装置の時刻にずれが発生した場合であっても、通信を切断することなく配信処理を継続することができる。

第１の実施形態に係る映像配信システムの全体構成図である。 カメラサーバ装置のハードウェア構成図である。 カメラサーバ装置の機能構成図である。 セグメントデータの構成例を示す図である。 映像配信処理を示すシーケンス図である。 映像配信処理を示すシーケンス図である。 映像配信処理を示すフローチャートである。 セグメント再構成処理を示すフローチャートである。 第２の実施形態に係る映像配信処理を示すフローチャートである。 第３の実施形態に係る映像配信処理を示すフローチャートである。 第４の実施形態に係る映像配信処理を示すフローチャートである。

以下、本発明の実施形態について図面に基づいて説明する。なお、実施形態においては、説明の簡略化のため動画データは、映像データのみを含むものとして説明するが、動画データには、音声データ、画像・音声解析データ、字幕データ等が含まれていてもよい。

（第１の実施形態）
図１は、第１の実施形態に係る映像配信システム１００の全体構成図である。カメラサーバ装置１１０とクライアント装置１２０とはネットワーク１３０を介して相互に接続される。カメラサーバ装置１１０は、カメラを備え、ネットワーク１３０を介して撮影した画像をクライアント装置１２０に配信する。クライアント装置１２０は、カメラサーバ装置１１０にアクセスし、画像を取得する。

なお、本実施形態においては、説明の簡略化のためにカメラサーバ装置１１０及びクライアント装置１２０はいずれも１台とするが、カメラサーバ装置及びクライアント装置はそれぞれ２台以上であってもよい。２台以上のカメラサーバ装置が１台のクライアント装置１２０に映像を配信してもよい。また、２台以上のクライアント装置１２０が１台のカメラサーバ装置１１０から映像を受信してもよい。ネットワーク１３０はＥｔｈｅｒｎｅｔ（登録商標）等の通信規格を満足する複数のルータ、スイッチ、ケーブル等から構成される。ネットワーク１３０は、インターネットやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等である。

図２は、カメラサーバ装置１１０のハードウェア構成図である。ＣＰＵ２０１、一次記憶装置２０２、二次記憶装置２０３、画像キャプチャＩ／Ｆ２０４、ネットワークＩ／Ｆ２０６が内部バス２１０を介して相互に接続されている。ＣＰＵ２０１は、カメラサーバ装置１１０の全体を制御する。一次記憶装置２０２は、ＲＡＭに代表される書き込み可能な高速の記憶装置である。一次記憶装置２０２には、ＯＳや各種プログラム及び各種データがロードされ、またＯＳや各種プログラムの作業領域としても使用される。二次記憶装置２０３は、フラッシュメモリ、ＨＤＤ、ＳＤカード等に代表される不揮発性の記憶装置である。二次記憶装置２０３は、ＯＳや各種プログラム及び各種データの永続的な記憶領域として使用される。二次記憶装置２０３はまた、短期的な各種データの記憶領域としても使用される。後述するカメラサーバ装置１１０の機能や処理は、ＣＰＵ２０１が二次記憶装置２０３に格納されているプログラムを読み出し、このプログラムを実行することにより実現されるものである。

画像キャプチャＩ／Ｆ２０４にはＣＣＤやＣＭＯＳからなる画像センサ２０５が接続され、画像センサ２０５から取得した画像データを所定のフォーマットに変換・圧縮して一次記憶装置２０２に転送する。ネットワークＩ／Ｆ２０６は前述のネットワーク１３０と接続するためのＩ／Ｆであり、Ｅｔｈｅｒｎｅｔ等の通信媒体を介してクライアント装置１２０等との通信を担う。

図３は、カメラサーバ装置１１０の機能構成図である。映像取得部３０１は、画像センサ２０５で生成された映像フレームを画像キャプチャＩ／Ｆ２０４を経由して取得し符号化処理を行い、一時記憶部３０４に保存する。一時記憶部３０４は、生成された映像フレームを一時的に蓄積する。映像フレームは、配信完了後に一時記憶部３０４から削除される。

配信管理部３０２は、クライアント装置１２０から配信開始要求を受信すると、通信処理部３０３を経由して配信可能映像ストリーム情報を含んだＭＰＤファイルを送信する。配信管理部３０２はまた、一時記憶部３０４に蓄積されている単数または複数の映像フレームを送信可能なセグメント（動画ファイル）に変換し、クライアント装置１２０の要求に合わせて通信処理部３０３を経由してセグメントを送信する。ここで、セグメントは、映像データを構成する区間データの一例である。

図４は、ＭＰ４ファイルフォーマットで配信する場合のセグメントデータの構成例を示す図である。セグメントデータの先頭には、セグメントであることを示すＢＯＸ ｓｔｙｐ４００とセグメントの順番を示すＢＯＸ ｓｉｄｘ４０１が存在する。ＢＯＸ ｓｉｄｘ４０１には配信開始からの経過時間を示すｅａｒｌｉｅｓｔ ｐｒｅｓｅｎｔａｔｉｏｎ ｔｉｍｅが含まれる。続いて、フラグメントの先頭を示すＢＯＸ ｍｏｏｆ４０２があり、その中にはフラグメントの時刻情報を示すＢＯＸ ｔｆｄｔ４０３が存在する。ＢＯＸ ｔｆｄｔ４０３には、配信開始からの経過時間を示すｂａｓｅ ｍｅｄｉａ ｄｅｃｏｄｅ ｔｉｍｅが含まれる。そして、最後に映像データを含むＢＯＸ ｍｄａｔ４０４が存在する。

次に、カメラサーバ装置１１０による、リアルタイム映像配信処理について説明する。カメラサーバ装置１１０は、リアルタイム映像配信処理において、一連の映像データを構成する複数のセグメントを再生順に対応した順番で生成し、クライアント装置１２０からの取得要求に応じて順次セグメントを送信する。クライアント装置１２０は、映像ストリームの情報、セグメントが配信可能となる時刻、セグメントの生成間隔、バッファリング時間などが記載されたＭＰＤファイルを配信開始時に取得する。クライアント装置１２０は、セグメントの取得要求において、セグメントの番号でセグメントを指定するものとする。なお、他の例としては、時刻やファイルのオフセット位置でセグメントを指定してもよい。

図５は、リアルタイムでの映像配信処理を示すシーケンス図である。図５を参照しつつ、映像配信処理の実行中にクライアント装置１２０の時刻が変更された場合の処理について説明する。なお、ここでは、セグメントの生成間隔を１秒として説明する。リアルタイム映像配信処理が開始すると、カメラサーバ装置１１０の配信管理部３０２は、セグメントの生成を開始する。図５の例では、カメラサーバ装置１１０は、Ｓ５０１においてセグメント１０００を生成し、続いて、Ｓ５０２、Ｓ５０３において、それぞれセグメント１００１、１００２を生成する。生成されたセグメント１０００、１００１、１００２は、順にバッファ（一次記憶領域）に保存される。

一方、クライアント装置１２０は、Ｓ５１１において、配信開始時刻と処理時点の時刻からセグメント番号を算出する。そして、クライアント装置１２０は、算出されたセグメント（セグメント１０００）が生成されたタイミングを見計らって、セグメント１０００を指定した取得要求を送信する。そして、Ｓ５１２において、クライアント装置１２０は、セグメント１０００の取得要求に対するレスポンス（応答）として、カメラサーバ装置１１０からセグメント１０００を受信する。その後、Ｓ５１３において、クライアント装置１２０は、次のセグメント番号（セグメント１００１）を算出し、セグメント１００１の取得要求を送信し、Ｓ５１４において、セグメント１００１を受信する。この時点で、例えば、ユーザ操作やＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）などによりクライアント装置１２０の時刻を約７０００秒進めたものとする（Ｓ５１５）。

クライアント装置１２０は、次のセグメント番号の算出に現在時刻を使用する。このため、クライアント装置１２０の時刻が進むとセグメント番号も進み、次に、クライアント装置１２０が取得するセグメントは、セグメント１００２よりも先のセグメントとなる。例えば、本来取得対象のセグメントがセグメント１００２であるところ、クライアント装置１２０の時刻が進んだことにより、取得対象のセグメントがセグメント８０００になる。この場合、時刻が進んだ後のＳ５１６において、クライアント装置１２０は、セグメント８０００の取得要求を送信する。

カメラサーバ装置１１０は、バッファリング中のセグメント１００２の取得要求を期待していたが、Ｓ５１６において、セグメント８０００つまり約７０００秒も未来のセグメントの取得要求を受信することになる。すなわち、カメラサーバ装置１１０は、セグメント１００１の送信後で、かつセグメント１００２の送信前のタイミングにおいて、セグメント８０００の取得要求を受信する。セグメント８０００の取得要求は、本来なら７０００秒経過後の要求であるが、７０００秒待たせる処理を実施した場合には、クライアント装置１２０のレスポンスタイムアウトにより切断してしまう。そこで、本実施形態においては、カメラサーバ装置１１０はバッファリング中のセグメントをセグメント８０００としてクライアント装置１２０に送信する。

すなわち、まず、Ｓ５０４において、カメラサーバ装置１１０は、バッファリング中のセグメント１００２をセグメント８０００に再構成する。セグメントの再構成は、バッファリング中のセグメントの映像データはそのままに、図４に示す時刻情報、セグメント情報、ファイル名等を変更することで、バッファリング中のセグメントを要求されたセグメントにする処理である。次に、Ｓ５１７において、カメラサーバ装置１１０は、再構成したセグメント８０００をクライアント装置１２０に送信する。続く、Ｓ５０５においては、カメラサーバ装置１１０は、セグメント８０００の次のセグメント８００１を生成する。クライアント装置１２０は、Ｓ５１７でセグメント８０００を受信すると、次に、Ｓ５１８において、セグメント８００１の取得要求を送信し、続いて、Ｓ５１９において、セグメント８００１を受信する。

図５においては、クライアント装置１２０の時刻を進めた例を説明したが、時刻を戻した場合にも適用可能である。この場合、カメラサーバ装置１１０は、バッファリングしている最古（最も前）のセグメントより過去（前）に生成されたセグメントの取得要求を受信することがある。また、カメラサーバ装置１１０は、配信済みのセグメントの取得要求を再度受信する場合がある。これらの場合に、カメラサーバ装置１１０は、セグメントの再構成を行うこととする。これにより、配信処理を継続することができる。なお、配信済みセグメントの取得要求を再度受信したときは、カメラサーバ装置１１０は、セグメントを再構成して送信してもよく、配送済みセグメントを再度送信してもよい。

図６は、映像配信処理を示すシーケンス図である。図６を参照しつつ、映像アイシン処理の実行中に、カメラサーバ装置１１０とクライアント装置１２０のＣＰＵクロック誤差が大きくなった場合の処理について説明する。なお、ここでは、セグメントの生成間隔を１秒、バッファリング時間は２秒（セグメント２つ分）として説明する。なお、ＦＩＦＯ方式で、バッファリングから２秒経過したセグメントはバッファから削除されるものとする。

図６の例では、Ｓ６０１において、カメラサーバ装置１１０は、セグメント１０００を生成し、続いて、Ｓ６０２、Ｓ６０３、Ｓ６０４、Ｓ６０５において、セグメント１００１、１００２、１００３、１００４を生成する。一方、クライアント装置１２０は、Ｓ６１１において、配信開始時刻と処理時点の時刻からセグメントを算出し、算出されたセグメント（セグメント１０００）が生成されたタイミングを見計らって、セグメント１０００の取得要求を送信する。そして、Ｓ６１２において、クライアント装置１２０は、カメラサーバ装置１１０からセグメント１０００をレスポンスとして受信する。

その後、クライアント装置１２０は、次のセグメントを算出し、セグメント１００１が生成されるタイミングまで待つ。ただし、前述のように、カメラサーバ装置１１０とクライアント装置１２０のＣＰＵクロック誤差がある。このため、クライアント装置１２０は、Ｓ６１３において、少し遅いタイミングで次のセグメント取得要求を送信する。これに対し、Ｓ６１４において、クライアント装置１２０は、カメラサーバ装置１１０からセグメント１００１をレスポンスとして受信する。なお、本実施例では、理解しやすくするため１セグメント程度遅らせているが実際は数十ｐｐｍ（ｐａｒｔｓ ｐｅｒ ｍｉｌｌｉｏｎ）程度、具体的には数秒のずれが発生するには数時間～十数時間かかることが多い。また、カメラサーバ装置１１０はセグメントを２つしかバッファリングできない。このため、カメラサーバ装置１１０は、Ｓ６０５において、セグメント１００４を生成すると、バッファリングされている、未送信のセグメント１００２を破棄する。

一方、クライアント装置１２０は、セグメント１００１を取得した後、Ｓ６１５において、同様にセグメント１００２の生成タイミングを待って、セグメント１００２の取得要求を送信する。カメラサーバ装置１１０は、Ｓ６１５において、バッファリングしている最古のセグメント１００３より過去のセグメント１００２の取得要求を受信する。この場合、Ｓ６０６において、カメラサーバ装置１１０は、処理時点においてバッファリングしているセグメント１００３をセグメント１００２に再構成し、セグメント１００４をセグメント１００３に再構成する。そして、Ｓ６１６において、カメラサーバ装置１１０は、セグメント１００３として生成され、セグメント１００２に再構成されたセグメントをクライアント装置１２０に送信する。すなわち、セグメント１００３をセグメント１００２としてクライアント装置１２０に送信する。カメラサーバ装置１１０は、続く、Ｓ６０７においては、Ｓ６０４において生成されたセグメントの次のセグメントではなく、Ｓ６０６において再構成されたセグメントの次のセグメント（セグメント１００４）を生成する。

図６に示す例においては、Ｓ６０６において、カメラサーバ装置１１０は、セグメント１００３をセグメント１００２に再構成した。ただし、リアルタイム性を考慮して、カメラサーバ装置１１０は、セグメント１００３を破棄し、セグメント１００４をセグメント１００２に再構成することとしてもよい。この場合、Ｓ６０７で生成されるセグメントはセグメント１００３となる。

図６においては、クライアント装置１２０のＣＰＵクロックがカメラサーバ装置１１０のＣＰＵクロックより遅い例を説明したが、クライアント装置１２０のＣＰＵクロックの方が早い場合は、図５と同様のシーケンスとなる。

図７は、カメラサーバ装置１１０による映像配信処理を示すフローチャートである。カメラサーバ装置１１０がクライアント装置１２０から配信開始要求を受信すると、映像配信処理が開始する。Ｓ７０１において、カメラサーバ装置１１０の配信管理部３０２は、映像取得部３０１に映像生成の開始指示を送信する。次に、Ｓ７０２において、配信管理部３０２は、配信可能な時刻や映像ストリームの情報、セグメント生成間隔、セグメントのファイル名の雛形を記述したＭＰＤをクライアント装置１２０に送信する。次に、Ｓ７０３において、配信管理部３０２は、イベントが発生するまで待機する。次に、Ｓ７０４において、配信管理部３０２は、イベントが発生すると、発生イベントの種類を判定する。

発生イベントが映像フレーム生成イベントである場合には（Ｓ７０４で映像フレーム生成）、配信管理部３０２は、処理をＳ７０５へ進める。なお、映像フレーム生成イベントは、映像取得部３０１が生成するイベントである。発生イベントがセグメント生成通知イベントの場合には（Ｓ７０４でセグメント生成通知）、配信管理部３０２は、処理をＳ７１０へ進める。セグメント生成通知イベントは、配信管理部３０２が生成するイベントである。なお、他の例としては、カメラサーバ装置１１０が配信管理部３０２と別にセグメント生成通知を生成する生成部を有してもよい。発生イベントがセグメント取得要求イベントの場合には（Ｓ７０４でセグメント取得要求）、配信管理部３０２は、処理をＳ７２０へ進める。セグメント取得要求イベントは、通信処理部３０３が外部装置から取得するイベントである。発生イベントが配信終了イベントの場合には（Ｓ７０４で配信終了）、配信管理部３０２は、処理をＳ７３０へ進める。

Ｓ７０５において、配信管理部３０２は、映像フレームをバッファリングする。次に、Ｓ７０６において、配信管理部３０２は、セグメント分のフレームがバッファに蓄積されたか否かを判定する。配信管理部３０２は、セグメント分のフレームがバッファに蓄積されると（Ｓ７０６でＹＥＳ）、処理をＳ７０７へ進める。配信管理部３０２は、セグメント分のフレームが蓄積されていない場合には（Ｓ７０６でＮＯ）、処理をＳ７０３へ進める。すなわち、イベント待ち状態になる。Ｓ７０７において、配信管理部３０２は、セグメントを生成する。次に、Ｓ７０８において、配信管理部３０２は、自身にセグメント生成通知を送る。次に、Ｓ７０９において、配信管理部３０２は、セグメント化した映像フレームを解放する。配信管理部３０２は、その後処理をＳ７０３へ進める。

Ｓ７１０においては、配信管理部３０２は、セグメントをバッファ（一時記憶領域）バッファリングする。次に、Ｓ７１１において、配信管理部３０２は、セグメント数がバッファリングの上限を超えたか否かを判定する。配信管理部３０２は、セグメント数がバッファリングの上限を超えた場合には（Ｓ７１１でＹＥＳ）、処理をＳ７１２へ進める。配信管理部３０２は、セグメント数がバッファリングの上限を超えていない場合には（Ｓ７１１でＮＯ）、処理をＳ７０３へ進める。Ｓ７１２において、配信管理部３０２は、古いセグメントを解放し、その後処理をＳ７０３へ進める。

Ｓ７２０において、配信管理部３０２は、セグメント取得要求イベントにおいて要求されたセグメントが基準範囲に含まれないタイミング（基準範囲外のタイミング）を再生タイミングとするセグメントか否かを判定する。ここで、基準範囲とは、最新のセグメントを基準とした時間範囲である。本実施形態においては、基準範囲は、バッファに存在し得る最古のタイミングを一端とし、このタイミングから、最新のセグメントから予め設定された時間後（未来）のタイミングまでの範囲である。このように、基準範囲のうち前側の一端はバッファのサイズに応じて定まる。

配信管理部３０２は、要求されたセグメントが基準範囲外のタイミングを再生タイミングとするセグメントである場合（Ｓ７２０でＹＥＳ）、処理をＳ７２１へ進める。配信管理部３０２は、要求されたセグメントが基準範囲内のタイミングを再生タイミングとするセグメントである場合（Ｓ７２０でＮＯ）、処理をＳ７２６へ進める。

要求されたセグメントが基準範囲外のタイミングを再生タイミングとするセグメントである場合とは、以下の２つのケースである。すなわち、１つ目は、要求されたセグメントが基準範囲のうち最も前のタイミングよりも前のタイミングを再生タイミングとする場合である。２つ目は、要求されたセグメントが基準範囲の最も後のタイミングよりも後のタイミングを再生タイミングとする場合である。

Ｓ７２１において、配信管理部３０２は、バッファにあるセグメントを要求されたセグメントとして再構成する。次に、Ｓ７２２において、配信管理部３０２は、再構成に成功したか否かを判定する。配信管理部３０２は、再構成に成功した場合には（Ｓ７２２でＹＥＳ）、処理をＳ７２３へ進める。配信管理部３０２は、再構成に失敗した場合には（Ｓ７２２でＮＯ）、処理をＳ７２５へ進める。なお、Ｓ７２１の処理及び再構成に成功したか否かの判断については、図８を参照しつつ後に詳述する。

Ｓ７２３において、配信管理部３０２は、再構成されたセグメントをクライアント装置１２０へ送信する。次に、Ｓ７２４において、配信管理部３０２は、送信セグメントをバッファから解放する。配信管理部３０２は、その後処理をＳ７０３へ進める。また、Ｓ７２５においては、配信管理部３０２は、エラー応答をクライアント装置１２０へ送信する。配信管理部３０２は、その後処理をＳ７０３へ進める。

Ｓ７２６において、配信管理部３０２は、セグメント取得要求イベントにおいて要求されたセグメントがバッファに存在するか否かを判定する。配信管理部３０２は、要求されたセグメントがバッファに存在する場合には（Ｓ７２６でＹＥＳ）、処理をＳ７２７へ進める。配信管理部３０２は、要求されたセグメントがバッファに存在しない場合には（Ｓ７２６でＮＯ）、処理をＳ７２９へ進める。Ｓ７２７において、配信管理部３０２は、要求されたセグメントをクライアント装置１２０に送信する。次に、Ｓ７２８において、配信管理部３０２は、送信したセグメントをバッファから解放する。配信管理部３０２は、その後処理をＳ７０３へ進める。また、Ｓ７２９において、配信管理部３０２は、エラー応答をクライアント装置１２０へ送信する。配信管理部３０２は、その後処理をＳ７０３へ進める。

Ｓ７３０において、配信管理部３０２は、バッファリングしているすべてのセグメントを解放する。次に、Ｓ７３１において、配信管理部３０２は、バッファリングしているすべての映像フレームを解放する。次に、Ｓ７３２において、映像取得部３０１に映像生成の停止を指示する。以上で、映像配信処理が終了する。

図８は、セグメント再構成処理を示すフローチャートである。Ｓ８０１において、配信管理部３０２は、セグメント取得要求に係るセグメントのセグメント番号を保存する。次に、Ｓ８０２において、配信管理部３０２は、再構成中フラグをＯＦＦにする。次に、Ｓ８０３において、配信管理部３０２は、バッファリングされているセグメントを１つずつ処理するループを開始する。ループ処理において、まずＳ８０４において、配信管理部３０２は、再構成中フラグがＯＦＦか否かを判定する。配信管理部３０２は、再構成中フラグがＯＦＦの場合には（Ｓ８０４でＹＥＳ）、処理をＳ８０５へ進める。配信管理部３０２は、再構成中フラグがＯＮの場合には（Ｓ８０４でＮＯ）、処理をＳ８１０へ進める。

Ｓ８０５において、配信管理部３０２は、対象セグメントが再構成可能か否かを判定する。ここで、対象セグメントは、バッファリングされているセグメントのうち、処理対象として選択されているセグメントである。配信管理部３０２は、再構成可能な場合には（Ｓ８０５でＹＥＳ）、処理をＳ８０６へ進める。配信管理部３０２は、再構成不可能な場合には（Ｓ８０５でＮＯ）、処理をＳ８０９へ進める。

Ｓ８０６において、配信管理部３０２は、セグメントを再設定する。具体的には、配信管理部３０２は、対象セグメントに含まれる映像データはそのままで、ヘッダ情報として含まれる時刻情報、セグメント情報、ファイル名をＳ８０１で保存した、セグメント取得要求に係るセグメントに合わせて変更する。配信管理部３０２は、セグメントから経過した時間を算出し、図４を参照しつつ説明したｓｉｄｘ４０１のｅａｒｌｉｅｓｔ ｐｒｅｓｅｎｔａｔｉｏｎ ｔｉｍｅと、ｔｆｄｔ４０３のｂａｓｅ ｍｅｄｉａ ｄｅｃｏｄｅ ｔｉｍｅの値を更新する。これにより、対象セグメントのヘッダ情報は、セグメント要求に係るセグメントであることを識別するヘッダ情報に書き替えられる。本処理は、再構成処理の一例である。

次に、Ｓ８０７において、配信管理部３０２は、セグメントを次の番号に更新する。次に、Ｓ８０８において、配信管理部３０２は、再構成中フラグをＯＮに変更する。Ｓ８０９においては、配信管理部３０２は、セグメントを解放する。また、Ｓ８１０及びＳ８１１の処理は、Ｓ８０６及びＳ８０７の処理と同様である。配信管理部３０２は、以上の処理をすべてのセグメントに対して実施する。配信管理部３０２は、最終的にバッファに新しいセグメントが残っている場合には、成功と判定し、先頭のセグメントを送信対象として決定する。配信管理部３０２は、セグメントが残っていない場合には、失敗と判定する。なお、他の例としては、リアルタイム性を考慮し、配信管理部３０２は、最終的にバッファに新しいセグメントが残っている場合には、先頭のセグメントに替えて最後のセグメントを送信対象として決定してもよい。

以上のように、本実施形態に係るカメラサーバ装置１１０は、基準範囲外のタイミングを再生タイミングとするセグメントの取得要求を受信した場合には、要求に応じてセグメントを再構成することで、要求に応じたセグメントを配信する。このように、カメラサーバ装置１１０は、セグメントの配信を継続することができる。すなわち、本実施形態によれば、映像配信中に映像配信装置とクライアント装置の時刻にずれが発生した場合であっても、通信を切断することなく配信処理を継続することができる。

第１の実施形態の第１の変形例について説明する。図７を参照しつつ説明したＳ７２０において参照される基準範囲の前側の一端及び後側の一端のタイミングは、実施形態に限定されるものではない。例えば、基準範囲のうち前側の一端のタイミングは、最新のセグメントから予め設定された期間だけ前（過去）のタイミングであってもよい。また、例えば、クライアント装置１２０は、セグメント取得要求にエラーが返ってきても、配信処理を継続するため何度かリトライを行う。しかし、クライアント装置１２０は、一定回数以上エラーが続くような場合には配信継続不可と判断して、切断状態となる。これに対応し、基準範囲のうち後側の一端は、最新のセグメントからクライアント装置１２０が通信を切断せずに繰り返しセグメント取得要求を行う程度の時間だけ後のタイミングであってもよい。さらに、カメラサーバ装置１１０は、クライアント装置１２０からタイムアウト期間やリトライの最大回数等、通信の切断の条件を示す切断情報を受信し、切断情報に基づいて、基準範囲のうち後側の一端のタイミングを決定してもよい。

また、カメラサーバ装置１１０が、セグメントを配信した後はセグメントを解放するような実装では、配信済みセグメントを再要求された場合には、配信期間外のタイミングを再生タイミングとするセグメントであると判断してもよい。

また、第２の変形例としては、配信管理部３０２は、再構成の成功か否かの判定において、再構成の対象のセグメントにＩＤＲ（Ｉｎｓｔａｎｔａｎｅｏｕｓ Ｄｅｃｏｄｅｒ Ｒｅｆｒｅｓｈ）フレームが含まれるか否かを考慮してもよい。ＩＤＲフレームの前後でフレーム間の参照関係がなくなることに起因したもので、例えば、配信管理部３０２は、ＩＤＲフレームから始まるセグメントの場合に再構成に成功したと判断してもよい。また、他の例としては、配信管理部３０２は、ＩＤＲフレームを含むセグメントの場合に再構成に成功したと判断してもよい。

また、第３の変形例としては、本実施形態においては、ＭＰＥＧ－ＤＡＳＨによる配信方法を説明したが、ＨＬＳなど他のＨＴＴＰ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇを用いた配信や、それ以外の時刻情報を使った配信方式にも適用可能である。

（第２の実施形態）
次に、第２の実施形態に係る映像配信システム１００について、第１の実施形態に係る映像配信システム１００と異なる点を主に説明する。第２の実施形態に係る映像配信システム１００においては、カメラサーバ装置１１０は、セグメントの再構成に失敗した場合に、エラー応答を返さずに、配信処理を継続する。

図９は、第２の実施形態に係るカメラサーバ装置１１０による映像配信処理を示すフローチャートである。Ｓ９０１～Ｓ９０３の処理は、それぞれ図７を参照しつつ説明したＳ７０１～Ｓ７０３の処理と同様である。Ｓ９０４において、配信管理部３０２は、イベントの種類を判定する。発生イベントが映像フレーム生成イベントである場合には（Ｓ９０４で映像フレーム生成）、配信管理部３０２は、処理をＳ９０５へ進める。発生イベントがセグメント生成通知イベントの場合には（Ｓ９０４でセグメント生成通知）、配信管理部３０２は、処理をＳ９１０へ進める。発生イベントがセグメント取得要求イベントの場合には（Ｓ９０４でセグメント取得要求）、配信管理部３０２は、処理をＳ９２０へ進める。発生イベントが配信終了イベントの場合には（Ｓ９０４で配信終了）、配信管理部３０２は、処理をＳ９３０へ進める。Ｓ９０５～Ｓ９０９の処理及びＳ９３０～Ｓ９３２の処理は、それぞれＳ７０６～Ｓ７０９の処理及びＳ７３０～Ｓ７３２の処理と同様である。

Ｓ９１０～Ｓ９１２の処理は、それぞれＳ７１０～Ｓ９１２の処理と同様である。なお、Ｓ９１１において、バッファリングの上限を超えていない場合には（Ｓ９１１でＮＯ）、配信管理部３０２は、処理をＳ９１３へ進める。また、Ｓ９１２の処理の後、配信管理部３０２は、処理をＳ９１３へ進める。Ｓ９１３において、配信管理部３０２は、既にセグメント取得要求が保存されているかどうかを判定する。配信管理部３０２は、セグメント取得要求が保存されている場合には（Ｓ９１３でＹＥＳ）、処理をＳ９１４へ進める。配信管理部３０２は、セグメント取得要求が保存されていない場合には（Ｓ９１３でＮＯ）、処理をＳ９０３へ進める。

Ｓ９１４において、配信管理部３０２は、保存されているセグメント取得要求に係るセグメントがバッファリングされているか否かを判定する。配信管理部３０２は、セグメントがバッファリングされている場合には（Ｓ９１４でＹＥＳ）、処理をＳ９１５へ進める。配信管理部３０２は、セグメントがバッファリングされていない場合には（Ｓ９１４でＮＯ）、処理をＳ９０３へ進める。Ｓ９１５において、配信管理部３０２は、バッファリングされているセグメントを、保存されているセグメント取得要求に係るセグメントとしてクライアント装置１２０に送信する。次に、Ｓ９１６において、配信管理部３０２は、送信したセグメントを解放する。配信管理部３０２は、その後処理をＳ９０３へ進める。

Ｓ９２０～Ｓ９２４の処理は、それぞれＳ７２０～Ｓ７２４の処理と同様である。ただし、Ｓ９２２において、配信管理部３０２は、再構成に失敗した場合には（Ｓ９２２でＮＯ）、処理をＳ９２５へ進める。そして、Ｓ９２５において、配信管理部３０２は、セグメント取得要求を保存する。Ｓ９２６においてセグメント取得要求が保存された後で、Ｓ９１３が実行されたとする。この場合、Ｓ９１３において、セグメント取得要求が保存されていると判定され、Ｓ９１５において、新たに生成されたセグメントがセグメント取得要求に係るセグメントとして送信される。なお、Ｓ９２６～Ｓ９２９の処理は、それぞれＳ７２６～Ｓ７２９の処理と同様である。なお、第２の実施形態に係る映像配信システム１００のこれ以外の構成及び処理は、第１の実施形態に係る映像配信システム１００の構成及び処理と同様である。

以上のように、第２の実施形態のカメラサーバ装置１１０は、第１の実施形態のカメラサーバ装置１１０と同様に、基準範囲外のタイミングのセグメントの取得要求を受信した場合には、要求に応じてセグメントを再構成する。第２の実施形態のカメラサーバ装置１１０は、さらに再構成に失敗した場合においても、エラーレスポンスを返さない。これにより、配信処理の継続性をさらに向上させることができる。

（第３の実施形態）
次に、第３の実施形態に係る映像配信システム１００について、他の実施形態に係る映像配信システム１００と異なる点を主に説明する。第３の実施形態のカメラサーバ装置１１０は、基準範囲外のタイミングのセグメント取得要求を受信した場合には、バッファリングしているセグメントを破棄し、新たに生成されたセグメントをセグメント取得要求に係るセグメントとして送信する。

図１０は、第３の実施形態に係るカメラサーバ装置１１０による映像配信処理を示すフローチャートである。Ｓ１００１～Ｓ１００３の処理は、それぞれ図７を参照しつつ説明したＳ７０１～Ｓ７０３の処理と同様である。Ｓ１００４において、配信管理部３０２は、イベントの種類を判定する。発生イベントが映像フレーム生成イベントである場合には（Ｓ１００４で映像フレーム生成）、配信管理部３０２は、処理をＳ１００５へ進める。発生イベントがセグメント生成通知イベントの場合には（Ｓ１００４でセグメント生成通知）、配信管理部３０２は、処理をＳ１０１０へ進める。発生イベントがセグメント取得要求イベントの場合には（Ｓ１００４でセグメント取得要求）、配信管理部３０２は、処理をＳ１０２０へ進める。発生イベントが配信終了イベントの場合には（Ｓ１００４で配信終了）、配信管理部３０２は、処理をＳ１０３０へ進める。Ｓ１００５～Ｓ１００９の処理及びＳ１０１０～Ｓ１０１２の処理は、それぞれＳ７０６～Ｓ７０９の処理及びＳ７１０～Ｓ７１２の処理と同様である。また、Ｓ１０３０～Ｓ１０３２の処理は、及びＳ７３０～Ｓ７３２の処理と同様である。

Ｓ１０２０において、配信管理部３０２は、セグメント取得要求イベントにおいて要求されたセグメントが基準範囲外のタイミングを再生タイミングとするセグメントか否かを判定する。配信管理部３０２は、要求されたセグメントが基準範囲外のタイミングを再生タイミングとするセグメントである場合（Ｓ１０２０でＹＥＳ）、処理をＳ１０２１へ進める。配信管理部３０２は、要求されたセグメントが基準範囲内のタイミングを再生タイミングとするセグメントである場合（Ｓ１０２０でＮＯ）、処理をＳ１０２４へ進める。Ｓ１０２１において、配信管理部３０２は、バッファリングしているすべてのセグメントを解放する。次に、Ｓ１０２２において、配信管理部３０２は、次に作成するセグメントをセグメント取得要求に係るセグメントとして生成するようにセグメント情報を更新する。

次に、Ｓ１０２３において、配信管理部３０２は、エラー応答を送信する。配信管理部３０２は、Ｓ１０２３の処理の後、処理をＳ１００３へ進める。なお、Ｓ１０２４～Ｓ１０２７の処理は、それぞれＳ７２６～Ｓ７２９の処理と同様である。なお、第３の実施形態に係る映像配信システム１００のこれ以外の構成及び処理は、他の実施形態に係る映像配信システム１００の構成及び処理と同様である。

以上のように、第３の実施形態のカメラサーバ装置１１０は、基準範囲外のタイミングのセグメントの取得要求を受信した場合には、バッファリングしているセグメントを破棄し、エラー応答を返す。これに対し、カメラサーバ装置１１０は、リトライ処理により、再度セグメント取得要求を受信した場合には、新たに生成されたセグメントをセグメント取得要求に係るセグメントとして送信することで、配信処理を継続することができる。第３の実施形態においては、また、カメラサーバ装置１１０が再構成を行わなくてよいという利点がある。

（第４の実施形態）
次に、第４の実施形態に係る映像配信システム１００について、他の実施形態に係る映像配信システム１００と異なる点を主に説明する。第４の実施形態のカメラサーバ装置１１０は、基準範囲外のタイミングのセグメント取得要求を受信した場合には、バッファリングしているセグメントを破棄し、エラー応答を返さずに、配信処理を継続する。

図１１は、第４の実施形態に係るカメラサーバ装置１１０による映像配信処理を示すフローチャートである。Ｓ１１０１～Ｓ１００３の処理は、それぞれ図７を参照しつつ説明したＳ７０１～Ｓ７０３の処理と同様である。Ｓ１１０４において、配信管理部３０２は、イベントの種類を判定する。発生イベントが映像フレーム生成イベントである場合には（Ｓ１１０４で映像フレーム生成）、配信管理部３０２は、処理をＳ１１０５へ進める。発生イベントがセグメント生成通知イベントの場合には（Ｓ１１０４でセグメント生成通知）、配信管理部３０２は、処理をＳ１１１０へ進める。発生イベントがセグメント取得要求イベントの場合には（Ｓ１１０４でセグメント取得要求）、配信管理部３０２は、処理をＳ１１２０へ進める。発生イベントが配信終了イベントの場合には（Ｓ１１０４で配信終了）、配信管理部３０２は、処理をＳ１１３０へ進める。Ｓ１００５～Ｓ１００９の処理及びＳ１０３０～Ｓ１０３２の処理は、それぞれ図７を参照しつつ説明したＳ７０６～Ｓ７０９の処理及びＳ７３０～Ｓ７３２の処理と同様である。また、Ｓ１１１０～Ｓ１１１６の処理は、それぞれ図９を参照しつつ説明した、Ｓ９１０～Ｓ９１６の処理と同様である。

Ｓ１１２０において、配信管理部３０２は、セグメント取得要求イベントにおいて要求されたセグメントが基準範囲外のタイミングを再生タイミングとするセグメントか否かを判定する。配信管理部３０２は、要求されたセグメントが基準範囲外のタイミングを再生タイミングとするセグメントである場合（Ｓ１１２０でＹＥＳ）、処理をＳ１１２１へ進める。配信管理部３０２は、要求されたセグメントが基準範囲内のタイミングを再生タイミングとするセグメントである場合（Ｓ１１２０でＮＯ）、処理をＳ１１２４へ進める。Ｓ１１２１～Ｓ１１２３の処理は、それぞれ図１０を参照しつつ説明したＳ１０２１～Ｓ１０２３の処理と同様である。

Ｓ１１２４において、配信管理部３０２は、セグメント取得要求イベントにおいて要求されたセグメントがバッファに存在するか否かを判定する。配信管理部３０２は、要求されたセグメントがバッファに存在する場合には（Ｓ１１２４でＹＥＳ）、処理をＳ１１２５へ進める。配信管理部３０２は、要求されたセグメントがバッファに存在しない場合には（Ｓ１１２４でＮＯ）、処理をＳ１１２７へ進める。Ｓ１１２５及びＳ１１２６の処理は、それぞれ図７を参照しつつ説明したＳ７２７及びＳ７２８の処理と同様である。Ｓ１１２７において、配信管理部３０２は、セグメント取得要求を保存する。配信管理部３０２は、Ｓ１１２７の処理の後、処理をＳ１１０３へ進める。なお、第４の実施形態に係る映像配信システム１００のこれ以外の構成及び処理は、他の実施形態に係る映像配信システム１００の構成及び処理と同様である。

以上のように、第３の実施形態のカメラサーバ装置１１０は、基準範囲外のタイミングのセグメントの取得要求を受信した場合には、バッファリングしているセグメントを破棄するが、エラー応答を返さない。そして、カメラサーバ装置１１０は、新たに生成されたセグメントを、セグメント取得要求に係るセグメントとして送信する。これにより、配信処理を継続することができる。

以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

１００ 映像配信システム
１１０ カメラサーバ装置
１２０ クライアント装置

Claims (14)

1. 映像データをクライアント装置に送信する映像配信装置であって、
   一連の映像データを構成する複数の区間データを再生順に生成する生成手段と、
   前記映像データを構成する複数の区間データのうち一の区間データの取得要求をクライアント装置から受信する受信手段と、
   前記取得要求に応じた区間データを前記クライアント装置に送信する送信手段と、
   を備え、
   前記送信手段は、第１の区間データの送信後でかつ前記第１の区間データに続く第２の区間データの送信前のタイミングにおいて、前記第２の区間データの再生タイミングを基準とした時間範囲に含まれないタイミングを再生タイミングとする区間データである第３の区間データの取得要求を受信した場合に、前記第３の区間データと異なる区間データであって、前記第１の区間データよりも後に生成された区間データを前記第３の区間データとして送信することを特徴とする映像配信装置。
2. 前記生成手段により生成された区間データを一時記憶領域に保存する保存手段をさらに有し、
   前記送信手段は、前記第３の区間データの取得要求を受信した場合に、前記一時記憶領域に保存されている、前記第３の区間データと異なる区間データである第４の区間データを前記第３の区間データとして送信することを特徴とする請求項１に記載の映像配信装置。
3. 前記第４の区間データのヘッダ情報を、前記第３の区間データであることを識別するヘッダ情報に書き替える再構成手段をさらに有し、
   前記送信手段は、前記再構成手段によりヘッダ情報が書き替えられた前記第４の区間データを前記第３の区間データとして送信することを特徴とする請求項２に記載の映像配信装置。
4. 前記区間データに含まれるフレームの種類に基づいて、前記第４の区間データを送信可能か否かを判定する判定手段をさらに有し、
   前記送信手段は、前記第４の区間データを送信可能でないと判定された場合に、前記第４の区間データの送信を行わず、エラー応答を前記クライアント装置に送信することを特徴とする請求項２又は３に記載の映像配信装置。
5. 前記区間データに含まれるフレームの種類に基づいて、前記第４の区間データを送信可能か否かを判定する判定手段をさらに有し、
   前記送信手段は、前記第４の区間データを送信可能でないと判定された場合に、前記第４の区間データよりも後に生成された第５の区間データを前記第３の区間データとして送信することを特徴とする請求項２又は３に記載の映像配信装置。
6. 前記送信手段は、前記第２の区間データの再生タイミングよりも後のタイミングで、かつ前記時間範囲に含まれるタイミングを再生タイミングとする区間データの取得要求を、前記第１の区間データの送信後でかつ前記第２の区間データの送信前のタイミングにおいて受信した場合に、区間データの送信を行わず、エラー応答を前記クライアント装置に送信することを特徴とする請求項１乃至５の何れか１項に記載の映像配信装置。
7. 前記送信手段は、前記第３の区間データの取得要求を受信した場合に、前記第３の区間データと異なる区間データで、前記第３の区間データの取得要求を受信した後で前記生成手段により生成された区間データを前記第３の区間データとして送信することを特徴とする請求項１に記載の映像配信装置。
8. 前記生成手段により生成された区間データを一時記憶領域に保存する保存手段と、
   前記第３の区間データの取得要求を受信した場合に、前記一時記憶領域に保存されている区間データを削除する削除手段と
   をさらに有し、
   前記送信手段は、前記削除手段により削除された区間データよりも後に生成された第６の区間データを前記第３の区間データとして送信することを特徴とする請求項１に記載の映像配信装置。
9. 前記送信手段は、前記第３の区間データの取得要求を受信した場合に、エラー応答を前記クライアント装置に送信し、前記エラー応答を送信した後で、前記第３の区間データの取得要求を再度受信した場合に、前記第６の区間データを前記第３の区間データとして送信することを特徴とする請求項８に記載の映像配信装置。
10. 前記生成手段により生成された区間データを一時記憶領域に保存する保存手段をさらに有し、
    前記時間範囲は、前記第２の区間データの再生タイミングを含み、前記第２の区間データの再生タイミングから、少なくとも前記一時記憶領域のサイズに応じた時間だけ前のタイミングを一端とする範囲であることを特徴とする請求項１乃至９の何れか１項に記載の映像配信装置。
11. 前記時間範囲は、前記第２の区間データの再生タイミングを含み、前記第２の区間データの再生タイミングから所定の時間後のタイミングを一端とする範囲であることを特徴とする請求項１乃至１０の何れか１項に記載の映像配信装置。
12. 前記受信手段は、前記クライアント装置から、通信の切断の条件を示す切断情報を受信し、
    前記切断情報に基づいて、前記時間範囲のうち前記第２の区間データの再生タイミングより後の一端となるタイミングを決定する決定手段をさらに有することを特徴とする請求項１に記載の映像配信装置。
13. 映像データをクライアント装置に送信する映像配信装置が実行する配信方法であって、
    一連の映像データを構成する複数の区間データを再生順に生成する生成ステップと、
    前記映像データを構成する複数の区間データのうち一の区間データの取得要求をクライアント装置から受信する受信ステップと、
    前記取得要求に応じた区間データを前記クライアント装置に送信する送信ステップと、を含み、
    前記送信ステップにおいては、第１の区間データの送信後でかつ前記第１の区間データに続く第２の区間データの送信前のタイミングにおいて、前記第２の区間データの再生タイミングを基準とした時間範囲に含まれないタイミングを再生タイミングとする区間データである第３の区間データの取得要求を受信した場合に、前記第３の区間データと異なる区間データであって、前記第１の区間データよりも後に生成された区間データを前記第３の区間データとして送信することを特徴とする配信方法。
14. コンピュータを、請求項１乃至１２の何れか１項に記載の映像配信装置として機能させるためのプログラム。

Images