JP6327809B2 - 受信装置、制御方法及びプログラム - Google Patents

Description

本発明は受信装置、制御方法及びプログラムに関し、特に、メディアデータとメディアデータの再生区間情報を所定の時間毎にネットワークを介して連続して送受信するために用いて好適な技術に関する。

近年、ネットワークカメラやビデオ会議システムなど、ネットワークを介してメディアデータをリアルタイムに送受信するストリーミング技術が実用化されている。このようなストリーミング技術の例として、プレイリストとセグメントを利用してメディアデータをストリーミングする方法が標準規格化されている。例えば、（HTTP Live Streaming（非特許文献１参照）、MPEG-DASH（非特許文献２参照）等）。

プレイリストとは、メディアデータの再生区間情報であり、セグメントとは所定の単位時間に分割されたメディアデータである。前述した標準規格では、プレイリストとセグメントを所定の時間毎にネットワークを介して連続して送受信することにより、メディアデータのストリーミングを可能としている。また、HTTPを使用してコンテンツをストリーミングする方法が提案されている（特許文献１参照）。

特開２０１２−１３８０８３号公報

IETF draft HTTP Live Streaming draft-pantos-http-live-streaming-10 ISO/IEC 23009-1

ところが、前述した標準規格や特許文献１に記載の方法をライブストリーミングに利用する場合、再生開始までの待ち時間を短くしつつ再生が途切れないように、リアルタイム性と安定性を最適化するための具体的な方法は提案されていなかった。
本発明は前述の問題点に鑑み、プレイリストとセグメントを利用してライブストリーミングする場合に、再生開始までの待ち時間を短くしつつ再生が途切れないように、リアルタイム性と安定性を最適化することを可能とすることを目標とする。

本発明の受信装置は、メディアデータの異なる複数の時間区間に対応する複数の部分データを特定するプレイリストを取得する取得手段と、前記取得手段により取得されるプレイリストから特定される複数の部分データのうち、最も後の時間区間に対応する部分データを含む１以上の部分データであって合計の時間長が送信装置と前記受信装置との間の通信の種別及び通信状況の少なくとも何れかに応じた所定の時間長以上である１以上の部分データを、前記送信装置に要求する対象の部分データとして決定する決定手段と、前記決定手段による決定に応じた部分データを前記送信装置に要求する要求手段とを有することを特徴とする。

本発明によれば、プレイリストとセグメントを利用してライブストリーミングする場合に、再生開始までの待ち時間を短くしつつ再生が途切れないように、リアルタイム性と安定性を最適化することができる。

第１の実施形態に係る送信装置と、受信装置の接続形態を示す図である。 第１の実施形態に係る受信装置の内部構成例を示すブロック図である。 第１の実施形態に係る受信装置の再生区間制御処理手順の一例を示すフローチャートである。 第１の実施形態に係る受信装置のＲＯＭに設定される最大遅延時間選択テーブルの構成を示す図である。 Ｍ３Ｕ８形式のシンプルなプレイリストの一例である。 第１の実施形態に係る送信装置と受信装置の、送受信データの関係を時間経過と共に示す図である。

以下、添付の図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。

＜第１の実施形態＞
図１は、本発明の実施形態に係る送信装置１００と、受信装置１０２の接続形態を示す図である。送信装置１００と受信装置１０２は、ネットワーク１０１を介して相互に接続されている。

送信装置１００と受信装置１０２は、メディアデータの再生区間情報と所定の単位時間に分割されたメディアデータとをネットワーク１０１を介して夫々連続して送受信することによりメディアデータのストリーミングを行う。以下、メディアデータの再生区間情報をプレイリストと称し、所定の単位時間に分割されたメディアデータをセグメントデータと称す。また、メディアデータは、映像データまたは音声データの少なくとも一方を含む。

プレイリストは、各セグメントデータの再生順序、所在情報（ＵＲＩ）、再生時間等が記載されたデータである。本実施形態では、プレイリストのフォーマットとしてテキストベースのＭ３Ｕ８形式を用いる。Ｍ３Ｕ８形式のプレイリストの詳細は、図５を用いて後述する。

ネットワーク１０１は、例えばホームネットワークとしての有線ＬＡＮ（Local Area Network）や無線ＬＡＮ（Wireless LAN）である。なお、本実施形態ではホームネットワークとして有線ＬＡＮや無線ＬＡＮを想定しているが、これに限らず、ＷＡＮ（Wide Area Network）、アドホックネットワーク、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｚｉｇｂｅｅ（登録商標）、ＵＷＢなどでもよい。

