JP2017073814A

JP2017073814A - コンテンツ送信装置およびコンテンツ再生装置

Info

Publication number: JP2017073814A
Application number: JP2016233265A
Authority: JP
Inventors: 徳毛　靖昭; Yasuaki Tokuge; 靖昭徳毛; 琢也岩波; Takuya Iwanami; 渡部　秀一; Shuichi Watabe; 秀一渡部; 鈴木　秀樹; Hideki Suzuki; 秀樹鈴木
Original assignee: Sharp Corp
Current assignee: Sharp Corp
Priority date: 2012-10-09
Filing date: 2016-11-30
Publication date: 2017-04-13
Also published as: US20150296269A1; US20170208366A1; JP2018186524A; US9641906B2; US9832534B2; EP2908535A1; WO2014057896A1; US20180070148A1; JPWO2014057896A1; EP2908535A4; JP2015208018A

Abstract

【課題】低遅延ライブストリーミングを実現する。【解決手段】クライアント（２）からセグメントの送信を要求するリクエストを受信すると、当該セグメントをさらに複数に分割したサブセグメント単位で、当該セグメントをクライアント（２）にチャンク転送するコンテンツ送信部（２２）を備える。【選択図】図１

Description

本発明は、コンテンツを送信するコンテンツ送信装置およびコンテンツを取得・再生するコンテンツ再生装置に関するものである。

インターネットの普及やコンピュータの高性能化に伴い、インターネットを介して動画像などの大容量コンテンツを配信することが広く行われている。例えば、ユーザの要求に応じて動画等のコンテンツを提供するＶＯＤ（Video On Demand）というサービスがある。ＶＯＤでは、例えば、特許文献１に記載されているように、ＨＴＴＰ（HyperText Transfer Protocol）を用いて、サーバ（コンテンツ提供装置）とクライアント（コンテンツ再生装置）との間でデータを送受信する。

ここで、ＨＴＴＰによるコンテンツの配信に関して、様々な技術が開発されている。例えば、ＭＰＥＧ（Motion Picture Experts Group）は、ＨＴＴＰを利用した適応ストリーミング技術をＭＰＥＧ−ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）規格として国際標準化を進めている。

ＭＰＥＧ−ＤＡＳＨでは、コンテンツは、複数のセグメント（segment）に時分割され、セグメント単位で伝送される。また、各セグメントは、１または複数のフラグメント（fragment）で構成される。また、コンテンツは、１または複数のピリオド（period）で構成されており、１つのピリオドに１または複数のセグメントが含まれる。

また、ＭＰＥＧ−ＤＡＳＨでは、１つのコンテンツに対して品質種別（ビットレート、画像解像度等の再生品質や、データフォーマット等の種別）が異なる複数のRepresentationが準備される。例えば、セグメント毎に異なるビットレートで符号化した複数のセグメントデータを準備する。これにより、コンテンツを受信して再生するクライアントは、コンテンツの受信状況等に応じて、要求するコンテンツ（セグメント）のビットレートを変えることにより、適応ストリーミングを実行することができる。

また、ＭＰＥＧ−ＤＡＳＨでは、コンテンツにＭＰＤ（Media Presentation Description）が対応付けられており、ＭＰＤによってコンテンツを管理する。ＭＰＤは、コンテンツのメタデータであって、コンテンツの管理情報をＸＭＬ形式で記述したものである。換言すると、ＭＰＤは、クライアントがコンテンツの取得・再生時に利用する情報である。

ＭＰＤの具体的な記述例を図１０に基づいて説明する。図１０は、ＭＰＤの記述例を示す図である。図１０に示すように、ＭＰＤ２００には、タイプ情報２１１、プロファイル情報２１２、バッファリング時間情報２１３、配信開始時刻情報２１４を含む情報２１０が記述されている。

タイプ情報２１１は、ライブ配信であるかオンデマンド配信であるかを示す情報（属性「type」の属性値）である。図示の例では、属性「type」の属性値が「dynamic」であり、このＭＰＤ２００が対応付けられたコンテンツがライブ配信コンテンツであることを示す。一方、オンデマンド配信の場合、属性「type」の属性値に「static」が記述される。

プロファイル情報２１２は、コンテンツのプロファイルを示す情報である。また、バッファリング時間情報２１３は、最小のバッファリング時間を示す情報である。図示の例では、属性「minBufferTime」の属性値が「PT10S」であるため、クライアントは少なくとも１０秒のバッファリングを行うことを示す。

配信開始時刻情報２１４は、サーバがコンテンツのライブストリーミング配信を開始する時刻を示す情報（属性「availabilityStartTime」の属性値）である。図示の例では、属性「availabilityStartTime」の属性値が「2012-09-20T15:00:00」であり、２０１２年９月２０日１５時にライブストリーミング配信が開始されることを示す。

また、ＭＰＤ２００には、コンテンツの再生期間を区切った各ピリオドに関するピリオド情報２２０が記述されている。図示の例では、ピリオド情報２２０として、コンテンツの配信開始時刻を基準とした場合のそのピリオドの開始時刻（属性「start」の属性値）およびそのピリオドの期間（属性「duration」の属性値）が記述されている。

また、コンテンツの取得先を示す取得先情報２３０が記述されている。図示の例では、取得先情報２３０として、サーバのＵＲＬが記述されている。

また、ここでは、コンテンツとして、ビットレートが1024kbpsの高品質Representationと、ビットレートが512kbpsの低品質Representationが用意されているものとする。そのため、ＭＰＤ２００には、或るピリオド（再生時刻０秒から３６００秒まで）に含まれるセグメントとして、高品質セグメントを示す高品質セグメント情報２４１と、低品質セグメントを示す低品質セグメント情報２４２とが記述されている。高品質セグメント情報２４１には、当該ピリオドに含まれる高品質RepresentationのＩＤおよびビットレートが記述されている。また、当該ピリオドに含まれる各セグメントの長さおよびＵＲＬが記述されている。また、低品質セグメント情報２４２も同様である。なお、当該ピリオドは、セグメント＃１〜セグメント＃６の６個のセグメントで構成されている。

次に、従来の基本的なセグメントデータのデータ構造について図１１に基づいて説明する。図１１は、従来における、高品質セグメントおよび低品質セグメントのセグメントデータのデータ構造を示す図である。ここでは、セグメントデータがＩＳＯＢＦＦ（ISO/IEC 14496-12）で規定されるbox形式で記述されている例を説明する。

図１１（ａ）に示すように、従来の高品質セグメントデータ２６０は、１つのstyp（Segment Type Box）２６１、１つのsidx（Segment Index Box）２６２、並びに、moof（Movie Fragment Box）２６３、２６５、２６７および２６９と、mdat（Media Data Box）２６４、２６６、２６８および２７０との１つまたは複数の組から構成される。また、図１１（ｂ）に示すように、低品質セグメントデータ２８０も、高品質セグメントデータ２６０と同様に、１つのstyp２８１、１つのsidx２８２、並びに、moof２８３、２８５、２８７および２８９と、mdat２８４、２８６、２８８および２９０との１つまたは複数の組から構成される。

styp２６１およびstyp２８１は、セグメントの種別および／またはバージョン情報等を示す情報である。sidx２６２およびsidx２８２は、セグメント内のランダムアクセスポイントに関する情報である。moof２６３、２６５、２６７および２６９、並びに、mdat２６４、２６６、２６８および２７０と、moof２８３、２８５、２８７および２８９、並びに、mdat２８４、２８６、２８８および２９０とは、セグメントを構成するフラグメントに関する情報である。

moofおよびmdatの１つの組が１つのフラグメントを構成する。また、１つまたは複数のフラグメントから構成され、ランダムアクセスに適応するようにセグメントを分割した単位をサブセグメント（subsegment）とする。例えば、図１１の例では、moof２６３、２６５およびmdat２６４、２６６が１つのサブセグメントを構成する。sidxの各エントリ２７１、２７２、２９１および２９２（図１１（ａ）および（ｂ）に示す「ｓ０」、「ｓ１」）には、各サブセグメントのバイトサイズ、時間情報などが記述されている。

