Nothing Special   »   [go: up one dir, main page]

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

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

Info

Publication number
WO2012046487A1
WO2012046487A1 PCT/JP2011/066270 JP2011066270W WO2012046487A1 WO 2012046487 A1 WO2012046487 A1 WO 2012046487A1 JP 2011066270 W JP2011066270 W JP 2011066270W WO 2012046487 A1 WO2012046487 A1 WO 2012046487A1
Authority
WO
WIPO (PCT)
Prior art keywords
content
request
clock
response
server
Prior art date
Application number
PCT/JP2011/066270
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 シャープ株式会社
Publication of WO2012046487A1 publication Critical patent/WO2012046487A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47202—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/242—Synchronization processes, e.g. processing of PCR [Program Clock References]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/654—Transmission by server directed to the client
    • H04N21/6543—Transmission by server directed to the client for forcing some client operations, e.g. recording
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server

Definitions

  • the present invention includes a content reproduction apparatus that acquires and reproduces content, a synchronization method of the content reproduction apparatus, a control program for the content reproduction apparatus, a recording medium that records the control program, and the content reproduction apparatus
  • the present invention relates to a content distribution system.
  • VOD video on demand
  • content is provided to clients by a streaming method, a download method, or a progressive download method.
  • a clock drift countermeasure for correcting a clock shift between the content providing device and the content acquisition device is taken in order to avoid a streaming failure.
  • the above problem is solved by clock synchronization by PCR (Program Clock Reference), RTP (Real-Time Protocol), NTP (Network Time Protocol) / SNTP (Simple Network Time Protocol), and the like.
  • PCR Program Clock Reference
  • RTP Real-Time Protocol
  • NTP Network Time Protocol
  • SNTP Simple Network Time Protocol
  • FIG. 14 is a schematic diagram showing a transmission method in the MPEG-2 System.
  • MPEG-2 System is a standard used in, for example, terrestrial digital broadcasting.
  • the transmitter transmits video signals and audio signals to the receiver in units of TS packets (188 bytes). Further, the transmitter transmits the PCR to the receiver at a predetermined interval (about 100 msec), and the receiver performs clock synchronization based on the received PCR.
  • Clock synchronization by PCR is a technique for countering clock drift that is useful for broadcasting networks and the like that have almost no fluctuation (jitter) in the transmission delay time of TS packets.
  • RTP (see Non-Patent Document 2) used in IPTV or the like having a transmission packet delay time jitter but relatively small
  • a transmission time is assigned to each RTP packet.
  • the transmitter transmits the system time of the transmitter to the receiver about every 1 msec.
  • the receiver receives the RTP packet and measures the error between the internal clock and the reception clock (time in the Timestamp field of the RTP header). When this measurement is repeated, the measured error basically has a distribution as shown in FIG. 16 with respect to the occurrence frequency. Based on this distribution, the receiver performs statistical processing on a plurality of measurement results (errors) to obtain a correction value of the internal clock (for example, an error value with the highest occurrence frequency).
  • RTP increases the frequency of transmitting the system time of the transmitter compared to the PCR transmission frequency in MPEG-2 System, so that jitter is relatively small even when there is fluctuation (jitter) in the transmission delay of TS packets. In some cases, it can be removed or reduced by statistical processing. Therefore, clock synchronization between the transmitter and the receiver can be executed with high accuracy.
  • NTP / SNTP is a protocol dedicated to clock synchronization and can be operated independently of video transmission. Also, NTP / SNTP normally operates on UDP, and the UDP port number 123 is used.
  • FIG. 17 is a diagram showing a request / response transmission / reception sequence in the clock synchronization of the client and the server (NTP server) in NTP / SNTP.
  • RTC Real Time Clock
  • Tc a clock unique to the client device
  • Ts RTC of the server
  • the client transmits a request including the request transmission time Tc0 to the server (S1001).
  • the server receives the request and transmits a response including the request reception time Ts0, the response transmission time Ts1, and Tc0 to the client (S1002).
  • the client receives the response, and sets the time when the response is received as Tc1. In this way, the client knows Tc0, Tc1, Ts0, and Ts1.
  • Japanese Published Patent Publication Japanese Patent Laid-Open No. 2001-148712 (Publication Date: May 29, 2001)”
  • Japanese Patent Publication Japanese Patent Laid-Open No. 2002-55890 (Publication Date: Published on February 20, 2002)”
  • FIG. 18 is a diagram illustrating a data structure of content transmitted using DASH.
  • DASH is a video transmission method based on the 3GPP streaming method (TS 26.234 ver 9.3.0), and realizes adaptive streaming led by clients.
  • MP4 or MPEG-2TS is used as a content transmission format
  • HTTP is used as a content transmission protocol.
  • the content transmission format is MP4.
  • DASH content (MP4 file) is divided into a plurality of Media segments.
  • the content is divided, for example, in units of GOP (Group Of Picture) in image coding.
  • DASH includes a plurality of MP4 files having different quality types (reproduction quality such as bit rate and type such as data format) for one content.
  • the content is transmitted, and the quality type of each content and the MPD file (control data) that controls each Media ⁇ Segment are transmitted.
  • the MPD file is a metafile for adaptive streaming.
  • one Media1Segment is transmitted by one HTTP request / response.
  • the conventional clock drift countermeasure is an effective method for a transmission method in which the jitter of the IP packet transmission delay time is relatively small, and cannot be applied as it is to a DASH having a large jitter of the IP packet transmission delay time. .
  • the clock can be corrected with sufficient accuracy even if the PCR transmission frequency is relatively low.
  • DASH when the transmission frequency of information indicating the time corresponding to PCR is increased, the accuracy of clock correction is improved, but the load of clock correction processing is increased.
  • DASH handles MP4 in addition to TS, but since MP4 does not have information corresponding to PCR, the MPEG-2 System method cannot be applied as it is.
  • an MP4 / MPEG-2TS file is divided into Media segments of a unit of about 0.5 to several seconds, and a plurality of Media segments are divided. create.
  • an HTTP header is generated by adding an HTTP header to each Media Segment.
  • an HTTP message in which an HTTP header is added to one Media Segment is further divided, and one IP packet is about 1500 bytes.
  • An IP packet is created so that Then, a TCP / IP header is added to each IP packet. Since data is transmitted in this manner in DASH, the first IP packet of the HTTP message includes the HTTP header, but the second and subsequent IP packets do not include the HTTP header. The transmission time cannot be stored for every IP packet.
  • Patent Document 1 describes that a client acquires time data from a header portion of a response packet received as an access response to a WWW server, and adjusts the client's RTC to the time indicated by the acquired time data. Further, in Patent Document 2, when the communication device is activated, the communication device accesses the WWW server, acquires the Japanese standard time from the home page information of the WWW server, and adjusts the RTC of the communication device to the Japanese standard time. Are listed.
  • Patent Documents 1 and 2 the client performs clock synchronization when downloading data such as an HTML file from the server. For this reason, when receiving time information for clock correction, resources that may cause jitter are acquired simultaneously or successively. Since Patent Documents 1 and 2 assume Web browsing and the like rather than streaming playback of video content, even if jitter occurs during clock synchronization, there is no significant effect on server service provision. Therefore, the inventions described in Patent Documents 1 and 2 do not perform clock synchronization in consideration of the influence of jitter inherent to TCP / IP.
  • the present invention has been made in view of the above-described problems, and an object of the present invention is to remove or reduce a jitter factor in TCP / IP and perform a content synchronization apparatus that performs clock synchronization with high accuracy of clock correction, and the content reproduction.
  • a content playback apparatus acquires content from a content distribution apparatus using HTTP (HyperText ⁇ Transfer Protocol), and plays back the acquired content. Included in the HTTP header in the response received by the request execution unit, and the request execution unit that transmits a request requesting transmission of the request to the content distribution device and receives a response to the request that does not include a resource. And a clock correction means for correcting the clock of the own apparatus based on the time information.
  • HTTP HyperText ⁇ Transfer Protocol
  • the content reproducing apparatus synchronization method is a content reproducing apparatus synchronization method for acquiring content from a content distribution apparatus by HTTP and reproducing the acquired content, wherein A request transmission step of transmitting a request for requesting transmission of information to the content distribution device, a response reception step of receiving a response that is a response to the request transmitted in the request transmission step and does not include a resource, and the response And a clock correction step of correcting the clock of the own apparatus based on time information included in the HTTP header in the response received in the reception step.
  • the request execution means transmits a request for requesting transmission of meta information related to a resource to the content distribution apparatus, and receives a response that does not include a resource, in response to the transmitted request.
  • amendment means correct
  • the request execution means receives and receives a response including time information used by the clock correction means to correct the clock of its own device by transmitting and receiving a request and response with a small amount of data. Therefore, it is possible to suppress the occurrence of packet transmission delay due to waiting for retransmission of the preceding packet and waiting for completion of reception when the content reproduction device performs its own clock correction. Therefore, the content reproduction apparatus can increase the accuracy of clock correction by removing or reducing the influence of jitter caused by TCP.
  • the content playback apparatus is a content playback apparatus that acquires content from a content distribution apparatus by HTTP (HyperText Transfer Protocol) and plays back the acquired content, and transmits meta information related to resources.
  • a request execution unit that transmits a request to the content distribution device and receives a response that is a response to the request and does not include a resource, and time information included in an HTTP header in the response received by the request execution unit. Based on this, the clock correction means for correcting the clock of the device itself is provided.
  • the content playback apparatus synchronization method is a content playback apparatus synchronization method for acquiring content from a content distribution apparatus by HTTP and playing back the acquired content, and requests transmission of meta information related to a resource.
  • a request transmission step for transmitting a request to the content distribution device; a response reception step for receiving a response that is a response to the request transmitted in the request transmission step and does not include a resource; and received in the response reception step And a clock correction step of correcting the clock of the own apparatus based on time information included in the HTTP header in the response.
  • the content reproduction apparatus can increase the accuracy of clock correction by removing or reducing the influence of jitter caused by TCP.
  • FIG. 1 illustrates a first embodiment of the present invention, and is a block diagram illustrating an outline of a content distribution system and a configuration of main parts of devices included in the content distribution system. It is a figure which shows an example of the data stored in a clock correction data storage part. It is a sequence diagram of a request / response between a client and a server in clock synchronization during content transmission.
  • 4A is a diagram illustrating an example of a request message transmitted from the client to the server
  • FIG. 4B is a diagram illustrating an example of a response message transmitted from the server to the client.
  • It is a flowchart which shows an example of the clock synchronization process which a client performs.
  • FIG. 6A is a diagram illustrating an example of a request message transmitted from the client to the server
  • FIG. 6B is a diagram illustrating an example of a response message transmitted from the server to the client.
  • It is a figure which shows the example which expanded the description of the MPD file.
  • It is a flowchart which shows an example of the procedure of a Date field precision insufficient countermeasure.
  • It is a graph which shows the relationship between response time and occurrence frequency. It is the graph which plotted the time of the client clock, the time of the server clock, and the Date field value with respect to real time.
  • It is the graph which plotted the difference value of the time of a server clock and a Date field value, and the difference value of the time of a client clock and a Date field value with respect to real time.
  • FIG. 1 is a diagram illustrating an overview of the content distribution system 1 according to the first embodiment and a configuration of main parts of each device constituting the content distribution system 1.
  • the content distribution system 1 includes a server (content distribution device) 2 and a client (content reproduction device) 3.
  • the content distribution system 1 includes a content storage unit 5 connected to the server 2 and a clock correction data storage unit 6 connected to the client 3.
  • the server 2 and the client 3 are connected via a network 4.
  • the network 4 may be any network as long as the server 2 and the client 3 can communicate with each other, and may be a wired communication network or a wireless communication network.
  • the content distribution system 1 includes one server 2 and one client 3, but the present invention is not limited to this.
  • the content distribution system 1 may include a plurality of servers 2 and may include a plurality of clients 3. In other words, the content distribution system 1 only needs to include at least one server 2 and one client 3.
  • the transmission protocol on the network 4 in the content distribution system 1 is HTTP, which is widely used as a general-purpose file transmission protocol.
  • the content distributed by the server 2 is video content, and the content is segmented MP4 data. That is, in the present embodiment, the content distribution system 1 transmits and receives content using DASH. Specifically, when the content is requested from the client 3, the server 2 transmits segmented MP4 data or MPD file to the client 3.
  • the server 2 is a content distribution device that receives a request message (request) requesting transmission of content from the client 3 and transmits a response message (response) to the received request message. As described above, both the request message and the response message are HTTP messages.
  • the server 2 is connected to a content storage unit 5 that stores content such as moving images, and manages the content stored in the content storage unit 5.
  • the content storage unit 5 may be built in the server 2. Alternatively, a configuration including an encoder that generates content in real time instead of the content storage unit 5 may be used.
  • the server 2 may simultaneously distribute the same content to an unspecified number of devices, may distribute the content to a single device, or may simultaneously distribute the same content to a plurality of determined devices. May be delivered.
  • the server 2 counts the server control unit 11 that controls and controls the operation of the server 2, the server communication unit 12 for the server 2 to communicate with an external device, and the RTC of the server 2.
  • the server clock 13 is provided.
  • the server control unit 11 includes a response execution unit 14.
  • the response execution unit 14 When the response execution unit 14 receives a request message from the client 3 via the server communication unit 12, the response execution unit 14 transmits a response message to the received request message to the client 3. For example, when receiving a request message for requesting content transmission from the client 3, the response execution unit 14 reads the content requested by the client from the content storage unit 5 and transmits the read content to the client 3.
  • the client 3 is a device that requests and acquires content and reproduces the acquired content. As described above, the client 3 is connected to the clock correction data storage unit 6 that stores information about clock correction executed by the client 3 (details will be described later), and the information stored in the clock correction data storage unit 6 Manage.
  • the clock correction data storage unit 6 may be built in the client 3.
  • the client 3 includes an input unit that receives a user operation, and requests content based on the input operation received by the input unit.
  • the client 3 includes a client control unit 21 that controls and controls the operation of the client 3, a client communication unit 22 for the client 3 to communicate with an external device, and a client that counts the RTC of the client 3. And a clock (clock) 23.
  • the client control unit 21 includes a request execution unit (request execution unit) 31, a content reproduction unit 32, a transmission / reception time acquisition unit 33, a server clock acquisition unit 34, an error calculation unit 35, and a clock correction unit (clock correction unit) 36. It is included.
  • the request execution unit 31 transmits a TCP synchronization request (SYN) for establishing a TCP session with the server 2 to the server 2 and establishes a TCP session with the server 2.
  • SYN TCP synchronization request
  • the request execution unit 31 generates a request message for requesting transmission of content, transmits the request message to the server 2 via the client communication unit 22, and sends a response message including the segmented content and the MPD file as a response thereto.
  • Receive As described above, the content transmitted from the server 2 is transmitted after being divided into a plurality of segments.
  • the content playback unit 32 restores and plays back content from the segmented content acquired together according to the acquired MPD file acquired by the request execution unit 31. For example, when the acquired content is a moving image content, the content reproduction unit 32 decodes the acquired content, and the video and audio obtained thereby are displayed on the external display device based on the client clock 23. (Not shown).
  • the transmission / reception time acquisition unit 33 records the time when the request execution unit 31 transmits a request for executing clock correction as Tc0. Further, the time when the request execution unit 31 receives a response to the request for executing the clock correction is recorded as Tc1. Note that a request transmitted by the request execution unit 31 to execute clock correction will be described later with reference to another drawing.
  • the transmission / reception time acquisition unit 33 may hold the recorded times Tc0 and Tc1 internally or may store them in the clock correction data storage unit 6 connected to the client 3.
  • the transmission / reception time acquisition unit 33 outputs the recorded Tc0 and Tc1 to the error calculation unit 35.
  • the server clock acquisition unit 34 extracts a Date field value (time information) indicating the time when the server 2 transmits the response, which is included in the HTTP header of the response received by the request execution unit 31, and the Date field value indicates The time is recorded as Ts.
  • the server clock acquisition unit 34 may internally store the recorded time Ts or may store it in the clock correction data storage unit 6 connected to the client 3.
  • the error calculation unit 35 acquires Tc0 and Tc1 from the transmission / reception time acquisition unit 33 and Ts from the server clock acquisition unit 34, respectively, and based on Tc0, Tc1 and Ts, the error between the RTC of the client 3 and the RTC of the server 2 Td is calculated.
  • the clock correction unit 36 corrects the clock of the client clock 23 based on the error Td calculated by the error calculation unit 35.
  • the clock correction data storage unit 6 stores information related to clock correction. Specifically, the clock correction data storage unit 6 stores Tc0 and Tc1 acquired by the transmission / reception time acquisition unit 33, Ts acquired by the server clock acquisition unit 34, and the error Td calculated by the error calculation unit 35. .
  • the information stored in the clock correction data storage unit 6 may be data as shown in FIG. 2, for example.
  • FIG. 2 shows data in which Tc0, Tc1, Ts, and Td are arranged as a set for each request. In the example illustrated in FIG. 2, the times of Tc0, Tc1, and Ts are indicated by “hour: minute: second”.
  • the unit of Td is microseconds.
  • FIG. 3 is a sequence diagram of a request / response between a client and a server in clock synchronization during content transmission.
  • the client 3 transmits a TCP synchronization request (SYN) to the server 2 (S101), and establishes a TCP session (SS1) for acquiring content (S102). Then, the client 3 acquires content from the server 2 using HTTP and performs streaming playback of the moving image (S103).
  • SYN TCP synchronization request
  • SS1 TCP session
  • Client 3 performs clock synchronization with server 2 in order to prevent streaming failure while performing streaming playback.
  • the client 3 establishes a TCP session (SS2) for performing clock synchronization separately from the TCP session (SS1) for acquiring the currently established content.
  • the client 3 transmits a TCP synchronization request (SYN) to the server 2 (S104).
  • the server 2 that has received the TCP synchronization request (SYN) returns a TCP synchronization request (SYN) and a response (ACK) to the client 3 (S105).
  • the client 3 that has received the TCP synchronization request (SYN) and the response (ACK) transmits a response (ACK) to the server 2 and newly establishes a TCP session (SS2) (S106).
  • the client 3 transmits a request using the HTTP Head method to the server 2 in the newly established TCP session (SS2) for performing clock synchronization (S107).
  • the server 2 that has received the request transmits a response to the request to the client 3 (S108).
  • the client 3 that has received the response performs clock correction based on the request transmission time Tc0, the response reception time Tc1, and the response transmission time Ts indicated by the Date field value included in the response.
  • the TCP session (SS1) for acquiring content and the TCP session (SS2) for executing clock synchronization are logically independent TCP sessions (communication paths).
  • FIG. 4 shows an example of a request / response message exchanged between a client and a server in a TCP session (SS2) for executing clock synchronization.
  • FIG. 4A is a diagram illustrating an example of a request message transmitted from the client 3 to the server 2.
  • FIG. 4B is a diagram illustrating an example of a response message transmitted from the server 2 to the client 3.
  • FIG. 5 is a flowchart illustrating an example of the clock synchronization process executed by the client 3. Note that the flow chat in FIG. 5 shows a processing example of the client 3 from the establishment of the TCP session (SS2) for performing clock synchronization until the clock correction is performed.
  • SS2 TCP session
  • the request execution unit 31 of the client 3 transmits a request to the server 2 using the HTTP Head method (S201).
  • the transmission / reception time acquisition unit 33 records the time when the request execution unit 31 transmits the request as Tc0 (S202).
  • the transmission / reception time acquisition unit 33 records the time when the request execution unit 31 receives the response as Tc1 (S204). Further, the server clock acquisition unit 34 extracts the Date field value included in the response received by the request execution unit 31, and records the time indicated by the Date field value as Ts (S205).
  • the error calculation unit 35 acquires Tc0 and Tc1 from the transmission / reception time acquisition unit 33, and Ts from the server clock acquisition unit 34, respectively.
  • Td (Tc1 + Tc0) / 2 ⁇ Ts (3)
  • an error Td between the RTC of the client 3 and the RTC of the server 2 is calculated (S206).
  • the error calculation unit 35 outputs the calculated error Td to the clock correction unit 36.
  • the clock correction unit 36 corrects the clock of the client clock 23 based on the error Td calculated by the error calculation unit 35 (S207).
  • the client 3 periodically executes S201 to S207 to synchronize the client clock 23 with the server clock 13 so that the streaming does not fail.
  • the server 2 since the Date field value of the HTTP response is used as the server clock, the server 2 does not need to synchronize with another external server and does not require clock correction. Further, since the Date field value of the HTTP response is used, the server 2 does not need to have a special function and can use a conventional device as it is. That is, the transmission protocol used by the server 2 and the file format of the content managed by the server 2 can be used as they are.
  • a request / response for clock synchronization is exchanged using a TCP session (SS2) for executing clock synchronization independently of a TCP session (SS1) for acquiring content. Therefore, the client 3 can acquire the required number of times and the server clock Ts at any timing without being affected by the content transmission / reception status, transmission / reception speed, and the like. Specifically, the client 3 can perform clock correction at an arbitrary timing even when waiting for retransmission of a packet or waiting for completion of reception in content transmission occurs.
  • the HTTP Head method since the HTTP Head method is used in S201, the response received by the client 3 in S203 includes only the HTTP header and the resource meta information, and does not include the resource entity. . For this reason, the amount of response data received by the client 3 in S203 is very small, and is normally included and transmitted in a single IP packet (even if not included in a single IP packet, 2 to It can be composed of 3 IP packets). Therefore, in a clock-synchronized TCP session, the amount of data transmitted and received at a time is small, and a large number of server clocks can be acquired in a short period of time.
  • the HTTP response can be contained in one packet (or several packets), and the occurrence of waiting for retransmission of the preceding packet and waiting for completion of reception can be suppressed.
  • the request that the client 3 transmits to the server 2 may be a request that requests transmission of meta information related to the resource, and is not limited to a request that uses the Head method.
  • a request that uses the Head method For example, an Options method may be used (this modification will be described later). It will be apparent that the response data size can be kept extremely small for any request that does not include the resource entity in the response.
  • the influence of jitter caused by TCP can be removed or reduced, so that clock correction can be performed with high accuracy.
  • the client 3 acquires the RTC of the server 2 by an HTTP message using the Head method, but the method of acquiring the RTC of the server 2 is not limited to this.
  • the Options method may be used instead of the Head method.
  • the client 3 may transmit a request message illustrated in FIG. 6A to the server 2, and the server 2 may transmit a response message illustrated in FIG. 6B to the client 3.
  • the server 2 transmits a response in the HTTP header of the response to the request transmitted by the server 2, as shown in FIG. Since the Date field value indicating the time is included, the client 3 can acquire the server clock time Ts.
  • the HTTP message using the Options method has a small amount of data transmitted and received at a time, so that an HTTP response can be accommodated within several packets, waiting for retransmission of the preceding packet, and receiving The occurrence of waiting for completion can be suppressed.
  • the request execution unit 31 when acquiring the RTC of the server 2, transmits a request to the server 2 using a method for requesting transmission of meta information related to the resource, and receives a response to the transmitted request. do it.
  • the client 3 transmits a request for requesting transmission of an MPD file using the Get method instead of the Head method.
  • the Date field value included in the response to the request may be acquired.
  • the HTTP response can be accommodated within several packets. Therefore, even when a request for requesting transmission of an MPD file is transmitted using the Get method, the influence of jitter can be removed or reduced. Alternatively, even when a request that requests transmission of a part of content is transmitted using the Get method to which the Range request header is added, the influence of jitter can be removed or reduced.
  • the MPD file generation time (time information) included in the MPD file is used instead of the Date field value.
  • the acquired MPD file generation time may be used as the server clock Ts.
  • the client 3 may acquire the MPD file generation time in the MPD file included in the response to the request by transmitting a request for requesting transmission of the MPD file using the Get method.
  • Fig. 7 shows an example of extending the description of the MPD file.
  • the MPD file generation time is described in the MPD file.
  • the server 2 manages a plurality of content files having different quality types for one content, divides the one content file in a predetermined unit, and manages the content file in Media Segment (segment) unit. Furthermore, it manages the MPD file (control data) that controls the content quality type and each Media Segment.
  • FIG. 8 is a flowchart showing an example of a procedure for measures against date field inaccuracy.
  • the client 3 acquires the server clock Ts repeatedly at regular intervals in a short time (S211). Specifically, the influence (average error: 0.5 second, minimum 0 second to maximum 1 second error) of the Date field included in the measurement result (acquired Ts) is determined for each sample (hereinafter acquired Ts, Tc0). 5 are repeatedly executed at intervals of M / N (M and N are relatively prime integers) seconds so that Ts of Tc1 and Tc1 is referred to as a sample is uniformly distributed. Acquire (measure). For example, the client 3 measures for 10 seconds at 100 msec intervals.
  • the measurement interval may be reset according to the response time.
  • a separate TCP session may be established for each measurement sample.
  • the influence of the Date field is uniformly distributed over the Ts of each sample regardless of the measurement interval. Therefore, a configuration in which the measurement interval is not constant may be used.
  • the error calculation unit 35 calculates the response time (Tc1-Tc0) of each sample, and excludes (discards) samples having a long response time as shown in FIG. 9 (S212).
  • FIG. 9 is a graph showing the relationship between response time and occurrence frequency (number of samples). The horizontal axis in FIG. 9 indicates the response time, and the vertical axis indicates the occurrence frequency.
  • a predetermined threshold value e.g., 1 second
  • all samples may be arranged in the order of the length of response time, and samples included in a predetermined ratio (for example, 5%) from those having a long response time may be discarded.
  • the average value ⁇ and the standard deviation ⁇ of the response time may be obtained, and samples that are slower than the average ⁇ by a predetermined value (eg, 6 ⁇ ) or more may be discarded. Since samples with a short response time are considered to be reliable data (not affected by jitter), the effects of jitter can be eliminated or reduced by excluding samples with a long response time. Since the influence of jitter appears in the response time, it can be processed regardless of the accuracy of the Date field.
  • a predetermined value eg, 6 ⁇
  • the error calculation unit 35 calculates each error Td for the sample remaining in the process of S212 (S213). Then, an average value Ta of the error Td of each sample calculated by the clock correction unit 36 is calculated (S214).
  • FIG. 10 is a graph in which the time Tc of the client clock 23, the time Ts of the server clock 13 and the Date field value are plotted with respect to real time.
  • the horizontal axis indicates the real time (actual elapsed time), and the vertical axis indicates the clock value (time).
  • the client clock 23 moves faster than the server clock 13 by a predetermined time. It is ideal to calculate the time lag between the two as the clock correction amount Td '.
  • the time indicated by the Date field value is the time when the server clock 13 is rounded down to the second accuracy.
  • the difference value between the time Ts of the server clock 13 and the Date field value and the difference value between the time Tc of the client clock 23 and the Date field value are plotted with respect to real time in FIG. is there.
  • the horizontal axis in FIG. 11 indicates real time (actual elapsed time), and the vertical axis indicates the difference value of the clock (time).
  • the error Td of each sample calculated in S213 is the vicinity of the graph indicating the difference value between the time Tc of the client clock 23 and the Date field value shown in FIG. Distributed uniformly (ideally coincides with the graph). Therefore, in S214, Td 'can be estimated by calculating the average value Ta of the errors Td.
  • FIGS. 12 and 13 A second embodiment of the present invention will be described with reference to FIGS. 12 and 13 as follows.
  • the server configuration and the clock synchronization processing executed by the client are different from those in the first embodiment in order to reduce the load on the server that provides the content.
  • differences from the first embodiment will be mainly described.
  • FIG. 12 is a diagram illustrating an overview of the content distribution system 10 according to the second embodiment and a configuration of main parts of each device configuring the content distribution system 10.
  • the content distribution system 10 includes an MPD distribution server (control data distribution device) 7, an MP4 distribution server (content distribution device) 8, and a client (content reproduction device) 9.
  • the content distribution system 10 includes an MPD file storage unit 75 connected to the MPD distribution server 7, an MP4 file storage unit 85 connected to the MP4 distribution server 8, and clock correction data connected to the client 9. And a storage unit 6.
  • the content distribution system 10 includes one MPD distribution server 7, one MP4 distribution server 8, and one client 9, but the present invention is not limited to this.
  • the content distribution system 10 may include a plurality of MPD distribution servers 7, MP4 distribution servers 8, and clients 9.
  • the content distribution system 10 may include at least one MPD distribution server 7, MP4 distribution server 8, and client 9.
  • contents are distributed from the MPD distribution server 7 and the MP4 distribution server 8 to the client 9 using DASH.
  • the content format is the MP4 file format.
  • the content format distributed by the MP4 distribution server 8 is not limited to this.
  • the content distribution system 10 divides the functions of the server 2 of the first embodiment, and manages the MPD file and the MPD file 7 respectively.
  • an MP4 distribution server 8 that manages That is, the MPD distribution server 7 manages the MPD file shown in FIG. 18, while the MP4 distribution server 8 manages each MP4 file having different quality types, which is composed of Media Segment, shown in FIG. .
  • the client 9 requests content from the MPD distribution server 7.
  • the MPD distribution server 7 Upon receiving the request, the MPD distribution server 7 returns an MPD file including information (for example, URL) indicating the content acquisition destination MP4 distribution server 8 to the client, and the client 9 transmits the designated MP4 distribution.
  • MP4 is acquired from the server 8.
  • the MPD distribution server 7 is a content distribution apparatus that receives a request message (request) requesting transmission of content from the client 9 and transmits a response message (response) to the received request message.
  • the MPD distribution server 7 manages the content quality type managed by the MP4 distribution server 8 and the MPD file (control data) that controls each segment. Further, as described above, the MPD distribution server 7 transmits an MPD file including information (for example, URL) indicating the content acquisition destination MP4 distribution server 8 as a response message.
  • the MPD file storage unit 75 may be built in the MPD distribution server 7.
  • the MPD distribution server 7 includes an MPD distribution server control unit 71 that controls the operation of the MPD distribution server 7 and MPD distribution server communication for allowing the MPD distribution server 7 to communicate with an external device. And an MPD distribution server clock 73 that counts the RTC of the MPD distribution server 7.
  • the MPD distribution server control unit 71 includes a response execution unit 74.
  • the response execution unit 74 When the response execution unit 74 receives a request message from the client 9 via the MPD distribution server communication unit 72, the response execution unit 74 transmits a response message to the received request message to the client 9. For example, when receiving a request message for requesting content transmission from the client 9, the response execution unit 74 transmits an MPD file including information indicating the MP4 distribution server 8 from which the content is acquired to the client 9. When a request message requesting an MPD file is received from the client 9, the MPD file is read from the MPD file storage unit 75 and the read MPD file is transmitted to the client 9.
  • the MP4 distribution server 8 is a content distribution apparatus that receives a request message (request) requesting transmission of content from the client 9 and transmits a response message (response) to the received request message. Also, the MP4 distribution server 8 manages a plurality of content files having different quality types for one content, divides the one content file in a predetermined unit, and manages the content file in a Media Segment (segment) unit. Note that the MP4 file storage unit 85 may be built in the MP4 distribution server 8.
  • the MP4 distribution server 8 includes an MP4 distribution server control unit 81 that controls the operation of the MP4 distribution server 8 and MP4 distribution server communication for the MP4 distribution server 8 to communicate with an external device.
  • the MP4 distribution server control unit 81 includes a response execution unit 84. Note that the MP4 distribution server clock 83 is assumed to be synchronized with the MPD distribution server clock 73 using means such as NTP.
  • the response execution unit 84 When the response execution unit 84 receives a request message from the client 9 via the MP4 distribution server communication unit 82, the response execution unit 84 transmits a response message to the received request message to the client 9. For example, when receiving a request message for requesting content transmission from the client 9, the response execution unit 84 reads the MP4 file from the MP4 file storage unit 85 and transmits the read MP4 file to the client 9.
  • the client 9 is a device that requests and acquires content and reproduces the acquired content.
  • the client 9 is different in the configuration of the client 3 and the client control unit 24 of the first embodiment.
  • the client control unit 24 further includes a server clock acquisition count setting unit 37 and a determination unit 38 in addition to the configuration of the client control unit 21 of the first embodiment.
  • the request execution unit 31 acquires the MPD file shown in FIG. 7 from the MPD distribution server 7 before establishing a TCP session (SS2) for executing clock synchronization (for example, at the time of content acquisition). It is assumed that the server that receives and performs clock synchronization is designated. Specifically, the request execution unit 31 refers to the clock source (clock synchronization target designation information) included in the MPD file shown in FIG. 7, and the MPD distribution server (server device) of the URL described in the clock source. 7 or the server clock Ts is acquired from the MP4 distribution server (server device) 8. In the example shown in FIG. 7, only one URL is described in the clock source, but a plurality of URLs may be described. In this case, the request execution unit 31 selects at least one from a plurality of URLs, and determines a server that is a target for clock synchronization.
  • SS2 TCP session
  • a dedicated server that performs clock synchronization with the client 9 is set, and the dedicated server and the client 9 are instructed to perform clock synchronization. can do. Therefore, the load on the server can be flexibly distributed, and clock correction can be performed stably.
  • the server clock acquisition count setting section 37 sets / updates the acquisition count of the server clock used for one clock correction executed by the clock correction section 36.
  • the server clock acquisition count setting unit 37 determines whether or not the error Td calculated by the error calculation unit 35 is greater than a predetermined value. If the error Td is greater than the predetermined value, the server clock acquisition count setting unit 37 is set to a predetermined server clock acquisition count. Add a value to update the set value of the server clock acquisition count. In the present embodiment, it is assumed that the server clock acquisition count is set to a predetermined value in advance by user input or default. The set value of the number of server clock acquisition times may be stored in the clock correction data storage unit 6.
  • the determination unit 38 determines whether or not the client 9 should execute the clock synchronization process. The determination unit 38 determines whether or not a predetermined condition is satisfied. If the predetermined condition is satisfied, the determination unit 38 transmits a request for clock synchronization to the request execution unit 31. Instruct.
  • the determination unit 38 may determine, for example, whether or not the data occupation amount in the content reception buffer (not shown) of the client 9 is within a predetermined range (less than a predetermined value or more than a predetermined value). In addition, the determination unit 38 obtains the time indicated by the Date field value (other time information) of the HTTP header (additional data) when acquiring the MPD file and / or MP4 file (Media (Segment) and the time indicated by the client clock 23. It may be determined whether or not the difference is equal to or greater than a predetermined value, or whether or not a state where the difference is equal to or greater than the predetermined value continues for a predetermined period.
  • the determination unit 38 determines that the difference between the time indicated by the PCR included in the MPEG-2TS (Media Segment) and the time indicated by the client clock 23 is equal to or greater than a predetermined value. Or whether or not the difference is equal to or greater than a predetermined value continues for a predetermined period. Note that threshold values, predetermined values, and the like used by the determination unit 38 for determination may be stored in the clock correction data storage unit 6.
  • FIG. 13 is a flowchart illustrating an example of a clock synchronization process executed by the client 9.
  • the flow chat in FIG. 13 shows a processing example of the client 9 from the establishment of the TCP session (SS2) for performing clock synchronization until the clock correction is performed.
  • the target for clock synchronization is designated in the MPD distribution server 7 before the TCP session (SS2) is established.
  • the server on which the client 9 performs clock synchronization may be a server whose clock is synchronized with the MP4 distribution server 8 from which the client 9 acquires content.
  • the determination unit 38 determines whether or not a predetermined condition is satisfied (S301). When determining that the predetermined condition is satisfied (YES in S301), the determination unit 38 instructs the request execution unit 31 to execute transmission of a request for clock synchronization.
  • the request execution unit 31 Upon receiving the instruction, the request execution unit 31 uses the Get method to transmit a request for requesting transmission of the MPD file to the MPD distribution server 7 (S302). When the request execution unit 31 transmits a request, the transmission / reception time acquisition unit 33 records the time when the request execution unit 31 transmits the request as Tc0 (S303).
  • the transmission / reception time acquisition unit 33 records the time when the request execution unit 31 received the response as Tc1 (S305). Further, the server clock acquisition unit 34 extracts the MPD file generation time from the MPD file included in the response received by the request execution unit 31, and records the time indicated by the MPD file generation time as Ts (S306).
  • the error calculation unit 35 acquires Tc0 and Tc1 from the transmission / reception time acquisition unit 33, and Ts from the server clock acquisition unit 34, respectively.
  • Td (Tc1 + Tc0) / 2 ⁇ Ts (3)
  • an error Td between the RTC of the client 9 and the RTC of the MPD distribution server 7 is calculated (S307).
  • the error calculation unit 35 outputs the calculated error Td to the clock correction unit 36 and the server clock acquisition count setting unit 37.
  • the server clock acquisition count setting unit 37 determines whether or not the error Td calculated by the error calculation unit 35 is larger than a predetermined value (S308). If the error Td is not greater than the predetermined value (NO in S308), the server clock acquisition count setting unit 37 does not perform processing and proceeds to S310. On the other hand, when the error Td is larger than the predetermined value (YES in S308), the server clock acquisition count setting unit 37 adds the predetermined value to the set server clock acquisition count and updates the set value of the server clock acquisition count. (S309).
  • the clock correction unit 36 refers to the set value of the server clock acquisition count and determines whether Ts has been acquired for the set server clock acquisition count (S310). If Ts has not been acquired for the set number of server clock acquisition times (NO in S310), the request execution unit 31 subsequently transmits a request for transmission of the MPD file to the MPD distribution server 7, and S302 to S309. Execute the process. On the other hand, if Ts has been acquired for the set number of server clock acquisition times (YES in S310), the clock correction unit 36 corrects the clock of the client clock 23 based on the error Td calculated by the error calculation unit 35. (S311).
  • the server clock acquisition count setting unit 37 adds a predetermined value to the set server clock acquisition count to calculate the server clock acquisition count. Update the setting value. As a result, the number of samples is increased only when the variation in clock error is large. Therefore, even if the clock error may be large, the clock correction can be executed with stable accuracy.
  • a content playback device acquires content from a content distribution device using HTTP (HyperText Transfer Protocol), and plays back the acquired content. Included in the HTTP header in the response received by the request execution unit, and the request execution unit that transmits a request requesting transmission of the request to the content distribution device and receives a response to the request that does not include a resource. And a clock correction means for correcting the clock of the own apparatus based on the time information.
  • HTTP HyperText Transfer Protocol
  • the content reproducing apparatus synchronization method is a content reproducing apparatus synchronization method for acquiring content from a content distribution apparatus by HTTP and reproducing the acquired content, wherein A request transmission step of transmitting a request for requesting transmission of information to the content distribution device, a response reception step of receiving a response that is a response to the request transmitted in the request transmission step and does not include a resource, and the response And a clock correction step of correcting the clock of the own apparatus based on time information included in the HTTP header in the response received in the reception step.
  • the request execution means transmits a request for requesting transmission of meta information related to a resource to the content distribution apparatus, and receives a response that does not include a resource, in response to the transmitted request.
  • amendment means correct
  • the request execution means receives and receives a response including time information used by the clock correction means to correct the clock of its own device by transmitting and receiving a request and response with a small amount of data. Therefore, it is possible to suppress the occurrence of packet transmission delay due to waiting for retransmission of the preceding packet and waiting for completion of reception when the content reproduction device performs its own clock correction. Therefore, the content reproduction apparatus can increase the accuracy of clock correction by removing or reducing the influence of jitter caused by TCP.
  • the clock correction unit receives the time when the request execution unit transmits a request and the response in addition to the time information included in the HTTP header of the response. It is preferable to correct the clock of the own device based on the time.
  • the clock correction unit corrects the clock of its own device based on the time information, the time when the request is transmitted, and the time when the response is received.
  • the clock correction means calculates the clock of its own device based on the difference between the time when the request is transmitted and the time when the response is received and the time indicated by the time information. to correct. Thereby, the clock correction means can execute clock correction with higher accuracy.
  • the request execution means transmits a request for requesting transmission of meta information related to the resource in a TCP session independent of the TCP session for acquiring the content, It is preferable to receive a response to the request.
  • the request execution unit transmits a response including time information used by the clock correction unit to correct the clock of its own device to a TCP independent of the TCP session for acquiring the content. Receive in session.
  • the request execution unit repeats transmission of the request and reception of the response, and the clock correction unit is included in an HTTP header of each response received by the request execution unit. It is preferable to correct the clock of the own device based on the time information.
  • the clock correction unit corrects its own clock based on the time information included in the HTTP header of each response received by the request execution unit. Therefore, for example, even when the time indicated by the time information is truncated to the second system, the clock correction unit statistically processes the times indicated by the plurality of time information, and rounds down to the actual time and the second system. By considering an error from the time indicated by the time information, the clock of the own device can be corrected at a time less than a second.
  • the clock correction means can remove or reduce the influence of jitter caused by TCP by statistically processing the time indicated by the plurality of time information. Therefore, the clock correction means can perform clock correction with higher accuracy.
  • the request execution unit transmits the next request after transmitting the request and receiving a response to the request.
  • the request execution unit transmits the request, receives a response to the request, and then transmits the next request.
  • the request execution means transmits a request without using the HTTP request pipeline. That is, the request execution means transmits a request so that waiting for retransmission of the preceding packet and waiting for completion of reception do not occur. Therefore, it is possible to suppress the occurrence of packet transmission delay due to waiting for retransmission of the preceding packet and waiting for completion of reception when the content reproduction device performs its own clock correction.
  • the request execution means includes a time indicated by other time information included in the HTTP header in a response to the request for acquiring the content, and a time indicated by the clock of the own device. It is preferable to transmit the request when the difference between the two is equal to or greater than a predetermined value.
  • the request execution means has a predetermined difference between the time indicated by the other time information included in the HTTP header in the response to the request for acquiring the content and the time indicated by the clock of the own device. If the value is greater than or equal to the value, send the above request.
  • the difference between the time indicated by the other time information and the time indicated by the clock of the content reproduction apparatus is a predetermined value. In the above case, it is assumed that streaming fails and normal streaming reproduction cannot be performed. On the other hand, when the time difference between the two is less than a predetermined value, streaming reproduction can be normally performed.
  • the predetermined value is set in a range in which the content reproduction apparatus can normally perform streaming reproduction.
  • the content reproduction apparatus does not perform clock correction when the streaming reproduction can be normally performed, and performs the clock correction when the streaming reproduction cannot be performed normally.
  • the clock correction is performed only when the content reproduction device needs the clock correction, the processing (load) of the content reproduction device and the content distribution device can be reduced. Moreover, since useless communication between the content reproduction apparatus and the content distribution apparatus can be reduced, resources on the network between the two can be used effectively.
  • the request execution unit transmits a request for requesting transmission of meta information related to the resource by using a Head method.
  • the request transmitted by the request execution unit is a request using the Head method with a small amount of data
  • the response received by the request execution unit is a response with only an HTTP header. Therefore, it is possible to suppress the occurrence of packet transmission delay due to waiting for retransmission of the preceding packet and waiting for completion of reception when the content reproduction device performs its own clock correction.
  • the request execution means transmits a request for requesting transmission of meta information related to the resource using an Options method.
  • the request transmitted by the request execution unit is a request using the Options method with a small amount of data
  • the response received by the request execution unit is supported by the HTTP header and the content distribution device.
  • This response contains information indicating the method that Therefore, it is possible to suppress the occurrence of packet transmission delay due to waiting for retransmission of the preceding packet and waiting for completion of reception when the content reproduction device performs its own clock correction.
  • the content reproduction apparatus is a content reproduction apparatus that acquires content from a content distribution apparatus by HTTP and reproduces the acquired content, and requests a request for transmission of meta information related to a resource to the content distribution apparatus.
  • a request execution unit that receives a response that is a response to the request and does not include a resource, and a time included in an HTTP header in the response received by the request execution unit It is characterized by comprising clock correction means for correcting the clock of its own device based on the information.
  • the said request execution means transmits the request which requests
  • amendment means correct
  • the request execution means receives and receives a response including time information used by the clock correction means to correct the clock of its own device by transmitting and receiving a request and response with a small amount of data. Therefore, it is possible to suppress the occurrence of packet transmission delay due to waiting for retransmission of the preceding packet and waiting for completion of reception when the content reproduction device performs its own clock correction.
  • the request execution means transmits the request to a server device whose clock is synchronized with the content distribution device. Therefore, even if a packet transmission delay occurs in the transmission / reception of content between the content reproduction device and the content distribution device, the transmission / reception of the request and the response executed by the request execution unit is not affected. Therefore, it is possible to suppress the occurrence of packet transmission delay due to waiting for retransmission of the preceding packet and waiting for completion of reception when the content reproduction device performs its own clock correction.
  • the content reproduction apparatus has an effect of improving the accuracy of clock correction by removing or reducing the influence of jitter caused by TCP.
  • the content reproduction apparatus acquires a plurality of segments obtained by dividing the content together with control data from the content distribution apparatus, and the plurality of segments based on the control data.
  • the clock correction unit corrects the clock of its own device based on the time information included in the control data. For example, by acquiring only control data including time information used by the clock correction unit from the content distribution device, it is possible to transmit control data with a small data amount without transmitting / receiving entity data (segments) of content with a large data amount.
  • the clock correction means can correct the clock of its own device only by transmitting / receiving a request including transmission and a response including control data.
  • the content reproduction apparatus can increase the accuracy of clock correction by removing or reducing the influence of jitter caused by TCP.
  • the content reproduction device acquires a plurality of segments obtained by dividing content from the content distribution device and acquires control data from the control data distribution device.
  • the content reproduction apparatus that reproduces the content from the plurality of segments based on the control data, wherein the control data is transmitted to the apparatus indicated by the clock synchronization target designation information included in the control data acquired at the time of the segment acquisition.
  • a request execution unit that transmits a request for requesting and receives control data requested from the device, and a clock correction that corrects the clock of the own device based on time information included in the control data received by the request execution unit. Means.
  • the said request execution means transmits the request which requests
  • the clock correction means corrects the clock of the own apparatus based on the time information included in the control data received by the request execution means. That is, the request execution means transmits / receives a request for requesting transmission of control data having a small data amount and a response including control data without transmitting / receiving actual data of a resource having a large data amount.
  • the request execution means receives and receives a response including time information used by the clock correction means to correct the clock of its own device by transmitting and receiving a request and response with a small amount of data. Therefore, it is possible to suppress the occurrence of packet transmission delay due to waiting for retransmission of the preceding packet and waiting for completion of reception when the content reproduction device performs its own clock correction.
  • the request execution means transmits the request for clock correction to the device indicated by the clock synchronization target designation information included in the control data acquired at the time of the segment acquisition. Therefore, even if a packet transmission delay occurs in the transmission / reception of content between the content reproduction device and the content distribution device, the transmission / reception of the request and the response executed by the request execution unit is not affected. Therefore, it is possible to suppress the occurrence of packet transmission delay due to waiting for retransmission of the preceding packet and waiting for completion of reception when the content reproduction device performs its own clock correction.
  • the content reproduction apparatus has an effect of improving the accuracy of clock correction by removing or reducing the influence of jitter caused by TCP.
  • the content distribution system preferably includes the content reproduction device and a content distribution device that distributes content to the content reproduction device.
  • the content distribution system has the same effect as the content reproduction device.
  • the content reproduction apparatus may be realized by a computer.
  • a control program for realizing the content reproduction apparatus by a computer by causing the computer to operate as each unit of the content reproduction apparatus, and A computer-readable recording medium on which it is recorded also falls within the scope of the present invention.
  • each block of the client 3 and the client 9, particularly the client control unit 21 and the client control unit 24, may be configured by hardware logic, or may be realized by software using a CPU as follows. .
  • the client 3 and the client 9 include a CPU (central processing unit) that executes instructions of a control program that realizes each function, a ROM (read only memory) that stores the program, and a RAM (random access memory that expands the program). ),
  • a storage device such as a memory for storing the program and 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 of the client 3 and the client 9 which are software for realizing the above-described functions 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 tapes such as magnetic tapes and cassette tapes, magnetic disks such as floppy (registered trademark) disks / hard disks, and disks including optical disks such as CD-ROM / MO / MD / DVD / CD-R.
  • Card system such as IC card, IC card (including memory card) / optical card, or semiconductor memory system such as mask ROM / EPROM / EEPROM / flash ROM.
  • the client 3 and the client 9 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.
  • the Internet intranet, extranet, LAN, ISDN, VAN, CATV communication network, virtual private network, telephone line network, mobile communication network, satellite communication. A net or the like is available.
  • the transmission medium constituting the communication network is not particularly limited.
  • infrared rays such as IrDA and remote control, Bluetooth (Registered trademark), 802.11 wireless, HDR, mobile phone network, satellite line, terrestrial digital network, and the like can also be used.
  • the present invention can be used for an apparatus that acquires content such as a moving image via a communication network.
  • it can be suitably used for an apparatus that acquires content by a streaming method.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Synchronisation In Digital Transmission Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

