JP2007281973A - 映像データ送信装置、映像データ送信方法及びプログラム - Google Patents

Abstract

【課題】複数の映像ストリームデータを異なる受信端末に送信するような映像配信処理において、通信プロトコル処理の処理遅延が少なく、高スループットを実現するとともに、アプリケーションが要求する様々なネットワークプロトコルへ柔軟に対応する。
【解決手段】複数映像ストリームの同時生成を行うマルチストリームエンコーダと、ストリーム形式や送信形式にそれぞれ対応した複数のネットワークプロトコル処理ブロックで構成されたシステムであり、ネットワークプロトコル処理ブロックのうちひとつはＣＰＵで実行されるソフトウェアによってプロトコル処理されるものであり、ひとつはエンコーダから出力されたストリームデータを送信パケットに分割し、あらかじめ設定されているストリーミングプロトコルのパケットヘッダを自動的に付加して送信パケットをリアルタイムに生成して送信する専用ブロックから構成されるものである。
【選択図】図１

Description

本発明は、ネットワークに接続された複数の端末からの要求に応じて大容量の映像データを配信するシステムにおいて、特にネットワークに接続されたカメラの映像を複数の形式のデータで同時に配信することが可能なネットワークカメラをはじめとする、映像データ送信装置、映像データ送信方法及びプログラムに関するものである。

近年、インターネットをはじめとするネットワークの普及が進みその伝送帯域も拡大してきている。これにともない、大容量の映像データをネットワークを利用して伝送するような装置やアプリケーションも増えつつある。

例えば、ネットワークに接続されたカメラ装置で動画映像を遠隔地から監視したり撮影するようなネットワークカメラ装置においては、ネットワークカメラは撮影映像を圧縮符号化処理により符号化ビットストリーム形式の映像ストリームデータへ変換し、ＩＰ／ＵＤＰ／ＲＴＰパケットとしてネットワーク上へ送信していた。これらの映像ストリームデータのネットワーク送信処理においては、ＯＳＩ参照モデルあるいはＴＣＰ／ＩＰで規定される４層モデルに代表されるように、複数のレイヤに分割されたパケット処理を行い、それぞれのレイヤ間でデータの受け渡しを行うのが一般的である。例えば動画映像のストリーム配信の場合には、ＴＣＰ／ＩＰの４層モデルにおいて、インターネット層でＩＰパケット、トランスポート層でＵＤＰパケット、アプリケーション層でＲＴＰパケットを生成し、多重化パケットとしてネットワークに送信される。

一方、ネットワークカメラから配信される撮影映像の高画質化、高機能化の要求は年々高くなってきており、映像ストリームデータのビットレート増大にともなうデータ量の増加、あるいは複数端末からの同時要求に答えるため複数ストリームの同時配信の数も増えてきている。このような状況においてはデータ送信におけるネットワークプロトコル処理を高速に行わなければならず、これらの要求を解決するものとして、例えば特許文献１、特許文献２に開示されているように、複数の形式の映像ストリームを同時に生成するために複数のエンコーダを並列に備えることによりエンコード処理性能を向上させたり、あるいは送信ストリームに対するパケットヘッダ自動付加や、複数のプロトコル処理モジュールを同時並行して実行することでストリーム送信スループットを向上させるような手法がとられている。

特開２０００−５９４６３号公報（第１頁、第２図） 特開２００１−４５０２５号公報（第１頁、第１図）

しかしながら、複数の端末から様々な形式の映像ビットストリームの配信要求が行われるネットワークカメラにおいては、特許文献２に開示されているように、エンコーダを複数備える構成とした場合は装置の回路規模が大きくなってしまうという欠点がある。また、エンコーダから出力された映像ストリームデータに対して、パケットヘッダを自動付加して送信するような構成とした場合は、例えばＵＤＰ／ＲＴＰのようにあらかじめ決まったプロトコルへの対応は可能であるが、アプリケーションによる上位のプロトコルへの対応などの拡張性は実現することが困難である。

また、特許文献１に開示されているように、ＣＰＵで実行されるアプリケーションが生成したデータに対して、パケットヘッダを自動的に付加するようなプロトコル専用処理手段を設けた構成においては、プロトコル処理については高速に実行できるものの、ペイロードデータがＣＰＵシステムバスを通じてシステムメモリ上のバッファを経由することになるため、高速のメモリや広帯域のシステムバス性能が要求され、安価なシステム構成においては、データ送信のスループットが低下してしまうこととなる。

本発明は、上記の問題点を解決するためになされたもので、複数の映像ストリームデータを異なる受信端末に送信するような映像配信処理において、処理遅延が少なく、高スループットの送信を実現するとともに、アプリケーションが要求する様々なネットワークプロトコルへ柔軟に対応を可能とすることを目的としている。

本発明の映像データ送信装置は、複数の形式に圧縮符号化された映像ストリームデータをネットワークに接続された複数の端末に同時に送信するような映像データ送信装置において、非圧縮映像データに対して複数の形式の圧縮符号化データを生成することが可能なエンコーダと、プロセッサによるソフトウェアで実行される第１のネットワークプロトコル処理手段と、画像データのリアルタイム送信処理を実行する第２のネットワークプロトコル処理手段と、該エンコーダで生成された複数の圧縮符号化データのうち第１のネットワークプロトコル処理手段によって処理を行うデータと第２のネットワークプロトコル処理手段によって処理を行うデータを選択的に振り分ける手段とを備えることを特徴とする。
本発明の映像データ送信方法は、複数の形式に圧縮符号化された映像ストリームデータをネットワークに接続された複数の端末に同時に送信するような映像データ送信方法において、非圧縮映像データに対して複数の形式の圧縮符号化データを生成するステップと、プロセッサによるソフトウェアで実行されるステップと、画像データのリアルタイム送信処理を実行するステップと、該エンコーダで生成された複数の圧縮符号化データのうち第１のネットワークプロトコル処理ステップによって処理を行うデータと第２のネットワークプロトコル処理ステップによって処理を行うデータを選択的に振り分けるステップとを備えることを特徴とする。
本発明のプログラムは、前記映像データ送信方法をコンピュータに実行させることを特徴とする。

本発明によれば、処理遅延が少なく、高スループットの送信を実現するとともに、アプリケーションが要求する様々なネットワークプロトコルへ柔軟に対応可能な映像配信処理が行える。

以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。

（第１の実施形態）
図１は、本発明の第１の実施形態の全体構成の一例を示す図である。本実施形態では、汎用的な通信を行うプロトコル処理部と、リアルタイムストリーミング送信が可能なプロトコル処理部を、別形態として構成する。

図１においては、前者の汎用プロトコル処理部は、１０１のＣＰＵで実行するソフトウェアの通信プロトコルスタックであり、後者のリアルタイムストリーミングプロトコル処理部は、画像データのリアルタイム送信を専用の目的とする１０２のプロトコル処理部として示している。以下、図１を参照しながら、本発明の実施形態について全体構成を説明する。

１０３は、撮像部を表す。撮像部１０３は、レンズ、ＣＣＤ（光電変換素子）、ＣＣＤ制御部などを含む。撮像部１０３では、レンズを通して投影される撮像を、ＣＣＤによってアナログ電気信号に変換する。また、アナログ電気信号に変換された撮像画像から、ノイズ除去等の処理を施し、デジタルデータに変換するＡ／Ｄ変換を行う画像処理部を備えている。

