WO2019220034A1 - Management of adaptive progressive download of a digital content within a restoration terminal of a local communication network - Google Patents

Abstract

The invention relates to a method for managing the adaptive progressive download (HAS) of a digital content within a restoration terminal (30) of a local communication network, comprising a step of obtaining (310) a description file (7) for the digital content comprising a list of temporal segments (C1i@Nj) of said content, each associated with several encoding bitrates (Nj) for said content. According to the invention, such a method comprises: - a determination of an integer N≥2 of client modules (HAS-1-HAS-3) to be activated within said restoration terminal (30) in order to download said content; - a transmission (311) of a command to download at least one of said temporal segments with one of said encoding bitrates from said description file, to each of said N client modules to be activated; - N parallel downloads (312), by each of said N client modules, of said temporal segments with said encoding bitrates, in accordance with said transmitted command.

Description

 Management of adaptive progressive downloading of digital content within a rendering terminal of a local communication network.

 1. Field of the invention

 The field of the invention is that of digital multimedia contents, namely digital audio and / or video contents. More specifically, the invention relates to the management of adaptive progressive downloading of digital content within a local communication network, such as a home network.

 2. Prior art and its disadvantages

 Access to multimedia content, such as television or video on demand, from an Internet-type network is possible today, for most of the rendering terminals, especially when they are part of a network. local communication, such as a home network.

 The terminal generally sends a request to a server, indicating the chosen content and receives back a stream of digital data relating to this content. In the context of a local communication network, such a request passes through the access gateway to the network, for example the residential gateway.

 The terminal is adapted to receive these digital contents as multimedia data and to make a restitution. This restitution consists in providing at the terminal level the digital content in a form accessible to the user. For example, received data corresponding to a video is generally decoded, and then rendered at the terminal as a display of the corresponding video with its associated soundtrack. In the following, for the sake of simplification, it will equate the digital content to a video and the return by the terminal, or consumption by the user of the terminal to a display on the screen of the terminal.

 The dissemination of digital content on the Internet is often based on client-server protocols of the HTTP ("Hyper Text Transport Protocol") family. In particular, the progressive downloading of digital contents, 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 on the network and returned by the terminal as and as they arrive. The terminal receives and stores a portion of the digital data in a buffer before rendering them. This distribution mode is particularly useful when the rate available to the user is not guaranteed for the real-time transfer of the video.

