JPWO2010024102A1 - 動画像データの配信方法 - Google Patents

Abstract

この発明は、時間経過とともに変化する処理負荷の偏在状況や接続されるネットワークの帯域状況に影響されることなく、各情報端末の処理負荷増大を抑制する動画像データの配信方法に関する。送信側情報端末(120,130)から受信側情報端末(110)への動画像データの配信動作において、受信側情報端末(110)は、一定時間間隔で動画像データの送信要求を送信側情報端末(120,130)に対し繰り返す際、受信制限情報として、自己の画像フレーム受信可能量、及び、自己の付加許容量のうち少なくとも何れか一方のデータ量を予め計算した後、該データ量、及び、該データ量の算出根拠となるデータ構造要素のうち少なくとも何れか一方の上限値を送信側情報端末(120,130)に逐次通知する。

Description

この発明は、ネットワークを介して互いに接続された複数の情報端末により構成されるテレビ会議システムなどの双方向データ通信システムに適用され、各情報端末間において送受信されるビジュアル情報に含まれる動画像データの配信方法に関するものである。

データ通信回線における通信速度は、近年、飛躍的に速くなってきており、個人所有のパーソナルコンピュータ（以下、ＰＣという）などの情報端末間においても、日常的に、動画像データ、音声データ等を含む大容量のビジュアル情報の送受信が行われるようになってきた。特に、このような通信環境では、リアルタイムでの双方向データ通信を実現するシステムが簡単に構築され得る。図１の領域（ａ）は、テレビ会議システムなど、ネットワーク回線及びＰＣ等の情報端末など、既存のネットワーク・リソースを利用して構築され得る双方向データ通信システムの構成を示す図である。この双方向データ通信システムは、ネットワーク１００と、該ネットワーク１００に個々に接続された複数の情報端末（端末Ａ１１０、端末Ｂ１２０、及び端末Ｃ１３０）により構成される。また、システムの一部を構成する端末Ａ１１０と端末Ｂ１２０間では、ネットワーク１００を介して動画像データなどのビジュアル情報の送受信１００ａ（送信要求とデータ配信が含まれる）が行われる。同様に、端末Ａ１１０と端末Ｃ１３０間でも、ネットワーク１００を介して動画像データなどのビジュアル情報の送受信１００ｂが行われる。端末Ｂ１２０と端末Ｃ１３０間では、ネットワーク１００を介して動画像データなどのビジュアル情報の送受信１００ｃ（送信要求とデータ配信が含まれる）が行われる。なお、端末Ａ１１０は制御部１１０ａ（ＰＣにおけるＣＰＵに相当）を備え、端末Ｂ１２０は制御部１２０ａを備え、端末Ｃ１３０は制御部１３０ａを備えており、実際の通信制御、各種ディジタル処理は、これら制御部１１０ａ〜１３０ａにおいて行われる。

しかしながら、現状において膨大な動画像データを限られたネットワーク・リソースを利用して配信する場合、各情報端末の処理能力、ネットワークの回線速度などの制限から、データ量自体を少なくする必要がある。そのため、配信される動画像データや音声データを圧縮する技術が盛んに研究され、また、実用化されてきている。例えば、特許文献１には、操作者や各情報端末に多大な負担をかけることなく、受信側クライアントの端末種別等の通信環境に適した画像データ送受信を可能にするための画像通信技術が開示されている。一方、特許文献２には、解像度方向に対する情報更新性を実現する方式として、スケーラビリティを利用した符号化装置、その方法、プログラムなどが開示されている。

また、特許文献３には、サーバと受信側クライアント間の個々の通信環境に応じたデータ通信を可能にする技術が開示されている。すなわち、サーバから送信される画像データの品質に対してサーバと受信側クライアント間の回線速度が低い場合、該受信側クライアントからの要求に応じた品質の画像データが、サーバが受信側クライアントへ送信される。

特開２００６−１７４０４５号公報 特開２００５−０９４０５４号公報 特公平１１−１６１５７１号公報

発明者らは、従来の動画像データの配信方法について詳細に検討した結果、以下のような課題を発見した。

すなわち、複数の情報端末間においてビジュアル情報の送受信を行う従来の双方向データ通信システムは、ブロードバンドを活用したＰＣシステムに置き換わりつつある。ただし、動画像データや音声データの配信時に利用されるブロードバンドの使用料が比較的安価なため、配信されるデータ量の制御等は考慮されていない実態がある。これは、一見高速化するブロードバンド環境においてなんら問題がないと思われる。しかしながら、各情報端末のデータ処理性能が均一ではないため、異なる性能の情報端末間における双方向データ通信に障害が発生しやすくなっている現状は見逃すことができない。例えば、処理速度の速いＰＣから動画像データが処理速度の遅いＰＣへ配信された場合、該処理速度の遅いＰＣでは、受信データの処理が追いつかなくなってしまう。

また、近年実用化されてきたＨ．２６４（ＭＰＥＧ−４ ＡＶＣ、以下、これら次世代画像圧縮技術を含め単にＭＰＥＧ方式という）などの動画配信技術では、送信側情報端末において一定時間におけるフレーム数を変更することが可能だが、受信側情報端末の要求に応じて処理可能時にフレームを送信すると、フレーム数を変更して送信するまでの遅延が発生するなど、リアルタイム処理ができない。

より具体的には、図１の領域（ａ）に示されたような個人所有のＰＣ等の情報端末１１０〜１３０を既存のネットワーク１００に接続することにより、容易に複数人による双方向データ通信システムが構築できる通信環境下では、単にネットワーク・リソースのみの負荷管理だけではストレスフリーなネットワーク・コミュニケーションができないことは経験的にも明らかである。

