FR3109489A1 - Preparation of digital content accessible by adaptive progressive download and encoded using a variable rate encoding method, depending on a network load - Google Patents

Abstract

Preparation of digital content accessible in adaptive progressive downloading and encoded according to a variable bit rate encoding method, depending on a network load The invention relates to a method for preparing digital content accessible in adaptive progressive downloading (HAS) by a multimedia stream player terminal connected to a distribution network of said content; the digital content (C1) is associated with a digital content description file, comprising a list of time segments of the content each associated with a plurality of apparent encoding rates of the content; the time segments of the digital content are encoded (20) according to a variable bit rate (VBR) encoding method associated with an average encoding bit rate (ABR) and a maximum encoding bit rate (MBR). , such a method comprises a determination (21) of the apparent encoding bit rates (Nj) exposed in the description file in association with the time segments of the content, as a function of at least one load criterion (ChNet) of the distribution, an apparent encoding bit rate (Nj) possibly taking a value between the average encoding bit rate (ABRj) and the maximum encoding bit rate (MBRj). Figure for abstract: Fig 2

Description

Preparation of digital content accessible in adaptive progressive download and encoded using a variable bit rate encoding method, depending on network load

The field of the invention is that of digital multimedia content, namely digital audio and/or video content. More specifically, the invention relates to the preparation of digital content accessible using a technique known as adaptive progressive downloading, and encoded using a variable bit rate encoding method, depending on a network load.

Prior art

Access to multimedia content, such as television or video on demand, is possible today, for most restitution terminals.

The terminal generally sends a request to a server, indicating the chosen content and it receives in return a stream of digital data relating to this content.

The terminal is suitable for receiving these digital contents in the form of multimedia data and for restoring them. This restitution consists of providing the terminal with the digital content in a form accessible to the user. For example, received data corresponding to a video are generally decoded, then restored at the terminal level in the form of a display of the corresponding video with its associated soundtrack. In the following, for the sake of simplicity, we will assimilate the digital content to a video and the restitution by the terminal, or consumption by the user of the terminal, to a visualization on the screen of the terminal.

The distribution of digital content is often based on client-server protocols of the HTTP (Hyper Text Transport Protocol) family. In particular, the downloading in progressive mode of digital content, also called streaming, makes it possible to transport and consume data in real time, i.e. the digital data is transmitted over the network and restored by the terminal as and as they arrive. The terminal receives and stores part of the digital data in a buffer memory before restoring it. This distribution mode is particularly useful when the bit rate available to the user is not guaranteed for the real-time transfer of the video, depending for example on the fluctuation of the available bandwidth.

Adaptive progressive downloading, in English HTTP Adaptive Streaming, abbreviated HAS, also makes it possible to broadcast and receive data according to different qualities corresponding for example to different speeds. These different qualities are described in a parameter file available for download on a data server, for example a content server. When the client terminal wishes to access a content, this description file makes it possible to select the correct format for the content to be consumed according to the available bandwidth or the storage and decoding capacities of the client terminal. This type of technique makes it possible in particular to take into account variations in bandwidth on the link between the client terminal and the content server.

There are several technical solutions to facilitate the distribution of such streaming content, such as the proprietary solutions Microsoft® Smooth Streaming, Apple® HLS, Adobe® HTTP Dynamic Streaming or the MPEG-DASH standard of the ISO/ IEC which will be described below. These methods propose to send the client one or more intermediate description files, also called documents or manifests, containing the addresses of the different segments with different qualities of the multimedia content.

Thus, the MPEG-DASH standard (for English “Dynamic Adaptive Streaming over HTTP”, in French “Dynamic adaptive streaming over HTTP”) is an audiovisual format standard for broadcasting on the Internet. It is based on the preparation of the content in different presentations of variable quality and speed, cut into short segments (of the order of a few seconds), also called “chunks”. Each of these segments is made available individually by means of an exchange protocol. The protocol mainly targeted is the HTTP protocol, but other protocols (eg FTP) can also be used. Segment organization and associated settings are published in a manifest in XML format.

The principle underlying this standard is that the MPEG-DASH client makes an estimate of the bandwidth available for the reception of the segments, and, according to the filling of its reception buffer, chooses, for the next segment to be loaded, a representation whose bit rate:

• ensures the best possible quality,
• and allows a reception delay compatible with the uninterrupted rendering of the content.

Thus, to adapt to varying network conditions, particularly in terms of bandwidth, existing adaptive download solutions allow the client terminal to switch from one version of the content encoded at a certain bit rate, to another encoded at a other speed, during the download. Indeed, each version of the content is divided into segments of the same duration. To allow continuous playback of the content on the terminal, each segment must reach the terminal before its scheduled playback time. The perceived quality associated with a segment increases with the size of the segment, expressed in bits, but at the same time, larger segments require more transmission time, and therefore present an increased risk of not being received in time for continuous playback of content.

The rendering terminal must therefore find a compromise between the overall quality of the content, and its uninterrupted rendering, by carefully selecting the next segment to be downloaded, from among the various encoding rates offered. To do this, there are different algorithms for selecting the quality of the content according to the available bandwidth, which can present more or less aggressive strategies, or more or less secure.

The consumption of digital content in adaptive progressive download (HAS) tends to become more democratic. It is used in particular by many streaming services (in French, streaming in continuous mode, or streaming), but also by certain TV decoders, or set-top-boxes, which use it to access delinearized content, such as video on demand (VOD), delayed broadcast of television programs (Replay), or even Network PVR-type offers (for "Network Personal Video Recorder", i.e. a digital content recording service, performed by the content provider itself rather than at the end user's home).

In addition, other devices such as real-time media streaming devices also access digital content in progressive adaptive download mode for real-time (or Live) television content. This is the case, for example, of the Chromecast® device developed by Google®, or the CléTV® from Orange®. Such devices, more generically referred to as Clef HDMI, can also be used to access video-on-demand type content.

Such devices are conventionally plugged into the HDMI port of a television and communicate, for example by Wi-Fi® connection, with another device of the home communication network connected to an extended communication network (for example a smart phone of the smartphone, connected to a 4G mobile network), in order to play back, on the television, the multimedia content received by a compatible software application. These devices will be referred to below under the generic designation of HDMI Key.

There are also several techniques for encoding digital content which are thus accessible in HAS adaptive progressive downloading.

A first known technique, called CBR (for "Constant Bit Rate", which can be translated as "fixed sampling rate"), consists in encoding the content at a constant bit rate: thus, all the video segments , or "chunks", of the same quality level, have an identical size, expressed in kilobytes. Thus, whatever the nature of the encoded images, the size of the segments is always the same, which makes it possible to predict the consumption of data in the digital content distribution network.

Another known encoding technique, called VBR (for “Variable Bit Rate”, which can be translated as “variable sampling rate”), makes it possible to encode the content at a variable bit rate, limited by a maximum bit rate called MBR (for “Max Bit Rate”). The average encoding bit rate obtained for the content is called ABR (for "Average Bit Rate"). According to this technique, the size of the video segments of the same level of quality evolves according to the encoded digital content and the nature of the images: thus, the video segments corresponding to a very animated scene will be encoded at a bit rate close to the maximum bit rate. MBR, unlike “chunks” of scenes with very little animation (for example black images with very little movement), which will be encoded according to a lower encoding rate, for example lower than the average ABR rate.

By considering video segments of the same duration (for example 2s) and of the same level of quality, we will therefore observe a very strong disparity in their size (in kilobytes), depending on the portion of content to which they correspond (calm scene or animated scene).

This VBR variable rate encoding technique is advantageous in that it makes it possible to reduce the average size in kilobytes of the video segments, while maintaining the same level of quality perceived by the user: on average we thus observe a reduction 50% less bandwidth usage on the network, compared to CBR encoding, for the same video quality.

It is easy to understand that, for content encoded using a CBR technique, the apparent encoding bitrate displayed in the content description file, or manifesto, is the constant encoding bitrate that applies for all of the content, depending on the level of quality offered. Thus, a manifest file (MPD) conforming to the MPEG-DASH standard can include the description of content available in three different qualities (N1 = 512 kb/s, N2 = 1024 kb/s, N3 = 2048 kb/s) , where N1, N2 and N3 designate the constant encoding bitrates used for encoding all the video segments of the content. The multimedia rendering terminal then chooses to download the segments at one of these three quality levels: for the same quality level, all the downloaded segments are of the same size in kilobytes.

On the other hand, for content encoded using a VBR technique, the question arises of what is the apparent encoding bitrate that should be exposed in the manifest file.

A first option consists in exposing in the manifest file, for each content quality level, the maximum MBR encoding bit rate of the video segments: this first option is advantageous in terms of reducing bandwidth consumption in the distribution of HAS content. Indeed, the display of the maximum MBR bit rate in the manifest file leads the multimedia stream reader terminal to overestimate the size of the segments to be downloaded, compared to their effective size. It is this MBR value that is used by the multimedia stream player terminal to calculate the recovery time of the chunks, and thus determine the level of quality proposed in the manifest file to which it can claim. This therefore leads the multimedia stream player terminal to select a level of quality probably lower than that which it could actually claim in practice, and therefore, ultimately, for the operator, to a reduction in bandwidth consumption and to a reduction in the load on the distribution network.

A second option is to expose in the manifest file, not the maximum MBR bitrate, but, for each content quality level, the associated average ABR encoding bitrate. This second option advantageously improves the quality perceived by the user.

These two options therefore each present their interests, according to the respective expectations of the operator on the one hand, and the customer on the other. However, they have the disadvantage of being fixed: the choice, once and for all, to expose in the manifest file, either the maximum rate MBR, or the average rate ABR, does not in fact make it possible to adapt to the context. .

There is therefore a need for a technique for preparing digital content accessible for HAS download and encoded according to a variable bit rate VBR encoding technique which does not have these various drawbacks of the prior art. In particular, there is a need for such a technique which makes it possible to finely adapt to the context, particularly, but not exclusively, to the particular load context of the content distribution network and the associated servers.

There is also a need for such a technique which makes it possible to take advantage in a combined way of the advantages of the known techniques of displaying the MBR and displaying the ABR in the manifest file.

There is still a need for such a technique which is simple to implement and can jointly meet the expectations of the network operator on the one hand, and of the user customers on the other hand.

The invention meets this need by proposing a method for preparing digital content accessible by adaptive progressive downloading (HAS) by a multimedia stream player terminal connected to a distribution network of said content. The digital content is associated with a digital content description file, comprising a list of time segments (C1 _i @Nj) of the content each associated with several apparent encoding rates of the content.

The time segments of the digital content are encoded using a variable bit rate (VBR) encoding method associated with an average encoding bit rate (ABR) and a maximum encoding bit rate (MBR).
According to the invention, such a method comprises a determination of the apparent encoding bit rates exposed in the description file in association with the time segments of the content, according to at least one load criterion (ChNet) of the distribution network, an apparent encoding bit rate that can take a value between the average encoding bit rate and the maximum encoding bit rate.

Thus, the invention is based on an entirely new and inventive approach to the preparation of digital content made available to user client terminals for adaptive progressive downloading of the HAS type, when this content is encoded using a bitrate encoding technique. VBR variable.

Indeed, unlike the techniques of the prior art, according to which it is decided once and for all to expose in the manifest file, either the maximum rate MBR, or the average rate ABR, the technique of the invention proposes on the contrary to change over time the apparent bit rate exposed in this description file, according to one or more load criteria of the content distribution network. This apparent bit rate can advantageously take a value between the average bit rate ABR, to improve the quality perceived by the user, and the maximum bit rate MBR, to reduce the consumption of resources in the network.

In other words, the proposed solution aims to adapt the content of the manifest according to the real-time use of the network load of the operator. Here, network load means all the load generated on the content servers and also on the consumption of bandwidth in the operator's network.

According to a first embodiment, the apparent encoding bitrate takes a value equal to (MBR-ABR)/100*ChNet+ABR, where MBR designates the maximum encoding bitrate, ABR designates the average encoding bitrate and ChNet designates a value, between 0 and 100, assigned to said at least one load criterion. When the ChNet load criterion takes the value 0, the load is zero; when it takes the value 100, the load is maximum.

Thus, if the load is low, the technique according to the invention makes it possible to favor the improvement of the video quality returned to the client, without however optimizing the reduction in the network load. On the other hand, when the load increases, the technique according to the invention makes it possible to gradually optimize the reduction in the network load to the detriment of the improvement in the quality of the image.

Indeed, if the ChNet load criterion takes the value 0, the operator builds the manifest files by indicating as the bit rate of each quality level the value of the average bit rate ABR. In this case, the maximum improvement in video quality provided to the client is favored, without limiting the use of bandwidth. Indeed, in this case, the operator's network being little used, it is not necessary to optimize the flows.

If the network load increases, the operator exposes in the manifest files an apparent throughput value that increases to approach the MBR maximum throughput when the value of the ChNet load criterion approaches 100.

Such an approach to determining the apparent bitrate to expose in the manifest file provides an advantageous servo feedback loop.

According to one aspect, such a content preparation method comprises measuring a distribution network load and the value assigned to said at least one network load criterion is a function of the measurement.

Thus, the operator constantly monitors and monitors the network load related to the distribution of HAS content, and adapts its manifest file construction strategy, according to the measured load. This ensures optimal adaptability of the content proposal made to customers according to the actual network load, and the best possible compromise between the video quality perceived by the user and the consumption of resources for the operator.

This is particularly advantageous when the digital content is broadcast over the network in real time. Indeed, the so-called LIVE contents are open contents for which the client terminal must very regularly download the description file, in general every minute. The real-time adaptation of the apparent bit rates exposed in the manifest file therefore has a direct impact on the choice, by the multimedia stream reader terminal, of the quality to which it can claim for downloading the video segments of content.

According to another aspect, said at least one network load criterion also takes account of at least one parameter belonging to the group comprising:

• network load prediction;
• network electricity consumption;
• a time of year;
• network equipment update schedule.

Indeed, this principle of adaptation of the apparent throughput exposed in the manifest file can be extended to take into account other load criteria than the simple measured effective load of the network, and in particular take on a predictive dimension.

Thus, it is possible to take into account a period of the year, for example the winter period during which the overall electricity consumption is higher: in this case, we tend to change the apparent flow towards the MBR, to reduce the consumption of resources, and therefore also reduce the electrical consumption during recorded consumption peaks, for example during severe cold alert periods.

It is also possible to take account of network load predictions, obtained by observing the loads during elapsed past periods. Thus, if there is an increase in the network load at the beginning of the month, compared to the end of the month, it can be taken into account to weight the value of the apparent throughput exposed in the manifest file.

It is still possible to take into account holiday periods, or weather conditions to predict the network load: indeed, when the weather is bad, we see that video consumption is higher.

You can also voluntarily modify the apparent speed exposed in the manifest file, for example in the event of maintenance or updating of certain equipment or certain platforms of the content distribution network, to lighten the load on other equipment. .

We can still act on this apparent flow to take into account new and unforeseen situations, for example in order to reduce the consumption of network resources during a period of confinement of the population, to favor access to resources for more priorities, such as teleworking.

The invention also relates to a computer program product comprising program code instructions for implementing a method as described previously, when it is executed by a processor.

The invention also relates to a recording medium readable by a computer on which is recorded a computer program comprising program code instructions for the execution of the steps of the method for preparing a digital content according to the invention, as described above.

Such recording medium can be any entity or device capable of storing the program. For example, the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a USB key or a hard disk.

On the other hand, such a recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means, so that the program computer it contains is executable remotely. The program according to the invention can in particular be downloaded onto a network, for example the Internet network.

Alternatively, the recording medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the aforementioned display control method.

The invention also relates to a platform for preparing digital content accessible in adaptive progressive downloading (HAS) by a multimedia stream player terminal connected to a content distribution network. The digital content is associated with a digital content description file, comprising a list of time segments (C1 _i @Nj) of the content each associated with several apparent encoding rates of the content. The time segments of the digital content are encoded using a variable bit rate (VBR) encoding method associated with an average encoding bit rate (ABR) and a maximum encoding bit rate (MBR).

According to the invention, such a platform comprises a computer able to determine the apparent encoding bit rates exposed in the description file in association with the time segments of the content, according to at least one load criterion (ChNet) of the distribution network, an apparent encoding bit rate possibly taking a value between the average encoding bit rate and the maximum encoding bit rate.

It should be noted that this platform can be dissociated from the content provision platform, the structure and operation of which are not impacted by the technique of the invention.

Advantageously, the apparent encoding bit rate determined by the computer takes a value equal to (MBR-ABR)/100*ChNet+ABR, where MBR designates the maximum encoding bit rate, ABR designates the average encoding bit rate and ChNet designates a value, between 0 and 100, assigned to said at least one load criterion.

According to another aspect, such a platform for preparing digital content comprises a module for measuring a distribution network load and the computer assigns to said at least one network load criterion a value which is a function of the measured load.

According to another aspect, such a network load criterion also takes account of at least one parameter belonging to the group comprising:

• network load prediction;
• network electricity consumption;
• a time of year;
• network equipment update schedule.

Presentation of figures

Other aims, characteristics and advantages of the invention will appear more clearly on reading the following description, given by way of a simple illustrative example, and not limiting, in relation to the figures, among which:

presents a mobile network progressive downloading architecture based on the use of adaptive streaming according to the invention;

illustrates in the form of a schematic flowchart the different steps of the method for preparing content according to one embodiment of the invention;

illustrates the principle of evolution of the encoding bit rate of a content encoded according to a variable bit rate technique of the VBR type;

presents the hardware structure of a digital content preparation platform implementing the process of Fig 2.

Detailed Description of Embodiments of the Invention

The general principle of the invention is based on the adaptation of the description files of the digital contents accessible in HAS progressive download and encoded according to a variable bit rate VBR encoding technique, in order to change the apparent bit rate exposed in these description files. , depending on one or more distribution network load criteria.

A progressive downloading architecture based on the use of adaptive streaming according to the invention is now presented in relation to FIG .

The terminal 3, for example a smart phone of the “smartphone” type, and the terminal 4, for example a tablet, are, in this example, connected to an extended communication network 1, forming a digital content distribution network. They communicate with a terminal 8, for example an HDMI key connected to a television 5.

A digital content server 2 is located according to this example in the wide area network (WAN, 1) and receives, for example, digital television content channels from a broadcast television network, not shown, and/or videos from request, and makes them available to customer terminals.

The client terminals 3 and 4 can enter into communication with the content server 2 to receive one or more contents (films, documentaries, advertising sequences, etc.).

It is common, in this client-server context, to use, to exchange data between the client terminals 3, 4 and the server 2, an adaptive progressive downloading technique, in English “adaptive streaming”, abbreviated as HAS based on the HTTP protocol. This type of technique makes it possible in particular to offer a good quality of content to the user by taking into account the bandwidth variations which may occur on the link between the client terminal 3, 4 and the content server 2.

Conventionally, different qualities can be encoded for the same content of a channel, corresponding for example to different bitrates. More generally, we will speak of quality to refer to a certain resolution of the digital content (spatial, temporal resolution, level of quality associated with the video and/or audio compression) with a certain apparent bit rate. Each quality level is itself cut on the content server into time segments (or “fragments” of content, in English “chunks”, these three words being used interchangeably throughout this document).

The description of these different qualities and the associated temporal segmentation, as well as the content fragments, are described for the client terminal and made available to it via their Internet addresses (URI: Universal Resource Identifier). All of these parameters (qualities, fragment addresses, etc.) are generally grouped together in a parameter file, called the description file. It should be noted that this parameter file can be a computer file or a set of information descriptive of the content, accessible at a certain address.

Terminals 3, 4 have their own characteristics in terms of decoding capacity, display, etc. In a context of progressive adaptive downloading, they can adapt their requests to receive and decode the content requested by the user at the quality that suits them best. In our example, if the content is available at the apparent speeds of 512 kb/s (kilobits per second) (Resolution 1, or level 1, denoted N1), 1024 kb/s (N2), 2048 kb/s (N3) and that the client terminal has a bandwidth of 3000 kb/s, it can request the content at any rate below this limit, for example 2048 kb/s. In general, “Ci@Nj” denotes the content number i with the quality j (for example the j-th quality level Nj described in the description file).

The client terminals 3, 4 receive the data from the extended network 1 and ensure their decoding, and possibly their restitution on their screen, or their transmission to the HDMI key 8 for restitution on the screen of the television set 5. Alternatively, the decoders can be located elsewhere in the network, in particular at the level of an element of STB (Set-Top-Box) type (not shown) associated with a television.

In this example, to view a content, the terminal 3, 4 or 8 first retrieves an address of the description document 7 of the desired content (for example, C1). In the following, we will assume that this file is a file of the manifest type according to the MPEG-DASH standard (denoted "C.mpd") and we will refer indifferently, depending on the context, to the expression "description file" or " manifest”. This file can be retrieved directly from an Internet server of the extended network 1, or can already be found on the terminal at the time of the request.

An example of a manifest file (MPD) conforming to the MPEG-DASH standard and comprising the description of content available in three different qualities (N1 = 512 kb/s, N2 = 1024 kb/s, N3 = 2048 kb/s) of content fragmented is presented in appendix 1 . This simplified manifest file describes digital content in an XML syntax (from the English "eXtended Markup Language"), comprising a list of content in the form of fragments conventionally described between an opening tag (<SegmentList>) and a closing tag (</SegmentList>). Cutting into fragments makes it possible in particular to adapt finely to fluctuations in bandwidth. Each fragment corresponds to a certain duration (“duration” field) with several quality levels and makes it possible to generate their addresses (URL – Uniform Resource Locator). This generation is done in this example using the elements "BaseURL"("HTTP://server.com") which indicates the address of the content server and "SegmentURL" which lists the complementary parts of the addresses of the different fragments :

- “C1_512kb_1.mp4” for the first fragment of the “C1” content at an apparent bit rate of 512 kilobits per second (“kb”) in MPEG-4 format (“mp4”),

- “C1_512kb_2.mp4” for the second fragment,

- etc.

Once it has the fragment addresses corresponding to the desired content, the terminal proceeds to obtain the fragments via a download to these addresses. It should be noted that this download takes place here, traditionally, through an HTTP URL, but could also take place through a universal address (URI) describing another protocol (dvb://monsegmentdecontent for example).

It is assumed here that the HDMI key 8 is connected to the television set 5 by plugging into the HDMI port of the latter, and is used to render, on the screen of the television set 5, a content C1, described in a manifest file 7. Note that the content C1 can be a television program broadcast live or deferred, or a video on demand, or any other multimedia content.

The HDMI key 8 can be connected via WiFi® directly to the tablet 4 or to the smart phone 3, via which it can access the extended communication network 1, for example via a 4G connection.

The HDMI key 8 can also be controlled by the user by means of the smartphone 3, on which a software application for controlling the HDMI key 8 is installed.

The content fragments obtained by the smartphone 3 or the tablet 4 are for example transmitted via WiFi® to the HDMI key 8, which controls their display on the television screen 5, for restitution to the user.

Fig 2 illustrates in the form of a simplified flowchart the different steps implemented according to an embodiment of the invention to prepare the manifest file 7, when a content C1 is intended to be encoded according to a variable bit rate encoding technique , VBR. In this example, a content C1 broadcast in real time, also called LIVE, is considered. Indeed, for such LIVE content, the multimedia stream player terminal retrieves the manifest file 7 at very regular time intervals, for example approximately every minute, according to a known technique. The adaptation of the apparent bit rate of the content exposed in this manifest 7 file, according to a load criterion, is therefore particularly effective and directly followed by an effect, for the choice of bit rate and quality level made by the reader terminal. multimedia stream, for example the HDMI key 8.

During a first step referenced 20, the content C1 is encoded according to a VBR variable bit rate encoding technique. In other words, the content C1 is split into segments, or chunks, of constant duration, for example of 2s. Each segment of the content C1 is then encoded according to an encoding rate which may fluctuate, depending on the nature of the content over the duration of the segment. This encoding bit rate is however limited by the maximum MBR encoding bit rate (for a given quality level or resolution). The average encoding bitrate of C1 content is called ABR (for a given quality level or resolution). This is illustrated by FIG. 3 , which represents in simplified form a possible fluctuation of the encoding rate of the content C1 as a function of time, according to the VBR encoding technique. The two horizontal straight lines in dotted lines represent respectively (for a given level of quality or resolution) the maximum encoding bitrate MBR which is reached for this content C1, and the average encoding bitrate ABR, corresponding to the average of the bitrates encoding of each of the segments.

During a step referenced 21, the network operator determines one or more ChNet load criteria. These load criteria include in particular an estimate of the load of the content distribution network, as it can be measured by the operator, according to known techniques which are not the subject of the present invention. By network load, we mean here all the load generated on the content servers, and in particular on the content distribution platforms, and also the consumption of bandwidth in the operator's network.

These charging criteria can also take into account other charging parameters, such as:

• a period of the year: thus, in winter, in the event of a severe cold alert, it may be useful to consider reducing consumption by the operator's network;
• a political decision by the operator, who may wish to give priority to the quality perceived by his customers or, conversely, to reduce the load on his network;
• a particular situation of updating by the operator of certain equipment or certain network platforms;
• a CSR (Corporate Social Responsibility) policy for the operator, which can, in a sustainable development approach, choose to reduce the electricity consumption of its network;
• a load prediction, based on past observation of consumption peaks in the network, depending on the time of day, day of the week, or time of year.

This list is of course not exhaustive, and any other parameter directly or indirectly influencing the evaluation of a network load can be taken into account for the determination, during step 21, of the load metric ChNet.

In the following, for the sake of simplification, it is considered that this ChNet load metric takes, in step 21, a value between 0 and 100, where the value 0 corresponds to a zero network load, and where the value 100 corresponds at maximum network load. Any other scale of value or weighting of the ChNet criterion can of course be envisaged in the context of the present invention, subject to corresponding adaptation of the calculation formula which will be described below in relation to the step referenced 22.

During this step 22, the apparent encoding bit rate is therefore calculated which will be exposed in association with each level of quality of the content, in the manifest file 7. With reference to the example of appendix 1, this step 22 therefore makes it possible to calculate the value of the quality levels N1, N2, N3, etc. which are going to be displayed in the manifest 7 file for the C1 content.

Thus, for a given resolution j, the content preparation platform calculator calculates the apparent bit rate Nj according to the formula:

Nj=(MBRj-ABRj)/100*ChNet+ABRj

Thus, if the network load is zero, and the load criterion ChNet takes the value 0, the apparent encoding bit rate Nj which will be exposed in the manifest file 7 for the resolution level j will be Nj=ABRj, i.e. the bit rate of average encoding at quality level j for the video segments of the content C1. Thus, it promotes the improvement of the video quality provided to the client, without limiting the use of bandwidth. Indeed, this case corresponds to one where the operator's network is little used (off-peak hours for example), and it is therefore not necessary to optimize flows.

When the network load increases, the value of the ChNet load criterion gradually increases between 0 and 100; the value of the apparent encoding bit rate Nj therefore also increases to approach the maximum value MBRj of the encoding bit rate for this level of resolution. Thus, it promotes the optimization of network resource consumption, to the detriment of the video quality perceived by the customer.

The table below illustrates an example of apparent bitrate values exposed in manifest 7 for different resolution levels of a portion of C1 content. It is assumed in this example that, for this portion of the content C1, the load criterion ChNet takes a value ChNet=80.

j-level Resolution Maximum throughput (MBRj) Average bit rate (ABRj) Apparent flow (Nj) 1 320x180 pixels 600kbps 300kbps 540kbps 2 569x320 pixels 1.2Mb/s 600kbps 1080kbps 3 1024x576 pixels 2.1Mbps 1.05Mbps 1.89Mbps 4 1280x720 pixels 3Mbps 1.5Mbps 2.7Mbps 5 1920x1080 pixel 5Mbps 2.5Mbps 4.5Mbps

When downloading the manifest 7 file, the multimedia stream reader terminal can therefore choose to ask the content distribution platform to download the next video segments at an encoding rate N1=540kb/s, N2=1080kb/s, N3=1.89MB/s, N4=2.7MB/s or N5=4.5MB/s.

Thus, a HAS 2 content server exposes a video C1 in the form of “chunks” C1 _i @Nj encoded at different encoding bit rates Nj, where the index i denotes a temporal identifier of the “chunk” C1 _i @Nj.

According to the prior art, a HAS client module is responsible for coming to retrieve its “chunks” from the HAS content server 2 by choosing the video quality Nj according to the available network resource. We will not describe here in more detail the way in which the HAS client module chooses the encoding bit rate of the next video fragment to be downloaded: there are indeed many algorithms allowing this choice to be made, whose strategies are more or less secure. or aggressive. It is however recalled that, most often, the general principle of such algorithms is based on the downloading of a first fragment at the lowest encoding rate proposed in the manifesto, and on the evaluation of the recovery time of this first fragment. . Based on this, the HAS client module evaluates whether, based on the size of the fragment and the time taken to retrieve it, the network conditions allow the next fragment to be downloaded at a higher encoding rate. Some algorithms rely on gradually increasing the quality level of downloaded content fragments; others propose more risky approaches, with jumps in the levels of the encoding bit rates of the successive fragments.

In the classic case, if a video “chunk” lasts 3 seconds, the recovery of the “chunk” by the HAS client module must not exceed 3 seconds, in order to allow uninterrupted playback of the content by the terminal. It is therefore appropriate for the HAS client module to operate the best compromise between a restitution quality, and therefore an encoding bit rate, as high as possible, and the download time of the fragment, which must be sufficiently low to allow a restitution. continuously on the return terminal.

For LIVE type C1 content (i.e. broadcast in real time), the HAS download module of the multimedia stream reader terminal retrieves the manifest file 7 at regular time intervals, for example every minute, in order to discover the available fragments of the video content C1, and the different apparent video qualities Nj associated.

Thus, in the example of Table 1 , the content C1 is for example offered in the form of fragments of duration 3s, with a first apparent encoding rate N1=540kb/s, a second apparent encoding rate N2=1080kb/ s, a third apparent encoding rate N3=1.89Mb/s, etc.

On the basis of the encoding bit rates Nj exposed in the manifest file 7, the HAS download module of the terminal performs the download, for example, of successive fragments C1 ₁ @N1 (i.e. the first temporal fragment at an encoding bit rate of 540 kb /s), then C1 ₂ @N3 (i.e. the second time fragment at an encoding rate of 1.89Mb /s), then C1 ₃ @N3 (i.e. the third time fragment at an encoding rate of 1.89Mb /s), ...

This choice made by the HAS download module is therefore based on the apparent encoding bit rate value Nj exposed in the manifest 7 file, and not on the effective size in kilobytes of the video segments it receives. This size is only used to calculate the recovery time of the chunks, and thus determine what level of quality j it can claim.

Thus, if he chooses for the second time fragment a download at an encoding rate of 1.89Mb /s (i.e. C1 ₂ @N3), it is possible, as illustrated by Fig 3, that the actual encoding rate of this fragment is much lower, for example only 800 kb/s. The gain resulting from this difference between apparent and effective encoding bit rates makes it possible to optimize the consumption of the network resources of the operator.

The different fragments downloaded by the HAS download module are then returned to the user on the screen of the restitution terminal.

If the network load fluctuates, and the value of the ChNet load criterion changes, the apparent encoding bitrates exposed in the manifest 7 file will also be modified, in the next version of manifest 7, downloaded by the stream reader terminal multimedia, for example 60 s later. Thus, if the ChNet load criterion changes from a value of 80 to a value of 40, the apparent encoding bitrates exposed in the following version of the manifest 7 file become:

j-level Resolution Maximum throughput (MBRj) Average bit rate (ABRj) Apparent flow (Nj) 1 320x180 pixels 600kbps 300kbps 420kbps 2 569x320 pixels 1.2Mb/s 600kbps 840kbps 3 1024x576 pixels 2.1Mbps 1.05Mbps 1.47Mbps 4 1280x720 pixels 3Mbps 1.5Mbps 2.1Mbps 5 1920x1080 pixel 5Mbps 2.5Mbps 3.5Mbps

As the load has decreased, it is possible to expose lower apparent encoding bitrates in the manifest 7 file, and thus promote the improvement of the video quality provided to the user.

A feedback feedback loop is thus ensured, according to which, the lower the network load, the more it is authorized to consume a large part of the resources of the operator's network, and thus to ensure that the encoding in VBR (compared to CBR encoding) contributes to improving the video quality delivered to the end customer.

The above embodiment has been described in the context of real-time, or LIVE, C1 video content for which the manifest file is downloaded at regular time intervals by the media stream player terminal, allowing to ensure enslavement.

It should be noted that the technique of the invention can also find application for VOD type content (for "Video On Demand", or video on demand), or "replay" content (in French, catch-up television), based on the predictive character of the evolution of the network load. Indeed, for such content, the manifest 7 file is downloaded once and for all, when the client starts viewing the content. However, depending on the download time of this manifest 7 file, the duration of the content, and a prediction of the evolution of the network load over this duration, it is possible to assign a value to the criterion of ChNet load, and thus to determine the apparent optimum encoding bit rates to expose in the manifest, according to the principle of Fig 2 . In this case, the value of ChNet does not result solely from a measurement of the network load, but from detailed knowledge of the recurring daily, weekly or seasonal load peaks. Indeed, HAS download volumes fluctuate greatly over the course of a day, with strong peaks in consumption in the evening. Thus, for the same content, and the same network load measured at the start of its download, different apparent encoding bitrates will be able to be exposed in the manifest file, depending on the time at which this content is requested by the user. .

We now present, in relation toFig 4, the hardware structure of a platform 40 preparation of digital content accessible in adaptive progressive download (HAS), connected to the distribution network 1 of an operator.

It comprises, conventionally, memories M associated with a processor CPU. The memories can be of the ROM ( Read Only Memory ) or RAM ( Random Access Memory ) type, or else Flash. The platform 40 communicates with the extended Internet network 1 via an I/O module for communication with other servers and network equipment, for example the content server 2, to which it provides the manifest file 7. The platform 40 comprises in addition to a module MONIT_ChNet for measuring the load of network 1, capable of assigning a value to the load criterion ChNet. This value can be recorded for example in the memories M of the platform 40.

The platform 40 also includes a module ENCOD(Ci) for encoding video segments of a content Ci, according to a VBR variable bit rate encoding technique.

It also includes a PREP_MANIFEST module for preparing the manifest 7 file, for the Ci content, which exposes in this file the apparent encoding bit rates calculated by the CPU calculator, according to the ChNet load criterion delivered by the MONIT_ChNet module and the values maximum encoding bit rate MBR and average encoding bit rate ABR supplied by the encoding module ENCOD(Ci).

It will be noted that the term module can correspond both to a software component and to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more programs or computer or more generally to any element of a program capable of implementing a function or a set of functions as described for the modules concerned. In the same way, a hardware component corresponds to any element of a hardware (or hardware) assembly capable of implementing a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc. .).

More generally, such a platform 40 comprises a random access memory (for example a RAM memory), a processing unit equipped for example with a processor CPU, and driven by a computer program, stored in a read only memory (for example a ROM or hard disk). On initialization, the code instructions of the computer program are for example loaded into the RAM before being executed by the processor CPU of the processing unit. The random access memory contains in particular the value of the load criterion ChNet. The processor of the processing unit controls the determination of the apparent encoding bit rates to expose in the manifest file 7, according to the algorithm of FIG 2 .

Fig 4 only illustrates one particular way, among several possible ones, of making a content preparation platform so that it performs the steps of the method detailed above, in relation to Fig 2 (in any one of the different embodiments , or in a combination of these embodiments). Indeed, these steps can be carried out either on a reprogrammable calculation machine (a PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated calculation machine (for example a set of logic gates like an FPGA or an ASIC, or any other hardware module).

APPENDIX 1: sample manifest file

Claims (10)

Method for preparing digital content accessible by adaptive progressive download (HAS) by a multimedia stream player terminal connected to a network (1) for distributing said content,
said digital content being associated with a file (7) describing said digital content, comprising a list of time segments (C1 _i @Nj) of said content each associated with several apparent encoding bit rates of said content,
said time segments of said digital content being encoded (20) according to a variable bit rate (VBR) encoding method associated with an average encoding bit rate (ABR) and a maximum encoding bit rate (MBR),
characterized in that it comprises a determination (21) of said apparent encoding bit rates (Nj) exposed in said description file (7) in association with said time segments of said content, as a function of at least one load criterion ( ChNet) of said distribution network,
an apparent encoding bit rate (Nj) being able to take a value between said average encoding bit rate (ABRj) and said maximum encoding bit rate (MBRj). Process for preparing digital content according to Claim 1, characterized in that the said apparent encoding rate (Nj) takes a value equal to (MBR-ABR)/100*ChNet+ABR,
where MBR designates said maximum encoding bit rate, ABR designates said average encoding bit rate and ChNet designates a value, between 0 and 100, assigned to said at least one load criterion. Process for preparing digital content according to claim 2, characterized in that it comprises a measurement of a load of said distribution network (1) and in that said value assigned to said at least one load criterion (ChNet) of said network (1) is a function of said measurement. Process for preparing digital content according to any one of Claims 1 to 3, characterized in that the said at least one load criterion (ChNet) of the said network (1) also takes account of at least one parameter belonging to the group including:
a load prediction of said network;
an electrical consumption of said network;
a time of year;
programming for updating equipment of said network. Process for preparing digital content according to any one of Claims 1 to 4, characterized in that the said digital content (C _i ) is broadcast on the said network (1) in real time. Computer program product comprising program code instructions for implementing a method according to any one of claims 1 to 5, when executed by a processor. A computer-readable recording medium on which is recorded a computer program comprising program code instructions for carrying out the steps of the method according to any one of claims 1 to 5. Platform (40) for preparing digital content accessible in adaptive progressive download (HAS) by a multimedia stream player terminal connected to a network (1) for distributing said content,
said digital content being associated with a file (7) describing said digital content, comprising a list of time segments (C1 _i @Nj) of said content each associated with several apparent encoding bit rates of said content,
said time segments of said digital content being encoded using a variable bit rate (VBR) encoding method associated with an average encoding bit rate (ABR) and a maximum encoding bit rate (MBR),
characterized in that it comprises a computer (CPU) capable of determining said apparent encoding bit rates (Nj) exposed in said description file (7) in association with said time segments of said content, as a function of at least one criterion load (ChNet) of said distribution network (1),
an apparent encoding bit rate (Nj) being able to take a value between said average encoding bit rate (ABRj) and said maximum encoding bit rate (MBRj). Platform (40) for preparing digital content according to claim 8, characterized in that said apparent encoding rate (Nj) determined by said computer (CPU) takes a value equal to (MBR-ABR)/100 *ChNet+ABR,
where MBR designates said maximum encoding bit rate, ABR designates said average encoding bit rate and ChNet designates a value, between 0 and 100, assigned to said at least one load criterion. Platform (40) for preparing digital content according to claim 8, characterized in that it comprises a module (MONIT_ChNet) for measuring a load of said distribution network (1) and in that said computer ( CPU) assigns to said at least one load criterion (ChNet) of said network a value which is a function of said measured load.