次に、sidxのシンタックスの一例を図１２に基づいて説明する。図１２は、sidxのシンタックスの一例を示す図である。ここでは、sidxは、ISO/IEC 14496-12で定義されている例を示す。

このように、ＭＰＥＧ−ＤＡＳＨでは、サーバでのセグメントの生成開始から配信可能になるまでの時間を短縮するために、セグメントの時間長を小さくして低遅延ライブストリーミングに対応することを想定している。なお、サーバおよびクライアントによる処理遅延やネットワーク上の遅延等が発生するため、クライアントが厳密にリアルタイムに再生することは不可能である。そのため、わずかに遅延しているが、実質的にリアルタイムでのライブストリーミングを低遅延ライブストリーミングと称する。

日本国公開特許公報「特開２００５−１１０２４４号公報（２００５年４月２１日公開）」

"ISO/IEC 23009-1"、[online]、２０１２年４月１日、ISO/IEC、[平成２４年９月２６日検索]、インターネット＜ＵＲＬ：http://standards.iso.org/ittf/PubliclyAvailableStandards/c057623_ISO_IEC_23009-1_2012.zip＞

上述のように、ＭＰＥＧ−ＤＡＳＨでは、セグメントの時間長を短くすることで低遅延ライブストリーミングを実現しようとするものであるが、セグメントの時間長を短くすることで遅延が生じる場合がある。具体的には、セグメントの時間長が短い場合、通常、ネットワークジッタに対応するために、セグメントの送信を要求する複数のリクエストをパイプライン化して送信する。このとき、リクエストしたリソースがサーバに存在しないこと等によりエラーが発生した場合、再度複数のリクエストを送信しなければならず、再リクエストにより遅延が発生するという問題がある。

本発明は、上記の問題点に鑑みてなされたものであり、その目的は、安定的に低遅延ライブストリーミングを実行するコンテンツ送信装置およびコンテンツ再生装置を実現することにある。

上記の課題を解決するために、本発明の一態様に係るコンテンツ送信装置は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ再生装置に送信するコンテンツ送信装置であって、上記コンテンツ再生装置からリクエストを受信すると、当該リクエストに対する応答として、レスポンスを当該コンテンツ再生装置に送信する送信手段を備え、上記送信手段は、上記リクエストがセグメントの送信を要求するものである場合、当該セグメントを上記コンテンツ再生装置に、上記サブセグメント単位でチャンク転送する。

また、上記の課題を解決するために、本発明の一態様に係るコンテンツ送信装置の制御方法は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ再生装置に送信するコンテンツ送信装置の制御方法であって、上記コンテンツ再生装置からリクエストを受信すると、当該リクエストに対する応答として、レスポンスを当該コンテンツ再生装置に送信する送信ステップを含み、上記送信ステップにおいて、上記リクエストがセグメントの送信を要求するものである場合、当該セグメントを上記コンテンツ再生装置に、上記サブセグメント単位でチャンク転送する。

さらに、上記の課題を解決するために、本発明の一態様に係るコンテンツ再生装置は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ送信装置から取得して再生するコンテンツ再生装置であって、上記コンテンツ送信装置に、セグメントの送信を要求するリクエストを送信する取得手段を備え、上記取得手段は、上記リクエストに対する応答として、上記コンテンツ送信装置から、上記サブセグメント単位でチャンク転送された上記セグメントを取得する。

さらに、上記の課題を解決するために、本発明の一態様に係るコンテンツ再生装置の制御方法は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ送信装置から取得して再生するコンテンツ再生装置の制御方法であって、上記コンテンツ送信装置に、セグメントの送信を要求するリクエストを送信する送信ステップと、上記リクエストに対する応答として、上記コンテンツ送信装置から、上記サブセグメント単位でチャンク転送された上記セグメントを取得する取得ステップとを含む。

本発明の一態様によれば、低遅延ライブストリーミングを安定的に実現することができる。

本発明の実施形態を示すものであり、サーバおよびクライアントの要部構成を示すブロック図である。上記サーバおよびクライアントを含むコンテンツ配信システムの概要を示す図である。上記サーバが実行するセグメント送信処理の一例を示すフローチャートである。上記クライアントが実行するセグメント取得処理の一例を示すフローチャートである。本発明で用いるＭＰＤの記述例を示す図である。低遅延ライブストリーミングを実行する上記サーバ、上記クライアントおよびプロキシの動作シーケンスの一例を示す図である。低遅延ライブストリーミングにおいて送受信されるＨＴＴＰメッセージの一例を示す図である。本発明で用いるＭＰＤの他の記述例を示す図である。各サブセグメントの境界が揃っていない高品質セグメントおよび低品質セグメントのセグメントデータのデータ構造を示す図である。従来のＭＰＤの記述例を示す図である。従来における、高品質セグメントおよび低品質セグメントのセグメントデータのデータ構造を示す図である。従来技術を示すものであり、sidxのシンタックスの一例を示す図である。従来技術を示すものであり、バイトレンジリクエストによってコンテンツの一部を送受信するサーバ、クライアントおよびプロキシの動作シーケンスの一例を示す図である。従来のライブストリーミングにおいて送受信されるＨＴＴＰメッセージの一例を示す図である。伝送ストリームの構成の例を示す図である。本発明の別の実施形態に係るサーバおよびクライアントの要部構成を示すブロック図である。多重化ストリームが受信側で分離される過程を示す図である。コンテンツ内のピクチャと階層レベルの例を示す図である。伝送情報（プログラム構成テーブル）にｉｓＲｅｆ、ＲｅｆＰＩＤを格納した例を示す図である。

本発明の一実施形態について図１から図１４に基づいて説明すると以下の通りである。まず、本実施形態のコンテンツ配信システムの概要について、図２に基づいて説明する。

〔コンテンツ配信システムの概要〕
図２は、本実施形態に係るコンテンツ配信システム６の概要を示す図である。図２に示すように、コンテンツ配信システム６は、サーバ１、クライアント２、プロキシ３、ＭＰＤ記憶装置４およびセグメント記憶装置５を含む。

図２に示すように、クライアント２は、プロキシ３を介して、サーバ１と接続する。また、サーバ１は、ＭＰＤ記憶装置４およびセグメント記憶装置５と接続する。各装置は、有線通信または無線通信の任意のネットワークで接続される。

サーバ１は、クライアント２またはプロキシ３からコンテンツの送信の要求を受けて、コンテンツを送信するコンテンツ送信装置である。サーバ１は、コンテンツのデータ本体（セグメントデータ）を送信する前に、予めＭＰＤデータをクライアント２またはプロキシ３に送信する。なお、サーバ１は、ネットワーク７上のＭＰＤ記憶装置４およびセグメント記憶装置５からＭＰＤデータおよびセグメントデータを取得するものであるが、これに限るものではない。例えば、各サーバ１は、ローカルでＭＰＤデータおよびセグメントデータを保持していてもよい。

クライアント２は、サーバ１等の他の装置から取得したコンテンツ、または、自装置に格納しているコンテンツを再生するコンテンツ再生装置である。クライアント２は、例えば、デジタルテレビ、レコーダ、ＳＴＢ（Set Top Box）、ＰＣ、携帯電話機、スマートフォン、ゲーム機、ＰＤＡ（Personal Digital Assistant）、デジタルカメラ、デジタルビデオ等である。

プロキシ３は、或る装置（サーバ１またはクライアント２）から取得したデータを他の装置（クライアント２またはサーバ１）へ転送する中継装置である。例えば、プロキシ３は、クライアント２から取得したリクエストをサーバ１に転送し、サーバ１から取得したコンテンツをクライアント２に転送する。