この大きな原因としては、各情報端末においてバックラウンドの処理が双方向データ通信とは別に行われていることに起因している。換言すれば、図１の領域（ｂ）に示されたように、ネットワーク１００を介して互いに接続された端末Ａ１１０〜端末Ｃ１３０それぞれにおける処理負荷（ＣＰＵ稼働率）が、時間経過とともに刻々と変化するためである。例えば、図１の領域（ｂ）において、時刻Ｔ１では、端末Ａ１１０の処理負荷は低下傾向にあり、ある程度のデータ送受信処理に対する負荷が許容でき、端末Ｂ１２０にいたっては十分な処理負荷が許容できる。一方、時刻Ｔ１における端末Ｃ１３０の処理負荷は非常に高く、新たにデータ送受信処理の負荷を許容することはできない状態となっている。また、時刻Ｔ２では、端末Ａ１１０における処理負荷は高いが、端末Ｂ１２０、端末Ｃ１３０における処理負荷は低く、端末Ａ１１０の処理能力低下が、端末Ａ１１０、端末Ｂ１２０、端末Ｃ１３０間の双方向データ通信におけるボトルネックとなることは明白である。さらに、時刻Ｔ３では、端末Ａ１１０における処理負荷は低いが、端末Ｂ１２０、端末Ｃ１３０における処理負荷が高くなっている。この場合、端末Ｂ１２０及び端末Ｃ１３０それぞれの処理能力低下が、端末Ａ１１０、端末Ｂ１２０、端末Ｃ１３０間の双方向データ通信におけるボトルネックとなる。

上述のように、ネットワークを介して互いに接続された端末Ａ１１０、端末Ｂ１２０、端末Ｃ１３０それぞれにおける負荷状態を無視して一定量のビジュアル情報の双方向データ通信が行われると、ボトルネックとなる情報端末ではＰＣの処理能力をオーバーしてしまい、モニタに表示される映像やスピーカから出力される音声の乱れ等が発生してしまう。すなわち、受信側端末における画像データや音声データの処理状況を無視して送信側端末がデータ送信を続けるため、受信側情報端末の映像再生処理が遅れてしまう。逆に、送信側情報端末の処理負荷が大きくなる場合も受信側情報端末の映像再生処理が遅れてしまう。例えば、上記特許文献３におけるサーバの配信対象となる情報端末の数は時間経過とともに刻々と変化する。したがって、処理ピーク（複数の情報端末からの送信要求があった場合）では、サーバの処理能力の限界を超えてしまい、該サーバからの画像データの送信遅れに伴って受信側情報端末の映像再生処理が遅れてしまう。

なお、各情報端末における処理負荷には、上述のような画像フレームの符号化、複合化、表示処理の他、ネットワークを介して受信したデータ（一旦、通信用バッファに格納される）をバッファから取り出す処理負荷も含まれる。通常、ＰＣなどの情報端末では、ネットワークを介して受信したデータがソフトウエアにより通信用バッファに一旦格納され、該格納されたデータをアプリケーションソフトが取り出して所定の処理を行う。このとき、電気的にＰＣのネットワークカードなど、通信用Ｉ／Ｏ部に届いたパケットも、当該情報端末の処理負荷が増大するとアプリケーションソフトが取り出すまでに時間がかかる。この場合、実質的にバッファオーバーフローのような状態となるため、受信データの取りこぼしの原因となってしまう。

この発明は、上述のような課題を解決するためになされたものであり、ネットワークを介して互いに接続された複数の情報端末間における処理負荷の偏在や接続されるネットワークの帯域状況に影響されることなく、リアルタイムでの動画像配信を可能にするための構造を備えた動画像データの配信方法を提供することを目的としている。

この発明に係る動画像データの配信方法は、ネットワークを介して互いに接続された複数の情報端末により構成された、テレビ会議システムなどの双方向データ通信システムに適用される。したがって、ネットワークを介して互い接続された情報端末のそれぞれは、ネットワーク上に配信される動画像データに対して受信先にも送信元にもなり得る。

ここで、当該双方向データ通信システムで送受信されるビジュアル情報は、動画像データや各情報端末の操作者等の音声の他、静止画データ、テキストデータをも含む双方向対話に寄与し得る情報を含む。特に、ビジュアル情報に含まれる動画像データは、各情報端末における送受信動作において符号化（データ圧縮）及び復号化（データ伸長）が行われるため、その配信動作の効率化は各情報端末のデータ処理能力に大きく依存することになる。この発明に係る動画像データの配信方法では、受信側情報端末によりデータ配信動作を制御することを特徴としている。そのため、当該動画像データの配信方法において適用される動画像データは、時間軸方向に圧縮されることなく各画像フレームが隣接する画像フレームとは独立に圧縮／伸長され得るフレーム構造を有するか、あるいは、特定の画像フレーム群が前後の画像フレーム群とは独立に再生可能なフレーム構造（１つのフレーム群を構成する複数の画像フレーム間ではフレーム間予測による時間軸方向の圧縮が行われていても問題ない）を有する動画像データであるのが好ましい。

この発明の配信対象となり得る動画像データとしては、上述のようなフレーム構造の特徴を積極的に利用するため、主に、静止画像の圧縮方式として知られるＪＰＥＧ（又はＪＰＥＧ２０００）規格に従って各画像フレームが圧縮されるＭｏｔｉｏｎ−ＪＰＥＧ（又はＭｏｔｉｏｎ−ＪＰＥＧ２０００）方式の動画像データが好適である。すなわち、送受信される動画像データのトータルのデータ量は、データ構造要素として単に送受信される画像フレームの数のみで決定されるわけではなく、「画像フレーム数」×「画像解像度（サイズ）」×「一画素を表現するビット数」により決定される。しかしながら、トータルのデータ量の増減には、画像フレーム数、画像解像度、及び、一画素を表現するビット数のうち少なくとも何れかを制御すればよく、特に、画像フレーム数の制御が効果的である。そこで、時間軸方向に沿って圧縮されることなく個々の画像フレームについて圧縮／伸長が可能なＪＰＥＧ方式の動画像データは、任意に画像フレームを欠落させた場合であっても、残りの画像フレームの符号化には影響を及ぼすことがないため、特に有効である。

