JP2011082934A - ストリームデータ送信装置、方法、及びプログラム - Google Patents

Abstract

【課題】 ネットワークを介して受信側で視聴される映像や音声の品質が所望の品質となるように送信側で制御することを可能にする技術の提供。
【解決手段】 配信サーバ１００のデータ組合せ部１４０は、映像データ格納部１１０に格納される符号化データを読み込んで、ＴＳパケットを作成し、この符号化データを含むＴＳパケットに、ダミーデータ生成部１３０で生成されるダミーパケットを追加して、一つのＩＰパケットを生成する生成動作を、繰り返し行う。データ配信部１５０は、映像データの符号化レートから定まるＩＰパケットの出力レートよりも、ダミーパケットの追加に応じて速くした出力レートで、生成されたＩＰパケットをネットワーク２００へ送り出す。
【選択図】 図１

Description

本発明は、映像や音声等のストリームデータを、インターネット等のネットワークを介して伝送する場合に、受信側で視聴される映像や音声の品質が所望の品質となるように、送信側で制御するための技術に関する。

近年、配信サーバに蓄積された映像や音声等のストリームデータを、インターネット等のネットワークを介して、当該配信サーバに接続されたユーザ側のコンピュータへ配信するサービスが、普及してきている。このような配信サービスを提供する事業者（コンテンツプロバイダ）は、ネットワークサービスを提供する事業者（通信キャリア）と、利用可能な通信帯域の契約をした上で、配信サービスの顧客の端末（クライアント）へコンテンツを送信するが、その映像や音声の実際の品質は、ネットワークで起こるデータの欠損や、伝送の遅延により、大きく影響され、これを視聴する顧客の満足度を左右する。

しかし、通信キャリアによる多くのネットワークサービスは、そのサービスを受ける契約者に対し、利用可能な通信帯域を常に保証するものではないため、コンテンツプロバイダ側は、自身の顧客が視聴する映像や音声の品質を確保する術がないというのが実情である。

通信キャリアではなく、ネットワークサービスを受ける側で、ネットワークにおけるストリームデータの伝送品質を測定することを可能にする技術としては、インターネット・プロトコル（ＩＰ）上で音声通話を実現するＩＰ電話サービスに関するものとして、以下のような測定手法がある。

特許文献１には、ＩＰ電話網における音声パケットの伝送品質を測定するため、発呼側と着呼側のＩＰ電話の近くにそれぞれ、ネットワークからはＩＰ電話として認識されるパケット測定器を設置し、この測定器が、音声パケットに擬似する（音声パケットと同じヘッダを有する）測定パケットを、対向する測定器に対して送出することにより、音声パケットの伝送品質の測定を可能にする技術が、開示されている。

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

上述した従来技術のような手法では、実際に配信されるストリームデータ（ＩＰ電話の例では、ＩＰ電話間で送受信される実際の通話音声パケット）とは別の、測定用のストリームデータ（ＩＰ電話の例では、パケット測定器間で送受信される擬似測定パケット）について、データの欠損や伝送遅延を測定して、それにより、実際に配信されるストリームデータにも同様の欠損や遅延が起きているものと推測することになる。

この点に関し、特許文献１には、音声パケットと同じヘッダを有する測定パケットを送信するから、通話に用いられるＩＰパケットの通信が優先されて測定パケットの通信が後回しにされてしまうことがなく、パケット受信タイミング、受信間隔、受信順序が本来とは異なってしまうことがないから、測定精度が向上すると記載されている。

しかし、それでも、実際の通話音声パケットと測定用パケットとが、別々のＩＰパケットとしてネットワーク内を転送されている以上は、測定パケットについての伝送品質が、実際の通話音声パケットの伝送品質を正確に表しているとはいえない。

つまり、実際に配信されるストリームデータとは別に、擬似の測定用データを配信し、擬似の測定用データについて、データの欠損や伝送遅延があったということが測定されても、実際のストリームデータへの影響を直接測定したり、正確に推測したりすることは、不可能である。

また、視聴するユーザにとっては、ネットワークの伝送品質（パケット損失率、遅延時間等）そのものではなく、自身の目や耳に触れる映像や音声の品質が重要である。

しかし、従来技術では、擬似の測定用データは、実際のストリームデータとパケットのヘッダは同じでも、内容は映像や音声を含むものではないから、たとえ測定用データをユーザが視聴してみたとしても、その品質を判断することはできず、実際に配信される映像や音声の品質を推測することは、全く不可能である。

さらに、従来技術では、パケット測定器からパケット測定機までのエンド−エンドの伝送品質が測定できても、経由するネットワークのどの辺りに原因があって伝送品質が悪化しているのかについては、見当をつけることができず、それでは、通信キャリアに改善を具体的に要求することが難しい。

このような従来の測定手法を、仮に、コンテンツプロバイダが採用したとしても、結局のところ、自身の顧客が視聴する映像や音声の品質を確保することは、困難である。

本発明は、上記の事情に鑑み、受信側（上記の例では顧客）で視聴される映像や音声の品質が所望の品質となるように、送信側（上記の例ではコンテンツプロバイダ）で制御することを可能にする技術を、提供することを目的とする。

本発明に係る、ネットワークを介してストリームデータを送信する送信システムは、符号化されたストリームデータを含むトランスポート・ストリーム（ＴＳ）パケットを作成するパケット化手段と、前記パケット化手段により作成された、符号化データを含むＴＳパケットに、ダミーパケットを追加して、一つのＩＰパケットを生成する生成動作を、繰り返し行う生成手段と、前記ストリームデータの符号化レートから定まるＩＰパケットの出力レートよりも、前記ダミーパケットの追加に応じて速くした出力レートで、前記生成手段により生成されたＩＰパケットをネットワークへ出力する出力手段とを備えることを特徴とする。

この構成によれば、実際の映像及び／又は音声のデータが入ったＴＳパケットと、ダミーのパケットとが、一つのＩＰパケットに格納され、そのＩＰパケットの連なりが、ダミーパケットの追加に応じて速くした出力レートで、送信される。したがって、このＩＰパケットの連なりが、受信側の装置でどのように受信されたかを測定すれば、実際に配信されるストリームデータについてのネットワークの伝送品質（ＩＰパケットの伝送が失敗したり遅れたりしていないか）を、直接測定することが可能になる。すなわち、映像／音声の入ったパケットとダミーのパケットとを、別々のＩＰパケットとして送信するのではなく、映像／音声の入ったＩＰパケットの内部に、ダミーパケットを追加で入れ込んで送信するため、映像／音声の入ったＩＰパケット自体についての伝送品質を、直接測定することができるようになる。

さらに、上記の受信されたＩＰパケットの連なりから取り出されて復号化された映像／音声がどのような品質なのか（画質／音質等）を測定すれば、ネットワークの伝送品質だけではなく、実際に視聴される映像や音声の品質を、直接測定の対象とすることが可能になる。映像／音声の符号化データに誤り訂正符号が含まれていて、映像／音声データの一部が失われても元の映像／音声を正しく復号化できる場合もあるので、ネットワークの伝送品質の悪化が、必ずしも映像／音声の視聴品質を悪化させるものではないところ、コンテンツプロバイダのように、顧客が視聴する映像／音声の品質がサービスの基準となる事業者にとっては、実際の視聴品質を直接測定できることが、有用である。

また、映像／音声の入ったパケットとダミーのパケットとを、別々のＩＰパケットとして送信していると、たとえ映像／音声の品質を測定したとしても、ダミーパケットが伝送途中で紛失したり遅延したりしたことは検出できず、ネットワークの伝送品質が正確に反映された情報を得ることはできないが、本発明に係る構成によれば、映像／音声の入ったＩＰパケットの内部に、ダミーパケットが追加で入れ込まれるため、ＩＰパケットが伝送途中で紛失したり遅延したりすれば、映像／音声データの一部に影響が発生することになる。よって、ネットワークの伝送品質を正確に反映した映像／音声の品質を、測定することが可能になる。

