EP4035408A1

EP4035408A1 - Management of adaptive streaming of an item of digital content over a mobile network with selection of a maximum authorized encoding rate on the basis of a data bucket

Info

Publication number: EP4035408A1
Application number: EP20792466.3A
Authority: EP
Inventors: Mathieu Rivoalen; Hervé Marchand
Original assignee: Orange SA
Current assignee: Orange SA
Priority date: 2019-09-27
Filing date: 2020-09-23
Publication date: 2022-08-03
Also published as: FR3101503A1; US20220345511A1; WO2021058910A1

Abstract

The invention relates to a method for managing adaptive streaming (HAS) of an item of digital content (C1) within a multimedia stream reading terminal (30) connected to a mobile communication network. The item of digital content is associated with a description file (7) that describes the item of digital content and that comprises a list of time segments (C1i@Nj) of the item of content that are each associated with multiple encoding rates of the item of content. A maximum data volume to be consumed within the mobile communication network, referred to as a data bucket, is allocated to the multimedia stream reading terminal. According to the invention, when the adaptive streaming of the item of digital content is launched, such a management method: - determines (DET 301) a data volume that would be consumed by the multimedia stream reading terminal as a result of streaming the time segments at at least certain encoding rates, - selects (SEL 302) a maximum encoding rate of the item of content authorized for the streaming on the basis of the consumed data volume associated therewith and of the data bucket.

Description

DESCRIPTION

TITLE: Management of adaptive progressive downloading of digital content on a mobile network with selection of a maximum authorized encoding rate according to a bucket of data

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 management of the data consumption of a user wishing to access digital content according to 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 playback 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 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 simplification, 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 speed available to the user is not guaranteed for the transfer in real time of the video, which is particularly the case when the terminal is connected to a mobile communication network, for example. example a 4G type network, known for its variability in bandwidth.

Adaptive progressive download, in English HTTP Adaptive Streaming, abbreviated HAS, furthermore makes it possible to broadcast and receive data according to 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 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 primary target 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 a longer transmission time, and therefore present an increased risk of not being received in time for continuous playback of the 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.

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. This limit may correspond to a volume of data associated with a prepaid card purchased by the user, or to a monthly package that he has taken out with the operator of the extended communication network, for example the mobile network. This maximum amount of consumable data is more commonly referred to as the data bucket, or "data bucket". Indeed, the English term "data" means "data". In mobile language, data represents data downloaded to a telephone or a mobile terminal 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. Strictly speaking, unlimited plans in this area do not exist. Data plans include a maximum authorized data volume, generally expressed in Megabytes or Gigabytes.

When the user consumes a content or a data stream according to a HAS adaptive progressive download technique on a mobile communication network, the HAS client on board his multimedia stream reader terminal has, in principle, for objective, to achieve the best possible reproduction quality for the user, as a function of resource and bandwidth constraints, and therefore to aim for the maximum encoding rate available for the content to be downloaded. As a result, the downloading of content can consume a very large proportion, if not all, of the data bucket allocated to the user, without the latter having any means of action to prevent it. Indeed, the only option available to the user is, quite radically, to give up accessing the stream, and therefore to give up watching the chosen multimedia content.

This situation turns out to be 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. , depriving him of resources for the end of the period.

There is therefore a need for a technique for managing 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 view content downloaded in HAS via a mobile network, while ensuring him control over the consumption of his data bucket.

Disclosure of the invention

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

According to the invention, at the launch of the adaptive progressive download of the digital content, such a management method implements: a determination of a volume of data which would be consumed by the multimedia stream reader terminal by downloading the time segments of the content at at least some of the encoding rates, a selection of a maximum encoding rate of the content authorized for the download, depending on the amount of data consumed associated with it, and the data bucket.

Thus, the invention is based on a completely new and inventive approach to the adaptive progressive downloading of content, in the case where the multimedia stream reader terminal has a maximum volume of consumable data within its access network to the network. content. Such a limit value for data consumption, also called a “data bucket”, can 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 method according to one embodiment of the invention proposes to take this "data bucket" into account in the choice of the encoding rate at which the HAS client on board the multimedia stream reader terminal downloads the time segments of the content. 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 of the content server, the data consumption resulting from the downloading of the content at different encoding rates is evaluated; taking into account this consumption assessment on the one hand, and the user's data bucket on the other hand, a maximum encoding rate is selected making it possible to restrict the progressive adaptive HAS downloading of the content, in order to better control the share of the data bucket devoted to this download.

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, such a management method also comprises a display, on a reproduction terminal associated with the multimedia stream reader terminal, of the volumes of data consumed determined for at least some of the encoding rates.

The user can thus easily know the volume of data that will be consumed by his terminal if he starts downloading the content he has chosen, at one or other of the available encoding rates: all he needs is to do this, consult the screen of his return terminal, on which these volumes are presented to him. This is particularly advantageous when the user is in a mobility solution, and he does not necessarily understand the impact that the launch of the download of content will have on his data consumption, and therefore on his data bucket. A consultation of the screen of his rendering terminal (for example his mobile phone) indicates to him directly, for example in the form of a comparative table, the volumes of data, for example expressed in Gigabits or in Megabits, associated with the different speeds of encoding of the content.

To simplify the calculation, for example, the assumption is made that all the time segments of the content will be downloaded at the same encoding rate, or at the same resolution, without taking into account any fluctuations associated with changes in the constraints of network resources or from the content server.

It will be noted that the playback terminal can be the multimedia stream reader terminal itself (for example an intelligent mobile telephone of the smartphone type), or be distinct from it (for example a television connected to an HDMI key).

According to an advantageous optional characteristic, the volumes of data consumed, determined for at least some of the encoding rates, are displayed in the form of a proportion of the data bucket.

The user can thus directly understand what percentage of his data bucket will be consumed in the event of launching the download of the content at a particular encoding rate. Such a presentation is more meaningful and understandable for the user. It of course requires that this data bucket be known to the multimedia stream reader terminal.

According to another advantageous optional characteristic, such a management method also comprises a display, on the reproduction terminal, of a volume of data remaining to be consumed by the multimedia stream reader terminal, after the downloading of the time segments of the content at at least some of the encoding rates.

Thus, the user knows not only what volume of data will be consumed by downloading the content, but also how much data he will still have at the end of this download, taking into account his data bucket, and possibly the part he has already consumed. This display of remaining volume can be done in Gigabits / Megabits, or as a percentage of the data bucket. The user can thus easily choose the maximum encoding rate to which he wishes to limit himself, so as not to consume too much of his data bucket, and to keep enough data credit, for example until the end of the month.

According to another advantageous characteristic, the displayed data volumes correspond only to the encoding rates for which the downloading of the time segments of the content does not induce the data bucket to be exceeded.

Thus, if the user's data bucket is known, we can indicate only the encoding rates to which he can claim in order to be able, at a minimum, to see the entire content, if he does not have enough consumable data left for him. see it in maximum quality. According to another characteristic, such a management method also comprises an entry, on a reproduction terminal associated with the multimedia stream reader terminal, of the data bucket.

Thus, the user pre-informs his data bucket, so that this information is accessible to the multimedia stream reader terminal. This entry can be made 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 an innovation in the service, and asks him about this new useful information which is his bucket. data. Alternatively, if the mobile network operator controls the adaptive progressive download service from end to end, it can extract the user's data bucket information from their profile or billing, so that it is accessible to the user. multimedia stream player terminal.

According to one embodiment of the invention, the selection of the maximum encoding rate of the content authorized for downloading is performed by a user via an interface of a playback terminal associated with the multimedia stream reader terminal.

Thus, the user himself chooses the maximum encoding rate to be set, via the interface of his rendering terminal, for example by selecting a highlighted menu or by entering in a pop-in window. This selection may be valid only for a given content, or may be taken into account for all content accessible via the adaptive download service HAS, or even for all content downloaded during a given period (for example during the current month). .

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 of managing the adaptive progressive download (HAS) of 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 an electrical or optical signal, which can be conveyed via an electrical or optical cable, by radio or by other means, so that the program computer 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 device for managing the adaptive progressive download (HAS) of digital content within a multimedia stream reader terminal connected to a mobile communication network. Such digital content is associated with a description file, comprising a list of time segments of the content each associated with several encoding rates of the content; a maximum volume of data to be consumed within the mobile communication network, called a data bucket, is allocated to the multimedia stream reader terminal. According to the invention, such a device comprises:

a module for determining a volume of data which would be consumed by the multimedia stream reader terminal by downloading the time segments of the content at at least some of the encoding rates,

a module for selecting a maximum encoding rate of the content authorized for downloading, as a function of the volume of data consumed which is associated with it, and of the data bucket.

According to one embodiment, such a device for managing the adaptive progressive download (HAS) of digital content also comprises a module for transmitting a command, to a reproduction terminal associated with the multimedia stream reader terminal, display consumed data volumes determined for at least some of the encoding rates.

Such a command can be a command internal to the device when the latter is integrated into the playback terminal itself.

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

The adaptive progressive download management device, the playback multimedia stream reader terminal and the computer program according to embodiments of the invention have 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 content according to one embodiment of the present invention.

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] schematically illustrates the hardware structure of a multimedia stream reader terminal incorporating an adaptive progressive download management device according to one embodiment of the invention;

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

Detailed description of embodiments of the invention

The general principle of the invention is based on the possibility, within the framework of the adaptive progressive downloading of a content, of selecting the maximum encoding rate of the content authorized for the download, so as not to consume too large a portion of the bucket. user data, especially when on the move.

We now present, in relation with [FIG. 1], 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 4G type 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 that 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 video and / or audio compression) with a certain bit rate. Each quality level is itself split on the content server into time segments (or "fragments" 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 the bit rates 512 kb / s (kilobits per second) (Resolution 1, or level 1, denoted NI), 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, we denote “Ci @ Nj” the content number i with the quality j (for example the j-th level Nj of quality described in the description file).

The client terminals 3, 4 receive the data coming 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 TV 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 512 kilobits per second (“kb”) in MPEG-4 (“mp4”) format,

- "Cl_512kb_2.mp4" for the second fragment,

- etc.

Once it has the addresses of fragments 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 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, 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 smartphone 3 or the tablet 4 are, for example, transmitted via ^WiFi® to the HDMI key 8, which controls their display on the television screen 5, for restitution to the user.

[Fig 2] 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 phone 3, of [Fig 1]. following the example of the HDMI 8 key.

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 8 key communicates with the extended Internet network 1 via the WIFI module for local wireless communication with another communication terminal, for example the smart phone 3. The HDMI 8 key also includes a HAS adaptive progressive download module capable of requesting a progressive download of one of the contents with 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 outside.

The HDMI key 8 also includes a DET module for determining a volume of data which would be consumed by adaptive progressive downloading of content, with the different qualities proposed in the description file 7.

It also comprises a DISP module for controlling the display of the data volumes determined by the module DET on a screen of a rendering terminal, for example the smart phone 3 or the television 5. More generally, such a DISP module is a module for managing the interface with the user's playback terminal, by which the HDMI key 8 obtains, for example, information on any interactions the user has with the playback terminal (action on the television remote control by for example by pressing the volume key or a channel change key, or selecting from a menu highlighted on the television screen of a maximum quality of content authorized, or selecting this maximum quality on the touch screen of the telephone intelligent 3 or tablet 4), and by which it can control the display on the screen of the display terminal for rendering pop-up windows, allowing it to deliver messages, information on data volumes consumed or remaining, or user alerts. It also includes a SEL module for selecting a maximum encoding rate or a maximum resolution authorized for downloading the content, which controls the adaptive progressive download module HAS, in order to force the latter to request a progressive download of the content. 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 quality selected via the SEL module.

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 application for controlling the HDMI key is installed, thanks to which the user can control its operation, etc. Indeed, such an HDMI 8 key does not generally contain no I / O interface module, and it is the I / O interface module of the user's smartphone 3 or tablet 4, or of the TV 5, which is used by the latter to choose by example its content.

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 an HDMI 8 key 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, representative of the progressive download management module. adaptive HAS, stored in read only memory (eg ROM or hard disk). 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 description file manifest 7. The processor of the processing unit controls the determination of the volumes of data consumed by downloading the content at its various quality levels, the display of pop-up windows on the display of the display terminal, and restricting the quality of the downloaded content, through the choice of the time segments and the associated encoding rates to download, and the issuance of corresponding commands to the HAS client module.

In the case where the multimedia stream reader terminal in question is not the HDMI key 8 but, for example, the smart phone 3, the architecture proposed in [Fig 2] 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 rendering terminal is then the multimedia stream reader terminal itself, so that the display control module DISP controls the display of the estimated data volumes directly on the screen of the smart phone 3, and the module SEL directly receives the value of the maximum quality of the authorized content selected by the user on the screen of the smartphone 3 itself.

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

We now present, in relation with [Fig 3], an example of clamping of the maximum quality of a multimedia stream obtained 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],

The multimedia stream reader terminal 30 is connected to a TX playback terminal (for example the HDMI key 8 is connected to the television 5 via an HDMI link or to the smart phone 3 via a WIFI link. ). It comprises a DISP 300 interface module with the TX rendering terminal, a DET module 301 for determining the volume of data consumed by downloading a content at its various encoding rates, a SEL module 302 for selecting a maximum encoding rate allowed for the download, and a HAS 303 client module.

A HAS content server 2 exposes a video C1 in the form of “chunks” Cli @ Nj encoded at different 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 conventional 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 30. It is therefore appropriate 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 low enough to allow continuous reproduction on the TX restitution terminal.

In the embodiment illustrated in [Fig 3], on the other hand, the HAS client module 303 may not order the download of the fragment at the optimum encoding rate, in order to limit the consumption of the user's data bucket, such as described in more detail below. During a step referenced 310, the HAS module 303 recovers the manifest file 7 in order to discover the available fragments of the video content C1, and the various associated video qualities Nj.

For example, we consider the case of a customer who wishes to watch a video on demand (VOD) lasting two hours, using his CléTV ^® 8 and his smartphone 3 in modem mode (4G connection sharing).

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 bit rate and resolution available, according to the example given in the table [Table 1]. below.

[Table 1] e proposed in the form of fragments of duration 3s, with a first encoding rate NI = 600 kb / s, a second encoding rate

N2 = 1200 kb / s, a third encoding rate N3 = 2100 kb / s, etc.

In normal operating mode, not illustrated in [Fig 3], the HAS 303 module downloads, for example, successive Cli @ Nl fragments (i.e. the first temporal fragment at an encoding rate of 600 kb / s), then Cl ₂ @ N3 (ie the second time fragment at an encoding rate of 2100 kb / s), then Cl ₃ @ N3 (ie the third time fragment at an encoding rate of 2100 kb / s), .. .

The various fragments downloaded by the HAS client module 303 are transmitted to the DISP 300 interface module for their return to the user on the screen of the TX reproduction terminal. The algorithm implemented by the HAS 303 client module to determine which fragment at which encoding rate should be downloaded in normal operating mode (i.e. outside of the encoding rate restricting by the module SEL 302) can be one of the already existing algorithms of the prior art. This algorithm will therefore not be described in more detail here.

In parallel, in accordance with [Fig 3], the DET module 301 determines the volume of data that would be consumed by downloading the content C1 at the different resolution levels of [Table 1] To do this, the DET module 301 uses for example a hypothesis simplifying, according to which the download takes place at the same level of resolution for the duration of the content, that is, in this example for two hours, or 7200 seconds. Although it does not correspond to the actual operation of HAS type downloading, this hypothesis allows a good estimate of the amount of data that could be consumed by downloading the content at each of the resolution levels proposed in the manifest file 7.

Thus, for example, for a resolution of 320x180 pixels, the DET module 301 estimates a data consumption of: 600kb / s * 7200s = 4.32Gb, or 540Mo. The result of all the calculations performed is summarized in the table below.

[Table 2]

We first consider a first case, in which the terminal 30 knows the data bucket of the user client. This data bucket corresponds for example to a volume of data associated with a prepaid card which it has acquired from the operator of the mobile network 1. It can also correspond to a monthly package that it has subscribed to with this operator, for example a 50GB / month package.

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

As a variant, this data bucket can also be entered by the user himself. It can for example be entered via the interface of the TX rendering terminal (smart phone 3, or television 5 for example), during an installation phase of the HAS download service, or in response to a request from the service provider. this service, for example via a “pop in” window informing the user of new features or innovations in the service.