ただし、前後に隣接する画像フレーム間の差分情報を利用するなど、時間軸方向にも圧縮が可能なＭＰＥＧ方式も、この発明の配信対象となり得る動画像データに含まれる。例えば、フレーム間予測における参照フレームとして、画像フレームそれぞれが個別に符号化されるＩフレームが指定されたＭＰＥＧ方式の動画像データもこの発明の配信対象となり得る動画像データに含まれる。さらに、フレーム間予測における参照フレームとして、ＩフレームとＰフレームの組み合わせが指定されたような場合には、Ｉフレーム指定された１枚の画像フレームと、Ｐフレーム指定された２枚の画像フレームの合計３枚の画像フレームにより、１つの取り扱い単位（送受信単位）となるフレーム群と扱うことが可能であり、このようなフレーム群からなるフレーム構造の動画像データも、この発明の配信対象となり得る。なお、ＭＰＥＧ方式のフレーム間予測における参照フレームとしては、例えば、画像フレームそれぞれが個別に符号化されるＩフレーム、前後２枚の画像フレームを利用して符号化が行われるＢフレーム、前画像フレームを利用して符号化が行われるＰフレームが指定可能である。

なお、上述のようなＭｏｔｉｏｎ−ＪＰＥＧ（又はＭｏｔｉｏｎ−ＪＰＥＧ２０００）方式の動画像データは、時間軸方向には圧縮されないためにＭＰＥＧ方式の動画像データと比較して同一ビットレートでの圧縮効率は悪いが、任意の画像フレームを他の画像フレームと切り離して個別に編集することを可能にするなどの特徴を有し、個人向けのビデオキャプチャーカードなどが出力形式として採用している。

具体的に、この発明に係る動画像データの配信方法は、ネットワークを介して互いに接続された複数の情報端末間において、上述のような動画像データ（時間軸方向に沿ってそれぞれ独立に再生可能な画像フレームあるいはフレーム群からなるフレーム構造を有する動画像データ）の送受信を行う。例えば、この発明に係る動画像データの配信方法では、複数の情報端末間における双方向データ通信の一態様として、送信側情報端末から受信側情報端末への動画像データの配信動作において、受信側情報端末及び送信側情報端末は、互いの処理可能なデータ量に応じて、送信要求及び画像フレームの配信を行う。

すなわち、受信側情報端末は、所定の時間間隔、例えば一定時間間隔で動画像データの送信要求を送信元となる送信側情報端末に対し繰り返す際、送信要求を行う時点における受信可能データ量を計算する。その後、受信側情報端末は、受信制限情報として、計算されたデータ量、及び、該データ量の算出根拠となるデータ構造要素のうち少なくとも何れか一方の上限値を、送信側情報端末に逐次通知する。一方、送信要求を受けた送信側情報端末は、受信した受信制限情報の指示に従って、送信要求を受けた時点における自己の負荷許容範囲内に収まるデータ量、及び、受信側情報端末から要求されたデータ量のうち少なくとも一方、好ましくは少ない方に合わせてそのデータ量が制限された動画像データを、送信要求を通知してきた受信側情報端末に送信する。

特に、受信側情報端末において算出される受信可能データ量は、ネットワークの帯域制限に起因する画像フレーム受信可能量、及び、自己の画像フレーム表示処理の負荷許容量のうち少なくとも何れか一方のデータ量であるのが好ましい。より好ましくは、受信可能データ量は、上記画像フレーム受信可能量、及び、上記負荷許容量のうち少ない方のデータ量である。このように、ネットワークの帯域制限と情報端末の処理能力のいずれか少ない方を選択可能にすることにより、当該受信側情報端末の負荷対策だけでなく、ネットワーク負荷の状態に対しても当該発明が有効に機能し得るからである。

また、動画像データの配信に先立ち、受信側情報端末から送信側情報端末へ送信される受信制限情報には、上述のように、ネットワークの帯域制限、及び、自己の画像フレーム表示処理の負荷許容のうち少なくとも何れか一方を考慮して計算されたデータ量の上限値、及び、該データ量の算出根拠となったフレーム構成要素の上限値のうち少なくとも何れか一方が含まれる。なお、フレーム構造要素には、画像フレームに関する送受信単位の単位時間当たりの数、画像解像度、及び一画素当たりのビット数の少なくともいずれかが含まれる。

このように動画像データの配信動作において受信側情報端末及び送信側情報端末双方の処理負荷が考慮された配信対象である動画像データの送受信データ量（画像フレーム数等の増減により制御される）が動的に決定されるため、ネットワークを介して互いに接続された複数の情報端末（各情報端末は、受信側及び送信側情報端末のいずれにもなり得る）のそれぞれにおける処理負荷の低減につながる。しかしながら、送受信データ量を画像フレーム数の増減で制御する場合、受信側及び送信側双方の情報端末における処理負荷の許容限度内で動画像データが配信されるため、受信側情報端末において動画表示される際には途中の画像フレームが受信されない場合がある。また、送信側情報端末が任意のタイミングで画像を配信することによって途中の画像フレームが送信されない場合（送信動作をスキップ）もある。この発明に係る動画像データの配信方法は、このように受信側及び送信側双方の情報端末における処理状況に起因して発生する画像フレームの欠落を予め考慮し、受信側情報端末での映像表示が可能になるよう、Ｈ．２６４等の動画フォーマットではなく、静止画フォーマット（例えばＪＰＥＧ２０００規格等）のフレーム構造を有する動画像データが好ましい。

ところが、送信側情報端末から受信側情報端末へ任意のタイミングで画像フレームが送信される場合、単に、受信側及び送信側双方の情報端末における処理負荷の許容限度内の画像フレーム数を通知するだけでは、これら複数の情報端末間での同期は取れず、非同期の状態で個々の情報端末から動画像データが送信される可能性は否定できない。このような状況を具体的に説明するため、例えば、図２の領域（ａ）に示されたように、端末Ａ１１０が、端末Ｂ１２０、端末Ｃ１３０それぞれに対し動画像データの送信要求を行った場合を考える。このとき、端末Ａ１１０からの送信要求を受信した端末Ｂ１２０、端末Ｃ１３０それぞれが、自己のタイミングで要求された画像フレームを端末Ａ１１０へ送信していくと、受信側の端末Ａ１１０では受信タイミングを制御できない。そのため、図２の領域（ｂ）に示されたように、タイミングＴ５、Ｔ６において、端末Ａ１１０の処理負荷が著しく増加したり、ネットワークでの伝送衝突状態となる可能性がある。この場合、データ損失により表示処理を完了できない状態となってしまう。そこで、この発明に係る動画像データの配信方法では、図２の領域（ｃ）に示されたように、受信側情報端末に動画像データの配信タイミングの制御権を与えることで、一対多のデータ送受信態様における同期を確保する。