上記の構成において、前記生成手段が一つのＩＰパケットに含ませる、符号化データを含むＴＳパケットと、ダミーパケットとの比率を、指定するための指定手段をさらに備えるようにしてもよい。

本発明に係る構成によれば、ストリームデータの符号化レートから定まるＩＰパケットの出力レートよりも、ダミーパケットの追加に応じて速くした出力レートで、ＩＰパケットが送信される。ここでいうＩＰパケットの出力レート（速度）は、「送信帯域」ともいう。そして、ストリームデータの符号化レートから定まる帯域をｘ［ｂｐｓ］、ダミーパケットの追加に応じて増加させた全体の「送信帯域」をｙ［ｂｐｓ］とすると、上記の指定手段により指定される「符号化データを含むＴＳパケットと、ダミーパケットとの比率」は、データ量の比であり、時間で平均してほぼｘ：（ｙ−ｘ）となる。

例えば、コンテンツプロバイダの管理者から、全体の「送信帯域」としてｚ［ｂｐｓ］が入力されたとき、上記の指定手段は、ｘ：（ｚ−ｘ）を「比率」として指定してもよいし、ＴＳパケットとダミーパケットのそれぞれの長さの関係からα分の調整をして、ｘ：（ｚ−ｘ−α）を「比率」として指定してもよい（この場合、全体の「送信帯域」は、時間で平均してほぼ（ｚ−α）［ｂｐｓ］となる）。

上記の構成において、前記指定手段は、前記符号化データを含むＴＳパケットに対する前記ダミーパケットの比率を、段階的に増加もしくは減少させる手段を含み、前記送信システムは、前記指定手段により指定される比率の段階毎に、前記ＩＰパケットをネットワークから受信して元のストリームデータを得る装置における当該ストリームデータの再生品質に関する情報を収集する収集手段をさらに備えるようにしてもよい。

これにより、指定される「比率」ひいては全体の「送信帯域」を、段階的に増加又は減少させたときに、その段階毎に受信側での「再生品質」（ネットワークの伝送品質だけでもよいし、映像／音声の品質だけでもよいし、両方でもよい）がどうなったかを示す情報を、収集することができる。そうすると、例えば、コンテンツプロバイダの管理者は、通信キャリアと契約した利用可能な通信帯域のうち、実際に「再生品質」が自身の定める基準を満たすことのできる「送信帯域」がどこまでなのかを、知ることができる。

上記の構成において、前記ネットワークを介して接続されたクライアント宛てにコンテンツを配信するためのサーバ手段と、前記サーバ手段が前記クライアント宛てに配信するコンテンツのストリームデータの符号化レートの選択、及び／又は、前記サーバ手段がコンテンツを同時に配信することを許可するクライアントの数の決定を、当該ストリームデータの符号化レートと同時配信可能なクライアントの数とから定まるＩＰパケットの出力レートが、前記収集手段により収集された比率の段階毎の再生品質に関する情報に基づいて再生品質が許容範囲内になると判断される比率に対応するものとなるように、行う制御手段とをさらに備えるようにしてもよい。

上記の構成によれば、コンテンツプロバイダ側で、通信キャリアと契約した利用可能な通信帯域ｒ［ｂｐｓ］のうち、実際に再生品質が基準以上となる（許容範囲内になる）「送信帯域」はｓ［ｂｐｓ］までである（ｒ＞ｓ）と、判断することができるため、その「送信帯域」の最大値（ｓ［ｂｐｓ］）に収まるようにコンテンツの配信を実行することにより、顧客が視聴する映像や音声の品質を確保するための制御が可能になる。

例えば、クライアントに対してコンテンツを配信する際、複数の符号化レート（符号化レートが高ければ映像／音声が高品質となる）のうちの一つをそのクライアント用に選択して、選択された符号化レートで符号化されたストリームデータを送信するシステムでは、上記のように、再生品質が実際に基準以上となる「送信帯域」の最大値（ｓ［ｂｐｓ］）が求まると、そこに収まる範囲内で、再生品質に関する情報を収集する時点で用いていた符号化レートよりも高い符号化レートを選択して、コンテンツを配信することが可能になる。

しかも、「送信帯域」の最大値（ｓ［ｂｐｓ］）を求める（再生品質に関する情報を収集する）際には、別の符号化レートで符号化データを作成し直すのではなく、元の符号化レートの符号化データにダミーパケットを追加して送信すればよいため、コンテンツプロバイダは、符号化データを複数のレートで作成し直すというコストをかけずに、最適な符号化レートを選択することが可能となる。

また、例えば、複数のクライアントに対して、放送型又はオンデマンド型で、コンテンツを配信するシステムでは、同時に配信を行うクライアントの数に応じて、帯域を消費することになるが、上記のように、再生品質が実際に基準以上となる「送信帯域」の最大値（ｓ［ｂｐｓ］）が求まると、そこに収まる範囲内で、同時に配信することを許可するクライアントの数を増加させることが可能になる。

しかも、「送信帯域」の最大値（ｓ［ｂｐｓ］）を求める（再生品質に関する情報を収集する）際には、一本のストリームデータにダミーパケットを追加して送信すればよいため、コンテンツプロバイダは、送信するストリームデータの本数に応じてコンテンツ所有者に利用料金を支払うというコストをかけずに、最適な同時配信可能クライアント数を決定することが可能となる。

また、上記の符号化レートの選択と同時配信可能クライアント数の決定とを組み合わせて、例えば、クライアントＡとＢには符号化レートａで（６Ｍｂｐｓ×２）、クライアントＣには符号化レートｂで（１４Ｍｂｐｓ）、クライアントＤには符号化レートｃで（３Ｍｂｐｓ）、クライアントＥとＦには符号化レートｄで（１Ｍｂｐｓ×２）というように、各クライアントの要望に応えつつ「送信帯域」の最大値（この例では３１Ｍｂｐｓ）の全体を有効利用するような制御をすることも可能になる。

以上とは別に、上記の構成において、前記出力手段は、前記生成手段により生成されたＩＰパケットを、複数の宛先に対して送信するものであり、前記収集手段は、前記比率の段階毎に再生品質に関する情報を収集する作業を、前記宛先毎に行うものであり、前記送信システムは、前記収集手段により収集された比率の段階毎、及び、宛先毎の再生品質に関する情報に基づいて、前記ネットワーク内部で伝送品質が悪化している部分を推測できるように、収集された情報を提示する提示手段をさらに備えるようにしてもよい。

これにより、コンテンツプロバイダ側で、ネットワークのどの辺りに伝送品質の悪化の原因がありそうかの見当をつけることが可能になるため、通信キャリアに対して具体的な改善を要求する道が開ける。

以上に記述した構成において、前記指定手段により指定される「比率」が、一つのＩＰパケット内での固定長のＴＳパケットと固定長のダミーパケットの数の比よりも、細かい数値となる場合に、その「比率」を実現する手法には、例えば、次の二つがある。

一つは、前記生成手段が生成する複数のＩＰパケットのうちの二つ以上において、各ＩＰパケットに含ませる、符号化データを含むＴＳパケットの数と、ダミーパケットとして働くダミーＴＳパケットの数との比を、互いに異ならせることにより、前記複数のＩＰパケット全体で、前記指定手段により指定される比率を実現するものである。

もう一つは、前記生成手段が一つのＩＰパケットに含ませるダミーパケットを、可変長のパケットとすることにより、前記指定手段により指定される比率を実現するものである。

