(57)【要約】      （修正有）【課題】リアルタイムの映像を取得可能であって、サーバに負荷をかけることなく、最適化したデータ保存を可能とする監視カメラシステムを提供する。【解決手段】監視カメラシステムは、監視カメラ４００と、監視カメラにネットワークを介して接続されたサーバと、を備える。監視カメラは、受光した映像を撮像して未加工の映像データを生成する撮像部４０１と、未加工の映像データを、過去のフレームと未来のフレームの両方を参照して作成される双方向予測インターフレームを含む動画データに符号化して、サーバに送信するエンコード部４０２と、未加工の映像データからリアルタイムの映像データを作成して、サーバに送信するライブ映像生成部４０３と、を有する。【選択図】図２
2018107655.tif 000002
【特許請求の範囲】
【請求項１】
監視カメラと、
前記監視カメラにネットワークを介して接続されたサーバと、
を備え、
前記監視カメラは、
受光した映像を撮像して未加工の映像データを生成する撮像部と、
前記未加工の映像データを、過去のフレームと未来のフレームの両方を参照して作成される双方向予測インターフレームを含む動画データに符号化して、前記サーバに送信するエンコード部と、
前記未加工の映像データからリアルタイムの映像データを作成して、前記サーバに送信するライブ映像生成部と、
を有する、ことを特徴とする監視カメラシステム。
【請求項２】
前記エンコード部は、前記動画データをストリーム方式で前記サーバに送信する
ことを特徴とする請求項１に記載の監視カメラシステム。ことを特徴とする請求項１に記載の監視カメラシステム。
【請求項３】
前記エンコード部は、前記動画データからＧＯＰ単位で撮影時刻順に分割データを作成してメモリに保存し、前記サーバから分割データ要求を受け付ける毎に、前記メモリから前記サーバに１つずつ分割データを転送し、
前記サーバは、前記監視カメラから受け取る分割データを撮影時刻順に結合して動画データを作成する
ことを特徴とする請求項１に記載の監視カメラシステム。
【請求項４】
前記ライブ映像生成部は、前記サーバからライブ画像要求を受け付ける毎に、前記未加工の映像データからリアルタイムの静止画像データを切り出して前記サーバに送信する
ことを特徴とする請求項１〜３のいずれかに記載の監視カメラシステム。
【請求項５】
前記ライブ映像生成部は、前記未加工の映像データを、前記双方向予測インターフレームを含まないリアルタイムの動画データに符号化して、ストリーム方式で前記サーバに送信する
ことを特徴とする請求項１〜３のいずれかに記載の監視カメラシステム。
【請求項６】
前記ライブ映像生成部は、予め定められたスナップショット時間間隔で、前記未加工の映像データからリアルタイムの静止画像データを切り出して前記サーバに送信することを繰り返す
ことを特徴とする請求項１〜３のいずれかに記載の監視カメラシステム。
【請求項７】
前記サーバは、
前記監視カメラから受け取る静止画像データを、記憶装置に保存する一次映像保存部と、
ネットワークを介して接続された端末装置に前記静止画像データをライブ画像として送信するライブ画像送信部と、
前記端末装置から、ライブ画像からの巻き戻し要求を受け付けると、前回送信した静止画像データより一定時間分過去の時点の静止画像データを前記記憶装置から取得して、巻き戻しライブ画像として前記端末装置に送信する巻き戻しライブ画像送信部と、
前記端末装置から、巻き戻しライブ画像からの早送り要求を受け付けると、現時点の静止画像データに達するまで、前回送信した静止画像データより一定時間分未来の時点の静止画像データを前記記憶装置から取得して、早送りライブ画像として前記端末装置に送信する早送りライブ画像送信部と、
を有する、
ことを特徴とする請求項４または６に記載の監視カメラシステム。
【請求項８】
前記サーバは、前記監視カメラから受け取る動画データを、前記エンコード部での符号化に係る遅延に応じて時間調整して記憶装置に保存する二次映像保存部を有する、
ことを特徴とする請求項１〜７のいずれかに記載の監視カメラシステム。
【請求項９】
サーバにネットワークを介して接続される監視カメラであって、
受光した映像を撮像して未加工の映像データを生成する撮像部と、
前記未加工の映像データを、過去のフレームと未来のフレームの両方を参照して作成される双方向予測インターフレームを含む動画データに符号化して、前記サーバに送信するエンコード部と、
前記未加工の映像データからリアルタイムの映像データを作成して、前記サーバに送信するライブ映像生成部と、
を有する、
ことを特徴とする監視カメラ。
【請求項１０】
受光した映像を撮像して未加工の映像データを生成する撮像部と、
前記未加工の映像データを、過去のフレームと未来のフレームの両方を参照して作成される双方向予測インターフレームを含む動画データに符号化して、前記サーバに送信するエンコード部と、
前記未加工の映像データからリアルタイムの映像データを作成して、前記サーバに送信するライブ映像生成部と、
を有する監視カメラにネットワークを介して接続されるサーバであって、
前記監視カメラから受け取るリアルタイムの映像データを、記憶装置に保存する一次映像保存部と、
前記監視カメラから受け取る動画データを、前記エンコード部での符号化に係る遅延に応じて時間調整して前記記憶装置に保存する二次映像保存部と、
を備えたことを特徴とするサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、監視カメラシステムに関する。
【背景技術】
【０００２】
防犯や調査あるいは管理といった目的で、集合住宅などの建物の出入口や店頭あるいは街頭、工場や配送センターなど、監視対象となるポイントを監視カメラにより適時撮像し、カメラ映像をインターネットなどの電気通信回線を介して、ユーザ端末のモニタに送出し、監視する監視カメラシステムが知られている（たとえば、特許文献１参照）。監視カメラの業界では、リアルタイムの映像を表示することが必須の条件とされているため、ＩＰカメラ（ネットワークカメラ）の技術が発達してきた今でもなお、アナログ構成が優位となっている。
【０００３】
従来の監視カメラシステムにおいてＩＰカメラを使用する場合には、ＩＰカメラからのストリーム出力は、Ｈ．２６４のベースラインプロファイルに限定されている。これは、監視カメラシステムが、リアルタイムでの閲覧を主としている性格上、遅延の発生するハイプロファイルでのストリームを許容しないからである。なお、本明細書において「ハイプロファイル」とは、双方向予測インターフレーム（未来予測フレーム、Ｂフレームなどとも表現される）を含む動画データを意味する。ハイプロファイルは、過去のフレームと未来のフレームの両方を参照して最適化を行うため、仕組み上必ず遅延が発生する。
【０００４】
ところで、一般に、動画データをサーバに保存する場合、データ容量が膨大になるという問題や長期保存ができないという問題がある。また、大容量のサーバを多数用意する必要があり、コストがかさむという問題がある。
【０００５】
動画データの容量を減らすために、従来の監視カメラシステムでは、ベースラインプロファイルの最適化や可変レートでの容量削減を行っている。また、本件出願人は、ベースラインプロファイルの動画データをハイプロファイルに変換して保存する監視カメラシステムを既に提案している（特願２０１６−０７９４７０）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００２−７７８８２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、従来の監視カメラシステムでは、動画データの保存をベースラインプロファイルで行っているため、容量の圧縮により映像が劣化したり、可変レートの場合は瞬時の動きに映像が乱れたりするなど、仕組み自体に限界が来ている。
【０００８】
一方、ベースラインプロファイルの動画データをハイプロファイルに変換して保存する構成では、最適化したデータ保存が可能とされるものの、レコーダとなるサーバのＣＰＵリソースを使用して変換を行うため、システムにかかるコストが大きくなる傾向がある。
【０００９】
また、カメラからのストリーム出力はベースラインプロファイルに限定されていることから、ネットワークに複数台のカメラを接続すると、トラフィックが増大し、ネットワーク設計や機器への負荷が発生する。
【００１０】
本発明は、以上のような点を考慮してなされたものである。本発明の目的は、リアルタイムの映像を取得可能な監視カメラシステムであって、サーバに負荷をかけることなく、最適化したデータ保存を可能とする監視カメラシステムを提供することにある。
【課題を解決するための手段】
【００１１】
本発明に係る監視カメラシステムは、
監視カメラと、
前記監視カメラにネットワークを介して接続されたサーバと、
を備え、
前記監視カメラは、
受光した映像を撮像して未加工の映像データを生成する撮像部と、
前記未加工の映像データを、過去のフレームと未来のフレームの両方を参照して作成される双方向予測インターフレームを含む動画データに符号化して、前記サーバに送信するエンコード部と、
前記未加工の映像データからリアルタイムの映像データを作成して、前記サーバに送信するライブ映像生成部と、
を有する。
【００１２】
このような態様によれば、監視カメラのエンコード部が、未加工の映像データを、双方向予測インターフレーム（Ｂフレーム）を含む動画データに符号化してサーバに送信するため、サーバに負荷をかけることなく、最適化したデータ保存が可能となる。また、ネットワーク上を流れるデータ量が大幅に小さくなり、ネットワークトラフィックを低減することができる。これにより、ネットワーク設計や機器への負荷が低減し、ネットワーク機器を長寿命化できる。また、ネットワークに複数台のカメラを接続することが可能となる。
【００１３】
また、このような態様によれば、双方向予測インターフレーム（Ｂフレーム）を含む動画データへの符号化が、サーバのＣＰＵリソースを使用して行われるのではなく、監視カメラの内部で行われるため、サーバの負荷が低減し、システムにかかるコストを低減できる。また、サーバの負荷が低減するので、サーバ１台当たりの監視カメラの収容台数を増やすことができる。
【００１４】
また、このような態様によれば、監視カメラから送信される動画データは、双方向予測インターフレーム（Ｂフレーム）を含むことから、必然的に遅延しているものの、ライブ映像生成部が、遅延のない未加工の映像データからリアルタイムの映像データを作成してサーバに送信するため、サーバは、リアルタイムの映像を取得可能であり、リアルタイムでの閲覧という監視カメラシステムとしての必須の要件は何ら損なわれることがない。
【００１５】
本発明に係る監視カメラシステムにおいて、
前記エンコード部は、前記動画データをストリーム方式で前記サーバに送信してもよい。
【００１６】
本発明に係る監視カメラシステムにおいて、
前記エンコード部は、前記動画データからＧＯＰ単位で撮影時刻順に分割データを作成してメモリに保存し、前記サーバから分割データ要求を受け付ける毎に、前記メモリから前記サーバに１つずつ分割データを転送し、
前記サーバは、前記監視カメラから受け取る分割データを撮影時刻順に結合して動画データを作成してもよい。
【００１７】
本発明に係る監視カメラシステムにおいて、
前記ライブ映像生成部は、前記サーバからライブ画像要求を受け付ける毎に、前記未加工の映像データからリアルタイムの静止画像データを切り出して前記サーバに送信してもよい。
【００１８】
本発明に係る監視カメラシステムにおいて、
前記ライブ映像生成部は、記未加工の映像データを、前記双方向予測インターフレームを含まないリアルタイムの動画データに符号化して、ストリーム方式で前記サーバに送信してもよい。
【００１９】
本発明に係る監視カメラシステムにおいて、
前記ライブ映像生成部は、予め定められたスナップショット時間間隔で、前記未加工の映像データからリアルタイムの静止画像データを切り出して前記サーバに送信することを繰り返してもよい。
【００２０】
本発明に係る監視カメラシステムにおいて、
前記サーバは、前記監視カメラから受け取る動画データを、前記エンコード部での符号化に係る遅延に応じて時間調整して記憶装置に保存する二次映像保存部を有してもよい。
【００２１】
このような態様によれば、監視カメラから送信される動画データはエンコード部での符号化により必然的に遅延しているものの、記憶装置には遅延時間に応じて時間調整された状態で保存されるため、サーバは、端末装置から時刻を特定して過去の動画データの再生要求を受け付けた場合に、要求された時刻の動画データを記憶装置から正確に抽出して端末装置に送信することができる。
【００２２】
本発明に係る監視カメラシステムにおいて、
前記サーバは、
前記監視カメラから受け取る静止画像データを、記憶装置に保存する一次映像保存部と、
ネットワークを介して接続された端末装置に前記静止画像データをライブ画像として送信するライブ画像送信部と、
前記端末装置から、ライブ画像からの巻き戻し要求を受け付けると、前回送信した静止画像データより一定時間分過去の時点の静止画像データを前記記憶装置から取得して、巻き戻しライブ画像として前記端末装置に送信する巻き戻しライブ画像送信部と、
前記端末装置から、巻き戻しライブ画像からの早送り要求を受け付けると、現時点の静止画像データに達するまで、前回送信した静止画像データより一定時間分未来の時点の静止画像データを前記記憶装置から取得して、早送りライブ画像として前記端末装置に送信する早送りライブ画像送信部と、
を有してもよい。
【００２３】
このような態様によれば、端末装置にてライブ画像を表示しているときに、ユーザが見落とし等に気付いた場合には、端末装置からサーバに巻き戻し要求を送信することで、端末装置ではそのまま過去にさかのぼって確認することができ、また、端末装置からサーバに早送り要求を送信することで、過去から現時点までを早送りで確認することができる。
【００２４】
本発明に係る監視カメラは、
サーバにネットワークを介して接続される監視カメラであって、
受光した映像を撮像して未加工の映像データを生成する撮像部と、
前記未加工の映像データを、過去のフレームと未来のフレームの両方を参照して作成される双方向予測インターフレームを含む動画データに符号化して、前記サーバに送信するエンコード部と、
前記未加工の映像データからリアルタイムの映像データを作成して、前記サーバに送信するライブ映像生成部と、
を有する。
【００２５】
本発明に係るサーバは、
受光した映像を撮像して未加工の映像データを生成する撮像部と、
前記未加工の映像データを、過去のフレームと未来のフレームの両方を参照して作成される双方向予測インターフレームを含む動画データに符号化して、前記サーバに送信するエンコード部と、
前記未加工の映像データからリアルタイムの映像データを作成して、前記サーバに送信するライブ映像生成部と、
を有する監視カメラにネットワークを介して接続されるサーバであって、
前記監視カメラから受け取るリアルタイムの映像データを、記憶装置に保存する一次映像保存部と、
前記監視カメラから受け取る動画データを、前記エンコード部での符号化に係る遅延に応じて時間調整して前記記憶装置に保存する二次映像保存部と、
を備える。
【発明の効果】
【００２６】
本発明によれば、リアルタイムの映像を取得可能な監視カメラシステムにおいて、サーバに負荷をかけることなく、最適化したデータ保存が可能となる。
【図面の簡単な説明】
【００２７】
【図１】図１は、一実施の形態に係る監視カメラシステムの概略的な構成を示す図である。
【図２】図２は、図１に示す監視カメラシステムにおける監視カメラの概略的な構成を示す図である。
【図３】図３は、図２に示す監視カメラのエンコード部の概略的な内部構成を示すブロック図である。
【図４】図４は、図３に示すエンコード部における出力フレームの遅延と並び替えを説明するための図である。
【図５】図５は、図３に示すエンコード部の原理的な動作を説明するための図である。
【図６】図６は、図３に示すエンコード部のハードウェア構成の一例を示すブロック図である。
【図７】図７は、図３に示すエンコード部のハードウェア構成の変形例を示すブロック図である。
【図８】図８は、図１に示す監視カメラシステムにおけるサーバの概略的な構成を示す図である。
【図９】図９は、図１に示す監視カメラシステムにおける端末装置（モバイル端末）の概略的な構成を示す図である。
【図１０】図１０は、図１に示す監視カメラシステムにおける端末装置（閲覧ＰＣ）の概略的な構成を示す図である。
【図１１】図１１は、図１に示す監視カメラシステムの動作の一例を示す概略図である。
【図１２】図１２は、一実施の形態の第１の変形例に係る監視カメラの概略的な構成を示す図である。
【図１３】図１３は、一実施の形態の第２の変形例に係る監視カメラの概略的な構成を示す図である。
【図１４】図１４は、一実施の形態の第３の変形例に係る監視カメラの概略的な構成を示す図である。
【発明を実施するための形態】
【００２８】
以下に、添付の図面を参照して、本発明の実施の形態を詳細に説明する。なお、各図において同等の機能を有する構成要素には同一の符号を付し、同一符号の構成要素の詳しい説明は繰り返さない。
【００２９】
図１は、一実施の形態に係る監視カメラシステム１０の概略的な構成を示す図である。
【００３０】
図１に示すように、監視カメラシステム１０は、監視カメラ４００Ａ、４００Ｂと、サーバ１００と、端末装置２００Ａ、２００Ｂ、３００Ａ〜３００Ｃとを備えている。監視カメラ４００Ａ、４００Ｂとサーバ１００と端末装置２００Ａ、２００Ｂ、３００Ａ〜３００Ｃとは、ネットワーク５００を介して互いに接続されている。
【００３１】
ネットワーク５００は、有線回線と無線回線のいずれでもよく、回線の種類や形態は問わない。本実施の形態では、ネットワーク５００は、ＬＡＮやインターネット、Ｗｉ−Ｆｉ回線、３Ｇ／ＬＴＥ回線などの通信網から構成される。
【００３２】
本実施の形態では、監視カメラ４００Ａ、４００Ｂは、サーバ１００からライブ画像要求を受け付ける毎に、カメラ映像からリアルタイムの静止画像を作成してサーバ１００に送信する。サーバ１００は、監視カメラ４００から静止画像を取得して蓄積し、端末装置２００Ａ、２００Ｂ、３００Ａ〜３００Ｃから閲覧要求を受け付ける毎に、閲覧用の静止画像を端末装置２００Ａ、２００Ｂ、３００Ａ〜３００Ｃに送信する。図示された例では、監視カメラ４００Ａ、４００Ｂは、サーバ１００と同じＬＡＮ内に存在している。監視カメラ４００Ａ、４００Ｂとサーバ１００との通信は、ＴＣＰ／ＩＰ方式であり、確実にカメラ映像を送受信することができ、信頼性が高い。
【００３３】
端末装置２００Ａ、２００Ｂ、３００Ａ〜３００Ｃは、ユーザが使用するものであり、スマートフォン、タブレットなどのモバイル端末、ノートブックコンピュータまたはデスクトップコンピュータなどである。端末装置２００Ａ、２００Ｂ、３００Ａ〜３００Ｃは、サーバ１００と同じＬＡＮ内に存在していてもよいし、ネットワーク５００にルータ６００を介して接続されていれば、インターネットを介してサーバ１００に接続されていてもよい。
【００３４】
以下の説明では、監視カメラ４００Ａ、４００Ｂに符号４００を付してまとめて表現することがある。また、モバイル端末としての端末装置２００Ａ、２００Ｂに符号２００、閲覧ＰＣとしての端末装置３００Ａ〜３００Ｃに符号３００を付してまとめて表現することがある。
【００３５】
次に、監視カメラ４００の構成を説明する。図２は、監視カメラ４００の概略構成を示す図である。
【００３６】
図２に示すように、監視カメラ４００は、撮像部４０１と、エンコード部４０２と、ライブ映像生成部４０３と、ネットワークインターフェース４０４などの通信制御部と、を有している。これらの各部４０１〜４０４は、同一の筐体４０５に一体に収容されている。
【００３７】
図示された例では、撮像部４０１は、レンズ４０１１と、レンズ４０１１を通して受光した映像を撮像する映像データ受信部４０１２と、撮像結果に基づいて未加工の映像データ（ＲＡＷデータなどとも表現される）を生成するＲＡＷデータ生成部４０１３と、を有している。撮像部４０１の構成は、従来の監視カメラのものと同様であり、詳細な説明を省略する。
【００３８】
エンコード部４０２は、撮像部４０１に接続されており、撮像部４０１にて生成された未加工の映像データ（ＲＡＷデータ）を、過去のフレームと未来のフレームの両方を参照して作成される双方向予測インターフレーム（Ｂフレーム）を含む動画データに符号化して、ネットワークインターフェース４０４を介してサーバ１００に送信する。本実施の形態では、エンコード部４０２は、動画データをストリーム方式（ストリーミング方式ともいう）でサーバ１００に送信する。
【００３９】
図３は、エンコード部４０２の概略的な内部構成を示すブロック図である。
【００４０】
図３に示すように、エンコード部４０２は、制御回路４０２１と、フレーム内圧縮ブロック４０２２と、フレーム間圧縮ブロック４０２３と、可変長符号圧縮／フレーム並べ替えブロック４０２４と、メモリ４０２５と、を有している。
【００４１】
制御回路４０２１は、圧縮パラメータの設定など、各ブロックの制御を行う。フレーム内圧縮ブロック４０２２は、フレーム内の空間的相関関係による情報圧縮（１画面内のデータ圧縮）を行う。フレーム間圧縮ブロック４０２３は、前後のフレームとの時間的相関関係による情報圧縮を行う。可変長符号圧縮／フレーム並べ替えブロック４０２４は、出現頻度の高いデータに短い符号を割り当てることで情報を圧縮する（エントロピー符号化）とともに、符号化したフレームデータの出力の順番を並べ替える。メモリ４０２５は、双方向予測インターフレーム（Ｂフレーム）を生成するために、複数（図示された例では５フレーム）のフレームデータを蓄積する。
【００４２】
図４は、エンコード部４０２における出力フレームの遅延と並び替えを説明するための図である。
【００４３】
図４に示すように、エンコード部４０２は、ＲＡＷデータを、単独でデコーディング可能で一定時間ごとに作成されるイントラフレーム（Ｉフレーム）と、過去のフレームを参照してイントラフレームの間に複数作成される予測インターフレーム（Ｐフレーム）と、過去のフレームと未来のフレームの両方を参照して作成される双方向予測インターフレーム（Ｂフレーム）とを含む動画データに符号化する。ここで、双方向予測インターフレーム（Ｂフレーム）は、予測インターフレーム（Ｐフレーム）が確定しなければ生成できない。そのため、双方向予測インターフレーム（Ｂフレーム）を含むハイプロファイル出力は、双方向予測インターフレーム（Ｂフレーム）を含まないベースライン出力に比べて、出力までの遅延時間が長く、かつフレームの並べ替えが必要である。遅延時間が長いため、エンコード部４０２には、その期間のフレームを保持するメモリ４０２５が設けられている。
【００４４】
図５は、エンコード部４０２の原理的な動作を説明するための図である。
【００４５】
図５に示すように、エンコード部４０２は、順次入力されるＲＡＷデータのうち最初のフレームデータについては、そのままフレーム内圧縮（空間的情報圧縮）を行う（ステップＳ４１）。一方、エンコード部４０２は、２枚目以降のフレームデータについては、まず、前後のフレームのフレーム内圧縮を展開し（ステップＳ４２）、それらを参照してフレーム間圧縮（時間的情報圧縮）を行ったのち（ステップＳ４３）、フレーム内圧縮（空間的情報圧縮）を行う（ステップＳ４１）。そして、エンコード部４０２は、フレーム内圧縮されたフレームデータに対して、符号の出現頻度による圧縮（エントロピー符号化）および並び替えを行って出力する（ステップＳ４４）。
【００４６】
図６は、エンコード部４０２のハードウェア構成の一例を示すブロック図である。
【００４７】
図６に示す例では、エンコード部４０２は、エンコードＬＳＩ４１０と、インターフェースブロック４１１Ａ、４１１Ｂと、を有している。エンコードＬＳＩ４１０は、ハイプロファイルのエンコードを行うハードウェアであり、制御回路４０２１と、フレーム内圧縮ブロック４０２２と、フレーム間圧縮ブロック４０２３と、可変長符号圧縮／フレーム並べ替えブロック４０２４（図３参照）とを含んでいる。また、図示された例では、エンコードＬＳＩ４１０は、内部にメモリ４０２５を含んでいる。インターフェースブロック４１１Ａ、４１１Ｂは、データ入出力とＬＳＩの入出力とが異なる場合に変換を行う。
【００４８】
エンコードＬＳＩ４１０としては、具体的には、たとえば、ソシオネクスト社のＨ．２６４トランスレート対応メモリ内蔵トランスコーダＬＳＩ  ＭＢ８６Ｍ０ｘが用いられる。従来、このようなエンコードＬＳＩ４１０は、Ｂフレームを生成することから、必然的に遅延を発生させるため、その性格上、テレビ、ハードディスクレコーダ、パソコンなどデジタル放送の録画機能を搭載する据置き機器、またはスマートフォンやタブレット製品向けのモバイル関連機器に利用されるものであり、本件発明者らの知るかぎり、監視カメラに利用された例は存在しない。
【００４９】
なお、図６に示す例では、メモリ４０２５はエンコードＬＳＩ４１０に内蔵されていたが、これに限定されず、図７に示すように、メモリ４０２５はエンコードＬＳＩ４１０に外付けされていてもよい。
【００５０】
また、エンコード部４０２のハードウェア構成は、図６および図７に示すようなエンコードＬＳＩ４１０を用いて実装される態様に限定されず、マイコンとソフトウェアを用いて実装される態様であってもよい。
【００５１】
図２に戻って、ライブ映像生成部４０３は、撮像部４０１に接続されており、遅延のない未加工の映像データ（ＲＡＷデータ）からリアルタイムの映像データを作成して、サーバ１００に送信する。本実施の形態では、ライブ映像生成部４０３は、サーバ１００からライブ画像要求を受け付ける毎に、遅延のない未加工の映像データ（ＲＡＷデータ）からリアルタイムの静止画像データを作成して（たとえば、そのまま切り出して）、ライブ画像として、ネットワークインターフェース４０４を介してサーバ１００に送信する。なお、本明細書において「ライブ画像」とは、リアルタイムのカメラ映像を表す１枚の静止画像を意味する。
【００５２】
次に、サーバ１００の構成を説明する。図８は、サーバ１００の概略的な構成を示す図である。
【００５３】
図８に示すように、サーバ１００は、キャッシュメモリであるメモリ１０２を伴うＣＰＵ１０１やデバイスドライバなどを有する制御・演算装置と、ＤＲＡＭなどの主記憶装置やハードディスクなどの補助記憶装置を有する記憶装置１１０と、ネットワークインターフェース１０４などの通信制御装置と、表示装置としてのディスプレイ１０３と、キーボード１０５、マウス１０６などを含む入力装置と、を備えている。
【００５４】
記憶装置１１０には、一次映像フォルダ１１１と、二次映像フォルダ１１２と、プログラム１１３と、オペレーティングシステム１１４と、認証用データベースや環境設定フォルダ（図示しない）などと、が格納されている。
【００５５】
一次映像フォルダ１１１には、監視カメラ４００から受け取るリアルタイムの映像データが保存される。本実施の形態では、一次映像フォルダ１１１には、監視カメラ４００から受け取るリアルタイムの静止画像データが順次保存される。二次映像フォルダ１１２には、監視カメラ４００から受け取る動画データが、予め定められた保存単位（たとえば１０分）ごとに１つのファイルとして保存される。
【００５６】
プログラム１１３は、通常、記憶装置１１０の補助記憶装置に格納されており、実行時には主記憶装置にロードされる。認証用データベースには、ＩＤ、パスワード、各監視カメラ４００や端末装置２００、３００のポート番号とＩＰアドレス、ＩＰアドレスの無いモバイル端末２００では個体識別番号（ＵＩＤ）などが記憶されている。環境設定フォルダには、各監視カメラ４００の映像取得タイミング、各監視カメラ４００のエンコード部４０２での符号化に係る遅延時間などが予め記憶されている。
【００５７】
本実施の形態では、サーバ１００は、サーバと端末装置とが一体となっており、自らカメラ映像を表示する端末装置の役割も果たすため、また、メンテナンスや管理のため、表示装置としてのディスプレイ１０３と、入力装置としてのキーボード１０５やマウス１０６とを有している。サーバ１０９にてカメラ映像の表示を要しない場合は、表示装置としての端末機能は無くてもよい。
【００５８】
サーバ１００は、ＣＰＵ１０１が、プログラム１１３をメモリ１０２にロードして実行することにより、監視カメラ４００からのカメラ映像の取得および端末装置２００、３００へのカメラ映像の送出が可能なコンピュータの機能を実現する。ＣＰＵ１０１は、通常のコンピュータに搭載される演算処理装置であり、各種プログラムを実行し、各種制御等を行う。
【００５９】
サーバ１００は、１台のサーバであってもよいし、複数のサーバからなるサーバ群であってもよい。たとえば、二次映像フォルダ１１２について、一定期間（たとえば２４時間）経過後の動画データの保存先を、監視カメラ４００から動画データを取得するサーバとは別のサーバに設けられた二次映像フォルダ１１２としてもよい。頻繁には再生しない過去の動画データの保存先を別にすることで、サーバ１００の負荷を低減でき、さらに多くの台数のカメラを同一ネットワーク上で監視可能となる。
【００６０】
プログラム１１３は、コンピュータに、監視カメラ４００から受け取る動画データを、エンコード部４０２での符号化に係る遅延に応じて時間調整して二次映像フォルダ１１２に保存する二次映像保存機能を実現させるためのプログラムである。サーバ１００は、ＣＰＵ１０１が、プログラム１１３をメモリ１０２にロードして実行することにより、監視カメラ４００から受け取る動画データを、エンコード部４０２での符号化に係る遅延に応じて時間調整して二次映像フォルダ１１２に保存する二次映像保存部として機能する。
【００６１】
また、プログラム１１３は、コンピュータに、監視カメラ４００から受け取る静止画像データを、たとえば予め定められた閲覧期間（たとえば２４時間）、一次映像フォルダ１１１に保存する一次映像保存機能を実現させるためのプログラムである。サーバ１００は、ＣＰＵ１０１が、プログラム１１３をメモリ１０２にロードして実行することにより、監視カメラ４００から受け取る静止画像データを、たとえば予め定められた閲覧期間、一次映像フォルダ１１１に保存する一次映像保存部として機能する。なお、静止画像データの閲覧期間（一次映像フォルダ１１１での保存期間）は、予め定められている態様に限定されず、その時の記憶装置１１０の空き容量に応じて適宜設定されるようになっていてもよい。
【００６２】
また、プログラム１１３は、コンピュータに、端末装置２００、３００からのカメラ映像の再生要求を受付するカメラ映像再生要求受付機能、一次映像フォルダ１１１に保存された最新の静止画像データを、ライブ画像として端末装置２００、３００に送信するライブ画像送信機能を実現させるためのプログラムである。サーバ１００は、ＣＰＵ１０１が、プログラム１１３をメモリ１０２にロードして実行することにより、端末装置２００、３００からカメラ映像再生要求を受け付けると、一次映像フォルダ１１１に保存された最新の静止画像データを、ライブ画像として端末装置２００、３００に送信するライブ画像送信部として機能する。
【００６３】
また、プログラム１１３は、コンピュータに、端末装置２００、３００からの、ライブ画像からの巻き戻し要求を受付する巻き戻し要求受付機能、ライブ画像からの巻き戻し要求を受け付けると、前回送信した静止画像データより一定時間分過去の時点の静止画像データを一次映像フォルダ１１１から取得して、巻き戻しライブ画像として端末装置２００、３００に送信する巻き戻しライブ画像送信機能、端末装置２００、３００からの、巻き戻しライブ画像からの早送り要求を受付する早送り要求受付機能、巻き戻しライブ画像からの早送り要求を受け付けると、現時点の静止画像データに達するまで、送信した静止画像データより一定時間分未来の時点の静止画像データを一次映像フォルダ１１１から取得して、早送りライブ画像として端末装置２００、３００に送信する早送りライブ画像送信機能を実現させるためのプログラムである。サーバ１００は、ＣＰＵ１０１が、プログラム１１３をメモリ１０２にロードして実行することにより、端末装置２００、３００から、ライブ画像からの巻き戻し要求を受け付けると、前回送信した静止画像データより一定時間分過去の時点の静止画像データを一次映像フォルダ１１１から取得して、巻き戻しライブ画像として端末装置２００、３００に送信する巻き戻しライブ画像送信部と、端末装置２００、３００から、巻き戻しライブ画像からの早送り要求を受け付けると、現時点の静止画像データに達するまで、前回送信した静止画像データより一定時間分未来の時点の静止画像データを一次映像フォルダ１１１から取得して、早送りライブ画像として端末装置２００、３００に送信する早送りライブ画像送信部と、して機能する。
【００６４】
また、プログラム１１３は、コンピュータに、端末装置２００、３００から過去の動画データの再生を受付する過去動画再生受付機能、受付した過去の動画データを二次映像フォルダ１１２から抽出し、抽出した動画データを端末装置２００、３００に送信する過去動画送信機能を実現させるためのプログラムである。
【００６５】
また、プログラム１１３は、コンピュータに、１または複数台の監視カメラ４００との接続を行う監視カメラ接続機能、１または複数台の端末装置２００、３００との接続を行う端末装置接続機能を実現させるためのプログラムである。
【００６６】
本実施の形態では、監視カメラ４００とサーバ１００との接続は、ＴＣＰ／ＩＰ方式で行い、接続すべき監視カメラ４００を特定するため、サーバ１００側で設定したユーザＩＤとパスワードで認証を行ってから、カメラ映像の取得などの要求を行う。端末装置２００、３００とサーバ１００との接続もＴＣＰ／ＩＰ方式で行い、ユーザＩＤとパスワードで認証を行って、端末装置２００、３００がサーバ１００に登録してある端末装置であることを確認してから、カメラ映像の送信を行う。認証は、サーバ１００上の認証用データベースによる認証が好ましい。
【００６７】
端末装置２００、３００や監視カメラ４００が同じＬＡＮ内に存在しなくても、ルータ６００を介してネットワーク５００で繋がっていれば、接続するルータ６００のＩＰアドレスとそれぞれに割り振られたポート番号にて特定が行われる。インターネットで接続されているときは、両者の間のルータ６００のポート番号が「有効」にされる。ＩＰアドレスのないモバイル端末２００ではＵＩＤが利用される。
【００６８】
本実施の形態では、監視カメラ４００からサーバ１００への動画データの送信は、ＴＣＰ／ＩＰベースのＲＴＳＰ（リアルストリーミングプロトコル）で行われる。本実施の形態では、動画データはＨ．２６４のハイプロファイルで圧縮して送信されるが、Ｈ．２６５等、次世代コーディックのハイプロファイルが用いられてもよい。
【００６９】
次に、モバイル端末としての端末装置２００の構成を説明する。図９は、端末装置２００の概略構成を示す図である。
【００７０】
図９に示すように、端末装置２００は、メモリ２０２を伴うＣＰＵ２０１やデバイスドライバなどを有する制御・演算装置と、記憶装置２１０と、データの送受信などを行う通信制御装置（図示しない）と、表示装置としてのディスプレイ２０４と、操作ボタンあるいはタッチパネルなどの出力装置（図示しない）とを備えている。記憶装置２１０には、画像表示のためのプログラム２１３やオペレーティングシステム２１４が格納されている。
【００７１】
端末装置２００は、たとえばスマートフォンなどの携帯電話などであり、ＣＰＵ２０１がプログラム２１３をメモリ２０２にロードして実行することにより、サーバ１００から送信されたカメラ映像の表示が可能なコンピュータの機能を実現する。ＣＰＵ２０１は、通常のモバイル端末に搭載される演算処理装置であり、各種プログラムを実行し、各種制御などを行う。
【００７２】
次に、閲覧ＰＣとしての端末装置３００の構成を説明する。図１０は、端末装置３００の概略構成を示す図である。
【００７３】
図１０に示すように、端末装置３００は、メモリ３０２を伴うＣＰＵ３０１やデバイスドライバなどを有する制御・演算装置と、ＤＲＡＭなどの主記憶装置やハードディスクなどの補助記憶装置を有する記憶装置３１０と、ネットワークインターフェース３０４などの通信制御装置と、表示装置としてのディスプレイ３０３と、キーボード３０５、マウス３０６などの出力装置と、を有している。記憶装置３１０には、画像表示のためのプログラム３１３やオペレーティングシステム３１４が格納されている。
【００７４】
端末装置３００は、たとえばデスクトップコンピュータやノートブックコンピュータ、タブレット端末などであり、ＣＰＵ３０１がプログラム３１３をメモリ３０２にロードして実行することにより、サーバ１００から送信されたカメラ映像の表示が可能なコンピュータの機能を実現する。ＣＰＵ３０１は、通常のＰＣに搭載される演算処理装置であり、各種プログラムを実行し、各種制御を行う。
【００７５】
画像表示のためのプログラム２１３、３１３は、コンピュータに、サーバ１００との接続を行うサーバ接続機能、監視権限のある１または複数台の監視カメラ４００に係るカメラ映像の再生をサーバ１００に要求するカメラ映像再生要求機能、サーバ１００から送信されたカメラ映像を表示するカメラ映像表示機能を実現させるためのプログラムである。
【００７６】
サーバ１００は、ローカル環境にある監視カメラ４００との接続開始時にＩＰアドレスおよびポート番号を用いた接続によって接続相手を特定し、ユーザＩＤとパスワードで認証する。サーバ１００は、遠隔環境にある監視カメラ４００との接続では、ルータ６００のポート転送（ポートフォワーディングなどとも表現される）を用いることで、グローバルＩＰアドレスおよびポート番号を用いて接続相手を特定する。サーバ１００は、端末装置２００との接続開始時にＵＩＤを用いた端末固有情報をもとに端末装置２００を特定するため、ユーザＩＤとパスワードの認証および端末固有情報の一致によりカメラ映像の表示を可能とする。
【００７７】
本実施の形態では、サーバ１００と閲覧ＰＣとしての端末装置３００とは、ともにパーソナルコンピュータとして構成され、通常のパーソナルコンピュータが有するクロック機能などを備えている。モバイル端末としての端末装置２００および監視カメラ４００もクロック機能などを備えている。
【００７８】
次に、このような構成からなる監視カメラシステム１０の動作の一例について、図１１を参照して説明する。図１１は、監視カメラシステム１０の動作の一例を示す概略図である。なお、図１１に示す例では、モバイル端末としての端末装置２００が図示されているが、閲覧ＰＣとしての端末装置３００に置き換えても動作は同様である。
【００７９】
図１１を参照し、まず、サーバ１００は、監視カメラ４００にＴＣＰ／ＩＰ方式で接続を要求する。監視カメラ４００は１または複数台の監視カメラで構成され、監視カメラ４００とサーバ１００とはユーザＩＤおよびパスワードで認証を行う。サーバ１００の認証用データベースが参照され、認証が成功すると、監視カメラ４００とサーバ１００とは接続状態となる。
【００８０】
次に、サーバ１００は、監視カメラ４００にカメラ映像を撮像して送信することを要求する。監視カメラ４００は、サーバ１００からの映像要求を受け付けると、カメラ映像を連続して撮像し、撮像して得られた未加工の映像データ（ＲＡＷデータ）をＨ．２６４のハイプロファイルの動画データに符号化する。より詳しくは、監視カメラ４００は、ＲＡＷデータを、単独でデコーディング可能で一定時間ごとに作成されるイントラフレーム（Ｉフレーム）と、過去のフレームを参照してイントラフレームの間に複数作成される予測インターフレーム（Ｐフレーム）と、過去のフレームと未来のフレームの両方を参照して作成される双方向予測インターフレーム（Ｂフレーム）とを含む動画データに符号化する。そして、監視カメラ４００は、符号化した動画データをストリーム方式でサーバ１００に送信する。
【００８１】
また、サーバ１００は、予め定められたスナップショット時間間隔で、監視カメラ４００にライブ画像要求を送信することを繰り返す。スナップショット時間間隔は、予め任意で設定されており、たとえば１０分の１秒、１秒、３秒あるいは６０秒などである。以下に説明する実施例では、スナップショット時間間隔を１秒とする。監視カメラ４００は、サーバ１００からライブ画像要求を受け付ける毎に、未加工の映像データ（ＲＡＷデータ）からリアルタイムの静止画像データを作成し（切り出し）、ライブ画像としてサーバ１００に送信する。
【００８２】
サーバ１００は、監視カメラ４００からストリーム方式で動画データを取得すると、保存単位（たとえば１０分）ごとに１つのファイルとして二次映像フォルダ１１２に格納する。これにより、過去の動画データの再生は動画データ保存後（たとえば１０分後）から受付可能となる。
【００８３】
本実施の形態では、サーバ１００は、監視カメラ４００から受け取る動画データを、エンコード部４０２での符号化に係る遅延に応じて時間調整して二次映像フォルダ１１２に保存する。たとえば、監視カメラ４００から送信される動画データが、動画データと同時に送信されるリアルタイムの静止画像データに対して１分遅延している場合には、サーバ１００は、たとえば９：５１：００〜１０：００：５９に受け取る動画データに、９：５０：００〜９：５９：５９のタイムスタンプを付して１つのファイルとして二次映像フォルダ１１２に保存する。
【００８４】
また、サーバ１００は、監視カメラ４００からライブ画像としての静止画像データを取得すると、予め定められた閲覧期間（たとえば２４時間）は、頻繁に見る可能性がある高解像度のデータとして一次映像フォルダ１１１に保存し、閲覧期間を過ぎると、一次映像フォルダ１１１から削除する。
【００８５】
端末装置２００は、ユーザによるサーバ１００への接続要求を受付ける。サーバ１００への接続要求が端末装置２００に入力されると、端末装置２００は、サーバ１００にＴＣＰ／ＩＰ方式で接続を要求する。モバイル端末２００では、部分的に携帯電話独自のプロトコルを使用して接続することもある。端末装置２００は、１または複数台の端末装置で構成され、端末装置２００とサーバ１００とはユーザＩＤおよびパスワードで認証を行う。サーバ１００の認証用データベースが参照され、端末装置２００の認証登録がされていない場合は、初回のみ暗号化キーを発行して登録が行われ、登録時にユーザＩＤとパスワードが発行される。認証が成功すると、端末装置２００とサーバ１００とは接続状態となる。
【００８６】
端末装置２００は、ユーザからのカメラ一覧要求を受け付ける。端末装置２００は、カメラ一覧要求が入力されると、サーバ１００にカメラ一覧要求を送信する。サーバ１００は、カメラ一覧要求を受信すると、要求した端末装置２００が監視できる監視カメラ４００についての権限情報を確認する。サーバ１００は、権限のあるカメラ一覧データを端末装置２００に送信する。端末装置２００は、受信したカメラ一覧データをディスプレイ２０３に表示し、ライブ再生させるべき監視カメラについてのユーザからの選択を受け付ける。
【００８７】
端末装置２００は、ユーザからの監視カメラの選択が入力されると、選択された監視カメラについてカメラ映像のライブ再生をサーバ１００に要求する。サーバ１００は、ライブ再生の要求を受け付けると、選択された監視カメラ４００から取得して一次映像フォルダ１１１に保存された最新の静止画像データを、ライブ画像として端末装置２００へ送信する。
【００８８】
端末装置２００は、サーバ１００から受け取る静止画像データを、ライブ画像としてディスプレイ２０３に表示する。ユーザによって監視カメラの選択が解除されるまで、あるいはライブ再生以外が選択されている間を除き、端末装置２００は、監視カメラ４００におけるスナップショット時間間隔と同じ時間間隔で、ライブ再生の要求を繰り返す。
【００８９】
端末装置２００は、ライブ画像の表示中に、ユーザからの巻き戻し要求の入力を受け付ける。端末装置２００は、ユーザから巻き戻し要求が入力されると、サーバ１００に巻き戻し画像を要求する。
【００９０】
サーバ１００は、巻き戻し画像の要求を受信すると、前回送信した静止画像データより一定時間分過去の時点の静止画像データを、一次映像フォルダ１１１から抽出し、巻き戻しライブ画像として端末装置２００へ送信する。本実施例では、一定時間分過去の時点を１秒分過去の時点とし、ライブ画像が１秒ごとに取得した静止画像データであるので、最初に巻き戻し要求が入力されたときは、１枚前の静止画像データが端末装置２００に送信される。
【００９１】
巻き戻しが選択されている間中、すなわち、巻き戻しライブ画像の表示中は、端末装置２００は、サーバ１００に、一定時間ごとに巻き戻しライブ画像を要求する。その際の一定時間は、ライブ画像の要求間隔より短い一定時間であって、たとえば０．２秒ごとである。したがって。端末装置２００には、０．２秒ごとに、１秒ずつ前のカメラ映像の静止画像データから作成された巻き戻しライブ画像が表示されることになる。
【００９２】
さらに、端末装置２００は、巻き戻しライブ画像の表示中に、ユーザからの早送り要求の入力を受け付ける。端末装置２００は、早送り要求が入力されると、サーバ１００に早送りライブ画像を要求する。サーバ１００は、早送りライブ画像の要求を受信すると、前回送信した静止画像データより一定時間分未来の時点の静止画像データを、一次映像フォルダ１１１から抽出し、早送りライブ画像として端末装置２００に送信する。本実施の形態では、一定時間分未来の時点を１秒分未来の時点とし、ライブ画像が１秒ごとに取得した画像であるので、最初に早送り要求が入力されたときは、巻き戻しライブ画像として現在表示されている静止画像データより、１秒未来の静止画像データが送信される。
【００９３】
早送りが選択されている間中、すなわち、早送りライブ画像の表示中は、端末装置２００は、サーバ１００に、一定時間ごとに早送りライブ画像を要求する。その際の一定時間は、ライブ画像の要求間隔より短い一定時間であって、たとえば０．２秒ごとである。したがって、端末装置２００には、０．２秒ごとに、１秒ずつ後のカメラ映像の静止画像データから作成された早送りライブ画像が表示されることになる。早送りライブ画像が現時点の画像までたどり着いたら、ライブ画像表示に切り替わり、早送りは終了する。
【００９４】
さらに、端末装置２００は、巻き戻しライブ画像の表示中に、ユーザからのリライブ再生要求の入力を受け付ける。本明細書において「リライブ」とは、ライブ以外の蓄積された静止画像のデータを意味する。端末装置２００は、リライブ再生要求が入力されると、サーバ１００にリライブ再生を要求する。サーバ１００は、リライブ再生の要求を受信すると、前回送信した画像より一定時間分未来の時点の静止画像データを、一次映像フォルダ１１１から抽出し、リライブ画像として端末装置２００に送信する。本実施の形態では、一定時間分未来の時点を１秒分未来の時点とし、ライブ画像が１秒ごとに取得した画像であるので、最初にリライブ再生の要求が入力されたときは、リライブ画像として現在表示されている静止画像データより、１枚未来の静止画像データが送信される。
【００９５】
リライブ再生が選択されている間中、すなわち、リライブ画像の表示中は、端末装置２００は、サーバ１００に、一定時間ごとにリライブ再生を要求する。その際の一定時間は、ライブ画像の要求間隔と同じ一定時間であって、本実施例では１秒ごとである。したがって、端末装置２００には、１秒ごとに、１秒ずつ後の静止画像データが表示されることになる。リライブ再生以外が選択されると、リライブ画像表示は終了する。
【００９６】
ライブ再生に代えて、過去の動画データの再生も同様に行うことができる。サーバ１００は、静止画像データの代わりに、受付した過去の動画データを、二次映像フォルダ１１２から抽出し、抽出した動画データを端末装置２００に送信して表示させる。
【００９７】
静止画像データは、画像であって端末装置２００に連続して送信できるほど軽く、また、動画データも、ハイプロファイルで符号化されていて、動画でありながらデータ量が極めて小さいため、端末装置２００に送信できるほど軽い。また、静止画像データも、動画データも、ともに、巻き戻し、巻き戻してからの再生や早送りが可能であり、利便性が高い。
【００９８】
ところで、発明が解決しようとする課題の欄でも言及したように、従来の監視カメラシステムでは、動画データの保存をベースラインプロファイルで行っているため、容量の圧縮により映像が劣化したり、可変レートの場合は瞬時の動きに映像が乱れたりするなど、仕組み自体に限界が来ていた。
【００９９】
また、ベースラインプロファイルの動画データをハイプロファイルに変換して保存する構成では、最適化したデータ保存が可能とされるものの、レコーダとなるサーバのＣＰＵリソースを使用して変換を行うため、システムにかかるコストが大きくなる傾向があった。
【０１００】
また、カメラからのストリーム出力はベースラインプロファイルに限定されていることから、ネットワークに複数台のカメラを接続すると、トラフィックが増大し、ネットワーク設計や機器への負荷が発生していた。
【０１０１】
これに対し、本実施の形態によれば、監視カメラ４００のエンコード部４０２が、未加工の映像データを、双方向予測インターフレーム（Ｂフレーム）を含む動画データに符号化してサーバに送信するため、サーバに負荷をかけることなく、最適化したデータ保存が可能となる。また、ネットワーク５００上を流れるデータ量が大幅に小さくなり、ネットワークトラフィックを低減することができる。これにより、ネットワーク設計や機器への負荷が低減し、ネットワーク機器を長寿命化できる。また、ネットワーク５００に複数台の監視カメラ４００を接続することが可能となる。
【０１０２】
また、本実施の形態によれば、双方向予測インターフレーム（Ｂフレーム）を含む動画データへの符号化が、サーバ１００のＣＰＵリソースを使用して行われるのではなく、監視カメラ４００の内部で行われるため、サーバ１００の負荷が低減し、システムにかかるコストを低減できる。また、サーバ１００の負荷が低減するので、サーバ１台当たりの監視カメラ４００の収容台数を増やすことができる。
【０１０３】
また、本実施の形態によれば、監視カメラ４００から送信される動画データは、双方向予測インターフレーム（Ｂフレーム）を含むことから、必然的に遅延しているものの、ライブ映像生成部４０３が、遅延のない未加工の映像データからリアルタイムの映像データを作成してサーバ１００に送信するため、サーバ１００は、リアルタイムの映像を取得可能であり、リアルタイムでの閲覧という監視カメラシステムとしての必須の要件は何ら損なわれることがない。
【０１０４】
また、本実施の形態によれば、監視カメラ４００から送信される動画データはエンコード部４０２での符号化により必然的に遅延しているものの、二次映像フォルダ１１２には遅延に応じて時間調整された状態で保存されるため、サーバ１００は、端末装置２００から時刻を特定して過去の動画データの再生要求を受け付けた場合に、要求された時刻の動画データを二次映像フォルダ１１２から正確に抽出して端末装置２００に送信することができる。
【０１０５】
また、本実施の形態によれば、端末装置２００にてライブ画像を表示しているときに、ユーザが見落とし等に気付いた場合には、端末装置２００からサーバ１００に巻き戻し要求を送信することで、端末装置２００ではそのままさかのぼって確認することができ、また、端末装置２００からサーバ１００に早送り要求を送信することで、過去から現時点までを早送りで確認することができる。
【０１０６】
なお、上述した実施の形態に対して様々な変更を加えることが可能である。以下、図面を参照しながら、変形の一例について説明する。以下の説明および以下の説明で用いる図面では、上述した実施の形態と同様に構成され得る部分について、上述した実施の形態における対応する部分に対して用いた符号と同一の符号を用いるとともに、重複する説明を省略する。
【０１０７】
（第１の変形例）
第１の変形例について、図１２を参照して説明する。図１２は、第１の変形例に係る監視カメラ４００の概略的な構成を示す図である。
【０１０８】
図１２に示すように、第１の変形例では、監視カメラ４００のエンコード部４０２Ｂは、撮像部４０１にて生成された未加工の映像データ（ＲＡＷデータ）を、Ｂフレームを含む動画データ（たとえば、Ｈ．２６４のハイプロファイルの動画データ）に符号化したのち、動画データからＩフレームが先頭の画像となるＧＯＰ単位（たとえば１秒分）で、撮影時刻順に分割データを作成してメモリ４０２５に保存する。
【０１０９】
なお、ＧＯＰ（Ｇｒｏｕｐ  Ｏｆ  Ｐｉｃｔｕｒｅ）は、１つ以上のＩフレーム（イントラフレーム）と複数のＰフレーム（予測インターフレーム）およびＢフレーム（双方向予測インターフレーム）からなるフレーム群である。エンコード部４０２は、たとえば、動画データからＩフレームを検出すると、次のＩフレームを検出した直前のフレームまでを１つの分割データとする。この場合、１つの分割データが１つのＩフレームを含むことになる。なお、１つの分割データが２つ以上のＩフレームを含んでもよい。
【０１１０】
また、監視カメラ４００のエンコード部４０２Ｂは、サーバ１００から分割データ要求を受け付ける毎に、メモリ４０２５からサーバ１００に１つずつ分割データを転送する。
【０１１１】
一方、サーバ１００は、監視カメラ４００に分割データ要求を送信して分割データを受け取ることを繰り返す。そして、サーバ１００は、監視カメラ４００から受け取る分割データを撮影時刻順に結合して、保存単位（たとえば１０分）ごとに１つのファイルの動画データを作成し、二次映像フォルダ１１２に保存する。
【０１１２】
以上のような第１の変形例によれば、たとえばクラウド環境にサーバ１００を設置して遠隔地の監視カメラ４００から映像データをサーバ１００に転送する際に、後で元の映像を復元可能な容量が小さい単位に分割して、ネットワーク５００の混雑を回避しつつ送信できるので、クラウド環境で安定的なカメラ映像の収集が可能となる。
【０１１３】
（第２の変形例）
第２の変形例について、図１３を参照して説明する。図１３は、第２の変形例に係る監視カメラ４００の概略的な構成を示す図である。
【０１１４】
図１３に示すように、第２の変形例では、監視カメラ４００のライブ映像生成部４０３Ｂは、未加工の映像データ（ＲＡＷデータ）を、双方向予測インターフレーム（Ｂフレーム）を含まないリアルタイムの動画データ、すなわち単独でデコーディング可能で一定時間ごとに作成されるイントラフレーム（Ｉフレーム）と、過去のフレームを参照してイントラフレームの間に複数作成される予測インターフレーム（Ｐフレーム）とから構成されるベースラインプロファイルの動画データに符号化して、ストリーム方式でサーバ１００に送信する。
【０１１５】
第２の変形例によっても、上述した実施の形態と同様に、監視カメラ４００のエンコード部４０２が未加工の映像データを、双方向予測インターフレーム（Ｂフレーム）を含む動画データに符号化してサーバ１００に送信するため、サーバ１００に負荷をかけることなく最適化したデータ保存が可能となるとともに、ライブ映像生成部４０３が、遅延のない未加工の映像データからリアルタイムの映像データを作成してサーバ１００に送信するため、サーバ１００はリアルタイムの映像を取得可能であり、リアルタイムでの閲覧という監視カメラシステムとしての必須の要件は何ら損なわれることがない。
【０１１６】
なお、第２の変形例によれば、監視カメラ４００がリアルタイムの映像をストリーム方式で送出するので、上述した実施の形態に比べてネットワーク５００のトラフィックが増える可能性があるものの、ローカル環境であれば問題にならない。
【０１１７】
（第３の変形例）
第３の変形例について、図１４を参照して説明する。図１４は、第３の変形例に係る監視カメラ４００の概略的な構成を示す図である。
【０１１８】
図１４に示すように、第３の変形例では、監視カメラ４００のライブ映像生成部４０３Ｃは、タイマー４０９などに予め定められたスナップショット時間間隔（たとえば、１秒ごと）で、未加工の映像データ（ＲＡＷデータ）からリアルタイムの静止画像データを切り出してサーバ１００に送信することを繰り返す。監視カメラ４００からサーバ１００への静止画像データの転送では、ＦＴＰ、ＨＴＴＰなどのＴＣＰ／ＩＰベースの転送方式が用いられる。
【０１１９】
第３の変形例によっても、上述した実施の形態と同様に、監視カメラ４００のエンコード部４０２が未加工の映像データを、双方向予測インターフレーム（Ｂフレーム）を含む動画データに符号化してサーバ１００に送信するため、サーバ１００に負荷をかけることなく最適化したデータ保存が可能となるとともに、ライブ映像生成部４０３が、遅延のない未加工の映像データからリアルタイムの映像データを作成してサーバ１００に送信するため、サーバ１００はリアルタイムの映像を取得可能であり、リアルタイムでの閲覧という監視カメラシステムとしての必須の要件は何ら損なわれることがない。
【０１２０】
なお、上述した実施の形態および個々の変形例の記載ならびに図面の開示は、特許請求の範囲に記載された発明を説明するための一例に過ぎず、上述した実施の形態および個々の変形例の記載または図面の開示によって特許請求の範囲に記載された発明が限定されることはない。上述した実施の形態および個々の変形例の構成要素は、発明の主旨を逸脱しない範囲で任意に組み合わせることが可能である。
【符号の説明】
【０１２１】
１０      監視カメラシステム
１００    サーバ
１０１    ＣＰＵ
１０２    メモリ
１０３    ディスプレイ
１０４    ネットワークインターフェース
１０５    キーボード
１０６    マウス
１１０    記憶装置
１１１    一次映像フォルダ
１１２    二次映像フォルダ
１１３    プログラム
１１４    オペレーティングシステム
２００、２００Ａ、２００Ｂ    端末装置（モバイル端末）
２０１    ＣＰＵ
２０２    メモリ
２０３    ディスプレイ
２１０    記憶装置
２１３    プログラム
２１４    オペレーティングシステム
３００、３００Ａ、３００Ｂ、３００Ｃ  端末装置（閲覧用ＰＣ）
３０１    ＣＰＵ
３０２    メモリ
３０３    ディスプレイ
３０４    ネットワークインターフェース
３０５    キーボード
３０６    マウス
３１０    記憶装置
３１３    プログラム
３１４    オペレーティングシステム
４００、４００Ａ、４００Ｂ    監視カメラ
４０１    撮像部
４０１１  レンズ
４０１２  映像データ受信部
４０１３  ＲＡＷデータ生成部
４０２、４０２Ｂ    エンコード部
４０２１  制御回路
４０２２  フレーム内圧縮ブロック
４０２３  フレーム間圧縮ブロック
４０２４  可変長符号圧縮／フレーム並べ替えブロック
４０２５  メモリ
４０３、４０３Ｂ、４０３Ｃ    ライブ映像生成部
４０４    情報通信部
４０５    筐体
４０９    タイマー
４１０    エンコードＬＳＩ
４１１Ａ、４１１Ｂ    インターフェースブロック
５００    ネットワーク
６００    ルータ
【図１】
2018107655.tif 000003
【図２】
2018107655.tif 000004
【図３】
2018107655.tif 000005
【図４】
2018107655.tif 000006
【図５】
2018107655.tif 000007
【図６】
2018107655.tif 000008
【図７】
2018107655.tif 000009
【図８】
2018107655.tif 000010
【図９】
2018107655.tif 000011
【図１０】
2018107655.tif 000012
【図１１】
2018107655.tif 000013
【図１２】
2018107655.tif 000014
【図１３】
2018107655.tif 000015
【図１４】
2018107655.tif 000016