１０４はエンコーダであり、非圧縮デジタル画像データのエンコード（圧縮符号化）を実行する。撮像部１０３が一定の周期で非圧縮デジタル画像データを出力し、エンコーダ１０４がその画像データをエンコードすることにより、動画データストリームを生成する。

本実施形態におけるエンコーダ１０４は、画像データの高速なエンコード処理を実現するハードウェア装置であり、複数のエンコード形式に対応する。エンコード形式にはＪＰＥＧやＭＰＥＧ４を含むものとする。また、撮像部１０３からの出力周期内で、エンコード形式や圧縮効率が異なる複数のエンコード条件の設定とエンコードを実行し、複数の動画ストリームを生成することが可能である。

エンコーダ１０４の設定や制御は、１０５の入力切替制御部が行う。実施形態として、例えば、局所メモリ装置を備えたマイクロプロセッサで実現される。入力切替制御部１０５は、撮像部１０３が出力する画像フレームデータ毎に、エンコーダ１０４に対して、エンコード形式や圧縮効率などのパラメータの設定を行う。また、エンコードの開始タイミングを指示し、エンコード完了を通知する割り込み信号を受け取るなどの、エンコーダ制御を行う。

エンコーダ１０４からの画像データは、１０６の画像バッファ１、１０７の画像バッファ２のダブルバッファ構成のいずれかに出力される。画像バッファ１、画像バッファ２は、ＤＲＡＭのような同一のメモリ装置上に配置してもよいし、別々の専用メモリ装置による実施構成としてもよい。

前記入力切替制御部１０５は、エンコーダ１０４が出力する画像データのデータパスのセレクタ１０８を制御し、どちらの画像バッファに出力するかを決定する。本構成では、出力画像バッファを決定するセレクタ１０８を設けているが、例えば画像バッファがＤＲＡＭ上にあり、エンコーダ１０４に画像バッファのアドレスを設定することで、画像データ毎に出力先を変更できるような場合には、入力切替制御部１０５がエンコーダ１０４に対して出力先を設定する方法で実現してもよい。

次に、１０９のデータ転送切替部は、１０６と１０７のいずれかの画像バッファからプロトコル処理部１０２にデータを転送する機能を有する。この機能はＤＭＡ装置をデータ転送切替部１０９の内部に具備して利用する。また、ＣＰＵ１０１が、画像バッファに対してメモリアドレスで読み出し可能となるようなデータアクセス機能を有する。この機能は、データ転送切替部１０９の内部にアドレスデコーダ機能を有し、ＣＰＵ１０１から画像バッファへのデータアクセスが、１０６と１０７のどちらの画像バッファであっても、同一のメモリアドレスでアクセス可能となるようにしている。

そして、データ転送切替部１０９は、画像データをリアルタイムにネットワークへ送出する場合には、プロトコル処理部１０２に、いずれかの画像バッファから画像データを転送し、ＣＰＵ１０１の汎用通信プロトコルによって画像データをネットワークに送信する場合には、ＣＰＵ１０２から画像バッファのデータ読み出せるように制御される。

このデータ転送切替部１０９の制御は、前記入力切替制御部１０５によってなされる。すなわち、入力切替制御部１０５は、画像バッファ１（１０６）もしくは画像バッファ２（１０７）に出力された画像データが、ＣＰＵ１０１によって送信するデータであるか、プロトコル処理部１０２で送信するデータであるかによって、データ転送切替部１０９を制御する。ＣＰＵ１０１によって送信するデータである場合は、ＣＰＵ１０１に対して画像データの準備完了を割り込み通知する。また、プロトコル処理部１０２で送信するデータである場合は、プロトコル処理部１０２に対して画像データの準備完了を割り込み通知し、プロトコル処理部１０２がデータ転送を受け付ける状態になるのをチェックした後に、データ転送切替部１０９に対して画像データの転送開始させる。

ＣＰＵ１０１は、画像データの送受信を行うアプリケーションソフトウェアを実行する。例えば、本発明の適用形態に監視カメラが考えられるが、本実施形態では、ＣＰＵ１０１において撮影映像配信サーバプログラムを動作させることが考えられる。また、ＣＰＵ１０１では、汎用なＴＣＰ／ＩＰ通信を可能とするプロトコル処理ソフトウェアを有し、ＴＣＰ／ＩＰパケットの送受信を行う。

プロトコル処理部１０２は、本実施形態においては、画像データを送信にかかるプロトコル処理時間を極小化する送信専用のハードウェア回路装置である。ただし、画像データをリアルタイムに送信処理するための専用プログラムを実行するプロセッサによる構成、あるいはプロセッサとハードウエアアクセラレート回路による構成で実現してもよい。撮像部１０３、エンコーダ１０４によって作成される画像データを、パケット化してリアルタイムにネットワーク上へ送信することを可能とする。プロトコル処理部１０２は、データリンク層、ＩＰ、ＵＤＰ、ＴＣＰのプロトコル、また、ＣＰＵ１０１で実行するアプリケーションが使用する動画ストリーミングプロトコルにおけるパケット作成処理を行う。動画ストリーミングのプロトコルには、例えばＲＴＰやＨＴＴＰが挙げられる。

エンコーダ１０４からの画像データをリアルタイムに送信する場合、画像データは、１０６と１０７のどちらかの画像バッファに出力されると、直ちにデータ転送切替部１０９によってプロトコル処理部１０２に転送される。プロトコル処理部１０２は順次、転送される画像データをパケット化する。

１１０の通信管理データは、ＣＰＵ１０１とプロトコル処理部１０２間において、ＴＣＰ／ＩＰや動画ストリーミングにおけるプロトコル制御情報、またプロトコル処理部１０２が送出するパケットの統計情報などを保持する。本実施形態では、通信管理データ１１０は共有メモリで実現されている。ＴＣＰ／ＩＰの制御情報は、ＴＣＰ／ＩＰのセッション状態、送受信パケットのシーケンス番号やフローコントロールなどが含まれる。また、上位のストリーミングプロトコルにおけるストリーミング制御情報も含まれる。

ＣＰＵ１０１とプロトコル処理部１０２からの送信パケットは、最終的に１１５のＭＡＣによって伝送制御され、ネットワークへ送出される。本発明では、双方から出力されるパケットの送信にかかる１１５のＭＡＣの制御を行うために、１１１の送信タイミング制御部を有する。

送信タイミング制御部１１１は、ＣＰＵ１０１のＴＣＰ／ＩＰプロトコル処理と、プロトコル処理部１０２によって作成されるパケットの送信を調整する。この送信タイミング制御部１１１は、プロトコル処理部１０２が作成するストリーミングパケットを優先して送信させる特徴を備えており、ＣＰＵ１０１からのパケットは、プロトコル処理部１０２からの送信パケットがない間に送信するように、双方からのパケットの送信を制御する。

ＣＰＵ１０１のＴＣＰ／ＩＰプロトコル処理は、送信パケットを一旦１１２の送信バッファでキューイングする。ＣＰＵ１０１は、送信パケットを送信バッファ１１２にキューイングした後、送信タイミング制御部１１１に対して送信要求を発行する。同様に、プロトコル処理部１０２は、送信パケットを出力する際に、送信タイミング制御部１１１に送信要求を発行する。送信タイミング制御部１１１は、双方からの送信パケットの送信順を決定し、ＭＡＣ１１５が送信データを読み出すデータ転送パスを決定するためのセレクタ１１４を制御し、ＭＡＣ１１５に対して送信指示を行う。

