JP5918030B2 - データ中継装置、データ中継方法、データ伝送システムおよびプログラム - Google Patents

Description

本発明は、データ伝送技術に関し、より詳細には、ネットワークを介してデータ送信装置からデータ受信装置へ伝送されるデータを中継するデータ中継装置、データ中継方法、データ伝送システムおよびプログラムに関する。

近年、ネットワーク通信技術の発展およびカメラの高精細化に伴い、ＩＰ（Internet Protocol）ネットワークを介して映像データを伝送するＩＰ映像伝送システムへの移行が進んでいる。例えば、道路、河川に監視用ＩＰカメラを設置し、ＩＰカメラからの映像データを光ケーブルなどの高速ＩＰネットワークで伝送し、総合監視センタにて、映像を投影する監視システムが知られている。このような監視システムにより、ＩＰネットワークを用いて、複数の観測点における道路の運行状況や河川の水位をリアルタイムに観測することができる。

上記ＩＰ映像伝送システムでは、ＩＰカメラや、アナログカメラに接続されたＩＰエンコーダなどの映像データ送信装置からＩＰパケット形式で送信される映像データを映像データ受信装置で受信し、デコードし、監視モニタやビデオウォールに映像を表示させている。映像データ受信装置としては、上記映像データを受信およびデコードするＩＰデコーダ機能をハードウェア実装したハードウェアＩＰデコーダが用いられる場合が多い。

上述したＩＰ映像伝送システムにおいて、同一メーカ製のＩＰカメラ（ＩＰエンコーダの場合を含む。以下同じ。）とハードウェアＩＰデコーダとを使用する場合は、あまり問題は生じない。しかしながら、現実には、ＩＰカメラとは異なるメーカ製のハードウェアＩＰデコーダを使用せざるを得ない場合もある。近年、ハードウェアＩＰデコーダを提供するメーカが減少している傾向にあり、ＩＰカメラおよびハードウェアＩＰデコーダを同一メーカ製のもので揃えることが難しくなっている。また、新規に追加する設備については、同一メーカ製のもので揃えることができたとしても、コスト削減および資産有効利用の観点から、異なるメーカの既設のカメラを活用したいという要望もある。

すなわち、ＩＰカメラの映像を、ＩＰカメラ側のメーカとは異なるメーカ製のハードウェアＩＰデコーダを経由して監視モニタやビデオウォールに表示させたいという要望があった。

特開２００７−３００３８６号公報（特許文献１）は、複数の監視カメラが異なるメーカ製のものである場合に対処する従来技術を開示する。特許文献１の従来技術では、複数の監視カメラ毎にＩＰアドレスや制御プロトコルを格納するテーブルの設定内容に基づいて、データ抽出部で、ＩＰパケットからヘッダ部を除去し、ペイロード部である圧縮データを抽出している。

特開２００７−３００３８６号公報

しかしながら、異なるメーカ間の組み合わせでは、ケーブルを接続するのみでは、映像コーデックを同一のものとした前提であっても、正常に表示されることは非常に少ない。仮に表示される組み合わせを見つけ出しても、数分程度表示させると、ハードウェアＩＰデコーダが自己復旧機能によりシステム再起動してしまい、頻繁に映像が途切れるなどの問題が発生する。ひいては、映像の可用性が失われ、監視業務に支障をきたすおそれがあった。

上記特許文献１の構成により、いくつかの組み合わせでは、正常な表示が可能となる場合もある。しかしながら、依然として、仕様が異なるＩＰカメラおよびＩＰデコーダの組み合わせにおいて、コーデック、フォーマット、ヘッダ情報、パケットサイズなどの種々の条件を適合させても、ＩＰカメラからの映像を、ハードウェアＩＰデコーダを経由してモニタに正常に表示させることができないケースが多数あった。

本発明は、上記従来技術における不具合に鑑みてなされたものであり、仕様が異なるデータ送信装置およびデータ受信装置の組み合わせにおいても、データ送信装置から送信されるデータを、データ受信装置を経由して正常に使用することができるデータ中継装置を提供することを目的とする。

