WO2014057896A1 - コンテンツ送信装置、コンテンツ再生装置、コンテンツ配信システム、コンテンツ送信装置の制御方法、コンテンツ再生装置の制御方法、制御プログラムおよび記録媒体 - Google Patents

コンテンツ送信装置、コンテンツ再生装置、コンテンツ配信システム、コンテンツ送信装置の制御方法、コンテンツ再生装置の制御方法、制御プログラムおよび記録媒体 Download PDF

Info

Publication number
WO2014057896A1
WO2014057896A1 PCT/JP2013/077165 JP2013077165W WO2014057896A1 WO 2014057896 A1 WO2014057896 A1 WO 2014057896A1 JP 2013077165 W JP2013077165 W JP 2013077165W WO 2014057896 A1 WO2014057896 A1 WO 2014057896A1
Authority
WO
WIPO (PCT)
Prior art keywords
content
segment
sub
segments
transmission
Prior art date
Application number
PCT/JP2013/077165
Other languages
English (en)
French (fr)
Inventor
徳毛　靖昭
琢也 岩波
渡部　秀一
鈴木　秀樹
Original Assignee
シャープ株式会社
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 シャープ株式会社 filed Critical シャープ株式会社
Priority to JP2014540833A priority Critical patent/JPWO2014057896A1/ja
Priority to EP13844804.8A priority patent/EP2908535A4/en
Priority to US14/434,158 priority patent/US9641906B2/en
Publication of WO2014057896A1 publication Critical patent/WO2014057896A1/ja
Priority to US15/478,258 priority patent/US9832534B2/en
Priority to US15/807,892 priority patent/US20180070148A1/en

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/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • 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/637—Control signals issued by the client directed to the server or network components
    • H04N21/6373—Control signals issued by the client directed to the server or network components for rate control, e.g. request to the server to modify its transmission rate
    • 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • 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/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4621—Controlling the complexity of the content stream or additional data, e.g. lowering the resolution or bit-rate of the video stream for a mobile client with a small screen
    • 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