ＭＡＣ１１５は、ＣＰＵ１０１のＴＣＰ／ＩＰプロトコル処理で作成したパケットを送信する場合は、送信バッファ１１２からパケットを読み出す。一方、プロトコル処理部１０２で作成したパケットを送信する場合は、ＭＡＣ１１５はプロトコル処理部１０２から直接パケットを転送する。

ＭＡＣ１１５からのパケット送信完了の通知は、送信タイミング制御部１１１が受け取る。送信完了通知を受信後、ＣＰＵ１０１かプロトコル処理部１０２のどちらか送信を完了したパケットを作成したブロックに対して、送信完了を通知する。

１１３は、受信パケットが書き込まれるメモリである受信バッファである。本実施形態において、ＭＡＣ１１５で受信したパケットは、受信バッファ１１３に書き込まれる。そしてＭＡＣ１１５からＣＰＵ１０１に対して受信割り込みが通知される。受信パケットは、全てＣＰＵ１０１のＴＣＰ／ＩＰプロトコル処理によって解釈されることになる。

ＣＰＵ１０１が、プロトコル処理部１０２のストリーミング通信における、例えばＲＴＣＰパケットのようなストリーミング制御パケットや、ＡＣＫパケットおよびＴＣＰの通信セッションの制御情報を受信した場合には、通信管理データ１１０を更新する。
以上が本実施形態の全体的な実施構成である。

次に入力切替制御部１０５における制御方法の実施形態を、図２、図３および図４を参照しながら示す。

図２は、入力切替制御部１０５が有する、エンコーダ１０２、セレクタ１０８、およびデータ転送切替部１０９を制御するため必要な動画ストリーム毎の属性情報の一例を示している。それぞれのストリームの属性情報は、ＣＰＵ１０１によって与えられる。図２には、ストリームの識別子として、Ｎｏ（２０１）がａ〜ｄまで、４ストリームが示されている。各ストリームの属性には、画像（動画）フォーマット（２０２）、フレーム角（２０３）、フレームレート（２０４）があり、また、エンコーダ１０４から出力される画像データを、ＣＰＵ１０１とプロトコル処理部１０２のどちらへ渡すべきかの値（２０５）がある。これらのストリームの属性情報は、ＣＰＵ１０１が設定する。

入力切替制御部１０５は、各ストリームの属性情報に基づき、エンコーダ１０４、セレクタ１０８、データ転送切替部１０９に対して一連の動作シーケンスを制御する。入力切替制御部１０５がマイクロプロセッサで実現する場合において、各ストリームの画像フレームデータにおける上記制御プログラムのフローチャートを図３に示す。

入力切替制御部１０５のある画像フレームにおける処理フローは、３０１から開始し、はじめに３０２において、エンコーダ１０４から出力先となる画像バッファを、画像バッファ１（１０６）と画像バッファ２（１０７）のいずれか、前回のエンコードの出力先と異なる方になるように、セレクタ１０８を切替える。次に３０３において、エンコーダ１０４に対し、画像データのエンコードのフォーマットなどの設定を行う。続いて、Ｓ３０４でエンコーダ１０４にエンコード開始を指示する。そして画像データのエンコードが終了するのを待ち、Ｓ３０５において、エンコーダからエンコード完了の割り込み通知を受ける。

次にＳ３０６に進み、画像バッファ１（１０６）または画像バッファ２（１０７）に出力された画像データが、プロトコル処理部１０２で送信処理するデータであるかを判別し、プロトコル処理部１０２で送信する場合には、Ｓ３０７に進み、そうでないならば、ＣＰＵ１０１で処理されるデータであるので、以降の処理はＳ３１２からとなる。

Ｓ３０７では、プロトコル処理部１０２に対して、画像データの転送に先立ち、画像データの準備完了を割り込み通知する。次にＳ３０８において、プロトコル処理部１０２が画像データ転送を受け付けられる状態になるまで画像データ転送を待機する。そしてＳ３０９で、画像データが書き込まれた画像バッファがいずれかにより、画像バッファ１（１０６）の場合はＳ３１０でデータ転送切替部１０９にプロトコル処理部１０２への画像データを転送開始する指示を出す。画像バッファ２（１０７）の場合も同様である。次にＳ３１１において画像データの転送を開始させる。そして、Ｓ３１６へ進み、この画像データについての一連の処理フローが終了する。

Ｓ３０６において、画像データがＣＰＵ１０１で送信される場合は、Ｓ３１２へと進む。Ｓ３１２で画像データがどちらの画像バッファに書き込まれたかにより、画像バッファ１（１０６）の場合は、Ｓ３１３においてＣＰＵから画像バッファ１をアクセス可能となるようにデータ転送切替部１０９を設定する。画像バッファ２（１０７）に書き込まれた場合には、Ｓ３１４においてＣＰＵから画像バッファ２をアクセス可能となるようにデータ転送切替部１０９を設定する。Ｓ３１３とＳ３１４から次にＳ３１５へ進み、ＣＰＵ１０１に対して画像データの準備完了を割り込み通知を行い、Ｓ３１６に進み、この画像データについての一連の処理フローが終了する。

入力切替制御部１０５は、以上の処理フローを各ストリームについて繰り返し実行し、エンコーダ１０４からＣＰＵ１０１あるいはプロトコル処理部１０２への画像データ入力を制御することになる。図４に、図２が示す４本のストリーム（ａ〜ｄ）例について、入力切替制御部１０５が実行する画像データ入力の制御例を模式的なタイムチャートで表したものである。

図４は、縦軸４０１と４０２の間が１００ｍｓの時間幅を表し、入力切替制御部１０５が繰り返す制御内容を時間幅内で表している。

横軸４０３には、撮像部１０３から非圧縮画像データ出力のタイミングを４０９〜４１０で表す。横軸４０４上には、エンコードに要する時間を４１２〜４１９で表す。４１２〜４１９のそれぞれの時間内には、入力切替制御部１０５がエンコーダ１０４へのエンコード設定と、エンコーダ１０４の動作時間を含む。４１２〜４１９それぞれに記したａ〜ｄは、図２で示したストリームのＮｏであり、対象とするストリームを示している。例えば４０９のタイミングで出力される非圧縮画像データは、４１２〜４１４で３度エンコードされ、それぞれｂ、ｃ、ａのストリームがエンコード対象であることを示す。同様に４１０で出力される非圧縮画像データは４１５〜４１７でｂ、ｄ、ａのストリーム用にエンコードし、４１１についても、４１８〜４１９でｂ、ａのストリーム用にエンコードすることを示している。

横軸４０５は、エンコーダ１０４からの出力先の画像バッファの選択時間を示す。それぞれの選択時間に記された"１"または"２"は、それぞれ画像バッファ１（１０６）と画像バッファ２（１０７）を示す。前述のように、入力切替制御部１０５は、セレクタ１０８を制御して、エンコード毎に画像バッファ１と２のダブルバッファをそれぞれ切替える。

横軸４０６と４０７は、入力切替制御部１０５の制御によるデータ転送切替部１０９の動作を示し、４０６は画像バッファ１（１０６）、４０７は画像バッファ２（１０７）に対応した動作を示す。それぞれの横軸上に記された、４２８〜４３０、４３２〜４３６の三角の記号△あるいは▽は、データ転送切替部１０９の動作切替えのタイミングを示す。△Ｐは画像バッファからプロトコル処理部１０２へのデータ転送開始を表し、△Ｃは、ＣＰＵ１０１に画像バッファのデータにアクセス可能とするタイミングを表している。また４３１の斜線範囲は、ＣＰＵ１０１が画像バッファにアクセス可能な期間を示している。
すなわち、入力切替制御部１０５は、画像バッファ１（１０６）からプロトコル処理部１０２へのデータ転送は、４２８、４２９、４３２の時点で実行し、画像バッファ２（１０７）からは、４３３〜４３６のそれぞれの時点で実行するように、データ転送切替部１０９を制御する。