本発明の他の目的は、上記データ中継装置が実行するデータ中継方法、上記データ中継装置を含むデータ伝送システム、および上記データ中継装置を実現するためのプログラムを提供することである。

本発明者等は、上記仕様が異なる映像データ送信装置および映像データ受信装置の組み合わせにおいて生じる不具合を鋭意検討した結果、このような組み合わせでは、映像データ送信装置および映像データ受信装置の映像データの送受信タイミングが仕様等によって相違しており、この相違に起因して、映像データ受信装置側のバッファ領域を超える映像データが無理に送り込まれる事態が発生し、正常な表示を妨げていることを見出し、本発明に至ったのである。

本発明では、上記課題を解決するために、データ送信装置およびデータ受信装置の間に、データ送信装置から送信されるデータを、該データの受信動作とは非同期に、データ受信装置へ送信するデータ中継装置を提供する。

すなわち、本発明によれば、データ送信装置およびデータ受信装置に接続されるデータ中継装置であって、
上記データ送信装置から送信された所定単位のデータを第１のタイミングで受信する受信手段と、
受信された所定単位のデータを記憶する記憶手段と、
上記記憶手段から読み出した所定単位のデータを、上記データ受信装置に対応付けて事前定義された、第１のタイミングとは異なる第２のタイミングで、上記データ受信装置へ送信する送信手段と
を含む、データ中継装置が提供される。

さらに、本発明によれば、上記データ中継装置が実行するデータ中継方法、上記データ中継装置を含むデータ伝送システム、および上記データ中継装置を実現するためのプログラムが提供される。

本発明によれば、データ中継装置において、データ送信装置からのデータの受信動作と、データ受信装置へのデータの送信動作とが、非同期に行われる。これにより、データ送信装置およびデータ受信装置の双方で独立したデータ送受信タイミングを調整することが可能となり、その結果、データ受信装置側でバッファのオーバフローが発生する可能性を低減することができる。ひいては、データ送信装置およびデータ受信装置の正常な使用が可能な組み合わせが増え、装置選定の自由度も拡張される。

本実施形態による映像伝送システムの概略図。 本実施形態による映像伝送システムの機能ブロック図。 映像フレームの送受信タイミングを説明する図。 映像フレームの送受信タイミングの相違に起因したＩＰパケットの間隔の相違を説明する図。 本実施形態による映像タイミング調整装置が実行する、映像データ中継処理を示すフローチャート。 本実施形態による映像タイミング調整装置のハードウェア構成図。

以下、本発明の実施形態について説明するが、本発明の実施形態は、以下に説明する実施形態に限定されるものではない。なお、以下の説明では、データ送信装置およびデータ受信装置に接続されるデータ中継装置の一例として、映像データ送信装置および映像データ受信装置に接続される映像データ中継装置を用いて説明する。

図１は、本実施形態による映像伝送システムの概略を示す図である。図１に示す映像伝送システムは、ＩＰネットワーク１００上に配置された、ＩＰカメラ１１０と、ハードウェアＩＰデコーダ（以下、単にＩＰデコーダと参照する。）１３０と、ＩＰカメラ１１０およびＩＰデコーダ１３０の間に設けられた映像タイミング調整装置１５０とを含む。

ＩＰカメラ１１０は、ＣＣＤ（Charge Coupled Device）カメラなどの撮像装置により撮像された映像を、内蔵するＩＰエンコーダでエンコードし、ＩＰパケット化して、ＩＰデコーダ１３０に向けて映像データを送信する映像データ送信装置である。なお、図１には、ＩＰエンコーダを内蔵するＩＰカメラ１１０を例示するが、他の実施形態では、アナログカメラに接続されたＩＰエンコーダを映像データ送信装置としてもよい。

ＩＰデコーダ１３０は、ＩＰカメラ１１０から送信されるＩＰパケット形式の映像データを受信し、デコードして、映像出力する映像データ受信装置である。ＩＰデコーダ１３０には、ビデオ信号インタフェースを介して監視モニタ１３２が接続されており、ＩＰデコーダ１３０により受信された映像が、アナログ映像信号またはデジタル映像信号として監視モニタ１３２に出力される。

