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

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/637Control signals issued by the client directed to the server or network components
    • H04N21/6373Control 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21Server components or server architectures
    • H04N21/218Source of audio or video content, e.g. local disk arrays
    • H04N21/2187Live feed
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management 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/266Channel 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/2662Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/45Management 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/462Content 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/4621Controlling 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456Structuring 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

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

Description

コンテンツ送信装置、コンテンツ再生装置、コンテンツ配信システム、コンテンツ送信装置の制御方法、コンテンツ再生装置の制御方法、制御プログラムおよび記録媒体
 本発明は、コンテンツを送信するコンテンツ送信装置、コンテンツを取得・再生するコンテンツ再生装置、コンテンツ配信システム、コンテンツ送信装置の制御方法、コンテンツ再生装置の制御方法、制御プログラムおよび記録媒体に関するものである。
 インターネットの普及やコンピュータの高性能化に伴い、インターネットを介して動画像などの大容量コンテンツを配信することが広く行われている。例えば、ユーザの要求に応じて動画等のコンテンツを提供するVOD(Video On Demand)というサービスがある。VODでは、例えば、特許文献1に記載されているように、HTTP(HyperText Transfer Protocol)を用いて、サーバ(コンテンツ提供装置)とクライアント(コンテンツ再生装置)との間でデータを送受信する。
 ここで、HTTPによるコンテンツの配信に関して、様々な技術が開発されている。例えば、MPEG(Motion Picture Experts Group)は、HTTPを利用した適応ストリーミング技術をMPEG-DASH(Dynamic Adaptive Streaming over HTTP)規格として国際標準化を進めている。
 MPEG-DASHでは、コンテンツは、複数のセグメント(segment)に時分割され、セグメント単位で伝送される。また、各セグメントは、1または複数のフラグメント(fragment)で構成される。また、コンテンツは、1または複数のピリオド(period)で構成されており、1つのピリオドに1または複数のセグメントが含まれる。
 また、MPEG-DASHでは、1つのコンテンツに対して品質種別(ビットレート、画像解像度等の再生品質や、データフォーマット等の種別)が異なる複数のRepresentationが準備される。例えば、セグメント毎に異なるビットレートで符号化した複数のセグメントデータを準備する。これにより、コンテンツを受信して再生するクライアントは、コンテンツの受信状況等に応じて、要求するコンテンツ(セグメント)のビットレートを変えることにより、適応ストリーミングを実行することができる。
 また、MPEG-DASHでは、コンテンツにMPD(Media Presentation Description)が対応付けられており、MPDによってコンテンツを管理する。MPDは、コンテンツのメタデータであって、コンテンツの管理情報をXML形式で記述したものである。換言すると、MPDは、クライアントがコンテンツの取得・再生時に利用する情報である。
 MPDの具体的な記述例を図10に基づいて説明する。図10は、MPDの記述例を示す図である。図10に示すように、MPD200には、タイプ情報211、プロファイル情報212、バッファリング時間情報213、配信開始時刻情報214を含む情報210が記述されている。
 タイプ情報211は、ライブ配信であるかオンデマンド配信であるかを示す情報(属性「type」の属性値)である。図示の例では、属性「type」の属性値が「dynamic」であり、このMPD200が対応付けられたコンテンツがライブ配信コンテンツであることを示す。一方、オンデマンド配信の場合、属性「type」の属性値に「static」が記述される。
 プロファイル情報212は、コンテンツのプロファイルを示す情報である。また、バッファリング時間情報213は、最小のバッファリング時間を示す情報である。図示の例では、属性「minBufferTime」の属性値が「PT10S」であるため、クライアントは少なくとも10秒のバッファリングを行うことを示す。
 配信開始時刻情報214は、サーバがコンテンツのライブストリーミング配信を開始する時刻を示す情報(属性「availabilityStartTime」の属性値)である。図示の例では、属性「availabilityStartTime」の属性値が「2012-09-20T15:00:00」であり、2012年9月20日15時にライブストリーミング配信が開始されることを示す。
 また、MPD200には、コンテンツの再生期間を区切った各ピリオドに関するピリオド情報220が記述されている。図示の例では、ピリオド情報220として、コンテンツの配信開始時刻を基準とした場合のそのピリオドの開始時刻(属性「start」の属性値)およびそのピリオドの期間(属性「duration」の属性値)が記述されている。
 また、コンテンツの取得先を示す取得先情報230が記述されている。図示の例では、取得先情報230として、サーバのURLが記述されている。
 また、ここでは、コンテンツとして、ビットレートが1024kbpsの高品質Representationと、ビットレートが512kbpsの低品質Representationが用意されているものとする。そのため、MPD200には、或るピリオド(再生時刻0秒から3600秒まで)に含まれるセグメントとして、高品質セグメントを示す高品質セグメント情報241と、低品質セグメントを示す低品質セグメント情報242とが記述されている。高品質セグメント情報241には、当該ピリオドに含まれる高品質RepresentationのIDおよびビットレートが記述されている。また、当該ピリオドに含まれる各セグメントの長さおよびURLが記述されている。また、低品質セグメント情報242も同様である。なお、当該ピリオドは、セグメント#1~セグメント#6の6個のセグメントで構成されている。
 次に、従来の基本的なセグメントデータのデータ構造について図11に基づいて説明する。図11は、従来における、高品質セグメントおよび低品質セグメントのセグメントデータのデータ構造を示す図である。ここでは、セグメントデータがISOBFF(ISO/IEC 14496-12)で規定されるbox形式で記述されている例を説明する。
 図11(a)に示すように、従来の高品質セグメントデータ260は、1つのstyp(Segment Type Box)261、1つのsidx(Segment Index Box)262、並びに、moof(Movie Fragment Box)263、265、267および269と、mdat(Media Data Box)264、266、268および270との1つまたは複数の組から構成される。また、図11(b)に示すように、低品質セグメントデータ280も、高品質セグメントデータ260と同様に、1つのstyp281、1つのsidx282、並びに、moof283、285、287および289と、mdat284、286、288および290との1つまたは複数の組から構成される。
 styp261およびstyp281は、セグメントの種別および/またはバージョン情報等を示す情報である。sidx262およびsidx282は、セグメント内のランダムアクセスポイントに関する情報である。moof263、265、267および269、並びに、mdat264、266、268および270と、moof283、285、287および289、並びに、mdat284、286、288および290とは、セグメントを構成するフラグメントに関する情報である。
 moofおよびmdatの1つの組が1つのフラグメントを構成する。また、1つまたは複数のフラグメントから構成され、ランダムアクセスに適応するようにセグメントを分割した単位をサブセグメント(subsegment)とする。例えば、図11の例では、moof263、265およびmdat264、266が1つのサブセグメントを構成する。sidxの各エントリ271、272、291および292(図11(a)および(b)に示す「s0」、「s1」)には、各サブセグメントのバイトサイズ、時間情報などが記述されている。
 次に、sidxのシンタックスの一例を図12に基づいて説明する。図12は、sidxのシンタックスの一例を示す図である。ここでは、sidxは、ISO/IEC 14496-12で定義されている例を示す。
 このように、MPEG-DASHでは、サーバでのセグメントの生成開始から配信可能になるまでの時間を短縮するために、セグメントの時間長を小さくして低遅延ライブストリーミングに対応することを想定している。なお、サーバおよびクライアントによる処理遅延やネットワーク上の遅延等が発生するため、クライアントが厳密にリアルタイムに再生することは不可能である。そのため、わずかに遅延しているが、実質的にリアルタイムでのライブストリーミングを低遅延ライブストリーミングと称する。
