FR3103668A1 - Management of the adaptive progressive download of digital content over the mobile network with determination of a maximum encoding rate allowed over a session based on a bucket of data - Google Patents

Abstract

Management of the adaptive progressive download of digital content on a mobile network with determination of a maximum encoding rate allowed over a session as a function of a data bucket The invention relates to a method of managing the adaptive progressive download (HAS) of digital content within a multimedia stream reader terminal connected to a mobile communication network. Digital content is associated with a description file, comprising a list of content time segments, each associated with multiple content encoding rates. A maximum volume of data to be consumed within the mobile communication network during a session, called a data bucket, is allocated to the multimedia stream reader terminal. According to the invention, such a method comprises: an estimate (406), as a function of a volume of data consumed by adaptive progressive downloading of digital content during at least one period by the multimedia stream reader terminal, of a volume of data which could be consumed by the terminal by adaptive progressive downloading of the digital contents during the session; determining (407) a maximum allowed encoding rate for downloading time segments of digital content during the session so that the estimated data volume is less than or equal to a determined consumption threshold of the data bucket. Figure for the abstract: Fig 4

Description

Management of adaptive progressive downloading of digital content on the mobile network with determination of a maximum encoding rate authorized over a session according to a data bucket

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 management of the data consumption of a user wishing to access digital content using a technique known as adaptive progressive downloading, through a mobile communication network.

Prior art

Access to multimedia content, such as television or video on demand, is possible today, for most rendering terminals, even when they are on the move, through a mobile communication network. 4G type for example.

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 Transfer 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 mode of distribution is particularly useful when the speed available to the user is not guaranteed for real-time video transfer, which is particularly the case when the terminal is connected to a mobile communication network, for example a 4G type network, known for its bandwidth variability.

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 a format standard for audiovisual 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 flow rate:

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

Thus, to adapt to the variation in network conditions, in particular in terms of bandwidth, and to the variation in the conditions of content distribution by the server, the existing adaptive downloading solutions allow the client terminal to switch from one version content encoded at a certain bit rate, to another encoded at another bit rate, 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 TV Key® 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.

In this specific context of broadcasting content on a mobile communication network, it is important to take into account the data consumption limit authorized for the client terminal during a session. This limit may correspond to a volume of data associated with a prepaid card purchased by the user, or with a monthly plan that he has subscribed to with the operator of the extended communication network, for example the mobile network. This maximum volume of consumable data during a session is more commonly referred to as the data bucket, or “data bucket”.

Indeed, the English term “data” means “data”. In mobile parlance, data represents data downloaded to a phone or mobile device via the Internet. A mobile data plan therefore allows users to browse the Internet with a mobile phone, according to specific volumes allocated by the network operator. Unlimited packages in this area do not exist strictly speaking. Data plans include a maximum authorized data volume, generally expressed in Megabytes or Gigabytes. Similarly, a prepaid card purchased from the operator of the mobile communication network is associated with a maximum volume of data consumable by the user.

When the user consumes content or a data stream using an HAS adaptive progressive downloading technique on a mobile communication network, the HAS client embedded on his multimedia stream player terminal has, in principle, the objective of achieving the best possible playback quality for the user, depending on resource and bandwidth constraints, and therefore aiming for the maximum encoding bit rate available for the content to be downloaded. As a result, downloading content can consume a very large proportion, or even all, of the data bucket allocated to the user, without the latter having any means of action to prevent it.

This situation is problematic insofar as it can lead the user, in a situation of mobility, to exceed his "data bucket", which can prove to be expensive, or to consume all of it at the very beginning of the month. (or more generally at the start of the session), depriving him of resources for the end of the period (i.e. of the session). It can also lead the user to consume too much of his data bucket for downloading HAS content (for example, TV programs in HD), to the detriment of other data-consuming applications (for example, e-mail , instant messaging, geolocation system, etc.)

There is therefore a need for a technique for managing the adaptive progressive downloading of content, in particular for a user connected to a mobile communication network, allowing better control of his data consumption, compared to previous solutions. In particular, there is a need for such a technique which allows a user to limit the portion of his data bucket devoted to the adaptive progressive downloading of content during a session, while guaranteeing him access to this content while throughout this session.

There is still a need for such a technique which allows a constant and automatic adaptation of a user's HAS flow consumption profile, according to his habits and needs.

