Client, Server, Receiving Method and Sending Method

Abstract

To provide a client capable of effectively reducing a processing amount, a server, a reception method, and a transmission method.SOLUTION: A client 20A receives streaming data according to MPEG-DASH standard and includes a transmission unit 202 which transmits an MPD request to a server, and a reception unit 201 which receives an MPD. The MPD request contains a push directive for designating whether or not to transmit an initialization segment from a server by a push. When the push directive indicates transmission of the initialization segment from the server by a push, the push directive further indicates whether or not to transmit a medium segment from the server by a push.SELECTED DRAWING: Figure 12

Description

[Technical Field]

[0001] The present disclosure relates to a client receiving a stream of multimedia content over a network with varying bandwidth using the MPEG-DASH format, a server transmitting the stream, and a client receiving method and a server transmitting method. [Background technology]

[0002] Non-Patent Document 1 discloses MPEG-DASH (Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP), a standard for adaptive streaming technology using HTTP (HyperText Transfer Protocol). A DASH server provides content data corresponding to multiple representations with different image quality and bitrates as files corresponding to segments, which are units divided by time, or subsegments obtained by dividing a segment. A segment or subsegment is, for example, a unit divided into several seconds, and a file corresponding to a segment or subsegment is an MP4 file containing video or audio. A file corresponding to a segment or subsegment can be obtained, for example, by specifying a URL address via HTTP. A DASH client can request a file corresponding to a segment or subsegment of an appropriate quality (i.e., representation) depending on the current network conditions and throughput, based on a manifest file (i.e., a Media Presentation Description (MPD)) that describes the configuration of the entire or partial content and the specification of the starting segment. [Prior art documents] [Non-patent literature]

[0003] [Non-Patent Document 1] Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats, INTERNATIONAL STANDARD, ISO / IEC 23009-1:2014(E) Summary of the Invention [Problem to be solved by the invention]

[0004] However, the technology disclosed in Non-Patent Document 1 has not been able to reduce the amount of processing performed by the client and the server. [Means for solving the problem]

[0005] A client according to one embodiment of the present disclosure is a client that receives streaming data in accordance with the MPEG-DASH (Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP) standard, and includes a transmitter that transmits a Media Presentation Description (MPD) request to a server, and a receiver that receives the Media Presentation Description (MPD), wherein the MPD request includes a push directive that specifies whether an initialization segment is to be sent from the server by push, and when the push directive indicates that the initialization segment is to be sent from the server by push, the push directive further specifies whether a media segment is to be sent from the server by push. Contains information .

[0006] A server according to an embodiment of the present disclosure may include a moving picture encoding (MPEG-DASH) encoding method. 1. A server that transmits streaming data in accordance with the IEEE 802.11b / g Experts Group - Dynamic Adaptive Streaming over HTTP (IEEE 802.11b / g) standard, comprising: a receiving unit that receives a Media Presentation Description (MPD) request from a client; and a transmitting unit that transmits the Media Presentation Description (MPD), wherein the MPD request includes a push directive that specifies whether an initialization segment is to be sent from the server by push; and when the push directive indicates that the initialization segment is to be sent from the server by push, the push directive further specifies whether media segments are to be sent from the server by push. Contains information .

[0007] A client according to one embodiment of the present disclosure is a client that complies with the MPEG-DASH (Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP) standard and includes a transmitter and a receiver, and the transmitter transmits a Media Presentation Data (MPD) including a first push directive. The client sends a request for an MPD (Mapping of MPD Description) to a server, the receiving unit receives from the server an MPD specified in the request for the MPD and an initialization segment, the sending unit sends to the server a segment request including a second push directive, the receiving unit receives from the server a first segment specified in the segment request and a second segment that follows the first segment in accordance with the second push directive, the first push directive and the second push directive each describe a push type that defines a strategy for pushing information from the server to the client, the first push directive indicates whether to push a media segment in addition to the initialization segment, and the second push directive indicates that a media segment included in a representation to which the media segment specified in the segment request belongs is to be pushed.

[0008] A receiving method according to one embodiment of the present disclosure is a receiving method implemented by a client that complies with the MPEG-DASH (Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP) standard, and includes receiving a Media Presentation Data (MPD) containing a first push directive. a request for an MPD (MPD Description) to a server, receiving from the server an MPD specified in the request for the MPD and an initialization segment, sending a segment request to the server including a second push directive, receiving from the server a first segment specified in the segment request and a second segment that follows the first segment in accordance with the second push directive, the first push directive and the second push directive each describing a push type defining a strategy for pushing information from the server to the client, the first push directive indicating whether to push a media segment in addition to the initialization segment, and the second push directive indicating to push a media segment included in a representation to which the media segment specified in the segment request belongs.

[0009] A server according to an embodiment of the present disclosure may include a moving picture encoding (MPEG-DASH) encoding method. A server conforming to the Experts Group - Dynamic Adaptive Streaming over HTTP standard, comprising a transmitter and a receiver, wherein the receiver transmits a Media Presentation Data (MPD) including a first push directive. The server receives a request for an MPD (Mapping of MPDs to a Representation) from a client, wherein the sending unit sends an MPD specified in the request for an MPD and an initialization segment to the client, the receiving unit receives a segment request from the client including a second push directive, and the sending unit sends to the client a first segment specified in the segment request and a second segment that follows the first segment in accordance with the second push directive, wherein the first push directive and the second push directive each describe a push type that defines a strategy for pushing information from the server to the client, the first push directive indicating whether to push a media segment in addition to the initialization segment, and the second push directive indicating to push a media segment included in a representation to which the media segment specified in the segment request belongs.