日本国公開特許公報「特開2005-110244号公報(2005年4月21日公開)」
"ISO/IEC 23009-1"、[online]、2012年4月1日、ISO/IEC、[平成24年9月26日検索]、インターネット<URL:http://standards.iso.org/ittf/PubliclyAvailableStandards/c057623_ISO_IEC_23009-1_2012.zip>
 上述のように、MPEG-DASHでは、セグメントの時間長を短くすることで低遅延ライブストリーミングを実現しようとするものであるが、セグメントの時間長を短くすることで遅延が生じる場合がある。具体的には、セグメントの時間長が短い場合、通常、ネットワークジッタに対応するために、セグメントの送信を要求する複数のリクエストをパイプライン化して送信する。このとき、リクエストしたリソースがサーバに存在しないこと等によりエラーが発生した場合、再度複数のリクエストを送信しなければならず、再リクエストにより遅延が発生するという問題がある。
 本発明は、上記の問題点に鑑みてなされたものであり、その目的は、安定的に低遅延ライブストリーミングを実行するコンテンツ送信装置、コンテンツ再生装置、コンテンツ配信システム、コンテンツ送信装置の制御方法、コンテンツ再生装置の制御方法、制御プログラムおよび記録媒体を実現することにある。
 上記の課題を解決するために、本発明の一態様に係るコンテンツ送信装置は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ再生装置に送信するコンテンツ送信装置であって、上記コンテンツ再生装置からリクエストを受信すると、当該リクエストに対する応答として、レスポンスを当該コンテンツ再生装置に送信する送信手段を備え、上記送信手段は、上記リクエストがセグメントの送信を要求するものである場合、当該セグメントを上記コンテンツ再生装置に、上記サブセグメント単位でチャンク転送する。
 また、上記の課題を解決するために、本発明の一態様に係るコンテンツ送信装置の制御方法は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ再生装置に送信するコンテンツ送信装置の制御方法であって、上記コンテンツ再生装置からリクエストを受信すると、当該リクエストに対する応答として、レスポンスを当該コンテンツ再生装置に送信する送信ステップを含み、上記送信ステップにおいて、上記リクエストがセグメントの送信を要求するものである場合、当該セグメントを上記コンテンツ再生装置に、上記サブセグメント単位でチャンク転送する。
 さらに、上記の課題を解決するために、本発明の一態様に係るコンテンツ再生装置は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ送信装置から取得して再生するコンテンツ再生装置であって、上記コンテンツ送信装置に、セグメントの送信を要求するリクエストを送信する取得手段を備え、上記取得手段は、上記リクエストに対する応答として、上記コンテンツ送信装置から、上記サブセグメント単位でチャンク転送された上記セグメントを取得する。
 さらに、上記の課題を解決するために、本発明の一態様に係るコンテンツ再生装置の制御方法は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ送信装置から取得して再生するコンテンツ再生装置の制御方法であって、上記コンテンツ送信装置に、セグメントの送信を要求するリクエストを送信する送信ステップと、上記リクエストに対する応答として、上記コンテンツ送信装置から、上記サブセグメント単位でチャンク転送された上記セグメントを取得する取得ステップとを含む。
 本発明の一態様によれば、低遅延ライブストリーミングを安定的に実現することができる。
本発明の実施形態を示すものであり、サーバおよびクライアントの要部構成を示すブロック図である。 上記サーバおよびクライアントを含むコンテンツ配信システムの概要を示す図である。 上記サーバが実行するセグメント送信処理の一例を示すフローチャートである。 上記クライアントが実行するセグメント取得処理の一例を示すフローチャートである。 本発明で用いるMPDの記述例を示す図である。 低遅延ライブストリーミングを実行する上記サーバ、上記クライアントおよびプロキシの動作シーケンスの一例を示す図である。 低遅延ライブストリーミングにおいて送受信されるHTTPメッセージの一例を示す図である。 本発明で用いるMPDの他の記述例を示す図である。 各サブセグメントの境界が揃っていない高品質セグメントおよび低品質セグメントのセグメントデータのデータ構造を示す図である。 従来のMPDの記述例を示す図である。 従来における、高品質セグメントおよび低品質セグメントのセグメントデータのデータ構造を示す図である。 従来技術を示すものであり、sidxのシンタックスの一例を示す図である。 従来技術を示すものであり、バイトレンジリクエストによってコンテンツの一部を送受信するサーバ、クライアントおよびプロキシの動作シーケンスの一例を示す図である。 従来のライブストリーミングにおいて送受信されるHTTPメッセージの一例を示す図である。 伝送ストリームの構成の例を示す図である。 本発明の別の実施形態に係るサーバおよびクライアントの要部構成を示すブロック図である。 多重化ストリームが受信側で分離される過程を示す図である。 コンテンツ内のピクチャと階層レベルの例を示す図である。 伝送情報(プログラム構成テーブル)にisRef、RefPIDを格納した例を示す図である。
 本発明の一実施形態について図1から図14に基づいて説明すると以下の通りである。まず、本実施形態のコンテンツ配信システムの概要について、図2に基づいて説明する。
 〔コンテンツ配信システムの概要〕
 図2は、本実施形態に係るコンテンツ配信システム6の概要を示す図である。図2に示すように、コンテンツ配信システム6は、サーバ1、クライアント2、プロキシ3、MPD記憶装置4およびセグメント記憶装置5を含む。
 図2に示すように、クライアント2は、プロキシ3を介して、サーバ1と接続する。また、サーバ1は、MPD記憶装置4およびセグメント記憶装置5と接続する。各装置は、有線通信または無線通信の任意のネットワークで接続される。
 サーバ1は、クライアント2またはプロキシ3からコンテンツの送信の要求を受けて、コンテンツを送信するコンテンツ送信装置である。サーバ1は、コンテンツのデータ本体(セグメントデータ)を送信する前に、予めMPDデータをクライアント2またはプロキシ3に送信する。なお、サーバ1は、ネットワーク7上のMPD記憶装置4およびセグメント記憶装置5からMPDデータおよびセグメントデータを取得するものであるが、これに限るものではない。例えば、各サーバ1は、ローカルでMPDデータおよびセグメントデータを保持していてもよい。
 クライアント2は、サーバ1等の他の装置から取得したコンテンツ、または、自装置に格納しているコンテンツを再生するコンテンツ再生装置である。クライアント2は、例えば、デジタルテレビ、レコーダ、STB(Set Top Box)、PC、携帯電話機、スマート
フォン、ゲーム機、PDA(Personal Digital Assistant)、デジタルカメラ、デジタルビデオ等である。
 プロキシ3は、或る装置(サーバ1またはクライアント2)から取得したデータを他の装置(クライアント2またはサーバ1)へ転送する中継装置である。例えば、プロキシ3は、クライアント2から取得したリクエストをサーバ1に転送し、サーバ1から取得したコンテンツをクライアント2に転送する。
 また、プロキシ3は、サーバ1から取得したデータ(MPDおよびコンテンツ)をキャッシュするため、キャッシュサーバ(Cache Server)とも言える。なお、プロキシ3をキャッシュサーバと称する場合、サーバ1は、オリジンサーバ(Origin Server)と称する
