(57)【特許請求の範囲】
【請求項１】
送信側クライアント装置からキャッシュ型プロキシ経由で所定の単位のデータ量毎に符号化データを受信し、受信した符号化データを受信側クライアント装置に送信する映像通信装置であって、
前記送信側クライアント装置から送信され、前記キャッシュ型プロキシを経由して受信した符号化データを一時的に蓄積するバッファ手段と、
前記バッファ手段に蓄積された前記所定の単位分の符号化データからイントラフレームに対する符号化データを検索する検索手段と、
前記バッファ手段に蓄積されている所定の単位分の符号化データの次に送信された所定の単位分の符号化データを受信後に、前記検索手段により検索された前記イントラフレームに対する符号化データから前記受信側クライアント装置への符号化データ送信を開始する送信制御手段と
を備えたことを特徴とする映像通信装置。
【請求項２】
前記送信制御手段は、前記バッファ手段に蓄積されている所定の単位分の符号化データの先頭がイントラフレームに対する符号化データである場合に、前記次の所定の単位分の符号化データの受信を待たずに前記先頭の符号化データから前記受信側クライアント装置への符号化データ送信を開始することを特徴とする請求項１に記載の映像通信装置。
【請求項３】
前記検索手段は、前記バッファ手段に蓄積された所定の単位分の符号化データ内に複数のイントラフレームが存在する場合に、最新のイントラフレームを選択することを特徴とする請求項１に記載の映像通信装置。
【請求項４】
送信側クライアント装置からキャッシュ型プロキシ経由で所定の単位のデータ量毎に符号化データを受信し、受信した符号化データを受信側クライアント装置に送信する映像通信装置としてコンピュータを機能させるためのプログラムであって、コンピュータを、
前記送信側クライアント装置から送信され、前記キャッシュ型プロキシを経由して受信した符号化データを一時的に蓄積するバッファ手段、
前記バッファ手段に蓄積された前記所定の単位分の符号化データからイントラフレームに対する符号化データを検索する検索手段、
前記バッファ手段に蓄積されている所定の単位分の符号化データの次に送信された所定の単位分の符号化データを受信後に、前記検索手段により検索された前記イントラフレームに対する符号化データから前記受信側クライアント装置への符号化データ送信を開始する送信制御手段、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、送信側クライアント装置からｐｏｓｔキャッシュ型プロキシ経由で送信された映像データを受信側クライアント装置が小さい遅延で安定して受信するための技術に関するものである。
【背景技術】
【０００２】
社内ＬＡＮからインターネットへ接続する場合、セキュリティ対策のために通過させるプロトコルの制限等を行うプロキシが設置される場合が多い。例えば、HTTP（ポート番号８０）やHTTPS（ポート番号４４３）等は通過させるが、telnetやFTPは通過させないこととする場合が多い。この通過不可能なポート番号のパケットを通過させるために、例えばHTTPパケットで通過させたいポート番号のパケットを包み込むトンネリング技術が使用されている（非特許文献１参照）。また、トンネリング技術を用いて社内ＬＡＮとインターネット間でテレビ会議を行うシステムとして、MeetingPlaza（非特許文献２参照）やWebEX（非特許文献３参照）が存在する。
【０００３】
一方、セキュリティ対策のために用いられるプロキシの中には、社内ＬＡＮからインターネット向けに送信されたデータをキャッシュしそのデータの内容をチェックすることにより通過の可否を判定するものがある（非特許文献４参照）。
【０００４】
しかしながら、プロキシにより送信データがキャッシュされてしまうと、プロキシからインターネット上のクライアント装置までの通信が離散的になり、連続して映像データを受信できなくなるため、映像のフリーズや乱れ、揺らぎが生じるという問題がある。
【非特許文献１】「通信担当者のためのＶｏＩＰ−Ｑ＆Ａで学ぶ基礎」、藤原信一郎著、（株）リックテレコム、２００１年
【非特許文献２】MeetingPlaza、[online]、[平成１７年１１月１６日検索]、インターネット URL: http://www.meetingplaza.com
【非特許文献３】WebEX、 [online]、[平成１７年１１月１６日検索]、インターネット URL:http://www.webex.com
【非特許文献４】NetApp、[online]、[平成１７年１１月１６日検索]、インターネット URL:http://www-jp.netapp.com
【発明の開示】
【発明が解決しようとする課題】
【０００５】
本発明は上記の点に鑑みてなされたものであり、送信側クライアント装置から送信される映像の符号化データがプロキシにおいてキャッシュされる場合でも、受信側のクライアント装置において少ない遅延で安定した映像の受信を可能とする技術を提供することを目的とする。
【課題を解決するための手段】
【０００６】
上記の課題は、送信側クライアント装置からキャッシュ型プロキシ経由で所定の単位のデータ量毎に符号化データを受信し、受信した符号化データを受信側クライアント装置に送信する映像通信装置であって、前記送信側クライアント装置から送信され、前記キャッシュ型プロキシを経由して受信した符号化データを一時的に蓄積するバッファ手段と、前記バッファ手段に蓄積された前記所定の単位分の符号化データからイントラフレームに対する符号化データを検索する検索手段と、前記バッファ手段に蓄積されている所定の単位分の符号化データの次に送信された所定の単位分の符号化データを受信後に、前記検索手段により検索された前記イントラフレームに対する符号化データから前記受信側クライアント装置への符号化データ送信を開始する送信制御手段とを備えたことを特徴とする映像通信装置により解決される。
【０００７】
前記送信制御手段は、前記バッファ手段に蓄積されている所定の単位分の符号化データの先頭がイントラフレームに対する符号化データである場合に、前記次の所定の単位分の符号化データの受信を待たずに前記先頭の符号化データから前記受信側クライアント装置への符号化データ送信を開始する。
【０００８】
前記検索手段は、前記バッファ手段に蓄積された所定の単位分の符号化データ内に複数のイントラフレームが存在する場合に、最新のイントラフレームを選択するようにしてもよい。  
また、本発明は、映像の符号化データを送受信する複数のクライアント装置と符号化データの中継を行う映像通信装置とを備え、少なくとも１つのクライアント装置がキャッシュ型プロキシ経由で前記映像通信装置と接続された映像通信システムにおいて用いられるクライアント装置であって、キャッシュ型プロキシ経由接続の有無及び当該キャッシュ型プロキシ経由時の所定の単位の送信データ量を前記映像通信装置に通知する通知手段と、カメラから映像を取得する映像取得手段と、取得した映像の符号化データを生成する符号化手段と、前記キャッシュ型プロキシ経由の場合に、前記符号化手段で生成される符号化データを、前記所定の単位のデータ量毎に分割して送信する分割送信手段と、前記映像通信装置から受信した符号化データを復号する復号化手段と、受信した符号化データ内のタイムコードと実時間とを同期させてフレームを表示する表示制御手段とを備えたことを特徴とするクライアント装置として構成することもできる。
【０００９】
前記表示制御手段は、前記映像通信装置から最初に受信したイントラフレームのタイムコードを基準とし、それ以降のフレームの相対時間を前記最初のイントラフレームの復号終了時間に加算して得た時間に従ってフレームの表示を行うように構成することができる。
【００１０】
また、本発明は、コンピュータを上記映像通信装置の各手段として機能させるためのプログラム、及び、コンピュータを上記クライアント装置の各手段として機能させるためのプログラムとして構成することができる。
【発明の効果】
【００１１】
本発明によれば、クライアント装置が所定の単位で符号化データを分割して送信し、映像通信サーバが符号化データのバッファリング処理を行うとともに、最新のＩフレームから送信開始を行うこととしたので、キャッシュ型プロキシを経由し、符号化データが離散的に送受信される場合でも、符号化データを受信したクライアント装置は低遅延でかつ安定した映像表示を行うことができるようになる。
【発明を実施するための最良の形態】
【００１２】
以下、図面を参照して本発明の実施の形態について説明する。
【００１３】
（システム構成）
図１に本発明の実施の形態におけるシステム構成図を示す。図１に示すように、本実施の形態のシステムは、映像通信サーバに複数のクライアント装置がインターネットを介して接続された構成をとる。クライアント装置Ａは社内ＬＡＮを経由してインターネットに接続されており、社内ＬＡＮとインターネットとの間にはpostキャッシュ型プロキシが設置されている。
【００１４】
本実施の形態で使用するpostキャッシュ型プロキシは、HTTP（ポート番号８０）のみを通過させ、postで送信された１セッション（1回のリクエストとレスポンス）分のデータをキャッシュし、クライアント装置Ａとpostキャッシュ型プロキシ間のHTTPのセッション切断後にキャッシュしたデータを送出する機能を有している。なお、キャッシュは社内ＬＡＮからインターネットに向けたデータ送信の際に行われる。
【００１５】
また、各クライアント装置にはカメラ及び表示装置が接続されており、カメラで撮影された映像はクライアント装置に取り込まれ、予め設定されたビットレートで符号化される。クライアント装置に接続されたカメラは、例えば、USB接続カメラやキャプチャボードを介して接続されたNTSCのTVカメラ等である。また、表示装置には復号化された映像が表示される。
【００１６】
図２に、図１のシステムで使用されるクライアント装置の機能構成図を示す。図２に示すように、クライアント装置は、カメラインタフェース部１１、表示装置インタフェース部１２、ネットワーク通信部１３、符号化部１４、分割送信部１５、通知部１６、復号化部１７、及び表示制御部１８を備えている。
【００１７】
カメラインタフェース部１１はカメラとクライアント装置とを接続するためのインタフェース部である。表示装置インタフェース部１２は表示装置とクライアント装置とを接続するためのインタフェース部である。ネットワーク通信部１３はクライアント装置がインターネット等のネットワークを介してデータ通信を行うための機能部である。符号化部１４はカメラから取得した映像を符号化するための機能部である。分割送信部１５は、postキャッシュ型プロキシ経由での送信を行う場合に、連続的に符号化される符号化データをあるまとまった単位に分割しながら送信するための機能部である。通知部１６はpostキャッシュ型プロキシ経由の有無や１単位あたりの送信データ量等を映像通信サーバに通知するための機能部である。復号化部１７はネットワークを介して受信した映像の符号化データを復号するための機能部である。なお、ここでの符号化方式としては、例えば、MotionJPEGやMPEG４、H.263等を使用する。表示制御部１８は受信した符号化データ内のタイムコードと実時間とを同期させてフレームを表示するための機能部である。
【００１８】
クライアント装置は、ＣＰＵ、記憶装置等を備えたコンピュータに符号化部１４、復号化部１５、分割送信部１７、表示制御部１８等の処理を実行させるためのプログラムを搭載することにより実現可能である。
【００１９】
図３に映像通信サーバの機能構成図を示す。図３に示すように、映像通信サーバは、ネットワーク通信部２１、送信制御部２２、バッファ部２３、及び受信要求処理部２４を備えている。ネットワーク通信部２１はインターネット等のネットワークを介してデータ通信を行うための機能部である。バッファ部２３はクライアント装置から受信した所定の単位の符号化データを一時的に蓄積するための機能部であり、クライアント装置毎にバッファが設けられる。送信制御部２２はバッファに格納された１セッションあたりの符号化データにおけるＩフレーム（イントラフレーム）を検索する機能、受信側のクライアント装置からの要求に基づき、適切なタイミングでバッファに格納された符号化データを送信する機能等を備えている。受信要求処理部２４は受信側クライアント装置からの符号化データ受信要求に基づき、送信制御部２２に送信指示を行う機能部である。
【００２０】
映像通信サーバは、ＣＰＵ、記憶装置等を備えたコンピュータに送信制御部２２等の処理を実行させるためのプログラムを搭載することにより実現可能である。
【００２１】
（処理の流れ）
以下、図１に示したシステムにおいて、クライアント装置Ａからクライアント装置Ｂに符号化データを配信する場合における処理の流れを図４のフローチャートに沿って説明する。
【００２２】
まず、クライアント装置Ａは、自分と映像通信サーバとの間におけるpostキャッシュ型プロキシの有無とHTTPの１セッションあたりのデータ送信量とを映像通信サーバに通知する（ステップ１）。クライアント装置Ａと映像通信サーバ間にはpostキャッシュ型プロキシが存在するので、クライアント装置Ａはpostキャッシュ型プロキシ有の情報を送信する。また、１セッションあたりの送信量は、連続して符号化される符号化データを分割してある単位で送る場合のその単位となる符号化データのデータ量である。具体的にはこの量はHTTPプロトコルヘッダ内のcontent-lengthを意味する。このデータ量は、受信側のクライアント装置において遅延をできるだけ小さくし、なおかつ、postキャッシュ型プロキシに負荷を与えないという観点で決定される。このデータ量が大きいと、postキャッシュ型プロキシでのデータ待ち時間が長くなり、遅延が大きくなる。一方、このデータ量が小さすぎると、postキャッシュ型プロキシに対して短時間にセッションの接続・切断を繰り返すことになり、postキャッシュ型プロキシに負荷をかけることとなり、場合によっては攻撃と見なされて接続を拒否される。
【００２３】
次に、クライアント装置ＡはカメラＡで撮影された映像の取得を行い（ステップ２）、カメラ映像の符号化処理を行う（ステップ３）。ここでの符号化データはＧＯＰ＝６であり、その構成はＩＰＰ（Ｉ＝イントラフレーム、Ｐ＝順方向差分フレーム）であるものとする。
【００２４】
続いて、クライアント装置Ａは映像の符号化データを映像通信サーバに送信する処理を行う（ステップ４）。ここでは、クライアント装置Ａは、符号化データを映像の送受信で使用されるRTPをHTTPでカプセリングすることによりpostキャッシュ型プロキシを通過できるプロトコルに変換して送信を行う。
【００２５】
また、クライアント装置Ａと映像通信サーバ間にはpostキャッシュ型プロキシが存在するので、クライアント装置Ａはステップ１で通知したデータ量毎に符号化データを分割し、分割された単位で符号化データを順次送信する。例えば、５つのフレーム分の符号化データのデータ量を単位として分割して送信する場合には、符号化データを連続的に送るのではなく、５つのフレーム分の符号化データが生成された後に５つのフレーム分の符号化データをまとめて送信する。  
連続して生成される符号化データをそのままpostキャッシュ型プロキシに送信した場合には、postキャッシュ型プロキシはデータが切れるまでキャッシュしてしまい、その後に映像通信サーバへの送信が行われることとなって、遅延が大きくなり、データの途切れも大きくなる。
【００２６】
一方、本実施の形態のようにセッション毎に符号化データを適切な大きさに分割して送信することにより、postキャッシュ型プロキシは分割された単位の符号化データ毎にキャッシュ及び送出を行うので、データキャッシュ待ちにより生じる遅延を小さくでき、データの途切れも小さくすることができる。
【００２７】
postキャッシュ型プロキシから送出された符号化データを受信した映像通信サーバは、当該符号化データをクライアント装置Ａ用のバッファに蓄積する（ステップ５）。バッファの大きさはステップ１でクライアント装置Ａから通知されたデータ量に基づき決定することができる。なお、本実施の形態の映像通信サーバをリアルタイム性が重要なテレビ会議システムに適用する場合には、映像送受信時の遅延をできるだけ抑制する必要があるため、バッファ内での滞在時間が予め設定した遅延許容時間を過ぎた符号化データは順に削除することとする。
【００２８】
続いて、映像通信サーバはバッファに蓄積された符号化データからＩフレーム（イントラフレーム）を検索する（ステップ６）。この処理を図５を用いて説明する。図５（ａ）、（ｂ）はバッファに蓄積された１セッション分の符号化データの例を示している。図５（ａ）、（ｂ）における横軸は時間を示し、縦軸はバッファの深さ及びバッファ量を示している。各図においてバッファが浅いほど最新の符号化データであることを意味している。
【００２９】
クライアント装置Ａから分割されて送信された１セッション分の符号化データは、postキャッシュ型プロキシを経由して離散的に映像通信サーバに届き、バッファに蓄積される。映像通信サーバは符号化データがバッファに蓄積されたタイミングでIフレームを検索する。図５（ａ）に示す場合においてはバッファ内にＩフレームが１つだけ存在するので、映像通信サーバはそのＩフレームを選択する。図５（ｂ）の場合にはバッファ内のＩフレームが２つ存在するが、映像通信サーバは最新（バッファが最も浅い）Ｉフレームを選択する。バッファへの蓄積及びＩフレームの選択は送信開始まで符号化データを受信する度に行われる。
【００３０】
次に、図４のステップ７において、クライアント装置Ｂは映像通信サーバに対してクライアント装置Ａの符号化データ送信を要求する。要求には受信したいクライアント装置（ここではクライアント装置Ａ）やフレームの種類（例えばＩフレームのみ）等の事項を含み、映像通信サーバはこの要求事項に基づき送信を開始することになる。
【００３１】
映像通信サーバは、符号化データ送信元のクライアント装置Ａから通知されている情報に基づき、クライアント装置Ａはpostキャッシュ型プロキシを経由して符号化データを送信していると認識しているので、次のような送信処理を行う（図４のステップ８）。図６を用いてこの場合の送信処理について説明する。
【００３２】
図６（ａ）、（ｂ）は、クライアント端末Ａから送信されて蓄積された符号化データがクライアント装置Bへ送信されるタイミングの一例を示した図であり、図５と同様に、横軸は時間を示し、縦軸はバッファの深さ及びバッファ量を示し、バッファが浅いほど最新のデータであることを意味する。
【００３３】
図６（ａ）は送信開始決定の時点での１セッション分の符号化データの中にＩフレームが１つ含まれる場合を示し、図６（ｂ）はＩフレームが２つ含まれる場合を示している。どちらの場合にも、送信開始決定時点の１セッション分の符号化データの中での最新のＩフレームから送信を開始するが、次の１セッション分の符号化データがサーバに蓄積された後に送信を開始する。つまり、送信開始対象の１セッション分の符号化データが蓄積された後、次の１セッション分の符号化データが蓄積されるまで待ち、次の１セッション分の符号化データが蓄積された後に、送信開始対象の１セッション分の符号化データの中の最新のＩフレームから順にデータ送信を行う。図６（ａ）の場合であれば、ＩＰＰＩＰＰＩＰのようにフレームを順次送信する。その後は１セッション分の符号化データの蓄積に応じて順次符号化データ送信を行う。
【００３４】
最初に次の１セッション分の蓄積を待たないで、Ｉフレームが発見されたタイミングで当該Ｉフレームから送信を開始してしまうと、受信側クライアント装置での復号化処理が次の符号化データが届く前に終了してしまうため、映像のフリーズや乱れが生じる。一方、送信開始にあたって次の１セッション分の符号化データの蓄積を待てば、連続的に符号化データを送信できるので上記の問題は解消できる。
【００３５】
また、図６（ｂ）の場合において、もし送信開始対象のＩフレームより古いＩフレームから送信を開始してしまうと、受信側でその分遅延が大きくなる。よって、Ｉフレームが複数ある場合には最新のＩフレームから送信することとしている。
【００３６】
ただし、図７に示すように、送信開始決定の時点で、１セッション分の符号化データの中でバッファの最も深い部分にあるフレームがＩフレームである場合には、それが送信開始フレームとなり、次のセッション分の符号化データの蓄積を待たずに符号化データの送信を行う。この場合には、受信側で最初の１セッション分の符号化データから５フレーム分の復号化処理を行うことになり、次の符号化データが届く前に復号化処理が終了してしまう可能性が低いからである。
【００３７】
次に、図４のステップ９において、クライアント装置Ｂは符号化データの受信及び復号化処理を行う。クライアント装置Ｂは映像送信側でのエンコーダ（符号化部）に対応したデコーダ（復号化部）を用いることにより符号化データの復号を行う。クライアント装置Ａから送信されpostキャッシュ型プロキシを経由した符号化データは離散的にクライアント装置Ｂに到着するが、そのまま復号化処理を行ってよい。これは、セッション毎の符号化データ間の途切れ間隔が小さく、１セッション分の符号化データの復号化処理が終わる前に次のセッション分の符号化データが届くからである。
【００３８】
次に、図４のステップ１０において、クライアント装置Ｂは符号化データ内のタイムスタンプに基づく表示処理を行う。ここで、クライアント装置Ａから送信されpostキャッシュ型プロキシを経由し、離散的に到達する符号化データについては、復号化処理で出力されるタイミングも完全に連続ではなく離散的になる。従って、そのまま表示してしまうと映像の再生速度が一定にならず、フリーズしたり早送りのように見える可能性がある。そこで、このように符号化データに含まれるタイムスタンプに基づいて表示を行う。
【００３９】
より具体的には、符号化データにはエンコード開始からの相対時間（タイムコード）が含まれているので、クライアント装置Ｂで受信した最初のＩフレームのタイムコードを基準とし、それ以降のフレームの相対時間を最初のＩフレームの復号終了時間に加算した時間に従って各フレームの表示を行う。これにより、エンコード時のフレーム間隔と一致させて各フレームを表示することが可能となる。
【００４０】
次に、図１のシステムにおいて、クライアント装置Ｂからクライアント装置Ａに向けての映像通信について説明する。この場合でも基本的な処理の流れは図４のフローの通りである。以下、クライアント装置Ａからクライアント装置Ｂに向けての映像通信と異なる点を主に説明する。
【００４１】
クライアント装置Ｂと映像通信サーバ間にはpostキャッシュ型プロキシが存在しないため、ステップ１において映像通信サーバはそのことを認識する。また、ステップ４においてクライアント装置Ｂは生成した符号化データを連続的に映像通信サーバに送出する。
【００４２】
ステップ６では、図８に示すようなＩフレーム選択処理が行われる。クライアント装置Ｂから受信した符号化データに関しては連続的にバッファ内に蓄積されるため、映像通信サーバは予め決められたポーリング間隔でＩフレームを検索する。図８に示す例ではポーリング時刻においてバッファ内に１つのＩフレームがあるのでそのＩフレームを選択する。バッファ内に複数のＩフレームがあれば最新のＩフレームを選択する。
【００４３】
そして、ステップ８の符号化データ送信処理においては、図９に示すように、選択された最新のＩフレームから符号化データが連続的にクライアント装置Ａに送信される。クライアント装置Ａでは連続的に受信する符号化データを復号し、表示を行う。この場合にもタイムコードに基づく表示処理を行ってもよい。
【００４４】
クライアント装置Ａからクライアント装置Ｂへの通信とクライアント装置Ｂからクライアント装置Ａへの通信を別々に説明したが、これらの通信は同時に行うことが可能である。
【００４５】
以上説明したように、本実施の形態で説明した技術を用いることにより、postキャッシュ型プロキシを経由し、符号化データが離散的に送受信される場合でも、符号化データを受信したクライアント装置は安定して映像表示を行うことができるようになる。特に、映像通信サーバにおいて最新のＩフレームからの送信開始を行うとともに、プロキシ情報に基づくバッファリング処理を行うので、低遅延の映像通信が可能となる。
【００４６】
なお、本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。
【図面の簡単な説明】
【００４７】
【図１】本発明の実施の形態におけるシステム構成図である。
【図２】クライアント装置の機能構成図である。
【図３】映像通信サーバの機能構成図である。
【図４】本発明の実施の形態におけるシステムの動作を示すフローチャートである。
【図５】バッファに蓄積された符号化データからＩフレームを選択する処理を説明するための図である。
【図６】映像通信サーバにおける符号化データの送信処理を説明するための図である。
【図７】映像通信サーバにおける符号化データの送信処理を説明するための図である。
【図８】バッファに蓄積された符号化データからＩフレームを選択する処理を説明するための図である。
【図９】映像通信サーバにおける符号化データの送信処理を説明するための図である。
【符号の説明】
【００４８】
１１  カメラインタフェース部
１２  表示装置インタフェース部
１３  ネットワーク通信部
１４  符号化部
１５  分割送信部
１６  通知部
１７  復号化部
１８  表示制御部１８
２１  ネットワーク通信部
２２  送信制御部
２３  バッファ部
２４  受信要求処理部
【図１】
0004648164.tif 000002
【図２】
0004648164.tif 000003
【図３】
0004648164.tif 000004
【図４】
0004648164.tif 000005
【図５】
0004648164.tif 000006
【図６】
0004648164.tif 000007
【図７】
0004648164.tif 000008
【図８】
0004648164.tif 000009
【図９】
0004648164.tif 000010