具体的には、複数の情報端末間における双方向データ通信の一態様として二以上の送信側情報端末から受信側情報端末への動画像データの配信動作において、受信側情報端末は、画像フレーム表示処理が可能な自己のタイミングで、二以上の送信側情報端末の少なくともいずれか一つに送信要求信号を送信する。一方、上記二以上の送信側情報端末では、受信側情報端末自身のタイミングで発せられた送信要求信号を受信した送信側情報端末のみが該受信側情報端末から要求されたデータ量の動画像データを受信側情報端末に送信する。このとき、自己への送信要求を受信しなかった送信側情報端末は、自己への送信要求を受信するまで動画像データの送信待機状態となる。

なお、この発明に係る動画像データの配信方法において、動画像データが時間軸方向に圧縮されることなくそれぞれが前画像フレームとは独立に再生可能な画像フレームから構成されている場合、すなわち、動画像データがＪＰＥＧ方式、あるいは、ＭＰＥＧ方式であってもフレーム間予測においてＩフレーム指定された場合には、画像フレームに関する送受信単位は、当該動画像データを構成する各画像フレームに相当する。ここで、動画像データとは、複数の画像フレームを含み、これらがあるタイミングで順次切り替わっていくデータ群を指す。したがって、配信対象となり得る動画像データには、パワーポイント等のスライドショーにおいてスライド切り替え用に準備される画像データ群も含まれる。

また、動画像データが、それぞれが複数の画像フレームを含むとともに時間軸方向から見て前に位置する画像フレームとは独立に再生可能な複数のフレーム群から構成されている場合、すなわち、ＩフレームとＰフレームの組み合わせ、又は、Ｉフレーム、Ｐフレーム及びＢフレームの組み合わせにより構成されたフレーム群（隣接する画像フレームとは独立に再生可能なフレーム群）の場合には、画像フレームに関する送受信単位は、当該動画像データを構成する各フレーム群に相当する。

さらに、この発明に係る動画像データの配信方法において、複数の情報端末それぞれは、画像フレームに関する送受信単位の数について、自己の情報端末が前記動画像データの送信元となったときの、単位時間当たりに送信可能な上限値を指示する送信制限情報を、該動画像データの送信に先立ち、予め他の情報端末に通知しておくのが好ましい。このように、送信側情報端末となり得る各情報端末において予め送信可能な画像フレーム数等の上限を設定可能にしておくことにより、受信側情報端末は、この上限以内でフレーム数を設定することとなる。そのため、負荷状況を無視して受信側情報端末に動画像データを送ることによる該受信側情報端末の処理負荷増加の回避とともに、送信側情報端末における処理負荷の低減も可能になる。さらに、受信側情報端末は映像表示すべき画像フレーム数以外に自己のデータ処理（バックグラウンドでのデータ処理）を管理しながら、送信側情報端末から送信される動画像データの処理が可能と判断したときのみに該送信側情報端末へ送信要求を行うなど、受信側及び送信側双方の情報端末が能動的に動画像データの配信動作を管理できる。

なお、この発明に係る各実施例は、以下の詳細な説明及び添付図面によりさらに十分に理解可能となる。これら実施例は単に例示のために示されるものであって、この発明を限定するものと考えるべきではない。

また、この発明のさらなる応用範囲は、以下の詳細な説明から明らかになる。しかしながら、詳細な説明及び特定の事例はこの発明の好適な実施例を示すものではあるが、例示のためにのみ示されているものであって、この発明の範囲における様々な変形および改良はこの詳細な説明から当業者には自明であることは明らかである。

この発明に係る動画像データの配信方法によれば、ネットワークを介して互いに接続された複数の情報端末間における処理負荷の偏在状況に応じて配信されるべき動画像データの画像フレーム数等の上限値を動的に調整することができる。そのため、これら複数の情報端末間における処理負荷の偏在に影響されることなく、リアルタイムでの動画像データ配信が可能になる。

また、この発明に係る動画像データの配信方法において、送受信される動画像データとしては、ＪＰＥＧ規格に従って画像フレームを圧縮／伸長されるＭｏｔｉｏｎ−ＪＰＥＧ方式の動画像データに代表されるように、時間軸方向に圧縮されることなく隣接する画像フレームとは独立に再生可能な画像フレーム、又はフレーム群から構成された動画像データが採用される。このような構成の動画像データが送受信対象として採用されることにより、動画像データを構成する画像フレーム数等の増減が頻繁に発生した場合であっても、各情報端末間におけるリアルタイムでの動画像データ配信への影響は少ない。したがって、送受信される動画像データの単位時間当たりの画像フレーム数等を各情報端末における処理負荷の増減に応じて動的に調節することにより、各情報端末間においてストレスフリーの動画像データ配信が可能になる。

は、一般的な複数情報端末間の双方向データ通信システムの構成及び各情報端末における処理負荷の時間変化を説明するための図である。 は、この発明に係る動画像データの配信方法の代表的な効果の一つを概略的に説明するための図である。 は、図１に示された双方向データ通信システムにおいて配信されるビジュアル情報に含まれる動画データの一例（例えば、ＪＰＥＧ２００規格の画像フレームで構成されたＭｏｔｉｏｎ−ＪＰＥＧ２０００のデータ構造）を説明するための図である。 は、図１に示された双方向データ通信システムにおける各情報端末間の動画像データ配信手順を説明するためのブロック図である。 は、図１に示された双方向データ通信システムにおける各情報端末間の通信制御シーケンスである。 は、この発明に係る動画像データの配信方法を、各情報端末における処理負荷の観点から説明するための図である。 は、この発明に係る動画像データの配信方法における受信側シーケンスを説明するためのフローチャートである。 は、この発明に係る動画像データの配信方法における送信側シーケンスを説明するためのフローチャートである。 は、この発明に係る動画像データの配信方法における送信側シーケンスを、ビジュアル情報、特に画像フレームの送信枚数制御（負荷制御）の観点から説明するための図である。