また、プロキシ３は、サーバ１から取得したデータ（ＭＰＤおよびコンテンツ）をキャッシュするため、キャッシュサーバ（Cache Server）とも言える。なお、プロキシ３をキャッシュサーバと称する場合、サーバ１は、オリジンサーバ（Origin Server）と称する。このとき、プロキシ３は、クライアント２からリクエストを取得し、当該リクエストの示すコンテンツを保持している場合、当該コンテンツを読み出し、クライアント２へ当該コンテンツを送信してもよい。

また、コンテンツ配信システム６の構成は図２に示す例に限るものではない。例えば、コンテンツ配信システム６は、サーバ１を複数含んでいてもよいし、クライアント２を複数含んでいてもよい。また、コンテンツ配信システム６は、プロキシ３を複数含んでいてもよい。

また、本実施形態では、コンテンツ配信システム６におけるネットワーク上の伝送プロトコルは、ハイパーテキスト転送プロトコルとして広く用いられているＨＴＴＰを用いるものとする。また、サーバ１が配信するコンテンツは、映像コンテンツであり、コンテンツは、セグメント化されたＩＳＯＢＦＦデータであるものとする。すなわち、本実施形態では、コンテンツ配信システム６は、上述のＭＰＥＧ−ＤＡＳＨ規格に基づくコンテンツを配信するものである。

また、本発明で扱うコンテンツは、複数のセグメントから構成されるものであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツである。サブセグメントの時間情報とは、サブセグメントの時間的な位置を示す情報であり、例えば、サブセグメントの再生開始時刻を示す情報である。また、本発明では、セグメントをサブセグメントに分割する単位は任意でよいが、例えば、サブセグメント単位でランダムアクセスできるように、セグメントがサブセグメントに分割されていてもよい。換言すると、セグメントのヘッダに、サブセグメントの時間情報として、ランダムアクセスポイントの時間的な位置を示す情報が記述されていてもよい。

〔各装置の構成〕
次に、図１に基づいて、サーバ１およびクライアント２の要部構成について説明する。図１は、サーバ１およびクライアント２の要部構成の一例を示す図である。なお、図１では、プロキシ３を省略している。

（サーバについて）
図１に示すように、サーバ１は、サーバ制御部１１、サーバ記憶部１２およびサーバ通信部１３を備える構成である。

サーバ通信部１３は、無線通信手段または有線通信手段によって、クライアント２、プロキシ３、ＭＰＤ記憶装置４およびセグメント記憶装置５等の他の装置と通信を行い、サーバ制御部１１の指示に従って、データのやりとりを行うものである。

サーバ制御部１１は、サーバ記憶部１２から一時記憶部（不図示）に読み出されたプログラムを実行することにより、各種の演算を行うと共に、サーバ１が備える各部を統括的に制御するものである。

本実施形態では、サーバ制御部１１は、機能ブロックとして、コンテンツ取得部２１およびコンテンツ送信部（送信手段）２２備える構成である。サーバ制御部１１の各機能ブロック（２１、２２）は、ＣＰＵ（central processing unit）が、ＲＯＭ（read only memory）等で実現された記憶装置に記憶されているプログラムをＲＡＭ（random access memory）等で実現された一時記憶部に読み出して実行することで実現できる。

コンテンツ取得部２１は、コンテンツ送信部２２からの指示に基づいて、ＭＰＤ記憶装置４からＭＰＤデータまたはセグメント記憶装置５からセグメントデータを取得するものである。コンテンツ取得部２１は、取得したＭＰＤデータまたはセグメントデータをコンテンツ送信部２２に出力する。

なお、コンテンツ取得部２１は、コンテンツ送信部２２からの指示の有無に関わらず、事前に、ＭＰＤデータおよび／またはセグメントデータを取得していても良い。この場合、コンテンツ取得部２１は、事前に取得したＭＰＤデータおよびセグメントデータをサーバ記憶部１２に格納しておき、コンテンツ送信部２２からの指示に基づいて、サーバ記憶部１２からＭＰＤデータおよびセグメントデータを読み出す。

コンテンツ送信部２２は、クライアント２からリクエストを受信すると、受信したリクエストがセグメントの送信を要求するリクエストであるか否かを判定する。受信したリクエストがセグメントの送信を要求するリクエストである場合、コンテンツ送信部２２は、当該セグメントを取得するようにコンテンツ取得部２１に指示して、コンテンツ取得部２１からセグメントデータを取得し、当該セグメントデータを含むレスポンスをクライアント２に送信する。

ただし、本発明では、コンテンツ送信部２２は、セグメントデータを送信する際、セグメントデータを一度に全て送信するのではなく、セグメントをさらに複数に分割したサブセグメントを１チャンクとして、チャンク単位で送信する。

一方、受信したリクエストがセグメントの送信を要求するリクエストではない場合、リクエストに対するレスポンスを当該クライアント２に送信する。例えば、クライアント２からコンテンツ管理情報（ＭＰＤ）の送信を要求するリクエストを受信すると、当該コンテンツのＭＰＤを取得するようにコンテンツ取得部２１に指示し、コンテンツ取得部２１からＭＰＤデータを取得すると、取得したＭＰＤデータを含むレスポンスをクライアント２に送信する。また、クライアント２からWebページ等のリソースの送信を要求するリクエストを受信すると、当該リソースを取得するようにコンテンツ取得部２１に指示し、コンテンツ取得部２１からリソースを取得すると、取得したリソースを含むレスポンスをクライアント２に送信する。

なお、コンテンツ送信部２２は、受信したリクエストがセグメントの送信を要求するリクエストであるか否かを、受信したリクエストによって指定されたリソースのメディアタイプがセグメントであるか否かに基づいて判定してもよい。

サーバ記憶部１２は、サーバ制御部１１が参照するプログラムやデータ等を格納するものであり、例えば、コンテンツ取得部２１が取得したＭＰＤデータおよびセグメントデータ等を格納してもよい。

（クライアントについて）
図１に示すように、クライアント２は、クライアント制御部４１、クライアント記憶部４２、クライアント通信部４３、表示部４４および音声出力部４５を備える。なお、クライアント２は、操作部、音声入力部等の部材を備えていてもよいが、発明の特徴点とは関係がないため当該部材を図示していない。

クライアント通信部４３は、無線通信手段または有線通信手段によって、サーバ１、プロキシ３等の他の装置と通信を行い、クライアント制御部４１の指示に従って、データのやりとりを行うものである。

表示部４４は、クライアント制御部４１の指示に従って画像を表示するものである。表示部４４は、クライアント制御部４１の指示に従って画像を表示するものであればよく、例えば、ＬＣＤ（液晶ディスプレイ）、有機ＥＬディスプレイ、プラズマディスプレイなどを適用することが可能である。

音声出力部４５は、クライアント制御部４１から電気信号を受信し、受信した電気信号を音に変換し、クライアント２の外部に音を出力するものである。音声出力部４５は、いわゆるスピーカである。

クライアント制御部４１は、クライアント記憶部４２から一時記憶部（不図示）に読み出されたプログラムを実行することにより、各種の演算を行うと共に、クライアント２が備える各部を統括的に制御するものである。

本実施形態では、クライアント制御部４１は、機能ブロックとして、コンテンツ取得部（取得手段）５１およびコンテンツ再生部５２を備える構成である。これらのクライアント制御部４１の各機能ブロック（５１、５２）は、ＣＰＵが、ＲＯＭ等で実現された記憶装置に記憶されているプログラムをＲＡＭ等で実現された一時記憶部に読み出して実行することで実現できる。

コンテンツ取得部５１は、サーバ１にクライアント通信部４３を介してリクエストを送信し、サーバ１からコンテンツ（コンテンツに対応付けられたＭＰＤおよびコンテンツを構成するセグメント）を取得するものである。

具体的には、コンテンツ取得部５１は、ユーザから操作部（不図示）を介してコンテンツの取得（再生）指示が入力されると、当該コンテンツの管理情報（ＭＰＤ）の送信を要求するリクエストをサーバ１またはプロキシ３に送信する。そして、コンテンツ取得部５１は、当該リクエストのレスポンスとして、上記コンテンツのＭＰＤデータを受信する。コンテンツ取得部５１は、受信したＭＰＤデータを参照して、上記コンテンツを構成するセグメントの送信を要求するリクエストをサーバ１またはプロキシ３に送信する。そして、コンテンツ取得部５１は、当該リクエストのレスポンスとして、上記コンテンツのセグメントデータを取得する。コンテンツ取得部５１は、取得したセグメントデータをコンテンツ再生部５２に出力する。