[0010] A transmission method according to one embodiment of the present disclosure is a transmission method implemented by a server that complies with the MPEG-DASH (Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP) standard, and includes transmitting a Media Presentation Data (MPD) including a first push directive. a request for an MPD (MPD Description) from a client, sending an MPD specified in the request for the MPD and an initialization segment to the client, receiving a segment request from the client including a second push directive, sending to the client a first segment specified in the segment request and a second segment that follows the first segment in accordance with the second push directive, wherein the first push directive and the second push directive each describe a push type that defines a strategy for pushing information from the server to the client, the first push directive indicating whether to push media segments in addition to the initialization segment, and the second push directive indicating to push media segments included in a representation to which the media segment specified in the segment request belongs.

[0011] A client according to one embodiment of the present disclosure is a client that complies with the MPEG-DASH (Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP) standard and has a transmitter and a receiver, wherein the transmitter transmits a request for a Media Presentation Description (MPD) including a first push directive to a server, the receiver receives an MPD specified in the MPD request and an initialization segment from the server, the transmitter transmits a segment request including a second push directive to the server, and the receiver receives from the server a first segment specified in the segment request and a second segment that follows the first segment in accordance with the second push directive, the first push directive and the second push directive each describing a push type that defines a strategy for pushing information from the server to the client, and the first push directive indicates whether to push a media segment in addition to the initialization segment.

[0012] A receiving method according to one embodiment of the present disclosure is a receiving method implemented by a client that complies with the MPEG-DASH (Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP) standard, which includes sending a request for an MPD (Media Presentation Description) including a first push directive to a server, receiving from the server an MPD specified in the MPD request and an initialization segment, sending a segment request including a second push directive to the server, and receiving from the server a first segment specified in the segment request and a second segment that follows the first segment in accordance with the second push directive, wherein the first push directive and the second push directive each describe a push type that defines a strategy for pushing information from the server to the client, and the first push directive indicates whether to push a media segment in addition to the initialization segment.

[0013] A server according to an embodiment of the present disclosure may include a moving picture encoding (MPEG-DASH) encoding method. a server conforming to the (RPC Experts Group - Dynamic Adaptive Streaming over HTTP) standard and comprising a transmitter and a receiver, wherein the receiver receives a request for a Media Presentation Description (MPD) including a first push directive from a client, the transmitter transmits an MPD specified in the MPD request and an initialization segment to the client, the receiver receives a segment request including a second push directive from the client, and the transmitter transmits to the client a first segment specified in the segment request and a second segment following the first segment in accordance with the second push directive, the first push directive and the second push directive each describing a push type defining a strategy for pushing information from the server to the client, and the first push directive indicates whether to push a media segment in addition to the initialization segment.

[0014] A transmission method according to one aspect of the present disclosure is a transmission method implemented by a server that complies with the MPEG-DASH (Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP) standard, comprising: receive a request for a Media Presentation Description (MPD) from a client, the request including a first push directive; transmit an MPD specified in the MPD request and an initialization segment to the client; receive a segment request from the client, the request including a second push directive; transmit a first segment specified in the segment request and a second segment following the first segment in accordance with the second push directive to the client; the first push directive and the second push directive each describe a push type that defines a strategy for pushing information from the server to the client; and the first push directive indicates whether to push a media segment in addition to the initialization segment.

[0015] A client according to another aspect of the present disclosure is a client that complies with the MPEG-DASH (Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP) standard and includes a transmitter and a receiver, and the transmitter transmits a Media Presentation Data (MPD) including a first push directive. the receiving unit receives an MPD specified in the request for the MPD from the server and receives an initialization segment from the server in response to the first push directive; the sending unit sends a segment request including a second push directive to the server; the receiving unit receives the first segment specified in the segment request from the server and receives a second segment subsequent to the first segment from the server in response to the second push directive; the first push directive and the second push directive each describe a push type that defines a strategy for pushing information from the server to the client; and a push type selectable in the push directive added to the request for the MPD cannot be selected in the push directive added to the segment request.

[0016] A receiving method according to another aspect of the present disclosure is a receiving method implemented by a client that complies with the MPEG-DASH (Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP) standard, the receiving method including: sending a request for an MPD (Media Presentation Description) including a first push directive to a server; receiving an MPD specified in the MPD request from the server; receiving an initialization segment from the server in response to the first push directive; sending a segment request including a second push directive to the server; receiving a first segment specified in the segment request from the server; and receiving a second segment that follows the first segment from the server in response to the second push directive; the first push directive and the second push directive each describe a push type that defines a strategy for pushing information from the server to the client; and a push type selectable by the push directive added to the request for the MPD cannot be selected by the push directive added to the segment request.

[0017] A server according to another aspect of the present disclosure is a server that complies with the MPEG-DASH (Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP) standard and includes a transmitter and a receiver, and the receiver transmits an MPD (Media Picture Data) including a first push directive. the sending unit receives a request for an MPD (Multimedia Presentation Description) from a client, the sending unit sends an MPD specified in the request for the MPD to the client, and sends an initialization segment to the client in response to the first push directive, the receiving unit receives a segment request including a second push directive from the client, the sending unit sends the first segment specified in the segment request to the client, and sends a second segment that follows the first segment to the client in response to the second push directive, the first push directive and the second push directive each describe a push type that defines a strategy for pushing information from the server to the client, and a push type selectable in the push directive added to the request for the MPD cannot be selected in the push directive added to the segment request.

[0018] A transmission method according to another aspect of the present disclosure is a transmission method implemented by a server that complies with the MPEG-DASH (Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP) standard, which receives a request for a Media Presentation Description (MPD) from a client, the request including a first push directive, sends the MPD specified in the MPD request to the client, sends an initialization segment to the client in response to the first push directive, receives a segment request from the client, the request including a second push directive, sends the first segment specified in the segment request to the client, and sends a second segment that follows the first segment to the client in response to the second push directive, the first push directive and the second push directive each describe a push type that defines a strategy for pushing information from the server to the client, and a push type selectable in the push directive added to the request for the MPD cannot be selected in the push directive added to the segment request.

[0019] A client according to another aspect of the present disclosure is a client that receives streaming data according to the MPEG-DASH (Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP) standard, and includes a transmitter that transmits a request for an MPD (Media Presentation Description) or a request for a segment to a server, and a receiver that receives an MPD specified in the MPD request and a segment specified in the segment request, wherein the MPD request includes information requesting that an initialization segment be sent by push, and the receiver receives the initialization segment sent by push.

[0020] A server according to another embodiment of the present disclosure is a server that transmits streaming data conforming to the MPEG-DASH standard, and includes a receiving unit that receives an MPD request or a segment request from a client, and a transmitting unit that transmits, by push, to the client an MPD specified in the MPD request received by the receiving unit and a segment specified in the segment request received by the receiving unit, wherein the MPD request includes information requesting that an initialization segment be transmitted by push, and the transmitting unit transmits the initialization segment by push.

[0021] These general or specific aspects may be realized as a system, a method, an integrated circuit, a computer program, or a recording medium such as a computer-readable CD-ROM, or as any combination of a system, a method, an integrated circuit, a computer program, and a recording medium. [Effects of the Invention]

[0022] According to the above aspect, the amount of processing performed in the client and the server can be reduced. [Brief explanation of the drawings]

[0023] [Figure 1] FIG. 1 is a diagram illustrating a communication system according to the second embodiment. [Figure 2] FIG. 2 is a diagram showing the structure of a TCP header. [Figure 3] FIG. 3 shows an excerpt from a Wireshark session. [Figure 4] Figure 4 is a graph showing the estimated throughput when transmitting at a TCP bandwidth of 100 kByte / s. [Figure 5] FIG. 5 is a graph showing the estimated throughput when transmitting with a TCP bandwidth of 500KByte / s. [Figure 6]FIG. 6 is a graph showing the estimated throughput when transmission is performed without limiting the bandwidth. [Figure 7] FIG. 7 is a graph showing the estimated throughput when transmission is performed without limiting the bandwidth. [Figure 8] FIG. 8 is a graph showing the estimated throughput when transmission is performed without limiting the bandwidth. [Figure 9] FIG. 9 is a graph showing the estimated results of throughput when transmission is performed without limiting the bandwidth. [Figure 10] FIG. 10 is a diagram illustrating another example of a detailed configuration of the communication system according to the second embodiment. [Figure 11] FIG. 11 is a sequence diagram showing the operation of the communication system in the modified example. [Figure 12] FIG. 12 is a diagram illustrating another example of a specific configuration of a communication system. [Figure 13] FIG. 13 is a sequence diagram for explaining the operation of the communication system, including the transmission method by the server and the reception method by the client. DETAILED DESCRIPTION OF THE INVENTION

[0024] A client according to one embodiment of the present disclosure is a client that receives streaming data according to the MPEG-DASH (Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP) standard, and includes a transmitter that transmits a request for an MPD (Media Presentation Description) or a request for a segment to a server, and a receiver that receives an MPD specified in the MPD request and a segment specified in the segment request, wherein the MPD request includes information requesting that an initialization segment be sent by push, and the receiver receives the initialization segment sent by push.

[0025] A server according to one embodiment of the present disclosure is a server that transmits streaming data conforming to the MPEG-DASH standard, and includes a receiving unit that receives an MPD request or a segment request from a client, and a transmitting unit that transmits, via push, to the client an MPD specified in the MPD request received by the receiving unit and a segment specified in the segment request received by the receiving unit, wherein the MPD request includes information requesting that an initialization segment be transmitted via push, and the transmitting unit transmits the initialization segment via push.

[0026] These general or specific aspects may be realized as a system, a method, an integrated circuit, a computer program, or a computer-readable recording medium such as a CD-ROM, or as any combination of a system, a method, an integrated circuit, a computer program, or a recording medium.

[0027] Hereinafter, a client, a server, a receiving method, and a transmitting method according to an embodiment of the present invention will be specifically described with reference to the drawings.

[0028] It should be noted that the embodiments described below each illustrate a specific example of the present invention. The numerical values, shapes, materials, components, component placement and connection configurations, steps, and step order shown in the following embodiments are merely examples and are not intended to limit the present invention. Furthermore, among the components in the following embodiments, components that are not described in the independent claims that represent the highest concept are described as optional components.

[0029] (Embodiment 1) [1-1. Background technology] MPEG-DASH specifies a URL addressing format for ISO-BMFF formatted media segments, and the manifest file is called MPD (Media Presentation Description). DASH was originally devised to address the transport of media over networks with variable throughput (e.g., over-the-top (OTT)). The MPEG-DASH system is client-centric and leverages already available technology. Therefore, existing HTTP-web servers and DASH-enabled clients can implement dynamic streaming sessions.

[0030] The first concept was expanded by MPEG, and new concepts were introduced, such as Server-And-Network-Assisted DASH (SAND), Content-Aggregation-and-Playback Control (CAPCO), and Full-Duplex-HTTP (FDH). The latter, FDH, leverages the recently ratified HTTP / 2 standard and allows a server to push to a client without the client having requested it itself. The benefit of the defined related push directives is primarily overhead reduction: for every pushed segment, the corresponding HTTP request from the client can be omitted, thereby saving bandwidth.

[0031] The FDH part of DASH is currently specified in ISO / IEC 23009 Part 6 and includes four strategies for pushing content from the server to the client. These strategies are called push directives and consist of a push type and additional push parameters. Examples of push types include push next, push none, push template, and push time.

[0032] The push parameter K with push-next indicates that the next K segments will be considered for pushing using the requested segment as the initial index.

[0033] A push-nan indicates that no push occurred. In this case, the parameter is not used.

[0034] A push template indicates that some segment described by a URI template is being considered for pushing. The push parameters are referred to as a URI template.

[0035] The push time is considered for pushing up to the specified segment time beyond the start of the requested segment (segment time T). Time T is signaled as a push parameter.

[0036] Push Next and Push Time indicate that the server can choose to push indefinitely by setting these push parameters to 0. This is already within the scope of the present invention, but does not give the server any control beyond the choice of representation, nor does it affect bitrate fluctuations.

[0037] [1-2. Typical DASH-FDH Session] The client first requests an MPD and then media segments with a push directive. After receiving the requested MPD, the client initiates a request for media segments from the server using the DASH segment URL and push directive, respectively. The server then responds with the requested media segments. The media segments continue through a push cycle, as indicated by the push strategy. The client starts playing media after receiving a minimum amount of data. The above process is repeated until the media streaming session ends.

[0038] To prepare the client for the next media segment, the server may also push an initialization segment in advance, along with the MPD, which contains the segment header information.

[0039] The advantage of the push directive is the reduction of overhead. All of the above push directives require the client to request a new segment if any of the requested number of segments have yet to be delivered (push next) or if the segment time has been exceeded (push time). Described below is a new push directive, an aspect of this disclosure, that allows the server to automatically select and push segments over the entire media duration. This minimizes the overhead caused by segment requests. It also provides support for unicast and / or multicast mode applications for all or part of the client's connections. The parameters that the server automatically determines may be only those related to the network bandwidth between the server and the receiving terminal, such as the bit rate and resolution of the segment.

[0040] [1-3. Estimating client-side throughput at the server] Part of this disclosure is a method for a server to estimate the throughput experienced by a client based on the acknowledgment number contained in the acknowledgment packets sent from the client to the server during a TCP / IP connection. Because these acknowledgment packets are an integral part of the TCP layer, no additional overhead is generated or required to use this method. This throughput estimation method, along with the automatic push directive, minimizes the total overhead while maintaining the DASH philosophy of switching displays based on current throughput.

[0041] DASH is based on the ubiquitous HTTP protocol, which relies on the underlying TCP / IP layer to transport requests, responses, and data. The TCP / IP layer divides the data stream into packets and ensures their reliable transmission. The HTTP layer is completely independent of this process. The packetization and reassembly processes are enabled by two fields contained in the TCP header: the sequence number and the acknowledgment number.

[0042] The sequence number and acknowledgment number are generated by both endpoints during the initial stage of a TCP connection (the three-way handshake). Both numbers are used in the packetization and reassembly process. They are initially two random 32-bit integers exchanged between the server and the client.

[0043] The sequence number is incremented by the server by the number of bytes currently sent, so that the relative sequence number within a packet acts as a pointer to the start of the current packet within the total data byte stream.

[0044] More importantly, the acknowledgment number is sent from the client to the server to inform the server of the number of bytes successfully received, so a server with an external timer measuring the arrival time of the acknowledgment packets can easily estimate the throughput currently experienced by the client.

[0045] [1-4. Effects, etc.] As already mentioned, the system according to the present disclosure can reduce overhead because metric messages and segment requests are not required. Furthermore, the system according to the present disclosure can centrally manage switching between unicast and multicast modes. Furthermore, the system according to the present disclosure can centrally manage its resources. That is, by monitoring throughput, the server can predict throughput bottlenecks and smoothly reduce the transmission bit rate, thereby avoiding unintended highly dynamic changes in presentation. HTTP / 2-compatible clients do not need to track traffic diagnostics. Traffic diagnostics can simultaneously achieve power savings and cost reductions.

[0046] Furthermore, a server typically serves data to multiple clients. Using mechanisms for automatic push directives and throughput estimation, the server can choose to switch from unicast mode to the more efficient multicast mode when multiple clients simultaneously request the same content (e.g., related to live TV transmissions). Depending on channel conditions, for example, the server can assign unicast or multicast mode to all or some of these clients.

[0047] In particular, when communicating within a specific area such as an event venue, it may be possible to estimate in advance the rate and segment that are likely to be selected based on other information such as the number of attendees, information specific to communication devices within the area, etc. In such cases, the judgment and selection process on the server is simplified, enabling ideal distribution with minimal delay.

[0048] [1-5. Overview of the Disclosure] New DASH Auto-Push Directive DASH push parameters / capability indicators: The client needs to signal its capabilities before the server can provide media segments indefinitely.

[0049] -Throughput estimation method based on TCP acknowledgment number Combining existing DASH push directives (next, time, template) with the new claimed automatic DASH push directive Example: The server automatically pushes the next K segments, and then receives a new push request to automatically push the next L segments.

[0050] Automatic and dynamic selection of unicast or multicast mode for all or some clients simultaneously requesting the same content (based on the throughput measurements above) [1-5-1.Details 1] The new DASH push directive allows the server to select and push data to clients as monitored by the server. In the following, this push directive is referred to as the auto-push directive.

[0051] [1-5-2.Details 2] DASH pushes parameters along with the push directive. The client's capabilities are also communicated to the server. The client is, for example, a device capable of processing available media decoders, playable image resolutions, and frame rates. In an embodiment, the push parameters may be represented by a composite data type with fields taken from a Receiver Capability Table (RCT), as shown in Tables 1-1 and 1-2. This embodiment should not be interpreted as limiting. For example, it should not be limited to any form of Receiver Capability Table that serves the same purpose of communicating the client's capabilities to the server.

[0052] [Table 1-1]

[0053] [Table 1-2]

[0054] The "modeIndicator" guides the server in selecting the actual parameters. Suitable modes are, for example, highest quality, lowest quality, and low dynamics in switching representations. These are shown in Table 2. Other modes are possible, and the invention should not be understood as being limited to these modes shown.

[0055] [Table 2]

[0056] [1-5-3.Details 3] Other DASH push directive combinations include the auto or push auto rate push directives. In one embodiment of the present disclosure, suitable push directives to combine with the auto push directive may be push next, push time, and push template, but should not be limited to these combinations.

[0057] For example, by using push-next to specify that the next N segments should be received and specifying push-automatic-rate, the server will automatically select the bit rate for the N segments. Alternatively, the push-automatic-rate may remain in effect until it is disabled by a separately specified push directive, push-channel-automatic-rate. If push-channel-automatic-rate is not issued at this time, the push-automatic-rate will remain in effect for segments sent after the N segments have been sent.

[0058] Even after push-full-automatic is specified, if the server receives a push-nan while sending a segment, the server will stop sending the segment immediately or after sending the final data of the segment in progress.

[0059] [1-5-4.Details 4] The estimation method and estimation device estimate the throughput of a client based on the acknowledgment number sent in the TCP header from the client to the server by measuring the arrival time of the acknowledgment packet using an external timer.

[0060] The relative acknowledgment number is shown as the difference between the current acknowledgment number and the first acknowledgment number, and similarly the relative time is shown as the difference between the arrival time of the current acknowledgment packet and the arrival time of the first acknowledgment packet. A first method for throughput estimation is to calculate the quotient of the relative acknowledgment number and the relative time.

[0061] Show the acknowledgment number difference as the difference between the last and penultimate acknowledgment packets. Similarly, show the time difference as the difference in arrival time between the last and penultimate acknowledgment packets. A second method for estimating throughput is to calculate the average of successive quotients of the acknowledgment number difference and the time difference with an appropriate digital filter.

[0062] [1-5-5.Details 5] Automatic and dynamic selection (in the extreme case of per-segment) is performed, which involves choosing between unicast and multicast mode for all or some clients simultaneously requesting the same content, based on the throughput measurements described above (which represent the quality of the connection to each single client).

[0063] (Embodiment 2) [2-1. Background technology] The DASH philosophy is based on clients measuring throughput and requesting segments based on those measurements. Recently, HTTP / 2 introduced a new push feature that allows servers to send data to clients unsolicited. In Part 6 of the DASH specification, MPEG hopes to leverage this new HTTP / 2 feature for DASH. Part 6 is called FDH. Four push directives already exist (push next, push noun, push template, and push time), but they are still largely client-driven.

[0064] As explained in the first embodiment, the throughput to the client can be measured on the server side, that is, the server can manage the client by using the new auto-push directive.

[0065] Segment selection is partly or entirely controlled by the server based on push directives, i.e., the number of segments to send, the time at which they are sent, and their bitrate are all determined by the server.

[0066] [2-2. Measurement setup] Fig. 1 is a diagram illustrating a communication system according to embodiment 2. Fig. 1(a) is a block diagram illustrating an example of the configuration of the communication system, and Fig. 1(b) is a diagram illustrating a communication state in the communication system.

[0067] As shown in FIG. 1( a ), the communication system 1 includes a server 10 and a client 20 that is communicatively connected to the server 10 via a communication network 30 .

[0068] Server 10 is an HTTP / 2 server. It runs a dummy net for custom traffic shaping. Server 10 captures all packets to a pcap file (for further processing in Python with the scapy package) by running software (e.g., Wireshark®) for packet capture and protocol analysis. Here, pcap (packet capture) is an API (Application Programming Interface) for packet sniffers (packet analyzers) in the field of computer network management. In Unix-based systems, pcap is implemented as libpcap.

[0069] The server 10 transmits a 1MB file with PRBS (Pseudo-Random Bit Sequence). A dummy net is used for traffic shaping, specifically to control the transmission bandwidth. Wireshark® captures and stores the TCP / IP traffic. Python is used for data aggregation and evaluation based on the Wireshark® capture.

[0070] The server 10 may be realized by a processor and a memory in which a predetermined program is stored, or may be realized by a dedicated circuit. The server 10 includes a computer.

[0071] The client 20 may be realized by a TV, a player, a recorder, a smartphone, a tablet terminal, a PC, or the like.

[0072] As shown in FIG. 1(b), it is possible to obtain the timing (timestamp) when the file is transmitted from the server 10 and the timing when the ACK for the file is transmitted from the client 20.

[0073] [2-3. Dummy Net] Next, the dummy net executed by the server 10 will be described.

[0074] Dummynet is a network emulation tool. It simulates queues, bandwidth limits, delays, and packet loss, and implements various scheduling algorithms. Dummynet runs within any operating system and operates by intercepting selected traffic en route through the network stack. It passes packets to pipes that implement a set of queues, schedulers, and links, all of which implement configurable features (bandwidth, delay, loss rate, queue size, scheduling policy, etc.). Traffic selection is performed using the ipfw firewall, the main user interface for Dummynet. It creates a "Hello world" pipe for all outgoing TCP traffic and sets the bandwidth to 500kByte / s. For example, the packet filter firewall ipfw (ipfirewall) adds a pipe outside of proto TCP. For example, one ipfw pipe has a bandwidth of 500kByte / s.

[0075] [2-4. TCP Header] Next, the TCP header will be described.

[0076] FIG. 2 is a diagram showing the structure of a TCP header.

[0077] As shown in FIG. 2, the TCP header includes a sequence number and an acknowledgement number.

[0078] The sequence number is a pointer to the current payload's position in the overall transmitted data byte stream, and is used to sort received packets in the same order they were transmitted.

[0079] The acknowledgment number indicates that a packet bearing a particular sequence number was received correctly, and includes the next expected sequence number.

[0080] From the acknowledgement number (sent from the client to the server), the server 10 can derive the number of bytes successfully received. The timing of the ACK packets can further be used to estimate the current throughput.

[0081] During the three-way handshake, both endpoints (i.e., server 10 and client 20) generate random 32-bit integers for their respective sequence numbers and exchange them. As shown in the Wireshark® session excerpt (Figure 3), the boxes indicate the sequence number and the acknowledgment number. The sending endpoint increments its sequence number by the number of bytes currently sent. The acknowledgment number is used by the client to indicate the number of bytes that were correctly received.

[0082] Figures 4 to 9 are graphs showing the number of bytes actually transmitted and the throughput results estimated using the above method. Figure 4 is a graph showing the estimated throughput results when transmitted at a TCP bandwidth of 100 kByte / s. Figure 5 is a graph showing the estimated throughput results when transmitted at a TCP bandwidth of 500 KByte / s. Figures 6 to 9 are graphs showing the estimated throughput results when transmitted without bandwidth restrictions.

[0083] As shown in FIGS. 4 to 9, the estimated results generally match the number of bytes actually transmitted, so the estimated results can be used.

[0084] As mentioned above, the above server-side throughput measurements show that this is largely feasible.

[0085] This allows the server 10 to be the primary manager of its resources. The server 10 is more able to avoid variations in representations on the client 20 side. The client 20 does not need to be smart and keep track of traffic diagnostics. Storing metrics / diagnostic messages reduces overhead.

[0086] For example, a push directive may be employed with the addition of push automatic rate and push full automatic, as shown in Table 3.

[0087] [Table 3]

[0088] FIG. 10 is a diagram illustrating another example of a detailed configuration of the communication system according to the second embodiment.

[0089] The communication system 1 includes a server 10 and a client 20. The server 10 and the client 20 are communicatively connected to each other via a communication network 30.

[0090] The server 10 and the client 20 each have a processor, storage, and a communication device including a transceiver.

[0091] The processors provided in the server 10 and the client 20 each execute the processing shown in the sequence diagram (see FIG. 11). The processors use other units in cooperation with the server 10 and the client 20 or other devices. Typically, programs for executing the processing shown in the flow are stored in storage provided in the server 10 and the client 20, respectively.

[0092] The server 10 includes a selection unit 11 and a transmission unit 12 .

[0093] The server 10 and the client 20 will be described in detail in the description of their respective operations in the communication system 1.

[0094] FIG. 11 is a sequence diagram illustrating an example of the operation of the communication system.

[0095] First, the client 20 transmits an MPD request indicating a request for an MPD to the server 10 (S11).

[0096] Next, the server 10 receives the MPD request transmitted from the client 20, and the transmission unit 12 of the server 10 transmits an MPD corresponding to the received MPD request (corresponding MPD) to the client 20 (S12). As described in the first embodiment, in S12, the server 10 may transmit some or all of the initialization segments to the client 20 by push in addition to the MPD corresponding to the received MPD request. Hereinafter, transmitting other files such as initialization segments and updated new MPD by push in response to an MPD request in addition to the MPD specified in the MPD request will also be referred to as MPD push.

[0097] Note that when the server 10 does not send the initialization segment by push, the client 20 operates in the same way as when communicating with a server that does not support push transmission. That is, the client 20 sends a segment request specifying the necessary initialization segment from among the initialization segments described in the received MPD. The server 10 sends the initialization segment specified in the received segment request to the client 20.

[0098] The client 20 receives the corresponding MPD, transmits a segment request indicating a request for segment #n together with one or more push directives to the server 10, and counts the Ack (S13).

[0099] The server 10 receives a segment request for segment #n that specifies a push directive, and the selection unit 11 of the server 10 determines a fixed rate or an adaptive rate based on the push directive of the received segment, and selects a segment to send based on the received segment request for segment #n (S14).

[0100] The server 10 transmits the segment n specified in the segment request, and then sequentially transmits the segments n+1 and onward selected by the selection unit 11 by push (S15, S16). Hereinafter, transmitting segments other than the segment specified in the segment request by push in response to the segment request will also be referred to as segment push.

[0101] Note that segment n may be transmitted before determining the fixed rate or adaptive rate. The selector 11 selects segments after segment n based on the throughput obtained by the measurement using the Ack described above. If the push directive specified in the segment request for segment #n is a push directive requesting a push transmission other than push automatic rate or push fully automatic, the selector 11 selects segments after segment n+1 in accordance with the push directive specified in the segment request for segment #n without measuring the throughput.

[0102] 10 illustrates only a selection unit 11 and a transmission unit 12, which are necessary for transmitting segments at an adaptive rate, as components included in the server 10. However, it goes without saying that the server 10 also includes other components necessary for operating as a DASH server, for example, as described in Non-Patent Document 1. For example, the server 10 includes a reception unit that receives messages such as MPD requests and segment requests transmitted by the client 20, a processing unit that interprets DASH commands included in the received messages, and generates messages to be transmitted to the client 20 as responses to messages such as MPD requests and segment requests.

[0103] 10 shows an example in which the MPD delivery function is located outside the server 10, which indicates that the MPD may be transmitted to the client 20 from a communication device different from the server 10. However, as will be explained in the following description of FIG. 11, when the server 10 transmits an MPD to the client 20 in response to an MPD request transmitted from the client 20, the server 10 has an MPD transmission function.

[0104] Although FIG. 10 shows an example in which the throughput measurement module is arranged outside the server 10, the server 10 may also include the throughput measurement module.

[0105] If the server 10 does not support push directives that control the bit rate on the server side, such as the above-mentioned push automatic rate or push fully automatic, the throughput measurement module shown in Fig. 10 may be omitted. In this case, the selection unit 11 of the server 10 selects a segment to push based on a push directive (e.g., push next, push template, push time) other than the push directive that controls the bit rate on the server side, which is added to the segment request received from the client 20. If a push number is specified, the client 20 transmits a segment request to the server 10 specifying the segment required for playback and acquires that segment.

[0106] Although FIG. 10 does not disclose a detailed configuration of the client 20, it goes without saying that the client 20 also includes other components necessary for operation as a DASH client, for example, as described in Non-Patent Document 1. For example, the client 20 includes a transmitter that transmits messages such as an MPD request, a segment request, and an Ack to the server 10 or other communication devices, and a receiver that receives messages including an MPD, a segment, and a DASH command from the server 10 or other communication devices. The client 20 also includes a DASH access unit that interprets DASH commands included in received messages and generates DASH commands such as an MPD request and a segment request to be transmitted to the server 10 or other communication devices. The client 20 may also include a decoder that decodes media data acquired by the DASH access unit and displays the decoded audio and video signals on an internal display unit of the client or an external display unit connected to the client via a wired or wireless connection. The display unit may be, for example, a display or a speaker. The client 20 may also include an application unit that executes event data acquired by the DASH access unit.

[0107] [3. Modifications] In the above-described embodiment, the following modifications are applicable.

[0108] [3-1. Variation 1] In the above-described embodiment, examples have been given in which push automatic rate and push full automatic are defined as new push strategies that can be specified as "pushType" in parallel with push next and push noun, but they may also be defined in other formats.

[0109] For example, push automatic rate and push fully automatic may be defined as parameters that can be written in parallel with the "K:Number" parameter (PUSH_PARAMS) specified when Push Next is selected for PushType. In this case, multiple parameters are written in PUSH_PARAMS of the push directive or PushAck. Similarly, when a push template or push type is selected as PushType, you can specify whether it is "automatic" or the "automatic" mode in PUSH_PARAMS.

[0110] Also, for example, push automatic rate or push full automatic may be defined as a parameter in parallel (written side by side) with PUSH_TYPE in the push directive. In this case, the push directive format has a field separate from PUSH_TYPE that specifies whether or not "automatic" is used, or the "automatic" mode.

[0111] [3-2. Variation 2] The following modifications can be applied to the above-described embodiment. However, the following configurations may be used without being combined with the above-described embodiment (for example, specifying "automatic" in segment push). By treating "automatic" as an independent attribute in this way, it is possible to specify whether the server 10 automatically determines not only the number, duration, and bit rate of segments to be transmitted by the server 10, but also other parameters.

[0112] For example, when specifying an MPD push using a push directive (or other Data Type) in an MPD request, any of the following configurations or any combination of the following configurations may be used:

[0113] (1) If the execution of MPD push is specified using a push directive in the MPD request, the server 10 may send a new MPD by push when the MPD is updated.

[0114] (2) When the implementation of MPD push is specified using a push directive in the MPD request, the server 10 may send, by push, metadata related to the decoding or display of the media data in addition to the specified MPD. Here, an example of the metadata is MP4 header information (i.e., initialization segment) when the media data is MP4. The metadata stores, for example, access information for encoded audio and video data, PTS / DTS, etc. In other words, the server 10 may send the initialization segment along with the MPD to the client 20. Note that in this case, the push directive in the MPD request may specify whether or not to send metadata by push.

[0115] (3) The period or number of times that the MPD (or metadata) is sent by the server 10 by push may be specified by, for example, the push type. That is, the server 10 may send the number of times or the MPD (and metadata) by push for the period or specified by the push type.

[0116] (4) When MPD Push is specified, the server 10 performs a predetermined operation (default operation), and the push directive in the MPD request may simply specify whether or not to perform MPD Push. However, it may also be possible for the client 20 or the server 10 to specify whether to cancel (not perform) MPD Push.

[0117] It goes without saying that if the client 20 sends an MPD request specifying a push directive requesting MPD Push, but the server 10 specifies not to perform MPD Push, the subsequent operation of the client 20 is the same as the operation of a client that does not support MPD Push. That is, the client 20 obtains the initialization segment required for playing the desired media by sending a segment request to the server 10.

[0118] In this way, by allowing the server 10 to specify that an MPD push will not be performed, the server 10 can decide not to push an initialization segment even for a client 20 that requests a push transmission of an initialization segment, and notify the client, thereby increasing the degree of control freedom of the server 10.

[0119] (5) Unlike segment push, MPD push allows, for example, all initialization segments to be sent, which may eliminate the need for the server 10 or client 20 to select one segment from multiple corresponding segments (e.g., segments with different bit rates). In this way, when the push strategies selectable in MPD push differ from those selectable in segment push, an "MPD push Directive" for specifying the push strategy in an MPD request and a "Segment push Directive" for specifying the push strategy in a segment request may be specified separately. Furthermore, the same format of push directives may be used for MPD requests and segment requests, but the parameters available in the MPD request may be restricted. For example, the parameters available in the MPD request may be restricted by prohibiting the use of "automatic."

[0120] (6) The push directive in the MPD request MAY specify the push strategy for the media segments.

[0121] For example, the MPD request may specify the push strategy for MPD push and the push strategy for segments separately.

[0122] Also, for example, when a push strategy for a media segment is specified in an MPD request, a push strategy (including a push number) for the MPD push corresponding to the push strategy for the specified segment may be automatically selected and generated.

[0123] Also, for example, when a push strategy for MPD push is specified in an MPD request, a push strategy for a segment (including a push number) corresponding to the push strategy for the specified MPD push may be automatically selected or generated.

[0124] [4. Supplement: Client and Server] 10 and 11, a client and a server that can specify automatic in the push directive are described. Below, an example of the configuration of a client as a receiving device that receives streaming data conforming to the MPEG-DASH standard and a server as a transmitting device that transmits the streaming data when automatic is not used in the push directive mentioned in the description of the above modification is described.

[0125] FIG. 12 is a diagram illustrating another example of the configuration of a communication system.

[0126] As explained in FIG. 10, the server 10A and the client 20A each have a processor, a storage, and a communication device including a transceiver.

[0127] The communication system 1A is configured by a server 10A and a client 20A that are communicatively connected to each other via a communication network (not shown).

[0128] Server 10A includes a receiving unit 101 and a transmitting unit 102. Each of receiving unit 101 and transmitting unit 102 is realized by, for example, a microcomputer, a processor, or a dedicated circuit. Although not shown in Fig. 12, server 10A may also include a selecting unit and a processing unit, similar to server 10 in Fig. 10.

[0129] The server 10A is equipped with (1) Sending MPD (2) Sending a segment (3) Interpreting the received DASH command and sending the DASH command to client 20A The functions may be implemented by the same server, or multiple servers may each implement at least one of the functions, and the multiple servers may provide the above functions to client 20A as an integrated operation.

[0130] The client 20A includes a receiving unit 201 and a transmitting unit 202. The receiving unit 202 and the transmitting unit 202 are each realized by, for example, a microcomputer, a processor, or a dedicated circuit. Although not shown in Fig. 12, the client 20A may include a DASH access unit, a decryption unit, and an application unit, similar to the client 20 in Fig. 10.

[0131] The operations performed by each component of the server 10A and the client 20A will be described in the explanations of the transmission method and the reception method, respectively.

[0132] An example of a transmission method and a reception method implemented by the server 10A and the client 20A will be described with reference to FIG.

[0133] FIG. 13 is a sequence diagram for explaining the operation of the communication system, including the transmission method by the server and the reception method by the client.

[0134] The operation (reception method) of client 20A will be described.

[0135] The transmitting unit 202 of the client 20A transmits an MPD request specifying a required MPD together with one or more push directives to the server (S201). In addition to the MPD specified in the MPD request, the MPD request transmitted by the client 20A also includes a push directive requesting that an initialization segment referenced by the MPD be transmitted by push.

[0136] The receiving unit 201 of the client 20A receives the MPD specified in the MPD request and the initialization segment sent by push.

[0137] Then, the transmitting unit 202 of the client 20A transmits a segment request specifying the segment n together with one or more push directives (S202).

[0138] The operation (transmission method) of the server 10A will be described.

[0139] The receiving unit 101 of the server 10A receives from the client 20A the MPD request that specifies an MPD together with one or more push directives, which was sent in step S201.

[0140] The transmitting unit 102 of the server 10A transmits to the client 20A an initialization segment in addition to the MPD specified in the MPD request received by the receiving unit 101 (S101).

[0141] The receiving unit 101 of the server 10A receives the one or more push directives and the segment request specifying the segment n, which have been sent in step S202.

[0142] The transmitting unit 102 of the server 10A transmits the segment n specified in the segment request to the client 20A (S102).

[0143] Similarly, the transmitting unit 102 of the server 10A pushes the segments from segment n+1 onwards to the client 20A (S103).

[0144] In this way, the client 20A transmits an MPD request to the server 10A together with a push directive that indicates a request for an initialization segment, which reduces the processing step by one step compared to the conventional case in which the MPD request and the initialization segment request are transmitted separately, in which an MPD request is transmitted, an MPD is received, and then a segment request specifying an initialization segment is transmitted to receive the initialization segment, thereby effectively reducing the amount of processing.

[0145] In each of the above embodiments, each component may be configured with dedicated hardware, or may be realized by executing a software program suitable for each component. Each component may be realized by a program execution unit such as a CPU or processor reading and executing a software program recorded on a recording medium such as a hard disk or semiconductor memory. Here, the software that realizes the receiving method and transmitting method of each of the above embodiments is a program such as the following.

[0146] That is, this program causes a computer to execute a receiving method in a client that receives streaming data conforming to the MPEG-DASH standard, in which an MPD request or a segment request is sent to a server, an MPD specified in the MPD request and a segment specified in the segment request are received, the MPD request includes information requesting that an initialization segment be sent by push, and the receiving process receives the initialization segment sent by push.

[0147] This program also causes a computer to execute a transmission method in a server that transmits streaming data conforming to the MPEG-DASH standard, which receives an MPD request or a segment request from a client, and pushes an MPD specified in the received MPD request and a segment specified in the received segment request to the client, wherein the MPD request includes information requesting that an initialization segment be sent by push, and in the sending, the method sends the initialization segment by push.

[0148] The client, server, receiving method, and transmitting method according to one or more aspects of the present invention have been described above based on the embodiments, but the present invention is not limited to these embodiments. As long as they do not deviate from the spirit of the present invention, various modifications that a person skilled in the art can make to these embodiments, or configurations constructed by combining components of different embodiments, may also be included within the scope of one or more aspects of the present invention. [Industrial Applicability]

[0149] The present disclosure is applicable to devices or equipment that transmit or receive streaming data according to the MPEG-DASH standard. [Explanation of symbols]

[0150] 1. Communication Systems 10, 10A Server 11 Selection section 12 Transmitter 20, 20A Client 30 Communication Network 101 Receiving unit 102 Transmitter 201 Receiving unit 202 Transmission Unit

Claims

1. 1. A client for receiving streaming data according to the MPEG-DASH (Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP) standard, comprising: a sending unit that sends a Media Presentation Description (MPD) request to a server; A receiving unit that receives an MPD (Media Presentation Description), the MPD request includes a push directive specifying whether to send an initialization segment from the server by push; When the push directive indicates that the initialization segment is to be sent from the server by push, the push directive further includes information indicating whether the media segment is to be sent from the server by push. client.

2. A server that transmits streaming data in accordance with the MPEG-DASH (Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP) standard, comprising: a receiving unit that receives an MPD (Media Presentation Description) request from a client; a transmitting unit that transmits an MPD (Media Presentation Description), the MPD request includes a push directive specifying whether to send an initialization segment from the server by push; When the push directive indicates that the initialization segment is to be sent from the server by push, the push directive further includes information indicating whether the media segment is to be sent from the server by push. server.

3. 1. A receiving method for use in a client receiving streaming data according to the MPEG-DASH (Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP) standard, the method comprising: Sending a Media Presentation Description (MPD) request to a server; Receive a Media Presentation Description (MPD); the MPD request includes a push directive specifying whether to send an initialization segment from the server by push; When the push directive indicates that the initialization segment is to be sent from the server by push, the push directive further includes information indicating whether the media segment is to be sent from the server by push. Receiving method.

4. 1. A transmission method for use in a server transmitting streaming data according to the MPEG-DASH (Moving Picture Experts Group - Dynamic Adaptive Streaming over HTTP) standard, comprising: receiving a Media Presentation Description (MPD) request from a client; Sending a Media Presentation Description (MPD), the MPD request includes a push directive specifying whether to send an initialization segment from the server by push; When the push directive indicates that the initialization segment is to be sent from the server by push, the push directive further includes information indicating whether the media segment is to be sent from the server by push. Sending method.

Images