映像タイミング調整装置１５０は、ＩＰカメラ１１０およびＩＰデコーダ１３０の間で動作し、ＩＰカメラ１１０から送信される映像データを、ＩＰデコーダ１３０へ中継する映像データ中継装置である。本実施形態において、映像タイミング調整装置１５０による映像データの中継の対象となるＩＰカメラ１１０およびＩＰデコーダ１３０の組み合わせでは、異なるメーカ製である等の理由から仕様が相違しており、映像データの送受信タイミングが相違している。映像タイミング調整装置１５０は、詳細を後述するように、受信した映像データを、ＩＰカメラ１１０から受信したタイミングとは異なるタイミングで、非同期的に、ＩＰデコーダ１３０に送信する。これによって、ＩＰカメラ１１０側の送信タイミングとＩＰデコーダ１３０側の受信タイミングとの差が吸収されて、ＩＰデコーダ１３０に適合するように映像データの送信タイミングが調整される。

なお、図１に示すＩＰネットワーク１００には、ＩＰカメラ１１０およびＩＰデコーダ１３０をそれぞれ１つ例示するが、ＩＰネットワーク１００上に存在するＩＰカメラおよびＩＰデコーダの数は限定されるものではない。また、映像タイミング調整装置１５０が映像データを中継するＩＰカメラ１１０およびＩＰデコーダ１３０の組み合わせの数も、限定されるものではない。例えば、映像タイミング調整装置１５０が複数のチャンネルを有し、複数のＩＰカメラからの映像データをそれぞれ対応するＩＰデコーダへ中継することもできる。

以下、図２〜図５を参照しながら、本実施形態による映像データ中継装置が実行する、映像データ中継処理について詳細を説明する。図２は、本実施形態による映像伝送システム２００の機能ブロックを示す図である。図２には、ＩＰカメラ１１０上の機能ブロック２１０と、ＩＰデコーダ１３０上の機能ブロック２３０と、映像タイミング調整装置１５０上の機能ブロック２５０とが示されている。

ＩＰカメラ１１０上の機能ブロック２１０は、撮像部２１２と、エンコード処理部２１４と、多重化部２１６と、ＩＰパケット化処理部２１８と、ＩＰパケット送信部２２０とを含む。撮像部２１２は、撮像して生成した映像信号をエンコード処理部２１４に出力する。エンコード処理部２１４は、撮像部２１２からの映像信号を所定の映像コーデックでエンコードし、また図示しないマイクロフォンにより採音された音声信号を所定の音声コーデックでエンコードする。

本実施形態で用いられる映像コーデックとしては、特に限定されるものではないが、ＭＰＥＧ−１ Ｖｉｄｅｏ、ＭＰＥＧ−２ Ｖｉｄｅｏ、ＭＰＥＧ−４ Ｖｉｓｕａｌ、Ｈ．２６４／ＭＰＥＧ−４ ＡＶＣ（Advanced Video Coding）、Ｈ．２６１、Ｈ．２６３、ＭＪＰＧ（Motion Joint Photographic Experts Group）などを例示することができる。本実施形態で用いられる音声コーデックとしては、特に限定されるものではないが、ＭＰＥＧ−１ Ｌａｙｅｒ ＩＩＩ（ＭＰ３）、ＭＰＥＧ−１ Ｌａｙｅｒ ＩＩ、ＡＡＣ（Advanced Audio Coding）などを例示することができる。

多重化部２１６は、撮像部２１２からの映像信号がエンコードされた映像ストリームと、音声信号がエンコードされた音声ストリームと、他の付加データのストリームとを、所定のストリーム形式で多重化する。ストリーム形式としては、ＴＳ（Transport Stream）方式やＰＳ（Program Stream）方式などを挙げることができる。なお、ＩＰカメラの仕様によっては、多重化したストリームを生成しない生のＥＳ（Elementary Stream）形式で送信される場合もある。

ＩＰパケット化処理部２１８は、多重化部２１６により出力されるストリームを、ＭＴＵ（Maximum Transmission Unit）に適合した所定サイズのＩＰパケットにカプセル化する。ＩＰパケット送信部２２０は、ＩＰパケット化されたストリームを送信する。本実施形態においては、ここでのＩＰパケットの送信先は、映像タイミング調整装置１５０となる。

上記構成によって、映像データは、ＴＣＰ（Transmission Control Protocol）／ＵＤＰ（User Datagram Protocol）、またはＲＴＰ（Real-time Transport Protocol）などのプロトコルにしたがって、ＩＰパケットの形態で、ＩＰネットワーク１００を介して、ＩＰカメラ１１０から、映像タイミング調整装置１５０を経て、ＩＰデコーダ１３０へと伝送される。

ＩＰデコーダ１３０上の機能ブロック２３０は、ＩＰパケット受信部２３２と、ＩＰパケット処理部２３４と、逆多重化部２３６と、デコード処理部２３８と、ビデオ信号インタフェース２４０とを含む。ＩＰパケット受信部２３２は、ＩＰカメラ１１０から映像タイミング調整装置１５０を経て送信されてきたＩＰパケット形式のストリームを受信する。ＩＰパケット処理部２３４は、ＩＰパケットのペイロードにカプセル化されたデータを抽出し、ストリームを逆多重化部２３６に出力する。

逆多重化部２３６は、ストリームに含まれる映像、音声およびデータを識別して逆多重化し、映像、音声およびデータに区分してバッファに格納する。デコード処理部２３８は、バッファから映像、音声およびデータを読み出してそれぞれデコード処理を行い、映像については、映像信号をビデオインタフェース２４０に出力する。

ビデオ信号インタフェース２４０は、ＩＰデコーダ１３０と監視モニタ１３２との間の映像出力インタフェース機器であり、再生された映像を所定の映像信号の形態で外部出力する。映像信号としては、特に限定されるものではないが、ＮＴＳＣ（National Television System Committee）信号、ＰＡＬ（Phase Alternating Line）などのアナログ・コンポジット映像信号、ＨＤＭＩ（High-Definition Multimedia Interface）、ＤＶＩ（Digital Visual Interface）、ＤｉｓｐｌａｙＰｏｒｔ（登録商標）、ＳＤＩ（Serial Digital Interface）などのデジタル映像信号を挙げることができる。

映像伝送システム２００においては、上述したように、映像や音声のストリームが、所定の伝送規格に準じて伝送され、同期再生が行われる。一方、ＩＰカメラ１１０およびＩＰデコーダ１３０間で行われる映像データの送受信タイミングは、ＩＰカメラおよびＩＰデコーダのメーカが各々設計している。ＩＰデコーダの設計時に想定している映像受信タイミング方式としては、仕様の優先度により大きく２種類存在する。第１の種類のタイミング方式は、図３（Ａ）に示すように、映像フレームの切り替えタイミングを優先としたタイミング方式である。もう一方の種類のタイミング方式は、図３（Ｂ）に示すように、ネットワークへの負荷低減を優先としたタイミング方式である。

図３は、映像フレームの送受信タイミングを説明する図である。図３（Ａ）に示すタイミング方式では、映像フレームは、固定間隔で送受信される。３０ｆｐｓのフレームレートの場合であれば、約３３ｍｓｅｃ間隔で映像フレームの送受信が行われる。

これに対して、図３（Ｂ）に示すタイミング方式では、映像フレームは、可変間隔で送信される。３０ｆｐｓのフレームレートであれば、図３（Ｂ）の例示では、１５フレームがグループ単位として５００ｍｓｅｃ間隔に固定され、グループ内では、第１フレームから第１５フレームまでのフレーム間の間隔が（１６＋α）ｍｓｅｃとなり、第１５フレームと次のグループの第１フレーム（第１６フレーム）との間隔が残余ｘ（ｘ＝５００−（（１６＋α）×１５））となり、映像フレームの送受信が行われる。このとき、αは、１６＋α＜３３．３３を満たす任意の値である。