送信装置１００は、受信装置１０２からネットワーク１０１を介して送信されるプレイリスト要求・セグメントデータ要求に応じて、プレイリスト・セグメントデータの送信を行う。送信装置１００の具体的な例としては、カメラ、ビデオカメラ、スマートフォン、携帯電話、ＰＣなどが挙げられるが、後述のハードウェア構成及びモジュール構成を満たすものであれば、これらに限定されない。また、メディアデータの生成は送信装置１００内で行われてもよいし、他のサーバー装置等で生成されて送信装置１００へ送信されてもよい。

一方、受信装置１０２は、送信装置１００からネットワーク１０１を介して送信されるプレイリスト・セグメントデータを受信し、メディアデータの再生や記録を行う。受信装置１０２の具体的な例としては、スマートフォン、携帯電話、ＰＣ、テレビ、プロジェクターなどが挙げられるが、後述のハードウェア構成及びモジュール構成を満たすものであれば、これらに限定されない。また、ネットワーク１０１に接続された受信装置１０２は一台のみであってもよいし、複数台存在してもよい。

図２は、本発明の実施形態に係る受信装置１０２の内部構成の一例を示すブロック図である。
図２において、２０１は中央処理装置（ＣＰＵ）であり、以下に述べる各部を統括的に制御する。２０２はＲＡＭであり、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。２０３はＲＯＭであり、ＣＰＵ２０１で実行される制御プログラム等を格納している。２０４はユーザの指示を受け取る操作部であり、ボタンやモードダイヤルなどが含まれる。

２０５は記録部であり、通信部２１２によって受信したメディアデータを外部メモリ制御部２１０を介して記録する。２０６は各種データの転送経路となるバスである。例えば、通信部２１２によって受信したデジタルデータはこのバス２０６を介して所定の処理部に送られる。

２０７は表示制御部であり、表示部２０８に表示される映像の表示制御を行う。表示部２０８は、例えば、液晶ディスプレイが用いられる。表示部２０８はタッチスクリーン機能を有していてもよく、その場合はタッチスクリーンを用いたユーザ指示を操作部２０４の入力として扱うことも可能である。

２０９はデコーダ部であり、受信したメディアデータをＭＰＥＧ−２ ＴＳ方式にて逆多重化し、復号する処理を行う。ＭＰＥＧ−２ ＴＳは、符号化された映像や音声等のメディアデータを多重化し、伝送するためのコンテナ形式であり、本実施形態のセグメントデータとして利用する。外部メモリ制御部２１０は、ＰＣやその他のメディア（例えば、ハードディスク、メモリーカード、ＣＦカード、ＳＤカード、ＵＳＢメモリ）に繋ぐためのインターフェースである。

２１１は通信制御部であり、送信装置１００から受信するメディアデータや制御情報の通信制御を行う。メディアデータの受信制御処理の詳細については図３で後述する。２１２は通信部であり、送信装置１００から送信されるプレイリストやセグメントデータの受信、送信装置１００に対する制御情報の送信を行う。本実施形態の通信部２１２は、通信プロトコルとしてＨＴＴＰを用いるものとする。２１３は再生区間制御部であり、送信装置１００から送信されたプレイリストからセグメントデータの時間長やＵＲＩなどを解析し、受信するセグメントデータを制御する。

続いて、本実施形態の受信装置１０２によるメディアデータ受信制御の詳細について、図３を用いて説明する。図３は、本発明の実施形態に係る受信装置１０２の再生区間制御処理手順の一例を示すフローチャートである。

まず、通信制御部２１１は、ネットワーク１０１の無線通信回線の種類、通信速度、往復応答時間、ジッタの少なくとも１つを計測することにより、最大の遅延時間Ｔ１を計測する（Ｓ３０１）。最大遅延時間Ｔ１は、送信装置１００と受信装置１０２との間で往復の通信に要する時間の最大値である。なお、最大遅延時間Ｔ１の計測タイミングは任意であり、一定の時間間隔で定期的に計測してもよいし、ストリーミング開始時に一度だけ計測してもよい。

ここで、Ｓ３０１における最大遅延時間Ｔ１の算出方法は、例えば図４に示した無線通信回線の種類（３Ｇ／ＬＴＥ／Ｗｉ−Ｆｉ）と最大遅延時間とを対応付けたテーブルに基づいて決定することが可能である。本テーブルは、図２に示したＲＯＭ２０３に記録されている。