以下、この発明に係るビジュアル情報の配信方法の各実施形態を、図３〜図９を用いて詳細に説明する。なお、必要に応じて、各実施形態の説明において図１及び図２も参照する。また、図面の説明において同一の要素には同一符号を付して重複する説明を省略する。

この発明に係る動画像データの配信方法は、図１の領域（ａ）に示されたように、ネットワークに接続された複数の情報端末により構成された、テレビ会議システムなどの双方向データ通信システムに適用される。この双方向データ通信システムは、ネットワーク１００と、該ネットワーク１００に個々に接続された複数の情報端末を備える。なお、以下の説明では、ネットワーク１００に接続された情報端末を、それぞれ端末Ａ１１０、端末Ｂ１２０、及び端末Ｃ１３０と表す。また、このようにネットワーク１００を介して互い接続された端末Ａ１１０、端末Ｂ１２０、端末Ｃ１３０のそれぞれは、該ネットワーク１００上に配信される動画像データに対して受信先にも送信元にもなり得る。

双方向データ通信システムの一部を構成する端末Ａ１１０と端末Ｂ１２０間では、ネットワーク１００を介して動画像データなどのビジュアル情報の送受信１００ａ（送信要求とデータ配信が含まれる）が行われる。同様に、端末Ａ１１０と端末Ｃ１３０間でも、ネットワーク１００を介して動画像データなどのビジュアル情報の送受信１００ｂが行われる。端末Ｂ１２０と端末Ｃ１３０間では、ネットワーク１００を介して動画像データなどのビジュアル情報の送受信１００ｃ（送信要求とデータ配信が含まれる）が行われる。

なお、当該動画像データの配信方法において適用される動画像データは、時間軸方向に圧縮されることなく各画像フレーム又はフレーム群が、隣接する画像フレーム又はフレーム群とは独立に圧縮／伸長され得るフレーム構造を有するが、以下、簡単のため、この動画像データをＪＰＥＧ方式の動画像データに絞って各実施形態を説明することとする。

図１の領域（ａ）に示された双方向データ通信システムでは、各端末間においてビジュアル情報の送受信が行われる。ここで、送受信されるビジュアル情報は、動画像データや各情報端末の操作者等の音声の他、静止画データ、テキストデータをも含む双方向対話に寄与し得る情報を含む。特に、ビジュアル情報に含まれる動画像データは、図３に示されたように、時間軸ｔに沿った方向に圧縮されることなく該時間軸ｔに沿って配置されるとともにそれぞれが個別に圧縮／伸長される画像フレームであって、単位時間（ｓ）当たり１２枚の画像フレームｆ１〜ｆ１２から構成された動画像データＤ１である。なお、図３は、図１に示された双方向データ通信システムにおいて配信されるビジュアル情報に含まれる動画データの一例（例えば、ＪＰＥＧ２００規格の画像フレームで構成されたＭｏｔｉｏｎ−ＪＰＥＧ２０００のデータ構造）を説明するための図である。

このような動画像データＤ１は、隣接する画像フレーム間の差分情報を利用するなど、時間軸ｔの方向にも圧縮が可能であり、配信対象である動画像データＤ１としては、例えば、Ｍｏｔｉｏｎ−ＪＰＥＧ（又はＭｏｔｉｏｎ−ＪＰＥＧ２０００）方式の動画像データが含まれる。

Ｍｏｔｉｏｎ−ＪＰＥＧ（又はＭｏｔｉｏｎ−ＪＰＥＧ２０００）方式の動画像データは、ＭＰＥＧ方式の動画像データと比較して同一ビットレートでの圧縮効率は悪いが、任意の画像フレームを他の画像フレームと切り離して個別に編集することを可能にする。また、このような動画像データは、各端末におけるエンコード・デコード時の負荷が軽く、比較的簡単な設備でリアルタイムエンコードを可能にする。

次に、この発明に係る動画像データの配信方法を、図４及び図５を参照しながら詳細に説明する。なお、図４は、各端末間における動画像データＤ１の配信手順を説明するためのブロック図である。図５は、各端末間における通信シーケンスである。

以下の説明では、端末Ａ１１０を受信側情報端末（以下、単に受信側端末Ａ１１０で表す）とする一方、端末Ｂ１２０及び端末Ｃ１３０を送信側情報端末（以下、単に送信側端末Ｂ１２０、送信側端末Ｃ１３０で表す）とし、受信側端末Ａ１１０が受信タイミングを制御する。また、受信側端末Ａ１００は、一定時間間隔Ｔで動画像データの送信要求を送信元となる送信側端末Ｂ１２０又は送信側端末Ｃ１３０に対し繰り返す際、受信制限情報として、送信要求を行う時点における受信可能データ量を計算する。このような受信側端末Ａ１１０における受信可能データ量は、ネットワークの帯域制限に起因する画像フレーム受信可能量、及び、自己の画像フレーム表示処理の負荷許容量のうち、いずれか少ない方のデータ量とする。さらに、受信側端末Ａ１１０から送信側端末Ｂ１２０、Ｃ１３０へ送信される受信制限情報には、該データ量の算出根拠となるデータ構造要素として、画像フレームに関する送受信単位の単位時間当たりの数、画像解像度、及び一画素当たりのビット数の少なくともいずれかが含まれる。ただし、以下の説明では簡単のため、単位時間当たりに送信すべき画像フレーム数のみを受信制限情報とする。

この発明に係る動画像データの配信方法では、送信側端末Ｂ１２０から受信側端末Ａ１１０への動画像データの配信動作、及び、送信側端末Ｃ１３０から受信側端末Ａ１１０への動画像データの配信動作において、互いの処理可能なフレーム数に応じた送信要求及び画像フレーム配信が行われる。