The adaptive progressive download, in English HTTP Adaptative Streaming, of abbreviation HAS, allows moreover to diffuse and receive data according to different qualities corresponding for example to different flow 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 capabilities of the client terminal. This type of technique makes it possible in particular to take account of bandwidth variations on the link between the client terminal and the content server.

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

 Thus, the MPEG-DASH (Dynamic Adaptive Streaming over HTTP) standard is an audiovisual broadcasting format standard on the Internet. It is based on the preparation of the content in different presentations of variable quality and speed, divided into segments of short duration (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 mainly targeted protocol is the HTTP protocol, but other protocols (eg FTP) can also be used. Segment organization and associated parameters are published in a manifest in XML format.

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

 ensures the best possible quality,

 and allows a reception delay compatible with the uninterrupted rendering of the content.

Thus, to adapt to the variation of the network conditions, especially in terms of bandwidth, the existing solutions for adaptive download allow the client terminal to switch from one version of the encoded content to a certain bitrate, to another encoded to a different one. other debit, during download. Indeed, each version of the content is divided into segments of the same duration. To allow a continuous return of content on the terminal, each segment must reach the terminal before its scheduled time of return. The perceived quality associated with a segment increases with the size of the segment, expressed in bits, but in the same At the same time, larger segments require more transmission time, and thus 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 restitution, carefully selecting the next segment to download, among the various encoding rates proposed. To do this, there are different algorithms for selecting the quality of the content according to the available bandwidth, which may have more or less aggressive or more or less secure strategies.

In addition, in the context of a local communication network, when several progressive downloads are launched in parallel, by several rendering terminals, the total bandwidth available for downloading is divided equally between the different streams downloaded. Thus, if in a local communication network, which has a downlink bandwidth of 6Mb / s, it is simultaneously launching the download of a video on demand (by a first client HAS installed for example on a personal computer), a digital television channel (by a second client HAS installed for example on a television), and access to a streaming film as proposed for example by Netflix ^® (by a third client HAS installed for example on a smart phone type), the bandwidth available to each of these three HAS customers is 2Mb / s.

 By HAS client, here is meant a software or hardware component, or a set of hardware and software components, capable of recovering the segments of a video content at different encoding rates, with a view to their return by a rendering terminal. which he is embarked on.

 Indeed, the HTTP protocol is based on principles of equal access to a resource. The HTTP protocol is in particular based on protocols of the TCP-IP type (set of protocols used for the transfer of data on the Internet) which make it possible to convey the data packets between the different terminals and servers and the access gateway. The access gateway that receives the data packets routed according to TCP-IP does not assign priority to them, which results in an equal sharing of the bandwidth.

 However, it is not always desirable to distribute the available bandwidth equitably, and there is therefore a need for a technique to control the bandwidth sharing between the different HAS clients, as part of the progressive adaptive download of digital content.

 3. Presentation of the invention

The invention responds to this need by proposing a method for managing the adaptive progressive download (HAS) of a digital content within a rendering terminal of a device. local communication network, comprising a step of obtaining a description file of the digital content, comprising a list of temporal segments of the content each associated with several encoding rates of the content.

 According to the invention, such a management method comprises:

 a determination of an integer N> 2 of client modules to be activated within the rendering terminal for downloading the content;

 transmitting to each of the N client modules to activate a download command of at least one of the time segments at one of the encoding rates of the description file;

 N downloads in parallel, by each of the N client modules, time segments to the encoding rates, in accordance with the transmitted command.

 Thus, the invention is based on a completely new and inventive approach to the management of progressive adaptive downloading in a local communication network. Indeed, the invention proposes to instantiate a greater or lesser number of HAS client modules within a rendering terminal, so as to allow finer control of the sharing of the bandwidth between the different restitution terminals. local communication network. When it is necessary to increase the bandwidth allocated to a rendering terminal, a higher number of HAS client modules are activated within this terminal; these HAS client modules are controlled, in order to recover in parallel manner the different segments, or "chunks", video. To do this, a HAS client manager is installed in the rendering terminal, and sends download commands to the different client modules, to indicate which time segment of the content they must download, and at which encoding rate. The parallel downloading of the different segments by the different client modules HAS makes it possible, if necessary, to increase the bandwidth devoted to downloading and returning the content by the rendering terminal.

 According to a first aspect of the invention, the determination of the number N of client modules to be activated for downloading the content takes into account a preference of a user of the rendering terminal.

Thus, the client has the possibility, from an interface of the local communication network, for example, to give a weighting, or a priority, to each of the network rendering terminals. This weighting can take the form of a note, expressed for example in the form of a number of stars (from one to five for example), allocated to each of the network rendering terminals. Depending on the choice of the number of stars, a larger or smaller number of HAS clients will be instantiated in the rendering terminal (from one to five for example). According to another aspect of the invention, which can be implemented alternatively or cumulatively with the previous one, the determination of the number N of client modules to be activated for downloading the content takes into account a dimension of a screen of the terminal of restitution.

 Thus, the number of HAS client modules to be activated may be proportional to the size of the diagonal of the display of the rendering terminal. Indeed, we can be content with a lower quality, and therefore a lower flow, for a small screen, such as that of a "smartphone" for example (in French, smart phone or ordiphone). Conversely, a large display screen, such as that of a large diagonal TV, may require a higher quality of playback of content, and therefore a larger share of the bandwidth available for downloading segments of the content.

 According to yet another aspect of the invention, which can be implemented alternatively or cumulatively with the above, the determination of the number N of client modules to be activated for downloading the content takes into account a characteristic of the content belonging to the group comprising :

 a duration of said content;

 a type of said content.

 According to this embodiment, a larger part of the bandwidth available for download is for example assigned to short-term content, compared to live broadcast content, for which it is possible for example to return backwards thanks to an option of the type "TimeShifting" (in French, "offset"). For example, paying content (for example, video-on-demand), giving it a larger share of the bandwidth, compared to free content (for example, a television program of a free channel) may also be preferred. .

 According to yet another aspect of the invention, which can be implemented alternatively or cumulatively with the previous ones, the determination of the number N of client modules to be activated for downloading the content takes into account a number of users to whom the content is restored.

 The number of people present in front of the screen of the rendering terminal can be detected, by means of a camera, or a beacon of the "Beacon Bluetooth Low Energy" type. If no user is present, it is possible that the content is downloaded only for its soundtrack and audio component: in this case, we can be content with a very low quality for downloading video segments, and therefore a very low bandwidth.

The quality, and therefore the number of HAS client modules activated within the rendering terminal, can then be chosen proportionally to the number of users present. in front of the screen of the restitution terminal: the more the public is, the higher the quality of restitution said to be high.

 According to yet another aspect of the invention, which can be implemented alternatively or cumulatively with the previous ones, the determination of the number N of client modules to be activated for downloading the content takes into account a profile of a user to which the content is restored.

 For example, the age or role of users may be taken into account, for example by giving priority to quality for content intended for parents rather than children.

 According to another aspect of the invention, the number N of client modules is between 2 and 5, so as to allow a good modularity of bandwidth sharing, without inducing too much complexity in the rendering terminal.

 According to yet another aspect of the invention, after the determination of the number N of client modules to be activated, such a method comprises a download initialization phase, comprising a progressive incrementation of the number i of client modules to which are transmitted the time segment download commands, for i ranging from 1 to N.

 It is indeed important to provide a progressive startup algorithm, to allow a gradual increase in power. For example, the HAS client manager can begin downloading the content by activating a single HAS client module, until a stable rendering quality is achieved for X seconds (with X, for example, equal to ten times the duration of a time segment ), then instantiate a second client module HAS, and so on, always waiting during a phase of stabilization of the quality of duration X, before activation of an additional client module.

 The invention also relates to a device for managing the adaptive progressive download (HAS) of a digital content within a reproduction terminal of a local communication network, comprising a module for obtaining a description file of the digital content, comprising a list of time segments of the content each associated with several content encoding rates, which comprises:

a plurality of content download client modules, capable of downloading time segments of the content to one of the encoding rates of the description file; a module for managing the client modules, able to determine a number N of client modules to be activated for downloading the content, and to transmit to each of the N client modules a download command, dedicated to the client module and including an identifier of the minus one of the time segments at one of the encoding rates. The invention also relates to a digital content reproduction terminal, which comprises such a device for managing the adaptive progressive download (HAS) of a digital content.

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

 The invention is also directed to a computer-readable recording medium on which is recorded a computer program comprising program code instructions for executing the steps of the adaptive progressive download management method according to the invention such that described above.

 Such a recording medium may be any entity or device capable of storing the program. For example, the medium may include storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or 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 that it contains is executable remotely. The program according to the invention can in particular be downloaded to 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 device for managing the adaptive progressive download (HAS) of a digital content, the rendering terminal and the corresponding computer program mentioned above have at least the same advantages as those conferred by the adaptive progressive download management (HAS) method. digital content according to the present invention.

4. List of figures

 Other objects, features and advantages of the invention will appear more clearly on reading the following description, given as a simple illustrative and non-limiting example, in relation to the figures, among which:

 FIG. 1 represents a progressive download architecture on the Internet based on the use of adaptive streaming according to the invention;

FIG. 2 schematically illustrates the hardware structure of a rendering terminal incorporating an adaptive progressive downloading management device according to one embodiment of the invention; FIG. 3 illustrates an exemplary embodiment of the adaptive progressive downloading of a content by a rendering terminal of FIG. 2;

 FIG. 4 shows an example of an algorithm making it possible to determine the number of client modules HAS to be activated, corresponding to an initialization phase of the example of FIG. 3.

 5. Detailed Description of Embodiments of the Invention

 The general principle of the invention is based on the activation of a greater or lesser number of HAS client modules in a content reader (or rendering terminal), in order to allow finer control of the sharing of the bandwidth between the different terminals for rendering a local communication network, compared to the techniques of the prior art.

 We now show, in connection with Figure 1, a progressive download architecture based on the use of adaptive streaming according to the invention.

 The terminal 3, for example a smart phone type "smartphone", the terminal 4, for example a laptop, and the terminal 5, for example a PC-type personal computer are in this example located in a local area network (LAN , 10) controlled by a home gateway 6. The context of the local network is given as an example and could be easily transposed to a "best effort" Internet network, a corporate network, etc.

 A digital content server 2 is according to this example in the wide area network (WAN, 1) but it could equally well be located in the local area network (LAN, 10), for example in the home gateway 6 or any other equipment capable of host such a content server. The content server 2 receives for example channels of digital television content from a broadcast television network, not shown, and / or videos on demand, and makes them available to the client terminals.

 Conventionally, at least one of the client terminals 3-5 wishes to communicate with the content server 2 to receive one or more content (movies, documentaries, advertising sequences, etc.).

 It is common, in this client-server context, to use, in order to exchange data between the client terminal 3-5 and the server 2, an adaptive streaming technique, abbreviated to 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 bandwidth variations that may occur on the link between the client terminal 3-5 and the service gateway 6, or between this link. last and the content server 2.

Classically, different qualities can be encoded for the same content of a chain, corresponding for example to different rates. More generally, we will talk about quality to refer to a certain resolution of the digital content (spatial, temporal resolution, quality level associated with video and / or audio compression) with a certain bitrate. Each level of quality 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 fragments of content, are described for the client terminal and made available via their Internet addresses (URI: Universal Resource Identifier). All these parameters (qualities, addresses of the fragments, etc.) are generally grouped together in a parameter file, called a description file. It should be noted that this parameter file can be a computer file or a set of descriptive information of the content, accessible to a certain address.

 The terminal 3-5 has its own characteristics in terms of decoding capability, display, etc. In a context of progressive adaptive downloading, it can adapt its requests to receive and decode the content requested by the user to the quality that best corresponds to it. In our example, if the contents are available at rates of 512 kb / s (kilobits per second) (Resolution 1, or level 1, denoted by 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. Generally speaking, "Ci @ Nj" denotes the content number i with the quality j (for example the j-th level Nj of quality described in the description file).

 In this example, the service gateway 6 is a home gateway which routes the data between the WAN 1 and the LAN 10, manages the digital contents, in particular by ensuring their reception from the network and their decoding by means of the decoders that the It is assumed here integrated with the gateway 6 or the terminal 3-5. Alternatively, the decoders may be located elsewhere in the WAN 1 or local 10, especially at a STB-type element (English Set-Top-Box) associated with a TV (not shown).

 In this example, to view a content, the terminal 3-5 first queries the service gateway 6 to obtain an address of the description document 7 of the desired content (for example, C1). The service gateway 6 responds by supplying the terminal with the address of the description file 7. In the following, it will be assumed that this file is a manifest type file according to the MPEG-DASH standard (denoted "C.mpd") and will refer indifferently, depending on the context, to the expression "description file" or "manifest".

Alternatively, this file can be retrieved directly from a local Internet server or external to the local network, or already be on the service gateway or on the terminal at the time of the request. An example MPEG-DASH manifest file (MPD) containing the description of content available in three different qualities (NI = 512 kb / s, N2 = 1024 kb / s, N3 = 2048 kb / s). This simplified manifest file describes digital contents in an XML syntax (of the English "eXtended Markup Language"), comprising a list of contents in the form of fragments conventionally described between an opening tag (<SegmentList> ) and a closing tag (</ SegmentList>). Particle cutting makes it possible to adapt finely to fluctuations in the bandwidth. Each fragment corresponds to a certain duration ("duration" field) with several levels of quality 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 :

 - "Cl_512kb_l.mp4" for the first fragment of the content "Cl" at 512 kilobits per second ("kb") in the MPEG-4 ("mp4") format,

 - "Cl_512kb_2.mp4" for the second fragment,

 - etc.

 Once it has the fragment addresses corresponding to the desired content, the service gateway 6 proceeds to obtain the fragments via a download to these addresses. Note that this download is done here, traditionally, through an HTTP URL, but could also be done through a universal address (URI) describing another protocol (dvb: // monsegmentdecontenu for example).

It is assumed here that the terminal 3 renders a first content referenced C1 (for example a video content on demand), that the terminal 4 renders a second referenced content C2 (for example a film in continuous stream as proposed for example by Netflix ^® ) and that the terminal 5 renders a third content referenced C3 (for example a television content chain), all three described in a manifest file 7.

 According to the state of the art, the strategy usually preferred is to route the three streams at an equal rate to each of the three rendering terminals 3-5, each of which instantiates a client module HAS.

 Thus, if the ADSL download link (for "Asymmetric Digital Subscriber Line") from the home gateway 6 has a bandwidth of 6 Mb / s, the bandwidth accessible to each HAS client of each of the rendering terminals 3-5 is The bandwidth is therefore shared equitably according to the HAS clients present (one per rendering terminal 3-5).

The purpose of the download management device according to the invention, which will be described Later in more detail in support of Figures 2 and 3 is to be able to control this sharing of bandwidth between the different terminals.

This device is located in the rendering terminal (set top box, TV, real-time media streaming device type Chromecast ^® or Key-TV ^® , ...) and can control the activation of one or more HAS client modules within the terminal for downloading a given content.

 FIG. 2 represents an architecture of a rendering terminal incorporating such a progressive adaptive download management device according to one embodiment of the invention, for example one of the terminals 3-5 of FIG. 1.

 It comprises, conventionally, memories M associated with a CPU processor. The memories can be ROM (Read Only Memory) or RAM (Random Access Memory) or Flash. The rendering terminal 3-5 communicates with the local area network 10 and the extended Internet network 1 via the Ethernet module ETH on the one hand and possibly the WIFI module for local wireless communication. The rendering terminal 3-5 furthermore comprises, in accordance with the invention, several modules (only two have been represented here, for the sake of simplification) of an adaptive progressive download HAS able to request a progressive download of one of the contents to one of the qualities proposed in a description file 7. The terminal according to the invention also comprises a module MNG management of adaptive progressive download modules HAS, or HAS client modules, capable of determining the number N of client modules HAS to activate for the download of the content, and to transmit to each of these N client modules a download command, indicating to each client module HAS which time segments, to which encoding rate, it must download, according to the information contained in the description file 7.

 This MNG module for managing the client modules HAS accesses a content rendering parameters file, by which it can determine the optimum number of HAS client modules to be activated for the reproduction of a given content. These parameters can be for example the user's preferences for the return of content on this terminal, the display characteristics (screen size, window) of the content, the age / role parameters of the users to which a content is intended ...

 The description files 7 can be recorded for example in the memories M of the rendering terminal 3-5 or be outside.

The rendering terminal 3-5 according to the invention may also contain other modules such as an unrepresented hard disk for storing the video fragments, a module for controlling access to the contents, a video interface module, and other modules allowing him to communicating with the outside via different protocols on different physical links, etc. In particular, the rendering terminal 3-5 may contain an I / O interface module (not shown), allowing the user to enter a restitution preference. content, for example in the form of a number of stars (from one to five, for example), enabling the module MNG to determine the number of client modules HAS to activate. Such an I / O module can take the form of a remote control or a touch screen for example.

The terminal 3-5 can also integrate an interface module with a Bluetooth Low Energy ^® camera or beacon, enabling the MNG module for managing HAS client modules to access information relating to the number of users present in front of the terminal. of restitution 3-5.

 Note that the term module can correspond to a software component as well as a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subprograms. in a more general manner 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 set (or hardware) able to implement a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc. .).

 More generally, such a rendering terminal 3-5 comprises a random access memory (for example a RAM memory), a processing unit equipped for example with a CPU processor, and driven by a computer program, representative of the management module. HAS client modules, stored in a read-only memory (for example a ROM or a hard disk). At 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 description file 7. The CPU of the processing unit controls the determination of the number of HAS client modules to be activated, as well as the choice of time segments and associated encoding rates to be downloaded by each. from them, and issuing corresponding commands to each HAS client module.

FIG. 2 illustrates only one particular way, among several possible, of realizing the rendering terminal 3-5, so that it performs the steps of the method detailed hereinafter, in relation to FIGS. 3 and 4 (in one any of the various embodiments, or in a combination of these embodiments). Indeed, these steps can be carried out indifferently 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 computing machine (for example a set of logical gates such as an FPGA or an ASIC, or any other hardware module).

 In the case where the rendering terminal 3-5, and in particular the adaptive progressive download management device that it integrates, is realized with a reprogrammable calculation machine, the corresponding program (that is to say the sequence of instructions) can be stored in a removable storage medium (such as for example a floppy disk, a CD-ROM or a DVD-ROM) or not, this storage medium being partially or fully readable by a computer or a processor.

 An exemplary embodiment of the adaptive progressive downloading of a content by a rendering terminal 30, which corresponds for example to one of the terminals 3-5 of FIGS. 1 and 2, is now presented in connection with FIG.

 The rendering terminal 30 comprises a content player VP (for the English "Video Player") 301, a module MNG 302 for managing the client modules HAS, and several client modules HAS, only three of which have been represented here, referenced HAS. -1, HAS-2 and HAS-3. It should be noted that, in most embodiments of the invention, the number of HAS-i client modules is generally between two and five. The module MNG 302 for managing HAS client modules is responsible for instantiating the desired number of HAS clients and for controlling the HAS-1, HAS-2 and HAS-3 clients in order to retrieve the different video "chunks" in a parallel manner.

 A content server HAS 2 exposes a video C1 in the form of chunks C1, @ Nj encoded at different encoding rates Nj, where the index i denotes a time identifier of the chunk Cli @ Nj.

According to the prior art, a client module HAS is responsible for picking up its "chunks" from the content server HAS 2 by choosing the video quality Nj according to the available network resource. We do not describe here in more detail how the HAS client module chooses the encoding rate of the next video fragment to download: there are indeed many algorithms to make this choice, whose strategies are more or less safe 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 manifest, and on the evaluation of the recovery time of this first fragment. . On this basis, the client module HAS evaluates whether, depending on the size of the fragment and the time taken to recover it, the network conditions make it possible to download the next fragment at a higher encoding rate. Some algorithms rely on a gradual increase in the quality level of downloaded content fragments; others propose riskier approaches, with jumps in the levels of encoding rates of successive fragments. In the classic case, if a "chunk" video lasts 3 seconds, the recovery of the "chunk" by the client module HAS must not exceed 3 seconds, to allow a restitution without interruption of the content by the restitution terminal 30. The HAS client module is therefore best suited to achieve the best compromise between rendering quality, and thus encoding rate, as high as possible, and the fragment download time, which must be sufficiently small to allow for a restitution. contained by the terminal 30.

 In the embodiment illustrated in FIG. 3, on the other hand, several HAS client modules can be activated in parallel, as described in more detail below. In the case, for example, where three HAS client modules are activated, which download in parallel the successive video fragments of the content, each client module HAS therefore has 3 x 3 = 9 seconds to recover its video chunk.

 In accordance with FIG. 3, the MNG 302 client management module HAS first determines the number of HAS-i client modules to be activated, for example by accessing a file of restitution parameters. A reading of this file enables it, for example, to determine that the user of the rendering terminal 30 has given him a rating of three stars out of five, or that the number of persons present in front of the screen of the rendering terminal 30 is sufficiently high. to activate several HAS client modules, for example three.

The number of HAS client modules to be activated can result directly from the reading of the restitution parameters file, which may for example be in the form of Table 1. It may also result from a calculation made by the MNG module of 302, according to an algorithm which will not be described here in more detail, which can be multi-criteria, and take into account weightings, for example assigned to the different parameters of Table 1.

 Table 1

 The MNG module 302 thus activates the three client modules HAS-1 to HAS-3, for the purpose of downloading and rendering by the terminal 30 of the content Cl.

 During a step referenced 310, the MNG module 302 retrieves the manifest file 7 to discover the available fragments of the video content C1, and the various video qualities Nj associated. In the example of FIG. 3, the content C1 is for example proposed in the form of fragments of duration 3s, with a first encoding bit rate NI = 500 kb / s, a second encoding bit rate N2 = 1000 kb / s , a third encoding rate N3 = 2000 kb / s, etc.

 During a step referenced 311, the MNG management module 302 drives the client modules HAS-1 to HAS-3, in order to optimally download the various fragments Cli @ Nj. There are as many TCP sessions as there are HAS clients, so the bandwidth recovery is weighted according to the number of clients.

 Thus, if it is assumed that in addition to the rendering terminal 30, two other terminals are in the adaptive download phase of content in the local network (for example the terminals

3 and 4 of Figure 1), and only one HAS client module is activated in each of these two other terminals, the distribution of the bandwidth of 6 Mb / s is therefore done automatically by TCP mechanisms as follows:

 • Terminal 3 (for example assigned to download a delayed television program):

 1 / (1 + 1 + 3) * 6 Mb / s = 1.5 Mb / s

 • Terminal 4 (eg assigned to download a live TV channel):

 1 / (1 + 1 + 3) * 6 Mb / s = 1.5 Mb / s

 • Terminal 30 (for example, assigned to download video on demand):

 3 / (1 + 1 + 3) * 6 Mb / s = 3 Mb / s

 The VOD client of the terminal 30 thus recovers half of the total bandwidth, thanks to the activation of three client modules HAS-1 to HAS-3 by the management module MNM 302.

 To optimize the downloading of the content Cl, and its restitution by the terminal 30, the management module MNG 302 addresses commands dedicated to each of the client modules HAS-i, so that each client module HAS-i recover autonomously and parallelized the different fragments of the content C1, during a step referenced 312.

Thus, in stabilized operating mode (ie outside of the initialization phase or the start of the download which will be described in more detail below), the management MNG module 302 sends the client module HAS-1 a download command fragment 01 _C @ N1 (the first time fragment at an encoding rate of 500 kb / s) and fragment C1 ₄ @ N3 (the fourth time fragment at an encoding rate of 2000 kb / s).

The client module HAS-2 receives a download command of the C1 ₂ @ N2 fragment (ie the second temporal fragment at an encoding rate of 1000 kb / s) and of the fragment C1 ₅ @ N4 (the fifth time fragment at a single time). encoding rate of 3000 kb / s). Finally, the client module HAS-3 receives, from the management module MNG 302, a download command of the fragment C1 ₃ @ N3 (the third time fragment at an encoding rate of 2000 kb / s) and the fragment C1 ₆ @ N3 (ie the sixth time fragment, also at an encoding rate of 2000 kb / s).

 The management module MNG 302 thus continuously calculates, according to the network conditions, what is the optimum encoding rate to be used to enable a continuous reproduction of the content by the terminal 30, and sends the corresponding commands to the various client modules. HAS-i, until the end of the return of the content C1 by the terminal 30.

Note that, in this embodiment, as several time fragments are retrieved in parallel by the different client modules HAS-i, the maximum time to retrieve a fragment of the content Cl is therefore N x 3 seconds, where N is the number customer modules HAS-i enabled by the MNG management module 302, and where the duration of a temporal fragment Cl _{r (} S ⁾ Nj is three seconds.

 The various fragments downloaded by the various client modules HAS-1 to HAS-3 are transmitted to the video player V.P. 301 which decodes them for their return to the user by the terminal 30.

The algorithm implemented by the management module MNG 302 to determine which fragment at which encoding rate must be downloaded by the client module HAS-i may be one of the already existing algorithms of the prior art, since that the management module MNG 302 takes into account the recovery time of the fragment i-1 by the client HAS-j to determine the encoding bit rate of the fragment i by the client HAS-j + 1. This algorithm will not be described here in more detail. Note, however, that the HAS-i client modules are solicited one after the other to retrieve the successive fragments of the content: thus, preferably, if the client HAS-1 retrieves a fragment Cl ,, the client HAS-2 retrieves the fragment Cl _{i + 1} , and the client HAS-3 retrieves the fragment Cl _{i + 2} , and so on.

 This description corresponds to the stabilized operating mode of the adaptive progressive download management device of the rendering terminal 30. At initialization, it may be advantageous to operate a progressive scaling up of the download, starting with an instantiation a client module HAS-1, then wait for a stabilization phase before activating a second client module HAS-2, and so on alternating new activation and waiting during a stabilization phase. An immediate activation of all the HAS-i client modules could indeed cause discomfort for the user, for example in the case of a download of a television content channel, in the event that he decides to "zap ". This initialization phase is illustrated in FIG.

 During a phase of starting the adaptive progressive download, it is thus possible for the MNG management module 302 to first determine (42) the optimum number N of client modules HAS-i to be activated, for example as a function of the type of content (paid or free) chosen during a step referenced 41 (or more generally using the restitution parameter file, an example of which is given in Table 1), then activates (43) the first client module HAS -1 by sending a download command (45) of the first temporal fragment Cli @ Nl at the lowest encoding rate proposed in the manifest 7 (here for example Nl = 512kb / s).

The management module MNG 302 then initiates a counter (44), or "timer", in order to verify that the quality Q of reproduction of the content C1 is stable, for example for a duration of 10 times the duration of a temporal fragment, in this example 30 seconds. At the end of this duration of 30 seconds of stability of the quality of reproduction (46), the management module MNG 302 can then activate a second client module HAS-2 (47), by sending him the appropriate commands for downloading the fragments of the content Cl. He can again wait for a stabilization time of the quality of thirty seconds before activating the third and last HAS-3 client module. It is only after this phase of initialization and progressive scaling that the three client modules HAS-1 to HAS-3 can operate simultaneously for the parallel download (48) of the different fragments of the content C1, according to the commands received from the MNG management module 302, and in accordance with the example of FIG.

APPENDIX 1: Sample manifest file

Claims

A method for managing the adaptive progressive download (HAS) of a digital content within a terminal (3-5; 30) for rendering a local communication network (10), comprising a step of obtaining ( 310) (7) of a description file of said digital content, comprising a list of time segments (Cli @ Nj) of said content each associated with several encoding rates of said content, characterized in that it comprises:  determining (42) an integer N> 2 of client modules (HAS-i) to be activated within said rendering terminal for downloading said content;  transmitting to each of said N client modules to activate a download command of at least one of said time segments at one of said encoding rates of said description file;  N downloads in parallel, by each of said N client modules, said time segments to said encoding rates, in accordance with said command transmitted.  2. Management method according to claim 1, characterized in that said determination of the number N of client modules to be activated for downloading said content takes into account a preference of a user of said rendering terminal.  3. Management method according to any one of claims 1 and 2, characterized in that said determination of the number N of client modules to be activated for downloading said content takes into account a dimension of a screen of said restitution terminal.  4. Management method according to any one of claims 1 to 3, characterized in that said determination of the number N of client modules to be activated for downloading said content takes into account a characteristic of said content belonging to the group comprising: a duration said content;  a type of said content.  5. Management method according to any one of claims 1 to 4, characterized in that said determination of the number N of client modules to be activated for downloading said content takes into account a number of users to which said content is returned.  6. Management method according to any one of claims 1 to 5, characterized in that said determination of the number N of client modules to be activated for downloading said content takes into account a profile of a user to which said content is returned . 7. Management method according to any one of claims 1 to 6, characterized in that said number N of client modules is between 2 and 5. 8. Management method according to any one of claims 1 to 7, characterized in that, after said determination of the number N of client modules to activate, it comprises a phase of initialization of said download, including an incrementation progressive number of i client modules to which are transmitted said time segments download commands, for i varying from 1 to N.  9. Device for managing adaptive progressive downloading (HAS) of a digital content within a rendering terminal of a local communication network, comprising a module for obtaining a description file of said digital content, comprising: a list of time segments of said content each associated with several encoding rates of said content, characterized in that it comprises:  a plurality of client modules for downloading said content, able to download time segments of said content to one of said encoding rates of said description file;  a module for managing said client modules, able to determine a number N of client modules to be activated for downloading said content, and to transmit to each of said N client modules a download command, dedicated to said client module and comprising an identifier of at least one of said time segments at one of said encoding rates.  10. Terminal for rendering a digital content, characterized in that it comprises a device for managing the adaptive progressive download (HAS) of a digital content according to claim 9.  A computer program product comprising program code instructions for implementing a method as claimed in any one of claims 1 to 8, when executed by a processor.