ＩＰデコーダ１３０に実装される各種バッファは、通常、固定長の記憶領域として提供され、コスト削減や遅延低減の観点から上述した送受信タイミング方式に最適化されたサイズだけが確保されている。このとき、図３（Ｂ）の可変間隔のタイミング方式でＩＰカメラから送信された映像データを、図３（Ａ）の送信タイミング方式のＩＰデコーダで直接受信した場合に問題となる。あるいは、図３（Ａ）の固定間隔のタイミング方式でＩＰカメラから送信された映像データを、図３（Ｂ）の可変間隔の送信タイミング方式のＩＰデコーダで直接受信した場合に問題となる。

図４は、映像フレームの送受信タイミングの相違に起因したＩＰパケットの伝送間隔の相違を説明する図である。図４に示すように、ＩＰカメラは、フレームレートに応じた所定間隔でシャッターを切り、その映像のデータを所定の圧縮形式へ変換し、圧縮方法に準じて映像フレームを生成し、所定サイズのＩＰパケットに分割して送信する。

固定間隔のタイミング方式では、映像フレームに対応するＩＰパケット群も固定間隔で送信され、可変間隔のタイミング方式では、ＩＰパケット群は可変間隔で送信される。このとき、例えば図３（Ａ）および図４（Ａ）に示す固定間隔の映像フレームのタイミングを想定したＩＰデコーダに対して、ＩＰカメラが、図３（Ｂ）および図４（Ｂ）のような可変間隔のタイミングで映像フレーム（ＩＰパケット群）を直接送信した場合、ＩＰデコーダは、想定よりも送信間隔が詰まった状態でＩＰパケットを受信してしまう。このような場合には、ＩＰデコーダは、典型的には、数秒程度でシステム・ハングアップを引き起こすか、自己修復機能により再起動されてしまう。再起動されるＩＰデコーダの場合は、上述した現象を繰り返し起し、再起動が頻発することになる。

同一メーカのＩＰカメラおよびＩＰデコーダの組み合わせであれば、例えばＲＴＣＰ（RTP Control Protocol）通信などにより、ＩＰカメラとＩＰデコーダとの間でＩＰパケットの送信タイミングを調整することもできる。しかしながら、異なるメーカ製である等の理由から仕様が相違する場合には、ＩＰカメラ側が、ＲＴＣＰに対応していても、ＩＰデコーダ側が対応して無い場合や、その反対の場合などがあり、対処が困難となる。

すなわち、送受信タイミング方式が適合していない場合は、上述した映像データの送受信タイミングの相違に起因して、ＩＰデコーダ１３０が実装する固定長バッファがオーバフローしてしまう可能性がある。そこで、本実施形態による映像タイミング調整装置１５０は、ＩＰカメラ１１０側の映像送信タイミングとＩＰデコーダ１３０側の映像受信タイミングとの差を吸収し、ＩＰデコーダ１３０に適合するよう映像データの送信タイミングを調整する機能を備える。

映像タイミング調整装置１５０上の機能ブロック２５０は、上述したタイミング調整を実現するために、ＩＰパケット受信部２５２と、データ受信処理部２５４と、可変長キュー２５６と、データ送信処理部２５８と、ＩＰパケット送信部２６０とを含む。

ＩＰパケット受信部２５２およびＩＰパケット送信部２６０は、ＩＰカメラ１１０やＩＰデコーダ１３０と同様に、ＴＣＰ／ＵＤＰおよびＩＰプロトコル・スタックの機能を備える。ＩＰパケット受信部２５２は、ＩＰカメラ１１０から送信されたＩＰパケット形式の映像データを受信し、データ受信処理部２５４に渡す。

データ受信処理部２５４は、渡されたＩＰパケットのペイロード部のデータを可変長キュー２５６に順次保存して行く。データ送信処理部２５８は、可変長キュー２５６にデータが一定量の保存されることを待って、可変長キュー２５６に保存されたデータの送信処理を開始する。可変長キュー２５６は、ストリームを記憶する可変長の記憶手段であり、データ受信処理部２５４およびデータ送信処理部２５８間で行われるデータ交換を橋渡しする。