具体的に、受信側端末Ａ１１０は、図５に示されたように、一定時間間隔Ｔで動画像データの送信要求を送信元となる送信側端末Ｂ１２０又は送信側端末Ｃ１３０に対し繰り返す。その際、受信制限情報として、現時点における自己の画像フレーム表示処理の負荷許容範囲内において処理可能な単位時間（ｓ）当たりのフレーム数（ネットワーク１００の帯域制限に基づいて算出してもよい）を、送信側端末Ｂ１２０又は送信側端末Ｃ１３０に逐次通知する。一方、送信要求を受けた送信側端末Ｂ１２０及び送信側端末Ｃ１３０は、送信要求を受けた時点における自己の画像フレーム送信処理の負荷許容範囲内に収まる単位時間（ｓ）当たりのフレーム数、及び、受信側情報端末から要求された単位時間（ｓ）当たりのフレーム数のうち少ない方のフレーム数の動画像データを、送信要求を通知してきた受信側端末Ａ１１０に送信する。

すなわち、図４に示されたように、受信側端末Ａ１１０は、まず、現時点における自己の画像フレーム表示処理の負荷許容範囲が１０フレーム／ｓであることを確認し、送信側端末Ｂ１２０に対し送信要求（送信フレーム数の制限通知含む）を逐次通知する。受信側端末Ａ１１０から送信要求が通知された送信側端末Ｂ１２０では、送信要求を受信した時点における自己のバックグラウンド処理を含む負荷状態を確認し、自己のフレーム送信能力を設定する。例えば、図４に示されたケースにおいて、送信側端末Ｂ１２０は、受信側端末Ａ１１０から送信要求を受けた時点における処理能力として送信制限が設定されていないため、送信要求のあった１０フレーム／ｓの動画像データを受信側端末Ａ１１０へ送信することになる。

一方、受信側端末Ａ１１０から送信側端末Ｃ１３０に対し、送信側端末Ｂ１２０と同様に、１０フレーム／ｓの送信要求（受信可能なフレーム数の制限）が通知されたケースでは、送信側端末Ｃ１３０は、送信要求を受信した時点における自己のバックグラウンド処理を含む負荷状態を確認し、自己のフレーム送信能力を設定する。例えば、図４に示されたケースにおいて、送信側端末Ｃ１３０は、受信側端末Ａ１１０から送信要求を受けた時点における処理能力として５フレーム／ｓが設定されているため、送信要求のあった１０フレーム／ｓに対して５フレーム／ｓの動画像データを受信側端末Ａ１１０へ送信することになる。

このように動画像データの配信動作において、受信側端末Ａ１１０、送信側端末Ｂ１２０、及び送信側端末Ｃ１３０それぞれの処理負荷が考慮された状態で配信対象である動画像データのフレーム数が動的に決定される。そのため、ネットワーク１００を介して互いに接続された受信側端末Ａ１１０、送信側端末Ｂ１２０、及び送信側端末Ｃ１３０のそれぞれにおける処理負荷の低減につながる。

ただし、受信側端末Ａ１１０、送信側端末Ｂ１２０、及び送信側端末Ｃ１３０のそれぞれにおける処理負荷の許容限度内で動画像データが配信されるため、受信側端末Ａ１１０において動画表示される際には途中の画像フレームが受信されない場合がある。また、送信側端末Ｂ１２０及び送信側端末Ｃ１３０が任意のタイミングで画像を配信することによって途中の画像フレームが送信されない場合もある。このような通信環境下であっても、送受信対象である動画像データＤ１は、受信側端末Ａ１１０での映像表示が可能になるよう、例えばＪＰＥＧ２０００規格など、動画フォーマットのフレーム構造を有する動画像データＤ１が採用されている。

図６は、図４及び図５を参照しながら説明した各端末の通信制御手順を処理負荷の観点から説明するための図である。特に、図６の領域（ａ）には、受信側端末Ａ１１０、送信側端末Ｂ１２０、及び送信側端末Ｃ１３０のそれぞれにおける所定時間Ｔごとの処理能力の変化を、単位時間当たりに処理可能な画像フレームのフレーム数で示されている。

図６の領域（ａ）に示されたように、受信側端末Ａ１１０の処理能力（フレーム／ｓ）は、時間ｔの経過とともに刻々と変化する。同様に、送信側端末Ｂ１２０及び送信側端末Ｃ１３０のそれぞれにおいても、処理能力（フレーム／ｓ）は、時間ｔの経過とともに刻々と変化する。なお、この図６の領域（ａ）及び（ｂ）において、受信側端末Ａ１１０における負荷算出のタイミングは、受信側端末Ａ１１０から送信側端末Ｂ１２０又は送信側端末Ｃ１３０への送信要求のタイミングと略一致している。また、送信側端末Ｂ１２０及び送信側端末Ｃ１３０のそれぞれにおける負荷算出のタイミングは、受信側端末Ａ１１０からの送信要求の受信タイミングと一致している。

図６の領域（ｂ）は、図５に示された通信制御手順に従って、受信側端末Ａ１１０が送信側端末Ｂ１２０及び送信側端末Ｃ１３０のそれぞれに対して動画像データの配信動作を各端末における処理負荷の観点から説明するための図である。この図６の領域（ｂ）に示されたように、受信側端末Ａ１１０は、所定時間ごと、例えば一定時間間隔Ｔごとの送信要求を、送信側端末Ｂ１２０及び送信側端末Ｃ１３０の双方に交互に送信している。ただし、領域Ａ１は、受信側端末Ａ１１０からの送信要求のあったフレーム数と、実際に送信要求に応答して送信側端末Ｂ１２０及び送信側端末Ｃ１３０の双方から送信されたフレーム数の差（受信側端末Ａ１１０では映像表示されなかった処理フレーム数であって、受信側端末Ａ１１０における画像フレーム表示の余力）を示している。

