JP2005033556A - データ送信装置、データ送信方法、データ受信装置、データ受信方法 - Google Patents

Abstract

【課題】送信側装置および受信側装置の双方の処理負荷を高めることなく、受信側装置が置かれている多様な伝送環境に対して適応的なデータ伝送を実現することのできる装置、および方法を提供することを目的とする。
【解決手段】同一のデータ信号を異なる符号化パラメータを用いて符号化し、第１、第２の符号化データストリームを生成する。第１の符号化データストリームはパケット化されて第１のマルチキャストアドレスに送信される。第２の符号化データストリームは第２のマルチキャストアドレスに送信される。第１、第２の符号化データストリームの生成に用いられたそれぞれの符号化パラメータを第１、第２のマルチキャストアドレスに対応付けて表すパラメータデータが要求に応じてデータ受信装置に送信される。データ受信装置はパラメータデータに基づいてマルチキャストアドレスを切り替えて符号化データストリームを選択的に受信する。
【選択図】 図１

Description

【０００１】
【発明の属する技術分野】
本発明は、通信ネットワーク、特にマルチキャストネットワークを介して画像や音声などのデータを送受信し、再生する方法及び装置に関する。
【０００２】
【従来の技術】
近年、画像をはじめとする各種情報のディジタル符号化技術及び広帯域ネットワーク技術の進展により、これらの技術を利用して圧縮符号化した画像データをネットワークを通じて伝送するシステムが開発されている。データ伝送の際に、多数のユーザが効率よく伝送路を利用する手法として、データをパケット化して送受信する方法が有効である。データをパケット化して伝送するプロトコルとしては、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）やＵＤＰ／ＩＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）などが存在する。ＴＣＰ／ＩＰは再送などの枠組みが組み込まれていることから誤り耐性が高く、多少時間がかかっても正しくデータを受信したいダウンロード型のアプリケーションに有効である。またＴＣＰ／ＩＰは、ウインドウサイズと呼ばれるパケットのサイズをネットワークからの応答により動的に変更することで輻輳制御を行うことが可能であるものの、リアルタイム性を求められるアプリケーションには非力である。これに対し、ＵＤＰ／ＩＰは再送の枠組みを備えていないことから、再送などにかかる遅延がなく、リアルタイム性を求められるアプリケーションに極めて有効である。
【０００３】
さらに近年では、ＵＤＰをベースにして、オーディオ・データやビデオ・データをリアルタイム伝送するためのＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）を利用するアプリケーションが増えてきている。ＲＴＰについてはＲＦＣ１８８９に規定されており、リアルタイム会話形式でデータを授受するビデオ会議のようなマルチメディア・システムに適用されることが想定されている。なお、ＲＴＰはＲＴＰヘッダー中にパケットの順序番号や時間情報（タイム・スタンプ）を記述可能なパケットフォーマットを有しており、これらの情報に基づくリアルタイム動作をサポートしている。例えば、受信側では、パケットに記述された正しい時間情報に従って音声や画像のコンテンツデータを構築して適切に表示再生することができる。また、ネットワーク伝送過程で順番が入れ替わったパケットを判定したり、伝送中にどのパケットが損失したかなどをパケット番号に基づいて検知することができる。ＲＴＰには音質や画質の品質保証機能は設けられていないが、パケット送信受の補足情報として、ジッタ（遅延情報）やパケット損失率などを相互間で通知する仕組み（ＲＴＣＰ）を備える。
【０００４】
リアルタイム性を求められるアプリケーションの代表例として動画像の伝送が挙げられるが、ごく普通の動画像であっても、そのままのデータ形式では画像データ量はきわめて膨大でありネットワーク帯域を圧迫するから、画像データを符号化し、データ量をあらかじめ圧縮してから伝送するという手法が採られる。
【０００５】
動画像信号の圧縮符号化技術としては動き補償、離散コサイン変換（ＤＣＴ）、サブバンド符号化、ピラミッド符号化、可変長符号化等の技術やこれらを組み合わせた方式が開発されている。動画像符号化の国際標準方式としてはＩＳＯ ＭＰＥＧ−１、ＭＰＥＧ−２、ＩＴＵ−Ｔ Ｈ．２６１、Ｈ．２６２、Ｈ．２６３が存在し、また動画像、音声・オーディオ信号を圧縮した符号列や他のデータを多重化する国際標準方式としてはＩＳＯ ＭＰＥＧシステム、ＩＴＵ−Ｔ Ｈ．２２１、Ｈ．２２３が存在する。これらの符号化方式によるデータ量の圧縮効果は極めて高いが、不安定な伝送路上でデータを伝送することによるパケット損失や誤りの混入に対して脆弱である。これは、動画像符号化方式では前フレームとの差分フレームのみを送信していることに起因しており、データの一部が欠落することが、圧縮効果が高いが故に重大な問題になり得るからである。ＵＤＰやＲＴＰがデータ伝送に利用される場合、これらは基本的にデータの再送を行わないことから、この問題への対策が必要であるとされている。
【０００６】
画像符号化の中には、通常２つのモードが存在する。前述した前のフレームとの差分を送るフレーム間符号化モード（Ｐ Ｐｉｃｔｕｒｅ）と、１枚のフレームの中で閉じた符号化を行うフレーム内符号化モード（Ｉ Ｐｉｃｔｕｒｅ）である。通常のデータ伝送シーケンスでは、適当な時間間隔でフレーム内符号化モードとし、それらの間はフレーム間符号化モードとする。このフレーム内符号化モードでフレームを符号化する間隔をＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）間隔と呼ぶ。データの欠落が発生しある復号画像が壊れてしまった場合、それ以降、フレーム間符号化モードで符号化を行っていると、壊れた画像をもとに復号を行うため、以降の復号画像全てが影響を被り、正しく復号できないことになる。そこで、フレーム内符号化モードで符号化されたフレームを途中に挿入することで、誤りの影響の伝播をそこで断ち切るようにしている。ただし、フレーム内符号化モードは、フレーム間符号化モードに比べて符号量を必要とするため、同じビットレートでＧＯＰ間隔を短くすると画質が低下するため、誤りの発生率に応じて適切なＧＯＰ間隔になるように制御を行う必要がある。
【０００７】
また、ＵＤＰはＴＣＰのような輻輳制御機能を備えていないことから、ＵＤＰを用いた画像伝送アプリケーションでは常にネットワークの帯域を越えないような伝送レートでデータを送受信する必要がある。例えば、リアルタイム性が求められるデータを通信路の帯域を越える高い送信レートで送信すると、ネットワーク上のルータなどのバッファに送信したデータが蓄積され（輻輳）、これにより伝送遅延が大きくなる。さらに、バッファの許容量を超えるデータが送信されると、輻輳が限界を超えてバッファが溢れてしまい、パケットロスが生じるなどの障害が発生する。
【０００８】
これらの誤りや輻輳への対策を講じた従来技術として、ＲＴＣＰを利用し受信側からのパケットロス率やジッタなどの情報をＲＴＣＰレポートから得て、これに基づき伝送レートや誤り耐性のパラメータを送信側で制御するものがある（例えば、下記特許文献１を参照。）。
【０００９】
また、伝送路使用帯域の節約のためには、マルチキャストと呼ばれるパケット送信技術が有効であるとされている。インターネットでのパケット送信方法には、ユニキャスト、マルチキャスト、ブロードキャストがある。ユニキャストでは、送信元から、データを要求した各クライアントにそのコピーがそれぞれ送信される。ブロードキャストでは、ネットワーク上のすべてのクライアントに１つのデータのコピーが送信される。これに対しマルチキャストでは、データを要求したクライアント群に、データのコピーが１つのみ送信される。近年、伝送路の広帯域化が進んでいるものの、多数のクライアントに向けて同一のコンテンツを伝送する場合、伝送路を効率的に使用することが必要であり、このためにマルチキャストが有効である。
【００１０】
しかし、受信側から得られるパケットロス率やジッタの情報に基づき、送信側で送信レートおよびＧＯＰ間隔の制御を行うことを考えた場合、ＲＴＣＰレポートは各受信側から個別に送信されることから、すべてのＲＴＣＰレポートに対して処理を行うとすると、送信側に極めて高い処理負担がかかってしまう。また、クライアントが多くなるほどＲＴＣＰレポートの送信数も増えることから、帯域が浪費されることも問題である。
【００１１】
これらの問題を解決するために、各クライアントからのＲＴＣＰレポートを集約し、送信レートおよびＧＯＰ間隔の制御を、最も通信環境の悪いクライアントからのＲＴＣＰレポートを基準にして行うことが考えられる。しかし、マルチキャストにおいては送信側から送信されるストリームは一つであるから、良好な通信環境に居るクライアントが存在するにもかかわらず、伝送するデータの品質を下げることになり、好ましくない。反対に、最も通信環境の良好なクライアントからのＲＴＣＰレポートを基準にする場合、悪い通信環境に居るクライアントは正常にデータを受信することができなくなる。
【００１２】
このようなクライアント側の通信環境の多様性を考慮したデータ伝送を可能にする従来技術の一つに階層化マルチキャストがある（例えば、下記特許文献２を参照。）。この階層化マルチキャストでは、１つのストリームのデータを分割して階層に振り分けるとともに、階層に応じて異なるマルチキャストグループに分割されたストリームデータを配信する。それぞれ通信環境が異なる各クライアントは、ネットワークの状態に応じて各々がデータを受信する階層を制御する。これにより、受信レートの分散的な制御が実現される。階層化マルチキャストにおいて、サーバは例えば１つのストリームデータをフレーム内符号化されたフレームのみを含む階層と、フレーム間符号化されたフレームのみを含む階層の２つの階層に分割する。この分割された階層をさらにフレームの低周波成分のみを含む階層と、フレームの高周波成分のみを含む階層とに分割する場合もある。
【００１３】
【特許文献１】
特開２００２―２０４２７８公報
【００１４】
【特許文献２】
特開２０００−７８５７３公報
【００１５】
【発明が解決しようとする課題】
上記のような階層化マルチキャスト方式では、有線ネットワークにおける伝送帯域を有効に利用するとともに多様なクライアントに対する品質管理を行うことができる。しかしながら、サーバ側における階層符号化の処理負荷およびクライアント側における復号化の処理負荷の双方が、階層化を行わない場合に比べて極めて高いという問題点がある。また、誤り耐性に対するパラメータの制御が行えないことや、帯域に余裕がないクライアントでは１本のストリームの分割された階層の一部のみを受信することになり、フレームレートが落ちて見難い画像を受信することになる可能性、高周波成分を含む階層を受信できずに復号化の際にミスマッチが生じ、正しく復号が行えずに画質が低下する可能性、などが問題点として挙げられる。
【００１６】
本発明は、送信側装置および受信側装置の双方の処理負荷を高めることなく、受信側装置が置かれている多様な伝送環境に対して適応的なデータ伝送を実現することのできる装置、および方法を提供することを目的とする。
【００１７】
【課題を解決するための手段】
本発明の一観点に係わるデータ送信装置は、データ信号を入力する入力手段と、前記データ信号を第１、第２の符号化パラメータを用いて符号化して第１、第２の符号化データストリームを生成する符号化手段と、前記第１の符号化データストリームをパケット化して第１のマルチキャストアドレスに送信するとともに、前記第２の符号化データストリームをパケット化して第２のマルチキャストアドレスに送信するパケットデータ送信手段と、前記第１、第２の符号化パラメータを前記第１、第２のマルチキャストアドレスを含む送信パラメータに対応付けて表すパラメータデータをデータ受信装置からの要求に応じて送信するパラメータ送信手段と、を具備する。
【００１８】
また本発明の他の観点に係るデータ受信装置は、同一のデータ信号を第１、第２の符号化パラメータを用いて符号化して生成された第１、第２の符号化データストリームのそれぞれの符号化パラメータを第１、第２のマルチキャストアドレスを含む送信パラメータに対応付けて表すパラメータデータを受信するパラメータ受信手段と、前記パラメータデータに基づいて前記第１、第２のマルチキャストアドレスのいずれか一方を選択するアドレス選択手段と、前記アドレス選択手段により選択されたマルチキャストアドレスに対応する前記第１、第２の符号化データストリームのいずれか一方のパケットデータを受信するパケットデータ受信手段と、前記パケットデータ受信手段により受信されたパケットデータを復号して前記データ信号を再生するデータ再生手段と、を具備する。
【００１９】
【発明の実施の形態】
以下、図面を参照しながら本発明の実施形態を説明する。
【００２０】
（第１の実施形態）
本発明の実施形態は、動画像データの伝送をマルチキャストで行うデータ伝送システムに関する。本システムにおいて、動画像データを送信するデータ送信装置を「サーバ」又は「送信側」と呼ぶ。この装置は、ある動画像の画像信号を異なる符号化パラメータで符号化して構築された複数のストリームを、異なるマルチキャストアドレスに、例えばＲＴＰなどのプロトコルを用いて配信する。また、動画像データを要求し、データ送信装置から受信するデータ受信装置を「クライアント」又は「受信側」と呼ぶ。この装置は、パケットの遅延や損失などの情報から通信路の状態を判定し、送信側から送信される複数のストリームの中から通信路の状態に適切な符号化パラメータのストリームを１つ選択し、マルチキャストアドレスから受信する。
【００２１】
図１は、本発明の第１の実施形態に係るデータ伝送システムの全体構成を示すブロック図である。このデータ伝送システムは、データの配信装置である少なくとも１つのサーバ２０００と、サーバ２０００から転送されるコンテンツデータ（ここでは動画像）を受信して再生する少なくとも１つ以上のクライアント１０００ａ〜１０００ｄから構成されている。サーバ２０００とクライアント１０００ａ〜１０００ｄはネットワーク３０００を介して接続されている。サーバ２０００は、１つ以上のデータストリームＳ１〜Ｓ３をそれぞれ異なるマルチキャストアドレスグループにネットワーク３０００を介してマルチキャストで送信する。クライアント１０００ａ〜１０００ｄはデータストリームＳ１〜Ｓ３の中から、それぞれの通信路の状態に応じたデータストリームを選択して受信する。また、クライアント１０００ａ〜１０００ｄは、それぞれの通信路の状態変化に応じて、動的に受信するデータストリームを変更する。
【００２２】
図２は、サーバの内部構成を示すブロック図である。サーバ２０００は、図２に示すように、例えばビデオカメラで撮影された映像（動画像）の画像信号を入力する画像入力部２１００と、画像入力部２１００から得られる画像信号２００６を異なるパラメータで符号化する画像符号化部２４００ａ〜２４００ｃと、画像符号化部２４００ａ〜２４００ｃが出力する符号化データ２００５ａ〜２００５ｃをパケット化し、パケット化された符号化データ２００４ａ〜２００４ｃのそれぞれを異なるマルチキャストアドレスに送信するパケットデータ送信部２２００と、少なくとも１つの画像符号化部２４００ａ〜２４００ｃから得られるそれぞれ異なる符号化パラメータ２００１と、パケットデータ送信部２２００がそれぞれの符号化データをパケット化して送信する際の例えば送信先マルチキャストアドレスなどを含む送信パラメータ２００２との対応が記述されたパラメータデータ２００３を送信するパラメータ送信部２３００からなる。
【００２３】
本実施形態ではパケットの送信に用いるプロトコルとしてＵＤＰ／ＩＰおよびＲＴＰを用いることとするが、これらに限るものではない。この図２に示すサーバは、例えばライブ放送システムに好適である。
【００２４】
このように構成されたサーバ２０００では、まず画像入力部２１００から画像信号２００６が入力される。この入力された画像信号２００６は、画像符号化部２４００ａ〜２４００ｃでそれぞれ符号化される。この符号化の際、画像符号化部２４００ａ〜２４００ｃは、それぞれ別の符号化パラメータを用いて符号化を行う。例えば、２４００ａは、ＧＯＰ間隔２ｓ、ビットレート１２８ｋｂｐｓで符号化し、２４００ｂはＧＯＰ間隔０．５ｓ、ビットレート１２８ｋｂｐｓで符号化し、２４００ｃはＧＯＰ間隔２ｓ、ビットレート６４ｋｂｐｓで符号化する。ここで、画像符号化部は図２の場合３つであるが、１つ以上であればいくつでもかまわない。画像符号化部の数に応じて、出力される符号化データの数も変化する。
【００２５】
パケットデータ送信部２２００では、画像符号化部２４００ａ〜２４００ｃの各々が出力した符号化データ２００５ａ〜２００５ｃを、それぞれパケット化して伝送する。このときの伝送先のアドレスは、それぞれの符号化データに対し、異なるマルチキャストアドレスとする。すなわち、例えば符号化データ２００５ａはパケット化された後、マルチキャストアドレス「２２４．１．１．１」に送信され、符号化データ２００５ｂはパケット化された後マルチキャストアドレス「２２４．１．１．２」に送信され、符号化データ２００５ｃはパケット化された後マルチキャストアドレス「２２４．１．１．３」に送信される。またこれらのパケットデータには、例えば伝送プロトコルとしてＲＴＰを用いる場合、異なるペイロード番号を付与して送信することも可能である。例えば、パケットデータ２００４ａにはペイロード番号９６を付与して送信し、パケットデータ２００４ｂにはペイロード番号９７を付与して送信し、パケットデータ２００４ｃにはペイロード番号９８を付与して送信する。
【００２６】
パラメータ送信部２３００では、前述のパケットデータ送信部２２００で送信されるパケットデータ２００４ａ〜２００４ｃのそれぞれの符号化パラメータと、送信時のマルチキャストアドレスやペイロード番号などの対応が記述されたパラメータデータ２００３を送信する。パラメータ送信部２３００では、画像符号化部２４００ａ〜２４００ｃが符号化を行う際のＧＯＰ間隔やビットレートなどの符号化パラメータ２００１と、パケットデータ送信部２２００が各符号化データ２００５ａ〜２００５ｃをパケット化し、送信する際の送信先マルチキャストアドレスやペイロード番号などの送信パラメータ２００２を対応づけたパラメータデータ２００３を送信する。このデータ２００３は、あらかじめ作成されたものを用意しておき、画像符号化部２４００およびパケット送信部２２００がこのデータを参照して符号化パラメータの設定およびパケットの送信パラメータの設定を行うことも可能である。
【００２７】
ここで、パラメータ送信部２３００が送信するパラメータデータの例を図３に示す。パラメータデータは例えば、少なくとも１つの符号化データの１つを識別するためのＳｔｒｅａｍＮｏと、該符号化データをパケット化し送信する際の送信先ＩＰ Ａｄｄｒｅｓｓと、該符号化データのＧＯＰ間隔と、該符号化データの送信レートと、例えばＲＴＰを用いて伝送する場合のペイロード番号などを対応づけるデータである。図３の例では、ＳｔｒｅａｍＮｏが１の符号化データは、ＧＯＰ間隔２秒、符号化レート１２８ｋｂｐｓで符号化されたデータであり、ペイロード番号９６番を用いてマルチキャストアドレス「２２４．１．１．１」に送信されることがわかる。図３では、ＳｔｒｅａｍＮｏ１，２，３が例えばパケットデータ２００４ａ、２００４ｂ、２００４ｃに対応するパラメータとなっている。図３は符号化パラメータと送信パラメータの対応を示す一例であるが、このような対応を記述可能な規格として例えばＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ）などがあり、ＳＤＰで記述されたデータを用い、符号化パラメータと送信パラメータの対応が記述されたデータを送信することも可能である。
【００２８】
図４は、サーバの他の構成例を示すブロック図である。このサーバ２０００は、図４に示すように、同一の画像信号をあらかじめ異なるパラメータで符号化した少なくとも１つの符号化データ２６１０ａ〜２６１０ｃを格納する符号化データ格納部２６００と、少なくとも１つの符号化データ２６１０ａ〜２６１０ｃの符号化パラメータを格納する符号化情報格納部２５００と、符号化データ格納部２６００から、符号化データ２６１０ａ〜２６１０ｃのうち、符号化情報格納部２５００より得られる符号化パラメータ２００１に対応する符号化データを読み出す少なくとも１つの符号化データ読み出し部２７００ａ〜２７００ｃと、符号化データ読み出し部２７００ａ〜２７００ｃが出力する符号化データ２００５ａ〜２００５ｃをパケット化するとともにそのパケット化された符号化データ２００４ａ〜２００４ｃを異なるマルチキャストアドレスに送信するパケットデータ送信部２２００と、符号化情報格納部２５００から得られる符号化パラメータ２００１と、パケットデータ送信部２２００がそれぞれの符号化データをパケット化して送信する際の例えば送信先マルチキャストアドレスなどを含む送信パラメータ２００２との対応を記述したパラメータデータ２００３を送信するパラメータ送信部２３００とにより構成される。
【００２９】
ここで、符号化データ２６１０ａ〜２６１０ｃは、同一の画像信号を異なる条件で符号化したものである。例えば２６１０ａは、ＧＯＰ間隔２ｓ、ビットレート１２８ｋｂｐｓで符号化され、２６１０ｂはＧＯＰ間隔０．５ｓ、ビットレート１２８ｋｂｐｓで符号化され、２６１０ｃはＧＯＰ間隔２ｓ、ビットレート６４ｋｂｐｓで符号化されたものである。図４では、あらかじめ異なる符号化パラメータで符号化したデータは３つであるが、１つ以上ならいくつあってもかまわない。これらの符号化データ２６１０に対応する例えばＧＯＰ間隔やビットレートなどの符号化パラメータと、その格納場所を記述したデータを符号化情報格納部２５００は保持する。
【００３０】
このような構成のサーバ２０００では、符号化データ読み出し部２７００ａ〜２７００ｃが符号化データ格納部２６００に格納されている符号化データを読み込む。この際、符号化データ読み出し部２７００は、符号化データ格納部２６００より、符号化情報格納部２６００に格納されている符号化データ２６１０ａ〜２６１０ｃの符号化パラメータおよびその格納場所が記述されたデータ２００１から格納場所を参照し、読み出しを行う。ここで、符号化データ読み出し部２７００は、図４の場合３つであるが、１つ以上であればいくつあってもかまわない。
【００３１】
符号化データ読み出し部２７００ａ〜２７００ｃで読み出された符号化データ２００５ａ〜２００５ｃがパケット送信部２２００によってパケット化され送信される方法については、図２に示したサーバと同様である。
【００３２】
パラメータ送信部２３００では、前述のパケットデータ送信部２２００で送信されるパケットデータ２００４ａ〜２００４ｃのそれぞれの符号化された際の符号化パラメータと送信される際の例えばマルチキャストアドレスやペイロード番号などの対応を記述したパラメータデータ２００３を送信する。パラメータ送信部２３００では、符号化データ２６１０ａ〜２６１０ｃが符号化された際のＧＯＰ間隔やビットレートなどの符号化パラメータ２００１と、パケットデータ送信部２２００が各符号化データ２００５ａ〜２００５ｃをパケット化し、送信する際の送信先マルチキャストアドレスやペイロード番号を対応づけたデータを送信する。パラメータデータ２００３は、例えば図３で示すようなデータである。
【００３３】
この図４のサーバは、例えば撮影済みの放送番組などの視聴コンテンツをあらかじめ符号化して蓄積しておき、クライアントから要求されたコンテンツのデータを配信するコンテンツ配信システムに好適である。
【００３４】
なお、図４の構成において、前述の符号化データ格納部２６００及び符号化情報格納部２５００はコンピュータの主記憶に存在してもよいし、フラッシュメモリやハードディスクなどの記憶媒体に存在してもよいし、また他のサーバ上にに存在してもよい。
【００３５】
また、図４に示された構成要素のうち、符号化情報格納部２５００、符号化データ格納部２６００、および符号化データ読み出し部２７００を、図２の構成に追加してもよい。この場合、（１）ビデオカメラ等からの入力を符号化して配信する、（２）あらかじめ符号化されたデータを配信する、（３）あるいは双方を同時に行う、といったデータ配信形態をユーザが必要に応じて選択可能にする機能を実現できる。
【００３６】
次に、クライアント１０００の構成について説明する。図５はクライアント１０００の基本的な構成を示すブロック図である。クライアント１０００は、図１に示したサーバ２０００が送信するパラメータデータ１６０１を受信するパラメータデータ受信部１１００と、サーバ２０００が送信するパケット化された符号化データ１６０２を受信するパケットデータ受信部１３００と、パケットデータ受信部１３００が解析したパケット情報１６０４からネットワークの状態を判定し、パラメータデータ受信部１１００が受信したパラメータデータ１６０１から得られる受信の選択肢となるパラメータの候補データ１６０３より現在のネットワークの状態に適切な符号化データのパラメータ１６０５を選択し、パケットデータ受信部１３００に通知するネットワーク状態判定部１２００と、パケットデータ受信部１３００から得られる符号化データ１６０６を復号する画像復号部１４００と、復号された画像信号１６０７を出力する画像出力部１５００から構成される。
【００３７】
このような構成のクライアント１０００では、あらかじめ、パラメータデータ受信部１１００において、サーバ２０００が送信する少なくとも２つ以上のデータストリームのＧＯＰ間隔やビットレートなどの符号化パラメータと、送信先マルチキャストアドレスやペイロード番号などの送信パラメータとを対応づけたパラメータデータ１６０１を受信しておき、ネットワーク状態判定部１２００に渡す。
【００３８】
ネットワーク状態判定部１２００では、該パラメータデータよりサーバから配信される少なくとも２つ以上のデータストリームのパラメータデータより１つのデータストリームのパラメータデータを選択し、パケットデータ受信部１３００に通知する。ここで、ネットワーク状態判定部１２００において、最初に受信するデータストリームのパラメータを選択する方法は、例えば一番ＧＯＰ間隔が長い、あるいは短いストリームを選択したり、一番ビットレートの高い、あるいは低いストリームを選択したり、あらかじめ通信路の帯域がわかっている場合には、その帯域以下で一番高いビットレートの高いストリームを選択したり、あるいはパラメータデータにデフォルトのストリームのパラメータを記述しておいて、それに該当するストリームを選択するなど、さまざまな方法が考えられるが、ここに挙げたものに限るものではなく、どれか１つのストリームを選択する方法であれば何でもよい。
【００３９】
パケットデータ受信部１３００は、ネットワーク状態判定部１２００において選択されたパラメータに記述されたマルチキャストアドレスから選択されたストリームデータパケットの受信を開始する。ストリームデータパケットの受信を行う方法としては、該データストリームが配信されているマルチキャストグループのマルチキャストアドレス宛てに受信宣言（ＪＯＩＮ）を行う（例えば、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）に従う）ことが一般的である。
【００４０】
パケットデータ受信部１３００により受信されたパケットデータ１６０２に含まれる符号化データ１６０６（符号化データおよびタイムスタンプなどの時刻情報）は、画像復号部１４００に渡され、画像信号１６０７に復号されたのち、表示装置などの画像出力部１５００に出力される。
【００４１】
また、パケットデータ１６０２に含まれるシーケンス番号や到着時刻より導かれる遅延情報（ジッタ）などを含むパケット情報１６０４は、ネットワーク状態判定部１２００に渡される。ネットワーク状態判定部１２００は、このパケット情報を用いて通信路の状態を判断し、その状態に適したパラメータをもつデータストリームを選択し、パケットデータ受信部１３００に切り替えを行うよう切り替え情報１６０５を通知する。
【００４２】
図６は、ネットワーク状態判定部１２００において、パケット情報を用いて通信路の状態を判断し、その状態に適したパラメータをもつデータストリームを選択する処理の一例を示すフローチャートである。通信路の状態は、例えばＲＴＰを用いて通信を行っている場合には、パケットの損失はパケット受信部１３００より得られるパケット情報１６０４に含まれるシーケンス番号の不連続性から導かれる。また、遅延については、パケット情報１６０４に含まれる送信時刻と、パケットの到着時刻から導かれる。
【００４３】
この例では、まずＳ９００１において、パケット情報から通信路が輻輳しているかどうかを判断する。一般に、通信路が輻輳している場合は遅延が生じるため、例えば、ある時点で到着したパケットの遅延ｄおよび遅延の閾値ｄｔｈを用いて、
ｄ ＞ｄｔｈ （１）
を満たすならば、通信路は輻輳していると判断して、処理Ｓ９００２に進む。
【００４４】
また、輻輳を判断する方法として、パケットの遅延の値は急激に変動する場合もあるため、その値を吸収する目的でジッタを用いる方法も考えられる。例えば、ある時点で到着したパケットのジッタｊおよびジッタの閾値ｊｔｈを用いて、
ｊ＞ｊｔｈ （２）
を満たすならば、通信路は輻輳していると判断し、処理Ｓ９００２に進む。ジッタの求め方については、例えばＲＦＣ１８８９を参考にすることができる。
【００４５】
また、ジッタｊの値も急激に変動する場合には、さらにこの値にローパスフィルタを適用した平均ジッタＪ＝ ｋｊ ＋ （１ − ｋ）Ｊｐｒｅｖ （ｋは０＜ｋ＜１の実数値、Ｊｐｒｅｖは前回に計算された平均ジッタ）と、平均ジッタの閾値Ｊｔｈを用いて、
Ｊ＞Ｊｔｈ （２’）
を満たすならば、通信路は輻輳していると判断し、処理Ｓ９００２に進む。
【００４６】
また、輻輳が進むと、ネットワーク上のルータなどのバッファに送信したデータが蓄積されて伝送遅延が大きくなり、さらにその後バッファの許容量を超えるデータが送信されるとバッファが溢れパケット損失が生じることが考えられるため、ある一定区間のパケット損失率を輻輳の判定に用いる方法も考えられる。例えば、ある一定区間のパケット損失率Ｌおよび、パケット損失率の閾値Ｌｔｈを用いて、
Ｌ＞Ｌｔｈ（３）
を満たすならば、通信路は輻輳していると判断し、処理Ｓ９００２に進む。パケット損失率の求め方については、例えばＲＦＣ１８８９を参考にすることができる。
【００４７】
なお、ここで挙げた輻輳判定方法については一例であり、例えば、式（１）や式（２）（２’）の閾値を定数ではなく、受信しているストリームのビットレートに応じて変化する値を用いたり、例えば、式（１）と式（２）あるいは（２’）と式（３）を同時に満たす場合に輻輳と判定したり、また他の式を用いるなど、さまざまな判定方式をネットワークにあわせて設定することが可能である。
【００４８】
また、この輻輳判定の処理Ｓ９００１においては、ネットワーク状態判定部１２００を図７のように発展させて、ネットワークの情報格納部１２２０を設け、過去のパケット情報１６０４をネットワーク情報格納部１２２０に蓄積しておき、ネットワーク情報判定部１２１０は過去のパケット情報１２１１と現在のパケット情報１６０４から、通信路状態の時間的な推移を判断することも可能である。例えば、過去に起こったパケット損失情報を格納しておき、例えば連続して式（３）を満たした回数Ｌｃｏｕｎｔと閾値Ｌｃｏｕｎｔ＿ｔｈを用いて輻輳を判断する方法も考えられる。この場合は、例えば、
Ｌｃｏｕｎｔ＞Ｌｃｏｕｎｔ＿ｔｈ（４）
を満たすならば、通信路は輻輳していると判断し、処理Ｓ９００２に進む。
【００４９】
この方法は、特に無線などでデータ伝送を行う場合は、パケット損失は輻輳が原因で起こる場合のみならず、回線上にノイズのようなものが発生し、データを破壊した結果、その誤りがパケット損失としてあらわれる可能性がある場合に、ある一定区間のパケット損失率のみでは、誤りによるパケット損失を輻輳と判断してしまうのを防ぐことが可能である。
【００５０】
逆に、例えば少し輻輳しているような状況において、（３）式におけるＬｔｈを超えない少量のパケット損失がある場合、（３）式や（４）式のみでは輻輳と判断しない可能性もある。このような場合には、ネットワーク上の中継装置のバッファにおいて、ランダムにパケットが廃棄されていると考えられるため、その廃棄によりジッタの値にある程度の変動が生じる。これを用いて、例えば過去の平均ジッタをネットワーク情報格納部１２２０に蓄積しておき、前回の平均ジッタＪｐｒｅｖと、今回の平均ジッタＪｎｏｗの変動値Ｊｄｅｌｔａ＝Ｊｐｒｅｖ−Ｊｎｏｗが、ジッタの変動値の閾値Ｊｄｅｌｔａ＿ｔｈを超えた場合、すなわち
Ｊｄｅｌｔａ＞Ｊｄｅｌｔａ＿ｔｈ（５）
を満たすならば輻輳であると判断し、処理Ｓ９００２に進む。
【００５１】
また、伝送路において発生する誤りに対し、ネットワーク層での再送が行われている場合には、クライアントでは大幅な遅延として観測され、結果的にジッタの変動となり、再送を輻輳と誤って判断してしまう。従ってこのような場合はジッタではなく、例えば、パケットの遅延ｄとパケットの到着間隔ｉの積ｒｉ ＝ ｄ×ｉの移動平均ＲＩ＝ ｋ・ｒｉ ＋ （１ − ｋ）ｒｉｐｒｅｖ （ｋは０＜ｋ＜１の実数値、ｒｉｐｒｅｖは前回に計算されたｒｉの移動平均）を用いて再送による遅延の変動をパケット到着間隔によって吸収した値を指標として用いてもよい。ただし、この指標によって輻輳を判断する場合の閾値をあらかじめ取得する必要があり、この取得方法の一例を以下に述べる。まず、受信開始時にネットワーク状態判定部１２００において始めに受信するストリームを選択する際、輻輳する可能性のきわめて低い、一番レートの低いストリームのパラメータを選択しパケットデータ受信部１３００に通知する。次にパケットデータ受信部１３００は、ネットワーク状態判定部１２００において選択されたパラメータに記述されたマルチキャストアドレスから選択されたストリームデータパケットの受信を開始し、開始後Ｎ個のパケットのｒｉの平均値ｒｉ＿ｔｈを計算し、ネットワーク状態判定部１２００に通知し、この値を輻輳判定の閾値として使用する。ＲＩがｒｉ＿ｔｈのγ倍以上であった場合、すなわち
ＲＩ ＞ ｒｉ＿ｔｈ×γ（γ＞１の実数）（６）
を満たすような場合に輻輳であると判断し、処理Ｓ９００２に進む。閾値を取得した後は帯域を有効に利用するため、現在選択しているレートより一段高いレートのストリームのパラメータに切り替えるための切り替え情報１６０５をパケット受信部１３００に通知し、後述の切り替え処理によって、レートを回復させる処理を（６）式によって輻輳と判断されるまで、あるいは選択できるパラメータのうち一番高いレートになるまで繰り返し行ってもよい。
【００５２】
このように、図７の構成を用いることにより、より正確に輻輳を判定することができる。
【００５３】
次に処理Ｓ９００２において、現在選択しているデータストリームのビットレート未満で最大のビットレートの受信パラメータを選択する。ここで、この条件を満たすパラメータデータが複数であった場合には、どれか一つを選択するが、その選択方法は、例えばＧＯＰ間隔が一番短いものを選択するといった方法が考えられるがこれに限るものではない。ただし、後述の切り替え処理を考慮すると、ＧＯＰ間隔の短いものの方が望ましい。その理由については後述する。
【００５４】
図３の例を用いて説明する。現在ＳｔｒｅａｍＮｏ．３のストリーム（６４ｋｂｐｓ）を受信している場合には、６４ｋｂｐｓ未満で最大のビットレートを持つストリームはＳｔｒｅａｍＮｏ．５および６であるが、このうち、ＧＯＰ間隔の一番短いものとして、ＳｔｒｅａｍＮｏ．６が選択される。
【００５５】
次に処理Ｓ９００３において、選択されたストリームの受信パラメータを切り替え情報１６０５として、パケット受信部１３００に通知する。
【００５６】
一方、処理Ｓ９００２において、輻輳でないと判断された場合には、ストリームの変更は行わず、終了する。
【００５７】
パケット受信部１３００では、切り替え情報１６０５を渡されると、切り替えの処理を行うが、この処理の一例を示したものが図８である。図８の処理Ｓ１０００１において、まず、受信を行っているデータストリームのパケットの受信を終了する。データストリームのパケットの受信を終了する方法としては、該データストリームが配信されているマルチキャストグループのマルチキャストアドレス宛てに受信終了宣言（ＬＥＡＶＥ）を行う（例えば、ＩＧＭＰ（Ｉｎｔｅｒｎｅｔ Ｇｒｏｕｐ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）に従う）ことが一般的である。次に処理Ｓ１０００２に進み、前述の選択されたデータストリームのパケットの受信を開始する。この方法は、例えば該データストリームのパケットが送信されているマルチキャストアドレスにＪＯＩＮを送信する方法がある。前述の例を用いてこの切り替え処理を説明すると、ＳｔｒｅａｍＮｏ．３のデータストリームのパケットが送信されているマルチキャストアドレス「２２４．１．１．３」に対し、ＬＥＡＶＥを送信した後、ＳｔｒｅａｍＮｏ．６のデータストリームのパケットが送信されているマルチキャストアドレス「２２４．１．１．６」に対しＪＯＩＮを送信することで切り替えを行うことができる。ここで、ＪＯＩＮを送信した後に初めて到着するＳｔｒｅａｍＮｏ．６パケットデータは、フレーム内符号化モード（Ｉ ｐｉｃｔｕｒｅ）のデータを含むパケットであるとは限らないため、切り替えを行ってから初めてフレーム内符号化モードのパケットを受信するまでは正常に復号できない。なぜなら、フレーム間符号化（Ｐ ｐｉｃｔｕｒｅ）では、前の画像との差分を符号化しているため、切り替える前のストリームの最後のフレームを用いて復号しようと試みるからである。この正常に復号できない時間を短くするためには、受信を開始したストリームが、ＧＯＰ間隔の短いデータストリームであることが効果的であり、これが、前述の選択を行う際にＧＯＰ間隔の短いものの方が望ましい理由である。しかし、ここで挙げた切り替えの方法は一例であり、先にＪＯＩＮを行ったのちにＬＥＡＶＥを行うということも考えられ、ネットワークに適した方法を設定することが可能である。この切り替え方法の他の例については、後述する。
【００５８】
なお、この選択の処理は、通信路の状態の変化に追随するため、例えばある一定の時間ごとに行うなど、繰り返し行われる。
【００５９】
以上説明した第１の実施形態によれば、通信路の状態から動的に受信するマルチキャストアドレスを切り替えることにより、符号化パラメータの異なるストリームを受信することで、各受信者がそれぞれの環境に応じたストリームを効率よく受信することができる。
【００６０】
また、通信路の帯域が不明の場合や、途中で変化した場合でも、受信側でパケット情報などから通信路の状態を判断し、何らかの原因で通信路上で輻輳が起こった場合にビットレートを落としたストリームに切り替えることによって、輻輳によるパケット損失を抑制し、パケット損失による画像データの破壊を防止して通信を行うことができる。また、これらの処理は各クライアントごとに行われるため、サーバ側の制御負荷を軽減することができる。
【００６１】
また、あるクライアントの通信路上のみで輻輳が起こっているような場合でも、そのクライアントのみがビットレートの低いストリームに切り替えることが可能となるので、各クライアントごとに、それぞれの通信路の状態に適したストリームを提供することが可能になる。
【００６２】
（第２の実施形態）
第２の実施形態は、第１の実施形態の図１，図２，図４，図５，および図７に示したものと共通の構成を有する。ただし、図５のネットワーク判定部１２００におけるネットワークの状態判定とストリームパラメータの選択の処理において、通信路上の輻輳のみならず、ノイズなどが原因で発生するデータ誤りも考慮する点で第１の実施形態と異なる。
【００６３】
図９は、ネットワーク状態判定部１２００において、パケット情報を用いて通信路の状態を判断し、その状態に適したパラメータをもつデータストリームを選択する処理の一例を示すフローチャートである。このフローチャートにおいて、まず処理Ｓ９００１における輻輳の判定では、第１の実施形態と同様の方法を用いる。また、処理Ｓ９００１において輻輳していると判断された場合の処理Ｓ９００２も第１の実施形態と同様である。
【００６４】
処理Ｓ９００１において、輻輳と判断されなかった場合、本実施形態では、処理Ｓ９００４において、パケット損失があるかどうかを判断する。パケット損失があるかどうかの判断は、例えばパケット受信部１３００から得られるパケット情報１６０４に含まれるパケットのシーケンス番号が連続していない場合に損失ありと判断できる。輻輳と判断されなかったにもかかわらず、パケット損失がある場合には、何らかの原因により通信路上で誤りが発生したと判断し、処理Ｓ９００５において、パラメータデータ１６０１より例えば現在受信中のパラメータと同じビットレートのストリームのうち、一番ＧＯＰ間隔の短いパラメータを持つデータストリームを選択する。図３のパラメータデータ例を用いて例を説明すると、現在ＳｔｒｅａｍＮｏ．３のストリームを受信している場合には、同じビットレート（６４ｋｂｐｓ）でもっともＧＯＰ間隔の短いＳｔｒｅａｍＮｏ．４のストリームが選択される。
【００６５】
ここで、処理Ｓ９００４では、パケット損失があるかどうかの判断をシーケンス番号を用いて行ったが、少量のパケット損失がそれほど画像の再生に影響を与えないような場合には、パケット損失率Ｌを用いてもよい。この場合は、例えばパケット損失率の閾値Ｌｅｒｒｏｒ＿ｔｈ（＜Ｌｔｈを用いて、例えば、
Ｌｅｒｒｏｒ ＞ Ｌｅｒｒｏｒ＿ｔｈ（７）
を満たす場合に損失ありと判断することも考えられる。
【００６６】
ストリームの変更を行う場合に、それをパケット受信部１３００に通知する処理Ｓ９００３およびパケット受信部１３００における切り替え処理については、第１の実施形態と同様である。
【００６７】
最後に、処理Ｓ９００４において、パケット損失が発生しなかった場合には、通信路の状態は良好と判断し、その後の処理は何も行わない。
【００６８】
また、この選択の処理は、通信路の状態の変化に追随するため、例えばある一定の時間ごとに行うなど、繰り返し行われることも、第１の実施形態と同様である。
【００６９】
なお、本実施形態では、図９における処理Ｓ９００１においてまず輻輳かどうかを判定しているが、帯域に変動がない場合や、帯域に十分な余裕があることを前提とし、同一のビットレートでＧＯＰ間隔のみが異なるの１つ以上のストリームを配信するような場合には、Ｓ９００１およびＳ９００２の処理を省き、処理Ｓ９００４のパケット損失判定のみを行うことで処理の軽減を行うことも可能である。
【００７０】
このような本発明の第２の実施形態によれば、輻輳のみならずノイズなどによるデータ誤りが原因で発生するパケット損失についてもその発生有無を判断することができ、誤りに対しては、ＧＯＰ間隔の短いストリームに切り替えることにより、ビットレートを下げることなくパケット損失による誤りの伝播を抑制することができるようになる。また、これらの処理は各クライアントごとに行われるため、サーバ側の制御負荷を軽減することができる。また、あるクライアントの通信路上のみで誤りが起こっているような場合でも、そのクライアントのみＧＯＰ間隔の短いストリームに切り替えることが可能なので、各クライアントごとに、それぞれの通信路の状態に適したストリームを提供することが可能である。
【００７１】
第１の実施形態や第２の実施形態では、通信路に輻輳や誤りが発生すると、ビットレートの低いストリームや、ＧＯＰ間隔の短いストリームに変更していたが、逆にビットレートの高いストリームやＧＯＰ間隔の長いストリームに変更することも可能である。そのような例を第３の実施形態および第４の実施形態に示す。
【００７２】
（第３の実施形態）
第３の実施形態は、第２の実施形態と同様に、第１の実施形態の図１，図２，図４，図５，および図７に示したものと共通の構成を有する。ただし、第３の実施形態では、図５のネットワーク判定部１２００におけるネットワークの状態判定において、誤りの発生が局所的であるような場合に、誤りが一定期間起こらない場合にはＧＯＰ間隔を長く回復させることができるよう構成される点で第２の実施形態と異なる。
【００７３】
図１０は、ネットワーク状態判定部１２００において、パケット情報を用いて通信路の状態を判断し、その状態に適したパラメータをもつデータストリームを選択する処理の一例を示すフローチャートである。このフローチャートにおいて、まず処理Ｓ９００１において輻輳を判定する方法は、第１の実施形態と同様の方法を用いる。また、処理Ｓ９００１において輻輳していると判断された場合の処理Ｓ９００２も第１、第２の実施形態と同様である。
【００７４】
処理Ｓ９００１において、輻輳と判断されなかった場合、本実施形態では、処理Ｓ９００４において、パケット損失があるかどうかを判断する。ここでのパケット損失の判定および、パケット損失があると判定された場合のＧＯＰ間隔を短くするストリーム選択処理Ｓ９００５は、第２の実施形態と同様である。
【００７５】
処理Ｓ９００４において、パケット損失が発生しなかった場合には、通信状態が良好であると判断し、処理Ｓ９００６〜Ｓ９００７において、ＧＯＰ間隔を回復しようと試みる。図１０の処理の例では、処理Ｓ９００３において、前回損失が検知された時刻と現時刻の差を損失が起きなかった時間Ｔとして計算し、この時間Ｔを用いて適切なＧＯＰ間隔Ｔ_ＧＯＰを計算する。これは例えば、次に示すような式（７）で計算することが可能である。
【００７６】
Ｔ_ＧＯＰ＝Ｔ×α （８）
ここで、αは感度係数であり、ＧＯＰ間隔の回復の感度を示す値である。αが小さければ、回復の感度は鈍くなり、αが大きければ回復の感度は鋭くなる。例えば、パケット損失が起こらなかった時間が４ｓであった場合に感度係数αの値が０．５であったとすると、Ｔ_ＧＯＰ＝４×０．５＝２ｓと計算される。
【００７７】
次に、Ｓ９００７において、現在受信中のストリームと同じビットレートで、かつＳ９００６で計算された適切なＧＯＰ間隔を超えない、もっとも近いＧＯＰ間隔のストリームを選択する。図３のパラメータデータ例および前述のＴ_ＧＯＰ＝２ｓを用いて例を説明すると、現在ＳｔｒｅａｍＮｏ．４のストリームを受信している場合には、同じビットレート（６４ｋｂｐｓ）で２ｓを超えない最も近いＧＯＰ間隔が２ｓであるＳｔｒｅａｍＮｏ．３のストリームが選択される。もしも、Ｔ_ＧＯＰ＝１ｓである場合には、引き続きＳｔｒｅａｍＮｏ．４のストリームが選択されることになる。
【００７８】
ストリームの変更を行う場合に、それをパケット受信部１３００に通知する処理Ｓ９００３およびパケット受信部１３００における切り替え処理については、第１、第２の実施形態と同様である。
【００７９】
この選択の処理は、通信路の状態の変化に追随するため、例えばある一定の時間ごとに行うなど、繰り返し行われることも、第１、第２の実施形態と同様である。
【００８０】
なお、本実施形態では、図１０における処理Ｓ９００１においてまず輻輳かどうかを判定しているが、帯域に変動がなく、同一のビットレートでＧＯＰ間隔のみが異なる１つ以上のストリームを配信するような場合には、はじめから処理Ｓ９００１およびＳ９００２を省き、処理Ｓ９００４のパケット損失判定のみを行うことで処理負荷を軽減することも可能である。
【００８１】
以上説明した本発明の第３の実施形態によれば、通信路上に誤りが発生し、ＧＯＰ間隔を短くすることでこれに対処した後に、通信路の状態が好転した場合に、ＧＯＰ間隔を長く回復させることができ、より品質のよいストリームを提供することが可能である。また、これらの処理は各クライアントごとに行われるため、サーバ側の制御負荷を軽減することができる。各クライアントごとに、それぞれの通信路の状態に適したストリームを提供することが可能である点は、第１、第２の実施形態と同様である。
【００８２】
（第４の実施形態）
第４の実施形態においても、第２、第３の実施形態と同様に、第１の実施形態において図１，図２，図４，図５，および図７に示したものと共通する構成を有する。第４の実施形態は、図５のネットワーク判定部１２００におけるネットワークの状態判定において、通信路の帯域に余裕があるかどうかを判断し、余裕がある場合にはビットレートの高いストリームを選択し、ビットレートを回復させることができる点で第３の実施形態とは異なる。
【００８３】
図１１は、ネットワーク状態判定部１２００において、パケット情報を用いて通信路の状態を判断し、その状態に適したパラメータをもつデータストリームを選択する処理の一例を示すフローチャートである。このフローチャートにおいて、まず処理Ｓ９００１において輻輳を判定する方法は、第１〜第３の実施形態と同様の方法を用いる。また、処理Ｓ９００１において輻輳していると判断された場合の処理Ｓ９００２も第１〜第３の実施形態と同様である。
【００８４】
処理Ｓ９００１において、輻輳と判断されなかった場合、処理Ｓ９００４において、パケット損失があるかどうかを判断する。ここでのパケット損失の判定および、パケット損失があると判定された場合のＧＯＰ間隔を短くするストリーム選択処理Ｓ９００５は第３の実施形態と同様である。
【００８５】
処理Ｓ９００４において、パケット損失がないと判断された場合、本実施形態では、処理Ｓ９００８において、帯域に余裕があるかどうかの判定を行う。この判定については、例えば、その時点での受信パケットの平均ジッタの値Ｊｎｏｗを帯域の余裕度とし、この平均ジッタの値Ｊｎｏｗが、十分小さい値の閾値Ｊｕｐ＿ｔｈを下回った場合、すなわち、
Ｊｎｏｗ＜Ｊｕｐ＿ｔｈ（９）
を満たす場合に帯域に余裕があると判断する。ただし、この帯域に余裕があるかどうかの判定方法は、これに限るものではなく、例えば、遅延ｄが十分小さい値であるかどうかを判定したり、また式（９）においてＪｕｐ＿ｔｈを受信しているストリームのビットレートに応じて変化する値を用いたり、受信しているストリームのビットレートｂｎｏｗの次にビットレートが高いストリームｂｕｐとのビットレートの差ｂｄｅｌｔａ＝ｂｎｏｗ − ｂｕｐに応じて変化する値を用いるなどの方法が考えられる。
【００８６】
また、伝送路において発生する誤りに対し、ネットワーク層での再送が行われている場合には、例えばその時点での受信パケットの遅延とパケットの到着間隔の積の移動平均ＲＩが、（６）式で用いた閾値ｒｉ＿ｔｈのδ倍を下回った場合、すなわち
ＲＩ ＜ ｒｉ＿ｔｈ×δ（１０）
を満たすような場合に帯域に余裕があると判断するなどの方法も考えられる。
【００８７】
処理Ｓ９００８において帯域に余裕があると判断された場合には、処理Ｓ９００９に進み、現在選択しているデータストリームのビットレートより大きく、最小のビットレートの受信パラメータを選択する。ここで、この条件を満たすパラメータデータが複数であった場合には、どれか一つを選択する。その選択方法は、例えばＧＯＰ間隔が一番短いものを選択するといった方法が考えられるがこれに限るものではない。ただし、前述のとおり、切り替え時に発生する正常に復号できない時間を短くするために、ＧＯＰ間隔の短いものの方が望ましい。図３の例を用いて説明する。現在ＳｔｒｅａｍＮｏ．３のストリーム（６４ｋｂｐｓ）を受信している場合には、６４ｋｂｐｓ未満で最大のビットレートを持つストリームはＳｔｒｅａｍＮｏ．１および２（１２８ｋｂｐｓ）であるが、このうち、ＧＯＰ間隔の一番短いものとして、ＳｔｒｅａｍＮｏ．２が選択される。
【００８８】
処理Ｓ９００８において、帯域に余裕がないと判断された場合には、ＧＯＰ間隔を回復しようと試みる処理を行うが、この処理Ｓ９００６およびＳ９００７は第３の実施形態と同様である。
【００８９】
ストリームの変更を行う場合に、それをパケット受信部１３００に通知する処理Ｓ９００３およびパケット受信部１３００における切り替え処理については、第１〜第３の実施形態と同様である。
【００９０】
この選択の処理は、通信路の状態の変化に追随するため、例えばある一定の時間ごとに行うなど、繰り返し行われることも、第１〜第３の実施形態と同様である。
【００９１】
なお、本実施形態では、図１１において通信路に誤りが発生しないと仮定し、同一のＧＯＰ間隔のみの１つ以上のストリームを配信するような場合には、処理Ｓ９００４、Ｓ９００５、および処理Ｓ９００６、Ｓ９００７を省き、処理Ｓ９００１において輻輳していない場合には処理Ｓ９００８に進めて、輻輳かどうかと帯域に余裕があるかどうかの判定のみを行うことで処理の軽減を行うことも可能である。
【００９２】
以上説明した本発明の第４の実施形態によれば、通信路の帯域に余裕があるかどうかを判定し、余裕がある場合には、ビットレートを高く回復させることができるため、帯域を無駄なく使用して品質のよいストリームを提供することが可能である。また、これらの処理は各クライアントごとに行われるため、サーバ側の制御負荷を軽減することができ、各クライアントごとに、それぞれの通信路の状態に適したストリームを提供することが可能であることは、第１〜第３の実施形態と同様である。
【００９３】
なお、第４の実施形態では、帯域に余裕があるかどうかの判定は行ったが、どれくらい余裕があるかの判定は行っていないため、ビットレートを回復させた結果、帯域をオーバーし、輻輳を招く可能性がある。さらに、選択処理を繰り返し行うことにより、ビットレートの回復と輻輳を繰り返し、逆に見づらい映像になってしまう可能性がある。このような現象を抑制するために、過去のストリームの切り替えの履歴に基づき、安定してストリームを提供できるようにした例を第５の実施形態で説明する。
【００９４】
（第５の実施形態）
第５の実施形態では、図１，図２，図４，および図５に示した構成は第１〜第４の実施形態のものと共通している。図５のネットワーク状態判定部１２００の内部に図１２のように図７と同様の、パケット受信部１３００からのパケット情報１６０４を蓄積するためのネットワーク情報格納部１２２０と、過去に選択したストリームのパラメータ１６０５を蓄積するための受信パラメータ情報格納部１２３０を設けたこと、および、ネットワーク状態判定部１２００における状態判定の処理において、その過去に選択したストリームの履歴１２１２を用いた判定を行う点が第４の実施形態とは異なる。
【００９５】
図１３は、本実施形態のネットワーク状態判定部１２１０（図１２）において、パケット情報を用いて通信路の状態を判断し、その状態に適したパラメータをもつデータストリームを選択する処理の一例を示すフローチャートである。このフローチャートにおいて、まず処理Ｓ９００１において輻輳を判定する方法は、第１〜第４の実施形態と同様の方法を用いる。また、処理Ｓ９００１において輻輳していると判断された場合の処理Ｓ９００２も第１〜第４の実施形態と同様である。
【００９６】
次に処理Ｓ９０１０に進むが、ここでは、前回の切り替えがビットレートの回復を行ったものであったかどうかを判定する。この判定には、図１２における受信パラメータ情報格納部１２３０から切り替え情報の履歴１２１２を得ることで判断する。前回の切り替えがビットレートの回復であり、その切り替えの後に輻輳した場合には、その回復が適切でなかったと判断される。そのため、処理Ｓ９０１１に進み、輻輳していなかった場合の帯域に余裕があるかどうかの判定を行う処理Ｓ９００８において、余裕があると判断する式（８）Ｊｎｏｗ＜Ｊｕｐ＿ｔｈの閾値Ｊｕｐ＿ｔｈをさらに小さくするために、例えば、