。このとき、プロキシ3は、クライアント2からリクエストを取得し、当該リクエストの示すコンテンツを保持している場合、当該コンテンツを読み出し、クライアント2へ当該コンテンツを送信してもよい。
 また、コンテンツ配信システム6の構成は図2に示す例に限るものではない。例えば、コンテンツ配信システム6は、サーバ1を複数含んでいてもよいし、クライアント2を複数含んでいてもよい。また、コンテンツ配信システム6は、プロキシ3を複数含んでいてもよい。
 また、本実施形態では、コンテンツ配信システム6におけるネットワーク上の伝送プロトコルは、ハイパーテキスト転送プロトコルとして広く用いられているHTTPを用いるものとする。また、サーバ1が配信するコンテンツは、映像コンテンツであり、コンテンツは、セグメント化されたISOBFFデータであるものとする。すなわち、本実施形態では、コンテンツ配信システム6は、上述のMPEG-DASH規格に基づくコンテンツを配信するものである。
 また、本発明で扱うコンテンツは、複数のセグメントから構成されるものであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツである。サブセグメントの時間情報とは、サブセグメントの時間的な位置を示す情報であり、例えば、サブセグメントの再生開始時刻を示す情報である。また、本発明では、セグメントをサブセグメントに分割する単位は任意でよいが、例えば、サブセグメント単位でランダムアクセスできるように、セグメントがサブセグメントに分割されていてもよい。換言すると、セグメントのヘッダに、サブセグメントの時間情報として、ランダムアクセスポイントの時間的な位置を示す情報が記述されていてもよい。
 〔各装置の構成〕
 次に、図1に基づいて、サーバ1およびクライアント2の要部構成について説明する。図1は、サーバ1およびクライアント2の要部構成の一例を示す図である。なお、図1では、プロキシ3を省略している。
 (サーバについて)
 図1に示すように、サーバ1は、サーバ制御部11、サーバ記憶部12およびサーバ通信部13を備える構成である。
 サーバ通信部13は、無線通信手段または有線通信手段によって、クライアント2、プロキシ3、MPD記憶装置4およびセグメント記憶装置5等の他の装置と通信を行い、サーバ制御部11の指示に従って、データのやりとりを行うものである。
 サーバ制御部11は、サーバ記憶部12から一時記憶部(不図示)に読み出されたプログラムを実行することにより、各種の演算を行うと共に、サーバ1が備える各部を統括的に制御するものである。
 本実施形態では、サーバ制御部11は、機能ブロックとして、コンテンツ取得部21およびコンテンツ送信部(送信手段)22備える構成である。サーバ制御部11の各機能ブロック(21、22)は、CPU(central processing unit)が、ROM(read only memory)等で実現された記憶装置に記憶されているプログラムをRAM(random access memory)等で実現された一時記憶部に読み出して実行することで実現できる。
 コンテンツ取得部21は、コンテンツ送信部22からの指示に基づいて、MPD記憶装置4からMPDデータまたはセグメント記憶装置5からセグメントデータを取得するものである。コンテンツ取得部21は、取得したMPDデータまたはセグメントデータをコンテンツ送信部22に出力する。
 なお、コンテンツ取得部21は、コンテンツ送信部22からの指示の有無に関わらず、事前に、MPDデータおよび/またはセグメントデータを取得していても良い。この場合、コンテンツ取得部21は、事前に取得したMPDデータおよびセグメントデータをサーバ記憶部12に格納しておき、コンテンツ送信部22からの指示に基づいて、サーバ記憶部12からMPDデータおよびセグメントデータを読み出す。
 コンテンツ送信部22は、クライアント2からリクエストを受信すると、受信したリクエストがセグメントの送信を要求するリクエストであるか否かを判定する。受信したリクエストがセグメントの送信を要求するリクエストである場合、コンテンツ送信部22は、当該セグメントを取得するようにコンテンツ取得部21に指示して、コンテンツ取得部21からセグメントデータを取得し、当該セグメントデータを含むレスポンスをクライアント2に送信する。
 ただし、本発明では、コンテンツ送信部22は、セグメントデータを送信する際、セグメントデータを一度に全て送信するのではなく、セグメントをさらに複数に分割したサブセグメントを1チャンクとして、チャンク単位で送信する。
 一方、受信したリクエストがセグメントの送信を要求するリクエストではない場合、リクエストに対するレスポンスを当該クライアント2に送信する。例えば、クライアント2からコンテンツ管理情報(MPD)の送信を要求するリクエストを受信すると、当該コンテンツのMPDを取得するようにコンテンツ取得部21に指示し、コンテンツ取得部21からMPDデータを取得すると、取得したMPDデータを含むレスポンスをクライアント2に送信する。また、クライアント2からWebページ等のリソースの送信を要求するリクエストを受信すると、当該リソースを取得するようにコンテンツ取得部21に指示し、コンテンツ取得部21からリソースを取得すると、取得したリソースを含むレスポンスをクライアント2に送信する。
 なお、コンテンツ送信部22は、受信したリクエストがセグメントの送信を要求するリクエストであるか否かを、受信したリクエストによって指定されたリソースのメディアタイプがセグメントであるか否かに基づいて判定してもよい。
 サーバ記憶部12は、サーバ制御部11が参照するプログラムやデータ等を格納するものであり、例えば、コンテンツ取得部21が取得したMPDデータおよびセグメントデータ等を格納してもよい。
 (クライアントについて)
 図1に示すように、クライアント2は、クライアント制御部41、クライアント記憶部42、クライアント通信部43、表示部44および音声出力部45を備える。なお、クライアント2は、操作部、音声入力部等の部材を備えていてもよいが、発明の特徴点とは関係がないため当該部材を図示していない。
 クライアント通信部43は、無線通信手段または有線通信手段によって、サーバ1、プロキシ3等の他の装置と通信を行い、クライアント制御部41の指示に従って、データのやりとりを行うものである。
 表示部44は、クライアント制御部41の指示に従って画像を表示するものである。表示部44は、クライアント制御部41の指示に従って画像を表示するものであればよく、例えば、LCD(液晶ディスプレイ)、有機ELディスプレイ、プラズマディスプレイなどを適用することが可能である。
 音声出力部45は、クライアント制御部41から電気信号を受信し、受信した電気信号を音に変換し、クライアント2の外部に音を出力するものである。音声出力部45は、いわゆるスピーカである。
 クライアント制御部41は、クライアント記憶部42から一時記憶部(不図示)に読み出されたプログラムを実行することにより、各種の演算を行うと共に、クライアント2が備える各部を統括的に制御するものである。
 本実施形態では、クライアント制御部41は、機能ブロックとして、コンテンツ取得部(取得手段)51およびコンテンツ再生部52を備える構成である。これらのクライアント制御部41の各機能ブロック(51、52)は、CPUが、ROM等で実現された記憶装置に記憶されているプログラムをRAM等で実現された一時記憶部に読み出して実行することで実現できる。
 コンテンツ取得部51は、サーバ1にクライアント通信部43を介してリクエストを送信し、サーバ1からコンテンツ(コンテンツに対応付けられたMPDおよびコンテンツを構成するセグメント)を取得するものである。
 具体的には、コンテンツ取得部51は、ユーザから操作部(不図示)を介してコンテンツの取得(再生)指示が入力されると、当該コンテンツの管理情報(MPD)の送信を要求するリクエストをサーバ1またはプロキシ3に送信する。そして、コンテンツ取得部51は、当該リクエストのレスポンスとして、上記コンテンツのMPDデータを受信する。コンテンツ取得部51は、受信したMPDデータを参照して、上記コンテンツを構成するセグメントの送信を要求するリクエストをサーバ1またはプロキシ3に送信する。そして、コンテンツ取得部51は、当該リクエストのレスポンスとして、上記コンテンツのセグメントデータを取得する。コンテンツ取得部51は、取得したセグメントデータをコンテンツ再生部52に出力する。
 また、コンテンツ取得部51は、ネットワークの遅延等が発生した場合、取得するRepresentationの切替を実行する。このとき、次に残りのセグメントの一部を取得する場合、コンテンツ取得部51は、未取得のデータを含むサブセグメントのバイトレンジを特定し、特定したバイトレンジに基づいて、バイトレンジテンプレートを用いたリクエストをサーバ1またはプロキシ3に送信する。
 コンテンツ再生部52は、コンテンツ取得部51からセグメントデータを取得すると、MPDデータを参照して、取得したセグメントデータに基づいてコンテンツを再生するものである。
 クライアント記憶部42は、クライアント制御部41が参照するプログラムやデータ等を格納するものであり、例えば、コンテンツ取得部51が取得したMPDデータおよびセグメントデータ等を格納してもよい。
 〔サーバの処理〕
 次に、図3に基づいて、サーバ1のセグメント送信処理について説明する。図3は、サーバ1のセグメント送信処理の一例を示すフローチャートである。
 図3に示すように、サーバ1は、クライアント2から、セグメントまたはセグメントの一部の送信を要求するHTTPリクエストメッセージを受信する(S61)。コンテンツ送信部22は、当該セグメントを取得するようにコンテンツ取得部21に指示して、コンテンツ取得部21からセグメントデータを取得する。そして、コンテンツ送信部22は、当該セグメントを複数に分割したサブセグメントを1チャンクとして、チャンク単位でセグメントをクライアント2に送信する(S62)。
 コンテンツ送信部22は、チャンク単位で送信を行い、要求されたセグメント全体を送信すると(S63でYES)、セグメント送信処理を終了する。または、コンテンツ送信部22は、途中でコネクションがクローズした場合(S63でYES)、セグメント送信処理を終了する。
 〔クライアントの処理〕
 次に、図4に基づいて、クライアント2のセグメント取得処理について説明する。図4は、クライアント2のセグメント取得処理の一例を示すフローチャートである。
 図4に示すように、まず、コンテンツ取得部51は、MPDデータを参照して、初期Representationのセグメント(例えば、高品質セグメント)の送信を要求するリクエストを送信する(S71)。
 リクエストを送信した後、コンテンツ取得部51は、Representationを切り替えるべきか否かを判定する(S72)。ここで、ネットワークの遅延等が発生していなければ、Representationを切り替えず(S72でNO)、サーバ1からサブセグメント単位でチャンク転送されたセグメントを取得する(S73)。コンテンツ取得部51は、リクエストしたセグメント全体を受信したか否かを判定し(S74)、まだ全てを受信していなければ(S74でNO)、S72に戻る。
 ここで、ネットワークの遅延等が発生した場合、コンテンツ取得部51は、取得するセグメントのRepresentationを切り替える(S72でYES)。コンテンツ取得部51は、切替先のRepresentation(例えば、低品質セグメント)のsidxを解析し、リクエストしたセグメントのうちの未取得のサブセグメントのアクセスポイントに基づいて、未取得のサブセグメントのバイトレンジを特定する(S75)。コンテンツ取得部51は、特定したバイトレンジに基づいて、未取得のサブセグメントの取得先を示すバイトレンジテンプレートURLを生成する(S76)。コンテンツ取得部51は、生成したURLに基づいて、セグメントの残りのデータ(途中からのデータ)の送信を要求するリクエストを送信する(S77)。そして、コンテンツ取得部51は、切替先のepresentationのセグメントを途中から、チャンク単位で取得する(S73)。
 このようにして、セグメント全体を受信するまで処理を実行し、セグメント全体を受信すると(S74でYES)、セグメント取得処理を終了する。
 〔MPDの記述例〕
 次に、本発明で用いるMPDの記述例について図5に基づいて説明する。図5は、本発明で用いるMPDの記述例を示す図である。
 図5に示すように、本発明で用いるMPD100は、図10に示す従来のMPD200と比較して、情報110に含まれるプロファイル情報112、および、取得先情報130が異なる。
 具体的には、MPD100では、プロファイル情報112に、低遅延ライブ配信であることを示す「urn:mpeg:dash:profile:isoff-low-latency-live:2012」が記述される。また、取得先情報130には、単なるサーバのURLではなく、バイトレンジテンプレート(BaseURL@byterange)が記述される。
 〔バイトレンジリクエスト〕
 従来、クライアント2は、コンテンツの一部を取得する場合、HTTP/1.1で規定されているバイトレンジリクエストによって取得することができる。しかしながら、バイトレンジリクエストに対するサーバ1からのレスポンスは、ステータスコードが「206」であるため、プロキシ3は、当該レスポンスに含まれるデータをキャッシュしない。そのため、再度同じコンテンツをプロキシ3を介してサーバ1にリクエストした場合であっても、プロキシ3にはキャッシュされていないため、サーバ1が当該コンテンツを送信しなければならない。よって、低遅延ライブストリーミングを安定的に実現することが困難となる。
 以下に、より具体的に、バイトレンジリクエストによってコンテンツの一部を送受信するサーバ、クライアントおよびプロキシの動作シーケンス、および、従来のライブストリーミングにおいて送受信されるHTTPメッセージについて図13および図14に基づいて説明する。図13は、バイトレンジリクエストによってコンテンツの一部を送受信するサーバ、クライアントおよびプロキシの動作シーケンスの一例を示す図である。また、図14は、従来のライブストリーミングにおいて送受信されるHTTPメッセージの一例を示す図である。
 図13および図14に示すように、まず、クライアントは、MPD200を参照して、セグメント#1の送信を要求するためのリクエストメッセージ301をプロキシに送信する。プロキシは、リクエストメッセージ301を受信し、セグメント#1がキャッシュされていないため、リクエストをそのまま転送して、サーバにリクエストメッセージ302を送信する。
 サーバは、リクエストメッセージ302がセグメントの送信を要求するものであるため、リクエストメッセージ302の応答として、セグメント#1のデータ本体を含むレスポンスメッセージ303をプロキシに送信する。プロキシは、レスポンスメッセージ303を受信し、レスポンスメッセージ303のステータスコードが「200」であるため、レスポンスメッセージ303に含まれるデータをキャッシュ304すると共に、レスポンスをそのまま転送して、クライアントにレスポンスメッセージ305を送信する。クライアントは、レスポンスメッセージ305を受信して、セグメント#1を取得する。
 ここで、ネットワークの遅延等が発生したため、クライアントは、Representationの切替306を実行する。クライアントは、sidxを解析して、セグメント#1の未取得のデータのバイトレンジ(xxx~yyy)を特定する。クライアントは、特定したバイトレンジに基づいて、バイトレンジリクエストメッセージ307をプロキシに送信する。プロキシは、リクエストメッセージ307を受信し、ここでもリクエストの示すデータがキャッシュされていないため、リクエストをそのまま転送して、サーバにリクエストメッセージ308を送信する。
 サーバ1は、リクエストメッセージ308がバイトレンジリクエストであるため、リクエストメッセージ308の応答として、セグメント#1の一部である指定されたバイトレンジのデータを含む、ステータスコード「206」のレスポンスメッセージ309をプロキシに送信する。プロキシは、レスポンスメッセージ309を受信し、レスポンスメッセージ309のステータスコードが「206」であるため、レスポンスメッセージ309に含まれるデータをキャッシュせず、レスポンスをそのまま転送して、クライアントにレスポンスメッセー310を送信する。クライアントは、レスポンスメッセージ310を受信して、セグメント#1の残りのデータを取得する。
 このように、バイトレンジリクエストによってコンテンツの一部を送受信する場合、そのレスポンスのステータスコードが「206」であるため、プロキシ3はキャッシュしない。なお、プロキシ3がキャッシュするデータは、ステータスコードが「200」、「203」、「300」、「301」または「410」のレスポンスに含まれるデータである。
 MPEG-DASHでは、キャッシュサーバであるプロキシ3でのキャッシュヒットによるRTT(Round Trip Time)の低減によっても、低遅延ライブストリーミングを実現することができる。そのため、プロキシ3がキャッシュしないデータがあると、低遅延ライブストリーミングを安定的に実現することが困難となる。
 セグメントの一部をバイトレンジリクエストで取得する際に、プロキシ3でキャッシュされないという上記問題を解決するために、本発明では、上述のバイトレンジテンプレートを用いたリクエストでセグメントの一部を取得する。後述のように、バイトレンジテンプレートを用いたリクエストに対するレスポンスは、ステータスコードが「200」であるため、プロキシ3は、当該レスポンスに含まれるデータをキャッシュすることができる。
 〔実施例1〕
 次に、低遅延ライブストリーミングを実行するサーバ1、クライアント2およびプロキシ3の動作シーケンスおよび低遅延ライブストリーミングにおいて送受信されるHTTPメッセージについて図6および図7に基づいて説明する。図6は、低遅延ライブストリーミングを実行するサーバ1、クライアント2およびプロキシ3の動作シーケンスの一例を示す図である。また、図7は、低遅延ライブストリーミングにおいて送受信されるHTTPメッセージの一例を示す図である。
 図6および図7に示すように、まず、クライアント2は、MPD70を参照して、セグメント#1の送信を要求するためのリクエストメッセージ81をプロキシ3に送信する。プロキシ3は、リクエストメッセージ81を受信し、セグメント#1がキャッシュされていないため、リクエストをそのまま転送して、サーバ1にリクエストメッセージ82を送信する。
 サーバ1は、リクエストメッセージ82がセグメントの送信を要求するものであるため、リクエストメッセージ82の応答として、サブセグメント単位でチャンクに分割されたセグメント#1のデータ本体を含むレスポンスメッセージ83をプロキシ3に送信する。プロキシ3は、レスポンスメッセージ83を受信し、レスポンスメッセージ83のステータスコードが「200」であるため、レスポンスメッセージ83に含まれるデータをキャッシュ84すると共に、レスポンスをそのまま転送して、クライアント2にレスポンスメッセージ85を送信する。クライアント2は、レスポンスメッセージ85を受信して、サブセグメント単位でチャンク転送されたセグメント#1を取得する。
 ここで、ネットワークの遅延等が発生したため、クライアント2は、Representationの切替86を実行する。クライアント2は、sidxを解析して、セグメント#1の未取得のデータを含むサブセグメントのバイトレンジ(xxx~yyy)を特定する。クライアント2は、バイトレンジリクエストではなく、特定したバイトレンジに基づいて、バイトレンジテンプレートを用いたリクエストメッセージ87をプロキシ3に送信する。プロキシ3は、リクエストメッセージ87を受信し、ここでもリクエストの示すデータがキャッシュされていないため、リクエストをそのまま転送して、サーバ1にリクエストメッセージ88を送信する。
 サーバ1は、リクエストメッセージ88がバイトレンジリクエストではなく、通常のリクエストであるため、リクエストメッセージ88の応答として、指定されたバイトレンジのサブセグメントをチャンク単位で含む、ステータスコード「200」のレスポンスメッセージ89をプロキシ3に送信する。プロキシ3は、レスポンスメッセージ89を受信し、レスポンスメッセージ89のステータスコードが「200」であるため、レスポンスメッセージ89に含まれるデータをキャッシュ90すると共に、レスポンスをそのまま転送して、クライアント2にレスポンスメッセージ91を送信する。クライアント2は、レスポンスメッセージ91を受信して、セグメント#1の残りのデータをチャンク単位で取得する。
 〔MPDの他の記述例〕
 本発明では、セグメントをさらに複数のサブセグメントに分割しているが、このサブセグメントの時間長は、任意でよい。すなわち、各サブセグメントの時間長が一定であってもよいし、各サブセグメントの時間長が異なっていてもよい。
 また、本発明では、サブセグメント単位でチャンク転送するため、サブセグメントの時間長と1チャンクの時間長は一致する。クライアント2は、チャンク時間長を事前に把握しておくことにより、ライブストリーミングにおける遅延量を予測することができる。そのため、MPDにチャンク時間長が記述されていることが好ましい。チャンク時間長が固定の場合、例えば、MPDにチャンク時間長が記述してもよい。また、チャンク時間長が可変の場合、例えば、MPDにチャンク時間長の最大値および/または最小値を記述してもよい。チャンク時間長の記述例については後述する。
 また、MPEG-DASHでは、Representationを切り替えるため、Representation間で、対応する各サブセグメントの境界が揃っていることが好ましい。換言すると、Representation間で、対応する各サブセグメントの再生開始時刻が一致していることが好ましい。この場合、Representationを切り替えても、各サブセグメントの再生時刻が一致しているため、特に問題なく再生することができる。
 一方、Representation間で、対応する各サブセグメントの境界が揃っていない場合、Representationの切替後に、整合をとって再生しなければならないため、クライアント2が各サブセグメントの境界が揃っているか否かを事前に把握しておくことが好ましい。そのため、MPDに各サブセグメントの境界が揃っているか否かを示すサブセグメントの配列に関する情報が記述されていることが好ましい。このサブセグメントの配列に関する情報については後述する。
 次に、本発明で用いるMPDの他の記述例について図8に基づいて説明する。図8は、本発明で用いるMPDの他の記述例を示す図である。図8では、サブセグメントの配列に関する情報およびチャンク時間長に関する情報が記述されているMPDの一例を示す。
 図8に示すように、本発明で用いるMPD101は、図5に示すMPD100と比較して、サブセグメントの配列に関する情報およびチャンク時間長に関する情報が追記されている。
 具体的には、MPD101では、サブセグメントの配列に関する情報150として、属性「AdaptationSet@subsegmentAlignment」、およびその属性値「true」が記述されている。属性値「true」は、各サブセグメントの境界が揃っていることを示し、各サブセグメントの境界が揃っていない場合、属性値として「false」が記述される。
 また、MPD101には、高品質セグメント情報143および低品質セグメント情報144に、チャンク時間長に関する情報として、属性「maxChunkDuration」、およびその属性値「PT10S」が記述されている。属性「maxChunkDuration」は、可変のチャンク時間長の最大値を示し、属性値「PT10S」は、その最大値が10秒であることを示す。上述のように、チャンク時間長に関する情報として、固定のチャンク時間長を示す属性「chunkDuration」が記述されていても良く、可変のチャンク時間長の最小値を示す属性「minChunkDuration」が記述されていてもよい。
 また、上記属性「chunkDuration」は、セグメントの最初のチャンクの時間長と解釈してもよい。あるいは、属性「chunkDuration」の代わりに、セグメントの時間長(属性「SegmentList@duration」の値と等しい)と、セグメントの最初のチャンク時間長(属性「SegmentList@chunkDuration」の値と等しい)との差分値を示す属性「chunkDurationOffset」が記述されていてもよい。
 〔各サブセグメントの境界が揃っていない場合のRepresentationの切替例〕
 次に、各サブセグメントの境界が揃っていない場合のRepresentationの切替について図9に基づいて説明する。図9は、各サブセグメントの境界が揃っていない高品質セグメントおよび低品質セグメントのセグメントデータのデータ構造を示す図である。
 図9(a)に示すように、1024kbpsの高品質セグメント160は、moof163およびmdat164から成るサブセグメント#0と、moof165およびmdat166から成るサブセグメント#1と、moof167、169およびmdat168、180から成るサブセグメント#2とを含む。一方、512kbpsの低品質セグメント180は、moof183およびmdat184から成るサブセグメント#0と、moof185、187およびmdat186、188から成るサブセグメント#1と、moof189およびmdat190から成るサブセグメント#2とを含む。つまり、高品質セグメント160と低品質セグメント180とでは、サブセグメント#2の再生開始時刻が異なっている。
 なお、高品質セグメント160および低品質セグメント180に含まれるフラグメント(moofおよびmdat)の時間長は一定である。つまり、高品質セグメントのフラグメント163~170と、低品質セグメントのフラグメント183~190とがそれぞれ対応している。
 ここで、高品質セグメントのサブセグメント#1まで取得した後、Representationを切り替えて、低品質セグメントを取得するものとする。この場合、次に取得すべきデータは、高品質セグメントのmoof167に対応する低品質セグメントのmoof187である。ところが、低品質セグメント180では、moof185、187およびmdat186、188がサブセグメント#1となっているため、moof187以降だけを取得することはできない。そのため、再生時にギャップが生じないように、未取得のデータであるmoof187を含むサブセグメント#1から取得を開始する。このとき、moof185およびmdat186は時間的に重複して取得することとなるが、再生時に調整することによってスムーズなライブストリーミングを実現する。
 なお、上述のように、セグメントのヘッダであるsidx162、182には、各サブセグメントの時間情報が記述されており、sidxを解析して、バイトレンジを特定する。
 〔まとめ〕
 本発明の一態様に係るコンテンツ送信装置は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ再生装置に送信するコンテンツ送信装置であって、上記コンテンツ再生装置からリクエストを受信すると、当該リクエストに対する応答として、レスポンスを当該コンテンツ再生装置に送信する送信手段を備え、上記送信手段は、上記リクエストがセグメントの送信を要求するものである場合、当該セグメントを上記コンテンツ再生装置に、上記サブセグメント単位でチャンク転送する。
 本発明の一態様に係るコンテンツ送信装置の制御方法は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ再生装置に送信するコンテンツ送信装置の制御方法であって、上記コンテンツ再生装置からリクエストを受信すると、当該リクエストに対する応答として、レスポンスを当該コンテンツ再生装置に送信する送信ステップを含み、上記送信ステップにおいて、上記リクエストがセグメントの送信を要求するものである場合、当該セグメントを上記コンテンツ再生装置に、上記サブセグメント単位でチャンク転送する。
 上記の構成によれば、上記送信手段は、セグメントの送信を要求するリクエストに対して、当該セグメントをさらに複数に分割したサブセグメント単位でチャンク転送する。すなわち、送信単位は、セグメントよりさらに時間的に短いサブセグメント単位で送信すると共に、1つのリクエストで複数のサブセグメントの送信を要求することができる。そのため、サブセグメントの生成開始から配信可能になるまでの時間を短縮しつつ、複数リクエストのパイプライン化にともなうエラー処理を抑制することができる。よって、低遅延ライブストリーミングを安定的に実現することができる。
 さらに、本発明の一態様に係るコンテンツ送信装置では、上記サブセグメント単位でランダムアクセスできるように、上記セグメントが上記サブセグメントに分割されていてもよい。
 さらに、本発明の一態様に係るコンテンツ送信装置において、上記送信手段は、各サブセグメントの時間長が一定の場合、上記サブセグメントの時間長が記述されたコンテンツ管理情報をコンテンツ再生装置に送信してもよい。
 さらに、本発明の一態様に係るコンテンツ送信装置において、上記送信手段は、各サブセグメントの時間長が異なる場合、上記サブセグメントの時間長の最大値および最小値の少なくとも一方が記述されたコンテンツ管理情報をコンテンツ再生装置に送信してもよい。
 上記の構成によれば、クライアントは、チャンク転送されたサブセグメントの時間長を把握することができるため、ライブストリーミングにおける遅延量を予測することができる。
 さらに、本発明の一態様に係るコンテンツ再生装置は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ送信装置から取得して再生するコンテンツ再生装置であって、上記コンテンツ送信装置に、セグメントの送信を要求するリクエストを送信する取得手段を備え、上記取得手段は、上記リクエストに対する応答として、上記コンテンツ送信装置から、上記サブセグメント単位でチャンク転送された上記セグメントを取得する。
 さらに、本発明の一態様に係るコンテンツ再生装置の制御方法は、複数のセグメントから構成されるコンテンツであって、当該セグメントのヘッダに、当該セグメントをさらに複数に分割したサブセグメントの時間情報が記述されたコンテンツをコンテンツ送信装置から取得して再生するコンテンツ再生装置の制御方法であって、上記コンテンツ送信装置に、セグメントの送信を要求するリクエストを送信する送信ステップと、上記リクエストに対する応答として、上記コンテンツ送信装置から、上記サブセグメント単位でチャンク転送された上記セグメントを取得する取得ステップとを含む。
 〔実施例2〕
 サーバとクライアントの間のネットワーク上に発生する遅延としては、実施例1において、クライアントのリクエストしたリソースがサーバに存在しないこと等によりエラーが発生した場合、再度複数のリクエストを送信するためにネットワーク及びクライアントに負荷がかかり、遅延が発生するという問題があった。クライアントに発生する遅延としては、クライアントの有するデコーダの処理能力が低いためにデコード処理時に負荷がかかり、遅延が発生するという問題もある。
 本実施例では、クライアントのデコード処理能力に応じて、コンテンツ中の適切な情報を抽出することで、デコード処理時に発生する遅延を解消する方法について、図15~図18を参照しながら以下に説明する。図15は、本実施例に係る伝送ストリームの構成の例を示す図である。また、図16は、本実施例に係るサーバおよびクライアントの要部構成を示すブロック図である。さらに、図17は、本実施例に係る複数のフレームレートデータを多重化したストリームが受信側で分離される過程を示す図である。図18は、本実施例に係るコンテンツ内のピクチャと階層レベルを示す図である。
 現行のデジタル放送では、サーバにあたる放送局が映像、音声、その他の番組情報といった複数のデータをそれぞれ複数のパケットに格納し、1本のストリームに多重化して送出している。多重化には、MPEGのストリームフォーマットであるMPEG-2 TS(トランスポートストリーム)が用いられる。多重化されたトランスポートストリーム(TS)は、クライアントにあたる放送受信機でそれぞれのパケットに分離され、映像や音声などのデータが取得される。
 図15(a)は、従来のTSの構造を示したものである。TSは、それぞれが188バイトを有するTSパケットの集合で構成され、このTSパケットがクライアントに時系列的に入力される。このとき、各TSパケットのヘッダには、図15(a)に示されるようにパケット中のデータの種別を示すPID(Packet Identifier)が付与され、この値を用いて、分離部は、パケットのペイロードに格納された映像、音声、関連情報などを識別し、分離した上で、適切なデコーダにデータを入力できる。
 TSでは、スケーラブル符号化された複数の映像品質から構成される映像データを分離し格納したパケットに同一のPIDを付与する。そして、クライアントはデコード処理の段階で複数の映像品質データに分離することができる。即ち、1つの映像データは必ず1つのPIDで伝送される。
 一方、従来のTSにおいては、別のPIDが付加されたコンテンツは、同一のコンテンツとして認識することができない。例えば、HEVCなどの予測符号化圧縮規格で圧縮された映像データでは、各フレームをI、P、Bなどの予測方式の異なるピクチャとして圧縮することが可能であり、それぞれ別のパケットに格納して伝送することが可能であるが、TSのレベルでパケットに格納されたピクチャデータがIかPかBかを識別することはできない。このとき、他のピクチャの復号に対して参照されないBピクチャがあれば、Bピクチャのデータを除去しても再生は可能である。従って、この性質を利用すれば、クライアントの能力に応じてBピクチャデータのパケットを適宜削除し、クライアントごとにフレームレートを変えて再生することも可能である。しかし、TSを用いて伝送する場合は、前述のとおり多重化分離部でパケットを識別できないため、このような処理は不可能であった。
 上記課題に対し、本実施例では、図15(b)に示すように、PIDに加え、別のPIDが付与されたパケットが同一のコンテンツであることを示すRefPID(依存性識別子)を付与して、同一のコンテンツとして認識できるようにする。更に、本実施例では、パケットがRefPIDを含むか否かを示すフラグisRefを備える。isRefは2値のフラグであり、1のときRefPIDを含むことを示し、0のときRefPIDを含まないことを示す。
 図16は、本実施例の要部構成を示したブロック図である。図16に示すように、サーバは複数のパケットを多重化する多重化部を備え、クライアントはサーバから受信した複数のパケットが多重化されたストリームを個別のパケットに分離する多重化分離部を備えている。なお、図1と図16に示すサーバとクライアントにおいて、同様の部材に関する説明は適宜省略する。
 (サーバについて)
 サーバ送信部は、無線通信手段または有線通信手段によって、クライアントにデータを送信するものである。
 サーバ制御部は、機能ブロックとして、コンテンツ生成部および多重化部、コンテンツ送信部(送信手段)を備える構成である。ここで、コンテンツ生成部はコンテンツデータを生成するものであり、多重化部においてパケットへの分離と多重化を行って、コンテンツ送信部に出力する。例えば、I、Pピクチャデータを格納したパケットにはPIDの値pid_bを付与し、Bピクチャデータを格納したパケットにはPIDに値pid_aを付与する。さらに、Bピクチャデータを格納したパケットは、isRefの値を1とし、値pid_bのRefPIDを付与する。
 (クライアントについて)
 クライアント受信部は、無線通信手段または有線通信手段によって、サーバからデータを受信するものである。
 クライアント制御部は、機能ブロックとして、コンテンツ取得部(取得手段)および多重化分離部、コンテンツ再生部を備える構成である。ここで、コンテンツ取得部は、サーバから送られた多重化ストリームを取得し、多重化分離部に出力する。
 多重化分離部は、多重化ストリームをそれぞれのパケットに分離する。この際、PIDの値を参照することで、映像、音声、番組情報などのパケットに分離する。
 多重化分離部はさらに、パケットがRefPIDを含んでいるかを判断し、RefPIDを含んでいるパケットであれば、そのパケットのデータとRefPIDが示すパケットのデータとを、1つのコンテンツのデータとして解釈する。そして、多重化分離部で分離したそれぞれのコンテンツのデータが、コンテンツ再生部に入力される。
 なお、この際、パケットのデータとRefPIDが示すパケットのデータとは、図示しない伝送時刻情報がそれぞれのパケットヘッダに格納されており、伝送時刻情報をみて順序を一意に決めることが可能である。あるいは、図示しないシーケンス番号がパケットヘッダに格納されて、シーケンス番号から順序を一意に決めるとしてもよい。
 コンテンツ再生部は、PIDとRefPIDに従って、多重化分離部で分離された映像のパケットデータを順番に映像信号にデコードし、デコードされたピクチャデータを表示順序に適宜並べ替えた上で、表示部にそれぞれ出力する。
 図17は、上記で説明したように、I、Pピクチャデータ、Bピクチャデータをそれぞれ、PIDが値pid_bのパケット、PIDが値pid_aのパケットにそれぞれ格納して多重化されたストリームを受け取り、受け取った多重化ストリームをクライアントの多重化分離部において、PIDとRefPIDに基づいてフレームレートの異なるコンテンツデータに多重化分離されることを示した図である。このとき、I、Pピクチャデータはフレームレート60Hzの符号化データである。一方、BピクチャデータはI、Pピクチャデータの各ピクチャ間にBピクチャ1枚を挟むことで120Hzの再生を行うための付加データである。具体的には、pid_aのRefPIDがpid_bであることから、pid_aとpid_bの全てのパケットを映像デコーダに出力することで、120Hzの映像を再生する。一方、pid_bのみを映像デコーダに出力する場合、60Hzの映像が再生される。
 なお、本実施例においては、isRef、RefPIDをパケットヘッダに付与する構成としたが、格納する場所はこれに限定されず、例えば既に実施例1で説明したのと同様、図16に示すMPD記憶装置に格納しているMPDに記述してもよい。あるいはMPD以外のコンテンツの伝送に関わる伝送情報や、コンテンツの再生に係る再生情報のメタデータの一部として記述してもよい。あるいはさらに、PIDの値自身にコンテンツ同士が同一のコンテンツであることを示す情報を記述し、PIDがRefPIDを兼ねることで、RefPIDを付加しない構成としてもよい。また、RefPIDを必須とし、isRefを省略した構成も可能である。
 例えば、現行のデジタル放送において使われているPAT/PMT(Program Association Table/Program Map Table)をベースに、伝送情報(プログラム構成テーブル)にisRef、RefPIDを格納した例を図19(a)に示す。また、isRef、RefPIDを使う以外に、映像に複数PIDを記述した例を図19(b)に示す。図19(b)の場合には、映像が2つのPIDの付与されたデータから成ることが示され、後ろに書かれたPIDは前に書かれたPIDに依存するものと解釈する。このような伝送情報を用いることで、クライアントの多重化分離部は、必要なデータのPIDを知り、多重化ストリームから当該PIDの付与されたパケットデータのみを分離し、再生する。
 これにより、クライアントは、多重化ストリーム中で異なるPIDを持った同一コンテンツを含むパケットを識別することができ、デコード能力に応じて必要なパケットデータを取得して、デコードすることができる。上記例では、I、PピクチャデータとBピクチャデータを格納したパケットから、60Hz、120Hzのフレームレートの異なる再生を行う例を示したが、これ以外にも、例えば、スケーラブル符号化において低解像度ベースレイヤのストリームデータと高解像度エンハンスメントレイヤのストリームデータを別PIDのパケットに格納し、PID、RefPIDを用いて識別することで、デコード能力の低いクライアントはベースレイヤのデータを取得し低解像度映像を再生、デコード能力の高いクライアントはベース、エンハンスメントレイヤのデータを取得し高解像度の映像を再生するといった処理も可能である。デコード能力に応じた適切なフレームレート、解像度のデータを抽出することで、デコード時に発生する遅延を解消できる。
 また、I、P、BピクチャへのPID、RefPIDの付与は上記例に限定されず、図18に示すように、多数の階層からなるBピクチャを有する場合に、I/Pピクチャのパケット(階層0)には値pid_0のPIDを付与し、階層1のBピクチャのパケットには値pid_1のPIDを付与し、同様に、階層2、3のBピクチャのパケットには値pid_2、pid_3のPIDを付与してもよい。この場合、階層1のBピクチャのパケットには値pid_0のRefPIDを付与し、同様に、階層2、3のBピクチャのパケットには値pid_1、pid_2のRefPIDを付与する。
 上記の構成によれば、上記取得手段は、セグメントの送信を要求するリクエストに対して、当該セグメントをさらに複数に分割したサブセグメント単位でチャンク転送されたセグメントを取得する。すなわち、送信単位は、セグメントよりさらに時間的に短いサブセグメント単位で送信すると共に、1つのリクエストで複数のサブセグメントの送信を要求することができる。そのため、サブセグメントの生成開始から配信可能になるまでの時間を短縮しつつ、複数リクエストのパイプライン化にともなうエラー処理を抑制することができる。よって、低遅延ライブストリーミングを安定的に実現することができる。
 さらに、本発明の一態様に係るコンテンツ再生装置では、上記サブセグメント単位でランダムアクセスできるように、上記セグメントが上記サブセグメントに分割されていてもよい。
 さらに、本発明の一態様に係るコンテンツ再生装置において、上記取得手段は、セグメントの一部の送信を要求するリクエストを送信する場合、当該セグメントの一部を含むサブセグメントのバイトレンジを特定し、特定したバイトレンジを指定する、バイトレンジテンプレートを用いたリクエストを送信してもよい。
 上記の構成によれば、上記取得手段は、セグメントの一部の送信を要求するリクエストを送信する場合、バイトレンジテンプレートを用いたリクエストを送信するため、当該リクエストに対するレスポンスのステータスコードは「200」となる。よって、コンテンツの中継装置であるプロキシを介してコンテンツを取得する場合、プロキシは、上記レスポンスに含まれるデータをキャッシュすることができる。よって、RTTを低減することができ、安定的に低遅延ライブストリーミングを実現することができる。
 さらに、本発明の一態様に係るコンテンツ配信システムは、上記コンテンツ送信装置と、上記コンテンツ再生装置とを含む。
 上記の構成によれば、コンテンツ配信システムは、上記コンテンツ送信装置および上記コンテンツ再生装置と同様の効果を奏する。
 また、コンテンツ再生装置がコンテンツ送信装置から取得する、複数のセグメントから構成されたコンテンツであって、当該セグメントがさらに複数のサブセグメントに分割されたコンテンツに対応付けられたコンテンツ管理情報のデータ構造であって、バイトレンジテンプレートが記述された、コンテンツの取得先を示す取得先情報を含むことを特徴とするコンテンツ管理情報のデータ構造も本発明の範疇に含まれる。
 なお、上記コンテンツ送信装置および上記コンテンツ再生装置は、コンピュータによって実現してもよく、この場合には、コンピュータを上記コンテンツ送信装置および上記コンテンツ再生装置の各手段として動作させることにより、上記コンテンツ送信装置および上記コンテンツ再生装置をコンピュータにて実現させる制御プログラム、及びそれを記録したコンピュータ読み取り可能な記録媒体も本発明の範疇に入る。
 本発明は上述した実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能である。すなわち、請求項に示した範囲で適宜変更した技術的手段を組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
 〔ソフトウェアによる実現例〕
 最後に、サーバ1およびクライアント2の各ブロック、特にサーバ制御部11およびクライアント制御部41は、集積回路(ICチップ)上に形成された論理回路によってハードウェア的に実現してもよいし、CPU(Central Processing Unit)を用いてソフトウェア的に実現してもよい。
 後者の場合、サーバ1およびクライアント2は、各機能を実現するプログラムの命令を実行するCPU、上記プログラムを格納したROM(Read Only Memory)、上記プログラムを展開するRAM(Random Access Memory)、上記プログラムおよび各種データを格納するメモリ等の記憶装置(記録媒体)などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアであるサーバ1およびクライアント2の制御プログラムのプログラムコード(実行形式プログラム、中間コードプログラム、ソースプログラム)をコンピュータで読み取り可能に記録した記録媒体を、上記サーバ1およびクライアント2に供給し、そのコンピュータ(またはCPUやMPU)が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。
 上記記録媒体としては、一時的でない有形の媒体(non-transitory tangible medium)、例えば、磁気テープやカセットテープ等のテープ類、フロッピー(登録商標)ディスク/ハードディスク等の磁気ディスクやCD-ROM/MO/MD/DVD/CD-R等の光ディスクを含むディスク類、ICカード(メモリカードを含む)/光カード等のカード類、マスクROM/EPROM/EEPROM(登録商標)/フラッシュROM等の半導体メモリ類、あるいはPLD(Programmable logic device)やFPGA(Field Programmable Gate Array)等の論理回路類などを用いることができる。
 また、サーバ1およびクライアント2を通信ネットワークと接続可能に構成し、上記プログラムコードを通信ネットワークを介して供給してもよい。この通信ネットワークは、プログラムコードを伝送可能であればよく、特に限定されない。例えば、インターネット、イントラネット、エキストラネット、LAN、ISDN、VAN、CATV通信網、仮想専用網(Virtual Private Network)、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、この通信ネットワークを構成する伝送媒体も、プログラムコードを伝送可能な媒体であればよく、特定の構成または種類のものに限定されない。例えば、IEEE1394、USB、電力線搬送、ケーブルTV回線、電話線、ADSL(Asymmetric Digital Subscriber Line)回線等の有線でも、IrDAやリモコンのような赤外線、Bluetooth(登録商標)、IEEE802.11無線、HDR(High Data Rate)、NFC(Near Field Communication)、DLNA(Digital Living Network Alliance)(登録商標)、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。なお、本発明は、上記プログラムコードが電子的な伝送で具現化された、搬送波に埋め込まれたコンピュータデータ信号の形態でも実現され得る。
 本発明は、MPEG-DASH規格のコンテンツを送信するコンテンツ送信装置、および、当該コンテンツを取得・再生するコンテンツ再生装置に利用することができる。
 1  サーバ
 2  クライアント
 3  プロキシ
 4  MPD記憶装置
 5  セグメント記憶装置
 6  コンテンツ配信システム