データ送信処理部２５８は、可変長キュー２５６に記憶されているデータを読み出し、ＩＰデコーダ１５０に適合する所定のパケットサイズでＩＰパケット化する。また、データ送信処理部２５８は、事前設定されたタイミング定義情報２６２に応じて送信タイミングを判定し、受信タイミングとは異なるタイミングで、ＩＰパケット送信部２６０に対し、ＩＰパケット形式の映像データをＩＰデコーダ１３０へ送信させる。本実施形態においては、ここでのＩＰパケットの送信先は、ＩＰデコーダ１３０となる。

タイミング定義情報２６２は、ＩＰデコーダ１３０の仕様に応じて事前設定された、ＩＰパケットの送信タイミングを定義する情報である。ＩＰデコーダ１３０に応じたＩＰパケットの送信タイミングは、例えば、送信予定のＩＰパケットサイズのデータを所望のＩＰデコーダ側へ送信間隔を変えながら送り込み、上述したシステム・ハングアップまたは再起動が発生しないような間隔を見つけ出し、その間隔を送信タイミングに決定することができる。このようなタイミング定義情報２６２は、本映像タイミング調整装置１５０のベンダ側で、複数の機種のＩＰデコーダ毎に用意し、ユーザが選択可能としてもよいし、本映像タイミング調整装置１５０のユーザ側で、各自設定させることもできる。また、タイミング定義情報２６２には、上述した一定量のデータの蓄積を待つための遅延時間も設定される。

図５は、本実施形態による映像タイミング調整装置１５０が実行する、映像データ中継処理を示すフローチャートである。図５には、データ受信動作の処理フローと、データ送信動作の処理フローとが示されている。

図５に示す、データ受信動作の処理フローは、映像データの受信が開始されたことに応答して、ステップＳ１００から開始される。ステップＳ１０１〜ステップＳ１０４のループでは、ストリームが入力されている間（ｔｒｕｅの間）、ステップＳ１０２およびステップＳ１０３の処理が繰り返し実行される。ステップＳ１０２では、ＩＰパケット受信部２５２は、ＩＰパケット形式の映像データを受信し、ステップＳ１０３では、データ受信処理部２５４は、受信したＩＰパケットのペイロード部のデータを可変長キュー２５６に順次保存する。ストリームの入力が止まると（ｆａｌｓｅ）、ステップＳ１０５へ処理が進められ、本受信処理が終了する。

図５に示す、データ送信動作の処理フローは、事前設定された遅延時間が経過し、所定量のデータが保存されたことに応答して、ステップＳ２００から開始される。ステップＳ２０１〜ステップＳ２０５のループでは、データが可変長キュー２５６に存在する間（ｔｒｕｅの間）、ステップＳ２０２〜ステップＳ２０４の処理が繰り返し実行される。

ステップＳ２０２では、データ送信処理部２５８は、可変長キュー２５６に保存されたデータを読み出し、ＩＰデコーダ１３０に適合した所定のパケットサイズでＩＰパケット化する。ステップＳ２０３では、データ送信処理部２５８は、事前設定されたタイミング定義情報２６２に基づいて、ＩＰパケットの送信タイミングを判定する。ステップＳ２０３の判定で、送信タイミングではないと判定された場合（ＮＯ）は、ステップＳ２０３内をループさせられ、送信タイミングが到来するのを待ち受ける。ここでは、映像タイミング調整装置１５０のクロックを用いて、上記事前定義された時間が経過したか否かが判定される。上記事前定義された時間が経過していた場合には、送信タイミングであると判定される。

ステップＳ２０３の判定で、送信タイミングであると判定された場合（ＹＥＳ）は、ステップＳ２０４へ処理が進められる。ステップＳ２０４では、ＩＰパケット送信部は、データ送信処理部２５８が準備したＩＰパケットをＩＰデコーダ１３０へ向けて送信する。可変長キュー２５６に送信すべきデータがなくなると（ｆａｌｓｅ）、ステップＳ２０６へ処理が進められて、本送信処理が終了する。