として閾値Ｊｕｐ＿ｔｈの修正を行う。これにより、次回の帯域に余裕があるかどうかの判定では、帯域に余裕があると判断される確率が低くなる。また、ネットワーク層での再送により遅延に変動がある場合にＲＩを指標として用いている場合にも同様に、式（１０）で用いている閾値ｒｉ＿ｔｈをさらに小さくするために、例えば、

としてもよい。
【００９７】
処理Ｓ９００１において、輻輳と判断されなかった場合は、処理Ｓ９００４においてパケット損失があるかどうかを判断する。ここでのパケット損失の判定および、パケット損失があると判定された場合のＧＯＰ間隔を短くするストリーム選択処理Ｓ９００５は第４の実施形態と同様である。また、Ｓ９００４でパケット損失が発生しなかった場合には、帯域に余裕があるかどうかの判定を行う処理Ｓ９００８を行うが、この処理は第４の実施形態と同様である。
【００９８】
さらに、処理Ｓ９００８において帯域に余裕があると判断された場合の、ビットレートを回復するようなストリームを選択する処理Ｓ９００９は、第４の実施形態と同様である。また、処理９００８において、帯域に余裕がないと判断された場合にＧＯＰ間隔を回復しようと試みる処理Ｓ９００６およびＳ９００７も第４の実施形態と同様である。
【００９９】
ストリームの変更を行う場合に、それをパケット受信部１３００に通知する処理Ｓ９００３およびパケット受信部１３００における切り替え処理についても、第１〜第４の実施形態と同様である。
【０１００】
この選択の処理は、通信路の状態の変化に追随するため、例えばある一定の時間ごとに行うなど、繰り返し行われることも、第１〜第４の実施形態と同様である。
【０１０１】
なお、本実施形態では、図１１において通信路に誤りが発生しないと仮定し、同一のＧＯＰ間隔のみの１つ以上のストリームを配信するような場合には、処理Ｓ９００４、Ｓ９００５、および処理Ｓ９００６、Ｓ９００７を省き、処理Ｓ９００１において輻輳していない場合には処理Ｓ９００８に進めて、輻輳かどうかと帯域に余裕があるかどうかの判定のみを行うことで処理の軽減を行うことも可能である。
【０１０２】
また、この実施形態を変形し、過去の切り替えの履歴１２１２において、一定期間同じビットレートを受信している場合には、処理Ｓ９００８における判定の平均ジッタの閾値を、例えば、

