JPWO2017135181A1 - クライアント、サーバ、受信方法及び送信方法 - Google Patents

Abstract

ＭＰＥＧ−ＤＡＳＨ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ − Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）規格によるストリーミングデータを受信するクライアント（２０Ａ）であって、ＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）の要求またはセグメントの要求をサーバに送信する送信部（２０２）と、ＭＰＤで指定されたＭＰＤ、および、セグメントの要求で指定されたセグメントを受信する受信部（２０１）と、を備え、ＭＰＤの要求は、イニシャライゼーション・セグメントをプッシュで送信することを要求する情報を含み、受信部（２０１）は、プッシュで送信されたイニシャライゼーション・セグメントを受信する。

Description

本開示は、ＭＰＥＧ−ＤＡＳＨフォーマットを使用して、帯域幅の変化するネットワーク上でマルチメディアコンテンツのストリーミングの受信を行うクライアント、及び、当該ストリーミングの送信を行うサーバと、クライアントの受信方法及びサーバの送信方法に関する。

非特許文献１は、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）によるアダプティブストリーミング技術の標準規格であるＭＰＥＧ−ＤＡＳＨ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ − Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）について開示している。ＤＡＳＨサーバは、画質およびビットレートが異なる複数の表現に対応するコンテンツデータを、時間で分割した単位であるセグメント、またはセグメントを分割したサブセグメントに対応するファイルとして提供する。セグメントまたはサブセグメントは、例えば、数秒単位に分割された単位であり、セグメントまたはサブセグメントに対応するファイルは、映像または音声を含むＭＰ４ファイルである。セグメントまたはサブセグメントに対応するファイルは、例えばＵＲＬアドレスを指定してＨＴＴＰで取得することができる。ＤＡＳＨクライアントは、コンテンツ全体または一部の構成や開始セグメントの指定が記述されたマニフェストファイル（いわゆるＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ））に基づいて、現在のネットワークの状態とスループットに応じて適切な品質（いわゆる表現）のセグメント、またはサブセグメントに対応するファイルを要求することができる。

Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats, INTERNATIONAL STANDARD, ISO/IEC 23009-1:2014(E)

しかし、非特許文献１に開示されている技術では、クライアントおよびサーバにおいて行われる処理の処理量を低減できていなかった。

本開示の一態様に係るクライアントは、ＭＰＥＧ−ＤＡＳＨ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ − Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）規格によるストリーミングデータを受信するクライアントであって、ＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）の要求またはセグメントの要求をサーバに送信する送信部と、前記ＭＰＤの要求で指定されたＭＰＤ、および、前記セグメントの要求で指定されたセグメントを受信する受信部と、を備え、前記ＭＰＤの要求は、イニシャライゼーション・セグメントをプッシュで送信することを要求する情報を含み、前記受信部は、プッシュで送信されたイニシャライゼーション・セグメントを受信する。

本開示の一態様に係るサーバは、ＭＰＥＧ−ＤＡＳＨ規格によるストリーミングデータを送信するサーバであって、ＭＰＤの要求またはセグメントの要求をクライアントから受信する受信部と、前記受信部が受信した前記ＭＰＤの要求で指定されたＭＰＤと、前記受信部が受信した前記セグメントの要求で指定されたセグメントとを、前記クライアントにプッシュで送信する送信部と、を備え、前記ＭＰＤの要求は、イニシャライゼーション・セグメントをプッシュで送信することを要求する情報を含み、前記送信部は、前記イニシャライゼーション・セグメントをプッシュで送信する。

なお、これらの全般的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。

上記態様によれば、クライアントおよびサーバにおいて行われる処理の処理量を低減できる。

図１は、実施の形態２に係る通信システムについて説明するための図である。 図２は、ＴＣＰヘッダの構成を示す図である。 図３は、Ｗｉｒｅｓｈａｒｋ（登録商標）のセッションからの抜粋を示す図である。 図４は、１００ｋＢｙｔｅ／ｓのＴＣＰ帯域幅で伝送した場合のスループットの推測結果を示すグラフである。 図５は、５００ＫＢｙｔｅ／ｓのＴＣＰ帯域幅で伝送した場合のスループットの推測結果を示すグラフである。 図６は、帯域幅を制限せずに伝送した場合のスループットの推測結果を示すグラフである。 図７は、帯域幅を制限せずに伝送した場合のスループットの推測結果を示すグラフである。 図８は、帯域幅を制限せずに伝送した場合のスループットの推測結果を示すグラフである。 図９は、帯域幅を制限せずに伝送した場合のスループットの推測結果を示すグラフである。 図１０は、実施の形態２における通信システムの詳細な構成の他の一例を示す図である。 図１１は、変形例における通信システムの動作を示すシーケンス図である。 図１２は、通信システムの具体的構成の他の一例を示す図である。 図１３は、サーバによる送信方法およびクライアントによる受信方法を含む、通信システムの動作を説明するためのシーケンス図である。

本開示の一態様に係るクライアントは、ＭＰＥＧ−ＤＡＳＨ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ − Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）規格によるストリーミングデータを受信するクライアントであって、ＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）の要求またはセグメントの要求をサーバに送信する送信部と、前記ＭＰＤの要求で指定されたＭＰＤ、および、前記セグメントの要求で指定されたセグメントを受信する受信部と、を備え、前記ＭＰＤの要求は、イニシャライゼーション・セグメントをプッシュで送信することを要求する情報を含み、前記受信部は、プッシュで送信されたイニシャライゼーション・セグメントを受信する。

本開示の一態様に係るサーバは、ＭＰＥＧ−ＤＡＳＨ規格によるストリーミングデータを送信するサーバであって、ＭＰＤの要求またはセグメントの要求をクライアントから受信する受信部と、前記受信部が受信した前記ＭＰＤの要求で指定されたＭＰＤと、前記受信部が受信した前記セグメントの要求で指定されたセグメントとを、前記クライアントにプッシュで送信する送信部と、を備え、前記ＭＰＤの要求は、イニシャライゼーション・セグメントをプッシュで送信することを要求する情報を含み、前記送信部は、前記イニシャライゼーション・セグメントをプッシュで送信する。

なお、これらの全般的または具体的な態様は、システム、方法、集積回路、コンピュータプログラムまたはコンピュータ読み取り可能なＣＤ−ＲＯＭなどの記録媒体記録媒体で実現されてもよく、システム、方法、集積回路、コンピュータプログラムまたは記録媒体の任意な組み合わせで実現されてもよい。

以下、本発明の一態様に係るクライアント、サーバ、受信方法および送信方法について、図面を参照しながら具体的に説明する。

なお、以下で説明する実施の形態は、いずれも本発明の一具体例を示すものである。以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置位置及び接続形態、ステップ、ステップの順序などは、一例であり、本発明を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素については、任意の構成要素として説明される。