　本発明のクライアント（３）は、ＨＴＴＰによりサーバ（２）からコンテンツを取得し、取得したコンテンツを再生するクライアント（３）であって、リソースに関するメタ情報の送信を要求するリクエストをサーバ（２）に送信し、送信したリクエストに対するレスポンスであって、リソースを含まないレスポンスを受信するリクエスト実行部（３１）と、リクエスト実行部（３１）が受信したレスポンスにおけるＨＴＴＰヘッダに含まれるDateフィールド値に基づいて、クライアントクロック（２３）を補正するクロック補正部（３６）とを備える。

Description

コンテンツ再生装置、コンテンツ配信システム、コンテンツ再生装置の同期方法、制御プログラム、および、記録媒体
　本発明は、コンテンツを取得して再生するコンテンツ再生装置、当該コンテンツ再生装置の同期方法、当該コンテンツ再生装置の制御プログラム、および、当該制御プログラムを記録した記録媒体、並びに、当該コンテンツ再生装置を含むコンテンツ配信システムに関するものである。
　従来から、通信ネットワークを介した動画などのコンテンツの提供を行う技術が広く用いられている。例えば、コンテンツを再生するクライアントからの要求に応じて、コンテンツを管理するサーバからクライアントにコンテンツを配信するビデオ・オン・デマンド（ＶＯＤ）サービス等がある。ＶＯＤ等のコンテンツ配信サービスでは、ストリーミング方式、ダウンロード方式またはプログレッシブダウンロード方式によって、クライアントにコンテンツを提供している。
　ストリーミング方式、特にライブストリーミングでは、ストリーミングの破綻を避けるため、コンテンツ提供装置とコンテンツ取得装置とのクロックのずれを補正するクロックドリフト対策が行われている。従来の通信システムでは、ＰＣＲ(Program Clock Reference)によるクロック同期、ＲＴＰ（Real-Time Protocol）、ＮＴＰ（Network Time Protocol）／ＳＮＴＰ（Simple Network Time Protocol）等で上記の問題を解決していた。以下に、それぞれの具体的なクロックドリフト対策の手法を説明する。
　まず、MPEG-2 System（非特許文献１を参照）について、図１４に基づいて説明する。図１４は、MPEG-2 Systemにおける伝送方式を示す模式図である。MPEG-2 Systemは、例えば、地上デジタル放送等で使用されている規格である。MPEG-2 Systemでは、送信機は、映像信号や音声信号をＴＳパケット（１８８バイト）単位で受信機に送信する。さらに、送信機は、所定の間隔（100msec程度）でＰＣＲを受信機に送信し、受信機は、受信したＰＣＲを基にクロック同期を行う。ＰＣＲによるクロック同期は、ＴＳパケットの伝送遅延時間の揺らぎ（ジッタ）が殆どない放送網等に対して有用なクロックドリフト対策の手法である。
　次に、ＴＳパケットの伝送遅延時間のジッタがあるが比較的小さいＩＰＴＶ等で用いられるＲＴＰ（非特許文献２を参照）について説明する。ＲＴＰでは、図１５に示すように、ＲＴＰパケット毎に送出時刻を付与する。具体的には、ＲＴＰヘッダのTimestampフィールドに、ＲＴＰパケット内の先頭ＴＳパケットの送出時刻を格納する（Timestampフィールドは、本来は表示時刻を格納する）。ＲＴＰパケットは１３５６バイトであるため、例えば、１０Mbpsで伝送を行う場合、下記式（１）によると、
　10M(bps) ÷(1356 x 8) = 921.8 (packets/sec)　　・・・（１）
送信機は、約１msec毎に送信機のシステム時刻を受信機に送信する。
　受信機では、ＲＴＰパケットを受信し、内部クロックと受信クロック（ＲＴＰヘッダのTimestampフィールドの時刻）との誤差を測定する。この測定を繰り返すと、測定した誤差は、基本的には、発生頻度に対して、図１６に示すような分布をとる。受信機は、この分布に基づいて、複数の測定結果（誤差）に対して統計処理を行って、内部クロックの補正値（例えば、最も発生頻度が高い誤差の値）を求める。ＲＴＰでは、MPEG-2 SystemにおけるＰＣＲの送信頻度に比べて、送信機のシステム時刻を送信する頻度を増やすことにより、ＴＳパケットの伝送遅延の揺らぎ（ジッタ）があっても、ジッタが比較的小さい場合、統計処理によって除去もしくは軽減することができる。そのため、送信機と受信機とのクロック同期を精度良く実行することができる。
　次に、ＮＴＰ／ＳＮＴＰ（非特許文献３および４を参照）について、図１７に基づいて説明する。ＮＴＰ／ＳＮＴＰは、クロック同期専用のプロトコルであり、映像伝送とは独立して運用可能である。また、ＮＴＰ／ＳＮＴＰは、通常、ＵＤＰ上で動作し、ＵＤＰのポートは１２３番を使用する。
　図１７は、ＮＴＰ／ＳＮＴＰにおける、クライアント、およびサーバ（ＮＴＰサーバ）のクロック同期におけるリクエスト／レスポンスの送受信のシーケンスを示す図である。ここでは、クライアントの装置固有のクロックであるＲＴＣ（Real Time Clock）をＴｃとし、サーバのＲＴＣをＴｓとする。図１７に示すように、クライアントは、リクエストの送信時刻Ｔｃ０を含むリクエストをサーバに送信する（Ｓ１００１）。サーバは、リクエストを受信し、リクエストの受信時刻Ｔｓ０、レスポンスの送信時刻Ｔｓ１、および、Ｔｃ０を含むレスポンスをクライアントに送信する（Ｓ１００２）。そして、クライアントは、レスポンスを受信し、レスポンスを受信した時刻をＴｃ１とする。このようにして、クライアントは、Ｔｃ０、Ｔｃ１、Ｔｓ０およびＴｓ１を把握する。
　図１７において、クライアントからサーバへのリクエストの送信時間と、サーバからクライアントへのレスポンスの送信時間とが同じであると仮定すると、Ｔｃ０とＴｃ１との中点の時刻と、Ｔｓ０とＴｓ１との中点の時刻が一致する。この仮定に基づくと、サーバのＲＴＣに対するクライアントのＲＴＣの遅延時間θは、
　θ＝(Ts0 + Ts1)/2 - (Tc0 + Tc1)/2　　・・・（２）
で表される。クライアントは、算出した遅延時間θに基づいて、クライアントのＲＴＣを補正する。
　なお、ＮＴＰでは、実運用上ではＵＴＣ（協定世界時）が基準クロックとして用いられているため、クライアントおよびクライアントにコンテンツを配信するコンテンツ配信サーバが共にＮＴＰサーバとクロック同期を行い、ＵＴＣを基準としたクロック補正が行われる。また、リクエスト／レスポンスを繰り返して複数のθの値を算出し、統計処理を施すことによって、より高精度にクロック補正を行うことができる。
「ISO/IEC 13818-1」, (スイス), International Organization for Standardization/International Electrotechnical Commission, １９９４年１１月 「RFC 2250」, [online], Internet Engineering Task Force, １９９８年１月, ［２０１０年１０月１日検索］, インターネット＜URL : http://tools.ietf.org/html/rfc2250＞ 「RFC 1305」, [online], Internet Engineering Task Force, １９９２年３月, ［２０１０年１０月１日検索］, インターネット＜URL : http://tools.ietf.org/html/rfc1305＞ 「RFC 2030」, [online], Internet Engineering Task Force, １９９６年１０月, ［２０１０年１０月１日検索］, インターネット＜URL : http://tools.ietf.org/html/rfc2030＞
日本国公開特許公報「特開２００１－１４８７１２号公報（公開日：２００１年５月２９日）」 日本国公開特許公報「特開２００２－５５８９０号公報（公開日：２００２年２月２０日公開）」
　本発明では、現在MPEGにて規格策定中のＤＡＳＨ（Dynamic Adaptive Streaming over HTTP）などＨＴＴＰによる映像伝送方式を用いて、コンテンツを伝送することを想定している。ここで、そのＤＡＳＨについて図１８に基づいて説明する。図１８は、ＤＡＳＨを用いて伝送されるコンテンツのデータ構造を示す図である。
　ＤＡＳＨは、３ＧＰＰのストリーミング方式（TS 26.234 ver 9.3.0）をベースにした映像伝送方式であり、クライアント主導で適応ストリーミングを実現するものである。ＤＡＳＨでは、コンテンツの伝送フォーマットとしてＭＰ４またはMPEG-2TSを用い、コンテンツの伝送プロトコルとしてＨＴＴＰを利用する。図１８に示す例では、コンテンツの伝送フォーマットがＭＰ４である。
　図１８に示すように、ＤＡＳＨでは、コンテンツ（ＭＰ４ファイル）を、複数のMedia Segmentに分割する。コンテンツは、例えば、画像符号化におけるＧＯＰ（Group Of Picture）単位等で分割される。また、ＤＡＳＨでは、１つのコンテンツに対して品質種別（ビットレート等の再生品質や、データフォーマット等の種別）が異なる複数のＭＰ４ファイルを備える。そして、ＤＡＳＨでは、コンテンツを伝送すると共に、各コンテンツの品質種別や、各Media Segmentを統括するＭＰＤファイル（制御データ）を伝送する。ＭＰＤファイルは、適応ストリーミングのためのメタファイルである。また、ＤＡＳＨでは、１度のＨＴＴＰリクエスト/レスポンスで１つのMedia Segmentを伝送する。
　このＤＡＳＨの映像伝送方式でストリーミングを行う場合にも、当然クロックドリフト対策を行う必要がある。しかしながら、ＤＡＳＨでは従来のクロックドリフト対策を単純に適用することができない。あるいは、ＤＡＳＨにおいて利用されるＴＣＰ／ＩＰの制約から、ＩＰパケットの伝送遅延時間のジッタが大きく、クロック補正の精度が十分保てない。従来のクロックドリフト対策は、ＩＰパケットの伝送遅延時間のジッタが比較的小さい伝送方式に対して有効な手法であり、ＩＰパケットの伝送遅延時間のジッタが大きいＤＡＳＨには、そのまま適用することができない。
　具体的には、MPEG-2 Systemでは、ＴＳパケットの伝送遅延時間のジッタが殆どないため、ＰＣＲの送信頻度が比較的低くても、十分な精度をもってクロックを補正することができる。しかしながら、ＤＡＳＨでは、ＴＣＰに起因するジッタがあるため、MPEG-2 SystemにおけるＰＣＲによるクロック同期の手法を利用しても、クロック補正の精度が十分保てない。ＤＡＳＨにおいて、ＰＣＲに相当する時刻を示す情報の送信頻度を上げた場合、クロック補正の精度は向上するが、クロック補正処理の負荷が増加する。さらに、ＤＡＳＨではＴＳ以外にＭＰ４も扱うが、ＭＰ４にはＰＣＲに相当する情報を持っていないため、MPEG-2 Systemの手法をそのまま適用することができない。
　また、ＨＴＴＰではＩＰパケット毎に送出時刻を格納するフィールドが用意されておらずＲＴＰの方法を応用することが困難である。より詳細には、図１９に示すように、ＤＡＳＨでデータを伝送する場合、まず、ＭＰ４／ＭＰＥＧ－２ＴＳファイルを０．５～数秒程度の単位のMedia Segmentに分割して、複数のMedia Segmentを作成する。そして、各Media SegmentにＨＴＴＰヘッダを付与してＨＴＴＰメッセージを生成する。基本的に、１つのMedia Segmentは、ＩＰパケットの送信単位のデータサイズに比べてデータが大きいため、１つのMedia SegmentにＨＴＴＰヘッダを付与したＨＴＴＰメッセージをさらに分割し、１つのＩＰパケットが1500Bytes程度になるようにＩＰパケットを作成する。そして各ＩＰパケットにＴＣＰ／ＩＰヘッダを付与する。ＤＡＳＨではこのようにデータが伝送されるため、ＨＴＴＰメッセージの１つ目のＩＰパケットにはＨＴＴＰヘッダが含まれているが、２つ目以降のＩＰパケットにはＨＴＴＰヘッダが含まれていないため、全てのＩＰパケット毎に送出時刻を格納することができない。
　また、ＮＴＰ／ＳＮＴＰを利用する場合、ＵＤＰ１２３番ポートがルータ等の中継機器で遮断されていると利用できないという問題がある。
　このように、従来技術をジッタの大きいＴＣＰ／ＩＰでの伝送に応用すると、サーバクロックの送信頻度が少ない（従来と同程度の）場合、ＴＣＰ／ＩＰ伝送におけるジッタの影響が除去しきれず、クロック補正の精度が低下する。一方、サーバクロックの送信頻度を上げる場合、クロック補正処理の負荷が増加するという問題がある。
　また、ＨＴＴＰを用いたクロック同期の手法が特許文献１および２に開示されているが、これらの技術もＤＡＳＨによるライブストリーミングでのクロックドリフト対策としては不十分である。特許文献１には、クライアントが、ＷＷＷサーバに対するアクセスの応答として受信した応答パケットのヘッダ部から時刻データを取得し、取得した時刻データの示す時刻にクライアントのＲＴＣを合わせることが記載されている。また、特許文献２には、通信装置の起動時に、通信装置がＷＷＷサーバにアクセスして、ＷＷＷサーバのホームページ情報から日本標準時を取得して、通信装置のＲＴＣを取得した日本標準時に合わせることが記載されている。
　特許文献１および２に記載の発明では、クライアントがサーバからＨＴＭＬファイル等のデータをダウンロード時にクロック同期を行っている。そのため、クロック補正を行うための時刻情報を受信する際に、ジッタが発生する虞のあるリソースを同時に、もしくは続けて取得している。特許文献１および２では、映像コンテンツのストリーミング再生ではなく、Ｗｅｂの閲覧等を想定しているため、クロック同期の際にジッタが発生したとしても、サーバのサービス提供に重大な影響を与えない。それゆえ、特許文献１および２に記載の発明は、ＴＣＰ／ＩＰ固有のジッタの影響を考慮したクロック同期を行っていない。一方、ＤＡＳＨによるライブストリーミングでは、ＴＣＰ／ＩＰ固有のジッタが大きく影響するため、特許文献１および２に記載の発明をそのまま適用しても、クロック補正の精度をライブストリーミングが実行可能な程度に保てない。
　本発明は、上記の問題点に鑑みてなされたものであり、その目的は、ＴＣＰ／ＩＰにおけるジッタ要因を除去または軽減し、クロック補正の精度が高いクロック同期を行うコンテンツ再生装置、当該コンテンツ再生装置の同期方法、当該コンテンツ再生装置の制御プログラム、および、当該制御プログラムを記録した記録媒体、並びに、当該コンテンツ再生装置を含むコンテンツ配信システムを実現することにある。
　本発明に係るコンテンツ再生装置は、上記課題を解決するために、ＨＴＴＰ（HyperText Transfer Protocol）によりコンテンツ配信装置からコンテンツを取得し、取得したコンテンツを再生するコンテンツ再生装置であって、リソースに関するメタ情報の送信を要求するリクエストを上記コンテンツ配信装置に送信し、当該リクエストに対するレスポンスであって、リソースを含まないレスポンスを受信するリクエスト実行手段と、上記リクエスト実行手段が受信したレスポンスにおけるＨＴＴＰヘッダに含まれる時間情報に基づいて、自装置のクロックを補正するクロック補正手段とを備えることを特徴としている。
　本発明に係るコンテンツ再生装置の同期方法は、上記課題を解決するために、ＨＴＴＰによりコンテンツ配信装置からコンテンツを取得し、取得したコンテンツを再生するコンテンツ再生装置の同期方法であって、リソースに関するメタ情報の送信を要求するリクエストを上記コンテンツ配信装置に送信するリクエスト送信ステップと、上記リクエスト送信ステップにおいて送信されたリクエストに対するレスポンスであって、リソースを含まないレスポンスを受信するレスポンス受信ステップと、上記レスポンス受信ステップにおいて受信されたレスポンスにおけるＨＴＴＰヘッダに含まれる時間情報に基づいて、自装置のクロックを補正するクロック補正ステップとを含むことを特徴としている。
　上記の構成によれば、上記リクエスト実行手段は、リソースに関するメタ情報の送信を要求するリクエストを上記コンテンツ配信装置に送信し、送信したリクエストに対するレスポンスであって、リソースを含まないレスポンスを受信する。そして、上記クロック補正手段が、レスポンスにおけるＨＴＴＰヘッダに含まれる時間情報に基づいて、自装置のクロックを補正する。すなわち、上記リクエスト実行手段は、データ量の大きいリソースの実体データを送受信することなく、データ量の小さいリソースに関するメタ情報の送信を要求するリクエストおよびリソースに関するメタ情報を含み、リソースの実体データを含まないレスポンスを送受信する。
　そのため、上記リクエスト実行手段は、データ量の小さいリクエストおよびレスポンスを送受信することにより、上記クロック補正手段が自装置のクロックを補正するために使用する時間情報を含むレスポンスを受信する。よって、コンテンツ再生装置が自装置のクロック補正を行う際に、先行パケットの再送待ち、受信完了待ちによるパケットの伝送遅延が発生することを抑制することができる。従って、コンテンツ再生装置は、ＴＣＰに起因するジッタの影響を除去または軽減することにより、クロック補正の精度を高めることができるという効果を奏する。
　以上のように、本発明に係るコンテンツ再生装置は、ＨＴＴＰ（HyperText Transfer Protocol）によりコンテンツ配信装置からコンテンツを取得し、取得したコンテンツを再生するコンテンツ再生装置であって、リソースに関するメタ情報の送信を要求するリクエストを上記コンテンツ配信装置に送信し、当該リクエストに対するレスポンスであって、リソースを含まないレスポンスを受信するリクエスト実行手段と、上記リクエスト実行手段が受信したレスポンスにおけるＨＴＴＰヘッダに含まれる時間情報に基づいて、自装置のクロックを補正するクロック補正手段とを備えている構成である。
　また、本発明に係るコンテンツ再生装置の同期方法は、ＨＴＴＰによりコンテンツ配信装置からコンテンツを取得し、取得したコンテンツを再生するコンテンツ再生装置の同期方法であって、リソースに関するメタ情報の送信を要求するリクエストを上記コンテンツ配信装置に送信するリクエスト送信ステップと、上記リクエスト送信ステップにおいて送信されたリクエストに対するレスポンスであって、リソースを含まないレスポンスを受信するレスポンス受信ステップと、上記レスポンス受信ステップにおいて受信されたレスポンスにおけるＨＴＴＰヘッダに含まれる時間情報に基づいて、自装置のクロックを補正するクロック補正ステップとを含むことを特徴としている。
　よって、コンテンツ再生装置が自装置のクロック補正を行う際に、先行パケットの再送待ち、受信完了待ちによるパケットの伝送遅延が発生することを抑制することができる。従って、コンテンツ再生装置は、ＴＣＰに起因するジッタの影響を除去または軽減することにより、クロック補正の精度を高めることができるという効果を奏する。
　本発明のさらに他の目的、特徴、及び優れた点は、以下に示す記載によって十分わかるであろう。また、本発明の利益は、添付図面を参照した次の説明で明白になるであろう。
本発明の第１の実施形態を示すものであり、コンテンツ配信システムの概要およびコンテンツ配信システムを構成する各装置の要部構成を示すブロック図である。 クロック補正データ記憶部に格納されるデータの一例を示す図である。 コンテンツ伝送中のクロック同期におけるクライアント－サーバ間のリクエスト／レスポンスのシーケンス図である。 図４の（ａ）は、クライアントからサーバへ送信されるリクエストメッセージの一例を示す図であり、図４の（ｂ）は、サーバからクライアントへ送信されるレスポンスメッセージの一例を示す図である。 クライアントが実行するクロック同期処理の一例を示すフローチャートである。 図６の（ａ）は、クライアントからサーバへ送信されるリクエストメッセージの一例を示す図であり、図６の（ｂ）は、サーバからクライアントへ送信されるレスポンスメッセージの一例を示す図である。 ＭＰＤファイルの記述を拡張した例を示す図である。 Dateフィールド精度不足対策の手順の一例を示すフローチャートである。 応答時間と発生頻度との関係を示すグラフである。 クライアントクロックの時刻、サーバクロックの時刻およびDateフィールド値を実時間に対してプロットしたグラフである。 サーバクロックの時刻とDateフィールド値との差分値、および、クライアントクロックの時刻とDateフィールド値との差分値を実時間に対してプロットしたグラフである。 本発明の第２の実施形態を示すものであり、コンテンツ配信システムの概要およびコンテンツ配信システムを構成する各装置の要部構成を示すブロック図である。 クライアントが実行するクロック同期処理の一例を示すフローチャートである。 MPEG-2 Systemにおける伝送方式を示す模式図である。 ＲＴＰパケットのデータ構造を示す図である。 ＲＴＰにおいて、内部クロックと受信クロックとの誤差と発生頻度との関係を示すグラフである。 ＮＴＰ／ＳＮＴＰにおける、クライアントおよびサーバのリクエスト／レスポンスの送受信のシーケンスを示す図である。 ＤＡＳＨを用いて伝送されるコンテンツのデータ構造を示す図である。 ＤＡＳＨでの伝送時におけるコンテンツのデータ構造を示す図である。
　＜第１の実施形態＞
　本発明の第１の実施形態について図１から図１１に基づいて説明すると以下の通りである。まず、本実施形態のコンテンツ配信システム１の概要について、図１に基づいて説明する。
　〔コンテンツ配信システム１の概要〕
　図１は、第１の実施形態に係るコンテンツ配信システム１の概要およびコンテンツ配信システム１を構成する各装置の要部構成を示す図である。図１に示すように、コンテンツ配信システム１は、サーバ（コンテンツ配信装置）２、および、クライアント（コンテンツ再生装置）３を含む。また、コンテンツ配信システム１は、サーバ２と接続しているコンテンツ格納部５と、クライアント３と接続しているクロック補正データ記憶部６とを含む。
　図１に示すように、サーバ２、および、クライアント３は、ネットワーク４を介して接続されている。なお、ネットワーク４は、サーバ２、および、クライアント３が相互に通信可能なものであればよく、有線通信のネットワークであってもよいし、無線通信のネットワークであってもよい。
　また、図１に示す例では、コンテンツ配信システム１が、サーバ２およびクライアント３を１つずつ含んでいるが、これに限るものではない。コンテンツ配信システム１が、サーバ２を複数含んでいてもよく、また、クライアント３を複数含んでいてもよい。換言すると、コンテンツ配信システム１は、サーバ２およびクライアント３を少なくとも１つずつ含んでいればよい。
　また、本実施形態では、コンテンツ配信システム１におけるネットワーク４上の伝送プロトコルは、汎用的なファイル伝送プロトコルとして広く用いられているＨＴＴＰを用いるものとする。また、サーバ２が配信するコンテンツは、映像コンテンツであり、コンテンツは、セグメント化されたＭＰ４データであるものとする。すなわち、本実施形態では、コンテンツ配信システム１は、ＤＡＳＨを用いてコンテンツを送受信する。具体的に、サーバ２は、クライアント３からコンテンツを要求されると、セグメント化されたＭＰ４データあるいはＭＰＤファイルをクライアント３に送信する。
　〔サーバ２について〕
　サーバ２は、クライアント３からコンテンツの送信を要求する要求メッセージ（リクエスト）を受信して、受信した要求メッセージに対する応答メッセージ（レスポンス）を送信するコンテンツ配信装置である。上述のように、要求メッセージおよび応答メッセージは、何れもＨＴＴＰメッセージである。サーバ２は、動画などのコンテンツを格納するコンテンツ格納部５と接続されており、コンテンツ格納部５に格納されているコンテンツを管理する。なお、コンテンツ格納部５は、サーバ２に内蔵されていてもよい。あるいは、コンテンツ格納部５の代わりに、コンテンツをリアルタイム生成するエンコーダを備えた構成であっても構わない。
　なお、サーバ２は、不特定多数の装置に同じコンテンツを同時に配信してもよいし、単一の装置にコンテンツを配信してもよいし、決められた複数の装置に対して、同時に同じコンテンツを配信してもよい。
　図１に示すように、サーバ２は、サーバ２の動作を統括して制御するサーバ制御部１１と、サーバ２が外部の装置と通信するためのサーバ通信部１２と、サーバ２のＲＴＣをカウントするサーバクロック１３とを備えている。また、サーバ制御部１１には、レスポンス実行部１４が含まれている。
　レスポンス実行部１４は、サーバ通信部１２を介して、クライアント３から要求メッセージを受信すると、受信した要求メッセージに対する応答メッセージをクライアント３に送信する。レスポンス実行部１４は、例えば、クライアント３からコンテンツの送信を要求する要求メッセージを受信すると、コンテンツ格納部５からクライアントが要求するコンテンツを読み出し、読み出したコンテンツをクライアント３に送信する。
　〔クライアント３について〕
　クライアント３は、コンテンツをリクエストして取得し、取得したコンテンツを再生する装置である。上述のように、クライアント３は、クライアント３が実行するクロック補正に関する情報（詳細は後述）を格納するクロック補正データ記憶部６と接続されており、クロック補正データ記憶部６に格納されている情報を管理する。なお、クロック補正データ記憶部６は、クライアント３に内蔵されていてもよい。また、図１には示していないが、クライアント３は、ユーザ操作を受け付ける入力部を備えており、この入力部で受け付けた入力操作に基づき、コンテンツをリクエストする。
　図示のように、クライアント３は、クライアント３の動作を統括して制御するクライアント制御部２１と、クライアント３が外部の装置と通信するためのクライアント通信部２２と、クライアント３のＲＴＣをカウントするクライアントクロック（クロック）２３とを備えている。また、クライアント制御部２１には、リクエスト実行部（リクエスト実行手段）３１、コンテンツ再生部３２、送受信時刻取得部３３、サーバクロック取得部３４、誤差算出部３５およびクロック補正部（クロック補正手段）３６が含まれている。
　リクエスト実行部３１は、サーバ２とのＴＣＰセッションを確立するＴＣＰ同期要求（ＳＹＮ）をサーバ２に送信し、サーバ２とのＴＣＰセッションを確立するものである。また、リクエスト実行部３１は、コンテンツの送信を要求する要求メッセージを生成し、クライアント通信部２２を介してサーバ２に送信し、これに対する応答としてセグメント化されたコンテンツおよびＭＰＤファイルを含む応答メッセージを受信する。上述のように、サーバ２から送信されるコンテンツは、複数のセグメントに分割されて送信される。
　コンテンツ再生部３２は、リクエスト実行部３１が取得した取得したＭＰＤファイルに従って、共に取得したセグメント化されたコンテンツから、コンテンツを復元して再生する。例えば、取得したコンテンツが動画像のコンテンツである場合には、コンテンツ再生部３２は、取得したコンテンツをデコードし、これにより得られた映像及び音声を、クライアントクロック２３に基づいて、外部の表示装置（図示せず）に出力させる。
　送受信時刻取得部３３は、リクエスト実行部３１がクロック補正を実行するためのリクエストを送信した時刻をＴｃ０として記録するものである。また、リクエスト実行部３１がクロック補正を実行するためのリクエストに対するレスポンスを受信した時刻をＴｃ１として記録するものである。なお、リクエスト実行部３１がクロック補正を実行するために送信するリクエストについて、参照する図面を代えて後述する。送受信時刻取得部３３は、記録した時刻Ｔｃ０およびＴｃ１を内部で保持してもよいし、クライアント３と接続するクロック補正データ記憶部６に格納してもよい。送受信時刻取得部３３は、記録したＴｃ０およびＴｃ１を誤差算出部３５に出力する。
　サーバクロック取得部３４は、リクエスト実行部３１が受信したレスポンスのＨＴＴＰヘッダに含まれる、サーバ２が当該レスポンスを送信した時刻を示すDateフィールド値（時間情報）を抽出して、Dateフィールド値が示す時刻をＴｓとして記録するものである。サーバクロック取得部３４は、記録した時刻Ｔｓを内部で保持してもよいし、クライアント３と接続するクロック補正データ記憶部６に格納してもよい。
　誤差算出部３５は、送受信時刻取得部３３からＴｃ０およびＴｃ１を、サーバクロック取得部３４からＴｓをそれぞれ取得し、Ｔｃ０、Ｔｃ１およびＴｓに基づいて、クライアント３のＲＴＣとサーバ２のＲＴＣとの誤差Ｔｄを算出するものである。
　クロック補正部３６は、誤差算出部３５が算出した誤差Ｔｄに基づいて、クライアントクロック２３のクロックを補正するものである。
　〔クロック補正データ記憶部６について〕
　クロック補正データ記憶部６は、クロック補正に関する情報を格納するものである。具体的には、クロック補正データ記憶部６は、送受信時刻取得部３３が取得したＴｃ０およびＴｃ１、サーバクロック取得部３４が取得したＴｓ、誤差算出部３５が算出した誤差Ｔｄを格納するものである。クロック補正データ記憶部６が格納する情報は、例えば、図２に示すようなデータであってよい。図２は、リクエストごとにＴｃ０、Ｔｃ１、ＴｓおよびＴｄを１組にして並べたデータである。図２に示す例では、Ｔｃ０、Ｔｃ１およびＴｓの時刻を「時：分：秒」で示している。また、Ｔｄの単位はマイクロ秒である。
　〔クロック同期方法〕
　次に、本発明のクロック同期方法の概要について、図３に基づいて説明する。図３は、コンテンツ伝送中のクロック同期におけるクライアント－サーバ間のリクエスト／レスポンスのシーケンス図である。
　始めに、クライアント３は、サーバ２に対してＴＣＰ同期要求（ＳＹＮ）を送信し（Ｓ１０１）、コンテンツを取得するためのＴＣＰセッション（ＳＳ１）を確立する（Ｓ１０２）。そして、クライアント３は、ＨＴＴＰを用いてサーバ２からコンテンツを取得して、動画のストリーミング再生を行う（Ｓ１０３）。
　クライアント３は、ストリーミング再生を行いながら、ストリーミングの破綻を防ぐために、サーバ２とのクロック同期を実行する。まず、クライアント３は、現在確立中のコンテンツを取得するためのＴＣＰセッション（ＳＳ１）とは別に、クロック同期を実行するためのＴＣＰセッション（ＳＳ２）を確立する。具体的には、クライアント３は、ＴＣＰ同期要求（ＳＹＮ）をサーバ２に送信する（Ｓ１０４）。ＴＣＰ同期要求（ＳＹＮ）を受信したサーバ２は、ＴＣＰ同期要求（ＳＹＮ）とその応答（ＡＣＫ）をクライアント３に返信する（Ｓ１０５）。ＴＣＰ同期要求（ＳＹＮ）および応答（ＡＣＫ）を受信したクライアント３は、応答（ＡＣＫ）をサーバ２に送信し、ＴＣＰセッション（ＳＳ２）を新たに確立する（Ｓ１０６）。
　クライアント３は、この新たに確立した、クロック同期を実行するためのＴＣＰセッション（ＳＳ２）において、ＨＴＴＰのHeadメソッドを利用したリクエストをサーバ２に送信する（Ｓ１０７）。リクエストを受信したサーバ２は、当該リクエストに対するレスポンスをクライアント３に送信する（Ｓ１０８）。
　レスポンスを受信したクライアント３は、リクエストの送信時刻Ｔｃ０、レスポンスの受信時刻Ｔｃ１、および、レスポンスに含まれるDateフィールド値の示すレスポンスの送信時刻Ｔｓに基づいて、クロック補正を行う。
　ここで、コンテンツを取得するためのＴＣＰセッション（ＳＳ１）とクロック同期を実行するためのＴＣＰセッション（ＳＳ２）とは論理的に独立したＴＣＰセッション（通信路）である。
　また、クロック同期を実行するためのＴＣＰセッション（ＳＳ２）において、クライアント－サーバ間でやりとりされるリクエスト／レスポンスのメッセージ例を図４に示す。図４の（ａ）は、クライアント３からサーバ２へ送信されるリクエストメッセージの一例を示す図である。また、図４の（ｂ）は、サーバ２からクライアント３へ送信されるレスポンスメッセージの一例を示す図である。
　〔クライアント３が実行するクロック同期処理について〕
　次に、クライアント３が実行するクロック同期処理について、図５に基づいて説明する。図５は、クライアント３が実行するクロック同期処理の一例を示すフローチャートである。なお、図５のフローチャットでは、クロック同期を実行するためのＴＣＰセッション（ＳＳ２）を確立した後、クロック補正を行うまでのクライアント３の処理例を示す。
　図５に示すように、クライアント３のリクエスト実行部３１は、ＴＣＰセッション（ＳＳ２）を確立した後、ＨＴＴＰのHeadメソッドを利用して、リクエストをサーバ２に送信する（Ｓ２０１）。リクエスト実行部３１がリクエストを送信すると、送受信時刻取得部３３は、リクエスト実行部３１がリクエストを送信した時刻をＴｃ０として記録する（Ｓ２０２）。
　その後、リクエスト実行部３１がサーバ２からレスポンスを受信すると（Ｓ２０３）、送受信時刻取得部３３は、リクエスト実行部３１がレスポンスを受信した時刻をＴｃ１として記録する（Ｓ２０４）。さらに、サーバクロック取得部３４は、リクエスト実行部３１が受信したレスポンスに含まれるDateフィールド値を抽出して、Dateフィールド値が示す時刻をＴｓとして記録する（Ｓ２０５）。
　誤差算出部３５は、送受信時刻取得部３３からＴｃ０およびＴｃ１を、サーバクロック取得部３４からＴｓをそれぞれ取得し、
　Ｔｄ ＝ （Ｔｃ１＋Ｔｃ０）／２ － Ｔｓ　　・・・（３）
上記の数式（３）に基づいて、クライアント３のＲＴＣとサーバ２のＲＴＣとの誤差Ｔｄを算出する（Ｓ２０６）。誤差算出部３５は、算出した誤差Ｔｄをクロック補正部３６に出力する。そして、クロック補正部３６は、誤差算出部３５が算出した誤差Ｔｄに基づいて、クライアントクロック２３のクロックを補正する（Ｓ２０７）。
　ストリーミング再生中では、クライアント３は、Ｓ２０１～Ｓ２０７を定期的に繰り返し実行し、ストリーミングが破綻しないように、クライアントクロック２３をサーバクロック１３に同期させる。
　以上のように、本発明では、サーバクロックとしてＨＴＴＰレスポンスのDateフィールド値を利用しているため、サーバ２は、別の外部サーバとの同期を行う必要がなく、クロック補正が不要である。また、ＨＴＴＰレスポンスのDateフィールド値を利用しているため、サーバ２は、特別な機能を有する必要がなく、従来の装置をそのまま利用可能である。つまり、サーバ２が使用する伝送プロトコルやサーバ２が管理するコンテンツのファイルフォーマットは従来のものをそのまま転用できる。
　また、本発明では、コンテンツを取得するためのＴＣＰセッション（ＳＳ１）とは独立して、クロック同期を実行するためのＴＣＰセッション（ＳＳ２）を用いて、クロック同期のためのリクエスト／レスポンスをやり取りしているため、コンテンツの送受信状況、送受信速度等に影響されることなく、クライアント３が任意のタイミングで必要回数、サーバクロックＴｓを取得できる。具体的には、コンテンツ伝送におけるパケットの再送待ちや受信完了待ちが発生したとしても、クライアント３が任意のタイミングでクロック補正を行うことができる。
　また、本発明では、Ｓ２０１にてＨＴＴＰのHeadメソッドを利用しているため、Ｓ２０３にてクライアント３が受信するレスポンスは、ＨＴＴＰヘッダと、リソースのメタ情報とだけを含み、リソースの実体を含まない。このため、Ｓ２０３にてクライアント３が受信するレスポンスのデータ量はごく僅かであり、通常、単一のＩＰパケットに包含されて送信される（単一のＩＰパケットに包含されない場合でも、高々２～３個のＩＰパケットにより構成できる）。それゆえ、クロック同期のＴＣＰセッションにおいて、１度に送受信されるデータ量が少なく、短期間に多数のサーバクロックを取得することができる。ＨＴＴＰのHeadメソッドを利用することで、ＨＴＴＰレスポンスが１パケット（もしくは数パケット）に収めることができ、先行パケットの再送待ち、受信完了待ちの発生を抑制することができる。
　なお、ステップＳ２０１において、クライアント３がサーバ２に送信するリクエストは、リソースに関するメタ情報の送信を要求するリクエストであればよく、Headメソッドを利用したリクエストに限定されない。例えば、Optionsメッソドを用いてもよい（この変形例については後述）。レスポンスにリソースの実体を含まないリクエストであれば、どのようなリクエストであっても、レスポンスのデータサイズを極めて小さく抑えられることは明らかであろう。
　また、同一サーバに対して複数のＨＴＴＰリクエスト／ＨＴＴＰレスポンスを繰り返し行う場合、ＨＴＴＰリクエストパイプラインを用いて効率的な処理を行うのが一般的であるが、本発明では、クロック同期のＴＣＰセッションにおいて、ＨＴＴＰリクエストパイプラインを利用しないことが望ましい。すなわち、リクエスト実行部３１は、直前に送信したリクエストに対するレスポンスの受信が完了してから、次のリクエストを送信することが望ましい。ＨＴＴＰリクエストパイプラインを利用しないことにより、先行ＨＴＴＰリクエスト／ＨＴＴＰレスポンスパケットの再送待ち、受信完了待ちの発生を抑制することができる。
　このように、本発明では、ＴＣＰに起因するジッタの影響を除去または軽減できるため、クロック補正を精度良く実行することができる。
　〔変形例〕
　図５に示すクロック同期処理の一例では、クライアント３は、Headメソッドを用いたＨＴＴＰメッセージによって、サーバ２のＲＴＣを取得していたが、サーバ２のＲＴＣの取得方法はこれに限るものではない。
　例えば、Headメソッドの代わりに、Optionsメソッドを使ってもよい。具体的な例として、クライアント３が、図６の（ａ）に示すリクエストメッセージをサーバ２に送信し、サーバ２が図６の（ｂ）に示すレスポンスメッセージをクライアント３に送信してもよい。クライアント３がOptionsメソッドを用いてサーバ２にリクエストを送信した場合であっても、図６に示すように、サーバ２が送信する当該リクエストに対するレスポンスのＨＴＴＰヘッダには、サーバ２がレスポンスを送信する時刻を示すDateフィールド値が含まれているため、クライアント３がサーバクロックの時刻Ｔｓを取得することができる。また、Optionsメソッドを用いたＨＴＴＰメッセージも、Headメソッドの場合と同様に、１度に送受信されるデータ量が少ないため、ＨＴＴＰレスポンスを数パケット以内に収めることができ、先行パケットの再送待ち、受信完了待ちの発生を抑制することができる。
　つまり、本発明では、サーバ２のＲＴＣを取得する際に、リクエスト実行部３１は、リソースに関するメタ情報の送信を要求するメソッドを用いてサーバ２にリクエストを送信し、送信したリクエストに対するレスポンスを受信すればよい。
　また、サーバ２およびクライアント３がＤＡＳＨを用いてコンテンツの送受信を行っている場合、クライアント３は、Headメソッドの代わりに、Getメソッドを用いてＭＰＤファイルの送信を要求するリクエストを送信することにより、当該リクエストに対するレスポンスに含まれるDateフィールド値を取得してもよい。ＤＡＳＨにおいて、ＭＰＤファイルのデータ量は小さいため、ＨＴＴＰレスポンスを数パケット以内に収めることができる。そのため、Getメソッドを用いてＭＰＤファイルの送信を要求するリクエストを送信する場合でも、ジッタの影響を除去または軽減することができる。あるいは、Rangeリクエストヘッダを付与したGetメソッドも用いて、コンテンツの一部の送信を要求するリクエストを送信する場合でも、ジッタの影響を除去または軽減することができる。
　さらに、ＭＰＤファイルの記述を拡張して、サーバ２がＭＰＤファイルを生成した時刻をＭＰＤファイル内に記述した場合、Dateフィールド値の代わりに、ＭＰＤファイルに含まれるＭＰＤファイル生成時刻（時間情報）を取得して、取得したＭＰＤファイル生成時刻をサーバクロックＴｓとしてもよい。具体的には、クライアント３は、Getメソッドを用いてＭＰＤファイルの送信を要求するリクエストを送信することにより、当該リクエストに対するレスポンスに含まれるＭＰＤファイル内のＭＰＤファイル生成時刻を取得してもよい。
　ＭＰＤファイルの記述を拡張した例を図７に示す。図７に示すように、ＭＰＤファイル内にＭＰＤファイル生成時刻が記述されている。ＨＴＴＰでは、Dateフィールド値に秒精度の記述しかできないが、ＭＰＤファイルには、Dateフィールド値より精度の高いサーバクロックの時刻を記述することができる。従って、ＭＰＤファイル生成時刻を利用してサーバクロックＴｓを取得する場合、Dateフィールド値を利用する場合に比べて、クロック補正を精度良く実行することができる。なお、この場合、サーバ２は、１つのコンテンツにつき品質種別が異なるコンテンツファイルを複数管理し、当該１つのコンテンツファイルを所定の単位で分割して、コンテンツファイルをMedia Segment（セグメント）単位で管理し、さらに、コンテンツの品質種別および各Media Segmentを統括するＭＰＤファイル（制御データ）を管理する。
　上述のように、ＨＴＴＰでは、Dateフィールド値に秒精度の記述しかできないが、クロック同期処理においてサーバクロックＴｓを複数回取得し、クロック補正部３６が統計処理を行うことにより、Dateフィールド値を利用した場合であっても、秒未満の精度でクロック補正を行うことができる。以下において、そのDateフィールド値による精度不足を解消するDateフィールド精度不足対策の方法について、図８～図１１に基づいて説明する。
　図８は、Dateフィールド精度不足対策の手順の一例を示すフローチャートである。まず、クライアント３が短時間に一定間隔で繰り返しサーバクロックＴｓを取得する（Ｓ２１１）。具体的には、測定結果（取得したＴｓ）に含まれるDateフィールドの影響（平均誤差：０．５秒、最小０秒～最大１秒の誤差）が、各サンプル（以下では取得したＴｓ、Ｔｃ０およびＴｃ１の組をサンプルと称する）のＴｓに一様に分布するよう、Ｍ／Ｎ（Ｍ、Ｎは互いに素な整数）秒間隔で、図５に示すＳ２０１～Ｓ２０５を繰り返し実行し、Ｔｓを取得（測定）する。例えば、クライアント３は、100msec間隔で１０秒間計測する。なお、応答時間（Ｔｃ１－Ｔｃ０）が測定間隔より長い場合には、先行するクロック同期のためのリクエスト／レスポンス待ちの影響が生じるため、応答時間に応じて測定間隔を再設定してもよいし、測定サンプル毎に個別のＴＣＰセッションを確立してもよい。また、多数のサンプルを取得する構成であれば、測定間隔に関わらず、Dateフィールドの影響が各サンプルのＴｓに一様に分布するので、測定間隔を一定としない構成でも構わない。
　次に、誤差算出部３５は、各サンプルの応答時間（Ｔｃ１－Ｔｃ０）を算出して、図９に示すように、応答時間の長いサンプルを除外（破棄）する（Ｓ２１２）。図９は、応答時間と発生頻度（サンプル数）との関係を示すグラフである。図９の横軸は応答時間を示し、縦軸は発生頻度を示す。サンプルを除外する方法として、例えば、応答時間が所定の閾値（例：１秒）以上のサンプルを全て破棄してもよい。また、全サンプルを応答時間の長さの順に並べて、応答時間の長いものから所定の割合（例：５％）に含まれるサンプルを破棄してもよい。また、応答時間の平均値μおよび標準偏差σを求め、平均μから所定値（例：６σ）以上遅いサンプルを破棄してもよい。応答時間の短いサンプルは信頼できる（ジッタの影響を受けていない）データであると考えられるため、応答時間の長いサンプルを除外することにより、ジッタの影響を除去または軽減することができる。なお、ジッタの影響は応答時間に表れるため、Dateフィールドの精度とは無関係に処理が可能である。
　次に、Ｓ２１２の処理によって残ったサンプルについて、誤差算出部３５がそれぞれの誤差Ｔｄを算出する（Ｓ２１３）。そして、クロック補正部３６が算出した各サンプルの誤差Ｔｄの平均値Ｔａを算出する（Ｓ２１４）。Ｓ２１４で算出した誤差の平均値Ｔａは、Dateフィールド精度の影響（平均誤差：０．５秒）を含む。そのため、クロック補正部３６が、平均値Ｔａから上記影響を除去して、クロック補正量Ｔｄ’＝Ｔａ－０．５を算出する（Ｓ２１５）。最後に、クロック補正部３６は、クライアントクロックのＲＴＣからクロック補正量Ｔｄ’を引いて、補正後のクライアントクロックの時刻Ｔｃ’（＝Ｔｃ－Ｔｄ’）とする（Ｓ２１６）。
　ここで、上記のクロック補正量Ｔｄ’について、図１０および図１１に基づいてより詳細に説明する。図１０は、クライアントクロック２３の時刻Ｔｃ、サーバクロック１３の時刻ＴｓおよびDateフィールド値を実時間に対してプロットしたグラフである。図１０の横軸は実時間（実際の経過時間）を示し、縦軸はクロック値（時刻）を示す。図１０に示すように、ここではクライアントクロック２３がサーバクロック１３に対して所定時間早く動いている。この両者の時間のずれをクロック補正量Ｔｄ’として算出することが理想である。また、図１０に示すように、Dateフィールド値の示す時刻は、サーバクロック１３を秒精度に切り捨てた時刻である。
　図８に示す補正方法では、短時間の間でＴｓを繰り返し取得しているため、Ｔｓを取得している間の期間においては、サーバクロック１３およびクライアントクロック２３のクロック速度差は無視できる程度に小さい。そのため、ここでは、サーバクロック１３およびクライアントクロック２３のクロック速度差はないものとして扱う。すなわち、サーバクロック１３およびクライアントクロック２３の時間差（クロック補正量Ｔｄ’）はＴｓ取得期間中変化しない。
　図１０に基づいて、サーバクロック１３の時刻ＴｓとDateフィールド値との差分値、および、クライアントクロック２３の時刻ＴｃとDateフィールド値との差分値を実時間に対してプロットしたものが図１１である。図１１の横軸は実時間（実際の経過時間）を示し、縦軸はクロック（時刻）の差分値を示す。
　Ｓ２１２の処理において、ジッタの影響が十分に除去できていれば、Ｓ２１３で算出した各サンプルの誤差Ｔｄは、図１１に示すクライアントクロック２３の時刻ＴｃとDateフィールド値との差分値を示すグラフ近傍に均一に分布する（理想的には当該グラフと一致する）。従って、Ｓ２１４において、誤差Ｔｄの平均値Ｔａを算出することにより、Ｔｄ’を推定することができる。なおＳ２１３、Ｓ２１４の処理については、他上記の方法の代わりに、他の統計処理手法を用いる構成でも構わない。例えばＴｓ＝Ｔｃ－Ｔaを仮定し、最小二乗法にてＴaを推定することが可能である。
　＜第２の実施形態＞
　本発明の第２の実施形態について図１２および図１３に基づいて説明すると以下の通りである。第２の実施形態では、コンテンツを提供するサーバの負荷を軽減するために、第１の実施形態と比較して、サーバの構成と、クライアントが実行するクロック同期処理とが異なっている。以下では、第１の実施形態と異なる点について主に説明する。
　〔コンテンツ配信システム１０の概要〕
　まず、第２の実施形態のコンテンツ配信システム１０の概要について、図１２に基づいて説明する。図１２は、第２の実施形態に係るコンテンツ配信システム１０の概要およびコンテンツ配信システム１０を構成する各装置の要部構成を示す図である。図１２に示すように、コンテンツ配信システム１０は、ＭＰＤ配信サーバ（制御データ配信装置）７、ＭＰ４配信サーバ（コンテンツ配信装置）８、および、クライアント（コンテンツ再生装置）９を含む。また、コンテンツ配信システム１０は、ＭＰＤ配信サーバ７と接続しているＭＰＤファイル格納部７５と、ＭＰ４配信サーバ８と接続しているＭＰ４ファイル格納部８５と、クライアント９と接続しているクロック補正データ記憶部６とを含む。
　図１２に示す例では、コンテンツ配信システム１０が、ＭＰＤ配信サーバ７、ＭＰ４配信サーバ８、および、クライアント９を１つずつ含んでいるが、これに限るものではない。コンテンツ配信システム１０が、ＭＰＤ配信サーバ７、ＭＰ４配信サーバ８、および、クライアント９をそれぞれ複数含んでいてもよい。換言すると、コンテンツ配信システム１０は、ＭＰＤ配信サーバ７、ＭＰ４配信サーバ８、および、クライアント９を少なくとも１つずつ含んでいればよい。
　また、本実施形態では、ＤＡＳＨを用いてＭＰＤ配信サーバ７およびＭＰ４配信サーバ８からクライアント９に対してコンテンツを配信するものとする。また、コンテンツのフォーマットは、ＭＰ４ファイルフォーマットとする。なお、本実施形態において、ＭＰ４配信サーバ８が配信するコンテンツのフォーマットは、これに限るものではない。
　第２の実施形態では、図１２に示すように、コンテンツ配信システム１０は、第１の実施形態のサーバ２の機能を分割して、それぞれ、ＭＰＤファイルを管理するＭＰＤ配信サーバ７と、ＭＰ４ファイルを管理するＭＰ４配信サーバ８とを含む。すなわち、ＭＰＤ配信サーバ７は、図１８に示すＭＰＤファイルを管理し、一方、ＭＰ４配信サーバ８は、図１８に示す、Media Segmentで構成される品質種別の異なる各ＭＰ４ファイルを管理するものである。
　第２の実施形態では、クライアント９は、ＭＰＤ配信サーバ７にコンテンツをリクエストする。リクエストを受けたＭＰＤ配信サーバ７は、クライアントに対して、コンテンツの取得先のＭＰ４配信サーバ８を示す情報（例えば、ＵＲＬ等）を含むＭＰＤファイルを返信し、クライアント９は、指定されたＭＰ４配信サーバ８からＭＰ４を取得する。
　〔ＭＰＤ配信サーバ７について〕
　ＭＰＤ配信サーバ７は、クライアント９からコンテンツの送信を要求する要求メッセージ（リクエスト）を受信して、受信した要求メッセージに対する応答メッセージ（レスポンス）を送信するコンテンツ配信装置である。また、ＭＰＤ配信サーバ７は、ＭＰ４配信サーバ８が管理するコンテンツの品質種別および各セグメントを統括するＭＰＤファイル（制御データ）を管理する。また、上述のように、ＭＰＤ配信サーバ７は、応答メッセージとして、コンテンツの取得先のＭＰ４配信サーバ８を示す情報（例えば、ＵＲＬ等）を含むＭＰＤファイルを送信する。なお、ＭＰＤファイル格納部７５は、ＭＰＤ配信サーバ７に内蔵されていてもよい。
　図１２に示すように、ＭＰＤ配信サーバ７は、ＭＰＤ配信サーバ７の動作を統括して制御するＭＰＤ配信サーバ制御部７１と、ＭＰＤ配信サーバ７が外部の装置と通信するためのＭＰＤ配信サーバ通信部７２と、ＭＰＤ配信サーバ７のＲＴＣをカウントするＭＰＤ配信サーバクロック７３とを備えている。また、ＭＰＤ配信サーバ制御部７１には、レスポンス実行部７４が含まれている。
　レスポンス実行部７４は、ＭＰＤ配信サーバ通信部７２を介して、クライアント９から要求メッセージを受信すると、受信した要求メッセージに対する応答メッセージをクライアント９に送信する。レスポンス実行部７４は、例えば、クライアント９からコンテンツの送信を要求する要求メッセージを受信すると、コンテンツの取得先のＭＰ４配信サーバ８を示す情報を含むＭＰＤファイルをクライアント９に送信する。また、クライアント９からＭＰＤファイルを要求する要求メッセージを受信すると、ＭＰＤファイル格納部７５からＭＰＤファイルを読み出し、読み出したＭＰＤファイルをクライアント９に送信する。
　〔ＭＰ４配信サーバ８について〕
　ＭＰ４配信サーバ８は、クライアント９からコンテンツの送信を要求する要求メッセージ（リクエスト）を受信して、受信した要求メッセージに対する応答メッセージ（レスポンス）を送信するコンテンツ配信装置である。また、ＭＰ４配信サーバ８は、１つのコンテンツにつき品質種別が異なるコンテンツファイルを複数管理し、当該１つのコンテンツファイルを所定の単位で分割して、コンテンツファイルをMedia Segment（セグメント）単位で管理する。なお、ＭＰ４ファイル格納部８５は、ＭＰ４配信サーバ８に内蔵されていてもよい。
　図１２に示すように、ＭＰ４配信サーバ８は、ＭＰ４配信サーバ８の動作を統括して制御するＭＰ４配信サーバ制御部８１と、ＭＰ４配信サーバ８が外部の装置と通信するためのＭＰ４配信サーバ通信部８２と、ＭＰ４配信サーバ８のＲＴＣをカウントするＭＰ４配信サーバクロック８３とを備えている。また、ＭＰ４配信サーバ制御部８１には、レスポンス実行部８４が含まれている。なお、ＭＰ４配信サーバクロック８３は、ＮＴＰなどの手段を用いてＭＰＤ配信サーバクロック７３と同期が取れているものとする。
　レスポンス実行部８４は、ＭＰ４配信サーバ通信部８２を介して、クライアント９から要求メッセージを受信すると、受信した要求メッセージに対する応答メッセージをクライアント９に送信する。レスポンス実行部８４は、例えば、クライアント９からコンテンツの送信を要求する要求メッセージを受信すると、ＭＰ４ファイル格納部８５からＭＰ４ファイルを読み出し、読み出したＭＰ４ファイルをクライアント９に送信する。
　〔クライアント９について〕
　クライアント９は、第１の実施形態のクライアント３と同様に、コンテンツをリクエストして取得し、取得したコンテンツを再生する装置である。クライアント９は、第１の実施形態のクライアント３とクライアント制御部２４の構成が異なっている。具体的には、図１２に示すように、クライアント制御部２４は、第１の実施形態のクライアント制御部２１の構成に加えて、さらに、サーバクロック取得回数設定部３７および判定部３８を含む。
　第２の実施形態では、リクエスト実行部３１は、クロック同期を実行するためのＴＣＰセッション（ＳＳ２）を確立する前（例えば、コンテンツ取得時）に、図７に示すＭＰＤファイルをＭＰＤ配信サーバ７から受信し、クロック同期を行う対象であるサーバを指定されているものとする。具体的には、リクエスト実行部３１は、図７に示すＭＰＤファイルに含まれるクロックソース（クロック同期対象指定情報）を参照して、クロックソースに記述されているＵＲＬのＭＰＤ配信サーバ（サーバ装置）７またはＭＰ４配信サーバ（サーバ装置）８からサーバクロックＴｓを取得する。図７に示す例では、クロックソースに１つのＵＲＬしか記述されていないが、複数記述されていてもよい。この場合、リクエスト実行部３１は、複数のＵＲＬから少なくとも１つを選択して、クロック同期を行う対象であるサーバを決定する。
　これにより、第２の実施形態では、クライアント９とのクロック同期を行う専用のサーバ（サーバ装置）を設定しておき、その専用サーバとクライアント９とがクロック同期を行うように、クライアント９に指示することができる。従って、サーバの負荷を柔軟に分散することができ、クロック補正を安定的に実行することができる。
　サーバクロック取得回数設定部３７は、クロック補正部３６が実行する１度のクロック補正に用いるサーバクロックの取得回数を設定／更新するものである。サーバクロック取得回数設定部３７は、誤差算出部３５が算出した誤差Ｔｄが所定値より大きいか否かを判定し、誤差Ｔｄが所定値より大きい場合に、設定されているサーバクロック取得回数に所定値を加えて、サーバクロック取得回数の設定値を更新する。なお、本実施形態では、ユーザからの入力またはデフォルトにより、サーバクロック取得回数が予め所定値に設定されているものとする。サーバクロック取得回数の設定値は、クロック補正データ記憶部６に格納されていてもよい。
　判定部３８は、クライアント９がクロック同期処理を実行するべきか否かを判定するものである。判定部３８は、予め定められた所定の条件を満たしているか否かを判定し、所定の条件を満たしている場合、リクエスト実行部３１にクロック同期を行うためのリクエストの送信を実行するように指示する。
　判定部３８は、例えば、クライアント９のコンテンツの受信バッファ（不図示）内のデータ占有量が所定の範囲内（所定値未満あるいは所定値以上）に収まっているか否かを判定してもよい。また、判定部３８は、ＭＰＤファイルおよび／またはＭＰ４ファイル（Media Segment）取得時のＨＴＴＰヘッダ（付加データ）のDateフィールド値（他の時間情報）の示す時刻と、クライアントクロック２３の示す時刻との差が所定値以上であるか否か、または、上記差が所定値以上の状態が所定期間継続しているか否かを判定してもよい。また、コンテンツのフォーマットがＭＰ４ではなく、ＭＰＥＧ－２ＴＳの場合、判定部３８は、ＭＰＥＧ－２ＴＳ（Media Segment）に含まれるＰＣＲの示す時刻と、クライアントクロック２３の示す時刻との差が所定値以上であるか否か、または、上記差が所定値以上の状態が所定期間継続しているか否かを判定してもよい。なお、判定部３８が判定に使用する閾値、所定値等は、クロック補正データ記憶部６に格納されていてもよい。
　〔クライアント９が実行するクロック同期処理について〕
　次に、クライアント９が実行するクロック同期処理について、図１３に基づいて説明する。図１３は、クライアント９が実行するクロック同期処理の一例を示すフローチャートである。なお、図１３のフローチャットでは、クロック同期を実行するためのＴＣＰセッション（ＳＳ２）を確立した後、クロック補正を行うまでのクライアント９の処理例を示す。前提として、図１３に示すクロック同期処理では、ＴＣＰセッション（ＳＳ２）の確立前に、クロック同期を行う対象がＭＰＤ配信サーバ７に指定されているものとする。なお、クライアント９がクロック同期を行うサーバは、クライアント９がコンテンツを取得するＭＰ４配信サーバ８と互いにクロックが同期しているサーバであればよい。
　図１３に示すように、ＴＣＰセッション（ＳＳ２）を確立した後、判定部３８が所定の条件を満たしているかどうかを判定する（Ｓ３０１）。判定部３８は、所定の条件を満たしていると判断した場合（Ｓ３０１でＹＥＳ）、リクエスト実行部３１に対して、クロック同期を行うためのリクエストの送信を実行するように指示する。
　指示を受けたリクエスト実行部３１は、Getメソッドを利用して、ＭＰＤファイルの送信を要求するリクエストをＭＰＤ配信サーバ７に送信する（Ｓ３０２）。リクエスト実行部３１がリクエストを送信すると、送受信時刻取得部３３は、リクエスト実行部３１がリクエストを送信した時刻をＴｃ０として記録する（Ｓ３０３）。
　その後、リクエスト実行部３１がＭＰＤ配信サーバ７からレスポンスを受信すると（Ｓ３０４）、送受信時刻取得部３３は、リクエスト実行部３１がレスポンスを受信した時刻をＴｃ１として記録する（Ｓ３０５）。さらに、サーバクロック取得部３４は、リクエスト実行部３１が受信したレスポンスに含まれるＭＰＤファイルからＭＰＤファイル生成時刻を抽出して、ＭＰＤファイル生成時刻が示す時刻をＴｓとして記録する（Ｓ３０６）。
　誤差算出部３５は、送受信時刻取得部３３からＴｃ０およびＴｃ１を、サーバクロック取得部３４からＴｓをそれぞれ取得し、
　Ｔｄ ＝ （Ｔｃ１＋Ｔｃ０）／２ － Ｔｓ　　・・・（３）
上記の数式（３）に基づいて、クライアント９のＲＴＣとＭＰＤ配信サーバ７のＲＴＣとの誤差Ｔｄを算出する（Ｓ３０７）。誤差算出部３５は、算出した誤差Ｔｄをクロック補正部３６およびサーバクロック取得回数設定部３７に出力する。
　ここで、サーバクロック取得回数設定部３７は、誤差算出部３５が算出した誤差Ｔｄが所定値より大きいか否かを判定する（Ｓ３０８）。サーバクロック取得回数設定部３７は、誤差Ｔｄが所定値より大きくなければ（Ｓ３０８でＮＯ）、処理を行わず、Ｓ３１０に進む。一方、サーバクロック取得回数設定部３７は、誤差Ｔｄが所定値より大きい場合（Ｓ３０８でＹＥＳ）、設定されているサーバクロック取得回数に所定値を加えて、サーバクロック取得回数の設定値を更新する（Ｓ３０９）。
　クロック補正部３６は、サーバクロック取得回数の設定値を参照して、設定されたサーバクロック取得回数分、Ｔｓを取得しているかどうかを判定する（Ｓ３１０）。設定されたサーバクロック取得回数分、Ｔｓを取得していない場合（Ｓ３１０でＮＯ）、続けて、リクエスト実行部３１がＭＰＤファイルの送信を要求するリクエストをＭＰＤ配信サーバ７に送信し、Ｓ３０２～Ｓ３０９の処理を実行する。一方、設定されたサーバクロック取得回数分、Ｔｓを取得している場合（Ｓ３１０でＹＥＳ）、クロック補正部３６は、誤差算出部３５が算出した誤差Ｔｄに基づいて、クライアントクロック２３のクロックを補正する（Ｓ３１１）。
　上述の処理例では、誤差算出部３５が算出した誤差Ｔｄが所定値より大きい場合、サーバクロック取得回数設定部３７が設定されているサーバクロック取得回数に所定値を加えて、サーバクロック取得回数の設定値を更新する。これにより、クロック誤差のバラツキが大きい時のみ、サンプル数を増加する。そのため、クロック誤差が大きい場合があったとしても、安定した精度でクロック補正を実行することができる。
　〔課題を解決するための手段〕
　本発明に係るコンテンツ再生装置は、上記課題を解決するために、ＨＴＴＰ（HyperText Transfer Protocol）によりコンテンツ配信装置からコンテンツを取得し、取得したコンテンツを再生するコンテンツ再生装置であって、リソースに関するメタ情報の送信を要求するリクエストを上記コンテンツ配信装置に送信し、当該リクエストに対するレスポンスであって、リソースを含まないレスポンスを受信するリクエスト実行手段と、上記リクエスト実行手段が受信したレスポンスにおけるＨＴＴＰヘッダに含まれる時間情報に基づいて、自装置のクロックを補正するクロック補正手段とを備えることを特徴としている。
　本発明に係るコンテンツ再生装置の同期方法は、上記課題を解決するために、ＨＴＴＰによりコンテンツ配信装置からコンテンツを取得し、取得したコンテンツを再生するコンテンツ再生装置の同期方法であって、リソースに関するメタ情報の送信を要求するリクエストを上記コンテンツ配信装置に送信するリクエスト送信ステップと、上記リクエスト送信ステップにおいて送信されたリクエストに対するレスポンスであって、リソースを含まないレスポンスを受信するレスポンス受信ステップと、上記レスポンス受信ステップにおいて受信されたレスポンスにおけるＨＴＴＰヘッダに含まれる時間情報に基づいて、自装置のクロックを補正するクロック補正ステップとを含むことを特徴としている。
　上記の構成によれば、上記リクエスト実行手段は、リソースに関するメタ情報の送信を要求するリクエストを上記コンテンツ配信装置に送信し、送信したリクエストに対するレスポンスであって、リソースを含まないレスポンスを受信する。そして、上記クロック補正手段が、レスポンスにおけるＨＴＴＰヘッダに含まれる時間情報に基づいて、自装置のクロックを補正する。すなわち、上記リクエスト実行手段は、データ量の大きいリソースの実体データを送受信することなく、データ量の小さいリソースに関するメタ情報の送信を要求するリクエストおよびリソースに関するメタ情報を含み、リソースの実体データを含まないレスポンスを送受信する。
　そのため、上記リクエスト実行手段は、データ量の小さいリクエストおよびレスポンスを送受信することにより、上記クロック補正手段が自装置のクロックを補正するために使用する時間情報を含むレスポンスを受信する。よって、コンテンツ再生装置が自装置のクロック補正を行う際に、先行パケットの再送待ち、受信完了待ちによるパケットの伝送遅延が発生することを抑制することができる。従って、コンテンツ再生装置は、ＴＣＰに起因するジッタの影響を除去または軽減することにより、クロック補正の精度を高めることができるという効果を奏する。
　また、本発明に係るコンテンツ再生装置は、上記クロック補正手段は、上記レスポンスのＨＴＴＰヘッダに含まれる上記時間情報に加えて、上記リクエスト実行手段がリクエストを送信した時刻、および、上記レスポンスを受信した時刻に基づいて、自装置のクロックを補正することが好ましい。
　上記の構成によれば、上記クロック補正手段は、上記時間情報、リクエストを送信した時刻、および、上記レスポンスを受信した時刻に基づいて、自装置のクロックを補正する。ここで、例えば、コンテンツ再生装置とコンテンツ配信装置とのリクエスト／レスポンスの送受信において、上り／下りのパケットの伝送時間が同じであると仮定する。この仮定に基づいて、例えば、上記クロック補正手段は、リクエストを送信した時刻と上記レスポンスを受信した時刻との中間時刻と、上記時間情報の示す時刻との差分に基づいて、自装置のクロックを補正する。これにより、上記クロック補正手段は、より精度の高いクロック補正を実行することができる。
　また、本発明に係るコンテンツ再生装置は、上記リクエスト実行手段は、上記コンテンツを取得するためのＴＣＰセッションとは独立したＴＣＰセッションにて、上記リソースに関するメタ情報の送信を要求するリクエストを送信し、当該リクエストに対するレスポンスを受信することが好ましい。
　上記の構成によれば、上記リクエスト実行手段は、上記クロック補正手段が自装置のクロックを補正するために使用する時間情報を含むレスポンスを、上記コンテンツを取得するためのＴＣＰセッションとは独立したＴＣＰセッションにて受信する。
　コンテンツ再生装置とコンテンツ配信装置との間のコンテンツの送受信では、比較的データ量の大きいパケットを送受信するため、先行パケットの再送待ち、受信完了待ちによるパケットの伝送遅延が発生する虞がある。ところが、上記コンテンツを取得するためのＴＣＰセッションとは独立したＴＣＰセッションにて上記時間情報を含むレスポンスを受信するため、仮に、コンテンツ再生装置とコンテンツ配信装置との間のコンテンツの送受信においてパケットの伝送遅延が発生したとしても、上記リクエスト実行手段が実行する上記リクエストおよび上記レスポンスの送受信には影響しない。よって、コンテンツ再生装置が自装置のクロック補正を行う際に、先行パケットの再送待ち、受信完了待ちによるパケットの伝送遅延が発生することを抑制することができる。
　また、本発明に係るコンテンツ再生装置は、上記リクエスト実行手段は、上記リクエストの送信および上記レスポンスの受信をそれぞれ繰り返し、上記クロック補正手段は、上記リクエスト実行手段が受信した各レスポンスのＨＴＴＰヘッダに含まれる時間情報に基づいて、自装置のクロックを補正することが好ましい。
　上記の構成によれば、上記クロック補正手段は、上記リクエスト実行手段が受信した各レスポンスのＨＴＴＰヘッダに含まれる時間情報に基づいて、自装置のクロックを補正する。そのため、例えば、上記時間情報の示す時刻が秒制度に切り捨てられた時刻であっても、上記クロック補正手段は、複数の時間情報の示す時刻を統計処理し、実際の時刻と、秒制度に切り捨てられた上記時間情報の示す時刻との誤差を考慮することにより、秒未満の時刻で自装置のクロックを補正することができる。
　また、上記クロック補正手段は、複数の時間情報の示す時刻を統計処理することにより、ＴＣＰに起因するジッタの影響を除去または軽減することができる。従って、上記クロック補正手段は、より精度の高いクロック補正を実行することができる。
　また、本発明に係るコンテンツ再生装置は、上記リクエスト実行手段は、上記リクエストを送信し、当該リクエストに対するレスポンスを受信してから、次のリクエストを送信することが好ましい。
　上記の構成によれば、上記リクエスト実行手段は、上記リクエストを送信し、当該リクエストに対するレスポンスを受信してから、次のリクエストを送信する。換言すると、上記リクエスト実行手段は、ＨＴＴＰリクエストパイプラインを利用せずに、リクエストを送信する。つまり、上記リクエスト実行手段は、先行パケットの再送待ち、受信完了待ちが発生しないように、リクエストを送信する。よって、コンテンツ再生装置が自装置のクロック補正を行う際に、先行パケットの再送待ち、受信完了待ちによるパケットの伝送遅延が発生することを抑制することができる。
　また、本発明に係るコンテンツ再生装置は、上記リクエスト実行手段は、上記コンテンツを取得するためのリクエストに対するレスポンスにおけるＨＴＴＰヘッダに含まれる他の時間情報の示す時刻と、自装置のクロックの示す時刻との差が所定値以上の場合に、上記リクエストを送信することが好ましい。
　上記の構成によれば、上記リクエスト実行手段は、上記コンテンツを取得するためのリクエストに対するレスポンスにおけるＨＴＴＰヘッダに含まれる他の時間情報の示す時刻と、自装置のクロックの示す時刻との差が所定値以上の場合に、上記リクエストを送信する。ここで、例えば、コンテンツ再生装置がコンテンツ配信装置からコンテンツを取得して、ストリーミング再生を行う際に、上記他の時間情報の示す時刻と、コンテンツ再生装置のクロックの示す時刻との差が所定値以上の場合、ストリーミングが破綻して正常にストリーミング再生を行うことができず、一方、両者の時刻の差が所定値未満の場合、ストリーミング再生を正常に行うことができるとする。換言すると、例えば、コンテンツ再生装置が正常にストリーミング再生を行うことができる範囲に、上記所定値を設定したとする。この場合、コンテンツ再生装置は、正常にストリーミング再生を行うことが可能な状態のときにはクロック補正をおこなわず、一方、正常にストリーミング再生を行うことが不可能な状態のときにクロック補正を行う。
　よって、コンテンツ再生装置がクロック補正が必要なときにだけクロック補正を行うため、コンテンツ再生装置およびコンテンツ配信装置の処理（負荷）を軽減することができる。また、コンテンツ再生装置とコンテンツ配信装置との間の無駄な通信を削減することができるため、両者間のネットワーク上の資源を有効に利用することができる。
　また、本発明に係るコンテンツ再生装置は、上記リクエスト実行手段は、上記リソースに関するメタ情報の送信を要求するリクエストを、Headメソッドを用いて送信することが好ましい。
　上記の構成によれば、上記リクエスト実行手段が送信するリクエストは、データ量の小さいHeadメソッドを用いたリクエストであり、上記リクエスト実行手段が受信するレスポンスは、ＨＴＴＰヘッダのみのレスポンスである。よって、コンテンツ再生装置が自装置のクロック補正を行う際に、先行パケットの再送待ち、受信完了待ちによるパケットの伝送遅延が発生することを抑制することができる。
　また、本発明に係るコンテンツ再生装置は、上記リクエスト実行手段は、上記リソースに関するメタ情報の送信を要求するリクエストを、Optionsメソッドを用いて送信することが好ましい。
　上記の構成によれば、上記リクエスト実行手段が送信するリクエストは、データ量の小さいOptionsメソッドを用いたリクエストであり、上記リクエスト実行手段が受信するレスポンスは、ＨＴＴＰヘッダおよびコンテンツ配信装置がサポートしているメソッドを示す情報を含むレスポンスである。よって、コンテンツ再生装置が自装置のクロック補正を行う際に、先行パケットの再送待ち、受信完了待ちによるパケットの伝送遅延が発生することを抑制することができる。
　また、本発明に係るコンテンツ再生装置は、ＨＴＴＰによりコンテンツ配信装置からコンテンツを取得し、取得したコンテンツを再生するコンテンツ再生装置であって、リソースに関するメタ情報の送信を要求するリクエストを上記コンテンツ配信装置と互いにクロックが同期しているサーバ装置に送信し、当該リクエストに対するレスポンスであって、リソースを含まないレスポンスを受信するリクエスト実行手段と、上記リクエスト実行手段が受信したレスポンスにおけるＨＴＴＰヘッダに含まれる時間情報に基づいて、自装置のクロックを補正するクロック補正手段とを備えることを特徴としている。
　上記の構成によれば、上記リクエスト実行手段は、リソースに関するメタ情報の送信を要求するリクエストを上記コンテンツ配信装置と互いにクロックが同期しているサーバ装置に送信し、送信したリクエストに対するレスポンスであって、リソースを含まないレスポンスを受信する。そして、上記クロック補正手段が、レスポンスにおけるＨＴＴＰヘッダに含まれる時間情報に基づいて、自装置のクロックを補正する。すなわち、上記リクエスト実行手段は、データ量の大きいリソースの実体データを送受信することなく、データ量の小さいリソースに関するメタ情報の送信を要求するリクエストおよびリソースに関するメタ情報を含み、リソースの実体データを含まないレスポンスを送受信する。
　そのため、上記リクエスト実行手段は、データ量の小さいリクエストおよびレスポンスを送受信することにより、上記クロック補正手段が自装置のクロックを補正するために使用する時間情報を含むレスポンスを受信する。よって、コンテンツ再生装置が自装置のクロック補正を行う際に、先行パケットの再送待ち、受信完了待ちによるパケットの伝送遅延が発生することを抑制することができる。
　さらに、上記リクエスト実行手段は、上記リクエストを上記コンテンツ配信装置と互いにクロックが同期しているサーバ装置に送信する。そのため、仮に、コンテンツ再生装置とコンテンツ配信装置との間のコンテンツの送受信においてパケットの伝送遅延が発生したとしても、上記リクエスト実行手段が実行する上記リクエストおよび上記レスポンスの送受信には影響しない。よって、コンテンツ再生装置が自装置のクロック補正を行う際に、先行パケットの再送待ち、受信完了待ちによるパケットの伝送遅延が発生することを抑制することができる。
　従って、コンテンツ再生装置は、ＴＣＰに起因するジッタの影響を除去または軽減することにより、クロック補正の精度を高めることができるという効果を奏する。
　また、本発明に係るコンテンツ再生装置は、上記課題を解決するために、コンテンツを分割することにより得られた複数のセグメントを制御データと共にコンテンツ配信装置から取得し、上記制御データに基づいて上記複数のセグメントから上記コンテンツを再生するコンテンツ再生装置であって、上記制御データに含まれる時間情報に基づいて、自装置のクロックを補正するクロック補正手段を備えることを特徴としている。
　上記の構成によれば、上記クロック補正手段は、上記制御データに含まれる時間情報に基づいて、自装置のクロックを補正する。例えば、上記クロック補正手段が使用する時間情報を含む制御データのみをコンテンツ配信装置から取得することにより、データ量の大きいコンテンツの実体データ（セグメント）を送受信することなく、データ量の小さい制御データの送信を要求するリクエストおよび制御データを含むレスポンスの送受信だけで上記クロック補正手段が自装置のクロックを補正することができる。
　よって、コンテンツ再生装置が自装置のクロック補正を行う際に、先行パケットの再送待ち、受信完了待ちによるパケットの伝送遅延が発生することを抑制することができる。従って、コンテンツ再生装置は、ＴＣＰに起因するジッタの影響を除去または軽減することにより、クロック補正の精度を高めることができるという効果を奏する。
　また、本発明に係るコンテンツ再生装置は、上記課題を解決するために、コンテンツを分割することにより得られた複数のセグメントをコンテンツ配信装置から取得すると共に、制御データを制御データ配信装置から取得し、上記制御データに基づいて上記複数のセグメントから上記コンテンツを再生するコンテンツ再生装置であって、上記セグメント取得時に取得した制御データに含まれるクロック同期対象指定情報の示す装置に、上記制御データの送信を要求するリクエストを送信し、当該装置から要求した制御データを受信するリクエスト実行手段と、上記リクエスト実行手段が受信した制御データに含まれる時間情報に基づいて、自装置のクロックを補正するクロック補正手段とを備えることを特徴としている。
　上記の構成によれば、上記リクエスト実行手段は、上記セグメント取得時に取得した制御データに含まれるクロック同期対象指定情報の示す装置に、上記制御データの送信を要求するリクエストを送信し、当該装置から要求した制御データを受信する。そして、上記クロック補正手段が、上記リクエスト実行手段が受信した制御データに含まれる時間情報に基づいて、自装置のクロックを補正する。すなわち、上記リクエスト実行手段は、データ量の大きいリソースの実体データを送受信することなく、データ量の小さい制御データの送信を要求するリクエストおよび制御データを含むレスポンスを送受信する。
　そのため、上記リクエスト実行手段は、データ量の小さいリクエストおよびレスポンスを送受信することにより、上記クロック補正手段が自装置のクロックを補正するために使用する時間情報を含むレスポンスを受信する。よって、コンテンツ再生装置が自装置のクロック補正を行う際に、先行パケットの再送待ち、受信完了待ちによるパケットの伝送遅延が発生することを抑制することができる。
　さらに、上記リクエスト実行手段は、クロック補正をするための上記リクエストを、上記セグメント取得時に取得した制御データに含まれるクロック同期対象指定情報の示す装置に送信する。そのため、仮に、コンテンツ再生装置とコンテンツ配信装置との間のコンテンツの送受信においてパケットの伝送遅延が発生したとしても、上記リクエスト実行手段が実行する上記リクエストおよび上記レスポンスの送受信には影響しない。よって、コンテンツ再生装置が自装置のクロック補正を行う際に、先行パケットの再送待ち、受信完了待ちによるパケットの伝送遅延が発生することを抑制することができる。
　従って、コンテンツ再生装置は、ＴＣＰに起因するジッタの影響を除去または軽減することにより、クロック補正の精度を高めることができるという効果を奏する。
　また、本発明に係るコンテンツ配信システムは、上記コンテンツ再生装置と、上記コンテンツ再生装置にコンテンツを配信するコンテンツ配信装置とを備えることが好ましい。
　上記の構成によれば、コンテンツ配信システムは、上記コンテンツ再生装置と同様の効果を奏する。
　なお、上記コンテンツ再生装置は、コンピュータによって実現してもよく、この場合には、コンピュータを上記コンテンツ再生装置の各手段として動作させることにより、上記コンテンツ再生装置をコンピュータにて実現させる制御プログラム、及びそれを記録したコンピュータ読み取り可能な記録媒体も本発明の範疇に入る。
　〔補足〕
　本発明は上述した各実施形態に限定されるものではなく、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。
　最後に、クライアント３およびクライアント９の各ブロック、特にクライアント制御部２１およびクライアント制御部２４は、ハードウェアロジックによって構成してもよいし、次のようにＣＰＵを用いてソフトウェアによって実現してもよい。
　すなわち、クライアント３およびクライアント９は、各機能を実現する制御プログラムの命令を実行するＣＰＵ（central processing unit）、上記プログラムを格納したＲＯＭ（read only memory）、上記プログラムを展開するＲＡＭ（random access memory）、上記プログラムおよび各種データを格納するメモリ等の記憶装置（記録媒体）などを備えている。そして、本発明の目的は、上述した機能を実現するソフトウェアであるクライアント３およびクライアント９の制御プログラムのプログラムコード（実行形式プログラム、中間コードプログラム、ソースプログラム）をコンピュータで読み取り可能に記録した記録媒体を、上記クライアント３およびクライアント９に供給し、そのコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に記録されているプログラムコードを読み出し実行することによっても、達成可能である。
　上記記録媒体としては、例えば、磁気テープやカセットテープ等のテープ系、フロッピー（登録商標）ディスク／ハードディスク等の磁気ディスクやＣＤ－ＲＯＭ／ＭＯ／ＭＤ／ＤＶＤ／ＣＤ－Ｒ等の光ディスクを含むディスク系、ＩＣカード（メモリカードを含む）／光カード等のカード系、あるいはマスクＲＯＭ／ＥＰＲＯＭ／ＥＥＰＲＯＭ／フラッシュＲＯＭ等の半導体メモリ系などを用いることができる。
　また、クライアント３およびクライアント９を通信ネットワークと接続可能に構成し、上記プログラムコードを通信ネットワークを介して供給してもよい。この通信ネットワークとしては、特に限定されず、例えば、インターネット、イントラネット、エキストラネット、ＬＡＮ、ＩＳＤＮ、ＶＡＮ、ＣＡＴＶ通信網、仮想専用網（virtual private network）、電話回線網、移動体通信網、衛星通信網等が利用可能である。また、通信ネットワークを構成する伝送媒体としては、特に限定されず、例えば、ＩＥＥＥ１３９４、ＵＳＢ、電力線搬送、ケーブルＴＶ回線、電話線、ＡＤＳＬ回線等の有線でも、ＩｒＤＡやリモコンのような赤外線、Ｂｌｕｅｔｏｏｔｈ（登録商標）、８０２．１１無線、ＨＤＲ、携帯電話網、衛星回線、地上波デジタル網等の無線でも利用可能である。
　本発明は、通信ネットワークを介して動画などのコンテンツの取得を行う装置に利用することができる。特に、ストリーミング方式によってコンテンツの取得を行う装置に好適に利用することができる。
　１　　コンテンツ配信システム
　２　　サーバ（コンテンツ配信装置）
　３　　クライアント（コンテンツ再生装置）
　７　　ＭＰＤ配信サーバ（制御データ配信装置、サーバ装置）
　８　　ＭＰ４配信サーバ（コンテンツ配信装置、サーバ装置）
　９　　クライアント（コンテンツ再生装置）
１０　　コンテンツ配信システム
２３　　クライアントクロック（クロック）
３１　　リクエスト実行部（リクエスト実行手段）
３６　　クロック補正部（クロック補正手段）

