WO2021209706A1

WO2021209706A1 - Management of access to digital content available via progressive and adaptive streaming and encoded using a variable bit rate encoding method, depending on a network load

Info

Publication number: WO2021209706A1
Application number: PCT/FR2021/050638
Authority: WO
Inventors: Olivier GASTE; Hervé Marchand
Original assignee: Orange
Priority date: 2020-04-16
Filing date: 2021-04-12
Publication date: 2021-10-21
Also published as: FR3109489B1; FR3109489A1

Abstract

Management of access to digital content available via progressive and adaptive streaming and encoded using a variable bit rate encoding method, depending on a network load The invention relates to a method for managing access to digital content available via progressive and adaptive streaming (HAS) by a multimedia stream player terminal connected to a network for distributing the content; the digital content (C1) is associated with a description file of the digital content comprising a list of time segments of the content, each associated with a plurality of apparent encoding bit rates of the content; the time segments of the digital content are encoded (20) 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 determining (21) apparent encoding bit rates (Nj) contained in the description file together with the time segments of the content, depending on at least one load criteria (ChNet) of the distribution network, an apparent encoding bit rate (Nj) being able to assume a value between the average encoding bit rate (ABRj) and the maximum encoding bit rate (MBRj).

Description

DESCRIPTION

TITLE: Management of access to digital content accessible by adaptive progressive download and encoded using a variable bit rate encoding method, depending on a network load

Technical area

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 according to a technique known as adaptive progressive downloading, and encoded according to a variable 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 playback terminals.

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

The terminal is suitable for receiving this digital content in the form of multimedia data and for rendering it back. This restitution consists in providing the digital content at the level of the terminal in a form accessible to the user. For example, data received corresponding to a video is generally decoded, then restored at the level of the terminal in the form of a display of the corresponding video with its associated soundtrack. In the following, for the sake of simplicity, the digital content will be assimilated to a video and the reproduction by the terminal, or consumption by the user of the terminal, to a display on the screen of the terminal. The distribution of digital content is often based on client-server protocols of the HTTP family (standing for “Hyper Text Transport Protocol”). In particular, the progressive downloading of digital content, also called streaming, makes it possible to transport and consume the data in real time, that is to say that the digital data is transmitted over the network and returned by the terminal as it goes. and as they arrive. The terminal receives and stores part of the digital data in a buffer memory before returning them. 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, furthermore makes it possible to broadcast and receive data in different qualities corresponding for example to different bit rates. 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 right 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 account of the 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 content in streaming, 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 broadcast format standard on the Internet. It is based on the preparation of the content in different presentations of varying 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 primarily targeted protocol is HTTP, but other protocols (eg FTP) can also be used. The organization of the segments and the associated parameters are published in a manifesto 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 segments, and, depending on 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 variations in network conditions, particularly in terms of bandwidth, existing adaptive downloading solutions allow the client terminal to switch from one version of the content encoded at a certain speed, to another encoded at a certain speed. other speed, during the download. This is because 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 longer transmission time, and therefore present an increased risk of not being received on time. continuous restitution of content. The rendering terminal must therefore find a compromise between the overall quality of the content, and its uninterrupted reproduction, by carefully selecting the next segment to download, among the various encoding rates offered. To do this, there are different algorithms for selecting the quality of the content as a function of the available bandwidth, which may have more or less aggressive, or more or less secure, strategies.

The consumption of digital content in adaptive progressive download (HAS) is tending to democratize. It is used in particular by many streaming services (in French, streaming in streaming 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 broadcasting of television programs (Replay), or even Network PVR type offers (for “Network Personal Video Recorder”, ie a digital content recording service, carried out by the content provider itself rather than at the end user's home).

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

Such devices are conventionally connected to the HDMI port of a television set 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 type smartphone, connected to a 4G mobile network), in order to reproduce, 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 encoding techniques for digital content which are thus accessible by HAS adaptive progressive download.

A first known technique, called CBR (for the English “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 the English "Variable Bit Rate", which can be translated as "variable sampling rate"), allows the content to be encoded at a bit rate. variable, limited by a maximum bit rate called MBR (for "Max Bit Rate"). The average encoding 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 the “chunks” of very little animated scenes (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. Such a technique for VBR variable rate encoding of content is described in particular in patent document US 2016/0205162.

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 (quiet 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: a reduction is thus observed on average. 50% of network bandwidth usage, compared to CBR encoding, for the same video quality. It is easily understood that, for a content encoded according to a CBR technique, the apparent encoding rate exposed in the content description file, or manifest, is the constant encoding rate which applies for all the content, depending on the level of quality offered. Thus, a manifest file (MPD) conforming to the MPEG-DASH standard can contain the description of a content available in three different qualities (NI = 512 kb / s, N2 = 1024 kb / s, N3 = 2048 kb / s) , where NI, N2 and N3 denote the constant encoding rates used for encoding all of the video segments of the content. The multimedia reproduction 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 a content encoded according to a VBR technique, the question arises of knowing what is the apparent encoding rate 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 rate of the video segments: this first option is advantageous in terms of reducing the consumption of bandwidth in the network. 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 which is used by the multimedia stream reader terminal to calculate the chunk recovery time, and thus determine the level of quality proposed in the manifest file to which it can claim. This therefore leads the terminal multimedia stream player to be selected at a level of quality that is probably lower than that to which it could actually claim in practice, and therefore, ultimately, for the operator, a reduction in the consumption of the bandwidth and a reduction in the load of the distribution network.

A second option consists in exposing in the manifest file, not the maximum MBR rate, but, for each content quality level, the associated average ABR encoding rate. This second option advantageously makes it possible to improve the quality perceived by the user.

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

The problem of managing the load and congestion of the operator's network, in the context of downloading multimedia content, is discussed in particular in patent document WO 2017/167958 in the name of the Applicant, for the particular context. of a cellular network. However, this document does not mention the particular problem of encoding the content using a variable bit rate technique of the VBR type. In order to reduce congestion in a cell of the network, it proposes to modify on the fly the manifest file associated with a content, by removing from this file certain bit rates deemed too high in relation to a network load criterion.

There is therefore a need for a technique for preparing digital content accessible by HAS download and encoded according to a variable 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 adapt finely to the context, very particularly, but not exclusively, to the particular load context of the content distribution network and of the associated servers.

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

There is also 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.

Disclosure of the invention

The invention responds to this need by proposing a method for managing access to digital content accessible by adaptive progressive download (HAS) by a multimedia stream reader terminal connected to a distribution network for said content. Digital content is associated to a digital content description file, comprising a list of time segments (Cli @ Nj) of the content each associated with several quality levels of the content.

The temporal segments of the digital content are encoded according to a limited variable rate (VBR) encoding method, for a given quality level, by a maximum encoding rate (MBR) of said segments for said level.

According to the invention, such a method comprises a determination of at least one load criterion (ChNet) of the distribution network, and an adaptation, as a function of said at least one determined load criterion, of the apparent encoding rates exposed in the description file. The adaptation of an apparent encoding rate, for a given quality level, assigns to said apparent encoding rate a value between the maximum encoding rate for said given quality level and a corresponding average encoding rate to an average of the encoding rates of the segments of said content for said given quality level.

Thus, the invention is based on a completely new and inventive approach to the management of access to digital content made available to user client terminals for adaptive progressive downloading of the HAS type, when these contents are encoded according to a technique. VBR variable rate encoding.

In fact, 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 MBR rate or the average ABR rate, the technique of the invention proposes, on the contrary to changing over time the apparent bit rate exposed in this description file, as a function of 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 operator's network load. Network load is understood here to mean all of the load generated on the content servers and also on the consumption of bandwidth in the operator's network.

According to a first embodiment, for a given quality level, the apparent encoding rate takes a value equal to (MBR-ABR) / 100 * ChNet + ABR, where MBR designates the maximum encoding rate of the segments of the content for said given quality level, ABR designates the average encoding rate of the content segments for said given quality level 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 restored to the client, without however optimizing the reduction in the load on the network. 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 load criterion ChNet takes the value 0, the operator constructs 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 improvement in video quality provided to the customer is maximized, without limiting the use of bandwidth. In fact, 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 rate value which increases to approach the maximum MBR rate when the value of the ChNet load criterion approaches 100.

Such an approach for determining the apparent rate to be exposed in the manifest file provides an advantageous feedback loop.

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

Thus, the operator constantly monitors and monitors the network load linked to the distribution of HAS content, and adapts its construction strategy for manifest files, depending on the load measured. This ensures optimum adaptability of the content proposal made to customers as a function of the actual load of the network, 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, so-called LIVE content is open content for which the client terminal must download the description file very regularly, generally 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 content segments.

According to another aspect, said at least one network load criterion also takes account of at least one parameter belonging to the group comprising: a network load prediction; electricity consumption from the network; a period of the year; a schedule for updating network equipment. 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 effective measured 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 the peaks recorded in consumption, for example during a period of extreme cold alert.

It is also possible to take account of network load predictions, obtained by observing loads during past periods that have elapsed. 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 periods of holidays, or weather conditions to predict the load on the network: in fact, when the weather is bad, we see that the video consumption is higher.

We can also voluntarily modify the apparent bit rate exposed in the manifest file, for example in the event of maintenance or update operations of certain equipment or certain platforms of the content distribution network, to lighten the load on the other equipment. .

We can also act on this apparent flow to take account of 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 needs. priorities, such as teleworking.

The invention also relates to a computer program product comprising program code instructions for implementing a method as described above, 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 a 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 can be a transmissible medium such as a signal. electrical or optical, which can be routed via an electrical or optical cable, by radio or by other means, so that the computer program it contains can be executed remotely. The program according to the invention can in particular be downloaded over a network, for example the Internet network.

Alternatively, the recording medium can 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 managing access to digital content accessible by adaptive progressive download (HAS) by a multimedia stream reader terminal connected to a content distribution network. The digital content is associated with a description file of the digital content, comprising a list of time segments (Cli @ Nj) of the content each associated with several quality levels of the content. The time segments of the digital content are encoded according to a variable rate (VBR) encoding method limited, for a given quality level, by a maximum encoding rate (MBR) of the segments for the given level.

According to the invention, such a platform comprises a computer capable of adapting the apparent encoding rates exposed in the description file, as a function of at least one load criterion (ChNet) of the distribution network. The computer is able to assign to an apparent encoding bit rate, for a given quality level, a value between the maximum encoding bit rate for the given quality level and an average encoding bit rate corresponding to an average of the bit rates. encoding segments of the content for the given quality level.

It will be noted that this platform can be dissociated from the platform for making the content available, the structure and operation of which are not affected by the technique of the invention.

Advantageously, the value assigned by the computer to the apparent encoding rate for a given quality level is equal to (MBR-ABR) / 100 * ChNet + ABR, where MBR designates the maximum encoding rate of the segments of the content for the given quality level, ABR designates the average encoding rate of the content segments for the given quality level 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 managing access to digital content comprises a module for measuring a load of the distribution network and the computer assigns to said at least one load criterion of the network a value which is 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: a network load prediction; electricity consumption from the network; a period of the year; a schedule for updating network equipment.

Presentation of figures

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

[Fig 1] presents a progressive download architecture on a mobile network based on the use of adaptive streaming according to the invention;

[Fig 2] illustrates in the form of a schematic flowchart the different steps of the process for preparing a content according to one embodiment of the invention;

[FIG. 3] 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;

[Fig 4] shows the hardware structure of a platform for preparing digital content implementing the method 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 by HAS progressive download and encoded according to a VBR variable rate encoding technique, in order to change the apparent rate exposed in these description files. , according to one or more load criteria of the distribution network.

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

The terminal 3, for example an intelligent telephone 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 to demand, and makes them available to client terminals.

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

In this client-server context, it is common practice, to exchange data between the client terminals 3, 4 and the server 2, to use an adaptive progressive download 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, taking into account the variations in bandwidth 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 string, corresponding for example to different bit rates. 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). Each quality level is itself split 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, addresses of fragments, etc.) are generally grouped together in a parameter file, called a description file. It will be noted that this parameter file can be a computer file or a set of descriptive information about the content, accessible at a certain address.

The terminals 3, 4 have their own characteristics in terms of decoding capacity, display, etc. In a progressive adaptive download context, they can adapt their requests to receive and decode the content requested by the user at the quality that best suits them. In our example, if the contents are available at apparent speeds 512 kb / s (kilobits per second) (Resolution 1, or level 1, noted NI), 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, the content number i is denoted “Ci @ Nj” 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 coming from the extended network 1 and ensure their decoding, and possibly their reproduction on their screen, or their transmission to the HDMI key 8 for reproduction on the television screen 5. As a variant, the Decoders can be found elsewhere in the network, in particular at the level of an element of STB type (standing for Set-Top-Box) (not shown) associated with a television set.

In this example, to view a content, the terminal 3, 4 or 8 firstly retrieves an address from the description document 7 of the desired content (for example, C1). In the following, we will assume that this file is a manifest type file 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 be already 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 (NI = 512 kb / s, N2 = 1024 kb / s, N3 = 2048 kb / s) of the contents fragmented is presented in appendix 1. This simplified manifest file describes digital content in 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 the bandwidth. Each fragment corresponds to a certain duration (“duration” field) with several quality levels and allows 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. :

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

- "Cl_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 at 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: // my content segment for example).

It is assumed here that the HDMI key 8 is connected to the television 5 by connection to the HDMI port of the latter, and is used to restore, on the screen of the television 5, a content C1, described in a manifest file 7. It will be noted that the content C1 can be a television program broadcast live or delayed, 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, through which it can access the extended communication network 1, for example via a 4G connection.

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

The content fragments obtained by the 3 smartphone or tablet 4 are for example transmitted to the HDMI ^® wireless key 8, which controls display on the TV screen 5 to return to the user.

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

During a first step referenced 20, the content C1 is encoded according to a VBR variable rate encoding technique. In other words, the content C1 is split into segments, or chunks, of constant duration, for example 2s. Each segment of the content C1 is then encoded according to an encoding rate which can fluctuate, depending on the nature of the content over the duration of the segment. This encoding rate is however limited by the maximum encoding rate MBR (for a given quality level or resolution). The average encoding rate of the content C1 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 lines in dotted lines represent respectively (for a given level of quality or resolution) the maximum encoding bit rate MBR which is reached for this content C1, and the average encoding bit rate ABR, corresponding to the average of the bit rates. encoding of each segment.

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 load criteria can also take into account other load parameters, such as: a period of the year: thus, in winter, in the event of a very cold warning, it may be useful to consider reducing the load. consumption by the operator's network; a political decision by the operator, who may wish to favor the quality perceived by its customers or, conversely, reduce the load on its 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, who 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 influencing directly or indirectly on 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 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, with a corresponding adaptation of the calculation formula which will be described below in relation to the step referenced 22.

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

Thus, for a given quality level or resolution j, the calculator of the content preparation platform calculates the apparent throughput Nj according to the formula: Nj = (MBRj-ABRj) / 100 * ChNet + ABRj

Thus, if the network load is zero, and the ChNet load criterion takes the value 0, the apparent encoding rate Nj which will be exposed in the manifest file 7 for the level of resolution j will be Nj = ABRj, i.e. the rate mean encoding at the quality level j for the video segments of the content C1. Thus, the improvement of the video quality supplied to the client is promoted, without limiting the use of the bandwidth. Indeed, this case corresponds to that where the operator's network is not used much (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 increases progressively between 0 and 100; the value of the apparent encoding rate Nj therefore also increases to approach the maximum value MBRj of the encoding rate for this level of resolution. Thus, optimization of the consumption of network resources is favored, to the detriment of the video quality perceived by the customer.

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

[Table 1]

When downloading the manifest file 7, 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 content server 2 exposes a video C1 in the form of “chunks” Cli @ Nj encoded at different quality levels j associated with encoding rates Nj, where the index i designates a temporal identifier of the “chunk” Cli @ 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 as a function of the available network resource. We do not describe here in more detail the way in which the HAS client module chooses the encoding rate of the next video fragment to download: there are indeed many algorithms allowing this choice to be made, the strategies of which are more or less secure. or aggressive. It is recalled, however, 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, depending 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 are based on a gradual increase in the quality level of the downloaded content fragments; others propose more risky approaches, with jumps in the levels of the encoding rates of 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 restitution of the content without interruption by the terminal. It is therefore necessary for the HAS client module to operate the best compromise between a reproduction quality, and therefore an encoding rate, as high as possible, and the download time of the fragment, which must be sufficiently low to allow a reproduction. continuously on the return terminal. For content C1 of LIVE type (ie 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 various associated apparent video qualities Nj.

Thus, in the example of Table 1, the content C1 is for example proposed 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 rates Nj exposed in the manifest file 7, the HAS download module of the terminal performs the download, for example, of successive fragments Cli @ Nl (i.e. the first temporal fragment at a first quality level 1 associated with an encoding rate of 540kb / s), then Cl ₂ @ N3 (i.e. the second time fragment at a quality level 3 associated with an encoding rate of 1.89Mb / s), then Cl ₃ @ N3 (i.e. the third temporal fragment at quality level 3 associated with the 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 file 7, and not on the effective size in kilobytes of the video segments that it receives. This size is in fact only used to calculate the chunk recovery time, and thus to 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. Cl ₂ @ 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 rates makes it possible to optimize the consumption of the operator's network resources.

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

If the network load fluctuates, and the value of the ChNet load criterion changes, the apparent encoding rates exposed in manifest file 7 will also be modified, or adapted, in the next version of manifest 7, downloaded by the terminal media stream player, for example 60 s later. Thus, if the ChNet load criterion goes from a value 80 to a value 40, the apparent encoding rates exposed in the following version of the manifest file 7 become: [Table 2]

replaced by the values of the apparent encoding rates Nj of Table 2.

The load having decreased, we can expose lower apparent encoding rates in the manifest file 7, and thus promote the improvement of the video quality provided to the user.

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

The above embodiment has been described in the context of a video content C1 broadcast in real time, or LIVE, for which the manifest file is downloaded at regular time intervals by the multimedia stream reader terminal, which allows to ensure enslavement.

It will be noted that the technique of the invention can also find application for content of the VOD type (for “Video On Demand”, or video on demand), or “replay” content (in French, catch-up television), based on the predictive nature of the evolution of the network load. Indeed, for such content, the manifest file 7 is downloaded once and for all, when the customer begins to view the content. However, depending on the download time of this manifest file 7, 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 load ChNet, and thus determine the optimum apparent encoding rates to be exposed in the manifest, according to the principle of Fig 2. In this case, the value of ChNet does not result only from a measurement of the network load, but a detailed knowledge of the daily, weekly or seasonal recurring peaks of load. 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 rates will be able to be exposed in the manifest file, depending on the time at which this content is requested by the user. .

In relation to FIG. 4, we now present the hardware structure of a platform 40 for managing access to digital content accessible by adaptive progressive download (HAS), connected to the distribution network 1 of an operator.

It conventionally comprises memories M associated with a processor CPU. The memories can be of the ROM type (standing for “Read Only Memory”) or RAM (standing for “Random Access Memory”) 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 supplies the manifest file 7. The platform 40 furthermore comprises a MONIT_ChNet module for measuring the load of the network 1, capable of assigning a value to the ChNet load criterion. This value can be recorded for example in the memories M of the platform 40.

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

It also includes a PREP_MANIFEST module for preparing the manifest file 7, for the content Ci, which exposes in this file the apparent encoding rates calculated by the computer CPU, as a function of the ChNet load criterion delivered by the MONIT_ChNet module and of the values maximum MBR encoding rate and average ABR encoding rate supplied by the ENCOD encoding module (Ci) for a given quality level of the content Ci.

It will be noted that the term module can correspond just as well to a software component as to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subroutines 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. Likewise, a hardware component corresponds to any element of a hardware set (or hardware) 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 controlled by a computer program, stored in a read only memory (for example a ROM or hard drive). On initialization, the code instructions of the computer program are, for example, loaded into 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 rates to be exposed in the manifest file 7, according to the algorithm of FIG. 2.

Fig 4 illustrates only one particular way, among several possible, of achieving 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 performed either on a reprogrammable computing machine (a PC computer, a DSP processor or a microcontroller) executing a program comprising a sequence of instructions, or on a dedicated computing machine (for example a set of logic gates such as an FPGA or ASIC, or any other hardware module). APPENDIX 1: example of manifest file

Claims

1. A method of managing access to digital content accessible by adaptive progressive download (HAS) by a multimedia stream reader terminal connected to a network (1) for distributing said content, said digital content being associated with a file (7 ) description of said digital content, comprising a list of time segments (Cli @ Nj) of said content each associated with several quality levels of said content, said time segments of said digital content being encoded (20) according to a variable rate encoding method (VBR) bounded, for a given quality level, by a maximum encoding rate (MBR) of said segments for said level, an encoding rate, called apparent encoding rate, being exposed in said description file for each quality level of said content, characterized in that it comprises a determination (21) of at least one load criterion (ChNet) of said distribution network, and an adaptation (22), as a function of said at least one criterion e determined load (ChNet), of said apparent encoding rates (Nj) exposed in said description file (7), said adaptation of an apparent encoding rate (Nj), for a given quality level, affecting said apparent encoding rate (Nj) a value between said maximum encoding rate

(MBRj) for said given quality level and an average encoding rate (ABRj) corresponding to an average of the encoding rates of the segments of said content for said given quality level.

2. A method of managing access to digital content according to claim 1, characterized in that, for a given quality level, said apparent encoding rate (Nj) takes a value equal to (MBR-ABR) / 100 * ChNet + ABR, where MBR denotes said maximum encoding rate of content segments for said given quality level, ABR denotes said average encoding rate of content segments for said given quality level and ChNet denotes a value, between 0 and 100, assigned to said at least one load criterion.

3. A method of managing access to 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 criterion load (ChNet) of said network (1) is a function of said measurement.

4. A method of managing access to digital content according to any one of claims 1 to 3, characterized in that said at least one load criterion (ChNet) of said network (1) also takes into account at least a parameter belonging to the group comprising: a load prediction of said network; an electrical consumption of said network; a period of the year; a schedule for updating equipment of said network.

5. A method of managing access to digital content according to any one of claims 1 to 4, characterized in that said digital content () is broadcast over said network (1) in real time.

6. A computer program product comprising program code instructions for carrying out a method according to any one of claims 1 to 5, when executed by a processor.

7. A computer readable recording medium on which is recorded a computer program comprising program code instructions for performing the steps of the method according to any one of claims 1 to 5.

8. Platform (40) for managing access to digital content accessible by adaptive progressive download (HAS) by a multimedia stream reader terminal connected to a network (1) for distributing said content, said digital content being associated. to a description file (7) of said digital content, comprising a list of temporal segments (Cli @ Nj) of said content each associated with several quality levels of said content, said temporal segments of said digital content being encoded according to an encoding method at variable bit rate (VBR) bounded, for a given quality level, by a maximum encoding bit rate (MBR) of said segments for said level, an encoding bit rate, called apparent encoding bit rate, being exposed in said description file for each level of quality of said content, characterized in that it comprises a computer (CPU) capable of adapting said apparent encoding rates (Nj) exposed in said description file (7), as a function of at least a load criterion (ChNet) of said distribution network (1), said computer being able to assign to an apparent encoding rate (Nj) for a given quality level a value between said maximum encoding rate (MBRj) for said given quality level and an average encoding rate (ABRj) corresponding to an average of the encoding rates of the segments of said content for said given quality level.

9. Platform (40) for managing access to digital content according to claim 8, characterized in that said value assigned by said computer (CPU) to said apparent encoding rate (Nj) for a level of quality given is equal to (MBR-ABR) / 100 * ChNet + ABR, where MBR denotes said maximum encoding rate of content segments for said level of given quality, ABR designates said average encoding rate of the content segments for said given quality level and ChNet designates a value, between 0 and 100, assigned to said at least one load criterion.

10. Platform (40) for managing access to 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.