JP2005033556A

JP2005033556A - Data transmitter, data transmitting method, data receiver, data receiving method

Info

Publication number: JP2005033556A
Application number: JP2003196725A
Authority: JP
Inventors: Reiko Noda; 玲子野田; Takeshi Nagai; 剛永井; Yoshihiro Kikuchi; 義浩菊池; Hideyuki Ueno; 秀幸上野
Original assignee: Toshiba Corp
Current assignee: Toshiba Corp
Priority date: 2003-07-14
Filing date: 2003-07-14
Publication date: 2005-02-03

Abstract

<P>PROBLEM TO BE SOLVED: To provide a device and a method capable of performing adaptive data transmission to various kinds of transmission environments under which a device on the receiving side is placed without raising processing burdens of both of the device on the transmitting side and the device on the receiving side. <P>SOLUTION: The same data signal is encoded by using different encoding parameters, and first and second encoding data streams are generated. The first encoding data stream is packetized and transmitted to a first multicast address. The second encoding data stream is transmitted to a second multicast address. Parameter data which indicate the respective encoding parameters used for the generation of the first and second encoding data streams by associating them with first and second multicast addresses is transmitted to a data receiver according to a request. The data receiver switches the multicast addresses based on the parameter data and selectively receives the encoding data streams. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

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

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

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

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

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

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