などと大きくなるように変更し、ビットレートの回復を行いやすくするようにすることで、通信路の帯域が回復した場合に早く状況に追従できるようにすることも可能である。また、ネットワーク層での再送により遅延に変動がある場合にＲＩを指標として用いている場合にも同様に、式（１０）で用いている閾値ｒｉ＿ｔｈを大きくするために、例えば、

としてもよい。
【０１０３】
以上説明した本発明の第５の実施形態によれば、ビットレートを回復させた結果、帯域をオーバーして輻輳を招いた場合でも、過去のストリームの切り替えの履歴を用いて閾値に修正を行うことができ、これによりビットレートの回復と輻輳の繰り返しを適切に抑制できることから、安定したストリーム提供を実現できる。また、これらの処理は各クライアントごとに行われるため、サーバ側の制御負荷を軽減することができる。各クライアントごとに、それぞれの通信路の状態に適したストリームを提供することが可能であることは、第１〜第４の実施形態と同様である。
【０１０４】
以上に述べた第１〜第５の実施形態では、パケット受信部１３００におけるストリームの受信切り替え処理において、切り替えを行ってから初めてフレーム内符号化モードのパケットを受信するまでは正常に復号がおこなえない。このような現象の抑制方法について以下に説明する。
【０１０５】
これは、図５に示すクライアントの構成のうち、パケット受信部１３００を発展させたものであり、これまでに述べた第１〜第５の実施形態の一部を発展させた例として適用可能である。図１４に示すように、内部にフレーム内符号化判定部１３２１、切り替え制御部１３２２およびパケットデータ受信部１３２３を設けている。この構成によれば、パケットデータ受信部１３２３により受信されたパケットのシーケンス番号やタイムスタンプなどのヘッダ情報およびパケットの到着時間などのパケット情報１６０４はネットワーク状態判定部１２００に渡され、第１〜第５の実施形態で述べたストリームを選択する処理が行われる。ここで、ストリームの変更があった場合には変更後のストリームの受信パラメータを含む切り替え情報１６０５が、ネットワーク状態判定部１２００より切り替え制御部１３２２に渡される。また、パケットデータ受信部１３２３により受信されたパケット１６０２は、フレーム内符号化判定部１３２１に渡される。フレーム内符号化判定部１３２１は、パケットに含まれる符号化データがフレーム内符号化のデータかフレーム間符号化のデータかを判定し、その結果がパケット１６０２に付加されたデータ１３２４を切り替え制御部１３２２に渡す。
【０１０６】
切り替え制御部１３２２では、切り替え情報１６０５を受け取ると、例えば図１５に示すような切り替えの処理を行う。まず、処理Ｓ１１００１において、受信帯域に余裕があるかどうかを判定する。この判定は、フレーム内符号化判定部１３２１から渡されるデータ１３２４に含まれるパケットのシーケンス番号やタイムスタンプなどのヘッダ情報およびパケットの到着時間などからパケットの平均ジッタなどを計算し、例えば第４の実施形態で示した（９）式などを用いて行う。
【０１０７】
帯域に余裕があると判定された場合には、処理Ｓ１１００２に進み、切り替え情報１６０５に含まれる変更後の受信パラメータのマルチキャストアドレスよりストリームの受信を開始（ＪＯＩＮ）する。
【０１０８】
次に処理１１００３に進み、変更後のストリームの受信パケットがフレーム内符号化かどうかを判断する。これは、フレーム内符号化判定部１３２１から渡されるデータ１３２４に含まれる判定結果を用い、変更後のストリームであるかどうかの判断は、パケットヘッダに含まれる送信先マルチキャストアドレスや、ペイロード番号などを用いて行う。ここで、変更後のストリームでフレーム内符号化された符号化データを含むパケットを受信するまでは、画像復号部１４００に対して変更前のストリームを含むパケットに含まれる符号化データ１６０６を出力し、変更後のストリームを含むパケットは破棄する。変更後のストリームの受信パケットがフレーム内符号化された符号化データを含むパケットであった場合には、処理Ｓ１１００４に進み、画像復号部１４００に対して変更前のストリームのパケットに含まれる符号化データの出力を停止するとともに以降のパケットは破棄し、変更後のストリームのパケットに含まれる符号化データ１６０６を出力する。
【０１０９】
最後に、処理Ｓ１１００５にて、変更前のストリームのマルチキャストアドレスからのストリームの受信を停止（ＬＥＡＶＥ）する。
【０１１０】
この一連の処理（Ｓ１１００２〜Ｓ１１００５）では、帯域に余裕があることを利用して、変更前のストリームと変更後のストリームを一時同時に受信し、変更後のストリームのフレーム内符号化されたデータの到着を待ってから画像復号部１４００に対して出力するストリームを切り替えることで、途切れのないスムーズな切り替えを行うことが可能である。
【０１１１】
具体的な例を用いて説明する。図１６において、切り替えが発生した際には変更前のストリーム（２２４．１．１．１のストリーム）を受信している。この時点でまず変更先のストリーム（２２４．１．１．２のストリーム）の受信を開始（ＪＯＩＮ）する。次に変更後のストリームの受信を開始してから最初のフレーム内符号化されたパケット１６００１を受信した時点で出力するストリームを切り替え、変更前のストリームの受信を停止（ＬＥＡＶＥする）。こうすることで、出力されるストリームはフレーム内符号化されたフレームが到着するまでは変更前のストリームが出力され、ちょうどフレーム内符号化されたフレームが到着した時点で変更先のストリームに切り替わることから、乱れのない映像を提供可能である。ただし、切り替えの間は２本のストリームを同時に受信することになるため、Ｓ１１００１において帯域に十分な余裕があるか判定する必要がある。
【０１１２】
一方、処理Ｓ１１００１において、帯域に余裕がないと判断された場合には、処理Ｓ１１００６に進み、変更前のストリームのマルチキャストアドレスからのストリームの受信を停止（ＬＥＡＶＥ）する。次に、処理Ｓ１１００７に進み、切り替え情報１６０５に含まれる変更後の受信パラメータのマルチキャストアドレスよりストリームの受信を開始（ＪＯＩＮ）する。次に処理１１００８に進み、処理１１００３と同様の方法で変更後のストリームの受信パケットがフレーム内符号化かどうかを判断する。ここで、変更後のストリームでフレーム内符号化された符号化データを含むパケットを受信するまでは、画像復号部１４００に対して変更前のストリームを含むパケットに含まれる符号化データ１６０６を出力し、変更後のストリームを含むパケットは破棄する。変更後のストリームの受信パケットがフレーム内符号化された符号化データを含むパケットであった場合には、処理Ｓ１１００９に進み、画像復号部１４００に対して変更前のストリームのパケットに含まれる符号化データの出力を停止するとともに以降のパケットは破棄し、変更後のストリームのパケットに含まれる符号化データ１６０６を出力する。
【０１１３】
この一連の処理（Ｓ１１００６〜Ｓ１１００７）では、変更前のストリームの受信を停止した後に変更後のストリームの受信を開始し、変更後のストリームのフレーム内符号化されたデータの到着を待ってから画像復号部１４００に対して出力するストリームを切り替えることで、使用帯域を抑制するとともに、変更後のストリームのフレーム内符号化されたデータを受信するまで変更前のストリームの最後のフレームで一端画像が停止するものの、切り替えによる画像の乱れが起きないスムーズな切り替えを行うことが可能である。
【０１１４】
具体的な例を用いて説明する。図１７において、切り替えが発生した際には変更前のストリーム（２２４．１．１．１のストリーム）を受信しているが、まず変更前のストリーム（２２４．１．１．１のストリーム）の受信を停止（ＬＥＡＶＥ）した後に変更後のストリーム（２２４．１．１．２のストリーム）の受信を開始（ＪＯＩＮ）する。これにより図１６の例のように２本のストリームを同時に受信する必要がなくなり、帯域を節約することが可能である。次に変更後のストリームの受信を開始してから最初のフレーム内符号化されたパケット１７００１を受信した時点で出力するストリームを切り替える。この間、出力されるストリームは変更前のストリームの最後に受信したフレームで停止しているが、出力されるストリームはちょうどフレーム内符号化されたフレームから切り替わり、乱れのない映像を提供することができる。
【０１１５】
また、処理Ｓ１１００６〜Ｓ１１００７においては、変更後のストリームのフレーム内符号化されたデータを受信するまで変更前のストリームの最後のフレームで一端画像が停止するが、この区間を短く抑える方法を提供する。一定間隔でフレーム内符号化されたフレームが入ることがわかっている場合に、次のフレーム内符号化されたフレームが送信される時刻を予測して切り替えるタイミングを制御することも考えられる。例えば、サーバ２０００から送信されるＲＴＣＰなどから取得することが可能なストリームの先頭パケットを送信した時刻Ｔｆｉｒｓｔ＿ｓｅｎｄと現在時刻ｔおよびパラメータデータから取得可能なＧＯＰ間隔Ｉｇｏｐから、次のフレーム内符号化されたデータを含むパケットがサーバ側で送信される時刻Ｔｎｅｘｔ＿ｉｖｏｐ＿ｓｅｎｄを以下のように推定する。
【０１１６】

