JP6294527B2 - 送信装置、送信方法、再生装置、及び再生方法 - Google Patents
送信装置、送信方法、再生装置、及び再生方法 Download PDFInfo
- Publication number
- JP6294527B2 JP6294527B2 JP2017045119A JP2017045119A JP6294527B2 JP 6294527 B2 JP6294527 B2 JP 6294527B2 JP 2017045119 A JP2017045119 A JP 2017045119A JP 2017045119 A JP2017045119 A JP 2017045119A JP 6294527 B2 JP6294527 B2 JP 6294527B2
- Authority
- JP
- Japan
- Prior art keywords
- segment data
- data
- playback
- mpd
- segment
- 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.)
- Expired - Fee Related
Links
Images
Description
本発明は、コンテンツをサーバからクライアントに送信するシステムにおいて、サーバは、異なる符号化パラメータで複数のエンコードを行い、クライアントは、当該コンテンツの受信・再生にあたり、通信環境等の条件に応じて、前記符号化パラメータから適切な再生対象を選択し、当該コンテンツの再生中、前記通信環境の変化に応じて、適切に再生対象を切り替えることを可能とする技術に関する。
従来から、通信ネットワークを介してコンテンツの提供を行う技術が広く用いられている。例えば、下記の特許文献1には、クライアントからサーバにHTTPでコンテンツの要求を送信し、クライアントがこの要求に対する応答として受信したコンテンツをストリーミング再生するコンテンツストリーミングサービスシステムが開示されている。
また、このようなシステムの1つとして、現在、MPEG(Moving Picture Experts Group)にて標準化作業が進められている、非特許文献1に示されるDASH(Dynamic Adaptive Streaming over HTTP)があげられる。DASHでは、MPDデータ(Media Presentation Description)と呼ばれる記述情報(メタデータ)をストリーミング制御に用いる。MPDデータには、コンテンツの属性、コンテンツを構成するリソースの再生順序などが記述される。クライアントは、ストリーミングサービスの事前あるいはサービス途中に、MPDデータを受信し、当該MPDデータを参照して、サーバに要求するリソースを決定する。
このMPDデータは、対象コンテンツの再生期間を複数の再生期間に分割し、分割された再生期間における情報をピリオド(Period)として記述する。また、ピリオド毎に再生されるリソースの情報を示すリプリゼンテーション(Representation)を記述する。1つのピリオドには複数のリプリゼンテーションを記述することができる。つまり、クライアントは、1つの再生期間において、複数のリプリゼンテーションから選択した1つのリプリゼンテーションを再生対象とする。
これにより、例えばビットレートの異なる複数のリプリゼンテーションをMPDデータに記述しておくことにより、クライアントはそのときの通信状況や、自装置の再生能力に応じたビットレートのリプリゼンテーションを選択し、そのリプリゼンテーションで特定されるリソースを取得して再生することができる。
DASHを用いたストリーミング再生動作の詳細について、図17の例を用いて説明する。図17は、DASHを用いたストリーミング再生中に、動的にリプリゼンテーションの切り替えを行う例を示す図であり、同図(a)はサーバとクライアントの処理の一例を示すタイミングチャートであり、同図(b)はクライアントが使用するMPDデータの一例を示している。
まず同図(b)を用いて、MPDデータの詳細について説明する。MPDデータはXMLにて記述されるメタデータである。MPDデータは、ストリーミング配信全体に係る情報を記述するMPDエレメントをルート要素とし、MPDエレメントの属性として、ストリーミング配信形態(type)、ストリーミング再生開始に必要な最小バッファ時間(minBufferTime)、ストリーミング配信の開始時刻(availabilityStartTime)が記述されている。さらに、MPDエレメントは子要素として前述のピリオドを示すPeriodエレメントを(図示の例では1つ)有している。
ピリオドは、前述のリプリゼンテーションを示すRepresentationエレメントを(図示の例では2つ)有している。1つのピリオド中に含まれる複数のリプリゼンテーションは、当該ピリオドにおける再生対象の選択肢を示す。言い換えれば、同一ピリオドに含まれる複数のリプリゼンテーションは、その何れかを選択して再生可能であることを示している。
また、各リプリゼンテーションは、そのリプリゼンテーションに対応する再生対象の属性を有する。リプリゼーションが持つことのできる属性には、コーデック、ビットレート、フレームレート、解像度等の当該再生対象の符号化条件に関する情報(特にコンテンツの再生に関する情報)を記述することができ、クライアントは、これらの属性を参照して、リプリゼンテーションを選択する。
例えば、ある映像コンテンツについて、コーデック、ビットレート、フレームレート、解像度等が異なる複数のリプリゼンテーションが記述されている場合には、クライアントは、自機の再生可能なコーデック、ビットレート、フレームレート、解像度等に応じたリプリゼンテーションを選択する。
図示の例では、属性として、そのリプリゼンテーションの識別子(id)、データ形式を示すMIMEタイプ(mimeType)、及びビットレート(図では当該リプリゼンテーションをストリーミング再生するために必要なネットワークバンド幅:bandwidth)が記述されている。
またピリオドには、SegmentInfoDefaultエレメントおよびSegmentInfoエレメントを用いてセグメントデータに関する情報が記述される。なお、セグメントデータとは、1つのURL(Uniform Resource Locator)で指定される再生対象コンテンツの構成リソースのアクセス単位である。図示の例では、SegmentInfoDefaultエレメントに、当該ピリオドに含まれる全てのセグメントデータに対して適用されるパラメータの規定値が記述されており、各セグメントデータの再生期間(duration)が記述されている。また、前述のリプレゼンテーション毎に、SegmentInfoエレメントが記述され、SegmentInfoエレメントの子要素であるUrlエレメントに各セグメントデータのURLが記述されており、クライアントは当該URLにアクセスすることで選択したリプレゼンテーションを構成するセグメントデータを取得することができる。
図示の例では、各リプリゼンテーションのそれぞれに複数のURLが記述されており、各URLで取得されるセグメントデータの再生期間は、前述のSegmentInfoDefaultエレメントに記載された再生期間が適用され10秒である。つまり、SegmentInfoエレメント内に記述された一番目のURLは、ストリーミング再生開始直後からの10秒間(0秒から10秒)のセグメントデータに対応し、二番目のURLは再生期間が10秒から20秒までのセグメントデータに対応し、三番目のURLは再生期間20秒から30秒までのセグメントデータに対応している。
ここで、図示のように、各リプリゼンテーションの属性には異なる値が記述されている。すなわち、一番目のリプリゼンテーションでは、MIMEタイプにMPEG2-TS(ISO/IEC 13818)を示す"video/mpeg2ts"が記述され、バンド幅が"1024000"と記述されているのに対し、二番目のリプリゼンテーションでは、MIMEタイプは一番目のリプリゼンテーションと同じvideo/mpeg2ts"が記述されているが、バンド幅が"102400"と記述されている。
したがって、クライアントは、このMPDデータを用いた場合、バンド幅が"1024000"
のMPEG2−TS、またはバンド幅が"102400"のMPEG2−TSからなるリプリゼンテーションの何れかを選択することができる。これらのリプリゼンテーションの内容は同一の映像コンテンツあるため、バンド幅に余裕があり、高品質な映像を取得したいときは一番目のリプリゼンテーションを選択し、バンド幅に余裕がないとき等は二番目のリプリゼンテーションを選択すればよい。なお、図示の例では、セグメントデータとして、MPEG2−TSを用いる場合について例示したが、DASHでは、セグメントデータとして、MP4を用いることも可能である。
のMPEG2−TS、またはバンド幅が"102400"のMPEG2−TSからなるリプリゼンテーションの何れかを選択することができる。これらのリプリゼンテーションの内容は同一の映像コンテンツあるため、バンド幅に余裕があり、高品質な映像を取得したいときは一番目のリプリゼンテーションを選択し、バンド幅に余裕がないとき等は二番目のリプリゼンテーションを選択すればよい。なお、図示の例では、セグメントデータとして、MPEG2−TSを用いる場合について例示したが、DASHでは、セグメントデータとして、MP4を用いることも可能である。
同図(a)は、このMPDデータを用いてコンテンツを再生する処理の流れを示している。図示のように、まずクライアントは、サーバにMPDデータの取得要求を送信し、サーバはこの要求に応じてクライアントにMPDデータを送信する。
次に、このMPDデータを取得したクライアントは、MPDデータに記述されているリプリゼンテーションの中から1つのリプリゼンテーションを選択し、選択したリプリゼンテーションに含まれるURLを用いてセグメントデータの取得要求を行う。この例では、一番目のリプリゼンテーションを選択し、その一番目のURLを用いて"Sample-div1.ts"を要求する。なお、MPDデータに記載されたとおり、ストリーミング配信の開始時刻(availabilityStartTime)に合わせて、当該セグメントデータの取得要求は行われる。つまり図示の例では、2011年5月1日12:00に、"Sample-div1.ts"の取得要求が行われる。
この要求を受信したサーバは、要求されたセグメントデータをクライアントに送信する。
なお、セグメントデータは、複数のIPパケットに分割されて、順次クライアントに送信され、送信開始から送信完了に要する時間は、クライアントとサーバを結ぶネットワークのトラフィック等で変化する。
なお、セグメントデータは、複数のIPパケットに分割されて、順次クライアントに送信され、送信開始から送信完了に要する時間は、クライアントとサーバを結ぶネットワークのトラフィック等で変化する。
クライアントは、セグメントデータの受信を開始し、MPDデータに記述されているストリーミング再生開始に必要な最小バッファ時間(minBufferTime)、図示の例では再生期間6秒に相当するセグメントデータを受信した時点で、再生を開始する。
また、"Sample-div1.ts"の受信が完了した時点で、クライアントは後続の"Sample-div2.ts"の取得要求を行い、サーバはこの要求に応じて"Sample-div2.ts"のデータをクライアントに送信する。そして、クライアントはこの受信したセグメントデータを、”Sample-div1.ts”の再生完了後に再生する。
ここで、トラフィックの増大等の要因により、クライアント、サーバ間のスループットが低下し、セグメントデータ受信が遅延したとする。遅延が長時間に渡ると、バッファリングによる再生中断が頻発するようになり、コンテンツの視聴が困難になるので、クライアントは、セグメントデータの切り替えが必要と判断する。同図(b)のMPDデータには、二番目のリプリゼンテーションに必要なバンド幅のより小さいセグメントデータが含まれているので、クライアントは2番目のリプリゼンテーションに再生対象を切り替えることを判断する。
クライアントは、再生期間0秒から20秒に相当する、”Sample1-div1.ts”、”Sample1-div2.ts”の取得要求を既に行っているため、”Sample1-div2.ts”の受信完了後、2番目のリプリゼンテーションの再生期間20秒から30秒のセグメントに相当する、"Sample2-div3.ts"を取得して”sample1-div2.ts”の再生完了後、再生する。以降、2番目のリプリゼンテーションを構成するセグメントデータを順次、受信し再生する。
このようにDASHでは、ネットワーク状況に応じて、動的にセグメントデータ単位でリプリゼンテーションを切り替える、アダプティブストリーミングが可能である。
しかしながら、上述のアダプティブストリーミングを実現するためには、時々刻々と変化するネットワークトラフィックの変化に対応するため、変化の大きいネットワークでは、短期間でリプリゼンテーションの切り替えが可能である必要がある。言い換えれば、リプリゼンテーションの切り替え単位である、セグメントデータの再生期間は、充分に短い(例えば2秒)必要がある。
なお、セグメントデータの再生期間を短く設定することは、MPDデータのデータ量が増大する問題がある。また、コンテンツを再生する際、セグメント取得要求によって生じるネットワークトラフィックが増大する問題がある。
このような問題を解決するために、1つのセグメントデータの再生期間を短く設定する代わりに、セグメントデータを複数のサブセグメントデータに分割し、各サブセグメントデータを参照するためのインデックス情報を記述する方法が提案されている。なお、サブセグメントデータは、セグメントデータを物理的に分割したものではなく、セグメントデータの一部分を、インデックス情報によってサブセグメントデータとして参照可能にしたものである。つまり、インデックス情報はセグメントデータの論理的な分割位置を示す制御情報と言える。
これについて、図18から図20に基づいて説明する。図18は、インデックス情報を用いて、前述の図17で例示したストリーミングを実現するMPDデータの例である。図17(b)のMPDデータと同様、2つのリプリゼンテーションが含まれているが、それぞれのリプリゼンテーションには、セグメントデータが1つだけ含まれている。セグメントデータ”sample1.ts”は、図17のセグメントデータ ”sample1-div1.ts”から”sample1-div180.ts”が連結されたデータあり、セグメントデータ”sample2.ts”は、図17のセグメントデータ ”sample2-div1.ts”から”sample2-div180.ts”が連結されたデータあり、SegmentInfoDefaultエレメントのduration属性が示す通り、再生期間30分が設定されている。また、各セグメントデータのインデックス情報を参照するために記述されたIndexエレメントがSegmentInfoエレメントと対になる形で記述されている。このIndexエレメントには、インデックス情報にアクセスするためのURLが記述されている。
そして、Indexエレメントに記述されたURLにアクセスすることによって、セグメントデータを論理的に分割したサブセグメントを特定するインデックス情報を取得することができる。
図19は、図18で例示した対になるセグメントデータ”sample1.ts”とインデックス情報”index1.mp4”、及びセグメントデータ”sample2.ts”とインデックス情報”index2.mp4”の詳細を説明する図である。図示のように、セグメントデータは、サブセグメント1〜Nからなる。セグメントデータ”sample1.ts”のサブセグメント1〜Nはそれぞれ、図17のセグメントデータ ”sample1-div1.ts”〜”sample1-div180.ts”に相当し、セグメントデータ”sample2.ts”のサブセグメント1〜Nはそれぞれ、図17のセグメントデータ ”sample2-div1.ts”〜”sample2-div180.ts”に相当する。
またセグメントデータ”sample1.ts”におけるサブセグメント1、2、…Nのデータサイズはそれぞれ、S1_1,S1_2,…,S1_Nであり、セグメントデータ”sample2.ts”におけるサブセグメント1、2、…Nのデータサイズはそれぞれ、S2_1,S2_2,…,S2_Nであり、各サブセグメント再生期間は10秒である。
一方、インデックス情報”index1.mp4”、”index2.mp4”には、対象セグメントデー
タ”Sample1.ts”、”Sample2.ts”のサブセグメント毎のデータサイズ、再生期間、各サブセグメントの先頭がランダムアクセスポイントであるか否かを示すRAPフラグがエントリー情報(図中のエントリー1〜N)としてそれぞれ記録されている。
タ”Sample1.ts”、”Sample2.ts”のサブセグメント毎のデータサイズ、再生期間、各サブセグメントの先頭がランダムアクセスポイントであるか否かを示すRAPフラグがエントリー情報(図中のエントリー1〜N)としてそれぞれ記録されている。
なお、DASHにおいて、インデックス情報のデータフォーマットは、セグメントデータのデータフォーマットによらず、MP4形式が用いられ、上述のエントリー情報を管理するエントリー情報管理領域が、インデックス情報先頭に設けられている。
エントリー情報管理領域には、インデックス情報全体のデータサイズSiおよび、当該インデックス情報に含まれるエントリー情報数(対象セグメントデータに含まれるサブセグメント数)Nが記録されている。
したがって、インデックス情報”index1.mp4”、”index2.mp4”を取得することで、クライアントは、対象セグメントデータ内のサブセグメント1〜Nの再生期間がそれぞれ、0〜10秒、10秒〜20秒、…1790秒〜1800秒であること、セグメントデータ内のサブセグメント1〜Nのバイトオフセットを求めることが可能である。
これにより、例えば図20(a)に示すようなHTTPリクエストによって、セグメントデータ“sample2.ts”のサブセグメント2以降、あるいは同図(b)に示すような、バイトレンジ(バイト位置)を指定したHTTPリクエストによって、サブセグメント3以降を取得することが可能であり、サブセグメント単位でのリプリゼンテーション切り替えを実現できる。
上述のインデックス情報を用いてサブセグメント単位でのリプリゼンテーション切り替え(アダプティブストリーミング)を実現する従来技術においては、(1)MPDデータを用いたセグメント単位でリプリゼンテーション切り替え(アダプティブストリーミング)を実現する従来技術に比べ、MPDデータの記述が簡素化される、(2)リプリゼンテーション切り替え時にのみ、インデックス情報およびセグメントデータ(あるいはサブセグメント)の取得要求が発生し、ストリーミング中に生じるHTTPリクエストによる通信トラフィックを軽減することができる、(3)リプリゼンテーションの切り替えが発生しない場合には、インデックス情報を取得する必要がない等の利点がある。
"Information technology-MPEG systems technologies - Part6:Dynamic Adaptive streaming over HTTP(DASH)"、[online]、2011年1月28日、[2011年6月3日検索]、ISO/IEC、インターネット<http://www.itscj.ipsj.or.jp/sc29/open/29view/29n11873t.doc>
その一方で、上記従来技術には、ライブストリーミングに用いた場合に、低遅延での配信を実現できないという問題があった。
具体的には、インデックス情報を利用したサブセグメント単位でのリプリゼンテーション切り替えには、ライブ配信中のセグメントデータに関するインデックス情報が必要となる。しかしながら、前述の通り、インデックス情報には、当該インデックス情報全体のデータサイズや、対象セグメントデータに含まれるサブセグメント数、各サブセグメントのデータサイズ等が含まれており、セグメントデータのエンコードが完了するまでは、生成することができなかった。
したがって、セグメントデータのライブエンコード開始からセグメントデータのライブエンコード完了および当該セグメントデータに対するインデックス情報の生成が完了するまで、セグメントデータおよびインデックス情報の配信開始を遅らせる必要があった。なお、インデックス情報の生成にはほとんど時間を要さないが、セグメントデータのライブエンコード完了には、そのセグメントデータの再生と同じだけの時間を要するので、セグメントデータの再生期間に相当する時間、配信開始を遅らせる必要があったとも言える。
本発明は、上記の問題点に鑑みてなされたものであり、その目的は、セグメントデータの全体の符号化が完了する前にセグメントデータの一部を送信可能にする送信装置等を提供することにある。
上記の課題を解決するために、本発明の送信装置は、複数の再生期間で構成されるコンテンツを符号化し送信する送信装置であって、前記複数の再生期間のうちの1つに対応するセグメントデータを符号化する符号化手段と、前記セグメントデータの全体の符号化が完了する前に前記セグメントデータの一部を送信可能か否かを示すフラグを生成する生成手段と、前記セグメントデータの全体の符号化が完了する前に前記セグメントデータの一部と前記フラグを送信する送信手段と、前記コンテンツに対応し、複数の前記セグメントデータの記述を含むメディアプレゼンテーションデスクリプション(MPD)を生成する生成手段と、前記MPDを送信する送信手段と、を備える。
上記の課題を解決するために、本発明の送信方法は、複数の再生期間で構成されるコンテンツを符号化し送信する送信方法であって、前記複数の再生期間のうちの1つに対応するセグメントデータを符号化するステップと、前記セグメントデータの全体の符号化が完了する前に前記セグメントデータの一部を送信可能か否かを示すフラグを生成するステップと、前記セグメントデータの全体の符号化が完了する前に前記セグメントデータの一部と前記フラグを送信するステップと、前記コンテンツに対応し、複数の前記セグメントデータの記述を含むメディアプレゼンテーションデスクリプション(MPD)を生成するステップと、前記MPDを送信するステップと、を含む。
上記の課題を解決するために、本発明の再生装置は、複数の再生期間で構成されるコンテンツを再生する再生装置であって、前記複数の再生期間のうちの1つに対応するセグメントデータの記述を複数含み、前記コンテンツに対応するメディアプレゼンテーションデスクリプション(MPD)を受信する受信手段と、前記セグメントデータの全体の符号化が完了する前に前記セグメントデータの一部を送信可能か否かを示すフラグを前記MPDから解析する解析手段と、前記フラグが前記セグメントデータの一部を送信可能であることを示す場合、前記セグメントデータの一部を要求する要求手段と、前記セグメントデータの一部を受信する受信手段と、前記セグメントデータの一部を再生する再生手段と、
を備える。
を備える。
上記の課題を解決するために、本発明の再生方法は、複数の再生期間で構成されるコンテンツを再生する再生方法であって、前記複数の再生期間のうちの1つに対応するセグメントデータの記述を複数含み、前記コンテンツに対応するメディアプレゼンテーションデスクリプション(MPD)を受信するステップと、前記セグメントデータの全体の符号化が完了する前に前記セグメントデータの一部を送信可能か否かを示すフラグを前記MPDから解析するステップと、前記フラグが前記セグメントデータの一部を送信可能であることを示す場合、前記セグメントデータの一部を要求するステップと、前記セグメントデータの一部を受信するステップと、前記セグメントデータの一部を再生するステップと、
を含む。
を含む。
上記の構成によれば、送信装置等は、セグメントデータの全体の符号化が完了する前にセグメントデータの一部を送信することができるという効果を奏する。
〔実施の形態1〕
以下、本発明の一実施形態について、図1〜図10に基づいて詳細に説明する。
以下、本発明の一実施形態について、図1〜図10に基づいて詳細に説明する。
〔システムの概要〕
まず、本実施形態のコンテンツ送受信システムの概要を図1に基づいて説明する。図1は、本発明の一実施形態を示すものであり、コンテンツ送受信システム3に含まれるクライアント(再生装置)1とサーバ(送信装置)2の要部構成を示すブロック図である。
まず、本実施形態のコンテンツ送受信システムの概要を図1に基づいて説明する。図1は、本発明の一実施形態を示すものであり、コンテンツ送受信システム3に含まれるクライアント(再生装置)1とサーバ(送信装置)2の要部構成を示すブロック図である。
〔クライアントの構成〕
図示のように、クライアント1は、クライアント1が外部の装置とネットワークを介して通信するためのクライアント通信部11と、記述情報解析部12と、コンテンツ再生部13と、インデックス情報解析部14を備えている。
図示のように、クライアント1は、クライアント1が外部の装置とネットワークを介して通信するためのクライアント通信部11と、記述情報解析部12と、コンテンツ再生部13と、インデックス情報解析部14を備えている。
クライアント通信部11は、記述情報解析部12が選択したリプリゼンテーションを構成するセグメントデータあるいはサブセグメントの取得要求をサーバ2に送信し、これによりセグメントデータあるいはサブセグメントを取得する。また、インデックス情報解析部14の要求するインデックス情報を取得する。ここでは、クライアント通信部11が、HTTPで要求を送信するものとする。
記述情報解析部12は、サーバ2に要求可能なリソースを示す情報をコンテンツの再生期間(ピリオド)毎に含むコンテンツの記述情報を取得し、取得した記述情報に従って、再生対象のリプリゼンテーションを選択する。具体的には、記述情報解析部12は、サーバ2から記述情報としてMPDデータを受信し、再生対象のリプリゼンテーションを決定する。また、コンテンツ再生部13があるリプリゼンテーションのセグメントデータを再生しているときに、リプリゼンテーションの切り替えが必要となる所定の事象を検出した場合に、検出した事象に応じた他のリプリゼンテーションへ再生対象を切り替える決定を行う。
コンテンツ再生部13は、クライアント通信部11の要求によって受信されたセグメントデータあるいはサブセグメントを順に再生する。なお、再生したコンテンツは、クライアント1が備えるディスプレイやスピーカ等から出力してもよいし、クライアント1に有線または無線接続されているディスプレイやスピーカ等から出力してもよい。
インデックス情報解析部14は、クライアント通信部11を介して受信したインデックス情報を解析し、解析結果を記述情報解析部12に通知する。
〔サーバの構成〕
一方、サーバ2は、サーバ通信部21と、サーバ記憶部22と、エンコーダ(符号化手段)23と、インデックス情報生成部24と、記述情報生成部25と、サーバ制御部26とを備える。
一方、サーバ2は、サーバ通信部21と、サーバ記憶部22と、エンコーダ(符号化手段)23と、インデックス情報生成部24と、記述情報生成部25と、サーバ制御部26とを備える。
また、サーバ記憶部22には、サーバ2にて生成、配信される、セグメントデータ27と、インデックス情報28と、記述情報29とが格納される。
サーバ通信部21は、クライアント1からの記述情報の取得要求に応じて、記述情報29をクライアント1に送信する。具体的には、サーバ記憶部22に格納されている記述情報29を読み出して、クライアント1に送信する。上述のように、ここでは記述情報29としてMPDデータを用いる。
またサーバ通信部21は、同様に、クライアント1からのセグメントデータ27の取得要求、あるいはインデックス情報28の取得要求に応じて、サーバ記憶部22に格納されたセグメントデータ27あるいはインデックス情報28を読み出して、クライアント1に送信する。
サーバ制御部26は、サーバ2にて生成、配信されるデータの生成タイミングおよびデータ生成に必要な配信パラメータ等の情報を、エンコーダ23、インデックス情報生成部24、記述情報生成部25に指示する。
エンコーダ23は、カメラ等(図示せず)で撮影され、外部からライブ入力されるコンテンツを、サーバ制御部26にて指示されたリプリゼンテーション毎のエンコード条件(符号化パラメータ)に従って、それぞれエンコードしてセグメントデータ27を生成し、サーバ記憶部22に格納する。なお、同一ピリオドにおける複数のリプリゼンテーションは、同時並行でライブエンコードが行われ、リプリゼンテーション毎に1つのセグメントデータ27が生成される。
インデックス情報生成部24は、各セグメントデータ27について、そのセグメントデータ27に含まれるサブセグメント単位で切り替えを行うためのインデックス情報28を生成する。なお、インデックス情報28及びその生成方法の詳細については後述する。
セグメントデータ27は、前述の通り、クライアント1に提供可能なコンテンツを所定のエンコード条件に従ってエンコードし、所定の再生期間単位で分割したデータである。
インデックス情報28は、サブセグメントデータでの切り替えを可能にするための情報である。クライアント1は、インデックス情報28を参照することによってサブセグメントデータの位置を特定し、サブセグメントデータ単位で再生対象を切り替えることができる。
記述情報29は、サーバ2からクライアント1に提供可能なコンテンツ(ここでは、サーバ記憶部22に格納されるセグメントデータ27)に関する情報である。具体的には、記述情報29は、選択候補を示すリプリゼンテーションがピリオド毎に記述されたMPDデータである。MPDデータの詳細は後述する。
なお、セグメントデータ27、インデックス情報28、及び記述情報29の少なくとも1つは、サーバ2に着脱可能な外部の記録媒体に記録されていてもよいし、サーバ2がアクセス可能な外部の装置に記憶されていてもよい。すなわち、セグメントデータ27、インデックス情報28、及び記述情報29は、サーバ2が取得可能な状態で格納されていればよく、格納先は特に限定されない。
また、コンテンツ送受信システムが複数のサーバ2によって構成され、セグメントデータ27、インデックス情報28、及び記述情報29のそれぞれが異なるサーバ2から提供される構成であっても構わない。
〔システムで用いるデータの詳細〕
図2はコンテンツ送受信システム3で用いるMPDデータの一例である。ストリーミングの配信形態を示すMPDエレメントのType属性がライブストリーミングである点を除けば前述の図18のMPDデータと同じであり、詳細な説明を省略する。
図2はコンテンツ送受信システム3で用いるMPDデータの一例である。ストリーミングの配信形態を示すMPDエレメントのType属性がライブストリーミングである点を除けば前述の図18のMPDデータと同じであり、詳細な説明を省略する。
図3は図2に示すMPDデータと共にコンテンツ送受信システム3で用いるセグメントデータ及びインデック情報の一例を示す図である。ライブストリーミングでのアダプティブストリーミングを実現するために、サブセグメントの再生期間が前述の図19に示す例より短い2秒に設定されている点を除き図19と同じであり、詳細な説明を省略する。
〔サーバ2で行われる処理の詳細〕
次に、コンテンツ送受信システム3におけるサーバ2の動作について、詳細を図4〜9に基づいて説明する。
次に、コンテンツ送受信システム3におけるサーバ2の動作について、詳細を図4〜9に基づいて説明する。
図4は、コンテンツ送受信システム3において、アダプティブストリーミングを実現するためのインデックス情報を生成するインデックス情報生成部24の動作を示すフローチャートである。
コンテンツ送受信システム3においてライブストリーミングが開始されると、インデックス情報生成部24は、インデックス情報におけるエントリー情報管理領域を生成する(S1)。前述の通り、エントリー情報管理領域には、インデックス情報全体のデータサイズSiとエントリー数(サブセグメント数)Nを記述する必要がある。エントリー情報管理領域のデータサイズおよび各エントリーのデータサイズは固定長であるため、セグメントデータに含まれるサブセグメント数が確定していれば、エントリー情報管理領域を生成することができる。
例えば、図2に示したMPDデータを用いたライブ配信を行う場合、ライブストリーミング開始時点で、セグメントデータの再生期間30分、サブセグメントの再生期間2秒が配信パラメータとして、サーバ制御部26から入力されることにより、サブセグメント数が1800に確定されるので、エントリー情報管理領域は即時生成される。
次に、インデックス情報生成部24は、エントリー生成のため、エンコーダ23でのサブセグメントエンコード完了を待つ(S2)。
エンコーダ23にてサブセグメントのエンコードが完了したことがエンコーダ23から通知されると、インデックス情報生成部24は当該サブセグメントに対する新規エントリーを生成(参照情報生成ステップ)し、インデックス情報に追加する(S3)。なお、エントリーには、サブセグメントのデータサイズ、再生期間、RAPフラグを記載する。サブセグメントのデータサイズは、サブセグメントのエンコード完了通知時にエンコーダ23から通知された値が設定される。サブセグメントの再生期間については、サーバ制御部26からの配信パラメータで与えられた2秒が設定される。なお本システムにおいてサブセグメントは、アダプティブストリーミングを実現する際の、リプリゼンテーションの切り替えポイントであるため、常にランダムアクセスポイントとしてエンコードが行われることから、RAPフラグは常にYesが設定される。
生成したエントリー数がS1で求めたエントリー数N未満の場合(S4でYesの場合)、S2に戻って処理を継続し、生成したエントリー数がNに達した場合(S4でNoの場合)、インデックス情報の生成を終了する。
次に、サーバにおける各データの生成タイミングと、当該データの配信可能タイミングに係るサーバ動作を図5〜9を用いて説明する。図5は、サーバ2におけるMPDデータ生成タイミングおよびMPDデータ配信可能タイミングに係る動作を説明するためのタイミングチャートである。
図5において、時刻t0はMPDデータの生成開始時刻である。時刻t0になると、MPDデータの生成開始のため、サーバ制御部26が記述情報生成部25に対し、所定の配信パラメータにて記述情報生成を指示する。記述情報生成部25は、記述情報生成指示を受け、指定された配信パラメータ(リプリゼンテーション数、配信開始時刻、セグメントの再生期間、サブセグメントの再生期間、最小バッファ時間等)に基づき記述情報を生成する。なお、サーバ制御部26は、クライアントでのアダプティブストリーミングを実現するため、最小バッファ時間に複数のサブセグメントが含まれるよう配信パラメータを制御する。例えば、図2、図3のデータ構成の場合、最小バッファ時間は6秒に設定されており、サブセグメントの再生期間は2秒に設定されている。記述情報生成部25は、即時、MPDデータを生成し、サーバ記憶部22に生成したMPDデータを格納する。
時刻t0は、クライアント1がMPDデータを取得可能となる時刻でもある。時刻t0に、サーバ通信部21がクライアント1からのMPD取得要求を受けると、サーバ記憶部22に、要求されたMPDデータが存在するか否かを検索する。図5に示す通り、当該検索実行時には、既にMPDデータの生成が完了しており、サーバ通信部21は、当該MPDデータをサーバ記憶部22から読み出し、クライアント1へ送信する。なお、図5において、MPD取得要求から応答までに、タイムラグ(Δt)が生じているが、このタイムラグΔtは、ユーザが遅延を体感できるほどに大きなものでなく、充分短い時間である。
なお、サーバ2において、生成されたMPDデータはサーバ記憶部22に保存されているため、t0以降の任意の時刻tにおいてクライアント1はMPDデータの取得が可能である。
図6は、サーバ2におけるセグメントデータ生成タイミングおよびセグメントデータ配信可能タイミングに係る動作を説明するためのタイミングチャートである。
図6において、時刻t1は、サーバ2におけるライブエンコードの開始時刻である。また図中のセグメントデータ[n,m]は、セグメントデータ内のサブセグメントnにおけるm番目のデータを表している。なおセグメントデータ[n,m]は、入力コンテンツ[n,m]のエンコーダ23によるエンコード結果である。
時刻t1になると、セグメントデータのライブエンコードのため、サーバ制御部26がエンコーダ23に対し、所定の配信パラメータにてエンコード開始を指示する。エンコーダ23は、指定された配信パラメータ(コーデック、ビットレート、画像サイズ、セグメントの再生期間、サブセグメントの再生期間等)に基づきエンコードを開始する。なお、配信パラメータはリプリゼンテーション毎にエンコーダ23に与えられる。
エンコーダ23は、コンテンツの入力があると、複数の配信パラメータで並行してセグメントデータのエンコードを行う。図2の例では、2つのリプリゼンテーションが存在するため、エンコーダ23は、2つのセグメントデータについて並行してエンコードを行う。なお、図示の通り、コンテンツ[1,1]がエンコーダ23に入力されると、即時セグメントデータ[1,1]へライブエンコードされ、サーバ記憶部22に格納される。以降、エンコーダ23にコンテンツ[1,2]、コンテンツ[1,3]、コンテンツ[1,4]、…と順次コンテンツが入力される毎に、セグメントデータ[1,2]、セグメントデータ[1,3]、セグメントデータ[1,4]、…がエンコードされ、サーバ記憶部22のセグメントデータに追加される。
また、時刻t1は、セグメントデータの配信開始時刻(図2のMPDデータにおいては、availabilityStartTime属性に設定された、”2011年5月1日12:00”)でもある。前述のMPDデータの場合と同様、時刻t1以降にクライアント1からセグメントデータの取得要求を受けたサーバ通信部21は、サーバ記憶部22に要求されたセグメントデータが存在するか否かを検索する。図6に示す通り、サーバ通信部21は、当該セグメントデータが一部でも存在していれば(図中では検索時にセグメントデータ[1,1]存在)、クライアント1に送信を開始する。以降、残りのセグメントデータが追加される毎に、順次クライアント1に送信する。
図7は、サーバ2におけるサブセグメント生成タイミングおよびサブセグメント配信可能タイミングに係る動作を説明するためのタイミングチャートである。
図7において、時刻tnは、サブセグメントnを生成開始される時刻である。図示のとおり、時刻tnにおいて、カメラからサブセグメントnの先頭データであるコンテンツ[n,1]が入力され、当該コンテンツ[n,1]は、エンコーダ23にてサブセグメントnの先頭データ(セグメントデータ[n,1])としてエンコードされ、サーバ記憶部22に格納されたセグメントデータに追記される。
また、時刻tnは、サブセグメントnの配信開始時刻でもある。前述のセグメントデータの場合と同様に、時刻tn以降にクライアント1からサブセグメントデータnで開始されるセグメントデータの部分取得要求を受けたサーバ通信部21は、サーバ記憶部22に要求されたセグメントデータが存在するか否かを検索する。なお、セグメントデータの部分取得要求は、図20の例で示した通り、セグメントデータの取得開始バイト位置指定によって行われる。従ってサーバ通信部21は、要求されたセグメントデータが存在する場合、さらに指定された取得開始バイト位置のデータが存在するかを確認し、指定バイト位置のデータが存在すれば、クライアント1に送信を開始する。
図8は、サーバ2におけるインデックス情報生成タイミングおよびインデックス情報配信可能タイミングに係る動作を説明するためのタイミングチャートである。
図8において、時刻t1は図6で説明した時刻t1と同時刻を示しており、インデックス情報の生成が開始される時刻である。時刻t1になると、インデックス情報の生成のため、サーバ制御部26がインデックス情報生成部24に対し、所定の配信パラメータに基づきインデックス情報生成を指示する。インデックス情報生成部24は、前述の通り、指定された配信パラメータ(セグメントの再生期間、サブセグメントの再生期間)に基づきインデックス情報の生成を開始する。時刻t1においては、エントリー情報管理領域のみが生成され、サーバ記憶部22に格納される。なお、インデックス情報もまた、セグメントデータと同様、配信されるリプリゼンテーション数に応じて、複数のインデックス情報が並行して生成される。
また時刻t1は、インデックス情報の配信開始時刻でもある。つまり時刻t1において、クライアント1は、セグメントデータ、インデックス情報共に受信可能となる。時刻t1以降にクライアント1からインデックス情報の取得要求を受けたサーバ通信部21は、サーバ記憶部22に要求されたインデックス情報が存在するか否かを検索する。図8に示す通り、サーバ通信部21は、当該インデックス情報が一部でも存在していれば(図中では検索時にエントリー情報管理領域のみ存在)、クライアント1に送信を開始する。以降、インデックス情報にエントリーが追加される毎に、順次クライアント1に送信する。
図9は、サーバ2におけるインデックス情報の各エントリー情報の生成タイミングおよび各エントリー情報配信可能タイミングに係る動作を説明するためのタイミングチャートである。
図9において、時刻tnは、図7で説明した時刻tnと同時刻(サブセグメントnの生成開始時刻)を示しており、インデックス情報のエントリーn-1が生成される時刻である。
図示のとおり、エンコーダ23は、時刻tnにおいて、サブセグメントn-1の生成を完了し、サブセグメントnの生成を開始する。サブセグメントn-1の生成を完了したエンコーダ23は、インデックス情報生成部24にサブセグメントn-1の生成完了を通知する。
サブセグメントn-1の生成完了の通知を受けたインデックス情報生成部24は、インデックス情報のエントリーn-1を生成し、サーバ記憶部22に格納されたインデックス情報に追加する。
また時刻tnは、インデックス情報のエントリn-1の配信開始時刻でもある。図示の通り、tn>tである時刻tにクライアント1からインデックス情報の取得要求を受けた前述のセグメントデータの場合と同様、時刻tn以降にクライアント1からサブセグメントデータnで開始されるセグメントデータの部分取得要求を受けたサーバ通信部21は、サーバ記憶部22に要求されたインデックス情報が存在するか否かを検索する。インデックス情報の一部が存在すれば、サーバ通信部21は、順次データをクライアント1に送信する。
時刻tnの直前では、インデックス情報としてエントリーn-2までがサーバ記憶部22に格納されているため、エントリーn-2までの送信が可能である。前述のとおり、時刻tnにおいて、エントリーn-1が生成されサーバ記憶部22に即時追加される。サーバ通信部21は、追加されたエントリーn-1を即時クライアント1に送信する。
以上説明した通り、サーバ2はセグメントデータにおけるサブセグメントnの配信開始時刻tnにおいて、インデックス情報として当該セグメントデータのサブセグメント1〜サブセグメントn-1までの情報をクライアント1に配信することが可能である。
〔クライアント1で行われる処理の詳細〕
次に、インデックス情報を用いたアダプティブストリーミング再生の詳細について図10に基づいて説明する。
次に、インデックス情報を用いたアダプティブストリーミング再生の詳細について図10に基づいて説明する。
図10は、ストリーミング再生中にリプリゼンテーション切り替えが発生した場合におけるクライアント1の動作を示すタイミングチャートである。
まずクライアント1は、MPDデータの配信開時刻t0(図5に示したt0と同時刻)において、記述情報解析部12が、クライアント通信部11に対しMPDデータの取得を指示し、クライアント通信部11が、サーバ2に対し、MPDデータの取得要求を発行する。
記述情報解析部12は、クライアント通信部11を介して図2に示したMPDデータを受信する。ストリーミング開始時の再生対象として,id=”rep1”で示されるリプリゼンテーションを選択し、ストリーミング開始時刻(t0: 2011年5月1日12:00)になるまで待機する。
ストリーミング開始時刻t1において、記述情報解析部12は、クライアント通信部11に対し、id=”rep1”で示されるリプリゼンテーションを構成するセグメントデータ”sample1.ts”の取得を指示し、クライアント通信部11が、サーバ2に対し、セグメントデータ”sample1.ts”の取得要求を発行する。
また記述情報解析部12は、MPDデータに記載された最小バッファ時間に基づき、バッファ時間をコンテンツ再生部13に指示する。図2のMPDデータでは、最小バッファ時間が6秒に設定されているため、この値を指示する。
サーバ2から受信したセグメントデータ”sample1.ts”は、順次コンテンツ再生部13に入力される。コンテンツ再生部13は、受信したセグメントデータの再生期間が指示されたバッファ時間6秒に達するまで、再生を開始せず、バッファリングを行う。
コンテンツ再生部13は、受信したセグメントデータの再生期間がバッファ時間6秒に達した時点で、再生を開始する。なおサーバ2においては、時刻t1にコンテンツのライブエンコードが開始されており、コンテンツ再生部13の再生開始には、ネットワーク状況に関わらず、少なくとも6秒間のバッファリング遅延が発生する。ここでは、最小のバッファリング遅延(6秒)で再生が開始されたものとして以下説明する。
rep1(sample1.ts)の再生中、クライアントとサーバ間のネットワーク状況が良好で、ストリーミング再生に必要なスループットが確保されている場合には、コンテンツ再生部13には、常にバッファ時間6秒に相当するセグメントデータがバッファされる。一方、クライアント、サーバ間のスループットが低下し、セグメントデータの受信の遅延が発生した場合、コンテンツ再生部13にバッファされたセグメントデータ量が減少する。例えば、バッファされたセグメントデータが再生期間4秒分になった時点で、コンテンツ再生部13は再生遅延を検出し、記述情報解析部12に通知する。
遅延の通知を受けた記述情報解析部12は、rep1よりもストリーミング再生に必要なバンド幅の小さいrep2を選択し、クライアント通信部11にrep1(sample1.ts)の取得中止を指示すると同時に記述情報解析部12は、切り替え先のサブセグメントを特定するため、rep2のインデックス情報”index2.mp4”の取得をクライアント通信部11に指示する。
サーバ2から取得されたインデックス情報index2.mp4は、インデックス情報解析部14にて解析され、各サブセグメントに関するデータサイズ、再生期間が解析結果として記述情報解析部12に通知される。なおインデックス情報取得要求を行った時刻tにおいて、サーバ2では、サブセグメントnのライブエンコード及びライブ配信中であるとき、取得されるインデックス情報にはエントリーn-1までが含まれる。つまり記述情報解析部12には、サブセグメントn-1までの解析結果が通知される。一方、時刻tにおいてコンテンツ再生部13では、サーバ2の配信から6秒遅延したサブセグメントn-3の再生が行われている。また、コンテンツ再生部13には、4秒分のセグメントデータがバッファされていることから、サブセグメントn-2およびサブセグメントn-1の一部がバッファされている。
記述情報解析部12は、サブセグメントn-1に関するインデックス情報の解析結果の通知を受けた時点で、クライアント通信部11に対し、インデックス情報”index2.mp4”の取得中止を指示すると同時に、rep2を構成するセグメントデータ”sample2.ts”の部分取得を指示する。なおセグメントデータの取得範囲は、サブセグメントn-1以降のデータであり、インデックス情報の解析結果により、サブセグメントn-1のバイトオフセットが指示される。
サブセグメントn-1以降の”sample2.ts”の受信が開始されると、コンテンツ再生部13に順次入力され、既にバッファ済みのrep1(”sample1.ts”)と重複する再生期間のデータについては、デコード処理のみが並行して行われ、表示は行わず破棄される。その後、バッファ済みのrep1(”sample1.ts”)の再生完了時点で、rep2の再生に切り替えストリーミング再生が継続され、ユーザは快適にコンテンツを視聴することができる。
なお、上述の説明では、高品質なリプリゼンテーションの再生を優先するため、rep1、rep2で重複受信した再生期間のデータについて、並行してデコードする構成としたが、このような構成ではクライアント1には複数のデコーダが必要である。したがって、重複再生期間のデータをre1、rep2共にデコードする代わりに、一部のバッファ済みのrep1のサブセグメントデータn-1を破棄し、サブセグメントn-1のデータについては、rep2のデコードおよび表示を行う構成であっても構わない。
なお、上記の例では、バンド幅の異なるコンテンツに切り替える例を示したが、切り替え対象となるコンテンツはこのような例に限られない。例えば、コンテンツがマルチアングルの映像で構成される場合、異なるアングルのコンテンツにシームレスに切り替えを行ってもよい。また、上記の例では、対応する再生位置に切り替える例を示したが、インデックス情報から特定できる範囲であれば、これ以外の再生位置に切り替えてもよい。つまり、インデックス情報から特定できる範囲におけるタイムシフト再生を行ってもよい。
以上説明したように、本実施形態のコンテンツ配信システムにおいては、インデックス情報を用いたアダプティブストリーミングが可能であり、MPDデータの簡素化が実現できる。
またクライアントは、リプリゼンテーションの切り替え発生時にのみ、インデックス情報及びセグメントデータの取得要求を行うので、ストリーミング中に生じるHTTPリクエスト回数および通信トラフィックを軽減することができ、クライアント、サーバ間のネットワーク状況が良好で、リプリゼンテーションの切り替えが発生しない場合には、ストリーミング再生開始以降、一切のHTTPリクエストが不要である。
またコンテンツはリプリゼンテーション毎に単一のセグメントデータとして提供されるので、MPDデータやインデックス情報の解析機能を有しない(アダプティブストリーミング機能を有しない)クライアント、例えばWebブラウザが、当該セグメントデータのURLの通知を受け、再生を行うことも可能である。
〔配信方式の選択〕
また、サブセグメント及び/又はエントリーの生成(エンコード)が完了したタイミングでそれらのデータを配信可能とする配信方式(上述の実施形態での配信方式)と、セグメントデータに含まれる全てのサブセグメント及び/又はインデックス情報に含まれる全てのエントリーの生成(エンコード)が完了したタイミングでそれらのデータを配信可能とする配信方式とを選択可能にし、MPDデータによってこれらの配信方式を識別できるようにしてもよい。
また、サブセグメント及び/又はエントリーの生成(エンコード)が完了したタイミングでそれらのデータを配信可能とする配信方式(上述の実施形態での配信方式)と、セグメントデータに含まれる全てのサブセグメント及び/又はインデックス情報に含まれる全てのエントリーの生成(エンコード)が完了したタイミングでそれらのデータを配信可能とする配信方式とを選択可能にし、MPDデータによってこれらの配信方式を識別できるようにしてもよい。
ここでは、複数の配信方式を識別する方法について、図21に基づいて説明する。図21は、配信方式を識別するためのフラグを含むMPDデータの一例を示す図である。
図示のMPDデータは、SegmentInfoエレメントに、配信方式を示すpartialAvailability属性が付加されている点が、図2のMPDデータと異なる。このpartialAvailability属性は、値として"true"または"false"をとることができる。partialAvailability="true"は、サブセグメント及び/又はエントリーの単位で配信可能であることを示し、partialAvailability="false"は、セグメントデータ及び/又はインデックス情報の単位で配信可能であることを示す。partialAvailability属性の記述が省略された場合、"false"の場合と同様に解釈されるものとする。
なお、図21の例では、partialAvailability属性は、SegmentInfoエレメントの属性として記述されているが、これに限られない。例えば、RepresentationエレメントやPeriodエレメント等、SegmentInfoより上位のエレメントの属性として記述してもよい。また、例えばIndexエレメントやUrlエレメント等、SegmentInfoより下位のエレメントの属性として記述してもよい。
このようなMPDデータを生成する場合、サーバ制御部26は、記述情報生成部25に対して、上述の所定の配信パラメータ(リプリゼンテーション数、配信開始時刻、セグメントの再生期間、サブセグメントの再生期間、最小バッファ時間等)に加えて、partialAvailability属性の値を指定して、記述情報生成を指示する。
これにより、記述情報生成部25は、サブセグメント(部分再生期間のコンテンツ)を、セグメントデータ(再生期間全体)のエンコードが完了する前に送信可能か否かを示す情報であるpartialAvailability属性を含むMPDデータを生成する。このMPDデータは、記述情報29としてサーバ記憶部22に格納される。
そして、サーバ通信部21は、クライアント1からのMPD取得要求に応じて、上記のようにして生成されたMPDデータを、サーバ記憶部22から読み出してクライアント1に送信する。なお、MPDデータをクライアント1に取得させる方法はこれに限られない。
このようなMPDデータを受信したクライアント1は、これを参照することによって、リプリゼンテーションの切り替えを行う場合、上記2種類の配信方式に応じたHTTPリクエストを送信することができる。具体的には、クライアント1のクライアント通信部11は、取得したMPDデータのpartialAvailability属性の値が"true"であれば、セグメントに含まれる全てのサブセグメント及び/又はインデックス情報に含まれる全てのエントリーの生成(エンコード)が完了する前であっても、生成(エンコード)が完了したサブセグメントに対応するエントリーを取得できるため、図20に示すようなバイトレンジ(バイト位置)を指定したHTTPリクエストを送信することによって、切り替え後のリプリゼンテーションにおける指定したサブセグメント以降のデータを取得することができる。したがって、低遅延での配信を実現することができる。一方、取得したMPDデータのpartialAvailability属性の値が"false"であれば、セグメントに含まれる全てのサブセグメント及び/又はインデックス情報に含まれる全てのエントリーの生成(エンコード)が完了するまでは、それらのデータを取得できない。そのため、該データの生成(エンコード)の完了後に、バイトレンジを指定したHTTPリクエストを送信する必要があることを認識することができる。
このように、partialAvailability属性をMPDデータに記述することにより、クライアント1は配信方式に応じた適切なHTTPリクエストを送信することができる。
また、サーバ2においても、バイトレンジを指定したHTTPリクエストに対応する場合には、記述情報生成部25は、partialAvailability属性の値に"true"を設定したMP
Dデータを生成し、バイトレンジを指定したHTTPリクエストに対応しない場合には、partialAvailability属性の値に"false"を設定したMPDデータを生成することで、設計の自由度を高めることができる。
Dデータを生成し、バイトレンジを指定したHTTPリクエストに対応しない場合には、partialAvailability属性の値に"false"を設定したMPDデータを生成することで、設計の自由度を高めることができる。
〔その他の構成例〕
上述の説明では、インデックス情報28が図3に記載のデータ構造である場合について説明したが、DASHでは、倍速再生等のトリック再生を実現するために、図11に示すデータ構造のインデックス情報も用いることができる。図11に示したインデックス情報は、図3に記載のデータ構造の後半部分に、トリック再生を実現するために必要な階層インデックス情報を付与したデータ構造となっている。階層インデックス情報も、サブセグメント単位でエントリー情報を持ち、エントリー毎に、階層数および階層毎にトリック再生のための情報を有している。なお、図11に示した階層インデックス情報を除く、図3に記載のインデックス情報と同じデータ構造をした部分は、以降の説明では通常インデックス情報と呼び、区別する。
上述の説明では、インデックス情報28が図3に記載のデータ構造である場合について説明したが、DASHでは、倍速再生等のトリック再生を実現するために、図11に示すデータ構造のインデックス情報も用いることができる。図11に示したインデックス情報は、図3に記載のデータ構造の後半部分に、トリック再生を実現するために必要な階層インデックス情報を付与したデータ構造となっている。階層インデックス情報も、サブセグメント単位でエントリー情報を持ち、エントリー毎に、階層数および階層毎にトリック再生のための情報を有している。なお、図11に示した階層インデックス情報を除く、図3に記載のインデックス情報と同じデータ構造をした部分は、以降の説明では通常インデックス情報と呼び、区別する。
図11に示すデータ構造を持つインデックス情報をコンテンツ送受信システム3で用いる場合、通常インデックス情報の配信完了は、前述の通り、ライブストリーミング完了時であるため、クライアント1が、ライブストリーミング中に階層インデックス情報を取得し、トリック再生を実現できない問題がある。この問題を解決するためには、図12に示すように、通常インデックス情報と、階層インデックス情報をそれぞれ独立のデータとして生成し、図13のMPDデータに示すように、IndexエレメントとExtIndexエレメントとを記述すればよい。そして、Indexエレメントに通常インデックス情報を参照するためのURLを記載し、ExtIndexエレメントに階層インデックス情報を参照するためのURLを記載することで、それぞれ独立に取得できる構成とすればよい。
あるいは、図14のインデックス情報のデータ構造例に示すように、通常インデックス情報および、階層インデックス情報のそれぞれのエントリーに含まれる情報を、サブセグメント毎に1つのエントリーに纏めて記載する構成のインデックス情報を用いる構成としてもよい。
あるいは、図15のインデックス情報のデータ構造例に示すように、通常インデックス情報および、階層インデックス情報の各エントリーに当該エントリーに有効値が設定されているか否かを示すフィールド”isValid”を設けてもよい。そして、サブセグメントのエンコードが完了する毎に、インデックス情報生成部24が、エンコード済みのサブセグメントに対応するエントリーにエントリー情報を記述すると共に、”isValid”にそのエントリーが有効なエントリーであることを示す“Yes”を設定する一方、未エンコードのサブセグメントに関するエントリーについては、”isValid”に“No”を設定して無効なエントリーであることを示すことで、インデックス情報全体を生成し、即時配信可能な構成としてもよい。この場合、”isValid”の値を参照することにより、予め定められた数のエントリーのうち、何れのエントリーが有効であるか(エントリー情報を含むか)を特定することができる。
あるいは、通常インデックス情報、階層インデックス情報のデータ構造は図11に記載のデータ構造を用い、インデックス情報全体の先頭部分に、当該インデックス情報に含まれる有効エントリー数を記載したインデックス管理情報を備えた図16に示すデータ構造のインデックス情報を、サブセグメントのエンコード完了毎に生成する構成であってもかまわない。
また、階層インデックス情報を用いない場合(図21の例)と同様に、サブセグメント及び/又はエントリー(通常インデックス情報のエントリーと階層インデックス情報のエントリーとを含む)の生成(エンコード)が完了したタイミングでそれらのデータを配信可能とする配信方式と、セグメントデータに含まれる全てのサブセグメント、及び/又は通常インデックス情報に含まれる全てのエントリーと階層インデックス情報に含まれる全てのエントリーの生成(エンコード)が完了したタイミングでそれらのデータを配信可能とする配信方式とを選択可能にし、MPDデータによってこれらの配信方式を識別できるようにしてもよい。
これについて、図22に基づいて説明する。図22は、配信方式を識別するためのフラグを含むMPDデータの他の一例を示す図である。
図示のMPDデータは、SegmentInfoエレメントに、配信方式を示すpartialAvailability属性が付加されている点が、図13のMPDデータと異なる。このpartialAvailability属性は、値として"true"または"false"をとることができる。partialAvailability="true"は、サブセグメント及び/又はエントリーの単位で配信可能であることを示し、partialAvailability="false"は、セグメントデータ、及び/又はインデックス情報(通常インデックス情報と階層インデックス情報を含む)の単位で配信可能であることを示す。partialAvailability属性の記述が省略された場合、"false"の場合と同様に解釈されるものとする。
なお、図22の例では、partialAvailability属性は、SegmentInfoエレメントの属性として記述されているが、これに限られない。例えば、RepresentationエレメントやPeriodエレメント等、SegmentInfoより上位のエレメントの属性として記述してもよい。また、例えばIndexエレメント、ExtIndexエレメント、Urlエレメント等、SegmentInfoより下位のエレメントの属性として記述してもよい。
このようなMPDデータを生成する場合、サーバ制御部26は、記述情報生成部25に対して、上述の所定の配信パラメータ(リプリゼンテーション数、配信開始時刻、セグメントの再生期間、サブセグメントの再生期間、最小バッファ時間等)に加えて、partialAvailability属性の値を指定して、記述情報生成を指示する。
これにより、記述情報生成部25は、サブセグメント(部分再生期間のコンテンツ)を、セグメントデータ(再生期間全体)のエンコードが完了する前に送信可能か否かを示す情報であるpartialAvailability属性を含むMPDデータを生成する。このMPDデータは、記述情報29としてサーバ記憶部22に格納される。
そして、サーバ通信部21は、クライアント1からのMPD取得要求に応じて、上記のようにして生成されたMPDデータを、サーバ記憶部22から読み出してクライアント1に送信する。なお、MPDデータをクライアント1に取得させる方法はこれに限られない。
このようなMPDデータを受信したクライアント1は、これを参照することによって、リプリゼンテーションの切り替えを行う場合、上記2種類の配信方式に応じたHTTPリクエストを送信することができる。具体的には、クライアント1のクライアント通信部11は、取得したMPDデータのpartialAvailability属性の値が"true"であれば、セグメントに含まれる全てのサブセグメント及び/又は通常・階層インデックス情報に含まれる全てのエントリーの生成(エンコード)が完了する前であっても、生成(エンコード)が完了したサブセグメントに対応するエントリーを取得できるため、図20に示すようなバイトレンジ(バイト位置)を指定したHTTPリクエストを送信することによって、切り替え後のリプリゼンテーションにおける指定したサブセグメント以降のデータを取得することができる。したがって、低遅延での配信を実現することができる。一方、取得したMPDデータのpartialAvailability属性の値が"false"であれば、セグメントに含まれる全てのサブセグメント及び/又は通常・階層インデックス情報に含まれる全てのエントリーの生成(エンコード)が完了するまでは、それらのデータは取得できない。そのため、該データの生成(エンコード)の完了後に、バイトレンジを指定したHTTPリクエストを送信する必要があることを認識することができる。
このように、partialAvailability属性をMPDデータに記述することにより、クライアント1は配信方式に応じた適切なHTTPリクエストを送信することができる。
また、サーバ2においても、バイトレンジを指定したHTTPリクエストに対応する場合には、記述情報生成部25は、partialAvailability属性の値に"true"を設定したMPDデータを生成し、バイトレンジを指定したHTTPリクエストに対応しない場合には、partialAvailability属性の値に"false"を設定したMPDデータを生成することで、設計の自由度を高めることができる。
〔ソフトウェアによる構成例〕
最後に、クライアント1及びサーバ2の各ブロックは、集積回路(ICチップ)上に形成された論理回路によってハードウェア的に実現してもよいし、CPU(Central Processing Unit)を用いてソフトウェア的に実現してもよい。
最後に、クライアント1及びサーバ2の各ブロックは、集積回路(ICチップ)上に形成された論理回路によってハードウェア的に実現してもよいし、CPU(Central Processing Unit)を用いてソフトウェア的に実現してもよい。
後者の場合、クライアント1及びサーバ2は、各機能を実現するプログラムの命令を実行するCPU、上記プログラムを格納したROM(Read Only Memory)、上記プログラムを展開するRAM(Random Access Memory)、上記プログラムおよび各種データを格納するメモリ等の記憶装置(記録媒体)などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアであるクライアント1及びサーバ2の制御プログラムのプログラムコード(実行形式プログラム、中間コードプログラム、ソースプログラム)をコンピュータで読み取り可能に記録した記録媒体を、クライアント1及びサーバ2に供給し、そのコンピュータ(またはCPUやMPU)が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。
上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ類、フロッピー(登録商標)ディスク/ハードディスク等の磁気ディスクやCD−ROM/MO/MD/DVD/CD−R等の光ディスクを含むディスク類、ICカード(メモリカードを含む)/光カード等のカード類、マスクROM/EPROM/EEPROM(登録商標)/フラッシュROM等の半導体メモリ類、あるいはPLD(Programmable logic device)やFPGA(Field Programmable Gate Array)等の論理回路類などを用いることができる。
また、クライアント1及びサーバ2は通信ネットワークと接続可能に構成されているので、上記プログラムコードを通信ネットワークを介して供給してもよい。この通信ネットワークは、プログラムコードを伝送可能であればよく、特に限定されない。例えば、インターネット、イントラネット、エキストラネット、LAN、ISDN、VAN、CATV通信網、仮想専用網(Virtual Private Network)、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、この通信ネットワークを構成する伝送媒体も、プログラムコードを伝送可能な媒体であればよく、特定の構成または種類のものに限定されない。例えば、IEEE1394、USB、電力線搬送、ケーブルTV回線、電話線、ADSL(Asymmetric Digital Subscriber Line)回線等の有線でも、IrDAやリモコンのような赤外線、Bluetooth(登録商標)、IEEE802.11無線、HDR(HighData Rate:登録商標)、NFC(Near Field Communication)、DLNA(Digital Living Network Alliance:登録商標)、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。
〔まとめ〕
〔発明の一態様が解決しようとする課題〕
低遅延でのライブストリーミングを行うシステムにおいて、1つのセグメントデータのライブエンコード完了を待たず、セグメントデータおよびインデックスデータの配信を開始でき、リプリゼンテーションの切り替え(アダプティプストリーミング)を可能にする送信装置等を提供することにある。
〔発明の一態様が解決しようとする課題〕
低遅延でのライブストリーミングを行うシステムにおいて、1つのセグメントデータのライブエンコード完了を待たず、セグメントデータおよびインデックスデータの配信を開始でき、リプリゼンテーションの切り替え(アダプティプストリーミング)を可能にする送信装置等を提供することにある。
〔課題を解決するための手段〕
本発明の一態様の送信装置は、同一の再生期間に対応する複数のコンテンツをエンコードし、エンコードしたコンテンツのうち再生対象として選択されたコンテンツを再生装置に送信する送信装置であって、上記複数のコンテンツについて予め定めた再生位置までエンコードが進んだときに、上記再生期間のうち上記再生位置までの部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成する参照情報生成手段と、上記参照情報生成手段が生成した参照情報を上記再生装置に取得させる参照情報提供手段とを備えていることを特徴としている。
本発明の一態様の送信装置は、同一の再生期間に対応する複数のコンテンツをエンコードし、エンコードしたコンテンツのうち再生対象として選択されたコンテンツを再生装置に送信する送信装置であって、上記複数のコンテンツについて予め定めた再生位置までエンコードが進んだときに、上記再生期間のうち上記再生位置までの部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成する参照情報生成手段と、上記参照情報生成手段が生成した参照情報を上記再生装置に取得させる参照情報提供手段とを備えていることを特徴としている。
また、本発明の一態様の送信装置の制御方法は、上記の課題を解決するために、同一の再生期間に対応する複数のコンテンツをエンコードし、エンコードしたコンテンツのうち再生対象として選択されたコンテンツを再生装置に送信する送信装置の制御方法であって、上記複数のコンテンツについて予め定めた再生位置までエンコードが進んだときに、上記再生期間のうち上記再生位置までの部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成する参照情報生成ステップと、上記参照情報生成ステップで生成した参照情報を上記再生装置に取得させる参照情報提供ステップとを含むことを特徴としている。
上記の構成によれば、複数のコンテンツについて部分再生期間のエンコードが進んだときに、部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成し、これを再生装置に取得させる。
したがって、再生装置は、コンテンツのエンコードが完了するまでの期間に、部分再生期間で再生対象のコンテンツを切り替えることが可能になる。つまり、上記の構成によれば、コンテンツのエンコードが完了するまでの期間に、再生装置に1つの再生期間の途中で再生対象のコンテンツを切り替えさせることができる。
また、再生装置が再生しているコンテンツはエンコードが完了している部分であり、このような部分については参照情報による切り替えが可能となる。よって、上記の構成によれば、再生装置が再生している再生位置におけるコンテンツの切り替えが保証される。
また、上記参照情報生成手段は、コンテンツのエンコードが予め定めた再生位置まで進んだときに、該コンテンツの該再生位置までの部分再生期間のデータサイズを示す参照情報を生成し、その後、後続する予め定めた再生位置までエンコードが進む毎に、該コンテンツの該再生位置とその直前の予め定めた再生位置の間の部分再生期間のデータサイズを示す情報を上記参照情報に追加することが好ましい。
上記の構成によれば、コンテンツのエンコードが予め定めた再生位置まで進んだときに、コンテンツの部分再生期間のデータサイズを示す参照情報を生成し、その後、後続する予め定めた再生位置までエンコードが進む毎に、部分再生期間のデータサイズを示す情報を上記参照情報に追加する。
上記の構成では、エンコードの進行に応じて部分再生期間のデータサイズを示す情報を追加するので、生成された参照情報はエンコード済みの各部分再生期間のデータサイズが示された情報となる。
したがって、上記の構成によって生成された参照情報を用いることによって、部分再生期間で再生対象のコンテンツを切り替えることが可能になる。例えば、1〜3番目までの部分再生期間のデータサイズがそれぞれSz1〜Sz3である場合、2番目の部分再生期間で切り替えるときには、再生装置はSz1以降を指定してコンテンツの要求を行えばよい。
また、上記参照情報は、予め定められた数のエントリーと、該エントリーのうち有効なエントリーを示す有効情報を記述する記述領域とを含む情報であり、上記参照情報生成手段は、コンテンツのエンコードが予め定めた再生位置まで進んだときに、該再生位置までの部分再生期間に対応するエントリーに、該部分再生期間で再生対象のコンテンツを切り替えるための情報を追加すると共に、該エントリーが有効であることを示す有効情報を上記記述領域に記述するものであってもよい。
上記の構成によれば、コンテンツのエンコードが予め定めた再生位置まで進んだときに、該再生位置までの部分再生期間に対応するエントリーに、該部分再生期間で再生対象のコンテンツを切り替えるための情報を追加すると共に、該エントリーが有効であることを示す有効情報を記述領域に記述する。
このような参照情報を取得した再生装置は、その参照情報に含まれているエントリーのうち、何れが有効であるかを有効情報から特定し、有効なエントリーに含まれる情報を用いて、そのエントリーに対応する部分再生期間でコンテンツを切り替えることができる。つまり、上記の構成によれば、有効なエントリーと有効ではないエントリーとを含む参照情報を用いて、再生装置に1つの再生期間の途中で再生対象のコンテンツを切り替えさせることができる。
また、上記送信装置は、上記部分再生期間のコンテンツを、上記再生期間の全体のエンコードが完了する前に送信可能か否かを示す情報を含む記述情報を生成する記述情報生成手段と、上記記述情報生成手段が生成した記述情報を上記再生装置に取得させる記述情報提供手段とをさらに備えていることが好ましい。
上記の構成によれば、部分再生期間のコンテンツを、再生期間の全体のエンコードが完了する前に送信可能か否かを示す情報を含む記述情報を生成し、生成した記述情報を再生装置に取得させる。
したがって、部分再生期間で再生対象のコンテンツを切り替えることのできる配信方式であるか、再生期間全体のエンコードが完了した時点でコンテンツを配信可能にする配信方式であるかをクライアントに適切に認識させることができる。
なお、上記送信装置及び上記再生装置は、コンピュータによって実現してもよく、この場合には、コンピュータを上記送信装置及び上記再生装置の各手段として動作させることにより、上記送信装置及び上記再生装置をコンピュータにて実現させる制御プログラム、及びそれを記録したコンピュータ読み取り可能な記録媒体も本発明の範疇に入る。
〔発明の効果〕
以上のように、本発明の一態様の送信装置は、複数のコンテンツについて予め定めた再生位置までエンコードが進んだときに、再生期間のうち上記再生位置までの部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成する参照情報生成手段と、上記参照情報生成手段が生成した参照情報を再生装置に取得させる参照情報提供手段とを備えている構成である。
以上のように、本発明の一態様の送信装置は、複数のコンテンツについて予め定めた再生位置までエンコードが進んだときに、再生期間のうち上記再生位置までの部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成する参照情報生成手段と、上記参照情報生成手段が生成した参照情報を再生装置に取得させる参照情報提供手段とを備えている構成である。
また、本発明の一態様の送信装置の制御方法は、複数のコンテンツについて予め定めた再生位置までエンコードが進んだときに、再生期間のうち上記再生位置までの部分再生期間で再生対象のコンテンツを切り替えるための参照情報を生成する参照情報生成ステップと、上記参照情報生成ステップで生成した参照情報を再生装置に取得させる参照情報提供ステップとを含む構成である。
上記の構成によれば、再生装置は、コンテンツのエンコードが完了するまでの期間に、部分再生期間で再生対象のコンテンツを切り替えることが可能になる。つまり、上記の構成によれば、コンテンツのエンコードが完了するまでの期間に、再生装置に1つの再生期間の途中で再生対象のコンテンツを切り替えさせることができるという効果を奏する。
本発明は、ネットワークを介したコンテンツの送受信システムに利用することができる。
1 クライアント(再生装置)
2 サーバ(送信装置)
11 クライアント通信部(要求手段、受信手段)
12 記述情報解析部(受信手段)
13 コンテンツ再生部(再生手段)
14 インデックス情報解析部
21 サーバ通信部(送信手段)
22 サーバ記憶部
23 エンコーダ(符号化手段)
24 インデックス情報生成部
25 記述情報生成部(生成手段)
26 サーバ制御部
27 セグメントデータ
28 インデックス情報(参照情報)
29 記述情報
2 サーバ(送信装置)
11 クライアント通信部(要求手段、受信手段)
12 記述情報解析部(受信手段)
13 コンテンツ再生部(再生手段)
14 インデックス情報解析部
21 サーバ通信部(送信手段)
22 サーバ記憶部
23 エンコーダ(符号化手段)
24 インデックス情報生成部
25 記述情報生成部(生成手段)
26 サーバ制御部
27 セグメントデータ
28 インデックス情報(参照情報)
29 記述情報
Claims (4)
- 複数の再生期間で構成されるコンテンツを符号化し送信する送信装置であって、
前記複数の再生期間のうちの1つに対応するセグメントデータを符号化する符号化手段と、
前記セグメントデータの全体の符号化が完了する前に前記セグメントデータの一部を送信可能か否かを示すフラグを生成する生成手段と、
前記セグメントデータの全体の符号化が完了する前に前記セグメントデータの一部と前記フラグを送信する送信手段と、
前記コンテンツに対応し、複数の前記セグメントデータの記述を含むメディアプレゼンテーションデスクリプション(MPD)を生成する生成手段と、
前記MPDを送信する送信手段と、
を備えることを特徴とする送信装置。 - 複数の再生期間で構成されるコンテンツを符号化し送信する送信方法であって、
前記複数の再生期間のうちの1つに対応するセグメントデータを符号化するステップと、
前記セグメントデータの全体の符号化が完了する前に前記セグメントデータの一部を送信可能か否かを示すフラグを生成するステップと、
前記セグメントデータの全体の符号化が完了する前に前記セグメントデータの一部と前記フラグを送信するステップと、
前記コンテンツに対応し、複数の前記セグメントデータの記述を含むメディアプレゼンテーションデスクリプション(MPD)を生成するステップと、
前記MPDを送信するステップと、
を含むことを特徴とする送信方法。 - 複数の再生期間で構成されるコンテンツを再生する再生装置であって、
前記複数の再生期間のうちの1つに対応するセグメントデータの記述を複数含み、前記コンテンツに対応するメディアプレゼンテーションデスクリプション(MPD)を受信する受信手段と、
前記セグメントデータの全体の符号化が完了する前に前記セグメントデータの一部を送信可能か否かを示すフラグを前記MPDから解析する解析手段と、
前記フラグが前記セグメントデータの一部を送信可能であることを示す場合、前記セグメントデータの一部を要求する要求手段と、
前記セグメントデータの一部を受信する受信手段と、
前記セグメントデータの一部を再生する再生手段と、
を備えることを特徴とする再生装置。 - 複数の再生期間で構成されるコンテンツを再生する再生方法であって、
前記複数の再生期間のうちの1つに対応するセグメントデータの記述を複数含み、前記コンテンツに対応するメディアプレゼンテーションデスクリプション(MPD)を受信するステップと、
前記セグメントデータの全体の符号化が完了する前に前記セグメントデータの一部を送信可能か否かを示すフラグを前記MPDから解析するステップと、
前記フラグが前記セグメントデータの一部を送信可能であることを示す場合、前記セグメントデータの一部を要求するステップと、
前記セグメントデータの一部を受信するステップと、
前記セグメントデータの一部を再生するステップと、
を含むことを特徴とする再生方法。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2011154350 | 2011-07-12 | ||
JP2011154350 | 2011-07-12 |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012099296A Division JP2013038766A (ja) | 2011-07-12 | 2012-04-24 | 送信装置、送信装置の制御方法、制御プログラム、及び記録媒体 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2017130957A JP2017130957A (ja) | 2017-07-27 |
JP6294527B2 true JP6294527B2 (ja) | 2018-03-14 |
Family
ID=59395033
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2017045119A Expired - Fee Related JP6294527B2 (ja) | 2011-07-12 | 2017-03-09 | 送信装置、送信方法、再生装置、及び再生方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP6294527B2 (ja) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109787983A (zh) * | 2019-01-24 | 2019-05-21 | 北京百度网讯科技有限公司 | 直播流切片方法、装置和系统 |
-
2017
- 2017-03-09 JP JP2017045119A patent/JP6294527B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2017130957A (ja) | 2017-07-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2013008867A1 (ja) | 送信装置、送信装置の制御方法、制御プログラム、及び記録媒体 | |
JP6404505B2 (ja) | メディアコンテンツをクライアントデバイスにストリーミングするための方法および装置 | |
US10123059B2 (en) | Fast start of streaming digital media playback with deferred license retrieval | |
KR101868280B1 (ko) | 정보 처리 장치, 정보 처리 방법 및 컴퓨터 판독 가능한 기록 매체 | |
JP6449494B2 (ja) | 再生装置 | |
CN105814900B (zh) | 用于在自适应流播环境中管理相邻频道的系统和方法 | |
US8850054B2 (en) | Hypertext transfer protocol live streaming | |
CN103190092A (zh) | 用于流数字内容的同步重放的系统和方法 | |
JP2007295038A (ja) | 動画再生装置及び方法 | |
JP4315914B2 (ja) | 画像再生装置及び画像再生方法 | |
JP4526294B2 (ja) | ストリームデータ送信装置、受信装置、プログラムを記録した記録媒体、およびシステム | |
JP6294527B2 (ja) | 送信装置、送信方法、再生装置、及び再生方法 | |
JP6535273B2 (ja) | 受信装置、セグメント取得方法、及びプログラム | |
JP5144771B2 (ja) | 画像処理装置、画像再生装置、画像記録装置、画像処理方法、画像再生方法、及び画像記録方法 | |
JP2014131307A (ja) | 情報処理装置、情報処理方法およびプログラム | |
JP2016040919A (ja) | 情報処理装置、情報処理方法およびプログラム | |
CN112887755A (zh) | 用于播放视频的方法和装置 | |
KR20140048917A (ko) | 적응형 스트리밍 방법 | |
JP2009060353A (ja) | コンテンツ配信装置、及び移動端末装置、並びにコンテンツ配信システム、コンテンツ配信方法、コンテンツ受信方法、及びコンテンツ配信プログラム | |
KR20100115988A (ko) | 콘텐츠 재생 제어 장치 및 방법 | |
WO2015072020A1 (ja) | 情報処理装置および情報処理方法 | |
KR20130095243A (ko) | 실시간 컨텐츠 스트리밍 방법 | |
KR20090123519A (ko) | 다운로드-앤-플레이 서비스에서 전 구간에 대한 컨텐츠트릭 플레이 기능 및 찾기 기능을 제공하는 방법 및 그컨텐츠 수신 장치 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20171219 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20180116 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20180215 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 6294527 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
LAPS | Cancellation because of no payment of annual fees |