（実施の形態１）
［１−１．背景技術］
ＭＰＥＧ−ＤＡＳＨは、ＩＳＯ−ＢＭＦＦフォーマットされたメディアセグメントのためのＵＲＬアドレス指定形式を指定し、マニフェストファイルは、ＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）と呼ばれる。ＤＡＳＨは、元々変数スループットのネットワーク（例えば、管理されていないインターネット接続（ＯＴＴ））を介してメディアのトランスポートに対処するために考案された。ＭＰＥＧ−ＤＡＳＨのシステムは、クライアント中心の技術思想であり、既に利用可能な技術を活用することだった。よって、既存のＨＴＴＰ−ＷＥＢサーバとＤＡＳＨ対応クライアントとは、ダイナミックストリーミングセッションを実現することができる。

最初のコンセプトは、ＭＰＥＧによって範囲が拡大され、新しいコンセプトは、ＳＡＮＤ（Ｓｅｒｖｅｒ−Ａｎｄ−Ｎｅｔｗｏｒｋ−Ａｓｓｉｓｔｅｄ−ＤＡＳＨ）、ＣＡＰＣＯ（Ｃｏｎｔｅｎｔ−Ａｇｇｒｅｇａｔｉｏｎ−ａｎｄ−Ｐｌａｙｂａｃｋ Ｃｏｎｔｒｏｌ）およびＦＤＨ（Ｆｕｌｌ−Ｄｕｐｌｅｘ−ＨＴＴＰ）などに導入された。後者のＦＤＨは、最近批准されたＨＴＴＰ／２標準を活用しており、サーバがクライアント自身によって要求されていないクライアントにプッシュすることができる。定義された関連プッシュ・ディレクティブの利点は、主にオーバヘッドを削減することにある。全てのプッシュセグメントに対して、クライアントからの対応するＨＴＴＰ要求は、省略することができ、これによって帯域幅を節約することができる。

ＤＡＳＨのＦＤＨパートは、現在、ＩＳＯ／ＩＥＣ２３００９パート６で指定され、これまでにサーバからクライアントにコンテンツをプッシュするための４つのストラテジーが含まれている。これらのストラテジーは、プッシュ・ディレクティブ（ｐｕｓｈ ｄｉｒｅｃｔｉｖｅ）と呼ばれ、プッシュ・タイプ（ｐｕｓｈ ｔｙｐｅ）と付加されるプッシュ・パラメータ（ｐｕｓｈ ｐａｒａｍｅｔｅｒ）とにより構成される。プッシュ・タイプは、例えば、プッシュ・ネクスト（ｐｕｓｈ ｎｅｘｔ）、プッシュ・ナン（ｐｕｓｈ ｎｏｎｅ）、プッシュ・テンプレート（ｐｕｓｈ ｔｅｍｐｌａｔｅ）、およびプッシュ・タイム（ｐｕｓｈ ｔｉｍｅ）を含む。

プッシュ・ネクストとプッシュパラメータＫとは、次のＫセグメントが初期インデックスとして要求されたセグメントを使用してプッシュするために考慮されることを示している。

プッシュ・ナンは、プッシュが発生していないことを示している。この場合、パラメータは使用されていない。

プッシュ・テンプレートは、ＵＲＩテンプレートによって説明されるいくつかのセグメントがプッシュのために考慮されていることを示している。プッシュパラメータはＵＲＩテンプレートと言われる。

プッシュ・タイムは、要求されたセグメントの開始（セグメントが、時間Ｔを超える指定されたセグメント時間までのプッシュのために考慮されている。時間Ｔは、プッシュパラメータとしてシグナリングされる。

プッシュ・ネクストおよびプッシュ・タイムは、それらのプッシュパラメータを０とすることで、サーバが無限にプッシュすることを選択することができることを示している。これは、既に本発明の主旨に含まれるが、サーバに、表現の選択を超えた制御をさせるものではなく、ビットレートの変動へ作用させるものでもない。

［１−２．典型的なＤＡＳＨ−ＦＤＨセッション］
クライアントは、プッシュ・ディレクティブで、最初にＭＰＤを要求し、次にメディアセグメントを要求する。要求されたＭＰＤを受け取った後、クライアントは、それぞれＤＡＳＨセグメントＵＲＬとプッシュ・ディレクティブとを用いて、サーバからのメディアセグメントの要求を開始する。そして、サーバは、要求されたメディアセグメントで応答する。メディアセグメントは、プッシュ・ストラテジー（ｐｕｓｈ ｓｔｒａｔｅｇｙ）によって示されるように、プッシュサイクルによって続けられる。クライアントは、最小量のデータを受信した後に、メディアの再生を開始する。上記のプロセスは、メディアストリーミングセッションが終了するまで繰り返される。

なお、サーバは、次のメディアセグメントのためのクライアントを準備するために、ＭＰＤを送信するだけでなく、同時に、事前にイニシャライゼーション・セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）をプッシュで送信してもよい。イニシャライゼーション・セグメントは、セグメントのヘッダ情報を含む情報である。

プッシュ・ディレクティブの利点は、オーバヘッドの削減にある。上記プッシュ・ディレクティブの全ては、まだ要求されたセグメント数のいずれかが提供されているか（プッシュ・ネクスト）、セグメント時間が超える（プッシュ・タイム）場合には、新しいセグメントを要求するためにクライアントを必要とする。以下で説明するのは、本開示一局面である新しいプッシュ・ディレクティブであり、それは、サーバが自動的にセグメントを総メディア期間にわたって選択しプッシュすることを可能にする。これによりセグメントの要求に起因するオーバヘッドは最小限に低減される。また、クライアントへの接続の全部または一部のためのユニキャスト及び/又はマルチキャストモードのアプリケーションについて、サーバ側に決定させることを可能にする。サーバが自動的に決定するのは、セグメントのビットレートや解像度など、サーバと受信端末との間のネットワーク帯域と関連するパラメータのみであってもよい。

［１−３．サーバにおけるクライアント側のスループットの推測］
本開示の一部は、ＴＣＰ／ＩＰ接続の間においてクライアントからサーバに送信された確認応答パケットに含まれる確認応答番号に基づいてクライアントのエクスペリエンスのスループットをサーバにおいて推定する方法である。これらの確認応答パケットは、ＴＣＰ層の不可欠な部分であるため、この方法を使用するには、追加のオーバヘッドは、生成または必要とされない。このスループット推定方法は、自動プッシュ・ディレクティブと共に、現在のスループットに基づいて表示を切り替えるというＤＡＳＨの技術思想を維持しつつ、総オーバヘッドを最小限に減少させる。