この時刻に間に合うように、例えば、この時刻よりパケットの遅延ｄと、パケットの遅延のばらつきｄ’の和だけ早い時刻Ｔｃｈａｎｇｅ、すなわち

に処理１１００６〜処理１１００７を実行すれば、次のフレーム内符号化されたデータを含むパケットの到着にあわせて切り替えることができ、切り替え時に映像が停止する時間を短く抑えることが可能である。
【０１１７】
また、切り替えによる画像の停止を短く抑える別の方法を提供する。この方法は前記方法とは異なり、一定間隔でフレーム内符号化されたフレームが入っていなくても使用可能である。すなわち、サーバ２０００に対し、例えばＲＴＳＰのＧＥＴ＿ＰＡＲＡＭＥＴＥＲなどの上位プロトコルのコマンドを利用し、変更後のストリームの次のフレーム内符号化されたフレームを含むパケットが送信される時刻Ｔｎｅｘｔ＿ｉｖｏｐ＿ｓｅｎｄを取得する。後は前記の方法と同様に例えば（１６）式で計算される時刻Ｔｃｈａｎｇｅに処理１１００６〜処理１１００７を実行すれば、次のフレーム内符号化されたデータを含むパケットの到着にあわせて切り替えることができ、切り替え時に映像が停止する時間を短く抑えることが可能である。この処理１１００６〜処理１１００７を行う時刻の制御については、以上に述べた方法は一例であり、サーバ２０００が変更後のストリームの次のフレーム内符号化されたデータを含むパケットを送信する時刻Ｔｎｅｘｔ＿ｉｖｏｐ＿ｓｅｎｄを取得あるいは推定する方法であれば（１６）式を用いて切り替え時刻を制御することが可能である。
【０１１８】
以上のような切り替え方法を第１〜第５の実施形態に適用することで、通信路の状態に追従した適したストリームに切り替える際に、帯域の余裕に応じた切り替え方式を切り替えることで、スムーズな切り替えを行うことが可能になる。
【０１１９】
なお、以上に示した実施形態では、図１で示すようなサーバ２０００から各クライアント１０００にいたるまでネットワーク３０００上をマルチキャストを介してデータ伝送を行ったが、例えばクライアント１０００ａ〜１０００ｂとして携帯端末を想定する場合は、図１８のように、ネットワーク３０００からクライアント１０００ａ〜１０００ｂへの末端ノードを基地局４０００とし、サーバ２０００から基地局４０００までをマルチキャストで伝送し、基地局４０００からクライアント１０００ａ〜１０００ｂ間はユニキャストを用いて伝送してもよい。また、ネットワーク３０００から例えばクライアント１０００ｃ〜１０００ｄへの末端ノードを、マルチキャストグループへの参加／不参加を監視し下流のノードへ転送するストリームを制御する機能を持つスイッチ５０００とすることで、スイッチ５０００とクライアント１０００ｃおよびクライアント１０００ｄ間において、クライアント１０００ｃおよび１０００ｄがそれぞれ受信しているストリームのみを伝送することが可能となる。このように、本発明では、サーバからクライアントにいたるまでの通信経路の一部に、ユニキャストを用いたり、マルチキャストのトラフィックを制御するようなスイッチを含んでいてもよい。特に、図１８の例のように誤りや帯域変動が生じやすいネットワークの末端ノード（基地局やスイッチ）からクライアントまでをユニキャストで伝送したり、末端ノードをマルチキャストトラフィック制御機能を持つスイッチとするなどして、伝送されるストリームを制御することにより本発明はより効果を発揮する。
【０１２０】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【０１２１】
【発明の効果】
以上説明したように、本発明によれば、送信側装置および受信側装置の双方の処理負荷を高めることなく、受信側装置が置かれている多様な伝送環境に対して適応的なデータ伝送を実現することのできる装置、および方法を提供することができる。
【図面の簡単な説明】
【図１】本発明の実施形態に係るデータ伝送システムの全体構成を示すブロック図
【図２】サーバの内部構成を示すブロック図
【図３】パラメータ送信部が送信するパラメータデータの一例を示す図
【図４】サーバの他の構成例を示すブロック図
【図５】クライアントの基本的な構成を示すブロック図
【図６】通信路の状態に適したパラメータをもつデータストリームを選択する処理の一例を示すフローチャート
【図７】ネットワーク状態判定部における輻輳判定に係る他の構成例を示すブロック図
【図８】パケット受信部における切り替え処理の一例を示すフローチャート
【図９】本発明の第２実施形態に係わり、ネットワーク状態判定部において、通信路の状態に適したパラメータをもつデータストリームを選択する処理の一例を示すフローチャート
【図１０】本発明の第３実施形態に係わり、ネットワーク状態判定部において、通信路の状態に適したパラメータをもつデータストリームを選択する処理の他の例を示すフローチャート
【図１１】本発明の第４実施形態に係わり、ネットワーク状態判定部において、通信路の状態に適したパラメータをもつデータストリームを選択する処理のさらに別の例を示すフローチャート
【図１２】本発明の第５実施形態に係るネットワーク状態判定部の構成を示すブロック図
【図１３】本発明の第５実施形態に係り、ネットワーク状態判定部において、通信路の状態に適したパラメータをもつデータストリームを選択する処理の一例を示すフローチャート
【図１４】実施形態の変形例に係わるパケットデータ受信部の構成例を示すブロック図
【図１５】上記変形例に係わり、切り替え制御部による切り替え情報に基づく切り替えの処理を示すフローチャート
【図１６】上記変形例に係わり、ストリームの切り替えを説明するための概念図
【図１７】上記変形例に係わり、ストリームの切り替えを説明するための概念図
【図１８】実施形態の変形例に係わるシステム構成図
【符号の説明】
１０００ａ〜ｄ…クライアント（データ受信装置）、２０００…サーバ（データ送信装置）、３０００…ネットワーク