以下、映像タイミング調整装置１５０のハードウェア構成について説明する。映像タイミング調整装置１５０は、特定の実施形態においては、汎用コンピュータ装置１０を用いて実装することができる。図６は、本実施形態による映像タイミング調整装置１５０のハードウェア構成図である。映像タイミング調整装置１５０は、シングルコアやマルチコアのマイクロプロセッサ・ユニット（ＭＰＵ)１２と、ＢＩＯＳ（Basic Input Output System）を格納する不揮発性メモリ１４と、ＭＰＵ１２によるプログラム処理を可能とする実行記憶空間を提供するメモリ１６とを含む。メモリ１６は、また、可変長キュー２５６の記憶領域を提供する。

ＭＰＵ１２は、内部バス２２を介して記憶制御用インタフェース１８に接続され、ハードディスク２０が、ＭＰＵ１２からの入出力要求に応答してデータの書き込みまたは読み出しを実行する。ＭＰＵ１２は、内部バス２２を介してＵＳＢなどのシリアルまたはパラレル・インタフェース２４を制御して、キーボード、マウス、プリンタなどの入出力装置２６と通信し、ユーザからの入力を受け取る。

映像タイミング調整装置１５０は、さらにＶＲＡＭ２８とグラフィック・チップ３０とを含むことができる。グラフィック・チップ３０は、ＭＰＵ１２からの指令に応答してビデオ信号を処理し、ディスプレイ装置３２へと表示させている。ＭＰＵ１２は、また、内部バス２２を介してネットワークＩ／Ｆ（ＮＩＣ；Network Interface Card）３４と接続する。これにより、映像タイミング調整装置１５０を、ネットワークを通して、ＩＰカメラ１１０およびＩＰデコーダ１３０と通信させている。

映像タイミング調整装置１５０は、不揮発性メモリ１４やハードディスク２０、その他ＮＶ−ＲＡＭ（図示せず）やＳＤカード（図示せず）などの記憶装置に格納されたプログラム（図示せず）を読み出し、メモリ１６のメモリ領域に展開する。これにより、適切なオペレーティング・システム（ＯＳ）のもとで、上述した各機能手段および各処理を実現する。上記ＯＳとしては、Ｗｉｎｄｏｗｓ（登録商標）、ＵＮＩＸ（登録商標）またはＬＩＮＵＸ（登録商標）など、如何なるアーキテクチャを有するＯＳを採用することができる。

また、映像タイミング調整装置１５０は、他の実施形態では、組み込み機器として実装されてもよい。また、上述した実施形態では、映像データの送受信タイミング以外の条件（コーデック、フォーマット、ヘッダ情報、パケットサイズ）が揃っているものとして説明したが、映像タイミング調整装置１５０が、これらの相違を吸収するプロトコル変換機能を備えても良い。さらに、上述した実施形態では、ストリームには映像および音声が含まれるものとして説明したが、映像および音声々のストリームが別々に伝送される場合には、映像および音声の両方のストリームに対して、本実施形態のデータ中継処理を適用することができる。

なお、上記機能部は、アセンブラ、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（登録商標）、などのレガシープログラミング言語やオブジェクト指向プログラミング言語などで記述されたコンピュータ実行可能なプログラムにより実現でき、ＲＯＭ、ＥＥＰＲＯＭ、ＥＰＲＯＭ、フラッシュメモリ、フレキシブルディスク、ＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＡＭ、ＤＶＤ−ＲＷ、ブルーレイディスク、ＳＤカード、ＭＯなど装置可読な記録媒体に格納して、あるいは電気通信回線を通じて頒布することができる。

以上説明したように、本実施形態によれば、仕様が異なるデータ送信装置およびデータ受信装置の組み合わせにおいても、データ送信装置から送信されるデータを、データ受信装置を経由して正常に使用することができるデータ中継装置、データ中継方法、データ伝送システムおよびプログラムを提供することができる。

本発明によれば、映像タイミング調整装置１５０において、ＩＰカメラ１１０からの映像データの受信動作と、ＩＰデコーダ１３０への映像データの送信動作とが、非同期で行われる。これにより、ＩＰカメラ１１０およびＩＰデコーダ１３０の双方で独立した映像送受信タイミングを調整することが可能となる。その結果、ＩＰデコーダ１３０側でバッファのオーバフローが発生する可能性を低減することができる。ひいては、正常に表示可能なＩＰカメラおよびＩＰデコーダの組み合わせが増え、装置選定の自由度も拡張される。

また、ＩＰデコーダ１３０側に何らかの障害が生じている場合でも、ＩＰカメラ１１０からの映像データは、映像タイミング調整装置１５０で受信され、可変長キュー２５６へ一旦スプールされる。このため、デジタル・ビデオ・レコーダのような映像蓄積装置との間で用いること、蓄積映像の欠落を低減することも可能となる。

これまで本発明の実施形態について説明してきたが、本発明の実施形態は上述した実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

１００…ＩＰネットワーク、１１０…ＩＰカメラ、１３０…ＩＰデコーダ、１３２…監視モニタ、１５０…映像タイミング調整装置、２００…映像伝送システム、２１０…機能ブロック、２１２…撮像部、２１４…エンコード処理部、２１６…多重化部、２１８…ＩＰパケット化処理部、２２０…ＩＰパケット送信部、２３０…機能ブロック、２３２…ＩＰパケット受信部、２３４…ＩＰパケット処理部、２３６…逆多重化部、２３８…デコード処理部、２４０…ビデオ信号インタフェース、２５０…機能ブロック、２５２…ＩＰパケット受信部、２５４…データ受信処理部、２５６…可変長キュー、２５８…データ送信処理部、２６０…ＩＰパケット送信部、２６２…タイミング定義情報、１０…コンピュータ装置、１２…ＭＰＵ、１４…不揮発性メモリ、１６…メモリ、１８…記憶制御用インタフェース、２０…ハードディスク、２２…バス、２４…インタフェース、２６…入出力装置、２８…ＶＲＡＭ、３０…グラフィック・チップ、３２…ディスプレイ装置、３４…ネットワークＩ／Ｆ

Claims (6)

1. データ送信装置およびデータ受信装置に接続されるデータ中継装置であって、
   前記データ送信装置から送信された所定単位のデータを受信する受信手段と、
   受信された所定単位のデータを記憶する記憶手段と、
   前記記憶手段から読み出した所定単位のデータを、前記受信手段の受信動作とは非同期に、前記データ受信装置に対応付けて事前設定された送信間隔で、前記データ受信装置へ送信する送信手段と
   を含む、データ中継装置。
2. 前記所定単位のデータは、映像および音声またはこれらの一方を伝送する伝送パケットであり、前記データ中継装置は、さらに、
   前記データ受信装置に対応付けて事前設定された伝送パケットのタイミング定義情報に基づいて、伝送パケットを送信する前記送信間隔を判定する判定手段
   をさらに含む、請求項１に記載のデータ中継装置。
3. 前記記憶手段は、可変長のバッファ記憶領域である、請求項１または２に記載のデータ中継装置。
4. データ送信装置およびデータ受信装置に接続されるデータ中継装置が実行するデータ中継方法であって、前記データ中継装置が、
   前記データ送信装置から送信された所定単位のデータを受信するステップと、
   受信された所定単位のデータを記憶手段に保存するステップと、
   前記記憶手段から所定単位のデータを読み出すステップと、
   読み出した所定単位のデータを、前記受信するステップでの受信動作とは非同期に、前記データ受信装置に対応付けて事前設定された送信間隔で、前記データ受信装置へ送信するステップと
   を含む、映像データ中継方法。
5. 請求項１〜３のいずれか１項に記載のデータ中継装置と、前記データ中継装置に接続されるデータ受信装置とを含む、データ伝送システム。
6. 請求項１〜３のいずれか１項に記載のデータ中継装置の各手段としてコンピュータを機能させるためのプログラム。