ＤＡＳＨは、ユビキタスＨＴＴＰプロトコルに基づく。そして、この間、ＨＴＴＰは、リクエスト、レスポンスおよびデータを転送するために基礎となるＴＣＰ／ＩＰ層に依存する。ＴＣＰ／ＩＰ層は、データ・ストリームをパケットに分割し、その信頼性の高い転送を保証する。このプロセスまで、ＨＴＴＰ層は、完全に気がつかない。パケット化処理および再構築化処理は、ＴＣＰヘッダに含まれる２つのフィールドであるシーケンスナンバーと確認応答番号とによって有効である。

シーケンスナンバーおよび確認応答番号は、ＴＣＰ接続（３ウェイハンドシェイク）の初期段階の間に両方のエンドポイントで生成される。両方の番号は、パケット化およびパケット再構築化処理に使用される。それらは、当初２つのランダムの３２ビットの整数であり、サーバとクライアントとの間で交換される。

シーケンスナンバーは、現在送信されたバイト数だけサーバによって増加される。これにより、パケット感の相対的なシーケンスナンバーは、総データバイトストリームにおける現在のパケットの開始位置へのポインタとして機能する。

さらに重要なことは、確認応答番号は、正常に受信したバイト数をサーバに通知するために、クライアントからサーバに送信される。したがって、確認応答パケットの到着時間を計測する外部タイマを持つサーバは、クライアントによる現在のエクスペリエンスのスループットを容易に推測することができる。

［１−４．効果など］
既に述べたように、本開示に係るシステムは、メトリックメッセージおよびセグメント要求が必要とされないため、オーバヘッドを低減することができる。また、本開示に係るシステムは、ユニキャストモードおよびマルチキャストモードの切り替えを集中管理することができる。また、本開示に係るシステムは、そのリソースを中央において管理することができる。つまり、スループットを監視しながら、サーバは、スループットのボトルネックを予測することができ、スムーズに伝送ビットレートを減らすことができ、これにより、表現の意図しないハイダイナミック変化を回避できる。ＨＴＴＰ／２対応のクライアントは、トラフィック診断を追跡する必要がない。トラフィック診断は、省電力化とコスト削減を同時に実現できる。

さらに、典型的には、サーバは、複数のクライアントにデータを提供する。自動プッシュ・ディレクティブとスループット推定とのメカニズムを利用すれば、サーバは、複数のクライアントが同じコンテンツを同時に要求した場合（例えば、ライブＴＶ伝送に関連）、ユニキャストモードからもっと効果的なマルチキャストモードへの切り替えを選択できる。例えばチャネル条件に応じて、ユニキャストモードまたはマルチキャストモードを、全部または一部の上記のクライアントに割り当てることができる。

特に、イベント会場など特定のエリア内での通信の場合には、入場者数、エリア内の通信端末固有の情報など他の情報に基づいて、選ばれる可能性が高いレートやセグメント自体を予め推定できる可能性もある。このような場合には、サーバにおける判断と選択処理とが簡易化され、遅延量が少なく理想的な配信が可能となる。

［１−５．本開示の概略］
・新しいＤＡＳＨの自動プッシュ・ディレクティブ
・ＤＡＳＨのプッシュパラメータ／機能指標：クライアントは、サーバがメディアセグメントを無期限に提供する前に、クライアントの能力を知らせる必要がある。

・ＴＣＰの確認応答番号に基づくスループット推定方法
・既存のＤＡＳＨプッシュ・ディレクティブ（ネクスト、タイム、テンプレート）と、クレームされた新しい自動ＤＡＳＨプッシュ・ディレクティブとの組合せ
・例：サーバは、自動的に次のＫセグメントをプッシュし、その後、自動的に次のＬセグメントをプッシュするための新しいプッシュリクエストを受信する。
・同時に同じコンテンツをリクエストしている全部または一部のクライアントのためのユニキャストモードまたはマルチキャストモードの自動および動的選択（上記のスループット測定値に基づく）

［１−５−１．詳細１］
新しいＤＡＳＨプッシュ・ディレクティブは、サーバによって監視されるように、サーバがデータを選択し、クライアントにプッシュすることを可能にする。以下では、このプッシュ・ディレクティブを、自動プッシュ・ディレクティブと言う。

［１−５−２．詳細２］
ＤＡＳＨは、プッシュ・ディレクティブに伴ってパラメータをプッシュする。また、クライアントの能力は、サーバに通知される。クライアントは、例えば、利用可能なメディアデコーダ、再生可能な画像解像度、およびフレームレートについて処理できる装置である。実施の形態では、プッシュパラメータは、表１−１および表１−２に示すように、受信能力テーブル（ＲＣＴ：Ｒｅｃｅｉｖｅｒ Ｃａｐａｂｉｌｉｔｙ Ｔａｂｌｅ）から取り出したフィールドを持つ複合データタイプによって表現されてもよい。本実施の形態は、限定的に理解されるべきではない。例えば、サーバへのクライアントの能力を通信する同じ目的を果たす受信能力テーブルの任意の形式にまで及ぶことに限定されるべきではない。

“ｍｏｄｅＩｎｄｉｃａｔｏｒ”は、実際のパラメータを選択する際に、サーバをガイドする。適したモードは、例えば、最高品質、最低品質、および表現の切り替えにおける低ダイナミックである。これらは、表２に示される。他のモードも可能であり、本発明は、示されるこれらのモードに限定されるものとして理解されるべきではない。

［１−５−３．詳細３］
他のＤＡＳＨのプッシ・ディレクティブの組合せは、自動またはプッシュ自動速度のプッシュ・ディレクティブを有する。本開示の一実施形態では、自動プッシュ・ディレクティブと組み合わせるための適切なプッシュ・ディレクティブは、プッシュ・ネクスト、プッシュ・タイムおよびプッシュ・テンプレートであるとしてもよい。なお、これらの組合せに限定されるべきではない。

例えば、プッシュ・ネクストを用いて次のＮ個のセグメントを受信するように指定し、かつ、プッシュ・オートマティック・レート（ｐｕｓｈ−ａｕｔｏｍａｔｉｃ−ｒａｔｅ）を指定することで、Ｎ個のセグメントのビットレートはサーバが自動的に選択する。あるいは、プッシュ・オートマティック・レートは、別途規定するプッシュ・ディレクティブであるプッシュ・チャネル・オートマティック・レート（ｐｕｓｈ−ｃａｎｃｅｌ−ａｕｔｏｍａｔｉｃ−ｒａｔｅ）によって無効化されるまで有効としてもよい。このとき、プッシュ・チャネル・オートマティック・レートが発行されなければ、上記Ｎ個のセグメントの送信後に送られるセグメントに対してもプッシュ・オートマティック・レートが有効となる。

プッシュ・フル・オートマティック（ｐｕｓｈ−ｆｕｌｌ−ａｕｔｏｍａｔｉｃ）が指定された後であっても、セグメントの送信中にサーバがプッシュ・ナンを受信した場合には、サーバは直ちに、あるいは、送信中のセグメントの最終データ送信後にセグメントの送信を停止する。

