JPWO2012096372A1 - コンテンツ再生装置、コンテンツ再生方法、配信システム、コンテンツ再生プログラム、記録媒体、およびデータ構造 - Google Patents

コンテンツ再生装置、コンテンツ再生方法、配信システム、コンテンツ再生プログラム、記録媒体、およびデータ構造 Download PDF

Info

Publication number
JPWO2012096372A1
JPWO2012096372A1 JP2012552767A JP2012552767A JPWO2012096372A1 JP WO2012096372 A1 JPWO2012096372 A1 JP WO2012096372A1 JP 2012552767 A JP2012552767 A JP 2012552767A JP 2012552767 A JP2012552767 A JP 2012552767A JP WO2012096372 A1 JPWO2012096372 A1 JP WO2012096372A1
Authority
JP
Japan
Prior art keywords
time
data
distribution
division data
content
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2012552767A
Other languages
English (en)
Inventor
高橋　真毅
真毅 高橋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sharp Corp
Original Assignee
Sharp Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sharp Corp filed Critical Sharp Corp
Publication of JPWO2012096372A1 publication Critical patent/JPWO2012096372A1/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00—Details of colour television systems
    • H04N9/79—Processing of colour television signals in connection with recording
    • H04N9/87—Regeneration of colour television signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

再生装置（１００）は、ＤＡＳＨを用いて配信サーバ（３００）から１つ目のメディアセグメント（ＭＳ）を取得し、以降のＭＳをマルチキャスト通信により取得する通信制御部（１１０）と、受信したＭＳを再生する再生部（１２０）と、を備えている。制御部（１１０）は、ＤＡＳＨを用いた１つ目のＭＳの取得と、マルチキャスト通信による以降のＭＳの取得と、を同時に開始する。再生部（１２０）は、ＤＡＳＨを用いて最初に取得した１つ目のＭＳを、マルチキャスト通信により以降に取得したＭＳよりも先に再生する。

Description