また、以上に記述した構成における前記ダミーパケットは、前記ＩＰパケットをネットワークから受信して元のストリームデータを得る装置において、前記ＩＰパケットに含まれるＴＳパケットから当該ストリームデータを復号化する処理に用いられることなく廃棄されるものとしてもよい。

これにより、全体の「送信帯域」を増加させても、増加分はダミーパケットであって、受信側の復号化処理にかかる負荷は変化しないため、「送信帯域」を増加させて「再生品質」が悪化した場合に、これが、受信側の復号器等の性能が足りないためではなく、ネットワークの伝送品質の悪化に起因するものであることを特定することが可能になる。

以上に記述した構成において、前記生成手段が一つのＩＰパケットを生成する際に、符号化データを含むＴＳパケットの群と、ダミーパケットの群とを、群別に分かれて並べるか、双方が混在するように並べるかを、指示するための指示手段をさらに備えるようにしてもよい。

これにより、受信側のバッファが少ない場合に、全体の「送信帯域」を増加させても、符号化データを含むＴＳパケットとダミーパケットとが混在するように並んでいれば、ダミーパケットは復号器へ渡すことなく廃棄してよいため、バッファがあふれないようにすることができる。そうすると、「送信帯域」を増加させて「再生品質」が悪化した場合に、これが、受信側のバッファが足りないためではなく、ネットワークの伝送品質の悪化に起因するものであることを特定することが可能になる。

また、符号化データを含むＴＳパケットとダミーパケットとを群別に分かれて並べて送信する場合は、ダミーパケットを幾つ連続させると「再生品質」が悪化するかを調べることができるため、「送信帯域」はネットワークの伝送品質が良好に保たれる範囲で一定としておいて、ダミーパケットの並びを変化させることにより、受信装置のデータ受信の途切れに対する耐性能力を測定することも可能になる。

なお、上述した送信システムの発明はいずれも、送信方法の発明としても、コンピュータシステムを上記の送信システムとして機能させるためのプログラムの発明としても、そのプログラムを記録した記録媒体の発明としても、勿論成立するものである。

例えば、本発明に係る、ネットワークを介してストリームデータを送信する送信方法は、符号化されたストリームデータを含むＴＳパケットを作成するパケット化ステップと、前記パケット化ステップで作成された、符号化データを含むＴＳパケットに、ダミーパケットを追加して、一つのＩＰパケットを生成する生成動作を、繰り返し行う生成ステップとを備え、前記ストリームデータの符号化レートから定まるＩＰパケットの出力レートよりも、前記ダミーパケットの追加に応じて速くした出力レートで、前記生成ステップで生成されたＩＰパケットをネットワークへ出力することを特徴とする。

また、例えば、本発明に係るプログラムは、ネットワークを介してストリームデータを送信するために、符号化されたストリームデータを含むＴＳパケットを作成するパケット化手段と、ＩＰパケットをネットワークへ出力する出力手段とを備えるシステムに、組み込まれて当該システムを動作させるものであって、前記パケット化手段により作成された、符号化データを含むＴＳパケットに、ダミーパケットを追加して、一つのＩＰパケットを生成する生成動作を、前記システムに繰り返し行わせるための第１のプログラムコードと、前記ストリームデータの符号化レートから定まるＩＰパケットの出力レートよりも、前記ダミーパケットの追加に応じて速くした出力レートで、前記第１のプログラムコードにより生成されたＩＰパケットを前記出力手段に出力させるための第２のプログラムコードとを備えることを特徴とする。

なお、以上において、一つのＩＰパケットが、符号化データを含むＴＳパケットとダミーパケットとを含む形式は、ＩＰパケットに直接的にＴＳパケットが載るのでもよいし、ＩＰパケットにＵＤＰ（ユーザ・データグラム・プロトコル）ヘッダが付加されたＵＤＰ／ＩＰパケットにＴＳパケットが載るのでもよいし、ＩＰパケットにＲＴＰ（リアルタイム・トランスポート・プロトコル）ヘッダが付加されたＲＴＰ／ＵＤＰ／ＩＰパケット又はＲＴＰ／ＩＰパケットにＴＳパケットが載るのでもよい。

また、以上において、符号化されたストリームデータを含むＴＳパケットが作成される構成は、ストリームデータを予め符号化して格納しておき、それを送信時に読み出してＴＳパケットとする蓄積型の配信にも適用可能であるし、送信時にリアルタイムでストリームデータの符号化が進行し、符号化と出力の間のバッファとしてデータが格納されてそれがＴＳパケット化される生中継型の配信にも適用可能である。

以上のとおり、本発明によれば、受信側で視聴される映像や音声の品質が所望の品質となるように、送信側で制御することを可能にする種々の技術が、提供される。

本発明の一実施形態に係る送信システムを含む全体の構成の一例を示す図 ＴＳパケットがＩＰパケットに収容されるフォーマットの四つの例を示す図 帯域増加量指定部１２０及びダミー挿入形式指示部１６０における処理の一例を示すフローチャート データ組合せ部１４０における処理の一例を示すブロック図 品質測定装置４０ｎ（４０１，４０２，…の各々）の内部構成例を示す図 本実施形態による測定結果の利用の一例についての説明図 本実施形態による測定結果の利用の別の例についての説明図 本実施形態による測定結果の利用のさらに別の例についての説明図 ダミーパケットの挿入形式の二つの例と、第二の例の変形例について説明する図 配信帯域を増加させる際のＩＰパケット（一つのＩＰパケット）の作成法の一例を示す図 配信帯域を増加させる際のＩＰパケット（一つのＩＰパケット）の作成法の別の例を示す図 配信帯域を増加させる際のＩＰパケット（複数のＩＰパケット）の作成法の一例を示す図 配信帯域を増加させる際のＩＰパケット（複数のＩＰパケット）の作成法の別の例を示す図 可変長のダミーパケットを用いてＩＰパケットを作成する例を説明する図 動的に配信帯域の増加量を変更する場合のＩＰパケットの作成例を説明する図 映像データ生成部１８０における処理の一例を示すブロック図

以下、本発明の実施の形態について、図面を用いて説明する。本実施形態では、映像データを音声データも含めてストリームデータとして、サーバからクライアントへ配信するシステムの場合を例示するが、ここで説明する技術は、映像（動画）データのみが対象でも、音声データのみが対象でも、他のストリームデータが対象でも、適用可能であり、また、一般的に、ネットワークサービスのユーザ間の通信に適用できるものである。

図１に、本発明の一実施形態に係る送信システムを含む全体の構成の一例を示す。

図１の例では、データ配信サーバ１００と複数のデータ受信クライアント（端末）３０１，３０２，…（図示省略）がネットワーク２００に接続されており、配信サーバ１００の映像データ格納部１１０に格納された映像データ（コンテンツ）が、ネットワーク２００経由で配信される。ネットワーク２００は、通信キャリア（インターネット・サービス・プロバイダでもよい）が提供するものであり、配信サーバ１００は、ネットワークのユーザである。

データ配信サーバ１００は、コンテンツを配信するサーバとして十分なストレージ容量とプログラム実行性能を有するコンピュータで構成すればよく、データ受信クライアント３０ｎは、パーソナルコンピュータやセットトップボックスで構成することができる。

図１に示す実施形態では、配信サーバ１００からコンテンツの配信を受けられる複数の受信クライアントのうちの一部又は全部のそれぞれに対応して、品質測定装置４０１，４０２，…（図示省略）が設けられ、データ受信クライアント３０１，３０２，…のそれぞれがネットワーク２００から受信するデータの複製を、対応する品質測定装置４０１，４０２，…でも受信するようにしている。