Claims (20)

1. データ信号を入力する入力手段と、
   前記データ信号を第１、第２の符号化パラメータを用いて符号化して第１、第２の符号化データストリームを生成する符号化手段と、
   前記第１の符号化データストリームをパケット化して第１のマルチキャストアドレスに送信するとともに、前記第２の符号化データストリームをパケット化して第２のマルチキャストアドレスに送信するパケットデータ送信手段と、
   前記第１、第２の符号化パラメータを前記第１、第２のマルチキャストアドレスを含む送信パラメータに対応付けて表すパラメータデータをデータ受信装置からの要求に応じて送信するパラメータ送信手段と、
   を具備するデータ送信装置。
2. 同一のデータ信号を第１、第２の符号化パラメータを用いて符号化して生成される第１、第２の符号化データストリームを格納する格納手段と、
   データ受信装置からの要求に応じて前記格納手段から前記第１、第２の符号化データストリームを読み出す読み出し手段と、
   前記読み出し手段により読み出された第１の符号化データストリームをパケット化して第１のマルチキャストアドレスに送信するとともに、前記読み出し手段により読み出された第２の符号化データストリームをパケット化して第２のマルチキャストアドレスに送信するパケットデータ送信手段と、
   前記第１、第２の符号化データストリームのそれぞれの符号化パラメータを前記第１、第２のマルチキャストアドレスを含む送信パラメータに対応付けて表すパラメータデータを、データ受信装置からの要求に応じて送信するパラメータ送信手段と、
   を具備するデータ送信装置。