また、コンテンツ取得部５１は、ネットワークの遅延等が発生した場合、取得するRepresentationの切替を実行する。このとき、次に残りのセグメントの一部を取得する場合、コンテンツ取得部５１は、未取得のデータを含むサブセグメントのバイトレンジを特定し、特定したバイトレンジに基づいて、バイトレンジテンプレートを用いたリクエストをサーバ１またはプロキシ３に送信する。

コンテンツ再生部５２は、コンテンツ取得部５１からセグメントデータを取得すると、ＭＰＤデータを参照して、取得したセグメントデータに基づいてコンテンツを再生するものである。

クライアント記憶部４２は、クライアント制御部４１が参照するプログラムやデータ等を格納するものであり、例えば、コンテンツ取得部５１が取得したＭＰＤデータおよびセグメントデータ等を格納してもよい。

〔サーバの処理〕
次に、図３に基づいて、サーバ１のセグメント送信処理について説明する。図３は、サーバ１のセグメント送信処理の一例を示すフローチャートである。

図３に示すように、サーバ１は、クライアント２から、セグメントまたはセグメントの一部の送信を要求するＨＴＴＰリクエストメッセージを受信する（Ｓ６１）。コンテンツ送信部２２は、当該セグメントを取得するようにコンテンツ取得部２１に指示して、コンテンツ取得部２１からセグメントデータを取得する。そして、コンテンツ送信部２２は、当該セグメントを複数に分割したサブセグメントを１チャンクとして、チャンク単位でセグメントをクライアント２に送信する（Ｓ６２）。

コンテンツ送信部２２は、チャンク単位で送信を行い、要求されたセグメント全体を送信すると（Ｓ６３でＹＥＳ）、セグメント送信処理を終了する。または、コンテンツ送信部２２は、途中でコネクションがクローズした場合（Ｓ６３でＹＥＳ）、セグメント送信処理を終了する。

〔クライアントの処理〕
次に、図４に基づいて、クライアント２のセグメント取得処理について説明する。図４は、クライアント２のセグメント取得処理の一例を示すフローチャートである。

図４に示すように、まず、コンテンツ取得部５１は、ＭＰＤデータを参照して、初期Representationのセグメント（例えば、高品質セグメント）の送信を要求するリクエストを送信する（Ｓ７１）。

リクエストを送信した後、コンテンツ取得部５１は、Representationを切り替えるべきか否かを判定する（Ｓ７２）。ここで、ネットワークの遅延等が発生していなければ、Representationを切り替えず（Ｓ７２でＮＯ）、サーバ１からサブセグメント単位でチャンク転送されたセグメントを取得する（Ｓ７３）。コンテンツ取得部５１は、リクエストしたセグメント全体を受信したか否かを判定し（Ｓ７４）、まだ全てを受信していなければ（Ｓ７４でＮＯ）、Ｓ７２に戻る。

ここで、ネットワークの遅延等が発生した場合、コンテンツ取得部５１は、取得するセグメントのRepresentationを切り替える（Ｓ７２でＹＥＳ）。コンテンツ取得部５１は、切替先のRepresentation（例えば、低品質セグメント）のsidxを解析し、リクエストしたセグメントのうちの未取得のサブセグメントのアクセスポイントに基づいて、未取得のサブセグメントのバイトレンジを特定する（Ｓ７５）。コンテンツ取得部５１は、特定したバイトレンジに基づいて、未取得のサブセグメントの取得先を示すバイトレンジテンプレートＵＲＬを生成する（Ｓ７６）。コンテンツ取得部５１は、生成したＵＲＬに基づいて、セグメントの残りのデータ（途中からのデータ）の送信を要求するリクエストを送信する（Ｓ７７）。そして、コンテンツ取得部５１は、切替先のepresentationのセグメントを途中から、チャンク単位で取得する（Ｓ７３）。

このようにして、セグメント全体を受信するまで処理を実行し、セグメント全体を受信すると（Ｓ７４でＹＥＳ）、セグメント取得処理を終了する。

〔ＭＰＤの記述例〕
次に、本発明で用いるＭＰＤの記述例について図５に基づいて説明する。図５は、本発明で用いるＭＰＤの記述例を示す図である。

図５に示すように、本発明で用いるＭＰＤ１００は、図１０に示す従来のＭＰＤ２００と比較して、情報１１０に含まれるプロファイル情報１１２、および、取得先情報１３０が異なる。

具体的には、ＭＰＤ１００では、プロファイル情報１１２に、低遅延ライブ配信であることを示す「urn:mpeg:dash:profile:isoff-low-latency-live:2012」が記述される。また、取得先情報１３０には、単なるサーバのＵＲＬではなく、バイトレンジテンプレート（BaseURL@byterange）が記述される。

〔バイトレンジリクエスト〕
従来、クライアント２は、コンテンツの一部を取得する場合、ＨＴＴＰ／１．１で規定されているバイトレンジリクエストによって取得することができる。しかしながら、バイトレンジリクエストに対するサーバ１からのレスポンスは、ステータスコードが「２０６」であるため、プロキシ３は、当該レスポンスに含まれるデータをキャッシュしない。そのため、再度同じコンテンツをプロキシ３を介してサーバ１にリクエストした場合であっても、プロキシ３にはキャッシュされていないため、サーバ１が当該コンテンツを送信しなければならない。よって、低遅延ライブストリーミングを安定的に実現することが困難となる。

以下に、より具体的に、バイトレンジリクエストによってコンテンツの一部を送受信するサーバ、クライアントおよびプロキシの動作シーケンス、および、従来のライブストリーミングにおいて送受信されるＨＴＴＰメッセージについて図１３および図１４に基づいて説明する。図１３は、バイトレンジリクエストによってコンテンツの一部を送受信するサーバ、クライアントおよびプロキシの動作シーケンスの一例を示す図である。また、図１４は、従来のライブストリーミングにおいて送受信されるＨＴＴＰメッセージの一例を示す図である。

図１３および図１４に示すように、まず、クライアントは、ＭＰＤ２００を参照して、セグメント＃１の送信を要求するためのリクエストメッセージ３０１をプロキシに送信する。プロキシは、リクエストメッセージ３０１を受信し、セグメント＃１がキャッシュされていないため、リクエストをそのまま転送して、サーバにリクエストメッセージ３０２を送信する。

サーバは、リクエストメッセージ３０２がセグメントの送信を要求するものであるため、リクエストメッセージ３０２の応答として、セグメント＃１のデータ本体を含むレスポンスメッセージ３０３をプロキシに送信する。プロキシは、レスポンスメッセージ３０３を受信し、レスポンスメッセージ３０３のステータスコードが「２００」であるため、レスポンスメッセージ３０３に含まれるデータをキャッシュ３０４すると共に、レスポンスをそのまま転送して、クライアントにレスポンスメッセージ３０５を送信する。クライアントは、レスポンスメッセージ３０５を受信して、セグメント＃１を取得する。

ここで、ネットワークの遅延等が発生したため、クライアントは、Representationの切替３０６を実行する。クライアントは、sidxを解析して、セグメント＃１の未取得のデータのバイトレンジ（xxx〜yyy）を特定する。クライアントは、特定したバイトレンジに基づいて、バイトレンジリクエストメッセージ３０７をプロキシに送信する。プロキシは、リクエストメッセージ３０７を受信し、ここでもリクエストの示すデータがキャッシュされていないため、リクエストをそのまま転送して、サーバにリクエストメッセージ３０８を送信する。