［１−５−４．詳細４］
推定方法および推定装置は、外部タイマで確認応答パケットの到着時間を計測することで、クライアントからサーバにＴＣＰヘッダにおいて送信された確認応答番号に基づいて、クライアントのスループットの推定を行う。

現在の確認応答番号と最初の確認応答番号との間の差としての相対的な確認応答番号が示され、同様に、現在の確認応答パケットの到着時間と最初の確認応答パケットの到着時間との間の差としての相対的な時間が示される。スループット推定のための最初の方法は、相対的な確認応答番号と相対的な時間との商を算出することである。

最後と最後から２番目の確認応答パケットとの間の差としての確認応答番号の差を示す。同様に、最後と最後から２番目の確認応答パケットとの間の到着時間の差としての時間差を示す。スループット推定のための第二の方法は、適切なデジタルフィルタによる確認応答番号の差と時間差との連続的な商の平均を算出することである。

［１−５−５．詳細５］
（セグメント毎の極端なケースにおいて）自動的および動的な選択が行われる。自動的および動的な選択では、上述のスループット計測方法（それぞれの単一のクライアントへの接続の品質を表す）に基づき、同時に同じコンテンツをリクエストしている全部または一部のクライアントのためのユニキャストモードまたはマルチキャストモードの選択を行う。

（実施の形態２）
［２−１．背景技術］
ＤＡＳＨの哲学は、クライアントがスループットを計測し、それらの計測値に基づいてセグメントを要求することに基づいている。最近では、ＨＴＴＰ／２は、サーバが求められていないクライアントにデータを送信することが可能な新しいプッシュ機能を導入した。ＤＡＳＨ仕様のパート６では、ＭＰＥＧは、ＤＡＳＨのために、この新しいＨＴＴＰ／２機能を活用したいと考えている。パート６は、ＦＤＨと呼ばれている。４つのプッシュ・ディレクティブは、すでに（プッシュ・ネクスト、プッシュ・ナン、プッシュ・テンプレート、プッシュ・タイム）が存在するが、それらは依然として大部分はクライアントによって駆動される。

実施の形態１で説明したとおり、クライアントへのスループットは、サーバ側で測定することができる。つまり、サーバでは、新しい自動プッシュ・ディレクティブを用いることでクライアントを管理することができる。

セグメントの選択は、一部または全てにおいて、プッシュ・ディレクティブに基づいてサーバによって制御される。つまり、セグメントを送る数または時間とそのビットレートなどは、サーバによって決定される。

［２−２．計測のセットアップ］
図１は、実施の形態２に係る通信システムについて説明するための図である。図１の（ａ）は、通信システムの構成の一例を示すブロック図であり、図１の（ｂ）は、通信システムにおける通信状況について説明するための図である。

図１の（ａ）に示すように、通信システム１は、サーバ１０と、サーバ１０と通信ネットワーク３０を介して通信接続されるクライアント２０とを備える。

サーバ１０は、ＨＴＴＰ／２サーバである。サーバ１０は、カスタムトラフィックシェーピングのためにダミーネットを実行する。サーバ１０は、パケットの取得状況やプロトコルを解析するためのソフトウェア（例えば、Ｗｉｒｅｓｈａｒｋ（登録商標））を実行することで、ｐｃａｐファイル（ｓｃａｐｙパッケージを持つＰｙｔｈｏｎで更なる処理）への全てのパケットをキャプチャする。ここで、ｐｃａｐ（ｐａｃｋｅｔ ｃａｐｔｕｒｅ）とは、コンピュータネットワーク管理の分野におけるパケットスニファ（パケットアナライザ）のためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）である。Ｕｎｉｘ（登録商標）系のシステムではｐｃａｐはｌｉｂｐｃａｐとして実装されている。

サーバ１０は、１ＭＢのファイルをＰＲＢＳ（Ｐｓｅｕｄｏ−Ｒａｎｄｏｍ Ｂｉｔ Ｓｅｑｕｅｎｃｅ：擬似ランダム・ビット・シーケンス）と共に送信する。ダミーネットは、トラフィックシェーピングのため、特に送信帯域幅を制御するために利用される。Ｗｉｒｅｓｈａｒｋ（登録商標）は、ＴＣＰ／ＩＰトラフィックをキャプチャし保存する。Ｐｙｔｈｏｎは、Ｗｉｒｅｓｈａｒｋ（登録商標）のキャプチャに基づいて、データ集約と評価のために使用される。

サーバ１０は、プロセッサおよび所定のプログラムが格納されたメモリにより実現されてもよいし、専用回路により実現されてもよい。サーバ１０は、コンピュータを含む。

クライアント２０は、ＴＶ、プレーヤ、レコーダ、スマートフォン、タブレット端末、ＰＣ等によって実現されてもよい。

図１の（ｂ）に示すように、サーバ１０からファイルが送信されたタイミング（タイムスタンプ）と、当該ファイルに対するＡＣＫがクライアント２０から送信されたタイミングとを取得することができる。

［２−３．ダミーネット］
次に、サーバ１０が実行するダミーネットについて説明する。

ダミーネットは、ネットワークエミュレーションツールである。ダミーネットは、キュー、帯域幅制限、遅延、パケットロスをシミュレートし、様々なスケジューリングアルゴリズムを実装している。ダミーネットは、任意のオペレーティングシステム内で実行され、ネットワークスタックを通じて途中で選択されたトラフィックを傍受することにより動作する。それは、キューのセット、スケジューラ、およびリンク、全ての設定可能な機能（帯域幅、遅延、損失率、キューサイズ、スケジューリングポリシー・・・）を実装するパイプにパケットを渡す。トラフィックの選択は、ダミーネットのためのメインユーザインタフェースであるｉｐｆｗファイアウォールを使用して行われる。「Ｈｅｌｌｏ ｗｏｒｌｄ」、全ての発信ＴＣＰトラフィックにパイプを作成し、５００ｋＢｙｔｅ／ｓに帯域幅を設定する。例えば、パケットフィルタ型のファイアウォールであるｉｐｆｗ（ｉｐｆｉｒｅｗａｌｌ）は、ｐｒｏｔｏ ｔｃｐの外にパイプ１つを追加する。また、例えば、ｉｐｆｗのパイプ１つは、帯域幅を５００ｋＢｙｔｅ／ｓに設定する。

［２−４．ＴＣＰヘッダ］
次に、ＴＣＰヘッダについて説明する。

図２は、ＴＣＰヘッダの構成を示す図である。

図２に示すように、ＴＣＰヘッダは、シーケンスナンバー（Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ）と応答確認番号（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ Ｎｕｍｂｅｒ）とを含む。

シーケンスナンバーは、全体的な送信データのバイトストリームにおける、現在のペイロードの位置へのポインタである。また、シーケンスナンバーは、受信したパケットが送信されたのと同じ順に当該パケットをソートするために利用される。