3. 同一のデータ信号を第１、第２の符号化パラメータを用いて符号化して生成された第１、第２の符号化データストリームのそれぞれの符号化パラメータを第１、第２のマルチキャストアドレスを含む送信パラメータに対応付けて表すパラメータデータを受信するパラメータ受信手段と、
   前記パラメータデータに基づいて前記第１、第２のマルチキャストアドレスのいずれか一方を選択するアドレス選択手段と、
   前記アドレス選択手段により選択されたマルチキャストアドレスに対応する前記第１、第２の符号化データストリームのいずれか一方のパケットデータを受信するパケットデータ受信手段と、
   前記パケットデータ受信手段により受信されたパケットデータを復号して前記データ信号を再生するデータ再生手段と、
   を具備するデータ受信装置。
4. 伝送路の通信状態を前記パケットデータ受信手段により受信されたパケットデータに基づいて判定するネットワーク状態判定手段と、
   前記ネットワーク状態判定手段により判定された通信状態に基づいて、前記伝送路に現在、輻輳が生じているか否かを判定する輻輳判定手段と、
   前記輻輳判定手段により輻輳が生じていると判定された場合に、前記伝送路の占有帯域幅を削減可能な前記第１、第２の符号化データストリームのいずれか一方のパケットデータを受信するように前記第１、第２のマルチキャストアドレスをいずれか一方からいずれか他方に切り替えるアドレス切り替え手段と、
   をさらに具備する請求項３に記載のデータ受信装置。