サーバ１は、リクエストメッセージ３０８がバイトレンジリクエストであるため、リクエストメッセージ３０８の応答として、セグメント＃１の一部である指定されたバイトレンジのデータを含む、ステータスコード「２０６」のレスポンスメッセージ３０９をプロキシに送信する。プロキシは、レスポンスメッセージ３０９を受信し、レスポンスメッセージ３０９のステータスコードが「２０６」であるため、レスポンスメッセージ３０９に含まれるデータをキャッシュせず、レスポンスをそのまま転送して、クライアントにレスポンスメッセー３１０を送信する。クライアントは、レスポンスメッセージ３１０を受信して、セグメント＃１の残りのデータを取得する。

このように、バイトレンジリクエストによってコンテンツの一部を送受信する場合、そのレスポンスのステータスコードが「２０６」であるため、プロキシ３はキャッシュしない。なお、プロキシ３がキャッシュするデータは、ステータスコードが「２００」、「２０３」、「３００」、「３０１」または「４１０」のレスポンスに含まれるデータである。

ＭＰＥＧ−ＤＡＳＨでは、キャッシュサーバであるプロキシ３でのキャッシュヒットによるＲＴＴ（Round Trip Time）の低減によっても、低遅延ライブストリーミングを実現することができる。そのため、プロキシ３がキャッシュしないデータがあると、低遅延ライブストリーミングを安定的に実現することが困難となる。

セグメントの一部をバイトレンジリクエストで取得する際に、プロキシ３でキャッシュされないという上記問題を解決するために、本発明では、上述のバイトレンジテンプレートを用いたリクエストでセグメントの一部を取得する。後述のように、バイトレンジテンプレートを用いたリクエストに対するレスポンスは、ステータスコードが「２００」であるため、プロキシ３は、当該レスポンスに含まれるデータをキャッシュすることができる。

〔実施例１〕
次に、低遅延ライブストリーミングを実行するサーバ１、クライアント２およびプロキシ３の動作シーケンスおよび低遅延ライブストリーミングにおいて送受信されるＨＴＴＰメッセージについて図６および図７に基づいて説明する。図６は、低遅延ライブストリーミングを実行するサーバ１、クライアント２およびプロキシ３の動作シーケンスの一例を示す図である。また、図７は、低遅延ライブストリーミングにおいて送受信されるＨＴＴＰメッセージの一例を示す図である。

図６および図７に示すように、まず、クライアント２は、ＭＰＤ７０を参照して、セグメント＃１の送信を要求するためのリクエストメッセージ８１をプロキシ３に送信する。プロキシ３は、リクエストメッセージ８１を受信し、セグメント＃１がキャッシュされていないため、リクエストをそのまま転送して、サーバ１にリクエストメッセージ８２を送信する。

サーバ１は、リクエストメッセージ８２がセグメントの送信を要求するものであるため、リクエストメッセージ８２の応答として、サブセグメント単位でチャンクに分割されたセグメント＃１のデータ本体を含むレスポンスメッセージ８３をプロキシ３に送信する。プロキシ３は、レスポンスメッセージ８３を受信し、レスポンスメッセージ８３のステータスコードが「２００」であるため、レスポンスメッセージ８３に含まれるデータをキャッシュ８４すると共に、レスポンスをそのまま転送して、クライアント２にレスポンスメッセージ８５を送信する。クライアント２は、レスポンスメッセージ８５を受信して、サブセグメント単位でチャンク転送されたセグメント＃１を取得する。

ここで、ネットワークの遅延等が発生したため、クライアント２は、Representationの切替８６を実行する。クライアント２は、sidxを解析して、セグメント＃１の未取得のデータを含むサブセグメントのバイトレンジ（xxx〜yyy）を特定する。クライアント２は、バイトレンジリクエストではなく、特定したバイトレンジに基づいて、バイトレンジテンプレートを用いたリクエストメッセージ８７をプロキシ３に送信する。プロキシ３は、リクエストメッセージ８７を受信し、ここでもリクエストの示すデータがキャッシュされていないため、リクエストをそのまま転送して、サーバ１にリクエストメッセージ８８を送信する。

サーバ１は、リクエストメッセージ８８がバイトレンジリクエストではなく、通常のリクエストであるため、リクエストメッセージ８８の応答として、指定されたバイトレンジのサブセグメントをチャンク単位で含む、ステータスコード「２００」のレスポンスメッセージ８９をプロキシ３に送信する。プロキシ３は、レスポンスメッセージ８９を受信し、レスポンスメッセージ８９のステータスコードが「２００」であるため、レスポンスメッセージ８９に含まれるデータをキャッシュ９０すると共に、レスポンスをそのまま転送して、クライアント２にレスポンスメッセージ９１を送信する。クライアント２は、レスポンスメッセージ９１を受信して、セグメント＃１の残りのデータをチャンク単位で取得する。

〔ＭＰＤの他の記述例〕
本発明では、セグメントをさらに複数のサブセグメントに分割しているが、このサブセグメントの時間長は、任意でよい。すなわち、各サブセグメントの時間長が一定であってもよいし、各サブセグメントの時間長が異なっていてもよい。

また、本発明では、サブセグメント単位でチャンク転送するため、サブセグメントの時間長と１チャンクの時間長は一致する。クライアント２は、チャンク時間長を事前に把握しておくことにより、ライブストリーミングにおける遅延量を予測することができる。そのため、ＭＰＤにチャンク時間長が記述されていることが好ましい。チャンク時間長が固定の場合、例えば、ＭＰＤにチャンク時間長が記述してもよい。また、チャンク時間長が可変の場合、例えば、ＭＰＤにチャンク時間長の最大値および／または最小値を記述してもよい。チャンク時間長の記述例については後述する。

また、ＭＰＥＧ−ＤＡＳＨでは、Representationを切り替えるため、Representation間で、対応する各サブセグメントの境界が揃っていることが好ましい。換言すると、Representation間で、対応する各サブセグメントの再生開始時刻が一致していることが好ましい。この場合、Representationを切り替えても、各サブセグメントの再生時刻が一致しているため、特に問題なく再生することができる。

一方、Representation間で、対応する各サブセグメントの境界が揃っていない場合、Representationの切替後に、整合をとって再生しなければならないため、クライアント２が各サブセグメントの境界が揃っているか否かを事前に把握しておくことが好ましい。そのため、ＭＰＤに各サブセグメントの境界が揃っているか否かを示すサブセグメントの配列に関する情報が記述されていることが好ましい。このサブセグメントの配列に関する情報については後述する。

次に、本発明で用いるＭＰＤの他の記述例について図８に基づいて説明する。図８は、本発明で用いるＭＰＤの他の記述例を示す図である。図８では、サブセグメントの配列に関する情報およびチャンク時間長に関する情報が記述されているＭＰＤの一例を示す。

図８に示すように、本発明で用いるＭＰＤ１０１は、図５に示すＭＰＤ１００と比較して、サブセグメントの配列に関する情報およびチャンク時間長に関する情報が追記されている。

具体的には、ＭＰＤ１０１では、サブセグメントの配列に関する情報１５０として、属性「AdaptationSet@subsegmentAlignment」、およびその属性値「true」が記述されている。属性値「true」は、各サブセグメントの境界が揃っていることを示し、各サブセグメントの境界が揃っていない場合、属性値として「false」が記述される。

また、ＭＰＤ１０１には、高品質セグメント情報１４３および低品質セグメント情報１４４に、チャンク時間長に関する情報として、属性「maxChunkDuration」、およびその属性値「PT10S」が記述されている。属性「maxChunkDuration」は、可変のチャンク時間長の最大値を示し、属性値「PT10S」は、その最大値が１０秒であることを示す。上述のように、チャンク時間長に関する情報として、固定のチャンク時間長を示す属性「chunkDuration」が記述されていても良く、可変のチャンク時間長の最小値を示す属性「minChunkDuration」が記述されていてもよい。

また、上記属性「chunkDuration」は、セグメントの最初のチャンクの時間長と解釈してもよい。あるいは、属性「chunkDuration」の代わりに、セグメントの時間長（属性「SegmentList@duration」の値と等しい）と、セグメントの最初のチャンク時間長（属性「SegmentList@chunkDuration」の値と等しい）との差分値を示す属性「chunkDurationOffset」が記述されていてもよい。