応答確認番号は、特定のシーケンス番号を揺するパケットが正しく受信されたことを示す。また、応答確認番号は、次に予想されるシーケンスナンバーを含む。

（クライアントからサーバに送信される）応答確認番号から、サーバ１０は、正常に受信したバイト数を導出することができる。ＡＣＫパケットのタイミングをさらに用いれば、現在のスループットを推定することができる。

３ウェイハンドシェイクの間、両方のエンドポイント（つまり、サーバ１０およびクライアント２０）は、それぞれに対応するシーケンスナンバーについてランダムな３２ビットの整数を生成し、それらを交換する。Ｗｉｒｅｓｈａｒｋ（登録商標）のセッションからの抜粋（図３）に示すように、四角で囲んだ部分は、シーケンス番号および応答確認番号を示す。送信のエンドポイントは、現在送信されたバイト数によってそのシーケンスナンバーを増加させる。応答確認番号は、正しく受信されたバイト数を示すためにクライアントによって使用される。

図４〜図９は、実際に伝送されたバイト数と、上記の方法で推測したスループットの結果とを示すグラフである。図４は、１００ｋＢｙｔｅ／ｓのＴＣＰ帯域幅で伝送した場合のスループットの推測結果を示すグラフである。図５は、５００ＫＢｙｔｅ／ｓのＴＣＰ帯域幅で伝送した場合のスループットの推測結果を示すグラフである。図６〜図９は、帯域幅を制限せずに伝送した場合のスループットの推測結果を示すグラフである。

図４〜図９に示すように、推測結果は、実際に伝送されたバイト数と概ね一致するため、推測結果を利用することができる。

上述したように、上記サーバ側スループット測定は、主に実行可能であることを示している。

これにより、サーバ１０は、そのリソースを主に管理することができる。サーバ１０は、クライアント２０側の表現のバラツキを、より回避できる。クライアント２０は、賢くなくてもよく、トラフィック診断を追跡する必要がない。メトリック／診断メッセージを保存することでオーバヘッドを低減できる。

例えば、表３に示すように、プッシュ・オートマティック・レートおよびプッシュ・フル・オートマティックを追加したプッシュ・ディレクティブを採用してもよい。

図１０は、実施の形態２における通信システムの詳細な構成の他の一例を示す図である。

通信システム１は、サーバ１０と、クライアント２０とを備える。サーバ１０と、クライアント２０とは、通信ネットワーク３０を介して互いに通信接続されている。

サーバ１０およびクライアント２０は、プロセッサ、ストレージおよび送受信機を含む通信機を有する。

サーバ１０およびクライアント２０のそれぞれが備えるプロセッサは、シーケンス図（図１１参照）で示す処理を実行する。プロセッサは、サーバ１０およびクライアント２０または他の装置との連携における他のユニットを使用する。典型的には、フローに示す処理を実行するためのプログラムは、それぞれ、サーバ１０およびクライアント２０が備えるストレージに記憶されている。

サーバ１０は、選択部１１および送信部１２を備える。

サーバ１０およびクライアント２０についての詳細な説明は、それぞれ通信システム１における動作の説明において行う。

図１１は、通信システムの動作の一例を示すシーケンス図である。

まず、クライアント２０は、ＭＰＤの要求を示すＭＰＤ要求（ＭＰＤ ｒｅｑｕｅｓｔ）をサーバ１０に送信する（Ｓ１１）。

次に、サーバ１０は、クライアント２０から送信されたＭＰＤ要求を受信し、サーバ１０の送信部１２は、受信したＭＰＤ要求に対応するＭＰＤ（対応ＭＰＤ）をクライアント２０に送信する（Ｓ１２）。なお、実施の形態１で説明したとおり、Ｓ１２において、サーバ１０は、受信したＭＰＤ要求に対応するＭＰＤに加えて、一部またはすべてのイニシャライゼーション・セグメントをクライアント２０にプッシュで送信してもよい。以下、ＭＰＤ要求に応じて、ＭＰＤ要求で指定されたＭＰＤに加えて、イニシャライゼーション・セグメントや更新された新しいＭＰＤ等の他のファイルをプッシュで送信することをＭＰＤプッシュ（ＭＰＤ ｐｕｓｈ）とも言う。

なお、サーバ１０がイニシャライゼーション・セグメントをプッシュで送信しない場合のクライアント２０の動作は、プッシュ送信に対応しないサーバと通信を行う場合と同様である。すなわち、クライアント２０は、受信したＭＰＤに記載されたイニシャライゼーション・セグメントのうちの必要なイニシャライゼーション・セグメントを指定したセグメント要求を送信する。サーバ１０は、受信したセグメント要求で指定されたイニシャライゼーション・セグメントをクライアント２０に送信する。

クライアント２０は、対応ＭＰＤを受信し、１以上のプッシュ・ディレクティブと共に、セグメント＃ｎの要求を示すセグメント要求（Ｓｅｇｍｅｎｔ ｒｅｑｕｅｓｔ）をサーバ１０に送信し、Ａｃｋを計測する（Ｓ１３）。

サーバ１０は、プッシュ・ディレクティブを指定したセグメント＃ｎのセグメント要求受信し、サーバ１０の選択部１１は、受信したセグメントのプッシュ・ディレクティブに基づいて固定レートまたは適応レートを決定し、受信したセグメント＃ｎのセグメント要求に基づいて送信するセグメントを選択する（Ｓ１４）。

サーバ１０は、セグメント要求で指定されたセグメントｎを送信し、選択部１１が選択した、セグメントｎ＋１以降のセグメントをプッシュで順次送信する（Ｓ１５、Ｓ１６）。以下、セグメント要求に応じて、セグメント要求で指定されたセグメント以外のセグメントをプッシュで送信することをセグメント・プッシュ（Ｓｅｇｍｅｎｔ ｐｕｓｈ）とも言う。

なお、セグメントｎの送信は、固定レートまたは適応レートを決定する前に行ってもよい。また、選択部１１は、セグメントｎ以降のセグメントの選択を上述したＡｃｋを用いた計測で得られたスループットに基づいて行う。なお、セグメント＃ｎのセグメント要求で指定されたプッシュ・ディレクティブが、プッシュ・オートマティック・レートやプッシュ・フル・オートマティック以外のプッシュ送信を要求するプッシュ・ディレクティブの場合は、選択部１１は、スループットの計測を行うことなく、セグメント＃ｎのセグメント要求で指定されたプッシュ・ディレクティブに従ってセグメントｎ＋１以降のセグメントを選択する。

なお、図１０では、サーバ１０が備える構成として、適応レートでセグメントを送信するために必要な、選択部１１及び送信部１２のみを記載している。しかしながら、サーバ１０が、例えば非特許文献１に記載のＤＡＳＨサーバとしての動作に必要なその他の構成を備えていることは言うまでもない。例えば、サーバ１０は、クライアント２０が送信したＭＰＤ要求やセグメント要求などのメッセージを受信する受信部や、受信したメッセージに含まれるＤＡＳＨコマンドの解釈や、ＭＰＤ要求やセグメント要求などのメッセージに対する応答としてクライアント２０に送信するメッセージの生成等を行う処理部等を備える。