このように、品質測定装置４０ｎに複製を受信させるためには、ＯＳＩのプロトコルレイヤ３又は２でコピーを作成する「ミラーリング」と呼ばれる技術、もしくは、レイヤ１でコピーを作成する「タッピング」と呼ばれる技術を使えばよい。ミラーリングの場合は、ネットワークスイッチなどの装置を使って、ＩＰやイーサネット（ＶＬＡＮを含む）のプロトコルレイヤでコピーを行い、データ受信クライアントが接続している物理ポートと異なる物理ポートに対して、そのコピーしたＩＰパケット又はイーサネットフレームを品質測定装置に転送する。タッピングの場合は、ネットワークとデータ受信クライアントを結ぶ物理線にタップと呼ばれる装置をはさむことにより、物理的な信号をコピーして、そのコピーした信号を品質測定装置に送る。

そして、図１の例では、各品質測定装置４０ｎで測定されたネットワークの伝送品質や視聴される映像の品質等を、品質情報収集装置５００が収集して、表示部５１０を介して、配信サーバの管理者（例えば、コンテンツプロバイダ）に提示することができる。別の例として、測定された品質の情報を表示する機能を、各々の品質測定装置４０ｎに持たせても構わない。

なお、図１の例では、一旦、各品質測定装置４０ｎが測定した品質の情報を、収集装置５００が収集しているが、そのような分担を行わない構成例もあり得る。例えば、各データ受信クライアント３０ｎがネットワーク２００から受信するデータの複製を、対応する品質測定装置４０ｎではなく、品質情報収集装置５００が直接受信するようにして、収集装置５００自体が、複数のデータ受信クライアントにおけるネットワーク伝送品質や映像品質等の測定を行ってもよい。

具体的には、品質情報収集装置５００が、ネットワーク２００を構成しているネットワーク装置から直接ミラーリングを利用して複製を受信するか、もしくは、ネットワーク２００とデータ受信クライアント３０１，３０２，…との接続線からタッピングを利用して直接複製を受信する。ミラーリングやタッピングを利用して、品質測定装置４０ｎを介さずにデータの複製を受信する場合、トンネリングを利用してネットワーク２００を通しても構わない。このように、収集装置５００が直接データの複製を受信する場合は、後述する品質測定装置４０ｎの内部構成を、代わりに収集装置５００が有することになる。

データ配信サーバ１００の制御部１７０は、映像データ格納部１１０に格納された映像データ（コンテンツ）を、データ配信部１５０を介してクライアントへ配信する際の制御を行うものである。ここでの制御とは、後述するように、例えば、コンテンツの符号化をし直して配信帯域を増減させたり、同時配信可能なコンテンツの数を増減させたりすることであり、品質情報収集装置５００（もしくは対応する品質測定装置４０ｎでも構わない）で把握された品質情報に基づいて、その制御の内容を変化させることができる。

データ配信サーバ１００の映像データ格納部１１０は、一つ又は複数のＭＰＥＧ−ＴＳファイルを格納できるハードディスクやメモリ等で構成する。ＭＰＥＧ−ＴＳは、符号化された映像・音声データをネットワーク上で伝送する際のフォーマットを規定しており、実質的な標準となっているものである。ＴＳファイルのデータは、分割されて、ＴＳパケットと呼ばれる固定長のパケットに入れられ、ネットワーク上を伝送される。

なお、ＭＰＥＧ−ＴＳの代わりに、ＦＬＡＳＨを用いることも可能である。ＦＬＡＳＨの場合は、ＭＰＥＧ−ＴＳでダミーを利用するのに相当するダミーデータとして、ダミーｐｎｇを生成して利用することにより、本実施形態と同様の仕組みを実現することができる。

図２には、ＴＳパケットが、ネットワークを介して伝送される際に、どのような形でＩＰパケットに収容され得るかを示す。図２（ａ）のフォーマットでは、ＩＰパケットに直接的にＴＳパケットが載っている。図２（ｂ）のフォーマットでは、ＵＤＰ／ＩＰパケットにＴＳパケットが載っている。図２（ｃ）のフォーマットでは、ＲＴＰ／ＵＤＰ／ＩＰパケットにＴＳパケットが載っている。図２（ｄ）のフォーマットでは、ＲＴＰ／ＩＰパケットにＴＳパケットが載っている。本実施形態に係るシステムでは、（ａ）〜（ｄ）のいずれのフォーマットを採用してもよい。いずれの場合も、複数のＴＳパケットを一つのＩＰパケットに含めることが可能である。

それぞれのＴＳパケットは、ＴＳヘッダとペイロードとから成り、ＴＳのペイロードに入るデータは、１８８バイトと規定されている。そして、ＩＰパケットを載せるイーサネットフレームの大きさ（１５００バイト）の制限から、一つのＩＰパケット（各種ヘッダ以外のボディ）に入れることのできるＴＳパケットは、最大７個までとなる。なお、イーサネットのジャンボフレームを利用する場合は、フレームの大きさの制限を、１５００バイトから９０００バイトまで緩くすることができるため、一つのＩＰパケットに７個より多くのＴＳパケットを格納することができる。以下には、最大数が７個の場合を例にとって、説明することとする。

データ配信サーバ１００のダミーデータ生成部１３０は、ダミーパケットを生成する。ダミーパケットとして、例えば、ＴＳパケットの一種として定義されている固定長のＮＵＬＬ−ＴＳパケットを生成してもよい。この場合、ダミーデータ生成部は、ＴＳヘッダ内に、ダミーＴＳであることを示す識別子を設定し、ペイロードに０ｘ００でパディングしたデータを書き込む。

但し、ダミーＴＳパケットは、映像データの復号化に使われるものではないため、受信クライアントは、受信したパケットのＴＳヘッダを見て、そこにダミーＴＳであることを示す識別子が存在すれば、ペイロードを読み込まずにＴＳパケットを破棄する動作を行うように製造されていることが多い。よって、ダミーＴＳのペイロードにパディングするデータは、０ｘ００以外の値でも構わない。さらに、受信クライアントが、ダミーＴＳパケットのペイロードに対して特別な処理を行う機能を有している場合には、配信サーバ側で、コンテンツの番組宣伝情報等の付加情報を、ダミーＴＳのペイロードに入れても構わない。

また、後述するように、可変長のダミーパケットをＩＰパケットに含めたい場合には、ダミーデータ生成部１３０は、ＴＳヘッダを設けて、そこにダミーＴＳであることを示す識別子を設定し、本来は１８８バイトの固定長であるペイロードを、１８８バイト未満の長さにして、ダミーパケットを作成してもよい。受信側クライアントは、ＴＳヘッダを見てダミーＴＳと判別されればペイロードを破棄するように製造されていれば、ダミーパケットの長さがＴＳパケットの規定に反していても、ＩＰパケットの最後に可変長のダミーパケットが含まれている分には、処理可能である（ＩＰパケットの途中に含まれている場合でも、長さの検出機能があれば、処理可能である）。

データ配信サーバ１００のデータ組合せ部１４０は、映像データ格納部１１０に格納されるＭＰＥＧ−ＴＳファイルのデータを読み込み、ＴＳパケットを作成する（図４のＴＳパケット作成部１４２）。具体的には、ＴＳファイルのデータを分割し、それぞれをＴＳパケットのペイロードに入れ、所定のＴＳヘッダを付与する。