図４に示すように、無線通信回線の種類に応じて予め遅延時間が設定されており、無線通信回線の種類から最大遅延時間を参照することができる。また、Ｓ３０１における最大遅延時間Ｔ１の算出方法は、前述した以外にも、送信装置１００と受信装置１０２間における通信の往復応答時間とゆらぎ（ジッタ）の最大値との和を最大遅延時間Ｔ１として算出する等の方法が考えられる。

続いて、通信制御部２１１は、送信装置１００に対してプレイリストの取得要求を送信する（Ｓ３０２）。ここでの要求は、ＨＴＴＰ ＧＥＴメソッドを使用し、プレイリスト要求のＵＲＩが予め送信装置１００から通知されているものとする。
通信部２１２は、Ｓ３０２の要求に従い送信装置１００から送信されたプレイリストを受信する（Ｓ３０３）。
再生区間制御部２１３は、Ｓ３０１で計測した最大遅延時間Ｔ１が、Ｓ３０３で受信したプレイリストに記載の全セグメントデータの時間長Ｔ２以下か否かを判断する（Ｓ３０４）。

ここで、Ｍ３Ｕ８形式のプレイリストの詳細を説明する。
図５は、Ｍ３Ｕ８形式のシンプルなプレイリストの一例である。プレイリストにはセグメントデータの再生時間長、所在情報（ＵＲＩ）が記載されている。４行目の”＃ＥＸＴＩＮＦ：”タグに続く値（＝５２１９．２）がセグメントデータの秒数を、続く５行目の”ｈｔｔｐ：／／”で始まる文字列がセグメントデータのＵＲＩを示している。

本例では、単一のセグメントデータに関する情報のみが記載されているが、プレイリストに複数のセグメントデータに関する情報が記載される場合もある。この場合には、各セグメントデータの時間長の和を計算することにより、全セグメントデータの時間長Ｔ２を求めることが可能である。図５中の＃ＥＸＴで始まるその他のタグについての説明は省略する。

なお、本実施形態において送信装置１００は、セグメントデータを所定の時間間隔毎に定期的に生成している。そのため、送信装置１００で生成されるプレイリストには、時間の経過に従って複数のセグメントデータに関する再生区間情報が記載されることになる。

最大遅延時間Ｔ１が全セグメントデータの時間長以下と判定した場合（Ｓ３０４のＹＥＳ）、再生区間制御部２１３は再生開始までの待ち時間を短くしつつ再生が途切れないようにする最適なセグメントデータを取得するために、Ｓ３０５以降の処理を行う。

まず、再生区間制御部２１３は、セグメントデータ数ｎを１で初期化し（Ｓ３０５）、Ｓ３０１で計測した最大遅延時間Ｔ１が、Ｓ３０３で受信したプレイリストに記載の最新のセグメントデータｎ個の時間長Ｔ３以下か否かを判断する（Ｓ３０６）。セグメントデータは、生成順にプレイリストに記載されるため、プレイリストの最後に記載されたセグメントデータが最も新しいセグメントデータである。

Ｓ３０６で最大遅延時間Ｔ１が最新のセグメントデータｎ個の時間長Ｔ３よりも大きいと判定した場合（Ｓ３０６のＮＯ）、セグメントデータ数ｎを１つ増やし（Ｓ３０７）、再度Ｓ３０６の判断を行う。Ｓ３０６〜Ｓ３０７を繰り返すことにより、最終的にはセグメントデータの時間長の和が最大遅延時間Ｔ１以上となるセグメントデータ数ｎを算出することができる（Ｓ３０６のＹＥＳ）。

続いて、再生区間制御部２１３は、最新のセグメントデータｎ個のうち、未受信の最も古いセグメントデータの取得要求を送信装置１００へ送信する（Ｓ３０８）。なお、Ｓ３０８でのセグメントデータの取得要求も、Ｓ３０２のプレイリスト要求と同様にＨＴＴＰ ＧＥＴメソッドを使用し、Ｓ３０３で受信したプレイリストに記載されたセグメントデータのＵＲＩ情報を参照してリクエストを送信する。

通信部２１２は、Ｓ３０８の要求に従い送信装置１００から送信されたセグメントデータを受信し（Ｓ３０９）、デコーダ部２０９及び表示部２０８においてセグメントデータを復号・再生する（Ｓ３１０）。前述したように、セグメントデータは所定の単位時間に分割されたメディアデータである。

再生区間制御部２１３は、Ｓ３０８で取得要求を送信したセグメントデータがプレイリスト中の最新の（再生順序が最後の）セグメントデータか否かを判断する（Ｓ３１１）。
Ｓ３１１において、セグメントデータが最新のセグメントデータでないと判断された場合には（Ｓ３１１のＮＯ）、未受信のセグメントデータを受信するべくＳ３０８へと処理を戻す。

Ｓ３０５〜Ｓ３１１の処理により、再生区間情報に対応する複数のメディアデータのうち、再生順序が最後のメディアデータからの再生区間長の和が、前述した最大遅延時間を超える範囲で最も少数のメディアデータの取得要求を行うことができる。これにより、本発明の実施形態に係る受信装置１０２は、再生開始までの待ち時間を短くしつつ再生が途切れないようにする最適なセグメントデータを再生することが可能になる。

Ｓ３１１において、セグメントデータが最新のセグメントデータであると判定された場合（Ｓ３１１のＹＥＳ）、再生区間制御部２１３はストリーミングを終了するか否かを判断する（Ｓ３１２）。ここでの判断は、ユーザのストリーミング終了指示を操作部２０４が受信したかを判断することにより可能である。

Ｓ３１２でストリーミングを終了しないと判断した場合には、Ｓ３０２へと処理を戻し、後続のメディアデータ受信処理を継続する。なお、処理を継続する場合には、セグメントデータの時間長から送信装置１００における次のプレイリスト生成タイミングを推測してプレイリスト要求を送信することにより、無駄なプレイリスト要求や応答を削減することが可能である。

Ｓ３０４へと説明を戻し、最大遅延時間Ｔ１が全セグメントデータの時間長よりも大きいと判断された場合には（Ｓ３０４のＮＯ）、再生区間制御部２１３はプレイリストに記載の全てのセグメントデータの取得要求を送信する（Ｓ３１３）。
続いて、通信部２１２は、Ｓ３１３の要求に従い送信装置１００から送信されたセグメントデータを受信する（Ｓ３１４）。また、ＲＡＭ２０２はＳ３１４で受信したセグメントデータをバッファリングする（Ｓ３１５）。

最後に、再生区間制御部２１３は、最大遅延時間Ｔ１から全セグメントデータの時間長Ｔ２を引いた時間を新たにＴ１として設定し（Ｓ３１６）、Ｓ３０２へと処理を戻す。
Ｓ３１３〜Ｓ３１６の処理により、最大遅延時間Ｔ１に満たないセグメントデータをバッファリングし、後続のセグメントデータを受信してバッファが満たされるまで復号・再生を行わないため、再生の途切れを防止することが可能になる。

次に、本実施形態の送信装置１００と受信装置１０２の送受信データの関係について、図６を用いて説明する。図６は、本発明の実施形態に係る送信装置１００と受信装置１０２の送受信データの関係を時間経過と共に示す図である。

６０１、６０２は各々、送信装置１００においてセグメントデータ５及びセグメントデータ６が生成されることを示している。本実施形態では、セグメントデータの生成タイミングは所定の間隔（１秒）で一定であるものとする。なお、６０１以前及び６０２以降にもセグメントデータは生成されているが、図６ではこれらのセグメントデータの生成タイミングは図示しない。セグメントデータ生成の開始と停止は、ユーザが任意に制御することが可能である。

６０３で示すように、受信装置１０２はストリーミング受信開始時に、ネットワーク１０１の通信回線の種類がＷｉ−Ｆｉであることを検出する。したがって、図４に示した通信回線の種類と最大遅延時間とを対応付けたテーブルから、受信装置１０２がストリーミングに要する最大の遅延時間は３秒であると決定することができる。

続いて、受信装置１０２は、プレイリストとセグメントデータとをネットワーク１０１を介して連続して受信することによりメディアデータのストリーミングを行う。
６０４は、受信装置１０２が最初に送受信するプレイリストの要求と応答である。６１０は、６０４のプレイリスト応答により受信したプレイリストであり、セグメントデータ１からセグメントデータ５に関する再生区間情報が記載されている。