図１０では、ＭＰＤ配送機能がサーバ１０の外部に配置された例を示しているが、これは、ＭＰＤをサーバ１０とは異なる通信装置からクライアント２０に送信されてもよいことを示している。ただし、以下の図１１の説明のように、クライアント２０から送信されたＭＰＤ要求に応じてサーバ１０がクライアント２０にＭＰＤを送信する場合、サーバ１０がＭＰＤ送信機能を備える。

図１０では、スループット計測モジュールがサーバ１０の外部に配置された例を示しているが、サーバ１０がスループット計測モジュールを備えていてもよい。

なお、サーバ１０が、上述したプッシュ・オートマティック・レートやプッシュ・フル・オートマティックといったサーバ側でビットレートの制御を行うプッシュ・ディレクティブに対応しない場合、図１０に示したスループット計測モジュールはなくてもよい。その場合、サーバ１０の選択部１１はクライアント２０から受信したセグメント要求に付加された、サーバ側でビットレートの制御を行うプッシュ・ディレクティブ以外のプッシュ・ディレクティブ（例えば、プッシュ・ネクスト、プッシュ・テンプレート、プッシュ・タイム）に基づいて、プッシュ送信するセグメントを選択する。なお、プッシュ・ナンを指定された場合、クライアント２０は、サーバ１０に対して再生に必要なセグメントを指定したセグメント要求を送信して、当該セグメントを取得する。

また、図１０では、クライアント２０について詳細な構成を開示していないが、クライアント２０は、例えば非特許文献１に記載のＤＡＳＨクライアントとしての動作に必要なその他の構成を備えていることは言うまでもない。例えば、クライアント２０は、サーバ１０またはその他の通信装置に対してＭＰＤ要求、セグメント要求及びＡｃｋ等のメッセージを送信する送信部や、サーバ１０またはその他の通信装置からＭＰＤ、セグメント、ＤＡＳＨコマンドを含むメッセージ等を受信する受信部を備える。さらに、クライアント２０は、受信したメッセージに含まれるＤＡＳＨコマンドの解釈や、ＭＰＤ要求やセグメント要求等のサーバ１０またはその他の通信装置に送信するＤＡＳＨコマンドの生成を行うＤＡＳＨアクセス部を備える。また、クライアント２０は、ＤＡＳＨアクセス部で取得されたメディアデータを復号し、復号された音声信号や映像信号をクライアントの内部、またはクライアントと有線、または無線で接続された外部の表示部に表示する復号部を備えていてもよい。なお、上述した表示部は、例えば、ディスプレイやスピーカー等である。また、クライアント２０は、ＤＡＳＨアクセス部で取得されたイベントデータを実行するアプリケーション部を備えていてもよい。

［３．変形例］
上述した実施の形態において、以下のような変形が適用可能である。

［３−１．変形例１］
上述した実施の形態においては、プッシュ・オートマティック・レートやプッシュ・フル・オートマティックをプッシュ・ネクストやプッシュ・ナンと並列の“ｐｕｓｈＴｙｐｅ”として指定可能な新しいプッシュ・ストラテジーとして規定する場合を例に挙げて説明したが、他の形式で規定されていてもよい。

例えば、プッシュ・オートマティック・レートやプッシュ・フル・オートマティックは、ＰｕｓｈＴｙｐｅでプッシュ・ネクストを選択した場合に指定するパラメータ（ＰＵＳＨ＿ＰＡＲＡＭＳ）である“Ｋ：Ｎｕｍｂｅｒ”と並列の（併記可能な）パラメータとして定義してもよい。この場合、プッシュ・ディレクティブまたはＰｕｓｈＡｃｋのＰＵＳＨ＿ＰＡＲＡＭＳにおいて、複数のパラメータが併記される。同様に、ＰｕｓｈＴｙｐｅとしてプッシュ・テンプレートやプッシュ・タイプが選択された場合も、ＰＵＳＨ＿ＰＡＲＡＭＳにおいて、“ａｕｔｏｍａｔｉｃ”であるか否か、または“ａｕｔｏｍａｔｉｃ”のモードを指定できる。

また、例えば、プッシュ・オートマティック・レートやプッシュ・フル・オートマティックは、プッシュ・ディレクティブにおいて、ＰＵＳＨ＿ＴＹＰＥと並列の（併記される）パラメータとして定義してもよい。この場合、プッシュ・ディレクティブのフォーマットに、ＰＵＳＨ＿ＴＹＰＥとは別に、“ａｕｔｏｍａｔｉｃ”であるか否か、または“ａｕｔｏｍａｔｉｃ”のモードを指定する領域が設けられる。

［３−２．変形例２］
上述した実施の形態において、以下のような変形が適用可能である。ただし、以下の構成は、上述した実施の形態（例えば、セグメント・プッシュにおける“ａｕｔｏｍａｔｉｃ”指定）と組み合わせずに使用してもよい。このように“ａｕｔｏｍａｔｉｃ”を独立の属性として扱うことで、サーバ１０が送出するセグメントの個数、時間長、ビットレートだけでなく、他のパラメータについても、サーバ１０が自動的に決定するか否かを指定できる。

例えば、ＭＰＤ要求において、プッシュ・ディレクティブ（またはその他のＤａｔａ Ｔｙｐｅ）を用いてＭＰＤプッシュを指定する場合、以下のいずれかの構成、または以下の任意の構成の組み合わせを用いてもよい。

（１）
ＭＰＤ要求において、プッシュ・ディレクティブを用いてＭＰＤプッシュの実施が指定されると、サーバ１０は、ＭＰＤが更新されると新たなＭＰＤをプッシュで送信してもよい。

（２）
ＭＰＤ要求において、プッシュ・ディレクティブを用いてＭＰＤプッシュの実施が指定されると、サーバ１０は、指定されたＭＰＤに加えて、メディアデータの復号または表示に関連するメタデータをｐｕｓｈで送信してもよい。ここで、メタデータの一例としては、メディアデータがＭＰ４の場合のＭＰ４のヘッダ情報（つまりイニシャライゼーション・セグメント）が挙げられる。メタデータには、例えば、音声や映像の符号化データへのアクセス情報や、ＰＴＳ／ＤＴＳなどが格納される。つまり、サーバ１０は、ＭＰＤと共にイニシャライゼーション・セグメントをクライアント２０に送信してもよい。なお、この場合、ＭＰＤ要求のプッシュ・ディレクティブによって、メタデータをプッシュで送信するか否かを指定できるようにしてもよい。

