JP6329964B2 - 送信装置、送信方法、受信装置、及び、受信方法 - Google Patents

送信装置、送信方法、受信装置、及び、受信方法 Download PDF

Info

Publication number
JP6329964B2
JP6329964B2 JP2015544919A JP2015544919A JP6329964B2 JP 6329964 B2 JP6329964 B2 JP 6329964B2 JP 2015544919 A JP2015544919 A JP 2015544919A JP 2015544919 A JP2015544919 A JP 2015544919A JP 6329964 B2 JP6329964 B2 JP 6329964B2
Authority
JP
Japan
Prior art keywords
fragment
sample
http
header
sample group
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.)
Active
Application number
JP2015544919A
Other languages
English (en)
Other versions
JPWO2015064383A1 (ja
Inventor
山岸　靖明
靖明 山岸
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.)
Saturn Licensing LLC
Original Assignee
Saturn Licensing LLC
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 Saturn Licensing LLC filed Critical Saturn Licensing LLC
Publication of JPWO2015064383A1 publication Critical patent/JPWO2015064383A1/ja
Application granted granted Critical
Publication of JP6329964B2 publication Critical patent/JP6329964B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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/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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • 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
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • 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/435—Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • 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/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • 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/633—Control signals issued by server directed to the network components or client
    • 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/64—Addressing
    • H04N21/6405—Multicasting
    • 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/64—Addressing
    • H04N21/6408—Unicasting
    • 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
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Library & Information Science (AREA)
  • Databases & Information Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

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では、コンテンツをマルチキャスト配信（ブロードキャスト配信を含む）する場合に、セグメントが生成されるまで、コンテンツの配信を待つ必要がある。
今後は、より高画質の動画配信が一般になることが予想され、その場合、コンテンツのストリームのビットレートが大になる。
コンテンツのストリームのビットレートが大である場合に、セグメントの生成が完了するのを待って、セグメントの単位で、コンテンツの配信、すなわち、バルク転送を行うのでは、ネットワークの帯域が圧迫され、シェーピングが必要になることがある。
したがって、セグメントの生成が完了するのを待って、セグメントの単位で、コンテンツを配信するのでは、最終的には、クライアントでのコンテンツの受信、及び、バッファリングの開始に遅延が生じるため、コンテンツを迅速に配信する技術の提案が要請されている。
本技術は、このような状況に鑑みてなされたものであり、コンテンツ等のデータを迅速に配信することができるようにするものである。
本技術の送信装置は、フラグメントの一部と、前記フラグメントの順番を表すシーケンスナンバと、前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンとを含む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， ３０５ ハードディスク， ３０６ 出力部， ３０７ 入力部， ３０８ 通信部， ３０９ ドライブ， ３１０ 入出力インタフェース， ３１１ リムーバブル記録媒体

