(57)【要約】  本技術は、データを迅速に配信することができるようにする送信装置、送信方法、受信装置、及び、受信方法に関する。フラグメントの一部と、http(Hypertext Transfer Protocol)ヘッダとを有するhttpレスポンスが配信される。httpヘッダには、フラグメントの順番を表すシーケンスナンバと、フラグメントの一部の、そのフラグメントにおける順番を表すバージョンとが含まれる。本技術は、例えば、コンテンツをマルチキャスト配信する場合等に適用することができる。
2015064383.tif 000002
【特許請求の範囲】
【請求項１】
フラグメントの一部と、
前記フラグメントの順番を表すシーケンスナンバと、
前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと
を含むhttp(Hypertext Transfer Protocol)ヘッダと
を含むhttpレスポンスを配信する配信部を備える
送信装置。
【請求項２】
前記フラグメントの最後の一部を含む前記httpレスポンスの前記バージョンは、前記フラグメントの最後を表す情報を含む
請求項１に記載の送信装置。
【請求項３】
前記フラグメントは、moof(movie fragment)とmdat(media data)とを有し、
前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、
前記httpヘッダは、前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻をさらに含む
請求項２に記載の送信装置。
【請求項４】
前記httpヘッダは、前記httpレスポンスに含まれる前記フラグメントの一部の先頭の前記サンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報を、さらに含む
請求項３に記載の送信装置。
【請求項５】
前記フラグメントの2番目以降の一部を含む前記httpレスポンスの前記httpヘッダが、前記サンプルカウントスタート情報を含む
請求項４に記載の送信装置。
【請求項６】
前記フラグメントは、fragmentedMP4のフラグメントである
請求項５に記載の送信装置。
【請求項７】
フラグメントの一部と、
前記フラグメントの順番を表すシーケンスナンバと、
前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと
を含むhttp(Hypertext Transfer Protocol)ヘッダと
を含むhttpレスポンスを配信する
ステップを含む送信方法。
【請求項８】
フラグメントの一部と、
前記フラグメントの順番を表すシーケンスナンバと、
前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと
を含むhttp(Hypertext Transfer Protocol)ヘッダと
を含むhttpレスポンスを受信する受信部を備える
受信装置。
【請求項９】
前記フラグメントの最後の一部を含む前記httpレスポンスの前記バージョンは、前記フラグメントの最後を表す情報を含む
請求項８に記載の受信装置。
【請求項１０】
前記フラグメントは、moof(movie fragment)とmdat(media data)とを有し、
前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、
前記httpヘッダは、前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻をさらに含む
請求項９に記載の受信装置。
【請求項１１】
前記httpヘッダは、前記httpレスポンスに含まれる前記フラグメントの一部の先頭の前記サンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報を、さらに含む
請求項１０に記載の受信装置。
【請求項１２】
前記フラグメントの2番目以降の一部を含む前記httpレスポンスの前記httpヘッダが、前記サンプルカウントスタート情報を含む
請求項１１に記載の受信装置。
【請求項１３】
前記フラグメントは、fragmentedMP4のフラグメントである
請求項１２に記載の受信装置。
【請求項１４】
フラグメントの一部と、
前記フラグメントの順番を表すシーケンスナンバと、
前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと
を含むhttp(Hypertext Transfer Protocol)ヘッダと
を含むhttpレスポンスを受信する
ステップを含む受信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、送信装置、送信方法、受信装置、及び、受信方法に関し、特に、例えば、データを迅速に配信すること等ができるようにする送信装置、送信方法、受信装置、及び、受信方法に関する。
【背景技術】
【０００２】
近年、インターネット上のストリーミングサービスの主流が、OTT-V(Over The Top Video)となっている。例えば、MPEG-DASH(Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP(Hypertext Transfer Protocol))（以下、DASHともいう）が、OTT-Vの基盤技術として普及し始めている。【０００３】
DASHでは、例えば、ストリームを配信するサーバから、同一ソースからの特性の異なるストリームを最適に選択するための属性情報を含むメタデータとしてのMPD(Media Presentation Description)を、ストリームを受信するクライアントに通知し、クライアントにおいて、そのMPDを用いることで、ネットワーク環境適応型のストリーミングが実現される（例えば、非特許文献１を参照）。【０００４】
すなわち、DASHでは、サーバが、同一内容のコンテンツとして、配信パスの通信環境や、クライアントの能力、状態等に応じて画質や画サイズ等が異なる複数のストリームを用意する。【０００５】
一方、クライアントは、サーバが用意している複数のストリームのうちの、クライアントが受信可能であり、かつ、クライアントの能力（デコード能力等）に適したストリームを適応的に選択し、そのストリームを受信して再生する。【０００６】
DASHでは、クライアントが、ストリームを適応的に選択して受信することができるように、MPDと呼ばれる、コンテンツの再生制御に用いられるメタデータが、サーバからクライアントに配信される。【０００７】
MPDには、コンテンツを分割したセグメント(Audio/Video/Subtitle等のメディアデータ)のアドレスとしてのURL(Uniform Resource Locator)等が記述される。クライアントは、MPDに記述されたURL等に基づいて、コンテンツの配信元となる(web)サーバにhttpリクエストを送信し、このhttpリクエストに応じてサーバがユニキャスト配信するセグメントを受信して再生する。
【先行技術文献】
【非特許文献】
【０００８】
【非特許文献１】「既存のWebサーバーで途切れない動画配信を実現」、平林光浩、NIKKEI ELECTRONICS 2012.3.19
【発明の概要】
【発明が解決しようとする課題】
【０００９】
DASHによるコンテンツの配信は、ポイントトゥーポイントのhttpストリーミングにより実現されるため、例えば、スポーツ中継等の、極めて多数のユーザが同時に視聴する可能性があるコンテンツ(番組)のストリーミング等に適用する場合には、Akamai等のCDN(Contents Delivery Network)の利用（サポート）が必要となる。【００１０】
但し、CDNを利用しても、CDNのコスト的な制約から、既存の放送配信に匹敵する程のスケーラビリティを求めることは難しい。【００１１】
DASHはhttpを利用するストリーミングプロトコルをベースとしているが、多数のユーザが同時に視聴するコンテンツ等については、例えば、RTP(Real-time Transport Protocol)やFLUTE(File Delivery over Unidirectional Transport)等のマルチキャストやブロードキャスト(MC/BC)ベアラを併用することにより、一斉同報配信を行い、ネットワークリソースの負荷を軽減することが望ましい。【００１２】
ところで、現行のDASHでは、コンテンツのストリームを分割したセグメント（のファイル）を、DASHでのファイル配信単位（制御対象）として、そのセグメント単位で、ファイルが配信される。【００１３】
したがって、現行のDASHでは、コンテンツをマルチキャスト配信（ブロードキャスト配信を含む）する場合に、セグメントが生成されるまで、コンテンツの配信を待つ必要がある。【００１４】
今後は、より高画質の動画配信が一般になることが予想され、その場合、コンテンツのストリームのビットレートが大になる。【００１５】
コンテンツのストリームのビットレートが大である場合に、セグメントの生成が完了するのを待って、セグメントの単位で、コンテンツの配信、すなわち、バルク転送を行うのでは、ネットワークの帯域が圧迫され、シェーピングが必要になることがある。【００１６】
したがって、セグメントの生成が完了するのを待って、セグメントの単位で、コンテンツを配信するのでは、最終的には、クライアントでのコンテンツの受信、及び、バッファリングの開始に遅延が生じるため、コンテンツを迅速に配信する技術の提案が要請されている。【００１７】
本技術は、このような状況に鑑みてなされたものであり、コンテンツ等のデータを迅速に配信することができるようにするものである。
【課題を解決するための手段】
【００１８】
本技術の送信装置は、フラグメントの一部と、前記フラグメントの順番を表すシーケンスナンバと、前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンとを含むhttp(Hypertext Transfer Protocol)ヘッダとを含むhttpレスポンスを配信する配信部を備える送信装置である。【００１９】
本技術の送信方法は、フラグメントの一部と、前記フラグメントの順番を表すシーケンスナンバと、前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンとを含むhttp(Hypertext Transfer Protocol)ヘッダとを含むhttpレスポンスを配信するステップを含む送信方法である。【００２０】
以上のような本技術の送信装置、及び、送信方法においては、フラグメントの一部と、http(Hypertext Transfer Protocol)ヘッダとを含むhttpレスポンスが配信される。httpヘッダには、前記フラグメントの順番を表すシーケンスナンバと、前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンとが含まれる。【００２１】
本技術の受信装置は、フラグメントの一部と、前記フラグメントの順番を表すシーケンスナンバと、前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンとを含むhttp(Hypertext Transfer Protocol)ヘッダとを含むhttpレスポンスを受信する受信部を備える受信装置である。【００２２】
本技術の受信方法は、フラグメントの一部と、前記フラグメントの順番を表すシーケンスナンバと、前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンとを含むhttp(Hypertext Transfer Protocol)ヘッダとを含むhttpレスポンスを受信するステップを含む受信方法である。【００２３】
以上のような本技術の受信装置、及び、受信方法においては、フラグメントの一部と、http(Hypertext Transfer Protocol)ヘッダとを含むhttpレスポンスが受信される。httpヘッダには、前記フラグメントの順番を表すシーケンスナンバと、前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンとが含まれる。【００２４】
なお、送信装置、及び、受信装置は、独立した装置であっても良いし、１つの装置を構成している内部ブロックであっても良い。
【発明の効果】
【００２５】
本技術によれば、データを迅速に配信すること等ができる。【００２６】
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
【図面の簡単な説明】
【００２７】
【図１】本技術を適用したコンテンツ提供システムの一実施の形態の構成例を示すブロック図である。
【図２】配信サーバ１１の構成例を示すブロック図である。
【図３】クライアント１２の構成例を示すブロック図である。
【図４】コンテンツ提供システムによるコンテンツの提供の処理の例を説明する図である。
【図５】コンテンツ提供システムにおいて、ネットワーク１０を介して配信されるデータの例を示す図である。
【図６】MPD，SDP，USD、及び、OMA-ESGを説明する図である。
【図７】DASHのファイル配信単位であるセグメントの構成を説明する図である。
【図８】１個のフラグメントを有するセグメントと、複数のフラグメントを有するセグメントとの構成例を示す図である。
【図９】DASHでの、セグメントをファイル配信単位とするコンテンツの配信の例を示す図である。
【図１０】配信サーバ１１での、ポーションをファイル配信単位とするコンテンツの配信の概要を説明する図である。
【図１１】セグメントとポーションとの関係の例を示す図である。
【図１２】ポーション６０としてのhttpレスポンスの例を示す図である。
【図１３】ポーション７０としてのhttpレスポンスの例を示す図である。
【図１４】ポーション単位でのコンテンツの配信の処理の例を説明するフローチャートである。
【図１５】ポーション単位でのコンテンツの受信の処理の例を説明するフローチャートである。
【図１６】LCTパケットによるポーション（及びセグメント）のマルチキャスト配信を説明する図である。
【図１７】LCTパケットのフォーマットを示す図である。
【図１８】LCTヘッダのフォーマットを示す図である。
【図１９】ポーション単位でのコンテンツの配信の例を示す図である。
【図２０】LCTヘッダの拡張ヘッダ(Header Extentions)のフォーマットを示す図である。
【図２１】優先度パラメータを格納する新たな拡張ヘッダの定義の例を示す図である。
【図２２】優先度パラメータ(Filtering Parameter)の定義の例を示す図である。
【図２３】MVC Filterの定義の例を示す図である。
【図２４】優先度パラメータを有するLCTパケットの配信の処理の例を説明するフローチャートである。
【図２５】クライアント１２が行うパケットフィルタリングの処理の例を説明するフローチャートである。
【図２６】本技術を適用したコンピュータの一実施の形態の構成例を示すブロック図である。
【発明を実施するための形態】
【００２８】
＜本技術を適用したコンテンツ提供システムの一実施の形態＞
【００２９】
図１は、本技術を適用したコンテンツ提供システムの一実施の形態の構成例を示すブロック図である。
【００３０】
図１において、コンテンツ提供システムは、１以上の配信サーバ１１、１以上のクライアント１２、及び、NTP(Network Time Protocol)サーバ１３が、ネットワーク１０に接続されて構成される。
【００３１】
図１のコンテンツ提供システムでは、DASHを利用して、配信サーバ１１から、ネットワーク１０を介して、クライアント１２に対して、コンテンツが提供される。
【００３２】
ここで、現行のDASHでは、ストリーミングそのものがOTT/CDN(Over The Top/Contents Delivery Network)上のユニキャストにより行われることが前提となっているが、図１のコンテンツ提供システムでは、コンテンツを、ユニキャスト配信する他、例えば、携帯網上の品質の保証された一斉同報可能なマルチキャストネットワーク(eMBMS等)上でマルチキャスト配信することができるようになっている。
【００３３】
ネットワーク１０は、ユニキャストやマルチキャストが可能な、インターネット等の双方向ネットワークと、ブロードキャストやマルチキャストが可能な放送系ネットワークとを包含する。ネットワーク１０としては、例えば、3GPP(3rd Generation Partnership Project)のMBMS(Multimedia Broadcast Multicast Service)（eMBMS(Evolved MBMS)を含む）等を採用することができる。
【００３４】
配信サーバ１１は、例えば、放送局に対応し、その放送局のチャンネル（サービス）の番組として、同一内容のコンテンツのストリームであって、ビットレートや画サイズ等が異なる複数のストリームを、ネットワーク１０を介して配信する。
【００３５】
クライアント１２は、配信サーバ１１が配信するコンテンツ（のストリーム）を、ネットワーク１０を介して受信して再生する。
【００３６】
NTPサーバ１３は、UTC(Coordinated Universal Time)タイムフォーマットに従った時刻情報であるNTP時刻を、ネットワーク１０を介して提供する。
【００３７】
配信サーバ１１、及び、クライアント１２は、NTPサーバ１３から提供されるNTP時刻に同期して動作することができる。
【００３８】
なお、配信サーバ１１が配信する番組は、リアルタイムの番組（生放送の番組）であってもよいし、録画番組であってもよい。
【００３９】
＜配信サーバ１１の構成例＞
【００４０】
図２は、図１の配信サーバ１１の構成例を示すブロック図である。
【００４１】
図２において、配信サーバ１１は、チャンネルストリーマ２１、セグメンタ２２、メタデータジェネレータ２３、FLUTE(File Delivery over Unidirectional Transport)ストリーマ２４、マルチキャストサーバ２５、及び、webサーバ２６を有する。
【００４２】
ここで、チャンネルストリーマ２１ないしwebサーバ２６は、ネットワーク１０上の一カ所に配置することもできるし、ネットワーク１０上に分散して配置することもできる。チャンネルストリーマ２１ないしwebサーバ２６を、ネットワーク１０上に分散して配置する場合、相互間での通信は、ネットワーク１０の他、専用線その他の任意の通信回線を介して行うことができる。
【００４３】
チャンネルストリーマ２１は、配信サーバ１１のチャンネルの番組として配信するためのコンテンツのソースデータとしてのビデオや、オーディオ、字幕等を管理しており、コンテンツのソースデータとしてのビデオ等からビットレートが異なる複数のストリーミングデータを生成して、セグメンタ２２に供給する。
【００４４】
セグメンタ２２は、チャンネルストリーマ２１からの各ストリーミングデータを、時間方向に分割したセグメントのファイルを生成し、FLUTEストリーマ２４、及び、webサーバ２６に供給する。
【００４５】
すなわち、セグメンタ２２は、ストリーミングデータを分割して、例えば、fragmentedMP4のフラグメント(moofとmdat)を生成し、そのフラグメントの１以上を集めてセグメントのファイルを生成する。
【００４６】
また、セグメンタ２２は、セグメントのURL（セグメントを提供するサーバ（例えば、配信サーバ１１）のURL）や、セグメントのレンジ(range)（セグメントに含まれるビデオ等のコンテンツ中の範囲を表す情報）等の、MPDの生成に必要なセグメントに関係する関係情報を、メタデータジェネレータ２３に供給する。
【００４７】
ここで、セグメンタ２２は、フラグメントを集めたセグメントではなく、フラグメントの生成中に、フラグメントの一部で構成される後述するポーションを生成し、セグメントに代えて、ポーションを、FLUTEストリーマ２４に供給することができる。
【００４８】
メタデータジェネレータ２３は、セグメンタ２２から供給されるセグメントの関係情報等を用いて、クライアント１２でのセグメントの受信等に必要なコンテンツのメタデータとして、例えば、MBMSのUSD(User Service Description)、DASHのMPD、及び、IETF(Internet Engineering Task Force)のSDP(Session Description Protocol)（ファイル）の組み合わせ、又は、それらのUSD，MPD、及び、SDPに、OMA-ESG(Open Mobile Alliance-Electronic Service Guide)を加えた組み合わせを生成する。
【００４９】
すなわち、メタデータジェネレータ２３は、セグメンタ２２から供給されるセグメントの関係情報を用いて、クライアント１２がセグメントを受信して再生制御を行うために必要な、セグメントのURL等が記述されたMPDを生成する。
【００５０】
さらに、メタデータジェネレータ２３は、コンテンツがマルチキャスト配信（ブロードキャスト配信を含む）されることをアナウンスするアナウンス情報として、USD、及び、SDP、又は、USD，SDP、及び、OMA-ESGを生成する。
【００５１】
メタデータジェネレータ２３は、メタデータを、FLUTEストリーマ２４、及び、webサーバ２６に供給する。
【００５２】
FLUTEストリーマ２４は、セグメンタ２２から供給されるコンテンツ（のセグメント又はポーション）を、FLUTEパケット、すなわち、LCT(Layerd Coding Transport)パケット（本実施の形態では、LCTヘッダを有するパケットを意味し、ALC(Asynchronous Layered Coding)パケットを含む）に格納し、マルチキャストサーバ２５に供給する。
【００５３】
また、FLUTEストリーマ２４は、メタデータジェネレータ２３から供給されるメタデータを、LCTパケットに格納し、マルチキャストサーバ２５に供給する。
【００５４】
マルチキャストサーバ２５は、FLUTEストリーマ２４からのLCTパケットを、ネットワーク１０を介して(FLUTE)マルチキャスト配信する。
【００５５】
ここで、FLUTEストリーマ２４からのLCTパケットには、上述したように、コンテンツ（のセグメント又はポーション）や、メタデータが格納されているので、マルチキャストサーバ２５では、コンテンツや、メタデータが、マルチキャスト配信されることになる。
【００５６】
webサーバ２６は、クライアント１２からの要求（httpリクエスト）に応じて、メタデータジェネレータ２３からのメタデータや、セグメンタ２２からのコンテンツ（のセグメント）を、ネットワーク１０を介して、クライアント１２に、(http)ユニキャスト配信する。
【００５７】
ここで、以上のように、マルチキャストサーバ２５、及び、webサーバ２６は、コンテンツやメタデータを配信する配信部として機能する。
【００５８】
なお、図２では、webサーバ２６において、コンテンツのセグメントをユニキャスト配信することとしたが、webサーバ２６では、マルチキャストサーバ２５と同様に、コンテンツのセグメントではなく、ポーションを、ユニキャスト配信することができる。
【００５９】
＜クライアント１２の構成例＞
【００６０】
図３は、図１のクライアント１２の構成例を示すブロック図である。
【００６１】
図３において、クライアント１２は、受信部３０、及び、再生部３３を有する。
【００６２】
受信部３０は、例えば、ユーザによるクライアント１２の操作等に応じて、配信サーバ１１から配信されるコンテンツやメタデータを受信する受信部として機能する。
【００６３】
すなわち、受信部３０は、配信サーバ１１から配信されるメタデータを受信する。さらに、受信部３０は、例えば、ユーザによるクライアント１２の操作等に応じて、配信サーバ１１から受信したメタデータに基づき、配信サーバ１１から配信されるコンテンツ（のセグメントやポーション）を受信する。
【００６４】
そして、受信部３０は、配信サーバ１１から受信したコンテンツを、再生部３３に供給し、配信サーバ１１から受信したメタデータに基づき、再生部３３でのコンテンツの再生を制御する。
【００６５】
再生部３３は、受信部３０の制御に従い、受信部３０から供給されるコンテンツとしてのビデオや、オーディオ、字幕等を再生する。
【００６６】
ここで、受信部３０は、ミドルウェア３１とDASHクライアント３２を有する。
【００６７】
DASHクライアント３２は、必要に応じて、MPDを要求するhttpリクエストや、コンテンツのセグメントを要求するhttpリクエストを、ミドルウェア３１に出力する。
【００６８】
ミドルウェア３１は、配信サーバ１１からマルチキャスト配信されてくるコンテンツ（のセグメントやポーション）や、メタデータを必要に応じて受信しており、DASHクライアント３２がhttpリクエストを出力すると、そのhttpリクエストにより要求されているMPDやセグメントが、マルチキャスト配信されているかどうかを、メタデータに基づいて判定する。
【００６９】
そして、DASHクライアント３２が出力するhttpリクエストにより要求されているMPDやセグメントが、マルチキャスト配信されている場合には、ミドルウェア３１は、そのマルチキャスト配信されるMPDやセグメント（又はセグメントの一部を含むポーション）を受信し、DASHクライアント３２に供給する。
【００７０】
なお、ミドルウェア３１は、DASHクライアント３２が出力するhttpリクエストにより要求されているMPDやセグメントが、既に受信済みである場合には、その受信済みのMPDやセグメントを、DASHクライアント３２に供給する。
【００７１】
一方、DASHクライアント３２が出力するhttpリクエストにより要求されているMPDやセグメントが、マルチキャスト配信されていない場合、ミドルウェア３１は、DASHクライアント３２が出力するhttpリクエストを、そのまま、ネットワーク１０（の配信サーバ１１）に送信する。そして、ミドルウェア３１は、そのhttpリクエストに応じて、（配信サーバ１１から）ユニキャスト配信されてくるMPDやセグメントを受信し、DASHクライアント３２に供給する。
【００７２】
したがって、DASHクライアント３２は、一般的なDASHクライアントと同様に、必要なMPDやセグメントを要求するhttpリクエストを出力し、そのhttpリクエストに応じて、ミドルウェア３１から供給されるMPDやセグメントを受信して処理する。
【００７３】
＜コンテンツ提供システムの処理＞
【００７４】
図４は、図１のコンテンツ提供システムによるコンテンツの提供の処理の例を説明する図である。
【００７５】
チャンネルストリーマ２１（図２）は、ステップＳ１１において、配信サーバ１１のチャンネルの番組として配信するためのコンテンツのソースデータとしてのビデオ等からビットレートが異なる複数のストリーミングデータを生成する。
【００７６】
そして、チャンネルストリーマ２１は、ステップＳ１２において、コンテンツの、ビットレートが異なる複数のストリーミングデータを、セグメンタ２２に供給する。
【００７７】
セグメンタ２２（図２）は、ステップＳ２１において、チャンネルストリーマ２１から供給されるコンテンツ（の複数のストリーミングデータ）を受信する。
【００７８】
セグメンタ２２は、ステップＳ２２において、チャンネルストリーマ２１からのコンテンツから、DASHのファイル配信単位であるセグメントを生成し、ステップＳ２３において、そのセグメントを、FLUTEストリーマ２４、および、webサーバ２６に供給する。
【００７９】
さらに、セグメンタ２２は、ステップＳ２４において、セグメントの関係情報を生成し、メタデータジェネレータ２３に供給する。
【００８０】
メタデータジェネレータ２３（図２）は、ステップＳ３１において、セグメンタ２２からステップＳ２４で供給されるセグメントの関係情報を受信する。
【００８１】
そして、メタデータジェネレータ２３は、ステップＳ３２において、セグメンタ２２からの関係情報等を用いて、コンテンツのメタデータを生成し、FLUTEストリーマ２４、及び、webサーバ２６に供給する。
【００８２】
FLUTEストリーマ２４（図２）は、ステップＳ４１において、セグメンタ２２からステップＳ２３で供給されるコンテンツ（のセグメント）を受信し、ステップＳ４２において、そのコンテンツを含むLCTパケットを生成して、マルチキャストサーバ２５に供給する。
【００８３】
さらに、FLUTEストリーマ２４は、ステップＳ４３において、メタデータジェネレータ２３からステップＳ３２で供給されるメタデータを受信し、ステップＳ４４において、そのメタデータを含むLCTパケットを生成して、マルチキャストサーバ２５に供給する。
【００８４】
マルチキャストサーバ２５（図２）は、ステップＳ５１において、FLUTEストリーマ２４からステップＳ４２で供給される、コンテンツを含むLCTパケットを受信し、ステップＳ５２において、メタデータを含むLCTパケットを受信する。
【００８５】
そして、マルチキャストサーバ２５は、ステップＳ５３において、FLUTEストリーマ２４からのメタデータを含むLCTパケットを、マルチキャスト配信し、ステップＳ５４において、FLUTEストリーマ２４からのコンテンツを含むLCTパケットを、マルチキャスト配信する。
【００８６】
webサーバ２６（図２）は、ステップＳ６１において、セグメンタ２２からステップＳ２３で供給されるコンテンツ（のセグメント）を受信し、ステップＳ６２において、メタデータジェネレータ２３からステップＳ３２で供給されるメタデータを受信する。
【００８７】
そして、ステップＳ６３において、webサーバ２６は、クライアント１２から、メタデータを要求するhttpリクエストが送信されてくると、そのhttpリクエストを受信する。
【００８８】
その後、ステップＳ６４において、webサーバ２６は、クライアント１２からのhttpリクエストによって要求されているメタデータを、クライアント１２に、ユニキャスト配信する。
【００８９】
また、ステップＳ６５において、webサーバ２６は、クライアント１２から、コンテンツ（のセグメント）を要求するhttpリクエストが送信されてくると、そのhttpリクエストを受信する。
【００９０】
その後、ステップＳ６６において、webサーバ２６は、クライアント１２からのhttpリクエストによって要求されているコンテンツ（のセグメント）を、クライアント１２に、ユニキャスト配信する。
【００９１】
クライアント１２（図３）では、受信部３０が、ステップＳ７１において、マルチキャストサーバ２５がステップＳ５３でマルチキャスト配信するメタデータ（のLCTパケット）を受信する。
【００９２】
又は、クライアント１２では、受信部３０が、ステップＳ７２において、メタデータを要求するhttpリクエストを送信する。
【００９３】
クライアント１２がステップＳ７２で送信するhttpリクエストは、上述したように、webサーバ２６がステップＳ６３で受信し、ステップＳ６４で、そのhttpリクエストによって要求されているメタデータを、クライアント１２に、ユニキャスト配信する。
【００９４】
クライアント１２の受信部３０は、ステップＳ７３において、以上のようにしてユニキャスト配信されてくるメタデータを受信する。
【００９５】
そして、クライアント１２の受信部３０は、ステップＳ７４において、ステップＳ７１又はＳ７３で受信したメタデータに基づき、マルチキャストサーバ２５がステップＳ５４でマルチキャスト配信するコンテンツ（のLCTパケット）を受信する。
【００９６】
又は、クライアント１２では、受信部３０が、ステップＳ７５において、ステップＳ７１又はＳ７３で受信したメタデータに基づき、コンテンツを要求するhttpリクエストを送信する。
【００９７】
クライアント１２がステップＳ７５で送信するhttpリクエストは、上述したように、webサーバ２６がステップＳ６５で受信し、ステップＳ６６で、そのhttpリクエストによって要求されているコンテンツを、クライアント１２に、ユニキャスト配信する。
【００９８】
クライアント１２の受信部３０は、ステップＳ７６において、以上のようにしてユニキャスト配信されてくるコンテンツを受信する。
【００９９】
そして、クライアント１２の再生部３３は、ステップＳ７７において、受信部３０がステップＳ７４又はＳ７６で受信したコンテンツを、メタデータ(MPD)に基づいて再生する。
【０１００】
＜ネットワーク１０を介して配信されるデータの説明＞
【０１０１】
図５は、図１のコンテンツ提供システムにおいて、ネットワーク１０を介して配信されるデータの例を示す図である。
【０１０２】
コンテンツ提供システムでは、MPDや、SDP，USD，OMA-ESG等のメタデータと、コンテンツ（のセグメント又はポーション）とが、クライアント１２に配信される。
【０１０３】
メタデータ、及び、コンテンツは、マルチキャスト配信することもできるし、ユニキャスト配信することもできる。
【０１０４】
メタデータとしては、MPD，SDP、及び、USDの組み合わせや、それらに、OMA-ESGを加えた組み合わせが用いられる。
【０１０５】
図６は、MPD，SDP，USD、及び、OMA-ESGを説明する図である。
【０１０６】
いま、ある番組を、注目する注目番組とすると、その注目番組のOMA-ESGには、注目番組の詳細情報や、注目番組のUSDへのアクセス方法等が記述される。
【０１０７】
したがって、クライアント１２において、注目番組のOMA-ESGを取得すると、そのOMA-ESGに記述されているUSDへのアクセス方法を参照することにより、注目番組のUSDを取得することができる。
【０１０８】
注目番組のUSDには、注目番組のSDPのURI(Uniform Resource Identifier)や、注目番組のMPDのURI等が記述される。
【０１０９】
したがって、クライアント１２において、注目番組のUSDを取得すると、そのUSDに記述されているSDPやMPDのURIを参照することにより、注目番組のSDPやMPDを取得することができる。
【０１１０】
注目番組のSDPには、注目番組のコンテンツをマルチキャスト配信するIPアドレスとポート番号等のトランスポート属性等が記述される。
【０１１１】
したがって、注目番組のSDPを取得することにより、そのSDPに記述されているIPアドレスとポート番号に基づき、マルチキャスト配信されてくる注目番組のコンテンツを受信することができる。
【０１１２】
以上のように、USD、及び、SDPの組み合わせや、USD，SDP、及び、OMA-ESGの組み合わせによれば、クライアント１２では、コンテンツがマルチキャスト配信されることを認識し、そのマルチキャスト配信されてくるコンテンツを受信することができる。
【０１１３】
注目番組のMPDには、注目番組のセグメントのURLや、そのセグメントの再生制御に必要な情報等が記述される。
【０１１４】
したがって、注目番組のMPDを取得することにより、そのMPDに記述されているURLに基づき、注目番組のセグメントをユニキャストで受信することができる。また、注目番組のMPDに基づき、注目番組のセグメントを再生することができる。
【０１１５】
すなわち、MPDには、セグメントの再生制御に必要な情報が含まれるため、MPDは、セグメントをユニキャストで受信するのに必要である他、セグメントの再生にも必要である。
【０１１６】
＜セグメントの構成＞
【０１１７】
図７は、DASHのファイル配信単位であるセグメントの構成を説明する図である。
【０１１８】
ここで、DASHで配信するコンテンツのフォーマットは、特に限定されるものではないが、本実施の形態では、DASHで配信するコンテンツのフォーマットとして、例えば、fragmentedMP4（のファイル）を採用することとする。
【０１１９】
セグメント(Media Segment)は、styp(segment type)（ボックス）、必要なsidx(segment index)（ボックス）、１個以上のフラグメント(MP4 fragment)を有する。
【０１２０】
ここで、stypが、'msdh'であるときは、セグメントに、sidxが含まれず、stypが、'msix'であるときは、セグメントに、sidxが含まれる。以下では、sidxについては、適宜、記載を省略する。
【０１２１】
フラグメントは、moof(movie fragment)（ボックス）、及び、mdat(media data)（ボックス）を有する。
【０１２２】
mdatは、mdatヘッダと、１個以上のサンプルを有する。サンプルとは、MP4ファイル内のメディアデータ（ビデオ等のデータ）にアクセスする場合の、最小のアクセス単位である。したがって、サンプルより細かい単位で、MP4ファイル内のメディアデータにアクセスすることはできない。
【０１２３】
moofは、mfhd(movie fragment header)（ボックス）と、traf(track fragment)（ボックス）とを有する。
【０１２４】
mfhdには、シーケンスナンバ(sequence_number)が格納される。sequence_numberは、そのsequence_numberを有するフラグメントの順番を表す。
【０１２５】
trafは、tfhd(track fragment header)（ボックス）や、tfdt(track fragment decode time)（ボックス）、trun(track fragment run)（ボックス）、sdtp(independent samples)（ボックス）等を有する。
【０１２６】
tfdtには、BaseMediaDecodeTimeが格納される。BaseMediaDecodeTimeは、そのBaseMediaDecodeTimeを有するフラグメントに含まれるサンプルのうちの、先頭のサンプルのプレゼンテーションタイムを表す。
【０１２７】
trunには、そのtrunを有するフラグメントに含まれる各サンプルのプレゼンテーションタイムを計算するのに必要な情報が格納される。
【０１２８】
図８は、１個のフラグメントを有するセグメントと、複数のフラグメントを有するセグメントとの構成例を示す図である。
【０１２９】
図８のＡは、１個のフラグメントを有するセグメントの構成例を示している。
【０１３０】
図８のＡでは、３個の連続するセグメント#1，#2，#3のそれぞれが、１個のフラグメントを有する。
【０１３１】
この場合、最初のセグメント#1が有する１個のフラグメントのsequence_number（以下、sqnとも記載する）が、例えば、1であるとすると、２番目のセグメント#2が有する１個のフラグメントのsqnは、例えば、直前のフラグメントのsqn=1を1だけインクリメントした2となる。さらに、３番目のセグメント#3が有する１個のフラグメントのsqnは、例えば、直前のフラグメントのsqn=2を1だけインクリメントした3となる。
【０１３２】
図８のＢは、複数のフラグメントを有するセグメントの構成例を示している。
【０１３３】
図８のＢでは、セグメント#1は、3個のフラグメントを有している。
【０１３４】
この場合、セグメント#1の最初のフラグメントのsqnが、例えば、1であるとすると、セグメント#1の２番目のフラグメントのsqnは、例えば、直前のフラグメントのsqn=1を1だけインクリメントした2となる。さらに、セグメント#1の３番目のフラグメントのsqnは、例えば、直前のフラグメントのsqn=2を1だけインクリメントした3となる。
【０１３５】
以下、説明を簡単にするため、特に断らない限り、セグメントは、図８のＡに示したように、１個のフラグメントを有することとする。
【０１３６】
＜セグメントをファイル配信単位とするコンテンツの配信＞
【０１３７】
図９は、DASHでの、セグメントをファイル配信単位とするコンテンツの配信の例を示す図である。
【０１３８】
図９では、それぞれが１以上のサンプルであるサンプル群#1，#2、及び、#3が、フラグメントを構成するサンプル群として、順次生成されている。そして、配信サーバ１１（図２）のセグメンタ２２において、フラグメントの最後のサンプル群#3の生成の完了後に、それらのサンプル群#1ないし#3を配置したmdatと、サンプル群#1ないし#3のmoofとを含むフラグメントが生成され、そのフラグメントを含むセグメントが生成されており、その後、FLUTEストリーマ２４、及び、マルチキャストサーバ２５において、そのセグメントが配信される。
【０１３９】
ここで、サンプル群#1ないし#3のmoofは、例えば、サンプル群#1ないし#3の生成と並列して行われる。
【０１４０】
また、フラグメントとするコンテンツの範囲（フラグメントのmdatとして配置するサンプル群#1ないし#3）としては、例えば、ランダムアクセス可能な最小の単位であるGOP(Group Of Picture)の範囲を採用することができる。
【０１４１】
但し、フラグメントとするコンテンツの範囲は、GOPの範囲に限定されるものではない。
【０１４２】
ところで、GOPの時間としては、例えば、約0.5ないし2秒程度が採用されることが多い。したがって、フラグメントとするコンテンツの範囲として、GOPの範囲を採用する場合には、moof、ひいては、セグメントは、少なくとも、約0.5ないし2秒程度であるGOPの時間だけ待って生成される。すなわち、セグメントの生成には、少なくとも、GOPの時間だけ要する。
【０１４３】
その結果、セグメントをファイル配信単位としてマルチキャスト配信する場合には、セグメントの配信に、少なくとも、そのセグメントの生成に要するGOPの時間だけ待つ必要がある。
【０１４４】
今後、より高画質の動画配信が行われることが予想され、その場合、セグメントのデータ量は膨大になる。かかる膨大なデータ量のセグメントを、GOPの時間だけ待って配信する場合には、ネットワークの帯域が圧迫され、シェーピングが必要になることがある。
【０１４５】
したがって、セグメントをファイル配信単位とするのでは、最終的には、クライアントでのコンテンツの受信、及び、バッファリングの開始に遅延が生じる。
【０１４６】
そこで、配信サーバ１１では、セグメントよりも小さい、フラグメントの一部を含むデータ（以下、ポーションともいう）を、ファイル配信単位として、そのポーションをマルチキャスト配信することで、コンテンツ（のデータ）を迅速に配信し、これにより、クライアントでのコンテンツの受信、及び、バッファリングの開始に生じる遅延を抑制する。
【０１４７】
＜ポーションをファイル配信単位とするコンテンツの配信＞
【０１４８】
図１０は、配信サーバ１１での、ポーションをファイル配信単位とするコンテンツの配信の概要を説明する図である。
【０１４９】
図１０では、図９の場合と同様に、サンプル群#1，#2、及び、#3が、フラグメントを構成するサンプル群として、順次生成される。
【０１５０】
但し、図１０では、配信サーバ１１（図２）のセグメンタ２２において、フラグメントの最後のサンプル群#3の生成が完了するのを待たずに、サンプル群#1が生成された時点で、そのサンプル群#1を含むファイル配信単位としてのポーションが生成され、FLUTEストリーマ２４、及び、マルチキャストサーバ２５において、マルチキャスト配信される。
【０１５１】
さらに、図１０では、セグメンタ２２において、次のサンプル群#2が生成された時点で、そのサンプル群#2を含むファイル配信単位としてのポーションが生成され、FLUTEストリーマ２４、及び、マルチキャストサーバ２５において、マルチキャスト配信される。
【０１５２】
そして、セグメンタ２２において、フラグメントの最後のサンプル群#3の生成が完了すると、そのサンプル群#3を含むファイル配信単位としてのポーションが生成され、FLUTEストリーマ２４、及び、マルチキャストサーバ２５において、マルチキャスト配信される。
【０１５３】
以上のように、セグメントよりも小さい、フラグメントの一部のサンプル群（図１０では、サンプル群#1，#2，#3）を含むポーションを生成し、そのポーションをマルチキャスト配信することにより、コンテンツを迅速に配信し、クライアントでのコンテンツの受信、及び、バッファリングの開始に生じる遅延を抑制することができる。
【０１５４】
ここで、サンプル群#1ないし#3が、例えば、1GOPのデータであるとすると、サンプル群#1は、例えば、GOPにおいて最初に符号化されるIピクチャのデータに相当する。そして、サンプル群#2は、GOPのIピクチャの後に符号化される1ピクチャ以上のPピクチャやBピクチャのデータに相当し、サンプル群#3は、GOPの残りのPピクチャやBピクチャのデータに相当する。
【０１５５】
＜ポーション＞
【０１５６】
図１１は、セグメントとポーションとの関係の例を示す図である。
【０１５７】
図１１のＡは、セグメントの例を示している。
【０１５８】
図１１のＡにおいて、セグメント５０は、styp５１と、（１個の）フラグメント５２とを有する。
【０１５９】
フラグメント５２は、moof５３とmdat５４とから構成される。
【０１６０】
moof５３には、図７で説明したように、フラグメント５２のシーケンスナンバsqnと、フラグメント５２のmdat５４の先頭のサンプル（図１１のＡでは、サンプル群５６の先頭のサンプル）のプレゼンテーションタイムを表すBaseMediaDecodeTime（以下、bmdtともいう）が格納されている。
【０１６１】
ここで、図１１のＡでは、フラグメント５２のシーケンスナンバsqnとして、1が設定されている。
【０１６２】
mdat５４には、mdatヘッダ５５と、３個のサンプル群５６，５７、及び、５８とが、その順で格納されている。サンプル群５６ないし５８は、例えば、図１０のサンプル群#1ないし#3に、それぞれ相当する。
【０１６３】
mdat５４に格納された３個のサンプル群５６ないし５８のうちの、２番目のサンプル群５７の先頭のサンプルは、最初のサンプル群５６の先頭からn1サンプル目のサンプルになっている。
【０１６４】
また、３個のサンプル群５６ないし５８のうちの、３番目のサンプル群５８の先頭のサンプルは、最初のサンプル群５６の先頭からn2(>n1)サンプル目のサンプルになっている。
【０１６５】
ここで、mdatに格納されたあるサンプルが、そのmdatの先頭のサンプルから何番目のサンプルであるかを、以下、サンプル番号ともいう。
【０１６６】
図１１のＡにおいて、サンプル群５７の先頭のサンプルのサンプル番号は、n1であり、サンプル群５８の先頭のサンプルのサンプル番号は、n2である。
【０１６７】
図１１のＢ、図１１のＣ、及び、図１１のＤは、図１１のＡのセグメント５０が生成される場合の、そのセグメント５０に含まれるフラグメント５２の一部を含むポーションの例を示している。
【０１６８】
すなわち、図１１のＢは、フラグメント５２の一部としてのサンプル群５６を含むポーションの例を示している。また、図１１のＣは、フラグメント５２の他の一部としてのサンプル群５７を含むポーションの例を示しており、図１１のＤは、フラグメント５２のさらに他の一部としてのサンプル群５８を含むポーションの例を示している。
【０１６９】
図１１において、ポーション（のファイル）としては、httpレスポンス（のファイル）が採用されている。
【０１７０】
図１１のＢにおいて、ポーション６０は、フラグメント５２の最初のサンプル群５６を含むhttpレスポンスであり、ポーション６０には、httpヘッダ６１、MS/BR６２、styp５１、moofサブセット６４、MS/BR６５、mdatヘッダ５５、MS/BR６６、サンプル群５６、及び、MS６７が、その順で配置されている。
【０１７１】
httpヘッダ６１は、メッセージボディがマルチパートメッセージボディ(multipart message body)であることを指示するhttpヘッダで、httpヘッダ６１には、シーケンスナンバsqn，バージョンv、及び、NTP時刻ntが含まれる。
【０１７２】
httpヘッダ６１のシーケンスナンバsqnは、ポーション６０に含まれる（フラグメント５２の一部としての）サンプル群５６を含むフラグメント５２のmoof５３に格納されるシーケンスナンバsqnと同一の1に設定される。
【０１７３】
バージョンvは、そのバージョンvを含むポーションに含まれるフラグメントの一部としてのサンプル群の、そのフラグメントにおける順番を表す。バージョンvは、同一のシーケンスナンバsqnについて（sqnスコープで）、例えば、初期値を1として、1ずつインクリメントされる整数である。
【０１７４】
httpヘッダ６１のバージョンvを含むポーション６０に含まれるフラグメント５２の一部は、サンプル群５６であり、そのサンプル群５６の、フラグメント５２における順番は、１番目であるので、httpヘッダ６１のバージョンvには、1が設定される。
【０１７５】
なお、セグメントが、例えば、図９に示したように、複数としての3個のフラグメントを含み、その3個のフラグメントのシーケンスナンバsqnが、それぞれ、1,2,3である場合において、各フラグメントのサンプル群を、例えば、2分割したサンプル群それぞれが含まれる6(=3×2)個のポーションが生成されるときには、その6個のポーションそれぞれのシーケンスナンバsqnとバージョンvとの組(sqn,v)は、それぞれ、(1,1),(1,2),(2,1),(2,2),(3,1),(3,2)となる。
【０１７６】
httpヘッダ６１のNTP時刻ntは、そのNTP時刻ntを含むポーション６０に一部（サンプル群５６）が含まれるフラグメント５２のmoof５３に格納されるbmdt(BaseMediaDecodeTime)、すなわち、フラグメント５２の先頭のサンプル（サンプル群５６の先頭のサンプル）のプレゼンテーションタイムを表すbmdtに対応するNTP時刻NTを表す。
【０１７７】
MS/BR６２は、マルチパートセパレータ(multipart-separater)と、その直後に配置されたstyp５１のバイトレンジ(byte range)を表す。
【０１７８】
MS/BR６３は、マルチパートセパレータと、その直後に配置されたmoofサブセット６４のバイトレンジを表す。
【０１７９】
moofサブセット６４は、フラグメント５２の３個のサンプル群５６ないし５８のうちの、ポーション６０に配置される１番目（最初）のサンプル群５６を生成するまでに生成することができる、moof５３のサブセットであり、moof５３に格納されるシーケンスナンバsqnとbmdtとを含む。
【０１８０】
サンプル群５６を生成するまでに生成することができる、moof５３のサブセットであるmoofサブセット６４によれば、サンプル群５６を再生することができる。
【０１８１】
MS/BR６５は、マルチパートセパレータと、その直後に配置されたmdatヘッダ５５のバイトレンジを表す。
【０１８２】
MS/BR６６は、マルチパートセパレータと、その直後に配置されたサンプル群５６のバイトレンジを表す。
【０１８３】
MS６７は、マルチパートセパレータを表す。
【０１８４】
なお、図１１のＢでは、フラグメント５２の最初のサンプル群５６が含まれるポーション６０に、styp５１を含めることとしたが、styp５１（さらには、図示せぬsidx）は、ポーション６０とは別のhttpレスポンスに含めて配信することができる。
【０１８５】
図１１のＣにおいて、ポーション７０は、フラグメント５２の２番目のサンプル群５７を含むhttpレスポンスであり、ポーション７０には、httpヘッダ７１、MS/BR７２、moofサブセット７３、MS/BR７４、サンプル群５７、及び、MS７５が、その順で配置されている。
【０１８６】
httpヘッダ７１は、メッセージボディがマルチパートメッセージボディであることを指示するhttpヘッダで、httpヘッダ７１には、シーケンスナンバsqn，バージョンv、及び、NTP時刻ntと、サンプルカウントスタートscs(SampleCountStart)とが含まれる。
【０１８７】
httpヘッダ７１のシーケンスナンバsqnは、ポーション７０に含まれる（フラグメント５２の一部としての）サンプル群５７を含むフラグメント５２のmoof５３に格納されるシーケンスナンバsqnと同一の1に設定される。
【０１８８】
httpヘッダ７１のバージョンvには、2が設定される。すなわち、ポーション７０には、フラグメント５２のサンプル群５６ないし５８のうちの２番目のサンプル群５７が含まれるので、httpヘッダ７１のバージョンvには、2が設定される。
【０１８９】
httpヘッダ７１のNTP時刻ntは、そのNTP時刻ntを含むポーション７０に一部（サンプル群５７）が含まれるフラグメント５２のmoof５３に格納されるbmdtに対応するNTP時刻を表し、httpヘッダ６１のNTP時刻nt=NTと同一である。
【０１９０】
サンプルカウントスタートscsは、そのサンプルカウントスタートscsを含むポーションに含まれるサンプル群の先頭のサンプルの、フラグメントの先頭のサンプルからの順番を表す。
【０１９１】
ポーション７０に含まれるサンプル群５７の先頭のサンプルは、図１１のＡで説明したように、最初のサンプル群５６の先頭からn1サンプル目のサンプルであるので、httpヘッダ７１のサンプルカウントスタートscsには、n1が設定される。
【０１９２】
MS/BR７２は、マルチパートセパレータと、その直後に配置されたmoofサブセット７３のバイトレンジを表す。
【０１９３】
moofサブセット７３は、フラグメント５２の３個のサンプル群５６ないし５８のうちの、ポーション７０に配置される２番目のサンプル群５７を生成するまでに生成することができる、moof５３のサブセットであり、moof５３に格納されるシーケンスナンバsqnとbmdtとを含む。
【０１９４】
サンプル群５７を生成するまでに生成することができる、moof５３のサブセットであるmoofサブセット７３では、サンプル群５６を生成するまでに生成されるmoofサブセット６４に、サンプル群５７の再生に必要な情報が追加されており、したがって、moofサブセット７３によれば、サンプル群５７、さらには、サンプル群５７が生成される前に生成されるサンプル群５６を再生することができる。
【０１９５】
MS/BR７４は、マルチパートセパレータと、その直後に配置されたサンプル群５７のバイトレンジを表す。
【０１９６】
MS７５は、マルチパートセパレータを表す。
【０１９７】
図１１のＤにおいて、ポーション８０は、フラグメント５２の３番目のサンプル群５８を含むhttpレスポンスであり、ポーション８０には、httpヘッダ８１、MS/BR８２、moofサブセット８３、MS/BR８４、サンプル群５８、及び、MS８５が、その順で配置されている。
【０１９８】
httpヘッダ８１は、メッセージボディがマルチパートメッセージボディであることを指示するhttpヘッダで、httpヘッダ８１には、シーケンスナンバsqn，バージョンv、及び、NTP時刻ntと、サンプルカウントスタートscsとが含まれる。
【０１９９】
httpヘッダ８１のシーケンスナンバsqnは、ポーション８０に含まれる（フラグメント５２の一部としての）サンプル群５８を含むフラグメント５２のmoof５３に格納されるシーケンスナンバsqnと同一の1に設定される。
【０２００】
httpヘッダ８１のバージョンvには、3が設定される。すなわち、ポーション８０には、フラグメント５２のサンプル群５６ないし５８のうちの３番目のサンプル群５８が含まれるので、httpヘッダ８１のバージョンvには、3が設定される。
【０２０１】
さらに、ポーション８０に含まれるサンプル群５８は、フラグメント５２の最後のサンプル群であるため、すなわち、シーケンスナンバsqnが1になっている最後のサンプル群であるため、httpヘッダ８１のバージョンvには、サンプル群５８の、フラグメント５２における順番である3とともに、フラグメントの最後のサンプル群であることを表す情報としての"-end"が設定される。
【０２０２】
したがって、ポーションを受信する、例えば、クライアント１２では、バージョンvによって、ポーションに含まれる（フラグメントの一部としての）サンプル群の順番と、そのサンプル群が、フラグメントの最後のサンプル群であるかどうかを認識することができる。
【０２０３】
httpヘッダ８１のNTP時刻ntは、そのNTP時刻ntを含むポーション８０に一部（サンプル群５８）が含まれるフラグメント５２のmoof５３に格納されるbmdtに対応するNTP時刻を表し、httpヘッダ６１及び７１のNTP時刻nt=NTと同一である。
【０２０４】
サンプルカウントスタートscsは、上述したように、そのサンプルカウントスタートscsを含むポーションに含まれるサンプル群の先頭のサンプルの、フラグメントの先頭のサンプルからの順番を表す。
【０２０５】
したがって、httpヘッダ８１のサンプルカウントスタートscsには、n2が設定される。すなわち、ポーション８０に含まれるサンプル群５８の先頭のサンプルは、図１１のＡで説明したように、最初のサンプル群５６の先頭からn2サンプル目のサンプルであるので、httpヘッダ８１のサンプルカウントスタートscsには、n2が設定される。
【０２０６】
MS/BR８２は、マルチパートセパレータと、その直後に配置されたmoofサブセット８３のバイトレンジを表す。
【０２０７】
moofサブセット８３は、フラグメント５２の３個のサンプル群５６ないし５８のうちの、ポーション８０に配置される３番目のサンプル群５８を生成するまでに生成することができる、moof５３のサブセットであり、moof５３に格納されるシーケンスナンバsqnとbmdtとを含む。
【０２０８】
ここで、moofサブセット８３は、ポーション８０に配置される３番目のサンプル群５８、すなわち、フラグメント５２の最後のサンプル群５８を生成するまでに生成することができる、moof５３のサブセットであるので、moof５３に等しい。
【０２０９】
以上のように、サンプル群５８を生成するまでに生成することができる、moof５３のサブセットであるmoofサブセット８３は、moof５３に等しいので、moofサブセット８３によれば、サンプル群５８、さらには、サンプル群５８が生成される前に生成されるサンプル群５６及び５７を再生することができる。
【０２１０】
MS/BR８４は、マルチパートセパレータと、その直後に配置されたサンプル群５８のバイトレンジを表す。
【０２１１】
MS８５は、マルチパートセパレータを表す。
【０２１２】
以上のように、httpレスポンスであるポーションは、httpヘッダに、シーケンスナンバsqnと、バージョンvとを含むので、ポーションを受信したクライアント１２（その他の装置）では、シーケンスナンバsqnと、バージョンvとに基づき、ポーションに含まれるサンプル群の、セグメントにおける順番を認識して再生することや、必要に応じて、セグメントを構成して再生することができる。
【０２１３】
また、ポーションには、そのポーションに含まれるサンプル群の再生に必要なmoofの情報であるmoofサブセットが含まれるので、クライアント１２では、セグメントを構成するすべてのポーション（サンプル群）を受信する前に、１個のポーションを受信した時点で、その１個のポーションに含まれるサンプル群が、単独で再生可能なサンプル群（例えば、Iピクチャのサンプル群）である場合や、既に受信しているサンプル群を用いて再生可能なサンプル群である場合には、受信した１個のポーションに含まれるサンプル群の再生を開始することができる。
【０２１４】
なお、バージョンvは、シーケンスナンバsqnとともに、moofサブセットに含めることができる。但し、バージョンvを、シーケンスナンバsqnとともに、moofサブセットに含める場合には、moofに、バージョンvを含めるように、既存のmoofの定義を拡張する必要がある。バージョンvを、httpヘッダに含める場合には、既存のmoofの定義を拡張せずに済む。
【０２１５】
また、図１１では、フラグメント５２の２番目以降のサンプル群５７及び５８をそれぞれ含むポーション７０及び８０のhttpヘッダ７１及び８１には、サンプルカウントスタートscsが含まれ、フラグメント５２の最初のサンプル群５６を含むポーション６０のhttpヘッダ６１には、サンプルカウントスタートscsが含まれていないが、サンプルカウントスタートscsは、フラグメント５２の最初のサンプル群５６を含むポーション６０のhttpヘッダ６１にも含めることができる。
【０２１６】
但し、フラグメントの最初のサンプル群の先頭のサンプルの、そのフラグメントの先頭のサンプルからの順番は、常に1であり、固定値であるため、フラグメントの最初のサンプル群を含むポーションのhttpヘッダ（バージョンvが1のhttpヘッダ）については、図１１のＢに示したように、サンプルカウントスタートscsを省略することができ、これにより、httpヘッダのサイズを小さくすることができる。
【０２１７】
また、httpレスポンスであるポーションでは、httpヘッダに、フラグメントのmoofに格納されるbmdt（フラグメントの先頭のサンプルのプレゼンテーションタイムを表すbmdt）に対応するNTP時刻ntを含めることができるので、クライアント１２では、ポーションを受信した場合に、対応するMPDがなくても、そのポーションに含まれるサンプル群を再生することが可能になる。
【０２１８】
すなわち、コンテンツには、例えば、ライブ放送の番組のような、NTP時刻で表現される絶対時刻の時間軸上で再生のタイミングを制御する必要があるコンテンツがあり、かかるコンテンツのサンプルについては、各サンプルがマッピング（表示）される絶対時刻としてのNTP時刻を計算する必要がある。
【０２１９】
ここで、フラグメントのN番目のサンプルのプレゼンテーションタイム(PresentatioTime(CompositionTime) of Nth Sample)は、次式に従って計算することができる。
【０２２０】
PresentatioTime(CompositionTime) of Nth Sample =
BaseMediaDecodeTime + Sum of SampleDuration of (N-1) Samples + CompositionTimeOffset of Nth Sample
【０２２１】
なお、Sum of SampleDuration of (N-1) Samplesと、CompositionTimeOffset of Nth Sampleとは、フラグメントのmoofに格納される情報(sampleCount，SampleDuration，CompositionTimeOffset)から求めることができ、BaseMediaDecodeTimeは、bmdtとして、moofに格納されている。
【０２２２】
サンプルの絶対時刻は、そのサンプルのプレゼンテーションタイムの計算に用いられるBaseMediaDecodeTimeに対応するNTP時刻が分かれば、求めることができる。
【０２２３】
DASHのMPDには、起点となるBaseMediaDecodeTime(BaseMediaDecodeTime=0)に対応するNTP時刻が記述されるので、MPDの取得が保証されている場合等には、httpヘッダには、フラグメントのmoofに格納されるbmdtに対応するNTP時刻ntを含めなくてもよい。
【０２２４】
但し、httpヘッダに、フラグメントのmoofに格納されるbmdt（フラグメントの先頭のサンプルのプレゼンテーションタイムを表すbmdt）に対応するNTP時刻ntを含めることにより、クライアント１２では、ポーションを受信した場合に、そのポーションのhttpヘッダに含まれるNTP時刻ntに基づいて、対応するMPDがなくても、そのポーションに含まれるサンプル群の各サンプルの絶対時刻としてのNTP時刻を計算し、そのNTP時刻に従って、サンプルを再生することができる。
【０２２５】
また、httpレスポンスであるポーションでは、httpヘッダに、そのポーションに含まれるサンプル群の先頭のサンプルの、フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタートscsを含めることができるので、セグメントを構成する複数のポーション（セグメントに含まれる複数のサンプル群それぞれを含む複数のポーション）のうちの一部のポーションが欠落した場合でも、その欠落したポーションに続くポーション（に含まれるサンプル群）を再生することができる。
【０２２６】
すなわち、セグメントを構成する複数のポーションのすべてを、クライアント１２で受信することが保証されている場合には、サンプルカウントスタートscsがなくても、各ポーションの各サンプルが、フラグメントの先頭のサンプルから何番目のサンプルであるかのサンプル番号を認識することができ、そのサンプル番号に基づいて、moofサブセットから、サンプルの再生に必要な情報を取得し、サンプルを再生することができる。
【０２２７】
但し、セグメントを構成する複数のポーションのうちの一部のポーションが欠落した場合には、その欠落したポーションに続くポーションに含まれるサンプルについては、サンプルカウントスタートscsがないと、サンプル番号を認識することができず、再生が困難になる。
【０２２８】
ポーションのhttpヘッダに、サンプルカウントスタートscsを含めることで、セグメントを構成する複数のポーションのうちの一部のポーションが欠落した場合であっても、その欠落したポーションに続くポーションに含まれるサンプルについては、サンプルカウントスタートscsによって、サンプル番号を認識し、再生を行うことができる。
【０２２９】
また、ポーションには、そのポーションに含まれるサンプル群を生成するまでに生成することができる、moof５３のサブセットであるmoofサブセットが含められるので、ポーションを受信したクライアント１２では、後続のポーションを待たずに、受信したポーションに含まれるサンプル群の再生を、そのポーションに含まれるmoofサブセットに基づいて開始することができる。
【０２３０】
なお、ポーションのhttpヘッダには、その他、例えば、ポーションをマルチキャスト配信するFLUTEで配信される様々な属性情報であるFDT(File Delivery Table)を含めることができる。この場合、クライアント１２では、ポーションのhttpヘッダに含まれるFDTを、FLUTEマルチキャスト配信されるデータの受信の用に供することができる。
【０２３１】
図１２は、図１１のポーション６０としてのhttpレスポンスの記述の例を示す図である。
【０２３２】
記述１００は、httpヘッダ６１であり、そのhttpヘッダ６１の記述１０１における"X-MoofSeqNumVersion"、及び、記述１０２における"X-NTPTimeStamp"は、新規に定義されたヘッダである。
【０２３３】
記述１０１における"X-MoofSeqNumVersion"は、シーケンスナンバsqn、及び、バージョンvを表すヘッダであり、シーケンスナンバを表す変数sqnと、バージョンを表す変数vを有する。変数sqnには、フラグメント５２のシーケンスナンバsqnである1が設定され、変数vには、ポーション６０に含まれるサンプル群５６の、フラグメント５２における順番である1が設定される。
【０２３４】
記述１０２における"X-NTPTimeStamp"は、(BaseMediaDecodeTimeに対応する)NTP時刻ntを表すヘッダであり、図１２では、"X-NTPTimeStamp"に、フラグメント５２の先頭のサンプル（サンプル群５６の先頭のサンプル）のプレゼンテーションタイムを表すbmdtに対応するNTP時刻NTとして、2890844526が設定されている。
【０２３５】
記述１０３は、MS/BR６２であり、記述１０３における"SEPARATER_STRING"は、マルチパートセパレータを表す。また、記述１０３における"Content-range: bytes 492-499/124567654"は、直後のstyp５１のバイトレンジを表す。
【０２３６】
ここで、記述１０３におけるバイトレンジ"Content-range: bytes 492-499/124567654"は、フラグメントのサイズが、124567654バイトで、直後のstyp５１が、その124567654バイトのうちの、492-499バイトであることを表す。
【０２３７】
記述１０３の後には、styp５１のバイト列が続く。
【０２３８】
styp５１のバイト列の後の記述１０４は、MS/BR６３であり、記述１０４における"Content-range: bytes 500-991/124567654"は、直後のmoofサブセット６４のバイトレンジを表す。
【０２３９】
ここで、moofサブセットのバイトレンジについては、フラグメントの最初のサンプル群を含むポーション（図１１では、ポーション６０）の生成時に、フラグメントのmoof（図１１では、moof５３）のバイトレンジが予測され、そのmoofのバイトレンジの予測値が、フラグメントのサンプル群を含む各ポーション（図１１では、ポーション６０，７０、及び、８０）のmoofサブセットのバイトレンジとして採用される。したがって、ポーション６０のmoofサブセット６４、ポーション７０のmoofサブセット７３、及び、ポーション８０のmoofサブセット８３のバイトレンジは、同一の値（moof５３のバイトレンジの予測値）となる。
【０２４０】
記述１０４の後には、moofサブセット６４のバイト列が続く。
【０２４１】
moofサブセット６４のバイト列の後の記述１０５は、MS/BR６５であり、記述１０５における"Content-range: bytes 992-999/124567654"は、直後のmdatヘッダ５５のバイトレンジを表す。
【０２４２】
記述１０５の後には、mdatヘッダ５５のバイト列が続く。
【０２４３】
mdatヘッダ５５のバイト列の後の記述１０６は、MS/BR６６であり、記述１０６における"Content-range: bytes 1000-4999/124567654"は、直後のサンプル群５６のバイトレンジを表す。
【０２４４】
記述１０６の後には、サンプル群５６のバイト列が続く。
【０２４５】
サンプル群５６のバイト列の記述１０７は、MS６７である。
【０２４６】
図１３は、図１１のポーション７０としてのhttpレスポンスの記述の例を示す図である。
【０２４７】
記述１２０は、httpヘッダ７１であり、そのhttpヘッダ７１の記述１２１における"X-MoofSeqNumVersion"、記述１２２における"X-NTPTimeStamp"、及び、記述１２３における"X-SampleCountStart"は、新規に定義されたヘッダである。
【０２４８】
記述１２１における"X-MoofSeqNumVersion"は、図１２で説明したように、シーケンスナンバsqn、及び、バージョンvを表すヘッダである。シーケンスナンバを表す変数sqnには、フラグメント５２のシーケンスナンバsqnである1が設定され、バージョンを表す変数vには、ポーション７０に含まれるサンプル群５７の、フラグメント５２における順番である2が設定される。
【０２４９】
記述１２２における"X-NTPTimeStamp"は、図１２で説明したように、NTP時刻ntを表すヘッダであり、フラグメント５２の先頭のサンプルのプレゼンテーションタイムを表すbmdtに対応するNTP時刻NTとして、図１１の場合と同一の2890844526が設定されている。
【０２５０】
記述１２３における"X-SampleCountStart"は、サンプルカウントスタートscsを表すヘッダであり、図１３では、"X-SampleCountStart"に、フラグメント７０に含まれるサンプル群５７の先頭のサンプルのサンプル番号n1が設定されている。
【０２５１】
記述１２４は、MS/BR７２であり、記述１２４における"Content-range: bytes 500-991/124567654"は、直後のmoofサブセット７３のバイトレンジを表し、図１２の記述１０５におけるmoofサブセット６４のバイトレンジと同一になっている（moof５３のバイトレンジの予測値になっている）。
【０２５２】
記述１２４の後には、moofサブセット７３のバイト列が続く。
【０２５３】
moofサブセット７３のバイト列の後の記述１２５は、MS/BR７４であり、記述１２５における"Content-range: bytes 5000-7999/124567654"は、直後のサンプル群５７のバイトレンジを表す。
【０２５４】
記述１２５の後には、サンプル群５７のバイト列が続く。
【０２５５】
サンプル群５７のバイト列の記述１２６は、MS７５である。
【０２５６】
図１１のポーション８０は、図１３のポーション７０と同様に構成される。
【０２５７】
＜ポーション単位でのコンテンツの配信＞
【０２５８】
図１４は、ポーション単位でのコンテンツの配信の処理の例を説明するフローチャートである。
【０２５９】
ステップＳ１０１において、配信サーバ１１（図２）のセグメンタ２２は、サンプル群を生成しようとしているフラグメント（例えば、図１１のフラグメント５２）を、注目フラグメントとして、注目フラグメントのmdatヘッダ、及び、最初のサンプル群を生成し、処理は、ステップＳ１０２に進む。
【０２６０】
ステップＳ１０２では、セグメンタ２２は、最初のサンプル群用のhttpヘッダ（例えば、図１１のhttpヘッダ６１）を生成し、処理は、ステップＳ１０３に進む。
【０２６１】
すなわち、セグメンタ２２は、注目フラグメントのmoofに格納されるシーケンスナンバと同一のシーケンスナンバsqn、最初のサンプル群の、注目フラグメントにおける順番を表す1であるバージョンv、及び、注目フラグメントのmoofに格納されるbmdtに対応するNTP時刻ntを含むhttpヘッダを、最初のサンプル群用のhttpヘッダとして生成する。
【０２６２】
ステップＳ１０３では、セグメンタ２２は、注目フラグメントについて、最初のサンプル群を生成するまでに生成することができた、最初のサンプル群の再生に必要なmoofの一部を、最初のサンプル群用のmoofサブセットとして取得し、処理は、ステップＳ１０４に進む。
【０２６３】
ステップＳ１０４では、セグメンタ２２は、注目フラグメントを含むセグメントのstyp（及び必要なsidx）、最初のサンプル群用のmoofサブセット、注目フラグメントのmdatヘッダ、及び、最初のサンプル群に、最初のサンプル群用のhttpヘッダを付加することで、ポーションとしてのhttpレスポンスを生成し、FLUTEストリーマ２４に供給して、処理は、ステップＳ１０５に進む。
【０２６４】
ここで、注目フラグメントを含むセグメントが、複数のフラグメントを含み、注目フラグメントが、その複数のフラグメントの最初のフラグメントでない場合には、ステップＳ１０４で生成されるポーションとしてのhttpレスポンスには、styp（及び必要なsidx）は、含まれない。
【０２６５】
ステップＳ１０５では、FLUTEストリーマ２４が、セグメンタ２２からのポーションとしてのhttpレスポンスを、LCTパケットにパケット化し、マルチキャストサーバ２５が、そのLCTパケットをマルチキャスト配信して、処理は、ステップＳ１０６に進む。
【０２６６】
ステップＳ１０６では、セグメンタ２２は、注目フラグメントについて、次のサンプル群を、注目サンプル群として生成し、処理は、ステップＳ１０７に進む。
【０２６７】
ステップＳ１０７では、セグメンタ２２は、注目サンプル群用のhttpヘッダ（例えば、図１１のhttpヘッダ７１や８１）を生成し、処理は、ステップＳ１０８に進む。
【０２６８】
すなわち、セグメンタ２２は、注目フラグメントのmoofに格納されるシーケンスナンバと同一のシーケンスナンバsqn、注目サンプル群の、注目フラグメントにおける順番を表すバージョンv、注目フラグメントのmoofに格納されるbmdtに対応するNTP時刻nt、及び、注目サンプル群の先頭のサンプルのサンプル番号を表すサンプルカウントスタートscsを含むhttpヘッダを、注目サンプル群用のhttpヘッダとして生成する。
【０２６９】
ステップＳ１０８では、セグメンタ２２は、注目フラグメントについて、注目サンプル群を生成するまでに生成することができた、注目サンプル群、（及び、注目フラグメントの注目サンプル群を生成する前に生成されたサンプル群）の再生に必要なmoofの一部を、注目サンプル群用のmoofサブセットとして取得し、処理は、ステップＳ１０９に進む。
【０２７０】
ステップＳ１０９では、セグメンタ２２は、注目サンプル群用のmoofサブセット、及び、注目サンプル群に、注目サンプル群用のhttpヘッダを付加することで、ポーションとしてのhttpレスポンスを生成し、FLUTEストリーマ２４に供給して、処理は、ステップＳ１１０に進む。
【０２７１】
ステップＳ１１０では、ステップＳ１０５と同様に、FLUTEストリーマ２４が、セグメンタ２２からのポーションとしてのhttpレスポンスを、LCTパケットにパケット化し、マルチキャストサーバ２５が、そのLCTパケットをマルチキャスト配信して、処理は、ステップＳ１１１に進む。
【０２７２】
ステップＳ１１１では、セグメンタ２２は、注目サンプル群が、注目フラグメントの最後のサンプル群であるかどうかを判定する。
【０２７３】
ステップＳ１１１において、注目サンプル群が、注目フラグメントの最後のサンプル群でないと判定された場合、すなわち、注目フラグメントにおいて、注目サンプル群の次のサンプル群がある場合、処理は、ステップＳ１０６に戻り、注目サンプル群の次のサンプル群を、新たな注目サンプル群として、同様の処理が繰り返される。
【０２７４】
また、ステップＳ１１１において、注目サンプル群が、注目フラグメントの最後のサンプル群であると判定された場合、処理は、ステップＳ１０１に戻り、例えば、注目フラグメントの次のフラグメントを、新たな注目フラグメントとして、以下、同様の処理が繰り返される。
【０２７５】
＜ポーション単位でのコンテンツの受信＞
【０２７６】
図１５は、ポーション単位でのコンテンツの受信の処理の例を説明するフローチャートである。
【０２７７】
ステップＳ１２１において、クライアント１２（図３）の受信部３１は、ポーションとしてのhttpレスポンスがマルチキャスト配信されているのを待って、そのポーションとしてのhttpレスポンスを受信し、処理は、ステップＳ１２２に進む。
【０２７８】
ステップＳ１２２では、再生部３３が、受信部３１で受信されたポーションとしてのhttpレスポンスに含まれるサンプル群の再生を、そのhttpレスポンスに含まれるmoofサブセット、並びに、httpレスポンスのhttpヘッダに含まれるシーケンスナンバsqn、バージョンv、NTP時刻nt、及び、サンプルカウントスタートscsを必要に応じて用いて行う。
【０２７９】
そして、処理は、ステップＳ１２２からＳ１２１に戻り、以下、同様の処理が繰り返される。
【０２８０】
以上のように、配信サーバ１１では、セグメントが生成されるのを待つことなく、そのセグメントに含まれるフラグメントの一部であるサンプル群が生成された時点で、そのサンプル群を含むポーションとしてのhttpレスポンスを配信するので、コンテンツを迅速に配信することができる。
【０２８１】
その結果、クライアント１２でのコンテンツの受信、及び、バッファリングの開始に遅延が生じることを抑制することができる。
【０２８２】
＜LCTパケット＞
【０２８３】
図１６は、LCTパケットによるポーション（及びセグメント）のマルチキャスト配信を説明する図である。
【０２８４】
FLUTEストリーマ２４では、ポーション（及びセグメント）が、LCTパケットにパケット化され、マルチキャストサーバ２５において、そのLCTパケットがマルチキャスト配信される。
【０２８５】
FLUTEストリーマ２４での、ポーションの、LCTパケットへのパケット化は、例えば、図１６に示すように、ポーションを、所定のサイズの小片に分割し、各小片を、LCTパケットに格納することで行われる。
【０２８６】
図１７は、LCTパケットのフォーマットを示す図である。
【０２８７】
LCTパケットは、LCTヘッダ(LCT Header)、FEC Payload ID、及び、Encoding Symbol(s)が、その順で配置されて構成される。
【０２８８】
ポーションの小片は、Encoding Symbolとして、LCTパケットに格納される。
【０２８９】
図１８は、LCTヘッダのフォーマットを示す図である。
【０２９０】
LCTヘッダには、TSI(Transport Session Identifier)，TOI(Transport Object Identifier)、及び、必要な拡張ヘッダ(Header Extensions)が含まれる。
【０２９１】
TSIは、LCTパケットのセッションを識別する識別子である。例えば、本来、１個のセグメント５０（図１１）で配信されるべきサンプル群５６，５７、及び、５８を含むポーション６０，７０、及び、８０それぞれをパケット化したLCTパケットのTSIは、同一の値に設定される。
【０２９２】
TOIは、LCTパケットのEncoding Symbolにデータが格納されるオブジェクトを識別する識別子である。例えば、ポーション６０を分割した小片がEncoding Symbolに格納されるLCTパケットのTOIは、同一の値に設定される。
【０２９３】
但し、例えば、ポーション６０を分割した小片がEncoding Symbolに格納されるLCTパケットと、ポーション７０を分割した小片がEncoding Symbolに格納されるLCTパケットとでは、Encoding Symbolにデータ（小片）が格納されるオブジェクトが、ポーション６０と７０とで異なるので、ポーション６０を分割した小片がEncoding Symbolに格納されるLCTパケットと、ポーション７０を分割した小片がEncoding Symbolに格納されるLCTパケットとでは、TOIは異なる。
【０２９４】
クライアント１２では、TOIが同一のLCTパケットを受信することで、そのLCTパケットに格納されたポーションの小片を集めて、元のポーションを再構成することができる。
【０２９５】
図１９は、ポーション単位でのコンテンツの配信の例を示す図である。
【０２９６】
図１９では、あるフラグメントが、サンプル群#1，#2，#3，・・・を有している。
【０２９７】
そして、サンプル群#1は、例えば、他のビューを参照しないベースビュー（ベースレイヤのビュー）のビデオになっており、サンプル群#2，#3，・・・は、例えば、ベースビュー等の他のビューを参照することがあるノンベースビュー（エンハンスレイヤのビュー）のビデオになっている。
【０２９８】
ポーション単位でのコンテンツの配信では、配信サーバ１１において、サンプル群#iを含むポーション#iが生成される（i=1,2,3・・・）。そして、ポーション#iは、小片に分割され、ポーション#iの小片は、LCTパケット#iに格納されて配信される。
【０２９９】
あるポーション#iの小片が格納されたLCTパケット#iのTOIは、同一の値になっているので、クライアント１２では、LCTパケットを受信し、その受信したLCTパケットのうちの、TOIが同一のLCTパケットに格納されたポーション#iの小片を集めることで、元のポーション#iを再構成することができる。
【０３００】
ここで、上述したように、図１９において、ポーション#1に含まれるサンプル群#1は、ベースビューのビデオになっており、サンプル群#2，#3，・・・は、ノンベースビューのビデオになっている。
【０３０１】
以上のように、ポーションに含まれるサンプル群が、ベースビューのビデオや、ノンベースビューのビデオのような、何らかの基準で分類することができるデータ（処理単位）である場合には、ポーション（に含まれるサンプル群）単位で、LCTパケットを取捨選択するパケットフィルタリングを行うことができる。
【０３０２】
すなわち、例えば、LCTパケットが配信されるネットワーク環境の変動等により、LCTパケットの配信に、十分なリソース（LCTパケットを最終的に受信するクライアント１２のリソースを含む）を割り当てることが困難な場合には、LCTパケットの配信経路上のルータ（例えば、FLUTEマルチキャストのルータ）や、クライアント１２のネットワークスタック（LCTパケットを処理するブロック）において、必要最小限、あるいは、処理の優先度が高いLCTパケットだけを選択して処理（転送やスタック等の処理）を行うことができる。
【０３０３】
特に、ネットワーク環境の変動が激しい、例えば、携帯網を用いるコンテンツの配信では、上述のような、必要最小限のLCTパケットや、処理の優先度が高いLCTパケットだけを選択して処理するパケットフィルタリングの技術の要請は、高い。
【０３０４】
ポーション単位で、LCTパケットを取捨選択するパケットフィルタリングを行う方法としては、ポーションとしてのhttpヘッダに、ポーションに含まれるサンプル群が、例えば、ベースビューのビデオであることや、ノンベースビューのビデオであること等を表す、サンプル群の属性情報（例えば、FDT等）を含めておき、そのサンプル群の属性情報に基づいて、そのサンプル群を含むポーション（の小片）が格納されたLCTパケットを取捨選択する方法がある。
【０３０５】
しかしながら、ポーションとしてのhttpヘッダに、そのポーションに含まれるサンプル群の属性情報を含めておくのでは、パケットフィルタリングを行うたびに、サンプル群の属性情報を認識するために、LCTパケットから、元のポーションを再構成しなければならず、パケットフィルタリングを、効率的に行うことが困難となる。
【０３０６】
そこで、配信サーバ１１では、FLUTEストリーマ２４において、LCTパケットの処理の優先度を表す優先度パラメータを含むLCTヘッダを有するLCTパケットを生成し、マルチキャストサーバ２５において、そのような優先度パラメータを含むLCTヘッダを有するLCTパケットをマルチキャスト配信することで、効率的なパケットフィルタリングを可能とし、これにより、必要なLCTパケットを迅速に配信することや処理することを可能にする。
【０３０７】
＜優先度パラメータ＞
【０３０８】
本技術では、LCTヘッダの拡張ヘッダを、優先度パラメータを格納することができるように拡張することで、LCTヘッダに、優先度パラメータを含める。
【０３０９】
図２０は、図１８のLCTヘッダの拡張ヘッダ(Header Extentions)のフォーマットを示す図である。
【０３１０】
拡張ヘッダの先頭の8ビットには、拡張ヘッダの種類（拡張ヘッダにHECとして格納される実データの種類）を表すHET(Header Extension Type)が格納される。
【０３１１】
8ビットのHETが、127以下のとき、HETに続き、8ビットのHEL(Header Extension Length)が格納される。HELには、拡張ヘッダの長さ32×Nビットを表す値Nが設定される。
【０３１２】
そして、HELに続き、32×N-8-8ビットの可変長(variable length)のHEC(Header Extension Content)が格納される。HECは、拡張ヘッダの実データである。
【０３１３】
一方、8ビットのHETが、128以上のとき、HETに続き、32-8ビットのHECが格納される。
【０３１４】
HETについては、既に、幾つかの値が規定されているが、本実施の形態では、HETに、まだ規定されてない値を採用することで、優先度パラメータを格納する新たな拡張ヘッダを定義する。
【０３１５】
図２１は、優先度パラメータを格納する新たな拡張ヘッダの定義の例を示す図である。
【０３１６】
新たな拡張ヘッダは、8ビットのHET、8ビットのHEL、8ビットのFiltering SchemeURI、8ビットのFiltering Parameter Length、及び、8×FPLNビットのFiltering Parameterが、その順で配置されて構成される。
【０３１７】
新たな拡張ヘッダのHETには、拡張ヘッダに、優先度パラメータが格納されていることを表す値としての、例えば、120が設定される。この場合、HETが127以下なので、図２０に示したように、HETの後には、HETが配置される。
【０３１８】
HELには、0ないし255の範囲の整数値HELNが設定される。整数値HELNとしては、32×HELNが拡張ヘッダの長さとなる値が採用される。
【０３１９】
Filtering Scheme URIは、Filtering Parameterを定義するスキーム識別子(SchemeURI)である。
【０３２０】
Filtering Parameter Lengthには、0ないし255の範囲の整数値FPLNが設定される。整数値FPLNとしては、32×FPLNが、Filtering Parameterの長さとなる値が採用される。
【０３２１】
Filtering Parameterは、優先度パラメータであり、その定義（構造）は、Filtering Scheme URIによって特定される。
【０３２２】
図２２は、優先度パラメータ(Filtering Parameter)の定義の例を示す図である。
【０３２３】
例えば、Filtering Scheme URI=1000が、図２２の定義を表す。
【０３２４】
図２２では、優先度パラメータ(Filtering Parameter)は、64ビットであり、8ビットのTrack Reference Index、8ビットのPriority、8ビットのDependency Counter、8ビットのMVC Filter Length、及び、32ビットのMVC Filterが、その順で配置されて構成される。
【０３２５】
Track Reference Indexには、0ないし255の範囲の整数値のうちの、LCTパケットに格納されているフラグメントの一部としてのサンプル群（LCTパケットに小片が格納されているポーションに含まれるサンプル群）が属するトラック（MP4ファイルのトラック）を識別する値が設定される。
【０３２６】
優先度パラメータとしてのTrack Reference Indexによれば、例えば、所定のトラックの属するサンプル群を含むポーションの小片が格納されたLCTパケットを優先的に選択して処理するパケットフィルタリングを行うことができる。
【０３２７】
Priorityは、TOIが同一のLCTパケットごとに設定される。Priorityには、各値のTOIのLCTパケットの処理の優先度を表すインデクスが設定される。
【０３２８】
Priorityに設定されるインデクスは、LCTパケットの処理の優先度をランク付けする、0ないし255の範囲の整数値であり、例えば、値が大きいほど、優先度が低い。
【０３２９】
優先度パラメータとしてのPriorityによれば、例えば、所定の値以下のPriorityが設定されたTOIのLCTパケットを優先的に選択して処理するパケットフィルタリングを行うことができる。
【０３３０】
Dependency Counterには、そのDependency Counterを含むLCTパケットが影響する後続のLCTパケットの数Kが設定される。Dependency Counter=Kの場合、そのDependency Counter=KのLCTパケットの後続のK個のLCTパケットの処理が、Dependency Counter=KのLCTパケットの処理に依存する。
【０３３１】
優先度パラメータとしてのDependency Counterによれば、例えば、Dependency Counterが1以上のLCTパケット、すなわち、後続の１個以上のLCTパケットに影響するLCTパケットを優先的に選択して処理するパケットフィルタリングを行うことができる。
【０３３２】
MVC Filter Lengthは、Boolean値をとり、Trueのときに、後続のMVC Filterが存在することを表す。
【０３３３】
MVC Filterは、LCTパケットに小片が格納されたポーションに含まれるサンプル群が、MVC(Multiview Video Coding)のデータである場合に、そのMVCのデータを取捨選択するフィルタリングを行うための情報である。
【０３３４】
MVC Filterとしては、例えば、RTPパケットに格納されるMVCのNAL(Network Abstraction Layer)ユニットのヘッダとして定義されているPRID(priority_id)，TID(tempral_id)、及び、VID(View_id)の１以上を採用することができる。
【０３３５】
図２３は、MVC Filterの定義の例を示す図である。
【０３３６】
32ビットのMVC Filterは、6ビットのpriority_id(PRID)、3ビットのtemporal_id(TID)、10ビットのview_id(VID)、及び、13ビットのReservedが、その順に配置されて構成される。
【０３３７】
PRID，TID， VID、及び、Reservedは、以下のように定義される。
【０３３８】
PRID: 6 bits
priority_id.  This flag specifies a priority identifier for the NAL unit.  A lower value of PRID indicates a higher priority.
TID: 3 bits
temporal_id.  This component specifies the temporal layer (or frame rate) hierarchy.  Informally put, a temporal layer consisting of view component with a less temporal_id corresponds to a lower frame rate.
A given temporal layer typically depends on the lower temporal layers(i.e. the temporal layers with less temporal_id values) but never depends on any higher temporal layer (i.e. a temporal layers with higher temporal_id value).
VID: 10 bits
view_id.  This component specifies the view identifier of the view the NAL unit belongs to.
Reserved: 13bits
(将来拡張のための予約bit)
【０３３９】
PIDは、NALユニット（LCTパケットに小片が格納されたポーションに含まれるサンプル群が、NALユニットである場合の、そのNALユニット）の優先度を表す。PIDが小さいほど、NALユニットの優先度は高い。
【０３４０】
TIDは、ビデオ（LCTパケットに小片が格納されたポーションに含まれるサンプル群が、ビデオ（のデータ）である場合の、そのビデオ）の時間的なレイヤ（又はフレームレート）を表す。TIDが小さいレイヤほど、フレームレートは低い。あるレイヤは、そのレイヤよりもTIDが小さい下位レイヤに依存することはあるが、TIDが大きい上位レイヤに依存することはない。
【０３４１】
VIDは、NALユニットが属するビューを表す。
【０３４２】
Reservedは、将来のための予約ビットである。
【０３４３】
以上のようなMVC Filterによれば、例えば、LCTパケットがビデオとしてのNALユニット（の一部）を含む場合に、PIDに基づき、優先度が高いNALユニットを含むLCTパケットを優先的に選択して処理するパケットフィルタリングを行うことができる。
【０３４４】
また、例えば、TIDに基づき、時間的なレイヤが所定のレイヤ以下のビデオ（のNALユニット）、すなわち、時間解像度としてのフレームレートが所定値以下のビデオを含むLCTパケットを優先的に選択して処理するパケットフィルタリングを行うことができる。
【０３４５】
さらに、例えば、VIDに基づき、所定のビューのビデオ（のNALユニット）を含むLCTパケットを優先的に選択して処理するパケットフィルタリングを行うことができる。
【０３４６】
その他、優先度パラメータとしては、様々な情報を採用することができる。
【０３４７】
すなわち、例えば、LCTパケットが、動画、及び、静止画のうちのいずれかのビデオを含む場合には、そのビデオが、動画、又は、静止画であることを表す情報を、優先度パラメータとして採用することができる。この場合、動画、又は、静止画のビデオを含むLCTパケットを優先的に選択して処理するパケットフィルタリングを行うことができる。
【０３４８】
また、例えば、LCTパケットが、他のレイヤを参照しないベースレイヤ、及び、他のレイヤを参照することがある１以上のノンベースレイヤのうちのいずれかのレイヤのビデオを含む場合には、ビデオのレイヤを表す情報を、優先度パラメータとして採用することができる。この場合、例えば、ベースレイヤのビデオを含むLCTパケットを優先的に選択して処理するパケットフィルタリングを行うことができる。
【０３４９】
さらに、例えば、LCTパケットが、複数のビューのうちのいずれかのビューのビデオを含む場合には、ビデオのビューを表す情報を、優先度パラメータとして採用することができる。この場合、例えば、ユーザが所望するビューのビデオ（例えば、野球中継において、１塁側、３塁側、及び、バックネット側等の複数の位置から撮影された複数のビューのビデオのうちの、バックネット側から撮影したビューのビデオ）を含むLCTパケットを優先的に選択して処理するパケットフィルタリングを行うことができる。
【０３５０】
また、例えば、LCTパケットが、複数の解像度のうちのいずれかの解像度のビデオを含む場合には、解像度を表す情報を、優先度パラメータとして採用することができる。この場合、例えば、所定の解像度（以下）のビデオを含むLCTパケットを優先的に選択して処理するパケットフィルタリングを行うことができる。優先度パラメータとしての解像度を表す情報としては、時間解像度、及び、空間解像度の一方、又は、両方の情報を採用することができる。
【０３５１】
なお、パケットフィルタリングは、１種類の優先度パラメータに基づいて行う他、複数種類の優先度パラメータに基づいて行うことができる。
【０３５２】
すなわち、例えば、パケットフィルタリングでは、優先度パラメータとしての、例えば、ビデオのビューを表す情報と、解像度を表す情報とに基づき、所定のビューのビデオであって、かつ、所定の解像度のビデオを含むLCTパケットを優先的に選択して処理することができる。
【０３５３】
＜優先度パラメータを有するLCTパケットの配信の処理＞
【０３５４】
図２４は、優先度パラメータを有するLCTパケットの配信の処理の例を説明するフローチャートである。
【０３５５】
ステップＳ２０１において、配信サーバ１１のFLUTEストリーマ２４（図２）は、LCTパケットのエンコーディングシンボル(Encoding Symbol)（図１７）に格納するデータ（セグメンタ２２から供給されるポーションの小片）や、配信サーバ１１のオペレータの操作等に基づき、優先度パラメータを設定し、処理は、ステップＳ２０２に進む。
【０３５６】
ステップＳ２０２では、FLUTEストリーマ２４は、ステップＳ２０１で設定した優先度パラメータを含む拡張ヘッダ（図２１）（図２２）を生成し、処理は、ステップＳ２０３に進む。
【０３５７】
ステップＳ２０３では、FLUTEストリーマ２４は、ステップＳ２０２で生成した拡張ヘッダを含むLCTヘッダ（図１８）を有し、セグメンタ２２から供給されるポーションの小片を、エンコーディングシンボルに配置したLCTパケット（図１７）を生成し、マルチキャストサーバ２５に供給して、処理は、ステップＳ２０４に進む。
【０３５８】
ステップＳ２０４では、マルチキャストサーバ２５が、FLUTEストリーマ２４からのLCTパケットをマルチキャスト配信して、処理は、ステップＳ２０１に戻り、以下、同様の処理が繰り返される。
【０３５９】
＜パケットフィルタリングの処理＞
【０３６０】
図２５は、クライアント１２（その他、マルチキャスト配信されるLCTパケットを受信するルータ等の装置）が行うパケットフィルタリングの処理の例を説明するフローチャートである。
【０３６１】
ステップＳ２１１において、クライアント１２の受信部３０（図３）は、ネットワーク環境や装置（クライアント１２）のリソース、ユーザの操作、ユーザの嗜好等に基づいて、LCTパケットを処理するときの閾値とする優先度（以下、閾値優先度ともいう）を設定し、処理は、ステップＳ２１２に進む。
【０３６２】
ステップＳ２１２では、受信部３０は、LCTパケットがマルチキャスト配信されてくるのを待って、そのLCTパケットを受信し、処理は、ステップＳ２１３に進む。
【０３６３】
ステップＳ２１３では、受信部３０は、ステップＳ２１２で受信したLCTパケットのLCTヘッダに含まれる優先度パラメータと、ステップＳ２１１で設定した閾値優先度とに基づき、LCTパケットの処理の可否を判定する可否判定を行って、処理は、ステップＳ２１４に進む。
【０３６４】
ステップＳ２１４では、受信部３０は、ステップＳ２１３での可否判定の判定結果に従い、LCTパケットを取捨選択して、閾値優先度より優先度が低い優先度パラメータを有するLCTパケットについては処理を中止し、閾値優先度以上の優先度の優先度パラメータを有するLCTパケットについては処理を続行する。そして、処理は、ステップＳ２１４からステップＳ２１１に戻り、以下、同様の処理が繰り返される。
【０３６５】
＜本技術を適用したコンピュータの説明＞
【０３６６】
次に、上述した一連の処理は、ハードウェアにより行うこともできるし、ソフトウェアにより行うこともできる。一連の処理をソフトウェアによって行う場合には、そのソフトウェアを構成するプログラムが、汎用のコンピュータ等にインストールされる。
【０３６７】
そこで、図２６は、上述した一連の処理を実行するプログラムがインストールされるコンピュータの一実施の形態の構成例を示している。
【０３６８】
プログラムは、コンピュータに内蔵されている記録媒体としてのハードディスク３０５やROM３０３に予め記録しておくことができる。
【０３６９】
あるいはまた、プログラムは、リムーバブル記録媒体３１１に格納（記録）しておくことができる。このようなリムーバブル記録媒体３１１は、いわゆるパッケージソフトウエアとして提供することができる。ここで、リムーバブル記録媒体３１１としては、例えば、フレキシブルディスク、CD-ROM(Compact Disc Read Only Memory)，MO(Magneto Optical)ディスク，DVD(Digital Versatile Disc)、磁気ディスク、半導体メモリ等がある。
【０３７０】
なお、プログラムは、上述したようなリムーバブル記録媒体３１１からコンピュータにインストールする他、通信網や放送網を介して、コンピュータにダウンロードし、内蔵するハードディスク３０５にインストールすることができる。すなわち、プログラムは、例えば、ダウンロードサイトから、ディジタル衛星放送用の人工衛星を介して、コンピュータに無線で転送したり、LAN(Local Area Network)、インターネットといったネットワークを介して、コンピュータに有線で転送することができる。
【０３７１】
コンピュータは、CPU(Central Processing Unit)３０２を内蔵しており、CPU３０２には、バス３０１を介して、入出力インタフェース３１０が接続されている。
【０３７２】
CPU３０２は、入出力インタフェース３１０を介して、ユーザによって、入力部３０７が操作等されることにより指令が入力されると、それに従って、ROM(Read Only Memory)３０３に格納されているプログラムを実行する。あるいは、CPU３０２は、ハードディスク３０５に格納されたプログラムを、RAM(Random Access Memory)３０４にロードして実行する。
【０３７３】
これにより、CPU３０２は、上述したフローチャートにしたがった処理、あるいは上述したブロック図の構成により行われる処理を行う。そして、CPU３０２は、その処理結果を、必要に応じて、例えば、入出力インタフェース３１０を介して、出力部３０６から出力、あるいは、通信部３０８から送信、さらには、ハードディスク３０５に記録等させる。
【０３７４】
なお、入力部３０７は、キーボードや、マウス、マイク等で構成される。また、出力部３０６は、LCD(Liquid Crystal Display)やスピーカ等で構成される。
【０３７５】
ここで、本明細書において、コンピュータがプログラムに従って行う処理は、必ずしもフローチャートとして記載された順序に沿って時系列に行われる必要はない。すなわち、コンピュータがプログラムに従って行う処理は、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含む。
【０３７６】
また、プログラムは、１のコンピュータ（プロセッサ）により処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。
【０３７７】
さらに、本明細書において、システムとは、複数の構成要素（装置、モジュール（部品）等）の集合を意味し、すべての構成要素が同一筐体中にあるか否かは問わない。したがって、別個の筐体に収納され、ネットワークを介して接続されている複数の装置、及び、１つの筐体の中に複数のモジュールが収納されている１つの装置は、いずれも、システムである。
【０３７８】
なお、本技術の実施の形態は、上述した実施の形態に限定されるものではなく、本技術の要旨を逸脱しない範囲において種々の変更が可能である。
【０３７９】
例えば、本技術は、１つの機能をネットワークを介して複数の装置で分担、共同して処理するクラウドコンピューティングの構成をとることができる。
【０３８０】
また、上述のフローチャートで説明した各ステップは、１つの装置で実行する他、複数の装置で分担して実行することができる。
【０３８１】
さらに、１つのステップに複数の処理が含まれる場合には、その１つのステップに含まれる複数の処理は、１つの装置で実行する他、複数の装置で分担して実行することができる。
【０３８２】
また、セグメンタ２２において、ポーションを生成する対象のフラグメントとしては、fragmentedMP4(ISO/IEC14496-14)のフラグメントの他、任意のデータフォーマットのフラグメント（データの一部）を採用することができる。
【０３８３】
すなわち、ポーションを生成する対象のフラグメントとしては、例えば、ISO base media file format(ISO/IEC 14496-12)や、ISO/IEC 14496-15で規定されているフォーマット、QuickTime形式、その他の、いわゆるボックス構造を有するデータフォーマットのフラグメント、さらには、ボックス構造を有しないデータフォーマット（例えば、TS(Transport Stream)等）のデータを断片化したフラグメントを採用することができる。
【０３８４】
さらに、ポーションを生成する対象のフラグメントとしては、例えば、MPEGのTS(Transport Stream)や、webM、その他の任意の動画フォーマットのフラグメントを採用することができる。
【０３８５】
また、本技術は、コンテンツ以外の任意のデータの配信に適用することができる。
【０３８６】
ここで、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。
【０３８７】
なお、本技術は、以下のような構成をとることができる。
【０３８８】
＜１＞
フラグメントの一部と、
前記フラグメントの順番を表すシーケンスナンバと、
前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと
を含むhttp(Hypertext Transfer Protocol)ヘッダと
を含むhttpレスポンスを配信する配信部を備える
送信装置。
＜２＞
前記フラグメントの最後の一部を含む前記httpレスポンスの前記バージョンは、前記フラグメントの最後を表す情報を含む
＜１＞に記載の送信装置。
＜３＞
前記フラグメントは、moof(movie fragment)とmdat(media data)とを有し、
前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、
前記httpヘッダは、前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻をさらに含む
＜１＞又は＜２＞に記載の送信装置。
＜４＞
前記httpヘッダは、前記httpレスポンスに含まれる前記フラグメントの一部の先頭の前記サンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報を、さらに含む
＜３＞に記載の送信装置。
＜５＞
前記フラグメントの2番目以降の一部を含む前記httpレスポンスの前記httpヘッダが、前記サンプルカウントスタート情報を含む
＜４＞に記載の送信装置。
＜６＞
前記フラグメントは、fragmentedMP4のフラグメントである
＜１＞ないし＜５＞のいずれかに記載の送信装置。
＜７＞
フラグメントの一部と、
前記フラグメントの順番を表すシーケンスナンバと、
前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと
を含むhttp(Hypertext Transfer Protocol)ヘッダと
を含むhttpレスポンスを配信する
ステップを含む送信方法。
＜８＞
フラグメントの一部と、
前記フラグメントの順番を表すシーケンスナンバと、
前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと
を含むhttp(Hypertext Transfer Protocol)ヘッダと
を含むhttpレスポンスを受信する受信部を備える
受信装置。
＜９＞
前記フラグメントの最後の一部を含む前記httpレスポンスの前記バージョンは、前記フラグメントの最後を表す情報を含む
＜８＞に記載の受信装置。
＜１０＞
前記フラグメントは、moof(movie fragment)とmdat(media data)とを有し、
前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、
前記httpヘッダは、前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻をさらに含む
＜８＞又は＜９＞に記載の受信装置。
＜１１＞
前記httpヘッダは、前記httpレスポンスに含まれる前記フラグメントの一部の先頭の前記サンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報を、さらに含む
＜１０＞に記載の受信装置。
＜１２＞
前記フラグメントの2番目以降の一部を含む前記httpレスポンスの前記httpヘッダが、前記サンプルカウントスタート情報を含む
＜１１＞に記載の受信装置。
＜１３＞
前記フラグメントは、fragmentedMP4のフラグメントである
＜８＞ないし＜１２＞のいずれかに記載の受信装置。
＜１４＞
フラグメントの一部と、
前記フラグメントの順番を表すシーケンスナンバと、
前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと
を含むhttp(Hypertext Transfer Protocol)ヘッダと
を含むhttpレスポンスを受信する
ステップを含む受信方法。
【符号の説明】
【０３８９】
１０  ネットワーク，  １１  配信サーバ，  １２  クライアント，  １３  NTPサーバ，  ２１  チャンネルストリーマ，  ２２  セグメンタ，  ２３  メタデータジェネレータ，  ２４  FLUTEストリーマ，  ２５  マルチキャストサーバ，  ２６  webサーバ，  ３０  受信部，  ３１  ミドルウェア，  ３２  DASHクライアント，  ３３  再生部，  ３０１  バス，  ３０２  CPU，  ３０３  ROM，  ３０４  RAM，  ３０５  ハードディスク，  ３０６  出力部，  ３０７  入力部，  ３０８  通信部，  ３０９  ドライブ，  ３１０  入出力インタフェース，  ３１１  リムーバブル記録媒体
【図１】
2015064383.tif 000003
【図２】
2015064383.tif 000004
【図３】
2015064383.tif 000005
【図４】
2015064383.tif 000006
【図５】
2015064383.tif 000007
【図６】
2015064383.tif 000008
【図７】
2015064383.tif 000009
【図８】
2015064383.tif 000010
【図９】
2015064383.tif 000011
【図１０】
2015064383.tif 000012
【図１１】
2015064383.tif 000013
【図１２】
2015064383.tif 000014
【図１３】
2015064383.tif 000015
【図１４】
2015064383.tif 000016
【図１５】
2015064383.tif 000017
【図１６】
2015064383.tif 000018
【図１７】
2015064383.tif 000019
【図１８】
2015064383.tif 000020
【図１９】
2015064383.tif 000021
【図２０】
2015064383.tif 000022
【図２１】
2015064383.tif 000023
【図２２】
2015064383.tif 000024
【図２３】
2015064383.tif 000025
【図２４】
2015064383.tif 000026
【図２５】
2015064383.tif 000027
【図２６】
2015064383.tif 000028
【国際調査報告】
2015064383.tif 000029
2015064383.tif 000030
2015064383.tif 000031
2015064383.tif 000032