そして、データ組合せ部１４０は、この実映像データを含むＴＳパケットに、ダミーデータ生成部１３０で生成されたダミーパケットを追加して、一つのＩＰパケットを生成する生成動作を、繰り返し行う（図４のＩＰパケット生成部１４４）。具体的には、後述する帯域増加量指定部１２０から指示された数ＤのダミーＴＳパケットをダミー生成部１３０から読み込み、これを、帯域増加量指定部１２０から指示された数Ｒの実映像データＴＳパケットの間に、後述するダミー挿入形式指示部１６０から指示された形式で、挿入して、ＩＰパケットを生成する。ＩＰパケットの生成の際には、必要に応じて、ＵＤＰヘッダやＲＴＰヘッダも付与する。なお、ダミーパケットの挿入形式が一種類しかないシステムでは、ダミー挿入形式指示部１６０は不要である。

データ配信サーバ１００のデータ配信部１５０は、データ組合せ部１４０からＩＰパケットを受け取り、帯域増加量指定部１２０から配信レート（配信帯域）を受け取って、配信レートに従いＩＰパケットをネットワーク２００へ送り出す。配信帯域は、本実施形態では、映像データの符号化レートから定まる帯域（符号化帯域）よりも増加させたものとすることができる。

データ配信サーバ１００の帯域増加量指定部１２０及びダミー挿入形式指示部１６０は、例えば、図３に示すような処理を行う。

まず、配信サーバ１００の管理者が、増加させた配信帯域ＴＢを入力し、帯域増加量指定部１２０がこれを受け付ける（Ｓ３００）。帯域増加量指定部１２０は、映像データ格納部１１０に格納されているＴＳファイルの符号化レートを調べて、符号化帯域ＥＢを取得する（Ｓ３１０）。あるいは、配信サーバ１００の管理者が、符号化帯域ＥＢを設定しておいてもよい。符号化帯域ＥＢは、映像データを符号化してＭＰＥＧ−ＴＳファイルを作成する際に確定するものであり、映像データを符号化し直さなければ符号化帯域ＥＢは変更されない。

帯域増加量指定部１２０は、配信帯域ＴＢと符号化帯域ＥＢから、実映像データＴＳパケットの数ＲとダミーＴＳパケットの数Ｄとの比を計算する（Ｓ３１０）。基本的には、（ＴＢ−ＥＢ）：ＥＢ＝Ｄ：Ｒとなるように計算するが、ＴＳパケットが固定長であることから、Ｄ：Ｒを近似的な値で求めてもよい。なお、近似的な値とする場合は、そのＤ：Ｒから正しい配信帯域ＴＢ’を計算し直し、後述するＳ３４０，Ｓ３７０で、ＴＢの代わりにＴＢ’をデータ配信部１５０に渡すようにする。

例えば、ＥＢ＝６Ｍｂｐｓであったところ、ＴＢ＝１８Ｍｂｐｓに増加させるよう指定する場合は、（１８−６）：６＝１２：６＝２：１が、Ｄ：Ｒとなる。また、ＥＢ＝６Ｍｂｐｓであったところ、ＴＢ＝２０Ｍｂｐｓに増加させるよう指定する場合は、（２０−６）：６＝１４：６＝７：３が、Ｄ：Ｒとなる。

次に、帯域増加量指定部１２０は、一つのＩＰパケットに入れられるＴＳパケットの最大数が７個であることから、Ｄ＋Ｒが７以下（Ｓ３２０Ｎｏ）であるか、７より大きい（Ｓ３２０Ｙｅｓ）であるかを調べる。

Ｄ＋Ｒが７以下の場合は、全てのＩＰパケットにつき同一のＲとＤを決定する（Ｓ３３０）。上記の例のうち前者は、Ｄ＋Ｒ＝２＋１＝３であるので、Ｒ＝１，Ｄ＝２と決定する。なお、この場合は、それぞれを倍にしても未だ合計数が７以下であるため、同じ比を実現する数として、Ｒ＝２，Ｄ＝４と決定しても構わない。そして、決定したＲとＤの値を、データ組合せ部１４０に渡すとともに、データ配信部１５０に、配信帯域ＴＢを渡す（Ｓ３４０）。

Ｄ＋Ｒが７より大きい場合は、ＲとＤの比を完結させるＩＰパケットの数ＩＰ（Ｎ）を計算する（Ｓ３５０）。具体的には、Ｄ＋Ｒを７で割った商に１を加えた数をＩＰ（Ｎ）とする。上記の例のうち後者は、Ｄ＋Ｒ＝７＋３＝１０であるので、ＩＰ（Ｎ）＝２となる。つまり、ＩＰパケットが２個あれば、実映像データＴＳパケット３個とダミーＴＳパケット７個を収容することができる。

そして、ＩＰ（Ｎ）個のＩＰパケットのそれぞれに対し、どちらのＴＳパケットを幾つ入れるか（Ｒ（１）〜Ｒ（Ｎ），Ｄ（１）〜Ｄ（Ｎ））を決定する（Ｓ３６０）。上記の後者の例では、各ＩＰパケットに入れるＴＳパケットの数を平均化しようとすれば、一つのＩＰパケットに５個のＴＳパケットを入れることになり、例えば、Ｒ（１）＝２，Ｒ（２）＝１（で合計３個）、Ｄ（１）＝３，Ｄ（２）＝４（で合計７個）のように割り振ればよい。

各ＩＰパケットにどちらのＴＳパケットを何個入れるかの割り振りは、ランダムに選択してもよいし、後述するダミー挿入形式の指示に依存して決定することもできる。前者の場合は、例えば、コンピュータのランダム関数機能を利用すればよい。後者の場合は、例えば、双方のＴＳパケットを混在させる（なるべく分散させて交互になるように並べる）形式（図９の挿入形式１）の場合には、個数の割り振りを平均化するとよい。種別ごとに固めて群分けする（同じ種別が連続するように並べる）形式（図９の挿入形式２）の場合には、個数の割り振りは平均化しても偏らせてもよい。

個数の割り振りを偏らせる場合も、一つのＩＰパケットの中に必ず（但し、数が絶対的に足りない場合は除く）双方のＴＳパケットが含まれるようにしてもよい。逆に、ダミーＴＳパケットを連続させて受信クライアントの性能を検査したい場合には、ダミーＴＳパケットのみから成るＩＰパケットの存在を許してもよい。例えば、ＥＢ＝６ＭｂｐｓをＴＢ＝２６Ｍｂｐｓに増加させる場合は、Ｒ＝３，Ｄ＝１３となるので、Ｒ（１）＝２，Ｄ（１）＝３，Ｒ（２）＝０，Ｄ（２）＝６，Ｒ（３）＝１，Ｄ（３）＝４のように決定してもよい。また、実映像データＴＳパケットのみから成るＩＰパケットの存在を許してもよい。

その後、帯域増加量指定部１２０は、決定したＲ（１）〜Ｒ（Ｎ）とＤ（１）〜Ｄ（Ｎ）の値を、データ組合せ部１４０に渡すとともに、データ配信部１５０に、配信帯域ＴＢを渡す（Ｓ３７０）。データ配信部１５０は、１個又はＩＰ（Ｎ）個のＩＰパケットを利用して、（Ｄ＋Ｒ）個のＴＳパケットを配信することになる。

以上には、図３を例にして、固定長のダミーＴＳパケットを用いる場合を説明したが、１８８バイト未満の可変長のダミーパケットを、単独で又は固定長のダミーＴＳパケットと組合せて用いるようにすれば、Ｄ＋Ｒが７より大きくても、一つのＩＰパケットでＲとＤの比を完結させることができる場合が出てくる。

また、配信サーバ１００の管理者が、配信帯域ＴＢを入力する代わりに、ＲとＤの比、もしくはＲの値及びＤの値を入力することもできる。その場合、帯域増加量指定部１２０は、ＲとＤの比と符号化帯域ＥＢから、配信帯域ＴＢを計算する。具体的な計算式は、ＴＢ＝ＥＢ×（１＋Ｄ／Ｒ）となる。

ダミー挿入形式指示部１６０は、帯域増加量指定部１２０の動作と並行して、ダミーパケットの挿入形式を決定し（Ｓ３３５，Ｓ３６５）、データ組合せ部１４０に指示する。挿入形式としては、例えば、ランダムに挿入する形式の他に、図９に示す２種類があり、受信端末の性能（受信バッファ量の大小等）に基づいて選択してもよい。

ダミーパケットを均等に挿入する挿入形式１は、受信クライアントのバッファ量が少ない場合に選択するとよい。例えば、チャネル切り替えの際のタイムラグを小さくするために、バッファ量を少なくしている受信クライアントが存在し得る。ダミーパケットをまとめて挿入する挿入形式２は、受信クライアントのバッファ量が十分ある場合に選択可能で、さらに、ダミーＴＳパケットを連続させる数を変化させて画質への影響を見ることにより、受信クライアントの復号能力を測定することもできる。

受信クライアントの復号能力が高い場合に、その限界を測定するために、３つ以上のＩＰパケットを利用し、最初と最後のＩＰパケット以外の中間にあるＩＰパケットは全てダミーＴＳパケットで構成するようにしてもよい。上述したＥＢ＝６ＭｂｐｓをＴＢ＝２６Ｍｂｐｓに増加させる例でいうと、最大限ダミーＴＳパケットを連続させるには、１番目のＩＰパケットの最初に２個の実映像ＴＳパケットを入れ、その後に３個のダミーＴＳパケット、２番目のＩＰパケットに６個のダミーＴＳパケット、３番目のＩＰパケットの最初に４個のダミーＴＳパケット、最後に１個の実映像ＴＳパケットを入れることになる。

以上に詳述したように、本実施形態では、ＭＰＥＧ−ＴＳパケットを配信する際に、ダミーＴＳパケットを挿入して、より広帯域でデータを配信する。追加したダミーＴＳパケットの分だけ、単位時間当たりに配信するデータ量（配信帯域）を増加させるため、例えば、ＩＰパケット毎に実映像ＴＳパケットを４個入れて６Ｍｂｐｓで配信することを想定する場合、本実施形態では、ダミーＴＳパケットを３個追加するとすれば、ＩＰパケット毎にＴＳパケットを７個入れて１０．５Ｍｂｐｓで配信することになる。

そうすると、配信帯域を様々な幅で増加させても、データを受信する視聴クライアントでは、復号化する単位時間当たりのデータ量はオリジナルデータと同じ（６Ｍｂｐｓ）であるため、視聴クライアントでの映像・音声の復号化負荷を上げずに、様々な伝送帯域でのネットワーク伝送品質を測定することが可能になる。

図５は、品質測定装置４０ｎの内部構成の一例を示している。品質測定装置４０ｎは、上述したように、データ受信クライアント３０ｎへのデータのコピーをネットワーク２００から受信し、受信したデータに対して、ＩＰパケット受信部４１０、ＵＤＰパケット受信部４２０、ＲＴＰパケット受信部４３０、ＴＳパケット取出部４４０、映像・音声復号化部４５０の順に、下位レイヤから上位レイヤへの処理が施される。なお、図２（ａ）の場合は、ＩＰパケット受信部４１０からＴＳパケット取出部４４０へ直接上がり、図２（ｂ）の場合は、ＵＤＰパケット受信部４２０からＴＳパケット取出部４４０へ直接上がり、図２（ｄ）の場合には、ＩＰパケット受信部４１０からＲＴＰパケット受信部４３０へ直接上がることになる。

品質の測定は、ネットワークの伝送品質を分析する伝送品質情報取得部４３５と、視聴される映像・音声の品質を分析する画質・音質情報取得部４５５とにより行われる。システムにより、いずれか一方の情報取得部のみが実装されてもよい。

まず、受信したＩＰパケットの種類が、ＩＰ（４１０の出力）か、ＵＤＰ／ＩＰ（４２０の出力）か、ＲＴＰ／ＵＤＰ／ＩＰもしくはＲＴＰ／ＩＰ（４３０の出力）かによって、それぞれの測定部４６０〜４８４で分析される。すなわち、ＩＰであれば、ＩＰパケットの欠損が測定され（４６０）、ＵＤＰであれば、ＵＤＰ／ＩＰのパケット受信順序の変更が測定され（４７０）、ＲＴＰであれば、ＲＴＰパケットの欠損（４８０）、ＲＴＰパケットのパケット受信順序の変更（４８２）、ＲＴＰパケットの受信ジッタ（受信の間隔の揺らぎ）（４８４）等が測定される。

配信サーバ１００のデータ配信部１５０は、ＲＴＰパケットを配信する場合、ＲＴＰに準拠したパケット欠損測定情報（シーケンス番号）、ジッタ測定情報（タイムスタンプ）をＲＴＰヘッダに付加するため、測定部４８０，４８２，４８４は、これらの情報を用いて分析を行うことができる。なお、測定部４８０，４８２，４８４は、この順番に測定を行う必要はなく、異なる順序で行っても、並列に行っても構わない。

システムによっては、上記の測定部４６０〜４８４の一部のみが実装されてもよい。また、全てが実装されている場合でも、例えば、ＲＴＰ／ＵＤＰ／ＩＰパケットを受信すれば、いずれの測定も可能ではあるが、測定部４６０〜４８４の全ての機能で測定してもよいし、予め指定された一部の測定機能だけを利用してもよい。

次に、ＩＰパケットからＴＳファイルを抜き出し、映像・音声情報としてＭＰＥＧで復号化がされると、映像・音声出力部４９０が、映像・音声を出力するため、映像・音声の品質（映像の乱れやフリーズ等）をオペレータ（人間）が確認してもよい。また、ブロックノイズ測定部４９５が、自動的に、復号化された映像・音声を分析し、実映像のブロックノイズを測定してもよい。出力部４９０での人間による確認と、測定部４９５の測定とは、両方行ってもよい（どちらを先に行ってもよいし並列に行ってもよい）し、いずれか一方のみ行ってもよい。

このように、本実施形態では、配信するデータの一部でも欠損、または伝送遅延がネットワークにおいて発生すると、いずれかの実映像データが入ったＩＰパケットに影響が発生させることが可能なため、ネットワークの伝送品質だけでなく、視聴クライアントでの画質も測定把握することが可能となる。

以上に説明したシステムの各部の機能は、一般のコンピュータにソフトウェアプログラムをインストールすることにより実装されてもよいし、機能の一部又は全部を専用ハードウェア化して実装してもよい。

図６〜図８は、以上に述べた本実施形態による測定結果の利用について説明するものである。

図６では、６Ｍｂｐｓで配信されるべき映像データのＴＳパケット１つに対して、追加するダミーＴＳデータを１つ、２つ、…と増加させて、受信側での品質を測定することにより、１２Ｍｂｐｓまでは所望の品質で配信できるが、１８Ｍｂｐｓからは品質が劣化することが判明している。よって、符号化レートを倍にした映像データを作成して格納し、所望の品質を確保できる１２Ｍｂｐｓで配信するという制御をすることが可能である。

このとき、符号化レートの異なる複数のＭＰＥＧ−ＴＳデータを用意しなくても、一つだけ用意したＭＰＥＧ−ＴＳデータを利用して、その符号化帯域よりも大きい帯域で配信を実行して、品質を調べることができるので、符号化のコストを削減することができる。このように、図６のような利用形態では、より広帯域（高品質）の映像配信を行える限界値を把握することが可能となるが、上記の例よりもさらに詳細な限界値を調べたい場合には、上述した複数のＩＰパケットを利用してより細かいＤとＲの比を実現する手法や、１８８バイト未満の長さのダミーパケットを挿入する手法を使えばよい。

