JP7022540B2 - 情報処理装置およびその制御方法 - Google Patents

情報処理装置およびその制御方法 Download PDF

Info

Publication number
JP7022540B2
JP7022540B2 JP2017173222A JP2017173222A JP7022540B2 JP 7022540 B2 JP7022540 B2 JP 7022540B2 JP 2017173222 A JP2017173222 A JP 2017173222A JP 2017173222 A JP2017173222 A JP 2017173222A JP 7022540 B2 JP7022540 B2 JP 7022540B2
Authority
JP
Japan
Prior art keywords
stream
individual
request
information processing
reception
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.)
Active
Application number
JP2017173222A
Other languages
English (en)
Other versions
JP2019050487A (ja
Inventor
英之 池上
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to JP2017173222A priority Critical patent/JP7022540B2/ja
Priority to EP18191376.5A priority patent/EP3454563A1/en
Priority to CN201810993475.3A priority patent/CN109474835B/zh
Priority to US16/120,724 priority patent/US10868847B2/en
Publication of JP2019050487A publication Critical patent/JP2019050487A/ja
Application granted granted Critical
Publication of JP7022540B2 publication Critical patent/JP7022540B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/231—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion
    • H04N21/23103—Content storage operation, e.g. caching movies for short term storage, replicating data over plural servers, prioritizing data for deletion using load balancing strategies, e.g. by placing or distributing content on different disks, different memories or different servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/239—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
    • H04N21/2393—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/438—Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N23/00—Cameras or camera modules comprising electronic image sensors; Control thereof
    • H04N23/60—Control of cameras or camera modules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N23/00—Cameras or camera modules comprising electronic image sensors; Control thereof
    • H04N23/60—Control of cameras or camera modules
    • H04N23/66—Remote control of cameras or camera parts, e.g. by remote control devices
    • H04N23/661—Transmitting camera control signals through networks, e.g. control via the Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/18—Closed-circuit television [CCTV] systems, i.e. systems in which the video signal is not broadcast

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Description

本発明は、情報処理装置およびその制御方法に関する。
ネットワークカメラからの映像の配信はクライアントからの１つのリクエストに対して複数の画像（映像ストリーム）を配信するストリーム配信と、クライアントからの１つのリクエストに対して１つの画像（個別画像）を送信する個別配信がある。一般に、ストリーム受信可能なクライアントは高速受信するためにストリーム配信をリクエストし、映像ストリームを受信して表示する。一方、ストリーム受信不可能なクライアントは個別配信をリクエストし、個別画像を受信して表示する。
ストリーム配信では、ネットワークカメラがクライアントからリクエストを受信すると一方的に配信を行うため高速な配信が可能となる。よって、ストリーム配信は高速で映像を表示したい時に利用される。個別配信では、ネットワークカメラがクライアントから個別リクエストを受信して個別の画像を送信するという動作が繰り返される。個別配信はクライアントの環境を選ばず例えばブラウザ上でも表示が可能である。
このようなストリーム配信と個別配信の両方を場合に応じて選択して利用するクライアントが提案されている。特許文献１では、通常はストリーム配信を表示し、映像ストリームの切り替えの際に画像が乱れてしまう場合に、個別配信の画像を表示する技術が開示されている。
特開２００８－２１１５０３号公報
しかしながら、クライアントがストリーム受信をリクエストした場合に、特にプロキシを介した通信により映像ストリームの受信を行う際には映像ストリームを受信できない場合がある。これは、画像ソースからデータが分割送信された場合に、プロキシがそれらの分割されたデータを貯め込み、すべてのデータを受信してからまとめて送信する場合があるからである。映像ストリームのような分割データの送信は、例えばｈｔｔｐのチャンク形式などを用いて行われる。チャンク形式では、分割されたデータが途中データなのか最終データなのか分かる形式で送信される。プロキシは、画像ソースから最終データが受信されるまでデータ（途中データ）を蓄積し、最終データが受信されると、それまでに蓄積したデータをまとめてクライアントへ送信する。
画像ソースがカメラの場合、映像ストリームのデータ（分割データ）は例えばチャンク形式における途中データが送り続けられる。この場合、最終データが受信されないため、プロキシはカメラから受信した映像を貯め込むだけでクライアントに送信しない。その結果、映像はいつまでたってもクライアントに届かず、クライアントでは映像がまったく表示されないという課題が発生する。
本発明は、上記の課題に鑑みてなされたものであり、クライアントがカメラからの画像を適切に受信できるようにすることを目的とする。
本発明の一態様による情報処理装置は以下の構成を備える。すなわち、
外部装置から映像を受信する受信処理を実行する情報処理装置であって、
前記外部装置へ映像ストリームを要求するためのストリームリクエストを送信してから所定時間内に前記外部装置から映像ストリームを受信したか否かを判定する判定手段と、
前記判定手段により映像ストリームが受信されたと判定された場合は前記外部装置へストリームリクエストを送信して映像ストリームを受信するストリーム受信動作を継続し、前記判定手段により映像ストリームが受信されなかったと判定された場合は前記外部装置へ前記映像ストリームに含まれる画像を個別に要求する個別リクエストを送信して個別に画像を受信する個別受信動作を実行する実行手段と、を備える。
本発明によれば、クライアントがカメラからの画像を適切に受信できる。
カメラのストリーム配信と個別配信を説明する図。 プロキシの介在による分割送信の動作を説明する図。 プロキシの介在によりクライアントに映像ストリームが届かない様子を示す図。 実施形態によるカメラおよびクライアントの機能構成例を示すブロック図。 クライアントで表示されるビューワ画面を示す図。 第１実施形態のクライアント、プロキシ、カメラの動作を説明する図。 クライアントで表示されるビューワ画面を示す図。 第１実施形態のクライアント、プロキシ、カメラの動作を説明する図。 第１実施形態の受信処理を示すフローチャート。 第１実施形態の受信処理を示すフローチャート。 第２実施形態のクライアント、プロキシ、カメラの動作を説明する図。 第２実施形態の受信処理を示すフローチャート。 実施形態によるクライアントのハードウエア構成例を示すブロック図。
＜第１実施形態＞
以下に、本発明の好ましい実施の形態を、添付の図面に基づいて詳細に説明する。
まず、実施形態によるストリーム配信と個別配信について図１を用いて説明する。図１（ａ）はストリーム配信をクライアントで受信して表示する場合のシーケンス図である。クライアント１０１が映像ストリームを要求するためのストリームリクエストを送信し（ステップ１１０）、それをカメラ１０２が受信すると（ステップ１１１）、カメラ１０２はストリーム配信を行う（ステップ１１２）。ストリーム配信では、カメラ１０２により撮影された映像が映像ストリームとして送信される。クライアント１０１はカメラ１０２から送信された映像ストリームを受信し表示を行う（ステップ１１３）。
図１（ｂ）はカメラ１０２から個別配信された画像をクライアント１０１で受信して表示する場合のシーケンス図である。クライアント１０１が個別リクエストを送信し（ステップ１２０）、カメラ１０２はこの個別リクエストを受信すると個別配信を行う（ステップ１２１）。個別配信では、カメラ１０２により撮影された映像のうちの１コマ（フレーム）の画像（以下、個別画像ともいう）が配信される。個別配信では、１コマではなく、２コマや３コマなど、複数コマの画像を要求及び配信するようにしてもよい。クライアント１０１は、カメラ１０２が送信した画像を受け取り、表示する（ステップ１２３）。続いて、クライアント１０１は次の個別リクエストを送ると（ステップ１２４）、カメラ１０２はこの個別リクエストを受信し（ステップ１２５）、次の画像を配信する（ステップ１２６）。クライアント１０１はこの画像を受信し、表示する（ステップ１２７）。この様な動作を繰り返すことにより、クライアント１０１は、カメラ１０２から個別配信により受信された画像を表示する。
次に、図２、図３を参照して、クライアント１０１と画像ソースの間にデータ送信を中継するプロキシ１０３が介在し、プロキシ１０３が分割された途中データを貯め込んでから送信する設定となっている場合を説明する。
図２（ａ）は、クライアント１０１がプロキシ１０３経由で画像ソースとしてのサーバ１０４と繋がっている事を示している。図２（ｂ）は、途中データを溜め込んでから一度に送信する設定となっているプロキシ１０３が介在する場合の動作を示すシーケンス図である。まず、クライアント１０１はサーバ１０４に対してリクエストを送信する（ステップ２００）。プロキシ１０３はこのリクエストを受け取るとそのままサーバ１０４へ送信する（ステップ２１０）。サーバ１０４はリクエストを受信すると（ステップ２２０）、送信対象のデータを分割して送信することにより返答を行う（ステップ２２１）。データの分割および配信には、例えばｈｔｔｐのチャンク形式が用いられ得る。ステップ２２１において送信されるデータはデータが終了という情報が付加されていない途中データであり、プロキシ１０３はこれらのデータを貯めておく（ステップ２１１）。その後、サーバ１０４が分割データの最終であることを示した最終データを送信する（ステップ２２２）。プロキシ１０３は、この最終データを受信すると（ステップ２１２）、プロキシ１０３は、それまでに貯めておいた途中データと最終データをまとめてクライアント１０１へ送信する（ステップ２１３）。こうして、クライアント１０１は、分割して送信されたデータをまとめて受信する（ステップ２０１）。
次に、図３（ａ）を参照して、途中データを貯め込むプロキシ１０３を介して、カメラ１０２の映像を図１（ａ）のようなストリーム配信で受信しようとした場合の動作を説明する。
クライアント１０１はプロキシ１０３を経由してインターネット上にあるカメラ１０２につながっている。まず、クライアント１０１はストリームリクエストを送信する（ステップ３００）。プロキシ１０３はこのストリームリクエストを受信すると、そのままカメラ１０２に送信する（ステップ３１０）。カメラ１０２では、ストリームリクエストを受信すると（ステップ３２０）、撮影により得られた映像をストリーム映像の形式で返信する（ステップ３２１）。ここで、カメラ１０２からは、例えばチャンク形式における終了情報のない途中データとして、映像ストリームが送り続けられる。カメラ１０２からはいつまでたっても終了データが付加されたデータが送信されないので、プロキシ１０３は途中データであるストリームデータを貯め込むだけでクライアント１０１に映像を送信しない（ステップ３１１）。その結果、クライアント１０１では映像をいつまでたっても受信することができず、映像を表示することができない（ステップ３０１）。
図４は、本実施形態のクライアント１０１およびカメラ１０２の機能構成例を示すブロック図である。クライアント１０１は、外部装置であるカメラ１０２から映像を受信する受信処理を実行する。
本実施形態では、クライアント１０１とカメラ１０２がネットワーク４５０によって、不図示のプロキシを介して接続されている。ネットワーク４５０に接続されるクライアントおよびカメラの数に制限はないが、説明の簡略化のため各々１台ずつが接続されていると仮定する。ネットワーク４５０に関しても、後で述べるカメラ制御信号、圧縮した画像信号を通すのに十分な帯域があるディジタルネットワークであれば、インターネットやイントラネット等、どのようなものでもよい。なお、本実施形態ではネットワークプロトコルとしてＴＣＰ／ＩＰ（ＵＤＰ／ＩＰ）プロトコルを仮定し、以下アドレスといった場合にはＩＰアドレスを指すこととする。また、クライアント１０１およびカメラ１０２は、共にＩＰアドレスを割り当てられているものとする。
本実施形態のカメラ１０２はカメラ機能と映像を配信するサーバ機能を有する、カメラサーバ装置である。なお、カメラ機能とサーバ機能は別体の装置により実現されてもよいし、１つの装置として実現されてもよい。カメラ１０２は、通信制御部４１４でクライアントから受信したコマンドに応じて、ネットワーク４５０を介して画像データを配信するともに、各種カメラ制御を実行する。画像入力部４１５はビデオカメラ４１１による撮影画像（動画および静止画）を取り込む。画像入力部４１５は、全体画像を扱うように設定されている場合は画像全体を取り込み、切り出し画像を扱うように設定されている場合には画像の一部を取り込む。取り込まれた撮影画像は、画像圧縮部４１６によってクライアント１０１に配信しやすいデータサイズに圧縮される。記憶部４１８は各種設定値およびデータを保持する。
ビデオカメラ４１１は可動雲台４１２に取り付けられている。カメラ・雲台制御部４１３は、通信制御部４１４が受信し、コマンド解釈部４１７が解釈したコマンドによって指定される制御内容に応じて可動雲台４１２を制御する。これにより、例えばビデオカメラ４１１のパン・チルト・ローテート角度が制御される。
認証部４１９は通信制御部４１４を介して認証情報が送られてきたときに認証を許可するか否かを判断する。カメラ１０２にはゲストと管理者というユーザ操作モードがあるが、ゲストと管理者では実行可能な機能が異なる。認証部４１９ではユーザが入力した文字列とパスワードを用いて認証を行い、認証に成功すればユーザが管理者であると認定して、管理者用の操作モードへ移行する。管理者用の操作モードでは、管理者でなければ行えない機能等を受け付ける。
画像圧縮部４１６は、ビデオカメラ４１１からのＮＴＳＣ画像信号を取り込み、Ａ／Ｄ変換後、ＭｏｔｉｏｎＪＥＰＧで圧縮して、通信制御部４１４に渡す。通信制御部４１４は、圧縮された画像をネットワーク４５０に送出する。なお、ここでは画像の圧縮形式として、ＭｏｔｉｏｎＪＥＰＧ圧縮としたが、この圧縮形式に限定されるものではない。また、カメラ１０２は一つのストリームリクエストで映像ストリームを配信するストリーム配信と、一つの個別リクエストで一つの画像（個別画像）を送信する個別配信の両方に対応している。
クライアント１０１は、カメラ１０２に割り当てられているＩＰアドレスを指定して、ネットワーク４５０を介してカメラ１０２に接続し、通信を確立する。クライアント１０１において、通信制御部４２１は、カメラ１０２から送信された撮影画像データ（映像ストリームまたは個別画像）、および記憶部４１８に保持されていたパノラマ画像データを受信する。また、通信制御部４２１は、カメラ１０２から各種カメラ制御の結果を受信する。制御部４２４は、クライアント１０１によるストリーム受信モードの動作、個別受信モードの動作を含む、各種動作を制御する。また、制御部４２４は、図９Ａ、９Ｂにより後述する受信処理を実行する。また、制御部４２４は、画像伸長部４２５で展開された撮影画像およびパノラマ画像、各種カメラ制御の結果からグラフィカルユーザインタフェース（ＧＵＩ）を生成し、表示部４２６に表示するよう制御する。操作入力部４２３はユーザのマウスやキーボードによるＧＵＩ操作を受け付ける。コマンド生成部４２２は、パノラマ画像上でのマウスクリックや、ビデオカメラ４１１のパン・チルト・ローテート・ズーム位置を表す枠のドラッグといったＧＵＩ操作から各種カメラ制御コマンドを生成する。受信する画像のサイズのコマンド、切り出し配信のコマンドなどもコマンド生成部４２２で生成される。生成された各種カメラ制御コマンドは通信制御部４２１からカメラ１０２に送信される。またタイマ４３０はストリームリクエストを発行してからの時間を計測する。タイマ４３０は、表示制御のタイムアウト判定などに使用される。
図１２は、クライアント１０１のハードウエア構成例を示すブロック図である。クライアント１０１は情報処理装置であり、たとえば汎用コンピュータ装置により実現される。ＣＰＵ１２０１は、ＲＯＭ１２０２またはＲＡＭ１２０３に格納されたプログラムを実行することにより種々の制御を実現する。ＲＯＭ１２０２およびＲＡＭ１２０３はＣＰＵ１２０１に接続されたメモリの一例である。ＲＯＭ１２０２は読み出し専用の不揮発性メモリである。ＲＡＭ１２０３は、随時書き込みが可能な揮発性メモリである。図４に示したクライアント１０１の各機能部の少なくとも一部は、ＣＰＵ１２０１が所定のプログラムを実行することにより実現される。
表示装置１２０４は表示部４２６を構成し、ＣＰＵ１２０１の制御下で種々の表示を行う。二次記憶装置１２０５は例えばハードディスクであり、各種データを保存する。なお、二次記憶装置１２０５にＣＰＵ１２０１が実行するためのプログラムを格納しておき、必要に応じてＲＡＭ１２０３に展開し、ＣＰＵ１２０１により実行されるようにしてもよい。入力装置１２０６は、キーボード、マウスなどを有し、操作入力部４２３を構成する。なお、入力装置１２０６は、表示装置１２０４の表示画面に設けられたタッチパネルを備えてもよい。ネットワークインターフェース１２０７はネットワーク４５０とクライアント１０１を接続するインターフェースである。上述した各構成は、バス１２０８を介して相互に通信可能に接続されている。
次に図５を参照して本実施形態のＧＵＩ画面（ビューワ画面５００）について説明する。ビューワ画面５００において、映像表示領域５０１にカメラ１０２から配信された映像が表示される。操作バー５１１，５１２，５１３によりパン、チルト、ズームの操作が可能である。スナップショットボタン５１４は、静止画を取るときに利用される。画像サイズ設定セレクタ５１５は、現在の映像サイズを表示するとともに、表示する映像サイズを切り換えるのに用いられる。映像表示領域５０１には、図１（ａ）で説明したストリーム配信により得られた画像、および、図１（ｂ）で説明した個別配信により得られた画像を表示する事が可能となっている。
次に図６を参照してクライアント１０１とカメラ１０２と間の映像のやりとりを説明する。
本実施形態のクライアント１０１で稼働する受信処理（ビューワ）は、最初にストリームリクエストをカメラに投げる。クライアント１０１は、通常は図１（ａ）の様な手順で映像ストリームを受信し、映像を表示する。これに対して、図６に示されている動作シーケンスは、図３で説明したような、クライアント１０１とカメラ１０２の間に分割データを貯めてから一度に送信するプロキシ１０３が介在する場合の動作を示している。まずクライアント１０１はストリームリクエストをカメラ１０２に対して送信する（ステップ６００）。プロキシ１０３は、このリクエストを受信すると、そのままカメラ１０２に送信する（ステップ６１０）。こうして、クライアント１０１から送信されたストリームリクエストはプロキシ１０３を経由してカメラ１０２により受信される（ステップ６２０）。カメラ１０２は、このストリームリクエストに応じて映像ストリームを配信する（ステップ６２１）。配信される映像ストリームは途中データであり、プロキシ１０３が途中データを貯め込む（ステップ６１１）ためクライアント１０１は映像を受信しない。
クライアント１０１では、ストリームリクエストを送信した後、タイマ４３０を起動し（ステップ６３０）、ストリームリクエストを送信してからの経過時間を計測する。タイマ４３０の値が所定値（例えば３秒）になるまでに映像ストリームが受信されなかった場合（ステップ６３１）、クライアント１０１は個別配信により画像を受信するべく個別リクエストの送信を始める（ステップ６０２）。個別リクエストがプロキシ１０３を介してカメラ１０２に受信されると、カメラ１０２は画像を送信する（ステップ６２３）。送信された画像はプロキシ１０３を介してクライアント１０１により受信され、映像表示領域５０１に表示される（ステップ６０２）。個別の画像が送信される場合、分割データの形式ではないため、プロキシ１０３で貯め込まれることはない。以上のような個別配信が繰り返されることで（ステップ６０３、６２４、６０４）、クライアント１０１はカメラ１０２が配信した画像を受信し映像として表示することができる。
図７は図６のステップ６０２以降の個別配信により映像を表示している時のＧＵＩを示す図である。図７で示すように映像表示領域５０１には個別配信により受信した画像が表示される。また、領域７０１には「映像ストリームタイムアウトにより個別リクエストで映像を引いています。」と表示され、ストリーム配信から個別配信に切り替わった事をユーザに明示している。この表示により、ユーザは、クライアント１０１が、ストリームリクエストに応じた映像ストリームを受信するストリーム受信動作を実行しているのか、個別リクエストに応じた個別画像を受信する個別受信動作を実行しているのかを把握できる。
図８（ａ）は、図６の様にタイムアウトが発生して個別配信に切り替わった後に受信処理が終了し、その後、受信処理が起動された場合に、クライアント１０１がカメラ１０２から画像を取得する際のやり取りを示している。この場合、再度、図６と同じシーケンスにすると、すなわち、ストリームリクエストにより映像ストリームを受信しようとすると、映像を受信しないまま３秒のタイムアウトが発生する可能性が高い。したがって、クライアント１０１は、最初から図１（ｂ）で説明した個別配信により映像を受信して表示する。すなわち、受信処理が起動されると、クライアント１０１は個別リクエストを送信（ステップ８００、８０２、８０４）する。カメラ１０２はこれを受信して（ステップ８２０、８２２，８２４）画像を送信する（ステップ８２１、８２３、８２５）。クライアント１０１は、画像を受信し表示を行う（ステップ８０１、８０３、８０５）。
なお、図８（ａ）に示されるように、初めから個別配信に処理が切り替わるのは、図６で示した個別リクエストに切り替えて画像を表示できた場合に限るようにするのがよい。その理由は次のとおりである。図８（ｂ）で示すように、クライアント１０１は、ストリームリクエストを送信した後（ステップ８０５）、映像を受信できずにタイムアウトすると個別リクエストを送信する（ステップ８０６、８０７）。図８（ｂ）に示されるように、これら個別リクエストに対してもカメラ１０２から返事がない場合は、カメラ１０２側に不具合があると考えらえる。カメラ１０２の不具合が解消された後は、高速で映像表示を行う事が可能なストリーム受信で受信を行いたいため、まずはストリーム配信を試すことが望ましい。
次に、以上に説明した処理について図９Ａのフローチャートを参照してさらに説明する。図９Ａは図５で示したビューワを開いた時にクライアント１０１で開始される処理（受信処理）である。
まずステップＳ９０１で、制御部４２４は個別フラグがＯｎであるか否かを判断する。この個別フラグは初期時にはＯｆｆが設定されている。この個別フラグをＯｎにするタイミングについては後述する。ステップＳ９０１で個別フラグがＯｎでないと判断された場合、ステップＳ９０２において、制御部４２４は、ストリーム配信により配信されたストリームを受信するために、受信モードをストリーム受信モードに設定し、映像ストリームを受信する準備を行う。次に、制御部４２４は、ステップＳ９０３においてカメラ１０２にストリームリクエストを送信し、ステップＳ９０４においてタイマ４３０を起動してストリームリクエストを送信してからの経過時間の計測（タイムアウトカウント）を開始する。
次に、ステップＳ９０５において、制御部４２４は、映像ストリームの受信が開始されたか否かを判断する。ステップＳ９０５で映像ストリームの受信が開始されていないと判断された場合、ステップＳ９０８において、制御部４２４は、ステップＳ９０４で開始したタイムアウトカウントが３秒を超えたか否かを判断する。タイムアウトカウントが３秒以内であれば、ステップＳ９０５の処理を繰り返す。
ステップＳ９０５で映像受信が開始されたと判断された場合、ステップＳ９０６において、制御部４２４はストリーム受信動作を継続する。すなわち、ステップＳ９０１で設定されたストリーム受信モードによるストリーム受信動作が継続される。ステップＳ９０７でストリーム受信動作の終了か否かを判断する。ステップＳ９０７でストリーム受信動作の終了と判断された場合、本処理は終了する。ストリーム受信動作の終了ではないと判断された場合は、ステップＳ９０６のストリーム受信動作が繰り返される。ここでストリーム受信動作の終了とはビューワのアプリケーションを閉じるなどの事を指す。
一方、ステップＳ９０８でタイムアウトカウントが３秒より大きいと判断された場合は、途中データを貯め込むプロキシが介在していると判断し、ステップＳ９０９において、制御部４２４は、映像ストリームをキャンセルする。そして、ステップＳ９１０において、制御部４２４は、受信モードを個別配信による画像を受信するための個別受信モードに設定する。個別受信モードでは、制御部４２４は、映像ストリームに含まれる画像を個別に要求する個別リクエストにより個別画像を受信し、表示する。以下、具体的に説明する。
まず、ステップＳ９１１で制御部４２４は、個別フラグをＯｎにする。この個別フラグがＯｎであることにより、ステップＳ９０１で示すように、次回の起動時に個別配信での動作が実行される。次に、ステップＳ９１２において、制御部４２４は、個別リクエストを送信して個別画像のリクエストを行う。そして、ステップＳ９１３において、制御部４２４は、個別画像を受信し、表示する。ステップＳ９１４において、制御部４２４は、個別受信動作の終了か否かを判断する。個別受信動作の終了であると判断した場合、本処理は終了する。個別受信動作の終了でないと判断した場合、ステップＳ９１２以降の処理が繰り返される。個別フラグがＯｎの状態で受信処理が終了した場合、すなわち個別受信動作が実行された場合は、受信処理の次回の起動時には、ストリームリクエストを用いた判定を行わずに個別受信動作を実行するのが好ましい。なぜなら、ストリームリクエストを行ってもプロキシ１０３の介在によりタイムアウトしてしまう可能性が高いからである。したがって、本実施形態の受信処理では、起動時に個別フラグがＯｎである場合には、最初から個別受信モードで動作するようにしている（ステップＳ９０１でＹＥＳ→ステップＳ９１０）。
また、上述したように、個別リクエストに対してもカメラ１０２から返事がない場合は、カメラ１０２側に不具合があると考えられる。そのような場合は、ユーザは、不具合が解消された後は高速で映像表示を行う事が可能なストリーム受信で受信を行いたいと考えるであろう。したがって、ステップＳ９１３において、個別リクエストに対する画像が所定時間内に受信されなかった場合、制御部４２４は、ステップＳ９１１でＯｎにした個別フラグをＯｆｆにして本処理を終了する。この処理を図９Ｂに示す。図９ＢのステップＳ９２１～Ｓ９２５は、ステップＳ９１２～Ｓ９１３の処理の詳細を示している。制御部４２４は、ステップＳ９２１において個別リクエストを送信するとともに、タイマ４３０を起動してタイムアウトカウントを開始する。ステップＳ９２２において、制御部４２４は、個別リクエストに対する画像が受信されたか否かを判定する。画像が受信された場合、ステップＳ９２３において、制御部４２４は、個別画像の受信を行う。一方、ステップＳ９２２において画像が受信されていないと判定された場合、ステップＳ９２４において、制御部４２４は、タイムアウトカウントが所定値を超えたか否かを判定する。タイムアウトカウントが所定値以下であれば、処理はステップＳ９２２に戻る。ステップＳ９２４においてタイムアウトカウントが所定値を超えた場合、ステップＳ９２５において、制御部４２４は個別フラグをＯｆｆにして、受信処理を終了する。こうして、個別受信動作を実行して画像を受信できた場合には、受信処理の次回の起動時に最初から個別受信モードが設定される。また、個別受信動作を実行しても画像を受信できなかった場合には、受信処理の次回の起動時には、ストリーム受信モードが設定されて、ステップＳ９０３～Ｓ９０８の判定が行われる。
以上説明したように、第１実施形態によれば、途中に映像を貯めこんでしまうプロキシサーバが介在した場合には、映像ストリームを受信し表示する動作から個別画像を受信し表示する動作に切り替える事が可能となる。したがって、そのようなプロキシが介在する環境下、介在しない環境下のいずれにおいてもカメラからの映像を見ることができる。
＜第２実施形態＞
第１実施形態では、ストリームリクエストを送信してから所定時間内に映像ストリームの受信を開始できない場合に個別リクエストによる映像の受信に切り替えるように制御した。第２実施形態では、個別リクエストによる個別画像の到着に要した時間と、部分ストリームリクエストによる映像ストリームの到着に要した時間とに基づいて、ストリーム配信か個別配信のいずれかを選択する。なお、第２実施形態のクライアント１０１、カメラ１０２の構成、ストリーム配信および個別配信の基本的な動作は第１実施形態と同様である。
図１０は、第２実施形態において、映像の本配信をリクエストする前のカメラ１０２とクライアント１０１のやり取りを示したシーケンス図である。この処理により、本配信をリクエストする前に、図２あるいは図３で示したような、途中データを貯め込むプロキシが介在する環境であるか否かを判断する。以下、この処理を環境判定処理と称する。クライアント１０１は、環境判定処理により、カメラ１０２による本番の映像の配信（以下、本配信）をストリーム配信で行うか個別配信で行うかを、本配信の実行前に決定することができる。
環境判定処理により途中データを貯め込むプロキシ１０３が介在するか否かの判断に仕方について説明する。個別リクエストの場合、途中データを貯め込む設定のプロキシが介在する場合でもすぐにカメラ１０２からの返信が届く。一方、ストリーム配信の場合、途中データを貯め込む設定のプロキシが介在すると、すべてのデータが貯まった時点でデータが返ってくるため、最初のデータが返ってくるまでの時間が多くかかる。これを用いて、個別リクエストの送信から最初の返答までの時間と、ストリームリクエストの送信から最初の返答までの時間との差が大きい時には、プロキシが途中でデータを貯め込んでいると判断する。
図１０（ａ）は、途中データを貯め込むプロキシが介在しないネットワークの環境でこの判定を行った時のシーケンス図である。クライアント１０１は、まず個別リクエストを送る（ステップ１０００）。カメラ１０２はこの個別リクエストを受信すると（ステップ１０１０）、個別リクエストに対する返答（個別画像）を送信する（ステップ１０１１）。クライアント１０１は、この返答を受信し（ステップ１００１）、個別リクエストの送信（ステップ１０００）から返答の受信（ステップ１００１）での時間を第１の時間として保持しておく。次に、クライアント１０１は部分ストリームリクエストを送る（ステップ１００２）。部分ストリームリクエストは、カメラ１０２に所定のデータ量のストリームを配信させるものである。本実施形態では、所定枚数の映像をストリーム、例えば５枚の映像ストリームを配信させるものとする。カメラ１０２は、この部分ストリームリクエストを受信すると（ステップ１０１２）、リクエストされた部分ストリーム（５枚の映像）を返す（ステップ１０１３～ステップ１０１７）。クライアント１０１は、カメラ１０２から送信された映像を受け取る（ステップ１００３～ステップ１００７）。クライアント１０１は、部分ストリームリクエストの送信（ステップ１００２）から最初の映像の受信（ステップ１００３）までの時間を第２の時間として得る。
本実施形態では、環境判定処理において第１の時間と第２の時間との比または差に基づいて、ストリーム受信動作と、個別受信動作のいずれを実行するかが決定される。例えば、第１の時間と第２の時間の差が閾値以下の場合、または、第１の時間を第２の時間で割った値が所定値以上の場合に、ストリーム受信動作を実行すると決定する。図１０（ａ）では、保持されているステップ１０００からステップ１００１までの第１の時間と、ステップ１００２からステップ１００３までの第２の時間との差は小さいため、通常の環境（データを貯め込むプロキシが介在しない環境）であると判断する。なお、第１の時間と第２の時間の比を用いて決定を行う場合、本実施形態では、誤差を考慮して、第１の時間と第２の時間に２倍以上の差がない場合は、両者の差は小さいと判断している。
次に図１０（ｂ）を用いて図１０（ａ）と同じ処理を、途中データを貯め込むプロキシが介在した状態で行った場合を説明する。まず、クライアント１０１は個別リクエストをカメラ１０２に送信する（ステップ１０２０）。カメラ１０２は、このリクエストを受信し（ステップ１０３０）、受信したリクエストに対する返答（個別画像）を送信する（ステップ１０３１）。クライアント１０１はこの返答を受信する（ステップ１０２１）。クライアント１０１は、個別リクエストの送信（ステップ１０２０）から返答の受信（ステップ１０２１）までの時間を求め、第１の時間として保持しておく。
次に、クライアント１０１は、部分ストリームリクエストを送信する（ステップ１０２２）。部分ストリームリクエストについては上述したとおりである。カメラ１０２は、部分ストリームリクエストを受信すると（ステップ１０３２）、リクエストされた部分ストリームを返す（ステップ１０３３～ステップ１０３７）。プロキシ１０３は、終了の情報がある部分ストリームが来るまで、これらの部分ストリームを貯め込む（ステップ１０４０）。プロキシは、終了の情報を有する部分ストリームを受信すると、貯め込んだすべての部分ストリームをクライアント１０１に送信する（ステップ１０４１）。クライアント１０１では、これを部分ストリームリクエストに対する返答として受け取る（ステップ１００３）。クライアント１０１は、部分ストリームリクエストの送信（ステップ１０２２）から返答の受信（ステップ１０２３）までの第２の時間を求める。図１０（ｂ）の場合、ステップ１０２０からステップ１０２１までの第１の時間と、ステップ１０２２からステップ１０２３までの第２の時間との差が大きいため、データを貯め込むプロキシが介在する環境であると判断する。上述のように、第１の時間と第２の時間に２倍以上の差がある場合に両者の差は大きいと判断する。
以上説明した環境判定処理を含む、第２実施形態のクライアント１０１によるビューワの受信処理について図１１のフローチャートを用いて説明する。図１１において、ステップＳ１１０１～Ｓ１１０９が環境判定処理に対応する。
ステップＳ１１０１で、制御部４２４は、個別リクエストを送信する。次にステップＳ１１０２で、タイマ４３０を起動する。この際、タイマ４３０のカウントは０から開始される。次にステップＳ１１０３において、制御部４２４は、ステップＳ１１０１で送信したリクエストに対応する返答を受信したかどうかを判断する。返答が受信されるまでステップＳ１１０３が繰り返される。ステップＳ１１０３で返答が受信されると、ステップＳ１１０４において、制御部４２４は、タイマ４３０の値（タイマカウントという）をカウント１に代入する。結果、カウント１には個別リクエストを送信してからその返答を受信するまでの時間が入る。
次に、ステップＳ１１０５において、制御部４２４は、部分ストリームリクエストをカメラ１０２に送信する。そして、ステップＳ１１０６において、制御部４２４は、タイマ４３０を開始する。タイマ４３０は０から開始される。その後、ステップＳ１１０７において、制御部４２４は、部分ストリームリクエストに対する最初の返答が受信されるのを待つ。返答が受信されると、ステップＳ１１０８において、制御部４２４は、カウント２に現在のタイマカウントを代入する。結果、カウント２には部分ストリームリクエストを送信してから最初の返答が受信されるまでの時間が入る。
ステップＳ１１０９において、制御部４２４は、カウント１とカウント２に保持されている時間を比較し、カウント１÷カウント２の値が０．５より大きいか否かを判断する。つまり個別リクエストに対する返答に要した第１の時間と部分ストリームリクエストに対する返答に要した第２の時間があまり変わらないのか否かが判断される。ステップＳ１１０９で０．５より大きい場合は、カウント１とカウント２の時間に大きな差はない、すなわち、途中データを貯め込むプロキシ１０３は介在しないと判断する。この場合、処理はステップＳ１１１０へ進み、映像ストリーム配信を用いて本配信が行われる。すなわち、ステップＳ１１１０において、制御部４２４は、受信モードを、映像ストリームを受信するストリーム受信モードに設定し、ステップＳ１１１１でストリームリクエストを送信する。ステップＳ１１１２で、制御部４２４は、映像ストリームを受信し、表示する。映像ストリームの配信が終了するまでステップＳ１１１２、Ｓ１１１３が繰り返される。
一方、ステップＳ１１０９で０．５以下と判断された場合、処理はステップＳ１１１４に進み、個別配信を用いて本配信が行われる。すなわち、ステップＳ１１１４において、制御部４２４は、受信モードを、個別リクエストにより個別に画像を受信する個別受信モードに設定する。そして、制御部４２４は、ステップＳ１１１５において個別リクエストを送信し、ステップＳ１１１６において個別画像を受信、表示する。ステップＳ１１１７において、制御部４２４は、個別配信の終了か否かを判断し、終了と判断されると本処理を終了する。ステップＳ１１１７で終了でないと判断された場合、処理はステップＳ１１１５に戻り、個別配信が終了するまでステップＳ１１１５～Ｓ１１１７が繰り返される。
以上説明したように、第２実施形態では、カメラに映像の本配信を開始させる前に、個別リクエストと部分ストリームリクエストについて返答の受信に要する時間を比較する事で、データ（画像）を貯め込むプロキシが介在するか否かを判断する。第２実施形態では、この判断結果に応じて、個別配信にするかストリーム配信にするかを決めるので、ビューワ動作の開始時から適切な受信モードで映像を受信することができる。
なお、上記では、本配信前の環境判定処理で実行される個別リクエストによる配信と部分ストリームリクエストによる配信において、それぞれカメラ１０２が撮影した映像がリクエストに対応する返答として用いられたがこれに限られるものではない。環境判定処理においては、映像、画像以外の予め定められたデータが、リクエストに対応する返答として用いられてもよい。
＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
１０１：クライアント、１０２：カメラ、１０３：プロキシ、４２１：通信制御部、４２２：コマンド生成部、４２３：操作入力部、４２４：制御部、４２５：画像伸長部、４２６：表示部、４３０：タイマ４

Claims (14)

  1. 外部装置から映像を受信する受信処理を実行する情報処理装置であって、
    前記外部装置へ映像ストリームを要求するためのストリームリクエストを送信してから所定時間内に前記外部装置から映像ストリームを受信したか否かを判定する判定手段と、
    前記判定手段により映像ストリームが受信されたと判定された場合は前記外部装置へストリームリクエストを送信して映像ストリームを受信するストリーム受信動作を継続し、前記判定手段により映像ストリームが受信されなかったと判定された場合は前記外部装置へ前記映像ストリームに含まれる画像を個別に要求する個別リクエストを送信して個別に画像を受信する個別受信動作を実行する実行手段と、を備えることを特徴とする情報処理装置。
  2. 前記受信処理の起動時に、前記判定手段を実行することを特徴とする請求項１に記載の情報処理装置。
  3. 前記受信処理は起動時に前記ストリーム受信動作を実行し、
    前記実行手段は、前記判定手段により映像ストリームが受信されたと判定された場合は前記ストリーム受信動作を継続し、前記判定手段により映像ストリームが受信されなかったと判定された場合は、前記ストリームリクエストをキャンセルして前記個別受信動作を開始することを特徴とする請求項１または２に記載の情報処理装置。
  4. 前記実行手段が前記個別受信動作を実行した場合、前記受信処理の次回の起動時に、前記ストリームリクエストを用いた判定を行わずに前記個別受信動作を実行することを特徴とする請求項２または３に記載の情報処理装置。
  5. 前記実行手段が前記個別受信動作を実行して画像を受信できた場合、前記受信処理の次回の起動時には前記判定手段による判定を行わずに前記個別受信動作を実行し、
    前記実行手段が前記個別受信動作を実行して画像を受信できなかった場合、前記受信処理の次回の起動時には前記ストリーム受信動作を実行して前記判定手段による判定を行う、ことを特徴とする請求項１乃至４のいずれか１項に記載の情報処理装置。
  6. 前記ストリーム受信動作により受信された映像ストリームまたは前記個別受信動作により受信した画像を表示装置に表示させる表示制御手段をさらに備えることを特徴とする請求項１乃至５のいずれか１項に記載の情報処理装置。
  7. 前記表示制御手段は、前記ストリーム受信動作と前記個別受信動作のいずれが実行されているかを明示する表示を行わせることを特徴とする請求項６に記載の情報処理装置。
  8. 外部装置から映像を受信する受信処理を実行する情報処理装置であって、
    前記受信処理の起動時に、個別リクエストを送信して対応する返答を受信するまでの第１の時間と、所定のデータ量のストリームを送信させる部分ストリームリクエストを送信して対応する返答を受信するまでの第２の時間とを計測する計測手段と、
    前記第１の時間と前記第２の時間との比または差に基づいて、前記外部装置へストリームリクエストを送信して映像ストリームを受信するストリーム受信動作と、前記外部装置へ個別リクエストを送信して画像を受信する個別受信動作のいずれを実行するかを決定する決定手段と、を備えることを特徴とする情報処理装置。
  9. 前記個別リクエストに対応する返答は前記外部装置が撮影した個別の画像であり、前記部分ストリームリクエストに対応する返答は前記外部装置が撮影した所定枚数の映像のストリームであることを特徴とする請求項８に記載の情報処理装置。
  10. 前記決定手段は、前記第１の時間を前記第２の時間で割った値が所定値以上の場合に、前記ストリーム受信動作を実行すると決定することを特徴とする請求項８または９に記載の情報処理装置。
  11. 前記決定手段は、前記第１の時間と前記第２の時間の差が閾値以下の場合に、前記ストリーム受信動作を実行すると決定することを特徴とする請求項８乃至１０のいずれか１項に記載の情報処理装置。
  12. 外部装置から映像を受信する受信処理を実行する情報処理装置の制御方法であって、
    前記外部装置へ映像ストリームを要求するためのストリームリクエストを送信してから所定時間内に前記外部装置から映像ストリームを受信したか否かを判定する判定工程と、
    前記判定工程により映像ストリームが受信されたと判定された場合は前記外部装置へストリームリクエストを送信して映像ストリームを受信するストリーム受信動作を継続し、前記判定工程により映像ストリームが受信されなかったと判定された場合は前記外部装置へ前記映像ストリームに含まれる画像を個別に要求する個別リクエストを送信して個別に画像を受信する個別受信動作を実行する実行工程と、を備えることを特徴とする情報処理装置の制御方法。
  13. 外部装置から映像を受信する受信処理を実行する情報処理装置の制御方法であって、
    前記受信処理の起動時に、個別リクエストを送信して対応する返答を受信するまでの第１の時間と、所定のデータ量のストリームを送信させる部分ストリームリクエストを送信して対応する返答を受信するまでの第２の時間とを計測する計測工程と、
    前記第１の時間と前記第２の時間と比または差に基づいて、前記外部装置へストリームリクエストを送信して映像ストリームを受信するストリーム受信動作と、前記外部装置へ個別リクエストを送信して画像を受信する個別受信動作のいずれを実行するかを決定する決定工程と、を備えることを特徴とする情報処理装置の制御方法。
  14. コンピュータを、請求項１乃至１１のいずれか１項に記載の情報処理装置として機能させるためのプログラム。
JP2017173222A 2017-09-08 2017-09-08 情報処理装置およびその制御方法 Active JP7022540B2 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2017173222A JP7022540B2 (ja) 2017-09-08 2017-09-08 情報処理装置およびその制御方法
EP18191376.5A EP3454563A1 (en) 2017-09-08 2018-08-29 Information processing apparatus for network camera, control method therefor and program
CN201810993475.3A CN109474835B (zh) 2017-09-08 2018-08-29 信息处理设备及其控制方法和存储介质
US16/120,724 US10868847B2 (en) 2017-09-08 2018-09-04 Information processing apparatus, control method therefor and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2017173222A JP7022540B2 (ja) 2017-09-08 2017-09-08 情報処理装置およびその制御方法

Publications (2)

Publication Number Publication Date
JP2019050487A JP2019050487A (ja) 2019-03-28
JP7022540B2 true JP7022540B2 (ja) 2022-02-18

Family

ID=63442566

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017173222A Active JP7022540B2 (ja) 2017-09-08 2017-09-08 情報処理装置およびその制御方法

Country Status (4)

Country Link
US (1) US10868847B2 (ja)
EP (1) EP3454563A1 (ja)
JP (1) JP7022540B2 (ja)
CN (1) CN109474835B (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6844480B2 (ja) * 2017-09-22 2021-03-17 株式会社Ｊｖｃケンウッド 映像データストリーミング監視装置、方法及びプログラム、並びに端末装置及び映像データストリーミング監視システム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008211503A (ja) 2007-02-26 2008-09-11 Hitachi Kokusai Electric Inc 映像伝送システム
JP2015208018A (ja) 2012-10-09 2015-11-19 シャープ株式会社 コンテンツ送信装置、コンテンツ再生装置、コンテンツ配信システム、コンテンツ送信装置の制御方法、コンテンツ再生装置の制御方法、制御プログラムおよび記録媒体
WO2017095649A1 (en) 2015-12-03 2017-06-08 Microsoft Technology Licensing, Llc Protocol fallback during call signaling

Family Cites Families (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5815793A (en) * 1995-10-05 1998-09-29 Microsoft Corporation Parallel computer
US6771594B1 (en) * 1997-03-31 2004-08-03 Intel Corporation Reliable/non-reliable transmission of voice using TCP/UDP based on network quality of service
DE19717548A1 (de) * 1997-04-25 1998-11-05 Philips Patentverwaltung Übertragungssystem
US6717936B1 (en) * 1998-07-29 2004-04-06 Qwest Communications International, Inc. Directory talk service and system
US6275470B1 (en) * 1999-06-18 2001-08-14 Digital Island, Inc. On-demand overlay routing for computer-based communication networks
US6965926B1 (en) * 2000-04-10 2005-11-15 Silverpop Systems, Inc. Methods and systems for receiving and viewing content-rich communications
US6925495B2 (en) * 2000-07-13 2005-08-02 Vendaria Media, Inc. Method and system for delivering and monitoring an on-demand playlist over a network using a template
US7945688B1 (en) * 2001-06-12 2011-05-17 Netapp, Inc. Methods and apparatus for reducing streaming media data traffic bursts
US7088467B1 (en) * 2001-07-06 2006-08-08 Hewlett-Packard Development Company, L.P. Digital video imaging with high-resolution still imaging capability
US7369537B1 (en) * 2001-07-18 2008-05-06 Global Ip Solutions, Inc. Adaptive Voice-over-Internet-Protocol (VoIP) testing and selecting transport including 3-way proxy, client-to-client, UDP, TCP, SSL, and recipient-connect methods
JP3734774B2 (ja) * 2002-06-21 2006-01-11 株式会社リコー ネットワークファクシミリ装置、及び、ファクシミリ通信方法
US7702817B2 (en) * 2003-10-28 2010-04-20 Microsoft Corporation Wireless network access technologies for retrieving a virtual resource via a plurality of wireless network interfaces
JP4155920B2 (ja) * 2003-12-25 2008-09-24 株式会社日立コミュニケーションテクノロジー メディアゲートウェイおよび自動電話転送サービスシステム
US8145219B2 (en) * 2004-07-28 2012-03-27 Broadcom Corporation Handoff of a multimedia call session using background network scanning
US20060168626A1 (en) * 2005-01-21 2006-07-27 U-Turn Media Corporation Methods and systems for providing video content to a mobile client
US20070011338A1 (en) * 2005-06-08 2007-01-11 Logitech Europe S.A. System and method for transparently processing multimedia data
US8055783B2 (en) * 2005-08-22 2011-11-08 Utc Fire & Security Americas Corporation, Inc. Systems and methods for media stream processing
US9021134B1 (en) * 2006-03-03 2015-04-28 Juniper Networks, Inc. Media stream transport conversion within an intermediate network device
US20080056139A1 (en) * 2006-09-06 2008-03-06 Mentor Graphics Corporation Network traffic monitoring using embedded target-side analyzer during embedded software development
US20100005178A1 (en) * 2006-10-24 2010-01-07 Catalin Sindelaru Method and system for firewall friendly real-time communication
FR2919778A1 (fr) * 2007-07-30 2009-02-06 Canon Kk Procede de transmission de paquets de donnees dans un tunnel, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants
US8560634B2 (en) * 2007-10-17 2013-10-15 Dispersive Networks, Inc. Apparatus, systems and methods utilizing dispersive networking
US8165091B2 (en) * 2008-06-27 2012-04-24 Nix John A Efficient handover of media communications in heterogeneous IP networks using LAN profiles and network handover rules
US8938201B2 (en) * 2010-04-16 2015-01-20 Spirent Communications, Inc. WiFi positioning bench test method and instrument
GB2490364B (en) * 2011-04-28 2015-09-23 Thales Holdings Uk Plc Wireless communication method and apparatus
JP5101728B1 (ja) * 2011-05-12 2012-12-19 シャープ株式会社 出力システムおよび表示システム
ITMI20120491A1 (it) * 2012-03-27 2013-09-28 Videotec Spa Dispositivo di interfaccia per telecamere
US9087163B2 (en) * 2012-07-11 2015-07-21 Silicon Image, Inc. Transmission of multiple protocol data elements via an interface utilizing a data tunnel
TW201406158A (zh) * 2012-07-18 2014-02-01 Hon Hai Prec Ind Co Ltd 網路視頻傳輸與播放系統及方法
US10075498B2 (en) * 2012-12-21 2018-09-11 Vmware, Inc. Systems and methods for transmitting data in real time
US9569232B1 (en) * 2013-02-19 2017-02-14 Amazon Technologies, Inc. Network traffic data in virtualized environments
US9602359B2 (en) * 2013-03-15 2017-03-21 Custom Microwave Components, Inc. Methods, systems, and computer program product for providing graphical cross connectivity and dynamic configurability
JP6084080B2 (ja) * 2013-03-15 2017-02-22 キヤノン株式会社 撮像装置
CA2919966A1 (en) * 2013-08-06 2015-02-12 Ricoh Company, Ltd. Information processing apparatus and determination result providing method
JP6465541B2 (ja) * 2013-08-06 2019-02-06 キヤノン株式会社 通信装置、再生装置、及びその方法、並びにプログラム
JP6338349B2 (ja) * 2013-10-28 2018-06-06 キヤノン株式会社 データ送信装置、データ受信装置、それらの制御方法、プログラム
US9380351B2 (en) * 2014-01-17 2016-06-28 Lg Display Co., Ltd. Apparatus for transmitting encoded video stream and method for transmitting the same
JP2015170955A (ja) * 2014-03-06 2015-09-28 富士通株式会社 通信方法、通信制御プログラム、及び、通信装置
US20150281303A1 (en) * 2014-03-26 2015-10-01 Mohamed Yousef Adaptive media streaming
US20160080205A1 (en) * 2014-09-16 2016-03-17 Sentry360 Plug and Play Camera Configuration Tool for Internet Protocol Cameras with Export to Third-Party Video Management Software Support, Batch Firmware Update, and Other Capabilities
JP2016091436A (ja) * 2014-11-08 2016-05-23 キヤノン株式会社 通信装置、通信方法、及び、プログラム
US11057446B2 (en) * 2015-05-14 2021-07-06 Bright Data Ltd. System and method for streaming content from multiple servers
US10404807B2 (en) * 2015-10-16 2019-09-03 Hewlett-Packard Development Company, L.P. Notification systems
US10582022B2 (en) * 2016-05-20 2020-03-03 Citrix Systems, Inc. Adaptive session reliability over multiple transports
US9998299B2 (en) * 2016-07-20 2018-06-12 Oracle International Corporation Efficient transport of encapsulated media traffic over restrictive networks
CN106791680A (zh) * 2016-12-30 2017-05-31 国网上海市电力公司 一种外损源工地的手机远程视频监控系统
US10348722B2 (en) * 2017-06-30 2019-07-09 Paypal, Inc. System and method for implementing hacker traffic barriers
US20190081991A1 (en) * 2017-09-08 2019-03-14 Qualcomm Incorporated Systems and methods for session initiation protocol communication

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008211503A (ja) 2007-02-26 2008-09-11 Hitachi Kokusai Electric Inc 映像伝送システム
JP2015208018A (ja) 2012-10-09 2015-11-19 シャープ株式会社 コンテンツ送信装置、コンテンツ再生装置、コンテンツ配信システム、コンテンツ送信装置の制御方法、コンテンツ再生装置の制御方法、制御プログラムおよび記録媒体
WO2017095649A1 (en) 2015-12-03 2017-06-08 Microsoft Technology Licensing, Llc Protocol fallback during call signaling

Also Published As

Publication number Publication date
EP3454563A1 (en) 2019-03-13
CN109474835B (zh) 2022-04-05
JP2019050487A (ja) 2019-03-28
US10868847B2 (en) 2020-12-15
US20190081999A1 (en) 2019-03-14
CN109474835A (zh) 2019-03-15

Similar Documents

Publication Publication Date Title
JP5030261B2 (ja) 映像配信装置、ビューワ装置、映像配信装置の制御方法、ビューワ装置の制御方法およびコンピュータプログラム
JP5791256B2 (ja) 表示制御装置、表示制御方法
JP6633862B2 (ja) 情報処理装置およびその制御方法
US20240007516A1 (en) Ultra-low latency remote application access
CN101031080B (zh) 在用户命令之前发送视听流的方法以及接收机和发射机
JP7111288B2 (ja) ビデオ処理方法、装置および記憶媒体
JP7073128B2 (ja) 通信装置、通信方法、及びプログラム
JP6241802B1 (ja) 映像配信システム、ユーザ端末装置および映像配信方法
CN108462729B (zh) 实现终端设备交互的方法和装置、终端设备及服务器
JP2006115046A (ja) 映像配信装置及びクライアント
JP7075252B2 (ja) 情報処理装置およびその制御方法、プログラム
JP7022540B2 (ja) 情報処理装置およびその制御方法
JP2012231231A (ja) 画像表示装置
US10542213B2 (en) Imaging apparatus
CN106412617A (zh) 远程调试控制方法及装置
KR102010479B1 (ko) 비디오 월 시스템
KR102148776B1 (ko) 촬상 제어 장치, 그 제어 방법 및 컴퓨터 판독가능한 저장 매체
JP6991768B2 (ja) 表示制御装置および表示制御方法
CN104823441B (zh) 用于显示可控制的摄像机的摄像机图像的客户端装置、方法以及具有所述客户端装置的监视系统
JP5476734B2 (ja) サーバ、リモート操作システム、伝送方式選択方法、プログラム及び記録媒体
JP6001140B2 (ja) 情報処理装置、情報処理方法
JP6362090B2 (ja) ネットワークカメラのプリセット位置の表示方法
JP2024006566A (ja) 表示制御装置、表示制御装置の制御方法およびプログラム
JP2013021568A (ja) 情報処理装置、情報処理方法
JP2006197398A (ja) 複数ストリームの映像配信システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200804

RD01 Notification of change of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7421

Effective date: 20210103

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210113

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210628

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210817

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20220106

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220207

R151 Written notification of patent or utility model registration

Ref document number: 7022540

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151