JP2023112033A - 送信装置、サーバ装置、送信方法およびプログラム - Google Patents
送信装置、サーバ装置、送信方法およびプログラム Download PDFInfo
- Publication number
- JP2023112033A JP2023112033A JP2023099839A JP2023099839A JP2023112033A JP 2023112033 A JP2023112033 A JP 2023112033A JP 2023099839 A JP2023099839 A JP 2023099839A JP 2023099839 A JP2023099839 A JP 2023099839A JP 2023112033 A JP2023112033 A JP 2023112033A
- Authority
- JP
- Japan
- Prior art keywords
- data
- unit
- transmission
- distribution
- transmitted
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000005540 biological transmission Effects 0.000 title claims abstract description 149
- 238000000034 method Methods 0.000 title claims description 33
- 238000012545 processing Methods 0.000 claims abstract description 45
- 230000004044 response Effects 0.000 claims abstract description 14
- 238000012217 deletion Methods 0.000 claims description 3
- 230000037430 deletion Effects 0.000 claims description 3
- 230000002542 deteriorative effect Effects 0.000 abstract 1
- 238000010586 diagram Methods 0.000 description 17
- 230000008569 process Effects 0.000 description 17
- 238000004891 communication Methods 0.000 description 15
- 239000012634 fragment Substances 0.000 description 14
- 238000001514 detection method Methods 0.000 description 13
- 238000003384 imaging method Methods 0.000 description 13
- 230000006870 function Effects 0.000 description 11
- 238000012986 modification Methods 0.000 description 11
- 230000004048 modification Effects 0.000 description 11
- 238000012544 monitoring process Methods 0.000 description 11
- 238000006243 chemical reaction Methods 0.000 description 6
- 230000003044 adaptive effect Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 230000000593 degrading effect Effects 0.000 description 3
- 230000006835 compression Effects 0.000 description 2
- 238000007906 compression Methods 0.000 description 2
- 230000007774 longterm Effects 0.000 description 2
- 230000002159 abnormal effect Effects 0.000 description 1
- 230000005856 abnormality Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000006866 deterioration Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000013467 fragmentation Methods 0.000 description 1
- 238000006062 fragmentation reaction Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
Images
Landscapes
- Closed-Circuit Television Systems (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Signal Processing For Digital Recording And Reproducing (AREA)
- Management Or Editing Of Information On Record Carriers (AREA)
Abstract
【課題】品質を低下させることなく、回線負荷や処理負荷を低減する。【解決手段】本実施形態の送信装置は、分割部と、送信部と、記憶制御部と、受信部と、を備える。分割部は、送信対象となる複数の送信データを、第1データと第2データとに分割する。送信部は、第1データを、送信データを受信装置に配信するサーバ装置に送信する。記憶制御部は、第2データを記憶部に記憶させる。受信部は、第2データの送信要求を受信装置またはサーバ装置から受信する。送信部は、さらに、送信要求に応じて第2データをサーバ装置に送信する。【選択図】図3
Description
本発明の実施形態は、送信装置、サーバ装置、送信方法およびプログラムに関する。
HLS(HTTP Live Streaming)およびMPEG-DASH(Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP)などのアダプティブストリーミングは、例えば、カメラで撮像した映像(動画像データ)を配信し監視可能とするシステム(映像配信システム、映像監視システム)に適用できる。
R. Pantos et al.、"RFC 8216、 HTTP Live Streaming"、[online]、August 2017、retrieved from the Internet: <URL:http://www.ietf.org/rfc/rfc8216.txt>
しかしながら、従来技術では、データ(映像など)を送信するネットワーク回線の負荷、および、システムの処理負荷が増加するおそれがあった。例えば、接続されるカメラの個数が増大することに伴い、カメラから映像を送信するためのネットワーク回線の負荷、並びに、映像の収録および配信などを実行するサーバの処理負荷が増大する可能性があった。
実施形態の送信装置は、分割部と、送信部と、記憶制御部と、受信部と、を備える。分割部は、送信対象となる複数の送信データを、第1データと第2データとに分割する。送信部は、第1データを、送信データを受信装置に配信するサーバ装置に送信する。記憶制御部は、第2データを記憶部に記憶させる。受信部は、第2データの送信要求を受信装置またはサーバ装置から受信する。送信部は、さらに、送信要求に応じて第2データをサーバ装置に送信する。
以下に添付図面を参照して、この発明にかかる送信装置の好適な実施形態を詳細に説明する。
従来のアダプティブストリーミングを用いた映像配信システムでは、高品質なライブ映像の配信に必要な高品質の映像ストリーム(送信データの一例)を確実に収録するためには、伝送レートが高いネットワーク回線を準備する必要がある。
一方、多数のカメラが接続される大規模な映像配信システムでは、常に大量のカメラ映像が送信される。このため、回線負荷やコストの低減のためには、カメラと、映像を収録するサーバ装置との間に、伝送レートが低いネットワーク回線を用いることが望ましい。しかし伝送レートが低い回線ではライブ映像が低品質となり、監視作業に支障をきたすおそれがある。
そこで、本実施形態では、品質を低下させることなく、回線負荷や処理負荷を低減することができる映像配信システムを実現する。
ここで、本実施形態を適用できる送信データの例について説明する。送信データは、例えば、動画像データおよびセンサデータなどの、時間的な順序が定められた時系列データを含む。
動画像データは、例えばカメラおよびフレームキャプチャなどの撮像装置により撮像されるデータである。動画像データは、例えば撮像装置からリアルタイムに取得され、配信対象のコンテンツとして使用される。撮像された後、一旦記憶媒体に記憶された動画像データが、配信対象のコンテンツとして使用されてもよい。
センサデータとは、センサ(検知装置)が検知した値を示すデータであり、例えばデータを検知(サンプリング)した時刻の情報を含む。センサはどのような装置であってもよい。例えば、音声を取得するマイクロフォン、位置情報を取得するGPS(Global Positioning System)装置、および、検知対象となる周辺環境や電子機器の温度、速度、圧力などを、定期的に、または、不定期に検知してセンサデータとして出力するセンサを使用することができる。
以下では、主に動画像データを送信データとした例について説明する。
図1は、本実施形態にかかる映像配信システムの構成の一例を示すブロック図である。図1に示すように、映像配信システムは、送信装置100(送信装置の一例)と、配信サーバ200(サーバ装置の一例)と、クライアント300(受信装置の一例)と、を備えている。送信装置100と配信サーバ200とは、ネットワーク401により接続される。配信サーバ200とクライアント300とは、ネットワーク402により接続される。
ネットワーク401および402は、インターネットなどの、どのようなネットワークであってもよい。例えばネットワーク401および402は、有線ネットワークおよび無線ネットワークのいずれであってもよい。また、ネットワーク401および402は、統合した1つのネットワークとして構成してもよい。
図1に示す通信システムの構成は一例であり、これに限られるものではない。例えば送信装置100、配信サーバ200、および、クライアント300は、それぞれ複数備えられていてもよい。また、送信装置100、配信サーバ200およびクライアント300それぞれは、物理的に1つの装置によって構成されてもよいし、物理的に複数の装置によって構成されてもよい。例えば配信サーバ200は、クラウド環境上で構築されてもよい。
図2は、本実施形態の映像配信システムによる配信処理の概要を示す図である。送信装置100は、映像を入力し、入力した映像をエンコード(符号化)する。送信装置100は、例えばH.264などの規格に従い、映像を圧縮符号化する。エンコードされた映像は、例えばIピクチャおよびPピクチャを含む。Iピクチャは、フレーム内予測により符号化された画像データであり、単独で再生できる全画面の範囲を含む。Pピクチャは、Iピクチャに基づいてフレーム間予測により符号化した画像データである。Pピクチャは、単独では再生できずIピクチャと組み合わせて再生可能となる。
送信装置100は、これらのエンコードされた映像を、ピクチャごとに分割(フラグメント化)する。そして送信装置100は、分割したピクチャの一部(例えばIピクチャ)を配信サーバ200に送信し、残り(例えばPピクチャ)は、記憶部に記憶する。なお送信装置100は、配信サーバ200に送信したピクチャについてもプレイバック(ローカル再生)およびバックアップ等のために記憶部に記憶してもよい。
配信サーバ200は、通常時には、送信装置100から送信されたIピクチャのみをクライアント300に配信する。クライアント300は、例えばビューワアプリを用いて配信された映像を表示する。ビューワアプリは、例えばブラウザに含まれる、映像を表示して閲覧可能とするためのアプリケーションである。Iピクチャは一定間隔で送信されるため(例えば1秒間に数枚、または、数秒に1枚)、クライアント300では、静止画像(Iピクチャ)が一定間隔で更新されるような映像(ぱらぱら漫画、コマ送り(間欠)動画)が表示される。ビューワアプリは、例えば、HTML(Hyper Text Markup Language)5用のアプリケーションプログラミングインタフェースであるMSE(Media Source Extensions)を用いたアプリケーションとして実現できる。これにより、HTTPダウンロードを利用したストリーミング再生が可能となる。
クライアント300を操作するユーザなどにより、Pピクチャの表示が要求されると、送信装置100は、記憶したPピクチャを読み出し、配信サーバ200に送信する。配信サーバ200は、送信されたPピクチャをクライアント300に配信する。配信サーバ200は、送信されたPピクチャをそのまま配信してもよいし、画像データに対する変換処理(再圧縮など)以外の加工処理(伝送パケット形式の変更など)のみを加えたPピクチャを配信してもよい。クライアント300のビューワアプリは、既に受信したIピクチャと、後から受信したPピクチャとを合成して表示する。これにより、クライアント300では、より滑らかな映像が表示可能となる。転送済みのデータ(例えばIピクチャ)は、クライアント300内の記憶部に記憶しておけば、後で受信したPピクチャとの合成等に使用できる。すなわち、転送済みのデータは再度送信装置100および配信サーバ200から送信する必要はない。従って、Pピクチャを含む全映像データを改めて送信しなおす方法と比べ、伝送データ量を減らすことができる。
上述のように、配信サーバ200は、画像データに対して再圧縮などの変換処理などを適用することなく、送信装置100から送信された画像データをそのまままたは伝送パケット形式のみを加工してクライアント300に配信する。例えば配信サーバ200は、低い伝送レートで配信可能とするために、品質を低下させた映像に変換する処理を実行する必要がない。従って、配信サーバ200の処理負荷の増加、および、画質の劣化を回避できる。また、通常時は、Iピクチャのみを配信するため、通信量を抑制することができる。このように、品質を低下させることなく、回線負荷や処理負荷を低減することが可能となる。
なおIピクチャは、映像(動画像データ)を構成する一部のデータであるが、静止画像として扱うことができる。例えば、クライアント300で動作するブラウザ(ビューワアプリ)は、動画像データに含まれるIピクチャを静止画像データとして表示できる場合がある。従って、例えばJPEG(Joint Photographic Experts Group)などの静止画像への圧縮処理を実行することなく、Iピクチャを静止画像データとして表示可能となる。JPEG形式の静止画像と比べてIピクチャはデータサイズが小さいため(圧縮効率が大きい)、回線負荷および処理負荷をより軽減可能となる。また、配信された映像を画像認識に用いるような場合にも、映像を静止画像に変換することなく、Iピクチャを画像認識の入力データとして利用することが可能となる。
次に、本実施形態の映像配信システムの各装置の構成の詳細について説明する。図3は、本実施形態の映像配信システムの各装置の機能構成の一例を示すブロック図である。
図3に示すように、送信装置100は、撮像部101と、記憶部121と、符号化部111と、分割部112と、データ送信部113と、記憶制御部114と、要求受信部115と、を備えている。
撮像部101は、映像(動画像データ)を撮像して出力する。撮像部101は、例えば、CCD(Charge Coupled Device)およびCIS(CMOS image sensor)等の撮像素子、または、フレームメモリ、フレームグラバ、および、スクリーンキャプチャ等のフレームバッファキャプチャにより実現できる。
記憶部121は、送信装置100による各種処理で用いられる各種データを記憶する。例えば記憶部121は、撮像部101により撮像された映像を記憶する。
符号化部111は、撮像部101から入力された映像を符号化する。符号化部111による符号化方式はどのような方式であってもよいが、例えば、H.264などの規格に従った符号化方式を適用できる。符号化部111は、例えば、映像を圧縮符号化し、IピクチャおよびPピクチャを含む映像を出力する。符号化された映像の各ピクチャが、送信対象となる複数の送信データに相当する。
分割部112は、符号化された映像を、配信サーバ200に送信するデータ(第1データ)と、送信せずに記憶部121に記憶するデータ(第2データ)と、に分割する。例えば分割部112は、Iピクチャを配信サーバ200に送信するデータ(フラグメントデータ)とし、Pピクチャを記憶部121に記憶するデータ(フラグメントデータ)とするように、符号化された映像をピクチャごとに分割する。分割部112は、分割したピクチャそれぞれが1つのファイル(フラグメントファイル)となるように映像を分割してもよい。記憶部121に記憶するデータについては、分割部112は、複数のピクチャが1つのファイルに含まれるように分割してもよい。
分割部112によるデータの分割方法はこれに限られず、どのような方法であってもよい。例えば分割部112は、符号化された映像を、複数のIピクチャから一定数ごとに選択されたIピクチャと、それ以外のピクチャ(残りのIピクチャおよびPピクチャ)とに分割してもよい。また例えば分割部112は、符号化された映像を、Iピクチャおよび複数のPピクチャから一定数ごとに選択されたPピクチャと、それ以外のピクチャ(残りのPピクチャ)とに分割してもよい。また例えば分割部112は、符号化された映像を、複数のIピクチャから一定数ごとに選択されたIピクチャ、および、複数のPピクチャから一定数ごとに選択されたPピクチャと、それ以外のピクチャ(残りのIピクチャおよびPピクチャ)とに分割してもよい。
配信サーバ200に送信するデータは、配信サーバ200がそのまま配信可能な形式で表されてもよい。例えば分割部112は、Fragmented MP4(fMP4)などの規格に従った形式となるように、分割したデータを変換してもよい。
配信サーバ200に送信するデータは、配信サーバ200が配信する形式に変換できるようなデータ(メタデータ)が付加された形式で表されてもよい。例えば分割部112は、配信サーバ200側でfMP4などの規格に従った形式に変換できるように、変換に必要な情報を含むメタデータを、分割したデータに付加してもよい。変換に必要な情報は、例えば、送信装置100を識別する情報(IPアドレスおよびポート番号など)、時刻(撮像された日時分秒など)、および、当該時刻内での画像の位置(例えば先頭から何番目かを示す情報など)を含む。
分割部112は、ネットワーク401の帯域に応じて、配信サーバ200に送信するデータのサイズまたは符号量を変更してもよい。例えば分割部112は、割り当てられたネットワーク401の帯域内で遅延等が生じずに送信できるサイズに相当するデータ、または、ネットワーク401の帯域以内の符号化ビットレートとなるデータを配信サーバ200に送信するデータとして分割してもよい。例えば、ネットワーク401の帯域が大きい場合は、分割部112は、IピクチャおよびPピクチャの一部を配信サーバ200に送信するデータとして分割し、帯域が小さくなるに従い、Iピクチャのみ、および、Iピクチャのうち一部(Iピクチャを一定数ごとに間引きするなど)を配信サーバ200に送信するデータとして分割してもよい。Pピクチャを部分的に配信する際のエンコード手法については、例えば特許文献1に記載の手法などを用いることができる。
分割部112は、ネットワーク401の帯域に応じて、あるいは、クライアント300または配信サーバ200からの要求に応じて、上記のような分割方法を動的に切り替えることにより、配信サーバ200に送信するデータのサイズまたは符号量を変更してもよい。
符号化部111により符号化されたデータを単純に分割すると、分割されたデータのサイズが不一致となる可能性がある。例えば、符号化部111が、ネットワーク401の帯域に応じて各ピクチャの符号量を調整する機能を備えている場合、各Iピクチャのサイズ、および、各Pピクチャのサイズは相互に異なりうる。従って、このようにして符号化された各ピクチャのうち、例えばIピクチャを配信サーバ200に送信するデータとして分割すると、分割されたIピクチャそれぞれのサイズも相互に異なる可能性がある。
そこで、符号化部111は、分割後のデータのサイズまたは符号化ビットレートが、割り当てられたネットワーク401の帯域内で遅延等が生じずに送信できるサイズまたは符号化ビットレートとなるように、ネットワーク401の帯域に応じて符号量を調整してもよい。例えば、分割部112がIピクチャのみを配信サーバ200に送信するように映像を分割する場合であれば、符号化部111は、Iピクチャのサイズがネットワーク401の帯域内で遅延等が生じずに送信できる一定のサイズとなるように、または、ネットワーク401の帯域以内の符号化ビットレートとなるように、映像を符号化してもよい。
データ送信部113は、配信サーバ200などの外部装置に対してデータを送信する。例えばデータ送信部113は、分割部112により分割されたデータのうち、配信サーバ200に送信するデータ(第1データ)を、配信サーバ200に送信する。またデータ送信部113は、記憶部121に記憶されたデータの送信要求が要求受信部115(後述)により受信された場合、要求されたデータを配信サーバ200に送信する。
記憶制御部114は、記憶部121に対する記憶処理を制御する。例えば記憶制御部114は、分割部112により分割されたデータのうち、配信サーバ200に送信しないデータを記憶部121に記憶する。記憶制御部114は、配信サーバ200に送信したデータ(第1データ)を記憶部121に記憶してもよい。このとき、記憶制御部114は、送信したデータ(第1のデータ)が送信済であることを示す、または、第2データが未送信であることを示すメタデータを用いて、記憶したデータを管理してもよい。記憶制御部114は、予め定められた条件に従い記憶部121に記憶されたデータを削除してもよい。例えば記憶制御部114は、記憶してから一定期間が経過したデータを削除してもよい。
要求受信部115は、記憶部121に記憶されたデータの送信要求を配信サーバ200から受信する。クライアント300から配信サーバ200以外の制御サーバ等を経由して要求を送信する構成の場合、要求受信部115は、記憶部121に記憶されたデータの送信要求をこのような制御サーバから受信してもよい。
上記各部(符号化部111、分割部112、データ送信部113、記憶制御部114、要求受信部115)は、例えば、1または複数のプロセッサにより実現される。例えば上記各部は、CPU(Central Processing Unit)などのプロセッサにプログラムを実行させること、すなわちソフトウェアにより実現してもよい。上記各部は、専用のIC(Integrated Circuit)などのプロセッサ、すなわちハードウェアにより実現してもよい。上記各部は、ソフトウェアおよびハードウェアを併用して実現してもよい。複数のプロセッサを用いる場合、各プロセッサは、各部のうち1つを実現してもよいし、各部のうち2以上を実現してもよい。
なお送信装置100の各機能は、物理的または論理的に異なる複数の装置に分散されてもよい。例えば、撮像部101および符号化部111を備える装置(図2の映像入力、エンコーダ)と、残りの各部(図2のフラグメント化、記憶部)を備える装置とに分けられてもよい。この場合、符号化部111により符号化されたデータは、例えば、ネットワークまたは同軸ケーブルなどの通信路により、後者の装置に入力される。後者の装置が、符号化されたデータを通信路を介して取得するように構成してもよい。
次に配信サーバ200の構成について説明する。配信サーバ200は、配信リストおよび判定情報を、ネットワーク402を介してクライアント300に配信する。配信リストは、配信するデータ(以下、コンテンツともいう)に関する情報を記載したリストである。通常、コンテンツ配信者は、配信リストにコンテンツの取得先やビットレート等のメタデータを記載する。コンテンツ取得者は、配信リストを取得し、解析することで、取得するコンテンツを特定することができる。
配信リストに記載されるコンテンツは、送信可能な状態のコンテンツのみではなく、送信できない状態のコンテンツ、および、送信を許可しないコンテンツなどを含みうる。判定情報は、配信リストに含まれるコンテンツの送信を要求するか否かを受信装置(クライアント300)が判定するための情報である。
図3に示すように、配信サーバ200は、検出部201と、リスト生成部211と、判定情報生成部212と、リスト送信部213と、判定情報送信部214と、要求送受信部215と、配信部216と、データ受信部217と、記憶制御部218と、一時記憶部221と、記憶部222と、を備えている。
検出部201は、コンテンツが送信可能になったことを検出する。例えば検出部201は、コンテンツを提供する提供装置(送信装置100など)からコンテンツが提供された場合に、コンテンツが送信可能になったと判断する。検出部201は、コンテンツが記憶される記憶領域(例えば一時記憶部221)を監視し、コンテンツが記憶された場合に、コンテンツが送信可能になったと判断してもよい。
リスト生成部211は、配信リストを生成する。リスト生成部211は、例えば、配信リストを生成して送信することをクライアント300から要求されたときに、配信リストを生成する。配信リストの生成の契機はこれに限られず、どのような契機であってもよい。例えばリスト生成部211は、一定時間が経過するごとに、次の期間に送信するコンテンツの配信リストを生成してもよい。リスト生成部211は、提供装置からコンテンツが提供されたとき、または、生成を指示されたときなどに配信リストを生成してもよい。
図4は、配信リストのデータ構造の一例を示す図である。図4に示すように、配信リストは、コンテンツを識別する識別情報を含む。図3は、コンテンツのURL(Uniform Resource Locator)を識別情報として利用する例を示している。識別情報は、コンテンツを識別できればURL以外の情報を用いてもよい。配信リストは、識別情報以外の情報を含んでもよい。本実施形態では、例えば分割されたデータ(ピクチャなど)ごとのURLを含む配信リストが作成される。
図3に戻り、判定情報生成部212は、判定情報を生成する。例えば判定情報生成部212は、コンテンツが送信可能である場合に送信可能であることを示す判定情報を生成し、コンテンツが送信可能でない場合に送信可能でないことを示す判定情報を生成する。また判定情報生成部212は、コンテンツが送信可能であるか否かを示す状況が変化した場合に、変化した後の状況に対応するように更新した判定情報を生成する。
判定情報生成部212は、例えば、判定情報を生成して送信することをクライアント300から要求されたときに、判定情報を生成する。リスト生成部211により配信リストが生成されたときに、その時点での判定情報を判定情報生成部212が生成してもよい。判定情報の生成の契機はこれに限られず、どのような契機であってもよい。例えば判定情報生成部212は、一定時間が経過するごとに、例えば検出部201を用いてコンテンツが送信可能になったか否かを検出し、検出結果に応じて更新した判定情報を生成してもよい。
図5は、判定情報のデータ構造の一例を示す図である。図5の判定情報は、図4の配信リストに記載された4つのコンテンツが送信可能かを判定するための判定情報の例である。例えば「○」は、コンテンツが送信可能であることを示し、「×」は、コンテンツが送信可能でないことを示す。図5の例では、図4の4つのURLに対応する4つのコンテンツ(“ContentA_1”、“ContentA_2”、“ContentA_3”、“ContentA_4”)に対応する4つの判定情報(「○」または「×」)が対応する順序で指定されている。
コンテンツごとに判定情報を指定できる方法であれば、図5以外のデータ構造の判定情報を用いてもよい。例えば、コンテンツの識別情報を判定情報に対応づけてもよい。いずれの配信リストに対応する判定情報であるかを識別可能とするために、配信リストを識別するための情報を判定情報に対応づけてもよい。
コンテンツが送信可能であるとは、例えば、配信対象となるコンテンツが配信サーバ200に提供されており、クライアント300に対して送信できる状態である。コンテンツが送信可能でないとは、例えば、配信対象となるコンテンツが配信サーバ200にまだ提供されておらず、クライアント300に対して送信できない状態である。なお配信サーバ200は、クライアント300からの要求に応じてコンテンツを送信(プル型送信)してもよいし、クライアント300からの要求なしにコンテンツを送信(プッシュ型送信)してもよい。
コンテンツが提供されているか否かに関わらず、配信サーバ200が、コンテンツを送信可能であるか否かを指定してもよい。例えば、通信負荷を軽減させるために、提供された複数のコンテンツのうち一部または全部に対して、送信可能でないことを示す判定情報を生成し、これらのコンテンツを送信できないように構成してもよい。このように、送信可能であるコンテンツが、その後、送信可能でなくなる場合がありうる。
判定情報は、コンテンツごとに1つであってもよいし、複数であってもよい。例えば、コンテンツの1以上のメタデータを判定情報として使用してもよい。メタデータは、例えば、コンテンツの範囲を示す範囲情報、コンテンツのデータ長、および、コンテンツの種類などである。範囲情報は、例えば、あるデータのうち、コンテンツとして配信するデータの範囲を指定する情報である。範囲情報が確定している場合には、確定した範囲情報を判定情報として設定し、未確定の場合には、未確定であることを示す予め定められた情報(未確定情報)を判定情報として設定する。クライアント300は、判定情報としての範囲情報に未確定情報が設定されていた場合に、対応するコンテンツが送信可能でないと判定できる。このように、メタデータを判定情報として使用する場合は、メタデータによりコンテンツが送信可能か否かを判定できるようなデータ形式を定めておけばよい。
図3に戻り、リスト送信部213は、リスト生成部211により生成された配信リストをクライアント300に送信する。例えばリスト送信部213は、コンテンツの送信を開始する前に、事前に配信リストをクライアント300に送信する。判定情報送信部214は、判定情報生成部212により生成された判定情報をクライアント300に送信する。
要求送受信部215は、各種要求の送受信を行う。例えば要求送受信部215は、配信リストの送信要求、判定情報の送信要求、および、コンテンツの送信要求をクライアント300から受信する。また要求送受信部215は、記憶部121に記憶されたコンテンツの送信要求を、送信装置100に送信する。
配信部216は、要求されたコンテンツを、送信要求を送信したクライアント300に送信する。プッシュ型送信を採用する場合、配信部216は、クライアント300からの要求なしにコンテンツを送信してもよい。
データ受信部217は、送信装置100から送信されたデータを受信する。例えばデータ受信部217は、配信サーバ200に送信するデータとして分割されたデータを受信する。記憶部121に記憶されたデータの送信要求が送信された場合、データ受信部217は、この送信要求に対して送信装置100が送信したデータを受信する。
記憶制御部218は、一時記憶部221および記憶部222に対する記憶処理を制御する。送信装置100から送信されたデータおよび送信装置100から送信されたデータを配信サーバ200が配信する形式に変換したデータを記憶部222に記憶してから配信するように構成すると、記憶部222にデータを記憶する処理が配信速度に追いつかない、および、記憶部222への書き出し処理が一時的にフリーズする、などの書き出し処理の異常が生じ、正常に配信できなくなる場合がある。そこで、記憶制御部218は、送信装置100から送信されたデータを、上記のような書き出し処理の異常が生じないような記憶媒体である一時記憶部221に記憶する。配信部216は、データが一時記憶部221に記憶されている場合は、一時記憶部221からデータを読み出してクライアント300に配信する。この際、送信装置100から送信されたデータは最終的に記憶部222に記憶することになる。このため、配信部216はクライアント300からの要求に対してあたかも記憶部222から配信しているかのように動作してもよい。すなわち、記憶部222に保存されているデータに対する要求に対し、一時記憶部221に保存されているデータを返してもよい。配信サーバ200上でこれらのファイルの紐づけを記録(データベース、ファイル、シンボリックリンクなど)して配信時に参照することで、このような機能を実現できる。
そして、記憶制御部218は、一時記憶部221に記憶されたデータを、記憶部222に書き出す処理(書き出し処理)を行う。書き出し処理では、記憶制御部218は、一時記憶部221に記憶された複数のデータを1つのデータに結合して記憶部222に記憶してもよい。例えば、記憶制御部218は、一定期間内に撮像された複数のデータを1つのファイルに含まれるように結合し、結合したファイル(結合ファイル)を記憶部222に書き出してもよい。これにより、記憶部222に記憶するファイルの個数が例えばオペレーティングシステムの許容量を超えることにより、データが記憶できなくなる不具合などを回避可能となる。
複数のデータを1つのデータに結合して記憶部222に記憶した後、結合したデータに含まれるデータの送信要求をクライアント300から受信した場合は、結合したデータから、該当データを特定する機能が必要となる。そこで、例えばリスト生成部211は、該当データを特定するための特定情報を含むように配信リストを更新してもよい。リスト生成部211は、例えば、結合ファイル内でのデータの位置を示す特定情報(先頭からのバイトオフセットなど)を、当該データの識別情報(URLなど)に対応づけた配信リストを作成し、クライアント300に送付する。
クライアント300は、更新された配信リストを参照してデータの送信を要求する場合、要求するデータの識別情報とともに、対応づけられた特定情報を指定する。例えば、クライアント300は、データの識別情報を示すURLに特定情報を付加した情報により、データを要求する。クライアント300は、ヘッダ(HTTPの拡張ヘッダなど)に特定情報を含めた送信要求によりデータを要求してもよい。
この際に要求するファイル名は、もとの分割前のファイル名としてもよい。これによりクライアント300上で既に受信済でキャッシュされているかの判定が容易となり、取得済データの再取得を抑制できる。この場合、配信サーバ200は元の分割されたファイル(フラグメントファイル)から結合したデータ(結合ファイル)を特定する必要がある。このためには、(1)予めクライアント300に送信する特定情報としてフラグメントファイルに対する結合ファイルの情報を送信しておきクライアント300が要求時にHTTP拡張ヘッダに記載する、(2)配信サーバ200が要求されたフラグメントファイル名から結合ファイルを要求応答時に自ら特定する、という方法がある。(2)については、(2-1)結合ファイルを作成する際にフラグメントファイルとの紐づけを記録しておく(データベース、ファイル、シンボリックリンクなど)ほか、(2-2)命名規則で自己解決するようにしておく(例えば図4の例であれば、ContentsA_1~ContentsA_4の結合ファイル名はContentsAとするなど)ことなどが考えられる。
配信サーバ200は、クライアント300から送信された特定情報を用いて、結合データから該当データを特定し、特定したデータを要求元のクライアント300に配信する。
記憶制御部218は、予め定められた条件に従い記憶部222に記憶されたデータを削除してもよい。例えば記憶制御部218は、記憶してから一定期間が経過したデータを削除してもよい。記憶制御部218は、一定時間が経過するごとに、段階的にデータを削除してもよい。例えば記憶制御部218は、所定期間(例えば1日)が経過したらPピクチャの全部または一部を記憶部222から削除し、以降は、さらに所定期間(最初の期間と同じでもよいし異なってもよい)が経過するごとにPピクチャまたはIピクチャを段階的に間引くように記憶部222から削除する。このような処理により、長期記録のため記憶容量を削減したいときに、例えば品質を低下させた映像に変換する処理を実行することなく、時間の経過とともに間欠性を増した映像を得ることが可能となる。Pピクチャの段階的な削除については、例えば特許文献1に記載のエンコード手法などを用いることができる。
また例えば記憶制御部218は、送信済みのデータを優先して削除してもよい。この際、記憶制御部218は、データが送信済みであるか否かを示すメタデータを用いて、データが送信済みであるか判定してもよい。さらに、記憶制御部218は、削除処理で参照するためのその他のメタデータを予め用意しておいてもよい。このメタデータは、例えば、どのデータがどのピクチャに該当するかを判別できるデータなどである。より具体的には、メタデータは、例えば、時刻(撮像された日時分秒など)、当該時刻内での画像の位置(例えば先頭から何番目かを示す情報など)、ファイル名、および、ファイルの先頭からのバイトオフセットなどを含む。
一時記憶部221は、受信されたデータを一時的に記憶する。例えば一時記憶部221は、DRAM(Dynamic Random Access Memory)などの揮発性のメモリにより構成することができる。
記憶部222は、配信サーバ200が使用する各種データを記憶する。例えば記憶部222は、配信対象となるコンテンツ、生成された配信リスト、および、生成された判定情報を記憶する。記憶部222は、メモリカード、RAM(Random Access Memory)、HDD(Hard Disk Drive)、光ディスクなどの一般的に利用されているあらゆる記憶媒体により構成することができる。
なお、上記のような書き出し処理の異常が生じないような場合であれば、一時記憶部221を備えないように構成してもよい。
上記各部(検出部201、リスト生成部211、判定情報生成部212、リスト送信部213、判定情報送信部214、要求送受信部215、配信部216、データ受信部217、および、記憶制御部218)は、例えば、1または複数のプロセッサにより実現される。例えば上記各部は、CPUなどのプロセッサにプログラムを実行させること、すなわちソフトウェアにより実現してもよい。上記各部は、専用のICなどのプロセッサ、すなわちハードウェアにより実現してもよい。上記各部は、ソフトウェアおよびハードウェアを併用して実現してもよい。複数のプロセッサを用いる場合、各プロセッサは、各部のうち1つを実現してもよいし、各部のうち2以上を実現してもよい。
なお配信サーバ200の各機能は、物理的または論理的に異なる複数の装置に分散されてもよい。例えば、配信リストを送信するサーバ装置と、コンテンツを送信するサーバ装置とに分けられてもよい。また、例えば、送信装置100からデータを受信して一時記憶部221および記憶部222に記憶するサーバ装置と、一時記憶部221および記憶部222からデータを読み出して配信するサーバ装置とに分けられてもよい。
次にクライアント300の機能について説明する。図3に示すように、クライアント300は、リスト受信部311と、判定情報受信部312と、判定部313と、要求送信部314と、データ受信部315と、再生部316と、記憶部321と、を備えている。
リスト受信部311は、配信リストを配信サーバ200から受信する。判定情報受信部312は、判定情報を配信サーバ200から受信する。
判定部313は、配信リストおよび判定情報に基づいて、送信を要求するコンテンツを判定する。例えば判定部313は、図4に示す配信リストにURLが記載されたコンテンツのうち、図5のように判定情報として「○」が設定されたコンテンツを、送信を要求するコンテンツとして判定する。判定情報として上述の範囲情報を用いる場合、判定部313は、例えば、範囲情報に未確定情報が設定されていないコンテンツを、送信を要求するコンテンツと判定する。複数の判定情報を用いる場合、判定部313は、複数の判定情報の組み合わせに応じて、送信を要求するコンテンツを判定してもよい。例えば判定部313は、すべての判定情報がコンテンツを送信可能であることを示す場合に、対応するコンテンツを、送信を要求するコンテンツと判定する。
要求送信部314は、送信を要求すると判定されたコンテンツの送信要求を配信サーバ200に送信する。データ受信部315は、要求送信部314により送信した送信要求に応じて送信されたコンテンツを配信サーバ200から受信する。再生部316は、受信されたコンテンツを再生する。
記憶部321は、クライアント300が使用する各種データを記憶する。例えば記憶部321は、送信された配信リスト、送信された判定情報、および、配信されたコンテンツを記憶する。
上記各部(リスト受信部311、判定情報受信部312、判定部313、要求送信部314、データ受信部315、および、再生部316)は、例えば、1または複数のプロセッサにより実現される。例えば上記各部は、CPUなどのプロセッサにプログラムを実行させること、すなわちソフトウェアにより実現してもよい。上記各部は、専用のICなどのプロセッサ、すなわちハードウェアにより実現してもよい。上記各部は、ソフトウェアおよびハードウェアを併用して実現してもよい。複数のプロセッサを用いる場合、各プロセッサは、各部のうち1つを実現してもよいし、各部のうち2以上を実現してもよい。
上記のような配信リストと判定情報とを用いることにより、配信サーバ200は、例えば、更新があるごとに配信リストを作成して送信する必要がなくなる。また、クライアント300は、判定情報を参照すれば、更新箇所をより容易に解析することができる。すなわち、配信リストを再取得および再解析することなく、最新の配信リストと同等の情報を効率的に取得および解析可能となる。
なお、判定情報を用いずに、例えば、データの更新があるごとに配信リストを作成して送信するように構成してもよい。この場合、判定情報に関する機能(判定情報生成部212、判定情報送信部214、判定情報受信部312など)は備えなくてもよい。また、例えばプッシュ型送信などを採用する場合であれば、配信サーバ200は、配信リストを用いずに映像をクライアント300に配信してもよい。
次に、本実施形態にかかる送信装置100によるデータの送信処理について説明する。図6は、本実施形態における送信処理の一例を示すフローチャートである。
撮像部101は、配信対象となる映像を撮像する(ステップS101)。符号化部111は、撮像部101から入力された映像を符号化する(ステップS102)。分割部112は、配信サーバ200に送信するデータと、記憶部121に記憶するデータと、に分割する。例えば分割部112は、入力された映像を、Iピクチャのフラグメントと、Pピクチャのフラグメントとに分割する(ステップS103)。データ送信部113は、Iピクチャのフラグメントを、配信サーバ200に送信する(ステップS104)。記憶制御部114は、Pピクチャのフラグメントを、記憶部121に記憶する(ステップS105)。
次に、記憶部121に記憶されたデータの送信処理について説明する。図7は、記憶部121に記憶されたデータの送信処理の一例を示すフローチャートである。
要求受信部115は、配信サーバ200(または制御サーバ)から、記憶部121に記憶されたデータの送信要求を受信する(ステップS201)。記憶部121にPピクチャが記憶されている場合は、要求受信部115は、記憶されたPピクチャのうちいずれかのPピクチャの送信要求を受信する。データ送信部113は、要求されたPピクチャを記憶部121から読み出し、配信サーバ200に送信する(ステップS202)。
次に、このように構成された本実施形態にかかる配信サーバ200によるリスト生成処理について説明する。リスト生成処理は、配信サーバ200が配信リストを生成する処理である。図8は、本実施形態におけるリスト生成処理の一例を示すフローチャートである。
配信サーバ200のリスト生成部211は、例えばクライアント300からの要求に応じて、配信リストを生成する(ステップS301)。リスト生成部211は、生成した配信リストを例えば記憶部222に記憶する(ステップS302)。
一例として、時間的に連続したコンテンツであるContentA_1、ContentA_2、ContentA_3、およびContentA_4が配信予定のコンテンツとして存在し、ContentA_1とContentA_3が配信可能であるとする。この場合、リスト生成部211は、ContentA_1、ContentA_2、ContentA_3、およびContentA_4を配信するための配信リストを生成する。上述の図4は、このときに生成される配信リストの一例を示す。
次に、本実施形態にかかる配信サーバ200による判定情報生成処理について説明する。判定情報生成処理は、配信サーバ200が判定情報を生成する処理である。判定情報生成処理は、例えばクライアント300から判定情報の送信要求があった場合に実行される。図9は、本実施形態における判定情報生成処理の一例を示すフローチャートである。
配信サーバ200の判定情報生成部212は、配信予定のコンテンツについて、判定情報を生成済みであるか否かを判定する(ステップS401)。判定情報を生成済みでない場合(ステップS401:No)、判定情報生成部212は、当該コンテンツについての判定情報を生成する(ステップS402)。上述の図5は、図8で説明した例(ContentA_1とContentA_3が配信可能である例)に対して生成される判定情報の一例を示す。
判定情報を生成した後、および、判定情報を生成済みの場合(ステップS401:Yes)、判定情報生成部212は、生成済みの判定情報を更新するか否かを判定する(ステップS403)。例えば判定情報生成部212は、検出部201からコンテンツが送信可能になったことを示す検出結果を受け取った場合に、判定情報を更新すると判定する。
判定情報を更新すると判定した場合(ステップS403:Yes)、判定情報生成部212は、判定情報を更新する(ステップS404)。判定情報を更新した後、および、判定情報を更新しないと判定した場合(ステップS403:No)、判定情報生成処理を終了する。
配信サーバ200は、生成した配信リストおよび判定情報を、ネットワーク402を介して配信可能な状態にする。クライアント300は、配信サーバ200にアクセスして配信リストおよび判定情報を取得することが可能となる。
次に、本実施形態にかかる通信システムによるコンテンツ配信処理について説明する。図10は、本実施形態におけるコンテンツ配信処理の一例を示すシーケンス図である。
配信サーバ200のリスト生成部211は、配信リストを生成する(ステップS501)。この処理は、例えば上述のリスト生成処理に相当する。配信サーバ200のリスト送信部213は、例えばクライアント300からの要求に応じて、配信リストをクライアント300に送信する(ステップS502)。
配信サーバ200の判定情報生成部212は、判定情報を生成する(ステップS503)。この処理は、例えば上述の判定情報生成処理に相当する。配信サーバ200の判定情報送信部214は、例えばクライアント300からの要求に応じて、判定情報をクライアント300に送信する(ステップS504)。
クライアント300のリスト受信部311が配信リストを受信し、判定情報受信部312が判定情報を受信する。その後、クライアント300の判定部313は、受信した配信リストおよび判定情報を用いて、送信を要求するコンテンツを判定する(ステップS505)。例えば図4に示す配信リストを受信した場合、判定部313は、受信した配信リストを解析することで、ContentA_1~ContentA_4をそれぞれ取得するためのURLを得る。また判定部313は、受信した判定情報を解析し、配信リストに記載されたコンテンツのうち、送信可能なコンテンツを判定する。
図11は、図4に示す配信リストに対して図5に示す判定情報を用いて判定する例を説明する図である。図11に示すように、配信リストに記載のContentA_1を取得するためのURLと、ContentA_1に対応する判定情報とを組み合わせることで、判定部313は、ContentA_1が送信可能(アクセス可能)であると判定できる。同様に判定部313は、ContentA_2が送信不可(アクセス不可)であると判定できる。
図10に戻り、要求送信部314は、送信を要求すると判定されたコンテンツの送信要求を、配信サーバ200に送信する(ステップS506)。配信サーバ200の配信部216は、要求されたコンテンツをクライアント300に送信する(ステップS507)。クライアント300のデータ受信部315がコンテンツを受信し、再生部316が、受信したコンテンツを再生する(ステップS508)。
なお、配信サーバ200でそのまま配信可能な形式で表されたコンテンツが送信装置100から送信される場合は、配信部216は、送信装置100から送信されたコンテンツを変換せずに、そのままクライアント300に送信する。配信サーバ200が配信する形式に変換できるようなメタデータが付加された形式でコンテンツが送信される場合は、配信部216は、送信されたコンテンツを、メタデータに従って配信可能な形式に変換し、変換したコンテンツをクライアント300に送信する。
この後、ContentA_2が配信可能な状態となったとする。このとき、配信サーバ200の検出部201は、ContentA_2が配信可能な状態となったことを検出する。判定情報生成部212は、検出結果に応じて更新した判定情報を生成する(ステップS509)。
図12は、更新した判定情報の一例を示す図である。判定情報生成部212は、図12に示すように、ContentA_2に対応する判定情報を「×」から「○」に更新する。更新された判定情報は、ネットワーク402を介して配信可能な状態にされる。
図10に戻り、配信サーバ200の判定情報送信部214は、例えばクライアント300からの要求に応じて、更新された判定情報をクライアント300に送信する(ステップS510)。この後のステップS511からステップS514は、ステップS505からステップS508と同様である。
図13は、図4に示す配信リストに対して図12に示す判定情報を用いて判定する例を説明する図である。図13に示すように、判定部313は、ContentA_2が送信可能(アクセス可能)な状態になったことを判定できる。
このようにクライアント300は、ContentA_2が配信可能な状態となったときに、配信リストを再取得することなく、既に受信済みの配信リストに対して、更新された判定情報を適用するのみで、各コンテンツの最新の状態を得ることが可能となる。
本実施形態は、例えば、ドライブレコーダで撮像した映像を監視するシステムに適用できる。適用可能なシステムはこれに限られるものではない。例えば、センサにより得らえたセンサデータを配信して監視するシステム、および、移動体に搭載された撮像装置などにより得られた動画像データを配信して監視するシステムに適用してもよい。移動体は、例えば、人、ロボット、車両(自動車、二輪車、電車など)、台車、飛行可能な物体(有人飛行機、無人飛行機(例えば、UAV(Unmanned Aerial Vehicle)、ドローン)、および、パーソナルモビリティ、などである。また、移動体は、例えば、人による運転操作を介して走行する移動体、および、人による運転操作を介さずに自動的に走行(自動運転)可能な移動体である。
本実施形態は、例えば、機器の監視制御システムの画面(HMI:Human Machine Interface)の操作履歴を監視する監視システムに適用することもできる。画面の操作履歴は、例えば、表示装置に表示される画面をキャプチャして記録する機能により得ることができる。このようにして得られる画像データを、送信装置100により撮像される映像の代わりに用いることができる。
機器の監視制御システムでは、通常、多数の監視画面が使用されるため、画面の操作履歴の監視システムは、多数の監視画面の画像を並べて監視する必要が生じる場合がある。一般に、このように多数の映像を並行して表示させる処理は処理負荷が高くなるが、本実施形態では分割したデータ(例えばIピクチャ)のみを表示させることができるため、処理負荷の増加を抑制することができる。
(変形例1)
ネットワーク401を、複数の通信回線により構成し、分割部112により分割されたデータの一部(例えばIピクチャ)を複数の通信回線のいずれか(通信回線401Aとする)により配信サーバ200に送信し、残りのデータ(例えばPピクチャ)を複数の通信回線のうち他の通信回線(通信回線401Bとする)により配信サーバ200に送信するように構成してもよい。図14は、このように構成された変形例1の映像配信システムの構成例を示す図である。例えばデータ送信部113は、Iピクチャを通信回線401Aによりライブ配信し、Pピクチャを通信回線401Bにより、任意のタイミングで送信してもよい。
ネットワーク401を、複数の通信回線により構成し、分割部112により分割されたデータの一部(例えばIピクチャ)を複数の通信回線のいずれか(通信回線401Aとする)により配信サーバ200に送信し、残りのデータ(例えばPピクチャ)を複数の通信回線のうち他の通信回線(通信回線401Bとする)により配信サーバ200に送信するように構成してもよい。図14は、このように構成された変形例1の映像配信システムの構成例を示す図である。例えばデータ送信部113は、Iピクチャを通信回線401Aによりライブ配信し、Pピクチャを通信回線401Bにより、任意のタイミングで送信してもよい。
(変形例2)
分割したデータを配信サーバ200に送信せず、分割したデータを、送信装置100内の記憶部121に分けて記憶するように構成してもよい。これにより、例えば記憶部121から必要なピクチャ(例えばIピクチャ)のみを読み出して表示させることなどが可能になる。Iピクチャのみを表示させる方法は、Pピクチャも含むすべてのピクチャを表示させる方法より処理負荷を軽減できる。従って、例えば処理能力が限られるクライアント300などであっても、複数の送信装置100の記憶部121からIピクチャのみを読み出して並行して表示させることが可能になる。さらに、必要に応じて残りのPピクチャなどを段階的に読み込出して動きのある表示とすることが可能となる。
分割したデータを配信サーバ200に送信せず、分割したデータを、送信装置100内の記憶部121に分けて記憶するように構成してもよい。これにより、例えば記憶部121から必要なピクチャ(例えばIピクチャ)のみを読み出して表示させることなどが可能になる。Iピクチャのみを表示させる方法は、Pピクチャも含むすべてのピクチャを表示させる方法より処理負荷を軽減できる。従って、例えば処理能力が限られるクライアント300などであっても、複数の送信装置100の記憶部121からIピクチャのみを読み出して並行して表示させることが可能になる。さらに、必要に応じて残りのPピクチャなどを段階的に読み込出して動きのある表示とすることが可能となる。
この場合、記憶制御部114は、配信サーバ200の記憶制御部218と同様に、記憶してから一定期間が経過したデータを削除してもよいし、一定時間が経過するごとに、段階的にデータを削除してもよい。例えば、記憶容量が足りなくなった場合などに、IピクチャおよびPピクチャを含む全データを古い順に削除するのではなく、Pピクチャのみ削除してIピクチャを間欠表示できるデータとして残しておくことが可能となり、データの長期保存と低容量化を両立できる。
(変形例3)
ピクチャごとに映像を分割して配信すると、配信リストのサイズが増大する可能性がある。そこで、リスト生成部211は、階層構造を有する複数のファイルにより配信リストを作成してもよい。例えば、リスト生成部211は、年、月、日、時間などを単位として階層的に配信リストを構成してもよい。例えば最下層の配信リストは、ある範囲の時間に分割されたフラグメントデータそれぞれの識別情報を含む。次の上位の配信リストは、ある日に含まれる時間に対応する1以上の配信リストを識別する情報を含む。次の上位の配信リストは、ある月に含まれる日に対応する1以上の配信リストを識別する情報を含む。次の上位の配信リストは、ある年に含まれる月に対応する1以上の配信リストを識別する情報を含む。
ピクチャごとに映像を分割して配信すると、配信リストのサイズが増大する可能性がある。そこで、リスト生成部211は、階層構造を有する複数のファイルにより配信リストを作成してもよい。例えば、リスト生成部211は、年、月、日、時間などを単位として階層的に配信リストを構成してもよい。例えば最下層の配信リストは、ある範囲の時間に分割されたフラグメントデータそれぞれの識別情報を含む。次の上位の配信リストは、ある日に含まれる時間に対応する1以上の配信リストを識別する情報を含む。次の上位の配信リストは、ある月に含まれる日に対応する1以上の配信リストを識別する情報を含む。次の上位の配信リストは、ある年に含まれる月に対応する1以上の配信リストを識別する情報を含む。
(変形例4)
図15は、変形例4の映像配信システムによる配信処理の概要を示す図である。本変形例の映像配信システムは、制御サーバ510と、Webサーバ520と、をさらに備えている。なお本変形例では、配信サーバ200は、ビデオ(映像)を配信するWebサーバとして構成される。
図15は、変形例4の映像配信システムによる配信処理の概要を示す図である。本変形例の映像配信システムは、制御サーバ510と、Webサーバ520と、をさらに備えている。なお本変形例では、配信サーバ200は、ビデオ(映像)を配信するWebサーバとして構成される。
制御サーバ510は、制御部511を備える。制御部511は、クライアント300から送信される要求に従い、送信装置100を制御する。例えばクライアント300は、ピクチャを分割して一部のみ(例えば、Iピクチャのみ)を送信するか、すべてのピクチャを送信するかを示す送信要求を制御サーバ510に送信する。制御サーバ510の制御部511は、送信要求に従い、一部のピクチャのみを分割して配信サーバ200に送信(アップロード)するか、または、すべてのピクチャを配信サーバ200に送信するかを示す制御信号を、送信装置100に送信する。
送信装置100は、制御サーバ510から送信された制御信号に従い、上記実施形態のように分割した一部のピクチャのみを配信サーバ200に送信するか、または、すべてのピクチャを配信サーバ200に送信するかを切り替えて動作する。
キャプチャストリーム送信(アップロード送信)は、配信サーバ200に送信するデータ(第1データ)として分割されたデータを配信サーバ200に送信することを表す。キャプチャファイル保存(ファイル出力)は、配信サーバ200に送信せずに記憶部121に記憶するデータ(第2データ)として分割されたデータを記憶することを表す。図15に示すように、記憶したデータは、オフラインで配信サーバ200にコピーしてもよい。
配信サーバ200は、必要に応じて、データ受信部217により受信したデータを配信可能な形式に変換(ストリーム変換)し、記憶部222に記憶する。オフラインでコピーしたデータは、一括して変換(バッチ変換)して記憶部222に記憶してもよい。
記憶部222は、配信可能な形式の各ピクチャ(フラグメントファイル)、および、配信リストなどを記憶する。配信サーバ200は、記憶部222に記憶されたピクチャを配信するビデオサーバとして機能する。上記のように、データ受信部217で受信されたデータを一時記憶部221に記憶し、一時記憶部221に記憶されたデータを配信部216により配信してもよい。
クライアント300は、ビューワを備えるWebブラウザを備えている。Webブラウザは、ビデオを再生するビデオプレイヤを備えている。ビデオプレイヤは、例えば、HTML5に準拠したアプリケーションとして実現される。
Webサーバ520は、ビデオサーバの機能以外の機能を備えるサーバ装置である。例えばWebサーバ520は、映像配信システムとは異なる外部システムのためのユーザインタフェース(UI)を提供するためのサーバ装置である。
このように、上記実施形態の映像配信システムは、例えばインターネット上で利用されるWebシステムとして実現することができる。
以上のように、本実施形態にかかる映像配信システムでは、品質を低下させることなく、回線負荷や処理負荷を低減することが可能となる。
次に、本実施形態にかかる送信装置のハードウェア構成について図16を用いて説明する。図16は、本実施形態にかかる送信装置のハードウェア構成例を示す説明図である。
本実施形態にかかる送信装置は、CPU51などの制御装置と、ROM(Read Only Memory)52やRAM53などの記憶装置と、ネットワークに接続して通信を行う通信I/F54と、各部を接続するバス61を備えている。
本実施形態にかかる送信装置で実行されるプログラムは、ROM52等に予め組み込まれて提供される。
本実施形態にかかる送信装置で実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでCD-ROM(Compact Disk Read Only Memory)、フレキシブルディスク(FD)、CD-R(Compact Disk Recordable)、DVD(Digital Versatile Disk)等のコンピュータで読み取り可能な記録媒体に記録してコンピュータプログラムプロダクトとして提供されるように構成してもよい。
さらに、本実施形態にかかる送信装置で実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、本実施形態にかかる送信装置で実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
本実施形態にかかる送信装置で実行されるプログラムは、コンピュータを上述した送信装置の各部として機能させうる。このコンピュータは、CPU51がコンピュータ読取可能な記憶媒体からプログラムを主記憶装置上に読み出して実行することができる。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
100 送信装置
101 撮像部
111 符号化部
112 分割部
113 データ送信部
114 記憶制御部
115 要求受信部
121 記憶部
200 配信サーバ
201 検出部
211 リスト生成部
212 判定情報生成部
213 リスト送信部
214 判定情報送信部
215 要求送受信部
216 配信部
217 データ受信部
218 記憶制御部
221 一時記憶部
222 記憶部
300 クライアント
311 リスト受信部
312 判定情報受信部
313 判定部
314 要求送信部
315 データ受信部
316 再生部
321 記憶部
401、 402 ネットワーク
510 制御サーバ
511 制御部
520 Webサーバ
101 撮像部
111 符号化部
112 分割部
113 データ送信部
114 記憶制御部
115 要求受信部
121 記憶部
200 配信サーバ
201 検出部
211 リスト生成部
212 判定情報生成部
213 リスト送信部
214 判定情報送信部
215 要求送受信部
216 配信部
217 データ受信部
218 記憶制御部
221 一時記憶部
222 記憶部
300 クライアント
311 リスト受信部
312 判定情報受信部
313 判定部
314 要求送信部
315 データ受信部
316 再生部
321 記憶部
401、 402 ネットワーク
510 制御サーバ
511 制御部
520 Webサーバ
Claims (10)
- 複数の送信データの一部である第1データを送信装置から受信するデータ受信部と、
前記第1データを受信装置に配信する配信部と、を備え、
前記データ受信部は、さらに、複数の前記送信データのうち前記第1データ以外の第2データの送信要求に応じて前記送信装置から送信された前記第2データを受信し、
前記配信部は、前記第2データを前記受信装置に配信し、
予め定められた条件に従い、前記送信装置から送信された前記第1データおよび前記第2データを記憶する記憶部に記憶された前記第1データおよび前記第2データの少なくとも一方である対象データの全部または一部を削除する記憶制御部と、をさらに備える、
サーバ装置。 - 前記記憶制御部は、記憶してから一定期間が経過した前記対象データの全部または一部を削除する、
請求項1に記載のサーバ装置。 - 前記記憶制御部は、所定期間が経過するごとに、前記対象データの全部または一部を削除する、
請求項1に記載のサーバ装置。 - 前記記憶制御部は、前記受信装置に配信済みの前記対象データを優先して前記記憶部から削除する、
請求項1に記載のサーバ装置。 - 前記記憶制御部は、配信済みであるか否かを示すメタデータを用いて、前記対象データが前記受信装置に配信済みであるか判定する、
請求項4に記載のサーバ装置。 - 前記記憶制御部は、削除処理で参照するためのメタデータを用いて、前記対象データの全部または一部を削除する、
請求項1に記載のサーバ装置。 - 前記メタデータは、時刻、前記対象データを含むファイルの先頭を基準とする位置を示す情報、および、前記ファイルのファイル名を含む、
請求項6に記載のサーバ装置。 - 前記記憶部を備える、
請求項1に記載のサーバ装置。 - サーバ装置で実行される送信方法であって、
複数の送信データの一部である第1データを送信装置から受信する第1データ受信ステップと、
前記第1データを受信装置に配信する第1配信ステップと、
複数の前記送信データのうち前記第1データ以外の第2データの送信要求に応じて前記送信装置から送信された前記第2データを受信する第2データ受信ステップと、
前記第2データを前記受信装置に配信する第2配信ステップと、
予め定められた条件に従い、前記送信装置から送信された前記第1データおよび前記第2データを記憶する記憶部に記憶された前記第1データおよび前記第2データの少なくとも一方である対象データの全部または一部を削除する記憶制御ステップと、
を含む送信方法。 - コンピュータに、
複数の送信データの一部である第1データを送信装置から受信する第1データ受信ステップと、
前記第1データを受信装置に配信する第1配信ステップと、
複数の前記送信データのうち前記第1データ以外の第2データの送信要求に応じて前記送信装置から送信された前記第2データを受信する第2データ受信ステップと、
前記第2データを前記受信装置に配信する第2配信ステップと、
予め定められた条件に従い、前記送信装置から送信された前記第1データおよび前記第2データを記憶する記憶部に記憶された前記第1データおよび前記第2データの少なくとも一方である対象データの全部または一部を削除する記憶制御ステップと、
を実行させるためのプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2023099839A JP2023112033A (ja) | 2018-11-02 | 2023-06-19 | 送信装置、サーバ装置、送信方法およびプログラム |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2018207604A JP7105675B2 (ja) | 2018-11-02 | 2018-11-02 | 送信装置、サーバ装置、送信方法およびプログラム |
JP2022111201A JP7302076B2 (ja) | 2018-11-02 | 2022-07-11 | 送信装置、サーバ装置、送信方法およびプログラム |
JP2023099839A JP2023112033A (ja) | 2018-11-02 | 2023-06-19 | 送信装置、サーバ装置、送信方法およびプログラム |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2022111201A Division JP7302076B2 (ja) | 2018-11-02 | 2022-07-11 | 送信装置、サーバ装置、送信方法およびプログラム |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2023112033A true JP2023112033A (ja) | 2023-08-10 |
JP2023112033A5 JP2023112033A5 (ja) | 2023-08-18 |
Family
ID=86996674
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2022111201A Active JP7302076B2 (ja) | 2018-11-02 | 2022-07-11 | 送信装置、サーバ装置、送信方法およびプログラム |
JP2023099839A Pending JP2023112033A (ja) | 2018-11-02 | 2023-06-19 | 送信装置、サーバ装置、送信方法およびプログラム |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2022111201A Active JP7302076B2 (ja) | 2018-11-02 | 2022-07-11 | 送信装置、サーバ装置、送信方法およびプログラム |
Country Status (1)
Country | Link |
---|---|
JP (2) | JP7302076B2 (ja) |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1998034405A1 (en) | 1997-01-30 | 1998-08-06 | Microsoft Corporation | Vcr-like functions rendering video on demand |
JP4447860B2 (ja) | 2003-06-30 | 2010-04-07 | ソニー株式会社 | ネットワークカメラ |
JP5261785B2 (ja) | 2007-10-31 | 2013-08-14 | 株式会社日立製作所 | コンテンツ配信システム、キャッシュサーバ及びキャッシュ管理サーバ |
JP2011249865A (ja) | 2010-05-21 | 2011-12-08 | Nippon Telegr & Teleph Corp <Ntt> | コンテンツサーバ、コンテンツ配信システム、コンテンツ配信方法、およびプログラム |
JP2012175274A (ja) | 2011-02-18 | 2012-09-10 | Nippon Telegr & Teleph Corp <Ntt> | コンテンツ配信システム、コンテンツ配信方法、ならびにコンテンツ配信システムに用いられるピア、アプリケーションサーバ及びキャッシュサーバ |
JP6239472B2 (ja) | 2014-09-19 | 2017-11-29 | 株式会社東芝 | エンコード装置、デコード装置、ストリーミングシステム、および、ストリーミング方法 |
JP6686541B2 (ja) | 2016-03-04 | 2020-04-22 | 日本電気株式会社 | 情報処理システム |
-
2022
- 2022-07-11 JP JP2022111201A patent/JP7302076B2/ja active Active
-
2023
- 2023-06-19 JP JP2023099839A patent/JP2023112033A/ja active Pending
Also Published As
Publication number | Publication date |
---|---|
JP7302076B2 (ja) | 2023-07-03 |
JP2022125359A (ja) | 2022-08-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP7105675B2 (ja) | 送信装置、サーバ装置、送信方法およびプログラム | |
US9106934B2 (en) | Distribution of adaptive bit rate live streaming video via hyper-text transfer protocol | |
US9832492B2 (en) | Distribution of adaptive bit rate video streaming via hyper-text transfer protocol | |
US20070143807A1 (en) | Data distribution apparatus, data provision apparatus and data distribution system comprised thereof | |
US20110037864A1 (en) | Method and apparatus for live capture image | |
JP2018182447A (ja) | 映像配信装置、映像配信方法及びプログラム | |
CN114501052A (zh) | 直播数据处理方法、云平台、计算机设备和存储介质 | |
TWI731579B (zh) | 傳輸裝置、通訊系統、傳輸方法及電腦程式產品 | |
JP2019092133A (ja) | 送信装置、受信装置、通信システムおよびプログラム | |
JP7302076B2 (ja) | 送信装置、サーバ装置、送信方法およびプログラム | |
JP7419151B2 (ja) | サーバ装置、情報処理方法およびプログラム | |
KR102291293B1 (ko) | 송신 디바이스, 통신 시스템, 송신 방법, 및 비일시적 컴퓨터 판독가능 기록 매체 | |
KR102613872B1 (ko) | 서버 디바이스, 통신 시스템, 및 비일시적 컴퓨터 판독가능 기록 매체 | |
CN113315997B (zh) | 发送装置、服务器装置、发送方法以及程序 | |
CN113542747B (zh) | 服务器装置、通信系统以及存储介质 | |
WO2017179271A1 (ja) | 監視カメラシステム及び監視カメラデータ保存方法 | |
JP2020150321A (ja) | 動画配信装置、動画配信方法及びプログラム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20230619 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20230802 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20240620 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20240625 |