プレイリスト６１０中、”ＥＸＴＩＮＦ：１，”は全てのセグメントデータの再生時間長が１秒であることを示しており、”ｈｔｔｐ：／／”で始まる行が各セグメントデータのＵＲＩを示している。

受信装置１０２は、プレイリスト６１０の内容と計測した最大の遅延時間（３秒）とに従って、最新のセグメントデータ５から３秒分のセグメントデータ（＝セグメントデータ３〜セグメントデータ５）を送信装置１００へ順次要求する。そして、受信・再生する（６０５〜６０７）。最大遅延時間の３秒を超えるセグメントデータ１とセグメントデータ２の送受信や復号、再生を行わないため、通信帯域の節約や処理負荷軽減、再生映像のリアルタイム性確保が可能になる。

受信装置１０２は、セグメントデータ３〜セグメントデータ５の受信を終えると、ストリーミングを継続するために再度プレイリストの要求と応答を送受信する（６０８）。６１１は、６０８のプレイリスト応答により受信したプレイリストであり、送信装置１００で新たに生成されたセグメントデータ６（６０２）に関する再生区間情報（１１行目、１２行目）が追記されている。

受信装置１０２は、プレイリスト６１１に記載されたセグメントデータのうち未受信のセグメントデータ６を送信装置１００へ要求、受信し（６０９）、セグメントデータ５に続いて再生することで、途切れること無くスムーズな再生が可能となる。
以上のように、本実施形態の通信装置の再生区間制御処理の結果、ネットワークの種類や通信状況に応じた最大遅延時間に従って最適なメディアデータを受信する。これにより、受信装置１０２の再生開始までの待ち時間を短くしつつ再生が途切れないように、リアルタイム性と安定性を最適化することが可能になる。

前述の実施形態では、映像の符号化・復号化方式としてＭＰＥＧ−２を用いたが、ＭＰＥＧ−２に限らずＭＰＥＧ−４ ＡＶＣ／Ｈ．２６４やＶＣ−１など他の映像符号化・復号化方式を用いることが可能である。また、前述の実施形態では、符号化された映像のコンテナ形式としてＭＰＥＧ−２ＴＳを用いたが、ＭＰＥＧ−２ＴＳに限らずＭＰ４形式やＭＯＶ形式などストリーミングに適した他のコンテナ形式を用いることも可能である。

また、前述の実施形態では、プレイリストのフォーマットとしてＭ３Ｕ８形式を用いたが、Ｍ３Ｕ８形式に限らずＭ３Ｕ形式やＷＰＬ形式など他のプレイリストフォーマットを用いることも可能である。

また、前述の実施形態では、データ転送プロトコルとしてＨＴＴＰを用いたが、ＨＴＴＰに限らずＨＴＴＰＳやＴＣＰ、ＵＤＰなどＯＳＩ参照モデルの同一レイヤーの他のプロトコルまたは別レイヤーの他のプロトコルを用いる事が可能である。

（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。即ち、前述した実施形態の機能を実現するソフトウェア（コンピュータプログラム）を、ネットワーク又は各種のコンピュータ読み取り可能な記憶媒体を介してシステム或いは装置に供給する。そして、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

２１１ 通信制御部
２１２ 通信部
２１３ 再生区間制御部

Claims (20)

1. 受信装置であって、
   メディアデータの異なる複数の時間区間に対応する複数の部分データを特定するプレイリストを取得する取得手段と、
   前記取得手段により取得されるプレイリストから特定される複数の部分データのうち、最も後の時間区間に対応する部分データを含む１以上の部分データであって合計の時間長が送信装置と前記受信装置との間の通信の種別及び通信状況の少なくとも何れかに応じた所定の時間長以上である１以上の部分データを、前記送信装置に要求する対象の部分データとして決定する決定手段と、
   前記決定手段による決定に応じた部分データを前記送信装置に要求する要求手段とを有することを特徴とする受信装置。
