(57)【要約】【課題】ライブ再生でネットワーク輻輳が発生した場合に適切な復帰を行う。【解決手段】ネットワークを介してセグメント単位で送信されるコンテンツをライブ再生する再生装置における再生状況を、再生装置において再生を開始してからの経過時間を取得することにより把握し、再生装置にセグメントを送信する際に、再生装置での再生状況に基づいて、再生装置においてライブ再生されないと判断したセグメントの送信を回避してセグメントの送信を行う。本技術は、例えば、MPEG-DASHを利用してコンテンツデータを配信する配信装置に適用できる。【選択図】図３３
2016015533.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介してセグメント単位で送信されるコンテンツをライブ再生する再生装置における再生状況を把握する再生状況把握部と、
前記再生装置に前記セグメントを送信する際に、前記再生装置での再生状況に基づいて、前記再生装置においてライブ再生されないと判断した前記セグメントの送信を回避して前記セグメントの送信を行う送信部と
を備える情報処理装置。
【請求項２】
前記再生状況把握部は、前記再生装置において再生を開始してからの経過時間を取得することにより、前記再生装置での再生状況を把握する
請求項１に記載の情報処理装置。
【請求項３】
前記再生状況把握部は、前記再生装置において保持されている前記セグメントだけでライブ再生を継続することができる再生継続可能時間を取得することにより、前記再生装置での再生状況を把握する
請求項１に記載の情報処理装置。
【請求項４】
ネットワークを介してセグメント単位で送信されるコンテンツをライブ再生する再生装置における再生状況を把握し、
前記再生装置に前記セグメントを送信する際に、前記再生装置での再生状況に基づいて、前記再生装置においてライブ再生されないと判断した前記セグメントの送信を回避して前記セグメントの送信を行う
ステップを含む情報処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、情報処理装置および方法に関し、特に、ライブ再生でネットワーク輻輳が発生した場合に適切な復帰を行うことができるようにした情報処理装置および方法に関する。
【背景技術】
【０００２】
近年、HTTP（Hyper Text Transfer Protocol）を利用したコンテンツ配信技術としてMPEG-DASH（Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP）が標準化された（例えば、非特許文献１参照）。MPEG-DASHでは、同一コンテンツが異なるビットレートで表現された複数の符号化データをコンテンツサーバに格納し、クライアントが、ネットワーク帯域に応じて複数の符号化データのいずれかの符号化データを選択しながら再生するABS（Adaptive Bitrate Streaming）技術が採用されている。
【０００３】
ところで、全体画像の代わりにその一部である部分画像を適応的に選択して配信することが考えられた。例えば、全体画像の内、画像データを受け取る端末側によって選択された部分の部分画像を配信したり、端末の性能（例えばCPU等の処理能力やディスプレイの大きさ等）や伝送経路やサーバの負荷状況等に応じて、配信する部分画像の大きさを制御したりすることが考えられた。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】MPEG-DASH(Dynamic Adaptive Streaming over HTTP)（URL:http://mpeg.chiariglione.org/standards/mpeg-dash/media-presentation-description-and-segment-formats/text-isoiec-23009-12012-dam-1）
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来のMPEG-DASH規格では、ライブ再生でネットワーク輻輳が発生した場合に、ネットワーク輻輳により送信されなかったセグメントの送信が行われており、帯域を不要に使用することになっていた。
【０００６】
本開示は、このような状況に鑑みてなされたものであり、ライブ再生でネットワーク輻輳が発生した場合に適切な復帰を行うことができるようにするものである。
【課題を解決するための手段】
【０００７】
本開示の一側面の情報処理装置は、ネットワークを介してセグメント単位で送信されるコンテンツをライブ再生する再生装置における再生状況を把握する再生状況把握部と、前記再生装置に前記セグメントを送信する際に、前記再生装置での再生状況に基づいて、前記再生装置においてライブ再生されないと判断した前記セグメントの送信を回避して前記セグメントの送信を行う送信部とを備える。
【０００８】
本開示の一側面の情報処理方法は、ネットワークを介してセグメント単位で送信されるコンテンツをライブ再生する再生装置における再生状況を把握し、前記再生装置に前記セグメントを送信する際に、前記再生装置での再生状況に基づいて、前記再生装置においてライブ再生されないと判断した前記セグメントの送信を回避して前記セグメントの送信を行うステップを含む。
【０００９】
本開示の一側面においては、ネットワークを介してセグメント単位で送信されるコンテンツをライブ再生する再生装置における再生状況が把握され、前記再生装置に前記セグメントを送信する際に、前記再生装置での再生状況に基づいて、前記再生装置においてライブ再生されないと判断した前記セグメントの送信を回避して前記セグメントの送信が行われる。
【発明の効果】
【００１０】
本開示の一側面によれば、ライブ再生でネットワーク輻輳が発生した場合に適切な復帰を行うことができる。
【図面の簡単な説明】
【００１１】
【図１】MPEG-DASHの概要を説明する図である。
【図２】MPDの構成例を示す図である。
【図３】コンテンツの時間的区切りを説明する図である。
【図４】MPDにおけるPeriod以下の階層構造の例を示す図である。
【図５】MPDファイルの構成例を時間軸上で説明する図である。
【図６】配信システムの主な構成例を示すブロック図である。
【図７】従来のHTTPとウェブソケット（WebSocket）とのそれぞれにおけるサーバ−クライアント間のセグメントデータの転送方法を説明する図である。
【図８】従来のHTTPとウェブソケット（WebSocket）とのそれぞれにおけるサーバ−クライアント間のセグメントデータの帯域適応ロジックを適用した場合の転送方法を説明する図である。
【図９】DASHに適用されるウェブソケットのサブフレームのプロトコルについて説明する図である。
【図１０】dashのコントロールデータのシンタックスを説明する図である。
【図１１】コントロールデータを送信するサブフレームに用いられるオペレーションコードの一覧を示す図である。
【図１２】オペレーションコードopenMediaのシンタックスを説明する図である。
【図１３】オペレーションコードmediainfoのシンタックスを説明する図である。
【図１４】オペレーションコードcloseMediaのシンタックスを説明する図である。
【図１５】オペレーションコードplayStreamのシンタックスを説明する図である。
【図１６】オペレーションコードStreamInfoのシンタックスを説明する図である。
【図１７】オペレーションコードstopStreamのシンタックスを説明する図である。
【図１８】オペレーションコードchangeMediaのシンタックスを説明する図である。
【図１９】オペレーションコードplayerInfoのシンタックスを説明する図である。
【図２０】オペレーションコードcapabilityのシンタックスを説明する図である。
【図２１】オペレーションコードpreferenceのシンタックスを説明する図である。
【図２２】VOD再生を開始させるシーケンスを説明するタイミングチャートである。
【図２３】VOD再生を中断し、再開させるシーケンスを説明するタイミングチャートである。
【図２４】VOD再生を最後まで再生し、終了するシーケンスを説明するタイミングチャートである。
【図２５】ライブの最初から視聴する場合におけるライブ再生を開始させるシーケンスを説明するタイミングチャートである。
【図２６】ライブの途中から視聴する場合におけるライブ再生を開始するシーケンスを説明するタイミングチャートである。
【図２７】サーバの機能を実現する機能ブロック図である。
【図２８】クライアントの機能を実現する機能ブロック図である。
【図２９】Multiple Representations Transfer at startupのシーケンスを説明するタイミングチャートである。
【図３０】Multiple Representations Transfer at startupのシーケンスを説明する図である。
【図３１】Low delay Transfer by Sub-Segmentのシーケンスを説明するタイミングチャートである。
【図３２】Low delay Transfer by Sub-Segmentのシーケンスを説明する図である。
【図３３】ライブ再生でネットワーク輻輳が発生した場合に行われるシーケンスを説明するタイミングチャートである。
【図３４】複数のメディアを切り替えて再生させるシーケンスを説明するタイミングチャートである。
【図３５】複数のメディアを切り替えて再生させるシーケンスを説明するタイミングチャートである。
【図３６】本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。
【発明を実施するための形態】
【００１２】
以下、本開示を実施するための形態（以下実施の形態とする）について説明する。なお、説明は以下の順序で行う。
１．概要
２．第１の実施の形態（MPEG-DASH over WebSocket）
３．第２の実施の形態（Multiple Representations Transfer at startup）
４．第３の実施の形態（Low delay Transfer by Sub-Segment）
５．第４の実施の形態（Auto Segment Skip for Live Streaming）
６．第５の実施の形態（Fast Switching of multiple media）
７．第６の実施の形態（コンピュータ）
【００１３】
＜１．概要＞
＜DASH＞
従来、HTTP（HyperText Transfer Protocol）を利用したコンテンツ配信技術として、例えば、非特許文献１に記載のように、MPEG-DASH（Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP）がある。MPEG-DASHでは、同一コンテンツが異なるビットレートで表現された複数の符号化データをコンテンツサーバに格納し、クライアントが、ネットワーク帯域に応じて複数の符号化データのいずれかの符号化データを選択しながら再生するABS（Adaptive Bitrate Streaming）技術が採用されている。
【００１４】
DASHによるコンテンツの伝送の手順を、図１を参照して説明する。まず、コンテンツを取得する側の動画再生端末において、ストリーミング・データの制御用ソフトウエアが、所望のコンテンツのMPD（Media Presentation Description）ファイルを選択し、Webサーバから取得する。MPDは、配信する動画や音声等のコンテンツを管理するメタデータである。
【００１５】
MPDを取得すると、動画再生端末のストリーミング・データの制御用ソフトウエアは、そのMPDを解析し、所望のコンテンツの、通信回線の品質や動画再生端末の性能等に合ったデータ（DASHセグメント）をWebサーバから取得するように制御する。HTTPアクセス用のクライアント・ソフトウエアは、その制御に従って、そのDASHセグメントを、HTTPを用いてWebサーバから取得する。このように取得されたコンテンツを、動画再生ソフトウエアが再生する。
【００１６】
MPDは、例えば図２に示されるような構成を有する。MPDの解析（パース）においては、クライアントは、MPD（図２のMedia Presentation）のピリオド（Period）に含まれるリプレゼンテーション（Representation）の属性から最適なものを選択する。
【００１７】
クライアントは、選択したリプレゼンテーション（Representation）の先頭のセグメント（Segment）を読んでイニシャライズセグメント（Initialization Segment）を取得し、処理する。続いて、クライアントは、後続のセグメント（Segment）を取得し、再生する。
【００１８】
なお、MPDにおける、ピリオド（Period）、リプレゼンテーション（Representation）、およびセグメント（Segment）の関係は、図３のようになる。つまり、１つのメディアコンテンツは、時間方向のデータ単位であるピリオド（Period）毎に管理することができ、各ピリオド（Period）は、時間方向のデータ単位であるセグメント（Segment）毎に管理することができる。また、各ピリオド（Period）について、ビットレート等の属性の異なる複数のリプレゼンテーション（Representation）を構成することができる。
【００１９】
したがって、このMPDのファイル（MPDファイルとも称する）は、ピリオド（Period）以下において、図４に示されるような階層構造を有する。また、このMPDの構造を時間軸上に並べると図５の例のようになる。図５の例から明らかなように、同一のセグメント（Segment）に対して複数のリプレゼンテーション（Representation）が存在している。クライアントは、これらのうちのいずれかを適応的に選択することにより、通信環境や自己のデコード能力などに応じて適切なストリームデータを取得し、再生することができる。
【００２０】
＜配信システム＞
次に、以上のような本技術を実現する装置とその方法について説明する。図６は、本技術を適用したシステムの一態様である、配信システムを示す図である。図６に示される配信システム１００は、全体画像の一部である部分画像のデータを適応的に配信することができるシステムである。
【００２１】
図６に示されるように配信システム１００は、配信データ生成装置１０１、配信サーバ１０２、および端末装置１０３を有する。
【００２２】
配信データ生成装置１０１は、配信サーバ１０２が配信する、例えば画像や音声等のコンテンツのファイル（コンテンツファイル）とそのMPDファイルを生成し、それを配信サーバ１０２に供給する。配信サーバ１０２は、配信データ生成装置１０１から供給されたコンテンツファイルとそのMPDファイルを、ネットワーク１０４に向けて公開し、部分画像の適応的な配信を行う。
【００２３】
端末装置１０３は、ネットワーク１０４を介して配信サーバ１０２にアクセスし、配信サーバ１０２が公開する所望のコンテンツのMPDファイルを取得する。
【００２４】
端末装置１０３は、そのMPDファイルに従って、ネットワーク１０４を介して配信サーバ１０２にアクセスし、MPDファイルに対応する適切なコンテンツファイルを適応的に選択し、それをHTTPプロトコルにより取得する。端末装置１０３は、取得したコンテンツファイルを再生する。
＜２．第１の実施の形態＞
＜MPEG-DASH over WebSocket＞
次に、図７を参照して、従来のHTTPとウェブソケット（WebSocket）とのそれぞれにおけるサーバ−クライアント間のセグメントデータ（図中のSeg.Data）の転送方法について説明する。尚、図７におけるサーバ２０１は、上述した図６の配信サーバ１０２に対応するものであり、クライアント２０２は、上述した図６の端末装置１０３に対応するものである。
【００２５】
サーバ２０１およびクライアント２０２間における、HTTPによるセグメントデータの転送は、図７Ａで示されるような処理となる。尚、ここでは、デコードの開始時に３個のセグメントデータ（Seg.Data）単位でバッファリングがされるものとする。
【００２６】
すなわち、クライアント２０２において、まず、再生が指示されると（PlayStart）、Getコマンドからなる要求（図７Ａの３段目のクライアント２０２の先頭のReq.）がサーバ２０１に対して送信される。
【００２７】
次に、サーバ２０１が、このGetコマンドに応じて、応答（図７Ａの３段目のクライアント２０２の先頭のResp.）としてMPDをクライアント２０２に送信する。
【００２８】
クライアント２０２は、このMPDの情報に基づいて、順次、セグメントデータ（Seg.Data）をサーバ２０１に対して要求（図７Ａの３段目のクライアント２０２の２番目以降のReq.）する。
【００２９】
サーバ２０１は、この要求に応じて、セグメントデータ（Seg.Data）をクライアント２０２に対して送信（図７Ａの３段目のサーバ２０１の２番目以降のResp.）する。
【００３０】
ここで、クライアント２０２が、サーバ２０１に対してセグメントデータ（Seg.Data）を要求して、サーバ２０１がセグメントデータ（Seg.Data）をクライアント２０２に送信する際、図７Ａの２段目で示されるように、PlayStartのタイミングからクライアント２０２により再生が開始される（DecStart）タイミングまでに遅延時間（Delay to Rendering）が発生する。
【００３１】
尚、図７Ａにおいては、最上段において、サーバ２０１−クライアント２０２間が接続されていることが示されており、中段においては、再生が要求されたタイミング（Play Start）から再生が実際に開始されるタイミング（DecStart）までの遅延時間（Delay to Rendering）が示されている。さらに、図７Ａの最下段においては、パイプ状に描かれた通信回線上をセグメントデータ（Seg.Data）が転送される様子が図中右方向に時系列に描かれている。また、図７Ａにおいては、パイプ状の通信回線の上側がクライアント（Client）２０２側の動作タイミングを示しており、下側がサーバ（Server）２０１側の動作タイミングを示している。さらに、以降において、図７Ｂおよび図８においても同様の記載である。
【００３２】
すなわち、従来のHTTPにおいて、サーバ２０１−クライアント２０２間は、いわゆるPull回線となるため、トランザクション間にGAPが生じ、複数ファイルの読み出しに時間がかかる。特に、毎回、TCPコネクションした場合、オープンの遅延やフロー制御のスロースタートの為、さらに時間がかかる。
【００３３】
結果として、再生開始時に、十分なデータをバッファリングするため再生画像が表示されるまでの時間が遅く、転送スループットが上がらないので、低いビットレートのビデオが選択されることになるので、常に低画質の画像が転送される恐れがある。
【００３４】
これに対して、サーバ２０１およびクライアント２０２間における、ウェブソケットによるセグメントデータの転送は、図７Ｂで示されるような処理となる。
【００３５】
すなわち、クライアント２０２において、まず、再生が指示されると（PlayStart）、Getコマンドからなる要求（図７Ｂの３段目のクライアント２０２の先頭のCommand Send）がサーバ２０１に対して送信される。
【００３６】
次に、サーバ２０１は、このGetコマンドに応じて、応答（図７Ｂの３段目のクライアント２０２の先頭のData（MPD））としてMPDと共に、セグメントデータ（Seg.Data）をクライアント２０２に対して順次送信（図７Ｂの３段目のサーバ２０１の２番目以降のSeg.Data）する。
【００３７】
ここでも、クライアント２０２が、サーバ２０１に対してセグメントデータ（Seg.Data）を要求して、サーバ２０１がセグメントデータ（Seg.Data）をクライアント２０２に送信する際、図７Ｂの２段目で示されるように、PlayStartのタイミングからクライアント２０２により再生が開始される（DecStart）タイミングまでに遅延時間（Delay to Rendering）が発生するものの、HTTPの場合よりも短い。
【００３８】
すなわち、ウェブソケットにおいては、サーバ２０１−クライアント２０２間は、いわゆるPush回線となるため、トランザクション間にGAPが生じず、複数ファイルの読み出しにかかる時間を短縮することができる。特に、同一のTCPセッションでの転送となるため、コネクションに関わる問題も発生しない。
【００３９】
結果として、再生開始時の画像が表示されるまでの時間を短縮することが可能となり、転送スループットを上げることができるので、高めのビットレートのビデオを選択でき、再生の開始から比較的高画質の画像を転送することが期待できる。
【００４０】
ただし、HTTPにおいても、帯域適応ロジックであるPipeliningがサポートされている場合を考えると、上述した図７Ａにおける処理よりも遅延時間を短縮することが可能である。Pipeliningとは、クライアント２０２が、帯域の状態を判断し、帯域に応じて、サーバ２０１に対して、一度に複数の要求をすることができ、これに応じて、クライアント２０２は、サーバ２０１からまとめて要求に応じたデータを受信できる機能である。
【００４１】
すなわち、図８Ａで示されるように、サーバ２０１からのMPDによる応答があった後のタイミングで、クライアント２０２は、サーバ２０１に対して、３個のセグメントデータを同時に要求することにより、サーバ２０１から、まとめて３個のセグメントデータを受信するというものである。
【００４２】
このようにすることで、図７Ａで示されるような要求を出してから応答を受信するまでのGapを省くことができ、遅延時間（Delay to Rendering）を短縮することが可能となる。
【００４３】
しかしながら、リクエストへのレスポンスが返ってくる前に、次のセグメントデータのリクエストをすることになるので、進行中のトランザクションの帯域をモニタし、その結果から状況により異なるリプレゼンテーション（Representation）を選択して、次のセグメントデータの要求に反映させることができない。このため、進行中のトランザクション結果は、３個後のセグメントのリクエストにしか反映させることができない。
【００４４】
すなわち、例えば、図８Ａで示されるように、クライアント２０２側で帯域の判断をするため、最初の要求を送った後のタイミングで、実際には、十分な帯域があるにも関わらず、次の要求を送信するまでの間、３個の低画質のセグメントデータをサーバ２０１から受信しなければならない。尚、図８Ａの最下段におけるSeg.Data(rep1)およびSeg.Data(rep3)は、それぞれリプレゼンテーションが異なるセグメントデータを示しており、rep3は、rep1よりも高画質のリプレゼンテーションのセグメントデータであることを示している。すなわち、図８Ａの最下段においては、最初の要求に対して、低画質の３個のセグメントデータ（Seg.Data(rep1)）が送信された後に、高画質のセグメントデータ（Seg.Data(rep3)）が送信されることが示されている。
【００４５】
これに対して、ウェブソケットにおいては、サーバ２０１が帯域の状態を判断してセグメントデータのリプレゼンテーションを切り替えることができる。このため、図８Ｂで示されるように、サーバ２０１が帯域に応じた判断をするため、１個目のセグメントデータを送った直後のタイミングにでも、帯域の状態に応じて、異なるリプレゼンテーションのセグメントデータを送信することができる。すなわち、図８Ｂの最下段においては、先頭で低画質のセグメントデータ（Seg.Data(rep1)）が送信された直後に、高画質のセグメントデータ（Seg.Data(rep3)）が送信されることが示されている。
【００４６】
結果として、帯域の状態に応じて、迅速で、かつ適切なリプレゼンテーションのセグメントデータを切り替えて送信することが可能になると共に、クライアント２０２側の実装内容を簡易なものとすることが可能となる。
【００４７】
＜ウェブソケットのサブフレームのプロトコル＞
また、ウェブソケットでは、フレーム（Frame）と呼ばれる単位で、データの送受信が行われる。
【００４８】
そこで、次に、図９を参照して、DASHに適用されるウェブソケットのサブフレームのプロトコルについて説明する。
【００４９】
図９の左側には、ウェブソケットのベースフレーミングプロトコルと、サブフレームのヘッダ部分に記述されるオペレーションコード（operation code , opcode）との例が示されている。
【００５０】
サブフレームのヘッダ部分には、オペレーションコードの他、例えば、このサブフレームがデータの終わりなのかどうかを示すFINや、データがマスク化されているかどうかを示すMASK、アプリケーションデータの長さを示すPayload lenなどが記述される。
【００５１】
また、オペレーションコードが０である場合、接続を継続するのに用いられるサブフレーム（Continuation Frame）であることを示しており、オペレーションコードが１である場合、テキストデータ用のサブフレーム（Text Frame）であることを示している。また、オペレーションコードが２である場合、バイナリデータ用のサブフレーム（Binary Frame）であることを示しており、オペレーションコードが８である場合、接続終了を行うサブフレーム（Connection Close Frame）であることを示している。また、オペレーションコードが９である場合、接続維持できているかを確認するのに用いられるサブフレーム（Ping Frame）であることを示している。また、オペレーションコードが１０である場合、Ping Frameに対する応答に用いられるサブフレーム（Pong Frame）であることを示している。
【００５２】
そして、ウェブソケットをDASHに適用する場合、図９の右側に示すように、サブフレームのペイロード部分に、テキストフレームとして送信されるコントロールデータと、バイナリフレームとして送信されるセグメントデータとの２つのデータが規定される。
【００５３】
例えば、コントロールデータは、軽量なデータ記述言語の１つであるジェイソン（JSON：JavaScript Object Notation）により記述されるJSON Dataより構成される。また、セグメントデータ（Segment Data）は、ISO/IEC 14496-12（MPEG-4）の規格に従って記述されたデータより構成される。
【００５４】
このように、DASHにウェブソケットを適用する際、コントロールデータとセグメントデータとを共通のサブフレームのペイロード部分に混在させず、それぞれが個別のサブフレームのペイロード部分に配置される。
【００５５】
これにより、コントロールデータが遅延されて伝送されることを回避することができる。即ち、セグメントデータはデータ量が大きいため、伝送が遅れてしまうことがあり、コントロールデータをセグメントデータと混在させた場合には、混在させたデータの全てを読み取った後でなければコントロールデータを認識することできない。このため、コントロールデータが認識されるまでに遅延時間が発生することが想定される。これに対し、コントロールデータとセグメントデータとを個別のサブフレームのペイロード部分に配置すると、セグメントデータを送信する前に、比較的小さなコントロールデータを送信するようにすることができるので、コントロールデータが認識されるまでに発生する遅延時間を短縮して伝送することができる。
【００５６】
また、HTML5のウェブソケットAPIにて、受信したセグメントデータを、JavaScript(登録商標)でパースせずにそのままMSEのソースバッファに追加（Append）することができる。
【００５７】
次に、図１０乃至図２１を参照して、コントロールデータについて説明する。
【００５８】
図１０には、ジェイソンにより記述されたコントロールデータのシンタックス（syntax）が示されている。
【００５９】
図１０の例では、プロトコルのＩＤがdashであり、プロトコルのバージョンが0.2であることが示されている。また、タイムスタンプ（図１０の例では、1403627982268）は、アプリケーション層以下で発生する伝送遅延を補正することができる。
【００６０】
また、例えば、１つのサブフレームに、複数のコントロールデータをまとめて送信することができる。これにより、受信した側は、一括処理を容易に行うことができる。即ち、図１０の例では、コントロールデータとして、capability，openMedia，playStreamのオペレーションコードがまとめて記述されている。
【００６１】
図１１には、コントロールデータを送信するサブフレームに用いられるオペレーションコードの一覧が示されている。
【００６２】
openMediaは、MPDのURLを指定して、サーバにメディアのセグメントをストリームできる状態にするためのオペレーションコードであり、クライアントからサーバに送信される。例えば、openMediaは、図１２に示すように記述され、１行目の“opcode”:“openMedia”は、MPDのURLを指定して、サーバにメディアのセグメントをストリームできる状態にするためのオペレーションコードであることを表している。URL（図１２の例では、“http://cdn.example/movies/134532.mpd“）によりMPDを指定する。そして、openMediaを受信したサーバは、指定されたMPDをオープンして、mediaInfoをクライアントに送り返す。
【００６３】
mediaInfoは、openMediaを受信した直後、もしくは、メディアの情報が更新された場合に送信されるオペレーションコードであり、サーバからクライアントに送信される。
【００６４】
例えば、mediaInfoは、図１３に示すように記述され、１行目の“opcode”:“mediaInfo”は、openMediaを受信した直後、もしくは、メディアの情報が更新された場合に送信されるオペレーションコードであることを表している。また、２行目以降においては、対象となるメディアがmediaDescriptor（図１３の例では、152736）により指定される。また、networkStateによりHTML5 Videoにおいて定義されるようにネットワークの動作状態（アクティビティ）（図１３の例では、4）が指定される。また、readyStateにより、対象となるメディアの準備状態（図１３の例では、4）が指定される。さらに、URL（図１３の例では、“http://cdn.example/movies/134532.mpd“）によりMPDが指定される。
【００６５】
closeMediaは、openMediaでサーバが確保したリソースを解放するためのオペレーションコードであり、クライアントからサーバに送信される。例えば、closeMediaは、図１４に示すように記述され、“opcode”:“closeMedia”により、openMediaでサーバが確保したリソースを解放するためのオペレーションコードであることを表している。クローズにするメディアがmediaDescriptor（図１４の例では、152736）により指定される。
【００６６】
playStreamは、ストリームを開始し、オープンされているメディアを指定するためのオペレーションコードであり、クライアントからサーバに送信される。
【００６７】
例えば、playStreamは、図１５に示すように記述される。
【００６８】
より詳細には、１行目の“opcode”:“playStream”は、ストリームを開始し、オープンされているメディアを指定するためのオペレーションコードであることを表している。
【００６９】
２行目以降においては、streamDescriptorで指定された（図１５の例では、4323）ストリームにおける、mediaDescriptorで指定したメディア（図１５の例では、152736）のsegmentNumberで指定されたセグメント番号のセグメント（図１５の例では、155）からnumSegmentにより指定されたセグメント数（図１５では1000）分のストリームを開始する。また、VODの場合はメディアの最初のセグメントからストリームを開始し、Liveの場合は現在の最新のセグメントからストリームを開始する。
【００７０】
streamInfoは、ストリームの状態、次に伝送されるセグメントデータの属性を通知するためのオペレーションコードであり、サーバからクライアントに送信される。
【００７１】
例えば、streamInfoは、図１６に示すように記述される。また、streamInfoは、定期的に伝送され、このコントロールデータの後に伝送されるセグメントデータの属性情報を示す。
【００７２】
より詳細には、１行目の“opcode”:“StreamInfo”は、ストリームの状態、次に伝送されるセグメントデータの属性を通知するためのオペレーションコードであることを表している。
【００７３】
また、２行目以降においては、対象となるストリームがstreamDescriptor（図１６の例では4323）により指定される。また、対象となるメディアがmediaDescriptor（図１３の例では、1527364235312）により指定される。さらに、networkStateによりHTML5 Videoにおいて定義されるようにネットワークの動作状態（アクティビティ）（図１６の例では4に）が指定される。また、readyStateにより、対象となるメディアの準備状態（図１６の例では、4）が記述される。
【００７４】
multipleRepresentationにより、同一のセグメントデータに対して複数のリプレゼンテーションが送信されてくる可能性があるか否かが指定される。図１６の例では“true”とされて、同一のセグメントデータに対して複数のリプレゼンテーションが送信されてくる可能性があることが指定されている。クライアントはその場合、次のStreamInfoの受信を待ってから、現在のSegmentデータを利用するか破棄するかを決める。尚、“false”とされるとき、同一のセグメントデータに対して複数のリプレゼンテーションが送信されてくることがないことが指定される。
【００７５】
segmentSkippedにより、Live配信などの際、実時間に対して再生が遅れてしまったセグメントの配信をスキップさせる、セグメントスキップがなされる可能性があるか否かが指定され、図１６の例では、“false”とされて、セグメントスキップがなされる可能性がないことが指定されている。尚、“true”とされる場合、セグメントスキップがなされる可能性があることが指定される。
【００７６】
minBufferTimeにより、バッファリングの最小時間が指定されており、図１６においては、“4.00”により４秒であることが指定されている。
【００７７】
minNetworkBufferTimeにより、クライアントがどのくらいのデータをバッファリングしてからデコードを開始すればよいという奨励値が指定されており、図１６においては、“5.00”により５秒分であることが指定されている。
【００７８】
すなわち、サーバは、MinNetworkBufferDurationにより、クライアントがどのくらいのデータをバッファリングしてからデコードを開始すればよいという奨励値として指定し、ネットワークの状態などから判断して、帯域変動でクライアントのバッファが枯渇し、再生が停止しないよう、ストリーム開始時にstreamInfoをシグナリング（送信）する。
【００７９】
segmentにより、セグメントデータが指定され、このうち、presentationTimeによりセグメントデータの時刻が指定され、図１６においては“331533”がミリ秒単位で指定される。また、“periodID”により、再生開始位置が指定され、図１６においては、“1”と指定され、先頭ピリオドからの再生が指定されている。
【００８０】
さらに、“adaptationSetID”によりセグメントデータの種別が指定されて、図１６においては“video”が指定されている。また、representationIDによりリプレゼンテーションの種別が指定され、図１６の例では“rep4”が指定されている。segmentNumber”によりセグメントデータの番号が指定され、図１６において、“1324”が指定されている。尚、もし、これらのセグメントを指定する情報が無い場合、対象となるセグメントは、初期化された先頭のセグメントとされる。
【００８１】
“SAPType”により、セグメントやサブセグメントなどの離プレゼンテーションが変化する先頭位置SAP（Stream Access Point）の種別が指定される。SAP TypeはつまりSegmentのSubSegmentの先頭のピクチャーがClosed GOPやOpen GOPの先頭のピクチャーであるなどのSAPの種類が記述Type1から６まで定義されており、図１６の例では、1が指定されている。
【００８２】
subsegmentNumberにより、１のセグメントデータを構成するサブセグメントを識別する番号が指定され、図１６においては、“0”が指定されている。尚、サブセグメントを識別する番号については、サブセグメントが３個で１のセグメントデータを構成するような場合、図１６の例で示されるように、１番目のサブセグメントであれば、“0”であり、２番目のサブセグメントであれば“1”となり、３番目のサブセグメントであれば“2”とするようにしてもよい。
【００８３】
すなわち、Segment Dataを分割してSubSegmentとして伝送可能にするため、サーバは、SAPTypeおよびSubSegmentNumberをシグナリング（送信）する。
【００８４】
このように、サブセグメントを定義することにより、StopStream、およびChangeMediaにおいて、サーバは、SubSegmentの途中でストリームを停止することができる。これにより、不要なSegment Dataを伝送しないで、StopStreamにより、即座にストリームを停止することができ、ChangeMediaを低遅延で実現することができる。さらに、ChangeMediaでは切り替えたMediaをSubSegmentからストリームすることで、更に高速に切り替えることが可能となる。
【００８５】
stopStreamは、ストリームを停止するためのオペレーションコードであり、クライアントからサーバに送信される。
【００８６】
例えば、stopStreamは、図１７に示すように記述され、対象となるストリームとしてstreamDescriptor（図１６の例では4323）により指定されたストリームの停止が指示される。
【００８７】
より詳細には、１行目の“opcode”:“stopStream”は、ストリームの停止を指示するオペレーションコードであることを表しており、２乃至４行目の“params” : { “streamDescriptor”: “4323” }は、停止するストリームを指定するパラメータを表している。
【００８８】
changeMediaは、ストリームをされるメディアを変えるものであり、オープンされているMediaを指定し、ストリームを止めることなく切り替える。changeMediaは、クライアントからサーバに送信される。
【００８９】
例えば、changeMediaは、図１８に示すように記述される。
【００９０】
１行目の“opcode” : “changeMedia”は、変更後に再生するストリームするメディアを指定するオペレーションコードであることを表している。２乃至７行目の“params”: {“streamDescriptor” : “4323”, “mediaDescriptor” : “152736”,“segmentNumber” : “155”, “numSegment” : “1000”}は、それぞれ、複数のストリームを指定するパラメータ、切り替えるメディアを指定するパラメータ、セグメント番号を指定するパラメータ、およびメディアのエンドが存在しない場合におけるセグメントの数を指定するパラメータを表している。
【００９１】
このように、予め複数のメディアをサーバにオープンの状態にしておき、直ちにセグメントをストリームできる状態にしておくことで、図３４および図３５を参照して後述するように、メディアを切り替えた直後に、別のセグメントを伝送することができる。また、上述したOpenMediaおよびCloseMediaによって、サーバが保持するメディアに関するリソースが管理される。
【００９２】
playerInfoは、ストリームを再生中のプレイヤーの再生状況を通知するためのオペレーションコードであり、クライアントからサーバに送信される。
【００９３】
例えば、playerInfoは、図１９に示すように記述され、プレイヤーの再生状況に変化があれば通知される。
【００９４】
１行目の“opcode” : “playerInfo”は、プレイヤーの再生状況を通知するオペレーションコードであることを表している。２乃至８行目の“params”: { “streamDescriptor”: “4323”,“networkState” : “4”, “readyState” : “4” “currentPresentationTime” : “478777”, “bufferedTime” : “4000”}は、それぞれ、ストリームを識別するパラメータ、ネットワーク状況を表すパラメータ、読み込み状況を表すパラメータ、現在の再生時間をミリ秒で表すパラメータ、バッファされている時間をミリ秒で表すパラメータを表している。
【００９５】
このように、サーバは、playerInfoに含まれるcurrentPresentationTimeを利用して、ライブでクライアントがリアルタイムに再生できていないことを感知することができる。これにより、図３３を参照して後述するように、サーバは、再生されない不要なセグメントはスキップして、ライブの最新のセグメントを継続して転送することができる。
【００９６】
capabilityは、例えば、コーデックなど、クライアンのケーパビリティを通知するためのオペレーションコードであり、クライアントからサーバに送信される。
【００９７】
例えば、capabilityは、図２０に示すように記述される。
【００９８】
すなわち、１行目の“opcode” : “capability”は、例えば、コーデックなど、クライアントのケーパビリティを通知するためのオペレーションコードであることを表している。２行目以降においては、multipleRepresentationにより、クライアントが、同一のセグメントデータについて、複数のRepresentationを受け入れることが可能であるか否かが指定される。例えば、図２０においては、“true”とされて、同一のセグメントデータについて、複数のRepresentationを受け入れることが可能であることが指定されている。尚、“false”とされる場合、同一のセグメントデータについて、複数のRepresentationを受け入れることができないことが指定される。
【００９９】
segmentSkipにより、セグメントスキップに対応可能であるか否かが指定され、例えば、図２０においては“false”とされて、セグメントスキップに対応可能ではないことが指定されている。尚、“true”とされた場合、セグメントスキップに対応可能であることが指定されている。
【０１００】
decodeにより、対応可能なデコードの種別が指定され、mimeTypeによりmimeタイプが指定され、図２０においては、“video/mp4”とされ、mp4のビデオのデコードが可能であることが指定されている。また、codecによりコーデックの種別として[“avc1.640828”]が可能であると指定されている。このときmaxWidth、maxHieght、およびmaxBandwidthにより、処理可能な画像の最大幅、最大高、および最大バンド幅が指定され、図２０においては、それぞれ“1920”,“1080”,“101024”とされて、1920画素×1080画素のバンド幅が101024となる画像を処理可能であることが指定されている。
【０１０１】
また、segmentAlignment!により、リプレゼンテーションのセグメントがそろっているか否かが指定され、図２０においては、falseとされており、各リプレゼンテーションのセグメントがそろっていることが指定されている。尚、trueの場合、各リプレゼンテーションのセグメントがそろっていないことが指定される。
【０１０２】
さらに、SAPTypeにより、セグメントの先頭位置SAP（Stream Access Point）の種別が指定され、図２０の場合、SAPの種別が１または２のいずれかであることが指定されている。
【０１０３】
また、図２０においては、さらなる対応可能なmimeタイプとして“audiomp4”が指定されて、音声のmp4がデコード可能であることが指定されている。さらに、コーデックの種別として[“mp4a.40”]が指定され、segmentAlignment!により、リプレゼンテーションのセグメントがそろっているか否かが指定され、図２０においては、falseとされており、各リプレゼンテーションのセグメントがそろっていることが指定されている。
【０１０４】
preferenceは、例えば、AdaptationSetIDなど、クライアントのプリファレンス（優先的にして欲しい設定）を通知するためのオペレーションコードであり、クライアントからサーバに送信される。
【０１０５】
例えば、preferenceは、図２１に示すように記述される。
【０１０６】
すなわち、１行目の“opcode” : “preference”は、クライアントのプリファレンス（優先的にして欲しい設定）を通知するためのオペレーションコードであることを表している。２行目以降においては、mediaDescriptorにより、対象となるメディアがmediaDescriptor（図２１の例では、152736）により指定される。segmentSkipにより、対象となるメディアに対してセグメントスキップをしない状態か否かが指定され、図２１においては、“false”によりセグメントスキップをしない状態を設定するように求められていることが指定されている。
【０１０７】
languageにより、使用する言語が指定され、図２１の場合、[“en”,“fr”]により英語とフランス語の使用を優先的に設定するように求められていることが指定されている。
【０１０８】
segmentにより、セグメントデータに対する設定についてのプリファレンスが指定され、このうち１番目のperiodIDにより画像の再生開始位置が指定され、図２１の場合、“1”とされ、画像の再生開始位置として先頭ピリオドを優先的に設定するように求められていることが指定されている。
【０１０９】
１番目のadaptationSetIDにより、セグメントデータの画像種別が指定され、図２１の場合、“mainVideo”により主画像が優先的に設定されるように求められていることが示されている。
【０１１０】
１番目のreprsentationIDにより、画像のリプレゼンテーションの種別が指定され、図２１においては、[“1”, “2”, “3”]とされ、reprsentationの種別として、１乃至３のいずれかとするように優先的に設定するように求められていることが示されている。尚、この場合、リプレゼンテーションの種別としては３種類が指定されることになるが、サーバは、この３種類のリプレゼンテーションのうち、帯域の状態を判断して、最適なリプレゼンテーションを設定する。
【０１１１】
さらに、２番目のperiodIDにより、音声の再生開始位置が指定され、図２１の場合、“1”とされ、音声の再生開始位置として先頭ピリオドを優先的に設定するように求められていることが指定されている。
【０１１２】
２番目のadaptationSetIDによりセグメントデータの音声種別が指定され、図２１の場合、“mainAudio”により主音声が優先的に設定するように求められていることが示されている。
【０１１３】
さらに、２番目のreprsentationIDにより、音声のリプレゼンテーションの種別が指定され、図２１においては、[“1”]とされ、音声のリプレゼンテーションの種別として、１とするように優先的に設定するように求められていることが示されている。
【０１１４】
すなわち、preferenceにより、MediaのどのMediaSegmentをストリームするかクライアントのプリファレンスが指定される。（なにも指定しない場合はサーバがクライアントのCapabilityに合わせて自動で選択する）
【０１１５】
尚、representationIDがArrayの場合で複数指定されている場合、サーバは、Network Adaptation（ネットワークの状態に応じた処理）を実行し、その範囲にて、帯域適応等のサーバの判断にて適切なリプレゼンテーションを選択しストリームする。
【０１１６】
このようなコントロールデータが、サーバ２０１およびクライアント２０２の間で送受信され、コンテンツファイルの配信が制御される。
【０１１７】
図２２には、VOD再生を開始させるシーケンスが示されている。
【０１１８】
例えば、ユーザが、VOD再生を開始するようにクライアント２０２に対する操作を行うと処理が開始される。ステップＳ１１において、クライアント２０２は、コントロールデータ（capability，openMedia，playStream）をサーバ２０１送信し、クライアント２０２のケーパビリティを通知するとともに、メディアを指定してストリームを開始するように要求する。
【０１１９】
サーバ２０１は、この要求に従って、クライアント２０２により指定されたメディアのメディア情報を読み出し、ステップＳ１２において、コントロールデータ（mediaInfo）をクライアント２０２に送信することでメディア情報を返信する。
【０１２０】
そして、サーバ２０１は、ステップＳ１３において、コントロールデータ（streamInfo）をクライアント２０２に送信して、次に伝送されるセグメントデータの属性を通知する。続いて、サーバ２０１は、ステップＳ１４において、セグメントデータ（RepID 1，SegmentNo 0）をクライアント２０２に送信する。
【０１２１】
クライアント２０２は、このセグメントデータを受信してデコードを開始し、ステップＳ１５において、コントロールデータ（playerInfo）をサーバ２０１に送信することで、ストリームのデコードを開始してからの経過時間を通知する。
【０１２２】
その後、サーバ２０１は、セグメントデータを順次、クライアント２０２に送信する。このとき、サーバ２０１は、ネットワークの状態に応じた処理（Network Adaption）により、リプレゼンテーション（Rep）を変えるPlayerInfoでCurrentPresentanTimeからクライアントのバッファ量を推測することで、適切な帯域適応をすることができる。
【０１２３】
これにより、例えば、サーバ２０１は、ステップＳ１６において、コントロールデータ（streamInfo）を送信し、ステップＳ１７において、セグメントデータ（RepID 3，SegmentNo 1）を送信する。続いて、サーバ２０１は、ステップＳ１８において、コントロールデータ（streamInfo）をクライアント２０２に送信し、ステップＳ１９において、セグメントデータ（RepID 3，SegmentNo 2）を送信する。
【０１２４】
また、サーバ２０１は、Transmission Controlにより、クライアント２０２の再生進行に合わせてセグメントデータを送り続けることができる。即ち、サーバ２０１は、クライアント２０２の再生進行に合わせたタイミングで、ステップＳ２０において、コントロールデータ（streamInfo）をクライアント２０２に送信し、ステップＳ２１において、セグメントデータ（RepID 3，SegmentNo 3）を送信する。
【０１２５】
一方、クライアント２０２は、再生状況の変化があると、ステップＳ２２において、コントロールデータ（playerInfo）をサーバ２０１に送信し、ストリームのデコードを開始してからの経過時間を通知する。
【０１２６】
このように、VOD再生を開始する処理が行われ、以下同様に、サーバ２０１からクライアント２０２にセグメントデータが送信される。
【０１２７】
図２３には、VOD再生を中断し、再開させるシーケンスが示されている。
【０１２８】
上述したようにセグメントデータの送信が続けられ、サーバ２０１は、ステップＳ３１において、コントロールデータ（streamInfo）を送信し、ステップＳ３２において、セグメントデータ（RepID 2，SegmentNo 153）を送信する。そして、クライアント２０２は、ステップＳ３３において、コントロールデータ（playerInfo）をサーバ２０１に送信する。
【０１２９】
そして、ユーザが再生を中断（例えば、ポーズやシークなど）するようにクライアント２０２に対する操作を行うと、ステップＳ３４において、クライアント２０２は、コントロールデータ（stopStream）をサーバ２０１に送信する。これにより、クライアント２０２は、ストリームを停止することをサーバ２０１に通知する。
【０１３０】
これに応じ、サーバ２０１は、ステップＳ３５およびＳ３６において、コントロールデータ（streamInfo）およびセグメントデータ（RepID 3，SegmentNo 154）をそれぞれ送信した後、ステップＳ３７において、中断したことを通知するコントロールデータ（streamInfo）をクライアント２０２に送信する。
【０１３１】
その後、ユーザが再生を再開するようにクライアント２０２に対する操作を行うと、ステップＳ３８において、クライアント２０２は、コントロールデータ（Start Stream）を送信して、再開するセグメント番号（図２３の例では155）を指定する。
【０１３２】
これに応じ、サーバ２０１は、ステップＳ３９において、セグメントデータ（RepID 3，SegmentNo 155）をクライアント２０２に送信し、クライアント２０２は、ステップＳ４０において、コントロールデータ（playerInfo）をサーバ２０１に送信する。
【０１３３】
このように、VOD再生を中断し、再開させる処理が行われ、以下同様に、サーバ２０１からクライアント２０２にセグメントデータが送信される。
【０１３４】
図２４には、VOD再生を最後まで再生し、終了するシーケンスが示されている。
【０１３５】
上述したようにセグメントデータの送信が続けられ、サーバ２０１は、ステップＳ５１において、コントロールデータ（streamInfo）を送信し、ステップＳ５２において、セグメントデータ（RepID 2，SegmentNo 873）を送信する。そして、クライアント２０２は、ステップＳ５３において、コントロールデータ（playerInfo）をサーバ２０１に送信する。
【０１３６】
そして、サーバ２０１は、ステップＳ５４において、コントロールデータ（streamInfo）を送信し、ステップＳ５５において、セグメントデータ（RepID 2，SegmentNo 874）を送信する。ここで、送信されたセグメントがストリームの最後である場合、サーバ２０１は、ステップＳ５６において、コントロールデータ（streamInfo）を送信し、ストリームが終了したことをクライアント２０２に通知する。
【０１３７】
これに応じ、クライアント２０２は、ステップＳ５７において、コントロールデータ（playerInfo）をサーバ２０１に送信した後、ステップＳ５８において、コントロールデータ（closeMedia，stopStream）をサーバ２０１に送信する。これにより、クライアント２０２は、受信したセグメントの再生をすべて終了し、メディアをクローズすることをサーバ２０１に通知する。
【０１３８】
サーバ２０１は、コントロールデータ（closeMedia，stopStream）を受信すると、メディアの情報を破棄する。そして、ステップＳ５９において、サーバ２０１は、コントロールデータ（MediaStatus）をクライアント２０２に送信し、VOD再生が終了される。
【０１３９】
このように、VOD再生を終了する処理が行われる。
【０１４０】
図２５には、ライブの最初から視聴する場合におけるライブ再生を開始させるシーケンスが示されている。
【０１４１】
例えば、ユーザが、ライブ再生を開始するようにクライアント２０２に対する操作を行うと処理が開始される。ステップＳ７１において、クライアント２０２は、コントロールデータ（capability，openMedia，playStream）をサーバ２０１送信し、クライアント２０２のケーパビリティを通知するとともに、メディアを指定してストリームの開始するように要求する。
【０１４２】
サーバ２０１は、この要求に従って、クライアント２０２により指定されたメディアのメディア情報を読み出し、ステップＳ７２において、コントロールデータ（mediaInfo）をクライアント２０２に送信することでメディア情報を返信する。
【０１４３】
ここで、例えば、ライブ放送が開始されていない場合にはMediaStatusが定期的に通知され、サーバ２０１は、ステップＳ７３において、コントロールデータ（mediaInfo）をクライアント２０２に送信して、MediaStatusを通知する。
【０１４４】
その後、ライブ放送が開始されるとセグメントの送信が開始され、ステップＳ７４において、サーバ２０１は、コントロールデータ（mediaInfo，streamInfo）をクライアント２０２に送信する。続いて、サーバ２０１は、ステップＳ７５において、セグメントデータ（Segment Data of SegmentNo 0）をクライアント２０２に送信する。
【０１４５】
クライアント２０２は、このセグメントデータを受信してデコードを開始し、ステップＳ７６において、コントロールデータ（playerInfo）をサーバ２０１に送信することで、例えば、ストリームのデコードを開始してからの経過時間を通知する。
【０１４６】
このように、ライブの最初から視聴する場合におけるライブ再生を開始する処理が行われ、以下同様に、サーバ２０１からクライアント２０２にセグメントデータが送信される。
【０１４７】
図２６には、ライブの途中から視聴する場合におけるライブ再生を開始するシーケンスが示されている。
【０１４８】
例えば、ユーザが、ライブ再生を開始するようにクライアント２０２に対する操作を行うと処理が開始される。ステップＳ９１において、クライアント２０２は、コントロールデータ（capability，openMedia，playStream）をサーバ２０１送信し、クライアント２０２のケーパビリティを通知するとともに、メディアを指定してストリームの開始するように要求する。
【０１４９】
サーバ２０１は、この要求に従って、クライアント２０２により指定されたメディアのメディア情報を読み出し、ステップＳ９２において、コントロールデータ（mediaInfo）をクライアント２０２に送信することでメディア情報を返信する。
【０１５０】
ここで、例えば、ライブ放送が既に始まっている場合は、最新のセグメントから伝送が行われ、ステップＳ９３において、サーバ２０１は、コントロールデータ（streamInfo）をクライアント２０２に送信する。続いて、サーバ２０１は、ステップＳ９４において、セグメントデータ（Segment Data of SegmentNo 1447）をクライアント２０２に送信する。
【０１５１】
クライアント２０２は、このセグメントデータを受信してデコードを開始し、ステップＳ９５において、コントロールデータ（playerInfo）をサーバ２０１に送信することで、例えば、ストリームのデコードを開始してからの経過時間を通知する。
【０１５２】
その後、サーバ２０１は、セグメントデータを送り続けることができ、ステップＳ９６およびＳ９７において、コントロールデータ（streamInfo）およびセグメントデータ（Segment Data of SegmentNo 1448）をそれぞれ送信する。続いて、サーバ２０１は、ステップＳ９８およびＳ９９において、コントロールデータ（streamInfo）およびセグメントデータ（Segment Data of SegmentNo 1449）をそれぞれ送信する。
【０１５３】
このように、ライブの途中から視聴する場合におけるライブ再生を開始する処理が行われ、以下同様に、サーバ２０１からクライアント２０２にセグメントデータが送信される。
【０１５４】
＜３．第２の実施の形態＞
＜Multiple Representations Transfer at startup＞
＜配信システムを実現するサーバの構成＞
図２７に示すように、サーバ２０１は、受信部２１１、送信部２１２、記憶部３１２、および通信処理部２１４を備えて構成される。
【０１５５】
受信部２１１は、ネットワークを介してサーバ２０１に送信されるデータを受信して通信処理部２１４に供給する。
【０１５６】
送信部２１２は、通信処理部２１４において実行される通信処理に従い、例えば、各種のコントロールデータをクライアント２０２に送信したり、記憶部３１２からコンテンツファイルのセグメントを適宜読み出してクライアント２０２に送信する。
【０１５７】
記憶部３１２には、サーバ２０１から配信される画像や音声等のコンテンツファイルが記憶されている。
【０１５８】
通信処理部２１４は、例えば、クライアント２０２の通信処理部２２７との間で、上述したようなコントロールデータを利用した通信処理を行う。
【０１５９】
＜配信システムを実現するクライアントの構成＞
図２８に示すように、クライアント２０２は、受信部２２１、送信部２２２、バッファ２２３、再生処理部２２４、ディスプレイ２２５、スピーカ２２６、および通信処理部２２７を備えて構成される。
【０１６０】
受信部２２１は、例えば、サーバ２０１から送信されてくるコントロールデータを受信して通信処理部２２７に供給したり、サーバ２０１から送信されてくるコンテンツファイルのセグメントを受信してバッファ２２３に供給する。バッファ２２３は、受信部２２１から供給されるコンテンツファイルのセグメントを一時的に保持する。
【０１６１】
再生処理部２２４は、バッファ２２３に保持されているセグメントを読み出してデコードする再生処理を行い、映像データをディスプレイ２２５に供給するとともに、音声データをスピーカ２２６に供給する。これにより、ディスプレイ２２５は映像を表示し、スピーカ２２６は音声を出力する。
【０１６２】
通信処理部２２７は、例えば、サーバ２０１の通信処理部２１４との間で、上述したようなコントロールデータを利用した通信処理を行う。
【０１６３】
次に、図２９のフローチャートを参照して、図２７のサーバ２０１、および図２８のクライアント２０２とからなる配信システムによる、コンテンツの再生開始時において複数のリプレンゼンテーションを送信する処理（Multiple Representations Transfer at startup）について説明する。すなわち、この処理においては、再生開始時に、同一のSegment Noで、異なるリプレンゼンテーションのセグメントデータが送信されるようにする。これにより、帯域の状態に対応した画質のリプレンゼンテーションのセグメントデータから再生させることができ、必ず最初に低画質の画像から再生が開始されるのを防ぐことが可能となる。
【０１６４】
すなわち、例えば、ユーザが、VOD再生を開始するようにクライアント２０２に対する操作を行うと処理が開始される。
【０１６５】
ステップＳ１１１において、クライアント２０２の通信処理部２２７は、送信部２２２を制御して、コントロールデータ（capability，openMedia，playStream）をサーバ２０１に送信する。これにより、クライアント２０２のケーパビリティがサーバ２０１に通知されるとともに、メディアが指定されてストリームの開始が要求される。
【０１６６】
サーバ２０１の通信処理部２１４は、受信部２１１を制御して、この要求を受信し、クライアント２０２により指定されたメディアのメディア情報を記憶部２１３より読み出す。そして、ステップＳ１１２において、通信処理部２１４は、送信部２１２を制御して、コントロールデータ（mediaInfo）をクライアント２０２に送信することでメディア情報を返信する。
【０１６７】
そして、サーバ２０１の通信処理部２１４は、ステップＳ１１３において、送信部２１２を制御して、コントロールデータ（streamInfo（RepID 1，SegmentNo 0，RepRep:true））をクライアント２０２に送信して、次に伝送されるセグメントデータの属性を通知する。続いて、通信処理部２１４は、ステップＳ１１４において、送信部２１２を制御してセグメントデータ（RepID 1，SegmentNo 0）をクライアント２０２に送信する。
【０１６８】
すなわち、DASHにウェブソケットを適用する際、コントロールデータとセグメントデータとは、図９を参照して説明したように、それぞれが個別のサブフレームのペイロード部分に配置されている。
【０１６９】
そこで、サーバ２０１の通信処理部２１４は、ステップＳ１１３において、送信部２１２を制御して、セグメントデータを送信する前に、コントロールデータを用いて、StreamInfoにより、次のタイミングで送信するセグメントデータ（Media Data Frame）により送信する予定であるリプレゼンテーションを識別する情報（RepID 1）と共に、同一のSegment Noで、異なるリプレゼンテーションのセグメントデータを送信する可能性があることを示す情報（RepRep:true）を送信する。
【０１７０】
すなわち、例えば、図３０の上段最左部におけるコントロールフレーム（Control Frame StreamInfo）においては、次に送信するセグメントデータが、セグメントナンバが０（SegmentNo. 0）であって、セグメントのリプレゼンテーションがVideo1（RepID：Video1）であることを示す情報であることが示されている。さらに、同一のSegment Noで、異なるリプレゼンテーションのセグメントデータを送る可能性があることを示す情報（Multiple Representationl:True）が送信される。尚、Multiple Representationl:Trueは、図２９のRepRep:trueに対応する。
【０１７１】
そして、引き続き、ステップＳ１１４において、図３０の上段の左から２番目で示されるように、セグメントデータが送信される。
【０１７２】
クライアント２０２の通信処理部２２７は、受信部２２１を制御して、このセグメントデータを受信してデコードを開始する。そして、ステップＳ１１５において、通信処理部２２７は、送信部２２２を制御して、コントロールデータ（playerInfo（CurrentPresentanTime））をサーバ２０１に送信することで、ストリームのデコードを開始してからの経過時間を通知する。
【０１７３】
その後、サーバ２０１の通信処理部２１４は、送信部２１２を制御して、セグメントデータを順次、クライアント２０２に送信する。このとき、サーバ２０１の通信処理部２１４は、ネットワークの状態に応じた処理（Network Adaption）により、リプレゼンテーション（Rep）を変えるPlayerInfoにより、CurrentPresentanTimeからクライアント２０２のバッファ２２３のバッファ量を推測することで、適切な帯域に適応することができる。
【０１７４】
すなわち、これにより、例えば、十分な帯域があると判断される場合、サーバ２０１の通信制御部２１４は、同一のセグメントナンバであって、異なるビットレートの高いリプレゼンテーションのセグメントデータを送信すると判断し、ステップＳ１１６において、図３０の下段最左列で示されるように、コントロールデータ（streamInfo（RepID 3，SegmentNo 0，RepRep:false））からなるコントロールデータフレーム（Control Frame streamInfo）を送信する。
【０１７５】
このとき、クライアント２０２は、直前に送信されてきている、ビットレートの低いリプレンゼンテーションのセグメントデータ（RepID 1，SegmentNo 0）を破棄する。
【０１７６】
そして、ステップＳ１１７において、サーバ２０１の通信制御部２１４は、送信部２１２を制御して、図３０の下段左から２番目で示されるように、事前のコントロールデータにより予告したセグメントデータ（RepID 3，SegmentNo 0）からなるセグメントデータフレーム（Media Data Frame0）を送信する。
【０１７７】
すなわち、図３０の下段最左部で示されるように、次に送信するセグメントデータが、直前に送ったセグメントデータと同一のセグメントナンバが０（SegmentNo. 0）であって、よりビットレートの高いリプレゼンテーションのVideo3（RepID：Video3）を示すコントロールデータからなるコントロールフレームが送信される。続いて、サーバ２０１の通信制御部２１４は、送信部２１２を制御して、ステップＳ１１７において、図３０の下段左から２番目で示されるように、セグメントデータからなるセグメントデータフレーム（RepID 3，SegmentNo 0）からなるセグメントデータフレーム（Media Data Frame0）を送信する。
【０１７８】
続いて、サーバ２０１の通信制御部２１４は、送信部２１２を制御して、ステップＳ１１８において、図３０の下段左から３番目で示されるように、コントロールデータ（streamInfo）からなるコントロールフレーム（Control Frame streamInfo）をクライアント２０２に送信する。そして、ステップＳ１１９において、サーバ２０１の通信制御部２１４は、送信部２１２を制御して、図３０の下段左から４番目で示されるように、セグメントデータ（RepID 3，SegmentNo 1）からなるセグメントデータフレーム（Media Data Frame1）を送信する。
【０１７９】
クライアント２０２の通信制御部２２７は、受信部２２１を制御して、このセグメントデータを受信してデコードを開始し、ステップＳ１２０において、送信部２２２を制御して、コントロールデータ（playerInfo（CurrentPresentanTime））をサーバ２０１に送信する。これにより、クライアント２０２において、ストリームのデコードが開始されてからの経過時間がサーバ２０１に通知される。
【０１８０】
また、サーバ２０１の通信制御部２１４は、Transmission Controlにより、クライアント２０２の再生進行に合わせてセグメントデータを送り続けることができる。即ち、サーバ２０１の通信制御部２１４は、クライアント２０２の再生進行に合わせたタイミングで、ステップＳ１２１において、送信部２１２を制御して、図３０の下段左から５番目で示されるように、コントロールデータ（streamInfo）からなるコントロールフレーム（Control Frame streamInfo）をクライアント２０２に送信する。
【０１８１】
ステップＳ１２２において、サーバ２０１の通信制御部２１４は、送信部２１２を制御して、図３０の下段最右列で示されるように、セグメントデータ（RepID 3，SegmentNo 2）からなるセグメントデータフレーム（Media Data Frame2）を送信する。
【０１８２】
一方、クライアント２０２の通信制御部２２７は、再生処理部２２４により再生状況の変化があると、ステップＳ１２３において、送信部２２２を制御して、コントロールデータ（playerInfo）をサーバ２０１に送信し、ストリームのデコードを開始してからの経過時間を通知する。
【０１８３】
このように、サーバ２０１は、再生開始時に、帯域の状態に応じて、必要に応じてリプレゼンテーションを切り替えて、セグメントデータをクライアント２０２に送信する。セグメントデータのリプレゼンテーションを切り替える際には、直前に送ったセグメントナンバと同一のセグメントデータであって、帯域の状態に応じたリプレゼンテーションに切り替えられたものが送信される。
【０１８４】
尚、ステップＳ１１５の処理により、例えば、今の帯域に対して現在のリプレゼンテーションが適切であると判断される場合、サーバ２０１の通信処理部２１４は、直前に送信したセグメントデータのセグメントナンバを順序通り１インクリメントし、同一のリプレゼンテーションのセグメントデータを送信する。すなわち、サーバ２０１は、次のステップにおいて、図３０の上段の左から３列目で示されるように、コントロールデータ（streamInfo（RepID 1，SegmentNo 1，RepRep:false））からなるコントロールフレーム（Control Frame streamInfo）をクライアント２０２に送信する。
【０１８５】
そして、さらに次のステップにおいて、サーバは、図３０の上段左から４番目で示されるように、事前のコントロールデータにより予告したセグメントデータ（RepID 1，SegmentNo 1）からなるセグメントデータフレーム（Media Data Frame1）を送信し、以降において、順次セグメントナンバが１ずつインクリメントされて、コントロールデータからなるコントロールデータフレームと、セグメントデータからなるセグメントデータフレームとが、順次、交互に送信されていく。
【０１８６】
以上の如く、再生開始時に同一のセグメントデータに対して、帯域の状態に応じて、複数の種別のリプレゼンテーションを送信するようにしたので、帯域の状態に対して適切なビットレートのセグメントデータを送信することが可能となる。これにより、必ず低画質の画像から再生が開始されるのを防止することが可能となり、帯域の状態に応じた適切な画質の画像から再生させることが可能となる。結果として、再生処理における操作性を向上させることが可能となる。
【０１８７】
＜４．第３の実施の形態＞
＜Low delay Transfer by Sub-Segment＞
【０１８８】
次に、図３１のフローチャートを参照して、セグメント（Segment）データをより小さな単位のサブセグメント（Sub-Segment）データで管理するシーケンスについて説明する。
【０１８９】
サブセグメントデータは、セグメントデータよりも小さな単位としたものである。これにより、セグメントデータ単位での処理よりも、より高速での動作を実現させて、伝送遅延等を防止するものである。
【０１９０】
例えば、ユーザが、VOD再生を開始するようにクライアント２０２に対する操作を行うと処理が開始される。
【０１９１】
ステップＳ１４１において、クライアント２０２の通信制御部２２７は、送信部２２２を制御して、コントロールデータ（capability（subSegment＝true），openMedia，playStream）をサーバ２０１に送信させる。これにより、クライアント２０２のケーパビリティが通知されるとともに、メディアが指定されてストリームが開始されるように要求される。このとき、ケーパビリティにおいて、サブセグメント単位での伝送に対応することができるときには、クライアント２０２の通信制御部２２７は、送信部２２２を制御して、サブセグメント単位での伝送が可能であることを示す情報（subSegment＝true）をサーバ２０１に送信する。これにより、サーバ２０１の通信制御部２１４は、クライアント２０２がサブセグメント単位での伝送に対応することを認識することができる。
【０１９２】
サーバ２０１の通信制御部２１４は、この要求に従って、記憶部２１３よりクライアント２０２により指定されたメディアのメディア情報を読み出し、ステップＳ１４２において、送信部２１２を制御して、コントロールデータ（mediaInfo）をクライアント２０２に送信することでメディア情報を返信する。
【０１９３】
そして、サーバ２０１の通信制御部２１４は、ステップＳ１４３において、送信部２１２を制御して、図３２の最左部で示されるようにコントロールデータ（streamInfo（RepID 1，SegmentNo 1，SubsegmentNo, SAPType 1））からなるコントロールフレーム（Control Frame）をクライアント２０２に送信させて、次に伝送されるサブセグメントの属性を通知する。
【０１９４】
図３２は、図中の左右に異なるリプレゼンテーションの２個のセグメントデータが、それぞれ２個のサブセグメントデータから構成されるときに送信されるコントロールデータからなるコントロールフレーム（Control Frame）と、サブセグメントデータからなるメディアデータフレーム（Media Data Frame）の送信順序を説明する図である。
【０１９５】
すなわち、図３２には、左からリプレゼンテーションがvideo1（RepID ： video1）のセグメント番号が1となる（Segment No 1）セグメントデータが送信されるときの手順と、リプレゼンテーションがvideo2（RepID ： video2）のセグメント番号が2となる（Segment No 2）のセグメントデータが送信されるときの手順が示されている。
【０１９６】
サブセグメントデータは、例えば、セグメントデータがMPEGの画像データであるような場合における、GOP（Group of Picture）であり、セグメントデータの構成単位よりも、より小さなデータサイズの構成単位のデータである。
【０１９７】
この場合、図３２で示されるように、サブセグメント単位で伝送が行われるので、サブセグメント単位で、コントロールデータも構成される。
【０１９８】
従って、図３２においては、図中の左側のセグメントデータに対する１番目のサブセグメントデータ（Media Data Frame：Segment Data of Subsegment 1）が送信される前のタイミングで、コントロールデータ（streamInfo（RepID video1，SegmentNo 1，SubsegmentNo 1, SAPType 1））からなるコントロールデータフレーム（Control Frame）が送信される。
【０１９９】
同様に、図３２中の左側のセグメントデータに対する２番目のサブセグメントデータ（Media Data Frame：Segment Data of Subsegment 2）が送信される前のタイミングで、コントロールデータ（streamInfo（RepID video1，SegmentNo 1，SubsegmentNo 2, SAPType 3））からなるコントロールデータフレーム（Control Frame）が送信される。
【０２００】
引き続き、図３２中の右側のセグメントデータに対する１番目のサブセグメントデータ（Media Data Frame：Segment Data of Subsegment 1）が送信される前のタイミングで、コントロールデータ（streamInfo（RepID video2，SegmentNo 2，SubsegmentNo 1, SAPType 1））からなるコントロールデータフレーム（Control Frame）が送信される。
【０２０１】
そして、図中の右側のセグメントに対する２番目のサブセグメントデータ（Media Data Frame：Segment Data of Subsegment 2）が送信される前のタイミングで、コントロールデータ（streamInfo（RepID video2，SegmentNo 2，SubsegmentNo 2, SAPType 2））からなるコントロールデータフレーム（Control Frame）が送信される。
【０２０２】
ここで、図３１の説明に戻る。
【０２０３】
従って、この場合、サーバ２０１の通信制御部２１４は、ステップＳ１４４において、送信部２１２を制御して、図３１中の左側のセグメントに対する１番目のサブセグメントデータ（Media Data Frame：Segment Data of Subsegment 1（RepID video1，SegmentNo 1，SubsegmentNo 1, SAPType 1））を送信する。
【０２０４】
クライアント２０２の通信制御部２２７は、受信部２２１を制御して、このセグメントデータを受信して、バッファ２２３に記憶させる。このとき、再生処理部２２４は、バッファ２２３にバッファリングされたセグメントデータのデコードを開始する。ステップＳ１４５において、通信制御部２２７は、送信部２２２を制御して、コントロールデータ（playerInfo）をサーバ２０１に送信することで、再生処理部２２４におけるストリームのデコードを開始してからの経過時間を通知する。この際、クライアント２０２は、サブセグメント単位のセグメントデータよりも、より小さなデータに基づいて画像を表示する処理を実行することができるので、より高速に画像を表示することが可能となる。
【０２０５】
そして、サーバ２０１の通信処理部２１４は、ステップＳ１４６において、送信部２１２を制御して、図３２の左側のセグメントデータのうちの２番目のサブセグメントデータのコントロールデータ（streamInfo（RepID video1，SegmentNo 1，SubsegmentNo 2, SAPType 3））からなるコントロールフレーム（Control Frame）をクライアント２０２に送信して、次に伝送されるサブセグメントの属性を通知する。
【０２０６】
従って、この場合、サーバ２０１の通信制御部２１４は、ステップＳ１４７において、送信部２１２を制御して、図３２中の左側のセグメントに対する２番目のサブセグメントデータ（Media Data Frame：Segment Data of Subsegment 2（RepID video1，SegmentNo 1，SubsegmentNo 2, SAPType 3））を送信する。
【０２０７】
ここで、ユーザにより再生停止が指示された場合、クライアント２０２の通信制御部２２７は、ステップＳ１４８において、送信部２２２を制御して、コントロールデータ（closeMedia，stopStream）をサーバ２０１に送信する。これにより、クライアント２０２の再生処理部２２４は、バッファ２２３に記憶されている、受信したセグメントの再生をすべて終了する。ここで、通信処理部２２７は、送信部２２２を制御して、メディアをクローズすることをサーバ２０１に通知する。
【０２０８】
サーバ２０１の通信処理部２１４は、受信部２１１を制御して、コントロールデータ（closeMedia，stopStream）を受信すると、メディアの情報を破棄し、停止処理を開始する。そして、ステップＳ１４９において、サーバ２０１の通信処理部２１４は、送信部２１２を制御して、コントロールデータ（MediaStatus）をクライアント２０２に送信する。
【０２０９】
しかしながら、サーバ２０１の通信制御部２１４は、送信部２１２を制御して、サブセグメント単位の処理であることから、送信が開始された処理を停止することができないので、例えば、ステップＳ１５０において、引き続き図３２の右側のセグメントデータのうちの１番目のサブセグメントデータのコントロールデータ（streamInfo（RepID video2，SegmentNo 2，SubsegmentNo 1, SAPType 2））からなるコントロールフレーム（Control Frame）をクライアント２０２に送信して、次に伝送されるサブセグメントの属性を通知する。
【０２１０】
そして、サーバ２０１の通信制御部２１４は、ステップＳ１５１において、送信部２１２を制御して、図３２中の右側のセグメントに対する１番目のサブセグメントデータ（Media Data Frame：Segment Data of Subsegment 1（RepID video2，SegmentNo 2，SubsegmentNo 1, SAPType 2））を送信する。
【０２１１】
最後に、ステップＳ１５２において、サーバ２０１の通信制御部２１４は、送信部２１２を制御して、動作の停止をクライアントに通知する。
【０２１２】
以上の如く、セグメントデータ単位よりも、より小さなサブセグメント単位で、コントロールデータStreamInfo（SegmentNo，SubSegmentNo，SAP Type)を付して、管理することで、画像の再生表示時間、停止完了までの時間、およびコンテンツの切り替え等をより高速に実現することが可能となる。すなわち、上述したように、送信が開始された処理については停止できないため、サブセグメントデータのようにセグメントデータより小さな単位で送信を管理することで、画像の再生表示時間、停止完了までの時間、およびコンテンツの切り替え等をより高速に実現することが可能となる。
【０２１３】
また、例えば、ライブ放送では、例えば、GOP単位でサブセグメントを構成することで、伝送遅延をより短縮させることが可能となる。さらに、MPDにサブセグメントの情報がない場合、サーバ２０１の通信制御部２１４は、セグメントデータを解析（パース）して、可能であればサブセグメントに分割して、サブセグメント単位で伝送するようにしてもよく、このようにすることで、セグメントデータの管理を、より迅速なものとすることが可能となる。結果として、再生における操作性を向上させることが可能となる。
＜５．第４の実施の形態＞
＜Auto Segment Skip for Live Streaming＞
次に、図３３を参照して、本技術を適用した第４の実施の形態について説明する。
【０２１４】
図３３には、ライブ再生でネットワーク輻輳が発生した場合に行われるシーケンスが示されている。
【０２１５】
例えば、ユーザが、ライブ再生を開始するようにクライアント２０２に対する操作を行うと処理が開始される。ステップＳ１６１において、クライアント２０２は、コントロールデータ（capability，openMedia，playStream）をサーバ２０１送信し、クライアント２０２のケーパビリティを通知するとともに、メディアを指定してストリームの開始するように要求する。ここで、上述した図２０に示したようにcapabilityでは、segmentSkipにより、セグメントスキップに対応可能であるか否かを指定することができ、図３３の例では、セグメントスキップに対応可能であることを指定する“true”とされている。
【０２１６】
サーバ２０１は、この要求に従って、クライアント２０２により指定されたメディアのメディア情報を読み出し、ステップＳ１６２において、コントロールデータ（mediaInfo）をクライアント２０２に送信することでメディア情報を返信する。
【０２１７】
ここで、例えば、ライブ放送が既に始まっている場合は、最新のセグメントから伝送が行われる。サーバ２０１は、ステップＳ１６３において、コントロールデータ（streamInfo）をクライアント２０２に送信するのに続いて、ステップＳ１６４において、セグメントデータ（MediaDisc 1, SegmentNo 1699）をクライアント２０２に送信する。
【０２１８】
その後、セグメントデータの送信が順次行われ、サーバ２０１は、ステップＳ１６５において、コントロールデータ（streamInfo）を送信し、続いて、ステップＳ１６６において、セグメントデータ（MediaDisc 1, SegmentNo 1700）を送信する。
【０２１９】
クライアント２０２は、ステップＳ１６７において、コントロールデータ（playerInfo）をサーバ２０１に送信する。例えば、コントロールデータ（playerInfo）には、上述した図１９に示したようにcurrentPresentationTimeおよびBufferedTimeが含まれる。
【０２２０】
このとき、ネットワーク輻輳（Network Congestion）が発生して、サーバ２０１およびクライアント２０２の間で送受信が行うことができなくなった後、ネットワーク輻輳が解消したとする。
【０２２１】
このようにネットワーク輻輳が発生した場合、サーバ２０１は、前のセグメントデータ（SegmentNo 1700）の伝送に時間がかかってしまい、SegmentNo 1701を送信しても再生されないと判断した場合、SegmentNo 1701の送信をスキップする。
【０２２２】
即ち、サーバ２０１は、ステップＳ１６８およびＳ１６９において、コントロールデータ（mediaInfo）およびコントロールデータ（streamInfo）を送信した後、ステップＳ１７０において、セグメントデータ（MediaDisc 1, SegmentNo 1701）を送信する。つまり、サーバ２０１は、クライアント２０２においてライブ再生されるセグメントから送信を再開する。
【０２２３】
例えば、サーバ２０１は、SegmentNoおよびSubSegmentのシグナリングの他に、帯域に適応的に、クライアント２０２にセグメントがどのくらいバッファされているのかをシグナリングすることができる。即ち、サーバ２０１は、クライアント２０２からステップＳ１６７で送信されるコントロールデータ（playerInfo）により、currentPresentationTimeもしくはBufferedTimeをシグナリングすることができる。currentPresentationTimeは、クライアント２０２において再生処理部２２４によりストリームのデコードが開始されてからの経過時間を示す。BufferedTimeは、クライアント２０２のバッファ２２３に保持されているセグメントデータにて再生継続可能な時間を示し、仮にネットワークからセグメントデータを全く受信することができない状態において再生を継続することができる時間と同等である。
【０２２４】
つまり、クライアント２０２では、通信処理部２２７が、例えば、再生処理部２２４によりストリームのデコードを開始してからの経過時間を取得する。また、通信処理部２２７は、バッファ２２３に保持されているセグメントだけで再生を継続することができる再生継続可能時間を取得する。そして、通信処理部２２７は、サーバ２０１に対して適宜、経過時間または再生継続可能時間を通知する。これにより、サーバ２０１では、通信処理部２１４が、ステップＳ１６７でコントロールデータ（playerInfo）を受信することで、クライアント２０２でのライブ再生の再生状況を把握して、ネットワーク輻輳などが発生して復帰する際に、再生されないセグメントの送信をスキップするように通信処理を行い、送信部２１２によりセグメントの送信を行うことができる。
【０２２５】
従って、例えば、再生されない不要なセグメントの送信が行われないので、帯域をより有効に利用することができ、ライブ再生でネットワーク輻輳が発生した場合に適切な復帰を行うことができる。
【０２２６】
なお、currentPresentationTimeおよびBufferedTimeを通知するコントロールデータ（playerInfo）は、毎回送信する必要はなく、例えば、クライアント２０２は、再生が開始された時点、または、データが枯渇して再生を再開したときに送信することができる。
＜６．第５の実施の形態＞
＜Fast Switching of multiple media＞
次に、図３４および図３５を参照して、本技術を適用した第５の実施の形態について説明する。
【０２２７】
図３４および図３５には、複数のメディアを切り替えて再生させるシーケンスが示されている。
【０２２８】
例えば、ユーザが、再生を開始するようにクライアント２０２に対する操作を行うと処理が開始される。ステップＳ１８１において、クライアント２０２は、コントロールデータ（capability，openMedia，playStream）をサーバ２０１送信し、クライアント２０２のケーパビリティを通知するとともに、メディアを指定してストリームの開始するように要求する。
【０２２９】
サーバ２０１は、この要求に従って、クライアント２０２により指定されたメディアのメディア情報を読み出し、ステップＳ１８２において、コントロールデータ（mediaInfo）をクライアント２０２に送信することでメディア情報を返信する。このとき、図３４の例では、再生の対象とされるメディアは、MediaDesc 1とされ、サーバ２０１は、MediaDesc 1を配信するためのリソースを確保する。
【０２３０】
そして、サーバ２０１は、ステップＳ１８３において、コントロールデータ（streamInfo）をクライアント２０２に送信して、次に伝送されるセグメントデータの属性を通知する。続いて、サーバ２０１は、ステップＳ１８４において、セグメントデータ（MediaDesc 1，SegmentNo1447）をクライアント２０２に送信する。このとき、例えば、ライブ再生であって放送が既に始まっている場合、最新のセグメントから伝送が行われる。
【０２３１】
クライアント２０２は、このセグメントデータを受信してデコードを開始し、ステップＳ１８５において、コントロールデータ（playerInfo）をサーバ２０１に送信する。
【０２３２】
続いて、サーバ２０１は、セグメントデータの送信を継続し、ステップＳ１８６およびＳ１８７において、コントロールデータ（streamInfo）およびセグメントデータ（MediaDesc 1，SegmentNo1448）を、クライアント２０２にそれぞれ送信する。
【０２３３】
クライアント２０２は、このセグメントデータを受信してデコード行う一方で、ステップＳ１８８において、コントロールデータ（openMedia）をサーバ２０１送信し、別のメディアを指定してオープンするように要求する。
【０２３４】
サーバ２０１は、この要求に従って、クライアント２０２により指定されたメディアのメディア情報を読み出し、ステップＳ１８９において、コントロールデータ（mediaInfo）をクライアント２０２に送信することでメディア情報を返信する。このとき、図３４の例では、オープンされるメディアは、再生中のMediaDesc 1とは別のMediaDesc 2とされ、サーバ２０１は、MediaDesc 2を配信するためのリソースも確保する（オープン処理）。
【０２３５】
そして、サーバ２０１は、セグメントデータの送信を継続し、ステップＳ１９０およびＳ１９１において、コントロールデータ（streamInfo）およびセグメントデータ（MediaDesc 1，SegmentNo1449）を、クライアント２０２にそれぞれ送信する。続いて、図３５に示すように、ステップＳ１９２およびＳ１９３において、コントロールデータ（streamInfo）およびセグメントデータ（MediaDesc 1，SegmentNo1450）を、クライアント２０２にそれぞれ送信する。
【０２３６】
このとき、ユーザが、メディアを切り替えるようにクライアント２０２に対する操作を行うと、ステップＳ１９４において、クライアント２０２は、コントロールデータ（changeMedia）をサーバ２０１送信し、ストリームされるメディアをMediaDesc 2に切り替えるようにサーバ２０１に対して要求する。
【０２３７】
ここで、MediaDesc 2のメディア情報は、図３４のステップＳ１８９で既にクライアント２０２に送信されている。従って、サーバ２０１は、ステップＳ１９５において、コントロールデータ（streamInfo）を送信するのに続いて、ステップＳ１９６において、セグメントデータ（MediaDesc 2，SegmentNo7337）を送信する。これにより、途切れなくストリーム再生が継続される。
【０２３８】
そして、サーバ２０１は、セグメントデータの送信を継続し、ステップＳ１９７およびＳ１９８において、コントロールデータ（streamInfo）およびセグメントデータ（MediaDesc 2，SegmentNo7338）を、クライアント２０２にそれぞれ送信する。
【０２３９】
また、ユーザが再度、メディアを切り替えるようにクライアント２０２に対する操作を行うと、ステップＳ１９９において、クライアント２０２は、コントロールデータ（changeMedia）をサーバ２０１に送信し、ストリームされるメディアをMediaDesc 1に切り替えるようにサーバ２０１に対して要求する。
【０２４０】
ここで、MediaDesc 1のメディア情報は、図３４のステップＳ１８２で既にクライアント２０２に送信されている。従って、サーバ２０１は、ステップＳ２００において、コントロールデータ（streamInfo）を送信するのに続いて、ステップＳ２０１において、セグメントデータ（MediaDesc 1，SegmentNo1452）を送信する。このとき、サーバ２０１は、ライブ再生であれば最新のセグメントから送信を行い、VOD再生であれば、前回のメディアのセグメントの続きから送信を行う。
【０２４１】
そして、サーバ２０１は、セグメントデータの送信を継続し、ステップＳ２０２およびＳ２０３において、コントロールデータ（streamInfo）およびセグメントデータ（MediaDesc 1，SegmentNo1453）を、クライアント２０２にそれぞれ送信する。
【０２４２】
このように、複数のメディアを切り替えて再生する処理が行われ、以下同様に、サーバ２０１からクライアント２０２にセグメントデータが送信される。
【０２４３】
以上のように、サーバ２０１は、クライアント２０２の要求に応じて複数のメディアをあらかじめオープンしておくことができる。これにより、クライアント２０２が、ストリーム中にコントロールデータ（changeMedia）を送信することで、サーバ２０１は、各メディアのセグメントを切れ目なく送信することができる。即ち、クライアント２０２は、メディアを切り替える際に新しいＭＰＤ（メディア情報）をロードする処理が不要になるので、チャンネルをスムーズに高速に切り替えて、メディアを再生することができる。
【０２４４】
また、幾つのメディアをオープンできるのかはサーバ２０１の能力に依存するので、クライアント２０２が、サーバ２０１に対してメディアをオープンできるか否かを問い合わせるようにしてもよい。なお、OpenMediaおよびCloseMediaのコマンドではステートフルにＭＰＤ情報を維持できるようにされる。また、クライアント２０２がOpenMediaを送信するのに応じて、サーバ２０１はMediaDescriptorを返信する。
【０２４５】
例えば、放送型のサービスであれば、最初から複数のメディアをオープンするようにしておくことで、高速にチャンネルを切り替えることができる。
【０２４６】
＜７．第６の実施の形態＞
＜コンピュータ＞
上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここでコンピュータには、専用のハードウエアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータ等が含まれる。
【０２４７】
図３６は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。
【０２４８】
図３６に示されるコンピュータ９００において、CPU（Central Processing Unit）９０１、ROM（Read Only Memory）９０２、RAM（Random Access Memory）９０３は、バス９０４を介して相互に接続されている。
【０２４９】
バス９０４にはまた、入出力インタフェース９１０も接続されている。入出力インタフェース９１０には、入力部９１１、出力部９１２、記憶部９１３、通信部９１４、およびドライブ９１５が接続されている。
【０２５０】
入力部９１１は、例えば、キーボード、マウス、マイクロホン、タッチパネル、入力端子などよりなる。出力部９１２は、例えば、ディスプレイ、スピーカ、出力端子などよりなる。記憶部９１３は、例えば、ハードディスク、RAMディスク、不揮発性のメモリなどよりなる。通信部９１４は、例えば、ネットワークインタフェースよりなる。ドライブ９１５は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブルメディア９２１を駆動する。
【０２５１】
以上のように構成されるコンピュータでは、CPU９０１が、例えば、記憶部９１３に記憶されているプログラムを、入出力インタフェース９１０およびバス９０４を介して、RAM９０３にロードして実行することにより、上述した一連の処理が行われる。RAM９０３にはまた、CPU９０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０２５２】
コンピュータ（CPU９０１）が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア９２１に記録して適用することができる。その場合、プログラムは、リムーバブルメディア９２１をドライブ９１５に装着することにより、入出力インタフェース９１０を介して、記憶部９１３にインストールすることができる。
【０２５３】
また、このプログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することもできる。その場合、プログラムは、通信部９１４で受信し、記憶部９１３にインストールすることができる。
【０２５４】
その他、このプログラムは、ROM９０２や記憶部９１３に、あらかじめインストールしておくこともできる。
【０２５５】
なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
【０２５６】
また、本明細書において、記録媒体に記録されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０２５７】
また、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、全ての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
【０２５８】
また、以上において、１つの装置（または処理部）として説明した構成を分割し、複数の装置（または処理部）として構成するようにしてもよい。逆に、以上において複数の装置（または処理部）として説明した構成をまとめて１つの装置（または処理部）として構成されるようにしてもよい。また、各装置（または各処理部）の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置（または処理部）の構成の一部を他の装置（または他の処理部）の構成に含めるようにしてもよい。
【０２５９】
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
【０２６０】
例えば、本技術は、１つの機能を、ネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
【０２６１】
また、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。
【０２６２】
さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。
【０２６３】
上述した実施形態に係る情報処理装置は、例えば、衛星放送、ケーブルＴＶなどの有線放送、インターネット上での配信、及びセルラー通信による端末への配信などにおける送信機若しくは受信機、光ディスク、磁気ディスク及びフラッシュメモリなどの媒体に画像を記録する記録装置、又は、これら記憶媒体から画像を再生する再生装置などの様々な電子機器に応用され得る。
【０２６４】
なお、本技術は以下のような構成も取ることができる。
（１）
ネットワークを介してセグメント単位で送信されるコンテンツをライブ再生する再生装置における再生状況を把握する再生状況把握部と、
前記再生装置に前記セグメントを送信する際に、前記再生装置での再生状況に基づいて、前記再生装置においてライブ再生されないと判断した前記セグメントの送信を回避して前記セグメントの送信を行う送信部と
を備える情報処理装置。
（２）
前記再生状況把握部は、前記再生装置において再生を開始してからの経過時間を取得することにより、前記再生装置での再生状況を把握する
上記（１）に記載の情報処理装置。
（３）
前記再生状況把握部は、前記再生装置において保持されている前記セグメントだけでライブ再生を継続することができる再生継続可能時間を取得することにより、前記再生装置での再生状況を把握する
上記（１）または（２）に記載の情報処理装置。
（４）
ネットワークを介してセグメント単位で送信されるコンテンツをライブ再生する再生装置における再生状況を把握し、
前記再生装置に前記セグメントを送信する際に、前記再生装置での再生状況に基づいて、前記再生装置においてライブ再生されないと判断した前記セグメントの送信を回避して前記セグメントの送信を行う
ステップを含む情報処理方法。
【０２６５】
なお、本実施の形態は、上述した実施の形態に限定されるものではなく、本開示の要旨を逸脱しない範囲において種々の変更が可能である。
【符号の説明】
【０２６６】
１００  配信システム，  １０１  配信データ生成装置，  １０２  配信サーバ，  １
０３  端末装置，  １０４  ネットワーク，  ２０１  サーバ，  ２０２  クライアント
【図１】
2016015533.tif 000003
【図２】
2016015533.tif 000004
【図３】
2016015533.tif 000005
【図４】
2016015533.tif 000006
【図５】
2016015533.tif 000007
【図６】
2016015533.tif 000008
【図７】
2016015533.tif 000009
【図８】
2016015533.tif 000010
【図９】
2016015533.tif 000011
【図１０】
2016015533.tif 000012
【図１１】
2016015533.tif 000013
【図１２】
2016015533.tif 000014
【図１３】
2016015533.tif 000015
【図１４】
2016015533.tif 000016
【図１５】
2016015533.tif 000017
【図１６】
2016015533.tif 000018
【図１７】
2016015533.tif 000019
【図１８】
2016015533.tif 000020
【図１９】
2016015533.tif 000021
【図２０】
2016015533.tif 000022
【図２１】
2016015533.tif 000023
【図２２】
2016015533.tif 000024
【図２３】
2016015533.tif 000025
【図２４】
2016015533.tif 000026
【図２５】
2016015533.tif 000027
【図２６】
2016015533.tif 000028
【図２７】
2016015533.tif 000029
【図２８】
2016015533.tif 000030
【図２９】
2016015533.tif 000031
【図３０】
2016015533.tif 000032
【図３１】
2016015533.tif 000033
【図３２】
2016015533.tif 000034
【図３３】
2016015533.tif 000035
【図３４】
2016015533.tif 000036
【図３５】
2016015533.tif 000037
【図３６】
2016015533.tif 000038