5. 前記通信状態の判定に用いられるパケットデータは、パケットの遅延時間、パケットの損失、あるいはパケットの到着間隔の少なくともいずれかの情報を含む請求項４に記載のデータ受信装置。
6. 前記ネットワーク状態判定手段により判定された前記通信状態を表すネットワーク情報を格納するネットワーク情報格納手段をさらに具備し、
   前記輻輳判定手段は、前記ネットワーク情報格納手段に格納された過去のネットワーク情報と、前記ネットワーク状態判定手段により判定された現在の通信状態とに基づいて、前記伝送路に現在、輻輳が生じているか否かを判定する請求項４又は５に記載のデータ受信装置。
7. 前記パラメータ受信手段により受信されたパラメータデータを格納するパラメータ格納手段をさらに具備し、
   前記輻輳判定手段は、前記パラメータ格納手段に格納された過去のパラメータデータと、前記ネットワーク状態判定手段により判定された現在の通信状態とに基づいて、前記伝送路に現在、輻輳が生じているか否かを判定する請求項４又は５に記載のデータ受信装置。
8. 前記パケットデータ受信手段により受信されたパケットデータにパケット損失が生じたか否かを検出する検出手段と、
   前記検出手段により検出されたパケット損失の時間間隔を計測する計測手段と、
   前記時間間隔の長短に応じて前記アドレス選択手段によるマルチキャストアドレスの選択を制御する手段をさらに具備する請求項４乃至７のいずれかに記載のデータ受信装置。