横軸４０８には、入力切替制御部１０５から、ＣＰＵ１０１あるいはプロトコル処理部１０２への入力画像データの準備完了の割り込み通知をするタイミングを４３７〜４４４で表している。４３７〜４４０と４４２〜４４４の三角の記号▲Ｐは、プロトコル処理部１０２への割り込み通知を表し、４４１の▲Ｃは、ＣＰＵ１０１への割り込み通知を表す。
以上を踏まえ、ある１つのストリームにおける入力切替制御部１０５が繰り返す制御処理について、図２のストリームＮｏ．ｂとＮｏ．ｄを例に挙げ、図４を参照しながら説明する。

まずＮｏ．ｂのストリームについて説明する。ストリームＮｏ．ｂの連続する３フレームは、図４では４０９、４１０、４１１の非圧縮画像データである。４０９の非圧縮画像データの場合、入力切替制御部１０５は、４２０でエンコード出力先に画像バッファ１（１０６）をセレクタ１０８で選択し、４１２でエンコードを実行するように制御を行う。次に、ストリームＮｏ．ｂはプロトコル処理部１０２で送信するので（図２を参照）、４１２のエンコード終了後の４３７において、入力切替制御部１０５は、プロトコル処理部１０２に画像データの準備完了の割り込み通知を行う。その後、４２８においてデータ転送切替部１０９に画像データの転送を開始させる。入力切替制御部１０５は、他の非圧縮画像４１０、４１１についても、同様の制御を行う。

ストリームＮｏ．ｄの場合は、図４の４１０の非圧縮画像データをエンコードする。入力切替制御部１０５は、４２４でエンコード出力先に画像バッファ１（１０６）をセレクタ１０８で選択し、４１６でエンコードを実行するように制御を行う。ストリームＮｏ．ｄはＣＰＵ１０１によって送信するので（図２を参照）、４１６のエンコード終了後の４３０において、入力切替制御部１０５は、ＣＰＵ１０１から画像バッファ１（１０６）がアクセス可能となるようにデータ転送切替部１０９を制御する。その後、４４１においてＣＰＵ１０１に画像データの準備完了の割り込み通知を行う。ＣＰＵ１０１が画像バッファ１（１０６）のデータにアクセス可能である期間は、次に画像バッファ１（１０６）にエンコード後データが書き込まれる４２６までの間である４３１の期間となる。

以上、図２、図３および図４を参照して、本実施形態における入力切替制御部１０５の制御方法の一例を示した。

次に、送信タイミング制御部１１１におけるＣＰＵ１０１とプロトコル処理部１０２の双方からのパケット送信の調整方法について、実施形態を図５を参照しながら示す。

図５は、ＣＰＵ１０１とプロトコル処理部１０２、送信タイミング制御部１１１、およびＭＡＣ１１５間におけるパケット送信処理のシーケンスの一例を表している。図５の上から下へ時間推移を表しており、各処理部間での送信要求、および送信完了の通知を矢印で示している。

図５において、Ｐ５０１−１のように、記号名に'Ｐ'が付く矢印はプロトコル処理部１０２からのパケット送信処理を意味し、記号名に'Ｃ'が付く矢印はＣＰＵ１０１からのパケット送信処理を意味する。また、１つのパケットの一連の送信シーケンスは、枝番号が'１'〜'４'の異なる４つの矢印で示されている。例えば、Ｐ５０１−１はプロトコル処理部１０２から送信タイミング制御部１１１への送信要求であり、Ｐ５０１−２は、同パケットの送信タイミング制御部１１１からＭＡＣ１１５への送信指示であり、Ｐ５０１−３は同パケットのＭＡＣ１１５から送信タイミング制御部１１１への送信完了通知であり、Ｐ５０１−４は、送信タイミング制御部１１１からプロトコル処理部１０２への同パケットの送信完了通知である。

前述の通り、ＣＰＵ１０１とプロトコル処理部１０２は、作成したパケットを送信タイミング制御部１１１に対して送信要求を発行する。また、ＣＰＵ１０１は、送信パケットを送信バッファ１１２でキューイングした後に、送信を要求する。

プロトコル処理部１０２は、画像バッファから転送される画像データを順次パケット化して送信するため、画像データ毎にまとまった個数のパケットを連続して送信要求する。図５の５１２の破線範囲は、プロトコル処理部１０２がＰ５０１〜Ｐ５０４のパケットを連続して送信することを記している。同様に、５１３の破線範囲はＰ５０８〜Ｐ５１０のパケットを連続して送信することを記している。

プロトコル処理部１０２からのパケット連続送信は、各パケット作成後に即時に送信開始することで実現する。送信タイミング制御部１１１は、プロトコル処理部１０２からパケットの送信要求が届くと、該パケットを次の送信パケットに設定してＭＡＣ１１５に送信指示を行う。

一方、ＣＰＵ１０１からのパケットの送信は、送信バッファ１１２でキューイングする。図５において、Ｃ５０５〜Ｃ５０７のパケットは、送信タイミング制御部１１１に対して５１２の範囲のプロトコル処理部１０２からの連続送信処理中に、送信要求を行っている。Ｃ５０５〜Ｃ５０７のパケットはキューイングされており、送信タイミング制御部１１１は、５１２の範囲の送信処理の終了後に、これらのパケットの送信を開始する。図５では、Ｃ５０５のパケットの送信処理が済み、次のＣ５０６のパケットの送信処理中に、プロトコル処理部１０２によって、５１３の範囲に記されたＰ５０８〜Ｐ５１０のパケットの連続送信が始まっている。このため、送信タイミング制御部１１１は、Ｃ５０６の送信処理を終了後、プロトコル処理部１０２の送信処理が優先してＰ５０８を送信する。Ｃ５０７のパケットは、５１３の範囲にあるプロトコル処理部１０２の送信が終了後に送信する。Ｃ５１１のパケットも同様に、送信タイミング制御部１１１が送信を遅延させ、Ｃ５０７の送信後に送信を行う。

尚、プロトコル処理部１０２から送信タイミング制御部１１１への送信要求において、プロトコル処理部１０２が、送信処理する画像データがまだ残っているか、すなわち連続して送信要求が続くかどうかの情報を付加する。これにより、送信タイミング制御部１１１は、プロトコル処理部１０２からの連続する送信要求の合間を判断し、ＣＰＵ１０１からの送信パケットの送信を開始する。

以上、図５に示す例を挙げて、送信タイミング制御部１１１のパケット送信の調整方法について実施形態を説明した。この方法によってプロトコル処理部１０２からのパケットを優先し、送信処理における遅延量を極力無くすことが可能である。

最後にＣＰＵ１０１における画像データの送信処理について説明する。本実施形態において、エンコーダ１０４から、ＣＰＵ１０１で送信すべき画像データが、１０６あるいは１０７のいずれかの画像バッファに出力されると、入力切替制御部１０５から画像データの準備完了の割り込み通知を受ける。そして画像バッファの画像データにアクセスし、アプリケーション、および汎用プロトコルスタックによる送信パケット処理を行う。パケットの送信は、送信バッファ１１２に送信パケットを書き込み、送信タイミング制御部１１１に対して送信要求を発行する。また、ＣＰＵ１０１は、入力切替制御部１０５に動画ストリームの属性情報を設定する。