一方、送信側端末Ｂ１２０では、受信側端末Ａ１１０からの送信要求を受けた場合に、その間だけ自己の処理能力の許容範囲内において受信側端末Ａ１１０へのフレーム送信が行われ、他の時間帯は別の処理が行われている。フレーム送信処理に十分な処理能力が確保できる時間帯であれば、送信側端末Ｂ１２０は、受信側端末Ａ１１０の送信要求に応じたフレーム数の動画像データを配信する。ところが、受信側端末Ａ１１０から自己の処理能力を超えたフレーム数が要求された場合、送信側端末Ｂ１２０は、要求されたフレーム数以下であっても自己の処理能力の範囲内で送信可能なフレーム数の動画像データを受信側端末Ａ１１０へ送信する。領域Ｂ１は、送信側端末Ｂ１２０から受信側端末Ａ１１０へのフレーム送信において、エラー送信（送信動作をスキップ）の処理フレーム数である。

同様に、送信側端末Ｃ１３０でも、受信側端末Ａ１１０からの送信要求を受けた場合、その間だけ自己の処理能力の許容範囲内において受信側端末Ａ１１０へのフレーム送信が行われ、他の時間帯は別の処理が行われている。フレーム送信処理に十分な処理能力が確保できる時間帯であれば、送信側端末Ｃ１３０は、受信側端末Ａ１１０の送信要求に応じたフレーム数の動画像データを配信する。ところが、受信側端末Ａ１１０から自己の処理能力を超えたフレーム数が要求された場合、送信側端末Ｃ１３０は、要求されたフレーム数以下であっても自己の処理能力の範囲内で送信可能なフレーム数の動画像データを受信側端末Ａ１１０へ送信する。領域Ｃ１は、送信側端末Ｂ１２０から受信側端末Ａ１１０へのフレーム送信において、エラー送信（送信動作をスキップ）された処理フレーム数である。

次に、受信側端末Ａ１１０における受信側シーケンスを、図７のフローチャートを用いて具体的に説明する。実際の受信側シーケンス、受信処理等は制御部１１０ａにおいて実行される。

この発明に係る動画像データの配信方法において、端末Ａ、端末Ｂ、及び端末Ｃそれぞれでは、それぞれのフレーム送信制限が予め設定される（ステップＳＴ６１）。すなわち、端末Ａ、端末Ｂ、及び端末Ｃそれぞれは、自己の端末が動画像データの送信元となったときの、単位時間当たりの送信可能なフレーム数に関する送信制限情報を、該動画像データの送信に先立ち、予め他の端末に通知しておく。例えば、図４に示されたケースの場合、予め送信側端末Ｂ１２０は、バックグラウンドでの処理負荷が低いために送信制限が設定されていない。一方、送信側端末Ｃ１３０は、処理負荷が高いために５フレーム／ｓの送信制限が予め設定され、他の端末Ａ１１０、端末Ｂ１２０のそれぞれに通知される。

このように、送信側端末Ｂ１２０及び送信側端末Ｃ１３０において予め送信可能な画像フレーム数の上限を設定可能にしておくことにより、受信側端末Ａ１１０は、この上限以内で受信フレーム数を設定することとなる。そのため、負荷状況を無視して受信側端末Ａ１１０に動画像データを送ることによる該受信側端末Ａ１１０の処理負荷増加の回避とともに、送信側情報端末における処理負荷の低減も可能になる。さらに、受信側端末Ａ１１０は映像表示すべき画像フレーム数以外に自己のデータ処理（バックグラウンドでのデータ処理）を管理しながら、送信側端末Ｂ１２０又は送信側端末Ｃ１３０から送信される動画像データの処理が可能と判断したときのみに該当する送信側端末へ送信要求を行うなど、受信側及び送信側双方の端末が能動的に動画像データの配信動作を管理できる。

続いて、受信側端末Ａ１１０では、動画像データの受信タイミングの際に（ステップＳＴ６２）、自己の処理能力を確認する（ステップＳＴ６３）。このとき、受信側端末Ａ１１０が受信可能であると判断すれば、処理可能範囲内のフレーム数の動画データの送信要求を、送信側端末Ｂ１２０又は送信側端末Ｃ１３０のいずれかに通知する（ステップＳＴ６４）。

受信側端末Ａ１１０は、送信要求を通知した送信側端末Ｂ１２０又は送信側端末Ｃ１３０のいずれかから所定フレーム数の動画像データを受信すると、該受信された動画像データの各画像フレームを伸長しながら逐次モニタへ表示するなど、所定のフレーム再生処理を行う（ステップＳＴ６６）。なお、このフレーム再生動作（ステップＳＴ６６）は、送信要求した画像フレームすべての受信終了まで繰り返される（ステップＳＴ６７）。また、受信側端末Ａ１１０が送信側端末Ｂ１２０又は送信側端末Ｃ１３０から送信された画像フレームの受信待ちの状態で一定時間経過した場合には、再度、受信側端末Ａ１１０から送信側端末Ｂ１２０又は送信側端末Ｃ１３０へ送信要求が通知される。

次に、送信側端末Ｂ１２０及び送信側端末Ｃ１３０のそれぞれにおける送信側シーケンス及び画像フレームの送信処理を、図８のフローチャート及び図９を参照しながら具体的に説明する。実際の送信側シーケンス、送信処理等は、制御部１２０ａ、１３０ａにおいて実行される。

なお、端末Ａ、端末Ｂ、及び端末Ｃは、自己の端末が動画像データの送信元となったときの、単位時間当たりの送信可能なフレーム数に関する送信制限情報を、該動画像データの送信に先立ち、予め他の端末に通知しておく（ステップＳＴ７１）。図４のような実施形態では、端末Ｂ１２０及び端末Ｃ１３０が送信元であるため、これら送信側端末Ｂ１２０及び送信側端末Ｃ１３０のそれぞれは、他の端末に送信制限を通知して、受信側端末Ａ１１０からの送信要求を待つ（ステップＳＴ７２）。

例えば、受信側端末Ａ１１０から送信側端末Ｂ１２０へ送信要求が通知されたとすると、送信側端末Ｂ１２０は、まず、自己の処理能力を確認し、（ステップＳＴ７３）、続いて、受信側端末Ａ１１０に対してフレーム送信（ステップＳＴ７４）又は送信スキップを意味するエラー送信処理（ステップＳＴ７５）が行われる。なお、このフレーム送信処理は、図９に示されたように行われる。この図９に示されたフレーム送信処理では、受信側端末Ａ１１０から送信側端末Ｂ１２０に対して５フレーム／ｓの送信要求が通知されるものとする。また、このときの送信側端末Ｂ１２０における送信能力を５フレーム／ｓとする。