〔各サブセグメントの境界が揃っていない場合のRepresentationの切替例〕
次に、各サブセグメントの境界が揃っていない場合のRepresentationの切替について図９に基づいて説明する。図９は、各サブセグメントの境界が揃っていない高品質セグメントおよび低品質セグメントのセグメントデータのデータ構造を示す図である。

図９（ａ）に示すように、1024kbpsの高品質セグメント１６０は、moof１６３およびmdat１６４から成るサブセグメント＃０と、moof１６５およびmdat１６６から成るサブセグメント＃１と、moof１６７、１６９およびmdat１６８、１８０から成るサブセグメント＃２とを含む。一方、512kbpsの低品質セグメント１８０は、moof１８３およびmdat１８４から成るサブセグメント＃０と、moof１８５、１８７およびmdat１８６、１８８から成るサブセグメント＃１と、moof１８９およびmdat１９０から成るサブセグメント＃２とを含む。つまり、高品質セグメント１６０と低品質セグメント１８０とでは、サブセグメント＃２の再生開始時刻が異なっている。

なお、高品質セグメント１６０および低品質セグメント１８０に含まれるフラグメント（moofおよびmdat）の時間長は一定である。つまり、高品質セグメントのフラグメント１６３〜１７０と、低品質セグメントのフラグメント１８３〜１９０とがそれぞれ対応している。

ここで、高品質セグメントのサブセグメント＃１まで取得した後、Representationを切り替えて、低品質セグメントを取得するものとする。この場合、次に取得すべきデータは、高品質セグメントのmoof１６７に対応する低品質セグメントのmoof１８７である。ところが、低品質セグメント１８０では、moof１８５、１８７およびmdat１８６、１８８がサブセグメント＃１となっているため、moof１８７以降だけを取得することはできない。そのため、再生時にギャップが生じないように、未取得のデータであるmoof１８７を含むサブセグメント＃１から取得を開始する。このとき、moof１８５およびmdat１８６は時間的に重複して取得することとなるが、再生時に調整することによってスムーズなライブストリーミングを実現する。

なお、上述のように、セグメントのヘッダであるsidx１６２、１８２には、各サブセグメントの時間情報が記述されており、sidxを解析して、バイトレンジを特定する。

〔まとめ〕
本発明の一態様に係るコンテンツ送信装置は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ再生装置に送信するコンテンツ送信装置であって、上記コンテンツ再生装置からリクエストを受信すると、当該リクエストに対する応答として、レスポンスを当該コンテンツ再生装置に送信する送信手段を備え、上記送信手段は、上記リクエストがセグメントの送信を要求するものである場合、当該セグメントを上記コンテンツ再生装置に、上記サブセグメント単位でチャンク転送する。

本発明の一態様に係るコンテンツ送信装置の制御方法は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ再生装置に送信するコンテンツ送信装置の制御方法であって、上記コンテンツ再生装置からリクエストを受信すると、当該リクエストに対する応答として、レスポンスを当該コンテンツ再生装置に送信する送信ステップを含み、上記送信ステップにおいて、上記リクエストがセグメントの送信を要求するものである場合、当該セグメントを上記コンテンツ再生装置に、上記サブセグメント単位でチャンク転送する。

上記の構成によれば、上記送信手段は、セグメントの送信を要求するリクエストに対して、当該セグメントをさらに複数に分割したサブセグメント単位でチャンク転送する。すなわち、送信単位は、セグメントよりさらに時間的に短いサブセグメント単位で送信すると共に、１つのリクエストで複数のサブセグメントの送信を要求することができる。そのため、サブセグメントの生成開始から配信可能になるまでの時間を短縮しつつ、複数リクエストのパイプライン化にともなうエラー処理を抑制することができる。よって、低遅延ライブストリーミングを安定的に実現することができる。

さらに、本発明の一態様に係るコンテンツ送信装置では、上記サブセグメント単位でランダムアクセスできるように、上記セグメントが上記サブセグメントに分割されていてもよい。

さらに、本発明の一態様に係るコンテンツ送信装置において、上記送信手段は、各サブセグメントの時間長が一定の場合、上記サブセグメントの時間長が記述されたコンテンツ管理情報をコンテンツ再生装置に送信してもよい。

さらに、本発明の一態様に係るコンテンツ送信装置において、上記送信手段は、各サブセグメントの時間長が異なる場合、上記サブセグメントの時間長の最大値および最小値の少なくとも一方が記述されたコンテンツ管理情報をコンテンツ再生装置に送信してもよい。

上記の構成によれば、クライアントは、チャンク転送されたサブセグメントの時間長を把握することができるため、ライブストリーミングにおける遅延量を予測することができる。

さらに、本発明の一態様に係るコンテンツ再生装置は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ送信装置から取得して再生するコンテンツ再生装置であって、上記コンテンツ送信装置に、セグメントの送信を要求するリクエストを送信する取得手段を備え、上記取得手段は、上記リクエストに対する応答として、上記コンテンツ送信装置から、上記サブセグメント単位でチャンク転送された上記セグメントを取得する。

さらに、本発明の一態様に係るコンテンツ再生装置の制御方法は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ送信装置から取得して再生するコンテンツ再生装置の制御方法であって、上記コンテンツ送信装置に、セグメントの送信を要求するリクエストを送信する送信ステップと、上記リクエストに対する応答として、上記コンテンツ送信装置から、上記サブセグメント単位でチャンク転送された上記セグメントを取得する取得ステップとを含む。

〔実施例２〕
サーバとクライアントの間のネットワーク上に発生する遅延としては、実施例１において、クライアントのリクエストしたリソースがサーバに存在しないこと等によりエラーが発生した場合、再度複数のリクエストを送信するためにネットワーク及びクライアントに負荷がかかり、遅延が発生するという問題があった。クライアントに発生する遅延としては、クライアントの有するデコーダの処理能力が低いためにデコード処理時に負荷がかかり、遅延が発生するという問題もある。

本実施例では、クライアントのデコード処理能力に応じて、コンテンツ中の適切な情報を抽出することで、デコード処理時に発生する遅延を解消する方法について、図１５〜図１８を参照しながら以下に説明する。図１５は、本実施例に係る伝送ストリームの構成の例を示す図である。また、図１６は、本実施例に係るサーバおよびクライアントの要部構成を示すブロック図である。さらに、図１７は、本実施例に係る複数のフレームレートデータを多重化したストリームが受信側で分離される過程を示す図である。図１８は、本実施例に係るコンテンツ内のピクチャと階層レベルを示す図である。

現行のデジタル放送では、サーバにあたる放送局が映像、音声、その他の番組情報といった複数のデータをそれぞれ複数のパケットに格納し、１本のストリームに多重化して送出している。多重化には、ＭＰＥＧのストリームフォーマットであるＭＰＥＧ−２ＴＳ（トランスポートストリーム）が用いられる。多重化されたトランスポートストリーム（ＴＳ）は、クライアントにあたる放送受信機でそれぞれのパケットに分離され、映像や音声などのデータが取得される。

図１５（ａ）は、従来のＴＳの構造を示したものである。ＴＳは、それぞれが１８８バイトを有するＴＳパケットの集合で構成され、このＴＳパケットがクライアントに時系列的に入力される。このとき、各ＴＳパケットのヘッダには、図１５（ａ）に示されるようにパケット中のデータの種別を示すＰＩＤ（ＰａｃｋｅｔＩｄｅｎｔｉｆｉｅｒ）が付与され、この値を用いて、分離部は、パケットのペイロードに格納された映像、音声、関連情報などを識別し、分離した上で、適切なデコーダにデータを入力できる。

ＴＳでは、スケーラブル符号化された複数の映像品質から構成される映像データを分離し格納したパケットに同一のＰＩＤを付与する。そして、クライアントはデコード処理の段階で複数の映像品質データに分離することができる。即ち、１つの映像データは必ず１つのＰＩＤで伝送される。