このようなＣＰＵ１０１の処理について、処理フローを図６に示す。ＣＰＵ１０１の処理フローはＳ６０１から始まり、まずＳ６０２において入力切替制御部１０５の初期設定を行う。初期設定においては、ＣＰＵ１０１とプロトコル処理部１０２で送信処理する各ストリームの属性情報の設定を行う。次にＳ６０３においてプロトコル処理部１０２の初期設定を実行する。また、通信管理データ１１０にストリーミング送信するプロトコル等における初期設定情報を書き込む。続いて撮像部１０３と入力切替制御部１０５の処理を開始する。

Ｓ６０５からは、ＣＰＵ１０１による、エンコーダ１０４からの画像データを待って送信を行う処理である。Ｓ６０５では入力切替制御部１０５から画像データ準備完了の割り込み通知が待ち、Ｓ６０６で画像データ準備完了の割り込み通知を受ける。ＣＰＵ１０１で送信する画像データが画像バッファに準備されると、Ｓ６０７の判定で未送信の画像データがなくなるまで、Ｓ６０８からＳ６１３までの画像データの送信処理を繰り返す。未送信が画像データが無くなると、Ｓ６０５に戻り、再び画像データ準備完了の割り込み通知を待つ。

Ｓ６０８では送信バッファ１１２に、送信パケットをキューイングするのに十分な空き領域があるかを調べる。空き領域がある場合はＳ６０９に進み、アプリケーションによるストリーミングプロトコル処理、および汎用ＴＣＰ／ＩＰプロトコル処理を実行し、画像データから送信パケットを作成する。続いてＳ６１０において、作成したパケットを送信バッファ１１２にキューイングし、Ｓ６１１で送信タイミング制御部１１１に対して送信要求を発行する。そしてＳ６０７に戻り、未送信の画像データがあれば再び次のパケットの送信処理をＳ６０８から開始する。

Ｓ６０８において、送信バッファ１１２に送信パケットをキューイングする空き領域が
ない場合は、Ｓ６１２へと進む。Ｓ６１２では、送信タイミング制御部１１１から、先に送信要求を出したパケットの送信完了の通知を待つ。Ｓ６１３で送信完了の通知を受けると、Ｓ６０８に戻り、再度送信バッファ１１２の空き領域を調べる。

以上の処理フローによって、ＣＰＵ１０１は、送信すべき画像データが生成されたときに送信処理を開始し、画像データの送信処理の後に再び、画像データを待機する動作を行うことになる。

以上、本発明における実施形態の一例を示した。本実施形態によれば、アプリケーションは、ストリーム毎にＣＰＵ１０１とプロトコル処理部１０２で送信処理を切り替わるように入力切替制御部１０５の設定を行うことができ、エンコーダ１０４からの画像データは、自動的にＣＰＵ１０１とプロトコル処理部１０２に振り分けられる。したがって、例えば送信遅延を極力低減するような、撮影動画のリアルタイム送信はプロトコル処理部１０２で実行し、送信にかかる遅延時間を容認しても汎用的なプロトコル処理によって柔軟な送信処理を行うには、ＣＰＵ１０１で送信処理を行うといった適用が可能となる。

（第２の実施形態）
第１の実施形態では、図１における送信タイミング制御部１１１が、ＣＰＵ１０１が送信要求するパケットより送信プロトコル処理部１０２が送信要求するパケットを優先して送信する制御を行うとしていた。送信タイミング制御部１１１は、プロトコル処理部１０２からの送信パケットを優先するため、ＣＰＵ１０１からの送信パケットは送信バッファ１１２でキューイングされる。したがって、ＣＰＵ１０１とプロトコル処理部１０２で送信処理するストリーム総数が多い場合や、ＣＰＵ１０１側で送信処理する画像データ量が非常に大きい場合などでは、ＭＡＣ１１５が伝送帯域の大きい通信メディアであっても、送信バッファ１１２でキューイング可能なデータ量の制限により、送信パケットデータがオーバーフローする可能性がある。

本発明の第２の実施形態では、ＣＰＵ側の送信バッファでのオーバーフローを回避するための実施構成およびパケットの送信制御について、図７を参照しながら説明する。

図７は、前記実施形態１における図１が示す全体構成において、ＣＰＵ１０１とプロトコル処理部１０２の送信処理より後段部分を変更した図である。尚、本実施形態においては、ＣＰＵとプロトコル処理部より前段の構成は、第１の実施形態と同様であるとする。

図７において、７０１はＣＰＵ、７０２はプロトコル処理部、７０３は送信タイミング制御部、７０４は送信バッファ、７０５はＭＡＣであり、７０６はＭＡＣがデータを読み出すデータ転送パスを決定するためのセレクタである。７０８は、ＣＰＵ７０１への入力画像データパスを表し、７０９はプロトコル処理部７０２への入力画像データパスを表している。

本実施形態では、図７の７１０のデータパスに流れるプロトコル処理部からの送信パケットを、ＵＤＰパケットに限定する。すなわち、本実施形態では、上位のストリーミングプロトコルがＵＤＰパケットを利用するものとする。このようなストリーミングの上位プロトコルには、例えば、ＲＴＰが挙げられる。

また、本実施構成では、７０７のバッファ監視部を有する。バッファ監視部７０７は、送信バッファ７０４の空き残量を監視する機能を持つ。送信バッファ７０４は、メモリ装置上に、送信パケットキューの管理データ７１１とパケットデータの記憶領域７１２で構成している。バッファ監視部７０７は、送信パケットキューの管理データ７１１を読み出し、パケットデータの記憶領域７１２の空き残量を監視を行う。以下、送信バッファ７０４の空き残量は、パケットデータの記憶領域７１２の空き残量を意味することとする。

バッファ監視部７０７は、信号線７１３で送信タイミング制御部７０３に接続しており、送信バッファ７０４の空き残量がオーバーフローが起こらないとする閾値よりも少ないか否かによって、信号線７１３の状態を変化させる。

送信タイミング制御部７０３は、バッファ監視部７０７からの信号線７１３の状態が、送信バッファ７０４の空き残量が閾値よりも大きい状態であるときは、プロトコル処理部７０２からの送信パケットを優先して送信を行う。反対にバッファ７０４の空き残量が閾値よりも小さい状態であるときは、空き残量が閾値よりも大きくなるまで、プロトコル処理部７０２からのパケットの送信を抑制調節し、送信バッファ７０４にキューイングされたパケットを送信できる制御を行う。

この制御は、プロトコル処理部７０２からの送信を間引くことによって実現する。すなわち、プロトコル処理部７０２からのＵＤＰパケットの送信要求に対して、ランダムな要求回数ごとに、ＭＡＣ７０５への送信指示をせず、実際の送信を行わないで即座にプロトコル処理部７０２へ送信完了を通知する。

つまり、送信タイミング制御部７０３は、プロトコル処理部７０２からのパケット送信回数を減らし、送信バッファ７０４にキューイングされているパケット、およびＣＰＵ７０１が送信要求するパケットを送出するタイミングを増やす。

以上の制御方法により、送信バッファ７０４のオーバーフローが起こらないような送信制御を実現する。

（第３の実施形態）
第２の実施形態では、ＣＰＵ側の送信バッファでのオーバーフローを回避するために、第１の実施形態におけるＣＰＵ１０１とプロトコル処理部１０２の送信処理より後段部分の実施構成およびパケットの送信制御について説明している。本実施形態においても、第２の実施形態と同様にＣＰＵ側の送信バッファでのオーバーフローを回避することを目的とする。以下、実施構成および画像データのエンコード制御について、図８と図９を参照しながら説明する。

図８は、本発明の第３の実施形態の全体構成を示す図である。図８の８０１〜８１５は、前記実施形態１における図１の１０１〜１１５と同じ構成である。すなわち、ＣＰＵ（８０１）、プロトコル処理部（８０２）、撮像部（８０３）、エンコーダ（８０４）、入力切替制御部（８０５）、画像バッファ１（８０６）、画像バッファ２（８０７）、出力画像バッファのセレクタ（８０８）、データ転送切替部（８０９）、通信管理データ（８１０）、送信タイミング制御部（８１１）、送信バッファ（８１２）、受信バッファ（８１３）、送信データの入力セレクタ（８１４）、ＭＡＣ（８１５）である。

また、本実施構成では、８１６のバッファ監視部を有する。バッファ監視部８１６は、送信バッファ８１２の空き残量を監視する機能を持つ。送信バッファ８１２は、メモリ装置上に、送信パケットキューの管理データ８１７とパケットデータの記憶領域８１８で構成している。バッファ監視部８１６は、送信パケットキューの管理データ８１７を読み出し、パケットデータの記憶領域８１８の空き残量の監視を行う。以下、送信バッファ８１２の空き残量は、パケットデータの記憶領域８１８の空き残量を意味することとする。

バッファ監視部８１６は、信号線８１９で送信タイミング制御部８１１に接続しており、送信バッファ８１２の空き残量によって、信号線８１９の状態を変化させる。バッファ監視部８１６は、送信バッファ８１２の空き残量に対して２つの閾値でチェックを行い、信号線８１９を３レベルの状態に保持および変化させる。具体的には、送信バッファ８１２の空き残量が第１の閾値よりも大きい場合は、空き残量に余裕があり、送信バッファ８１２のオーバーフローが起こらない状態であり、第１のレベルとする。送信バッファ８１２の空き残量が第１の閾値よりも小さく、第２の閾値よりも大きい場合は、空き残量が足りなくなってきている状態であり、第２のレベルとする。送信バッファ８１２の空き残量が第２の閾値よりも小さい場合は、送信バッファ８１２の空き残量が小さく、オーバーフローを起こす可能性が高い状態であり、第３のレベルとする。バッファ監視部８１６は、信号線８１９をこの３レベルの状態にいずれかを保持することになる。

本実施形態の送信タイミング制御部８１１は、バッファ監視部８１６からの信号線８１９の状態の変化が起こると、入力切替制御部８０５に対して、エンコード制御の変更指示を発行する（８２０）。すなわち、送信バッファ８１２の空き残量によって、画像データのエンコード制御にフィードバックを行うことを可能とする。

エンコード制御の変更指示８２０は、制御変更の対象とするストリームがＣＰＵ８０１側の送信ストリームだけか、全送信ストリームであるかと、対象のストリームのビットレートを下げるか、通常のビットレートに戻すかを指示する。具体的に述べると、送信タイミング制御部８１１は、前記信号線８１９の状態が第１のレベルから第２のレベルに変化したときと、第３のレベルから第２のレベルに変化したときに、ＣＰＵ８０１側の送信ストリームを対象としてビットレートを下げるエンコード制御への変更指示を出す。また、前記信号線８１９の状態が、第２のレベルから第３のレベルに変化したときと、第１のレベルから第３のレベルに変化したときに全送信ストリームを対象としてビットレートを下げるエンコード制御への変更指示を出す。さらに、前記信号線８１９の状態が、第２のレベルから第１のレベルに変化したときと、第３のレベルから第１のレベルに変化したときに全ストリームを対象として、通常のビットレートで出力するエンコード制御への変更指示を出す。

このような送信タイミング制御部８１１から入力切替制御部８０５へのエンコード制御変更指示８２０により、入力切替制御部８０５は、３種類のエンコード制御を実行する。第１のエンコード制御は、ＣＰＵ８０１によって入力切替制御部に設定される各ストリームの属性情報に合致するように、通常のビットレートで画像データのエンコードを行う。

第２のエンコード制御は、ＣＰＵ８０１によって送信処理する動画ストリームだけを対象とし、各ストリームのビットレートを下げるように画像データをエンコードする制御である。第３のエンコード制御は、全ての動画ストリームを対象として、各ストリームのビットレートを下げるように画像データのエンコードを行う制御である。各ストリームのビットレートを下げる制御は、エンコード形式により異なるが、例えばＪＰＥＧの場合は量子化テーブルを切替えて量子化レベルが大きくなるように設定したり、ＭＰＥＧの場合は、ストリーム毎のエンコーダ８０４へのビットレートの設定を低くしたり、エンコーダ８０４への詳細制御が可能な場合は量子化ステップサイズを大きくすることやフレーム内圧縮符号化のフレーム間隔を大きくするなどのエンコード条件を変更することで実現する。

次に送信タイミング制御部８１１からのエンコード制御変更指示８２０によって、入力切替制御部８０５のエンコード制御を変更する処理フローについて図９を参照して述べる。

本実施形態において、図９が示す入力切替部制御８０５のエンコード制御の変更処理はＳ９０１から始まり、撮像部９０３から出力される非圧縮デジタル画像データ毎に処理するＳ９０２からＳ９１１までのループ処理である。はじめにＳ９０３において、送信タイミング制御部８１１からエンコード制御変更指示８２０があるかを調べ、指示があるならばＳ９０４に進む。エンコード制御の変更指示がないならば、現状のエンコード制御のままであるとして、Ｓ９１０に進む。

Ｓ９０４では、エンコード制御変更指示８２０がビットレートを下げる制御であるか否かを調べる。ビットレートを下げる指示であるならばＳ９０５に進み、そうでないならばＳ９０６に進む。Ｓ９０５では、ビットレートを下げる制御指示の対象がＣＰＵ８０１で送信処理するストリームであるならば、Ｓ９０８に進む。そうでないならばＣＰＵ８０１とプロトコル処理部８０２の両方で送信する全ストリームを対象としているのであり、Ｓ９０７に進む。

一方、Ｓ９０４からＳ９０６へ進む場合は、ストリーム毎に通常のビットレートでエンコードを行う制御に戻す指示である。Ｓ９０６においては、ビットレートを戻す対象のストリームが全ストリームであるか否かを調べ、全ストリームが対象としているならば、Ｓ９０９に進む。そうでないならばＳ９０８へ進む。

Ｓ９０７では全ストリームを対象として、各ストリームのビットレートを下げるエンコード制御に移行する。すなわち前記第３のエンコード制御への移行を意味する。Ｓ９０８では、ＣＰＵ８０１側の送信ストリームを対象とし、各ストリームのビットレートを下げるエンコードを行い、プロトコル処理部８０２で送信処理するストリームについては、通常のビットレートでエンコードする制御に移行する。すなわち前記第２のエンコード制御への移行を意味する。Ｓ９０９は、全ストリームのエンコードは、各ストリームにおける通常のビットレートで実行する制御に移行する。すなわち前記第１のエンコード制御への移行を意味する。