Claims (14)

  1. フラグメントの一部と、
    前記フラグメントの順番を表すシーケンスナンバと、
    前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと
    を含むhttp(Hypertext Transfer Protocol)ヘッダと
    を含むhttpレスポンスを配信する配信部を備える
    送信装置。
  2. 前記フラグメントの最後の一部を含む前記httpレスポンスの前記バージョンは、前記フラグメントの最後を表す情報を含む
    請求項１に記載の送信装置。
  3. 前記フラグメントは、moof(movie fragment)とmdat(media data)とを有し、
    前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、
    前記httpヘッダは、前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻をさらに含む
    請求項２に記載の送信装置。
  4. 前記httpヘッダは、前記httpレスポンスに含まれる前記フラグメントの一部の先頭の前記サンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報を、さらに含む
    請求項３に記載の送信装置。
  5. 前記フラグメントの2番目以降の一部を含む前記httpレスポンスの前記httpヘッダが、前記サンプルカウントスタート情報を含む
    請求項４に記載の送信装置。
  6. 前記フラグメントは、fragmentedMP4のフラグメントである
    請求項５に記載の送信装置。
  7. フラグメントの一部と、
    前記フラグメントの順番を表すシーケンスナンバと、
    前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと
    を含むhttp(Hypertext Transfer Protocol)ヘッダと
    を含むhttpレスポンスを配信する
    ステップを含む送信方法。
  8. フラグメントの一部と、
    前記フラグメントの順番を表すシーケンスナンバと、
    前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと
    を含むhttp(Hypertext Transfer Protocol)ヘッダと
    を含むhttpレスポンスを受信する受信部を備える
    受信装置。
  9. 前記フラグメントの最後の一部を含む前記httpレスポンスの前記バージョンは、前記フラグメントの最後を表す情報を含む
    請求項８に記載の受信装置。
  10. 前記フラグメントは、moof(movie fragment)とmdat(media data)とを有し、
    前記moofは、前記mdatの先頭のサンプルのプレゼンテーションタイムを表すBaseMediaDecodeTimeを含み、
    前記httpヘッダは、前記BaseMediaDecodeTimeに対応するNTP(Network Time Protocol)時刻をさらに含む
    請求項９に記載の受信装置。
  11. 前記httpヘッダは、前記httpレスポンスに含まれる前記フラグメントの一部の先頭の前記サンプルの、前記フラグメントの先頭のサンプルからの順番を表すサンプルカウントスタート情報を、さらに含む
    請求項１０に記載の受信装置。
  12. 前記フラグメントの2番目以降の一部を含む前記httpレスポンスの前記httpヘッダが、前記サンプルカウントスタート情報を含む
    請求項１１に記載の受信装置。
  13. 前記フラグメントは、fragmentedMP4のフラグメントである
    請求項１２に記載の受信装置。
  14. フラグメントの一部と、
    前記フラグメントの順番を表すシーケンスナンバと、
    前記フラグメントの一部の、前記フラグメントにおける順番を表すバージョンと
    を含むhttp(Hypertext Transfer Protocol)ヘッダと
    を含むhttpレスポンスを受信する
    ステップを含む受信方法。
JP2015544919A 2013-10-30 2014-10-17 送信装置、送信方法、受信装置、及び、受信方法 Active JP6329964B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2013225540 2013-10-30
JP2013225540 2013-10-30
PCT/JP2014/077658 WO2015064383A1 (ja) 2013-10-30 2014-10-17 送信装置、送信方法、受信装置、及び、受信方法

Publications (2)

Publication Number Publication Date
JPWO2015064383A1 JPWO2015064383A1 (ja) 2017-03-09
JP6329964B2 true JP6329964B2 (ja) 2018-05-23

Family

ID=53003992

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015544919A Active JP6329964B2 (ja) 2013-10-30 2014-10-17 送信装置、送信方法、受信装置、及び、受信方法

Country Status (6)