図７では、図６と同様に、追加するダミーＴＳデータの数を増加させて、受信側での品質を測定することにより、３０Ｍｂｐｓまで品質劣化なしに配信できることが確認されたとする。そうすると、６Ｍｂｐｓで配信されるべき映像データを５本まで、同時に配信可能な要求として受け付けるという制御をすることが可能になる。

ここでも、一つの映像符号化データだけを利用して、より広帯域での配信時の映像品質を測定することが可能であり、最大何本まで同時に映像を配信しても品質が劣化せずに配信サービスできるかを、本数分の利用料金の支払いというコストをかけずに把握することができる。

図８には、ネットワークに存在する故障が起こりやすい箇所、帯域が細い箇所、遅延が発生し易い箇所など、ネットワーク内で映像・音声配信サービスの品質に影響を与えている部分（このような部分を「脆弱箇所」と呼ぶ）を推測する手法を示す。

図６と同様に、徐々に配信帯域を増やすことにより、より弱い脆弱箇所を特定していく。例えば、配信帯域６Ｍｂｐｓでは、どの視聴クライアントでも映像・音声の品質は劣化しないが、配信帯域を１０Ｍｂｐｓに上げたときに、脆弱箇所を利用している視聴クライアント群が受信している映像・音声の品質が劣化するということが起こる。

ネットワークへの負荷のかけ方として、通信キャリアと契約している帯域が多い場合には、Ａのポイントに接続されている視聴クライアント群Ａ（１００人）と、Ｂのポイントに接続されている視聴クライアント群Ｂ（１００人）の両方に対して、同じ映像・音声ストリームの配信帯域を、ダミーパケットを用いて「元の利用帯域（６Ｍｂｐｓ×２００人）」から徐々に増加させる。そして、「増加後の利用帯域（１０Ｍｂｐｓ×２００人）」で配信した時点で、視聴クライアントＢ群にだけブロックノイズやパケット欠損等、映像・音声品質に問題が発生した場合、視聴クライアントＢ群を集約しているネットワークの機器やその周辺（接続ポイント周辺）に脆弱性があると推定することができる。

通信キャリアと契約している帯域にそれほど余裕がない場合には、「増加後の利用帯域（１０Ｍｂｐｓ×１００人＋６Ｍｂｐｓ×１００人）」となるように、片方ずつ、配信帯域を徐々に増加させる検査を行う。まず、Ｂのポイントに接続している視聴クライアント群Ｂには６Ｍｂｐｓの配信帯域を維持したまま、Ａのポイントに接続されている視聴クライアント群Ａに対して配信帯域を１０Ｍｂｐｓまで増加させ、映像・音声品質に問題がないことが確認されたとする。次に、Ａのポイントに接続している視聴クライアント群Ａへの配信帯域を６Ｍｂｐｓに戻して、視聴クライアント群Ｂに対して配信帯域を１０Ｍｂｐｓまで増加させると、視聴クライアントＢ群の複数の視聴品質測定装置から品質低下が発生していることが確認されたとする。そうすると、視聴クライアントＢ群を集約しているネットワークの機器やその周辺（接続ポイント周辺）に脆弱性があると推定することができる。

なお、最初に配信帯域を増加させた方の視聴クライアント群で品質劣化が検出された場合は、次にもう一方の視聴クライアント群で配信帯域を増加させてみて、品質劣化が起こらなければ、最初の視聴クライアント群を集約しているネットワークの接続ポイント周辺が脆弱箇所であり、両方とも品質劣化が起これば、もっと配信サーバに近い側のネットワークの問題であると推測することができる。

図６〜図８に説明した測定は、本番のコンテンツ配信サービスを開始する前のテストとして行ってもよいし、本番のコンテンツ配信を一部行いながら測定することも可能である。テスト用の映像も、本番と同じ映像の一部でもよいし、他に用意した映像でもよい。

図１０〜図１４には、配信帯域を増加させる際のＩＰパケットの作成法を例示する。

図１０は、ＴＳパケット／ＩＰパケットで６Ｍｐｂｓの配信を行う例（実映像ＴＳパケットは１個）であり、一つのＩＰパケットに含ませるダミーＴＳパケットが１個増える毎に合計の配信帯域が６Ｍｂｐｓずつ増加している。コンテンツプロバイダが通信キャリアと契約している利用帯域が３６Ｍｂｐｓだったとして、６Ｍｂｐｓずつ配信帯域を増やしながら受信側での品質を測定した結果、３０Ｍｂｐｓまでは劣化がなく、３６Ｍｂｐｓで劣化したとすれば、３６Ｍｂｐｓのうち実際には３０Ｍｂｐｓが、コンテンツ配信の品質が保てる範囲であると判断することができる。

図１１は、ＴＳパケット／ＩＰパケットで３Ｍｐｂｓの配信を行う例（実映像ＴＳパケットは２個）であり、一つのＩＰパケットに含ませるダミーＴＳパケットが１個増える毎に合計の配信帯域が３Ｍｂｐｓずつ増加している。コンテンツプロバイダが通信キャリアと契約している利用帯域が２１Ｍｂｐｓだったとして、６Ｍｂｐｓずつ配信帯域を増やしながら受信側での品質を測定した結果、１８Ｍｂｐｓまでは劣化がなく、２１Ｍｂｐｓで劣化したとすれば、２１Ｍｂｐｓのうち実際には１８Ｍｂｐｓが、コンテンツ配信の品質が保てる範囲であると判断することができる。

図１２は、ダミーＴＳパケットを挿入すると一つのＩＰパケットに収まらなくなる場合に、複数のＩＰパケットを利用する例であり、同じ数のＴＳパケットを含むＩＰパケットの単位時間当たりに送出する数を倍にすることにより、配信帯域を６Ｍｂｐｓから１２Ｍｂｐｓへ増加させている。

図１３は、複数のＩＰパケットを利用することにより、元の実映像データから増加させる配信量をより微調整する例であり、上述したＥＢ＝６ＭｂｐｓをＴＢ＝２０Ｍｂｐｓに増加させる例を説明している。ここでは、一つのＩＰパケットに入れるＴＳパケット数を６個から５個に減らし、単位時間当たりに送出するＩＰパケットの数を４倍にすることにより、配信帯域を６Ｍｂｐｓから２０Ｍｂｐｓへ増加させている。

図１４は、可変長のダミーパケットを用いてＩＰパケットを作成する例であり、挿入するダミーパケットを１８８バイト未満の長さにして、１バイト単位で設定することにより、より細かい単位で配信帯域を増加させることが可能となっている。

図１５は、動的に、ＩＰパケット単位のダミーデータの挿入量を変更することにより、配信帯域量を変更する例を示している。例えば、どの時刻に配信帯域量を何Ｍｂｐｓにするかを、予めスケジューリングしておいてもよい。

最後に、図１６を参照して、データ配信サーバ１００に映像データ生成部１８０を設ける場合について説明する。

ＭＰＥＧ−ＴＳファイルを蓄積しておく方式では、予め、１つないし複数のＴＳファイルを映像データ格納部１１０に所持しており、そのＴＳファイルを指定される配信レート（帯域）に従って配信するため、映像データ生成部１８０は不要である。

