JP2018509679A - Improved client-driven push of resources with server devices - Google Patents

Abstract

The present invention relates to data transmission, eg data streaming, over an HTTP communication network. The method for transmitting data between the server and the client is at the server: receiving an HTTP request from the client to obtain the first data, the HTTP request enabling the identification of the first data on the server. Receiving, including one or more additional header fields including first data specific information and including instructions associated with pushing the second data; retrieving the first data and sending to the client; and Sending acknowledgment data representing the indication associated with pushing the second data to the client device. [Selection] 11a

Description

  The present invention relates to data transmission, eg, data streaming, over an HTTP (representing HyperText Transfer Protocol) communication network, and more precisely to client-driven push of resources by a server device.

  In communication over HTTP, such as DASH (Dynamic Adaptive Streaming over HTTP) media content streaming, a client device may require a large amount of data from the server device. In order to do so, the client device typically has a method (eg, “GET”) and possibly one or more additional headers (eg, its uniform resource identifier (URI) in the HTTP request). Send an HTTP request, each containing a request line consisting of a URI indicating the location and location of the requested data on the server device, along with a Range header that provides the byte range in the resource specified by .

  Server push features have been developed to allow server devices to voluntarily push data that has not yet been requested by a client device. This is a useful feature to reduce web resource loading time.

  The server push feature is HTTP / 2 (which allows several request / responses within a single existing connection to allow the server device to send unsolicited web resource representations to the client device. Is also introduced), ie, having several streams). Web resources, such as web pages, typically include links to other resources, and themselves may include links to other resources. In order to fully display a web page, typically all linked resources and sublinked resources must be retrieved by the client device. This increased discovery can lead to slow display of web pages, especially on high latency networks such as mobile networks.

  When receiving a request for a given web page, the server device can determine which other resources are required for the complete processing of the requested resource. By sending the requested resource and the linked resource simultaneously, the server device can reduce the loading time of the web page. Thus, using the push feature, the server device can send a representation of additional resources when requested for a given resource.

  Data push has also been proposed in connection with DASH, for example in an application published as US Pat.

  This publication seeks to improve data streaming to optimize the user experience, particularly in connection with DASH-based communications. The reason is that in conventional mechanisms, the client and server devices do not know if the promised data is sent and received when needed, and the client device does not know when and in what order the video segments are sent. It may be. Furthermore, the promised data pushed or announced by the server device may not meet the needs of the client device (this may evolve over time), thus resulting in wasted resources, especially at the server end. May lead. Therefore, Patent Document 1 proposes that a server device and a client device share a push policy.

  This sharing helps client devices know in advance what data is being pushed and then prepares to cancel such pushes to avoid wasting network bandwidth.

  However, the mechanism proposed in this publication is specifically for XML-based DASH “media presentation description” files (MPD) to determine what data or resources to push according to the push policy. The server device requires very complex knowledge about DASH so that the push policy can be applied.

  Note that MPD files describe the structure of media content in media segments. MPD files are exchanged between the server device and the client device, which allows the latter to control the delivery of media content, i.e. allows the latter to request each media segment individually. Give information.

International Publication No. 2015/004276

In this context, the present invention provides a method for transmitting data between a server device and a client device, the method being at the server device:
Receiving an HTTP request for obtaining first data from a client device, the HTTP request including first data identifying information enabling identification of the first data on the server device and pushing the second data; Receiving, including one or more additional header fields containing associated instructions;
Retrieving the first data and sending it to the client device;
Sending acknowledgment data representing instructions associated with pushing the second data to the client device; and using only one or more header fields and optionally further the first data identification information, the server device Determining second data identification information that enables identification of the second data above;
including.

  Thus, the method of the present invention allows client devices to adapt their behavior in view of the push policy applied by the server device.

In embodiments, the method further includes:
Sending a push commitment message to announce the push of the second data to the client device and / or pushing the second data to the client device.

  In embodiments, the acknowledgment data represents an instruction to push the second data.

  In some embodiments, the acknowledgment data indicates that the second data is not pushed in response to the HTTP request.

  In embodiments, the instructions associated with pushing the second data include a list that includes at least two different instructions associated with pushing the second data.

  In embodiments, the acknowledgment data includes one of at least two different instructions associated with pushing the second data, and the at least two different instructions associated with pushing the second data. The one of them is used to identify the second data to be pushed to the client device.

  In embodiments, the instruction associated with pushing the second data is associated with a data type of the second data, the data type including a descriptive data type or a content data type, wherein the second data is the content data Or belong to descriptive data.

  In embodiments, the instructions related to pushing the second data are directed to pushing the media presentation description update.

  In embodiments, the acknowledgment data includes an indication associated with pushing the second data, and the indication associated with pushing the second data within the acknowledgment data is the second data within the HTTP request. Different from the instructions related to pushing.

  In embodiments, the indication associated with pushing the second data includes at least one unique identifier, the at least one unique identifier being the directive to push the second data and the first to be pushed. Represents a two-data identification or a directive not to push the second data.

  In embodiments, the unique identifier is defined in the central repository.

  In embodiments, the unique identifier is set as a function of at least one parameter.

In accordance with another object of the present invention, a method is provided for transmitting data between a server device and a client device, the method at the client device:
Identifying the data to be obtained from the server device;
Generating an HTTP request to obtain first data from the identified data, wherein the HTTP request includes first data identifying information that enables identification of the first data on the server device and the server device is configured to receive the second data Generating, including one or more additional header fields that include an indication as to whether to push data or not to push second data;
Sending an HTTP request to the server device to obtain the first data and cause the server device to push or not push the second data; and receiving acknowledgment data from the server device in response to sending the HTTP request. The acknowledgment data represents an instruction associated with pushing the second data, receiving;
The one or more additional header fields are the second data from the identified data on the server device based only on the one or more additional header fields, and possibly further on the first data identification information. 2nd data specific information which makes specification possible is defined.

  Thus, the method of the present invention allows a client device to adapt its behavior taking into account the push policy applied by the server device.

  In embodiments, the acknowledgment data represents an instruction to push the second data.

  In embodiments, the acknowledgment data indicates that the second data is not pushed in response to the HTTP request.

  In embodiments, the instructions associated with pushing the second data include a list that includes at least two different instructions associated with pushing the second data.

  In embodiments, the acknowledgment data includes one of at least two different instructions associated with pushing the second data, and among the at least two different instructions associated with pushing the second data. The one of is used by the server device to identify the second data to be pushed to the client device.

  In embodiments, the instruction associated with pushing the second data is associated with a data type of the second data, the data type including a descriptive data type or a content data type, wherein the second data is the content data Or belong to descriptive data.

  In embodiments, the instructions related to pushing the second data are directed to pushing a descriptive data update.

  In embodiments, the acknowledgment data includes an indication associated with pushing the second data, and the indication associated with pushing the second data within the acknowledgment data is the second data within the HTTP request. Different from the instructions related to pushing.

  In embodiments, the indication associated with pushing the second data includes at least one unique identifier, the at least one unique identifier being the directive to push the second data and the first to be pushed. Represents a two-data identification or a directive not to push the second data.

  In embodiments, the unique identifier is defined in the central repository.

  In embodiments, the unique identifier is set as a function of at least one parameter.

In accordance with another object of the present invention, a method is provided for transmitting data between a server device and a client device, the method at the server device:
Receiving an HTTP request for obtaining first data from a client device, the HTTP request including first data identifying information that enables identification of the first data on the server device and one or more additional headers; Receiving, including fields;
Retrieving and sending the first data to the client device; and pushing or pushing the second data to the client device as a function of an indication associated with pushing the second data contained in the one or more additional fields. Don't step;
including.

  Thus, the method of the present invention improves the server device's ability to push useful data to the client device.

  In embodiments, the instructions associated with pushing the second data include a list that includes at least two different instructions associated with pushing the second data.

  In embodiments, the instruction associated with pushing the second data is associated with a data type of the second data, the data type including a descriptive data type or a content data type, wherein the second data is the content data Or belong to descriptive data.

  In embodiments, the instructions related to pushing the second data are directed to pushing a descriptive data update.

  In embodiments, the indication associated with pushing the second data includes at least one unique identifier, the at least one unique identifier being the directive to push the second data and the first to be pushed. Represents a two-data identification or a directive not to push the second data.

  In embodiments, the unique identifier is defined in the central repository.

  In embodiments, the unique identifier is set as a function of at least one parameter.

In accordance with another object of the present invention, a method is provided for transmitting data between a server device and a client device, the method at the client device:
Identifying the data to be obtained from the server device;
Generating an HTTP request to obtain first data from the identified data, wherein the HTTP request includes first data identifying information that enables identification of the first data on the server device and the server device is configured to receive the second data Generating, including one or more additional header fields including an indication as to whether to push data or not to push the second data; and obtaining the first data and pushing the second data to the server device Sending an HTTP request to the server device to prevent it from being pushed or pushed;
including.

  Thus, the method of the present invention improves the server device's ability to push useful data to the client device.

  In embodiments, the instructions associated with pushing the second data include a list that includes at least two different instructions associated with pushing the second data.

  In embodiments, the instruction associated with pushing the second data is associated with a data type of the second data, the data type including a descriptive data type or a content data type, wherein the second data is the content data Or belong to descriptive data.

  In embodiments, the instructions associated with pushing the second data are directed to pushing a descriptive data update.

  In embodiments, the indication associated with pushing the second data includes at least one unique identifier, the at least one unique identifier being the directive to push the second data and the first to be pushed. Represents a two-data identification or a directive not to push the second data.

  In embodiments, the unique identifier is defined in the central repository.

  In embodiments, the unique identifier is set as a function of at least one parameter.

In accordance with another object of the present invention, a method is provided for receiving data from a server device by a client device, the method at the client device:
Sending an HTTP request to obtain first data, wherein the HTTP request includes first data identification information that enables identification of the first data on the server device and includes one or more additional header fields. Sending step;
If the client does not want the server device to push second data different from the first data, the client has one information item indicating that the client does not want the server to push the second data in response to the HTTP request. Inserting into at least one of a plurality of additional header fields; and sending an HTTP request to the server device;
including.

  Thus, the method of the present invention prevents the transmission of useless data that is pushed from the server device to the client device.

  In embodiments, the information indicating that the client does not want the server to push the second data includes at least one unique identifier, the at least one unique identifier being a directive for preventing the second data from being pushed. Represents.

  In embodiments, the unique identifier is defined in the central repository.

  In embodiments, the unique identifier is set as a function of at least one parameter.

In accordance with another object of the present invention, a method is provided for sending data from a server device to a client device, the method at the server device:
Receiving an HTTP request for obtaining first data from a client device, the HTTP request including first data identifying information that enables identification of the first data on the server device and one or more additional headers; Receiving, including fields;
Retrieving the first data and sending it to the client device; and sending an information item to the client indicating that the server does not push second data different from the first data in response to the HTTP request;
including.

  Thus, the method of the present invention prevents the transmission of useless data that is pushed from the server device to the client device.

  In embodiments, the information indicating that the server does not push the second data includes at least one unique identifier, and the at least one unique identifier represents a directive for preventing the second data from being pushed.

  In embodiments, the unique identifier is defined in the central repository.

  In embodiments, the unique identifier is set as a function of at least one parameter.

In accordance with another object of the present invention, a method is provided for receiving data from a server device by a client device, the method at the client device:
Sending an HTTP request to obtain first data, wherein the HTTP request includes first data identification information that enables identification of the first data on the server device and includes one or more additional header fields. Sending step;
If the client does not want the server device to push second data different from the first data, the client has one information item indicating that the client does not want the server to push the second data in response to the HTTP request. Inserting into at least one of the plurality of additional header fields;
Sending an HTTP request to the server device;
Receiving acknowledgment data from the server device in response to sending an HTTP request, the acknowledgment data including an information item indicating that the server does not push second data different from the first data; Receiving step;
including.

  Thus, the method of the present invention prevents the transmission of useless data that is pushed from the server device to the client device.

  In embodiments, the information indicating that the client does not want the server to push the second data includes at least one unique identifier, the at least one unique identifier being a directive for preventing the second data from being pushed. Represents.

  In embodiments, the information indicating that the server does not push the second data includes at least one unique identifier, and the at least one unique identifier represents a directive for preventing the second data from being pushed.

  In embodiments, the unique identifier is defined in the central repository.

  In embodiments, the unique identifier is set as a function of at least one parameter.

In accordance with another object of the present invention, a method is provided for sending data from a server device to a client device, the method at the server device:
Receiving an HTTP request for obtaining first data from a client device, wherein the HTTP request includes first data identifying information that enables identification of the first data on the server device, and the client responds to the HTTP request by the server Receiving, including one or more additional header fields containing information items indicating that you do not want the second data to be pushed by
Retrieving the first data and sending it to the client device; and, in response to the HTTP request, sending an information item indicating that the server does not push the second data different from the first data to the client;
including.

  Thus, the method of the present invention prevents the transmission of useless data that is pushed from the server device to the client device.

  In embodiments, the information indicating that the server does not push the second data includes at least one unique identifier, and the at least one unique identifier represents a directive for preventing the second data from being pushed.

  In embodiments, the information indicating that the client does not want the server to push the second data includes at least one unique identifier, and the at least one unique identifier includes a directive to prevent the second data from being pushed. Represent.

  In embodiments, the unique identifier is defined in the central repository.

  In embodiments, the unique identifier is set as a function of at least one parameter.

  In embodiments, the one or more additional header fields are one or more optional header fields.

  In embodiments, the first and second data identification information includes first and second uniform resource identifiers, URIs, respectively.

  In embodiments, the one or more optional header fields include at least one construction rule that generates a second URI from the contents of the HTTP request.

  In embodiments, the one or more optional header fields include change portion information and substitution information, the change portion information identifies at least one change subpart in the reference URI, and the substitution information is one or more of It includes at least one substitution value that replaces the change subpart specified in the reference URI to define a second URI.

  In embodiments, the reference URI includes a first URI included in the received HTTP request.

  In embodiments, the changed portion information identifies two or more subparts in the reference URI to be replaced using each one or more substitution values included in the substitution information.

  In embodiments, the changed portion information includes each of two or more subparts in the reference URI to sequentially consider substitution values of two or more subparts according to their respective priority levels. Associate with each priority level.

  In embodiments, the additional header field explicitly includes a second URI.

In some embodiments, the first data specifying information includes a first uniform resource identifier and URI that specify a main resource on the server device, and defines a sub part of the main resource as first data. And the optional header field includes substitution subpart information that replaces the subpart information in the first data identification information to define the second data identification information.

  In embodiments, the subpart information includes a range value of bytes in the main resource.

  In embodiments, the first and second data are media segments or media content subparts identified by first and second data identification information, respectively, in the DASH manifest presentation description.

In accordance with another object of the present invention, a method is provided for transmitting data between a server device and a client device, the method at the server device:
Receiving an HTTP request for obtaining first data from a client device, wherein the HTTP request includes first data specifying information that enables the first data on the server device to be specified and specifies the second data; Receiving, including one or more optional header fields that make it possible to:
Retrieving the first data and sending it to the client device; and if an optional header field is present in the HTTP request:
Determining the second data identification information that allows the identification of the second data on the server device using only the optional header field and optionally further the first data identification information. I.e. using only the content of the HTTP request; and sending a push commitment message to announce the push of the second data to the client device and / or pushing the second data to the client device;
including.