一方、従来のＴＳにおいては、別のＰＩＤが付加されたコンテンツは、同一のコンテンツとして認識することができない。例えば、ＨＥＶＣなどの予測符号化圧縮規格で圧縮された映像データでは、各フレームをＩ、Ｐ、Ｂなどの予測方式の異なるピクチャとして圧縮することが可能であり、それぞれ別のパケットに格納して伝送することが可能であるが、ＴＳのレベルでパケットに格納されたピクチャデータがＩかＰかＢかを識別することはできない。このとき、他のピクチャの復号に対して参照されないＢピクチャがあれば、Ｂピクチャのデータを除去しても再生は可能である。従って、この性質を利用すれば、クライアントの能力に応じてＢピクチャデータのパケットを適宜削除し、クライアントごとにフレームレートを変えて再生することも可能である。しかし、ＴＳを用いて伝送する場合は、前述のとおり多重化分離部でパケットを識別できないため、このような処理は不可能であった。

上記課題に対し、本実施例では、図１５（ｂ）に示すように、ＰＩＤに加え、別のＰＩＤが付与されたパケットが同一のコンテンツであることを示すＲｅｆＰＩＤ（依存性識別子）を付与して、同一のコンテンツとして認識できるようにする。更に、本実施例では、パケットがＲｅｆＰＩＤを含むか否かを示すフラグｉｓＲｅｆを備える。ｉｓＲｅｆは２値のフラグであり、１のときＲｅｆＰＩＤを含むことを示し、０のときＲｅｆＰＩＤを含まないことを示す。

図１６は、本実施例の要部構成を示したブロック図である。図１６に示すように、サーバは複数のパケットを多重化する多重化部を備え、クライアントはサーバから受信した複数のパケットが多重化されたストリームを個別のパケットに分離する多重化分離部を備えている。なお、図１と図１６に示すサーバとクライアントにおいて、同様の部材に関する説明は適宜省略する。

（サーバについて）
サーバ送信部は、無線通信手段または有線通信手段によって、クライアントにデータを送信するものである。

サーバ制御部は、機能ブロックとして、コンテンツ生成部および多重化部、コンテンツ送信部（送信手段）を備える構成である。ここで、コンテンツ生成部はコンテンツデータを生成するものであり、多重化部においてパケットへの分離と多重化を行って、コンテンツ送信部に出力する。例えば、Ｉ、Ｐピクチャデータを格納したパケットにはＰＩＤの値ｐｉｄ＿ｂを付与し、Ｂピクチャデータを格納したパケットにはＰＩＤに値ｐｉｄ＿ａを付与する。さらに、Ｂピクチャデータを格納したパケットは、ｉｓＲｅｆの値を１とし、値ｐｉｄ＿ｂのＲｅｆＰＩＤを付与する。

（クライアントについて）
クライアント受信部は、無線通信手段または有線通信手段によって、サーバからデータを受信するものである。

クライアント制御部は、機能ブロックとして、コンテンツ取得部（取得手段）および多重化分離部、コンテンツ再生部を備える構成である。ここで、コンテンツ取得部は、サーバから送られた多重化ストリームを取得し、多重化分離部に出力する。

多重化分離部は、多重化ストリームをそれぞれのパケットに分離する。この際、ＰＩＤの値を参照することで、映像、音声、番組情報などのパケットに分離する。

多重化分離部はさらに、パケットがＲｅｆＰＩＤを含んでいるかを判断し、ＲｅｆＰＩＤを含んでいるパケットであれば、そのパケットのデータとＲｅｆＰＩＤが示すパケットのデータとを、１つのコンテンツのデータとして解釈する。そして、多重化分離部で分離したそれぞれのコンテンツのデータが、コンテンツ再生部に入力される。

なお、この際、パケットのデータとＲｅｆＰＩＤが示すパケットのデータとは、図示しない伝送時刻情報がそれぞれのパケットヘッダに格納されており、伝送時刻情報をみて順序を一意に決めることが可能である。あるいは、図示しないシーケンス番号がパケットヘッダに格納されて、シーケンス番号から順序を一意に決めるとしてもよい。

コンテンツ再生部は、ＰＩＤとＲｅｆＰＩＤに従って、多重化分離部で分離された映像のパケットデータを順番に映像信号にデコードし、デコードされたピクチャデータを表示順序に適宜並べ替えた上で、表示部にそれぞれ出力する。

図１７は、上記で説明したように、Ｉ、Ｐピクチャデータ、Ｂピクチャデータをそれぞれ、ＰＩＤが値ｐｉｄ＿ｂのパケット、ＰＩＤが値ｐｉｄ＿ａのパケットにそれぞれ格納して多重化されたストリームを受け取り、受け取った多重化ストリームをクライアントの多重化分離部において、ＰＩＤとＲｅｆＰＩＤに基づいてフレームレートの異なるコンテンツデータに多重化分離されることを示した図である。このとき、Ｉ、Ｐピクチャデータはフレームレート６０Ｈzの符号化データである。一方、ＢピクチャデータはＩ、Ｐピクチャデータの各ピクチャ間にＢピクチャ１枚を挟むことで１２０Ｈｚの再生を行うための付加データである。具体的には、ｐｉｄ＿ａのＲｅｆＰＩＤがｐｉｄ＿ｂであることから、ｐｉｄ＿ａとｐｉｄ＿ｂの全てのパケットを映像デコーダに出力することで、１２０Ｈｚの映像を再生する。一方、ｐｉｄ＿ｂのみを映像デコーダに出力する場合、６０Ｈｚの映像が再生される。

なお、本実施例においては、ｉｓＲｅｆ、ＲｅｆＰＩＤをパケットヘッダに付与する構成としたが、格納する場所はこれに限定されず、例えば既に実施例１で説明したのと同様、図１６に示すＭＰＤ記憶装置に格納しているＭＰＤに記述してもよい。あるいはＭＰＤ以外のコンテンツの伝送に関わる伝送情報や、コンテンツの再生に係る再生情報のメタデータの一部として記述してもよい。あるいはさらに、ＰＩＤの値自身にコンテンツ同士が同一のコンテンツであることを示す情報を記述し、ＰＩＤがＲｅｆＰＩＤを兼ねることで、ＲｅｆＰＩＤを付加しない構成としてもよい。また、ＲｅｆＰＩＤを必須とし、ｉｓＲｅｆを省略した構成も可能である。

例えば、現行のデジタル放送において使われているＰＡＴ／ＰＭＴ（ＰｒｏｇｒａｍＡｓｓｏｃｉａｔｉｏｎＴａｂｌｅ／ＰｒｏｇｒａｍＭａｐＴａｂｌｅ）をベースに、伝送情報（プログラム構成テーブル）にｉｓＲｅｆ、ＲｅｆＰＩＤを格納した例を図１９（ａ）に示す。また、ｉｓＲｅｆ、ＲｅｆＰＩＤを使う以外に、映像に複数ＰＩＤを記述した例を図１９（ｂ）に示す。図１９（ｂ）の場合には、映像が２つのＰＩＤの付与されたデータから成ることが示され、後ろに書かれたＰＩＤは前に書かれたＰＩＤに依存するものと解釈する。このような伝送情報を用いることで、クライアントの多重化分離部は、必要なデータのＰＩＤを知り、多重化ストリームから当該ＰＩＤの付与されたパケットデータのみを分離し、再生する。

これにより、クライアントは、多重化ストリーム中で異なるＰＩＤを持った同一コンテンツを含むパケットを識別することができ、デコード能力に応じて必要なパケットデータを取得して、デコードすることができる。上記例では、Ｉ、ＰピクチャデータとＢピクチャデータを格納したパケットから、６０Ｈｚ、１２０Ｈｚのフレームレートの異なる再生を行う例を示したが、これ以外にも、例えば、スケーラブル符号化において低解像度ベースレイヤのストリームデータと高解像度エンハンスメントレイヤのストリームデータを別ＰＩＤのパケットに格納し、ＰＩＤ、ＲｅｆＰＩＤを用いて識別することで、デコード能力の低いクライアントはベースレイヤのデータを取得し低解像度映像を再生、デコード能力の高いクライアントはベース、エンハンスメントレイヤのデータを取得し高解像度の映像を再生するといった処理も可能である。デコード能力に応じた適切なフレームレート、解像度のデータを抽出することで、デコード時に発生する遅延を解消できる。