（３）
ＭＰＤ（または、メタデータ）がサーバ１０によりプッシュで送信される期間または数は、例えば、ｐｕｓｈ ｔｙｐｅにより指定されてもよい。つまり、サーバ１０は、ｐｕｓｈ ｔｙｐｅにより指定された期間または数のＭＰＤ（及びメタデータ）をプッシュで送信してもよい。

（４）
ＭＰＤプッシュが指定された場合、サーバ１０は、予め規定された動作（デフォルト動作）を行うものとし、ＭＰＤ要求におけるプッシュ・ディレクティブは、ＭＰＤプッシュを実施するか否かを指定するだけとしてもよい。ただし、クライアント２０またはサーバ１０からＭＰＤプッシュの中止（行わない）を指定できるようにしてもよい。

なお、クライアント２０がＭＰＤプッシュを要求するプッシュ・ディレクティブを指定したＭＰＤ要求を送信したがサーバ１０がＭＰＤプッシュを行わないと指定した場合、クライアント２０の以降の動作はＭＰＤプッシュに対応しないクライアントの動作と同様であることはいうまでもない。すなわち、クライアント２０は、所望のメディアの再生に必要なイニシャライゼーション・セグメントを、サーバ１０にセグメント要求を送信することで取得する。

このように、サーバ１０がＭＰＤプッシュを行わないことを指定できるようにすることで、イニシャライゼーション・セグメントのプッシュ送信を要求するクライアント２０に対しても、サーバ１０がイニシャライゼーション・セグメントのプッシュ送信を行わないことを決定して、クライアントに通知することができるので、サーバ１０における制御の自由度が高くなる。

（５）
ＭＰＤプッシュにおいては、セグメント・プッシュの場合とは異なり、例えば、全てのイニシャライゼーション・セグメントを送信することも可能なため、サーバ１０またはクライアント２０が、対応する複数のセグメント（例えば、互いに異なるｂｉｔ ｒａｔｅを有するセグメント）の中からいずれか一つのセグメントを選択する必要がない可能性がある。このように、ＭＰＤプッシュで選択できるプッシュ・ストラテジーと、セグメント・プッシュで選択できるプッシュ・ストラテジーとが異なる場合、ＭＰＤ要求でプッシュ・ストラテジーを指定するための“ＭＰＤ ｐｕｓｈ Ｄｉｒｅｃｔｉｖｅ”と、セグメント要求でプッシュ・ストラテジーを指定するための“Ｓｅｇｍｅｎｔ ｐｕｓｈ Ｄｉｒｅｃｔｉｖｅ”とを別に規定してもよい。また、ＭＰＤ要求とセグメント要求とにおいて、同じフォーマットのプッシュ・ディレクティブを用いるが、ＭＰＤ要求において使用可能なパラメータを制限してもよい。例えば、ａｕｔｏｍａｔｉｃの使用を禁止することでＭＰＤ要求において使用可能なパラメータを制限する。

（６）
ＭＰＤ要求のプッシュ・ディレクティブにおいて、メディア・セグメントのプッシュ・ストラテジーを指定できるようにしてもよい。

例えば、ＭＰＤ要求においてＭＰＤプッシュのプッシュ・ストラテジーとセグメントのプッシュ・ストラテジーとを個別に指定してもよい。

また、例えば、ＭＰＤ要求においてメディア・セグメントのプッシュ・ストラテジーが指定されると、指定されたセグメントのプッシュ・ストラテジーに対応するＭＰＤプッシュのプッシュ・ストラテジー（プッシュ・ナンを含む）が自動的に選択・生成されてもよい。

また、例えば、ＭＰＤ要求においてＭＰＤプッシュのプッシュ・ストラテジーが指定されると、指定されたＭＰＤプッシュのプッシュ・ストラテジーに対応するセグメントのプッシュ・ストラテジー（プッシュ・ナンを含む）が自動的に選択または生成されてもよい。

［４．補足：クライアントおよびサーバ］
図１０及び図１１を用いた説明では、プッシュ・ディレクティブで、オートマティックを指定可能なクライアント及びサーバについて示した。以下では、上記の変形例の説明で言及したプッシュ・ディレクティブで、オートマティックを用いない場合における、ＭＰＥＧ−ＤＡＳＨ規格によるストリーミングデータを受信する受信装置としてのクライアント、及び、当該ストリーミングデータを送信する送信装置としてのサーバの構成の一例について説明する。

図１２は、通信システムの構成の他の一例を示す図である。

サーバ１０Ａおよびクライアント２０Ａは、図１０でも説明したようにプロセッサ、ストレージ、および送受信機を含む通信機を有する。

通信システム１Ａは、サーバ１０Ａおよびクライアント２０Ａが図示しない通信ネットワークにより互いに通信接続されることにより構成されている。

サーバ１０Ａは、受信部１０１と、送信部１０２とを備える。受信部１０１および送信部１０２のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。また、図１２には図示されていないが、図１０のサーバ１０と同様に、サーバ１０Ａは、選択部や処理部を備えていてもよい。

なお、サーバ１０Ａが備える
（１）ＭＰＤの送信
（２）セグメントの送信
（３）受信したＤＡＳＨコマンドの解釈とクライアント２０ＡへのＤＡＳＨコマンドの送信
の機能は、同一のサーバで実施されてもよいし、複数のサーバのそれぞれが少なくともいずれか一つの機能を実施し、当該複数のサーバによって上記の機能が統合された動作としてクライアント２０Ａに提供されてもよい。

クライアント２０Ａは、受信部２０１と、送信部２０２とを備える。受信部２０２および送信部２０２のそれぞれは、例えば、マイクロコンピュータ、プロセッサ、または、専用回路などによって実現される。また、図１２には図示されていないが、図１０のクライアント２０と同様に、クライアント２０Ａは、ＤＡＳＨアクセス部、復号部、アプリケーション部を備えていてもよい。

サーバ１０Ａおよびクライアント２０Ａの各構成要素が実施する動作についての説明は、それぞれ、送信方法および受信方法の説明において行う。

サーバ１０Ａおよびクライアント２０Ａが実施する送信方法および受信方法の一例について、図１３を用いて説明する。

図１３は、サーバによる送信方法およびクライアントによる受信方法を含む、通信システムの動作を説明するためのシーケンス図である。

クライアント２０Ａの動作（受信方法）について説明する。

クライアント２０Ａの送信部２０２は、１以上のプッシュ・ディレクティブと共に必要なＭＰＤを指定したＭＰＤ要求をサーバに送信する（Ｓ２０１）。クライアント２０Ａが送信するＭＰＤ要求には、ＭＰＤ要求で指定されたＭＰＤに加えて、当該ＭＰＤにより参照されるイニシャライゼーション・セグメントをプッシュで送信することを要求するプッシュ・ディレクティブが設定されている。

クライアント２０Ａの受信部２０１は、ＭＰＤ要求で指定したＭＰＤとプッシュで送信されたイニシャライゼーション・セグメントとを受信する。