9. 前記伝送路の帯域の余裕度を計算する計算手段と、
   前記計算手段により計算された余裕度を閾値と比較し、その比較結果に従って前記アドレス選択手段によるマルチキャストアドレスの選択を制御する手段をさらに具備する請求項４乃至７のいずれかに記載のデータ受信装置。
10. フレーム内符号化された符号化ストリームの推定送信時刻を計算する計算手段と、
    前記データ再生手段によるデータ信号の再生が前記フレーム内符号化された符号化ストリームの不達に起因して停止しないように、前記アドレス選択手段によるマルチキャストアドレスの選択を前記推定送信時刻に基づいて制御する手段をさらに具備する請求項８又は９に記載のデータ受信装置。
11. データ信号を入力する入力ステップと、
    前記データ信号を第１、第２の符号化パラメータを用いて符号化し、第１、第２の符号化データストリームを生成する符号化ステップと、
    前記第１の符号化データストリームをパケット化して第１のマルチキャストアドレスに送信するとともに、前記第２の符号化データストリームをパケット化して第２のマルチキャストアドレスに送信するパケットデータ送信ステップと、
    前記第１、第２の符号化データストリームの生成に用いられたそれぞれの符号化パラメータを前記第１、第２のマルチキャストアドレスを含む送信パラメータに対応付けて表すパラメータデータを、データ受信装置からの要求に応じて送信するパラメータ送信ステップと、
    を具備するデータ送信方法。
12. 同一のデータ信号を第１、第２の符号化パラメータを用いて符号化して生成された第１、第２の符号化データストリームを格納する格納ステップと、
    データ受信装置からの要求に応じて前記格納ステップにおいて格納された前記第１、第２の符号化データストリームを読み出す読み出しステップと、
    前記読み出しステップにおいて読み出された第１の符号化データストリームをパケット化して第１のマルチキャストアドレスに送信するとともに、前記読み出しステップにおいて読み出された第２の符号化データストリームをパケット化して第２のマルチキャストアドレスに送信するパケットデータ送信ステップと、
    前記第１、第２の符号化データストリームのそれぞれの符号化パラメータを前記第１、第２のマルチキャストアドレスを含む送信パラメータに対応付けて表すパラメータデータを、データ受信装置からの要求に応じて送信するパラメータ送信ステップと、
    を具備するデータ送信方法。
13. 同一のデータ信号を第１、第２の符号化パラメータを用いて符号化して生成された第１、第２の符号化データストリームのそれぞれの符号化パラメータを第１、第２のマルチキャストアドレスを含む送信パラメータに対応付けて表すパラメータデータを受信するパラメータ受信ステップと、
    前記パラメータデータに基づいて前記第１、第２のマルチキャストアドレスのいずれか一方を選択するアドレス選択ステップと、
    前記アドレス選択ステップにおいて選択されたマルチキャストアドレスに対応する前記第１、第２の符号化データストリームのいずれか一方のパケットデータを受信するパケットデータ受信ステップと、
    前記パケットデータ受信ステップにおいて受信されたパケットデータを復号して前記データ信号を再生するデータ再生ステップと、
    を具備するデータ受信方法。
14. 伝送路の通信状態を前記パケットデータ受信ステップにおいて受信されたパケットデータに基づいて判定するネットワーク状態判定ステップと、
    前記ネットワーク状態判定ステップにおいて判定された通信状態に基づいて、前記伝送路に現在、輻輳が生じているか否かを判定する輻輳判定ステップと、
    前記輻輳判定ステップにおいて輻輳が生じていると判定された場合に、前記伝送路の占有帯域幅を削減可能な前記第１、第２の符号化データストリームのいずれか一方のパケットデータを受信するように前記第１、第２のマルチキャストアドレスをいずれか一方からいずれか他方に切り替えるアドレス切り替えステップと、
    をさらに具備する請求項１３に記載のデータ受信方法。
15. 前記通信状態の判定に用いられるパケットデータは、パケットの遅延時間、パケットの損失、あるいはパケットの到着間隔の少なくともいずれかの情報を含む請求項１４に記載のデータ受信方法。
16. 前記ネットワーク状態判定ステップにおいて判定された前記通信状態を表すネットワーク情報を格納するネットワーク情報格納ステップをさらに具備し、
    前記輻輳判定ステップは、前記ネットワーク情報格納手段に格納された過去のネットワーク情報と、前記ネットワーク状態判定ステップにおいて判定された現在の通信状態とに基づいて、前記伝送路に現在、輻輳が生じているか否かを判定する請求項１４又は１５に記載のデータ受信方法。
17. 前記パラメータ受信ステップにおいて受信されたパラメータデータを格納するパラメータ格納ステップをさらに具備し、
    前記輻輳判定ステップは、前記パラメータ格納ステップにおいて格納された過去のパラメータデータと、前記ネットワーク状態判定ステップにおいて判定された現在の通信状態とに基づいて、前記伝送路に現在、輻輳が生じているか否かを判定する請求項１４又は１５に記載のデータ受信方法。
18. 前記パケットデータ受信ステップにおいて受信されたパケットデータにパケット損失が生じたか否かを検出する検出ステップと、
    前記検出ステップにおいて検出されたパケット損失の時間間隔を計測する計測ステップと、
    前記時間間隔の長短に応じて前記アドレス選択ステップにおけるマルチキャストアドレスの選択を制御するステップをさらに具備する請求項１４乃至１７のいずれかに記載のデータ受信方法。
19. 前記伝送路の帯域の余裕度を計算する計算ステップと、
    前記計算ステップにおいて計算された余裕度を閾値と比較し、その比較結果に従って前記アドレス選択ステップにおけるマルチキャストアドレスの選択を制御するステップをさらに具備する請求項１４乃至１７のいずれかに記載のデータ受信方法。
20. フレーム内符号化された符号化ストリームの推定送信時刻を計算する計算ステップと、
    前記データ再生ステップにおけるデータ信号の再生が前記フレーム内符号化された符号化ストリームの不達に起因して停止しないように、前記アドレス選択ステップにおけるマルチキャストアドレスの選択を前記推定送信時刻に基づいて制御するステップをさらに具備する請求項１８又は１９に記載のデータ受信方法。

Images