Ｓ９０７、Ｓ９０８、Ｓ９０９でのエンコード制御が移行すると、Ｓ９１０に進む。Ｓ９１０は画像データをエンコード、および送信処理するための入力切替制御部８０２の処理であり、図３で示される処理フローである。次にＳ９１１へ進んでＳ９０２からの処理ループが完了する。

以上のような処理フローにより、入力切替制御部８０５は、送信タイミング制御部８１１からのエンコード制御変更指示８２０に従って、画像データのエンコード制御の変更を行う。

以上、本実施形態について詳細を説明した。本実施形態では、バッファ監視部８１６が、ＣＰＵ８０１からの送信パケットをキューイングする送信バッファ８１２の空き残量を監視し、送信タイミング制御部８１１に送信バッファの空き残量状態を検知させることができ、これによって送信タイミング制御部８１１は、入力切替制御部８０５へエンコード制御変更指示８２０を行うことができる。一方、入力切替制御部８０５は、送信タイミング制御部８１１からのエンコード制御変更指示８２０によって、動画ストリームのビットレートを下げる制御を行う。本実施形態によれば、送信バッファ８１２の空き残量が少なくなると、ＣＰＵ８０１で送信処理するストリームのデータ量を減らして送信バッファにキューイングするデータ量を減らしたり、プロトコル処理部８０２で送信処理するストリームのデータ量を減らして送信回数を少なくしてＣＰＵ８０１が送信要求するパケットを送出するタイミングを増やすことができる。したがって、送信バッファ８１２がオーバーフローが起こらないような送信制御を実現することが可能となる。

（第４の実施形態）
第１から第３の実施形態においては、エンコーダ１０４の設定や制御およびデータ転送切替部１０９の制御はマイクロプロセッサで構成される入力切替制御部１０５のソフトウェア制御で行い、画像データの送受信を行うアプリケーションソフトウェアおよび汎用的な通信プロトコルスタックの実行はＣＰＵ１０１で行うような実施形態であった。第４の実施形態では、これらの制御をすべて単一のＣＰＵで行うような実施形態について説明する。

図１０は、本発明の第４の実施形態における全体構成の一例を示す図である。図１０におけるプロトコル処理部１０２からＭＡＣ１１５は、第１の実施形態で説明した図１、１０２〜１１５と同様の構成ブロックとなる。図１０において、１００１はＣＰＵであり、このＣＰＵで実行されるソフトウェアにより、以下の制御を実行するものである。

ＣＰＵ１００１は、撮像部１０３が出力する画像フレームデータ毎に、エンコーダ１０４に対して、エンコード形式や圧縮効率などのパラメータの設定を行う。また、エンコードの開始タイミングを指示し、エンコード完了を通知する割り込み信号を受け取るなどの、エンコーダ制御を行う。また、エンコーダ１０４が出力する画像データのデータパスのセレクタ１０８を制御し、どちらの画像バッファに出力するかを決定する。また、画像バッファ１（１０６）もしくは画像バッファ２（１０７）に出力された画像データが、ＣＰＵ１００１によって送信するデータであるか、プロトコル処理部１０２で送信するデータであるかによって、データ転送切替部１０９を制御する。ＣＰＵ１００１によって送信するデータである場合は、ＣＰＵ１００１に対して画像データの準備完了を割り込み通知する。また、プロトコル処理部１０２で送信するデータである場合は、プロトコル処理部１０２に対して画像データの準備完了を割り込み通知し、プロトコル処理部１０２がデータ転送を受け付ける状態になるのをチェックした後に、データ転送切替部１０９に対して画像データの転送開始させる。また、画像データの送受信を行うアプリケーションソフトウェアの実行、および汎用的なＴＣＰ／ＩＰ通信を可能とするプロトコル処理ソフトウェアを有し、ＴＣＰ／ＩＰパケットの送受信を行う。また、ＣＰＵ１００１のＴＣＰ／ＩＰプロトコル処理は、送信パケットを一旦１１２の送信バッファでキューイングした後、送信タイミング制御部１１１に対して送信要求を発行する。

次に図１１において、第４の実施形態におけるＣＰＵ１００１による制御フローチャートを説明する。

図１１において、ＣＰＵ１０１の処理フローはＳ１１０１から始まり、まずＳ１１０２においてプロトコル処理部１０２の初期設定を実行する。また、通信管理データ１１０にストリーミング送信するプロトコル等における初期設定情報を書き込む。続いてＳ１１０３において、撮像部１０３に対して撮像開始指示を行うことにより、撮像データの取り込みが開始する。Ｓ１１０４では、撮像部１０３により撮像された１フレーム分の非圧縮画像データの到着を待ち、データが到着するとＳ１１０５において、エンコーダ１０４からの出力先となる画像バッファを、画像バッファ１（１０６）と画像バッファ２（１０７）のいずれか、前回のエンコードの出力先と異なる方になるように、セレクタ１０８を切替える処理を実行する。次に１１０６において、エンコーダ１０４に対し、画像データのエンコードのフォーマットなどの設定を行う。続いて、Ｓ１１０７でエンコーダ１０４にエンコード開始を指示する。

Ｓ１１０８では、Ｓ１１０７でエンコーダが出力する画像バッファとは異なるほうの画像バッファにすでにエンコードされたストリームデータがあるかどうかをチェックし、データがある場合には、エンコーダ１０４によるエンコード処理を継続したままＳ１１１０へ進む。データがない場合にはＳ１１０９において、エンコードが終了するのを待ち、エンコーダ１０４からエンコード完了の割り込み通知を受けるとＳ１１１０へ進む。

Ｓ１１１０では、画像バッファ１（１０６）または画像バッファ２（１０７）に出力された画像データが、プロトコル処理部１０２で送信処理するデータであるかを判別し、プロトコル処理部１０２で送信する場合には、Ｓ１１２１に進み、そうでないならば、ＣＰＵ１００１で処理されるデータであるので、以降の処理はＳ１１１１からとなる。

Ｓ１１２１では、プロトコル処理部１０２に対して、画像データの転送に先立ち、画像データの準備完了を割り込み通知する。次にＳ１１２２において、プロトコル処理部１０２が画像データ転送を受け付けられる状態になるまで画像データ転送を待機する。そしてＳ１１２３で、画像データが書き込まれた画像バッファがいずれかにより、画像バッファ１（１０６）の場合はＳ１１２４でデータ転送切替部１０９にプロトコル処理部１０２への画像データを転送開始する指示を出す。同様に画像バッファ２（１０７）の場合も、Ｓ１１２５において画像データの転送を開始させる。Ｓ１１２４、Ｓ１１２５の処理が終了すると、Ｓ１１２６において、撮像部１０３で撮像された１フレーム分の非圧縮画像データに対するすべての符号化ストリームの送信が終了したかどうかをチェックし、Ｓ１１２７において、送信が終了した場合は再びＳ１１０４の非圧縮データの到着を待つ処理へ戻る。また送信が終了していない場合には、Ｓ１１０５のセレクタを切り替える処理へ戻る。

一方、Ｓ１１１０において、画像データがＣＰＵ１００１で送信される場合はＳ１１１１へと進む。Ｓ１１１１で画像データがどちらの画像バッファに書き込まれたかにより、画像バッファ１（１０６）の場合は、Ｓ１１１３においてＣＰＵから画像バッファ１をアクセス可能となるようにデータ転送切替部１０９を設定する。画像バッファ２（１０７）に書き込まれた場合には、Ｓ１１１２においてＣＰＵから画像バッファ２をアクセス可能となるようにデータ転送切替部１０９を設定する。これらＳ１１１２、１１１３の処理が終了するとＳ１１１４へ進む。