そして、クライアント２０Ａの送信部２０２は、１以上のプッシュ・ディレクティブと共にセグメントｎを指定したセグメント要求とを送信する（Ｓ２０２）。

サーバ１０Ａの動作（送信方法）について説明する。

サーバ１０Ａの受信部１０１は、ステップＳ２０１により送信された、１以上のプッシュ・ディレクティブと共にＭＰＤを指定したＭＰＤ要求をクライアント２０Ａから受信する。

サーバ１０Ａの送信部１０２は、受信部１０１が受信したＭＰＤ要求で指定されたＭＰＤに加えてイニシャライゼーション・セグメントを、クライアント２０Ａに送信する（Ｓ１０１）。

サーバ１０Ａの受信部１０１は、ステップＳ２０２により送信された、１以上のプッシュ・ディレクティブと、セグメントｎを指定したセグメント要求とを受信する。

サーバ１０Ａの送信部１０２は、セグメント要求で指定されたセグメントｎを、クライアント２０Ａに送信する（Ｓ１０２）。

同様に、サーバ１０Ａの送信部１０２は、セグメントｎ＋１以降のセグメントを、クライアント２０Ａにプッシュで送信する（Ｓ１０３）。

このように、クライアント２０Ａは、イニシャライゼーション・セグメントの要求を意味するプッシュ・ディレクティブと共にＭＰＤ要求をサーバ１０Ａに送信するため、従来のＭＰＤ要求を送信してＭＰＤを受信した後にイニシャライゼーション・セグメントを指定したセグメント要求を送信してイニシャライゼーション・セグメントを受信するように、ＭＰＤ要求とイニシャライゼーション・セグメント要求とを分けて送信する場合と比較して、処理を１ステップ削減できる。このため、処理量を効果的に低減できる。

なお、上記各実施の形態において、各構成要素は、専用のハードウェアで構成されるか、各構成要素に適したソフトウェアプログラムを実行することによって実現されてもよい。各構成要素は、ＣＰＵまたはプロセッサなどのプログラム実行部が、ハードディスクまたは半導体メモリなどの記録媒体に記録されたソフトウェアプログラムを読み出して実行することによって実現されてもよい。ここで、上記各実施の形態の受信方法および送信方法などを実現するソフトウェアは、次のようなプログラムである。

すなわち、このプログラムは、コンピュータに、ＭＰＥＧ−ＤＡＳＨ規格によるストリーミングデータを受信するクライアントにおける受信方法であって、ＭＰＤの要求またはセグメントの要求をサーバに送信し、前記ＭＰＤの要求で指定されたＭＰＤ、および、前記セグメントの要求で指定されたセグメントを受信し、前記ＭＰＤの要求は、イニシャライゼーション・セグメントをプッシュで送信することを要求する情報を含み、前記受信では、プッシュで送信されたイニシャライゼーション・セグメントを受信する受信方法を実行させる。

また、このプログラムは、コンピュータに、ＭＰＥＧ−ＤＡＳＨ規格によるストリーミングデータを送信するサーバにおける送信方法であって、ＭＰＤの要求またはセグメントの要求をクライアントから受信し、受信した前記ＭＰＤの要求で指定されたＭＰＤと、受信した前記セグメントの要求で指定されたセグメントとを、前記クライアントにプッシュで送信し、前記ＭＰＤの要求は、イニシャライゼーション・セグメントをプッシュで送信することを要求する情報を含み、前記送信では、前記イニシャライゼーション・セグメントをプッシュで送信する送信方法を実行させる。

以上、本発明の一つまたは複数の態様に係るクライアント、サーバ、受信方法および送信方法について、実施の形態に基づいて説明したが、本発明は、この実施の形態に限定されるものではない。本発明の趣旨を逸脱しない限り、当業者が思いつく各種変形を本実施の形態に施したものや、異なる実施の形態における構成要素を組み合わせて構築される形態も、本発明の一つまたは複数の態様の範囲内に含まれてもよい。

本開示は、ＭＰＥＧ−ＤＡＳＨ規格によるストリーミングデータの送信または受信を行う装置または機器に適用できる。

１ 通信システム
１０、１０Ａ サーバ
１１ 選択部
１２ 送信部
２０、２０Ａ クライアント
３０ 通信ネットワーク
１０１ 受信部
１０２ 送信部
２０１ 受信部
２０２ 送信部

Claims (4)

1. ＭＰＥＧ−ＤＡＳＨ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ − Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ）規格によるストリーミングデータを受信するクライアントであって、
   ＭＰＤ（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）の要求またはセグメントの要求をサーバに送信する送信部と、
   前記ＭＰＤの要求で指定されたＭＰＤ、および、前記セグメントの要求で指定されたセグメントを受信する受信部と、を備え、
   前記ＭＰＤの要求は、イニシャライゼーション・セグメントをプッシュで送信することを要求する情報を含み、
   前記受信部は、プッシュで送信されたイニシャライゼーション・セグメントを受信する
   クライアント。
2. ＭＰＥＧ−ＤＡＳＨ規格によるストリーミングデータを送信するサーバであって、
   ＭＰＤの要求またはセグメントの要求をクライアントから受信する受信部と、
   前記受信部が受信した前記ＭＰＤの要求で指定されたＭＰＤと、前記受信部が受信した前記セグメントの要求で指定されたセグメントとを、前記クライアントにプッシュで送信する送信部と、を備え、
   前記ＭＰＤの要求は、イニシャライゼーション・セグメントをプッシュで送信することを要求する情報を含み、
   前記送信部は、前記イニシャライゼーション・セグメントをプッシュで送信する
   サーバ。
3. ＭＰＥＧ−ＤＡＳＨ規格によるストリーミングデータを受信するクライアントにおける受信方法であって、
   ＭＰＤの要求またはセグメントの要求をサーバに送信し、
   前記ＭＰＤの要求で指定されたＭＰＤ、および、前記セグメントの要求で指定されたセグメントを受信し、
   前記ＭＰＤの要求は、イニシャライゼーション・セグメントをプッシュで送信することを要求する情報を含み、
   前記受信では、プッシュで送信されたイニシャライゼーション・セグメントを受信する
   受信方法。
4. ＭＰＥＧ−ＤＡＳＨ規格によるストリーミングデータを送信するサーバにおける送信方法であって、
   ＭＰＤの要求またはセグメントの要求をクライアントから受信し、
   受信した前記ＭＰＤの要求で指定されたＭＰＤと、受信した前記セグメントの要求で指定されたセグメントとを、前記クライアントにプッシュで送信し、
   前記ＭＰＤの要求は、イニシャライゼーション・セグメントをプッシュで送信することを要求する情報を含み、
   前記送信では、前記イニシャライゼーション・セグメントをプッシュで送信する
   送信方法。

Images