Country Link
US (1) US10499094B2 (ja)
EP (1) EP3065414B1 (ja)
JP (1) JP6329964B2 (ja)
CN (1) CN105659623B (ja)
PH (1) PH12016500757A1 (ja)
WO (1) WO2015064383A1 (ja)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101779435B1 (ko) * 2014-01-03 2017-09-18 엘지전자 주식회사 방송 신호를 송신하는 장치, 방송 신호를 수신하는 장치, 방송 신호를 송신하는 방법 및 방송 신호를 수신하는 방법
KR101737849B1 (ko) * 2014-02-24 2017-05-19 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
JP2015192407A (ja) 2014-03-28 2015-11-02 ソニー株式会社 送信装置、送信方法、受信装置、受信方法、及び、プログラム
WO2016076654A1 (ko) 2014-11-13 2016-05-19 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
JP6610019B2 (ja) 2015-06-16 2019-11-27 ソニー株式会社 受信装置、送信装置、及び、データ処理方法
WO2017041827A1 (en) * 2015-09-08 2017-03-16 Telefonaktiebolaget Lm Ericsson (Publ) Streaming session continuation
CN107948762B (zh) * 2016-10-13 2021-05-11 华为技术有限公司 直播视频的传输方法、装置和系统
EP3539271A1 (en) * 2016-11-10 2019-09-18 Telefonaktiebolaget LM Ericsson (PUBL) Resource segmentation to improve delivery performance
JP7454951B2 (ja) * 2020-01-27 2024-03-25 日本放送協会 コンテンツ配信装置、端末、およびプログラム

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101330492B (zh) 2007-06-19 2012-08-01 上海贝尔股份有限公司 数据发送方法、数据接收方法和设备
JP6029805B2 (ja) 2010-01-15 2016-11-24 富士通株式会社 配信装置、配信プログラムおよび配信方法
KR101709903B1 (ko) * 2010-02-19 2017-02-23 텔레폰악티에볼라겟엘엠에릭슨(펍) 에이치티티피 스트리밍에서 적응화를 위한 방법 및 장치
WO2012011467A1 (ja) * 2010-07-20 2012-01-26 シャープ株式会社 データ配信システム、データ配信方法、配信側データ中継装置、及び受信側データ中継装置
KR20120010089A (ko) * 2010-07-20 2012-02-02 삼성전자주식회사 Ｈｔｔｐ 기반의 멀티미디어 스트리밍 서비스의 품질 향상을 위한 방법 및 장치
WO2012046487A1 (ja) 2010-10-05 2012-04-12 シャープ株式会社 コンテンツ再生装置、コンテンツ配信システム、コンテンツ再生装置の同期方法、制御プログラム、および、記録媒体
US8489760B2 (en) 2011-03-31 2013-07-16 Juniper Networks, Inc. Media file storage format and adaptive delivery system
JP2013005260A (ja) * 2011-06-17 2013-01-07 Sony Corp 送出装置、受信装置、放送システム、送出方法、受信方法及びこれらのプログラム
JP2013038766A (ja) * 2011-07-12 2013-02-21 Sharp Corp 送信装置、送信装置の制御方法、制御プログラム、及び記録媒体
US9465923B2 (en) * 2013-03-08 2016-10-11 Intel Corporation Blackouts architecture
JP2015192407A (ja) * 2014-03-28 2015-11-02 ソニー株式会社 送信装置、送信方法、受信装置、受信方法、及び、プログラム

Also Published As

Publication number Publication date
WO2015064383A1 (ja) 2015-05-07
PH12016500757A1 (en) 2016-05-30
US20160219311A1 (en) 2016-07-28
JPWO2015064383A1 (ja) 2017-03-09
CN105659623B (zh) 2019-04-26
CN105659623A (zh) 2016-06-08
EP3065414A4 (en) 2017-06-21
US10499094B2 (en) 2019-12-03
EP3065414B1 (en) 2019-01-09
EP3065414A1 (en) 2016-09-07

Similar Documents

Publication Publication Date Title
JP6329964B2 (ja) 送信装置、送信方法、受信装置、及び、受信方法
JP6348251B2 (ja) 端末装置、受信方法、およびプログラム
CN110213666B (zh) 一种接收装置、接收方法及存储介质
JP6570999B2 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
EP3016396B1 (en) Content supply device, content supply method, program, terminal device, and content supply system for providing zapping segments using mpeg-dash streaming
KR20120114016A (ko) 사용자 컨텐츠를 외부 단말기에서 네트워크 적응적으로 스트리밍하는 방법 및 장치
WO2015146647A1 (ja) 送信装置、送信方法、受信装置、受信方法、及び、プログラム
KR20160077066A (ko) 송신 장치, 송신 방법, 수신 장치, 및 수신 방법
WO2016174960A1 (ja) 受信装置、送信装置、およびデータ処理方法
JP6492006B2 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、および、コンテンツ供給システム
KR20160077067A (ko) 송신 장치, 송신 방법, 수신 장치, 및 수신 방법
WO2015064384A1 (ja) 送信装置、送信方法、受信装置、及び、受信方法
JP2014239291A (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
WO2015041071A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
WO2015045917A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
RU2658672C2 (ru) Устройство предоставления контента, программа, оконечное устройство и система предоставления контента
JP6653575B2 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、端末装置の動作方法、およびコンテンツ供給システム
WO2015012140A1 (ja) コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20171012

A711 Notification of change in applicant

Free format text: JAPANESE INTERMEDIATE CODE: A711

Effective date: 20180219

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180327

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20180423

R150 Certificate of patent or registration of utility model

Ref document number: 6329964

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250