Ｓ１１１４では、送信対象となる画像バッファ中に未送信の画像データがあるかどうかをチェックし、ない場合、つまりすべての画像データの送信が終了した場合は、Ｓ１１２６のすべてのストリームの送信が終了したかどうかのチェックに進む。また、Ｓ１１１４で未送信の画像データが残っている場合は、Ｓ１１１４の判定で未送信の画像データがなくなるまで、Ｓ１１１５からＳ１１２０までの画像データの送信処理を繰り返す。

Ｓ１１１５では送信バッファ１１２に、送信パケットをキューイングするのに十分な空き領域があるかを調べる。空き領域がある場合はＳ１１１６に進み、アプリケーションによるストリーミングプロトコル処理、および汎用ＴＣＰ／ＩＰプロトコル処理を実行し、画像データから送信パケットを作成する。続いてＳ１１１７において、作成したパケットを送信バッファ１１２にキューイングし、Ｓ１１１８で送信タイミング制御部１１１に対して送信要求を発行する。それからＳ１１１４に戻り、未送信の画像データがあれば再び次のパケットの送信処理をＳ１１１５から開始する。

Ｓ１１１５において、送信バッファ１１２に送信パケットをキューイングする空き領域がない場合は、Ｓ１１１９へと進む。Ｓ１１１９では、送信タイミング制御部１１１から、先に送信要求を出したパケットの送信完了の通知を待つ。Ｓ１１２０で送信完了の通知を受けると、Ｓ１１１５に戻り、再度送信バッファ１１２の空き領域を調べる。

以上の処理フローによって、ＣＰＵ１００１は、送信すべき画像データが生成されたときに送信処理を開始し、画像データの送信処理の後に再び、画像データを待機する動作を行うことになる。

また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体をシステム或いは装置に供給し、そのシステム等のコンピュータが記憶媒体からプログラムコードを読み出し実行することによっても達成される。

この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、プログラムコード自体及びそのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

プログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。

また、コンピュータが読み出したプログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ等が実際の処理の一部又は全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれる。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに接続された機能拡張ユニット等に備わるメモリに書込まれた後、そのプログラムコードの指示に基づきＣＰＵ等が実際の処理を行い、前述した実施形態の機能が実現される場合も含まれる。

本発明の実施形態の全体構成の一例を示す図である。 動画ストリームの属性情報の一例を示す図である。 入力切替制御部がマイクロプロセッサで実現される場合において、各ストリームの画像フレームデータにおける制御を示すフローチャートである。 入力切替制御部の画像データ入力の制御例を示す模式的なタイムチャートである。 ＣＰＵとプロトコル処理部、送信タイミング制御部、およびＭＡＣ間におけるパケット送信処理のシーケンスの一例を示す図である。 本発明の第１の実施形態におけるＣＰＵの処理フローを示す図である。 本発明の第２の実施形態におけるＣＰＵとプロトコル処理部から後段部分の構成を示す図である。 本発明の第３の実施形態における全体構成図である。 本発明の第３の実施形態における入力切替制御部の処理フローを示す図である。 本発明の第４の実施形態における全体構成の一例を示す図である。 本発明の第４の実施形態におけるＣＰＵの処理フローを示す図である。

符号の説明

１０１、７０１、８０１、１００１ ＣＰＵ
１０２、７０２、８０２ プロトコル処理部
１０３、８０３ 撮像部
１０４、８０４ エンコーダ
１０５、８０５ 入力切替制御部
１０６、８０６ 画像バッファ１
１０７、８０７ 画像バッファ２
１０８、８０８ エンコーダの出力データパスのセレクタ
１０９、８０９ データ転送切替部
１１０、８１０ 通信管理データ
１１１、７０３、８１１ 送信タイミング制御部
１１２、７０４、８１２ 送信バッファ
１１３、８１３ 受信バッファ
１１４、７０６、８１４ ＭＡＣの入力データパスセレクタ
１１５、７０５、８１５ ＭＡＣ
７０７、８１６ バッファ監視部
７０８ ＣＰＵへの画像データ
７０９ プロトコル処理部への画像データ
７１０ プロトコル処理部が送信するＵＤＰパケットデータ
７１１、８１７ 送信バッファのキューの管理データ
７１２、８１８ 送信バッファのキューの送信パケットデータ
７１３、８１９ バッファ監視部と送信タイミング制御部間の信号線
８２０ エンコード制御変更指示

Claims (8)

1. 複数の形式に圧縮符号化された映像ストリームデータをネットワークに接続された複数の端末に同時に送信するような映像データ送信装置において、
   非圧縮映像データに対して複数の形式の圧縮符号化データを生成することが可能なエンコーダと、
   プロセッサによるソフトウェアで実行される第１のネットワークプロトコル処理手段と、
   画像データのリアルタイム送信処理を実行する第２のネットワークプロトコル処理手段と、
   該エンコーダで生成された複数の圧縮符号化データのうち第１のネットワークプロトコル処理手段によって処理を行うデータと第２のネットワークプロトコル処理手段によって処理を行うデータを選択的に振り分ける手段とを備えることを特徴とする映像データ送信装置。
2. 前記複数の形式の圧縮符号化データは、符号化方式の異なるデータ、またはフレームレートが異なるデータ、またはビットレートが異なるデータ、または映像のピクセル数が異なるデータであることを特徴とする請求項１記載の映像データ送信装置。
3. 前記ネットワークプロトコル処理は、少なくともＴＣＰ／ＩＰで規定される４層モデルにおけるインターネット層、トランスポート層、またはアプリケーション層を含むプロトコル処理であることを特徴とする請求項１記載の映像データ送信装置。
4. 前記エンコーダは、複数の形式の圧縮符号化データを１フレームごとに時分割で生成し、生成された１フレーム分の符号化データを予め設定された組み合わせに応じて、第１のネットワークプロトコル処理手段への出力と、第２のネットワークプロトコル処理手段への出力とに順次切り替えるような制御を行うことを特徴とする請求項１記載の映像データ送信装置。
5. 前記第１のネットワークプロトコル処理手段の処理の進行状況に応じて、第１のネットワークプロトコル処理手段へ振り分けられる圧縮符号化データのビットレートのみを小さくする第１のエンコード条件変更手段と、
   第１のネットワークプロトコル処理手段および第２のネットワークプロトコル処理手段の双方に振り分けられる圧縮符号化データのビットレートを小さくする第２のエンコード条件変更手段とを備えることを特徴とする請求項１記載の映像データ送信装置。
6. ビットレートの変更は、圧縮符号化データの映像フレームレートの変更、または、圧縮符号化における量子化条件の変更により行われることを特徴とする請求項５記載の映像データ送信装置。
7. 複数の形式に圧縮符号化された映像ストリームデータをネットワークに接続された複数の端末に同時に送信するような映像データ送信方法において、
   非圧縮映像データに対して複数の形式の圧縮符号化データを生成するステップと、
   プロセッサによるソフトウェアで実行されるステップと、
   画像データのリアルタイム送信処理を実行するステップと、
   該エンコーダで生成された複数の圧縮符号化データのうち第１のネットワークプロトコル処理ステップによって処理を行うデータと第２のネットワークプロトコル処理ステップによって処理を行うデータを選択的に振り分けるステップとを備えることを特徴とする映像データ送信方法。
8. 請求項７記載の映像データ送信方法をコンピュータに実行させるためのプログラム。

Images