本発明は、配信サーバから取得したコンテンツデータを再生するコンテンツ再生装置およびコンテンツ再生方法に関する。また、本発明は、そのような配信サーバおよびコンテンツ再生装置を含む配信システムに関する。また、本発明は、そのようなコンテンツ再生装置としてコンピュータを動作させるコンテンツ再生プログラム、および、そのようなコンテンツ再生プログラムを記憶している記録媒体に関する。さらに、本発明は、コンテンツ再生装置がコンテンツデータを取得するために参照するデータのデータ構造に関する。
近年、インターネットに対する需要が急速に高まるにしたがって、テキストや静止画等で構成されたＷＥＢページを見るだけでなく、動画コンテンツを鑑賞するユーザが増えてきている。
このような状況を踏まえ、動画コンテンツを伝送するための様々な技術が開発されているが、そのうちのひとつに現在標準化作業が進められているＤＡＳＨ(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を用いるというように複数の配信システムを併用する必要がない。
（付記事項１）
再生装置１００が映像コンテンツの再生を開始するためにＭＰＤデータとしてＭＰＤデータ５ａを参照するものとして、再生装置１００の動作（図５のフローチャートに従った動作例１および図７のフローチャートに従った動作例２）を説明した。
再生装置１００が映像コンテンツの再生を開始するために参照するＭＰＤデータがＭＰＤデータ５ｂである場合にも、再生装置１００は、図５（または図７）のフローチャートに従った動作を行う。ただし、ＭＰＤデータ５ｂを参照する場合の再生装置１００の動作は、ステップＳ７（またはステップＳ２７）におけるインデックスＮを算出する具体的な動作が、ＭＰＤデータ５ｂを参照する場合の再生装置１００の動作と異なっている。
すなわち、通信制御部１１０は、以下の式を満たすようなＮを算出することになる。
Figure 2012096372
ここで、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）、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。
なお、ここで開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明だけではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
以上のように、本発明に係るコンテンツ再生装置は、再生指示をユーザから受け付けると、再生すべきコンテンツデータが時分割された複数の時分割データを配信サーバから取得しながら順次再生するコンテンツ再生装置において、上記複数の時分割データのうち、上記配信サーバがすでにマルチキャスト配信した一部の時分割データをユニキャスト通信により上記配信サーバから取得する第１取得手段と、上記複数の時分割データのうち、上記一部の時分割データに続けて再生すべき残りの時分割データを上記配信サーバからマルチキャスト配信を受けて取得する第２取得手段と、上記第１取得手段が最初に取得した時分割データを、上記複数の時分割データの中で最初に再生する再生手段と、を備えているが、上記第１取得手段は、上記第２取得手段が上記残りの時分割データを取得する処理を開始する時点以前（すなわち、該時点、または該時点より前）に、上記一部の時分割データを取得する処理を開始するように構成されていることが望ましい。
本発明に係るコンテンツ再生装置は、上記時分割データが相異なる複数の品質の再生対象データから構成されており、上記再生手段は、上記複数の時分割データの各々について、該時分割データを構成するいずれかの品質の再生対象データを配信サーバから取得しながら順次再生するように構成されていることが望ましい。
上記の構成によれば、本発明に係るコンテンツ再生装置は、時分割データを再生する際に、コンテンツ再生装置の処理能力や配信サーバとの間のネットワークの帯域負荷といった状況に応じて最適な品質の再生対象データを選択して再生することができるというさらなる効果を奏する。
本発明に係るコンテンツ再生装置は、上記コンテンツデータに関するメタデータであって、上記複数の時分割データの各々について上記配信サーバが該時分割データをマルチキャスト配信する配信時刻を該コンテンツ再生装置が特定可能なメタデータを、該コンテンツデータの取得に先駆けて取得する第３取得手段と、タイマーが指し示す時刻を監視する時刻監視手段と、をさらに備え、上記第１取得手段は、上記メタデータから特定した各時分割データの配信時刻に基づいて、上記再生指示を受け付けたときに上記タイマーが指し示す時刻の直近でマルチキャスト配信された上記一部の時分割データを取得するように構成されており、上記第２取得手段は、上記メタデータから特定した上記配信時刻に基づいて、上記第１取得手段が上記一部の時分割データを取得する処理を開始してから最初に時分割データが配信される配信時刻を上記タイマーが指し示したときに、上記残りの時分割データを取得する処理を開始することが望ましい。
上記の構成によれば、本発明に係るコンテンツ再生装置は、再生指示を受け付けた時点以降に最初に配信サーバが時分割データを配信するタイミングで、上記残りの時分割データを取得する処理を開始するので、再生指示を受け付けた直後に上記時分割データの一部分のみを取得して再生できずに破棄するといった無駄な処理を抑制することができるというさらなる効果を奏する。
本発明に係るコンテンツ再生装置は、上記残りの時分割データに加えて、上記第１取得手段により取得される上記一部の時分割データを構成する１以上の時分割データの少なくともいずれかを上記第２取得手段が重複取得するか否かを判定する重複取得判定手段をさらに備え、上記複数の時分割データの各々について、上記時分割データには該時分割データを識別するための識別値が関連づけられているとともに、上記メタデータには、該時分割データを識別するための識別値が含まれており、上記重複取得判定手段は、上記配信時刻を上記タイマーが指し示した後に上記第２取得手段が取得する最初の時分割データに関連づけられている識別値が、上記配信時刻に配信されると上記メタデータから特定可能な時分割データの識別値よりも小さい場合に限り、上記第２取得手段が重複取得すると判定するように構成されており、上記重複取得判定手段が上記１以上の時分割データの少なくともいずれかが上記第２取得手段により取得されると判定した場合に、上記再生手段は、上記第１取得手段および上記第２取得手段の双方により取得された同一の時分割データの一方を再生しないことが望ましい。
ここで、例えば、配信サーバからコンテンツ再生装置への時分割データの伝送に大きな遅延がある場合、コンテンツ再生装置は、すでに配信サーバがマルチキャスト配信した上記一部の時分割データを、再生指示を受け付けた時点以降にマルチキャスト配信を受けて取得するような状況が発生することがある。
上記の構成によれば、本発明に係るコンテンツ再生装置は、このような状況においてユニキャスト通信およびマルチキャスト配信の双方で取得した同一の時分割データを２回再生してしまうという再生の不具合を防ぐことができるというさらなる効果を奏する。
本発明に係るコンテンツ再生装置は、上記コンテンツデータに関するメタデータであって、上記複数の時分割データの各々について上記配信サーバが該時分割データをマルチキャスト配信する配信時刻を該コンテンツ再生装置が特定可能なメタデータを、該コンテンツデータの取得に先駆けて取得する第３取得手段と、タイマーが指し示す時刻を参照する時刻参照手段と、上記メタデータから特定される配信時刻が上記再生指示を受け付けた時点において上記タイマーが指し示す時刻以降となるような時分割データのうち、すでにマルチキャスト配信された時分割データが存在するか否かを判定する判定手段と、をさらに備え、上記複数の時分割データの各々について、上記時分割データには該時分割データを識別するための識別値が関連づけられているとともに、上記メタデータには、該時分割データを識別するための識別値が含まれており、上記判定手段は、上記配信時刻を上記タイマーが指し示した後に上記第２取得手段が取得する最初の時分割データに関連づけられている識別値が、上記配信時刻に配信されると上記メタデータから特定可能な時分割データの識別値よりも大きい場合に限り、すでにマルチキャスト配信された時分割データが存在すると判定するように構成されており、上記第１取得手段は、上記メタデータから特定される配信時刻が上記タイマーの指し示す時刻以前である時分割データだけでなく、上記特定される配信時刻が上記タイマーの指し示す時刻以降である時分割データであってすでにマルチキャスト配信された時分割データを、ユニキャスト通信により取得することが望ましい。
ここで、タイマーが指し示す時刻が正確な時刻よりも遅れている場合、メタデータから特定される配信時刻が上記再生指示を受け付けた時点において上記タイマーが指し示す時刻以降となるような分割データであっても、上記時点においてすでにマルチキャスト配信されてしまっている場合がある。
上記の構成によれば、本発明に係るコンテンツ再生装置は、このような場合にマルチキャスト配信を受けて取得できなかった、上記特定される配信時刻が上記タイマーが指し示す時刻以降である分割データであってすでにマルチキャスト配信された分割データをユニキャスト通信により取得する。
したがって、本発明に係るコンテンツ再生装置は、コンテンツデータの再生中に一部の分割データを再生できなくなる再生の不具合を防ぐことができるというさらなる効果を奏する。
上記配信サーバは、上記複数の時分割データの各々について、該時分割データを分割することにより得られる複数の部分データが個別に格納された複数のＲＴＰパケットであって各ＲＴＰパケットに該時分割データを識別するための識別子が格納された複数のＲＴＰパケットをマルチキャスト配信するように構成されており、本発明に係るコンテンツ再生装置は、上記第２取得手段が、上記再生指示を受け付けた時点以降にマルチキャスト配信される複数のＲＴＰパケットを上記配信サーバから取得するように構成されており、上記第１取得手段が、上記第２取得手段が最初に取得したＲＴＰパケットに含まれる識別子から識別される時分割データをユニキャスト通信により上記配信サーバから取得するように構成されており、上記再生手段が、上記第１取得手段が取得した時分割データを再生してから、上記第２取得手段が取得した複数のＲＴＰパケットから複数の時分割データを生成して再生することが望ましい。
上記の構成によれば、本発明に係るコンテンツ再生装置は、上記第１取得手段により取得すべき上記一部の時分割データを、上記第２取得手段が取得したＲＴＰパケットに格納されている上記時分割データを識別するための識別子から特定する。
したがって、本発明に係るコンテンツ再生装置は、上記コンテンツデータに関するメタデータを参照することなく、上記第１取得手段により取得すべき上記一部の時分割データを特定することができるというさらなる効果を奏する。
本発明に係るコンテンツ再生装置は、上記第１取得手段が、上記第２取得手段が最初に取得したＲＴＰパケットに含まれる識別子から識別される時分割データを構成する全部分データのうち、上記第２取得手段が取得した上記複数のＲＴＰパケットのいずれにも格納されていない一部の部分データのみを取得するように構成されており、上記再生手段が、上記一部の部分データを構成する１以上の部分データを順次再生してから、上記第２取得手段が取得した複数のＲＴＰパケットに格納されている各部分データを順次再生することが望ましい。
上記の構成によれば、本発明に係るコンテンツ再生装置は、第１取得手段が取得した一部の部分データを再生してから、上記識別子から識別される時分割データの残りの部分データを再生し、その後の時分割データを順次再生する。
したがって、本発明に係るコンテンツ再生装置は、上記識別子から識別される時分割データ全体を取得することなく、再生すべきコンテンツデータを再生することができるというさらなる効果を奏する。
上記コンテンツ再生装置と、該コンテンツ再生装置に対してコンテンツデータを配信可能に該コンテンツ再生装置と接続されている上記配信サーバと、を含んでいる配信システムも本発明の範疇に含まれる。
また、本発明に係るコンテンツ再生装置としてコンピュータを動作させるプログラムであって、コンピュータを上記の各手段として機能させることを特徴とするプログラム、および、そのようなプログラムを記録した、コンピュータが読み取り可能な記録媒体も本発明の範疇に含まれる。
さらに、複数の分割データに時分割して配信されるコンテンツデータであって配信サーバがユニキャスト通信およびマルチキャスト配信の両配信方式により配信可能なコンテンツデータに関するメタデータのデータ構造であって、上記複数の分割データの各々について上記配信サーバが該分割データをマルチキャスト配信する配信時刻と、上記配信サーバから該分割データをユニキャスト通信により取得するために参照すべきＵＲＬと、が特定可能に記載されていることを特徴とするデータ構造も本発明の範疇に含まれる。
さらに、配信サーバが複数の時分割データに時分割して配信されるコンテンツデータを少なくとも１以上の配信用データを用いて配信する場合における該配信用データのデータ構造であって、１以上の上記時分割データの各々について、該時分割データと該時分割データを識別するための識別子とが関連づけて記録されていることを特徴とする配信用データのデータ構造も本発明の範疇に含まれる。
本発明に係るコンテンツ取得装置は、再生装置などに広く適用することができる。
５ａ、５ｂ ＭＰＤデータ
１００、１００’、１００” 再生装置（コンテンツ再生装置）
１１０、１１０’、１１０” 通信制御部（第１取得手段、第２取得手段、第３取
得手段、時刻監視手段、時刻参照手段、判定手段、
重複取得判定手段）
１２０ 再生部（再生手段）
１３０ 記憶部
１４０ ネットワーク・Ｉ／Ｆ
１５０ 表示部
１６０ 内蔵時計部（タイマー）
２００ マルチキャストルータ
３００、３００’、３００” 配信サーバ
４００ ネットワークストレージサーバ（ＮＡＳ）

Claims (14)

  1. 再生指示をユーザから受け付けると、再生すべきコンテンツデータが時分割された複数の時分割データを配信サーバから取得しながら順次再生するコンテンツ再生装置において、
    上記複数の時分割データのうち、上記配信サーバがすでにマルチキャスト配信した一部の時分割データをユニキャスト通信により上記配信サーバから取得する第１取得手段と、
    上記複数の時分割データのうち、上記一部の時分割データに続けて再生すべき残りの時分割データを上記配信サーバからマルチキャスト配信を受けて取得する第２取得手段と、
    上記第１取得手段が最初に取得した時分割データを、上記複数の時分割データの中で最初に再生する再生手段と、を備えていることを特徴とするコンテンツ再生装置。
  2. 請求項１に記載のコンテンツ再生装置であって、
    上記時分割データは相異なる複数の品質の再生対象データから構成されており、
    上記再生手段は、上記複数の時分割データの各々について、該時分割データを構成するいずれかの品質の再生対象データを配信サーバから取得しながら順次再生するように構成されていることを特徴とするコンテンツ再生装置。
  3. 請求項１または２に記載のコンテンツ再生装置であって、
    上記第１取得手段は、上記第２取得手段が上記残りの時分割データを取得する処理を開始する時点以前に、上記一部の時分割データを取得する処理を開始するように構成されていることを特徴とするコンテンツ再生装置。
  4. 請求項３に記載のコンテンツ再生装置であって、
    上記コンテンツデータに関するメタデータであって、上記複数の時分割データの各々について上記配信サーバが該時分割データをマルチキャスト配信する配信時刻を該コンテンツ再生装置が特定可能なメタデータを、該コンテンツデータの取得に先駆けて取得する第３取得手段と、
    タイマーが指し示す時刻を監視する時刻監視手段と、をさらに備え、
    上記第１取得手段は、上記メタデータから特定した各時分割データの配信時刻に基づいて、上記再生指示を受け付けたときに上記タイマーが指し示す時刻の直近でマルチキャスト配信された上記一部の時分割データを取得するように構成されており、
    上記第２取得手段は、上記メタデータから特定した上記配信時刻に基づいて、上記第１取得手段が上記一部の時分割データを取得する処理を開始してから最初に時分割データが配信される配信時刻を上記タイマーが指し示したときに、上記残りの時分割データを取得する処理を開始することを特徴とするコンテンツ再生装置。
  5. 請求項４に記載のコンテンツ再生装置であって、
    上記残りの再生対象データに加えて、上記第１取得手段により取得される上記一部の時分割データを構成する１以上の時分割データの少なくともいずれかを上記第２取得手段が重複取得するか否かを判定する重複取得判定手段をさらに備え、
    上記複数の時分割データの各々について、上記時分割データには該時分割データを識別するための識別値が関連づけられているとともに、上記メタデータには、該時分割データを識別するための識別値が含まれており、
    上記重複取得判定手段は、上記配信時刻を上記タイマーが指し示した後に上記第２取得手段が取得する最初の時分割データに関連づけられている識別値が、上記配信時刻に配信されると上記メタデータから特定可能な時分割データの識別値よりも小さい場合に限り、上記第２取得手段が重複取得すると判定するように構成されており、
    上記重複取得判定手段が上記１以上の時分割データの少なくともいずれかが上記第２取得手段により取得されると判定した場合に、上記再生手段は、上記第１取得手段および上記第２取得手段の双方により取得された同一の時分割データの一方を再生しないことを特徴とするコンテンツ再生装置。
  6. 請求項４に記載のコンテンツ再生装置であって、
    上記コンテンツデータに関するメタデータであって、上記複数の時分割データの各々について上記配信サーバが該時分割データをマルチキャスト配信する配信時刻を該コンテンツ再生装置が特定可能なメタデータを、該コンテンツデータの取得に先駆けて取得する第３取得手段と、
    タイマーが指し示す時刻を参照する時刻参照手段と、
    上記メタデータから特定される配信時刻が上記再生指示を受け付けた時点において上記タイマーが指し示す時刻以降となるような時分割データのうち、すでにマルチキャスト配信された時分割データが存在するか否かを判定する判定手段と、をさらに備え、
    上記複数の時分割データの各々について、上記時分割データには該時分割データを識別するための識別値が関連づけられているとともに、上記メタデータには、該時分割データを識別するための識別値が含まれており、
    上記判定手段は、上記配信時刻を上記タイマーが指し示した後に上記第２取得手段が取得する最初の時分割データに関連づけられている識別値が、上記配信時刻に配信されると上記メタデータから特定可能な時分割データの識別値よりも大きい場合に限り、すでにマルチキャスト配信された時分割データが存在すると判定するように構成されており、
    上記第１取得手段は、上記メタデータから特定される配信時刻が上記タイマーの指し示す時刻以前である時分割データだけでなく、上記特定される配信時刻が上記タイマーの指し示す時刻以降である時分割データであってすでにマルチキャスト配信された時分割データを、ユニキャスト通信により取得することを特徴とするコンテンツ再生装置。
  7. 請求項１に記載のコンテンツ再生装置であって、
    上記配信サーバは、上記複数の時分割データの各々について、該時分割データを分割することにより得られる複数の部分データが個別に格納された複数のＲＴＰパケットであって各ＲＴＰパケットに該時分割データを識別するための識別子が格納された複数のＲＴＰパケットをマルチキャスト配信するように構成されており、
    上記第２取得手段は、上記再生指示を受け付けた時点以降にマルチキャスト配信される複数のＲＴＰパケットを上記配信サーバから取得するように構成されており、
    上記第１取得手段は、上記第２取得手段が最初に取得したＲＴＰパケットに含まれる識別子から識別される時分割データをユニキャスト通信により上記配信サーバから取得するように構成されており、
    上記再生手段は、上記第１取得手段が取得した時分割データを再生してから、上記第２取得手段が取得した複数のＲＴＰパケットから複数の時分割データを生成して再生することを特徴とするコンテンツ再生装置。
  8. 請求項７に記載のコンテンツ再生装置であって、
    上記第１取得手段は、上記第２取得手段が最初に取得したＲＴＰパケットに含まれる識別子から識別される時分割データを構成する全部分データのうち、上記第２取得手段が取得した上記複数のＲＴＰパケットのいずれにも格納されていない一部の部分データのみを取得するように構成されており、
    上記再生手段は、上記一部の部分データを構成する１以上の部分データを順次再生してから、上記第２取得手段が取得した複数のＲＴＰパケットに格納されている各部分データを順次再生することを特徴とするコンテンツ再生装置。
  9. 請求項１から８のいずれか１項に記載のコンテンツ再生装置と、該コンテンツ再生装置に対してコンテンツデータを配信可能に該コンテンツ再生装置と接続されている上記配信サーバと、を含んでいることを特徴とする配信システム。
  10. 再生指示をユーザから受け付けると、再生すべきコンテンツデータが時分割された複数の時分割データを配信サーバから取得しながら順次再生するコンテンツ再生装置のコンテンツ再生方法において、
    上記複数の時分割データのうち、上記配信サーバがすでにマルチキャスト配信した一部の時分割データをユニキャスト通信により上記配信サーバから取得する第１取得工程と、
    上記複数の時分割データのうち、上記一部の分割データに続けて再生すべき残りの時分割データを上記配信サーバからマルチキャスト配信を受けて取得する第２取得工程と、
    上記第１取得工程にて最初に取得した分割データを、上記第１取得工程および上記第２取得工程を通じて取得した上記複数の時分割データの中で最初に再生する再生工程と、を含んでいることを特徴とするコンテンツ再生方法。
  11. 請求項１から８のいずれか１項に記載のコンテンツ再生装置としてコンピュータを動作させるプログラムであって、コンピュータを上記各手段として機能させるためのコンテンツ再生プログラム。
  12. 請求項１１に記載のコンテンツ再生プログラムが記録されているコンピュータ読み取り可能な記録媒体。
  13. 複数の時分割データに時分割して配信されるコンテンツデータであって配信サーバがユニキャスト通信およびマルチキャスト配信の両配信方式により配信可能なコンテンツデータに関するメタデータのデータ構造であって、
    上記複数の時分割データの各々について上記配信サーバが該時分割データをマルチキャスト配信する配信時刻と、上記配信サーバから該時分割データをユニキャスト通信により取得するために参照すべきＵＲＬと、が特定可能に記載されていることを特徴とするデータ構造。
  14. 配信サーバが複数の時分割データに時分割して配信されるコンテンツデータを少なくとも１以上の配信用データを用いて配信する場合における該配信用データのデータ構造であって、
    １以上の上記時分割データの各々について、該時分割データと該時分割データを識別するための識別子とが関連づけて記録されていることを特徴とする配信用データのデータ構造。
JP2012552767A 2011-01-14 2012-01-13 コンテンツ再生装置、コンテンツ再生方法、配信システム、コンテンツ再生プログラム、記録媒体、およびデータ構造 Pending JPWO2012096372A1 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2011005639 2011-01-14
JP2011005639 2011-01-14
PCT/JP2012/050583 WO2012096372A1 (ja) 2011-01-14 2012-01-13 コンテンツ再生装置、コンテンツ再生方法、配信システム、コンテンツ再生プログラム、記録媒体、およびデータ構造

Publications (1)

Publication Number Publication Date
JPWO2012096372A1 true JPWO2012096372A1 (ja) 2014-06-09

Family

ID=46507263

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2012552767A Pending JPWO2012096372A1 (ja) 2011-01-14 2012-01-13 コンテンツ再生装置、コンテンツ再生方法、配信システム、コンテンツ再生プログラム、記録媒体、およびデータ構造

Country Status (4)

Country Link
US (1) US20130294747A1 (ja)
EP (1) EP2665261A4 (ja)
JP (1) JPWO2012096372A1 (ja)
WO (1) WO2012096372A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10212208B2 (en) 2013-06-06 2019-02-19 Saturn Licensing Llc Content supply device, content supply method, program, and content supply system

Families Citing this family (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9948989B1 (en) * 2004-07-21 2018-04-17 Cox Communications, Inc. Interactive media content listing search and filtering system for a media content listing display system such as an electronic programming guide
JP2013021574A (ja) * 2011-07-12 2013-01-31 Sharp Corp 生成装置、配信サーバ、生成方法、再生装置、再生方法、再生システム、生成プログラム、再生プログラム、記録媒体およびデータ構造
JP2013038766A (ja) * 2011-07-12 2013-02-21 Sharp Corp 送信装置、送信装置の制御方法、制御プログラム、及び記録媒体
US9591361B2 (en) * 2011-09-07 2017-03-07 Qualcomm Incorporated Streaming of multimedia data from multiple sources
US9438883B2 (en) * 2012-04-09 2016-09-06 Intel Corporation Quality of experience reporting for combined unicast-multicast/broadcast streaming of media content
CN104704793B (zh) * 2012-08-14 2018-05-25 瑞典爱立信有限公司 用于多媒体数据的处理的方法和装置
JP6348251B2 (ja) * 2012-09-13 2018-06-27 サターン ライセンシング エルエルシーＳａｔｕｒｎ Ｌｉｃｅｎｓｉｎｇ ＬＬＣ 端末装置、受信方法、およびプログラム
US8923880B2 (en) * 2012-09-28 2014-12-30 Intel Corporation Selective joinder of user equipment with wireless cell
US9544344B2 (en) * 2012-11-20 2017-01-10 Google Technology Holdings LLC Method and apparatus for streaming media content to client devices
WO2014109321A1 (ja) * 2013-01-09 2014-07-17 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
EP2946539B1 (en) * 2013-01-17 2020-09-02 Intel IP Corporation Dash-aware network application function (d-naf)
WO2014148277A1 (ja) * 2013-03-19 2014-09-25 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
JP2014230055A (ja) * 2013-05-22 2014-12-08 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、プログラム、およびコンテンツ供給システム
JP2014239291A (ja) 2013-06-06 2014-12-18 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
EP3018912B1 (en) 2013-07-02 2018-09-12 Sony Corporation Content provision device, content provision method, program, terminal device, and content provision system
JP6505996B2 (ja) 2013-08-30 2019-04-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 受信方法、及び、受信装置
JP6268066B2 (ja) 2013-09-20 2018-01-24 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ 送信方法、受信方法、送信装置及び受信装置
US20150113101A1 (en) * 2013-10-21 2015-04-23 Electronics And Telecommunications Research Institute Method and apparatus for providing streaming content
JP6466850B2 (ja) * 2013-10-28 2019-02-06 サターン ライセンシング エルエルシーＳａｔｕｒｎ Ｌｉｃｅｎｓｉｎｇ ＬＬＣ コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
EP3063943B1 (en) * 2013-11-01 2019-08-21 LG Electronics Inc. Apparatus for transmitting and method for transmitting broadcast signals
CN103702203A (zh) * 2013-12-13 2014-04-02 北京厚睿技术有限公司 播放流媒体时对附加内容的播放控制方法和系统
GB2521845B (en) * 2014-01-03 2021-07-07 British Broadcasting Corp Content delivery
CN103974147A (zh) * 2014-03-07 2014-08-06 北京邮电大学 一种基于mpeg-dash协议的带有码率切换控制和静态摘要技术的在线视频播控系统
JP2017517221A (ja) * 2014-03-20 2017-06-22 サムスン エレクトロニクス カンパニー リミテッド Ｈｔｔｐストリーミングを使用するｄａｓｈストリーミングのための方法及び装置
CN106233735B (zh) 2014-03-31 2020-10-02 英国电讯有限公司 管理多播视频传送的方法
EP3127333A1 (en) * 2014-03-31 2017-02-08 British Telecommunications Public Limited Company Multicast streaming
WO2015178690A1 (ko) * 2014-05-21 2015-11-26 엘지전자 주식회사 방송 신호 송/수신 처리 방법 및 장치
KR20150134861A (ko) * 2014-05-23 2015-12-02 삼성전자주식회사 서버 장치, 디스플레이 장치, 시스템 및 그 제어 방법
WO2016136489A1 (ja) * 2015-02-27 2016-09-01 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
US10432688B2 (en) 2015-03-13 2019-10-01 Telefonaktiebolaget Lm Ericsson (Publ) System and method for optimized delivery of live ABR media
US10735823B2 (en) 2015-03-13 2020-08-04 Telefonaktiebolaget Lm Ericsson (Publ) System and method for optimized delivery of live ABR media
CN107483970B (zh) 2016-06-08 2020-09-18 华为技术有限公司 一种确定热门直播视频的方法及设备
JP7403957B2 (ja) * 2019-03-06 2023-12-25 キヤノン株式会社 通信装置、通信方法及びプログラム
US11611784B2 (en) 2019-08-02 2023-03-21 Dao Lab Limited System and method for transferring large video files with reduced turnaround time
GB2586071B (en) * 2019-08-02 2023-05-10 Dao Lab Ltd System and method for transferring large video files with reduced turnaround time
JP7462199B1 (ja) 2023-06-14 2024-04-05 株式会社インフォシティ 番組受信表示装置及び番組受信表示制御方法

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040220791A1 (en) * 2000-01-03 2004-11-04 Interactual Technologies, Inc. A California Corpor Personalization services for entities from multiple sources
US20050193408A1 (en) * 2000-07-24 2005-09-01 Vivcom, Inc. Generating, transporting, processing, storing and presenting segmentation information for audio-visual programs
TWI256250B (en) * 2001-05-10 2006-06-01 Ibm System and method for enhancing recorded radio or television programs with information on the world wide web
US7562375B2 (en) * 2003-10-10 2009-07-14 Microsoft Corporation Fast channel change
JP4534997B2 (ja) * 2006-02-13 2010-09-01 ソニー株式会社 送受信システム、受信装置、受信方法
KR101777347B1 (ko) * 2009-11-13 2017-09-11 삼성전자주식회사 부분화에 기초한 적응적인 스트리밍 방법 및 장치
US9185335B2 (en) * 2009-12-28 2015-11-10 Thomson Licensing Method and device for reception of video contents and services broadcast with prior transmission of data
US9185439B2 (en) * 2010-07-15 2015-11-10 Qualcomm Incorporated Signaling data for multiplexing video components

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10212208B2 (en) 2013-06-06 2019-02-19 Saturn Licensing Llc Content supply device, content supply method, program, and content supply system

Also Published As

Publication number Publication date
WO2012096372A1 (ja) 2012-07-19
EP2665261A4 (en) 2014-10-15
EP2665261A1 (en) 2013-11-20
US20130294747A1 (en) 2013-11-07

Similar Documents

Publication Publication Date Title
WO2012096372A1 (ja) コンテンツ再生装置、コンテンツ再生方法、配信システム、コンテンツ再生プログラム、記録媒体、およびデータ構造
JP6081541B2 (ja) データ伝送方法及び装置
US9277252B2 (en) Method and apparatus for adaptive streaming based on plurality of elements for determining quality of content
US9756364B2 (en) Streaming method and apparatus operating by inserting other content into main content
EP3100464B1 (en) Establishing a streaming presentation of an event
EP2499793B1 (en) Adaptive streaming method and apparatus
KR102120525B1 (ko) 통신 장치, 통신 데이터 생성 방법, 및 통신 데이터 처리 방법
US20120272281A1 (en) Method and apparatus for transmitting media data, and method and apparatus for receving media data
US20140019587A1 (en) Dynamic Adaptive Streaming over Hypertext Transfer Protocol as Hybrid Multirate Media Description, Delivery, and Storage Format
US20130247098A1 (en) Video distribution system, video distribution apparatus, video distribution method and medium
KR102103054B1 (ko) 통신 장치, 통신 데이터 생성 방법, 및 통신 데이터 처리 방법
WO2018103696A1 (zh) 媒体文件的播放方法、服务端、客户端及系统
WO2015064383A1 (ja) 送信装置、送信方法、受信装置、及び、受信方法
KR102085192B1 (ko) 렌더링 시간 제어
WO2015107784A1 (ja) 通信装置、通信データ生成方法、および通信データ処理方法
KR102137858B1 (ko) 송신 장치, 송신 방법, 수신 장치, 수신 방법 및 프로그램
JP6492006B2 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、および、コンテンツ供給システム
US20190014366A1 (en) Transmission apparatus, reception apparatus, and data processing method
JP2015136058A (ja) 通信装置、通信データ生成方法、および通信データ処理方法
WO2013039042A1 (ja) 再生装置、再生方法、配信装置、配信システム、再生プログラムおよび記録媒体
KR20160042426A (ko) 멀티미디어 플레이어에 의한, mbms 서비스에 의해서 전송된 멀티미디어 콘텐츠 아이템의 프로세싱 동안의 동기화 방법
JP2012253615A (ja) ネットワーク型録画システム

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150113

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150113

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160412

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20161018