The invention meets this need by proposing a method for managing the adaptive progressive downloading (HAS) of digital content within a multimedia stream player terminal connected to a mobile communication network. A digital content is associated with a description file, comprising a list of time segments of the content, each associated with several encoding bitrates of the content. A maximum volume of data to be consumed within the mobile communication network during a session, called a data bucket, is allocated to the multimedia stream player terminal.

According to the invention, such a method comprises:

• an estimate, based on a volume of data consumed by adaptive progressive downloading of digital content over at least one period by the multimedia stream player terminal, of a volume of data that could be consumed by this terminal by downloading adaptive progressive of digital contents during the session;
• a determination of a maximum encoding rate authorized for the downloading of time segments of the digital content during the session so that the estimated data volume is less than or equal to a determined consumption threshold of the data bucket.

Thus, the invention is based on an entirely new and inventive approach to adaptive progressive downloading of content, in the case where the multimedia stream player terminal has a maximum volume of consumable data during a session within its mobile content access network. Such a data consumption limit value, also called "data bucket", may correspond to a volume of data authorized within the framework of a monthly package taken out with a network operator, or associated with a prepaid card purchased from this operator. The session then corresponds to the periodicity of the plan (for example, one month for a monthly plan), or to the period of validity of the prepaid card.

The method according to one embodiment of the invention proposes to determine a maximum encoding rate of the temporal segments of the content authorized during the session, in order to avoid overconsumption of the data bucket on this session. Thus, instead of systematically downloading the time segments of the content at the maximum accessible encoding rate, taking into account the constraints of the network and the content server, this encoding rate is limited, for better control of the consumption of the data bucket .

The maximum encoding bit rate authorized for the session is determined by observing the user's consumption over one or more period(s), and estimating, based on this observation, what his consumption could be for the session.

It is thus possible for the user to benefit from the advantages of HAS adaptive progressive downloading of content, without this being done to the detriment of his data bucket, which must be able to be used for other purposes or for other applications: the user is thus offered interesting tools for controlling his data consumption.

According to an advantageous characteristic, an initial value of the determined consumption threshold of the data bucket is chosen by a user, for example in the form of a proportion of the data bucket.

Thus, when the user for example accesses the HAS content download service for the first time, he may be asked to indicate whether or not he wishes to benefit from consumption control according to one embodiment of the invention. . If so, the user may be asked to indicate whether he wishes to limit his consumption of HAS content to 50%, 70%, or any other proportion of his data bucket. The user thus benefits from controlling the conditions of his consumption of HAS content.

This choice can be made via the interface of its restitution terminal, for example by selecting a highlighted menu or by typing in a pop-in window. It can be valid only for a given session, or be defined as an initialization parameter of the HAS adaptive download service, for all sessions.

If the consumption threshold is defined in the form of a proportion of the data bucket, it is of course necessary that this data bucket is also known to the multimedia stream reader terminal.

According to one embodiment, this data bucket is entered by the user on a restitution terminal associated with the multimedia stream reader terminal. It will be noted that the restitution terminal can be the multimedia stream reader terminal itself (for example an intelligent mobile telephone of the smartphone type), or be separate from the latter (for example a television set connected to an HDMI Key).

Thus, the user pre-enters his data bucket, so that this information is accessible to the multimedia stream reader terminal. This entry can take place during an installation or configuration phase of the adaptive progressive download service. It can also be requested from the user by displaying a "pop in" type window, which informs him of a new feature on the service, and asks him about this new useful information that is his bucket. date.

Alternatively, if the mobile network operator has end-to-end control of the adaptive progressive download service, it can extract the user's data bucket information from its profile or billing, so that it is accessible to the multimedia stream player terminal.

According to a first aspect, the period is included in the session, and the estimate is made by extrapolating, over the session, the volume of data consumed over the period.

For example, for a session corresponding to a monthly plan, the observation period may correspond to the first week of the month. Depending on the volume of data consumed during this first week, it is possible by extrapolation to estimate what the volume of data consumed will be over the month, and to compare it to the consumption threshold set by the user. If the set threshold is exceeded, the method according to one embodiment of the invention proposes to restrict the maximum encoding rate authorized for the adaptive downloading of the time segments of content at the end of the month, in order to avoid or limit this overshoot.