2. 前記所定の時間長は、前記送信装置と前記受信装置との間での通信に要する時間に応じた時間長であることを特徴とする請求項１に記載の受信装置。
3. 前記決定手段は、前記最も後の時間区間に対応する部分データを含み且つ合計の時間長が前記所定の時間長以上となる最小数の連続する部分データを、前記要求する対象の部分データとして決定することを特徴とする請求項１又は２に記載の受信装置。
4. 前記要求手段は、前記決定手段により決定された前記要求する対象の部分データのうち未受信の部分データを、前記送信装置に要求することを特徴とする請求項１乃至３の何れか１項に記載の受信装置。
5. 前記要求手段は、前記決定手段により決定された前記要求する対象の部分データが複数である場合に、より前の時間区間に対応する部分データから順に要求することを特徴とする請求項１乃至４の何れか１項に記載の受信装置。
6. 前記取得手段は、前記決定手段により決定された前記要求する対象の部分データに含まれる前記最も後の時間区間に対応する部分データが前記要求手段により要求された後に、前記メディアデータに関する新たなプレイリストを取得することを特徴とする請求項１乃至５の何れか１項に記載の受信装置。
7. 前記取得手段は、前記送信装置により前記新たなプレイリストが生成されるタイミングを前記部分データの時間長に基づいて推測した結果に応じて、前記新たなプレイリストを前記送信装置に要求して取得することを特徴とする請求項６に記載の受信装置。
8. 前記取得手段による取得対象となるプレイリストには、前記メディアデータの新たな時間区間に対応する部分データを特定する情報が時間の経過に伴って追加されることを特徴とする請求項１乃至７の何れか１項に記載の受信装置。
9. 前記取得手段は、前記プレイリストを前記送信装置から取得することを特徴とする請求項１乃至８の何れか１項に記載の受信装置。
10. 前記送信装置と前記受信装置との間の通信状況は、前記送信装置と前記受信装置との間の通信における通信速度、通信に要する時間、及び当該時間に関するジッタの少なくとも何れかを含むことを特徴とする請求項１乃至９の何れか１項に記載の受信装置。
11. 前記送信装置と前記受信装置との間の通信種別には、３Ｇ、ＬＴＥ、及びＷｉ−Ｆｉの少なくとも何れかが含まれることを特徴とする請求項１乃至１０の何れか１項に記載の受信装置。
12. 前記要求手段による要求に応じて前記送信装置から送信される部分データを受信する受信手段と、
    前記受信手段により受信された部分データに対応する時間区間の合計の時間長が前記所定の時間長以上である場合に、前記受信手段により受信された部分データを再生する再生手段とを有することを特徴とする請求項１乃至１１の何れか１項に記載の受信装置。
13. 前記決定手段は、前記取得手段により取得されたプレイリストから特定される部分データに対応する時間区間の合計の時間長が前記所定の時間長未満である場合に、前記特定される部分データを前記要求する対象の部分データとして決定し、
    前記取得手段は、前記合計の時間長が前記所定の時間長未満である場合に、前記再生手段による再生が行われる前に、前記メディアデータに関する新たなプレイリストを取得することを特徴とする請求項１２に記載の受信装置。
14. 前記取得手段により取得されるプレイリストから複数の部分データが特定される場合に、前記複数の部分データは互いに等しい時間長を有する時間区間に対応することを特徴とする請求項１乃至１３の何れか１項に記載の受信装置。
15. 前記取得手段により取得されるプレイリストは、部分データの再生順序、所在情報、及び再生時間を特定する情報を含むことを特徴とする請求項１乃至１４の何れか１項に記載の受信装置。
16. 前記メディアデータは、映像データまたは音声データの少なくとも一方を含むことを特徴とする請求項１乃至１５の何れか１項に記載の受信装置。
17. 受信装置の制御方法であって、
    メディアデータの異なる複数の時間区間に対応する複数の部分データを特定するプレイリストを取得する取得工程と、
    前記取得工程において取得されるプレイリストから特定される複数の部分データのうち、最も後の時間区間に対応する部分データを含む１以上の部分データであって合計の時間長が送信装置と前記受信装置との間の通信の種別及び通信状況の少なくとも何れかに応じた所定の時間長以上である１以上の部分データを、前記送信装置に要求する対象の部分データとして決定する決定工程と、
    前記決定工程における決定に応じた部分データを前記送信装置に要求する要求工程とを有することを特徴とする制御方法。
18. 前記所定の時間長は、前記送信装置と前記受信装置との間での通信に要する時間に応じた時間長であることを特徴とする請求項１７に記載の制御方法。
19. 前記決定工程においては、前記最も後の時間区間に対応する部分データを含み且つ合計の時間長が前記所定の時間長以上となる最小数の連続する部分データが、前記要求する対象の部分データとして決定されることを特徴とする請求項１７又は１８に記載の制御方法。
20. コンピュータを請求項１乃至１６の何れか１項に記載の受信装置の各手段として機能させるためのプログラム。

Images