(57)【要約】  再生装置（１００）は、ＤＡＳＨを用いて配信サーバ（３００）から１つ目のメディアセグメント（ＭＳ）を取得し、以降のＭＳをマルチキャスト通信により取得する通信制御部（１１０）と、受信したＭＳを再生する再生部（１２０）と、を備えている。制御部（１１０）は、ＤＡＳＨを用いた１つ目のＭＳの取得と、マルチキャスト通信による以降のＭＳの取得と、を同時に開始する。再生部（１２０）は、ＤＡＳＨを用いて最初に取得した１つ目のＭＳを、マルチキャスト通信により以降に取得したＭＳよりも先に再生する。
2012096372.tif 000002
【特許請求の範囲】
【請求項１】
再生指示をユーザから受け付けると、再生すべきコンテンツデータが時分割された複数の時分割データを配信サーバから取得しながら順次再生するコンテンツ再生装置において、
上記複数の時分割データのうち、上記配信サーバがすでにマルチキャスト配信した一部の時分割データをユニキャスト通信により上記配信サーバから取得する第１取得手段と、
上記複数の時分割データのうち、上記一部の時分割データに続けて再生すべき残りの時分割データを上記配信サーバからマルチキャスト配信を受けて取得する第２取得手段と、
上記第１取得手段が最初に取得した時分割データを、上記複数の時分割データの中で最初に再生する再生手段と、を備えていることを特徴とするコンテンツ再生装置。
【請求項２】
請求項１に記載のコンテンツ再生装置であって、
上記時分割データは相異なる複数の品質の再生対象データから構成されており、
上記再生手段は、上記複数の時分割データの各々について、該時分割データを構成するいずれかの品質の再生対象データを配信サーバから取得しながら順次再生するように構成されていることを特徴とするコンテンツ再生装置。
【請求項３】
請求項１または２に記載のコンテンツ再生装置であって、
上記第１取得手段は、上記第２取得手段が上記残りの時分割データを取得する処理を開始する時点以前に、上記一部の時分割データを取得する処理を開始するように構成されていることを特徴とするコンテンツ再生装置。
【請求項４】
請求項３に記載のコンテンツ再生装置であって、
上記コンテンツデータに関するメタデータであって、上記複数の時分割データの各々について上記配信サーバが該時分割データをマルチキャスト配信する配信時刻を該コンテンツ再生装置が特定可能なメタデータを、該コンテンツデータの取得に先駆けて取得する第３取得手段と、
タイマーが指し示す時刻を監視する時刻監視手段と、をさらに備え、
上記第１取得手段は、上記メタデータから特定した各時分割データの配信時刻に基づいて、上記再生指示を受け付けたときに上記タイマーが指し示す時刻の直近でマルチキャスト配信された上記一部の時分割データを取得するように構成されており、
上記第２取得手段は、上記メタデータから特定した上記配信時刻に基づいて、上記第１取得手段が上記一部の時分割データを取得する処理を開始してから最初に時分割データが配信される配信時刻を上記タイマーが指し示したときに、上記残りの時分割データを取得する処理を開始することを特徴とするコンテンツ再生装置。
【請求項５】
請求項４に記載のコンテンツ再生装置であって、
上記残りの再生対象データに加えて、上記第１取得手段により取得される上記一部の時分割データを構成する１以上の時分割データの少なくともいずれかを上記第２取得手段が重複取得するか否かを判定する重複取得判定手段をさらに備え、
上記複数の時分割データの各々について、上記時分割データには該時分割データを識別するための識別値が関連づけられているとともに、上記メタデータには、該時分割データを識別するための識別値が含まれており、
上記重複取得判定手段は、上記配信時刻を上記タイマーが指し示した後に上記第２取得手段が取得する最初の時分割データに関連づけられている識別値が、上記配信時刻に配信されると上記メタデータから特定可能な時分割データの識別値よりも小さい場合に限り、上記第２取得手段が重複取得すると判定するように構成されており、
上記重複取得判定手段が上記１以上の時分割データの少なくともいずれかが上記第２取得手段により取得されると判定した場合に、上記再生手段は、上記第１取得手段および上記第２取得手段の双方により取得された同一の時分割データの一方を再生しないことを特徴とするコンテンツ再生装置。
【請求項６】
請求項４に記載のコンテンツ再生装置であって、
上記コンテンツデータに関するメタデータであって、上記複数の時分割データの各々について上記配信サーバが該時分割データをマルチキャスト配信する配信時刻を該コンテンツ再生装置が特定可能なメタデータを、該コンテンツデータの取得に先駆けて取得する第３取得手段と、
タイマーが指し示す時刻を参照する時刻参照手段と、
上記メタデータから特定される配信時刻が上記再生指示を受け付けた時点において上記タイマーが指し示す時刻以降となるような時分割データのうち、すでにマルチキャスト配信された時分割データが存在するか否かを判定する判定手段と、をさらに備え、
上記複数の時分割データの各々について、上記時分割データには該時分割データを識別するための識別値が関連づけられているとともに、上記メタデータには、該時分割データを識別するための識別値が含まれており、
上記判定手段は、上記配信時刻を上記タイマーが指し示した後に上記第２取得手段が取得する最初の時分割データに関連づけられている識別値が、上記配信時刻に配信されると上記メタデータから特定可能な時分割データの識別値よりも大きい場合に限り、すでにマルチキャスト配信された時分割データが存在すると判定するように構成されており、
上記第１取得手段は、上記メタデータから特定される配信時刻が上記タイマーの指し示す時刻以前である時分割データだけでなく、上記特定される配信時刻が上記タイマーの指し示す時刻以降である時分割データであってすでにマルチキャスト配信された時分割データを、ユニキャスト通信により取得することを特徴とするコンテンツ再生装置。
【請求項７】
請求項１に記載のコンテンツ再生装置であって、
上記配信サーバは、上記複数の時分割データの各々について、該時分割データを分割することにより得られる複数の部分データが個別に格納された複数のＲＴＰパケットであって各ＲＴＰパケットに該時分割データを識別するための識別子が格納された複数のＲＴＰパケットをマルチキャスト配信するように構成されており、
上記第２取得手段は、上記再生指示を受け付けた時点以降にマルチキャスト配信される複数のＲＴＰパケットを上記配信サーバから取得するように構成されており、
上記第１取得手段は、上記第２取得手段が最初に取得したＲＴＰパケットに含まれる識別子から識別される時分割データをユニキャスト通信により上記配信サーバから取得するように構成されており、
上記再生手段は、上記第１取得手段が取得した時分割データを再生してから、上記第２取得手段が取得した複数のＲＴＰパケットから複数の時分割データを生成して再生することを特徴とするコンテンツ再生装置。
【請求項８】
請求項７に記載のコンテンツ再生装置であって、
上記第１取得手段は、上記第２取得手段が最初に取得したＲＴＰパケットに含まれる識別子から識別される時分割データを構成する全部分データのうち、上記第２取得手段が取得した上記複数のＲＴＰパケットのいずれにも格納されていない一部の部分データのみを取得するように構成されており、
上記再生手段は、上記一部の部分データを構成する１以上の部分データを順次再生してから、上記第２取得手段が取得した複数のＲＴＰパケットに格納されている各部分データを順次再生することを特徴とするコンテンツ再生装置。
【請求項９】
請求項１から８のいずれか１項に記載のコンテンツ再生装置と、該コンテンツ再生装置に対してコンテンツデータを配信可能に該コンテンツ再生装置と接続されている上記配信サーバと、を含んでいることを特徴とする配信システム。
【請求項１０】
再生指示をユーザから受け付けると、再生すべきコンテンツデータが時分割された複数の時分割データを配信サーバから取得しながら順次再生するコンテンツ再生装置のコンテンツ再生方法において、
上記複数の時分割データのうち、上記配信サーバがすでにマルチキャスト配信した一部の時分割データをユニキャスト通信により上記配信サーバから取得する第１取得工程と、
上記複数の時分割データのうち、上記一部の分割データに続けて再生すべき残りの時分割データを上記配信サーバからマルチキャスト配信を受けて取得する第２取得工程と、
上記第１取得工程にて最初に取得した分割データを、上記第１取得工程および上記第２取得工程を通じて取得した上記複数の時分割データの中で最初に再生する再生工程と、を含んでいることを特徴とするコンテンツ再生方法。
【請求項１１】
請求項１から８のいずれか１項に記載のコンテンツ再生装置としてコンピュータを動作させるプログラムであって、コンピュータを上記各手段として機能させるためのコンテンツ再生プログラム。
【請求項１２】
請求項１１に記載のコンテンツ再生プログラムが記録されているコンピュータ読み取り可能な記録媒体。
【請求項１３】
複数の時分割データに時分割して配信されるコンテンツデータであって配信サーバがユニキャスト通信およびマルチキャスト配信の両配信方式により配信可能なコンテンツデータに関するメタデータのデータ構造であって、
上記複数の時分割データの各々について上記配信サーバが該時分割データをマルチキャスト配信する配信時刻と、上記配信サーバから該時分割データをユニキャスト通信により取得するために参照すべきＵＲＬと、が特定可能に記載されていることを特徴とするデータ構造。
【請求項１４】
配信サーバが複数の時分割データに時分割して配信されるコンテンツデータを少なくとも１以上の配信用データを用いて配信する場合における該配信用データのデータ構造であって、
１以上の上記時分割データの各々について、該時分割データと該時分割データを識別するための識別子とが関連づけて記録されていることを特徴とする配信用データのデータ構造。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、配信サーバから取得したコンテンツデータを再生するコンテンツ再生装置およびコンテンツ再生方法に関する。また、本発明は、そのような配信サーバおよびコンテンツ再生装置を含む配信システムに関する。また、本発明は、そのようなコンテンツ再生装置としてコンピュータを動作させるコンテンツ再生プログラム、および、そのようなコンテンツ再生プログラムを記憶している記録媒体に関する。さらに、本発明は、コンテンツ再生装置がコンテンツデータを取得するために参照するデータのデータ構造に関する。
【背景技術】
【０００２】
近年、インターネットに対する需要が急速に高まるにしたがって、テキストや静止画等で構成されたＷＥＢページを見るだけでなく、動画コンテンツを鑑賞するユーザが増えてきている。【０００３】
このような状況を踏まえ、動画コンテンツを伝送するための様々な技術が開発されているが、そのうちのひとつに現在標準化作業が進められているＤＡＳＨ(Dynamic Adaptive Streaming over HTTP)が挙げられる。【０００４】
ＤＡＳＨではＭＰＤ（Media Presentation Description）とメディアセグメントとの２つのフォーマットが規定されている。メディアセグメントは、動画コンテンツが時分割された、ＨＴＴＰ伝送の伝送単位である。また、ＭＰＤは、メディアセグメントのＵＲＬやメディアセグメントの提示可能な品質態様（例えば、１Ｍｂｐｓ、２Ｍｂｐｓ、４Ｍｂｐｓの３種類の映像ビットレート）等の情報が期間ごとに規定されている、動画コンテンツに関するメタデータである。ＭＰＤは、動画コンテンツの配信開始前に配信サーバからクライアント装置に伝送される。【０００５】
ＤＡＳＨを用いたストリーミング配信にはデジタル放送やＩＰマルチキャスト放送等の一斉送信型の配信と異なり以下に示すような様々な利点がある。【０００６】
利点１：ＤＡＳＨに対応したクライアント装置は、ＭＰＤを参照してメディアセグメントの受信および再生を行うが、配信サーバとの間のネットワークにおける帯域負荷の状況に応じて適切なメディアセグメントを選択して再生することができる。すなわち、帯域負荷の状況に応じて適応的に動画コンテンツのストリーミング再生を行うことが可能である。【０００７】
利点２：ＤＡＳＨでは、映像ビットレートが相異なる複数の動画コンテンツを配信可能であるため、携帯端末、ＰＣ、テレビなどの処理能力の異なる様々なクライアント装置に対して一元的なストリーミングサービスを提供することが可能になる。【０００８】
利点３：ＤＡＳＨでは、デジタル放送やＩＰマルチキャスト放送等の一斉送信型の映像配信とは異なり、ライブ配信だけでなくオンデマンド配信を行うことも可能である。【０００９】
利点４：ＤＡＳＨでは、デジタル放送やＩＰマルチキャスト放送等の映像配信技術と比べ、クライアント装置がコンテンツデータの受信速度を制御できるため、ユーザが再生指示を出してから再生開始までの待ち時間を短縮できる。
【発明の概要】
【発明が解決しようとする課題】
【００１０】
しかしながら、ＤＡＳＨはユニキャスト通信を用いたストリーミング配信技術であり、配信サーバは各クライアント装置に対して個別にストリーミング配信を行う必要があるため、配信サーバ側のネットワークの帯域負荷および配信サーバの処理負荷がクライアント装置の台数に略比例して高まるという問題があった。【００１１】
本発明は、上記課題に鑑みてなされたものであり、その主な目的は、配信サーバ側のネットワークの帯域負荷および配信サーバの処理負荷を抑制しつつ、コンテンツデータの再生を短い待ち時間で開始することが可能なコンテンツ再生装置を実現することにある。
【課題を解決するための手段】
【００１２】
本発明に係るコンテンツ再生装置は、上記課題を解決するために、再生指示をユーザから受け付けると、再生すべきコンテンツデータが時分割された複数の時分割データを配信サーバから取得しながら順次再生するコンテンツ再生装置において、上記複数の時分割データのうち、上記配信サーバがすでにマルチキャスト配信した一部の時分割データをユニキャスト通信により上記配信サーバから取得する第１取得手段と、上記複数の時分割データのうち、上記一部の時分割データに続けて再生すべき残りの時分割データを上記配信サーバからマルチキャスト配信を受けて取得する第２取得手段と、上記第１取得手段が最初に取得した時分割データを、上記複数の時分割データの中で最初に再生する再生手段と、を備えていることを特徴としている。【００１３】
上記の構成によれば、本発明に係るコンテンツ再生装置は、マルチキャスト配信によって残りの時分割データを取得する処理を開始する時点以前に、または、該時点の直後に、ユニキャスト通信により一部の時分割データを取得する処理を開始することにより、残りの時分割データを構成する最初の時分割データのマルチキャスト配信による取得を完了するタイミングよりも早く、上記一部の時分割データを構成する最初の時分割データのユニキャスト通信による取得を完了し、最初に取得した時分割データを上記複数の時分割データの中で最初に再生する。【００１４】
これにより、本発明に係るコンテンツ再生装置は、マルチキャスト配信だけを受けてコンテンツデータを再生する従来のクライアント装置がコンテンツデータの再生を開始するタイミングよりも早く、コンテンツデータの再生を開始することができる。また、本発明に係るコンテンツ再生装置は、ユニキャスト通信により受信するのはコンテンツデータに含まれる一部の時分割データのみであるので、配信サーバ側のネットワークの帯域負荷および配信サーバの処理負荷を抑制することができる。【００１５】
以上のことから、本発明に係るコンテンツ再生装置は、配信サーバ側のネットワークの帯域負荷および配信サーバの処理負荷を抑制しつつ、映像コンテンツの再生を短い待ち時間で開始することできるという効果を奏する。【００１６】
本発明に係るコンテンツ再生方法は、上記課題を解決するために、再生指示をユーザから受け付けると、再生すべきコンテンツデータが時分割された複数の時分割データを配信サーバから取得しながら順次再生するコンテンツ再生装置のコンテンツ再生方法において、
上記複数の時分割データのうち、上記配信サーバがすでにマルチキャスト配信した一部の時分割データをユニキャスト通信により上記配信サーバから取得する第１取得工程と、
上記複数の時分割データのうち、上記一部の分割データに続けて再生すべき残りの時分割データを上記配信サーバからマルチキャスト配信を受けて取得する第２取得工程と、
上記第１取得工程にて最初に取得した分割データを、上記第１取得工程および上記第２取得工程を通じて取得した上記複数の時分割データの中で最初に再生する再生工程と、を含んでいることを特徴としている。【００１７】
上記の構成によれば、本発明に係るコンテンツ再生方法は、本発明に係るコンテンツ再生装置と同様の作用効果を奏する。
【発明の効果】
【００１８】
以上のように、本発明のコンテンツ再生装置は、配信サーバ側のネットワークの帯域負荷および配信サーバの処理負荷を抑制しつつ、コンテンツデータの再生を短い待ち時間で開始することができるという効果を奏する。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施形態に係る再生装置の構成を示した図である。
【図２】本発明の実施形態に係る配信システムの全体構成を示した図である。
【図３】図１の再生装置が参照するＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）データの一例を示した図である。
【図４】図１の再生装置が参照するＭＰＤデータの別の一例を示した図である。
【図５】図１の再生装置が映像の再生を開始するまでの動作の一実施形態を示すフローチャートである。
【図６】図２の配信システムにおいて配信サーバがメディアセグメントを配信するスケジュールと、従来のクライアントがメディアセグメントを受信および再生するスケジュールと、図１の再生装置が図５のフローチャートに従ってメディアセグメントを受信および再生するスケジュールと、の時間的関係を模式的に示した図である。
【図７】図１の再生装置が映像の再生を開始するまでの動作の別の一実施形態を示すフローチャートである。
【図８】配信サーバがメディアセグメントを配信するスケジュールと、図１の再生装置が図７のフローチャートに従ってメディアセグメントを受信および再生するスケジュールと、の時間的関係を模式的に示した図である。
【図９】本発明の別の実施形態に係る再生装置の構成を示した図である。
【図１０】本発明の別の実施形態に係る配信システムの全体構成を示した図である。
【図１１】図９の再生装置が映像の再生を開始するまでの動作の一実施形態を示すフローチャートである。
【図１２】図１０の配信システムにおいて配信サーバが配信するメディアセグメントのデータ構造を示す図である。（ａ）は、ＭＰＥＧ２―ＴＳ形式のデータ構造を示しており、（ｂ）は、ＭＰ４形式のデータ構造を示している。
【図１３】配信サーバと図９の再生装置との間の通信に大きな遅延が生じた場合における、配信サーバがメディアセグメントを配信するスケジュールと、再生装置が図５のフローチャートに従ってメディアセグメントを受信および再生するスケジュールと、の時間的関係を模式的に示した図である。
【図１４】配信サーバの内蔵時計と、図９の再生装置の内蔵時計との同期がとれていない場合における、配信サーバがメディアセグメントを配信するスケジュールと、再生装置が図５のフローチャートに従ってメディアセグメントを受信および再生するスケジュールと、の時間的関係を模式的に示した図である。
【図１５】配信サーバがメディアセグメントを配信するために生成するＲＴＰパケットの一具体例を模式的に示した図である。
【図１６】本発明のさらに別の実施形態に係る再生装置の構成を示した図である。
【図１７】本発明のさらに別の実施形態に係る配信システムの全体構成を示した図である。
【図１８】配信サーバがメディアセグメントを配信するために生成するＲＴＰパケットの別の一具体例を模式的に示した図である。
【図１９】図１６の再生装置が映像の再生を開始するまでの動作の一実施形態を示すフローチャートである。
【図２０】配信サーバがメディアセグメントを配信するために生成するＲＴＰパケットのさらに別の一具体例を模式的に示した図である。
【図２１】図１６の再生装置が映像の再生を開始するまでの動作の別の一実施形態を示すフローチャートである。
【発明を実施するための形態】
【００２０】
〔実施形態１〕
本発明の一実施形態に係る配信システムは、映像コンテンツを再生装置にライブ配信およびオンデマンド配信するための配信システムである。
【００２１】
本実施形態に係る配信システムについて図１〜図８を参照しながら説明する。
【００２２】
図１は、本実施形態に係る再生装置の全体構成を示した図であり、図２は、本実施形態に係る配信システム１の全体構成を示した図である。
【００２３】
図２に示すように、配信システム１は、再生装置１００とマルチキャストルータ２００と配信サーバ３００とネットワークストレージサーバ（ＮＡＳ）４００とを含むシステムである。また、再生装置１００および配信サーバ３００は、インターネットＮＷに接続しており、配信サーバ３００が属するローカルエリアネットワークとインターネットＮＷとの境界に、マルチキャストルータ２００が設置されている。
【００２４】
以下、再生装置１００、マルチキャストルータ２００、配信サーバ３００、およびＮＡＳ４００について説明する。
（再生装置１００）
再生装置１００は、操作部（図示せず）を介して映像コンテンツの再生指示をユーザから受け付けると、そのリアルタイム再生すべき映像コンテンツを、配信サーバ３００からメディアセグメント（映像コンテンツの符号化データを一定時間（本実施形態では１０秒）ごとに分割して得られる各単位、以下、「ＭＳ」とも称する）単位で受信して再生する。図１に示すように、再生装置１００は、通信制御部１１０、再生部１２０、記憶部１３０、ネットワークＩ／Ｆ１４０、表示部１５０、および内蔵時計部１６０を備えている。再生装置１００の具体例としてはスマートフォン、スマートＴＶ等が挙げられる。
（通信制御部１１０）
通信制御部１１０は、予め映像コンテンツに関する後述のＭＰＤデータ（メタデータ）を配信サーバ３００から受信して記憶部１３０に記録する。
【００２５】
通信制御部１１０は、映像コンテンツ（以下では、再生指示を受け付けた映像コンテンツを「対象映像コンテンツ」とも称する）の再生指示をユーザから受け付けると、対象映像コンテンツに関するＭＰＤデータを参照することにより、対象映像コンテンツを構成する各メディアセグメント（時分割データ）を配信サーバ３００が配信する配信時刻を特定する。そして、通信制御部１１０は、現在時刻と、各メディアセグメントについて特定した配信時刻と、から、受信すべきメディアセグメントのＵＲＬを特定し、特定した各メディアセグメントのＵＲＬがユニキャスト通信(HTTP)によるものであれば、ＨＴＴＰ要求を配信サーバ３００に送信する。
【００２６】
さらに、通信制御部１１０は、特定した各メディアセグメントのURLがマルチキャスト配信（RTP）によるものであれば、対象映像コンテンツのマルチキャスト配信の要求を、マルチキャストルータ２００に送信する。
【００２７】
通信制御部１１０は、受信したメディアセグメントを記憶部１３０に記憶する。
（再生部１２０）
再生部１２０は、再生すべき時刻の早い順に、記憶部１３０にバッファリングされているメディアセグメントを読み出してデコードおよび再生を行うことにより、対象映像コンテンツを表示部１５０に表示する。
（記憶部１３０）
記憶部１３０は、対象映像コンテンツを構成する各メディアセグメントや対象映像コンテンツに関するＭＰＤデータ等の各種データを記憶する記録媒体である。
（ネットワークＩ／Ｆ１４０）
ネットワークＩ／Ｆ１４０は、サーバ３００およびマルチキャストルータ２００との間でデータの送受信を行う。
（表示部１５０）
表示部１５０は、対象映像コンテンツを表示するディスプレイである。
（内蔵時計部１６０）
内蔵時計部１６０は、再生装置１００に組み込まれているＲＴＣ（リアルタイムクロック）である。
（マルチキャストルータ２００）
マルチキャストルータ２００は、対象映像コンテンツのマルチキャスト配信の要求を再生装置１００から受信すると、対象映像コンテンツのマルチキャスト配信に使用されるマルチキャストグループに再生装置１００を登録する、再生装置１００のファーストホップルータである。
【００２８】
マルチキャストルータ２００は、登録後に対象映像コンテンツを構成するメディアセグメントを配信サーバ３００から受信すると、そのメディアセグメントを再生装置１００が属するサブネットに転送する。
（配信サーバ３００）
配信サーバ３００は、再生装置１００からＭＰＤデータの要求を受けると、ＮＡＳ４００に記録されているＭＰＤデータを再生装置１００に送信する。
【００２９】
配信サーバ３００は、映像コンテンツを構成するライブカメラ（図示せず）からの映像をメディアセグメント単位で順次、ＮＡＳ４００に記録しつつ対象映像コンテンツをマルチキャスト配信する。また、配信サーバ３００は、再生装置１００からメディアセグメントのＨＴＴＰ要求を受けると、ＮＡＳ４００に記録された該メディアセグメントをＤＡＳＨにより再生装置１００に配信する。
（ＮＡＳ４００）
ＮＡＳ４００は、映像コンテンツを構成する各メディアセグメントおよび映像コンテンツに関するＭＰＤデータを保持するネットワークストレージである。
（ＭＰＤデータの詳細について）
次に、上述したＭＰＤデータの詳細について図３を参照しながら以下に説明する。図３は、ＮＡＳ４００が保持しており、再生装置１００が受信すべきメディアセグメントを特定するために参照するＭＰＤデータの一具体例を示した図である。
【００３０】
図３に示すように、ＭＰＤデータ５ａは、「ＭＰＤ」をルート要素とするマークアップ言語形式のデータである。ＭＰＤ開始タグの属性「minBufferTime」の値は、映像をスムーズに再生するために必要な最小の初期バッファリング時間を示しており、属性「type」の値は、後述する「Representation」タグの属性「type」のデフォルト値を示している。すなわち、属性「type」の値は、「Representation」タグにおいて属性「type」が指定されていないリプレセンテーションがオンデマンドストリーミング配信であるかライブストリーミング配信であるかを示している。また、属性「availabilityStartTime」の値としては、UTC（協定世界時）で示された映像コンテンツの配信開始時刻が記される。
【００３１】
「ＭＰＤ」のサブ要素である「Period」は、特定の期間（ピリオド）において再生すべき映像に関する情報が、対応するPeriod開始タグおよび終了タグで囲まれた範囲に記載されていることを示している。属性「start」には当該ピリオドの開始時刻が、当該映像コンテンツ冒頭を基準とした相対時刻で記される。図３のＭＰＤデータ５ａの例では、<Period start=“PT0S”>と</Period>とで囲まれた範囲には、映像コンテンツ冒頭から１８００秒の時点までに再生すべき映像に関する情報が記載される。
【００３２】
「Period」のサブ要素である「RepresentationGroup」は、RepresentationGroup開始タグおよび終了タグで囲まれた範囲に記載されている１以上のサブ要素「Representation」が同一のリプレゼンテーショングループに属していることを示している。すなわち、選択されたいずれか１つのリプレゼンテーションのメディアセグメント（再生対象データ）だけが該当する期間において再生されることを示している。なお、同一リプレゼンテーショングループに属するリプレゼンテーションは、画像サイズ、フレームレート、ビットレート等の再生品質に違いがあるものの、再生される内容は同じである。図３のＭＰＤデータ５ａの例では、<Period start=“PT0S”>と</Period>とで囲まれた範囲には、サブ要素「Representation」が３つ記載されている、すなわち、2011年11月15日12:00を配信開始時刻とする期間において、３つのリプレゼンテーションのうちいずれかのリプレゼンテーションのメディアセグメントを配信サーバから受信し、再生装置１００にて再生可能であることを示している。
【００３３】
また、RepresentationGroup開始タグと終了タグとで囲まれた範囲には、サブ要素「SegmentInfoDefault」が記載されている。SegmentInfoDefault開始タグの属性「duration」の値は、上記期間中に順次再生される各メディアセグメントの再生開始から再生完了までに要する時間を示す。ＭＰＤデータ５ａの例では１０秒である。また、属性「startIndex」の値は、各リプレゼンテーションに属する各メディアセグメントを識別するためのインデックス（識別値）の初期値を示す。ＭＰＤデータ５ａの例では、各リプレゼンテーションに属する先頭のメディアセグメントのインデックスを１とし、後続のメディアセグメントに対し順次、２、３、４・・・とインデックスが付されること示している。なお、同一リプレゼンテーショングループに属する同一のインデックスを付したメディアセグメントは画像サイズ、フレームレート、ビットレート等の再生品質に違いがあるものの、再生される内容は同じである。
【００３４】
Representation開始タグの属性「default」の値”true”は、同一のリプレゼンテーショングループに属しているリプレゼンテーションの中で、デフォルトで再生すべきリプレゼンテーションであることを示している。また、Representation開始タグの属性「mimeType」の値は、リプレゼンテーションを構成するメディアセグメントに使用されるコーデック種別等を示している。また、属性「bandwidth」の値はリプレゼンテーションを構成するメディアセグメントを順次受信し、ストリーミング再生するために必要なビットレートを示している。さらに、Representation開始タグの属性「type」の値はリプレセンテーションがオンデマンドストリーミング配信であるかライブストリーミング配信であるかを示している。属性「timeShiftBufferDepth」は、ライブストリーミング配信のみで有効な属性であり、配信サーバが各メディアセグメントについてメディアセグメントの配信を開始してから破棄するまでの時間を示している。ＭＰＤデータ５ａの例では、id=“rep1”のリプレゼンテーションに値０が設定されており、当該リプレゼンテーションのメディアセグメントは配信直後に配信サーバから破棄されることを示している。言い換えれば、当該リプレゼンテーションのメディアセグメントは配信サーバから再配信されないことを示している。
【００３５】
さらに、属性「availabilityStartTime」の値と属性「availabilityEndTime」の値とは、UTCで示された当該リプレゼンテーションの配信開始時刻および配信終了時刻が記される。
【００３６】
Representation開始タグと終了タグとで囲まれた範囲には、当該リプレゼンテーションを構成するメディアセグメントに関する情報を記したサブ要素「SegmentInfo」が記載されている。SegmentInfo開始タグと終了タグとで囲まれた範囲には、各メディアセグメントのURLに関する情報を記すためのサブ要素「Url」が含まれる。サブ要素「SegmentInfo」には、当該リプレゼンテーションを構成するメディアセグメント数に相当するサブ要素「Url」が含まれる。前述の通り、同一「SegmentInfo」に属するUrlタグは上から順にインデックスstartIndex,startIndex+1,startIndex+2,…にて識別される。Urlタグの属性「sourceURL」は、Urlタグが示すメディアセグメントを取得する際に必要なURLを示す。なお複数のUrlタグでURLの一部あるいは全てが一致する場合、共通部分をサブ要素「BaseURL」に記載してもよい。サブ要素「BaseURL」にメディアセグメントのURLの全てが記載される場合には、Urlタグの属性「sourceURL」の記載を省略することができる。具体的にはライブ配信の場合、同一リプレゼンテーションの各メディアセグメントは順次配信されるので、各メディアセグメントを配信時刻で識別することで、同一URLを用いることが可能である。ＭＰＤデータ５ａの例では、id=”rep1”がライブ配信用リプレゼンテーションであり、各メディアセグメントのURLとしてはサブ要素「BaseURL」に記載されたRTPによるマルチキャスト配信用の共通URL「rtp://239.255.42.42:1234/」が用いられ、各Urlタグの属性「sourceURL」の記載は省略される。その替わりに各Urlタグには、属性「availabilityTime」が記載され、当該メディアセグメントのUTC配信時刻が記される。
【００３７】
一方、オンデマンド配信用リプレゼンテーションでは、配信時刻によるメディアセグメントの識別はできないため、属性「sourceURL」により各メディアセグメントの識別が行われる。
【００３８】
以上の説明からわかるように、本実施形態では、映像コンテンツのライブストリーミング配信を受けるために参照されるリプレゼンテーションと、当該映像コンテンツのオンデマンドストリーミング配信を受けるために参照されるリプレゼンテーションが、１つのＭＰＤデータに記載される構成となっている。
【００３９】
また、ライブストリーミング配信を受けるために参照されるリプレゼンテーションには、RTPによるマルチキャスト配信を用い、オンデマンドストリーミング配信を受けるために参照されるリプレゼンテーションには、HTTPによるユニキャスト配信を用いる。
【００４０】
なお、ＭＰＤデータは、図３のＭＰＤデータ５ａのようにではなく、図４のＭＰＤデータ５ｂのように記載されていてもよい。図４のMPDデータ５ｂでは、SegmentInfoに含まれる複数のサブ要素「Url」の記述を簡潔に行うため、サブ要素「Url」の代わりにサブ要素「UrlTemplate」を用いている。サブ要素「UrlTemplate」は、属性「endIndex」の値以下のメディアセグメントのインデックスを持つサブ要素「Url」を代替する要素である。図４のMPDデータ５ｂの例では、１つのUrlTemplateでインデックス１〜１８０のUrlを代替している。
【００４１】
すなわち、Representationの属性「type」の値が”Live”である場合、Representationのサブ要素に「BaseURL」を含めず、SegmentInfoのサブ要素としてメディアセグメントの個数分のサブ要素「Url」の代わりにサブ要素「UrlTemplate」を１つ含めてもよい。この場合、UrlTemplateの属性「sourceURL」の値としてURLを記載し、属性「endindex」の値として該当する期間における最後のメディアセグメントのインデックスを記載する。
【００４２】
また、Representationの属性「type」の値が”OnDemand”である場合も同様に、SegmentInfoのサブ要素としてセグメントの個数分のサブ要素「Url」の代わりにサブ要素「UrlTemplate」を１つ含めてもよい。この場合、各メディアセグメントのＵＲＬを$indexというインデックス値の変数を用いて表現する。これにより、全メディアセグメントのＵＲＬを１つの「UrlTemplate」タグで表現することができる。ただし、このような表現が可能となるように、URLの表現に一定の制約（例えば、図示されているように、ファイル名の一部にインデックス値を含めるような命名規則でTSファイルを生成すること）が必要となることは言うまでもない。
【００４３】
なお、ＭＰＤデータ５ｂにおいて、属性「availabilityEndTime」は記載しなくともよい。属性「duration」の値と属性「EndIndex」の値との積に、属性「availabilityEndTime」の値を加えることにより、対象となるリプレゼンテーションのメディアセグメントの配信を完了する時刻を計算できるからである。
（再生装置１００が映像コンテンツの再生を開始する動作の動作例１）
以下では、図５を参照しながら、映像コンテンツのストリーミング再生を開始するまでの再生装置１００の動作の一動作例について説明する。なお、以下の説明では、MPDデータ内に記載の全てのリプレゼンテーションが単一のリプレゼンテーショングループに属する場合について説明するが、複数のリプレゼンテーショングループが存在する場合、リプレゼンテーショングループ毎に同様の処理を行うことが可能なため、説明を省略する。
【００４４】
図５は、再生装置１００が映像コンテンツの再生を開始するまでの動作を示すフローチャートである。
【００４５】
図示しない操作部を介して再生装置１００がユーザから映像コンテンツの再生指示を受け付けると、図５に示すように、再生装置１００の通信制御部１１０は、予め配信サーバから受信していた対象映像コンテンツに関するMPDデータ５aを記億部１３０から読み出す（ステップＳ１）。なお、MPDデータを事前に取得せず、再生指示後に配信サーバから受信する構成でも構わない。
【００４６】
次に、通信制御部１１０は、属性「default」の値が”True”であるようなRepresentation開始タグを対象リプレゼンテーションとして選択して解析する（ステップＳ２）。具体的には、通信制御部１１０は、ＭＰＤ開始タグの属性「availabilityStartTime」の値と、各Period開始タグの属性「start」の値と、に基づいて、内蔵時計部１６０が指し示す現在時刻が属するピリオド（以下、「対象ピリオド」とも称する）を特定し、対応するPeriod開始タグと終了タグとに囲まれた範囲に記載されているRepresentation開始タグ（以下、「対象ピリオドのRepresentation開始タグ」とも称する）の中から属性「default」の値が”True”であるようなRepresentation開始タグを特定して解析する。以下では、直近で解析対象となったRepresentation開始タグを対象Representation開始タグとも称することにする。
【００４７】
通信制御部１１０は、直前のステップ（ステップＳ２またはステップＳ６）で解析した対象Representation開始タグの属性「type」の値が”Live”であるか否かを判定する（ステップＳ３）。
【００４８】
“Live”でないと判定された場合（ステップＳ３においてＮＯ）、通信制御部１１０は、対象リプレゼンテーションの先頭のメディアセグメントの受信を開始し（ステップＳ４）、ステップＳ１０に進む。
【００４９】
一方、“Live”であると判定された場合（ステップＳ３においてＹＥＳ）、通信制御部１１０は、対象リプレゼンテーションが現在ライブストリーミング配信されているか否かを判定する（ステップＳ５）。具体的には、通信制御部１１０は、内蔵時計部１６０が指し示す現在時刻の値が、対象Representation開始タグの属性「availabilityStartTime」の値以上であり、且つ、属性「availabilityEndTime」の値より小さいかどうかを判定する。なお、属性「availabilityStartTime」値との大小の判定は、内蔵時計の示す現在時刻をUTCに換算した値と属性「availabilityStartTime」値との大きさを比較することによって行われる。
【００５０】
ステップＳ５において、ライブストリーミング配信されていないと判定された場合（ステップＳ５においてＮＯ）、通信制御部１１０は、対象ピリオドのRepresentation開始タグの中で、対象Representation開始タグの次に位置するRepresentation開始タグを対象リプレゼンテーションとして選択して解析し（ステップＳ６）。ステップＳ３に戻る。
【００５１】
一方、ステップＳ５において、ライブストリーミング配信されていると判定された場合（ステップＳ５においてＹＥＳ）、通信制御部１１０は、現在ライブストリーミング配信中のメディアセグメントのインデックスＮを算出する（ステップＳ７）。具体的には、通信制御部１１０は、対象Representation開始タグと終了タグとに囲まれている各URLタグの属性「availabilityTime」の値を参照する。そして、通信制御部１１０は、内蔵時計部１６０が指し示す現在時刻の値が、上からＮ番目のURLタグの属性「availabilityTime」の値以上であり、且つ、上からＮ＋１番目のURLタグの属性「availabilityTime」の値未満であるようなＮ番目のＵＲＬタグを特定することにより、インデックスＮを算出する。
【００５２】
ステップＳ７の後、通信制御部１１０は、ユニキャスト用リプレゼンテーションを参照することにより、現在ライブストリーミング配信中の（直近で配信サーバ３００がマルチキャスト配信を開始した）インデックスＮのメディアセグメントに対応するオンデマンド配信中のメディアセグメントのＵＲＬ（図３の例では、例えば、http://exsample.com/rep2-segN.ts）を特定する。そして、通信制御部１１０は、特定したＵＲＬにアクセスすることにより、現在ライブストリーミング配信中のインデックスＮのメディアセグメントに対応するメディアセグメントをオンデマンド配信で受信する処理を開始する（ステップＳ８）。
【００５３】
ステップＳ８の後、内蔵時計部１６０が指し示す時刻がＮ＋１番目のURLタグの属性「availabilityTime」の値が示す時刻になった時点で、通信制御部１１０は、対象映像コンテンツのマルチキャスト配信を受けるためにマルチキャストグループへの参加要求をマルチキャストルータ２００に送信し（ステップＳ９）、ステップＳ１０に進む。これにより、再生装置１００は、インデックスＮ＋１のメディアセグメントの受信を開始し、後続するメディアセグメントをマルチキャスト配信にて順次受信することになる。
【００５４】
ステップＳ４またはステップＳ８にてメディアセグメントの受信を開始した時点から、属性「minBufferTime」の値が示す再生期間に相当する映像コンテンツ（メディアセグメント）を受信完了した時点で、再生部１２０は、ライブストリーミング映像の再生を開始する（ステップＳ１０）。なお、図３の例では、各メディアセグメントの再生期間（SegmentInfoDefault開始タグの属性「duration」の値）、属性「minBufferTime」の何れも１０秒が設定されているため、先頭メディアセグメント（インデックスＮのメディアセグメント）を１つ受信完了した時点で再生を開始することが可能である。
【００５５】
以上、再生装置１００がライブストリーミング映像の再生を開始するまでの動作について説明したが、再生装置１００が各メディアセグメントを受信および再生するタイミングが図６に示されている。
【００５６】
図６は、配信サーバ３００がメディアセグメントをマルチキャストにてライブ配信するスケジュールと、従来のクライアントがマルチキャストでライブ配信されるメディアセグメントを受信し、再生するスケジュールと、再生装置１００がメディアセグメントを受信および再生するスケジュールと、の時間的関係を模式的に示した図である。図中の各四角形は１つのメディアセグメントを示しており、四角形の内部の文字は、メディアセグメントのインデックスを示している。なお、上述の説明の場合と同様、先頭メディアセグメントを１つ受信した時点で再生開始可能な場合について説明する。
【００５７】
図６に示すように、従来のクライアント装置は、ユーザから再生指示を受け付けた時点で配信サーバにより配信中であるインデックスＮのメディアセグメントの受信を開始するが、実際に再生を開始するのは、インデックスＮ＋１のメディアセグメントの受信を完了した時点以降である。すなわち、従来のクライアント装置は、全体を受信できなかったインデックスＮのメディアセグメントを破棄し、全体を受信できたインデックスＮ＋１のメディアセグメントから再生を開始するので、再生指示を受け付けてから再生が開始するまでの所要時間（図中の再生開始遅延）はメディアセグメントを１つ再生するのに要する時間よりも大きくなる。
【００５８】
一方、再生装置１００は、ユーザから再生指示を受け付けた時点で、ユニキャスト通信を用いて、オンデマンド配信されるＮＡＳ４００に記録中のインデックスＮのメディアセグメントの受信を開始することができる。すなわち、再生装置１００は、インデックスＮのメディアセグメント全体を受信することが可能であるので、インデックスＮのメディアセグメントの受信が完了した時点で再生を開始することになる。また、オンデマンド配信されるメディアセグメントの受信速度は、再生装置１００にて制御可能であり、再生装置１００が利用可能なネットワーク帯域に応じた適切なビットレートのリプレゼンテーションを選択することで、ライブ配信の場合に比べ高速に受信が可能である。したがって、再生装置１００が再生指示を受け付けてから再生が開始するまでの所要時間は、ライブ配信されるメディアセグメントを１つ再生するのに要する時間未満となるので、従来のクライアント装置よりも短くなる。
【００５９】
また、従来のユニキャスト通信を用いた配信システムにおいては、映像コンテンツの配信開始直後に多数の再生装置からのアクセスが集中し、配信サーバの負荷が膨大となるが、本実施形態の配信システムにおいては、再生装置１００がユニキャスト通信により受信するメディアセグメントはインデックスＮのメディアセグメントのみであるので、同時に多数の再生装置１００が配信サーバ３００から対象映像コンテンツの配信を受ける場合であっても、配信サーバ３００側のネットワークの帯域や配信サーバ３００自体の処理にはそれほど負荷がかからないという利点がある。
（再生装置１００が映像コンテンツの再生を開始する動作の動作例２）
次に、映像コンテンツの再生を開始するまでの再生装置１００の動作の別の動作例について説明する。
【００６０】
本動作例では、対象映像コンテンツがライブストリーミング配信されている場合に動作例１と異なる動作を行うようになっている。すなわち、再生装置１００は、映像コンテンツの再生指示をユーザから受け付けると、対象映像コンテンツの対象ピリオドの先頭から（すなわち、対象ピリオドの先頭のメディアセグメント）から順にユニキャスト通信によりメディアセグメントを受信してタイムシフト再生を開始するように構成されている。また、再生指示を受け付けた時点から、対象映像コンテンツのライブストリーミング映像のマルチキャスト配信を同時に受信するように構成されている。
【００６１】
以下、図７を参照しながら本動作例を説明する。図７は、再生装置１００が映像コンテンツの再生を開始するまでの本動作例を示すフローチャートである。
【００６２】
図７に示すように、図示しない操作部を介して再生装置１００がユーザから映像コンテンツの再生指示を受け付けると、動作例１のステップＳ１と同様に、再生装置１００の通信制御部１１０は、予め配信サーバから受信していた対象映像コンテンツに関するMPDデータ５aを記億部１３０から読み出す（ステップＳ２１）。なお、MPDデータを事前に取得せず、再生指示後に配信サーバから受信する構成でも構わない。
【００６３】
以降のステップＳ２２〜Ｓ２７においても、再生装置１００は動作例１のステップＳ２〜Ｓ７と同様の動作を行うので、ここでは、ステップＳ２８以降の動作について説明する。
【００６４】
ステップＳ２７の後、通信制御部１１０は、ユニキャスト用リプレゼンテーションを参照することにより、先頭ピリオドの先頭のメディアセグメント（インデックス１のメディアセグメント）から現在マルチキャストによるライブストリーミング配信中のインデックスＮのメディアセグメントまでの各メディアセグメントのＵＲＬを特定する。そして、通信制御部１１０は、インデックスの昇順で特定した各メディアセグメントのＵＲＬにアクセスすることにより、タイムシフト再生するためのインデックス１〜Ｎのメディアセグメントをユニキャスト通信で受信する処理を開始する（ステップＳ２８）。
【００６５】
ステップＳ２８の後、Ｎ＋１番目のURLタグの属性「availabilityTime」の値が示す時刻になった時点で、通信制御部１１０は、対象映像コンテンツのマルチキャスト配信を受けるためにマルチキャストグループへの参加要求をマルチキャストルータ２００に送信し（ステップＳ２９）、ステップＳ３０に進む。これにより、再生装置１００は、インデックスＮ＋１のメディアセグメントの受信を開始し、後続するメディアセグメントを順次受信することになる。
【００６６】
ステップＳ２４またはステップＳ２８にてメディアセグメントの受信を開始した時点から、属性「minBufferTime」の値が示す再生期間に相当する映像コンテンツ（メディアセグメント）を受信完了した時点で、再生部１２０は、ライブストリーミング映像の再生を開始する（ステップＳ３０）。
【００６７】
以上、再生装置１００がタイムシフト再生を開始するまでの動作について説明したが、再生装置１００が各メディアセグメントを受信および再生するタイミングが図８に示されている。
【００６８】
図８は、配信サーバ３００がメディアセグメントを配信するスケジュールと、再生装置１００がメディアセグメントを受信および再生するスケジュールと、の時間的関係を模式的に示した図である。図中の各四角形は１つのメディアセグメントを示しており、四角計の内部の文字は、メディアセグメントのインデックスを示している。
【００６９】
図８に示すように、再生装置１００は、ユーザから再生指示を受け付けた時点で、ユニキャスト通信を用いて、ＮＡＳ４００に記録済みまたは記録中のインデックス１〜Ｎのメディアセグメントの受信を開始することができる。すなわち、再生装置１００は、インデックス１のメディアセグメントの受信が完了した時点で再生を開始することになる。したがって、再生装置１００が再生指示を受け付けてから再生が開始するまでの所要時間は、通常メディアセグメントを１つ再生するのに要する時間未満となるので、動作例１と同様に従来のクライアント装置よりも短くなる。
【００７０】
なお、再生装置１００は、ユーザからの再生指示を受け付けたときにタイムシフト再生を行うか、あるいは、前述のライブストリーミング映像の再生を行うかを、ユーザからの操作指示に応じて切り替え可能に構成されていてもよいし、一旦いずれか一方の再生方法で再生を開始し、ユーザからの操作指示に応じて、もう一方の再生方法による再生に切り替え可能に構成されていてもよい。
【００７１】
例えば、図８に示す再生装置１００の受信・再生スケジュールにおいて、オンデマンド配信されるインデックス３のメディアセグメントを受信した時点では、インデックス１〜３およびインデックスＮ＋１のメディアセグメントを受信済みである。この場合、再生部１２０は、タイムシフト再生の再生指示を受けると、インデックス１のメディアセグメントから順次再生を行い、リアルタイム再生の再生指示を受けると、インデックスＮ＋１のメディアセグメントから順次再生を行うように再生動作を行ってもよい。
【００７２】
本実施形態の配信システムでは、再生装置１００がライブストリーミング映像の再生およびタイムシフト再生の何れを行う場合であっても、再生装置１００が再生指示を受け付けてから再生が開始するまでの所要時間、および、配信サーバ３００側のネットワークの帯域や配信サーバ３００自体の負荷を変化させることなく、ライブ配信およびオンデマンド配信を実現できる。そのため、本実施形態の配信システムでは、従来とは異なり、効率的なライブ配信用にデジタル放送やIPマルチキャストによるIPTVを用い、且つ、オンデマンド配信用にDASHを用いるというように複数の配信システムを併用する必要がない。
【００７３】
（付記事項１）
再生装置１００が映像コンテンツの再生を開始するためにＭＰＤデータとしてＭＰＤデータ５ａを参照するものとして、再生装置１００の動作（図５のフローチャートに従った動作例１および図７のフローチャートに従った動作例２）を説明した。
【００７４】
再生装置１００が映像コンテンツの再生を開始するために参照するＭＰＤデータがＭＰＤデータ５ｂである場合にも、再生装置１００は、図５（または図７）のフローチャートに従った動作を行う。ただし、ＭＰＤデータ５ｂを参照する場合の再生装置１００の動作は、ステップＳ７（またはステップＳ２７）におけるインデックスＮを算出する具体的な動作が、ＭＰＤデータ５ｂを参照する場合の再生装置１００の動作と異なっている。
【００７５】
すなわち、通信制御部１１０は、以下の式を満たすようなＮを算出することになる。
【００７６】
【数１】
2012096372.tif 000003
【００７７】
ここで、Stime:直前に解析した対象Representation開始タグの属性「availabilityTime」の値、Ｄ：対象ピリオドのSegmentInfoDefault開始タグの属性「duration」の値、curTime:内蔵時計部１６０が指し示す時刻の値である。上記式を満たすＮを算出することにより、通信制御部１１０は、ＭＰＤデータ５ａを参照する場合と同じ値Ｎを算出することができる。
【００７８】
（付記事項２）
ライブ配信のために上述のRTPによるマルチキャスト配信する構成について説明したが、他の一斉送信手段を用いる構成を採用することも可能である。例えば、既存のデジタル放送網を用いてブロードキャスト配信する構成を採用することも可能である。その場合、再生装置はIP網向けのネットワークI/F１４０に加え、デジタル放送に対応したデジタルチューナを備え、デジタル放送網経由でメディアセグメント（MPEG-2TS）の受信を行う。また、配信サーバには同様に、デジタル放送網へのデータ送信手段を設ける。デジタル放送網経由でライブ配信される映像コンテンツ（メディアセグメント）を示すURLには、例えば「dvb://233a.104」のような既存のデジタル放送網用URL表記を用い、このようなURL表記が用いられたリプレゼンテーションに属するメディアセグメントの送受信には、デジタル放送網を用いる構成とすればよい。
〔実施形態２〕
次に、本発明の別の一実施形態に係る配信システムについて、図９〜図１４を参照しながら説明する。
【００７９】
本実施形態に係る配信システムは、実施形態１に係る配信システムと同様に、映像コンテンツを再生装置にライブ配信およびオンデマンド配信するための配信システムである。一方、本実施形態に係る配信システムは、再生装置と配信サーバとの間の通信に大きな遅延が発生したり、再生装置の内蔵時計の現在時刻が配信サーバの内蔵時計の現在時刻と大きく異なっていたりするといった状況においても、適切に映像コンテンツを再生することができる点で実施形態１の配信システムと相違している。
【００８０】
すなわち、実施形態１の配信システムでは、再生装置１００が配信サーバからマルチキャスト配信を受けるメディアセグメントのインデックスを確認する術がないため、上記状況が発生した場合に、ユニキャスト通信により受信して再生したメディアセグメントと同じメディアセグメントをマルチキャスト通信により受信して重複して再生してしまったり、一部のメディアセグメントを受信および再生ができなかったりといった状況が生じ得る。
【００８１】
本実施形態に係る配信システムは、以下に詳細に説明するように、再生装置が同じメディアセグメントを重複して再生したり、一部のメディアセグメントを再生しなかったりするといった不具合なく適切に映像コンテンツを再生することができるようになっている。
【００８２】
最初に、本実施形態に係る配信システムの構成について説明する。図９は、本実施形態に係る再生装置の全体構成を示した図であり、図１０は、本実施形態に係る配信システム１の全体構成を示した図である。
【００８３】
図１０に示すように、配信システム１’は、実施形態１の配信システム１と類似したシステム構成となっているが、再生装置１００’および配信サーバ３００’が実施形態１の再生装置１００および配信サーバ３００と一部異なっている。以下では、配信システム１’の構成をその相違点を中心に説明することにし、相違しない部分については説明を省略することにする。
【００８４】
（配信サーバ３００’）
配信サーバ３００’は、映像コンテンツを構成するライブカメラ（図示せず）からの映像をメディアセグメント単位で順次、ＮＡＳ４００に記録しつつ対象映像コンテンツをマルチキャスト配信する。また、配信サーバ３００’は、再生装置１００’からメディアセグメントのＨＴＴＰ要求を受けると、ＮＡＳ４００に記録された該メディアセグメントをユニキャスト通信により再生装置１００’にオンデマンド配信する。
【００８５】
配信サーバ３００’は、各メディアセグメントのメタ情報として該メディアセグメントのインデックス情報を含めて、メディアセグメントを記録および配信をするようになっている。
【００８６】
（再生装置１００’）
図９に示すように、再生装置１００’は、通信制御部１１０’、再生部１２０、記憶部１３０、ネットワークＩ／Ｆ１４０、表示部１５０、および内蔵時計部１６０を備えている。ここでは、通信制御部１１０’についてのみ説明する。
【００８７】
（通信制御部１１０’）
通信制御部１１０’は、予め映像コンテンツに関するＭＰＤデータ（メタデータ）を配信サーバ３００から受信して記憶部１３０に記録する。映像コンテンツの再生指示をユーザから受け付けると、通信制御部１１０’は、記憶部１３０に記録されたＭＰＤデータを参照することにより、対象映像コンテンツを構成する各メディアセグメントを配信サーバ３００が配信する配信時刻を特定する。そして、通信制御部１１０’は、内蔵時計部１６０が指し示す現在時刻と、各メディアセグメントについて特定した配信時刻と、から、オンデマンド配信およびライブ配信のそれぞれで受信すべきメディアセグメントを特定し、オンデマンド配信されるメディアセグメントの取得のためのＨＴＴＰ要求を配信サーバ３００に送信する。
【００８８】
さらに、通信制御部１１０’は、ライブ配信されるメディアセグメントの取得には、対象映像コンテンツのマルチキャスト配信の要求を、マルチキャストルータ２００に送信する。
【００８９】
通信制御部１１０’は、受信したメディアセグメントを記憶部１３０に記憶するが、マルチキャスト配信により最初に受信したメディアセグメントのインデックス情報を参照する。通信制御部１１０’は、参照したインデックス情報が要求時に想定した値と異なる場合、オンデマンド配信およびライブ配信の双方により一部のメディアセグメントを重複して取得したり、オンデマンド配信およびライブ配信のいずれによっても取得すべき一部のメディアセグメントを取得できなかったりといった状況が生じると判断し、そのような一部のメディアセグメントについて重複分の破棄または追加取得要求を行う。
【００９０】
（再生装置１００’が映像コンテンツの再生を開始する動作の動作例）
以下では、図１１を参照しながら、映像コンテンツのライブストリーミング映像の再生を開始するまでの再生装置１００’の動作の一動作例について説明する。
【００９１】
図１１は、再生装置１００’が映像コンテンツの再生を開始するまでの動作を示すフローチャートである。
【００９２】
ステップＳ４１〜ステップＳ４５の処理は、再生装置１００の動作例１としてすでに説明したステップＳ２〜ステップＳ４およびステップＳ１０の処理と同じ処理であり、ステップＳ４６〜Ｓ４９、Ｓ５１の処理は、すでに説明したステップＳ５〜Ｓ８、Ｓ１０の処理と同じ処理であるので、ここでは、説明を省略する。
【００９３】
ステップＳ５０において、通信制御部１１０’は、ステップＳ４９の処理と同時に、対象映像コンテンツのマルチキャスト配信を受けるためにマルチキャストグループへの参加要求をマルチキャストルータ２００に送信し、ステップＳ５１に進む。
【００９４】
その後、ステップＳ５２において、通信制御部１１０’は、最初にマルチキャスト配信により受信したメディアセグメントのインデックス情報を参照する。例えば、配信サーバ３００’が再生装置１００’にメディアセグメントをMPEG2-TS形式で配信する場合には、図１２(ａ)に示すように、PMT（Program Map Table）に当該メディアセグメントのインデックスＮが埋め込まれた状態でMPEG2-TSを配信する。また、例えば、配信サーバ３００’が再生装置１００’にメディアセグメントをMP4形式で配信する場合には、図１２（ｂ）に示すように、ボックスのひとつにメディアセグメントのインデックスＮが格納されたMP4データを配信する。
【００９５】
その後、通信制御部１１０’は、ステップＳ５２にて参照したインデックスの値がＮ＋１であるか、Ｎ＋１より大きいか、あるいは、Ｎ＋１より小さいかを判定する（ステップＳ５３）。
【００９６】
インデックスの値がＮ＋１であると判定された場合（ステップＳ５３において「＝Ｎ＋１」）、受信されるメディアセグメントの重複あるいは不足は発生しないため、処理を終了する。一方、インデックスの値Ｍ＋１がＮ＋１より大きいと判定された場合（ステップＳ５３において「＝Ｍ＋１（Ｍ＞Ｎ）」）、ステップＳ５４に進み、インデックスの値Ｍ＋１がＮ＋１より小さいと判定された場合（ステップＳ５３において「＝Ｍ＋１（Ｍ＜Ｎ）」）、ステップＳ５５に進む。
【００９７】
ステップＳ５４において、通信制御部１１０’は、さらに（Ｍ−Ｎ）個のメディアセグメント（インデックスＮ＋１〜インデックスＭの各メディアセグメント）の受信不足が発生すると判定し、オンデマンド配信での追加取得要求を行い、処理を終了する。
【００９８】
また、ステップＳ５５において、通信制御部１１０’は、受信される（Ｎ−Ｍ）個のメディアセグメント（インデックスＭ＋１〜インデックスＮの各メディアセグメント）がオンデマンド配信、ライブ配信の双方で重複受信されると判定し、一方（例えばマルチキャストにてライブ配信されるメディアセグメント）を破棄することを決定し、処理を終了する。
【００９９】
以上、再生装置１００’がライブストリーミング映像の再生を開始するまでの動作について説明したが、再生装置１００’が各メディアセグメントを受信および再生するタイミングの例が図１３および図１４に示されている。
【０１００】
図１３および図１４は、配信サーバ３００’がメディアセグメントを配信するスケジュールと、再生装置１００’がメディアセグメントを受信および再生するスケジュールと、の時間的関係を模式的に示した図である。
【０１０１】
図１３は、配信サーバ３００’とマルチキャストルータ２００との間のネットワークＮＷにおける通信に大きな遅延がある場合であって、再生装置１００’と同一のサブネットに、マルチキャストルータ２００を介して対象映像コンテンツのマルチキャスト配信を受けている他の再生装置がすでに存在している場合のスケジュールの例である。
【０１０２】
配信サーバ３００’とマルチキャストルータ２００との間の通信に大きな遅延がある場合、配信サーバ３００’がインデックスＮのメディアセグメントを配信するタイミングにおいて、マルチキャストルータ２００がインデックスＭ（Ｍ＜Ｎ）のメディアセグメントを上記他の再生装置に転送している。
【０１０３】
このタイミングで、再生装置１００’が映像コンテンツの再生指示をユーザから受け付けると、ステップＳ４９において再生装置１００’が最初にマルチキャスト配信により受信するメディアセグメントのインデックスはＭ＋１（図１３ではＭ＋１＝Ｎ）となる。すなわち、再生装置１００’は、ライブ配信およびオンデマンド配信によりインデックスＮのメディアセグメントを重複して受信してしまう。
【０１０４】
しかしながら、再生装置１００’は、ステップＳ５２、Ｓ５３の処理により、重複して受信してしまうことを検出し、ステップＳ５５の処理により一方を破棄することができる。したがって、再生装置１００’は、インデックスＮのメディアセグメントを重複して再生してしまう（すなわち、映像コンテンツ中の一部の映像を２度再生してしまう）ことなく、図１３に示すように適切にライブストリーミング映像を再生することができる。
【０１０５】
また、図１４は、配信サーバ３００’の内蔵時計が正確な時刻を刻んでおり、再生装置１００’の内蔵時計部１６０が、正確な時刻よりも著しく遅れている場合のスケジュールの例である。
【０１０６】
この場合、内蔵時計部１６０が指し示す時刻が遅れているので、ステップＳ５８において求めたインデックスＮの値は、実際に配信サーバ３００’が配信中のメディアセグメントＭ（図１４ではＭ＝Ｎ＋１）のインデックスよりも小さい値になる。
【０１０７】
すなわち、ステップＳ４９において再生装置１００’が最初にマルチキャスト配信により受信するメディアセグメントのインデックスはＭ＋１（図１４ではＮ＋２）となり、（Ｍ−Ｎ）個のメディアセグメント（インデックスＮ＋１〜インデックスＭの各メディアセグメント）を受信できなくなってしまう。
【０１０８】
しかしながら、再生装置１００’は、ステップＳ５２、Ｓ５３の処理により、想定していた一部のメディアセグメント（図１４ではＮ＋１）をマルチキャスト配信によって受信できないことを検出し、ステップＳ５４の処理により、上記一部のメディアセグメントをＤＡＳＨにより受信することを決定する。これにより、再生装置１００’は、一部のメディアセグメントを再生できない（すなわち、映像コンテンツ中の一部の映像を飛ばして再生してしまう）という不具合が生じることなく、図１４に示すように適切にライブストリーミング映像を再生することができる。
【０１０９】
（付記事項３）
なお、実施形態１の再生装置１００の動作例２のように、再生装置１００’は対象映像コンテンツのタイムシフト再生を行うことができる。また、再生装置１００’は、再生装置と配信サーバとの間の通信に大きな遅延が発生したり、再生装置の内蔵時計の現在時刻が配信サーバの内蔵時計の現在時刻と大きく異なっていたりするといった状況においても、適切にタイムシフト再生を行うことができる。
【０１１０】
このためには、通信制御部１１０’は、上述した再生装置１００’のステップＳ５２およびＳ５３の処理を行うことにより、マルチキャスト配信およびＤＡＳＨにより同一のメディアセグメントを重複して受信してしまうこと、および、一部のメディアセグメントをマルチキャスト配信により受信できないことを検出すればよい。
【０１１１】
そして、同一のメディアセグメントを重複して受信してしまうことが検出された場合には、ステップＳ５５のように、マルチキャスト配信により重複して受信したメディアセグメントを破棄することを決定すればよい。
【０１１２】
また、一部のメディアセグメントをマルチキャスト配信により受信できないことが検出された場合には、通信制御部１１０’は、インデックス１〜Ｎのメディアセグメントに加えて、ステップＳ５４のように、インデックスＮ＋１〜Ｍのメディアセグメントをユニキャスト通信によるオンデマンド配信により追加受信することを決定すればよい。
【０１１３】
（付記事項４）
実施形態２では、各メディアセグメントのメタ情報として該メディアセグメント内部にインデックス情報を含めることにより、配信サーバ３００’は、再生装置１００’にマルチキャスト配信するメディアセグメントのインデックスを再生装置１００’に特定させていた。
【０１１４】
メディアセグメントのインデックスを再生装置１００’に特定させるために、配信サーバ３００’は、以下のように動作してもよい。
【０１１５】
すなわち、配信サーバ３００’は、各メディアセグメントをＲＴＰパケット（配信用データ）のＲＴＰペイロード部分に分割して格納することにより、ＲＴＰパケットの形式で各メディアセグメントを再生装置１００’に配信することができる。この場合に、配信サーバ３００’は、各メディアセグメントの先頭部分がＲＴＰペイロードに格納されるＲＴＰパケットについてはＲＴＰ拡張ヘッダに、対応するメディアセグメントのインデックス（識別子）を格納した上で、各ＲＴＰパケットを配信すればよい。
【０１１６】
図１５は、配信サーバ３００’が再生装置１００’にマルチキャスト配信により配信するＲＴＰパケット群の一部を示している。図１５に即して言えば、配信サーバ３００’は、インデックスＮのメディアセグメントの先頭部分が格納されるＲＴＰパケットPak-Ｎ1、およびインデックスＮ＋１のメディアセグメントの先頭部分が格納されるＲＴＰパケットPak-（Ｎ＋１）1の各ＲＴＰパケットについて、対応するインデックスを該ＲＴＰパケットのＲＴＰ拡張ヘッダに格納した上で、ＲＴＰパケットPak-Ｎ1、ＲＴＰパケットPak-Ｎ2、ＲＴＰパケットPak-（Ｎ＋１）1を配信すればよい。
【０１１７】
メディアセグメント内部にメタ情報としてインデックス情報を埋め込む場合では、再生装置にメディアセグメントを保存する際、埋め込まれたメタ情報の分だけオーバヘッドが生じるが、ＲＴＰパケットヘッダは、受信時に破棄されるため、オーバヘッドが生じないメリットがある。
【０１１８】
（付記事項５）
またメディアセグメントを特定するためのメタ情報として、MPDデータに記載のメディアセグメントのインデックスを、メディアセグメント内部、あるいはRTPパケットヘッダ内部に格納する代わりに、各メディアセグメントの配信開始時刻、再生開始時刻等の時間情報（識別子）を用いてもよい。
【０１１９】
上述の通り各メディアセグメントの配信開始時刻が、MPDデータ内の属性「availabilityTime」にUTCで記載される。あるいは、属性「availabilityStartTime」等を用いて導出することが可能である。従って、UTCで示される各メディアセグメントの配信開始時刻を、メタ情報として、メディアセグメント内部、あるいはRTPパケットヘッダ内部にメディアセグメントのインデックスの代わりに格納すれば、メタ情報を基にメディアセグメントを特定することが可能ことは明らかである。またメタ情報としてMPDデータ内の各属性を基に導出可能なメディアセグメント毎の再生開始時刻を用いることも可能である。
【０１２０】
あるいは、メディアセグメント内に元々存在する時間情報を用いることもできる。MPEG-2TSでは、90KHzのカウンタ値で表わされるPCRによって復号時刻、再生時刻等の時間情報が管理されているため、直接PCR値とUTCを基準としたMPDデータ内の時間情報と比較することはできない。しかしながら例えば各ピリオドの先頭メディアセグメントの先頭PCRの値を当該リプレゼンテーションの「SegmentInfo」の新たな属性として記載することで、受信したメディアセグメントのPCRとの比較によりピリオド先頭からの経過時間を求めることが可能であり、求めた経過時間から対応するメディアセグメントを特定することが可能である。なおMPDデータの生成は映像コンテンツのライブ配信に先立って行われるため、MPEG-2TSデータ生成時に設定されるピリオド先頭のPCR値を、MPDデータ生成時に求めることが困難な場合も考えられる。従って、ピリオド先頭のPCRを含むMPEG-2TSパケットが生成されたのち、マルチキャスト配信とは別に当該PCRを含むMPEG-2TSパケットのみをオンデマンド配信にて受信可能となるよう配信サーバを構成し、さらにMPDデータにはピリオド先頭のPCR値の代わりに当該MPEG-2TSパケットのオンデマンド配信を行うURLを「SegmentInfo」の新たな属性として記載する構成としてもよい。あるいは、MPDデータに新たな属性の追加は行わず、ピリオド先頭のPCR値をメタ情報として各メディアセグメントに格納しても、メディアセグメント受信時に、ピリオド先頭からの経過時間を求めることが可能であり、受信したメディアセグメントを特定することが可能であり、連続したメディアセグメントを順次再生することができる。
〔実施形態３〕
次に、本発明のさらに別の一実施形態に係る配信システムについて、図１６〜図２１を参照しながら説明する。
【０１２１】
本実施形態に係る配信システムは、実施形態１および実施形態２に係る配信システムと同様に、映像コンテンツを再生装置にライブ配信するための配信システムである。
【０１２２】
最初に、本実施形態に係る配信システムの構成について説明する。図１６は、本実施形態に係る再生装置の全体構成を示した図であり、図１７は、本実施形態に係る配信システム１”の全体構成を示した図である。
【０１２３】
図１７に示すように、配信システム１”は、実施形態２の配信システム１’と類似したシステム構成となっているが、再生装置１００”および配信サーバ３００”が実施形態２の再生装置１００’および配信サーバ３００’と一部異なっている。以下では、配信システム１”の構成をその相違点を中心に説明することにし、相違しない部分については説明を省略することにする。
【０１２４】
（配信サーバ３００”）
配信サーバ３００”は、配信サーバ３００’の付記事項４に記載した構成と同様に、各メディアセグメントをＲＴＰパケットのＲＴＰペイロード部分に分割して格納する。ただし、図１８に示すように、配信サーバ３００”は、すべてのＲＴＰパケットについて、ＲＴＰペイロードにその一部（部分データ）が格納されるメディアセグメントのインデックスを、ＲＴＰ拡張ヘッダのSegmentIdx変数値として格納する。この点で、メディアセグメントの先頭部分がＲＴＰペイロードに格納されるＲＴＰパケットのＲＴＰ拡張ヘッダにのみインデックスを格納する付記事項４の構成とは異なっている。
【０１２５】
（再生装置１００”）
図１６に示すように、再生装置１００”は、通信制御部１１０”、再生部１２０、記憶部１３０、ネットワークＩ／Ｆ１４０、表示部１５０、および内蔵時計部１６０を備えている。ここでは、通信制御部１１０”についてのみ説明する。
【０１２６】
（通信制御部１１０”）
通信制御部１１０”は、予め映像コンテンツに関するＭＰＤデータ（メタデータ）を配信サーバ３００”から受信して記憶部１３０に記録する。映像コンテンツの再生指示をユーザから受け付けると、通信制御部１１０”は、ＭＰＤデータを参照し、対象映像コンテンツのマルチキャスト配信の要求を、マルチキャストルータ２００に送信する。そして、通信制御部１１０”は、最初に受信したＲＴＰパケットについて、オンデマンド配信により受信すべきメディアセグメントを特定するために、ＲＴＰパケットのＲＴＰ拡張ヘッダに格納されているインデックスを参照する。
（再生装置１００”が映像コンテンツの再生を開始する動作の動作例）
以下では、図１９を参照しながら、映像コンテンツのライブストリーミング映像の再生を開始するまでの再生装置１００”の動作の一動作例について説明する。
【０１２７】
図１９は、再生装置１００”が映像コンテンツの再生を開始するまでの動作を示すフローチャートである。
【０１２８】
ステップＳ６１〜ステップＳ６６の処理は、再生装置１００の動作例１としてすでに説明したステップＳ２〜ステップＳ６の処理と同じ処理であるので、ここでは、説明を省略する。
【０１２９】
ステップＳ６５においてＹＥＳと判定された場合、通信制御部１１０は、対象映像コンテンツのマルチキャスト配信を受けるためにマルチキャストグループへの参加要求をマルチキャストルータ２００に送信する（ステップＳ６７）。
【０１３０】
ステップＳ６７の処理により再生装置１００”はライブストリーミング映像を構成するＲＴＰパケットの受信を開始するが、最初のＲＴＰパケットを受信すると、ＲＴＰパケットのＲＴＰ拡張ヘッダに含まれているインデックスを参照する。参照したインデックスの値がＮである場合、通信制御部１１０”は、ユニキャスト用リプレゼンテーションを参照することにより、インデックスＮのメディアセグメントのＵＲＬを特定する。そして、通信制御部１１０”は、特定したＵＲＬにアクセスすることにより、インデックスＮのメディアセグメントをオンデマンド配信で受信する処理を開始する（ステップＳ６８）。
【０１３１】
ステップＳ６４またはステップＳ６８にてメディアセグメントの受信を開始した時点から、属性「minBufferTime」の値が示す再生期間に相当する映像コンテンツ（メディアセグメント）を受信完了した時点で、再生部１２０は、ライブストリーミング映像の再生を開始する（ステップＳ６９）。
【０１３２】
以上のように、本実施形態では、オンデマンド配信で取得するメディアセグメントを特定するために、メディアセグメント毎の詳細な配信時刻をＭＰＤデータに基づいて特定する必要がない。換言すれば、再生装置１００”は、各メディアセグメントの配信時刻がＭＰＤデータに記載されていなくとも、オンデマンド配信で受信すべきメディアセグメントを特定することができる。
【０１３３】
（再生装置１００”および配信サーバ３００”の変形例）
なお、再生装置１００”および配信サーバ３００”は、以下のように動作するように構成されてもよい。なお、以下の説明では、配信サーバ３００”は、配信方法がユニキャストによるオンデマンド配信、マルチキャストによるライブ配信のみが異なる２つのリプレゼンテーションで構成される場合の例である。
【０１３４】
図２０に示すように、配信サーバ３００”は、各ＲＴＰパケットについて、ＲＴＰ拡張ヘッダにメディアセグメントのインデックスだけでなくメディアセグメントのバイトオフセット値を格納してもよい。すなわち、配信サーバ３００”は、ＲＴＰペイロードの先頭バイトとしてメディアセグメントＮの先頭からＸＸＸバイト目のバイトデータが格納される場合には、SegmentIdx変数の値としてインデックスＮを格納するだけでなく、ByteOffset変数の値としてバイトオフセット値ＸＸＸを格納してもよい。
【０１３５】
そして、再生装置１００”は、マルチキャスト配信により最初に受信するＲＴＰパケットに含まれるＲＴＰペイロードの先頭バイトがインデックスＮのメディアセグメントの先頭からＸＸＸバイト目のデータである場合には、オンデマンド配信により受信するインデックスＮのメディアセグメントを、該メディアセグメント全体ではなく該メディアセグメントのＸＸＸバイト目より前の部分のデータのみ部分取得する構成としてもよい。
【０１３６】
図２１は、再生装置１００”が映像コンテンツの再生を開始するまでの変形例に係る動作を示すフローチャートである。
【０１３７】
図２１からわかるように、図２１のフローチャートが図１９のフローチャートと異なる点はステップＳ８８のみである。すなわち、再生装置１００”の変形例に係る動作は、次の段落で説明するステップＳ８８を除き、図１９のフローチャートを用いて説明した再生装置１００”の動作と同じである。
【０１３８】
ステップＳ８８では、ステップＳ８７の処理により受信した最初のＲＴＰパケットのＲＴＰ拡張ヘッダに含まれているインデックスおよびバイトオフセット値を参照する。参照したインデックスの値がＮである場合、通信制御部１１０”は、ユニキャスト用リプレゼンテーションを参照することにより、インデックスＮのメディアセグメントのＵＲＬを特定する。そして、通信制御部１１０”は、特定したＵＲＬにアクセスすることにより、インデックスＮのメディアセグメントをＨＴＴＰで受信する処理を開始する。通信制御部１１０”は、バイトオフセット値であるＸＸＸバイト目までのデータを受信した時点で、受信処理を中断する。あるいはＨＴＴＰのバイトレンジ指定を用いてバイトオフセット値であるＸＸＸバイト目までのデータを取得するためのＨＴＴＰ要求を行ってもよい。
【０１３９】
再生装置１００”は、上記変形例に係る動作により、ＨＴＴＰにより受信したＸＸＸバイト目までのデータとマルチキャスト配信により受信したＸＸＸバイト目以降のデータとを組み合わせて、インデックスＮのメディアセグメントを再生することができる。
【０１４０】
すなわち、再生装置１００”は、インデックスＮのメディアセグメントの一部（ＸＸＸバイト目以降のデータ）をオンデマンド配信とライブ配信とで重複して受信してしまうことがない効率のよい受信処理を行うことができる。
【０１４１】
（実施形態１〜３に係る各再生装置１００、１００’、１００”の利点）
以上のように、各再生装置１００（１００’、１００”）は、再生指示をユーザから受け付けると、再生すべきストリーミング映像が時分割された複数のメディアセグメントを配信サーバ３００（３００’、３００”）から取得しながら順次再生する。
【０１４２】
各再生装置では、通信制御部１１０（１１０’、１１０”）が、配信サーバがすでにマルチキャスト配信した一部（１個またはＮ個）のメディアセグメントをＤＡＳＨにより配信サーバから受信する。また、通信制御部は、残りのメディアセグメントを配信サーバからマルチキャスト配信を受けて受信する。
【０１４３】
そして、各再生装置では、再生部１２０が、ユニキャスト通信により最初に受信したメディアセグメントを、最初に再生する。
【０１４４】
さらに、通信制御部は、マルチキャスト配信を受けて上記残りのメディアセグメントを受信する処理を開始する時点、該時点より前、または該時点の直後に、上記一部のメディアセグメントを受信する処理を開始する。
【０１４５】
すなわち、各再生装置は、マルチキャスト配信だけを受けてストリーミング映像を再生する従来のクライアント装置が映像の再生を開始するタイミングよりも早く、ストリーミング映像の再生を開始することができる。また、各再生装置がＤＡＳＨにより受信するのはストリーミング映像を構成する全メディアセグメントではなく一部のメディアセグメントのみであるので、ストリーミング映像の配信を受ける再生装置の台数が増加した場合であっても、配信サーバ側のネットワークの帯域負荷および配信サーバの処理負荷を抑制することができる。
【０１４６】
以上のことから、各再生装置は、配信サーバ側のネットワークの帯域負荷および配信サーバの処理負荷を抑制しつつ、コンテンツの再生を短い待ち時間で開始することできる。
【０１４７】
（その他）
なお、本発明は、映像コンテンツを再生する映像再生装置としてだけでなく、例えば、音声コンテンツを再生する音声再生装置としても実現することができる。
【０１４８】
各実施形態の再生装置は、内蔵時計から時刻を参照するように構成されていなくてもよい。すなわち、外部のタイムサーバ（図示せず）から時刻情報を取得して時刻を参照するように構成されていもよい。
【０１４９】
（プログラム、記憶媒体）
再生装置１００（１００’、１００”）の各ブロックは、集積回路（ＩＣチップ）上に形成された論理回路によってハードウェア的に実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェア的に実現してもよい。
【０１５０】
後者の場合、再生装置１００（１００’、１００”）は、各機能を実現するプログラムの命令を実行するＣＰＵ、上記プログラムを格納したＲＯＭ（Read Only Memory）、上記プログラムを展開するＲＡＭ（Random Access Memory）、上記プログラムおよび各種データを格納するメモリ等の記憶装置（記録媒体）などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアである再生装置１００（１００’、１００”）の制御プログラムのプログラムコード（実行形式プログラム、中間コードプログラム、ソースプログラム）をコンピュータで読み取り可能に記録した記録媒体を、再生装置１００（１００’、１００”）に供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。
【０１５１】
上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ類、フロッピー（登録商標）ディスク／ハードディスク等の磁気ディスクやＣＤ−ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ／ＣＤ−Ｒ等の光ディスクを含むディスク類、ＩＣカード（メモリカードを含む）／光カード等のカード類、マスクＲＯＭ／ＥＰＲＯＭ／ＥＥＰＲＯＭ（登録商標）／フラッシュＲＯＭ等の半導体メモリ類、あるいはＰＬＤ（Programmable logic device）やＦＰＧＡ（Field Programmable Gate Array）等の論理回路類などを用いることができる。
【０１５２】
また、上記プログラムコードは、通信ネットワークを介して再生装置１００（１００’、１００”）に供給してもよい。この通信ネットワークは、プログラムコードを伝送可能であればよく、特に限定されない。例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ、ＩＳＤＮ、ＶＡＮ、ＣＡＴＶ通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、この通信ネットワークを構成する伝送媒体も、プログラムコードを伝送可能な媒体であればよく、特定の構成または種類のものに限定されない。例えば、ＩＥＥＥ１３９４、ＵＳＢ、電力線搬送、ケーブルＴＶ回線、電話線、ＡＤＳＬ（Asymmetric Digital Subscriber Line）回線等の有線でも、ＩｒＤＡやリモコンのような赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩＥＥＥ８０２．１１無線、ＨＤＲ（High Data Rate）、ＮＦＣ（Near Field Communication）、ＤＬＮＡ（Digital Living Network Alliance）、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。
【０１５３】
なお、ここで開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明だけではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
【０１５４】
以上のように、本発明に係るコンテンツ再生装置は、再生指示をユーザから受け付けると、再生すべきコンテンツデータが時分割された複数の時分割データを配信サーバから取得しながら順次再生するコンテンツ再生装置において、上記複数の時分割データのうち、上記配信サーバがすでにマルチキャスト配信した一部の時分割データをユニキャスト通信により上記配信サーバから取得する第１取得手段と、上記複数の時分割データのうち、上記一部の時分割データに続けて再生すべき残りの時分割データを上記配信サーバからマルチキャスト配信を受けて取得する第２取得手段と、上記第１取得手段が最初に取得した時分割データを、上記複数の時分割データの中で最初に再生する再生手段と、を備えているが、上記第１取得手段は、上記第２取得手段が上記残りの時分割データを取得する処理を開始する時点以前（すなわち、該時点、または該時点より前）に、上記一部の時分割データを取得する処理を開始するように構成されていることが望ましい。
【０１５５】
本発明に係るコンテンツ再生装置は、上記時分割データが相異なる複数の品質の再生対象データから構成されており、上記再生手段は、上記複数の時分割データの各々について、該時分割データを構成するいずれかの品質の再生対象データを配信サーバから取得しながら順次再生するように構成されていることが望ましい。
【０１５６】
上記の構成によれば、本発明に係るコンテンツ再生装置は、時分割データを再生する際に、コンテンツ再生装置の処理能力や配信サーバとの間のネットワークの帯域負荷といった状況に応じて最適な品質の再生対象データを選択して再生することができるというさらなる効果を奏する。
【０１５７】
本発明に係るコンテンツ再生装置は、上記コンテンツデータに関するメタデータであって、上記複数の時分割データの各々について上記配信サーバが該時分割データをマルチキャスト配信する配信時刻を該コンテンツ再生装置が特定可能なメタデータを、該コンテンツデータの取得に先駆けて取得する第３取得手段と、タイマーが指し示す時刻を監視する時刻監視手段と、をさらに備え、上記第１取得手段は、上記メタデータから特定した各時分割データの配信時刻に基づいて、上記再生指示を受け付けたときに上記タイマーが指し示す時刻の直近でマルチキャスト配信された上記一部の時分割データを取得するように構成されており、上記第２取得手段は、上記メタデータから特定した上記配信時刻に基づいて、上記第１取得手段が上記一部の時分割データを取得する処理を開始してから最初に時分割データが配信される配信時刻を上記タイマーが指し示したときに、上記残りの時分割データを取得する処理を開始することが望ましい。
【０１５８】
上記の構成によれば、本発明に係るコンテンツ再生装置は、再生指示を受け付けた時点以降に最初に配信サーバが時分割データを配信するタイミングで、上記残りの時分割データを取得する処理を開始するので、再生指示を受け付けた直後に上記時分割データの一部分のみを取得して再生できずに破棄するといった無駄な処理を抑制することができるというさらなる効果を奏する。
【０１５９】
本発明に係るコンテンツ再生装置は、上記残りの時分割データに加えて、上記第１取得手段により取得される上記一部の時分割データを構成する１以上の時分割データの少なくともいずれかを上記第２取得手段が重複取得するか否かを判定する重複取得判定手段をさらに備え、上記複数の時分割データの各々について、上記時分割データには該時分割データを識別するための識別値が関連づけられているとともに、上記メタデータには、該時分割データを識別するための識別値が含まれており、上記重複取得判定手段は、上記配信時刻を上記タイマーが指し示した後に上記第２取得手段が取得する最初の時分割データに関連づけられている識別値が、上記配信時刻に配信されると上記メタデータから特定可能な時分割データの識別値よりも小さい場合に限り、上記第２取得手段が重複取得すると判定するように構成されており、上記重複取得判定手段が上記１以上の時分割データの少なくともいずれかが上記第２取得手段により取得されると判定した場合に、上記再生手段は、上記第１取得手段および上記第２取得手段の双方により取得された同一の時分割データの一方を再生しないことが望ましい。
【０１６０】
ここで、例えば、配信サーバからコンテンツ再生装置への時分割データの伝送に大きな遅延がある場合、コンテンツ再生装置は、すでに配信サーバがマルチキャスト配信した上記一部の時分割データを、再生指示を受け付けた時点以降にマルチキャスト配信を受けて取得するような状況が発生することがある。
【０１６１】
上記の構成によれば、本発明に係るコンテンツ再生装置は、このような状況においてユニキャスト通信およびマルチキャスト配信の双方で取得した同一の時分割データを２回再生してしまうという再生の不具合を防ぐことができるというさらなる効果を奏する。
【０１６２】
本発明に係るコンテンツ再生装置は、上記コンテンツデータに関するメタデータであって、上記複数の時分割データの各々について上記配信サーバが該時分割データをマルチキャスト配信する配信時刻を該コンテンツ再生装置が特定可能なメタデータを、該コンテンツデータの取得に先駆けて取得する第３取得手段と、タイマーが指し示す時刻を参照する時刻参照手段と、上記メタデータから特定される配信時刻が上記再生指示を受け付けた時点において上記タイマーが指し示す時刻以降となるような時分割データのうち、すでにマルチキャスト配信された時分割データが存在するか否かを判定する判定手段と、をさらに備え、上記複数の時分割データの各々について、上記時分割データには該時分割データを識別するための識別値が関連づけられているとともに、上記メタデータには、該時分割データを識別するための識別値が含まれており、上記判定手段は、上記配信時刻を上記タイマーが指し示した後に上記第２取得手段が取得する最初の時分割データに関連づけられている識別値が、上記配信時刻に配信されると上記メタデータから特定可能な時分割データの識別値よりも大きい場合に限り、すでにマルチキャスト配信された時分割データが存在すると判定するように構成されており、上記第１取得手段は、上記メタデータから特定される配信時刻が上記タイマーの指し示す時刻以前である時分割データだけでなく、上記特定される配信時刻が上記タイマーの指し示す時刻以降である時分割データであってすでにマルチキャスト配信された時分割データを、ユニキャスト通信により取得することが望ましい。
【０１６３】
ここで、タイマーが指し示す時刻が正確な時刻よりも遅れている場合、メタデータから特定される配信時刻が上記再生指示を受け付けた時点において上記タイマーが指し示す時刻以降となるような分割データであっても、上記時点においてすでにマルチキャスト配信されてしまっている場合がある。
【０１６４】
上記の構成によれば、本発明に係るコンテンツ再生装置は、このような場合にマルチキャスト配信を受けて取得できなかった、上記特定される配信時刻が上記タイマーが指し示す時刻以降である分割データであってすでにマルチキャスト配信された分割データをユニキャスト通信により取得する。
【０１６５】
したがって、本発明に係るコンテンツ再生装置は、コンテンツデータの再生中に一部の分割データを再生できなくなる再生の不具合を防ぐことができるというさらなる効果を奏する。
【０１６６】
上記配信サーバは、上記複数の時分割データの各々について、該時分割データを分割することにより得られる複数の部分データが個別に格納された複数のＲＴＰパケットであって各ＲＴＰパケットに該時分割データを識別するための識別子が格納された複数のＲＴＰパケットをマルチキャスト配信するように構成されており、本発明に係るコンテンツ再生装置は、上記第２取得手段が、上記再生指示を受け付けた時点以降にマルチキャスト配信される複数のＲＴＰパケットを上記配信サーバから取得するように構成されており、上記第１取得手段が、上記第２取得手段が最初に取得したＲＴＰパケットに含まれる識別子から識別される時分割データをユニキャスト通信により上記配信サーバから取得するように構成されており、上記再生手段が、上記第１取得手段が取得した時分割データを再生してから、上記第２取得手段が取得した複数のＲＴＰパケットから複数の時分割データを生成して再生することが望ましい。
【０１６７】
上記の構成によれば、本発明に係るコンテンツ再生装置は、上記第１取得手段により取得すべき上記一部の時分割データを、上記第２取得手段が取得したＲＴＰパケットに格納されている上記時分割データを識別するための識別子から特定する。
【０１６８】
したがって、本発明に係るコンテンツ再生装置は、上記コンテンツデータに関するメタデータを参照することなく、上記第１取得手段により取得すべき上記一部の時分割データを特定することができるというさらなる効果を奏する。
【０１６９】
本発明に係るコンテンツ再生装置は、上記第１取得手段が、上記第２取得手段が最初に取得したＲＴＰパケットに含まれる識別子から識別される時分割データを構成する全部分データのうち、上記第２取得手段が取得した上記複数のＲＴＰパケットのいずれにも格納されていない一部の部分データのみを取得するように構成されており、上記再生手段が、上記一部の部分データを構成する１以上の部分データを順次再生してから、上記第２取得手段が取得した複数のＲＴＰパケットに格納されている各部分データを順次再生することが望ましい。
【０１７０】
上記の構成によれば、本発明に係るコンテンツ再生装置は、第１取得手段が取得した一部の部分データを再生してから、上記識別子から識別される時分割データの残りの部分データを再生し、その後の時分割データを順次再生する。
【０１７１】
したがって、本発明に係るコンテンツ再生装置は、上記識別子から識別される時分割データ全体を取得することなく、再生すべきコンテンツデータを再生することができるというさらなる効果を奏する。
【０１７２】
上記コンテンツ再生装置と、該コンテンツ再生装置に対してコンテンツデータを配信可能に該コンテンツ再生装置と接続されている上記配信サーバと、を含んでいる配信システムも本発明の範疇に含まれる。
【０１７３】
また、本発明に係るコンテンツ再生装置としてコンピュータを動作させるプログラムであって、コンピュータを上記の各手段として機能させることを特徴とするプログラム、および、そのようなプログラムを記録した、コンピュータが読み取り可能な記録媒体も本発明の範疇に含まれる。
【０１７４】
さらに、複数の分割データに時分割して配信されるコンテンツデータであって配信サーバがユニキャスト通信およびマルチキャスト配信の両配信方式により配信可能なコンテンツデータに関するメタデータのデータ構造であって、上記複数の分割データの各々について上記配信サーバが該分割データをマルチキャスト配信する配信時刻と、上記配信サーバから該分割データをユニキャスト通信により取得するために参照すべきＵＲＬと、が特定可能に記載されていることを特徴とするデータ構造も本発明の範疇に含まれる。
【０１７５】
さらに、配信サーバが複数の時分割データに時分割して配信されるコンテンツデータを少なくとも１以上の配信用データを用いて配信する場合における該配信用データのデータ構造であって、１以上の上記時分割データの各々について、該時分割データと該時分割データを識別するための識別子とが関連づけて記録されていることを特徴とする配信用データのデータ構造も本発明の範疇に含まれる。
【産業上の利用可能性】
【０１７６】
本発明に係るコンテンツ取得装置は、再生装置などに広く適用することができる。
【符号の説明】
【０１７７】
５ａ、５ｂ                    ＭＰＤデータ
１００、１００’、１００”    再生装置（コンテンツ再生装置）
１１０、１１０’、１１０”      通信制御部（第１取得手段、第２取得手段、第３取
得手段、時刻監視手段、時刻参照手段、判定手段、
重複取得判定手段）
１２０                          再生部（再生手段）
１３０                          記憶部
１４０                          ネットワーク・Ｉ／Ｆ
１５０                          表示部
１６０                        内蔵時計部（タイマー）
２００                        マルチキャストルータ
３００、３００’、３００”    配信サーバ
４００                        ネットワークストレージサーバ（ＮＡＳ）
【図１】
2012096372.tif 000004
【図２】
2012096372.tif 000005
【図３】
2012096372.tif 000006
【図４】
2012096372.tif 000007
【図５】
2012096372.tif 000008
【図６】
2012096372.tif 000009
【図７】
2012096372.tif 000010
【図８】
2012096372.tif 000011
【図９】
2012096372.tif 000012
【図１０】
2012096372.tif 000013
【図１１】
2012096372.tif 000014
【図１２】
2012096372.tif 000015
【図１３】
2012096372.tif 000016
【図１４】
2012096372.tif 000017
【図１５】
2012096372.tif 000018
【図１６】
2012096372.tif 000019
【図１７】
2012096372.tif 000020
【図１８】
2012096372.tif 000021
【図１９】
2012096372.tif 000022
【図２０】
2012096372.tif 000023
【図２１】
2012096372.tif 000024
【国際調査報告】
2012096372.tif 000025
2012096372.tif 000026