Definitions

  • the present invention relates to a content transmission apparatus that transmits content, a content reproduction apparatus that acquires and reproduces content, a content distribution system, a control method for a content transmission apparatus, a control method for a content reproduction apparatus, a control program, and a recording medium.
  • VOD Video On Demand
  • data is transmitted and received between a server (content providing apparatus) and a client (content reproducing apparatus) using HTTP (HyperText Transfer Protocol).
  • MPEG Motion Picture Experts Group
  • MPEG-DASH Dynamic Adaptive Streaming over HTTP
  • content is time-divided into a plurality of segments and transmitted in segment units.
  • Each segment is composed of one or a plurality of fragments.
  • the content is composed of one or a plurality of periods, and one period includes one or a plurality of segments.
  • a plurality of representations having different quality types are prepared for one content. For example, a plurality of segment data encoded at different bit rates for each segment is prepared. Accordingly, a client that receives and reproduces content can execute adaptive streaming by changing the bit rate of the requested content (segment) in accordance with the reception status of the content.
  • MPD Media Presentation Description
  • MPD is content metadata and describes content management information in XML format.
  • MPD is information used by the client when acquiring / reproducing content.
  • FIG. 10 is a diagram illustrating a description example of MPD.
  • the MPD 200 describes information 210 including type information 211, profile information 212, buffering time information 213, and distribution start time information 214.
  • Type information 211 is information (attribute value of attribute “type”) indicating whether the distribution is live distribution or on-demand distribution.
  • attribute value of attribute “type” is “dynamic”, which indicates that the content associated with the MPD 200 is the live delivery content.
  • “static” is described in the attribute value of the attribute “type”.
  • the profile information 212 is information indicating a content profile.
  • the buffering time information 213 is information indicating the minimum buffering time. In the illustrated example, since the attribute value of the attribute “minBufferTime” is “PT10S”, it indicates that the client performs buffering for at least 10 seconds.
  • Delivery start time information 214 is information (attribute value of attribute “availabilityStartTime”) indicating the time at which the server starts live streaming delivery of content.
  • attribute value of attribute “availabilityStartTime” is “2012-09-20T15: 00: 00”, which indicates that live streaming distribution starts at 15:00 on September 20, 2012.
  • period information 220 relating to each period that delimits the content reproduction period is described.
  • the period information 220 includes the period start time (attribute value of the attribute “start”) and the period of the period (attribute value of the attribute “duration”) based on the content distribution start time. is described.
  • acquisition destination information 230 indicating the acquisition destination of contents is described.
  • the URL of the server is described as the acquisition source information 230.
  • high-quality segment information 241 indicating a high-quality segment and low-quality segment information 242 indicating a low-quality segment are described as segments included in a certain period (from playback time 0 to 3600 seconds).
  • the high quality segment information 241 describes the ID and bit rate of the high quality representation included in the period.
  • the length and URL of each segment included in the period are described. The same applies to the low quality segment information 242.
  • the period is composed of six segments, segment # 1 to segment # 6.
  • FIG. 11 is a diagram illustrating a data structure of segment data of a high quality segment and a low quality segment in the related art.
  • segment data is described in a box format defined by ISOBFF (ISO / IEC 14496-12) will be described.
  • conventional high-quality segment data 260 includes one styp (Segment Type Box) 261, one sidx (Segment Index Box) 262, and moof (Movie Fragment Box) 263, 265. 267 and 269 and one or a plurality of sets of mdat (Media Data Box) 264, 266, 268 and 270.
  • the low quality segment data 280 is similar to the high quality segment data 260, one styp 281, one sidx 282, moof 283, 285, 287 and 289, and mdat 284, 286. 288 and 290 and one or more pairs.
  • Styp 261 and styp 281 are information indicating a segment type and / or version information.
  • sidx 262 and sidx 282 are information on random access points in the segment.
  • the moof 263, 265, 267, and 269, mdat 264, 266, 268, and 270, the moof 283, 285, 287, and 289, and the mdat 284, 286, 288, and 290 are information regarding the fragments that constitute the segment.
  • moof 263 and 265 and mdat 264 and 266 constitute one subsegment.
  • Each entry 271, 272, 291, and 292 of sidx (“s 0” and “s 1” shown in FIGS. 11A and 11B) describes the byte size and time information of each sub-segment.
  • FIG. 12 is a diagram illustrating an example of the syntax of sidx.
  • sidx indicates an example defined in ISO / IEC 14496-12.
  • Japanese Patent Publication Japanese Patent Laid-Open No. 2005-110244 (published on April 21, 2005)”
  • MPEG-DASH is intended to realize low-delay live streaming by shortening the segment time length, but there may be a delay caused by shortening the segment time length.
  • the time length of a segment is short, normally, in order to cope with network jitter, a plurality of requests for requesting segment transmission are pipelined and transmitted. At this time, if an error occurs because the requested resource does not exist in the server, a plurality of requests must be transmitted again, and there is a problem that a delay occurs due to the re-request.
  • the present invention has been made in view of the above-described problems, and its purpose is to provide a content transmission apparatus, a content reproduction apparatus, a content distribution system, a content transmission apparatus control method, which stably perform low-delay live streaming, A content reproducing apparatus control method, a control program, and a recording medium are realized.
  • a content transmission apparatus is content including a plurality of segments, and includes a sub-segment obtained by further dividing the segment into a plurality of segments in the header of the segment.
  • a content transmission device that transmits content in which time information is described to a content reproduction device, and includes a transmission unit that, when receiving a request from the content reproduction device, transmits a response to the content reproduction device as a response to the request.
  • the transmission means chunk-transfers the segment to the content reproduction device in units of sub-segments.
  • a control method for a content transmission device is content including a plurality of segments, and the segment header is further divided into a plurality of segments.
  • the response is reproduced as a response to the request.
  • a content playback apparatus is a content including a plurality of segments, and the sub-segment is further divided into a plurality of segments in the header of the segments.
  • a content playback apparatus that acquires and reproduces content in which segment time information is described from a content transmission apparatus, and includes an acquisition means for transmitting a request for transmission of a segment to the content transmission apparatus, the acquisition means Obtains the segment that has been chunk-transferred in units of sub-segments from the content transmission device as a response to the request.
  • a content playback apparatus control method is content configured by a plurality of segments, and the segment header is further divided into a plurality of segments.
  • a method for controlling a content reproduction apparatus that acquires and reproduces content in which time information of divided sub-segments is described from a content transmission apparatus, and transmits a request for transmitting a segment to the content transmission apparatus And an acquisition step of acquiring the segment that has been chunk-transferred in units of sub-segments from the content transmission device as a response to the request.
  • low-delay live streaming can be realized stably.
  • FIG. 1 is a block diagram illustrating a main configuration of a server and a client.
  • FIG. It is a figure which shows the outline
  • It is a flowchart which shows an example of the segment transmission process which the said server performs.
  • It is a flowchart which shows an example of the segment acquisition process which the said client performs.
  • FIGS. 1 to 14 An embodiment of the present invention will be described with reference to FIGS. 1 to 14 as follows. First, an outline of the content distribution system of the present embodiment will be described based on FIG.
  • FIG. 2 is a diagram showing an outline of the content distribution system 6 according to the present embodiment.
  • the content distribution system 6 includes a server 1, a client 2, a proxy 3, an MPD storage device 4, and a segment storage device 5.
  • the client 2 connects to the server 1 via the proxy 3.
  • the server 1 is connected to the MPD storage device 4 and the segment storage device 5.
  • Each device is connected by an arbitrary network of wired communication or wireless communication.
  • the server 1 is a content transmission apparatus that receives a content transmission request from the client 2 or the proxy 3 and transmits the content.
  • the server 1 transmits MPD data to the client 2 or the proxy 3 in advance before transmitting the content data body (segment data).
  • the server 1 acquires the MPD data and the segment data from the MPD storage device 4 and the segment storage device 5 on the network 7, but is not limited to this.
  • each server 1 may hold MPD data and segment data locally.
  • the client 2 is a content reproduction device that reproduces content acquired from another device such as the server 1 or content stored in the own device.
  • the client 2 is, for example, a digital television, a recorder, an STB (Set Top Box), a PC, a mobile phone, a smartphone, a game machine, a PDA (Personal Digital Assistant), a digital camera, a digital video, or the like.
  • the proxy 3 is a relay device that transfers data acquired from a certain device (server 1 or client 2) to another device (client 2 or server 1). For example, the proxy 3 transfers the request acquired from the client 2 to the server 1 and transfers the content acquired from the server 1 to the client 2.
  • the proxy 3 caches data (MPD and content) acquired from the server 1, it can be said to be a cache server.
  • the server 1 is referred to as an origin server.
  • the proxy 3 may read the content and transmit the content to the client 2.
  • the configuration of the content distribution system 6 is not limited to the example shown in FIG.
  • the content distribution system 6 may include a plurality of servers 1 or a plurality of clients 2.
  • the content distribution system 6 may include a plurality of proxies 3.
  • HTTP which is widely used as a hypertext transfer protocol
  • the content distributed by the server 1 is video content, and the content is segmented ISOBFF data. That is, in the present embodiment, the content distribution system 6 distributes content based on the above-described MPEG-DASH standard.
  • the content handled in the present invention is composed of a plurality of segments, and is content in which time information of sub-segments obtained by further dividing the segment into a plurality of segments is described in the header of the segment.
  • the sub-segment time information is information indicating the temporal position of the sub-segment, for example, information indicating the reproduction start time of the sub-segment.
  • the unit for dividing the segment into sub-segments may be arbitrary.
  • the segment may be divided into sub-segments so that random access can be performed in units of sub-segments.
  • information indicating the temporal position of the random access point may be described in the segment header as the sub-segment time information.
  • FIG. 1 is a diagram illustrating an example of a main configuration of the server 1 and the client 2.
  • the proxy 3 is omitted.
  • the server 1 is configured to include a server control unit 11, a server storage unit 12, and a server communication unit 13.
  • the server communication unit 13 communicates with other devices such as the client 2, the proxy 3, the MPD storage device 4, and the segment storage device 5 by wireless communication means or wired communication means, and in accordance with instructions from the server control unit 11, It is an exchange.
  • the server control unit 11 performs various operations by executing a program read from the server storage unit 12 to a temporary storage unit (not shown), and comprehensively controls each unit included in the server 1. is there.
  • the server control unit 11 is configured to include a content acquisition unit 21 and a content transmission unit (transmission unit) 22 as functional blocks.
  • Each function block (21, 22) of the server control unit 11 has a program stored in a storage device realized by a CPU (central memory processing unit) such as a ROM (read memory only) RAM (random memory access memory) or the like. This can be realized by reading out and executing the temporary storage unit realized in the above.
  • the content acquisition unit 21 acquires MPD data from the MPD storage device 4 or segment data from the segment storage device 5 based on an instruction from the content transmission unit 22.
  • the content acquisition unit 21 outputs the acquired MPD data or segment data to the content transmission unit 22.
  • the content acquisition unit 21 may acquire MPD data and / or segment data in advance regardless of whether there is an instruction from the content transmission unit 22.
  • the content acquisition unit 21 stores the MPD data and segment data acquired in advance in the server storage unit 12, and MPD data and segment data from the server storage unit 12 based on an instruction from the content transmission unit 22. Is read.
  • the content transmission unit 22 determines whether the received request is a request for requesting transmission of a segment.
  • the content transmission unit 22 instructs the content acquisition unit 21 to acquire the segment, acquires segment data from the content acquisition unit 21, and A response including data is transmitted to the client 2.
  • the content transmission unit 22 when transmitting the segment data, does not transmit all the segment data at once, but transmits the sub-segments obtained by dividing the segment into a plurality of chunks as one chunk. .
  • a response to the request is transmitted to the client 2.
  • the content acquisition unit 21 is instructed to acquire the MPD of the content, and when MPD data is acquired from the content acquisition unit 21, the acquisition is performed.
  • a response including the MPD data is transmitted to the client 2.
  • the content acquisition unit 21 is instructed to acquire the resource, and when the resource is acquired from the content acquisition unit 21, the acquired resource is included.
  • a response is transmitted to the client 2.
  • the content transmitting unit 22 determines whether the received request is a request for transmitting a segment based on whether the media type of the resource specified by the received request is a segment. Also good.
  • the server storage unit 12 stores programs, data, and the like that the server control unit 11 refers to.
  • the MPD data and segment data acquired by the content acquisition unit 21 may be stored.
  • the client 2 includes a client control unit 41, a client storage unit 42, a client communication unit 43, a display unit 44, and an audio output unit 45.
  • the client 2 may include members such as an operation unit and a voice input unit, but the members are not shown because they are not related to the feature points of the invention.
  • the client communication unit 43 communicates with other devices such as the server 1 and the proxy 3 by wireless communication means or wired communication means, and exchanges data in accordance with instructions from the client control unit 41.
  • the display unit 44 displays an image according to an instruction from the client control unit 41.
  • the display unit 44 only needs to display an image in accordance with an instruction from the client control unit 41.
  • an LCD liquid crystal display
  • an organic EL display organic EL display
  • a plasma display or the like can be applied.
  • the audio output unit 45 receives an electrical signal from the client control unit 41, converts the received electrical signal into sound, and outputs the sound to the outside of the client 2.
  • the audio output unit 45 is a so-called speaker.
  • the client control unit 41 performs various operations by executing a program read from the client storage unit 42 to a temporary storage unit (not shown), and comprehensively controls each unit included in the client 2. is there.
  • the client control unit 41 includes a content acquisition unit (acquisition means) 51 and a content reproduction unit 52 as functional blocks.
  • the CPU reads a program stored in a storage device realized by a ROM or the like to a temporary storage unit realized by a RAM or the like and executes the program. Can be realized.
  • the content acquisition unit 51 transmits a request to the server 1 via the client communication unit 43, and acquires content (an MPD associated with the content and a segment constituting the content) from the server 1.
  • the content acquisition unit 51 issues a request for requesting transmission of management information (MPD) of the content. Send to server 1 or proxy 3. Then, the content acquisition unit 51 receives the MPD data of the content as a response to the request.
  • the content acquisition unit 51 refers to the received MPD data and transmits a request for transmission of a segment constituting the content to the server 1 or the proxy 3.
  • the content acquisition unit 51 acquires the segment data of the content as a response to the request.
  • the content acquisition unit 51 outputs the acquired segment data to the content reproduction unit 52.
  • the content acquisition unit 51 switches the representation to be acquired when a network delay or the like occurs. At this time, when acquiring a part of the remaining segment next, the content acquisition unit 51 specifies the byte range of the sub-segment including unacquired data, and uses the byte range template based on the specified byte range. The received request is transmitted to the server 1 or the proxy 3.
  • the content playback unit 52 refers to the MPD data and plays back the content based on the acquired segment data.
  • the client storage unit 42 stores programs, data, and the like referred to by the client control unit 41, and may store MPD data, segment data, and the like acquired by the content acquisition unit 51, for example.
  • FIG. 3 is a flowchart illustrating an example of the segment transmission process of the server 1.
  • the server 1 receives an HTTP request message requesting transmission of a segment or a part of a segment from the client 2 (S61).
  • the content transmission unit 22 instructs the content acquisition unit 21 to acquire the segment, and acquires segment data from the content acquisition unit 21. Then, the content transmitting unit 22 transmits the segment to the client 2 in units of chunks, with the subsegment obtained by dividing the segment into a plurality of chunks (S62).
  • the content transmission unit 22 performs transmission in units of chunks, and when the entire requested segment is transmitted (YES in S63), the segment transmission process ends. Or the content transmission part 22 complete
  • FIG. 4 is a flowchart illustrating an example of the segment acquisition process of the client 2.
  • the content acquisition unit 51 refers to the MPD data and transmits a request for requesting transmission of an initial representation segment (for example, a high quality segment) (S71).
  • an initial representation segment for example, a high quality segment
  • the content acquisition unit 51 determines whether to switch the representation (S72). Here, if no network delay or the like has occurred, Representation is not switched (NO in S72), and the segment transferred from the server 1 in units of sub-segments is acquired (S73). The content acquisition unit 51 determines whether or not the entire requested segment has been received (S74). If not all have been received (NO in S74), the process returns to S72.
  • the content acquisition unit 51 switches the representation of the segment to be acquired (YES in S72).
  • the content acquisition unit 51 analyzes the sidx of the switching destination Representation (for example, a low quality segment), and determines the byte range of the unacquired subsegment based on the access point of the unacquired subsegment of the requested segments. Specify (S75).
  • the content acquisition unit 51 generates a byte range template URL indicating an acquisition destination of an unacquired subsegment based on the specified byte range (S76). Based on the generated URL, the content acquisition unit 51 transmits a request for transmission of the remaining data of the segment (data from the middle) (S77). And the content acquisition part 51 acquires the segment of presentation of a switching destination in the chunk unit from the middle (S73).
  • FIG. 5 is a diagram showing a description example of MPD used in the present invention.
  • the MPD 100 used in the present invention differs from the conventional MPD 200 shown in FIG. 10 in the profile information 112 included in the information 110 and the acquisition destination information 130.
  • the profile information 112 describes “urn: mpeg: dash: profile: isoff-low-latency-live: 2012” indicating low-latency live delivery.
  • the acquisition destination information 130 describes a byte range template (BaseURL @ byterange) rather than a simple server URL.
  • the client 2 can acquire a part of content by a byte range request defined in HTTP / 1.1.
  • the proxy 3 since the response from the server 1 to the byte range request has the status code “206”, the proxy 3 does not cache the data included in the response. For this reason, even if the same content is requested to the server 1 again through the proxy 3, it is not cached in the proxy 3, so the server 1 must transmit the content. Therefore, it becomes difficult to stably realize low-latency live streaming.
  • FIG. 13 is a diagram illustrating an example of an operation sequence of a server, a client, and a proxy that transmits and receives a part of content by a byte range request.
  • FIG. 14 is a diagram showing an example of an HTTP message transmitted and received in conventional live streaming.
  • the client refers to the MPD 200 and transmits a request message 301 for requesting transmission of the segment # 1 to the proxy.
  • the proxy receives the request message 301, and since the segment # 1 is not cached, the proxy transfers the request as it is and transmits the request message 302 to the server.
  • the server sends a response message 303 including the data body of segment # 1 to the proxy as a response to the request message 302 because the request message 302 is a request for transmission of the segment. Since the proxy receives the response message 303 and the status code of the response message 303 is “200”, the proxy caches the data included in the response message 303 and transfers the response as it is, and sends the response message 305 to the client. Send. The client receives the response message 305 and acquires segment # 1.
  • the client executes Representation switching 306.
  • the client analyzes sidx and specifies the byte range (xxx to yyy) of the unacquired data of segment # 1.
  • the client transmits a byte range request message 307 to the proxy based on the specified byte range.
  • the proxy receives the request message 307, and since the data indicated by the request is not cached here, the proxy transfers the request as it is and transmits the request message 308 to the server.
  • the server 1 Since the request message 308 is a byte range request, the server 1 returns, as a response to the request message 308, a response message 309 with a status code “206” that includes data of the specified byte range that is part of the segment # 1. Send to proxy.
  • the proxy receives the response message 309, and since the status code of the response message 309 is “206”, the proxy does not cache the data included in the response message 309, transfers the response as it is, and sends the response message 310 to the client. To do.
  • the client receives the response message 310 and acquires the remaining data of the segment # 1.
  • the proxy 3 does not cache.
  • the data cached by the proxy 3 is data included in a response with a status code “200”, “203”, “300”, “301”, or “410”.
  • low-delay live streaming can also be realized by reducing RTT (Round Trip Time) due to a cache hit in proxy 3 as a cache server. Therefore, if there is data that the proxy 3 does not cache, it is difficult to stably realize low-latency live streaming.
  • RTT Red Trip Time
  • a part of the segment is acquired by a request using the above-described byte range template.
  • the proxy 3 can cache the data included in the response.
  • FIG. 6 is a diagram illustrating an example of an operation sequence of the server 1, the client 2, and the proxy 3 that performs low-latency live streaming.
  • FIG. 7 is a diagram illustrating an example of an HTTP message transmitted and received in low-delay live streaming.
  • the client 2 refers to the MPD 70 and transmits a request message 81 for requesting transmission of the segment # 1 to the proxy 3.
  • the proxy 3 receives the request message 81, and since the segment # 1 is not cached, the proxy 3 transfers the request as it is and transmits the request message 82 to the server 1.
  • the server 1 Since the request message 82 requests the transmission of the segment, the server 1 sends a response message 83 including the data body of the segment # 1 divided into chunks in units of sub-segments to the proxy 3 as a response to the request message 82 Send. Since the proxy 3 receives the response message 83 and the status code of the response message 83 is “200”, the proxy 3 caches the data included in the response message 83 and transfers the response as it is to the client 2. 85 is transmitted. The client 2 receives the response message 85 and acquires the segment # 1 that has been chunk-transferred in units of subsegments.
  • the client 2 executes the representation switching 86.
  • the client 2 analyzes sidx and specifies the byte range (xxx to yyy) of the sub-segment including the unacquired data of the segment # 1.
  • the client 2 transmits a request message 87 using the byte range template to the proxy 3 based on the specified byte range instead of the byte range request.
  • the proxy 3 receives the request message 87, and since the data indicated by the request is not cached here, the proxy 3 transfers the request as it is and transmits the request message 88 to the server 1.
  • the server 1 Since the request message 88 is not a byte range request but a normal request, the server 1 responds to the request message 88 with a status code “200” response message including sub-segments of the specified byte range in units of chunks. 89 is sent to the proxy 3. Since the proxy 3 receives the response message 89 and the status code of the response message 89 is “200”, the proxy 3 caches the data included in the response message 89 and transfers the response as it is to the client 2. 91 is transmitted. The client 2 receives the response message 91 and acquires the remaining data of the segment # 1 in units of chunks.
  • the segment is further divided into a plurality of sub-segments, but the time length of this sub-segment may be arbitrary. That is, the time length of each subsegment may be constant, or the time length of each subsegment may be different.
  • the time length of the sub-segment matches the time length of one chunk.
  • the client 2 can predict the amount of delay in live streaming by grasping the chunk time length in advance. Therefore, it is preferable that the chunk time length is described in MPD.
  • the chunk time length is fixed, for example, the chunk time length may be described in the MPD.
  • the chunk time length is variable, for example, the maximum value and / or the minimum value of the chunk time length may be described in MPD. A description example of the chunk time length will be described later.
  • the boundaries of the corresponding sub-segments are aligned between the representations.
  • the reproduction start times of the corresponding subsegments coincide between Representations. In this case, even if the representation is switched, the reproduction times of the sub-segments are the same, so that the reproduction can be performed without any particular problem.
  • FIG. 8 is a diagram showing another description example of the MPD used in the present invention.
  • FIG. 8 shows an example of MPD in which information on the arrangement of sub-segments and information on the chunk time length are described.
  • the MPD 101 used in the present invention additionally includes information on the sub-segment arrangement and information on the chunk time length as compared with the MPD 100 shown in FIG. 5.
  • an attribute “AdaptationSet @ subsegmentAlignment” and its attribute value “true” are described as information 150 regarding the subsegment arrangement.
  • the attribute value “true” indicates that the boundaries of the sub-segments are aligned. If the boundaries of the sub-segments are not aligned, “false” is described as the attribute value.
  • the attribute “maxChunkDuration” and the attribute value “PT10S” are described in the high quality segment information 143 and the low quality segment information 144 as information on the chunk time length.
  • the attribute “maxChunkDuration” indicates the maximum value of the variable chunk time length, and the attribute value “PT10S” indicates that the maximum value is 10 seconds.
  • the attribute “chunkDuration” indicating the fixed chunk time length may be described as the information on the chunk time length, and the attribute “minChunkDuration” indicating the minimum value of the variable chunk time length is described. Also good.
  • the attribute “chunkDuration” may be interpreted as the time length of the first chunk of the segment. Or, instead of the attribute “chunkDuration”, the difference between the segment length (equal to the value of the attribute “SegmentList @ duration”) and the first chunk duration of the segment (equal to the value of the attribute “SegmentList @ chunkDuration”) An attribute “chunkDurationOffset” indicating a value may be described.
  • FIG. 9 is a diagram illustrating a data structure of segment data of a high quality segment and a low quality segment in which the boundaries of the sub-segments are not aligned.
  • the high-quality segment 160 of 1024 kbps includes a sub-segment # 0 composed of moof 163 and mdat 164, a sub-segment # 1 composed of moof 165 and mdat 166, and sub-segments composed of moof 167, 169 and mdat 168, 180. Segment # 2 is included.
  • the low quality segment 180 of 512 kbps includes sub-segment # 0 composed of moof 183 and mdat 184, sub-segment # 1 composed of moof 185, 187 and mdat 186 and 188, and sub-segment # 2 composed of moof 189 and mdat 190. That is, the playback start time of sub-segment # 2 differs between high quality segment 160 and low quality segment 180.
  • the time lengths of the fragments (moof and mdat) included in the high quality segment 160 and the low quality segment 180 are constant. That is, the high-quality segment fragments 163 to 170 correspond to the low-quality segment fragments 183 to 190, respectively.
  • the representation is switched to acquire the low-quality segment.
  • the next data to be acquired is the moof 187 of the low quality segment corresponding to the moof 167 of the high quality segment.
  • moof 185, 187 and mdat 186, 188 are sub-segment # 1, and therefore, only moof 187 and later cannot be acquired. Therefore, acquisition is started from subsegment # 1 including moof 187 which is unacquired data so that a gap does not occur during reproduction.
  • moof 185 and mdat 186 are acquired in a time-overlapping manner, but smooth live streaming is realized by adjusting during reproduction.
  • time information of each sub-segment is described in the segment headers sidx 162 and 182, and the byte range is specified by analyzing sidx.
  • the content transmission apparatus is content that includes a plurality of segments, and includes content in which the time information of sub-segments obtained by further dividing the segment is described in the header of the segment
  • a content transmission device that transmits to a playback device, and when receiving a request from the content playback device, the content transmission device includes a transmission unit that transmits a response to the content playback device as a response to the request.
  • the segment is chunk-transferred to the content reproduction device in units of sub-segments.
  • a method for controlling a content transmission device which is content composed of a plurality of segments, and in the header of the segment, time information of a sub-segment obtained by further dividing the segment is described.
  • a method for controlling a content transmission apparatus for transmitting content to a content reproduction apparatus comprising: a transmission step of transmitting a response to the content reproduction apparatus as a response to the request when a request is received from the content reproduction apparatus; In the step, when the request is for requesting transmission of a segment, the segment is chunk-transferred to the content reproduction device in units of sub-segments.
  • the transmission means in response to a request for requesting transmission of a segment, performs chunk transfer in units of subsegments obtained by further dividing the segment. That is, the transmission unit can be transmitted in units of sub-segments that are shorter in time than the segment, and transmission of a plurality of sub-segments can be requested with one request. For this reason, it is possible to suppress the error processing associated with the pipelining of a plurality of requests while shortening the time from the start of generation of the sub-segments until the distribution becomes possible. Therefore, it is possible to stably realize low-latency live streaming.
  • the segment may be divided into the sub-segments so that random access can be performed in units of the sub-segments.
  • the transmission means transmits content management information describing the time length of the sub-segment to the content reproduction device when the time length of each sub-segment is constant. May be.
  • the transmission means includes content management in which at least one of the maximum value and the minimum value of the time length of the sub-segment is described when the time length of each sub-segment is different Information may be transmitted to the content reproduction apparatus.
  • the delay amount in live streaming can be predicted.
  • the content reproduction apparatus is content configured by a plurality of segments, and content in which time information of sub-segments obtained by further dividing the segment into a plurality of segments is described in the header of the segment Is obtained from a content transmission device and is reproduced, and includes an acquisition unit that transmits a request for transmitting a segment to the content transmission device, and the acquisition unit receives the request as a response to the request.
  • the segment that has been chunk-transferred in units of sub-segments is acquired from the content transmission device.
  • the method for controlling a content playback device includes content composed of a plurality of segments, and the time information of a sub-segment obtained by further dividing the segment into a plurality of segments is described in the header of the segment
  • a method for controlling a content playback device that acquires and plays back content that has been received from a content transmission device, wherein the content transmission device transmits a request for transmission of a segment, and a response to the request includes: An acquisition step of acquiring the segment that has been chunk-transferred in units of the sub-segments from the content transmission device.
  • Example 2 As the delay occurring on the network between the server and the client, in the first embodiment, when an error occurs due to the resource requested by the client not existing in the server, the network and There was a problem that the client was overloaded and delayed. As a delay occurring in the client, there is a problem that a delay occurs due to a load applied during the decoding process because the processing capability of the decoder of the client is low.
  • FIG. 15 is a diagram illustrating an example of a configuration of a transmission stream according to the present embodiment.
  • FIG. 16 is a block diagram illustrating the main configuration of the server and the client according to the present embodiment.
  • FIG. 17 is a diagram illustrating a process in which a stream obtained by multiplexing a plurality of frame rate data according to the present embodiment is separated on the receiving side.
  • FIG. 18 is a diagram illustrating pictures and hierarchy levels in the content according to the present embodiment.
  • a broadcast station corresponding to a server stores a plurality of data such as video, audio, and other program information in a plurality of packets, and multiplexes them into one stream for transmission.
  • MPEG-2 TS transport stream
  • the multiplexed transport stream (TS) is separated into respective packets by a broadcast receiver corresponding to the client, and data such as video and audio is acquired.
  • FIG. 15A shows the structure of a conventional TS.
  • the TS is composed of a set of TS packets each having 188 bytes, and these TS packets are input to the client in time series.
  • the header of each TS packet is given a PID (Packet Identifier) indicating the type of data in the packet, as shown in FIG. 15 (a).
  • PID Packet Identifier
  • Data, audio, and related information stored in the payload can be identified and separated, and data can be input to an appropriate decoder.
  • the same PID is assigned to a packet in which video data composed of a plurality of scalable encoded video qualities is separated and stored.
  • the client can separate the video quality data into a plurality of video quality data at the stage of the decoding process. That is, one video data is always transmitted by one PID.
  • each frame can be compressed as a picture with a different prediction method such as I, P, B, and stored in separate packets.
  • a prediction method such as I, P, B
  • a RefPID dependingency identifier
  • a flag isRef indicates whether or not the packet includes RefPID.
  • isRef is a binary flag. When it is 1, it indicates that RefPID is included, and when it is 0, it indicates that RefPID is not included.
  • FIG. 16 is a block diagram showing the main configuration of the present embodiment.
  • the server includes a multiplexing unit that multiplexes a plurality of packets
  • the client includes a demultiplexing unit that separates a stream in which the plurality of packets received from the server are multiplexed into individual packets. ing.
  • description regarding similar members will be omitted as appropriate.
  • the server transmission unit transmits data to the client by wireless communication means or wired communication means.
  • the server control unit includes a content generation unit, a multiplexing unit, and a content transmission unit (transmission means) as functional blocks.
  • the content generation unit generates content data
  • the multiplexing unit performs separation and multiplexing into packets, and outputs them to the content transmission unit.
  • a packet storing I and P picture data is assigned a PID value pid_b
  • a packet storing B picture data is assigned a value pid_a.
  • a packet storing B picture data is assigned a RefPID having a value pid_b with the value of isRef being 1.
  • the client receiving unit receives data from the server by wireless communication means or wired communication means.
  • the client control unit includes a content acquisition unit (acquisition means), a demultiplexing unit, and a content reproduction unit as functional blocks.
  • the content acquisition unit acquires the multiplexed stream sent from the server, and outputs it to the demultiplexing unit.
  • the demultiplexing unit separates the multiplexed stream into respective packets. At this time, by referring to the value of PID, it is separated into packets of video, audio, program information and the like.
  • the demultiplexing unit further determines whether the packet includes RefPID, and if the packet includes RefPID, interprets the packet data and the packet data indicated by RefPID as one content data. . Then, the data of each content separated by the multiplexing / separating unit is input to the content reproducing unit.
  • the packet data and the packet data indicated by RefPID store transmission time information (not shown) in each packet header, and the order can be uniquely determined by looking at the transmission time information.
  • a sequence number (not shown) may be stored in the packet header, and the order may be uniquely determined from the sequence number.
  • the content reproduction unit sequentially decodes the video packet data separated by the demultiplexing unit into a video signal according to the PID and RefPID, rearranges the decoded picture data in the display order as appropriate, and then displays the video data on the display unit. Output each.
  • FIG. 17 receives and receives streams multiplexed by storing I, P picture data, and B picture data in a packet having a PID value of pid_b and a packet having a PID value of pid_a, respectively.
  • FIG. 6 is a diagram illustrating that the multiplexed stream is multiplexed and separated into content data having different frame rates based on PID and RefPID in a client demultiplexing unit.
  • the I and P picture data is encoded data at a frame rate of 60 Hz.
  • B picture data is additional data for reproducing at 120 Hz by sandwiching one B picture between pictures of I and P picture data.
  • pid_a since the RefPID of pid_a is pid_b, 120 Hz video is reproduced by outputting all packets of pid_a and pid_b to the video decoder. On the other hand, when only pid_b is output to the video decoder, 60 Hz video is reproduced.
  • isRef and RefPID are added to the packet header.
  • the storage location is not limited to this, and for example, the MPD storage shown in FIG. It may be described in the MPD stored in the device. Alternatively, it may be described as part of transmission information related to transmission of content other than MPD and metadata of playback information related to content playback. Alternatively, information indicating that the content is the same content may be described in the PID value itself, and the RefPID may not be added by the PID also serving as the RefPID. Also, a configuration in which RefPID is essential and isRef is omitted is possible.
  • FIG. 19A shows an example in which isRef and RefPID are stored in transmission information (program configuration table) based on PAT / PMT (Program Association Table / Program Map Table) currently used in digital broadcasting.
  • transmission information program configuration table
  • PMT Program Map Table
  • FIG. 19B shows an example in which a plurality of PIDs are described in a video.
  • FIG. 19B it is shown that the video is composed of data to which two PIDs are added, and the PID written behind is interpreted as being dependent on the PID written before.
  • the demultiplexing unit of the client knows the PID of the necessary data and separates and reproduces only the packet data to which the PID is assigned from the multiplexed stream.
  • the client can identify packets including the same content having different PIDs in the multiplexed stream, and can acquire and decode necessary packet data according to the decoding capability.
  • Layer stream data and high-resolution enhancement layer stream data are stored in separate PID packets and identified using PID and RefPID, so clients with low decoding capability obtain base layer data and play back low-resolution video
  • a client having a high decoding capability can also perform processing such as acquiring base and enhancement layer data and reproducing high-resolution video. By extracting data with an appropriate frame rate and resolution according to the decoding capability, it is possible to eliminate the delay that occurs during decoding.
  • PID and RefPID are not limited to the above example.
  • a PID with a value pid_0 is assigned to a packet of a B picture in layer 1
  • a PID with values pid_2 and pid_3 is assigned to a packet with a B picture in layers 2 and 3 It may be given.
  • a RefPID having a value pid_0 is assigned to a packet of a B picture in layer 1
  • a RefPID having values pid_1 and pid_2 is assigned to a packet of a B picture in layers 2 and 3.
  • the acquisition unit acquires a segment that has been chunk-transferred in units of subsegments obtained by further dividing the segment. That is, the transmission unit can be transmitted in units of sub-segments that are shorter in time than the segment, and transmission of a plurality of sub-segments can be requested with one request. For this reason, it is possible to suppress the error processing associated with the pipelining of a plurality of requests while shortening the time from the start of generation of the sub-segments until the distribution becomes possible. Therefore, it is possible to stably realize low-latency live streaming.
  • the segments may be divided into the sub-segments so that random access can be performed in units of the sub-segments.
  • the acquisition unit when the acquisition unit transmits a request for requesting transmission of a part of a segment, the acquisition unit specifies a byte range of a sub-segment including the part of the segment, A request using a byte range template that specifies the specified byte range may be transmitted.
  • the acquisition unit transmits a request using a byte range template when transmitting a request for requesting transmission of a part of a segment
  • the status code of a response to the request is “200”. It becomes. Therefore, when acquiring content via a proxy that is a content relay device, the proxy can cache the data included in the response. Therefore, RTT can be reduced and low-delay live streaming can be realized stably.
  • a content distribution system includes the content transmission device and the content reproduction device.
  • the content distribution system has the same effects as the content transmission device and the content reproduction device.
  • the data structure of the content management information including the acquisition source information indicating the acquisition destination of the content in which the byte range template is described is also included in the category of the present invention.
  • the content transmission device and the content reproduction device may be realized by a computer.
  • the content transmission device is operated by causing the computer to operate as each unit of the content transmission device and the content reproduction device.
  • a control program for realizing the content reproduction apparatus on a computer and a computer-readable recording medium on which the program is recorded also fall within the scope of the present invention.
  • each block of the server 1 and the client 2, particularly the server control unit 11 and the client control unit 41, may be realized in hardware by a logic circuit formed on an integrated circuit (IC chip), or a CPU (Central Processing Unit) may be used for software implementation.
  • IC chip integrated circuit
  • CPU Central Processing Unit
  • the server 1 and the client 2 include a CPU that executes instructions of a program that realizes each function, a ROM (Read Memory) that stores the program, a RAM (Random Access Memory) that expands the program, and the program And a storage device (recording medium) such as a memory for storing various data.
  • An object of the present invention is a recording medium in which program codes (execution format program, intermediate code program, source program) of control programs for the server 1 and the client 2 which are software for realizing the functions described above are recorded so as to be readable by a computer. Can also be achieved by reading the program code recorded on the recording medium and executing it by the computer (or CPU or MPU).
  • Examples of the recording medium include non-transitory tangible media, such as magnetic tapes and cassette tapes, magnetic disks such as floppy (registered trademark) disks / hard disks, and CD-ROM / MO.
  • Discs including optical disks such as / MD / DVD / CD-R, cards such as IC cards (including memory cards) / optical cards, and semiconductor memories such as mask ROM / EPROM / EEPROM (registered trademark) / flash ROM
  • logic circuits such as PLD (Programmable logic device) and FPGA (Field Programmable Gate array) can be used.
  • the server 1 and the client 2 may be configured to be connectable to a communication network, and the program code may be supplied via the communication network.
  • the communication network is not particularly limited as long as it can transmit the program code.
  • the Internet intranet, extranet, LAN, ISDN, VAN, CATV communication network, virtual private network (Virtual Private Network), telephone line network, mobile communication network, satellite communication network, etc. can be used.
  • the transmission medium constituting the communication network may be any medium that can transmit the program code, and is not limited to a specific configuration or type.
  • wired lines such as IEEE1394, USB, power line carrier, cable TV line, telephone line, ADSL (Asymmetric Digital Subscriber Line) line, infrared rays such as IrDA and remote control, Bluetooth (registered trademark), IEEE 802.11 wireless, HDR ( It can also be used wirelessly such as High Data Rate, NFC (Near Field Communication), DLNA (Digital Living Network Alliance) (registered trademark), a mobile phone network, a satellite line, and a terrestrial digital network.
  • the present invention can also be realized in the form of a computer data signal embedded in a carrier wave in which the program code is embodied by electronic transmission.
  • the present invention can be used for a content transmission device that transmits content of the MPEG-DASH standard and a content playback device that acquires and plays back the content.

Landscapes

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

Abstract

　クライアント（２）からセグメントの送信を要求するリクエストを受信すると、当該セグメントをさらに複数に分割したサブセグメント単位で、当該セグメントをクライアント（２）にチャンク転送するコンテンツ送信部（２２）を備える。

Description

コンテンツ送信装置、コンテンツ再生装置、コンテンツ配信システム、コンテンツ送信装置の制御方法、コンテンツ再生装置の制御方法、制御プログラムおよび記録媒体
　本発明は、コンテンツを送信するコンテンツ送信装置、コンテンツを取得・再生するコンテンツ再生装置、コンテンツ配信システム、コンテンツ送信装置の制御方法、コンテンツ再生装置の制御方法、制御プログラムおよび記録媒体に関するものである。
　インターネットの普及やコンピュータの高性能化に伴い、インターネットを介して動画像などの大容量コンテンツを配信することが広く行われている。例えば、ユーザの要求に応じて動画等のコンテンツを提供するＶＯＤ（Video On Demand）というサービスがある。ＶＯＤでは、例えば、特許文献１に記載されているように、ＨＴＴＰ（HyperText Transfer Protocol）を用いて、サーバ（コンテンツ提供装置）とクライアント（コンテンツ再生装置）との間でデータを送受信する。
　ここで、ＨＴＴＰによるコンテンツの配信に関して、様々な技術が開発されている。例えば、ＭＰＥＧ（Motion Picture Experts Group）は、ＨＴＴＰを利用した適応ストリーミング技術をＭＰＥＧ－ＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）規格として国際標準化を進めている。
　ＭＰＥＧ－ＤＡＳＨでは、コンテンツは、複数のセグメント（segment）に時分割され、セグメント単位で伝送される。また、各セグメントは、１または複数のフラグメント（fragment）で構成される。また、コンテンツは、１または複数のピリオド（period）で構成されており、１つのピリオドに１または複数のセグメントが含まれる。
　また、ＭＰＥＧ－ＤＡＳＨでは、１つのコンテンツに対して品質種別（ビットレート、画像解像度等の再生品質や、データフォーマット等の種別）が異なる複数のRepresentationが準備される。例えば、セグメント毎に異なるビットレートで符号化した複数のセグメントデータを準備する。これにより、コンテンツを受信して再生するクライアントは、コンテンツの受信状況等に応じて、要求するコンテンツ（セグメント）のビットレートを変えることにより、適応ストリーミングを実行することができる。
　また、ＭＰＥＧ－ＤＡＳＨでは、コンテンツにＭＰＤ（Media Presentation Description）が対応付けられており、ＭＰＤによってコンテンツを管理する。ＭＰＤは、コンテンツのメタデータであって、コンテンツの管理情報をＸＭＬ形式で記述したものである。換言すると、ＭＰＤは、クライアントがコンテンツの取得・再生時に利用する情報である。
　ＭＰＤの具体的な記述例を図１０に基づいて説明する。図１０は、ＭＰＤの記述例を示す図である。図１０に示すように、ＭＰＤ２００には、タイプ情報２１１、プロファイル情報２１２、バッファリング時間情報２１３、配信開始時刻情報２１４を含む情報２１０が記述されている。
　タイプ情報２１１は、ライブ配信であるかオンデマンド配信であるかを示す情報（属性「type」の属性値）である。図示の例では、属性「type」の属性値が「dynamic」であり、このＭＰＤ２００が対応付けられたコンテンツがライブ配信コンテンツであることを示す。一方、オンデマンド配信の場合、属性「type」の属性値に「static」が記述される。
　プロファイル情報２１２は、コンテンツのプロファイルを示す情報である。また、バッファリング時間情報２１３は、最小のバッファリング時間を示す情報である。図示の例では、属性「minBufferTime」の属性値が「PT10S」であるため、クライアントは少なくとも１０秒のバッファリングを行うことを示す。
　配信開始時刻情報２１４は、サーバがコンテンツのライブストリーミング配信を開始する時刻を示す情報（属性「availabilityStartTime」の属性値）である。図示の例では、属性「availabilityStartTime」の属性値が「2012-09-20T15:00:00」であり、２０１２年９月２０日１５時にライブストリーミング配信が開始されることを示す。
　また、ＭＰＤ２００には、コンテンツの再生期間を区切った各ピリオドに関するピリオド情報２２０が記述されている。図示の例では、ピリオド情報２２０として、コンテンツの配信開始時刻を基準とした場合のそのピリオドの開始時刻（属性「start」の属性値）およびそのピリオドの期間（属性「duration」の属性値）が記述されている。
　また、コンテンツの取得先を示す取得先情報２３０が記述されている。図示の例では、取得先情報２３０として、サーバのＵＲＬが記述されている。
　また、ここでは、コンテンツとして、ビットレートが1024kbpsの高品質Representationと、ビットレートが512kbpsの低品質Representationが用意されているものとする。そのため、ＭＰＤ２００には、或るピリオド（再生時刻０秒から３６００秒まで）に含まれるセグメントとして、高品質セグメントを示す高品質セグメント情報２４１と、低品質セグメントを示す低品質セグメント情報２４２とが記述されている。高品質セグメント情報２４１には、当該ピリオドに含まれる高品質RepresentationのＩＤおよびビットレートが記述されている。また、当該ピリオドに含まれる各セグメントの長さおよびＵＲＬが記述されている。また、低品質セグメント情報２４２も同様である。なお、当該ピリオドは、セグメント＃１～セグメント＃６の６個のセグメントで構成されている。
　次に、従来の基本的なセグメントデータのデータ構造について図１１に基づいて説明する。図１１は、従来における、高品質セグメントおよび低品質セグメントのセグメントデータのデータ構造を示す図である。ここでは、セグメントデータがＩＳＯＢＦＦ（ISO/IEC 14496-12）で規定されるbox形式で記述されている例を説明する。
　図１１（ａ）に示すように、従来の高品質セグメントデータ２６０は、１つのstyp（Segment Type Box）２６１、１つのsidx（Segment Index Box）２６２、並びに、moof（Movie Fragment Box）２６３、２６５、２６７および２６９と、mdat（Media Data Box）２６４、２６６、２６８および２７０との１つまたは複数の組から構成される。また、図１１（ｂ）に示すように、低品質セグメントデータ２８０も、高品質セグメントデータ２６０と同様に、１つのstyp２８１、１つのsidx２８２、並びに、moof２８３、２８５、２８７および２８９と、mdat２８４、２８６、２８８および２９０との１つまたは複数の組から構成される。
　styp２６１およびstyp２８１は、セグメントの種別および／またはバージョン情報等を示す情報である。sidx２６２およびsidx２８２は、セグメント内のランダムアクセスポイントに関する情報である。moof２６３、２６５、２６７および２６９、並びに、mdat２６４、２６６、２６８および２７０と、moof２８３、２８５、２８７および２８９、並びに、mdat２８４、２８６、２８８および２９０とは、セグメントを構成するフラグメントに関する情報である。
　moofおよびmdatの１つの組が１つのフラグメントを構成する。また、１つまたは複数のフラグメントから構成され、ランダムアクセスに適応するようにセグメントを分割した単位をサブセグメント（subsegment）とする。例えば、図１１の例では、moof２６３、２６５およびmdat２６４、２６６が１つのサブセグメントを構成する。sidxの各エントリ２７１、２７２、２９１および２９２（図１１（ａ）および（ｂ）に示す「ｓ０」、「ｓ１」）には、各サブセグメントのバイトサイズ、時間情報などが記述されている。
　次に、sidxのシンタックスの一例を図１２に基づいて説明する。図１２は、sidxのシンタックスの一例を示す図である。ここでは、sidxは、ISO/IEC 14496-12で定義されている例を示す。
　このように、ＭＰＥＧ－ＤＡＳＨでは、サーバでのセグメントの生成開始から配信可能になるまでの時間を短縮するために、セグメントの時間長を小さくして低遅延ライブストリーミングに対応することを想定している。なお、サーバおよびクライアントによる処理遅延やネットワーク上の遅延等が発生するため、クライアントが厳密にリアルタイムに再生することは不可能である。そのため、わずかに遅延しているが、実質的にリアルタイムでのライブストリーミングを低遅延ライブストリーミングと称する。
日本国公開特許公報「特開２００５－１１０２４４号公報（２００５年４月２１日公開）」
"ISO/IEC 23009-1"、[online]、２０１２年４月１日、ISO/IEC、[平成２４年９月２６日検索]、インターネット＜ＵＲＬ：http://standards.iso.org/ittf/PubliclyAvailableStandards/c057623_ISO_IEC_23009-1_2012.zip＞
　上述のように、ＭＰＥＧ－ＤＡＳＨでは、セグメントの時間長を短くすることで低遅延ライブストリーミングを実現しようとするものであるが、セグメントの時間長を短くすることで遅延が生じる場合がある。具体的には、セグメントの時間長が短い場合、通常、ネットワークジッタに対応するために、セグメントの送信を要求する複数のリクエストをパイプライン化して送信する。このとき、リクエストしたリソースがサーバに存在しないこと等によりエラーが発生した場合、再度複数のリクエストを送信しなければならず、再リクエストにより遅延が発生するという問題がある。
　本発明は、上記の問題点に鑑みてなされたものであり、その目的は、安定的に低遅延ライブストリーミングを実行するコンテンツ送信装置、コンテンツ再生装置、コンテンツ配信システム、コンテンツ送信装置の制御方法、コンテンツ再生装置の制御方法、制御プログラムおよび記録媒体を実現することにある。
　上記の課題を解決するために、本発明の一態様に係るコンテンツ送信装置は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ再生装置に送信するコンテンツ送信装置であって、上記コンテンツ再生装置からリクエストを受信すると、当該リクエストに対する応答として、レスポンスを当該コンテンツ再生装置に送信する送信手段を備え、上記送信手段は、上記リクエストがセグメントの送信を要求するものである場合、当該セグメントを上記コンテンツ再生装置に、上記サブセグメント単位でチャンク転送する。
　また、上記の課題を解決するために、本発明の一態様に係るコンテンツ送信装置の制御方法は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ再生装置に送信するコンテンツ送信装置の制御方法であって、上記コンテンツ再生装置からリクエストを受信すると、当該リクエストに対する応答として、レスポンスを当該コンテンツ再生装置に送信する送信ステップを含み、上記送信ステップにおいて、上記リクエストがセグメントの送信を要求するものである場合、当該セグメントを上記コンテンツ再生装置に、上記サブセグメント単位でチャンク転送する。
　さらに、上記の課題を解決するために、本発明の一態様に係るコンテンツ再生装置は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ送信装置から取得して再生するコンテンツ再生装置であって、上記コンテンツ送信装置に、セグメントの送信を要求するリクエストを送信する取得手段を備え、上記取得手段は、上記リクエストに対する応答として、上記コンテンツ送信装置から、上記サブセグメント単位でチャンク転送された上記セグメントを取得する。
　さらに、上記の課題を解決するために、本発明の一態様に係るコンテンツ再生装置の制御方法は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ送信装置から取得して再生するコンテンツ再生装置の制御方法であって、上記コンテンツ送信装置に、セグメントの送信を要求するリクエストを送信する送信ステップと、上記リクエストに対する応答として、上記コンテンツ送信装置から、上記サブセグメント単位でチャンク転送された上記セグメントを取得する取得ステップとを含む。
　本発明の一態様によれば、低遅延ライブストリーミングを安定的に実現することができる。
本発明の実施形態を示すものであり、サーバおよびクライアントの要部構成を示すブロック図である。 上記サーバおよびクライアントを含むコンテンツ配信システムの概要を示す図である。 上記サーバが実行するセグメント送信処理の一例を示すフローチャートである。 上記クライアントが実行するセグメント取得処理の一例を示すフローチャートである。 本発明で用いるＭＰＤの記述例を示す図である。 低遅延ライブストリーミングを実行する上記サーバ、上記クライアントおよびプロキシの動作シーケンスの一例を示す図である。 低遅延ライブストリーミングにおいて送受信されるＨＴＴＰメッセージの一例を示す図である。 本発明で用いるＭＰＤの他の記述例を示す図である。 各サブセグメントの境界が揃っていない高品質セグメントおよび低品質セグメントのセグメントデータのデータ構造を示す図である。 従来のＭＰＤの記述例を示す図である。 従来における、高品質セグメントおよび低品質セグメントのセグメントデータのデータ構造を示す図である。 従来技術を示すものであり、sidxのシンタックスの一例を示す図である。 従来技術を示すものであり、バイトレンジリクエストによってコンテンツの一部を送受信するサーバ、クライアントおよびプロキシの動作シーケンスの一例を示す図である。 従来のライブストリーミングにおいて送受信されるＨＴＴＰメッセージの一例を示す図である。 伝送ストリームの構成の例を示す図である。 本発明の別の実施形態に係るサーバおよびクライアントの要部構成を示すブロック図である。 多重化ストリームが受信側で分離される過程を示す図である。 コンテンツ内のピクチャと階層レベルの例を示す図である。 伝送情報（プログラム構成テーブル）にｉｓＲｅｆ、ＲｅｆＰＩＤを格納した例を示す図である。
　本発明の一実施形態について図１から図１４に基づいて説明すると以下の通りである。まず、本実施形態のコンテンツ配信システムの概要について、図２に基づいて説明する。
　〔コンテンツ配信システムの概要〕
　図２は、本実施形態に係るコンテンツ配信システム６の概要を示す図である。図２に示すように、コンテンツ配信システム６は、サーバ１、クライアント２、プロキシ３、ＭＰＤ記憶装置４およびセグメント記憶装置５を含む。
　図２に示すように、クライアント２は、プロキシ３を介して、サーバ１と接続する。また、サーバ１は、ＭＰＤ記憶装置４およびセグメント記憶装置５と接続する。各装置は、有線通信または無線通信の任意のネットワークで接続される。
　サーバ１は、クライアント２またはプロキシ３からコンテンツの送信の要求を受けて、コンテンツを送信するコンテンツ送信装置である。サーバ１は、コンテンツのデータ本体（セグメントデータ）を送信する前に、予めＭＰＤデータをクライアント２またはプロキシ３に送信する。なお、サーバ１は、ネットワーク７上のＭＰＤ記憶装置４およびセグメント記憶装置５からＭＰＤデータおよびセグメントデータを取得するものであるが、これに限るものではない。例えば、各サーバ１は、ローカルでＭＰＤデータおよびセグメントデータを保持していてもよい。
　クライアント２は、サーバ１等の他の装置から取得したコンテンツ、または、自装置に格納しているコンテンツを再生するコンテンツ再生装置である。クライアント２は、例えば、デジタルテレビ、レコーダ、ＳＴＢ（Set Top Box）、ＰＣ、携帯電話機、スマート
フォン、ゲーム機、ＰＤＡ（Personal Digital Assistant）、デジタルカメラ、デジタルビデオ等である。
　プロキシ３は、或る装置（サーバ１またはクライアント２）から取得したデータを他の装置（クライアント２またはサーバ１）へ転送する中継装置である。例えば、プロキシ３は、クライアント２から取得したリクエストをサーバ１に転送し、サーバ１から取得したコンテンツをクライアント２に転送する。
　また、プロキシ３は、サーバ１から取得したデータ（ＭＰＤおよびコンテンツ）をキャッシュするため、キャッシュサーバ（Cache Server）とも言える。なお、プロキシ３をキャッシュサーバと称する場合、サーバ１は、オリジンサーバ（Origin Server）と称する
。このとき、プロキシ３は、クライアント２からリクエストを取得し、当該リクエストの示すコンテンツを保持している場合、当該コンテンツを読み出し、クライアント２へ当該コンテンツを送信してもよい。
　また、コンテンツ配信システム６の構成は図２に示す例に限るものではない。例えば、コンテンツ配信システム６は、サーバ１を複数含んでいてもよいし、クライアント２を複数含んでいてもよい。また、コンテンツ配信システム６は、プロキシ３を複数含んでいてもよい。
　また、本実施形態では、コンテンツ配信システム６におけるネットワーク上の伝送プロトコルは、ハイパーテキスト転送プロトコルとして広く用いられているＨＴＴＰを用いるものとする。また、サーバ１が配信するコンテンツは、映像コンテンツであり、コンテンツは、セグメント化されたＩＳＯＢＦＦデータであるものとする。すなわち、本実施形態では、コンテンツ配信システム６は、上述のＭＰＥＧ－ＤＡＳＨ規格に基づくコンテンツを配信するものである。
　また、本発明で扱うコンテンツは、複数のセグメントから構成されるものであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツである。サブセグメントの時間情報とは、サブセグメントの時間的な位置を示す情報であり、例えば、サブセグメントの再生開始時刻を示す情報である。また、本発明では、セグメントをサブセグメントに分割する単位は任意でよいが、例えば、サブセグメント単位でランダムアクセスできるように、セグメントがサブセグメントに分割されていてもよい。換言すると、セグメントのヘッダに、サブセグメントの時間情報として、ランダムアクセスポイントの時間的な位置を示す情報が記述されていてもよい。
　〔各装置の構成〕
　次に、図１に基づいて、サーバ１およびクライアント２の要部構成について説明する。図１は、サーバ１およびクライアント２の要部構成の一例を示す図である。なお、図１では、プロキシ３を省略している。
　（サーバについて）
　図１に示すように、サーバ１は、サーバ制御部１１、サーバ記憶部１２およびサーバ通信部１３を備える構成である。
　サーバ通信部１３は、無線通信手段または有線通信手段によって、クライアント２、プロキシ３、ＭＰＤ記憶装置４およびセグメント記憶装置５等の他の装置と通信を行い、サーバ制御部１１の指示に従って、データのやりとりを行うものである。
　サーバ制御部１１は、サーバ記憶部１２から一時記憶部（不図示）に読み出されたプログラムを実行することにより、各種の演算を行うと共に、サーバ１が備える各部を統括的に制御するものである。
　本実施形態では、サーバ制御部１１は、機能ブロックとして、コンテンツ取得部２１およびコンテンツ送信部（送信手段）２２備える構成である。サーバ制御部１１の各機能ブロック（２１、２２）は、ＣＰＵ（central processing unit）が、ＲＯＭ（read only memory）等で実現された記憶装置に記憶されているプログラムをＲＡＭ（random access memory）等で実現された一時記憶部に読み出して実行することで実現できる。
　コンテンツ取得部２１は、コンテンツ送信部２２からの指示に基づいて、ＭＰＤ記憶装置４からＭＰＤデータまたはセグメント記憶装置５からセグメントデータを取得するものである。コンテンツ取得部２１は、取得したＭＰＤデータまたはセグメントデータをコンテンツ送信部２２に出力する。
　なお、コンテンツ取得部２１は、コンテンツ送信部２２からの指示の有無に関わらず、事前に、ＭＰＤデータおよび／またはセグメントデータを取得していても良い。この場合、コンテンツ取得部２１は、事前に取得したＭＰＤデータおよびセグメントデータをサーバ記憶部１２に格納しておき、コンテンツ送信部２２からの指示に基づいて、サーバ記憶部１２からＭＰＤデータおよびセグメントデータを読み出す。
　コンテンツ送信部２２は、クライアント２からリクエストを受信すると、受信したリクエストがセグメントの送信を要求するリクエストであるか否かを判定する。受信したリクエストがセグメントの送信を要求するリクエストである場合、コンテンツ送信部２２は、当該セグメントを取得するようにコンテンツ取得部２１に指示して、コンテンツ取得部２１からセグメントデータを取得し、当該セグメントデータを含むレスポンスをクライアント２に送信する。
　ただし、本発明では、コンテンツ送信部２２は、セグメントデータを送信する際、セグメントデータを一度に全て送信するのではなく、セグメントをさらに複数に分割したサブセグメントを１チャンクとして、チャンク単位で送信する。
　一方、受信したリクエストがセグメントの送信を要求するリクエストではない場合、リクエストに対するレスポンスを当該クライアント２に送信する。例えば、クライアント２からコンテンツ管理情報（ＭＰＤ）の送信を要求するリクエストを受信すると、当該コンテンツのＭＰＤを取得するようにコンテンツ取得部２１に指示し、コンテンツ取得部２１からＭＰＤデータを取得すると、取得したＭＰＤデータを含むレスポンスをクライアント２に送信する。また、クライアント２からWebページ等のリソースの送信を要求するリクエストを受信すると、当該リソースを取得するようにコンテンツ取得部２１に指示し、コンテンツ取得部２１からリソースを取得すると、取得したリソースを含むレスポンスをクライアント２に送信する。
　なお、コンテンツ送信部２２は、受信したリクエストがセグメントの送信を要求するリクエストであるか否かを、受信したリクエストによって指定されたリソースのメディアタイプがセグメントであるか否かに基づいて判定してもよい。
　サーバ記憶部１２は、サーバ制御部１１が参照するプログラムやデータ等を格納するものであり、例えば、コンテンツ取得部２１が取得したＭＰＤデータおよびセグメントデータ等を格納してもよい。
　（クライアントについて）
　図１に示すように、クライアント２は、クライアント制御部４１、クライアント記憶部４２、クライアント通信部４３、表示部４４および音声出力部４５を備える。なお、クライアント２は、操作部、音声入力部等の部材を備えていてもよいが、発明の特徴点とは関係がないため当該部材を図示していない。
　クライアント通信部４３は、無線通信手段または有線通信手段によって、サーバ１、プロキシ３等の他の装置と通信を行い、クライアント制御部４１の指示に従って、データのやりとりを行うものである。
　表示部４４は、クライアント制御部４１の指示に従って画像を表示するものである。表示部４４は、クライアント制御部４１の指示に従って画像を表示するものであればよく、例えば、ＬＣＤ（液晶ディスプレイ）、有機ＥＬディスプレイ、プラズマディスプレイなどを適用することが可能である。
　音声出力部４５は、クライアント制御部４１から電気信号を受信し、受信した電気信号を音に変換し、クライアント２の外部に音を出力するものである。音声出力部４５は、いわゆるスピーカである。
　クライアント制御部４１は、クライアント記憶部４２から一時記憶部（不図示）に読み出されたプログラムを実行することにより、各種の演算を行うと共に、クライアント２が備える各部を統括的に制御するものである。
　本実施形態では、クライアント制御部４１は、機能ブロックとして、コンテンツ取得部（取得手段）５１およびコンテンツ再生部５２を備える構成である。これらのクライアント制御部４１の各機能ブロック（５１、５２）は、ＣＰＵが、ＲＯＭ等で実現された記憶装置に記憶されているプログラムをＲＡＭ等で実現された一時記憶部に読み出して実行することで実現できる。
　コンテンツ取得部５１は、サーバ１にクライアント通信部４３を介してリクエストを送信し、サーバ１からコンテンツ（コンテンツに対応付けられたＭＰＤおよびコンテンツを構成するセグメント）を取得するものである。
　具体的には、コンテンツ取得部５１は、ユーザから操作部（不図示）を介してコンテンツの取得（再生）指示が入力されると、当該コンテンツの管理情報（ＭＰＤ）の送信を要求するリクエストをサーバ１またはプロキシ３に送信する。そして、コンテンツ取得部５１は、当該リクエストのレスポンスとして、上記コンテンツのＭＰＤデータを受信する。コンテンツ取得部５１は、受信したＭＰＤデータを参照して、上記コンテンツを構成するセグメントの送信を要求するリクエストをサーバ１またはプロキシ３に送信する。そして、コンテンツ取得部５１は、当該リクエストのレスポンスとして、上記コンテンツのセグメントデータを取得する。コンテンツ取得部５１は、取得したセグメントデータをコンテンツ再生部５２に出力する。
　また、コンテンツ取得部５１は、ネットワークの遅延等が発生した場合、取得するRepresentationの切替を実行する。このとき、次に残りのセグメントの一部を取得する場合、コンテンツ取得部５１は、未取得のデータを含むサブセグメントのバイトレンジを特定し、特定したバイトレンジに基づいて、バイトレンジテンプレートを用いたリクエストをサーバ１またはプロキシ３に送信する。
　コンテンツ再生部５２は、コンテンツ取得部５１からセグメントデータを取得すると、ＭＰＤデータを参照して、取得したセグメントデータに基づいてコンテンツを再生するものである。
　クライアント記憶部４２は、クライアント制御部４１が参照するプログラムやデータ等を格納するものであり、例えば、コンテンツ取得部５１が取得したＭＰＤデータおよびセグメントデータ等を格納してもよい。
　〔サーバの処理〕
　次に、図３に基づいて、サーバ１のセグメント送信処理について説明する。図３は、サーバ１のセグメント送信処理の一例を示すフローチャートである。
　図３に示すように、サーバ１は、クライアント２から、セグメントまたはセグメントの一部の送信を要求するＨＴＴＰリクエストメッセージを受信する（Ｓ６１）。コンテンツ送信部２２は、当該セグメントを取得するようにコンテンツ取得部２１に指示して、コンテンツ取得部２１からセグメントデータを取得する。そして、コンテンツ送信部２２は、当該セグメントを複数に分割したサブセグメントを１チャンクとして、チャンク単位でセグメントをクライアント２に送信する（Ｓ６２）。
　コンテンツ送信部２２は、チャンク単位で送信を行い、要求されたセグメント全体を送信すると（Ｓ６３でＹＥＳ）、セグメント送信処理を終了する。または、コンテンツ送信部２２は、途中でコネクションがクローズした場合（Ｓ６３でＹＥＳ）、セグメント送信処理を終了する。
　〔クライアントの処理〕
　次に、図４に基づいて、クライアント２のセグメント取得処理について説明する。図４は、クライアント２のセグメント取得処理の一例を示すフローチャートである。
　図４に示すように、まず、コンテンツ取得部５１は、ＭＰＤデータを参照して、初期Representationのセグメント（例えば、高品質セグメント）の送信を要求するリクエストを送信する（Ｓ７１）。
　リクエストを送信した後、コンテンツ取得部５１は、Representationを切り替えるべきか否かを判定する（Ｓ７２）。ここで、ネットワークの遅延等が発生していなければ、Representationを切り替えず（Ｓ７２でＮＯ）、サーバ１からサブセグメント単位でチャンク転送されたセグメントを取得する（Ｓ７３）。コンテンツ取得部５１は、リクエストしたセグメント全体を受信したか否かを判定し（Ｓ７４）、まだ全てを受信していなければ（Ｓ７４でＮＯ）、Ｓ７２に戻る。
　ここで、ネットワークの遅延等が発生した場合、コンテンツ取得部５１は、取得するセグメントのRepresentationを切り替える（Ｓ７２でＹＥＳ）。コンテンツ取得部５１は、切替先のRepresentation（例えば、低品質セグメント）のsidxを解析し、リクエストしたセグメントのうちの未取得のサブセグメントのアクセスポイントに基づいて、未取得のサブセグメントのバイトレンジを特定する（Ｓ７５）。コンテンツ取得部５１は、特定したバイトレンジに基づいて、未取得のサブセグメントの取得先を示すバイトレンジテンプレートＵＲＬを生成する（Ｓ７６）。コンテンツ取得部５１は、生成したＵＲＬに基づいて、セグメントの残りのデータ（途中からのデータ）の送信を要求するリクエストを送信する（Ｓ７７）。そして、コンテンツ取得部５１は、切替先のepresentationのセグメントを途中から、チャンク単位で取得する（Ｓ７３）。
　このようにして、セグメント全体を受信するまで処理を実行し、セグメント全体を受信すると（Ｓ７４でＹＥＳ）、セグメント取得処理を終了する。
　〔ＭＰＤの記述例〕
　次に、本発明で用いるＭＰＤの記述例について図５に基づいて説明する。図５は、本発明で用いるＭＰＤの記述例を示す図である。
　図５に示すように、本発明で用いるＭＰＤ１００は、図１０に示す従来のＭＰＤ２００と比較して、情報１１０に含まれるプロファイル情報１１２、および、取得先情報１３０が異なる。
　具体的には、ＭＰＤ１００では、プロファイル情報１１２に、低遅延ライブ配信であることを示す「urn:mpeg:dash:profile:isoff-low-latency-live:2012」が記述される。また、取得先情報１３０には、単なるサーバのＵＲＬではなく、バイトレンジテンプレート（BaseURL@byterange）が記述される。
　〔バイトレンジリクエスト〕
　従来、クライアント２は、コンテンツの一部を取得する場合、ＨＴＴＰ／１．１で規定されているバイトレンジリクエストによって取得することができる。しかしながら、バイトレンジリクエストに対するサーバ１からのレスポンスは、ステータスコードが「２０６」であるため、プロキシ３は、当該レスポンスに含まれるデータをキャッシュしない。そのため、再度同じコンテンツをプロキシ３を介してサーバ１にリクエストした場合であっても、プロキシ３にはキャッシュされていないため、サーバ１が当該コンテンツを送信しなければならない。よって、低遅延ライブストリーミングを安定的に実現することが困難となる。
　以下に、より具体的に、バイトレンジリクエストによってコンテンツの一部を送受信するサーバ、クライアントおよびプロキシの動作シーケンス、および、従来のライブストリーミングにおいて送受信されるＨＴＴＰメッセージについて図１３および図１４に基づいて説明する。図１３は、バイトレンジリクエストによってコンテンツの一部を送受信するサーバ、クライアントおよびプロキシの動作シーケンスの一例を示す図である。また、図１４は、従来のライブストリーミングにおいて送受信されるＨＴＴＰメッセージの一例を示す図である。
　図１３および図１４に示すように、まず、クライアントは、ＭＰＤ２００を参照して、セグメント＃１の送信を要求するためのリクエストメッセージ３０１をプロキシに送信する。プロキシは、リクエストメッセージ３０１を受信し、セグメント＃１がキャッシュされていないため、リクエストをそのまま転送して、サーバにリクエストメッセージ３０２を送信する。
　サーバは、リクエストメッセージ３０２がセグメントの送信を要求するものであるため、リクエストメッセージ３０２の応答として、セグメント＃１のデータ本体を含むレスポンスメッセージ３０３をプロキシに送信する。プロキシは、レスポンスメッセージ３０３を受信し、レスポンスメッセージ３０３のステータスコードが「２００」であるため、レスポンスメッセージ３０３に含まれるデータをキャッシュ３０４すると共に、レスポンスをそのまま転送して、クライアントにレスポンスメッセージ３０５を送信する。クライアントは、レスポンスメッセージ３０５を受信して、セグメント＃１を取得する。
　ここで、ネットワークの遅延等が発生したため、クライアントは、Representationの切替３０６を実行する。クライアントは、sidxを解析して、セグメント＃１の未取得のデータのバイトレンジ（xxx～yyy）を特定する。クライアントは、特定したバイトレンジに基づいて、バイトレンジリクエストメッセージ３０７をプロキシに送信する。プロキシは、リクエストメッセージ３０７を受信し、ここでもリクエストの示すデータがキャッシュされていないため、リクエストをそのまま転送して、サーバにリクエストメッセージ３０８を送信する。
　サーバ１は、リクエストメッセージ３０８がバイトレンジリクエストであるため、リクエストメッセージ３０８の応答として、セグメント＃１の一部である指定されたバイトレンジのデータを含む、ステータスコード「２０６」のレスポンスメッセージ３０９をプロキシに送信する。プロキシは、レスポンスメッセージ３０９を受信し、レスポンスメッセージ３０９のステータスコードが「２０６」であるため、レスポンスメッセージ３０９に含まれるデータをキャッシュせず、レスポンスをそのまま転送して、クライアントにレスポンスメッセー３１０を送信する。クライアントは、レスポンスメッセージ３１０を受信して、セグメント＃１の残りのデータを取得する。
　このように、バイトレンジリクエストによってコンテンツの一部を送受信する場合、そのレスポンスのステータスコードが「２０６」であるため、プロキシ３はキャッシュしない。なお、プロキシ３がキャッシュするデータは、ステータスコードが「２００」、「２０３」、「３００」、「３０１」または「４１０」のレスポンスに含まれるデータである。
　ＭＰＥＧ－ＤＡＳＨでは、キャッシュサーバであるプロキシ３でのキャッシュヒットによるＲＴＴ（Round Trip Time）の低減によっても、低遅延ライブストリーミングを実現することができる。そのため、プロキシ３がキャッシュしないデータがあると、低遅延ライブストリーミングを安定的に実現することが困難となる。
　セグメントの一部をバイトレンジリクエストで取得する際に、プロキシ３でキャッシュされないという上記問題を解決するために、本発明では、上述のバイトレンジテンプレートを用いたリクエストでセグメントの一部を取得する。後述のように、バイトレンジテンプレートを用いたリクエストに対するレスポンスは、ステータスコードが「２００」であるため、プロキシ３は、当該レスポンスに含まれるデータをキャッシュすることができる。
　〔実施例１〕
　次に、低遅延ライブストリーミングを実行するサーバ１、クライアント２およびプロキシ３の動作シーケンスおよび低遅延ライブストリーミングにおいて送受信されるＨＴＴＰメッセージについて図６および図７に基づいて説明する。図６は、低遅延ライブストリーミングを実行するサーバ１、クライアント２およびプロキシ３の動作シーケンスの一例を示す図である。また、図７は、低遅延ライブストリーミングにおいて送受信されるＨＴＴＰメッセージの一例を示す図である。
　図６および図７に示すように、まず、クライアント２は、ＭＰＤ７０を参照して、セグメント＃１の送信を要求するためのリクエストメッセージ８１をプロキシ３に送信する。プロキシ３は、リクエストメッセージ８１を受信し、セグメント＃１がキャッシュされていないため、リクエストをそのまま転送して、サーバ１にリクエストメッセージ８２を送信する。
　サーバ１は、リクエストメッセージ８２がセグメントの送信を要求するものであるため、リクエストメッセージ８２の応答として、サブセグメント単位でチャンクに分割されたセグメント＃１のデータ本体を含むレスポンスメッセージ８３をプロキシ３に送信する。プロキシ３は、レスポンスメッセージ８３を受信し、レスポンスメッセージ８３のステータスコードが「２００」であるため、レスポンスメッセージ８３に含まれるデータをキャッシュ８４すると共に、レスポンスをそのまま転送して、クライアント２にレスポンスメッセージ８５を送信する。クライアント２は、レスポンスメッセージ８５を受信して、サブセグメント単位でチャンク転送されたセグメント＃１を取得する。
　ここで、ネットワークの遅延等が発生したため、クライアント２は、Representationの切替８６を実行する。クライアント２は、sidxを解析して、セグメント＃１の未取得のデータを含むサブセグメントのバイトレンジ（xxx～yyy）を特定する。クライアント２は、バイトレンジリクエストではなく、特定したバイトレンジに基づいて、バイトレンジテンプレートを用いたリクエストメッセージ８７をプロキシ３に送信する。プロキシ３は、リクエストメッセージ８７を受信し、ここでもリクエストの示すデータがキャッシュされていないため、リクエストをそのまま転送して、サーバ１にリクエストメッセージ８８を送信する。
　サーバ１は、リクエストメッセージ８８がバイトレンジリクエストではなく、通常のリクエストであるため、リクエストメッセージ８８の応答として、指定されたバイトレンジのサブセグメントをチャンク単位で含む、ステータスコード「２００」のレスポンスメッセージ８９をプロキシ３に送信する。プロキシ３は、レスポンスメッセージ８９を受信し、レスポンスメッセージ８９のステータスコードが「２００」であるため、レスポンスメッセージ８９に含まれるデータをキャッシュ９０すると共に、レスポンスをそのまま転送して、クライアント２にレスポンスメッセージ９１を送信する。クライアント２は、レスポンスメッセージ９１を受信して、セグメント＃１の残りのデータをチャンク単位で取得する。
　〔ＭＰＤの他の記述例〕
　本発明では、セグメントをさらに複数のサブセグメントに分割しているが、このサブセグメントの時間長は、任意でよい。すなわち、各サブセグメントの時間長が一定であってもよいし、各サブセグメントの時間長が異なっていてもよい。
　また、本発明では、サブセグメント単位でチャンク転送するため、サブセグメントの時間長と１チャンクの時間長は一致する。クライアント２は、チャンク時間長を事前に把握しておくことにより、ライブストリーミングにおける遅延量を予測することができる。そのため、ＭＰＤにチャンク時間長が記述されていることが好ましい。チャンク時間長が固定の場合、例えば、ＭＰＤにチャンク時間長が記述してもよい。また、チャンク時間長が可変の場合、例えば、ＭＰＤにチャンク時間長の最大値および／または最小値を記述してもよい。チャンク時間長の記述例については後述する。
　また、ＭＰＥＧ－ＤＡＳＨでは、Representationを切り替えるため、Representation間で、対応する各サブセグメントの境界が揃っていることが好ましい。換言すると、Representation間で、対応する各サブセグメントの再生開始時刻が一致していることが好ましい。この場合、Representationを切り替えても、各サブセグメントの再生時刻が一致しているため、特に問題なく再生することができる。
　一方、Representation間で、対応する各サブセグメントの境界が揃っていない場合、Representationの切替後に、整合をとって再生しなければならないため、クライアント２が各サブセグメントの境界が揃っているか否かを事前に把握しておくことが好ましい。そのため、ＭＰＤに各サブセグメントの境界が揃っているか否かを示すサブセグメントの配列に関する情報が記述されていることが好ましい。このサブセグメントの配列に関する情報については後述する。
　次に、本発明で用いるＭＰＤの他の記述例について図８に基づいて説明する。図８は、本発明で用いるＭＰＤの他の記述例を示す図である。図８では、サブセグメントの配列に関する情報およびチャンク時間長に関する情報が記述されているＭＰＤの一例を示す。
　図８に示すように、本発明で用いるＭＰＤ１０１は、図５に示すＭＰＤ１００と比較して、サブセグメントの配列に関する情報およびチャンク時間長に関する情報が追記されている。
　具体的には、ＭＰＤ１０１では、サブセグメントの配列に関する情報１５０として、属性「AdaptationSet@subsegmentAlignment」、およびその属性値「true」が記述されている。属性値「true」は、各サブセグメントの境界が揃っていることを示し、各サブセグメントの境界が揃っていない場合、属性値として「false」が記述される。
　また、ＭＰＤ１０１には、高品質セグメント情報１４３および低品質セグメント情報１４４に、チャンク時間長に関する情報として、属性「maxChunkDuration」、およびその属性値「PT10S」が記述されている。属性「maxChunkDuration」は、可変のチャンク時間長の最大値を示し、属性値「PT10S」は、その最大値が１０秒であることを示す。上述のように、チャンク時間長に関する情報として、固定のチャンク時間長を示す属性「chunkDuration」が記述されていても良く、可変のチャンク時間長の最小値を示す属性「minChunkDuration」が記述されていてもよい。
　また、上記属性「chunkDuration」は、セグメントの最初のチャンクの時間長と解釈してもよい。あるいは、属性「chunkDuration」の代わりに、セグメントの時間長（属性「SegmentList@duration」の値と等しい）と、セグメントの最初のチャンク時間長（属性「SegmentList@chunkDuration」の値と等しい）との差分値を示す属性「chunkDurationOffset」が記述されていてもよい。
　〔各サブセグメントの境界が揃っていない場合のRepresentationの切替例〕
　次に、各サブセグメントの境界が揃っていない場合のRepresentationの切替について図９に基づいて説明する。図９は、各サブセグメントの境界が揃っていない高品質セグメントおよび低品質セグメントのセグメントデータのデータ構造を示す図である。
　図９（ａ）に示すように、1024kbpsの高品質セグメント１６０は、moof１６３およびmdat１６４から成るサブセグメント＃０と、moof１６５およびmdat１６６から成るサブセグメント＃１と、moof１６７、１６９およびmdat１６８、１８０から成るサブセグメント＃２とを含む。一方、512kbpsの低品質セグメント１８０は、moof１８３およびmdat１８４から成るサブセグメント＃０と、moof１８５、１８７およびmdat１８６、１８８から成るサブセグメント＃１と、moof１８９およびmdat１９０から成るサブセグメント＃２とを含む。つまり、高品質セグメント１６０と低品質セグメント１８０とでは、サブセグメント＃２の再生開始時刻が異なっている。
　なお、高品質セグメント１６０および低品質セグメント１８０に含まれるフラグメント（moofおよびmdat）の時間長は一定である。つまり、高品質セグメントのフラグメント１６３～１７０と、低品質セグメントのフラグメント１８３～１９０とがそれぞれ対応している。
　ここで、高品質セグメントのサブセグメント＃１まで取得した後、Representationを切り替えて、低品質セグメントを取得するものとする。この場合、次に取得すべきデータは、高品質セグメントのmoof１６７に対応する低品質セグメントのmoof１８７である。ところが、低品質セグメント１８０では、moof１８５、１８７およびmdat１８６、１８８がサブセグメント＃１となっているため、moof１８７以降だけを取得することはできない。そのため、再生時にギャップが生じないように、未取得のデータであるmoof１８７を含むサブセグメント＃１から取得を開始する。このとき、moof１８５およびmdat１８６は時間的に重複して取得することとなるが、再生時に調整することによってスムーズなライブストリーミングを実現する。
　なお、上述のように、セグメントのヘッダであるsidx１６２、１８２には、各サブセグメントの時間情報が記述されており、sidxを解析して、バイトレンジを特定する。
　〔まとめ〕
　本発明の一態様に係るコンテンツ送信装置は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ再生装置に送信するコンテンツ送信装置であって、上記コンテンツ再生装置からリクエストを受信すると、当該リクエストに対する応答として、レスポンスを当該コンテンツ再生装置に送信する送信手段を備え、上記送信手段は、上記リクエストがセグメントの送信を要求するものである場合、当該セグメントを上記コンテンツ再生装置に、上記サブセグメント単位でチャンク転送する。
　本発明の一態様に係るコンテンツ送信装置の制御方法は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ再生装置に送信するコンテンツ送信装置の制御方法であって、上記コンテンツ再生装置からリクエストを受信すると、当該リクエストに対する応答として、レスポンスを当該コンテンツ再生装置に送信する送信ステップを含み、上記送信ステップにおいて、上記リクエストがセグメントの送信を要求するものである場合、当該セグメントを上記コンテンツ再生装置に、上記サブセグメント単位でチャンク転送する。
　上記の構成によれば、上記送信手段は、セグメントの送信を要求するリクエストに対して、当該セグメントをさらに複数に分割したサブセグメント単位でチャンク転送する。すなわち、送信単位は、セグメントよりさらに時間的に短いサブセグメント単位で送信すると共に、１つのリクエストで複数のサブセグメントの送信を要求することができる。そのため、サブセグメントの生成開始から配信可能になるまでの時間を短縮しつつ、複数リクエストのパイプライン化にともなうエラー処理を抑制することができる。よって、低遅延ライブストリーミングを安定的に実現することができる。
　さらに、本発明の一態様に係るコンテンツ送信装置では、上記サブセグメント単位でランダムアクセスできるように、上記セグメントが上記サブセグメントに分割されていてもよい。
　さらに、本発明の一態様に係るコンテンツ送信装置において、上記送信手段は、各サブセグメントの時間長が一定の場合、上記サブセグメントの時間長が記述されたコンテンツ管理情報をコンテンツ再生装置に送信してもよい。
　さらに、本発明の一態様に係るコンテンツ送信装置において、上記送信手段は、各サブセグメントの時間長が異なる場合、上記サブセグメントの時間長の最大値および最小値の少なくとも一方が記述されたコンテンツ管理情報をコンテンツ再生装置に送信してもよい。
　上記の構成によれば、クライアントは、チャンク転送されたサブセグメントの時間長を把握することができるため、ライブストリーミングにおける遅延量を予測することができる。
　さらに、本発明の一態様に係るコンテンツ再生装置は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ送信装置から取得して再生するコンテンツ再生装置であって、上記コンテンツ送信装置に、セグメントの送信を要求するリクエストを送信する取得手段を備え、上記取得手段は、上記リクエストに対する応答として、上記コンテンツ送信装置から、上記サブセグメント単位でチャンク転送された上記セグメントを取得する。
　さらに、本発明の一態様に係るコンテンツ再生装置の制御方法は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ送信装置から取得して再生するコンテンツ再生装置の制御方法であって、上記コンテンツ送信装置に、セグメントの送信を要求するリクエストを送信する送信ステップと、上記リクエストに対する応答として、上記コンテンツ送信装置から、上記サブセグメント単位でチャンク転送された上記セグメントを取得する取得ステップとを含む。
　〔実施例２〕
　サーバとクライアントの間のネットワーク上に発生する遅延としては、実施例１において、クライアントのリクエストしたリソースがサーバに存在しないこと等によりエラーが発生した場合、再度複数のリクエストを送信するためにネットワーク及びクライアントに負荷がかかり、遅延が発生するという問題があった。クライアントに発生する遅延としては、クライアントの有するデコーダの処理能力が低いためにデコード処理時に負荷がかかり、遅延が発生するという問題もある。
　本実施例では、クライアントのデコード処理能力に応じて、コンテンツ中の適切な情報を抽出することで、デコード処理時に発生する遅延を解消する方法について、図１５～図１８を参照しながら以下に説明する。図１５は、本実施例に係る伝送ストリームの構成の例を示す図である。また、図１６は、本実施例に係るサーバおよびクライアントの要部構成を示すブロック図である。さらに、図１７は、本実施例に係る複数のフレームレートデータを多重化したストリームが受信側で分離される過程を示す図である。図１８は、本実施例に係るコンテンツ内のピクチャと階層レベルを示す図である。
　現行のデジタル放送では、サーバにあたる放送局が映像、音声、その他の番組情報といった複数のデータをそれぞれ複数のパケットに格納し、１本のストリームに多重化して送出している。多重化には、ＭＰＥＧのストリームフォーマットであるＭＰＥＧ－２　ＴＳ（トランスポートストリーム）が用いられる。多重化されたトランスポートストリーム（ＴＳ）は、クライアントにあたる放送受信機でそれぞれのパケットに分離され、映像や音声などのデータが取得される。
　図１５（ａ）は、従来のＴＳの構造を示したものである。ＴＳは、それぞれが１８８バイトを有するＴＳパケットの集合で構成され、このＴＳパケットがクライアントに時系列的に入力される。このとき、各ＴＳパケットのヘッダには、図１５（ａ）に示されるようにパケット中のデータの種別を示すＰＩＤ（Ｐａｃｋｅｔ　Ｉｄｅｎｔｉｆｉｅｒ）が付与され、この値を用いて、分離部は、パケットのペイロードに格納された映像、音声、関連情報などを識別し、分離した上で、適切なデコーダにデータを入力できる。
　ＴＳでは、スケーラブル符号化された複数の映像品質から構成される映像データを分離し格納したパケットに同一のＰＩＤを付与する。そして、クライアントはデコード処理の段階で複数の映像品質データに分離することができる。即ち、１つの映像データは必ず１つのＰＩＤで伝送される。
　一方、従来のＴＳにおいては、別のＰＩＤが付加されたコンテンツは、同一のコンテンツとして認識することができない。例えば、ＨＥＶＣなどの予測符号化圧縮規格で圧縮された映像データでは、各フレームをＩ、Ｐ、Ｂなどの予測方式の異なるピクチャとして圧縮することが可能であり、それぞれ別のパケットに格納して伝送することが可能であるが、ＴＳのレベルでパケットに格納されたピクチャデータがＩかＰかＢかを識別することはできない。このとき、他のピクチャの復号に対して参照されないＢピクチャがあれば、Ｂピクチャのデータを除去しても再生は可能である。従って、この性質を利用すれば、クライアントの能力に応じてＢピクチャデータのパケットを適宜削除し、クライアントごとにフレームレートを変えて再生することも可能である。しかし、ＴＳを用いて伝送する場合は、前述のとおり多重化分離部でパケットを識別できないため、このような処理は不可能であった。
　上記課題に対し、本実施例では、図１５（ｂ）に示すように、ＰＩＤに加え、別のＰＩＤが付与されたパケットが同一のコンテンツであることを示すＲｅｆＰＩＤ（依存性識別子）を付与して、同一のコンテンツとして認識できるようにする。更に、本実施例では、パケットがＲｅｆＰＩＤを含むか否かを示すフラグｉｓＲｅｆを備える。ｉｓＲｅｆは２値のフラグであり、１のときＲｅｆＰＩＤを含むことを示し、０のときＲｅｆＰＩＤを含まないことを示す。
　図１６は、本実施例の要部構成を示したブロック図である。図１６に示すように、サーバは複数のパケットを多重化する多重化部を備え、クライアントはサーバから受信した複数のパケットが多重化されたストリームを個別のパケットに分離する多重化分離部を備えている。なお、図１と図１６に示すサーバとクライアントにおいて、同様の部材に関する説明は適宜省略する。
　（サーバについて）
　サーバ送信部は、無線通信手段または有線通信手段によって、クライアントにデータを送信するものである。
　サーバ制御部は、機能ブロックとして、コンテンツ生成部および多重化部、コンテンツ送信部（送信手段）を備える構成である。ここで、コンテンツ生成部はコンテンツデータを生成するものであり、多重化部においてパケットへの分離と多重化を行って、コンテンツ送信部に出力する。例えば、Ｉ、Ｐピクチャデータを格納したパケットにはＰＩＤの値ｐｉｄ＿ｂを付与し、Ｂピクチャデータを格納したパケットにはＰＩＤに値ｐｉｄ＿ａを付与する。さらに、Ｂピクチャデータを格納したパケットは、ｉｓＲｅｆの値を１とし、値ｐｉｄ＿ｂのＲｅｆＰＩＤを付与する。
　（クライアントについて）
　クライアント受信部は、無線通信手段または有線通信手段によって、サーバからデータを受信するものである。
　クライアント制御部は、機能ブロックとして、コンテンツ取得部（取得手段）および多重化分離部、コンテンツ再生部を備える構成である。ここで、コンテンツ取得部は、サーバから送られた多重化ストリームを取得し、多重化分離部に出力する。
　多重化分離部は、多重化ストリームをそれぞれのパケットに分離する。この際、ＰＩＤの値を参照することで、映像、音声、番組情報などのパケットに分離する。
　多重化分離部はさらに、パケットがＲｅｆＰＩＤを含んでいるかを判断し、ＲｅｆＰＩＤを含んでいるパケットであれば、そのパケットのデータとＲｅｆＰＩＤが示すパケットのデータとを、１つのコンテンツのデータとして解釈する。そして、多重化分離部で分離したそれぞれのコンテンツのデータが、コンテンツ再生部に入力される。
　なお、この際、パケットのデータとＲｅｆＰＩＤが示すパケットのデータとは、図示しない伝送時刻情報がそれぞれのパケットヘッダに格納されており、伝送時刻情報をみて順序を一意に決めることが可能である。あるいは、図示しないシーケンス番号がパケットヘッダに格納されて、シーケンス番号から順序を一意に決めるとしてもよい。
　コンテンツ再生部は、ＰＩＤとＲｅｆＰＩＤに従って、多重化分離部で分離された映像のパケットデータを順番に映像信号にデコードし、デコードされたピクチャデータを表示順序に適宜並べ替えた上で、表示部にそれぞれ出力する。
　図１７は、上記で説明したように、Ｉ、Ｐピクチャデータ、Ｂピクチャデータをそれぞれ、ＰＩＤが値ｐｉｄ＿ｂのパケット、ＰＩＤが値ｐｉｄ＿ａのパケットにそれぞれ格納して多重化されたストリームを受け取り、受け取った多重化ストリームをクライアントの多重化分離部において、ＰＩＤとＲｅｆＰＩＤに基づいてフレームレートの異なるコンテンツデータに多重化分離されることを示した図である。このとき、Ｉ、Ｐピクチャデータはフレームレート６０Ｈzの符号化データである。一方、ＢピクチャデータはＩ、Ｐピクチャデータの各ピクチャ間にＢピクチャ１枚を挟むことで１２０Ｈｚの再生を行うための付加データである。具体的には、ｐｉｄ＿ａのＲｅｆＰＩＤがｐｉｄ＿ｂであることから、ｐｉｄ＿ａとｐｉｄ＿ｂの全てのパケットを映像デコーダに出力することで、１２０Ｈｚの映像を再生する。一方、ｐｉｄ＿ｂのみを映像デコーダに出力する場合、６０Ｈｚの映像が再生される。
　なお、本実施例においては、ｉｓＲｅｆ、ＲｅｆＰＩＤをパケットヘッダに付与する構成としたが、格納する場所はこれに限定されず、例えば既に実施例１で説明したのと同様、図１６に示すＭＰＤ記憶装置に格納しているＭＰＤに記述してもよい。あるいはＭＰＤ以外のコンテンツの伝送に関わる伝送情報や、コンテンツの再生に係る再生情報のメタデータの一部として記述してもよい。あるいはさらに、ＰＩＤの値自身にコンテンツ同士が同一のコンテンツであることを示す情報を記述し、ＰＩＤがＲｅｆＰＩＤを兼ねることで、ＲｅｆＰＩＤを付加しない構成としてもよい。また、ＲｅｆＰＩＤを必須とし、ｉｓＲｅｆを省略した構成も可能である。
　例えば、現行のデジタル放送において使われているＰＡＴ／ＰＭＴ（Ｐｒｏｇｒａｍ　Ａｓｓｏｃｉａｔｉｏｎ　Ｔａｂｌｅ／Ｐｒｏｇｒａｍ　Ｍａｐ　Ｔａｂｌｅ）をベースに、伝送情報（プログラム構成テーブル）にｉｓＲｅｆ、ＲｅｆＰＩＤを格納した例を図１９（ａ）に示す。また、ｉｓＲｅｆ、ＲｅｆＰＩＤを使う以外に、映像に複数ＰＩＤを記述した例を図１９（ｂ）に示す。図１９（ｂ）の場合には、映像が２つのＰＩＤの付与されたデータから成ることが示され、後ろに書かれたＰＩＤは前に書かれたＰＩＤに依存するものと解釈する。このような伝送情報を用いることで、クライアントの多重化分離部は、必要なデータのＰＩＤを知り、多重化ストリームから当該ＰＩＤの付与されたパケットデータのみを分離し、再生する。
　これにより、クライアントは、多重化ストリーム中で異なるＰＩＤを持った同一コンテンツを含むパケットを識別することができ、デコード能力に応じて必要なパケットデータを取得して、デコードすることができる。上記例では、Ｉ、ＰピクチャデータとＢピクチャデータを格納したパケットから、６０Ｈｚ、１２０Ｈｚのフレームレートの異なる再生を行う例を示したが、これ以外にも、例えば、スケーラブル符号化において低解像度ベースレイヤのストリームデータと高解像度エンハンスメントレイヤのストリームデータを別ＰＩＤのパケットに格納し、ＰＩＤ、ＲｅｆＰＩＤを用いて識別することで、デコード能力の低いクライアントはベースレイヤのデータを取得し低解像度映像を再生、デコード能力の高いクライアントはベース、エンハンスメントレイヤのデータを取得し高解像度の映像を再生するといった処理も可能である。デコード能力に応じた適切なフレームレート、解像度のデータを抽出することで、デコード時に発生する遅延を解消できる。
　また、Ｉ、Ｐ、ＢピクチャへのＰＩＤ、ＲｅｆＰＩＤの付与は上記例に限定されず、図１８に示すように、多数の階層からなるＢピクチャを有する場合に、Ｉ／Ｐピクチャのパケット（階層０）には値ｐｉｄ＿０のＰＩＤを付与し、階層１のＢピクチャのパケットには値ｐｉｄ＿１のＰＩＤを付与し、同様に、階層２、３のＢピクチャのパケットには値ｐｉｄ＿２、ｐｉｄ＿３のＰＩＤを付与してもよい。この場合、階層１のＢピクチャのパケットには値ｐｉｄ＿０のＲｅｆＰＩＤを付与し、同様に、階層２、３のＢピクチャのパケットには値ｐｉｄ＿１、ｐｉｄ＿２のＲｅｆＰＩＤを付与する。
　上記の構成によれば、上記取得手段は、セグメントの送信を要求するリクエストに対して、当該セグメントをさらに複数に分割したサブセグメント単位でチャンク転送されたセグメントを取得する。すなわち、送信単位は、セグメントよりさらに時間的に短いサブセグメント単位で送信すると共に、１つのリクエストで複数のサブセグメントの送信を要求することができる。そのため、サブセグメントの生成開始から配信可能になるまでの時間を短縮しつつ、複数リクエストのパイプライン化にともなうエラー処理を抑制することができる。よって、低遅延ライブストリーミングを安定的に実現することができる。
　さらに、本発明の一態様に係るコンテンツ再生装置では、上記サブセグメント単位でランダムアクセスできるように、上記セグメントが上記サブセグメントに分割されていてもよい。
　さらに、本発明の一態様に係るコンテンツ再生装置において、上記取得手段は、セグメントの一部の送信を要求するリクエストを送信する場合、当該セグメントの一部を含むサブセグメントのバイトレンジを特定し、特定したバイトレンジを指定する、バイトレンジテンプレートを用いたリクエストを送信してもよい。
　上記の構成によれば、上記取得手段は、セグメントの一部の送信を要求するリクエストを送信する場合、バイトレンジテンプレートを用いたリクエストを送信するため、当該リクエストに対するレスポンスのステータスコードは「２００」となる。よって、コンテンツの中継装置であるプロキシを介してコンテンツを取得する場合、プロキシは、上記レスポンスに含まれるデータをキャッシュすることができる。よって、ＲＴＴを低減することができ、安定的に低遅延ライブストリーミングを実現することができる。
　さらに、本発明の一態様に係るコンテンツ配信システムは、上記コンテンツ送信装置と、上記コンテンツ再生装置とを含む。
　上記の構成によれば、コンテンツ配信システムは、上記コンテンツ送信装置および上記コンテンツ再生装置と同様の効果を奏する。
　また、コンテンツ再生装置がコンテンツ送信装置から取得する、複数のセグメントから構成されたコンテンツであって、当該セグメントがさらに複数のサブセグメントに分割されたコンテンツに対応付けられたコンテンツ管理情報のデータ構造であって、バイトレンジテンプレートが記述された、コンテンツの取得先を示す取得先情報を含むことを特徴とするコンテンツ管理情報のデータ構造も本発明の範疇に含まれる。
　なお、上記コンテンツ送信装置および上記コンテンツ再生装置は、コンピュータによって実現してもよく、この場合には、コンピュータを上記コンテンツ送信装置および上記コンテンツ再生装置の各手段として動作させることにより、上記コンテンツ送信装置および上記コンテンツ再生装置をコンピュータにて実現させる制御プログラム、及びそれを記録したコンピュータ読み取り可能な記録媒体も本発明の範疇に入る。
　本発明は上述した実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能である。すなわち、請求項に示した範囲で適宜変更した技術的手段を組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
　〔ソフトウェアによる実現例〕
　最後に、サーバ１およびクライアント２の各ブロック、特にサーバ制御部１１およびクライアント制御部４１は、集積回路（ＩＣチップ）上に形成された論理回路によってハードウェア的に実現してもよいし、ＣＰＵ（Central Processing Unit）を用いてソフトウェア的に実現してもよい。
　後者の場合、サーバ１およびクライアント２は、各機能を実現するプログラムの命令を実行するＣＰＵ、上記プログラムを格納したＲＯＭ（Read Only Memory）、上記プログラムを展開するＲＡＭ（Random Access Memory）、上記プログラムおよび各種データを格納するメモリ等の記憶装置（記録媒体）などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアであるサーバ１およびクライアント２の制御プログラムのプログラムコード（実行形式プログラム、中間コードプログラム、ソースプログラム）をコンピュータで読み取り可能に記録した記録媒体を、上記サーバ１およびクライアント２に供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。
　上記記録媒体としては、一時的でない有形の媒体（non-transitory tangible medium）、例えば、磁気テープやカセットテープ等のテープ類、フロッピー（登録商標）ディスク／ハードディスク等の磁気ディスクやＣＤ－ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ／ＣＤ－Ｒ等の光ディスクを含むディスク類、ＩＣカード（メモリカードを含む）／光カード等のカード類、マスクＲＯＭ／ＥＰＲＯＭ／ＥＥＰＲＯＭ（登録商標）／フラッシュＲＯＭ等の半導体メモリ類、あるいはＰＬＤ（Programmable logic device）やＦＰＧＡ（Field Programmable Gate Array）等の論理回路類などを用いることができる。
　また、サーバ１およびクライアント２を通信ネットワークと接続可能に構成し、上記プログラムコードを通信ネットワークを介して供給してもよい。この通信ネットワークは、プログラムコードを伝送可能であればよく、特に限定されない。例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ、ＩＳＤＮ、ＶＡＮ、ＣＡＴＶ通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、この通信ネットワークを構成する伝送媒体も、プログラムコードを伝送可能な媒体であればよく、特定の構成または種類のものに限定されない。例えば、ＩＥＥＥ１３９４、ＵＳＢ、電力線搬送、ケーブルＴＶ回線、電話線、ＡＤＳＬ（Asymmetric Digital Subscriber Line）回線等の有線でも、ＩｒＤＡやリモコンのような赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＩＥＥＥ８０２．１１無線、ＨＤＲ（High Data Rate）、ＮＦＣ（Near Field Communication）、ＤＬＮＡ（Digital Living Network Alliance）（登録商標）、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。
　本発明は、ＭＰＥＧ－ＤＡＳＨ規格のコンテンツを送信するコンテンツ送信装置、および、当該コンテンツを取得・再生するコンテンツ再生装置に利用することができる。
　１　　サーバ
　２　　クライアント
　３　　プロキシ
　４　　ＭＰＤ記憶装置
　５　　セグメント記憶装置
　６　　コンテンツ配信システム
２１　　コンテンツ取得部
２２　　コンテンツ送信部（送信手段）
５１　　コンテンツ取得部（取得手段）
５２　　コンテンツ再生部

Claims (13)

  1. 　複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ再生装置に送信するコンテンツ送信装置であって、
    　上記コンテンツ再生装置からリクエストを受信すると、当該リクエストに対する応答として、レスポンスを当該コンテンツ再生装置に送信する送信手段を備え、
    　上記送信手段は、上記リクエストがセグメントの送信を要求するものである場合、当該セグメントを上記コンテンツ再生装置に、上記サブセグメント単位でチャンク転送することを特徴とするコンテンツ送信装置。
  2. 　上記サブセグメント単位でランダムアクセスできるように、上記セグメントが上記サブセグメントに分割されていることを特徴とする請求項１に記載のコンテンツ送信装置。
  3. 　上記送信手段は、各サブセグメントの時間長が一定の場合、上記サブセグメントの時間長が記述されたコンテンツ管理情報をコンテンツ再生装置に送信することを特徴とする請求項１または２に記載のコンテンツ送信装置。
  4. 　上記送信手段は、各サブセグメントの時間長が異なる場合、上記サブセグメントの時間長の最大値および最小値の少なくとも一方が記述されたコンテンツ管理情報をコンテンツ再生装置に送信することを特徴とする請求項１または２に記載のコンテンツ送信装置。
  5. 　複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ送信装置から取得して再生するコンテンツ再生装置であって、
    　上記コンテンツ送信装置に、セグメントの送信を要求するリクエストを送信する取得手段を備え、
    　上記取得手段は、上記リクエストに対する応答として、上記コンテンツ送信装置から、上記サブセグメント単位でチャンク転送された上記セグメントを取得することを特徴とするコンテンツ再生装置。
  6. 　上記サブセグメント単位でランダムアクセスできるように、上記セグメントが上記サブセグメントに分割されていることを特徴とする請求項５に記載のコンテンツ再生装置。
  7. 　上記取得手段は、セグメントの一部の送信を要求するリクエストを送信する場合、当該セグメントの一部を含むサブセグメントのバイトレンジを特定し、特定したバイトレンジを指定する、バイトレンジテンプレートを用いたリクエストを送信することを特徴とする請求項５または６に記載のコンテンツ再生装置。
  8. 　請求項１～４の何れか１項に記載のコンテンツ送信装置と、
    　請求項５～７の何れか１項に記載のコンテンツ再生装置とを含むことを特徴とするコンテンツ配信システム。
  9. 　複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ再生装置に送信するコンテンツ送信装置の制御方法であって、
    　上記コンテンツ再生装置からリクエストを受信すると、当該リクエストに対する応答として、レスポンスを当該コンテンツ再生装置に送信する送信ステップを含み、
    　上記送信ステップにおいて、上記リクエストがセグメントの送信を要求するものである場合、当該セグメントを上記コンテンツ再生装置に、上記サブセグメント単位でチャンク転送することを特徴とするコンテンツ送信装置の制御方法。
  10. 　複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ送信装置から取得して再生するコンテンツ再生装置の制御方法であって、
    　上記コンテンツ送信装置に、セグメントの送信を要求するリクエストを送信する送信ステップと、
    　上記リクエストに対する応答として、上記コンテンツ送信装置から、上記サブセグメント単位でチャンク転送された上記セグメントを取得する取得ステップとを含むことを特徴とするコンテンツ再生装置の制御方法。
  11. 　請求項１～４の何れか１項に記載のコンテンツ送信装置を動作させるための制御プログラムであって、コンピュータを上記各手段として機能させるための制御プログラム。
  12. 　請求項５～７の何れか１項に記載のコンテンツ再生装置を動作させるための制御プログラムであって、コンピュータを上記各手段として機能させるための制御プログラム。
  13. 　請求項１１および１２の少なくとも１項に記載の制御プログラムを記録したコンピュータ読み取り可能な記録媒体。
PCT/JP2013/077165 2012-10-09 2013-10-04 コンテンツ送信装置、コンテンツ再生装置、コンテンツ配信システム、コンテンツ送信装置の制御方法、コンテンツ再生装置の制御方法、制御プログラムおよび記録媒体 WO2014057896A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2014540833A JPWO2014057896A1 (ja) 2012-10-09 2013-10-04 コンテンツ再生装置
EP13844804.8A EP2908535A4 (en) 2012-10-09 2013-10-04 Content transfer device, content playback device, content distribution system, method for controlling a content transfer device, method for controlling a content playback device, control program and recording medium
US14/434,158 US9641906B2 (en) 2012-10-09 2013-10-04 Content transmission device, content playback device, content distribution system, method for controlling content transmission device, method for controlling content playback device, control program, and recording medium
US15/478,258 US9832534B2 (en) 2012-10-09 2017-04-04 Content transmission device and content playback device
US15/807,892 US20180070148A1 (en) 2012-10-09 2017-11-09 Content transmission device and content playback device

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2012-224236 2012-10-09
JP2012224236 2012-10-09
JP2013102178 2013-05-14
JP2013-102178 2013-05-14

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US14/434,158 A-371-Of-International US9641906B2 (en) 2012-10-09 2013-10-04 Content transmission device, content playback device, content distribution system, method for controlling content transmission device, method for controlling content playback device, control program, and recording medium
US15/478,258 Continuation US9832534B2 (en) 2012-10-09 2017-04-04 Content transmission device and content playback device

Publications (1)

Publication Number Publication Date
WO2014057896A1 true WO2014057896A1 (ja) 2014-04-17

Family

ID=50477363

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/077165 WO2014057896A1 (ja) 2012-10-09 2013-10-04 コンテンツ送信装置、コンテンツ再生装置、コンテンツ配信システム、コンテンツ送信装置の制御方法、コンテンツ再生装置の制御方法、制御プログラムおよび記録媒体

Country Status (4)

Country Link
US (3) US9641906B2 (ja)
EP (1) EP2908535A4 (ja)
JP (4) JPWO2014057896A1 (ja)
WO (1) WO2014057896A1 (ja)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015182492A1 (ja) * 2014-05-30 2015-12-03 ソニー株式会社 情報処理装置および情報処理方法
WO2015194392A1 (ja) * 2014-06-20 2015-12-23 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
WO2016002498A1 (ja) * 2014-06-30 2016-01-07 ソニー株式会社 情報処理装置および方法、配信システム、並びにプログラム
WO2016002493A1 (ja) * 2014-06-30 2016-01-07 ソニー株式会社 ファイル生成装置および方法、並びにコンテンツ再生装置および方法
EP2993910A1 (en) * 2014-09-04 2016-03-09 Thomson Licensing Method and client terminal for receiving a multimedia content split into at least two successive segments, and corresponding computer program product and computer-readable medium.
CN106464985A (zh) * 2015-04-30 2017-02-22 华为技术有限公司 一种媒体流传输方法及装置
JP2017535133A (ja) * 2014-09-26 2017-11-24 アルカテル−ルーセント クライアントへのメディアコンテンツのアダプティブストリーミングのためのサーバ、方法、およびコンピュータプログラム製品
WO2020184357A1 (ja) * 2019-03-08 2020-09-17 ソニー株式会社 情報処理装置、情報処理方法及び情報処理プログラム
JP7517324B2 (ja) 2019-03-08 2024-07-17 ソニーグループ株式会社 情報処理装置、情報処理方法及び情報処理プログラム

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101987756B1 (ko) * 2012-07-24 2019-06-11 삼성전자주식회사 미디어 재생 방법 및 미디어 장치
JPWO2014057896A1 (ja) * 2012-10-09 2016-09-05 シャープ株式会社 コンテンツ再生装置
EP2962468A1 (en) * 2013-03-14 2016-01-06 Arris Technology, Inc. Devices, systems, and methods for converting or translating dynamic adaptive streaming over http (dash) to http live streaming (hls)
EP3065408A4 (en) * 2013-10-30 2017-09-13 Sony Corporation Transmission device, transmission method, reception device, and reception method
FR3016263A1 (fr) * 2014-01-07 2015-07-10 Orange Procede de traitement d'erreur de restitution d'un contenu numerique
US10313415B2 (en) * 2014-07-18 2019-06-04 Cisco Technology, Inc. Using segment routing to access chunks of content
US10582235B2 (en) * 2015-09-01 2020-03-03 The Nielsen Company (Us), Llc Methods and apparatus to monitor a media presentation
US11617019B2 (en) * 2016-07-28 2023-03-28 Qualcomm Incorporated Retrieving and accessing segment chunks for media streaming
KR101863598B1 (ko) * 2016-07-29 2018-06-01 주식회사 에어브로드 스트리밍 서비스를 위한 클라이언트의 동작 방법
JP6674355B2 (ja) * 2016-08-31 2020-04-01 株式会社東芝 通信装置、通信方法及びプログラム
EP3539270B1 (en) * 2016-11-10 2022-07-20 Telefonaktiebolaget LM Ericsson (PUBL) Resource segmentation to improve delivery performance
WO2018127780A1 (en) 2017-01-09 2018-07-12 Telefonaktiebolaget Lm Ericsson (Publ) Controllable beam management accuracy
WO2019011430A1 (en) * 2017-07-12 2019-01-17 Telefonaktiebolaget Lm Ericsson (Publ) FAST TUNING FOR LOW-LOW CONTINUOUS DIFFUSION
JP7022540B2 (ja) * 2017-09-08 2022-02-18 キヤノン株式会社 情報処理装置およびその制御方法
US20210021659A1 (en) * 2018-04-06 2021-01-21 Sony Corporation Delivery apparatus, delivery method, and program
CN109787983A (zh) * 2019-01-24 2019-05-21 北京百度网讯科技有限公司 直播流切片方法、装置和系统
US11564018B2 (en) 2019-10-02 2023-01-24 Qualcomm Incorporated Random access at resync points of dash segments
JP2021069084A (ja) * 2019-10-28 2021-04-30 ラディウス株式会社 ストリーミングデータの再生装置、ストリーミングデータの配信システム、及び、ストリーミングデータの生成再生方法
JP7390159B2 (ja) * 2019-10-28 2023-12-01 日本放送協会 送信装置及び受信装置
EP3905708B1 (en) * 2020-04-27 2022-12-21 Broadpeak Method and server for audio and/or video content delivery
US11973817B2 (en) * 2020-06-23 2024-04-30 Tencent America LLC Bandwidth cap signaling using combo-index segment track in media streaming
US11765444B2 (en) * 2020-07-01 2023-09-19 Qualcomm Incorporated Streaming media data including an addressable resource index track
JP2023007048A (ja) 2021-07-01 2023-01-18 株式会社東芝 ストリーミングサーバ、送信方法及びプログラム

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005110244A (ja) 2003-09-27 2005-04-21 Lg Electronics Inc マルチメディアストリーミングサービスシステム及びその方法
WO2012094199A1 (en) * 2011-01-04 2012-07-12 Thomson Licensing Apparatus and method for transmitting live media content

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101204134B1 (ko) * 2008-04-25 2012-11-23 프라운호퍼 게젤샤프트 쭈르 푀르데룽 데어 안겐반텐 포르슝 에. 베. 트랜스포트 데이터 스트림내에서 참조하는 유연성 있는 서브스트림
US7925774B2 (en) * 2008-05-30 2011-04-12 Microsoft Corporation Media streaming using an index file
CN102150432A (zh) * 2008-09-17 2011-08-10 夏普株式会社 可分级视频流解码装置以及可分级视频流生成装置
US8396114B2 (en) * 2009-01-29 2013-03-12 Microsoft Corporation Multiple bit rate video encoding using variable bit rate and dynamic resolution for adaptive video streaming
CA2755774C (en) * 2009-03-19 2015-01-06 Azuki Systems, Inc. Method for scalable live streaming delivery for mobile audiences
CA2711311C (en) * 2009-08-10 2016-08-23 Seawell Networks Inc. Methods and systems for scalable video chunking
JP5304539B2 (ja) * 2009-08-27 2013-10-02 日本電気株式会社 メディア品質変換装置、メディア品質変換方法およびメディア品質変換プログラム
US20110096828A1 (en) * 2009-09-22 2011-04-28 Qualcomm Incorporated Enhanced block-request streaming using scalable encoding
US8751677B2 (en) * 2009-10-08 2014-06-10 Futurewei Technologies, Inc. System and method to support different ingest and delivery schemes for a content delivery network
WO2012011473A1 (ja) * 2010-07-20 2012-01-26 シャープ株式会社 送信装置、送信方法、受信装置、受信方法、通信システム、データ構造、プログラム、及び、記憶媒体
WO2012011490A1 (ja) 2010-07-20 2012-01-26 シャープ株式会社 コンテンツ取得装置、コンテンツ送信装置、コンテンツ送受信システム、データ構造、制御方法、制御プログラム、及び記録媒体
TW201210325A (en) * 2010-07-21 2012-03-01 Nokia Corp Method and apparatus for indicating switching points in a streaming session
JP2012095053A (ja) * 2010-10-26 2012-05-17 Toshiba Corp ストリーム伝送システム、送信装置、受信装置、ストリーム伝送方法及びプログラム
WO2012134530A1 (en) * 2011-04-01 2012-10-04 Intel Corporation Cross-layer optimized adaptive http streaming
CN102232298B (zh) * 2011-04-07 2013-10-09 华为技术有限公司 媒体内容的传输处理方法、装置与系统
KR20170083641A (ko) * 2012-07-10 2017-07-18 브이아이디 스케일, 인크. 품질 주도형 스트리밍
JPWO2014057896A1 (ja) * 2012-10-09 2016-09-05 シャープ株式会社 コンテンツ再生装置

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005110244A (ja) 2003-09-27 2005-04-21 Lg Electronics Inc マルチメディアストリーミングサービスシステム及びその方法
WO2012094199A1 (en) * 2011-01-04 2012-07-12 Thomson Licensing Apparatus and method for transmitting live media content

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
ISO/IEC 23009-1, 1 April 2012 (2012-04-01), Retrieved from the Internet <URL:http://standards.iso.org/ittf/PubliclyAvailableStandards/c0576 23 ISO IEC 23009-1 2012.zip>
ISO/IEC23009-1 INFORMATION TECHNOLOGY - DYNAMIC ADAPTIVE STREAMING OVER HTTP (DASH) - PART 1: MEDIA PRESENTATION DESCRIPTION AND SEGMENT FORMATS, 1 April 2012 (2012-04-01), pages 67 - 69,16-19,114-115, XP055112819 *
See also references of EP2908535A4

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015182492A1 (ja) * 2014-05-30 2015-12-03 ソニー株式会社 情報処理装置および情報処理方法
JPWO2015182492A1 (ja) * 2014-05-30 2017-04-20 ソニー株式会社 情報処理装置および情報処理方法
US10375439B2 (en) 2014-05-30 2019-08-06 Sony Corporation Information processing apparatus and information processing method
WO2015194392A1 (ja) * 2014-06-20 2015-12-23 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
US11863807B2 (en) 2014-06-20 2024-01-02 Saturn Licensing Llc Reception device, reception method, transmission device, and transmission method
US11356719B2 (en) 2014-06-20 2022-06-07 Saturn Licensing Llc Reception device, reception method, transmission device, and transmission method
US10798430B2 (en) 2014-06-20 2020-10-06 Saturn Licensing Llc Reception device, reception method, transmission device, and transmission method
JPWO2015194392A1 (ja) * 2014-06-20 2017-04-20 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
US10271076B2 (en) 2014-06-30 2019-04-23 Sony Corporation File generation device and method, and content playback device and method
WO2016002498A1 (ja) * 2014-06-30 2016-01-07 ソニー株式会社 情報処理装置および方法、配信システム、並びにプログラム
WO2016002493A1 (ja) * 2014-06-30 2016-01-07 ソニー株式会社 ファイル生成装置および方法、並びにコンテンツ再生装置および方法
JPWO2016002493A1 (ja) * 2014-06-30 2017-04-27 ソニー株式会社 ファイル生成装置および方法、並びにコンテンツ再生装置および方法
EP2993911A1 (en) * 2014-09-04 2016-03-09 Thomson Licensing Method and client terminal for receiving a multimedia content split into at least two successive segments, and corresponding computer program product and computer-readable medium
CN105407414A (zh) * 2014-09-04 2016-03-16 汤姆逊许可公司 用于接收多媒体内容的方法和客户端
EP2993910A1 (en) * 2014-09-04 2016-03-09 Thomson Licensing Method and client terminal for receiving a multimedia content split into at least two successive segments, and corresponding computer program product and computer-readable medium.
JP2017535133A (ja) * 2014-09-26 2017-11-24 アルカテル−ルーセント クライアントへのメディアコンテンツのアダプティブストリーミングのためのサーバ、方法、およびコンピュータプログラム製品
CN106464985B (zh) * 2015-04-30 2019-04-12 华为技术有限公司 一种媒体流传输方法及装置
CN106464985A (zh) * 2015-04-30 2017-02-22 华为技术有限公司 一种媒体流传输方法及装置
WO2020184357A1 (ja) * 2019-03-08 2020-09-17 ソニー株式会社 情報処理装置、情報処理方法及び情報処理プログラム
US11936962B2 (en) 2019-03-08 2024-03-19 Sony Group Corporation Information processing device and information processing method
JP7517324B2 (ja) 2019-03-08 2024-07-17 ソニーグループ株式会社 情報処理装置、情報処理方法及び情報処理プログラム

Also Published As

Publication number Publication date
US20150296269A1 (en) 2015-10-15
US20170208366A1 (en) 2017-07-20
JP2018186524A (ja) 2018-11-22
US9641906B2 (en) 2017-05-02
US9832534B2 (en) 2017-11-28
EP2908535A1 (en) 2015-08-19
US20180070148A1 (en) 2018-03-08
JPWO2014057896A1 (ja) 2016-09-05
EP2908535A4 (en) 2016-07-06
JP2015208018A (ja) 2015-11-19
JP2017073814A (ja) 2017-04-13

Similar Documents

Publication Publication Date Title
JP2018186524A (ja) コンテンツ送信装置およびコンテンツ再生装置
US9351020B2 (en) On the fly transcoding of video on demand content for adaptive streaming
US9712890B2 (en) Network video streaming with trick play based on separate trick play files
US9247317B2 (en) Content streaming with client device trick play index
US9288251B2 (en) Adaptive bitrate management on progressive download with indexed media files
JP6016778B2 (ja) チャンクの形態でストリーミングされたコンテンツを回復する方法
CN110099288B (zh) 发送媒体数据的方法及装置
US20140297804A1 (en) Control of multimedia content streaming through client-server interactions
US20140359678A1 (en) Device video streaming with trick play based on separate trick play files
US20110138018A1 (en) Mobile media server
CA2965484A1 (en) Adaptive bitrate streaming latency reduction
CN103843301A (zh) 经译码多媒体数据的网络串流期间的表示之间的切换
WO2014193996A2 (en) Network video streaming with trick play based on separate trick play files
KR100678891B1 (ko) Ａｖ데이터 수신시 버퍼량을 컨텐츠 속성에 따라탄력적으로 조절하는 방법 및 장치
KR102499231B1 (ko) 수신 장치, 송신 장치 및 데이터 처리 방법
WO2013145419A1 (ja) コンテンツデータ記録装置、コンテンツデータ記録方法、制御プログラムおよび記録媒体
KR101145782B1 (ko) 모바일 컨텐츠 서비스를 제공하기 위한 경량화된 비디오 컨텐츠 암호화 및 복호화 방법
US9060184B2 (en) Systems and methods for adaptive streaming with augmented video stream transitions using a media server
KR102137858B1 (ko) 송신 장치, 송신 방법, 수신 장치, 수신 방법 및 프로그램
WO2014010444A1 (ja) コンテンツ送信装置、コンテンツ再生装置、コンテンツ配信システム、コンテンツ送信装置の制御方法、コンテンツ再生装置の制御方法、データ構造、制御プログラムおよび記録媒体
WO2012011466A1 (ja) 中継装置、中継方法、通信システム、中継制御プログラム、および記録媒体
US11893090B2 (en) Synchronization of digital rights management data
KR101568317B1 (ko) Ip 카메라에서 hls 프로토콜을 지원하는 시스템 및 그 방법
Adeyemi-Ejeye et al. Implementation of 4kUHD HEVC-content transmission
JP2018074348A (ja) 映像処理装置、映像処理方法および映像処理プログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13844804

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
ENP Entry into the national phase

Ref document number: 2014540833

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14434158

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2013844804

Country of ref document: EP