According to another aspect, the period is of the same duration as the session and the estimate takes account of at least one calendar parameter of the session with respect to the period.

Thus, for example, the volume of data that could be consumed during a month N is estimated, based on the volume of data that was consumed during month N-1, or during month N of the year former. We can also take into account the season, or a vacation period, or public holidays.

In one embodiment, the estimate can jointly take into account the volume of data consumed over a first part of the session (for example during the first week of a monthly plan), and the volume of data consumed during a previous session (for example during the same month of the past year). The estimate can then perform a weighted average calculation, based on these multiple observations.

According to yet another aspect, the estimation and the determination of the maximum encoding rate are updated at least twice during the session.

For example, in the context of a monthly plan, the control of not exceeding the threshold and the adaptation (if necessary) of the maximum authorized speed are carried out on a weekly basis, until the end of the month. Thus, we jointly optimize the quality of experience of the user and the control of his consumption. Indeed, significant consumption during the first week can lead to a strong limitation of the maximum authorized encoding bit rate, and therefore to a strong reduction in the quality of content reproduction; however, if the user consumes little content during the following two weeks, it is then possible, for the last week of the month, to authorize a higher maximum encoding rate, and thus improve the experience of the user by offering them better quality content.

According to one embodiment, when initializing the session, the maximum authorized encoding bit rate is assigned a value of a maximum authorized encoding bit rate determined during a previous session. In other words, at the end of the session, the next session is reinitialized with the same threshold and the consumption profile at the end of the previous session.

This gives priority to the user's quality of experience, avoiding excessive fluctuations in the quality of the content when changing sessions.

According to another aspect, if, at the end of the estimation, the estimated volume is substantially greater than the determined consumption threshold of the data bucket, such a method comprises sending an alert message to a user of the terminal multimedia stream player, and for example an invitation to modify the consumption threshold.

Thus, in the event of forecasting a strong overshoot of the threshold set by the user, the client is informed, for example by displaying a message on a playback terminal associated with the multimedia stream player terminal. This message can inform him of the possible need to revise the value of the threshold he has set, to avoid, for example, too great a deterioration in the quality of content reproduction, or simply invite him to reduce his consumption of content on the end of the session.

According to one embodiment, such a method for managing the adaptive progressive downloading of digital content also comprises an analysis of the estimated data volumes consumed over a plurality of sessions, and an adaptation of the determined consumption threshold of the data bucket as a function of this analysis.

Thus, it is possible to automatically adapt the consumption threshold initially set by the user, over time, taking into account, for example, the seasonality of its consumption.

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 managing the adaptive progressive downloading (HAS) of 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 device for managing the adaptive progressive downloading (HAS) of digital content within a multimedia stream player terminal connected to a mobile communication network. A digital content is associated with a description file of the digital content, comprising a list of time segments of the content each associated with several encoding bitrates of the content. A maximum volume of data to be consumed within the mobile communication network during a session, called a data bucket, is allocated to the multimedia stream player terminal.

Such a device includes:

• a module for estimating, based on a volume of data consumed by adaptive progressive downloading of digital content over a period by the multimedia stream player terminal, a volume of data that could be consumed by the player terminal multimedia streams by adaptive progressive downloading of the digital contents during the session;
• a module for determining a maximum encoding rate authorized for downloading time segments of the digital content during the session so that the estimated data volume is less than or equal to a determined consumption threshold of the data bucket.

The invention also relates to a multimedia stream reader terminal which comprises a device for managing the adaptive progressive downloading (HAS) of digital content as described above.

The adaptive progressive downloading management device, the restitution multimedia stream reader terminal and the computer program according to embodiments of the invention present in combination all or part of the characteristics set out throughout this document. In particular, they have at least the same advantages as those conferred by the method for managing the adaptive progressive downloading of a content according to an embodiment of the present invention.

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;

schematically illustrates the hardware structure of a multimedia stream reader terminal integrating an adaptive progressive downloading management device according to one embodiment of the invention;

describes an example of limiting the maximum quality of a multimedia stream obtained in adaptive progressive downloading mode by a multimedia stream reader terminal of [Fig 1] or [Fig 2];

presents in flowchart form the different steps of the adaptive progressive downloading management method according to one embodiment of the invention.

Detailed Description of Embodiments of the Invention

The general principle of the invention is based on the automatic adaptation of a user's HAS flow consumption profile during a session, based on an observation of the user's consumption usage over one or more periods. .

We now present, in relation to , a progressive download architecture based on the use of adaptive streaming according to the invention.

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 mobile communication network 1, for example a network of the 4G type. 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 video and/or audio compression) with a certain 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 512 kb/s (kilobits per second) (Resolution 1, or level 1, denoted N1), 1024 kb/s (N2), 2048 kb/s (N3) and 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 mobile 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. Alternatively, the decoders can be located elsewhere in the network, in particular at the level of an element of the 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 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 of fixed or determinable duration.

In this example, the HDMI key 8 is 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.

represents an architecture of a multimedia stream reader terminal according to one embodiment of the invention, for example the HDMI key 8, or the smart telephone 3, of [Fig 1]. The example of the HDMI 8 key is described more specifically below.

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 HDMI key 8 communicates with the extended Internet network 1 via the WIFI module by local wireless communication with another communication terminal, for example the smart telephone 3. The HDMI key 8 further comprises an adaptive progressive download module HAS capable of to request a progressive downloading of one of the contents to one of the qualities proposed in a description file 7. This description file 7 can be recorded for example in the memories M of the HDMI key 8 or be located at outside.

The HDMI 8 key also includes an ESTIM module for estimating the volume of data that could be consumed by the HDMI 8 key, during the session, based on an observation of the volume of data that has actually been consumed by the key. HDMI 8, per HAS download of content requested by the user during one or more time periods.

Such an ESTIM module collects information relating to the consumption of the user's HAS streams during an observation period, such as the duration of the contents that he has viewed, their quality of restitution and the encoding bit rate. corresponding downloaded content time segments. Such an ESTIM module calculates, from the information collected, an estimate of the volume of data that can be consumed in HAS by the user during the session.

The HDMI key 8 also includes a DISP module for managing the interface with a restitution terminal, for example the smart telephone 3 or the television set 5. Via such a DISP module, the HDMI key 8 obtains for example information on any user interactions with the rendering terminal (action on the television remote control, for example by pressing the volume key or a channel change key, or selection in a menu highlighted on the screen of the television of a maximum consumption threshold authorized during the session, or selection of this consumption threshold on the touch screen of the smart telephone 3 or of the tablet 4), and by which it can control the display on the screen of the terminal displaying pop-up windows, allowing it to deliver messages, information on the volumes of data consumed or remaining, or alerts to the user.

It also comprises a module DET for determining a maximum encoding rate authorized for the adaptive progressive downloading of segments of a content during a session, which drives the adaptive progressive downloading module HAS, in order to force the latter to request a progressive downloading of the content at a quality, proposed in the description file 7, lower than the optimum quality to which it could claim, in the case where this optimum quality is higher than the maximum authorized quality determined by the module DET.

The HDMI key 8 according to one embodiment of the invention can also contain other modules such as a hard disk (not shown) for storing video fragments, a content access control module, a data processing module commands received from a tablet or smartphone on which the HDMI key control application is installed, thanks to which the user can control its operation, etc. Indeed, such an HDMI key 8 does not generally contain an I/O interface module, and it is the I/O interface module of the user's smart telephone 3 or of his tablet 4, or of the television 5, which is used by the latter to choose, for example, its content.

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 an HDMI 8 key comprises a random access memory (for example a RAM memory), a processing unit equipped for example with a CPU processor, and controlled by a computer program, representative of the progressive download management module adaptive HAS, stored in a read only memory (for example a ROM memory or a 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 RAM contains in particular the manifest 7 description file. The processing unit processor controls the determination of the volumes of data consumed by downloading of content during different periods, the display of pop-up windows on of the restitution terminal, and the restriction of the quality of the content downloaded during the session, through the choice of the time segments and the associated encoding bit rates to be downloaded, and the transmission of corresponding commands to the HAS client module.

In the case where the multimedia stream reader terminal considered is not the HDMI key 8 but, for example, the smart telephone 3, the architecture proposed on remains the same, except that the terminal communicates directly with the extended communication network via a mobile communication module, for example of the 4G type, instead of the WIFI module. The restitution terminal is then the multimedia stream reader terminal itself, so that the display control module DISP controls the display of the various alert messages directly on the screen of the smart telephone 3, and the DET module directly receives the value of the consumption threshold of the data bucket chosen by the user on the screen of the smart telephone 3 itself.

only illustrates one particular way, among several possible, of making a multimedia stream player terminal, so that it performs the steps of the method detailed below, in relation to [Fig 3] (in any one of the different modes of embodiment, 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).

We now present, in relation to and [Fig 4], an example of limiting the maximum quality of the multimedia streams obtained during a session in adaptive progressive download mode by a multimedia stream reader terminal 30, for example the HDMI key 8 or the smart phone 3 of [Fig 1] and [Fig 2]. It is recalled that by session is meant the period associated with a package taken out with an operator of the mobile communication network 1 (for example one month for a monthly package), or the period of validity of a prepaid card purchased for this operator.

The multimedia stream player terminal 30 is connected to a playback terminal TX (for example the HDMI key 8 is connected to the television set 5 via an HDMI link or to the smartphone 3 via a WIFI link ). It notably comprises a DISP 300 module for interfacing with the restitution terminal TX, an ESTIM module 301 for determining the volume of data consumed by HAS downloading of content during a given period, a DET module 302 for determining a maximum encoding bit rate authorized for downloading content during a session, and a HAS 303 client module.

Consider, for example, the case of a customer who wishes to watch television programs, using his CléTV® 8 and his smartphone 3 in modem mode (4G connection sharing), on his mobile plan, taken out with the operator of his communications network. In this example, we consider that the customer has subscribed to a monthly package, to which is associated a monthly data bucket of 50GB/month.

It is assumed that the multimedia stream reader terminal 30 is aware of this data bucket of 50 GB/month.

In the case where the HAS download service is controlled from start to finish by the mobile network operator 1, the user's data bucket is known to the operator, from the offer subscribed to by the user. user, or their billing information. It is therefore the operator who transmits this information to the terminal 30.

Alternatively, this data bucket can also be filled in by the user himself. It can for example be entered via the interface of the restitution terminal TX (smart telephone 3, or television 5 for example), during an installation phase of the HAS download service, or in response to a request from the provider of this service, for example via a "pop in" window informing the user of new functionalities or new features of the service.

When the customer accesses the HAS download service for the first time (INIT step 400), or during the initial installation of this service on his terminal, the DISP module 300 manages the display on the screen of the restitution terminal TX (here, the smartphone 3) of a dialogue window, in which the customer is asked if he wishes to activate the consumption control of his data bucket (step CTRL_C° 401). The customer's response can be made by selecting a menu highlighted on the screen of the smartphone 3.

If the customer answers in the affirmative, the DISP 300 module manages the display of a new dialogue window on the screen of the terminal, in which the customer is invited to enter the consumption threshold that suits him (step SEL_THR 402 ). This threshold can be expressed as a proportion of its data bucket, or as a maximum volume of data not to be exceeded, expressed for example in GB.

For example, the DISP 300 module controls the display of a window in which different consumption limits are proposed, such as 30% of the data bucket, 50% or 70% of the data bucket. The customer selects the threshold that suits him by moving a cursor corresponding to a highlighted display of one of the proposed thresholds.

This threshold can be chosen once and for all when the HAS service is initialized, or updated at each session start. For example, in the case of a monthly plan, at the beginning of each month, the customer can choose the threshold he wishes to apply for the coming month.

It is assumed in this example that the customer selects, by touch input on the screen of his smartphone 3, a consumption threshold of 50% of his data bucket, which means that he does not wish to consume more than half of its data bucket for downloading HAS television programs during the month. He wishes to keep data resources for other applications, such as geolocation applications, the management of his electronic or instant messaging, or access to websites.

It is assumed that on the HDMI 8 Key that he wants to use, the multimedia stream transport technology is of the HAS type with five levels of encoding bitrate and resolution available, according to the example given in the table [Table 1] below.

Resolution Debit 320x180 pixels 600kbps 569x320 pixels 1.2Mbps 1024x576 pixels 2.1Mbps 1280x720 pixels 3Mbps 1920x1080 pixel 5Mbps

After initialization of the HAS download service, the customer begins to use the TV Key 8, for example to watch a television program live on a high-definition channel (step START_HAS(D<Dmax) 404). During initialization, the maximum authorized encoding bit rate set by the DET 302 module is initialized to the maximum encoding bit rate available in HAS (see Table 1), i.e. in this example 5 Mb/s (step Dmax:=Dmax( HAS) 403).

The ESTIM module 301 of the multimedia stream reader terminal 30 begins to measure the duration of consumption of content downloaded in HAS, and the average rate of stream consumed (step MES_C° 405).

For example, the ESTIM 301 module collects the following information:

• the customer watched content lasting 30 minutes per HAS download at a rate of 5 Mb/s on Monday;
• the customer watched 2 hours of content by HAS download at a rate of 5Mb/s on Tuesday;
• the customer watched content lasting 1 hour per HAS download at a rate of 5 Mb/s on Wednesday;
• Etc.

After a week of observation for example (i.e. in this example approximately a quarter of the duration of the session associated with the data bucket), the ESTIM module 301 can therefore calculate an average consumption of data over the period. In this example, it is assumed that this average consumption amounts to one hour per day at the maximum encoding rate of 5Mb/s, i.e. 5Mb/s*3600s/d=18Gb/d, i.e. 2.25GB/d, or even 2.25GB/d*7d/week=15.75GB/week.

By carrying out an extrapolation over the entire duration of the session, i.e. one month, the ESTIM module 301 can estimate that the customer will consume 15.75 GB/week*4 weeks/month=63 GB during the month (step ESTIM_C ° 406).

We remind you that the customer's data bucket is 50 GB/month, and that he does not wish to devote more than 50% of his data bucket to downloading content in HAS, i.e. no more than 25 GB.

After only one week, and if it continues, for the rest of the month, to consume HAS content at the same rate of consumption, the ESTIM 3011 module can therefore predict a strong overconsumption of the customer's monthly data bucket.

It is therefore appropriate to limit the customer's consumption of HAS flows over the next few weeks, to respect their wish to control consumption.

To do this, the DET module 302 will set a maximum authorized encoding rate at which the next HAS contents can be downloaded until the end of the month (step DET_Dmax 407). The ESTIM module 301 provides the DET module 302 with the data collected relating to the customer's consumption during the first week of observation, i.e. 15.75 GB.

In view of the consumption threshold set by the customer at 25GB, the DET module 302 determines that the customer can still devote 25GB-15.75GB=9.25GB=74Gb of data for downloading HAS content during the month, i.e. at over the next three weeks or so.

Over the next three weeks, the daily consumption of HAS content must therefore be limited to 74Gb/(3 weeks*7 days)=3.52Gb/day.

Assuming that the duration of daily consumption of HAS streams will remain constant at around one hour per day, the DET module 302 deduces that the available bit rate for one hour of consumption is 3.52 Gb/3600=977 kb/s . Given the different throughput levels available for the TV Key 8 (see Table 1), it is necessary to limit the maximum resolution to which the customer can claim to 320x180 pixels.

Thus, until the end of the current session, lasting one month, i.e. over the next three weeks approximately, the DET 302 module will restrict the maximum encoding bit rate authorized for the downloading of content by the HAS 303 module to match this very low resolution of 320x180 pixels.

The maximum authorized encoding rate Dmax is provided to the HAS download module, which respects it for the download of all the content required by the client during the duration of the session.

The consumption measurement MES_C° 405 continues during the second week of the month. At the end of this second week, the ESTIM module 301 carries out a new estimate of the consumption of HAS flows over the month (step ESTIM_C° 406), by extrapolation of the measurement carried out over the first two weeks. On the basis of this new estimate, the module DET 302 can determine a new maximum authorized encoding rate Dmax during a step DET_Dmax 407.

Thus, if the customer has reduced his duration of consumption of HAS content during the second week compared to the first week, the Dmax speed can be revised upwards, so that the next contents can be downloaded with a better resolution. at the end of the period.

Conversely, if the client has increased its consumption of HAS streams, it is possible that the DET 302 module must impose on the HAS download module a lower maximum encoding rate to avoid overconsumption of the data bucket, and/or a famine at the end of the month.

The same estimation and the same update of the maximum authorized encoding bit rate can be performed again at the end of the third week.

More generally, any frequency of measurement and updating of the maximum authorized encoding bit rate can be considered, depending on the duration of the session, and the desired tracking finesse.

At the initialization of the next session (i.e. at the beginning of the following month), the HAS content download service is initialized with, on the one hand, the consumption threshold chosen by the user during step SEL_THR 402 ( i.e. in this example 50% of the data bucket of 50 GB), but also the maximum authorized encoding bit rate Dmax calculated during the previous session (step DET_Dmax 407). For example, it is assumed that during this session, the user's consumption finally amounted to three quarters of an hour of HAS content per day, i.e.:

Consumable data for 4 weeks: 50%*50GB=25GB=200Gb

Consumable data per day: 200Gb/(4 weeks * 7 days)=7.14Gb/day

Speed available for 0h45 of daily consumption: 7.14/(45*60s)=2.64Mb/s

In view of the throughput levels available in [Table1], the maximum resolution authorized during the month which begins is established at 1024x576 pixels.

The maximum authorized encoding bit rate Dmax is therefore initialized for the new monthly session at 2.1 Mb/s. However, a new estimate and update can be made at the end of the first week, and so on at the end of each week, until the end of the month.

Referring to the example of , it is considered that during the month, the customer wishes to access content C1, for example a television program exposed by a content server HAS 2 in the form of “chunks” C1i@Nj encoded at different encoding rates Nj, where the index i designates a temporal identifier of the “chunk” C1i@Nj. In this example, the content C1 is for example offered in the form of fragments of duration 3s, with a first encoding bit rate N1=600 kb/s, a second encoding bit rate N2=1200 kb/s, a third bit rate of 'encoding N3=2100 kb/s, etc.

In a normal mode of operation, not shown on , the HAS module 303 performs the downloading, for example, of successive fragments C11@N1 (i.e. the first time fragment at an encoding rate of 600 kb/s), then C12@N3 (i.e. the second time fragment at a rate of encoding of 2100 kb/s), then C13@N4 (i.e. the third temporal fragment at an encoding rate of 3000 kb/s), ...

The various fragments downloaded by the HAS 303 client module are transmitted to the DISP 300 interface module for their restitution to the user on the screen of the restitution terminal TX.

The algorithm implemented by the HAS client module 303 to determine which fragment at which encoding bitrate must be downloaded in normal operating mode (that is to say outside the limitation of the maximum encoding bitrate authorized by the DET module 302) can be one of the already existing algorithms of the prior art. This algorithm will therefore not be described here in more detail.

Indeed, it is recalled that 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. There are many algorithms allowing the HAS module to choose the encoding bitrate of the next video fragment to be downloaded, 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 restitution of the content by the terminal 30. It is therefore appropriate for the HAS client module to operate the best compromise between playback quality, and therefore encoding bit rate, as high as possible, and fragment download time, which must be low enough to allow continuous playback on the restitution terminal TX.

In the embodiment illustrated in , on the other hand, the HAS client module 303 may not order the downloading of the fragment at the optimal encoding rate, in order to limit the consumption of the user's data bucket, as described above in relation to [Fig 4] .

Indeed, according to this embodiment of the invention, the module DET 302 defines an upper limit of the encoding rate of the content to be downloaded: the different fragments of the content C1 cannot then be downloaded at a higher encoding rate. at this upper limit determined by the DET module 302, in view of the observation of the quantity of data consumed by the client during the previous period, and of the consumption threshold set by the user with respect to his data bucket.

In this example, the maximum resolution allowed during the month is set to 1024x576 pixels and the maximum allowed encoding bitrate Dmax is initialized for the monthly session at 2.1Mb/s.

This Dmax value is provided by the DET 302 module to the HAS 303 module, so as to restrict the downloading of content fragments to the maximum encoding bit rate of 2.1 Mb/s.

Thus, as shown in , during a step referenced 310, the HAS module 303 retrieves the manifest file 7 in order to discover the available fragments of the video content C1, and the different associated video qualities Nj.

Next, the HAS client module 303 will successively download (312) the fragments C1 ₂ @N3, C1 ₃ @N3, C1 ₄ @N2, C1 ₅ @N1 and C1 ₆ @N3, that is to say, download the fragment of the best possible quality depending on the network constraints, but without ever exceeding the maximum value Dmax 311 of the encoding bit rate, which has been calculated by the module DET 302 as being equal to 2100 kb/s.

Thus, if after having downloaded the fragments C1 ₂ @N3, C1 ₃ @N3, C1 ₄ @N2 and C1 ₅ @N1, the HAS client module 303 determines, according to the network conditions, that the optimal rate of temporal fragment at which it can claim is 5000kb/s, it does not initiate the downloading of the next fragment at this optimal rate, but downloads the time fragment C1 ₆ @N3, at the maximum encoding rate authorized by the DET 302 module.

According to one embodiment of the invention, the DET module 302 can also take into account the seasonality of the user's consumption to establish the maximum encoding rate authorized over a period, and weight the estimate provided by the module ESTIM 301 according to calendar parameters such as the presence of holidays or public holidays during the session.

For example, to determine the maximum encoding rate authorized during the month M of the year N, the module DET 302 can take account, not only of the estimate provided by the module ESTIM 301 for the month M-1 of the year N, but also of the estimate provided by the ESTIM module 301 for the month M of the year N-1.

In its various embodiments, the present invention can be implemented on set-top boxes, on Orange® CléTV® and generally on all terminals consuming HAS videos on the move. (on mobile network).

APPENDIX 1: sample manifest file

Claims (11)

Method for managing the adaptive progressive downloading (HAS) of digital content (C1) within a terminal (3, 4, 8) multimedia stream player connected to a mobile communication network (1),
a 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 encoding bit rates of said content,
a maximum volume of data to be consumed within said mobile communication network during a session, called a data bucket, being allocated to said multimedia stream reader terminal,
characterized in that it comprises:
- an estimate (406), based on a volume of data consumed by adaptive progressive downloading of digital content during at least one period by said multimedia stream reader terminal, of a volume of data which could be consumed by said multimedia stream reader terminal by adaptive progressive downloading of said digital contents during said session;
- a determination (407) of a maximum authorized encoding rate (Dmax) for downloading time segments of said digital content during said session so that said estimated data volume is less than or equal to a determined consumption threshold of said data bucket. Method for managing the adaptive progressive downloading of digital contents according to claim 1, characterized in that an initial value of said determined consumption threshold of said bucket of data is chosen (402) by a user. Method for managing the adaptive progressive downloading of digital content according to either of Claims 1 and 2, characterized in that the said period is included in the said session, and in that the said estimation (406) is carried out by extrapolation, on the said session, of said volume of data consumed over said period. Method for managing the adaptive progressive downloading of digital content according to any one of Claims 1 to 3, characterized in that the said period is of the same duration as the said session and in that the said estimate (406) takes account of at least one calendar parameter of said session with respect to said period. Method for managing the adaptive progressive downloading of digital contents according to any one of Claims 1 to 4, characterized in that the said estimation and the said determination of the said maximum encoding rate are updated at least twice during the said session. Method for managing the adaptive progressive downloading of digital content according to any one of Claims 1 to 5, characterized in that , on initializing the said session, said maximum authorized encoding bit rate is assigned a value of a bit rate of maximum allowed encoding determined during a previous session. Method for managing the adaptive progressive downloading of digital content according to any one of Claims 1 to 6, characterized in that , if, at the end of the said estimation, the said estimated volume is substantially greater than the determined consumption threshold of the said bucket of data, said method comprises sending an alert message to a user of said multimedia stream reader terminal and an invitation to modify said consumption threshold. Method for managing the adaptive progressive downloading of digital content according to any one of Claims 1 to 7, characterized in that it also comprises an analysis of the said volumes of data estimated and consumed over a plurality of sessions, and an adaptation of the said threshold of determined consumption of said data bucket based on said analysis. Computer program product comprising program code instructions for implementing a method according to any one of claims 1 to 8, when executed by a processor. Device for managing the adaptive progressive downloading (HAS) of digital content (C1) within a terminal (3, 4, 8) multimedia stream player connected to a mobile communication network (1),
a 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 encoding bit rates of said content,
a maximum volume of data to be consumed within said mobile communication network during a session, called a data bucket, being allocated to said multimedia stream reader terminal,
characterized in that it comprises:
- an estimation module (301), based on a volume of data consumed by adaptive progressive downloading of digital content during a period by said multimedia stream reader terminal, of a volume of data that could be consumed by said multimedia stream reader terminal by adaptive progressive downloading of said digital contents during said session;
- a module (302) for determining a maximum encoding rate authorized for downloading time segments of said digital content during said session so that said estimated data volume is less than or equal to a determined consumption threshold of said bucket of data. Multimedia stream reader terminal (3, 4, 8), characterized in that it comprises a device for managing the adaptive progressive downloading (HAS) of a digital content according to claim 10.