また、Ｉ、Ｐ、ＢピクチャへのＰＩＤ、ＲｅｆＰＩＤの付与は上記例に限定されず、図１８に示すように、多数の階層からなるＢピクチャを有する場合に、Ｉ／Ｐピクチャのパケット（階層０）には値ｐｉｄ＿０のＰＩＤを付与し、階層１のＢピクチャのパケットには値ｐｉｄ＿１のＰＩＤを付与し、同様に、階層２、３のＢピクチャのパケットには値ｐｉｄ＿２、ｐｉｄ＿３のＰＩＤを付与してもよい。この場合、階層１のＢピクチャのパケットには値ｐｉｄ＿０のＲｅｆＰＩＤを付与し、同様に、階層２、３のＢピクチャのパケットには値ｐｉｄ＿１、ｐｉｄ＿２のＲｅｆＰＩＤを付与する。

上記の構成によれば、上記取得手段は、セグメントの送信を要求するリクエストに対して、当該セグメントをさらに複数に分割したサブセグメント単位でチャンク転送されたセグメントを取得する。すなわち、送信単位は、セグメントよりさらに時間的に短いサブセグメント単位で送信すると共に、１つのリクエストで複数のサブセグメントの送信を要求することができる。そのため、サブセグメントの生成開始から配信可能になるまでの時間を短縮しつつ、複数リクエストのパイプライン化にともなうエラー処理を抑制することができる。よって、低遅延ライブストリーミングを安定的に実現することができる。

さらに、本発明の一態様に係るコンテンツ再生装置では、上記サブセグメント単位でランダムアクセスできるように、上記セグメントが上記サブセグメントに分割されていてもよい。

さらに、本発明の一態様に係るコンテンツ再生装置において、上記取得手段は、セグメントの一部の送信を要求するリクエストを送信する場合、当該セグメントの一部を含むサブセグメントのバイトレンジを特定し、特定したバイトレンジを指定する、バイトレンジテンプレートを用いたリクエストを送信してもよい。

上記の構成によれば、上記取得手段は、セグメントの一部の送信を要求するリクエストを送信する場合、バイトレンジテンプレートを用いたリクエストを送信するため、当該リクエストに対するレスポンスのステータスコードは「２００」となる。よって、コンテンツの中継装置であるプロキシを介してコンテンツを取得する場合、プロキシは、上記レスポンスに含まれるデータをキャッシュすることができる。よって、ＲＴＴを低減することができ、安定的に低遅延ライブストリーミングを実現することができる。

さらに、本発明の一態様に係るコンテンツ配信システムは、上記コンテンツ送信装置と、上記コンテンツ再生装置とを含む。

上記の構成によれば、コンテンツ配信システムは、上記コンテンツ送信装置および上記コンテンツ再生装置と同様の効果を奏する。

また、コンテンツ再生装置がコンテンツ送信装置から取得する、複数のセグメントから構成されたコンテンツであって、当該セグメントがさらに複数のサブセグメントに分割されたコンテンツに対応付けられたコンテンツ管理情報のデータ構造であって、バイトレンジテンプレートが記述された、コンテンツの取得先を示す取得先情報を含むことを特徴とするコンテンツ管理情報のデータ構造も本発明の範疇に含まれる。

なお、上記コンテンツ送信装置および上記コンテンツ再生装置は、コンピュータによって実現してもよく、この場合には、コンピュータを上記コンテンツ送信装置および上記コンテンツ再生装置の各手段として動作させることにより、上記コンテンツ送信装置および上記コンテンツ再生装置をコンピュータにて実現させる制御プログラム、及びそれを記録したコンピュータ読み取り可能な記録媒体も本発明の範疇に入る。

本発明は上述した実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能である。すなわち、請求項に示した範囲で適宜変更した技術的手段を組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。

〔ソフトウェアによる実現例〕
最後に、サーバ１およびクライアント２の各ブロック、特にサーバ制御部１１およびクライアント制御部４１は、集積回路（ＩＣチップ）上に形成された論理回路によってハードウェア的に実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェア的に実現してもよい。

後者の場合、サーバ１およびクライアント２は、各機能を実現するプログラムの命令を実行するＣＰＵ、上記プログラムを格納したＲＯＭ（Read Only Memory）、上記プログラムを展開するＲＡＭ（Random Access Memory）、上記プログラムおよび各種データを格納するメモリ等の記憶装置（記録媒体）などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアであるサーバ１およびクライアント２の制御プログラムのプログラムコード（実行形式プログラム、中間コードプログラム、ソースプログラム）をコンピュータで読み取り可能に記録した記録媒体を、上記サーバ１およびクライアント２に供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。

上記記録媒体としては、一時的でない有形の媒体（non-transitory tangible medium）、例えば、磁気テープやカセットテープ等のテープ類、フロッピー（登録商標）ディスク／ハードディスク等の磁気ディスクやＣＤ−ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ／ＣＤ−Ｒ等の光ディスクを含むディスク類、ＩＣカード（メモリカードを含む）／光カード等のカード類、マスクＲＯＭ／ＥＰＲＯＭ／ＥＥＰＲＯＭ（登録商標）／フラッシュＲＯＭ等の半導体メモリ類、あるいはＰＬＤ（Programmable logic device）やＦＰＧＡ（Field Programmable Gate Array）等の論理回路類などを用いることができる。

また、サーバ１およびクライアント２を通信ネットワークと接続可能に構成し、上記プログラムコードを通信ネットワークを介して供給してもよい。この通信ネットワークは、プログラムコードを伝送可能であればよく、特に限定されない。例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ、ＩＳＤＮ、ＶＡＮ、ＣＡＴＶ通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、この通信ネットワークを構成する伝送媒体も、プログラムコードを伝送可能な媒体であればよく、特定の構成または種類のものに限定されない。例えば、ＩＥＥＥ１３９４、ＵＳＢ、電力線搬送、ケーブルＴＶ回線、電話線、ＡＤＳＬ（Asymmetric Digital Subscriber Line）回線等の有線でも、ＩｒＤＡやリモコンのような赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩＥＥＥ８０２．１１無線、ＨＤＲ（High Data Rate）、ＮＦＣ（Near Field Communication）、ＤＬＮＡ（Digital Living Network Alliance）（登録商標）、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。

本発明は、ＭＰＥＧ−ＤＡＳＨ規格のコンテンツを送信するコンテンツ送信装置、および、当該コンテンツを取得・再生するコンテンツ再生装置に利用することができる。

１サーバ
２クライアント
３プロキシ
４ＭＰＤ記憶装置
５セグメント記憶装置
６コンテンツ配信システム
２１コンテンツ取得部
２２コンテンツ送信部（送信手段）
５１コンテンツ取得部（取得手段）
５２コンテンツ再生部

Claims

複数のセグメントから構成されるライブ配信コンテンツをコンテンツ再生装置に送信するコンテンツ送信装置であって、
上記セグメントが配信可能となる時間と上記セグメントの少なくとも一部が配信可能となる時間との差分を示すオフセットが記述されたコンテンツ管理情報を上記コンテンツ再生装置に送信する管理情報送信手段を備えていることを特徴とするコンテンツ送信装置。
複数のセグメントから構成されるライブ配信コンテンツを受信し、再生するコンテンツ再生装置であって、
上記セグメントが配信可能となる時間と上記セグメントの少なくとも一部が配信可能となる時間との差分を示すオフセットが記述されたコンテンツ管理情報を取得する管理情報取得手段を備えることを特徴とするコンテンツ再生装置。