From a client perspective, the present invention provides a method for transmitting data between a server device and a client device, the method at the client device:
Identifying the data to be obtained from the server device;
Generating an HTTP request to obtain first data from the identified data, wherein the HTTP request includes first data identifying information that allows the first data on the server device to be identified and one Or including a plurality of optional header fields, based only on the optional header fields, and possibly further on the first data identification information (ie, only the content of the HTTP request), from the identified data on the server device Defining and generating second data specifying information that enables specifying
Sending an HTTP request to the server device to obtain the first data and cause the server device to push the second data;
including.

In correlation, the present invention provides a server device for exchanging data with a client device, which device:
Receiving an HTTP request for obtaining first data from a client device, wherein the HTTP request includes first data specifying information that enables the first data on the server device to be specified and specifies the second data; Receiving, including one or more optional header fields that allow
Retrieving the first data and sending it to the client device; and if an optional header field is present in the HTTP request:
Determining second data identification information that enables identification of second data on the server device using only an optional header field, and optionally further first data identification information; and Sending a push commitment message to announce the push to the client device and / or pushing the second data to the client device;
Including at least one microprocessor configured to execute.

Furthermore, the present invention provides a client device for exchanging data with a server device, which device:
Identifying the data to be obtained from the server device;
Generating an HTTP request to obtain first data from the identified data, wherein the HTTP request includes first data identifying information that allows the first data on the server device to be identified and one Or including a plurality of optional header fields, wherein the second data can be identified from the identified data on the server device based only on the optional header fields and possibly further the first data identification information. 2 defining and generating data specific information;
Sending an HTTP request to the server device to obtain the first data and cause the server device to push the second data;
Including at least one microprocessor configured to execute.

  In HTTP / 2, the push promise message precedes the actual push of the corresponding data. Other protocols, particularly bi-directional protocols such as Web Sockets or SPDY (representing SpeedDY), can immediately push the second data without a prior push announcement.

  According to the present invention, the client device efficiently controls the push mechanism by the server device and at the same time allows backward compatibility. It reduces discrepancies between pushed data and client needs. The reason is that the second data (resource or part of the resource) that the client device wants to push is defined using the optional header field of the conventional HTTP request. Furthermore, backward compatibility means that if the server device is native, i.e. it does not support the optional header field, it can still handle HTTP requests in a conventional manner without processing errors. Stem from the facts.

  On a server that understands the optional header field but does not support push features, if the server is a relay server rather than a content server, it can prefetch resources using information from the optional header field.

  Furthermore, the present invention makes it possible to rely on low skill servers, such as servers that do not have DASH knowledge. The reason is that the identification of the second data to be pushed does not require the MPD file or the like to be processed. According to the present invention, only the optional header field, and possibly further the first data identification information, is used to perform such identification.

  Accordingly, embodiments of the present invention provide a lightweight mechanism for server-guided streaming, including a client-driven server push approach. Multiple embodiments may be implemented in connection with a DASH network.

  Embodiments of the present invention may be compatible with existing HTTP / 2 features. These features can be advantageously used to implement multiple embodiments of the present invention.

  Network performance is generally enhanced.

  Any features of the method and device are defined in the dependent claims. Some of them are described below in connection with the method. However, they can also be applied to corresponding devices.

  In one embodiment, the first and second data identification information includes first and second uniform resource identifiers, URIs, respectively.

  In one particular embodiment, the one or more optional header fields include at least one construction rule that generates a second URI from the content of the HTTP request. In other words, the optional header field implicitly defines one or more second URIs using construction rules. As can be inferred from the above, the construction rule only uses an optional header field, and possibly even a first URI, to obtain one or more second URIs.

  For example, the one or more optional header fields include change part information and substitution information, the change part information identifies at least one change subpart in the reference URI, and the substitution information is one or more second URIs. Includes at least one substitution value to replace the change subpart identified in the reference URI. This convention thus defines how the construction rules can be used.

  According to one particular feature, the reference URI includes a first URI included in the received HTTP request. In other words, the construction rule (substitution process) is applied to the first URI, i.e. to the URI of the requested first data. That means that the construction rule (which may be general) uses only the content of the HTTP request to infer the second data to be pushed from the requested first data.

  According to another particular feature, the changed portion information identifies two or more subparts in the reference URI to be replaced using each one or more substitution values included in the substitution information. . Therefore, a complicated second URI can be generated from the first URI.

  According to yet another particular feature, the change part information can be obtained by considering two or more subpart substitution values continuously in the reference URI in order to consider them sequentially according to their respective priority levels. Each of the subparts is associated with a respective priority level. With this definition, the client device orders multiple second URIs and thus leads the order in which the second data is pushed by the server device.

  In some embodiments, the optional header field explicitly includes a second URI. This is contrary to the implicit definition of one or more second URIs, for example using construction rules.

In other embodiments, the first data specifying information includes a first uniform resource identifier, a URI that specifies a main resource on the server device, and a sub part that defines a sub part of the main resource as the first data. And the optional header field includes substitution subpart information that replaces the subpart information in the first data identification information to define the second data identification information.

  An example of the sub-part information is a range parameter used in DASH. In this example, the sub-part information includes a range value of bytes in the main resource.

  In embodiments, the first and second data are media segments or media content subparts identified by first and second data identification information, respectively, in the DASH manifest presentation description. Note that the use of the DASH range parameter allows media content / segment subparts to be identified, and a URI in DASH typically identifies an entire media segment.

Compared to the known prior art, there is also a need to help the client device to lead or guide the push feature of the server. In this context, the present invention also provides a method for transmitting data between a server device and a client device, the method being at the server device:
Receiving an HTTP request for obtaining first data from a client device, wherein the HTTP request includes a first optional header field including one or more filtering parameters;
Retrieving the first data and sending it to the client device; and if its first optional header field is present in the HTTP request:
Identifying a set of data using the main resource obtained from the HTTP request;
Filtering each identified set of data using one or more filtering parameters to obtain a list of second data; and pushing the second data to the client device;
including.

  For protocols that include a push promise feature, the method further includes sending a push promise message to the client device that announces the push of the second data before pushing the second data.

From a client perspective, the present invention provides a method for transmitting data between a server device and a client device, the method at the client device:
Generating an HTTP request to obtain first data, wherein the HTTP request includes a first optional header field that includes one or more filtering parameters;
Obtaining the first data and sending the HTTP request to the server device to cause the server device to push the second data referenced in the main resource estimated from the HTTP request according to the filtering parameters;
including.

One or more filtering parameters are:
-Define a resource type; the one or more resource types include one or more types from application type, text type, image type, video type, audio type; or-in the DASH media presentation description The element identifier is used to identify one or more groups of data; or the first optional header field is defined using a time range that identifies a sub-part of the main resource.

  In addition, push promise messages may be received.

In correlation, the present invention provides a server device for exchanging data with a client device, which device:
Receiving an HTTP request for obtaining first data from a client device, wherein the HTTP request includes a first optional header field including one or more filtering parameters;
Retrieving the first data and sending it to the client device; and if the first optional header field is present in the HTTP request:
Identifying a set of data using the main resource obtained from the HTTP request;
Filtering each identified set of data using one or more filtering parameters to obtain a list of second data; and pushing the second data to the client device;
Including at least one microprocessor configured to execute.

One or more filtering parameters are:
-Define a resource type; the one or more resource types include one or more types from application type, text type, image type, video type, audio type; or-in the DASH media presentation description The element identifier is used to identify one or more groups of data; or the first optional header field is defined using a time range that identifies a sub-part of the main resource.

Furthermore, the present invention provides a client device for exchanging data with a server device, which device:
Generating an HTTP request to obtain first data, wherein the HTTP request includes a first optional header field that includes one or more filtering parameters;
Obtaining the first data and sending the HTTP request to the server device to cause the server device to push the second data referenced in the main resource estimated from the HTTP request according to the filtering parameters;
Includes at least one macro processor configured to execute

  One example of this approach is a request for a main HTML web page as the first data. The optional header field can then define which type or types of sub-resources referenced in the HTML page are to be pushed. Therefore, the optional header field behaves as a filtering parameter. For example, it can provide a filtering parameter “images / *. Jpg” that filters sub-resources to have only a subset of jpg images pushed.

  Improved control of the server push feature by the client device is obtained through the use of filtering parameters applied to the data specified by the request through an optional header field.

  Again, the use of such an optional header field allows backward compatibility at the end of the server.

  Thus, embodiments of the present invention provide a lightweight mechanism for server-guided streaming, including a client-driven server push approach. Multiple embodiments may be implemented in connection with a DASH network.

  Embodiments of the present invention may be compatible with existing HTTP / 2 features. These features can be advantageously used to implement embodiments of the present invention.

  Network performance is generally enhanced.

  Any features of the method and device are defined in the dependent claims. Some of them are described below in connection with the method. However, they can also be applied to corresponding devices.

  In some embodiments, the main resource is the first data. That means that HTTP requests used alone allow the server device to efficiently identify all the second data to be pushed. The server device does not require additional knowledge, such as DASH knowledge for the prior art discussed above. Thus, a low skill server device can be used.

  In other embodiments, the HTTP request includes a second optional header field that defines a uniform resource identifier, URI, that identifies the main resource on the server device. Such an embodiment specifies that the client device first obtains the main resource and then specifies the filtering parameters to actually select the appropriate second data from the main resource (and using an optional header field) Can be implemented when it needs to be analyzed. In fact, in such a case, when the client device requests the main resource, it cannot define filtering parameters because it does not yet have access to the contents of the main resource.

  This specification allows a client to specify a static configuration file stored on a server that can define a list of resources for each resource type. Using such a static configuration file requires low skill for the server to identify resources based on resource type filtering parameters.

  In yet another embodiment, two (or more) filtering parameters are associated with two (or more) respective groups of data and two respective priority levels; the step of filtering comprises second data In order to obtain the ordered list, the second data is arranged in order according to the priority level of the group to which each of the data is data; the step of pushing pushes the second data according to the ordered list. At the client end, it means that two filtering parameters are associated with two groups of data and two respective priority levels; the second data is received in an order according to the priority level of the group to which they belong respectively. It is. This allows the client device to efficiently lead the order in which it wants to receive the pushed data.

  In yet another embodiment, each filtering parameter defines a resource type; the one or more resource types can be an application type (eg, javascript®), a text type (eg, css or html), an image type ( For example, one or more types from png or jpg) video type (eg mp4 or webm), audio type (eg mp3 or wav).

  This rule applies in particular to similar exchanges such as for html or for loading web pages. Of course, any subdivision of these resource types may help to efficiently load specific content (eg, an image or a built-in function such as a JavaScript function).

  In yet another embodiment, the one or more filtering parameters in the first optional header field identify one or more groups of data using an identifier of an element in the DASH media presentation description. Such an element may include a DASH MPD AdaptationSet element, a Presentation element, or a Segment element. In one embodiment, the first data requested by the HTTP request is DASH MPD. Of course, in one variation, the DASH MPD may be specified in the second optional header field above.

  This definition allows the client device to control the push of some parts of the media content defined by MPD.

  In yet another embodiment, the one or more filtering parameters are defined in the first optional header field with a time range that identifies subparts of the main resource, eg, a time range used in a DASH request. Similar to the previous convention, this one also allows the client device to control how subparts of media content streamed using DASH are pushed by the server device.

  Another aspect of the invention relates to a non-transitory computer readable medium that stores a program that, when executed by a microprocessor or computer system in a device, causes the device to perform any of the methods defined above. To do.

  Non-transitory computer readable media provide features and benefits similar to those described above and below in connection with methods and devices, particularly for improved control of server push features by clients and for low skill server devices. You can have that about relying.

  Yet another aspect of the invention relates to a device comprising means adapted to perform the steps of any of the methods defined above.

  Yet another aspect of the present invention is the server device and client described and illustrated substantially in connection with FIGS. 3a or 3b or 5a or 5b or 6a or 7b or 8 of the accompanying drawings. Related to how resources are sent to and from the device.

  At least some parts of the method according to the invention can be executed on a computer. Accordingly, the present invention encompasses completely hardware embodiments, fully software embodiments (including firmware, resident software, microcode, etc.) or software aspects, all herein referred to as “circuits”, “modules” or It can take the form of an embodiment that combines a hardware aspect, which can be generally referred to as a “system”. Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of representation in which computer usable program code is embodied in the medium.

  Since the invention can be implemented using software, the invention can be embodied as computer readable code supplied to a programmable device on any suitable carrier medium. The tangible carrier medium may include a storage medium such as a floppy disk, CD-ROM, hard disk drive, magnetic tape device or solid state memory device. The temporary carrier medium may include signals such as electrical signals, electronic signals, optical signals, acoustic signals, magnetic signals or electromagnetic signals, such as microwave or RF signals.

  Other features and advantages of the present invention will become apparent from the following description of non-limiting exemplary embodiments, taken in conjunction with the accompanying drawings.

A graph is used to show a set of resources linked to a main resource, such as a web page. Fig. 2 shows the loading of the main resource of Fig. Ia without using push features. Fig. 2 shows the loading of the main resource of Fig. Ia using push features. The conventional steps of the client device when the push feature is implemented are shown using a flowchart. The conventional steps of the server device when the push feature is implemented are shown using a flowchart. Figure 2 shows an HTTP exchange for loading a web page. 1 shows a DASH-oriented client-server system according to the prior art. 1 illustrates a client-server system in which embodiments of the present invention may be implemented. 1 illustrates a DASH-oriented client-server system in which embodiments of the present invention may be implemented. Shows the construction of a media presentation. The structure of a DASH media presentation description and MPD file is shown. Fig. 3 shows the main steps describing the client behavior in the system of Fig. 3a. Fig. 3 shows the main steps describing the behavior of a streaming-oriented client in the system of Fig. 3b. Fig. 4 shows the main steps describing the behavior of the server in the system of Fig. 3a or 3b. An exemplary structure of a push header according to the present invention will be described. Fig. 4 shows an exemplary MPD file with SegmentTemplate. Fig. 7b shows a client-server exchange implementing the invention based on the MPD file of Fig. 7a. Fig. 4 shows an example of a push header according to the present invention, associated with DASH streaming. FIG. 2 is a schematic diagram of a device according to an embodiment. An MPD sample illustrating the declaration of a template URI at several levels is shown. An example of a push policy notification confirmation response in the server is shown. An example of a push policy notification confirmation response in the server is shown. An example of a push policy notification confirmation response in the server is shown. An example of a push policy notification confirmation response in the server is shown. An example of a push policy notification confirmation response in the server is shown. Fig. 5 illustrates an example of an exchange of information related to push policies between a client and a server based on a unique identifier. Fig. 5 illustrates an example of an exchange of information related to push policies between a client and a server based on a unique identifier.

  As briefly introduced above, the present invention relates to data transmission over an HTTP communication network. One example is adaptive data streaming such as DASH.

