知財求人 - 知財ポータルサイト「IP Force」
▶ 三菱電機インフォメーションネットワーク株式会社の特許一覧
特許7104819映像データ送信装置、映像データ送信プログラムおよび映像データ送信方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2022-07-12
(45)【発行日】2022-07-21
(54)【発明の名称】映像データ送信装置、映像データ送信プログラムおよび映像データ送信方法
(51)【国際特許分類】
H04N 21/238 20110101AFI20220713BHJP
H04N 21/24 20110101ALI20220713BHJP
【ＦＩ】
H04N21/238
H04N21/24
【請求項の数】
6
(21)【出願番号】P 2021008205
(22)【出願日】2021-01-21
【審査請求日】2021-01-21
(73)【特許権者】
【識別番号】501158538
【氏名又は名称】三菱電機インフォメーションネットワーク株式会社
(74)【代理人】
【識別番号】110002491
【氏名又は名称】溝井国際特許業務法人
(72)【発明者】
【氏名】下島 明久
【審査官】益戸 宏
(56)【参考文献】
【文献】特開２０２１－１９７５８４（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｎ ２１／００－２１／８５８
(57)【特許請求の範囲】
【請求項1】
記憶領域として複数のチャンク領域が設定されているセグメントファイルの各チャンク領域に、ネットワークカメラの撮影した映像データであるフレームを、指定されている指定枚数だけ順番に格納するファイル作成部と、前記チャンク領域に前記指定枚数の前記フレームが格納されているかを確認する時間間隔を示すチャンク応答間隔を前記フレームのフレームレイトに基づいて決定し、前記ファイル作成部によって前記指定枚数の前記フレームが新たに格納された前記チャンク領域である格納チャンク領域が存在するかどうかを、決定された前記チャンク応答間隔が経過するたびに確認し、前記格納チャンク領域が存在する場合には、前記格納チャンク領域に格納された指定枚数のフレームを１チャンクとして、前記映像データを要求する要求装置に送信する応答部と、
を備える映像データ送信装置。
【請求項2】
前記応答部は、前記フレームレイトに加えて、前記指定枚数に基づいて、前記チャンク応答間隔を決定する請求項１に記載の映像データ送信装置。
【請求項3】
前記応答部は、前記フレームレイトを示す値の逆数と、前記指定枚数とに基づいて、前記チャンク応答間隔を決定する請求項２に記載の映像データ送信装置。
【請求項4】
前記映像データ送信装置は、さらに、前記複数のチャンク領域に格納される複数のフレームを前記ネットワークカメラから取得し、取得した前記複数のフレームから前記フレームレイトを算出する映像取得部を備え、
前記応答部は、
前記映像取得部が算出した前記フレームレイトを用いて前記チャンク応答間隔を決定する請求項１から請求項３のいずれか１項に記載の映像データ送信装置。
【請求項5】
コンピュータに、記憶領域として複数のチャンク領域が設定されているセグメントファイルの各チャンク領域に、ネットワークカメラの撮影した映像データであるフレームを、指定されている指定枚数だけ順番に格納するフレーム格納処理と、
前記チャンク領域に前記指定枚数の前記フレームが格納されているかを確認する時間間隔を示すチャンク応答間隔を前記フレームのフレームレイトに基づいて決定し、前記フレーム格納処理によって前記指定枚数の前記フレームが新たに格納された前記チャンク領域である格納チャンク領域が存在するかどうかを、決定された前記チャンク応答間隔が経過するたびに確認し、前記格納チャンク領域が存在する場合には、前記格納チャンク領域に格納された指定枚数のフレームを１チャンクとして、前記映像データを要求する要求装置に送信する応答処理と、
を実行させる映像データ送信プログラム。
【請求項6】
コンピュータが、記憶領域として複数のチャンク領域が設定されているセグメントファイルの各チャンク領域に、ネットワークカメラの撮影した映像データであるフレームを、指定されている指定枚数だけ順番に格納し、
前記チャンク領域に前記指定枚数の前記フレームが格納されているかを確認する時間間隔を示すチャンク応答間隔を前記フレームのフレームレイトに基づいて決定し、前記指定枚数の前記フレームが新たに格納された前記チャンク領域である格納チャンク領域が存在するかどうかを、決定された前記チャンク応答間隔が経過するたびに確認し、前記格納チャンク領域が存在する場合には、前記格納チャンク領域に格納された指定枚数のフレームを１チャンクとして、前記映像データを要求する要求装置に送信する映像データ送信方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、ライブ映像を送信する映像データ送信装置、映像データ送信装置に使用する映像データ送信プログラム、映像データ送信装置が実施する映像データ送信方法に関する。
【背景技術】
【0002】
モバイル端末およびＷｅｂブラウザでの映像配信には、ＨＬＳ（ＨＴＴＰ Ｌｉｖｅ Ｓｔｒｅａｍｉｎｇ）およびＭＰＥＧ－ＤＡＳＨという方式がある。これらの方式では、一般的に１０秒から３０秒程度の遅延が発生する。この遅延を軽減する方式として、ＣＭＡＦ（Ｃｏｍｍｏｎ Ｍｅｄｉａ Ａｐｐｌｉｃａｔｉｏｎ Ｆｏｒｍａｔ））と呼ばれる技術がある。ＣＭＡＦ方式では、一つの映像セグメントファイル内にｃｈｕｎｋと呼ばれる区切りを設け、ｃｈｕｎｋ単位でクライアント端末に映像データを送ることで遅延を軽減する。
【0003】
しかし、ＣＭＡＦ方式では、セグメントファイルが未完成な状態で順次ｃｈｕｎｋ単位の映像データを応答するため、セグメントファイルが完成しているか未完成であるかを映像配信サーバが確認する必要がある。セグメントファイルが完成状態かを必要以上に確認する場合には映像配信サーバに負荷がかかり、一方、確認間隔を開けすぎると、その分映像配信に遅延が発生する。
【0004】
従来技術にはＨＴＴＰ応答によって発生する映像配信の遅延対策に関する技術の開示はあるが（例えば特許文献１）、ライブ映像の配信において、配信遅延の低減と、セグメントファイルの完成状態確認の負荷とのバランスのとれた映像配信サーバの提供に関する開示はない。
【先行技術文献】
【特許文献】
【0005】
【文献】国際公開第２０１４／０５７８９６号パンフレット
【発明の概要】
【発明が解決しようとする課題】
【0006】
本開示は、ライブ映像の配信において、配信の遅延低減と、セグメントファイルの完成状態確認の負荷低減との、双方のバランスのとれた映像配信サーバを提供することを目的とする。
【課題を解決するための手段】
【0007】
本開示に係る映像配信サーバは、
記憶領域として複数のチャンク領域が設定されているセグメントファイルの各チャンク領域に、ネットワークカメラの撮影した映像データであるフレームを、指定されている指定枚数だけ順番に格納するファイル作成部と、
前記チャンク領域に前記指定枚数の前記フレームが格納されているかを確認する時間間隔を示すチャンク応答間隔を前記フレームのフレームレイトに基づいて決定し、前記ファイル作成部によって前記指定枚数の前記フレームが新たに格納された前記チャンク領域である格納チャンク領域が存在するかどうかを、決定された前記チャンク応答間隔が経過するたびに確認し、前記格納チャンク領域が存在する場合には、前記格納チャンク領域に格納された指定枚数のフレームを１チャンクとして、前記映像データを要求する要求装置に送信する応答部と、
を備える。
記憶領域として複数のチャンク領域が設定されているセグメントファイルの各チャンク領域に、ネットワークカメラの撮影した映像データであるフレームを、指定されている指定枚数だけ順番に格納するファイル作成部と、
前記チャンク領域に前記指定枚数の前記フレームが格納されているかを確認する時間間隔を示すチャンク応答間隔を前記フレームのフレームレイトに基づいて決定し、前記ファイル作成部によって前記指定枚数の前記フレームが新たに格納された前記チャンク領域である格納チャンク領域が存在するかどうかを、決定された前記チャンク応答間隔が経過するたびに確認し、前記格納チャンク領域が存在する場合には、前記格納チャンク領域に格納された指定枚数のフレームを１チャンクとして、前記映像データを要求する要求装置に送信する応答部と、
を備える。
【0008】
前記応答部は、
前記フレームレイトに加えて、前記指定枚数に基づいて、前記チャンク応答間隔を決定する。
前記フレームレイトに加えて、前記指定枚数に基づいて、前記チャンク応答間隔を決定する。
【0009】
前記応答部は、
前記フレームレイトを示す値の逆数と、前記指定枚数とに基づいて、前記チャンク応答間隔を決定する。
前記フレームレイトを示す値の逆数と、前記指定枚数とに基づいて、前記チャンク応答間隔を決定する。
【0010】
前記映像データ送信装置は、さらに、
前記複数のチャンク領域に格納される複数のフレームを前記ネットワークカメラから取得し、取得した前記複数のフレームから前記フレームレイトを算出する映像取得部を備え、
前記応答部は、
前記映像取得部が算出した前記フレームレイトを用いて前記チャンク応答間隔を決定する。
前記複数のチャンク領域に格納される複数のフレームを前記ネットワークカメラから取得し、取得した前記複数のフレームから前記フレームレイトを算出する映像取得部を備え、
前記応答部は、
前記映像取得部が算出した前記フレームレイトを用いて前記チャンク応答間隔を決定する。
【0011】
本開示の映像データ送信プログラムは、
コンピュータに、
記憶領域として複数のチャンク領域が設定されているセグメントファイルの各チャンク領域に、ネットワークカメラの撮影した映像データであるフレームを、指定されている指定枚数だけ順番に格納するフレーム格納処理と、
前記チャンク領域に前記指定枚数の前記フレームが格納されているかを確認する時間間隔を示すチャンク応答間隔を前記フレームのフレームレイトに基づいて決定し、前記フレーム格納処理によって前記指定枚数の前記フレームが新たに格納された前記チャンク領域である格納チャンク領域が存在するかどうかを、決定された前記チャンク応答間隔が経過するたびに確認し、前記格納チャンク領域が存在する場合には、前記格納チャンク領域に格納された指定枚数のフレームを１チャンクとして、前記映像データを要求する要求装置に送信する応答処理と、
を実行させる。
コンピュータに、
記憶領域として複数のチャンク領域が設定されているセグメントファイルの各チャンク領域に、ネットワークカメラの撮影した映像データであるフレームを、指定されている指定枚数だけ順番に格納するフレーム格納処理と、
前記チャンク領域に前記指定枚数の前記フレームが格納されているかを確認する時間間隔を示すチャンク応答間隔を前記フレームのフレームレイトに基づいて決定し、前記フレーム格納処理によって前記指定枚数の前記フレームが新たに格納された前記チャンク領域である格納チャンク領域が存在するかどうかを、決定された前記チャンク応答間隔が経過するたびに確認し、前記格納チャンク領域が存在する場合には、前記格納チャンク領域に格納された指定枚数のフレームを１チャンクとして、前記映像データを要求する要求装置に送信する応答処理と、
を実行させる。
【0012】
本開示の映像データ送信方法では、
コンピュータが、
記憶領域として複数のチャンク領域が設定されているセグメントファイルの各チャンク領域に、ネットワークカメラの撮影した映像データであるフレームを、指定されている指定枚数だけ順番に格納し、
前記チャンク領域に前記指定枚数の前記フレームが格納されているかを確認する時間間隔を示すチャンク応答間隔を前記フレームのフレームレイトに基づいて決定し、前記指定枚数の前記フレームが新たに格納された前記チャンク領域である格納チャンク領域が存在するかどうかを、決定された前記チャンク応答間隔が経過するたびに確認し、前記格納チャンク領域が存在する場合には、前記格納チャンク領域に格納された指定枚数のフレームを１チャンクとして、前記映像データを要求する要求装置に送信する。
コンピュータが、
記憶領域として複数のチャンク領域が設定されているセグメントファイルの各チャンク領域に、ネットワークカメラの撮影した映像データであるフレームを、指定されている指定枚数だけ順番に格納し、
前記チャンク領域に前記指定枚数の前記フレームが格納されているかを確認する時間間隔を示すチャンク応答間隔を前記フレームのフレームレイトに基づいて決定し、前記指定枚数の前記フレームが新たに格納された前記チャンク領域である格納チャンク領域が存在するかどうかを、決定された前記チャンク応答間隔が経過するたびに確認し、前記格納チャンク領域が存在する場合には、前記格納チャンク領域に格納された指定枚数のフレームを１チャンクとして、前記映像データを要求する要求装置に送信する。
【発明の効果】
【0013】
本開示に係る映像配信サーバによれば、ライブ映像の配信において、配信の遅延低減と、セグメントファイルの完成状態確認の負荷低減との、双方のバランスのとれた映像配信サーバを提供することができる。
【図面の簡単な説明】
【0014】
【図1】実施の形態１の図で、映像配信システム１０００の構成図。
【図2】実施の形態１の図で、映像配信システム１０００の動作概要を示す図。
【図3】実施の形態１の図で、映像配信サーバ１００の特徴を示す図。
【図4】実施の形態１の図で、映像配信サーバ１００のハードウェア構成図。
【図5】実施の形態１の図で、クライアント端末２００による映像再生の概要を説明する図。
【図6】実施の形態１の図で、クライアント端末２００の動作を示すフローチャート。
【図7】実施の形態１の図で、映像取得部１１１の動作概要を示す図。
【図8】実施の形態１の図で、ブラウザビューア部１１２の起動動作を示す図。
【図9】実施の形態１の図で、ブラウザビューア部１１２によるセグメントファイルの作成を示す図。
【図10】実施の形態１の図で、ブラウザビューア部１１２のセグメントファイルの作成動作を示すフローチャート。
【図11】実施の形態１の図で、映像配信サーバ１００の動作を示すシーケンス図。
【図12】実施の形態１の図で、映像配信サーバ１００の効果を示す図。
【発明を実施するための形態】
【0015】
実施の形態の説明および図面において、同じ要素および対応する要素には同じ符号を付している。同じ符号が付された要素の説明は、適宜に省略または簡略化する。以下の実施の形態では、「部」を、「回路」、「工程」、「手順」、「処理」または「サーキットリー」に適宜読み替えてもよい。
【0016】
【0017】
＊＊＊構成の説明＊＊＊
図１は、映像配信システム１０００の構成図である。映像配信システム１０００は、複数のネットワークカメラ１１、映像配信サーバ１００，クライアント端末２００を備えている。映像配信サーバ１００は映像データ送信装置である。クライアント端末２００はライブ映像の配信を要求する要求装置である。複数のネットワークカメラ１１、映像配信サーバ１００およびクライアント端末２００は、ネットワーク３００に接続している。図１では３台のネットワークカメラ１１を示している。各ネットワークカメラ１１は、フレームレイトを示すＦＰＳ（Ｆｒａｍｅｓ Ｐｅｒ Ｓｅｃｏｎｄ）値が異なる。３台のネットワークカメラ１１はそれぞれ、ＦＰＳ＝３０、ＦＰＳ＝１０、ＦＰＳ＝１である。例えばＦＰＳ＝３０は、３０枚／秒を示す。
図１は、映像配信システム１０００の構成図である。映像配信システム１０００は、複数のネットワークカメラ１１、映像配信サーバ１００，クライアント端末２００を備えている。映像配信サーバ１００は映像データ送信装置である。クライアント端末２００はライブ映像の配信を要求する要求装置である。複数のネットワークカメラ１１、映像配信サーバ１００およびクライアント端末２００は、ネットワーク３００に接続している。図１では３台のネットワークカメラ１１を示している。各ネットワークカメラ１１は、フレームレイトを示すＦＰＳ（Ｆｒａｍｅｓ Ｐｅｒ Ｓｅｃｏｎｄ）値が異なる。３台のネットワークカメラ１１はそれぞれ、ＦＰＳ＝３０、ＦＰＳ＝１０、ＦＰＳ＝１である。例えばＦＰＳ＝３０は、３０枚／秒を示す。
【0018】
映像配信サーバ１００は、映像取得部１１１、ブラウザビューア部１１２および受信応答部１１３を備えている。映像取得部１１１はネットワークカメラ１１から映像データを取得する。ブラウザビューア部１１２はセグメントファイルを作成するファイル作成部である。受信応答部１１３は、クライアント端末２００の要求に応答する応答部である。
【0019】
映像配信サーバ１００では、各ネットワークカメラ１１から映像データを取得し、クライアント端末２００からのリクエストに応答して、取得した映像データをリアルタイムにより近い状態でクライアント端末２００へ送信する。クライアント端末２００は、映像配信サーバ１００へネットワークカメラ１１の撮影する映像の配信を要求する配信要求を送信し、映像配信サーバ１００から映像データを受信する。
【0020】
図２は、映像配信システム１０００の動作概要を示す。映像配信サーバ１００の映像取得部１１１は、ネットワークカメラ１１から、ネットワークカメラ１１の撮影した映像データを取得する。映像取得部１１１は、ネットワークカメラ１１から取得した映像データからＦＰＳ値を算出する。ブラウザビューア部１１２は、セグメントフィルを作成する。ブラウザビューア部１１２は、セグメントフィルに、映像取得部１１１の取得した映像データである複数のフレームおよび映像取得部１１１の算出したＦＰＳ値を書き込む。ブラウザビューア部１１２はＨＬＳ用プレイリストも作成する。図３で後述するが、受信応答部１１３は、ＦＰＳ値から後述のチャンク応答間隔△ｔを決定し、チャンク応答間隔△ｔごとにセグメントフィルのチャンク領域を確認する。チャンク領域を確認したときに、新たに指定枚数のフレームが格納されている場合に、新たに格納された指定枚数のフレームを１チャンクとして、クライアント端末２００に送信する。
【0021】
図３は、映像配信サーバ１００の特徴を示す。ｃｈｕｎｋ応答処理の適切な間隔がネットワークカメラ１１の映像ごとで異なること、セグメントファイルの過剰な状態確認は映像配信サーバ１００に負荷を与える可能性があることに着目し、映像配信サーバ１００の特徴概要は以下のようである。映像配信サーバ１００は、映像データのＦＰＳ値から適切な応答間隔であるチャンク応答間隔△ｔを決定する。チャンク応答間隔△ｔにより、映像配信サーバ１００にとって負荷が少なくし、かつ、応答間隔を最小にして映像配信の遅延時間を低減する。
【0022】
映像配信サーバ１００が従来のＷｅｂサーバの動作と異なる点は、ｃｈｕｎｋ応答の間隔をＦＰＳ値に合わせて最適化する点にある。
【0023】
実施の形態１の映像配信サーバ１００によれば、ｃｈｕｎｋ応答時に無駄な待機時間が発生しないため、ライブ再生の遅延時間を最小限に抑えることができる。また、ｃｈｕｎｋ応答処理の間隔を最適化することで、映像配信サーバ１００への不要な負荷を軽減でき、サービスのセッション数増加などを実現できる。以下、図３を説明する。
【0024】
映像配信サーバ１００の特徴は、受信応答部１１３によるチャンク応答間隔△ｔの決定にある。図３を参照してチャンク応答間隔△ｔの決定と、チャンク応答間隔△ｔの使用を説明する。なおチャンク応答間隔△ｔの決定と、チャンク応答間隔△ｔの使用との具体的な説明は図１１で後述する。
【0025】
ステップＳ０１において、クライアント端末２００が、セグメントファイル２をリクエストする。この状態では、クライアント端末２００はすでにセグメントファイル１に含まれるフレームはクライアント端末２００へ送信済とする。
【0026】
図３に示すように、セグメントファイルにはｃｈｕｎｋ１からｃｈｕｎｋ１０として示す複数のｃｈｕｎｋ領域（以下、チャンク領域と表記）が設定されている。中段のｃｈｕｎｋ１０には「ｃｈｕｎｋ」と表示していないのは、ｃｈｕｎｋ１０には、まだフレームが格納されていないことを示す。セグメントファイルの中に示す１から１０の長方形が各チャンク領域を示す。実施の形態１においてチャンク領域とは、フレームの格納領域を意味する。受信応答部１１３は、チャンク領域に格納された指定枚数のフレームを１チャンクとして、クライアント端末２００に送信する。
【0027】
ステップＳ０２（図１１のステップＳ１３１に対応）において、映像配信サーバ１００の受信応答部１１３は、リクエストされたファイル名である「セグメントファイル２」からフレームのＦＰＳ値を取得し、チャンク応答間隔△ｔを決定する。ＦＰＳ値＝１０の場合、チャンク応答間隔△ｔ＝０．１秒とする。ここでは各チャンク領域には１フレームが格納される前提である。つまり後述の指定枚数＜Ｎ＞が１枚の場合である。
【0028】
ステップＳ０３（ステップＳ１３２に対応）において、受信応答部１１３は、ファイルのロック状態とファイルサイズとを取得する。ステップＳ０３では、チャンク領域８に対して新たにチャンク領域９にフレームが格納されているとする。受信応答部１１３は、チャンク領域９の分、ファイルサイズが増加したことを確認する。またロック状態とは、セグメントファイルをブラウザビューア部１１２が作成途中である場合である。ロック状態ではセグメントファイルにフレームが格納される可能性がある。
【0029】
ステップＳ０４（ステップＳ１３４に対応）において、受信応答部１１３は、取得したサイズ分のフレーム、すなわちチャンク領域９に格納されたフレームを１チャンクとして、かつ、応答として、クライアント端末２００に送信する。ステップＳ０４の完了の状態では、ロック状態であるので、まだ最後のチャンク領域１０までフレームが書き込まれていない。
【0030】
ステップＳ０５において、受信応答部１１３は、ステップＳ０２で決定したチャンク応答間隔△ｔ＝０．１秒だけ待機する。
【0031】
ステップＳ０６において、受信応答部１１３は、再度、ファイルのロック状態とファイルサイズを取得する。ステップＳ０６ではチャンク領域１０にフレームが書き込まれ、かつ、ロック状態が解放されて未ロック状態であり、受信応答部１１３はこの状態を取得する。
ステップＳ０７において、受信応答部１１３は、取得したサイズ分のデータを応答する。すなわち、受信応答部１１３は、チャンク領域１０に格納されているフレームを１チャンクとして、クライアント端末２００へ送信する。未ロック状態であるので処理はステップＳ０８へ進む。
ステップＳ０８において、受信応答部１１３は、「０￥ｒ￥ｎ￥ｒ￥ｎ」をクライアント端末２００へ送信し、チャンク応答を終了する。以上の受信応答部１１３の動作詳細は図１１の説明で後述する。
ステップＳ０７において、受信応答部１１３は、取得したサイズ分のデータを応答する。すなわち、受信応答部１１３は、チャンク領域１０に格納されているフレームを１チャンクとして、クライアント端末２００へ送信する。未ロック状態であるので処理はステップＳ０８へ進む。
ステップＳ０８において、受信応答部１１３は、「０￥ｒ￥ｎ￥ｒ￥ｎ」をクライアント端末２００へ送信し、チャンク応答を終了する。以上の受信応答部１１３の動作詳細は図１１の説明で後述する。
【0032】
図４は、映像配信サーバ１００のハードウェア構成図である。図４に示す映像配信サーバ１００は、コンピュータである。映像配信サーバ１００は、プロセッサ１１０を備える。映像配信サーバ１００は、プロセッサ１１０の他に、主記憶装置１２０、補助記憶装置１３０、入力インタフェース１４０、出力インタフェース１５０、通信インタフェース１６０といった、他のハードウェアを備える。プロセッサ１１０は、信号線１７０を介して、他のハードウェアと接続され、他のハードウェアを制御する。
【0033】
映像配信サーバ１００は、機能要素として、映像取得部１１１、ブラウザビューア部１１２および受信応答部１１３を備える。映像取得部１１１、ブラウザビューア部１１２および受信応答部１１３の機能は、映像データ送信プログラム１０１により実現される。
【0034】
プロセッサ１１０は、映像データ送信プログラム１０１を実行する装置である。映像データ送信プログラム１０１は、映像取得部１１１、ブラウザビューア部１１２および受信応答部１１３の機能を実現するプログラムである。プロセッサ１１０は、演算処理を行うＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）である。プロセッサ１１０の具体例は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＤＳＰ（Ｄｉｇｉｔａｌ
Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）である。
Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）である。
【0035】
主記憶装置１２０は、データを揮発的に保管する。主記憶装置１２０の具体例は、ＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）である。主記憶装置１２０は、プロセッサ１１０の演算結果を保持する。主記憶装置１２０は共有メモリ１１１ｍを実現する。
【0036】
補助記憶装置１３０は、データを不揮発的に保管する。補助記憶装置１３０の具体例は、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）である。また、補助記憶装置１３０は、ＳＤ（登録商標）（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）メモリカード、ＮＡＮＤフラッシュ、フレキシブルディスク、光ディスク、コンパクトディスク、ブルーレイ（登録商標）ディスク、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）といった可搬記録媒体であってもよい。補助記憶装置１３０は、映像データ送信プログラム１０１を記憶している。
【0037】
入力インタフェース１４０は、各装置からデータが入力されるポートである。出力インタフェース１５０は、各種機器が接続され、各種機器にプロセッサ１１０によりデータが出力されるポートである。
【0038】
通信インタフェース１６０は、プロセッサ１１０がネットワークカメラ１１およびクライアント端末２００のような他の装置と通信するための通信ポートである。
【0039】
プロセッサ１１０は補助記憶装置１３０から映像データ送信プログラム１０１を主記憶装置１２０にロードし、主記憶装置１２０から映像データ送信プログラム１０１を読み込み実行する。映像配信サーバ１００は、プロセッサ１１０を代替する複数のプロセッサを備えていてもよい。これら複数のプロセッサは、映像データ送信プログラム１０１の実行を分担する。それぞれのプロセッサは、プロセッサ１１０と同じように、映像データ送信プログラム１０１を実行する装置である。映像データ送信プログラム１０１により利用、処理または出力されるデータ、情報、信号値および変数値は、主記憶装置１２０、補助記憶装置１３０、または、プロセッサ１１０内の、レジスタあるいはキャッシュメモリに記憶される。
【0040】
映像データ送信プログラム１０１は、映像取得部１１１、ブラウザビューア部１１２および受信応答部１１３の「部」を「処理」、「手順」あるいは「工程」に読み替えた各処理、各手順あるいは各工程を、コンピュータに実行させるプログラムである。
【0041】
また、映像データ送信方法は、コンピュータである映像配信サーバ１００が、映像データ送信プログラム１０１を実行することにより行われる方法である。映像データ送信プログラム１０１は、コンピュータ読み取り可能な記録媒体に格納されて提供されてもよいし、プログラムプロダクトとして提供されてもよい。
【0042】
＊＊＊動作の説明＊＊＊
図５は、クライアント端末２００による映像再生の概要を説明する図である。図５を参照してクライアント端末２００と映像配信サーバ１００とのやり取りの概要を説明する。
ステップＳ３１において、クライアント端末２００は、映像配信サーバ１００へプレイリストをリクエストする。
ステップＳ３２において、受信応答部１１３がプレイリストを検索し取得する。
ステップＳ３３において、受信応答部１１３が、取得したプレイリストをクライアント端末２００へ送信する。
ステップＳ３４において、クライアント端末２００が、初期セグメントファイルおよびセグメントファイルを映像配信サーバ１００へ、リクエストする。
ステップＳ３５において、受信応答部１１３が、初期セグメントファイルおよびセグメントファイルを検索し取得する。
ステップＳ３６において、受信応答部１１３が、初期セグメントファイルおよびセグメントファイルを応答する。セグメントファイルの応答とは、チャンク応答間隔△ｔに基づくチャンク応答である。
図５は、クライアント端末２００による映像再生の概要を説明する図である。図５を参照してクライアント端末２００と映像配信サーバ１００とのやり取りの概要を説明する。
ステップＳ３１において、クライアント端末２００は、映像配信サーバ１００へプレイリストをリクエストする。
ステップＳ３２において、受信応答部１１３がプレイリストを検索し取得する。
ステップＳ３３において、受信応答部１１３が、取得したプレイリストをクライアント端末２００へ送信する。
ステップＳ３４において、クライアント端末２００が、初期セグメントファイルおよびセグメントファイルを映像配信サーバ１００へ、リクエストする。
ステップＳ３５において、受信応答部１１３が、初期セグメントファイルおよびセグメントファイルを検索し取得する。
ステップＳ３６において、受信応答部１１３が、初期セグメントファイルおよびセグメントファイルを応答する。セグメントファイルの応答とは、チャンク応答間隔△ｔに基づくチャンク応答である。
【0043】
図６は、クライアント端末２００の動作を示すフローチャートであり、図５におけるクライアント端末２００の動作をさらに具体的に説明する図である。
ステップＳ２０１において、クライアント端末２００は、プロセス起動用ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）をリクエストする。
ステップＳ２０２において、クライアント端末２００は、映像配信サーバ１００から、応答ｈｔｍｌデータを受信する。
ステップＳ２０３において、クライアント端末２００は、応答ｈｔｍｌに埋め込まれているプレイヤーを読み込み、プレイヤーを起動し同時にプレイリストを映像配信サーバ１００にリクエストする。
ステップＳ２０４において、クライアント端末２００は、映像配信サーバ１００からプレイリストを受信する。
ステップＳ２０５において、クライアント端末２００は、プレイリストに記載のあるセグメントファイルを、映像配信サーバ１００にリクエストする。
ステップＳ２０６において、クライアント端末２００は、受信したセグメントファイルのデータを再生する。
ステップＳ２０７において、クライアント端末２００は、映像配信サーバ１００に、プレイリストを再度リクエストする。なお、ステップＳ２０４からステップＳ２０７については、基本ループである。エラー発生あるいはブラウザタブ削除でプロセスが終了する。
ステップＳ２０１において、クライアント端末２００は、プロセス起動用ＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）をリクエストする。
ステップＳ２０２において、クライアント端末２００は、映像配信サーバ１００から、応答ｈｔｍｌデータを受信する。
ステップＳ２０３において、クライアント端末２００は、応答ｈｔｍｌに埋め込まれているプレイヤーを読み込み、プレイヤーを起動し同時にプレイリストを映像配信サーバ１００にリクエストする。
ステップＳ２０４において、クライアント端末２００は、映像配信サーバ１００からプレイリストを受信する。
ステップＳ２０５において、クライアント端末２００は、プレイリストに記載のあるセグメントファイルを、映像配信サーバ１００にリクエストする。
ステップＳ２０６において、クライアント端末２００は、受信したセグメントファイルのデータを再生する。
ステップＳ２０７において、クライアント端末２００は、映像配信サーバ１００に、プレイリストを再度リクエストする。なお、ステップＳ２０４からステップＳ２０７については、基本ループである。エラー発生あるいはブラウザタブ削除でプロセスが終了する。
【0044】
【0045】
図８は、ブラウザビューア部１１２の起動動作を示す図である。
ステップＳ１１において、クライアント端末２００がブラウザビューア部１１２の起動用ＣＧＩをリクエストする。
ステップＳ１２において、受信応答部１１３が、ブラウザビューア部１１２の起動用ＣＧＩを起動する。
ステップＳ１３において、起動用ＣＧＩがブラウザビューア部１１２のプロセスを起動する。
ステップＳ１４において、起動用ＣＧＩが、応答用のｈｔｍｌデータを標準出力に出力する。
ステップＳ１５において、受信応答部１１３は、標準出力に出力されたデータを応答する。標準出力に出力されたデータには映像再生の際に必要なプレイヤーと、プレイリストが含まれている。
ステップＳ１１において、クライアント端末２００がブラウザビューア部１１２の起動用ＣＧＩをリクエストする。
ステップＳ１２において、受信応答部１１３が、ブラウザビューア部１１２の起動用ＣＧＩを起動する。
ステップＳ１３において、起動用ＣＧＩがブラウザビューア部１１２のプロセスを起動する。
ステップＳ１４において、起動用ＣＧＩが、応答用のｈｔｍｌデータを標準出力に出力する。
ステップＳ１５において、受信応答部１１３は、標準出力に出力されたデータを応答する。標準出力に出力されたデータには映像再生の際に必要なプレイヤーと、プレイリストが含まれている。
【0046】
図９は、ブラウザビューア部１１２のセグメントファイル作成を示す図である。
図１０は、ブラウザビューア部１１２のセグメントファイル作成動作を示すフローチャートである。図９、図１０を参照して、ブラウザビューア部１１２によるセグメントファイル作成を説明する。
ステップＳ２１において、ブラウザビューア部１１２は、共有メモリ１１１ｍにアクセスし、映像取得部１１１によって共有メモリ１１１ｍに格納された、ＦＰＳ値、キーフレーム間隔、映像データを取得する。映像取得部１１１による共有メモリ１１１ｍへの格納は図１１のシーケンスで説明する。
ステップＳ２２において、ブラウザビューア部１１２はセグメントファイルを作成し、作成したセグメントファイルをセグメントファイル用ディレクトリ１１２ｄに格納する。
図１０は、ブラウザビューア部１１２のセグメントファイル作成動作を示すフローチャートである。図９、図１０を参照して、ブラウザビューア部１１２によるセグメントファイル作成を説明する。
ステップＳ２１において、ブラウザビューア部１１２は、共有メモリ１１１ｍにアクセスし、映像取得部１１１によって共有メモリ１１１ｍに格納された、ＦＰＳ値、キーフレーム間隔、映像データを取得する。映像取得部１１１による共有メモリ１１１ｍへの格納は図１１のシーケンスで説明する。
ステップＳ２２において、ブラウザビューア部１１２はセグメントファイルを作成し、作成したセグメントファイルをセグメントファイル用ディレクトリ１１２ｄに格納する。
【0047】
図１０を説明する。
ステップＳ１２１において、ブラウザビューア部１１２は、映像取得部１１１の共有メモリ１１１ｍから、ＦＰＳ値、キーフレーム間隔を取得する。これらは、セグメントファイルの作成に使用される。
ステップＳ１２２において、ブラウザビューア部１１２は、映像取得部１１１の共有メモリ１１１ｍから、映像データを取得する。
ステップＳ１２３において、ブラウザビューア部１１２は、映像データをから、Ｆｌａｇｍｅｎｔｅｄ ＭＰ４の初期セグメントファイルを作成する。
ステップＳ１２４において、ブラウザビューア部１１２は、映像データをから、Ｆｌａｇｍｅｎｔｅｄ ＭＰ４のセグメントファイルを作成する。
ステップＳ１２５において、ブラウザビューア部１１２は、ＨＬＳプレイリストを作成または更新する。
ステップＳ１２６において、ブラウザビューア部１１２は、古くなったセグメントファイルを削除する。
ステップＳ１２７において、ブラウザビューア部１１２は、セグメントファイルおよびプレイリストを削除する。図１０に示すように、プロセス停止までステップＳ１２４からステップＳ１２６はループする。このループは停止命令やエラー時に終了する。
ステップＳ１２１において、ブラウザビューア部１１２は、映像取得部１１１の共有メモリ１１１ｍから、ＦＰＳ値、キーフレーム間隔を取得する。これらは、セグメントファイルの作成に使用される。
ステップＳ１２２において、ブラウザビューア部１１２は、映像取得部１１１の共有メモリ１１１ｍから、映像データを取得する。
ステップＳ１２３において、ブラウザビューア部１１２は、映像データをから、Ｆｌａｇｍｅｎｔｅｄ ＭＰ４の初期セグメントファイルを作成する。
ステップＳ１２４において、ブラウザビューア部１１２は、映像データをから、Ｆｌａｇｍｅｎｔｅｄ ＭＰ４のセグメントファイルを作成する。
ステップＳ１２５において、ブラウザビューア部１１２は、ＨＬＳプレイリストを作成または更新する。
ステップＳ１２６において、ブラウザビューア部１１２は、古くなったセグメントファイルを削除する。
ステップＳ１２７において、ブラウザビューア部１１２は、セグメントファイルおよびプレイリストを削除する。図１０に示すように、プロセス停止までステップＳ１２４からステップＳ１２６はループする。このループは停止命令やエラー時に終了する。
【0048】
なお図１０において、各ネットワークカメラ１１毎にセグメントファイル用ディレクトリ１１２ｄが作成され、セグメントファイルは各ディレクトリに作成、保管される。また、作成中のセグメントファイルは、受信応答部１１３に未完成であるかどうかを判断させるため、排他制御を行う。排他制御により受信応答部１１３はロック状態かどうかを判断することとなる（図３のステップＳ０３、Ｓ０６、図１１のステップＳ１３２等）。例えばｃ言語のｆｌｏｃｋなどを使用できるが、受信応答部１１３がセグメントファイルのファイルサイズを確認しながら、セグメントファイルの完成状態を判断する方法は問わない。
【0049】
図１１は、映像配信サーバ１００の動作を示すシーケンス図である。図１１は図３に対応している。まずクライアント端末２００がセグメントフィル２をリクエストする。これは図３のステップＳ０１である。
ステップＳ１１１において、映像取得部１１１は、各ネットワークカメラ１１から映像データを取得する。
ステップＳ１１２において、映像取得部１１１は、映像データを、フレーム単位で共有メモリ１１１ｍに格納する。
ステップＳ１１３において、映像取得部１１１は、取得した映像データの実績値から、キーフレーム間隔、ＦＰＳ値を算出する。映像取得部１１１は、複数のチャンク領域に格納される複数のフレームをネットワークカメラから取得し、取得した複数のフレームからフレームレイトを算出する。
ステップＳ１１４において、映像取得部１１１は、算出したキーフレーム間隔，ＦＰＳ値を共有メモリ１１１ｍに格納する。
ステップＳ１１１において、映像取得部１１１は、各ネットワークカメラ１１から映像データを取得する。
ステップＳ１１２において、映像取得部１１１は、映像データを、フレーム単位で共有メモリ１１１ｍに格納する。
ステップＳ１１３において、映像取得部１１１は、取得した映像データの実績値から、キーフレーム間隔、ＦＰＳ値を算出する。映像取得部１１１は、複数のチャンク領域に格納される複数のフレームをネットワークカメラから取得し、取得した複数のフレームからフレームレイトを算出する。
ステップＳ１１４において、映像取得部１１１は、算出したキーフレーム間隔，ＦＰＳ値を共有メモリ１１１ｍに格納する。
【0050】
次に，図１１におけるブラウザビューア部１１２の動作を説明する。図１１におけるブラウザビューア部１１２の動作は、図１０から抜き出した主要処理を示している。
ステップＳ１２１、Ｓ１２２において、ブラウザビューア部１１２は、キーフレーム間隔，ＦＰＳ値，映像データを共有メモリ１１１ｍから取得する。
ステップＳ１２３、Ｓ１２４において、ファイル作成部であるブラウザビューア部１１２は、複数のチャンク領域が設定されているセグメントファイルの各チャンク領域（フレームが書き込まれる記憶領域）に、ネットワークカメラの撮影した映像データであるフレームを、指定されている指定枚数＜Ｎ＞だけ順番に格納する。図３で説明したように、実施の形態１では指定枚数＜Ｎ＞はＮ＝１であるので、各チャンク領域には１枚のフレームが格納される。
具体的には以下のようである。ブラウザビューア部１１２は、セグメントファイルを作成する。図２および図３に示すように、セグメントファイルにはＦＰＳ値が記録されていると共に、複数のチャンク領域に分割されている。実施の形態１では、指定枚数は１枚であるので、各チャンク領域には１枚のフレームが格納される。ブラウザビューア部１１２は、セグメントファイル用ディレクトリ１１２ｄに、作成中のセグメントファイルおよび作成中のセグメントファイルを格納する。
ステップＳ１２１、Ｓ１２２において、ブラウザビューア部１１２は、キーフレーム間隔，ＦＰＳ値，映像データを共有メモリ１１１ｍから取得する。
ステップＳ１２３、Ｓ１２４において、ファイル作成部であるブラウザビューア部１１２は、複数のチャンク領域が設定されているセグメントファイルの各チャンク領域（フレームが書き込まれる記憶領域）に、ネットワークカメラの撮影した映像データであるフレームを、指定されている指定枚数＜Ｎ＞だけ順番に格納する。図３で説明したように、実施の形態１では指定枚数＜Ｎ＞はＮ＝１であるので、各チャンク領域には１枚のフレームが格納される。
具体的には以下のようである。ブラウザビューア部１１２は、セグメントファイルを作成する。図２および図３に示すように、セグメントファイルにはＦＰＳ値が記録されていると共に、複数のチャンク領域に分割されている。実施の形態１では、指定枚数は１枚であるので、各チャンク領域には１枚のフレームが格納される。ブラウザビューア部１１２は、セグメントファイル用ディレクトリ１１２ｄに、作成中のセグメントファイルおよび作成中のセグメントファイルを格納する。
【0051】
【0052】
＜ステップＳ１３１＞
ステップＳ１３１において、受信応答部１１３は、チャンク領域に指定枚数＜Ｎ＞のフレームが格納されているかを確認する時間間隔を示すチャンク応答間隔△ｔを、フレームのフレームレイトに基づいて決定する。指定枚数＜Ｎ＞の値は、予め受信応答部１１３に設定されている。受信応答部１１３は、映像取得部１１１が算出したフレームレイトを用いてチャンク応答間隔△ｔを決定する。セグメントファイルはネットワークカメラ１１ごとに作成されるので、ネットワークカメラ１１のＦＰＳ値が既知であるときには既知のＦＰＳ値を用いることもできる。この場合、既知のＦＰＳ値が受信応答部１１３に設定される。受信応答部１１３は、フレームレイトに加えて、指定枚数＜Ｎ＞に基づいて、チャンク応答間隔△ｔを決定する。受信応答部１１３は、フレームレイトを示すＦＰＳ値の逆数と、指定枚数＜Ｎ＞とに基づいて、チャンク応答間隔△ｔを決定することができる。図３ではセグメントファイル２についてはチャンク応答間隔△ｔは０．１秒であった。これは、ＦＰＳ値の逆数＝（１／１０）と指定枚数＜Ｎ＞＝１との積から決定した。仮にＦＰＳ値＝１０、指定枚数＜Ｎ＞＝２であれば、チャンク応答間隔△ｔは０．２秒となる。以下の説明では指定枚数＜Ｎ＞＝１とする。
ステップＳ１３１において、受信応答部１１３は、チャンク領域に指定枚数＜Ｎ＞のフレームが格納されているかを確認する時間間隔を示すチャンク応答間隔△ｔを、フレームのフレームレイトに基づいて決定する。指定枚数＜Ｎ＞の値は、予め受信応答部１１３に設定されている。受信応答部１１３は、映像取得部１１１が算出したフレームレイトを用いてチャンク応答間隔△ｔを決定する。セグメントファイルはネットワークカメラ１１ごとに作成されるので、ネットワークカメラ１１のＦＰＳ値が既知であるときには既知のＦＰＳ値を用いることもできる。この場合、既知のＦＰＳ値が受信応答部１１３に設定される。受信応答部１１３は、フレームレイトに加えて、指定枚数＜Ｎ＞に基づいて、チャンク応答間隔△ｔを決定する。受信応答部１１３は、フレームレイトを示すＦＰＳ値の逆数と、指定枚数＜Ｎ＞とに基づいて、チャンク応答間隔△ｔを決定することができる。図３ではセグメントファイル２についてはチャンク応答間隔△ｔは０．１秒であった。これは、ＦＰＳ値の逆数＝（１／１０）と指定枚数＜Ｎ＞＝１との積から決定した。仮にＦＰＳ値＝１０、指定枚数＜Ｎ＞＝２であれば、チャンク応答間隔△ｔは０．２秒となる。以下の説明では指定枚数＜Ｎ＞＝１とする。
【0053】
受信応答部１１３は、リクエストされたファイル名からデータのＦＰＳ値を取得し、応答間隔△ｔを決定する。例えば図３のセグメントファイル２がリクエストされた場合を想定する。図２に示すように、「セグメントファイル２」というファイル名から、受信応答部１１３はデータであるフレームのＦＰＳ値を取得できる。セグメントファイル２ではＦＰＳ値＝１０である。受信応答部１１３は、チャンク応答間隔△ｔを、ＦＰＳ値の逆数＝（１／１０）＝０．１と、指定枚数＜Ｎ＞＝１との積から、０．１秒と決定する。
【0054】
＜ステップＳ１３２＞
ステップＳ１３２において、受信応答部１１３は、図３のチャンク領域９までフレームが格納されているセグメントファイル２のロック状態とファイルサイズをチェックする。ロック状態は「ロック」であり、ファイルサイズはチャンク領域８までの格納状態から、チャンク領域９にフレームが格納された状態である。
ステップＳ１３２において、受信応答部１１３は、図３のチャンク領域９までフレームが格納されているセグメントファイル２のロック状態とファイルサイズをチェックする。ロック状態は「ロック」であり、ファイルサイズはチャンク領域８までの格納状態から、チャンク領域９にフレームが格納された状態である。
【0055】
＜ステップＳ１３３＞
ステップＳ１３３において、受信応答部１１３は、受信応答部１１３はロック状態かどうかを判定する。この例では「ロック状態」なので、処理はステップＳ１３６に進む。
ステップＳ１３３において、受信応答部１１３は、受信応答部１１３はロック状態かどうかを判定する。この例では「ロック状態」なので、処理はステップＳ１３６に進む。
【0056】
＜ステップＳ１３６＞
ステップＳ１３６（１）において、まず受信応答部１１３は、新規取得サイズ分応答する。つまり、受信応答部１１３は、前回から新たに格納されたチャンク領域９（格納チャンク領域）のフレームを１チャンクとして、クライアント端末２００に送信する。
そしてステップＳ１３６（２）において、受信応答部１１３は、チャンク応答間隔△ｔだけ待機した後、ステップＳ１３２において、セグメントファイル２のロック状態とファイルサイズをチェックする。ステップＳ１３２では受信応答部１１３は、セグメントファイル２のロック状態とファイルサイズをチェックする。
ステップＳ１３６（１）において、まず受信応答部１１３は、新規取得サイズ分応答する。つまり、受信応答部１１３は、前回から新たに格納されたチャンク領域９（格納チャンク領域）のフレームを１チャンクとして、クライアント端末２００に送信する。
そしてステップＳ１３６（２）において、受信応答部１１３は、チャンク応答間隔△ｔだけ待機した後、ステップＳ１３２において、セグメントファイル２のロック状態とファイルサイズをチェックする。ステップＳ１３２では受信応答部１１３は、セグメントファイル２のロック状態とファイルサイズをチェックする。
【0057】
＜ステップＳ１３３＞
ステップＳ１３３において、ロック状態であれば処理はステップＳ１３６に進み、ロック状態でなければ、つまりセグメントファイル２へのフレームの格納が終了した場合には、処理はステップＳ１３４に進む。ここでは未ロック状態とする。つまりセグメントファイル２はチャンク領域１０までフレームが格納されているとする。
ステップＳ１３３において、ロック状態であれば処理はステップＳ１３６に進み、ロック状態でなければ、つまりセグメントファイル２へのフレームの格納が終了した場合には、処理はステップＳ１３４に進む。ここでは未ロック状態とする。つまりセグメントファイル２はチャンク領域１０までフレームが格納されているとする。
【0058】
＜ステップＳ１３４＞
ステップＳ１３４において、受信応答部１１３は、新規取得サイズ分応答する。すなわち受信応答部１１３は、チャンク領域１０に格納されたフレームを１チャンクとして、クライアント端末２００に送信する。
ステップＳ１３４において、受信応答部１１３は、新規取得サイズ分応答する。すなわち受信応答部１１３は、チャンク領域１０に格納されたフレームを１チャンクとして、クライアント端末２００に送信する。
【0059】
＜ステップＳ１３５＞
ステップＳ１３５において、受信応答部１１３は、「０￥ｒ￥ｎ￥ｒ￥ｎ」をクライアント端末２００に応答し、チャンク応答が終了する。
ステップＳ１３５において、受信応答部１１３は、「０￥ｒ￥ｎ￥ｒ￥ｎ」をクライアント端末２００に応答し、チャンク応答が終了する。
【0060】
受信応答部１１３によるステップＳ１３２，ステップＳ１３３，ステップＳ１３６の一連の処理をさらに説明しておく。受信応答部１１３は、ブラウザビューア部１１２によって指定枚数＜Ｎ＞のフレームが新たに格納されたチャンク領域である「格納チャンク領域」が存在するかどうかを、決定されたチャンク応答間隔△ｔが経過するたびに確認する。図１１に示すように、受信応答部１１３は、ステップＳ１３２、次にステップＳ１３３、ステップＳ１３３でＹＥＳであればステップＳ１３６（１）における新規取得分の応答、次にステップＳ１３６（２）におけるチャンク応答間隔△ｔの待機というように処理を進める。つまりステップＳ１３６（２）と、ステップＳ１３２のセグメントファイルのファイルサイズチェックとの関係は、「格納チャンク領域が存在するかどうかを、決定されたチャンク応答間隔△ｔが経過するたびに確認する。」という関係である。そして受信応答部１１３は、格納チャンク領域が存在する場合には、格納チャンク領域に格納された指定枚数のフレームを１チャンクとして、映像データを要求する要求装置であるクライアント端末２００に送信する（ステップＳ１３６（１）、ステップＳ１３４）。
【0061】
＊＊＊実施の形態１の効果の説明＊＊＊
図１２は、比較例との比較において、実施の形態１の映像配信サーバ１００の効果を説明する図である。映像配信サーバ１００の指定枚数＜Ｎ＞は１枚とする。図１２の左は、「ＦＰＳ＝１、ＧＯＶ＝１」の映像データの場合を示す。図１２の右は、「ＦＰＳ＝３０、ＧＯＶ＝３０」の映像データの場合を示す。
図１２は、比較例との比較において、実施の形態１の映像配信サーバ１００の効果を説明する図である。映像配信サーバ１００の指定枚数＜Ｎ＞は１枚とする。図１２の左は、「ＦＰＳ＝１、ＧＯＶ＝１」の映像データの場合を示す。図１２の右は、「ＦＰＳ＝３０、ＧＯＶ＝３０」の映像データの場合を示す。
【0062】
まず図１２の左を説明する。ＦＰＳ＝１（枚／秒）であるので、チャンク完成間隔、すなわち、チャンク領域に１フレームが格納される間隔は、映像配信サーバ１００および比較例も、１０００ｍｓｅｃである。最速応答に必要なファイル状態のチェック回数／秒は、どちらも１回である。チャンク応答間隔△ｔは、映像配信サーバ１００の場合、ＦＰＳ値の逆数と、指定枚数＜Ｎ＞との積であるので、チャンク応答間隔△ｔ＝１秒＝１０００ｍｓｅｃである。一方、比較例は７０ｍｓｅｃである。７０ｍｓｅｃは従来から仮定した値である。ファイル状態のチェック（回数／秒）は、チャンク応答間隔△ｔ＝１０００ｍｓｅｃと、チャンク応答間隔△ｔ＝７０ｍｓｅｃとから、映像配信サーバ１００と比較例は、それぞれ、１回、１０００／７０＝１４．３から１５回となる。無駄なファイル状態のチェック（回数／秒）は、映像配信サーバ１００が０回であるのに対して比較例は１４回となる。応答時間の遅延は、１チャンクあたり、どちらも０ｍｓｅｃである。図１２の左の場合、「無駄なファイル状態のチェック（回数／秒）」により、比較例では１４回の無駄が生じており、比較例の配信サーバでは無駄なＣＰＵ負荷が生じている。
【0063】
まず図１２の右を説明する。ＦＰＳ＝３０（枚／秒）であるので、チャンク完成間隔、すなわち、１つのチャンク領域に１フレームが格納される間隔は、映像配信サーバ１００および比較例も、３３ｍｓｅｃである。最速応答に必要なファイル状態のチェック回数／秒は、１０００／３３＝３０より、どちらも３０回である。チャンク応答間隔△ｔは、映像配信サーバ１００の場合、ＦＰＳ値の逆数と、指定枚数＜Ｎ＞との積であるので、チャンク応答間隔△ｔ＝１／３０×１＝３３ｍｓｅｃである。一方、比較例は７０ｍｓｅｃである。７０ｍｓｅｃは上記のように従来から仮定した値である。ファイル状態のチェック（回数／秒）は、チャンク応答間隔△ｔ＝３３ｍｓｅｃと、チャンク応答間隔△ｔ＝７０ｍｓｅｃとから、映像配信サーバ１００と比較例は、それぞれ、３０回、１５回となる。無駄なファイル状態のチェック（回数／秒）は、映像配信サーバ１００、比較例とも０回である。応答時間の遅延は、１チャンクあたり、映像配信サーバ１００、比較例ではそれぞれ、０ｍｓｅｃ、３７ｍｓｅｃ（７０ｍｓｅｃ－３３ｍｓｅｃ）である。図１２の右の場合、「１チャンクあたりの応答時間の遅延」により、比較例では３７ｍｓｅｃの遅延が生じている。
【0064】
図１２に示すように、映像配信サーバ１００によれば、受信応答部１１３がフレームレイトに基づいてチャンク応答間隔△ｔを決定するので、配信サーバのＣＰＵへの不要な負荷を軽減することができ、同時に、映像のライブ再生の遅延時間を低減することができる。
【符号の説明】
【0065】
１１ ネットワークカメラ、１００ 映像配信サーバ、１０１ 映像データ送信プログラム、１１０ プロセッサ、１１１ 映像取得部、１１１ｍ 共有メモリ、１１２ ブラウザビューア部、１１２ｄ セグメントファイル用ディレクトリ、１１３ 受信応答部、１２０ 主記憶装置、１３０ 補助記憶装置、１４０ 入力インタフェース、１５０ 出力インタフェース、１６０ 通信インタフェース、１７０ 信号線、２００ クライアント端末、３００ ネットワーク、１０００ 映像配信システム。
【要約】
【課題】ライブ映像の配信において、配信の遅延低減と、セグメントファイルの完成状態確認の負荷低減との、双方のバランスのとれた映像配信サーバを提供する。
【解決手段】映像配信サーバ１００は、記憶領域である複数のチャンク領域が設定されているセグメントファイルの各チャンク領域に、ネットワークカメラ１１の撮影した映像データのフレームを、指定枚数だけ順番に格納するブラウザビューア部１１２と、チャンク領域に指定枚数のフレームが格納されているか確認する時間間隔を示すチャンク応答間隔△ｔをフレームのＦＰＳ値に基づいて決定し、指定枚数のフレームが新たに格納された格納チャンク領域が存在するかどうかを、チャンク応答間隔△ｔが経過するたびに確認し、格納チャンク領域が存在する場合には、格納された指定枚数のフレームを１チャンクとして、クライアント端末２００に送信する受信応答部１１３とを備える。
【選択図】図１
【解決手段】映像配信サーバ１００は、記憶領域である複数のチャンク領域が設定されているセグメントファイルの各チャンク領域に、ネットワークカメラ１１の撮影した映像データのフレームを、指定枚数だけ順番に格納するブラウザビューア部１１２と、チャンク領域に指定枚数のフレームが格納されているか確認する時間間隔を示すチャンク応答間隔△ｔをフレームのＦＰＳ値に基づいて決定し、指定枚数のフレームが新たに格納された格納チャンク領域が存在するかどうかを、チャンク応答間隔△ｔが経過するたびに確認し、格納チャンク領域が存在する場合には、格納された指定枚数のフレームを１チャンクとして、クライアント端末２００に送信する受信応答部１１３とを備える。
【選択図】図１
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】