We therefore consider the example of a data bucket of 50 GB / month, of which the customer has already consumed lOGo during the current month. Again, the knowledge of the customer's current consumption can be provided by the operator of the mobile network 1, or by the customer himself. The DET module 301 can then easily determine, for each of the resolutions proposed in the manifest file 7, the part of the data bucket that will be consumed in the event of downloading the content at this resolution, and the portion of this bucket that will remain with the client afterwards. download, based on current monthly consumption. The result of the calculations carried out by the DET 301 module can be displayed, for example in the form of the table [Table 3] below, on the screen of the TX restitution terminal.

[Table 3]

Thus, by simply consulting the screen of the rendering terminal TX, the customer knows that by downloading the content C1 at an encoding rate of 2.1Mb / s, he will consume 7200 * 2, 1 = 15, 12Gb, or 15, 12/8 = 1, 89GB. Since its data bucket is 50GB, this is therefore 1.89GB * 50GB / 100 = 3.78% of its monthly data bucket. And since it has already consumed LOGo of data since the beginning of the month, i.e. 20% of its data bucket, it will have, after downloading the Cl content at this resolution of 1024x576 pixels, 100% -20% -3.78% = 76.22% of its monthly data bucket.

The terminal 30 then offers the customer, on the strength of this knowledge of his level of data bucket consumed and remaining after downloading, to define a high limit of the encoding rate of the content to be downloaded: the different fragments of the content C1 will then not be able to be downloaded at an encoding rate greater than this high limit selected by the user.

In this example, the user decides for example that he wishes to view the content C1, but without exceeding 7% of consumption of his data bucket: he therefore chooses to restrict the downloading of the fragments of the content to a maximum resolution of 1280x720 pixels. .

To do this, it uses the interface of the TX rendering terminal. For example, on the television screen 5, he selects, by means of a remote control, one of the rows of the table [Table 3], which is displayed for example in highlight. In another example, he selects this maximum authorized encoding rate by clicking on the appropriate row of the table [Table3] displayed on the touch screen of the smartphone 3. Any other type of interface configuration could also be used, such as a banner, a pop-in window, etc.

It will be noted that the multimedia stream reader terminal 30 can make this selection itself, without the intervention of the user, for example by applying a principle of precaution with regard to the consumption of the data bucket. It can also encourage the user to select a low value for the maximum authorized encoding rate, for example by highlighting on the screen of the reproduction terminal a maximum recommended encoding rate value, depending on the share of the user. Bucket of data remaining after download. The user then only has to confirm or reject this pre-selection. The selected value feeds the selection module SEL 302, which communicates it to the HAS module 303, so as to restrict the downloading of the content fragments at the maximum encoding rate of 3Mb / s chosen by the user.

Thus, as illustrated in [Fig 3], the HAS 303 client module will successively download (312) the fragments Cl ₂ @ N3, Cl ₃ @ N3, C1 ₄ @ N2, C1 ₅ @ N1 and Cl ₆ @ N3, c ' that is, download the best possible quality fragment based on network constraints, but never exceeding the maximum encoding rate MAX 311, which has been selected by the user to be 2100kb / s.

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

A second case is now considered, in which the multimedia stream reader terminal 30 has no knowledge of the user's data bucket. In this case, the module DET 301 for determining the volume of data consumed can only determine the absolute value of the volume of data consumed by downloading the content C1 at the various resolution levels proposed in the manifest file 7, and not its relative value by compared to the data bucket. In other words, only the data in the table [Table 2] can be displayed, upon action of the display control module DISP 300, on the screen of the TX rendering terminal. Thus, the level of consumption of the multimedia stream C1 is simply presented at its various encoding rates, and the user must make a selection of the maximum encoding rate that he authorizes as a function only of the number of GB consumed at each of the flow rates.

Since the user is most often aware of their data bucket, they can perform a quick head calculation to help them make a decision. Thus, if he wants to watch the VOD Cl, he can be ready to consume 2.7GB of his monthly data bucket, even if it means restricting his consumption during the rest of the month on other services or applications. In this case, it selects, in the table [Table2], the resolution of 1280x720 pixels, and the associated maximum encoding rate of 3Mb / s. Once again, the configuration of the interface of the TX rendering terminal making this selection possible can take any appropriate form.

In this second case, the display of the data restitution terminal is therefore displayed on the screen allowing the user to better understand the impact of downloading the content C1 on his data consumption, so that he has the necessary tools to adapt its content consumption, depending on its capabilities. It will be noted that, in one embodiment, the selection of the maximum encoding rate MAX 311 is effective only for the content C1 being downloaded HAS. As a variant, this selection can be applied to all the multimedia streams accessible via the content server 2, or to all the multimedia streams that the user will download during a given period (for example the current month in the event of monthly flat rate), or during a given period during which the user is on the move.

In another embodiment, the DISP 300 module does not display all the lines of the tables [Table 2] and [Table 3] on the screen of the TX restitution terminal, but only the lines corresponding to the encoding rates which do not result in the user data bucket being exceeded. In other words, the customer is only offered the encoding speeds to which he can claim in order to be able to at least view the entire K1 content, if he does not have enough consumable data left to see it at the maximum available quality. .

The example of content C1 of the video on demand (VOD) type was given above. It will be noted that the content C1 can also be a deferred television program (or “replay”), or a live television program (“Live”). In the latter case, the duration of the program necessary for the calculation by the DET module 301 of the volume of data consumed can be extracted from the electronic program guide EPG (“Electronic Program Guide”).

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

APPENDIX 1: example of manifest file

Claims

1. A method of managing the adaptive progressive download (HAS) of a digital content (C1) within a terminal (3, 4, 8) multimedia stream reader connected to a mobile communication network (1), said content digital being associated with a file (7) describing said digital content, comprising a list of time segments (Cli @ Nj) of said content each associated with several encoding rates of said content, a maximum volume of data to be consumed within said network communication device, called a data bucket, being allocated to said multimedia stream reader terminal, characterized in that, on launching said adaptive progressive download of said digital content, said management method implements:

a determination (DET 301) of a data volume which would be consumed by said multimedia stream reader terminal by downloading said time segments of said content at at least some of said encoding rates,

- a selection (SEL 302) of a maximum encoding rate (MAX 311) of said content authorized for said downloading, as a function of said consumed data volume associated with it, and of said data bucket.

2. Management method according to claim 1, characterized in that it also comprises a display (DISP 300), on a reproduction terminal (TX) associated with said multimedia stream reader terminal, of said consumed data volumes determined for at least some of said encoding rates.

3. Management method according to claim 2, characterized in that said consumed data volumes, determined for at least some of said encoding rates, are displayed in the form of a proportion of said data bucket.

4. Management method according to any one of claims 2 and 3, characterized in that it also comprises a display, on said reproduction terminal, of a volume of data remaining to be consumed by said multimedia stream reader terminal, at the end of said downloading of said time segments of said content at at least some of said encoding rates.

5. Management method according to any one of claims 2 to 4, characterized in that said displayed data volumes correspond only to the encoding rates for which said downloading of said time segments of said content does not induce exceeding of said bucket of data.

6. Management method according to any one of claims 1 to 5, characterized in that it also comprises an entry, on a reproduction terminal associated with said multimedia stream reader terminal, of said data bucket.

7. Management method according to any one of claims 1 to 6, characterized in that said selection of said maximum encoding rate of said content authorized for said downloading is performed by a user via an interface of a playback terminal associated with said. multimedia stream player terminal.

8. A computer program product comprising program code instructions for implementing a method according to any one of claims 1 to 7, when executed by a processor.

9. Device for managing the adaptive progressive download (HAS) of digital content within a multimedia stream reader terminal connected to a mobile communication network, said digital content being associated with a description file (7) of said content. digital, comprising a list of time segments of said content each associated with several encoding rates of said content, a maximum volume of data to be consumed within said mobile communication network, called a data bucket, being allocated to said multimedia stream reader terminal, characterized in that it comprises:

a module for determining (DET) a volume of data which would be consumed by said multimedia stream reader terminal by downloading said time segments of said content at at least some of said encoding rates,

a selection module (SEL) of a maximum encoding rate of said content authorized for said downloading, as a function of said consumed data volume which is associated with it, and of said data bucket.

10. A device for managing the adaptive progressive download (HAS) of digital content according to claim 9, characterized in that it also comprises a module (DISP) for transmitting a command, to a playback terminal (3, 4, 5) associated with said multimedia stream reader terminal (3, 4, 8), for displaying said consumed data volumes determined for at least some of said encoding rates.

11. Multimedia stream reader terminal (3, 4, 8), characterized in that it comprises a device for managing the adaptive progressive download (HAS) of digital content according to claim 9 or 10.