HTTP is a protocol used to send web resources, typically web pages. HTTP implies the following for clients and servers:
The client sends a request to the server, which consists of a “request_line” optionally followed by various types of “headers”. “Request-line” typically includes a method (eg, “GET”) with a “Request-URI” parameter that identifies the requested resource or data on the server, possibly using a range header or the like;
-The server responds to the client's request with a response that includes a representation of the web resource.

  Requests and responses are messages that contain various parts, especially HTTP headers. The HTTP header includes a name along with a value. For example, consider “Host: en.wikipedia.org” where “Host” is the header name and its value is “en.wikipedia.org”. It is used to show the queried resource to the host (eg, the Wikipedia page describing HTTP is available from HTTP://en.wikipedia.org/wiki/HTTP). HTTP headers appear in client requests and server responses.

  A new version of HTTP, HTTP / 2, allows exchanging requests / responses through a stream. A stream is generated inside an HTTP / 2 connection for the exchange of any HTTP request and response. Frames are exchanged within the stream to convey request and response content, pseudo headers and headers.

HTTP / 2 is:
-HEADERS: provided for transmission of HTTP headers. HTTP / 2 distinguishes headers (optional, ie ignored if not understood by the processing device) from pseudo headers that follow stricter rules. The latter corresponds to the request-line mapping defined in previous HTTP versions to indicate HTTP methods and request-URIs. In this document, “HTTP header” or “header” is intended to specify an arbitrary header and is intended to specify a pseudo-header that is explicitly specified as such. Not.
○ Furthermore, in this document, “Request-URI” is a parameter that specifies the requested resource on the server used in the Request-URI defined in RFC2616 (that is, “request-line”). ) Or its equivalent / HTTP / 2 pseudo-header conversion.
-DATA: This is provided for the transmission of HTTP message content-PUSH_PROMISE: This is provided to announce the content to be pushed-PRIORITY: This is provided to set the priority of the stream -WINDOW_UPDATE: This is provided to update the value of the control flow window.-SETTINGS: This is provided to convey configuration parameters.-CONTINUATION: This is provided to continue the sequence of header block fragments. -RST_STREAM: This defines a limited set of frames with various meanings, such as provided to terminate or cancel a stream.

  In HTTP / 2, the request is then converted into a first HEADER frame and one or more DATA frames, and HTTP / 1. The request-line from x is converted into a pseudo header field as described in the HTTP / 2 specification.

  This specification uses “request” or “HTTP request” to indicate a message sent from a client to a server, and uses “response” or “HTTP response” to indicate a message from the server to the client. In addition to requests and responses, we also talk about notifications or server notifications corresponding to messages initiated by the server to the client. The term is HTTP / 1. Conforms to x and HTTP / 2.

  Server push has been introduced in HTTP / 2 to allow the server to send unsolicited web resource representations to clients. Web resources such as web pages typically include links to other resources, and themselves may include links to other resources. In order to fully display a web page, all of the linked or sublinked resources may have to be retrieved by the client. This increasing discovery will lead to slow display of web pages, especially in high latency networks such as mobile networks.

  Upon receiving a request for a given web page, the server can know which other resources are required for complete processing of the requested resource. By sending the requested resource and the linked resource at the same time, the server makes it possible to reduce the loading time of the web page. Thus, using push features, the server can send additional resource representations when requested for a given resource.

As an example of linked resources, FIG. 1a shows a graph of a set of resources owned by a server and their relationships. The set of resources is intertwined: R ₁ , R ₂ , R ₃ , and R ₄ are resources that must be downloaded together to be properly processed by the client. Further, sub-resources A to H are defined. These sub-resources are associated with one, two or three resources. For example, A is linked to R ₁ and C is linked to R ₁ , R ₂ and R ₄ .

  With reference to the flowchart of FIG. 1e, an exemplary mode of operation of a server implementing a push feature is described.

  During step 100, the server receives an initial request. Next, the server identifies the resource to push as part of the response during step 101 and sends a push promise message to the client during step 102. It then starts sending a content response during step 103. The push promise message identifies other resources that the server is trying to push based on, for example, the dependencies shown in FIG. 1a. These messages are sent to inform the client in advance which resources to be pushed are sent. In particular, this reduces the risk of a client sending a request for a resource that is being pushed at the same time or is about to be pushed. To further reduce this risk, the server should send a push commitment message before sending the portion of the response associated with the resource described in the push commitment. This also allows the client to cancel the promised resource push if the client does not want those resources. Next, during step 104, the response and all promised resources are sent. The process ends during step 105.

  FIGS. 1b and 1c show loading a web page without a push feature and loading a web page with a push feature, respectively.

Figure 1b shows the HTTP exchange that does not use the push feature of the server: the client requests the R _1, then it requests them to discover R _2, A, B, C and D. After receiving them, the client requests R ₃ , R ₄ , F and G. Finally, the client requests H and I sub-resources. Thus, a request must be sent to any required resource: resources R ₁ to R ₄ and sub-resources A to I. In addition, this process requires four round trips to retrieve the entire set of resources.

