(57)【特許請求の範囲】
【請求項１】
受信装置に対してデータを送信する送信装置であって、
前記受信装置が受信に失敗した第１のデータに表示領域が対応する第２のデータを用いて前記第１のデータの表示領域の表示をする機能を前記受信装置が有するか否かを示す情報と前記受信装置が受信に失敗した前記第１のデータの表示領域に含まれる領域のデータの再送を行うか否かを決定するために用いる閾値とを含む通知を前記送信装置と前記受信装置との接続時に前記受信装置から受信する受信手段と、
前記受信装置が前記第２のデータを用いて前記第１のデータの表示領域の表示をする機能を有し前記受信に失敗した第１のデータのデータ量が所定のデータ量より多い場合、前記第１のデータの表示領域に含まれる領域のうちデータの重要度が受信した前記通知に含まれる前記閾値以上である領域のデータを前記受信装置に再送すると決定する決定手段とを有することを特徴とする送信装置。
【請求項２】
前記決定手段は、前記受信装置が前記第２のデータを用いて前記第１のデータの表示領域の表示をする機能を有し前記受信に失敗した第１のデータのデータ量が所定のデータ量より多い場合、前記第１のデータの表示領域に含まれる領域のうち動き量が受信した前記通知に含まれる前記閾値以上である領域のデータを前記重要度が受信した前記通知に含まれる前記閾値以上である領域のデータとして前記受信装置に再送すると決定することを特徴とする請求項１に記載の送信装置。
【請求項３】
前記決定手段は、前記受信装置が前記第２のデータを用いて前記第１のデータの表示領域の表示をする機能を有し前記受信に失敗した第１のデータのデータ量が所定のデータ量より多い場合、前記第１のデータの表示領域に含まれる領域のうち他の領域の動き方向との差が受信した前記通知に含まれる前記閾値以上である領域のデータを前記重要度が受信した前記通知に含まれる前記閾値以上である領域のデータとして前記受信装置に再送すると決定することを特徴とする請求項１に記載の送信装置。
【請求項４】
前記決定手段は、前記受信装置が前記第２のデータを用いて前記第１のデータの表示領域の表示をする機能を有し前記受信に失敗した第１のデータのデータ量が所定のデータ量より多い場合、前記第１のデータの表示領域に含まれる複数の領域の動き方向のばらつきの度合いが受信した前記通知に含まれる前記閾値以上である前記複数の領域のデータを前記重要度が受信した前記通知に含まれる前記閾値以上である領域のデータとして前記受信装置に再送すると決定することを特徴とする請求項１に記載の送信装置。
【請求項５】
受信装置に対してデータを送信する送信装置が行う送信方法であって、
前記受信装置が受信に失敗した第１のデータに表示領域が対応する第２のデータを用いて前記第１のデータの表示領域の表示をする機能を前記受信装置が有するか否かを示す情報と前記受信装置が受信に失敗した前記第１のデータの表示領域に含まれる領域のデータの再送を行うか否かを決定するために用いる閾値とを含む通知を前記送信装置と前記受信装置との接続時に前記受信装置から受信する受信工程と、
前記受信装置が前記第２のデータを用いて前記第１のデータの表示領域の表示をする機能を有し前記受信に失敗した第１のデータのデータ量が所定のデータ量より多い場合、前記第１のデータの表示領域に含まれる領域のうちデータの重要度が受信した前記通知に含まれる前記閾値以上である領域のデータを前記受信装置に再送すると決定する決定工程とを有することを特徴とする送信方法。
【請求項６】
前記決定工程において、前記受信装置が前記第２のデータを用いて前記第１のデータの表示領域の表示をする機能を有し前記第１のデータのデータ量が所定のデータ量より多い場合、前記第１のデータの表示領域に含まれる領域のうち動き量が受信した前記通知に含まれる前記閾値以上である領域のデータを前記重要度が受信した前記通知に含まれる前記閾値以上である領域のデータとして前記受信装置に再送すると決定することを特徴とする請求項５に記載の送信方法。
【請求項７】
受信装置に対してデータを送信するコンピュータに、
前記受信装置が受信に失敗した第１のデータに表示領域が対応する第２のデータを用いて前記第１のデータの表示領域の表示をする機能を前記受信装置が有するか否かを示す情報と前記受信装置が受信に失敗した前記第１のデータの表示領域に含まれる領域のデータの再送を行うか否かを決定するために用いる閾値とを含む通知を前記コンピュータと前記受信装置との接続時に前記受信装置から受信する受信手順と、
前記受信装置が前記第２のデータを用いて前記第１のデータの表示領域の表示をする機能を有し前記受信に失敗した第１のデータのデータ量が所定のデータ量より多い場合、前記第１のデータの表示領域に含まれる領域のうちデータの重要度が受信した前記通知に含まれる前記閾値以上である領域のデータを前記受信装置に再送すると決定する決定手順とを実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば映像ストリーミング等のデータ通信サービスの品質を維持するための技術に関するものである。
【背景技術】
【０００２】
従来、映像ストリーミングにおける送信装置と受信装置といった末端で行われるＱｏＳ（通信サービスの品質）制御技術としてよく知られているものとしては、再送制御、レート制御、エラー訂正技術であるＦＥＣ、エラー隠蔽技術であるＥＣ等がある。なお、ＦＥＣとは、Forward Error Correctionの略称であり、ＥＣは、Error Concealmetの略称である。
【０００３】
これら個々の技術における技術検討は既に多方面で行われており、ネットワークの帯域の輻輳状況を考慮した細かい制御を更に付加するような先行技術が存在する。
【０００４】
このように、映像ストリーミングシステムを考えた場合に、例えばレート制御技術において映像データの配信側での映像データ送信時のエラー回避を考慮し、映像を送信するが、それでもロスしたパケットを再送する等してエラーの回復を行う技術を使用する。また、映像ストリーミングの受信側においてそれでも回復できないようなエラーの隠蔽を行う技術を更に追加するといった複合的な制御方法が検討されている。そして、種々のエラー耐性技術が映像ストリーミング送信時に全て制御可能な状況で、且つ期待通りの動作が実行された場合に、高い確率で高品位な映像ストリーミング送信のＱｏＳ制御が可能になると予想されている。
【０００５】
特許文献１には、エラーがパケット内で推測されるときに受信側システムが再送を試みてはならいないことを示すリトライフラグをパケットに付加する技術が開示されている。
【０００６】
【特許文献１】特開２００７−２８６２３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、映像ストリーミングの送信側や映像ストリーミングの受信側又はその間の帯域のような各ポイントで完全にＱｏＳ制御が全て行われているからといって、必ずしも最善な結果が得られるとは限らない。なぜならば、エラー耐性処理が各ポイントで行われていると、それぞれのポイントでＱｏＳリソースを使用することとなり、システム全体としてのＱｏＳリソース負荷が大きくなる。その為、単一の映像ストリーミングの配信では支障がなくとも、個人が複数の映像ストリーミングの配信を行う場合に支障を来たすことが考えられる。また、複数のユーザによるネットワーク回線を利用した複数の映像ストリーミングの送信時、及び、個人のＰＣ端末における複数のアプリケーションの使用時にも他の映像ストリーミングやアプリケーションに支障を来たすことが大いに考えられる。特に映像ストリーミングの再送においては、狭帯域の伝送や帯域の混雑時のパケットロスで必要とされる為、再送により更なる帯域の悪化の可能性が考えられる。
【０００８】
また、特許文献１に開示される技術においては、エラー訂正技術とエラー隠蔽技術との複合的な制御方法については何ら考慮されていない。
【０００９】
そこで、本発明の目的は、通信サービスの品質維持のための制御負荷を分散させるとともに、データの再送による通信帯域の悪化を回避することにある。
【課題を解決するための手段】
【００１０】
本発明の送信装置は、受信装置に対してデータを送信する送信装置であって、前記受信装置が受信に失敗した第１のデータに表示領域が対応する第２のデータを用いて前記第１のデータの表示領域の表示をする機能を前記受信装置が有するか否かを示す情報と前記受信装置が受信に失敗した前記第１のデータの表示領域に含まれる領域のデータの再送を行うか否かを決定するために用いる閾値とを含む通知を前記送信装置と前記受信装置との接続時に前記受信装置から受信する受信手段と、前記受信装置が前記第２のデータを用いて前記第１のデータの表示領域の表示をする機能を有し前記受信に失敗した第１のデータのデータ量が所定のデータ量より多い場合、前記第１のデータの表示領域に含まれる領域のうちデータの重要度が受信した前記通知に含まれる前記閾値以上である領域のデータを前記受信装置に再送すると決定する決定手段とを有する。
【発明の効果】
【００１１】
本発明によれば、通信サービスの品質維持のための制御負荷を分散させるとともに、データの再送による通信帯域の悪化を回避することが可能となる。
【発明を実施するための最良の形態】
【００１２】
以下、本発明を適用した好適な実施形態を、添付図面を参照しながら詳細に説明する。
【００１３】
＜第１の実施形態＞
先ず、本発明の第１の実施形態について説明する。図１は、本発明の第１の実施形態に係るシステム構成を概略的に示す図である。なお、後述する他の実施形態においても図１に示すシステム構成を採用することが可能である。
【００１４】
図１に示すように、本実施形態に係るシステムは、送信装置１０１から受信装置１０２、１０３へ映像ストリーミングを配信するシステムである。受信装置１０２、１０３から送信装置１０２へのパケットの再送要求が行われた際、送信装置１０１には受信装置１０２、１０３のエラー隠蔽機能であるError Concealment（以下、ＥＣと称す）機能の有無が伝達される。なお、送信装置１０１と受信装置１０２、１０３とは、例えばサーバとクライアントとの関係にある。以下では、送信装置１０１をサーバ１０１と称し、受信装置１０２、１０３をクライアント１０２、１０３と称する。受信装置１０２、１０３は、本発明のデータ受信装置の適用例となる構成であり、送信装置１０１は、本発明のデータ送信装置の適用例となる構成である。
【００１５】
サーバ１０１はＥＣ機能を持たないクライアント１０３には配信部によりパケットの再送を行い、ＥＣ機能を持つクライアント１０２にはパケットの再送を行わない。本実施形態では、このような制御を基本制御とする。このように、クライアント１０２にＥＣ機能がある場合には、クライアント１０２側のＱｏＳ機能を利用し、サーバ１０１とクライアント１０２間の再送機能は利用しないといった制御を行う。これにより、ＱｏＳリソースの負荷分散を行う。
【００１６】
クライアント１０２、１０３がＥＣ機能を保持するかどうかの情報の伝達方法としては、図２の２０４に示すように、クライアント１０２、１０３からのＲＴＳＰリクエストにＥＣ機能の有無を伝達できるヘッダ情報を埋め込むことが例として考えられる。２０４はクライアント１０２、１０３からサーバ１０１へのＲＴＳＰリクエストの内容の例である。このリクエストの最終行にあるEC:1がＥＣ機能の有無の伝達部分である。ＥＣ機能が有る場合には１、無い場合には０とすることで、サーバ１０１側でクライアントのＥＣ機能の有無を判別することを可能としている。
【００１７】
上記の基本制御では、クライアントにＥＣ機能があればパケットを再送しないと一意的に決定する。しかしながら、それだけでは、パケットロスの量やロスしたパケットがその後のフレームに影響を及ぼす範囲（影響範囲）により映像品質が著しく低下する恐れがある。このように著しい画像品質の低下が予想される場合においては、上記の基本制御に加えて、サーバ１０１側の判断でパケットの再送を行うこととする。つまり、クライアント１０２においてＥＣ機能を有するが、その機能の効果が見込めない場合、サーバ１０１は特別にパケットの再送を許可するといったような制御をリアルタイムに行う。
【００１８】
上述した制御を行うために、本実施形態においては、前述のＥＣ機能の有無に加えて、ＥＣ機能の更に詳細な手法を示す情報や、その手法によってエラーを修復する為の各種閾値である数値情報を付加してクライアントからサーバ１０１に伝達される。具体的には、図２の２０４の最終行における前述のＥＣ機能の有無を示すEC:1の後の文字列にＥＣ機能の更に詳細な手法を示す情報や、その手法によってエラーを修復する為の各種閾値が記述されている。例えば、ec_level =３のような記述でＲＴＳＰリクエストをクライアント１０２からサーバ１０１へ送信する。これは重要度を５段階で設定したうちの重要度３以上のパケットを再送するということを示している。この詳細な情報付加によって、サーバ１０１において、クライアント１０２、１０３のＥＣ機能の有無のみではなく、クライアント１０２、１０３のより詳細なＥＣ機能の効果の把握が可能になる。
【００１９】
上記のＥＣ機能の効果が見込めない場合の判断は種々の手法が考えられる。ここでは、サーバ１０１側で例外的にパケットの再送を行う場合の判断基準を、サーバ１０１−クライアント１０２、１０３間のエラーパケット（ロスしたパケット）の量に応じて設けた場合を例に挙げて説明する。エラーパケットの量を検知する方法としては、ＲＴＳＰを利用する方法がある。
【００２０】
図３は、ＲＴＳＰ（Real Time Streaming Protocol）のＲＲ（Receiver Report）パケット内に含まれるreception report blockの構成を概念的に示す図である。図３に示すように、reception report blockには、クライアント１０２、１０３が受信したストリーム各々についてストリームの受信状態（パケット廃棄率、ジッタ、その他）を示す情報が記述されている。サーバ１０１は、reception report block３０１に含まれる情報を取得することにより、どのくらいパケットロスが発生しているかを判定することができる。このパケットロスの量によりクライアント１０２、１０３側にＥＣ機能が存在することが分かっていても、再送を行うこととする。その他、クライアント１０２、１０３側のパケットのシーケンス番号を確認することにより、どのくらいのパケットがロスしているかの把握が可能である。
【００２１】
ＥＣ機能の効果が見込めないことを判定するためにロスしたパケットの量との比較対象となる閾値に関しては、アプリケーション毎にサーバ１０１側に予め設定しておく方法がある。また、上述のＲＴＳＰリクエスト内においてＥＣ機能の手法毎に異なる閾値を細かく設定しておき、これをサーバ１０１側で設定するようにしてもよい。これにより、ＥＣ機能の手法に合わせてパケットロスの量の許容範囲を制御することが可能になる。
【００２２】
図２を用いて説明すると、２０４の最終行において、前述のＥＣの有無を示すEC:1、重要度許容レベルを示すec_level =３の後の文字列である。Max_loss=5と記述してクライアント１０２からサーバ１０１へ送ることにより、パケットロスの割合が５％を超えた場合にはサーバ１０１はパケットの再送を行う。又は、５つ連続してパケットがロスした場合にはパケットを再送すること等が考えられる。これら具体的な数値の設定方法としては、事前にテストしておき、最適な数値を設定する方法が一例として考えられる。例えば、擬似的にエラーパケットを発生させて、ＥＣ機能の効果を視覚的にチェックすることで耐え得る数値を設定する。
【００２３】
次に、図４のフローチャートを参照しながら、サーバ１０１の動作を詳細に説明する。図４は、サーバ１０１の動作の流れを示すフローチャートである。
【００２４】
先ず、サーバ１０１は、最初にクライアント１０２、１０３からサーバ１０１への接続時にＲＴＳＰのDESCRIBEメッセージに付加されたクライアントのＥＣ機能の有無を取得する（ステップ４０１）。そして、取得したＥＣ機能の有無により、ＥＣ機能が有ることが判明した場合には、サーバ１０１は、再送機能をＯＦＦにするかの判断を行う（ステップ４０２）。このステップ４０２の判断において、再送機能をＯＦＦにしないと判断した場合には、サーバ１０１は、再送有りでストリーミング送信を行う（ステップ４０３）。一方、ステップ４０２の判断において再送機能をＯＦＦにすると判断した場合には、サーバ１０１は、再送なしでストリーミング送信を行う（ステップ４０４）。なお、ステップ４０２は、本発明のデータ送信装置の判定手段の一処理例である。
【００２５】
次に、サーバ１０１は、ＲＴＳＰのＲＲパケットに付加されるパケットロスの状況を取得する（ステップ４０５）。前述のように、クライアント１０２、１０３側でＲＴＰパケットのシーケンス番号を確認し、その結果をサーバ１０１が取得することによりパケットロスの状況把握が可能となる。
【００２６】
次に、サーバ１０１は、ステップ４０５で取得したエラーパケットの量が予め設定された閾値を超えているか否かの判断を行う（ステップ４０６）。ステップ４０６の判断において閾値を超えていないと判断した場合には、処理はステップ４０４に戻り、サーバ１０１は、パケットの再送なしで映像ストリーミングの送信を継続して行う。一方、ステップ４０６の判断において閾値を超えていると判断した場合には、サーバ１０１は、パケットの再送有りで映像ストリーミングの送信を開始する（ステップ４０７）。以降、サーバ１０１は、パケットの再送を行いながら映像ストリーミングの送信を継続するが、定期的にクライアント１０２、１０３から受信するＲＴＳＰのＲＲパケットを取得したり、ＲＴＰパケットのシーケンス番号をチェックする。そして、サーバ１０１は、ロスしたパケット量と閾値との判断を繰り返し行うことで、随時ロスしたパケット量の状況に合わせたストリーミング送信制御を行う。なお、クライアント１０２、１０３から終了イベントをサーバ１０１が受信することにより処理は終了する。なお、ステップ４０７は、本発明の送信手段の一処理例である。
【００２７】
＜第２の実施形態＞
次に、本発明の第２の実施形態について説明する。前述した第１の実施形態では、クライアント１０２、１０３でＥＣ機能の効果が見込めない場合の判断方法として、パケットロスの量が閾値を超えるか否かの判断を行う例を説明した。これに対し、本実施形態では、その他のＥＣ機能の効果が見込めない場合の判断方法について説明する。
【００２８】
本実施形態では、サーバ１０１が予め重要な動きベクトルを決定しておき、その動きベクトルを含むパケットがロスした場合にパケットを再送する。本実施形態では、図５に示すように、時刻ｔ１においてマクロブロック（以下、ＭＢと称す）は５０３に位置しているが、時刻ｔ２にはＭＢが５０４の位置に移動している。本実施形態においては、ＭＢの移動量を示す動きベクトル５０５を予め決定しておき、動きベクトル５０５を含むパケットがロスした場合にパケットの再送を行う。
【００２９】
具体的には、予めフレーム内の動きベクトルのうち、ロスした場合に影響が大きいと思われる動きベクトルを抽出して記憶しておく。そして、その動きベクトルを含むパケットがロスしたことをサーバ１０１がクライアント１０２、１０３から通知を受けることにより、サーバ１０１は当該パケットを再送する。また、予め動きベクトルを抽出して決定しておく方法の他に、各種動きベクトルに重要度を付加しておき、ロスしたパケットの動きベクトルの重要度が予め設定される閾値を超えた場合、当該パケットを再送するようにしてもよい。
【００３０】
ここで、動きベクトルの重要度について図６〜図８を参照しながら具体的に説明する。図６に示すように、フレーム内にＭＢ１〜ＭＢ９が存在する場合を例に挙げて説明する。これらのＭＢ１〜ＭＢ９の動きベクトルを表したものが夫々図７に示すＭＶ１〜ＭＶ９である。即ち、ＭＢ１の動きベクトルはＭＶ１であり、ＭＢ２の動きベクトルはＭＶ２であり、・・・、ＭＢ９の動きベクトルはＭＶ９である。
【００３１】
サーバ１０１には、動きベクトルの長さを示す所定の数値が閾値として予め設定されており、その閾値以上の長さを有する動きベクトルが、ロスした場合に影響が大きいと思われる動きベクトルとして抽出される。
【００３２】
上記動きベクトルの長さを示す所定の数値である閾値をサーバ１０１に設定する方法としては、前述の図２におけるＲＴＳＰリクエストでクライアント１０２、１０３からサーバ１０１へ伝達して設定する方法がある。また、ユーザの操作によってサーバ１０１に予め設定しておく方法でもよい。
【００３３】
また、動きベクトルの長さを何段階かにレベル分けし、レベルに応じた重要度を設定してもよい。重要度は、アプリケーション毎又はユーザ毎に変更可能であり、高精彩な画像を必要とするアプリケーション又はユーザにおいては、重要度の低いレベルの動きベクトルを含むパケットから再送を行うといった調整が可能であり、より汎用的な制御が可能となる。
【００３４】
また、動きベクトルを用いた他の例としては、図６に示すＭＢ１〜ＭＢ９について図８に示す動きベクトルＭＶ１〜ＭＶ９が発生した場合、動きベクトルＭＶ１〜ＭＶ９の向きが一方向であるか又は多方向を向いているのかといったばらつきを求める。例えば、多くの動きベクトルの向きがほぼ同一の方向を向いている場合、サーバ１０１はその方向と反している動きベクトルを含むパケットを再送する。図８に示す例では、ＭＶ３、ＭＶ６、ＭＶ７が該当するため、これらの動きベクトルを含むパケットを再送する。
【００３５】
さらに、動きベクトルを用いた他の例としては、サーバ１０１がフレーム単位で各動きベクトルのばらつきを検出し、ばらつきの度合いを算出する。算出したばらつきの度合いが所定の数値以上である場合、サーバ１０１は当該フレームを再送する。又は、ばらつきを何段階かにレベル分けし、レベルに応じた重要度をフレームに設定することによりアプリケーション毎及びユーザ毎に汎用的に制御可能とする方法が考えられる。
【００３６】
＜第３の実施形態＞
次に、本発明の第３の実施形態について説明する。本実施形態では、サーバ１０１は、予め重要なテクスチャデータを決定しておき、そのテクスチャデータがロスした場合にテクスチャデータのパケットを再送する。サーバ１０１は、予めフレーム内のテクスチャデータのうち、ロスした場合に影響が大きいと思われるテクスチャデータを抽出して記憶しておく。それ以降は、第１の実施形態と同様に、クライアント１０２からロスしたデータに関する情報がサーバ１０１へ送られる。ロスしたパケットが予め記憶しておいたテクスチャデータのパケットであることをサーバ１０１側で検出した場合、サーバ１０１は、そのパケットを再送する。
【００３７】
また、第１の実施形態と同様に、予めテクスチャデータに重要度を割り当てておき、ロスしたパケットに該当するテクスチャデータの重要度が所定の閾値以上であれば、当該パケットの再送を行うようにしてもよい。
【００３８】
具体的なテクスチャデータの重要度の設定方法としては、図９に示すように、フレーム内の領域をＴｘ１〜Ｔｘ９のように分割してランク付けを行い、ランクに応じた重要度を設定する方法が考えられる。また、カメラの向きが移動する場合に、注目する物体を検出してその物体の中心からの距離に応じて重要度をレベル分けする方法も考えられる。但し、ここでは説明の簡便のため、定点カメラにおける画像のフレーム内の領域分割による重要度のレベル付けを例に挙げる。図９に示すように目標物９０２を含む領域Ｔｘ４〜Ｔｘ９を最重要データとする。そして、目標物９０２から遠くなるに従って領域の重要度を下げるように設定しておく。重要度の使用方法は前述の動きベクトルと同様である。なお、サーバ１０１におけるテクスチャデータの重要度の閾値設定方法は、ユーザの操作に応じて閾値をサーバ１０１に設定してもよいし、クライアント１０２、１０３から閾値を含むＲＴＳＰリクエストをサーバ１０１に送信することにより設定してもよい。
【００３９】
＜第４の実施形態＞
次に、本発明の第４の実施形態について説明する。本実施形態においては、パケット再送要求後に、ロスパケットがその後のフレームのどれだけの面積で参照されているかを計算し、その面積が予め設定した閾値を超える場合にパケットの再送が行われる。
【００４０】
クライアント１０２、１０３から通知されるロスしたパケットのシーケンス番号から、そのパケットが次のフレームのどの程度の領域から参照されるのかを、サーバ１０１側で確認する。この際、エンコードしたデータをしばらくサーバ１０１側で保存しておく。そして、そのロスしたパケットを参照する領域が大きい程、重要度が高くなり、その領域の面積によって重要度のレベル分けを行う。
【００４１】
その重要度を判別する面積の閾値の設定方法としては、単に面積を使用する方法と、全画面の面積に対するロスパケットが参照される面積のパーセンテージを使用する方法とが考えられる。例えば、事前にテストを行い、乱れる映像の視覚的許容値、例えば、視覚的に耐え得る乱れがどのくらいの面積までなのか、又は、全体の画像のどのくらいのパーセンテージが上限であるかを決定しておき、その許容値を超えた場合には再送するといった方法がある。閾値の設定及び伝達方法に関しては前述の通りである。
【００４２】
＜第５の実施形態＞
次に、本発明の第５の実施形態について説明する。本実施形態においては、再送要求後に、ロスパケットがその後の何フレームに乱れを生じさせるか、予め最大許容影響フレーム数を設定し、その閾値を超える場合のみ再送する。
【００４３】
第４の実施形態では、ロスしたパケットの影響範囲を参照している次のフレームの面積で計算してきたが、ここでは、参照しているフレーム数によってその影響を判定することとする。ロスしたパケットがその後の何フレームに参照されているかをチェックして、例えば閾値を３フレームとした場合には、３フレーム以上参照されるような場合には、再送を行うこととする。
【００４４】
＜第６の実施形態＞
次に、本発明の第６の実施形態について説明する。本実施形態においては、再送要求時のクライアント１０２、１０３のＣＰＵ使用率により、ＥＣ機能の効果が見込めない場合にパケットを再送する。この通知方法に関しては、ＲＴＳＰレスポンスのＲＲパケットの拡張領域内にクライアント１０２、１０３のＣＰＵ使用率を付加する。予めクライアント１０２、１０３でのＥＣ機能の効果においてＣＰＵ使用率毎に視覚的に効果が得られるという数値を計測しておく。次に、その数値を前述のRTSP DESCRIBEのパラメータに例えばec_CPU_tolerance=70等といった項目を追加する。そして、サーバ１０１側でＣＰＵ使用率を取得した場合に、ＣＰＵ使用率が７０％以上の場合にパケットの再送を行う。なお、クライアント１０２、１０３のＣＰＵ使用率は、本発明におけるデータ受信装置のリソース状況の一例である。従って、本発明に適用可能なリソース状況には、メモリやハードディスク等の使用量、ネットワークの流量等も含まれる。
【００４５】
以上、ＥＣ機能の効果の判断方法について説明したが、それを判断するための閾値を設定する際にＥＣ機能の効果が見込めない場合の境界値をどこに設けるかは、個人差やシステムの目的毎に異なる。前述のようにシステム毎に閾値を設定したり、重要度を設定してもよい。或いは、ユーザが画質に低、中、高のどのレベルを求めるかに応じて任意に閾値及び重要度を設定してもよい。
【００４６】
＜第７の実施形態＞
次に、本発明の第７の実施形態について説明する。前述した第１〜第６の実施形態では、クライアント１０２、１０３でのＥＣ機能の効果が見込めるかどうかの判断を単一の判断処理で決定しているが、本実施形態においては、複合判断によって再送の有無を切り換える。
【００４７】
例えば、前述のパケットロスの量による判断と動きベクトルによる重要度の判断の両方を用いる場合について説明する。この判断方法を用いる場合には、まず最初に、パケットロスの量を前述のＲＴＳＰレスポンスのＲＲパケットから取得して、そのパケットロスの量がある一定の量を超える場合にはパケットの再送を行うこととする。但し、この判断方法においては、パケットを再送する際に全パケットをサーバ１０１から送信するのではなく、動きベクトルによる重要度の中で予め設定した閾値以上、又は、クライアント１０２、１０３からの接続時に要求した重要度の閾値以上のパケットのみを再送する。この場合、単独の判断のみでなく、複合的な判断が加わることにより、再送するパケット量の削減が図れる。更に重要データの選択が入ることで、重要度の高いパケットを乱れの大きい地点で再送することが可能となり、単独の場合と比較して再送するパケットにおける回復効率を向上させることができる。
【００４８】
＜第８の実施形態＞
次に、本発明の第８の実施形態について説明する。前述の第１〜第７の実施形態では、クライアント１０２、１０３でのＥＣ機能の効果が見込めるかどうかの判断をサーバ１０１で行っている。これに対し、本実施形態においては、前述の各種判断方法を全てクライアント１０２、１０３側で行う。
【００４９】
図１０は、本実施形態におけるクライアント１０２、１０３の動作の流れを示すフローチャートである。図１０において、まず、クライアント１０２、１０３は、ＥＣ機能を保持しているかどうかの確認を行う（ステップ１００１）。ＥＣ機能を保持しない場合には、クライアント１０２、１０３は、サーバ１０１へＥＣ機能が無いことと、その為にパケットの再送を開始することとを通知する（ステップ１００２）。その通知方法については、第１の実施形態で図２を用いて説明したＲＴＳＰリクエストにＥＣ機能の有無を付加して送信する方法が一例として挙げられる。その結果、クライアント１０２、１０３はパケットの再送有りで映像ストリーミングを受信する（ステップ１００３）。なお、ステップ１００１は、本発明のデータ受信装置の判定手段の一処理例である。
【００５０】
一方、ステップ１００１におけるＥＣ機能保持の判断において、ＥＣ機能を保持すると判断された場合には、クライアント１０２、１０３は、サーバ１０１へＥＣ機能が有ることと、その為にパケットの再送無しで映像ストリーミングの送信を開始することとを通知する（ステップ１００３）。この通知方法は、前述したＲＴＳＰリクエストを使用した方法と同様である。この通知の結果、クライアント１０２、１０３はパケットの再送無しで映像ストリーミングを受信する（ステップ１００５）。
【００５１】
そして、クライアント１０２、１０３は、受信した映像ストリーミングのパケットのシーケンスナンバからパケットロスを検知する（ステップ１００６）。続いて、クライアント１０２、１０３は、単位時間当たりにロスしたパケットの量が予め設定された閾値を超えているか否かの判断を行う（ステップ１００７）。この閾値の設定方法に関しては、既に述べた設定方法と同様である。即ち、事前にテスト、例えば擬似的なエラーを発生する等して視覚的に耐え得る最大値を算出しておき、その閾値をクライアント１０２、１０３側で保持する。ロスパケットが発生した場合に、クライアント１０２、１０３側で単位時間のロスしたパケット量を計測して、保持している閾値と比較するといった判断方法が挙げられる。
【００５２】
そして、ロスしたパケットの量と閾値との比較において、ロスしたパケットの量が閾値を超えない場合には、クライアント１０２、１０３は、それまでと同様にパケットの再送無しで映像ストリーミングの受信を継続する。一方、ロスしたパケットの量が閾値を超える場合には、クライアント１０２、１０３は、サーバ１０１へパケットの再送有りで映像ストリーミングの送信を依頼する（ステップ１００８）。その通知方法としては、ＲＴＳＰリクエストのＲＲパケットの拡張領域を使用することが一例として挙げられる。その結果、クライアント１０２、１０３は、ＥＣ機能を保持するが、例外的にパケットの再送有りで映像ストリーミングの受信を開始する（ステップ１００９）。以降、クライアント１０２、１０３は、映像ストリーミングの受信を継続するが、定期的にサーバ１０１から受信するパケットのシーケンス番号からパケットロスの状況を検出し、ロスしたパケットの量と閾値との判断を繰り返し行う。このようにして、クライアント１０２、１０３は、随時ロスしたパケットの量の状況に合わせた映像ストリーミングの受信制御を行う。なお、クライアント１０２、１０３は、自ら終了イベントを発生することにより処理は終了する。
【００５３】
以上、上述した実施形態においては、受信装置１０２、１０３におけるエラー隠蔽機能に応じて、受信装置１０１にパケットの再送を行うか否かを決定するように構成している。従って、通信サービスの品質維持のための制御負荷を分散させるとともに、パケットの再送による通信帯域の悪化を回避することが可能となる。
【００５４】
上述した本発明の実施形態を構成する各手段及び各ステップは、コンピュータのＲＡＭやＲＯＭ等に記憶されたプログラムが動作することによって実現できる。このプログラム及び前記プログラムを記録したコンピュータ読み取り可能な記録媒体は本発明に含まれる。
【００５５】
また、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施形態も可能であり、具体的には、一つの機器からなる装置に適用してもよい。
【００５６】
なお、本発明は、上述した実施形態の機能を実現するソフトウェアのプログラムを、システム又は装置に直接、又は遠隔から供給する。そして、そのシステム又は装置のコンピュータが前記供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。
【００５７】
従って、本発明の機能処理をコンピュータで実現するために、前記コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であってもよい。
【００５８】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される。更に、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳ等が、実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現され得る。
【００５９】
更に、その他の方法として、まず記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれる。そして、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によっても前述した実施形態の機能が実現される。
【図面の簡単な説明】
【００６０】
【図１】本発明の実施形態に係るシステム構成を概略的に示す図である。
【図２】エラー隠蔽機能の通知方法を説明するための図である。
【図３】ＲＴＳＰのＲＲパケット内に含まれるreception report blockの構成を概念的に示す図である。
【図４】サーバの動作の流れを示すフローチャートである。
【図５】マクロブロックの動きベクトルを説明するための図である。
【図６】動きベクトルの重要度を説明するための図である。
【図７】動きベクトルの重要度を説明するための図である。
【図８】動きベクトルの重要度を説明するための図である。
【図９】テクスチャデータの重要度の設定方法を具体的に説明するための図である。
【図１０】本発明の他の実施形態におけるクライアントの動作の流れを示すフローチャートである。
【符号の説明】
【００６１】
１０１  送信装置（サーバ）
１０２、１０３  受信装置（クライアント）
【図１】
0005142828.tif 000002
【図２】
0005142828.tif 000003
【図３】
0005142828.tif 000004
【図４】
0005142828.tif 000005
【図５】
0005142828.tif 000006
【図６】
0005142828.tif 000007
【図７】
0005142828.tif 000008
【図８】
0005142828.tif 000009
【図９】
0005142828.tif 000010
【図１０】
0005142828.tif 000011