ＴＳファイルを動的に生成するライブ方式では、地デジ等の電波媒体で映像音声を受信したり、ケーブルテレビ等の同軸ケーブル媒体で映像音声を受信したり、ＤＶＤ等の動画・音声を再生したりすることにより、映像受信部１８２で映像音声を受信する。受信した映像音声を、ＭＰＥＧ−ＴＳ作成部１８６が、符号化レート設定部１８４により設定された符号化レートで、ＭＰＥＧ−ＴＳファイル又はＴＳデータに変換する。このＭＰＥＧ−ＴＳファイル又はＴＳデータが、一時的に、映像データ格納部１１０に保持されて、配信される。

ライブ方式の場合、映像データの符号化と、符号化データの配信が、同時並行で進むため、符号化が配信に追い付かず、送るべき符号化データが映像データ格納部１１０に未だ保持されていないということが起こり得る。その場合は、ダミーＴＳデータを挿入するが、本実施形態の場合、実映像ＴＳデータとダミーＴＳデータを合計した全体の配信帯域量を指定されたものにするため、符号化が追い付いてきたら、実映像ＴＳデータを送出して、時間平均で、実映像ＴＳデータとダミーＴＳデータの比が指定された帯域増加量に対応するものになるように調整する。また、符号化が配信に先立って映像データ格納部１１０に既にデータが保持されていても、指定された配信帯域量を実現するためのダミーＴＳデータを優先して挿入することになる。

なお、以上に説明した実施形態は、ユニキャストの配信にも、マルチキャストの配信にも、適用可能である。マルチキャストの場合、複数の宛先のうちの一つに受信されるデータを、マルチキャスト制御を利用してネットワーク装置内でミラーリングして品質測定装置に受信させればよい。なお、例えば、ＩＰｖ６では、ＭＬＤ（Multicast Listener Discovery）のマルチキャスト制御方式を、ＩＰｖ４では、ＩＧＭＰ（Internet Group Management Protocol）のマルチキャスト制御方式を利用することができる。

以上、本発明の実施形態について説明したが、上述の実施形態を本発明の範囲内で当業者が種々に変形、応用して実施できることは勿論である。

１００ データ配信サーバ
１１０ 映像データ格納部
１２０ 帯域増加量指定部
１３０ ダミーデータ生成部
１４０ データ組合せ部
１５０ データ配信部
１６０ ダミー挿入形式指示部
１７０ 制御部
１８０ 映像データ生成部
２００ ネットワーク
３０１、３０２ データ受信クライアント
４０１、４０２ 品質測定装置
５００ 品質情報収集装置
５１０ 表示部

Claims (11)

1. ネットワークを介してストリームデータを送信する送信システムにおいて、
   符号化されたストリームデータを含むトランスポート・ストリーム（ＴＳ）パケットを作成するパケット化手段と、
   前記パケット化手段により作成された、符号化データを含むＴＳパケットに、ダミーパケットを追加して、一つのインターネット・プロトコル（ＩＰ）パケットを生成する生成動作を、繰り返し行う生成手段と、
   前記ストリームデータの符号化レートから定まるＩＰパケットの出力レートよりも、前記ダミーパケットの追加に応じて速くした出力レートで、前記生成手段により生成されたＩＰパケットをネットワークへ出力する出力手段とを備えることを特徴とする送信システム。
2. 前記生成手段が一つのＩＰパケットに含ませる、符号化データを含むＴＳパケットと、ダミーパケットとの比率を、指定するための指定手段をさらに備えることを特徴とする請求項１記載の送信システム。
3. 前記指定手段は、前記符号化データを含むＴＳパケットに対する前記ダミーパケットの比率を、段階的に増加もしくは減少させる手段を含み、
   前記送信システムは、前記指定手段により指定される比率の段階毎に、前記ＩＰパケットをネットワークから受信して元のストリームデータを得る装置における当該ストリームデータの再生品質に関する情報を収集する収集手段をさらに備えることを特徴とする請求項２記載の送信システム。
4. 前記ネットワークを介して接続されたクライアント宛てにコンテンツを配信するためのサーバ手段と、
   前記サーバ手段が前記クライアント宛てに配信するコンテンツのストリームデータの符号化レートの選択、及び／又は、前記サーバ手段がコンテンツを同時に配信することを許可するクライアントの数の決定を、当該ストリームデータの符号化レートと同時配信可能なクライアントの数とから定まるＩＰパケットの出力レートが、前記収集手段により収集された比率の段階毎の再生品質に関する情報に基づいて再生品質が許容範囲内になると判断される比率に対応するものとなるように、行う制御手段とをさらに備えることを特徴とする請求項３記載の送信システム。
5. 前記出力手段は、前記生成手段により生成されたＩＰパケットを、複数の宛先に対して送信するものであり、
   前記収集手段は、前記比率の段階毎に再生品質に関する情報を収集する作業を、前記宛先毎に行うものであり、
   前記送信システムは、前記収集手段により収集された比率の段階毎、及び、宛先毎の再生品質に関する情報に基づいて、前記ネットワーク内部で伝送品質が悪化している部分を推測できるように、収集された情報を提示する提示手段をさらに備えることを特徴とする請求項３記載の送信システム。
6. 前記生成手段が生成する複数のＩＰパケットのうちの二つ以上において、各ＩＰパケットに含ませる、符号化データを含むＴＳパケットの数と、ダミーパケットとして働くダミーＴＳパケットの数との比を、互いに異ならせることにより、前記複数のＩＰパケット全体で、前記指定手段により指定される比率を実現することを特徴とする請求項２〜５のいずれか１項記載の送信システム。
7. 前記生成手段が一つのＩＰパケットに含ませるダミーパケットを、可変長のパケットとすることにより、前記指定手段により指定される比率を実現することを特徴とする請求項２〜６のいずれか１項記載の送信システム。
8. 前記ダミーパケットは、前記ＩＰパケットをネットワークから受信して元のストリームデータを得る装置において、前記ＩＰパケットに含まれるＴＳパケットから当該ストリームデータを復号化する処理に用いられることなく廃棄されるものであることを特徴とする請求項１〜７のいずれか１項記載の送信システム。
9. 前記生成手段が一つのＩＰパケットを生成する際に、符号化データを含むＴＳパケットの群と、ダミーパケットの群とを、群別に分かれて並べるか、双方が混在するように並べるかを、指示するための指示手段をさらに備えることを特徴とする請求項１〜８のいずれか１項記載の送信システム。
10. ネットワークを介してストリームデータを送信する送信方法において、
    符号化されたストリームデータを含むトランスポート・ストリーム（ＴＳ）パケットを作成するパケット化ステップと、
    前記パケット化ステップで作成された、符号化データを含むＴＳパケットに、ダミーパケットを追加して、一つのインターネット・プロトコル（ＩＰ）パケットを生成する生成動作を、繰り返し行う生成ステップとを備え、
    前記ストリームデータの符号化レートから定まるＩＰパケットの出力レートよりも、前記ダミーパケットの追加に応じて速くした出力レートで、前記生成ステップで生成されたＩＰパケットをネットワークへ出力することを特徴とする送信方法。
11. ネットワークを介してストリームデータを送信するために、符号化されたストリームデータを含むトランスポート・ストリーム（ＴＳ）パケットを作成するパケット化手段と、インターネット・プロトコル（ＩＰ）パケットをネットワークへ出力する出力手段とを備えるシステムに、組み込まれて当該システムを動作させるプログラムであって、
    前記パケット化手段により作成された、符号化データを含むＴＳパケットに、ダミーパケットを追加して、一つのＩＰパケットを生成する生成動作を、前記システムに繰り返し行わせるための第１のプログラムコードと、
    前記ストリームデータの符号化レートから定まるＩＰパケットの出力レートよりも、前記ダミーパケットの追加に応じて速くした出力レートで、前記第１のプログラムコードにより生成されたＩＰパケットを前記出力手段に出力させるための第２のプログラムコードとを備えることを特徴とするプログラム。