JP2015192407A - 送信装置、送信方法、受信装置、受信方法、及び、プログラム - Google Patents

送信装置、送信方法、受信装置、受信方法、及び、プログラム Download PDF

Info

Publication number
JP2015192407A
JP2015192407A JP2014069940A JP2014069940A JP2015192407A JP 2015192407 A JP2015192407 A JP 2015192407A JP 2014069940 A JP2014069940 A JP 2014069940A JP 2014069940 A JP2014069940 A JP 2014069940A JP 2015192407 A JP2015192407 A JP 2015192407A
Authority
JP
Japan
Prior art keywords
fragment
sample
moof
header
lct
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2014069940A
Other languages
English (en)
Inventor
山岸　靖明
Yasuaki Yamagishi
靖明 山岸
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP2014069940A priority Critical patent/JP2015192407A/ja
Priority to MX2016012218A priority patent/MX362219B/es
Priority to KR1020167025213A priority patent/KR102137858B1/ko
Priority to CN201580015015.8A priority patent/CN106105239B/zh
Priority to US15/127,462 priority patent/US10432989B2/en
Priority to EP15770090.7A priority patent/EP3125563A4/en
Priority to PCT/JP2015/057533 priority patent/WO2015146647A1/ja
Priority to CA2941367A priority patent/CA2941367A1/en
Publication of JP2015192407A publication Critical patent/JP2015192407A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23605—Creation or processing of packetized elementary streams [PES]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2353—Processing of additional data, e.g. scrambling of additional data or processing content descriptors specifically adapted to content descriptors, e.g. coding, compressing or processing of metadata
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2362—Generation or processing of Service Information [SI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/242—Synchronization processes, e.g. processing of PCR [Program Clock References]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4305—Synchronising client clock from received content stream, e.g. locking decoder clock with encoder clock, extraction of the PCR packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Library & Information Science (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

【課題】データを迅速に配信する。【解決手段】フラグメントの一部を含むデータであるポーションと、LCTヘッダとを含むLCTパケットが配信される。フラグメントは、moofと、mdatヘッダ及びサンプル群を有するmdatとを有し、moofは、mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、LCTヘッダは、フラグメントの順番を表すシーケンスナンバと、フラグメントの一部の、フラグメントにおける順番を表すバージョンと、BaseMediaDecodeTimeに対応するNTP時刻と、フラグメントの一部の先頭のサンプルの、フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報と、moofの少なくとも一部であるmoofサブセットとを含む。本技術は、例えば、コンテンツをマルチキャスト配信する場合等に適用することができる。【選択図】図２７

Description

本技術は、送信装置、送信方法、受信装置、受信方法、及び、プログラムに関し、特に、例えば、データを迅速に配信すること等ができるようにする送信装置、送信方法、受信装置、受信方法、及び、プログラムに関する。
近年、インターネット上のストリーミングサービスの主流が、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では、コンテンツをマルチキャスト配信（ブロードキャスト配信を含む）する場合に、セグメントが生成されるまで、コンテンツの配信を待つ必要がある。
今後は、より高画質の動画配信が一般的になることが予想されるが、そのような高画質の動画配信では、コンテンツのストリームのビットレートが大になる。
コンテンツのストリームのビットレートが大である場合に、セグメントの生成が完了するのを待って、セグメントの単位で、コンテンツの配信、すなわち、バルク転送を行うのでは、ネットワークの帯域が圧迫され、シェーピングが必要になることがある。
したがって、セグメントの生成が完了するのを待って、セグメントの単位で、コンテンツを配信するのでは、最終的には、クライアントでのコンテンツの受信、及び、バッファリングの開始に遅延が生じる。そのため、コンテンツを迅速に配信する技術の提案が要請されている。
本技術は、このような状況に鑑みてなされたものであり、コンテンツ等のデータを迅速に配信することができるようにするものである。
本技術の送信装置、又は、第１のプログラムは、フラグメントの一部を含むデータであるポーションと、LCT(Layerd Coding Transport)ヘッダとを含むLCTパケットを配信する配信部を備え、前記フラグメントは、moof(movie fragment)と、mdat(media data)ヘッダ及び1個以上のサンプル群を有するmdatとを有し、前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、前記LCTヘッダは、前記フラグメントの順番を表すシーケンスナンバと、前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと、前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻と、前記フラグメントの一部の先頭のサンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報と、前記moofの少なくとも一部であるmoofサブセットとを含む送信装置、又は、そのような送信装置として、コンピュータを機能させるためのプログラムである。
本技術の送信方法は、フラグメントの一部を含むデータであるポーションと、LCT(Layerd Coding Transport)ヘッダとを含むLCTパケットを配信するステップを含み、前記フラグメントは、moof(movie fragment)と、mdat(media data)ヘッダ及びサンプル群を有するmdatとを有し、前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、前記LCTヘッダは、前記フラグメントの順番を表すシーケンスナンバと、前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと、前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻と、前記フラグメントの一部の先頭のサンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報と、前記moofの少なくとも一部であるmoofサブセットとを含む送信方法である。
以上のような送信装置、送信方法、及び、第１のプログラムにおいては、フラグメントの一部を含むデータであるポーションと、LCT(Layerd Coding Transport)ヘッダとを含むLCTパケットが配信される。前記フラグメントは、moof(movie fragment)と、mdat(media data)ヘッダ及びサンプル群を有するmdatとを有し、前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、前記LCTヘッダは、前記フラグメントの順番を表すシーケンスナンバと、前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと、前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻と、前記フラグメントの一部の先頭のサンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報と、前記moofの少なくとも一部であるmoofサブセットとを含んでいる。
本技術の受信装置、又は、第２のプログラムは、フラグメントの一部を含むデータであるポーションと、LCT(Layerd Coding Transport)ヘッダとを含むLCTパケットを受信する受信部を備え、前記フラグメントは、moof(movie fragment)と、mdat(media data)ヘッダ及びサンプル群を有するmdatとを有し、前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、前記LCTヘッダは、前記フラグメントの順番を表すシーケンスナンバと、前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと、前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻と、前記フラグメントの一部の先頭のサンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報と、前記moofの少なくとも一部であるmoofサブセットとを含む受信装置、又は、そのような受信装置として、コンピュータを機能させるためのプログラムである。
本技術の受信方法は、フラグメントの一部を含むデータであるポーションと、LCT(Layerd Coding Transport)ヘッダとを含むLCTパケットを受信するステップを備え、前記フラグメントは、moof(movie fragment)と、mdat(media data)ヘッダ及びサンプル群を有するmdatとを有し、前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、前記LCTヘッダは、前記フラグメントの順番を表すシーケンスナンバと、前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと、前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻と、前記フラグメントの一部の先頭のサンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報と、前記moofの少なくとも一部であるmoofサブセットとを含む受信方法である。
以上のような受信装置、受信方法、及び、第２のプログラムにおいては、フラグメントの一部を含むデータであるポーションと、LCT(Layerd Coding Transport)ヘッダとを含むLCTパケットが受信される。前記フラグメントは、moof(movie fragment)と、mdat(media data)ヘッダ及びサンプル群を有するmdatとを有し、前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、前記LCTヘッダは、前記フラグメントの順番を表すシーケンスナンバと、前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと、前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻と、前記フラグメントの一部の先頭のサンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報と、前記moofの少なくとも一部であるmoofサブセットとを含んでいる。
なお、送信装置、及び、受信装置は、独立した装置であっても良いし、１つの装置を構成している内部ブロックであっても良い。
本技術によれば、データを迅速に配信すること等ができる。
なお、ここに記載された効果は必ずしも限定されるものではなく、本開示中に記載されたいずれかの効果であってもよい。
本技術を適用したコンテンツ提供システムの一実施の形態の構成例を示すブロック図である。 配信サーバ１１の構成例を示すブロック図である。 クライアント１２の構成例を示すブロック図である。 コンテンツ提供システムによるコンテンツの提供の処理の例を説明する図である。 コンテンツ提供システムにおいて、ネットワーク１０を介して配信されるデータの例を示す図である。 MPD，SDP，USD、及び、OMA-ESGを説明する図である。 DASHのファイル配信単位であるセグメントの構成を説明する図である。 １個のフラグメントを有するセグメントと、複数のフラグメントを有するセグメントとの構成例を示す図である。 DASHでの、セグメントをファイル配信単位とするコンテンツの配信の例を示す図である。 配信サーバ１１での、ポーションをファイル配信単位とするコンテンツの配信の概要を説明する図である。 セグメントとポーションとの関係の例を示す図である。 ポーション６０としてのhttpレスポンスの例を示す図である。 ポーション７０としてのhttpレスポンスの例を示す図である。 ポーション単位でのコンテンツの配信の処理の例を説明するフローチャートである。 ポーション単位でのコンテンツの受信の処理の例を説明するフローチャートである。 LCTパケットによるポーション（及びセグメント）のマルチキャスト配信を説明する図である。 LCTパケットのフォーマットを示す図である。 LCTヘッダのフォーマットを示す図である。 ポーション単位でのコンテンツの配信の例を示す図である。 LCTヘッダの拡張ヘッダ(Header Extentions)のフォーマットを示す図である。 優先度パラメータを格納する新たな拡張ヘッダの定義の例を示す図である。 優先度パラメータ(Filtering Parameter)の定義の例を示す図である。 MVC Filterの定義の例を示す図である。 優先度パラメータを有するLCTパケットの配信の処理の例を説明するフローチャートである。 クライアント１２が行うパケットフィルタリングの処理の例を説明するフローチャートである。 デコード関係情報を格納するLCTヘッダの新たな拡張ヘッダの定義の例を示す図である。 拡張ヘッダにデコード関係情報が格納されるLCTパケットの第１の例を示す図である。 第１の例のLCTパケットを用いて、ポーション単位でのコンテンツの配信を行う場合の、その配信の処理の例を説明するフローチャートである。 第１の例のLCTパケットを用い、ポーション単位で配信されてくるコンテンツの受信の処理の例を説明するフローチャートである。 拡張ヘッダにデコード関係情報が格納されるLCTパケットの第２の例を示す図である。 第２の例の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'や'msix'が設定される。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での、セグメントをファイル配信単位とするコンテンツの配信の例を示す図である。
図９では、複数である、例えば、3個のサンプル群#1，#2、及び、#3が、フラグメントを構成するサンプル群として、順次生成されている。そして、配信サーバ１１（図２）のセグメンタ２２において、フラグメントの最後のサンプル群#3の生成の完了後に、それらのサンプル群#1ないし#3を配置したmdatと、サンプル群#1ないし#3のmoofとを含むフラグメントが生成され、そのフラグメントを含むセグメントが生成されており、その後、FLUTEストリーマ２４、及び、マルチキャストサーバ２５において、そのセグメントが配信される。
ここで、サンプル群#1，#2、及び、#3は、それぞれ、1以上のサンプルで構成される。また、サンプル群#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６７が、その順で配置されている。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７５が、その順で配置されている。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８５が、その順で配置されている。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の部分）を、最初のサンプル群用の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パケットへのパケット化は、例えば、図１６に示すように、ポーションを、所定のサイズの1個以上の小片に分割し、各小片を、LCTパケットに格納することで行われる。
図１７は、LCTパケットのフォーマットを示す図である。
LCTパケットは、LCTヘッダ(LCT Header)、FECペイロードID(FEC Payload ID)、及び、エンコーディングシンボル(Encoding Symbol(s))が、その順で配置されて構成される。
ポーション（の小片）は、エンコーディングシンボルとして、LCTパケットに格納される。
図１８は、LCTヘッダのフォーマットを示す図である。
LCTヘッダには、TSI(Transport Session Identifier)，TOI(Transport Object Identifier)、及び、必要な拡張ヘッダ(Header Extensions)が含まれる。
TSIは、LCTパケットのセッションを識別する識別子である。例えば、本来、１個のセグメント５０（図１１）で配信されるべきサンプル群５６，５７、及び、５８を含むポーション６０，７０、及び、８０それぞれをパケット化したLCTパケットのTSIは、同一の値に設定される。
TOIは、LCTパケットのエンコーディングシンボルにデータが格納されるオブジェクトを識別する識別子である。例えば、ポーション６０を分割した小片がエンコーディングシンボルに格納されるLCTパケットのTOIは、同一の値に設定される。
但し、例えば、ポーション６０を分割した小片がエンコーディングシンボルに格納されるLCTパケットと、ポーション７０を分割した小片がエンコーディングシンボルに格納される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ヘッダに、優先度パラメータを含める。
図２０は、図１８の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の後には、HELが配置される。
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パケットのエンコーディングシンボル（図１７）に格納するデータ（セグメンタ２２から供給されるポーションの小片）や、配信サーバ１１のオペレータの操作等に基づき、優先度パラメータを設定し、処理は、ステップＳ２０２に進む。
ステップＳ２０２では、FLUTEストリーマ２４は、ステップＳ２０１で設定した優先度パラメータを含む拡張ヘッダ（図２１）（図２２）を生成し、処理は、ステップＳ２０３に進む。
ステップＳ２０３では、FLUTEストリーマ２４は、ステップＳ２０２で生成した拡張ヘッダを含むLCTヘッダ（図１８）を有し、セグメンタ２２から供給されるポーションの小片を、エンコーディングシンボルに配置したLCTパケット（図１７）を生成し、マルチキャストサーバ２５に供給して、処理は、ステップＳ２０４に進む。
ステップＳ２０４では、マルチキャストサーバ２５が、FLUTEストリーマ２４からのLCTパケットをマルチキャスト配信して、処理は、ステップＳ２０１に戻り、以下、同様の処理が繰り返される。
＜パケットフィルタリングの処理＞
図２５は、クライアント１２（その他、マルチキャスト配信されるLCTパケットを受信するルータ等の装置）が行うパケットフィルタリングの処理の例を説明するフローチャートである。
ステップＳ２１１において、クライアント１２の受信部３０（図３）は、ネットワーク環境や装置（クライアント１２）のリソース、ユーザの操作、ユーザの嗜好等に基づいて、LCTパケットを処理するときの閾値とする優先度（以下、閾値優先度ともいう）を設定し、処理は、ステップＳ２１２に進む。
ステップＳ２１２では、受信部３０は、LCTパケットがマルチキャスト配信されてくるのを待って、そのLCTパケットを受信し、処理は、ステップＳ２１３に進む。
ステップＳ２１３では、受信部３０は、ステップＳ２１２で受信したLCTパケットのLCTヘッダに含まれる優先度パラメータと、ステップＳ２１１で設定した閾値優先度とに基づき、LCTパケットの処理の可否を判定する可否判定を行って、処理は、ステップＳ２１４に進む。
ステップＳ２１４では、受信部３０は、ステップＳ２１３での可否判定の判定結果に従い、LCTパケットを取捨選択して、閾値優先度より優先度が低い優先度パラメータを有するLCTパケットについては処理を中止し、閾値優先度以上の優先度の優先度パラメータを有するLCTパケットについては処理を続行する。そして、処理は、ステップＳ２１４からステップＳ２１１に戻り、以下、同様の処理が繰り返される。
＜デコード関係情報＞
図２６は、デコード関係情報を格納するLCTヘッダの新たな拡張ヘッダの定義の例を示す図である。
ここで、LCTパケットのエンコーディングシンボルに格納されたポーションとしてのhttpレスポンスに含まれるサンプル群のデコード（レンダリング（表示）を含む）にあたっては、まず最初に、moofに含まれるdecoding time（デコード時刻）及びcomposition time（表示時刻）や、httpヘッダに含まれるシーケンスナンバsqn、バージョンv、NTP時刻nt、及び、サンプルカウントスタートscs等の情報が必要となる。
なお、上述のようなサンプル群のデコードに必要な、例えば、decoding timeや、composition time、シーケンスナンバsqn、バージョンv、NTP時刻nt、及び、サンプルカウントスタートscs等の情報を、デコード関係情報ともいう。
デコード関係情報は、例えば、上述の優先度パラメータと同様に、LCTパケットのパケットフィルタリングに用いることができる。
また、デコード関係情報は、例えば、LCTパケットのエンコーディングシンボルに格納されたポーションとしてのhttpレスポンスに含まれるサンプル群を処理する処理順の決定等の、サンプル群のデコードのいわば前処理に用いることができる。
ところで、上述の場合には、decoding time及びcomposition timeを含むmoofサブセットや、シーケンスナンバsqn、バージョンv、NTP時刻nt、及び、サンプルカウントスタートscs等のデコード関係情報は、LCTパケットのエンコーディングシンボルに格納されたポーションとしてのhttpレスポンスに含まれる。
したがって、デコード関係情報を用いて、LCTパケットのパケットフィルタリングや、デコードの前処理を行うためには、LCTパケットを解析し、そのLCTパケットのエンコーディングシンボルに格納されたポーションとしてのhttpレスポンスから、デコード関係情報を抽出する必要がある。
しかしながら、デコード関係情報の抽出に、LCTパケットを解析するのでは、時間を要することになり、効率的なパケットフィルタリングや、必要なLCTパケットの迅速な処理の妨げとなる。
そこで、配信サーバ１１では、FLUTEストリーマ２４において、デコード関係情報を含むLCTヘッダを有するLCTパケットを生成し、マルチキャストサーバ２５において、そのようなデコード関係情報を含むLCTヘッダを有するLCTパケットをマルチキャスト配信することで、効率的なパケットフィルタリングや、必要なLCTパケットの迅速な処理を可能にする。
本技術では、デコード関係情報を含むLCTヘッダを有するLCTパケットを生成するため、上述の優先度パラメータを含むLCTヘッダを有するLCTパケットを生成する場合と同様に、HETに、まだ規定されてない値を採用することで、デコード関係情報を格納する新たな拡張ヘッダを定義する。
すなわち、デコード関係情報を格納する新たな拡張ヘッダは、例えば、図２６に示すように、8ビットのHET、8ビットのHEL、64ビットのNTPTimeStamp、16ビットのMoofSequenceNumber、16ビットのMoofVersion、16ビットのSampleCountStart、8ビットのPartial moof Length、及び、8×FPLNビットのPartial Moofが、その順で配置されて構成される。
新たな拡張ヘッダのHETには、拡張ヘッダに、デコード関係情報が格納されていることを表す値としての、例えば、101が設定される。この場合、HETが127以下なので、図２０に示したように、HETの後には、HELが配置される。
HELには、0ないし255の範囲の整数値HELNが設定される。整数値HELNとしては、32×HELNが拡張ヘッダの長さとなる値が採用される。
NTPTimeStamp，MoofSequenceNumber，MoofVersion、及び、SampleCountStartには、LCTパケットに格納されるポーションとしてのhttpレスポンスのhttpヘッダに格納されたNTP時刻nt、シーケンスナンバsqn、バージョンv、及び、サンプルカウントスタートscsが、それぞれ設定される。
Partial moof Lengthには、0ないし255の範囲の整数値PMLNが設定される。整数値PMLNとしては、32×PMLNが、Partial moofの長さとなる値が採用される。
Partial moofには、LCTパケットに格納されるポーションとしてのhttpレスポンスのメッセージボディに格納された（バイナリの）moofサブセットが設定される。
ここで、以下では、説明を簡単にするため、LCTパケットのエンコーディングシンボルには、ポーションが分割されずに格納されることとする。
なお、LCTパケットのエンコーディングシンボルに、ポーションが複数の小片に分割されて格納される場合には、1個のポーションから分割された小片が格納される各LCTパケットの拡張ヘッダには、例えば、同一のデコード関係情報が格納される。
＜拡張ヘッダにデコード関係情報が格納されるLCTパケットの第１の例＞
図２７は、拡張ヘッダにデコード関係情報が格納されるLCTパケットの第１の例を示す図である。
図２７では、図１１の場合と同様に、1個のフラグメントから、3個のポーションとしてのhttpレスポンス４００，４２０、及び、４４０が生成されている。
さらに、図２７では、httpレスポンス４００，４２０、及び、４４０から、そのhttpレスポンス４００，４２０、及び、４４０それぞれがエンコーディングシンボルに格納されたLCTパケットが生成されている。
1個のフラグメントから生成された3個のポーションのうちの1番目のポーションとしてのhttpレスポンス４００は、図１１Ｂの1番目（最初）のサンプル群５６を含むポーション６０としてのhttpレスポンスと同様に構成される。
すなわち、httpレスポンス４００は、httpヘッダ４０１とメッセージボディ４０２とを有する。
httpヘッダ４０１は、図１１Ｂのポーション６０としてのhttpレスポンスのhttpヘッダ６１と同様に、シーケンスナンバsqn，バージョンv、及び、NTP時刻ntを有する。
メッセージボディ４０２は、図１１Ｂのポーション６０としてのhttpレスポンスのメッセージボディ（図１１Ｂのhttpヘッダ６１の後の部分）と同様に、MS/BR，styp，moofサブセット，MS/BR，mdatヘッダ，MS/BR、1番目のサンプル群５６に相当するサンプル群#1、及び、MSが、その順で配置されて構成される。
FLUTEストリーマ２４（図２）は、セグメンタ２２から供給されるポーションとしてのhttpレスポンス４００を参照することにより、httpヘッダ４０１に含まれるシーケンスナンバsqn，バージョンv、及び、NTP時刻ntと、メッセージボディ４０２に含まれるmoofサブセットとを認識し、LCTヘッダ４１１の拡張ヘッダ(Header Extentions)に格納する。
さらに、FLUTEストリーマ２４は、エンコーディングシンボル(Encoding Symbol(s))４１２に、ポーションとしてのhttpレスポンス４００を格納し、LCTヘッダ４１１に、エンコーディングシンボル４１２を付加することで、LCTパケット４１０を生成する。
1個のフラグメントから生成された3個のポーションのうちの2番目のポーションとしてのhttpレスポンス４２０は、図１１Ｃの2番目のサンプル群５７を含むポーション７０としてのhttpレスポンスと同様に構成される。
すなわち、httpレスポンス４２０は、httpヘッダ４２１とメッセージボディ４２２とを有する。
httpヘッダ４２１は、図１１Ｃのポーション７０としてのhttpレスポンスのhttpヘッダ７１と同様に、シーケンスナンバsqn，バージョンv、NTP時刻nt、及び、サンプルカウントスタートscsを有する。
メッセージボディ４２２は、図１１Ｃのポーション７０としてのhttpレスポンスのメッセージボディ（図１１Ｃのhttpヘッダ７１の後の部分）と同様に、MS/BR，moofサブセット，MS/BR、2番目のサンプル群５７に相当するサンプル群#2、及び、MSが、その順で配置されて構成される。
FLUTEストリーマ２４（図２）は、セグメンタ２２から供給されるポーションとしてのhttpレスポンス４２０を参照することにより、httpヘッダ４２１に含まれるシーケンスナンバsqn，バージョンv、NTP時刻nt、及び、サンプルカウントスタートscsと、メッセージボディ４２２に含まれるmoofサブセットとを認識し、LCTヘッダ４３１の拡張ヘッダに格納する。
さらに、FLUTEストリーマ２４は、エンコーディングシンボル４３２に、ポーションとしてのhttpレスポンス４２０を格納し、LCTヘッダ４３１に、エンコーディングシンボル４３２を付加することで、LCTパケット４３０を生成する。
1個のフラグメントから生成された3個のポーションのうちの3番目のポーションとしてのhttpレスポンス４４０は、図１１Ｄの3番目（最後）のサンプル群５８を含むポーション８０としてのhttpレスポンスと同様に構成される。
すなわち、httpレスポンス４４０は、httpヘッダ４４１とメッセージボディ４４２とを有する。
httpヘッダ４４１は、図１１Ｄのポーション８０としてのhttpレスポンスのhttpヘッダ８１と同様に、シーケンスナンバsqn，バージョンv、NTP時刻nt、及び、サンプルカウントスタートscsを有する。
メッセージボディ４４２は、図１１Ｄのポーション８０としてのhttpレスポンスのメッセージボディ（図１１Ｄのhttpヘッダ８１の後の部分）と同様に、MS/BR，moofサブセット，MS/BR、3番目のサンプル群５８に相当するサンプル群#3、及び、MSが、その順で配置されて構成される。
ここで、メッセージボディ４４２に含まれるmoofサブセットは、そのメッセージボディ４４２に含まれる3番目のサンプル群#3、すなわち、3個のポーションとしてのhttpレスポンス４００，４２０、及び、４４０が生成された元の1個のフラグメントにおける最後のサンプル群#3を生成するまでに生成することができるmoofのサブセットであるので、元のフラグメントに含まれるサンプル群#1ないし#3の全体のmoofに等しい。
FLUTEストリーマ２４（図２）は、セグメンタ２２から供給されるポーションとしてのhttpレスポンス４４０を参照することにより、httpヘッダ４４１に含まれるシーケンスナンバsqn，バージョンv、NTP時刻nt、及び、サンプルカウントスタートscsと、メッセージボディ４４２に含まれるmoofサブセットとを認識し、LCTヘッダ４５１の拡張ヘッダに格納する。
さらに、FLUTEストリーマ２４は、エンコーディングシンボル４５２に、ポーションとしてのhttpレスポンス４４０を格納し、LCTヘッダ４５１に、エンコーディングシンボル４５２を付加することで、LCTパケット４５０を生成する。
以上のような、デコード関係情報であるmoofサブセット、シーケンスナンバsqn、バージョンv、NTP時刻nt、及び、サンプルカウントスタートscsをLCTヘッダに有するLCTパケットによれば、やはり、ポーション単位でのコンテンツの配信が行われるので、コンテンツを迅速に配信することができる。
さらに、LCTヘッダ（の拡張ヘッダ）には、デコード関係情報であるmoofサブセット、シーケンスナンバsqn、バージョンv、NTP時刻nt、及び、サンプルカウントスタートscsがまとめて格納されるため、サンプル群のデコードに必要な時間（時刻）の計算を、LCTヘッダにまとめて格納されたデコード関係情報を用いて、効率的に行うことができる。
また、デコード関係情報であるmoofサブセット、シーケンスナンバsqn、バージョンv、NTP時刻nt、及び、サンプルカウントスタートscsは、LCTヘッダのバイナリの拡張ヘッダの、あらかじめ決められた位置に配置（格納）（設定）されるため、そのバイナリの拡張ヘッダを参照することにより、シーケンスナンバsqnや、バージョンv、moofサブセットに含まれるbmdt(BaseMediaDecodeTime)等に基づき、LCTパケット（のエンコーディングシンボルに格納されたポーション）を取捨選択するパケットフィルタリングを効率的に行い、必要なLCTパケットを、優先的かつ迅速に処理することが可能となる。
図２８は、図２７の第１の例のLCTパケットを用いて、ポーション単位でのコンテンツの配信を行う場合の、その配信の処理の例を説明するフローチャートである。
ステップＳ４０１ないしＳ４０４において、配信サーバ１１では、図１４のステップＳ１０１ないしＳ１０４とそれぞれ同様の処理が行われ、これにより、セグメンタ２２（図２）は、注目フラグメントの最初のサンプル群を含むポーションとしてのhttpレスポンスを生成し、FLUTEストリーマ２４に供給して、処理は、ステップＳ４０５に進む。
ステップＳ４０５では、FLUTEストリーマ２４は、セグメンタ２２からのポーションとしてのhttpレスポンスから、デコード関連情報（moofサブセット、シーケンスナンバsqn、バージョンv、及び、NTP時刻nt）を認識し、そのデコード関連情報を格納したLCTヘッダを生成する。
さらに、ステップＳ４０５では、FLUTEストリーマ２４は、デコード関連情報を格納したLCTヘッダに、セグメンタ２２からのポーションとしてのhttpレスポンスを、エンコーディングシンボルとして付加することで、LCTパケットを生成し、マルチキャストサーバ２５に供給して、処理は、ステップＳ４０６に進む。
ステップＳ４０６では、マルチキャストサーバ２５は、FLUTEストリーマ２４からのLCTパケットをマルチキャスト配信して、処理は、ステップＳ４０７に進む。
ステップＳ４０７ないしＳ４１０では、配信サーバ１１では、図１４のステップＳ１０６ないしＳ１０９とそれぞれ同様の処理が行われ、これにより、セグメンタ２２は、注目フラグメントの次のサンプル群を注目サンプル群として、その注目サンプル群を含むポーションとしてのhttpレスポンスを生成し、FLUTEストリーマ２４に供給して、処理は、ステップＳ４１１に進む。
ステップＳ４１１では、FLUTEストリーマ２４は、セグメンタ２２からのポーションとしてのhttpレスポンスから、デコード関連情報（moofサブセット、シーケンスナンバsqn、バージョンv、NTP時刻nt、及び、サンプルカウントスタートscs）を認識し、そのデコード関連情報を格納したLCTヘッダを生成する。
さらに、ステップＳ４１１では、FLUTEストリーマ２４は、デコード関連情報を格納したLCTヘッダに、セグメンタ２２からのポーションとしてのhttpレスポンスを、エンコーディングシンボルとして付加することで、LCTパケットを生成し、マルチキャストサーバ２５に供給して、処理は、ステップＳ４１２に進む。
ステップＳ４１２では、マルチキャストサーバ２５は、FLUTEストリーマ２４からのLCTパケットをマルチキャスト配信して、処理は、ステップＳ４１３に進む。
ステップＳ４１３では、セグメンタ２２は、注目サンプル群が、注目フラグメントの最後のサンプル群であるかどうかを判定する。
ステップＳ４１３において、注目サンプル群が、注目フラグメントの最後のサンプル群でないと判定された場合、すなわち、注目フラグメントにおいて、注目サンプル群の次のサンプル群がある場合、処理は、ステップＳ４０７に戻り、注目サンプル群の次のサンプル群を、新たな注目サンプル群として、同様の処理が繰り返される。
また、ステップＳ４１３において、注目サンプル群が、注目フラグメントの最後のサンプル群であると判定された場合、処理は、ステップＳ４０１に戻り、例えば、注目フラグメントの次のフラグメントを、新たな注目フラグメントとして、以下、同様の処理が繰り返される。
図２９は、図２７の第１の例のLCTパケットを用い、ポーション単位で配信されてくるコンテンツの受信の処理の例を説明するフローチャートである。
ステップＳ４３１において、クライアント１２の受信部３０（図３）は、LCTパケットがマルチキャスト配信されてくるのを待って、そのLCTパケットを受信し、処理は、ステップＳ４３２に進む。
ステップＳ４３２では、受信部３０は、ステップＳ４３１で受信したLCTパケットのLCTヘッダに含まれるデコード関係情報（moofサブセット（に含まれるbmdt等）や、シーケンスナンバsqn、バージョンv、NTP時刻nt、サンプルカウントスタートscs）等に基づいて、そのLCTパケットを取捨選択するパケットフィルタリングを行い、処理は、ステップＳ４３３に進む。
ステップＳ４３３では、受信部３０は、パケットフィルタリングの結果残ったLCTパケットのLCTヘッダに含まれるデコード関係情報を必要に応じて用い、そのLCTパケットに格納されたサンプル群のデコード等の処理を行う。そして、処理は、ステップＳ４３３からステップＳ４３１に戻り、以下、同様の処理が繰り返される。
＜拡張ヘッダにデコード関係情報が格納されるLCTパケットの第２の例＞
図３０は、拡張ヘッダにデコード関係情報が格納されるLCTパケットの第２の例を示す図である。
なお、図中、図２７の場合と対応する部分については、同一の符号を付してあり、以下では、その説明は、適宜省略する。
図３０では、FLUTEストリーマ２４は、LCTパケット４１０として、エンコーディングシンボルに、httpレスポンス４００ではなく、そのhttpレスポンス４００に含まれるサンプル群#1だけが格納されたLCTパケットを生成する。
同様に、FLUTEストリーマ２４は、LCTパケット４３０として、エンコーディングシンボルに、httpレスポンス４２０ではなく、そのhttpレスポンス４２０に含まれるサンプル群#2だけが格納されたLCTパケットを生成する。さらに、同様に、FLUTEストリーマ２４は、LCTパケット４５０として、エンコーディングシンボルに、httpレスポンス４４０ではなく、そのhttpレスポンス４４０に含まれるサンプル群#3だけが格納されたLCTパケットを生成する。
したがって、第２の例のLCTパケットでは、httpヘッダやmoofサブセット等が、エンコーディングシンボルに格納されていないため、第１の例のLCTパケットに比較して、転送や、受信、スタックの処理のオーバーヘッドを減らすことができる。
なお、図３０では、説明を分かりやすくするために、httpメッセージをポーションとして、そのポーションとしてのhttpメッセージと比較したLCTパケットを図示したが、図３０の第２の例のLCTパケットは、フラグメントに含まれる（一部の）サンプル群や、moof及びmdatヘッダ等を、そのまま、ポーションとして用いて生成することができる。
すなわち、1個のセグメントが、例えば、図１１Ａに示したように、styp（と必要なsidx）、及び、1個のフラグメントから構成され、その1個のフラグメントが、moof，mdatヘッダ、及び、3個のサンプル群#1ないし#3を有することとする。
この場合、セグメンタ２２（図２）は、1個のフラグメントの一部としてのサンプル群#1ないし#3を、それぞれ、ポーションとして、FLUTEストリーマ２４に供給し、FLUTEストリーマ２２は、セグメンタ２２からのポーションとしてのサンプル群#1ないし#3それぞれを、エンコーディングシンボル４１２，４３２、及び、４５２に格納したLCTパケット４１０，４３０、及び、４５０をそれぞれ生成する。
さらに、セグメンタ２２は、1個のフラグメントに含めるべきサンプル群#1ないし#3すべてが生成され、そのサンプル群#1ないし#3のmoofが生成されると、1個のフラグメントについて、最後に、その1個のフラグメントの一部としてのmdatヘッダ及びmoof、並びに、その1個のフラグメントが含まれるセグメントが有するstyp（と必要なsidx）を、ポーションとして、FLUTEストリーマ２４に供給する。
FLUTEストリーマ２２は、セグメンタ２２からのポーションとしてのmdatヘッダ、moof、及び、styp（と必要なsidx）をエンコーディングシンボル４６２に格納したLCTパケット４６０を生成する。
なお、サンプル群#1ないし#3のmoofは、LCTパケット４６０のエンコーディングシンボル４６２の他、LCTパケット４６０のLCTヘッダ４６１（の拡張ヘッダにおけるPartial moof（図２６））にも格納することができる。
また、サンプル群#1ないし#3のmoofは、エンコーディングシンボル４６２に代えて、LCTヘッダ４６１にだけ格納することができる。
図３１は、図３０の第２の例のLCTパケットを用いて、ポーション単位でのコンテンツの配信を行う場合の、その配信の処理の例を説明するフローチャートである。
ステップＳ４５１において、配信サーバ１１（図２）のセグメンタ２２は、サンプル群を生成しようとしているフラグメント（例えば、図１１のフラグメント５２）を、注目フラグメントとして、注目フラグメントのmdatヘッダを生成し、ポーション（の一部）として、FLUTEストリーマ２４に供給する。
さらに、ステップＳ４５１では、セグメンタ２２は、注目フラグメントの最初のサンプル群を生成し、ポーションとして、FLUTEストリーマ２４に供給して、処理は、ステップＳ４５２に進む。
ステップＳ４５２では、セグメンタ２２は、ポーションとしての最初のサンプル群についてのデコード関係情報、すなわち、注目フラグメントのmoofに格納されるシーケンスナンバと同一のシーケンスナンバsqn、最初のサンプル群の、注目フラグメントにおける順番を表す1であるバージョンv、及び、注目フラグメントのmoofに格納されるbmdtに対応するNTP時刻ntを生成し、FLUTEストリーマ２４に供給する。
さらに、ステップＳ４５２では、セグメンタ２２は、注目フラグメントについて、最初のサンプル群を生成するまでに生成することができた、最初のサンプル群の再生に必要なmoofの一部を、最初のサンプル群用のmoofサブセットとして取得し、FLUTEストリーマ２４に供給して、処理は、ステップＳ４５３に進む。
ステップＳ４５３では、FLUTEストリーマ２４は、セグメンタ２２からのデコード関連情報、すなわち、moofサブセット、シーケンスナンバsqn、バージョンv、及び、NTP時刻ntを格納したLCTヘッダを生成する。
さらに、ステップＳ４５３では、FLUTEストリーマ２４は、デコード関連情報を格納したLCTヘッダに、セグメンタ２２からのポーションとしての最初のサンプル群を、エンコーディングシンボルとして付加することで、LCTパケット（図３０のLCTパケット４１０に相当するLCTパケット）を生成し、マルチキャストサーバ２５に供給して、処理は、ステップＳ４５４に進む。
ステップＳ４５４では、マルチキャストサーバ２５は、FLUTEストリーマ２４からのLCTパケットをマルチキャスト配信して、処理は、ステップＳ４５５に進む。
ステップＳ４５５では、セグメンタ２２は、注目フラグメントについて、次のサンプル群を、注目サンプル群として生成し、ポーションとして、FLUTEストリーマ２４に供給して、処理は、ステップＳ４５６に進む。
ステップＳ４５６では、セグメンタ２２は、ポーションとしての注目サンプル群についてのデコード関係情報、すなわち、注目フラグメントのmoofに格納されるシーケンスナンバと同一のシーケンスナンバsqn、注目サンプル群の、注目フラグメントにおける順番を表すバージョンv、注目フラグメントのmoofに格納されるbmdtに対応するNTP時刻nt、及び、注目サンプル群の先頭のサンプルのサンプル番号を表すサンプルカウントスタートscsを生成し、FLUTEストリーマ２４に供給する。
さらに、ステップＳ４５６では、セグメンタ２２は、注目フラグメントについて、注目サンプル群を生成するまでに生成することができた、注目サンプル群、（及び、注目フラグメントの注目サンプル群を生成する前に生成されたサンプル群）の再生に必要なmoofの一部を、注目サンプル群用のmoofサブセットとして取得し、FLUTEストリーマ２４に供給して、処理は、ステップＳ４５７に進む。
ステップＳ４５７では、FLUTEストリーマ２４は、セグメンタ２２からのデコード関連情報、すなわち、moofサブセット、シーケンスナンバsqn、バージョンv、NTP時刻nt、及び、サンプルカウントスタートscsを格納したLCTヘッダを生成する。
さらに、ステップＳ４５７では、FLUTEストリーマ２４は、デコード関連情報を格納したLCTヘッダに、セグメンタ２２からのポーションとしての注目サンプル群を、エンコーディングシンボルとして付加することで、LCTパケット（図３９のLCTパケット４３０又は４５０に相当するLCTパケット）を生成し、マルチキャストサーバ２５に供給して、処理は、ステップＳ４５８に進む。
ステップＳ４５８では、マルチキャストサーバ２５は、FLUTEストリーマ２４からのLCTパケットをマルチキャスト配信して、処理は、ステップＳ４５９に進む。
ステップＳ４５９では、セグメンタ２２は、注目サンプル群が、注目フラグメントの最後のサンプル群であるかどうかを判定する。
ステップＳ４５９において、注目サンプル群が、注目フラグメントの最後のサンプル群でないと判定された場合、すなわち、注目フラグメントにおいて、注目サンプル群の次のサンプル群がある場合、処理は、ステップＳ４５５に戻り、注目サンプル群の次のサンプル群を、新たな注目サンプル群として、同様の処理が繰り返される。
また、ステップＳ４５９において、注目サンプル群が、注目フラグメントの最後のサンプル群であると判定された場合、処理は、ステップＳ４６０に進み、FLUTEストリーマ２４は、注目フラグメントを有するセグメントのstyp（及び、必要なsidx）を、セグメンタ２２から取得する。
さらに、FLUTEストリーマ２４は、セグメンタ２２から供給されたmdatヘッダ、及び、注目フラグメントの最後のサンプル群の生成時までに生成されたmoofサブセット、すなわち、注目フラグメントのすべてのサンプル群についてのmoof、並びに、セグメンタ２２から取得したstyp（及び、必要なsidx）をエンコーディングシンボルに格納したLCTパケット（図３０のLCTパケット４６０に相当するLCTパケット）を生成し、マルチキャストサーバ２５に供給して、処理は、ステップＳ４６１に進む。
ステップＳ４６１では、マルチキャストサーバ２５は、FLUTEストリーマ２４からの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、その他の任意の動画フォーマットのフラグメントを採用することができる。
また、本技術は、コンテンツ以外の任意のデータの配信に適用することができる。
ここで、本明細書に記載された効果はあくまで例示であって限定されるものではなく、他の効果があってもよい。
なお、本技術は、以下のような構成をとることができる。
＜１＞
フラグメントの一部を含むデータであるポーションと、LCT(Layerd Coding Transport)ヘッダとを含むLCTパケットを配信する配信部を備え、
前記フラグメントは、
moof(movie fragment)と、
mdat(media data)ヘッダ及び1個以上のサンプル群を有するmdatと
を有し、
前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、
前記LCTヘッダは、
前記フラグメントの順番を表すシーケンスナンバと、
前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと、
前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻と、
前記フラグメントの一部の先頭のサンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報と、
前記moofの少なくとも一部であるmoofサブセットと
を含む
送信装置。
＜２＞
前記フラグメントは、fragmentedMP4のフラグメントである
＜１＞に記載の送信装置。
＜３＞
前記ポーションは、
前記フラグメントの一部としてのサンプル群、
又は、前記フラグメントの一部としての前記moof、及び、前記mdatヘッダ
である
＜２＞に記載の送信装置。
＜４＞
前記ポーションは、http(Hypertext Transfer Protocol)レスポンスであり、
前記httpレスポンスは、
前記フラグメントの一部としてのサンプル群、及び、前記moofサブセットを、メッセージボディに含み、
前記シーケンスナンバ、前記バージョン、前記NTP時刻、及び、前記サンプルカウントスタート情報を、httpヘッダに含む
＜２＞に記載の送信装置。
＜５＞
前記moofサブセットは、前記フラグメントの一部としてのサンプル群が生成されるまでに生成されるmoofの部分である
＜１＞ないし＜４＞のいずれかに記載の送信装置。
＜６＞
フラグメントの一部を含むデータであるポーションと、LCT(Layerd Coding Transport)ヘッダとを含むLCTパケットを配信するステップを含み、
前記フラグメントは、
moof(movie fragment)と、
mdat(media data)ヘッダ及びサンプル群を有するmdatと
を有し、
前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、
前記LCTヘッダは、
前記フラグメントの順番を表すシーケンスナンバと、
前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと、
前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻と、
前記フラグメントの一部の先頭のサンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報と、
前記moofの少なくとも一部であるmoofサブセットと
を含む
送信方法。
＜７＞
フラグメントの一部を含むデータであるポーションと、LCT(Layerd Coding Transport)ヘッダとを含むLCTパケットを配信する配信部として、コンピュータを機能させるためのプログラムであり、
前記フラグメントは、
moof(movie fragment)と、
mdat(media data)ヘッダ及びサンプル群を有するmdatと
を有し、
前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、
前記LCTヘッダは、
前記フラグメントの順番を表すシーケンスナンバと、
前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと、
前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻と、
前記フラグメントの一部の先頭のサンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報と、
前記moofの少なくとも一部であるmoofサブセットと
を含む
プログラム。
＜８＞
フラグメントの一部を含むデータであるポーションと、LCT(Layerd Coding Transport)ヘッダとを含むLCTパケットを受信する受信部を備え、
前記フラグメントは、
moof(movie fragment)と、
mdat(media data)ヘッダ及びサンプル群を有するmdatと
を有し、
前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、
前記LCTヘッダは、
前記フラグメントの順番を表すシーケンスナンバと、
前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと、
前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻と、
前記フラグメントの一部の先頭のサンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報と、
前記moofの少なくとも一部であるmoofサブセットと
を含む
受信装置。
＜９＞
前記フラグメントは、fragmentedMP4のフラグメントである
＜８＞に記載の受信装置。
＜１０＞
前記ポーションは、
前記フラグメントの一部としてのサンプル群、
又は、前記フラグメントの一部としての前記moof、及び、前記mdatヘッダ
である
＜９＞に記載の受信装置。
＜１１＞
前記ポーションは、http(Hypertext Transfer Protocol)レスポンスであり、
前記httpレスポンスは、
前記フラグメントの一部としてのサンプル群、及び、前記moofサブセットを、メッセージボディに含み、
前記シーケンスナンバ、前記バージョン、前記NTP時刻、及び、前記サンプルカウントスタート情報を、httpヘッダに含む
＜９＞に記載の受信装置。
＜１２＞
前記moofサブセットは、前記フラグメントの一部としてのサンプル群が生成されるまでに生成されるmoofの部分である
＜８＞ないし＜１１＞のいずれかに記載の受信装置。
＜１３＞
フラグメントの一部を含むデータであるポーションと、LCT(Layerd Coding Transport)ヘッダとを含むLCTパケットを受信するステップを備え、
前記フラグメントは、
moof(movie fragment)と、
mdat(media data)ヘッダ及びサンプル群を有するmdatと
を有し、
前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、
前記LCTヘッダは、
前記フラグメントの順番を表すシーケンスナンバと、
前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと、
前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻と、
前記フラグメントの一部の先頭のサンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報と、
前記moofの少なくとも一部であるmoofサブセットと
を含む
受信方法。
＜１４＞
フラグメントの一部を含むデータであるポーションと、LCT(Layerd Coding Transport)ヘッダとを含むLCTパケットを受信する受信部として、コンピュータを機能させるためのプログラムであり、
前記フラグメントは、
moof(movie fragment)と、
mdat(media data)ヘッダ及びサンプル群を有するmdatと
を有し、
前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、
前記LCTヘッダは、
前記フラグメントの順番を表すシーケンスナンバと、
前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと、
前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻と、
前記フラグメントの一部の先頭のサンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報と、
前記moofの少なくとも一部であるmoofサブセットと
を含む
プログラム。
１０ ネットワーク， １１ 配信サーバ， １２ クライアント， １３ NTPサーバ， ２１ チャンネルストリーマ， ２２ セグメンタ， ２３ メタデータジェネレータ， ２４ FLUTEストリーマ， ２５ マルチキャストサーバ， ２６ webサーバ， ３０ 受信部， ３１ ミドルウェア， ３２ DASHクライアント， ３３ 再生部， ３０１ バス， ３０２ CPU， ３０３ ROM， ３０４ RAM， ３０５ ハードディスク， ３０６ 出力部， ３０７ 入力部， ３０８ 通信部， ３０９ ドライブ， ３１０ 入出力インタフェース， ３１１ リムーバブル記録媒体

Claims (14)

  1. フラグメントの一部を含むデータであるポーションと、LCT(Layerd Coding Transport)ヘッダとを含むLCTパケットを配信する配信部を備え、
    前記フラグメントは、
    moof(movie fragment)と、
    mdat(media data)ヘッダ及び1個以上のサンプル群を有するmdatと
    を有し、
    前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、
    前記LCTヘッダは、
    前記フラグメントの順番を表すシーケンスナンバと、
    前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと、
    前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻と、
    前記フラグメントの一部の先頭のサンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報と、
    前記moofの少なくとも一部であるmoofサブセットと
    を含む
    送信装置。
  2. 前記フラグメントは、fragmentedMP4のフラグメントである
    請求項１に記載の送信装置。
  3. 前記ポーションは、
    前記フラグメントの一部としてのサンプル群、
    又は、前記フラグメントの一部としての前記moof、及び、前記mdatヘッダ
    である
    請求項２に記載の送信装置。
  4. 前記ポーションは、http(Hypertext Transfer Protocol)レスポンスであり、
    前記httpレスポンスは、
    前記フラグメントの一部としてのサンプル群、及び、前記moofサブセットを、メッセージボディに含み、
    前記シーケンスナンバ、前記バージョン、前記NTP時刻、及び、前記サンプルカウントスタート情報を、httpヘッダに含む
    請求項２に記載の送信装置。
  5. 前記moofサブセットは、前記フラグメントの一部としてのサンプル群が生成されるまでに生成されるmoofの部分である
    請求項２に記載の送信装置。
  6. フラグメントの一部を含むデータであるポーションと、LCT(Layerd Coding Transport)ヘッダとを含むLCTパケットを配信するステップを含み、
    前記フラグメントは、
    moof(movie fragment)と、
    mdat(media data)ヘッダ及びサンプル群を有するmdatと
    を有し、
    前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、
    前記LCTヘッダは、
    前記フラグメントの順番を表すシーケンスナンバと、
    前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと、
    前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻と、
    前記フラグメントの一部の先頭のサンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報と、
    前記moofの少なくとも一部であるmoofサブセットと
    を含む
    送信方法。
  7. フラグメントの一部を含むデータであるポーションと、LCT(Layerd Coding Transport)ヘッダとを含むLCTパケットを配信する配信部として、コンピュータを機能させるためのプログラムであり、
    前記フラグメントは、
    moof(movie fragment)と、
    mdat(media data)ヘッダ及びサンプル群を有するmdatと
    を有し、
    前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、
    前記LCTヘッダは、
    前記フラグメントの順番を表すシーケンスナンバと、
    前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと、
    前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻と、
    前記フラグメントの一部の先頭のサンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報と、
    前記moofの少なくとも一部であるmoofサブセットと
    を含む
    プログラム。
  8. フラグメントの一部を含むデータであるポーションと、LCT(Layerd Coding Transport)ヘッダとを含むLCTパケットを受信する受信部を備え、
    前記フラグメントは、
    moof(movie fragment)と、
    mdat(media data)ヘッダ及びサンプル群を有するmdatと
    を有し、
    前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、
    前記LCTヘッダは、
    前記フラグメントの順番を表すシーケンスナンバと、
    前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと、
    前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻と、
    前記フラグメントの一部の先頭のサンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報と、
    前記moofの少なくとも一部であるmoofサブセットと
    を含む
    受信装置。
  9. 前記フラグメントは、fragmentedMP4のフラグメントである
    請求項８に記載の受信装置。
  10. 前記ポーションは、
    前記フラグメントの一部としてのサンプル群、
    又は、前記フラグメントの一部としての前記moof、及び、前記mdatヘッダ
    である
    請求項９に記載の受信装置。
  11. 前記ポーションは、http(Hypertext Transfer Protocol)レスポンスであり、
    前記httpレスポンスは、
    前記フラグメントの一部としてのサンプル群、及び、前記moofサブセットを、メッセージボディに含み、
    前記シーケンスナンバ、前記バージョン、前記NTP時刻、及び、前記サンプルカウントスタート情報を、httpヘッダに含む
    請求項９に記載の受信装置。
  12. 前記moofサブセットは、前記フラグメントの一部としてのサンプル群が生成されるまでに生成されるmoofの部分である
    請求項９に記載の受信装置。
  13. フラグメントの一部を含むデータであるポーションと、LCT(Layerd Coding Transport)ヘッダとを含むLCTパケットを受信するステップを備え、
    前記フラグメントは、
    moof(movie fragment)と、
    mdat(media data)ヘッダ及びサンプル群を有するmdatと
    を有し、
    前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、
    前記LCTヘッダは、
    前記フラグメントの順番を表すシーケンスナンバと、
    前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと、
    前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻と、
    前記フラグメントの一部の先頭のサンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報と、
    前記moofの少なくとも一部であるmoofサブセットと
    を含む
    受信方法。
  14. フラグメントの一部を含むデータであるポーションと、LCT(Layerd Coding Transport)ヘッダとを含むLCTパケットを受信する受信部として、コンピュータを機能させるためのプログラムであり、
    前記フラグメントは、
    moof(movie fragment)と、
    mdat(media data)ヘッダ及びサンプル群を有するmdatと
    を有し、
    前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、
    前記LCTヘッダは、
    前記フラグメントの順番を表すシーケンスナンバと、
    前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと、
    前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻と、
    前記フラグメントの一部の先頭のサンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報と、
    前記moofの少なくとも一部であるmoofサブセットと
    を含む
    プログラム。
JP2014069940A 2014-03-28 2014-03-28 送信装置、送信方法、受信装置、受信方法、及び、プログラム Pending JP2015192407A (ja)

Priority Applications (8)

Application Number Priority Date Filing Date Title
JP2014069940A JP2015192407A (ja) 2014-03-28 2014-03-28 送信装置、送信方法、受信装置、受信方法、及び、プログラム
MX2016012218A MX362219B (es) 2014-03-28 2015-03-13 Aparato de transmision, metodo de transmision, aparato de recepcion, metodo de recepcion, y programa.
KR1020167025213A KR102137858B1 (ko) 2014-03-28 2015-03-13 송신 장치, 송신 방법, 수신 장치, 수신 방법 및 프로그램
CN201580015015.8A CN106105239B (zh) 2014-03-28 2015-03-13 发送设备、发送方法、接收设备、接收方法和程序
US15/127,462 US10432989B2 (en) 2014-03-28 2015-03-13 Transmission apparatus, transmission method, reception apparatus, receiving method, and program
EP15770090.7A EP3125563A4 (en) 2014-03-28 2015-03-13 Transmission device, transmission method, reception device, reception method, and program
PCT/JP2015/057533 WO2015146647A1 (ja) 2014-03-28 2015-03-13 送信装置、送信方法、受信装置、受信方法、及び、プログラム
CA2941367A CA2941367A1 (en) 2014-03-28 2015-03-13 Transmission apparatus, transmission method, reception apparatus, receiving method, and program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2014069940A JP2015192407A (ja) 2014-03-28 2014-03-28 送信装置、送信方法、受信装置、受信方法、及び、プログラム

Publications (1)

Publication Number Publication Date
JP2015192407A true JP2015192407A (ja) 2015-11-02

Family

ID=54195170

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014069940A Pending JP2015192407A (ja) 2014-03-28 2014-03-28 送信装置、送信方法、受信装置、受信方法、及び、プログラム

Country Status (8)

Country Link
US (1) US10432989B2 (ja)
EP (1) EP3125563A4 (ja)
JP (1) JP2015192407A (ja)
KR (1) KR102137858B1 (ja)
CN (1) CN106105239B (ja)
CA (1) CA2941367A1 (ja)
MX (1) MX362219B (ja)
WO (1) WO2015146647A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019524011A (ja) * 2016-05-26 2019-08-29 サムスン エレクトロニクス カンパニー リミテッド Ｍｍｔｐパケットを送受信する方法及びその装置
JP2019536354A (ja) * 2016-11-10 2019-12-12 テレフオンアクチーボラゲット エルエム エリクソン（パブル） 配信性能を改善するためのリソースセグメント化

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015064383A1 (ja) 2013-10-30 2015-05-07 ソニー株式会社 送信装置、送信方法、受信装置、及び、受信方法
EP3703379B1 (en) * 2013-12-16 2022-06-22 Panasonic Intellectual Property Corporation of America Transmission method, reception method, transmitting device, and receiving device
CN109391551B (zh) * 2017-08-14 2021-10-12 中兴通讯股份有限公司 一种多端口组播方法、设备及计算机可读存储介质

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9209934B2 (en) * 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
WO2009087563A2 (en) * 2008-01-09 2009-07-16 Nokia Corporation Systems and methods for media container file generation
KR101479890B1 (ko) * 2010-12-26 2015-01-06 엘지전자 주식회사 미디어 콘텐트 송수신 방법 및 그를 이용한 송수신 장치
US9026671B2 (en) * 2011-04-05 2015-05-05 Qualcomm Incorporated IP broadcast streaming services distribution using file delivery methods
US20150172348A1 (en) 2012-01-17 2015-06-18 Telefonaktiebolaget L M Ericsson (Publ) Method for sending respectively receiving a media stream
KR102057107B1 (ko) * 2012-01-24 2019-12-18 소니 주식회사 수신 장치, 수신 방법, 프로그램 및 정보 처리 시스템
US9843845B2 (en) * 2012-11-28 2017-12-12 Sinclair Broadcast Group, Inc. Terrestrial broadcast market exchange network platform and broadcast augmentation channels for hybrid broadcasting in the internet age
US9426196B2 (en) * 2013-01-04 2016-08-23 Qualcomm Incorporated Live timing for dynamic adaptive streaming over HTTP (DASH)
WO2015064384A1 (ja) * 2013-10-30 2015-05-07 ソニー株式会社 送信装置、送信方法、受信装置、及び、受信方法
WO2015064383A1 (ja) * 2013-10-30 2015-05-07 ソニー株式会社 送信装置、送信方法、受信装置、及び、受信方法
US10313716B2 (en) * 2013-11-01 2019-06-04 Lg Electronics Inc. Apparatus for transmitting broadcast signals, apparatus for receiving broadcast signals, method for transmitting broadcast signals and method for receiving broadcast signals

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019524011A (ja) * 2016-05-26 2019-08-29 サムスン エレクトロニクス カンパニー リミテッド Ｍｍｔｐパケットを送受信する方法及びその装置
JP2019536354A (ja) * 2016-11-10 2019-12-12 テレフオンアクチーボラゲット エルエム エリクソン（パブル） 配信性能を改善するためのリソースセグメント化
US11558677B2 (en) 2016-11-10 2023-01-17 Telefonaktiebolaget Lm Ericsson (Publ) Resource segmentation to improve delivery performance

Also Published As

Publication number Publication date
MX2016012218A (es) 2017-01-05
EP3125563A4 (en) 2017-09-06
CN106105239B (zh) 2019-09-10
US20170134773A1 (en) 2017-05-11
WO2015146647A1 (ja) 2015-10-01
KR20160138401A (ko) 2016-12-05
EP3125563A1 (en) 2017-02-01
CN106105239A (zh) 2016-11-09
KR102137858B1 (ko) 2020-07-24
MX362219B (es) 2019-01-09
US10432989B2 (en) 2019-10-01
CA2941367A1 (en) 2015-10-01

Similar Documents

Publication Publication Date Title
JP6329964B2 (ja) 送信装置、送信方法、受信装置、及び、受信方法
JP6845223B2 (ja) コーディングされたオーディオデータのトランスポート
JP6348251B2 (ja) 端末装置、受信方法、およびプログラム
CN110213666B (zh) 一种接收装置、接收方法及存储介质
JP6743704B2 (ja) 送信装置、送信方法、受信装置および受信方法
KR20120114016A (ko) 사용자 컨텐츠를 외부 단말기에서 네트워크 적응적으로 스트리밍하는 방법 및 장치
EP3016396B1 (en) Content supply device, content supply method, program, terminal device, and content supply system for providing zapping segments using mpeg-dash streaming
WO2015146647A1 (ja) 送信装置、送信方法、受信装置、受信方法、及び、プログラム
US20200021867A1 (en) Broadcast signal transmitting and receiving method and device
JP6492006B2 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、および、コンテンツ供給システム
KR20170082064A (ko) 방송 통신 융합망의 하이브리드 서비스를 위한 방송 서비스 제공 장치 및 이를 이용한 방법
JP2015061307A (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
WO2015064384A1 (ja) 送信装置、送信方法、受信装置、及び、受信方法
WO2015045917A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
EP3041242B1 (en) Content provision device, content provision method, program, terminal device, and content provision system
WO2015012140A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム