送信装置、送信装置の制御方法、制御プログラム、及び記録媒体
【課題】１つのコンテンツのエンコードが完了する前の段階において、そのコンテンツのエンコードが完了している部分については切り替えを可能にする。
【解決手段】サーバ２は、複数のセグメントデータ２７について予め定めたサブセグメントデータまでエンコードが進んだときに、該サブセグメントデータで再生対象のコンテンツを切り替えるためのインデックス情報２８を生成するインデックス情報生成部２４と、インデックス情報生成部２４が生成したインデックス情報２８をクライアント１に取得させるエンコーダ２３とを備えている。
【解決手段】サーバ２は、複数のセグメントデータ２７について予め定めたサブセグメントデータまでエンコードが進んだときに、該サブセグメントデータで再生対象のコンテンツを切り替えるためのインデックス情報２８を生成するインデックス情報生成部２４と、インデックス情報生成部２４が生成したインデックス情報２８をクライアント１に取得させるエンコーダ２３とを備えている。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コンテンツをサーバからクライアントに送信するシステムにおいて、サーバは、異なる符号化パラメータで複数のエンコードを行い、クライアントは、当該コンテンツの受信・再生にあたり、通信環境等の条件に応じて、前記符号化パラメータから適切な再生対象を選択し、当該コンテンツの再生中、前記通信環境の変化に応じて、適切に再生対象を切り替えることを可能とする技術に関する。
【背景技術】
【０００２】
従来から、通信ネットワークを介してコンテンツの提供を行う技術が広く用いられている。例えば、下記の特許文献１には、クライアントからサーバにＨＴＴＰでコンテンツの要求を送信し、クライアントがこの要求に対する応答として受信したコンテンツをストリーミング再生するコンテンツストリーミングサービスシステムが開示されている。
【０００３】
また、このようなシステムの１つとして、現在、ＭＰＥＧ（Moving Picture Experts Group）にて標準化作業が進められている、非特許文献１に示されるＤＡＳＨ(Dynamic Adaptive Streaming over HTTP)があげられる。ＤＡＳＨでは、ＭＰＤデータ（Media Presentation Description）と呼ばれる記述情報（メタデータ）をストリーミング制御に用いる。ＭＰＤデータには、コンテンツの属性、コンテンツを構成するリソースの再生順序などが記述される。クライアントは、ストリーミングサービスの事前あるいはサービス途中に、ＭＰＤデータを受信し、当該ＭＰＤデータを参照して、サーバに要求するリソースを決定する。
【０００４】
このＭＰＤデータは、対象コンテンツの再生期間を複数の再生期間に分割し、分割された再生期間における情報をピリオド（Period）として記述する。また、ピリオド毎に再生されるリソースの情報を示すリプリゼンテーション（Representation）を記述する。１つのピリオドには複数のリプリゼンテーションを記述することができる。つまり、クライアントは、１つの再生期間において、複数のリプリゼンテーションから選択した１つのリプリゼンテーションを再生対象とする。
【０００５】
これにより、例えばビットレートの異なる複数のリプリゼンテーションをＭＰＤデータに記述しておくことにより、クライアントはそのときの通信状況や、自装置の再生能力に応じたビットレートのリプリゼンテーションを選択し、そのリプリゼンテーションで特定されるリソースを取得して再生することができる。
【０００６】
ＤＡＳＨを用いたストリーミング再生動作の詳細について、図１７の例を用いて説明する。図１７は、ＤＡＳＨを用いたストリーミング再生中に、動的にリプリゼンテーションの切り替えを行う例を示す図であり、同図（ａ）はサーバとクライアントの処理の一例を示すタイミングチャートであり、同図（ｂ）はクライアントが使用するＭＰＤデータの一例を示している。
【０００７】
まず同図（ｂ）を用いて、ＭＰＤデータの詳細について説明する。ＭＰＤデータはＸＭＬにて記述されるメタデータである。ＭＰＤデータは、ストリーミング配信全体に係る情報を記述するＭＰＤエレメントをルート要素とし、ＭＰＤエレメントの属性として、ストリーミング配信形態（type）、ストリーミング再生開始に必要な最小バッファ時間（minBufferTime）、ストリーミング配信の開始時刻（availabilityStartTime）が記述されている。さらに、ＭＰＤエレメントは子要素として前述のピリオドを示すPeriodエレメントを（図示の例では１つ）有している。
【０００８】
ピリオドは、前述のリプリゼンテーションを示すRepresentationエレメントを（図示の例では２つ）有している。１つのピリオド中に含まれる複数のリプリゼンテーションは、当該ピリオドにおける再生対象の選択肢を示す。言い換えれば、同一ピリオドに含まれる複数のリプリゼンテーションは、その何れかを選択して再生可能であることを示している。
【０００９】
また、各リプリゼンテーションは、そのリプリゼンテーションに対応する再生対象の属性を有する。リプリゼーションが持つことのできる属性には、コーデック、ビットレート、フレームレート、解像度等の当該再生対象の符号化条件に関する情報（特にコンテンツの再生に関する情報）を記述することができ、クライアントは、これらの属性を参照して、リプリゼンテーションを選択する。
【００１０】
例えば、ある映像コンテンツについて、コーデック、ビットレート、フレームレート、解像度等が異なる複数のリプリゼンテーションが記述されている場合には、クライアントは、自機の再生可能なコーデック、ビットレート、フレームレート、解像度等に応じたリプリゼンテーションを選択する。
【００１１】
図示の例では、属性として、そのリプリゼンテーションの識別子（id）、データ形式を示すＭＩＭＥタイプ（mimeType）、及びビットレート（図では当該リプリゼンテーションをストリーミング再生するために必要なネットワークバンド幅：bandwidth）が記述されている。
【００１２】
またピリオドには、SegmentInfoDefaultエレメントおよびSegmentInfoエレメントを用いてセグメントデータに関する情報が記述される。なお、セグメントデータとは、１つのＵＲＬ（Uniform Resource Locator）で指定される再生対象コンテンツの構成リソースのアクセス単位である。図示の例では、SegmentInfoDefaultエレメントに、当該ピリオドに含まれる全てのセグメントデータに対して適用されるパラメータの規定値が記述されており、各セグメントデータの再生期間（duration）が記述されている。また、前述のリプレゼンテーション毎に、SegmentInfoエレメントが記述され、SegmentInfoエレメントの子要素であるUrlエレメントに各セグメントデータのＵＲＬが記述されており、クライアントは当該ＵＲＬにアクセスすることで選択したリプレゼンテーションを構成するセグメントデータを取得することができる。
【００１３】
図示の例では、各リプリゼンテーションのそれぞれに複数のＵＲＬが記述されており、各ＵＲＬで取得されるセグメントデータの再生期間は、前述のSegmentInfoDefaultエレメントに記載された再生期間が適用され１０秒である。つまり、SegmentInfoエレメント内に記述された一番目のＵＲＬは、ストリーミング再生開始直後からの１０秒間（０秒から１０秒）のセグメントデータに対応し、二番目のＵＲＬは再生期間が１０秒から２０秒までのセグメントデータに対応し、三番目のＵＲＬは再生期間２０秒から３０秒までのセグメントデータに対応している。
【００１４】
ここで、図示のように、各リプリゼンテーションの属性には異なる値が記述されている。すなわち、一番目のリプリゼンテーションでは、ＭＩＭＥタイプにＭＰＥＧ２-ＴＳ（ISO/IEC 13818）を示す"video/mpeg2ts"が記述され、バンド幅が"1024000"と記述されているのに対し、二番目のリプリゼンテーションでは、ＭＩＭＥタイプは一番目のリプリゼンテーションと同じvideo/mpeg2ts"が記述されているが、バンド幅が"102400"と記述されている。
【００１５】
したがって、クライアントは、このＭＰＤデータを用いた場合、バンド幅が"1024000"のＭＰＥＧ２−ＴＳ、またはバンド幅が"102400"のＭＰＥＧ２−ＴＳからなるリプリゼンテーションの何れかを選択することができる。これらのリプリゼンテーションの内容は同一の映像コンテンツあるため、バンド幅に余裕があり、高品質な映像を取得したいときは一番目のリプリゼンテーションを選択し、バンド幅に余裕がないとき等は二番目のリプリゼンテーションを選択すればよい。なお、図示の例では、セグメントデータとして、ＭＰＥＧ２−ＴＳを用いる場合について例示したが、ＤＡＳＨでは、セグメントデータとして、ＭＰ４を用いることも可能である。
【００１６】
同図（ａ）は、このＭＰＤデータを用いてコンテンツを再生する処理の流れを示している。図示のように、まずクライアントは、サーバにＭＰＤデータの取得要求を送信し、サーバはこの要求に応じてクライアントにＭＰＤデータを送信する。
【００１７】
次に、このＭＰＤデータを取得したクライアントは、ＭＰＤデータに記述されているリプリゼンテーションの中から１つのリプリゼンテーションを選択し、選択したリプリゼンテーションに含まれるＵＲＬを用いてセグメントデータの取得要求を行う。この例では、一番目のリプリゼンテーションを選択し、その一番目のＵＲＬを用いて"Sample-div1.ts"を要求する。なお、ＭＰＤデータに記載されたとおり、ストリーミング配信の開始時刻（availabilityStartTime）に合わせて、当該セグメントデータの取得要求は行われる。つまり図示の例では、2011年5月1日12:00に、"Sample-div1.ts"の取得要求が行われる。
【００１８】
この要求を受信したサーバは、要求されたセグメントデータをクライアントに送信する。
なお、セグメントデータは、複数のＩＰパケットに分割されて、順次クライアントに送信され、送信開始から送信完了に要する時間は、クライアントとサーバを結ぶネットワークのトラフィック等で変化する。
【００１９】
クライアントは、セグメントデータの受信を開始し、ＭＰＤデータに記述されているストリーミング再生開始に必要な最小バッファ時間（minBufferTime）、図示の例では再生期間６秒に相当するセグメントデータを受信した時点で、再生を開始する。
【００２０】
また、"Sample-div1.ts"の受信が完了した時点で、クライアントは後続の"Sample-div2.ts"の取得要求を行い、サーバはこの要求に応じて"Sample-div2.ts"のデータをクライアントに送信する。そして、クライアントはこの受信したセグメントデータを、”Sample-div1.ts”の再生完了後に再生する。
【００２１】
ここで、トラフィックの増大等の要因により、クライアント、サーバ間のスループットが低下し、セグメントデータ受信が遅延したとする。遅延が長時間に渡ると、バッファリングによる再生中断が頻発するようになり、コンテンツの視聴が困難になるので、クライアントは、セグメントデータの切り替えが必要と判断する。同図（ｂ）のＭＰＤデータには、二番目のリプリゼンテーションに必要なバンド幅のより小さいセグメントデータが含まれているので、クライアントは２番目のリプリゼンテーションに再生対象を切り替えることを判断する。
【００２２】
クライアントは、再生期間０秒から２０秒に相当する、”Sample1-div1.ts”、”Sample1-div2.ts”の取得要求を既に行っているため、”Sample1-div2.ts”の受信完了後、２番目のリプリゼンテーションの再生期間２０秒から３０秒のセグメントに相当する、"Sample2-div3.ts"を取得して”sample1-div2.ts”の再生完了後、再生する。以降、２番目のリプリゼンテーションを構成するセグメントデータを順次、受信し再生する。
【００２３】
このようにＤＡＳＨでは、ネットワーク状況に応じて、動的にセグメントデータ単位でリプリゼンテーションを切り替える、アダプティブストリーミングが可能である。
【００２４】
しかしながら、上述のアダプティブストリーミングを実現するためには、時々刻々と変化するネットワークトラフィックの変化に対応するため、変化の大きいネットワークでは、短期間でリプリゼンテーションの切り替えが可能である必要がある。言い換えれば、リプリゼンテーションの切り替え単位である、セグメントデータの再生期間は、充分に短い（例えば２秒）必要がある。
【００２５】
なお、セグメントデータの再生期間を短く設定することは、ＭＰＤデータのデータ量が増大する問題がある。また、コンテンツを再生する際、セグメント取得要求によって生じるネットワークトラフィックが増大する問題がある。
【００２６】
このような問題を解決するために、１つのセグメントデータの再生期間を短く設定する代わりに、セグメントデータを複数のサブセグメントデータに分割し、各サブセグメントデータを参照するためのインデックス情報を記述する方法が提案されている。なお、サブセグメントデータは、セグメントデータを物理的に分割したものではなく、セグメントデータの一部分を、インデックス情報によってサブセグメントデータとして参照可能にしたものである。つまり、インデックス情報はセグメントデータの論理的な分割位置を示す制御情報と言える。
【００２７】
これについて、図１８から図２０に基づいて説明する。図１８は、インデックス情報を用いて、前述の図１７で例示したストリーミングを実現するＭＰＤデータの例である。図１７（ｂ）のＭＰＤデータと同様、２つのリプリゼンテーションが含まれているが、それぞれのリプリゼンテーションには、セグメントデータが１つだけ含まれている。セグメントデータ”sample1.ts”は、図１７のセグメントデータ ”sample1-div1.ts”から”sample1-div180.ts”が連結されたデータあり、セグメントデータ”sample2.ts”は、図１７のセグメントデータ ”sample2-div1.ts”から”sample2-div180.ts”が連結されたデータあり、SegmentInfoDefaultエレメントのduration属性が示す通り、再生期間３０分が設定されている。また、各セグメントデータのインデックス情報を参照するために記述されたIndexエレメントがSegmentInfoエレメントと対になる形で記述されている。このIndexエレメントには、インデックス情報にアクセスするためのＵＲＬが記述されている。
【００２８】
そして、Indexエレメントに記述されたＵＲＬにアクセスすることによって、セグメントデータを論理的に分割したサブセグメントを特定するインデックス情報を取得することができる。
【００２９】
図１９は、図１８で例示した対になるセグメントデータ”sample1.ts”とインデックス情報”index1.mp4”、及びセグメントデータ”sample2.ts”とインデックス情報”index2.mp4”の詳細を説明する図である。図示のように、セグメントデータは、サブセグメント１〜Nからなる。セグメントデータ”sample1.ts”のサブセグメント１〜Ｎはそれぞれ、図１７のセグメントデータ ”sample1-div1.ts”〜”sample1-div180.ts”に相当し、セグメントデータ”sample2.ts”のサブセグメント１〜Ｎはそれぞれ、図１７のセグメントデータ ”sample2-div1.ts”〜”sample2-div180.ts”に相当する。
【００３０】
またセグメントデータ”sample1.ts”におけるサブセグメント１、２、…Nのデータサイズはそれぞれ、S1_1,S1_2，…,S1_Nであり、セグメントデータ”sample2.ts”におけるサブセグメント１、２、…Nのデータサイズはそれぞれ、S2_1,S2_2，…,S2_Nであり、各サブセグメント再生期間は１０秒である。
【００３１】
一方、インデックス情報”index１.mp4”、”index2.mp4”には、対象セグメントデータ”Sample１.ts”、”Sample2.ts”のサブセグメント毎のデータサイズ、再生期間、各サブセグメントの先頭がランダムアクセスポイントであるか否かを示すＲＡＰフラグがエントリー情報（図中のエントリー１〜Ｎ）としてそれぞれ記録されている。
【００３２】
なお、ＤＡＳＨにおいて、インデックス情報のデータフォーマットは、セグメントデータのデータフォーマットによらず、ＭＰ４形式が用いられ、上述のエントリー情報を管理するエントリー情報管理領域が、インデックス情報先頭に設けられている。
【００３３】
エントリー情報管理領域には、インデックス情報全体のデータサイズSiおよび、当該インデックス情報に含まれるエントリー情報数（対象セグメントデータに含まれるサブセグメント数）Ｎが記録されている。
【００３４】
したがって、インデックス情報”index1.mp4”、”index2.mp4”を取得することで、クライアントは、対象セグメントデータ内のサブセグメント１〜Ｎの再生期間がそれぞれ、０〜１０秒、１０秒〜２０秒、…１７９０秒〜１８００秒であること、セグメントデータ内のサブセグメント１〜Ｎのバイトオフセットを求めることが可能である。
【００３５】
これにより、例えば図２０（a）に示すようなＨＴＴＰリクエストによって、セグメントデータ“sample2.ts”のサブセグメント２以降、あるいは同図（ｂ）に示すような、バイトレンジ（バイト位置）を指定したＨＴＴＰリクエストによって、サブセグメント３以降を取得することが可能であり、サブセグメント単位でのリプリゼンテーション切り替えを実現できる。
【００３６】
上述のインデックス情報を用いてサブセグメント単位でのリプリゼンテーション切り替え（アダプティブストリーミング）を実現する従来技術においては、（１）ＭＰＤデータを用いたセグメント単位でリプリゼンテーション切り替え（アダプティブストリーミング）を実現する従来技術に比べ、ＭＰＤデータの記述が簡素化される、（２）リプリゼンテーション切り替え時にのみ、インデックス情報およびセグメントデータ（あるいはサブセグメント）の取得要求が発生し、ストリーミング中に生じるＨＴＴＰリクエストによる通信トラフィックを軽減することができる、（３）リプリゼンテーションの切り替えが発生しない場合には、インデックス情報を取得する必要がない等の利点がある。
【先行技術文献】
【特許文献】
【００３７】
【特許文献１】特開２００５−１１０２４４号公報（２００５年４月２１日公開）
【非特許文献】
【００３８】
【非特許文献１】”Information technology-MPEG systems technologies - Part6:Dynamic Adaptive streaming over HTTP(DASH)”、[online]、２０１１年１月２８日、[２０１１年６月３日検索]、ISO/IEC、インターネット<http://www.itscj.ipsj.or.jp/sc29/open/29view/29n11873t.doc>
【発明の概要】
【発明が解決しようとする課題】
【００３９】
その一方で、上記従来技術には、ライブストリーミングに用いた場合に、低遅延での配信を実現できないという問題があった。
【００４０】
具体的には、インデックス情報を利用したサブセグメント単位でのリプリゼンテーション切り替えには、ライブ配信中のセグメントデータに関するインデックス情報が必要となる。しかしながら、前述の通り、インデックス情報には、当該インデックス情報全体のデータサイズや、対象セグメントデータに含まれるサブセグメント数、各サブセグメントのデータサイズ等が含まれており、セグメントデータのエンコードが完了するまでは、生成することができなかった。
【００４１】
したがって、セグメントデータのライブエンコード開始からセグメントデータのライブエンコード完了および当該セグメントデータに対するインデックス情報の生成が完了するまで、セグメントデータおよびインデックス情報の配信開始を遅らせる必要があった。なお、インデックス情報の生成にはほとんど時間を要さないが、セグメントデータのライブエンコード完了には、そのセグメントデータの再生と同じだけの時間を要するので、セグメントデータの再生期間に相当する時間、配信開始を遅らせる必要があったとも言える。
【００４２】
本発明は、上記の問題点に鑑みてなされたものであり、その目的は、低遅延でのライブストリーミングを行うシステムにおいて、１つのセグメントデータのライブエンコード完了を待たず、セグメントデータおよびインデックスデータの配信を開始でき、リプリゼンテーションの切り替え（アダプティプストリーミング）を可能にする送信装置等を提供することにある。
【課題を解決するための手段】
【００４３】
上記の課題を解決するために、本発明の送信装置は、同一の再生期間に対応する複数のコンテンツをエンコードし、エンコードしたコンテンツのうち再生対象として選択されたコンテンツを再生装置に送信する送信装置であって、上記複数のコンテンツについて予め定めた再生位置までエンコードが進んだときに、上記再生期間のうち上記再生位置までの部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成する参照情報生成手段と、上記参照情報生成手段が生成した参照情報を上記再生装置に取得させる参照情報提供手段とを備えていることを特徴としている。
【００４４】
また、本発明の送信装置の制御方法は、上記の課題を解決するために、同一の再生期間に対応する複数のコンテンツをエンコードし、エンコードしたコンテンツのうち再生対象として選択されたコンテンツを再生装置に送信する送信装置の制御方法であって、上記複数のコンテンツについて予め定めた再生位置までエンコードが進んだときに、上記再生期間のうち上記再生位置までの部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成する参照情報生成ステップと、上記参照情報生成ステップで生成した参照情報を上記再生装置に取得させる参照情報提供ステップとを含むことを特徴としている。
【００４５】
上記の構成によれば、複数のコンテンツについて部分再生期間のエンコードが進んだときに、部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成し、これを再生装置に取得させる。
【００４６】
したがって、再生装置は、コンテンツのエンコードが完了するまでの期間に、部分再生期間で再生対象のコンテンツを切り替えることが可能になる。つまり、上記の構成によれば、コンテンツのエンコードが完了するまでの期間に、再生装置に１つの再生期間の途中で再生対象のコンテンツを切り替えさせることができる。
【００４７】
また、再生装置が再生しているコンテンツはエンコードが完了している部分であり、このような部分については参照情報による切り替えが可能となる。よって、上記の構成によれば、再生装置が再生している再生位置におけるコンテンツの切り替えが保証される。
【００４８】
また、上記参照情報生成手段は、コンテンツのエンコードが予め定めた再生位置まで進んだときに、該コンテンツの該再生位置までの部分再生期間のデータサイズを示す参照情報を生成し、その後、後続する予め定めた再生位置までエンコードが進む毎に、該コンテンツの該再生位置とその直前の予め定めた再生位置の間の部分再生期間のデータサイズを示す情報を上記参照情報に追加することが好ましい。
【００４９】
上記の構成によれば、コンテンツのエンコードが予め定めた再生位置まで進んだときに、コンテンツの部分再生期間のデータサイズを示す参照情報を生成し、その後、後続する予め定めた再生位置までエンコードが進む毎に、部分再生期間のデータサイズを示す情報を上記参照情報に追加する。
【００５０】
上記の構成では、エンコードの進行に応じて部分再生期間のデータサイズを示す情報を追加するので、生成された参照情報はエンコード済みの各部分再生期間のデータサイズが示された情報となる。
【００５１】
したがって、上記の構成によって生成された参照情報を用いることによって、部分再生期間で再生対象のコンテンツを切り替えることが可能になる。例えば、１〜３番目までの部分再生期間のデータサイズがそれぞれSz1〜Sz3である場合、２番目の部分再生期間で切り替えるときには、再生装置はSz1以降を指定してコンテンツの要求を行えばよい。
【００５２】
また、上記参照情報は、予め定められた数のエントリーと、該エントリーのうち有効なエントリーを示す有効情報を記述する記述領域とを含む情報であり、上記参照情報生成手段は、コンテンツのエンコードが予め定めた再生位置まで進んだときに、該再生位置までの部分再生期間に対応するエントリーに、該部分再生期間で再生対象のコンテンツを切り替えるための情報を追加すると共に、該エントリーが有効であることを示す有効情報を上記記述領域に記述するものであってもよい。
【００５３】
上記の構成によれば、コンテンツのエンコードが予め定めた再生位置まで進んだときに、該再生位置までの部分再生期間に対応するエントリーに、該部分再生期間で再生対象のコンテンツを切り替えるための情報を追加すると共に、該エントリーが有効であることを示す有効情報を記述領域に記述する。
【００５４】
このような参照情報を取得した再生装置は、その参照情報に含まれているエントリーのうち、何れが有効であるかを有効情報から特定し、有効なエントリーに含まれる情報を用いて、そのエントリーに対応する部分再生期間でコンテンツを切り替えることができる。つまり、上記の構成によれば、有効なエントリーと有効ではないエントリーとを含む参照情報を用いて、再生装置に１つの再生期間の途中で再生対象のコンテンツを切り替えさせることができる。
【００５５】
また、上記送信装置は、上記部分再生期間のコンテンツを、上記再生期間の全体のエンコードが完了する前に送信可能か否かを示す情報を含む記述情報を生成する記述情報生成手段と、上記記述情報生成手段が生成した記述情報を上記再生装置に取得させる記述情報提供手段とをさらに備えていることが好ましい。
【００５６】
上記の構成によれば、部分再生期間のコンテンツを、再生期間の全体のエンコードが完了する前に送信可能か否かを示す情報を含む記述情報を生成し、生成した記述情報を再生装置に取得させる。
【００５７】
したがって、部分再生期間で再生対象のコンテンツを切り替えることのできる配信方式であるか、再生期間全体のエンコードが完了した時点でコンテンツを配信可能にする配信方式であるかをクライアントに適切に認識させることができる。
【００５８】
なお、上記送信装置及び上記再生装置は、コンピュータによって実現してもよく、この場合には、コンピュータを上記送信装置及び上記再生装置の各手段として動作させることにより、上記送信装置及び上記再生装置をコンピュータにて実現させる制御プログラム、及びそれを記録したコンピュータ読み取り可能な記録媒体も本発明の範疇に入る。
【発明の効果】
【００５９】
以上のように、本発明の送信装置は、複数のコンテンツについて予め定めた再生位置までエンコードが進んだときに、再生期間のうち上記再生位置までの部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成する参照情報生成手段と、上記参照情報生成手段が生成した参照情報を再生装置に取得させる参照情報提供手段とを備えている構成である。
【００６０】
また、本発明の送信装置の制御方法は、複数のコンテンツについて予め定めた再生位置までエンコードが進んだときに、再生期間のうち上記再生位置までの部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成する参照情報生成ステップと、上記参照情報生成ステップで生成した参照情報を再生装置に取得させる参照情報提供ステップとを含む構成である。
【００６１】
上記の構成によれば、再生装置は、コンテンツのエンコードが完了するまでの期間に、部分再生期間で再生対象のコンテンツを切り替えることが可能になる。つまり、上記の構成によれば、コンテンツのエンコードが完了するまでの期間に、再生装置に１つの再生期間の途中で再生対象のコンテンツを切り替えさせることができるという効果を奏する。
【図面の簡単な説明】
【００６２】
【図１】本発明の一実施形態にかかるコンテンツ送受信システムに含まれるクライアントとサーバの要部構成を示すブロック図である。
【図２】上記コンテンツ送受信システムで使用するＭＰＤデータの一例を示している。
【図３】インデックス情報とセグメントデータの関係を示す図である。
【図４】サーバにおけるインデックス情報生成部の動作を示すフローチャートである。
【図５】サーバにおけるＭＰＤデータ生成タイミングおよびＭＰＤデータ配信可能タイミングを説明するためのタイミングチャートである。
【図６】サーバにおけるセグメントデータ生成タイミングおよびセグメントデータ配信可能タイミングを説明するためのタイミングチャートである。
【図７】サーバにおけるサブセグメント生成タイミングおよびサブセグメント配信可能タイミングを説明するためのタイミングチャートである。
【図８】サーバにおけるインデックス情報生成タイミングおよびインデックスデータ配信可能タイミングを説明するためのタイミングチャートである。
【図９】サーバにおけるインデックス情報の各エントリー情報の生成タイミングおよび各エントリー情報配信可能タイミングを説明するためのタイミングチャートである。
【図１０】アダプティブストリーミング再生の一例を示すクライアントのタイミングチャートである。
【図１１】通常インデックス情報、階層インデックス情報からなるインデックス情報の構造を示す図である。
【図１２】通常インデックス情報、階層インデックス情報をそれぞれ個別のデータ構造に分離した例を示す図である。
【図１３】通常インデックス情報、階層インデックス情報をそれぞれ独立に参照可能としたＭＰＤデータの記述例である。
【図１４】通常インデックス情報、階層インデックス情報の各エントリーを纏めて記録するデータ構造を持つインデックス情報の例を示す図である。
【図１５】インデックス情報の各エントリーにのエントリーが有効であるか否かを示す情報を記述したインデックス情報の一例を示す図である。
【図１６】有効なエントリーを示す情報を管理領域に記述したインデックス情報の一例を示す図である。
【図１７】アダプティプストリーミング再生の一例を示す図であり、同図（ａ）はサーバとクライアントの処理の一例を示すタイミングチャートであり、同図（ｂ）は当該ストリーミングを制御に用いるＭＰＤデータの一例を示している。
【図１８】インデックス情報を利用可能にするＭＰＤデータの例を示す図である。
【図１９】インデックス情報とセグメントデータの関係を示す図である。
【図２０】インデックス情報を用いたサブセグメント単位でのセグメントデータの部分取得のためのＨＴＴＰリクエストの一例を示す図である。
【図２１】配信方式を識別するためのフラグを含むＭＰＤデータの一例を示す図である。
【図２２】配信方式を識別するためのフラグを含むＭＰＤデータの他の一例を示す図である。
【発明を実施するための形態】
【００６３】
〔実施の形態１〕
以下、本発明の一実施形態について、図１〜図１０に基づいて詳細に説明する。
【００６４】
〔システムの概要〕
まず、本実施形態のコンテンツ送受信システムの概要を図１に基づいて説明する。図１は、本発明の一実施形態を示すものであり、コンテンツ送受信システム３に含まれるクライアント（再生装置）１とサーバ（送信装置）２の要部構成を示すブロック図である。
【００６５】
〔クライアントの構成〕
図示のように、クライアント１は、クライアント１が外部の装置とネットワークを介して通信するためのクライアント通信部１１と、記述情報解析部１２と、コンテンツ再生部１３と、インデックス情報解析部１４を備えている。
【００６６】
クライアント通信部１１は、記述情報解析部１２が選択したリプリゼンテーションを構成するセグメントデータあるいはサブセグメントの取得要求をサーバ２に送信し、これによりセグメントデータあるいはサブセグメントを取得する。また、インデックス情報解析部１４の要求するインデックス情報を取得する。ここでは、クライアント通信部１１が、ＨＴＴＰで要求を送信するものとする。
【００６７】
記述情報解析部１２は、サーバ２に要求可能なリソースを示す情報をコンテンツの再生期間（ピリオド）毎に含むコンテンツの記述情報を取得し、取得した記述情報に従って、再生対象のリプリゼンテーションを選択する。具体的には、記述情報解析部１２は、サーバ２から記述情報としてＭＰＤデータを受信し、再生対象のリプリゼンテーションを決定する。また、コンテンツ再生部１３があるリプリゼンテーションのセグメントデータを再生しているときに、リプリゼンテーションの切り替えが必要となる所定の事象を検出した場合に、検出した事象に応じた他のリプリゼンテーションへ再生対象を切り替える決定を行う。
【００６８】
コンテンツ再生部１３は、クライアント通信部１１の要求によって受信されたセグメントデータあるいはサブセグメントを順に再生する。なお、再生したコンテンツは、クライアント１が備えるディスプレイやスピーカ等から出力してもよいし、クライアント１に有線または無線接続されているディスプレイやスピーカ等から出力してもよい。
【００６９】
インデックス情報解析部１４は、クライアント通信部１１を介して受信したインデックス情報を解析し、解析結果を記述情報解析部１２に通知する。
【００７０】
〔サーバの構成〕
一方、サーバ２は、サーバ通信部（参照情報提供手段、記述情報提供手段）２１と、サーバ記憶部２２と、エンコーダ２３と、インデックス情報生成部（参照情報生成手段）２４と、記述情報生成部（記述情報生成手段）２５と、サーバ制御部２６とを備える。
【００７１】
また、サーバ記憶部２２には、サーバ２にて生成、配信される、セグメントデータ２７と、インデックス情報２８と、記述情報２９とが格納される。
【００７２】
サーバ通信部２１は、クライアント１からの記述情報の取得要求に応じて、記述情報２９をクライアント１に送信する。具体的には、サーバ記憶部２２に格納されている記述情報２９を読み出して、クライアント１に送信する。上述のように、ここでは記述情報２９としてＭＰＤデータを用いる。
【００７３】
またサーバ通信部２１は、同様に、クライアント１からのセグメントデータ２７の取得要求、あるいはインデックス情報２８の取得要求に応じて、サーバ記憶部２２に格納されたセグメントデータ２７あるいはインデックス情報２８を読み出して、クライアント１に送信する。
【００７４】
サーバ制御部２６は、サーバ２にて生成、配信されるデータの生成タイミングおよびデータ生成に必要な配信パラメータ等の情報を、エンコーダ２３、インデックス情報生成部２４、記述情報生成部２５に指示する。
【００７５】
エンコーダ２３は、カメラ等（図示せず）で撮影され、外部からライブ入力されるコンテンツを、サーバ制御部２６にて指示されたリプリゼンテーション毎のエンコード条件（符号化パラメータ）に従って、それぞれエンコードしてセグメントデータ２７を生成し、サーバ記憶部２２に格納する。なお、同一ピリオドにおける複数のリプリゼンテーションは、同時並行でライブエンコードが行われ、リプリゼンテーション毎に１つのセグメントデータ２７が生成される。
【００７６】
インデックス情報生成部２４は、各セグメントデータ２７について、そのセグメントデータ２７に含まれるサブセグメント単位で切り替えを行うためのインデックス情報２８を生成する。なお、インデックス情報２８及びその生成方法の詳細については後述する。
【００７７】
セグメントデータ２７は、前述の通り、クライアント１に提供可能なコンテンツを所定のエンコード条件に従ってエンコードし、所定の再生期間単位で分割したデータである。
【００７８】
インデックス情報２８は、サブセグメントデータでの切り替えを可能にするための情報である。クライアント１は、インデックス情報２８を参照することによってサブセグメントデータの位置を特定し、サブセグメントデータ単位で再生対象を切り替えることができる。
【００７９】
記述情報２９は、サーバ２からクライアント１に提供可能なコンテンツ（ここでは、サーバ記憶部２２に格納されるセグメントデータ２７）に関する情報である。具体的には、記述情報２９は、選択候補を示すリプリゼンテーションがピリオド毎に記述されたＭＰＤデータである。ＭＰＤデータの詳細は後述する。
【００８０】
なお、セグメントデータ２７、インデックス情報２８、及び記述情報２９の少なくとも１つは、サーバ２に着脱可能な外部の記録媒体に記録されていてもよいし、サーバ２がアクセス可能な外部の装置に記憶されていてもよい。すなわち、セグメントデータ２７、インデックス情報２８、及び記述情報２９は、サーバ２が取得可能な状態で格納されていればよく、格納先は特に限定されない。
【００８１】
また、コンテンツ送受信システムが複数のサーバ２によって構成され、セグメントデータ２７、インデックス情報２８、及び記述情報２９のそれぞれが異なるサーバ２から提供される構成であっても構わない。
【００８２】
〔システムで用いるデータの詳細〕
図２はコンテンツ送受信システム３で用いるＭＰＤデータの一例である。ストリーミングの配信形態を示すＭＰＤエレメントのType属性がライブストリーミングである点を除けば前述の図１８のＭＰＤデータと同じであり、詳細な説明を省略する。
【００８３】
図３は図２に示すＭＰＤデータと共にコンテンツ送受信システム３で用いるセグメントデータ及びインデック情報の一例を示す図である。ライブストリーミングでのアダプティブストリーミングを実現するために、サブセグメントの再生期間が前述の図１９に示す例より短い２秒に設定されている点を除き図１９と同じであり、詳細な説明を省略する。
【００８４】
〔サーバ２で行われる処理の詳細〕
次に、コンテンツ送受信システム３におけるサーバ２の動作について、詳細を図４〜９に基づいて説明する。
【００８５】
図４は、コンテンツ送受信システム３において、アダプティブストリーミングを実現するためのインデックス情報を生成するインデックス情報生成部２４の動作を示すフローチャートである。
【００８６】
コンテンツ送受信システム３においてライブストリーミングが開始されると、インデックス情報生成部２４は、インデックス情報におけるエントリー情報管理領域を生成する（Ｓ１）。前述の通り、エントリー情報管理領域には、インデックス情報全体のデータサイズSiとエントリー数（サブセグメント数）Ｎを記述する必要がある。エントリー情報管理領域のデータサイズおよび各エントリーのデータサイズは固定長であるため、セグメントデータに含まれるサブセグメント数が確定していれば、エントリー情報管理領域を生成することができる。
【００８７】
例えば、図２に示したＭＰＤデータを用いたライブ配信を行う場合、ライブストリーミング開始時点で、セグメントデータの再生期間３０分、サブセグメントの再生期間２秒が配信パラメータとして、サーバ制御部２６から入力されることにより、サブセグメント数が１８００に確定されるので、エントリー情報管理領域は即時生成される。
【００８８】
次に、インデックス情報生成部２４は、エントリー生成のため、エンコーダ２３でのサブセグメントエンコード完了を待つ（Ｓ２）。
【００８９】
エンコーダ２３にてサブセグメントのエンコードが完了したことがエンコーダ２３から通知されると、インデックス情報生成部２４は当該サブセグメントに対する新規エントリーを生成（参照情報生成ステップ）し、インデックス情報に追加する（Ｓ３）。なお、エントリーには、サブセグメントのデータサイズ、再生期間、ＲＡＰフラグを記載する。サブセグメントのデータサイズは、サブセグメントのエンコード完了通知時にエンコーダ２３から通知された値が設定される。サブセグメントの再生期間については、サーバ制御部２６からの配信パラメータで与えられた２秒が設定される。なお本システムにおいてサブセグメントは、アダプティブストリーミングを実現する際の、リプリゼンテーションの切り替えポイントであるため、常にランダムアクセスポイントとしてエンコードが行われることから、ＲＡＰフラグは常にＹｅｓが設定される。
【００９０】
生成したエントリー数がＳ１で求めたエントリー数Ｎ未満の場合（Ｓ４でＹｅｓの場合）、Ｓ２に戻って処理を継続し、生成したエントリー数がＮに達した場合（Ｓ４でＮｏの場合、インデックス情報の生成を終了する。
【００９１】
次に、サーバにおける各データの生成タイミングと、当該データの配信可能タイミングに係るサーバ動作を図５〜９を用いて説明する。図５は、サーバ２におけるＭＰＤデータ生成タイミングおよびＭＰＤデータ配信可能タイミングに係る動作を説明するためのタイミングチャートである。
【００９２】
図５において、時刻t0はＭＰＤデータの生成開始時刻である。時刻t0になると、ＭＰＤデータの生成開始のため、サーバ制御部２６が記述情報生成部２５に対し、所定の配信パラメータにて記述情報生成を指示する。記述情報生成部２５は、記述情報生成指示を受け、指定された配信パラメータ（リプリゼンテーション数、配信開始時刻、セグメントの再生期間、サブセグメントの再生期間、最小バッファ時間等）に基づき記述情報を生成する。なお、サーバ制御部２６は、クライアントでのアダプティブストリーミングを実現するため、最小バッファ時間に複数のサブセグメントが含まれるよう配信パラメータを制御する。例えば、図２、図３のデータ構成の場合、最小バッファ時間は６秒に設定されており、サブセグメントの再生期間は２秒に設定されている。記述情報生成部２５は、即時、ＭＰＤデータを生成し、サーバ記憶部２２に生成したＭＰＤデータを格納する。
【００９３】
時刻t0は、クライアント１がＭＰＤデータを取得可能となる時刻でもある。時刻t0に、サーバ通信部２１がクライアント１からのＭＰＤ取得要求を受けると、サーバ記憶部２２に、要求されたＭＰＤデータが存在するか否かを検索する。図５に示す通り、当該検索実行時には、既にＭＰＤデータの生成が完了しており、サーバ通信部２１は、当該ＭＰＤデータをサーバ記憶部２２から読み出し、クライアント１へ送信する。なお、図５において、ＭＰＤ取得要求から応答までに、タイムラグ（Δｔ）が生じているが、このタイムラグΔｔは、ユーザが遅延を体感できるほどに大きなものでなく、充分短い時間である。
【００９４】
なお、サーバ２において、生成されたＭＰＤデータはサーバ記憶部２２に保存されているため、t0以降の任意の時刻tにおいてクライアント１はＭＰＤデータの取得が可能である。
【００９５】
図６は、サーバ２におけるセグメントデータ生成タイミングおよびセグメントデータ配信可能タイミングに係る動作を説明するためのタイミングチャートである。
【００９６】
図６において、時刻t1は、サーバ２におけるライブエンコードの開始時刻である。また図中のセグメントデータ[n,m]は、セグメントデータ内のサブセグメントｎにおけるｍ番目のデータを表している。なおセグメントデータ[n,m]は、入力コンテンツ[n,m]のエンコーダ２３によるエンコード結果である。
【００９７】
時刻t1になると、セグメントデータのライブエンコードのため、サーバ制御部２６がエンコーダ２３に対し、所定の配信パラメータにてエンコード開始を指示する。エンコーダ２３は、指定された配信パラメータ（コーデック、ビットレート、画像サイズ、セグメントの再生期間、サブセグメントの再生期間等）に基づきエンコードを開始する。なお、配信パラメータはリプリゼンテーション毎にエンコーダ２３に与えられる。
【００９８】
エンコーダ２３は、コンテンツの入力があると、複数の配信パラメータで並行してセグメントデータのエンコードを行う。図２の例では、２つのリプリゼンテーションが存在するため、エンコーダ２３は、２つのセグメントデータについて並行してエンコードを行う。なお、図示の通り、コンテンツ[1,1]がエンコーダ２３に入力されると、即時セグメントデータ[1,1]へライブエンコードされ、サーバ記憶部２２に格納される。以降、エンコーダ２３にコンテンツ[1,2]、コンテンツ[1,3]、コンテンツ[1,4]、…と順次コンテンツが入力される毎に、セグメントデータ[1,2]、セグメントデータ[1,3]、セグメントデータ[1,4]、…がエンコードされ、サーバ記憶部２２のセグメントデータに追加される。
【００９９】
また、時刻t1は、セグメントデータの配信開始時刻（図２のＭＰＤデータにおいては、availabilityStartTime属性に設定された、”2011年５月1日12:00”）でもある。前述のＭＰＤデータの場合と同様、時刻t1以降にクライアント１からセグメントデータの取得要求を受けたサーバ通信部２１は、サーバ記憶部２２に要求されたセグメントデータが存在するか否かを検索する。図６に示す通り、サーバ通信部２１は、当該セグメントデータが一部でも存在していれば（図中では検索時にセグメントデータ[1,1]存在）、クライアント１に送信を開始する。以降、残りのセグメントデータが追加される毎に、順次クライアント１に送信する。
【０１００】
図７は、サーバ２におけるサブセグメント生成タイミングおよびサブセグメント配信可能タイミングに係る動作を説明するためのタイミングチャートである。
【０１０１】
図７において、時刻tnは、サブセグメントｎを生成開始される時刻である。図示のとおり、時刻tnにおいて、カメラからサブセグメントnの先頭データであるコンテンツ[n,1]が入力され、当該コンテンツ[n,1]は、エンコーダ２３にてサブセグメントnの先頭データ（セグメントデータ[n,1]）としてエンコードされ、サーバ記憶部２２に格納されたセグメントデータに追記される。
【０１０２】
また、時刻tnは、サブセグメントnの配信開始時刻でもある。前述のセグメントデータの場合と同様に、時刻tn以降にクライアント１からサブセグメントデータnで開始されるセグメントデータの部分取得要求を受けたサーバ通信部２１は、サーバ記憶部２２に要求されたセグメントデータが存在するか否かを検索する。なお、セグメントデータの部分取得要求は、図２０の例で示した通り、セグメントデータの取得開始バイト位置指定によって行われる。従ってサーバ通信部２１は、要求されたセグメントデータが存在する場合、さらに指定された取得開始バイト位置のデータが存在するかを確認し、指定バイト位置のデータが存在すれば、クライアント１に送信を開始する。
【０１０３】
図８は、サーバ２におけるインデックス情報生成タイミングおよびインデックス情報配信可能タイミングに係る動作を説明するためのタイミングチャートである。
【０１０４】
図８において、時刻t1は図６で説明した時刻t1と同時刻を示しており、インデックス情報の生成が開始される時刻である。時刻t1になると、インデックス情報の生成のため、サーバ制御部２６がインデックス情報生成部２４に対し、所定の配信パラメータに基づきインデックス情報生成を指示する。インデックス情報生成部２４は、前述の通り、指定された配信パラメータ（セグメントの再生期間、サブセグメントの再生期間）に基づきインデックス情報の生成を開始する。時刻t1においては、エントリー情報管理領域のみが生成され、サーバ記憶部２２に格納される。なお、インデックス情報もまた、セグメントデータと同様、配信されるリプリゼンテーション数に応じて、複数のインデックス情報が並行して生成される。
【０１０５】
また時刻t1は、インデックス情報の配信開始時刻でもある。つまり時刻t1において、クライアント１は、セグメントデータ、インデックス情報共に受信可能となる。時刻t1以降にクライアント１からインデックス情報の取得要求を受けたサーバ通信部２１は、サーバ記憶部２２に要求されたインデックス情報が存在するか否かを検索する。図８に示す通り、サーバ通信部２１は、当該インデックス情報が一部でも存在していれば（図中では検索時にエントリー情報管理領域のみ存在）、クライアント１に送信を開始する。以降、インデックス情報にエントリーが追加される毎に、順次クライアント１に送信する。
【０１０６】
図９は、サーバ２におけるインデックス情報の各エントリー情報の生成タイミングおよび各エントリー情報配信可能タイミングに係る動作を説明するためのタイミングチャートである。
【０１０７】
図９において、時刻tnは、図７で説明した時刻tnと同時刻（サブセグメントnの生成開始時刻）を示しており、インデックス情報のエントリーn-1が生成される時刻である。
【０１０８】
図示のとおり、エンコーダ２３は、時刻tnにおいて、サブセグメントn-1の生成を完了し、サブセグメントｎの生成を開始する。サブセグメントn-1の生成を完了したエンコーダ２３は、インデックス情報生成部２４にサブセグメントn-1の生成完了を通知する。
【０１０９】
サブセグメントn-1の生成完了の通知を受けたインデックス情報生成部２４は、インデックス情報のエントリーn-1を生成し、サーバ記憶２２に格納されたインデックス情報に追加する。
【０１１０】
また時刻tnは、インデックス情報のエントリn-1の配信開始時刻でもある。図示の通り、tn>tである時刻tにクライアント１からインデックス情報の取得要求を受けた前述のセグメントデータの場合と同様、時刻tn以降にクライアント１からサブセグメントデータnで開始されるセグメントデータの部分取得要求を受けたサーバ通信部２１は、サーバ記憶部２２に要求されたインデックス情報が存在するか否かを検索する。インデックス情報の一部が存在すれば、サーバ通信部２１は、順次データをクライアント１に送信する。
【０１１１】
時刻tnの直前では、インデックス情報としてエントリーn-2までがサーバ記憶部２２に格納されているため、エントリーn-2までの送信が可能である。前述のとおり、時刻tnにおいて、エントリーn-1が生成されサーバ記憶部２２に即時追加される。サーバ通信部２１は、追加されたエントリーn-1を即時クライアント１に送信する。
【０１１２】
以上説明した通り、サーバ２はセグメントデータにおけるサブセグメントnの配信開始時刻tnにおいて、インデックス情報として当該セグメントデータのサブセグメント１〜サブセグメントn-1までの情報をクライアント１に配信することが可能である。
【０１１３】
〔クライアント１で行われる処理の詳細〕
次に、インデックス情報を用いたアダプティブストリーミング再生の詳細について図１０に基づいて説明する。
【０１１４】
図１０は、ストリーミング再生中にリプリゼンテーション切り替えが発生した場合におけるクライアント１の動作を示すタイミングチャートである。
【０１１５】
まずクライアント１は、ＭＰＤデータの配信開時刻t0(図５に示したt0と同時刻)において、記述情報解析部１２が、クライアント通信部１１に対しＭＰＤデータの取得を指示し、クライアント通信部１１が、サーバ２に対し、ＭＰＤデータの取得要求を発行する。
【０１１６】
記述情報解析部１２は、クライアント通信部１１を介して図２に示したＭＰＤデータを受信する。ストリーミング開始時の再生対象として，id=”rep1”で示されるリプリゼンテーションを選択し、ストリーミング開始時刻(t0: 2011年5月1日12:00)になるまで待機する。
【０１１７】
ストリーミング開始時刻t1において、記述情報解析部１２は、クライアント通信部１１に対し、id=”rep1”で示されるリプリゼンテーションを構成するセグメントデータ”sample1.ts”の取得を指示し、クライアント通信部１１が、サーバ２に対し、セグメントデータ”sample1.ts”の取得要求を発行する。
【０１１８】
また記述情報解析部１２は、ＭＰＤデータに記載された最小バッファ時間に基づき、バッファ時間をコンテンツ再生部１３に指示する。図２のＭＰＤデータでは、最小バッファ時間が６秒に設定されているため、この値を指示する。
【０１１９】
サーバ２から受信したセグメントデータ”sample1.ts”は、順次コンテンツ再生部１３に入力される。コンテンツ再生部１３は、受信したセグメントデータの再生期間が指示されたバッファ時間６秒に達するまで、再生を開始せず、バッファリングを行う。
【０１２０】
コンテンツ再生部１３は、受信したセグメントデータの再生期間がバッファ時間６秒に達した時点で、再生を開始する。なおサーバ２においては、時刻t1にコンテンツのライブエンコードが開始されており、コンテンツ再生部１３の再生開始には、ネットワーク状況に関わらず、少なくとも６秒間のバッファリング遅延が発生する。ここでは、最小のバッファリング遅延（６秒）で再生が開始されたものとして以下説明する。
【０１２１】
rep1（sample1.ts）の再生中、クライアントとサーバ間のネットワーク状況が良好で、ストリーミング再生に必要なスループットが確保されている場合には、コンテンツ再生部１３には、常にバッファ時間６秒に相当するセグメントデータがバッファされる。一方、クライアント、サーバ間のスループットが低下し、セグメントデータの受信の遅延が発生した場合、コンテンツ再生部１３にバッファされたセグメントデータ量が減少する。例えば、バッファされたセグメントデータが再生期間４秒分になった時点で、コンテンツ再生部１３は再生遅延を検出し、記述情報解析部１２に通知する。
【０１２２】
遅延の通知を受けた記述情報解析部１２は、rep1よりもストリーミング再生に必要なバンド幅の小さいrep2を選択し、クライアント通信部１１にrep1（sample1.ts)の取得中止を指示すると同時に記述情報解析部１２は、切り替え先のサブセグメントを特定するため、rep2のインデックス情報”index2.mp4”の取得をクライアント通信部１１に指示する。
【０１２３】
サーバ２から取得されたインデックス情報index2.mp4は、インデックス情報解析部１４にて解析され、各サブセグメントに関するデータサイズ、再生期間が解析結果として記述情報解析部１２に通知される。なおインデックス情報取得要求を行った時刻tにおいて、サーバ２では、サブセグメントnのライブエンコード及びライブ配信中であるとき、取得されるインデックス情報にはエントリーn-1までが含まれる。つまり記述情報解析部１２には、サブセグメントn-1までの解析結果が通知される。一方、時刻ｔにおいてコンテンツ再生部１３では、サーバ２の配信から６秒遅延したサブセグメントn-3の再生が行われている。また、コンテンツ再生部１３には、４秒分のセグメントデータがバッファされていることから、サブセグメントn-2およびサブセグメントn-1の一部がバッファされている。
【０１２４】
記述情報解析部１２は、サブセグメントn-1に関するインデックス情報の解析結果の通知を受けた時点で、クライアント通信部１１に対し、インデックス情報”index2.mp4”の取得中止を指示すると同時に、rep2を構成するセグメントデータ”sample2.ts”の部分取得を指示する。なおセグメントデータの取得範囲は、サブセグメントn-1以降のデータであり、インデックス情報の解析結果により、サブセグメントn-1のバイトオフセットが指示される。
【０１２５】
サブセグメントn-1以降の”sample2.ts”の受信が開始されると、コンテンツ再生部１３に順次入力され、既にバッファ済みのrep１（”sample1.ts”）と重複する再生期間のデータについては、デコード処理のみが並行して行われ、表示は行わず破棄される。その後、バッファ済みのrep1(”sample1.ts”)の再生完了時点で、rep2の再生に切り替えストリーミング再生が継続され、ユーザは快適にコンテンツを視聴することができる。
【０１２６】
なお、上述の説明では、高品質なリプリゼンテーションの再生を優先するため、rep1、rep2で重複受信した再生期間のデータについて、並行してデコードする構成としたが、このような構成ではクライアント１には複数のデコーダが必要である。したがって、重複再生期間のデータをre1、rep2共にデコードする代わりに、一部のバッファ済みのrep1のサブセグメントデータn-1を破棄し、サブセグメントn-1のデータについては、rep2のデコードおよび表示を行う構成であっても構わない。
【０１２７】
なお、上記の例では、バンド幅の異なるコンテンツに切り替える例を示したが、切り替え対象となるコンテンツはこのような例に限られない。例えば、コンテンツがマルチアングルの映像で構成される場合、異なるアングルのコンテンツにシームレスに切り替えを行ってもよい。また、上記の例では、対応する再生位置に切り替える例を示したが、インデックス情報から特定できる範囲であれば、これ以外の再生位置に切り替えてもよい。つまり、インデックス情報から特定できる範囲におけるタイムシフト再生を行ってもよい。
【０１２８】
以上説明したように、本実施形態のコンテンツ配信システムにおいては、インデックス情報を用いたアダプティブストリーミングが可能であり、ＭＰＤデータの簡素化が実現できる。
【０１２９】
またクライアントは、リプリゼンテーションの切り替え発生時にのみ、インデックス情報及びセグメントデータの取得要求を行うので、ストリーミング中に生じるＨＴＴＰリクエスト回数および通信トラフィックを軽減することができ、クライアント、サーバ間のネットワーク状況が良好で、リプリゼンテーションの切り替えが発生しない場合には、ストリーミング再生開始以降、一切のＨＴＴＰリクエストが不要である。
【０１３０】
またコンテンツはリプリゼンテーション毎に単一のセグメントデータとして提供されるので、ＭＰＤデータやインデックス情報の解析機能を有しない（アダプティブストリーミング機能を有しない）クライアント、例えばＷｅｂブラウザが、当該セグメントデータのＵＲＬの通知を受け、再生を行うことも可能である。
【０１３１】
〔配信方式の選択〕
また、サブセグメント及び／又はエントリーの生成（エンコード）が完了したタイミングでそれらのデータを配信可能とする配信方式（上述の実施形態での配信方式）と、セグメントデータに含まれる全てのサブセグメント及び／又はインデックス情報に含まれる全てのエントリーの生成（エンコード）が完了したタイミングでそれらのデータを配信可能とする配信方式とを選択可能にし、ＭＰＤデータによってこれらの配信方式を識別できるようにしてもよい。
【０１３２】
ここでは、複数の配信方式を識別する方法について、図２１に基づいて説明する。図２１は、配信方式を識別するためのフラグを含むＭＰＤデータの一例を示す図である。
【０１３３】
図示のＭＰＤデータは、SegmentInfoエレメントに、配信方式を示すpartialAvailability属性が付加されている点が、図２のＭＰＤデータと異なる。このpartialAvailability属性は、値として"true"または"false"をとることができる。partialAvailability="true"は、サブセグメント及び／又はエントリーの単位で配信可能であることを示し、partialAvailability="false"は、セグメントデータ及び／又はインデックス情報の単位で配信可能であることを示す。partialAvailability属性の記述が省略された場合、"false"の場合と同様に解釈されるものとする。
【０１３４】
なお、図２１の例では、partialAvailability属性は、SegmentInfoエレメントの属性として記述されているが、これに限られない。例えば、RepresentationエレメントやPeriodエレメント等、SegmentInfoより上位のエレメントの属性として記述してもよい。また、例えばIndexエレメントやUrlエレメント等、SegmentInfoより下位のエレメントの属性として記述してもよい。
【０１３５】
このようなＭＰＤデータを生成する場合、サーバ制御部２６は、記述情報生成部２５に対して、上述の所定の配信パラメータ（リプリゼンテーション数、配信開始時刻、セグメントの再生期間、サブセグメントの再生期間、最小バッファ時間等）に加えて、partialAvailability属性の値を指定して、記述情報生成を指示する。
【０１３６】
これにより、記述情報生成部２５は、サブセグメント（部分再生期間のコンテンツ）を、セグメントデータ（再生期間全体）のエンコードが完了する前に送信可能か否かを示す情報であるpartialAvailability属性を含むＭＰＤデータを生成する。このＭＰＤデータは、記述情報２９としてサーバ記憶部２２に格納される。
【０１３７】
そして、サーバ通信部２１は、クライアント１からのＭＰＤ取得要求に応じて、上記のようにして生成されたＭＰＤデータを、サーバ記憶部２２から読み出してクライアント１に送信する。なお、ＭＰＤデータをクライアント１に取得させる方法はこれに限られない。
【０１３８】
このようなＭＰＤデータを受信したクライアント１は、これを参照することによって、リプリゼンテーションの切り替えを行う場合、上記２種類の配信方式に応じたＨＴＴＰリクエストを送信することができる。具体的には、クライアント１のクライアント通信部１１は、取得したＭＰＤデータのpartialAvailability属性の値が"true"であれば、セグメントに含まれる全てのサブセグメント及び／又はインデックス情報に含まれる全てのエントリーの生成（エンコード）が完了する前であっても、生成（エンコード）が完了したサブセグメントに対応するエントリーを取得できるため、図２０に示すようなバイトレンジ（バイト位置）を指定したＨＴＴＰリクエストを送信することによって、切り替え後のリプリゼンテーションにおける指定したサブセグメント以降のデータを取得することができる。したがって、低遅延での配信を実現することができる。一方、取得したＭＰＤデータのpartialAvailability属性の値が"false"であれば、セグメントに含まれる全てのサブセグメント及び／又はインデックス情報に含まれる全てのエントリーの生成（エンコード）が完了するまでは、それらのデータを取得できない。そのため、該データの生成（エンコード）の完了後に、バイトレンジを指定したＨＴＴＰリクエストを送信する必要があることを認識することができる。
【０１３９】
このように、partialAvailability属性をＭＰＤデータに記述することにより、クライアント１は配信方式に応じた適切なＨＴＴＰリクエストを送信することができる。
【０１４０】
また、サーバ２においても、バイトレンジを指定したＨＴＴＰリクエストに対応する場合には、記述情報生成部２５は、partialAvailability属性の値に"true"を設定したＭＰＤデータを生成し、バイトレンジを指定したＨＴＴＰリクエストに対応しない場合には、partialAvailability属性の値に"false"を設定したＭＰＤデータを生成することで、設計の自由度を高めることができる。
【０１４１】
〔その他の構成例〕
上述の説明では、インデックス情報２８が図３に記載のデータ構造である場合について説明したが、ＤＡＳＨでは、倍速再生等のトリック再生を実現するために、図１１に示すデータ構造のインデックス情報も用いることができる。図１１に示したインデックス情報は、図３に記載のデータ構造の後半部分に、トリック再生を実現するために必要な階層インデックス情報を付与したデータ構造となっている。階層インデックス情報も、サブセグメント単位でエントリー情報を持ち、エントリー毎に、階層数および階層毎にトリック再生のための情報を有している。なお、図１１に示した階層インデックス情報を除く、図３に記載のインデックス情報と同じデータ構造をした部分は、以降の説明では通常インデックス情報と呼び、区別する。
【０１４２】
図１１に示すデータ構造を持つインデックス情報をコンテンツ送受信システム３で用いる場合、通常インデックス情報の配信完了は、前述の通り、ライブストリーミング完了時であるため、クライアント１が、ライブストリーミング中に階層インデックス情報を取得し、トリック再生を実現できない問題がある。この問題を解決するためには、図１２に示すように、通常インデックス情報と、階層インデックス情報をそれぞれ独立のデータとして生成し、図１３のＭＰＤデータに示すように、IndexエレメントとExtIndexエレメントとを記述すればよい。そして、Indexエレメントに通常インデックス情報を参照するためのＵＲＬを記載し、ExtIndexエレメントに階層インデックス情報を参照するためのＵＲＬを記載することで、それぞれ独立に取得できる構成とすればよい。
【０１４３】
あるいは、図１４のインデックス情報のデータ構造例に示すように、通常インデックス情報および、階層インデックス情報のそれぞれのエントリーに含まれる情報を、サブセグメント毎に１つのエントリーに纏めて記載する構成のインデックス情報を用いる構成としてもよい。
【０１４４】
あるいは、図１５のインデックス情報のデータ構造例に示すように、通常インデックス情報および、階層インデックス情報の各エントリーに当該エントリーに有効値が設定されているか否かを示すフィールド”isValid”を設けてもよい。そして、サブセグメントのエンコードが完了する毎に、インデックス情報生成部２４が、エンコード済みのサブセグメントに対応するエントリーにエントリー情報を記述すると共に、”isValid”にそのエントリーが有効なエントリーであることを示す“Ｙｅｓ”を設定する一方、未エンコードのサブセグメントに関するエントリーについては、”isValid”に“Ｎｏ”を設定して無効なエントリーであることを示すことで、インデックス情報全体を生成し、即時配信可能な構成としてもよい。この場合、”isValid”の値を参照することにより、予め定められた数のエントリーのうち、何れのエントリーが有効であるか（エントリー情報を含むか）を特定することができる。
【０１４５】
あるいは、通常インデックス情報、階層インデックス情報のデータ構造は図１１に記載のデータ構造を用い、インデックス情報全体の先頭部分に、当該インデックス情報に含まれる有効エントリー数を記載したインデックス管理情報を備えた図１６に示すデータ構造のインデックス情報を、サブセグメントのエンコード完了毎に生成する構成であってもかまわない。
【０１４６】
また、階層インデックス情報を用いない場合（図２１の例）と同様に、サブセグメント及び／又はエントリー（通常インデックス情報のエントリーと階層インデックス情報のエントリーとを含む）の生成（エンコード）が完了したタイミングでそれらのデータを配信可能とする配信方式と、セグメントデータに含まれる全てのサブセグメント、及び／又は通常インデックス情報に含まれる全てのエントリーと階層インデックス情報に含まれる全てのエントリーの生成（エンコード）が完了したタイミングでそれらのデータを配信可能とする配信方式とを選択可能にし、ＭＰＤデータによってこれらの配信方式を識別できるようにしてもよい。
【０１４７】
これについて、図２２に基づいて説明する。図２２は、配信方式を識別するためのフラグを含むＭＰＤデータの他の一例を示す図である。
【０１４８】
図示のＭＰＤデータは、SegmentInfoエレメントに、配信方式を示すpartialAvailability属性が付加されている点が、図１３のＭＰＤデータと異なる。このpartialAvailability属性は、値として"true"または"false"をとることができる。partialAvailability="true"は、サブセグメント及び／又はエントリーの単位で配信可能であることを示し、partialAvailability="false"は、セグメントデータ、及び／又はインデックス情報（通常インデックス情報と階層インデックス情報を含む）の単位で配信可能であることを示す。partialAvailability属性の記述が省略された場合、"false"の場合と同様に解釈されるものとする。
【０１４９】
なお、図２２の例では、partialAvailability属性は、SegmentInfoエレメントの属性として記述されているが、これに限られない。例えば、RepresentationエレメントやPeriodエレメント等、SegmentInfoより上位のエレメントの属性として記述してもよい。また、例えばIndexエレメント、ExtIndexエレメント、Urlエレメント等、SegmentInfoより下位のエレメントの属性として記述してもよい。
【０１５０】
このようなＭＰＤデータを生成する場合、サーバ制御部２６は、記述情報生成部２５に対して、上述の所定の配信パラメータ（リプリゼンテーション数、配信開始時刻、セグメントの再生期間、サブセグメントの再生期間、最小バッファ時間等）に加えて、partialAvailability属性の値を指定して、記述情報生成を指示する。
【０１５１】
これにより、記述情報生成部２５は、サブセグメント（部分再生期間のコンテンツ）を、セグメントデータ（再生期間全体）のエンコードが完了する前に送信可能か否かを示す情報であるpartialAvailability属性を含むＭＰＤデータを生成する。このＭＰＤデータは、記述情報２９としてサーバ記憶部２２に格納される。
【０１５２】
そして、サーバ通信部２１は、クライアント１からのＭＰＤ取得要求に応じて、上記のようにして生成されたＭＰＤデータを、サーバ記憶部２２から読み出してクライアント１に送信する。なお、ＭＰＤデータをクライアント１に取得させる方法はこれに限られない。
【０１５３】
このようなＭＰＤデータを受信したクライアント１は、これを参照することによって、リプリゼンテーションの切り替えを行う場合、上記２種類の配信方式に応じたＨＴＴＰリクエストを送信することができる。具体的には、クライアント１のクライアント通信部１１は、取得したＭＰＤデータのpartialAvailability属性の値が"true"であれば、セグメントに含まれる全てのサブセグメント及び／又は通常・階層インデックス情報に含まれる全てのエントリーの生成（エンコード）が完了する前であっても、生成（エンコード）が完了したサブセグメントに対応するエントリーを取得できるため、図２０に示すようなバイトレンジ（バイト位置）を指定したＨＴＴＰリクエストを送信することによって、切り替え後のリプリゼンテーションにおける指定したサブセグメント以降のデータを取得することができる。したがって、低遅延での配信を実現することができる。一方、取得したＭＰＤデータのpartialAvailability属性の値が"false"であれば、セグメントに含まれる全てのサブセグメント及び／又は通常・階層インデックス情報に含まれる全てのエントリーの生成（エンコード）が完了するまでは、それらのデータは取得できない。そのため、該データの生成（エンコード）の完了後に、バイトレンジを指定したＨＴＴＰリクエストを送信する必要があることを認識することができる。
【０１５４】
このように、partialAvailability属性をＭＰＤデータに記述することにより、クライアント１は配信方式に応じた適切なＨＴＴＰリクエストを送信することができる。
【０１５５】
また、サーバ２においても、バイトレンジを指定したＨＴＴＰリクエストに対応する場合には、記述情報生成部２５は、partialAvailability属性の値に"true"を設定したＭＰＤデータを生成し、バイトレンジを指定したＨＴＴＰリクエストに対応しない場合には、partialAvailability属性の値に"false"を設定したＭＰＤデータを生成することで、設計の自由度を高めることができる。
【０１５６】
〔ソフトウェアによる構成例〕
最後に、クライアント１及びサーバ２の各ブロックは、集積回路（ＩＣチップ）上に形成された論理回路によってハードウェア的に実現してもよいし、ＣＰＵ（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）、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。
【産業上の利用可能性】
【０１６０】
本発明は、ネットワークを介したコンテンツの送受信システムに利用することができる。
【符号の説明】
【０１６１】
１ クライアント（再生装置）
２ サーバ（送信装置）
１１ クライアント通信部
１２ 記述情報解析部
１３ コンテンツ再生部
１４ インデックス情報解析部
２１ サーバ通信部（参照情報提供手段、記述情報提供手段）
２２ サーバ記憶部
２３ エンコーダ
２４ インデックス情報生成部（参照情報生成手段）
２５ 記述情報生成部（記述情報生成手段）
２６ サーバ制御部
２７ セグメントデータ
２８ インデックス情報（参照情報）
２９ 記述情報
【技術分野】
【０００１】
本発明は、コンテンツをサーバからクライアントに送信するシステムにおいて、サーバは、異なる符号化パラメータで複数のエンコードを行い、クライアントは、当該コンテンツの受信・再生にあたり、通信環境等の条件に応じて、前記符号化パラメータから適切な再生対象を選択し、当該コンテンツの再生中、前記通信環境の変化に応じて、適切に再生対象を切り替えることを可能とする技術に関する。
【背景技術】
【０００２】
従来から、通信ネットワークを介してコンテンツの提供を行う技術が広く用いられている。例えば、下記の特許文献１には、クライアントからサーバにＨＴＴＰでコンテンツの要求を送信し、クライアントがこの要求に対する応答として受信したコンテンツをストリーミング再生するコンテンツストリーミングサービスシステムが開示されている。
【０００３】
また、このようなシステムの１つとして、現在、ＭＰＥＧ（Moving Picture Experts Group）にて標準化作業が進められている、非特許文献１に示されるＤＡＳＨ(Dynamic Adaptive Streaming over HTTP)があげられる。ＤＡＳＨでは、ＭＰＤデータ（Media Presentation Description）と呼ばれる記述情報（メタデータ）をストリーミング制御に用いる。ＭＰＤデータには、コンテンツの属性、コンテンツを構成するリソースの再生順序などが記述される。クライアントは、ストリーミングサービスの事前あるいはサービス途中に、ＭＰＤデータを受信し、当該ＭＰＤデータを参照して、サーバに要求するリソースを決定する。
【０００４】
このＭＰＤデータは、対象コンテンツの再生期間を複数の再生期間に分割し、分割された再生期間における情報をピリオド（Period）として記述する。また、ピリオド毎に再生されるリソースの情報を示すリプリゼンテーション（Representation）を記述する。１つのピリオドには複数のリプリゼンテーションを記述することができる。つまり、クライアントは、１つの再生期間において、複数のリプリゼンテーションから選択した１つのリプリゼンテーションを再生対象とする。
【０００５】
これにより、例えばビットレートの異なる複数のリプリゼンテーションをＭＰＤデータに記述しておくことにより、クライアントはそのときの通信状況や、自装置の再生能力に応じたビットレートのリプリゼンテーションを選択し、そのリプリゼンテーションで特定されるリソースを取得して再生することができる。
【０００６】
ＤＡＳＨを用いたストリーミング再生動作の詳細について、図１７の例を用いて説明する。図１７は、ＤＡＳＨを用いたストリーミング再生中に、動的にリプリゼンテーションの切り替えを行う例を示す図であり、同図（ａ）はサーバとクライアントの処理の一例を示すタイミングチャートであり、同図（ｂ）はクライアントが使用するＭＰＤデータの一例を示している。
【０００７】
まず同図（ｂ）を用いて、ＭＰＤデータの詳細について説明する。ＭＰＤデータはＸＭＬにて記述されるメタデータである。ＭＰＤデータは、ストリーミング配信全体に係る情報を記述するＭＰＤエレメントをルート要素とし、ＭＰＤエレメントの属性として、ストリーミング配信形態（type）、ストリーミング再生開始に必要な最小バッファ時間（minBufferTime）、ストリーミング配信の開始時刻（availabilityStartTime）が記述されている。さらに、ＭＰＤエレメントは子要素として前述のピリオドを示すPeriodエレメントを（図示の例では１つ）有している。
【０００８】
ピリオドは、前述のリプリゼンテーションを示すRepresentationエレメントを（図示の例では２つ）有している。１つのピリオド中に含まれる複数のリプリゼンテーションは、当該ピリオドにおける再生対象の選択肢を示す。言い換えれば、同一ピリオドに含まれる複数のリプリゼンテーションは、その何れかを選択して再生可能であることを示している。
【０００９】
また、各リプリゼンテーションは、そのリプリゼンテーションに対応する再生対象の属性を有する。リプリゼーションが持つことのできる属性には、コーデック、ビットレート、フレームレート、解像度等の当該再生対象の符号化条件に関する情報（特にコンテンツの再生に関する情報）を記述することができ、クライアントは、これらの属性を参照して、リプリゼンテーションを選択する。
【００１０】
例えば、ある映像コンテンツについて、コーデック、ビットレート、フレームレート、解像度等が異なる複数のリプリゼンテーションが記述されている場合には、クライアントは、自機の再生可能なコーデック、ビットレート、フレームレート、解像度等に応じたリプリゼンテーションを選択する。
【００１１】
図示の例では、属性として、そのリプリゼンテーションの識別子（id）、データ形式を示すＭＩＭＥタイプ（mimeType）、及びビットレート（図では当該リプリゼンテーションをストリーミング再生するために必要なネットワークバンド幅：bandwidth）が記述されている。
【００１２】
またピリオドには、SegmentInfoDefaultエレメントおよびSegmentInfoエレメントを用いてセグメントデータに関する情報が記述される。なお、セグメントデータとは、１つのＵＲＬ（Uniform Resource Locator）で指定される再生対象コンテンツの構成リソースのアクセス単位である。図示の例では、SegmentInfoDefaultエレメントに、当該ピリオドに含まれる全てのセグメントデータに対して適用されるパラメータの規定値が記述されており、各セグメントデータの再生期間（duration）が記述されている。また、前述のリプレゼンテーション毎に、SegmentInfoエレメントが記述され、SegmentInfoエレメントの子要素であるUrlエレメントに各セグメントデータのＵＲＬが記述されており、クライアントは当該ＵＲＬにアクセスすることで選択したリプレゼンテーションを構成するセグメントデータを取得することができる。
【００１３】
図示の例では、各リプリゼンテーションのそれぞれに複数のＵＲＬが記述されており、各ＵＲＬで取得されるセグメントデータの再生期間は、前述のSegmentInfoDefaultエレメントに記載された再生期間が適用され１０秒である。つまり、SegmentInfoエレメント内に記述された一番目のＵＲＬは、ストリーミング再生開始直後からの１０秒間（０秒から１０秒）のセグメントデータに対応し、二番目のＵＲＬは再生期間が１０秒から２０秒までのセグメントデータに対応し、三番目のＵＲＬは再生期間２０秒から３０秒までのセグメントデータに対応している。
【００１４】
ここで、図示のように、各リプリゼンテーションの属性には異なる値が記述されている。すなわち、一番目のリプリゼンテーションでは、ＭＩＭＥタイプにＭＰＥＧ２-ＴＳ（ISO/IEC 13818）を示す"video/mpeg2ts"が記述され、バンド幅が"1024000"と記述されているのに対し、二番目のリプリゼンテーションでは、ＭＩＭＥタイプは一番目のリプリゼンテーションと同じvideo/mpeg2ts"が記述されているが、バンド幅が"102400"と記述されている。
【００１５】
したがって、クライアントは、このＭＰＤデータを用いた場合、バンド幅が"1024000"のＭＰＥＧ２−ＴＳ、またはバンド幅が"102400"のＭＰＥＧ２−ＴＳからなるリプリゼンテーションの何れかを選択することができる。これらのリプリゼンテーションの内容は同一の映像コンテンツあるため、バンド幅に余裕があり、高品質な映像を取得したいときは一番目のリプリゼンテーションを選択し、バンド幅に余裕がないとき等は二番目のリプリゼンテーションを選択すればよい。なお、図示の例では、セグメントデータとして、ＭＰＥＧ２−ＴＳを用いる場合について例示したが、ＤＡＳＨでは、セグメントデータとして、ＭＰ４を用いることも可能である。
【００１６】
同図（ａ）は、このＭＰＤデータを用いてコンテンツを再生する処理の流れを示している。図示のように、まずクライアントは、サーバにＭＰＤデータの取得要求を送信し、サーバはこの要求に応じてクライアントにＭＰＤデータを送信する。
【００１７】
次に、このＭＰＤデータを取得したクライアントは、ＭＰＤデータに記述されているリプリゼンテーションの中から１つのリプリゼンテーションを選択し、選択したリプリゼンテーションに含まれるＵＲＬを用いてセグメントデータの取得要求を行う。この例では、一番目のリプリゼンテーションを選択し、その一番目のＵＲＬを用いて"Sample-div1.ts"を要求する。なお、ＭＰＤデータに記載されたとおり、ストリーミング配信の開始時刻（availabilityStartTime）に合わせて、当該セグメントデータの取得要求は行われる。つまり図示の例では、2011年5月1日12:00に、"Sample-div1.ts"の取得要求が行われる。
【００１８】
この要求を受信したサーバは、要求されたセグメントデータをクライアントに送信する。
なお、セグメントデータは、複数のＩＰパケットに分割されて、順次クライアントに送信され、送信開始から送信完了に要する時間は、クライアントとサーバを結ぶネットワークのトラフィック等で変化する。
【００１９】
クライアントは、セグメントデータの受信を開始し、ＭＰＤデータに記述されているストリーミング再生開始に必要な最小バッファ時間（minBufferTime）、図示の例では再生期間６秒に相当するセグメントデータを受信した時点で、再生を開始する。
【００２０】
また、"Sample-div1.ts"の受信が完了した時点で、クライアントは後続の"Sample-div2.ts"の取得要求を行い、サーバはこの要求に応じて"Sample-div2.ts"のデータをクライアントに送信する。そして、クライアントはこの受信したセグメントデータを、”Sample-div1.ts”の再生完了後に再生する。
【００２１】
ここで、トラフィックの増大等の要因により、クライアント、サーバ間のスループットが低下し、セグメントデータ受信が遅延したとする。遅延が長時間に渡ると、バッファリングによる再生中断が頻発するようになり、コンテンツの視聴が困難になるので、クライアントは、セグメントデータの切り替えが必要と判断する。同図（ｂ）のＭＰＤデータには、二番目のリプリゼンテーションに必要なバンド幅のより小さいセグメントデータが含まれているので、クライアントは２番目のリプリゼンテーションに再生対象を切り替えることを判断する。
【００２２】
クライアントは、再生期間０秒から２０秒に相当する、”Sample1-div1.ts”、”Sample1-div2.ts”の取得要求を既に行っているため、”Sample1-div2.ts”の受信完了後、２番目のリプリゼンテーションの再生期間２０秒から３０秒のセグメントに相当する、"Sample2-div3.ts"を取得して”sample1-div2.ts”の再生完了後、再生する。以降、２番目のリプリゼンテーションを構成するセグメントデータを順次、受信し再生する。
【００２３】
このようにＤＡＳＨでは、ネットワーク状況に応じて、動的にセグメントデータ単位でリプリゼンテーションを切り替える、アダプティブストリーミングが可能である。
【００２４】
しかしながら、上述のアダプティブストリーミングを実現するためには、時々刻々と変化するネットワークトラフィックの変化に対応するため、変化の大きいネットワークでは、短期間でリプリゼンテーションの切り替えが可能である必要がある。言い換えれば、リプリゼンテーションの切り替え単位である、セグメントデータの再生期間は、充分に短い（例えば２秒）必要がある。
【００２５】
なお、セグメントデータの再生期間を短く設定することは、ＭＰＤデータのデータ量が増大する問題がある。また、コンテンツを再生する際、セグメント取得要求によって生じるネットワークトラフィックが増大する問題がある。
【００２６】
このような問題を解決するために、１つのセグメントデータの再生期間を短く設定する代わりに、セグメントデータを複数のサブセグメントデータに分割し、各サブセグメントデータを参照するためのインデックス情報を記述する方法が提案されている。なお、サブセグメントデータは、セグメントデータを物理的に分割したものではなく、セグメントデータの一部分を、インデックス情報によってサブセグメントデータとして参照可能にしたものである。つまり、インデックス情報はセグメントデータの論理的な分割位置を示す制御情報と言える。
【００２７】
これについて、図１８から図２０に基づいて説明する。図１８は、インデックス情報を用いて、前述の図１７で例示したストリーミングを実現するＭＰＤデータの例である。図１７（ｂ）のＭＰＤデータと同様、２つのリプリゼンテーションが含まれているが、それぞれのリプリゼンテーションには、セグメントデータが１つだけ含まれている。セグメントデータ”sample1.ts”は、図１７のセグメントデータ ”sample1-div1.ts”から”sample1-div180.ts”が連結されたデータあり、セグメントデータ”sample2.ts”は、図１７のセグメントデータ ”sample2-div1.ts”から”sample2-div180.ts”が連結されたデータあり、SegmentInfoDefaultエレメントのduration属性が示す通り、再生期間３０分が設定されている。また、各セグメントデータのインデックス情報を参照するために記述されたIndexエレメントがSegmentInfoエレメントと対になる形で記述されている。このIndexエレメントには、インデックス情報にアクセスするためのＵＲＬが記述されている。
【００２８】
そして、Indexエレメントに記述されたＵＲＬにアクセスすることによって、セグメントデータを論理的に分割したサブセグメントを特定するインデックス情報を取得することができる。
【００２９】
図１９は、図１８で例示した対になるセグメントデータ”sample1.ts”とインデックス情報”index1.mp4”、及びセグメントデータ”sample2.ts”とインデックス情報”index2.mp4”の詳細を説明する図である。図示のように、セグメントデータは、サブセグメント１〜Nからなる。セグメントデータ”sample1.ts”のサブセグメント１〜Ｎはそれぞれ、図１７のセグメントデータ ”sample1-div1.ts”〜”sample1-div180.ts”に相当し、セグメントデータ”sample2.ts”のサブセグメント１〜Ｎはそれぞれ、図１７のセグメントデータ ”sample2-div1.ts”〜”sample2-div180.ts”に相当する。
【００３０】
またセグメントデータ”sample1.ts”におけるサブセグメント１、２、…Nのデータサイズはそれぞれ、S1_1,S1_2，…,S1_Nであり、セグメントデータ”sample2.ts”におけるサブセグメント１、２、…Nのデータサイズはそれぞれ、S2_1,S2_2，…,S2_Nであり、各サブセグメント再生期間は１０秒である。
【００３１】
一方、インデックス情報”index１.mp4”、”index2.mp4”には、対象セグメントデータ”Sample１.ts”、”Sample2.ts”のサブセグメント毎のデータサイズ、再生期間、各サブセグメントの先頭がランダムアクセスポイントであるか否かを示すＲＡＰフラグがエントリー情報（図中のエントリー１〜Ｎ）としてそれぞれ記録されている。
【００３２】
なお、ＤＡＳＨにおいて、インデックス情報のデータフォーマットは、セグメントデータのデータフォーマットによらず、ＭＰ４形式が用いられ、上述のエントリー情報を管理するエントリー情報管理領域が、インデックス情報先頭に設けられている。
【００３３】
エントリー情報管理領域には、インデックス情報全体のデータサイズSiおよび、当該インデックス情報に含まれるエントリー情報数（対象セグメントデータに含まれるサブセグメント数）Ｎが記録されている。
【００３４】
したがって、インデックス情報”index1.mp4”、”index2.mp4”を取得することで、クライアントは、対象セグメントデータ内のサブセグメント１〜Ｎの再生期間がそれぞれ、０〜１０秒、１０秒〜２０秒、…１７９０秒〜１８００秒であること、セグメントデータ内のサブセグメント１〜Ｎのバイトオフセットを求めることが可能である。
【００３５】
これにより、例えば図２０（a）に示すようなＨＴＴＰリクエストによって、セグメントデータ“sample2.ts”のサブセグメント２以降、あるいは同図（ｂ）に示すような、バイトレンジ（バイト位置）を指定したＨＴＴＰリクエストによって、サブセグメント３以降を取得することが可能であり、サブセグメント単位でのリプリゼンテーション切り替えを実現できる。
【００３６】
上述のインデックス情報を用いてサブセグメント単位でのリプリゼンテーション切り替え（アダプティブストリーミング）を実現する従来技術においては、（１）ＭＰＤデータを用いたセグメント単位でリプリゼンテーション切り替え（アダプティブストリーミング）を実現する従来技術に比べ、ＭＰＤデータの記述が簡素化される、（２）リプリゼンテーション切り替え時にのみ、インデックス情報およびセグメントデータ（あるいはサブセグメント）の取得要求が発生し、ストリーミング中に生じるＨＴＴＰリクエストによる通信トラフィックを軽減することができる、（３）リプリゼンテーションの切り替えが発生しない場合には、インデックス情報を取得する必要がない等の利点がある。
【先行技術文献】
【特許文献】
【００３７】
【特許文献１】特開２００５−１１０２４４号公報（２００５年４月２１日公開）
【非特許文献】
【００３８】
【非特許文献１】”Information technology-MPEG systems technologies - Part6:Dynamic Adaptive streaming over HTTP(DASH)”、[online]、２０１１年１月２８日、[２０１１年６月３日検索]、ISO/IEC、インターネット<http://www.itscj.ipsj.or.jp/sc29/open/29view/29n11873t.doc>
【発明の概要】
【発明が解決しようとする課題】
【００３９】
その一方で、上記従来技術には、ライブストリーミングに用いた場合に、低遅延での配信を実現できないという問題があった。
【００４０】
具体的には、インデックス情報を利用したサブセグメント単位でのリプリゼンテーション切り替えには、ライブ配信中のセグメントデータに関するインデックス情報が必要となる。しかしながら、前述の通り、インデックス情報には、当該インデックス情報全体のデータサイズや、対象セグメントデータに含まれるサブセグメント数、各サブセグメントのデータサイズ等が含まれており、セグメントデータのエンコードが完了するまでは、生成することができなかった。
【００４１】
したがって、セグメントデータのライブエンコード開始からセグメントデータのライブエンコード完了および当該セグメントデータに対するインデックス情報の生成が完了するまで、セグメントデータおよびインデックス情報の配信開始を遅らせる必要があった。なお、インデックス情報の生成にはほとんど時間を要さないが、セグメントデータのライブエンコード完了には、そのセグメントデータの再生と同じだけの時間を要するので、セグメントデータの再生期間に相当する時間、配信開始を遅らせる必要があったとも言える。
【００４２】
本発明は、上記の問題点に鑑みてなされたものであり、その目的は、低遅延でのライブストリーミングを行うシステムにおいて、１つのセグメントデータのライブエンコード完了を待たず、セグメントデータおよびインデックスデータの配信を開始でき、リプリゼンテーションの切り替え（アダプティプストリーミング）を可能にする送信装置等を提供することにある。
【課題を解決するための手段】
【００４３】
上記の課題を解決するために、本発明の送信装置は、同一の再生期間に対応する複数のコンテンツをエンコードし、エンコードしたコンテンツのうち再生対象として選択されたコンテンツを再生装置に送信する送信装置であって、上記複数のコンテンツについて予め定めた再生位置までエンコードが進んだときに、上記再生期間のうち上記再生位置までの部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成する参照情報生成手段と、上記参照情報生成手段が生成した参照情報を上記再生装置に取得させる参照情報提供手段とを備えていることを特徴としている。
【００４４】
また、本発明の送信装置の制御方法は、上記の課題を解決するために、同一の再生期間に対応する複数のコンテンツをエンコードし、エンコードしたコンテンツのうち再生対象として選択されたコンテンツを再生装置に送信する送信装置の制御方法であって、上記複数のコンテンツについて予め定めた再生位置までエンコードが進んだときに、上記再生期間のうち上記再生位置までの部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成する参照情報生成ステップと、上記参照情報生成ステップで生成した参照情報を上記再生装置に取得させる参照情報提供ステップとを含むことを特徴としている。
【００４５】
上記の構成によれば、複数のコンテンツについて部分再生期間のエンコードが進んだときに、部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成し、これを再生装置に取得させる。
【００４６】
したがって、再生装置は、コンテンツのエンコードが完了するまでの期間に、部分再生期間で再生対象のコンテンツを切り替えることが可能になる。つまり、上記の構成によれば、コンテンツのエンコードが完了するまでの期間に、再生装置に１つの再生期間の途中で再生対象のコンテンツを切り替えさせることができる。
【００４７】
また、再生装置が再生しているコンテンツはエンコードが完了している部分であり、このような部分については参照情報による切り替えが可能となる。よって、上記の構成によれば、再生装置が再生している再生位置におけるコンテンツの切り替えが保証される。
【００４８】
また、上記参照情報生成手段は、コンテンツのエンコードが予め定めた再生位置まで進んだときに、該コンテンツの該再生位置までの部分再生期間のデータサイズを示す参照情報を生成し、その後、後続する予め定めた再生位置までエンコードが進む毎に、該コンテンツの該再生位置とその直前の予め定めた再生位置の間の部分再生期間のデータサイズを示す情報を上記参照情報に追加することが好ましい。
【００４９】
上記の構成によれば、コンテンツのエンコードが予め定めた再生位置まで進んだときに、コンテンツの部分再生期間のデータサイズを示す参照情報を生成し、その後、後続する予め定めた再生位置までエンコードが進む毎に、部分再生期間のデータサイズを示す情報を上記参照情報に追加する。
【００５０】
上記の構成では、エンコードの進行に応じて部分再生期間のデータサイズを示す情報を追加するので、生成された参照情報はエンコード済みの各部分再生期間のデータサイズが示された情報となる。
【００５１】
したがって、上記の構成によって生成された参照情報を用いることによって、部分再生期間で再生対象のコンテンツを切り替えることが可能になる。例えば、１〜３番目までの部分再生期間のデータサイズがそれぞれSz1〜Sz3である場合、２番目の部分再生期間で切り替えるときには、再生装置はSz1以降を指定してコンテンツの要求を行えばよい。
【００５２】
また、上記参照情報は、予め定められた数のエントリーと、該エントリーのうち有効なエントリーを示す有効情報を記述する記述領域とを含む情報であり、上記参照情報生成手段は、コンテンツのエンコードが予め定めた再生位置まで進んだときに、該再生位置までの部分再生期間に対応するエントリーに、該部分再生期間で再生対象のコンテンツを切り替えるための情報を追加すると共に、該エントリーが有効であることを示す有効情報を上記記述領域に記述するものであってもよい。
【００５３】
上記の構成によれば、コンテンツのエンコードが予め定めた再生位置まで進んだときに、該再生位置までの部分再生期間に対応するエントリーに、該部分再生期間で再生対象のコンテンツを切り替えるための情報を追加すると共に、該エントリーが有効であることを示す有効情報を記述領域に記述する。
【００５４】
このような参照情報を取得した再生装置は、その参照情報に含まれているエントリーのうち、何れが有効であるかを有効情報から特定し、有効なエントリーに含まれる情報を用いて、そのエントリーに対応する部分再生期間でコンテンツを切り替えることができる。つまり、上記の構成によれば、有効なエントリーと有効ではないエントリーとを含む参照情報を用いて、再生装置に１つの再生期間の途中で再生対象のコンテンツを切り替えさせることができる。
【００５５】
また、上記送信装置は、上記部分再生期間のコンテンツを、上記再生期間の全体のエンコードが完了する前に送信可能か否かを示す情報を含む記述情報を生成する記述情報生成手段と、上記記述情報生成手段が生成した記述情報を上記再生装置に取得させる記述情報提供手段とをさらに備えていることが好ましい。
【００５６】
上記の構成によれば、部分再生期間のコンテンツを、再生期間の全体のエンコードが完了する前に送信可能か否かを示す情報を含む記述情報を生成し、生成した記述情報を再生装置に取得させる。
【００５７】
したがって、部分再生期間で再生対象のコンテンツを切り替えることのできる配信方式であるか、再生期間全体のエンコードが完了した時点でコンテンツを配信可能にする配信方式であるかをクライアントに適切に認識させることができる。
【００５８】
なお、上記送信装置及び上記再生装置は、コンピュータによって実現してもよく、この場合には、コンピュータを上記送信装置及び上記再生装置の各手段として動作させることにより、上記送信装置及び上記再生装置をコンピュータにて実現させる制御プログラム、及びそれを記録したコンピュータ読み取り可能な記録媒体も本発明の範疇に入る。
【発明の効果】
【００５９】
以上のように、本発明の送信装置は、複数のコンテンツについて予め定めた再生位置までエンコードが進んだときに、再生期間のうち上記再生位置までの部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成する参照情報生成手段と、上記参照情報生成手段が生成した参照情報を再生装置に取得させる参照情報提供手段とを備えている構成である。
【００６０】
また、本発明の送信装置の制御方法は、複数のコンテンツについて予め定めた再生位置までエンコードが進んだときに、再生期間のうち上記再生位置までの部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成する参照情報生成ステップと、上記参照情報生成ステップで生成した参照情報を再生装置に取得させる参照情報提供ステップとを含む構成である。
【００６１】
上記の構成によれば、再生装置は、コンテンツのエンコードが完了するまでの期間に、部分再生期間で再生対象のコンテンツを切り替えることが可能になる。つまり、上記の構成によれば、コンテンツのエンコードが完了するまでの期間に、再生装置に１つの再生期間の途中で再生対象のコンテンツを切り替えさせることができるという効果を奏する。
【図面の簡単な説明】
【００６２】
【図１】本発明の一実施形態にかかるコンテンツ送受信システムに含まれるクライアントとサーバの要部構成を示すブロック図である。
【図２】上記コンテンツ送受信システムで使用するＭＰＤデータの一例を示している。
【図３】インデックス情報とセグメントデータの関係を示す図である。
【図４】サーバにおけるインデックス情報生成部の動作を示すフローチャートである。
【図５】サーバにおけるＭＰＤデータ生成タイミングおよびＭＰＤデータ配信可能タイミングを説明するためのタイミングチャートである。
【図６】サーバにおけるセグメントデータ生成タイミングおよびセグメントデータ配信可能タイミングを説明するためのタイミングチャートである。
【図７】サーバにおけるサブセグメント生成タイミングおよびサブセグメント配信可能タイミングを説明するためのタイミングチャートである。
【図８】サーバにおけるインデックス情報生成タイミングおよびインデックスデータ配信可能タイミングを説明するためのタイミングチャートである。
【図９】サーバにおけるインデックス情報の各エントリー情報の生成タイミングおよび各エントリー情報配信可能タイミングを説明するためのタイミングチャートである。
【図１０】アダプティブストリーミング再生の一例を示すクライアントのタイミングチャートである。
【図１１】通常インデックス情報、階層インデックス情報からなるインデックス情報の構造を示す図である。
【図１２】通常インデックス情報、階層インデックス情報をそれぞれ個別のデータ構造に分離した例を示す図である。
【図１３】通常インデックス情報、階層インデックス情報をそれぞれ独立に参照可能としたＭＰＤデータの記述例である。
【図１４】通常インデックス情報、階層インデックス情報の各エントリーを纏めて記録するデータ構造を持つインデックス情報の例を示す図である。
【図１５】インデックス情報の各エントリーにのエントリーが有効であるか否かを示す情報を記述したインデックス情報の一例を示す図である。
【図１６】有効なエントリーを示す情報を管理領域に記述したインデックス情報の一例を示す図である。
【図１７】アダプティプストリーミング再生の一例を示す図であり、同図（ａ）はサーバとクライアントの処理の一例を示すタイミングチャートであり、同図（ｂ）は当該ストリーミングを制御に用いるＭＰＤデータの一例を示している。
【図１８】インデックス情報を利用可能にするＭＰＤデータの例を示す図である。
【図１９】インデックス情報とセグメントデータの関係を示す図である。
【図２０】インデックス情報を用いたサブセグメント単位でのセグメントデータの部分取得のためのＨＴＴＰリクエストの一例を示す図である。
【図２１】配信方式を識別するためのフラグを含むＭＰＤデータの一例を示す図である。
【図２２】配信方式を識別するためのフラグを含むＭＰＤデータの他の一例を示す図である。
【発明を実施するための形態】
【００６３】
〔実施の形態１〕
以下、本発明の一実施形態について、図１〜図１０に基づいて詳細に説明する。
【００６４】
〔システムの概要〕
まず、本実施形態のコンテンツ送受信システムの概要を図１に基づいて説明する。図１は、本発明の一実施形態を示すものであり、コンテンツ送受信システム３に含まれるクライアント（再生装置）１とサーバ（送信装置）２の要部構成を示すブロック図である。
【００６５】
〔クライアントの構成〕
図示のように、クライアント１は、クライアント１が外部の装置とネットワークを介して通信するためのクライアント通信部１１と、記述情報解析部１２と、コンテンツ再生部１３と、インデックス情報解析部１４を備えている。
【００６６】
クライアント通信部１１は、記述情報解析部１２が選択したリプリゼンテーションを構成するセグメントデータあるいはサブセグメントの取得要求をサーバ２に送信し、これによりセグメントデータあるいはサブセグメントを取得する。また、インデックス情報解析部１４の要求するインデックス情報を取得する。ここでは、クライアント通信部１１が、ＨＴＴＰで要求を送信するものとする。
【００６７】
記述情報解析部１２は、サーバ２に要求可能なリソースを示す情報をコンテンツの再生期間（ピリオド）毎に含むコンテンツの記述情報を取得し、取得した記述情報に従って、再生対象のリプリゼンテーションを選択する。具体的には、記述情報解析部１２は、サーバ２から記述情報としてＭＰＤデータを受信し、再生対象のリプリゼンテーションを決定する。また、コンテンツ再生部１３があるリプリゼンテーションのセグメントデータを再生しているときに、リプリゼンテーションの切り替えが必要となる所定の事象を検出した場合に、検出した事象に応じた他のリプリゼンテーションへ再生対象を切り替える決定を行う。
【００６８】
コンテンツ再生部１３は、クライアント通信部１１の要求によって受信されたセグメントデータあるいはサブセグメントを順に再生する。なお、再生したコンテンツは、クライアント１が備えるディスプレイやスピーカ等から出力してもよいし、クライアント１に有線または無線接続されているディスプレイやスピーカ等から出力してもよい。
【００６９】
インデックス情報解析部１４は、クライアント通信部１１を介して受信したインデックス情報を解析し、解析結果を記述情報解析部１２に通知する。
【００７０】
〔サーバの構成〕
一方、サーバ２は、サーバ通信部（参照情報提供手段、記述情報提供手段）２１と、サーバ記憶部２２と、エンコーダ２３と、インデックス情報生成部（参照情報生成手段）２４と、記述情報生成部（記述情報生成手段）２５と、サーバ制御部２６とを備える。
【００７１】
また、サーバ記憶部２２には、サーバ２にて生成、配信される、セグメントデータ２７と、インデックス情報２８と、記述情報２９とが格納される。
【００７２】
サーバ通信部２１は、クライアント１からの記述情報の取得要求に応じて、記述情報２９をクライアント１に送信する。具体的には、サーバ記憶部２２に格納されている記述情報２９を読み出して、クライアント１に送信する。上述のように、ここでは記述情報２９としてＭＰＤデータを用いる。
【００７３】
またサーバ通信部２１は、同様に、クライアント１からのセグメントデータ２７の取得要求、あるいはインデックス情報２８の取得要求に応じて、サーバ記憶部２２に格納されたセグメントデータ２７あるいはインデックス情報２８を読み出して、クライアント１に送信する。
【００７４】
サーバ制御部２６は、サーバ２にて生成、配信されるデータの生成タイミングおよびデータ生成に必要な配信パラメータ等の情報を、エンコーダ２３、インデックス情報生成部２４、記述情報生成部２５に指示する。
【００７５】
エンコーダ２３は、カメラ等（図示せず）で撮影され、外部からライブ入力されるコンテンツを、サーバ制御部２６にて指示されたリプリゼンテーション毎のエンコード条件（符号化パラメータ）に従って、それぞれエンコードしてセグメントデータ２７を生成し、サーバ記憶部２２に格納する。なお、同一ピリオドにおける複数のリプリゼンテーションは、同時並行でライブエンコードが行われ、リプリゼンテーション毎に１つのセグメントデータ２７が生成される。
【００７６】
インデックス情報生成部２４は、各セグメントデータ２７について、そのセグメントデータ２７に含まれるサブセグメント単位で切り替えを行うためのインデックス情報２８を生成する。なお、インデックス情報２８及びその生成方法の詳細については後述する。
【００７７】
セグメントデータ２７は、前述の通り、クライアント１に提供可能なコンテンツを所定のエンコード条件に従ってエンコードし、所定の再生期間単位で分割したデータである。
【００７８】
インデックス情報２８は、サブセグメントデータでの切り替えを可能にするための情報である。クライアント１は、インデックス情報２８を参照することによってサブセグメントデータの位置を特定し、サブセグメントデータ単位で再生対象を切り替えることができる。
【００７９】
記述情報２９は、サーバ２からクライアント１に提供可能なコンテンツ（ここでは、サーバ記憶部２２に格納されるセグメントデータ２７）に関する情報である。具体的には、記述情報２９は、選択候補を示すリプリゼンテーションがピリオド毎に記述されたＭＰＤデータである。ＭＰＤデータの詳細は後述する。
【００８０】
なお、セグメントデータ２７、インデックス情報２８、及び記述情報２９の少なくとも１つは、サーバ２に着脱可能な外部の記録媒体に記録されていてもよいし、サーバ２がアクセス可能な外部の装置に記憶されていてもよい。すなわち、セグメントデータ２７、インデックス情報２８、及び記述情報２９は、サーバ２が取得可能な状態で格納されていればよく、格納先は特に限定されない。
【００８１】
また、コンテンツ送受信システムが複数のサーバ２によって構成され、セグメントデータ２７、インデックス情報２８、及び記述情報２９のそれぞれが異なるサーバ２から提供される構成であっても構わない。
【００８２】
〔システムで用いるデータの詳細〕
図２はコンテンツ送受信システム３で用いるＭＰＤデータの一例である。ストリーミングの配信形態を示すＭＰＤエレメントのType属性がライブストリーミングである点を除けば前述の図１８のＭＰＤデータと同じであり、詳細な説明を省略する。
【００８３】
図３は図２に示すＭＰＤデータと共にコンテンツ送受信システム３で用いるセグメントデータ及びインデック情報の一例を示す図である。ライブストリーミングでのアダプティブストリーミングを実現するために、サブセグメントの再生期間が前述の図１９に示す例より短い２秒に設定されている点を除き図１９と同じであり、詳細な説明を省略する。
【００８４】
〔サーバ２で行われる処理の詳細〕
次に、コンテンツ送受信システム３におけるサーバ２の動作について、詳細を図４〜９に基づいて説明する。
【００８５】
図４は、コンテンツ送受信システム３において、アダプティブストリーミングを実現するためのインデックス情報を生成するインデックス情報生成部２４の動作を示すフローチャートである。
【００８６】
コンテンツ送受信システム３においてライブストリーミングが開始されると、インデックス情報生成部２４は、インデックス情報におけるエントリー情報管理領域を生成する（Ｓ１）。前述の通り、エントリー情報管理領域には、インデックス情報全体のデータサイズSiとエントリー数（サブセグメント数）Ｎを記述する必要がある。エントリー情報管理領域のデータサイズおよび各エントリーのデータサイズは固定長であるため、セグメントデータに含まれるサブセグメント数が確定していれば、エントリー情報管理領域を生成することができる。
【００８７】
例えば、図２に示したＭＰＤデータを用いたライブ配信を行う場合、ライブストリーミング開始時点で、セグメントデータの再生期間３０分、サブセグメントの再生期間２秒が配信パラメータとして、サーバ制御部２６から入力されることにより、サブセグメント数が１８００に確定されるので、エントリー情報管理領域は即時生成される。
【００８８】
次に、インデックス情報生成部２４は、エントリー生成のため、エンコーダ２３でのサブセグメントエンコード完了を待つ（Ｓ２）。
【００８９】
エンコーダ２３にてサブセグメントのエンコードが完了したことがエンコーダ２３から通知されると、インデックス情報生成部２４は当該サブセグメントに対する新規エントリーを生成（参照情報生成ステップ）し、インデックス情報に追加する（Ｓ３）。なお、エントリーには、サブセグメントのデータサイズ、再生期間、ＲＡＰフラグを記載する。サブセグメントのデータサイズは、サブセグメントのエンコード完了通知時にエンコーダ２３から通知された値が設定される。サブセグメントの再生期間については、サーバ制御部２６からの配信パラメータで与えられた２秒が設定される。なお本システムにおいてサブセグメントは、アダプティブストリーミングを実現する際の、リプリゼンテーションの切り替えポイントであるため、常にランダムアクセスポイントとしてエンコードが行われることから、ＲＡＰフラグは常にＹｅｓが設定される。
【００９０】
生成したエントリー数がＳ１で求めたエントリー数Ｎ未満の場合（Ｓ４でＹｅｓの場合）、Ｓ２に戻って処理を継続し、生成したエントリー数がＮに達した場合（Ｓ４でＮｏの場合、インデックス情報の生成を終了する。
【００９１】
次に、サーバにおける各データの生成タイミングと、当該データの配信可能タイミングに係るサーバ動作を図５〜９を用いて説明する。図５は、サーバ２におけるＭＰＤデータ生成タイミングおよびＭＰＤデータ配信可能タイミングに係る動作を説明するためのタイミングチャートである。
【００９２】
図５において、時刻t0はＭＰＤデータの生成開始時刻である。時刻t0になると、ＭＰＤデータの生成開始のため、サーバ制御部２６が記述情報生成部２５に対し、所定の配信パラメータにて記述情報生成を指示する。記述情報生成部２５は、記述情報生成指示を受け、指定された配信パラメータ（リプリゼンテーション数、配信開始時刻、セグメントの再生期間、サブセグメントの再生期間、最小バッファ時間等）に基づき記述情報を生成する。なお、サーバ制御部２６は、クライアントでのアダプティブストリーミングを実現するため、最小バッファ時間に複数のサブセグメントが含まれるよう配信パラメータを制御する。例えば、図２、図３のデータ構成の場合、最小バッファ時間は６秒に設定されており、サブセグメントの再生期間は２秒に設定されている。記述情報生成部２５は、即時、ＭＰＤデータを生成し、サーバ記憶部２２に生成したＭＰＤデータを格納する。
【００９３】
時刻t0は、クライアント１がＭＰＤデータを取得可能となる時刻でもある。時刻t0に、サーバ通信部２１がクライアント１からのＭＰＤ取得要求を受けると、サーバ記憶部２２に、要求されたＭＰＤデータが存在するか否かを検索する。図５に示す通り、当該検索実行時には、既にＭＰＤデータの生成が完了しており、サーバ通信部２１は、当該ＭＰＤデータをサーバ記憶部２２から読み出し、クライアント１へ送信する。なお、図５において、ＭＰＤ取得要求から応答までに、タイムラグ（Δｔ）が生じているが、このタイムラグΔｔは、ユーザが遅延を体感できるほどに大きなものでなく、充分短い時間である。
【００９４】
なお、サーバ２において、生成されたＭＰＤデータはサーバ記憶部２２に保存されているため、t0以降の任意の時刻tにおいてクライアント１はＭＰＤデータの取得が可能である。
【００９５】
図６は、サーバ２におけるセグメントデータ生成タイミングおよびセグメントデータ配信可能タイミングに係る動作を説明するためのタイミングチャートである。
【００９６】
図６において、時刻t1は、サーバ２におけるライブエンコードの開始時刻である。また図中のセグメントデータ[n,m]は、セグメントデータ内のサブセグメントｎにおけるｍ番目のデータを表している。なおセグメントデータ[n,m]は、入力コンテンツ[n,m]のエンコーダ２３によるエンコード結果である。
【００９７】
時刻t1になると、セグメントデータのライブエンコードのため、サーバ制御部２６がエンコーダ２３に対し、所定の配信パラメータにてエンコード開始を指示する。エンコーダ２３は、指定された配信パラメータ（コーデック、ビットレート、画像サイズ、セグメントの再生期間、サブセグメントの再生期間等）に基づきエンコードを開始する。なお、配信パラメータはリプリゼンテーション毎にエンコーダ２３に与えられる。
【００９８】
エンコーダ２３は、コンテンツの入力があると、複数の配信パラメータで並行してセグメントデータのエンコードを行う。図２の例では、２つのリプリゼンテーションが存在するため、エンコーダ２３は、２つのセグメントデータについて並行してエンコードを行う。なお、図示の通り、コンテンツ[1,1]がエンコーダ２３に入力されると、即時セグメントデータ[1,1]へライブエンコードされ、サーバ記憶部２２に格納される。以降、エンコーダ２３にコンテンツ[1,2]、コンテンツ[1,3]、コンテンツ[1,4]、…と順次コンテンツが入力される毎に、セグメントデータ[1,2]、セグメントデータ[1,3]、セグメントデータ[1,4]、…がエンコードされ、サーバ記憶部２２のセグメントデータに追加される。
【００９９】
また、時刻t1は、セグメントデータの配信開始時刻（図２のＭＰＤデータにおいては、availabilityStartTime属性に設定された、”2011年５月1日12:00”）でもある。前述のＭＰＤデータの場合と同様、時刻t1以降にクライアント１からセグメントデータの取得要求を受けたサーバ通信部２１は、サーバ記憶部２２に要求されたセグメントデータが存在するか否かを検索する。図６に示す通り、サーバ通信部２１は、当該セグメントデータが一部でも存在していれば（図中では検索時にセグメントデータ[1,1]存在）、クライアント１に送信を開始する。以降、残りのセグメントデータが追加される毎に、順次クライアント１に送信する。
【０１００】
図７は、サーバ２におけるサブセグメント生成タイミングおよびサブセグメント配信可能タイミングに係る動作を説明するためのタイミングチャートである。
【０１０１】
図７において、時刻tnは、サブセグメントｎを生成開始される時刻である。図示のとおり、時刻tnにおいて、カメラからサブセグメントnの先頭データであるコンテンツ[n,1]が入力され、当該コンテンツ[n,1]は、エンコーダ２３にてサブセグメントnの先頭データ（セグメントデータ[n,1]）としてエンコードされ、サーバ記憶部２２に格納されたセグメントデータに追記される。
【０１０２】
また、時刻tnは、サブセグメントnの配信開始時刻でもある。前述のセグメントデータの場合と同様に、時刻tn以降にクライアント１からサブセグメントデータnで開始されるセグメントデータの部分取得要求を受けたサーバ通信部２１は、サーバ記憶部２２に要求されたセグメントデータが存在するか否かを検索する。なお、セグメントデータの部分取得要求は、図２０の例で示した通り、セグメントデータの取得開始バイト位置指定によって行われる。従ってサーバ通信部２１は、要求されたセグメントデータが存在する場合、さらに指定された取得開始バイト位置のデータが存在するかを確認し、指定バイト位置のデータが存在すれば、クライアント１に送信を開始する。
【０１０３】
図８は、サーバ２におけるインデックス情報生成タイミングおよびインデックス情報配信可能タイミングに係る動作を説明するためのタイミングチャートである。
【０１０４】
図８において、時刻t1は図６で説明した時刻t1と同時刻を示しており、インデックス情報の生成が開始される時刻である。時刻t1になると、インデックス情報の生成のため、サーバ制御部２６がインデックス情報生成部２４に対し、所定の配信パラメータに基づきインデックス情報生成を指示する。インデックス情報生成部２４は、前述の通り、指定された配信パラメータ（セグメントの再生期間、サブセグメントの再生期間）に基づきインデックス情報の生成を開始する。時刻t1においては、エントリー情報管理領域のみが生成され、サーバ記憶部２２に格納される。なお、インデックス情報もまた、セグメントデータと同様、配信されるリプリゼンテーション数に応じて、複数のインデックス情報が並行して生成される。
【０１０５】
また時刻t1は、インデックス情報の配信開始時刻でもある。つまり時刻t1において、クライアント１は、セグメントデータ、インデックス情報共に受信可能となる。時刻t1以降にクライアント１からインデックス情報の取得要求を受けたサーバ通信部２１は、サーバ記憶部２２に要求されたインデックス情報が存在するか否かを検索する。図８に示す通り、サーバ通信部２１は、当該インデックス情報が一部でも存在していれば（図中では検索時にエントリー情報管理領域のみ存在）、クライアント１に送信を開始する。以降、インデックス情報にエントリーが追加される毎に、順次クライアント１に送信する。
【０１０６】
図９は、サーバ２におけるインデックス情報の各エントリー情報の生成タイミングおよび各エントリー情報配信可能タイミングに係る動作を説明するためのタイミングチャートである。
【０１０７】
図９において、時刻tnは、図７で説明した時刻tnと同時刻（サブセグメントnの生成開始時刻）を示しており、インデックス情報のエントリーn-1が生成される時刻である。
【０１０８】
図示のとおり、エンコーダ２３は、時刻tnにおいて、サブセグメントn-1の生成を完了し、サブセグメントｎの生成を開始する。サブセグメントn-1の生成を完了したエンコーダ２３は、インデックス情報生成部２４にサブセグメントn-1の生成完了を通知する。
【０１０９】
サブセグメントn-1の生成完了の通知を受けたインデックス情報生成部２４は、インデックス情報のエントリーn-1を生成し、サーバ記憶２２に格納されたインデックス情報に追加する。
【０１１０】
また時刻tnは、インデックス情報のエントリn-1の配信開始時刻でもある。図示の通り、tn>tである時刻tにクライアント１からインデックス情報の取得要求を受けた前述のセグメントデータの場合と同様、時刻tn以降にクライアント１からサブセグメントデータnで開始されるセグメントデータの部分取得要求を受けたサーバ通信部２１は、サーバ記憶部２２に要求されたインデックス情報が存在するか否かを検索する。インデックス情報の一部が存在すれば、サーバ通信部２１は、順次データをクライアント１に送信する。
【０１１１】
時刻tnの直前では、インデックス情報としてエントリーn-2までがサーバ記憶部２２に格納されているため、エントリーn-2までの送信が可能である。前述のとおり、時刻tnにおいて、エントリーn-1が生成されサーバ記憶部２２に即時追加される。サーバ通信部２１は、追加されたエントリーn-1を即時クライアント１に送信する。
【０１１２】
以上説明した通り、サーバ２はセグメントデータにおけるサブセグメントnの配信開始時刻tnにおいて、インデックス情報として当該セグメントデータのサブセグメント１〜サブセグメントn-1までの情報をクライアント１に配信することが可能である。
【０１１３】
〔クライアント１で行われる処理の詳細〕
次に、インデックス情報を用いたアダプティブストリーミング再生の詳細について図１０に基づいて説明する。
【０１１４】
図１０は、ストリーミング再生中にリプリゼンテーション切り替えが発生した場合におけるクライアント１の動作を示すタイミングチャートである。
【０１１５】
まずクライアント１は、ＭＰＤデータの配信開時刻t0(図５に示したt0と同時刻)において、記述情報解析部１２が、クライアント通信部１１に対しＭＰＤデータの取得を指示し、クライアント通信部１１が、サーバ２に対し、ＭＰＤデータの取得要求を発行する。
【０１１６】
記述情報解析部１２は、クライアント通信部１１を介して図２に示したＭＰＤデータを受信する。ストリーミング開始時の再生対象として，id=”rep1”で示されるリプリゼンテーションを選択し、ストリーミング開始時刻(t0: 2011年5月1日12:00)になるまで待機する。
【０１１７】
ストリーミング開始時刻t1において、記述情報解析部１２は、クライアント通信部１１に対し、id=”rep1”で示されるリプリゼンテーションを構成するセグメントデータ”sample1.ts”の取得を指示し、クライアント通信部１１が、サーバ２に対し、セグメントデータ”sample1.ts”の取得要求を発行する。
【０１１８】
また記述情報解析部１２は、ＭＰＤデータに記載された最小バッファ時間に基づき、バッファ時間をコンテンツ再生部１３に指示する。図２のＭＰＤデータでは、最小バッファ時間が６秒に設定されているため、この値を指示する。
【０１１９】
サーバ２から受信したセグメントデータ”sample1.ts”は、順次コンテンツ再生部１３に入力される。コンテンツ再生部１３は、受信したセグメントデータの再生期間が指示されたバッファ時間６秒に達するまで、再生を開始せず、バッファリングを行う。
【０１２０】
コンテンツ再生部１３は、受信したセグメントデータの再生期間がバッファ時間６秒に達した時点で、再生を開始する。なおサーバ２においては、時刻t1にコンテンツのライブエンコードが開始されており、コンテンツ再生部１３の再生開始には、ネットワーク状況に関わらず、少なくとも６秒間のバッファリング遅延が発生する。ここでは、最小のバッファリング遅延（６秒）で再生が開始されたものとして以下説明する。
【０１２１】
rep1（sample1.ts）の再生中、クライアントとサーバ間のネットワーク状況が良好で、ストリーミング再生に必要なスループットが確保されている場合には、コンテンツ再生部１３には、常にバッファ時間６秒に相当するセグメントデータがバッファされる。一方、クライアント、サーバ間のスループットが低下し、セグメントデータの受信の遅延が発生した場合、コンテンツ再生部１３にバッファされたセグメントデータ量が減少する。例えば、バッファされたセグメントデータが再生期間４秒分になった時点で、コンテンツ再生部１３は再生遅延を検出し、記述情報解析部１２に通知する。
【０１２２】
遅延の通知を受けた記述情報解析部１２は、rep1よりもストリーミング再生に必要なバンド幅の小さいrep2を選択し、クライアント通信部１１にrep1（sample1.ts)の取得中止を指示すると同時に記述情報解析部１２は、切り替え先のサブセグメントを特定するため、rep2のインデックス情報”index2.mp4”の取得をクライアント通信部１１に指示する。
【０１２３】
サーバ２から取得されたインデックス情報index2.mp4は、インデックス情報解析部１４にて解析され、各サブセグメントに関するデータサイズ、再生期間が解析結果として記述情報解析部１２に通知される。なおインデックス情報取得要求を行った時刻tにおいて、サーバ２では、サブセグメントnのライブエンコード及びライブ配信中であるとき、取得されるインデックス情報にはエントリーn-1までが含まれる。つまり記述情報解析部１２には、サブセグメントn-1までの解析結果が通知される。一方、時刻ｔにおいてコンテンツ再生部１３では、サーバ２の配信から６秒遅延したサブセグメントn-3の再生が行われている。また、コンテンツ再生部１３には、４秒分のセグメントデータがバッファされていることから、サブセグメントn-2およびサブセグメントn-1の一部がバッファされている。
【０１２４】
記述情報解析部１２は、サブセグメントn-1に関するインデックス情報の解析結果の通知を受けた時点で、クライアント通信部１１に対し、インデックス情報”index2.mp4”の取得中止を指示すると同時に、rep2を構成するセグメントデータ”sample2.ts”の部分取得を指示する。なおセグメントデータの取得範囲は、サブセグメントn-1以降のデータであり、インデックス情報の解析結果により、サブセグメントn-1のバイトオフセットが指示される。
【０１２５】
サブセグメントn-1以降の”sample2.ts”の受信が開始されると、コンテンツ再生部１３に順次入力され、既にバッファ済みのrep１（”sample1.ts”）と重複する再生期間のデータについては、デコード処理のみが並行して行われ、表示は行わず破棄される。その後、バッファ済みのrep1(”sample1.ts”)の再生完了時点で、rep2の再生に切り替えストリーミング再生が継続され、ユーザは快適にコンテンツを視聴することができる。
【０１２６】
なお、上述の説明では、高品質なリプリゼンテーションの再生を優先するため、rep1、rep2で重複受信した再生期間のデータについて、並行してデコードする構成としたが、このような構成ではクライアント１には複数のデコーダが必要である。したがって、重複再生期間のデータをre1、rep2共にデコードする代わりに、一部のバッファ済みのrep1のサブセグメントデータn-1を破棄し、サブセグメントn-1のデータについては、rep2のデコードおよび表示を行う構成であっても構わない。
【０１２７】
なお、上記の例では、バンド幅の異なるコンテンツに切り替える例を示したが、切り替え対象となるコンテンツはこのような例に限られない。例えば、コンテンツがマルチアングルの映像で構成される場合、異なるアングルのコンテンツにシームレスに切り替えを行ってもよい。また、上記の例では、対応する再生位置に切り替える例を示したが、インデックス情報から特定できる範囲であれば、これ以外の再生位置に切り替えてもよい。つまり、インデックス情報から特定できる範囲におけるタイムシフト再生を行ってもよい。
【０１２８】
以上説明したように、本実施形態のコンテンツ配信システムにおいては、インデックス情報を用いたアダプティブストリーミングが可能であり、ＭＰＤデータの簡素化が実現できる。
【０１２９】
またクライアントは、リプリゼンテーションの切り替え発生時にのみ、インデックス情報及びセグメントデータの取得要求を行うので、ストリーミング中に生じるＨＴＴＰリクエスト回数および通信トラフィックを軽減することができ、クライアント、サーバ間のネットワーク状況が良好で、リプリゼンテーションの切り替えが発生しない場合には、ストリーミング再生開始以降、一切のＨＴＴＰリクエストが不要である。
【０１３０】
またコンテンツはリプリゼンテーション毎に単一のセグメントデータとして提供されるので、ＭＰＤデータやインデックス情報の解析機能を有しない（アダプティブストリーミング機能を有しない）クライアント、例えばＷｅｂブラウザが、当該セグメントデータのＵＲＬの通知を受け、再生を行うことも可能である。
【０１３１】
〔配信方式の選択〕
また、サブセグメント及び／又はエントリーの生成（エンコード）が完了したタイミングでそれらのデータを配信可能とする配信方式（上述の実施形態での配信方式）と、セグメントデータに含まれる全てのサブセグメント及び／又はインデックス情報に含まれる全てのエントリーの生成（エンコード）が完了したタイミングでそれらのデータを配信可能とする配信方式とを選択可能にし、ＭＰＤデータによってこれらの配信方式を識別できるようにしてもよい。
【０１３２】
ここでは、複数の配信方式を識別する方法について、図２１に基づいて説明する。図２１は、配信方式を識別するためのフラグを含むＭＰＤデータの一例を示す図である。
【０１３３】
図示のＭＰＤデータは、SegmentInfoエレメントに、配信方式を示すpartialAvailability属性が付加されている点が、図２のＭＰＤデータと異なる。このpartialAvailability属性は、値として"true"または"false"をとることができる。partialAvailability="true"は、サブセグメント及び／又はエントリーの単位で配信可能であることを示し、partialAvailability="false"は、セグメントデータ及び／又はインデックス情報の単位で配信可能であることを示す。partialAvailability属性の記述が省略された場合、"false"の場合と同様に解釈されるものとする。
【０１３４】
なお、図２１の例では、partialAvailability属性は、SegmentInfoエレメントの属性として記述されているが、これに限られない。例えば、RepresentationエレメントやPeriodエレメント等、SegmentInfoより上位のエレメントの属性として記述してもよい。また、例えばIndexエレメントやUrlエレメント等、SegmentInfoより下位のエレメントの属性として記述してもよい。
【０１３５】
このようなＭＰＤデータを生成する場合、サーバ制御部２６は、記述情報生成部２５に対して、上述の所定の配信パラメータ（リプリゼンテーション数、配信開始時刻、セグメントの再生期間、サブセグメントの再生期間、最小バッファ時間等）に加えて、partialAvailability属性の値を指定して、記述情報生成を指示する。
【０１３６】
これにより、記述情報生成部２５は、サブセグメント（部分再生期間のコンテンツ）を、セグメントデータ（再生期間全体）のエンコードが完了する前に送信可能か否かを示す情報であるpartialAvailability属性を含むＭＰＤデータを生成する。このＭＰＤデータは、記述情報２９としてサーバ記憶部２２に格納される。
【０１３７】
そして、サーバ通信部２１は、クライアント１からのＭＰＤ取得要求に応じて、上記のようにして生成されたＭＰＤデータを、サーバ記憶部２２から読み出してクライアント１に送信する。なお、ＭＰＤデータをクライアント１に取得させる方法はこれに限られない。
【０１３８】
このようなＭＰＤデータを受信したクライアント１は、これを参照することによって、リプリゼンテーションの切り替えを行う場合、上記２種類の配信方式に応じたＨＴＴＰリクエストを送信することができる。具体的には、クライアント１のクライアント通信部１１は、取得したＭＰＤデータのpartialAvailability属性の値が"true"であれば、セグメントに含まれる全てのサブセグメント及び／又はインデックス情報に含まれる全てのエントリーの生成（エンコード）が完了する前であっても、生成（エンコード）が完了したサブセグメントに対応するエントリーを取得できるため、図２０に示すようなバイトレンジ（バイト位置）を指定したＨＴＴＰリクエストを送信することによって、切り替え後のリプリゼンテーションにおける指定したサブセグメント以降のデータを取得することができる。したがって、低遅延での配信を実現することができる。一方、取得したＭＰＤデータのpartialAvailability属性の値が"false"であれば、セグメントに含まれる全てのサブセグメント及び／又はインデックス情報に含まれる全てのエントリーの生成（エンコード）が完了するまでは、それらのデータを取得できない。そのため、該データの生成（エンコード）の完了後に、バイトレンジを指定したＨＴＴＰリクエストを送信する必要があることを認識することができる。
【０１３９】
このように、partialAvailability属性をＭＰＤデータに記述することにより、クライアント１は配信方式に応じた適切なＨＴＴＰリクエストを送信することができる。
【０１４０】
また、サーバ２においても、バイトレンジを指定したＨＴＴＰリクエストに対応する場合には、記述情報生成部２５は、partialAvailability属性の値に"true"を設定したＭＰＤデータを生成し、バイトレンジを指定したＨＴＴＰリクエストに対応しない場合には、partialAvailability属性の値に"false"を設定したＭＰＤデータを生成することで、設計の自由度を高めることができる。
【０１４１】
〔その他の構成例〕
上述の説明では、インデックス情報２８が図３に記載のデータ構造である場合について説明したが、ＤＡＳＨでは、倍速再生等のトリック再生を実現するために、図１１に示すデータ構造のインデックス情報も用いることができる。図１１に示したインデックス情報は、図３に記載のデータ構造の後半部分に、トリック再生を実現するために必要な階層インデックス情報を付与したデータ構造となっている。階層インデックス情報も、サブセグメント単位でエントリー情報を持ち、エントリー毎に、階層数および階層毎にトリック再生のための情報を有している。なお、図１１に示した階層インデックス情報を除く、図３に記載のインデックス情報と同じデータ構造をした部分は、以降の説明では通常インデックス情報と呼び、区別する。
【０１４２】
図１１に示すデータ構造を持つインデックス情報をコンテンツ送受信システム３で用いる場合、通常インデックス情報の配信完了は、前述の通り、ライブストリーミング完了時であるため、クライアント１が、ライブストリーミング中に階層インデックス情報を取得し、トリック再生を実現できない問題がある。この問題を解決するためには、図１２に示すように、通常インデックス情報と、階層インデックス情報をそれぞれ独立のデータとして生成し、図１３のＭＰＤデータに示すように、IndexエレメントとExtIndexエレメントとを記述すればよい。そして、Indexエレメントに通常インデックス情報を参照するためのＵＲＬを記載し、ExtIndexエレメントに階層インデックス情報を参照するためのＵＲＬを記載することで、それぞれ独立に取得できる構成とすればよい。
【０１４３】
あるいは、図１４のインデックス情報のデータ構造例に示すように、通常インデックス情報および、階層インデックス情報のそれぞれのエントリーに含まれる情報を、サブセグメント毎に１つのエントリーに纏めて記載する構成のインデックス情報を用いる構成としてもよい。
【０１４４】
あるいは、図１５のインデックス情報のデータ構造例に示すように、通常インデックス情報および、階層インデックス情報の各エントリーに当該エントリーに有効値が設定されているか否かを示すフィールド”isValid”を設けてもよい。そして、サブセグメントのエンコードが完了する毎に、インデックス情報生成部２４が、エンコード済みのサブセグメントに対応するエントリーにエントリー情報を記述すると共に、”isValid”にそのエントリーが有効なエントリーであることを示す“Ｙｅｓ”を設定する一方、未エンコードのサブセグメントに関するエントリーについては、”isValid”に“Ｎｏ”を設定して無効なエントリーであることを示すことで、インデックス情報全体を生成し、即時配信可能な構成としてもよい。この場合、”isValid”の値を参照することにより、予め定められた数のエントリーのうち、何れのエントリーが有効であるか（エントリー情報を含むか）を特定することができる。
【０１４５】
あるいは、通常インデックス情報、階層インデックス情報のデータ構造は図１１に記載のデータ構造を用い、インデックス情報全体の先頭部分に、当該インデックス情報に含まれる有効エントリー数を記載したインデックス管理情報を備えた図１６に示すデータ構造のインデックス情報を、サブセグメントのエンコード完了毎に生成する構成であってもかまわない。
【０１４６】
また、階層インデックス情報を用いない場合（図２１の例）と同様に、サブセグメント及び／又はエントリー（通常インデックス情報のエントリーと階層インデックス情報のエントリーとを含む）の生成（エンコード）が完了したタイミングでそれらのデータを配信可能とする配信方式と、セグメントデータに含まれる全てのサブセグメント、及び／又は通常インデックス情報に含まれる全てのエントリーと階層インデックス情報に含まれる全てのエントリーの生成（エンコード）が完了したタイミングでそれらのデータを配信可能とする配信方式とを選択可能にし、ＭＰＤデータによってこれらの配信方式を識別できるようにしてもよい。
【０１４７】
これについて、図２２に基づいて説明する。図２２は、配信方式を識別するためのフラグを含むＭＰＤデータの他の一例を示す図である。
【０１４８】
図示のＭＰＤデータは、SegmentInfoエレメントに、配信方式を示すpartialAvailability属性が付加されている点が、図１３のＭＰＤデータと異なる。このpartialAvailability属性は、値として"true"または"false"をとることができる。partialAvailability="true"は、サブセグメント及び／又はエントリーの単位で配信可能であることを示し、partialAvailability="false"は、セグメントデータ、及び／又はインデックス情報（通常インデックス情報と階層インデックス情報を含む）の単位で配信可能であることを示す。partialAvailability属性の記述が省略された場合、"false"の場合と同様に解釈されるものとする。
【０１４９】
なお、図２２の例では、partialAvailability属性は、SegmentInfoエレメントの属性として記述されているが、これに限られない。例えば、RepresentationエレメントやPeriodエレメント等、SegmentInfoより上位のエレメントの属性として記述してもよい。また、例えばIndexエレメント、ExtIndexエレメント、Urlエレメント等、SegmentInfoより下位のエレメントの属性として記述してもよい。
【０１５０】
このようなＭＰＤデータを生成する場合、サーバ制御部２６は、記述情報生成部２５に対して、上述の所定の配信パラメータ（リプリゼンテーション数、配信開始時刻、セグメントの再生期間、サブセグメントの再生期間、最小バッファ時間等）に加えて、partialAvailability属性の値を指定して、記述情報生成を指示する。
【０１５１】
これにより、記述情報生成部２５は、サブセグメント（部分再生期間のコンテンツ）を、セグメントデータ（再生期間全体）のエンコードが完了する前に送信可能か否かを示す情報であるpartialAvailability属性を含むＭＰＤデータを生成する。このＭＰＤデータは、記述情報２９としてサーバ記憶部２２に格納される。
【０１５２】
そして、サーバ通信部２１は、クライアント１からのＭＰＤ取得要求に応じて、上記のようにして生成されたＭＰＤデータを、サーバ記憶部２２から読み出してクライアント１に送信する。なお、ＭＰＤデータをクライアント１に取得させる方法はこれに限られない。
【０１５３】
このようなＭＰＤデータを受信したクライアント１は、これを参照することによって、リプリゼンテーションの切り替えを行う場合、上記２種類の配信方式に応じたＨＴＴＰリクエストを送信することができる。具体的には、クライアント１のクライアント通信部１１は、取得したＭＰＤデータのpartialAvailability属性の値が"true"であれば、セグメントに含まれる全てのサブセグメント及び／又は通常・階層インデックス情報に含まれる全てのエントリーの生成（エンコード）が完了する前であっても、生成（エンコード）が完了したサブセグメントに対応するエントリーを取得できるため、図２０に示すようなバイトレンジ（バイト位置）を指定したＨＴＴＰリクエストを送信することによって、切り替え後のリプリゼンテーションにおける指定したサブセグメント以降のデータを取得することができる。したがって、低遅延での配信を実現することができる。一方、取得したＭＰＤデータのpartialAvailability属性の値が"false"であれば、セグメントに含まれる全てのサブセグメント及び／又は通常・階層インデックス情報に含まれる全てのエントリーの生成（エンコード）が完了するまでは、それらのデータは取得できない。そのため、該データの生成（エンコード）の完了後に、バイトレンジを指定したＨＴＴＰリクエストを送信する必要があることを認識することができる。
【０１５４】
このように、partialAvailability属性をＭＰＤデータに記述することにより、クライアント１は配信方式に応じた適切なＨＴＴＰリクエストを送信することができる。
【０１５５】
また、サーバ２においても、バイトレンジを指定したＨＴＴＰリクエストに対応する場合には、記述情報生成部２５は、partialAvailability属性の値に"true"を設定したＭＰＤデータを生成し、バイトレンジを指定したＨＴＴＰリクエストに対応しない場合には、partialAvailability属性の値に"false"を設定したＭＰＤデータを生成することで、設計の自由度を高めることができる。
【０１５６】
〔ソフトウェアによる構成例〕
最後に、クライアント１及びサーバ２の各ブロックは、集積回路（ＩＣチップ）上に形成された論理回路によってハードウェア的に実現してもよいし、ＣＰＵ（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）、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。
【産業上の利用可能性】
【０１６０】
本発明は、ネットワークを介したコンテンツの送受信システムに利用することができる。
【符号の説明】
【０１６１】
１ クライアント（再生装置）
２ サーバ（送信装置）
１１ クライアント通信部
１２ 記述情報解析部
１３ コンテンツ再生部
１４ インデックス情報解析部
２１ サーバ通信部（参照情報提供手段、記述情報提供手段）
２２ サーバ記憶部
２３ エンコーダ
２４ インデックス情報生成部（参照情報生成手段）
２５ 記述情報生成部（記述情報生成手段）
２６ サーバ制御部
２７ セグメントデータ
２８ インデックス情報（参照情報）
２９ 記述情報
【特許請求の範囲】
【請求項１】
同一の再生期間に対応する複数のコンテンツをエンコードし、エンコードしたコンテンツのうち再生対象として選択されたコンテンツを再生装置に送信する送信装置であって、
上記複数のコンテンツについて予め定めた再生位置までエンコードが進んだときに、上記再生期間のうち上記再生位置までの部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成する参照情報生成手段と、
上記参照情報生成手段が生成した参照情報を上記再生装置に取得させる参照情報提供手段とを備えていることを特徴とする送信装置。
【請求項２】
上記参照情報生成手段は、コンテンツのエンコードが予め定めた再生位置まで進んだときに、該コンテンツの該再生位置までの部分再生期間のデータサイズを示す参照情報を生成し、その後、後続する予め定めた再生位置までエンコードが進む毎に、該コンテンツの該再生位置とその直前の予め定めた再生位置の間の部分再生期間のデータサイズを示す情報を上記参照情報に追加することを特徴とする請求項１に記載の送信装置。
【請求項３】
上記参照情報は、予め定められた数のエントリーと、該エントリーのうち有効なエントリーを示す有効情報を記述する記述領域とを含む情報であり、
上記参照情報生成手段は、コンテンツのエンコードが予め定めた再生位置まで進んだときに、該再生位置までの部分再生期間に対応するエントリーに、該部分再生期間で再生対象のコンテンツを切り替えるための情報を追加すると共に、該エントリーが有効であることを示す有効情報を上記記述領域に記述することを特徴とする請求項１に記載の送信装置。
【請求項４】
上記部分再生期間のコンテンツを、上記再生期間の全体のエンコードが完了する前に送信可能か否かを示す情報を含む記述情報を生成する記述情報生成手段と、
上記記述情報生成手段が生成した記述情報を上記再生装置に取得させる記述情報提供手段とをさらに備えていることを特徴とする請求項１から３の何れか１項に記載の送信装置。
【請求項５】
同一の再生期間に対応する複数のコンテンツをエンコードし、エンコードしたコンテンツのうち再生対象として選択されたコンテンツを再生装置に送信する送信装置の制御方法であって、
上記複数のコンテンツについて予め定めた再生位置までエンコードが進んだときに、上記再生期間のうち上記再生位置までの部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成する参照情報生成ステップと、
上記参照情報生成ステップで生成した参照情報を上記再生装置に取得させる参照情報提供ステップとを含むことを特徴とする送信装置の制御方法。
【請求項６】
請求項１から４の何れか１項に記載の送信装置を動作させるための制御プログラムであって、コンピュータを上記各手段として機能させるための制御プログラム。
【請求項７】
請求項６に記載の制御プログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項１】
同一の再生期間に対応する複数のコンテンツをエンコードし、エンコードしたコンテンツのうち再生対象として選択されたコンテンツを再生装置に送信する送信装置であって、
上記複数のコンテンツについて予め定めた再生位置までエンコードが進んだときに、上記再生期間のうち上記再生位置までの部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成する参照情報生成手段と、
上記参照情報生成手段が生成した参照情報を上記再生装置に取得させる参照情報提供手段とを備えていることを特徴とする送信装置。
【請求項２】
上記参照情報生成手段は、コンテンツのエンコードが予め定めた再生位置まで進んだときに、該コンテンツの該再生位置までの部分再生期間のデータサイズを示す参照情報を生成し、その後、後続する予め定めた再生位置までエンコードが進む毎に、該コンテンツの該再生位置とその直前の予め定めた再生位置の間の部分再生期間のデータサイズを示す情報を上記参照情報に追加することを特徴とする請求項１に記載の送信装置。
【請求項３】
上記参照情報は、予め定められた数のエントリーと、該エントリーのうち有効なエントリーを示す有効情報を記述する記述領域とを含む情報であり、
上記参照情報生成手段は、コンテンツのエンコードが予め定めた再生位置まで進んだときに、該再生位置までの部分再生期間に対応するエントリーに、該部分再生期間で再生対象のコンテンツを切り替えるための情報を追加すると共に、該エントリーが有効であることを示す有効情報を上記記述領域に記述することを特徴とする請求項１に記載の送信装置。
【請求項４】
上記部分再生期間のコンテンツを、上記再生期間の全体のエンコードが完了する前に送信可能か否かを示す情報を含む記述情報を生成する記述情報生成手段と、
上記記述情報生成手段が生成した記述情報を上記再生装置に取得させる記述情報提供手段とをさらに備えていることを特徴とする請求項１から３の何れか１項に記載の送信装置。
【請求項５】
同一の再生期間に対応する複数のコンテンツをエンコードし、エンコードしたコンテンツのうち再生対象として選択されたコンテンツを再生装置に送信する送信装置の制御方法であって、
上記複数のコンテンツについて予め定めた再生位置までエンコードが進んだときに、上記再生期間のうち上記再生位置までの部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成する参照情報生成ステップと、
上記参照情報生成ステップで生成した参照情報を上記再生装置に取得させる参照情報提供ステップとを含むことを特徴とする送信装置の制御方法。
【請求項６】
請求項１から４の何れか１項に記載の送信装置を動作させるための制御プログラムであって、コンピュータを上記各手段として機能させるための制御プログラム。
【請求項７】
請求項６に記載の制御プログラムを記録したコンピュータ読み取り可能な記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【公開番号】特開２０１３−３８７６６（Ｐ２０１３−３８７６６Ａ）
【公開日】平成２５年２月２１日（２０１３．２．２１）
【国際特許分類】
【出願番号】特願２０１２−９９２９６（Ｐ２０１２−９９２９６）
【出願日】平成２４年４月２４日（２０１２．４．２４）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
【公開日】平成２５年２月２１日（２０１３．２．２１）
【国際特許分類】
【出願日】平成２４年４月２４日（２０１２．４．２４）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
[ Back to top ]