に処理１１００６〜処理１１００７を実行すれば、次のフレーム内符号化されたデータを含むパケットの到着にあわせて切り替えることができ、切り替え時に映像が停止する時間を短く抑えることが可能である。
【０１１７】
また、切り替えによる画像の停止を短く抑える別の方法を提供する。この方法は前記方法とは異なり、一定間隔でフレーム内符号化されたフレームが入っていなくても使用可能である。すなわち、サーバ２０００に対し、例えばＲＴＳＰのＧＥＴ＿ＰＡＲＡＭＥＴＥＲなどの上位プロトコルのコマンドを利用し、変更後のストリームの次のフレーム内符号化されたフレームを含むパケットが送信される時刻Ｔｎｅｘｔ＿ｉｖｏｐ＿ｓｅｎｄを取得する。後は前記の方法と同様に例えば（１６）式で計算される時刻Ｔｃｈａｎｇｅに処理１１００６〜処理１１００７を実行すれば、次のフレーム内符号化されたデータを含むパケットの到着にあわせて切り替えることができ、切り替え時に映像が停止する時間を短く抑えることが可能である。この処理１１００６〜処理１１００７を行う時刻の制御については、以上に述べた方法は一例であり、サーバ２０００が変更後のストリームの次のフレーム内符号化されたデータを含むパケットを送信する時刻Ｔｎｅｘｔ＿ｉｖｏｐ＿ｓｅｎｄを取得あるいは推定する方法であれば（１６）式を用いて切り替え時刻を制御することが可能である。
【０１１８】
以上のような切り替え方法を第１〜第５の実施形態に適用することで、通信路の状態に追従した適したストリームに切り替える際に、帯域の余裕に応じた切り替え方式を切り替えることで、スムーズな切り替えを行うことが可能になる。
【０１１９】
なお、以上に示した実施形態では、図１で示すようなサーバ２０００から各クライアント１０００にいたるまでネットワーク３０００上をマルチキャストを介してデータ伝送を行ったが、例えばクライアント１０００ａ〜１０００ｂとして携帯端末を想定する場合は、図１８のように、ネットワーク３０００からクライアント１０００ａ〜１０００ｂへの末端ノードを基地局４０００とし、サーバ２０００から基地局４０００までをマルチキャストで伝送し、基地局４０００からクライアント１０００ａ〜１０００ｂ間はユニキャストを用いて伝送してもよい。また、ネットワーク３０００から例えばクライアント１０００ｃ〜１０００ｄへの末端ノードを、マルチキャストグループへの参加／不参加を監視し下流のノードへ転送するストリームを制御する機能を持つスイッチ５０００とすることで、スイッチ５０００とクライアント１０００ｃおよびクライアント１０００ｄ間において、クライアント１０００ｃおよび１０００ｄがそれぞれ受信しているストリームのみを伝送することが可能となる。このように、本発明では、サーバからクライアントにいたるまでの通信経路の一部に、ユニキャストを用いたり、マルチキャストのトラフィックを制御するようなスイッチを含んでいてもよい。特に、図１８の例のように誤りや帯域変動が生じやすいネットワークの末端ノード（基地局やスイッチ）からクライアントまでをユニキャストで伝送したり、末端ノードをマルチキャストトラフィック制御機能を持つスイッチとするなどして、伝送されるストリームを制御することにより本発明はより効果を発揮する。
【０１２０】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【０１２１】
【発明の効果】
以上説明したように、本発明によれば、送信側装置および受信側装置の双方の処理負荷を高めることなく、受信側装置が置かれている多様な伝送環境に対して適応的なデータ伝送を実現することのできる装置、および方法を提供することができる。
【図面の簡単な説明】
【図１】本発明の実施形態に係るデータ伝送システムの全体構成を示すブロック図
【図２】サーバの内部構成を示すブロック図
【図３】パラメータ送信部が送信するパラメータデータの一例を示す図
【図４】サーバの他の構成例を示すブロック図
【図５】クライアントの基本的な構成を示すブロック図
【図６】通信路の状態に適したパラメータをもつデータストリームを選択する処理の一例を示すフローチャート
【図７】ネットワーク状態判定部における輻輳判定に係る他の構成例を示すブロック図
【図８】パケット受信部における切り替え処理の一例を示すフローチャート
【図９】本発明の第２実施形態に係わり、ネットワーク状態判定部において、通信路の状態に適したパラメータをもつデータストリームを選択する処理の一例を示すフローチャート
【図１０】本発明の第３実施形態に係わり、ネットワーク状態判定部において、通信路の状態に適したパラメータをもつデータストリームを選択する処理の他の例を示すフローチャート
【図１１】本発明の第４実施形態に係わり、ネットワーク状態判定部において、通信路の状態に適したパラメータをもつデータストリームを選択する処理のさらに別の例を示すフローチャート
【図１２】本発明の第５実施形態に係るネットワーク状態判定部の構成を示すブロック図
【図１３】本発明の第５実施形態に係り、ネットワーク状態判定部において、通信路の状態に適したパラメータをもつデータストリームを選択する処理の一例を示すフローチャート
【図１４】実施形態の変形例に係わるパケットデータ受信部の構成例を示すブロック図
【図１５】上記変形例に係わり、切り替え制御部による切り替え情報に基づく切り替えの処理を示すフローチャート
【図１６】上記変形例に係わり、ストリームの切り替えを説明するための概念図
【図１７】上記変形例に係わり、ストリームの切り替えを説明するための概念図
【図１８】実施形態の変形例に係わるシステム構成図
【符号の説明】
１０００ａ〜ｄ…クライアント（データ受信装置）、２０００…サーバ（データ送信装置）、３０００…ネットワーク[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a method and apparatus for transmitting and receiving and reproducing data such as images and sounds via a communication network, particularly a multicast network.
[0002]
[Prior art]
In recent years, a system for transmitting image data compressed and encoded using these technologies through a network has been developed due to the progress of digital encoding technology for various information including images and broadband network technology. As a method for many users to efficiently use a transmission path during data transmission, a method of transmitting and receiving data in packets is effective. Protocols for packetizing and transmitting data include TCP / IP (Transmission Control Protocol / Internet Protocol) and UDP / IP (User Datagram Protocol / Internet Protocol). TCP / IP has a high error tolerance because it incorporates a framework such as retransmission, and is effective for download-type applications that want to receive data correctly even if it takes some time. TCP / IP can perform congestion control by dynamically changing a packet size called a window size according to a response from the network, but is ineffective for applications that require real-time performance. On the other hand, since UDP / IP does not have a retransmission framework, there is no delay for retransmission and the like, which is extremely effective for applications that require real-time performance.
[0003]
Further, in recent years, applications using RTP (Real-time Transport Protocol) for transmitting audio data and video data in real time based on UDP have been increasing. RTP is defined in RFC 1889, and is assumed to be applied to a multimedia system such as a video conference that exchanges data in a real-time conversation format. Note that RTP has a packet format in which a packet sequence number and time information (time stamp) can be described in an RTP header, and supports real-time operation based on such information. For example, on the receiving side, it is possible to construct audio and / or image content data according to the correct time information described in the packet and appropriately display and reproduce it. In addition, it is possible to determine a packet whose order has been changed in the network transmission process, and to detect which packet has been lost during transmission based on the packet number. RTP does not have a quality assurance function for sound quality and image quality, but has a mechanism (RTCP) for notifying each other of jitter (delay information), packet loss rate, and the like as supplementary information for packet transmission / reception.
[0004]
A typical example of an application that requires real-time performance is the transmission of moving images. However, even with an ordinary moving image, the amount of image data in the original data format is enormous and the network bandwidth is compressed. A method is adopted in which data is encoded and the amount of data is compressed before transmission.
[0005]
As compression coding techniques for moving image signals, techniques such as motion compensation, discrete cosine transform (DCT), subband coding, pyramid coding, variable length coding, etc., and methods combining these techniques have been developed. International standards for moving picture coding include ISO MPEG-1, MPEG-2, ITU-T H.264, and the like. 261, H.H. 262, H.C. H.263, and ISO MPEG system, ITU-T H.264, and the like as international standard systems for multiplexing moving images, code strings compressed audio / audio signals, and other data. 221, H.M. 223 exists. Although the compression effect of the data amount by these encoding methods is extremely high, it is vulnerable to packet loss and error mixture caused by transmitting data on an unstable transmission path. This is due to the fact that only the difference frame from the previous frame is transmitted in the moving image coding system, and the loss of a part of the data can be a serious problem because the compression effect is high. Because. When UDP and RTP are used for data transmission, they basically do not retransmit data, and it is said that countermeasures against this problem are necessary.
[0006]
There are usually two modes in image coding. There are an inter-frame coding mode (P Picture) in which a difference from the previous frame is sent and an intra-frame coding mode (I Picture) in which coding is closed in one frame. In a normal data transmission sequence, an intra-frame coding mode is set at an appropriate time interval, and an inter-frame coding mode is set between them. The interval at which frames are encoded in this intra-frame encoding mode is called a GOP (Group of Pictures) interval. If the decoded image is corrupted due to data loss, all subsequent decoded images will be decoded because the decoding is performed based on the broken image when encoding is performed in the inter-frame encoding mode. Will be affected and cannot be decoded correctly. Therefore, by inserting a frame encoded in the intra-frame encoding mode in the middle, the propagation of the influence of the error is cut off there. However, since the intraframe coding mode requires a larger amount of code than the interframe coding mode, if the GOP interval is shortened at the same bit rate, the image quality deteriorates. It is necessary to perform control so as to be at intervals.
[0007]
Also, since UDP does not have a congestion control function like TCP, it is necessary for image transmission applications using UDP to always transmit and receive data at a transmission rate that does not exceed the network bandwidth. For example, when data that requires real-time performance is transmitted at a high transmission rate that exceeds the bandwidth of the communication path, the data transmitted to a buffer such as a router on the network is accumulated (congestion), thereby increasing transmission delay. Furthermore, when data exceeding the buffer capacity is transmitted, congestion exceeds the limit and the buffer overflows, causing a failure such as packet loss.
[0008]
As a conventional technology that takes measures against these errors and congestion, information such as packet loss rate and jitter from the receiving side is obtained from the RTCP report using RTCP, and transmission rate and error resilience parameters are transmitted based on this information. There is what is controlled on the side (see, for example, Patent Document 1 below).
[0009]
In addition, a packet transmission technique called multicast is considered to be effective for saving the transmission line use band. Packet transmission methods on the Internet include unicast, multicast, and broadcast. In unicast, a copy is transmitted from the transmission source to each client that has requested the data. In broadcast, one copy of data is sent to all clients on the network. In contrast, in multicast, only one copy of data is sent to the client group that requested the data. In recent years, although the bandwidth of transmission lines has been increased, when the same content is transmitted to a large number of clients, it is necessary to use the transmission path efficiently, and multicast is effective for this purpose.
[0010]
However, when considering transmission rate and GOP interval control on the transmission side based on packet loss rate and jitter information obtained from the reception side, the RTCP report is individually transmitted from each reception side, If processing is performed for all RTCP reports, a very high processing load is imposed on the transmission side. Further, since the number of RTCP reports to be transmitted increases as the number of clients increases, the bandwidth is wasted.
[0011]
In order to solve these problems, it is conceivable that RTCP reports from each client are aggregated, and the transmission rate and GOP interval are controlled based on the RTCP report from the client having the worst communication environment. However, since there is one stream transmitted from the transmission side in the multicast, the quality of data to be transmitted is lowered despite the presence of a client in a good communication environment, which is not preferable. On the other hand, when the RTCP report from the client with the best communication environment is used as a reference, the client in the bad communication environment cannot receive data normally.
[0012]
Hierarchical multicast is one of the prior arts that enables data transmission considering the diversity of communication environments on the client side (see, for example, Patent Document 2 below). In this hierarchical multicast, data of one stream is divided and distributed to the hierarchy, and stream data divided into different multicast groups according to the hierarchy is distributed. Each client having a different communication environment controls the hierarchy in which each receives data according to the state of the network. Thereby, distributed control of the reception rate is realized. In layered multicast, for example, the server divides one stream data into two layers, a layer including only intra-frame encoded frames and a layer including only inter-frame encoded frames. This divided hierarchy may be further divided into a hierarchy containing only the low frequency component of the frame and a hierarchy containing only the high frequency component of the frame.
[0013]
[Patent Document 1]
JP 2002-204278 A
[0014]
[Patent Document 2]
JP 2000-78573 A
[0015]
[Problems to be solved by the invention]
In the above-described hierarchical multicast method, it is possible to effectively use the transmission band in the wired network and perform quality management for various clients. However, there is a problem that both the hierarchical encoding processing load on the server side and the decoding processing load on the client side are extremely high as compared to the case where no hierarchization is performed. In addition, it is impossible to control parameters for error resilience, and a client with insufficient bandwidth receives only a part of a divided layer of one stream. Problems include the possibility of reception, the possibility of receiving a hierarchy including high-frequency components and a mismatch during decoding, and the possibility of image quality degradation due to failure in correct decoding.
[0016]
The present invention provides an apparatus capable of realizing adaptive data transmission for various transmission environments in which the receiving apparatus is placed without increasing the processing load on both the transmitting apparatus and the receiving apparatus, and It aims to provide a method.
[0017]
[Means for Solving the Problems]
A data transmission apparatus according to an aspect of the present invention includes an input unit that inputs a data signal, and first and second encoded data streams obtained by encoding the data signal using first and second encoding parameters. Packetizing the first encoded data stream and transmitting the packet to the first multicast address, and packetizing the second encoded data stream and transmitting the packet to the second multicast address. A parameter that transmits packet data in response to a request from the data receiving device, and parameter data representing the first and second encoding parameters in association with transmission parameters including the first and second multicast addresses. Transmitting means.
[0018]
According to another aspect of the present invention, there is provided a data receiving apparatus including: first and second encoded data streams generated by encoding the same data signal using first and second encoding parameters. Parameter receiving means for receiving parameter data representing the encoding parameter in association with transmission parameters including the first and second multicast addresses, and one of the first and second multicast addresses based on the parameter data Address selecting means for selecting, packet data receiving means for receiving one of the packet data of the first and second encoded data streams corresponding to the multicast address selected by the address selecting means, and the packet Decoding the packet data received by the data receiving means to convert the data signal And data reproducing means for raw, comprising a.
[0019]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
[0020]
(First embodiment)
Embodiments described herein relate generally to a data transmission system that performs transmission of moving image data by multicast. In this system, a data transmission device that transmits moving image data is referred to as a “server” or “transmission side”. This apparatus distributes a plurality of streams constructed by encoding an image signal of a moving image with different encoding parameters to different multicast addresses using, for example, a protocol such as RTP. A data receiving device that requests moving image data and receives it from the data transmitting device is called a “client” or “receiving side”. This device determines the state of a communication channel from information such as packet delay and loss, and selects one encoding parameter stream appropriate for the state of the communication channel from a plurality of streams transmitted from the transmission side. Receive from a multicast address.
[0021]
FIG. 1 is a block diagram showing an overall configuration of a data transmission system according to the first embodiment of the present invention. This data transmission system includes at least one server 2000 that is a data distribution device and at least one or more clients 1000a to 1000d that receive and reproduce content data (moving images in this case) transferred from the server 2000. Has been. The server 2000 and the clients 1000a to 1000d are connected via a network 3000. The server 2000 transmits one or more data streams S1 to S3 to different multicast address groups via the network 3000 by multicast. The clients 1000a to 1000d select and receive a data stream corresponding to the state of each communication path from the data streams S1 to S3. In addition, the clients 1000a to 1000d change the data stream to be dynamically received according to the change in the state of each communication path.
[0022]
FIG. 2 is a block diagram showing the internal configuration of the server. As shown in FIG. 2, the server 2000 encodes, for example, an image input unit 2100 that inputs an image signal of a video (moving image) captured by a video camera and an image signal 2006 obtained from the image input unit 2100 with different parameters. The image encoding units 2400a to 2400c to be converted and the encoded data 2005a to 2005c output from the image encoding units 2400a to 2400c are packetized, and each of the packetized encoded data 2004a to 2004c is transmitted to different multicast addresses. The packet data transmission unit 2200, different encoding parameters 2001 obtained from at least one of the image encoding units 2400a to 2400c, and the transmission destination when the packet data transmission unit 2200 packetizes and transmits each encoded data, for example Multichi Consisting parameter transmission unit 2300 transmits the parameter data 2003 corresponding is described with transmission parameters 2002, including strike address.
[0023]
In this embodiment, UDP / IP and RTP are used as protocols used for packet transmission. However, the present invention is not limited to these. The server shown in FIG. 2 is suitable for a live broadcast system, for example.
[0024]
In the server 2000 configured as described above, an image signal 2006 is first input from the image input unit 2100. The input image signal 2006 is encoded by the image encoding units 2400a to 2400c. At the time of this encoding, the image encoding units 2400a to 2400c perform encoding using different encoding parameters. For example, 2400a is encoded with a GOP interval of 2 s and a bit rate of 128 kbps, 2400b is encoded with a GOP interval of 0.5 s and a bit rate of 128 kbps, and 2400c is encoded with a GOP interval of 2 s and a bit rate of 64 kbps. Here, there are three image encoding units in the case of FIG. 2, but any number of image encoding units may be used as long as the number is one or more. The number of encoded data to be output also changes according to the number of image encoding units.
[0025]
The packet data transmission unit 2200 packetizes and transmits the encoded data 2005a to 2005c output from each of the image encoding units 2400a to 2400c. The transmission destination address at this time is a different multicast address for each encoded data. That is, for example, the encoded data 2005a is packetized and then transmitted to the multicast address “224.1.1.1”, and the encoded data 2005b is packetized and then the multicast address “224.1.1.2”. The encoded data 2005c is packetized and then transmitted to the multicast address “224.1.1.3”. In addition, for example, when RTP is used as a transmission protocol, these packet data can be transmitted with different payload numbers. For example, the packet data 2004a is transmitted with a payload number 96, the packet data 2004b is transmitted with a payload number 97, and the packet data 2004c is transmitted with a payload number 98.
[0026]
The parameter transmission unit 2300 transmits the parameter data 2003 describing the correspondence between the encoding parameters of the packet data 2004a to 2004c transmitted by the packet data transmission unit 2200 and the multicast address and payload number at the time of transmission. To do. In the parameter transmission unit 2300, the encoding parameters 2001 such as GOP interval and bit rate when the image encoding units 2400a to 2400c perform encoding, and the packet data transmission unit 2200 packetize each encoded data 2005a to 2005c, Parameter data 2003 in which transmission parameters 2002 such as a transmission destination multicast address and a payload number are associated with each other is transmitted. The data 2003 can be prepared in advance, and the image encoding unit 2400 and the packet transmission unit 2200 can set the encoding parameter and the packet transmission parameter by referring to this data. It is.
[0027]
Here, an example of the parameter data transmitted by the parameter transmission unit 2300 is shown in FIG. The parameter data includes, for example, a StreamNo for identifying one of at least one encoded data, a destination IP address when the encoded data is packetized and transmitted, a GOP interval of the encoded data, and the code This is data that associates the transmission rate of the digitized data with, for example, the payload number in the case of transmission using RTP. In the example of FIG. 3, the encoded data whose StreamNo is 1 is data encoded with a GOP interval of 2 seconds and an encoding rate of 128 kbps, and a multicast address “224.1.1.1” using the payload number 96. It can be seen that " In FIG. 3, Stream Nos. 1, 2, and 3 are parameters corresponding to, for example,

packet data

2004a, 2004b, and 2004c. FIG. 3 shows an example of the correspondence between encoding parameters and transmission parameters. For example, SDP (Session Description Protocol) is a standard that can describe such correspondence, and encoding is performed using data described in SDP. It is also possible to transmit data describing the correspondence between parameters and transmission parameters.
[0028]
FIG. 4 is a block diagram illustrating another configuration example of the server. As shown in FIG. 4, the server 2000 includes an encoded data storage unit 2600 that stores at least one encoded data 2610a to 2610c obtained by encoding the same image signal with different parameters in advance, and at least one encoded data. Corresponding to the encoding parameter 2001 obtained from the encoding information storage unit 2500 among the encoding data 2610a to 2610c from the encoding information storage unit 2500 for storing the encoding parameters 2610a to 2610c and the encoded data storage unit 2600. The encoded data read unit 2700a to 2700c for reading the encoded data to be packetized and the encoded data 2005a to 2005c output from the encoded data read units 2700a to 2700c are packetized and the packetized encoded data 2 When the packet data transmission unit 2200 that transmits 04a to 2004c to different multicast addresses, the encoding parameter 2001 obtained from the encoding information storage unit 2500, and the packet data transmission unit 2200 packetize and transmit the respective encoded data For example, a parameter transmission unit 2300 that transmits parameter data 2003 describing a correspondence with a transmission parameter 2002 including a destination multicast address.
[0029]
Here, the encoded data 2610a to 2610c are obtained by encoding the same image signal under different conditions. For example, 2610a is encoded with a GOP interval of 2 s and a bit rate of 128 kbps, 2610 b is encoded with a GOP interval of 0.5 s and a bit rate of 128 kbps, and 2610 c is encoded with a GOP interval of 2 s and a bit rate of 64 kbps. In FIG. 4, there are three data encoded in advance with different encoding parameters. However, any number of data may be used as long as it is one or more. The encoded information storage unit 2500 holds encoding parameters such as GOP intervals and bit rates corresponding to the encoded data 2610 and data describing the storage location.
[0030]
In the server 2000 having such a configuration, the encoded data reading units 2700a to 2700c read the encoded data stored in the encoded data storage unit 2600. At this time, the encoded data reading unit 2700 receives from the encoded data storage unit 2600 data 2001 describing the encoding parameters of the encoded data 2610a to 2610c stored in the encoded information storage unit 2600 and their storage locations. Referring to the storage location from, read out. Here, the number of the encoded data reading units 2700 is three in the case of FIG.
[0031]
The method in which the encoded data 2005a to 2005c read by the encoded data reading units 2700a to 2700c is packetized and transmitted by the packet transmitting unit 2200 is the same as that of the server shown in FIG.
[0032]
In the parameter transmission unit 2300, the correspondence between the encoding parameters of the packet data 2004a to 2004c transmitted by the packet data transmission unit 2200 and the encoding of each of the packet data 2004a to 2004c, for example, is determined. The described parameter data 2003 is transmitted. In parameter transmission unit 2300, encoding parameters 2001 such as GOP interval and bit rate when encoded data 2610a to 2610c are encoded, and packet data transmission unit 2200 packetizes each encoded data 2005a to 2005c for transmission. Data associated with the destination multicast address and payload number at the time of transmission. The parameter data 2003 is data as shown in FIG. 3, for example.
[0033]
The server shown in FIG. 4 is suitable for a content distribution system in which viewing content such as a broadcast program that has been photographed is encoded and stored in advance and content data requested by a client is distributed.
[0034]
In the configuration of FIG. 4, the encoded data storage unit 2600 and the encoded information storage unit 2500 described above may exist in the main memory of the computer, or may exist in a storage medium such as a flash memory or a hard disk. It may also exist on another server.
[0035]
In addition, among the components shown in FIG. 4, an encoded information storage unit 2500, an encoded data storage unit 2600, and an encoded data reading unit 2700 may be added to the configuration of FIG. In this case, the user needs a data distribution form such as (1) encoding and distributing input from a video camera, (2) distributing pre-encoded data, (3) or performing both at the same time. It is possible to realize a function that enables selection.
[0036]
Next, the configuration of the client 1000 will be described. FIG. 5 is a block diagram showing a basic configuration of the client 1000. The client 1000 includes a parameter data receiving unit 1100 that receives the parameter data 1601 transmitted by the server 2000 shown in FIG. 1, a packet data receiving unit 1300 that receives the packetized encoded data 1602 transmitted by the server 2000, The network state is determined from the packet information 1604 analyzed by the packet data receiving unit 1300, and the current network state is obtained from the parameter candidate data 1603 as a reception option obtained from the parameter data 1601 received by the parameter data receiving unit 1100. An appropriate encoded data parameter 1605 is selected, a network state determination unit 1200 that notifies the packet data receiving unit 1300, and an encoded data 1606 obtained from the packet data receiving unit 1300 is decoded. A decoding unit 1400, and an image output unit 1500 for outputting an image signal 1607 that has been decoded.
[0037]
In the client 1000 having such a configuration, in the parameter data receiving unit 1100, encoding parameters such as GOP intervals and bit rates of at least two or more data streams transmitted by the server 2000, a destination multicast address, and a payload number are preliminarily set. The parameter data 1601 associated with the transmission parameters such as is received and passed to the network state determination unit 1200.
[0038]
The network state determination unit 1200 selects parameter data of one data stream from the parameter data of at least two data streams distributed from the server based on the parameter data, and notifies the packet data reception unit 1300 of the parameter data. Here, in the network state determination unit 1200, the method of selecting the parameter of the data stream to be received first is, for example, selecting the stream with the longest or shortest GOP interval, or the stream with the highest or lowest bit rate. If the channel bandwidth is already known, select the stream with the highest bit rate below that bandwidth, or describe the default stream parameters in the parameter data. Various methods such as selecting a corresponding stream are conceivable. However, the present invention is not limited to those described here, and any method may be used as long as one of the methods is selected.
[0039]
The packet data reception unit 1300 starts receiving the stream data packet selected from the multicast address described in the parameter selected by the network state determination unit 1200. As a method of receiving a stream data packet, it is common to make a reception declaration (JOIN) to a multicast address of a multicast group to which the data stream is distributed (for example, according to IGMP (Internet Group Management Protocol)). is there.
[0040]
Encoded data 1606 (time information such as encoded data and time stamp) included in the packet data 1602 received by the packet data receiving unit 1300 is passed to the image decoding unit 1400 and decoded into an image signal 1607, The image is output to an image output unit 1500 such as a display device.
[0041]
Packet information 1604 including delay information (jitter) derived from the sequence number and arrival time included in the packet data 1602 is passed to the network state determination unit 1200. The network state determination unit 1200 determines the state of the communication path using this packet information, selects a data stream having a parameter suitable for the state, and notifies the packet data reception unit 1300 of switching information 1605 to perform switching. To do.
[0042]
FIG. 6 is a flowchart illustrating an example of processing in which the network state determination unit 1200 determines the state of a communication path using packet information and selects a data stream having parameters suitable for the state. As for the state of the communication path, for example, when communication is performed using RTP, the packet loss is derived from the discontinuity of the sequence number included in the packet information 1604 obtained from the packet receiving unit 1300. The delay is derived from the transmission time included in the packet information 1604 and the arrival time of the packet.
[0043]
In this example, first, in S9001, it is determined from the packet information whether the communication path is congested. In general, when a communication path is congested, a delay occurs. For example, using a delay d of a packet that arrives at a certain time and a delay threshold dth,
d> dth (1)
If the condition is satisfied, it is determined that the communication path is congested, and the process proceeds to step S9002.
[0044]
In addition, as a method for determining congestion, since the packet delay value may fluctuate rapidly, a method of using jitter for the purpose of absorbing the value may be considered. For example, using the jitter j and the jitter threshold jth of a packet that arrived at a certain point in time,
j> jth (2)
If the condition is satisfied, it is determined that the communication path is congested, and the process proceeds to step S9002. For example, RFC1889 can be referred to for determining the jitter.
[0045]
Further, when the value of jitter j also fluctuates abruptly, average jitter J = kj + (1−k) Jprev (k is a real value of 0 <k <1 and Jprev is Using the average jitter (previously calculated) and the threshold Jth of average jitter,
J> Jth (2 ')
If the condition is satisfied, it is determined that the communication path is congested, and the process proceeds to step S9002.
[0046]
Also, as congestion progresses, data sent to a buffer such as a router on the network accumulates, increasing transmission delay. If data exceeding the buffer capacity is sent after that, the buffer overflows and packet loss occurs. Therefore, a method of using the packet loss rate in a certain interval for determining congestion is also conceivable. For example, using a packet loss rate L of a certain interval and a threshold Lth of the packet loss rate,
L> Lth (3)
If the condition is satisfied, it is determined that the communication path is congested, and the process proceeds to step S9002. For example, RFC1889 can be referred to for obtaining the packet loss rate.
[0047]
Note that the congestion determination method mentioned here is merely an example, and for example, the threshold values of Expression (1) and Expression (2) (2 ′) are not constants, but change according to the bit rate of the received stream. Various determination methods such as using a value, determining, for example, congestion when the expressions (1) and (2) or (2 ') and (3) are satisfied at the same time, and using other expressions It can be set according to the network.
[0048]
Further, in this congestion determination process S9001, the network state determination unit 1200 is developed as shown in FIG. 7, and a network information storage unit 1220 is provided, and past packet information 1604 is accumulated in the network information storage unit 1220. The network information determination unit 1210 can also determine the temporal transition of the communication path state from the past packet information 1211 and the current packet information 1604. For example, a method of storing packet loss information that has occurred in the past and determining congestion using the number of times Lcount and threshold value Lcount_th that satisfy equation (3), for example, can be considered. In this case, for example,
Lcount> Lcount_th (4)
If the condition is satisfied, it is determined that the communication path is congested, and the process proceeds to step S9002.
[0049]
In this method, especially when data transmission is performed wirelessly, packet loss is caused not only by congestion, but also noise is generated on the line, and as a result of destroying data, the error is packetized. When there is a possibility of appearing as a loss, it is possible to prevent a packet loss due to an error from being determined as congestion only with a packet loss rate in a certain interval.
[0050]
On the other hand, if there is a small amount of packet loss that does not exceed Lth in equation (3) in a situation where there is a little congestion, for example, there is a possibility that congestion is not judged only by equations (3) and (4). . In such a case, it is considered that packets are randomly discarded in the buffer of the relay apparatus on the network, and the jitter value varies to some extent due to the discarding. By using this, for example, past average jitter is accumulated in the network information storage unit 1220, and the previous average jitter Jprev and the current average jitter Jnow variation value Jdelta = Jprev−Jnow are the threshold values of the jitter variation value. If Jdelta_th is exceeded, ie
Jdelta> Jdelta_th (5)
If the condition is satisfied, it is determined that the congestion is present, and the process proceeds to step S9002.
[0051]
In addition, when retransmission at the network layer is performed for errors that occur in the transmission path, it is observed as a significant delay at the client, resulting in jitter fluctuations, and the retransmission is erroneously determined as congestion. End up. Therefore, in such a case, it is not jitter. For example, the product of the packet delay d and the packet arrival interval i ri = d × i moving average RI = k · ri + (1−k) riprev (k is 0 <k <A real value of 1 and ripprev is a moving average of ri previously calculated), and a value obtained by absorbing a variation in delay due to retransmission by a packet arrival interval may be used as an index. However, it is necessary to acquire in advance a threshold for determining congestion based on this index, and an example of this acquisition method will be described below. First, when the network state determination unit 1200 selects a stream to be received first at the start of reception, the parameter of the stream with the lowest possibility of congestion and the lowest rate is selected and notified to the packet data reception unit 1300. Next, the packet data receiving unit 1300 starts receiving the stream data packet selected from the multicast address described in the parameter selected by the network state determining unit 1200, and after starting, the average value ri_th of ri of N packets Is calculated and notified to the network state determination unit 1200, and this value is used as a congestion determination threshold. When RI is γ times or more than ri_th, that is,
RI> ri_th × γ (real number with γ> 1) (6)
If the condition is satisfied, it is determined that the congestion is present, and the process proceeds to step S9002. After acquiring the threshold value, in order to effectively use the bandwidth, the packet reception unit 1300 is notified of switching information 1605 for switching to a stream parameter at a rate that is one step higher than the currently selected rate. The processing for recovering the rate may be repeated until it is determined that the congestion is caused by the equation (6) or until the highest rate among the selectable parameters.
[0052]
Thus, congestion can be determined more accurately by using the configuration of FIG.
[0053]
In step S9002, a reception parameter having a maximum bit rate that is less than the bit rate of the currently selected data stream is selected. Here, when there are a plurality of parameter data satisfying this condition, one of them is selected. For example, a method of selecting the one with the shortest GOP interval is conceivable. It is not limited to. However, when the switching process described later is taken into consideration, it is preferable that the GOP interval is short. The reason will be described later.
[0054]
This will be described with reference to the example of FIG. Currently StreamNo. 3 stream (64 kbps) is received, the stream having the maximum bit rate of less than 64 kbps is the StreamNo. 5 and 6, of which the stream No. is the shortest GOP interval. 6 is selected.
[0055]
In step S9003, the reception parameter of the selected stream is notified to the packet reception unit 1300 as switching information 1605.
[0056]
On the other hand, if it is determined in step S9002 that there is no congestion, the process is terminated without changing the stream.
[0057]
The packet receiving unit 1300 performs switching processing when switching information 1605 is passed, and FIG. 8 shows an example of this processing. In step S10001 of FIG. 8, first, reception of the packet of the data stream being received is terminated. As a method of ending the reception of the data stream packet, a reception end declaration (LEAVE) is made to the multicast address of the multicast group to which the data stream is distributed (for example, according to IGMP (Internet Group Management Protocol)). It is common. In step S10002, reception of the packet of the selected data stream is started. As this method, for example, there is a method of transmitting JOIN to a multicast address to which the packet of the data stream is transmitted. This switching process will be described using the above example. 3 is transmitted to the multicast address “224.1.1.3” to which the packet of the data stream 3 is transmitted. Switching can be performed by sending a JOIN to the multicast address “224.1.1.6” to which packets of 6 data streams are being sent. Here, the Stream No. that arrives for the first time after transmitting the JOIN. Since the 6-packet data is not necessarily a packet including data in the intra-frame coding mode (I picture), it cannot be normally decoded until a packet in the intra-frame coding mode is received for the first time after switching. This is because in inter-frame coding (P picture), the difference from the previous image is coded, and therefore, an attempt is made to decode using the last frame of the stream before switching. In order to shorten the time that cannot be normally decoded, it is effective that the stream that has started reception is a data stream with a short GOP interval, which is the one with the short GOP interval when performing the above selection. Is why. However, the switching method described here is merely an example, and it is possible to perform LEAVE after performing JOIN first, and it is possible to set a method suitable for the network. Other examples of this switching method will be described later.
[0058]
Note that this selection process is repeated, for example, at regular intervals, to follow changes in the state of the communication path.
[0059]
According to the first embodiment described above, by receiving a stream with different encoding parameters by switching the multicast address that is dynamically received from the state of the communication path, each receiver can respond to each environment. Stream can be received efficiently.
[0060]
Even if the bandwidth of the channel is unknown or changes in the middle, the receiving side judges the state of the channel from the packet information, etc., and if for some reason congestion occurs on the channel, the bit rate is reduced. By switching to this stream, packet loss due to congestion can be suppressed, and image data can be prevented from being destroyed due to packet loss for communication. Moreover, since these processes are performed for each client, the control load on the server side can be reduced.
[0061]
In addition, even when congestion occurs only on a communication path of a certain client, only that client can switch to a stream with a low bit rate, so each client is suitable for the state of each communication path. Stream can be provided.
[0062]
(Second Embodiment)
The second embodiment has the same configuration as that of the first embodiment shown in FIGS. 1, 2, 4, 5, and 7. However, in the network state determination and stream parameter selection processing in the network determination unit 1200 of FIG. 5, the first embodiment takes into account not only congestion on the communication path but also data errors caused by noise and the like. And different.
[0063]
FIG. 9 is a flowchart illustrating an example of processing in which the network state determination unit 1200 determines the state of a communication path using packet information and selects a data stream having a parameter suitable for the state. In this flowchart, first, the congestion determination in step S9001 uses the same method as in the first embodiment. Further, the process S9002 when it is determined that the process is congested in the process S9001 is the same as that in the first embodiment.
[0064]
If it is not determined in step S9001 that there is congestion, in the present embodiment, it is determined in step S9004 whether there is a packet loss. The determination of whether or not there is a packet loss can be determined that there is a loss, for example, when the packet sequence numbers included in the packet information 1604 obtained from the packet receiving unit 1300 are not consecutive. If there is packet loss despite not being determined to be congested, it is determined that an error has occurred on the communication path for some reason, and in processing S9005, for example, the same bit as the parameter currently being received from the parameter data 1601 Among the rate streams, a data stream having a parameter with the shortest GOP interval is selected. An example will be described using the parameter data example of FIG. When the stream No. 3 is received, the stream No. with the same bit rate (64 kbps) and the shortest GOP interval is used. Four streams are selected.
[0065]
In step S9004, the sequence number is used to determine whether or not there is a packet loss. However, if a small amount of packet loss does not affect the image reproduction so much, the packet loss rate L is set. It may be used. In this case, for example, the packet loss rate threshold Lerror_th (<Lth is used, for example,
Lerror> Lerror_th (7)
It may be determined that there is a loss if
[0066]
When changing the stream, processing S9003 for notifying the packet reception unit 1300 of the change and switching processing in the packet reception unit 1300 are the same as those in the first embodiment.
[0067]
Finally, in step S9004, if no packet loss occurs, it is determined that the state of the communication path is good, and no subsequent processing is performed.
[0068]
In addition, since the selection process follows a change in the state of the communication path, the selection process may be repeated, for example, at certain intervals, as in the first embodiment.
[0069]
In the present embodiment, it is first determined in step S9001 in FIG. 9 whether or not there is congestion, but it is assumed that there is no fluctuation in the band or that there is a sufficient margin in the band. When delivering one or more streams that differ only in the interval, it is possible to reduce the processing by omitting the processing of S9001 and S9002 and performing only the packet loss determination of processing S9004.
[0070]
According to the second embodiment of the present invention, it is possible to determine whether or not packet loss occurs due to a data error due to noise or the like as well as congestion. By switching to a stream with a short interval, error propagation due to packet loss can be suppressed without reducing the bit rate. Moreover, since these processes are performed for each client, the control load on the server side can be reduced. In addition, even if an error occurs only on the communication path of a certain client, only that client can be switched to a stream with a short GOP interval, so that a stream suitable for the state of each communication path is provided for each client. It is possible to provide.
[0071]
In the first embodiment and the second embodiment, when congestion or error occurs in the communication path, the stream is changed to a stream having a low bit rate or a stream having a short GOP interval. It is also possible to change to a stream with a long GOP interval. Such an example is shown in the third and fourth embodiments.
[0072]
(Third embodiment)
Similar to the second embodiment, the third embodiment has the same configuration as that of the first embodiment shown in FIGS. 1, 2, 4, 5, and 7. However, in the third embodiment, in the network state determination in the network determination unit 1200 of FIG. 5, when an error occurs locally, if the error does not occur for a certain period, the GOP interval is recovered long. The second embodiment is different from the second embodiment in that it can be configured.
[0073]
FIG. 10 is a flowchart illustrating an example of processing in which the network state determination unit 1200 determines the state of a communication path using packet information and selects a data stream having parameters suitable for the state. In this flowchart, the method for determining congestion in step S9001 uses the same method as in the first embodiment. Further, the process S9002 when it is determined that the process is congested in the process S9001 is the same as that in the first and second embodiments.
[0074]
If it is not determined in step S9001 that there is congestion, in the present embodiment, it is determined in step S9004 whether there is a packet loss. The determination of packet loss here and the stream selection processing S9005 for shortening the GOP interval when it is determined that there is packet loss are the same as in the second embodiment.
[0075]
If no packet loss has occurred in process S9004, it is determined that the communication state is good, and an attempt is made to recover the GOP interval in processes S9006 to S9007. In the example of the process of FIG. 10, in process S9003, the difference between the time when the previous loss was detected and the current time is calculated as a time T when no loss occurred, and an appropriate GOP interval T is used using this time T. _GOP Calculate This can be calculated by, for example, the following equation (7).
[0076]
T _GOP = T × α (8)
Here, α is a sensitivity coefficient, which is a value indicating the sensitivity of GOP interval recovery. If α is small, the recovery sensitivity becomes dull, and if α is large, the recovery sensitivity becomes sharp. For example, if the time when no packet loss occurs is 4 s and the value of the sensitivity coefficient α is 0.5, T _GOP = 4 × 0.5 = 2s.
[0077]
Next, in S9007, the stream having the same GOP interval as the currently received stream and having the closest GOP interval that does not exceed the appropriate GOP interval calculated in S9006 is selected. The example of parameter data in FIG. _GOP = 2s, an example will be described. 4 stream 5 is received at the same bit rate (64 kbps) and the nearest GOP interval not exceeding 2 s is 2 s. Three streams are selected. If T _GOP = 1 s, StreamNo. Four streams are selected.
[0078]
The processing S9003 for notifying the packet reception unit 1300 of the change of the stream and the switching processing in the packet reception unit 1300 are the same as those in the first and second embodiments.
[0079]
Since the selection process follows a change in the state of the communication path, it may be repeatedly performed, for example, at certain time intervals, as in the first and second embodiments.
[0080]
In this embodiment, it is first determined whether or not there is congestion in step S9001 in FIG. 10. However, one or more streams in which there is no fluctuation in the band and only the GOP interval is different at the same bit rate are distributed. In this case, it is also possible to reduce the processing load by omitting the processes S9001 and S9002 from the beginning and performing only the packet loss determination in the process S9004.
[0081]
According to the third embodiment of the present invention described above, when an error occurs on the communication path and this is dealt with by shortening the GOP interval, the GOP interval is increased when the state of the communication path improves. It is possible to recover and provide a higher quality stream. Moreover, since these processes are performed for each client, the control load on the server side can be reduced. The point that it is possible to provide a stream suitable for the state of each communication path for each client is the same as in the first and second embodiments.
[0082]
(Fourth embodiment)
Also in the fourth embodiment, similar to the second and third embodiments, the configuration common to that shown in FIGS. 1, 2, 4, 5, and 7 in the first embodiment is used. Have. In the fourth embodiment, in the network state determination in the network determination unit 1200 of FIG. 5, it is determined whether there is a margin in the bandwidth of the communication path, and if there is a margin, a stream with a high bit rate is selected, It differs from the third embodiment in that the bit rate can be recovered.
[0083]
FIG. 11 is a flowchart illustrating an example of processing in which the network state determination unit 1200 determines the state of a communication path using packet information and selects a data stream having parameters suitable for the state. In this flowchart, the method of determining congestion in step S9001 uses the same method as in the first to third embodiments. Further, the process S9002 when it is determined that the process is congested in the process S9001 is the same as that in the first to third embodiments.
[0084]
If it is not determined in step S9001 that there is congestion, it is determined in step S9004 whether there is a packet loss. The determination of packet loss here and the stream selection processing S9005 for shortening the GOP interval when it is determined that there is packet loss are the same as in the third embodiment.
[0085]
In the case where it is determined in step S9004 that there is no packet loss, in the present embodiment, in step S9008, it is determined whether or not there is a sufficient bandwidth. With respect to this determination, for example, when the average jitter value Jnow of the received packet at that time is set as a margin of the bandwidth, and this average jitter value Jnow falls below a sufficiently small threshold value Jup_th, that is,
Jnow <Jup_th (9)
When satisfying, it is determined that there is room in the bandwidth. However, the method of determining whether or not there is a margin in this band is not limited to this. For example, it is determined whether or not the delay d is a sufficiently small value, or Jup_th is received in Expression (9). A value that changes according to the bit rate of the stream being used, or a bit rate difference between the stream bup having the next highest bit rate after the bit rate bnow of the stream being received bdelta = bnow-a value that changes according to bup A method such as using can be considered.
[0086]
Further, when retransmission at the network layer is performed for an error occurring in the transmission path, for example, the moving average RI of the product of the delay of the received packet and the arrival interval of the packet at that time is (6) When the value is less than δ times the threshold value ri_th used in the equation,
RI <ri_th × δ (10)
A method such as determining that there is room in the band when satisfying the above condition is also conceivable.
[0087]
If it is determined in step S9008 that the bandwidth is sufficient, the process proceeds to step S9009, and a reception parameter having a minimum bit rate that is larger than the bit rate of the currently selected data stream is selected. Here, if there are a plurality of parameter data satisfying this condition, one of them is selected. For example, a method of selecting the shortest GOP interval is conceivable as the selection method, but is not limited thereto. However, as described above, in order to shorten the time that cannot be normally decoded that occurs at the time of switching, it is preferable that the GOP interval is short. This will be described with reference to the example of FIG. Currently StreamNo. 3 stream (64 kbps) is received, the stream having the maximum bit rate of less than 64 kbps is the StreamNo. 1 and 2 (128 kbps). Among these, as the shortest GOP interval, Stream No. 2 is selected.
[0088]
If it is determined in step S9008 that there is no room in the bandwidth, a process for trying to recover the GOP interval is performed. The processes S9006 and S9007 are the same as those in the third embodiment.
[0089]
The processing S9003 for notifying the packet reception unit 1300 of the change of the stream and the switching processing in the packet reception unit 1300 are the same as those in the first to third embodiments.
[0090]
In order to follow the change in the state of the communication path, the selection process may be repeatedly performed, for example, every certain time, as in the first to third embodiments.
[0091]
In this embodiment, it is assumed that no error occurs in the communication path in FIG. 11, and when one or more streams having only the same GOP interval are distributed, processing S9004, S9005, and processing S9006, If S9007 is omitted and the process S9001 is not congested, the process proceeds to process S9008, and it is possible to reduce the process by only determining whether it is congested and whether there is a bandwidth.
[0092]
According to the fourth embodiment of the present invention described above, it is determined whether or not there is a margin in the bandwidth of the communication path, and when there is a margin, the bit rate can be recovered high, so that the bandwidth is wasted. Can be used without any problem to provide a high-quality stream. Since these processes are performed for each client, the control load on the server side can be reduced, and a stream suitable for the state of each communication path can be provided for each client. Is the same as in the first to third embodiments.
[0093]
In the fourth embodiment, it is determined whether or not there is a margin in the bandwidth. However, since it is not determined whether or not there is a margin, the bandwidth is exceeded as a result of restoring the bit rate, and congestion is caused. May be incurred. Furthermore, by repeatedly performing the selection process, there is a possibility that the recovery of the bit rate and the congestion will be repeated, and conversely, the video will be difficult to see. In order to suppress such a phenomenon, an example in which a stream can be provided stably based on the history of past stream switching will be described in a fifth embodiment.
[0094]
(Fifth embodiment)
In the fifth embodiment, the configurations shown in FIGS. 1, 2, 4, and 5 are the same as those in the first to fourth embodiments. As shown in FIG. 12, a network information storage unit 1220 for accumulating packet information 1604 from the packet receiving unit 1300 and a parameter of a stream selected in the past are included in the network state determination unit 1200 of FIG. Fourth, the reception parameter information storage unit 1230 for accumulating 1605 is provided, and the determination using the history 1212 of the stream selected in the past is performed in the state determination process in the network state determination unit 1200. This is different from the embodiment.
[0095]
FIG. 13 shows an example of processing for determining the state of a communication path using packet information and selecting a data stream having parameters suitable for the state in the network state determination unit 1210 (FIG. 12) of this embodiment. It is a flowchart. In this flowchart, the method of determining congestion in step S9001 uses the same method as in the first to fourth embodiments. Further, the process S9002 when it is determined that the process is congested in the process S9001 is the same as that in the first to fourth embodiments.
[0096]
Next, the processing proceeds to step S9010. Here, it is determined whether or not the previous switching was a recovery of the bit rate. This determination is made by obtaining the switching information history 1212 from the reception parameter information storage unit 1230 in FIG. When the previous switching is recovery of the bit rate and congestion occurs after the switching, it is determined that the recovery is not appropriate. Therefore, the process proceeds to step S9011, and in the process S9008 for determining whether there is a margin in the case where there is no congestion, the threshold value Jup_th of the equation (8) Jnow <Jup_th for determining that there is a margin is further reduced. For example,

The threshold value Jup_th is corrected as follows. Thereby, in the determination of whether or not there is a margin in the next band, the probability that it is determined that there is a margin in the band is low. Similarly, when RI is used as an index when delay varies due to retransmission in the network layer, in order to further reduce the threshold value ri_th used in equation (10), for example,

It is good.
[0097]
If it is not determined in step S9001 that there is congestion, it is determined in step S9004 whether there is a packet loss. The determination of packet loss here and the stream selection processing S9005 for shortening the GOP interval when it is determined that there is packet loss are the same as in the fourth embodiment. If no packet loss has occurred in S9004, a process S9008 for determining whether there is a bandwidth is performed. This process is the same as in the fourth embodiment.
[0098]
Furthermore, the process S9009 for selecting a stream that recovers the bit rate when it is determined in the process S9008 that there is a sufficient bandwidth is the same as in the fourth embodiment. Also, in processing 9008, processing S9006 and S9007 that attempt to recover the GOP interval when it is determined that there is no room in the band are the same as in the fourth embodiment.
[0099]
The processing S9003 for notifying the packet reception unit 1300 of the change of the stream and the switching processing in the packet reception unit 1300 are the same as those in the first to fourth embodiments.
[0100]
In order to follow the change in the state of the communication path, the selection process may be repeatedly performed, for example, at certain intervals, as in the first to fourth embodiments.
[0101]
In this embodiment, it is assumed that no error occurs in the communication path in FIG. 11, and when one or more streams having only the same GOP interval are distributed, processing S9004, S9005, and processing S9006, If S9007 is omitted and the process S9001 is not congested, the process proceeds to process S9008, and it is possible to reduce the process by only determining whether it is congested and whether there is a bandwidth.
[0102]
Further, when this embodiment is modified and the same bit rate is received for a certain period in the past switching history 1212, the threshold value of the average jitter in the determination in the process S9008 is set to, for example,

It is also possible to make it easier to follow the situation when the bandwidth of the communication path is recovered by changing the size so that it becomes larger and making it easier to recover the bit rate. Similarly, in the case where RI is used as an index when there is a variation in delay due to retransmission in the network layer, in order to increase the threshold value ri_th used in equation (10), for example,

It is good.
[0103]
According to the fifth embodiment of the present invention described above, even when the bandwidth is exceeded and congestion is caused as a result of restoring the bit rate, the threshold value is corrected using the past stream switching history. Thus, the recovery of the bit rate and the repetition of congestion can be appropriately suppressed, so that stable stream provision can be realized. Moreover, since these processes are performed for each client, the control load on the server side can be reduced. As in the first to fourth embodiments, it is possible to provide a stream suitable for the state of each communication path for each client.
[0104]
In the first to fifth embodiments described above, in the stream reception switching process in the packet reception unit 1300, decoding cannot be performed normally until a packet in the intra-frame coding mode is received for the first time after switching. . A method for suppressing such a phenomenon will be described below.
[0105]
This is an extension of the packet receiving unit 1300 in the client configuration shown in FIG. 5, and can be applied as an example in which a part of the first to fifth embodiments described so far is developed. is there. As shown in FIG. 14, an intra-frame coding determination unit 1321, a switching control unit 1322 and a packet data receiving unit 1323 are provided inside. According to this configuration, the packet information 1604 received by the packet data receiving unit 1323 is passed to the network state determination unit 1200, such as header information such as the sequence number and time stamp of the packet, and packet arrival time. The process of selecting a stream described in the fifth embodiment is performed. Here, when the stream is changed, the switching information 1605 including the reception parameter of the changed stream is passed from the network state determination unit 1200 to the switching control unit 1322. Also, the packet 1602 received by the packet data receiving unit 1323 is passed to the intraframe coding determination unit 1321. The intra-frame encoding determination unit 1321 determines whether the encoded data included in the packet is intra-frame encoded data or inter-frame encoded data, and the result is the data 1324 added to the packet 1602 switching control unit Pass to 1322.
[0106]
Upon receiving the switching information 1605, the switching control unit 1322 performs a switching process as shown in FIG. First, in process S11001, it is determined whether there is a margin in the reception band. For this determination, the average jitter of the packet is calculated from the header information such as the sequence number and time stamp of the packet included in the data 1324 passed from the intra-frame encoding determination unit 1321 and the arrival time of the packet. This is performed using the equation (9) shown in the embodiment.
[0107]
If it is determined that the bandwidth is sufficient, the process proceeds to step S11002, and the reception of the stream is started (JOIN) from the multicast address of the reception parameter after the change included in the switching information 1605.
[0108]
Next, the processing proceeds to step 11003, and it is determined whether the received packet of the changed stream is intra-frame encoded. This uses the determination result included in the data 1324 passed from the intra-frame encoding determination unit 1321, and the determination as to whether or not the stream has been changed is based on the destination multicast address and payload number included in the packet header. To do. Here, until the packet including the encoded data encoded in the frame with the stream after the change is received, the encoded data 1606 included in the packet including the stream before the change is output to the image decoding unit 1400. The packet including the changed stream is discarded. If the received packet of the stream after the change is a packet including encoded data that has been intra-frame encoded, the process proceeds to step S11004, and the image decoding unit 1400 performs the encoding included in the packet of the stream before the change. The output of data is stopped and the subsequent packets are discarded, and the encoded data 1606 included in the packet of the changed stream is output.
[0109]
Finally, in process S11005, the reception of the stream from the multicast address of the stream before the change is stopped (LEAVE).
[0110]
In this series of processing (S11002 to S11005), the pre-change stream and the post-change stream are temporarily received at the same time by making use of the bandwidth, and the intra-frame encoded data of the post-change stream is stored. By switching the stream output to the image decoding unit 1400 after waiting for arrival, it is possible to perform smooth switching without interruption.
[0111]
This will be described using a specific example. In FIG. 16, when switching occurs, the stream before the change (the 224.1.1.1 stream) is received. At this time, first, reception (JOIN) of the stream to be changed (the stream of 224.1.1.2) is started. Next, the reception of the stream before the change is stopped (LEAVE) by switching the stream to be output when the first intra-frame encoded packet 16001 is received after the reception of the stream after the change is started. By doing this, the stream before output is output until the intra-frame encoded frame arrives, and the output stream is switched to the destination stream when the intra-frame encoded frame arrives. Therefore, it is possible to provide a video without disturbance. However, since two streams are received simultaneously during switching, it is necessary to determine in S11001 whether there is sufficient bandwidth.
[0112]
On the other hand, if it is determined in step S11001 that the bandwidth is not sufficient, the process proceeds to step S11006, and reception of the stream from the multicast address of the stream before the change is stopped (LEAVE). In step S11007, stream reception is started (JOIN) from the multicast address of the changed reception parameter included in the switching information 1605. Next, the processing proceeds to processing 11008, and it is determined whether or not the received packet of the stream after the change is intraframe encoding by the same method as the processing 11003. Here, until the packet including the encoded data encoded in the frame with the stream after the change is received, the encoded data 1606 included in the packet including the stream before the change is output to the image decoding unit 1400. The packet including the changed stream is discarded. If the received packet of the stream after the change is a packet including encoded data that has been intra-frame encoded, the process proceeds to step S11009, and the encoding included in the packet of the stream before the change is performed on the image decoding unit 1400. The output of data is stopped and the subsequent packets are discarded, and the encoded data 1606 included in the packet of the changed stream is output.
[0113]
In this series of processing (S11006 to S11007), the reception of the stream after the change is started after the reception of the stream before the change is stopped, and the image after waiting for arrival of the intra-frame encoded data of the stream after the change By switching the stream to be output to the decoding unit 1400, the use band is suppressed, and the image is temporarily stopped at the last frame of the stream before the change until the intra-coded data of the stream after the change is received. However, it is possible to perform smooth switching without causing image disturbance due to switching.
[0114]
This will be described using a specific example. In FIG. 17, when switching occurs, the stream before the change (224.1.1.1 stream) is received. First, the stream before the change (224.1.1.1 stream) is received. After the reception is stopped (LEAVE), the reception of the changed stream (the 224.1.1.2 stream) is started (JOIN). As a result, it is not necessary to receive two streams at the same time as in the example of FIG. 16, and the bandwidth can be saved. Next, the stream to be output is switched when the first intra-frame encoded packet 17001 is received after reception of the changed stream is started. During this time, the output stream is stopped at the frame received at the end of the stream before the change, but the output stream is switched from the frame that was just encoded within the frame, and it is possible to provide an undisturbed video. .
[0115]
In steps S11006 to S11007, the image is temporarily stopped at the last frame of the stream before the change until the intra-frame encoded data of the stream after the change is received. . When it is known that frames encoded within a frame at regular intervals are included, it is conceivable to control the switching timing by predicting the time when the next frame encoded within a frame is transmitted. For example, the next intra-frame encoding is performed from the time Tfirst_send at which the first packet of the stream that can be acquired from the RTCP transmitted from the server 2000 is transmitted, the current time t, and the GOP interval Igop that can be acquired from the parameter data. A time Tnext_ivop_send at which a packet including data is transmitted on the server side is estimated as follows.
[0116]

In order to meet this time, for example, a time Tchange earlier than this time by the sum of the packet delay d and the packet delay variation d ′, that is,

If processing 11006 to processing 11007 are executed at the same time, switching can be performed in accordance with arrival of a packet including the next intra-frame encoded data, and the time during which video is stopped at the time of switching can be kept short.
[0117]
In addition, another method is provided for suppressing the stoppage of an image due to switching. Unlike the above method, this method can be used even if there are no frames that are intra-coded at regular intervals. That is, the time Tnext_ivop_send at which a packet including the frame encoded in the next frame of the changed stream is transmitted to the server 2000 using, for example, an RTSP GET_PARAMETER command. After that, if processing 11006 to processing 11007 are executed at the time Tchange calculated by, for example, the equation (16) as in the above method, switching is performed in accordance with arrival of a packet including the next intra-frame encoded data. It is possible to shorten the time during which the video stops at the time of switching. Regarding the control of the time at which the processing 11006 to processing 11007 is performed, the method described above is an example, and the time Tnext_ivop_send at which the server 2000 transmits a packet including the next intra-frame encoded data of the changed stream is set. If it is the method of acquisition or estimation, it is possible to control switching time using (16) Formula.
[0118]
By applying the switching method as described above to the first to fifth embodiments, when switching to a suitable stream that follows the state of the communication path, the switching method according to the margin of the band is switched smoothly. Switching becomes possible.
[0119]
In the embodiment described above, data transmission is performed via multicast on the network 3000 from the server 2000 to each client 1000 as shown in FIG. 1, but for example, portable terminals are assumed as the clients 1000a to 1000b. In this case, as shown in FIG. 18, the terminal node from the network 3000 to the clients 1000a to 1000b is the base station 4000, the server 2000 to the base station 4000 is transmitted by multicast, and the base station 4000 to the clients 1000a to 1000b are You may transmit using a unicast. Further, the end node from the network 3000 to, for example, the clients 1000c to 1000d is a switch 5000 having a function of monitoring a participation / non-participation in a multicast group and controlling a stream to be transferred to a downstream node. Only the streams received by the clients 1000c and 1000d can be transmitted between the client 1000c and the client 1000d. Thus, in the present invention, a switch that uses unicast or controls multicast traffic may be included in a part of the communication path from the server to the client. In particular, as in the example of FIG. 18, unicast transmission is performed from the end node (base station or switch) of the network that is likely to cause errors and bandwidth fluctuations to the client, or the end node is a switch having a multicast traffic control function. Thus, the present invention is more effective by controlling the transmitted stream.
[0120]
Note that the present invention is not limited to the above-described embodiment as it is, and can be embodied by modifying the constituent elements without departing from the scope of the invention in the implementation stage. In addition, various inventions can be formed by appropriately combining a plurality of components disclosed in the embodiment. For example, some components may be deleted from all the components shown in the embodiment. Furthermore, constituent elements over different embodiments may be appropriately combined.
[0121]
【The invention's effect】
As described above, according to the present invention, adaptive data transmission can be performed for various transmission environments in which a receiving apparatus is placed without increasing the processing load on both the transmitting apparatus and the receiving apparatus. Devices and methods can be provided that can be implemented.
[Brief description of the drawings]
FIG. 1 is a block diagram showing an overall configuration of a data transmission system according to an embodiment of the present invention.
FIG. 2 is a block diagram showing the internal configuration of the server
FIG. 3 is a diagram illustrating an example of parameter data transmitted by a parameter transmission unit.
FIG. 4 is a block diagram illustrating another configuration example of the server.
FIG. 5 is a block diagram showing a basic configuration of a client
FIG. 6 is a flowchart illustrating an example of processing for selecting a data stream having parameters suitable for the state of a communication path.
FIG. 7 is a block diagram illustrating another configuration example related to congestion determination in the network state determination unit;
FIG. 8 is a flowchart illustrating an example of switching processing in a packet reception unit.
FIG. 9 is a flowchart illustrating an example of processing for selecting a data stream having parameters suitable for a communication path state in a network state determination unit according to the second embodiment of the present invention.
FIG. 10 is a flowchart according to the third embodiment of the present invention, showing another example of processing for selecting a data stream having parameters suitable for the communication path state in the network state determination unit;
FIG. 11 is a flowchart illustrating still another example of processing for selecting a data stream having a parameter suitable for a communication path state in a network state determination unit according to the fourth embodiment of the present invention.
FIG. 12 is a block diagram showing a configuration of a network state determination unit according to the fifth embodiment of the present invention.
FIG. 13 is a flowchart illustrating an example of processing for selecting a data stream having a parameter suitable for a communication path state in a network state determination unit according to the fifth embodiment of the present invention.
FIG. 14 is a block diagram illustrating a configuration example of a packet data receiving unit according to a modification of the embodiment;
FIG. 15 is a flowchart illustrating a switching process based on switching information by a switching control unit according to the modification example;
FIG. 16 is a conceptual diagram for explaining stream switching according to the modification example;
FIG. 17 is a conceptual diagram for explaining stream switching according to the modification example;
FIG. 18 is a system configuration diagram according to a modification of the embodiment.
[Explanation of symbols]
1000a to d ... client (data receiving device), 2000 ... server (data transmitting device), 3000 ... network

Claims

An input means for inputting a data signal;
Encoding means for encoding the data signal using first and second encoding parameters to generate first and second encoded data streams;
Packet data transmission means for packetizing the first encoded data stream and transmitting the packet to the first multicast address, and packetizing the second encoded data stream and transmitting the packet to the second multicast address;
Parameter transmitting means for transmitting parameter data representing the first and second encoding parameters in association with transmission parameters including the first and second multicast addresses in response to a request from a data receiving device;
A data transmission device comprising:

Storage means for storing first and second encoded data streams generated by encoding the same data signal using the first and second encoding parameters;
Reading means for reading the first and second encoded data streams from the storage means in response to a request from the data receiving device;
The first encoded data stream read by the reading unit is packetized and transmitted to the first multicast address, and the second encoded data stream read by the reading unit is packetized and second Packet data transmission means for transmitting to the multicast address of
Parameter data representing the respective encoding parameters of the first and second encoded data streams in association with the transmission parameters including the first and second multicast addresses is transmitted in response to a request from the data receiving apparatus. Parameter transmission means for
A data transmission device comprising:

The encoding parameters of the first and second encoded data streams generated by encoding the same data signal using the first and second encoding parameters include the first and second multicast addresses. Parameter receiving means for receiving parameter data associated with transmission parameters;
Address selection means for selecting one of the first and second multicast addresses based on the parameter data;
Packet data receiving means for receiving packet data of one of the first and second encoded data streams corresponding to the multicast address selected by the address selecting means;
Data reproducing means for decoding the packet data received by the packet data receiving means and reproducing the data signal;
A data receiving apparatus comprising:

Network state determining means for determining a communication state of a transmission path based on packet data received by the packet data receiving means;
Based on the communication state determined by the network state determination means, congestion determination means for determining whether congestion is currently occurring in the transmission path;
When it is determined by the congestion determination means that congestion has occurred, the packet data of any one of the first and second encoded data streams capable of reducing the occupied bandwidth of the transmission path is received. Address switching means for switching the first and second multicast addresses from one to the other;
The data receiving device according to claim 3, further comprising:

The data receiving apparatus according to claim 4, wherein the packet data used for determining the communication state includes at least one of packet delay time, packet loss, and packet arrival interval.

Network information storage means for storing network information representing the communication state determined by the network state determination means;
Whether the congestion determination unit is currently congested in the transmission path based on the past network information stored in the network information storage unit and the current communication state determined by the network state determination unit. The data receiving device according to claim 4, wherein it is determined whether or not.

Further comprising parameter storage means for storing parameter data received by the parameter receiving means;
The congestion determination unit is configured to determine whether congestion is currently occurring in the transmission path based on past parameter data stored in the parameter storage unit and a current communication state determined by the network state determination unit. The data receiving device according to claim 4, wherein the data receiving device determines whether or not.

Detecting means for detecting whether packet loss has occurred in the packet data received by the packet data receiving means;
Measuring means for measuring a time interval of packet loss detected by the detecting means;
The data receiving apparatus according to any one of claims 4 to 7, further comprising means for controlling selection of a multicast address by the address selecting means according to the length of the time interval.

A calculation means for calculating a margin of the bandwidth of the transmission path;
8. The data receiving apparatus according to claim 4, further comprising means for comparing the margin calculated by the calculating means with a threshold value and controlling selection of a multicast address by the address selecting means according to the comparison result. .

Calculation means for calculating an estimated transmission time of the encoded stream encoded in the frame;
Multicast address selection by the address selection unit is controlled based on the estimated transmission time so that the reproduction of the data signal by the data reproduction unit does not stop due to the non-delivery of the encoded stream encoded in the frame. The data receiving device according to claim 8, further comprising means for performing the processing.

An input step for inputting a data signal;
An encoding step of encoding the data signal using first and second encoding parameters to generate first and second encoded data streams;
Packetizing the first encoded data stream and transmitting it to a first multicast address, and packetizing the second encoded data stream and transmitting it to a second multicast address; and
Parameter data representing the respective encoding parameters used to generate the first and second encoded data streams in association with the transmission parameters including the first and second multicast addresses are transmitted from the data receiving apparatus. A parameter sending step to send upon request;
A data transmission method comprising:

A storing step of storing first and second encoded data streams generated by encoding the same data signal using first and second encoding parameters;
A reading step of reading out the first and second encoded data streams stored in the storing step in response to a request from a data receiving device;
The first encoded data stream read in the reading step is packetized and transmitted to the first multicast address, and the second encoded data stream read in the reading step is packetized and second Packet data transmission step for transmitting to the multicast address of
Parameter data representing the respective encoding parameters of the first and second encoded data streams in association with the transmission parameters including the first and second multicast addresses is transmitted in response to a request from the data receiving apparatus. A parameter transmission step to perform,
A data transmission method comprising:

Each encoding parameter of the first and second encoded data streams generated by encoding the same data signal using the first and second encoding parameters includes the first and second multicast addresses. A parameter receiving step for receiving parameter data associated with a transmission parameter;
An address selection step of selecting one of the first and second multicast addresses based on the parameter data;
A packet data receiving step of receiving packet data of one of the first and second encoded data streams corresponding to the multicast address selected in the address selection step;
A data reproduction step of decoding the packet data received in the packet data reception step to reproduce the data signal;
A data receiving method comprising:

A network state determining step for determining a communication state of a transmission path based on the packet data received in the packet data receiving step;
Based on the communication state determined in the network state determination step, a congestion determination step for determining whether congestion is currently occurring in the transmission path;
When it is determined in the congestion determination step that congestion has occurred, the packet data of any one of the first and second encoded data streams capable of reducing the occupied bandwidth of the transmission path is received. An address switching step of switching the first and second multicast addresses from one to the other;
The data receiving method according to claim 13, further comprising:

15. The data reception method according to claim 14, wherein the packet data used for determining the communication state includes at least one of packet delay time, packet loss, and packet arrival interval.

A network information storage step of storing network information representing the communication state determined in the network state determination step;
In the congestion determination step, based on the past network information stored in the network information storage means and the current communication state determined in the network state determination step, is congestion currently occurring in the transmission path? The data receiving method according to claim 14 or 15, wherein it is determined whether or not.

A parameter storing step of storing the parameter data received in the parameter receiving step;
In the congestion determination step, based on the past parameter data stored in the parameter storage step and the current communication state determined in the network state determination step, whether or not congestion is currently occurring in the transmission path. The data receiving method according to claim 14 or 15, wherein the data receiving method is determined.

A detecting step for detecting whether or not packet loss has occurred in the packet data received in the packet data receiving step;
A measurement step of measuring a time interval of packet loss detected in the detection step;
The data receiving method according to claim 14, further comprising a step of controlling selection of a multicast address in the address selection step according to the length of the time interval.

A calculation step of calculating a margin of the bandwidth of the transmission path;
The data receiving method according to any one of claims 14 to 17, further comprising a step of comparing the margin calculated in the calculating step with a threshold value and controlling selection of a multicast address in the address selecting step according to the comparison result. .

A calculation step for calculating an estimated transmission time of an intra-frame encoded encoded stream;
Multicast address selection in the address selection step is controlled based on the estimated transmission time so that reproduction of the data signal in the data reproduction step does not stop due to non-delivery of the encoded stream encoded in the frame The data receiving method according to claim 18 or 19, further comprising a step of: