Patent Grant
12170812
The present disclosure relates to clients which receive streaming of multimedia content on networks having varying bandwidths using a MPEG-DASH format, servers which transmit the streaming, client reception methods, and server transmission methods.
NPL 1 discloses Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP (MPEG-DASH) or standard specification of adaptive streaming techniques according to Hypertext Transfer Protocol (HTTP). A DASH server provides content data corresponding to a plurality of representations having different image qualities and different bit rates, as a file corresponding to time-divided units, i.e., segments, or subsegments of divided segments. The segments or subsegments are units divided in unit of several seconds. The file corresponding to the segments or subsegments is an MP4 file containing pictures or sounds. The file corresponding to the segments or subsegments can be obtained, for example, by specifying an URL address according to HTTP. A DASH client can request a file corresponding to the segments or subsegments having quality (so-called representation) suitable for the current network state and the current throughput, based on a manifest file (so-called Media Presentation Description (MPD)) where the configuration of the entire content or part thereof and the specification of the start segment are described.
NPL 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)
Unfortunately, the techniques disclosed in NPL 1 cannot reduce the amount of processing performed in the client and the server.
The client according to one aspect of the present disclosure is a client which receives streaming data according to Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP (MPEG-DASH) standard. The client includes a transmitter which transmits a Media Presentation Description (MPD) request or a segment request to a server; and a receiver which receives an MPD specified in the MPD request and a segment specified in the segment request. The MPD request contains information requesting transmission of an initialization segment by a push, and the receiver receives the initialization segment transmitted by the push.
The server according to one aspect of the present disclosure is a server which transmits streaming data according to MPEG-DASH standard. The server includes a receiver which receives an MPD request or a segment request from a client; and a transmitter which transmits, by a push, an MPD specified in the MPD request and a segment specified in the segment request to the client, the MPD request and the segment request being received by the receiver. The MPD request contains information requesting transmission of an initialization segment by a push, and the transmitter transmits the initialization segment by the push.
The overall or specific aspects may be implemented by a system, a method, an integrated circuit, a computer program, or a recording medium such as a computer-readable CD-ROM, or may be implemented by any combination of systems, methods, integrated circuits, computer programs, and recording media.
According to these aspects, the amount of processing performed in the client and the server can be reduced.
The client according to one aspect of the present disclosure is a client which receives streaming data according to Moving Picture Experts Group-Dynamic Adaptive Streaming over HTTP (MPEG-DASH) standard. The client includes a transmitter which transmits a Media Presentation Description (MPD) request or a segment request to a server, and a receiver which receives an MPD specified in the MPD request and a segment specified in the segment request. The MPD request contains information requesting transmission of an initialization segment by a push, and the receiver receives the initialization segment transmitted by the push.
The server according to one aspect of the present disclosure is a server which transmits streaming data according to the MPEG-DASH standard. The sever includes a receiver which receives an MPD request or a segment request from a client, and a transmitter which transmits, by a push, an MPD specified in the MPD request and a segment specified in the segment request to the client, the MPD request and the segment request having been received by the receiver. The MPD request includes information requesting transmission of an initialization segment by the push, and the transmitter transmits the initialization segment by the push.
The overall or specific aspects may be implemented by a system, a method, an integrated circuit, a computer program, or a recording medium such as a computer-readable CD-ROM, or may be implemented by any combination of systems, methods, integrated circuits, computer programs, and recording media.
The client, server, reception method, and transmission method according to one aspect of the present disclosure will now be specifically described below with reference to the drawings.
The embodiments to be described below only show specific examples of the present disclosure. Numeral values, shapes, materials, components, arrangements, positions, and connection forms of the components, steps, order of the steps, and the like shown in the embodiments below are only examples, and will not limit the present disclosure. Among the components in the embodiments below, components not described in independent claims expressing the highest concept will be described as arbitrary components.
MPEG-DASH specifies an URL-addressable format for ISO-BMFF formatted media segments, and a manifest file is called Media Presentation Description (MPD). DASH was originally conceived to deal with transport of media over networks (for example, unmanaged Internet connections (OTT)) with variable throughput. The MPEG-DASH system was based on a client-centric technical idea, which was to leverage already available technology. Accordingly, the existing HTTP-webserver and a DASH-enabled client can realize a dynamic streaming session.
The initial concept was expanded in scope by MPEG. New concepts were introduced into Server-And-Network-Assisted-DASH (SAND), Content-Aggregation-and-Playback Control (CAPCO), and Full-Duplex-HTTP (FDH), for example. The latter, FDH, leverages the recently ratified HTTP/2 standard, and enables the server to push data onto a client, the data having not been requested by the client itself. A benefit of defined related push directives is mainly a reduction in overhead. For every pushed segment, the corresponding HTTP request from the client can be dispensed with, thereby saving the bandwidth.
The FDH part of DASH is currently being specified in ISO/IEC 23009 Part 6, and to this date includes four strategies for pushing content from the server to the client. These strategies are called “push directives”, each of which is composed of a push type and an accompanying push parameter. The push type includes push-next, push-none, push-template, and push-time, for example.
Push-next and push parameter K indicate that the next K segments are considered for push using the segment requested as the initial index.
Push-none indicates that no push occurs. In this case, no parameter is used.
Push-template indicates that some segments described by an URI template are considered for push. The push parameter is referred to as URI template.
Push-time indicates that beginning with the requested segment, segments are considered for push until the specified segment time exceeds time T. Time T is signaled as a push parameter.
Push-next and push-time indicate that the server can select to indefinitely push when their push parameters are set at 0. Although this is already contained in the gist of the present disclosure, it does not cause the server to perform the control beyond the selection of the representation or to act on bit rate fluctuations.
The client first requests an MPD with a push directive, and then requests media segments. After receiving the requested MPD, the client starts requesting media segments from the server using the respective DASH segment URLs and push directives. The server then replies with the requested media segments. The operation is followed by the push cycles as indicated by the push strategy. After receiving a minimum amount of data, the client starts playing back the media. The process repeats until the media streaming session is completed.
To prepare a client for the next media segments, the server may transmit the MPD, and also preliminarily transmit an initialization segment by a push at the same time. The initialization segment is information containing the header information of a segment.
A benefit of the push directive is a reduction in overhead. All of the push directives still require the client to request new segments either when the number of the requested segments is provided (push-next) or when the segment time is exceeded (push-time). A new push directive according to one aspect of the present disclosure will now be described, which enables the server to automatically select and push the segments over the course of the total media duration. Thereby, the overhead caused by the segment requests is reduced to a minimum. The new push directive enables the server to determine the application of unicast and/or multicast mode for all or part of the connections to the client. The server may automatically determine only the parameters related to the network bandwidth between the server and a receiving terminal, such as the bit rate and the resolution of the segment.
Part of the present disclosure is a method for estimating a throughput experienced by a client in a server, based on acknowledgement numbers contained in the acknowledgement packets transmitted from the client to the server during a TCP/IP connection. These acknowledgement packets are an integral part of the TCP layer; therefore, no additional overhead is created or necessary to use the method. This throughput estimation method with the push directive “automatic” reduces the total overhead to a minimum while retaining the DASH philosophy of switching representations based on the current throughput.
DASH is based on the ubiquitous HTTP-protocol. HTTP in turns relies on the underlying TCP/IP layer to transport requests, responses, and data. The TCP/IP layer splits a data stream into packets, and ensures their reliable transport. To this process, the HTTP layer is completely oblivious. The packetization process and the reassembly process are enabled by two fields contained in the TCP header, i.e., a sequence number and an acknowledgement number.
The sequence number and the acknowledgement number are generated at both end-points during the initialization phase of the TCP connection (three-way handshake). Both numbers are used for the packetization and the packet reassembly process. These numbers are initially two random 32-bit integers, and are exchanged between the server and the client.
The sequence number is increased by the server by the number of bytes which are currently being transmitted. Thereby, the relative sequence number between packets serves as a pointer to the starting position of the current packet in the total data byte stream.
More importantly, the acknowledgement number is transmitted from the client to the server to notify the number of successfully received bytes of the server. Accordingly, the server having an external timer measuring the arrival time of the acknowledgement packets can readily estimate the throughput currently experienced by the client.
As already described above, the system according to the present disclosure can reduce the overhead because metric messages and segment requests are unnecessary. The system according to the present disclosure can also centralize control over switching between the unicast mode and the multicast mode. The system according to the present disclosure also enables a server to centrally manage its resources. In other words, while monitoring the throughput, the server anticipates a throughput bottleneck, and smoothly reduces the transmitted bit rate, thereby avoiding unintended highly dynamic changes of representations. HTTP/2-enabled clients do not need to track traffic diagnostics. The elimination of tracking of the traffic diagnostics can result in power saving and cost saving at the same time.
Furthermore, typically, the server provides data to multiple clients. Using a mechanism of the push directive “automatic” and the throughput estimation, the server can select to switch from the unicast mode to a more effective multicast mode when multiple clients request the same content at the same time (e.g., in conjunction with live TV transmission). Depending on the channel condition, for example, the unicast mode or the multicast mode can be assigned to all or part of the multiple clients.
In particular, in the cases of communication within specific areas such as event sites, it is possible to preliminarily estimate the rate and the segments themselves to be highly possibly selected, based on another information, such as the number of visitors and information unique to the communication terminals within the areas. In such cases, the determination and selection in the server are simplified, enabling ideal distribution with a small amount of delay.
New DASH push directive “automatic”
DASH push parameter/strategy indicators: The client needs to announce its capabilities before the server provides media segments indefinitely.
Throughput estimation method based on the acknowledgement number of TCP
Combination of the existing DASH push directives (push-next, push-time, and push-template) with the claimed new DASH push directive “automatic”
Example: The server automatically pushes the next K segments, and then receives a new push request for automatically pushing the next L segments.
Automatic and dynamic selection (based on the values measured in the throughput measurement) of the unicast mode or the multicast mode for all or part of the clients requesting the same content at the same time
A new DASH push directive enables a server to select and push data to a client as seen fit by the server. This push directive will now be referred to as push directive “automatic”.
A DASH push parameter which accompanies the push directive will be described. The server is notified about the capabilities of the clients. The client is, for example, an apparatus which can process available media decoders, reproducible image resolutions, and frame-rates. In an embodiment, as shown in Tables 1-1 and 1-2, the push parameter may be represented by a composite data type having a field extracted from a receiver capability table (RCT). The present embodiment should not be construed as limitative. For example, the present embodiment should not be limited by any format of the receiver capability table having a function identical with the communication with the server about the capabilities of the client.
The parameter “modelndicator” guides the server during selection of the actual parameter. Its suitable mode is maximum quality, minimum quality, and a low dynamic mode in switching of the representations, for example. These are shown in Table 2. Other modes are also possible. It should be understood that any other modes can be used in the present disclosure.
Another combination of DASH push directives contains a push directive “automatic” or “push-automatic-rate”. In one embodiment of the present disclosure, a suitable push directive combined with the push directive “automatic” may be push-next, push-time, and push-template. It should be understood that any other combination can be used.
For example, by specifying, using push-next, such that the next N segments are received, and by specifying push-automatic-rate, the server automatically selects the bit rate of the N segments. Alternatively, push-automatic-rate may be effective until it is invalidated by a push directive separately specified, i.e., push-channel-automatic-rate. At this time, unless push-channel-automatic-rate is issued, push-automatic-rate is still effective to the segments transmitted after the transmission of the N segments.
When the server receives push-none during the transmission of the segments even after push-full-automatic has already been specified, the server stops the transmission of the segments immediately or after transmitting the final data of the segment being currently transmitted.
The estimation method and the estimation apparatus estimate the throughput of the client based on the acknowledgement number in the TCP header transmitted from the client to the server, by measuring the arrival time of the acknowledgement packets with an external timer.
A relative acknowledgement number as the difference between the current acknowledgement number and the initial acknowledgement number is denoted. Similarly, a relative time as the difference between the arrival time of the current acknowledgement packets and the arrival time of the acknowledgement packets is denoted. A first method for estimating throughput is to calculate the quotient of the relative acknowledgement number and the relative time.
The difference in acknowledgement number is denoted as a difference between the last acknowledgement packet and the penultimate acknowledgement packet. Similarly, the difference in arrival time is denoted as a difference between the arrival time of the last acknowledgement packet and that of the penultimate acknowledgement packet. A second method for estimating throughput is to calculate the average of the consecutive quotients of differential acknowledgement numbers and differential times by a suitable digital filter.
Automatic and dynamic selection is performed (in the extreme case segment-by-segment). In the automatic and dynamic selection, based on the aforementioned throughput measurement methods (representing the quality of the connection to each single client), the unicast mode or multicast mode is selected for all or part of the clients requesting the same content at the same time.
DASH's philosophy builds on clients measuring throughput and requesting segments based on those measurements. Recently, HTTP/2 introduced a new push-feature with which the server can transmit data to a client unsolicited. In Part 6 of the DASH standard, MPEG wants to leverage this new HTTP/2 feature for DASH. Part 6 is called FDH. Although four push directives already exist (push-next, push-none, push-template, and push-time), these are still largely driven by the client.
As described in Embodiment 1, the throughput to the client can be measured on the server side. In other words, the server can manage the client by using this new push directive “automatic”.
Selection of segments is partially or completely controlled by the server based on a push directive. In other words, the numbers or duration to transmit the segments and their bit rate are determined by the server.
As illustrated in (a) of
Server 10 is an HTTP/2 server. Server 10 runs dummynet for custom traffic shaping. Server 10 runs software for analyzing the situations and protocols of packets when obtained (such as Wireshark (registered trademark)) to capture all the packets into pcap-file (further processed in Python having the scapy package). Here, pcap (packet capture) indicates an application programming interface (API) for a packet sniffer (packet analyzer) in the field of the management of computer networks. In Unix (registered trademark) system, pcap is packaged as libpcap.
Server 10 transmits a 1-MB file with Pseudo-Random Bit Sequence (PRBS). Dummynet is used for traffic shaping, in particular, for controlling the transmission bandwidth. Wireshark (registered trademark) captures and saves TCP/IP traffic. Python is used for data aggregation and evaluation based on the Wireshark (registered trademark) capture.
Server 10 may be implemented by a processor and a memory containing predetermined programs, or may be implemented by a dedicated circuit. Server 10 includes a computer.
Client 20 may be implemented by a TV set, a player, a recorder, a smartphone, a tablet computer, or a PC.
As illustrated in (b) of
Dummynet run by server 10 will now be described.
Dummynet is a network emulation tool. Dummynet simulates queue, bandwidth limitations, delays, and packet loss, and implements various scheduling algorithms. Dummynet runs within any operating system, and works by intercepting selected traffic on its way through the network stack. Dummynet passes packets to pipes which implement a set of queues, a scheduler, a link, and all of configurable features (bandwidth, delay, loss rate, queue size, scheduling policy, etc.). The traffic is selected using the ipfw firewall, which is the main user interface for dummynet. In “Hello world”, a pipe is created on all outgoing TCP traffic, and its bandwidth is set to 500 kByte/s. For example, a packet-filtering firewall ipfw (ipfirewall) adds one pipe to the outside of proto tcp. For example, one ipfw pipe has a bandwidth set to 500 kByte/s.
The TCP header will now be described.
As illustrated in
The sequence number is a pointer to the position of the current payload in the overall transmitted data byte stream. The sequence number is used to sort the received packets into the same order as they were transmitted.
The acknowledgement number indicates that a packet having a specific sequence number has been correctly received. The acknowledgement number includes the next expected sequence number.
From the acknowledgement number (transmitted from the client to the server), server 10 can derive the number of successfully received bytes. Further using the timing of ACK packets, the current throughput can be estimated.
During the three-way handshake, both end-points (i.e., server 10 and client 20) generate random 32-bit integers for their corresponding sequence numbers, and exchange them. As illustrated in the excerpt from the Wireshark (registered trademark) session (
As illustrated in
As described above, the throughput measurement on the server side is largely executable.
Thereby, server 10 can mainly manage its resources. Server 10 can more significantly avoid a fluctuation in representations on client 20 side. Client 20 may be dumb, and does not need to track traffic diagnostics. Overhead can be reduced by saving metric/diagnostic messages.
For example, as shown in Table 3, the push directives including push-automatic-rate and push-full-automatic may be used.
Communication system 1 includes server 10 and client 20. Server 10 is connected to client 20 via communication network 30 to communicate with each other.
Server 10 and client 20 each include a processor, a storage, and a communicator including a transmitter and a receiver.
The processors included in server 10 and client 20 each execute processing illustrated in a sequence diagram (see
Server 10 includes selector 11 and transmitter 12.
Details of server 10 and client 20 will be described in the description of the operation of communication system 1.
Client 20 first transmits an MPD request indicating an MPD request to server 10 (S11).
In the next step, server 10 receives the MPD request transmitted from client 20, and transmitter 12 in server 10 transmits an MPD corresponding to the received MPD request (corresponding MPD) to client 20 (S12). As described in Embodiment 1, in S12, server 10 may transmit part or all of initialization segments to client 20 by a push, in addition to the MPD corresponding to the received MPD request. Hereinafter, the transmission by the push, in response to the MPD request, of initialization segments or other files such as updated new MPDs in addition to the MPD specified in the MPD request is also referred to as MPD push.
The operation of client 20 when server 10 does not transmit the initialization segments by the push is similar to the communication with a server which does not deal with the push transmission. In other words, among the initialization segments described in the received MPD, client 20 transmits the segment requests specifying necessary initialization segments. Server 10 transmits the initialization segments specified in the received segment requests to client 20.
Client 20 receives the corresponding MPD with one or more push directives, transmits the segment request indicating the request of segment #n to server 10, and measures Ack (S13).
Server 10 receives the segment request for segment #n having a specified push directive. Selector 11 in server 10 determines the fixed rate or the adaptive rate based on the push directive of the received segment, and selects the segment to be transmitted, based on the received segment request for segment #n (S14).
Server 10 transmits segment n specified in the segment request, and sequentially transmits the segments after segment n+1 by a push, the segments being selected by selector 11 (S15 and S16). Hereinafter, the transmission by the push, in response to the segment request, of the segment other than the segment specified in the segment request is also referred to as segment push.
Segment n may be transmitted before the determination of the fixed rate or the adaptive rate. Selector 11 selects the segments after segment n based on the throughput obtained in the measurement using Ack described above. In the case where the push directive specified in the segment request for segment #n is a push directive requiring a push transmission other than push-automatic-rate or push-full-automatic, selector 11 selects the segments after segment n+1 according to the push directive specified in the segment request for segment #n without measuring the throughput.
In
Although
The throughput measurement module illustrated in
A detailed configuration of client 20 is not disclosed in
A following modification is applicable to the embodiments described above.
Although an example has been described in the embodiments above by way of an example in which push-automatic-rate or push-full-automatic is specified as a new push strategy which can be specified as “pushType” parallel to push-next or push-none, push-automatic-rate or push-full-automatic may be specified in any other format.
For example, push-automatic-rate or push-full-automatic may be defined as a parameter parallel to (written down along with) “K:Number”, which is a parameter (PUSH_PARAMS) specified when push-next is selected in PushType. In this case, multiple parameters are written down along with PUSH_PARAMS in push directive or PushAck. Similarly, the specification of whether it is “automatic” or not or the specification of the mode of “automatic” is also enabled in PUSH_PARAMS when push-template or push type is selected as PushType.
Alternatively, push-automatic-rate or push-full-automatic may be defined, for example, as a parameter parallel to (written down along with) PUSH_TYPE in the push directive. In this case, separated from PUSH_TYPE, a region specifying whether it is “automatic” or specifying the mode of “automatic” is disposed in the format of the push directive.
A following modification is applicable to the embodiments described above. It should be noted that the following configuration may be used not in combination with the above-described embodiments (for example, the specification of “automatic” in segment push). Such a treatment of “automatic” as an independent attribute enables the specification of whether server 10 can automatically determine not only the number and duration of segments transmitted from server 10 and their bit rate but also other parameters.
For example, in the case where MPD push is specified using a push directive (or another Data Type) in an MPD request, any one of the following configurations or any combination thereof may be used.
(1)
When execution of MPD push is specified using a push directive in an MPD request, server 10 may transmit a new MPD by a push in response to the updated MPD.
(2)
When the execution of MPD push is specified using the push directive in an MPD request, server 10 may transmit, by a push, metadata associated with the decode or display of the media data in addition to the specified MPD. Here, one example of the metadata is the header information (i.e., initialization segment) of MP4 when the media data is MP4. The metadata stores access information to coded data of sounds and/or pictures and PTS/DTS, for example. In other words, server 10 may transmit initialization segments with MPDs to client 20. In this case, transmission or non-transmission of the metadata by the push may be specified by the push directive in the MPD request.
(3)
The duration or number of MPDs (or metadata) transmitted by a push by server 10 may be specified by the push type, for example. In other words, server 10 may transmit, by the push, the duration or number of MPDs (and metadata) specified by the push type.
(4)
In the case where the MPD push is specified, server 10 may perform the preliminarily defined operation (default operation), and the push directive in the MPD request may only specify whether the MPD push is executed or not. It should be noted that stop (not executing) of the MPD push may be specified from client 20 or server 10.
Needless to say, in the case where client 20 transmits an MPD request specifying a push directive requesting MPD push and server 10 is specified not to execute MPD push, the subsequent operation of client 20 is similar to the operation of the client not corresponding to the MPD push. In other words, client 20 obtains the initialization segments needed to play back desired media by transmitting a segment request to server 10.
By allowing the specification of not executing MPD push by server 10 as described above, non-execution of push transmission of initialization segments by server 10 can be determined, and client 20 requiring the push transmission of the initialization segments can be notified about such a determination. Such a configuration enhances the freedom in control in server 10.
(5)
Unlike the case of the segment push, for example, all of the initialization segments can be transmitted in the MPD push. For this reason, there are possibilities that server 10 or client 20 does not need to select any one of corresponding segments (such as segments having different bit rates). In such a case where the push strategy which can be selected in the MPD push is different from the push strategy which can be selected in the segment push, “MPD push Directive” for specifying the push strategy in the MPD request may be defined separately from “Segment push Directive” for specifying the push strategy in the segment request. Alternatively, the push directives in the same format may be used in the MPD request and the segment request, and the parameters which can be used in the MPD request may be limited. For example, the parameters which can be used in the MPD request are limited by prohibiting the use of automatic.
(6)
The push strategy of the media segment may be specified in the push directive of an MPD request.
For example, the push strategy of the MPD push and the push strategy of the segment may be separately specified in the MPD request.
For example, when the push strategy of the media segment is specified in the MPD request, the push strategy (including push-none) of the MPD push corresponding to the push strategy of the specified segment may be automatically selected and generated.
For example, when the push strategy of the MPD push is specified in the MPD request, the push strategy (including push-none) of the segment corresponding to the push strategy of the specified MPD push may be automatically selected or generated.
The client and the server which enable the specification of automatic with the push directive have been described with reference to
Server 10A and client 20A include a processor, a storage, and a communicator including a transmitter and a receiver as described in
Communication system 1A is configured with server 10A and client 20A connected to communicate with each other via a communication network not illustrated.
Server 10A includes receiver 101 and transmitter 102. Receiver 101 and transmitter 102 are each implemented with a microcomputer, a processor, or a dedicated circuit, for example. Although not illustrated in
The following functions of server 10A:
(1) transmission of MPDs
(2) transmission of the segment, and
(3) interpretation of the received DASH commands and transmission of DASH commands to client 20A may be implemented in an identical server. Alternatively, each of multiple servers may implement at least one of the functions to provide these functions to client 20A as an integrated operation by the multiple servers.
Client 20A includes receiver 201 and transmitter 202. Receiver 202 and transmitter 202 are each implemented with a microcomputer, a processor, or a dedicated circuit, for example. Although not illustrated in
The operations executed by the components of server 10A and those of client 20A will be described in the description of a transmission method and a reception method.
One example of the transmission method and the reception method executed by server 10A and client 20A will be described with reference to
The operation (reception method) of client 20A will be described.
Transmitter 202 in client 20A transmits an MPD request specifying a necessary MPD to the server with one or more push directives (S201). Besides the MPD specified in the MPD request, a push directive requesting the transmission by a push of the initialization segment, which is referred by the MPD, is set in the MPD request transmitted by client 20A.
Receiver 201 in client 20A receives the MPD specified in the MPD request and the initialization segment transmitted by the push.
Transmitter 202 in client 20A then transmits a segment request specifying segment n with one or more push directives (S202).
The operation (transmission method) of server 10A will be described.
From client 20A, receiver 101 in server 10A receives the MPD request specifying the MPD with one or more push directives, the MPD request having been transmitted in Step S201.
Transmitter 102 in server 10A transmits the MPD specified in the MPD request, which is received by receiver 101, and the initialization segment to client 20A (S101).
Receiver 101 in server 10A receives the one or more push directives and the segment request specifying segment n, which are transmitted in Step S202.
Transmitter 102 in server 10A transmits segment n specified in the segment request to client 20A (S102).
Similarly, transmitter 102 in server 10A transmits the segments after segment n+1 to client 20A by a push (S103).
Because client 20A transmits the MPD request with the push directive indicating the initialization segment request to server 10A as described above, one step of the processing can be reduced compared to the case of a conventional method of separately transmitting an MPD request and an initialization segment request in which after the transmission of the MPD request and then the reception of the MPD, a segment request specifying an initialization segment is transmitted, and then the initialization segment is received. For this reason, the amount of processing can be effectively reduced.
In each of the embodiments above, the components may each be configured with dedicated hardware, or may be implemented by executing software programs suitable for the components. The components may each be implemented by a program executor (such as a CPU or a processor) reading and executing the software programs recorded in a recording medium (such as a hard disk or a semiconductor memory). Here, the reception method and the transmission method in these embodiments are implemented with the following software, for example.
That is, the program causes a computer to execute a reception method in a client which receives streaming data according to the MPEG-DASH standard. In the reception method, the client transmits an MPD request or a segment request to a server, and receives an MPD specified in the MPD request and a segment specified in the segment request. The MPD request contains information requesting transmission of an initialization segment by a push. In the reception, the client receives the initialization segment transmitted by the push.
The program causes a computer to execute a transmission method in a server which transmits streaming data according to the MPEG-DASH standard. In the transmission method, the server receives an MPD request or a segment request from a client, and transmits an MPD specified in the received MPD request and a segment specified in the received segment request to the client by a push. The MPD request contains information requesting transmission of an initialization segment by the push. In the transmission, the server transmits the initialization segment by the push.
Although the clients, servers, reception methods, and transmission methods according to one or more aspects of the present disclosure have been described above based on the embodiments, the present disclosure will not be limited by these embodiments. A variety of modifications conceived by persons skilled in the art and applied to the present embodiments without departing the gist of the present disclosure, and embodiments including combinations of components according to different embodiments may also be included within the scope of one or more aspects of the present disclosure.
The present disclosure is applicable to apparatuses or equipment in transmission or reception of streaming data according to the MPEG-DASH standard.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2016-228396 | Nov 2016 | JP | national |
| Number | Name | Date | Kind |
|---|---|---|---|
| 10951944 | Klenner | Mar 2021 | B2 |
| 11336951 | Klenner | May 2022 | B2 |
| 11678009 | Klenner | Jun 2023 | B2 |
| 20160028646 | Fablet | Jan 2016 | A1 |
| 20160182600 | Swaminathan | Jun 2016 | A1 |
| 20160198012 | Fablet et al. | Jul 2016 | A1 |
| 20170006081 | Grandl | Jan 2017 | A1 |
| 20170238040 | Huysegems | Aug 2017 | A1 |
| Number | Date | Country |
|---|---|---|
| 2015004276 | Jan 2015 | WO |
| Entry |
|---|
| International Search Report (ISR) dated Apr. 25, 2017 in International (PCT) Application No. PCT/JP2017/003094. |
| Information technology—Dynamic adaptive streaming over HTTP (DASH)—Part 1: Media presentation description and segment formats, International Standard, ISO/IEC 23009-1:2014(E), May 15, 2014. |
| Franck Denoual (Canon) et al: “[CE-FDH] Use of HTTP2 Push feature for DASH improvement”, 109. MPEG Meeting; Jul. 7, 2014-Jul. 11, 2014; Sapporo; (Motion Pic—Expert Group or ISO/IEC JTC1/SC29/WG11), No. m33665 Jun. 13, 2014 (Jun. 13, 2014), XP030062038. |
| Franck Denoual (Canon) et al: “[CE-FDH] Benefits of HTTP/2 Pus feature for DASH”, 110. MPEG Meeting; Oct. 20, 2014-Oct. 24, 2014; Strasbourg; (Motion Picture Expert Group or ISO/IEC JTC1/SC29/WG 11), No. m34632 Sep. 19, 2014 (Sep. 19, 2014), XP030063004. |
| Froejdh P et al.: “Adaptive Streaming within the 3GPP Packet Switched Streaming Service”, IEEE Network, IEEE Service Center, New York, NY, US, vol. 20, No. 2, Mar. 1, 2006 (Mar. 1, 2006), pp. 34-40, XP001546775. |
| “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs (Release 11)”, 3GPP Standard; 26234-B40, 3rd Generation Partnership Project (3GPP), Mobile Competence Centre; 650, Route Des Lucioles F-06921 Sophia-Antipolis Cedex ; France, Jun. 12, 2014 (Jun. 12, 2014), XP050915704. |
| ISO MPEG et al: “ILS from ISO MPEG on ISO/IEC Cd 23009-6 DASH with Server Push and Web Sockets—29n157642”, DVB, Digital Video Broadcasting, C/O EBU—17A Ancienne Route—CH-128 Grand Saconnex, Geneva—Switzerland, Jun. 15, 2016 (Jun. 15, 2016), XP017852134. |
| Extended European Search Report dated Jun. 22, 2022 in European Patent Application No. 22155822.4. |
| Communication Pursuant to Article 94(3) EPC dated Jun. 17, 2022 in European Patent Application No. 17747338.6. |
| Communication pursuant to Article 94(3) EPC dated Mar. 22, 2023 in European Patent Application No. 17 747 338.6. |
| Communication pursuant to Article 94(3) EPC dated Mar. 23, 2023 in European Patent Application No. 22 155 822.4. |
| Swaminathan, Viswanathan et al., Working Draft for 23009-6: DASH over Full Duplex HTTP-based Protocols (FDH), (Motion Picture Expert Group or ISO/IEC JTC1/SC29/WG11), No. n15220, Mar. 16, 2015, XP030021946. |
| Van Der Hooft, Jeroen et al., “HTTP/2-Based Adaptive Streaming of HEVC Video Over 4G/LTE Networks”, IEEE Communications Letters, vol. 20, No. 11, Nov. 1, 2016, pp. 2177-2180, XP011633685. |
| Huysegems, Rafael et al., “HTTP/2-Based Methods to Improve the Live Experience of Adaptive Streaming”, Multimedia, ACM, 2 Penn Plaza, Suite 701, New York, NY 10121-0701 USA, Oct. 13, 2015, pp. 541-550, XP058509690. |
| Result of consultation dated Jun. 18, 2024 in view of the upcoming Oral Proceedings for the European patent application No. 22155822.4. |
| Swaminathan et al., “Working Draft for 23009-6: DASH over Full Duplex HTTP-based Protocols (FDH),” ISO/IEC JTC1/SC29/WG11/N15532, International Organization for Standardization, Coding of Moving Pictures and Associated Audio, Jun. 2015, Warsaw, Poland, XP030022245, 29 pages. |
| Extended European Search Report issued Jul. 22, 2024 in European Patent Application No. 24177713.5. |
| Swaminanthan et al., “Draft International Standard for 23009-6: DASH with Server Push and WebSockets”, ISO/IEC JTC1/SC29/WG11/ W16232, Feb. 2016, XP030022905. |
| Number | Date | Country | |
|---|---|---|---|
| 20230269421 A1 | Aug 2023 | US |
| Number | Date | Country | |
|---|---|---|---|
| 62295790 | Feb 2016 | US | |
| 62289469 | Feb 2016 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17716212 | Apr 2022 | US |
| Child | 18138307 | US | |
| Parent | 17158151 | Jan 2021 | US |
| Child | 17716212 | US | |
| Parent | 16073553 | US | |
| Child | 17158151 | US |