具体的なフレーム送信処理（ステップＳＴ７３〜ＳＴ７５）では、まず、図９（ａ）に示されたように、送信側端末Ｂ１２０が、自己のフレーム送信能力に応じて、予め用意されている動画像データＤ１（１２フレーム／Ｓ）を構成する画像フレームｆ１〜ｆ１２からエラーデータＥ１として画像フレームｆ１、ｆ６を排除することで一旦処理可能な動画像データＤ２（１０フレーム／ｓ）を生成する。さらに、送信側端末Ｂ１２０は、図９の領域（ｂ）に示されたように、受信側端末Ａ１１０から通知された送信要求のフレーム制限に対応するよう自己が送信処理可能な動画像データＤ２（画像フレームｆ２，…，ｆ５，ｆ７，…，ｆ１２）から、エラーデータＥ２として画像フレームｆ３、ｆ４、ｆ８、ｆ９、ｆ１１をさらに排除する。これにより、送信用動画像データＤ３（画像フレームｆ２、ｆ５、ｆ７、ｆ１０、ｆ１２により構成された５フレーム／ｓの動画像データ）が生成され、送信側端末Ｂ１２０はこの送信用動画像データＤ３を、送信要求を通知してきた受信側端末Ａ１１０へ送信する。

送信側端末Ｂ１２０は、以上のフレーム送信処理が終了すると（ステップＳＴ７６）、次の送信要求が通知されるまで待機する（ステップＳＴ７２）。

以上のように、この発明に係る動画像データの配信方法によれば、ネットワークを介して互いに接続された複数の情報端末間における処理負荷の偏在状況や接続されたネットワークの帯域状況に応じて配信されるべき動画像データのフレーム数を動的に調整することができる。そのため、これら複数の情報端末間における処理負荷の偏在に影響されることなく、リアルタイムでの動画像データ配信が可能になる。また、送受信される動画像データとして、Ｍｏｔｉｏｎ−ＪＰＥＧ方式等の動画像データが採用されることにより、動画像データを構成する画像フレーム数の増減が頻繁に発生した場合であっても、各情報端末間におけるリアルタイムでの動画像データ配信への影響は効果的に低減され得る。

以上の本発明の説明から、本発明を様々に変形しうることは明らかである。そのような変形は、本発明の思想および範囲から逸脱するものとは認めることはできず、すべての当業者にとって自明である改良は、以下の請求の範囲に含まれるものである。

１００…ネットワーク、１１０、１２０、１３０…情報端末（ＰＣ）、１１０ａ、１２０ａ、１３０ａ…制御部（ＣＰＵ）。

Claims (8)

1. 複数の画像フレームから構成された動画像データを、ネットワークを介して互いに接続された複数の情報端末間において送受信するための動画像データの配信方法であって、
   前記複数の情報端末間における双方向データ通信の一態様として送信側情報端末から受信側情報端末への前記動画像データの配信動作において、
   前記受信側情報端末は、所定の時間間隔で動画像データの送信要求を送信元となる前記送信側情報端末に対し繰り返す際、該送信要求を行う時点における前記ネットワークの帯域制限に起因する画像フレーム受信可能量、及び、自己の画像フレーム表示処理の負荷許容量のうち少なくとも何れか一方のデータ量を予め計算し、受信制限情報として、該データ量、及び、該データ量の算出根拠となるデータ構造要素のうち少なくとも何れか一方の上限値を、前記送信側情報端末に逐次通知することを特徴とする動画像データの配信方法。
2. 請求項１記載の動画像データの配信方法において、
   前記受信側端末装置から送信要求を受けた前記送信側情報端末は、受信した前記受信制限情報で指示されたデータ構造要素について、送信要求を受けた時点における自己の負荷許容範囲内に収まるデータ量、及び、前記受信側情報端末から要求されたデータ量のうち少なくとも何れか一方に合わせてそのデータ量が制限された動画像データを、送信要求を通知してきた前記受信側情報端末に送信する。
3. 請求項１記載の動画像データの配信方法であって、
   前記複数の情報端末間における双方向データ通信の一態様として、二以上の送信側情報端末から受信側情報端末への前記動画像データの配信動作において、
   前記受信側情報端末は、画像フレーム表示処理が可能な自己のタイミングで、前記二以上の送信側情報端末の何れかに送信要求信号を送信する。
4. 請求項３記載の動画像データの配信方法において、
   前記二以上の送信側情報端末のうち前記タイミングで発せられた送信要求信号を受信した送信側情報端末のみが該受信側情報端末から要求されたデータ量の動画像データを前記受信側情報端末に送信する一方、残りの送信側情報端末は、自己への送信要求を受信するまで動画像データの送信待機状態となる。
5. 請求項１〜４の何れか一項記載の動画像データの配信方法において、
   前記データ構造要素は、画像フレームに関する送受信単位の単位時間当たりの数、画像解像度、及び一画素当たりのビット数の少なくとも何れかを含む。
6. 請求項５記載の動画像データの配信方法において、
   前記動画像データは、時間軸方向に圧縮されることなくそれぞれが前画像フレームとは独立に再生可能な画像フレームから構成されており、
   前記画像フレームに関する送受信単位は、前記動画像データを構成する各画像フレームに相当する。
7. 請求項５記載の動画像データの配信方法において、
   前記動画像データは、それぞれが複数の画像フレームを含むとともに、時間軸方向から見て前に位置する画像フレームとは独立に再生可能な複数のフレーム群から構成されており、
   前記画像フレームに関する送受信単位は、前記動画像データを構成する各フレーム群に相当する。
8. 請求項１〜７の何れか一項記載の動画像データの配信方法において、
   前記複数の情報端末それぞれは、画像フレームに関する送受信単位の数について、自己の情報端末が前記動画像データの送信元となったときの、単位時間当たりに送信可能な上限値を指示する送信制限情報を、該動画像データの送信に先立ち、予め他の情報端末に通知しておく。

Images