FIG. 1c shows an HTTP exchange that uses the push feature by a server of directly linked sub-resources. After R ₁ request, the server pushes A, B, C and D and sends an _{R 1.} The client identifies the R _2, requests it. The server sends R ₂ and pushes F and G. Finally, the client identifies R ₃ and R ₄ and requests these resources. The server sends R ₃ , R ₄ and pushes H and I. Thus, the number of requests is limited to elements R ₁ to R ₄ . Elements A through I are “pushed” by the server to the client based on the dependencies shown in FIG. 1a, thereby eliminating the associated request. This process requires three round trips to retrieve the entire set of resources.

  Thus, as shown in FIGS. 1b and 1c, when a server uses a push feature, the number of HTTP round trips (request + response) required to load a resource with its sub-resources is reduced. This is of particular interest for high latency networks such as mobile networks.

  In order to reduce the loading time of a set of resources, typically a web page and its sub-resources, HTTP / 2 allows multiple request and response priorities to be exchanged in parallel. As shown in FIG. 2, a web page may require the download of several resources, such as JavaScript and images. During the first HTTP exchange 200, the client retrieves the HTML file. This HTML file includes links to two JavaScript files (JS1, JS2), two images (IMG1, IMG2), one CSS file, and one HTML file. During exchange 201, the client sends a request for each file. The order given in the exchange 201 of FIG. 2 is based on the order of the web pages, and the client sends a request as soon as a link is found. The server then receives requests for JS1, CSS, IMG1, HTML, IMG2 and JS2 and processes these requests in that order. The client then retrieves these resources in that order.

  The client will want to have its proper order to download the sub-resources listed in the web page description (HTML file). In such cases, it may be valuable for the server to have this information, especially to perform push features using that order.

  The flowchart of FIG. 1d shows the client-side process when a push feature is performed.

  When the client identifies a resource to retrieve from the server, it first checks during step 106 whether the corresponding data already exists in its cache memory. If the resource already exists in the cache memory (Yes), it is retrieved from it during step 107. The cached data may be data retrieved from previous requests or previously pushed by the server. If it does not exist in the cache memory (No), the client sends a request during step 108 and waits for a server response.

  Upon receiving a frame from the server, the client checks during step 109 whether the frame is a frame corresponding to a push commitment. If the data frame corresponds to a push commitment (Yes), during step 110, the client processes the push commitment. To do so, the client identifies the resource to be pushed. If the client does not want to receive the resource, the server does not push the resource because the client can send an error message to the server. Otherwise, the client stores the push promise until it receives the corresponding pushed content. The push promise is used so that the client does not request the promised resource while the server is pushing the promised resource.

  If the data frame does not correspond to the push commitment (No), it is checked during step 111 whether the frame is a data frame associated with the pushed data. If it is related to pushed data (Yes), the client processes the pushed data during step 112. The pushed data is stored in the client's cache.

  If the frame is not a data frame associated with the pushed data (No), it is checked during step 113 whether it corresponds to a response received from the server. If the frame corresponds to a response from the server (Yes), the response is processed during step 114 (eg, sent to the application).

  If not (No), during step 115 it is checked whether the frame identifies the end of the response (Yes). In this case, the process is terminated during step 116. If not, the process returns to step 109.

  In this way, the client will receive the response and the promised resource. Thus, promised resources are typically stored in the client's cache while the response is being used by an application such as a browser that displays the retrieved web page. When a client application requests one of the pushed resources, that resource is immediately removed from the client's cache without incurring a network delay.

  The storage of pushed resources in the cache is controlled using cache control directives. Cache control directives are also used for response control. These directives are particularly applicable to proxies, where resources can be saved by the proxy or by the client alone, whether pushed or not.

  As mentioned above, the client will want to have its proper order of downloading the sub-resources listed in the web page description (HTML file), so it will push the push feature at the end of the server. Should lead. The present invention provides the server with a specific set of (sub) resources or one or more portions of (sub) resources that the client may desire after requesting the first resource, for example, in this respect Intended to improve to inform. In particular, the present invention applies to servers that have little intelligence, such as servers that do not have the knowledge to process web page descriptions as the basis for clients to identify their (sub) resources. Trying to fit.

  Such needs for the present invention are greater with respect to HTTP streaming over HTTP, for example, in connection with adaptive HTTP streaming such as DASH when using push features.

  The general principle of media streaming over HTTP is shown in FIG. Most new protocols and standards for adaptive media streaming over HTTP are based on this principle. This is the case for DASH, and the following description refers to this.

  The media server 300 streams data to the client 310. The media server stores media presentations. For example, the media presentation 301 includes audio and video data. Audio and video can be interleaved in the same file. The manner in which the media presentation is constructed is described below in connection with FIG. 4a. The media presentation is divided in time into temporary segments 302a, 302b and 302c, such as small independent continuous, MP4 segments that can be independently addressed and downloaded. The media content download address (HTTP URL) for each of these temporary segments is set by the server to the client. Each temporary segment of audio / video media content is associated with one HTTP address.

  The media server includes a list of media content characteristics (eg, media type: audio, video, audio-video, text, etc.), encoding format (eg, bit rate, timing information, etc.), temporary media segments, and associated URLs. A manifest file document 304 (an example of which is shown in FIG. 7a) that describes the contents of the media presentation is also saved. Alternatively, the document includes template information that allows an explicit list of temporary media segments and associated URLs to be reconstructed. This document can be written using the extensible markup language (XML).

  The manifest file is sent to the client. Upon receipt of the manifest file during step 305, the client is informed of the association between the temporary segment of media content and the HTTP address. In addition, the manifest file provides the client with information regarding the content of the media presentation (in this example, interleaved audio / video). This information may include resolution, bit rate, and the like.

  Based on the received information, the client's HTTP client module 311 can send an HTTP request 306 to download a temporary segment of the media content described in the manifest file. The server's HTTP response 307 conveys the requested temporary segment. The HTTP client module 311 extracts temporary media segments from the response and supplies them to the input buffer 307 of the media engine 312. Finally, the media segment can be decoded and displayed during respective steps 308 and 309.

  Media engine 312 interacts with DASH control engine 313 to obtain a request to issue the next temporary segment in a timely manner. The next segment is identified from the manifest file. When that request is issued, it depends on whether the receive buffer 307 is full. The DASH control engine 313 controls the buffer to prevent the buffer from being overloaded or completely emptied.

  Media presentation and manifest file generation are described in connection with FIG. 4a. During steps 400 and 401, audio and video data is acquired. Next, the audio data is compressed during 402. For example, the MP3 standard can be used. Furthermore, the video data is compressed in parallel during step 403. Video compression algorithms such as MPEG4, MPEG / AVC, SVC, HEVC or scalable HEVC may be used. Once compression of audio and video data has been performed, audio and video elementary streams 404, 405 are available. The elementary stream is encapsulated into a global media presentation during step 406. For example, the ISO BMFF standard (or the ISO BMFF standard extension to AVC, SVC, HEVC, HEVC scalable extension, etc.) is used to describe the contents of encoded audio and video elementary streams as a global media presentation. Can be used. The resulting encapsulated media presentation 407 is used during step 408 to generate an XML manifest file 409. Several representations of video data 401 and audio data 400 can be obtained, compressed, encapsulated, and described in media presentation 407.

  For the special case of the MPEG / DASH streaming protocol shown in FIG. 4b, the manifest file is referred to as a “Media Presentation Description” (or “MPD” file). The root element of this file is an MPD element that contains attributes that apply to all presentations and DASH information such as profiles or schemas. The media presentation is divided into temporary periods displayed by a period element. The MPD file 410 contains all the data associated with each temporary period. By receiving this information, the client knows the content for each period of time. For each period 411, an AdaptationSet element is defined.

  One possible configuration is to have one or more AdaptationSets for each media type included in the presentation. The AdaptationSet 412 associated with the video contains information regarding the various possible representations of the encoded video that can be obtained from the server. Each representation is described in a representation element. For example, the first representation may be a video encoded at a spatial resolution of 640 × 480 and compressed at a bit rate of 500 kbits / s. The second representation may be video that is the same but compressed at a bit rate of 250 kbits / s.

  Each video can then be downloaded with an HTTP request if the client knows the HTTP address associated with that video. The association between the content of each representation and the HTTP address is done using an additional level description: a temporary segment. Each video representation is divided into temporary segments 413 (typically a few seconds). Each temporary segment includes content stored on a server that can be accessed via an HTTP address (URL or URL having a range of 1 byte). Several elements can be used to describe temporary segments in the MPD file: SegmentList, SegmentBase or SegmentTemplate.

  In addition, a specific segment: initialization segment is available. The initialization segment contains MP4 initialization information that describes the encapsulated video stream (if the video is encapsulated using ISO BMFF or its extension). For example, it helps the client to instantiate a decoding algorithm associated with the video.

  The initialization segment and media segment HTTP addresses are specified in the MPD file. In this description, a “segment” is a temporary fragment (eg, one or more moof + mdat boxes in an mp4 file when the media is encapsulated according to ISO / IEC 14496 part 12 and part 15) or a temporary segment (eg, It should be noted that it is used to indicate the mp4 segment (starting from the “styp” directive).

  An exemplary MPD file is shown in FIG. 7a. Two video representations are described in the MPD file shown. The first is a low resolution version (“Representation id =“ h264bl_low ””) and the second is a higher resolution version (“Representation id =“ h264bl_full ””). Both video representations are included in the same AdaptationSet, and each segment of each representation is addressed through the SegmentTemplate URL (“media =“ mp4-live- $ RepresentationID $-$ “Number $ .m4s” ”, here. $ RepresentationID $ changes between two possible video representations, and $ Number $ changes along the position in the video).

  To gain clarity, the associated audio streams that may be present are not displayed, and they can be described in different AdaptationSets, each with an alternative version.

  When starting a streaming session, the DASH client requests a manifest file. Upon receipt, the client analyzes the manifest file and selects a set of AdaptationSets appropriate for the environment. The client then selects a representation that matches its bandwidth, decoding and rendering capabilities within each AdaptationSet in the MPD. It then builds in advance a list of segments to be requested, first from the initialization information for the media decoder (SegmentTemplate @ initialization URL in the example of FIG. 7a). When initialization information is received by the decoder, they are initialized and the client requests the first media data and buffers a minimum amount of data before actually starting the display.

  These multiple requests / responses can introduce delays during the startup of a streaming session. The risk is that the service provider encounters a situation where their client leaves the service without starting to watch the video. It is common to refer to this time between the initial HTTP request for the first media data chunk executed by the client and when the media data chunk actually begins to play as the startup delay. It depends not only on the network round trip time but also on the size of the media segment: the longer the segment, the longer the startup delay.

  Furthermore, in live streaming, when a client requests a media segment, this segment may not be ready at the server. To reduce latency, it may be beneficial to reduce the segment length. However, such a reduction in segment length may dramatically increase the number of requests / responses, resulting in significant network traffic overhead.

  In order to reduce such an increase in traffic overhead, the proposed approach is to use HTTP / 2 push features at the server so that data can be pushed to the client based solely on the server's spontaneity. More generally for HTTP, such an approach (using push features) organizes resources into a number of sub-resources (eg, css, jscript, web pages containing images; or DASH manifests containing a list of segments). It makes it possible to reduce the number of round trips (and then the latency) between the HTTP client and the HTTP server.

  As mentioned above, such use of push features in connection with DASH streaming over HTTP has already been proposed in US Pat.

  The mechanism proposed in this publication is a highly complex for DASH, especially where the server device can apply a push policy to the MPD file to determine what data or resources to push according to the push policy. Require knowledge.

  These mechanisms are contrary to some useful aspects of adaptive streaming over HTTP.

  More precisely, adaptive streaming over HTTP is based on the assumption that the client guides the streaming because the client can generally select the best version of multimedia content for his purposes. For example, the client will know whether to request HD video or SD video based on its form factor and screen resolution. The use of push features for adaptive streaming over HTTP should maintain such behavior and allow the client to fully drive the server with respect to the pushed data.

  Furthermore, adaptive streaming over HTTP, such as the MPEG DASH standard, requires little intelligence on the server side: the HTTP request sent by the client is simple, so with a simple HTTP server to serve the manifest and media segments. It is enough. Because of this simple server, it is possible to supply a large number of streaming clients without requiring additional costs for server resources other than the standard web usage of HTTP. In particular, a large number of streaming clients can be managed through a content distribution network using standard HTTP optimization techniques. The use of push features for adaptive streaming over HTTP should maintain the simplicity of this server.

The present invention seeks to improve the use of push features in general association with HTTP. It applies in particular to streaming over HTTP and adaptive streaming over HTTP such as DASH. However, the present invention should preferably preserve the existing beneficial features of adaptive streaming over HTTP as much as possible. This has the following requirements:
-Maintain client-controlled transmission to avoid potential useless (for client) data being pushed by the server;
-Preventing the use of specific application knowledge on the server side in order to maintain the scalability benefits mentioned above;
-Maintaining the way in which resources and sub-resources are requested in a conventional manner to maintain interoperability and caching capabilities between legacy clients and / or servers that do not implement the present invention. For example, in the case of a DASH segment, this should avoid the introduction of a request format that requires specific actions (eg, request-URI conversion, etc.) to process the requested segment;
-Keep server side processing low;
It means that as many as possible should be satisfied.

  The idea of the invention is to provide a hint for the server to determine additional resources / data or multiple resources that the client wishes to receive (if possible using a push mechanism) or the client receives additional resources Any information that provides a hint for the server to determine that it does not want to be included in a conventional HTTP request that requests the first data or resource. In particular, these hints are defined in such a way that the determination of additional resources / data or resources does not use contextual information or information outside the request. An HTTP request may be viewed as an automatic descriptive request with respect to additional resources / data or multiple resource definitions.

  Examples of such hints are described below and include an implicit URI / URL through the use of an explicit URI / URL or list of URI / URLs, construction rules based on automatic descriptive HTTP requests, and resource / data filtering rules. .

The server-side method according to the invention seeks to transmit data between a server device and a client device, at the server device:
Receiving an HTTP request for obtaining first data from a client device, the HTTP request including first data identifying information that enables identifying first data on the server device and allowing second data; Receiving, including one or more optional header fields
Retrieving the first data and sending it to the client device; and if its optional header field is present in the HTTP request:
Determining the second data identification information that allows the identification of the second data on the server device using only the optional header field and optionally further the first data identification information. That is, the HTTP request is self-sufficient, i.e., self-describing, to determine the second resource; and sends a push commitment message that announces when the second data is pushed to the client device and / or the second data Pushing to the client device;
including.

  In certain embodiments, to inform the client that the server will push the second data or additional resource requested by the client, to inform the server not to push the second data or additional resource, or Acknowledgment data is sent to the client to provide hints for the client to determine second data or additional resources / data or resources that may be sent.

The client-side method according to the present invention seeks to transmit data between a server device and a client device, at the client device:
Identifying the data to be obtained from the server device;
Generating an HTTP request to obtain first data from the identified data, wherein the HTTP request includes first data identifying information that allows the first data on the server device to be identified and one Or a plurality of optional header fields, based on the specified data on the server device based on only the optional header field and possibly further the first data specifying information (ie, only the content of the HTTP request). Defining and generating second data identification information that enables data identification;
Sending an HTTP request to the server device to obtain the first data and cause the server device to push the second data;
including.

  In certain embodiments, when the client receives acknowledgment data regarding the push request, the client adapts its strategy to obtain second data or additional resources.

  The first data identification information usually corresponds to a request URI that forms part of the “request-line” of an HTTP request (or its conversion to an HTTP / 2 pseudo-header).

  The approach proposed by the present invention satisfies all or part of the above requirements.

  First, the method of the present invention allows a client to specify one or more additional or related resources to push to the server at the same time as requesting data. Since the client will receive these resources without sending a special request for them, network traffic and latency are reduced.

  In addition, they can determine whether the client receives additional resources (depending on server support for optional headers according to the invention) or whether the client must request them (push commitment frame). It also makes it possible to be informed. Thus, backward compatibility with existing streaming servers is maintained and feature deployment should be made easier.

  In addition, they also allow the server to easily identify the next resource or resources to be pushed to the client without requiring application specific knowledge. Thus, processing on the server side is limited and multiple clients can be authorized to request from the same server.

  FIG. 3a shows a general illustration of a client / server system for implementation of the present invention. In the following, “video”, “media” or “content” will be referred to indiscriminately to indicate resources with the knowledge that video is a special case of media or content. Similarly, “MPD” or “manifest” or “streaming manifest” or “HTML page” is referred to indiscriminately to indicate a description file of media resources to be sent from the server to the client.

  The present invention aims to improve HTTP communication between the client and server, particularly data streaming, as shown in FIG. 3a, and more precisely the resource loading time and network traffic overhead. It aims to reduce both.

  The server 350 stores resources that the client 380 can download. The resources on the server are classified into main resources 351 that refer to or include sub-resources (352a, b, c).

  For example, the main resource can be an HTML page, and the sub-resource can be a css resource, image and / or media file, java script code or other HTML page referenced in the main resource. The access rights and organization of these resources can be described in the static configuration file 355.

  HTTP requests issued by the client 380 are received and processed by the HTTP processor 356, which includes a request parser 357 that decomposes the request into resource identification and header processing.

  The present invention contemplates one particular header process performed by the push header processor 358. The latter is responsible for processing one or more specific push headers that are optional in the HTTP request as described below. As briefly introduced above, based on that one or more specific push headers, using only HTTP requests, the server can push one or more references to additional resources to push them. Can be generated.

  The resource manager 360 is responsible for checking the presence / absence / freshness of the resource and supplying the requested resource to the HTTP processor 356. The response generator 359 then encapsulates these supplied resources into one or more HTTP responses (HTTP / 1.x) or frames (in HTTP / 2) that are sent to the client.

  The client 380 has a user interface 381 for the user to select, interact with and view content that is processed by several client modules.

  The user interface 381 converts the user's click into a request for additional content that is processed by the request scheduler 383 in the HTTP client 382. The request for the additional content can be translated as a list of resources to be downloaded. The HTTP client 382 processes communication with the HTTP server 350.

  The HTTP client includes a request generator 384 that constructs an HTTP request (HTTP1.x) or frame (HTTP / 2) to request resources from the server 350.

  In accordance with the present invention, the HTTP client 382 specifies the next one or more resources waiting in the request scheduler 383 and / or specifies a push policy, push strategy or push directive as specified above (optional ) Includes a specific module responsible for inserting the push header into the HTTP request, namely the push header generator 385. In certain embodiments, the push header may include a push type and possibly associated parameters.

  Responses or notifications received from the server are processed by a response parser 386 that extracts data and stores them in the client cache / memory 387. The information carried in the response header can also be received and processed by the HTTP client 311 and made available to the DASH control engine 313 (eg, when a DASH application is written in javascript code using XmlHTTPRequest).

  These data are used by the rendering engine 388, which parses the data (389) and dispatches them to the appropriate decoding module 390. Based on those data, the latter supplies the recovered data to the display 391 for rendering at the user interface 381.

  In accordance with the present invention, the parsing module 389 can analyze the content of the received data to identify additional resources that are of potential interest to the user. In such a case, the parse module 389 adds those additional resources in the request scheduler 383.

  The client behavior is shown in FIG. 5a and the server behavior is shown in FIG. 6a.

  Referring to FIG. 5a, in step 551, the client requests a main resource, eg, an HTML web page or a streaming manifest, using an HTTP request. The HTML code for the web page is parsed (using module 389) at step 552 to identify the resources that make up the web page. Using the parsed result, the client identifies a list of resources that it must download so that it can render the entire page. This is step 553 and the list of resources is stored in the scheduler 383.

  In step 554, the client generates and sends a first HTTP request to obtain the first identified resource from the server. In accordance with the present invention, the client (module 385) can also specify a list of additional / related resources that it wants the server to push to in a particular push header. This is step 555. An example syntax for a particular push header is given below.

  Upon receipt of one or more responses from the server at step 556, the client (module 384) checks whether a server notification (ie, push promise) that announces the push of data has been received (step 557). This check may be stopped when the data for the first resource is completely received. The reason is that after the end of the stream corresponding to the requested first resource, push promises related to additional / related resources defined by a particular push header cannot be sent. It is recalled here that a server that does not support a specific push header will simply ignore this header without sending a push commitment for the additional / related resources defined in this header.

  If the check is negative, the only data received is that of the requested first resource. Accordingly, they are processed by module 384 at step 560 and provided to the rendering engine 388. The process then returns to step 555 to request additional resources stored in the request scheduler 383 (step 561).

  If the check is positive, meaning that the server pushes some of the resources suggested by the client in a particular push header, the client updates the list of resources to download in the request scheduler 382. Withdraw the pushed resource from it. This is step 558. The client then repeats until the resource to download no longer remains in the request scheduler 382 (loop to step 561 and step 555) before the data for the first resource (step 560) and other additional / Process data for associated resources (step 559).

  Turning now to FIG. 6a, it is recalled that the server 350 uses a dedicated “push header” processor 358 to process a particular push header provided by the client 380 in the HTTP request. In addition, the HTTP processor 356 may parse the HTTP request and extract various parameters included in the request, including the requested first resource URI and any one or more headers. Handle. Thus, the HTTP processor 358 identifies a specific (optional) push header by its name and forwards it to the push header processor 358 for processing.

  In step 601, the server receives a request from client 380 and processes it to obtain a main resource, for example, a streaming manifest in the context of streaming. It is processed by the HTTP processor 356.

  Next, in step 602, the server responds by sending manifest data. In step 603, the server receives a new request from a client requesting a first resource, usually the first resource referenced in the manifest data. This can be a media segment in the context of media streaming.

  In this request, the client may specify additional or related resources that it is interested in using specific push headers. Accordingly, in step 604, the server checks whether such a specific push header is included in the request.

  If it is included and written, the server supplies that particular push header to the particular push header processor 358. The latter parses various parts of its push header as described below to generate one or more references to additional or related resources specified by the client. This is step 605.

  Optionally, the server can have a pre-configured authorization file that declares whether each resource belonging to the list of resources it owns can be pushed or not. This authorization file can be considered at step 606 to validate or invalidate some of the references obtained at step 605.

  The server notifies the client with a push announcement message (eg, PUSH_PROMISE frame) only for the resources for which the push is authorized according to the authorization file. This is step 607. In HTTP / 2, a PUSH PROMISE frame is a stream corresponding to a client request, and one PUSH PROMISE frame is sent per resource identified in step 605. Step 607 is followed by step 608, in which the server sends the requested first resource (ie, the first media segment in the context of streaming) to the requesting client.

  If the specific push header does not exist or is not supported (test 604 is false), or if no push is authorized for the specified resource (test 606 is false), only the requested first resource is stepped At 608, it is sent back to the client.

  Upon sending the requested first resource, the server then closes the corresponding stream and uses the stream announced in the push announcement message (PUSH PROMISE frame), if not canceled by the client, and steps Push data for additional or related resources identified at 605. This is step 609, and sending at this step may rely on sending one or more data frames.

  As noted above, in certain embodiments, the server is informed that the server will push the second data or additional resources requested by the client, or the server does not push the second data or additional resources. Acknowledgment data is sent to the client to inform it or provide a hint for the client to determine the second data or additional resources / data or resources that the server can send.

  Thus, as indicated by reference numeral 610, the server informs the client that the server will push the second data or additional resources requested by the client, or neither the second data nor the additional resources. Respond to received requests to inform the server that it will not push or to provide a hint for the client to determine the second data or additional resources / data or resources that the server can send Acknowledgment data can be added to the response sent. An example of such acknowledgment data is given by referring to FIGS. 11a to 11e.

  FIG. 3b shows a client-server system associated with data streaming, eg DASH. Components that are the same as those in FIG. 3 have the same reference numerals.

  First, at the DASH control engine 313 responsible for determining the media segment to download, to communicate with the HTTP client 311 a list of the next segment to download as inferred by the request scheduling module in the DASH control engine 313. Additional modules have been added.

  This information is processed in the HTTP client 311 by a specific “push header” generator 314. From the list of next segments to download, the push header generator 314 can generate an appropriate syntax for a particular push header, for example by mapping the list of next segments to download to various parts of the particular push header. Responsible for generating.

  The specific push header output by the push header generator 314 is supplied to the HTTP client 311 to be inserted into the current HTTP request.

  On the server side, HTTP processor 320 and push header processor 321 are similar to HTTP processor 356 and push header processor 358 described above in connection with FIG. 3a, but are streaming and DASH oriented.

  FIG. 5b shows the main steps describing the behavior of a streaming-oriented client in the system of FIG. 3b.

  In step 501, the client 310 requests the streaming server 300 for a streaming manifest associated with the desired media. Upon receipt of the streaming manifest, client 310 parses it at step 502 and then selects a video representation at step 503.

  Iteratively during media streaming, the client selects the next segment requesting the server to download. This is step 504.

  Next, step 505 is to identify future segments that the client may need. This decision is for the request scheduler in the DASH control engine 313 to anticipate a future segment: for example, whether it switches immediately or stays at the same representation level.

  To anticipate the download of the next segment or segments, the client can specify the number of future segments “K” (K is set by the client) needed for later rendering.

  For example, this can be done by parsing the SegmentList in the MPD to retrieve the next K segments from the current one, or for the next K segments using the SegmentTemplate provided in the MPD. This can be done directly by calculating the segment number or by calculating the next K byte ranges from the mp4 box when the segment is addressed through the byte range.

  However, different selection criteria may be used for the process identified in step 505.

  In connection with adaptive streaming, the selection criteria may include a client switching strategy when switching between representations. For example, when the client adopts an aggressive switching strategy, K is defined as low to allow finer switching granularity (eg, corresponding to the number of segments covering less than 5 seconds). On the other hand, when the client adopts a conservative strategy and does not switch too often, K may be set larger (eg, to the number of segments covering 10 seconds or more).

  Still in connection with adaptive streaming, another selection criterion may include the server's PUSH PROMISE capability. For example, if the server cannot promise or send the same number of segments in time as suggested by the client, the client can take this information into account and reduce the value of K. As a result, each time fewer media segments are proposed to be pushed.

  Still in connection with adaptive streaming, another selection criterion may include a client prefetch strategy. For example, the client can select the first segment for fast seeks at the beginning of various time periods. Alternatively, if the video application provides information about very popular parts in the video, the criteria may include selecting the first segment that corresponds to those very popular parts.

  Another possible streaming-oriented selection criterion can result from analysis of manifests, MPDs. For example, the client can suggest to the server to push the segment associated with the selected representation. This can be easily determined using the associationID between the associated representations. This proposal can rely on associationType information. Furthermore, for dependent representations, segments for the enhancement layer can be proposed to be pushed.

More generally, in resource downloads over HTTP, eg web pages (see FIGS. 3a and 5a), the client (web browser, HTML renderer) analyzes the main resource and is referenced in it One or more sub-resources that you want to download quickly can be identified. By parsing the HTML main resource, the client can, for example:
A <link> element with a “rel” value specifying “prefetch” or “next”;
-A <link> element that specifies a resource associated with the style sheet that selects the CSS resource, for example;
A <script> element that selects, for example, a sub-resource corresponding to a Java script code;
-Media elements such as <img> and / or <video>;
You can rely on

  From those elements that may be declared in the HTML page, the client can select a list of URIs through their “href” attribute. This list of URIs is placed, for example, in one or more specific push headers depending on the type of resource, or concatenated in a single header as a list of URIs, or “q” in the well-known Accept HTTP header. “Can be organized as a prioritized list similar to values.

  After step 505 of selecting and identifying K additional or related resources, the client generates an HTTP request to obtain the next segment identified in step 504. This is step 506.

  The URL of the next segment or the SegmentBase URL with one byte range is used to form an HTTP request (in addition to the HTTP method that forms the request line).

  In accordance with the present invention, the additional step 507 obtains a list of future segments (ie, additional resources) determined by the DASH control engine 313 at step 505 with respect to the push header processor 314 of the HTTP client 311 and these futures. Is to set a specific push header to define the segment.

  Several ways of declaring these future segments that the client wants the server to push can be implemented as described below.

  When an HTTP request containing a request line for the next segment and including a specific push header for proposing an additional segment push is ready, it is still sent to the server 300 by the HTTP client 311 in step 507.

  Upon receiving a response from the server at step 508, the client checks whether the server is sending a push announcement notification indicating that the server is willing to send additional segments defined by the specific push header. This check is step 509.

  Push announcement notifications can be made, for example, over HTTP / 2 using one or more PUSH_PROMISE frames, one for each future segment.

  If the data for the next segment selected and requested in step 504 has been completely received (the corresponding stream is closed by the server) and no push announcement notification has been received (test 509), the HTTP client 311 informs the DASH control engine that the next segment to request is the immediately following segment. This is step 510.

  Otherwise (test 509 true), the next segment to request with a new HTTP request is the segment immediately following the last segment promised to be pushed. Update on the client side is performed in step 511. Meanwhile, at step 512, data for K future segments is received by the HTTP client from the server.

  Following steps 510 and 512, the process loops back to step 505 to repeat the process until streaming is complete.

  Instead, the client 310 can implement processing of K future segments to obtain in the HTTP client 311. In such an implementation, it is the HTTP client that is responsible for determining the next segment or segments to download. The pushed data received by the HTTP client 311 is then pre-client cached for the DASH control engine 313 so that the latency perceived at the DASH application level is reduced when requesting the next segment. (307) will be satisfied.

  In certain embodiments, when the client receives the acknowledgment data for the push request, the client processes the received acknowledgment data, eg, to adapt its strategy of obtaining second data or additional resources (step 513). . An example of processing such acknowledgment data is given by referring to FIGS. 11a to 11e.

  Looking at the syntax of a specific push header as all HTTP headers, it is specified by a {name, value} pair, and the name and value are separated by a colon ':'.

  The header name can be, for example, “Push-Request”, or any other name that does not conflict with other existing header names. If it is an application-specific header, the name can begin with the application name: for example, “DASH-Push-Request” or “HTML-Push-Request” that matches various cases.

  In the following, generic headers are considered without application-related prefixes.

  The specific push header goal is to define (provide to the server) one or more unique resource identifiers (URIs) or locators (URLs) and provide additional resources for the client requesting the first resource. Or identifying the part of the resource of interest. As specified by the present invention, HTTP requests must be self-sufficient to determine these additional resources, i.e., without external or contextual information.

  Various embodiments are possible that define additional resources or portions of resources.

In embodiments, the specific push header explicitly includes a URI or URL to identify these additional resources. For example:
<Push-Request: HTTP: // server / path / segment-2. mp4>

  In other embodiments, they are indicated through construction rules, which are inserted into specific push headers. In other words, the list of additional resources of interest is expressed as a construction rule. The syntax for a particular push header may be as shown in FIG. 6b.

  The header value of the header 650 is composed of three separate parts separated by reserved characters, eg, ';'.

  The first part 652 is “support” that defines to which part of the HTTP request the construction rules defined by the two other parts must be applied. In particular, such a URI or URL may be all or part of the request-URI set in the HTTP request.

  Thus, the term “support” can refer to the initial request-URI itself, or it can refer to another HTTP header present in the HTTP request.

  The second part 653 defines the extraction pattern from the support, ie the URI or URL changing part that the support part 652 points to.

  For example, the change part in the request-URI or the like can be specified using a reserved character. In one variation, the variation portion may be expressed as a regular expression that indicates a portion such as a request-URI to be extracted and modified.

  Accordingly, the second portion 653 includes changed portion information and can take the form of a URI template.

  When the support is one other HTTP header, there may be no extraction pattern to show, or for example 880 (see below), the entire header value is shown as the pattern to replace.

  The last part 654 optionally includes one or more substitution values to be applied as successors of the change part defined by the second part 653.

  An assigned value may be defined using a colon-separated list of values (or any dedicated separator), or using a range of values, or using a list of ranges. In such a case, the push header processor 321/358 should infer the same number of URLs as the substitution value by repeating the list of values or the entire range or ranges.

For example, when the first part and the second part are merged:
<Push-Request: HTTP: // server / path / segment- {1}. mp4; {2-5}>
Here, {1} defines a change part and {2-5} is an assigned value.

Another example with three separate parts is as follows:
<Push-Request: request-URI; segment- {1}. mp4; {2-5}>
Here, “request-URI” is support, “segment- {1} .mp4” is the part of the URI defined by the support having the change part {1}, and {2-5} is an assigned value .

  One problem is to build construction rules as generally as possible. An exemplary important aspect for such construction is provided in connection with adaptive streaming.

  Various ways of describing media segments or media content subparts: SegmentTemplate, SegmentBase or SegmentList are provided in DASH, and only one of these three is present in the Representation, AdaptationSet or Period element at a time.

  SegmentTemplate is the most convenient way to easily build a URI template for clients to provide hints to the server for the next segment that they want to download. The reason is that SegmentTemplate clearly indicates which part of the segment URL defined in the manifest is about to change, for example depending on the unique identifier of the representation or the bandwidth of the representation. is there. In this case, the identification of the K future segments by the client does not require any capabilities other than the standard template decomposition process that can be utilized by the DASH control engine 313.

This is the case in the example of FIG. From the URI template “mp4-live- $ RepresentationID $-$ Number $ .m4s”, it is easy to define a construction rule that specifies K segments after the current segment N of the same Representation “h264bl_low”.
<Push-Request: “mp4-live-h264bl_low- {1} .m4s”; {(N + 1) − (N + K)}>

  With respect to the SegmentList approach, the client can preprocess the MPD file to identify a repeating pattern between the URIs of the listed segments, and then infer general rules that represent a list of segment URLs.

  Instead, the MPD analyzer can do this work offline and attach a new element, attribute or descriptor to the SegmentList to provide a URI template that can be used. This is to facilitate processing on the client side. As an element or attribute, a URI template could be defined within a SegmentList element. As a descriptor, it could be defined in the parent element of the SegmentList (eg at the level of the Representation element).

  FIG. 10 provides an MPD sample 1000 that uses a SegmentList element for segment description. SegmentList contains an enumeration of SegmentURL elements. In this MPD sample, two alternative representations 1002, 1003 for the same video content are described in the same AdaptationSet 1001.

  By parsing the list of SegmentURLs in each representation, the client can easily determine that the URL is largely constant except for the segment index.

  Next, annotations such as the exemplary URI templates provided at 1005 and 1006 can be added to the parent Representation element (since there is at most one SegmentList per Representation). Thanks to this annotation (in the @templateURI attribute), clients that want to indicate one or more segments in the list as to be pushed need only copy and paste the @templateURI value into the specific push header. Will.

  To further simplify the use of the URI template for the client, it is possible to check which portions of the resulting @templateURIs 1005 and 1006 are different for one representation and the other. The reason is that in this example 1000, there are multiple representations within the same AdaptationSet. This in turn leads to the generation of another template attribute at the AdaptationSet level with multiple variables or changing parts (see 1007).

  Therefore, it is possible to gradually generalize the @templateURI attribute from one level to the next level. Thus, the generalization process can be repeated over one or more parent segments until the segmentURL value remains completely similar.

  With respect to the @templateURI annotation 1007, it is possible that a URI template happens to contain multiple variables or changes. In such a case, it is the client that decides in which order these changes must be considered for replacement with their respective assigned values. Thus, the client can associate each change portion with a priority level to cause the server to follow a predetermined order when the server considers these change portions.

  Optionally, in addition to the @templateURI attribute, an @templateValue attribute may also be provided to indicate a range of possible values for one or more variable portions of the @templateURI attribute. The range of possible values is determined based on the MPD, ie in the example of FIG. 10, based on the list of SegmentURLs.

  For example, in addition to annotations 1005 and 1006, the @templateValue attribute could be declared with each of annotations 1005 and 1006 to define the same value range: @templateValue = “{1-6}”.

  For @templateURI added to the AdaptationSet level, the @templateValue attribute will take the following values: @ templateValue = “low: hd; {1-6}”. The 'low' and 'hd' strings list possible values for the first variable “level” corresponding to the representation identifier, and the range {1-6} is the second variable “nb” corresponding to the segment index. List possible values for "".

  Returning to the syntax of the specific push header shown in FIG. 6b, one embodiment describes an RFC 6570 for the following grammar and URI template to represent one or more extraction patterns 653 when describing a specific push header: Is used.

A “push header” can be defined as follows:
push_request = “Push-Request:“ header_name ”;“ uri_template ^* (“;” definition)
header_name = “URI” | HeaderName

  HeaderName corresponds to a predetermined header name in the specifications of various HTTP versions.

  The uri_template parameter is a URI template that is defined in RFC 6570 with potential extensions. This template may contain variables or variable parts whose names are numbers, defined between curly braces. For example: / server / video {1}. mp4 is uri_template with one changing parameter, / server / {1} / image {2}. jpg is another uri_template with two changing parameters.

  The simplest case corresponds to a uri_template equal to {1} which means that the entire support should be replaced with the declared definition, ie the assigned value. Furthermore, uri_template without a declared variable means that the entire support 652 should be replaced by the uri_template value. For example, if support = “URI” and uri_template = “/ server / resource2.ext”, the URI for the resource proposed by the client is / server / resource2 without any further processing. . “ext”.

  The last optional parameter declares one or more assigned values. The first definition corresponds to one or more substitution values for the first variable of uri_template, the second definition corresponds to the second variable, and so on. There must be as many definition parameters (ie, sets of substitution values) as there are uri_template parameters (ie, extraction patterns).

Thus, such a “definition” includes one or more values and / or one or more lists and / or one or more ranges:
Definition = value | list | range where the value is the first possibility to represent the substitution value as a string of characters;
List = value | range ^* (“:” value | range) is the second possibility to represent the substitution value as a colon-separated list of values (or range of values). Note that the colon character is selected over the comma character because the comma character is conventionally used to separate several values for the same header.
Range = “{“ start ”−“ end ”}” is a third possibility to express the substitution value as a range. This should be interpreted as a list of all values between 'start' and 'end', including both 'start' and 'end'. This is only possible for values that are integers.

  The formatting of variable values in the definition parameters is the default. In order to prevent formatting problems with a range of values, the formatting of values within the range should follow the formatting of the start and end values, especially with respect to leading zeros. For example, if the range is specified as '{8-10}', the generated values are: '8, 9, 10'. If the range is specified as' {08-10} ', the generated value is: '08, 09, 10'.

  As briefly introduced above in connection with annotation 1007, a particular push header may include a URI template having two or more change parts (ie, variables). The order in which additional resources defined by a particular push header are pushed by the server depends directly on how two or more of its changes are considered (ie, expanded) sequentially by the server. Therefore, this order should be inferred from the specific push header.

An exemplary algorithm for extending variables in uri_template rules is as follows, assuming that an order of variables is provided:
1. Get list of uri_template-For the first variable extension (first in the order provided), the uri_template defined in the specific push header is used.
-For the next one or more variable extensions (in the order provided), the list of uri_template resulting from the extension of the preceding one or more variables is used.
2. Each uri_template in the resulting list is replaced with a list of uri_template obtained as follows:
-For each value of the variable considered in the extension step, the uri_template is duplicated and the variable in the URI template is replaced with one of the assigned values.

This is because in the final list of URIs (or header values), the first variable in that order (eg, defined by '1') changes most slowly, and the last (ie, the largest number) in that order Means that the variable changes most rapidly.

For example, the construction rule <'Push-Request: URI; {1}-{2}; a: b; 1: 2'> yields the following ordered list:
-'A-1'
-'A-2'
-'B-1'
-'B-2'

The construction rule <'PushRequest: URI; {2}-{1}; a: b; {1-3}'> yields the following ordered list:
-'A-1'
-'B-1'
-'A-2'
-'B-2'
-'A-3'
-'B-3'

  Alternatively, the processing and replacement order for multiple variables can be expressed as a specific operator. RFC 6570 reserves several characters for operator expansion. In one embodiment, the '@' character may be used to indicate the order: the greater the operator value, the greater the processing order. In this alternative embodiment, the above two examples are as follows:

Construction rule <Push-Request: URI; {foo @ 1}-{bar @ 2}; a: b; 1: 2>, “foo” and “bar” are values “a” and “b” in the following order: And variable names that are replaced by "1" and "2" respectively:
-'A-1'
-'A-2'
-'B-1'
-'B-2'

The construction rule <Push-Request: URI; {foo @ 2}-{bar @ 1}; a: b; {1-3}> will yield the following ordered list:
-'A-1'
-'B-1'
-'A-2'
-'B-2'
-'A-3'
-'B-3'

  Although the above example uses a single specific push header in the HTTP header, other embodiments can use more than one push header.

  For example, when a client is interested in several resources of various types and / or when it is too difficult to provide construction rules, it can be determined to use multiple instances of a particular push header.

  As an example, if it is desired to accelerate the download of a web page, the client can generate one push header for each type of sub-resource that makes up the web page: one for the image, One for the style sheet, one for the script code, etc.

  In such a situation, the value of each specific push header behaves like a filtering parameter that filters several types of sub-resources. Note that the main resource to which the sub-resource is referenced may be a resource explicitly requested by the HTTP request (ie, a request-URI resource).

  Having multiple instances of the push header will result in an additional list of URI / URLs, each instance defining a separate set of resources to push.

  In one other case that justifies multiple instances of a particular push header, the client wants to modify the parts from the various supports in the initial request, eg the request-URI part and the byte range value in the range header Or when indicating two different header modifications. In such a situation, the client can place two (or more) specific push headers, one for URI modification and the other for range modification. The processed header will result in one composite instance with a new URI and a new byte range associated with it.

  For multiple header modifications based on multiple push headers, each push header process generates a set of URI / headers corresponding to the corresponding substitution value, and the final list of resources is all possible combinations of the generated sets Note that by providing all possible combinations of substitution values for each URI / set of the header.

  In embodiments, a specific push header may be used for an alternative to the uri_template specification.

  When the uri_template parameter indicates a relative URI, the push header processor must construct an absolute URI taking into account the relative path from the original request-URI.

  However, in embodiments, the base URI or another base URI could be specified in another specific header or as a parameter in the Push-Request header. This can be useful, for example, in DASH where multiple BaseURLs are declared in the manifest. Therefore, if the client wants to push some resources, it can test the first server using the first base URL with a specific push header, and if no push commitment is received, it The base URL can be changed in the next request to test whether the second server supports that particular push header.

  An exemplary way of indicating a base URI change in a specific push header includes an additional parameter, “var_base”, set after the uri_template parameter. The var_base parameter declares a new base URI value.

For example, the request line of the HTTP request is GET / server1 / video / segment-1. mp4
If so, the specific push header may be: <Push-Request: URI; segment- {1}. mp4; {2-4}; var_base = / AnotherServer / video />

This construction rule generates the following list of additional resources:
http: // AnotherServer / video / segment-2. mp4
http: // AnotherServer / video / segment-3. mp4
http: // AnotherServer / video / segment-4. mp4

  Alternatively, instead of declaring the uri_template parameter using URI-template RFC 6570, a regular expression may be provided instead.

In embodiments that handle interoperability purposes, the specific push header is split into two separate headers:
The first indicates the resource that the client is interested in. This is the specific push header described above;
-The second indicates to the server that the client accepts the server push. This can be negotiated during connection setup, but for the client, when it can accept the pushed data and when there is a greater risk of canceling the push (e.g. the client switches frequently It would be beneficial to tell the server that it is (when experiencing a well-established video mode).

  This second header may also be useful for network intermediaries that do not support push (eg, in a CDN): they are still a hint for prefetching some resource close to the edge of the network with the first push header. Could be interpreted as

The specific push header of the present invention will help streaming clients to improve various DASH situations:
-For example, when the client wants to predict the next segment;
-Or when the client wants to find a time offset in the video;
-Or when the client trusts that the server will send the next segment in a given period of time;
-Or when the client expects to switch;
-Or when the client is interested in the associated resource;
Or alternatively when the client requests an unmultiplexed audio-video segment. In such cases, when requesting a video segment, it may indicate interest in the corresponding audio segment.

In another embodiment, the substitution value can be placed in other dedicated headers (“Push-Values” below), which results in the following set of headers (header names here are just examples) Will:
Push-Request: header_name “;” uri_template
Push-Values: definition [ ^* (“;” definition)]
For this alternative embodiment, Example 850 below would be rewritten as follows:
GET / server / video / Rep-R1 / segment-01. mp4
Push-Request: URI; segment- {1}. mp4;
Push-Values: 02:10
Further, Example 865 below would be as follows:
GET / server / video / Rep-R1 / segment-01. mp4
Push-Request: URI; Rep- {1} / segment- {2}. mp4
Push-Values: R1: R2; {01-03}

Alternatively, when more than one variable parameter is declared in the push specific header, the assigned value for each variable parameter may be declared in its own “Push-Values” header. In such a case, the “Push-Values” header should include a variable parameter name followed by a value or a list of values or a range of values. For example:
GET / server / video / Rep-R1 / segment-01. mp4
Push-Request: URI; Rep- {var1} / segment- {var2}. mp4
Push-Values: var1 = R1: R2
Push-Values: var2 = {01-03}

  Other exemplary rewrites can be easily inferred from the above rewrite example.

In another alternative, each portion of the push specific header shown in FIG. 6b may be placed in a corresponding separate header; for example (header names are just examples):
Push-Support: URI
Push-Pattern: segment- {var}. mp4
Push-Values: var = 0: 10

  In conjunction with FIGS. 7a, 7b and 8, an example of a specific push header for DASH using a URI template will now be described.

  Figures 7a and 7b provide an example of the use of the invention in the context of adaptive streaming over HTTP using the DASH standard. FIG. 7a is an example MPD 700 that includes a SegmentTemplate element 701 that indicates to the streaming client where each media segment should be downloaded (ie, a URI). The client can select one of two alternative video representations 702 and 703 depending on the desired or possible spatial resolution and bandwidth.

  FIG. 7b describes a client-server exchange assuming that the client and server communicate using HTTP / 2 when the present invention is implemented.

  The client 750 first requests an MPD and a streaming manifest from the server 751 via an HTTP GET request in step 752. In step 753, the server sends an HTTP response to return the MPD file to the client.

  Upon receiving the MPD, the client parses it at step 754 to identify initialization information for setting up its media decoder.

  Next, in step 755, the client sends another HTTP GET request to obtain this initialization segment. The server provides the requested initialization segment file in the HTTP response. This is step 756.

  During or in succession (step 757), the client identifies an appropriate representation according to its preference / characteristics. This step is not only the first media segment the client needs to start reading the video, but the next segment to download to continue reading the video, usually (if no representation switch decision is made) Allows to identify subsequent media segments from the same representation. The client can infer one or more URIs for this / these subsequent one or more segments using the manifest.

  Next, at step 758, the client requests the first media segment from the server to begin displaying the video.

  Using the present invention, the client inserts in request 758 one or more URIs for the next media segment to be downloaded. This insertion is performed in a dedicated HTTP push header (eg, “Push-Request” header in request 758). An example value for this particular HTTP header is provided below in connection with FIG.

  In response to request 758, a server that supports the present invention and thus understands the specific push header can inform the client that it understands the push header and it (the server) pushes data to the client. Announce to lead. This is the purpose of the PUSH PROMISE frame 759 sent by the server that provides the server start stream identifier to the client.

  The server further sends the requested first segment, which is the purpose of the GET request, in one or more DATA frames 760 along with the stream identifier of the GET request 758 as a stream identifier.

  Finally, in conjunction with the server start stream identifier exchanged in step 759, the server pushes data corresponding to the media segment indicated in the specific header of request 758 through one or more DATA frames 761. .

  In certain embodiments, the server requests a push request from a client, i.e., a request to push specified additional resources, a request to use a specified push policy, strategy, or directive, or an additional request. Confirm receipt of a request that does not push the resource. Such an acknowledgment may be sent in the HTTP header of the push commitment message. It allows the DASH response header processor 386 to inform the DASH control engine 313 of the push policy used by the server.

  FIGS. 11a to 11e allow server 1101 and client 1100 to confirm receipt of a push policy received from client 1100 and inform the latter of the push policy that it is trying to apply or can apply. Some examples of push policy management during These examples are based on adaptive streaming over HTTP, such as MPEG DASH (streaming manifest based method).

  FIG. 11a shows the transmission by the client 1100 of the push policy indication in the initial request 1102 for the streaming manifest (MPD in the case of DASH). As mentioned above, this indication can be conveyed via a dedicated HTTP push header.

  Upon receipt, server 1101 processes the request at step 1103, ie, the server identifies a resource (MPD) to be provided to client 1100. Next, server 1101 prepares its response with a return code for the first request with reference number 1102 at step 1104. Thus, if the requested resource is available, the return code is the HTTP code 200.

  In parallel, the server 1101 processes the push policy instruction included in the dedicated HTTP push header. If the server understands this header and can process the proposed push policy, it confirms receipt of the proposed push policy by the client. This can be done by adding acknowledgment data to the response of reference number 1104, eg by adding the same dedicated HTTP push header having the same policy value as the request of reference number 1102 (in such a case, push confirmation Response data is the same as push policy data).

  This indicates to the client that the server is willing to use the proposed push policy.

  Thus, in such a case, after confirming the push policy in response to reference number 1104, the server begins to announce additional data that it is about to push to the client. This can be done, for example, by using a PUSH_PROMISE frame from HTTP / 2 (one PUSH_PROMISE frame per segment for DASH).

  It should be noted that on a standards basis, the server preferably includes the data requested by the client in the request with reference number 1102 (ie, the MPD file) in its reference number 1104 response.

  At the same time as the HTTP response so generated with reference number 1104 is sent back to the client in step 1105 and processed by the client, the server sends the data stream used to send the announced additional data to the client. Start preparing (step 1106) (typically in HTTP / 2 one data frame per promised resource, ie one segment in the case of DASH).

  Finally, the client starts receiving the first segment for media presentation during step 1107 and simultaneously processes the MPD sent in response to the request with reference number 1102, thus saving network traffic and transmission delay Make it smaller.

  Instead, it should be noted that the acknowledgment data sent by the server may be signaled through another dedicated HTTP push header having a simple value such as “OK”.

  For a server implementing an embodiment of the present invention, it may be recommended to confirm receipt of a push policy proposed by a client when the server supports it and applies it. In fact, this is appropriate information for the client to easily decide whether to accept the PUSH_PROMISE frame sent by the server.

  After this first round trip between the client and server, the client requests to continue streaming the media presentation, for example using a request for the next segment of the segment pushed during steps 1106 and 1107. (Step 1108). Within this request, the client can verify that it maintains the same push policy by adding a dedicated HTTP push header with the same push policy indication as the previous request to the request with reference number 1108. .

  At the server end, the processing of the received request (step 1109) confirms whether or not the requested resource is available (for example, HTTP status code 200OK) and applies itself using a dedicated HTTP push header. Result in a response confirming the push policy that is being sent, and an announcement of additional data to be pushed and transmission of the requested segment data (the actual push of data is not represented but follows response 1109).

  FIG. 11b shows an example of an acknowledgment of a push policy notification, whereby the server informs the client that it cannot execute the push policy proposed by the client.

  If the server does not support the push policy indication proposed by the client, it can simply ignore it.

  However, it may be beneficial for the server to alert the client that it does not use any push policy. This is useful information for clients to schedule their future requests. In fact, the client will have to request all segments in turn.

  For that purpose, the server is described with a specific push directive indicating that no push will take place, for example a push policy without a value of type “push-none” (or as reference number 1231 in FIG. 12b). Can be used).

  As shown, the first step is directed to the client 1100 sending a push policy indication in the first request 1111 for the streaming manifest (MPD in the case of DASH). As described above, this indication can be conveyed via a dedicated HTTP push header.

  Upon receipt, server 1101 processes the request at step 1112, ie, the server identifies a resource (MPD) to be provided to client 1100. Next, the server 1101 prepares its own response with a return code for the first request with the reference number 1102 in step 1113. Thus, if the requested resource is available, the return code is the HTTP code 200.

  In this example, it is assumed that server 1101 cannot execute the push policy proposed by the client, thus indicating that server 1101 does not use the proposed push policy for the client. This can be done by using a specific push directive that indicates that no push is performed (reference numeral 1113) as shown in FIG. 11b.

  Upon receiving such information (step 1114), client 1100 knows that all segments must be requested from step 1115 one by one.

  Optionally, it expects the resource to be pushed from the server by setting the same “no push” policy indication in its own request in the dedicated HTTP push header (as indicated by 1115). You can confirm that you have not.

  Next, the server 1101 processes the request received at step 1116 and responds to the request by confirming the “no push” policy and transmitting data corresponding to the request at step 1117. These two steps are repeated until the end of the streaming session.

  Instead, the server could use another dedicated HTTP push header with a reserved information code (eg, 103, informing the client of “unsupported push policy mode”).

  Note that instead, the client can indicate its push policy through the HTTP Expect header, in which case the server will either indicate a 417 code for “expected fail” or, more clearly, the client wants Will show reserved 4xx code dedicated to the server not supporting push mode.

  In another embodiment, a client implementing an embodiment of the present invention does not know whether a server supports the present invention. If the client decides to maintain full control and sends a “no push” push policy to the server, no acknowledgment is sent back because the server does not understand the header.

  In another embodiment where the server implements the present invention, but the client does not support it, a server that does not receive a dedicated HTTP push header in the client's request is “no push” to alert the client that nothing will be pushed. A policy indication can be used to acknowledge (because the server does not know whether the client supports the present invention or simply forgot to indicate its own preference). By doing so, the server does not take the risk of sending useless data.

The purpose of such a specific “no push” policy can be used in particular to indicate:
-The client is not interested in pushing; or-The client wants to interrupt the push for some requests.

  This provides more satisfactory control than the existing SETTINGS_ENABLE_PUSH setting parameter defined by HTTP / 2, which can be used by the client to indicate to the server whether server push usage is allowed. This setting parameter does not provide a fine-grained negotiation or control mechanism for server push. In fact, it would be beneficial for clients and servers to have such negotiation means. For example, the value of the SETTINGS_ENABLE_PUSH setting parameter allows the server to use server push, but the client may want to prohibit server push for some or all requests in the streaming session. For example, this can be beneficial for a client when loading a web page that embeds a video element. The client may be interested in having the resources (CSS, images, JavaScript) associated with the web page pushed instead of the media segment. In such a case, data can be pushed across the connection except for specific DASH content, and the client will indicate to the media server that it chooses no data push.

  FIG. 11c shows an example of confirming receipt of a push policy notification, in which the client proposes several push policies in the initial request for the streaming manifest. In other words, instead of proposing a single push policy as described in connection with FIGS. 11a and 11b, the client sends a list of push policies it supports.

  As shown, the first step is directed to the client 1100 sending a list of push policies it supports in the first request 1119 to the streaming manifest (MPD in the case of DASH). Such a list is preferably an ordered list (preferred order, not represented in FIG. 11c).

  To that end, a dedicated HTTP push header is created that conveys the type of policy and any parameters for the order of preference. For example, the dedicated HTTP push header is defined as an “Accept-Push-Policy” HTTP header similar to the existing Accept HTTP header (https://tools.ietf.org/html/rfc7231#section-5.3.2). See).

The Accept header has a given media-type:
0 ^* (zero or more) pieces of specific media-type parameters (for example: charset); This example, ^request: *. jpg, ^* . Can be a list of media types supported by the client issuing png 0-1 "q" parameters (to indicate relative weight)
0 ^* extended parameters ("q" parameter is required as a separator if extended parameters exist)
Allow to have.

This is for a dedicated HTTP push header:
Accept-Push-Policy: <urn>[':'<urn-specific-param> ^* ]; q = <N>
This “q” parameter is mandatory if any global parameter exists.

  The “q” parameter indicates one or more policy parameters, <urn-specific-param> in the above expression, if present, by the policy type (<urn> in the above expression). Q factor to be separated from

  The Q factor allows a user or user agent to indicate a relative priority for a policy type and / or policy value using a q-value scale from 0 to 1. The default value is q = 1 (greater Q factor or preferred).

For illustration purposes, the client notifies the following in the push header:
Accept-Push-Policy: urn: mpeg: dash: fdh: push-next; 5
Can ask the server to push the next 5 segments following one requested segment, where the first part, URN, uniquely identifies the type of push directive or push policy to use To be specific. The second parameter (optional) following the ';' separator corresponds to the parameter applied in this push policy.

  Alternatively, other separators between policy type and value parameters can be used as separators in HTTP header values (see RFC 2616).

An alternative embodiment that allows the client to show an ordered list of push policies according to their preferences is, for example, in a live scenario, if the server has several next segments, if they are ready on the server Using the “q” parameter to indicate to the server to immediately push, preferably 3 segments, otherwise 5 segments (standard push policy registered according to reference number 1230 in FIG. 12b); It can be expressed as:
Accept-Push-Policy: urn: mpeg: dash: fdh: push-next;
urn: mpeg: dash: fdh: push-next; 5; q = 0.5

Using the quality level as the order of preference, allows for a fast start of the video (ie, pushing the initialization and first video segment from the MPD request) (here from the owner's push policy, in some cases FIG. 12b). As another example where a client presents a push policy (which is also registered according to 1230), an ordered list of push policies can be expressed as:
Accept-Push-Policy: urn: canon: dash: fdh: push-fast-start; high,
urn: canon: dash: fdh: push-fast-start; mid; q = 0.7
urn: canon: dash: fdh: push-fast-start; low; q = 0.3
Or choose the resolution:
Accept-Push-Policy: urn: canon: dash: fdh: push-fast-start; HD,
urn: canon: dash: fdh: push-fast-start; SD; q = 0.7

  To indicate that the client pushes various data to the server, it can place in the request instructions for two different push policies with the same value for q. This should be interpreted by the server as two policies to be applied in response to the request.

  If the server can apply both, it confirms receipt of the client by placing these two push policies with the same q value in its response, in a dedicated HTTP push header. .

  However, if only one of the two can be applied, it confirms that the client's proposal has been received with a push policy that is used as the value for the dedicated HTTP push header.

  If neither of the two proposed push policies can be applied, the server can identify the identifier of the no-push policy (eg, the registered value 1231, or any push specifically defined for this purpose). Confirm that the client's proposal has been received by adding the policy type) into the dedicated HTTP push header.

  Returning to FIG. 11c, the server 1101 processes the received request 1119, which may be directed to a rapid start, at step 1120.

  In response to the request, server 1101 prepares its response with a return code for the first request at step 1121. Therefore, if the requested resource is available, the return code is the HTTP code 200.

  In addition, the server 1101 may use the same Accept-Push-Policy dedicated HTTP push header in some cases, rethinking the order to suit its preference (in such a case, the first By using a separate dedicated HTTP push header that only conveys the actual push policy used by itself in the list, or Approve one of the push policies proposed by the client 1100.

  For example, such a dedicated HTTP push header may be “DASH-PUSH”: urn: canon: dash: fdh: push-fast-start; low (where the header name (“DASH-PUSH”) is an example) Or only the type of policy without providing the exact value of the parameter, eg “DASH-PUSH”: urn: canon: dash: fdh: push-fast-start, (in this case the server To select the version of the media to push.

  Such acknowledgment data is received by client 1100 at step 1122.

  In parallel, server 1101 begins preparing a data stream that is used to send the announced additional data to the client (step 1123) and sends the corresponding data.

  The next request sent by client 1100 after receipt of the pushed data (step 1124) may again include push policy indications, such as preferred approved by the server.

  If the server 1101 does not support any of the proposed push policies received in the MPD request (step 1120), it sets the client's proposal by setting the dedicated HTTP push header to the “no push” policy. Receipt can be confirmed (eg, registered URN, urn: mpeg: dash: fdh: push-none, or any push policy type specifically defined for that purpose, with reference number 1231 in FIG. 12b) , Through).

  FIG. 11d shows an example of confirming receipt of a push policy notification, in which the client proposes a “no push” policy in the first request for the streaming manifest. In other words, FIG. 11d shows the case where the client initially wants to maintain control over the representation selection.

  As shown, the first step is directed to the client 1100 sending a “no push” policy indication in the first request 1131 for the streaming manifest (MPD in the case of DASH).

  Thus, the initial request 1131 clearly indicates that the client does not want to push anything to the server. For purposes of illustration, such a “no push” policy, as registered at reference number 1230 in FIG. 12b, may be: urn: mpeg: dash: fdh: push-none.

  Such an example corresponds to the case where the client is not interested in a quick start at the beginning of the session and thus prevents pushes from the server (by default, the HTTP / 2 server does not do anything appropriate to the client Can lead a push with the risk of sending to)).

  As shown in FIG. 11 d, the server 1101 confirms this no-push policy with its own response with the reference number 1133.

  To request a segment, the client analyzes its MPD to better know what it is trying to ask (step 1134) and, as a result of the analysis, the server can submit one or several push policies. (Step 1135).

  In response, server 1101 checks the push policy as described in connection with FIG. 11a or 11c to push the promised data (not represented).

  Of course, the push policy for rapid start of the streaming session can also be used for other purposes. For example, the client indicates a push policy upon MPD request (step 1131), and then the server confirms positively or negatively (as described previously in connection with FIG. 11a or 11c) and eventually , Promises to push the first segment to the client. Next, for successive requests for a segment, the client either makes itself trusted by the server by indicating its preferred push policy, or by using a specific “no push” policy You can decide if you want to maintain full control over the transmission.

  Whatever push policy is indicated by the client, if the server cannot process the push policy proposed by the client and / or does not process the corresponding specific HTTP header (eg test 604 in FIG. 6a is false) It should be noted that it cannot send any kind of acknowledgment, so it will simply ignore the hint from the client.

  Conversely, a DASH server that is configured to process a push policy (or directive) proposed by the client and decides to apply it, push parameter (if any) with an acceptable parameter value in its response. The client request should be confirmed by using the (or directive) URN. If the client indicates multiple push policies and the server supports one of the push policy lists proposed by the client, the push policy that it is trying to use is the URN of the applied push policy Should be confirmed by placing in a dedicated HTTP push header.

  Optionally, as described below and shown in FIG. 11e, the server may advertise the list of alternative push policies it performs in various ways.

  If the server does not support the push policy proposed by the client, it should inform the client using the URL for the “no push” strategy, ie urn: mpeg: dash: fdh: push-none. In addition to acknowledgment with a “no push” policy, it can publish one push policy or a list of push policies that it supports in another dedicated HTTP push header. In order to eliminate ambiguity from the acknowledgment response, the server preferably uses another dedicated HTTP push header. It can use the syntax given in the Accept-Push-Policy header depending on whether it publishes one push policy or a list of push policies.

  When a push policy is addressed to a non-push capable server (ie a server that does not understand any push policy from any client, eg test 604 in FIG. 6a is false) It should be noted that push policy promotions may also not be signaled to the client.

  To help the client propose a push policy, the server can send a list of push policies it supports to the client. This can be done in several ways.

  For example, the list of push policies supported by the server can be determined when creating content in the MPD and can be added to the latter as one or several DASH descriptors. They provide indications of push policies that are supported by the origin server or by a server in the Content Delivery Network.

  This can also be done by network intermediary if they are DASH aware.

  Such a descriptor may be identified by a specific scheme_id_uri attribute (eg, “urn: mpeg: dash: fdh: pushDirective”). The value attribute for such a descriptor includes the type of push policy (eg: “urn: mpeg: dash: fdh: push-next” or “urn: mpeg: dash: fdh: push-none”).

  Optionally, other attributes (eg, param) may include policy parameters such as the number of next segments to push. This would be written as follows: <SupplementalProperty scheme_id_uri = “urn: mpeg: dash: fdh: pushDirective” value = “urn: mpeg: dash: fdh: push-next” 5 ”. The values for scheme_id_uri and value attributes are assumed to be defined by the DASH standard or by at least a registration authority as at 1230. This may be, for example, IANA with DASH through the scheme_id_uris, DASH industry forum, or related guidelines on client and server behavior utilizing the corresponding push strategy.

  In another example, a specific HTTP header field, such as “Supported-Push-Policies”, may be used to describe a push policy supported by the server. In the basic implementation, the value of this header field is a comma separated list of supported push policy identifiers.

Such a specific HTTP header field can be, for example:
Supported-Push-Policies: urn: dash: adobe: k-push, urn: dash: canon: fast-start

  In richer implementations, the parameter values supported for each policy could be described as a “,” separate list, or range.

Such a specific HTTP header field can be, for example (using ';' as a separator between the policy type and its parameters):
Supported-Push-Policies: urn: dash: adobe: k-push; 0-100, urn: dash: canon: fast-start; low: medium

  The server could also indicate its own preference for each policy by adding a “q” parameter for each policy.

Such a specific HTTP header field can be, for example:
Supported-Push-Policies: urn: dash: adobe: k-push; 0-100; q = 0.4, urn: dash: canon: fast-start; low: medium; q = 0.9

  In application code, such as a web page, an HTML meta tag could list several policies that a client can use to improve transmission.

Such HTML meta tags can be, for example:
_{<Meta name = << dash: fdh} : pushDirective >> content = << urn: one_push_directive_ID >>/>
The new “dash: fdh: pushDirective” value allowed for the name attribute here is the existing extension list: https: // wiki. whatwg. could be registered with org / wiki / MetaExtensions . Such registration allows a web client to be informed that the application server considers a strategy for optimizing media delivery and that the media is embedded in the web page, for example as a <video> element. The value placed in the content attribute can be one of the registered values of reference number 1230 in FIG. 12b.

  FIG. 8 provides various examples of push headers for the case of adaptive streaming with DASH. The media (video) is available as two separate representations R1 810 and R2 820, both of which include video segments 811 and 821 that are temporally aligned.

  The first example 830 shows a client request for the first segment of the representation R1. This request also indicates through the push header “Push-Request” that the client is interested in segment number 2 as a future segment. To do so, the push specific header is sent by the server in a request-URI curly bracketed pattern (indicated by the first parameter of the header: “URI”), ie the string “01” in the request-URI, Indicates that it should be modified using the value provided in the last parameter (“02” in Example 830). One alternative would have been to show replacement rules via regular expressions such as Push-Request: URI;-\ (\ d \ + \),-\ (% 02d: \ 1 + 1 \).

  The second example 840 shows a client request for the first segment of the representation R1. This request also indicates through the push header “Push-Request” that the client is interested in segment numbers 02, 03, 04 and 05 as future segments. This list of future segments is represented here as a range for purposes of compactness and simplicity. Again, the pattern between the curly braces is repeatedly overridden by the value set in the provided range in the first request-URI to build the corresponding list of four URLs. There must be.

A third example 850 shows a client request for the first segment of the representation R1. This request also indicates through the push header “Push-Request” that the client is interested in segment numbers 02 and 10 as future segments. Interest in segment numbers will allow clients to browse videos on the fly. The assigned values are then given as a list of values separated by colons. If the client was interested in more segments (numbers 02 to 04 and 10 to 13), these could have been signaled through the list of ranges as follows:
Push-Request: segment- {1}. mp4; {02-04}: {10-13}

  The fourth example 860 shows a client request for the first segment of the representation R1. This request also indicates through the push header “Push-Request” that the client is interested in the segment number 01 in the representation R2 as a future segment. This can be beneficial for scalable video when the representation R2 is an enhanced version of the base version R1. This example shows the changes in multiple patterns in the request-URI indicated by the presence of two patterns (between the curly braces) that are assigned to the request-URI.

  The fifth example 865 shows a client request for the first segment of the representation R1. This request is also sent through the push header “Push-Request” to the client as the future segment, first in segment number 01 of representation R2, both in representation R1, and then in segment 02 of R2, and finally Shows interest in segment 03 of both representations “R1” and “R2”. This is indicated by the presence of two patterns (between curly braces) that each indicate the order of substitution. In this example, representation identifiers having a first set of values “R1” and “R2” are considered first, and then segment indices having values in the range including 01 to 03 are considered.

  For the special case of repeating over multiple parameters (two representation segments 01 to 03), the first segment of the representation R1 is provided twice (once as the requested first segment- Note that see request-URI; and once as data to be pushed). Thus, the server can filter the resulting list of URLs to delete the URL corresponding to the first request-URI.

  The sixth example 870 and the seventh example 880 illustrate the use of headers when media segments are addressed through byte ranges, for example in MPD the media segments are as SegmentBase elements containing SegmentURLs that provide the byte range of those segments. Described.

  Example 870 shows a client range request for the first byte of representation R1. This request is also via the push header “Push-Request” where the client is interested in the byte range starting from the 2001 byte offset in the “Rep-R1.mp4” file and ending at the 3000 byte offset as a future part of the resource. Indicates that

  A seventh example 880 shows a client range request for the first byte of the representation R1. This request is also sent via the push header “Push-Request” as the future part of the resource by the client in the byte range in the “Rep-R1.mp4” file, initially including the byte range 2001 to 3000, then 3001. Indicates that you are interested in the list of byte ranges from to 4000.

  The eighth and final example 890 of FIG. 8 shows a client request for an initialization segment. This request also indicates through the push header “Push-Request” that the client is interested in a given segment as a future segment: where there is no pattern identification or assignment value, An explicit absolute URI is provided.

  The above description focuses mainly on specific push headers that define specific resources to be pushed, possibly through construction rules.

  In some embodiments where the server includes a static configuration file that maps resource types to resource folders, the client can use specific push headers to filter the resources that the client is interested in. Such filtering can be performed, for example, during step 606 above.

  This filtering approach may be beneficial when the client indicates a resource type rather than a specific resource in a specific push header, or at least rules that specify these specific resources.

  Alternatives exist, such as the use of a unique identifier (eg, URN) that specifically specifies a push policy or push directive, as described in connection with FIGS. 12a and 12b.

  FIG. 12a shows the transmission by the client 1200 of a push policy indication in the initial request 1201 to the streaming manifest (MPD in the case of DASH), which is a unique identifier associated with that push policy. As described above, this indication can be conveyed via a dedicated HTTP push header.

  Upon receipt, server 1210 processes the request at step 1203, i.e., the server identifies a resource (MPD) to be provided to client 1200. The server 1210 then prepares its response with a return code for the initial request. Therefore, if the requested resource is available, the return code is the HTTP code 200.

  In parallel, the server 1210 identifies the proposed push policy as a function of the unique identifier contained in the dedicated HTTP push header. If the server can understand the header and can process the proposed push policy, it then confirms receipt of the proposed push policy by the client. This can be done by adding that unique identifier to the response 1204.

  This indicates to the client that the server is willing to use the proposed push policy.

  The unique identifier associated with the push policy may be defined in a centralized registry, such as the centralized registry 1230 shown in FIG. 12b. URN allows for the unique identification of push policies (or directives). When push policies (or directives) require parameters, these must be defined in the specification linked from the above registry so that the push policy is specified.

  If no central registry is defined, the dedicated HTTP push header can convey the type of push policy (eg, push the number of segments to be pushed, the duration that the segments should be pushed, or MPD updates) Instructions for).

For illustration purposes, the types of push policies that can be conveyed in a dedicated HTTP push header can be as follows ("Push-Request" is the name of the dedicated HTTP push header in this example):
Push-Request: push-next
Push-Request: push-time
Push-Request: fast-start
Push-Request: mpd-update

Optionally, a dedicated HTTP push header can convey the type of push policy and parameters for the proposed push policy (eg, number of segments and duration to push (in seconds)). Thus, the type of push policy that can be conveyed in a dedicated HTTP push header and the associated parameter can be as follows (here using ';' as a separator between the policy type and the parameter): :
Push-Request: push-next; 5
Push-Request: push-time; 2
Push-Request: fast-start; 2
Push-Request: mpd-update; patch
Push-Request: push-next;

More generally, dedicated HTTP push headers are:
Push-Request: URN ^* [';'<urn-specific-params>]
Can be expressed as

  The last example is specific and aims to show the server to keep pushing all the next from a given segment (ie a kind of switch from client to server driven mode).

For some policy types that are associated with a small number of possible values, the type and parameter must be one URN, eg:
urn: mpeg: dash: fdh: 2015: push-next- ^*
Or urn: mpeg: dash: fdh: 2015: push-time-2
It should be noted that it may be advantageous to register as

  Certain embodiments give the client the option of clearly expressing their wishes for the data that the client pushes to propose a push policy as a function of the type of data to push. Thus, as shown in the centralized registry 1230 of FIG. 12b, the user can define a set for the push strategy associated with the segment and another set for the push strategy associated with the MPD update. .

  Such an embodiment may prove beneficial for having a specific MPD update push policy because the client automates the update process. In fact, proposing and approving to push MPD updates makes it possible to avoid adding a special metadata box to the media segment to indicate the MPD expiration date (typically the MPD is updated). Sometimes done by the server).

  For example, a push policy for an MPD update approved at some point during a streaming session will inform the client that the server has promised to push the MPD update.

  In addition, with different types of MPD update policies, the client can either retransmit the entire MPD (eg, with URN: urn: mpeg: dash: fdh: push-mpd-full) or just the patch ( urn: mpeg: dash: fdh: push-mpd-patch). Instead, only one push policy can be defined for the MPD update, and the whole mode or patch mode is a parameter.

  Figures 11a to 11e illustrate the use of these two types of push policies. As described in connection with FIGS. 11a through 11e, the client first requests an MPD. In the meantime, it can indicate whether we are interested in pushing both MPD updates and segments, or just one of these two types of data. Similarly, when preparing a request for a segment, it can indicate interest in both MPD updates and segments, or interest in only one of these two types of data.

  In fact, the use of MPD specific policies should be allowed in requests for segments to indicate hope for MPD updates at any point in time. Similarly, using a segment-related push policy when requesting an MPD allows a client to have a fast-start streaming session.

It should be noted that although the examples given for streaming applications are based on the HTTP / 2 protocol for illustration, other bi-directional protocols such as WebSocket can also be used. In particular, the dedicated HTTP push header can be replaced in the binding for WebSockets as follows:
-URL: Indicates the URL of the requested resource. The corresponding JSON parameter is “url”.
-PushDirective: indicates the PushDirect URN selected by the client and has the JSON name "PushDirective".
-Any pushParams that are unique to pushDirective and indicate a value defined by pushDirective.

  Similarly, the acknowledgment mechanism can use JSON parameters in some dedicated WebSocket frames.

For example, the server can host data in various folders. Then, assuming that 'path' is the path on the server to reach the main resource, 'path / image' will contain the image resource, 'path / code' is a code, eg a javascript code, Will contain, 'path / style' will contain css resources, and so on. In this context, the specific push whether the client wants all types of images declared on the web page (image / ^* ) or all images of a given type (image / ^*. Jpg) When indicated in the header, the configuration file on the server should list a list of images that can be pushed for any resource directory.

  The web page may be the data being requested in the request-URI of the request. In one variation, the web page may be identified using another optional header in the request.

With a filtering approach, the present invention provides a method for transmitting data between a server device and a client device, which method at the server device:
Receiving an HTTP request for obtaining first data from a client device, wherein the HTTP request includes a first optional header field including one or more filtering parameters;
Retrieving the first data and sending it to the client device; and if the first optional header field is present in the HTTP request:
Identifying a set of data using the main resource obtained from the HTTP request;
Filtering each identified set of data using one or more filtering parameters to obtain a list of second data; and pushing the second data to the client device;
including.

From a client point of view, the present invention provides a method for transmitting data between a server device and a client device, the method at the client device:
Generating an HTTP request to obtain first data, wherein the HTTP request includes a first optional header field that includes one or more filtering parameters;
Obtaining the first data and sending the HTTP request to the server device to cause the server device to push the second data referenced in the main resource estimated from the HTTP request according to the filtering parameters;
including.

  Some examples of the use of push specific headers as a filtering approach will now be described.

The first example is the loading of web pages when the client wants to show the server a prioritized list of subresources to be pushed according to their type, eg jss and css and then html and img For loading, related to. The web resource, called the main resource, is the requested one defined in the request-URI of the request. A specific push header can be defined as follows:
Push-Request: application / javascript; q = 1, text / css; q = 0.8, text / html; q = 0.7, image / png; q = 0.6, image / ^* ; q = 0. 4

  This wants a set of resources (eg sub-resources declared in the main resource) that the client should be pushed according to their type (eg their MIME type, content type, format type or codec type) This is an instruction to the server.

  Here, a priority level is provided for each resource type using the 'q' parameter in a manner similar to the 'q' parameter in the Accept header indicating the relative degree of preference by the client. Note that q = 0 allows some resource types to be excluded from being pushed by the server.

  In this example, the priority 'q' allows to define the preferred order or version (eg, depending on the preferred resolution) of the clients that the sub-resource should be pushed by the server. As a result, the server must filter sub-resources to provide an ordered list of pushed data.

The second example relates to loading an image for a web page, where the web page is not the requested data as defined in the request-URI of the request. In such a situation, the support part of the specific push header explicitly indicates the HTTP “Referer” header. This is an instruction to the server that the additional resource desired by the client is a sub-resource of the main resource indicated by the value of the Referer header. Optionally, the header below is. Use the priority for images in the png image format to cause all images on the web page shown in the “Referer” HTTP header to be loaded:
Push-Request: Referer; image / png; q = 0.6, image / ^* ; q = 0.4
Referer: the_url_to-web-page

A third example relates to DASH streaming, particularly MPD loading and rapid start. The push header can be: MPD is the requested data as defined in the request-URI of the request:
Push-Request: video / mp4; q = 1, video / webm; q = 0.4

This indicates the client's preference to start with a media segment having a “video / mp4” MIME type rather than a segment having a “video / webm” MIME type. An equivalent example is:
Push-Request: URI; video. {1}; {video / ^* . mp4; q = 1, video / webm; q = 0.4}
Can be written.

  In the above example, based on the URI for the main resource, ie MPD, the server can infer all video segments in mp4 format to push to the client. For this wildcard substitution value, it is the server's duty to determine the list of segments to push, for example based on static configuration information for a given manifest or from MPD analysis.

  More generally, this means that, for example, a client that downloads a piece of javascript code or a CSS subresource wants to also get the subresource that is referenced in the javascript code and CSS subresource respectively for the same request. This can be useful when declaring this in a web page and showing it to the server.

The fourth example relates to video streaming, more specifically seeking in byte range units. If a media content subpart is requested using a SegmentBase URL and byte range in an HTTP request, the next push header in that same request will be pushed in byte range [1400-4000] and then lower priority Allows to push the byte range [4000-6000]:
Push-Request: Range; {1}; [1400-4000]; q = 1: [4000-6000]; q = 0.8

The fifth example describes a set of resources to be pushed as related to the main resource, ie the manifest, for the DASH application. This is indicated through the support part of the specific push header with the value “Referer”. The pattern portion indicates a set of video resources, and the wildcard substitution value indicates a filtering rule based on the type of video segment, here mp4:
Push-Request: Referer; video. {1}; video / ^* . mp4
Referer: the_url_to-MPD

  This allows the client to use wildcard values in specific push headers.

  Although the Referer header is optional, in the case of an intelligent server (MPD aware), its value is the set of segments (more generally (sub-) resources) the server has pointed to by the client. Can help to filter.

  FIG. 9 is a schematic diagram of a device according to embodiments. This device may be a server, client or proxy. The device includes a RAM memory 902 that can be used as a working memory for a control unit 901 configured to perform methods according to embodiments. For example, the control unit may be configured to execute instructions of a computer program loaded from ROM memory 903. The program can also be loaded from the hard drive 906.

  The device also includes a network interface 904, which can be a single network interface, or includes a set of network interfaces (eg, several wireless interfaces, or several types of wired or wireless interfaces). The device can include a user interface 905 for displaying information to the user and receiving input from the user.

  The device may also include an input / output module 907 for receiving data from and / or sending data to the external device.

  While the invention has been illustrated in detail in the drawings and described in detail above, such illustration and description are to be considered illustrative or exemplary and not restrictive; The invention is not limited to the disclosed embodiments. Other modifications to the disclosed embodiments can be understood and implemented by those skilled in the art from consideration of the drawings, specification, and appended claims in practicing the claimed invention.

  Such modifications may be derived, inter alia, from the combination of embodiments set forth in the summary of the invention and / or the appended claims.

  In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that various features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be used to advantage. Any reference signs in the claims should not be construed as limiting the scope of the invention.

Claims (29)

A method for transmitting data between a server device and a client device, the method comprising:
Receiving an HTTP request for obtaining first data from the client device, wherein the HTTP request includes first data specifying information that enables the first data on the server device to be specified; Said receiving step including one or more additional header fields containing instructions related to pushing;
Retrieving the first data and sending it to the client device;
Sending acknowledgment data representative of the indication associated with pushing second data to the client device; and using only the one or more header fields and possibly further the first data identification information. Determining second data identification information that enables identification of the second data on the server device;
Including a method. Sending a push commitment message to the client device that announces the push of the second data and / or pushing the second data to the client device;
The method of claim 1, further comprising:   The method of claim 1, wherein the acknowledgment data represents an instruction to push the second data.   The method of claim 1, wherein the instructions associated with pushing second data include a list including at least two different instructions associated with pushing second data.   The acknowledgment data includes one of the at least two different instructions associated with pushing second data, and the acknowledgment data includes the one of the at least two different instructions associated with pushing second data. The method of claim 4, wherein one is used to identify the second data to be pushed to the client device.   The instruction associated with pushing second data is associated with a data type of the second data, the data type including a descriptive data type or a content data type, and the second data is in or described in the content data The method of claim 1, belonging to data.   The acknowledgment data includes instructions associated with pushing second data, and the instructions associated with pushing second data within the acknowledgment data push second data within the HTTP request. The method of claim 1, wherein the method is different from the instructions related to doing.   The indication related to pushing second data includes at least one unique identifier, the at least one unique identifier being a directive for pushing second data and an identifier of the second data to be pushed. The method of claim 1, wherein the method represents a directive or represents a directive not to push the second data.   The method of claim 1, wherein the one or more additional header fields are one or more optional header fields.   The method of claim 1, wherein the first and second data identification information includes first and second uniform resource identifiers, URIs, respectively.   The method of claim 10, wherein the one or more optional header fields include at least one construction rule that generates the second URI from the content of the HTTP request.   The one or more optional header fields include change part information and substitution information, the change part information identifying at least one change subpart in a reference URI, wherein the substitution information is one or more of the second ones. The method of claim 10, comprising at least one substitution value that replaces the change subpart identified in the reference URI to define a URI of the reference URI. The first data specifying information includes a first uniform resource identifier, URI that specifies a main resource on the server device, and subpart information that defines a subpart of the main resource as the first data. And the optional header field includes substitution subpart information that replaces the subpart information in the first data identification information to define the second data identification information;
The method of claim 11.   The method of claim 13, wherein the sub-part information includes a range value of bytes in the main resource.   The one or more optional header fields include change part information and substitution information, the change part information identifying at least one change subpart in a reference URI, wherein the substitution information is one or more of the second ones. The method of claim 10, comprising at least one substitution value that replaces the change subpart identified in the reference URI to define a URI of the reference URI.   16. The method of claim 15, wherein the changed portion information identifies two or more subparts in the reference URI that are to be replaced using each one or more substitution values included in the substitution information. . A method for transmitting data between a server device and a client device, said method at a client device:
Identifying data to be obtained from the server device;
Generating an HTTP request to obtain first data from the identified data, wherein the HTTP request includes first data identifying information enabling identification of the first data on the server device, and Said generating step including one or more additional header fields including an indication as to whether the server device should or should not push the second data;
Sending the HTTP request to the server device to obtain the first data and prevent the server device from pushing or pushing second data; and in response to sending the HTTP request, acknowledgment data is sent to the server Receiving from the device, wherein the acknowledgment data represents the instruction associated with pushing second data, the receiving step;
The one or more additional header fields are identified on the server device based solely on the one or more additional header fields, and possibly further based on the first data identification information. Defining second data identification information that allows identification of the second data from the data;
Method. A method of receiving data from a server device by a client device, the method at the client device:
Sending an HTTP request to obtain first data, the HTTP request including first data identification information enabling identification of the first data on the server device and one or more additional headers Said sending step including a field;
If the client does not want the server device to push second data different from the first data, the client wants the second data to be pushed by the server in response to the HTTP request. Inserting an information item indicating no to into at least one of the one or more additional header fields; and sending the HTTP request to the server device;
Including a method. A method of sending data from a server device to a client device, the method at the server device:
Receiving an HTTP request for obtaining first data from the client device, wherein the HTTP request includes first data identification information that enables identification of the first data on the server device and includes one or more Said receiving step including an additional header field;
Retrieving the first data and sending it to the client device; and sending an information item indicating that the server does not push second data different from the first data to the client in response to the HTTP request;
Including a method.   20. The method of claim 19, wherein the information indicating that the server does not push second data includes at least one unique identifier, and the at least one unique identifier represents a directive to prevent second data from being pushed. .   In response to sending the HTTP request, further comprising receiving acknowledgment data from the server device, wherein the acknowledgment data indicates that the server does not push second data different from the first data. The method of claim 18, comprising an information item. Retrieving the first data and sending it to the client device; and in response to the HTTP request, the server sends an information item indicating that no second data different from the first data is sent to the client. Sending to the client;
20. The method of claim 19, further comprising:   20. The method of claim 19, wherein the information indicating that the server does not push second data includes at least one unique identifier, and the at least one unique identifier represents a directive for not pushing second data. .   The information indicating that the client does not want second data to be pushed by the server includes at least one unique identifier, and the at least one unique identifier represents a directive for not pushing second data. The method of claim 19. A method for transmitting data between a server device and a client device, said method comprising:
Receiving an HTTP request to obtain first data from the client device, wherein the HTTP request includes a first optional header field including one or more filtering parameters;
Retrieving the first data and sending it to the client device; and if the first optional header field is present in the HTTP request:
Identifying a set of data using a main resource obtained from the HTTP request;
Filtering each of the identified sets of data using the one or more filtering parameters to obtain a list of second data; and pushing the second data to the client device;
And the one or more filtering parameters include:
Defining a resource type; the one or more resource types include one or more of an application type, a text type, an image type, a video type, an audio type; or an element in a DASH media presentation description Identifying one or more groups of data using identifiers of: or-defined in the first optional header field using a time range identifying subparts of the main resource;
Method. A method for transmitting data between a server device and a client device, said method comprising:
Generating an HTTP request for obtaining first data, wherein the HTTP request includes a first optional header field including one or more filtering parameters;
Obtaining the first data and sending the HTTP request to the server device to cause the server device to push the second data referenced in the main resource estimated from the HTTP request according to the filtering parameters;
Including
The one or more filtering parameters are:
Defining a resource type; the one or more resource types include one or more types from application type, text type, image type, video type, audio type; or-in a DASH media presentation description Identifying one or more groups of data using an identifier of the element; or-defined in the first optional header field using a time range identifying a sub-part of the main resource;
Method.   27. A computer program product for a programmable device, wherein the computer program product is loaded and executed by a programmable device according to any of claims 1, 17, 18, 19, 25 and 26. A computer program product comprising instructions for performing the steps of the method according to claim 1.   27. A computer readable storage medium storing instructions of a computer program for performing the method of any one of claims 1, 17, 18, 19, 25 and 26.   27. A device comprising means adapted to carry out the steps of the method according to any one of claims 1, 17, 18, 19, 25 and 26.

Images