21  コンテンツ取得部
22  コンテンツ送信部(送信手段)
51  コンテンツ取得部(取得手段)
52  コンテンツ再生部

Claims (13)

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

* 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 ソニー株式会社 受信装置、受信方法、送信装置、及び、送信方法
WO2016002493A1 (ja) * 2014-06-30 2016-01-07 ソニー株式会社 ファイル生成装置および方法、並びにコンテンツ再生装置および方法
WO2016002498A1 (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 ソニー株式会社 情報処理装置、情報処理方法及び情報処理プログラム

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 シャープ株式会社 コンテンツ再生装置
US11102261B2 (en) * 2013-03-14 2021-08-24 Arris Enterprises Llc Devices, systems, and methods for converting or translating dynamic adaptive streaming over HTTP (DASH) to HTTP live streaming (HLS)
WO2015064212A1 (ja) * 2013-10-30 2015-05-07 ソニー株式会社 送信装置、送信方法、受信装置、及び、受信方法
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 株式会社東芝 通信装置、通信方法及びプログラム
MX2019005456A (es) * 2016-11-10 2019-08-12 Ericsson Telefon Ab L M Segmentacion de recursos para mejorar el rendimiento de entrega.
US11316568B2 (en) 2017-01-09 2022-04-26 Telefonaktiebolaget Lm Ericsson (Publ) Controllable beam management accuracy
US11647251B2 (en) 2017-07-12 2023-05-09 Telefonaktiebolaget Lm Ericsson (Publ) Fast tune-in for low latency streaming
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
WO2021084588A1 (ja) * 2019-10-28 2021-05-06 ラディウス株式会社 ストリーミングデータの生成装置、ストリーミングデータの配信システム、及び、ストリーミングデータの生成方法
JP7390159B2 (ja) * 2019-10-28 2023-12-01 日本放送協会 送信装置及び受信装置
ES2940452T3 (es) * 2020-04-27 2023-05-08 Broadpeak Procedimiento y servidor para la distribución de contenido de audio y/o vídeo
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
JP5238069B2 (ja) * 2008-04-25 2013-07-17 フラウンホッファー−ゲゼルシャフト ツァ フェルダールング デァ アンゲヴァンテン フォアシュンク エー.ファオ トランスポート・データストリーム内で参照するフレキシブル・サブストリーム
US7860996B2 (en) * 2008-05-30 2010-12-28 Microsoft Corporation Media streaming with seamless ad insertion
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
WO2010108053A1 (en) * 2009-03-19 2010-09-23 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
WO2012011490A1 (ja) 2010-07-20 2012-01-26 シャープ株式会社 コンテンツ取得装置、コンテンツ送信装置、コンテンツ送受信システム、データ構造、制御方法、制御プログラム、及び記録媒体
WO2012011473A1 (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
WO2011100901A2 (zh) 2011-04-07 2011-08-25 华为技术有限公司 媒体内容的传输处理方法、装置与系统
CN109618185A (zh) * 2012-07-10 2019-04-12 Vid拓展公司 由wtru执行的方法、wtru及编码设备
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 (20)

* 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
WO2016002493A1 (ja) * 2014-06-30 2016-01-07 ソニー株式会社 ファイル生成装置および方法、並びにコンテンツ再生装置および方法
WO2016002498A1 (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

Also Published As

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

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) Av데이터 수신시 버퍼량을 컨텐츠 속성에 따라탄력적으로 조절하는 방법 및 장치
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