Claims (15)

  1. 　ＨＴＴＰ（HyperText Transfer Protocol）によりコンテンツ配信装置からコンテンツを取得し、取得したコンテンツを再生するコンテンツ再生装置であって、
    　リソースに関するメタ情報の送信を要求するリクエストを上記コンテンツ配信装置に送信し、当該リクエストに対するレスポンスであって、リソースを含まないレスポンスを受信するリクエスト実行手段と、
    　上記リクエスト実行手段が受信したレスポンスにおけるＨＴＴＰヘッダに含まれる時間情報に基づいて、自装置のクロックを補正するクロック補正手段とを備えることを特徴とするコンテンツ再生装置。
  2. 　上記クロック補正手段は、上記レスポンスのＨＴＴＰヘッダに含まれる上記時間情報に加えて、上記リクエスト実行手段がリクエストを送信した時刻、および、上記レスポンスを受信した時刻に基づいて、自装置のクロックを補正することを特徴とする請求項１に記載のコンテンツ再生装置。
  3. 　上記リクエスト実行手段は、上記コンテンツを取得するためのＴＣＰセッションとは独立したＴＣＰセッションにて、上記リソースに関するメタ情報の送信を要求するリクエストを送信し、当該リクエストに対するレスポンスを受信することを特徴とする請求項１または２に記載のコンテンツ再生装置。
  4. 　上記リクエスト実行手段は、上記リクエストの送信および上記レスポンスの受信をそれぞれ繰り返し、
    　上記クロック補正手段は、上記リクエスト実行手段が受信した各レスポンスのＨＴＴＰヘッダに含まれる時間情報に基づいて、自装置のクロックを補正することを特徴とする請求項１～３の何れか１項に記載のコンテンツ再生装置。
  5. 　上記リクエスト実行手段は、上記リクエストを送信し、当該リクエストに対するレスポンスを受信してから、次のリクエストを送信することを特徴とする請求項１～４の何れか１項に記載のコンテンツ再生装置。
  6. 　上記リクエスト実行手段は、上記コンテンツを取得するためのリクエストに対するレスポンスにおけるＨＴＴＰヘッダに含まれる他の時間情報の示す時刻と、自装置のクロックの示す時刻との差が所定値以上の場合に、上記リクエストを送信することを特徴とする請求項１～５の何れか１項に記載のコンテンツ再生装置。
  7. 　上記リクエスト実行手段は、上記リソースに関するメタ情報の送信を要求するリクエストを、Headメソッドを用いて送信することを特徴とする請求項１～６の何れか１項に記載のコンテンツ再生装置。
  8. 　上記リクエスト実行手段は、上記リソースに関するメタ情報の送信を要求するリクエストを、Optionsメソッドを用いて送信することを特徴とする請求項１～６の何れか１項に記載のコンテンツ再生装置。
  9. 　ＨＴＴＰによりコンテンツ配信装置からコンテンツを取得し、取得したコンテンツを再生するコンテンツ再生装置であって、
    　リソースに関するメタ情報の送信を要求するリクエストを上記コンテンツ配信装置と互いにクロックが同期しているサーバ装置に送信し、当該リクエストに対するレスポンスであって、リソースを含まないレスポンスを受信するリクエスト実行手段と、
    　上記リクエスト実行手段が受信したレスポンスにおけるＨＴＴＰヘッダに含まれる時間情報に基づいて、自装置のクロックを補正するクロック補正手段とを備えることを特徴とするコンテンツ再生装置。
  10. 　コンテンツを分割することにより得られた複数のセグメントを制御データと共にコンテンツ配信装置から取得し、上記制御データに基づいて上記複数のセグメントから上記コンテンツを再生するコンテンツ再生装置であって、
    　上記制御データに含まれる時間情報に基づいて、自装置のクロックを補正するクロック補正手段を備えることを特徴とするコンテンツ再生装置。
  11. 　コンテンツを分割することにより得られた複数のセグメントをコンテンツ配信装置から取得すると共に、制御データを制御データ配信装置から取得し、上記制御データに基づいて上記複数のセグメントから上記コンテンツを再生するコンテンツ再生装置であって、
    　上記セグメント取得時に取得した制御データに含まれるクロック同期対象指定情報の示す装置に、上記制御データの送信を要求するリクエストを送信し、当該装置から要求した制御データを受信するリクエスト実行手段と、
    　上記リクエスト実行手段が受信した制御データに含まれる時間情報に基づいて、自装置のクロックを補正するクロック補正手段とを備えることを特徴とするコンテンツ再生装置。
  12. 　請求項１～８、１０の何れか１項に記載のコンテンツ再生装置と、
    　上記コンテンツ再生装置にコンテンツを配信するコンテンツ配信装置とを備えるコンテンツ配信システム。
  13. 　ＨＴＴＰによりコンテンツ配信装置からコンテンツを取得し、取得したコンテンツを再生するコンテンツ再生装置の同期方法であって、
    　リソースに関するメタ情報の送信を要求するリクエストを上記コンテンツ配信装置に送信するリクエスト送信ステップと、
    　上記リクエスト送信ステップにおいて送信されたリクエストに対するレスポンスであって、リソースを含まないレスポンスを受信するレスポンス受信ステップと、
    　上記レスポンス受信ステップにおいて受信されたレスポンスにおけるＨＴＴＰヘッダに含まれる時間情報に基づいて、自装置のクロックを補正するクロック補正ステップとを含むことを特徴とするコンテンツ再生装置の同期方法。
  14. 　請求項１～１１の何れか１項に記載のコンテンツ再生装置を動作させるための制御プログラムであって、コンピュータを上記各手段として機能させるための制御プログラム。
  15. 　請求項１４に記載の制御プログラムを記録したコンピュータ読み取り可能な記録媒体。
PCT/JP2011/066270 2010-10-05 2011-07-15 コンテンツ再生装置、コンテンツ配信システム、コンテンツ再生装置の同期方法、制御プログラム、および、記録媒体 WO2012046487A1 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2010-225736 2010-10-05
JP2010225736 2010-10-05

Publications (1)

Publication Number Publication Date
WO2012046487A1 true WO2012046487A1 (ja) 2012-04-12

Family

ID=45927487

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/066270 WO2012046487A1 (ja) 2010-10-05 2011-07-15 コンテンツ再生装置、コンテンツ配信システム、コンテンツ再生装置の同期方法、制御プログラム、および、記録媒体

Country Status (1)

Country Link
WO (1) WO2012046487A1 (ja)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015064383A1 (ja) * 2013-10-30 2015-05-07 ソニー株式会社 送信装置、送信方法、受信装置、及び、受信方法
JP2015518350A (ja) * 2012-04-24 2015-06-25 ヴィド スケール インコーポレイテッド Ｍｐｅｇ／３ｇｐｐ−ｄａｓｈにおける滑らかなストリーム切り換えのための方法および装置
JP2017509196A (ja) * 2014-01-16 2017-03-30 クアルコム，インコーポレイテッド Ｄａｓｈのロバストなライブ動作
JP2017517180A (ja) * 2014-04-09 2017-06-22 エルジー エレクトロニクス インコーポレイティド 放送信号送／受信処理方法及び装置
JP2017143528A (ja) * 2012-10-26 2017-08-17 インテル・コーポレーション ビデオの向きの調整（ｃｖｏ）を伴うストリーミング
GB2548440A (en) * 2016-03-14 2017-09-20 Adobe Systems Inc Streaming digital content synchronization
US10523982B2 (en) 2012-10-26 2019-12-31 Intel Corporation Multimedia adaptation based on video orientation

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003510734A (ja) * 1999-09-27 2003-03-18 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ ストリーミングのエミュレート用ファイル分割
JP2003162458A (ja) * 2001-11-26 2003-06-06 Fujitsu Ltd 時刻自動修正プログラム
JP2004171544A (ja) * 2002-10-31 2004-06-17 Oki Electric Ind Co Ltd 時刻制限付コンテンツ閲覧システム
JP2007064791A (ja) * 2005-08-31 2007-03-15 Sony Corp 時刻設定装置及び時刻設定方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003510734A (ja) * 1999-09-27 2003-03-18 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ ストリーミングのエミュレート用ファイル分割
JP2003162458A (ja) * 2001-11-26 2003-06-06 Fujitsu Ltd 時刻自動修正プログラム
JP2004171544A (ja) * 2002-10-31 2004-06-17 Oki Electric Ind Co Ltd 時刻制限付コンテンツ閲覧システム
JP2007064791A (ja) * 2005-08-31 2007-03-15 Sony Corp 時刻設定装置及び時刻設定方法

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Tokushu 1 Internet no `Jikoku' no Himitsu Part1 NTP no Himitsu o Saguru", NIKKEI NETWORK, no. 87, 22 June 2007 (2007-06-22), pages 26 - 31 *
"Tokushu 1 Web Access ni Tsuyoku Naro HTTP Hen Tanjun na Text no Yaritori, Korede Subete no Setsumei ga Tsuku", NIKKEI NETWORK, no. 1, 22 April 2000 (2000-04-22), pages 65 - 71 *
JUN NAKAJIMA: "Shoshinsha no Tameno Internet Katsuyo Koza Dai 6 Kai", INTERFACE, vol. 24, no. 6, 1 June 1998 (1998-06-01), pages 165 - 170 *

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2015518350A (ja) * 2012-04-24 2015-06-25 ヴィド スケール インコーポレイテッド Ｍｐｅｇ／３ｇｐｐ−ｄａｓｈにおける滑らかなストリーム切り換えのための方法および装置
US10432692B2 (en) 2012-10-26 2019-10-01 Intel Corporation Streaming with coordination of video orientation (CVO)
JP2017143528A (ja) * 2012-10-26 2017-08-17 インテル・コーポレーション ビデオの向きの調整（ｃｖｏ）を伴うストリーミング
US10523982B2 (en) 2012-10-26 2019-12-31 Intel Corporation Multimedia adaptation based on video orientation
JPWO2015064383A1 (ja) * 2013-10-30 2017-03-09 ソニー株式会社 送信装置、送信方法、受信装置、及び、受信方法
WO2015064383A1 (ja) * 2013-10-30 2015-05-07 ソニー株式会社 送信装置、送信方法、受信装置、及び、受信方法
US10499094B2 (en) 2013-10-30 2019-12-03 Saturn Licensing Llc Transmission apparatus, transmitting method, reception apparatus, and receiving method
JP2017509196A (ja) * 2014-01-16 2017-03-30 クアルコム，インコーポレイテッド Ｄａｓｈのロバストなライブ動作
JP2017517180A (ja) * 2014-04-09 2017-06-22 エルジー エレクトロニクス インコーポレイティド 放送信号送／受信処理方法及び装置
GB2548440A (en) * 2016-03-14 2017-09-20 Adobe Systems Inc Streaming digital content synchronization
GB2548440B (en) * 2016-03-14 2019-07-10 Adobe Inc Streaming digital content synchronization
US10079884B2 (en) 2016-03-14 2018-09-18 Adobe Systems Incorporated Streaming digital content synchronization
CN107197351A (zh) * 2016-03-14 2017-09-22 奥多比公司 流传输数字内容同步
CN107197351B (zh) * 2016-03-14 2020-12-04 奥多比公司 流传输数字内容同步的方法及系统

Similar Documents

Publication Publication Date Title
WO2012046487A1 (ja) コンテンツ再生装置、コンテンツ配信システム、コンテンツ再生装置の同期方法、制御プログラム、および、記録媒体
KR101748198B1 (ko) 다수의 오버 더 탑 스트리밍 클라이언트들의 동기화
US9973345B2 (en) Calculating and signaling segment availability times for segments of media data
WO2020192152A1 (zh) 视频传输的方法、根节点、子节点、p2p服务器和系统
US8325764B2 (en) Canonical scheduling for heterogeneous content delivery
US20200260132A1 (en) Video distribution synchronization
EP2148491A2 (en) Method and device for receiving content in a content delivery system
US9781474B2 (en) Content playback information estimation apparatus and method and program
US9621682B2 (en) Reduced latency media distribution system
EP3391652B1 (en) Controlling retrieval in adaptive streaming
CN106470352B (zh) 直播频道播放方法、装置及系统
JP7496022B2 (ja) クライアント、サーバ、受信方法及び送信方法
US20180343291A1 (en) Data Rate Adaptation For Multicast Delivery Of Streamed Content
JP2008124924A (ja) 放送ｔｓ配信システム、このシステムに用いられる放送ｔｓ配信装置、ユーザ端末装置及び配信方法
JP2010028691A (ja) コンテンツ受信再生方法および装置
JP2005244605A (ja) ストリーミングコンテンツ配信制御システム、プログラム及び該プログラムを格納した記録媒体
US11900010B2 (en) Method of managing an audio stream read in a manner that is synchronized on a reference clock
JP4650573B2 (ja) 通信装置、通信システム、プログラム、および通信方法
US9635082B2 (en) Method of saving content to a file on a server and corresponding device
EP2479984A1 (en) Device and method for synchronizing content received from different sources
EP3107261B1 (en) System, method and devices for low latency transmission
JP5082715B2 (ja) 受信装置、受信方法およびコンピュータプログラム
JP2005348015A (ja) リアルタイム・ストリーミングデータ受信装置
US20160173268A1 (en) Method of synchronization during the processing, by a multimedia player, of an item of multimedia content transmitted by an mbms service
WO2016099354A1 (en) Request scheduling for streamed media

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: 11830421

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11830421

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP